esp8266_milight_hub
esp8266_milight_hub copied to clipboard
Make MQTT QOS configurable
Currently all status messages are sent with retain = true. https://github.com/sidoh/esp8266_milight_hub/blob/50e91bf63d6249348300a9c7f502f2ced949a55a/lib/MQTT/MqttClient.cpp#L139
I'm using Milight remotes to control OpenHAB. So when I restard OpenHAB, it will fetch the last states of the remote from the MQTT server.
I have rules that will turn lights on and off based on an "received" trigger (not a "changed") trigger. This way I can switch on the light by using the remote, then use Alexa to turn the light off and later use the remote to turn it on again.
However if OpenHab is restarted, all remote states are fetched from the MQTT server which will trigger an "received" event which will the turn the light to whatever the last state of the remote was. This is quite problematic if The bedroom lamp was turned on using the remote, then urned off using Alexa and the OpenHab server restards in the middle of the night which will cause the lights to turn on again.
If the milight hub would send the status messages using retain = false this problem would go away as the messages are not persisted on the MQTT server.
To account for different scenarios it would be best to have a setting in the Web UI if retain should be true or false.
Makes sense.
Funny, I have same issue with HA. When there is a connection failure or the hub lost his connection and reconnect the last stored message will use to trigger the light.
retain=false will help.
But im wondering if this will also the opposite way: You working in HA and lights are on and you do a reboot will the lights still be on, will HA or OpenHAB get right status of the bulbs, or state them all as offline... (If HA and or OpenHAB, save last status in their dB then it will be ok)
any progress on this - retained messages from these bridges are causing chaos to automations every reboot or power cycle - also have to clear my mqtt db every time i rename a device
No active plans to pursue this, @s1nbad. The relevant section of the code has been linked. You're welcome to manually change retain to false.
Would also happily collaborate on a PR to add a setting! Wouldn't be hard, I just don't have the time or energy to make substantial changes to this project at the moment.
By the way -- "update" messages should not be retained. As a potential alternative, I'd recommend building your automations to work off of those instead of states.
understood, update topics are definitely not retained so I shall use those - thx