both device_tracker.wife_phone_lan and device_tracker.wife_phone_bt show a source type of null
I have enabled debuging and it shows it has loaded
2019-09-25 18:15:53 WARNING (MainThread) [homeassistant.loader] You are using a custom integration for composite which has not been tested by Home Assistant. This component might cause stability problems, be sure to disable it if you do experience issues with Home Assistant.
Other than that nothing else in the log. The wife is not home yet so maybe some extra logs when the device trackers change state I will update later if anything else.
Then they probably aren’t actually working. Are you sure they are actually updating? They should definitely have valid values for their source_type attributes. Note that the entities will be created from entries in known_devices.yaml, even if they’re not working.
I noticed a typo in your nmap_tracker config. The track_new_devices: yes line needs to be indented under new_device_defaults:. I wonder if this is causing a problem at least with the nmap trackers.
Turn on debug for for composite as I suggested above. It will output additional lines (you’ll need to look in home-assistant.log) whenever the tracker updates from one of its input trackers (and it will say which one.) You can also enable debug for bluetooth_tracker & nmap_tracker. If you’re not sure how to do that, then add this to your configuration:
logger:
default: info
logs:
custom_components.composite: debug
homeassistant.components.bluetooth_tracker: debug
homeassistant.components.nmap_tracker: debug
And rather than keep quoting you…
Your next paragraph makes absolutely perfect sense.
Your last paragraph would I suspect ‘satisfy my request’ but with hindsight and a little distance from this afternoons google too-ing and fro-ing I think might have been a knee jerk reaction trying to improve on something that was already close to perfection. What I am/was asking for might well be such an edge case (and should be if everything is working close to how it should be) that I wonder if it is worth the risk of introducing anything new.
I do think your suggestion would solve this scenario but I leave it to you to decide if it is worth implementing. I am very much on the fence…
Either way thanks (as always) for the consideration.
I’m pretty sure a “legacy” device_tracker entity’s source_type attribute will be null when it is first created at startup (from entries in known_devices.yaml) and will only stay that way if they don’t actually update.
Just enable the debug logging as I suggested then look in home-assistant.log for corresponding entries. I’m sure that will help shed light on what is going on (or not going on.) It might help to minimize other log entries with:
I have set up the logs as suggested.
Composite device tracker device_tracker.me gets updated several time but device_tracker.wife dose not appear at all. Even though the 2 listed device trackers change state.
Are you sure you have the entity_id’s spelled correctly in your wife’s composite config? I’m pretty sure what you posted above has been redacted. Maybe share the real config, as well as some snippets from the log, with me via PM???
Also, going back to the source_type attributes of these nmap & bt trackers. You had said they were null. Do they stay that way? If so, eventually the composite tracker will reject them and stop listening for their state changes. But if it does so there will be a warning and an error message about it in the log. (Will look something like this: <entity_id> unsupported source_type: <source_type>) Do you see those?
Can you capture some updates of these device_tracker entities? Maybe something like this:
This will create a file named wife_trackers.log in you config directory which will contain lines for each state change of the specified device_tracker entities. Maybe let the system run for a while and then take a look at this file, and maybe post the results here or PM them to me.
HI Phil, after having used your CC for a long and successful time, I seem to have run in to issues after updating to the latest version using the require_movement option.
Before, it would keep the constant triggering of the networked device_tracker covered by adding the life360 device_tracker.
Now, when the actual device is and remains in the home, the triggering has returned.
would you be able to explain this? Should I maybe set the require_movement to false, or not even use it. It is the only setting I added/changed.
Can it be that because the life360 reports no movement, it isnt tracked any longer, and tracking is based solely on the network devices… which continue to go on- and offline even while remaining place (the old issue…)
hence this require_movement brings that all back?
It was quite a nasty thing because this composite device is part of a group.family, on which state several rather important and impactful automations are based… switching the house in empty mode, turning off devices and computers… You can understand the mayhem caused by this or even…
thanks for having a look.
I’ve looked over the code and I’m not sure how this can happen. Not saying it isn’t; just not sure how it can.
If you don’t need the new feature, then simply set it to false, or remove it from your config (the default is false.) It should then work the way it did before.
Thanks Phil,
well, what can I say, the behavior is as I described.
At least could you confirm that what I pose here:
is true? life360 being the only gps tracker in the group, stops reporting because no movement, leave the rest of the changes to the networked devices. Which as we all know keep (dis)connecting and thus (falsely) triggering the home/not_home state?
I’ve done as you suggest (leave it out completely), and no more issues have arisen.
You can check the composite device_tracker's entity_id attribute to see if the life360 device_tracker entity has been seen yet by the composite device_tracker since HA started. If it’s listed, then it doesn’t matter if it never updates again, or if its updates are ignored due to no movement. Basically, the "ignore non-GPS updates except for home" algorithm “kicks in” once there is at least one GPS-based tracker listed in the entity_id attribute.
I am confused… you now mention "ignore **non-**GPS updates except for home " algorithm while the GitHub states:
**require_movement** ( *Optional* ): `true` or `false` . Default is `false` . If `true` , will skip update from a GPS-based tracker if it has not moved.
which led me to understand that if set to true, and the GPS-based tracker has no moved, it will skip this GPS-tracker, and then only update based on the other (non GPS-) trackers. (which in my case are networked trackers that flip frequently, so the CC follows that, as long as the GPS-trackers has not moved…)
It keeps track of which device_tracker's it has seen. It does not forget a device once it has seen it (unless it has fatal errors.) So, even if it skips some updates (if the tracker is no longer moving), it still remembers that it has seen it. Once it has seen at least one update from at least one GPS-based tracker, it will then ignore updates from non-GPS trackers unless they are home.
I have what is probably a lazy question, meaning I am sure the answer is in this thread somewhere.
Am I right in thinking that the Composite Tracker adopts the actual state of the last seen tracker? i.e. if the Life360 state is ‘driving’ will the composite have a state of ‘driving’?
And if yes, would I be right in thinking that if using a second GPS based tracker in parallel, this state of ‘driving’ may not be very useful as the second GPS tracker will probably cause the state to flip-flop between ‘driving’ and ‘away’?
This is all prompted by my very late realisation that Life360 can be configured to take ‘moving’ and ‘driving’ as its state.
For GPS-based trackers it only uses the GPS data (and some other attributes if they exist, like for battery, last_seen, etc.) It does not use the state string.
I’m using/evaluating your composite tracker and wonder about something: in the code, I find this:
# If router entity's state is 'home' and current GPS data from
# composite entity is available and is in 'zone.home',
# use it and make source_type gps.
Why are you making it source_type gps in this case?
The reason I’m asking is that I also use a binary sensor. Currently, the binary sensor is on and it still shows source_type=gps. I would have thought that the binary_sensor has precedence and would result in source_type=router.
If I read the docs about the Person component, also there the device_trackers that are not GPS get precedence.
If there are stationary trackers (non-GPS trackers, i.e., a router or Bluetooth ‘device_trackers’) presenting the status ‘home’, the tracker most recently updated will be used.
If there are trackers of type ‘gps’, then the most recently updated tracker will be used.
Otherwise, the latest tracker with status ‘not_home’ will be used.
I didn’t write the person component, and honestly don’t agree with how it works (which is why I don’t use it.) You’d have to ask whoever wrote it why they decided to implement it that way.
As far as which type “takes precedence,” that’s not how it works. The latest to update “takes precedence.” I.e., the newest, most up-to-date information is used. The main exception is, if GPS-based trackers have been seen, then for non-GPS-based trackers, only their 'home’ state will be used, because they (well, at least, router-based ones) are notoriously bad in guessing when the device is no longer home. (And that’s just what they do, they guess.)
Now, getting back to your question about why the source_type is changed to gps. That’s necessary to use GPS data, otherwise it would be ignored by the device_tracker component-level code.
If you want to know which entity contributed to the current state of the composite device tracker entity, just check its last_entity_id attribute.
or 
even…