Changing properties of standardTiles dynamically based on other state variables

something like this has worked for me in a smartapp

state "auto", label:'${name}', action:"switchMode", nextState:"...", icon: "st.Home.home1", backgroundColor: getDeviceState()


blah blah code

def getDeviceState(){
def color = "#003CEC"
if (device.currentState("thermostatOperatingState") == "heating"){
      color = "#E14902"
}
color
}

This worked for me in a smartapp to dynamically assign stuff to statuses within the app. Might work in a device type? I don’t see why it wouldn’t?

2 Likes

I’m confused… What has a “backgroundColor” in a SmartApp?

I thought only Devices have Tiles?

I adapted the code to make sense for a device type This code was used to set the complete/incomplete for a dynamic page in a smart app

Ah… Slightly different animal, right?

Do Dynamic Pages have backgroundColor?

Device Tiles seem relatively constrained, but maybe I just haven’t tried creative enough code…

No, but the inputs allow for complete or not complete so they are either grey or green

1 Like

Thanks, oddly interesting I don’t think once can access the device instance in a tile.

java.lang.NullPointerException: Cannot invoke method currentState() on null object

Any ideas?

It really comes down to can one access device properties in a tile? @duncan

Dang… It was worth a shot lol!

Right, device tiles are sent as data to the client as part of the device type. Any groovy code in them will be interpreted when the metadata is parsed, so it can’t respond to device specific changes.

For dynamic pages, the client calls back to the SmartApp running on the server each refresh.

1 Like

Hi Duncan … thanks for the explanation.

From my perspective, I’m a little confused by your wording. For example, Device Tiles can reflect the value of their particular attached State variable (including showing that value, changing color, etc., etc.).

In this example directly from the Documentation, isn’t ${currentValue} a “device specific change”? Granted, it is not a method, and it only references the Tile’s specific attribute (i.e., “device.power”), but it is somewhat Dynamic.

I guess what I’m asking is how likely or reasonable would it be to see if this particular functionality can be extended… i.e., so that a Tile can refer to properties and/or methods of it’s parent Device Instance – if my wording makes any sense or is in any way close to reality. :confused:

valueTile("power", "device.power", decoration: "flat") {
    state "power", label:'${currentValue} W'
}

Interesting point, if the device refreshs the data and server evaluates the metadata and send back the data to the device, the server is evaluating the property “operatingMode” in the above case. Isn’t is possible for it to evaluate other properties? Also can the Tile process multiple properties instead of just one?

2 Likes

I’ve been interested in similiar alterations to the tiles for power meters. I have mine hooked up to a washing machine and I’d like it to light up green when it’s drawing power, and go grey when not drawing power. That way with with glance I can see if the washing machine is in use.

I think this one is doable!

As long as you have a Tile dedicated to an attribute for power usage, you can change the color (and icons)… Check out the Device Handler for any Temperature Device as a good example.

We can work out the details together.5

The server just creates events, it doesn’t deal with the tiles. The mobile app updates the tiles based on events, and ${currentValue} is just a special token it looks for. IMO it’s confusing to use the groovy string interpolation for that because it’s not actually doing what it looks like it is.

What you can do is make an “aggregate attribute” that combines two other attributes. An example is Z-Wave Smoke Alarm, which uses the alarmState attribute solely to update the main tile based on either smoke or carbonMonoxide detection. Obviously that has limits though; it will only work with enum type attributes with a reasonable number of possible states.

4 Likes

To Which smoke alarm are you referring?

Go here, click “From Template”, then click “Z-Wave Smoke Alarm” down near the bottom.

2 Likes

LOL Wish I had read this thread yesterday.

This is my “solution” to do exactly what you were trying to do - all the way down the thread, I implement “shadow attributes” to have states with different tile colors.

1 Like

anyone have more information on this… I would like to have a separate set of colors when a thermostat is in Celsius vs Fahrenheit mode but seems there is no way to have external setting or state variables be evaluated in a tile…

thanks…

1 Like

Do the common Celsius vs Fahrenheit values overlap? If not, you can set this up the normal way for temp values. I guess you’d have trouble for actual outdoor temps, but for thermostat set points and readings there should be a big enough gap between hot in Celsius and cold in Fahrenheit.

Yes that’s what I did …but not perfect …there is slight overlap on the low end