search

xoseperez / espurna

Home automation firmware for ESP8266-based devices
http://tinkerman.cat
GNU General Public License v3.0
2.97k stars 635 forks source link

openHAB auto-discovery #1442

Open Misiu opened 5 years ago

Misiu commented 5 years ago

The recent version (2.4) has new MQTT binding that supports auto-discovery: https://www.openhab.org/blog/2018-12-16-mqtt-arrives-in-the-modern-openhab-2-x-architecture.html#mqtt-thing-auto-discovery.

Basically, openHAB is supporting two conventions:

HomeAssistant is supported but what do You think about Homie 3.x specification? Is there a chance to support it? This way adding new devices running ESPurna to openHAB would be much simpler.

Currently whole configuration must be done from code, with Homie support the same thing can be done from UI.

fab33 commented 5 years ago

It will be a great improvement. Especially because homie have a heartbeat function that you can easily use in openhab. Actually there is a PR to support homie 3.0 in @marvinroger repository.

Misiu commented 5 years ago

There is initial support for Homie 3.X for ESP8266 https://github.com/homieiot/homie-esp8266/pull/550 @mcspr do You think existing library should be used or should we add required changes to ESPurna?

mcspr commented 5 years ago

not sure. the convention itself is not that complicated and different from the current set of topics: https://homieiot.github.io/specification/ topic -> $topic being the main one, relay/light/button/etc. topics now being nodes

homie lib does a lot of other things and node classes seem to depend on them

peterhoeg commented 5 years ago

Having taken a quick look at it, the auto-discovery bits defined in homeassistant.ino are simple enough to change but the overall structure would have to change too which is more of a headache.

Since we advertise for HA where the various bits are found, can't we simply change the structure and just tell HA about the new location?

That way things would work for both.

mcspr commented 5 years ago

That way things would work for both.

Do you mean to re-use homeassistant discovery bits for homie integration running side-by-side?

peterhoeg commented 5 years ago

If this is already clear to everyone, then I apologise for stating the obvious, but I would like to ensure that we are all on the same page.

Homie is a convention for how to structure topics/nodes so that devices can be found.

HA auto discovery is a standard for how devices can advertise themselves but also containing full configuration details as the payload dropped into /homeassistant/component/device/config contains all the information that HA needs to fully configure the device.

So that makes the 2 rather different.

But the beauty of this is that they can actually co-exist.

  1. If we change to the Homie convention, the entire structure of topics need to change to follow the convention but this would be great for espurna (despite the obvious pain of changing the structure) as it would magically work with everything that does Homie.

  2. When we advertise to HA, we can simply advertise the new topics (as per the Homie convention) in which case HA will continue to work as normal but with the new structure.

mcspr commented 5 years ago

No need to apologise. It is an important thing to denote. And HASS discovery is weird. Essentially it is an addition to static yaml configuration, loaded on demand into the core though mqtt (same syntax and key-values and can even be instantly removed or replaced)

The largest part of HA module deals with bundling all of available information for some specific thing, like switches, and sending it somewhere else. Right now it only prints such config to json or console, but my though was that it may also be a basis to provide some translation between homie and the current way things, running side by side. (Maybe with some clever redirection, matching both topics)

But, it is probably easier just to change the core mqtt management (mqttTopic(...) results, root topic, subscriptions etc.) instead of doing it that way. And we don't necessarily need to up and replace current mqtt output with homie, if mqtt module is modified to provide data for both conventions.

HA module specifically should only care about mqtt endpoints; mqttTopic(relay,0) might as well return a boolean property topic of specific node and add configuration hint that it wants true/false instead of 1/0.

I did end up using docker openhab/openhab 2.4 to check things out. HASS discovery does not really work well, unlike homie :/ Status discovery is janky for some reason

Regarding openhab specifics, one bit in particular is mapping of homie properties to the UI things (and channels?): https://github.com/openhab/openhab2-addons/blob/de3ce25fb17bdf8a5670e8e381e3ea2d3a3c9b7f/bundles/org.openhab.binding.mqtt.homie/src/main/java/org/openhab/binding/mqtt/homie/internal/homie300/Property.java#L160 and some magic values are sometimes matched with internal types: https://github.com/openhab/openhab2-addons/blob/de3ce25fb17bdf8a5670e8e381e3ea2d3a3c9b7f/bundles/org.openhab.binding.mqtt.homie/src/main/java/org/openhab/binding/mqtt/homie/internal/homie300/Property.java#L144

And even without openhab running, this tool can verify topics: https://homieiot.github.io/tools/

peterhoeg commented 5 years ago

But, it is probably easier just to change the core mqtt management (mqttTopic(...) results, root topic, subscriptions etc.) instead of doing it that way. And we don't necessarily need to up and replace current mqtt output with homie, if mqtt module is modified to provide data for both conventions.

I have done some work on it and automatic discovery of espurna devices now work from openHAB. Currently I'm basically overwriting a bunch of topics as part of this (the homie specific functionality has been split into a separate homie.ino file though) to make things as easy as possible as a proof of concept, but I will split it out and make this work properly as I would like all my espurna devices to work out of the box with openHAB.

I am on purpose targeting the unreleased v4.0 spec for a few reasons:

  1. It is much smaller than v3, and
  2. While OH technically supports 3.0.0, the implementation is "skewed" towards v4.0 as it basically disregards a number of topics that are technically required

I would very much like to have espurna have first class support for Homie and hopefully make espurna the recommended firmware for openHAB deployments.

Cc: @davidgraeff

peterhoeg commented 4 years ago

Quick update for those tracking this issue.

As mentioned above, I have basic auto-discovery of sensors working (and config via the web UI) but have decided my approach isn't quite right as it wouldn't properly co-exist with other schemes (HA and people's own structure), so I went back to the drawing board for a cleaner design. Don't have an awful lot of free time these next few weeks but will try to fit in as much as possible.

mcspr commented 4 years ago

@peterhoeg any updates so far? in any case, you can ping me on gitter channel / directly or telegram, if you have problems with mqtt integration integrating with homie and something should be changed to remedy that

peterhoeg commented 4 years ago

Unfortunately not. It's not that I'm stuck but simply a lack of time. The current iteration works (as mentioned) although it basically overrides the HA stuff and a few things are hardcoded that really shouldn't be. The current version is deployed on a nodeMCU attached to a breadboard with a temp sensor in addition to a few sonoff devices but I really want to do this properly. I appreciate the offer!