Dynamic icons not updating when color item state changes

Hello everybody!

I tried to add dynamic icons to the color items to directly see the ON/OFF state of my RGB lights.

Since I couldn’t find much information about the state representation of color items I raised the log level and found OH3 looking for icons ‘name-#123456.ending’. Were 123456 is the RGB value (‘name-#RRGGBB.ending’).

I can’t imagine how the RGB value could be useful without some kind of ‘nearest matching algorithm’ in the AbstractResourcesIconProvider.java but for the ON/OFF display this shouldn’t be necessary.
OFF will always be RGB #000000. Everything else is ON and the icon provider will redirect to the default icon if no exact match will be found.

So I made a grayscale colorwheel icon and saved everything in the icons\classic folder:

  • colorwheel.svg → colorwheelstatus.svg
  • colorwheel.png → colorwheelstatus.png
  • colorwheel.svg in grayscale → colorwheelstatus-#000000.svg
  • colorwheel.png in grayscale → colorwheelstatus-#000000.png
    (I wasn’t sure, if the icon provider could combine a user icon and an internal icon. To be safe I used a new icon name.)

When the sitemap is accessed with the Android app everything works like a charm. The icon is updated as soon as the color item state changes. Just like on all other items.

But when the sitemap is accessed in a web browser with BasicUI the icon is not updated when the color item state changes. A refresh of the web page loads the correct icon. So it seems to work. Just without the automatic updates like on other items.

I tested this on Openhab 3.0.1-2 (zulu11.45.27) with:

  • Android App 2.16.0 (Android 9)
  • Chrome 89.0.4389.105 (Android 9)
  • Firefox 87.0 (Windows 7 64bit)
  • Chrome 89.0.4389.114 (Windows 7 64bit)

Is there something I’m doing wrong?
Or is it possible that there is no dynamic icon update on color items?
If so: Is this a bug? Or a feature?

Best regards,
Tobias

I think not.

Not properly, as you’ve found out.
Where do you see that # character, that seems possibly problematic.

It’s very easy to inadvertently make sitemaps that don’t refresh well. See your openhab.log at boot time fo possible clues.
Some browsers are better behaved thanothers.

Hello rossko57!

Thanks for the reply!

Since I couldn’t find information about the color item state in the docs or in the forum, I set the logger
<Logger level="INFO" name="org.openhab"/> in log4j2.xml
to level DEBUG to check for requested filenames and got something like this:

2021-04-12 20:22:13.940 [DEBUG] [ui.icon.AbstractResourceIconProvider] - Use icon colorwheelstatus.svg as colorwheelstatus-#000c00.svg is not found

With some testing, I could see the value 000000…FFFFFF is a 3x8 bit RGB color.
I was a little bit surprised, because I expected something HSV like.

