scripte/MABEA

Fork 0

Files

T

patrickandClaude Sonnet 5 7f06d1cecc

CI / backend-tests (push) Successful in 1m3s

Details

CI / frontend-build (push) Successful in 56s

Details

Karte 10: Test-Label-Skript + Druck-/Scan-Testcheckliste

Label-Druck-Test mit echten Geräten ist ein physischer Schritt, nicht per
Code erledigbar. Stattdessen: scripts/test_label_erzeugen.py erzeugt lokal
ein Test-PDF ohne DB-Verbindung, Karte 10 um 5-Schritt-Checkliste ergänzt.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01CVgbozhYmuEhiEJHffRXCV

2026-09-04 18:01:36 +02:00

3.1 KiB

Raw Blame History

Karte 10 – QR-Code / Barcode

Status: Roadmap-Feature, Datenmodell-Vorbereitung schon in V1 nötig

Entscheidung

QR/Barcode-Scan ist gewünschte spätere Funktion:

Objekt-Code (Rucksack/Fahrzeug) → Direktsprung ins Kontroll-Screen (statt Portal → Standort → Fahrzeug → Rucksack suchen).
Geräte-Code (Einzelgerät) → automatische Seriennummer-Erkennung.

Konsequenz für V1 (jetzt schon vorsehen)

Prompt 06 (Datenmodell): Objekt (Rucksack/Fahrzeug) und Einzelgerät bekommen je ein eindeutiges Code-/ID-Feld, auch wenn Scan-UI erst später kommt.
Kein Schema-Umbau später nötig, nur Scan-Funktion (Kamera/Reader) ergänzen.

Umsetzung

Eigentliche Scan-Funktion → Prompt 24 (Roadmap), nicht MVP.

Barcode-Format (Nutzerentscheidung)

Standard: Code128, eindimensional, weit verbreitet.
Bewusste Wahl statt proprietärem/2D-Format, um Geräteauswahl offen zu halten.
Konsequenz Datenmodell: Code-Feld (Objekt/Gerät) muss Code128-kompatiblen Zeichensatz aufnehmen können (alphanumerisch, keine Sonderzeichen-Einschränkung nötig, Code128 deckt ASCII ab).
Zusatzanforderung: Code muss per Tablet-/Smartphone-Kamera lesbar sein (Software-Scan). Code128 ist per Kamera grundsätzlich lesbar, aber empfindlicher gegenüber Druckqualität/Abstand/Winkel als 2D-Codes wie QR. Konsequenz: Drucklayout (Größe, Kontrast) muss auf Kamera-Scan getestet werden.

Label-Design (offener Punkt, Prompt 24 vertiefend)

Physisches Label-Design (Größe, Material, Kontrast, Schriftgröße Klartext unter Code, Anbringungsort am Objekt) muss mit aufgenommen werden, nicht nur der Code-Inhalt selbst.
Anforderungen an Label aus Einsatzumfeld: witterungsbeständig/abriebfest (Rucksäcke/Fahrzeuge im Rettungsdiensteinsatz), Kontrast/Größe für zuverlässigen Kamera-Scan (siehe oben).
Klartext-Fallback auf Label empfohlen (Code + lesbare Objekt-ID), falls Scan mal ausfällt.
Konkretes Layout/Material erst bei Umsetzung (Prompt 24) final festlegen, hier nur als Anforderung vermerkt.

Umsetzungsstand (2026-09-04)

Backend: objektposition.code-Feld, Lookup-/Vorschlag-Endpunkte, PDF-Label-Erzeugung (app/services/label.py) fertig.
Frontend/Flutter: Kamera-Scan (Objekt-Code, Scan-First) fertig.
Offen: Label-Druck-Test mit echten Geräten (physischer Schritt, nicht per Code erledigbar). Test-PDF erzeugen: python -m scripts.test_label_erzeugen im Backend-venv.

Test-Checkliste (pro Labelgröße/-material einmal durchgehen)

Test-Label drucken (test_label_erzeugen.py, mind. eine Größe pro geplantes Labelformat).
Auf Ziel-Untergrund kleben/befestigen (Rucksack-Stoff, Fahrzeuglack o. Ä. – reale Anbringung testen, nicht nur Tisch/Papier).
Mit jedem vorgesehenen Scan-Gerät testen (PWA im Handy-/Tablet-Browser, Flutter-App auf Android):
- Normalabstand (~15–20 cm) und Winkel 0°
- Schräger Winkel (~30°)
- Schwaches Licht / Gegenlicht
Bei Fehlschlag: Modulbreite/Ruhezone in _BARCODE_OPTIONEN (app/services/label.py) erhöhen, neues Test-Label drucken, erneut testen.
Ergebnis (Gerät, Abstand/Winkel, Erfolg/Fehlschlag) hier oder in einer neuen Notiz festhalten, bevor Seriendruck freigegeben wird.

3.1 KiB Raw Blame History Unescape Escape