GPS presence detection and notifications inside the iOS and Android Apps

[GoogleCodeExporter]

1. Feature Description

Presence detection was done using Latitude that Google regretfully 
discontinued. (See https://code.google.com/p/openhab/issues/detail?id=108). 
Notifications are done using Prowl and NotifyMyAndroid, but this feels somewhat 
clumsy to have a separate app for that.

So i'd like to propose to build presence detection and notifications into the 
iOS and Android apps. I'm willing to contribute to the effort. I've written 
both server side notification code and location services code on both iOS and 
Android for other projects.

2. Example Use Case

Use your phone or tablet with GPS function to handle presence detection. Get 
notifications from OpenHAB inside the iOS and Android Apps. Notifications could 
contain data to open specific sitemaps or frames inside sitemaps.

Original issue reported on code.google.com by jwsp...@gmail.com on 19 Sep 2013 at 10:14

[GoogleCodeExporter]

I also thought about integrating notifications directly into HABSweetie. 
Enabling openHAB to send C2DM messages to googles servers shouldn't be too 
hard. But we need an easy process to let the user configure this. There some 
IDs to setup and send around between the client and openHAB.
It would probably be better to wait until at least the REST interface is 
easyily extendable so we can add an API for this.
Same goes for location of the user. At least in Android it is easily possible 
to get reasonable accurate location without draining the battery in reasonable 
short intervals. But we need an API endpoint to deliver this information.
But if you are using Android you could use HABSweetie and Tasker to achieve GPS 
based presence. It is working fine for me.

Original comment by till.klo...@gmail.com on 19 Sep 2013 at 3:14

[GoogleCodeExporter]

It's actually not for me. I've got presence detection working trough GPS with 
an app that my company is producing (totally unrelated to openHAB) so I have my 
location anyway, but that doesn't benefit anybody else but me.

Original comment by jwsp...@gmail.com on 19 Sep 2013 at 6:49

[GoogleCodeExporter]

Nice project BTW, HABSweetie. It's an alternative to HABDroid? HABDroid is 
great for phones, but a bit less suitable for a tablet. (Same is true for the 
iOS app).

Original comment by jwsp...@gmail.com on 19 Sep 2013 at 6:52

[GoogleCodeExporter]

Thanks, I hope that I can release HABSweetie in the next weeks to the public. 
There are still some minor bugs left and I need a good icon as subpage 
indicator. But apart from that everything seems to be running fine.

Probably Thomas or Kai can tell us something about the plans to make the REST 
interface extendable. If that is done it should be easy to at least integrate 
notifications. For geolocation we probably also need a new item type.

Original comment by till.klo...@gmail.com on 20 Sep 2013 at 7:44

[GoogleCodeExporter]

Just saw this now. I totally agree with you JwS. I have already pushed for 
integrating presence detection inside the openHAB apps but the argument against 
was the fact we would be reinventing the wheel since there are many existing 
apps/services offering this type of thing. Since I don't have any experience in 
either iOS or Android development I am don't really have much to offer 
unfortunately. I think leveraging off your experience in this area would be 
great! 

I currently have the Mqttitude app installed on my phone, an MQTT broker 
running on my server, and the Mqttitude binding running on openHAB - just to 
track my presence! This is the third attempt after writing the Latitude and 
OpenPaths bindings. It all seems far too difficult and shouldn't be this hard, 
for something so important to home automation. 

I didn't think of the notification side of things - that sounds like a smart 
move also. The more integrated this stuff is the better. 

If there is there anything I can do to help with your work in this sing out!

Original comment by ben.jone...@gmail.com on 3 Oct 2013 at 4:28

[GoogleCodeExporter]

Had a another thought about this...it seems the built in location APIs of 
mobiles tend to only report location changes when you move 'x' number of 
metres. I think for iOS it is 500m, not sure how it works with Android. I 
thought it was also time based, but I am not seeing this with Mqttitude on my 
fiances iPhone 4S running iOS7. Once her phone stops moving all updates seem to 
stop. Again, not sure if this is due to the iOS location API or the Mqttitude 
app itself.

However this is a problem for presence detection. Say I have a 100m geofence 
configured around my home, and my fiance is on her way home. If iOS updates her 
location when she is 250m from home the Mqttitude binding correctly calculates 
her as being outside the geofence. However when she arrives home she hasn't 
moved far enough for iOS to send another update so openHAB never 'knows' she 
has arrived. I saw this last night - the last update was at 183m from home, but 
the phone never sent another update until she left for work this morning. I.e. 
moved more than 500m from her last location update, this time away from home!

What I would like to propose is a 'smart' system of updating location from 
inside the openHAB apps. We would need to store the lat/lon of 'home' - as I do 
currently in the presence detection bindings - then the location logic would 
send updates more frequently, more accurately, the closer you get to 'home'.

So if you are more than 100km from home for example, you would only send 
updates every hour and/or a change of location of more than 10km. If you are 
between 10km-100km you might update every 10 mins and location deltas of 1km. 
As you get closer the app will check you location more frequently and update 
openHAB accordingly. 

This would mean a reduced load on the location polling and openHAB updates when 
you are a long way from home, and clearly not very interesting to openHAB. 
However once you start getting closer openHAB is informed more regularly and 
more accurately so it can detect when you get inside that geofence as quickly 
as possible.

I have no idea if this is even possible using the Android/iOS location APIs but 
this type of location tracking would be the most useful for openHAB I believe. 
Since we don't really care where you are once you are away from home, we just 
care whether you are 'at' home or not.

Thoughts? 

Original comment by ben.jone...@gmail.com on 4 Oct 2013 at 1:02

[GoogleCodeExporter]

It's actually configurable in the iOS api. There is a distance filter that you 
can set from none to anything. Same for accuracy. So it's really up to the 
programmer to set that.

Original comment by jwsp...@gmail.com on 4 Oct 2013 at 7:55

[GoogleCodeExporter]

I'd say your suggestion is very useful. A more sensitive distance filter uses 
more battery (more events), but at home the phone would mostly be on the 
charger. And GPS doesn't have to be always on.

Original comment by jwsp...@gmail.com on 4 Oct 2013 at 7:58

[GoogleCodeExporter]

You could get quite smart, or at least provide the option, so that when the 
phone connects to wifi it stops broadcasting location updates. Would imagine 
95% of openHab users will have wifi at home, and you only really need to detect 
location changes, which is not going to happen when on wifi, even if not at 
home. I think we could make the logic pretty smart, with not too much 
difficulty, to conserve battery use and save unnecessary location requests.

Original comment by ben.jone...@gmail.com on 4 Oct 2013 at 8:06

[GoogleCodeExporter]

You can get the SSID of the wifi network using the Captive Network API. So once 
the phone detects the local wifi network, GPS can be turned off.

Original comment by jwsp...@gmail.com on 4 Oct 2013 at 8:15

[GoogleCodeExporter]

Sounds like a very useful addition to openHAB. Wish I could contribute more!

Original comment by ben.jone...@gmail.com on 4 Oct 2013 at 8:29

[GoogleCodeExporter]

Going to have a look at the HABDroid code (once I find out where it is stored 
these days!) and see if I can have a go at adding some of this logic to the 
openHAB app. I have been doing some reading and it looks like Android already 
has an API for what we are trying to do - 
http://developer.android.com/training/location/geofencing.html. So I am hopeful 
it might be quite straightforward to add. I don't have a Mac so will have to 
leave the iOS side of things to someone else...

JwS - have you come across this API in your travels? Is it going to be suitable 
as far as you know?

Original comment by ben.jone...@gmail.com on 6 Oct 2013 at 4:54

[GoogleCodeExporter]

That looks perfect. I see that iOS has added geofencing to it's api last year. 
Didn't know that. That will make it even easier. Let me know when you're done, 
also on the REST side. I can do iOS.

Verstuurd vanaf mijn iPhone

Original comment by jwsp...@gmail.com on 6 Oct 2013 at 8:18

[GoogleCodeExporter]

I am thinking of something pretty simple first up. Specify the 'home' lat/lon 
and geofence (radius) and finally the openHAB item to update. Then using the 
geofence API it should be a simple case of trapping the in/out events and 
updating the openHAB item.

You have any further thoughts? Anything else I should be considering?

Original comment by ben.jone...@gmail.com on 6 Oct 2013 at 8:55

[GoogleCodeExporter]

Also, do you know where the HABDroid source is located now?!

Original comment by ben.jone...@gmail.com on 6 Oct 2013 at 8:55

[GoogleCodeExporter]

No idea about the Habdroid source. Victor knows ;-)

