One folder I called “Backup 2019-06-22” which I put a copy of what was in the folder originally (a file called “device_tracker.py” and a folder called “pycache”).
One folder called “pycache”
TBH, I can’t remember how I set it up when I first got the Life360 account. I’d have to watch Dr ZZ’s YouTube video again
I haven’t done this yet until you confirm that’s what I need to do, plus I’m a little confused as to what I’m meant to do after that.
Ok, I’ve done that.
BTW, you replied quicker than I expected. I came back to edit my post to say that although the configuration checker says my configuration is valid, when I restart the services, the notifications bell shows the following:
(above screenshot has the 3rd notification cut off. It says there are newly discovered devices, but I always get this).
Anyway, I’ve updated my conf file with the debug lines and restarted and yet somehow, simply adding those lines have fixed the status on the icons as showing as home, plus the notification only shows the python issue and the “newly discovered devices”
I’m not sure why it’s now fixed as I’ve restarted the services multiple times.
Question. Do I still need to add those lines about custom_updater to my configuration.yaml file, and if so, what do I do after that?
Hey, Phil, I really hope you didn’t take anything I said as a criticism of anything you’ve done. I’m sorry if it came across that way. I’ve got nothing but respect for the work you’ve put into all of your components.
Based on prior posts, I (wrongly…) assumed that you had to remove the stuff you did to get it accepted. My bad.
And yes I think the driving & moving state option would definitely be beneficial to add back in if you would like to do that. It would be appreciated. I think i’m just going to add the feature request in the “feature request” area of the forum. I don’t want to get in anymore “hot water” because it’s not really a “bug”.
I’ve already added all of the life360 places as zones in HA so that isn’t an issue at all. So the driving and moving as states were the biggest thing I would be missing.
I never knew I needed to (or even could) vote on my own feature request.
I always assumed that it was a given that of course I had voted on the request if I was the one who posted it.
No wonder none of my feature requests ever get implemented. I guess they figured if the OP of the request never even thought it was good enough to vote on it then there was no use in implementing it!
Something that might work would be to create a Person “component” and not give it any presence or tracker entities. Then you could set the state of the component to be moving, driving or places.
Since the person component isn’t attached to any presence or tracker devices then Home Assistant shouldn’t be changing it’s state. Meaning that whatever you set the state to should stay that way until you change it. (I’m not sure what the state would be after restarting Home Assistant.)
I haven’t tested this to see if it works or to see what the downsides are.
I personally disagree that the official Life360 component should have a “show_as_state” option like the custom component did. The state of the official component should work exactly like all of the other device tracker components - it shows home/not_home or whether you are in one of HA’s defined zones. If you want to use Life360’s more advanced functionality all the information is there in attributes and can be accessed by automations or exposed using template sensors.
But if it’s as easy as making a few changes to the integration code then why shouldn’t it be done?
there should be no reason to make the user jump thru hoops to create a bunch of sensors (at least one for each circle member) just to get the same functionality that we had before.
I will also say that if you don’t want to use a “show_as_state:” option then no one is forcing you to use it and it will work exactly as all of the other device_trackers work. Why would you get to choose which options other people can use if it literally would have zero effect on you?
added to that, if ‘all the other device_trackers’ would behave perfectly, and wouldn’t cause any issue in tracking our devices, one could argue that that would have to be the default implementation.
unfortunately that is far from the case. wifi based trackers are famous for their unreliability, Bt trackers only work short distance, and several gps trackers (like iCloud) kill the battery of your device.
The Life360 component/now integration has proven to be (one of ) the most reliable device_trackers by far, except for maybe a set of device_trackers used as Composite (not coincidentally by the same author) or a hand_made configuration that takes a lot of fine-tuning (have one like that based on Mqtt device_tracker)
the Life360 is perfect out of the box. Id love it to be the next default tracker, including the moving and driving attributes, and set these as state. Once you use these, you don’t want to go back.
Regarding the Driving & Moving states, I mentioned to balloob on Discord that there was interest in having this added to the standard life360 integration, and he said, “that’s the kind of thing that we were thinking of adding to the person integration, but didn’t do yet.” I think that’s a better place for this kind of feature, so I guess I won’t pursue adding it to life360.
No. You can do that, but you do not need to do that. The life360 custom integration can be added manually. Just follow these instructions (where you can follow the “Alternatively, place a copy” part.)
That would not have had any effect. Something else must have changed.
Wouldn’t the person: component still need at least one device_tracker to report a “Driving” state though in order for it know? So this is still needed on the device_tracker level I believe.
Although his comment was a little vague, I interpreted it as a sign of support, that it was a good idea they were already thinking of. I just left a comment in the Discord too, so hopefully we’ll get a more clear answer.
Precisely because you can’t add that functionality to the other device trackers is why it shouldn’t be part of the standard Life360 tracker. The state of a device tracker in HA is either ‘home’, ‘not_home’, or a HA zone name. Is ‘driving’ a HA zone name? Or is it this weird state that the Life360 tracker can be in when it’s configured in a non-default way? What if one of my family members worked at a golf driving range and I had a HA zone named ‘driving’?
I’m sorry, but I don’t agree with your argument. If someone doesn’t like the feature, they can simply not use it. Also, if someone that wanted to use it had that scenario, then they could change their Life360 Place’s name from “driving” to “golf”.
I do like consistency, but there are plenty of examples in HA where things are not consistent. We’re not talking about dreaming up a new feature here. We’re talking about something that has existed for over a year that many people find useful.
Now, having said all that, if it can be implemented at the person level, then that makes more sense because then the feature could be used no matter which device tracker integration(s) were being used.
