I’m trying to get a good balance between polling my sensors frequently enough, and power/data savings. (This is with an electron.)
Currently, I take a sensor reading, decide whether to publish or not, then go to sleep for enough time to wake up at the next minute. I.e., poll at 12:00, 12:01, 12:02, etc… The electron is awake for about 20 seconds out of every minute, then asleep for 40 seconds. (I will probably increase this interval to 5 minutes, but 1 minute works well for experimentation purposes.)
I’m using normal sleep (not deep), with the “sleep_network_standby” option.
What I’m wondering is when/if the electron will send keepalives, when going through this continuous sleep/awake cycling. Yesterday, I was seeing “device came online” in the console log every 5 cycles (i.e., 5 minutes). Now, I never see “device came online” in the logs, and I didn’t change anything. Is “device came online” synonymous with a keepalive?
First, there is no keep alivewhile sleeping, so I changed the topic title, since you were not actually asking for that anyhow.
AFAIK keep alive only happens if required when there is no other traffic happening to keep the cell connection open.
The UDP based communication with the cloud on the other hand does also not really allow for a reliable online/offline status report from the cloud. So when you saw “device came online” messages but now don’t see them, I wouldn’t worry.
Thanks for changing the title… I was still half-asleep when I wrote it this morning, and it didn’t make much sense.
I seem to be using way too much data for keepalives only every 23 minutes. Right now, I have my sensor disconnected, so the code that reads it should timeout and report an error – which means that I should never send an update based on the sensor reading changing. Just to be sure, I’ll comment out the sensor read in the code and hard-code it to a constant.
Is there any way I can know definitively when the cellular transmits or receives billed data (i.e., keepalives)?
If you want to cut on data consuption, you’d need to take control of the cloud connection yourself.
You may want to call Particle.disconnect() before going to sleep and only reconnect if required, otherwise you’ll always have the cloud handshake on wake too, even if you don’t intend to use it.
The 23 minutes for keep alive only counts when there is no other traffic (as said above)
But you are not seeing the keep alive but the cloud handshake on each wake.
So there is no way to enter and exit sleep without either:
Disconnecting from the cloud to avoid data usage? or
Remain connected to the cloud, but handshake on every wakeup?
I was hoping to find a happy medium where I could frequently enter/exit stop-standby mode while not using data (aside from keepalives) unless I actually have something new to publish.
The problem with firmware actively managing cloud connectivity is that fw has to predict whether connectivity will be needed. If the prediction is wrong, then there’s either a needless disconnect/reconnect cycle, or the device stays awake and connected needlessly.
Disconnecting from the cloud does not immediately disconnect you from the cellular network, and hence you will not use the 6K cellular renegotiation when you wake and will also not have the cloud handshake with all the function/variable/subscrption update between device and cloud.
So that actually is the middle way
Why would you need to predict the need for a connection?
Would not an after-the-fact decission work?
You should actually know if you got data to publish or your last cloud communication was almost 23 minutes ago. Only in these two cases you’d need to reconnect to the cloud (although I’m not sure if Particle.keepAlive() even works while !Particle.connected()).
I assumed (I guess incorrectly) that disconnecting from the cloud would mean that I have to pay energy and data for cellular renegotiation and cloud handshake when I later decided to re-connect. If this were true, then I would have to decide whether to disconnect based on whether I expected to transmit an update in the near future. I.e., predict.
What you’re saying is that there is no energy/data penalty to disconnecting and reconnecting. I could disconnect, then reconnect only when here is something to transmit “right now” (either publish data, or a keepalive). It doesn’t matter if the reconnect happens one minute after the disconnect or 20 minutes after the disconnect because there is no cost to reconnect.
Not exactly.
What I was saying is that you will always have some data/power impact when reconnecting to the cloud, but that you would have on every sleep-wake cycle without disconnecting before sleep as well, so you save all the data/power penalties of unneeded reconnects.
Disconnecting before sleep tells the system it shouldn't bother reconnecting after wake, you'll take care of that.
BTW, I checked with Particle and the keep alive will also be sent when not connected to the cloud - as long as you are awake at least once in 23 minutes.
So you only need to reconnect when you want to publish, but the keep alive will be handled by the system.
@ScruffR, the keep-alive won’t work when sleeping. @BDub will be writing some docs for the power/data saving modes. Bottom line is you can save on data or you can save on power but you can’t do both together without some caveats.
I will try to explain...
I'm using an Electron with an additional 12v 9Ahr battery (boosted with solar charging) that reads an anemometer every 2 s.
Stop-mode sleeping (System.sleep(SLEEP_PIN,FALLING,2))
in between readings and only publishing a Health Status update daily (to me) and publishing an alert to the client if wind exceeds storm levels.
This has been working fine for the last 6 months
Now I want to add 20min live web based graphing.
I have hacked up test code working on my test Electron, but I now want to optimise that code for battery life.
The code I have working simply uses a delay of 2s, stays connected all the time and publishes data every 20mins to keep inside the magic 23 minute ping window. Thus keeping the data use as low as possible.
To keep my current consumption as low as possible I would like to be able to stop the micro and sleep for 2s between readings as the time spent awake to do a few ADC readings and check for excessive winds is very short.
The tricksy part is that I then want to connect every 20 mins, publish a string of data values concatenated together and disconnect while leaving the network on standby for the next publish in 20mins.
From what I have read, it seems this isn't possible at the moment because when I call Celular off(), it's not possible to also call NETWORK_STANDBY.
(please correct me if I'm wrong)
It seems that the above will be fixed with 0.6
Does anyone know when this 0.6 will be released ??
If anyone can see a way around the above issues before 0.6 comes out, please let me know
Thanks
Ants
