Queue data in cloud while device is offline?

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. :slight_smile:

If people are excited to have it though, we can try to bump it up the backlog!

Thanks,
David

7 Likes

I am exited about that :stuck_out_tongue:

Totally willing to help out with beta testing this feature!

I also need this feature and Iā€™m sure it will be a common need as well.

Any updates on this feature? Or should I go develop my own queueing system for now?

Hi @Carsten4207,

Thanks for asking! I havenā€™t been able to work on this, but Iā€™ll ping @bryce and @zachary who can speak to where this falls in the roadmap.

Thanks!
David

So, first, the whole team is currently laser focused on some big announcements coming soon. :wink:

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 :particle: 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 :particle: 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.

:heart: from :particle:

6 Likes

Hi @Dave ,

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.

thanks
Santhosh

1 Like

I sent you a message with an example app that uses it. :slight_smile:

Enjoy!
Dave

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.

We are also extremely interested by this feature, especially for queuing a list of actions to be performed once the device is again online.

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.

1 Like

Hi,

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.

In firmware :

  void loop()
  {
       if(yourTmeInterval)
         Particle.publish("spark/device/name");// or in setup block
  }
     void nameHandler(const char *topic, const char *data)
      {
	if( String(data).startsWith("prefix") )
	{
		function();

	}
   }

In app use rename cloud api or sdk
https://docs.particle.io/reference/api/#rename-a-device

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.

Sorry to bump...but has this happened?

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 :wink: ).

2 Likes

It has not happened. Thank you for bringing it up. :slight_smile:

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!

1 Like

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.

The introduction of the Rules Engine has provides a means to achieve this. Itā€™s still in Beta though, but feel free to apply :slight_smile:

2 Likes

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

:point_up: FYI @jeiden (product manager of the feature youā€™re asking about)

6 Likes

@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?

Hi,
Has any work been done on this feature. I would think for low power designs, queuing of firmware update and function requests is very critical.