Interesting. In the _update_member method you’ll see (on line 137) a commented statement that looks like this:
#_LOGGER.debug('Checking "{}, {}"'.format(f, l))
Uncomment that line and then restart HA. Then check the log. What is inside the double quotes? E.g., it should be "FIRST, LAST". Or, if the last name is completely empty, there should just be a single space between the comma and closing quote.
I don’t really know. Especially if you mean add-on as in “hass.io add-on”, since I don’t use hass.io.
The program logic was correct in handling a null lastname.
What I found was that known_devices.yaml contained both the old and new names and HA was ignoring the newer entry and not creating an entity_id for it.
Removed the first entry, and all is good now. That’s an easy one to miss! EDIT: Ah, I also missed that @ptdalen had mentioned this was one of his changes in his testing. Sorry for the trouble.
So, technically speaking, an entity_id was created (i.e., device_tracker.life360_april.) But, because track: was set to false, the entity was not “published” in the state machine, so you effectively couldn’t see it.
Is it possible you had new_device_defaults: track_new_devices set to false? See the Device Tracker page for more details.
It’s not likely I’ll create a Hass.io add-on, since again, I don’t use it. I have considered, though, trying to get this added as an official platform. But that’s a lot of work and I don’t really have the time for it right now. As a compromise, I might try adding it to the Custom Components github repo mentioned above.
I do indeed have track_new_devices : false - under the life360 platform. I do not have a new_device_defaults section, but the effect would be the same.
I didn’t realize that track: false would hide the new entity, but the main problem was me completely forgetting about known_devices.yaml.
I’m completely spoiled by how easy it is to keep up with updates in Hassio for both the core components and community add-on repo’s. Life360 is the only manual/custom component I use but it is now indispensable and I sure don’t want to miss out on any fixes or improvements.
I completely understand. Of course the trade-off with Hassio Add-ons, and Hassio itself (vs the more “basic” type install I’m using), is that they put a lot more burden on the developer than the user. Which is a good thing in general. I’m just not in a position to do that much right now.
Like I said, as a compromise I might add it to the Custom components repo at some point, which I understand has a sensor for monitoring the repo for changes. But in the meantime, you can always watch my repo (which I see you have. )
Added a feature to use Life360’s member avatars as HA entity pictures.
Given the way the device tracker component works, though, this only applies when a device (i.e., member) is first added to known_devices.yaml. Also, it appears the URL Life360 provides changes if you update the member’s picture in Life360.
So, if you want to use the Life360 avatar, then if the member is already in known_devices.yaml, or you update the picture on Life360, then you’ll need to remove the entry in known_devices.yaml and restart. I would suggest commenting it out instead of completely removing it. Then you can just uncomment your original entry and update the picture parameter from the new entry (which you can then just remove.)
FYI, this breaks device tracking if a user doesn’t have an avatar:
ue Sep 04 2018 14:46:34 GMT-0400 (Eastern Daylight Time)
Error doing job: Future exception was never retrieved
Traceback (most recent call last):
File "/usr/local/lib/python3.6/concurrent/futures/thread.py", line 56, in run
result = self.fn(*self.args, **self.kwargs)
File "/config/custom_components/device_tracker/life360.py", line 247, in _update_life360
self._update_member(m)
File "/config/custom_components/device_tracker/life360.py", line 188, in _update_member
picture = m['avatar'].strip()
AttributeError: 'NoneType' object has no attribute 'strip'
Ok, give it another try and let me know if that fixes it. (I actually made two commits because I first change KeyError to AttributeError, but then I realized it actually needs both.)
A couple more updates. Improved (hopefully ) error handling some more to (hopefully) better deal with any unexpected results from the server. Also added new config option: max_gps_accuracy (like Google Maps Location Sharing and Owntracks. See doc for more details on the new option.)
The times, like other HA entities, are reported in UTC. I’m not familiar with custom UI components, but I would think if you want a time to be shown in the local timezone, that’s where the conversion should probably be done. Maybe someone with more UI experience can comment on that.
The server does sometimes provide an address, which I could add as another attribute (similar to what Google Maps Location Sharing does.) I’ll take a look at that tomorrow.
I just wanted to say outstanding work on this. I’ve been moving everything away from SmartThings. Their presence detector would usually work but it’d be hit-or-miss at times. I tried OwnTracks with MQTT and it was even less reliable. UniFi was accurate but there was an extended delay for someone to be marked as not_home. I even used the Bayesian sensor, but it was often GIGO due to the above problems.
This has worked great. I’ve found Life 360 to be ultra-reliable for location detection, and your plugin should be included with the default build. Even the little bells and whistles like grabbing the user picture combine extremely well with the map card in Lovelace. Keep up the great work!
I was using SmartThings previously, too, and even using its official integration with Life360. But it was slow to update, ST often not realizing we were home for minutes after arriving (and hence cameras werenot getting turned off, and the thermostat was not going back to normal, etc. in a timely manner.) And sometimes ST would miss Life360 home/away updates completely (and the only way to fix the situation was to leave and come back!) There were just too many cloud services involved (Life360, Samsung Connect, and Samsung SmartThings, all between our phones and our ST hub.) Now there’s just the Life360 cloud, and updates have been much more responsive and reliable.
I won’t say Life360 has been perfect, but my experience with it has improved greatly since moving from ST to HA.
I’ve updated the code to add an address attribute. If a place name is provided by Life360 then the address attribute will be set to None (since in this case Life360 just reports the address as the name of the place.) Otherwise, any useful address information provided by Life360 will be stored in the address attribute.
)
) error handling some more to (hopefully) better deal with any unexpected results from the server. Also added new config option: max_gps_accuracy (like Google Maps Location Sharing and Owntracks. See doc for more details on the new option.)