Our hotel has 30 ESP32 boards in the ceilings (temperature, humidity, a door contact for some rooms), all on Hermetry. The contractor who built them left, and now we need to change the reporting interval and fix a bug where they don’t reconnect after the router reboots. Every update so far meant a ladder and a laptop in 30 rooms.
I found lots of «OTA over MQTT» examples that cut the .bin into chunks and publish it to the device. That looks complicated and our maintenance guy is nervous about bricking boards above guests’ beds. Does Hermetry have something for this, or do I have to build the chunk thing? I’m not a developer, but our maintenance guy can flash an ESP32 if someone tells him what to put in the code.
Hermetry has firmware updates built in, I’ve seen a Firmware item in the IoT menu. No idea how the device side works though.
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)
And once it works on one, use «Send in waves» for the profile, so if the new version is bad it stops after the first few rooms.
Our maintenance guy did the ladder round last month with the OTA-capable firmware. Yesterday we pushed 2.1.1 (the reconnect fix) to my office board first, then to the profile in waves of 5. All 30 show Updated, no ladder. One room went «No answer in time» because the board was unplugged by housekeeping, it updated the next morning when it came back. The first upload was refused because the Name was «Room-Sensor» with capitals and the boards report «room-sensor».
- Debes estar registrado para responder a este debate.
Únete a la conversación
Inicia sesión para preguntar y responder, dar me gusta a las publicaciones útiles y marcar la respuesta que resolvió tu problema. Cada aportación suma puntos y niveles.