Google Latitude binding or integration

[GoogleCodeExporter]

Integrate Google Latitude geodata into OH to track persons/people that interact 
with OpenHAB, either locally or remote. Assume that the GL client runs on a 
mobile device held by each person. It also includes a base framework for 
geofencing, or location definitions, that could be coupled and checked with 
People's positions. Lastly, it could entail integration in the OH core 
rule/script engines

Original issue reported on code.google.com by karel.go...@pharco.be on 25 Aug 2012 at 5:53

[GoogleCodeExporter]

Original comment by kai.openhab on 26 Aug 2012 at 7:34

• Changed state: Accepted

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Hi - I have just 'pushed' my first ever change - 
https://code.google.com/r/benjones12-latitude/. It has the implementation of my 
Google Latitude binding I have been working on this weekend. Let me know if I 
have done anything wrong! Or if you have any feedback etc. Cheers, Ben

Original comment by ben.jone...@gmail.com on 5 May 2013 at 5:30

[GoogleCodeExporter]

Original comment by kai.openhab on 5 May 2013 at 8:35

• Added labels: Version-1.3.0
• Removed labels: Version-later

[GoogleCodeExporter]

will do :-) Thanks for driving this issue ... please let us know when you are 
ready for feedback.

Original comment by teichsta on 5 May 2013 at 10:08

[GoogleCodeExporter]

I am curious to see the geofencing work. Early tests I did with the iPhone made 
me feel that this will be a hard feature to implement, due to the limitation of 
the device. Sometimes my position was "in the fence" when being more than 100m 
away from the fence (when approaching the fence). Not very useable for presence 
detection and so forth. /me thinks that the best solution will take a 
combination of technologies (KNX PIR, Google Lattitude,...) to root out false 
positives. 

Original comment by karel.go...@gmail.com on 5 May 2013 at 10:12

[GoogleCodeExporter]

to continue my previous point, and as suggested a long time ago, we might need 
a more general framework that sits above the bindings to deal with presence and 
so forth...

Thomas, maybe time to extend the OH Bus Protocol to incorporate that? 

Original comment by karel.go...@gmail.com on 5 May 2013 at 10:14

[GoogleCodeExporter]

maybe it's time, right, but let's first start with the binding ...

Original comment by teichsta on 5 May 2013 at 10:17

[GoogleCodeExporter]

It seems to work pretty well on my iPhone - although I have only tested leaving 
the house once. I have the geofence set to 50m and generally speaking I am 
reported as being within 15-20m. The critical issue is how often does openHAB 
request your location. Obviously the more often, the quicker your 'presence' 
will be detected. However it is a reasonably slow process to request the 
location - 2-3s at times by the time the request to the Google servers comes 
back - and thus you don't want to have openHAB continuously polling.

My thoughts were along the same lines as you Karel - to build 'presence' rules 
based around motion and Latitude states. But I think Teichsta is correct - for 
now it is best to get the binding working properly and then build on it from 
there.

I have started to abstract out the Google authentication stuff as there was 
talk of adding this as a core module to openHAB - so that other parts of the 
system can easily implement OAuth type authentication.

Is this worth continuing with? Or should I just leave it inside the Latitude 
binding for now?

Original comment by ben.jone...@gmail.com on 5 May 2013 at 8:34

[GoogleCodeExporter]

I have just pushed some changes which abstract out the Google OAuth 
authentication into a single class. This handles saving/loading tokens against 
a specified key (in my case the key for the Latitude binding is the email 
address).

I think this can be pulled out and added to core if you are happy with it. All 
you need to pass in is a key to uniquely identify what item/'thing' you are 
authenticating, and the list of 'scopes' you want authentication for - e.g. for 
Latitude I just need LatitudeScopes.LATITUDE_CURRENT_BEST.

A Credential object is passed back once successful and this can then be used to 
build services of the desired type. See the Latitude binding for an example.

I can't see why this can't be used for anything that requires OAuth 2.0 
authentication, but I haven't tried with anything by Latitude.

Original comment by ben.jone...@gmail.com on 5 May 2013 at 11:42

[GoogleCodeExporter]

Ben, this sounds really great, thanks for doing the refactoring - I am sure the 
OAuth stuff will become more and more important for many kinds of services in 
the future.

Original comment by kai.openhab on 6 May 2013 at 8:52

[GoogleCodeExporter]

Cool - I just pushed a further change as the GoogleOAuth class was incorrectly 
generating a Latitude specific GoogleClientSecrets object. This is now passed 
into the authentication code. GoogleOAuth also has a couple of public helper 
methods for building/loading the client secrets details. Should be ready for 
prime time now hopefully!

