Switch does not update state on change (MQTT, HABPanel)

Hi everyone,

I’m quite new to OpenHAB2 and I am trying to start simple to get into this topic.
I already managed to gather weather info in items and display them in HABPanel.

Now I bought a Sonoff Power Switch and flashed tasmota firmware on it. I set up a mosquitto server on the Pi running OpenHAB and got it working. Using a MQTT client, I can see messages by the switch and also can send messages to it to toggle it.
Then I configured a item like this:

Switch LivingRoom_Light “Living Room Light” (LR,gLight)
{ mqtt=">[broker:cmnd/sonoff-A00EEA/POWER:command:*:default],
<[broker:stat/sonoff-A00EEA/POWER:state:default]" }

and a sitemap containing this item. I also created a switch using a switch widget on HABPanel for this item.
Now I have the following observations:

  • On Basic UI: I can switch the switch ON and OFF, no problem, both works fine. But when I press the button on the hardware switch itself, the status is not updated.
  • On HABPanel: When loading the page, the initial state is correct. I can click on it and the hardware switch toggles, but the switch state in HABPanel stays the same. In the log I can see, that it sends the same command every time, but without updating the state. After reloading the page, the state is correct again.

What am I missing? This seems to be a common problem, but I didn’t find any solution yet…

Thanks in advance!


Here is some log output, when repeatly clicking a switch in HABPanel:

2018-02-08 06:21:58.354 [ome.event.ItemCommandEvent] - Item 'LivingRoom_Light' received command ON
2018-02-08 06:21:58.473 [vent.ItemStateChangedEvent] - LivingRoom_Light changed from OFF to ON
2018-02-08 06:22:01.703 [ome.event.ItemCommandEvent] - Item 'LivingRoom_Light' received command ON
2018-02-08 06:22:02.345 [ome.event.ItemCommandEvent] - Item 'LivingRoom_Light' received command ON
2018-02-08 06:22:02.905 [ome.event.ItemCommandEvent] - Item 'LivingRoom_Light' received command ON
2018-02-08 06:22:03.564 [ome.event.ItemCommandEvent] - Item 'LivingRoom_Light' received command ON
2018-02-08 06:22:03.952 [ome.event.ItemCommandEvent] - Item 'LivingRoom_Light' received command ON

And clicking the same switch in BasicUI:

2018-02-08 06:23:39.295 [ome.event.ItemCommandEvent] - Item 'LivingRoom_Light' received command OFF
2018-02-08 06:23:39.383 [vent.ItemStateChangedEvent] - LivingRoom_Light changed from ON to OFF
2018-02-08 06:23:40.975 [ome.event.ItemCommandEvent] - Item 'LivingRoom_Light' received command ON
2018-02-08 06:23:41.078 [vent.ItemStateChangedEvent] - LivingRoom_Light changed from OFF to ON
2018-02-08 06:23:41.868 [ome.event.ItemCommandEvent] - Item 'LivingRoom_Light' received command OFF
2018-02-08 06:23:41.999 [vent.ItemStateChangedEvent] - LivingRoom_Light changed from ON to OFF
2018-02-08 06:23:42.614 [ome.event.ItemCommandEvent] - Item 'LivingRoom_Light' received command ON
2018-02-08 06:23:42.646 [vent.ItemStateChangedEvent] - LivingRoom_Light changed from OFF to ON
2018-02-08 06:23:43.269 [ome.event.ItemCommandEvent] - Item 'LivingRoom_Light' received command OFF
2018-02-08 06:23:43.296 [vent.ItemStateChangedEvent] - LivingRoom_Light changed from ON to OFF

And just clicking the hardware switch:

2018-02-08 06:24:27.869 [vent.ItemStateChangedEvent] - LivingRoom_Light changed from OFF to ON
2018-02-08 06:24:29.313 [vent.ItemStateChangedEvent] - LivingRoom_Light changed from ON to OFF
2018-02-08 06:24:30.503 [vent.ItemStateChangedEvent] - LivingRoom_Light changed from OFF to ON
2018-02-08 06:24:31.684 [vent.ItemStateChangedEvent] - LivingRoom_Light changed from ON to OFF
2018-02-08 06:24:32.664 [vent.ItemStateChangedEvent] - LivingRoom_Light changed from OFF to ON

It seems that the item is updated correctly in every case. But the displayed state in HABPanel and BasicUI does not update. Anyone any idea, why?

Do I have to configure the MQTT event bus in any way?
In my understanding this is the place to configure the topics OpenHAB should subscribe to, isn’t it?

I set mine up slightly differently but if you add a virtual switch you should be able to do what you want.

Real switch:

Switch sonoff3 "my lamp"  {mqtt=">[mosquitto:cmnd/sonoff3/power:command:ON:1],>[mosquitto:cmnd/sonoff3/power:command:OFF:0]"}

Virtual switch:

Switch virSonoff3  { mqtt="<[mosquitto:stat/sonoff3/power:state:default]"} 


rule "sonoff3 rule"

    Item virSonoff3 recieved update
   if (virSonoff3.state == ON) {
else {

I haven’t tested the above but something like that should do the job.

Yes, I have read that already, using a second (virtual) switch.
But it should be possible to do it without it, or not?

So in your example, the visible switch is “sonoff3”, triggering the command. And the other one is receiving the updates and sending commands to the real switch? This is just to prevent the rule from running into a loop when using only one switch, right?

In my example, if the 'real’switch is ON and you send a command to turn it ON (via the rule), nothing will happen except the HABpanel switch item getting updated to match the state of the real switch.

I suppose you could have a virtual switch on your HABpanel and use that to control the real switch instead.

As you say, there’s probably a more elegant way of doing it and I’m sure someone will come along and show you.

I seem to get most things working but I’m always amending stuff when I see a better solution here.

Hi Benny,

I had similar issues in the beginning, for some reason the status update is case-sensitive. Try to change you item like this:

Switch LivingRoom_Light “Living Room Light” (LR,gLight) { mqtt=">[broker:cmnd/sonoff-A00EEA/POWER:command:*:default], <[broker:stat/sonoff-A00EEA/power:state:default]" }

Doing it like this the switch status should be updated when the appropriate MQTT message is received.

Ok, I will try that as soon as I am at home.
Hopefully that works! :slight_smile:

I’m sorry, that does not work! :frowning:
When I use the lower case version, the state change does not appear in the log any longer.

HI Benny,

Sorry, I misunderstood what you were after so please ignore my last post!

Have you tried HABpanel in a different browser and/or with a different OS?

I tried a different Browser, yes. But the problem ist not specific for HABPanel, but also die Basic UI.

I have tested further…
I configured a simple switch now, with OUT and IN parameter:

Switch Sonoff_1 "Sonoff 1" <light> (LR, gSonoffs) { mqtt=">[mosquitto:cmnd/sonoff-basic-1/POWER:command:*:default], <[mosquitto:stat/sonoff-basic-1/POWER:state:default]", autoupdate="true" }

I also reinstalled the mosquitto server to be sure not to have wracked something.
Now I have the following messages when I subscribe:

cmnd/sonoff-basic-1/POWER ON
stat/sonoff-basic-1/RESULT {"POWER":"ON"}
stat/sonoff-basic-1/POWER ON

But the result is still the same. See my first post. :frowning:

And now comes the surprising part!
When I use the openhab app on my Android phone, the item is updated correctly! But in the Chrome browser on my phone, it is still the same as on my PC…


Another new hint probably… the items are updating correctly in the IE for the BasicUI, but also not for HABPanel.
So I guess, this problem has to do with propagation of events from the server to the browser. But I have currectly no idea, how to debug this. The javascript console is empty after loading the page.

Any idea?


I have now (July 2019) the same problem on BasicUI using Firefox and Chrome, both on Ubuntu and Android.

No solutions?

The original poster had a number of issues. It might be helpful if you could describe your problem a bit better than “same”?

I found this thread researching an issue, which is that I am able to control a switch (an EFUN Plug flashed to Tasmota) through a channel on a Generic MQTT broker item, but the state does not update.

I am running openhabian on a Pi 4, OpenHAB version 2.5.6, using the Mosquitto broker (also running on the Pi).

I set everything up using the Paper Interface. Here is the channel configuration:

I saw the solution above to create a virtual switch and update it. I will do that if necessary, but like to keep things as simple as possible.

I can see on the Tasmota console that the device receives the commands when I click on the control.

The only unusual thing in the mosqitto log is a socket error:

There is nothing exceptional in the openhab log

I have tried it with a Chrome Browser and with the OpenHAB iPhone App, with the same result: switch responds to commands but doesn’t update status if it is switched from the device Tasmota UI.

I’m relatively new to OpenHAB, so I could well have missed something. I have searched and read various community postings but haven’t found anything (besides this thread) that addresses this issue.

In stateTopic of your channel definition use:


You’re currently subscribed to a state which doesn’t exist!

Thanks for pointing me in the right direction. I guess I’m still learning about the way “topics” work. From the Tasmota console, I observed that it publishes a couple of MQTT messages when the power is toggled on or off, “tele/tasmota-efunplug1/STATE” and “state/tasmota-efunplug1/RESULT”. I tried both of them and set the message transformation to JSONPATH:$.POWER. And both of them worked! Since both are published when there is change (whether by a subscribed message from the MQTT broker from the MQTT Generic Thing Channel, or because the power was toggled in the Tasmota GUI, or because the button was pushed on the device), I’m not sure if it matters which one I use, though I am leaning towards the “tele/…” because the device updates that every couple of minutes (in addition to the instantaneous update when there is a change).

It took me a little while to get my head around too!

For the incoming messages from Tasmota - in other words, those that are intercepted by stateTopic - I would always use stat/tasmota-efunplug1/RESULT with the JSONPATH transform as you have it. This is because a RESULT message is sent by Tasmota every time it has received a command from anything, be that openHAB, an infra-red remote, or something else. By subscribing to the RESULT topic your openHAB item (and therefore your switch on the sitemap) will always be up-to-date!

(For clarity - the stateTopic is always listening, not just when you’re sending a command from that same channel).

If you subscribe to the tele/tasmota-efunplug1/STATE topic then your item and switch will eventually update in openHAB, but there will be delay (of up to 5 minutes, I think).

Lastly, if you subscribe to a stat/tasmota-efunplug1/POWER topic then you don’t need the JSONPATH transform at all, because your stateTopic receives a simple string ON or OFF. You just need to set the Custom On and Custom Off values as you have shown in your screenshot to ON and OFF

To be clear, when you command a Tasmota device to switch on or off, you will get the following messages immediately:

  • stat/tasmota-efunplug1/RESULT
  • stat/tasmota-efunplug1/POWER

and the below message within 5 minutes:

  • tele/tasmota-efunplug1/STATE

All of the above assumes you haven’t fiddled at all with the various setOptions that Tasmota has. If so, then you can probably ignore everything I’ve written!

And lastly - be careful with state and stat! It’s stateTopic, stat/tasmota-efunplug1/... and tele/tasmota-efunplug1/STATE !

Thanks for all of your insightful comments.

As I have continued to experiment, I have encountered some strange behavior.

If I put “cmnd/tasmota-mooseroom-plug/POWER” in the MQTT Command section of Paper UI Configure Channel screen for the Generic MQTT thing, with no transform and no custom values, the item attached to that channel operates perfectly as a switch.

Likewise, if I put “stat/tasmota-mooseroom-plug/POWER” in the MQTT State Topic of the Configure Channel, (with no transform and no custom values) the attached switch item behaves perfectly - it changes state appropriately where the change is triggered by MQTT from OpenHAB, from the device GUI, or by a press of the button.

However, if I combine the above and put both of them in the same channel configuration, the state part still works, but the command does not. The device receives an empty payload, which it interprets as a power status request, to which it responds with the unchanged status, which causes the status to change immediately back to what it was before the item switch was pressed.

Searching for information I found the proxy switch solution, which I have implemented and it seems to work well. But it is extra coding for each device.

Any thoughts as to why the state and command topics work great separately but when combined on the Configure Channel, the state works and the command misfires?