I must have said this in another topic, but I did send an e-mail to the person who wrote the Person component and told him about this code and said he should feel free to leverage it. I did not get a response. Feel free to make the same suggestion. I’d be happy if they benefited from my work to make the Person component better. One less thing for me to maintain. 
1 Like
I’m not sure if this is a stupid question but how do we do that?
Your custom components are all exceptionally good and I would love to see this one especially (or the features it offers) become part of the core HA.
I’d miss your support though 
1 Like
Sad that no response… But not a surprise.
I’m pretty sure the person system was designed around who’s logged into home assistant and what area they are in. I.E. This is the foundation of displaying views/cards based on who is where. I.E. simple user access controls for the UI. I think that’s going to be the focus at first. Then all the other stuff will improve over time.
Well, as usual, when you get all the information it seems reasonable.
It is a shame no one communicated back to @pnbruckner or that the information given out with new features is often so sparse.
And yes, I know that (1) you are only passing on what you know or have heard/read and (2) that disseminating information is time consuming and not always high on the agenda of something like an open source ‘volunteer’ run project.
They probably aren’t documented due to the fact that there isn’t much to them yet. Same with the new area domian, it only works with like 40 components.
so what’s stopping you guys from using this custom component as a device tracker inside the person? I know it’s an extra layer, but wouldn’t it be the same thing essentially?
Released 1.7.2
Apparently HA 0.92 will require all custom components to have a manifest.json file. And the custom updater requires the component to have an __init__.py file to load other files. This release should work with 0.92 and the latest custom updater.
NOTE: Because of the reorganization, it’s possible the custom updater may not be able to simply update the component. You may need to install it again using the
custom_updater.installservice. You may want to get the latest version before updating to 0.92.
@pnbruckner thank you for this component.
Looking for a bit of advice; I’m using your life360 + googlelocation. Whenever I leave home the tracker cycles through enter/leave 5 or 6 times. This only happens at home and I suspect is related to the gps going dormant or similar.
Have you experienced similar? Any ideas to mitigate?
Thank you again.
Released 1.7.4
Sorry for any inconvenience. In trying to get ready for 0.92 I seem to have messed up support for the current release (multiple times. Argh! 
) The latest mistake was putting the REQUIREMENTS and DEPENDENCIES statements back in the wrong place. Everything worked if the component was installed via custom_updater, but not if manually installed (and the pypi.org packages weren’t already installed.)
Are you combining the life360 & google_maps trackers via this composite tracker? Have you set logger to debug and looked in home-assistant.log for related events?
FWIW, I use life360 & google_maps combined using this composite tracker, and I haven’t experienced anything like what you describe.
If you’d like to post your life360, googe_maps and/or composite device_tracker configs (redacting any sensitive information) I’d be happy to take a look to see if there’s anything questionable. Also, what is the radius of zone.home?
@pnbruckner
thank you. That’s correct; using life360 & google_maps trackers via this composite tracker. not activated the logger. I’ll do that.
this is the config:
- platform: composite
name: magda_composite
entity_id:
- device_tracker.life360_m_m
- device_tracker.google_maps_XXXXXXXX
- platform: life360
username: !secret life360_username
password: !secret life360_password
prefix: life360
show_as_state: driving, moving, places
driving_speed: 18
max_gps_accuracy: 200
max_update_wait:
minutes: 45
members:
- M, M
- J, P
interval_seconds: 10
filename: life360.conf
home radius is radius: 75
thank you again
First, if you haven’t already, you should read this section from the Life360 doc page that talks about how being home is determined, and especially how it is affected by the various configuration variables.
I would recommend either a) removing places from the show_as_state configuration variable, or b) adding add_zones with a value of at least only_home, or all if you’d prefer, or c) doing both a & b.
Note that HA determines a device_tracker is home by looking at two circles: the circle defining zone.home, and the circle that represents where the device tracker is. For zone.home it uses its location and radius. For a device_tracker, it uses the current values of its location and its gps_accuracy. So let’s say you were home and move outside the home zone circle. As soon as the circle representing your device tracker no longer overlaps with the home zone circle, HA will change the status to not_home. Now let’s say before you get too far away the device tracker’s gps_accuracy increases (i.e., gets worse.) The circle that now represents the device tracker is bigger than it was, and if it overlaps with the home zone again, the device tracker’s state will be changed back to home. I don’t know if this is what is happening in your case, but I suppose it’s possible. You might want to try reducing the max_gps_accuracy configuration variable and see if that helps. (Basically this is the largest value of gps_accuracy it will accept. If the accuracy gets worse than that – i.e., the number gets bigger – the location update will be rejected.)
@pnbruckner
Thank you for taking the time to look as well as offering advise. I have amended accordingly and will report back.
Hello, it’s likely I’m missing a core part of the desired functionality, but I have the Composite Device Tracker setup with your Life360 component, as well as a router device tracker and some bluetooth device trackers (Monitor, to be precise). It seems to work really well, however sometimes, when I’ve been home for hours, the Life360 tracker will incorrectly report that I’ve left, and even though the bluetooth trackers show that I’m home, the Composite tracker shows that I’m not home as well.
Is there a way to make the Composite tracker show that I’m home if either the Life360, router, or bluetooth trackers show that I’m home?
If the Life360 tracker is saying you’re not home, but you are, then there’s no way the composite tracker can know that that’s bad data. You should resolve that problem rather than trying to mask it or filter it out. What does the Life360 app and/or website say? If it also says you’re not home, then maybe you need to check how your phone is configured because it might be providing incorrect GPS data to Life360. I’d check their FAQs if I were you.
What does your Life360 configuration look like? It’s possibly you may have something misconfigured there.
Regarding the non-GPS-based trackers, the composite tracker only updates when one of the input trackers changes state (which is actually true for both non-GPS and GPS), so if they’re not changing to home then the composite won’t update. Basically the composite tracker is event based, not poll based.
The bottom line is, when using both GPS and non-GPS trackers, it always believes GPS tracker updates, but only believes the to home transitions of non-GPS trackers (because non-GPS trackers are notoriously bad about reporting false “not home” states.)
I might have some weirdness going on.
Or it might be something else 
My composite reported a momentary away state and yet none of my device trackers showed this.
This is my config (two GPS based and one router):
- platform: composite
name: me_composite
entity_id:
- device_tracker.life360_me
- device_tracker.google_maps_xxxxxxxxx
- device_tracker.me_phone_unifi
time_as: device_or_local
Here are some screen shots, firstly the composite showing when it thinks I’m home then away then home, followed by the individual device trackers
Any chance HA restarted at 4:04 PM?
Is there anything in home-assistant.log that shows what happened around that time, especially with the device_trackers?
No restart.
The reason I know this happened is because I was outside for a couple of minutes but well within range of the router and when I came in I got my ‘alarm deactivated’ announcement. Looking at my alarm history though it was never out of ‘Disarmed’. I suppose it might have been pending which means my automation is not quite right there but that is another story.
Log is below (nothing to see)…
Unless the response code 500 is relevant but that seems a bit early. (the tts error is common for me as it is my automation trying to restore my Sonos after the alarm notification but it couldn’t because I delete my tts cache every night).
2019-06-03 15:55:00 ERROR (SyncWorker_3) [homeassistant.components.waze_travel_time.sensor] Error on retrieving data: empty response
2019-06-03 15:58:20 WARNING (SyncWorker_6) [locationsharinglib.Service] Received response code:500
2019-06-03 16:00:00 ERROR (SyncWorker_4) [homeassistant.components.waze_travel_time.sensor] Error on retrieving data: empty response
2019-06-03 16:05:04 ERROR (SyncWorker_8) [homeassistant.components.waze_travel_time.sensor] Error on retrieving data: empty response
2019-06-03 16:05:04 ERROR (SyncWorker_7) [homeassistant.components.waze_travel_time.sensor] Error on retrieving data: empty response
2019-06-03 16:05:20 ERROR (MainThread) [homeassistant.components.tts] Error on load tts: a94a8fe5ccb19ba61c4c0873d391e987982fbbd3_en-uk_-_google_translate not in cache!
Well it asks HA to tell it whenever any of the input trackers change state, which is the only time it will update. So a state_changed event must have happened (actually two, if it changed to not_home and then back to home.) Either you’ll need to look in your database, or for the future, you can enable debug for homeassisant.core, which will log state_changed events to home-assistant.log. Or was there anything in the Logbook? Without the raw state_changed data that it takes as input, there’s no way I can speculate on why you saw what you saw.