gdoor-org/gdoor

Wifi adapter and bus protocol documentation for the Gira TKS Door System

gdoor's Issues

DIN Rail Mount

To mount the gdoor adapter in an electrical panel next to other Gira intercom components, a 3D printed case that fits onto a DIN rail would be great.

Consistent (debug) output

Not urgent but I think we should invest the effort to only send 1 JSON per event. Initially I thought only Home Assistant gets confused when sending multiple, but it seems that MQTT Explorer also doesn't recognize the JSON format if Gdoor debug mode is enabled:

Learning bus messages per action

Motivation

Currently, to add replay actions to the bus system, you need to capture the busmessage through serial or the HA logbook and then have the gdoor adapter replay that message by either sending it through mqtt or through serial. Capturing the busmessage is required since the actual message per action is different for every single Gira setup.

Proposal

I believe it might be beneficial to add a learning_mode to record and store bus messages for any actions that are recorded while learning_mode is active.

Then, when an action is triggered e.g. through mqtt, we may look up the bus message required to trigger the action and replay it onto the bus.

Open design decisions

1. How can the learning mode be enabled? Is there a separate mqtt topic?
2. How is the learning mode disabled? Automatically after one action has been recorded? Through the same channel as above?
3. Where are bus messages stored persistently? In which format?

Add high-level props to JSON output

To allow comfortable automations/triggers in Smart Home platforms like Home Assistant.

Suggestion for new fields:

• action: doorBell / floorBell / openDoor / ...
• param: which button was pressed
• deviceType: doorStation / indoorStation / controller
• source
• destination

Video Support

There is currently no video support planned until bus protocol reverse engineering is done and interfacing with the digital bus is fully working. Creating this Issue as a placeholder for possible future work and to inform others who might be looking for video support.

Details concerning possible Audio support are tracked in Issue #20.

Per @DaSchaef there is sufficient evidence to assume that video is transmitted in analog just like the audio part of the communication with the (door) station in a resolution of roughly 320x240 pixels (or respective lines) per @jschroeter . It is assumed that an ADC would be needed to convert the analog signals to digital for the ESP32 and then send them via SIP/RTSP/RTP to a destination on the network. Issues outlined in #20 apply, in addition to those the extra bandwidth needed to digitize the video signal from the wire is going to be of concern.

Diagnostics: Bus connected / disconnected

Nothing urgent or necessarily needed but I thought it might be useful to have a diagnostics status / serial debug output when the adapter detects that the bus in connected/disconnected - if we can detect that.

BUS_IDLE

In #18 there was a discussion on whether BUS_IDLE is needed.

Quick summary (thanks chatgpt):

Implementation of BUS_IDLE:

DaSchaef: Implemented BUS_IDLE to prevent Home Assistant from showing incorrect states. Without BUS_IDLE, HA might display "ringing" even when the bus is not ringing.

Alternative States:

DaSchaef: Suggested exploring other states like "online" or "offline" for better accuracy, but admitted not being deeply familiar with HA.
nholloh: Agreed that BUS_IDLE is appropriate but noted that the DOOR_OPEN event is difficult to catch because it lasts only a second. Suggested leaving it as is for now, as bus data can be accessed via a serial connection during the initial setup.

Proposed Enhancements:

nholloh: Proposed adding an MQTT topic for a "learning mode" to capture and save the next DOOR_OPEN event, allowing for direct triggering via another MQTT topic. Suggested this might be a separate feature branch.
DaSchaef: Agreed that this would need a new pull request to keep track of changes and discussions separately.

MQTT Topics and Templating:

DaSchaef: Suggested sending two MQTT topics: one with BUS_IDLE and one without, using templating to filter out BUS_IDLE in discovery messages, requiring no code change in the ESP.
sim-san: Supported this idea, proposing the use of entity categories in HA to manage the display of these messages.

Concerns about BUS_IDLE:

jschroeter: Raised concerns that BUS_IDLE might clutter logs and history with unnecessary entries, making it hard to track events. Preferred not using BUS_IDLE, as it adds redundant updates. Suggested promoting the web flasher's serial terminal to access bus data directly instead of relying on the HA logbook.

Spare bus adapters

Does anyone, preferably from Germany, have a spare bus adapter lying around?

If not, I may proceed with an order. If you're looking to source one through me, feel free to leave a message here.

Build firmware via GitHub Actions & publish releases

