From 3d69412f5a30b2f9f2d62406c4197ea88e01a574 Mon Sep 17 00:00:00 2001 From: Michael Sauer Date: Sun, 13 Sep 2026 00:40:55 +0200 Subject: [PATCH] docs: Wiederaufnahme-Verhalten bei Firmware-Updates differenzieren MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Der Abschnitt beschrieb pauschal ein rund siebenminütiges TCP-Timeout ohne Wiederaufnahme. Heute gemessen gilt das nur, wenn die Gegenstelle komplett stirbt (Prozess weg). Bleibt sie erreichbar und liefert nur nichts mehr, greift das 5-s-RECV_TIMEOUT der Firmware, und die Lampe setzt per Range sauber fort – am EVK fünfmal hintereinander bis das Image vollständig war. Co-Authored-By: Claude Sonnet 5 --- README.md | 18 +++++++++++++----- 1 file changed, 13 insertions(+), 5 deletions(-) diff --git a/README.md b/README.md index 239509a..a89d0e7 100644 --- a/README.md +++ b/README.md @@ -95,11 +95,19 @@ Update, oder scheitert der Start aus einem anderen Grund, antwortet sie mit `409 Lampe und bootet mit der neuen Version. Wird das Image abgelehnt, gibt es **keinen** Reset — die Lampe läuft mit der alten Firmware weiter und trägt den Grund in `last_ota_error` (`GET system/info`) ein. Ein Verbindungsabbruch mitten im Download endet bei `last_ota_error = download`. Die Firmware kann einen -sauber abgerissenen Transfer per HTTP-Range wieder aufnehmen (auf eine feste Rundenzahl begrenzt), aber -darauf sollte man sich nicht verlassen: Stirbt die Gegenstelle mitten im Download, hängt der Lesevorgang -am EVK gemessen rund **sieben Minuten** in einem einzigen TCP-Timeout — das `RECV_TIMEOUT` von 5 s des -HTTP-Clients greift dort nicht — und bricht danach ohne Wiederaufnahme ab. Die Lampe bleibt in dieser Zeit -über REST erreichbar und lässt sich weiter schalten, weist aber jeden weiteren `fw_update` mit `409` ab. +abgerissenen Transfer per HTTP-Range wieder aufnehmen (auf eine feste Rundenzahl begrenzt) — was dabei +passiert, hängt aber davon ab, wie die Gegenstelle abbricht: + +- **Gegenstelle bleibt erreichbar, liefert aber nichts mehr** (Station hängt, Netzwerkpfad lebt): Das + `RECV_TIMEOUT` von 5 s des HTTP-Clients greift wie vorgesehen, die Lampe gibt die Verbindung auf, baut + eine neue auf und setzt per `Range` genau dort fort, wo sie aufgehört hat. Am EVK gemessen funktionierte + das über **fünf** aufeinanderfolgende Reconnects hinweg, bis das Image vollständig übertragen war — auf + diesen Fall darf man sich also verlassen. +- **Gegenstelle stirbt komplett** (Prozess weg, nicht mehr erreichbar): Der Lesevorgang hängt am EVK + gemessen rund **sieben Minuten** in einem einzigen TCP-Timeout, den das 5-s-`RECV_TIMEOUT` der Firmware + nicht abfängt, und bricht danach **ohne** Wiederaufnahme ab. Das bleibt der unangenehme Fall: Die Lampe + ist während der sieben Minuten über REST erreichbar und lässt sich weiter schalten, weist aber jeden + weiteren `fw_update` mit `409` ab, bis der Download endgültig als gescheitert gilt. Werte von `last_ota_error` (`null`, solange nichts fehlgeschlagen ist):