Tasmota status issue... I think?

Setup, Configuration and Use Items & Sitemaps
,
15

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.

16

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.

17

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.

18

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

19

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
20

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:

21

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

22

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.

23

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.

atom_Json
atom_Json1600×875 68.8 KB

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

24

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
25

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

Thing_LWT
Thing_LWT1031×712 31.6 KB

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

26

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

27

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.

28

No its a bridge… A device, in this case a generic MQTT thing which is physically a Sonoff running Tasmota.

The broker ‘thing’, a totally different ‘thing’ is specified, elsewhere and referenced here, as you explained it would need to be.
Thus the LWT topic in question is being generated by the MQTT broker in response to the availability of a single device and subscribed to by the thing in the screenshot.

Anyway the issue isn’t where the message is coming from, or even what I have picked to subscribe to it it is the fact that the payload isn’t being identified and utilized. I know it is being processed by the correct ‘thing’ because the log tells me that ting is failing to numerate the response.
All of which is perfectly clear to me I am asking 1 of two things.

  1. do I translate the message to the existing code can recognize it?
    or
  2. Do I add something somewhere, ultimately updating the underlying collection in real terms, so that the existing message is recognized.

The screenshot shows a config that according to the documentation dose the latter
the log shows that the latter is pointless, inactive or malformed… Delete as appropriate.

‘’'Command ‘Offline’ not supported by type ‘OnOffValue’: No enum constant…
.

Ways to work… Files or REST API… RE REST…

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

How is that in any way different than building a file?
The JSOM processed by the system, good or bad, is identical.

If you are going to tell me to use an editor that understands the context I am working with, that’s fine, I would love one that works well.
That however would work equally well with either approach to physically update Openhab.

MQTT broker…
The documentation supplied with and the project clone setup recomended by the latest 2.5 version install instructions specifically tell a noob to use an external MQTT broker.
Install MQTT broker and a script to do that is part of a recommended install.

Why, or if that is better than a 1 click option to enable the embed one… who knows, definatly not the intended audience of the document.
You seem tom be suggesting I am doing things that are not ‘standard’/‘recommended’ where as in actuality every click and setting associated with setting up that first device, and the system it is added to, was done exactly as the latest setup manual tells me to do it.
By the book as I said, I even posted a shot of every screen I altered the last time someone told me that I wasn’t being clear enough.

Look, If I made a mistake, having misunderstood a step in the manual or after some experimentation, I am more than happy, grateful in fact, to be corrected but I have an issue with you simply telling me my setup is wrong without,
a, reading the info I posted, or b, telling me why,
particularly when what you are saying directly contradicts the setup manual.

Moreover. I am eager to learn, and realize that requires me to be wrong, or clueless, in the first place and accept that. What is not helpful is advice without explanation, citation or qualification.
If I just blindly followed that I would change me entire config based on whatever opinion the last post inferred was ‘normal’

I posted the log, you can see the issue and it inst the binding or broker service.
I am happy to accept it could be the/my setup of the device ‘thing’, but then you just looked at a screenshot of that and told me it isn’t my device.

Just to clarify, my entire ‘Things’ list, also previously posted as requested.

Things
Things1600×875 88.1 KB

Thanks,
Al

29

VSCode works well and here is a video showing how to install:

30

I think we need to worry about what kind of bridge.
MQTT binding supports two types of broker bridge Things
A Broker for any old broker you like e.g. Mosquitto, installed wherever you like.
A SystemBroker for the embedded Moquette broker, which is packaged and documented as easy peasy for beginners but it turns out he creators have stopped supporting it. So recently, the recommendation is to avoid using the embedded broker, because some issues have emerged that won’t get fixed (I think LWT handling may be amongst them, as it happens)

That’s good. But in that case, you’ve got elements of alternative setups - plain ordinary Broker type bridge Thing is preferred over the SystemBroker type bridge Thing for connection to Mosquitto.

Okay, I can see now that TYCG-071 is indeed a generic thing.
That’s good!
I don’t recognise the “Availability Topic” configuration screen at all. I don’t get offered that when editing a Generic with base 2.5

I know there was work on the binding for this kind of feature for HomeAssistant subset of MQTT.
So that looks to be new at 2.5.3, and maybe has leaked through to “generic” as well. And why not.
But maybe it just does not work (yet)

Moving on …

This log message is, I am convinced, coming from a channel.
That’s to say, it is not related to the Thing “availability” configuration, which is about Thing online/offline etc. and not about onoff.

May we see the switch type channel(s) that you have currently configured for TYCG-071 ?

31

I didn’t recognise as well, however when trying to configure a Generic MQTT Thing and hit the ShowMore you will find it. I was surprised as well!

32

I’m not 2.5.3

33

Sorry No… but only because I cleaned them all, all two of them :astonished:, out.
I take your point RE the source of the error in the log though, and no I didn’t check that, should have!

Well that looks cool and I agree way better than my tentative plan with the tight integration.
As it happens though it will also integrate using the REST API which gives all the automated features, exactly as it would linked to the config directory, but keeping the config in the JSON backend and thus the Paper UI fully editable.

VS is also available as a .dbb and even more simply via Snap.

Great tip thank so much.
goint to try the install now

Al

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

2020-04-07 14:16:20.631 [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 no switches, or evrn channels defined right now, just two devices so these are not coming from a switch.

However There is no device ID in the log, which I am sure there would be if this was from a device, so it makes me wonder if these are actually being generated by the MQTT service, or its associated binding which looks more likely.

I am going to setup the VS editor which should let me examine the JSON for the MQTT binding…
That may reviel what is going on and better still how to fix it.

If my superstition is correct…
This would mean that MQTT messages are being parsed by the the binding and the topic delivered to the device thing as a structured object/class ref whatever.

The point is that if the payload, and or topic, is an enumerated collection/objevct, as opposed to a string property then the unrecognized payload, “Offline” or “Online” in this case, will never make it to the device thing and so cant be compared to the availability Topic, (LWT), payload settings.

Thus, a transformation/map would be required on, or before the device ‘thing’, either in the System broker ‘thing’ or the system broker service…
The transform/map would need to modify the topic of the raw message and make it compatible with whatever ‘ab.binding.mqtt.generic.ChannelState’ can enumerate.

I think I will give this a go in Node Red and see what occurs
stat/…/LWT “Offline” > stat/…/NRT-LWT “OFF”

In theory if ab.binding.mqtt.generic.ChannelState supports “OFF” and the LWT btopic of the device thing is modified to stat/…/NRT-LWT, it should get the message from Node Red, assume it is actually a device stat and then act accordingly.

Fiddling to do me thinks.

Thoughts?