patrickandClaude Sonnet 5
7f06d1cecc
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
43 lines
3.1 KiB
Markdown
43 lines
3.1 KiB
Markdown
# 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)
|
||
1. Test-Label drucken (`test_label_erzeugen.py`, mind. eine Größe pro geplantes Labelformat).
|
||
2. Auf Ziel-Untergrund kleben/befestigen (Rucksack-Stoff, Fahrzeuglack o. Ä. – reale Anbringung testen, nicht nur Tisch/Papier).
|
||
3. 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
|
||
4. Bei Fehlschlag: Modulbreite/Ruhezone in `_BARCODE_OPTIONEN` (`app/services/label.py`) erhöhen, neues Test-Label drucken, erneut testen.
|
||
5. Ergebnis (Gerät, Abstand/Winkel, Erfolg/Fehlschlag) hier oder in einer neuen Notiz festhalten, bevor Seriendruck freigegeben wird.
|