Zigbee2mqtt integration quality

[TAKeanice (Tassilo Karge)]

The Zigbee2mqtt GitHub readme https://github.com/Koenkk/zigbee2mqtt mentions several integrations of Zigbee2mqtt into smart home platforms. OpenHAB is not amongst them.

First a disclaimer: I have not yet looked into what makes those integrations special. But independent of that, I think there are many things that could be improved upon in the current integration of Zigbee2mqtt with OpenHAB.
I´d like to have you add your thoughts, critique my points or express your support, so we can come up with a comprehensive list of ideas.

1. Thing creation

So far, Zigbee2mqtt is mostly standalone, offers a separate webui, pushes things over MQTT to OpenHAB and only if it is in the HomeAssistant format, OpenHAB recognizes the structure and allows to create things automatically. Otherwise, the process is fully manual. The purpose of Things to decouple physical devices from logical information is performed redundantly, once by the devices in Zigbee2mqtt and then by OpenHAB.

2. UI integration

The Zigbee2mqtt UI is completely separate from the OpenHAB UI. Switching back and forth is tedious. Additionally, it is not forwarded through myopenhab, making it unaccessible remotely.

3. Status information and logs

In OpenHAB, the status information or logs from Zigbee2mqtt are not visible, debugging becomes a scavenger hunt along the chain of dependencies, i.e. the device, the Zigbee adapter, Zigbee2mqtt, the mqtt provider, and OpenHAB. At least some steps within the hunt could be improved by tighter integration like showing the status of Zigbee2mqtt and the Zigbee adapter in OpenHAB, incorporating the device status into the Thing status.

These are just the first few thoughts I have on this, and I will probably add to them after I drew inspiration from how the integration with other systems looks like. I would love OpenHAB to be on the “notable integrations” list of Zigbee2mqtt!

[TAKeanice (Tassilo Karge)]

I let Claude research on what makes some other integrations “notable”, and think the best path to go would be a dedicated Z2M binding with some features that a generic mqtt binding does not have, like

• Auto-discovery of things also without the homeassistant convention, including device name, type etc.
• Integration of Z2M groups
• Renaming Z2M devices from OpenHAB and adopting names when they change in Z2M
• Stateless triggers for buttons like remote buttons etc.
• UI integration

[Oggerschummer (Thomas)]

Some small comment as you asked for opinions: I really like having z2m as a separate tool.

• First of all OH is not the only client for my devices. So using mqtt as common integration protocol is beneficial.
• Z2m gives me exactly the level of segregation prefered , has a large community and supports new devices fast. And I’m to a high degree not depending on OH release cycles.
• Even when openHAB is down for any reason I still have an UI I can use to control things. A big plus.
• As a specialized solution it has all the tools required when it starts getting tricky, no need to rebuild in OH. As soon as things work in z2m it is only the mqtt connection with OH or others you have to deal with. Smooth experience (at least for me up to now, depends on your requirements) , hiding the implementation details for hardware from clients like OH.

Where I struggle a bit is the discovery part, this tends to propose/rediscover duplicates for existing things with different IDs which can become a mess.

But overall I really enjoy the integration as is, autodiscovery has made very good progress in OH. Tighter coupling with OH you get with the zigbee binding I’d say.

[Larsen (Locke)]

@TAKeanice

OpenHAB is not amongst them.

The installation for openHAB is described on the Zigbee2MQTT website (which unfortunately seems to be down at the moment). GitHub is mainly aimed at developers, and koenkk likely didn’t update it after we created the installation in openHABian.

The way openHAB integrates Zigbee2MQTT should be quite similar to Home Assistant, since we simply rely on HA’s auto-detection. However, Zigbee2MQTT naturally has a stronger focus on Home Assistant, as the developer koenkk uses it himself—and unfortunately not openHAB.

Zigbee2MQTT is an external system. Like any external system, it comes with its own data model—this is true for almost all integrations.

Please keep in mind: the tighter the integration is supposed to be, the higher the effort becomes—for example, when dealing with new major releases.

[TAKeanice (Tassilo Karge)]

I appreciate your opinion, thanks for commenting!

Z2m gives me exactly the level of segregation prefered , has a large community and supports new devices fast. And I’m to a high degree not depending on OH release cycles.

I appreciate that part, too, which is why I am using it. However, the standalone tool could be integrated more tightly with OpenHAB through a binding, don´t you think? The way I am imagining is rather a sync than a full integration (for names, for example, or for discovered devices to propose them as things). I have seen bindings achieve that via an own “Thing” for the connection configuration, like the “MQTT Broker” thing or the “Matter Coordinator”.

What do you think about an integration in that way? And what is your opinion on the added OH features like stateless triggers and displaying the status of Z2M, its logs and devices?

Also, the Z2M site is down since yesterday - I was able to look up the Bilresa remote when I was at an IKEA, and one hour later I was not any more. But it´s powered by a GitHub repo - zigbee2mqtt.io/docs/devices/E2490.md at master · Koenkk/zigbee2mqtt.io · GitHub - which you can reference to if you want to show me anything there.

[rlkoshak (Rich Koshak)]

A couple of things worth mentioning.

