Seems that MQTT 2.4 HOMIE discovery completely ignores $stats/+ topics.
IMHO it’s must have feature to autodiscover as channels topics like $stats/uptime, $stats/battery, $stats/signal etc. or everything that is listed in $stats (as stated in https://homieiot.github.io/# Spec 6.2.3).
Also it will be nice to have possibility to specify globally or per broker custom HOMIE topic prefix which is used for things auto discovery.
openHAB implements what will become Homie 4, which you can find here: https://homieiot.github.io/specification/spec-core-develop/
Homie 4 doesn’t have those $stats attributes anymore.
Regarding the prefix: As of Homie 4, the prefix is not required to be “homie” anymore. Controllers will find devices by subscribing to “+/+/$homie” instead.
Thanks for explanation!
In case openHAB implements Homie 4.0 there are several bugs/inconsistencies in 2.4.0 release.
Everything in UI, docs and your blog post 
talks about Homie v3
Devices publishing something/something/$nomie are not autodiscovered, only homie/something/$homie are.
Seems that thing “status check” in openHAB relies on looking for regular $stats/interval messages which are not present in Homie 4
Homie 4 is not released yet, of course the docs say 3.0, but that doesn’t change that I think homie 3 arrays and $stats are of no use in how they are specified and all homie maintainers agreed and they got removed in 4.
Yes $stats/interval is considered. Please either send it and then stick to the published period or the device goes offline, or just don’t send it and it will not have any influence.
2 Likes
Have you noticed any performance issues? Seems like we are working on the same
I have also been trying to implement the homie 3 (4) standard on a ESP8266 running a DHT22 sensor. With a heartbeat of 3 seconds my RPI is working “fulltime” processing the datastream 
If you republish homie topics like “nodes” or “properties”, openHAB will rebuild the internal representation each time. If you just publish property values, the processing should be minimal only. The value is received, transformed, converted to an openHAB command and published to the framework.
Makes sense. Will try to clean my dirty code a little 
Thanks for input and patience…
@Tommy_Lian could You share Your code? I want to build Homie 3 (4 
) compatible device based on ESP8266 so anything I could use as a base would help a lot!
Why don’t you use the official Homie esp8266 project? There is a branch in the repository for Homie 3. I haven’t talked to the others if the plan is to make the V3 branch the default one at some point.
1 Like
For simple devices this would be fine, but I want to add support for Homie to ESPurna (https://github.com/xoseperez/espurna/issues/1442) so instead of adding beta library I would like to add just the missing parts here and there.
ESPurna already has MQTT support so I think adding another library will increase bin size.
Do that from scratch in ESpurna instead. You just need to publish a few additional topics to be Homie compliant. Other code will not help you much here, I guess.
Can openHAB publish its own devices out using the Homie MQTT spec so that other Homie compliant software can use them ?
No. openHAB is a homie controller only so far. But a pull request to add that functionally is welcome.
Now when Homie 4 and org.homie.legacy-stats extension are defined are there any plans to implement org.homie.legacy-stats in openHab and make $stats values available as channels of Homie thing? Or it will never be done and for use with openHab necessary device information must be published as ordinary nodes/properties?
@David_Graeff with the release of Homie 4 - Will the OH MQTT binding be able to use tags to properly create items (ie lights) with a dimmer item rather than a number?
Not yet. At the moment there is a bug triage ongoing and the homeassistant part is again massively improved. The Homie extension for Tagging is further down on the list.
Cheers, David