mqtt discovery standard - homie

[evilchen0815]

Hey there, im a big fan of this project as you made the milight bulbs usable. As you implemented the homeassistand MQTT standart, is there a chance to get the homie standard aswell? It looks quite more easy to implement and to use and (hehe) it fits in with openhab2.

https://homieiot.github.io/

[JMacIV]

Hey Tobi,

Can’t comment on Chris’ plans for Homie. But as far as OH2 goes, there is a binding for Chris’ hub already. Just wanted to send this in case you weren’t aware.

https://github.com/Skinah/EspMilightHub

https://community.openhab.org/t/espmilighthub-new-binding-for-milight-limitlessled-and-easybulb/39720

Sent from my iPhone

On Oct 7, 2020, at 10:14 AM, Tobi notifications@github.com wrote:

 Hey there, im a big fan of this project as you made the milight bulbs usable. As you implemented the homeassistand MQTT standart, is there a chance to get the homie standard aswell? It looks quite more easy to implement and to use and (hehe) it fits in with openhab2.

https://homieiot.github.io/

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[evilchen0815]

Hey Tobi, Can’t comment on Chris’ plans for Homie. But as far as OH2 goes, there is a binding for Chris’ hub already...

Hey JMacIV, i know this plugin and am using it ATM. But im not really happy with the implementation as it is a custom plugin and uses a custom mqtt binding aswell and both causing me trouble. Anyway the Usage of the Skinah Plugin is not that a charme as it looks. You could also try the Homeassistant support from OH2 but it aswell has its problems as it does not fit the HA specs in 100% (which i rednever will do and is kinda difficult to fit to) So The HA implementation in OH2 does not work for the espmilighthub.

I red a bit bout both standards. The HA standard aims to have all the configuration and states in one MQTT Message within a JSON String. The Homie standard splits it up in different messages within one topic (which stands for a device). As MQTT is as simple as possible, as i feel comfy with, having multiple short and clear messages within one topic sounds more easy to read and to configure than having one message with a json payload

/homeassistant/light/bulb_kitchen {lots_of_nested_configs_and_states_split_up_in_strings_numbers__and_["name:" "deeperlists"]}

/homie/bulb_kitchen/light/status ON
/homie/bulb_kitchen/light/color #0f7738
/homie/bulb_kitchen/light/effect flashing

I know, both don't fit the convention, but show the difference. As i understand it, homie gives ya the chance to simple ignore messages that don't fit your implementation. With homeassistant the string gets illegal then. And usually i subscribe to a topic, not only to a message. So a topic per device seems more clear to me.

[sidoh]

I think this is roughly the same request as #655.

In an ideal world, inbound and outbound MQTT message formats would be arbitrarily configurable. But that comes at the cost of complexity. Assuming a JSON format allows the code to stay simple, and is, I think, a pretty good balance of configurable and simple.

This is not something I envision pursuing.

I'm not sure I see a practical reason to avoid the larger MQTT messages, but you might consider using the updates topic instead of the state topic (see docs for further information).