Reading Spark Variables with Your Own HTML File

I'd say he means to put the html file containing the page (including the access token) on your dropbox and then you can open that html from there, wherever you are and on whichever machine.

2 Likes

Hi @dmack

You just put the HTML file with your code including your access token into a folder on your Dropbox. Then from any computer or phone that you use Dropbox on, you can open the HTML file is a browser and use it as a web page.

I see that @ScruffR types faster than I do today!

2 Likes

Hello bko

When I run this code locally (file on my hard drive directly) I have no issue, the variable updates post haste! But when I run the very same code on my github.io hosted page it sits waiting forever…

I’m super new to the web page get post javascript etc… Any direction you can point me?

Thank you,
rjones

Unfortunately I don’t know much about github.io pages. I read some of the doc and it does not seem like there are any limitations that could cause what you are seeing, but it is hard to know. It certainly is not meant for this type of page.

In any event, a page like will not keep your access token secure and probably should not be used! I would look for a hosting solution that allows for PHP so you can keep your token secret or at least rewrite the code to ask for username/password and only store a temporary token in javascript.

I generally avoid these issues and run the page locally, usually from Dropbox so I can have it available on multiple computers & devices I am using.

2 Likes

So it was an SSL thing apparently. The github.io hosted pages are https and it was seeing the initial AJAX “call” (?) as an unsecured script trying to run on a secured page. I changed the http to https just as a longshot and it works fine now. I’m pretty new to the web side of things.

src=“https://ajax.googleapis.com/ajax/libs/jquery/1.3.2/jquery.min.js” type=“text/javascript” charset=“utf-8”>

Thanks!
rjones

I have question with your code, in script about the source what kind of source did you put? I m using photon and I m using a photon as my voltage sensor with a circuit.
Basically i m sending variable in html, but i m having difficulty getting that variable to my webpage. I m trying to use your example to see if it works.

Waiting for data...

<script type="text/javascript">

  window.setInterval(function() {

    var deviceID = <redacted>;
    var accessToken = <redacted>;
    var varName = "voltaje";

    requestURL = "https://api.particle.io/v1/devices/" + deviceID + "/" + varName + "/?access_token=" + accessToken;
    $.getJSON(requestURL, function(json) {
             document.getElementById("v").innerHTML = json.result + "&deg; F";
             document.getElementById("v").style.fontSize = "28px";
             document.getElementById("vstand").innerHTML = json.coreInfo.last_heard;
             });
}, 10000);
</script>

this is ur code with my variables

Hi @cora121

The variable name needs to match exactly, including the upper or lowercase letters, so make sure on your Photon you are using “voltaje” in your code where you declare the Particle variable.

When I redacted your post to hide confidential data, I noticed you had a leading blank in your deviceID.
This would probably also throw off the functionality.

1 Like

Thanks for the tutorial. I was able to get it working with my particle(argon). I’m placing the HTML/javascript in a sites.google.com page. Works great on PC, however the $.getJSON call does not work on an Iphone. Can you offer any suggestions.

I just double-checked and this still works for me on my iPhone using Dropbox to hold the html file. When I browse to that file in the Dropbox app and select it, it launches a web browser that works correctly. I am not sure why is doesn't work from google sites.

That said on my phone, I have completely switched over to use Siri Shortcuts to do things like this. You can set up a shortcut with your deviceID, token, and variable name and have Siri read the value to you, which has a high "wow" factor.

1 Like

Inspired by BKO’s superb tutorials, I am now reading 7 Particle Variables with my own HTML File. Three of those variables are 600-byte long Strings that I constructed from char arrays applying snprinf in the Photon code (as documented in this forum on several places).
I found out that my HTML page however cannot read the variables right after another: on unexpected instances the status LED starts blinking cyan at a rather high frequency and in the WebPage I can see that then only some of the Particle variables are displayed. After a short while the communication with the cloud restores again automatically.
As I can perfectly read all those varables from the Particle console, I concluded that the problem that I am facing with the HTML page might have something to do with the timing of the communication with the cloud.
So I have build in some delays between the JSON functions pulling the variables from the cloud. That works fine!

However it was a rather trial-and-error approach finding out about the size of the delays, and I would feel more confident when there was a more structured way to determine those delays, or at least indicate what parameters play a role in the “dynamics” of getting fairly large amounts of data from Particle Cloud.
Is there???

