Halloween/halloween/instructions.md

# Modul `halloween/`

Hier liegt die erste Pi-WebUI. `run.py` im Projektstamm startet sie.

- `camera.py` liefert ein gemeinsames MJPEG-Bild für mehrere Betrachter.
  `--demo` erzeugt ausdrücklich gekennzeichnete Testbilder; echte Kamera
  läuft nur über Picamera2 auf dem Pi. Kamerafehler sichtbar melden.
- `controller.py` enthält bislang ausschließlich die simulierte
  Effekt-Zustandslogik. Stopp bleibt bis zum Rücksetzen bestehen; nach Start
  oder Rücksetzen muss erst der Bereich frei sein und dann ein neuer Trigger
  kommen. Beschädigte Einstellungen schalten auf `aus`.
- `web.py` bietet WebUI und API; `index.html` ist die Oberfläche. `run.py`
  bindet an `127.0.0.1`, Zugriff vom Laptop erfolgt per SSH-Tunnel.
  Für den vom Nutzer gewünschten direkten Heimnetzzugriff kann Uvicorn
  `halloween.web:create_app` als Factory auf `0.0.0.0:8000` starten;
  siehe `SOFTWARE.md`. `run.py` und systemd bleiben bei Loopback.
- `event_store.py` verwaltet `data/events.sqlite3`. Erfolgreiche manuelle
  Testauslösungen werden als Ereignisse gespeichert; Profile besitzen
  Kennungen und können Ereignissen zugeordnet werden. Profil-Löschen entfernt
  die Zuordnung, nicht das Ereignis. Auto-Profile können Merkmalsvektoren
  aufnehmen und verfallen 30 Tage nach letzter Sichtung. Start, stündlicher
  Lauf und Lesezugriffe räumen abgelaufene Profile auf; die Kamera liefert
  derzeit noch keine Merkmalsvektoren.
- Automatische Profilzuordnung per Kamera ist ein neuer Nutzerwunsch, aber
  noch nicht implementiert. Eine künftige Erkennung muss Unsicherheit und
  mögliche Fehlzuordnungen sichtbar machen und am echten Pi geprüft werden.
- Der Header `X-Halloween-UI` ist nur eine einfache Schranke für
  Schreibaufrufe, kein echter Zugangsschutz. Der direkte Heimnetzzugriff ist
  auf Nutzerwunsch für den aktuellen Test ohne Login vorgesehen; öffentliche
  Internetfreigabe ist nicht beauftragt. Zugangsschutz bleibt offen.
- Laufzeitdaten liegen standardmäßig unter `data/` und werden weder
  hochgeladen noch in Git aufgenommen.
- Echte GPIO-/Aktorsteuerung erst nach geklärter Mechanik, Versorgung,
  sicherem Stopp und den Hardwaretests aus `PLAN.md` ergänzen.

Bei Änderungen an Zustandsübergängen oder Endpunkten die zugehörigen Tests
unter `tests/` und die Bedienhinweise in `SOFTWARE.md` prüfen.

## Personendetektion

- `detection.py` wertet den gemeinsamen Kamerastream mit OpenCV DNN/NanoDet aus.
  Optionales Modell und OpenCV fehlen im Demo-Grundsetup bewusst. Kein Download
  im Server; geprüfte Modellmetadaten in `nanodet-model.json`.
- Nur neue, zeitlich gültige Frames auswerten. Hintergrundinferenz hält keine
  UI-/Zustandssperre; separater Watchdog sperrt aktivierte Automatik nach zwei
  Sekunden ohne gültiges Ergebnis. Fehler verlangen bewusstes Rücksetzen.
- Linienüberquerung nutzt bestätigte flüchtige Tracks und Fußpunkte, Richtung,
  endliches Segment und 3-%-Hysterese. Gruppen verlangen freien Bereich und
  Sperrzeit; Konfigurations-/Controllerwechsel verwerfen alte Beobachtungen.
- `/api/detection` liefert synchrones Bild und Rahmen; `/api/detection/config`
  speichert normierte Geometrie und Aktivierung unter `data/`. Erste Aktivierung
  ist bewusst, nach Neustart immer neue Bereichsfreigabe. UI zeichnet/editiert
  mit Canvas; keine Tracking-ID als Besucherprofil verwenden.
- Automatische Ereignisse tragen `person_line_crossing`, ohne Profilzuordnung.
  Die vorhandene Steuerung bleibt ausschließlich simuliert.