Halloween/PLAN.md

# Halloween – Arbeitsplan


## Aktueller Stand · 16. Oktober 2026

- Implementiert: getrennte Grab-/Kameraseiten, Farbpunktwahl, manuelle
  Servoeinrichtung, vier Endpunktkarten sowie numerische Bewegungs- und
  Einrichtgrenzen pro Achse. Bedienung in [SOFTWARE.md](SOFTWARE.md).
- Aktueller Zielverlustvertrag: Farbe dauerhaft gespeichert; Hardware-Sitzung
  wartet bei Punktverlust weiter. Optionale Suche nach 1,5 s, nach einem
  Durchlauf/60 s ohne Suchbewegung warten, bei zwei Funden weiter folgen.
  Stopp/Fehler/Neustart beenden weiterhin die Freigabe.
- Einrichtbereich standardmäßig 1100–1900 µs, im WebUI gestoppt innerhalb
  500–2500 µs einstellbar. Nachführgrenzen liegen darin. Startmitte je Achse = (Minimum + Maximum)/2.
  Technische Eingabehülle ist keine Bestätigung des mechanischen Fahrwegs.
- Zuletzt lokal geprüft: 104 Python-Tests (89 bestanden, 15 optionale
  übersprungen) und drei JS-Prüfungen. Optionale begrenzte Farbpunktsuche
  implementiert; echter Suchtest und Upload stehen noch aus.
- Pi-API am 16. Oktober: Kamera 15,0 Bilder/s, Nachführung inaktiv, Tempo noch
  80 µs/s. Aktuelle Grenzen PAN 588–2448, TILT 715–1620; nur gelesen.
  SSH-Batchzugang weiterhin abgelehnt; kein Deployment durch diese Prüfung.
- Farberkennung beschleunigt (JPEG-Reduktion, Pillow-Maske, 10-ms-Takt): lokal
  ca. 11,6 → 2,2 ms, gleiche Ergebnisse; Pi-Messung und Upload offen.
- Nutzer meldet Pendeln bei ruhigem Punkt (Tempo 800). Gegenmaßnahme: Verstärkung
  auf 600 µs/s je Bildanteil begrenzt; Wirkung am Pi noch zu prüfen.
- Nutzer meldet Zielverlust: Screenshot zeigt blauen Punkt auf bläulichem Papier
  (Papier Hue 152/S 80–100, Punkt 168/157); Toleranz 18 ließ das Papier als zweite
  Fläche mitzählen → kein Ziel. `locate()` nutzt jetzt Stufen streng→locker;
  lokal mit dem Screenshot und Regressionstest geprüft, Pi-Test offen.
- Nutzerstand: echtes Kameralivebild bestätigt, Aufbau laut Nutzer verdrahtet,
  separate Powerbank; Nutzer erprobt die Servoeinrichtung. Keine vollständig
  protokollierten realen Endpunkte oder bestätigte Fehlerabschaltung vorhanden.
- Offen: letzte Version auf den Pi übertragen, Achsrichtungen/Mittelstellung,
  Endpunkte, Versorgung und Stoppverhalten am Aufbau prüfen und dokumentieren.
- Breites responsives Layout lokal umgesetzt: Bild/Steuerung nebeneinander,
  Details aufklappbar. UI-Prüfungen siehe Abschnitt vom 16. Oktober unten.
- Anschlussplan Revision 14; Softwareänderungen erfordern keine neue Verdrahtung.

Die folgenden datierten Abschnitte dokumentieren auch frühere Zwischenstände.
Bei abweichenden Grenzen oder Bedienabläufen gilt der aktuelle Stand oben.

## Verdrahtungsplan vom 15. Oktober 2026

- Erledigt: dauerhafte Anschlussliste [VERDRAHTUNG.md](VERDRAHTUNG.md) und
  [Zeichnung](VERDRAHTUNG.svg) für Pi 5, Kamera und zwei Kameraservos angelegt.
  Kabelkennungen W01–W13; geplante Belegung CH0=PAN, CH1=TILT.
- Nutzerstand: Schwenkarm gekauft, Kameraadapter wird gedruckt; Nutzer nennt
  Amazon B07KPS9845 als Servos. Genaue Servodaten nicht unabhängig bestätigt.
- Dokumentarisch geprüft: Pi-/PCA9685-Verbindung gegen Herstellerreferenzen,
  getrennte Logik-/Servoversorgung und gemeinsame Masse beschrieben.
  Keine praktische Verdrahtungs- oder Bewegungsprüfung erfolgt.
- Per Nutzerfoto bestätigt und lokal abgelegt: PCA9685 mit 16 Kanälen;
  gelbe Reihe PWM, rote V+, schwarze GND; Plan um das Boardfoto ergänzt.
- Revision 4: große Pi-Pinübersicht [RASPI_PINS.svg](RASPI_PINS.svg) mit
  eindeutiger Draufsicht und vergrößerten ersten drei Pinpaaren ergänzt.
- Revision 3: W01 Grün, W02 Blau, W03 Braun, W04 Grau passend zu den
  Nutzerkabeln in Anschlussliste und Zeichnung dokumentiert.
- Offen: Klemmenpolung und Kanalposition am Board, Servotyp/Kabelfarben, geeignetes
  Servonetzteil und Polung, benutzter Kameraport, I²C-Adresse, Winkelgrenzen
  und Lasttest. Entwurf noch keine bestätigte Steckanleitung für D1.
- Offen: echte Kameraservosteuerung und sichere Start-/Fehlerabschaltung;
  Handservo, Relais/Motor und Beleuchtung später im selben Plan ergänzen.
- Pflege: nach jeder tatsächlichen Anschlussänderung Liste, Zeichnung und
  Prüfprotokoll gemeinsam aktualisieren; Kabel an beiden Enden beschriften.

## Ziel und aktueller Auftrag

Interaktives atmendes Grab für Halloween im Vorgarten der Schwester bauen.
Gewünscht sind ein kräftiger Schreckeffekt, Kamera, Weboberfläche und lokal
gespeicherte Bilder/Videoclips. Der Nutzer hat nun eine erste Pi-Software mit
Liveansicht und simuliertem Effektablauf beauftragt; das allgemeine
Uploadskript und die Blender-Konzeptvorschau wurden ebenfalls freigegeben.
Hardwarebau und Anschluss echter Aktoren folgen nach Klärung der Mechanik,
Versorgung und Sicherheit im Plan.

## Arbeitsweise

- Auf Deutsch, klar und knapp kommunizieren.
- `PLAN.md` als Arbeitsplan pflegen; erledigte Punkte, offene Entscheidungen
  und verifizierte Ergebnisse getrennt dokumentieren.
- Diese `AGENTS.md` nach dauerhaften Änderungen an Architektur, Betrieb,
  Sicherheit oder Werkzeugen im selben Arbeitsgang aktualisieren.
- Vor Änderungen in `halloween/`, `tools/`, `tests/` oder `preview/` die dortige
  `instructions.md` lesen und bei geänderten Verträgen oder Abläufen
  aktualisieren. Neue Modulordner erhalten eine eigene `instructions.md`.
