I am trying to optimize my data usage for an Electron device and have noticed the following usage:
10 days: 0.67mb of data
My Electron is publishing an event every 5 minutes called “Temp” with values similar to “71,53,97,0”.
That’s approximately 10 bytes of data. Where is the rest of my data usage coming from? I do have some cloud variables configured but I am not calling them on this device.
Are you using deep sleep? If so, see the note by @BDub on handshaking with the tower after deep sleep: Electron data usage
I am not using any sleep routine. I have my main loop polling for power source our temp change and firing off an event of thr condition is met (very infrequently) and every five minutes it publishes the data to my server.
It would be nice if we had a better peak at our data usage specifics as that could help optimize things on our end.
A few things you should keep in mind:
What you are seeing doesn’t seem like an outrageous amount of data for 10 days continuous usage.
JU
Each minimum publish currently with acknowledge is about ~70 sent and ~60 received, so if you add ~14 bytes (“Temp” is 4 bytes) to that let’s call it 144 bytes. Pings are 122 bytes every 23 minutes, but should not be happening if you are sending data every 5 minutes.
So 1441224*10 = 414k. This assumes no disconnects or re-handshakes… could be happening if signal strength is low or the tower is bouncing you.
I would suggest reducing “Temp” to just “T” and spread out your publish interval a bit if you can tolerate it. Also, you could pack that data in groups of 5 or 10 to save on the overhead… unless you require the realtime aspect of the data.
When we release no acknowledge publishing, this will reduce the data usage by almost half.
Outstanding feedback. Thank you! This gives me a much better picture at what is going on. I’m looking forward to the no acknowledge publishing. I’d like to still do every 5 minutes but I won’t need the acknowledge response.
Thanks again for the feedback BDub. I was also watching the logs on the Particle Dashboard. Is return data from a hook that goes through the Particle server sent back to the Electron?
Example:
hook-response/t/0{“recorded”:true}March 15th at 10:08:54 pmparticle-internal
Is “recorded”:true" sent back? That is what my webhook returns.
@Bdub - Has the no acknowledge publishing for the Electron made it to any official firmware yet?
I just put my Electron online to test out data usage for sending webhook data to an Azure table database, and I'm trying to optimize usage.
Yes it’s in 0.6.0-rc.1, sorry docs aren’t out yet… here’s the info:
Unless specified otherwise, events sent to the cloud are sent as a reliable message. The Electron waits for
acknowledgement from the cloud that the event has been received, resending the event in the background up to 3 times before giving up.
The NO_ACK flag disables this acknowledge/retry behavior and sends the event only once. This reduces data consumption per event, with the possibility that the event may not reach the cloud.
For example, the NO_ACK flag could be useful when many events are sent (such as sensor readings) and the occasional lost event can be tolerated.
// SYNTAX
int temperature = sensor.readTemperature(); // by way of example, not part of the API
Particle.publish("t", temperature, NO_ACK);
Particle.publish("t", temperature, PRIVATE, NO_ACK);
Particle.publish("t", temperature, ttl, PRIVATE, NO_ACK);
@BDub Sweet!
I will load 0.6.0-rc.1 on my Electron and see what kind of difference I see in data usage.
Right now sending a full JSON string every five mins the Electron is using 0.08 MB per 24 hours.
Can you provide more data on exactly how the NO_ACK feature cuts data consumption by up to half vs. not using NO_ACK? Just so I understand what is going on 
I might be wrong, but up to half might be a conservative estimate, since it might actually be up to 2/3+ when a publish without NO_ACK would actually continously fail on the first two attempts always needing all three attempts.
With NO_ACK you’ll save all the extra attempts, since it’s fire and forget and you also save the ack packet, which usually is only a fraction of a potentially full size event publish, but that’s the guaranteed minimal saving on each publish.
Thanks for the info @ScruffR ScruffR 
Is the first two of three publish attempts failing a known issue? Or is it just something that could happen under weak cellular conditions?
That’s a “safety net” for failing publishes for any possible reason - one of them weak cellular conditions.
But it’s not an indication for a known issue - much like an airbag in your car is no indication of the manufacturer not trusting you as a driver
Got it. I just didn’t know if this was something that others saw happening often or not.
I running the 0.6.0 firmware on the Electron now and I’m going to compare the same webhook using the NO_ACK to see what kind of data savings happens. I’ll report back on this.
Hey @ScruffR how is NO_ACK going to fail in your scenario? The idea of NO_ACK means it’s sent… but you don’t get confirmation that it got there. So there is no retry happening here.
I would suggest that if you are seeing the need for retries every time you publish, you probably don’t have an active PDP context and the Electron is likely re-handshaking before the publish really gets sent. I’d like to know more about what you’re seeing because it doesn’t sound normal, or at least is not the desired operation of the Electron and something we possibly need to fix. I wonder if it’s also possible you are seeing a very late ACK.
@RWB up to half comes from the observed effect that every publish of just one byte is about 61 bytes of data usage (data, encryption and overhead). Also there are about 61 bytes received for the ACK. So if your payload is large, it starts to be less than half since the ACK doesn’t change size. Does that make sense?
Yes that makes sense. Thank you.
I'm comparing the ACK vs the NO_ACK on the 0.6.0 fimrware now. I'll let you know the difference I see after 24 hours.
Now the next question I have is where are we at when it comes to reducing data rates when putting the Electron to Sleep?
I know you were working on reducing the frequency that the Electron needed to handshake or ping the cellular server which in turn reduced the amount of data used over the course of a day.
Can you also point me in the right direction when it comes to this?
@BDub, could you quote the exact statement you are refering to?
I guess you might have misunderstood what I meant, or I haven't expressed myself well.
When I said
I thought I've actually stated the same fact as you there 
If - on the other hand - you were refering to this
Then this was not a picture that I am seeing, but rather a worst case scenario that would describe the potential max data conservation effect of using NO_ACK
Try soft powering down a 0.6.0-rc.1 electron by double tapping the setup button. This is effectively deep sleep. Then press reset. Notice how fast it connects. No handshake! It's resuming the previous session.
I think I read publish with NO_ACK instead of publish without NO_ACK, sorry for the confusion! 
The question remains, when you said this sentence, it made me believe you typically experience every publish require 2 retry events. That should not be the case and I wonder why it is for you.
I just found this in the 0.6.0 firmware update reduce datausage on reset/wakeup by m-mcgowan · Pull Request #953 · particle-iot/device-os · GitHub
Does this work now automatically when using Deep Sleep on the Electron or do I need to follow the recommendations that is in the link above?
Great work either way Team 
I would advise using it as described… I may have misspoke about the soft power down… I swear I was just using it that way though and it was powering up super fast (blinking green and cyan in a couple seconds). Now that I’m trying it again it’s going through a long connection process (blinking green) presumably due to powering off the modem, but a very fast handshake process (blinking cyan). Still the low data usage you were after 