I have seen suggestions where you disable the automation for x seconds after hass starts and then enable it,
Although i am sure it works its a massive hack to work around something that I must be misunderstanding so want to avoid this âsolutionâ if possible.
I feel like itâs a bandaid fix if you are doing something to work around a problem you donât understand. (Maybe itâs just me)
Also from what I understand you are saying you canât operate your garage door (automation) for 10 minutes after a hass restart?
I mean it works but i have high hopes to achieve better.
It could be that the retain flag has been set for the topic at some point and never been cleared. In that case, the broker would send a message whenever HA subscribed (such as when HA restarts).
You can check this by subscribing to the topic with a command line tool and seeing if a message is immediately printed. For instance
I will try it tomorrow, this sounds very plausible and likely!
I know little no nothing about the MQTT protocol.
I did attempt installing a GUI client for it so I could browse its data and logs but didnât get it working yesterday.
I might be wrong but I thought I had this issue with my sonoff / mqtt and turned my retain to true. I believe this worked as this is how I have it now. My thinking is if shutting off HA doesnât change any MQTT messages, when HA restart and requests the payload, it will get the same payload as when turned off.
I had an issue using the firmware from @KmanOz in that on poor or weak wifi connections or electrical noise on the line the sonoff would chatter off and on. the way I fixed it was to set retain to false.
Iâm not saying that your problem is the same but there seems to be some possible stability improvement when the retain flag is set to false.
I forgot to mention, if it is the problem you can clear the retain flag by sending a message with a null payload, and the retain flag set, to that topic.
You can use the mqtt.publish service from the HA developer tools and set this as the payload {"topic":"cmnd/sonoff_front/Dimmer", "retain":true}
@gpbenton you legend!
Thank you so much for pointing me in the right direction.
Each time I subscribed with this command
mosquitto_sub -v -t âceiling_fan/on/setâ
I got a âtrueâ response.
When I called
{âtopicâ:âceiling_fan/on/setâ, âretainâ: false}
I got a NULL in the subscriber command line, however when I stop and subscribe as per #1 it gives me the true response straight away.
I tried this command, it DID retain the value set each time I subscribed (Now off instead of on by default)
{âtopicâ:âceiling_fan/on/setâ, âretainâ: true, âpayloadâ: âoffâ}
After reboot I got the default as on again??
I delete the mosquitto.db persistence!
Its fixed
I suspect it was toggling the in memory value but when it read from the db it kept getting the old value.
I cant say for sure but it probably had trouble writing to that db file but reading was ok.