- Vor Änderungen vorhandene Dateien und tatsächliche Hardware prüfen.
- Vorschläge und Annahmen ausdrücklich kennzeichnen; keine Kameramodelle,
  Motorleistungen, Anschlüsse, Netzwerkadressen oder Preise erfinden.
- Produktvorschläge und Kaufverweise ausschließlich für Reichelt oder
  Amazon; technische Herstellerunterlagen dürfen zur Prüfung dienen.
- Klein anfangen: einen vollständigen Effektablauf zuverlässig umsetzen,
  anschließend zusätzliche Effekte ergänzen.
- Dokumentation übersichtlich halten; diese Datei unter 400 Zeilen halten.
- Im lokalen Git Code, Planung und bearbeitbare Blender-Szenen versionieren;
  Renderdateien, Referenzclip, `.venv` und `data/` bleiben unversioniert.
- Gitea-Ziel für dieses Projekt: `https://gitea.fritz.box/marcinator_2/Halloween`;
  Branch `main`, Repository zunächst privat. HTTPS-Zertifikatsprüfung aktiv
  halten; das öffentliche Zertifikat nur lokal in Git konfigurieren.
  Zugangsdaten gehören nicht in Git oder Chat.

## Hardware und Architektur

- Vorhanden laut Nutzer: Raspberry Pis 3–5; Pi 5 auf Nutzerfoto bestätigt,
  RAM vermutlich 8 GB laut Nutzer, noch nicht am Gerät geprüft;
  außerdem „2mini“ (genaue Geräte unbekannt), Camera Module 3 NoIR
  (Beschriftung auf Nutzerfoto bestätigt), eventuell Display,
  LEDs, Servos und Lötwerkzeug. 3D-Drucker laut Nutzer vorhanden;
  Modell, Bauraum und Druckmaterial noch unbekannt.
  PCA9685-Modul mit 16 Kanälen laut Nutzer vorhanden; konkrete Platine
  und Anschlüsse noch nicht geprüft, kein Neukauf nötig.
  Buchse/Buchse-Steuerleitungen laut Nutzer reichlich vorhanden;
  kein Neukauf nötig, nicht für Servolast verwenden.
  Weitere Teile dürfen vorgeschlagen werden.
  Weiteres Nutzerfoto bestätigt einen 28BYJ-48-Schrittmotor mit 5-V-DC-
  Beschriftung und OPITEC-Werkpackung 224105 mit Getriebeteilen.
  Vollständigkeit, Treiber, Funktion und Lastfestigkeit noch ungeprüft.
  OPITEC nennt für Werkpackung 224105 Motor R20 mit 1,5–4,5 V und
  ca. 350–500 mA; Drehmoment fehlt. Fotografierter Einzelmotor nicht
  unabhängig als R20 bestätigt; 6-V-Servoversorgung nicht direkt anschließen.
- Vorgeschlagene Aufteilung: Pi 5 für Kamera/WebUI/Ereignisse und Pi 3/4
  für Effektsteuerung. Noch keine verbindliche Hardwareentscheidung.
- Für die NoIR-Kamera IR-Beleuchtung bei Dunkelheit und ein passendes
  Standard-auf-Mini-Kamerakabel für Pi 5 einplanen; vorhandenes Kabel prüfen.
- GPIOs steuern geeignete Treiber; Motoren, Servos und größere LED-Lasten
  erhalten eine passend dimensionierte Versorgung.
- Aktueller Nutzerumfang: zwei Antriebe, einer für die Hand und einer
  für die Atemrotation. Nutzer sieht nun 230 V mit Relais für Rotation
  vor; CHANCS 60KTYZ (Amazon B07WXFWYBZ, 220–240 V, ca. 2,5 U/min)
  ist nun ausgewählt, Kauf noch nicht bestätigt. Waveshare RPI RELAIS 3CH
  ist im aktuellen Warenkorb; Motorlastfreigabe noch offen. Versorgungsleitung
  laut Nutzer vorhanden; Eignung vor Anschluss prüfen. Für die
  Hand ist der Miuzei-35kg-/270°-Servo der aktuelle Kandidat, mit
  separater stabilisierter 6-V-/5-A-Versorgung und Delock 65485 als
  Anschlussadapter. Langsames Hervorkommen ist ausdrücklich akzeptiert.
  Hub, Last, PWM-Steuerung und sichere Bewegungsgrenzen noch festlegen.
  Motoren nicht gekauft oder praktisch geprüft.
  GM40,5 625 12V / E192.12.625 war die vorherige Reserveoption für
  Rotation; GM27 90 12V der frühere Kandidat für direkten Handhub.
  Beide sind historische Vorschläge, keine verbindliche Auswahl.
  Separate Pi-5-Versorgung ist der aktuelle Vorschlag;
  Netzteilreserve anhand beider Anlauf-/Blockierströme prüfen.
- Atemrotation laut Nutzer: ca. 1,5 m lange waagerechte Stange mit zwei
  leeren Kunststoffflaschen; vorgesehen ist Rotation um die Längsachse.
  Abdeckungs- und Lagerwiderstand mitmessen, keine schwere Hubfläche
  als Last voraussetzen.
  Stangenlänge ist dabei kein Drehmomenthebel; wirksamen Abstand zur
  Drehachse und Last über eine ganze Umdrehung prüfen. Keine
  abgeschlossene Dimensionierung aus den früheren Kandidaten ableiten.
- Mechanik erst nach Klärung von Abmessungen, Gewicht, Hub und Bewegungsraum
  auswählen. Atembewegung und kurzer Schreckimpuls getrennt bewerten.
- Neue Handidee: Gummizug für schnellen Hub, langsamer Motor zum
  Rückspannen. Verriegelung mit vorab abgewickelter Schnurreserve oder
  schaltbarer Kupplung ist noch ein Vorschlag. Ein zusätzlicher
  Entriegelungsaktor wäre beim Riegelvorschlag nötig; nicht ausgewählt.
  Motor muss die Spannkraft aufbringen; Gummizug ersetzt diese Last nicht.
- Elektrischer Linearantrieb ist eine zusätzliche Handoption; direktes
  Ausfahren und langsames Spannen eines getrennten Federhubs unterscheiden.
  Selbsthemmender Spindelantrieb gibt einen schnellen Federhub nicht
  automatisch frei. Hand bleibt befestigt, geführt und im Grab begrenzt.
- Weitere Handoption auf Nutzerwunsch: Schwenkhebel nach einer
  Industrieservo-Videovorlage. Günstiger Kandidat für direkten Handhub
  ist JOY-IT COM-MOTOR02 (Reichelt GRABIT SERVO); noch nicht ausgewählt
  oder getestet. Maximales Servomoment und Leerlaufgeschwindigkeit
  sind keine zugesicherte kombinierte Lastleistung. Eigenes passendes
  Servonetzteil und PWM-Steuerung vorsehen; keine Geschossfunktion.
