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.
After upgrading to 0.94.0 I am getting
Platform not found: device_tracker.composite
Platform not found: device_tracker.ping_arp
when doing a configuration check, device trackers are not being updated.
This may be due to the same changes that I had to prepare life360 for. I’ll look into it.
Hi there, since 0.94 composite seems to report the wrong state. I am getting always away regardless the attached trackers are home. I can’t spot any error in the logs. Can I help troubleshoot this in any way?
Released 1.7.5
Updated to be compatible with changes in HA 0.94.0 release.
FYI, for some reason when a custom integration cannot be loaded there are no visible error messages. However, if you run Check Config, it will tell you.
After you upgrade to 1.7.5 let me know how it works for you.
I was just coming back as I spotted that not_found error in the config check, however your speed was astonishing!!! I can confirm I have updated to 1.7.5, reverted the config for person to use the composite component trackers, and it is working well again! Thanks @pnbruckner !
I have been testing the component and I am wondering what logic is it using, let me give you an example.
I have attached a nMap tracker and a GMaps tracker, the first doesn’t see the phone since 11hrs 58m as the phone left the house, therefore it is in “not_home” since then, however since the phone exceptionally does not have mobile data today, maps has not updated its status since about the same time and shows still “home”. As a result, composite shows the main device as at home. Is this expected? I thought it was going to grab the result from the not_home nMap tracker which does update often.
Further to my recent weirdness I have ‘caught’ the Composite appearing to be behaving in an unexpected fashion.
Cutting straight to the chase, the Composite is reporting Away when the only router based device tracker is showing Home.
Briefly, both Life360 and Google Maps have drifted on this phone to be just outside the Home zone. I am not sure what information you might be interested in (if any 
) so I will wait to hear from you before flooding you with information that will in any case not have changed from my previous post a week or so ago.
I should add that the Composite has been giving me perfect service for many months and it has only been since I lost my Bluetooth tracker* that things began to show signs of strangeness.
*Since I moved to a NUC running Proxmox. At some point I plan to get it back by moving to Ubuntu and Docker but I need to not only learn a bit more about how that works but also find time to actually do it.