Bridge discovery

[mundschenk-at]

• Adds discovery for the Z2M Bridge. Fixes [Feature request]: Auto-discovery for bridge/controller #19877.
• Simplifies the getDiscoverKey method.
• Adds support for disabling the availability payload for certain entities.
• Adds the following entities for the bridge:
  • Control:
    • Permit join (switch)
    • Restart (button)
  • Config:
    • Log level (select)
  • Diagnostic:
    • Connection state (binary_sensor)
    • Network map (sensor)
    • Permit join timeout (sensor)
    • Restart required (binary_sensor)
    • Version (sensor)
    • Coordinator version (sensor)

[mundschenk-at]

Tests are still missing (as well as some potential HA entities).

[mundschenk-at]

@Koenkk Unfortunately, I need help with the tests again. I have got no clue why those three lines (89, 1396, 1560) are shown as uncovered.

Edit: OK, I get it now, they are partially covered. Not sure what to do about line 89 except ignore it, but I think I can work something out for the other two.

[mundschenk-at]

Open issues:

• Instead of putting the Coordinator Type into the hw_version field, we could set it as the model. I already changed it to that and then changed it back because having the Z2M version as sw_version (listed by HA as Firmware version) didn't look right.
• Would a data model for the Bridge be useful elsewhere (similar to Device and Group)?
• I am currently treating the CoordinatorVersion.meta object as containing the specific set of subfields that are provided by the ZH adapter classes, but formally that's not guaranteed. Do have any plans to make this structure an actual part of the interface/type definition?

[Koenkk]

First of all, many thanks for this!

Instead of putting the Coordinator Type into the hw_version field, we could set it as the model. I already changed it to that and then changed it back because having the Z2M version as sw_version (listed by HA as Firmware version) didn't look right.

Left a comment regarding this on the code

Would a data model for the Bridge be useful elsewhere (similar to Device and Group)?

I don't see another place to use it currently, let's leave it in homeassistant.ts and move it when needed elsewhere.

I am currently treating the CoordinatorVersion.meta object as containing the specific set of subfields that are provided by the ZH adapter classes, but formally that's not guaranteed. Do have any plans to make this structure an actual part of the interface/type definition?

Currently not, but the current handling is fine.

[mundschenk-at]

So apart from updating/expanding the list of discoverable entities, only the issue of the device identifier to use is still open. I've left a reply on the code comment, but I can recap here: If the coordinator address is only changed under very specific circumstances (like when restoring a backup to a new coordinator), I think we should be fine with using it as the identifier, as the discovery entries for all devices will be recreated on startup and point to the new bridge.

My preference for this is based on that it is an actual device identifier and not just a configuration setting like the base topic.

[Koenkk]

I don't think this sensor is necessary. It's basically the availability of the bridge, something which can already be retrieved from the other sensors (we also don't have a separate availability sensor for each device)

[mundschenk-at]

I think it is actually useful (but as a binary_sensor instead of a sensor like it was in the package.yaml) for automations in HA. Yes, you could build your own from individual ZigBee devices, but which would you "watch"? Having a binary sensor for online status of hub-style devices is pretty common.

[mundschenk-at]

I've changed the sensor to a binary_sensor.

[Koenkk]

, only the issue of the device identifier to use is still open.

Agree with your solution, left a few more comments, once those are solved this can be merged.

[mundschenk-at]

I've cleaned the list of entities somewhat and added a few more that seemed useful (either from the package.yaml or on its own).

[Koenkk]

Thanks again! I think all the manual entities can be removed from the docs now?

[mundschenk-at]

Mostly, I think. Some of the input helper entities are not included yet or can't be replaced with MQTT entities because they need more complex automation logic. I'll have a go at a PR to remove those that are now superfluous.

[leroyloren]

in connection with that PR I noticed these errors

When all the Z2M configuration is in the entities part of the attributes

State attributes for switch.zigbee2mqtt_bridge_permit_join exceed maximum size of 16384 bytes. This can cause database performance issues; Attributes will not be stored State attributes for sensor.zigbee2mqtt_bridge_permit_join_timeout exceed maximum size of 16384 bytes. This can cause database performance issues; Attributes will not be stored State attributes for sensor.zigbee2mqtt_bridge_version exceed maximum size of 16384 bytes. This can cause database performance issues; Attributes will not be stored State attributes for select.zigbee2mqtt_bridge_log_level exceed maximum size of 16384 bytes. This can cause database performance issues; Attributes will not be stored

[mundschenk-at]

@leroyloren I assume you have "legacy_entity_attributes" enabled?

[leroyloren]

yes

[mundschenk-at]

@Koenkk Is this a configuration you want to support? If so, the code for adding the legacy entity attributes will need special handling (probably by not adding any entity attributes automatically at all, or possibly by filtering). I can provide a PR. I also saw this during initial development, but since it does not technically break HA, I chose to view it as an incentive for people to not enable the legacy entity attributes anymore.

[Koenkk]

@mundschenk-at no, @leroyloren please disable the legacy option

[b2un0]

@mundschenk-at i love this new feature. thank you!

this makes some of my custom mqtt entities obsolet (restart, permit join)

can you add also a device counter sensor to the bridge?

currently i have this custom entity

mqtt:
  sensor:
    - unique_id: mqtt_z2m_device_count
      name: "Zigbee2MQTT Device Counter"
      state_topic: "zigbee2mqtt/bridge/devices"
      state_class: total
      value_template: "{{ value_json | count }}"
      availability:
        - topic: "zigbee2mqtt/bridge/state"
          value_template: "{{ value_json.state }}"
          payload_available: "online"

and a automation to notify me if some of the stupid aqara devices left the network again

alias: System - Z2M Devices change
description: ""
trigger:
  - platform: state
    entity_id:
      - sensor.z2m_devices
    for:
      hours: 0
      minutes: 0
      seconds: 0
condition:
  - condition: state
    entity_id: binary_sensor.zigbee2mqtt_bridge_connection_state
    state: online
    for:
      hours: 0
      minutes: 5
      seconds: 0
action:
  - service: notify.mobile_app_XY
    data:
      title: Z2M
      message: Device Counter changed
mode: single

[mundschenk-at]

@b2un0 I'll look into this.

[Drafteed]

Hello, great work! Maybe it's worth adding a 255s timeout there, as is done in the Z2M frontend? I think it's more secure. @Koenkk

Suggested change

	command_topic: `${baseTopic}/request/permit_join`,
	payload_on: 'true',
	command_topic: `${baseTopic}/request/permit_join`,
	payload_on: '{"value": true, "time": 255}',

[mundschenk-at]

Since this is a home automation system, it's as "secure" as you make your automations. There is a more involved discussion in #20468 (comment) (with wildly differing opinions, I don't see a clear consensus either way).