- Neuer stärkerer Handkandidat vom Nutzer: Amazon Miuzei 35kg/270°,
  ASIN B0CBBS6KX6. Anbieterwerte/Spitzenstrom und reale Last prüfen;
  PWM-Winkelzuordnung und Bewegungsgrenzen für 270° auslegen.
  Versorgungsvorschlag: getrenntes stabilisiertes 6-V-Netzteil mit
  mindestens 5 A, Anlaufverhalten noch prüfen. Pi behält eigenes Netzteil;
  bei nicht isolierter Steuerung gemeinsame Masse, Versorgungsplus getrennt.
  ZHITING DS3235 ist laut Nutzer nicht lieferbar, SAIA-230-V-Kandidat
  zu teuer; beide für die aktuelle Auswahl zurückgestellt.
  Langsamen direkten Hub zuerst bewerten;
  kein schneller Federimpuls zwingend erforderlich.
- Nutzer weist auf Verheddern abgewickelter Schnur hin. Die Variante mit
  Schnurreserve ist erst nach Auslegung einer geführten Aufnahme sinnvoll.
  Kurvenscheibe mit Hebel als schnurlose Alternative prüfen;
  recherchierte Druck-/CAD-Vorlagen sind noch keine passende Handmechanik.

## Betriebsregeln

- Bewegung bleibt im Grab und außerhalb des Besucherwegs; Quetschstellen
  abdecken. Leichte bewegte Bauteile und mechanische Anschläge vorsehen.
- Elektronik für Außeneinsatz geschützt planen; Kleinspannung am Grab
  bleibt der bisherige Vorschlag. Für die neue 230-V-Relaisalternative
  Netzspannungsseite geschlossen, berührungsgeschützt und für Außeneinsatz
  auslegen; durch eine Elektrofachkraft aufbauen/prüfen lassen.
  Pi-kompatible Steuerschnittstelle, geeignete Motorlastkontakte,
  Zugentlastung und passende Stromversorgung vorsehen.
- Bei Start, Verbindungsverlust oder Fehler keine neue Schrecksequenz
  auslösen; definierte sichere Zustände und lokalen Stopp vorsehen.
- Bei Gummizugmechanik stromlos haltende mechanische Verriegelung und
  kontrollierte Entspannung für Wartung vorsehen. Motor-Stopp nimmt die
  gespeicherte Energie nicht weg und hält einen entriegelten Hub nicht
  sofort an; Führung, Befestigung und gedämpfte Anschläge begrenzen ihn.
- Sperrzeit und belegten Auslösebereich berücksichtigen.
- Kinder-/Sanftmodus anbieten. Kamerabasierte Größenhinweise sind unsicher
  und dürfen nicht als zuverlässige Altersbestimmung gelten.
- Nutzerwunsch: „voller Schreck“ ist der anfängliche Standard und wird nach
  neuem gültigem Trigger automatisch ausgelöst, ohne Einzelfreigabe.
  Modi sind in der WebUI umstellbar; eine gewählte Einstellung soll einen
  normalen Neustart überdauern. Nach Start erst freien Auslösebereich
  abwarten; nach Stopp oder Fehler bewusst zurücksetzen. Kamerahinweise
  gelten nicht als verlässliche Altersentscheidung; automatische Reaktion
  auf Hinweise zu kleinen Besuchern vor Implementierung abstimmen.

## Kamera, Aufnahmen und Zugriff

- Personenerkennung für Auslösung und Profilzuordnung als getrennte Schritte
  behandeln; unsichere Zuordnungen keinem Profil zuschreiben.
- Neuer Nutzerwunsch: Personenprofile und später automatische Zuordnung
  wiederkehrender Besucher per Kamera. Aktuell ist nur die lokale Datenbank
  mit manueller Zuordnung umgesetzt; automatische Erkennung nicht als
  funktionsfähig ausgeben, bevor Verfahren und echte Kamera geprüft sind.
- Automatisch erzeugte Profile samt Merkmalsvektoren 30 Tage nach der letzten
  Sichtung löschen. Manuell angelegte Profile bleiben bis zur Löschung bestehen.
- Clips mit Zeit, Vorschaubild und Ereignistyp zum manuellen Prüfen anbieten.
- Neu beauftragt: bei jeder akzeptierten automatischen Auslösung ein JPEG
  des grünen Bereichs aus dem Trigger-Frame lokal unter data/event-images/
  speichern; Vorschau/Ansehen und bestätigtes Bildlöschen in der Ereignisliste.
  Nutzerwahl: bis manuelle Löschung behalten, keine automatische Bilderfrist.
  Ereignis/Profilzuordnung bleiben beim Bildlöschen; Upload-Sicherungen separat.
  Keine Bilder bei manuellen Testauslösungen oder nachträglich für alte Ereignisse.
  Lokale synthetische Tests bestanden; echter Pi-Speicher-/Anzeigetest noch offen.
- Aufnahmebereich auf den vorgesehenen privaten Bereich begrenzen;
  Maskierung, Aufbewahrung und Löschfrist vor Umsetzung festlegen.
- Tonwiedergabe und Tonaufnahme unterscheiden; Tonaufnahme standardmäßig aus.
- WebUI zunächst nur im lokalen Netz; keine öffentliche Freigabe ohne
  ausdrücklichen Auftrag. Zugangsschutz einplanen.

## Erste Softwareversion

- `run.py` startet die FastAPI-WebUI nur auf `127.0.0.1`; Laptop-Zugriff
  erfolgt per SSH-Tunnel. `--demo` kennzeichnet ein synthetisches Bild.
- Nutzer wünscht nun direkten Zugriff im Heimnetz. Manueller Start über
  Uvicorn mit `--factory --host 0.0.0.0` ist in `SOFTWARE.md` beschrieben.
  Aktuell ohne Login; keine öffentliche Internetfreigabe beauftragt.
  `run.py` bleibt bei Loopback; systemd nutzt die beim Upload gewählte
  Bind-Adresse, initial Loopback.
- Picamera2 liefert das MJPEG-Livebild; auf dem Entwicklungsrechner wurde
  nur der Demo-Feed geprüft, nicht die echte Pi-Kamera.
- Moduswahl, simulierte Sequenz und lokale NanoDet-Personendetektion mit
  gerichteter Linienüberquerung sind implementiert. Erkennung benötigt optional
  OpenCV und ausdrücklich installiertes SHA-256-geprüftes Modell unter data/.
  Am Pi fertige Systempakete python3-opencv/python3-numpy in einer Umgebung
  mit --system-site-packages verwenden; OpenCV mindestens 4.10 prüfen.
  requirements-detection.txt erlaubt nur Wheels, keinen impliziten Quellbuild.
  Erkennung startet deaktiviert; Linie/Bereich/Richtung in der UI einstellen.
  Gruppen verlangen neuen freien Bereich und Sperrzeit; Erkennungsfehler bei
  aktivierter Automatik sperren bis zum bewussten Rücksetzen. Frames und
  Personenrahmen werden synchron angezeigt; Tracks sind flüchtig, keine Profile.
  Echte Personenauslösung am Pi, GPIO und Clip-Speicherung sind noch offen.
