Homie 3 items not read properly in OH2.5M1

Tags: #<Tag:0x00007f6172378d10> #<Tag:0x00007f6172378bd0>

I have the following MQTT structure, and the item shows up in the Inbox.
Yet, after adding the thing and linking Items, the values are all NaN.
Is the structure missing anything?
Also, AFAIK OH2.4 used to show “BLEIO canvas” as name, now it just shows the topic id…

homie/bleio-fc9bc622bfce/$state ready
homie/bleio-fc9bc622bfce/$name BLEIO canvas
homie/bleio-fc9bc622bfce/$homie 3.0.1
homie/bleio-fc9bc622bfce/$mac FC:9B:C6:22:BF:CE
homie/bleio-fc9bc622bfce/$fw/name bleio-bridge
homie/bleio-fc9bc622bfce/$fw/version 1.0.0
homie/bleio-fc9bc622bfce/$implementation homie-python
homie/bleio-fc9bc622bfce/$stats signal,battery
homie/bleio-fc9bc622bfce/$stats/interval 60
homie/bleio-fc9bc622bfce/$stats/uptime 1740
homie/bleio-fc9bc622bfce/$stats/signal 58
homie/bleio-fc9bc622bfce/$nodes contact,battery
homie/bleio-fc9bc622bfce/contact/$name contact
homie/bleio-fc9bc622bfce/contact/$type contact
homie/bleio-fc9bc622bfce/contact/$properties contact,count
homie/bleio-fc9bc622bfce/contact/contact/$name Contact value
homie/bleio-fc9bc622bfce/contact/contact/$datatype boolean
homie/bleio-fc9bc622bfce/contact/count/$name Contact count
homie/bleio-fc9bc622bfce/contact/count/$datatype integer
homie/bleio-fc9bc622bfce/battery/$name battery
homie/bleio-fc9bc622bfce/battery/$type battery
homie/bleio-fc9bc622bfce/battery/$properties level
homie/bleio-fc9bc622bfce/battery/level/$name Battery level
homie/bleio-fc9bc622bfce/battery/level/$unit %
homie/bleio-fc9bc622bfce/battery/level/$datatype integer
homie/bleio-fc9bc622bfce/battery/level/$format 0:100

Does that homie topic structure validate correctly against the homie verificator on the homie website ?

https://homieiot.github.io/tools/

My homie items are read correctly, only thing which is changed from 2.4 is I believe heartbeat which was removed from next rls of homie if I recon correctly.

So most probably you have an slight error somewhere, do check it on homie website.

just practical note:
I do recommend to set it manually via files as this turned to be much more reliable than via paperUI. I’ve experienced issues when thing went offline or broker went offline, paperui autodiscovered things have had difficulties afterwards. Since I’ve changed everything to files, I’m running smoothly ever since

The validator seems to crash with every nested $-topic, like $stats/internal…

I was just told that that is a valid Homie structure.

Yet, OH does not seem to parse $name in autodiscovery,
and after adding as a thing and linking mostly the values are still NaN.

I have my own homie implementation that OH doesn’t like. No one has ever helped in stating what payloads are key or even used. Given the state of MQTT in OH2.5M1 I’ve stopped trying to get it to to work and always just assumed it’s broken. I’ve either had an unsupportive, dismissive or await next milestone fix response … but it is still broken even now.

I’ve already spent too much time on homie3 trying to fix my end, when maybe it’s not broken. I don’t like homie3 and I’m now really a bystander until it stabilises. Then I might try again.

K

dude, only thing which may be broken is your homie implementation… my homie devices are auto discovered by OH 2.4 and 2.5 just fine

and i have not done something super special, just followed homie webpage with validator and documentation

Did the validator work for you? despite of the fact that it used to crash with Homie3 $stats attributes?

… forgive me if I remain skeptical … not that my homie implementation is flawed, it may be - but that homie works fine for you in 2.4 (or even 2.5M1). I am sure it is broken in both, especially 2.4

how exactly it supposed to be broken?

Inparticular in that thread

There are moves to fix this but it’s quite a bit of work I think

I really didn’t want this to turn into a rant about the MQTT binding.

Is there any way we could patch our binding? Maybe somehow uninstall the binding and install a patched jar?

The validator was broken for me the last time I tried it (a couple of weeks ago), it indeed crashes on a perfectly valid homie device according to the spec. Not sure how it ever saw the light of day to be honest.

I would await 2.5M2 and try again assuming you’re willing to run 2.5. I don’t think the patches you want exist.

Part of the problem is that homie is so untested , OH being the only real application consuming it. It’s hard to know what and where any issues are.

There are a couple of other applications now on Athom Homey and Hubitat Elevation that support homie discovery and they work quite well together but they were written and tested to do that. Hopefully OH will become ‘the’ viable homie test device soon.

Daniel… you don’t have an MQTT Explorer screenshot of your topic tree fully expanded do you. It’s much easier to interpret.

Or thinking … just publish to a public broker and I can connect to same for discovery and see if Homey or Elevation accept it. But they will be less stringent than OH I’m sure.

Some MQTT fixes (3 PR) were merged today, including homie bugs. Maybe try with the next snapshot and report back what is missing. There are still some issues on my list, but we can see if it already improved.

If you can point me to a complete (and correct) homie setup, I can try to see why the OH binding is not properly using it.

thanks, i will do that

could you point me to those pull requests and the source code for the homie binding?

Nvm i think i found it.