MQTT Homeassistant Component Integration

Hello everybody,
I’m using tools like zigbee2mqtt, zwave-js-ui or esphome to integrate other systems/devices. They all send their data to mqtt and I created generic MQTT Items manually in openhab.
Basically this works, but sometimes it would be nice if it would be “easier” to integrate such devices / items.
The MQTT Binding also offers the option to add an HomeAssistant MQTT Component, but in my case it only works well on simple devices like temperature sensor. Mostly some of the important channels are missing.
Don’t get me wrong, I’m happy that someone developed the MQTT binding and added the HomeAssistant Component, but in general it gives me the impression that it is a more experimental feature.
Are there any plans to get a more reliable integration of the HomeAssistant MQTT standard or API? Or perhaps I’ve configured something totally wrong?
thank you very much

3 Likes

As with everything in OH, any change or improvement requires someone to identify and report the problem an issue on GitHub and someone to implement the change.

I was under the impression that even HA was kind of phasing out their MQTT topic hierarchy standard (tasmota has already dropped it iirc) it, so this might not be something with fixing.

However, it does make sense to do auto discovery on the zigbee2mqtt standard perhaps. It just takes someone to volunteer to do it.

1 Like

This thread might be interesting to you

But isn’t HA already supporting the Tasmota standard?

Yes. It basically just flipped around, so that HA uses a standard maintained by Tasmota, instead of Tasmota supporting one of the many home-automation systems.

What MQTT auto discoveries is Openhab supporting?

I think the HA standard is deprecated as HA is also supporting the Tasmota standard. This makes actually sense, as a lot of devices can run Tasmota. There is also ESPEasy and ESPHome, but I have not idea what standard they are using.

Thats what I was trying to say above. Sorry if it wasn’t clear.

Only the deprecated HA, so effectively none. As Rich noted, we’ll only support the Tasmota standard when someone volunteers to add it.

I suspect that its a low priority for developers since MQTT works already. It would be great to have the convenience of autodiscovery, but its not an absolute necessity.

Well, OH supports Homie, ESP Milight, and Ruuvi standards in addition to HA. More could be added if there is someone to volunteer to implement them.

Right, I was just thinking of the “MQTT Binding”. I never think about those other ones since they’re separate.

They really aren’t separate. They are part of the MQTT binding.

Well, things I learned today. :wink:

I read this:

But missed the key word “extensions”.

An also very interesting approach is ESPhome. It has an alternative native API (not MQTT) and is fully integrated into HA.

Here is a very interesting discussion:

Somebody already started working on a ESPhome binding:

Maybe we should try to make an official ESPhome binding which is right in the OH core.

At the moment I have the feeling OH is somehow running out of developers and HA brings features first. A lot of developers focus on HA, which is interessting, because I think OH is the more powerful framework.

Thank you for the many information. I thought there is a standard of mqtt messages of homeassitent, which is used by zigbee2mqtt, zwavejs, esp home,… but this seems to be deprecated (in esp Home)
The esphome binding is very interesting. perhaps someday there is also a binding for zigbee2mqtt, zwavejs, … :slight_smile:

I am not familiar with HA and how it handles things. @kubawolanin made an integration for it a while ago: GitHub - kubawolanin/ha-openhab: WORK IN PROGRESS 🏠 openHAB custom integration for Home Assistant

Kuba can’t continue initial work, but from what he said me, it was really meant to bridge gap between both systems.

If you have specific issues with the mqtt.homeassistant binding in openHAB, please file them on GitHub. I know there are still some feature gaps and bugs, but I’ve put a lot of effort into improving it lately. I specifically run all the devices you mention - zwave-js-ui, zigbee2mqtt, ESPHome, and a couple other services that use MQTT and Home Assistant discovery.

As for HA’s MQTT “standard” being deprecated, I’ve seen no such thing. Zwave-js-ui has essentially deprecated its MQTT Home Assistant discovery, but they are still accepting 3rd party pull requests to improve it. ESPHome does prioritize the direct websocket Home Assistant connection, but there are only one or two features that are specific to that, and the rest work just as well over MQTT. Home Assistant itself continues to develop and evolve their MQTT support, with several new component types (many of which I’ve added to openHAB). The most frustrating thing to me is that it’s not actually a standard - there’s documentation on it on Home Assistant’s website, but there are often inaccuracies and a lot of vagueness on the expected behavior of lots of things. And those things change quite often - Home Assistant has no qualms about breaking changes. I basically target the “current” Home Assistant release as my yardstick of “compliance”. Sometimes that means combing through HA’s source code and/or running HA itself to see how it actually behaves.

As for a non-MQTT Home Assistant binding… yes, that could be a different avenue. That should be prioritized over an ESPHome specific binding (since ESPHome does not have a protocol of its own, it just uses HA’s protocol). But that would be a large undertaking, and would have many of the same issues that the mqtt.homeassistant binding has - a constantly moving target of compatibility with Home Assistant, and mapping Home Assistant’s entity and actions architecture onto openHAB’s channel architecture, with vastly differing data types. I’ve had good success with improving the current MQTT binding to get the vast majority of the functionality working, so don’t plan on investing the time necessary to develop a separate binding from scratch. Part of that is because for other devices I write my own handlers for, it’s much easier to write them in say Ruby, and communicate with MQTT and tacking on a bit of metadata, rather than conforming to Home Assistant’s proprietary protocol.

1 Like

Does zigbee2mqtt or zwave2mqtt support Homie? That at least is a standard.

No, neither support Homie. Homie is nice that it more closely maps to openHAB’s model with basic data types, but it also has had issues with the spec changing without having an actual release, and support for it is quite limited.