Original comment by ben.jone...@gmail.com on 6 May 2013 at 9:44

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Original comment by teichsta on 21 May 2013 at 9:27

[GoogleCodeExporter]

Original comment by kai.openhab on 2 Jul 2013 at 8:25

• Changed state: ReadyForReview

[GoogleCodeExporter]

How are we going to proceed with this binding since Google stopped their 
Latitude service? 

Original comment by teichsta on 25 Jul 2013 at 10:28

[GoogleCodeExporter]

I have been talking to the founder of EchoEcho. It looks like this could be a 
viable alternative, although I do agree with someone who posted a comment in 
discussion group saying it would be better to integrate this sort of location 
detection in the native iOS/Android apps.

Since that is outside my area of expertise I will focus on getting EchoEcho up 
and running. Unfortunately their API isn't complete yet so it is not going to 
be a solution for the general public just yet. The EchoEcho app generates 
'secret' password when you sign up to the service. There is currently no way to 
obtain that password via their API. I have had to ask the EchoEcho founder to 
look mine up and send it through.

Now I have that I should be able to knock up a binding to send the necessary 
requests to the API to get my location in real time.

The current thinking is to make the binding a bit smarter and allow you to 
specify refresh interval thresholds. So if your last location is > 20km from 
home then openHAB will only poll every 30mins. If your next location is found 
to be < 5km from home the refresh interval will drop down to 5 mins for example.

This should reduce the number of polls, until you start getting close to home 
when it will ramp up and ensure more accurate location detection. Once inside 
the 'home' geofence the refreshing will drop back to something like 10mins.

I am hoping to have a crack at this over the weekend...stay tuned for a new 
'Echo' binding!

Original comment by ben.jone...@gmail.com on 25 Jul 2013 at 10:40

[GoogleCodeExporter]

thanks for this update!

Would you then agree to reject/close this issue because it is no longer 
relevant?

Regarding LBS. I could give access to our Glympse-Account. They have a well 
documents REST API. Victor did some investigations already. Do you think 
Glympse would suite your needs as well?

Original comment by teichsta on 25 Jul 2013 at 10:49

[GoogleCodeExporter]

Yeah probably just reject this issue I guess since my Latitude binding will 
never see the light of day (in the main branch).

I will have a look at Glympse - I did check it out briefly and for some reason 
thought Echo would be better.

Original comment by ben.jone...@gmail.com on 25 Jul 2013 at 11:09

[GoogleCodeExporter]

Before rejecting this issue, we should not forget about the work Ben did 
regarding the Google OAuth - we will need this for other services like GCal and 
Drive, so we need to make sure to integrate that into the main repo.

Original comment by kai.openhab on 26 Jul 2013 at 6:26

[GoogleCodeExporter]

Well it seems EchoEcho is a non-starter and from what I can see Glympse is also 
not suited to this type of location detection. Neither allows a third party app 
to 'request' a users location, and or allow a third party app to retrieve user 
locations without the user explicitly 'sending' it.

Someone mentioned that this type of presence detection should be moved into the 
iOS/Android openHAB apps and I tend to agree. That is the most sensible place 
for this stuff to live. The idea would be the apps have a configuration 
parameter which is the lat/long of your house. Then it would track the phones 
location and send REST API updates to openHAB to indicate when the phone is 
within a specified geofence.

The apps could be a bit smarter and have location update thresholds. So if you 
are > 20kms away the app only polls your location every 20mins. Once you get 
closer than 5km it would start polling every 5mins. This would mean fewer polls 
yet a very accurate/quick presence detection once you get close to home.

Once inside the geofence it could revert to 10min polls or something.

I have zero experience writing iOS or Android apps so this would be well 
outside my field of expertise. But I think this is probably going to be the 
best way to solve this issue.

Original comment by ben.jone...@gmail.com on 30 Jul 2013 at 1:34

[GoogleCodeExporter]

Original comment by teichsta on 13 Aug 2013 at 3:38

• Removed labels: Version-1.3.0

[GoogleCodeExporter]

Original comment by teichsta on 5 Nov 2013 at 10:47

• Added labels: To-Github

[GoogleCodeExporter]

This issue has been migrated to Github. If this issue id is greater than103 its 
id has been preserved on Github. You can open your issue by calling the URL 
https://github.com/openhab/openhab/issues/<issueid>. Issues with ids less or 
equal 103 new ids were created.

Original comment by teichsta on 17 Nov 2013 at 8:08

• Added labels: Migrated-To-Github

[GoogleCodeExporter]

see above!

Issue has been migrated to Github and should be discussed there.

Original comment by teichsta on 21 Nov 2013 at 1:51

• Changed state: Invalid