From 6d1c426ee431d202b01299ec5ef348f967cda727 Mon Sep 17 00:00:00 2001 From: serversdown Date: Sun, 21 Jun 2026 20:22:39 +0000 Subject: [PATCH] fix: recognize 'Start' state when confirming measurement start The /start handler waited for measurement_state == "Measure", but the device reports "Start" while measuring. The confirmation check therefore never matched, so the post-start status loop always ran its full 3x DOD retry cycle over cellular, pushing the call past ~10s. That blew past the Terra-View proxy's request timeout and surfaced to users as a misleading "Unknown error" even though the unit had already started recording. Match the device's actual reported state (and stay consistent with persist_snapshot's MEASURING_STATES handling) so /start confirms on the first attempt and returns promptly. Co-Authored-By: Claude Opus 4.8 (1M context) --- app/routers.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/app/routers.py b/app/routers.py index 7764b48..ac455ad 100644 --- a/app/routers.py +++ b/app/routers.py @@ -939,7 +939,7 @@ async def start_measurement(unit_id: str, db: Session = Depends(get_db)): db.expire_all() status = db.query(NL43Status).filter_by(unit_id=unit_id).first() logger.info(f"State check: measurement_state={status.measurement_state if status else 'None'}, start_time={status.measurement_start_time if status else 'None'}") - if status and status.measurement_state == "Measure" and status.measurement_start_time: + if status and status.measurement_state in ("Start", "Measure") and status.measurement_start_time: logger.info(f"✓ Measurement state confirmed for {unit_id} with start time {status.measurement_start_time}") break