Z-stack Firmware Download
Ellen Woolcock
In my mind ZigBee 3.0 is required to unify light link and home automation devices under one Controller, but I do notice the current binding supports Hue Light bulbs, how is this possible today with the Home Automation based firmware?
I am running the same firmware and it is working well, but I want to warn you that it has a problem, you cannot change the channel or panId since the firmware will revert them back to default values and you might lose your network if you set it up using different values. More details here
Koenkk, the great mastermind behind Zigbee2MQTT and the Z-Stack firmware that runs on the various Zigbee Coordinators, has released a new updated firmware for the CC2652/CC1352 series chipsets. This firmware is for both Zigbee2MQTT and Home Assistant ZHA users. The changelog is as follows:
The old saying of if isn't broke then don't fix it definitely applies here for the average Zigbee network sizes. I have a mixture of various Zigbee devices of around 50 devices and I've been running this firmware in beta for a few weeks without any issues. I'm using a CC2652P2 based Sonoff Dongle-P USB coordinator with Zigbee2MQTT. Several Home Assistant ZHA users on the Github testing thread have also reported no issues during the beta period. Give it a whirl if you want to, you can always downgrade if you think it is causing issues.
Just like any device in your smart home, the coordinator has an updatable firmware. And firmware, as we all know, needs an update every now and again, as bugs are discovered and improvements are implemented. Koenkk, the developer of the popular Zigbee2MQTT bridge, has just released such a firmware update for coordinators based on the CC2652/CC1352, which should increase the performance of large networks consisting of over 100 Zigbee nodes. More specifically, it increases request retry attempts and routing table sizes.
Updating the firmware of your Zigbee isn't as daunting of a task as you might think. Thanks to the ZigStar GW Multi tool, there is no need to mess around with any scripts or command line commands. Start off by verifying the type of adapter you are using. This step is crucial, as the wrong firmware can brick your device. If you are unsure, you might see the name in the port it uses. To achieve this, open the Zigbee frontend, enter the settings, and select the tab titled serial.
In my case, because I'm using the CC2652RB stick by slaesh, I require the CC2652RB firmware. Koenkk publishes a list of all tested adapters along with their firmware on GitHub. Download the zip file and extract its contents. Now that we have the correct firmware, we can shut down Zigbee2MQTT to avoid any errors from occurring.
Once the flashing process is complete, you can safely remove the adapter from your PC and return it to its original location. Now, you can launch the Zigbee2MQTT frontend and confirm the installation of the new firmware. Open the dashboard, go to settings, and select the 'About' tab. Here, you will find the coordinator's firmware version listed under 'Coordinator Revision'.
Just for reference, I used this documentation on how to flash using TI SmartRFR software and for the firmware itself, I built one based on Z-Stack 3.0.2 following this tutorial I mentionned before (you can download the hex file from the Files section: CC2530ZNP-with-SBL (Z-Stack 3.0.2).hex).
Also, while I was waiting for my CC Debugger to be delivered, I looked around on the Internet for possible reasons why my previous attempts at flashing the CC2530 module failed. I didn't find anything relevant so I decided to check carefully my components and found out the solder joint of D5 on my Wemos D1 mini was cracked... A quick rework and I successfully flashed my firmware using CC loader library (for those interested, I also uploaded the bin file in the Files section).
Note! Zigbee 3.0 support or not in zigpy, depends primarily on your Zigbee coordinator hardware and its firmware. Some Zigbee coordinator hardware supports Zigbee 3.0 but might be shipped with an older firmware which does not. In such a case you may want to upgrade the firmware manually yourself.
Some other Zigbee coordinator hardware may not support a firmware that is capable of Zigbee 3.0 at all but can still be fully functional and feature-complete for your needs. This is very common as many, if not most, Zigbee devices do not yet Zigbee 3.0. As a general rule, newer Zigbee coordinator hardware generally supports Zigbee 3.0 firmware and it is up to its manufacturer to make such firmware available for them.
The ZHA integrationIntegrations connect and integrate Home Assistant with your devices, services, and more.
[Learn more] has the ability to automatically download and perform OTA (Over-The-Air) firmware updates of Zigbee devices if the OTA firmware provider source URL for updates is available. OTA firmware updating is set to disabled (false) in the configuration by default.
Online OTA providers for firmware updates are currently only available for IKEA, LEDVANCE/OSRAM, SALUS/Computime, and INOVELLI devices. Support for OTA updates from other manufacturers could be supported in the future if they publish their firmware images publicly.
To enable OTA firmware updates for the ZHA integrationIntegrations connect and integrate Home Assistant with your devices, services, and more.
[Learn more] you need to add the following configuration to your configuration.yaml and restart Home Assistant:
You can choose if the IKEA, LEDVANCE, SALUS, INOVELLI or THIRDREALITY provider should be set to enabled (true) or disabled (false) individually. After the OTA firmware upgrades are finished, you can set these to false again if you do not want ZHA to automatically download and perform OTA firmware upgrades in the future.
Note that the otau_directory setting is optional and can be used for any firmware files you have downloaded yourself, for any device type and manufacturer. For example, Philips Hue firmwares manually downloaded from here and/or here added to the otau_directory can be flashed, although a manual zha.issue_zigbee_cluster_command command currently (as of 2021.3.3) must be issued against the IEEE of the Philips Hue device under Developer Tools->Services, e.g.:
The general recommendation is to only use channels 15, 20, or 25 in order to avoid interoperability problems with Zigbee devices. Not only because there is less chance of Wi-Fi networks interfering too much with the Zigbee network on other channels, but also because not all Zigbee devices support all channels. Some devices, for example, are limited to only being compatible with ZLL (Zigbee Light Link) channels. It is therefore especially not recommended to use Zigbee channels 11, 24, 25, or 26 on your Zigbee coordinator. These Zigbee channels are commonly only supported by relatively modern Zigbee hardware devices with newer Zigbee firmware. If using those channels, your coordinator may not be usable with older Zigbee devices.
Common root causes of unreliable performance are often seen with outdated Zigbee Coordinator radio adapter hardware, limited by obsolete chips, bad antenna designs, or old/buggy firmware. You can improve most Zigbee setups by using a good Zigbee Coordinator radio adapter and maintaining it.
While using an older Zigbee Coordinator radio adapter hardware might work, using obsolete hardware and/or old firmware can prevent reliable operation. It is also generally a good idea to upgrade Zigbee Coordinator firmware before troubleshooting any further if and when run into problems with devices.
With the second mode of operation, you have what TI calls a ZigBee Network Processor (ZNP), which is a CC253x running the Z-Stack ZNP firmware, and then you write your application on whatever platform you're already familiar with and you make it talk to the ZNP through an UART. The rest of this article explains how to get started with this mode of operation. To prepare your boards, you need a piece of hardware and some software.
In theory, you could also use an Arduino/ATmega328P (or any other microcontroller you may like, if you got the skillz!) to program the CC253x, using a special firmware, which is what I was planning to do originally. However, the associated upload software seems to work very unreliably and after a lot of wasted hours I decided to just spend 5 EUR to get on with my life.
Now, the more adventurous readers have probably already found out that TI ships pre-compiled binaries of the ZNP firmware in Z-Stack 3.0.2. So why have I asked you to install IAR Embedded Workbench, when we could just have flashed those?
So, fire up IAR Embedded Workbench, activate/request a trial code as needed, and then open the ZNP firmware projects from File > Open Workspace. The project we need to recompile is located under the Z-Stack directory, at \Projects\zstack\ZNP\CC253x\znp.eww. After loading the project, go to Project > Edit Configurations and select the "ZNP-with-SBL" configuration.
Select "Erase, program and verify" under "Actions", and then select the firmware we just compiled next to "Flash image:"; finally, press "Perform actions" and wait for the process to finish. If anything goes wrong, remove power from the board, reconnect and retry.
Please note that you have to connect pin P2_0 (CFG1) to GND before applying power in order to enable the UART. Hear, hear... not documented. This is the biggest documentation fail, as the entire point of the ZNP firmware is to have a UART command interface, and they don't tell you how to enable it in the document that talks about the physical interface (or anywhere else, apparently).
In Tools\Z-Tool you can find a little piece of software which can be used to test commands. Conveniently, it's made to work exactly with the MT commands that the ZNP firmware exposes. Not all subsystems documented in "Z-Stack Monitor and Test API" are available in Z-Tool, but the 5 subsystem that are listed in "Z-Stack ZNP Interface Specification" are.
760c119bf3