I guess I'm going to have to put in a support ticket because some of these are running my software and some of them are running tinker yet they are overusing data at the same rate.
@Paul_B Did you ever get to the root cause of this excessive data usage ?
I have also noticed this behavior across my deployed devices within the United States. My devices remain idle 99% of the time and occasionally one will enter a state of "high data" usage, consistently consuming 1.2 MB of data per day (36 MB/30 days), as shown in the example below. To address this issue, I've added a function in my code that triggers a System.reset(). Whenever I detect a device entering this "high data" state, I use this function to reset the Boron (sometimes multiple resets are needed) , which effectively puts an end to the "high data" period. I want to emphasize that I am entirely confident that this excessive data usage is not caused by my code and the devices are in a static locations. Given Particle's current pricing model, this data consumption is becoming a significant concern as my device fleet continues to grow. Any chance we can increase the overall data allowance, or find the root cause of this?
On a growth plan you get 540 MB of cellular data per month. Simple calculations 540MB /1.2MB = 450MB and if we divide that against 30 days that will only last for 15 devices at best if the devices are not consuming other cellular data to post data in the cloud.
Unfortunately, I was unable to find a definite fix for the data overuse. My only guess is that my devices were not playing nice with the cell towers in my area. I even had three devices that were completely unusable and refused to respond to more than one cloud command upon reset. I allowed about three months to pass and recently checked on those same unresponsive devices, and the problem seemed to fix itself. I have even been developing on some of the previously misbehaving devices with zero issues. I communicated with Particle and they were unable to identify the root cause of the issue. The issue is extremely frustrating, and I spent over a month of rewriting code, testing, changing OS versions, and just general troubleshooting trying to find a solution. Sometimes the problem would disappear if I factory-reset a device multiple times and only flashed it with my software once (emphasis on sometimes), but I never managed to find a realistic solution for fixing this issue on a large array of devices. I have about 18 particle Borons currently, and trying to deploy them became extremely difficult with the data overuse. I wish I could tell you why my data overuse issue disappeared, but the fact remains that the devices sat purely untouched for multiple months and fixed the issue themselves.
On another note, if you manage to contact someone at Particle, they were nice enough to increase my monthly data cap while we attempted (unsuccessfully) to find the root of the problem. I wish you luck, and hopefully it doesn't take a couple of months to somehow resolve this problem.
1 Like
Thanks @Paul_B.
I think it would benefit everyone if Particle incorporate a fix within the OS. As my fleet is increasing I'm seeing this behavior more frequently on random devices and at random times.
For what it's worth, I'm currently running version 4.2.0 on the devices that were giving trouble and haven't had any problems, but I doubt this will solve your issues.
Thanks, I'll give it a try soon. My fleet is at 4.1.0 at the moment.
@Paul_B It seems like version 4.2.0 might have contributed to improving the situation, although I'm uncertain whether this improvement was a direct result of addressing the issue in the bug fixes for that version. I've rolled out the update to a few users who were experiencing high data usage, and currently, the usage is approximately 0.05 MB per day down from 1.2 MB per day. This is with running the same underlying custom code.
2 Likes
Glad to hear that. I currently have one device in my fleet still running version 4.1.0 and it is the only one experiencing the 1.2 MB per day usage issue. I'm about to deploy some more devices running 4.2.0 with the same underlying code as well. It seems the approx. 1.2 MB per day over usage is the "standard" usage amount for this problem. Unfortunately, I don't know of a way to figure out what data is being transmitted.
I am experiencing a very similar problem with 5 of my 39 devices which eats through my data within 2 weeks. I have made multiple revisions to firmware without any luck. The next tier up is way too expensive for this solution and so I am franticly trying to fix this as I am 10% over my allowance this month without a reset until May 6th. I don't understand how ~30 of my devices are running no problem and I cannot recreate the problem with test devices that aren't deployed.
Attempting to get the 4.2.0 OS compiled for my fleet, however I am running into a problem where my test device will not flash the new OS. Fails around 25-30% completion. Has this ever been a problem for any of you? Not sure what I am doing wrong.
Hey, sometimes this tool got me out of trouble, want to try it?
Thanks! That seemed to work. My problem devices I want to test with this new OS are out in the field, so are there any steps I should take to successfully flash a device with the new OS remotely?
Depending on what current device OS you are running, it may be somewhat tedious to flash the new OS remotely. Upgrading is fairly easy, however downgrading seems like it may be a process. I have yet to attempt an OTA downgrade, and I am also unsure if it is the equivalent of using the Device Restore process, which is how I have resolved the data-overuse problem with my devices in the past. I will also note that attempted to fix this problem on a device that was previously running 4.1.0 via an OTA update, however it exhibited some odd behavior, and I will likely have to manually update the device when I have an opportunity. TLDR: try to deploy future devices with 4.2.0 initially so you don't end up with a mess of misbehaving devices if you are experiencing this issue. There's some info about downgrading here: Versions and upgrades | Reference | Particle
I have read that article you are referring to. I am not trying to downgrade the devices, rather upgrade, but cannot seem to get any remote device to accept the firmware with the 4.2.0 OS build. From my understanding and what I have read it seems that the devices should update their system firmware when flashing the application firmware OTA. But I am seeing the devices just sit and try over and over again without any luck. It seems to be the same behaviour I was getting with my local device however it obviously wouldn't sit and retry since I was only sending the command once.
If the device is failing to upgrade it will use a large amount of data but no data operations.
- What is the Device OS version prior to upgrade? If it was before 3.1.0, if the upgrade is interrupted it will restart from the beginning each time instead of resuming where it stopped.
- Does the device sleep? If your code sleeps without checking for an upgrade in process, it could stop the download in progress.
- Do you have a hardware watchdog? If the timeout period is too short, upgrading Device OS will fail. This is because when Device OS is being upgraded, user firmware is not running so presumably your watchdog servicing code is not running.
1 Like
The devices are on OS 4.1.0 and I have no troubles updating firmware remotely when it is just an application code change, it is the OS change that seems to cause problems remotely. The application code does not have any sleep calls in it to put the device into a sleep mode as it is always scanning for BLE tags. No hardware watchdogs exist either.
I will point out as well, the data problem has existed long before I have been trying to upgrade to 4.2.0. I have just seen on other posts that upgrading might help.