[BETA] MQTT app homie3 protocol support... OpenHAB, Athom Homey etc

This is the discussion topic for the MQTT app and it's use in connection with the homie3 / homie4 protocol. General discussion on the MQTT app (not homie or OpenHAB / Athom Homey related) should instead be directed to the main topic here.

The MQTT app uses the emerging homie3 topic structure as it's default MQTT presentation ,it provides advertising, status and control bi-directionally. Additionally the homie3 structure can be minimised to just provide essentially status reporting and control, removing static topics but will then no longer be homie3 compliant.

https://homieiot.github.io/

Whilst this provides linking to OpenHAB, Athom Homey and other controllers this is however not the primary purpose of the MQTT application for HE - more a side benefit. I am not a user of OH so can provide little support for OH and possibly on OH issues the OH forum itself might prove more appropriate and helpful. I am familiar with Athom Homey however

The MQTT app will discover devices advertised using the homie3 protocol. OpenHAB surprisingly (as they are the primary advocate of homie3) do not implement this export of devices. Athom Homey does.

The MQTT app advertises HE inbuilt devices using the homie3 MQTT protocol. This allows OH and others to discover these HE devices and include them into that system for both realtime status and control. I have been told this works well with OH v2.5 and above.

The range of device types supported between OH and HE includes switches, lights (white, colour and also colour temperature). many sensors along with locks. More devices will be added over time but the majority are already covered. Climate devices like thermostats are not currently supported for import to HE but do export to homie, as do keypads , buttons and quite a few other HE device capabilities.

Additionally using the MQTT app any MQTT exposed device can be imported as an aribitrary 'manual' device into HE and associated with one of HE's 24 inbuilt virtual device drivers.

N.B. Although homie3 in and out protocol theoretically allows two HE hubs / devices to be linked with discovery , status and control this is not recommended (or even tested at this time). The app was not designed with that purpose in mind. Instead the recommended approach is HubLInk or HubConnect which have been specifically designed for this application.

BTW OpenHAB does support the HA MQTT Discovery protocol too.

placeholder

Can anyone tell my why the MQTT is not discovering the "aa-1" device below? This is just my test before I start getting everything in there. I want to make sure the schema is right before I go any further:

Not an expert - I'm still working on my own structure for MQTT but you show 2 properties onoff and dim but only onoff is fleshed out. Missing the 'dim'.

Dim is on there, it's above the $properties. They got put in there out of order. Does that matter? I don't think it does because it looks like it subscribes with wildcards.

Yes. my error. FWIW, I'm also having issues with homie 3 discovery.

Are those values actually published to MQTT retained? You can test this by disconnecting MQTT Explorer and reconnecting. They should re-appear. Do not rely on the retained indication that Explorer shows, it is only showing the status at connection.

Also maybe you have a device called It2000 that should be it2000. You have the homie discovery topic set to It2000 do you ? Or is that a lowercase L in which case it’s good.

It's a lowercase "L".

I'll check retention in a few.

I’ll check later but topics look complete.

I recreated your device manually in MQTT and then ran the MQTT app

image

It was discovered fine - is yours not even discovered here ?

Where I have hubitat-42 you have entered lt2000 ?

image

image

Nope, not even discovered.

Then either your discovery topic is wrong or the topics are not being published 'retained'. If MQTT Explorer is re-connected to the broker does it show all that same detail (do not publish it again from your device) ?

I have just copied verbatim the topics/payload from your screenshot

I did get discovery to work on my home crafted esp32 motion sensor. The virtual motion sensor doesn't seem to track it however. For layout, @signal15, you can mark one of your hubitat device and export it MQTT. That will create something you can compare with in MQTT Explorer.

I just replied to your bug report on this. First step assuming the sensor only reports active|inactive is to change that to a boolean node and report true|false instead (which is a homie requirement).

If you were adding it as a 'manual' device to my app then you could accept any 'word' and map it to 'active' 'inactive' or whatever is required. homie and my 'discovery' of a motion sensor however expects boolean and requires true|false.

Yeah, it's not retaining the messages. I just created that data with MQTT explorer, and it seems that there is not a retain option. I'll create it with the paho python library.

Thanks!

edit, oh crap, there is a retain option. I just didn't scroll down far enough. :slight_smile:

.. and a QoS should you wish...
Just republish the existing payloads with retain set and hopefully discovery will work
image

Sweet! That works. Now when I switch it from on or off within Hubitat, shouldn't it publish to a topic like: "homie/lt2000/aa-1/onoff/set = true"?

I'm not getting that. Actually, nothing is publishing to the aa-1 device when I change something from the Hubitat. But, when I publish to "homie/lt2000/aa-1/dim" or ".../onoff", the Hubitat at least picks that up. It seems that the alpha versions of this MQTT app required a /set after the dim or onoff topic, and that configuration screen is gone now in the beta.

Yes - it should - it wont publish a command if the requested state is the same as the existing state though. Make sure it is a different state. I'll check here too in case it's a bug

image

On the second screen of my app 'Virtual MQTT Data' enable the device in the middle dropdown. You don't have to go through 'done'. This is untidy I realise - I will try and handle this better but I can't programatically enable devices.

image

TBH I'm a bit taken aback, but pleased by the uptake on homie discovery as very few devices already publish in this format. You two guys are originating your own implementation which is great.
Most of the questions have always been on HA 'discovery' and that has most device types covered.

When I look at my current homie discovery implementation I am only supporting the 'onoff' and 'dim' properties although I am indirectly discovering sensors. This means that the motion sensor that you have @ccoupe will be inadvertently discovered but won't update because I am not subscribed to the 'motion' topic. I'll get that added in the next update and also other sensors if they are easy.

What I won't be adding is active_hold though as it's custom. Probably best to create a dim property for that and you already have given it a $name=Active Hold and handle it that way. You could do the same with onoff and the PIR status and it would work with the beta 1 already.

In the future what I might do is take the $properties topic, which I don't utilise currently, and then subscribe to those listed. This would work well if I allowed 'enabling' at the node level rather than the 'property' level (onoff dim motion) - it would hold the node together as one entity with its properties and I could also pick up any custom properties for the node (although quite what I could do with them is another discussion)

I've got a working device and a working hubitat driver of my own so I can wait a long time. :wink: Handling unknown properties in discovery is pretty damn tricky.

The state of Homie3 is 'half baked', IMO. The Arduino|Platformio support for Homie is 'iffy' and pushes my 'Why I don't like C++' button. My burden to bear. Looking forward to helping test the next commit.