-
Notifications
You must be signed in to change notification settings - Fork 782
Unify geolocation #1694
Comments
@kaikreuzer @rkoshak you are invited :) |
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:
rule:
|
I was thinking about this requirement a few time as well already. 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). |
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. |
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 We would like to store the location as a string @maggu2810 : WDYT? |
Q : Can the location be provided by a binding, for example a weatherstation with a built-in gps receiver? |
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. |
@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. |
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 ***@***.***> 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.
|
May I ask what the use case for a geofence would be? |
@kaikreuzer right indeed. Maybe we should build a OH2 version of that binding |
@triller-telekom presence of object and persons for example |
@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. |
No, I think it is just fine where it is ;-) |
@kaikreuzer no urge then to get rid of OH1 and have a consistent set of ESH/OH2 bindings? Too bad ;-) |
Yes, that is possible of course, I was just thinking of #1042 and how to generalise that with respect to PointType |
sounds reasonable for me |
Fixes eclipse-archived#1694 Signed-off-by: Stefan Triller <stefan.triller@telekom.de>
Fixes eclipse-archived#1694 Signed-off-by: Stefan Triller <stefan.triller@telekom.de>
Fixes eclipse-archived#1694 Signed-off-by: Stefan Triller <stefan.triller@telekom.de>
* Implemented unique geolocation for ESH installation Fixes #1694 Signed-off-by: Stefan Triller <stefan.triller@telekom.de>
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:
.cfg
fileThe bindings or other parts of the system (Eclipse Smarthome or openHAB) could then optionally use this setting. For example,
What are your thoughts?
(This idea started as a thread in the openHAB community forum)
The text was updated successfully, but these errors were encountered: