I’m using a Sonoff basic with ESPurna, the switch is also connected to a dumb switch.
I’m trying to accomplish the following behavior (without success):
Sonoff is fully managed from HA
Sonoff turns on when powered on by the dumb switch
HA Sonoff status is changed to ON when the Sonoff is powered on by the dumb switch
HA Sonoff status is changed to OFF when the Sonoff is powered off by the dumb switch
I’m not able to update the status in HA when the Sonoff is powered off by the dumb switch, which actually means that that the Sonoff is disconnected from the network.
If the dumb switch kills the sonoff then the only way HA will know about it is if you have set a will message, as that will be propagated to HA when the sonoff is killed by the dumb switch. I know nothing about Espurna so maybe someone else can enlighten you about setting up will messages in the software, but it should come as part of the package.
thanks for your replies! @j.assuncao , you mean to change my state_topic
from state_topic: "camera/switch/sonoff4/relay/0"
to state_topic: "camera/switch/sonoff4/status" ?
@asp that’s not it. I use Espurna on all my Sonoff but don’t use the LWT messages.
I think you need to create a sensor that reads the sonoff/{identifier}/status topic. When the switch disconnects the Sonoff the topic will change and that will tell HA that the Sonoff is powered off. This last part needs to be made with an automation.
Make a search in the forum and I’m Shure you’ll find someone that already made something like this.
Thanks for the hints @j.assuncao! I made some progress, I discovered that since version 0.50, MQTT Switch has “availability_topic” variable for online/offline status. So it should be sufficient to add:
Thanks @gpbenton and @j.assuncao! Now it’s working! It takes around 35 seconds to switch its status to “unavailable” when disconnected, but I can live with that
You may be able to reduce this if you have access to the ‘keep-alive’ parameter in the firmware on your sonoff. The availability message is sent when the broker determines the sonoff is not there, which is normally when the keepalive messages is not returned. If the keepalive message is sent more frequently, the response time will be quicker.