Feature: Allow sending commands via MQTT or HTTP

[mrtnkhl]

It would be great to be able to send commands to the Bus via MQTT or HTTP in addition to being able to send via serial. Particularly when there is no computer close to the gdoor adapter/ESP32, sending commands via network would be ideal.

Maybe sending of the commands could be implemented in two ways:

• raw, send any raw command to the bus
• per function: e.g. open door, with the necessary parameters
• per slot (see new SIP firmware), allow configuration settings to be added per slot that allow the identification of the door to open per slot and then just the slot with command open can be requested via network

[DaSchaef]

MQTT sending is already implemented. Also in audio firmware and should work. If not it is a bug in the audio beta.

[mrtnkhl]

@DaSchaef awesome, do we have some generic documentation for that? It seems openhab documentation has it, but I am not familiar with openhab

[mrtnkhl]

https://gdoor-org.github.io/documentation/openhab.html

From what I can gather from the above to send a command to the bus via MQTT you have to publish to the MQTT topic "gdoor/bus_tx".

The payload is unclear. Is it 'formatBeforePublish="020031ECF3EB0060A11A2F76BD"' or is it just '020031ECF3EB0060A11A2F76BD' or is it a JSON?

Neither of the two first options seems to do anything. They are published and can be found on the MQTT broker but the gdoor device does not send a request.

[DaSchaef]

We need to improve MQTT documentation yes.

The topic is correct (it is the default value, you can change it in the web interface) and just send raw, the busdata json entry of the received message you want to send.

At the moment I do not know what the bus message 020031ECF3EB0060A11A2F76BD means and where it comes from, without decoding it.
But it needs to be the value you received on your bus of the action you want to "clone". This should work.

If it does not work we may have a bug in the beta firmware or the wiring between ESP and GDoor is somewhere wrong.

[DaSchaef]

Also the serial debug log should show what the GDoor is trying to send:

From sourcecode:

GDOOR::send(str_received); // Send to bus if it is not a command
JSONDEBUG("Send: ");
JSONDEBUG(str_received);

[mrtnkhl]

@DaSchaef so I got this to work somewhat in Home Assistant, but something is weird:

YAML to add a dashboard button to send to the bus (opens the door in this case). Note that the topic is "gdoor/bus_tx" not "/gdoor/bus_tx" as one would think from the openhab docu linked above.

Example Street Door

show_name: true
show_icon: true
type: button
tap_action:
  action: perform-action
  perform_action: mqtt.publish
  target: {}
  data:
    topic: gdoor/bus_tx
    payload: 020031ECF3EB0060A103C27A3D
name: Street
icon: mdi:door-sliding-open
show_state: false

Here comes the weird part:

Example Courtyard Door

show_name: true
show_icon: true
type: button
tap_action:
  action: perform-action
  perform_action: mqtt.publish
  target: {}
  data:
    topic: gdoor/bus_tx
    payload: 020031ECF3EB0060A11A2F76BD
name: Courtyard
icon: mdi:door-open

opens the same door (Courtyard) although the payload is different.

Sniffed payload to OPEN DOOR COURTYARD

{"action": "DOOR_OPEN", "parameters": "0060", "source": "ECF3EB", "destination": "1A2F76", "type": "INDOOR", "busdata": "020031ECF3EB0060A11A2F76BD", "valid": true, "raw": ["0x3C", "0x20", "0xC", "0x20", "0x20", "0x20", "0x20", "0x20", "0x20", "0xC", "0x20", "0x20", "0x20", "0x20", "0x20", "0x20", "0x20", "0x20", "0x20", "0xC", "0x20", "0x21", "0x20", "0xC", "0xC", "0x20", "0x20", "0xC", "0x20", "0x20", "0xC", "0xC", "0x20", "0xC", "0xC", "0xC", "0xC", "0xC", "0xC", "0x20", "0x20", "0xC", "0xC", "0xC", "0xC", "0x20", "0xC", "0xC", "0x20", "0xC", "0x20", "0xC", "0xC", "0xC", "0x20", "0x20", "0x20", "0x20", "0x20", "0x20", "0x20", "0x20", "0x20", "0x20", "0x20", "0x20", "0x20", "0x20", "0x20", "0xC", "0xC", "0x20", "0x20", "0xC", "0x20", "0x20", "0x20", "0x20", "0xC", "0x20", "0xC", "0xC", "0x20", "0xC", "0x20", "0xC", "0xC", "0x20", "0x20", "0x20", "0xC", "0xC", "0xC", "0xC", "0xC", "0x20", "0xC", "0x20", "0x20", "0xC", "0x20", "0xC", "0xC", "0x20", "0xC", "0xC", "0xB", "0x20", "0xC", "0xC", "0x20", "0xC", "0xC", "0xC", "0xC", "0x20", "0xC"], "event_id": "5", "busvoltage": 25.27}

