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:
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'
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.
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.
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
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.
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?
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() ?
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.
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.
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?