1. OH uses the actual Home Assistant Python code to do the discovery. So OH’s discovery and use of Z2M MQTT devices should be near parity with what HA provides since we are using the same code. But creating a new separate binding will not address this concern. Things still decouple the physical devices in Z2M and in OH evne if there is a dedicated binding.
2. ZWaveUI JS is very similar to Zigbee2MQTT and there is a separate binding for it. And the separate UI issue does not change. There are still many things that can only be done in the Zwave UI JS UI that cannot be done in OH.
3. A dedicated binding is not going to address this issue at all. It might provide more detailed information to OH’s logs.

@TAKeanice

• Auto-discovery of things also without the homeassistant convention, including device name, type etc.
• Integration of Z2M groups
• Renaming Z2M devices from OpenHAB and adopting names when they change in Z2M
• Stateless triggers for buttons like remote buttons etc.
• UI integration

I’m not sure any of these would be possible even with a dedicated add-on except for the auto-dicovery (stateless triggers are already supported). OH implements Groups using Items and bindings are not allowed to manipulate Items (e.g. creating Group Items).

The names of Things and Items in OH are their UID. Changing their name means changing their UID which will break any links to that Thing. And the Thing’s name matters far less than the Item’s name and, like I said, a binding is not allowed to mess with Items in that way.

Zigbee2MQTT discovered HA Items already support stateless triggers.

UI integration will never be possible. OH is not a generic proxy. It can only directly expose though myopenhab.org stuff actually hosted by OH itself. Assuming that Zigbee2MQTT provides a robust enough API, a new UI could be created by OH in the new Z2M binding though.

@TAKeanice

I have seen bindings achieve that via an own “Thing” for the connection configuration, like the “MQTT Broker” thing or the “Matter Coordinator”.

That’s exactly how the Home Assitant MQTT binding does it today. The connection configuration is the MQTT Broker Thing. You could write a Zigbee2MQTT MQTT binding similar to the Home Assistant binding that discovers and configures Things based on the “native” Zigbee2MQTT MQTT standard, or if Zigbee2MQTT has some other API it could use that. But it’s still going to work pretty much exactly like the Home Assistant binding: Things will be discovered and placed in the inbox.

Definitly look at the ZWave UI JS add-on for an example of what a dedicated add-on might look in an almost identical situation.

And here is an examople of a Zigbee2MQTT discovered Thing with an Event Channnel (i.e. stateless trigger)

