Device Status Tiles



I use it for both fans and as a light dimmer switch. For fans, it sets them to one of three speeds; for lights, I run a piston that checks a group of lights one by one, and if they are turned on it sets their level to the value of the dimmer.

I had tiles set up on the old SmartTiles that work great. Basically just a slider under the icon.

(I changed some device names and never updated the tiles, so some of the icons are wonky. But you get the idea :slight_smile: )



Brad… is there a way to speed up the updating of the tiles? When I click one, the actual device action is fine…lights, etc. change states almost immediately as they should. But, the clicked tile takes FOREVER to change state. In fact, sometimes they don’t change at all.

If I understand the code, the tile state should be changing first, and then the device gets toggled ( via the tilePressDeviceID toggle action).

Are there any execution policies or other piston settings that should be set? I have a pretty firm grasp on the piston code structure, but not all the settings for how they execute.



The tiles aren’t designed to be instant on webCoRE, visors are supposed to be more instant than the tiles would be once they are finished which @ady624 mentioned to be working on this year: Dashboard.webcore requests

That said, they usually refresh with 10 to 15 seconds for me on Chrome on my desktop but seem to take a little longer on Chrome on my phone.

tilePressDeviceID coding is only there to toggle the device when the tile is clicked on, it’s not used for updating the tiles.

I can make a Device tile for a Ceiling Fan switch like you have showing and see if I can find a fan icon similar to that. You mentioned 3 speeds for your fans, what level would it be for it to set low/medium/high or would it just display the level value instead of displaying low/medium/high? SmartTile has that slider on the bottom but that’s not an option on webCoRE though currently, maybe @ady624 can add that to the visors when they are done :slight_smile:

FYI, I’m just about done with updates to all of the Device Status Tiles on the first post, doing some further refinements and optimizations. I would love to have different styles as well as far as the look of the tiles since I’m digging the dark theme that you posted above but the icons are limited to Font Awesome or Emojis so I’m limited on the icons that can be used.


Here is what my latest dashboard looks like using webCoRE. It’s very much a work in progress. :slight_smile:

I’ve modified them to have different colors for the icons vs the background text, and to have gradient icons (battery, temp, and humidity) based on reported sensor values. I prefer the tile background and secondary text to remain constant, with only the icons or central info changing color in response to actions or values. Just looks cleaner to me than a whole tile changing.

Right now they have colorful backgrounds, which helps me identify each piston. Once I’m happy with it, I’ll probably change most of them to black. (I may leave the mode icons something slightly different… I dunno)


Those definitely look nice, my thoughts was having a light and dark themes that the user can select on the variables section and also allowing the user to have a custom theme to allow someone to modify the Text field (add text or icons like FA/Emojis), colors for the text and tile background colors. It’ll take some work to finish, my goal is for it to be as simple as possible for someone that is just starting out with webCoRE or allow for someone to customize as much as they like for their own needs but it’ll take a bit to get that part done with the themes. I’ll look to update the tiles though over next few days as I have time with updates that I’m finishing but won’t include themes yet.

Also releasing my Presence Sensor Device Tiles too shortly.


I’m using global variables: @TileDimmedText, @TileBrightText, @TileDimmedIcon, @TileBrightIcon, and @TileBulbOnColor. Those variables are then used in expressions that set the tileTextOn and tileTextOff variables at the top of each piston. By changing one global variable, I can change the text or icon color across all tiles. (poor man’s CSS :smiley: )


For the gradient battery and thermometer icons, I set a color variable using a rainbow color assignment once the device value is known, assign the FA string with a switch statement (fa-battery-0, fa-battery-1, etc) , and then concatenate those into the tileTextOn variable.


Thanks for the ideas, I’ll look into that once I start the theming portion.


Here is my modified temperature tile, using different icons and colors for the temp. You’ll just need to add @TileDimmedText for the tile text color, or hardcode it into the “Set piston tile…” statement.

Note that I took the “F” out of the display to give a little more room for the icons. Don’t need no stinkin’ celsius in Oklahoma. :stuck_out_tongue:

Also, you could probably use an expression to determine the last character of the fa thermometer name, which would simplify the code a lot…but using a switch statement is more flexible.


The switches work great like you have above, I’ve also used a variable with an expression using ternary operators that might work too just to show you another way to do the same thing.

Example from my Weather Status Tiles for the High Temp, it’ll make the tile background a certain color based on the temperature:

