I unexpectedly blew though my sandbox data allowance this month.
Investigation revealed a single Boron utilized essentially all of the data.
Exhibit A
Something was causing continuous reboots. I imagine something hardware related. Not sure, as I don’t have anything connected to the reset pin.
The relevant particle event was "spark/device/last_reset" : "pin_reset")
Exhibit B
The data hog was the event: "spark/device/diagnostics/update"
Which resulted in a 1kB message over and over again:
: “{“device”:{“network”:{“cellular”:{“radio_access_technology”: … }”`
I have unclaimed the device for now, until I can physically recover it for inspection.
In the meantime, has anyone seen anything like this?
I would like to implement some sort of automated guard to arrest a device that is over-consuming data like this! Under the pooled model, one device threatens the fleet.
Continuous reboot can use a lot of data, especially if you publish at boot, or if the reboot triggers a full renegotiation with the cloud, which can use up to 5K of data.
The spark/device/diagnostics/update does use data, but not as much as you’d think from the event log. The data sent by the device is in packed binary format in a CoAP message. The event that shows up in the event log is a synthetic event generated by the cloud, which fills in additional fields and expands the packed binary data into JSON key/value pairs.
To catch rolling reboot, the most common technique is to store a reset count in retained memory. If you are using SYSTEM_THREAD(ENABLED) (recommended), you can increment this at boot and take defensive action if some threshold is reached. You clear the counter from loop after the device has been online for a sufficiently long time. The defensive action is typically safe mode, but that’s best for cases where a bad OTA software update is causing the device to reboot shortly after boot. It may or may not be effective if there’s a hardware issue.