Thanks.
So, reading some posts in this 3d, the PyPi package will be downloaded automatically, is it correct?
Not sure if this is Life360 related, but issues started shortly after the last update to 2.6. Will move out of this thread if required.
My HA docker keeps restarting every 6-8 hours.
I’m running HA on docker, issue started on 0.86.3 and remains on 0.87.0
I can’t see anything in the HA logs, the docker logs (from portainer) only really show HA logs.
This doesn’t appear to be RAM related (no spike at the time and only ~50 usage. There are times when RMA usage is higher, like upper 70% but no container reboot then.)
I’m not too sure how to troubleshoot this one.
Any pointers?
By all means, let me know if you can determine this code is somehow at the root of the problem. I’m still on 0.84.6, so there might be something in all the re-architecting they’re doing that has caused problems with this. I’m in the process of getting my system more ready to deal with all the recent changes, especially moving to Lovelace, so hopefully I’ll be able to test with a newer HA before too long.
Thanks Phill. Will try and disable the component to see if it makes a difference…
Interestingly my uptime is the highest I’ve seen so far so if it keeps being up it’s going to be a difficult one to troubleshoot 
HI, please see Instant not_home status? for a short description of my CC suddenly stopped working. Ive updated and use this config:
device_tracker:
- platform: life360
username: !secret life360_username
password: !secret life360_password
prefix: life360
show_as_state: places, driving, moving
driving_speed: 20
interval_seconds: 30
max_gps_accuracy: 200
max_update_wait:
minutes: 15
add_zones: false
time_as: device_or_local
warning_threshold: 1
error_threshold: 2
an older version on my second system still works fine, so I know Life360 isn’t the culprit
I checked my recent changes again, and I can’t see anything obvious I changed that could cause these types of problems. There certainly could be – it’s just not obvious at this point.
Could you make sure DEBUG is turned on for custom_components.device_tracker.life360 and take a look at the messages it outputs to the log? Anything out of the ordinary or suspicious there? (If you’d like to share your log messages via PM, that’s fine.)
@Mariusthvdb, can you expand on how it’s failing? Are the device_tracker entities simply no longer updating? Are you seeing any errors in the log? Do you see any messages like these in home-assistant.log?
pi@raspberrypi:/home/homeassistant/.homeassistant $ grep 'custom_components\.device_tracker\.life360]' home-assistant.log
2019-02-12 10:08:40 DEBUG (Thread-10) [custom_components.device_tracker.life360] Life360 communication successful!
2019-02-12 10:08:40 DEBUG (Thread-10) [custom_components.device_tracker.life360] Configured members = None
2019-02-12 10:08:41 DEBUG (Thread-10) [custom_components.device_tracker.life360] Updating life360_xxx
2019-02-12 10:14:55 DEBUG (Thread-8) [custom_components.device_tracker.life360] Updating life360_xxx; Time since last update: 0:08:54
2019-02-12 10:18:24 DEBUG (Thread-19) [custom_components.device_tracker.life360] Updating life360_xxx; Time since last update: 0:03:25
yes that’s what was happening in once HA instance.
Ive waited longer than the max_update setting and nothing happened.
Seemed they were not only not updated, but not even initialized because normally when one clicks the more-info, the full list of attributes is displayed, and now only the regular history graph with home/not_home was shown.
Ive rebooted once again, and now they’re back! Which would at least suggest my settings are ok… Hope it was a short hiccup. Hadn’t experience it before…
If it happens again, please search home-assistant.log for messages from the component (as I showed above). There will probably be useful information there. Unfortunately, you restarted without doing that, now that information is gone.
One possibility I can think of that might explain what you experienced – at startup it will attempt to communicate with the server to see if everything is setup correctly. If that fails, for any reason, the platform setup will fail. You have to restart to get it to try again. So, for example, when HA starts, if you have a temporary Internet connection problem, or if the server just doesn’t respond for some reason, that will prevent the platform from starting. If this happens there would be messages in home-assistant.log that would provide the details of what went wrong.
I did recognize that this is a potential problem, and I even created an Issue so that I eventually get around to better handling this situation. I haven’t done anything about it yet, partly because I haven’t heard of anyone experiencing this type of problem (and I haven’t noticed it myself either.)
Thanks. I’ll first deactivate the custom package and will track. If it doesn’t crash then I’ll look into the logs.
I’ve installed custom_components at the same time and I’ve seen an update recently. Currently I only use custom_components for life360 so I’m also disabling this for now and will reactivate either/both depending on how the container behaves.
I tried to look at the docker logs (sudo journalctl -fu docker.service) but could not find anything relevant…
I did find some updates in some of the lovelace custom cards I was using so updated these just in case.
I also found I had 2 occurrences of the kiosk card in my lovelace resources so removed the extra one.
Now I just need to wait…
Do you mean custom_updater?
Sorry yes that’s what I meant
1 Like
that is exactly what I experienced, didn’t have debug settings low enough to see errors in the log, but did see inspector errors of that sort, not being able to load resources. If it happens again, I will do so and check the logs for details.
Would it be possible to create a Persistant Notification if this happens? That would make it easier to notice and you would know the cause of the problem.
I haven’t noticed the problem myself.
And thanks for a great component!
Good news (well for you @pnbruckner), the docker container restarted again after 12h with custom_updater and life360 disabled.
I’ll look elsewhere. Thanks though for looking into it
Thanks for the info. Glad it wasn’t me! 
Hope you figure it out soon.
1 Like
I suppose it would be possible for the platform to fire an event if this happened. Then you could use that to create a persistent notification if you liked. However, looking at other device_tracker platforms, I don’t see any evidence of any of the others doing anything like this. Nor do I see any of them retrying. (Although I’ll admit, I only looked at a dozen or so.) And, for example, I see the google_maps platform doing the same as life360 if a comm error happened during startup – i.e., aborting.
The problem is that the device_tracker component-level code has no provisions for retrying a platform setup if it fails like pretty much all other components do.
On the other hand, I suppose I could ignore errors at startup, with the theory being, if they’re intermittent, then eventually things will start working. Maybe I could treat a login error specially, since that’s not likely to get resolved just by time. Let me think some more on this…
1 Like
I haven’t checked any of this in yet, but I’m testing some slight improvements in the error handling in the life360 PyPI package, the main thing being differentiating a login error. Then in the life360 HA custom platform, I’m only aborting the setup if I get that login error. Otherwise I log any other errors as warnings and continue, with the hope that any error in talking to the Life360 server during startup, other than a login error, is temporary and will eventually clear like errors that happen after startup. I’ll test this for a while, and if it looks promising, I’ll release the changes.
1 Like
Great!
I like the way you think and how you write down your thought process. And your desire to improve your code.
2 Likes