I have a webpage that needs to display multiple pieces of data being provided by my Photon. They should each be updated about every minute, and it is possible that several people will be using the site to view the data.
As far as I understand, if I used Particle variables, each individual page would be sending a request to the Particle cloud for the variable, then the cloud would ask for data from the Photon, and then it would send the data back to the cloud and the cloud back to the webpage, all on 20 second intervals. If this is correct, it seems very taxing on the whole system, as opposed to publish, where I believe the device would send out the information on 20 second intervals, and each page would listen for the data.
Is all of the above correct, and just to confirm, requests go to the cloud and not directly to the Photon, right?
Also, as a free user of the Particle cloud, I only get 250 thousand events per month, so I am guessing that one publish is an event, and one variable request is an event?
Finally, to get back to my main question, it seems to me like I would be better off using publish, but I am not sure, so which is the right one for me to be using in this case? Thank you.
I would use Publish. Have your webpage subscribe to your events and render the data.
Also, as a free user of the Particle cloud, I only get 250 thousand events per month, so I am guessing that one publish is an event, and one variable request is an event?
A publish is an event. A variable request isn't. At the moment we don't have strict limits on the number of variable requests you can make.
On initially loading the web page, have it request the value using a variable so you get the most up to date value without having to wait for the next publish. Then, subscribe to subsequent publishes so you won’t have to poll continuously.
It’s the best of both worlds: information when you need it, and new information as soon as it becomes available
@Moors7 idea is great, but note, variables are only available if your Particle is constantly online. If you put it to sleep, it can’t respond to variable requests.
Publish will require you setup a “hook” to your website in order to keep the data, as particle only keeps it for 60 seconds.
Indeed it is But note, if your device is offline, any other method won't work either. If you put it to sleep, it can't send any publishes.
Publish will require you to subscribe to events, just like requesting variables will require you to write logic. Particle (currently) doesn't hold the data so you'll need to catch it when it's sent out, or you'll miss it.
If the question was regarding whether to go for long polling (exclusively variables) or publishes, then I'd go for a combination, which has worked extremely well for me the last three years. There are obviously cases in which either would be a better choice.
It shows how to refresh a variable value shown on a page at any reasonable interval you select (1 second in the tutorial is about as fast as possible).
I would say the variables and publish streams are about the same but variables seem easier to me to recover from bad things along the way. Some things are just naturally better with "push" and some with "pull" so you will have to decide.
I wanted to correct this statement since it is not true today. Publish data disappears as soon as it is published from the cloud to any listeners today. In this way the Particle cloud is just a transport, moving published data from your device to your application in a safe and effective way. If the 60 seconds refers to the TTL value, that is ignored today.
A webhook is a way to integrate another web-based service with published data, but is not required. Webhooks are extremely useful for gluing together flows that can do amazing things, so if your goal was to save your data to a Google spreadsheet, I would recommend a webhook for sure (of IFTTT), but for display on your own site they are not required.
@Moors7 a request to a variable will time out, while publish does require the particle to be awake, one would assume at some point you would wake, publish and sleep again. The most common method in remote monitor.
I just wanted to point that out.
Fair enough. My general idea was then when the device is online, and you’ve just missed the publish window, you won’t have to wait until the next on to get at the data. And while the variable might time-out, there’s no harm done.
Thank you everyone for your responses, I will definitely try out your combination suggestion, @Moors7. Also, @bko, I have been following your tutorials, and they are very helpful, thank you. What "bad things" did you mean when you said:
Like any internet connected thing, sometimes we have connection troubles. With publish, you have to restart the listener to a new SSE stream, but with variables each access does not depend on the previous access–it is just a URL to fetch.
If you think past the one photon / one web page scenario, you might end up wanting a cloud-based process (or processes for redundancy) that subscribes to a number of photons, all of which are publishers. In this way, you have a central record of all the messages. Any web clients would then request the most current info from the centralized storage rather than from the devices themselves. This would scale well to any number of publishing devices and any number of web clients. It would also support the ability to look at historical trends, establish descriptive statistics on the values collected (Mean, Standard Deviation, etc) and allow alerting for values outside the norm.
But note, if your device is offline, any other method won't work either. If you put it to sleep, it can't send any publishes.