Learning bus messages per action

[nholloh]

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?

[nholloh]

On a second thought a learning mode may not be necessary. We could have the adapter learn the appropriate bus message whenever it records an action that it did not trigger.

Technically speaking that means whenever we receive an action we could parse successfully, we store it in a map with the action string as key and save it to disk. This eliminates the need to provide a virtual switch to turn learning mode on and off.

From a user perspective, after the first setup they would simply have to press every button once to have gdoor learn all relevant bus messages. Also, should the message ever change, gdoor would be able to refresh it automatically once used.

[DaSchaef]

To be honest I do not understand what you want to achieve, neither your solution 😅

Also, I observed that some values may not be 100% stable, so button presses sometimes may vary.

[nholloh]

The fact that button presses are not stable is exactly what I wanted to tackle.

Because they're unstable and, as far as I understood from your documentation, vary per gira setup, we currently need to manually capture the bus messages and create a home assistant service call to publish the bus message on a dedicated mqtt topic.

I'd rather have a button entity that reads door_open, which you can press to open the door. However, to achieve this, the gdoor adapter needs to learn/map the button press to a previously recorded bus message.

Since gdoor can reliably determine the action of whatever it is, that is happening on the bus, we might use this to build a mapping of action to installation specific bus message. Then, home assistant could simply tell gdoor that the door open button was pressed, gdoor looks up the corresponding bus message internally (which it learned by observing s previous door open which was triggered manually) and sends that message on the bus.

This entirely eliminates the need for looking up and configuring the messages through logs or logbooks.

I hope this sums it up better :)

[DaSchaef]

Ah :)

, we store it in a map with the action string as key and save it to disk

This will not work sadly :-/

We would need to store the following actions with the following problems:

• "DOOR_OPEN" You could have multiple door openers (indoor, outdoor).
  The bus can handle it and Gira defines the setup.

• "BUTTON_RING" The depends on source (Button from which HW) and on parameter (which button, if multiple exists).
  For me they were pretty stable so far. But buttons are not fully understood.

• "BUTTON" The depends on source (Button from which HW) and on parameter (which button, if multiple exists).
  The parameter field is not yet fully understood. And there are bits which may "toggle".

• "BUTTON_LIGHT" see above

• "BUTTON_FLOOR" see above

• "BUTTON" , "BUTTON_LIGHT", "BUTTON_FLOOR": Depending on the Gira Setup,
  the action per button press changes.

In principle each bus message can be different although it may lead for the user to the same result / "action".
And this abstraction may then confuse the user even more.

TLDR: We need to select exact and understood, stable messages for this feature and ignore the rest.
This needs more bus data from all users so far:

• Which messages are constant?
• Which message are not constant, where?

Also we need to make sure that we do not write too often, I would assume the cheap storage inside ESP may not like lot's of write cycles.

[DaSchaef]

The main issue seems for me, that during the installation the bus is set up and this leads to kind of per installation individual messages, based on the setup (devices, mapping, assignment etc)

[mrtnkhl]

+1 on considering the multi tenancy, multiple door stations and multiple indoor stations across several apartments and doors scenario. The GIRA setup can scale pretty big and learning could be interrupted by another tenant being called from a door station, sending a door opening request or similar.