You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the solution you'd like
Home Assistant 0.113 added default MQTT birth and will message support. We should incorporate using that to trigger an automatic resend of discovery topics and last state topics for sensors. That will require adding storage of last state values in some way, possibly sensors.yaml.
This change, in theory, would eliminate the need to use retain with MQTT when implementation is for Home Assistant. I’ve personally had some issues with MQTT and retained topics where I occasionally have to dump Mosquitto’s persistent cache.
If OpenHab, or other platforms, support birth/will topics, then we should make the topic configurable and document defaults for known platforms.
Looking for feedback here before implementing, since this adds more disk writes to the host, and more MQTT communication.
The text was updated successfully, but these errors were encountered:
I personally do not like the idea of storing the states in `sensors.yaml`,
as this would make it a lot easier to become corrupted. I think having a
separate states database file of some sort would be a better option, using
something like SQLite.
As for disk writes, it could be stored in a variable and then only written
to disk every XX seconds, which can be configurable by the user. A default of 5 to
10 seconds should be suitable I would think. The only downside to this is
that a state or two might be lost in the event of a crash.
Lastly, it might be helpful to add an initial state to the sensor config.
Ideally this value would initialize and overwrite the assumed/stored state
of a sensor at startup, prior to sending out any events.
Certainly open to looking at something like SQLite, I was mostly thinking YAML is easy to read and debug, whereas a true database takes more effort, especially for someone less tech savy. A decent UI would solve that problem though (assuming we get motivated enough to do it. Though it could also be a new YAML file, something like sensor_states.yaml.
On the disk writes front, I'm less concerned, I just know with RPi's and SD cards, frequent excessive writes wear them out faster. So I wanted to mention it as a discussion item. Certainly could have it be another thread on a cycle though, and a few states being lost wouldn't be the end of the world, if the sensors trigger frequently enough.
I can appreciate the thoughts on an initial state, my concern would be an example like:
"Living Room Window is open", MQTT shows window is open
WS2MQTT restarts, default states sent
"Living Room Window is still open", MQTT shows window is closed
It certainly could just be an optional value, but if it got used could wreck all sorts of havoc with automations and the like. I think there will always be the risk that if WS2MQTT restarts or is off, a sensor event gets missed and things get out of sync, but since we can't actually poll the sensors (as far as I know) to see their current state, I don't think we can do much about that scenario.
Describe the solution you'd like
Home Assistant 0.113 added default MQTT birth and will message support. We should incorporate using that to trigger an automatic resend of discovery topics and last state topics for sensors. That will require adding storage of last state values in some way, possibly sensors.yaml.
This change, in theory, would eliminate the need to use retain with MQTT when implementation is for Home Assistant. I’ve personally had some issues with MQTT and retained topics where I occasionally have to dump Mosquitto’s persistent cache.
If OpenHab, or other platforms, support birth/will topics, then we should make the topic configurable and document defaults for known platforms.
Looking for feedback here before implementing, since this adds more disk writes to the host, and more MQTT communication.
The text was updated successfully, but these errors were encountered: