As for me setting movement required: if one gps tracker moves and updates, and after that another tracher that is not moving (since before the previous update!) updates, isn’t that strange? Isn’t it more likely that moving sensor is the most accurate and the second one reposting stale data?
That’s why the composite doesn’t just use any and all state updates of the input entities.
When an input entity updates, the composite looks at the full state to see if there is any indication of how old the information is. Some device tracker integrations (such as Life360 & Google Maps) provide a last_seen attribute that indicates when the GPS data was last updated. If the value is older than the age of the current data the composite is using, then the update is ignored, since it’s not the “most recent” data. Note that tracker integrations can update their entities for other reasons (besides the basic location information), such as battery status, etc.
If you have debug enabled, the composite integration outputs a debug message saying if it is updating based on the input entity, or if it’s ignoring the state change and why (e.g., it has older data than the composite already has.)
Other tracker integrations do not provide an indication of how old the basic location information is, and so the composite integration has to fall back to the state’s last_updated field. It’s unfortunate that these integrations potentially provide insufficient data. If the integration is saying there’s new location data when there really isn’t, there’s not much the composite can do about it.
If some of the entities you are using as inputs to the composite tracker do not provide a last_seen attribute, then the “require movement” feature might actually help (even though that wasn’t what the feature was originally created for.) If one of these entities updates for some other reason (e.g., battery), but the GPS data hasn’t changed, then the update will be ignored if you have set require movement to true.
FWIW, as of now the require_movement setting applies to all of the input entities of a composite. However, there are times when you might only want to use this feature with a subset of the input entities, so I’m considering allowing it to be set individually for each input entity (like the all_states option.)
Well, at this point, the details of exactly what you did and when are lost, so it’s kind of hard to say why you had issues that seem to have gone away now. I can guess what might have been the cause, but that’s all.
If you have any other issues, by all means, please let me know. If there’s a flaw, of course I want to find it and fix it. Enabling debug can help provide additional data for diagnosing problems. And now you have a rough idea of what other types of information would be helpful.
BTW, now that the composite entities are editable via the Entities page, you can change the name or entity ID if you want via that mechanism. Or you can do it via the YAML config (e.g., see the new id option):
- name: Jasper's samengestelde locatie
id: composite_jasper
time_as: device_or_local
require_movement: true
entity_id:
- entity: device_tracker.oneplus_jasper
all_states: true
- entity: device_tracker.google_maps_jasper
all_states: true
- device_tracker.ip_jasper_mobiel
- device_tracker.jasper_tado_non_gps_tracker
Regarding the all_states option, assuming the source_type attribute of the device_tracker.oneplus_jasper & device_tracker.google_maps_jasper entites is gps, as I mentioned before, you don’t need to specify true for those (although, of course, it doesn’t hurt if you do.)
What is the source_type of device_tracker.ip_jasper_mobiel & device_tracker.jasper_tado_non_gps_tracker? I’m guessing it’s router for device_tracker.ip_jasper_mobiel, which should be fine.
But what about device_tracker.jasper_tado_non_gps_tracker? I’m guessing it’s gps. And I’m guessing that it doesn’t have gps attributes (i.e., latitude, longitude & gps_accuracy). If that is the case, then the composite is basically going to reject it (and there should be a warning and error indicating this.) That seems to be confirmed by the full state of the composite you shared above. I.e., you can see it is not listed in the composite entity’s entity_id attribute. This is because an input entity whose source_type is gps is supposed to have gps attributes. But, since you created it via the device_tracker.see service and did not provide gps attributes, it’s basically malformed, at least as far as the composite integration is concerned.
If this is the case, one way to work around it is to add source_type: router to the device_tracker.see service call. E.g.:
alias: Tado locatie Jasper gewijzigd
trigger:
- platform: state
entity_id:
- device_tracker.jasper_s_telefoon
action:
- service: device_tracker.see
data:
dev_id: jasper_tado_non_gps_tracker
location_name: "{{ states('device_tracker.jasper_s_telefoon') }}"
source_type: router
mode: single
This is not documented, but it is a valid input for the service call. Then set all_states: true for it in the composite configuration:
- name: Jasper's samengestelde locatie
id: composite_jasper
time_as: device_or_local
require_movement: true
entity_id:
- device_tracker.oneplus_jasper
- device_tracker.google_maps_jasper
- device_tracker.ip_jasper_mobiel
- entity: device_tracker.jasper_tado_non_gps_tracker
all_states: true
Ah, thanks for that. I tried setting the source_type but could not find a way to do it. E.g. customize wouldn’t allow it. It is a bit of a shame you cannot create device trackers through a template. Source type was null now.
It just requires someone to write the code and convince the core team to accept it. 
BTW, you could also do it in a python_script. Then you would have full control of the resulting device_tracker entity’s state (& attributes.)
Hmm, that was not what I was expecting. FWIW, I just tried calling device_tracker.see via the services tab like this:
service: device_tracker.see
data:
dev_id: test
location_name: abc
And the source_type of the resulting device_tracker.test entity was gps:
I don’t see how it could be null.
EDIT: Per discussion below, yes, the first state update will indeed have a source_type of null. This is because the device tracker component level code creates the entity based on the entry in known_devices.yaml, but other than that, there’s no saved state. But, also per the discussion below, the composite integration was designed to effectively ignore this state. Remember, this integration was created way back when all device tracker integrations were “legacy” trackers and worked this way.
It is null after a restart, so your trick does not work. I think you already reject the tracker before I can set the right value. So I must use MQTT or python instead. Didn’t know about the python version, and have no other use for mqtt right now, so I’ll look into the python method.
The first time it sees a state change for a particular entity it will simply use it or not, but if not, it won’t even generate a warning. After that, if it sees a state change for that entity, and it doesn’t like it (for whatever reason), it will generate a warning, but won’t yet reject it. If it sees two consecutive state changes for a particular entity that it doesn’t like (with no “good” state changes in between), then it will generate an error and then reject the entity (and won’t listen to it until a restart.)
Again, are you seeing any warnings or errors? Up until now you’ve said you aren’t, but that doesn’t seem to jive with the descriptions you’ve given, or at least, the assumptions you seem to be making.
So, it would basically have to have three straight state changes, all of which are “bad”, before the composite will reject it. I’m sure the first state change is the device tracker component creating the entity based on the entry in known_devices.yaml. It will probably have no have a source_type attributesource_type of null, so that will be one bad state change. It shouldn’t change again until the device_tracker.see service is called. If that includes a source_type of router, then it should work ok.
When you say, “before I can set the right value”, what exactly do you mean by that? Do you mean calling the device_tracker.see service via the automation, or something else?
What I meant is that on startup the state_class is null (even if it wasn’t before the restart), and because of that you still don’t list the tracker in the attributes. My assumption was that that meant you wouldn’t listen to state changes. If so then setting the state_class with see won’t matter anymore, hence too late.
As for warnings or errors, I’ve looked again. There’s nothing there. But we’ve been home all four, and Jasper probably won’t leave home until monday, so looking for errors is not that useful right now.
By “state_class” I assume you mean the source_type attribute. 
The input entity’s entity ID is only listed in the composite entity’s entity_id attribute when the input entity changes state, and the state is “ok” (even if it’s not actually used to otherwise update the composite entity.)
As we’ve discussed, the first state change of the entity in question is not “ok”, because its source_type attribute is null. However, once your automation fires, and calls the device_tracker.see service with valid parameters (i.e., with “source_type: router” in this case), then it will get added to the composite entity’s entity_id attribute, and should update the composite entity’s state string to reflect the zone it is in (or set to not_home if it isn’t in a zone.)
Personally, I would not be trying to use this device_tracker entity this way as an input to the composite tracker, because it will cause the composite to lose its GPS attributes. But if that doesn’t matter to you, then sure, go ahead and use it. It should work, again if you add the source_type to the device_tracker.see service call.
Note that you can test this out by calling the device_tracker.see service via the SERVICES tab of the Developer Tools page, as long as doing so doesn’t cause the rest of your system to do something you don’t want (e.g., trigger some automation, etc.)
I’m pretty sure this will work the way you want. Try it out and let me know.
Bottom line, though, maybe this entity isn’t as useful as it should be because, as you say, it removes the decimals from the GPS coordinates. That’s weird.
FWIW, I’ve also been browsing the tado device tracker code. I have to do some more reading, but are you sure it’s creating a device_tracker entity whose source_type attribute is gps and has the other GPS attributes (latitude, longitude & gps_accuracy)? I would think it would be creating a device tracker with router as its source_type. Hmm…
EDIT:
Looking back at your original message, it looks like this entity is only home or away. So, it really seems to act like a router-based device tracker entity. If its source_type is really router, and its state is only ever home or away (actually, home or not_home), then you shouldn’t need this intermediate entity you’re creating via the device_tracker.see service. And you probably should not be configuring the composite to use all of its states. If my assumptions are correct, then the best way to use this entity as an input to the composite is to just add it to the entity_id list in the composite’s configuration. It should use it just like it uses the ping tracker.
I’d really be interested to see what the full states are of the original tado device_tracker entity (of course redacting any location or other personal data.) I really expect it to have a source_type of router, and only the states home or not_home (of course translated in the UI), and it looks like it might also have GPS attributes (which are basically HA’s configuration of your Home’s location) when the entity is home. If this is the case, I think you should be able to just use it “as is” with the composite without the complication of the intermediate entity.
The real Tado tracker looks like a gps tracker, complete with coordinates but type router. But the coordinates are not accurate unless it is home. The documentation states: “Beware that the Tado (v2) API does not provide GPS location of devices, only a bearing, therefore Home Assistant only uses home /not-home status”. That is why I decided to try to strip the gps coordinates, because I was afraid it would otherwise do more harm than good in your integration.
source_type: router
latitude: .....
longitude: ...
gps_accuracy: 0
scanner: TadoDeviceScanner
friendly_name: Jasper's telefoon
So the best I can tell from reading the tado and device tracker component level legacy code is that those GPS coordinates are just the coordinates of HA’s home zone. Take a look at zone.home on the STATES tab. Are the latitude & longitude values you see for this tado entity the same as the values for zone.home? And when this tado entity is not home, does it still have latitude & longitude attributes?
Unless I’m still missing something, I think you should be able to just use the real Tado tracker, as is, as an input to the composite tracker, and I would recommend not setting all_states to true for it (i.e., just list the entity ID.)
1 Like
Hi, I just got around to setting the Tado tracker back to the original one. I don’t know if that triggered it, but now the logs show this for all the compound trackers:
2022-12-09 12:15:40.953 ERROR (MainThread) [homeassistant] Error doing job: Future exception was never retrieved
Traceback (most recent call last):
File "/usr/local/lib/python3.10/concurrent/futures/thread.py", line 58, in run
result = self.fn(*self.args, **self.kwargs)
File "/usr/src/homeassistant/homeassistant/components/proximity/__init__.py", line 267, in check_proximity_state_change
self.dist_to = round(distances_to_zone[entity])
KeyError: 'device_tracker.jasper_s_samengestelde_locatie'
Ok, let me make sure I understand your current configuration. You have a composite that uses several tracker entities, including the “raw” Tado tracker (but not the synthesized one you created using the device_tracker.see service.) Is that correct?
The Tado tracker always has a source_type of router, and only when its state is home does it also have GPS attributes (latitude, longitude & gps_accuracy.) Is that correct?
Do you have all_states set to true for any of the composite’s input entities, and if so, which one(s)?
Maybe you should share your current composite configuration (for at least one that uses a Tado tracker as one of the inputs).
I browsed the proximity code, and as far as I can tell, it accepts entities that don’t have GPS data (latitude, etc.) So, to me, this is clearly a bug in the proximity integration (as opposed to a misuse of it.) It’s making an assumption about the states the entities can take on that is invalid, leading to this exception.
I’d be happy to try to fix the bug, or even make adjustments to the way the composite tracker works if that makes more sense, but I’m going to need much more detail. I tried to reproduce the problem, but couldn’t. I then tried to figure out what sequence of states of the entities the proximity integration is monitoring could lead to this exception, but I came up empty. Clearly it’s happening; I just can’t figure out yet how.
If you’d like this fixed, and you’re willing to provide the details I need, I’m more than happy to work on it. If so, please contact me via private message and I can work with you to get the details I need.
I was able to reproduce the exception from the proximity integration. It has nothing specifically to do with the composite integration. This can happen with any type of device tracker. In fact, I reproduced the problem by creating bogus device tracker states via the STATES tab of the Developer Tools page.
Here is the (most likely) scenario that causes the exception:
The proximity configuration contains at least two devices. At HA startup, the first of these device tracker devices to initialize is determined to be not in the proximity’s zone, nor in any of the proximity’s ignored zones. Then another of these device tracker devices to initialize is determined to be in one of the proximity’s ignored zones, AND is determined to be the closest device to the proximity’s zone.
So, e.g., the proximity zone is home, and it has an ignored zone, say “Work”. If, when HA is restarted, one of the devices for the proximity zone is at Work, and all the others are not home (nor in any of the ignored zones) and are further from home than the device in the Work zone, and if the device that is in the Work zone just happens to not be the first to be initialized, then the exception will happen.
This is clearly a bug in the proximity integration. BTW, I found other proximity bugs mentioned in HA issues that are not being addressed. Apparently, whoever created the proximity integration is no longer working on it. There is no code owner assigned.
FWIW, there is a custom integration that was created to replace it you could check out. I haven’t tried it myself; I just noticed it mentioned in the proximity issues.
Released 2.6.0
Adds a speed sensor for each composite device tracker that indicates the speed the device is moving.
Also converts last_seen attribute back to a datetime object when restoring.
As usual, I’d appreciate any feedback on this new feature, good or bad.
I’m also working on adding a couple of attributes to the speed sensor to indicate direction of movement: angle (in degrees), and direction (compass heading, e.g., N, NE, etc.) These attributes will contain None if the speed sensor’s state is unknown, or if the speed is less than 1 m/s. I hope to release these new features soon.
Released 2.7.0b0
This is a prerelease.
Add angle & direction attributes to speed sensor.
Also, better filter out speed value outliers, especially when a pair of location updates comes from different input entities.
BTW, a History Graph card of the speed sensors can really give a good sense of who has been on the move recently:
(Names removed to protect the innocent! 
)
1 Like
is life360 really worth it?