Mine too - I'm using it, well, because it's there and OpenHAB and Athom Homey supports it which is useful. homie4 is announced and I believe has been simplified but we're missing device type definition.
I could have used any format but there just isn't an alternative discovery format so I might as well use homie. You can turn off the 'complete' homie compliance and just publish a minimal structure if you wish. But for 'discovery' I need the extra homie information (or HA statestream).
homie3 is just not very helpful in converting it's information into a real device in it's current form. Consider something more complex like a thermostat for example. I'm hopeful it might flesh out a bit with higher level device templates as it starts to be adopted more.
So, quick question on MQTT best practices... My device I'm creating is using the homie3 schema. I've created an MQTT schema for it, but am not pushing it to the MQTT server yet. The MQTT app on HE subscribes to all of the topics under homie/lt2000. My device needs to subscribe as well in order to get the set commands when the HE requests a change in lighting load. So, on my device, do I subscribe it to the homie/lt2000 topic, or should I subscribe it to the homie/hubitat topic? Because with what I'm reading, if I both subscribe and publish to the homie/lt2000 topic, I'll get updates back to my device for what I just published. At least this is what I'm reading on using MQTT.
Yes, you do have to worry about catching things that you just published if you subscribe too broadly. The MQTT app/driver from Kevin can publish HE events to MQTT -> /homie/hub-name-you-chose . You can review my library for Arduinoc++ if it will help you. I too wanted to get a /set on a property. It's not too bad once it becomes clear. In other words, the /set should be on your device homie/lt2000/node/property.
So if I publish from the HE to $dim/set for a load, my device will pick that up and send the command over the serial port. But if someone presses a wall switch, my device will publish to the $dim/set also, and receive what I just published. So is the solution just to check my dim level and only send the serial command if the don't match? No sense in setting a load that is already where you want it.
It depends on the device $type. I'm writing motion sensors but there are rules/conventions for each type. I assume you have a dimmer. Odds are high that your device will subscribe to .homie/lt2000/aa-1/dim/set and the payload would be the level. All of the MQTT libraries I've seen allow multiple calls to subscribe(../../..) but all messages sent go to the same callback function. In there you need to check to see which topic you've got ...../dim/set or ../../onoff/set and do the right thing for your device. It's a big huge debugging distraction if your device publishes to a topic it's've subscribed to because you'll get an echo (and publish and echo and publish and infinite loop).
You can wildcard your subscriptions such that you get back the homie/lt2000/+/onoff/set or homie/lt2000/+/dim/set commands and use that earlier (+) topic level to establish which node (light) was addressed. Or even homie/lt2000/+/+/set and use the second wildcard to determine the command type.
I would recommend that locally you donât control the device via../set but of course report the state change back to .../onoff or .../dim.
It's a challenge to take Kevin's advice and mine and make sense of both because our terminology and perspective is slightly different. Both correct. Just don't subscribe to a topic you publish to - that causes grief for you, the device developer,
Actually it subscribes to just some of the homie topics for one configured device e.g. lt2000 but all nodes within that device. This is needed for discovery. I also only âwildcardâ subscribe to nodes that have $properties that I support and can import, e.g. onoff and dim. After discovery I unsubscribe from most of these topics.
With HomeAssistant discovery after completion I unsubscribe from all wildcarded topics and resubsrcribe to only the individual devices that the user has enabled. On homie I donât currently do that as completely but will do likely starting in beta 2. The specific topics I resubscribe to are all the ones that exist in âMQTT enabledâ devices that have a data entry ending in _Topic (these are auto created for you during discovery or user created for manual devices)
Also just to mention the homie specification does not define $type very well, if at all, and so Iâve invented my own $types. I also havenât used $type a lot and so many devices may have a default $type . I need to have more useful naming.
In beta 2 Iâve added a -device-driver topic at the node level that tells you what device driver HE is using. It could be used in the reverse way to inform HE which driver to use upon discovery but that is not a homie spec feature. I may implement that though. It would be useful if you linked two Hubitat hubs via MQTT for example.
But, I don't see a way around this. I need to see the set messages in both directions. If someone presses a button on the wall, I need to send a set command so the HE updates. If the HE needs to change a load, irlt sends a set command.
It might help to think about it as channels. If you device is controlled by hubitat:
HE-->MQTT-->your_device. (commands)
Your_device-->MQTT-->HE (status of commands)
A pair of channels (2 different MQTT Topics) for each attribute/sensor. Only one side should publish to a topic.
If your device just pushes status to HE, like a motion sensor or lux sensor then you only need one channel (topic) .
You can send json over a channel so that means you can pack whatever you like in a block of things but Kevin's Code will have a devil of a time doing what you want. Easier to write your own mqtt driver for HE if that's what you want. I've done that - it's not that hard UNTIL you start inventing heavier protocols on top of that - that's when you run into all kinds of race conditions - In my case I was way over-designing, over-thinking. Complexifing, if you will.
Ahh no. If someone presses a button on the wall switch the âstatusâ of the device on MQTT will change i.e. .../onoff or .../dim. You donât need to and shouldnât subscribe to .../set from HE. You should subscribe to the âstatusâ reporting topic only.
From HE you publish âcommandsâ to .../set. Of course the software/hardware that physically controls the device subscribes to .../set and then publishes the new state after change out to the âstatusâ topic .../onoff or .../dim which HE will see and can update its internal state e.g. on dasboard
Topics 'a/b/c' and 'a/b' are independent. either can be published to or subscribed to. What ties them together (barely together) is wild cards and conventions. Nothing more.
In Kevins code there are a lot of conventions - Homie and HAStatestream. There is another restriction - you can only talk to HE things with 'capabilities' which is roughly equivalent to Homie's 'properties'. There is a list of Capababilities allowed in Hubitat in the developer docs. Those are the only kind of things you can integrate into HE .
This is because HE doesnât have every capability built in not a restriction of the MQTT app, or if there are things I havenât implemented I can add them. What it does have covers most things though. My virtual devices are based on supporting every available HE Virtual Device plus variables and my own virtual text device. Some are still awaiting fuller implementation for example Virtual Thermostat and Virtual Omni.
But you can always import any MQTT payload into a variable in HE. All MQTT payloads are essentially text. What you might then do with that value is beyond the scope of this app. RM and moreso WC can be used to interpret the data and either resend it to another device or back out to MQTT via my app. Node-RED is ideally suited to massaging topics and payloads including json and supports MQTT really well.
I do not currently have an a ability to parse json payloads into separate values, so that would have to be done via another app, but I can get the json into a variable, and you can put json back into a variable or publish it back to any topic through the MQTT App.
What essentially the issue is is that there is no standardised way to represent complete devices on MQTT, like an amplifier or a thermostat. Even bulbs vary so mapping between HE devices and devices on other controllers like HA, OH, HS etc is not straightforward. That is what the two protocols HA Discovery and homie are attempting to address so MQTT becomes useful and standardised for device modelling.
Was also just going to mention that although OpenHAB and especially David Graef promote homie they only implement import into OH and do not export their devices in that format. People would have learned a lot about homie if they fully supported it birectionally.
I realise itâs to get people into OH rather than allow them out but itâs a rather selfish approach, albeit probably just a time/priority decision.
Hi,
I am a bit stuck with the MQTT App and homie protocol. All my devices are currently in Athom Homey and I am using the MQTT Hub to publish my devices. HE manage to find all devices and I select the once I want to include and hit done on the third settings page in the MQTT app.
The way I interpreted the instructions, child devices would be created automatically after this step but this does not happen. I have also not been able figure out how to create child devices manually based on the automatic inclusion.
The devices are discovered in HE ? I.e. they appear in the drop-downs and you then select individual devices within these, enable them and click done.. ?.. Nothing created ?
It could be the device categorisation for some devices but switches and dimmers should definitely work.
Could you post an expanded topic tree (using MQTT Explorer screengrab) of a light or similar and Iâll try it here.
Correct. I have had that issue for a number of weeks. I have seen them in the drop down, selected and hit done. Devices have never been created. I have seen the devices in the application setting screen under e.g. homie_sensor but no child devices have been created. I have tried to restart HE, have tried to delete and reinstall both the MQTT app and MQTT device, broadcast again from Homey etc and nothing have worked.
Today, when I checked all devices were now created without me doing any changes. I have no idea why (except to make me look bad since I finally gave up and created a post about my problem)
So too summarize, devices are now created but I don't know how and why. I have attached screenshots which have been the same since I first installed the MQTT app
Itâs always the way .. makes it hard to diagnose though.
However all the homie topics from Homey are incomplete as shown in that last screenshot. There are topics missing from every node and no status values or $properties reported like dim or onoff so something is wrong in the Athom Homey MQTT Hub app.
In other words, the /set should be on your device homie/lt2000/node/property.
