Tasmota status issue... I think?

OpenHAB 2.5.3 Release. running on XUbuntu installed on a 64 bit lappy
Installation via project clone, by the book. + Zulu 8
System MQTT, doing what it should.
Using Node Red to monitor/diagnose payload and check topic’s

Tasmota on sonoff basic, just the one for testing.
Binding, Thing & link added with Paper UI. Switch works.
Icon added to HabPanel… Again working, apparently. No site map.


After initial config the switch state wasn’t being returned.
IE. if the unit was switched externally, Tas interface / button / power on default, Openhab didn’t see the new state.

In addition I wanted to capture the MQTT log to ensure that after a system restart, either end, Openhab displayed the correct device state.

Whilst trying to get the log capture to work, not correctly as it happens, I set, and then removed, a custom On and Off state in the thing definition.
Following this the switch no longer functioned, sending an empty payload.
This however caused the state to respond as it should… CONFUSED I was!

I Added ON and OFF, as custom values, which fixed the switch and also fixed, or at least didn’t break, the status update.
Tested this by injecting stat/…/POWER messages from node red and found I could switch the Openhab state, and icon/text, without switching the device. Pointless but amusing none the less.

Have I found a bug? Or am I just a super-noob missing something obvious?
After replacing the default, empty, cmnd/state entries with ‘ON’ and ‘OFF’, which seems to be documented as the default anyway, status worked.
Removing the custom entry doesn’t seem to reinstate the default condition, breaking the switch because it then sends an empty payload.

I am now planning to use Node Red to split stat/…/LOGGING, which spits out a verbose comma separated payload, to identify periodic device state reports and then generate a, I was going to say ‘sudo’ but that would be confusing, new MQTT message with an apropriate stat/…/POWER topic to update Openhab, if it, or the device, has restarted.

I am sure I can get this to work but I have no idea if there is an easier/better way to go about.
Any advice, would be much appreciated.

I have searched, extensively, but to be honest a lack of knowledge is making a targeted search hard; and the relatively recent updates make many of the results I have got all but useless.

Sorry… Very new to this, Ubuntu and Openhab, and struggling to say the least.
It looks cool though, cant wait to get some sensible basic functionality in place and then play with it.

Can anyone recommend a Cheap android tab, 7", that will adequately run HabPanel…
I will need at least 4 so I would prefer not to go for high end stuff unless it is absolutely necessary.

I build PLC code for a living and plan to use the Modbus, or possibly a raw TCP, connector to hook up a couple of Schneider PLC’s and a Victron inverter system.
I would be more than happy to share that code/config, and anything else I come up with, if it will help anyone.
Where would I do that? I don’t want to spam the main forums… That’s just rude!

Long first post I know, sorry.
Looking forward to engaging with the community.


1 Like

Welcome to the Community!

I do not use HabPanel but for the sake of troubleshooting I recommend adding a sitemap and see if you get the same results.

Adding the Thing via PaperUI is the recommended way but most use files for the items. Try adding your items to files by coping the channel info from PaperUI. Before saving the file delete the channels so they will be recreated when the file is saved.

Item file example:

Switch CouchLight "Couch Light" <light>  ["Lighting"]  { channel="mqtt:topic:pibroker:sonoff2:power" }

This will be about setting up your MQTT broker to handle retained messages, and seeing that publishers use the retain tag.

Worry about that after you’ve got basic publishing/updating cycle working. About which we can say little, without further (focused) detail. Maybe a dedicated thread for that. Do not be frightened to make new threads targeted on a specific problem, likely to have a better outcome for you (and for later readers) than a long tour of issues.

1 Like

Welcome to the OpenHAB community, great first post!

HI Folks,
I am slightly relieved that there were not 10 of you telling me how silly I was being.

Site map
es I did try that but calling one thing a map seemed like overstating somewhat especially asz it was an auto generated map.
The behavior was exactly the same… Switch the switch push the button in Openhab and all is well, icon and text update you you would expect.
Change the state of the device outside Openhab and nothing happens, at least not inside Openhab.

There is an MQTT message with the new state in it on the subscribed topic with a payload of ‘OFF’ or ‘ON’ but no response to it.
Of course that was before I added the 'custom ‘on/open value’ & ‘custom off/closed value’
it is working now.

