robert/todo
Watch
1
0
Fork
You've already forked todo
 0
Code Issues 3 Pull requests Projects Releases Packages 1 Wiki Activity Actions

Headless Raspberry-Pi-Scanner — Speisekammer per eigenständigem Gerät befüllen #196

New issue
Open
opened 2026-09-12 09:49:43 +02:00 by lena · 1 comment
lena commented 2026-09-12 09:49:43 +02:00
Collaborator
Copy link

Story: Headless Raspberry-Pi-Scanner — Speisekammer per eigenständigem Gerät befüllen

As a Nutzer, der einen Barcode-Scanner an einen headless Raspberry Pi anschließt (kein Display, kein Browser),
I want to dass der Pi eigenständig über die Backend-API Produkte in der Speisekammer ein-/auschecken kann,
so that ich Wareneingang/-ausgang direkt am Regal erfassen kann, ohne ein Gerät mit Browser und Kamera-Scan-Modal (#171) offen zu halten.

Background

Es existiert bereits ein browserbasierter Hardware-Scanner-Modus (#171, HID-Tastatur-Emulation auf einer dauerhaft offenen Seite) und ein bestehender Command ScanPantryProductBarcodeCommand (#94/#104), der Barcode -> Check-in/Check-out/Neuanlage abbildet. Für den Pi wird kein Browser-Frontend benötigt — der Pi soll den Command direkt über eine authentifizierte HTTP-API ansteuern. Es existiert bereits ein API-Key-Mechanismus für externe, nicht-interaktive Clients (X-Api-Key-Header, gebaut für die Rezept-App-Integration #98), der aktuell aber nur zwei Routen erlaubt (ApiKeyAuthenticationMiddleware-Allowlist).

Diese Story ist als Architektur-/Spec-Story gedacht: Vor der Implementierung müssen Architect, Backend und Security sich auf einen Vertrag einigen (Auth, Routing, Verhalten bei unbekanntem Barcode ohne UI, Netzwerkerreichbarkeit), bevor Code geschrieben wird.

Acceptance criteria:

  • Entscheidung + Dokumentation, ob der bestehende ScanPantryProductBarcodeCommand wiederverwendet wird oder ein dedizierter Command/Endpoint für Geräte-Clients eingeführt wird.
  • X-Api-Key-Route-Allowlist (ApiKeyAuthenticationMiddleware) um die gewählte Route erweitert, inkl. eigener Rate-Limit-Policy (analog zu recipe-integration).
  • Definiertes Verhalten für unbekannten Barcode ohne interaktive UI (z. B. automatische Übernahme des Open-Food-Facts-Namensvorschlags statt Rückfrage; klar dokumentierter Fallback wenn OFF keinen Namen liefert).
  • Geklärt, ob check-in/check-out-Richtung im Request explizit mitgegeben wird oder wie bei #171 über feste Steuer-Barcodes serverseitig umgeschaltet wird.
  • Netzwerk-Erreichbarkeit geklärt und dokumentiert (öffentliche HTTPS-Domain vs. separater LAN-Pfad) — aktuell gibt es keinen LAN-only-Zugriff, nur den same-origin Prod-Pfad hinter Traefik.
  • API-Key-Erzeugung für Geräte bleibt über die bestehende Settings-UI möglich (kein neues Geräte-Register nötig), sofern kein Scope-Modell eingeführt wird.
  • Minimaler Client-Beispielaufruf (curl oder kurzes Python/Shell-Snippet) dokumentiert, den ein Administrator auf dem Pi einsetzen kann.

Out of scope for this story:

  • Konkrete Pi-seitige Implementierung (Scanner-Treiber, Betriebssystem-Setup, systemd-Service) — das ist Infrastruktur beim Nutzer, nicht Teil dieses Repos.
  • Neues Scope-/Rollen-Modell für API-Keys, falls die Story ohne es auskommt (siehe offene Frage unten).
  • Kamera-basiertes Scannen — bleibt unverändert bei den bestehenden Modalen.

Open questions:

  • Reicht ein einzelner API-Key mit vollem Allowlist-Zugriff pro Pi, oder soll es ein Scope-Konzept geben, falls künftig mehrere Geräte/Integrationen hinzukommen?
  • Soll der Pi über die öffentliche Domain (einfach, aber Internetabhängigkeit für eine reine Heimnetz-Aktion) oder über einen separaten LAN-Pfad angesprochen werden (mehr Infrastrukturaufwand)?
## Story: Headless Raspberry-Pi-Scanner — Speisekammer per eigenständigem Gerät befüllen **As a** Nutzer, der einen Barcode-Scanner an einen headless Raspberry Pi anschließt (kein Display, kein Browser), **I want to** dass der Pi eigenständig über die Backend-API Produkte in der Speisekammer ein-/auschecken kann, **so that** ich Wareneingang/-ausgang direkt am Regal erfassen kann, ohne ein Gerät mit Browser und Kamera-Scan-Modal (#171) offen zu halten. ## Background Es existiert bereits ein browserbasierter Hardware-Scanner-Modus (#171, HID-Tastatur-Emulation auf einer dauerhaft offenen Seite) und ein bestehender Command `ScanPantryProductBarcodeCommand` (#94/#104), der Barcode -> Check-in/Check-out/Neuanlage abbildet. Für den Pi wird kein Browser-Frontend benötigt — der Pi soll den Command direkt über eine authentifizierte HTTP-API ansteuern. Es existiert bereits ein API-Key-Mechanismus für externe, nicht-interaktive Clients (`X-Api-Key`-Header, gebaut für die Rezept-App-Integration #98), der aktuell aber nur zwei Routen erlaubt (`ApiKeyAuthenticationMiddleware`-Allowlist). Diese Story ist als **Architektur-/Spec-Story** gedacht: Vor der Implementierung müssen Architect, Backend und Security sich auf einen Vertrag einigen (Auth, Routing, Verhalten bei unbekanntem Barcode ohne UI, Netzwerkerreichbarkeit), bevor Code geschrieben wird. **Acceptance criteria:** - [ ] Entscheidung + Dokumentation, ob der bestehende `ScanPantryProductBarcodeCommand` wiederverwendet wird oder ein dedizierter Command/Endpoint für Geräte-Clients eingeführt wird. - [ ] `X-Api-Key`-Route-Allowlist (`ApiKeyAuthenticationMiddleware`) um die gewählte Route erweitert, inkl. eigener Rate-Limit-Policy (analog zu `recipe-integration`). - [ ] Definiertes Verhalten für unbekannten Barcode ohne interaktive UI (z. B. automatische Übernahme des Open-Food-Facts-Namensvorschlags statt Rückfrage; klar dokumentierter Fallback wenn OFF keinen Namen liefert). - [ ] Geklärt, ob check-in/check-out-Richtung im Request explizit mitgegeben wird oder wie bei #171 über feste Steuer-Barcodes serverseitig umgeschaltet wird. - [ ] Netzwerk-Erreichbarkeit geklärt und dokumentiert (öffentliche HTTPS-Domain vs. separater LAN-Pfad) — aktuell gibt es keinen LAN-only-Zugriff, nur den same-origin Prod-Pfad hinter Traefik. - [ ] API-Key-Erzeugung für Geräte bleibt über die bestehende Settings-UI möglich (kein neues Geräte-Register nötig), sofern kein Scope-Modell eingeführt wird. - [ ] Minimaler Client-Beispielaufruf (curl oder kurzes Python/Shell-Snippet) dokumentiert, den ein Administrator auf dem Pi einsetzen kann. **Out of scope for this story:** - Konkrete Pi-seitige Implementierung (Scanner-Treiber, Betriebssystem-Setup, systemd-Service) — das ist Infrastruktur beim Nutzer, nicht Teil dieses Repos. - Neues Scope-/Rollen-Modell für API-Keys, falls die Story ohne es auskommt (siehe offene Frage unten). - Kamera-basiertes Scannen — bleibt unverändert bei den bestehenden Modalen. **Open questions:** - Reicht ein einzelner API-Key mit vollem Allowlist-Zugriff pro Pi, oder soll es ein Scope-Konzept geben, falls künftig mehrere Geräte/Integrationen hinzukommen? - Soll der Pi über die öffentliche Domain (einfach, aber Internetabhängigkeit für eine reine Heimnetz-Aktion) oder über einen separaten LAN-Pfad angesprochen werden (mehr Infrastrukturaufwand)?
lena commented 2026-09-30 09:40:27 +02:00
Author
Collaborator
Copy link

Blocked by: Freigabe durch den Menschen. Dieses Issue wird von der autonomen Schleife nicht aufgegriffen, bis das Label status/blocked wieder entfernt wird.

Blocked by: Freigabe durch den Menschen. Dieses Issue wird von der autonomen Schleife nicht aufgegriffen, bis das Label status/blocked wieder entfernt wird.
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
master
feature/in-app-notifications
feature/list-archiving
feature/filter-search
No results found.
Labels
Clear labels   
priority/could

   
priority/must

   
priority/should

   
priority/wont

   
status/blocked

   
status/claimed

   
status/done-migrated

   
type/bug

   
type/feature

   
type/infra

   
type/tech-debt
No labels
priority/could
priority/must
priority/should
priority/wont
status/blocked
status/claimed
status/done-migrated
type/bug
type/feature
type/infra
type/tech-debt
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
robert/todo#196
No description provided.