Hello, I would like to use my conbee2 key as a router on my zigbee network under zigbeemqtt.
is there firmware to flash my key as a router?
THANKS

@manup Requesting an "energy detection scan" feature (with documented API) in deconz serial protocol

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

zigpy/zigpy-deconz#130

Hope can be used by zigpy-deconz (so if possible something similar what @puddly has added to zigpy-znp radio library for zigpy).

Suggest implement similar channel energy scanning via some energy scanner tool but for DeCONZ based firmware and hardware.

https://github.com/zha-ng/zigpy-znp

https://github.com/zha-ng/zigpy-znp/blob/dev/README.md

That command and feature is in turn used in zigpy-cli (a unified command line interface for zigpy radios):

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

Energy scan

Perform an energy scan to find a quiet Zigbee channel:

$ python -m zigpy_znp.tools.energy_scan /dev/cu.usbmodem14101
Channel energy (mean of 1 / 5):
------------------------------------------------
 + Lower energy is better
 + Active Zigbee networks on a channel may still cause congestion
 + Using 26 in the USA may have lower TX power due to FCC regulations
 + Zigbee channels 15, 20, 25 fall between WiFi channels 1, 6, 11
 + Some Zigbee devices only join networks on channels 15, 20, and 25
------------------------------------------------
 - 11    61.57%  #############################################################
 - 12    60.78%  ############################################################
 - 13    12.16%  ############
 - 14    58.43%  ##########################################################
 - 15    57.65%  #########################################################
 - 16    29.80%  #############################
 - 17    38.82%  ######################################
 - 18    47.06%  ###############################################
 - 19    36.86%  ####################################
 - 20    10.98%  ##########
 - 21    16.47%  ################
 - 22    33.73%  #################################
 - 23    30.59%  ##############################
 - 24    20.39%  ####################
 - 25     5.88%  #####
 - 26*   20.39%  ####################

For an automation system I would like to receive commands from a Sunricher ZGRC-KEY-013 (firmware 2.5.3_r20) Zigbee remote control using a ConBee II (version 2.05.84 / 9/14/2020, firmware 26660700) on a Raspberry Pi 4 using Python 3. So I'm not using deCONZ.

I have found 'Serial protocol' version 1.14 (2019-05-25), but that seems to be a little outdated according to other topics. Do you have a newer version of the protocol?

Using deCONZ the remote control is linked to the ConBee II. When you open deCONZ both are visible and when you press a key a green line appears to the left off both connecting them.

Using some demo code I have written a Python program that can communicate with the ConBee II via the SLIP protocol and also full CRC support is implemented.

So far so good.

But when I press a key on the remote control the ConBee II sends a message and the program responds:

Rx: 29-10-2020 15:47:51.099 1C-03-00-0C-00-05-00-02-0F-8B-FF-E1
Rx: MAC Poll Notification [0x1C]: Status: Success, NWK: 8B-0F, LQI = 255, RSSI = 225
Rx: 29-10-2020 15:47:51.102 0E-04-00-07-00-AA-00
Rx: Device state changed [0x0E]: Status: Success, Network: connected, APSE-DATA indication, APSE-DATA request free slots
Tx: APS_DATA_INDICATION request
Tx: C0-04-04-00-07-00-00-00-F1-FF-C0
Rx: 29-10-2020 15:47:51.105 1C-05-00-0C-00-05-00-02-0F-8B-FF-E1
Rx: MAC Poll Notification [0x1C]: Status: Success, NWK: 8B-0F, LQI = 255, RSSI = 225
Rx: 29-10-2020 15:47:51.107 04-04-05-08-00-01-00-2A
Rx: Query Send Data State Response, short [0x04]; Status: Error
Tx: Read Received Data Request request
Tx: C0-17-04-00-08-00-01-DC-FF-C0
Rx: 29-10-2020 15:47:51.171 1C-05-00-0C-00-05-00-02-0F-8B-FF-E1
Rx: MAC Poll Notification [0x1C]: Status: Success, NWK: 8B-0F, LQI = 255, RSSI = 225
Rx: 29-10-2020 15:47:52.083 0E-06-00-07-00-AA-00
Rx: Device state changed [0x0E]: Status: Success, Network: connected, APSE-DATA indication, APSE-DATA request free slots
Tx: APS_DATA_INDICATION request
Tx: C0-04-06-00-07-00-00-00-EF-FF-C0
Rx: 29-10-2020 15:47:52.086 1C-07-00-0C-00-05-00-02-0F-8B-FF-E1
Rx: MAC Poll Notification [0x1C]: Status: Success, NWK: 8B-0F, LQI = 255, RSSI = 225
Rx: 29-10-2020 15:47:52.089 04-06-05-08-00-01-00-2A
Rx: Query Send Data State Response, short [0x04]; Status: Error
Tx: Read Received Data Request request
Tx: C0-17-06-00-08-00-01-DA-FF-C0
Rx: 29-10-2020 15:47:53.090 1C-07-00-0C-00-05-00-02-0F-8B-FF-E1
Rx: MAC Poll Notification [0x1C]: Status: Success, NWK: 8B-0F, LQI = 255, RSSI = 225
Rx: 29-10-2020 15:47:54.193 0E-08-00-07-00-AA-00
Rx: Device state changed [0x0E]: Status: Success, Network: connected, APSE-DATA indication, APSE-DATA request free slots
Tx: APS_DATA_INDICATION request
Tx: C0-04-08-00-07-00-00-00-ED-FF-C0
Rx: 29-10-2020 15:47:54.195 1C-09-00-0C-00-05-00-02-0F-8B-FF-E1
Rx: MAC Poll Notification [0x1C]: Status: Success, NWK: 8B-0F, LQI = 255, RSSI = 225
Rx: 29-10-2020 15:47:54.197 04-08-05-08-00-01-00-2A
Rx: Query Send Data State Response, short [0x04]; Status: Error
Tx: Read Received Data Request request
Tx: C0-17-08-00-08-00-01-D8-FF-C0
Rx: 29-10-2020 15:47:55.115 1C-09-00-0C-00-05-00-02-0F-8B-FF-E1
Rx: MAC Poll Notification [0x1C]: Status: Success, NWK: 8B-0F, LQI = 255, RSSI = 225
Rx: 29-10-2020 15:47:56.217 1C-0A-00-0C-00-05-00-02-0F-8B-FF-E1
Rx: MAC Poll Notification [0x1C]: Status: Success, NWK: 8B-0F, LQI = 255, RSSI = 225
Rx: 29-10-2020 15:47:57.137 1C-0B-00-0C-00-05-00-02-0F-8B-FF-E1
Rx: MAC Poll Notification [0x1C]: Status: Success, NWK: 8B-0F, LQI = 255, RSSI = 225

