Unify geolocation

[metbril]

Several bindings require a geolocation to work. Some require the system's location (Astro) while others require any (nearby) location (Weather).

Instead of providing the same latitude and longitude (and altitude etc.) over and over again, I was thinking if this could not be set globally once for the entire installation.

I have come up with these options:

• Make these a setting that can be managed through Paper UI (much like locale)
  • manually enter lat/lon
  • compute at request through the browser (like many geo aware websites do these days)
• Provide it through some .cfg file
• Compute in real time (e.g. at system start) so that if I move my installation the new geolocation is automatically determined and available for use.
• Create a binding that determines this

The bindings or other parts of the system (Eclipse Smarthome or openHAB) could then optionally use this setting. For example,

• if set, force its use or
• use it as a default if not explicitly overwritten through the binding configuration What are your thoughts?

(This idea started as a thread in the openHAB community forum)

[metbril]

@kaikreuzer @rkoshak you are invited :)

[watou]

If there were a "structure" or "smarthome" thing type, and these things had configuration and channels for address, lat/long, home/away status, total energy usage and other attributes of a structure, the existing mechanisms in ESH could be used (including all the config UI). You would just have ESH come with (or just a simple binding) the built-in ability to model a SmartHome Thing itself, and the first order of business after installing an ESH solution would be to create your SmartHome Things ("apartment", "lakehouse", etc.). Then the only remaining question is how to allow all the code that wants to know location, home/away, etc., for a given structure/smarthome thing, to get it. So instead of inventing a new way to model the problem, use the existing way but make sure your use cases are met.

In the meantime, only using an item and rule to guess your lat/long based on public IP address (if you're connected to the Internet).

item:

Location home

rule:

rule SetHomeLocation
when
  System started
then
  if (!(home.state instanceof PointType)) {
    val String geoipString = sendHttpGetRequest("http://freegeoip.net/json/")
    val DecimalType lat = transform("JSONPATH", "$.latitude", geoipString)
    val DecimalType long = transform("JSONPATH", "$.longitude", geoipString)
    home.postUpdate(new PointType(lat, long))
  }
end

[kaikreuzer]

I was thinking about this requirement a few time as well already. I usually also tried to think along the lines of @watou and would say that we can already define locations with Location items and potentially mark them with suitable tags as a "home". To be generic, this would also allow the option to have multiple "home locations", because you might actually have a distributed setup and not necessarily only one center of the universe.

But then again, in probably >95% of the cases there is exactly one home and getting the location should be as simple as possible for the user, i.e. without having to create items first etc. - setting it through the browser is imho a very elegant solution. Furthermore, the services that require the location are mainly discovery services, which are not expected to directly access the item registry. From this perspective, I think introducing it as a configuration through the config admin service might be a good option. This allows defining it statically in a .cfg file as well as manually defining it in the Paper UI (or building mechanisms to automatically set it from the browser through a REST request, if it isn't yet set).

Something very similar has recently added by @maggu2810 with the LocaleProvider. I wonder if these two features should even be combined - if not set, we could also derive a locale from the current location (or also set it by the browser, dependent on its locale).

[rkoshak]

Taking a step back, does it make sense to make this mechanism more generic and not location specific? Are there other configuration parameters that are needed across multiple bindings etc. that could benefit from having a "set once and reference multiple times?"

I'm sure this greatly complicates the problem but thought I'd throw out that idea for consideration.

[triller-telekom]

Since this issue is now on our roadmap to be implemented, I just had a discussion with @kaikreuzer about how to proceed. The outcome of our discussion is as follows:

Since Locale and Location are somehow "related" we thought about adding a location to the existing LocaleProvider. This way we would store the location also with config admin and it will be available to all bindings. In a second step we could then have a Welcome page for users where they can set their homelocation via a pin on a map widget and if the user does not select a locale we could derive one from the set locale.

We would like to store the location as a string lat,long,alt, which is the most basic definition for a location where other types can be derived from. We could even provide a PointType from this to others. If a binding like the yahoo weather binding needs a woeid as a location it would be responsible of doing the conversion on its own, or if it somehow cannot do it, provide a configuration parameter as it currently does.

@maggu2810 : WDYT?

[kgoderis]

Q : Can the location be provided by a binding, for example a weatherstation with a built-in gps receiver?

[triller-telekom]

Interesting question. This feature is meant to be one that is provided as a system service to everyone and configured ONCE through the user at start-up. It can be changed later, i.e. if the user moves the installation somewhere else, but it is meant to be a rather static value.

A binding should not set any core configuration parameter, so the answer to your question would be no. However, one could think of "enhancements" of the dialog the user uses to set the location, so he could choose the location to be taken from a gps receiver. Bus this would obviously be the "change location" dialog as the connection to such a gps receiver has to exist. The wizard for the initial setup could not use it.

[kaikreuzer]

@kgoderis I was just remembering the ConfigAdmin Binding of openHAB 1 - this can actually be used to make a binding push information into the ConfigAdmin.

[kgoderis]

Can the concept be extended with a radius so that we have a geofence definition?

Sent from my iPhone

On 18 May 2017, at 17:30, Stefan Triller notifications@github.com wrote:

Interesting question. This feature is meant to be one that is provided as a system service to everyone and configured ONCE through the user at start-up. It can be changed later, i.e. if the user moves the installation somewhere else, but it is meant to be a rather static value.

A binding should not set any core configuration parameter, so the answer to your question would be no. However, one could think of "enhancements" of the dialog the user uses to set the location, so he could choose the location to be taken from a gps receiver. Bus this would obviously be the "change location" dialog as the connection to such a gps receiver has to exist. The wizard for the initial setup could not use it.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[triller-telekom]

May I ask what the use case for a geofence would be?

[kgoderis]

@kaikreuzer right indeed. Maybe we should build a OH2 version of that binding

[kgoderis]

@triller-telekom presence of object and persons for example

[triller-telekom]

@kgoderis : Why do you need a radius on the location for this scenario? If you want to calculate whether a person with position latX,lonY is within Z meters of the location you could calculate the distance between the 2 and at this place where you do this calculation you can also have the "radius", i.e. the max distance that you accept.

[kaikreuzer]

Maybe we should build a OH2 version of that binding

No, I think it is just fine where it is ;-)

[kgoderis]

@kaikreuzer no urge then to get rid of OH1 and have a consistent set of ESH/OH2 bindings? Too bad ;-)

[kgoderis]

If you want to calculate whether a person with position latX,lonY is within Z meters of the location you could calculate the distance between the 2 and at this place where you do this calculation you can also have the "radius", i.e. the max distance that you accept.

Yes, that is possible of course, I was just thinking of https://github.com/eclipse/smarthome/pull/1042 and how to generalise that with respect to PointType

[maggu2810]

@maggu2810 : WDYT?

sounds reasonable for me