On my way to eat my own dog food, I learned the hard way that ghost switching is kind of the default problem most people will stumble upon when setting up their MQTT switch for the first time.This is not a big deal when you are configuring a single light switch or some other not so critical appliance. But when your switch is in series with your main circuit breaker, ghost switching suddenly gains a whole different level of importance.
When I first configured my Sonoff light switches I have indeed identified some weird behaviours, such as the lights turning on after restarting Hass.io. Because these were just kitchen lights I didn't give much importance to this particular problem.It was only when replicating the same kind of setup for the ZMAi-90 switch, and after having it installed in the breaker panel, that I felt the relevance of this nuance.Basically if in Hass.io (or other MQTT client) we use the setting:switch: - platform: mqtt... retain: falsethen we will let whatever state change message held in the MQTT broker to take effect once the consumer or the broker comes back online. If the consumer is a switch, then it will give priority to executing the command contained in that retained message.This in itself is not a problem, but the issue lies in the fact that messages can be retained forever unless we clean these. As such if there is a retained message and the device for example reboots, it will read that message and execute the command. The same applies if the device has to reconnect to the broker. If the retained message is there, the switch in the device will toggle to whatever state the message indicates to be in.This is exactly what happened with my ZMAi-90, while already installed in the breaker panel: everytime I restarted Hass.io (including the Mosquitto MQTT broker), the entire house would turn to full darkness. Also, a restart to ZMAi-90 itself would result in the switch staying off (instead of on, which was the previous state).
Soon after this I tried to learn more about the problem, a video that I found particularly clarifying was this from "The Hook Up" channel :
I started by in the Hass.io side, making sure that the switch and light entities were changed to the "retain: false" setting. On Tasmota, for each device, I made sure to have the following settings:
PowerOnState 3
SwitchRetain OFF
ButtonRetain OFF
PowerRetain ON (*)
Regarding PowerRetain in particular, I learned that the only effect of this setting would be of the application that consumes the power status messages from the devices (Hass.io in this case), retaining the last state the device reported, eliminating the need for adding automation for reading the current status of each device. As such I preferred to turn it ON, and no impact seemed to derive from it.
But at first, changing these settings did not appeared to have any effect. For testing, I used a Sonoff switch instead of the actual ZMAi-90 which was alread in the breaker panel - the least amount of power outages I would produce in my house, the better..
So, everytime I would restart the Sonoff, the switches would toggle to some default state. I went through the settings over and over again, and nothing appeared abnormal.
That's when I decided to follow the advice of cleaning retained messages from the MQTT broker. Installed the Tasmota Device Manager, and was able to effectively clean the retained messages:
And, bingo, that was it. Tested on the Sonoff, and after restarting the device, it would leave the relays in the same state these were left in before the restart. Unfortunately the relays briefly turn off during the warm restart, but this is likely difficult to avoid, due to GPIO pins being reinitialized during bootup. In the case of the ZMAi-90 this translates to a momentary power glitch which may disturb some devices in the house.
No comments:
Post a Comment