The ConBee II reports an error at the [0x04] message so something is going wrong. And whatever key I press, I cannot find some info about what key was pressed on the remote control.

Is there a description about the sequence of messages needed while communicating with the ConBee II to get some info about the key being pressed?

This is the used configuration:

Host system: Raspberry Pi 4
Running method: Raspbian
Firmware version: (26660700) ConBee II (version 2.05.84 / 9/14/2020, firmware 26660700)
deCONZ version: (2.05.84)
Device: ConBee II and Sunricher ZGRC-KEY-013 (firmware 2.5.3_r20) Zigbee remote control

Dresden-Elektronik should consider adding native serial protocol (UART) support for ConBee and RaspBee hardware to open source home automation software such as Home Assistant and its Hass.io (Home Assistant appliance OS for RAspberry Pi).

That is, make open source home automation software such as Home Assistant support using ConBee and RaspBee adapters directly via serial potocol over UART and CLI using existing open source Zigbee libraries without the need to the deCONZ gateway software.

Commercial motivation for Dresden-Elektronik; open source home automation software such as Home Assistant and Hass.io (Home Assistant embedded Linux OS for Raspberry Pi) are the very popular today and as they are already available and used by perhaps millions of people right now, Dresden-Elektronik would most likely sell many more devices if its RaspBee and ConBee hardware had native support them inside open source home automation software such as Home Assistant and Hass.io

Please checkout: https://home-assistant.io

as well as

https://home-assistant.io/hassio/

Home Assistant recently gained native serial protocol (UART) support for ZigBee Home Automation via the ZigPy (Zigbee for Python) open source library that currently can only communicate with XBee and EmberZNet based devices (competing USB adapter by Silicon Labs) via other Python modules which in turn communicates with different radios native serial protocol (UART) for zigpy, for more information see:

https://github.com/zigpy/zigpy

https://github.com/zigpy/bellows
https://github.com/zigpy/zigpy-xbee
https://github.com/doudz/zigpy-zigate

Update! @damarco and @Equidamoid have both independently started working on zigpy radio libraries a native serial UART protocol for Conbee/Raspbee here:

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

https://github.com/Equidamoid/pyconz/

See also:

https://home-assistant.io/components/zha/

https://github.com/home-assistant/home-assistant/tree/dev/homeassistant/components/zha

home-assistant/core#6263

home-assistant/core#12187

home-assistant/core#19664

home-assistant/frontend#2389

home-assistant/frontend#2421

In the documentation it's written that for the query send data response command the frame length is 7.
In practice it has been 7 + Payload length.

A typo I think? Is it possible to fix that?

Thank you!

Version information from the stick:
2.11.02 / 14/03/2021
266B0700

According to the documentation after sending: APS_DATA_INDICATION command (17 : 24: 00: 07:00: 00:00: 3A:FF:C0)

APS_DATA_INDICATION 0x17 - Sequence 0x24 - Reserved 0x00 - Frame length 0x0007 - Payload length 0x0000 - Checksum 0xFF3A

I should receive the data, but nothing happens. Anything I am missing here ? Also the Device State (0x0E) report 0xA6. This is 1010:0110. What does this highest bit mean ? Documentation does not describe the two highest bits, but the highest bit (0x80) is on ???

Full log:
Receiving: 0E:20:00:07:00:A6:00
Sending: 04:22:00:07:00:00:00 Checksum 4F:FF
Receiving: 0E:21:00:07:00:AE:00
Sending: 17:24:00:07:00:00:00 Checksum 3A:FF
Receiving: 0E:22:00:07:00:AE:00
Sending: 17:26:00:07:00:00:00 Checksum 38:FF

Hi.

I have home assistant supervised installed on intel nuc. The conbee ii is configured and all is working fine. The only problem I have is when I reboot my home assistant (host reboot) most of the time the conbee II is not detected by home assistant os and I have to restart home assistant few times to get it back.

I am using device: /dev/ttyACM0 in configuration for deconz addon. (tried all different configurations but when conbee is not detected by the os this is not helping)
When conbee ii is not detected after reboot I can’t see it in devices available in hardware of a host (no usb devices detected).
Conbee ii is connected through usb2 extension to intel nuc. I have tried every usb port, tried using it without usb extension etc.. but no luck.
Can you pls help me with this problem. Is it possible that conbee ii might be faulty?

Documentation and code need to be updated to say "Zigbee" instead of "ZigBee" as the official Zigbee Alliance changed the Zigbee name stylization from “ZigBee” to “Zigbee”, as in they are no longer writing Zigbee with a capital “B” in the middle of the name.

