XZG icon indicating copy to clipboard operation
XZG copied to clipboard

Support the new/upcoming generic ZHA Zeroconf discovery?

Open Hedda opened this issue 1 year ago • 5 comments

Is your feature request related to a problem? Please describe.

This is a feature request; puddly is working on a new/upcoming generic Zeroconf discovery for the ZHA integration in Home Assistant to allow it to discover new network-attached Zigbee Coordinator adapters without code changes to the ZHA component in Home Assistant core. Please look into adding support for this Zeroconf discovery formatting, see:

https://github.com/home-assistant/core/pull/126294

Describe the solution you'd like

The goal with this is that code changes to the ZHA component in Home Assistant core but it puts some new requirement on the firmware site where the manufacturer need to enter unique metadate for each new type and model of network-attached Zigbee Coordinator adapter. This will eventeully also make the old disovery method obsolete:

https://www.home-assistant.io/integrations/zha#discovery-via-usb-or-zeroconf

Describe alternatives you've considered

Alternative is to use the old method but it is likley that new patches to Home Assistant core will be accepted once support for this new formallting/method has been implemented.

Additional context

puddly has already posted comments to each new patch for new devices that he is working on this and that it will become the default.

Hedda avatar Sep 30 '24 09:09 Hedda

Hi @Hedda, thanks for the info. I tried to implement it. I would appreciate tests and feedback! Screenshot 2024-10-01 at 4 16 35 PM

xyzroe avatar Oct 01 '24 14:10 xyzroe

FYI, this "generic ZHA Zeroconf discovery" feature has been merged into Home Assistant's core

  • https://github.com/home-assistant/core/pull/126294

"I'm introducing a new service type: _zigbee-coordinator._tcp.local.. This will allow all future TCP coordinators to be supported without an explicit PR to ZHA. The only expected properties are radio_type (one of ezsp, znp, etc.) and serial_number (must be unique per device and not derived from any Zigbee information, like the Ethernet MAC address). The service name will be shown as-is."

Disclaimer; This is just an FYI; I can not test this myself since I do not have a XZG based Zigbee Coordinator.

PS: puddly posted comments there and elseware stating that this become the new default for discovering Zigbee Coordiantors.

Hedda avatar Jan 20 '25 08:01 Hedda

Tip is to check out code from tube0013 since read that he helped puddly beta test it so also first to implement this feature:

  • https://github.com/tube0013/TubesZB-ESPHome-Builder

Noted that he is using get_mac_address and convert that into a serial_number in order to make the serials unique for each device:

  • https://github.com/tube0013/TubesZB-ESPHome-Builder/blob/main/esphome-config/tubeszb-efr32-mgm210-poe-2023.yaml#L10

PS: Off-topic but you might also be interested to check out his customized version of the uart component which enable hardware flow control for ESP32 boards:

  • https://github.com/tube0013/esphome-components

Hedda avatar Jan 20 '25 09:01 Hedda

In XZG we can provide the MAC address of Zigbee module as a serial.

XZG isn't based on ESP HOME, so I don't need to look at those code.

xyzroe avatar Jan 20 '25 12:01 xyzroe

In XZG we can provide the MAC address of Zigbee module as a serial.

XZG isn't based on ESP HOME, so I don't need to look at those code.

I only meant that you could use the same concept with the idea of using the MAC address as the serial number to make it unique.

Hedda avatar Jan 20 '25 13:01 Hedda