- Zusätzlicher Testmodus „Bewegung in Pfeilrichtung“ ist implementiert:
  Optical Flow im gewählten Bereich, kein Personenmodell/keine Überquerung nötig.
  Auswahl und Aktivierung gespeichert; Personenerkennung bleibt der Standard.
  Zwei gerichtete Beobachtungen bestätigen; zwei Sekunden Bildruhe und zehn
  Sekunden Sperrzeit. Bildruhe ist keine Personenfreiheit. Nur Simulation,
  separates motion_direction_test-Ereignis ohne Profil, mit lokalem Auslösebild.
  Nutzer-Screenshot bestätigt Testmodus mit Pi-Bild und 5 Auswertungen/s,
  aber bisher keine Auslösung. Kleine/langsame Nahbereichbewegung war im
  synthetischen Regressionstest zu schwach für die alte Schwelle; korrigiert.
  UI zeigt Bildänderung/Richtungsbestätigung und automatische Bereitschaft
  getrennt von manuellen Tests. Echte Auslösung am Pi bleibt zu prüfen.
- SQLite speichert Testereignisse und Profilkennungen unter `data/`;
  automatische Kamera-Zuordnung fehlt noch. Die Datenbank kann bereits
  Merkmalsvektoren für Auto-Profile mit 30-Tage-Frist speichern; die Kamera
  schreibt derzeit keine solchen Datensätze.
- Laufzeitdaten unter `data/` nicht mit dem Uploadskript überschreiben.
- Nutzer meldet am 14. Oktober 2026 die Pi-Kamera als angeschlossen;
  Ausgabe von `rpicam-hello --list-cameras` bestätigt `imx708_noir`
  mit 4608×2592 Pixeln. Nutzer bestätigt anschließend echtes Livebild
  in der WebUI nach Einrichtung von Picamera2.
- Nutzer-Screenshot vom 14. Oktober 2026 bestätigt SSH-Zugang als
  `marcinator_2` auf `raspi5wlan.local` und Projektdateien unter `~/halloween`.
  Standgleichheit, Python-Einrichtung und laufende WebUI noch prüfen.
- Versionierter Upload richtet systemd-Autostart bei jedem `--apply` ein.
  Neue Version samt eigener `.venv` unter `releases/`, atomarer `current`-Link,
  gemeinsames `data/` über `HALLOWEEN_STATE_DIR`. Nach Dienststopp Daten sichern;
  bei Start-/HTTP-Fehlern Code, Unit und Daten zurücksetzen. `--web-host` wählt
  Loopback oder ausdrücklich Heimnetz; gespeicherte Wahl bleibt erhalten.
  Upload teilt eine SSH-Verbindung über privaten temporären Socket; ohne
  Schlüssel typischerweise einmal SSH- und einmal sudo-Passwort. Aufräumen bei
  Erfolg/Fehler, keine neue Passwortabfrage durch Slave-Verbindungen.
  Update mit genau einem sudo-Aufruf für Umschaltung und Rückfall; Paketsetup
  unprivilegiert, Python-/Unitprüfung per runuser als Pi-Benutzer. Passwort und
  sudoers/Zeitstempel bleiben unverändert; echte Passwortabfrage noch prüfen.
  Alte Versionen/Sicherungen nicht automatisch löschen. Lokale Simulationstests
  bestanden; Nutzer bestätigt erfolgreichen Upload. Autostart nach tatsächlichem
  Reboot und automatischer Rückfall am Gerät noch ungeprüft.

## Prüfung

- Softwareprüfungen, Hardwaretests und Außentests getrennt berichten.
- Erst ohne angeschlossene Aktoren simulieren, dann einzelne Aktoren testen,
  anschließend Gesamtablauf und Fehlerfälle prüfen.
- Kamera bei tatsächlicher Dunkelheit, Beleuchtung und Verkleidungen testen.
- Sicheren Zustand bei Netzwerkausfall, Neustart und Stopp verifizieren.
- Dokumentationsänderungen erfordern keine zusätzlichen Softwaretests.

## Fiktive Videoeinblendungen

Scan-/Datenbankdarstellungen in Vorschauvideos verwenden erfundene
Avatare und IDs, mit sichtbarer Simulationskennzeichnung. Externe
Bildsequenzen eines Blender-Schnittprojekts bei Weitergabe mitnehmen.

- Nutzer-Ausgaben bestätigen Raspbian GNU/Linux 13 (trixie), Python 3.13.5
  und Kernelarchitektur aarch64; Paket-/Python-Bitness noch nicht geprüft.
  Nach Netzteilwechsel SSH wieder erreichbar, get_throttled=0x0;
  keine Diagnose des vorherigen Ausfalls daraus ableiten. Kein OpenCV-Build
  in der übermittelten Prozessliste; Dell-Netzteilwerte bleiben ungeprüft.


### Pi-Installation nach unterbrochenem OpenCV-Quellbuild

- Nutzer bestätigt Raspbian 13/trixie, Python 3.13.5, Kernel aarch64 und
  `get_throttled=0x0`. Paketarchitektur ist damit noch nicht nachgewiesen.
- SSH nach Netzteilwechsel wieder möglich; Prozessliste zeigt nur PipeWire,
  keinen laufenden pip-/Compiler-Build. Ausfallursache bleibt ungeklärt.
- Pi-Anleitung auf fertige Systempakete umgestellt; pip-Requirements erlauben
  nur Wheels und brechen andernfalls ab. Kein weiterer Quellbuild vorgesehen.
- Offen: installierte OpenCV-Version/-Herkunft und echte Modellinferenz am Pi
  prüfen. Dell-Netzteil laut Nutzer passend, Ausgangsprofile nicht verifiziert.

## Updateauftrag vom 14. Oktober 2026

- Erledigt: Versionsordner, eigene Python-Umgebung, gemeinsames data/,
  systemd-Neustart und Autostart, HTTP-Prüfung und automatischer Rückfall
  einschließlich Datensicherung; Anleitung in UPLOAD.md.
- Lokal verifiziert: simulierte Dienst-/Installationsfehler und erfolgreiche
  Umschaltung, Erhalt von Einstellungen/Daten und Rückfall zur Altinstallation.
- Nutzer bestätigt: bisheriger Updateaufruf hat funktioniert.
- Offen am Pi: tatsächlichen Neustart/Autostart und Rückfall testen;
  keine Hardwareprüfung durch den Agenten erfolgt.
- Betriebsgrenze: keine automatische Wiederherstellung nach Stromverlust während
  des Updates; Speicherbedarf und Aufräumen alter Sicherungen manuell prüfen.

## Nahbereichstest vom 14. Oktober 2026

- Erledigt: auswählbarer Bewegungs-Test in Pfeilrichtung ohne Personenmodell;
  keine Überquerung nötig, getrennte Testereignisse, gespeicherte Auswahl.
- Lokal verifiziert: synthetische Richtungs-/Störungs-/Sperrtests, modellfreier
  Worker und vorhandene Softwaretests. Browser-Demo: Auswahl, Speicherung und
  Wiederherstellung nach Neuladen in UI-Struktur; Screenshot nicht verfügbar.
- Offen: neue Version auf Pi übertragen und tatsächliche Nahbereichbewegung
  kalibrieren/prüfen. Bewegungstest ist kein Nachweis für Personenauslösung
  oder menschenfreie Bereiche im späteren Gartenbetrieb.

### Rückmeldung: Nahbereich löst nicht aus