To be able to download the firmware & upload it via Wifi web UI.

First action isn't received

As already mentioned by @DaSchaef, it seems like the very first action on the bus is always lost somehow.

Steps to reproduce:

1. connect adapter & monitor / upload & monitor
2. press e.g. "open door" on the indoor station
3. nothing is received
4. press "open door" again
5. action is received

MQTT Discovery

I'm collecting infos about MQTT Discovery

{
    "sw_version": "3.0",
    "name": "GDOOR Gira Bus Adapter",
    "force_update": true,
    "icon": "mdi:door",
    "state_topic": "gdoor/rx",
    "command_topic": "gdoor/tx"
}

topic: homeassistant/sensor/gdoor/data/config

retention flag needed

Add video and other bus actions to docs

Collecting some more bus actions to add them to the docs, code + streamline wording. Work in progress.

Outdoor ring & accept audio call & open door & manual close call

{"action": "BUTTON_RING", "parameters": "0360", "source": "A286FD", "destination": "000000", "type": "OUTDOOR", "busdata": "011011A286FD0360A04A", "event_id": "12"}
{"busdata": "011011A286FD0360A04A", "data": ["0x1", "0x10", "0x11", "0xA2", "0x86", "0xFD", "0x3", "0x60", "0xA0", "0x4A"], "valid": true}

# indoor station automatically tells the outdoor station to start the video stream
{"action": "CALL_ACCEPT_VIDEO", "parameters": "0278", "source": "ED3F4B", "destination": "A286FD", "type": "INDOOR", "busdata": "022028ED3F4B0278A1A286FD01", "event_id": "13"}
{"busdata": "022028ED3F4B0278A1A286FD01", "data": ["0x2", "0x20", "0x28", "0xED", "0x3F", "0x4B", "0x2", "0x78", "0xA1", "0xA2", "0x86", "0xFD", "0x1"], "valid": true}

# user activates 2-way audio by pressing the "phone" button on the indoor station
{"action": "CALL_ACCEPT", "parameters": "0000", "source": "ED3F4B", "destination": "A286FD", "type": "INDOOR", "busdata": "020021ED3F4B0000A1A286FD60", "event_id": "14"}
{"busdata": "020021ED3F4B0000A1A286FD60", "data": ["0x2", "0x0", "0x21", "0xED", "0x3F", "0x4B", "0x0", "0x0", "0xA1", "0xA2", "0x86", "0xFD", "0x60"], "valid": true}

# user opens the door by pressing the "lock" button
{"action": "OPEN_DOOR", "parameters": "0060", "source": "ED3F4B", "destination": "A286FD", "type": "INDOOR", "busdata": "020031ED3F4B0060A1A286FDD0", "event_id": "15"}
{"busdata": "020031ED3F4B0060A1A286FDD0", "data": ["0x2", "0x0", "0x31", "0xED", "0x3F", "0x4B", "0x0", "0x60", "0xA1", "0xA2", "0x86", "0xFD", "0xD0"], "valid": true}

# user closes the audio & video call by pressing the "phone" button again
{"action": "CALL_CLOSE", "parameters": "0000", "source": "ED3F4B", "destination": "A286FD", "type": "INDOOR", "busdata": "020020ED3F4B0000A1A286FD5F", "event_id": "16"}
{"busdata": "020020ED3F4B0000A1A286FD5F", "data": ["0x2", "0x0", "0x20", "0xED", "0x3F", "0x4B", "0x0", "0x0", "0xA1", "0xA2", "0x86", "0xFD", "0x5F"], "valid": true}

# unclear what this is doing
{"action": "ACTION_UNKOWN", "parameters": "0000", "source": "000000", "destination": "000000", "type": "TYPE_UNKOWN", "busdata": "E20020ED3F4B0000A1A286FD5F", "event_id": "17"}
{"busdata": "E20020ED3F4B0000A1A286FD5F", "data": ["0xE2", "0x0", "0x20", "0xED", "0x3F", "0x4B", "0x0", "0x0", "0xA1", "0xA2", "0x86", "0xFD", "0x5F"], "valid": false}

Outdoor ring + open door (without accepting audio call)

