Eight Sleep Pod connectivity (offline / recurring drops)¶

URL: https://mkdocs.justinsforge.com/memory/general/reference_eight_sleep_pod_connectivity/

ACTUAL recurring root cause (confirmed 2026-07-02)¶

After the 2.4GHz wifi fix held (hub confirmed associated to the 2.4 AP, not roaming to 5GHz) the Pod STILL dropped offline every few days. Live diagnosis found the real cause: the Home Assistant custom eight_sleep integration (lukas-clarke v1.0.22, /config/custom_components/eight_sleep/) ran four DataUpdateCoordinators polling the Eight Sleep cloud constantly: USER every 30s, DEVICE/BASE/SPEAKER every 60s each, roughly 5 cloud hits/min, ~7,200/day, 24/7 on Justin's single account. That nonstop pressure/re-auth thrashes the account's cloud session and knocks the hub's own registration loose ("white LED, associated to wifi, but PodOffline in the app"). Justin's own tell: the drops started when we stood up the Eight Sleep API polling. The speaker coordinator hammered /audio/player every 60s, the exact endpoint that returns {"errorType":"PodOffline"} when the hub is down.

Fix deployed 2026-07-02: edited the four *_SCAN_INTERVAL constants at top of __init__.py: DEVICE/USER/BASE = timedelta(hours=1), SPEAKER = None. ~99% reduction (7,200 -> ~72 cloud hits/day). Backup at __init__.py.bak-20260702. Added package /config/packages/eight_sleep_lowpoll.yaml: script.eight_sleep_refresh (on-demand homeassistant.update_entity, expose to Alexa / dashboard button) + automation.eight_sleep_morning_sleep_data_pull (09:00 daily pull).

CAUTION / debt: intervals are hardcoded in the integration source; a HACS/integration update will RESET them to 30/60s and reintroduce the thrash. Re-apply after any eight_sleep integration update. True on-demand-only (None intervals) was NOT verified because the Pod was offline during the fix; revisit dropping to None once the hub is back online and update_entity refresh is confirmed to force the coordinators. Forge's own scripts/integrations/eight-sleep/poll.py cron is DISABLED (each run is another account login, adds to thrash), keep it off; run manually only sparingly. Note (2026-07-02): the WA801N 2.4GHz AP is, per Justin, a separate router he bought from Amazon; disregard the earlier "TP-Link on MikroTik ether5" wiring claim below until re-confirmed.

Prior wifi root cause (confirmed 2026-05-30, real but not the whole story)¶

The Pod Hub kept showing "white LED but offline in the app" and dropping roughly every other night. Root cause: the Hub was associating to 5GHz on the single merged GFiber SSID (Wieb Wifi). 5GHz from under/beside the bed is too weak to hold a steady connection to Eight Sleep's cloud, so the Hub joins wifi (white LED) but never completes / sustain its cloud session.

Confirmed by: resetting the Hub and pairing it to an iPhone Personal Hotspot with "Maximize Compatibility" ON (forces 2.4GHz) brought it online immediately. So the Hub and Eight Sleep cloud are healthy; the home 5GHz link was the only problem.

Diagnostic facts¶

The HA eight_sleep integration is 100% cloud-based (polls app-api.8slp.net / client-api.8slp.net); it has no local visibility into the Hub. HA "available" entities can be stale cached values, always check last_updated freshness, not just state.
AdGuard (CT 105) is not blocking 8slp.net (verified in querylog); DNS resolves fine. The only Eight Sleep cloud traffic on the LAN comes from the HA integration (appears as client 192.168.86.67), never from the Hub when it's failing.
Hub LED: yellow = pairing mode (small button on back), white = joined wifi. White-but-app-offline = on wifi but not cloud-registered.
GFiber/Google merged SSID cannot split bands or disable 5GHz in the standard app (check "Advanced Wi-Fi settings" for a band-steering toggle, not guaranteed).

Permanent fix (in progress)¶

Dedicated 2.4GHz-only SSID from a TP-Link TL-WA801N AP (2.4GHz, 300Mbps, passive PoE). INSTALLED as of ~2026-06-08: SSID "Gus the Bass", plugged into MikroTik CRS328 ether5 (not Finn's spare NIC as originally planned). Pod joins that SSID on the main 192.168.86.0/24 subnet.

Incident 2026-06-12: the AP shipped with its DHCP server active at 192.168.0.254 and poisoned ~23 Wi-Fi clients with 192.168.0.x leases starting ~2026-06-08 (Echos, Tapo, WiZ, Lutron, printer all "down"). Fixed two ways: DHCP snooping on the switch (sfp-sfpplus3 sole trusted port, see [[reference-mikrotik-crs328]]), then the AP itself was pin-reset and rebuilt by Claude via Playwright: same SSID "Gus The Bus" + passphrase, DHCP server OFF, Smart IP LAN (mgmt at 192.168.86.177), admin creds in ~/.forge-secrets/tplink.env (TPLINK_AP_*). Note: snooping alone could NOT protect the AP's own wireless clients (DHCP replies to them never cross the switch), which is why the in-AP fix mattered for the Pod.

Optional belt-and-suspenders: DHCP reservation for the Hub once it's on the 2.4 SSID.

[Claude Code]