# Question about data usage tracking

**URL:** <https://community.particle.io/t/question-about-data-usage-tracking/58415>\
**Category:** Cloud\
**Created:** [November 13, 2020, 11:23pm UTC](https://community.particle.io/t/question-about-data-usage-tracking/58415 "2020-11-13T23:23:43Z")\
**Posts on this page:** 10\
**Page:** 1

<div class="post-metadata">

**Author:** ![AndrewM](https://avatars.discourse-cdn.com/v4/letter/a/c57346/32.png) [@AndrewM](https://community.particle.io/u/AndrewM)\
**Post date:** [November 13, 2020, 11:23pm UTC](https://community.particle.io/t/question-about-data-usage-tracking/58415/1 "2020-11-13T23:23:44Z")

</div>

Hi,

Is there a way in the particle cloud console to look up what data has been transferred to/from a device over, say, the past month?

I’ve just started developing some software on some particle Borons less than a month ago, and it already says one of them has used 12.5 MB, and another 4.74MB. For the higher one I can understand this, but the 4.75 device has so far only been used a few times, and the only actions I have asked it to take on the internet is to connect to the particle cloud and get the name of the device - something like:

```auto
 Particle.subscribe("particle/device/name", getnameCallback);
 Particle.publish("particle/device/name");
 Particle.connect();

```

---

<div class="post-metadata">

**Author:** ![armor](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/armor/32/18398_2.png) [@armor](https://community.particle.io/u/armor)\
**Post date:** [November 14, 2020, 4:11pm UTC](https://community.particle.io/t/question-about-data-usage-tracking/58415/2 "2020-11-14T16:11:40Z")

</div>

Are you using the console?

 ![image](https://us1.discourse-cdn.com/flex026/uploads/particle/original/3X/b/e/beaff32a304e613a49af707d01f4084ccf592597.png)

Have you read the reference docs? [https://docs.particle.io/reference/device-os/firmware/boron/#optimizing-cellular-data-use-with-cloud-connectivity](https://docs.particle.io/reference/device-os/firmware/boron/#optimizing-cellular-data-use-with-cloud-connectivity)

There are cellular functions that return the data usage and allow you to reset the usage counter. [https://docs.particle.io/reference/device-os/firmware/boron/#getdatausage-](https://docs.particle.io/reference/device-os/firmware/boron/#getdatausage-)

---

<div class="post-metadata">

**Author:** ![ScruffR](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/scruffr/32/6952_2.png) [@ScruffR](https://community.particle.io/u/ScruffR)\
**Post date:** [November 14, 2020, 4:52pm UTC](https://community.particle.io/t/question-about-data-usage-tracking/58415/3 "2020-11-14T16:52:40Z")

</div>

> [@AndrewM](#):
>
> ```auto
> Particle.publish("particle/device/name");
> Particle.connect();
> 
> ```

Just one note on that: Either your `Particle.connect()` is superfluous or your `Particle.publish()` is bound to fail.

You cannot publish without an _already_ established connection but if you already have one, why would you try to connect _again_?

One possible reason for excessive data consumption can be blocking code that may cause the connection to break and trigger an auto-connect which may result in several KB of data consumed for each try.  
Also OTA flashing will consume data, particularly when that implies a device OS update.

We do not know enough about your code to be more specific tho'

e.g.

> [@AndrewM](#):
>
> something like: ...

may even include something like this

```cpp
void loop() {
  Particle.subscribe("particle/device/name", getnameCallback);
  Particle.publish("particle/device/name");
  Particle.connect();
}

```

which would definitely be bad 😉

---

<div class="post-metadata">

**Author:** ![AndrewM](https://avatars.discourse-cdn.com/v4/letter/a/c57346/32.png) [@AndrewM](https://community.particle.io/u/AndrewM)\
**Post date:** [November 14, 2020, 5:26pm UTC](https://community.particle.io/t/question-about-data-usage-tracking/58415/4 "2020-11-14T17:26:07Z")

</div>

Thanks for that tip about the connect/publish thing. I was following the suggestion [https://docs.particle.io/reference/device-os/firmware/boron/#optimizing-cellular-data-use-with-cloud-connectivity](https://docs.particle.io/reference/device-os/firmware/boron/#optimizing-cellular-data-use-with-cloud-connectivity)

where it said to do stuff before calling Particle.connect to reduce data usage, but I guess that’s just subscribing and functions, not publishing.

I’m not using OTA flash that I know of. I’m almost entirely sure every flash has been through USB.

And no, that code is in setup, not loop, but thanks for the suggestion!

What’s the time limit for blocking code before it triggers a reconnection? That could be part of it, I do have a wait loop in there that I haven’t turned into an asynchronous timer yet, but it at most waits 7 seconds.

I did notice yesterday when looking through the cloud options an option to mark devices within a product as development to avoid firmware OTA overwrite, so I checked that. But I have not uploaded any firmware to the particle cloud yet.

Is there any sort of built in recovery I might be accidentally triggering? I have run into a few hard faults with some code that isn’t part of the project anymore.

Oh, and the code:

> **[StartLine · master · Andrew Moscoe / StartLineSoftware](https://gitlab.com/andrew.moscoe/StartLineSoftware/-/tree/master/StartLine)**
>
> GitLab.com

---

<div class="post-metadata">

**Author:** ![ScruffR](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/scruffr/32/6952_2.png) [@ScruffR](https://community.particle.io/u/ScruffR)\
**Post date:** [November 14, 2020, 5:43pm UTC](https://community.particle.io/t/question-about-data-usage-tracking/58415/5 "2020-11-14T17:43:24Z")

</div>

> [@AndrewM](#):
>
> What’s the time limit for blocking code before it triggers a reconnection?

Your code should be non-blocking as good as it goes, but at 5 seconds things may become flaky and anything beyond 10 seconds is an absolute no-go if you want your device to stay connected.

I noticed this in your code

```cpp
void wandInterrupt() {
  ...
  detachInterrupt(WAND_PIN);
}

```

This has become disallowed a while back - see this issue  
[https://github.com/particle-iot/device-os/issues/1835](https://github.com/particle-iot/device-os/issues/1835)  
Consequently, what device OS version are you targeting?

You should also avoid using `String` (and other statements using dynamic memory allocation) on projects that will be running for long periods without regular reset cycles as it may cause heap fragmentation which can lead to inability to connect to the cloud while still being connected to the cell network causing countless reconnection attempts.

Back to the topic of publishing without connection.  
I see this in your code

```cpp
    Particle.connect();
    Particle.publish("particle/device/name");

    //wait for display
    ERRCHK(epd->lcdCheck()); 
    
    //wait for internet DEBUG NOT CONNECTED
    waitUntil(Particle.connected);

```

Since `Particle.connect()` is not (always) blocking your `Particle.publish()` will probably still happen _before_ the connection is established. Hence I'd suggest you move that call _ **after** _ your `waitUntil()` statement.

---

<div class="post-metadata">

**Author:** ![AndrewM](https://avatars.discourse-cdn.com/v4/letter/a/c57346/32.png) [@AndrewM](https://community.particle.io/u/AndrewM)\
**Post date:** [November 14, 2020, 7:30pm UTC](https://community.particle.io/t/question-about-data-usage-tracking/58415/6 "2020-11-14T19:30:23Z")

</div>

I’m using DeviceOS 2.0.0-rc4 right now, and eventually will move to whatever the stable release of v2 is when that is released.

Thanks for catching that part about publish before waiting for connection.

If I’m not supposed to use detachInterrupt within an ISR, is there a good way to ensure I only catch the first edge of a bouncing signal? Should I set the interrupt in setup(), leave it always enabled and use a boolean guard flag so that the interrupt does nothing when I want it to do nothing?

> **[Device OS API - Boron | Reference Documentation](https://docs.particle.io/reference/device-os/firmware/boron/#interrupts)**

  
The interrupt reference does not mention anything about not using detachInterrupt from an ISR. This should probably be updated.

I’ll get rid of the String use at some point, it’s just convenient for now.

Is there a memory-safe way to use String as required by Particle.function() ?

---

<div class="post-metadata">

**Author:** ![ScruffR](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/scruffr/32/6952_2.png) [@ScruffR](https://community.particle.io/u/ScruffR)\
**Post date:** [November 14, 2020, 8:10pm UTC](https://community.particle.io/t/question-about-data-usage-tracking/58415/7 "2020-11-14T20:10:18Z")

</div>

> [@AndrewM](#):
>
> Should I set the interrupt in setup(), leave it always enabled and use a boolean guard flag so that the interrupt does nothing when I want it to do nothing?

I do use a flag set in the ISR to block further calls but also signal to `loop()` that the interrupt can/should be detached and then do it from there.

I agree, this should be documented but I'd rather prefer if the use of `detachInterrupt()` inside and ISR would be allowed again or at least we'd get a dedicated `detachInterruptFromISR()` function which ensures that any possible memory leak would be cleaned up by the system once it's save to do so.

> [@AndrewM](#):
>
> Is there a memory-safe way to use String as required by Particle.function() ?

Typically `Particle.function()` callback calls are a rare thing and hence the time before running into heap fragmentation issues is much longer with them than it would be with `loop()` code.  
However, I usually go with the undocumented but still valid version for the callback (`int callback(const char* argument)`) and then only use standard C string operations inside the function. That wouldn't remove the impact of the system call but prevents _me_ from _using_ the argument `String` inside the function and hence multiplying the impact of the original instance.

---

<div class="post-metadata">

**Author:** ![armor](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/armor/32/18398_2.png) [@armor](https://community.particle.io/u/armor)\
**Post date:** [November 15, 2020, 10:56pm UTC](https://community.particle.io/t/question-about-data-usage-tracking/58415/8 "2020-11-15T22:56:19Z")

</div>

Have you now completely solved and understood your data usage issue? Reading this thread it appears you have taken a different track from the title?

---

<div class="post-metadata">

**Author:** ![AndrewM](https://avatars.discourse-cdn.com/v4/letter/a/c57346/32.png) [@AndrewM](https://community.particle.io/u/AndrewM)\
**Post date:** [November 18, 2020, 9:18pm UTC](https://community.particle.io/t/question-about-data-usage-tracking/58415/9 "2020-11-18T21:18:20Z")

</div>

No, I still have no idea what caused the data consumption. I was hoping there was some way I could look at logs of what data was transferred form the particle console, but I guess that isn’t available?

---

<div class="post-metadata">

**Author:** ![system](https://us1.discourse-cdn.com/flex026/uploads/particle/original/3X/3/2/3291e3c9351789fe8620ae5bcec8d3fec67ff221.png) [@system](https://community.particle.io/u/system)\
**Post date:** [May 20, 2021, 9:18am UTC](https://community.particle.io/t/question-about-data-usage-tracking/58415/10 "2021-05-20T09:18:21Z")

</div>

Closed on May 20, 2021, 9:18am UTC

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