1a) Items - Names
In OH2 for Items I used a naming convention of (<Floor>)_<Location>_<Device/Function>_(<Specification/Property>). The parts in () are optional and only used if needed for differentiation. E.g.
-
Garage_Light: Simple case where I have only one light source in a location or
-
MF_Kitchen_Light_Door_1_Brightness: I have 6 doors that emit light in my kitchen in the main floor and this is the first of them
-
Garden_Weathersensor_Humidity: A multisensor placed in the garden with humidity, rain, … readings
For me this makes it very easy to mentally map an item to something physical. Also it’s quite searchable and makes for easy to follow entries in the log.
So I’m going to keep it this way for OH3. The only thing to note here is that the <Location> part now exactly matches the Location Groups name (minus prefix, see below).
2a) Groups - Names
In OH2 I used to have groups for categories (g_Lights), utility functions (g_Persistence_Hourly), locations (g_MainFloor) and items that somehow are grouped together (g_Kitchen_Light_Doors). All shared the same g_ prefix.
For OH3 I changed this completely because of the new semantic model. I now have:
- Groups of physical items: This is the only one identical to OH2 and starts with
g_. Example: g_Kitchen_Light_Doors.
- Groups that represent an Equipment. Those share the Items base name plus an
e_ prefix. Example: e_MF_Kitchen_Light_Door_1. This group would contain MF_Kitchen_Light_Door_1_Switch and MF_Kitchen_Light_Door_1_Brightness.
- Utility groups: Used for persistence or other utility functions like conversion of color from RBG to HSB. Those start with a
u_ prefix and then a loose description like u_Persistence_Hourly or u_Convert_HSB_to_RGB.
- Location groups for the semantic model locations. I initially wanted to prefix them with
l_ for location but this was so hard to read and easy to mix up with a capital I that I settled with r_ (room) instead, even though it is not quite accurate as a location is a brouader description than a room. But anyways it’s easily readable now. Example: r_Estate, r_MainBuilding, r_MF (MainFloor), r_MF_Kitchen.
I feel quite happy with this approach because I can quickly see what the purpose of a group is. Especially with the new Equipment groups this comes in handy.
2a) Groups - Label
- Equipment Groups: Description of the Equipment, without the room (“Ceiling Light” or “Light Door 1”).
- Location Groups: "Description of the Location, e.g. “Main Floor” or “Kitchen”.
- Utility Groups: Whatever you want, those are not displayed anywhere.
- Groups of physical Items: Plural version of the items, this time with the location because in my usage they are not ordered into the semantic model, e.g. “Kitchen Light Doors Brightness”.
What I’m struggling with in OH3
As you might have noticed, I did not include a section for 1b) Items - Labels because I’m currently struggling with this. From my perspective (maybe shaped from my daily work as a programmer) a main goal in complex systems is to avoid redundancy as much as possible (also known as DRY - don’t repeat yourself).
For the most part I can see this working very well in openHAB3 and the MainUI:
- Location(Building), e.g. “Main Building”
- Location(Floor), e.g. “Main Floor”
- Location(Room), e.g. “Kitchen”
- Equipment, e.g. “Light Door 1”
- Point, e.g. “On/Off” or “Brightness”
So the Item that is linked to the Channel would just be called “Brightness”. And this seems to perfectly fit with the automatically generated Location area in MainUI (excuse the german example, I’m too lazy to build an english one, but I think it’s easy enough to understand):
This seems to be very reasonable: Location and the parent of that Location are shown in the header, the Equipment is in the Group title and the actual points below that. All nice and clean, I love it. Especially on smaller devices (smartphone) where every unneccessary word on the screen makes it harder to read (and quite often is truncated otherwise) it is great.
But (you knew there was a but coming and it’s a rather big one 
) almost all other places seem to not agree with this labeling convention:
MainUI Devices Area:
How should I know which room we are talking abour? “Light Door 1” might still give me a clue because I only have those in the kitchen, but I have lots of equipments called “Ceiling Light”. It’s try or error hitting the right one there.
This would be fixable by including the Location (and parent location?) in the header, e.g. “Leuchte Schranktür 1 (Kitchen > Main Floor)” for the example.
MainUI Properties area:
Here it it something different again. All clues to what Equipment this is part of and what room this is part of are missing. To make amends for this, the Item Name is included instead.
While this works (especially with neat item naming conventions like mine ) I feel like this is also a lost opportunity to really make use of the semantic model.The “Location / parent Location” and the “Equipment” information could (and should imho) be displayed instead of the item name.
Google Home integration:
For the Google Home integration, the Item’s Label is used as the name displayed in Google Home as well. So “Brightness” for my examlpe. That of course doesn’t make too much sense, especially when there are multiple “Brightness” in one room (my 6 Kitchen Door Lights for example).
Manual solution: To fix this, I can include an override name like [ name=“Kitchen Light Door 1” ] in the Google Home metadata and it’s working fine, even though it’s quite some additional work.
Automatic solution (not available): This could just be derived from the Equipment and Location instead, e.g. <Location> <Equipment> <Point> would result in an acceptable “Kitchen Light Door 1 Brightness”. Google filters the room name away anyways for most purposes and a custom name could still be given.
HomeKit integration
Same problem as above but worse because the binding does not accept an easy override for the name.
Manual solution: A rather complex override for the name does exist, but you need multiple Items and a Group for it, so it gets quite complicated and results in lots of items and rules for setting the Items values to the Name that should be displayed in HomeKit. Another approach would be a Proxy Item just for the sake of changing the display name in HomeKit. This would have to be synchronized with the “MainUI Item” then.
Automatic solution (not available): See Google Home section above.
Alternative approach
So this labeling convention seems to be very logical and works great with the Location tab (which is at least for me the one I think I will spend most time in) but poorly with everything else. So you might suggest the alternative of “cram everything into every Item label”. Then we end up with labels like “Main Floor Kitchen Light Door 1 Brightness” which is neither semantic nor easy to read:
On my 32" desktop it looks manageable (though not pretty and quite redundant) but on my smartphone it is literally unusable:
Question
How do you handle this? Is there some obvious flaw in my logic?
