Weather Question


#7

No spaces:


#8

Thanks! The wiki has been updated


#9

Ha! I already got a new one: “Rain Shower/Wind”

I will try to start keeping a list of any new ones I see, and give them to you in a group, instead of one by one.


#10

Excellent!

Give me a few hours, and I will create a new thread for contributions for all of the weather data. Anyone can add to it for any datapoint they discover, and I will keep the wiki updated with all of the new information. (this is kind of wise because there will likely never be snow in my location, so I’d need contributions from a northerner to include those conditions as well)


#11

Sounds great!

I will be happy to contribute to this, as this is a great benefit.


#12

A new thread has been created for undocumented datapoints.

Thank you all in advance for any contributions!!


#13

Yes!! I figured it out!! So, this is why I was originally asking about the ‘wxPhraseLong’.

Right now, I have IFTTT with WeatherUnderground turning Virtual Switches on/off…‘Weather Clear’; ‘Weather Cloudy’; ‘Weather Rain’; and ‘Weather Snow’. Webcore will then turn certain lights from 0%, 10%, 50% depending on the switch that turned on.

IFTTT has been slow to report, and sometimes it will have been raining for 30 minutes already when the ‘Weather Rain’ finally kicks on.

So, I’ve been testing Webcore with the $twcweather… and I finally got some results.

Of course, this is just a test, but opens up so many possibilities.

I have another piston that is updating the variables.

Loving this!! And, it’s more accurate than with IFTTT and WeatherUnderground.

I will eventually have all of the outcomes of ‘wxPhraseLong’ added to 4 categories: Clear, Cloudy, Rain, Snow.

I will also be testing the Weather Alerts.


#14

Oh…and ‘Showers in Vicinity’ is another that I haven’t added to the other thread just yet. I was hoping for a few more before posting.


#15

Typo’s in "Test Auto Weather, string dfRain, “Light Rian”


#16

Thank you!! It is fixed!


#17

Question: I’m working on my Weather Alert piston. Right now, it sends an SMS to my phone when the $twcweather.alerts[0].eventDescription changes. But, it sends an SMS when an alert is activated, and then another ‘blank’ one when the alert goes away.

How do you tell webcore: When ‘variable’ changes away from ‘null’ ??

How do I tell it ‘null’ ? No matter what I do, it’s not working. If I leave it blank, nothing…if I type ‘null’, nothing…

How do you set the ‘changes away from “null”’? What do I type as the value?


#18

Here is a snippet from my old WUnderground code:

temp

Then do a bunch of stuff…
and the last line of code is:

temp


This piston will alert me on any changes, except for when it changes to null…

Notice the peculiar NOT in the IF section.
This is because there is no choice for: “is not equal to


#19

So here’s what I did, and it worked.

I defined a string at the start of the piston, “wCheck” and left it blank.

Then in an IF, I said IF ‘$twcweather.alerts[0].eventDescription’ is equal to ‘wCheck’, then set this variable to “NULL”.

Now, I can use that in the piston I mentioned above, and say: IF this variable changes away from “NULL”.

So cool the way you can work things out by playing around.


#20

Here’s what I’m doing:

The first piston captures the weather attributes.

The second piston uses those attributes to send SMS messages.


#21

Nice work, @dejavux2!

The only thing that bugs me a bit about piston “k087” is you are making 15 hits to the weather server to gather 7 data points…

The way I do it is to store the $twcweather into local variables, and then the rest of the piston only references those variables, instead of spamming the server a few milliseconds later for the same query. (globals are still ok to be set towards the end)

For example:

Set variable temp = $twcweather.conditions.temperature
Log info "Temp is {temp}"
Set variable @globalTemp = {temp}

Just my two cents.


#22

Good point… I will have it log the variables, instead of hitting $twcweather again.

Thanks!


#23

Weelll…

It will not successfully log using a GLOBAL because a global will not be updated until the last line of code is completed. Using locals are the only way around that


#24

Updated:


#25

Well done!!

This is a great example of how a more complex code can often streamline the execution. So often, people make the code in a way that is pleasing to the eye, without any regards to the way it processes later…


#26

If you prefer symmetry in your code, the above can be made to look “pretty”… but…
It’s important to note that the change below does not impact the execution in any way.
(it’s purely visual)

Set variable temp = $twcweather.conditions.temperature
Set variable wind = $twcweather.conditions.windSpeed
Set variable phrase = $twcweather.conditions.wxPhraseLong
Log info "Temp is {temp}"
Log info "Wind is {wind}"
Log info "Phrase is {phrase}"
Set variable @globalTemp = {temp}
Set variable @globalWind = {wind}
Set variable @globalPhrase = {phrase}

This variation means that changes to a variable is in three different “paragraphs”, but for me, it is actually easier to see the flow of code and catch any errors if there are any.

Your mileage may vary…