iPhone: FTW Cloud hears that the phone looks, even when that changes during the handshake

[frahlg]

While Fredrik had the app open, his box sent to FTW Cloud every 5–6 s instead of once a second (follow-up from #28). Two things caused it. This PR fixes the one in the app.

1. The app lost the watch (fixed here). CloudCarrier sends watch only on an open session. A launch passes through inactive, so message 1 often says hz: 0. If the app came to the front before message 2, setLooking(true) found no open session and sent nothing, and nothing sent it later. The service then never asked the box for 1 s updates, and the box stayed at 5 s for the whole session. Three of five cold starts of the 0.3.1 release build lost the watch.

Now CloudCarrier keeps what the service last heard: message 1's hz, then each watch. When the session opens and the phone has changed its mind, it sends watch at once. A change while the session is closed still goes in the next message 1, as before.

2. Fredrik's box reads its meter every 5 s (not changed here). The site meter is the Sungrow inverter, and its driver asks for a read every 5 s. The box sends live only when a reading changed. So even with the watch in force, it cannot send more often than every ~5 s. What the watch changes there is the delay after each reading: at most ~1.25 s instead of up to ~5 s. I read this from the home box, read-only, at 19:19 CEST: live went every 5.7–6.3 s and trailed each Sungrow reading by 0.9–4.7 s, which is the 5 s cadence with no phone looking.

Tests

• lookingChangedDuringTheHandshakeIsSaidOnceOpen fails on main (watches == [], both ways round) and passes here.
• lookingChangedWhileClosedGoesInMessage1: a redial sends no extra watch.
• swift test: 276 tests pass.

Measured end to end (13 Oct, 19:25–19:58 CEST). Release builds in the iOS 26.5 simulator, Core from srcfl/ftw master (f4bfff69) on the laptop with simulated devices, and the deployed cloud.ftw.energy. The test meter read every second, so the box could send at 1 Hz. I logged each frame the box sent from its GET /api/cloud/preview, every 200 ms.

Cold start, app on Now for 20 s	Runs with the watch	Gap between live frames (median per run)	Snapshot to first cloud update
main (0.3.1)	2 of 5	5.5–5.7 s in the three without; 1.1–1.25 s in the two with	0.1–5.2 s
this branch	8 of 8	1.0–1.25 s	0.05–1.2 s

• Home button: the box went back to 5 s after 22.4 s (main: 26.8 s). The protocol allows up to 60 s.
• Back from the background: median gap 1.14 s.
• The gaps are 1.0–1.25 s, not 1.0 s, because the box looks at its readings once a second on a 250 ms tick.

Not in this PR

• Reading a Sungrow faster than 5 s needs hardware evidence first.
• Core ignores the number a driver returns from driver_poll; only host.set_poll_interval counts (go/internal/drivers/registry.go). Ferroamp asks for 1000 ms and is read every 5 s. That belongs in srcfl/ftw.
• The service and the box were fine: once the session was open, watch reached the box every time.

🤖 Generated with Claude Code

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-10-13T18:02:10.955648Z	9baf63e	PR opened

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.