openHAB 4.0 wishlist

Pleas open a new topic describing your issues or missing features with the tuya binding controlling your AC. Perhaps we can add those easily…

I would like to see iconify support in .items files.

Won’t happen. .items and other file inputs are a valid input format only for fixed (and older) functionality (OH major versions <=2).
You can keep using sitemaps, but don’t expect any new features there.
After 3years of OH3 it’s time to move so if you want iconify, move over to MainUI.

A bit bold, the items file has been adapted to semantic tags and other metadata with 3.0+.
It is not old as in deprecated, it is fully supported and there are no plans to drop it. :slight_smile:
Agree in the end iconify will probably not happen though, it is gonna take a serious effort

I’m already using MainUI and driving it from the semantic model that I have defined in my .items files.

I think there is a big misunderstanding. The icon in the items file is configuring the category of an Item in MainUI and even there is no support for other icons than the classic set.

Technically this is not correct. Everything required that makes MainUI and the sensors model work (tags, metadata, Groups) has been supported by Items and in .items files for a very long time. Nothing has to be added or changed to support them.

That’s neither here nor there in the scheme of things but I think it’s important to understand this to understand where Marcus may be coming from. The syntax for items files has not changed in any meaningful way since OH 1.

In short, the semantic model was built on what already existed and was supported by .items files, .items files were not changed to support the semantic model.

Any contribution regarding sitemaps are still acceptable, even if priority is more on MainUI.
I even do not reject the idea to contribute myself to BasicUI.
I also try to maintain BasicUI when i have the skills to do it.

2 Likes

I could have a look, it is an interesting feature and I do not see immediately why it would be so difficult to implement.
Maybe simply a new icon provider?

2 Likes

Where’s the point of iconify then? It’s in Main UI as an item option.
As you say you are using Main UI you should import your .items one-time rather than continue maintaining them

Or a lookup field that searched directly in an icon provider…?

Everyone has the choice between UI or files for items.
Power users (more technical users) would certainly prefer keeping items in files because there are some advantages to that option.

1 Like

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 :wink:

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. :wink:
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