(decimal({$weather.forecast.forecast.simpleforecast.forecastday[0].high.fahrenheit}) >= 100 ? 'Maroon' :
(decimal({$weather.forecast.forecast.simpleforecast.forecastday[0].high.fahrenheit}) >= 90 ? 'Red' :
(decimal({$weather.forecast.forecast.simpleforecast.forecastday[0].high.fahrenheit}) >= 85 ? 'Dark Orange' : 
(decimal({$weather.forecast.forecast.simpleforecast.forecastday[0].high.fahrenheit}) >= 80 ? 'Orange' : 
(decimal({$weather.forecast.forecast.simpleforecast.forecastday[0].high.fahrenheit}) >= 70 ? 'Gray' : 
(decimal({$weather.forecast.forecast.simpleforecast.forecastday[0].high.fahrenheit}) >= 60 ? 'Dark Sean Green' :
(decimal({$weather.forecast.forecast.simpleforecast.forecastday[0].high.fahrenheit}) >= 50 ? 'Powder Blue' :
(decimal({$weather.forecast.forecast.simpleforecast.forecastday[0].high.fahrenheit}) >= 40 ? 'Light Sky Blue' :
(decimal({$weather.forecast.forecast.simpleforecast.forecastday[0].high.fahrenheit}) >= 33 ? 'Cadet Blue' : 
(decimal({$weather.forecast.forecast.simpleforecast.forecastday[0].high.fahrenheit}) >= 20 ? 'Medium Blue' :  
(decimal({$weather.forecast.forecast.simpleforecast.forecastday[0].high.fahrenheit}) >= 10 ? 'Blue' : 
(decimal({$weather.forecast.forecast.simpleforecast.forecastday[0].high.fahrenheit}) >= 0 ? 'Dark Blue' : 'Midnight Blue' ))))))))))))

The issue I have ran into when using this method above with ternary operators is you can’t have too many on one piston with this many conditions above since it’ll make the piston too big. I was able to do 4 different variables like above that makes the piston 20 chucks big so adding a 5th one wouldn’t be possible on the same piston.

You’ll notice I use ternary operators a lot, the IF statement in webCoRE is limited to 2 conditions where ternary operators allow for multiple conditions.


Hi @bfara83 been using you tiles for a while but I noticed something on the oC oF bit if the DH is from this side of the pond it is already worked out to be oC. So if you select oC in the variable it messes it up, what’s the best way to get over this?


Assuming you mean that it’s showing “C” twice…

You could always just remove the “C” (and even the degree symbol if you want) from the displayed text. That’s exactly what I did in the example I posted above… removed the “F” at the end of line 34, since it’s unneeded (everything is in F here).


Is that with the Temperature Device Tiles? I have a fix for Celsius on my latest version, just finishing up all the updates and I’ll update the initial post with an updated version.


Is this a limitation on the number of operators, or the piston size in general?

I wouldn’t expect that kind of limitation on piston size, at least in human readable, editable text form… maybe in memory requirements though.


The limitation would be with the size of the piston in general. You can have as many operators as you want if it’s coded right, one of my Weather Pistons has around 50 operators total on 4 different variables



No the values just became wrong so at the moment I just leave it as oF variable but in the piston equation I changed the oF to oC.


So it’s trying to convert a number from your DTH to celsius, that is already in celsius.

Not sure how Brad will handle that (and I can’t speak for him), but in your case you can just remove the celsius conversion function, since it isn’t needed. Then you can still set the UseCelsius variable to true so that the temp displays properly.

Or…just do what you did. That works too. :slight_smile:


The issue is I didn’t add a variable or expressions for when the DTH supports Celsius so it displays the °C correctly. I’ll work on posting the updated version now.



Brad… FYI

I used a gradient tool and some experimenting to come up with what for me is the best transition endpoints for blue/red temperature gradients (the hex values in my piston up there ^).

I would suggest adding variables for the upper and lower temperature end points, to set where values are fully red or fully blue. Using something like 0 to 100 is completely useless for me personally; I’m monitoring indoor temps, so I want mine set to something like 60-80. That means everything 60 and below is blue, everything above 80 is red, and in between is a gradient. It puts the happy spot somewhere right in the middle.

I’ve also added another case to the switch that sets the thermometer icon to white if the temp is 69-71…just because :smiley:


Now that I think about it…

I’m not sure how the webCoRE engine is structured or optimized, but in most languages you would pick up a little execution speed with less code if you first resolved object property/values to a simple variable, and then tested that. It may not make any difference at all for what we are doing, but in some cases (especially in loops with lots of tests) it can be pretty dramatic depending on the compiler and how/when it resolves object properties.

For example…

myTestVariable = decimal({$weather.forecast.forecast.simpleforecast.forecastday[0].high.fahrenheit})

myTestVariable >= 100 ? ‘Maroon’ :
myTestVariable >= 90 ? ‘Red’ :
myTestVariable >= 85 ? ‘Dark Orange’ :

That ^ “should” be a lot more efficient than having to parse an object collection that is 6 or 7 layers deep, and then running the target value through a decimal conversion function before every test.


For this particular example, I think a smooth gradient with a single function to assign the color would be much better, since it’s a linear change in color. Something like:

myTestVariable = decimal({$weather.forecast.forecast.simpleforecast.forecastday[0].high.fahrenheit})
someColor = rainbowValue(myTestVariable, ‘0’, ‘Dark Blue’, ‘100’, ‘Maroon’)

Just a thought. :wink:


Temperature Tiles are updated up on post 5 above:

If your devices are set to Celsius, change the CelsiusMode variable after you import to true to display the tiles in Celsius.