The code for the weather changed drastically a few weeks ago… I’m not sure how many updated pistons have been released publicly yet… (I am still tweaking mine)
In the meantime, there are lots of tiled pistons out there that are using the old weather data from Wunderground… Any one of us can download and edit those to line up with the new $twcweather parameters.
Thank you for the info, I am looking for the link to the dashboard… when I have 2 dashboards. I have a Pistons dashboard (most is here) and a Tiles dashboard (trying to make a pure dashboard without numerous piston details ). If you link to your dashboard, it seems to remember which instance used last and loads it. No way to link specifically to either (that I can find)
In digging into twcweather a bit more, I discovered that .forecast goes a full 16 days, so I’ve updated the tiles piston to show all of them. Second, I didn’t like the “after time” no information in the first position so I replaced it always with the current condition data. Here’s the updated piston:
I do notice that the piston doesn’t do anything until after 10 minutes. (The do every 10 minutes waits 10 minutes before the first run.) Is there any way to get a piston to run once right after it’s been updated and then go to a scheduled update?
I hope I am not out of line by saying this, but I would highly encourage you to lower the frequency greatly… Most of the “$twcweather.forecast” data only updates twice a day, but with your current piston at every 10 minutes, you are actually pulling nearly 600 data points each hour!?!
(6 x 15 + 5 = 95 every time the piston runs, or 14 thousand per day in this single piston)
If it were me, I would limit this to (at most) once per hour… (2k per day)
But really, with the stagnate data, every 2 or 3 hours is probably better. (760 per day) (I might even add a block so it does not run when I am asleep)
If I were being totally honest, I might cheat a bit and put the first tile ("$twcweather.conditions") into a separate piston running a bit more frequently (every 30 min?)… but most of the other 15 tiles will not change throughout the day, so why pound their server with needless requests?
(I suspect this was a big factor in why WUnderground stopped their free weather service earlier this year)
What I do sometimes in my early debugging phase is drag the “FOR” block outside of the “every X minutes” block. This way I can just press TEST to see nearly instant results. (a tile update may take up to 8 seconds) Once I am happy with the results, I drag the “FOR” block back inside the “EVERY” to return to the schedule.
Thanks. Both those responses are quite helpful.
…
Much better. I set the forecast tiles to update every 12 hours. (I could probably even go to 24.) and the current tile to every hour.
Is it necessary to put it into a separate piston or just put it into a separate Every…?
Here’s the latest version with the better timing:
You are right. It can definitely be in the same piston.
The one part that needs a bit of thought is that $twcweather changes the daily data sometime between 3AM and 3:35AM. I am tempted to make my piston grab the daily forecast at about 4AM.
For others making a similar piston, keep in mind that the [0] (not used above) is only valid from about 3:30AM to 3PM, and then turns to null
Right. I’m thinking the same thing about getting daily data.
On [0] thing, I had some coding in the original piston to work the the 3 pm problem with [0], but I decided that using the current forecast instead just avoids that issue entirely. I do notice that, at times the current and today forecast are subtly different. You could have both, but keep in mind the second comment above about valid times.
@MajorEvent is the man. Circling back on this old topic because the bug is still in the sample tiles for Lights and Switches (probably others). I spent about 3+ hours trying to track this down because my wife said the bedroom lights kept coming on, but I wasn’t touching those tiles. This is a pretty insidious bug because it is using the zero-based index of the device array to turn bulbs on and off. When it’s responding to a “tile” event, it’s not a problem, but for switch events, routines, buttons, and other things that can trigger this piston, it’s a big problem. Most of the time you just get the Java exception because it’s using an invalid index for the Bulb array. But sometimes, the event comes with a perfectly valid index for Bulb such as Level 1-n brightness (where n is 16 or less), which we use all the time in the late evening. Every time I would change a light to 1%, 2%, etc, my bedroom lights would turn on and off. Simple fix, to add a check for
{$currentEventAttribute} is 'tile'
You might also use a log statement like this to figure out what the hell is going on:
do Log info "{"type:" $currentEventAttribute " v:" $currentEventValue " device:" tilePressDeviceID"
Nothing against the great efforts here, because I love webCoRE, generally like hacking/coding, and really like effective home automation, but Jesus H. W. Christ. This wasted a whole lot of my time this evening.
Hoping to save someone from this coding horror when they think it’s going to take 20 minutes to add a few tiles, and they end up staying up until 4am chasing a ghost.
I’m going to ask what’s probably the dumbest question in this thread. I found the wiki on Device tiles, was able to install a second webCoRE instance for the tiles and imported one that I liked for Presence Sensors. I edited the variables it prompted me to edit, but how to I actually view the tile?
I am trying to get the presence tile piston working that you posted code for about 18 months ago. I only have one sensor on there right now, its a smartphone and it updates correctly in ST app but for some reason the tile never updates and the piston seems to not get any updates from the device. I have it posted Presence Tiles Code Seems To Work But Tile Still Says No Event
If you or someone who sees this could take a look it would be appreciated.