Don’t get what you mean. Textual defined Item are never updated. When you change .items files, the item gets deleted and then recreated with the new config.
The item definitions for the Widgets were never meant to be used in .items files but to be imported into the UI to have managed Items. You can then edit them within the UI.
Sorry for being ambiguous. I defined my semantic model via text (same as quite a bit of my items as a relict from my OH2 days) pretty much as you described in the initial post.
However I did update the semantic model groups based on your description with the uiSemantics tag and I also had to update some of the item definitions as well (mostly lights with both dimmer and white color temp). For the latter ones I updated the item definitions quite a few times and it seems every time I did it (via “Add items from textual definition”), another instance of the item is added to the widget.
As I wrote the weird thing is that I see this also in the developer view of the widget.
Did I understand you correct, having .items file in the items config folder and trying to update those by importing the Item definitions in the UI? If so, this is not going to work. Either use textual config or managed config, but don‘t mix them.
Following this, I have never seen errors like you describe and they are not widget related.
Nope, I don’t use .items files any more - I did a backup of my item definitions from OH2 when I moved over to OH3 and used those to initially create the items and groups via “add items from textual definition” rather than starting from scratch with MainUI.
I also defined the semantic model upfront via text as I got used to DSL over the years and it was pretty quick for me.
OK, I don’t have a clue what’s going on. Anything in the logs when you update via import ?
Could you PM me your items file?
The issue has been fixed - thanks @hmerk. It was due to the semantic tag “Equipment” missing.
As soon as I added it, the duplicated entries disappeared.
On another note: I have a couple of Tradfri Bulbs that only support brightness and white color. Is there a way to consider that in the Lights widget as well? As far as I can see it the widget would either show brightness only or ambiance + RGB.
This variant is not considered in the widget. Let me think of a way to solve this…
Those are white spectrum bulbs. I will add another non semantic Tag (WhiteSpectrumLight) to support these type of bulbs. Should be ready by tomorrow, will let you know.
2 Likes
Hi. Thanks for your work on these widgets.
I re-modelled my openhab semantic model according to the documentation and created widgets manually from github source files (I need to tweak some of them to fit my needs). The only problem is that the rendering has a delay of about a second and it is quite annoying.
I am running Openhab on a Raspberry Pi 4 from an SSD and inside a Docker container.
Is Rpi4 fast enough for this to work? I can try playing with Conteiner CPU priority…
What was your test enviroment?
Thanks for any ideas.
2 floors
21 rooms
31 lights
13 blinds
13 window contacts
Openhab docker container idle about 4% of CPU. When rendering, it jumps to over 120% of CPU.
We tried it on several installations and don‘t see long delays. A Pi4 has enough power to use the widgets.
If you can send me your modifications, I can try to see if those are the culprit.
But it also might be your large number of rooms.
Largest installation I could try was
4 floors
15 rooms
20 lights
7 rollershutters
11 radiator controls
4 air confitioners
10 door/window contacts
Never tried docker containers….
Hi. Thanks for the info.
My changes are here: GitHub - hynekprokop/semanticHomeMenu
But I mostly delete stuff:
- Lights - I modyfied footer + change bulb colour according to light status
- Rollershutter - removed schedule
- Weather - deleted everything that was in it
I am still missing some items in the model (SystemStatus items for example). Is there any performance issue if items do not exist in the model?
Nevertheless, I will try to play with Conteniner configuration.
You just need to delete the call for the weather widget in the semanticHomeMenu main widget.
I will check your changes later.
Did not explicitly check, but yes, this can cause performance issues.
You can remove the call for the semanticHomeMenu_System widget and check performance again.
1 Like
Just checked, but did not find anything obvious.
1 Like
This looks like a fantastic way to do a UI. I have started trying to implement this, and it’s not easy. The documentation, with respect, is not very clear. I finally got the widgets installed and started creating some of the required groups, but now it looks like I need to rename all my items to make them work - is that correct?
It’s not clear to me what to do after reading this thread semanticHomeMenu for openHAB 4 - Discussions - #8 by hmerk
That is correct. Or maybe correcter would be that you need to make sure certain items are named according to the convention of the semanticHomeMenu. (I.e. deleting items with ‘wrong’ names, and recreating them with the ‘right’ name.)
If I’m not mistaken, the naming guidelines are found throughout the different docs of the different parts of the semanticHomeMenu. So there’s a bit of puzzling to be done. 
2 Likes
Thanks, I know the docs need a bit of rework, will try to find some time for it.
Any suggestions what to improve are welcome.
If you could describe a bit more, I will try to explain what needs to be done.
Yes, and this is by intention. Every widget needs it‘s own Item set. If e.g. You don‘t use the HVAC widget, you do not need to read about it’s Items.
So, if I understand correctly, would I rename it this way?
Dimmer MainFloor_FirePlaceLights_Dimmmer "Fire Place Lights" <light> (gEquipFamilyRoomLights) ["Control","Light"] {channel="mqtt:homie300:Queen:dimmer-4ab35c1:dimmer#dimmer", OccupancyEvent = "Switch"}
Dimmer MainFloor_FirePlaceLights_brightness "Fire Place Lights" <light> (gEquipFamilyRoomLights) ["Control","Light"] {uiSemantics="uiSemantics"[preposition=" in the", equipment="Ceiling Light", location="Bathroom"],channel="mqtt:homie300:Queen:dimmer-4ab35c1:dimmer#dimmer", OccupancyEvent = "Switch"}
I am curious about the rationale for doing it this way. Could this not be solved by using Tags or Metadata? I’m looking at renaming at least > 100 items.
I would need to see the complete Equipment group to check.
The one Item you are showing seems to be correct.
That’s what we tried first. To achieve this, we needed a lot more oh-repeater components, cause Metadata and Tags are only available in widget expressions when using the repeater.
This massive use of repeaters caused delays while rendering the widgets and made the complete project unusable. It was a really bad user experience. After many hours of trying to optimise what could be optimised and even introducing the cachedSource option within the repeater, we decided to go the other way, using a predefined naming. We then could reduce the number of used oh-repeater components and the widgets became usable again.
I am afraid, there is no other way than to use the naming lige written in the widgets documentation. Sorry about that.
Ah, I got it - that makes sense. That’s a shame given that was one of the goals of the whole semantic implementation.
Here are the Equipment and Location groups.
Group gLocMainFloorFamilyRoom "Family Room" <material:family> (gLocMainFloor) ["FamilyRoom"] {OccupancySettings = "" [ Time = 60, VacantActions = "SceneOff,AVOff" ]}
Group gEquipFamilyRoomLights "Family Room Lights" <material:lightbulb> (gLocMainFloorFamilyRoom) ["Lightbulb"]