Connection and discovery
1. Test Core directly
From a computer or phone on the same network, open http://POD_IP:3000. Use the current LAN address from your router, not an old address saved in a client.
If it fails, verify the Pod is powered, connected, and running Core. On the Pod:
sp-status
sp-logs2. Check network isolation
Guest Wi-Fi, separate VLANs, and access-point client isolation can block local traffic. Bonjour/mDNS discovery and HTTP connectivity are different: manual IP can work even when multicast discovery is unavailable.
Core advertises _sleepypod._tcp and serves its API on 3000. Its sensor WebSocket uses 3001. Avoid opening either port to the public internet; the API has no authentication.
3. Check iOS permissions
In iOS Settings, ensure the sleepypod app has Local Network permission. Reopen the app, retry discovery, then enter the Pod IP manually if needed. Confirm the selected backend matches Core.
4. Check the Dial
In settings, verify the Wi-Fi connection and Pod IP. Use Discover Pod or enter the address manually. Inspect the USB serial monitor for API errors. The Dial periodically synchronizes at a 30-second interval.
5. Separate discovery from stale state
If clients connect but disagree, compare the selected side, wait for their next update, then refresh. Confirm a control change in Core itself. Persistent disagreement after refresh is useful evidence for a client bug report.
Source reference: Network trust · HTTP and WebSocket architecture · iOS discovery · Dial troubleshooting