Zigbee devices and HA – my experience

ZBBridge-U
1

I took some time to test more seriously the new functions of ZBBridge-U (v1.17.1).
Here are my observations:

Positive:

  • Connecting ZBBridge-U and synchronizing Zigbee devices with Home Assistant via MQTT is straightforward.
  • Communication is stable; on the HA side I used a Sonoff Dongle E as coordinator.
  • Device discovery is fast with very low latency (37 Zigbee devices connected, mostly Sonoff).

Negative:

  • After synchronization, devices are exposed only with their IDs, so renaming them in HA takes time.
  • Even after renaming, MQTT topics still rely on the raw device ID
    (e.g. zigbee2cube/0x3c2ef5fffebafc44), not the friendly name.
  • In addition to the main MQTT topic, entity topics are created
    (e.g. homeassistant/number/0x3c2ef5fffebafc44/valve_closing_degree/config),
    which added confusion rather than clarity.
  • Devices expose many entities, but their structure differs from what I’m used to in Zigbee2MQTT,
    so I had to adjust automations.
  • At this stage, Zigbee devices from other manufacturers are not fully supported
    (e.g. Ikea Inspelning works as a switch but without consumption data).
    I expect this will improve in future releases.
1 Like
2

Your tests are useful, but a few points mix different integration layers, so let me clarify them to avoid misleading other readers.

  1. Raw identifiers in MQTT
    Topics based on Zigbee addresses (0x3c2ef5fffebafc44) are normal.
    Friendly names exist only inside Home Assistant, not in MQTT - so renaming devices in HA does not change the MQTT topic structure.

  2. homeassistant/…/config topics
    These are part of HA’s standard autodiscovery mechanism, not “extra noise”.
    Every integration that wants automatic entity creation must publish them. Zigbee2MQTT structures them differently, hence the mismatch.

  3. Different entity structure compared to Z2M
    ZBBridge‑U does not replicate Zigbee2MQTT’s model.
    It exposes entities according to its own API, so some automations need adjustments - that’s expected, not a bug.

  4. Limited support for third‑party devices
    Agreed - the firmware still lacks a broad device database, so some products fall back to “generic” behavior. This should improve as the firmware matures, I believe.

  5. Same “payload noise” appears in NSPanel Pro
    This is identical to what I saw with NSPanel Pro: lots of automatically published payloads that clutter HA more than they help. I eventually disabled MQTT publishing on the panel because the noise outweighed the value.

1 Like
4

I’m going a little off topic, I hope you don’t mind…

I continued testing this time ZBBridge-U as a Matter Bridge for synchronizing Zigbee subdevices with Matter on HA.

Easy and fast connection to HA Matter, WiFi and Zigbee devices exposed without problems, names assigned adequately, without too many device entities, just the right amount, in my opinion :))))

In a word, excellent!

The problem I noticed is that when you cancel device synchronization on ZBBridge-U, the device with all entities remains inactive in HA (it can be removed manually without any problems), and re-synchronizing the device creates a new device with the same name but new entities (e.g. entity_name_1).