JS "backend" for website

[vskbellala]

Don't think this exists so here it is.

To create the interactive, live portions of this website necessitates 3 actions on the client-side:

• retrieving the dataset (in .json) from an external database (in this case firebase)
• transforming that data into a format that can be used by JS functions
• passing this newly formatted data into function for gauges, plots, and more

The latter two are not too difficult with some experimentation; its this first point that has proved the most troublesome, especially as we would need to handle multiple jsons (monthly data, daily data, live data). Some cases to consider are:

• firebase stops providing the json (json is inaccessible)
• handling multiple jsons; each json would necessitate its own xmlhttprequest. The benefit of this is that we can set custom intervals for each json to refresh. However, it is essential to ensure that we are not making more requests than needed.
  • Important to note that these custom intervals can vary wildly (refresh on the hour for daily data and every x minutes/second for live data)
• Station shuts down or drops below the minimum battery threshold (50% of max capacity). This shouldn't be a problem provided the station is able to report if is going to shut down or drop below minimum battery threshold.
• We take the station down for any reason. Firebase should be up 24/7, so we would need to indicate station availability another way. Previously, we discussed adding parameters to the settings part of our json that can let us manually set station availability, and even a custom message to display while the station is down.

function loadJSON2(sub, cb, time) {
    /* where,
    sub is specific portion of json to load
    cb is callback function to run
    time is an object containing ideal and alt times to wait in ms
    */
    //http request to get the json
    var linky = base_url + sub + end_bit;
    var http = new XMLHttpRequest();
    http.open('get', linky); // get the json
    http.onreadystatechange = function() {
        if (this.readyState == 4) { //was I able to access the json?
            if (this.status == 200) {
                var json = JSON.parse(http.responseText);
                cb(json);
                setTimeout(loadJSON2, time.up, sub, cb, time);
            } else {
                isDown2();
                setTimeout(loadJSON2, time.down, sub, cb, time);
            }
        }
    };
    http.send();
}

I've been giving quite a bit of thought to resolving that last bullet point. Currently, the website retrieves the dataset on an interval of our choosing, but this is done in a recursive manner, so we change the interval dynamically and avoid repetitive calls. Even the settings json must refresh on an interval There are 3 cases to acknowledge in regards to manually taking down the station:

• we shut down the station (true -> false): The program must halt all current timeouts (as no other station , display our custom message, and disable any plots, gauges, etc. as needed. This poses an interesting predicament as timeouts are defined recursively, so attempting to disable them all proves a challenge. It is also essential to make sure that we do not halt the timeouts for loading the settings json. Adding another setTimeout() call in this case may prove useful
• We turn the station back on (false -> true): The program must resume all timeouts for live, monthly, etc. data. This can be done by refreshing the page upon detection of the station turning back on or by calling setTimeout() once more for these datasets.
• the station is still in the same state as before, in which case we should do nothing in regards to other timeouts.

We can define global variables in js to track the status in this way, and assume "true" by default (on initial page load/refreshes) to handle the edge case where someone visits the dashboard while the station has been taken down. Ultimately, the challenge here seems to be defining a comprehensive callback function for the settings json and ensuring that we can dynamically clear timeouts.

I apologize if this seems convoluted; the above were some of my thoughts I had while brainstorming. Please reply if you have any questions or suggestions!

[joshua-8]

I don't know if this helps (and you may have already seen this), but in some of the examples on this page https://www.w3schools.com/jsref/met_win_settimeout.asp it seems setTimeout can be saved to global variables and adjusted by name in other locations

I don't know what firebase returns when it is unavailable because of being over quota, it might still return a json, but all the json says is some form of error message. We should probably find a way to test this or at least a reference from Google so we can know we're handling it properly. Maybe you can use try and catch? Reducing the rate of checking Firebase if it is unavailable might not be necessary, but is a fine feature to have. This error would probably make the website change the most from normal since it won't have data to display (though maybe it could keep longer term data visible if loaded?)

Other than firebase being offline, I can think of three different error states the station could be in.

1: station says it's unavailable for charging (due to low battery, time of day or other error state) but is still online. Since the minimum battery level is an artificial soft limit, I think the esp32 can just stay online logging data even if the battery is below the limit. At some point the esp32 might try to go into a low power mode but it will have been reporting unavailable because of low battery for a long time before that. 2: we manually set an error message for planned downtime that gets displayed on the site, but firebase is still running so we can still show data, it just would be a little out of date, but that's fine 3: station goes offline (because Brown's wifi goes down or something else unexpected) - I don't think we can expect to have the esp32 send a warning before this happens. This can only be detected by checking the timestamp of the most recent data. I think this can be handled similarly to 2, by showing all the data even though it's out of date, and maybe displaying a banner on the website. An offline station might still be functioning and available for charging.

I'm looking forward to talking with you at the meeting tomorrow!

[vskbellala]

These concerns were resolved at a subgroup meeting.

Closing this issue as the "backend" is seemingly no longer an issue.