Where are these files?
sorry new just as to Lynux too. I think it is entirly likely that Paper UI is simply not putting the correct value/s in the things file, assuming that is a thing… is it?
I can handle file editing and although MQTT is hardly one of my core skills. :slight_smile: I think I have the basics down now.

To be fair if I can add things and links, I think that is the correct terminology, from a file I would prefer to do that. I usually use spreadsheets extensively to generate PLC code and occasionally code for various scripts. It just makes sense what you have many similar items that need to be constructed and all that changes is IO mapping or names.
I don’t expect anyone to tell me how to build a spreadsheet that will make things file entries but I am confident that once I understand the syntax I will be able to do that.

retained messages…
Yes OK, I am happy to concede that this would help, potentially, but it is only caching the same message that Openhab isn’t, OK Wasn’t processing, and worse will not ride through a server restart, as far as I can tell… Happy to be proven wrong here.

The key point is that if the MQTT broker is down when the state changes, after a power cut for example, and or the retention settings are wrong the physical state and indicated state could get out od sync.

Additionally the payload of the MQTT logging message is huge and nothing like the ‘ON’ or ‘OFF’ that Openhab responds to.

I have played with retained messages and QOS settings and I appreciate that they will help but unless Openhab can be made to parse a long string and exreact the POWER item…

payload: “16:38:43 MQT: tele/TYCG_073/STATE = {“Time”:“2020-04-05T16:38:43”,“Uptime”:“0T06:55:20”,“UptimeSec”:24920,“Heap”:27,“SleepMode”:“Dynamic”,“Sleep”:50,“LoadAvg”:19,“MqttCount”:1,“POWER”:“OFF”,“Wifi”:{“AP”:1,“SSId”:“Ty-Cerrig”,“BSSId”:“74:DA:38:F0:BC:DC”,“Channel”:4,“RSSI”:100,“Signal”:-41,“LinkCount”:1,“Downtime”:“0T00:00:06”}}”

I don’t see a way round the issue without Node Red or the Tasmota sending something else.
The above is copped directly from debug in Node Red.
It seems to be a fully formatted MQTT message but sent as payload in another message, go figure!

If I font process this periodic report then I would need to periodically issues a cmnd/…/POWER with no payload, effectively querying the device, and eliciting a response on the topic stat/…/POWER which Openhab is now correctly responding to.

My node red script is almost correct now…

Tasmota MQTT Logging handler...
detects state from verbose payload and generates
a new message, with the same node ID, having either
ON or OFF as a payload.
MQTT in and out - Openhab handling stst report as normal.
var strPayLoad = msg.payload;
if (msg.topic.includes("/LOGGING"))
  var newMsg ="";  
  var intIdPos = strPayLoad.search("TYCG_");
  var strTopic = strPayLoad.slice(intIdPos, intIdPos+8);
  strTopic = "stat/"+strTopic+"/POWER";
  if (strPayLoad.includes("POWER\":\"OFF"))
      newMsg = { payload:"OFF",topic:strTopic };
  else if (strPayLoad.includes("POWER\":\"ON"))
      newMsg = { payload:"ON",topic:strTopic };
  return newMsg;

This seems to work.
I am struggling with MQTT wildcards though
I need to subscribe to…
stat/+/LOGGING is working but still captures stat/+/POWER, which I would prefer it didnt.
can someone tell me how to do that, looked but cant find it.
stat/#/LOGGING dose not work.


You’re wrong. A properly configured broker will preserve retained messages through its own restarts. When anything subscribes to a retained topic, whether that something has just done its own restart or whatever, it gets the retained message.
All you need to do is see that the device publishe messages with “retain” set.

Don’t look at it as a long string, it’s JSON. There must be a hundred threads about parsing values from JSON in MQTT

I migth be stupid, but why don’t you post exactly WHAT you have configured ( like the things and items files or even screenshots from PaperUI) and tell what is not working with thiose settings? Telling that you have configured something " by the book" won’t help. Most of us have been there at some point as well!

1 Like

I get that, although I didn’t appreciate it would persist through a restart and appreciate the heads up.