{"action": "BUTTON_RING", "parameters": "0360", "source": "A286FD", "destination": "000000", "type": "OUTDOOR", "busdata": "011011A286FD0360A04A", "event_id": "29"}
{"busdata": "011011A286FD0360A04A", "data": ["0x1", "0x10", "0x11", "0xA2", "0x86", "0xFD", "0x3", "0x60", "0xA0", "0x4A"], "valid": true}
{"action": "CALL_ACCEPT_VIDEO", "parameters": "0278", "source": "ED3F4B", "destination": "A286FD", "type": "INDOOR", "busdata": "022028ED3F4B0278A1A286FD01", "event_id": "30"}
{"busdata": "022028ED3F4B0278A1A286FD01", "data": ["0x2", "0x20", "0x28", "0xED", "0x3F", "0x4B", "0x2", "0x78", "0xA1", "0xA2", "0x86", "0xFD", "0x1"], "valid": true}
{"action": "OPEN_DOOR", "parameters": "0060", "source": "ED3F4B", "destination": "A286FD", "type": "INDOOR", "busdata": "020031ED3F4B0060A1A286FDD0", "event_id": "31"}
{"busdata": "020031ED3F4B0060A1A286FDD0", "data": ["0x2", "0x0", "0x31", "0xED", "0x3F", "0x4B", "0x0", "0x60", "0xA1", "0xA2", "0x86", "0xFD", "0xD0"], "valid": true}

# the following are happening automatically after 30s
{"action": "CALL_CLOSE", "parameters": "0000", "source": "ED3F4B", "destination": "A286FD", "type": "INDOOR", "busdata": "020020ED3F4B0000A1A286FD5F", "event_id": "32"}
{"busdata": "020020ED3F4B0000A1A286FD5F", "data": ["0x2", "0x0", "0x20", "0xED", "0x3F", "0x4B", "0x0", "0x0", "0xA1", "0xA2", "0x86", "0xFD", "0x5F"], "valid": true}
{"action": "CALL_CLOSE", "parameters": "0000", "source": "A286FD", "destination": "000000", "type": "OUTDOOR", "busdata": "013020A286FD0000A016", "event_id": "33"}
{"busdata": "013020A286FD0000A016", "data": ["0x1", "0x30", "0x20", "0xA2", "0x86", "0xFD", "0x0", "0x0", "0xA0", "0x16"], "valid": true}

Button ring + no user interaction

{"action": "BUTTON_RING", "parameters": "0360", "source": "A286FD", "destination": "000000", "type": "OUTDOOR", "busdata": "011011A286FD0360A04A", "event_id": "24"}
{"busdata": "011011A286FD0360A04A", "data": ["0x1", "0x10", "0x11", "0xA2", "0x86", "0xFD", "0x3", "0x60", "0xA0", "0x4A"], "valid": true}
{"action": "CALL_ACCEPT_VIDEO", "parameters": "0278", "source": "ED3F4B", "destination": "A286FD", "type": "INDOOR", "busdata": "022028ED3F4B0278A1A286FD01", "event_id": "25"}
{"busdata": "022028ED3F4B0278A1A286FD01", "data": ["0x2", "0x20", "0x28", "0xED", "0x3F", "0x4B", "0x2", "0x78", "0xA1", "0xA2", "0x86", "0xFD", "0x1"], "valid": true}

# indoor station closes the call after ~30s (time seems to be configurable in the indoor station)
{"action": "CALL_CLOSE", "parameters": "0000", "source": "ED3F4B", "destination": "A286FD", "type": "INDOOR", "busdata": "020020ED3F4B0000A1A286FD5F", "event_id": "26"}
{"busdata": "020020ED3F4B0000A1A286FD5F", "data": ["0x2", "0x0", "0x20", "0xED", "0x3F", "0x4B", "0x0", "0x0", "0xA1", "0xA2", "0x86", "0xFD", "0x5F"], "valid": true}

# also the outdoor station seems to close the call after a timeout
{"action": "CALL_CLOSE", "parameters": "0000", "source": "A286FD", "destination": "000000", "type": "OUTDOOR", "busdata": "013020A286FD0000A016", "event_id": "27"}
{"busdata": "013020A286FD0000A016", "data": ["0x1", "0x30", "0x20", "0xA2", "0x86", "0xFD", "0x0", "0x0", "0xA0", "0x16"], "valid": true}

View missed call / pressing the "menu" button on the indoor station

When viewing the missed call on the indoor station ("phone" button blinking + pressing it), the following command appears on the bus, although the video stream doesn't start or at least is not visible on the indoor station. It's just showing the picture which is saved on the SD card of the indoor station.
The same happens when pressing the "menu" button on the indoor station (there is no active call, no video showing, just the menu is visible).

