krkeegan / home-assistant-addons Goto Github PK

Similar to Panel. Can be used to determine if HA is acting on a re-delivered retained message.

Publish online and offline states and use last will and testament.

This likely creates a better user experience as it will make it clear to the user if this addon is down.

Could be created through MQTT discovery (which I already know well, but would require config settings) or I could learn the HA API.

I feel like this is an unsolvable problem, without making a change to our structure. Take the following:

1. Zone is faulted
2. alarmdecodermqtt is turned off
3. zone is restored
4. alarmdecodermqtt is turned on

In this scenario, the zone will be reported as faulted if retain=True.

Alternatively, if retain=False the faulted zones will be in an unknown state to any mqtt client when the client restarts.

Possible Solutions:
1a. If we know all the the zones (currently we do not) when ADMQTT restarts it can have a timer such that if a zone is not seen as faulted within the a specific time frame, it is reported as restored.

1b. Similar to 1 but check the MQTT state of the zone and only report as restored if zone was in faulted state? This seems annoying to have to add subscribe just for this.

In any event, it seems like we are going to need to know all the zones, which is probably fine, since we would need to in order to enable the discover feature anyways.

Syncthing will automatically upgrade itself. This seems to work fine until the DB schema changes. I think when the container is restarted, it is reverted back to its state on installation (meaning the originally installed version of syncthing is used) if the DB was updated before this restart, then syncthing cannot start.

This would require more frequent updates to the addon to stay up to date with upgrades, but wouldn't have the risk of a fail to start on reboot.

When HA boots, it does not restore the prior state of any binary sensors, all of them are assumed to be off or closed.

When AlarmdecoderMQTT boots, it also assumes all things to be closed or off.

The problem arises when you reboot HA but not ADMQTT. In this case, ADMQTT doesn't re-notify HA of the device states.

Options to solve the discrepancy:

1. Publish zone messages with the retain flag, essentially causing the MQTT broker to be the keeper of device states through reboots.
2. Monitor the HA restart topic from ADMQTT and republish the state of all zones when a reboot is detected.

We use a mix of both methods in InsteonMQTT.

However, if I have any plan of adding the discovery protocol I should consider #2 as we have to republish the discovery topics on reboot anyways.

The ADMQTT service may come online before the MQTT broker. Currently we only try once and die. It would probably be better if we tried x times in x second and then died.

This could simplify some of the config. It would certainly move all of it out of the HA configuration.yaml and would require putting some of it in our config.

At minimum, I we need to know:

• What zones exist? No way to know this using API.

Do we do anything else? User can be forced to edit all of this using customization and such in HA, but that seems less than convenient.