New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Location reporting doesn't resume after low power mode is switched off #430
Comments
I think my wife's iPhone 6 is doing this same thing. Although it does seem to stop at random times too. It has been very unreliable. What can I do to help troubleshoot? |
I run mine on an iPhone 6s Plus... my wife runs it on a 5s. Both seem to have periods of not sending locations. It's not just after low power mode... it's after reboot too. Unless you go into owntracks after these events, updating stops.
|
Which mode are you using (Move Mode, Significant Changes Mode)? |
Continuous update mode. In my wife's case, it didn't report her location for two weeks after she switched off low power mode, and only resumed when I asked her to run owntracks.
…________________________________
From: Christoph Krey <notifications@github.com>
Sent: Wednesday, January 4, 2017 11:16:59 AM
To: owntracks/ios
Cc: Jon Silver; Author
Subject: Re: [owntracks/ios] Location reporting doesn't resume after low power mode is switched off (#430)
Which mode are you using (Move Mode, Significant Changes Mode)?
When you say it does not report location anymore, do you mean it does not report while not moving or it does not report an update even when you move significantly?
-
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub<#430 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AIbAgindw6gscamjd5jYWlelAm6NMwlnks5rO3-rgaJpZM4Khp7o>.
|
Same thing here... She had continuous mode running, it stopped reporting completely, and did not start again until I ran owntracks to see what mode was selected. I changed to significant move mode to see if it behaves any different. |
Significant mode did not help either. It still quit reporting today. I must have something set up wrong?? Certainly if everyone had this issue on iOS, it would be unusable. Everything is working great on my android. Let me know if there is anything I can do or try, I'd really like to get this working! Thanks! |
One question: Do you (or your wife) kill the app (a.k.a. swipe out)? |
No.
And the first thing that happens when I open owntracks after the app has been dormant (still loaded in the double-click list) is a whole bunch of updates get sent and received... unless that's just a UI update thing, but I can't see why that would be.
…________________________________
From: Christoph Krey <notifications@github.com>
Sent: Thursday, January 5, 2017 8:46:48 AM
To: owntracks/ios
Cc: Jon Silver; Author
Subject: Re: [owntracks/ios] Location reporting doesn't resume after low power mode is switched off (#430)
One question: Do you (or your wife) kill the app (a.k.a. swipe out)?
-
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub<#430 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AIbAglqDm2Kpyok-tYPnL5KdsRztr04zks5rPK34gaJpZM4Khp7o>.
|
Same thing here. Once I run again manually, I see all of the missed updates from my friends. Then it will work again for a time until it randomly stops again. To my knowledge it has never been swiped away killed. |
Can anyone describe the settings they are using? My wife runs this on an iPhone 6 with the latest OS. I'm going to a private MQTT server with a TLS connection and authentication. I have the custom option set in order to allow for this connectivity. It works fine when I bring the app to the foreground - just quits updating regularly when in the background - that is, it doesn't work more than it works - and is pretty much unusable. I'm trying to figure out what is different about my setup than how it is used (presumably successfully) with the rest of the mainstream iOS users. I've tried both move mode and significant mode, and I get the same results. Are there any settings in iOS that changes the background behavior or permissions that I should check? To my knowledge, everything was left as default. |
We're using precisely the same setup - private MQTT, user authentication, TLS ( LetsEncrypt cert).
I've also tried using Locative to fire off webhook requests upon waypoint entry/exit, and that always works fine.
…Sent from my iPad
On 6 Jan 2017, at 23:53, rdgerken <notifications@github.com<mailto:notifications@github.com>> wrote:
Can anyone describe the settings they are using? My wife runs this on an iPhone 6 with the latest OS. I'm going to a private MQTT server with a TLS connection and authentication. I have the custom option set in order to allow for this connectivity. It works fine when I bring the app to the foreground - just quits updating regularly when in the background - that is, it doesn't work more than it works - and is pretty much unusable. I'm trying to figure out what is different about my setup than how it is used (presumably successfully) with the rest of the mainstream iOS users. I've tried both move mode and significant mode, and I get the same results. Are there any settings in iOS that changes the background behavior or permissions that I should check? To my knowledge, everything was left as default.
TIA
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub<#430 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AIbAgjp5C471qZDdUnov4lkYIL8b3u6kks5rPtPZgaJpZM4Khp7o>.
|
I've been having issues with background updates publishing as well and just stumbled across this issue. My wife's phone works flawlessly (5S) but my 6 behaves the same as others- opening the app shows a UI update like it's pushing all changes at once. I'll keep an eye on this over the next few days and see if it seems to be the same issue. |
I have noticed some strange behaviour around this issue which I thought I'd document here as I believe it points to a bug somewhere in OwnTracks. This morning (and at other times), OwnTracks notified me on my phone and watch that I'd left home. It didn't notify me that my wife had left home, even though she was with me. My home server logs everything sent by our OwnTracks, but it reported that the last received location for me was yesterday. I arrived at successive destinations and checked the server - no new positions logged, so no MQTT messages published, but the app was still reporting geofence transitions locally. When I arrived at work (my 5th stop). I loaded the OwnTracks app. I was in move mode. It still failed to report my location, so the most recent location the server had received up to this point was still from yesterday. I left it like that for a while, but no new location was published. Then I switched through the modes, and when I got back to move mode again, my location was finally published for the first time since yesterday. I hope this helps in tracking down and resolving the issue. |
Is it possible other apps can interfere? My wife runs life 360, and I noticed owntracks seems to work better when life 360 is not running. Could be a fluke, but thought I'd throw this out there. |
I was looking for an explanation why my Owntracks App on iOS was not publishing any messages when the app is in background and i leave my home. iPhone6s, iOS 10.2 , Owntracks 9.3.0, Privacy --> Location Services --> OwnTracks = Always |
I seem to be experiencing much the same. I have OwnTracks installed on 4 iPhones (2 7+ and 2 7) Setup: phones are all on latest OS 10.2.1 Any help or guidance would be GREATLY appreciated. |
I want to suggest you set a Region (Geofence) around your house with an radius of 50-100 meters. From my experience the geofence monitoring of iOS is quite reliable and wakes up the app from background. In addition the leave event is triggered a short while after you left the house. This means your phone has very likely finished the transition from WLAN to mobile network. When an app is woken up from background by iOS from background it is given only a very short time of activity. If the MQTT cannot be established within that timeframe, the messages is queued. |
I have 3 regions for testing right now, two are 50 meters and one is 200 meters. I'll up the 50 meter regions to see if that helps, but I did make them 50 meters based on previous posts I've read here that said 50 seemed to be a reliable choice (originally I had them at 30 meters.) I'll report back. Thanks for the reply. |
I guess this is probably the same issue I'm having - last week it just plain didn't send any updates in "move mode" for nearly 3 days despite travelling a good few miles each day. Whilst geofences might help in specific cases, it doesn't really help me when I'm out and about at random places I don't have geofences... |
In my experience, the iOS app is broken and unreliable (again, this is MY EXPERIENCE). I too, have coded a ton of stuff around Owntracks, but without reliable client reporting, its really not a good solution to lean on. As I mentioned earlier, I don't see how this is even usable, unless my problems are isolated to me - which I've assumed to be the case, because there are very few people in the community complaining other than the 5 people in this thread. I've tried so many different configurations, but they all act the same way. It'll report properly upon running the app initially for a short time, and then it will just stop, sometimes days on end - and won't report again until the app is reopened. And it just repeats this cycle. I've tried different move modes, I've checked and tried different settings as far as location permissions while in background, etc. I was thinking there were other location reporting apps somehow conflicting with Owntracks, but I haven't done any real testing with that idea, mainly because it's my wife's phone, and she uses those other apps quite often. I have zero iOS development experience, so for now, I'm waiting on others to fix this, and in the mean time I am not using Owntracks. I'll be updating my wife's device soon, and I was hoping it was just some specific issue with her device and this problem will just go away. Good luck! |
Most people I know use the iOS app and cannot confirm your "experience". |
That's great news. I was hoping that was the case. I just don't know why I have problems with this specific device. |
My experience isn't that bad - it's just sometimes unreliable like last week when it didn't report position for 3 days despite me travelling many miles. By way of contrast and to show it's not my device, Moves has never missed out whole days. It sometimes gets confused if I'm out of GPS coverage and my phone drops back to AGPS. But never dropping whole days like Owntracks has done. |
Yeah, it's been 6 days since my wife's phone has reported - and this is how it normally behaves. |
Although, again, yesterday it failed to report 5 hours of travelling (~230km). Only got a location at the end when I plugged it in to charge. |
I have the same symptoms as described by @rdgerken. Running latest OwnTracks on an iPhone SE with a Beacon-based setup. Could it be related to speed of your mobile connection and/or TLS/SSL-based connection? |
A new version 9.5.9 is in the app store which addresses the problem of iPhone 6 / 7 stopping to report location periodically in the background #462 |
I was seeing this issue with iPhone 8, iOS 11.4. I currently resolve by swiping out of the app and restarting it, when I take it off the charger. Not very automatic. Looking for the update in the U.S. app store. Don't see it, yet. |
The latest version is 9.9.3. Please don't comment on issues closed a year ago |
This is still an issue with Owntracks version 9.9.3 in iOS 11.4 as observed on iPhone 8. Not fixed. |
iOS10, iPhone 5s
Phone enters low power mode. Owntracks location reporting stops. Phone is recharged. Low power mode is switched off. Location reporting remains suspended indefinitely, resumes only after reloading Owntracks app.
The text was updated successfully, but these errors were encountered: