Auto-removed entities will break HA automations/scripts that reference them

[gh69]

The problem

The ReoLink integration will automatically add a newly discovered device and it's child entities when discovered on the network...as expected...but when a Reolink device goes offline the ReoLink integration then automatically removes that device's child entities. Once the child entities are gone, the first time a script or automation that references the child entity is triggered, HA will red-flag it (showing up as "Automation is unavailable" or "Script is unavailable") and HA will no longer execute that script/automation EVER until both a) the device comes back online and it's child entities are rediscovered by the integration and b) the script/automation is manually edited to remove the red-flag.

I've noticed this as an issue since at least December but I thought at first that it was an HA issue, since that red-flag feature is new. But now I'm seeing that the Reolink integration is contributing to this issue. I base this on the fact that I've got other integrations that similarly create Devices and child entities at discovery but then don't subsequently remove child entities when the parent device goes offline or for some reason becomes unreachable by the integration. My other integrations' offline devices will still also list the previously discovered child entities. Granted, when you attempt to open a child entity of a device that has gone offline, you'll get a message that reads "This entity is no longer being provided by the integration. If the entity is no longer in use, delete it in settings."...but the child still exists and all script/automation references to that child remain in tact. These no-longer-being-provided child entities referenced by scripts/automation do end up generating runtime errors until the child entities return to working order but they don't prevent any scripts/automations from running. With the ReoLink integration however, because the child entities completely disappear, existing scripts/automations that reference them automatically get disabled by HA and one has to manually re-enable them after the child entities are rediscovered and available again. This is a problem...especially for someone like me who has a couple of wifi cameras on the edge of my wifi range that will fall off the network every now and then. Lately, I've found myself checking my automations and scripts daily to make sure none have been red-flagged by HA due to this issue. It happens alot.

I tried turning off the Reolink integration's "Enable newly added entities" option, thinking that maybe if it stopped auto-adding then it might also stop auto-deleting but that didn't seem to work. I suppose there may be some legitimate reason to have the integration automatically remove entities from devices that disappear from the network...though I can't imagine what that reason would be...is this a recent and/or purposeful change? If so, would it be possible to add an option to turn off the auto-remove entities functionality? If no-longer-working child entities remain in place, scripts and automations may begin to fail at runtime but they won't get hard-disabled by HA (and require manual intervention) due to bad references.

Red-Flag example caused by the triggerring of this event after a referenced camera device's child entity disappeared.

from automation list:

inside automation:

What version of Home Assistant Core has the issue?

core-2024.3.1

What was the last working version of Home Assistant Core?

No response

What type of installation are you running?

Home Assistant OS

Integration causing the issue

Reolink IP NVR/camera

Link to integration documentation on our website

https://www.home-assistant.io/integrations/reolink

Diagnostics information

No response

Example YAML snippet

No response

Anything in the logs that might be useful for us?

No response

Additional information

No response

[home-assistant[bot]]

Hey there @starkillerog, mind taking a look at this issue as it has been labeled with an integration (reolink) you are listed as a code owner for? Thanks!

Code owner commands

Code owners of `reolink` can trigger bot actions by commenting: - `@home-assistant close` Closes the issue. - `@home-assistant rename Awesome new title` Renames the issue. - `@home-assistant reopen` Reopen the issue. - `@home-assistant unassign reolink` Removes the current integration label and assignees on the issue, add the integration domain after the command. - `@home-assistant add-label needs-more-information` Add a label (needs-more-information, problem in dependency, problem in custom component) to the issue. - `@home-assistant remove-label needs-more-information` Remove a label (needs-more-information, problem in dependency, problem in custom component) on the issue.

_{^{(message by CodeOwnersMention)}}

---

reolink documentation reolink source _{^{(message by IssueLinks)}}

[issue-triage-workflows[bot]]

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍 This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.

[starkillerOG]

I get the issue, Indeed I added a "feature" to clean-up devices that are no longer connected to a NVR. I was already wondering if this would cause issues when I implemented it.

The idea is that a platinum qaulity scale integration (what I am working towards) is supposed to automatically clean-up old entities if a device gets removed from a Hub (in this case a nvr).

Note that it will only remove devices at start of HomeAssistant, so as long as you don't restart HomeAssistant it will not be a problem. But with updates you will be foreced to restart HA.

I will think about this one. Maybe I will remove the auto-deletion in favor of the option to manualy remove a device, will look into the possibilities.

[gh69]

...or maybe just add a switch under system options to "Enable auto-cleanup of dead devices" and have this turned on by default. This would allow for auto-cleanup to continue to do what it does as is, but could be turned off for those who need it. It would fit in just perfectly under the already existing "Enable newly added entities" switch. :D

I imagine that most people with an NVR have it connected to their network via ethernet...such a direct connection is likely pretty stable and doesn't disconnect often. the problem is with child wifi cameras that are connected to the NVR...especially those at the edge of wifi-range that can intermittently drop off and on the network. even though the NVR itself has a stable connection to the HA integration, when invidivual child wireless cameras come offline, their entities sometimes disappear from HA, and then reappear when they come back online. i've had to workaround this by creating helper entities for all non-video-feed reolink entities that are just copies of the real reolink entities. These helpers never disappear and so they never break any scripts or automations....it's just a bit of a pain to have to have to have two of every reolink entities just to prevent scripts from breaking. the one thing i haven't been able to get around is the auto-removal of child cameras' HA assigned "Area". Every time a child device disappears and reappears, all of it's settings come back except for it's HA assigned area. So I never know where a camera's entities will appear on my "Overview" dashboard.

[gdt]

I think there's a larger problem lurking, and I realize it may be a philosophical disagreement.

When I configure a camera (or anything), then it is interviewed and entities are created. I think it's fine for those to go to unknown or unavailable when the camera is not reachable. But I do not understand why the entities are withdrawn. In my view they should still exist, but be unable to reach their hardware. If someone wants to delete the device, fine. But I would say 99% of the time they want to go plug their hardware back in, instead.

I think that if we stop the practice of withdrawing entities from unreachable hardware, a lot of things will work better.

[gdt]

I think it's reasonable to remove entities from a child of the NVR, if the NVR reports that the user has deconfigured that device. I would think that is what the platinum scale demands, but again I suspect a philosophical disagreement.

[gh69]

I think it's reasonable to remove entities from a child of the NVR, if the NVR reports that the user has deconfigured that device. I would think that is what the platinum scale demands, but again I suspect a philosophical disagreement.

but what if one has NOT deconfigured the child camera? ie..that child camera (which happens to be on wifi) disconnected temporarily from the NVR? this is my situation.

[gdt]

@gh69 My view is that if a device goes missing, the entities should remain until deconfigured, but unavailable/unknown, and it should be easy to deconfigure them. One should be able to have an alert on 'sensor.foo = unavailable' with a 4h holdoff, or whatever. One should be able to graph past values of that entity while it's gone, so you can e.g. look at signal strength before it went missing, or whatever you want to look at.

[gh69]

@gdt Yes that would be very nice.

[akuehner]

If this is a philosophical debate, I need to add my +1 to it shouldn't delete itself automatically in this situation. I too have the issue that occasionally the doorbell will lose signal and that has resulted in losing it in HA entirely.