version: 1
things:
  homeassistant:device:broker:zigbee2mqtt_5F0x282c02bfffe8f86f:
    bridge: mqtt:broker:broker
    label: Rich's Button
    config:
      topics:
        - event/0x282c02bfffe8f86f/action
        - sensor/0x282c02bfffe8f86f/battery
        - sensor/0x282c02bfffe8f86f/linkquality
        - update/0x282c02bfffe8f86f/update
      basetopic: homeassistant
    channels:
      action:
        type: trigger
        label: Action
        config:
          component: event
          nodeid: 0x282c02bfffe8f86f
          objectid:
            - action
          config:
            - "{\"availability\":[{\"topic\":\"zigbee2mqtt/bridge/state\",\"value_template\":\"{{ value_json.state }}\"},{\"topic\":\"zigbee2mqtt/Rich's Button/availability\",\"value_template\":\"{{ value_json.state }}\"}],\"availability_mode\":\"all\",\"default_entity_id\":\"event.rich's_button_action\",\"device\":{\"hw_version\":0,\"identifiers\":[\"zigbee2mqtt_0x282c02bfffe8f86f\"],\"manufacturer\":\"Third Reality\",\"model\":\"Smart button\",\"model_id\":\"3RSB22BZ\",\"name\":\"Rich's Button\",\"sw_version\":\"v1.00.28\",\"via_device\":\"zigbee2mqtt_bridge_0xc02cedfffee9b626\"},\"event_types\":[\"single\",\"double\",\"hold\",\"release\"],\"icon\":\"mdi:gesture-double-tap\",\"name\":\"Action\",\"object_id\":\"rich's_button_action\",\"origin\":{\"name\":\"Zigbee2MQTT\",\"sw\":\"2.12.1\",\"url\":\"https://www.zigbee2mqtt.io\"},\"state_topic\":\"zigbee2mqtt/Rich's Button\",\"unique_id\":\"0x282c02bfffe8f86f_action_zigbee2mqtt\",\"value_template\":\"{% set patterns = [\\n{\\\"pattern\\\": '^(?P<button>(?:button_)?[a-z0-9]+)_(?P<action>(?:press|hold)(?:_release)?)$', \\\"groups\\\": [\\\"button\\\", \\\"action\\\"]},\\n{\\\"pattern\\\": '^(?P<action>recall|scene)_(?P<scene>[0-2][0-9]{0,2})$', \\\"groups\\\": [\\\"action\\\", \\\"scene\\\"]},\\n{\\\"pattern\\\": '^(?P<actionPrefix>region_)(?P<region>[1-9]|10)_(?P<action>enter|leave|occupied|unoccupied)$', \\\"groups\\\": [\\\"actionPrefix\\\", \\\"region\\\", \\\"action\\\"]},\\n{\\\"pattern\\\": '^(?P<action>dial_rotate)_(?P<direction>left|right)_(?P<speed>step|slow|fast)$', \\\"groups\\\": [\\\"action\\\", \\\"direction\\\", \\\"speed\\\"]},\\n{\\\"pattern\\\": '^(?P<action>brightness_step)(?:_(?P<direction>up|down))?$', \\\"groups\\\": [\\\"action\\\", \\\"direction\\\"]}\\n] %}\\n{% set action_value = value_json.action|default('') %}\\n{% set ns = namespace(r=[('action', action_value)]) %}\\n{% for p in patterns %}\\n  {% set m = action_value|regex_findall(p.pattern) %}\\n  {% if m[0] is undefined %}{% continue %}{% endif %}\\n  {% for key, value in zip(p.groups, m[0]) %}\\n    {% set ns.r = ns.r|rejectattr(0, 'eq', key)|list + [(key, value)] %}\\n  {% endfor %}\\n{% endfor %}\\n{% if (ns.r|selectattr(0, 'eq', 'actionPrefix')|first) is defined %}\\n  {% set ns.r = ns.r|rejectattr(0, 'eq', 'action')|list + [('action', ns.r|selectattr(0, 'eq', 'actionPrefix')|map(attribute=1)|first + ns.r|selectattr(0, 'eq', 'action')|map(attribute=1)|first)] %}\\n{% endif %}\\n{% set ns.r = ns.r + [('event_type', ns.r|selectattr(0, 'eq', 'action')|map(attribute=1)|first)] %}\\n{{dict.from_keys(ns.r|rejectattr(0, 'in', ('action', 'actionPrefix'))|reject('eq', ('event_type', None))|reject('eq', ('event_type', '')))|to_json}}\"}"
      linkquality:
        type: number-advanced
        label: Linkquality
        config:
          component: sensor
          nodeid: 0x282c02bfffe8f86f
          objectid:
            - linkquality
          config:
            - "{\"availability\":[{\"topic\":\"zigbee2mqtt/bridge/state\",\"value_template\":\"{{ value_json.state }}\"},{\"topic\":\"zigbee2mqtt/Rich's Button/availability\",\"value_template\":\"{{ value_json.state }}\"}],\"availability_mode\":\"all\",\"default_entity_id\":\"sensor.rich's_button_linkquality\",\"device\":{\"hw_version\":0,\"identifiers\":[\"zigbee2mqtt_0x282c02bfffe8f86f\"],\"manufacturer\":\"Third Reality\",\"model\":\"Smart button\",\"model_id\":\"3RSB22BZ\",\"name\":\"Rich's Button\",\"sw_version\":\"v1.00.28\",\"via_device\":\"zigbee2mqtt_bridge_0xc02cedfffee9b626\"},\"enabled_by_default\":false,\"entity_category\":\"diagnostic\",\"icon\":\"mdi:signal\",\"name\":\"Linkquality\",\"object_id\":\"rich's_button_linkquality\",\"origin\":{\"name\":\"Zigbee2MQTT\",\"sw\":\"2.12.1\",\"url\":\"https://www.zigbee2mqtt.io\"},\"state_class\":\"measurement\",\"state_topic\":\"zigbee2mqtt/Rich's Button\",\"unique_id\":\"0x282c02bfffe8f86f_linkquality_zigbee2mqtt\",\"unit_of_measurement\":\"lqi\",\"value_template\":\"{{ value_json[\\\"linkquality\\\"] }}\"}"
      battery:
        type: number
        label: MQTT Sensor
        config:
          component: sensor
          nodeid: 0x282c02bfffe8f86f
          objectid:
            - battery
          config:
            - "{\"availability\":[{\"topic\":\"zigbee2mqtt/bridge/state\",\"value_template\":\"{{ value_json.state }}\"},{\"topic\":\"zigbee2mqtt/Rich's Button/availability\",\"value_template\":\"{{ value_json.state }}\"}],\"availability_mode\":\"all\",\"default_entity_id\":\"sensor.rich's_button_battery\",\"device\":{\"hw_version\":0,\"identifiers\":[\"zigbee2mqtt_0x282c02bfffe8f86f\"],\"manufacturer\":\"Third Reality\",\"model\":\"Smart button\",\"model_id\":\"3RSB22BZ\",\"name\":\"Rich's Button\",\"sw_version\":\"v1.00.28\",\"via_device\":\"zigbee2mqtt_bridge_0xc02cedfffee9b626\"},\"device_class\":\"battery\",\"enabled_by_default\":true,\"entity_category\":\"diagnostic\",\"object_id\":\"rich's_button_battery\",\"origin\":{\"name\":\"Zigbee2MQTT\",\"sw\":\"2.12.1\",\"url\":\"https://www.zigbee2mqtt.io\"},\"state_class\":\"measurement\",\"state_topic\":\"zigbee2mqtt/Rich's Button\",\"unique_id\":\"0x282c02bfffe8f86f_battery_zigbee2mqtt\",\"unit_of_measurement\":\"%\",\"value_template\":\"{{ value_json[\\\"battery\\\"] }}\"}"

Look for the “componet: event”. An event trigger is a stateless trigger. You cannot link this Channel to an Item (without a profile). You use this Channnel to directly trigger a Rule.

[TAKeanice (Tassilo Karge)]

Thank you, these are valuable hints and caveats. (sorry for sounding like AI, I assure you that all this is hand-written!)

ZWaveUI JS is very similar to Zigbee2MQTT and there is a separate binding for it. And the separate UI issue does not change. There are still many things that can only be done in the Zwave UI JS UI that cannot be done in OH.

