Repository navigation
Show remote command results sooner on the phone, watch and Live Activity - #805
Merged
bjorkert merged 4 commits intoNov 1, 2026
Merged
Conversation
Every Nightscout fetch rebuilds the chart, and every rebuild sent the full 24-hour state to the watch, even when nothing in it had changed. Each send can wake the watch app. The phone now skips a state equal to the last one sent, apart from its build time. It still sends at least every 5 minutes, well inside the 10 minutes after which the watch treats the phone's data as stale and fetches on its own. It always sends after the session activates or the watch changes (new install or pairing), and retries after a failed send.
When the phone is out of reach, the watch sends commands directly to Loop or Trio. Nothing then fetched the result: the watch only fetches on its own once the phone's last state is more than 10 minutes old, so a command sent soon after losing the phone could take up to 10 minutes to show. After a successful direct command, the watch now fetches 10, 20, 40 and 60 seconds after the send, even while the phone's last state is still fresh, and stops at the first fetch that shows the change: the preset's override or temp target, its cancellation, or a new bolus or carb entry with the sent amount. A check that never matches only means all four fetches run. The follow-up stops as soon as a newer state arrives from the phone, so a fetch that was already under way does not replace it. While the phone's last state is still fresh, its alarm stays shown, since the watch's own fetch has no alarms. The watch's own fetch now reads the override name from "notes" before "reason", as the phone does, so Trio overrides show the same name on both.
Loop and Trio apply a command within seconds, but the phone only saw the result on its next regular fetch: up to 2 minutes for treatments (overrides, temp targets, boluses, carbs) and about 5 minutes for device status (IOB, recommended bolus). The phone, the watch and the Live Activity showed the old state until then. After a command is sent from the phone or the watch, the phone now fetches treatments and device status 10, 20, 30, 60, 90 and 120 seconds later. It stops as soon as the command's change is visible: the active override or temp target differs from before the send, or a new bolus or carb entry with the sent amount appears. A Trio meal sent with a bolus waits for both. A newer command restarts the schedule. Each fetch schedules the next, so when the app was suspended past several of them, as in the Bluetooth heartbeat modes, it fetches once on resuming instead of all the overdue ones at once.
When the watch fetches on its own, it took the recommended bolus from the latest device status as is. If a manual bolus came after that loop cycle, the recommendation leaves that bolus out, and the watch could start the bolus screen at it. The phone already drops such a recommendation, and the watch only dropped one from before insulin it sent itself. The watch's own fetch now drops it the same way as the phone: when a manual bolus (not automatic, not an SMB) is at or after the loop cycle. This matters more now that the watch also fetches right after a command it sends without the phone, while the phone's last state is still fresh.
MtlPhil
requested review from
bjorkert,
codebymini and
marionbarker
as code owners
October 31, 2026 20:40
Collaborator
Test✅ successful test ConfigurationBuild LoopFollow from this PR onto phone that is observing a Loop URL. Test DetailsTested the sending of bolus, setting/clearing override, sending of carbs. |
marionbarker
approved these changes
Oct 31, 2026
marionbarker
left a comment
marionbarker
left a comment
Collaborator
There was a problem hiding this comment.
Approve from test. I would like a code review prior to merge.
bjorkert
approved these changes
Nov 1, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Loop and Trio apply a remote command within seconds, but LoopFollow only saw the result on its next regular fetch. That's up to 2 minutes for treatments and about 5 for device status.
This follows up on @marionbarker's testing in #792 (comment), where preset changes on the phone and presets sent from the watch were slow to show on the watch.
Phone
Watch
notesbeforereason, so they match the phone.