The issue is the payload, posted earlier, or perhaps more accurately my not understanding how to handle it.

When the device responds normally the topic is stat/mydeviceid/POWER with a payload of ON or OFF
simple enough and works with the switch channel configured in Paper UI

If the device is physically manipulated, with its switch, or power cycled this message is never sent so Openhab cant process it.

I think I see what you are getting at RE

and I will alter the device config now.
Honestly I don’t understand how it will help, if the issue is no message in the first place or a message that Openhab isn’t responding to, but then I don’t understand a great deal right now so if nothing else I will learn something.

OK Screenshots I could probably do that, I just didn’t think it would add much
(Also I haven’t worked out how to do that on this system yet)
There are no files, I looked couldn’t find them and then found documentation saying paperUI spores everything in Jason and not to muck about with it, so I didn’t.

I have One thing, at least 1 in play… There are other bindings and of course the broker but am not using anything else, yet, and the broker is working.

I am assuming a QOS of 1 or 2 and retained set TRUE will help, at the expense of network traffic, which will not be a problem anyway?

The rest…!

You can see the ON and OFF I added in the switch, everything else is point and click at the defaults, bar for names.

Those hundreds of posts about parsing Jason…
Honestly I would need to know…
what I wanted, and what Jason was (some form of Java scripting I assume, reading to do)
how it was going to work,
If there was a more direct way to go, you know like adding a switch
O and what in those posts is entirely wrong now the system has changed.

I get that I need to learn and in fact I want to.
I also didn’t want to start with complex stuff, walk first and all that, but if a simple switch, added through the recommended UI, is not performing and the documentation specifically tells noobs not to fiddle with files, asking questions seems reasonable.
Most of what was confusing me was apparently legacy stuff, obvious now I know but not yesterday.

Ideally I would want to generate config files to add things/channels/links/ but everything I have read thus far tells me not to go there. I think I said that earlier.
I had hoped to add 1 thing, look at its valid config and use that to make more but apparently that isn’t an option anymore.

My switch is working and my script is capturing the reports, although I may not need it now.
Will reconfogure MQTT, reconfigure the device and add a few more devices.

I don’t want to irritate anyone, I just don’t understand why such a basic config, barely a test setup, could, be or would, be buggy… I therefore assumed it was my error.


Retained messages won’t help with that at all.
Refer to my first post.

Completely irrelevant for listening for incoming messages, which is where you seem to be having problems at the moment? (These are properties of messages that openHAB will publish)

Let’s go back a step , keep it simple.
What does your device publish?
When does it publish it?
Do you need to change what it publishes when, e.g.if a local switch is operated?

When that’s established, you can think about getting openHAB to listen out for it. No point fiddling with that end otherwise.

1 Like

@Dyslexicbloke i believe you are missing a retained configuration as well as some other settings in tasmota.

This is if i am understanding what you are trying to achieve.

What @rossko57 suggest is your needed course of action. You need to make sure tasmota publishes as required prior to debugging openhab.

A correctly configured tasmota device does send a stat message when the device is switched manually.
Your openhab setup looks my working one!
Simply check on the console of the tasmota device when switching it manually, you should see the message there!

