@pnbruckner I just read the docs for the post 0.95 standard component, VERY COOL!! I see there will be some configuration changes needed to support the new method. How long will the legacy config continue to work? Life360 works great for me right now and I am not in a big hurry to go to make any changes.
I don’t plan to delete the custom component from my github repo anytime soon. On the other hand, I don’t plan to make anymore changes to it either to keep it working with new versions of HA. How long it continues to work is anyone’s guess.
If you don’t want to be surprised someday, after 0.95.0 is released you might want to consider changing to the standard component. (Of course, you can do that now with the beta.) The config changes aren’t very extreme, and you don’t even have to change to using the UI to add the integration. Your Life360 account(s) can still exist in the YAML files, albeit with a slightly different format. And there’s a few config options that no longer exist so you’ll have to delete them. Except for the zone and time zone features, the standard component is pretty much the same as the custom component was.
That’s completely fair and as I would expect. I plan to update as soon as I can find the time, I have been traveling for work a ton and my G/F uses the tracker in automation’s while I travel so I wanted to know what my buffer was for adoption. Looking forward to the updates…
Was excited to try out the official integration as soon as I installed the 0.95 beta. It was a very simple and easy transition, only had to change like maybe 3 lines from my existing yaml configuration. Smooth and painless, very nice job!
Have some feedback, minor things.
After first upgrading to 0.95 (and before setting up the official Life360 integration) it was printing a bunch of errors in the log, because I still had the custom_component installed. And the Life360 wasn’t showing up in the Integrations page either, just was a blank item that when clicked on did nothing. I correctly assumed what the problem was and resolved it but maybe you can print some kind of helpful user-friendly message to the log telling users to delete the custom component?
On the Integrations page when I press the + button and get the “Set up a new integration” popup, Life360 is listed first above all others. Not sure if this is supposed to be the case or not. The rest are listed alphabetically.
When I click on it in the integration page it says “This integration has no devices.” and there’s no icons like all my other device_trackers have. Not sure if this is intentional or not? The life360 device trackers are listed in the States page just fine.
Once again though great job, so happy right now
Yes, that’s all to be expected if you change the config but don’t delete the custom component. By design custom components take precedence over standard ones. There really isn’t anything I can do to fix this, or even create any warnings, because in this situation the standard code isn’t even getting loaded. I suppose I can add a warning to the standard doc page.
Don’t know what might cause that. It could be due to running initially with the custom component still installed which did not have the
config_flow.py file. That might have messed up the web page. Maybe try refreshing the browser???
I’m not sure about “intentional”, but it is the way it works in this case. Since it’s still a “legacy” device_tracker there are no devices or entities being registered in association with the config entry, so it has nothing to show. When you say “all of my other device_trackers”, what types are they?
Transition from custom to standard integration
For those that have been using this custom component/integration, when upgrading to HA 0.95.0b0 or later, you need to make some changes to avoid errors and keep your trackers working. This is a summary of the steps you should take.
life360related configuration. (See below.)
- Update HA as usual.
NOTE: life360 is still a “legacy” device tracker, so it still uses
known_devices.yaml. Do not modify, and do not delete
NOTE: After you complete these steps you should see Life360 configured on the Integrations page. If you click on it it will say, “This integration has no devices.” That is normal.
Modifying your configuration
A) Life360 Account(s)
This part of your configuration:
device_tracker: - platform: life360 username: LIFE360_USERNAME password: LIFE360_PASSWORD # Other life360 configuration variables...
should be changed to this:
life360: accounts: username: LIFE360_USERNAME password: LIFE360_PASSWORD # Other life360 configuration variables...
NOTE: If you have any other configuration variables besides your account credentials, make sure they are at the same indentation level as
If you have more than one Life360 account, they should all go under the one
accounts: key. E.g.:
life360: accounts: - username: LIFE360_USERNAME_1 password: LIFE360_PASSWORD_1 - username: LIFE360_USERNAME_2 password: LIFE360_PASSWORD_2 # Other life360 configuration variables...
The remainder of the configuration variables can only be specified once, which applies to all Life360 accounts. It’s no longer possible to have different settings for each account as was possible before.
B) Unsupported configuration variables
The following options are no longer supported and must be removed:
C) Changed configuration variables
NOTE: This is important to prevent your
device_trackerentity IDs from changing.
The default “device ID” prefix is now
life360, whereas it used to be none.
If you did not include
prefix: in your configuration, then you need to add this to keep your
device_tracker entity_id’s the same:
prefix: value can be left as-is.
This variable now only accepts
moving. If you had
places listed under this option, you need to remove it.
Also, if you had it entered like this:
show_as_state: driving, moving, places
You need to change it to a true YAML list, e.g., like this:
show_as_state: [driving, moving]
If you were using either or both of these before, just increase them each by 1 to get the same behavior.
Originally this was an “include” list, with Life360 Member names specified in any of these formats:
,name. It can now be either an include or exclude list, with Member names specified as
first last or
name. So, if you specified this option, change it from:
members: - first, last - name1 - , name2 - name3,
members: include: - first last - name1 - name2 - name3
Note that you can instead specify an exclude list for Members, and there is a new option for specifying which Life360 Circles to include/exclude. See standard integration doc for more details.
As noted above, the options for automatically adding/updating HA zones from Life360 Places are no longer supported. If you were using this feature, then you’ll need to add the corresponding HA zones a different way. See documentation for standard integration which talks more about this.
A final note. Life360 credentials used to be cached in a file in your
<config> folder which, by default, was named life360.conf. This file is no longer used or created and you can delete it if you like. (Credentials are now stored in the HA standard
Quick question and I may have just missed this. If we want to include every member in the circle, what do we do? Add everyone in an include list? Have an exclude list with no one in it? Don’t have an include or exclude list because that is the default? Or, any of the above will work?
The default (if you don’t specify either
circles) is to include all Members from all Circles.
What will be the result of removing “show_as_state” from support?
Are those old states just simply the default state for the entities now?
The device_tracker’s state will no longer be any of the values that came from that option. I.e., it won’t be
Moving or any of the names of Life360 Places. It will just like be all other device_tracker entities:
not_home or the name of a HA zone.
I should probably add that the information is still available through the attributes:
Ok, thanks for clarifying.
forgot to think about your CC immediately, sorry for that, so posted this: Track people's( devices) presence per country?
then remembered you have the time_as feature, which shows at least the timezone the device is in. Could that be expanded in the CC to showing the country? Or, could that be added to the CC. Would really be very helpful… and a unique feature (hope this is a trigger…)
timezone eg is ‘Europe/Rome’ and the ‘Italy’ would need to be calculated? Or is this hidden and would you be able to display that.
thanks for having a look.
which is really a pity, my uses case relies a lot on the driving and moving state. It makes a prominent part of my default Home page…
Just to be sure, we still can use the CC after 0.95… I see now the time_as will be gone too, so all the more need to keep using the CC, if possible at all
I don’t plan to do any more development on this custom component, nor fix any issues that come up with new releases of HA. Anyone is, of course, free to keep using it (I don’t plan to remove it from my repo), as long as it continues to work, or they fix any issues themselves that might come up, but I recommend moving to the standard component which is now available, at least in a beta release.
The existing features you’ve mentioned are also in my custom composite tracker, which I still support. Yes, it’s somewhat being replaced by the new standard person component, but at least for now I’ll try to make sure the composite tracker continues to work with new releases of HA, mainly for these additional features I can’t ever see making themselves into the person component.
Of course, they, and the new feature you’re asking about, probably belong somewhere else. At least, it feels like they should. I added them because I wanted the feature and it was the easiest way for me to do it at the time. So, I guess, at least for now, I probably wouldn’t consider adding this new feature.
Maybe you missed this:
Your automations can still get at this information, albeit in a different way.
if this is the new component, that’s a small relieve. But, as it stands now, Id love to be able you keep using the CC, since it behaves so perfectly.
If not added to the CC, could you help me sort this out then, Ive found a suggestion to calculate the country based in timezone here:
A bit at loss how to get this into HA though, either in a python script, or a jinja template using the attribute timezone from your component.
I think I just came up with another question related to my last one above…
Right now, I use “show_as_state” and I have combined all of my device trackers into the “person” component.
On the frontend, the state of my “person.xxx” is shown as the location I’m in based on my zones I have set up in HA. However, it also will show my state as “driving” or “moving” if I’m not home or in another defined zone and I’m actually driving, etc.
Since the “show_as_state” is removed will the state of the person component still show as “driving” like it did before? I think the answer, unfortunately, will be no but I’m hoping it’s yes.
Yeah, I figured.
I guess I’ll have to create another custom sensor.
Or just keep using the custom component till it dies.
same boat here, love the custom component, don’t like it getting deprecated because of integration into HA.
Just like the Hue CC for that matter.
2 major CC’s . Hope they will live long and prosper
I like the idea of it being officially integrated into HA and putting the CC to bed. And I appreciate Phil’s hard work to get it in there.
I just don’t like that some of the unique useful functionality of the CC was forced out to get it there.
+1 to that. you worded it better.
but, having read the discussions that accompanied this integration, my bets are on the long lived CC, even though my hopes are on the development of the integration.