Feature Request: OTA updates

[MJDSys]

I've picked up a few more b-parasite's, and one though I had to simplify there management was to implement the OTA update protocol for zigbee on these boards, to simplify applying updates for people who have a large number of deployed devices.

I'm interested in trying to implement this feature, but I wanted to check first if this would be of interest to the project.

I could also take a look at BLE updates ((Nordic seems to be have samples)[https://infocenter.nordicsemi.com/index.jsp?topic=%2Fug_nrfconnect_ble%2FUG%2FnRF_Connect_BLE%2FnRF_Connect_DFU.html]) after I get familiar with zigbee.

[rbaron]

@MJDSys that would be a great contribution.

For the Zigbee sample I understand the OTA process is more standardized:

• The Zigbee Cluster Library specs define a OTA cluster and all state machinery (chap 11, cluster ID 0x0019)
• There's a Nordic example (Zigbee OTA Upgrade Client) that we can get inspiration from

Out of curiosity, I checked the available clusters on my Ikea push button on Home Assistant and indeed we can see the cluster 0x0019 for OTA:

For the BLE sample, IIUC the process is more ad hoc (as in: implementation-specific), and we need to think about these things (and I think we should):

1. Currently the firmware just sleeps (fully radio off) for 10 minutes, so we need to either a. Keep the radio always on during sleep, advertising so it can be found for update or b. Come up with an "async" updater that you leave running in the background and eventually start an OTA upgrade within that 10m window. I believe Zigbee Cluster Lib has backed-in mechanic for this async style of OTA (i.e. our end device will poll its parent every minute or so, including checking for OTA requests I believe)
2. We currently keep it very simple - just a few seconds of intense non-connectable broadcasting (read only) and then right back to sleep. The idea is to maximize the range during that short interval, so we're very aggressive there (meaning: very low adv. interval). If we want to broadcast a connectable OTA service, we may need to do so less aggressive and likely more frequently. One idea is to alternate these two modes, or spread out those intense TX more evenly across the 10m window (this may be actually better, or at least not worse anyway). This is less of a problem in Zigbee because we usually have more routers and can get away with less TX power when transmitting (having multiple ESPHome proxies may help here, but not as convenient)
3. Security. While I don't mind too much broadcasting the soil moisture of my plants (given the short range, and we can have encryption (another nice TODO)), I would be against having a public OTA BLE service. Some ideas are: some static, user configured password; or having to press the button to put it in OTA mode (less convenient); or something else. Zigbee solves this trust via the initial pairing

Again, I think these are important points that are worth addressing, even if at the expense of battery life, for added convenience.

Either way, I think solving for the Zigbee sample is surprisingly easier, since the path is well paved. I would start there. Let me know if it all makes sense, and thanks for starting this discussion.

[oleo65]

I would love to see a ZigBee OTA feature. A couple of months ago I already dug into the documentation and the implementation on the Zephyr zigbee side should be fairly easy.

The harder part is how to provide the firmware to the zigbee network via the coordinator. To my understanding this is specific to the used zigbee dongle or module and I did not find a definitive way to go.

For the raw b-parasite implementation, providing the actual firmware is optional and could be done separately. But it would be nice to know which way to go to at least verify, that the parasite OTA feature is actually doing what it promises. 😉

[AlbanDurrheimer]

The harder part is how to provide the firmware to the zigbee network via the coordinator. To my understanding this is specific to the used zigbee dongle or module and I did not find a definitive way to go.

If it helps, Zigbee2MQTT uses Koenkk/zigbee-OTA collection of Zigbee firmware references to check and update devices.