sim-san
commented
2 weeks ago I think Events are the right type of entity, we should use in HA: HA Events
The State of the entity is the timestamp of the last trigger. It is also deeply integrated with the automations. We have to think about how to integrate the payload in this event.
jschroeter
In https://github.com/gdoor-org/gdoor/pull/18 there was a discussion on whether
BUS_IDLEis 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.