Change Colour of Cell upon state?

  • Platform information:
    • Hardware: _CPUArchitecture/RAM/storage_PI4
    • OS: _what OS is used and which version_OPENHABIAN
    • Java Runtime Environment: which java platform is used and what version
    • openHAB version:
  • Issue of the topic: please be detailed explaining your issue - Hi Im a newbie, Ive managed to set openhab to monitor 3 GPIO inputs, and have 3 cells showing on/off on this input change. I just want to change the colour of these cells from green to red upon input state change, and not judst rely on the text “oN” or “off”
  • Please post configurations (if applicable):
    • Items configuration related to the issue
    • Sitemap configuration related to the issue
    • Rules code related to the issue
    • Services configuration related to the issue
  • If logs where generated please post these here using code fences:

In Sitemaps or MainUI?

On the main page…

I have these 3 cells, which I wish to change colour. I have tried.

I have tried

You also need to fill in the "On" expression field below the Highlight Color field. You are correctly setting the color, but because the cell isn’t “on” it’s no using that color as a background.

Because you always want the cell to be either red or green you don’t even need a fancy expression there, just put true.

Hi, I have tried


and “true”

not working sorry

Leave it filled in and then select Edit YAML from the black menu button above the cell. Copy the text code that you see there and paste here in code fences like this:

pasted yaml code goes here

That way we can see the whole configuration and determine what is going wrong.

component: oh-label-cell
  item: Pigpio_Remote_PSB_1_RF
  title: PSB 1 RF
  stateAsHeader: true
  expandable: false
  color: "color: \"=(items.Pigpio_Remote_PSB_1_RF_Online.state === 'ON') ?'green':
  on: "true"

Ah, that makes it much easier to see what’s going on. In deed, I missed the error before in your screenshot because they are not nearly as easy to comb through. The on setting is correct (it actually doesn’t matter at all what the value is as long as it’s not empty or false).

You duplicated the key color in that definition when you entered it into the dialog. It should only read:

color: "=(items.Pigpio_Remote_PSB_1_RF_Online.state === 'ON') ?'green': 'red'"
component: oh-label-cell
  color: "=(items.Pigpio_Remote_PSB_1_RF_Online.state === 'ON') ?'green': 'red'"
  expandable: false
  item: Pigpio_Remote_PSB_1_RF
  on: "true"
  stateAsHeader: true
  title: PSB 1 RF

Sorry stays red , regardless

Welcome to the community!
Try changing the on: from “true” to ON since that is the value that you are getting as the state of the item. To determine if highlight should occur.
Also note if you add a trendline the color will not change I sorta recall as a behavior.


tried ON - unfortunately stays red regardless

component: oh-label-cell
  color: "=(items.Pigpio_Remote_PSB_1_RF_Online.state === 'ON') ?'green': 'red'"
  expandable: false
  item: Pigpio_Remote_PSB_1_RF
  stateAsHeader: true
  title: PSB 1 RF
  on: ON
slots: null

dont understand what you mean by trendline.


Looks like your " and ' are swapped around.


color: '=(items.Pigpio_Remote_PSB_1_RF_Online.state === "ON") ?"green": "red" '

The following works for me:

component: oh-cell
  color: '=(items.ShellyGarageDoorshelly1a4cf12f486ac10163199232_Input.state ===
    "OFF") ? "red" :(items.ShellyGateshelly1a4cf12f41d5e10163199231_Input.state
    === "OFF") ? "red" : (items.Shelly_UNI_Garage_ElectricFence_State.state ===
    "OFF") ? "red" : (items.ShellyUNI_Doorbell_Overide.state === "OFF") ?
    "red"  :"green"'
  on: true
  title: Security Controls

Well, that widget code is 100% correct. If it stays red, then that means that your item Pigpio_Remote_PSB_1_RF_Online does not have the state that you believe it does (or has typo in the name).

Open up the developer sidebar (shift + alt + d) and go to the widget expression tester (the image icon). Paste in:


And check the result.

This doesn’t matter. The value of the on property could be “cucumber” and it would still work. The cell is checking for a boolean value and in javascript, which is what is being used to process the cell’s function, most real values evaluate to boolean true. The only things that do not are actual false boolean values, 0, empty variables, and undefined variables (which includes if on is not set at all in the yaml).

That is 100% correct. If the cell has the trendline properties set then that overrides setting a highlight color and the color and on states will be ignored.

Shouldn’t matter as long as they are kept straight. There are some very slight differences in the use of " vs ' (such as whether or not you have to escape " characters inside the string if you want to display them, but none of those differences come into play here. The outside quote are only there because of the way the yaml is parsed initially. It looks for :[space] combinations to determine where key - values pairs are so something like:

a: =b ? "c" : "d"

actually gets read as:

a = '=b ? '
c = '"d"'

This of course leads to invalid expressions and errors while rendering the widget. Enclosing the entire expression in another set of quotes informs the yaml parser that the entire block is the value of that first key:

a: '=b ? "c" : "d"'

correctly gives:

a = '=b ? "c" : "d"'

If you arrange the ternary expression so that the : doesn’t have a space after it then you don’t even need the outside quotes. I like to use (...) as I think this is quite readable:

a: =(b)?("c"):("d")

In fact, if you don’t have any string literals then you don’t need any quotes at all:

a: =(items.someItem.state == vars.b)?(props.c):(props.d)

If the OP is wrapping quotes around the expression via the UI then it will not work. if they are added via yaml edit as soon as you click done they are removed. But if they are added in UI they remain when you view yaml.
this in yaml

This in UI

Works fine
This how ever will NOT work.
And gives you this.


But I also agree he needs to confirm his real item state value being returned as well.
Because the code does work perfectly fine.