Itās on the roadmap, I donāt have a planned date for it yet. There is a secret version of this on the cloud, but itās not documented / tested, so Iād want to clean it up before letting people start using it.
If people are excited to have it though, we can try to bump it up the backlog!
So, first, the whole team is currently laser focused on some big announcements coming soon.
Second, the feature that is being discussed in this thread may seem simple at first glance, but as we have played out all the related scenarios across the platform with different types of users (hobbyists, enterprises, everything between) with different types of devices (Photon, P1, Electron, bluz, RedBear Duo, Oak) using different protocols, some hardware made by and some not, it has become clear that this feature (1) will be an amazing level-up, and (2) will take multiple sprints worth of work even if the whole team is tackling it together.
Weāve got specs internally and have driven out a lot of the uncertainty. There are plenty of stories in our issue tracker. The broad description of what weāll be building is āsleepy devices as first class citizensā. It will involve making the TTLs on our events meaningful. It will involve paid tiers of historical data usage. It will involve new API endpoints for asynchronously accessing state that changed long after you requested the change. It will involve both event-driven and polling workflows for users to handle the asynchrony.
Weāre definitely excited about these features, and we know you all are going to love them. The current roadmap has us shipping them around October 1. Iām sure I donāt have to tell you that things change, and this is only our current best guess. But there you go folks ā no promises, but a little peek behind the curtain into our roadmap.
I am in need of this functionality badly, could you please give more details regarding this secret version on cloud. I can definitely help you guys on beta testing.
Iād like to see an example of this as well! I have built my own system for dealing with this, but Iād like to get away from maintaining a separate system for a feature like queued messaging.
Has this feature been implemented yet? Iām guessing no since Iām currently seeking a solution for this problem.
Specifically the cloud functions, can you call them while the device is offline and have them execute while back online?
Iām making a mobile app and it seems I will have to sync the times when its on to be able to push a function call, requiring my app to always run in the background. Iām not too sure this will work though.
I can suggest you a dirty work-around to use till the feature based on ttl is available, you can change your device name and append it with some string flag to identify the function you need to call so that you can check on its name when the device is online and call the function.
I donāt know how bad this is but i didnāt see any other option to achieve this for the time being. you may also need to change back device name from your app and then do āparticle.disconnect() and connect()ā in firmware to clear cloud cache and get updated device name after executing the functions.
There hasnāt been any change in regards to deferred publish/subscribe, function calls or variable request, but as the upcoming mesh infrastructure will be more reliant on such a feature this has made its way up in the priority list quite considerably - but thatās all we - non-employees - can say so far (we also keep bumping this topic ).
It has not happened. Thank you for bringing it up.
Iām happy to report that we are actively designing a feature that could fill this need though. Thereās no telling exactly when it will be released, but the topic is finally bubbling up! Sorry you had to wait so long!
Has it happened now? I have exactly the same issue. I want my device to be powered off must of the time, and as soon as is online again, retrieve all pending events.
Jordyās right about the rules engine, but no, the feature I was referring to in April got deprioritized as we ramped up to all-hands-on-deck for the third generation hardware.
Luis, I appreciate you advocating for this feature. Please keep doing so. As my best guess right now, I do not foresee it being implemented before mid-2019 at the earliest, probably later.
In the short term, your best bet is to implement the queueing in your own web app, along these lines:
in your own web app, enqueue the messages
make sure the firmware is subscribed to hook-response/get-messages (see the webhook tutorial)
on wakeup, have the device publish a get-messages event
create a webhook that listens for that event and hits your web app
the response body of your web app should be a list of messages in a format that your firmware can process
Good luck!
Zachary
FYI @jeiden (product manager of the feature youāre asking about)
@zachary, thanks a lot for the transparency and open communication on this very hard problem. Iām guessing that since thereās been no news that this hasnāt come to fruition yet. Any chance for an update?