feat: Allow scheduling OTA on device request

[Nerivec]

I figured allowing to schedule update on next device OTA request could help with some tricky end devices... (instead of forcing the update, it waits until the device expects the queryNextImageResponse, which I believe should fit better with indirect transmission devices).

Using the MQTT endpoint bridge/request/device/ota_update/schedule you can register a device for update, so that if Z2M receives an OTA request from a device, instead of just checking for update, it will start the update process (which should match with the ZigBee spec).
bridge/request/device/ota_update/unschedule serves to cancel a scheduled update.
bridge/request/device/ota_update/schedule/downgrade is also supported.

TODO:

• fix: Allow scheduling OTA on device request zigbee-herdsman-converters#9048
• Tests
• fix: new OTA features in Koenkk/zigbee2mqtt#26823 zigbee2mqtt.io#3686
• feat: Add support for scheduled OTA nurikk/zigbee2mqtt-frontend#2449

[emag37]

Hi, just gave it a try and I'm happy to report that it works! I sent a message to bridge/request/device/ota_update/schedule with my device ID and sure enough it started updating upon the next OTA image check.

I just had to add a coalescing operator on line 118 of otaUpdate.ts to get it to build.

[Nerivec]

Any chance you can test this with a couple of different "store-bought" end device & router too to check their behaviors? I don't have anything in need of update at the moment.
You'll also want to test:

• doing this while having no image available
• doing this and interrupting the update (pull power off the device)

Can you provide some debug logs so I can take a look too (for both store-bought and your devices)?

About the tsn, I believe it should be valid there (have to match the request queryNextImageRequest's one), so, probably have to enforce its presence (which will validate typing).

[Nerivec]

@sarthurdev if you have some time, do you think you could see about adding support for this in frontend? 😉
Still a few things to figure out on this end, but it will be held until after April release anyway!

This shouldn't change existing features, just add an extra one (at the same level as Check for new updates I think), that would provide a way to tell Z2M to schedule an update for the next time the given device itself requests OTA (also might want to somehow accentuate the fact that this may work better for end devices).

[emag37]

Hi, I did a test where I disconnected the device by pulling the plug, here is the log:

zigbee2mqtt_interrupt_update.zip

The disconnect happens around line 20688.

When I plugged it back in, zigbee2mqtt seems to ignore the OTA requests. If I restart zigbee2mqtt and then resend the schedule command, it starts the update again.

Unfortunately, I'm just dipping my toe into Zigbee and don't have any store-bought devices to test with yet.

[Nerivec]

I believe this should fix that. If you get a chance to retry (make sure to leave enough time for the device to try again after booting up - you shutdown Z2M just a couple of seconds after the request came in in that last log 😬).

[sarthurdev]

@Nerivec drafted a PR with frontend for this: nurikk/zigbee2mqtt-frontend#2449

I wonder if there should be an explicit endpoint to cancel, or if re-sending /schedule on an already scheduled device should cancel the scheduled OTA update?

[Nerivec]

Thanks! I've added an unschedule endpoint for this, clearer than toggling on schedule I think.

[emag37]

Hi, I tried it again with the latest HEAD of the schedule-ota branch. If I remove the check for this.inProgress.has(data.device.ieeeAddr) in otaUpdate.ts:83, it restarts the update when I pull the plug and reconnect it. Otherwise it ignores subsequent image requests since it thinks they're still in progress. Not sure if that could break something else, though.

[Nerivec]

It should ignore until it's cleaned up (officially timed out) at line 168. And then the next request should take. You may not have waited enough time for the next request (the first one maybe two are likely ignored because Z2M has a rather long wait time before it times out on OTA, so it's still marked "in progress").