My question or problem is now related to the overview page in the main ui
If I open the tab “places” I can see the following widgets with their related items inside
Kitchen (Groundfloor)
Ceiling lamp
Blind
Livingroom (Groundfloor)
Ceiling lamp
Couch lamp
Blind
Room (Groundfloor)
Ceiling lamp
Blind
this makes totally sense so far.
If I open now the tab “devices” I see the following widgets with their related items inside
Lights
Ceiling lamp
Ceiling lamp
Ceiling lamp
Blinds
Blind
Blind
Blind
which is more or less not usable.
I could add the location name to the label of the equipment like Ceiling lamp (Livingroom). But this would look weird if I open the “places”, because every equipment inside the “livingroom” location with have the suffix (Livingroom)
I think, one solution could be to
show the location somewhere inside the “devices” tab widgets as a suffix after each equipment automatically.
What do you think. Maybe my way how I labeled everything is wrong.
For OH, “best practice” type questions tend to get answered with a lot of “it’s different for every user”. You’re absolutely correct that you have to have a priority, or at least a balance, between sensible labels for points based on either the equipment/location tabs or the properties tab. What that priority or balance is, however, really does depend on your usage.
I, personally, am in the balance camp because I use different types of points in different ways. For example, my front door:
I don’t mind in this equipment view that three of the points are labeled identically as “Front Door”, the icons and state values make it pretty clear which is which. As I track the status of dozens of batteries in a single widget, each battery point has to be clearly identified, but I have few enough locks, and they are incorporated in custom widgets in such a way that the “Lock” label makes more sense in this this case.
Convention, particularly where item labels are concerned doesn’t have to mean a single rigid rule. An effective item naming convention can have several different, sensible, sub-conventions for different types of items.
Correct. It’s also not going to be usable in other locations where the list of Items is shown like the Item’s Settings page, the Developer Sidebar, rule triggers, etc.
You will have to decide what is more important to you: having the location not be a part of the label making the Locations tab look nicer, or include the location as part of the label so the Item labels work everywhere else in OH.
If the former is more important to you, then you will have to live with the problem you’ve outlined when ever looking at the other tabs in the Overview page as well as when working with Items in other parts of OH beyond the Overview page. If the latter, you’ll have to live with some redundant information in the Locations tab.
Ultimately all use cases cannot be supported perfectly all the time. For now, to really be usable and findable in all places, Item labels need to be unique. But if you don’t care about those other places it doesn’t really matter.
For me, the UI is secondary. No one in the house uses it and I only use it as a dashboard to quickly see what’s going on when something does wrong. So it’s far more important that each Item is easily findable and recognizable when building rules.
Finally, there is not and never can be infinite customizability of automated generated stuff like the Overview Pages. If what it generates is not suitable, you have the option to hide those tabs and build a custom set of Pages that look and work exactly how you desire.
thanks for all the explanations. Currently I’m experimenting with my fresh migrated openhab setup to find out what is the best way for me to go. i think I will stay with the current setup and will use the location tab.
btw. the migration from openhab 2 to openhab 3 (incl. all my python rules) was way easier than my migration from openhab 1 to opengab 2 long time ago.
the biggest effort I have to spend this time was the rewrite of all my joda time based logic. But now as it is based on java.time it is prepared for the future
thanks again to everyone who helped to make openhab to what it is. From my opinion, to the most powerful, stable and well designed smarthome platform ever!
