I’m not currently the right person to ask, I think I’ve been through too many different setups in too short a time. I am now confusing myself about what works and what doesn’t so I don’t want to muddy the waters! I’m lying low and following this thread with great interest while I calm down on my experimentation and others stabilise their developments ;-).
To be honest I had a decent (but limited) working solution with just Owntracks and NMAP combined using MAC addresses for individuals and then grouped for household presence but I kept reading about ‘better’ ways to monitor location and, well, you know how it is? I just couldn’t leave it alone…
all too familiar… but, this was new to me, and noted for references and future testing after Ive finalized setting up Life360 and mqtt tracking.
like different options and tricks in the bag, so to speak
thx!
Anyways, all works well when I leave home and at such time my EventGhost (EG) server receives this event : 22-Sep-2018 09:35:32, HTTP.EG.Life360.Away
Upon my return, EG receives: 22-Sep-2018 16:45:31, HTTP.EG.Life360.Home
(See Automation below)
Then, several minutes later , even though I have not moved away from home, EG receives: 22-Sep-2018 16:54:28, HTTP.EG.Life360.Away
This happens even though my Life360 shows at Home. I also have Life360 connected to Smarthings (ST) and it reports each event properly. In other words, ST reports: 22-Sep-2018 09:35:24, HTTP.ST.Life360.presence.not present
and 22-Sep-2018 16:45:23, HTTP.ST.Life360.presence.present
Is there something wrong with the way I setup these automations I use?
automation 23:
trigger:
platform: state
entity_id: device_tracker.cor_dikland
to: 'home'
action:
service: notify.EventGhost
data:
message: 'Life360.Home'
automation 24:
trigger:
platform: state
entity_id: device_tracker.cor_dikland
from: 'home'
action:
service: notify.EventGhost
data:
message: 'Life360.Away'
I don’t see anything wrong. Do you see any evidence of device_tracker.cor_dikland changing to not_home (or, I guess, more accurately, changing from home to something else) when you don’t expect it to? E.g., in home_assistant.log, or the history of the entity, or in the Logbook?
I am confused. Definitely something going on at my end. This morning at 6:46AM the “at home” (automation 23) automation triggered. Neither the Smarthings Life360 Connect nor the Life360 App has a corresponding event.
At 9:30Am I left home and the “Away” automation never triggered but the “Moving” one did however, that may be related to the fact I was just barely outside my home-circle and only for a brief time. When I did get back home, however, the “Moving” automation triggered… The “home” automation has yet to trigger. ST and the Life360 app do show the correct events. Very weird indeed. Anyway, here is the automation “Moving” ebvent I use,
FWIW, this last one will trigger whenever the state (state string or any attribute) of device_tracker.cor_dikland changes and in the new state the moving attribute is true. So, e.g., as you’re moving, and the GPS coordinates change (and the moving attribute also stays true), you should get multiple notifications.
If you want to know what’s going on, you’re going to have to dig deeper than just noticing whether or not your automations are firing. I suggest you look in the Logbook – there should be an entry whenever the state string of the entity changes. And you can look at the history of device_tracker.cor_dikland. But you should also look in home-assistant.log for actual state_changed events. (Note that you may need to change the logging options.) E.g., if you do something like this:
You should see information about when the Life360 platform has received new information for your device_tracker, as well as the details of the corresponding state change.
Also, are you seeing any errors anywhere (either on the Info page, or in home-assistant.log)?
The home_assitant.log shows no errors (or anything for that matter) pertaining to this device. The logbook pretty much matches the events I get from EventGhost. The history, on the other hand show something interesting. It appears I had 2 “home” locations set within the Life360 app even though both were in the exact same location. When I look at the history graph I see the event “home” in purple shortly followed by another “home” but this time in green, I have to think that the automation from: ‘home’ will/may trigger if life 360 goes from one home (green) to the other home (purple).
I removed the 2nd home from within the Life360 app and when I went out and came back this AM the events appeared correct… The only exception was the away event did not figure but I understand why. Life360 started at home then switched to"moving" The Away event should fire when the state changed from home
So, if you have places in show_as_state:, then any “Place” defined in Life360 will change the device_tracker’s state string to the name of that Life360 place (when Life360 determines you are at that place.) One exception is if the Place’s name, converted to all lower case is exactly ‘home’, then the state will become ‘home’. (All lower case ‘home’ is special.) Also note that a Life360 Place name takes precedence over the GPS coordinates. (I believe much of this is described on my doc page.)
I would definitely recommend having all "home"s be the exact same lat/lon and the exact same radius. And note that even HA itself has both a home location in the basic homeassistant config, and optionally a zone.home.
Also note that a device_tracker’s state string will never actually be ‘Away’, but rather ‘not_home’. (The frontend shows ‘not_home’ as Away, and ‘home’ as Home.) Well, unless you happen to have a Life360 Place named ‘Away’, which you probably shouldn’t.
Until you get this figured out, you might want to remove show_as_state, or at least comment it out. Then it will be based strictly on GPS coordinates and the HA Device Tracker component code will determine if this is in a HA zone.
You might want to check your config for the logger component. The default is debug, but it sounds like maybe you’ve changed that.
Note that letter case is important. As mentioned above, though, all lower case ‘home’ is special, and any Place name, when converted to all lower case, that matches ‘home’ would be changed to ‘home’. So in order to see two different “homes” (i.e., with two different colors in the history), they must be different than just the four letters h, o, m and e.
If the state was exactly ‘home’, and changed to something else, like ‘Moving’, then your away automation should have fired, if it’s still like it was when you posted it above.
BTW, you need to look at the States page, or home-assistant.log (with an appropriate level set) to see the details of the state and the exact case, because looking at the state or the history in the frontend does often use different words. E.g., as I’ve mentioned ‘home’ is shown as “Home”, and ‘not_home’ is showed as “Away”. I think it’s the same way in the Logbook.
Released version 1.5.0 – Add raw_speed and speed attributes and driving_speed config option. Derive driving attribute from speed if possible. See doc page for more details.
Note: If you’re using Custom Updater, be aware that version 2.7.2 introduced a bug that prevents the custom_updater.update_all service from working. The bug has been reported and I’m sure it will be fixed soon. In the meantime, you can still use the custom_updater.upgrade_single_component service, or simply grab a copy of custom_components/device_tracker/life360.py and install it manually as described in the doc page link above.
Awesome work. Quick question about the driving/driving speed. Does this require the life 360 paid subscription. I think driving never shows up for me (which is fine), but this is pretty cool, if it does not require the subscription model
I don’t have a subscription, and I don’t enable drive detection, and speed is still reported. It’s the isDriving field from the server (which the driving attribute was originally controlled by) that never seems to be true, at least for me. This was a suggestion to determine driving status from speed. I’ve only tested it a bit so far, and it seems to work, but the speed value from the Life360 is not very consistent. When I look at my device_tracker history it’s not uncommon to see it switch between Away, Moving and Driving several times while “I’m on the move.” And just recently it said I was going 150 mph. I can guarantee you I wasn’t!
Bottom line, this is only an estimate. Don’t count on it to be very accurate/responsive. If you don’t like it, just remove the driving_speed config item.
Well, that’s just the value that the server is providing. I have noticed that when the device is not moving that raw_speed is often zero, but sometimes it’s minus one. I want to leave raw_speed just that (i.e. the raw value from the server), but I suppose I could set speed to zero if raw_speed is <= 0.
yes that would be just fine I guess. Though you might want to round the raw speed to 2 decimals. Ive had it show 14 today (decimals that is)… which, given the reliability of the number, is a bit over the top
raw_speed is the raw speed value from the server. It is what it is. I’m just the messenger. I don’t even guarantee it’s a number. (It could be a string that looks like a number. It could sometimes be None, although I haven’t seen that.) I’m only providing it as an attribute because some suggested they would prefer to have that value and make their own decisions based on it. Therefore, if I continue to provide it as an attribute, it will not be filtered in any way. If the consensus is that it’s useless and/or bothersome then I can remove it. I get what you’re saying, but again, it’s intended to be “raw”.
Released version 1.5.1 that limits the speed attribute to non-negative values. Note that it is also possible for this attribute to be 'unknown' if it can’t properly interpret raw_speed as a number.
