(Optionally) Define the physical location of a Thing

[kaikreuzer]

So far, the Paper UI allowed assigning Things to item groups, but this will be removed soon. While items (and their group association) provide the functional location, it can be useful for managing a building topology or for having some default suggestion for the functional locations, to be able to define a physical location as well for a thing.

My suggestion is to add this as a new information to a Thing, which is simply a String value, which (optionally) refers to a (group) item name. Note that this means that you won't see the things as a "member" of the group item, since only items will be available there. So for retrieving all Things within a certain location, you will need some external logic which iterates through all things. The String reference will make it easy to potentially adapt this to new concepts, in the case that something new gets introduced with https://github.com/eclipse/smarthome/issues/582.

[maggu2810]

Perhaps it is enough it is very intuitive for the user to handle the group of the items of a thing:

• mark / filter all given items to the items that are linked to channels of a given thing
• add all marked items to group ... / create a new group for all marked items

The difficult part with that string is that the information that is coded does vary (if I understood it correct). What about the parameters of a thing? Could we add something similar that are added / removed by the user instead of the binding / thing handler? We could also define some "well-known" parameter names e.g. "location".

[kaikreuzer]

What about the parameters of a thing?

I assume you mean the properties? Yes, this could be an option. Actually, it is nowhere defined that only bindings are allowed to set them - a UI can use the REST API and send an updated Thing with changed properties. So a simple solution might be to simply define "location" as a fixed property key for this purpose.

[marcelrv]

+1 for having the location as property. This is easy to integrate and fits well with the other properties +1 for maintaining tag's based on @maggu2810 idea to mark / filter all given items to the items that are linked to channels of a given thing, add all marked items to group ... / create a new group for all marked items

[kaikreuzer]

+1 for having the location as property. This is easy to integrate and fits well with the other properties

I am not convinced. The "other properties" are meant to be static information about the thing (such as its serial number, its color, etc. Think of immutable values here). The location is a user specified and potentially changing information. It is rather comparable to the "label" of a Thing. And thus, I would tend to say that similar to the label, it might be worth to specify a "real" property for the location as well. Using the Thing properties feels to be rather a comfortable shortcut as they are already there.

maintaining tag's based on @maggu2810 idea

This discussion should rather happen in the issues https://github.com/eclipse/smarthome/issues/1039 and https://github.com/eclipse/smarthome/issues/1093.

[cdjackson]

I would agree with Kai - use a specific member of the thing.

Another issue with properties is that they are flexible, which is great, but from a UI perspective, or an 'ESH concepts' perspective, may not be idea. By this, I mean that if ESH wants to have the concept of a location, then using properties, and telling UIs or bindings etc to use a property called 'location' doesn't really ensure that the concept is enforced as in reality, you can do what you like and call it something different.

[maggu2810]

Another issue with properties is that they are flexible, which is great, but from a UI perspective, or an 'ESH concepts' perspective, may not be idea. By this, I mean that if ESH wants to have the concept of a location, then using properties, and telling UIs or bindings etc to use a property called 'location' doesn't really ensure that the concept is enforced as in reality, you can do what you like and call it something different.

There are properties for e.g. serial numbers. A device does not need to have a serial, but there is a "key" constant provided by ESH that should be used for serials. So I do not fully agree. The same could be valid for location. If you do not want to use one, don't use it. If you want to use it, use the ESH provided constant key definition.

Perhaps properties are not the right place, but I would prefer not to introduce an always available field to a thing.

Locations are useful for some UIs, but for embedded systems that do not need any visualization the field is just unused.

Perhaps (that was the intention of my comment above (https://github.com/eclipse/smarthome/issues/1083#issuecomment-187690468) we could use another key / value map (as written above, there could be well known keys as already done in ESH for properties) for stuff the user could set and (for well-known keys) could be evaluated by some special UIs.

I don't think the location is such a fundamental stuff of a thing that it is a mandatory property (such as a label field) and should be available optionally.

[maggu2810]

Have to read that saref stuff....

[kaikreuzer]

Locations are useful for some UIs, but for embedded systems that do not need any visualization the field is just unused.

The very same holds true for the label. The difference between label/location and the properties that describe the Thing is for me who defines them: In the one case (properties), it is the binding, in the other (label/location) it is the user. I am not a fan of interfaces like Map<String, Object> do(Map<String, Object> params) - and using the properties for something very specific feels like doing so. Note that having an explicit field like location does not mean that this is a mandatory field - just like the label, it will still be optional.

[watou]

The difference between label/location and the properties that describe the Thing is for me who defines them: In the one case (properties), it is the binding, in the other (label/location) it is the user.

Can't a binding be allowed to update the locations of the things it manages? Why is a distinction being made between who can update the data? Some bindings can identify in which rooms its devices are located, some can identify the street address, some can identify the lat,long, etc. I worry about creating different collections of metadata depending on who or what is envisioned will be updating it.

Should users be able to link/unlink channels to these metadata fields as they do with items?

[kaikreuzer]

Can't a binding be allowed to update the locations of the things it manages?

Never - the only thing it might do is to suggest a location, but this should probably be done through tags. Note that we are talking about references to Group items here, which represent a room - these items are maintained by the user and only himself. Otherwise you will end up having 5 different living rooms, because every device has another name or definition.

some can identify the street address, some can identify the lat,long, etc.

These infos could qualify as properties on the things as they are defined by the binding. But this cannot be directly mapped to any Group item by the binding itself (we are not talking about location items here).

[maggu2810]

It seems you have already a concrete idea how it should be implemented. ;) Using the location of a thing field, will it be allowed to set multiple locations / groups for the devices? Do you plan only one location or also multiple physical locations (floor and room of a floor) e.g. room1,floor1 for thing1 and room2,floor1 for thing2 and room3,floor2? So I can filter for things of a room, things of a floor.

[kaikreuzer]

It seems you have already a concrete idea how it should be implemented. ;)

