Life360 Device Tracker Platform

[gerard33 (Gerard 🇳🇱)]

@pnbruckner

Apparently HA 0.92 will require all custom components to have a manifest.json file.

Balloob mentioned this on Discord yesterday:
Just for the record, custom components won't need a manifest file, it will work without
Link is here.

Discussion if __init__.py is needed is ongoing here.

[pnbruckner (Phil)]

Thanks. I tried getting ready for 0.92 as best I could figure, but that clearly didn’t go well, and now maybe the requirements are changing even before 0.92 is released. I think from now on I’ll stick to fixing things if/when they break. Trying to prevent breakage ahead of time is a lot of work, and then everything changes anyway.

[gerard33 (Gerard 🇳🇱)]

Yeah I understand what you are saying. Have 2 custom components that I manage on https://github.com/custom-components.

Glad I have waited until now before doing any updates

[pnbruckner (Phil)]

BTW, I also try to maintain backwards compatibility, because I know many people can’t keep up with HA releases. I’m one of those people – for many reasons my “production” system is still running 0.84.6.

And then there’s custom_updater, and its differing requirements from HA. E.g., in order to get multiple files installed (i.e., use the resources parameter), custom_updater requires an __init__.py, which HA may or may not require. And then custom_updater wants the REQUIREMENTS statement in __init__.py, where HA wants it in the platform file (e.g., device_tracker.py.)

It all gets a bit ridiculous. I have five custom components that I try to maintain, and I’m also working on submitting major improvements to the standard amcrest component (which takes forever because it takes forever to get reviewed in the first place, then it takes a while to get through all the review comments, etc. E.g., my last PR took over a week before it was noticed – and after me prompting – and it’s taken days to get through the review, and now it’s just sitting waiting for balloob to get time to get back to giving his final blessing. Meanwhile I have multiple other enhancements I want to work on that are mostly waiting on this PR getting finished and merged.)

And now I’m considering trying to submit this Life360 integration into the standard release. Just shoot me!

[finity]

If it’s any consolation, we appreciate your hard work.

[pnbruckner (Phil)]

If anyone would care to take a look and provide feedback, I’ve staged the life360 code for possible PR. You can see it here. The main differences to the current custom component are:

• as_time configuration variable and time_zone attribute removed (and, hence, requirement for timezonefinderL and numpy packages.)
• Service renamed from device_tracker.life360_zones_from_places to life360.zones_from_places.
• Added service description.

I have not yet started on the “official” doc page that would go with it. Assuming I do submit a PR I may wait to do the doc stuff until I get some indication as to whether or not they’ll accept the code.

[GaryOkie]

I’ve switched to your proposed PR code - all is working just fine so far. I wasn’t using the as_time feature, so it’s not anything I will miss. It’s interesting though that this was removed. Was this done at the request of the PR reviewers because of the dependency size or what?

Since this staged PR code isn’t tracked by custom_updater, what’s the best way to follow any updates to it?

I noticed that the API token is hardcoded in the device_tracker.py code. Since this token is subject to change (which thankfullly, it hasn’t ever yet), might it be better to have it installed separately as a .life360_token file or in secrets? That way, if it ever does change, we can update it quickly and easily without waiting on the next release or rebuilding it as a custom component.

Lastly - it’s great that you’re making this effort to get this component into the official fold. It is greatly appreciated!

[pnbruckner (Phil)]

@GaryOkie

I wasn’t using the as_time feature, so it’s not anything I will miss. It’s interesting though that this was removed. Was this done at the request of the PR reviewers because of the dependency size or what?

I haven’t created a PR yet. I’m not even 100% sure I will (although I’m definitely leaning that way.) I removed it because I predicted it wouldn’t be looked at kindly. I assume it will be a rough road getting this through in the first place, and didn’t think this feature was worth it. I still have it in my custom composite tracker, so it’s still available that way.

@GaryOkie

Since this staged PR code isn’t tracked by custom_updater, what’s the best way to follow any updates to it?

I suppose you can go to the repo and at the top click on Watch and select the Watching option. Not 100% sure what this does. Just an FYI, though … I might make significant changes before submitting a PR. You’re, of course, welcome to use this, but I’m not going to be focusing on keeping it working, or worrying about “breaking changes”, because the focus is getting it ready as best I can for submission. If you do follow along, however, and run into any unexpected problems, by all means, let me know.

