Device Status Tiles

temperature
device_health
light
tiles
power

#178

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.


#179

Is there a way to change the background color of WebCore?

Is there a way to link directly to one of the WebCore instances (URL to my webcore tiles instance)?


#180

I use a plugin for Firefox called Stylish to achieve this:

temp

(it also let me reduce the wasted space so I can see more data at once)

Here is the Stylish code to change the background color:

temp


Yes, each piston has a unique URL, and can be called in numerous ways. Full writeup here.


#181

Found the a set of $weather tiles and modified them for $twcweather.
Here’s the result:



#182

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)


#183

Oh yes, you are right. One possible workaround is to use two different browsers, each remembering (and loading) a different instance


#184

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?


#185

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)


#186

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.


#187

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:


Weather tile not importing
#188

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


Turn off bug zapper if it might rain
#189

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.


#190

@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.


#191

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?


#192

in the webcore dashboard, the piston needs to be put into a category that allows/displays tiles.

The piston itself needs to issue set tile xxxx commands


#193

Whoa. Would you look at that! I would have never found that in a million years. Now I need to figure out how to get them into ActionTiles.

This is one hell of a learning curve, although I have to admit, it’s fun.


#194

Hey,

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.


#195

You can’t get them into Action Tiles but you can create a tile in AT. It will be a “generic” tile that will only only show Present or Not Present.


#196

If that’s the case, what do people use the device status tiles for in webCoRe?


#197

Here are a few examples from the Wiki.

Here are a few examples from this forum.