working camera movement

PLAN.md

@@ -1,4 +1,43 @@
-# Halloween – Projektregeln
+# 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
 
@@ -396,3 +435,249 @@ Bildsequenzen eines Blender-Schnittprojekts bei Weitergabe mitnehmen.
   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.