OH5.1: MQTT-integration of Tasmota plugs changed?

binderth · December 30, 2025, 3:09pm

since the upgrade from OH5.0 to OH5.1 in my docker instance, the MQTT-integration of Tasmota-plugs does not work and ends up in a endless loop?

I’m using Tasmota 15.1.0 with some power-plugs (Nous A1):

as you can see, Tasmota sends the stats every 15 seconds. If I don’t stop the MQTT-Thing for that plug you can see the loop already in the Tasmota-console:

15:54:42.510 MQT: devices/NousWaMa/tele/STATE = {"Time":"2025-12-30T15:54:42","Uptime":"79T06:06:42","UptimeSec":6847602,"Heap":25,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":19,"MqttCount":95,"POWER":"ON","Wifi":{"AP":1,"SSId":"PL.12","BSSId":"0C:72:74:91:5E:9C","Channel":11,"Mode":"11n","RSSI":70,"Signal":-65,"LinkCount":61,"Downtime":"0T00:05:18"},"Hostname":"NousWaMa-1753","IPAddress":"192.168.78.93"}
15:54:42.520 MQT: devices/NousWaMa/tele/SENSOR = {"Time":"2025-12-30T15:54:42","ENERGY":{"TotalStartTime":"2021-10-20T16:02:41","Total":840.172,"Yesterday":0.036,"Today":0.023,"Period":0,"Power":1,"ApparentPower":10,"ReactivePower":10,"Factor":0.13,"Voltage":230,"Current":0.045}}
15:54:57.513 MQT: devices/NousWaMa/tele/STATE = {"Time":"2025-12-30T15:54:57","Uptime":"79T06:06:57","UptimeSec":6847617,"Heap":25,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":19,"MqttCount":95,"POWER":"ON","Wifi":{"AP":1,"SSId":"PL.12","BSSId":"0C:72:74:91:5E:9C","Channel":11,"Mode":"11n","RSSI":70,"Signal":-65,"LinkCount":61,"Downtime":"0T00:05:18"},"Hostname":"NousWaMa-1753","IPAddress":"192.168.78.93"}
15:54:57.522 MQT: devices/NousWaMa/tele/SENSOR = {"Time":"2025-12-30T15:54:57","ENERGY":{"TotalStartTime":"2021-10-20T16:02:41","Total":840.172,"Yesterday":0.036,"Today":0.023,"Period":0,"Power":1,"ApparentPower":10,"ReactivePower":10,"Factor":0.11,"Voltage":232,"Current":0.045}}

15:55:05.324 CMD: Power=ON
15:55:05.329 MQT: devices/NousWaMa/stat/RESULT = {"POWER":"ON"}
15:55:05.333 MQT: devices/NousWaMa/stat/POWER = ON
15:55:06.067 MQT: devices/NousWaMa/stat/RESULT = {"POWER":"ON"}
15:55:06.069 MQT: devices/NousWaMa/stat/POWER = ON
15:55:06.119 MQT: devices/NousWaMa/stat/RESULT = {"POWER":"ON"}
15:55:06.122 MQT: devices/NousWaMa/stat/POWER = ON
15:55:06.168 MQT: devices/NousWaMa/stat/RESULT = {"POWER":"ON"}
15:55:06.172 MQT: devices/NousWaMa/stat/POWER = ON
15:55:06.218 MQT: devices/NousWaMa/stat/RESULT = {"POWER":"ON"}
15:55:06.221 MQT: devices/NousWaMa/stat/POWER = ON
15:55:06.268 MQT: devices/NousWaMa/stat/RESULT = {"POWER":"ON"}
15:55:06.272 MQT: devices/NousWaMa/stat/POWER = ON
15:55:06.319 MQT: devices/NousWaMa/stat/RESULT = {"POWER":"ON"}
15:55:06.323 MQT: devices/NousWaMa/stat/POWER = ON
15:55:06.371 MQT: devices/NousWaMa/stat/RESULT = {"POWER":"ON"}
15:55:06.375 MQT: devices/NousWaMa/stat/POWER = ON
15:55:06.419 MQT: devices/NousWaMa/stat/RESULT = {"POWER":"ON"}

same in the openHAB-logs:

2025-12-30 16:00:40.682 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'EMS_CmdWaMaPowered' received command ON (source: org.openhab.core.thing$mqtt:topic:synology:waschmaschine:state)
2025-12-30 16:00:40.684 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'EMS_WaMaPowered' received command ON (source: org.openhab.core.thing$mqtt:topic:synology:waschmaschine:state)
2025-12-30 16:00:40.684 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'WM_State' received command ON (source: org.openhab.core.thing$mqtt:topic:synology:waschmaschine:state)
2025-12-30 16:00:40.684 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'EMS_CmdWaMaPowered' predicted to become ON
2025-12-30 16:00:40.684 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'EMS_WaMaPowered' predicted to become ON
2025-12-30 16:00:40.684 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'WM_State' predicted to become ON
2025-12-30 16:00:40.735 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'EMS_CmdWaMaPowered' received command ON (source: org.openhab.core.thing$mqtt:topic:synology:waschmaschine:state)
2025-12-30 16:00:40.737 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'EMS_WaMaPowered' received command ON (source: org.openhab.core.thing$mqtt:topic:synology:waschmaschine:state)
2025-12-30 16:00:40.738 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'WM_State' received command ON (source: org.openhab.core.thing$mqtt:topic:synology:waschmaschine:state)
2025-12-30 16:00:40.739 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'EMS_CmdWaMaPowered' predicted to become ON
2025-12-30 16:00:40.740 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'EMS_WaMaPowered' predicted to become ON
2025-12-30 16:00:40.741 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'WM_State' predicted to become ON
2025-12-30 16:00:40.770 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'STRAT_VoltagePhase1' changed from 231.4 V to 228.3 V (source: org.openhab.core.thing$mqtt:topic:synology:stromAtelier:voltagePhase1)
2025-12-30 16:00:40.823 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'EMS_CmdWaMaPowered' received command ON (source: org.openhab.core.thing$mqtt:topic:synology:waschmaschine:state)
2025-12-30 16:00:40.824 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'EMS_WaMaPowered' received command ON (source: org.openhab.core.thing$mqtt:topic:synology:waschmaschine:state)
2025-12-30 16:00:40.826 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'WM_State' received command ON (source: org.openhab.core.thing$mqtt:topic:synology:waschmaschine:state)
2025-12-30 16:00:40.827 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'EMS_CmdWaMaPowered' predicted to become ON
2025-12-30 16:00:40.835 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'EMS_WaMaPowered' predicted to become ON
2025-12-30 16:00:40.836 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'WM_State' predicted to become ON
2025-12-30 16:00:40.852 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'EMS_CmdWaMaPowered' received command ON (source: org.openhab.core.thing$mqtt:topic:synology:waschmaschine:state)
2025-12-30 16:00:40.854 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'EMS_WaMaPowered' received command ON (source: org.openhab.core.thing$mqtt:topic:synology:waschmaschine:state)
2025-12-30 16:00:40.855 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'WM_State' received command ON (source: org.openhab.core.thing$mqtt:topic:synology:waschmaschine:state)

So, what causes this endless loop? I didn’t change anything in the config of the Tasmota plug:

version: 1
things:
  mqtt:topic:synology:waschmaschine:
    bridge: mqtt:broker:synology
    label: MQTT Tasmota Waschmaschine
    config:
      availabilityTopic: devices/NousWaMa/tele/LWT
      payloadAvailable: Online
      payloadNotAvailable: Offline
    channels:
      state:
        type: switch
        label: State
        description: Status Waschmaschine
        config:
          stateTopic: devices/NousWaMa/stat/POWER
          commandTopic: devices/NousWaMa/cmnd/POWER
          postCommand: true
          "on": "ON"
          "off": "OFF"
      Power:
        type: string
        label: Power
        description: Verbrauch Waschmaschine
        config:
          stateTopic: devices/NousWaMa/tele/SENSOR
          transformationPattern:
            - JSONPATH:$.ENERGY.Power
      EnergyToday:
        type: string
        label: EnergyToday
        description: Verbrauch heute Waschmaschine
        config:
          stateTopic: devices/NousWaMa/tele/SENSOR
          transformationPattern:
            - JSONPATH:$.ENERGY.Today
      EnergyTotal:
        type: string
        label: EnergyTotal
        description: Verbrauch gesamt Waschmaschine
        config:
          stateTopic: devices/NousWaMa/tele/SENSOR
          transformationPattern:
            - JSONPATH:$.ENERGY.Total
      StarteWaschmaschine:
        type: switch
        label: Starte Waschmaschine
        config:
          stateTopic: devices/NousWaMa/tele/state/starteWaschmaschine
          commandTopic: devices/NousWaMa/cmd/starteWaschmaschine
      Betriebsart:
        type: string
        label: Betriebsart
        description: Betriebsart Waschmaschine
        config:
          stateTopic: devices/NousWaMa/betriebsart

all three items from the log is “standard”-linked to the power-channel
none of the “power”-items have any Metadata or a rule attached to them, which would cause this loop?

How is it started anyways? and what did I do wrong?

Tschetan · December 30, 2025, 3:27pm

Hi,
take out postCommand or set it to false

rlkoshak · December 30, 2025, 3:39pm

I suspect @Tschetan has the answer, but I want to provide some details.

When an Item is sent a command the command goes out to the binding and out to the device (in this case MQTT topic). With postCommand set to true, that caused the MQTT binding to treat incoming messages (which are normally used to update an Item) as commands. So the binding commands the Item, the Item received a command so the binding picks up the command and, if configured posts the message on the commandTopic. And there is your loop.

Device changes/ updates -> Message posted to stat topic -> OH receives message -> OH commands Item OH received command -> OH publishes command to cmd topic -|
   ^                                                                                                                                                         |
   |_________________________________________________________________________________________________________________________________________________________|

To break the loop and avoid such loops in the future, any Channel that has both a stateTopic and a commandTopic should never have postCommand set to true unless you are certain that such a loop is not possible. And even if there is only a stateTopic you rarely want to use postCommand.

I can’t say why this wasn’t a problem before because as far as I know nothing has changed here. That configuration should have always generated a loop like this.

binderth · December 30, 2025, 4:11pm

ok, with postCommand = false it works.

But I don’t understand. As I set my Tasmotas up, I did think, without that postCommand = true openHAB won’t send out changed states to the commandTopic devices/NousWaMa/cmnd/POWER, if one linked item changed.
So, if the change comes from the stateTopic devices/NousWaMa/stat/POWER to openHAB, why does it send out the MQTT-received change on the commandTopic? This behaviour must have been changed with 5.1? does this even make sense?

rlkoshak · December 30, 2025, 4:53pm

The description in the UI for this field states:

If the received MQTT value should not only update the state of linked items, but command them, enable this option.

That matches my understanding of what this property has always done. Looking at the 4.3 docs and the 3.4 docs indicates that it’s not changed behavior.

postCommand: If true, the received MQTT value will not only update the state of linked items, but command it. The default is false. You usually need this to be true if your item is also linked to another channel, say a KNX actor, and you want a received MQTT payload to command that KNX actor.

postCommand has always been about how to handle incoming messages. When false incoming messages result in an update to the Item. When true incoming messages result in a command to the Item.

There is no property on the MQTT Thing that can handle treating an update to an Item as a command. Updates to Items never make it to the binding in the first place. That’s actually a rule enforced by OH core. The MQTT binding never sees the updates. It only sees commands. That’s kind of the whole point in having commands and updates as separate events and it’s why we need things like the follow profile.

Note, IIRC way back in OH 1 the MQTT 1.x binding did have a way to use updates as commands and publish when an Item updates. But we were not dealing with Things way back then and bindings had a lot more access to Items and events than is allowed since OH 2.0.

See my post above.

When postCommand is true, the MQTT binding always sends a command to the Item instead of an update.

All commands to an Item are sent to the Things they are linked to. That’s always the case for all bindings.

All commands to an Item linked to an MQTT Channel will cause a message to be published on the commandTopic.

And now we are in a loop.

Based on my experience and the archived docs this behavior has not changed. We can look at the history of the code changes in github, but I think the docs should be sufficient to show it’s not changed.

binderth · December 31, 2025, 2:06pm

that is, what troubled me - the loop shouldn’t be there, because the command came from the MQTT-payload - why should the MQTT channel send that same command back in this case? My guess would be, that behaviour changed sometime between 5.0.x and 5.1, perhaps some side effect of the newly introduced “source”-feature?

rlkoshak · December 31, 2025, 5:19pm

Until 5.1 the binding would have no way of knowing where the command came from. At best it could have guessed based on timing but that works be brittle at best. But even now I don’t know if the binding sees the new evenSource property or not.

As far as I know and based on the docs and my own experience nothing has changed. Someone with a bit of time can go look at the binding history to see if something charged.

But the current behavior matches the docs going back to at least OH 3.4. If there was a change, it was to bring the behavior in line with how it’s documented to work. If this didn’t cause a loop in the past, that was the incorrect behavior.

But now that the eventSource is there, it might be worth filling an issue on the binding to stop the loop of the command’s eventSource days it can from the binding.

I’m not sure what use case this works solve though that the follow profile doesn’t. But at least it won’t cause an infinite loop.

pmknowles · January 18, 2026, 6:37pm

I have experienced exactly the same after upgrading from OH5.0 to 5.1. Until a device state is changed (whether from OH or the Tasmota UI) the output is stable but, as soon as the output is changed, the output constantly cycles on and off. I have one device which has survived transition from OH2 all the way to OH5.1 without any issue so something must have changed in the MQTT binding between 5.0 and 5.1.

sihui · January 18, 2026, 7:22pm

pmknowles · January 19, 2026, 8:39am

That doesn’t explain the ‘cycling’ though. If I turn the device on via Tasmota MQTT will send an ON status to OH. If what you’re saying is correct OH would update the status and send ON. It doesn’t it sends OFF. Tasmota updates the status to OFF then OH sends ON again.

By the way, it only seems to affect Tasmota devices. Shelly and ZigBee2MQTT devices are not affected whether isCommand is selected or not. Perhaps it’s a ‘race’ between OH and Tasmota?

sihui · January 19, 2026, 4:22pm

If you have a state topic and a command topic for this channel and don’t have postCommand=true set, yes, then you have a different problem…

pmknowles · January 19, 2026, 7:03pm

Since OH2 I have had isCommand (in the UI) or postCommand (in Code) set to true without any issue until OH5.1. The devices remain stable until either OH or the device starts a state change at that point OH appears to try to reverse the state change it sees so when it sees the output turn ON it sends OFF. The device goes OFF and OH sees it change and responds with ON. This happens so quickly that the relay ‘buzzes’ and the device becomes unresponsive. The only way to stop it is to power off and disable MQTT on restart. I have removed isCommand from the Tasmota devices and everything operates correctly.

As I understood it, the statement If the received MQTT value should not only update the state of linked items, but command them, enable this option. meant that, if a device changed state remotely, isCommand needed to be set to true to ensure that everything stayed in sync.

rlkoshak · January 19, 2026, 7:33pm

That is not a correct understanding of that the parameter is for.

When a state changes, OH uses an update to cause the Item’s state to change. An update does that and only that. It changes the state of the Item so it remains in sync with the device.

A command is used to ask a device to do something. The light is currently OFF. To turn the light ON issue a command. Commands flow from the Item to the binding and back out to the device.

When postCommand is true, the MQTT binding doesn’t update the linked to Item. It commands it. And if there is a commandTopic configured, you can end up in a loop as the updates come in and go back out as commands.

If this configuration has ever worked in the past without these loops, that was a bug which apparently got fixed. The current behavior is the correct behavior. And message that comes in commands the Item. If there is also a commandTopic, that message gets retransmitted on the commandTopic because that is what it means to command an Item.

The only time postCommand should be true is in the rare cases where:

there is no commandTopic
using an event channnel is not possible

pmknowles · January 20, 2026, 9:31am

Rik, you have saved my bacon several times in the past so I respect your opinions. In this case, the ‘bug’ was there for many, many years but the current situation is that OH isn’t commanding the same as the incoming state message but the previous state.

OH commanding

OH sends ON to the device

Device responds with I’m ON

OH then sends OFF

Device responds with I’m OFF

OH sends ON ad infinitum

Device changes state remotely

Device says I’m ON

OH commands OFF

Device says I’m OFF

OH commands ON ad infinitum

OH is responding with a command opposite to the state it has just received (it should be repeating the state it received)

This only occurs with Tasmota devices (not Shelly or ZigBee2MQTT) so perhaps it isn’t interpreting the state correctly.

rlkoshak · January 20, 2026, 2:24pm

Doesn’t tasmota treat any command as a toggle? It’s been many years since I’ve messed with tasmota but I think that used to be the case anyway. Or at least it was configurable to do that.

If you set openhab.event.ItemStateEvent and openhab.event.ItemStateUpdatedEvent to INFO than you’ll see all the updates made to this Item and in OH 5.1 you’ll see where the update came from. Compared to the tasmota logs should make it clear where the loop is coming from.

woklei · February 2, 2026, 8:35am

I can also confirm that in OH3, there was no loop when you commanded the switch but now, after upgrading to 5.1.1. there is.

Switching the commanding off solved the issue.

Not discussing which setting is correct, but something definitely has changed.

pmknowles · February 2, 2026, 4:02pm

No, it accepts 1 or ON and 0 or OFF and 2 or TOGGLE. In the Tasmota log the commands are coming from OH and in the OH log it shows the ON but not the OFF

2026-01-18 07:57:27.708 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'CookerHoodLight' received command ON (source: org.openhab.core.thing$mqtt:topic:MQTTv2:CookerHood:Light)
2026-01-18 07:57:27.711 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'CookerHoodLight' predicted to become ON
2026-01-18 07:57:27.807 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'CookerHoodLight' received command ON (source: org.openhab.core.thing$mqtt:topic:MQTTv2:CookerHood:Light)
2026-01-18 07:57:27.809 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'CookerHoodLight' predicted to become ON
2026-01-18 07:57:27.908 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'CookerHoodLight' received command ON (source: org.openhab.core.thing$mqtt:topic:MQTTv2:CookerHood:Light)
2026-01-18 07:57:27.909 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'CookerHoodLight' predicted to become ON

It’s resolved in that I’ve now removed the offending isCommand