- Nutzer-Screenshot: Pi-Livebild, Testmodus aktiviert, 5 Auswertungen/s und
  Automatik bereit. Nutzer bewegt Hand/Kopf nach rechts passend zum Bildpfeil;
  keine Auslösung gemeldet. Manuelles Bereich-frei beeinflusste nur die separate
  Controlleranzeige, nicht die automatische Freigabe.
- Lokal reproduziert: kleiner/langsamer Stimulus im großen Bereich scheitert an
  alter Bildänderungsschwelle. Schwellen reduziert, Richtung und Doppelbestätigung
  beibehalten. Derselbe Stimulus löst nun ohne manuelles Freigeben aus; Gegenrichtung
  wird verworfen. Diagnoserückmeldung und Automatikstatus in der UI ergänzt.
- Offen am Pi: erneuter Upload und tatsächlicher Nahbereichstest. Synthetische
  Tests und JS-Rendererprüfung sind keine Bestätigung einer echten Auslösung.

## Automatische Auslösebilder vom 14. Oktober 2026

- Erledigt: lokal gespeichertes JPEG pro automatischem akzeptierten Trigger,
  auf grünen Bereich begrenzt; Bildvorschau/Ansehen/Löschen in Ereignisliste.
  Aufbewahrung laut Nutzer bis manueller Löschung. Ereignis/Profil bleiben.
- Lokal geprüft: identischer Trigger-Frame, Bereichsbeschnitt, Dateirechte,
  Persistenz, Migration, Fehlerbereinigung, Bild-API und manuelles Bildlöschen
  ausschließlich mit synthetischen Daten.
- Offen: neue Version hochladen, echte Auslösung und Bildvorschau am Pi prüfen.
  Bestehende Ereignisse bleiben bildlos; Sicherungsbilder gesondert verwalten.
- Liveprüfung vor diesem Auftrag: Pi-Ereignisliste zeigte drei automatische
  Bewegungs-Testauslösungen (13:07:54, 13:08:26, 13:08:53) ohne Bilder; daraus
  folgt kein Nachweis für neue Bildspeicherung oder Erkennungsqualität.

## Einmalige sudo-Abfrage beim Update

- Erledigt: ein sudo-Aufruf nach Vorbereitung der Python-Umgebung. Umschaltung,
  systemd und Rückfall laufen im selben privilegierten Teil; Python und
  Unit-Renderer als Pi-Benutzer über runuser. Besitzer von Link/Konfiguration/
  neuen Sicherungen bleiben beim Pi-Benutzer. Keine Passwortablage/sudoersänderung.
- Lokal verifiziert: 12 Update-Simulationstests einschließlich Ablehnung jedes
  zweiten sudo-Aufrufs, erfolgreichem Rückfall und abgelehnter sudo-Anmeldung.
- Offen am Pi: aktualisierten Upload ausführen und tatsächliche Anzahl der
  Passwortabfragen sowie Dienst/Python-Benutzer prüfen; kein echter PAM-Test.

## Mehrfache Passwortabfragen: gemeinsame SSH-Verbindung

- Nutzer meldet weiterhin 4–5 Passwortabfragen. Skriptprüfung zeigt zusätzlich
  zum einzigen sudo-Aufruf bislang drei separate SSH-Verbindungen. Die genaue
  Beschriftung der gemeldeten Dialoge wurde nicht beobachtet.
- Erledigt: einmalige SSH-Master-Verbindung mit privatem temporärem Socket,
  gemeinsame Nutzung durch mkdir/rsync/Aktivierung, BatchMode für Slaves und
  Aufräumen bei Erfolg/Fehler. Ohne Schlüssel sind SSH und sudo zwei Anmeldungen.
- Lokal verifiziert: 15 Update-/Transport-Simulationstests bestanden, keine
  Verbindung/Socketerzeugung bei Vorschau. Echte Passwortanzahl am Pi noch offen.


## Farbpunktnachführung vom 15. Oktober 2026

- Nutzerauftrag: Kameramodus zum Verfolgen eines Fingers beziehungsweise farbigen
  Punkts, eventuell mit Beispielfoto. Umgesetzt als Farbpunkt-Test, keine
  Finger-/Handerkennung und kein trainiertes Modell.
- Erledigt: Rot/Grün oder Farbwahl im flüchtigen Kamerafoto; eigener synchroner
  Bildbereich, Vorschau ohne I²C; bewusst gestartete CH0/CH1-Ausgabe mit enger
  Pulsbegrenzung, Totzone, Richtungsumkehr und begrenzter Geschwindigkeit.
- Erledigt: kein gleichzeitiger Automatikbetrieb; Controller bleibt gestoppt.
  Stop/Reset, Heartbeatverlust, Bild-/Auswertungsfehler und Marker-Verlust
  beenden Hardware-Sitzung; Konfiguration bleibt erhalten, Aktivierung nicht.
- Nutzer meldet Verdrahtung fertig; derzeit separate Powerbank, die bereits
  zwei Servos betrieben hat. Modell/Stromreserve und Leitungsstärke offen.
- Verifiziert lokal: synthetische Bild-/Regelungs-/Fehler-/API-Tests und
  künstlicher I²C-Bus; Browserdemo prüft Farbwahl, Vorschau, Stopp, Beispielfoto.
  Vollsuite: 84 Tests, davon 69 bestanden und 15 wegen fehlendem optionalem
  OpenCV/Modell übersprungen; beide bisherigen JS-UI-Tests und JS-Syntaxprüfung
  bestanden. Keine echte Bewegung, kein Upload am Pi erfolgt.
- Offen am Pi: Upload, I²C/Berechtigung/Adresse, entkoppelte 1500-µs-Zentrierung,
  Drehrichtungen und Grenzen, Stromreserve, Nachführung mit echter NoIR-Kamera.
- Offen: unabhängige OE-/Hardwareabschaltung. PWM-Aus bei funktionierendem I²C
  ist keine Stromtrennung und schützt nicht vor hartem Prozess-/Pi-Ausfall.


## Manueller Kameraeinrichtmodus vom 15. Oktober 2026

- Nutzerauftrag: Endpunkte ermitteln, insbesondere Neigung manuell stoppen;
  keine Endschalter vorhanden. Keine automatische Fahrt gegen Anschläge umgesetzt.
- Erledigt: eigene Einrichtsitzung, große Richtungstasten mit Haltefunktion,
  sichtbare Sollwerte und gespeicherte Grenzen; Richtungsumkehr konsistent.
  40 µs/s, Bewegungslease 0,35 s, Sequenzen gegen verspätete Befehle; Loslassen
  hält Position, Kamerastopp beendet PWM. Grenzspeicherung mit 10 µs Innenabstand.
- Lokal geprüft: synthetische Hardware-/Lease-/Persistenztests; Browserdemo
  mit gedrückter Taste, anschließend unveränderter Sollposition und Speicherung.
  Keine echte Bewegung, kein Upload und keine Bestätigung realer Endpunkte.
- Offen am Pi: Mittelstellung, Drehrichtungen, sichere mechanische Grenzen und
  Loslassen/Stopp bei echtem Aufbau prüfen. Beide Achsen vor Anschlag stoppen.
