The Life360 custom component by @pnbruckner has been migrated to be an official integration into HA. Congratulations! 
The “show_as_state:” options for “driving” and “moving” in the custom component were removed when it was a converted to the integration. I would like to see those options added back in.
Thanks!
I have to say that I’m against this. The ‘state’ of a device tracker should be ‘home’, ‘not_home’, or the name of a HA zone. If we allow device trackers to change this to have whatever random meaning that they want it’s going to create a lot of confusion. I know that there are a vocal minority of people that used the Life360 custom component that want this (including the author of the component I believe), but the data that they want is easily accessible through attributes of the device tracker. It’s easy enough to access the attributes directly or to create template sensors that expose the data in a different way.
Apparently mostly to you.
I will say this again here so as to clarify what I and the others are asking for…
This will be an optional configuration entry. If you feel you will get too confused by this minor optional setting or for whatever other reason you don’t want to use it then no one is forcing you. If you don’t want to use it then it will act exactly like any other device tracker. I fail to see sense in the opposition to this.
As anyone who has actually used the custom component this integration is based on and used the “show_as_state:” option can likely tell you it is a pretty useful option.
Especially when the device tracker it creates is added into the “person” component it is nice to see immediately on the front end that not only is the person “not_home” but that they are also driving.
Let’s imagine we use this as a ready display of a person’s true status. We can then use it as a part of a “safety system” of sorts for our other family members (the literal ultimate purpose for which the life360 app was developed in the first place). If a person isn’t in a known zone (which is also supported by the component, btw) you can see in an instant if they are driving instead of sitting still somewhere where they might not be expected to be sitting still. For instance, if they are in the middle of nowhere and are not driving/moving it could indicate that they may potentially be in trouble and in need of assistance (accident, car trouble, etc).
Why would someone not want that capability? And if it’s as easy as setting an option in a config then why force people who actually do want the option to have that option without jumping thru hoops to create a bunch of extra sensors for every person in the circle?
If you don’t want to use it then you don’t have to use it.
Why do you insist on preventing the option to others who find it very useful?
Here’s something to consider…
Where is the definition of a device_tracker’s state set in stone that it can only be home, not_home or in a zone? I’m probably sure that those were some kind of arbitrary states that were decided on in the early days of HA. Those “rules” can easily be changed and I promise that it won’t signal the demise of HA or trigger the end of civilization as we know it.
Please, let’s leave the ad hominem out of this. I know that some of the users of the Life360 component are very passionate about this but let’s not go
First off, I have used the custom component. Second, I’m sure that having the information in some form is useful to some people. Third, you haven’t explained why it’s useful to have the ‘state’ changed to ‘driving’/‘moving’ when that information is already available in an attribute. Sure it’ll make some automations prettier but I don’t find that very compelling.
I realize that you probably just came up with this example off the cuff but let’s look at it further.
Maybe they are just sitting at a long red light, or they stopped to get gas, or an ice cream cone, or they went into the dry cleaners, or or or… I can think of thousands of reasons why Life360 thinks that you’re no longer driving that are completely innocuous, including your phone battery being low, no signal etc.
How do you define where someone isn’t expected to be sitting still? Both from a practical standpoint and getting that information to HA.
Unless you are hooked into a comprehensive GIS database I don’t see how HA is going to know you’re “in the middle of nowhere”.
Do you even know what Life360 means by driving/not driving and moving/not moving? Unless you work for Life360 I don’t know how you do as I could find no explanation, other than a drive must be more than 1/4 mile and faster than 25mph. Support - Life360
This still doesn’t explain why changing the definition of the device tracker state is necessary. The information is already available as an attribute and can thus be shown.
If you want it, why isn’t it sufficient to access the data that you want through the device tracker’s attributes or through a template sensor? Yeah, OK it’s maybe not pretty to add a bunch of template sensors, but maybe it would be better to make it easier to create a bunch of template sensors rather than changing what a device tracker’s state means.
Personally, I think being able to template sensor templates would be a lot more useful. For example if you could do (pseudo code):
{% for device_tracker in device_trackers %}
{% if device_tracker.entity_id.startswith('life360'): %}
sensor:
- platform: template
sensor:
-name: {{ device_tracker.entity_id} driving
... yadda yadda yadda
{% endif %}
{% endfor %}
Now that’s a more generic solution with potential applications outside of just the Life360 device tracker. Wouldn’t it be interesting to be able to easily set up a sensor for all of your battery powered devices?
I think it’d also be better if HA made it easier to expose data from attributes in Lovelace rather than having to copy that data to a sensor.
Why do you insist on adding it? The information you need is available in an attribute and is easily accessible.
If the “rules” are changed it shouldn’t be because a few users of one bit of code want it changed. There should be a wider discussion and commitment from at least a few other device trackers to use the changed functionality.
Are there in fact any other device trackers that provide this sort of information as part of their API? And not just by HA synthesizing the information by watching successive GPS updates, something built into the upstream service?
Pretty sure if the developer who created it wants it in there and is willing to add it, that’s his prerogative.
Plus i dont think having to use templates to expose the attributes make it easy for new users.
It’s pretty amazing to me that an arbitrary decision I made to remove this feature, to try to make it easier to get the integration accepted as standard, not because I thought the feature was bad, just that there would be less for the reviewers to consider (they always want PR’s to be as “small” as possible), has caused so much fuss.
I’m not sure where you’re coming up with these “rules” that a device_tracker’s state can only be home, not_home or the name of a HA zone. If you look at the API the device_tracker component code provides for device_tracker platforms to use, there is a parameter that specifically exists to allow the platform to set the entity’s state. If there was some rule as you’ve described, then this option would not exist. It would be the job of the component level code to determine the state, period. Also, the device_tracker.see service provides the same option, so that users can create automations or whatever that result in device_tracker entries in know_devices.yaml and the state machine that have states set to whatever the user wants. Again, if there was a rule such as you describe, then this would not be an option.
You also say that people have not provided a reason for the driving & moving status to become the entity’s state, yet this has been explained multiple times.
Of course everyone is entitled to their opinion. And I appreciate you expressing yours. I just don’t happen to agree with it.
It had nothing to do with a personal attack on you. i was just pointing that you seemed to be the only one who found it confusing.
If it came across as an attack then my apologies.
because as far as I know you can’t include a sensor into the person component. So creating a sensor out of an attribute of the entity won’t help you seeing the actual state of the “person” you are tracking. If the state of the device tracker is driving then that state will get passed on to the “person” and will be readily displayed as the state of the “person”. That’s exactly how it works now using the CC and it works great.
Yes, all of those scenarios could be true but so could mine. At least the family member who is checking the status of the tracked person has the option to see that information and act accordingly. More information isn’t a bad thing.
you can look on the map in HA and the person will be shown at their location based on the GPS coordinates in the tracker. Most people know their local area well enough to tell if the person is “in the middle of nowhere”.
yes.
the definition of “driving” is literally right there in the configuration of the component.
driving_speed: 18
I’m not as sure of what moving means but I’m sure it’s as fairly common sense as driving.
I assume you have noticed all of the bold words throughout that entire post above right? If not then go back and look again. I’m sure it will be clear after that. If not then I’m really sorry if you lack the imagination to understand why people want this. Again not a personal attack but I don’t know how else to make the point that you are pretty much the only person who has stood up against this. And for not very good reasons, either, other than “that’s not the way it’s ever been done before”.
Have you seen how many integrations there are and how many of those integrations are useful to a very small handful of people? Should we not change the code just to cater to needs or desires of those few people?
It doesn’t seem to be that onerous of a change to be so adamantly against it or to think we need to call together hearings before Congress to get it accepted.
And I don’t know if you saw in the other thread but even balloob seems to be OK with the change.
PR submitted:
Home Assistant should strive to be as user-friendly as possible. And the idea of creating multiple template sensors for each family member to display basic information is the complete opposite of user-friendly.
The way I see it, Home Assistant already displays your current zone as state which nobody has a problem with. Having the zone as the state is a convenient way to see information at a glance - you can take a quick look at your Lovelace dashboard and see that your wife is at work, your child is at school, etc without needing to click through and read attributes. Showing a “driving” state is really no different - it’s about providing extra context to the away state, in the same way that zones do. If you think of your car as a zone, it makes perfect sense imo.
It’s worth nothing that Life360 is a massive, massive service, undoubtedly the biggest third party device tracker out there by a wide margin. Take a look at the Google Play website to see the stats under each app - for Life360, just the Android version alone has over 50 million users which is 100x bigger than GPSLogger and 1,000x bigger than OwnTracks.
Allowing these millions of existing Life360 users to simply login with their username and password and have all the device trackers for their entire family setup and ready to go (complete with avatars and everything), and have things work the way they’re familiar with, is an extremely compelling use case. These users can essentially have a fully-fledged presence detection setup for their entire family with literally five clicks of their mouse. We should be encouraging amazing user experiences like this.
Furthermore, Life360 is not the only device tracker that provides this type of activity information. Robbie has done incredible work on the soon to be released Home Assistant Companion 2.0 app for iOS which reports activity too. I would assume the upcoming official Home Assistant Android app he’s developing will have something similar too. Geofency is another one that supports this info. So activity information is certainly not something that is specific to just one app.
I don’t think ‘it’s different, let’s keep status quo’ is a good mindset to have. The question you should be asking is whether it makes sense and whether it provides a better or worse user experience. I feel the answer to both of those questions is yes.
… and approved, and merged into dev. I believe it should be in 0.95.0b3.