Sniffed payload to OPEN DOOR STREET

{"action": "DOOR_OPEN", "parameters": "0060", "source": "ECF3EB", "destination": "03C27A", "type": "INDOOR", "busdata": "020031ECF3EB0060A103C27A3D", "valid": true, "raw": ["0x3C", "0x1E", "0xB", "0x1F", "0x1E", "0x1F", "0x1F", "0x1E", "0x1F", "0xA", "0x1E", "0x1E", "0x1E", "0x1E", "0x1E", "0x1E", "0x1E", "0x1E", "0x1E", "0xA", "0x1F", "0x1F", "0x1F", "0xB", "0xB", "0x1F", "0x1E", "0xB", "0x1F", "0x1E", "0xA", "0xA", "0x1E", "0xA", "0xA", "0xA", "0xA", "0xA", "0xA", "0x1E", "0x1E", "0xA", "0xB", "0xB", "0xA", "0x1F", "0xB", "0xB", "0x1F", "0xB", "0x1E", "0xB", "0xB", "0xB", "0x1F", "0x1E", "0x1E", "0x1E", "0x1E", "0x1E", "0x1E", "0x1E", "0x1E", "0x1E", "0x1E", "0x1E", "0x1E", "0x1E", "0x1E", "0xA", "0xB", "0x1F", "0x1E", "0xB", "0x1F", "0x1F", "0x1F", "0x1E", "0xA", "0x1E", "0xA", "0xA", "0xA", "0xB", "0x1E", "0x1E", "0x1E", "0x1E", "0x1F", "0x1E", "0x1F", "0x1F", "0xB", "0x1F", "0x1E", "0x1F", "0x1F", "0xB", "0xB", "0xC", "0x1D", "0xA", "0x1F", "0xA", "0xA", "0xA", "0xA", "0x1E", "0xA", "0xB", "0x1E", "0xA", "0xA", "0xA", "0xB", "0x1F", "0x1E"], "event_id": "15", "busvoltage": 25.55}

Not sure what is happening here. Identical source makes sense (same indoor unit), destination is different.

Is it possible that the firmware does not refresh the payload from the MQTT topic update and just sees that there is an update and sends the same payload again without updating its variable?

[DaSchaef]

I think you hit a limitation of the Gira bus itself. The door opener used depends on the last BUTTON_RING message.
It is part of the Gira "bus training", when installing the bus.

The controller which operates the door opener relay decides if it opens the door.

https://partner.gira.de/service/faq/antwort.html?id=1268
In German from Gira, they talk about Nebenstellen etc, but in reality it is just a matter how your Gira Setup was configured. If DOOR_COURTYART is your main door opener, it will always fall back to this one:

Der an den Schaltaktor angeschlossene Türöffner kann nur über die Taste mit dem Schlüssel-Symbol der Wohnungsstation betätigt werden, wenn zuvor von der Türstation der Nebenstelle ein Türruf ausgegangen ist. Zwei Minuten nach dem Türruf (ohne Gespräch) bzw. 30 Sekunden nach dem Türgespräch erfolgt die Umschaltung auf die Hauptstelle.

[mrtnkhl]

Haha, fun times! Just found that out indirectly by rebooting the whole stack and getting the same result as described above.

Sniffed the bus again and found the payload for the street door that seems to be accepted at all times.

The below was what the firmware came configured with per default. So the documentation might need an update if this is the new default (it uses /gdoor/ not gdoor/)

[jschroeter]

I improved the HA MQTT docs with gdoor-org/gdoor-org.github.io#4.
Could you double-check? And then we can close this issue?