- Abschlussprüfung lokal: 87 Python-Tests, davon 72 bestanden, 15 optionale
  OpenCV-/Modelltests übersprungen. Bisherige JS-Tests und JS-Syntaxprüfung bestanden.


## Sichtprüfung der Verkabelung vom 15. Oktober 2026

- Nutzerfoto ohne angeschlossene Servoversorgung als PCA9685_VERKABELT_FOTO.jpg
  abgelegt und in VERDRAHTUNG.md Revision 7 verlinkt. Sichtbare Servosteckrichtung
  und Anordnung der Steuerstecker erscheinen passend zum Plan.
- Nicht bestätigt: Pi-seitige Pins (nicht vollständig im Foto), genaue
  Kanalnummern/Zuordnung zu PAN/TILT, elektrische Durchgängigkeit,
  Versorgungspolung und echte Funktion. Kein Einschalt- oder Bewegungstest.

- Ergänzendes Pi-Foto RASPI_VERKABELT_FOTO.jpg in VERDRAHTUNG.md Revision 8:
  sichtbare Anordnung passt zu Grün=1, Blau=3, W03=5 (violett wirkend), Grau=6.
  Frühere Lücke der Pi-Sichtprüfung ergänzt; keine elektrische Messung oder
  Bestätigung der Versorgungspolung/Servofunktion daraus ableiten.


## Getrennte Grab und Kameraseiten vom 15. Oktober 2026

- Erledigt: `/` und `/grab` mit Grabsteuerung, Ereignissen und Profilen;
  `/kamera` mit Livebild, Farbpunkt und Endpunkteinrichtung. Jede Seite hat
  eigene Bedienelemente und Poller; gemeinsamer Kameraproduzent bleibt erhalten.
- Erledigt: Vorschau verändert den Grabzustand nicht und darf parallel zur
  Automatik laufen. Nur echte Kamerabewegung bleibt bei aktiver Automatik
  gesperrt. Keine automatische Umschaltung gespeicherter Einstellungen.
- Erledigt: Grab-Stopp/-Reset wirkt nur auf Grab; Kamerastopp nur auf Kamera.
  Explizites „Alles stoppen“ bleibt auf beiden Seiten, alte globale APIs bleiben
  für bestehende Clients erhalten. Livebild auf Kameraseite auch ohne Sitzung.
- Lokal geprüft: Seiteninhalt/Pollertrennung, unabhängige API-Aktionen,
  Hardware-Interlock und globale Abschaltung mit künstlichem Treiber.
- Offen am Pi: Upload, Navigation und getrennte Bedienung am Gerät prüfen;
  gemeinsame Kamera erfordert nach Bewegung neue Bereichs-/Linienkontrolle.
- Abschluss lokal: 89 Python-Tests, 74 bestanden, 15 optionale OpenCV-/
  Modelltests übersprungen; beide bestehenden JS-UI-Tests und Syntaxprüfung
  beider Seiten bestanden. Beide Seiten und Navigation im Demo-Browser
  visuell geprüft; sofortiges Kameralivebild bestätigt. Kein Pi-Upload erfolgt.


## Verständliche Endpunktspeicherung vom 15. Oktober 2026

- Befund aus Nutzer-Screenshot: eingegebene 500/2500 µs widersprechen den
  gespeicherten 1400–1600 µs. Oberer Speichern-Knopf wird während aktiver
  Einrichtung abgelehnt; Fehleranzeige war vom Bedienort entfernt.
- Erledigt: editierbare Grenzfelder durch vier Richtungs-Karten mit tatsächlichem
  Serverwert, Kandidat (10 µs nach innen) und eindeutigem Speicherknopf ersetzt.
  Unpassende Seite/Mittelstellung sperrt den Knopf mit Hinweis. Bestätigung und
  Fehler im Einrichtbereich; gespeicherte Werte bleiben dauerhaft sichtbar.
- Erledigt: Start speichert keine Formularwerte; Farb-/Richtungsspeicherung
  übernimmt keine Grenzwerte aus alten Feldern. Aktive Einstellungen/Startknöpfe
  gesperrt. Veraltete Statusantworten nach Speicherung verworfen.
- Damaliger Zwischenstand: feste Testgrenzen 1100–1900 µs; durch den
  späteren einstellbaren Einrichtbereich unten abgelöst.
- Lokal geprüft: Endpoint-UI-Regressionen und Backendtests; Browserdemo mit
  Links-Bewegung und bestätigtem Speichern auf 1460 µs. Dies ist ein künstlicher
  Testwert, keine Endposition der echten Halterung. Upload und Pi-Prüfung offen.
- Abschluss: 89 Python-Tests, davon 74 bestanden und 15 optionale OpenCV-/
  Modelltests übersprungen. Drei JS-UI-Prüfungen inklusive neuer Endpunkt-
  Regression und JS-Syntaxprüfung bestanden. Zweispaltiges Kartenlayout und
  persistente Werte nach Demo-Neustart im Browser geprüft.


## Manuelle Grenzfelder wiederhergestellt am 15. Oktober 2026

- Auf Nutzerwunsch: sichtbare PAN-/TILT-Min-/Max-Felder zusätzlich zu den
  Endpunktkarten. Eigener Speichern-/Verwerfen-Knopf; nur gestoppt editierbar.
- Entwurf und gespeicherte Serverwerte getrennt anzeigen, ungespeicherte Werte
  nicht durch Polling überschreiben; Start verlangt Speichern oder Verwerfen.
  Separate Speicherung erhält Farbe/Drehrichtung. Damals noch feste Grenzen
  1100–1900 µs; inzwischen durch den einstellbaren Einrichtbereich abgelöst.
- Lokale JS-Regression für korrekte Werte, getrennte Speicherung, ungültige
  Grenzen und Startblockade ergänzt. Echte Pi-Prüfung nach Upload offen.


## Einstellbarer Einrichtbereich am 15. Oktober 2026

- Nutzerkorrektur: feste 1100–1900 µs reichen zum Ermitteln realer Endpunkte
  möglicherweise nicht. Jetzt pro Achse separate Einricht-Min-/Max-Felder,
  zusammen mit Nachführgrenzen nur gestoppt explizit speichern/verwerfen.
- Jog begrenzt auf gespeicherten Einrichtbereich, Nachführung auf Endpunkte.
  Technische Hülle 500–2500 µs, keine Aussage über mechanisch erlaubte Winkel.
  Bestehende Konfigurationen behalten 1100–1900 und ihre bisherigen Endpunkte.
- Lokal geprüft: Migration, Persistenz, aktive Änderung abgelehnt, erweitertes
  Jog/Begrenzen und Endpunktspeichern, getrennte Followgrenzen; JS-Formtests.
- Offen: Upload, Anzeige und beaufsichtigtes Einrichten am echten Pi.

- Abschlussprüfung lokal: 90 Python-Tests (75 bestanden, 15 optionale übersprungen),
  drei JS-Prüfungen bestanden; Browserdemo bestätigt erweiterten Einrichtwert
  und Erhalt nach Neuladen sowie Verwerfen. Keine echte Servobewegung getestet.


## Dokumentationsabgleich am 15. Oktober 2026

