They exist in the entity registry but will be disabled, all you would need to do is to enable entities you want to track
Yes, but they will be in the entity list as disabled along with the 75 other unifi entities that I have to keep disabled because they are on the network all the time and will keep coming back if I don’t have them disabled. the when I “show disabled entities” I then have to wade thru that long list to figure out the one that I want to re-enable.
I fail to see why I can’t delete a single entity if i want without deleting the entire integration when we were able to do that before this update?
I’m getting the same thing on HASS.OS rpi4 and trying to delete groups causes my zigbee devices to lag like 5 minute delay lag that a restart won’t fix only a snapshot restore.
Is there a way to do this with scenes?
Mine was resolved by doing a restart on the whole Rpi before the update.
A question to the community.
Is there a trick how developers become aware of the issues raised here?
Since version 102.x the integration of at least some Huawei LTE modems is no longer possible.
But it seems that the developers are not interested.
Have you submitted an issue on github?
Yes.
You don’t use the forums for bug reports, you use Github
Selecting multiple entities to remove them doesn’t really work for me. When I select a few and click “Remove Selected” I get a message “Do you want to remove 0 entities?” and when I click YES nothing happens.
It does seem to work if I click “Disable Selected” instead of “Remove Selected”
Thanks for the hint. I didn’t know Github.
I have now followed the entry in the release note for the Huawei LTE access topic.
But I see the following as the last entry.
“This conversation has been locked and limited to collaborators.”
How can I draw attention to the topic now?
That’s a PULL REQUEST for a code change, NOT an issue. Create an ISSUE and link to that pull request.
Just updated. I think that the new entity handling broke my vera integration. After I rebooted I got these errors:
Error doing job: Task exception was never retrieved
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 410, in _async_add_entity
raise HomeAssistantError(msg)
homeassistant.exceptions.HomeAssistantError: Entity id already exists: binary_sensor.s01_motion_167. Platform vera does not generate unique IDs
After I disabled the integration and deleted all entities coming from vera HA reboots but changes a lot of the entity names. After another reboot I get the same error messages as the first one. Looks like the integration can’t make unique entitiy names?
if It’s the unifi integration (or anything similar) that you are referring to then you can’t delete entities (anymore… ) individually without deleting the entire integration that added them in the first place.
I don’t think that was well thought thru before being implemented.
You would not delete those entities, since that does not prevent them from coming back (if deleting was possible). Instead you disable the entity in the integration, so the integration knows not to create or update those.
Sorry but did you read the use case that I explained a couple of posts up?
specifically, the unifi integration, or any device tracking integration that creates entities based on devices connecting to and dropping of a wifi system and also uses the entity registry, will create entities that might be a one-off connection depending on who visits and is given network access. I don’t need or want to track those devices. I also don’t want or need to add them to the miles long list of devices I have to disable because they are always on my network (nodemcu’s, shellies, sonoffs, security camera’s, etc). it’s better for entity/system management to just delete them since they (probably) won’t be coming back.
added to that there are times that i have a need to delete an entity temporarily to see if it comes back again because i’m not sure if it’s a device i want to keep (either enabled or disabled) until i see it connect to the network a couple of times. I don’t want to necessarily track it right now so the way it is now I would have to disable it. then once I decide if I want to track it again then I have to sift thru the miles long list of disabled devices (that now includes many devices that may never show up on my network again because I can’t delete them) to be able to re-enable that device.
I’m sure I’m not the only person in this situation. there have already been a couple of threads asking the same question.
Is there some reason why we have to switch to this method of deleting (or not) an entity? I fail to see why the same warning wouldn’t apply to the current situation just like it did before that basically said “deleting these will remove them from the system but they may be added back by the integration again later”. Kind of like the warning we have right now with the exception that we can now no longer take control over our own systems and just say do it anyway.
It’s kind of like you trying to delete a file from your computer because you have determined you don’t need it and the computer telling you it won’t do it. But then when you contact Microsoft customer support they tell you to “just make it a hidden file so you don’t see it anymore.”
If I want to delete an entity from my system I should be able to do it. If it comes back later on then that’s on me. Because, you know, it’s my system.
It’s not like they are critical files that will break things if they get deleted. But ironically we can delete those other critical files all day long and the system doesn’t complain at all.
Thinking in solutions: a suggestion for UniFi integration might be to add an option to add new entities as disabled by default, allow to enable them when needed.
If that is a solution that would fit, it should be a feature request for that integration.
It is not Home Assistant that creates entities, but an integrations that provides that, Home Assistant does not limit or control that.
What it sounds like is that we need a Unifi device_tracker
platform that works as other network trackers do (nmap
, router
, etc) that would allow us to use mac or ip addresses for tracking in an include:
or exclude:
block. This would solve the need to delete or hide entities and give us greater control over what devices are actually tracked, plus all the benefits that the Unifi integration gives us today. Do you agree?
You’re not.
That could be another possible solution to the problem.
However, it is up to the integration to implement that.
PS: I own UniFi, and I don’t use the integration for the same reasons. It doesn’t fit my needs in its current behavior.
Correct. @finity, do you have an issue already created in github for this (I haven’t checked)? I can add my suggestion to that issue if you do.
TBH, I think that would put us in a worse situation than we are now.
At least now those entities are staring us in the face and prompting us to do something with them. If you disabled them by default and with most people hiding their disabled entities you would still need to search thru the miles long list of disabled entities to find the one that you want to re-enable. But you might not even know it’s in there.
Again, continuing with the Windows analogy… it would be like Microsoft putting a bunch of hidden files on your system that you might find useful but you don’t know they are there or what they are unless you go looking for them and then you need to un-hide them or delete them if you don’t need them, but you can’t delete them because microsoft won’t let you.
100%
No because…
- I just noticed it in the last couple of days and I was trying to get feedback on why it might have been changed.
- from the explanation above and in the release notes it doesn’t seem to be an “issue” but a design implementation in the latest release.
It sounds more like it will be a feature request (as frenck said) but I haven’t had much any success with those in the past and so I’m hesitant to waste my time on it. Especially since this was just changed in a major redesign I’m sure the devs won’t be in any mood to revert back to the old way so soon.
But if you’d like to put one up I’ll be more than happy to upvote it.