I’m trying to figure out how to use the weather in a piston. I want to turn some lights on earlier if it’s not sunny out. I’ve looked other the weather page at https://wiki.webcore.co/Weather, but can’t figure out how to incorporate it in to the piston.
I see:
$weather.conditions.current_observation.weather
returns the current conditions. How do I add that? I see weather under variable… it says null next to it. Also how can I figure out what the possible conditions are?
New to webcore, thanks to all the people who help and developers.
Do you have a weather station device configured yet? If not try adding the Smart Weather Station Tile 2.0 device handler and then add a device using this handler:
I personally think the $weather is much nicer to use, no need to have another device on your ST. Only thing missing is Illuminance level which something like the Weather Station Tile can give you that the $weather variable doesn’t have.
I’ll look to post my weather alert pistons I have at some point the next few days as well.
Is there a list somewhere of the possible results you can get using the “$weather.conditions.current_observation.weather” variable?
I am working on a script for my home to automate the blinds based on internal temperature, external temperature and the conditions outside. For example if it was hot outside, but not sunny I would keep the blinds open but hot and sunny I would like to close them. And vice versa in the winter. The temperatures I am having no problem with but not knowing what the possible responses I can get for that variable is preventing me from using it at the moment.
I might also recommend the Accu-Weather plugin for webCoRE since that lets you query the cloud coverage into a number from 0 - 100. (It is much easier to code with numbers than words)
You can test this plugin by loading the ST app on your phone, and going to:
Market Place > Smart Apps > Climate Control > AccuWeather Connect
That’s great news. Thanks for that. Just to confirm what is the number in square brackets indicating? EDIT: Reading on mobile I didn’t see your explanation but now that I’m on my laptop I see the full post.
If my script is to check at regular intervals after 12:30pm (sun reaches the back of my home at this point) and I want to close the blinds if it is sunny would it be basically:
If $weather.hourly.hourly_forecast.sky[0] is less than or equal to 60?
I’ll have to experiment with the numbers to get a feel for the actual value to check against but I am assuming the higher the value the more cloud coverage there is.
The ‘sky’ parameters was found by accident two days ago, so it is all speculation at this point, but you might be right. I will be paying attention to the output before using that code in any of my pistons.
If someone can confirm these numbers, please share your findings here.
If you find out any more I’d appreciate if you can share.
I was only able to do a quick test upon seeing your post and found the output at the time was 22. Upon looking outside the coverage was fairly low which is why I assumed how it works. Hopefully we get some confirmation sooner than later. I guess for now I will keep my eye on it but not officially start using it in script.
In the meantime, I can say that the AccuWeather built in cloud coverage is quite accurate… The half dozen times I have randomly compared the two numbers they were between 30-50 points difference. This is why I have not used the ‘sky’ code yet in my pistons.
I have started an analysis running every ten minutes comparing AccuWeather’s cloud coverage to WUnderground’s ‘sky’ number. I will report back here in about 24 hours with my findings
*PROS (BLUE) WUNDERGROUND:* | *PROS (RED) ACCUWEATHER:*
Updates more frequently | No False reads
―――――――――――――――――――――――――――――|―――――――――――――――――――――――――――――
*CONS (BLUE) WUNDERGROUND:* | *CONS (RED) ACCUWEATHER:*
Many false data reads at 0 | Less frequent updates
| More 'blocky' data
Side note… The 4 times I went outside happened to be when the two data points were fairly close to each other… so I cannot speak on accuracy yet… It does seem like both data points are trying to convey the same trends though…
That’s a great post! Thanks for putting in the effort to log and share your findings. It’s tough to say which route to go at this point. I like the idea of less devices and more updates by weather underground but the more frequent 0’s is tough as well.
Yes, I agree. Also be aware that WUnderground has also warned us that they plan to pull all free API calls… (not sure if that affects us webCoRE users though or not, but I would venture to guess that it will)
If you decide to go the WUnderground route, here is my strategy to bypass the incorrect data points.
Check out weather underground api documentation pages. It gives all the weather options tgat you can use. You just don’t need the api address and key, tgat is substituted by $weather
