Do none of you look at the Tasmota Wiki? THere is an automation to get the state of the switch when HA restarts.
I have an automation:
- id: '1532478833428'
alias: Power State Sonoff on HA Start-Up
initial_state: 'true'
trigger:
- event: start
platform: homeassistant
action:
- data:
payload: ''
topic: sonoffs/cmnd/state
service: mqtt.publish
Totally agree, and I didn’t see that message when I was looking previously (a week ago) because they just barely released 0.92 like 18 hours ago. lol:
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.
-Greg
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.
Yes you need to be retaining messages in the tasmota settings…
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/POWERto%topic%/%prefix%/COMMAND, e.g.sonoff/cmnd/POWER. You cannot use custom defined topics whileSetoption19is 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”
POWER1 = Reed Switch
POWER2 = Relay
- platform: mqtt
name: "garage_door"
state_topic: "stat/garage/POWER1"
command_topic: "cmnd/garage/POWER2"
state_open: "ON"
state_closed: "OFF"
payload_open: "ON"
payload_close: "ON"
payload_stop: "ON"
Pro tip, you don’t need the automation to turn off to relay. There’s a Tasmota setting you can use instead.
PulseTime 5
Also I haven’t seen the need to use PowerRetain 1. Using SwitchRetain 1 seems to be enough.
Curious to try setting SwitchTopic2 to 0 to see if it adapts the topic like it does for you. It bugged me that I had to define it.
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.
I got mosquitto set up and it works very well. I like having the ability to run mosquitto_sub and watch all the messages and I guess because it’s a completely separate docker instance in hass.io when you restart HA, it retains everything which is IDEAL.
Thanks for the info RyanEwen.
just wanted to share my setup that I’ve been working on. quick disclaimer, I haven’t hooked up the final project yet (hopefully doing that this weekend), but this seemed to work fine while testing with a breadboard at my desktop.
Parts:
Tasmota Config
Backlog
Module 18;
PowerOnState 0;
Gpio4 9;
Gpio5 10;
Gpio12 29;
PulseTime 7;
SwitchMode1 2;
SwitchMode2 2;
SwitchTopic 0;
Rule1 1
&
Rule1
ON switch1#boot DO var1 %value% ENDON
ON switch2#boot DO var2 %value% ENDON
ON mqtt#connected DO BACKLOG event SetClosed=%var1%; event SetOpened=%var2% ENDON
ON switch1#state DO event SetClosed=%value% ENDON
ON switch2#state DO event SetOpened=%value% ENDON
ON event#SetClosed DO publish2 ha/garage/closed %value% ENDON
ON event#SetOpened DO publish2 ha/garage/opened %value% ENDON
Rule1 is where the most of the magic happens. When the board boots, I use switch<x>#boot to get the value of the alarm contact sensors and set them both to a variable. Then, when the MQTT connection is initialized (mqtt#connected), I immediately publish those values via custom events (SetClosed & SetOpened). Finally, I use switch<x>#state to publish any alarm contact changes.
Some key points…
publish2 is used instead of publish since publish2 uses a retain flag. This enables HomeAssistant to grab the last published message upon booting. Also, the switch<x>#boot event is nice because it lets me capture the alarm contact states immediately upon the ESP8266 boot instead of waiting for a state change.
I haven’t started testing the HomeAssistant side of things yet, but it will basically be two mqtt binary sensors and a template cover. The template cover will have open/close/stop actions that all publish an mqtt ON message to the POWER1 topic of my Tasmota. Then the position template will look something like the following pseudo-code:
if (closedSensor = 1) {
return 0
}
if (openedSensor = 1) {
return 100
}
return 50
hope this helps someone. i’ll report back once everything is setup entirely.
Diagram:
I’m migrating away from the tasmota/sonoff managed solution to my own ESPHome one. I posted the ESPHome.io yaml file here. It avoids using mqtt and brings all “decision making” into the esphome device, closer to the hardware. Now I just need to build the hardware for it. 
This used to work but I’m not sure when it broke. Now it doesn’t work with Sonoff TX switch or my newly Tasmota flashed Gosund dual outlet.
It is still working for me. Are you still using the MQTT integration and discovery or did you switch to Tasmota integration? I’m still on discovery and MQTT integration and no issues.
Sorry for my ignorance. How do you tell the difference?
Do you have or did you add the tasmota integration?
No, I didn’t. Didn’t know there’s such an integration.
David, thanks for your pointer. I added tasmota integration to HA, upgraded my tasmota from 8.3.1 to 9.2 and all 8 devices show up automatically. No need to add power state startup automation. Thanks again.
Weird. I am only using Mosquitto broker with MQTT integration. I also use auto-discovery and it’s worked like that for 3 years once I set the retain options properly. No idea why it would have just stopped working on your system. I tried the Tasmota integration but it didn’t add any value and in fact was less useful than the ‘old’ way.
Could running the latest version of HA matter? I’m on 2020.12.1
