Device Status Tiles

temperature
device_health
light
tiles
power
#168

I am pretty sure that all you need to do is delete the following text from your piston:

’ ‘"{format(’%.0f’, decimal([$currentEventDevice:humidity]))}%"

That should totally remove any tile display of humidity. Just pay extra attention when you do this. It is very easy to unintentionally delete the wrong section. (It starts with a single quote and a space, and it ends with a percent sign and a double quote)

To answer your coding question in laymans terms:
If humidity is greater than 0, then do blah blah blah…
If local variable is ‘true’ then do blah blah blah…
If it is not "true’ then do what is on the other side of the space colon space ( : )

Or if this helps to visualize:
( H ? T : F )
If H is true, then do T, otherwise, do F

The section you are removing is the last part of the ‘false’ statement.

#169

Thanks, very helpful. That is exactly what I needed. Appreciate the prompt response. It’s been working for a few days now.

#170

Hi,
I am looking for a tile that can have a date and time on it any ideas

#171

Here is one of my tiles:
temp - or - temp - or - temp

Using this code:

temp2
temp2.jpg889×79 22.9 KB

My footer tells me how today’s temp compares to the average historical data for this day… (A great way to see if we are experiencing a warm front or a cold front) Of course, you could easily change the footer to $time. Just be aware that it only updates when the piston is run, so the time will always be a bit off unless you run it every minute. (Not recommended)

#173

I’m bumping this since the NullPointerException error still occurs with the Light Bulb and Light Switch Status Tiles. I was scratching my head but another topic with the same error actually gave me a clue to the solution of the error problem. I’m reproducing it here for those who want to fix it.

To define the problem first, the NullPointerException error occurs because the currentEventAttribute is not ‘tile’, it’s something coming from another device and so the variable TilePressDeviceID comes up out of bounds and you get the error. The fix is actually simple, check that currentEventAttribute is ‘tile’ before the check for a tile press and you’re good to go.

Take this part:
BadCode

and change it to this:
NoError

Since only tile presses are recognized, the error is gone.

Edit: the same error occurs in the Door Lock Status Tiles piston and the fix is similar.

Here’s the error causing code:
BadLockCode

And with the check:
NoLockError

I set up the currentEventAttribute check If statements then used the drag and drop feature to move the original tilePressDeviceID code inside. Nice and easy.

#174

Oh boy! You might have just solved for my one primary reason for sort of letting webcore dashboard tiles to age and not really finish the deployment I wanted. Well this is layered dashboards such that I could drill into secondary ones from a top dashboard… However the tilePressDeviceID was a big stumbling block. So much for getting outside this weekend. Looks like I’ll be back at webcore dashboards! :slight_smile:

#175

Yeah, getting the error (especially on a piston that’s supposed to be an example) is kind of off-putting. I got a clue from another thread and after over-thinking things a bit (and trying some things that didn’t work), I posted in the Piston: Design Help section for help with a good description of what the problem actually was (which can make all the difference in getting to a solution) but before I got a reply there I got back to basics and KISS principle and sorted it out finally. Since I hadn’t been able to find any explanation or solution anywhere else, I felt I should post my result here for the benefit of the community. I’m happy you found it useful.

Sorry about your weekend, it’s getting chilly here so I wouldn’t want to get out too much but you can sort of manage with a tablet outside too. :wink: I only just started with WebCoRE and while the dashboard is a bit basic, it’s great! I’ve been spending way too much time setting up a dashboard (two versions, one for tablets with all size tiles and one for phones with just small tiles). Happy coding! Here’s my mobile dashboard for possible motivational value:

Dashboard%20Phone%20Flavor
Dashboard Phone Flavor.jpg631×886 260 KB

And the Tablet one:

Dashboard%20Tablet%20Flavor
Dashboard Tablet Flavor.jpg1025×878 365 KB

Edits: Add Tablet version, update images showing different state for some tiles.

#176

First of all. Thanks more than I can really say for all the work that’s gone into this and for the results. This appears to be exactly what I wanted.
The one embarrassing caveat: Apparently, I’m such a noob at webCoRE that I wasn’t sure how to actually view these tiles.
I figured it out, though: how to enable tile view for pistons

#177

I’ve looked through and I can’t seem to find the Tile Pistons for Weather. Any help?

#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:

weather%20status%20tiles
weather status tiles.png1178×944 117 KB

Weather%20Status%20Tiles
Weather Status Tiles.jpg1342×555 92.4 KB

#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:

weather%20status%20tiles%20code
weather status tiles code.png1178×926 124 KB

weather%20status%20tiles%20pic
weather status tiles pic.jpg1333×517 102 KB

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%20tiles-better%20timing
weather tiles-better timing.png1178×875 122 KB

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