lol! I just realized what I was looking at was not the speed attribute from my device_tracker entity, but that times another 2.25! This is from a template sensor from before I changed the speed attribute from the raw speed value from the server to the estimated mph speed. (I.e., from when I was doing testing before the release.) So the 150 was actually only 67 mph. 
still trying to settle my automations down on this device_tracker, I am surprised as to how many states it can haveā¦
I believed Moving, Driving and Away to be attributes, but now I re-read https://github.com/pnbruckner/homeassistant-config/blob/master/docs/life360.md#configuration-variables I understand why they pop-up. Away btw isnāt listed, but I take it thats HA itself, changing not_home to Away? Had to add it to the templates logic though to not have it notify something like
Marijn left Home and arrived at Awayā¦
using this
- service: notify.m
data_template:
title: 'Presence Tracking:'
message: >
{% set name = trigger.to_state.attributes.friendly_name %}
{% set to_state = trigger.to_state.state %}
{% set from_state = trigger.from_state.state %}
{{as_timestamp(now()) | timestamp_custom("%X") }} :
{% if to_state == 'not_home' %}
{{-name }} left {{from_state}}
{% elif from_state == 'not_home' %}
{{-name }} arrived at {{to_state}}
{% else %}
{{-name }} left {{from_state}} and arrived at {{to_state}}
{% endif %}
to be sure, the devices can be home and not_home, Away, Moving, Driving (with capitals), and in any of the defined zones, is that correct?
I created below conditional value_template to prevent triggering in case of:
- condition: template
value_template: >
{{ trigger.to_state.state is not none and
trigger.from_state.state is not none and
trigger.to_state.state not in ['Moving','Driving','Away'] and
trigger.from_state.state not in ['Moving','Driving','Away'] and
trigger.to_state.state != trigger.from_state.state }}
other than that, the Component is been a huge improvement! Too bad the attributes driving, moving and speed arenāt very accurate, otherwise it is a near perfect tracker. Thanks!
moving and driving are attributes, and when True they can cause the entityās state to be Moving or Driving if you have show_as_state set that way. Itās your choice if you want the state to be able to take on these values or not. So the attributes are always there, but you can control which, if any, might show up as the state as well.
device_trackers can have the states 'home' and 'not_home' (among others.) Those are the actual states, and what you need to use in automations, etc. But they display in the frontend usually as āHomeā and āAwayā. See Device tracker states. This is not unique to this platform.
Close, but no. 'not_home', 'home', a HA zone name, 'Moving', 'Driving', a Life360 Place name, or a Life360 check-in name. The first three are generic features of the device tracker component. The rest are features of the Life360 platform and are optional (depending on what you set in show_as_state.)
I updated the state chart to (hopefully) make it a bit clearer. Note that if show_as_state is removed from the config, the three rows that remain describe the generic behavior of the device tracker component.
thanks Phil, will check and see/test further.
btw, after the latest update, I still go a raw speed of -1 today? just letting you know.
Yep, raw is raw, i.e., not filtered or processed in any way.
appreciated.
i misread this:
sorry. my bad.
1 Like
getting back to you about the updating āissueā when and displaying āHomeā while not connected. I have a phone in repair nowā¦ been away for 4 days, and it is wiped. The life360 website displays that correctly as it states:
'User' is not connected to Life360
This user has lost connection to Life360. Visit our troubleshooting guide to help them reconnect.
*Last updated 4 days ago near Home,*
the device_tracker in HA still shows home though. and confuses all other logic based on that. I can set the state manually to get things back on track for the HA session, but after a reboot the device is back home again. I cant help thinking this is not expected behavior for your CC, and somehow could be changed to reflect the status of the life360 server, at least sense āLost connectionā ?
last_seen is correct:
last seen: 2018-09-30T18:30:31+00:00
thanks for considering againā¦
have some feature requests, maybe you could give a thought:
- automatically create a Map_url to be able to use in a camera: still_image card? like @tenly2000 does in his CC Places Would be way cool if possible. Especially if we could stay away from Google
Related would then be new attributes distance_from_home and directionā¦ I know we can use the device_tracker in Proximity and Waze travel time etc, but how nice would it be if all that would be unnecessary , and be provided by 1 complete tool?
anyways, thanks!
I think what youāre seeing is the recorder is restoring the last known state of the entity (like it does for other entities at restart.) If the last update from the Life360 server showed you at home, then it will still be that. If thereās been no further update from the Life360 server, then thereās nothing to update the state of the device_tracker.
But, you should have seen an error ā basically the same error youāre seeing from the Life360 website. Iāve definitely seen that myself in HA.
Also, when the entity is restored by the recorder, it wonāt have all the same attributes. It will only have a basic set of attributes. E.g., it shouldnāt have all the Life360 unique attributes (like moving, driving, even last_seen.)
Iāll have to give this some thought. I donāt think the state should be changed (e.g., to something like āunknownā) for every communication error. And like I said, I have seen this error before. But I suppose maybe if it happens for a minimum number of samples or a minimum amount of time, then it might make sense to do something.
But if youāre seeing the errors in HAā¦
check, that must be it.
no I havenāt seen anything other than the first error we discussed before, and the component suppressing further errors ā¦which, as I have just discovered, isnt displayed any longer in the log ?
hereās whatās showing:
Can you remind me exactly what that error was?
If you have debug turned on, can you do this:
grep -F '[custom_components.device_tracker.life360]' home-assistant.log
And let me know what that looks like? Maybe it would be best to start a private message session for this.
If the device_tracker entity has all the usual attributes, then unless Iām overlooking something, I think that means that my CC was able to communicate to the Life360 server and was able to retrieve a ānormalā response that basically just said, āhey, here you go, here is the last information I have for this member.ā Iām not sure that thereās anyway for my CC to determine from the server response that it has lost connection with the device. But, ā¦
As I said, I have seen the ālost connectionā error before, but Iām wondering if a change I made to deal with a member who is in multiple circles, but only shares their location in a subset of those circles, might have prevented the ālost connectionā error. Hmm. Iāll do some more testing to see how the current version of my CC reacts in these various scenarios.
see Life360 Device Tracker Platform - #146 by Mariusthvdb
and your repo issue#12 to suppress it
will do the debug later on, thanks!
So, turns out there is a ādisconnectedā field in the response from the Life360 server. It might be possible to use that. Unfortunately this is going to be difficult to test. Iāve seen updates for a device stop for over 5 hours, and I donāt think (although Iām not sure) that the ālost connectionā error happened during that time. (Certainly I donāt know what happened in the ādisconnectedā field because I havenāt been monitoring it.) It might take a long time before the server decides to mark a device as disconnected. And the only way for me to test that is to put my phone in airplane mode and wait for it to happen. But Iām not really willing to be without service for that long! 
(I just tried it for an hour, but neither the Life360 website, nor the disconnected field has indicated anything is wrong, other than the last update was an hour ago.)
I can try implementing something that might work. Is your phone still in the same condition, and if so, would you be willing to test it? Or have you got the phone back up and running (or will so soon)?
Iām still struggling with the same old argument, though. A lack of updates is not an update. And you do have at least two indications already that the data is excessively stale: the device_tracker.life360_update_overdue event, and the last_seen attribute. Either or both could be used in your logic to decide, based on your own requirements, to ignore the state of the corresponding entity, or otherwise alter the response of your system accordingly.
And regarding potentially adding a new āconnectedā attribute based on the ādisconnectedā field in the response from the server, that runs into the same old problem ā the only way a device tracker platform has to change the state of a device_tracker entity is to call the componentās see method. But that means the device has been āseenā, and it hasnāt. It could try and do an āend runā around the component code and update the entityās state directly in the state machine, but that is asking for trouble, and probably wouldnāt work anyway.
I still canāt see what I can do differently. The platform code is constrained by the component code in what it can do. I think you just need to use the existing indications (the overdue event and/or the last_seen attribute) and take them into account in your system logic.
But if you still feel strongly about this, then do as I suggested before ā open an issue with the device tracker component code. If it is enhanced to allow platform code a way to tell it the device has issues, then Iād be happy to implement that on the Life360 platform side.
i might have misunderstood you here, thought you wrote that component codeā¦ hence my issue on your repo. I now take it you advise me to raise an issue at life360ās address?
will do. ask them to change the state when the component had established a Lost connection. Cause thats what it is. And thats the only thing that is 100% positively true. When its lost, itās lost, and not home, not_home or any other zone. It might, but it isnāt 100% positively trueā¦
other than Support - Life360, would you have a link for their repo,/forum/community?
No, Iām not talking about opening an issue with Life360. Remember, the API weāre using is not officially documented or supported by Life360. This is a reverse engineering project.
āPlatformā and ācomponentā are HA terms. Device trackers (like many components) are implemented at two levels: component code and platform code. See Components Architecture. When I refer to the device tracker component code, Iām talking about components/device_tracker/__init__.py. And my ācustom componentā is really a device tracker platform.
So the issue is that the component code provides a limited API for the platform code. There are no provisions for a platform to tell the component that a device has lost connection. It can only say a device has been seen. And losing a connection is the exact opposite of being seen.
EDIT: This has all pretty much already been discussed on my github issues #20 and #21. And I donāt see how trying to use the ādisconnectedā field in the server response changes anything. And to be clear, I was suggesting opening an issue on the HA github repo.
Just to put my input into this idea of how to handle a device thatās not reportingā¦
When a device is disconnected, it could be home, not_home, some other HA zone, or Mars for all the system knows.
So thereās two options:
- Last known state is kept (current implementation)
- Set state to unknown, offline, whatever
The device going into state offline (option 2) shouldnāt make much difference because as was mentioned you could just look at the last_seen attribute for automations, so lets look only at how going out of a state would behave with each option. With the current behavior, if a device goes offline, nothing should trigger because nothing changes - unless of course you use last_seen as a trigger to explicitly handle that occurrence. With the proposed behavior however, when a device goes offline (lets say while itās āhomeā) the state would change and any from: home triggers would fire. The problem is, we donāt know if the device actually left home.
Ultimately, I donāt think thereās a good solution for this and you could argue it either way. To me the question is; when a device goes offline, is it more likely that it goes offline and stays at its last location, or is it more likely that it goes offline and then leaves that location? Keep in mind, although this component is typically used to determine where people are, itās ultimately a device tracker. Until we all get bio-powered GPS chips embedded in our bodies weāre not actually tracking people, weāre tracking devices. My personal opinion is that if a device goes offline, itās more reasonable to assume that it has remained at that location rather than assume that itās left. Option 1 allows for people to make this assumption and write automations accordingly, and it allows people to assume a device is no longer at that location by using the last_seen attribute in automations. Option 2 however, doesnāt allow for people to make the assumption that a device is still in the same location when it goes offline because thereās no real provision for state history.
So if weāre voting, I vote that it should remain as-is and if desired the last_seen attribute should be used.
2 Likes
yes, I follow completely, argue both ways 
only thing left in this might be that this device_tracker is the only one displaying as if its connected, while not being connected (read: show state its latest seen state, in my case āhomeā, while it could be anything). All other device_trackers I use show at least not_home or offline when disconnected.
I fully understand that could cause undesired triggers, but to that I could argue, the undesired non triggering when in a disconnected stateā¦ Both ways, I know.
If I then see that this device_tracker is the only one that knows of a certain state under which condition this happens with 100% certainty, the state I posted the screenshot of: Lost connection, Iād wager that enough reason to at least have that be reflected in its state, so automations could be triggered from that.
If I where to use a template where the state would say it is in a zone, but the attribute last_seen is overdue, that would overcomplicate things unnecessary I feel.
Then again, it is possible. Both worlds.
A device_tracker stating a state, while it knows it has a lost connection simply isnāt reliableā¦
But, it is the most reliable one up to now, so I am gratefully and happily using it as my main presence tracker 
Out of curiosity, what other device tracker platforms are you using that behave that way? Iād like to take a look to see if thereās something Iām overlooking.
np.
asuswrt
nmap
iCloud
owntracks
ping
bluetooth
iOS app Homeassistant
Places (only since yesterday, but so far seems to report correctly)
mqtt device_tracker (hand made)
and several other composite trackers
have to admit owntracks and the homeassistant app sometimes report false positives (or negatives) too, but thatās because I have set these explicitly not to update in the back, and only when in_use.
All other trackers show not_home when not connected. Bottomline: no connection = not tracked.
for this particular family member:
Not to start this all over, but I was wondering if the āLost connectionā from my screenshot is based on a dedicated server data attribute āconnectedā / ānot_connectedā, or if thats calculated, based on an algorithm on the last_seen attribute.
If it would be a dedicated attribute, you might be able to show that in the list of attributes of the component? That way the state of the component could stay as it is, namely the state life360 sent lastly, and yet providing a direct indication of the lost_connection. Which could be used on the user side logic for automations and representation.
Anyways, hope this helps, let me know if I could be of further info for you.
thx,
Marius