Data consumption blowout, pin_reset, and a large spark/device/diagnostics/update event

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:

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.

1 Like

This topic was automatically closed 182 days after the last reply. New replies are no longer allowed.