LBX-25: Fehlende Datensätze — Ingestion vom Fertigungs-Tablet seit 25.06. gestoppt

Roman Kempf · Trello, 2026-07-09:

@integritsol Moin :) Ich habe mir diese Karte mal angenommen, da ich das feedback gesendet habe. Also ich werde heute nochmal testen, wie es aussieht und rückmeldung geben.

tr-c:6a4f4c39c5216d154ffd0203

Felix · Trello, 2026-07-08:

@binder68 bitte nochmals mit Fertigungstablet testen und beobachten

tr-c:6a4e45b5b896c72b35a9da1e

Felix · Trello, 2026-07-08:

**🚀 v1.8.4 LIVE auf Production (08.07. 12:18Z)** — Ingestion-Härtung deployed und verifiziert.

**Prod-Verifikation (read-only):**

- Container `1.8.4` healthy, beide Quarantäne-Migrationen applied (`20260707` + `20260708`)
- MQTT-Bridge reconnected (QoS 2), Ingest fließt (REST + MQTT), **0 × 401 auf Telemetry-Routen seit Deploy**
- Keine Errors im Log

**Damit gilt ab sofort:** Ein Tablet/Gerät mit abgelaufener/widerrufener Anmeldung verliert **keine Daten mehr** — Uploads werden anonym angenommen (`meta.authFallback`, ohne Customer-Attribution/Ticket-Side-Effects).

**Auf dieser Karte noch offen (unverändert wichtig):**