Original comment by jwsp...@gmail.com on 6 Oct 2013 at 8:57

[GoogleCodeExporter]

@ben.jones12
You could also have a look at HABSweetie. The reason I started an alternate 
Android client was to provide a little better structured code 
(https://github.com/dereulenspiegel/HABSweetie).
If we have an API endpoint to post a location to it should be fairly easy to 
implement a BroadcastReceiver which receives the current position and posts 
this information to openHAB. Something similar is already implemented for the 
Tasker extension.

Original comment by till.klo...@gmail.com on 6 Oct 2013 at 9:08

[GoogleCodeExporter]

Cheers Till - I have downloaded the Android SDK but have no idea how to 
configure it for HABSweetie (which I have forked from your repository). I am a 
complete beginner when it comes to Android app development. I will have another 
go tomorrow and see if I can come up with some specific questions to help me 
get started!

BTW - I have tried HABSweetie before and found it to be a little unstable. 
Whereas with HABDroid I haven't had many issues, hence my inclination to start 
with that. Have you been making steady changes to HABSweetie? When do you think 
it will be ready for v1.0 release?

Original comment by ben.jone...@gmail.com on 7 Oct 2013 at 4:43

[GoogleCodeExporter]

HABSweetie is not really a standard Android project as Google intended it. I'm 
using Maven to build it. This brings some advantages like dependency 
resolution, but also some disadvantages since the Maven integration in Eclipse 
could be better.
All projects HABSweetie depends on are included as submodules under 
dependecies. Except for WizarDroid they are all pre built in "poor mans" maven 
repo in my github account. So if you build via command line, simply checkout 
the repo with all submodules. Go to the WizarDroid folder and build with "mvn 
clean install" and then go to the App folder and also do a "mvn clean install".
When you import the project to Eclipse make sure that you also import all 
projects under dependencies into your workspace. Then you probably habe to add 
the dependent projects manually as Android library dependency to HABSweetie. 
Eclipse needs to habe Android library dependencies in its workspace.

As for the stability. HABSweetie became much more stable in the past months, 
some (me including) are using it as their every day front end for openHAB 
already. But there are still some little bugs I have to fix. I'm currently 
involved in some other projects so I can't say when I get to fix them, but it 
will be done. And when these are fixed, 1.0 will be released to the public. And 
I have already some feature ideas for 1.1 ;)