Hi @Jan_dM

I’m glad the technique worked for you and it sounds great that you can mostly take advantage of the long strings as variables.

There is no rate-limiting mechanism built in to Particle variables that I know of, but I’m not surprised that there are practical limits to how much back to back communication you can do. Don’t forget that every time your HTML reads a Particle variable, it is going from browser to Particle server to device and back. I would think that the last link of that chain, the device itself, is the rate determining step since the cloud will only issue one request at a time, so any work you can do to improve the “loop time” on your device would likely improve things.

Another limiting factor is how long it takes your device to get message to/from the Particle cloud. I did some experiments recording times in the distant past and found that my devices (in the Boston area in the USA) see about 140ms of latency for each message. I did these measurements before the Particle cloud was scaled up to the extent it is now, so the exact number is likely different today, but the idea is that if it takes about 140ms up to the cloud and the same back down, you cannot do back-to-back transactions any faster that about 280ms or about 3.6 per second. I’m sure these numbers are not correct for the today’s cloud, but doing similar measurements at your location might give you confidence in your delay values.

Thanks for your reply BKO!
A few additional questions/remarks:

  1. What is likely to happen when you pushing “pulling data” from the device at a too high rate? Will this disturbe somehow the data-processing within the device or within the cloud communication?Will it just stop communicating, or may the data get corrupted (or both). And is there a way that the Device might monitor/signal that?
  2. I observed that Particle console reports something that is called “round-trip time” (in the window Last Vitals), but I couldn’t find a suitable definition of that figure. Would that be the time to execute an entire back-to-back transaction (similar to the 280msec in your reaction)???
    If so: is there a way to monitor that in a Particle Variable? In that case you might use that variable in your HTML page to optimize the “pulling rate” in such a way that this is always a safe rate.

I’d apprecate your comment!

One thing to keep in mind is that without SYSTEM_THREAD(ENABLED) only one variable request will be serviced at any iteration of loop. So when you request more frequently than the device can service the requests you’ll potentially overflow the request queue.

1 Like

Thanks for the addition ScruffR.

My main concern is: is there a way to:
-either prevent the request queue from getting overflown (for instance by monitoring the back-to-back transition time and adaptng the request rate to that (with a safe margin) In that respect: what is “round-trip time” and is there a way to read that figure as another Particle Variable?

-or reduce the “damage” whenever an overflow occurs anyhow (will data be corrupted or will the connection breakdown and then somehow restore autonomously, or something?)

Hi @Jan_dM

My experience is that when you try to “pull” variables at too high a rate, you mostly miss data. You can also overflow the request queue in the device, weird things can happen since the queue is a circular buffer in memory and I have seen older data partially replayed once or twice. The connection either self-heals or the device reboots in my experience.

I don’t know what “round-trip time” is but it sounds like a the metric that I measured. I don’t know any more about it than you do. It was such a long enough ago that I’m not sure how I measured this time, but at that time I did have Wireshark setup on a separate laptop to listen in on packets from my devices, so I think that’s how I got that number and that would be a good way to measure it today. It will differ for everyone depending on the number of intermediate routing steps to and from the cloud.

@ScruffR s point about loop iterations and using system threads is exactly what I was trying say about optimizing your “loop time” only said clearer.

1 Like

Hi bko,
For your information: I’ve found the Particle definition of Round-Trip time; see: Introducing expanded Remote Diagnostics with Fleet Health and Enhanced Vitals
So:

  • Round-Trip time : the amount of time it takes for a device to successfully respond to a message sent by the Particle Device Cloud.
1 Like

Hi BKO,
I followed your suggestion to put the HTML file on Dropbox. That works perfect as long as I open the file from the Dropbox folder on my computer.
However, when trying to open the file from the Dropbox app on my iPhone, I can open it, but it doesn’t show the data at all. I only see the html page layout.
Do you have any idea what I’ve missed?

I just tried a few of the HTML files from Dropbox on my iPhone and they work for me. I do name them xxx.html, not sure if the exact file extension matters.

One other thing that has tripped some people up is that the jQuery library I linked to has gotten very stale in the intervening almost-seven years, so don’t use 1.3.2 and use the newest one instead.