Do not have permission to read media for camera
The problem
Running Protect 5.0.34
Multiple times per day Home Assistant will stop getting updates for the entities for all Unifi Protect and all video streams will stop working. If you try to reload the integration all entities will go unavailable. Sometimes if you wait a number of hours it starts working. To temporarily fix it I must keep restarting Unifi Protect and Home Assistant until it starts working.
When this happens there are errors in the Home Assistant logs:
uiprotect.exceptions.NotAuthorized: Do not have permission to read media for camera: 5d9294f800362703e70003ed
And errors in the /var/log/ui.log:
2024-10-06 13:43:16.465 WARNING UCore cloud: Endpoint check failed 2024-10-06 13:43:18.175 WARNING qt.network.http2: stream 1 finished with error: "Connection closed" 2024-10-06 13:43:18.218 WARNING qtprotobuflog: "ConsoleStatus" call "unifi.core.console.v1.ConsoleAPI" stream finished: "Connection closed"
What version of Home Assistant Core has the issue?
2024.10.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
Unifi Protect
Link to integration documentation on our website
https://www.home-assistant.io/integrations/unifiprotect/
Diagnostics information
config_entry-unifiprotect-01J9C5GA8TF8XAH9W7CWYEVHW0.json
Example YAML snippet
No response
Anything in the logs that might be useful for us?
From the Home Assistant logs:
Traceback (most recent call last):
File "/usr/local/lib/python3.12/site-packages/aiohttp/web_protocol.py", line 477, in _handle_request
resp = await request_handler(request)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.12/site-packages/aiohttp/web_app.py", line 559, in _handle
return await handler(request)
^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.12/site-packages/aiohttp/web_middlewares.py", line 117, in impl
return await handler(request)
^^^^^^^^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/components/http/security_filter.py", line 92, in security_filter_middleware
return await handler(request)
^^^^^^^^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/components/http/forwarded.py", line 210, in forwarded_middleware
return await handler(request)
^^^^^^^^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/components/http/request_context.py", line 26, in request_context_middleware
return await handler(request)
^^^^^^^^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/components/http/ban.py", line 85, in ban_middleware
return await handler(request)
^^^^^^^^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/components/http/auth.py", line 242, in auth_middleware
return await handler(request)
^^^^^^^^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/components/http/headers.py", line 32, in headers_middleware
response = await handler(request)
^^^^^^^^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/helpers/http.py", line 73, in handle
result = await handler(request, **request.match_info)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/components/camera/__init__.py", line 813, in get
return await self.handle(request, camera)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/components/camera/__init__.py", line 831, in handle
image = await _async_get_image(
^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/components/camera/__init__.py", line 189, in _async_get_image
else await camera.async_camera_image(width=width, height=height)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/components/unifiprotect/camera.py", line 251, in async_camera_image
last_image = await self.device.get_snapshot(width, height)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.12/site-packages/uiprotect/data/devices.py", line 1989, in get_snapshot
raise NotAuthorized(
uiprotect.exceptions.NotAuthorized: Do not have permission to read media for camera: 5d9294f800362703e70003ed
From the /var/log/ui.log on the CloudKey:
2024-10-06 12:21:42.025 INFO LCM: user session active
2024-10-06 12:32:30.485 INFO LCM: user session inactive
2024-10-06 12:46:28.645 INFO LCM: user session active
2024-10-06 12:52:30.529 INFO LCM: user session inactive
2024-10-06 13:07:25.809 INFO LCM: user session active
2024-10-06 13:12:30.531 INFO LCM: user session inactive
2024-10-06 13:43:16.465 WARNING UCore cloud: Endpoint check failed
2024-10-06 13:43:18.175 WARNING qt.network.http2: stream 1 finished with error: "Connection closed"
2024-10-06 13:43:18.218 WARNING qtprotobuflog: "ConsoleStatus" call "unifi.core.console.v1.ConsoleAPI" stream finished: "Connection closed"
2024-10-06 13:43:18.245 WARNING qtprotobuflog: "ConsoleStatus" call "unifi.core.console.v1.ConsoleAPI" stream finished: "Connection refused"
2024-10-06 13:43:18.245 WARNING qtprotobuflog: "ConsoleStatus" call "unifi.core.console.v1.ConsoleAPI" stream error: "unifi.core.console.v1.ConsoleAPI call ConsoleStatus stream failed: Connection refused"
2024-10-06 13:43:18.249 WARNING UCore grpc: Subscription error: QtProtobuf::QGrpcStatus::Unavailable "unifi.core.console.v1.ConsoleAPI call ConsoleStatus stream failed: Connection refused"
2024-10-06 13:43:21.363 WARNING UCore applications: Endpoint check failed
2024-10-06 13:43:21.363 WARNING UCore cloud: Endpoint check failed
2024-10-06 13:43:26.366 WARNING UCore applications: Endpoint check failed
2024-10-06 13:43:26.367 WARNING UCore cloud: Endpoint check failed
2024-10-06 13:43:28.374 WARNING qtprotobuflog: "ConsoleStatus" call "unifi.core.console.v1.ConsoleAPI" stream finished: "Connection refused"
2024-10-06 13:43:28.374 WARNING qtprotobuflog: "ConsoleStatus" call "unifi.core.console.v1.ConsoleAPI" stream error: "unifi.core.console.v1.ConsoleAPI call ConsoleStatus stream failed: Connection refused"
2024-10-06 13:43:28.374 WARNING UCore grpc: Subscription error: QtProtobuf::QGrpcStatus::Unavailable "unifi.core.console.v1.ConsoleAPI call ConsoleStatus stream failed: Connection refused"
2024-10-06 14:11:39.405 INFO LCM: user session active
2024-10-06 14:23:28.751 INFO LCM: user session inactive
2024-10-06 14:31:01.118 INFO LCM: user session active
2024-10-06 14:42:21.795 INFO LCM: user session inactive
Additional information
No response
After the Protect update to versions 5.0.X, the integration became terrible. In version 4.0.33, it was quite stable. I'm experiencing many vehicle detection failures, the trigger that is activated but not deactivated, and car license plates that are no longer detected.
I was able to fix this just now but reloading the integration but it took two tries and some waiting time. I'm wondering if there's some new API limit in Unifi Protect that this is hitting.
I did some digging on the CloudKey. When those API errors in the ui.log happen the unifi-core process is dieing and systemd is restarting the unifi-core service. Nothing is happening to the unifi-protect service and soon after Home Assistant looses its connection to the Protect API and all entities stop updating. To fix I would manually restart unifi-protect and reload the protect integration in Home Assistant.
I was able to implement a work around on the ClouldKey so I don't have to manually fix anything when this happens.
I made the unifi-protect systemd service a dependent of unifi-core so anytime unifi-core is restarted systemd restarts unifi-protect. This has worked. Now anytime unifi-core dies and is restarted it restarts protect and Home Assistant is able to maintain it's connection. No more reloading the integration.
I added the following files to the CloudKey:
/etc/systemd/system/unifi-core.service.d/override.conf
[Service]
Restart=always
RestartSec=5
StartLimitInterval=60s
StartLimitBurst=3
/etc/systemd/system/unifi-protect.service.d/override.conf
[Unit]
PartOf=unifi-core.service
[Service]
Restart=always
RestartSec=5
StartLimitInterval=60s
StartLimitBurst=3
then run systemctl daemon-reload
So far these files have survived protect updates and CloudKey firmware updates
Are these the sort of logs you're seeing?
ui.log excerpt
2024-10-24 14:38:22.528 WARNING UCore applications: Endpoint check failed 2024-10-24 14:38:22.529 WARNING UCore cloud: Endpoint check failed 2024-10-24 14:38:27.504 WARNING UCore applications: Endpoint check failed 2024-10-24 14:38:27.505 WARNING UCore cloud: Endpoint check failed 2024-10-24 14:38:32.505 WARNING UCore applications: Endpoint check failed 2024-10-24 14:38:32.506 WARNING UCore cloud: Endpoint check failed 2024-10-24 14:38:37.504 WARNING UCore applications: Endpoint check failed 2024-10-24 14:38:37.505 WARNING UCore cloud: Endpoint check failed 2024-10-24 14:38:42.505 WARNING UCore applications: Endpoint check failed 2024-10-24 14:38:42.505 WARNING UCore cloud: Endpoint check failed 2024-10-24 14:38:47.505 WARNING UCore applications: Endpoint check failed 2024-10-24 14:38:47.505 WARNING UCore cloud: Endpoint check failed 2024-10-24 14:38:52.505 WARNING UCore applications: Endpoint check failed 2024-10-24 14:38:52.505 WARNING UCore cloud: Endpoint check failed 2024-10-24 14:38:57.505 WARNING UCore applications: Endpoint check failed 2024-10-24 14:38:57.506 WARNING UCore cloud: Endpoint check failed 2024-10-24 14:39:02.504 WARNING UCore applications: Endpoint check failed 2024-10-24 14:39:02.505 WARNING UCore cloud: Endpoint check failed 2024-10-24 14:39:07.505 WARNING UCore applications: Endpoint check failed 2024-10-24 14:39:07.505 WARNING UCore cloud: Endpoint check failed 2024-10-24 14:39:12.505 WARNING UCore applications: Endpoint check failed 2024-10-24 14:39:12.505 WARNING UCore cloud: Endpoint check failed 2024-10-24 14:39:17.505 WARNING UCore applications: Endpoint check failed 2024-10-24 14:39:17.506 WARNING UCore cloud: Endpoint check failed 2024-10-24 14:39:22.505 WARNING UCore applications: Endpoint check failed 2024-10-24 14:39:22.505 WARNING UCore cloud: Endpoint check failed 2024-10-24 14:39:27.505 WARNING UCore applications: Endpoint check failed 2024-10-24 14:39:27.506 WARNING UCore cloud: Endpoint check failed 2024-10-24 14:39:32.505 WARNING UCore applications: Endpoint check failed 2024-10-24 14:39:32.506 WARNING UCore cloud: Endpoint check failed 2024-10-24 14:39:37.505 WARNING UCore applications: Endpoint check failed 2024-10-24 14:39:37.505 WARNING UCore cloud: Endpoint check failed 2024-10-24 14:39:42.505 WARNING UCore applications: Endpoint check failed 2024-10-24 14:39:42.505 WARNING UCore cloud: Endpoint check failed 2024-10-24 14:39:47.505 WARNING UCore applications: Endpoint check failed 2024-10-24 14:39:47.506 WARNING UCore cloud: Endpoint check failed 2024-10-24 14:39:52.504 WARNING UCore applications: Endpoint check failed 2024-10-24 14:39:52.505 WARNING UCore cloud: Endpoint check failed 2024-10-24 14:39:57.505 WARNING UCore applications: Endpoint check failed 2024-10-24 14:39:57.506 WARNING UCore cloud: Endpoint check failed 2024-10-24 14:40:02.505 WARNING UCore applications: Endpoint check failed 2024-10-24 14:40:02.506 WARNING UCore cloud: Endpoint check failed 2024-10-24 14:40:07.504 WARNING UCore applications: Endpoint check failed 2024-10-24 14:40:07.505 WARNING UCore cloud: Endpoint check failed 2024-10-24 14:40:09.373 WARNING UCore applications: Endpoint check failed 2024-10-24 14:40:09.373 WARNING UCore cloud: Endpoint check failed 2024-10-24 14:40:09.393 WARNING qt.network.http2: stream 1 finished with error: "Connection closed" 2024-10-24 14:40:09.435 WARNING qtprotobuflog: "ConsoleStatus" call "unifi.core.console.v1.ConsoleAPI" stream finished: "Connection closed" 2024-10-24 14:40:09.455 WARNING qtprotobuflog: "ConsoleStatus" call "unifi.core.console.v1.ConsoleAPI" stream finished: "Connection refused" 2024-10-24 14:40:09.455 WARNING qtprotobuflog: "ConsoleStatus" call "unifi.core.console.v1.ConsoleAPI" stream error: "unifi.core.console.v1.ConsoleAPI call ConsoleStatus stream failed: Connection refused" 2024-10-24 14:40:09.456 WARNING UCore grpc: Subscription error: QtProtobuf::QGrpcStatus::Unavailable "unifi.core.console.v1.ConsoleAPI call ConsoleStatus stream failed: Connection refused" 2024-10-24 14:40:13.508 WARNING UCore applications: Endpoint check failed 2024-10-24 14:40:13.513 WARNING UCore cloud: Endpoint check failed 2024-10-24 14:40:18.508 WARNING UCore applications: Endpoint check failed 2024-10-24 14:40:18.509 WARNING UCore cloud: Endpoint check failed 2024-10-24 14:40:19.538 WARNING qtprotobuflog: "ConsoleStatus" call "unifi.core.console.v1.ConsoleAPI" stream finished: "Connection refused" 2024-10-24 14:40:19.539 WARNING qtprotobuflog: "ConsoleStatus" call "unifi.core.console.v1.ConsoleAPI" stream error: "unifi.core.console.v1.ConsoleAPI call ConsoleStatus stream failed: Connection refused" 2024-10-24 14:40:19.539 WARNING UCore grpc: Subscription error: QtProtobuf::QGrpcStatus::Unavailable "unifi.core.console.v1.ConsoleAPI call ConsoleStatus stream failed: Connection refused"
Thank you, I think I am suffering this as well.
I will need to do some reading as implementing your fix is beyond my current skillset.
Have you posted this on the UniFi forum so UI Glen is aware? (Please)
Also, rather than reloading the integration which didn’t work I have found that disabling and then re-enabling it restores the sensors.
Thank you, I think I am suffering this as well.
I will need to do some reading as implementing your fix is beyond my current skillset.
Have you posted this on the UniFi forum so UI Glen is aware? (Please)
Also, rather than reloading the integration which didn’t work I have found that disabling and then re-enabling it restores the sensors.
If you find out how to implement this fix would you be so kind to post a step by step here? I am also in desperate need to fix this issue.
Are these the sort of logs you're seeing?
ui.log excerpt
Yes. Those are the errors. In addition to the systemd changes on the CloudKey I made a Home Assistant automation to automatically reload the Protect integration when the entities go "unavailable" for longer than 5 minutes. Just in case things don't work out. I have only seen it fire once so far.
alias: "Monitor for Unifi Protect crash"
description: If entities are unavailable reload the integration to try to recover.
triggers:
- trigger: state
entity_id:
- camera.front_yard_low_resolution_channel_insecure
to: unavailable
for:
hours: 0
minutes: 5
seconds: 0
conditions: []
actions:
- action: persistent_notification.create
metadata: {}
data:
message: Unifi Protect
title: >-
Unifi Protect entities are unavailable. Attempting to recover by
reloading Unifi Protect integration.
- action: homeassistant.reload_config_entry
metadata: {}
data:
entry_id: 01J9WJ69YY69V7C84KZGE71TR3
alias: Reload Unifi Protect integration
mode: single
entry_id is found in the file .storage/core.config_entries in the Home Assistant config directory.
Thanks @cholywell
My camera feeds haven't been going down when all the other sensors 'freeze', I think because the RTSPS feeds are still there. The image cards do go grey though which is weird. I have enabled the "insecure" camera feed entity ID for the cameras, as you are using and I am gong to start monitoring those to see if they go offline when this happens as that seems to be working for you. Then I might have the automation repeat until the cameras come back online as modifying the CKG2+ is a bit beyond me to be honest and also may not survive a firmware update. Hopefully UI are working on the stablility of Protect 5.X on the CKG2+ (maybe also bad on the UNVR / DM Pro I don't know).
I should say in all this I am only assuming it is the same issue. I haven't been able to confirm via the logs.
For anyone wondering how to find the entry_id, you can browse to it using File Explorer once you un-hide .storage: https://community.home-assistant.io/t/access-storage-folder/190186/24
I posted to the Ubiquiti Community about this now.
https://community.ui.com/questions/Unifi-Protect-API-crashes-knock-Home-Assistant-connection-offline/7140d950-c058-40f3-abf8-2f9cfb3294ed
Thank you, I think I am suffering this as well. I will need to do some reading as implementing your fix is beyond my current skillset. Have you posted this on the UniFi forum so UI Glen is aware? (Please) Also, rather than reloading the integration which didn’t work I have found that disabling and then re-enabling it restores the sensors.
If you find out how to implement this fix would you be so kind to post a step by step here? I am also in desperate need to fix this issue.
Hi there. So I've just implemented @cholywell's workaround (above) on the cloud key. I downloaded WinSCP and connected to the CK via SSH (enable SSH and its password in settings, the username is 'root'). You can then navigate to the /etc/systemd/system folder and create the two new directories, then the two files and copy and paste in the code he gives. Then I connected to the CK via command prompt in administrator mode, SSH root@IP address of CK input password (you won't see the letters pop up but they are there) and then I pasted in systemctl daemon-reload and ran it.
Then I also setup the automation 3 posts above, just subbing in the entry_id for the one for my instance of Protect, which I did by finding it through File Explorer (https://community.home-assistant.io/t/access-storage-folder/190186/24).
I hope that helps, it hasn't been tested yet!
Thank you, I think I am suffering this as well. I will need to do some reading as implementing your fix is beyond my current skillset. Have you posted this on the UniFi forum so UI Glen is aware? (Please) Also, rather than reloading the integration which didn’t work I have found that disabling and then re-enabling it restores the sensors.
If you find out how to implement this fix would you be so kind to post a step by step here? I am also in desperate need to fix this issue.
Hi there. So I've just implemented @cholywell's workaround (above) on the cloud key. I downloaded WinSCP and connected to the CK via SSH (enable SSH and its password in settings, the username is 'root'). You can then navigate to the /etc/systemd/system folder and create the two new directories, then the two files and copy and paste in the code he gives. Then I connected to the CK via command prompt in administrator mode, SSH root@IP address of CK input password (you won't see the letters pop up but they are there) and then I pasted in systemctl daemon-reload and ran it.
Then I also setup the automation 3 posts above, just subbing in the entry_id for the one for my instance of Protect, which I did by finding it through File Explorer (https://community.home-assistant.io/t/access-storage-folder/190186/24).
I hope that helps, it hasn't been tested yet!
Thank you! Will you keep me updated if this fixes the issue for you?
Also, does anyone know if this will also work on the UNVR? Or is this fix cloud specific?
Thank you! Will you keep me updated if this fixes the issue for you?
Also, does anyone know if this will also work on the UNVR? Or is this fix cloud specific?
So yes I’m not aware of any disconnections of HA and Protect in the week since I applied this workaround to the CKG2+ (albeit it shouldn’t be CK specific). The automation hasn’t fired which means if there have been any they’ve been for less than the 3 minutes I have it set on.
I have been having good luck as well so far. I checked the ui.log and no crashes or anything since October 30th. Don't know if it makes a difference but I'm running: Home Assistant Core 2024.10.4 Home Assistant OS 13.2 CKG2+ with firmware 4.0.20 Protect 5.0.47
Are these the sort of logs you're seeing? ui.log excerpt
Yes. Those are the errors. In addition to the systemd changes on the CloudKey I made a Home Assistant automation to automatically reload the Protect integration when the entities go "unavailable" for longer than 5 minutes. Just in case things don't work out. I have only seen it fire once so far.
alias: "Monitor for Unifi Protect crash" description: If entities are unavailable reload the integration to try to recover. triggers: - trigger: state entity_id: - camera.front_yard_low_resolution_channel_insecure to: unavailable for: hours: 0 minutes: 5 seconds: 0 conditions: [] actions: - action: persistent_notification.create metadata: {} data: message: Unifi Protect title: >- Unifi Protect entities are unavailable. Attempting to recover by reloading Unifi Protect integration. - action: homeassistant.reload_config_entry metadata: {} data: entry_id: 01J9WJ69YY69V7C84KZGE71TR3 alias: Reload Unifi Protect integration mode: singleentry_id is found in the file .config/core.config_entries in the Home Assistant config directory.
So this basically reload the Unifi integration is that correct? Is the the same as disabling and reenabling the integration? Because that's what I have to keep doing to fix the issue.
I'm having a hard time finding the Home Assistant config directory though. I'm using file editor and can't see it. Could you point me in the right direction?
Thank you! Will you keep me updated if this fixes the issue for you? Also, does anyone know if this will also work on the UNVR? Or is this fix cloud specific?
So yes I’m not aware of any disconnections of HA and Protect in the week since I applied this workaround to the CKG2+ (albeit it shouldn’t be CK specific). The automation hasn’t fired which means if there have been any they’ve been for less than the 3 minutes I have it set on.
Hey just wanted to check in with you to see if the issue is still fixed for you. Also does the fix keep working when you update the Protect software? I'm not running the CK but I'm hoping the fix could maybe also work on the Dream Machine.
I did some digging on the CloudKey. When those API errors in the ui.log happen the unifi-core process is dieing and systemd is restarting the unifi-core service. Nothing is happening to the unifi-protect service and soon after Home Assistant looses its connection to the Protect API and all entities stop updating. To fix I would manually restart unifi-protect and reload the protect integration in Home Assistant.
I was able to implement a work around on the ClouldKey so I don't have to manually fix anything when this happens.
I made the unifi-protect systemd service a dependent of unifi-core so anytime unifi-core is restarted systemd restarts unifi-protect. This has worked. Now anytime unifi-core dies and is restarted it restarts protect and Home Assistant is able to maintain it's connection. No more reloading the integration.
I added the following files to the CloudKey:
/etc/systemd/system/unifi-core.service.d/override.conf
[Service] Restart=always RestartSec=5 StartLimitInterval=60s StartLimitBurst=3/etc/systemd/system/unifi-protect.service.d/override.conf
[Unit] PartOf=unifi-core.service [Service] Restart=always RestartSec=5 StartLimitInterval=60s StartLimitBurst=3then run systemctl daemon-reload
So far these files have survived protect updates and CloudKey firmware updates
Hey @cholywell I'm trying to implement your solution but it seems that on my Unifi UNVR there is no "unifi-core.service.d" folder in system:
I do see the "unifi-protect.service.d" folder, however!
Would it be enough to just create the folder in the "unifi-protect.service.d" folder or that wouldn't do anything? I'm a bit out of my element here but really hoping that I can use your fix.
Any help would be appreciated!
@VeniceNerd you should be able to create the folder and the files described by chloywell in the path you found. I made my overrides in /etc/systemd/system/unifi-core.service.d/override.conf and it seemed to work.
@VeniceNerd you should be able to create the folder and the files described by chloywell in the path you found. I made my overrides in
/etc/systemd/system/unifi-core.service.d/override.confand it seemed to work.
So I did that and created the override.conf file in JUST the /unifi-protect.service.d folder. I did NOT create the override.conf file in the /unifi-core.service.d folder since I didn't see that on my UNVR.
I'm hoping this will do something but please feel free to chime in @cholywell :)
So I did that and created the override.conf file in JUST the /unifi-protect.service.d folder. I did NOT create the override.conf file in the /unifi-core.service.d folder since I didn't see that on my UNVR.
I'm hoping this will do something but please feel free to chime in @cholywell :)
@VeniceNerd if directories/folders don't exist create them and the override.conf files. Neither directories existed on my CloudKey. It's fine don't worry.
This won't help you guys but perhaps for interest. I bought a UNVR and migrated protect from the CKG2+over to it, with a new HDD in the UNVR. It has been rock solid and I haven't had to apply this workaround (I do still have the automation setup so I would be notified). So I don't think it was a configuration issue as I've made no changes. I am wondering if it might have been to do with the HDD starting to fail. Perhaps that could have caused crashes.
This won't help you guys but perhaps for interest. I bought a UNVR and migrated protect from the CKG2+over to it, with a new HDD in the UNVR. It has been rock solid and I haven't had to apply this workaround (I do still have the automation setup so I would be notified). So I don't think it was a configuration issue as I've made no changes. I am wondering if it might have been to do with the HDD starting to fail. Perhaps that could have caused crashes.
So this IS interesting since I had some weird hard drive issue with my UNVR a while back. I’ll be ordering a new drive just in case and see what happens!
As far as that automation goes could you give me some more details on how to set that up? Am I correct to assume that it will reload the integration automatically? I thought that wasn’t possible with HA? If you could let me know how you set that up I’d appreciate it!
I was starting to see auto recovery events on the timeline in Protect, one a week or so, that was the giveaway to me of drive issues starting.
https://github.com/home-assistant/core/issues/127764#issuecomment-2438621720
The automation info is in that post, the only change to make is to the ID for your protect integration. It will reload the integration and notify you. Reloading isn’t enough I found in most occurrences, but it does work if the UniFi Protect instance has also been restarted by the code you’ve been discussing above on the UniFi device itself.
I was starting to see auto recovery events on the timeline in Protect, one a week or so, that was the giveaway to me of drive issues starting.
The automation info is in that post, the only change to make is to the ID for your protect integration. It will reload the integration and notify you. Reloading isn’t enough I found in most occurrences, but it does work if the UniFi Protect instance has also been restarted by the code you’ve been discussing above on the UniFi device itself.
I’m having issues with this:
“entry_id is found in the file .config/core.config_entries in the Home Assistant config directory”
I don’t know how to find the config directory on home assistant. How did you get to that?
“entry_id is found in the file .config/core.config_entries in the Home Assistant config directory”
I don’t know how to find the config directory on home assistant. How did you get to that?
Whoops looks like this is .storage not .config and it's in the same spot as the Home Assistant config files.
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.