oliviad55
@olivia-davis · Joined March 2026
System integrator · buildings · 6 years in the field
- Topics
- 1
- Replies
- 8
- Points
- 0
Forum Replies Created
Is this the same colour as the Status badge on a Sites board? On ours they don’t always agree.
The “place but no site” card is handy. We onboard sensors in batches and a few always end up placed but not under any site. Where does it take you?
Found it, worked. Two of our dosing pumps came out as labelled boxes though.
Where is the button? Looked in Process Diagrams and in the 3D Designs list and found nothing.
A variant for sensor networks without TCP, it needs its own gateway to turn it into normal MQTT anyway.
And the XBee price includes a certified module plus Digi’s firmware and tools. You’re paying them so you don’t do RF certification yourself.
The device asks for fw_url again (an attribute request) and gets a fresh one, then resumes from the byte it had with Range. We’ve had downloads take an hour that way without a problem.
We did exactly this on building controllers (STM32 plus an ESP32 modem). Hermetry doesn’t care which chip ends up running the image, it only talks to the device that’s logged in, so the ESP32 is the one that downloads and reports.
When you assign a package, the device gets these shared attributes in one message on v1/attributes/set: fw_title, fw_version, fw_size, fw_checksum, fw_checksum_algorithm (SHA256), fw_url and fw_sig if the package has a detached signature. fw_url is a short-lived HTTPS address, valid for 15 minutes, and the download can resume with an HTTP Range request.
The device reports progress as client attributes: fw_state goes DOWNLOADING, DOWNLOADED, VERIFIED, UPDATING, UPDATED (or FAILED with fw_error), fw_progress 0 to 100 while downloading, and after the reboot current_fw_title and current_fw_version. UPDATED alone isn’t accepted, it wants to see the new running version.
Our flow on the ESP32:
1. fw_* arrives -> check fw_title == "irr-stm32"
2. GET fw_url (Range resume) into ESP32 flash, report fw_progress
3. SHA-256 + Ed25519 check against fw_sig -> fw_state VERIFIED
4. stream image over UART to the STM32 bootloader into bank 2
5. STM32 verifies again, swaps banks, reboots -> fw_state UPDATING
6. STM32 reports its version to ESP32 -> current_fw_versionYou have a 1 MB F407, which is single bank, so for 380 KB I’d use the upper 512 KB as the download slot and a small bootloader that copies it over after checking it. External flash works too, but then the bootloader needs the SPI driver.
On the profile’s Firmware tab turn on firmware updates (off by default), and leave Allow unsigned images off outside the test bench. Updates over LTE are off by default too. Set Hardware models on the package so an ESP32 image never ends up in the STM32 slot.