FYI, ConBee / RaspBee (and deCONZ) developer manup is working on a "Phoscon RCP" firmware not based on OpenThread RCP

[Hedda]

Heads-up FYI, read ConBee / RaspBee (and deCONZ) developer @manup is working on a RCP firmware not based on OpenThread RCP:

• https://github.com/dresden-elektronik/phoscon-rcp

  "Firmware that turns dresden elektronik's ConBee and RaspBee adapters into a plain IEEE 802.15.4 radio. A host drives it over Spinel, the protocol OpenThread uses for its radio co-processors, and runs the whole network stack itself. The firmware keeps no state across a reset and writes no network data to flash."

That is, he has begun coding a custom Spinel RCP firmware which will be an alternatvie to OpenThread RCP on ConBee / RaspBee adapters.

Here is a firmware image of that "Phoscon RCP" for the previously very popular ConBee II (ConBee 2) USB radio adapter:

• https://github.com/user-attachments/files/33838106/deconz-spinel-e28b3ad-cb191edf.GCF.zip

(it can be flashed via their Web Flasher https://phoscon.de/updater or via GCFFlasher 4 https://github.com/dresden-elektronik/gcfflasher )

He works for Dresden Elektronik so unsure if he/they plan to always make that RCP firmware/stack available as fully open-source code(?)

He also only mentioned this as part of a feature request to the zigbee-on-host repo which could also be relevant to Ziggurat as well:

• Feature request: support using MAC address from RCP Nerivec/zigbee-on-host#165 (comment)

Feature request: support using MAC address from RCP

Is your feature request related to a problem? Please describe. The coordinator's IEEE address is never read from the RCP. SPINEL_PROP_HWADDR (0x08) is defined in src/spinel/properties.ts but unused, and the z2m adapter seeds eui64 with a fixed placeholder (zohAdapter.js). So the coordinator identity has nothing to do with the dongle, and every host built on zoh starts with the same address.

Describe the solution you'd like Query SPINEL_PROP_HWADDR once at init/reset and use the returned EUI-64 as the default netParams.eui64, falling back to the current placeholder only if the property is absent or the value is invalid (zero or all-ones). The existing zoh_config.json override should keep working.

Describe alternatives you've considered

• Keep the placeholder and document zoh_config.json, works today, but every deployment has to be told.
• Read it in the adapter instead, the adapter doesn't speak Spinel, so the driver is the right place.

Additional context

First of all thanks for this great project, this is much better than the closed-source Zigbee stacks.

I'm currently creating a new shared RCP firmware for all ConBee / RaspBee series (I, II, III). Compared to OpenThread the firmware is a lot smaller with just 37Kb. In my tests with z2m + zoh, joining and controlling an Ikea light already works great. I'm using the latest z2m-dev and your upstream version of zoh.

But I noticed that the MAC address was set to the fixed one mentioned above.

A working firmware version for ConBee II is attached (unzip first) and can be flashed via Web Flasher https://phoscon.de/updater

cb2-spinel-e28b3ad-cb191edf.GCF.zip

Appendix: As zoh matures I think the deconz driver in z2m can be deprecated in favor of zoh, once firmware is available for all targets.

[manup]

Note the latest RCP firmware images are always attached in https://github.com/dresden-elektronik/phoscon-rcp/releases
Most simply to flash via https://phoscon.de/updater

The firmware is feature complete and should already be quite stable, but is still being stress tested to see if there are any issues with Thread 1.4 / Zigbee R23.1. My plan is it to make this the default firmware asap, since now all projects develop Zigbee stack on host which is much better than the silicon vendor Zigbee stacks.

[puddly]

Thanks! For the Conbee III, can you consider bumping the baudrate to 460800? For RCP, 115200 is a little slow.

[puddly]

My mistake, I didn't see the Conbee III changelog:

ConBee III: the host may raise the link to 1 000 000 Bd with UART_BITRATE; a RESET, or a host that starts over at 115 200, returns it to 115 200 (docs/protocol.md).

I'll test this out later.

[manup]

Cool thanks, note the v0.2.0 starts with 115200 and can only be brought to higher baud rates with the standard spinel property. Later on there will be a version with the higher baudrate set as default as well.

[Hedda]

I'm currently creating a new shared RCP firmware for all ConBee / RaspBee series (I, II, III). Compared to OpenThread the firmware is a lot smaller with just 37Kb. In my tests with z2m + zoh, joining and controlling an Ikea light already works great. I'm using the latest z2m-dev and your upstream version of zoh.

@manup other than your RCP firmware being a lot smaller are or will there be additional "pros and cons" compared to OpenThread RCP?

Will there be any other advantages or disadvantages?

I would for example otherwise think that a huge potential advantage to the firmware being so small is if it could be ported to ESP-IDF then it would be very attractive to run on Espressif's ESP32 models with IEEE 802.15.4 radio (today ESP32-C6, ESP32-C5, ESP32-S31, ESP32-H2, ESP32-H4) as that would free up a lot of memmory to run other things.

• https://docs.espressif.com/projects/esp-idf/en/stable/esp32/api-guides/openthread.html
• https://github.com/espressif/esp-idf/tree/master/examples/openthread
• https://github.com/openthread/ot-esp32
• https://docs.espressif.com/projects/esp-thread-br
• https://openthread.io/codelabs/esp-openthread-hardware

[manup]

Will there be any other advantages or disadvantages?

Not that I'm aware of. So far the functionality should be on par with OpenThread, and new features can be added if needed.

For open source advocates there is one issue which I hope to solve in future, currently all projects, including Phoscon RCP for ConBee III port, which are using ESP32 or Silaps radios do link propritary radio libraries from the silicon vendors. I started to build a true open driver for Silabs but it's not complete yet. In contrast ConBee I and II are full open source down to the silicon.

For firmware sizes, there is also a small diagram to track current flash and RAM usage:
https://github.com/dresden-elektronik/phoscon-rcp/blob/main/docs/build-and-flash.md#3-artifacts-and-sizes

I made a experimental port for ESP32-C6 yesterday, it's not upstream yet. Our LED ballast FLS-M uses ESP32-C6, the port is running on a XIAO ESP32-C6 board. However there isn't much to gain there since on ESP32 there is already plenty of flash and RAM, most of it not needed for RCP.