{"action": "CALL_ACCEPT_VIDEO", "parameters": "0100", "source": "ED3F4B", "destination": "000000", "type": "INDOOR", "busdata": "013028ED3F4B0100A172", "event_id": "28"}
{"busdata": "013028ED3F4B0100A172", "data": ["0x1", "0x30", "0x28", "0xED", "0x3F", "0x4B", "0x1", "0x0", "0xA1", "0x72"], "valid": true}

Open door without open call

Similar to opening with an active call, but the destination is the controller instead of the outdoor station.

{"action": "OPEN_DOOR", "parameters": "0060", "source": "ED3F4B", "destination": "A25479", "type": "INDOOR", "busdata": "020031ED3F4B0060A1A254791A", "event_id": "11"}
{"busdata": "020031ED3F4B0060A1A254791A", "data": ["0x2", "0x0", "0x31", "0xED", "0x3F", "0x4B", "0x0", "0x60", "0xA1", "0xA2", "0x54", "0x79", "0x1A"], "valid": true}

Activate camera from indoor station (without audio call)

{"action": "CALL_ACCEPT_VIDEO", "parameters": "0278", "source": "ED3F4B", "destination": "A286FD", "type": "INDOOR", "busdata": "022028ED3F4B0278A1A286FD01", "event_id": "6"}
{"busdata": "022028ED3F4B0278A1A286FD01", "data": ["0x2", "0x20", "0x28", "0xED", "0x3F", "0x4B", "0x2", "0x78", "0xA1", "0xA2", "0x86", "0xFD", "0x1"], "valid": true}

Indoor station: "Schalthandlung"

see https://partner.gira.de/data3/12391110.pdf page 17

# Schalthandlung 1: on
{"action": "BUTTON_RING_UNKOWN", "parameters": "4140", "source": "ED3F4B", "destination": "000000", "type": "INDOOR", "busdata": "011042ED3F4B4140A1EC", "event_id": "35"}
{"busdata": "011042ED3F4B4140A1EC", "data": ["0x1", "0x10", "0x42", "0xED", "0x3F", "0x4B", "0x41", "0x40", "0xA1", "0xEC"], "valid": true}

# Schalthandlung 1: off
{"action": "BUTTON_RING_UNKOWN", "parameters": "4150", "source": "ED3F4B", "destination": "000000", "type": "INDOOR", "busdata": "011042ED3F4B4150A1FC", "event_id": "36"}
{"busdata": "011042ED3F4B4150A1FC", "data": ["0x1", "0x10", "0x42", "0xED", "0x3F", "0x4B", "0x41", "0x50", "0xA1", "0xFC"], "valid": true}

# Schalthandlung 2: on
{... "parameters": "4240" }

# Schalthandlung 2: off
{... "parameters": "4250" }

# Schalthandlung 3: on
{... "parameters": "4340" }

# Schalthandlung 3: off
{... "parameters": "4350" }

# Schalthandlung 4: on
{... "parameters": "4440" }

# Schalthandlung 4: off
{... "parameters": "4450" }

Internal calls from the indoor station

see https://partner.gira.de/data3/12391110.pdf page 17

# 1
{"action": "ACTION_UNKOWN", "parameters": "0160", "source": "ED3F4B", "destination": "000000", "type": "INDOOR", "busdata": "011012ED3F4B0160A19C", "event_id": "2"}
{"busdata": "011012ED3F4B0160A19C", "data": ["0x1", "0x10", "0x12", "0xED", "0x3F", "0x4B", "0x1", "0x60", "0xA1", "0x9C"], "valid": true}

# 2
{... "parameters": "0260" }

# 3
{... "parameters": "0360" }

# 4
{... "parameters": "0460" }

# 5
{... "parameters": "0560" }

# 6
{... "parameters": "0660" }

# 7
{... "parameters": "0760" }

# 8
{... "parameters": "0860" }

# 9
{... "parameters": "0960" }

# 10
{... "parameters": "0A60" }

Last action gets repeated?

I think there might be a bug in the firmware: apparently the last received action is repeated every now an then. In the screenshot there is a log of the actions received by Gdoor (note the increasing event_id). E.g. there are actions received during night time where there was clearly no user interaction. Maybe there are (yet unknown) things going on on the bus and due to a bug the last received action is detected again?
Unfortunately I don't have a debug mode log recorded yet - I'll try to record one asap.

