Variables unavailable when photon is in deep sleep?

I’m new to the Photon, so I may have missed something in the documentation. I’m starting out by developing a temperature sensor that runs on a battery. Since I want the battery to last for a while, I have the photon go to deep sleep for 5 minutes after taking a measurement. When this happens, I noticed that the cloud variables published by the photon are no longer available. Is this normal? I expected the value of the variables to still be readable from the cloud, which I planned to query through a web app. Is there a way around this?

If I’m not mistaken, variables don’t get ‘saved’ in the Cloud. The cloud acts as a sort of middleman to make connections easier. The Photon connects to the Cloud, much like your computer does. When you request something, the Cloud asks your Photon for this data, which it then routes to the computer requesting it.
As such, the Cloud can’t ask the Photon for information while it’s asleep. The features like you describe them might be added in the future, but for the time being, you’ll have to resort to alternatives.
If the receiving/requesting end is always active, you could have it listen to events, which can be pushed from the Photon. That way, the receiver doesn’t have to know when the Photon is awake, but will get its information pushed. HTTP calls, and webhooks are also possible, should you prefer those.

4 Likes

Ok, I see, thanks! Where does one post to make feature requests? :wink:

You just did :wink:
What might be helpful is some extra information on how you imagine it to work exactly. The more details and/or user scenarios, the better. @dave might be able to chime in when/if this will be implemented. If not, I’m sure he has some ideas that might be enlightening :smile:

1 Like

If I’m sleeping, I cannot update my facebook status or re-tweet the latest Kardashian updates. I have to wake up before I do that. :smile:

That said, what I last tweeted about Kim and Kanye is still in the cloud…

Have you thought about simply posting your (between nap) data updates to a server, or to google docs, or to many of the other available repositories which you may access 24/7?

The architecture of the core is really about linking… you got your subscribe(), your publish() your TCP and your UDP all available to you to make the connections.

A data repository in natively-supported particle lexicon would be a treat, but there are many ‘workarounds’ out there in the meantime. Many of which are discussed here on the forum.

As a side note, everyone is under pressure to monetize. What incentive would Particle have to make a native data repository which was captive to its (generally limited) hardware audience? There are soooo many folks out there want to be the giant in the IOT data warehouse business; it may be as crowded a space as the hardware side!

Good Question!

We’ve been thinking about this, and that’s also partially what the “TTL” is used for when you publish an event. This feature is in our queue, being able to get historic variable values and published events that still have “time to live”. :slight_smile: Feel free to post feature requests anytime in the forums or ping us directly! :slight_smile:

Thanks!
David

1 Like

You can’t tweet while asleep, but I can read your tweets while you sleep. :smile:

I assume you’re talking mostly about events here. Variables don’t have a TTL field, although I suppose you could add one. Or you could just return also a “freshness” value with the variable, like the time it was last updated.

Is the feature queue published somewhere? It would be very interesting to see the things you’re working on and to be able to vote for features that we’re interested in. Perhaps something like getsatisfaction.com?

1 Like

I’m thinking of the same functionality.

From my reading of the documentation, while my Photon is online I assumed the cloud would save up to 10 variables that could be accessed regardless of the offline/online status of the device from the cloud. A 24 hour max TTL would be fine too, as a compromise. There are just some cases where long intervals of information is not needed to be ‘live’ or subscribed to.

Thoughts: I also agree that the subscribe and publish are more the real time events.

My use: I would then query the values when the end user app needs the information.

Thank you,
Mr.Deek

1 Like

That’s probably where the confusion starts. Variables are not published, variables are exposed. SSEs are published, and therefore accessible through the cloud thanks to a potential TTL. SSEs are like Tweets: once out, they’re on the web and the sender no longer has to do anything for it to be accessible.

Variables on the other end is something you need to poll. Unless someone asks for that specific information, the sender is not going to do much.

So yeah, you can read a tweet from someone who’s asleep, but that same someone probably won’t respond when you ask them a question, since, well, they’re asleep ;)(?)

1 Like

Another anology might be, when you run a web server but switch the box off, no one will be able to GET any response of your server.
And for the time being your Photon is the server and the Particle cloud is a proxy with caching turned off.

3 Likes

So at least for ‘Particle.variable’ the cloud only pulls the global variable value upon request from the Photon. Confirmed ( [SOLVED] Particle.variable not working with function (*char var) )

[ Future Request ] Amend or introduce: Particle.push/pull value (“Name”, Value); with a <48hr TTL.

it would be very useful for when say a webpage/device is called (that is not persistence) and a value can be returned with the last state of the value from when the device was online.

Thank you again!!!
Mr.Deek

1 Like

The features like you describe them might be added in the future, but for the time being, you’ll have to resort to alternatives.

Was this feature ever added?

@oraclerouter, no it has not unfortunately.

Thanks for a quick reply.

1 Like