Released version 1.4.0.
Minor update to make sure name provided in configuration is converted to a valid device_tracker object_id if necessary.
Released version 1.5.0.
The code was waiting for the homeassistant_start event before updating the composite components. Also it was waiting for the tracked components to change as well. The end result was, after a restart, the composite components were not getting updated to reflect the status of the tracked components (until one of them changed.)
The new version removes the initialization delay, and immediately updates composite components based on the current status of their corresponding tracked components.
not sure what is happening, but after both updating to hassio 0.80.3 and the latest component version,
the logs show:
2018-10-20 16:00:11 ERROR (SyncWorker_3) [custom_components.device_tracker.composite] device_tracker.ios_phone unsupported source_type: None
it does this for my app devices, regular wifi and ping trackers.
Does it do this continually, or just for a short time at startup? I may need to make the new updates immediately after startup a bit more selective if some device trackers take a while to get into a good state. FWIW, it works fine for me with Life360, Google Maps Location Sharing and ping trackers. Oh, and I’m still on 0.77.2.
For now, I think it might do so only at startup yes.
On many device_trackers, also on ping:
2018-10-20 23:29:33 ERROR (SyncWorker_14) [custom_components.device_tracker.composite] device_tracker.ping_iphone_m unsupported source_type: None
this is the regular device_tracker ping, not the binary ping.
please notice it i also doing so with the regular wifi device_tracker using Nmap.
not sure if this is related, but the newer Ha versions seem to have issues with ping sensors. Believed the to be resolved in 80.3, so I am not sure this is related to that. Or maybe my specific tracker settings.
Ive set these trackers to be a littler easier on the processor, by not tracking each 20 seconds as default but per interval_seconds: 120
Good day. Thank you for the latest update. I upgraded to 1.5.0 and have experienced a few issues:
I was using the Suresh Kalavala life360 component and hadn’t migrated to yours, because that one was available a while back and was working ok. After 1.5.0 it stopped working with composite tracker. I migrated to your life360 and works perfect with composite tracker as expected 
Im also using the GPS logger (https://www.home-assistant.io/components/device_tracker.gpslogger/). It was working fine with composite tracker 1.4.0, but now it stopped. I get the below log error, which is the same I was getting with the Kalavala life360 component.
2018-10-22 09:34:18 ERROR (SyncWorker_5) [custom_components.device_tracker.composite] device_tracker.juan unsupported source_type: None
2018-10-22 09:34:18 ERROR (SyncWorker_29) [custom_components.device_tracker.composite] device_tracker.magda unsupported source_type: None
Perhaps additional conf required?
thank you again
When you say they “stopped working”, and you received the “unsupported source_type” errors, did that happen just at startup, or did you see these errors continually?
The recent change to 1.5.0 added an update of the composite devices by checking the current state of the watched trackers immediately after startup. The errors you are seeing do not indicate that the composite tracker “stopped working”, they indicate that the corresponding watched devices do not have a valid state at that time. If they have any state at all, then the source_type should be valid, but the error is indicating that they do not. I think this is what you are seeing.
As I mentioned above I can enhance the composite tracker to be more selective when using watched tracker states at startup (basically ignore invalid states.) But before I do so, I’d like to investigate why some of your tracker devices have invalid states in the first place.
Could you run the following command and share the output with me? If there is any sensitive data (such as gps location) feel free to redact it, or you could send it to me via private message if you’d prefer.
grep old_state=None home-assistant.log | grep 'new_state=<state device_tracker[^;]*;'
@Mariusthvdb, if you could provide the same data, I’d appreciate it.
EDIT: I should also mention, if you’re just seeing these errors once at startup (which I suspect to be the case), please realize that is not preventing the composite trackers from continuing to work and update as the watched trackers update. I believe what you’re seeing is just a one time, unexpected input value, not a composite device failure. If you are seeing the composite devices no longer working, then by all means, please let me know.
Thank you for your reply. The error appeared on start-up and neither device_tracker (old_life360, gpslogger) were reporting into composite_tracker (composite_tracker was not receiving data).
Homeassistant could not use long&lat to present anything on googlemap or any map. Location was reported only by the router when at home. Basically I had no gps data from either tracker.
when I switched to your life360, it came back on and operation seems normal, but Im almost sure it’s not using gpslogger at all. If I do a state query on the developer console all i get is “last_entity_id=device_tracker.life360_juan_perez,”. It’s only using life360.
I’m running docker so I went into the container in the /config folder and run your command. I got nothing.
Ok, I figured out what’s going on. When a watched device_tracker’s source_type attribute is not one of the expected values, it’s immediately being “rejected” from the list of watched entities, so any further updates from that tracker are being ignored by the composite device. This was done because I expected any valid device_tracker to always have a valid source_type, so if the source_type was ever not valid I assumed that would just cause a stream of errors for that tracker, and hence, I stopped watching it.
I don’t understand why any “valid” device_tracker entity would ever have a invalid source_type, but apparently it can happen. I’ll try to get a new version out today that handles this scenario better.
One example was my apple watch. It received that error. It uses my wifi as a device tracker, but it’s rarely on wifi. I think it may have been weeks since it was actully “present”. It would only be on wifi if my phone was in airplane mode (or dead). I actually cannot think of a time where I really needed it as a presence sensor, but I figured what the heck, maybe I would come home with a dead phone, and my watch could save the day. haha.
1 Like
If you’re wondering how each of the watched device_trackers is contributing to the composite, especially which one is first updating when coming or leaving home, you can use something like the following:
notify:
- platform: file
name: composite_me
filename: composite_me.log
timestamp: True
automation:
- alias: Composite Updates for Me
trigger:
- platform: state
entity_id: device_tracker.COMPOSITE_ME
to: 'home'
- platform: state
entity_id: device_tracker.COMPOSITE_ME
from: 'home'
action:
service: notify.composite_me
data_template:
message: "{{ trigger.to_state.state }}: {{ trigger.to_state.attributes.last_entity_id }}"
This will generate a log file that will list which watched device_tracker caused the composite device_tracker to change to or from home. I just started such a log yesterday for myself and my wife. For me, there were six transitions, and all except one was caused by Life360. The other was caused by a ping tracker when coming home. For my wife, there were two by Life360 and three by Google Maps Location Sharing. (I use Life360, Google Maps Location Sharing, and ping for both myself and my wife.)
Note that the last_entity_id attribute only shows the watched tracker that caused the last state change of the composite. If you want to know all the watched entities that have at one time or another changed the state of the composite since startup, that would be the entity_id attribute.
Did you wait for the commands to finish? Depending on how big your log is and how fast your system is, it might a few seconds. Or is it possible you’ve got your logger configuration set so these might not show up??? What this should result in are INFO messages from homeassistant.core. There should be one for each device_tracker entity, including the composite one(s.) Hmm, or maybe you haven’t restarted for a while and your log has flushed old data such that the info at startup is gone???
If you, or anyone, could do this and provide me the output, either here or via PM, that would be helpful. Without it I’m just guessing as to how to work around this scenario (which doesn’t happen for me.) Again, here are the commands to run:
grep old_state=None home-assistant.log | grep 'new_state=<state device_tracker[^;]*;'
I would think this should work for anyone, as long as INFO logger messages from homeassistant.core are enabled.
Thank you this is the
entity_id=('device_tracker.life360_juan_perez',),
only life360
I set up logger to default:info and run the command. I still get nothing.
I have a beta fix for the issue with invalid device_tracker states at startup. If someone who has experienced this issue could try it out and let me know how it works, that would be appreciated. You can get the beta version here.
Ok. Not sure why you’re not getting any output, but thanks for trying anyway.
ok, so I tried your beta and whilst Im still getting the “unsupported source_type: None” error on start up, It now shows both trackers on entity id.
see below
<template state device_tracker.juan_composite=home; source_type=gps, latitude=xx, longitude=xx, gps_accuracy=21, battery=100.0, entity_id=('device_tracker.juan', 'device_tracker.life360_juan'), last_entity_id=device_tracker.juan, last_seen=2018-10-22T22:06:36+04:00, scanner=NetgearDeviceScanner, friendly_name=Juan Mobile, entity_picture=/local/family/Juan.png @ 2018-10-22T22:01:01.166346+04:00>
I can positively say the error messages are gone. thank you very much sir!
Great! 
That is expected. It still shows the error if any (actually it should be a warning, not an error), but that should no longer prevent it from watching for further updates from the offending device_tracker (which appears to be the case now based on what you said.)
Um, I have no idea how your composite entity is getting that attribute. That’s weird.