# MQTT Homeassistant Component Integration

**URL:** <https://community.openhab.org/t/mqtt-homeassistant-component-integration/151341>\
**Category:** Bindings\
**Created:** [November 18, 2023, 1:12pm UTC](https://community.openhab.org/t/mqtt-homeassistant-component-integration/151341 "2023-11-18T13:12:56Z")\
**Posts on this page:** 17\
**Page:** 1

<div class="post-metadata">

**Author:** ![chris3](https://community.openhab.org/user_avatar/community.openhab.org/chris3/32/93913_2.png) [@chris3](https://community.openhab.org/u/chris3)\
**Post date:** [November 18, 2023, 1:12pm UTC](https://community.openhab.org/t/mqtt-homeassistant-component-integration/151341/1 "2023-11-18T13:12:56Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![rlkoshak](https://community.openhab.org/user_avatar/community.openhab.org/rlkoshak/32/75251_2.png) [@rlkoshak](https://community.openhab.org/u/rlkoshak)\
**Post date:** [November 18, 2023, 5:16pm UTC](https://community.openhab.org/t/mqtt-homeassistant-component-integration/151341/2 "2023-11-18T17:16:22Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![Andrew\_Rowe](https://community.openhab.org/user_avatar/community.openhab.org/andrew_rowe/32/37075_2.png) [@Andrew\_Rowe](https://community.openhab.org/u/Andrew_Rowe)\
**Post date:** [November 18, 2023, 5:27pm UTC](https://community.openhab.org/t/mqtt-homeassistant-component-integration/151341/3 "2023-11-18T17:27:29Z")

</div>

This thread might be interesting to you

> [@ESPHome binding for the Native API \[4.0.0;6.0.0)](https://community.openhab.org/t/esphome-binding-for-the-native-api/146849):
>
> [logo] Binding that communicates with ESPHome flashed devices using the api protocol as an alternative to mqtt. NOTE: Ensure that the Bluetooth binding is installed on your system as well, or the binding will not start. [Latest OH jars can be found here](https://github.com/seime/openhab-esphome/releases/download/latest_oh4/no.seime.openhab.binding.esphome-4.1.0-SNAPSHOT.jar) (same jar runs on both OH4 and OH5, don’t be confused with the release name nor artifact version) [README](https://github.com/seime/openhab-esphome#esphome-native-api-binding)[[beer\_me]](https://buymeacoffee.com/arnes) Note that the binding is continously updated, but the changelog below will only be updated in case of breaking or notable chan…

---

<div class="post-metadata">

**Author:** ![STSC](https://community.openhab.org/letter_avatar_proxy/v4/letter/s/f14d63/32.png) [@STSC](https://community.openhab.org/u/STSC)\
**Post date:** [November 18, 2023, 5:51pm UTC](https://community.openhab.org/t/mqtt-homeassistant-component-integration/151341/4 "2023-11-18T17:51:04Z")

</div>

> [@rlkoshak](#):
>
> 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.

But isn’t HA already supporting the Tasmota standard?

---

<div class="post-metadata">

**Author:** ![rpwong](https://community.openhab.org/user_avatar/community.openhab.org/rpwong/32/36036_2.png) [@rpwong](https://community.openhab.org/u/rpwong)\
**Post date:** [November 18, 2023, 8:24pm UTC](https://community.openhab.org/t/mqtt-homeassistant-component-integration/151341/5 "2023-11-18T20:24:03Z")

</div>

> [@STSC](#):
>
> 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.

---

<div class="post-metadata">

**Author:** ![STSC](https://community.openhab.org/letter_avatar_proxy/v4/letter/s/f14d63/32.png) [@STSC](https://community.openhab.org/u/STSC)\
**Post date:** [November 18, 2023, 8:45pm UTC](https://community.openhab.org/t/mqtt-homeassistant-component-integration/151341/6 "2023-11-18T20:45:45Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![rpwong](https://community.openhab.org/user_avatar/community.openhab.org/rpwong/32/36036_2.png) [@rpwong](https://community.openhab.org/u/rpwong)\
**Post date:** [November 18, 2023, 9:34pm UTC](https://community.openhab.org/t/mqtt-homeassistant-component-integration/151341/7 "2023-11-18T21:34:23Z")

</div>

> [@STSC](#):
>
> I think the HA standard is deprecated as HA is also supporting the Tasmota standard.

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

> [@STSC](#):
>
> What MQTT auto discoveries is Openhab supporting?

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.

---

<div class="post-metadata">

**Author:** ![rlkoshak](https://community.openhab.org/user_avatar/community.openhab.org/rlkoshak/32/75251_2.png) [@rlkoshak](https://community.openhab.org/u/rlkoshak)\
**Post date:** [November 19, 2023, 1:57am UTC](https://community.openhab.org/t/mqtt-homeassistant-component-integration/151341/8 "2023-11-19T01:57:30Z")

</div>

> [@rpwong](#):
>
> so effectively none

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.

---

<div class="post-metadata">

**Author:** ![rpwong](https://community.openhab.org/user_avatar/community.openhab.org/rpwong/32/36036_2.png) [@rpwong](https://community.openhab.org/u/rpwong)\
**Post date:** [November 19, 2023, 4:17am UTC](https://community.openhab.org/t/mqtt-homeassistant-component-integration/151341/9 "2023-11-19T04:17:18Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![rlkoshak](https://community.openhab.org/user_avatar/community.openhab.org/rlkoshak/32/75251_2.png) [@rlkoshak](https://community.openhab.org/u/rlkoshak)\
**Post date:** [November 19, 2023, 4:57am UTC](https://community.openhab.org/t/mqtt-homeassistant-component-integration/151341/10 "2023-11-19T04:57:24Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![rpwong](https://community.openhab.org/user_avatar/community.openhab.org/rpwong/32/36036_2.png) [@rpwong](https://community.openhab.org/u/rpwong)\
**Post date:** [November 19, 2023, 5:38am UTC](https://community.openhab.org/t/mqtt-homeassistant-component-integration/151341/11 "2023-11-19T05:38:53Z")

</div>

Well, things I learned today. 😉

I read this:

 ![image](https://community-openhab-org.s3.dualstack.eu-central-1.amazonaws.com/original/3X/1/0/103334df606b09e7174a7cee2c510109969a40d4.png)

But missed the key word “extensions”.

---

<div class="post-metadata">

**Author:** ![STSC](https://community.openhab.org/letter_avatar_proxy/v4/letter/s/f14d63/32.png) [@STSC](https://community.openhab.org/u/STSC)\
**Post date:** [November 19, 2023, 7:56am UTC](https://community.openhab.org/t/mqtt-homeassistant-component-integration/151341/12 "2023-11-19T07:56:06Z")

</div>

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:

> **[Goodbye Tasmota](https://community.home-assistant.io/t/goodbye-tasmota/436293/10)**
>
> Maybe you want to ask the question differently like: What makes a modern approach better than the 23 year old MQTT 🦕 Much more efficient: ESPHome encodes all messages in a highly optimized format with protocol buffers - for example binary...

Somebody already started working on a ESPhome binding:

> [@ESPHome binding for the Native API \[4.0.0;6.0.0)](https://community.openhab.org/t/esphome-binding-for-the-native-api/146849):
>
> [logo] Binding that communicates with ESPHome flashed devices using the api protocol as an alternative to mqtt. NOTE: Ensure that the Bluetooth binding is installed on your system as well, or the binding will not start. [Latest OH jars can be found here](https://github.com/seime/openhab-esphome/releases/download/latest_oh4/no.seime.openhab.binding.esphome-4.1.0-SNAPSHOT.jar) (same jar runs on both OH4 and OH5, don’t be confused with the release name nor artifact version) [README](https://github.com/seime/openhab-esphome#esphome-native-api-binding)[[beer\_me]](https://buymeacoffee.com/arnes) Note that the binding is continously updated, but the changelog below will only be updated in case of breaking or notable chan…

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.

---

<div class="post-metadata">

**Author:** ![chris3](https://community.openhab.org/user_avatar/community.openhab.org/chris3/32/93913_2.png) [@chris3](https://community.openhab.org/u/chris3)\
**Post date:** [November 19, 2023, 8:51am UTC](https://community.openhab.org/t/mqtt-homeassistant-component-integration/151341/13 "2023-11-19T08:51:54Z")

</div>

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, … 🙂

---

<div class="post-metadata">

**Author:** ![splatch](https://community.openhab.org/user_avatar/community.openhab.org/splatch/32/33925_2.png) [@splatch](https://community.openhab.org/u/splatch)\
**Post date:** [November 19, 2023, 4:45pm UTC](https://community.openhab.org/t/mqtt-homeassistant-component-integration/151341/14 "2023-11-19T16:45:15Z")

</div>

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](https://github.com/kubawolanin/ha-openhab)

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

---

<div class="post-metadata">

**Author:** ![ccutrer](https://community.openhab.org/user_avatar/community.openhab.org/ccutrer/32/73828_2.png) [@ccutrer](https://community.openhab.org/u/ccutrer)\
**Post date:** [January 29, 2024, 5:18pm UTC](https://community.openhab.org/t/mqtt-homeassistant-component-integration/151341/15 "2024-01-29T17:18:06Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![rlkoshak](https://community.openhab.org/user_avatar/community.openhab.org/rlkoshak/32/75251_2.png) [@rlkoshak](https://community.openhab.org/u/rlkoshak)\
**Post date:** [January 29, 2024, 5:22pm UTC](https://community.openhab.org/t/mqtt-homeassistant-component-integration/151341/16 "2024-01-29T17:22:08Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![ccutrer](https://community.openhab.org/user_avatar/community.openhab.org/ccutrer/32/73828_2.png) [@ccutrer](https://community.openhab.org/u/ccutrer)\
**Post date:** [January 29, 2024, 6:05pm UTC](https://community.openhab.org/t/mqtt-homeassistant-component-integration/151341/17 "2024-01-29T18:05:56Z")

</div>

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.
