[boschshc] Update location properties when initializing things #17893
Conversation
When a device is initialized, an attempt is made to look up the room name for the room id specified for the device and to store the room name in a thing property. This property is also updated if a room change is detected. The legacy property `Location` is removed if present. From now on the property `location` (with proper lower case spelling) is used. * add constants for location properties * implement location updates in abstract device handler * extend bridge handler to provide a cached list of rooms * add unit tests Signed-off-by: David Pace <[email protected]>
david-pace
added
the
bug
| if (currentLocation == null || !currentLocation.equals(roomName)) { | ||
| logger.debug("Updating property '{}' of thing {} to '{}'.", PROPERTY_LOCATION, getThing().getUID(), | ||
| roomName); | ||
| updateProperty(PROPERTY_LOCATION, roomName); |
There was a problem hiding this comment.
@jlaur I have a general conceptual question on this change: we store the room names in which devices are located in a thing property, which used to have the non-compliant spelling Location, and was now changed to location starting with a lower case letter.
My question is whether a thing property is the correct place to store this in general, because I looked at properties of other things and found that they are usually quite technical / hardware-specific. It this the right place to store location metadata, or do you have better ideas?
There was a problem hiding this comment.
Sorry, I forgot about this again after receiving an e-mail notification amongst many. Can you provide an example of a location, and perhaps more importantly, what is the use-case of having it?
There was a problem hiding this comment.
Hi @jlaur,
no problem, this PR is not time-critical, as it does not affect the actual thing/channel logics. It is kind of in between a bug and an enhancement 😉 I'm grateful for your support in any case.
The Bosch Smart Home system allows users to manage their rooms and to assign devices to rooms. For example, users can specify that window sensor A ist located in the living room and that smoke detector B is located in the dining room.
Internally, each room has a somewhat cryptic ID (like hz_1), and a user-provided name. Users will usually assign a name in their native language. So the actual name of hz_1 might be Living Room or Wohnzimmer.
In rare cases, for example if devices are repurposed or moved, the room assignment might change. This is not reflected in openHAB so far.
Behavior before this PR:
- Things that are found during discovery have a thing property called
Location. The value is the "resolved" room name (e.g.Living Room) - If the location/room changes, this is not reflected in a thing property change.
Behavior with this PR:
- If a thing has a property called
Location(with upper caseL), the property is removed. - Things that are found during discovery have a thing property called
location(note the lower caselto comply with openHAB naming guideline). The value is still the "resolved" room name (e.g.Living Room) - If the location changes or if the
locationproperty is not present yet, the thing propertylocationis updated with the new "resolved" room name (e.g.Kitchen)
The question is whether a thing property is the right place to store room names at all.
When a device is initialized, an attempt is made to look up the room name for the room id specified for the device and to store the room name in a thing property. This property is also updated if a room change is detected.
The legacy property
Locationis removed if present. From now on the propertylocation(with proper lower case spelling) is used.closes #16599