Queue data in cloud while device is offline?

Cloud
1

Due to iOS restrictions I have to push an event to the cloud at times when I want my Photon offline in order to preserve power and retrieve the data once it is online again. I’ve been diving through the documentation and it seems this is not possible with the current API/feature list.

Could someone confirm that the only way to achieve what I want is to either:

  • Have a separate Photon act as a ‘server’ which accepts the data through a Particle.function call and broadcast it further to the ‘client’ Photon once it is online again.
  • Use another cloud service to act as a datastore/relay.

Both options would spoil the idea of a IoT cloud for me which I hoped to have with my device. I had hoped the cloud variables were mutable through the API for example and would persist while the Photon is powered down, but that isn’t the case.

2

I just found a few related topics from a few months ago stating that such feature is in the roadmap and is being worked on. Any update on this topic @mdma/@Dave/#team?

[quote]“Things like storage and persistent events are being developed by the Particle team and are being pushed out between now and January.”[/quote] from:

3

Persistent variables are available a while already.
Give the keyword retained a try with the search function in the docs
https://docs.particle.io/reference/firmware/photon/#storing-data-in-backup-ram-sram-

Queueing function calls or subscribing to past event with valid TTL is not yet possible.

4

I’m wondering about persistent storage or queuing in the cloud, not local

5

If you refer to Particle.variable() these only exist on the device and the cloud can only GET the value from it. So the only place to keep them is on the device.
Imagine the cloud as only mirroring the Particle.variable. If the object vanishes the mirror hasn't got anything to reflect.
And manipulation of the variable is also only possible on the object and not on its reflection.

6

I am totally aware that the current implementation of the ‘cloud variable’ feature is just a way to retrieve a value from an online device. Like I stated in my opening post; my photon will be offline at the moment I am able to push a message to it. I -cannot- change the moment this message is send due to iOS restrictions. I’m looking for a way to push a message to the cloud and have the Photon retrieve it once it is back online. To my knowledge this is not possible at this moment.

My question to @Dave, @mdma, @clarissa is if such a feature is on the roadmap and if so, when it will be available.

7

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
8

I am exited about that :stuck_out_tongue:

Totally willing to help out with beta testing this feature!

9

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

10

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

11

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

12

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
13

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
14

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

Enjoy!
Dave

15

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.

16

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

17

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
18

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.

19

Sorry to bump...but has this happened?

20

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