kardia-as / zigpy-zboss Goto Github PK

License: GNU General Public License v3.0

Python 100.00%

zigpy-zboss's Introduction

zigpy-zboss

zigpy-zboss is a Python library project that adds support for common Nordic Semiconductor nRF modules to zigpy (a open source Python Zigbee stack project) and other Network Co-Processor radios that uses firmware based on ZOI (ZBOSS Open Initiative) by DSR.

Together with the zigpy library and a home automation software application with compatible Zigbee gateway implementation, (such as for example the Home Assistant's ZHA integration component), you can directly control Zigbee devices from most product manufacturers, like; IKEA, Philips Hue, Inovelli, LEDVANCE/OSRAM, SmartThings/Samsung, SALUS/Computime, SONOFF/ITEAD, Xiaomi/Aqara, and many more.

Back-story and use cases

This is currently an 'as-is' independent and unofficial implementation radio library for zigpy, as such should be considered experimental and you should only expect best-effort support from volunteers in the open-source community!

Zigbee NCP support for ZOI (ZBOSS Open Initiative) based Zigbee radios compatible with ZBOSS NCP firmware for zigpy based Zigbee gateway implementation is still in very early development.

Development is initially focused on Zigbee Coordinator functionality Nordic Semiconductor's development kit hardware which has been tested to be compatible. Those also officially recognized as Zigbee-Compliant platforms by the CSA (Connectivity Standards Alliance, formerly the Zigbee Alliance), of which both DSR Cooperation and Nordic Semiconductor are board and promoter members of.

Hardware requirements

Nordic Semi USB adapters or development kits/boards based on either the nRF52840 (nRF52 series) SoC or the nRF5340 (nRF53 series) SoC:

nRF52840 dongle
nRF52840 development kit
nRF5340 development kit (nRF5340 DK has not been tested but should be compatible)

Note! Only nRF52840 SoC has been used for development and tested as reference hardware by the developers of the zigpy-zboss project.

Firmware

Development and testing in zigpy-zboss project is done with a firmware image built using the ZBOSS NCP Host sample from Nordic Semi:

nrf-zboss-ncp - Compiled ZBOSS NCP Host firmware image required to be flash on a compatible nRF52840 or nRF5340 device.

Releases via PyPI

Tagged versions will also be released via PyPI

External links, documentation, and other development references

ZBOSS NCP Serial Protocol (v1.5) prepared by DSR Corporation for ZOI
https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/index.html - Specifically see the ZBOSS NCP sample, Zigbee CLI examples, and the ZBOSS NCP Host user guide.
zigpy/zigpy#394 - Previous development discussion about ZBOSS radio library for zigpy.
zigpy/zigpy#595 - Reference collections for Zigbee Stack and related dev docks
https://github.com/MeisterBob/zigpy_nrf52 - Other attemt at making a zigpy library for nFR52
https://gist.github.com/tomchy/04ac4ff78d6e117d33ab92d9cc1de779 - Another attemt at making a zigpy controller for nFR

Other radio libraries for zigpy to use as reference projects

Note! The initial development of the zigpy-zboss radio library for zigpy stems from information learned from the work in the zigpy-znp project.

zigpy-znp

The zigpy-znp zigpy radio library for Texas Instruments Z-Stack ZNP interface and has been the primary reference to base the zigpy-zboss radio library on. zigpy-znp is very stable with TI Z-Stack 3.x.x, (zigpy-znp also offers some stand-alone CLI tools that are unique for Texas Instruments hardware and Zigbee stack).

zigpy-deconz

The zigpy-deconz is another mature radio library for Dresden Elektronik's deCONZ Serial Protocol interface that is used by the deconz firmware for their ConBee and RaspBee seriies of Zigbee Coordinator adapters. Existing zigpy developers previous advice has been to also look at zigpy-deconz since it is somewhat similar to the ZBOSS serial protocol implementation.

zigpy deconz parser

zigpy-deconz-parser allow developers to parse Home Assistant's ZHA component debug logs using the zigpy-deconz radio library if you are using a deCONZ based adapter like ConBee or RaspBee.

bellows

The bellows is made Silicon Labs EZSP (EmberZNet Serial Protocol) interface and is another mature zigpy radio library project worth taking a look at as a reference, (as both it and some other zigpy radio libraires have some unique features and functions that others do not).

How to contribute

If you are looking to make a code or documentation contribution to this project suggest that you try to follow the steps in the contributions guide documentation from the zigpy project and its wiki:

Also see:

Related projects

zigpy

zigpy is a Zigbee protocol stack integration project to implement the Zigbee Home Automation standard as a Python library. Zigbee Home Automation integration with zigpy allows you to connect one of many off-the-shelf Zigbee adapters using one of the available Zigbee radio library modules compatible with zigpy to control Zigbee devices. There is currently support for controlling Zigbee device types such as binary sensors (e.g. motion and door sensors), analog sensors (e.g. temperature sensors), lightbulbs, switches, and fans. Zigpy is tightly integrated with Home Assistant's ZHA component and provides a user-friendly interface for working with a Zigbee network.

zigpy-cli (zigpy command line interface)

zigpy-cli is a unified command line interface for zigpy radios. The goal of this project is to allow low-level network management from an intuitive command line interface and to group useful Zigbee tools into a single binary.

ZHA Device Handlers

ZHA deviation handling in Home Assistant relies on the third-party ZHA Device Handlers project (also known unders zha-quirks package name on PyPI). Zigbee devices that deviate from or do not fully conform to the standard specifications set by the Zigbee Alliance may require the development of custom ZHA Device Handlers (ZHA custom quirks handler implementation) to for all their functions to work properly with the ZHA component in Home Assistant. These ZHA Device Handlers for Home Assistant can thus be used to parse custom messages to and from non-compliant Zigbee devices. The custom quirks implementations for zigpy implemented as ZHA Device Handlers for Home Assistant are a similar concept to that of Hub-connected Device Handlers for the SmartThings platform as well as that of zigbee-herdsman converters as used by Zigbee2mqtt, meaning they are each virtual representations of a physical device that expose additional functionality that is not provided out-of-the-box by the existing integration between these platforms.

ZHA integration component for Home Assistant

ZHA integration component for Home Assistant is a reference implementation of the zigpy library as integrated into the core of Home Assistant (a Python based open source home automation software). There are also other GUI and non-GUI projects for Home Assistant's ZHA components which builds on or depends on its features and functions to enhance or improve its user-experience, some of those are listed and linked below.

ZHA Toolkit

ZHA Toolkit is a custom service for "rare" Zigbee operations using the ZHA integration component in Home Assistant. The purpose of ZHA Toolkit and its Home Assistant 'Services' feature, is to provide direct control over low level zigbee commands provided in ZHA or zigpy that are not otherwise available or too limited for some use cases. ZHA Toolkit can also; serve as a framework to do local low level coding (the modules are reloaded on each call), provide access to some higher level commands such as ZNP backup (and restore), make it easier to perform one-time operations where (some) Zigbee knowledge is sufficient and avoiding the need to understand the inner workings of ZHA or Zigpy (methods, quirks, etc).

ZHA Device Exporter

zha-device-exporter is a custom component for Home Assistant to allow the ZHA component to export lists of Zigbee devices.

ZHA Network Visualization Card

zha-network-visualization-card was a custom Lovelace element for Home Assistant which visualize the Zigbee network for the ZHA component.

ZHA Network Card

zha-network-card was a custom Lovelace card for Home Assistant that displays ZHA component Zigbee network and device information in Home Assistant

zigpy-zboss's People

Contributors

Stargazers

Watchers

Forkers

hedda natexornate kevskitv puddly

zigpy-zboss's Issues

Time for a new release?

Time for a new release? https://github.com/kardia-as/zigpy-zboss/releases

[REQUEST] Compatibility with ESP ZBOSS 3.0 Libraries (esp-zboss-lib from Espressif) for ESP32-C6 and ESP32-H2?

Espressif of ESP32 fame joined ZOI (ZBOSS Open Initiative) more than a year ago and has now fully released ESP ZBOSS 3.0 binary libraries supporting the Zboss Zigbee 3.0 stack for ESP32-C6 and ESP32-H2 SoCs which features embedded 802.15.4 radio for Zigbee (and Thread) support:

Would it be possible to make zigpy-zboss compatible with a serial interface for Espressif's "esp-zboss-lib" (ESP ZBOSS 3.0 Libraries) to allow using a serial-server on ESP32-C6 or ESP32-H2 for Serial-over-IP pass-through proxy (similar to ser2net) to enable TCP streaming of the serial communication bridge to allow it to be used as a network-attached remote Zigbee Coordinator so that the Home Assistant's ZHA integration can connect to it via a socket (socat)?

https://github.com/tube0013/esphome-stream-server-v2

Bonus is if that serial streaming server is advertised on the network via Zeroconf for automatic network discovery that ZHA can find:

Espressif has also released a couple of development kits based on ESP32-H2 as reference hardware such and similar solutions:

https://www.cnx-software.com/2023/06/20/espressif-esp-thread-border-router-board-combines-esp32-h2-esp32-c3-wireless-chips/

That is a new ESP32-H2 + ESP32-C3 combo development board kit marketed as ESP Thread Boarder Router / Zigbee Gateway with an optional Ethernet daughter-board/sub-board sold separately (which would normally be recommended as streaming serial communication over WiFi does not work well), although that Ethernet daughter-board/sub-board is based on WIZnet W5500 which uses a non-standard SPI interface instead of RMII so might not yet be supported by ESPHome (and not yet supported in Tasmota).

An earlier two-board ESP Thread Border Router / Zigbee Gateway solution that combined separate ESP32-C6 and ESP32-H2 boards was previously available as an example project for reference to achieve the same result:

With either of those hardware combinations it should be possible to make a network-attached "Zigbee Coordinator" adapter products based on ESPHome (or Tasmota) similar to TubesZB Zigbee Gateways with ESP32-C6 or ESP32-H2 that simply tunnel/passthrough the serial connection to the serial interface for Espressif's "esp-zboss-lib" (ESP ZBOSS 3.0 Libraries) from Home Assistant's ZHA integration.

ESP ZBOSS 3.0 Libraries

This repository contains binary libraries supporting the Zboss Zigbee 3.0 stack for ESP32 series chips.

Packages from this repository are uploaded to Espressif’s component service. You can add them to your project via idf.py add-dependency

More information about idf-component-manager can be found in Espressif API guide or PyPi registry.

There now looks to be some Zigbee examples in Espressif’s IoT Development Framework (ESP-IDF):

Those examples include; Zigbee coordinator ("light coordinator"), "Zigbee RCP (radio co-processor"), and "Zigbee gateway":

