Mqtt switch changing state to incorrect value

Configuration
, ,
1

Hi everybody,

I have multiple tasmota devices that I created mqtt switches for. While most of them (using the same template!!) work fine, some of them keep showing incorrect values.

This is my TV switch

# (...)
  <<: &template
    platform: mqtt
    payload_on: "ON"
    payload_off: "OFF"
    state_on: "ON"
    state_off: "OFF"
    qos: 2
    retain: false

- name: "Schlafzimmer TV"
  command_topic: "cmnd/tasmotatv/POWER"
  state_topic: "stat/tasmotatv/POWER"
  icon: mdi:television
  <<: *template

The tasmota device is a Gosund SP1 v23 Modul running Sonoff-Tasmota 6.6.0.2 von Theo Arends.

  • PowerRetain: ON
  • TelePeriod: 10
  • SensorRetain: ON
  • GroupTopic: tasmota
  • Sleep: 50

Sometimes when I turn on/off the TV via mobile webUI, the device will physically turn on/off . However, after a couple of seconds, the switch will change back to it’s previous state. When this happens, sometimes it helps to click on the switch multiple times (it will still switch back to the opposite state) until Home Assistant “realizes” that the switch should actually be (on|off) and stay in that position.

While this would just be annoying because switching the devices will still work via Alexa, for example, it makes things like automations difficult. When the TV switch is toggled, things are supposed to happen (play auto, toggle lights, etc.), but this will not happen when the switch is stuck at the wrong position. I can still turn the switch via voice command, but the automations triggered by the switch will not be triggered.

I don’t understand the problem, as ALL my tasmota devices have the very same template I posted above. When I switched to Home Assistant I changed all my tasmota devices to the settings above (PowerRetain etc.), so if most switches work without any problem, this one (and the few others that have the same issue) should logically not behave any differently.

Has anybody else encountered this? Thanks for any ideas on how to fix this :slight_smile:

2

why does your anchor have <<: &name?

You aren’t placing the anchor in the anchor section, it should have a unique name associated with it. If you have other anchors in that section with << as the name, you will overwrite them with each new <<.

  mqtt_template: &template
    platform: mqtt
    payload_on: "ON"
    payload_off: "OFF"
    state_on: "ON"
    state_off: "OFF"
    qos: 2
    retain: false

- name: "Schlafzimmer TV"
  command_topic: "cmnd/tasmotatv/POWER"
  state_topic: "stat/tasmotatv/POWER"
  icon: mdi:television
  <<: *template

As for your issue, it seems like home assistant isn’t looking at the devices state topic. Verify that it looks correct for the device in question. Also, the device in question may not adjust the state topic quickly. Either way, you should be monitoring the state topic for the changes. Home assistant will only react when the device updates that state topic. If that’s not happening, then you need to debug the device itself and figure out why it behaves that way.

3

@petro sorry, I pasted this wrong or at least incompletely:

- name: "Schlafzimmer Lichterkette"
  # IP 192.168.100.33
  command_topic: "cmnd/11/POWER"
  state_topic: "stat/t11/POWER"
  icon: mdi:theme-light-dark  
  <<: &template
    platform: mqtt
    payload_on: "ON"
    payload_off: "OFF"
    state_on: "ON"
    state_off: "OFF"
    qos: 2
    retain: false

- name: "Schlafzimmer TV"
  # IP 192.168.100.89
  command_topic: "cmnd/22/POWER"
  state_topic: "stat/22/POWER"
  icon: mdi:television
  <<: *template

So in Schlafzimmer Lichterkette I define the template, and then each other entity will refer to that template and only substitue name, command_topic, state_topic, and icon.

I believe that I have already verified the state topic… please tell me if I did this wrong. I subscribed via command line to stat/22/POWER, then manually turned the switch to OFF via the webGUI. I would then see OFF in the terminal.

I could use a different state_topic (tele/22/STATE), then extract the value via value_json; however, tasmota only lets you set TelePeriod (which is the interval in which to send this status update) to every 10 seconds; the stat/22/POWER, however, is sent instantly when changing the value.

Could qos have anything to do with this? To my understanding, 1 means “send once and once only” and 2 means “send at least once”. So I always resort to 2 just in case 1 is not “efficient enough” (or something happens just the moment the message is sent and it is not received for some reason). However, this is all on the Home Assistant side. I’ll check if I can set qos for tasmota as well and set it to 2.