Asynchronous variable between two photons

I’m working on a project with two photons. One is a sender that publishes RGB values (based on the settings of three pots), while the other displays the color on an RGB LED.

I have the system working when both are turned on (by publishing an event), but I’d like them to also work asynchronously. If the sender is off, I’d like the receiver to still be able to read the last RGB value that the sender had before it was turned off. I basically just want to store a single string somewhere that another photon can grab when it wants.

The photon cloud doesn’t really do that and other topic threads I’ve seen have referred to a number of different services that might do this sort of thing, but I’m having trouble understanding the options well enough to pick a direction (this is my first IOT project, so I don’t have a lot of background knowledge). Most of what I’ve found is much more geared toward data logging, which I don’t need. I only need the last values. (Just stashing 13 or so characters somewhere).

My best try so far was to create an IFTTT rule that the sender could trigger that created a single line, public, dropbox text file, then have the receiver use a webhook to get the text. The problem was that IFTTT kept creating new files, rather than overwrite the old one. It also seemed a little roundabout (involving too many services).

Is there an obvious service (or other solution) to do this?

Why not…

In your receiver always store the last values, then if you cannot get the values from the sender, just use your last stored values (in the receiver?) - perhaps a flag to say the last stored values are valid (initialised on receiver start up as false), and every time you store the last received values, set the flag to true?

This seems too simple - perhaps I have missed something?


Do you also need the reverse; if the receiver is off when the sender publishes you want to save that value?

I’m sorry, I think I wasn’t clear what I’m trying to do. Here’s the case that I’m having trouble with:

To start the case, both sender and receiver are off. Then, the person with the sender turns it on, adjusts the pots to pick a color, then turns the sender off. Some time later, the other person turns the receiver on. I’d like to receiver to be able to get the last value the sender had when it was last turned on.

Which is, I think a “yes” to Ric’s question.

Does that make sense?


You might have to use an external site to hold that data. That way the sender can send data there at any time and the receiver can read that data from any time using a webhook.

Well, right now you need to use something external. Persistent publish is a planned feature; that’s what the TTL, time-to-live optional parameter in Particle.publish() is for, but it’s not implemented yet.

Ah, I see. External site it is.

Do you have any recommendations of how to implement that? I have a Raspberry Pi server running, so I could use that, but I am a little nervous about opening up a big security hole. I know there are a ton of cloud solutions out there, but I’m having trouble figuring out which ones would be the best suited to a pretty light weight use.


If you have a Raspberry Pi (or any computer that can run node.js), you have an excellent way to implement this without opening a hole in your firewall, or having a fixed IP address or dynamic DNS. No incoming connections are needed at all! The trick is that you run the server in node.js using the Particle API JS. It’s capable of subscribing to events and publishing events securely through the cloud just like the Photon and Electron do. It listens for events from the sender and saves the last value. When the receiver goes online is subscribes to a different event, then publishes and event for the Pi (or other server) to broadcast the latest value. I’ll try to write something up as a project share this week that can be used as a template, because this is a useful technique.


Brilliant! That sounds generally straight forward. Thanks! Looking forward to playing around with this next weekend.