I´ll have to check out the technical limitations here. Maybe I can completely relay the Z2M UI through the OH UI, or start a separate UI instance within a binding - we´ll see. Maybe I can also just add some actions to a Z2M Broker Thing, like the Matter Controller has, for frequent actions like starting pairing mode for example.

A dedicated binding is not going to address this issue at all. It might provide more detailed information to OH’s logs.

So, if it can provide more information to the logs, why can´t it address the issue? And why couldn´t it relay some information from the Z2M API or from what it posts to MQTT to the status of a thing (i.e. ONLINE, ERROR or something like this)?

Changing their name means changing their UID which will break any links to that Thing

Right, I didn´t consider that. But the display label should be changeable, and if a name changes in Z2M, that means the channels have to be reconfigured. Automating that could already be progress.

Look for the “componet: event”. An event trigger is a stateless trigger. You cannot link this Channel to an Item (without a profile). You use this Channnel to directly trigger a Rule.

Yes, I did not fully analyze that issue. It can definitely not be solved by a binding. What I am referring to is that there is no base item type for a “button”, and no item that registers the presses of one (for statistics etc.). Rollershutter and some others have button-like commands, but buttons appear in so many additional contexts (like sending a single command to a IR-remote). So I fell like that´s a missing OH functionality in general.

[sihui]

@TAKeanice

starting pairing mode

Easy to solve in openHAB:

See:

OH3 Zigbee2MQTT - Permit Join with Auto Off

