Is "Location" in a Thing still used for anything in OH3?

Is the “Location” attribute in the Thing details still used for anything? I know that in PaperUI it was used for the “Control” section, but with MainUI and the new “Model” area for structuring locations I don’t get why this still exists. Can someone enlighten me? :slight_smile:

This is the place I’m talking about:

Locations tab at bottom of the main page?

How is it used there? I have not entered any “Location” value for a thing and my locations tab looks like this (all values come from the “Model” settings):

I thought Location was part of the semantic model.

There are - as far as I can see - multiple locations:

Semantic Model (MainUI: “Model”):

  • Location
  • Point
  • Property
  • Equipment

Things (MainUI: “Things”):

  • Location

The “Location” from the semantic model is technically a parameter on a Group Item (defined in .items file if you don’t use the MainUI).
The “Location” from the Things is a parameter on the Thing (defined in .things file if you don’t use MainUI).

So this is obviously not the same and there are multiple places to set a “Location” which is exactly why I’m confused.

IMHO the locations in the OH3 location has nothing to do with the location settings of the (file created?) things. The former shows items at locations, the later only things.

I agree that these seem to be different things. But the question remains: Is there anything the “Location” set in the Things (created with files or MainUI, doesn’t matter) does in OH3?

I created my OH3 locations via the semantic modell, that way the location of things didn’t get set. Can’t say if a thing with a location is (together with its linked items) somehow automatically set in the semantic modell.

No, not really.

No, that’s controlled by the model. The model only applies to Items. This is a location on the Thing and as far as I know it’s not used any more.

It’s a parameter in UI created Things too.

1 Like

I’ve asked myself the same. I found no use of it in openHAB3 so far.

In openHAB2 it was used to bring some sort of structure in the control part of the PaperUI. All things in the same location were placed in the same tab there.

This feature is now provided by the semantic location but for items in the location cards.

So if you like: The first was meant as the physical location of a thing (e.g. a multi-channel actor installed in the basement providing channels linked to items for multiple locations) while the semantic location associates a linked item to a location in the model

Means: Beyond some “documentation” use, I don’t see any benefit from the “Location in Things Settings” and stopped maintaining it in my setup.

1 Like

Hasn’t it been right that ever ?

What? … No.

It has provided functionality - namely an reasonable option to organise your things in PaperUI’s control section:

And: I’m pretty sure Markus, you were fully aware of it :wink:

I should add:
“Location” is part of the “thing” data structure/class. Since the “things” have not changed between openHAB2 and openHAB3 it is still part of the data structure. As long as openHAB3 does not make more use of it, it just appears beeing a “leftover”.

But who knows?
Frankly, e.g. the looooong list of things may benefit from the physical location as third distinguisher/sort criteria in the UI (beside “Alphabetical” and “By Binding”)…

TBH, no.
That “user” part in PaperUI has ever been a little obscure to me. Never really used it, and few others did.

Allright, so the current state is:

  • It was somehow a little bit useful in OH2 only for PaperUI
  • PaperUI is now gone and it’s not used for anything else in OH3

Since it is confusing (see this thread for examples) and has no apparent use, I will open a Github issue for further discussion what to do with it so that this doesn’t get lost in the depths of the forum.

I see quite some options here:

  • Add the text “(deprecated)” next to it in the UI
  • Add a description stating that this is not to be confused with the semantic model and should represent the physical location where the thing is installed
  • Only show it for old things in the UI where the field has a non-empty value
  • Hide it behind some “show advanced” button like it is done for the less used channels or metadata entries
  • Completely remove it from the UI
  • Keep it and use it in the thing overview as another thing the list can be filtered by (like @curlyel suggested)
  • Completely remove it from OH Core

Personally I would vote for a complete removal from OH or at least from the UI. That way the least confusion is caused and as I understand one goal of openHAB 3 is to be more attractive to novice users. Those can be confused most easily :wink: Since it’s not used for anything, backwards compatibility shouldn’t be a problem here. Though maybe it’s exposed through the API and some 3rd party app or addon uses it for… something. Then I’d probably go with the “show advanced” button in combination with a rename to “Physical Location” and a description that it has nothing to do with the semantic model.

But of cause that’s not my decision to make so I think a discussion in Github to get the maintainers take on this will be beneficial.

3 Likes

Fully agree :+1:

Some thought though:

… in general: YES. Technically these are different.

But: The physical location of a thing could serve as default source to derive the semantic location from.

For quite some items, the physical location of thing were the items are linked to and the semantic location will be same.

Think of a temp/hum sensor thing. The physical device will be placed in a room and the channels provide temperature/humidity properties for exactly this room.

If this is case, “location” just needs to be set per thing. All items linked to channels of this thing may inherit the location and get it assigned in the metadate implicitly.

Location metadata just needs to be modified when the above is not true.

This might ease the setup of the model a bit… :wink:

I think it’s an interesting idea to use this as a default source, but I also see some drawbacks:

  • it adds another layer / concept that new users have to get used to
  • There are some difficulties with the details of this:

For the Thing>Location we have one string field. But the semantic model location is technically a group and has at least a Name and a Label (together with some more attributes). Which should this be linked against? You could also have multiple Locations with the same Label, e.g.

Main floor > “Bathroom”
Second floor > “Bathroom”

So that leaves the Name. But that might be more cryptic, e.g. it would be r_House_EG_Bad for me in the example and thus more prone to input errors. We’d need an autocomplete for that at least.

Anyways I opened the Github issue here:

Fair point.
Only unique option would to take the groups item name here.

Well, you’re right: It may hurt more than it heales… :wink:

1 Like