What is the issue to use icons already mentioned/shared by other users here
And how big should the openHAB distro grow to until users complain about the download size.
You already can use custom icons, so what’s wished here is already possible.
The default distro icon set is rather incomplete, and searching-collecting is tedious work so an upgrade to that would be a plus.
But hey people, no coding required so that’s something any of you can contribute to openhab so go for it and make it a PR rather than ask for it.
Yes you can use custom icons with iconify:…, but it’s too little known. Maybe some more integration to have a graphical picker mode would be a plus. And for sure this needs some more love in the docs.
6 Likes
The question was about usage in sitemaps, there is no iconify support in BasicUI …
First of all, we would need to know, what Wifi module is added to your AC.
Please note, my questions does not mean I am going to write a binding…
Just being interested in what is used here.
Wireless Internet Access & Control Module for Pioneer® Diamante WYT Se (pioneerminisplit.com)
Right now, I am controlling it through Alexa integration, but it is very limited.
Thanks
Based on Google, this is a TST-DIAWIFITPD which can be controlled with Smart Life App.
If so, it is a Tuya based device and you can find a Tuya Binding in the smarthome/J 3rd party marketplace.
I will try that. Thank you
Agree on this.
In my own personal openHAB installations I’ve made extensive use of icons I’ve downloaded from several sources (mostly from icons8). The issue with contributing to the distro is making sure you don’t run afoul of the many and varied copyright/license agreements that seem to abound in this space.
The vastly expanded icons options and the ability to change their color through expressions rather than the old dynamic icons approach in sitemaps was the primary reason I move to MainUI back when I did it. I’ve since come up with other reasons to stay, but that was my initial reason.
With very little configuration I can get a widget like this which combines two Items that lest me control the opener (clicking sends a command to Switch Item) and shows the status of the door through changes in the icon and the color.
This next one independently shows the locked/unlocked sate of the door’s deadbolt and the open/closed state of the door itself through icon and color changes and the text in the footer changes based on the state of the two Items as well. Click it triggers the lock to unlock.
1 Like
You probably mean the suggested name by MainUI, not by the binding? MainUI will propose, whatever the binding, this name: “thing ID_channel ID” as default item name.
In the case of remote openHAB binding, “channel ID” Is set to your remote item name. So you just have to define a short thing ID for your remote server.
So your wish apparently rather concerns MainUI. What default item name would you suggest when linking it to a chamnel?
now as you write it, I think that’s not binding related. What I discovered with remoteOpenhab-Binding is, that I used the Auto-generated Thing,which was reaaaaaaly long already, something like the local IP-address and stuff. You could rename it, but it took some time… Wait, I just try it again:
(1) Name of the remote openHAB Server
(2) Item piece
(3) name of item on remote OH
So, I guess my wish for MainUI would be to somehow be able to define a Prefix for items, when using the “Add-to-model” option in the Thing configuration - and vice-versa in the Model configuration, where I seem to remember, the suggestions from Model will differ from the suggestions from Thing?
Not sure to understand why you have piece 2 (item_). Either this is the binding that adds this part or MainUI. I will check that.
Note that when you create a thing, you can set the ID you want, even from inbox.
1 Like
I have tried the Tuya binding and it did work, but there is more functionality to the Alexa skill then this one. So I will stay with that. Thank you for your guidance!
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. 
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.