MQTT / LWT - Things Definition - Availability Topic

OH3 has the option to define your Things via YAML through the UI Code tab. But you can also use Things files like in OH2, or you can use the UI itself.

You’ll have to tell us what you means, what your configuration is and why you say it doesn’t work. For a start, do you have the JSONPATH Transformation Service installed?

Assuming we’re still on-topic and this is about availability?

Related -

So far as I can see the Thing ‘availability’ is about standardized LWT messages, no transformations are offered.

Comment; while the config examples page got updated for availabityTopic, the subject is still completely missing from the generic docs. It does deserve a mention - would someone knowledgeable take this on, please?

Yes it is on topic and it is about availability.

The device that am using is an Advantech Smart IO (ADAM-6024-D) that supports MQTT.

However, the last will message is of a JSON format and it is locked due to firmware probably, i can’t change it.

If connected, its:
{"status":"connect","name":"ADAM6024-D","macid":"<MAC ADDRESS>","ipaddr":"<IP ADDRESS>"}

if disconnected, its:
{"status":"disconnect","name":"ADAM6024-D","macid":"<MAC ADDRESS>","ipaddr":"<IP ADDRESS>"}

i just need to extract the status bit. I have seen somewhere in forums where people do something like:

availabilityTopic="<Path-in-MQTT>:JSONPATH:$.status"

while the .things file does not complain, it only shows offline status and doesn’t change.

On another note, what is the difference between lastwill and availabilityTopic? aren’t they the same thing?

File validation is only about basic syntax, it does not check if the parameter even exists, let alone is set to something meaningful.
Bananas=‘custard’
will flag no error.
(One reason people bang on about using GUI instead)

Probably worth referring back to that.

So you can put the whole JSON string in the matches (being careful about quote marks)?

Are you looking in different places? The Bridge thing may define an LWT for other’s information when openHAB goes offline.
This is unrelated to Thing availability topics listening to external devices.

I was probably referring to the old mqatt configuration in items:

"Luftfeuchte [%d %%]" <humidity> [ "CurrentHumidity" ] {mqtt="<[ mosquitto:tele/sonoff/SENSOR:state:JSONPATH($.DHT11.Humidity)]" }

:state:JSONPATH($.DHT11.Humidity)

is that something that can be done in the availabilityTopic in things configuration?

Also, looks like i confused LWT with availabilityTopic. i wasn’t referring to OH as a MQTT client rather than the device.

if i understand this correctly the availability topic for a device is expected to have the device’s LWT message configured?

Yes.

Don’t forget there is nothing to stop you subscribing to any topic with an ordinary channel, and processing the payload in any way you see fit.

For giggles I will ask again - why does this Binding hide this doc? I ask when I know the answer: the binding author does not want/believe in file based configuration so will not allow the file based documentation in the binding documentation (a request denied prior for that reason)…a conceit that confounds users over and over again.

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?

OMG!!! I have been using OpenHAB since 2019 (or 2018? I think), and I have been using MQTT since the beginning and ONLY JUST NOW have I discovered this. And only after working on mqtt binding source code to do some PRs, I saw some references to availabilityTopic which piqued my interest.

PR submitted:

Anything I should add / change?

1 Like