Here is a little test config for demonstration:
(It needs the icons “colorwheelstatus” and “colorwheelstatus-#000000”.)

testitems.items:

Switch		TestSwitchItem		"Test Switch [%s]"			<light>
Color		TestColorItem		"Test Color Item [%s]"		<colorwheelstatus>

testsitemap.sitemap:

sitemap testsitemap label="Test Sitemap" {
	Frame label="Test Switch Item" {
		Switch			item=TestSwitchItem
	}
	Frame label="Test Color Item" {
		Colorpicker		item=TestColorItem
		Switch			item=TestColorItem		icon="light"
	}
}

Both items are working perfect in the Android app.
In Webservers (at least with Basic UI) only the icons of the switches are updated. The icon of the colorpicker is only updated on page load/refresh.

I allready checked that. But there are no noticeable problems.
Is there a logger for “state updates” that could provide more information if configured to a higer level?

Best regards,
Tobias

Not sure what you mean. Raw Color state will be something like 201,42,95

I guess that comes from the UI. The UI’s can request icon images using a form like -
http://192.168.1.241/icon/EcoBeeTemp?state=73.3&format=svg
In that case, the icon picker will
Manipulate 73.3 into 73
look for image EcoBeeTemp-73.svg
if not found, look for EcoBeeTemp-72.svg, -71 etc.down to -0
If not found, serve up default EcoBeeTemp.svg

But I would imagine the icon picker treats #000c00 just as a string, not a number, like it would state=OPEN to serve someicon-open.svg. It just picks based on its own simple rules, knows nothing about Item types.

I rather think the Android app is doing entirely its own thing converting Color state to #000c00 for this.

Yes, I know. Because the HSBType is a more complex type than other states I tried to find some information about how to form the string for the icon filename. But in the Dynamic Icons chapter there were only some examples for less complex items like switch and dimmer items.
Could be helpful to also add an color item example, if “name-#RRGGBB.ending” is correct and working somehow.

I think you’re right!

But why is the Android App aware of the state change and refreshes the icon, while BasicUI is not?
How is the concept working? Do the connected clients have to poll for state updates or is there a notification from the OH server?
Could BasicUI decide or filters what kind of updates to forward to connected clients?

But as you have found, it is undocumented because it is not supported.

Because the BasicUI does not attempt to use an unsupported function?
To avoid the need for 16,000 icons, there would need to some graininess/quantizing introduced, like regular number icon picking.
Or something altogether cleverer, like generating a coloured image.

While you’re at it, Location type Items are not well supported by dynamic icons either.

You might be interested in -

Hey rossko57!

Many thanks for your time! :+1:

OK! Were do I find such information?
I wouldn’t assume something is unsupported, only, because there is no example for that explicit scenario in the docs. If everythink is working in the same way, one or two examples are completly suffecient to explain the schema.

I can remember, that till the early OH2 versions, there was no way to get dynamic icons working on color items. Even if represented as switch or dimmer/slider in the sitemap. So, there has definitly been an improvement. Now it’s working and with the RGB state together with the default icon logic, it’s at least good enough, to represent the ON/OFF state. The App is allready working perfect. Just an automatic update in BasicUI is still missing.

If this is still mentioned “unsupported” somewere, would it be possible to submit a kind of “feature request” to add the App-like-funktionality to BasicUI, too?

Of course, the perfect universal solution, capable of doing everything would be great. But that wouldn’t be found overnight. Keeping it strait forward with the default schema like on other items, offers at least some possibilities untill that day. Better than “not supported”. “Perfect” is an unobtainable standard.
If someone really tries to add 16000 icons to represent every color… Well nothing stops that guy from adding 101 icons for each dimmer. :wink:

Yes! Thats somthing I read somewhere but I can’t remember when or where.
But I think, thats fine. I would put uses like mapview in a row with charts, images or videos. There is no direct user control.
On the other hand switches, dimmers, rollershutters and color are objects for direct user control.
Organized in groups (for functional perspective) the offer an immediate overview. But only because of their dynamic icons.

Thanks! I’ll read through this.

It doesn’t work like that.

You might put that in the same place on github as the existing discussion I already pointed you to.

The point is that you don’t have to provide 101 dimmer icons. The icon picker applies smarts here, and allows ranges of numeric values to select from a limited number of icons.
The standard OH3 ‘slider’ icon set covers 0-100, UNDEF, and NULL with 12 images.

Have you tried expanding your scheme to just three icons? Let’s say, off, up to 50% bright, over 50%.
I think it is working almost by chance, and treating this magic #code from the UI as a string type icon selector. You’ve got an icon for exact-match (string state style) and an icon for no-match. It’s not very practical for Color unless the icon picker allows some kind of near-match or ranged system.

EDIT - had a peek at existing icon-picker code

It’s “simple and effective”.
It lines up a default icon (e.g. youricon.svg)
Only if that exists, will it consider state for a dynamic icon (e.g. OFF, 29,or indeed #00c000
It looks for a image name exact string match (e.g. youricon-off.svg, youricon-29.svg, youricon-#00c000.svg)
If that fails, it tries to get state as an integer 0-100 only (e.g. 29, those others will fail)
If a number is obtained, it steps down trying one by one 28, 27 etc. until it finds a match (e.g. youricon-20.svg)
Finally the found image is returned.

So, today, #00c000 is working as a string-type exact match. Seems a fair guess that’s an RGB version of state the UI is requesting, so you’d need 16,000 icons. Any missing codes would return the one common default icon.

Of course all that can be changed, but you need a sensible selection scheme. Stepping down through 16,000 possible codes in the same way as the “percentage” icon works is not going to perform well.

I think such a scheme would actually be more flexible based on HSB state than RGB.

Once the scheme is set in stone, each of the half-dozen UIs will need to implement it.

This old discussion,if you look beyond the provision of alternative icon sets,includes some alternative ideas about icon colourising.

Ah! Ok, I will try to do open an issue the next days. Maybe if some people show interest in a better color item icon support, someone could could kick it off in the future.

Yesterday it was too late to experiment. I’ll try this now.

My thoughts exactly! Thats why I thought it should work with the default icon (for ON) and the state #000000 icon (for OFF).
I’ll try with a third icon. For example #FF0000 and try to toogle between these exact values to check, if it has an influence on the icon update process, if all 3 icons are available (default, state 1 and state 2).

I’m not sure. With the RGB state and the “default-icon-rule”, it would at least be possible to provide ON and OFF icons allready.
With HSV this wouldn’t be possible at the moment, because OFF doesn’t have to be 0,0,0 just x,x,0.
But of curse, if the icon picker would be extended to do some math or transformation, it could also do all possible things with a HSB state. (As with RGB, since it just needs some math to get the one from the other, but HSB might be the more straight forward solution in that case, since it’s also the raw state.) :thinking:

Well yes, that will work. Still around 16,000 icons to go…
What I was suggesting was - can you make an icon set as basic as ‘black’ for off, ‘grey’ for on but less than 50% bright with any colour you like, ‘white’ for >50%.

I’m trying to say that there is today no meaningful support of dynamic icons from Color Item states.

So, I tested with three icons (default, #000000 and #ffffff) and switched exactly between the #000000 and #ffffff states.
Same as before: works flawless in the Android app but no automatic icon refresh in basic UI. Only after a page refresh with F5, the icon changes to the new state.

Only, if you assume, the only meaningful support would be to show the actual color and everybody needs to see that on the icon.
I don’t know, if we understand each other right. At least I don’t need this! The only important information for me is: Which lights are on and which are off.
I don’t care about the actual color on RGB lights nor the actual brightness of dimmers.
(I even find the dimmed icons on dimmers sensitive to erroneous recognition, because a low level looks like off. But this can be changed, with an less staged icon set.)

If I check my house, when I’m away, all of concern is: what is on or off, open or closed, up or down. If I’m at home, I adjust by well-being not by a value or an icon on the display.
So in my oppinion, a digital state icon, to show exacly 2 states, is sufficient for 95% of all things (on/off, open/close, up/down, alarm/ok,…) There is no need to overcomplicate this thing. :hugs:

And this is allready there! The icon picker does this job and this part works!
It’s just the automatic update for color item icons that is missing in basic UI.
In the App the icon is updated like all other icons.

Btw: Whatever nice logic might come some day: The automatic update for the color item icon would need to be included till than. Otherwise every logic won’t work.