Can you precise your wish please ?
Is your wish to have support of iconify in a sitemap UI (like BasicUI or the Android app) ?
According to docs it looks like items file format is:
// general syntax
Type Name "Label" <icon>
// example
Switch Livingroom_Light "Livingroom Ceiling Light" <switch>
From what I remember icons are looked up in backend through IconProviders and “classic” is one of them, notably a default icon provider which is always enabled.
So bringing a new icon provider and new set of icons through openahb core is possible. If one would hold a beer… maybe not for me but maybe for @Lolodomo 
3 Likes
Looking a little more what is iconify, I understand now that a new icon provider is probably not the right option. It is more the UI page that must be updated to use these online icons. So this would be more an enhancement to do in BasicUI. And we could probably use the existing “icon” attribute of the sitemap element to specific this icon (small change in core framework probably required to be backward compatible with all existing sitemap UIs).
That way, the iconify icon will not be assigned to an item but to a sitemap element.
Using the item category from the item definition to specifiy an icon would have certainly more impacts as the item category is certainly for UI rendering but also for other usages. And an item category is not exactly an icon.
Concerning the iconify icons, it sort of half way works already. If you know the name of the Item already you can enter that for the Category in MainUI and it’ll let you use it (e.g. f7:power). However it won’t show up everywhere it needs to. So it might not be as much work to make it work than it first appears.
There was a recent thread on this which I can’t seem to find at the moment.
However, I think one of the challenges is these Icons come with a default color (e.g. black) and in MainUI one would use a color field to select the desired color (or an expression to set the color based on some condition). I’m not sure how useful it would be to have all black icons for the categories and adding the ability to choose the color will become a significant;y bigger job.
1 Like
My wish is to specify icons in .items files that will then be used in the MainUI.
My MainUI is driven by the semantic groups defined in .items files, so everything under Locations, Equipment and Properties in the MainUI is automatically populated.
Maybe something like this:
Number:Dimensionless Battery <iconify:material-symbols:battery-horiz-000> [ "Battery", "Level" ] { config="some JSON object" }
I’ve made offline iconify iconset which contains only below iconsets:
- Material Symbols, iconset
material-symbols - Google Material Icons, iconset
ic - Material Design Icons, iconset
mdi - Remix Icon, iconset
ri - Carbon, iconset
carbon - Unicons, iconset
uil - MingCute Icon, iconset
mingcute - Memory Icons, iconset
memory - Unicons Monochrome, iconset
uim - Unicons Thin Line, iconset
uit - Unicons Solid, iconset
uis - IconPark Outline, iconset
icon-park-outline - IconPark Solid, iconset
icon-park-solid - IconPark TwoTone, iconset
icon-park-twotone - IconPark, iconset
icon-park
(they are licensed under Apache and fit into “general” category).
Attached link is ~30 megs, so it may slow down startup of your system https://co7.io/CFHi ;-).
Icons are available via two paths: /icon/baseline_1k.svg?iconset=ic, in schematic it is <icon>.svg?<icon-set>, or using classic iconset with scheme <icon-set>-<icon>.svg.
If you request icon containing _ it will be replaced with -. Assuming above example of baseline_1k or ic_baseline_1k final icon request will be baseline-1k or ic-baseline-1k.
This is due to two facts first 1) special meaning of dash for dynamic icons, 2) assumption that classic is default iconset (its hard to override it through UI config).
Note, using above icons will make main ui freak and display no icons. At least that was case for my test setup. Anyone interested in testing this - feel free to play with it.
Sources as usual available here: connectorio-addons/bundles/org.connectorio.addons.ui.iconify at master · ConnectorIO/connectorio-addons · GitHub
// edit 20.02.2023
Marketplace entry with provider: Iconify icon provider.
2 Likes
There is nothing related to Items that you cannot define in a .items file and have it work exactly like it does in MainUI. You point out would be the same as setting the icon to “iconify:material-symbols:battery-horiz-000” which you can do in MainUI too. And if you did that, it would work/not work in exactly the same ways.
I think both main ui and basicui could use same category/icon syntax if items file would relax validation of icon/category field. I may be reading it wrong but the definition - openhab-core/Items.xtext at 8d64ecfd8db99844d79a776fef37cbe527c1f0c6 · openhab/openhab-core · GitHub, of ID and STRING do not include : character used by UI and jsondb.
From that point of view your statement that you can do same does not pass…
Edit: existing issue for core: Item - Category field · Issue #3052 · openhab/openhab-core · GitHub
I’ve got another one. I would love to be able to configure the period of the oh-charts in widgets with a formula or reference to props. Now I’m making copies “xx_h”, “xx_2h” and so on. So
props:
parameters:
- context: String
label: period
name: period
type: TEXT
....
- component: oh-chart
config:
options:
period: = props.period
or period: "= props.period=='day' ? 'd' : 'h' "
@supersjel AFAIK this should already work in latest 4.0 snapshots (Generalize evaluating expressions for charts & fix diff_last aggregates by crnjan · Pull Request #1649 · openhab/openhab-webui · GitHub) …
1 Like
I have almost implemented iconify in BasicUI yesterday.
Regarding icon color, my idea is to add a iconcolor to sitemap syntax, similar to existing labelcolor and valuecolor. Would be added in a second step.
15 Likes
Legend.
That’s really great news! I’m on the 3.4 production release but now I know it’s coming 
For those wanting to follow the development of this new BasicUI feature:
4 Likes
It would be nice (UI-wise) to have the ability to associate an icon to Things.
Could you please explain your usecase.
Rendering a more fancy/appealing “Thing” list in main UI. Bindings are associated to a picture, channels also. This could also be used in documentation generation. Just a 2ct idea.
Thinking of it a bit further, that would mean that the binding should deliver appropriate icon ressources also. Then I’m wondering if it would not be interesting to package appropriate resource icons along with the binding (for the things and channels when not available in the standard icon sets). This could save sooo much time for end-user chasing the internet for appropriate icons.
Still 2cts
5 Likes
Hello,
It would be great if there was a UI way to create Aggregation Functions for groups with BaseType different than switch.
Examples for this are a groups with a type of string and an aggregate function that performs a logical AND or OR to see if items have the same value or not, or that performs a Count of items.
I would use this for example, to have a main control that controls several fans. Fans sometimes have more than 2 states, and thus aggregating them with a switch type does not work very well. But if I declare them as string, and I use an aggregation function like AND(“0”, “1”) , I could have a group with a value of 0 when all fans are 0, and a value of 1 when all fans are not zero. That way, i can turn them all on(to one of the specific ON values, can be 1, 2, 3, etc) or all off with one switch. With the Count function, I could also count how many fans are on or off.
I tried to define this through text, but it fails. And i do not see a way to define it in the GUI.
IF aggregation functions could also be very powerful here.
Thanks
This is already possible and has been for a very long time. But not every aggregation function makes sense for all base types.
AND and OR is only ever going to work with the boolean type Items: Switch and Contact. But you can use COUNT with String Items. If the UI doesn’t let one use that with String Items, than please open an issue as that should be supported right now.
No you really can’t, at least not in a way that makes sense given what AND and OR actually mean from a mathematical sense.
These operations only work for boolean data types. In a case like this, if you used Numbers you could use a MIN/MAX type aggregation function to achieve the same result I think.
Like I said, COUNT should already be working. If not please file an issue on the openhab-webuis repo because this has always worked even as far back as OH 1 so if it’s not working now, it’s because the UI isn’t showing the option.
Please open another issue to explore this. COUNT on a String Group has worked in the past.
That needs way more description and explanation.
@rlkoshak , thanks for the clarification.
How can i know which aggregations are available for each type?
Thanks