So I am probably missing something fundamental, so is there any documentation on how to really use sleep mode and still have the photon be able to be reprogrammed etc. ??.
Basically I am trying to get my head around the various timeouts there MUST be when trying to talk to a Photon which is asleep :-O.
What am I trying to do
Simply reduce power consumption so I can run from a battery
Put my photon to sleep for say 30 seconds (longer when its working).
It wakes up - so I want to be able to read my data, update variables, (eventually publish data), then sleep again.
When it wakes up - I want it to respond to a previously sent re-flash command to load up new code etc.
What it ‘seems’ to do
Go to sleep for the allotted time (testing with 10 seconds).
Wakes up and reconnects.
Reads my data perfectly well
Does not update variables - as after a sleep it says there are none defined :-O.
Does not allow a program update :-O.
Hope this makes sense - its a pretty basic requirement for putting a device to sleep and waking again :-O.
Thanks…
BR
Graham
NB I tried 4 times to wrap the following as code - sorry :-O.
So the variable request is not queued in your cloud then, I sort of assumed it would be for a defined timeout, same as re-programming requests would need to be…
Guess I can still use publish though…
What about functions - do these also simply fail and not get queued either ???.
Seems like a timeout mechanism would be useful - define a max time on sleep, then when it wakes up it asks are there any requests waiting for me ???.
If nothing like this exists - then what use is sleep - especially if we lose the ability to re-program as well.
Guess I’ll have to come up with another solution then - using webhooks to an MS EventQueue maybe ???. I sort of expected that this queueing mechanism would be a basic part of the photon cloud…
OR - could I use your own pub/sub model and have my photon re-subscribe every time it wakes up ???.
Obviously I don’t understand the underlying photon<->cloud comms - as I can’t find it documented anywhere (yet).
Defered flashing is on the ToDo list (no exact ETA, but round about official Electron release), but there are some workarounds with pubish/subscribe/webhooks discussed on the forum.
Normally - with the current firmware version - System.sleep(time) does only deactivate the WiFi module, so your Particle.variables should still come back to life after reconnect, but - as @Moors7 correctly said - without connection the cloud can’t request the data from the device.
But for this version of sleep() (especially with a subsequent waitUntil()) I’d rather go for SYSTEM_MODE(SEMI_AUTOMATIC) and have full control over WiFi and still be able to get other tasks done.
Or if powersaving is your main interest use one of the other sleep modes.
Particle.functions do timeout when the device is not connected.
Particle.publish() has a TTL setting, but for Particle.subscribe() it’s not yet used.
BTW: Just for clarification - Particle.variables() are never pushed to the cloud but can only be requested and will give you their current state - or timeout if noone answers. Without a request the cloud has no knowledge of the state and on request the state is delivered to the requestor and to nobody else (including the cloud).
Again - thanks for the response. When is the electron release you mention scheduled for then ???. Tried to find it (but failed).
Yup - I do fully understand that my photon cannot respond if its asleep - BUT hoped that a variable request would/could be ‘queued’ in the cloud until the device wakes up. This is not a big issue as I only (currently) use variables to view the state of a device (during development), everything else gets ‘published’.
Yes - my need is for power saving as I want to run a photon from a battery, let it wake up, take some readings, publish them, then go back to sleep again (which is a pretty basic need for almost any IOT device I would think…). Hence my ‘rather hopefully’ it seems) ‘assumption’ that external requests would be adequately queued - guess not then. Its the mechanism I had already built in to my 868 MHz developments ;-). Wake up - read data, connect to my base station, send data - ask ‘anything for me’, do anything asked for, then go back to sleep again…
This is the first time I have started to try to use the sleep capability, as I now need to run a few devices from battery…
NB I can probably do without the remote update for the time being, but longer term it will become a MUST HAVE !! - to make a manageable product…
I’ll have to look at what you mean by ‘other sleep modes’ - as far as I saw so far - these need a wakeup pin, and all I want is to sleep for a while to minimise power, wake up every so often, and ‘do stuff’.
Looks like I need to dig out and dust off my Azure Event Hubs again then ;-). They queue stuff for a definable timeout, and delivery on demand or discard after an hour/day etc. Then make my own ‘cloud interface’ :-(.
NB Its partly why I posted a question AGES back about integrating with ‘Azure IOT’ (instead of Event Hubs) - which got precisely zero replies :-O. Hey ho…
Thanks though - I look forward to the ‘deferred flashing’ then…
System.sleep(SLEEP_MODE_DEEP, timeout) does not.
It does restart the device tho', so your code will go through setup() all over again. But seeing your code above this doesn't seem to be too much of a problem.
If you need variables to be kept across reboots you can use retained variables and the VBAT buffer supply.
And for triggering remote action on reconnect you wouldn't even need to publish your own event, since there is on by default
OK - I’ll try to get my head around this little lot then :-O.
Yes I did spot the reboot messages - and the upload completed I think…
As for the Dashboard - I did try that (more than a month back though) and didn’t find anything much useful (to me on there - I don’t want to set up multiple clients, customers, organisations etc. - I found it highly confusing :-O.