What does it mean to this project that Espressif’s ESP Zigbee SDK 2.0 replaces ZBOSS with a new propriatory Zigbee stack?

[Hedda]

What will it mean short-term and long-term for this project that ESP Zigbee SDK 2.0 replaces ZBOSS with a propriatory Zigbee stack?

Originally posted by @luar123 in esphome/esphome#11553 (comment)

I could bring forward more PRs for additional options, sensor, switch and number components quite fast. However, espressif released a version 2.0 zigbee sdk a few days ago. Currently I am implementing it in my external component to test it (this will probably take a few days). If it works well we should consider to update here, or in a separate PR, before the release because they change the zigbee partition type. Overall, changes are large, they dropped zboss in favor of their own stack and integration with esp-idf seems much better. Functional changes are small, so review effort should be low, but all functions/types/macros change names.

For reference see:

• https://github.com/espressif/esp-zigbee-sdk/blob/main/RELEASE_NOTES.md

  • https://docs.espressif.com/projects/esp-zigbee-sdk/en/latest/esp32/migration-guide/v2.x/overview.html

    • https://docs.espressif.com/projects/esp-zigbee-sdk/en/latest/esp32/migration-guide/index.html

      • ESP Zigbee SDK 2.x Release espressif/esp-zigbee-sdk#803

        • 2.0 migration questions espressif/esp-zigbee-sdk#800

  "The ESP Zigbee SDK v2.x replaced the ZBOSS core with the Espressif proprietary Zigbee implementation, so headers and APIs have been restructured and refactored to different namespaces. See API Reference for the details of the differences between the Core API (prefixed with ezb) and the SDK API (prefixed with esp_zigbee_). For most APIs unless otherwise specified, the new API names are the same as the old API names, but with the namespace changed. A quick check of the API changes can be done by going through the headers of the compatibility layer in include/compat directory_".

In summery:

• v1.x is based on ZBOSS

  • LTS (Long-Term Support) version, which is under maintenance (bug fixes only, no new features).
  • It is stable for existing products.

• v2.x is based on Espressif proprietary Zigbee stack

  • A fully self-developed Zigbee stack provides greater flexibility and better capability to meet the evolving requirements of the Zigbee market
  • Full control of the entire stack, enabling better hardware–software adaptation
  • Faster iteration for new features (e.g., Zigbee 4.0, direct) and bug fixes
  • Improved code efficiency and reduced code size

• Espressif employee @xieqinan wrote that Espressif will provide an example demonstrating how to perform OTA from v1.x to v2.0 as soon as possible. In the meantime, we can review their migration guide to understand the differences between v1.x and v2.x.

• xieqinan also wrote that Espressif Zigbee 4.0 certification testing for v2.x is being planned and will be completed as soon as possible.

[luar123]

If there are no blockers I want to move to the new sdk. We will have to see if there is an easy way to (OTA) update existing devices or if flashing/re-joining is needed.

See #96 and v2 branch.

[sadpixel]

One thing I noticed in the migration guide from the ZBoss-based v1 to the new proprietary v2 is that the new version does not yet include Zigbee Green Power support.

I know @Hedda is also quite interested in ZHA/zigpy finally supporting ZGP sometime in the near future, so I thought I’d highlight this…

It would be neat if we could use this component to build ZGP switches and buttons! But I’m assuming it’s unreasonable to support both v1 and v2 of the ESP Zigbee library.

[luar123]

I guess they will support it at some point.

Never looked into ZGP, but seems to be a completely independence API. So this could as well be a separate component.

[Hedda]

One thing I noticed in the migration guide from the ZBoss-based v1 to the new proprietary v2 is that the new version does not yet include Zigbee Green Power support.

I do not think the fact that there is no Zigbee Green Power (ZGP) support matters at this time in this project for the the scope of using it for ESPHome's Zigbee component with ESP32 hardware, it is still very early and experimental as it is.

• https://next.esphome.io/components/zigbee/

Yes it would indeed be very cool to be able to make ZGP buttons based on ESPHome at some point, however not only does ZGP use a completely different API as luar123 mentions, but making ZGP hardware is more complicated too and would probbalky even needs to request that Espressif make a brand new ESP32 model that was optimized for Zigbee Green Power.

ZGP devices are not simply sleepy devices that only use very little power when transmitting, no instead they are really meant to be completly dorment and powerless until an action happen and then it very quicly powers on and sends a message before going completly dorment again. The while premis of Zigbee Green Power is to enable "maintenance-free" (near zero maintenance) ultra-low power efficient IoT devices that can operate without traditional batteries by using energy-harvesting technologies, powering themselves using ambient energy from their environment. Such as example energy harvestiing from kinetic (pressing a switch), thermal (heat differences), vibration, or light (solar cells that drive the device directly or charge capacitors / rechargable battaries). Zigbee Green Power Device (GPD themselves should really only use power when it transmits it message so therefor they need to extremely simple and small (like a button, a.k.a. a wireless "switch"), and then they depends on always-on Zigbee Green Power Proxy (GPP) devices to forward their messages to the and the Zigbee Green Power Sink (GPS) which receives the forwarded message and executes the command.

Anyway, since ESPHome's Zigbee component also support the nrf52 platform too in ESPHome you might have better luck there as the Zigbee stack for that is based on ZBOSS (similar to ESP-Zigbee-SDK 1.x) and Nordic Semiconductor has always had a higher focus on power consumption and technically is included in their NCS (nRF Connect SDK).