Original comment by till.klo...@gmail.com on 7 Oct 2013 at 6:33

[GoogleCodeExporter]

Thanks for the details Till. I have been shown where the HABDroid source is now 
so I might start with that. The reasons being, hopefully it will be easier to 
get setup in a dev environment, and also that I use HABDroid on my phone and so 
want this extra functionality where I can see it! ;) 

BTW - I have got HABSweetie on my device and it does seem more stable these 
days - well done! 

One question - what are the reasons/benefits you use HABSweetie ahead of 
HABDroid? I find the HABDroid UI a bit easier to follow (probably because it is 
so similar to the classic web UI). Not to say HABSweetie doesn't look good, I 
guess I just like the 'familiar' feel of HABDroid since I use the web UI quite 
a lot as well. 

But I am sure there are some killer features of HABSweetie I am not aware of. I 
see it is very good at handling multiple instances and sitemaps - but that 
isn't really an issue for me currently. 

Original comment by ben.jone...@gmail.com on 7 Oct 2013 at 9:31

[GoogleCodeExporter]

There were multiple reasons. As I discovered openHAB HABDroid wan't able to 
correctly handle SSL certificates, there was no Tablet capable UI, no native 
WebSocket support and a few other things. My first thought were also that I 
would just contribute to HABDroid, but I saw myself pretty soon rewriting the 
whole thing, so I thought why not start from scratch anyway.
HABSweetie has brought correct handling of SSL certificates from the beginning 
(it seems that Victor copied my approach pretty much), it has native WebSocket 
support through the Atmosphere client including fall back to other transport 
technologies. You can manage multiple instances, it has a responsive UI capable 
of showing multiple pages if there is space and so on. But these are only the 
improvements for the user.
Developers find that dependency injection via Dagger will make testing (in the 
future) much easier/possible at all. All or most APIs are abstracted via 
interfaces and are easily exchangeable if needed. Network communication (the 
REST calls, currently not the WebSocket connection) are handled in the 
background by RoboSpice so it is no problem to have configuration change while 
we wait for the result of a request.
Because of the abstraction it was fairly easy to implement support for Tasker, 
which enables you to have GPS based presence detection already (and much more).
So there were quite a few reasons to start from scratch with something new. But 
stability wise HABSweetie has yet to catch up with HABDroid, but the bugs I 
currently see shouldn't be too hard to fix.
HABDroid isn't bad at its job, but extending it could become quite difficult.

