Your camera's wrong password error can be three defaults deep

Two Tapo C210 cameras sit on my home network, static addresses, DNS pointed at my own AdGuard box. On 2026-10-18 the auth flow rejected a password I knew was right, my probes pushed the camera into a lockout, and the error read "Temporary Suspension: try again in ~1800 s". A camera I own, on my own network, telling me to come back in half an hour. The password was right. Three defaults sat between me and that camera, each one failing in a different way, and a fourth layer under them took every service on the box down for 70 minutes the same day. Layer 1, a toggle that resets on re-bind Tapo's app hides a per-camera switch called Third-Party Compatibility. Mine was off. With it off, the camera's control API rejects every credential, the correct password included. The setting also resets on a re-bind, so a camera that talked to Home Assistant yesterday can stop talking today after nothing but a re-pair in the vendor app. I flipped it on around 20:00 and both cameras accepted auth on the first try. An auth error never mentions this layer, it just blames the password. Layer 2, a username the integration guessed for me Home Assistant's Tapo integration ships cloud setup steps that hardcode the username as "admin". On these cameras the control username is the TP-Link account email, so every "admin" attempt fails no matter what password sits behind it. The winning path was three details: auth with the email, skip_rtsp true, because the RTSP pre-test breaks on the raw @ in the URL, and an empty {} for the cloud password field, skipping it entirely. The camera's own "camera account" credentials only open RTSP. The control endpoint and ONVIF both reject that account, "Invalid authentication data" from one, "Authority failure" from the other. Every app feature, the pan and tilt, presets, the privacy shutter, the siren, needs the full account password, and the SPAKE2+ handshake behind it computes everything locally without touching a TP-Link server. I typed that password into the integration form myself, my agent never saw it, and I made one attempt, because the camera suspends you again for another ~1800 seconds. Layer 3, rules that report success and never engage My AdGuard user_rules section had python-source garbage sitting in it, leftover lines from an earlier quoting crash. AdGuard's behavior here is the nasty part: bad lines make it silently discard the entire section. Every block rule I added reported a clean insert and none of them ever engaged. The fix is unglamorous: 65 valid rules kept, my allowlists untouched, container restarted, then proof. The TP-Link cloud domains the querylog showed, stun.tplinkcloud.com and use1-device-cloudgateway.iot.i.tplinknbu.com among them, now resolve to ::. Five domains, tplinkcloud.com, tplinknbu.com, tplinkra.com, tp-link.com, tapo.com, blocked for the two cameras only, NTP untouched. The cameras went DNS-quiet. The camera's own firmware switch in Home Assistant still reports "on", the update call can't reach anything, the network layer enforces what the UI claims. What shipped PTZ proof first: a jog right moved 54% of the frame, a jog back returned it. 45 entity references validated against the live registry, because the earlier warning-sign cards were unvalidated IDs. Four automations: arm on leave, disarm on home, alert while armed with a snapshot push, disarm on HA start when I'm home, and the test push landed on my phone. The first armed recording is a 1.7 MB 30-second clip at 720p, retention 30 days, auto-pruned. Recordings land on the same box, and I mounted them over SMB, browsed them, unmounted, clean. HA went from 2026.6.0 to 2026.10.2 with a backup taken first, every integration survived. The theme migration cost 4 recovery-mode boots. 2026.10 stopped auto-loading the themes directory, themes must live inline in the config, and YAML comments ate hex colors, empty mode dicts needed explicit braces, and one ghost line survived my regex surgery. Four boots to learn one rule: read the file tail before restarting. The layer nobody counts Capacity. The box runs 7 GB total RAM, with ~1.7 GB of that already in swap even at idle. Frigate had 2K recording hot on both cameras, the record ffmpeg stays hot even when disarmed, plus a CPU detector, plus 20 containers. Swap thrash, load average 182, every service dead from 13:10 to 14:20, smart home dark, 70 minutes. docker stop frigate, and the load fell from 182 to 4 in about 4 minutes, HA back. Reconfig: one 720p stream per camera doing both detect and record, detection 5 fps to 3 fps, a 3 GB memory cap on the container. Post-fix the box sits at load 4.4, both cameras capture at 3 fps, detection live, 20/20 automations on. The decision I keep from it: nothing heavy lands on that box without a free-RAM check first. The clips stay 720p because of the 7 GB constraint, and alerts use 2K snapshots from the camera entities, so the resolution loss lives in recordings I scrub through, never in the push I judge. The part I keep The next camera that tells me "wrong password" gets a vendor-app check before the login prompt. So what's the worst default that ate one of your evenings? Mine cost an evening and 70 minutes of a dark house, and the fix was one switch. Drop yours in the comments, I collect these.