I watched Dr. Zzs youtube video to set up the $5 DIY Smart Garage Door Opener. He does a great job of quickly taking you through all the important pieces without wasting any time. Anyway, I installed the Sonoff SV devices on two previously “dumb” garage door openers and for the most part they work great but I noticed that when I restart HA the doors always come up with an Unknown status which makes the doors look open by default:
I restarted HA at 9:24 AM:
I found that the Sonoff SV has four retain settings (powerretain, switchretain, buttonretain, and sensorretain) and I have tried a bunch of combinations of those as well as the setting in the cover: retain: true and retain: false but nothing so far seems to make the door status in HA retain it’s last state. I wonder if anyone has this issue solved? I saw a lot of chatter about it in the comments on his video and a couple of threads that touched on it in this forum but it seemed no one has it nailed.
Currently my configuration looks like this.
Sonoff SV settings:
ButtonRetain: OFF
PowerRetain: OFF
SwitchRetain: ON
SensorRetain: ON
SwitchMode1: 0
SwitchMode2: 1
I don’t have sonoff SV but with all my sonoff basic I followed this Hook Up video which helped me.
This is my cheat sheet whenever I setup/re-config sonoff/tasmota switches:
retain: false (for HA light/switch config)
In Tasmota console:
SwitchRetain Off
ButtonRetain On then Off
PowerOnState 3
PowerRetain On
Wow, thanks TJPublic, I hadn’t seen that video. That guy knows some stuff! In his video though, he says that if you’re using a sonoff as a door sensor you should use SwitchRetain On and if you’re using it as a switch you should use SwitchRetain Off, however, the DrZzs solution uses the SV as both a switch and a door sensor at the same time.
I have found this morning that I can use the periodic "tele/sonoff-sv/SENSOR" results and a value_template to set the state (state_topic) but then after button presses the state won’t be set until the tele data arrives (which could be up to 5 minutes by default). The following block sets up a “test” entity which will receive it’s state within 5 minutes after HA restarts – however, the state doesn’t get set immediately after button press because the tele data isn’t published then, apparently it has to wait for the timeout.
Is there any way in HA to list two state_topic values to set the state of an entity? If I could set the state with both tele and cmnd strings, then I would get instant feedback on button press and when HA restarts, within 5 minutes it would recover the state of the garage doors.
Alternatively, maybe there’s a way to make the sonoff publish a tele event after the relay toggles? This would also solve the issue.
I know that I can increase the tele reporting frequency too but it really feels like a band-aid solution to rely on a timeout…
I probably is not the best person to ask about how SV sensor behaves and its usage, try a forum search about SV here or tasmota site, pretty sure there is setup example for SV already
Worst case, you may try a template switch to use multiple state/event for state or like you say play with tasmota timing/freq.
This is terribly annoying. I’ve found that there are three ways to see the door state with Tasmota but each one is on a different topic!
By default, when I click the Up/Stop/Down buttons I eventually receive this (which currently sets the state of my door): cmnd/toygarage/POWER2 = OFF (retained)
As far I can tell, there is no way to send a command to the sonoff and have it report this topic without actually triggering the relay. I can issue: stat/sonoff-sv2/status 8 and I get back: stat/sonoff-sv2/STATUS8 = {"StatusSNS":{"Time":"2019-04-07T23:57:42","Switch2":"OFF"}}
Where Switch2 contains the state of the door; or I can wait every 5 minutes and I get this:
Where Switch2 also contains the state of the door. If I could get the darn thing to report the tele/sonoff-sv1/SENSOR topic or the cmnd/toygarage/POWER2 topic via a manual command, I could set this up more simply.
cmnd/sonoff/power on
cmnd/sonoff/power off
cmnd/sonoff/power toggle
In response, Sonoff will send an MQTT status message like:
stat/sonoff/POWER ON
Therefore you publish the command to a topics whose root is cmnd and the device will acknowledge by publishing a response to a topic whose root is stat.
Telemetry messages are published by the device, on a periodic basis, to a topic whose root is tele.
Now that the root topics cmnd, stat, and tele are sorted out, perhaps you can explain the following:
The command_topic seems right but I’m puzzled by state_topic. It’s not subscribed to a status topic (stat/) but to a command topic (cmnd/). Why’s that?
The problem is that with this setup, the stat/sonoff-sv2/POWER value is for the relay (garage door button) and not the sensor (reed switch). I care about the reed switch’s state because it reports the actual position of the door.
When I activate the garage door button using mqtt or the console from Tasmota, I see this messaging:
01:16:18 MQT: stat/sonoff-sv2/RESULT = {"POWER":"ON"}
01:16:18 MQT: stat/sonoff-sv2/POWER = ON (retained)
01:16:19 MQT: stat/sonoff-sv2/RESULT = {"POWER":"OFF"}
01:16:19 MQT: stat/sonoff-sv2/POWER = OFF (retained)
01:16:31 MQT: cmnd/toygarage/POWER2 = OFF (retained)
The last message is sent by the Sonoff-SV2 to HA through mqtt and indicates that the reed switch is closed, triggered by the reed switch. When I open the garage door using the same method I see this:
01:22:01 MQT: stat/sonoff-sv2/RESULT = {"POWER":"ON"}
01:22:01 MQT: stat/sonoff-sv2/POWER = ON (retained)
01:22:02 MQT: cmnd/toygarage/POWER2 = ON (retained)
01:22:02 MQT: stat/sonoff-sv2/RESULT = {"POWER":"OFF"}
01:22:02 MQT: stat/sonoff-sv2/POWER = OFF (retained)
The cmnd/toygarage/POWER2 message happens much more quickly because the reed switch is opened immediately when the door starts to move.
It seems that the only topic I can rely on from the Tasmota software that is actually triggered by the reed switch changing state is this cmnd/toygarage/POWER2 topic.
Thanks! That’s interesting how Tasmota bends its own rules and uses cmnd/ for publishing the reed sensor’s state.
I looked for an example on the openHAB forum and found this post which confirms the choice of topic. The person is defining it as a contact sensor (openHAB equivalent of a binary_sensor) and uses: stateTopic="cmnd/rearGarageDoorSensor/POWER2" (effectively the same as the topic you’re using).
So it would appear the problem stems from the fact the Sonoff doesn’t publish retained payloads to this topic. If it did, when you restarted Home Assistant, the reed sensor’s last payload (i.e. its current state) would still be retained by the MQTT broker and available to Home Assistant. Because it’s not retained, Home Assistant receives nothing and so defines the state as unknown.
I had the same issue and I was unable to find a way to get the current state into HA after it was restarted (I was hoping to have an automation on HA startup that could do this, like I do for my other Sonoffs).
What ended up working for me was to just use SwitchRetain 1 so that the last message from Tasmota containing the door open/closed state is retained on the MQTT server. Doing that allows HA to see the open/closed state on restart as if it was just broadcast again at that time.
Note: don’t use retain: true on the HA side of things (always avoid that if you can… messages should only be retained if originating from the source of the sensor itself, and even then it’s better not to retain and to instead have HA request state, if possible).
Also note that you might need to setup your MQTT server to persist messages to a file if it’s not doing so already (mosquitto in docker for example), so that when the MQTT server is restarted your retained messages aren’t lost. This caused most of my state-related issues and I didn’t realize it for a long time. HA was requesting state for my other Sonoffs but since the retained LWT messages were lost, each device was marked as unavailable regardless of what on/off states were reported back.
Here’s my entire setup in case it helps (swap out the topic for your own):
Note that I am setting SwitchTopic2 to the same value as tasmota was already using for MQTT. This just enables the POWER2 message to be sent on it in addition to the already-existing POWER message. You could set SwitchTopic2 to anything you want, just be sure to match it in the state_topic line of your HA config.
Is this file-based persistence one reason why people choose to use an external MQTT broker like mosquitto? I’ve been wondering why everyone prefers an outside broker until now if the built-in home assistant MQTT broker doesn’t have this option of writing the messages to a file…
External MQTT servers are suggested a few times in the documentation. On the MQTT component page it suggests using an external server for better stability. On the MQTT broker page it says the embedded server is now deprecated and that there’s also a known issue about a possible memory leak with it. I am 99% sure that I also saw a note somewhere stating that the embedded broker doesn’t persist retrained messages between restarts, although I can’t find that at the moment.
In my case I just went with mosquito as it was suggested by the documentation and turned out to be really easy to add to my docker-compose.yml
However if I knew at the time that the built in broker didn’t persist retrained messages then it would have been the reason I didn’t use it
Stuff in HA is in flux constantly which is good and bad. I definitely prefer it over a stale setup but it does cause some additional churn, I actually secretly love it. Thanks for the help Ryan. I’ll install mosquitto and see how it goes.
DavidFW1960, that’s great for lights and plugs and I even mentioned it in my first reply to the OP, but it doesn’t help in this case as the reed switch state isn’t included in the messages that the automation gets back. It’s only included in response to ‘Status 8’ and we would need to parse that message somehow and tell HA to use that in addition to the command topic that Tasmota broadcasts Switch2 changes to.
Also garage door stuff aside, that automation only helps if the LWT messages are retrained and not lost during a reboot. If those are lost then each Sonoff shows up as unavailable until rebooted as well. I have been using that automation for my ~20 lights for months now and it failed to help until I realized that mosquitto wasn’t persisting messages to a file. I was rebooting all of my Sonoffs after rebooting my HA/MQTT box in order to get them to become available again.
To clarify, the automation you suggest helps with regular use cases where one simply wants to refresh the current relay state. Even then it only works if your MQTT server is persisting retained messages to file, else everything becomes marked as unavailable if the MQTT server is rebooted. The latter part doesn’t seem to be common knowledge.
In the garage door use case the automation does nothing as we don’t care about the state of the relay. We want the state of Switch2. The solution is setting ‘SwitchRetain 1’ which helps retain the state of Switch2. But again, the MQTT server needs to be persisting retained messages to file or you lose that message if it’s rebooted and won’t see the state of your garage door until it’s opened and closed next (or worse, if using ‘availability_topic’ it will get marked as unavailable until the Sonoff is rebooted).
For anyone who is confused as to why some MQTT topics are like device-name/cmnd/POWER instead of cmnd/device-name/POWER …
This happens when using Home Assistant auto discovery in tasmota. I must’ve had this enabled when I originally flashed my garage door sonoff, and then later turned it off as it’s not useful in this case. The tasmota Wiki states:
This feature will change the default Tasmota topic %prefix%/%topic%/COMMAND , e.g. cmnd/sonoff/POWER to %topic%/%prefix%/COMMAND , e.g. sonoff/cmnd/POWER . You cannot use custom defined topics while Setoption19 is on since it will always revert it to %topic%/%prefix% due to Home Assistant requirements.
Just to defend DrZzs, the video description does tell you the setup for the Powerretain, Switchretain etc.
The below is my config and work like a charm with an automation to set the POWER2 payload to “OFF” when the rely is “ON”.
Btw, I use a D1 mini instead of Sonoff-SV but they are the same setup. And I have only changed the power retain and switchretain to “ON”, SwitchMode and SwitchTopic are still the default “0”
Wow, didn’t know there’s a pulse time setting in Tasomta. Thanks for the tip, i’ll definitely give it a go.
The PowerRetain 1 works for my other tasmota switches to keep up the state in HA as well so I just keep it that way.
I have my “tasmotized” D1mini connected to an “Actual Relay” to trigger the garage door and a Reed Switch with a “Virtual Relay” to monitor the door state. Think that might be the reason for the SwitchTopic 0 works for me.