ESPHome external component

Currently, home assistant integration is done through MQTT with auto discovery. However, in my opinion, the integration in home assistant still offers potential for optimisation:

1. Identifying bus messages to trigger various functions (door open, light, ...) is rather tedious, having to search through logbook, or by connecting the device via serial to a PC.
2. Triggering the functions currently has to be done by performing a service call to either echo something through the serial connection or perform a service call to send an MQTT message to a predefined topic, which carries just the bus message that was previously recorded.
3. The esp32 chip cannot be used for anything else, even though it might have resources to spare. That is, some people may find it useful to have it set up as bluetooth proxy for BLE devices, to extend home assistant's bluetooth coverage.

I believe there are multiple ways to address these issues.

I am currently exploring one of them, creating an external_component for esphome based on the gdoor code. In my opinion, esphome offers several advantages:

1. it provides an easy way to configure the rx related settings in the device's yml
2. it can provide an out-of-the-box feature to switch into a learning mode, where bus messages for certain actions (door open, light, ...) can be recorded
3. we can distinct buttons and states for these actions
4. the esp32 chip may additionally be used for something other than just being the gdoor adapter, by simply including that functionality in the device's yml.

For openHAB users I believe there is also a binding to include esphome devices, if desired.

Of course, most of this is also possible with the current firmware and MQTT based approach. However, I personally find the MQTT approach to be more verbose and it may require more knowledge on the user-side to get things up and running. Using esphome, we could reduce it to a couple of lines of yml code, which will be used by esphome to automatically compile the most recent firmware with default settings (of course you can override them) and flash that to the device.

I'd be keen to know any other Home Assistant user's take on this.

Audio Support

There is currently no audio support planned until reverse engineering and interfacing with the digital bus is fully working. Creating this Issue as a placeholder for possible future work and to inform others who might be looking for audio (and video) support.

Per @DaSchaef the audio (and video signals) are modulated onto the wire in an analog format. It is suggested but has not been verified through testing that connecting a headphone amplifier via a coupling capacitor to the bus would yield audio signals. Likewise, connecting a line-out to the bus could allow sending audio signals to the (door) station. It is important to understand that analogue audio (and video) signals are only present after the digital bus command has been sent to the respective station to transmit audio (or audio and video) on the wires that also transport the digital bus signals.

See https://gdoor-org.github.io/documentation/protocol.html "Request Audio", "Request Video" for more details on the respective bus messages.

Since is (unfortunately) no digital audio (or video) signal are present, a combination of an ADC and DAC, most likely connecting via I2S to the ESP32 is needed to convert the analog signals to the digital domain. Using an ADC, DAC and a Raspberry Pi could be an option as well but this would require too many resources and power.

Per @DaSchaef, on the ESP32 side, there is additional work needed, mostly in software, like working with the DMA engine, timing Wifi transmissions correctly, etc.. This work can be summarized in the categories of coupling, digitizing, processing and streaming to an endpoint, e.g. via SIP or RTSP. If one wanted to have bidirectional, parallel communication, with the other (door) station some analog circuit magic to prevent audio feedback loops would be needed as well.

Output is invalid JSON

e.g. validate the output with https://jsonlint.com/:

• trailing commas are not allowed
• hex values are not allowed

Bus Adapter Procurement Round 3

As mentioned from @github-k8n in #19 the bus connectors seem to be unavailable at JLCPCB.
https://jlcpcb.com/partdetail/Dorabo-DB301V_3_5_2P_GNS/C695629 can be a replacement,
but in the current HW Rev3.1 they would collide. Therefore the connector holes need to be moved a bit to the PCB edge.

I'll hopefully release a "Screw Terminal Version" 3.1-s this evening.
If you want to organize a procurement round, feel free to use this issue here 👍

How to build an Gira Bus <-> Smart Home adapter

Hello,
Thanks a lot for your efforts on documenting!

I’m looking for a (self-made) solution to open our house door via Home Assistant. I know there are commercial solutions like Gira TKS-IP-Gateway. But it’s too pricy.

I’m wondering if you could give me some guidance on how to build the hardware to connect to the bus? I’m a software guy, don’t know much about hardware. But e.g. I’m a bit familiar with ESPHome.

Thanks and have a nice day!