Original comment by till.klo...@gmail.com on 7 Oct 2013 at 10:27

[GoogleCodeExporter]

Struggling for time and understanding with this Android development. Think it 
is going to require me to put a fair bit of effort into understanding the 
Android framework in order to make any headway, and at the moment I don't have 
the time. I will keep you guys posted if I make any further progress.

Original comment by ben.jone...@gmail.com on 11 Oct 2013 at 4:02

[GoogleCodeExporter]

Had another crack at getting HABDroid up and running in dev mode with no luck. 
I can get the emulator running and HABDroid goes thru the initial startup 
sequence but then nothing happens. 

I found this (http://developer.android.com/training/location/geofencing.html) 
which explains how to implement geofence support in Android. It looks like most 
of it is baked into Android these days - all we would have to do in HABDroid is 
add somewhere for the user to enter their home lat/lon and geofence size, and 
then register it with the Location Services in Android. Then anytime the phone 
entered/left the geofence HABDroid would be notified and it could then post an 
update to the REST API.

Anyone with more expertise in Android development keen to have a crack at 
this?! Cos I am struggling to make any headway...

Original comment by ben.jone...@gmail.com on 14 Oct 2013 at 4:29

[GoogleCodeExporter]

Ben, can you post the logcat output of HABDroid startup?

Original comment by belovic...@gmail.com on 20 Oct 2013 at 1:16

[GoogleCodeExporter]

I can't attach the log to this post since the quota has been exceeded. It is 
quite long so I can email if you like? Or post it here in a 'comment'? Which 
would you prefer?

Original comment by ben.jone...@gmail.com on 20 Oct 2013 at 7:43

[GoogleCodeExporter]

E-mail would be easier, I think!

Original comment by belovic...@gmail.com on 20 Oct 2013 at 8:00

[GoogleCodeExporter]

Agreed - emailed!

Original comment by ben.jone...@gmail.com on 20 Oct 2013 at 8:01

[GoogleCodeExporter]

Original comment by kai.openhab on 5 Dec 2013 at 10:23

• Added labels: To-Github

[GoogleCodeExporter]

has been migrated to https://github.com/openhab/openhab/issues/646

Original comment by teichsta on 10 Dec 2013 at 10:50

• Changed state: Invalid
• Added labels: Migrated-to-Github