https://github.com/espressif/esp-idf/tree/master/examples/zigbee/light_sample/light_coordinator

"light_coordinator is a light coordinator example demonstrating Zigbee Coordinator role. It provides a formation of the Zigbee network. It runs on an 802.15.4 SoC like ESP32-H2. For more details to see the example readme file."

Wondering if "RPC" works similarly to Silicon Labs RPC which works like a dumb radio requiring external ESP ZBOSS 3.0 libraries?

https://components.espressif.com/component/espressif/esp-zboss-lib

"This test code shows how to configure Zigbee rcp (radio co-processor) device. Rcp doesn't function alone, it needs to work together with Zigbee gateway (see esp_zigbee_gateway example)"

"After rcp starts up, it will send its own MAC ieee address and Zigbee stack version number to the Zigbee gateway and start working together with Zigbee gateway via UART communication"

ESP32-H2 was apparently early on even certified as a “Zigbee Compliant Platform” by the CSA:

Type of Device: Zigbee Compliant Platform
Zigbee PRO Feature Set (2017)
Manufacturer: Espressif Systems (Shanghai) Co., Ltd.
Model Identification: ESP32-H2
Firmware Version: V1.0
Hardware Version: V1.0
Certification Date: October 20, 2021
Certification ID Number: ZIG21030ZCP27315-24

Frame fragmentation

When a request is exceeding the maximum size for the low level protocol body, the request is not received by the NCP.
We need to implement frame fragmentation. This is necessary for requests with a lot of data.

Add device path attribute to the factory reset script

When factory resetting the module, it is automatically detecting the path when the dongle is used. But when used with another nRF52840 based module, it is not necessary detected.
This will add the possibility to specify the device path when calling python -m zigpy_zboss.tools.factory_reset_ncp <path>

Fix neighbor scan

It seems like ZBOSS doesn't return the neighbors when using the ZDO Mgmt_Lqi_req command.
We'll probably have to use the NWK_GET_NEIGHBOR_BY_IEEE command from the ZBOSS Serial API in order to retrieve neighbor information and reconstruct the Mgmt_Lqi_rsp command for zigpy.

Write unit tests

Write unit tests for the zigpy-zboss code.

baudrate and flow_control keys added to zigpy config new centralized probe function?

FYI, baudrate and flow_control keys have been added to zigpy config as a new centralized probe function from 0.60.0 onwards:

zigpy/zigpy#1287

zigpy 0.60.0 has also implemented connection_lost to let the radio libraries know when should run their own reconnection logic:

zigpy/zigpy#1277

Does/will zigpy-zboss support those?

Not working with Home Assistant / TypeError: Can't instantiate abstract class ControllerApplication with abstract method permit_with_link_key

Appears that there has been a change in ZHA that needs to be accomodated in zigpy-zboss.

Logger: aiohttp.server
Source: /usr/local/lib/python3.11/site-packages/aiohttp/web_protocol.py:421
First occurred: 12:49:43 PM (4 occurrences)
Last logged: 12:50:15 PM

