There is a possibility to define “Availability Topic” in generic MQTT Thing when defining it in Paper UI
But this option is not described in Docu:
I am wondering how to archive the same result in Things File?
There’s a few examples on this forum: here’s two, see the Reachable channel defined as a string, or the one below where the Reachable channel is defined as a switch…
A rummage in github suggest that this might be used as
availabilityTopic=
in xxx.things file. Presumably a parameter of your generic topic Thing.
Interesting - not much information around on that: a couple of posts, and a related open GitHub issue.
Assuming this worked, how would this be usefully used from the thing itself?
Don’t know much about it. From what I can glean, when the target device has been dead long enough, the broker posts its prerecorded LWT.
This parameter should subscribe to that LWT, and set the generic Thing OFFLINE.
How/why the Thing ever gets back online, I have no idea.
You can have rules listening for Thing status changes, so that bells can be rung or foolish calculations avoided.
Personally I would rather subscribe an ordinary channel to LWT and manage it all myself, as is done in those postings you suggested.
There is a point of view that Thing status is supposed to closely represent “physical device” status, but I’m not convinced about that.
This is the bit I was missing - didn’t know you could trigger off Things too. Never scrolled that far down the page…!
I presume just by receiving the Online (or whatever) LWT message?
When the end device connects, it publishes “ONLINE” as a retained message to a status topic. It registers that same topic as the LWT topic with “OFFLINE” as the message, also retained.
When the device goes offline the broker publishes " OFFLINE" to the status topic. When the device comes online it publishes “ONLINE” to the status topic. The messages are retained so the topic always has the current state on the device.
When it’s OFFLINE, the Thing will be marked as offline. In think the Items become UNDEF but have not tried looking at that yet.
Continuing the discussion from MQTT / LWT - Things Definition - Availability Topic:
ok, the availabilityTopic - is taken without error -
Thing mqtt:topic:gosund5 "Gosund5" [availabilityTopic="tele/gosund5/LWT", Payloadavailable="Online", Payloadnotavailabe="Offline"]{
I tried to use “Payloadavailable” as interpretation of the Online/Offline Value - but this is not interpreted - so i guess there is another syntax needed.
Is there a way to check what Syntax is needed here?
1 Like
Ok, found it myself:
Syntax working is as follows - in my case a complete example of a Gosund SP111 with LWT
Thing mqtt:topic:gosund1 "Gosund1" [availabilityTopic="tele/gosund1/LWT", payloadAvailable="Online", payloadNotAvailable="Offline"]{
Channels:
Type switch : gosund1_sw [ stateTopic="tele/gosund1/STATE", commandTopic="cmnd/gosund1/POWER", transformationPattern="JSONPATH:$.POWER", on="ON", off="OFF" ]
Type number : gosund1_PWR [ stateTopic="tele/gosund1/SENSOR", transformationPattern="JSONPATH:$.ENERGY.Power" ]
Type number : powerload "Power load" [ stateTopic="tele/gosund1/SENSOR", transformationPattern="JSONPATH:$.ENERGY.Power"]
Type number : voltage "Line voltage" [ stateTopic="tele/gosund1/SENSOR", transformationPattern="JSONPATH:$.ENERGY.Voltage"]
Type number : current "Line current" [ stateTopic="tele/gosund1/SENSOR", transformationPattern="JSONPATH:$.ENERGY.Current"]
Type number : total "Total energy today" [ stateTopic="tele/gosund1/SENSOR", transformationPattern="JSONPATH:$.ENERGY.Today"]
Type number : totalyest "Total energy yesterday" [ stateTopic="tele/gosund1/SENSOR", transformationPattern="JSONPATH:$.ENERGY.Yesterday"]
Type number : rssi "WiFi Signal Strength" [ stateTopic="tele/gosund1/STATE", transformationPattern="JSONPATH:$.Wifi.RSSI"]
}
This is the .java - Reference interpreting the Syntax of Thingsdefinition. Be aware of “Case-Sensivity”…
5 Likes
Good work. Probably worth adding to the documentation? I’ll do it at some point if you don’t get to it!
I’d also be interested in learning how you use this within openHAB!
oh- thanks - i’m not in the mood to fork the whole repository for editing - especially as i don’t see where this could go;
There is a special doc for thing configuration in a thing.
1 Like
Oh wow, if only I’d seen this when starting out!! Doesn’t have anything about LWT though. Are you suggesting a PR into that page, rather than the normal openHAB docs?
certainly.
I did create a pull request; https://github.com/openhab/openhab-addons/pull/8244 with an update on the mentioned file; Lets see -
1 Like
Does anyone know why the examples on the page linked by @Udo_Hartmann aren’t in the main MQTT binding documentation pages? Is it just because no one has done that yet, or is there another reason?
David decided not to provide the information in the official documentation, as far as I remember, he argued that this form of configuration is (more or less) deprecated and should not be part of the “main” documentation. As the docs are created automagically whenever a file is updated, but does not support more than one file per binding, …
As in, config files are (more or less) deprecated in favour of PaperUI configuration?
(I realise this is off-topic - apologies OP!)
Nope, as in “soon there will be OH3 with a non-xtend-configuration”
apologies for tackling this again but:
Nope, as in “soon there will be OH3 with a non-xtend-configuration”
am i confusing xtend-configuration with .things .items configurations?
Also, if the last will sent by the MQTT device is of a JSON format, is it possible to extract only a bit? transformationPattern=JSONPATH:$.X doesn’t work