UGH! So is there a more reliable source? I bought the thermostats and wrote the pistons to save propane and electricity. Not to have them kick on and run up to 70* in side when it’s 70 plus outside. It was comfortable at 66ish and then it got hot… GRRRRRRR.
Fuel Streams not loading at all
WCmore
#27
I often query WUndergound every 20 minutes, so 3 bad data pulls a month is a 99.7% success rate. (which, to be fair, is not bad for a free service)
That being said, you could pull data less frequently than every 5 minutes, and put in some code to ignore numbers below X and above Y.
A more complex version that I use sometimes is, I compare the recent data pull to the previous data pull, and if it has dropped/risen more than Z degrees, to ignore the bad data.
Here is two brief posts showing that in a bit more detail.
chop249
#28
Thanks! Fuel streams are up but again empty. I haven’t used them before so my knowledge on them is limited. Here is what I have being written and then what is showing.
Lolo
#29
Fuel streams can only display numerical value (no string). Write 0 for cool and 1 for heat or something similar.
WCmore
#30
You can also do something like:
-1 = Heat
0 = Off
1 = Cool
It looks great when the Fuel Streams are working
Lolo
#31
And do not use the same fuel streams variable or container as the original one is contaminated with incorrect data and steams can not be deleted.
WCmore
#32
@Lolo is right. It takes 7 days for a corrupt fuel stream to clear the old bad data, and to be re-usable again.
WCmore
#33
Just a heads up @chop249, you will definitely get false alarms with that last piston you posted. If you are running it every 5 minutes, you can expect about 15-20 false readings each month. (using my 99.7% average)
chop249
#34
So from the Global Variable OutdoorTemp how do I write the recorded temp to a Fuel Stream so I can see what it is pulling without looking every 20 minutes ( I changed it)?
Robin
#36
On events from temperature device’s temperateure
With location
Write to fuel stream temperatures device’s temperature.
End with
End on event
WCmore
#38
Both methods work @GRClark.
I often use:
Every 20 minutes
With location
Write to fuel stream temperatures device’s temperature.
End with
End Every
Just please do not go crazy with really short loops. Someone has to pay for that server we are all using, and it’s better if we don’t abuse that.
For reference, every 30 minutes still gives me all the info I need:
It is also important to note that the more often a number gets written to it’s fuel stream, the longer it will take for that graph to load when you want to see it.
GRClark
#39
I’ve been doing them every hour. Wonder which works better though - hourly or on events.
WCmore
#40
I think “on events” will end up writing to the fuel stream more often when using outdoor temps… Using indoor temps is debatable. Mine rises and drops about 1 or 1.5 degrees each time the AC cycles.
Robin
#41
Actually… I retract my ‘on events’ method recommended above… I use that method a lot for things like logging lights, but as @WCmore notes, temperature events could certainly result in fairly heavy server demands if your device is very active.
Timers are the way to go for that use case
chop249
#42
Thanks all. Fuel Streams have been up and running for me for at least the last 24 hours. I think I got the streams set up the way I want them. I am using them to look over the data to see when or if there was a “malfunction” in the pistons due to either the “get” on the temperature or what. I’m hoping I can save some dollars, euros, yen, or whatever with the programming I have. I may delve deeper once I’m comfortable this current set up is reliable and adjust the indoor temps based on outdoor temps even more.
Robin
#44
source: $name (piston that pushed the data)
The reason for source is… you can push data to the same stream from multiple pistons in multiple instances in multiple locations.