Do you have at least one entry in the trackers part of the composite config? If not, then why do you have it in your configuration?
From the 3.0.0b0 release notes:
I’ll also add a note that trackers must contain at least one entry.
well, yess, I have 3 trackers each using several device trackers :
composite:
trackers:
- name: Marijn #required for valid config
id: marijn_composite
time_as: device_or_local
require_movement: true
entity_id:
- device_tracker.1
- device_tracker.2
- device_tracker.ping_marijn
- name:
- name:
Hmm, ok, not sure why you’re having errors. Let me do some checking…
so I went from the release to b01, and skipped the first beta
maybe something went wrong in that transition.
and, so I understand correctly:
after installation of 3.0, we still need those yaml configs?
or are they imported and need to be deleted after that process. (which is what happens with the core integrations when moving from yaml to UI)
Ok, I just tried a test where I start with 2.8.4 with a config similar to yours. Then I upgraded to 3.0.0b1, restarted, and it worked fine. Here is the warning about unsupported options that is issued after the restart:
This error originated from a custom integration.
Logger: custom_components.composite
Source: custom_components/composite/__init__.py:111
Integration: Composite (documentation, issues)
First occurred: 11:13:24 AM (1 occurrences)
Last logged: 11:13:24 AM
Your composite configuration contains options that are no longer supported: time_as; Please remove them
So, not sure why you’re having a problem.
So, this integration is not moving from YAML to UI; it’s adding UI. You can continue to use YAML, or you can remove YAML and use UI, or you can do both.
Ah, ok, I think I know what the problem is. You’ve got the composite integration in a package, right?
I’ll figure out how to fix that and release a new beta.
Yes. Along with my other device_trackers.
Or, rephrased, not inside configuration.yaml
3.0.0b2 released with a fix.
Thx! Can confirm I now have 3 items (from config)
removing those from yaml, and restarting, took them out of the integrations panel, where Composite now no longer was shown (which was expected, as I took them out…)
Ive rebuild them all using the UI now, however there is this result:
the original tracker (and speed entity) still exists, hence my new UI tracker gets the _2 suffix.
apparently this is not yet the case
- Any tracker entry removed from YAML configuration will be removed from the system.
the naming of the speed (snelheid) sensor is a bit odd too, but I can change that.
I cant however delete the original device_tracker.marijn_composite
leaving me with 12 entities now, instead of the expected 6…
edit
a second restart did make the original entities unavailable, so I can start renaming.
nice.
Hmm, I thought that removing a config entry would also remove all associated entities. But now that I think about it more, and given your experience, that probably isn’t the case. I think there is a function I need to call to “clear” the entity registry of an entities related to a config.
I’ll probably be releasing another beta soon. Thanks for being my guinea pig!
EDIT:
I reproduced what you experienced.
Well, I rechecked the code and removing a config entry does clear out associated entries in the entity registry, so this shouldn’t be happening. BUT…
It’s possible there is a race condition between removing the config and the (previously existing) config getting set up. This is probably a side effect of one of my recent changes to keep setup from delaying startup. I think I know how to fix this. Stay tuned (although this probably doesn’t matter to you anymore.)
Released 3.0.0b3 to fix the above noted issue.
Released 3.0.0b4
I had added the restored attribute if the state was restored after restart. However, this is used for other purposes and has an undesired side effect when used in this situation. Therefore, do not add that attribute anymore.
I’m also planning to fully release (as 3.0.0) soon. If anyone is having any issues with the beta releases, please let me know ASAP so I can fix any problems before releasing 3.0.0. Thanks!
Well, this is the second time today I noticed I got bit by using features in the dev branch of HA Core that are so new they are not in any release. Argh!
This time (with this integration) it causes the speed sensors (only for UI based configs) to be wrong. There’s a new translation feature I used, and without it, the names come out goofy.
In the interim, if you care, use the Settings (gear) page for the entities to change their names and entity IDs.
I’ll have to consider what to do about this. One choice is to make the minimum HA version 2024.2 (so it will work when that comes out.) Or I could try for a workaround to support older HA versions. Hmm…
is it only the naming of the entities, or also the state?
Tbh, Not seeing that here now on my test entities, but, I had already renamed them earlier.
Guess that (renaming) would be no issue, so not sure what my preference would be for compatibility minimum versions…
HA 2024.1.5 and CC 3.0.0b4
First, I released 3.0.0b5 with a fix.
It’s only the name (and, hence, entity ID) of the speed sensor, and only for UI created configuration entries. The fix only works when you create new entries from the UI. Existing UI created speed sensors can have their names and entity IDs changed the normal way.
I haven’t done enough testing yet to know exactly what HA version is needed.
I don’t remember if this has been asked (or answered) but is it a possibility to add a new state to the composite tracker that indicates “driving” similar to what the Life360 integration had?
I don’t recall anyone asking for that feature in the composite integration. But it would be very easy to add. Please add an issue to that repo and label it “enhancement.”
Done. But I don’t see a way, or know how, to apply the label.
Released 3.0.0
trackers in YAML configuration must have at least one entry.entity_id attribute has been changed to entities. entity_id did not show up in the attribute list in the UI.entity_id attribute to entities.I have an implementation of this feature. It is in a PR/branch. Let me know if you can test it as-is. If not, I can release it as a beta.