I'm querying the unit for the real time data over local api and it looks there is a bug there. Sensor 1 is returned properly but sensor 2 and 3 ALWAYS have a "nan" value in the last row of the JSON Array. So they only return 59 proper values.
And that screws around with the parsing of the array to display it as a real time plot if we want to plot all 3 phases.
Yes,
I also see this bug, when I want to read the value of my gas and water!
In my php script.
Sven
Hi Sherlock, Sven,
The 'nan' value is inserted intentionally. If you make a call with the param interval=minute it will return you the readings of the last 60secs. If no value can be returned for a specific timestamp, it will fill in the blank with a 'nan' string.
NaN is a Javascript property. It is however not included in the JSON spec. So setting the value to the 'nan' string is the JSON workaround. You should build in a check in your code that parses the array and does one of the following:
1/ Remove all entries with a nan value.
2/ Substitute the nan by null, nil, ... depending on the language and charting library you're using.
For the new JS-based Flukso charts, I'm using the map method on the data array:
-Bart.
Bart,
The value nan is usually reported as the value last second of the JSON array. The most recent one. Why then the API reports it if it has not been measured yet?
While replacing nan is easy it is hardly a solution. When replaced they need to be replaced by the neighbor values and not 0's as that looks bad on a graph.
It is annoying that API is not reliable in reporting 60 seconds of valid data. And we get 59 or 60 valid results randomy. If you graph 3 phases on one graph in 1 sec interval I need then extended logic to align the 3 sensor readout and check for NAN's.
I think this is issue to be fixed.
PS.
Additionally for a local API it would be nice to be able to get all 3 sensors in one call so there would be no case that I get 0-60 for one sensor and 1-61 for another as it arrived late due to the time of the call over the network.
The real-time api will indeed typically report a nan as a last entry on all but one of its sensors. The server api can have multiple nan's present at the end or even in the middle of the data series. Have a look at any of your sensors on the hour chart [1]. This chart will be generated with an x-axis from 'now' to 'now - 60min'. If the FLM has not reported in the last e.g. three minutes, at least three nans will be present when making a query ?interval=hour.
Any charting software tailored towards plotting time series worth its salt should be able to cope with nans by not drawing anything. I think it's wrong to force a nan to either zero or the previous value. A nan means that the value is (as of 'now') unknown and thus should not be rendered at all.
[1]: https://www.flukso.net/chart
HTH,
-Bart.
I get your point for the server API, as server might not have data due to the fact that the unit was not connected. But for local Api there is no excuse.
I worked around it by posting to the graph the values that are 3s from the past. There is no case the realtime api reports those as nan. Now the graph works but is I made extensive tests of the local api and about once in 50-100 readings it will report two nan's as values for the last 2 seconds, but then on the next second it will fill them. so the only save value is 3 seconds from past.
As for the nice handling of the nan (no results) in I'm mostly limited by the androidplot library that I use for graps. For the line graphs it will treat null as 0 an draw an ugly line to the bottom.
I just start experimenting with the server api to get the historic data.
The local API not only provides time series data for the analog (clamp) ports (for which we can calculate a power entry every second) but does so for the pulse ports as well. And since we can only calculate real-time readings between two pulses, we have to insert nan's between the most recent pulse and 'now'. So for a pulse port, there typically will be multiple nan's present at the end of the time series on the local API. So again, you will need to be able to cope with these pesky nan's.
I took a quick look at the androidplot lib. Could you tell me what chart type you're using? A scatter chart _should_ be able to deal with missing data points in a time series, especially at the beginning or end. A line chart will typically not allow this. So by literally connecting the dots in a scatter chart you should be able to get a line without having to assign zeros to non-existent data points.