0.104: Sentry, Signal Messenger, IntesisHome, Sure Petcare, KEF

[lizaoreo]

Is there a way to do this with scenes?

[Misna (Mikko Malkavara)]

Mine was resolved by doing a restart on the whole Rpi before the update.

[oneteam]

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.

Huawei LTE modem cannot be integrated

Since a few days (I think after the update from 102.x to 103.x) it is no longer possible to connect my Huawei LTE modem. This is an HA installation on a Synology. The Huawei LTE modem is a B529s-23a. And everything has worked fine. Can anyone help me solve the problem or do you need more information about my system? I always get the following error message. No matter if I do the Huawei integration via the frontend or the config.yaml. [homeassistant.components.huawei_lte.config_flow] Unknown…

[firstof9]

Have you submitted an issue on github?

[flamingm0e]

@oneteam

Is there a trick how developers become aware of the issues raised here?

Yes.

You don’t use the forums for bug reports, you use Github

[papadi (Dimitris Papadi)]

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”

[oneteam]

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.

Re-authorize Huawei LTE on login required error

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?

[flamingm0e]

That’s a PULL REQUEST for a code change, NOT an issue. Create an ISSUE and link to that pull request.

[BvL87 (Bart)]

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?

[finity]

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.

[frenck (Franck Nijhof)]

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.

[finity]

@frenck

You would not delete those entities, since that does not prevent them from coming back

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.

[frenck (Franck Nijhof)]

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.

[code-in-progress (Bill - I write code.)]

@finity

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.

@frenck

Thinking in solutions:

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?

@finity

I’m sure I’m not the only person in this situation.

You’re not.

[frenck (Franck Nijhof)]

@code-in-progress

t would allow us to use mac or ip addresses for tracking in an include: or exclude: block.

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.

[code-in-progress (Bill - I write code.)]

@frenck

However, it is up to the integration to implement that.

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.

[finity]

@frenck

a suggestion for UniFi integration might be to add an option to add new entities as disabled by default,

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.

@code-in-progress

Do you agree?

100%

@code-in-progress

do you have an issue already created in github for this

No because…

1. I just noticed it in the last couple of days and I was trying to get feedback on why it might have been changed.
2. 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.

[code-in-progress (Bill - I write code.)]

@finity

But if you’d like to put one up I’ll be more than happy to upvote it.

I can do that later today and I’ll PM you the link to it.

[frenck (Franck Nijhof)]

Yes, the entity registry is absolutely designed for this, and not an implementation of the latest release.

You keep comparing disabling with hiding (hidden files, Microsoft example). Those are not the same things, even in Home Assistant.

Hiding = not showing in UI, still in the registry, still having a state, still getting tracked. Disabling is letting the integration know we don’t care about that device and don’t want to have it. It will not get a state, and not receive state updates. It won’t be hidden, as it is not there.

The reason to have this difference: If an integration finds a device, you want to be able to map that device to an entity. If you could delete the entity, the integration can only conclude it doesn’t exists, so it normally would create it (<- That is up to the integration to decide on).

Hence, disabling is a method to tell the integration, we know this device, don’t want it.

There is no way for a computer to decide: “He might like this entity”. So in case of the UniFi, how would it know a device should be created as entity or not? He doesn’t know it is a guest. (Unless you have a guest network? Would be nice if I could exclude SSID’s tbh).

[Robban]

This is not a solution, the proper way according to guidelines is to use the enable/disable functionality of entity registry. We should not limit by configuration what entities gets created in the state machine