- ① Broker-Logs (Tablet-Connects seit 23.06.) — Evidenz verfällt
- ② @binder68 Vor-Ort: Login-Check + Test-Upload (Kommentar oben) — für saubere Attribution weiterhin sinnvoll, auch wenn der Datenverlust jetzt gestoppt ist; **betroffene Akkus einmal neu verbinden** (History-Nachlieferung, u. a. #0419-LB28MS-S700 / SN AD 10115)
- ③ BullMQ-Job 36316 replayen

tr-c:6a4e4181844508dd90208bad

Felix · Trello, 2026-07-07:

**PR offen:** https://github.com/LITEWERKS-GmbH/liteblox-backend/pull/83 (`fix/lbx-25-ingestion-hardening` → `main`, MERGEABLE, CI läuft — Gitleaks ✅).

Inhalt: TelemetryIngestGuard (invalid/revoked/fehlender Token → 202 anonym statt 401, `meta.authFallback`), Serial-Quarantäne (0/0xFFFF/Overflow), Rate-Limit-Fix (`trustProxy` loopback+private, XFF-spoof-resistent), Retry-Loss-Fix, 30-Tage-Quarantäne-Retention. Zweifach reviewt (Staff + Codex), main (1.8.2) gemergt, 1480 Tests grün.

Nach Merge: dev-Deploy → Live-Verifikation (revoked-Token-Ingest → 202 + Snapshot; XFF-Spoof ändert Bucket nicht) → dann prod (manuelles Gate). Migration `20260707_telemetry_quarantine` läuft vor dem App-Container.

tr-c:6a4d340df49fe2e9c25d2186

Julian Binder · Trello, 2026-07-07:

Habe mich mit 4 Akkus verbunden vona lle 4 kamen nun die Daten an. Aber man muss es immer kontrollieren ich ich meine ich habe es selbst erlebt das Daten mal nicht ankamen obwohl Wlan aktiv war und auch der account angemeldet war.

[#0076-LW28MS-S707](https://admin.liteblox.de/devices/49978175-ff44-409d-a0ca-ad33446e054f "‌") verbunden udn klappt;

[#0077-LW28MS-S707](https://admin.liteblox.de/devices/e6d480e0-34ce-411d-bfca-f39a1b587d4e "‌"); verbunden und klappt

[#0092-PS40MS-S707](https://admin.liteblox.de/devices/12a232aa-b72c-48a8-9f21-2af1a4cc1d37 "‌"); verbunden und klappt
[#0093-PS40MS-S707](https://admin.liteblox.de/devices/12a232aa-b72c-48a8-9f21-2af1a4cc1d37 "‌"); verbunden und klappt

Auch ist mri aufgefallen das in den Logs immer das default datum udn eine unplausible uhrzeit steht obwohl das system die Uhrzeit hat.

tr-c:6a4d02e635c06b3a5aa709b0

Felix · Trello, 2026-07-07:

@binder68 **Vor-Ort-Check Fertigungs-Tablet — bitte vor 09.07.**

**Kontext (Code- + Server-Analyse):** Tablet-App (v1.2.0) sendet per HTTPS mit Firebase-Login. Server nachweislich ok. Prod-Logs zeigen 401 „Firebase ID token has been revoked" auf Telemetry-Endpoints (28.06. / 02.07. / 05.07.) → wahrscheinliche Ursache: **abgelaufene/widerrufene Anmeldung auf dem Tablet**. Die App puffert fehlgeschlagene Uploads nicht — nicht gesendete Test-Sessions sind verloren; die BMS-interne History eines Akkus wird aber beim nächsten erfolgreichen Connect automatisch nachgeliefert.

**Schritte:**
1. App öffnen → eingeloggt? Welcher Account? Fehlermeldung? → Screenshot. **Falls abgemeldet: neu einloggen — vermutlich der Fix.**
2. Test-Upload: Batterie verbinden → trennen → **exakte Uhrzeit (Minute) an Felix** → wir verifizieren live server-seitig.
3. Nach erfolgreichem Test: alle seit ~23.06. getesteten Akkus einmal neu verbinden (History-Nachlieferung) — u. a. `#0419-LB28MS-S700` / SN AD 10115, falls dort getestet.
4. Info: Lief bis ~23.06. parallel noch die alte App (Tablet oder Zweitgerät)? Wurde daran etwas geändert?
5. Nur falls 1–2 unauffällig: Browser auf dem Tablet → https://api.litebloxbatteries.com erreichbar? App-Version notieren.

**Wichtig:** Tablet nicht zurücksetzen / App nicht neu installieren, bevor 1–2 dokumentiert sind.

tr-c:6a4cdfb377325ed7b7a3f3aa

Felix · Trello, 2026-07-07:

**Tiefen-Analyse 07.07.2026 (Prod-DB + Valkey + Loki, read-only) — Server exkulpiert, Fehlerort vor der API.**

**Pipeline:**
- Snapshot-Volumen konstant, kein Einbruch nach 25.06.: MQTT ~250–350/Tag, REST ~80–130/Tag (DB, 15.06.–07.07.)
- Server-seitige Verluste gesamt: 1 BullMQ-Failed-Job (24.06. 09:07Z, Serial 2855 `#HA72-LB31XX`, „Unable to start a transaction" → **replaybar**, Job-ID 36316) + ≤5 MQTT-JSON-Parse-Drops + 2 REST-500 (25.06./02.07., ~150 s Timeout). Sonst nichts.

**Tablet-Stop eingegrenzt auf 23.06. 13:01 – 25.06.:**
- Batch LW96MS (Serials 11902–11975, 20.–23.06.): Erst-Ingest via **MQTT = Tablet**. Letzter Tablet-MQTT-Snapshot: **23.06. 13:01** (`#0024-LW96MS-S706`)
- Alle neuen Fertigungs-Geräte ab 23.06. (LW28MS-S707, PR/PS-S707): **nur noch REST** (App 1.2.0) → App-Pfad ok, Tablet-MQTT-Pfad tot
- Broker→API gesund (Feld-MQTT läuft durchgehend, QoS 2, clean:false) → Fehlerort: **Tablet→Broker** (`mqtt.liteblox.de`, Legacy-Host, Logs nicht in Loki)

**Neben-Befund (eigenes Ticket): korrupte Serials mappen Daten auf falsche Geräte.** Payload-`serial` = Mapping-Key, keine Plausibilitätsprüfung:
- Serial **65535** (0xFFFF) `#0304-LB28XX-S608` ← empfängt Daten von `#X02-LW48V` (9 Snaps 30.06.–01.07.)
- Serial 58 `#F259-LB28XX` ← `#0145-LB20XX-R605` (01.–06.07.); Serial 115 ← `#F021-LB14XX`
- Phantom-Serial **26889** = Duplikat von `#0093-PR60XX-S707` (echt: 11854), 1 Snap 30.06.
- Ältere Phantome: 57150, 50724; korrupte cfg-Namen: `S=` (11118), `1`, `#0137–SR40XX–S`

**Referenzfall `#0419-LB28MS-S700` (SN 10115):** letzter Ingest 06.06. 06:47Z (MQTT, sauber, keine parseWarnings). Danach nichts — weder korrekt noch fehlgemappt (per cfg-Name-Suche über alle Snapshots verifiziert). Falls nach 25.06. am Tablet getestet → Daten liegen client-seitig.

**Zeitkritisch:** Loki-Retention ~14 Tage — 25.06.-Fenster fällt ~09.07. aus der Retention.

tr-c:6a4cd61d8140d79dee1a3785

Erledigt. Seit dem Server-Update vom 08.07. kommen die Datensätze aus der Fertigung wieder regelmäßig an, zuletzt am 16.09. Falls auf dem Tablet trotzdem noch etwas fehlt, bitte hier kurz Bescheid geben.