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?
Thanks!
The default (if you don’t specify either members or 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 Driving, Moving or any of the names of Life360 Places. It will just like be all other device_tracker entities: home, not_home or the name of a HA zone.
I should probably add that the information is still available through the attributes: driving, moving & place.
Ok, thanks for clarifying.
Hi Phil,
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.
Sorry, no.
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.
not sure if i should add this as an issue to here or not. but I am having an issue with the custom component Life360. I recently just update from 0.87 to 0.94.4 and I am getting errors in about:
In my log.
Setup failed for life360: No setup function defined.
My is as follows:
- platform: life360
username: !secret life360_username
password: !secret life360_password
max_update_wait:
minutes: 30
Did you upgrade to the latest version of the custom component?
i just read on your github that there was a complete overhaul of the custom components setup. I am going to complete those steps and return if needed. I will let you know if I still need your help. Thank you for you fast response.
I’ve got around this by making a bunch of template sensors for the various attributes.
sensor:
- platform: template
sensors:
sean_driving_status:
friendly_name: 'Sean Driving Status'
icon_template: mdi:gauge
entity_id: device_tracker.life360_sean
value_template: "{% if state_attr('device_tracker.life360_sean', 'driving') == True %}Driving{% else %}Not Driving{% endif %}"
sean_moving_status:
friendly_name: 'Sean Moving Status'
icon_template: mdi:run-fast
entity_id: device_tracker.life360_sean
value_template: "{% if state_attr('device_tracker.life360_sean', 'moving') == True %}Moving{% else %}Not Moving{% endif %}"
sean_wifi_status:
friendly_name: 'Sean WiFi Status'
icon_template: "{% if state_attr('device_tracker.life360_sean', 'wifi_on') == True %}mdi:wifi{% else %}mdi:wifi-off{% endif %}"
entity_id: device_tracker.life360_sean
value_template: "{% if state_attr('device_tracker.life360_sean', 'wifi_on') == True %}Connected{% else %}Not Connected{% endif %}"
sean_battery_status:
friendly_name: 'Sean Battery Status'
icon_template: mdi:battery-charging-wireless-alert
entity_id: device_tracker.life360_sean
value_template: "{% if state_attr('device_tracker.life360_sean', 'battery_charging') == True %}Charging{% else %}Unplugged{% endif %}"
Then in your automations instead of using the state of your device_tracker you use the state of your new template sensors (ie sensor.sean_driving_status & sensor.sean_moving_status).
It’s not quite as clean as before, especially when displaying in the UI, but this one very minor drawback is totally worth it to get this as a standard integration 
dumb me. i got it. thanks to your documentation. working well… About to upgrade to Python 3.7 now. Thank you again
Not all of the functionality that was removed was “forced out.” I chose to remove some features that I thought would make it harder to be accepted. The “standardization” process was difficult enough as it was. Leaving those features in could easily have made it even harder.
Of the features removed, show_as_state: driving, moving might be the easiest to add back. I don’t think I’d want to add the show_as_state: places option. That’s just too close the zone issues I ran up against. Better to add HA zones that are equivalent to the Places, and I explain how that can be done in the doc.
If there’s a strong desire to have show_as_state: driving, moving added back, by all means, open an Issue. I suppose it’s not strictly a bug report, but in this case an argument could probably be made to handle it this way (since many are coming from the custom component, and moving to the standard component is causing a “deficiency.”)
I’ll admit that I kind of liked being able to see Driving and Moving, not only “live”, but in the state history.