Closed GoogleCodeExporter closed 8 years ago
Original comment by kai.openhab
on 26 Aug 2012 at 7:34
[deleted comment]
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
Original comment by kai.openhab
on 5 May 2013 at 8:35
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
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
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
maybe it's time, right, but let's first start with the binding ...
Original comment by teichsta
on 5 May 2013 at 10:17
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
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
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
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
[deleted comment]
Original comment by teichsta
on 21 May 2013 at 9:27
Original comment by kai.openhab
on 2 Jul 2013 at 8:25
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
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
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
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
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
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
Original comment by teichsta
on 13 Aug 2013 at 3:38
Original comment by teichsta
on 5 Nov 2013 at 10:47
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
see above!
Issue has been migrated to Github and should be discussed there.
Original comment by teichsta
on 21 Nov 2013 at 1:51
Original issue reported on code.google.com by
karel.go...@pharco.be
on 25 Aug 2012 at 5:53