Tasmota status issue... I think?

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…!
Screenshot_2020-04-05_19-10-14|690x377

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.

Al

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!

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

"{"POWER":"ON"}"

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]

"ON"

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.

Cheers,
Al

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](http://192.168.2.1:1880/#)tele/TYCG_073/LWT :   msg.payload : string[7]
"Offline"

06/04/2020, 00:27:17[node: 1cba4cdd.d83513](http://192.168.2.1:1880/#)
tele/TYCG_073/LWT : msg.payload : string[6]
"Online"

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.

Thanks,
Al

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.

Neither.
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.

2 Likes

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="10.0.1.15", port=1883, secure=false, username="xxxxx", password="xxxxxxx" ]
{
     Sonoffs
    Thing topic sonoff11 "Living Room Light" @ "Living Room" {
    Channels:
        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" {
    Channels:
        Type switch : power        "Power"         [ stateTopic="stat/sonoff2/POWER", commandTopic="cmnd/sonoff2/POWER" ]
    }

    Thing topic sonoff55 "Office Light" @ "Office" {
    Channels:
        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:

You star…
I was getting frustrated yesterday, lack of understanding, lack of ability and even lack of sleep.

I was also having some issues with the MQTT service no starting, filldged; shouldn’t have!.. So I took it out and reinstalled form Openhab config

Then I took out the MQTT broker binding and started again… That seems to have helped and the auto update properties are now working, well doing something I need to further understand anyway.
Progress me thinks…!

I am pretty sure that the stat/…/LWT will fix the issue complrtly once I understand the effect of the various settings. That inst working yet but I think it just needs a transform file.
I did try none standard strings in the section that identifies the payload but it didn’t seem to work, I may have another go.

Also I discovered that ‘Select a Profile for the link’ has a huge effect on what the switch respond to.
two switches linked to a single device seem to synchronize, or not, in one or other direction, but not necessary both, based on a combination of profile and auto update properties.
Is on pushing state info to the to the profile and the other responding to it? … Reading to do I guess.

I did make an item file, minimal info, and discovered that it defined the item but that paper UI will not edit it… Good to know that is anticipated behavior.

I think on balance files are probably the way to go for things items and associated organizational bits.
The UI is nice but I suspect lacks some functionality right now.
Perhaps more impotently though, I lack functionality and will learn faster building code, even if that is a bigger jump.

Are there any pitfalls with respect to version?
IE. if I find a code example from an older version are those objects/methods, probably not the right terminology, going to work. Additionally are there any new ones that would be preferred to an older, outdated approach.

Obviously I need to read the docs but my initial searches turned up a load of stuff saying don’t do that, use the UI, and more detailed searching is hard without context.

I am 100% behind the do it one way and only one way strategy, I agree anything else would likely be horrible to maintain somewhere down the line.

I am going to strip out all ‘things’ device specific and have another go using your example.
I don’t see a problem leaving the broker defined with the UI as it is acting like a service essentially.
If you think that is not a good call I would like to understand why, so I can make the right call.

All the help is much appreciated folks.
Sad to say I expect I will need much more one way or another.

I have separate questions about rules and other similar topics, but I am going to leave those for another thread, which can wait until the basics are in place.
I will be asking ‘better’ questions from a more informed perspective by then I suspect.

Thanks
Al

It’s fine, there are lot of very different things to get right for a “simple” end to end working switch.

You are unlikely to want anything to do with link profiles at this stage, just leave it default.

There are a great many posts around MQTT binding version 1, the giveaway is Items linked using {mqtt= ...}
These are useless in detail for use with the Things & channels of current version 2, though the principles can still be useful.

Link profile…
No desire to play with anything I don’t have to the point was that default as opposed to follow, I think, seemed to determine if a switch, when duplicated as an item, actually followed the status correctly.

I am not suggesting that duplicate switches are of any use or even practical just that the setting seems to determine what, other than user input, modifies switch state.
Anyway, duplicates are bad,channels / items at least, I was just testing.

REST API … Dam that UI is cool, who knew?
When I first saw the comment I thought , NO not another different way to go!
but it looks great.


This is the JSON code extracted from a thing created in Paper UI in 5 clicks.
(OK an hour of mucking about and then 5 clicks :cowboy_hat_face:)
it is pasted into Atom… Another, well some hours :sweat_smile:, to find and install.

I have yet to try but I am assuming I can either use the ‘REST API Documentation’, bloody silly name for a UI I might add, to install another thing after editing the code, or put it into a file and create one that way…
I will try both.

I have got my head around the basics of MQTT now, using Node red as a debugger, displaying and injecting, showed me what to expect and how to handle it.

What I need to look at now, to make an actual useful thing, is mapping, because Tasmota, well Mosquito as its proxy, is spitting out ‘Online’ and ‘Offline’ in the LWT message wher Openhab wants ON and OFF.
I tried defining that in the thing but it didn’t seem to work… Another try perhaps…
Just changed that and extracted JSON again ad it changed the payload text associated with LWT rather than adding a map…
Seems logical… So whats the map about? I am sure someone mentioned that earlier.
Something else not to play with yet I think.

2020-04-07 00:45:05.864 [WARN ] [ab.binding.mqtt.generic.ChannelState] - Command 'Offline' not supported by type 'OnOffValue': No enum constant org.eclipse.smarthome.core.library.types.OnOffType.Offline

OK so officially broken… I understand what that means, I don’t understand how to fix it.
Why provide a field in which to set the match for the payload if setting it has no effect?
Do I have to put a .map or some form of translation in there? (The field/setpoint I mean)

On and up… or perhaps spiraling down… Its a bit of a lottery right now.
Much happier with the examination of JSON stuff now I have been pointed to the REST API mind you.

Just one clarification… It, REST API Documentation, isn’t under Misc anymore it is in UI’s.
Makes sense when you know what it is, but had me confused for a while.

Thanks folks,
I may have given up without your patience and support. Too much stuff and not enough hours.
Al

You must have realised by now that we cannot see what you are doing, have no idea what settings you are applying to what.
When you want some help, show us.

1 Like

Sorry… Thought that was sufficient context, here is a screenshot…


I will try to be more clear.
NB.
The Payload qualifiers here are set to the default values.
I was talking about setting them to ‘Online’ and ‘Offline’, respectively, because that is what the MQTT broker spits ouut in response to a Tasmota device comming on-line or,going off-line.

The MQTT bit/confog in the device and on the broker is fine, I have tested that with Node Red.
The issue is getting, or more likely me understanding how to get, Openhab to recognize the availability of the device.

If I stop the broker, or disable the service in Openhab the dependent things do go offline and then behave as I would expect, IE refusing to change state in response to UI commands.
They also respond correctly to the physical device status when it coms back online.

Literally 90% of the way there… And I am now pretty sure the last 10% is me failing not the system but I cant find the answer when searching, other than references to a map file.
(I haven’t actually found anything that tells me where or how to use a map file from a script/code/setting, point of view.)

Dood…! :smiling_face_with_three_hearts:
That has to be the most understated reply I ever got.

REST API Documentation, which is effectively a GUI utility to extract and deploy code that defines stuff, is literally AWESOME :astonished:

It manipulates text, JSON, from objects/definitions crated in Paper UI almost like it was handling a text file.
But it also handles the collection aspect of stuff so you can get a list of ‘stuff’s’ and then use that text to identify the ‘stuff’ to edit, calling it with the ID you just copped from the last query.

Stuff can be read, created, and even modified.
It even provides a template for all types of stuff at all levels of the tree/structure.

Ergo…
you are effectively working with files that are created by, or modifiers of, Paper UI. Because they are not physical files the items are editable in either interface…

Never mind this ‘one or the other approach stuff’, REST dose the business.
Make a ‘thing’ in Paper UI, clicking from inbox perhaps, and then immediately look under the hood to see what makes it work; and even fiddle with it a biy.
Hell you can even back it up first so that when you have broken it, :innocent:, you can restore it with a few clicks.

Why is nobody raving about this?; it is literally all thing to all men, provided the syntax is good the REST API just shoves in whatever code you pasted in.
As a solution to configuration it seems to be be as flexible as physical files, but without files, and with the ability to automatically generate templates from existing Paper UI configs.

I added a new MQTT ‘thing’ in less tome than it has taken to think about this post, let alone type it. I copied an existing ‘thing’'s code, did a text search and replace, twice, and posted the new code back as a new thing.
it went online immediately.

To be fair I had stripped out the links, and associated items, but both of those can be handled in the same way, just using different collections.

Had I known about this 48 Hrs ago I could have saved myself, and you folks, hours or reading and mucking about.
Granted I wouldn’t be any clever; but I would have had a feel for what was going on; way sooner.

The downside is that I now have more to learn but at least the system will work as an exemplar now, as opposed to being a fussy black box.

I think this should be front and center and installed, by default, in the standard build.
Just having the code there, so it can be used to ask better questions or search for examples, is huge, never mind the productivity bonus.

Thanks so much…
Best regards,
Al

It appears to be a screenshot of you configuring a SystemBroker type Thing?

Note that a SystemBroker type Thing is supposed to be associated with a broker, a very specific broker, the bundled “embedded” Moquette broker that everyone is advised not to use now.

You appear to be configuring a LWT message on that Thing for openHAB to use to announce to the broker that it (openHAB) is online/offfline.

In short, it’s got nothing to do with your Tasmota at all. This is why I asked for detail.

LWT associated with some remote device is just another topic. You’d usually create another channel in the bundle of channels of your Generic Thing that represents your device, probably link it to an Item, and do whatever yo do in response to Item changes.

Um, you are using a generic Thing to represent your Tasmota. right?

Don’t. You’re going to get in a mess. “just shoves in whatever code you pasted” is the problem.