Die Ueberwachung endete bisher mit einem Toast und verschwand — fuer Kunde,
PDF und Server existierte sie nicht (Sitzungen werden nicht synchronisiert).
Damit fehlte ausgerechnet der Nachweis fuer die haeufigste Reklamation
("die Kamera faellt staendig aus"). Genau dafuer wird ueberwacht.
Vor der Auswertung mussten drei Luecken in der Datengrundlage geschlossen
werden. Alle drei haetten das Ergebnis systematisch beschoenigt:
1. Der Startzustand wurde gemessen, aber nicht gemeldet. Ein Geraet, das vom
Anfang bis zum Ende des Termins tot war, hatte NULL Ereignisse — die
Auswertung haette ihm 100 % Verfuegbarkeit ins Kundendokument geschrieben.
Das Plugin erzeugt dafuer jetzt beim Start ein down-Ereignis und setzt
downSince, damit ein spaeteres up eine echte Ausfalldauer bekommt statt 0.
2. Ein beim Beenden noch offener Ausfall wurde nirgends abgeschlossen und
zaehlte gar nicht. stopMonitor liefert jetzt startedAt/endedAt/zustand,
die Auswertung rechnet ihn bis zum Sitzungsende zu.
3. Die Gesamtaussage ist das SCHLECHTESTE Geraet, nicht der Mittelwert — ein
Totalausfall verschwindet sonst zwischen neun gesunden Geraeten.
Ausserdem am Monitor:
- PARTIAL_WAKE_LOCK (12 h Grenze). Der Monitor war der einzige Langzeitpfad
ohne CPU-Sperre; der WifiLock allein haelt nur das Funkmodul wach. Bei
ausgeschaltetem Display streckt Android die Schleife, und es fehlen genau
die Messpunkte, auf denen die Aussage "ueber sechs Stunden stabil" beruht.
- Thread.sleep -> delay(): blockierte den Dispatcher-Thread ueber die gesamte
Wartezeit und nahm ihn parallelen Messungen weg.
- Reisst der Lauf ab (Prozess tot, App beendet), wird trotzdem ein
Teilergebnis gespeichert und als unvollstaendig gekennzeichnet, mit dem
letzten echten Messpunkt als Endzeit. Vorher wurde die Endzeit auf "jetzt"
gesetzt — eine Verfuegbarkeit ueber Stunden auszuweisen, in denen gar nicht
gemessen wurde, waere eine Falschaussage im Abnahmeprotokoll.
- Der Browser-Mock ist jetzt eine echte Zustandsmaschine. Vorher wuerfelte er
je Tick unabhaengig up oder down und erzeugte Folgen wie up,up,down,down,
die es in der Wirklichkeit nicht gibt (ein Ereignis IST ein Wechsel) — eine
Auswertung liess sich damit nicht sinnvoll pruefen.
Dolibarr-Seite gleich mit: die sechs neuen Schluessel in BEIDE Feldtabellen
(netdiagKundenfelder + messfelder.ts). Ohne das stuende im Kunden-PDF nur die
Ampel — der Fehler, der bei der Whitelist schon einmal passiert ist.
Geprueft: neues Werkzeug tools/pruefe-monitor.mjs rechnet sechs konstruierte
Faelle gegen von Hand ermittelte Sollwerte durch, darunter die drei kritischen
(durchgehend totes Geraet -> 0 % statt 100 %, offener Ausfall am Ende,
ein totes unter neun gesunden). Alle korrekt. Danach im Emulator ueber eine
echte Ueberwachung von 59 s: Messung entsteht, alle Felder korrekt beschriftet.
