I would like to use persistent functional calls in my project but didn’t find a ton of documentation. The closest thing I could find was a post by @mdma here: Power issues for uses that requires commands sent. Since that post hasn’t been updated since August I figured that I would start a new thread on persistent functional calls through the particle cloud network.
Solar Powered Sensor Box Project Overview
I am making a solar powered perpetual sensor box that hooks in to numerous other devices. Because the power draw is greater than what the solar power can provide it will have to sleep to recharge. The length and time of these sleeps cycles can vary drastically depending on use and I don’t want power limitations impacting critical user functionality.
After some research, it seems like my best approach is to sleep in 15-30 minute cycles. When the photon wakes up it will check another website to determine how long it should sleep, it at all. It will report back current power levels and will prevent the user from creating unreasonable power cycles. At first glance persistent function calls appear to be the best approach.
- Have there been any updates to persistent function calls with the latest firmware updates? Is there anything scheduled for the near future?
- Are there any workarounds in place now? What would you recommend that we use in the interim?
- Will it be possible to overwrite commands already sent out? For example, if I want to change the sleep time to 60 minutes in one command but decide to change the sleep time to 90 minutes later?
- Can we duplicate persistent function calls through scripted curl commands? Are there any downsides to this approach?
- Will there be any methods to interrupt the photon sleep cycle?
- Are there any power scheduling examples that would be a good place to start?
Thank you for all your time, help, and feedback
What if you set up an IFTTT to read a google spreadsheet or something. update the spreadsheet with the time you want it to sleep.
Dear sir (or ma’am), I love lots of questions in numbered form. It’s like a checklist!
Your questions are very similar to the Guaranteed Delivery from Particle Cloud to Particle Device thread from earlier today. In that thread, he’s asking about publish/subscribe (pub/sub), but the end goal is very similar.
- Not yet. However, it’s on the feature list, but I’m not sure what the priority level is yet. There was recent news from another product that may include what you are looking for. See the quote below this list for more info.
- I personally don’t know of any solutions off the top of my head, but I wouldn’t doubt that it has been done before. As an interim solution, see my response in the thread mentioned above.
- At this point, you might be rolling your own solution, so you can do anything you want there!
- See answer #2 above.
- You can use pin or timer interrupts to wake the device from sleep, but there is no way to wake it from wifi. Part of sleep is turning wifi and the cloud connection off.
- Check out the Spark Battery Life Testing thread. The Photon consumes less power, so you could consider those timings in that thread as a worst case scenario.
DigiStump is working on their own wifi device, called the Oak, that runs on the Particle Cloud. One of their touted features was “persistent events”. This is a small quote from their newsletter that went out yesterday (2015-10-30):
Things like storage and persistent events are being developed by the Particle team and are being pushed out between now and January.
Since that isn’t directly out of Particle’s mouth, don’t take it as gospel. It may only be initially rolled out for Oak. I do know that both companies intend well for their users, so don’t get discouraged or anything. Plan for the worst and hope for the best!
I’d like to ping @dave on this one for corrections/clarifications. This feels like it might be in his area of expertise.
In terms of rolling your own, I’m doing something very similar on the Raspberry Pi (RPi) using the Amazon Web Service called SQS (Simple Queuing Service).
The issue is, however, that the RPi can run python - so the equivalent of the (RPi) python code would have to be developed to run withing the Photon firmware implementation. Yep - what we really need is the ability to run python on the Photon!
Let me show you how easy this is to implement (in python) – it may spur someone on to write an implementation for the Photon.
The simplicity of the Arduino like Photon programming environment has obvious merit - but it leaves one out in the code in terms of leveraging the power of a full-featured development language.
Sorry, I just can’t resist to comment
Maybe I don’t undestand the term correct, but how many major software projects and even OSs are written in C/C++? I’d think more full-featured and ready for professional development it can hardly get
OK - I deserved that. Thanks!
What I am thinking is a language/dev environment suitable for the “maker” community - where arduino dominates. And a language that “interfaces” with the dominate cloud providers.
Your point is well taken and I hope I didn’t start a language war!
Happy to chime in here! Yes, we have been experimenting with durable function calls and flashes to your devices, but we haven’t released those generally yet. Yes we’re thinking about storing historic variable values and published events so your device can publish and go back to sleep quickly and you can get that from the cloud later. I’m not sure about exact timing yet, but hopefully in the next few months!
Great, eager to see progress for durable variables, it could help reliability in my current application.