@Ildar_Gabdullin @finity I think I know what the problem might be. It has to do with trying to be compatible with a wide range of HA versions. I’ll work on a fix Monday. But in the meantime I’m pretty sure a simple restart is all that is necessary to work around the problem (which is basically a race condition when first creating the entry in core.config_entries.)
1 Like
Thank you very much, Phil!
After the last restart I see no problem with these trackers, no warnings in Log (with “default: warn” in logger, w/o “custom_components.composite: debug”).
Have a nice Sunday.
I never had any old composite trackers so I tried another restart and I believe that has fixed it. At least the composite tracker I have is no longer unavailable and is now showing a valid location.
So we’ll see how it goes from here.
Ok. Now that I’m pretty sure what the problem is, that makes sense.
Released 2.4.0b1
This is a prerelease. It hopefully fixes the race condition that was causing exceptions when the composite config was first imported to .storage/core.config_entries.
DO NOT USE 2.4.0b1!
I made a mistake in the creation of release 2.4.0b1. I tagged the wrong branch. So 2.4.0b1 is effectively the same as the older 2.3.0. D’oh!
I will replace 2.4.0b1 shortly with 2.4.0b2 (that will be what 2.4.0b1 was supposed to be.)
1 Like
Released 2.4.0b2
This is a prerelease.
Fixes/replaces broken release 2.4.0b1.
Last chance…
Anyone see any reason I should NOT release the beta features in 2.4.0b2 as a “full” release (i.e., 2.4.0)?
EDIT: I just answered my own question … see below … 
Released 2.4.0b3
This is a prerelease.
- Fix options when creating more than one config entry.
- Fix async_setup_entry for HA version >= 2021.5, < 2022.8.
The first bug only manifests when first creating entries in .storage/core.config_entries. It caused all entries to have the same options as the last entry (e.g., its list of input entity IDs.) Luckily, the entries are automatically fixed after a HA restart (since the code makes sure the entries match what is in YAML in case the YAML settings are changed.) This fix causes the entries to be created correctly initially.
NOTE: I plan to remove support for HA versions older than 2021.12 in the next beta release.
Released 2.4.0b4
This is a prerelease.
- Add
default_optionsfor specifying default values forrequire_movement&time_asoptions undertrackers. - Drop support for Python 3.8 & HA versions older than 2021.12.
- Add typing.
- Fix minor bugs found by mypy.
Per the first item, a config like this:
composite:
trackers:
- name: A
entity_id: device_tracker.a
require_movement: true
time_as: device_or_local
- name: B
entity_id: device_tracker.b
require_movement: true
time_as: device_or_local
- name: C
entity_id: device_tracker.c
time_as: device_or_local
- name: D
entity_id: device_tracker.d
require_movement: true
time_as: local
Can now be specified like this:
composite:
default_options:
require_movement: true
time_as: device_or_local
trackers:
- name: A
entity_id: device_tracker.a
- name: B
entity_id: device_tracker.b
- name: C
entity_id: device_tracker.c
require_movement: false
- name: D
entity_id: device_tracker.d
time_as: local
It can significantly simplify the configuration, especially when there are a lot of composite trackers that all use the same options.
1 Like
Released 2.4.0b5
This is a prerelease.
- Add entity use_picture option
Although legacy device trackers can provide a picture to be used for the entity, the value is only used when its entry in known_devices.yaml is initially created. After that, the device tracker component level ignores the value, even if it changes, and hence, known_devices.yaml is never automatically updated.
Given this behavior, when the composite integration was first created, it didn’t make sense to try to use the picture from one of the input entities because there was no guarantee it would be the first to be seen, and hence create the entry in known_devices.yaml.
But now that it’s no longer a legacy device, it does make sense to use a picture from one of the input entities. This is now possible by specifying an entry such as:
composite:
trackers:
- name: Me
entity_id:
- entity: device_tracker.me_main
use_picture: true
- device_tracker.me_secondary
Released 2.4.0b6
This is a prerelease.
- Restore state after HA restart
This makes sure composite’s entity_picture attribute is the same immediately after a HA restart (in case the source entity it gets the picture from doesn’t update, or doesn’t have the most up-to-date data for the composite, for a while.)
The remainder of the state is only restored if the composite does not get updated (from one or more of its input entities) during startup.
Also update & write state atomically.
Released 2.4.0b7
This is a prerelease.
- Fix bug with HA version 2022.9 or newer
FYI, I’m working on two custom integrations at the same time, and trying to make them both compatible with HA versions going back to 2021.12.10 (which is the version I’m using on my “production” system. Long story!) It’s quite the balancing act. Sorry for any inconvenience.
Also, if you are using these prereleases and run into any problems, by all means, please let me know so I can fix them ASAP.
Released 2.4.0
- Convert to entity-based trackers
- Deprecate support for “legacy” trackers.
- Create persistent notification to change config from device_tracker → composite.
- Support HomeAssistant version 2021.12 or newer & Python 3.9 or newer.
- Add default_options.
- Add entity use_picture option.
- Restore state after HA restart.
I’m trying out the composite tracker but so far it is doing a worse job than the HA person integration for me, so maybe you can tell me what I’m doing wrong here?
I have the HA GPS tracker, the Google Locations GPS tracker, an IP ping tracker and a Tado tracker, all for the same phone. The TADO one looks like GPS but removes the decimals from the GPS coordinates. So instead I first derived a binary sensor to make sure composite is not fooled by inaccurate GPS coordinates. So in the end I have two true GPS trackers and two binary sensors configured like this:
- name: Jasper's samengestelde locatie
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
The binary sensors are acting up a bit now. Tado logged out on the phone so it is not updated, and the ping sensor may be off as I got a new router. I think I put in the right IP, but maybe I was wrong. But that does not really matter for the case shown below - and the idea is that the composite tracker should use the best info available, right?
Two GPS trackers show the right GPS coordinates, the binary sensors say ‘away’ for a long time. So they should not disagreee with the zone from the true GPS trackers, but still the zone from the GPS gets ignored. As far as the history graph shows, the newest info is grom the GPS trackers, but the compound tracker (the one below) ignores the zone:
I expected the location to be CLD, if even for a short while when the GPS trackers changed zones. Even if the binary sensors “updated” away, CLD is also away, so they should not have erased zone information from more detasiled trackers. What am I missing here?
EDIT: below is a screenshot from when the binary sensors were working fine (apparently I put in the right IP anyway). Seems the composite tracker isn’t working at all:
To be clear: I did convert to the new format as you can see. But before that the results were inconsistent too.
Ok, so you’re using version 2.4.0, is that correct?
Did you use an earlier version of the composite tracker? If so, after updating to 2.4.0, did you remove the old entry (or entries) from known_devices.yaml?
Do you see any warning or error messages, or persistent notifications, related to the composite integration?
You keep referring to binary sensors, but I only see device trackers in your composite configuration. Can you clarify?
So is device_tracker.jasper_tado_non_gps_tracker the actual TADO tracker, or your modified version, and if the latter, I’m curious how you created it (although that is probably not immediately important here.)
Yes and no. To be more precise, its purpose is to use the most up to date data, which presumably is the “best” data. However, non-GPS device trackers and binary sensors are often better at indicating when a device arrives in the Home zone than when it leaves the Home zone, which is why, by default, only their transition to home is used (although that can be changed per input entity using the all_states option. BTW, all_states is always true for GPS device trackers, so you don’t really need to specify that in your configuration.)
The composite integration does not use the zone information directly. I.e., it takes the GPS coordinates from GPS based device trackers, and the “system” (actually, the device tracker component level code) then uses those coordinates to determine if the composite entity is in a defined HA Zone. If so, then the state of the composite entity will be the name of the zone. If not, then it will be not_home (aka Away, or Away translated appropriately.)
So, bottom line, it looks like the composite entity is not updating at all.
My guess is you had used a previous version of the composite integration, and so there is an entry in known_devices.yaml, and you ignored the warning and persistent notification to remove that entry (or, at least, change its track setting to false.) If this is the case, then that entry is causing a non-functional entity to be created. What are the attributes of that entity? In particular, does it have a restored attribute? Is there another entity with a similar name but maybe with a “2” suffix? Do you see an entity on the Entities page created by the composite integration?
We can dig a little more deeply if needed, but I think the root cause of the problem is not removing the old entry from known_devices.yaml. If that’s not the problem, or none of the above helps you get it working, based on the answers to your questions I can make suggestions on how to better diagnose the problem and get it working for you.
BTW, the require_movement option is really meant for the scenario where you have more than one physical device where you don’t always take them all with you. (E.g., you have a personal phone and a work phone, and sometimes you forget to bring them both with you and leave one sitting at home. In that scenario you don’t want the device left at home constantly changing the composite entity back to home.) If all of the entities you are using with this composite tracker ultimately come from the same physical device (just via different services), then you shouldn’t need to use this option, and I’d recommend removing it from your configuration.
I had an older version, got the persistent notification that I needed to change the config, and removed the entries from known devices as instructed. I just checked and they are not there anymore.
When I said binary sensors I meant non GPS device trackers that just have home / not home. The real Tado device tracker is not used, only mine. I created it by adding a dummy to known devices (even though that file is about to be deprecated) and I set its state using an auutomation and device _tracker.see:
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') }}"
mode: single
I have only one entity per phone, that seems to be working again after a reboot.
Curiously enough, when this one was malfunctioning, 2 out of four were working fine, the other two not.
Ok, thanks.
After changing the config and removing the entry/entries from known_devices.yaml, did you restart HA?
What about the answers to my other questions? I’m sure this will work for you, but without additional details I can’t be sure what’s wrong.
Let’s start with the main questions…
Are you seeing any warnings or errors related to the composite integration? After restarting HA, do any persistent notifications come back?
If you’re not seeing any of those, then do you see an entry on the Entities page that indicates it is created by the composite integration? Do you see “Jasper’s samengestelde locatie” on the Entities page, and if so, what integration created it (i.e., composite or device tracker)?
What is the (full) current state of the composite device tracker, as seen on the Developer Tools STATES tab?
If necessary, you can enable debug for custom_components.composite and it will create additional debug output in home-assistant.log that might help.
I had just edited the earlier post with some of the answers (I posted too soon by mistake). The states data is there. I rebooted many times for various reasons, but of course also to load the config changes. The logfiles do not show errors, but maybe I rebooted one too many times for the log to be there still. The persistant notification has not returned, and the tracker is created by composite.
I did not change the composite trackers for quite some time, so as I said in my earlier post two trackers working fine and two frozen that now work again too after a reboot seems strange.