- README, Bedienanleitung, Uploadhinweise, Anschlussplan und Projekt-/Modulregeln
  auf getrennte Seiten und einstellbare Einrichtgrenzen abgeglichen.
- Frühere feste Grenzen im Verlauf als abgelöste Zwischenstände gekennzeichnet.
  Lokale Prüfung, Nutzerbeobachtungen und offene Pi-Tests getrennt dargestellt.
- Nur Dokumentation geändert. Verifiziert: 24 lokale Links einschließlich
  Überschriftenzielen, Revision 12 in Plan/Zeichnung, gültige SVG-Dateien,
  AGENTS.md unter 400 Zeilen und git diff --check ohne Fehler.
  Keine erneute Hardware-/Softwareprüfung erforderlich.


## Startmitte aus gespeicherten Endpunkten · 15. Oktober 2026

- Bewusster Start von Einrichtung/Nachführung berechnet PAN/TILT getrennt aus
  gespeicherten Bewegungsgrenzen, halbe µs aufgerundet. Dienststart bleibt
  inaktiv. Startwerte werden im WebUI angezeigt; kein automatischer Resume.
- Bereiche müssen nicht mehr 1500 enthalten, aber geordnet im Einrichtbereich
  liegen. Speicherknöpfe beziehen sich auf feste Startmitte der Sitzung;
  Speichern bewegt nichts, nächster Start verwendet die neuen Endpunkte.
- Dokumentation und Anschlussplan Revision 13 nachgeführt. Upload und echte
  Zentrierfahrt am Pi offen; keine Hardware im lokalen Test angesteuert.

- Verifiziert lokal: 92 Python-Tests (77 bestanden, 15 optionale übersprungen),
  drei JS-Prüfungen bestanden. Browserdemo startet bei PAN 1450/TILT 1600 µs
  aus gespeicherten 1200–1700/1400–1800; keine reale Servoausgabe.


## Mittelstellungsbutton · 15. Oktober 2026

- Im aktiven Einrichtmodus „In Mittelstellung fahren“: beide Achsen bis 40 µs/s
  zur Mitte der zuletzt gespeicherten Bewegungsgrenzen. Kein neuer Hardwarestart
  oder Umschalten aus der Nachführung durch diesen Button. Keine Endpunktänderung.
- „Bewegung anhalten“/Richtungstaste bricht ab; alte Sequenzen können keine
  spätere Stoppentscheidung aufheben. Watchdogs und Kamerastopp bleiben aktiv.
- Dokumentation und Anschlussplan Revision 14 aktualisiert. Upload und echte
  Fahrt am Pi weiterhin offen; lokale Prüfung mit künstlichem Treiber/Demo.

- Verifiziert: 95 Python-Tests (80 bestanden, 15 optionale übersprungen),
  drei JS-Prüfungen und JS-Syntaxprüfung bestanden. Browserdemo: PAN von 1450
  auf 1508 verfahren und per Mittelstellungsbutton auf 1450 zurückgeführt,
  TILT blieb bei 1600. Anschließend Kamerastopp geprüft, keine echte Hardware.

## FPS- und Nachführungsdiagnose · 15. Oktober 2026

- Nur lesend am laufenden Pi über Heimnetz geprüft; keine Bewegung, kein Start,
  kein Deployment und keine Änderung der Laufzeiteinstellungen.
- MJPEG-Messung über 15,09 s: 71 empfangene Bilder, 4,72 Bilder/s zwischen
  erstem und letztem Bild. Median Bildabstand 201,4 ms, größter Abstand 310,9 ms.
  Gemessen ist die ausgelieferte Bildrate über WLAN, nicht die Sensorbildrate.
- API meldet echte Pi-Kamera ohne Fehler, Detektionsauswertung ca. 5/s.
  Nachführung inaktiv; letzter Fehler „Farbpunkt verloren; erneut starten“.
- Vom Pi gelieferte camera.html ist bytegleich zur lokalen Datei. SSH ohne
  interaktive Anmeldung abgelehnt; Python-Dateien auf dem Pi nicht abgeglichen.
- Lokaler Code: camera.py wartet nach jedem Bild 0,2 s; stream.mjpg zusätzlich
  0,1 s zwischen Prüfungen. Kamera-Follow-Canvas wird über Statuspolling mit
  mindestens 0,3 s Abstand erneuert (höchstens ca. 3,3 Anzeigen/s).
- follow.py wertet nur neue Kamerabilder aus. Nachführung: normierter
  Bildfehler × 160 µs/s, höchstens ca. 80 µs/s, Totzone ±6 % der Bildbreite/-höhe.
  Einrichtung/Mittelstellung bleiben absichtlich auf 40 µs/s begrenzt.
- Live gespeicherte Bewegungsbereiche: PAN 588–2448 µs, TILT 715–1620 µs.
  Falls der laufende Python-Code dem lokalen entspricht, dauert bereits die
  Sollwertänderung über den ganzen Bereich selbst bei durchgehend maximalem
  Tempo mindestens ca. 23,3 s bzw. 11,3 s. Keine gemessene mechanische Fahrzeit.
- Ergebnis: geringe Auslieferungs-/Anzeigebildrate und sehr langsame
  Sollwertnachführung sind konkrete Softwarebremsen. Die reale Servogeschwindigkeit,
  Versorgung unter Last und tatsächliche Nachführleistung bleiben ungeprüft.
- Möglicher nächster Schritt: höhere kontrollierte Kamerabildrate und einstellbare
  Nachführgeschwindigkeit, anschließend beaufsichtigter Vergleich mit echten
  Bewegungen. Bestehende Endpunkte, langsames Einrichten und Watchdogs erhalten.

## Schnellere Farbnachführung · 15. Oktober 2026

- Nutzer meldet schnelle Grundstellungsfahrt und wünscht vergleichbar zügige
  Nachführung. Das bestätigt keine gemessene mechanische Geschwindigkeit.
- Lokal umgesetzt: Nachführtempo 40–800 µs/s, Standard bei neuer Konfiguration
  400. Vorhandene Dateien ohne diesen Wert behalten 80 und alle Endpunkte;
  nach Upload zum Test ausdrücklich 400 im WebUI speichern. Nah am Bildzentrum
  proportional langsamer, Totzone und Endpunkte bleiben erhalten.
- Pi-Kamera-Zielrate 15 Bilder/s bei 640×480, keine gespeicherte Altbild-Queue;
  bisherige feste 200-ms-Pause ersetzt. MJPEG-Prüfung alle 20 ms, Follow-UI
  100 ms nach Antwort. Demo bleibt ca. 5 Bilder/s. Gemessene Producer-FPS,
  Follow-Auswertungsrate und Farberkennungsdauer jetzt sichtbar.
- Bei verzögerten Bildern höchstens 100 ms Sollwertänderung nachholen.
  Einrichtung/Mittelstellungsbutton weiter 40 µs/s, Stopp-/Watchdog-Regeln
  unverändert. Kein zusätzlicher Hardwarestart oder automatisches Wiederanlaufen.
- Verifiziert: 98 Python-Tests, davon 83 bestanden und 15 optionale übersprungen;
  drei JS-Prüfungen und git diff --check bestanden. Regressionen prüfen Tempo
  bei 15/20 Hz, Bildlücken, Altdateien und Endpunkterhalt.