05/04/2020, 21:15:07[node: 1cba4cdd.d83513](http://localhost:1880/#)stat/TYCG_073/RESULT : msg.payload : string[14]


05/04/2020, 21:15:07[node: 1cba4cdd.d83513](http://localhost:1880/#)stat/TYCG_073/LOGGING : msg.payload : string[51]

"21:15:07 MQT: stat/TYCG_073/RESULT = {"POWER":"ON"}"

05/04/2020, 21:15:07[node: 1cba4cdd.d83513](http://localhost:1880/#)stat/TYCG_073/POWER : msg.payload : string[2]


05/04/2020, 21:15:08[node: 1cba4cdd.d83513](http://localhost:1880/#)stat/TYCG_073/LOGGING : msg.payload : string[38]

"21:15:07 MQT: stat/TYCG_073/POWER = ON"

This is one activation… Payload only captured in Node Red.
Replacing ON with OFF gives you the other state.
Turning off logging on the client dose just that. so you get two less messages.

Both result and power are reported when the device starts or is toggled some other way…
All well and good and the Openhab status is responding.

If the device is down, powered off, toggling the switch in Openhab still sets the state despite not getting any feedback from an actual device!

Periodic reports are verbose…

Okay, most people aren’t the least bit interested in logging to openHAB.

Okay, so there are no problems at openHAB.

That’s openHAB’s autoupdate feature at work. Explanation here.

If you don’t like it, disable it. It’s a per-Item setting.

1 Like
05/04/2020, 21:27:59[node: 1cba4cdd.d83513](http://localhost:1880/#)stat/TYCG_073/LOGGING : msg.payload : string[324]

"21:27:58 MQT: tele/TYCG_073/STATE = {"Time":"2020-04-05T21:27:58","Uptime":"0T00:05:42","UptimeSec":342,"Heap":26,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":19,"MqttCount":1,"POWER":"ON","Wifi":{"AP":1,"SSId":"Ty-Cerrig","BSSId":"74:DA:38:F0:BC:DC","Channel":4,"RSSI":100,"Signal":-36,"LinkCount":1,"Downtime":"0T00:00:06"}}"

Note this all payload, I haven’t fiddled with it at all.

I am setting persistence and QOS now but apart from the configuration bug/issue, the question is why Openhab is reporting a device state when it hasn’t had a message setting that state

What am I missing? something in Habpanel perhaps?
Do I need a separate link to toggle the state or disable the switch when the device is offline?

I have set persistent for the thing as well as QOS to 1

If the device is powered off and the switch is turned on in Openhab the the device responds when it is reconnected.

Sorry ti be a pain, its a steep learning curve with literally everything, including the OS being new to me.


Yes, that’s logging that it sent a tele/ message. Did you need to do something with that?
Did you mean to subscribe to the tele topic (not the logging topic) and do something with that instead?

Under what circumstances?

The “retain” process is all about assuming the remote device still has the same state that it last reported.
No want, no set retain at the remote device.

openHABs autoupdate process is all about guessing the likely outcome of an openHAB command from UI or rule, and setting that state in anticipation that state in your Item.
No want, disable autoupdate of that Item.

If you are having some other mystery state change, please spell it out.

Once an Item state is set, it is set. Something else has to happen to change it.
If you want your Item to “do something” in response to your remote device exploding, please say so. There are various techniques to do something along those lines.
Frequently MQTT “lwt” feature can be used.

Yes, that is what we’d expect if you publish messages from openHAB with “retain” set. The broker remembers it. When something subscribes to that topic, it gets the remembered message.

The two ends of an MQTT conversation can set their “retain” flas independently.
If you don’t want openHAB commands to be remembered, don’t set retain at openHAB end.

Command Poll Period
seems to be a mesh network thing, I cant find any reference to it anywhere else.

The logic makes sense, set the switch state if the device isn’t there or hasn’t responded promptly but looking at the documentation, and PaperUI I cant find anything that looks like it performs that function.

autoupdate is controlled per Item.

Look at your Item in PaperUI, if and only if you defined your Item using PaperUI.

Otherwise you set in in the xxx.items file where you define the Item. It appears in the { } part where you define binding links.
It’s documented in the Items docs

You’ve not clarified exactly what you find to be a problem, so I’ve no idea if it will meet your needs.

Thanks folks…
Auto update wasn’t set but I have now explicitly set it to ‘Veto an auto update’

And the behavior is still the same…
I am not sure how else to say it

1.The physical device is disconnected.
2.The Generic MQTT Thing is still online. presumably because it is only talking to MQTT
3. Operating a switch on the panel still toggles the state.

I want…
The lack of a confirmation message to either reset the last switch action or mark the switch offline.
I have no issue with the system assuming the sate change, to avoid latency, and then correcting that a few seconds later but simply reporting the position of the switch seems, well, silly given that the device will return a state if it was able to receive the command in the first place.

I can see that LWT is the availability topic, which makes sense now I understand what you were talking about.
So “Last Will and Testament”… Generated by the broker yes?

06/04/2020, 00:26:38[node: 1cba4cdd.d83513]( :   msg.payload : string[7]

06/04/2020, 00:27:17[node: 1cba4cdd.d83513](
tele/TYCG_073/LWT : msg.payload : string[6]

And I guess that would be it…

I get the concept of a map file, but don’t know where to put it.
Is the items file still in use or is it depreciated like the things file.

Perhaps more importantly, should I be using files as opposed to Paper UI?
If so which ones do I need to read up on? (I realise the scope of that task is way beyond forum chat)

Good info gents, I just need to find out how to make it actually do something useful now.


Every Item has autoupdate enabled by default.
It’s always active until you take some positive action to disable it, which you have now.

You could show us your events.log of the sequence you describe.

Yes. The Thing does not represent your device status, it is best thought of as the pathway to your device.
Think about it, the device only checks in once in a while. Between check-ins, openHAB can have no idea if it has burst into flames.
Thing ONLINE meaning = “Last I heard, the broker was okay and is waiting for messages on that topic”

What panel? I guess you mean some openHAB UI but you’ve got to be explicit - there are a lot of moving parts here. openHAB host, MQTT broker, OH UI, MQTT client, networks in between. You’re dealing with a complex system.

That’s two different things. Let’s not go off on tangents again, let’s focus on the first part, come back to the other later if you need it, do one thing at a time.

It’s quite reasonable to expect poking a button on your UI to have no effect if the target device is broken. Disabling autoupdate should accomplish that. Looking forward to your events.log to see why that appears not to happen.

OH2 supports the use of both xxx.items and xxx.things files
PaperUI supports the creation and editing of both Things and Items, and can also handle the links between them.

You will get conflicting advice on which is “best” for various reasons, and that will vary depending on the context.
You can mix the methodology in your own system, it is not either/or, but my advice is to take a consistent approach for your own sanity.
For any single Item or Thing you cannot mix e.g. create in file and then edit PaperUI.

There are a few circumstances involving e.g. legacy OH1 bindings where you must use legacy OH1 methods - files.


You can create your Things and items in files to verify everything works as expected. Below is an example of a few Tasmota Things/Items created via files. The file location is etc/openhab2/things and etc/openhab2/items you can name the file whatever you want.

Thing file:

Bridge mqtt:broker:pibroker "pibroker" [ host="", port=1883, secure=false, username="xxxxx", password="xxxxxxx" ]
    Thing topic sonoff11 "Living Room Light" @ "Living Room" {
        Type switch : power       "Power"         [ stateTopic="stat/sonoff11/POWER", commandTopic="cmnd/sonoff11/POWER" ]
        Type number : temperature "Temperature"   [ stateTopic="tele/sonoff11/SENSOR", transformationPattern="JSONPATH:$.SI7021.Temperature" ]
        Type number : humidity    "Humidity"      [ stateTopic="tele/sonoff11/SENSOR", transformationPattern="JSONPATH:$.SI7021.Humidity" ]

    Thing topic sonoff2 "Couch Light" @ "Couch Light" {
        Type switch : power        "Power"         [ stateTopic="stat/sonoff2/POWER", commandTopic="cmnd/sonoff2/POWER" ]

    Thing topic sonoff55 "Office Light" @ "Office" {
        Type switch : power        "Power"         [ stateTopic="stat/sonoff55/POWER", commandTopic="cmnd/sonoff55/POWER" ]

Items file:

Switch LivingRoom_Light "Living Room Light" <light>  ["Lighting"] { channel="mqtt:topic:pibroker:sonoff11:power" }
Number LivingRoom_Light_Temp "Temperature [%.1f °F]"      <temp>             { channel="mqtt:topic:pibroker:sonoff11:temperature" }
Number LivingRoom_Light_Humidity    "Humidity [%.1f %%]"    <humidity>       { channel="mqtt:topic:pibroker:sonoff11:humidity" }

Switch CouchLight "Couch Light" <light>  ["Lighting"]  { channel="mqtt:topic:pibroker:sonoff2:power" }

Switch OfficeLight "Office Light" <light>  ["Lighting"]  { channel="mqtt:topic:pibroker:sonoff55:power", expire="180m,command=OFF" }

Afterward, you can move your Things from files to PaperUI and leave the items in files. See this post for migrating from text files to PaperUI: