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.
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.
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.
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);
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.
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
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?
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 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