# Halloween – Arbeitsplan ## Aktueller Stand · 16. Oktober 2026 - Änderungsverlauf in VERDRAHTUNG.md durchgehend nach Revision absteigend sortiert (15 bis 1); alle 15 Einträge mit Nummer, Datum und Text erhalten. Reihenfolge, Vollständigkeit und Diff lokal geprüft. - Nutzer-Screenshot: README-Player kann das Video nicht laden; der Dateilink öffnet laut Nutzer die funktionierende Videoseite. Player durch ein anklickbares vorhandenes Schlussbild ersetzt, Bild gezielt versioniert. Bild lokal angesehen, Verweise und Diff geprüft; neue Gitea-Ansicht offen. - README um einen Videoplayer mit Steuerung, ohne Autoplay und mit alternativem Dateilink ergänzt. Renderer der aktiven Gitea-Instanz (28.0.0) authentifiziert geprüft: video, controls, width und src bleiben erhalten. Tatsächliche Wiedergabe im Browser noch nicht bestätigt. - Auf Nutzerwunsch die letzte Konzeptvorschau `preview/v4/halloween_scanner_group_photo.mp4` (ca. 3,5 MB) gezielt zur Versionierung freigegeben und in der README verlinkt. Andere Renderdateien bleiben ausgeschlossen. Simulationskennzeichnung und privates Git-Ziel bleiben erhalten; Dateipfad und Git-Ausnahme lokal geprüft. - README-Bildbereich als Markdown-Tabelle mit drei anklickbaren Fotos nebeneinander und Erläuterungen darunter angeordnet. HTML-Tabelle nach gemeldetem Vorschauproblem ersetzt. KI-Bildhinweis und Originalverweise erhalten; lokale Verweise und Diff geprüft. Nutzer bestätigt die sichtbaren Bilder in der Vorschau; Darstellung in Gitea noch nicht visuell geprüft. - Git-Ziel auf Nutzerwunsch lokal auf `https://git.mb-soft.site/marcinator_2/Halloween.git` umgestellt. HTTPS-Verbindung erreicht den Server mit aktiver Zertifikatsprüfung; Repository-Abfrage scheitert an fehlender interaktiver Anmeldung. Kein Push erfolgt; Existenz, Privatstatus und Stand des Zielrepositories sind noch authentifiziert zu prüfen. Vorgabe bleibt privat, Branch `main`. - Doku-Fotos: drei separate `*_DOKU.png`-Ansichten mit neutralem Hintergrund und Bildunterschriften erstellt und in `VERDRAHTUNG.md` eingebunden; Gestaltung visuell geprüft. Unveränderte Originale bleiben direkt verlinkt. KI-Ansichten dienen der Darstellung, nicht der technischen Anschlussprüfung. - README mit anklickbarer Bilderübersicht und direktem Einstieg in die bebilderte Aufbau-/Anschlussanleitung ergänzt. `VERDRAHTUNG.md` Revision 15 führt schrittweise zu Anschlusslisten, Erstprüfung und Aufbauprotokoll; elektrischer Entwurf unverändert. Bildpfade und Abschnittsverweise geprüft. - README-Vorschau: HTML-Vorschaubilder in einer Tabelle wurden laut Nutzer nur als Links angezeigt. Durch normale Markdown-Bilder untereinander ersetzt; Dateipfade geprüft, Darstellung in der Nutzervorschau noch zu bestätigen. - 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 15 (Dokumentationsaufbereitung); 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://git.mb-soft.site/marcinator_2/Halloween`; Branch `main`, Repository weiterhin 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.