fizzlepoof/truenas-stacks
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs: clarify current unifi protect chime state
Some checks failed
secret-guardrails / artifact-secret-scan (push) Has been cancelled
Details
secret-guardrails / gitleaks (push) Has been cancelled
Details

Browse Source
This commit is contained in:
Fizzlepoof
2026-05-26 20:10:45 +00:00
parent a282fe43bd
commit 77da65e64a
16 changed files with 193 additions and 43 deletions
Download Patch File Download Diff File Expand all files Collapse all files

6
docs/troubleshooting/KNOWN_QUIRKS.md
View File

@@ -59,6 +59,12 @@ Per-service gotchas that aren't bugs but will bite you if you forget them.
- `docker restart` or `docker compose restart` will NOT fix missing network attachments
- Must use `docker compose --env-file .env down <service> && docker compose --env-file .env up -d <service>`
### UniFi Protect WiFi chimes after doorbell/network changes
- A UniFi Protect WiFi chime can look healthy in UniFi Network while still showing offline in Protect if a per-client Camera virtual-network override puts it on a lane that does not preserve the required Protect path.
- In John's current environment, the known-good fallback for the two Wi-Fi chimes is Management/default `UniFi Wireless`, not the Camera-lane override that was tried on 2026-05-22.
- After a doorbell is re-adopted, also verify each chime's `ringSettings.cameraId` still points at the current doorbell object; a stale camera binding can break ringing even when the network path is healthy.
- Treat "device online in UniFi Network" and "device healthy in Protect / rings for the current doorbell" as separate checks.
---
## Serenity