All initializations seems to succeed on the RPI (Raspbee) Panid = 0xDEAF, Channel 15. All configuration succeeds over the serial port, log below but it looks like I do not receive any messages from the radio (from other devices).
I am writing the serial interface in the context of the RDK stack (so from scratch, using your documentation here) and with the USB stick (CONBEE) the same code works fine (it does receive data from other nodes).
Could it be that for the Raspbee I need to enable the SW1 pin [11] for the radio to turn on ? Or do I need to move the reset pin [12] to an output (I assume that due to the fact that by default it is an input, it is sufficient).

Log of the intialization:
Jan 1 00:00:04 buildroot user.notice /usr/bin/bridge[212]: [00:00:04]: Send: 0D:01:00:09:00:00:00:00:00:E9:FF
Jan 1 00:00:04 buildroot user.notice /usr/bin/bridge[212]: [00:00:04]: Received: 0D:01:00:09:00:00:05:39:26
Jan 1 00:00:04 buildroot user.notice /usr/bin/bridge[212]: [00:00:04]: Metadata: Version: 38.57 Platform: "Conbee"
Jan 1 00:00:04 buildroot user.notice /usr/bin/bridge[212]: [00:00:04]: Send: 0A:02:00:08:00:01:00:01:EA:FF
Jan 1 00:00:04 buildroot user.notice /usr/bin/bridge[212]: [00:00:04]: Received: 0A:02:00:10:00:09:00:01:E7:41:01:FF:FF:2E:21:00
Jan 1 00:00:04 buildroot user.notice /usr/bin/bridge[212]: [00:00:04]: Read: Parameter "MAC Address"
Jan 1 00:00:04 buildroot user.notice /usr/bin/bridge[212]: [00:00:04]: Send: 0A:03:00:08:00:01:00:07:E3:FF
Jan 1 00:00:04 buildroot user.notice /usr/bin/bridge[212]: [00:00:04]: Received: 0A:03:00:0A:00:03:00:07:00:00
Jan 1 00:00:04 buildroot user.notice /usr/bin/bridge[212]: [00:00:04]: Read: Parameter "Network address"
Jan 1 00:00:04 buildroot user.notice /usr/bin/bridge[212]: [00:00:04]: Send: 0A:04:00:08:00:01:00:09:E0:FF
Jan 1 00:00:04 buildroot user.notice /usr/bin/bridge[212]: [00:00:04]: Received: 0A:04:00:09:00:02:00:09:01
Jan 1 00:00:04 buildroot user.notice /usr/bin/bridge[212]: [00:00:04]: Read: Parameter "APS Designed mode"
Jan 1 00:00:04 buildroot user.notice /usr/bin/bridge[212]: [00:00:04]: Send: 0A:05:00:08:00:01:00:22:C6:FF
Jan 1 00:00:04 buildroot user.notice /usr/bin/bridge[212]: [00:00:04]: Received: 0A:05:00:0A:00:03:00:22:0C:01
Jan 1 00:00:04 buildroot user.notice /usr/bin/bridge[212]: [00:00:04]: Read: Parameter "Protocol version"
Jan 1 00:00:04 buildroot user.notice /usr/bin/bridge[212]: [00:00:04]: Send: 0A:06:00:08:00:01:00:05:E2:FF
Jan 1 00:00:04 buildroot user.notice /usr/bin/bridge[212]: [00:00:04]: Received: 0A:06:00:0A:00:03:00:05:AF:DE
Jan 1 00:00:04 buildroot user.notice /usr/bin/bridge[212]: [00:00:04]: Read: Parameter "Network PAN Id"
Jan 1 00:00:04 buildroot user.notice /usr/bin/bridge[212]: [00:00:04]: Send: 0A:07:00:08:00:01:00:0A:DC:FF
Jan 1 00:00:04 buildroot user.notice /usr/bin/bridge[212]: [00:00:04]: Received: 0A:07:00:0C:00:05:00:0A:00:80:00:00
Jan 1 00:00:04 buildroot user.notice /usr/bin/bridge[212]: [00:00:04]: Read: Parameter "Channel mask"
Jan 1 00:00:04 buildroot user.notice /usr/bin/bridge[212]: [00:00:04]: Send: 0A:08:00:08:00:01:00:26:BF:FF
Jan 1 00:00:04 buildroot user.notice /usr/bin/bridge[212]: [00:00:04]: Received: 0A:08:00:0C:00:05:00:26:94:0D:00:00
Jan 1 00:00:04 buildroot user.notice /usr/bin/bridge[212]: [00:00:04]: Read: Parameter "Watchdog"
Jan 1 00:00:04 buildroot user.notice /usr/bin/bridge[212]: [00:00:04]: Send: 0B:09:00:0C:00:05:00:26:88:0E:00:00:1F:FF
Jan 1 00:00:04 buildroot user.notice /usr/bin/bridge[212]: [00:00:04]: Received: 0B:09:00:08:00:01:00:26
Jan 1 00:00:04 buildroot user.notice /usr/bin/bridge[212]: [00:00:04]: Write: Parameter "Watchdog"
Jan 1 00:00:04 buildroot user.notice /usr/bin/bridge[212]: [00:00:04]: Watchdog @ [3476] loaded with [3720] seconds, Reset @ [Thu, 01 Jan 1970 01:00:04 GMT]