- Lokale Browserdemo: Tempo 500 und anschließend 400 gespeichert, Endpunkte
  unverändert. Vorschau ca. 4,8 Auswertungen/s, Producer ca. 4,9 Bilder/s,
  Farberkennung rund 18–20 ms auf Entwicklungsrechner. Stopp und Sperrung der
  Eingaben während Vorschau geprüft. Screenshot-Aufnahme scheiterte zweimal
  am Browser-Timeout; sichtbare Zustände über Browser-Zugänglichkeitsbaum geprüft.
- README, SOFTWARE, Modul-/Testanweisungen und AGENTS aktualisiert.
- Offen: Upload, echte Pi-Bildrate/Last und Nachführung mit bewegtem Farbpunkt.
  Kein Deployment und keine echte Servobewegung durch diese Änderung.

## Begrenzte Farbpunktsuche · 16. Oktober 2026

- Nutzer beauftragt Suchbewegung innerhalb gespeicherter Endpunkte.
- Lokal umgesetzt: gespeicherte Option (anfangs aus), erst nach erkanntem
  Farbpunkt und 0,5 Sekunden Verlust; zunächst letzte Bildrichtung, dann
  Schwenks auf aktueller Höhe und beiden TILT-Grenzen. Grenzen bleiben erhalten.
  Maximal min(Nachführtempo,200) µs/s, ein Durchlauf oder 60 Sekunden; ohne Fund
  Sitzung/PWM beenden. Zwei aufeinanderfolgende Funde beenden Suche; erster
  Fund hält Suchfahrt an. Preview/Setup suchen nicht. Kein automatischer Start.
- Verifiziert: 102 Python-Tests (87 bestanden, 15 übersprungen), drei JS-Tests.
  Grenzen, umgekehrte Achsen, Zeitlimit, Durchlaufende, Wiedererkennung, erneuter
  Verlust, gesperrte Achse, Stopp und Kamera-/Heartbeat-/Auswertungsfehler simuliert.
- Live nur gelesen: 15,0 Producer-Bilder/s, Suchoption noch nicht auf Pi,
  Nachführtempo 80, Achsumkehr jeweils aus. Keine Servos angesteuert.
- Offen: Upload per Nutzeranmeldung, Suchoption aktivieren und realen Punkt
  erst erkennen lassen, dann aus dem Bild führen. Tatsächliche Suchabdeckung,
  Wiedererkennung, Richtung und Geschwindigkeit am Aufbau verifizieren.
- Browserdemo verifiziert: Suchoption eingeschaltet, gespeichert und nach
  Neuladen weiterhin aktiv; Endpunkte unverändert. Screenshot unter
  `/tmp/halloween-suchoption.png` (lokale Demo, keine echte Bewegung).
  JS-Syntax und git diff --check ebenfalls bestanden.

## Übersichtliche WebUI · 16. Oktober 2026

- Auf Nutzerwunsch breite Ansicht bis 1800 px, ab 1000 px zwei Spalten.
  Kamera: Bild links, Status/Start/Stopp rechts, Detailparameter aufklappbar.
  Endpunkte/manuelle Einrichtung gemeinsamer Klappbereich, darin Zahlenwerte
  und Richtungstasten nebeneinander. Grabseite entsprechend verbreitert;
  Auslöseeinstellungen, Ereignisse und Profile aufklappbar.
- Lesbare Schrift/Bedienelemente beibehalten; Desktopkopf mit Alles-Stopp
  bleibt sichtbar. Mobil normale einspaltige Seite ohne seitlichen Überlauf.
  IDs, JavaScript-Abläufe, API, Servo- und Speicherlogik unverändert.
- Verifiziert: zwei Seitentests, drei bestehende JS-Tests, JS-Syntax, eindeutige
  HTML-IDs und git diff --check. Kein neuer Volltest der unveränderten Steuerung.
  Lokale Browserdemo bei normaler Desktopgröße, 1920×1080 und 390×844:
  Bild/Bedienung nebeneinander bzw. untereinander, kein horizontaler Überlauf
  auf beiden schmalen Seiten, Ausklappen erreichbar. Farbvorschau gestartet
  und gestoppt; Demo-Einrichtung PAN 1500→1534 und Mittelstellung→1500 geprüft.
  Keine echten Aktoren angesteuert, kein Pi-Upload.
- Dokumentation/Anweisungen aktualisiert. Upload und Kontrolle auf Nutzer-Pi
  noch offen; vorhandene Endpunkte bleiben erhalten.

## Farbpunkt bei Bildverlust behalten · 16. Oktober 2026

- Ursache: Farbe war bereits gespeichert; bisheriger 1-s-Zielverluststopp bzw.
  Suchende beendete jedoch die Servositzung. Nutzer wünscht dauerhaftes Behalten.
- Geändert: Ohne Fund aktive gesunde Sitzung an letzter Position warten lassen;
  keine neuen Bewegungsbefehle, PWM hält Position. Nach zwei Funden wieder folgen.
  Suchbeginn von 0,5 auf 1,5 s verzögert; ein Durchlauf/60 s endet im Wartezustand
  statt Sitzungsabbruch. Keine endlosen Suchrunden. UI benennt Wartezustand.
- Farbe bleibt wie bisher atomar in follow.json bis neuer Farbwahl, auch nach
  Stopp/Neustart. Kein gespeichertes Foto oder eindeutige Objektidentität.
  Nach explizitem Stopp, Fehler oder Neustart weiterhin bewusst neu starten.
- Verifiziert: 104 Python-Tests (89 bestanden, 15 optionale übersprungen), drei
  JS-Tests. Unter anderem drei Minuten simulierte Punktabwesenheit, kein
  wiederholtes Suchen, Wiederaufnahme, Farbe nach Neukonstruktion sowie
  bestehende Stopp-/Watchdog-Regeln. JS-Syntax und git diff --check bestanden.
- Nur lokale Umsetzung; Upload und echter Wiedererkennungstest noch offen.

## Schwarz/blaues Design · 16. Oktober 2026

- Nutzerwunsch lokal umgesetzt: dunkler Hintergrund, blaue Flächen/Akzente,
  statischer Glow an Navigation, Rahmen, Status und Hauptaktion. Rote Stopps,
  amberfarbene Hinweise und deutlicher Tastaturfokus bleiben unterscheidbar.
- Nur CSS/Designfarben; keine Änderungen an API, Polling, Bild-/Servosteuerung.
  Keine externen Assets, Daueranimation oder zusätzliche Pi-Bildberechnung.
  Hover-Übergänge unterstützen reduzierte Bewegung.
- Browserdemo visuell geprüft: Kamera-Desktop, beide Seiten bei 390×844 ohne
  horizontalen Überlauf, Details bedienbar. Screenshot der lokalen Demo:
  /tmp/halloween-schwarz-blau.png. Kein echter Hardware-/Pi-Leistungstest.
- Bestehende Seitentests/JS-Prüfungen, Syntax und diff --check geprüft.
  Upload zum Pi bleibt offen; Dokumentation und Anweisungen aktualisiert.