@GaryOkie

I noticed that the API token is hardcoded in the device_tracker.py code. Since this token is subject to change (which thankfullly, it hasn’t ever yet), might it be better to have it installed separately as a .life360_token file or in secrets? That way, if it ever does change, we can update it quickly and easily without waiting on the next release or rebuilding it as a custom component.

Well this touches on the shakiest part of this whole effort. This API is not officially documented, or even supported, to my knowledge, by Life360. It was reversed Engineered by someone in the open source community, which is what this is all based on. Yes, that key can change, or the whole API might change significantly, or become completely unavailable, at any time. I’m certainly not in a position to do anything about that. And I’m afraid to even try, because if I bring this to their attention, they might decide to not only not support it, but shut it down instead. Who knows. Maybe balloob will consider talking to Life360 since he represents this entire project, which might mean more to Life360.

[daneboom]

custom_updater is working really weirdly for me. Not only is it failing to track the Life360 component (but it OCCASIONALLY shows up following a reboot), but I can’t click the “check” or “update” buttons!

[ericlamer (Eric)]

Hi, since last update to 0.92 Life360 is no longer working. I am getting an error:
Integration life360 not found when trying to verify its device_tracker platform
Anyone have an idea why?

[pnbruckner (Phil)]

Trying to keep up with all the structural changes is bad enough, but trying to keep up with custom_updater’s unique and different requirements is worse.

Please try making sure you have the latest custom_updater, and restart HA.

Then manually run the custom_updater.install service specifying:

{"element": "device_tracker.life360"}

Then afterwards run the custom_updater.check_all service. (You may even have to restart HA before sensor.custom_component_tracker is updated correctly.)

That should work. Let me know how that goes.

[pnbruckner (Phil)]

Please make sure you’re using at least version 2.9.5 (the latest is actually 2.9.6.)

[pnbruckner (Phil)]

The (hopefully) good news is, I’m forging ahead with submitting this as a new standard integration. I haven’t made the PRs yet, but I hope to soon. Then hopefully the review process won’t be too bad, and maybe we can see this in the 0.94 release.

[pnbruckner (Phil)]

@daneboom @ericlamer

I just tried with 0.92.0. I removed custom_components/life360 to start clean. I made sure I had the latest custom_updater (4.2.19.) Then I used custom_updater.install to install element “device_tracker.life360”. That worked fine. Then I restarted HA and life360 seemed to work fine.

FWIW, the “Integration life360 not found” error probably means you’re not using the latest & greatest version of life360.

[ramdisk]

how do you get the latest custom_updater

[pnbruckner (Phil)]

You don’t have to use custom_updater to use the life360 custom component/integration. That is just one option. See these installation instructions for how to install life360 either via custom_updater (which links to instructions on how to install custom_updater) or manually.

[daneboom]

Thanks for this, Phil. I get:-

Error loading custom_components.life360.device_tracker. Make sure all dependencies are installed

Traceback (most recent call last): File "/usr/local/lib/python3.7/site-packages/homeassistant/loader.py", line 183, in _load_file module = importlib.import_module(path) File "/usr/local/lib/python3.7/importlib/__init__.py", line 127, in import_module return _bootstrap._gcd_import(name[level:], package, level) File "<frozen importlib._bootstrap>", line 1006, in _gcd_import File "<frozen importlib._bootstrap>", line 983, in _find_and_load File "<frozen importlib._bootstrap>", line 962, in _find_and_load_unlocked ModuleNotFoundError: No module named 'custom_components.life360.device_tracker'; 'custom_components.life360' is not a package

[ramdisk]

Thank you for your input, re-loaded Hassio .92 and so far all good with life360

[daneboom]

Thanks - I rebooted hass and now - inexplicably - it works.

(Prior to rebooting I’d deleted all trace of Life360 from my system, and was planning on calling the install service again once it came back up. Weirdly, I didn’t need to - when it came back up somehow custom updater knew I wanted the life360 component and had it ready!)

[ramdisk]

I just followed [pnbruckner] instructions