Not really, I just know that the current way (requiring an item for the Thing and assigning this item to a Group item) is not quite right and I want to get rid off it.

Do you plan only one location or also multiple physical locations

I would keep it simple and really just add a single String field to a Thing. After all, any Thing can only be at a single physical location. If there are containments (like room in floor etc.), this should be dealt with on the locations. Note that this field is merely the physical/installation location - as stated above, we still have the functional location through the items and this will stay the most relevant information.

[saerdnaer]

I would recommend an WGS84 lat/lon coordinates with floor number as third dimension in one String field. Definition of relations between spatial entities works best with set theory. Define rooms/floors/building als (planar) 3D polygon and you can simply query all things which are inside this area – probably in most cases cubes. I personally would use geodatabase extensions like PostGIS or SpatiaLite, but you really want you can also optimize at application level e.g. via geohashes.

Another questions if one should model rooms as separate entity type, or also simply as thing. Maybe adding adding a simple geometry field containing a GeoJSON string would be enough. But I'm not sure things without a binding corresponding can exist. ;-)

[sjsf]

I personally doubt that it's realistic to let every user determine the precise lat/long coordinates of each thermostat or wall switch. While it's a funny idea, it's simply not realistic to use coordinates for distinguishing between living room or toilet. Therefore, if you have movable devices that can figure out themselves where they are (being it GPS tags or whole cars...), simply continue using items for this kind of information. Regarding the location field as initially suggested, I'd also suggest to use plain String, leaving the semantics up to the platform (i.e. whether these should be user-maintained room names or whatever else...)

[kaikreuzer]

@saerdnaer As @sjka says, this issue is only about holding a reference to something that defines the location. For having precise locations in different kinds of coordinate systems, there is already the LocationItem available and there are also discussions like https://github.com/eclipse/smarthome/pull/1042 and https://github.com/eclipse/smarthome/issues/1694.

[saerdnaer]

@sjka I do not understand what's unrealistic in your point of view. Of course users will not input coordinates by numbers, they select the device position via a floor plan. There are already products like ABB-free@home where it's done in a similar way: http://new.abb.com/docs/librariesprovider84/freeathome/system-manual_free@home_en_abb_05_03.pdf -> page 20ff.

[sjsf]

@saerdnaer let's stick to strings where you maintain references to items. Your are free to use coordinates there then...

[metbril]

How would you set a location for a mobile, moving thing? Like a laptop, mobile phone or BTLE tag for my dog? These might move around the house only (so use smallest possible location 'home') or move outside as well.

And how does this location property relate to presence?

[kaikreuzer]

@rtvb Use the item name as the location reference and then update your item.

[kaikreuzer]

I am re-opening this issue in order to also add support for this new property in the Paper UI.

I would like to see two features there:

• Have a text input field on the "edit Thing" page
• Add tabs on the control UI for all different locations (use the capitalized string as a label) and keep the "ALL" tab (rename it to "OTHER") for all Things that do not have any location set.

[maggu2810]

Is the "use the item name as the location reference" something that could be done or something that should be done? If it is the common use case, I think that should be considered while changing the Paper UI.

[kaikreuzer]

As discussed in https://github.com/eclipse/smarthome/issues/1083#issuecomment-227080646, we do not have the general assumption that it has to be an item name.

Maybe we can come to such a definition, but before doing so, I would like to come to conclusions on https://github.com/eclipse/smarthome/issues/582 and https://github.com/eclipse/smarthome/issues/1093, so that it is also clear, what items (types/tags) we should filter when providing selection options in the Paper UI.

[kaikreuzer]

@aounhaider1 Thanks for #1764. One last change request on that: Could you rename the tab DEFAULT to OTHER (as mentioned in https://github.com/eclipse/smarthome/issues/1083#issuecomment-229022730) and always place it as the last (most right) tab (while sorting all other tabs alphabetically)?

[teknokill]

I'm a newbie, so I'm definitely naive to this, but I created groups in my items file for different locations in the house, but the items don't seem to be loading. When I create an item using paper UI I don't have an option to select a location. I remember adding something the other day and it had my groups in the pull-down menu. Where did I screw up? Is it because I'm not using an item from my manual item list?