$weather questions/issues

[ependergrass]

1) Give a description of the problem
I have a piston that is supposed to turn on a pipe heater when the temperature is below freezing, however it has been turning it on at random when I am using the condition $weather.conditions.current_observation.temp_f < 32.

2) What is the expected behavior?
I am expecting that $weather.conditions.current_observation.temp_f always returns a value

3) What is happening/not happening?
It seems that sometimes $weather.conditions.current_observation.temp_f returns a null value, and that when it does, checking it is <32 results in a TRUE result.

– I tried pulling $weather.conditions.current_observation.temp_f into a local variable to see if that was a problem, that didn’t help. So I thought alright… maybe it is a fluke, so in case $weather.conditions.current_observation.temp_f < 32, I actually check it again (set the variable again and check) so that I can be sure it’s really <32. Yet several times it has still made it through!

I am changing my comparison to check the variable is between -100 and 32, and hoping that will work. But clearly what is happening is there is no reading returned sometimes so it just returns a null.

Is this due to there just being inconsistent data available from certain weather sources? Could there be some sort of default setting to pull the last known good value for the current conditions/temperature in case a current one can’t be found so that null is never returned? Or is it up to us to buffer that value?

I think that $weather is super useful and maybe all this has been fixed in newer releases (I am a few behind) but am curious if anyone else has run into this, and if I should really expect a null to evaluate as <32 (and if using BETWEEN might fix it!)

Cheers!

Eric

[WCmore]

Every 30 minutes (for a few months now) I have been tracking the same weather condition:
$weather.conditions.current_observation.temp_f
and about 4-6 times a week it returns a bad number. Not null, but an incorrect decimal.

It used to spike 20-40 degrees in 30 minutes (which ruined the looks) in my fuel stream. Now, I have coded a safety net where each time it is run, it checks the number against the previous number. If it is beyond a certain threshold, then it uses the old data that time around. I programmed a “tiny spike” (4 degrees) in to my fuel stream, so I can still tell how often it is happening. (see pic below)

(This pic shows it happening 5 times this past week)

The occasional bad numbers coming back were often a 20-40 degree drop in 30 minutes, which is highly unlikely for my location. I made my threshold something like any change over 15 degrees, we can assume that the data is incorrect, and to use the old data instead.

On the subsequent piston runs, it always returns the right data. This is just my loophole to keep my data (fairly) accurate, even when WUnderground returns the occasional bad number.

[WCmore]

In other words, if it runs on a timer, you can program your piston to only turn on the heater

IF
currentTemp is in the range of (previousTemp - 15) and (previousTemp + 15)
-AND-
currentTemp is less than 32

The two 15’s above may need to be adjusted for your climate

Your last command in that piston could be something like:
Set variable {currentTemp} = {previousTemp}
which prepares the piston for the next run

[WCmore]

A lazy solution would be to have the temperature check run periodically (maybe every 30 min), and require TWO sequential runs, with both below 32 degrees… and THEN turn on your heater. (I have never seen bad numbers twice in a row using my 30 minute repeat).

You could also cut network traffic in the summertime, by also programming your piston to never run in months 4-10 (or whatever months are warm in your location). No need for the piston to be running if there is no possibility of your pipes freezing.

[ependergrass]

Thanks! I was wondering if anyone else saw the weird inconsistencies. I thought maybe double-checking it instantly would work, but I guess it makes sense that if it fails at once instant it would likely fail an instant later. I will have to check the previous temp 30 minutes ago for my buffer… that oughta do the trick! If both are beneath my threshold then I will activate.

I do wish that the bad data could be filtered out somewhere upstream though!

[WCmore]

That’s a good question… I have never tried:

check weather
wait 10 seconds
check weather again
compare

It would likely require a fuel stream to test though, since (for me) it only returns bad data about 1% of the time.

[WCmore]

Now that I think about it, I also occasionally get bad data from my moon query (pulled from timeanddate.com), so maybe it is a webCoRE issue, and not limited to just WUnderground…

(I haven’t made a safety net for this one yet)