Yes, this will happen because the initial value of the @CurrentSunriseTimeStamp and @CurrentSunsetTimeStamp numbers is 'zero' and the string values are "" until the Webparser finishes getting the valid timestamp data.
The error message will appear once every time the skin is loaded or refreshed.
The way to avoid the error is to have the measures that use TimeStamp values initially set to Disabled=1 and then enable them when the Webparser finishes.
Thankfully, the WeatherComJSONMeasures.inc file(s) provided by JSMorley have FinishAction=[!EnableMeasureGroup "Times"] in the code already.
All you need to do is to set those measure as belonging to the 'Times' group, Group=Times and have them disabled initially, Disabled=1.
eclectic-tech wrote: ↑August 28th, 2020, 9:53 pm
Yes, this will happen because the initial value of the @CurrentSunriseTimeStamp and @CurrentSunsetTimeStamp numbers is 'zero' and the string values are "" until the Webparser finishes getting the valid timestamp data.
The error message will appear once every time the skin is loaded or refreshed.
All you need to do is to set those measure as belonging to the 'Times' group, Group=Times and have them disabled initially, Disabled=1.
Yes, I noticed that it does not continue, but only on the refresh. That does not concern me, given your explanation, I am not worried about it being there once.
There are many ways to be different - there is only one way to be yourself - be amazing at it
The law of averages says what it means; even if you get everything right, you will get something wrong. Therefore; self managing error trapping initiates another set of averages - amongst the errors, some of them will not be errors, instead those instances will appear to be "luck". One cannot complain of the 'appearance' of 'infinite regress of causation', even if it does not have a predictable pattern, only that it requires luck to achieve.
