Particle.Publish TTL implementation status

I have an application where internet connectivity is spotty. I need to set a temperature value which the Photon will get and store in local memory, then depending on the local temperature reading compared to that temperature limit published in the event it can turn on/off a thermostat.

This does not have to be super fast but reliable. It is possible that the device could loose internet connectivity for a period of time and would miss events that only live on the server for 60 seconds. If I could extend the TTL then it would drastically improve the reliability of the system.

I remembered previously checking the docs over a year ago and saw the TTL parameter had no effect at this time and would be implemented at a later date. Checked the docs today only to find no update there. Is this still on the docket? If so any estimate on a completion date?

@IOTrav, instead of pushing to the Photon, why don’t you pull from the Photon. That way, whenever it can connect, it will get the latest value.

1 Like

Hi @peekay123

I am open to that. How though? I cannot check a variable which is set by software through the Particle Cloud. The only thing I can think of is setting up a server that the device would pull from but that would add seemingly un-needed complication to the project(Server running all the time).

Can you explain your situation in a bit more detail? It looks like you’ve got a Photon which you want to send a temperature value to (setPoint). Sounds like a perfect application for a Particle Cloud function. Then it reads a local temperature value (from a sensor), compares that to the setPoint, and then turns a thermostat on or off? Where do Particle Cloud Events enter in here?

Hi @harrisonhjones

Generally yes this would be quite simple if your photon has good internet connection. You could pass the setpoint temperature to the controller through a particle.function() as an argument. However since the unit might loose internet connectivity for an extended period of time(couple of hours possibly) I do not want the user to have to sit there and continuously press that button until it works. I would rather them press a button on the software and then forget about it. If the device is offline when that happens then this setpoint temperature needs to live on the server for a bit until the next time the Photon checks in. This is where an event with extended TTL would be useful.

Hopefully I have that explained somewhat well.

@IOTrav, my approach requires that you have a server listening for published events from the Photon. Increasing the TTL would be cool but I’m not sure if and when that will come.

Hi @peekay123

This project is for a customer so I really do not want to maintain a server for the application and I certainly do not want the user to have to maintain a server.

Is there anyone who could chime in on the possibility of implementing the TTL argument on Particle.publish()? It has been on the todo list for quite some time now and I am sure I am not the only one who would like to have it :grinning:

Ping @Dave

1 Like

(Jeopardy Music)…

1 Like

I’m in meetings for the next hour or two, but I’ll reply as soon as I can if someone else doesn’t beat me to it :wink:

2 Likes

IOTrav,

Event TTL aside, let me try to think of another solution. Here’s one off the top of my head:

  1. Have your user attempt to set the setPoint using a Particle function call. If it fails (timeout) then store the setPoint in Firebase’s realtime database using the RESTful API.
  2. When your Photon boots up it triggers a webhook with an event which retrieves the setPoint value from firebase.

Firebase is “serverless” so no additional servers for you to manage :slight_smile: Thoughts?

1 Like

@IOTrav thanks for your question. This is a totally valid use case, and where our current function and variable primitives fall short. @harrisonhjones offered up a nice workaround above for the time being that could get you unblocked.

We are aware of use cases like this where it would be nice to be able to set and retrieve data on a device regardless of if that device is online. This likely won’t be full-fledged TTL, but a flexible “blob” that will allow you to store data in the cloud from a device, and query that info regardless of if that device is currently online.

I don’t have timelines on when to expect that at the moment, but know that it is on our radar.

Jeff

1 Like

The Firebase idea is the last example in my firebase tutorial, using Firebase for persistent variables to communicate data between Particle devices that are online at different times.

Sure, it’s more work than having TTL support, but has the advantage of working right now, and you’ll likely easily fall in the free tier so it won’t cost anything.

1 Like

I do not mean to pry by any means but what is the hold up on the TLL feature for Published Events? Is it just limited data storage on the server? I assume it would be stored in a MySql database?

1 Like