Posting since i couldn’t find this specifically listed in anyother topic posts, here’s a quick one for anyone else looking at doing the same. Toggle button for permit join using GUI interface (not textfile configured. For general background - I use zigbee2mqtt in home assistant mode for mqtt auto discovery. If you’re not familiar with configuring any of that, recommended readings include : openHAB and zigbee2mqtt Tutorial for Beginners - how to configure zigbee2mqtt for general setup, althou…

[jimtng]

@sihui

Easy to solve in openHAB:

I set mine up a long time ago and used the json format and never looked at it again. It was before the simplified syntax was available. I just tried it now and indeed it can accept either syntax! TIL!

Or you could send that mqtt message directly from a script.
Either way works. It’s just plain mqtt.

Example Ruby script:

z2m_permit_join = "zigbee2mqtt/bridge/request/permit_join"
things["mqtt:broker:mybroker"].publish_mqtt(z2m_permit_join, "254") # 254 is the max allowed, and must be a string

# Or use the alternative syntax:
mqtt_broker_mybroker.publish_mqtt(z2m_permit_join, "254")

[rlkoshak (Rich Koshak)]

@TAKeanice

Maybe I can completely relay the Z2M UI through the OH UI

Not outside your LAN you can’t.

@TAKeanice

Maybe I can also just add some actions to a Z2M Broker Thing, like the Matter Controller has, for frequent actions like starting pairing mode for example.

Zigbee2MQTT supports controlling things like pairing mode and such through MQTT messages. In fact, OH should have discovered a Zigbee2MQTT Bridge Thing among all other devices which has a Channel to enable pairing mode, among other Channels:

version: 1
things:
  homeassistant:device:broker:zigbee2mqtt_5Fbridge_5F0xc02cedfffee9b626:
    bridge: mqtt:broker:broker
    label: Zigbee2MQTT Bridge
    config:
      topics:
        - binary_sensor/1221051039810110150109113116116_0xc02cedfffee9b626/connection_state
        - binary_sensor/1221051039810110150109113116116_0xc02cedfffee9b626/restart_required
        - button/1221051039810110150109113116116_0xc02cedfffee9b626/restart
        - select/1221051039810110150109113116116_0xc02cedfffee9b626/log_level
        - sensor/1221051039810110150109113116116_0xc02cedfffee9b626/coordinator_version
        - sensor/1221051039810110150109113116116_0xc02cedfffee9b626/network_map
        - sensor/1221051039810110150109113116116_0xc02cedfffee9b626/version
        - switch/1221051039810110150109113116116_0xc02cedfffee9b626/permit_join
      basetopic: homeassistant
    channels:
      connection_state:
        type: switch
        label: Connection state
        config:
          component: binary_sensor
          nodeid: 1221051039810110150109113116116_0xc02cedfffee9b626
          objectid:
            - connection_state
          config:
            - "{\"default_entity_id\":\"binary_sensor.zigbee2mqtt_bridge_connection_state\",\"device\":{\"hw_version\":\"EmberZNet 8.0.2 [GA]\",\"identifiers\":[\"zigbee2mqtt_bridge_0xc02cedfffee9b626\"],\"manufacturer\":\"Zigbee2MQTT\",\"model\":\"Bridge\",\"name\":\"Zigbee2MQTT Bridge\",\"sw_version\":\"2.12.1\"},\"device_class\":\"connectivity\",\"entity_category\":\"diagnostic\",\"name\":\"Connection state\",\"object_id\":\"zigbee2mqtt_bridge_connection_state\",\"origin\":{\"name\":\"Zigbee2MQTT\",\"sw\":\"2.12.1\",\"url\":\"https://www.zigbee2mqtt.io\"},\"payload_off\":\"offline\",\"payload_on\":\"online\",\"state_topic\":\"zigbee2mqtt/bridge/state\",\"unique_id\":\"bridge_0xc02cedfffee9b626_connection_state_zigbee2mqtt\",\"value_template\":\"{{ value_json.state }}\"}"
      coordinator_version:
        type: string-advanced
        label: Coordinator version
        config:
          component: sensor
          nodeid: 1221051039810110150109113116116_0xc02cedfffee9b626
          objectid:
            - coordinator_version
          config:
            - "{\"availability\":[{\"topic\":\"zigbee2mqtt/bridge/state\",\"value_template\":\"{{ value_json.state }}\"}],\"availability_mode\":\"all\",\"default_entity_id\":\"sensor.zigbee2mqtt_bridge_coordinator_version\",\"device\":{\"hw_version\":\"EmberZNet 8.0.2 [GA]\",\"identifiers\":[\"zigbee2mqtt_bridge_0xc02cedfffee9b626\"],\"manufacturer\":\"Zigbee2MQTT\",\"model\":\"Bridge\",\"name\":\"Zigbee2MQTT Bridge\",\"sw_version\":\"2.12.1\"},\"enabled_by_default\":false,\"entity_category\":\"diagnostic\",\"icon\":\"mdi:chip\",\"name\":\"Coordinator version\",\"object_id\":\"zigbee2mqtt_bridge_coordinator_version\",\"origin\":{\"name\":\"Zigbee2MQTT\",\"sw\":\"2.12.1\",\"url\":\"https://www.zigbee2mqtt.io\"},\"state_topic\":\"zigbee2mqtt/bridge/info\",\"unique_id\":\"bridge_0xc02cedfffee9b626_coordinator_version_zigbee2mqtt\",\"value_template\":\"{{ value_json.coordinator.meta.revision }}\"}"
      log_level:
        type: string
        label: Log level
        config:
          component: select
          nodeid: 1221051039810110150109113116116_0xc02cedfffee9b626
          objectid:
            - log_level
          config:
            - "{\"availability\":[{\"topic\":\"zigbee2mqtt/bridge/state\",\"value_template\":\"{{ value_json.state }}\"}],\"availability_mode\":\"all\",\"command_template\":\"{\\\"options\\\": {\\\"advanced\\\": {\\\"log_level\\\": \\\"{{ value }}\\\" } } }\",\"command_topic\":\"zigbee2mqtt/bridge/request/options\",\"default_entity_id\":\"select.zigbee2mqtt_bridge_log_level\",\"device\":{\"hw_version\":\"EmberZNet 8.0.2 [GA]\",\"identifiers\":[\"zigbee2mqtt_bridge_0xc02cedfffee9b626\"],\"manufacturer\":\"Zigbee2MQTT\",\"model\":\"Bridge\",\"name\":\"Zigbee2MQTT Bridge\",\"sw_version\":\"2.12.1\"},\"entity_category\":\"config\",\"name\":\"Log level\",\"object_id\":\"zigbee2mqtt_bridge_log_level\",\"options\":[\"error\",\"warning\",\"info\",\"debug\"],\"origin\":{\"name\":\"Zigbee2MQTT\",\"sw\":\"2.12.1\",\"url\":\"https://www.zigbee2mqtt.io\"},\"state_topic\":\"zigbee2mqtt/bridge/info\",\"unique_id\":\"bridge_0xc02cedfffee9b626_log_level_zigbee2mqtt\",\"value_template\":\"{{ value_json.log_level | lower }}\"}"
      permit_join:
        type: switch
        label: Permit join
        config:
          component: switch
          nodeid: 1221051039810110150109113116116_0xc02cedfffee9b626
          objectid:
            - permit_join
          config:
            - "{\"availability\":[{\"topic\":\"zigbee2mqtt/bridge/state\",\"value_template\":\"{{ value_json.state }}\"}],\"availability_mode\":\"all\",\"command_topic\":\"zigbee2mqtt/bridge/request/permit_join\",\"default_entity_id\":\"switch.zigbee2mqtt_bridge_permit_join\",\"device\":{\"hw_version\":\"EmberZNet 8.0.2 [GA]\",\"identifiers\":[\"zigbee2mqtt_bridge_0xc02cedfffee9b626\"],\"manufacturer\":\"Zigbee2MQTT\",\"model\":\"Bridge\",\"name\":\"Zigbee2MQTT Bridge\",\"sw_version\":\"2.12.1\"},\"icon\":\"mdi:human-greeting-proximity\",\"name\":\"Permit join\",\"object_id\":\"zigbee2mqtt_bridge_permit_join\",\"origin\":{\"name\":\"Zigbee2MQTT\",\"sw\":\"2.12.1\",\"url\":\"https://www.zigbee2mqtt.io\"},\"payload_off\":\"{\\\"time\\\": 0}\",\"payload_on\":\"{\\\"time\\\": 254}\",\"state_off\":\"false\",\"state_on\":\"true\",\"state_topic\":\"zigbee2mqtt/bridge/info\",\"unique_id\":\"bridge_0xc02cedfffee9b626_permit_join_zigbee2mqtt\",\"value_template\":\"{{ value_json.permit_join | lower }}\"}"
      restart:
        type: string
        label: Restart
        config:
          component: button
          nodeid: 1221051039810110150109113116116_0xc02cedfffee9b626
          objectid:
            - restart
          config:
            - "{\"availability\":[{\"topic\":\"zigbee2mqtt/bridge/state\",\"value_template\":\"{{ value_json.state }}\"}],\"availability_mode\":\"all\",\"command_topic\":\"zigbee2mqtt/bridge/request/restart\",\"default_entity_id\":\"button.zigbee2mqtt_bridge_restart\",\"device\":{\"hw_version\":\"EmberZNet 8.0.2 [GA]\",\"identifiers\":[\"zigbee2mqtt_bridge_0xc02cedfffee9b626\"],\"manufacturer\":\"Zigbee2MQTT\",\"model\":\"Bridge\",\"name\":\"Zigbee2MQTT Bridge\",\"sw_version\":\"2.12.1\"},\"device_class\":\"restart\",\"name\":\"Restart\",\"object_id\":\"zigbee2mqtt_bridge_restart\",\"origin\":{\"name\":\"Zigbee2MQTT\",\"sw\":\"2.12.1\",\"url\":\"https://www.zigbee2mqtt.io\"},\"payload_press\":\"\",\"unique_id\":\"bridge_0xc02cedfffee9b626_restart_zigbee2mqtt\"}"
      restart_required:
        type: switch-advanced
        label: Restart required
        config:
          component: binary_sensor
          nodeid: 1221051039810110150109113116116_0xc02cedfffee9b626
          objectid:
            - restart_required
          config:
            - "{\"availability\":[{\"topic\":\"zigbee2mqtt/bridge/state\",\"value_template\":\"{{ value_json.state }}\"}],\"availability_mode\":\"all\",\"default_entity_id\":\"binary_sensor.zigbee2mqtt_bridge_restart_required\",\"device\":{\"hw_version\":\"EmberZNet 8.0.2 [GA]\",\"identifiers\":[\"zigbee2mqtt_bridge_0xc02cedfffee9b626\"],\"manufacturer\":\"Zigbee2MQTT\",\"model\":\"Bridge\",\"name\":\"Zigbee2MQTT Bridge\",\"sw_version\":\"2.12.1\"},\"device_class\":\"problem\",\"enabled_by_default\":false,\"entity_category\":\"diagnostic\",\"name\":\"Restart required\",\"object_id\":\"zigbee2mqtt_bridge_restart_required\",\"origin\":{\"name\":\"Zigbee2MQTT\",\"sw\":\"2.12.1\",\"url\":\"https://www.zigbee2mqtt.io\"},\"payload_off\":false,\"payload_on\":true,\"state_topic\":\"zigbee2mqtt/bridge/info\",\"unique_id\":\"bridge_0xc02cedfffee9b626_restart_required_zigbee2mqtt\",\"value_template\":\"{{ value_json.restart_required }}\"}"
      version:
        type: string
        label: Version
        config:
          component: sensor
          nodeid: 1221051039810110150109113116116_0xc02cedfffee9b626
          objectid:
            - version
          config:
            - "{\"availability\":[{\"topic\":\"zigbee2mqtt/bridge/state\",\"value_template\":\"{{ value_json.state }}\"}],\"availability_mode\":\"all\",\"default_entity_id\":\"sensor.zigbee2mqtt_bridge_version\",\"device\":{\"hw_version\":\"EmberZNet 8.0.2 [GA]\",\"identifiers\":[\"zigbee2mqtt_bridge_0xc02cedfffee9b626\"],\"manufacturer\":\"Zigbee2MQTT\",\"model\":\"Bridge\",\"name\":\"Zigbee2MQTT Bridge\",\"sw_version\":\"2.12.1\"},\"entity_category\":\"diagnostic\",\"icon\":\"mdi:zigbee\",\"name\":\"Version\",\"object_id\":\"zigbee2mqtt_bridge_version\",\"origin\":{\"name\":\"Zigbee2MQTT\",\"sw\":\"2.12.1\",\"url\":\"https://www.zigbee2mqtt.io\"},\"state_topic\":\"zigbee2mqtt/bridge/info\",\"unique_id\":\"bridge_0xc02cedfffee9b626_version_zigbee2mqtt\",\"value_template\":\"{{ value_json.version }}\"}"
      network_map#json-attributes:
        type: string-advanced
        label: JSON Attributes
        config:
          component: sensor
          nodeid: 1221051039810110150109113116116_0xc02cedfffee9b626
          objectid:
            - network_map
          config:
            - "{\"availability\":[{\"topic\":\"zigbee2mqtt/bridge/state\",\"value_template\":\"{{ value_json.state }}\"}],\"availability_mode\":\"all\",\"default_entity_id\":\"sensor.zigbee2mqtt_bridge_network_map\",\"device\":{\"hw_version\":\"EmberZNet 8.0.2 [GA]\",\"identifiers\":[\"zigbee2mqtt_bridge_0xc02cedfffee9b626\"],\"manufacturer\":\"Zigbee2MQTT\",\"model\":\"Bridge\",\"name\":\"Zigbee2MQTT Bridge\",\"sw_version\":\"2.12.1\"},\"enabled_by_default\":false,\"entity_category\":\"diagnostic\",\"json_attributes_template\":\"{{ value_json.data.value | tojson }}\",\"json_attributes_topic\":\"zigbee2mqtt/bridge/response/networkmap\",\"name\":\"Network map\",\"object_id\":\"zigbee2mqtt_bridge_network_map\",\"origin\":{\"name\":\"Zigbee2MQTT\",\"sw\":\"2.12.1\",\"url\":\"https://www.zigbee2mqtt.io\"},\"state_topic\":\"zigbee2mqtt/bridge/response/networkmap\",\"unique_id\":\"bridge_0xc02cedfffee9b626_network_map_zigbee2mqtt\",\"value_template\":\"{{ now().strftime('%Y-%m-%d %H:%M:%S') }}\"}"
      network_map#sensor:
        type: string-advanced
        label: Sensor

@TAKeanice

So, if it can provide more information to the logs, why can´t it address the issue?

Because Zigbee2MQTT doesn’t expose it’s own logs over any API I can find. So there’s no way the OH binding can see those logs to add them to the openhab.log.

@TAKeanice

And why couldn´t it relay some information from the Z2M API or from what it posts to MQTT to the status of a thing (i.e. ONLINE, ERROR or something like this)?

It can, and it already does. IF Zigbee2MQTT determines a device is offline, the corresponding Thing in OH will be marked as offline and the error will be reported as the Thing’s status.

@TAKeanice

What I am referring to is that there is no base item type for a “button”, and no item that registers the presses of one (for statistics etc.).

That’s because Items represent state. That is a deliberate architectural choice in the OH framework. Ephemeral events that do not represent states are not supposed to be linked to Items. These Channels trigger rules directly.

But if you must link it for what ever reason, you have a profile that will let you link even these Channels to an Item if you so desire. Or you can record your statistics in the rule that triggers when the button press events occur.

A binding isn’t going to change this fundamental design decision in OH core.

@TAKeanice

So I fell like that´s a missing OH functionality in general.

It’s not missing. Sending ephemeral events is intended to be done from a rule. For MQTT there’s the publishMQTT Action. Receiving ephemeral events are used to trigger a rule to process the event. That’s how OH is designed to work and how all the bindings work.

But of course, if you do not like that design decision, you as an end user have the option to link an event Channel to an Item using the profile and you can set up a Generic MQTT Thing to publish. A binding isn’t going to change this fundamental design choice though.

@TAKeanice

Rollershutter and some others have button-like commands, but buttons appear in so many additional contexts (like sending a single command to a IR-remote).

In the case of Rollershutter, Dimmer, Color, and Player Items, indeed they can receive commands that do not match their state, but they are all still stateful. They all carry something representing the current position or setting of the device. And the commands cause the device to change it’s state.

Receiving an ephemeral event is very different. There is no state associated with the event.

@sihui

Easy to solve in openHAB:

As shown above, you don’t need a Generic MQTT Thing for this. The discovered Zigbee2MQTT Bridge Thing has a Channel for that for you.

[TAKeanice (Tassilo Karge)]

Before going into detail on your response, let me make a general assertion: This thread is supposed to be about finding ways to improve the integration between Z2M and OpenHAB. While I appreciate fundamental doubts about whether it is necessary, I would rather like to get some ideas on what could be improved. What is already there is a starting point, and ideas on how to solve things I suggested are valuable, too, but the real question is:

**Is the current integration optimal? And if not, how can we add things that are missing or improve suboptimal aspects?
**
It does not have to be through a binding or any other kind of plugin, and it does not have to be the precise improvements I suggested.

@rlkoshak

@TAKeanice

Maybe I can completely relay the Z2M UI through the OH UI

Not outside your LAN you can’t.

As I said, I need to experiment a little. Software has endless possibilities.

@rlkoshak

@TAKeanice

Maybe I can also just add some actions to a Z2M Broker Thing, like the Matter Controller has, for frequent actions like starting pairing mode for example.

Zigbee2MQTT supports controlling things like pairing mode and such through MQTT messages. In fact, OH should have discovered a Zigbee2MQTT Bridge Thing among all other devices which has a Channel to enable pairing mode, among other Channels

This looks promising, I did not have that when setting up Z2M (quite some time ago), what triggers that discovery?

@rlkoshak

@TAKeanice

So, if it can provide more information to the logs, why can´t it address the issue?

Because Zigbee2MQTT doesn’t expose it’s own logs over any API I can find. So there’s no way the OH binding can see those logs to add them to the openhab.log.

There are still the log files that Z2M leaves somewhere in the system.

@rlkoshak

@TAKeanice

And why couldn´t it relay some information from the Z2M API or from what it posts to MQTT to the status of a thing (i.e. ONLINE, ERROR or something like this)?

It can, and it already does. IF Zigbee2MQTT determines a device is offline, the corresponding Thing in OH will be marked as offline and the error will be reported as the Thing’s status.

If using the HomeAssistant binding? Because the generic MQTT binding does not do that to my knowledge. And I did not enable HomeAssistant format for Z2M in the past because it had some issues (if I come across it again, I will get into more details what they were)

@rlkoshak

@TAKeanice

What I am referring to is that there is no base item type for a “button”, and no item that registers the presses of one (for statistics etc.).

That’s because Items represent state. That is a deliberate architectural choice in the OH framework. Ephemeral events that do not represent states are not supposed to be linked to Items. These Channels trigger rules directly.

But if you must link it for what ever reason, you have a profile that will let you link even these Channels to an Item if you so desire. Or you can record your statistics in the rule that triggers when the button press events occur.

A binding isn’t going to change this fundamental design decision in OH core.

Thank you for the detailed explanation here, I already acknowledged that this is something a binding cannot do, but I will try your suggestions and report what I liked about them or what I did not elsewhere. Generally, the process to set up some button, for example in the WebUI, representing something that triggers e.g. an IR remote, seems way more tedious than for e.g. a switch. There are even UI plugins that implement this missing functionality, and the whole thing with rules that set an “on” state and then reset it immediately seems hacky. But again, not part of this topic.

[rlkoshak (Rich Koshak)]

@TAKeanice

This thread is supposed to be about finding ways to improve the integration between Z2M and OpenHAB. While I appreciate fundamental doubts about whether it is necessary, I would rather like to get some ideas on what could be improved. What is already there is a starting point, and ideas on how to solve things I suggested are valuable, too, but the real question is:

I’m not arguing that everything is fine and no improvements need to be made. But several of the ideas are already implemented and several are not feasible in OH or with the technology.

@TAKeanice

As I said, I need to experiment a little. Software has endless possibilities.

But networks work in specific ways. Unless you modify OH to become a reverse proxy, you cannot embed any local address (e.g. http://someInteralIP:8000) in MainUI and access that when you are outside your LAN.

This is a problem for IP cameras, Grafana, et al and not unique to Z2M.

If you make the add-on into a reverse proxy it maybe could work. Because then it’s OH itself that is “hosting” the UI. That;s kind of what the IP Camera add-on does.

@TAKeanice

This looks promising, I did not have that when setting up Z2M (quite some time ago), what triggers that discovery?

The Home Assistant binding does discovery on startup, and I think it does discovery periodically. You should be able to kick off a scan through Settings → Things → + ->Home Assitant Binding → Scan. Though make sure to check that you haven’t previously ignored this Thing.

I didn’t do anything special to discover and add this Thing. It was just one among the many that came from Z2M.

@TAKeanice

There are still the log files that Z2M leaves somewhere in the system.

Which kind of works if and only if OH is running on the same system. That is not a universal configuration. In fact, I suspect a large percentage do not host on the same machine so they can get their coordinator positioned in an optimal location.

It’s also not really the job of OH to add to its own loggers the logs from some other system. There are plenty of other tools out there that can do that. The logs you see in the log viewers built into MainUI do not come from the log files themselves. They are internally generated inside OH.

So in order to see the Z2M logs using the openhab.log and the log viewers built into MainUI, you need to find a way to have OH log them using it’s own loggers.

@TAKeanice

If using the HomeAssistant binding?

Yes.

@TAKeanice

Because the generic MQTT binding does not do that to my knowledge.

The Generic MQTT binding can do that too if you set it up to do that. The online/offline status of individual devices are published to (assuming you left everything at the default (zigbee2mqtt/<device name>/availability) where you will find {"state":"online"} or `{“state”:“offline”}.

In the Generic MQTT Thing check “Show advanced” and you will see options to configure the Thing to set the Thing’s status according to the availability topic.

For Home Assistant it does it automatically.

However, it appears these messages are not retained so unless Z2M has published an updated messages recently you might not see the topics in MQTT Explorer. But the availability topic is part of the spec.

I think there is another topic that controls the ONLINE/OFFLINE availability of Home Assistant HA Things too but I’d ahve to do more research to be sure.

@TAKeanice

And I did not enable HomeAssistant format for Z2M in the past because it had some issues (if I come across it again, I will get into more details what they were)

Previous to OH 5.0 the OH Home Assistant add-on was a reverse engineering of the Home Assistant standard. Indeed it had lots of problems. For OH 5.0 we imported the exact same Python code that Home Assistant uses and most of the problems are gone. Currently the only problem I have is if a publisher publishes an empty message to a switch Channel, I get exceptions in the logs saying that None (the Python equivalent to null) cannot be converted to ON or OFF. I’ve opened an issue to someday hopefully get that fixed. Everything else works very well for the rest of my devices.

@TAKeanice

Generally, the process to set up some button, for example in the WebUI, representing something that triggers e.g. an IR remote, seems way more tedious than for e.g. a switch.

You just need to set up the action for the button to call a rule. No Item is involved at all. That UI plug-in from four years ago is no longer necessary. Linking to an Item is no longer necessary. No more need to automatically set an Item to OFF. The UI calls the rule directly, and you can even pass arguments into the rule (e.g. name of the button pressed) so you could create one Rule to handle all of your IR remote buttons instead of a dozen Items.

@TAKeanice

But again, not part of this topic.

And yet you brought it up as something you want to fix.

Over all, you seem to not have recent experience with the Home Assistant binding and lack some understanding of what the latest state of the art is in OH. You want to solve problems that are already fixed. Now if you want to find some way to fix them better, I’m all for it. But if you are looking to reinvent the wheel because you don’t know what’s already been done, that’s a problem.

Personally, I think a Zigbee2MQTT binding is a great idea! I’d like to see it use the Websocket and REST API that Zigbee2MQTT uses between the backend and the browser for a more timely and robust integration to OH similar to what ZwaveUI JS provides.

But a lot of the problems sited won’t be fixed by a new add-on.