Tasmota status issue... I think?

Setup, Configuration and Use Items & Sitemaps
,
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?

35

This message never reports the ID of the channel it is associated with (regrettably). You will find many such examples in these forums for comparison.

Do not assume that in-flight editing of Things is immediately picked up by any binding. Deletions especially get missed until next restart of binding bundle(or OH system). I couldn’t say how good MQTT binding is at this.

I think you’re on a goose chase.

36

OK SO both physical devices are disconnected.
Injecting ’ tele/TYCG_073/LWT OFF ’ using is not changing the device state but is not generating an object/collection enum error.
note that a payload of ’ Off ’ or ’ off ’ gives the/an error.

I tried with the LWT payload blank, so default, in the device thing and also explicitly defining ON and OFF.

The only time I see a device thing offline is if the MQTT broker is unavailable or disabled so I know it works but I dont know how.

VS now I think.

Al

37

Good point RE restart, I will try that…

I agree but goose tastes so god when its cooked properly…
Anyway I am learning loads and its better done now before I define the whole house.

Update when I have some, even if I am just giving up

BTW… When the Thing is updated, by editing it, the log shows this using the device ID as a qualifier.

Thanks

38

As I said before, do not look upon a generic Thing ‘online’ status as an indication of the target device’s health, which can never truly be known. It’s an indicator that the pathway to it is apparently okay.
From that viewpoint, it will indeed go ‘offline’ if the “parent” broker Thing is in trouble.

People have constructed their own LWT “actions” in the past, simply by having an Item/channel listen for a specific LWT topic and manage it in rules.

It looks like an effort is/has been made to build that functionality into the binding in recent months, with a focus on the Home Automation implementation. It is undocumented as yet.
Whether that work is actually complete or functional in your version, I could not say.
Whether that work was intended to also be available for generic MQTT Things, I know not. I understand Tasmota is at least partly Home Automation compatible, so that’s a start.

I’m still plumping for goose chase.

39

Cant disagree with that summery at all and although I think the discussion and the issue is as done as it is going to get it defiantly wasn’t a pointless process.

Just getting to the point where I know what to expect and having now learned where to look for stuff is huge, and way more productive than trawling through endless manuals, many of which would have been a poor choice of reading, in this context anyway.

I am going to start a new thread asking for opinions on rule handling, automation and Node red but I need to do some searching of existing posts first.

I have also setup VS with the Openhab extension, which oddly dosn’t look like the examples, although it looks like it is going to work.

I am considering this thread closed, but will of course monitor for any future comments.
Thanks everyone for the help.

Al

40

If these manuals, which you think are a “poor choice”, are from openHAB.org, please let us know which and why. Only that way those manuals can evolve.

1 Like