I had the same issue but all gone after cleaning browser cache !
Just updated to 2022.7.4 and, while itās only been 60 seconds or so since the install finished, I only see one log line per person who has lost connection, so looks like it works. Thank you much!
1 Like
Previously under the old setup of Life360 I was able to add a local picture file to the known_devices.yaml to display in HA. With the new setup is there any way to add a local picture or is my only option to add that in the Life360 app?
Try using ācustomizeā for a ādevice_trackerā entity.
Thanks that worked however just trying to reload the āLocations & Customizationsā didnāt work, I had to actually restart HA for it to show.
I was going to point you to an Issue where I already answered this question, but thanks to @Ildar_Gabdullin for beating me to the punch responding first!
It should work by just reloading customizations (it worked for me when I tried it), but you have to wait until the next time the entity gets updated for the change to take effect. Of course, restarting HA also works.
yes, and if you donāt want to wait for the next state change, simply change it manually in dev tools / states Set State box.
I tried that too but that also didnāt work for me.
Oh, such a cruel English idiom, first I was stunned)))
Is there anything special we need to do to get the battery levels from Life360 working again after updating to 2022.7.x?
Neither of our phone battery entities are showing up that I can find.
Doh! nevermind.
They are entity attributes not entities in their own right.
Yep. Also note (as is mentioned in the release notes) that the battery attribute has changed its name to battery_level, which is controlled by the device tracker component level code. (It made this change between the ālegacyā implementation and the newer, entity-based implementation a long time ago. So, this is not due to a change in the Life360 integration, other than indirectly from changing from the old legacy implementation.)
yeah, thatās actually why I got confused about the entity.
I have a template sensor for battery level that pulled the battery attribute out of the device tracker. after I upgraded that sensor was showing as unavailable because the template couldnāt render because it was looking at the wrong attribute (looking at ābatteryā not ābattery_levelā).
But I figured it out right away so itās all good.
1 Like
As some might be aware, the recent changes to the Life360 integration had a negative side-effect when there are server communication problems (e.g., Internet connection goes out temporarily.) This caused the device_tracker entities to change state to unavailable.
Worse, when the problems went away, the entities did not immediately return to a proper state (due to a bug), but rather would stay unavailable until there was new data from the server for the entity (i.e., its last_seen attribute, and others, updated.)
This can (and has) caused user automations to fire when they shouldnāt (e.g., because the device is not āHomeā temporarily.)
After seeing what other device tracker integrations do in this situation, itās pretty clear device_tracker entities should not change state to unavailable, but rather should simply retain their previous state until they are able to successfully obtain new data from the server. This is effectively how the Life360 integration worked before 2022.7.
Iāve submitted a PR to fix this problem:
UPDATE: Per comment below, I was not allowed to make this change; the PR was rejected. Itās working the way the core team wants ā i.e., an entity should become unavailable when the source of its data (in this case the Life360 server) canāt be reached. Needless to say, I still disagree, but thereās nothing I can do about it.
3 Likes
A have a bit different scenario.
Due to Russian invasion (have no civilized words to describe it), Life360 services are not available for Russian IPs.
Actually, many Russian & foreign IP servers are banned by Russian government (censorship), but also many foreign services decided not to provide services to Russia (like Netflix etc).
So many people in Russia are using VPN services (which Russia is also trying to ban).
I installed OpenVPN on my router and specified routes like āthis client should use OVPN, this should notā. So, HA host (Debian) is using OVPN, and HA is supposed to use it too.
Also, every mobile client at home (linked to my router) is supposed to use OVPN - that is why all mobiles have access to Life360 and HA has it too - so HA āseesā these mobile Life360 clients.
When a mobile device is not home - it is not connected to routerās OVPN - but this is another story, I have to use other VPN services on mobiles.
But sometimes OVPN does not work due to different reasons; so clients either do not have access to Web at all or have a āusualā access.
Assume that on HA startup that OVPN access does not work for HA.
As a result - all Life360 device_trackers are āunavailableā.
If I managed to fix the OVPN connection, then these trackers are still unavailable.
I need to reboot the HA host (and HA) - then these trackers are available again - but only for mobiles which are connected to Life360 via VPN.
If some mobile is not connected - itās tracker is unavailable. When I fix its connection - it becomes available.
If OVPN connection is lost after HA startup, then some tracker is still available but is not updating.
If Iām understanding your setup correctly, that should not be necessary. It may take a while for the entities to update to a state other than unavailable, but they should eventually on their own (i.e., the next time the Life360 provides updated location information.) Restarting HA or the HA host should not be necessary.
Having said that, if I fix the current bug (one way or the other), the entities should change back from unavailable as soon as HA can talk to the Life360 server (i.e., it shouldnāt have to wait for new data from the Life360 server.)
Unfortunately, I need to restart Debian.
According to my tests:
- if OVPN does not work - a browser in GNOME does not open banned sites (like meduza.io - banned IN Russia, life360.com = banned FOR Russia);
- if I fixed OVPN on routerās side - restarting the router doesnāt help to Debian;
- up/down network in Debain does not help;
- need to restart Debian.
But - this is just my personal case; and probably I am just doing something wrong with Debianā¦
This is exactly the reason that my ring alarm got triggered the other day. When the life360 server had issue, all tracker for family members were set to not home, and my automation set the alarm to āAwayā mode, then when I walked around the house, alarm fired.
Well, actually theyāre all set to unavailable, which, of course, is not home (aka Home.) Depending on how your triggers/conditions are defined, that could definitely cause undesired triggering of your automations.
FWIW, Iām getting push back on my PR, so Iām not sure I will be able to change the Life360 integration to avoid the state of unavailable. The best I may be able to do is to fix a bug that prevented the entities from changing back from unavailable as soon as valid data can be retrieved from the server (as opposed to waiting for new data, which could take anywhere from a few seconds to minutes depending on what your device is doing - i.e., moving or not.)
I suppose this is an appropriate time to put in an advertisement 
for my:
Composite custom device tracker integration
It will ignore unavailable & unknown states, and has other nice features, too, if I do say so myself!
FWIW, the built-in Person integration wonāt really help. It does ignore unavailable, but then when itās left with no input states, its own state will change to unknown, which for this discussion is just as bad.
Unfortunately, sometimes the Composite platform gave me not precise results.
Sorry for an off-topic.
Posted my observations here.