Was using this specification to write a module for the RDK Thunder framework (https://github.com/rdkcentral). Thanks for the eleborative specification realy usefull. However while testing the software I ran into a new value for the device status. It gave 0xA6.
The highets bit of the DeviceState is not described in the document, but what is the meaning of the 0x80 bit ?

Here are the message exchanges:

Currently the queue holds: 0 messages, sending out a size of 46
Send: 12:56:00:29:00:22:00:03:00:02:8F:CF:01:5E:DB:DC:00:00:01:13:00:00:01:00:00:00:01:00:02:00:03:00:04:00:05:00:06:00:07:00:00:00:9A:FC:C0:

Received: 12:56:00:09:00:02:00:22:03:

Received: 0E:57:00:07:00:A6:00: A6 ->8,2 | 4,2 -> 8???, Request FreeSots flag and Data Confirm

@manup (Manuel Pietschmann) Can I suggest that you (and @dresden-elektronik / Phoscon) try to reach out to @pipiche38 (Patrick Pichon) and his fellow developers about possible collaborating and teaming up to add compatibility for your ConBee USB stick and RaspBee Raspberry Pi Shield Zigbee Coordinator adapters together with the new "Zigbee for Domoticz Plugin" implementation for Domoticz home automation software that they are developing with zigpy as a new dependency for hardware-independency so that it can make use of different radio libraries like the zigpy-deconz radio library to add deCONZ Serial Protocol compatibility with your Zigbee Coordinator adapters in addition to Zigbee Coordinators from other manufacturers?

Also posted a matching request to that project here -> zigbeefordomoticz/Domoticz-Zigbee#1081

You can also read about that projects long back-story about utilizing zigpy radio libraries here -> zigpy/zigpy#865

Their new zigpy based implementation was recently merged into their "beta6" branch of their "Zigbee for Domoticz" plugin project as they have so far added support the zigpy radio libraries for both Texas Instruments (TI Z-Stack ZNP) and Silicon Labs EZSP (EmberZNet Serial Protocol) support via the zigpy-znp and bellows radio libraries respectivly, which are both together with the zigpy-deconz radio library and some other zigp radio libraries already used in by both Home Assistant's ZHA integration component and Jeedom's Zigbee plugin implementations as well, making this the third popular home automation software to publicly make use of the zigpy library and zigpy radio libraires to support Zigbee Coordinator adapters from different manufacturers:

https://github.com/zigbeefordomoticz/Domoticz-Zigbee/tree/beta6

https://github.com/zigbeefordomoticz/Domoticz-Zigbee/blob/beta6/readme.md#tested-hardware-zigbee-adaptersdonglesstickskeys

https://github.com/zigbeefordomoticz/wiki/blob/zigpy/en-eng/Home.md

https://www.domoticz.com/wiki/ZigbeeForDomoticz

https://www.domoticz.com/forum/viewforum.php?f=68

@manup If dresden-elektronik / Phoscon would help sponsor them with hardware by donating a few of your ConBee USB sticks and RaspBee Raspberry Pi Shields to @pipiche38, @badzz @SylvainPer and @jp-keros then maybe they would consider prioritizing adding support for and testing zigpy-deconz radio library integration next in order to support even more types of Zigbee Coordinators from different manufacturers. Perhaps they can mention that they use ConBee and RaspBee adapters as reference adapters for Phoscon/deCONZ hardware compatibility. No strings attached of course as these are still hobby projects at their core with only a few developers volunteering on that project so far.

Support for zigpy based radio libraries "Zigbee for Domoticz Plugin" for Domoticz is still in Beta development stage, but those guys have long been developing a previous "ZiGate Plugin for Domoticz" for Domoticz, (with Domoticz itself also being a popular free and open-source DIY home automation software). So at least you know that these guys already have the experience, skills, and personal interest to develop a new zigpy based Zigbee plugin for Domoticz.

Again, as I understand it, zigpy, bellows, Domoticz, and this new "Zigbee for Domoticz Plugin" are all only spare-time hobby projects but still, I think that teaming up might give all involved projects some more positive recognition in the Domoticz community and the whole home automation scene in general which might attract more developers and willing alpha/beta-testers from the community to come to help out with all these involved projects which in the long run could benefit all users wanting Zigbee in Domoticz to become more mature and working with more Zigbee hardware dongles than it is today.

Whilst implementing this in Elixir/Erlang I found that Read Parameter Request frames frames for the network key parameter required an extra 0x00 byte after the parameter_id in order to return a value. The value returned also had the extra byte, that is the payload had 17 bytes not 16 as per the document.

The Write Parameter Request also required the extra byte or the response was invalid value.

Is there a quirk where the parameter id treated as a u16 in this case or is the data padded with an extra byte?

@manup and @ChrisHae Can I suggest that you at dresden-elektronik try to reach out to @pipiche38 (Patrick Pichon) about possible donating ConBee/RaspBee hardware to him so he can test deCONZ hardware with the new Zigbee plugin implementation based on zigpy that he is developing for Domoticz home automation software?

https://github.com/pipiche38/Domoticz-Zigpy/

If the project is successful then his plugin will add ConBee/RaspBee plug-and-play hardware to Domoticz without deCONZ gateway.

I know that @dresden-elektronik has made hardware donations of your deCONZ based Zigbee adapters to free and open source projects in the past, including developers working on the zigpy project, so though you might be willing to do same here? After all, zigpy already support ConBee and RaspBee adapters and the more projects that support those should mean more people buying and using your Zigbee adapters.

Please also see respective suggested posted to pipiche38 here:

https://github.com/pipiche38/Domoticz-Zigpy/issues/5

If you could donate one, two or few of your ConBee and RaspBee adapters (USB dongles or Raspberry Pi Shields) to @pipiche38 then maybe he that can help him with his developing effort as it would give him the possibility to also test the zigpy-deconz radio library for zigpy to try out their compatibility with ConBee and RaspBee adapters as zigpy can support many different adapters. Your hardware adapters could perhaps later even be used as one of the reference hardware tested for that new zigpy based Domoticz plugin, though no strings attached of course as these are still hobby projects at their core with only one developer so far.

https://github.com/zigpy/zigpy

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

Please understand that pipiche38 is still in a very early stage of developing his "Domoticz-Zigpy" plugin for Domoticz (a popular free and open-source home automation software), I understand in fact the project is so a such early in development that is not yet usable to end-users, however, I read on Domoticz community forum that he currently only has access to ZiGate Zigbee adapters (this as pipiche38 is also the developer of an already existing ZiGate plugin for Domoticz). So at least we know that pipiche38 already has the experience and skills to develop Zigbee plugins for Domoticz.

https://github.com/pipiche38/Domoticz-Zigate-Wiki/blob/master/en-eng/Home.md

https://www.domoticz.com/wiki/Zigate

I believe that both zigpy, Domoticz, and this new "Domoticz-Zigpy" plugin are all only spare-time hobby projects at this point, but still, I think that teaming up might give all involved projects some continued positive recognition in the Domoticz community and the whole home automation scene in general which might attract more developers and willing alpha/beta-testers from the community to come to help out with all these involved projects which in the long run could benefit all users wanting Zigbee in Domoticz to become more mature and working with more Zigbee hardware dongles than it is today.

I've been trying to write network settings to a Conbee II and am unable to progress with one part of this puzzle: setting the frame counter.

The serial protocol describes a "0x27" network parameter that indeed yields the correct network frame counter when read, but writing this parameter does not actually do anything. I've tried variations of bringing the network online, writing the parameter, and bringing it offline in every possible order, with 5s delays, and multiple times in a row to no avail: reading the parameter after a write "works", but after re-connecting to the serial port, the old value is returned once again.

I tried to check how deCONZ itself does it by performing a Phoscon backup, but according to the serial traffic, the frame counter is never actually written!

I'm testing this at the moment by directly editing a Phoscon backup archive and changing the frame counter value. deCONZ logs the following:

deconz    | 22:06:45:055 Warning frame counter 52316187 (0x031E481B) lower than previous one 4276993775 (0xFEEDBEEF)

0xFEEDBEEF (4276993775) is what I had in my edited backup. I'm testing with deconzcommunity/deconz:beta, Conbee II running firmware 0x26720700.

The source code for https://github.com/dresden-elektronik/deconz-rest-plugin/blob/0f370be484acad5e8b8820a13cf237d28c478836/backup.cpp#L484 isn't public (as far as I can tell) and it seems to me that apsCtrl->setParameter does more than just send WRITE_PARAMETER.

What conditions need to be present for the write to happen/succeed?

Attached is a log file of deCONZ running with as many verbosity settings as I could find. In it I performed a backup and restore through Phoscon.

Thanks!

deconz.log

I currently have a C++ implementation of the SerialProtocol implemented for Windows/Linux and it is working fine with the ConBee (Serial over USB). Now I wanted to switch to the Raspbee (Serial on the RASPBERRYPi) but looks like it is not reporting in. I assume the protocols are the same.
I can not clearly find the parameters that I need to use. Assumption is 38400, No parity, 8 databits, 1 stopbit. Serial terminal programmed as raw.

Is this correct?

Hi

The conbee device serial protocol sometime send an unsolicited command 0x19 that is not documented in

https://deconz.dresden-elektronik.de/raspbian/deCONZ-Serial-Protocol-en_1.21.pdf

Anyone that know what it is?

Is it possible to reconfigure my Conbee II stick as a repeater? If not this would be an awesome feature to introduce.

@manup Reposting from zigpy/zigpy-deconz#214 and Koenkk/zigbee2mqtt#17492 as a public request to you dresden-elektronik's deCONZ (ConBee) developers because the developers of zigpy (used by Home Assistant's ZHA integration + Zigbee plugins for Domoticz and Jeedom) and zigbee-herdsman (Zigbee2MQTT + IoBroker) replied there that this function is not supported in zigpy-deconz or zigbee-herdsman since the function for install code (and qr code) is not a documented in the linked deCONZ serial protocol documentation:

https://github.com/dresden-elektronik/deconz-serial-protocol/blob/master/README.md

UPDATE: The exact same issue also applies to Zigbee2MQTT (Z2M) and IoBroker (which are both based on zigbee-herdsman):

Koenkk/zigbee2mqtt#17492

It started with one user of Home Assistant’s ZHA integration with an ConBee Zigbee Coordinator adapter posted that they could not join/pair a Zigbee 3.0 (ZB3) device that required an "install code", and then some other user replied to that post saying "install code" (and "qr code"?) support is not implemented in the 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

For reference that specific Zigbee 3.0 device that require install code to join was the "Bosch Thermostat 2":

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

ZHA (and zigpy) can set an Install Code for Zigbee 3.0 devices if using Silicon Labs EmberZNet or Texas Instruments Z-Stack ZNP:

https://www.home-assistant.io/integrations/zha#services

https://www.silabs.com/documents/public/application-notes/an1089-using-installation-codes-with-zigbee-devices.pdf

https://wiki.st.com/stm32mcu/wiki/Connectivity:Zigbee_Install_Code

Just reposting 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. Another device that been mentioned to require install code is the rotary switch Aqara H1 -> Koenkk/zigbee-herdsman#420

PS: I do not have a ConBee/RaspBee Zigbee Coordinator setup myself any longer so can not replicate it to confirm or disconfirm this but think that it would be a good idea if this could be tracked as a feature request because the function is missing the deconz serial protocol documentation and for deconz firmware based Zigbee Coordinator adapters like ConBee/RaspBee but supported by other Zigbee Coordinator adapters like Silicon Labs and Texas Instruments based Zigbee Coordinator adapters via their respective radio library for zigpy.

I'm currently working on adding Green Power support to zigpy, and unfortunately the "only 2 endpoints" issue has finally bitten us. Given this current limitation, we're currently unable to add support for green power to zigpy-deconz. Any status updates on this issue would be greatly appreciated.

The document is a bit unclear on how to set the stick (if it is a controller) in a joinable mode. Documentation suggests that (chapter 7.2.1) The command CHANGE_NETWORK_STATE (0x08) force, if the role of the stick is controller, should force it into a join allowed by forcing the network state to NET_CONNECTED ?

Than my next question would be how to take it out of a joinable mode. SHould this be done by setting the state to NET_OFFLINE ?

What I am trying to ask is: How can I force the stick into the "Permit Join mode". This setting in the deconz App:

Currently we have the Conbee2 (USB) dongle and the Raspbee (Serial) working on the RDK stack. However there are two observations we are currently working around.

Whenever the command 0x0D (Metadata) is issued, the stick response is sending 0x0A (Config read data). Looks like the CRC is assuming that the command 0x0D was actually used during the CRC calculation.
The retrieval of the Watchdog shows (sometimes a similar CRC calculation failure)
Any idea what could be the issue? I am using the latest firmware.

Full logs:

Serial device

[Mon, 03 Jan 2022 20:43:04]:[Dresden.cpp:747] DataFrame: Send: 0D:01:00:09:00:00:00:00:00:E9:FF
[Mon, 03 Jan 2022 20:43:04]:[Dresden.cpp:170] Error: CRC failed but worked around (metadata). : [11], Data: [0A:01:00:09:00:00:05:39:26:85:FF], [0xFF88] != [0xFF85]
[Mon, 03 Jan 2022 20:43:04]:[Dresden.cpp:763] DataFrame: Received: 0D:01:00:09:00:00:05:39:26
[Mon, 03 Jan 2022 20:43:04]:[Dresden.cpp:764] Protocol: Metadata: Version: 38.57 Platform: "Conbee"

[Mon, 03 Jan 2022 20:43:04]:[Dresden.cpp:747] DataFrame: Send: 0A:02:00:08:00:01:00:01:EA:FF
[Mon, 03 Jan 2022 20:43:04]:[Dresden.cpp:763] DataFrame: Received: 0A:02:00:10:00:09:00:01:E7:41:01:FF:FF:2E:21:00
[Mon, 03 Jan 2022 20:43:04]:[Dresden.cpp:764] Protocol: Read: Parameter "MAC Address"

[Mon, 03 Jan 2022 20:43:04]:[Dresden.cpp:747] DataFrame: Send: 0A:03:00:08:00:01:00:07:E3:FF
[Mon, 03 Jan 2022 20:43:04]:[Dresden.cpp:763] DataFrame: Received: 0A:03:00:0A:00:03:00:07:00:00
[Mon, 03 Jan 2022 20:43:04]:[Dresden.cpp:764] Protocol: Read: Parameter "Network address"

[Mon, 03 Jan 2022 20:43:04]:[Dresden.cpp:747] DataFrame: Send: 0A:04:00:08:00:01:00:09:E0:FF
[Mon, 03 Jan 2022 20:43:04]:[Dresden.cpp:763] DataFrame: Received: 0A:04:00:09:00:02:00:09:01
[Mon, 03 Jan 2022 20:43:04]:[Dresden.cpp:764] Protocol: Read: Parameter "APS Designed mode"

[Mon, 03 Jan 2022 20:43:04]:[Dresden.cpp:747] DataFrame: Send: 0A:05:00:08:00:01:00:22:C6:FF
[Mon, 03 Jan 2022 20:43:04]:[Dresden.cpp:763] DataFrame: Received: 0A:05:00:0A:00:03:00:22:0C:01
[Mon, 03 Jan 2022 20:43:04]:[Dresden.cpp:764] Protocol: Read: Parameter "Protocol version"

[Mon, 03 Jan 2022 20:43:04]:[Dresden.cpp:747] DataFrame: Send: 0A:06:00:08:00:01:00:05:E2:FF
[Mon, 03 Jan 2022 20:43:04]:[Dresden.cpp:763] DataFrame: Received: 0A:06:00:0A:00:03:00:05:91:1B
[Mon, 03 Jan 2022 20:43:04]:[Dresden.cpp:764] Protocol: Read: Parameter "Network PAN Id"

[Mon, 03 Jan 2022 20:43:04]:[Dresden.cpp:747] DataFrame: Send: 0A:07:00:08:00:01:00:0A:DC:FF
[Mon, 03 Jan 2022 20:43:04]:[Dresden.cpp:763] DataFrame: Received: 0A:07:00:0C:00:05:00:0A:00:80:00:00
[Mon, 03 Jan 2022 20:43:04]:[Dresden.cpp:764] Protocol: Read: Parameter "Channel mask"

[Mon, 03 Jan 2022 20:43:04]:[Dresden.cpp:747] DataFrame: Send: 0A:08:00:08:00:01:00:26:BF:FF
[Mon, 03 Jan 2022 20:43:04]:[Dresden.cpp:763] DataFrame: Received: 0A:08:00:0C:00:05:00:26:D5:09:00:00
[Mon, 03 Jan 2022 20:43:04]:[Dresden.cpp:764] Protocol: Read: Parameter "Watchdog"

[Mon, 03 Jan 2022 20:43:04]:[Dresden.cpp:747] DataFrame: Send: 0B:09:00:0C:00:05:00:26:88:0E:00:00:1F:FF
[Mon, 03 Jan 2022 20:43:04]:[Dresden.cpp:763] DataFrame: Received: 0B:09:00:08:00:01:00:26
[Mon, 03 Jan 2022 20:43:04]:[Dresden.cpp:764] Protocol: Write: Parameter "Watchdog"
[Mon, 03 Jan 2022 20:43:04]:[Dresden.cpp:356] Timer: Watchdog @ [2517] loaded with [3720] seconds, Reset @ [Mon, 03 Jan 2022 20:43:04 GMT]
[Mon, 03 Jan 2022 20:43:04]:[Dresden.cpp:720] Timer: Next trigger in 3600000 milliseconds
[ 11235845 us] Activated plugin [ZigbeeControl]:[ZigbeeControl]

USB device
[Mon, 03 Jan 2022 20:47:29]:[Dresden.cpp:747] DataFrame: Send: 0D:01:00:09:00:00:00:00:00:E9:FF
[Mon, 03 Jan 2022 20:47:29]:[Dresden.cpp:170] Error: CRC failed but worked around (metadata). : [11], Data: [0A:01:00:09:00:00:07:72:26:4A:FF], [0xFF4D] != [0xFF4A]
[Mon, 03 Jan 2022 20:47:29]:[Dresden.cpp:763] DataFrame: Received: 0D:01:00:09:00:00:07:72:26
[Mon, 03 Jan 2022 20:47:29]:[Dresden.cpp:764] Protocol: Metadata: Version: 38.114 Platform: "Conbee2"

[Mon, 03 Jan 2022 20:47:29]:[Dresden.cpp:747] DataFrame: Send: 0A:02:00:08:00:01:00:01:EA:FF
[Mon, 03 Jan 2022 20:47:29]:[Dresden.cpp:763] DataFrame: Received: 0A:02:00:10:00:09:00:01:2F:89:04:FF:FF:2E:21:00
[Mon, 03 Jan 2022 20:47:29]:[Dresden.cpp:764] Protocol: Read: Parameter "MAC Address"

[Mon, 03 Jan 2022 20:47:29]:[Dresden.cpp:747] DataFrame: Send: 0A:03:00:08:00:01:00:07:E3:FF
[Mon, 03 Jan 2022 20:47:29]:[Dresden.cpp:763] DataFrame: Received: 0A:03:00:0A:00:03:00:07:00:00
[Mon, 03 Jan 2022 20:47:29]:[Dresden.cpp:764] Protocol: Read: Parameter "Network address"

[Mon, 03 Jan 2022 20:47:29]:[Dresden.cpp:747] DataFrame: Send: 0A:04:00:08:00:01:00:09:E0:FF
[Mon, 03 Jan 2022 20:47:29]:[Dresden.cpp:763] DataFrame: Received: 0A:04:00:09:00:02:00:09:01
[Mon, 03 Jan 2022 20:47:29]:[Dresden.cpp:764] Protocol: Read: Parameter "APS Designed mode"

[Mon, 03 Jan 2022 20:47:29]:[Dresden.cpp:747] DataFrame: Send: 0A:05:00:08:00:01:00:22:C6:FF
[Mon, 03 Jan 2022 20:47:29]:[Dresden.cpp:763] DataFrame: Received: 0A:05:00:0A:00:03:00:22:0E:01
[Mon, 03 Jan 2022 20:47:29]:[Dresden.cpp:764] Protocol: Read: Parameter "Protocol version"

[Mon, 03 Jan 2022 20:47:29]:[Dresden.cpp:747] DataFrame: Send: 0A:06:00:08:00:01:00:05:E2:FF
[Mon, 03 Jan 2022 20:47:29]:[Dresden.cpp:763] DataFrame: Received: 0A:06:00:0A:00:03:00:05:AF:DE
[Mon, 03 Jan 2022 20:47:29]:[Dresden.cpp:764] Protocol: Read: Parameter "Network PAN Id"

[Mon, 03 Jan 2022 20:47:29]:[Dresden.cpp:747] DataFrame: Send: 0A:07:00:08:00:01:00:0A:DC:FF
[Mon, 03 Jan 2022 20:47:29]:[Dresden.cpp:763] DataFrame: Received: 0A:07:00:0C:00:05:00:0A:00:80:00:00
[Mon, 03 Jan 2022 20:47:29]:[Dresden.cpp:764] Protocol: Read: Parameter "Channel mask"

[Mon, 03 Jan 2022 20:47:29]:[Dresden.cpp:747] DataFrame: Send: 0A:08:00:08:00:01:00:26:BF:FF
[Mon, 03 Jan 2022 20:47:29]:[Dresden.cpp:170] Error: CRC failed but worked around (metadata). : [14], Data: [0A:08:00:0C:00:05:00:26:9B:0A:00:00:0F:FF], [0xFF12] != [0xFF0F]
[Mon, 03 Jan 2022 20:47:29]:[Dresden.cpp:763] DataFrame: Received: 0D:08:00:0C:00:05:00:26:9B:0A:00:00
[Mon, 03 Jan 2022 20:47:29]:[Dresden.cpp:764] Protocol: Metadata: Version: 155.38 Platform: ""

[Mon, 03 Jan 2022 20:47:32]:[Dresden.cpp:273] Error: Could not extract watchdog value from stick
[ 21534740 us] Activation of plugin [ZigbeeControl]:[ZigbeeControl], failed. Error [Could not open the ZigbeeController link.]

Jan 3 21:00:06 buildroot user.notice /usr/bin/bridge[213]: [21:00:06]: CRC failed but worked around (metadata). : [11], Data: [0A:01:00:09:00:00:05:39:26:85:FF], [0xFF88] != [0xFF85]
Jan 3 21:00:06 buildroot user.notice /usr/bin/bridge[213]: [21:00:06]: Received: 0D:01:00:09:00:00:05:39:26
Jan 3 21:00:06 buildroot user.notice /usr/bin/bridge[213]: [21:00:06]: Metadata: Version: 38.57 Platform: "Conbee"

Jan 3 21:00:06 buildroot user.notice /usr/bin/bridge[213]: [21:00:06]: Send: 0A:02:00:08:00:01:00:01:EA:FF
Jan 3 21:00:06 buildroot user.notice /usr/bin/bridge[213]: [21:00:06]: Received: 0A:02:00:10:00:09:00:01:E7:41:01:FF:FF:2E:21:00
Jan 3 21:00:06 buildroot user.notice /usr/bin/bridge[213]: [21:00:06]: Read: Parameter "MAC Address"

Jan 3 21:00:06 buildroot user.notice /usr/bin/bridge[213]: [21:00:06]: Send: 0A:03:00:08:00:01:00:07:E3:FF
Jan 3 21:00:06 buildroot user.notice /usr/bin/bridge[213]: [21:00:06]: Received: 0A:03:00:0A:00:03:00:07:00:00
Jan 3 21:00:06 buildroot user.notice /usr/bin/bridge[213]: [21:00:06]: Read: Parameter "Network address"

Jan 3 21:00:06 buildroot user.notice /usr/bin/bridge[213]: [21:00:06]: Send: 0A:04:00:08:00:01:00:09:E0:FF
Jan 3 21:00:06 buildroot user.notice /usr/bin/bridge[213]: [21:00:06]: Received: 0A:04:00:09:00:02:00:09:01
Jan 3 21:00:06 buildroot user.notice /usr/bin/bridge[213]: [21:00:06]: Read: Parameter "APS Designed mode"

Jan 3 21:00:06 buildroot user.notice /usr/bin/bridge[213]: [21:00:06]: Send: 0A:05:00:08:00:01:00:22:C6:FF
Jan 3 21:00:06 buildroot user.notice /usr/bin/bridge[213]: [21:00:06]: Received: 0A:05:00:0A:00:03:00:22:0C:01
Jan 3 21:00:06 buildroot user.notice /usr/bin/bridge[213]: [21:00:06]: Read: Parameter "Protocol version"

Jan 3 21:00:06 buildroot user.notice /usr/bin/bridge[213]: [21:00:06]: Send: 0A:06:00:08:00:01:00:05:E2:FF
Jan 3 21:00:06 buildroot user.notice /usr/bin/bridge[213]: [21:00:06]: Received: 0A:06:00:0A:00:03:00:05:91:1B
Jan 3 21:00:06 buildroot user.notice /usr/bin/bridge[213]: [21:00:06]: Read: Parameter "Network PAN Id"

Jan 3 21:00:06 buildroot user.notice /usr/bin/bridge[213]: [21:00:06]: Send: 0A:07:00:08:00:01:00:0A:DC:FF
Jan 3 21:00:06 buildroot user.notice /usr/bin/bridge[213]: [21:00:06]: Received: 0A:07:00:0C:00:05:00:0A:00:80:00:00
Jan 3 21:00:06 buildroot user.notice /usr/bin/bridge[213]: [21:00:06]: Read: Parameter "Channel mask"

Jan 3 21:00:06 buildroot user.notice /usr/bin/bridge[213]: [21:00:06]: Send: 0A:08:00:08:00:01:00:26:BF:FF
Jan 3 21:00:06 buildroot user.notice /usr/bin/bridge[213]: [21:00:06]: Received: 0A:08:00:0C:00:05:00:26:89:0A:00:00
Jan 3 21:00:06 buildroot user.notice /usr/bin/bridge[213]: [21:00:06]: Read: Parameter "Watchdog"

Jan 3 21:00:06 buildroot user.notice /usr/bin/bridge[213]: [21:00:06]: Send: 0B:09:00:0C:00:05:00:26:88:0E:00:00:1F:FF
Jan 3 21:00:06 buildroot user.notice /usr/bin/bridge[213]: [21:00:06]: Received: 0B:09:00:08:00:01:00:26
Jan 3 21:00:06 buildroot user.notice /usr/bin/bridge[213]: [21:00:06]: Write: Parameter "Watchdog"
Jan 3 21:00:06 buildroot user.notice /usr/bin/bridge[213]: [21:00:06]: Watchdog @ [2697] loaded with [3720] seconds, Reset @ [Mon, 03 Jan 2022 21:00:06 GMT]
Jan 3 21:00:06 buildroot user.notice /usr/bin/bridge[213]: [21:00:06]: Next trigger in 3600000 milliseconds
Jan 3 21:00:06 buildroot user.notice /usr/bin/bridge[213]: [Mon, 03 Jan 2022 21:00:06]:[PluginServer.cpp:396]: Startup: Activated plugin [ZigbeeControl]:[ZigbeeControl]

I get a bunch of commands from the conbee stick with Command ID 0x1F that I don't know how to interpret. Anyone know what it is?

There is nothing in the serial protocol pdf about it.

When my Conbee2 is connected to my Synology NAS, and the device reboots (software update, whatever), Docker images lose contact with the device.

The device still shows up as:
/dev/ttyACM0

And Synology Info shows the device info as connected i.e ConBee2 etc. But none of the HomeAssistant docker images, despite full access to the device, can find it.

Only physically unplugging and reconnecting it works. ( No need to issue any commands or restart any docker images ) Then the device shows up in ZHA Home Assistant etc.

So warm reboot - device no longer available.
Cold reboot or hot-plug - device available.

Is there an available command to 'reboot' the USB device?

I do not understand the implications of
0x26 | Watchdog TTL
"By writing a lower value like 2 seconds, the firmware can be rebooted."

Which firmware? The ConBee?