I am on OH 3.1 M5 and I have setup the GPS tracker binding using GPSLogger on my Android device passing the GPS position to OpenHAB to leverage the region channel of the GPS tracker binding to decide whether a device leaves or enters a defined zone.
I am passing every 60 seconds (high rate for debugging) the GPS position from my Android device to the OpenHAB cloud account but I experience quite often a delay of more than 4 minutes before the “At Home” region (2km radius) switch state changes in my OpenHAB instance independent if it leaves or enters.
I measure this difference by comparing the LastSeen time stamp recorded by the GPSLogger channel LastReport for every GPS position transfer - proving by the homeDistance item that the device is outside of the defined home zone - with the “latest update” time stamp from the region switch atHomeGPS.lastUpdate("mapdb").
I intend to use the switch for steering heating, air condition, power outlets but it is useless when the switch state changes after I already reach my house.
Is there a chance to find out why this delay occurs or maybe a setting that I can configure to speed up the communication to achieve a near real-time switching without delay?
Thanks for any hint or idea how to solve this …
P.S.: I have used an app called “egigeozone” before which intitiated an event via REST-API instantly when leaving a geofence defined in the app. This allowed a near real-time switching of home devices. But unfortunately this app is not updated anymore and does not work correctly with the lates Android version
does no one else experience delays of passing the region_trigger changes to OH via the cloud connector?
It is no issue when leaving the home zone then e.g. the heating starts saving a little later … but it is very disturbing when you are already back home and heating starts powering up after you already arrived … It would be appreciated that the region_trigger is switched timely when you enter the home zone?
Thanks for any thoughts, hints or ideas how to solve this …
Presence detection is always difficult.
The most reliable results can be obtained by working a combination of techniques. Has the front door opened? Then there’s someone at home, but they might be going out. Has Fred’s phone joined the WiFi? Then Fred is at home.
THANK YOU for responding … I agree but some activities should start much earlier before the local techniques like door sensor, Wifi connection, etc. apply.
I would assume that the GPS tracker binding should not have a delay of over 4 minutes (with an update interval in the app of 60 seconds to report a switch status change?
Maybe someone could advise if there is a way to debug this …
or …
… it could probably be an option that the OpenHAB app could directly gather the GPS information from the device it is running on to simply initiate triggers for GPS regions …
I would just be thankful if someone who knows the GPS tracker binding may advise me how to avoid/solve the delays
Thanks Mark,
I tried both options but Owntracks used more battery power on my device and you could see all other members through the “Friends” feature in Owntracks which my kids - both fully occupied by puberty - did not like, that their parents can see their positions …
I already did turn that DEBUG option in OpenHAB on but it does not give more detail than what I said that the switch state change comes delayed … it should better be debugged in the cloud connection … I will keep my family in GPSLogger and switch myself back to Owntracks to see if there is a difference!
I’ve no real idea - but remember you are relying on a shared free cloud service provided by open source volunteers. I wouldn’t expect lightning performance.
I fully agree and I do not expect a millisecond response times (even seconds) and furthermore no high grade service levels. I totally appreciate to have this cloud service from OpenHAB.
But providing a GPS tracking service does not make sense if the delay is so immense that the region_triggers become so inaccurate that you can not rely on them.
My topic is definitely not intended to be offensive but you would also open a topic if OpenHAB locally takes 4 minutes to turn your light on
I just want to raise attention if this may be an obvious misbehaviour of this service which can be solved
And I am surprised that there are so many different strategies for presence detection around in the community as this seems to me to be a key functionality for home automation and there seems to be no real general agreement which strategy is the most promising/effective. I am also still searching for the best approach
Because it is difficult. The variety of partial solutions recognizes the variety of the people and habits being detected, the variety of purpose, and in the home context, what technologies are actually available/affordable to use (or repurpose).
Your GPS solution would be useless to me for example, because I’m an old duffer and don’t always carry a phone around.
So, to your case. You’ll have read this in the binding docs
Transition - This report is based on regions defined in tracker application only. A message is sent every time the tracker enters or leaves a region. [OwnTracks only]
which suggests to me that your usage is better supported by OwnTracks, because you are focusing on this at-home switch.
it is in many a very key functionality of home automation. There are a whole bunch of things you what to happen… only if someone is home.
There is in fact a general agreement in this community as to which strategy is the most effective. In fact, Rossko mentioned it a few replies up
Using several methods, and then combining the results and making an educated guess at the accuracy of the individual components. example
Think about what you really need to know (am I close enough to home to fire up the heat?) Well… where did you leave from? What if the notification can be sent when you leave a region (heading home from work?)
Not saying this will work for you, just trying to give you some ideas about how to think about the problem and invite ideas about how you can provide a working solution.
You are after all trying to predict something that is yet to happen in the future. (I’m almost home, fire up the heat) Not to be a smart a$$ but what if you get in a wreck a block from home? Heater fires up, malfunctions and burns house down while you are being brought to the hospital… … kidding but you get the point
True, everyone have their on personal ideas and circumstances what can be done to achieve this goal. So, diversity might be even a benefit than a confusion
I saw this and tried it via my own MQTT server. The OpenHAB GPS Tracker binding does not support this but in the binding it solved independently from the Owntracks solution. There is a location status implemented in the binding which is causing the delays …
No worries, I like that humor and you are right. This goes into prediction and might cause even other funny interactions
I have an app called Tasker on my Android which I used in the past for other stuff. I found that it has a geofencing feature and I will try if I can initiate a location based skript and then send an API-Call to the OpenHAB app (which has an appropriate plug-in for Tasker) to toggle the region_trigger more accurately …
I keep you posted on the progress.
Nevertheless I would kindly appreciate if there would be a way to find out if the delay in the GPS tracker binding for setting the region_trigger is a bug or a feature
Alright, if you think it is the binding you have access to all the diagnostics needed. Use DEBUG to find out when the binding gets a new position and when you get the switch action
yeah, that’s what I was thinking of as well, but I found the geofencing feature in tasker used a lot of battery power (for some, might not be a problem, for me was) but tasker also can perform some action when your phones wifi connection changes, such as when you log on or off a specific network. Does your phone log onto a ‘work’ wifi network? Maybe when you leave the office and your phone losses that connection, tasker sends a notification to openHAB whatever… anyhow
I get that the thread is about trying to diagnose the GPS tracker
(even seconds) and furthermore no high grade service levels. I totally appreciate to have this cloud service from OpenHAB.
… kidding but you get the point