Invalid weather reported as 0 degrees

#1

The new weather is occasionally (up to a couple times a day) reporting the outdoor temperature as 0 degrees. I assume this indicates an invalid reading for some reason. The old weather service would occasionally report invalid data though this was reported as blank strings. I’ve written code to work around these issues but it would be nice if weather was available more reliably and there was some reliable way to know (e.g. the blank string reported by the previous weather service) when data was invalid or unavailable.

#2

Not sure if this helps…from webcore weather wiki

Preliminary testing shows that today’s morning/daytime data [0] turns null shortly after 3PM each day, and the next day’s data shifts to [0] and [1] shortly after 3AM. This means from approximately 3PM to 3AM, you will find [0] to be null, and [1] will show data from the evening/night in progress. This also means that at about 3AM, the data for the night in progress vanishes, and is replaced with data for the following day/night.

#3

If you are polling:
$twcweather.forecast.daypart[0].temperature[0]
then it will be null from approx 3:05pm until 3:15am every day

Alternatively, if you are polling:
$twcweather.conditions.temperature
it should always show the current temperature
(unless the service is temporarily down)

Side Note:
If you are storing the temp into an integer variable, then null will appear as 0

#4

PS. I moved this thread out of the “bugs” category since webCoRE has absolutely no control over what $twcweather reports

#5

I am polling $twcweather.conditions.temperature and assigning it to a string variable and checking for empty string before converting to decimal. I never see an empty string with the new weather service, I see “0” instead.

So, apparently the weather service (or something between here and there) is regularly down temporarily. This does wreak havoc on pistons that trigger when the temperature goes above or below a threshold (e.g. freeze warnings). Even if the problem is with the weather service, it would be nice if webCoRE somehow presented a more usable temperature reading. I’m happy to share the workaround code I’ve written.

#6

With WUnderground, I used to poll every 30 minutes, and if the temp dropped more than 12 degrees since the last poll, my piston would assume it was bad data, and fall back on the previous temp until the next cycle.

We’d love to see the path you took for TWC.

#7

image
image.png1178×802 45 KB

This is my polling routine and has pieces of the old code that watch for an empty string and now the new workaround that has special handling when a temperature of 0 is reported.

Polled temperature is made available via a simulated thermometer device and the @Outdoor_temperature variable.

#8

Thank you for sharing!

I know we are in the TWC testing phase, but in the long run, I have a hunch that the more often we pound the TWC server, the more frequently we will all see bad data returned.

If I was being completely honest, I would say I am very unimpressed with the frequency of updates (and accuracy) of the new weather data.

My two cents?

  • You will get just as accurate temps if you query every 20-30 minutes
  • You can cut your queries in half by changing line 28 to {otempraw} instead of $twcweather… I might even go as far to guess that this is the reason you are seeing so much bad data. (Two identical queries within 10 milliseconds)

On mine, I take it a step farther so it only makes the query while I am awake

#9

I have looked at polling results and we do get updated information at least every 10 minutes so 5 minute polling does not seem unreasonable. I use temperature changes to control stuff and send me alerts so better responsiveness is actually useful.

My understanding of WebCoRE is that a snapshot of the environment is taken before a piston runs and remains constant during the run so it is the running of this piston, not the referencing of variables that results in a TWC load. But I assume you would know better than I and I thank you for the suggestion. I will make the change and see if it makes a difference.

#10

This is good to know. Thanks for sharing! I have been focusing on the $twcweather.forecast lately, and for the most part, the numbers often remain the same for the entire 12 hour time slot.