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…! 
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 
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, 
, 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.
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.
- do I translate the message to the existing code can recognize it?
or - 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.
Thanks,
Al
VSCode works well and here is a video showing how to install:
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 ?
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!
I’m not 2.5.3
Sorry No… but only because I cleaned them all, all two of them , 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
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?
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.
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
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
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.
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
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
After all that, you could at least tell us
if you successfully linked your openHAB Items to Tasmota (last heard everything deleted),
resolved an error message about onoff,
and are successfully (or not) using a SystemBroker type Thng with Mosquitto.
?
Sorry folks…
I felt it had all gone down a bit of a rabbit hole and got bound up in complex and apparently not yet supported stuff.
If I use Paper UI to add the MQTT broker and then add a generic MQTT thing thing all is well, except the system isn’t showing the basic MQTT thing offline in response to an LWT topic.
Other than that, an a little confusion, mine, over auto-update and the link profiles, it seems to work, easily.
With respect to manuals I am struggling quite a bit.
Now I am well aware that some of that is simply my lack of understanding and thus inability to look in the right places, but there are chunks that, although long and detailed seem to lack some basic qualification, almost certainly implicitly understood by the authors but very frustrating for a noob.
Case in point… and what I am struggling with now.
I realize that the sheer scope makes giving specific examples for everything impossible, and I can also see that a huge amount of time effort and thought went into the vast quantities of data available now but I still think this explanation is lacking with respect to detail.
What is a UID and where would I find that in any of the UI, any of them, if I needed it.
I am assuming it is a construct that forms a Unique ID
I am assuming all ID’s are unique in some scope but what scope?
Is Label optional or is its omission from one definition of a “bulb” and inclusion in another impotent.
Am I correct in assuming that the UID of a bulb defined to inherit its parent bridge will be different from on defined with a reference… Despite the functional relationship being the same.
what is @ Location and is it impotent
if…
Bridge mqtt:broker:MyMQTTBroker […] contains Thing topic sonoff_Dual_Thing “Light_Dual” @ “Sonoff”
dose that make “Light_Dual” the label and “Sonoff” the location
Furthermore is the following correct?
Thing mqtt:topic:MyMQTTBroker:sonoff_Dual_Thing (mqtt:broker:MyMQTTBroker) “Light_Dual” @ “Sonoff”
Perhaps I am just being dense but the format changes spaces to colons and no concise description of the differing syntax is making this difficult.
I have installed VS but it inst helping much with this. Perhaps its just me.
In general I think the issues, not finding references to settings, or even functional detail, and the myriad ways to do things is somewhat overwhelming.
For example consider config edits…
Paper UI looks and feels great, but I cant find answers to some basic stuff and apparently neither can the folk potentially helping me.
The REST API UI interface also looks great and makes cloning stuff from configs assembled using Paper UI relay easy BUT the syntax if the configs is different so literally none of the config editing examples make much sense.
I suspect this will be the way to go but I have been persuaded to go back to files, which have to be build manually, because I cant find much in the way of docs of advice when it comes to modifying stuff accessed via the API.
I thought I would be able to pull code with the API and use it to build a file with VS, getting the best of both world but that dosnt seem to work.
Essentially it took me a few of hours to get a Sonoff to switch when I pressed a button,
Ignoring install time. but I have now been 3 days trying to find the best way to plan my system and implement it.
PLEASE dont think I am complaining, I am a little frustrated but I am frustrated with by far the most promising tool I have looked at to do what I want to do.
It inst perfect by any means, but nothing is and I suspect with enough effort and the truly awesome capabilities of the suite as a whole I will get most of what I want quickly and all of what I want at some point.
The original issue by the way… I suspect I was coming at it literally backwards.
I think the LWT driven event is propagated from a channel to the UI, and or rules and scripts, and was never intended to reach back and mark a a device offline.
I do however think it noteworthy that some obviously knowledgeable folk who have been trying to answer my detail orientated questions don’t know that… Functional descriptions?
When you think about it it makes sense.
Sure the manual tells you to create a generic mqtt device for each physical device but then it also defines the state topics in child objects so there is no technical reason the one generic device couldn’t be handling a bunch of physical devices, it just requires more links…
Thanks folks,
don’t take my frustration as in any way indicating annoyd, or even disappointed.
I think the system is great has even greater potential when I get my head around the complexity and I really appreciate the help.
Cheers,
Al
As stated to you several times in this thread, that is as designed!