MQTT switches working strange lately

Configuration
1

I have been using MQTT switches for while now with Tasmota running on Sonoff Basic modules. Lately, I’ve noticed that switch changes made in Home Assistant don’t seem to get acknowledged by the switch. At least, that’s what I assume this means:

image

This is my switch configuration:

- platform: mqtt
  name: "Switch 1"
  command_topic: "cmnd/sonoff10/power"
  state_topic: "stat/sonoff10/POWER"
  availability_topic: "tele/sonoff10/LWT"
  payload_available: "Online"
  payload_not_available: "Offline"
  qos: 1
  optimistic: false
  payload_on: "ON"
  payload_off: "OFF"
  retain: true
  icon: mdi:current-dc

I can use mosquitto_sub to watch MQTT messages to and from the Sonoff and I see this when I turn the switch off:

cmnd/sonoff10/power OFF
stat/sonoff10/RESULT {"POWER":"OFF"}
stat/sonoff10/LOGGING 16:08:28 MQT: stat/sonoff10/RESULT = {"POWER":"OFF"}
stat/sonoff10/POWER OFF
stat/sonoff10/LOGGING 16:08:28 MQT: stat/sonoff10/POWER = OFF

How do I debug this? I set the logger default to debug but I could not learn anything from the logs. As far as HA is concerned, everything seems fine. That is, there are no errors. Is it possible that HA is not subscribing to the topics I refer to in my configuration? Can I look at those subscriptions while HA is running?

2

Your state_topic needs to be
stat/sonoff10/RESULT

3

should match

so the configuration looks correct to me - as it should be if it was working at one point.

One other possibility is that HA is no longer connected to the broker. Does the switch in HA change state when the light is turned on by other means?

4

and

If you want the power states to be persistent in Tasmota and Home Assistant set PowerRetain 1 (CLI in tasmota) instead of using retain: true (delete it in your config) in Home Assistant

and SetOption59:
Required Commands
SetOption59 1 - enables sending of tele/%topic%/STATE on POWER and light related commands

should work for switches due to the tasmota docs:

hope that helps

5

Isn’t it wiser to set it to false. Rather than deleting it from the config cause the broker will still retain the previous setting of true.

6

Probably YES, cause I don’t know the default.

7

False is the default. If you had true, you need to delete the retained message from the broker otherwise it will cause you some grief.

8

Thanks for all of the suggestions. I’m working through all of the changes one at a time and, so far, none have solved the problem. The change that includes putting “RESULT” in the topic caused the switch to snap back immediately so I know that alone is not a solution. I tried cutting and pasting one example from the Tasmota website but it didn’t just work either. I may need to install an older version of Tasmota to get it working again.

9

To be honest, I thought that was your problem was with your original configuration. Can you describe exactly what the problem you are having is? The OP just had a picture of an off switch.

10

Try this:

- platform: mqtt
  name: "Switch 1"
  command_topic: "cmnd/sonoff10/POWER"
  state_topic: "stat/sonoff10/RESULT"
  value_template: "{{ value_json.POWER }}"
  availability_topic: "tele/sonoff10/LWT"
  payload_available: "Online"
  payload_not_available: "Offline"
  qos: 1
  payload_on: "ON"
  payload_off: "OFF"
  retain: false
  icon: mdi:current-dc

What version of tasmota are you using?

11

The picture in the original post is meant to show that when you click the switch, it goes to the new position and stays but a ring persists around it. In the snap-back behavior I described later, the switch moves to the new position and snaps back in less than a second.

12

I’m using 8.1.0.
Your suggestion is what I’m trying now and it behaves the same way as the original post. The switch works, but the ring around it persists like the change was not acknowledged. I’d like to know the difference between the two behaviors:

1 - switch works but the ring persists indefinitely
2 - switch moves but snaps back
3 - switch change persists for awhile (5 seconds?) with a ring around it and then reverts to original state

I don’t really know what could cause behavior 1 (the one I’m seeing). If I were to guess, behavior 2 reflects an unexpected state update from the device since it reverts immediately. That leaves behavior 3 to describe when no state update is seen by HA from the device and a timeout on the update forces the switch back to the original state.

13

Is there a way to contact the developers and ask what is happening when behavior 3 occurs? That could speed up troubleshooting this problem a lot if we knew what’s missing from HA’s point of view.

14

Shouldn’t this be:

command_topic: "cmnd/sonoff10/POWER"

The ‘ring’ is just showing you what you have tapped. If you tap in the header you will see it disappear.

Is this just a simple switch? Is there a reason to not use MQTT discovery? I have 8 tasmotized devices all using discovery (7 are switches) and they all work. I am on firmware 8.1.0.1 It’s not a HA or Tasmota error but a config error I think. You could also try the Tasmota Discord for help…

1 Like
15

Yes, this is a simple switch. I decided to take your advice and try to use MQTT discovery. I got the latest Tasmota/master from github and verified that it was set up for MQTT discovery. I built it in platformio and uploaded it to the Sonoff Basic. I then commented out the configuration I’ve been working with so it wouldn’t conflict with discovery of the switch (I was being cautious; maybe I didn’t need to do that).

The HA documentation for MQTT discovery does not say when discovery takes place so I just restarted HA. After restart, I got this panel:

image

After clicking “Check it out”, I see this:

image

The “Homekit Accessory” entries seem to be just copies of the two ecobee thermostats I have. They are already configured in HA and working so I don’t know why they show up here. I wish I could stop them from showing after every restart.
The other entry, “MQTT: configuration.yaml”, seems to offer a chance to see my switch but all I see when I click it is:

image
image844×110 3.62 KB

I looked in the services menu to see if a homeassistant.discovery service was available but I didn’t see one. I have no confidence that a discovery was done. The Tasmota console on the Sonoff did not show that it participated in a discovery. So, what am I missing here?

16

I got the discovery working. I needed to use the SetOption19 1 command despite setting

‘’’
#define HOME_ASSISTANT_DISCOVERY_ENABLE 1
‘’’
in the my_user_config.h file in Tasmota. I then found the device in Configuration/Options. With the auto discovered device, I see the persistent ring again and so I reread David’s reply saying that the ring is benign and does not indicate an error. I don’t understand the value of it since it is so close to the ring that indicates that a status reply is pending.

Do you know if the auto discovered devices are documented in a yaml file where they can be edited?

17

No. You don’t use anything in yaml with discovery. There should be a MQTT integration though that will show the entities and you can edit them in there.

I see from your screenshot that the integration you have seems to think that it is still configured in the configuration.yaml - you should remove the mqtt: section and any manually configured switches and then restart HA. You may then also need to remove the integration and add it again.

18

I have a dozen or so sonoffs many with Tasmota rev 5 on them embedded in places that make them hard to upgrade (no OTA upgrades for 1MB flash). SO now I have a mix of auto-discoverable and non-auto-discoverable switches and lights. I think I’m going to stick with YAML files and leave auto discovery for the wizards.

Now, I just have to figure out how to remove the auto-discovered device…

19

Since when? All mine are 1MB and always do OTA. You might need to flash the minimal version first and then the full though. I build my own firmware and it’s around 450kb so I don’t have to do that.

20

One other oddity that I found is that with the sonoff running a pre-compiled binary (uploaded with Tasmotize), the MQTT topics are as you’d expect:

tele/sonoff10/STATE

With the sonoff running the version of Tasmota that I built in platformio, the MQTT topic is

sonoff10/tele/STATE

I cannot find the tool to control the form of the topic in the .h files. So, another mystery…