Error handling request
Traceback (most recent call last):
  File "/usr/local/lib/python3.11/site-packages/aiohttp/web_protocol.py", line 452, in _handle_request
    resp = await request_handler(request)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/aiohttp/web_app.py", line 543, in _handle
    resp = await handler(request)
           ^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/aiohttp/web_middlewares.py", line 114, in impl
    return await handler(request)
           ^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/components/http/security_filter.py", line 85, in security_filter_middleware
    return await handler(request)
           ^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/components/http/forwarded.py", line 100, in forwarded_middleware
    return await handler(request)
           ^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/components/http/request_context.py", line 28, in request_context_middleware
    return await handler(request)
           ^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/components/http/ban.py", line 80, in ban_middleware
    return await handler(request)
           ^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/components/http/auth.py", line 233, in auth_middleware
    return await handler(request)
           ^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/components/http/headers.py", line 31, in headers_middleware
    response = await handler(request)
               ^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/components/http/view.py", line 149, in handle
    result = await handler(request, **request.match_info)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/components/http/decorators.py", line 63, in with_admin
    return await func(self, request, *args, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/components/config/config_entries.py", line 177, in post
    return await super().post(request, flow_id)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/components/http/data_validator.py", line 72, in wrapper
    result = await method(view, request, data, *args, **kwargs)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/helpers/data_entry_flow.py", line 110, in post
    result = await self._flow_mgr.async_configure(flow_id, data)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/data_entry_flow.py", line 320, in async_configure
    result = await self._async_handle_step(
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/data_entry_flow.py", line 416, in _async_handle_step
    result: FlowResult = await getattr(flow, method)(user_input)
                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/config/custom_components/zha/config_flow.py", line 316, in async_step_verify_radio
    return await self.async_step_choose_formation_strategy()
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/config/custom_components/zha/config_flow.py", line 332, in async_step_choose_formation_strategy
    await self._radio_mgr.async_load_network_settings()
  File "/config/custom_components/zha/radio_manager.py", line 249, in async_load_network_settings
    async with self.connect_zigpy_app() as app:
  File "/usr/local/lib/python3.11/contextlib.py", line 204, in __aenter__
    return await anext(self.gen)
           ^^^^^^^^^^^^^^^^^^^^^
  File "/config/custom_components/zha/radio_manager.py", line 181, in connect_zigpy_app
    app = await self.radio_type.controller.new(
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/zigpy/application.py", line 242, in new
    app = cls(config)
          ^^^^^^^^^^^
TypeError: Can't instantiate abstract class ControllerApplication with abstract method permit_with_link_key

zigpy-cli support?

Is anything needed for zigpy-cli support other than adding zigpy-zboss as a dependency?

https://github.com/zigpy/zigpy-cli

Handle zboss exceptions

Exception handling is done correctly from zigpy, but zigpy-zboss should handle exception in a better way. For exemple when a command Timeout happens

[REQUEST] ZGP (Zigbee Green Power) Green Power Sink (GPS) support?

Can this zigpy-zboss radio library support Green Power Sink (GPS) and/or forwarding to ZGP controller support with the draft ZGP (Zigbee Green Power) patches for zigpy that are still a work in progress?

zigpy/zigpy#1282

https://github.com/konistehrad/zigpy/tree/zgp

zigpy/zigpy#341

Some of the other reference radio libraries for zigpy has to be patched by @konistehrad for GPDF (Green Power Data Frames) handling, see example:

zigpy/zigpy-znp#235

zigpy/bellows#594

zigpy/zigpy-deconz#235

PCAP packet capture dump to file for troubleshooting and Wireshark analysys (like bellows CLI tool)?

Low priority request however please consider implementing PCAP packet capture dump to file from raw MAC layer for troubleshooting and Wireshark analyses (like bellows CLI tool) as then this could also make the zigpy-zboss project usable as a stand-alone command line tool as well.

https://github.com/the-tcpdump-group/tcpdump-htdocs/blob/master/linktypes/LINKTYPE_ZBOSS_NCP.html

https://infocenter.nordicsemi.com/index.jsp?topic=%2Fug_sniffer_802154%2FUG%2Fsniffer_802154%2Fintro_802154.html

https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/protocols/zigbee/tools.html#id8

https://infocenter.nordicsemi.com/index.jsp?topic=%2Fug_sniffer_802154%2FUG%2Fsniffer_802154%2Fintro_802154.html

https://gitlab.com/wireshark/wireshark/-/merge_requests/5301

"Zigbee stack ZBOSS by DSR has a serial protocol for Network Co-Processor configuration (NCP).
This is an implementation of dissector for this protocol."

bellows support dumping captured packets into a PCAP file, see bellows -d /dev/ttyUSB1 dump -c 15 -w packet-capture-file.pcap

https://github.com/zigpy/bellows/blob/dev/bellows/cli/dump.py

Note, since this feature is radio dependent it probably will not be able to be implemented into zigpy, but maybe into zigpy-cli someday(?)

https://github.com/zigpy/zigpy-cli

com.zsmartsystems.zigbee.sniffer (by cdjackson for the https://github.com/zsmartsystems project) to the zigpy project to let Wireshark Zigbee sniffer function utilize radio libraries to even sniff Zigbee network traffic in real-time?

https://github.com/zsmartsystems/com.zsmartsystems.zigbee.sniffer

The com.zsmartsystems.zigbee.sniffer project act as a stand-alone example of how to features of an Ember dongle to provide a network sniffer to route frames to Wireshark.

See https://wiki.wireshark.org/IEEE_802.15.4

"To use Wireshark, the loopback interface needs to be selected, and then a filter udp port 17754 is used to only display ZigBee packets."

https://www.zigbee2mqtt.io/how_tos/how_to_sniff_zigbee_traffic.html

https://www.cd-jackson.com/downloads/ZigBeeWiresharkSniffer.pdf

com.zsmartsystems.zigbee.sniffer as it is currently depends on the Ember (EZSP) driver from https://github.com/zsmartsystems/com.zsmartsystems.zigbee

Firmware ZDO proxying

Thank you for writing and open sourcing this library! ZBOSS has long been on the radar and your implementation is very clear.

I've skimmed through the source code and noticed that ZBOSS seems to intercept and proxy all ZDO requests, similar to Z-Stack before. Does ZBOSS also successfully send any request to endpoint 0 and intercept the response? Or does it not allow the requests to be sent directly to endpoint 0 in the first place?

Also, do you happen to have a link to the serial protocol documentation? I'm unable to find any of the commands within the ZBOSS source code, nor in Nordic's documentation.

ApplicationController probe method - wrong configuration

          Attempting to add the update to HomeAssistant via:

Make a custom component by copying the zha component from inside the docker container /usr/src/homeassistant/homeassistant/components/zha to the /config/custom_components directory.
add a version key (I used "2025.1.1") and "zippy-zboss==1.1.1" to the requirements list in manifest.json
add import zigpy_zboss.zigbee.application and boss = ("boss", zigpy_zboss.application.ControllerApplication,) to custom_components/zha/core/const.py
Restart

I am able to see the custom component:

I select the serial port. It should be passed through into the docker container as I was using it previously with a cc2531.

I select the radio type:

I then get to a port configuration in the control flow, but no matter what combination of flow control and speed I select, it errors and won't move forward, with an "unknown error occurred."

The logs from home assistant:

Logger: aiohttp.server
Source: /usr/local/lib/python3.11/site-packages/aiohttp/web_protocol.py:403
First occurred: 8:33:22 AM (2 occurrences)
Last logged: 8:35:19 AM

Error handling request
Traceback (most recent call last):
  File "/usr/local/lib/python3.11/site-packages/zigpy_zboss/api.py", line 80, in connect
    self._config[conf.CONF_DEVICE], self)
    ~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^
KeyError: 'device'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/local/lib/python3.11/site-packages/aiohttp/web_protocol.py", line 433, in _handle_request
    resp = await request_handler(request)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/aiohttp/web_app.py", line 504, in _handle
    resp = await handler(request)
           ^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/aiohttp/web_middlewares.py", line 117, in impl
    return await handler(request)
           ^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/components/http/security_filter.py", line 85, in security_filter_middleware
    return await handler(request)
           ^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/components/http/forwarded.py", line 100, in forwarded_middleware
    return await handler(request)
           ^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/components/http/request_context.py", line 28, in request_context_middleware
    return await handler(request)
           ^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/components/http/ban.py", line 80, in ban_middleware
    return await handler(request)
           ^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/components/http/auth.py", line 236, in auth_middleware
    return await handler(request)
           ^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/components/http/headers.py", line 31, in headers_middleware
    response = await handler(request)
               ^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/components/http/view.py", line 148, in handle
    result = await handler(request, **request.match_info)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/components/http/decorators.py", line 63, in with_admin
    return await func(self, request, *args, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/components/config/config_entries.py", line 177, in post
    return await super().post(request, flow_id)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/components/http/data_validator.py", line 72, in wrapper
    result = await method(view, request, data, *args, **kwargs)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/helpers/data_entry_flow.py", line 110, in post
    result = await self._flow_mgr.async_configure(flow_id, data)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/data_entry_flow.py", line 293, in async_configure
    result = await self._async_handle_step(
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/data_entry_flow.py", line 389, in _async_handle_step
    result: FlowResult = await getattr(flow, method)(user_input)
                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/config/custom_components/zha/config_flow.py", line 269, in async_step_manual_port_config
    if await self._radio_mgr.radio_type.controller.probe(user_input):
       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/zigpy_zboss/zigbee/application.py", line 480, in probe
    await nrf.connect()
  File "/usr/local/lib/python3.11/site-packages/zigpy_zboss/api.py", line 83, in connect
    "Connection to %s failed, cleaning up", self._port_path)
                                            ^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/zigpy_zboss/api.py", line 63, in _port_path
    return self._config[conf.CONF_DEVICE][conf.CONF_DEVICE_PATH]
           ~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^
KeyError: 'device'

The nrf52840 is showing up in lsusb

ha@ha:~/ha$
lsusb -t
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 5000M
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/2p, 480M
    |__ Port 1: Dev 2, If 0, Class=Communications, Driver=cdc_acm, 12M
    |__ Port 1: Dev 2, If 1, Class=CDC Data, Driver=cdc_acm, 12M
    |__ Port 1: Dev 2, If 2, Class=Mass Storage, Driver=usb-storage, 12M

ha@ha:~/ha$
ls -l /dev/ttyACM0
crw-rw---- 1 root dialout 166, 0 Nov  6 08:27 /dev/ttyACM0

Apologies if I'm posting this in the wrong place and thanks for the update!

Originally posted by @willpuckett in #28 (comment)

GitHub releases + PyPI packages of "zigpy-zboss"?

Can you please tag and releases zigpy-zboss (e.g. "v0.0.1", "v0.0.2", etc. ) here on GitHub?

https://github.com/kardia-as/zigpy-zboss/releases

And also make those released available via PyPI? At example:

https://pypi.org/project/zigpy-zboss/

Having even new small revisions released as new "versions" and available via PyPI makes it much easier for users to install it + updates.

https://docs.github.com/en/repositories/releasing-projects-on-github

See reusable GitHub workflows from the zigpy organization:

https://github.com/zigpy/workflows

Tagged release versions of zigpy libraries are automation packaged via GitHub Actions and made available via separate projects on PyPI:

https://pypi.org/project/zigpy/
https://pypi.org/project/zha-quirks/
https://pypi.org/project/bellows/
https://pypi.org/project/zigpy-znp/
https://pypi.org/project/zigpy-deconz/
https://pypi.org/project/zigpy-xbee/
https://pypi.org/project/zigpy-zigate/
https://pypi.org/project/zigpy-cc/ (obsolete as replaced by zigpy-znp)

PS: If this project later gets moved into the zigpy organization (like other similar radio libraries for zigpy have done previously) then remember to give admin access in the PyPI project to other zigpy members as well for several people have full access ;)

ZBOSS Zigbee network backup and network restore + radio migration via zigpy radio API?

zigpy's (new) radio API support unified commands for Zigbee network backup and network restore; will zigpy-zboss support this?

https://github.com/zigpy/zigpy-cli/blob/dev/README.md#network-commands
- https://github.com/zigpy/zigpy-cli/blob/dev/README.md#network-backup
  - https://github.com/zigpy/zigpy-cli/blob/dev/README.md#network-restore

Home Assistant’s ZHA integration uses this backup and restore feature by default and even support easy to use radio migration to allow migrating back and forth from one radio type to another radio type:

zigpy (and thus also Home Assistant’s ZHA integration) uses the self-developed open standard and open file format specified in the "Open ZigBee Coordinator Backup Format" project:

https://github.com/zigpy/open-coordinator-backup

Zigbee network backup to file and restore is also an important feature because it allows network migration to and from different radios.

https://skyconnect.home-assistant.io/zigbee-migration-selection/
- https://skyconnect.home-assistant.io/migrate-zigbee-zha-only/

Reference:

zigpy/zigpy-cli#2
zigpy/zigpy#1006
zigpy/zigpy-cli#13
zigpy/zigpy-znp#97
zigpy/bellows#445
zigpy/zigpy-deconz#172
zigpy/zigpy-zigate#117

PS: Some zigpy radio libraries, like zigpy-znp and bellows, also have extended CLI tools to perform full NVRAM backup and restore too, as well as other functions, such as for example NVRAM reset (which can also be useful before doing a restore from backup):

PPS: In addition suggest check out the unofficial “zha-toolkit” which adds additional services to ZHA (including for backup):

https://github.com/mdeweerd/zha-toolkit

https://community.home-assistant.io/t/zha-toolkit-a-big-set-of-zigbee-commands-on-top-of-zha-zigpy/373346

How to get started with zigpy-zboss and Home Assistant?

Hi there!

I have a number of Nordic DKs and dongles here (e.g. nRF52840 Dongle) and would love to connect these up to HA.

I've programmed up the dongle with the right firmware and I have tried to add the integration into HA. The serial port is detected but I can't see how to get zigpy-zboss in here to support zboss?

Any advice would be much appreciated !!!

Thanks,

Alex

zigpy-zboss radio library for ZHA installable as custom component for Home Assistant via HACS?

Any ideas on how to make this new radio library easier to test by pre-alpha testers without making installation too complicated?

Ex. install a custom repository via HACS (Home Assistant Community Store)? -> https://hacs.xyz/docs/faq/custom_repositories/

As one possible option, could it maybe be a good idea to try to update the old "zha-custom-radios" project (or fork puddly's old custom component from older zigpy-znp revisions that was mentioned since the v0.0.10 release?) in order to make the zigpy-zboss radio library easier for alpha/beta-testers to install as a custom component via HACS?

https://github.com/zha-ng/zha-custom-radios

That (now obsolete) "zha-custom-radios" project was a custom component package for Home Assistant (with its ZHA component for zigpy integration) that allows users to test out new zigpy radio libraries and hardware modules before they have officially been integrated into ZHA. This enabled developers and testers to test new or updated zigpy radio modules without having to modify the ZHA component in the Home Assistant core source code.

[DISCUSSION] Implement pre-release compatibility tests with Zigbee plugin for Jeedom?

@zoic21 Any chance you will be implementing pre-release compatibility tests with Zigbee plugin for Jeedom in order to help test this experimental ZBOSS radio library for zigpy (in other Zigbee gateway applications than ZHA integration for Home Assistant)?

https://doc.jeedom.com/en_US/plugins/automation%20protocol/zigbee/

https://doc.jeedom.com/en_US/plugins/automation%20protocol/zigbee/changelog

https://market.jeedom.com/index.php?v=d&p=market_display&id=4050

https://blog.jeedom.com/5183-tout-ce-quil-faut-savoir-sur-le-plugin-officiel-zigbee/

https://blog.jeedom.com/category/protocole/zigbee/

Note! Zigbee plugin for Jeedom is still developed in a closed repository so its development is not fully transparent, see discussion:

zigpy/zigpy#725

PS: I do not actually use Jeedom myself (nor do I speak French) so can't really post to ask this question in Jeedom's forums myself:

https://community.jeedom.com/t/plugin-officiel-zigbee/58321

zigpy-zboss compatibility with Python 3.12?

Has anyone checked if zigpy-zboss has any issues with Python 3.12 or if it is fully compatible with Python 3.12?

Not tested myself but since had issue with Python 3.11 as per #28 thought flag that the Home Assistant 2024.2 release is now shipping with Python 3.12 by default (which is currently the newest major release of the Python programming language):

https://www.home-assistant.io/blog/2024/02/07/release-20242/#shipping-on-a-new-python-version

Preferably testing Home Assistant Operating System (HA OS), alternatively Home Assistant Container and/or Supervised on Debian 12 with Python 3.12.x versions?

https://www.home-assistant.io/installation/#advanced-installation-methods

https://www.home-assistant.io/more-info/unsupported/os/

[REQUEST] nRF5340 (nRF53 series) support with pre-compiled ZBOSS NCP Host firmware image for nRF5340 DK?

Originally posted by @JohnConnett in #43 under discussions section https://github.com/kardia-as/zigpy-zboss/discussions

I have an nRF5340 DK. Has anyone successfully used zigpy-zboss with one of these? I presume I would have to compile the ZBOSS NCP Host firmware image myself configured to use maximum memory?

Is nRF5340 supported? Can you please provide a compiled ZBOSS NCP Host firmware image required to be flash on nRF5340 DK?

https://github.com/kardia-as/nrf-zboss-ncp

https://github.com/kardia-as/zigpy-zboss?tab=readme-ov-file#firmware

https://www.nordicsemi.com/Products/Development-hardware/nRF5340-DK

https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/samples/zigbee/ncp/README.html

For reference;

nRF5340 is the latest SoC from Nordic Semiconductor with Zigbee support (combining all features of nRF52840 and nRF52833):

https://www.nordicsemi.com/products/nrf5340

It features 1 MB Flash + 512 kB RAM, and it provides better RX sensitivity (less sensitive to EMF/RMI noise) while using less power.

https://www.nordicsemi.com/-/media/Software-and-other-downloads/Product-Briefs/nRF5340-SoC-PB.pdf

https://blog.nordicsemi.com/getconnected/why-does-the-nrf5340-have-two-cores

"The 0 dBm TX current is 3.4 mA, while the RX current is only 2.7 mA, resulting in a reduction of 29% and 41% when comparing to the nRF52840 SoC. The RX sensitivity is -98 dBm, 3 dB better than nRF52840, meaning that the nRF5340 provides 3 dB better sensitivity, while using 41% less current."

https://infocenter.nordicsemi.com/index.jsp?topic=%2Fps_nrf5340%2Fkeyfeatures_html5.html

https://www.nordicsemi.com/Products/Wireless/Zigbee

https://www.nordicsemi.com/Products/Development-software/nrf5-sdk-for-thread-and-zigbee

Other than using about half the power, another reason why you might want to add support for it is for its nRF5340-DK development kit:

https://www.nordicsemi.com/Products/Development-hardware/nrf5340-dk

Ebyte/cdEbyte have an E83-2G4M03S SMD radio module as well which can be found on their E83-2G4M03S-TB evaluation board

https://ebyteiot.com/products/nrf5340-wireless-mesh-bluetooth-test-board-usb-interface-cdebyte-e83-2g4m03s-tb-easy-to-develop-bluetooth-test-kit-ipex-antenna

https://www.cdebyte.com/products/E83-2G4M03S

https://www.cdebyte.com/products/E83-2G4M03S-TB

https://www.amazon.co.uk/EBYTE-nRF5340-Wireless-Bluetooth-E83-2G4M03S-TB/dp/B0CKQGX9M2

https://www.aliexpress.com/item/1005006108259017.html

https://www.alibaba.com/product-detail/EBYTE-E83-2G4M03S-TB-Small-size_1600959383696.html

https://www.alibaba.com/product-detail/COJXU-E83-2G4M03S-Small-size-and_1600959538223.html

For commercial and DIY projects there is a nRF5340 based radio modules (BT40F, BT40, BT40E, BT40N) from Fanstel Corp.

https://www.fanstel.com/bt40f-nrf5340

https://www.fanstel.com/bc40m-nrf5340

and u-blox

https://www.fanstel.com/buy/bt840f-v1-nrf52840-bluetooth-5-thread-zigbee-module-hscxm-n7trh

https://www.u-blox.com/en/search?query=nRF5340

Fix bind/unbind request

Device configuration fails because of a wrong type used in the Bind_Req method overwrite.

zigpy-zboss does not appear to be compatible with Python 3.11

@DamKast Created an new issue for tracking this (as Home Assistant and zigpy now require supporting Python 3.11 or later).

Originally posted by @puddly in #20 (comment)

zigpy-zboss does not appear to be compatible with Python 3.11.

@DamKast Since this repository is based on zigpy-znp, take a look at this PR I made to zigpy-znp that removes unnecessary type duplication within radio libraries: zigpy/zigpy-znp#225

zigpy/zigpy-znp#225

Fix ZDO IEEE_addr_req command

ZBOSS doesn't support ZDO commands over APSDE requests. Has specific commands for ZDO, this is why we need to overwrite the ZDO endpoint.

When a device is changing NWK address, zigpy doesn't know the new one, so it has to get it using ZDO IEEE_addr_req in order to update the database. For now IEEE_addr_req command has not been overwritten.

Error importing zigpy_zboss.zigbee.application

Running import zigpy_zboss.zigbee.application, I get the following error:

Python 3.11.5 (main, Sep 28 2023, 20:48:59) [GCC 12.2.1 20220924] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import zigpy_zboss.zigbee.application
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python3.11/site-packages/zigpy_zboss/zigbee/application.py", line 14, in <module>
    import zigpy_zboss.types as t_zboss
  File "/usr/local/lib/python3.11/site-packages/zigpy_zboss/types/__init__.py", line 2, in <module>
    from .basic import *  # noqa: F401, F403
    ^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/zigpy_zboss/types/basic.py", line 353, in <module>
    class enum_flag_uint8(enum_flag_factory(uint8_t)):
                          ^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/zigpy_zboss/types/basic.py", line 303, in enum_flag_factory
    class _NewEnum(int_type, enum.Flag):
  File "/usr/local/lib/python3.11/site-packages/zigpy_zboss/types/basic.py", line 307, in _NewEnum
    enum.IntFlag._create_pseudo_member_.__func__
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/enum.py", line 784, in __getattr__
    raise AttributeError(name) from None
AttributeError: _create_pseudo_member_
>>>

Given my startling unfamiliarity with python, this could likely be a user error. Any pointers?

zigpy-zboss and ZHA support for joining/pairing via install code and qr code with ZBOSS NCP Host based Zigbee Coordinator adapter?

Originally posted by @JohnConnett in #43

From a recent change to zigpy_zboss/zigbee/application.py it appears that adding a device using an install code is not implemented. Is that a limitation of the ZBOSS NCP Host firmware?

I do not myself have any Zigbee devices that require an install code for joining/pairing but I will ask since asked in above discussion:

Does zigpy-zboss and ZHA support for joining/pairing via install code and qr code with ZBOSS NCP Host based Zigbee Coordinator adapter?

Note! For reference about the question about install code see related issue for deconz based adapters here -> zigpy/zigpy-deconz#214

Some users of Home Assistant’s ZHA integration with ConBee and RaspBee Zigbee Coordinator adapters from dresden elektronik have posted that they could not join/pair their Bosch Smart Home Zigbee devices that required an install code, and then some other users replied to that post saying that install code (and qr code?) support is not implemented in this zigpy-deconz radio library for zigpy which the ZHA integration depends on. Is that true?

https://github.com/zigpy/zigpy-deconz/blob/80041b9dbf334e0224b95081fcd49bb2da3e8c5d/zigpy_deconz/zigbee/application.py#L108

Just reporting this issue reported in the Home Assistant community forum:

https://community.home-assistant.io/t/bosch-thermostat-2/492845/10

https://community.home-assistant.io/t/bosch-thermostat-2/492845/11

The first device in question was the Bosch Thermostat II 230 V (BTH-RA / BTH-RM230Z), however, I understand that some people using deCONZ or Zigbee2MQTT have reported the same issue with a few other Bosch-branded Zigbee devices, like Bosch Smoke Alarm II (BSD-2), Bosch Door/window contact II (RBSH-SWD-ZB), and Bosch BWA-1 water sensor, all of which require adding the install code to pair/join.

dresden-elektronik/deconz-rest-plugin#6476

dresden-elektronik/deconz-rest-plugin#6421

dresden-elektronik/deconz-rest-plugin#5190

I do not have a ConBee or RaspBee setup as Zigbee Coordinator myself any longer so can not replicate to confirm or deny but think this should be tracked if a feature is missing since supported by Silicon Labs and Texas Instruments based Zigbee Coordinator adapters via their respective radio library for zigpy.

PS: Both Silicon Labs (bellows) and Texas Instruments (zigpy-znp) radio libraries for zigpy do support install code (and qr code) or?

https://github.com/zigpy/bellows/blob/8549f277027245f5e63ce1341b7e6c5c75381899/bellows/zigbee/application.py#L845-L866

https://github.com/zigpy/zigpy-znp/blob/c4db8d1151b5a999ead73480faea4ea01b7cb7d7/zigpy_znp/zigbee/application.py#L338-L377

watchdog compatibility with latest zigpy

zigpy-zboss radio library for zigpy does not yet seem compatible with the "watchdog" changes that was made to zigpy last year?

See references:

https://github.com/zigpy/zigpy/pulls?q=is%3Apr+watchdog+is%3Aclosed

and

https://github.com/zigpy/bellows/pulls?q=is%3Apr+watchdog+is%3Aclosed

PS: Also see puddly's reply in home-assistant/core#114828 indicates that this and adding unit tests are currently showstoppers.

Aqara Smart Vibration Sensor leaves network immediately on pairing

The Aqara Smart Vibration Sensor leaves the network immediately after pairing (showing as Unavailable in HA). Does not come back when pressing the identify button on the device and requires re-pairing.

2024-02-17 20:43:22.054 DEBUG (MainThread) [zigpy.application] Feeding watchdog
2024-02-17 20:43:25.523 INFO (MainThread) [zigpy.application] Device 0x5d9a (00:15:8d:00:01:0f:cb:b9) joined the network
2024-02-17 20:43:25.525 DEBUG (MainThread) [zigpy.application] Device 00:15:8d:00:01:0f:cb:b9 changed id (0xb2fe => 0x5d9a)
2024-02-17 20:43:25.527 DEBUG (MainThread) [zigpy.device] [0x5d9a] Skipping initialization, device is fully initialized
2024-02-17 20:43:25.528 DEBUG (MainThread) [zigpy.application] Device is initialized <VibrationAQ1 model='lumi.vibration.aq1' manuf='LUMI' nwk=0x5D9A ieee=00:15:8d:00:01:0f:cb:b9 is_initialized=True>
2024-02-17 20:43:25.576 DEBUG (MainThread) [zigpy.application] Received a packet: ZigbeePacket(timestamp=datetime.datetime(2024, 2, 17, 7, 43, 25, 576547, tzinfo=datetime.timezone.utc), src=AddrModeAddress(addr_mode=<AddrMode.NWK: 2>, address=0x5D9A), src_ep=1, dst=AddrModeAddress(addr_mode=<AddrMode.NWK: 2>, address=0x0000), dst_ep=1, source_route=None, extended_timeout=False, tsn=0, profile_id=260, cluster_id=0, data=Serialized[b'\x18\x00\n\x05\x00B\x12lumi.vibration.aq1\x01\x00 \x08'], tx_options=<TransmitOptions.NONE: 0>, radius=0, non_member_radius=0, lqi=192, rssi=-44)
2024-02-17 20:43:25.581 DEBUG (MainThread) [zigpy.zcl] [0x5D9A:1:0x0000] Received ZCL frame: b'\x18\x00\n\x05\x00B\x12lumi.vibration.aq1\x01\x00 \x08'
2024-02-17 20:43:25.583 DEBUG (MainThread) [zigpy.zcl] [0x5D9A:1:0x0000] Decoded ZCL frame header: ZCLHeader(frame_control=FrameControl<0x18>(frame_type=<FrameType.GLOBAL_COMMAND: 0>, is_manufacturer_specific=0, direction=<Direction.Server_to_Client: 1>, disable_default_response=1, reserved=0, *is_cluster=False, *is_general=True), tsn=0, command_id=10, *direction=<Direction.Server_to_Client: 1>)
2024-02-17 20:43:25.588 DEBUG (MainThread) [zigpy.zcl] [0x5D9A:1:0x0000] Decoded ZCL frame: VibrationBasicCluster:Report_Attributes(attribute_reports=[Attribute(attrid=0x0005, value=TypeValue(type=CharacterString, value='lumi.vibration.aq1')), Attribute(attrid=0x0001, value=TypeValue(type=uint8_t, value=8))])
2024-02-17 20:43:25.591 DEBUG (MainThread) [zigpy.zcl] [0x5D9A:1:0x0000] Received command 0x0A (TSN 0): Report_Attributes(attribute_reports=[Attribute(attrid=0x0005, value=TypeValue(type=CharacterString, value='lumi.vibration.aq1')), Attribute(attrid=0x0001, value=TypeValue(type=uint8_t, value=8))])
2024-02-17 20:43:25.593 DEBUG (MainThread) [zigpy.zcl] [0x5D9A:1:0x0000] Attribute report received: model='lumi.vibration.aq1', app_version=8
2024-02-17 20:43:26.791 DEBUG (MainThread) [zigpy.application] Received a packet: ZigbeePacket(timestamp=datetime.datetime(2024, 2, 17, 7, 43, 26, 790875, tzinfo=datetime.timezone.utc), src=AddrModeAddress(addr_mode=<AddrMode.NWK: 2>, address=0x5D9A), src_ep=1, dst=AddrModeAddress(addr_mode=<AddrMode.NWK: 2>, address=0x0000), dst_ep=1, source_route=None, extended_timeout=False, tsn=95, profile_id=260, cluster_id=0, data=Serialized[b'\x1c_\x11\x01\n\x01\xffB.\x01!O\x0b\x03(\x1f\x04!\xa8\x01\x05!Z\x00\x06$\x01\x00\x00\x00\x00\x08!\x08\x03\n!\x00\x00\x98!(\x00\x99!\x00\x00\x9a%\x12\x00=\xfc\xb1\x01'], tx_options=<TransmitOptions.NONE: 0>, radius=0, non_member_radius=0, lqi=156, rssi=-55)
2024-02-17 20:43:26.796 DEBUG (MainThread) [zigpy.zcl] [0x5D9A:1:0x0000] Received ZCL frame: b'\x1c_\x11\x01\n\x01\xffA.\x01!O\x0b\x03(\x1f\x04!\xa8\x01\x05!Z\x00\x06$\x01\x00\x00\x00\x00\x08!\x08\x03\n!\x00\x00\x98!(\x00\x99!\x00\x00\x9a%\x12\x00=\xfc\xb1\x01'
2024-02-17 20:43:26.799 DEBUG (MainThread) [zigpy.zcl] [0x5D9A:1:0x0000] Decoded ZCL frame header: ZCLHeader(frame_control=FrameControl<0x1C>(frame_type=<FrameType.GLOBAL_COMMAND: 0>, is_manufacturer_specific=True, direction=<Direction.Server_to_Client: 1>, disable_default_response=1, reserved=0, *is_cluster=False, *is_general=True), manufacturer=4447, tsn=1, command_id=10, *direction=<Direction.Server_to_Client: 1>)
2024-02-17 20:43:26.803 DEBUG (MainThread) [zigpy.zcl] [0x5D9A:1:0x0000] Decoded ZCL frame: VibrationBasicCluster:Report_Attributes(attribute_reports=[Attribute(attrid=0xFF01, value=TypeValue(type=LVBytes, value=b'\x01!O\x0b\x03(\x1f\x04!\xa8\x01\x05!Z\x00\x06$\x01\x00\x00\x00\x00\x08!\x08\x03\n!\x00\x00\x98!(\x00\x99!\x00\x00\x9a%\x12\x00=\xfc\xb1\x01'))])
2024-02-17 20:43:26.805 DEBUG (MainThread) [zigpy.zcl] [0x5D9A:1:0x0000] Received command 0x0A (TSN 1): Report_Attributes(attribute_reports=[Attribute(attrid=0xFF01, value=TypeValue(type=LVBytes, value=b'\x01!O\x0b\x03(\x1f\x04!\xa8\x01\x05!Z\x00\x06$\x01\x00\x00\x00\x00\x08!\x08\x03\n!\x00\x00\x98!(\x00\x99!\x00\x00\x9a%\x12\x00=\xfc\xb1\x01'))])
2024-02-17 20:43:26.807 DEBUG (MainThread) [zigpy.zcl] [0x5D9A:1:0x0000] Attribute report received: 0xFF01=b'\x01!O\x0b\x03(\x1f\x04!\xa8\x01\x05!Z\x00\x06$\x01\x00\x00\x00\x00\x08!\x08\x03\n!\x00\x00\x98!(\x00\x99!\x00\x00\x9a%\x12\x00=\xfc\xb1\x01'
2024-02-17 20:43:28.950 DEBUG (MainThread) [zigpy.application] Received a packet: ZigbeePacket(timestamp=datetime.datetime(2024, 2, 17, 7, 43, 28, 950729, tzinfo=datetime.timezone.utc), src=AddrModeAddress(addr_mode=<AddrMode.NWK: 2>, address=0x5D9A), src_ep=1, dst=AddrModeAddress(addr_mode=<AddrMode.NWK: 2>, address=0x0000), dst_ep=1, source_route=None, extended_timeout=False, tsn=2, profile_id=260, cluster_id=257, data=Serialized[b'\x18\x02\nU\x00!\x01\x00'], tx_options=<TransmitOptions.NONE: 0>, radius=0, non_member_radius=0, lqi=136, rssi=-59)
2024-02-17 20:43:28.954 DEBUG (MainThread) [zigpy.zcl] [0x5D9A:1:0x0101] Received ZCL frame: b'\x18\x02\nU\x00!\x01\x00'
2024-02-17 20:43:28.956 DEBUG (MainThread) [zigpy.zcl] [0x5D9A:1:0x0101] Decoded ZCL frame header: ZCLHeader(frame_control=FrameControl<0x18>(frame_type=<FrameType.GLOBAL_COMMAND: 0>, is_manufacturer_specific=0, direction=<Direction.Server_to_Client: 1>, disable_default_response=1, reserved=0, *is_cluster=False, *is_general=True), tsn=2, command_id=10, *direction=<Direction.Server_to_Client: 1>)
2024-02-17 20:43:28.962 DEBUG (MainThread) [zigpy.zcl] [0x5D9A:1:0x0101] Decoded ZCL frame: MultistateInputCluster:Report_Attributes(attribute_reports=[Attribute(attrid=0x0055, value=TypeValue(type=uint16_t, value=1))])
2024-02-17 20:43:28.964 DEBUG (MainThread) [zigpy.zcl] [0x5D9A:1:0x0101] Received command 0x0A (TSN 2): Report_Attributes(attribute_reports=[Attribute(attrid=0x0055, value=TypeValue(type=uint16_t, value=1))])
2024-02-17 20:43:28.966 DEBUG (MainThread) [zigpy.zcl] [0x5D9A:1:0x0101] Attribute report received: present_value=1
2024-02-17 20:43:28.968 DEBUG (MainThread) [zigpy.zcl] [0x5D9A:1:0x0500] 00:15:8d:00:01:0f:cb:b9 - Received motion event message
2024-02-17 20:43:30.032 DEBUG (MainThread) [zigpy.application] Received a packet: ZigbeePacket(timestamp=datetime.datetime(2024, 2, 17, 7, 43, 30, 31991, tzinfo=datetime.timezone.utc), src=AddrModeAddress(addr_mode=<AddrMode.NWK: 2>, address=0x5D9A), src_ep=1, dst=AddrModeAddress(addr_mode=<AddrMode.NWK: 2>, address=0x0000), dst_ep=1, source_route=None, extended_timeout=False, tsn=3, profile_id=260, cluster_id=257, data=Serialized[b'\x18\x03\nU\x00!\x02\x00\x03\x05!A\x00'], tx_options=<TransmitOptions.NONE: 0>, radius=0, non_member_radius=0, lqi=184, rssi=-47)
2024-02-17 20:43:30.035 DEBUG (MainThread) [zigpy.zcl] [0x5D9A:1:0x0101] Received ZCL frame: b'\x18\x03\nU\x00!\x02\x00\x03\x05!A\x00'
2024-02-17 20:43:30.037 DEBUG (MainThread) [zigpy.zcl] [0x5D9A:1:0x0101] Decoded ZCL frame header: ZCLHeader(frame_control=FrameControl<0x18>(frame_type=<FrameType.GLOBAL_COMMAND: 0>, is_manufacturer_specific=0, direction=<Direction.Server_to_Client: 1>, disable_default_response=1, reserved=0, *is_cluster=False, *is_general=True), tsn=3, command_id=10, *direction=<Direction.Server_to_Client: 1>)
2024-02-17 20:43:30.043 DEBUG (MainThread) [zigpy.zcl] [0x5D9A:1:0x0101] Decoded ZCL frame: MultistateInputCluster:Report_Attributes(attribute_reports=[Attribute(attrid=0x0055, value=TypeValue(type=uint16_t, value=2)), Attribute(attrid=0x0503, value=TypeValue(type=uint16_t, value=65))])
2024-02-17 20:43:30.046 DEBUG (MainThread) [zigpy.zcl] [0x5D9A:1:0x0101] Received command 0x0A (TSN 3): Report_Attributes(attribute_reports=[Attribute(attrid=0x0055, value=TypeValue(type=uint16_t, value=2)), Attribute(attrid=0x0503, value=TypeValue(type=uint16_t, value=65))])
2024-02-17 20:43:30.049 DEBUG (MainThread) [zigpy.zcl] [0x5D9A:1:0x0101] Attribute report received: present_value=2, 0x0503=65
2024-02-17 20:43:30.072 DEBUG (MainThread) [zigpy.application] Received a packet: ZigbeePacket(timestamp=datetime.datetime(2024, 2, 17, 7, 43, 30, 72880, tzinfo=datetime.timezone.utc), src=AddrModeAddress(addr_mode=<AddrMode.NWK: 2>, address=0x5D9A), src_ep=1, dst=AddrModeAddress(addr_mode=<AddrMode.NWK: 2>, address=0x0000), dst_ep=1, source_route=None, extended_timeout=False, tsn=4, profile_id=260, cluster_id=257, data=Serialized[b'\x18\x04\n\x08\x05%\t\x00\xeb\xff\xb2\x04'], tx_options=<TransmitOptions.NONE: 0>, radius=0, non_member_radius=0, lqi=184, rssi=-47)
2024-02-17 20:43:30.076 DEBUG (MainThread) [zigpy.zcl] [0x5D9A:1:0x0101] Received ZCL frame: b'\x18\x04\n\x08\x05%\t\x00\xeb\xff\xb2\x04'
2024-02-17 20:43:30.078 DEBUG (MainThread) [zigpy.zcl] [0x5D9A:1:0x0101] Decoded ZCL frame header: ZCLHeader(frame_control=FrameControl<0x18>(frame_type=<FrameType.GLOBAL_COMMAND: 0>, is_manufacturer_specific=0, direction=<Direction.Server_to_Client: 1>, disable_default_response=1, reserved=0, *is_cluster=False, *is_general=True), tsn=4, command_id=10, *direction=<Direction.Server_to_Client: 1>)
2024-02-17 20:43:30.088 DEBUG (MainThread) [zigpy.zcl] [0x5D9A:1:0x0101] Decoded ZCL frame: MultistateInputCluster:Report_Attributes(attribute_reports=[Attribute(attrid=0x0508, value=TypeValue(type=uint48_t, value=5166844280841))])
2024-02-17 20:43:30.090 DEBUG (MainThread) [zigpy.zcl] [0x5D9A:1:0x0101] Received command 0x0A (TSN 4): Report_Attributes(attribute_reports=[Attribute(attrid=0x0508, value=TypeValue(type=uint48_t, value=5166844280841))])
2024-02-17 20:43:30.092 DEBUG (MainThread) [zigpy.zcl] [0x5D9A:1:0x0101] Attribute report received: 0x0508=5166844280841
2024-02-17 20:43:47.971 INFO (MainThread) [zigpy.application] Device 0x5d9a (00:15:8d:00:01:0f:cb:b9) left the network
2024-02-17 20:43:52.056 DEBUG (MainThread) [zigpy.application] Feeding watchdog

Confirm firmware and hardware compatibility with Holyiot 21017 and Holyiot 22046 USB dongles?

Holyiot makes two nice looking nRF52840 based USB dongles, one with external antenna and one really small with PCB antenna.

These two are white-label products that Holyiot primarily manufacture and sells as ODM/OEM for rebranding.

Holyiot 21017 (model HOLYIOT-21017-nRF52840) = nRF52840 USB dongle with PA (Power Amplifier) and external antenna:

http://www.holyiot.com/eacp_view.asp?id=336

http://www.holyiot.com/tp/2021091017064271075.pdf

https://www.aliexpress.us/item/1005004684681671.html

https://www.aliexpress.us/item/1005004834781868.html

https://www.aliexpress.us/item/1005004673179004.html

https://www.aliexpress.us/item/1005004674423113.html

https://www.aliexpress.us/item/1005004684681671.html

Holyiot 22046 (Model: YJ-17120-USB or HOLYIOT-22046-USB) = Black or white mini nRF52840 USB dongle with PCB antenna:

http://www.holyiot.com/eacp_view.asp?id=280

http://www.holyiot.com/tp/2019042610332671697.pdf

https://www.aliexpress.us/item/1005004744954818.html

https://www.aliexpress.us/item/1005004745012331.html

https://www.aliexpress.us/item/1005004764916464.html

https://www.aliexpress.us/item/1005004744954818.html

https://www.aliexpress.us/item/1005004709614119.html

https://www.aliexpress.us/item/1005004834848674.html

PS: According to the sales page these should support USB description to show up as "Holyiot-21017" and "Holyiot-22046" and if so they could be whitelisted in Home Assistant's ZHA integration and Home Assistant Core for automatic USB discovery:

https://community.home-assistant.io/t/community-help-wanted-to-whitelist-all-compatible-zigbee-and-z-wave-dongles-adapters-for-automatic-usb-discovery-in-home-assistant/344412

https://www.home-assistant.io/blog/2021/09/01/release-20219/#usb-discovery

https://www.home-assistant.io/integrations/usb/

[SUGGESTION] Move zigpy-zboss repository to the shared zigpy organization?

@DamKast can I suggest that you consider asking/discussing the possibility with puddly of having this zigpy-zboss repository moved from https://github.com/kardia-as/zigpy-zboss moved to the zigpy organization @ https://github.com/zigpy/ on GitHub so that the mainstream copy of this repo will stay there become upstream for shared access together by the collective of developers that make up the zigpy organization?

That is, make puddly and the other administrators from the zigpy project co-administrators of this repository and then have them move this whole repository from https://github.com/kardia-as/zigpy-zboss to https://github.com/zigpy/zigpy-zboss

That "organization" is just GitHub's terminology as I understand it is more or less still only an informal collaboration between like-minded ZHA and zigpy developers in order to collect ZHA and zigpy projects ín one place and shared access rights, (noting that the zigpy organization on GitHub has no public members and that you must be a member to see who’s a part of that organization, which I am not myself).

https://github.com/zigpy/

Note that this does not mean that support for zigpy-zboss have to be implemeneted upstream into Home Assistant's ZHA integration right away. This zigpy-zboss can still remain experimental. I am however sure that it would gain much more attention from additional third-party developers if this repository belonged to the existing zigpy organization.

Most other ZHA related repositories have sooner or later been moved to the zigpy organization over time as a way for like-minded ZHA and zigpy developers that are members of the zigpy organization with yourself included can have shared ownership and access to your zigpy-zboss repository and the other projects for collaboration within that community.

Again, moving this zigpy-zboss repository there could potentially also help both new ZHA/zigpy developers and others to take more notice that this zigpy-zboss radio library project exist (which is much less likely with it remaining here) and hopefully more developers will then eventually be interested to help and assistant with improving and maintaining.

Perhaps ask if could do the same with your nrf-zboss-ncp repo with your reference firmware image for testing?

https://github.com/kardia-as/nrf-zboss-ncp

Hope that you at least will consider this option and if you think it is a good idea then hoping that you all could come to an agreement that will make everyone happy with you continuing this zigpy-zboss repository under the zigpy organization together without getting offended by any ownership conflicts.

Anyway, I believe a prerequire might be that add unit tests are added to zigpy-zboss in order to lessen the maintenance burden:

PS: By the way, the same people who are members of that zigpy organization on GitHub also share another GitHub organization called "zha-ng" (guess it is short for "ZHA next-generation"?) which contains additional early experimental projects before they became mature to be moved:

https://github.com/zha-ng

Confirm firmware and hardware compatibility with Ebyte E104-BT5040U USB dongle?

Have anyone confirmed if zigpy-zboss is compatible with Ebyte E104-BT5040U USB dongle (nRF52840 USB dongle from Ebyte)?

https://www.ebyte.com/en/product-view-news.html?id=1185

https://aliexpress.com/item/1005004262523219.html

https://aliexpress.com/item/1005005170155707.html

https://aliexpress.com/item/1005004625325848.html

https://aliexpress.com/item/1005002524165798.html

Note they also sell other models than the ” E104-BT5040U” model on same Aliextress items.