Don’t push the .bin over MQTT. Hermetry’s OTA tells the device where to download the image over HTTPS and the device does the rest. I did 140 street-cabinet controllers this way last year. The parts:
Hermetry side (an Admin, and an Owner once for the key):
- Profile of the room sensors, Firmware tab: turn on «Allow firmware updates for this profile». Leave unsigned images off.
- Firmware > Signing keys: the Owner adds your Ed25519 public key. You sign each .bin on your laptop and upload the .sig with it. Hermetry never holds the private key.
- Upload firmware: Name must equal what the board reports as its firmware title, e.g.
room-sensor, Version e.g.2.1.0. - Assign it, first to One device (the one in your office), later to the whole profile.
Device side, once by ladder, after that never again. The board gets these shared attributes on v1/attributes/set:
{"fw_title":"room-sensor","fw_version":"2.1.0","fw_size":1183744,
"fw_checksum":"9c1e...","fw_checksum_algorithm":"SHA256",
"fw_url":"https://...","fw_sig":"..."}Your code then: report fw_state DOWNLOADING with fw_progress, download fw_url with HTTPClient into the OTA partition using Update.h, check SHA-256 and the signature, report VERIFIED, then UPDATING, reboot. After the reboot publish current_fw_title and current_fw_version. Hermetry only marks it Updated when that new version shows up. If anything fails, report FAILED with fw_error and stay on the old image.
Gotchas: fw_url is valid 15 minutes, so if a download stalls, ask for fw_url again on v1/attributes/req/1 and resume with an HTTP Range request. And firmware is never offered over plain MQTT, so the boards need to be on TLS.
Full page: Firmware updates (OTA)