That looks similar to basicui
It is, I just customized the icons. The point is that it took me several days to do it. So either I’m stupid, or it’s not very self-explanatory 
How did you do it and what parts of doing it were challenging? Perhaps something can be done about it. Was it setting expressions? Searching for them?
I hope you didn’t download and put them into the icons folder. OH supports using icons from f7, material, and iconify by name. There’s no need to download them and create files for them.
The challenge was that the icons change dynamically (crossed out for off, different battery levels etc…) and this apparently only works with oh:icons, if i understood it correctly.
So yes, my solution was to download the icons and put them in the icons folder 
Actually no, this can also be managed using expressions in MainUI and in sitemaps there were changes made to support something similar.
For example, here is an expression I use for a light level icon:
icon: '=(Number.parseFloat(items[props.item].state) < 250) ? "f7:light_min" : "f7:light_max"'
This uses f7 icons as the source. Note that most of the time I end up using the same icon and use an expression on the color instead. But in this case it uses the f7:light_min icon when the Item is < 250 and the light_max icon when it’s >= 250.
For sitemaps they provide several examples, here’s one that also uses f7 icons.
Text item=TemperatureTrend icon=["UP"=f7:arrowtriangle_up, "DOWN"=f7:arrowtriangle_down, f7:arrowtriangle_right]
There is a separate parameter in sitemap entries to control the color of the icon.
Text item=NumberItem labelcolor=[>0 AND <50="yellow", >=50="green", "gray"] valuecolor=[>0 AND <50="yellow", >=50="green", "gray"] iconcolor=[>0 AND <50="yellow", >=50="green", "gray"]
See the sitemap docs for more details.
The “download and put files in the icons folder” approach is really kind of a legacy way to do it and IMO only to be used when you cannot use icons from any of the supported sources.
2 Likes
thanks for the tip, but I don’t know if thats any easier for me XD
1 Like
It seems that we should have items[xxx].numericState just so we don’t have to do parseFloat in such scriptlets.
1 Like
Is there a chance to get multi-value-icons working (like Level 0 to 100)?
@JustinG posted a tutorial (IIRC) but I can’t seem to find on how to create a dynamic icon that works like that. I don’t think Custom SVG Icon Sets is the one I’m remembering.
In the mean time, most of the icon sets for things representing levels (e.g. batteries) have three or four levels which you can define to correspond with any arbitrary values through expressions.
I don’t remember why I was told it doesn’t support that. I’ve seen your PR and will comment more there later this morning.
That probably is the one you are thinking about. The responses in the thread briefly mention that this would be a good way to make icons that are fully responsive to value even though the tutorial itself doesn’t work through that case.
Recently, @DiegoDF just did a nice job using that framework to make an svg that does just that:
Combining his work with the svg library tutorial would allow you to build an icon set responsive to arbitrary values.
Thinking more broadly, now that the png icons are de-ehpmasized (depreciated?) in the main OH icon server in favor of the svg versions it might be worth thinking about actually making the official icons arbitrary in value.
4 Likes
2 Likes
Is there a Roadmap or something comparable to this for openhab?
Yes and No. Recently we had a nice blog link below that covered it in a similar way, and the addon suggestions and improving the new user experience has been looked at more since the release and blog…
You can see the chat on it here, as we have a forum category for where areas being worked on can be discussed…
Core development is usually talked about in github, so you can see the open tickets and read the subject lines if you wish.
1 Like
No, there is none.
Isn’t that part of the problem? No communication about the future and a clear plan to make openhab better. I know we don’t have delevopers that are controllable, but maybe some of us will join the development if we know a clear strategy and idea of what could improve openhab in general…
I think openHAB should move more in direction A, developer 1 thinks it should move more into direction B.
How do we agree on what’s best for openHAB? Both our points are valid and are a direct result of how we use openHAB.
And it gets even more difficult if we talk about the fundamentals:
These are almost always a tremendous amount of work and it’s not always immediately clear if the result is worth the effort.
We have a new category for this now, it hopefully will enhance user - developer communication.
I moved this thread there.
Please note the category description.
My interpretation of Kai’s description is that this discussion does not belong in this new features category:
I can’t say that I have a better suggestion other than the basic Development category, but I do not see this thread as announcing any new user features specifically.
Well Kai created the category upon my request.
You’re sorta right and sorta not. Moving the thread that resulted in creation was meant to be a starter.
Fair enough.