Recover data from Israel

[majesticio]

Adapter upgraded, and updated to use new data URL.

Adds data from ~182 stations.

[caparker]

Lets filter the data down a little, or maybe there is a timestamp error somewhere. But this is what I got the first time I ran it

182 locations from 2019-01-01T08:55:00.000Z - 2024-04-04T23:50:00.000Z | 
Parameters for israel-envista {
"co":{"count":16,"errors":3,"max":1,"min":0,"nulls":0},
"no":{"count":164,"errors":0,"max":0.7908,"min":-9.999,"nulls":0},
"no2":{"count":165,"errors":0,"max":0.0456,"min":-9.999,"nulls":0},
"nox":{"count":165,"errors":0,"max":0.7958999999999999,"min":-9.999,"nulls":0},
"o3":{"count":88,"errors":0,"max":0.1971,"min":-9.999,"nulls":0},
"pm10":{"count":62,"errors":5,"max":263,"min":0,"nulls":0},
"pm25":{"count":112,"errors":4,"max":95,"min":0,"nulls":0},
"so2":{"count":107,"errors":0,"max":9.999,"min":-9.999,"nulls":0}}

Notice the min timestamp is in 2019? How about we make it default to the past 6hrs or something like that.

And then notice the various -9.999 and 9.999's ? Could you find out if those are values that are starting out as -9999 and 9999 and then going through our units converter (divided by 1000)? If they are we need to make sure they are not converted because if they are submitted as 9.9 and -9.9 I think our system will treat them as real values and not error codes. If they are not being divided we will need to figure out another way to deal with them.

[majesticio]

I have added updates to unifyMeasurementUnits that will ignore values of -9999 or 9999 and them pass them along, as these are known error codes, and dividing them by 1000 for example to convert ppb to ppm will create values like -9.999 which may be treated as a measurement rather than an error

[majesticio]

The API provides latest measurements every 5 minutes. The adapter has been updated to reflect this, and I am updating the docs as well.