MegBes Wiki - Benutzerbeiträge [de]

Messe

2026-10-28T15:33:41Z

Clawtronics: Neuen Direktzugriff Messeguide verlinkt

= Messe – MegBes am Messestand =

== Zweck ==

Das Projekt <code>messe</code> wird nur aktiviert, wenn tinetronics den eigenen Messestand mit MegBes-Funktionen betreibt. Außerhalb eines Messebetriebs ist die Umgebung nicht als dauerhaft aktives Produktivsystem zu behandeln.

Auf der Projektseite werden je Einsatz die Veranstaltung, der Aufbau und die tatsächlich verwendeten Funktionen dokumentiert. Dadurch bleibt nachvollziehbar, ob die vorhandene Konfiguration zum nächsten Messestand passt oder vorab angepasst werden muss.

== Technischer Stand ==

{| class="wikitable"
! Angabe
! Stand
|-
| Projektschlüssel
| <code>messe</code>
|-
| Externer Container
| <code>megbes-external-messe</code>
|-
| External-Release
| <code>MARCH-2026-1-RELEASE</code>
|-
| Container-Port
| Host-Port <code>32771</code> auf Container-Port <code>8080</code>
|-
| Betriebsstatus
| nur bei einem konkreten Messeeinsatz aktiv
|-
| Letzte technische Inventur
| 7. August 2026 – externer Container lief
|}

== Checkliste je Messeeinsatz ==

* Veranstaltung, Ort und Zeitraum eintragen
* geplante MegBes-Funktionen festlegen
* Stations- und Geräteliste für den konkreten Aufbau erstellen
* Internetzugang und lokales Messe-Netz vorab klären
* Releases und Funktion vor dem Versand testen
* Auf- und Abbauverantwortliche benennen
* nach der Messe temporäre Zugänge deaktivieren und Ergebnis dokumentieren

[[Kategorie:Projekte]]
[[Kategorie:MegBes]]

== Geplante MUTEC-WebSocket-Funktionen ==

Die Umsetzung [[MUTEC – WebSocket-Steuerung]] wird zunächst unter tine getestet. Der Wechsel auf messe erfolgt nach separater Abnahme mit projektgetrennter Ticket-/Relay-Konfiguration. Stand 09.10.2026: noch nicht live installiert.

== Direkter Zugang Messeguide ==
Der ergänzende Backend-Zugang unter https://messeguide.megbes.de/ ist unter [[Messeguide]] dokumentiert. Stand 28.10.2026: HTTPS und ticketloser Backend-Zugang eingerichtet; Abnahme bis zur konkreten Station noch offen.

Messeguide

2026-10-28T15:33:41Z

Clawtronics: Messeguide-Backend eingerichtet; HTTPS und Direktzugriff geprüft, Stationsabnahme offen

= Messeguide – direkter Zugriff auf das Messe-Terminal =

Stand: 28. Oktober 2026. Ergänzender Direktzugriff zum Projekt [[Messe]], analog zu [[MiQua Guide]] und [[HON]].

== Bereitstellung ==
{| class="wikitable"
! Angabe !! Wert
|-
| Öffentliche Backend-Adresse || https://messeguide.megbes.de/
|-
| Projektschlüssel || <code>messeguide</code>
|-
| Plesk-Container || <code>megbes-external-messeguide</code>
|-
| Image || <code>tinetronics/megbes-external:MARCH-2026-1-RELEASE</code>
|-
| Port || <code>127.0.0.1:32772 → 8080/tcp</code>; Container-Port nicht direkt aus dem Internet erreichbar
|-
| nginx-Proxy || <code>messeguide.megbes.de/ → megbes-external-messeguide:8080</code>
|-
| Start || Automatischer Start nach Serverneustart aktiviert
|-
| HTTPS || Let's Encrypt, automatische Erneuerung; HTTP leitet auf HTTPS um
|-
| Clientzertifikat zum Internal || Vorhandenes Messe-Zertifikat: <code>/home/certs/messe → /opt/app/certs</code>
|-
| Konfiguration || <code>tinetronics/megbes-config</code>, <code>megbes-external-config.json</code>, Eintrag <code>messeguide</code>
|-
| Konfiguriertes Internal-Ziel || <code>https://messe-dyndns.megbes.de:18905</code> (aus bestehender Messe-Konfiguration übernommen)
|}

Die Umgebungsvariablen entsprechen der bestehenden Messe-Instanz; <code>SPRING_APPLICATION_NAME=messeguide</code>. Der neue Projekteintrag enthält die drei Internal-Verbindungsfelder ohne Ticket-Administratorfelder. Keine Zugangsdaten, Tokens oder Zertifikatspasswörter auf dieser Seite speichern.

== Prüfung und verbleibende Abnahme ==
* DNS zeigt auf den zentralen Plesk-Server.
* Neuer Container gestartet; <code>GET /info</code> lokal und über öffentliches HTTPS ohne Ticket mit HTTP 200 geprüft.
* HTTP-zu-HTTPS-Weiterleitung liefert HTTP 301.
* Leere Befehlsliste an <code>POST /video-command</code> wird mit HTTP 400 zurückgewiesen; kein Stationsbefehl gesendet.
* <code>GET /management/health</code> ohne Verwaltungsberechtigung wird mit HTTP 401 zurückgewiesen.
* Bisheriger Messe-Endpunkt <code>/info</code> weiterhin HTTP 200.
* '''Offen:''' Stationsnummer und geeigneten Testbefehl mit Koi festlegen; danach Verbindung einschließlich Clientzertifikat bis zum Messe-Terminal prüfen. Dabei klären, ob am Standort ein eigener Internal-Container bzw. abweichender Port für die Direktbedienung erforderlich ist.
* Eine vorhandene Ticket-Oberfläche wird durch diesen Backend-Zugang nicht automatisch auf ticketlosen Betrieb umgestellt. Oberflächenanbindung separat nach Bedarf durchführen.

[[Kategorie:MegBes]]
[[Kategorie:Projekte]]

MUTEC – Mobile Apps

2026-10-21T16:14:18Z

Clawtronics: Root-Aktivierung der Trailer-Automatik und Testumfang bestaetigt

== Mobile-Auswahl vom 18.10.2026 ==
Die Besucherauswahl unter hub.html hat drei Tabs. Wasser · BrightSign ist vorerst nicht mehr angeboten; die unreife native Funktion und die MegBes-Programme wurden nicht entfernt oder geaendert.

{| class="wikitable"
! Tab !! Angebote
|-
| Medien || Drotschmann, Wasser, 001 Katzen, 002 Neon, 003 Monkeys, 004 KI-Material, 005 Visuals, 006 Katzen, 007 KI-Material
|-
| Education || 3D-Objekte und Aquarium
|-
| Games || Pong, Poeng, Flight, Farbenspektakel und Finde den Ort
|}

Medien nutzt die vorhandenen Film-Icons. Ein Klick oeffnet direkt die HTML-Wiedergabesteuerung des gewaehlten Beitrags, ohne erneut die Video-Infokarten zu durchlaufen. Der Film startet erst nach der Tonfreigabe/Startaktion. Dropdown enthaelt alle neun Beitraege; Start/Pause, Zeitleiste, +/-10 Sekunden, Lautstaerke und die vorhandenen Sprachen bleiben verfuegbar. Inhaltliche Kapitel wurden mangels Quelldaten nicht erfunden; Start-Kapitel fuer jeden Film. Wasser und Drotschmann Deutsch/Englisch, uebrige Beitraege Originalton.

=== Belegung und Beitritt ===
Scheitert der App-Start an einem belegten Monitor und ein Spiel ist beitretbar, zeigt genau die soeben angeklickte Kachel einen roten Rand, die Meldung Spieler 1 spielt gerade [Name des tatsaechlich laufenden Spiels] und einen gruenen Button Beitritt anfragen. Kein globaler Beitrittsbutton mehr im Ticketstatus. Haupt- und Gastaktion sind getrennte Buttons innerhalb einer sichtbaren Kachel, keine unzulaessig verschachtelten Buttons. Bei anderem laufendem Spiel nennt der Hinweis dessen Namen; die Anfrage richtet sich an dieses Spiel. Bei nicht beitretbaren Angeboten erscheint kein Gastbutton. Fehlversuche bleiben lokal sichtbar und wiederholbar.

Beim Gastgeber sind Beitrittsanfragen in Pong/Poeng, Flight und Ortssuche nun rot hinterlegt; Annehmen ist gruen. Rechte und Ticket-/Gastpruefungen unveraendert.

=== Webmedien und Ton ===
Die alten MP3s fuer 001–007 haben andere Laufzeiten/Schnitte als die nun bereitgestellten MP4s. Sie werden fuer diese HTML-Beitraege nicht verwendet. Neue passende AAC-Spuren stammen direkt aus den sieben MP4s. Drotschmann verwendet die bekannten DE/EN-Spuren, auf 134.4 s vereinheitlicht; die etwas kuerzere EN-Spur wird hinten mit Stille aufgefuellt. Wasser behielt seine erprobten MP3-Spuren.

Acht Webvideo-Ableitungen (H.264 CRF20, unveraenderte Aufloesung/Bildrate, Faststart, stummes Bild) plus neun passende Audio-Dateien liegen unter video/media/web-20261018/. Insgesamt 17 Dateien und ca. 473 MB. Originalvideos unter video/media/ und alte Audiodateien bleiben unveraendert. Alle neuen Dateien serverseitig per SHA-256 und oeffentlich per HTTP-Range geprueft. Bestehender WebSocket-Uhr-/Playerabgleich bleibt erhalten. Korrektur beim Seek exakt ans Ende: Film beendet bleibt erhalten, statt danach wieder in Pausiert zu wechseln.

=== Validierung und Installation ===
Alle neun echten Film-/Audio-Paare lokal im Browser ueber ihre Menuekachel gewaehlt, abgespielt und bis Mitte/Anfang/Ende gespult; Sprachwechsel bei Wasser/Drotschmann. Dropdown-Wechsel innerhalb derselben Sitzung zu Wasser und Monkeys geprueft. Menuepruefung mit vier echten Gastanfragen am isolierten Relay, Fehler/Wiederholen und Gastgeberfarben. 320/390/768/1280 Pixel ohne horizontalen Ueberlauf, Tabs mit Pfeilen/Home/End, sichtbare Bedienflaechen mindestens 44 Pixel. Bestehende neun Film-Icons auf dem Webserver bestaetigt. Neue Frontenddateien vorab gesichert und nach Veroeffentlichung oeffentlich bytegleich geprueft.

Die lokale Pruefung nutzt echte Player/Medien und Relay mit simuliertem MegBes-Upstream; dabei keine Hardwarebefehle und keine echte Stationsreservierung. Oeffentlicher Browser-Nachtest prueft die Seite read-only und die ticketfreie Filmvorschau. Physischer LED-/Mobilfunk-/Kopfhoerertest bleibt erforderlich.

Smartphone-Seiten neu laden; Electron oder seinen Video-Reiter neu laden, damit der neue Katalog und Player eingelesen werden. Kein Relay-/root-Update erforderlich. Synced sources/ unveraendert. Nachweise im Codex-Arbeitsordner: outputs/MUTEC-Menue-Installation.json, MUTEC-Menue-Umstellung.md, MUTEC-Menue-Medien-Dateien.json, MUTEC-Menue-Medien-Upload.json und MUTEC-Neun-Filme-Browserprüfung.json. Frontendpaket: outputs/MUTEC-Menue-Frontend.zip; grosse Medien separat installiert.

== Vereinfachte Mobile-Oberfläche und Trailer-Rückkehr, 18.10.2026 ==
Titel: tinetronics @ MUTEC 2026. Keine positive Ticketmeldung mehr im Menü; Status nur bei Fehlern. Filmkacheln zeigen vorhandenes Icon und Titel ohne Laufzeit/Ton-Zusatz. Hinweis unter der App-Auswahl entfernt.

Direkte Icons für WhatsApp, Instagram, Facebook, X und das native Teilen-Menü ersetzen den Dialog Messebesuch teilen. WhatsApp und X erhalten einen vorbereiteten Text mit MUTEC-/tinetronics-Hashtags und der öffentlichen Adresse https://www.tinetronics.de/. Instagram/Facebook erhalten den Text über die Zwischenablage zum Einfügen; bei fehlendem Zugriff erscheint ein auswählbares Textfeld. Keine Besucher-Tickets, privaten Steueradressen oder Schlüssel teilen. Keine automatische Veröffentlichung; Besucher bestätigen in ihrer App. Schrift/Icons reagieren auch ohne externe Social-Skripte. Instagram öffnet die App-/Website-Einstiegsseite; kein versprochenes automatisches Anlegen eines Posts.

Zur Auswahl wartet auf die Sitzungsbereitschaft und unterdrückt parallele Klicks. Rückkehr per Header fordert DELETE /session?returnToTrailer=1 an. Auch eine direkte Rückkehr nach hub.html mit bestehender Sitzung verwendet diese Rückkehr, statt still ohne Trailer abzumelden. Fehler werden ausdrücklich als Fehler markiert, damit der bisherige Wortfilter sie nicht versteckt. Bei fehlgeschlagener Trailer-Rückkehr bleiben Sitzung, Seite und weitere Verlängerung für erneutes Versuchen erhalten. Ressourcen-Version 20261018-polish1 auf allen referenzierenden Seiten erneuert, um alte Session-Skripte im Browsercache zu ersetzen.

Browserprüfung mit echtem Relay und simuliertem MegBes: Pong, Pöng, Flight, Finde den Ort, Video, Objects und Farbenspektakel senden einmal 50-Trailer vor Stationsfreigabe; direkte Menürückkehr, Trailer-Fehler/Wiederholung und gemeinsame Farben geprüft. Farben sendet Trailer nur beim letzten Teilnehmer. Der bestehende Aqua-Editor reserviert Station 50 nicht; seine serverseitige Ausnahme (kein Trailer) wurde nicht geändert. Gäste behalten ihren eigenen Spiel-verlassen-Weg ohne MegBes-Rechte. Keine echte Station beim Test gesteuert. Physische Trailer-Wiedergabe am Counter noch zu prüfen, insbesondere da mehrere Apps als betroffen gemeldet wurden; keine gesicherte Diagnose des Hardwarefehlers.

28 betroffene Frontenddateien auf Webserver und lokal vorab gesichert und anschließend öffentlich bytegleich geprüft. Öffentlicher Browser-Nachtest: Titel, neun Filmkacheln, fünf Icons, leere Erfolgsmeldung, entfernter Footer und 320/390/768 Pixel ohne Überlauf. Relay- und MegBes-Programme sowie synced sources/ unverändert. Kein root-Update erforderlich. Nachweise: outputs/MUTEC-Mobile-Polish-Installation.json und MUTEC-Mobile-Polish-Pruefung.json, Frontendpaket MUTEC-Mobile-Polish.zip. Smartphone-Seiten neu laden.

== Beitritt nur über Hauptmenü, 18.10.2026 ==
Die Buttons 2 Spieler / Zwei Spieler sind aus den aktiven Host- und Gastseiten entfernt. Keine QR-Einladungsdialoge mehr in Pong/Pöng, Flight oder Ortssuche. Spieler 2 nutzt seinen Ticket-Login im Hauptmenü: belegte App antippen, grüne Aktion Beitritt anfragen. Bestehende Gastgeber-Zustimmung, Gastrechte und gemeinsamer Countdown bleiben erhalten. Kein Relay-Update nötig; bestehende Serverfunktionen unterstützen den Ticket-Beitritt.

Pong/Pöng und Ortssuche: je eine kompakte Infokarte mit Steuerung und Ziel. Gäste erhalten ebenfalls eine Karte. Aquarium und alte Medien-/Video-Intros auf eine Karte zusammengefasst. Flight zwei Schritte: Sensoren aktivieren mit kurzer Spielregel, danach Kalibrieren und starten; bei fehlenden Sensoren zweite Karte mit Touch-Steuerung. Medienwahl im Hauptmenü öffnet weiterhin direkt den Player.

Geprüft: Hauptmenü-Beitritt zu allen vier Spielen am isolierten Relay, Fehlerfall und Wiederholen; Pong/Pöng-Host und Gast je eine Karte ohne Einladungsdialog, Flight zwei Karten mit Touch-Fallback. Keine Hardwarebefehle in Tests. 28 Frontenddateien gesichert und öffentlich bytegleich geprüft; Gastseiten erhalten ebenfalls neue Ressourcen-Versionen. Synced sources/ und Relay unverändert. Nachweise MUTEC-Menu-Beitritt-Installation.json sowie Cache-Installation.json im outputs-Ordner. Smartphone-Seiten neu laden.

== LinkedIn statt allgemeinem Teilen, 18.10.2026 ==
Der rechte Social-Button ist jetzt LinkedIn (blaues in-Icon). Reihenfolge: WhatsApp, Instagram, Facebook, X, LinkedIn. Der allgemeine native Teilen-Button entfällt. LinkedIn öffnet sharing/share-offsite mit ausschließlich der öffentlichen tinetronics-URL; vorbereiteter Beitragstext wird wie bei Facebook zum Einfügen kopiert, mit manuellem Kopierfeld bei fehlender Berechtigung. 21 betroffene Dateien inklusive Ressourcen-Versionen gesichert, veröffentlicht und bytegleich über HTTPS geprüft. Browser: fünf Icons, LinkedIn rechts, korrektes öffentliches Linkziel, kein generischer Teilen-Button. Keine Beiträge automatisch veröffentlicht.

== Steuerung in neuem Browser-Tab übernehmen, 18.10.2026 ==
Erneutes Scannen eines in diesem Browser bereits aktivierten Tickets übernimmt die bestehende normale Steuersitzung. Die Aktivierung enter-system wird nicht wiederholt. Ein Browserdatensatz in localStorage ist nach Kunde und Installationspfad getrennt und enthält Ticket, Relay-Sitzung, freigegebene App-Adresse und Momentaufnahme. sessionStorage bleibt als Kompatibilität für bestehende Module erhalten. Der Server prüft Ticket und Relay-Sitzung weiterhin. Nur freigegebene App-Pfade derselben Installation werden wieder geöffnet; keine beliebigen Zieladressen oder Display-Schlüssel.

Pro Dokument eigene Kennung; neuer Tab übernimmt die Eigentümerschaft, alter Tab stoppt seine WebSocket-Verbindung und Verlängerung und zeigt exit.html?reason=transferred mit Danke für Ihren Besuch, tinetronics-/MegBes-Logo und fünf Social-Icons. Kein Trailer, kein Stations-DELETE und keine neue Station beim Übergeben. Späte Steuerbefehle des alten Tabs werden zusätzlich vor dem Senden durch Eigentümerprüfung blockiert. Reload der Dankesseite holt keine Steuerung zurück. Abmelden entfernt den gemeinsamen Browserdatensatz. Eine abgelaufene Relay-Sitzung führt mit weiterhin gültigem Ticket zurück ins Menü.

Pong/Pöng und Ortssuche verwenden den wieder gemeldeten Spielzustand; kein erneuter Bereitschaftsbefehl aus dem übernommenen Intro. Video merkt Beitrag/Sprache und wählt bei Wiederaufnahme den laufenden Film nicht erneut aus; Browser-Autoplay kann erneut eine Tonfreigabe verlangen. Flight setzt bei erneutem Freigeben/Kalibrieren eine laufende Runde fort, ohne sie neu zu starten. Sensorfreigaben können browserbedingt erneut nötig sein. Aquarium übernimmt Tierart, Bild und Bearbeitungsschritt; normale Zeichnungen als PNG, große Bilddaten als JPEG zum Schutz der Browser-Speichergrenze. Noch unbestätigte UI-/Sensorzustände sind kein serverseitig garantierter vollständiger App-Speicher.

Geprüft am echten lokalen Relay mit simuliertem MegBes: laufende Pong-Partie mit Display und zwei aufeinanderfolgenden Übernahmen, gleicher Zugang und Spielkennung, keine Ticket-Neuaktivierung/Trailer-/Stationsfreigabe, alte Tabs mit Dank/Logos/Social-Icons, Abmelden. Aquarium-Entwurf samt Tierart und Malschritt in neuem Tab wiederhergestellt. Frische Ticketaktivierung, fehlgeschlagene Ticketprüfung ohne Übernahme, abgelaufene Relay-Sitzung und isolierter anderer Browser geprüft. Keine echte Station gesteuert. Neues MegBes-Logo stammt aus bestehendem Projekt kleh/pics/megbes.png. 50 Dateien gesichert und öffentlich bytegleich verifiziert. Relay/MegBes-Programme und sources/ unverändert; kein root-Update nötig.

Grenzen: gleicher Browser, gleiches Profil und exakt dieselbe Website-Adresse erforderlich; separate Browser, private Fenster oder Geräte übernehmen nicht per localStorage. Gilt für normale Ticket-Steuersitzungen. Der separate Mitspieler-/Gastzugang wird noch nicht tabübergreifend übernommen. Alte, bereits geladene Seiten einmal neu laden, damit die neue Übergabelogik aktiv ist. Bei eingefrorenen Hintergrund-Tabs kann die Browser-Zustellung verzögert sein. Nachweise outputs/MUTEC-Tab-Uebernahme-Installation.json und Frontendpaket MUTEC-Tab-Uebernahme.zip.

== Login-Reparatur nach gemischtem Frontendstand, 18.10.2026 ==
Fehler: MutecSession.resumeTicket is not a function. Webserver und lokaler Stand hatten nach einer weiteren Farben-App-Erweiterung eine ältere js/session.js und control/client.js, während js/login.js bereits die neue Tab-Übernahme verwendete. session.js wieder per Dreiwegevergleich mit dem aktuellen Stand zusammengeführt; colorsgame-Befehl und Zielpfad bleiben erhalten und sind auch in der zulässigen Wiederaufnahme enthalten. ControlClient führt Tab-Sperre mit colorsgame-Gastbereinigung zusammen. Neuere Karten-/Videoverbesserungen wurden nicht überschrieben.

Login prüft seine Abhängigkeit und lädt bei fehlenden Methoden die passende Sitzungsdatei neu; bei fehlendem Netz eine verständliche Meldung statt JavaScript-Typfehler. Ressourcen-Version 20261018-loginfix1 für Sitzungs-, Login- und Client-Dateien auf aktuellen Seiten/Modulen, einschließlich neuer Farben-App. 38 betroffene Dateien vorab lokal und auf Webserver gesichert und öffentlich bytegleich geprüft. Relay und sources/ unverändert.

Geprüft: bewusst alte Sitzungsdatei vor neuer Login-Datei geladen, erfolgreiche automatische Reparatur, frische Aktivierung, fehlgeschlagene Prüfung, abgelaufene Relay-Sitzung, Browser-Isolation. Erneute Übernahme laufender Pong-Partie zweimal ohne neues Ticket/Trailer/Freigabe und Aquarium-Entwurf getestet. Öffentlicher Login mit simulierten Authentifizierungsantworten erreicht Auswahl ohne JavaScriptfehler; keine echte Station oder Besucher-Anmeldung benutzt. Paket/Nachweise outputs/MUTEC-Login-Fix.zip und MUTEC-Login-Fix-Installation.json. Pakete künftiger Erweiterungen müssen gemeinsame Session-/Client-Funktionen beibehalten.

== Arcade-Beitritt: Here comes a new challenger, 18.10.2026 ==
Neues Ziel: mehrere gültige Tickets dürfen unabhängig angemeldet sein. Station 50 / LED-Counter bleibt genau einer normalen Steuersitzung zugeordnet. Weitere Besucher sehen bei belegtem Counter die laufende Anwendung und passende Aktionen statt einer Liste nicht startbarer Apps. Beitritt ist keine zustimmungspflichtige Anfrage mehr.

=== Besucherablauf ===
Bei freiem Counter bleiben die drei Tabs Medien / Education / Games sichtbar. Bei belegtem Counter werden die betreffenden Auswahltabs und App-Kacheln ausgeblendet. Beitretbares Spiel: nur Mitspielen. Ein Klick öffnet die Erklärung, dass der Beitritt die laufende Runde unterbricht; erst Ja, mitspielen sendet den Beitritt. Zurück schließt den Dialog ohne Auswirkung. Bestätigung eröffnet sofort eine akzeptierte Gastrolle und eine neue Zweispieler-Runde; Spieler 1 hat kein Annehmen/Ablehnen mehr. Auf seinem Smartphone und der Anzeige steht Here comes a new challenger. Bis Spieler 2 seine kurze Einführung bzw. Sensorfreigabe abgeschlossen hat, wartet das Spiel. Wenn Gastgeber, Gast und Display bereit/verbunden sind: vollständiger Countdown von drei Sekunden, dann gemeinsamer Start.

Die unterbrochene Einzelrunde wird durch eine neue gemeinsame Runde ersetzt; der Zugang und die Stationsreservierung von Spieler 1 bleiben erhalten. Der Gast kann nur seine Spielrolle steuern, keine Stationsbefehle, App-Wechsel, Neustarts oder Spielenden auslösen. Die Stationshoheit bleibt beim Gastgeber; er kann die App weiterhin selbst verlassen. Ein voller Zweispieler-Platz zeigt die Belegung ohne weiteren Beitrittsbutton. Ein Film oder 3D-Objekt zeigt eine Belegungsinfo; beim Freigeben erscheint automatisch die Auswahl wieder. Im bestehenden gemeinsamen Farbraum ist Gemeinsam malen die passende Aktion (bis 24 Personen). Der separate neue Farben-Spielmodus nutzt wie die vier bisherigen Spiele den Challenger-Beitritt. Vorhandene Aqua-Editor-/Stationsregeln wurden nicht umgebaut.

=== Schnittstellen und Grenzen ===
GET /station/availability prüft das Besucherticket und den aktuellen MegBes-Stationszustand, liefert station=50, Label, App, Belegung und erlaubte Beitritts-/Gemeinschaftsaktion. Keine Ticket-/Steuertoken oder Besucheridentitäten im Ergebnis. Menü fragt sichtbar alle 2,5 Sekunden und bei Rückkehr in den Tab ab. POST /game/challenge akzeptiert ausschließlich feature und die konkrete gameId; dieselbe Zugangskontrolle wie vorher, serielle Reservierung gegen doppelte Gäste. Veraltete Partie oder App-Wechsel werden abgewiesen. Dasselbe Ticket kann seinen noch vorhandenen Gastzugang wieder abrufen, ohne erneut zu unterbrechen. Der alte Anfrage-Endpunkt bleibt für bereits geladene ältere Frontends kompatibel; alle Seiten nach Aktivierung neu laden.

Lobby-Snapshot hat challenger=true für die neue Übernahme. Der erste Gastgeber muss seine Steuerung weiterhin vorbereiten, wenn er noch im Intro war. Gastbereitschaft startet erst mit allen Verbindungen. Abbruch und Timeout geben nur den Gastplatz frei, keine Trailer-/Stationsabmeldung. Erste Gastvorbereitung maximal 90 Sekunden, ungebundener bzw. verlorener Gastzugang weiterhin 15 Sekunden. Nach einmaliger Vorbereitung greift die 90-Sekunden-Frist bei späteren Wiederverbindungen/Revanchen nicht erneut. Ticketwiderruf, Sessionablauf und Gastgeberverlust behalten die bestehenden Schutzregeln. Challenger-Anzeige in der mittleren Bildschirmhälfte, mit horizontaler LED-Vorverzerrung.

=== Prüfung und Installation ===
194 Tests lokal und auf Linux/VPS bestanden, basierend auf den tatsächlich laufenden Servermodulen einschließlich des neuen Farben-Spiels. Geprüft für Pong, Pöng, Flight, Ortssuche und Farben-Spiel: sofortige Annahme nach Bestätigung, kein Gastgeber-Veto, verpflichtende Vorbereitung, vollständiger Countdown, zwei gleichzeitige Gäste, Wiederholung, voller Platz, Abbruch/Timeout, Wiederverbindung, falsches/abgelaufenes Ticket, falsche Partie und fehlende Stationsrechte. HTTP-Status und Challenge-Endpunkt authentifiziert geprüft. Browser mit echtem isoliertem Relay: Pong/Pöng einschließlich laufendem Solo, Bestätigungsabbruch ohne Unterbrechung, Smartphone-/Display-Meldung, Gastintro, Countdown, dritter Besucher, Gastausstieg und freier Auswahl. Zusätzlich Video, Objects und gemeinsamer Farbraum; öffentliche Website mit simulierten Statusdaten geprüft. Keine echte Station gesteuert.

52 Frontend-Dateien gesichert und öffentlich bytegleich hochgeladen. Aktivierung ist über challengerArcade in capabilities abgesichert: solange das Relay nicht aktualisiert ist, gilt weiterhin der bisherige Ablauf. Serverpaket auf /home/clawtronics/mutec-challenger-update bereit; als root bei freier Station 50 ausführen: bash /home/clawtronics/mutec-challenger-update/apply-challenger-update.sh. Installer prüft Paket, Tests und SHA-Ausgangsstand aller Servermodule vor Änderungen, sichert die ersetzten Dateien und hat Rollback. Ersetzt nur server.js, pong-guests.js, game-lobby.js und den neuen Test. DISPLAY_KEY, Umgebungsdatei, Bestenlisten, MegBes-Programme, vorhandene Farben-Spielmodule und synced sources/ bleiben erhalten. Root-Aktivierung bei Dokumentation noch ausstehend. Danach Smartphone-Seiten und Electron-Webseiten neu laden; physischer Messestandtest noch erforderlich.

Artefakte im bisherigen Codex-Arbeitsordner outputs/: MUTEC-Challenger-server.tar.gz, zugehörige SHA-Datei, apply-challenger-update.sh, MUTEC-Challenger-VPS-Test.txt, MUTEC-Challenger-Frontend.zip, MUTEC-Challenger-Installation.json und MUTEC-Challenger-Browserpruefung.json. Geprüfter Relay-Quellstand im Arbeitsordner work/challenger-stage/realtime; nicht blind aus älteren Frontendpaketen gemeinsame Session-/Client-Dateien überschreiben.

== Arcade-Beitritt aktiviert, 18.10.2026 ==
Root-Installation erfolgreich abgeschlossen: 194 Tests bestanden, Relay und Ablauf-Wächter aktiv. Health meldet challengerArcade=true; auch die öffentliche capabilities-Schnittstelle mit dem erlaubten Website-Origin wurde nach der Installation mit challengerArcade=true geprüft. Der zuvor als ausstehend dokumentierte Arcade-Ablauf ist damit aktiviert. Serversicherung: /var/backups/mutec-realtime/challenger-20261018T204434Z-3580490. Smartphone-Seiten und Electron-Webseiten neu laden. Physischer Test mit zwei Mobilgeräten am Counter bleibt noch durchzuführen.

== Museumsguide ==
Seit 20.10.2026 unter Education: Dummy-Ausstellung mit Sprach-/Untertitelwahl, vierstelligen Stationscodes, Originaltexten und Audios aus BAYAM/GKP, Bildergalerie und Umfragen. Auch bei belegtem Counter verfuegbar. Station-JSONs bleiben kompatibel; importierte IPs bleiben bis zur ausdruecklichen Zuordnung im Demo-Modus. Details: [[MUTEC – Museumsguide]].

== Messages und YouTube wieder im Medien-Tab ==
Stand 21.10.2026: Die ursprünglichen iFrames formmessage.php (Messages) und form.php (YouTube) stehen wieder direkt unter den Filmbeiträgen im Tab Medien. Ticket-Anmeldung bleibt erforderlich; erst Senden reserviert die exklusive media-Sitzung. Reines Öffnen der Medienauswahl reserviert den Counter nicht. Beide Formulare teilen dieselbe Sitzung; fremde Belegungen erlauben kein Senden.

Bestehende Signale bleiben erhalten: 50-message für Nachrichten, 166-youtube und 50-youtube für den YouTube-Link. „Wiedergabe beenden“ startet den Trailer und gibt die Station frei. Reload und erneuter Ticket-Scan im selben Browserprofil führen zur Medienauswahl mit derselben media-Sitzung zurück. Andere Anwendungen behalten den bisherigen Ablauf.

Sieben Dateien vorab lokal und vom Webserver gesichert, installiert und geprüft. Isolierte Prüfungen für beide Formulare, Befehle, gemeinsame Reservierung, Belegungssperre, Trailer, Reload/Tab-Übernahme sowie bestehender Pong-/Login-Ablauf. PHP-Syntax und reale Ablehnung nicht authentifizierter POSTs geprüft; öffentlicher Browsertest mit simuliertem Speichern und simulierten Befehlen, ohne Counter-Umschaltung. Kein Relay-Update und keine Änderungen an sources/.

== YouTube als steuerbarer Medienbeitrag ==
Stand 21.10.2026: YouTube ist jetzt ein eigener Medien-Button wie Wasser und Drotschmann. Der bisherige YouTube-iFrame im Hauptmenü entfällt; Messages bleibt erhalten. Nach Öffnen zeigt die bestehende Filmsteuerung ein zusätzliches YouTube-URL-Feld. Play/Pause, Fortschrittsregler, ±10 Sekunden und Lautstärke steuern den Counter. Der YouTube-Ton läuft auf Wunsch am Counter. Beim Wechsel zu lokalen Filmen bleiben Smartphone-Ton, Sprachspuren und Kapitel erhalten.

Die offizielle YouTube IFrame Player API wird im vorhandenen Electron-Reiter video eingesetzt (166-video / 50-maps). Kein neuer Reiter, kein neuer Schlüssel, kein Relay- oder Electron-Programmupdate. Der aktuelle VPS-Validator wurde auf Kompatibilität geprüft. youtube.js akzeptiert nur bekannte YouTube-Hostnamen und gültige einzelne Video-IDs. WebSocket nutzt unverändert video.command / video.listener / video.status; begrenzte Medienkennungen youtube_<Video-ID>_v<Lautstärke 0–100> übertragen Videoauswahl und Lautstärke. Eine Lautstärkeänderung desselben Videos erhält Abspielposition und Play/Pause. Roh-URLs oder beliebige Netzwerkziele werden nicht übertragen.

Referrer-Policy strict-origin-when-cross-origin und origin sind gesetzt. Keine Stream-Extraktion, keine separate YouTube-Audiospur und keine verdeckenden MUTEC-Overlays über dem YouTube-Player. Einbettungs-/Netzwerk-/Autoplay-Fehler werden angezeigt. YouTube-eigene Freigaben, Werbung und Verfügbarkeit gelten weiterhin; Live-Streams ohne bekannte Dauer haben keinen normalen Fortschrittsregler. Exklusive Ticket-Sitzung, Sperre bei fremder Belegung, Tab-Übernahme und Trailer-Rückkehr bleiben erhalten.

Zwölf Dateien vorab lokal und auf dem Webserver gesichert und installiert. Geprüft mit echter lokaler WebSocket-Verbindung und simuliertem YouTube-Player: Medienauswahl, URL-Prüfung, Play/Pause/Seek, Counter-Ton/Lautstärke ohne Sprung, laufende Wasser-Wiedergabe mit Smartphone-Ton, Fehler/Wiederaufnahme, Tab-Übernahme, Trailer und Mobilansichten. Bestehender Pong-/Login-Ablauf geprüft. Echte YouTube-API sowohl lokal als auch über die veröffentlichte HTTPS-Herkunft erfolgreich mit Video-Metadaten geprüft; öffentlicher Bedienoberflächentest mit simulierten Stationsbefehlen. Physischer Hör-/Bildtest am LED-Counter steht nach Neuladen/Neustart von Electron aus. views.json ist bereits passend eingerichtet. sources/ unverändert.

[https://www.tinetronics.de/mutec/video/README-YouTube.md Technische Anleitung] · [https://developers.google.com/youtube/iframe_api_reference Offizielle YouTube-API] · [https://developers.google.com/youtube/terms/required-minimum-functionality Einbettung und Client-Identifikation]

== YouTube: automatischer Start ohne Lautstärkeregler ==
Update 21.10.2026: Der Lautstärkeregler ist für YouTube entfernt; der Ton bleibt am Counter. Lokale Filme behalten Smartphone-Ton und dessen Lautstärkeregler.

„Video laden“ sendet die Videoauswahl; erst die Bestätigung des Counters löst unmittelbar Play aus. Kein zweiter Start-Klick und keine geschätzte Ladeverzögerung. Zeitposition und Wiedergabestatus kommen weiter vom Counter. Fehler und Verbindungsverlust verwerfen den vorgemerkten automatischen Start. Neue YouTube-Links verwenden den festen Player-Ausgangswert 100 Prozent. Die physische Audioanlage bestimmt die gewünschte Lautstärke vor Ort.

Drei Frontend-/Dokumentationsdateien vorab gesichert und veröffentlicht. Geprüft über echte lokale WebSocket-Verbindung mit simuliertem YouTube-Player: automatischer Start, versteckter Regler, Play/Pause/Seek, laufendes Wasser mit Smartphone-Ton und Regler, URL- und Einbettungsfehler mit Wiederaufnahme, Tab-Übernahme, Trailer und schmale Mobilansichten. Kein Relay-/Electron-Update. Smartphone-Seite neu laden.

== Automatische Auswahl und Trailer bei Inaktivitaet ==
Stand 21.10.2026: Frontend aktualisiert, Relay-Paket vorbereitet und auf VPS getestet; die Server-Aktivierung erfolgt noch durch root mit <code>bash /home/clawtronics/mutec-idle-update/apply-idle-update.sh</code> bei freier Station 50.

Abgelaufene Steuersitzungen führen automatisch zur Auswahl, sowohl bei API-Fehler als auch WebSocket-Code 4001. Ein weiterhin gültiges MegBes-Ticket bleibt erhalten. Ist das Ticket selbst ungültig, gilt weiter die normale Ticket-Prüfung/Dankeseite. Reine Netzfehler werden nicht als Sitzungsablauf behandelt; doppelte Steuerverbindungen geben keine fremde Sitzung frei. Gäste mit eigener angemeldeter Ticket-Sitzung kehren ebenfalls zur Auswahl zurück, anonyme Gäste behalten die Dankeseite. Eine alte automatische Rückkehr kann einen zwischenzeitlich neu gescannten Tab nicht übernehmen.

Smartphone-Seiten verlängern die Sitzung im Hintergrund nicht mehr. Beim Wiederanzeigen wird geprüft. Die vorhandene Steuersitzungsfrist beträgt ca. 45 Sekunden; nach Relay-Update startet auch deren automatischer Ablauf 50-Trailer vor der Freigabe. Bei Fehler wird Steuerung sofort gesperrt und die Trailer/Freigabe zur Wiederholung vorgemerkt. Vor jedem erneuten Trailer werden gültiges Ticket und die eigene REMOTE-Belegung geprüft; IDLE oder fremde Belegungen werden nicht umgeschaltet. Der vorhandene interne Ticketablauf-Wächter bleibt für tatsächlich abgelaufene Tickets unverändert zuständig.

Neue Serverfristen: 60 Sekunden ohne Bedienung nach Spiel-/Filmende, sonst 120 Sekunden ohne Eingabe. Unveränderte Steuer-Keepalives, Statusmeldungen und Sensorrauschen zählen nicht als Bedienung. Tatsächliche Tasten-/Touch-/Texteingaben werden bei Erneuerung gemeldet; zulässige geänderte Steuerdaten beider Spieler zählen ebenfalls. Spiel-Endebildschirme werden nicht durch weiterlaufende Steuerimpulse künstlich aktiv gehalten. Ein laufender Film mit aktiver Smartphone-Verbindung und frischer Display-Rückmeldung bleibt erhalten. Gemeinsam genutztes Farbenspektakel kehrt erst beim letzten Teilnehmer zum Trailer zurück. Aquarium-Editoren reservieren weiterhin keinen Counter und schalten fremde Anwendungen nicht um.

204 Servertests lokal und auf dem VPS bestanden, einschließlich Rückkehr, Fehler/Wiederholung, fremder Besitzer, IDLE, ungültiger Tickets, gemeinsamem Farbraum, Schluss-/Eingabefristen, Filmwiedergabe und Gastrechten. Browserprüfungen: automatischer Rückweg ohne Fehlbox, Ticket erhalten, Hintergrund ohne Erneuerung, einmalige Aktivitätsmeldung statt Heartbeats, alte Seite/Media-Sitzung und gleichzeitiger Ablauf/Tab-Scan. Bestehender Pong-/Login-Ablauf geprüft.

Frontend-Sicherung und Paket: outputs/MUTEC-Inaktivitaet-Frontend-Sicherung-20261021 und MUTEC-Inaktivitaet-Frontend.zip. Serverpaket: MUTEC-Inaktivitaet-server.tar.gz mit Prüfsumme und apply-idle-update.sh. Installer prüft den aktuellen Code-Ausgangsstand, sichert geänderte Dateien, führt alle Tests aus und startet nur den Relay neu. DISPLAY_KEY, Umgebungsdatei, Bestenlisten, MegBes-Programme, sources/ und Ticketablauf-Wächter bleiben erhalten. Nach Aktivierung liefert /health idleReturn:true; Smartphone-Seiten neu laden.

== Inaktivitaets-Update aktiviert, 21.10.2026 ==
Root-Installation vom Betreiber bestätigt: 204 Tests bestanden, keine Fehler; /health meldet idleReturn:true. Relay und Ticketablauf-Wächter sind active. Sicherung: /var/backups/mutec-realtime/idle-20261021T161249Z-2398303. Die zuvor als vorbereitet dokumentierte Trailer-Automatik ist damit aktiviert. Smartphone-Seiten neu laden, damit die neue Hintergrund-/Ablaufbehandlung verwendet wird.

Die Testliste umfasst aktuelle Funktionen sowie weiterhin vorhandene ältere Schnittstellen (z. B. QR-/Anfrage-Beitritt). Testnamen beschreiben nicht zwingend die aktuelle Benutzeroberfläche. Solange solche Schnittstellen unterstützt werden, bleiben ihre Rechte-/Ablaufprüfungen sinnvoll. Bereinigung erst zusammen mit gezielter Entfernung ungenutzter Schnittstellen. Künftige Installationsausgaben sollen Zusammenfassung und Fehler anzeigen und die vollständigen Testergebnisse in einem Detailprotokoll ablegen.

MUTEC – Mobile Apps

2026-10-21T16:07:46Z

Clawtronics: Automatische Sitzungsrueckkehr und vorbereitetes Inaktivitaets-Update dokumentiert

MUTEC – Mobile Apps

2026-10-21T10:41:42Z

Clawtronics: YouTube-Autostart und Entfernung des Lautstaerkereglers dokumentiert

MUTEC – Mobile Apps

2026-10-21T09:59:15Z

Clawtronics: YouTube-Medienbutton mit Counter-Steuerung und Ton dokumentiert

MUTEC – Mobile Apps

2026-10-21T09:37:05Z

Clawtronics: Messages und YouTube im Medien-Tab wiederhergestellt

MUTEC – Museumsguide

2026-10-20T21:54:21Z

Clawtronics: Gestaltung und Originalbeschriftungen an BAYAM/GKP angeglichen

= MUTEC – Museumsguide / Dummy-Ausstellung =

Stand: 20.10.2026. Einstieg: MUTEC-Hauptmenü → Education → Museumsguide.
Der Guide ist unabhängig vom LED-Counter verfügbar, auch wenn dort ein Film oder Spiel läuft. Das vorhandene MegBes-Ticket bleibt die einzige Besucher-Anmeldung. Der vierstellige Stationscode ist kein Login-Code.

== Bedienung und Beispielinhalte ==

Eine Einstellungsseite fragt Sprache (Deutsch, Englisch, Französisch), Filmuntertitel und Textgröße ab. Danach öffnet die Code-Eingabe Texte, Hörbeiträge, Bilder oder Umfragen. Die Beispielsammlung verbindet Krieg, Gesellschaft und Erinnerung. Beispielcodes sind auch unter der Code-Eingabe aufklappbar.

{| class="wikitable"
! Code !! Herkunft !! Inhalt
|-
| 1100 || GKP || Unsere Geschichte
|-
| 1103 || GKP || Frieden
|-
| 3509 || GKP || Erinnerung
|-
| 2017 || GKP || Deutschland 1923 – sieben Medienbeiträge
|-
| 1003 || GKP || Umfrage: Krieg
|-
| 3004 || GKP || Umfrage: Demokratie, mit Folgefragen
|-
| 5000 || BAYAM || Krieg und Frieden
|-
| 5004 || BAYAM || Fotosammlung zum Krieg 1870/71
|-
| 5128 || BAYAM || Gerahmte Erinnerung
|-
| 5455 || BAYAM || Frieden!
|-
| 5800 || BAYAM || Wehrpflicht und Militarisierung
|}

Originaltexte, Originalaudios und Quellenangaben bleiben erhalten. Nicht alle Beiträge liegen in allen Sprachen vor; der Guide kennzeichnet die Ersatzsprache. Lokale Audios bieten Start/Pause, Neustart, Fortschrittsregler und Tempo. Keine automatische Übersetzung oder künstliche Stimme.

== JSON-Kompatibilität und neue Inhalte ==

<code>data/config.json</code> enthält die Registrierung <code>app.stationJsons</code> wie BAYAM/GKP. Die Original-JSON-Dateien sind unverändert unter <code>content/gkp/data/</code> und <code>content/bayam/data/</code> kopiert. Unterstützte Typen: <code>ati</code>, <code>pictureStack</code>, <code>poll1</code>, <code>poll2</code> einschließlich bedingter Fragen mit <code>parent</code>.

Die optionale Ergänzung <code>app.assetRoots[Stationscode]</code> legt die Medienbasis fest. Damit bleiben originale Angaben wie <code>stations/M32/M32-intro-DE.mp3</code> unverändert und beide Projekte kollidieren nicht. Ohne <code>assetRoots</code> gelten Medienpfade relativ zum Guide-Verzeichnis, wie bei den Vorlagen.

Zum Austauschen: JSON und zugehörige Medien ablegen, Eintrag in <code>stationJsons</code> ergänzen, ggf. <code>assetRoots</code> setzen. Die <code>MegBes-Nummer</code> im JSON muss dem vierstelligen Schlüssel entsprechen. <code>app.title</code>, <code>app.theme</code> und <code>app.description</code> bestimmen Ausstellungstitel und Einführung. Texte werden vor der Anzeige von aktiven HTML-Inhalten bereinigt.

== Echte MegBes-Medienstationen ==

Die importierten IPs sind bewusst '''nicht aktiv geschaltet'''. <code>app.defaultPlayerMode</code> steht auf <code>demo</code>; Beispielauswahl und Audio funktionieren ohne UDP oder Belegung eines Players. Echte Geräte werden ausdrücklich in <code>app.stationBindings</code> zugeordnet, z. B.:

<pre>
"stationBindings": {
"2017": { "mode": "native", "ip": 232 }
}
</pre>

Die tatsächliche Gerätenummer einsetzen; 232 ist nur die Adresse aus der Vorlage. Keine IP aus einem fremden Projekt ungeprüft übernehmen. <code>defaultPlayerMode: "native"</code> würde die originalen IP-Felder allgemein aktivieren und ist erst für eine entsprechend vorbereitete Ausstellung sinnvoll.

Der Guide verwendet den gemeinsamen MUTEC-Kunden und <code>EXTERNAL_SERVER_URL</code> aus <code>../js/project-const.js</code>, nicht den Backend-Kunden der Herkunftsausstellung. Standard-Endpunkte: <code>/verify</code>, <code>/media-station/status/{IP}</code>, <code>/media-station</code>, <code>/video-command</code>. Vor Anmeldung muss IDLE oder OPEN gelten, danach wird REMOTE geprüft; ein HTTP 200 allein genügt nicht. Befehle enthalten <code>prSc</code> und <code>statNoCommands</code>.

Sprach-/Untertiteloptionen entsprechen den Vorlagen, z. B. <code>232-deno</code> ohne, <code>232-dede</code> mit Untertiteln. Beitragsstart sendet das originale UDP-Feld mit IP-Präfix; Stop <code>232-stop</code>, Stationsausstieg <code>232-exit</code> und DELETE <code>/media-station</code>. Der Player muss diese vorhandenen Ausstellungssignale unterstützen und bei Ende/Timeout IDLE melden. Ein abgelaufenes Ticket kann keine neuen Stationsbefehle senden; ein Stations-Timeout bleibt daher erforderlich.

Für gekoppelte native Beiträge sind Audio-Spulen/Tempo deaktiviert: Das ursprüngliche Protokoll bietet dafür keinen bestätigten gemeinsamen Zeitgeber. Start/Stop/Neustart übernimmt die Vorgehensweise von BAYAM/GKP; exakte laufende A/V-Synchronisation ist damit nicht zugesichert. Der bestehende MUTEC-HTML-Videoplayer bleibt für synchrones Spulen verfügbar. Dieses Guide-Feature setzt keine neue BrightSign-Plugin-Version voraus.

== Umfragen ==

<code>poll.php</code> prüft ein gültiges MegBes-Ticket, den Stationstyp und die erlaubten Antworten einschließlich sichtbarer Folgefragen. Eine Stimme pro Ticket und Station; erneutes Speichern ändert sie. Es werden nur Summen und die eigene Antwort zurückgegeben. Das rohe Ticket wird nicht gespeichert.

Standard: privater Ordner im PHP-Temp-Verzeichnis, Dateirechte 0600. Für dauerhaften Ausstellungsbetrieb <code>app.privateStorage</code> auf einen PHP-schreibbaren absoluten Ordner '''außerhalb aller Web-Dokumentwurzeln''' setzen, sichern und in die Löschroutine der Ausstellung aufnehmen. Temp-Verzeichnisse können vom Hoster geleert werden. PHP 8.1+ mit cURL wird benötigt; Ticketprüfung ist auf HTTPS-Kunden unter *.megbes.de begrenzt und prüft auch die Zurückweisung eines ungültigen Tickets. Beim späteren Wechsel von tine zu messe auch <code>guide/data/config.json</code> anpassen.

== Sitzungsübernahme und Installation ==

Ein erneuter Scan desselben Tickets im selben Browserprofil übernimmt den Guide samt Station, Beitrag und Audio-Position. Der alte Tab beendet seine Audiowiedergabe und zeigt die bestehende Dankeseite. Audio startet im neuen Tab erst durch Berührung. Native Beiträge starten beim nächsten Anhören von vorn, da keine zuverlässige native Seek-Schnittstelle zugesichert ist.

Die Anpassung erweitert ausschließlich Frontend/Guide und den bestehenden Browser-Sitzungsmanager. Kein Relay-, Electron-, BrightSign- oder MegBes-Backend-Update notwendig. Originalprojekte und synced <code>sources/</code> bleiben unverändert.

[https://www.tinetronics.de/mutec/ MUTEC-Remote] · [https://www.tinetronics.de/mutec/guide/README.md Konfiguration und Inhaltsaustausch]

== Bedienung stärker an BAYAM/GKP angeglichen ==
Stand 20.10.2026: Große Bildschirm-Zifferntastatur, vier Stellen, Löschtaste und Weiter-Pfeil nur bei registriertem Stationscode. Mehrere Beiträge als Zeilen mit Titel/Dauer und getrennten Play-/Stop- sowie Text-Aufklapp-Aktionen; ein Einzelbeitrag ist sofort aufgeklappt. Textwechsel lässt laufendes Audio unverändert, Beitragswechsel beendet das vorige Audio, Stop setzt es zurück. Einstellungen ändern Sprache/Untertitel innerhalb derselben Station und erhalten die native Gerätebelegung. Verlassen laufender Wiedergabe bzw. nativer Medienstation fragt nach; Abbrechen erhält Station und Wiedergabe. Titelumbrüche werden beim Umwandeln in Klartext als Leerraum erhalten.

Frontend lokal und veröffentlicht gesichert und bytegleich geprüft. Browserprüfungen: Zifferntastatur, gültige Codes, Beitragslisten, unabhängiges Lesen/Hören, Wiedergabewechsel, Sprachwechsel ohne Stationsfreigabe, Abbruch der Rückfrage, Tab-Übernahme, Galerie, bedingte Umfragen und Textstation ohne Audio. Mobilbreiten 320/390/768 Pixel geprüft. Keine Änderungen am Relay, MegBes-Backend oder an sources/.

== Gestaltung und Beschriftungen nach BAYAM/GKP ==
Stand 20.10.2026: Helle Gestaltung nach GKP statt dunkler Karten: Hintergrund #c8cac7, Kopfbereich #adafaa, Bedienelemente #e2e4e3 und Akzent #af2421. Die mitgelieferten Univers-Regular-/Bold-Schriften werden verwendet; keine fremden Museumslogos.

Beschriftungen DE/EN direkt aus GKP data/l10n.json, fehlende Einträge und Französisch aus BAYAM data/l10n.json. Beispiele: „Bitte wählen Sie Ihre Optionen“, „Bitte 4-stellige Nummer eingeben“, „Optionen“, „Schriftgröße“, „Weiter“, „Zurück“, „Möchten Sie die Station wirklich verlassen?“, „Bleiben“ und „Verlassen“. Sprache/Schriftgröße als direkte Auswahl, Untertitel mit Ja/Nein, Dokument-Piktogramm für Textansicht. Quellenangaben bleiben aufklappbar erhalten.

Geprüft: Originaltexte und Auswahl in DE/FR, drei Sprachoptionen, Untertitel Ja/Nein, klein/normal/groß, Schrift und Hintergrund, exakte Rückfrage, bestehende Wiedergabe, Galerie, Umfragen, Tab-Übernahme und native Stationssperren. Sechs Dateien vorab gesichert, veröffentlicht und bytegleich geprüft; kein Relay-/MegBes-Backend-Update, sources/ unverändert.

MUTEC – Museumsguide

2026-10-20T21:40:19Z

Clawtronics: Bedienung an BAYAM/GKP angeglichen und geprueft

MUTEC – Mobile Apps

2026-10-20T18:45:19Z

Clawtronics: Museumsguide unter Education ergaenzt

MUTEC – Museumsguide

2026-10-20T18:45:01Z

Clawtronics: Museumsguide: Ablauf, kompatible Stationsdaten, Demo/UDP und Umfragen dokumentiert

MUTEC – Einheitliche Spiele

2026-10-18T20:45:05Z

Clawtronics: Arcade-Beitritt erfolgreich aktiviert und oeffentlich bestaetigt

= MUTEC – Einheitliche Spiele =
Stand 13.10.2026: Pong, Pöng, Papierflug und Finde den Ort haben optionale Zweispielerrunden, eigene Top-10-Listen und qualifizierte Arcade-Einträge.

== Vor und nach dem Spiel ==
Die jeweilige Liste erscheint nur auf der Electron-Anzeige vor dem Start und nach Ende. Auf dem Smartphone stehen ausschließlich das eigene Ergebnis, der Qualifikationshinweis und gegebenenfalls drei Zeichen A–Z/0–9 zum Eintragen. Während des Spiels und bei einer Verbindungspause bleiben die Listen ausgeblendet. Gemeinsame Module: <code>control/game-scores.js</code> und <code>realtime/game-scores.js</code>.

Der Server entscheidet über den Eintrag: abgeschlossene Runde, positive Punkte und Platz in der Top 10. Gleichstände werden nach kürzerer Zeit und anschließend früherem Eintrag geordnet. Beim Speichern wird die Qualifikation erneut geprüft. Ein Smartphone darf keine Punkte/Tore/Zeiten übergeben; nur <code>resultId,name</code>. Ergebnisdaten bleiben an den jeweiligen Besitzer/Gast gebunden. Gäste behalten ausschließlich Spielrechte für ihre Seite/Steuerung.

== Pong und Pöng ==
<code>Punkte = round(Tore × 1000 × 300 / (300 + aktive Spielsekunden)) + Siegbonus</code>. Siegbonus: 1000 bei sieben eigenen Toren. Intro, Countdown und Pause zählen nicht zur aktiven Zeit. Beispiel 7:3 nach 60 Sekunden: 6833 bzw. 2500 Punkte. Tore und Zeit kommen von der authentifizierten Anzeige. Beide Besucher können ihr eigenes qualifiziertes Ergebnis eintragen; die Computer-Seite wird nicht eingetragen. Je Spiel eigene Liste.

== Kartenduell ==
Spieler 1 lädt über den Smartphone-QR-Code ein; Karten-Gast unter <code>control/guest.html</code>. Beide suchen dieselbe Stadt auf eigenen Karten, mit getrennten Hint-/Zeit-/Punktewerten. Electron zeigt zwei synchronisierte Kartenausschnitte. Gemeinsame Bereitschaft und Countdown, gemeinsame Runde, getrennte Ergebnisse. Wer gefunden hat, wartet auf den Abschluss beider Teilnehmer. Keine neuen MegBes-/Stations-/UDP-Rechte für den Gast. Nur Spieler 1 darf eine Runde neu starten oder für alle beenden.

== Flight und Speicherung ==
Die vorhandene Sensor-/Kalibrierungs-/Tempo- und Ring-/Streckenwertung bleibt erhalten. Erfolgreiche Flüge können von beiden Teilnehmern eingetragen werden. Vorhandene erfolgreiche race-v1-Einträge werden in die neue Flight-Liste übernommen; <code>flight-scores.json</code> bleibt erhalten. Vier Listen atomar in <code>/opt/mutec-realtime/data/arcade-scores.json</code> gespeichert.

GET/POST <code>/mutec-control-api/game/highscores/{pong|poeng|flight|maps}</code>. POST nur eigener Ergebniszugang; keine Liste in der mobilen Antwort. POST/DELETE <code>/game/invite</code> nur Besitzer. <code>/maps/guest</code> und <code>/maps/guest/leave</code>. Rückkanäle <code>game.result</code> und <code>game.highscores</code>. Bestehende Schnittstellen bleiben für ältere Clients erhalten; Flight-Qualifikation gilt auch dort.

== Auslieferung und Prüfung ==
48 Servertests auf dem VPS und Browserprüfungen mit getrennten Besitzer-/Gast-/Display-Kontexten bestanden. Spiel-Endzustände gezielt simuliert; Karte mit lokaler Google-API-Attrappe. Keine reale Hardware wurde angesteuert. Echte Google-Karten, Mobilgeräte, LED-Lesbarkeit und natürliche Abschlüsse vor Ort prüfen.

Serverpaket unter <code>/home/clawtronics/mutec-unified-update</code> am 13.10.2026 erfolgreich installiert. Verwendeter Installationsbefehl: <code>bash /home/clawtronics/mutec-unified-update/apply-unified-update.sh</code>. Sicherung, Ausgangsstandprüfung als JSON, 48 Tests, Schreibprüfung und Rücknahme bei Fehler. Danach Smartphone- und Electron-Seiten neu laden. Bestehende Bestenlisten, Objects, HTML-Video, Ticketablauf-Wächter, DISPLAY_KEY, Umgebungsdatei und MegBes-external/-internal bleiben erhalten.

== Installation bestaetigt ==
Am 13.10.2026 erfolgreich installiert: 48 Tests, Pruefung des Ausgangsstands und Schreibpruefung bestanden. Oeffentliche API: unifiedGames=true. Relay und Ticketablauf-Waechter aktiv. Sicherung: /var/backups/mutec-realtime/unified-20261013T093334Z-1900305. Bestehende Flight-Bestenliste uebernommen; MegBes-Programme, DISPLAY_KEY und Umgebungsdatei unveraendert. Smartphone- und Electron-Seiten neu laden. Abschliessender Test mit realen Mobilgeraeten und LED-Counter vor Ort steht aus.

== Zentrierung und Eingabekorrektur vom 16.10.2026 ==
Die vier Spiele ordnen Informationen/Ergebnis und Bestenliste vor und nach der Runde untereinander auf einer gemeinsamen Mittelachse im mittleren Bildschirmbereich an. Flight blendet die Namensmaske nur noch ueber das serverseitig freigegebene Spielergebnis ein; die alte Ergebnisroutine zeigte die Maske zuvor auch ohne gueltiges offenes Ergebnis. Eingabe mit Enter oder Eintragen, Unicode-Normalisierung und Entfernen aeusserer Leerzeichen; bestehende 1-20-Zeichen-Regel bleibt erhalten. Erfolg wird sichtbar bestaetigt. Bei Fehlern bleiben Name und Ergebnis erhalten; nach 12 Sekunden gibt es eine Fehlermeldung und erneute Bedienbarkeit. Unvollstaendige/nicht qualifizierte Runden zeigen eine Erklaerung. Browserpruefung fuer alle vier Spiele mit zehn Eintraegen vor/nach bei 1920x1080 und 1376x490 bestanden; Mobile-Eingabe, HTTP-Fehler/Wiederholen und Timeout ebenfalls geprueft. 29 Frontend-Dateien gesichert und oeffentlich per Pruefsumme bestaetigt. Keine Server-/Score-Daten-Aenderung, kein root-Update. Smartphone-/Electron-Seiten neu laden; physischer LED-Test noch offen.

== Arcade-Beitritt: Here comes a new challenger, 18.10.2026 ==
Neues Ziel: mehrere gültige Tickets dürfen unabhängig angemeldet sein. Station 50 / LED-Counter bleibt genau einer normalen Steuersitzung zugeordnet. Weitere Besucher sehen bei belegtem Counter die laufende Anwendung und passende Aktionen statt einer Liste nicht startbarer Apps. Beitritt ist keine zustimmungspflichtige Anfrage mehr.

=== Besucherablauf ===
Bei freiem Counter bleiben die drei Tabs Medien / Education / Games sichtbar. Bei belegtem Counter werden die betreffenden Auswahltabs und App-Kacheln ausgeblendet. Beitretbares Spiel: nur Mitspielen. Ein Klick öffnet die Erklärung, dass der Beitritt die laufende Runde unterbricht; erst Ja, mitspielen sendet den Beitritt. Zurück schließt den Dialog ohne Auswirkung. Bestätigung eröffnet sofort eine akzeptierte Gastrolle und eine neue Zweispieler-Runde; Spieler 1 hat kein Annehmen/Ablehnen mehr. Auf seinem Smartphone und der Anzeige steht Here comes a new challenger. Bis Spieler 2 seine kurze Einführung bzw. Sensorfreigabe abgeschlossen hat, wartet das Spiel. Wenn Gastgeber, Gast und Display bereit/verbunden sind: vollständiger Countdown von drei Sekunden, dann gemeinsamer Start.

Die unterbrochene Einzelrunde wird durch eine neue gemeinsame Runde ersetzt; der Zugang und die Stationsreservierung von Spieler 1 bleiben erhalten. Der Gast kann nur seine Spielrolle steuern, keine Stationsbefehle, App-Wechsel, Neustarts oder Spielenden auslösen. Die Stationshoheit bleibt beim Gastgeber; er kann die App weiterhin selbst verlassen. Ein voller Zweispieler-Platz zeigt die Belegung ohne weiteren Beitrittsbutton. Ein Film oder 3D-Objekt zeigt eine Belegungsinfo; beim Freigeben erscheint automatisch die Auswahl wieder. Im bestehenden gemeinsamen Farbraum ist Gemeinsam malen die passende Aktion (bis 24 Personen). Der separate neue Farben-Spielmodus nutzt wie die vier bisherigen Spiele den Challenger-Beitritt. Vorhandene Aqua-Editor-/Stationsregeln wurden nicht umgebaut.

=== Schnittstellen und Grenzen ===
GET /station/availability prüft das Besucherticket und den aktuellen MegBes-Stationszustand, liefert station=50, Label, App, Belegung und erlaubte Beitritts-/Gemeinschaftsaktion. Keine Ticket-/Steuertoken oder Besucheridentitäten im Ergebnis. Menü fragt sichtbar alle 2,5 Sekunden und bei Rückkehr in den Tab ab. POST /game/challenge akzeptiert ausschließlich feature und die konkrete gameId; dieselbe Zugangskontrolle wie vorher, serielle Reservierung gegen doppelte Gäste. Veraltete Partie oder App-Wechsel werden abgewiesen. Dasselbe Ticket kann seinen noch vorhandenen Gastzugang wieder abrufen, ohne erneut zu unterbrechen. Der alte Anfrage-Endpunkt bleibt für bereits geladene ältere Frontends kompatibel; alle Seiten nach Aktivierung neu laden.

Lobby-Snapshot hat challenger=true für die neue Übernahme. Der erste Gastgeber muss seine Steuerung weiterhin vorbereiten, wenn er noch im Intro war. Gastbereitschaft startet erst mit allen Verbindungen. Abbruch und Timeout geben nur den Gastplatz frei, keine Trailer-/Stationsabmeldung. Erste Gastvorbereitung maximal 90 Sekunden, ungebundener bzw. verlorener Gastzugang weiterhin 15 Sekunden. Nach einmaliger Vorbereitung greift die 90-Sekunden-Frist bei späteren Wiederverbindungen/Revanchen nicht erneut. Ticketwiderruf, Sessionablauf und Gastgeberverlust behalten die bestehenden Schutzregeln. Challenger-Anzeige in der mittleren Bildschirmhälfte, mit horizontaler LED-Vorverzerrung.

=== Prüfung und Installation ===
194 Tests lokal und auf Linux/VPS bestanden, basierend auf den tatsächlich laufenden Servermodulen einschließlich des neuen Farben-Spiels. Geprüft für Pong, Pöng, Flight, Ortssuche und Farben-Spiel: sofortige Annahme nach Bestätigung, kein Gastgeber-Veto, verpflichtende Vorbereitung, vollständiger Countdown, zwei gleichzeitige Gäste, Wiederholung, voller Platz, Abbruch/Timeout, Wiederverbindung, falsches/abgelaufenes Ticket, falsche Partie und fehlende Stationsrechte. HTTP-Status und Challenge-Endpunkt authentifiziert geprüft. Browser mit echtem isoliertem Relay: Pong/Pöng einschließlich laufendem Solo, Bestätigungsabbruch ohne Unterbrechung, Smartphone-/Display-Meldung, Gastintro, Countdown, dritter Besucher, Gastausstieg und freier Auswahl. Zusätzlich Video, Objects und gemeinsamer Farbraum; öffentliche Website mit simulierten Statusdaten geprüft. Keine echte Station gesteuert.

52 Frontend-Dateien gesichert und öffentlich bytegleich hochgeladen. Aktivierung ist über challengerArcade in capabilities abgesichert: solange das Relay nicht aktualisiert ist, gilt weiterhin der bisherige Ablauf. Serverpaket auf /home/clawtronics/mutec-challenger-update bereit; als root bei freier Station 50 ausführen: bash /home/clawtronics/mutec-challenger-update/apply-challenger-update.sh. Installer prüft Paket, Tests und SHA-Ausgangsstand aller Servermodule vor Änderungen, sichert die ersetzten Dateien und hat Rollback. Ersetzt nur server.js, pong-guests.js, game-lobby.js und den neuen Test. DISPLAY_KEY, Umgebungsdatei, Bestenlisten, MegBes-Programme, vorhandene Farben-Spielmodule und synced sources/ bleiben erhalten. Root-Aktivierung bei Dokumentation noch ausstehend. Danach Smartphone-Seiten und Electron-Webseiten neu laden; physischer Messestandtest noch erforderlich.

Artefakte im bisherigen Codex-Arbeitsordner outputs/: MUTEC-Challenger-server.tar.gz, zugehörige SHA-Datei, apply-challenger-update.sh, MUTEC-Challenger-VPS-Test.txt, MUTEC-Challenger-Frontend.zip, MUTEC-Challenger-Installation.json und MUTEC-Challenger-Browserpruefung.json. Geprüfter Relay-Quellstand im Arbeitsordner work/challenger-stage/realtime; nicht blind aus älteren Frontendpaketen gemeinsame Session-/Client-Dateien überschreiben.

== Arcade-Beitritt aktiviert, 18.10.2026 ==
Root-Installation erfolgreich abgeschlossen: 194 Tests bestanden, Relay und Ablauf-Wächter aktiv. Health meldet challengerArcade=true; auch die öffentliche capabilities-Schnittstelle mit dem erlaubten Website-Origin wurde nach der Installation mit challengerArcade=true geprüft. Der zuvor als ausstehend dokumentierte Arcade-Ablauf ist damit aktiviert. Serversicherung: /var/backups/mutec-realtime/challenger-20261018T204434Z-3580490. Smartphone-Seiten und Electron-Webseiten neu laden. Physischer Test mit zwei Mobilgeräten am Counter bleibt noch durchzuführen.

MUTEC – Spielablauf

2026-10-18T20:45:05Z

Clawtronics: Arcade-Beitritt erfolgreich aktiviert und oeffentlich bestaetigt

= MUTEC – Spielablauf =
Stand 11.10.2026. Das Frontend trennt Einführung, Bedienung/Spiel und Ergebnis. Gemeinsame Kartenmodule: <code>control/flow.js</code>, <code>flow.css</code>, <code>paddle-flow.js</code>. Karten enthalten ein SVG-Piktogramm, kurzen Text und „Verstanden, weiter“.

== Papierflug ==
Sensoren erlauben oder Touch wählen → Haltung kalibrieren bzw. Touch-Erklärung → Flugstart mit Steuerungswahl. Im Spiel nur aktuelle Steuerung, Punkte/Zeit und Neustart/Ende. Ergebnis: Punkte/Ringe, dreistelliger Arcade-Name, Bestenliste, neue Runde. Vorzeitiges Ende verwendet ausschließlich die bis dahin vom Display erzielten Punkte.

== Pong und Pöng: zweiter Spieler ==
QR-Code öffnet direkt die Gast-Infokarten. Die Gastanmeldung erzeugt eine Anfrage; der Computer spielt weiter. Spieler 1 kann „Spiel unterbrechen & annehmen“ oder „Jetzt nicht“ wählen. Annahme bereitet eine neue Zweispielerpartie vor. Beide melden Bereitschaft; erst mit beiden Verbindungen und der Anzeige startet ein gemeinsamer Countdown 3–2–1. Für eine Wiederholung melden sich beide erneut bereit; die Reihenfolge ist egal. Ohne verbundene Teilnehmer startet keine Partie.

Gasttrennung pausiert die Zweispielerpartie. Wiederverbindung erfordert erneute Bereitschaft nach der Einführung. Nach 15 Sekunden ohne Gastverbindung wird der rechte Platz frei; der Computer übernimmt mit Countdown. Eine ausdrückliche Gastabmeldung beendet nur den Gastzugang. Die Station bleibt für Spieler 1 reserviert.

<code>game.lobby</code> vom Smartphone enthält ausschließlich <code>action,id</code>. Gäste dürfen nur <code>ready</code>. <code>accept,reject,restart,end</code> bleiben dem Besitzer vorbehalten. Vor Annahme leitet der Relay keinen Gast-Schläger an die Anzeige weiter. Rückkanal: <code>gameId,roundId,phase,hostReady,guestReady,guestPending,guestAccepted,guestConnected,startAt,serverAt</code>. Keine neuen MegBes-/UDP-/Ticket-Rechte für Gäste. Der Ablauf wird in <code>realtime/game-lobby.js</code> verwaltet.

== Weitere Angebote ==
Finde den Ort: Einführung → Suche → Ergebnis mit Stadt, Punkten, Zeit und Hinweisen. Abbruch und neue Suche sind möglich. Aquarium: Einführung → gestalten/speichern/steuern → Schlusskarte mit dem eigenen Tier. HTML-Video: Einführung → vorhandene synchronisierte Filmsteuerung → Schlusskarte nach Filmende. Medienauswahl erhält ebenfalls eine kurze Einführung.

== Bestenliste und Dienst ==
Die bisherige Meldung „Dienst nicht verfügbar“ beim Eintragen wurde auf den strengen systemd-Dateisystemschutz eingegrenzt: Das Ergebnisverzeichnis gehörte bereits dem Dienstbenutzer, war im Dienst aber schreibgeschützt. Das vorbereitete Update ergänzt ausschließlich <code>ReadWritePaths=/opt/mutec-realtime/data</code> unter <code>/etc/systemd/system/mutec-realtime.service.d/highscores.conf</code>. Bestehende Ergebnisse bleiben erhalten. Eine echte Schreib-/Lese-/Löschprüfung unter dem Dienstbenutzer und strengem Dateisystemschutz erfolgt im Installer. Schreibfehler verwerfen ein noch nicht gespeichertes Ergebnis nicht; der Besucher kann erneut eintragen.

== Auslieferung und Prüfung ==
Serverpaket: <code>/home/clawtronics/mutec-flow-update</code>. Als root bei freier Station 50: <code>bash /home/clawtronics/mutec-flow-update/apply-flow-update.sh</code>. 32 Servertests auf dem VPS bestanden; Installer mit Sicherung/Rücknahme. Frontend-Dateien separat über den bestehenden Webserverzugang. Fähigkeiten <code>gameFlow:true</code> nach Installation. Bis dahin informiert der letzte Spiele-Intro-Schritt über die noch ausstehende Servereinrichtung.

Browserprüfung mit getrennten Besitzer-/Gast-/Display-Kontexten: Beitritt ohne Unterbrechung, Zustimmung, Bereitschaft, Countdown, Neustart, Ende. Papierflug mit Touch und simulierten Sensordaten sowie lokalem Arcade-Eintrag über echten WebSocket. Ortssuche mit lokaler Kartenattrappe; Aquarium/Video/Medien mit Einführung und Hauptansicht. Diese Prüfungen steuern keine reale MegBes-Hardware. Echte Mobilgeräte, LED-Counter und produktiver Arcade-Eintrag bleiben vor Ort zu prüfen.

MegBes-external/-internal, DISPLAY_KEY und Relay-Umgebungsdatei werden nicht geändert. Der bestehende Ticketablauf-Wächter bleibt aktiv. Smartphone-Seiten und Electron-Webseiten nach Installation neu laden.

== Installation bestätigt ==
Der Administrator hat das Update am 11.10.2026 installiert: 32 Tests bestanden, echte Bestenlisten-Schreibprüfung unter Dienst-Schutz bestanden. ReadWritePaths=/opt/mutec-realtime/data aktiv; NeedDaemonReload=no. Relay und Ticketablauf-Wächter aktiv. Öffentliche Fähigkeiten bestätigen gameFlow:true. Sicherung: /var/backups/mutec-realtime/flow-20261011T202430Z-176562. Die während der Installation erschienene Warnung über geänderte Dienstdateien wurde durch das anschließende daemon-reload erledigt. Smartphone-Seiten und Electron-Webseiten neu laden; echte Sensoren, LED-Darstellung und produktiven Flug-Eintrag vor Ort prüfen.

== Mobile Pong-Einladung ==
Stand 12.10.2026: Für Pong und Pöng wurde der QR-Code vom LED-Counter auf das Smartphone von Spieler 1 verlegt. Der Counter enthält kein QR-/Einladungspanel mehr; seine Punkteanzeige liegt mittig. Letzte Infokarte: '1 Spieler starten' gegen den Computer oder '2 Spieler' für einen großen unverzerrten QR-Code auf dem eigenen Smartphone. Nach ausdrücklicher Zweispielerwahl im Intro und Gastbeitritt gilt die Einladung bereits als Zustimmung. Bei einer späteren Einladung über den 2-Spieler-Button im laufenden Spiel bleibt die Computerrunde bis zur ausdrücklichen Annahme erhalten. Gast-Infokarten, Bereitschaft und Countdown bleiben bestehen. Gäste erhalten keine weiteren MegBes-Rechte.

Neue Relay-Route POST /mutec-control-api/pong/invite: Nur der aktuelle Besitzer seiner eigenen Pong-/Pöng-Sitzung darf eine kurzlebige einmalige Einladung abrufen. Gäste, fremde Module und abgelaufene Sitzungen sind ausgeschlossen. Der Display-Schlüssel wird nicht an das Smartphone übergeben. Frontend hochgeladen und Browserprüfung mit getrennten Smartphones/Display bestanden. Serverpaket unter /home/clawtronics/mutec-invite-update vorbereitet; 38 Tests auf dem VPS bestanden. Root-Installation steht noch aus: bash /home/clawtronics/mutec-invite-update/apply-invite-update.sh. Der Installer sichert und ersetzt nur server.js und den Relay-Test, prüft den unveränderten Ausgangsstand und startet den Relay neu. Flight-Wettbewerb, Bestenlisten, Ticketablauf-Wächter, DISPLAY_KEY und MegBes-external/-internal bleiben erhalten. Danach Smartphone-Seiten und Electron-Webseiten neu laden.

== Einheitliche Spiele und Bestenlisten ==
Stand 13.10.2026: [[MUTEC – Einheitliche Spiele]] dokumentiert optionale Zweispielerrunden auch für Finde den Ort, vier getrennte Top-10-Listen ausschließlich auf der Electron-Anzeige vor/nach dem Spiel und eigene qualifizierte Arcade-Einträge für Besitzer/Gast. Pong/Pöng werten Tore und aktive Zeit mit Siegbonus. Die vorhandene Flight-Wertung und die Karte mit getrennten Kameras/Hinweisen bleiben erhalten. Frontend hochgeladen und geprüft; 48 Servertests auf dem VPS bestanden. Serverpaket unter /home/clawtronics/mutec-unified-update am 13.10.2026 erfolgreich installiert; alle 48 Tests und die Schreibpruefung bestanden. Die oeffentliche API meldet unifiedGames=true; Relay und Ticketablauf-Waechter sind aktiv. Daten, Schlüssel, Objects, HTML-Video und MegBes-Programme bleiben erhalten.

== Zentrierung und Eingabekorrektur vom 16.10.2026 ==
Die vier Spiele ordnen Informationen/Ergebnis und Bestenliste vor und nach der Runde untereinander auf einer gemeinsamen Mittelachse im mittleren Bildschirmbereich an. Flight blendet die Namensmaske nur noch ueber das serverseitig freigegebene Spielergebnis ein; die alte Ergebnisroutine zeigte die Maske zuvor auch ohne gueltiges offenes Ergebnis. Eingabe mit Enter oder Eintragen, Unicode-Normalisierung und Entfernen aeusserer Leerzeichen; bestehende 1-20-Zeichen-Regel bleibt erhalten. Erfolg wird sichtbar bestaetigt. Bei Fehlern bleiben Name und Ergebnis erhalten; nach 12 Sekunden gibt es eine Fehlermeldung und erneute Bedienbarkeit. Unvollstaendige/nicht qualifizierte Runden zeigen eine Erklaerung. Browserpruefung fuer alle vier Spiele mit zehn Eintraegen vor/nach bei 1920x1080 und 1376x490 bestanden; Mobile-Eingabe, HTTP-Fehler/Wiederholen und Timeout ebenfalls geprueft. 29 Frontend-Dateien gesichert und oeffentlich per Pruefsumme bestaetigt. Keine Server-/Score-Daten-Aenderung, kein root-Update. Smartphone-/Electron-Seiten neu laden; physischer LED-Test noch offen.

== Zweispieler-Prüfung vom 16.10.2026 ==
[[MUTEC – Zweispieler-Prüfung]] dokumentiert die 125 bestandenen Servertests, die tatsächlich sichtbaren Optionen beider Spieler und drei noch offene Oberflächenfehler. Keine Änderung des Produktivsystems durch diese Prüfung.

== Arcade-Beitritt: Here comes a new challenger, 18.10.2026 ==
Neues Ziel: mehrere gültige Tickets dürfen unabhängig angemeldet sein. Station 50 / LED-Counter bleibt genau einer normalen Steuersitzung zugeordnet. Weitere Besucher sehen bei belegtem Counter die laufende Anwendung und passende Aktionen statt einer Liste nicht startbarer Apps. Beitritt ist keine zustimmungspflichtige Anfrage mehr.

=== Besucherablauf ===
Bei freiem Counter bleiben die drei Tabs Medien / Education / Games sichtbar. Bei belegtem Counter werden die betreffenden Auswahltabs und App-Kacheln ausgeblendet. Beitretbares Spiel: nur Mitspielen. Ein Klick öffnet die Erklärung, dass der Beitritt die laufende Runde unterbricht; erst Ja, mitspielen sendet den Beitritt. Zurück schließt den Dialog ohne Auswirkung. Bestätigung eröffnet sofort eine akzeptierte Gastrolle und eine neue Zweispieler-Runde; Spieler 1 hat kein Annehmen/Ablehnen mehr. Auf seinem Smartphone und der Anzeige steht Here comes a new challenger. Bis Spieler 2 seine kurze Einführung bzw. Sensorfreigabe abgeschlossen hat, wartet das Spiel. Wenn Gastgeber, Gast und Display bereit/verbunden sind: vollständiger Countdown von drei Sekunden, dann gemeinsamer Start.

Die unterbrochene Einzelrunde wird durch eine neue gemeinsame Runde ersetzt; der Zugang und die Stationsreservierung von Spieler 1 bleiben erhalten. Der Gast kann nur seine Spielrolle steuern, keine Stationsbefehle, App-Wechsel, Neustarts oder Spielenden auslösen. Die Stationshoheit bleibt beim Gastgeber; er kann die App weiterhin selbst verlassen. Ein voller Zweispieler-Platz zeigt die Belegung ohne weiteren Beitrittsbutton. Ein Film oder 3D-Objekt zeigt eine Belegungsinfo; beim Freigeben erscheint automatisch die Auswahl wieder. Im bestehenden gemeinsamen Farbraum ist Gemeinsam malen die passende Aktion (bis 24 Personen). Der separate neue Farben-Spielmodus nutzt wie die vier bisherigen Spiele den Challenger-Beitritt. Vorhandene Aqua-Editor-/Stationsregeln wurden nicht umgebaut.

=== Schnittstellen und Grenzen ===
GET /station/availability prüft das Besucherticket und den aktuellen MegBes-Stationszustand, liefert station=50, Label, App, Belegung und erlaubte Beitritts-/Gemeinschaftsaktion. Keine Ticket-/Steuertoken oder Besucheridentitäten im Ergebnis. Menü fragt sichtbar alle 2,5 Sekunden und bei Rückkehr in den Tab ab. POST /game/challenge akzeptiert ausschließlich feature und die konkrete gameId; dieselbe Zugangskontrolle wie vorher, serielle Reservierung gegen doppelte Gäste. Veraltete Partie oder App-Wechsel werden abgewiesen. Dasselbe Ticket kann seinen noch vorhandenen Gastzugang wieder abrufen, ohne erneut zu unterbrechen. Der alte Anfrage-Endpunkt bleibt für bereits geladene ältere Frontends kompatibel; alle Seiten nach Aktivierung neu laden.

Lobby-Snapshot hat challenger=true für die neue Übernahme. Der erste Gastgeber muss seine Steuerung weiterhin vorbereiten, wenn er noch im Intro war. Gastbereitschaft startet erst mit allen Verbindungen. Abbruch und Timeout geben nur den Gastplatz frei, keine Trailer-/Stationsabmeldung. Erste Gastvorbereitung maximal 90 Sekunden, ungebundener bzw. verlorener Gastzugang weiterhin 15 Sekunden. Nach einmaliger Vorbereitung greift die 90-Sekunden-Frist bei späteren Wiederverbindungen/Revanchen nicht erneut. Ticketwiderruf, Sessionablauf und Gastgeberverlust behalten die bestehenden Schutzregeln. Challenger-Anzeige in der mittleren Bildschirmhälfte, mit horizontaler LED-Vorverzerrung.

=== Prüfung und Installation ===
194 Tests lokal und auf Linux/VPS bestanden, basierend auf den tatsächlich laufenden Servermodulen einschließlich des neuen Farben-Spiels. Geprüft für Pong, Pöng, Flight, Ortssuche und Farben-Spiel: sofortige Annahme nach Bestätigung, kein Gastgeber-Veto, verpflichtende Vorbereitung, vollständiger Countdown, zwei gleichzeitige Gäste, Wiederholung, voller Platz, Abbruch/Timeout, Wiederverbindung, falsches/abgelaufenes Ticket, falsche Partie und fehlende Stationsrechte. HTTP-Status und Challenge-Endpunkt authentifiziert geprüft. Browser mit echtem isoliertem Relay: Pong/Pöng einschließlich laufendem Solo, Bestätigungsabbruch ohne Unterbrechung, Smartphone-/Display-Meldung, Gastintro, Countdown, dritter Besucher, Gastausstieg und freier Auswahl. Zusätzlich Video, Objects und gemeinsamer Farbraum; öffentliche Website mit simulierten Statusdaten geprüft. Keine echte Station gesteuert.

52 Frontend-Dateien gesichert und öffentlich bytegleich hochgeladen. Aktivierung ist über challengerArcade in capabilities abgesichert: solange das Relay nicht aktualisiert ist, gilt weiterhin der bisherige Ablauf. Serverpaket auf /home/clawtronics/mutec-challenger-update bereit; als root bei freier Station 50 ausführen: bash /home/clawtronics/mutec-challenger-update/apply-challenger-update.sh. Installer prüft Paket, Tests und SHA-Ausgangsstand aller Servermodule vor Änderungen, sichert die ersetzten Dateien und hat Rollback. Ersetzt nur server.js, pong-guests.js, game-lobby.js und den neuen Test. DISPLAY_KEY, Umgebungsdatei, Bestenlisten, MegBes-Programme, vorhandene Farben-Spielmodule und synced sources/ bleiben erhalten. Root-Aktivierung bei Dokumentation noch ausstehend. Danach Smartphone-Seiten und Electron-Webseiten neu laden; physischer Messestandtest noch erforderlich.

Artefakte im bisherigen Codex-Arbeitsordner outputs/: MUTEC-Challenger-server.tar.gz, zugehörige SHA-Datei, apply-challenger-update.sh, MUTEC-Challenger-VPS-Test.txt, MUTEC-Challenger-Frontend.zip, MUTEC-Challenger-Installation.json und MUTEC-Challenger-Browserpruefung.json. Geprüfter Relay-Quellstand im Arbeitsordner work/challenger-stage/realtime; nicht blind aus älteren Frontendpaketen gemeinsame Session-/Client-Dateien überschreiben.

== Arcade-Beitritt aktiviert, 18.10.2026 ==
Root-Installation erfolgreich abgeschlossen: 194 Tests bestanden, Relay und Ablauf-Wächter aktiv. Health meldet challengerArcade=true; auch die öffentliche capabilities-Schnittstelle mit dem erlaubten Website-Origin wurde nach der Installation mit challengerArcade=true geprüft. Der zuvor als ausstehend dokumentierte Arcade-Ablauf ist damit aktiviert. Serversicherung: /var/backups/mutec-realtime/challenger-20261018T204434Z-3580490. Smartphone-Seiten und Electron-Webseiten neu laden. Physischer Test mit zwei Mobilgeräten am Counter bleibt noch durchzuführen.

MUTEC – Mobile Apps

2026-10-18T20:45:05Z

Clawtronics: Arcade-Beitritt erfolgreich aktiviert und oeffentlich bestaetigt

MUTEC – Einheitliche Spiele

2026-10-18T20:44:18Z

Clawtronics: Arcade-Challenger mit Belegungsanzeige vorbereitet, 194 Tests; Root-Aktivierung ausstehend

MUTEC – Spielablauf

2026-10-18T20:44:18Z

Clawtronics: Arcade-Challenger mit Belegungsanzeige vorbereitet, 194 Tests; Root-Aktivierung ausstehend

MUTEC – Mobile Apps

2026-10-18T20:44:17Z

Clawtronics: Arcade-Challenger mit Belegungsanzeige vorbereitet, 194 Tests; Root-Aktivierung ausstehend

MUTEC – Mobile Apps

2026-10-18T20:26:12Z

Clawtronics: Login-Abhaengigkeiten und Tab-Uebernahme mit Farben-App zusammengefuehrt

MUTEC – Mobile Apps

2026-10-18T15:27:14Z

Clawtronics: Browser-Tab-Uebernahme fuer bestehende Steuersitzungen

MUTEC – Mobile Apps

2026-10-18T10:35:34Z

Clawtronics: LinkedIn ersetzt allgemeinen Teilen-Button

MUTEC – Mobile Apps

2026-10-18T10:31:15Z

Clawtronics: Nur Hauptmenue-Beitritt und kompakte Intros aktiviert

MUTEC – Mobile Apps

2026-10-18T10:25:02Z

Clawtronics: Mobile-Texte, direkte Social-Icons und abgesicherte Trailer-Rueckkehr

MUTEC – HTML-Video

2026-10-18T10:05:17Z

Clawtronics: Drei Mobile-Tabs, neun HTML-Filme und Beitritt direkt in App-Kachel veroeffentlicht

= MUTEC: HTML-Video mit Smartphone-Ton =
Stand 10.10.2026. Neues Feature '''video''' mit führendem HTML-Video in Electron und synchronisierter Audioausgabe auf dem Smartphone. Frontend hochgeladen, Electron-Reiter konfiguriert, Relay-Paket bereitgestellt und mit 20 Tests auf dem VPS geprüft. Relay durch root installiert, öffentliche Freigabe video:true geprüft. Abnahme am Counter mit echtem Film steht aus. Kein Eingriff in megbes-external/megbes-internal.

== Aktivieren ==
Als root auf dem VPS: <code>bash /home/clawtronics/mutec-video-update/apply-video-update.sh</code>. Installer sichert bestehende Relay-Dateien und prüft nach Neustart <code>video:true</code>. Electron neu starten. Neues Angebot wird im MUTEC-Menü erst nach dieser Relay-Aktivierung sichtbar. Auswahl reserviert Station 50 exklusiv und sendet <code>166-video</code>, danach <code>50-maps</code>. „Zur Auswahl“ sendet <code>50-Trailer</code> und gibt die Station frei. Anzeige: https://www.tinetronics.de/mutec/video/display.html mit bestehendem privaten Display-Schlüssel in der Electron-Konfiguration; Schlüssel nie im Wiki dokumentieren.

== Bedienung ==
Smartphone: Film, Start/Pause, Zeitleiste, ±10 Sekunden, Kapitel, Sprache, lokale Lautstärke. Tonfreigabe erfolgt per Nutzer-Klick. Erstes Angebot ist ein 60-Sekunden-Testfilm mit sichtbarem Takt und zwei Prüfton-Spuren, keine Sprachaufnahme. Wasser ist als erster echter Film eingebunden und als Standard ausgewählt. Unter „Bild und Ton abstimmen“ Audio-Verzögerung von −2000 bis +3000 ms einstellen; positiver Wert verzögert Audio. Lokal im Browser gespeichert.

== Synchronisation ==
Die tatsächliche Abspielposition in Electron führt. Alle 250 ms meldet die Anzeige Position, Dauer, Pause/Pufferung, Status und letzte ausgeführte Befehls-ID. RTT-Uhrabgleich über den Relay erzeugt eine gemeinsame Zeitbasis. Smartphone extrapoliert die Position bis jetzt; bei mehr als 350 ms Drift springt Audio zur Zielposition, bei mehr als 60 ms korrigiert es sanft mit maximal ±2 Prozent Geschwindigkeit. Audio stoppt bei mehr als 1,5 Sekunden alten Zeitdaten; Film stoppt bei mehr als 1,6 Sekunden fehlendem/ inaktivem Smartphone-Heartbeat. Audio-Pufferung hält den Film an, Video-Pufferung hält Audio an. Bei Verbindungsverlust explizit erneut starten. Sprachwechsel richtet die neue Spur am aktuellen Film aus.

Bildgenaue Synchronität über Mobilfunk ist nicht garantiert. HDMI-/LED-Verarbeitung und Kopfhörer verursachen zusätzliche Verzögerung, die vor Ort abzustimmen ist. Angezeigte Drift ist die Browser-Zeitabweichung, nicht die tatsächlich wahrnehmbare Latenz am LED-Counter. Alle Sprachspuren müssen denselben Schnitt, Nullpunkt und Zeitablauf wie das Bild haben. Abweichende Dauer wird gemeldet; endet Audio zu früh, wird angehalten.

== Dateien und Protokoll ==
* <code>video/catalog.json</code>: freigegebene Filmkennungen, Video-URLs, Sprachspuren, Kapitelzeiten in Sekunden. Relative Pfade zu /mutec/video/; externe Medien per HTTPS. MP4 mit H.264 und faststart; Hosting mit Byte-Range-Unterstützung. Eigene Filme lassen sich ohne Relay-Codeänderung hinzufügen.
* <code>video/display.js</code>: führender stummer Video-Player; <code>video/controller.js</code>: Smartphone-Steuerung/Audio; <code>video/sync.js</code>: Zeitabgleich und Driftkorrektur; <code>video/catalog.js</code>: validierte Medienkonfiguration.
* Feature <code>video</code>, neue zufällige <code>playbackId</code> je Ticket-Sitzung. <code>video.command</code> erlaubt ausschließlich select, play, pause und seek; keine Besuchereingabe beliebiger Medien-URLs. <code>video.listener</code> meldet active/ready; <code>video.status</code> kommt nur von der authentisierten führenden Anzeige. <code>video.clock</code> gleicht die Zeit ab.
* Nur eine Video-Anzeige als Zeitquelle; zweite Anmeldung wird abgewiesen. Fremde Features, Pong-Gäste, alte Sitzungen und beliebige UDP-Befehle können nicht steuern. Kein Wiederabspielen alter Steuerimpulse.
* Anzeige nutzt gemeinsame LED-Entzerrung mit horizontaler Breite 60 Prozent, Smartphone bleibt unverändert. Videobild wird proportional eingepasst.

== Prüfung ==
20 Relay-Tests einschließlich Karten/Trailer/Papierflug/Pong, vier unabhängige Sync-Tests. Browserprobe mit zwei Ansichten: Start/Pause, Kapitel laufend/pausiert, Sprachwechsel, Zeitnachführung und Stopp beim Schließen der Steuerung. Keine Hardwarebefehle in Tests. Abnahme mit echtem Video, Smartphone, LED-Counter und verwendeten Kopfhörern ausstehend.

== Wasser ==
Wasser.mp4 ist als erste Auswahl im Katalog eingebunden. Video: H.264, 1376 × 430 Pixel, 97 Sekunden, faststart. Smartphone-Ton: audios/WasserDE.mp3 und audios/WasserEN.mp3, jeweils etwa 97,07 Sekunden. Film und beide Tonspuren auf dem Webserver veröffentlicht. Start-Kapitel vorhanden; weitere inhaltliche Kapitel noch nicht festgelegt. Synchronisation am realen Counter mit gewählten Kopfhörern abstimmen. Kein Relay-Update erforderlich; Electron und Smartphone-Steuerseite neu laden.

== Spulkorrektur 11.10.2026 ==
Absichtliche AbortError-Abbrüche bei Pause oder Spulen verlieren nicht mehr die Audio-Freigabe und erzeugen keinen Filmfehler. Audio lädt die neue Zielposition auch während Pufferung; seeked und canplaythrough aktualisieren die Bereitschaft. Konkurrierende Startanfragen während eines Sprungs werden vermieden. Laufend/pausiert bleibt erhalten. Vier neue Regressionstests und vier Sync-Prüfungen bestanden. Frontend hochgeladen, Kennung 20261011-video2. Electron und Smartphone neu laden; kein Relay-Update. Abnahme am realen Smartphone ausstehend.

== Mobile-Auswahl vom 18.10.2026 ==
Die Besucherauswahl unter hub.html hat drei Tabs. Wasser · BrightSign ist vorerst nicht mehr angeboten; die unreife native Funktion und die MegBes-Programme wurden nicht entfernt oder geaendert.

{| class="wikitable"
! Tab !! Angebote
|-
| Medien || Drotschmann, Wasser, 001 Katzen, 002 Neon, 003 Monkeys, 004 KI-Material, 005 Visuals, 006 Katzen, 007 KI-Material
|-
| Education || 3D-Objekte und Aquarium
|-
| Games || Pong, Poeng, Flight, Farbenspektakel und Finde den Ort
|}

Medien nutzt die vorhandenen Film-Icons. Ein Klick oeffnet direkt die HTML-Wiedergabesteuerung des gewaehlten Beitrags, ohne erneut die Video-Infokarten zu durchlaufen. Der Film startet erst nach der Tonfreigabe/Startaktion. Dropdown enthaelt alle neun Beitraege; Start/Pause, Zeitleiste, +/-10 Sekunden, Lautstaerke und die vorhandenen Sprachen bleiben verfuegbar. Inhaltliche Kapitel wurden mangels Quelldaten nicht erfunden; Start-Kapitel fuer jeden Film. Wasser und Drotschmann Deutsch/Englisch, uebrige Beitraege Originalton.

=== Belegung und Beitritt ===
Scheitert der App-Start an einem belegten Monitor und ein Spiel ist beitretbar, zeigt genau die soeben angeklickte Kachel einen roten Rand, die Meldung Spieler 1 spielt gerade [Name des tatsaechlich laufenden Spiels] und einen gruenen Button Beitritt anfragen. Kein globaler Beitrittsbutton mehr im Ticketstatus. Haupt- und Gastaktion sind getrennte Buttons innerhalb einer sichtbaren Kachel, keine unzulaessig verschachtelten Buttons. Bei anderem laufendem Spiel nennt der Hinweis dessen Namen; die Anfrage richtet sich an dieses Spiel. Bei nicht beitretbaren Angeboten erscheint kein Gastbutton. Fehlversuche bleiben lokal sichtbar und wiederholbar.

Beim Gastgeber sind Beitrittsanfragen in Pong/Poeng, Flight und Ortssuche nun rot hinterlegt; Annehmen ist gruen. Rechte und Ticket-/Gastpruefungen unveraendert.

=== Webmedien und Ton ===
Die alten MP3s fuer 001–007 haben andere Laufzeiten/Schnitte als die nun bereitgestellten MP4s. Sie werden fuer diese HTML-Beitraege nicht verwendet. Neue passende AAC-Spuren stammen direkt aus den sieben MP4s. Drotschmann verwendet die bekannten DE/EN-Spuren, auf 134.4 s vereinheitlicht; die etwas kuerzere EN-Spur wird hinten mit Stille aufgefuellt. Wasser behielt seine erprobten MP3-Spuren.

Acht Webvideo-Ableitungen (H.264 CRF20, unveraenderte Aufloesung/Bildrate, Faststart, stummes Bild) plus neun passende Audio-Dateien liegen unter video/media/web-20261018/. Insgesamt 17 Dateien und ca. 473 MB. Originalvideos unter video/media/ und alte Audiodateien bleiben unveraendert. Alle neuen Dateien serverseitig per SHA-256 und oeffentlich per HTTP-Range geprueft. Bestehender WebSocket-Uhr-/Playerabgleich bleibt erhalten. Korrektur beim Seek exakt ans Ende: Film beendet bleibt erhalten, statt danach wieder in Pausiert zu wechseln.

=== Validierung und Installation ===
Alle neun echten Film-/Audio-Paare lokal im Browser ueber ihre Menuekachel gewaehlt, abgespielt und bis Mitte/Anfang/Ende gespult; Sprachwechsel bei Wasser/Drotschmann. Dropdown-Wechsel innerhalb derselben Sitzung zu Wasser und Monkeys geprueft. Menuepruefung mit vier echten Gastanfragen am isolierten Relay, Fehler/Wiederholen und Gastgeberfarben. 320/390/768/1280 Pixel ohne horizontalen Ueberlauf, Tabs mit Pfeilen/Home/End, sichtbare Bedienflaechen mindestens 44 Pixel. Bestehende neun Film-Icons auf dem Webserver bestaetigt. Neue Frontenddateien vorab gesichert und nach Veroeffentlichung oeffentlich bytegleich geprueft.

Die lokale Pruefung nutzt echte Player/Medien und Relay mit simuliertem MegBes-Upstream; dabei keine Hardwarebefehle und keine echte Stationsreservierung. Oeffentlicher Browser-Nachtest prueft die Seite read-only und die ticketfreie Filmvorschau. Physischer LED-/Mobilfunk-/Kopfhoerertest bleibt erforderlich.

Smartphone-Seiten neu laden; Electron oder seinen Video-Reiter neu laden, damit der neue Katalog und Player eingelesen werden. Kein Relay-/root-Update erforderlich. Synced sources/ unveraendert. Nachweise im Codex-Arbeitsordner: outputs/MUTEC-Menue-Installation.json, MUTEC-Menue-Umstellung.md, MUTEC-Menue-Medien-Dateien.json, MUTEC-Menue-Medien-Upload.json und MUTEC-Neun-Filme-Browserprüfung.json. Frontendpaket: outputs/MUTEC-Menue-Frontend.zip; grosse Medien separat installiert.

MUTEC – Mobile Apps

2026-10-18T10:05:17Z

Clawtronics: Drei Mobile-Tabs, neun HTML-Filme und Beitritt direkt in App-Kachel veroeffentlicht

MUTEC – Farbenspektakel

2026-10-16T21:01:08Z

Clawtronics: Aktuelle Lasersteuerung ersetzt Inertialsteuerung; veroeffentlicht und geprueft

== Integration vom 16.10.2026 ==
Neues Angebot mit feature-ID colors und Smartphone-Seite colors/controller.html sowie Electron-Anzeige colors/display.html. Bewegung/Beschleunigung verschiebt einen relativ integrierten, gedaempften Lichtpinsel; Neigung und Drehung beeinflussen ausschliesslich die Spurform/Wirbel/Breite. Reine Orientation-Ereignisse verschieben den Pinsel nicht. Touch ausschliesslich zur Farbwahl, kein Touch-Malmodus. Mitte neu setzen zentriert den Pinsel. Es handelt sich um eine relative Bewegungssteuerung, nicht um optisches oder raeumlich absolutes Tracking.

Schwarzer vollflaechiger Hintergrund, Farbspuren loesen sich nach ca. 3–5.3 Sekunden auf. Geometrie horizontal auf 60 Prozent entzerrt. Maximal 5000 Partikel. Keine QR-Codes, Anzeigen-HUDs oder Namensfelder am Rand. Fehlende Sensordaten und Berechtigungen werden auf dem Smartphone erklaert; kein automatischer Wechsel zu Touch-Malen.

Bis 24 getrennte gueltige MegBes-Tickets teilen einen Farbraum. Erster Teilnehmer reserviert Station 50 und schaltet 166-colors sowie 50-maps; weitere Teilnehmer treten bei, ohne die Anzeige erneut umzuschalten. Andere exklusive Angebote bleiben waehrenddessen gesperrt. Einzelabmeldung beendet nur den eigenen Zugang, letzter Teilnehmer startet 50-Trailer und gibt die Station frei. Aqua-Editor und MegBes-Programme unveraendert.

Die bestehende MegBes-Reservierung ist ticketgebunden: Als Stationsidentitaet bleibt das erste Ticket bis zum Ende des gemeinsamen Farbraums bestehen, auch wenn dessen Smartphone schon ausgestiegen ist. Laeuft dieses Ticket selbst ab, wird die Gruppe beendet. Fehlgeschlagene native Freigaben bleiben fuer den bestehenden Ablauf-Waechter vorgemerkt. Eine unabhaengige serverseitige Gruppenidentitaet wurde nicht in MegBes eingebaut.

=== Protokoll ===
colors.stroke: x/y 0–1; hue 0–360; tilt/twist -1–1; energy 0–1; active Boolean. Exakte Feldpruefung; NaN, Infinity und fremde Malerkennungen werden abgewiesen. Der Relay setzt artistId selbst und uebertraegt ausschliesslich an Farb-Displays. Keine Besucher-Token im Ereignis, kein Verlauf bei Wiederverbindung. Ein Controller pro eigener Farbsitzung, bis 24 parallele Sitzungen. Telegramme maximal etwa 30 Hz je Verbindung.

=== Installation und aktueller Stand ===
9 Frontenddateien gesichert, installiert und oeffentlich ueber HTTPS bytegleich geprueft. views.json im win-unpacked-Verzeichnis des Anzeige-PCs 192.168.14.166 gesichert und um colors ergaenzt; privater Anzeigeschluessel bleibt in der vorhandenen privaten Konfiguration. Keine Schluessel im ZIP. Electron muss fuer den neuen Reiter neu gestartet werden. sources/ wurde nicht beschrieben.

Serverpaket im VPS-Verzeichnis /home/clawtronics/mutec-colors-update bereitgestellt. Der eingeschraenkte SSH-Zugang hat kein root-Recht; Aktivierung steht noch aus. Bei freier Station 50 als root: bash /home/clawtronics/mutec-colors-update/apply-colors-update.sh

Der Installer prueft Paket-Pruefsumme, 141 Tests und die Dateiversionen des aktuellen Relay, sichert die betroffenen Dateien, installiert access.js/protocol.js/server.js sowie den Farbtest und startet den Dienst neu. Rollback bei Fehlern. MegBes-Container, Umgebungsdatei, DISPLAY_KEY, NATIVE_DISPLAY_KEY und Bestenlisten bleiben erhalten. Menuekarte wird erst nach colors:true sichtbar.

=== Validierung ===
141 Tests lokal und auf dem VPS bestanden. Neuer Sensor-Test: reine Neigung/Drehung bewegt Pinsel nicht; Translation bewegt; Gravitation und Ausfall fuehren nicht zu endloser Drift; Neusetzen zentriert. Echter WebSocket-Test mit zwei unabhaengigen Malern, getrennten Farben/Kennungen, Isolation von Maps/anderen Modulen, abgelaufenen Tickets und individueller Freigabe. Browserpruefung mit zwei Smartphone-Kontexten und Display, simulierten Sensoren: schwarz ohne Bewegung; Touch nur Farbe; Bewegung steuert Position; Spur verschwindet; einzelne Abmeldung laesst anderen Teilnehmer weiterarbeiten, letzter gibt Station frei. Keine echten Stationsbefehle waehrend dieser Tests.

Physischer Test mit echten Smartphone-Sensoren, Mobilfunk und LED-Ausgabe steht nach root-Aktivierung und Electron-Neustart aus. Empfindlichkeit und Drift koennen dann am echten Geraet bewertet werden.

Paket: outputs/MUTEC-Farbenspektakel.zip; Anleitung: outputs/MUTEC-Farbenspektakel.md; Installationsnachweis: outputs/MUTEC-Farbenspektakel-Installation.json im bisherigen Codex-Projektordner.

== Serveraktivierung bestaetigt ==
Root-Installation am 16.10.2026 erfolgreich. 141 Tests bestanden, Relay und Ablauf-Waechter active. Oeffentliche API unabhaengig mit HTTP 200 und colors:true geprueft. Sicherung: /var/backups/mutec-realtime/colors-20261016T203553Z-1442301. Die oben als offen beschriebene root-Aktivierung ist damit erledigt. Electron-Neustart und physischer Sensor-/LED-Test noch nicht bestaetigt.

== Hoch/Runter und Ruheabgleich korrigiert ==
Die alte Zuordnung nutzte nur Geraete-X/Y und ignorierte fuer die vertikale Bewegung die Geraete-Z-Achse. Jetzt Projektion der linearen Beschleunigung auf eine schwerkraftbezogene Aufwaertsachse und horizontale Rechtsachse, unter Beruecksichtigung von beta/gamma und Bildschirmausrichtung. Orientation liefert dabei nur das Bezugssystem, keine Verschiebung. Reine Drehung/Neigung ohne lineare Beschleunigung bewegt den Pinsel nicht. Bei fehlender gravity-free acceleration wird Gravitationsanteil ueber die Haltung abgezogen. Standardbezug: https://www.w3.org/TR/orientation-event/
Beim Start 600 ms ruhig halten: stabiler Mittelwert kleiner Sensorabweichungen wird beim Zentrieren als Offset erfasst. Keine Kalibrierung auf Basis einer einzelnen zufaelligen Bewegungsprobe. Partikel haben keine feste vertikale Vorzugsrichtung mehr. Neun Sensor-Regressionstests und Browserablauf mit zwei simulierten Sensor-Handys bestanden. Fuenf Frontenddateien gesichert, veroeffentlicht und ueber HTTPS bytegleich bestaetigt; Haupt-ZIP aktualisiert. Keine Aenderung am Relay, MegBes oder sources. Cacheversion 20261016-vertical1. Smartphone und Electron-Seite neu laden; echter Geraetetest fuer Empfindlichkeit/Drift weiter erforderlich.

== Cursor und Stiftkontakt: aktuelle Bedienung ==
Diese Erweiterung ersetzt die fruehere Regel Touch nur zur Farbwahl: Das Farbfeld waehlt weiterhin die Farbe, dient nun aber zusaetzlich als Stiftkontakt. Nur waehrend der Beruehrung entsteht Farbe. Die Cursorposition wird weiterhin ausschliesslich ueber Handybewegung gesteuert, nie ueber den Fingerort auf dem Farbfeld. Neigung/Drehung bleiben Spur-Effekte.
Ein klarer Cursor wird unabhaengig von den auslaufenden Partikeln dargestellt, auch ohne Stiftkontakt. Loslassen, Touch-Abbruch, Hintergrundwechsel oder Verbindungsverlust heben den Stift. Beim erneuten Aufsetzen keine Verbindung ueber den abgehobenen Weg. Halten malt auch bei stehender Pinselposition.
Die alte stark gedaempfte Integration interpretierte Bremsimpulse teilweise als Rueckbewegung. Jetzt richtungsgebundene Bremsbehandlung und kurze Stillstandserkennung; die getestete Bewegung Beschleunigen/Abbremsen bleibt an neuer Position, eine anschliessende bewusste Gegenbewegung verschiebt zurueck. Rueckkehr zur Seite zentriert nicht mehr. Nur explizit Mitte neu setzen setzt die Position auf Mitte. Weiterhin relative Inertialsteuerung, keine absolute Positionsmessung.
11 Sensorpruefungen sowie Zweipersonen-Browserlauf mit Bewegung ohne Malen, zwei Stiftkontakten, Loslassen/Abbruch, Sichtbarkeitsereignis und sichtbarem Cursor nach dem Spurende bestanden. Fuenf Webdateien gesichert und ueber HTTPS bytegleich bestaetigt. Version 20261016-cursor1. Smartphone und Electron-Anzeige neu laden. Relay/Protokoll, MegBes und sources unveraendert; kein root-Update. Haupt-ZIP aktualisiert; eigener Nachweis outputs/MUTEC-Farbenspektakel-Cursorkorrektur.json. Physischer Handytest fuer das Bewegungsgefuehl bleibt erforderlich.

== Aktuelle Steuerung: virtueller Laser ==
Auf Benutzerwunsch ersetzt die Lasersteuerung saemtliche vorherigen Inertial-/Beschleunigungsansaetze. DeviceOrientation liefert alpha/beta/gamma; DeviceMotion wird weder benoetigt noch angefragt. Strahl aus der physischen oberen Handykante (Geraeteachse +Y). Sensoren erlauben, dann auf reale Bildschirmmitte richten und zweite Schaltflaeche Auf Bildschirmmitte zielen und kalibrieren antippen. Schwenken und Neigen zielen auf andere Bildpunkte; gleiche Richtung ergibt gleiche Position, kleine zeitbasierte Glaettung gegen Zittern. Rollen veraendert den Spur-Effekt. Nur gehaltenes Farbfeld malt, Loslassen/Touch-Abbruch hebt den Stift. Zielmitte kalibrieren definiert eine neue Mitte.
Projektion des Strahls auf virtuelle Zielebene mit horizontal +/-32 Grad und vertikal +/-13 Grad. Kalibrierte Vorwaerts-/Rechts-/Oben-Basis; Winkelsprung 359/0 ueber Richtungsvektoren abgefangen. Hinter der Zielebene kein Malen. Keine automatische physische Vermessung des LED-Terminals; nach deutlicher Standortaenderung nachkalibrieren.
6 Geometrie-/Sensorfaelle und Browserpruefung mit zwei simulierten Sensor-Handys bestanden. Dabei keine DeviceMotion-Berechtigung, Beschleunigungsereignisse beeinflussen Position nicht, stabile Zielhaltung, Richtungskorrekturen, Nachkalibrierung und Stiftkontakt/Abbruch geprueft. Fuenf Dateien gesichert und ueber HTTPS bytegleich geprueft; Version 20261016-laser1. Smartphone und Electron-Seite neu laden. Kein Relay-/MegBes-/sources-Update, kein root-Schritt. Physischer Test des Zielgefuehls steht noch aus. Haupt-ZIP aktualisiert; outputs/MUTEC-Farbenspektakel-Lasersteuerung.md dokumentiert den aktuellen Stand und ersetzt die Bedienhinweise der vorherigen Versuche.

MUTEC – Farbenspektakel

2026-10-16T20:52:27Z

Clawtronics: Cursor haelt Position; Farbfeld ist Stiftkontakt, Frontend veroeffentlicht

MUTEC – Farbenspektakel

2026-10-16T20:44:08Z

Clawtronics: Vertikale Sensorbewegung und Ruheabgleich korrigiert; Frontend veroeffentlicht

MUTEC – Farbenspektakel

2026-10-16T20:37:05Z

Clawtronics: Farbenspektakel-Relay erfolgreich aktiviert und oeffentlich bestaetigt

MUTEC – Farbenspektakel

2026-10-16T20:33:06Z

Clawtronics: Farbenspektakel integriert; Bewegungssteuerung, nur Farbwahl per Touch, Aktivierung offen

MUTEC – Spielablauf

2026-10-16T20:06:04Z

Clawtronics: Zweispieler-Prüfbericht mit offenen UI-Befunden verlinkt

MUTEC – Zweispieler-Prüfung

2026-10-16T20:06:04Z

Clawtronics: Zweispieler-Audit: 125 Servertests, Browserzustände und drei offene UI-Befunde

Stand: 16.10.2026. Logische Prüfung des lokalen MUTEC-Projektstands; keine Änderung der produktiven Seiten, des Relay oder von Bestenlisten.

== Ergebnis ==
125 automatisierte Servertests bestanden: 61 bestehende und 64 neue Vertragsprüfungen (16 Szenarien je Pong, Pöng, Flight und Ortssuche). Zusätzlich drei getrennte Browserkontexte für Gastgeber, Gast und Anzeige; 36 Zustandspaare mit tatsächlich sichtbaren Optionen/Meldungen erfasst. Standardablauf einschließlich gemeinsamer Startbereitschaft, Ergebnis/Highscore, Revanche und Gastausstieg bestanden. Drei bestätigte Oberflächenfehler bleiben offen; dies ist keine uneingeschränkte Freigabe.

== Wer bekommt wann welche Optionen? ==
* QR nur auf Smartphone von Spieler 1. Das Anzeigen unterbricht ein laufendes Einzelspiel nicht; erst der Scan akzeptiert den Gast und bereitet eine gemeinsame neue Runde vor. Spieler 2 erhält eigene Infokarten.
* Eine Beitrittsanfrage mit eigenem Ticket bleibt dagegen offen, bis Spieler 1 annimmt. Spieler 1 sieht Annehmen/Ablehnen; bis dahin läuft das Einzelspiel weiter. Gast wartet nach den Karten auf Annahme.
* Gemeinsamer Countdown dauert drei Sekunden und erfordert Bereitschaft beider Teilnehmer sowie ihre Verbindungen und die Anzeige.
* Spieler 1 steuert links/eigenen Flieger/eigene Karte; er darf Neustart bzw. neue Suche anfordern und zur Auswahl zurückkehren. Bei Pong/Pöng auch Spiel beenden.
* Spieler 2 steuert nur rechts bzw. seinen Flieger/seine Karte. Er darf Bereitschaft erklären und selbst aussteigen. Er darf weder Stationen steuern/freigeben noch eine gemeinsame Runde erzwingen.
* Ergebnis und qualifizierte Namenseingabe gehören jeweils dem richtigen Teilnehmer. Bei Ortssuche kann ein fertiger Teilnehmer warten, während der andere weiter sucht. Bestenlisten nur auf der Anzeige.
* Revanche wartet erneut auf beide. Bei Pong/Pöng/Flight kann Gastbereitschaft nach dem Ende vor oder nach der Gastgeberanforderung eintreffen. Bei Ortssuche erhält der Gast nach der neuen Suchanforderung den Bereitschaftsbutton.
* Gastverbindung: kurze Unterbrechung pausiert; erneut bereit werden. Platz zunächst 15 Sekunden reserviert. Gast geht: Besitzer behält Station; Rückkehr zum Einzelspiel mit Countdown.
* Gastgeberverlust: Gast nach 15 Sekunden höflich verabschieden, keine Übernahme von Stationsrechten. Zusätzlicher Gast oder zweiter aktiver Gast-Tab wird abgewiesen.

== Offene reproduzierte Fehler ==
; UI-01 – Einladung während des Ladens abbrechen
Antwort des Einladungsabrufs verzögern, Zurück zum Spiel drücken, Antwort zulassen. Nur POST, kein Widerruf; geschlossener Dialog erhält trotzdem QR-Link und spätere Gastmeldung löst den Einladungserfolg aus. Gemeinsames Einladungsmodul aller vier Spiele. Eine Korrektur muss verspätete Antworten, Widerruf und Wiederöffnen gemeinsam behandeln.
; UI-02 – Gast wartet laut Hinweis auf sich selbst
Pong/Pöng zeigen auch dem Gast „Warte auf Spieler 2“, wenn seine eigene Bereitschaft fehlt. Rollenabhängigen Hinweis vorsehen.
; UI-03 – Bereitschaft ohne Verbindung aktiv
Pong/Pöng lassen „Ich bin bereit“ beim Wiederverbinden aktiv; Klick kann in dieser Phase nicht gesendet werden. Während Trennung deaktivieren und Bestätigung klar anzeigen.
Einige Pong/Pöng-Texte in control/paddle-flow.js enthalten zusätzlich fehlerhaft kodierte Zeichen. Keine dieser Korrekturen wurde im Rahmen der Prüfung veröffentlicht.

== Testumfang und Grenzen ==
Neue Tests: realtime/test/two-player-contract.test.js. Prüfung fehlender Bereitschaft/Anzeige; QR-Anzeige und Scan; Ticketanfrage/Annahme/Ablehnung/Rückzug; gleichzeitige Scans; alte/abgelaufene/widerrufene QR-Codes; dritte Person; verbotene Gastaktionen; Neustart/Revanche in beiden Reihenfolgen; Gast-/Displayverlust; Gasttimeout/Ticketwiderruf; Gastgeberverlust bei 14/16 Sekunden; doppelte Gastverbindung.

Echte Serverlogik und WebSocket-Weg lokal, MegBes-Upstream simuliert. Browser mit echten HTML-/CSS-/Steuerungsmodulen; Google Maps und Flight-3D-Ansicht als Attrappen, Rundenenden für reproduzierbare Ergebnisprüfung gezielt herbeigeführt. Kein physischer LED-, Neigungssensor-, Mobilfunk-, iOS-Hintergrund- oder Dauertest. Produktiver Relay unverändert.

Lokaler Nachweis: outputs/MUTEC-Zweispieler-Prüfbericht.md, MUTEC-Zweispieler-Optionen.md, MUTEC-Zweispieler-Browserzustände.json und MUTEC-Zweispieler-Grenzfälle.json im Codex-Arbeitsordner dieser Unterhaltung.

[[MUTEC – Spielablauf]] · [[MUTEC – Einheitliche Spiele]]

MUTEC – Spielablauf

2026-10-16T15:06:55Z

Clawtronics: Zentrierte Spiel-Bestenlisten und verlaesslichere Namenseingabe veroeffentlicht

MUTEC – Einheitliche Spiele

2026-10-16T15:06:54Z

Clawtronics: Zentrierte Spiel-Bestenlisten und verlaesslichere Namenseingabe veroeffentlicht

MUTEC – Native BrightSign-Videos

2026-10-16T09:46:31Z

Clawtronics: Isolierte native SD-Labortests nach Player-Abstuerzen vorbereitet; Hardwaretest offen

= MUTEC: Native BrightSign-Videos =

Stand: 15.10.2026. Frontend veröffentlicht; Serverpaket am 15.10.2026 erfolgreich als root installiert; 65 Tests bestanden. BrightAuthor-Projektkopie erstellt, noch nicht am XT1144 getestet/veröffentlicht.

== Aktivieren ==

Bei freier Station 50 als root auf dem VPS:

```bash
bash /home/clawtronics/mutec-native-video-update/apply-native-video-update.sh
```

Das Paket prüft 65 Tests und den aktuellen Stand aller 20 Quelldateien. Es sichert und ersetzt drei Relay-Dateien, ergänzt einen eigenen privaten `NATIVE_DISPLAY_KEY` in der vorhandenen Umgebungsdatei und startet den Dienst neu. Bei einem Fehler werden Dateien und Umgebung zurückgesetzt. MegBes-external/internal, der bestehende DISPLAY_KEY, Bestenlisten und der Ticketablauf-Wächter bleiben erhalten. Die neue Funktion ist über `nativevideo: true` in der öffentlichen capabilities-Antwort erkennbar.

Anschließend diese Projektkopie mit BrightAuthor Classic öffnen und auf Station 50 veröffentlichen:

`C:\tinetronics Claw\R&D\MUTEC\BrightSign\MUTEC2026 Counter XT1144 - Native Wasser.bpf`

Das Originalprojekt wurde nicht geändert. Die Kopie ist auf XT1144 eingestellt, enthält das Plugin `mutecNative` und die zusätzliche Szene `Native Wasser`. Alle vorhandenen Medienpfade bleiben wie im Original auf dem Produktionslaufwerk H erhalten. Die drei neuen Dateien direkt im Counter-Hauptverzeichnis auf dem Produktivrechner ablegen, neben Main und Header. Die Pruefung gegen die lokale Spiegelung fand keine fehlenden Medien. Die eigene Datei `MUTEC-Native-Wasser.mp4` wurde ohne erneute Videokodierung aus Wasser erzeugt, ohne Audiospur. Sie hat dieselbe Bildgröße 1376 × 430 und dieselbe Dauer von 97 Sekunden. Die vorhandene Zonenanordnung und Ausgabeauflösung bleiben erhalten.

Das Plugin enthält einen privaten, ausschließlich für diesen nativen Anzeigekanal gültigen Geräteschlüssel. Die Datei bleibt im lokalen BrightAuthor-Projekt und wird mit auf den Player veröffentlicht; sie gehört nicht auf den öffentlichen Webserver. Der Schlüssel ist bereits passend im Serverpaket hinterlegt und muss nicht vom Besucher eingegeben werden.

Die BrightSignOS-Version ist noch unbekannt. Die WebSocket-Brücke setzt einen modernen HTML-Renderer voraus; sie ist für die Sprachfunktionen von Chromium 87 (BrightSignOS 8.5) vorbereitet, einschließlich randomUUID-Ersatz. Ein tatsächlicher Kompatibilitätstest auf dem XT1144 ist erforderlich. Der Installer aktualisiert keine Player-Firmware.

Smartphone-Auswahlseite neu laden. Neuer Eintrag: **Wasser · BrightSign**. Electron ist für dieses Angebot nicht beteiligt und braucht keinen neuen Reiter.

== Ablauf ==

1. Mit MegBes-Ticket anmelden und Wasser · BrightSign wählen. Exklusive Reservierung von Station 50, Befehl `50-nativewater`.
2. Die eigene BrightAuthor-Szene spielt die lokale MP4 über den nativen Decoder. Das Plugin hält die Wiedergabe für die Smartphone-Freigabe an.
3. Zwei Infokarten auf dem Smartphone bestätigen, Ton aktivieren und starten. Deutsch/Englisch, Pause, Zeitleiste, ±10 Sekunden und Kapitel Start stehen zur Verfügung.
4. Zur Auswahl sendet wie bei den anderen exklusiven Angeboten `50-Trailer` und gibt die Sitzung frei. Filmende bleibt bis zur Rückkehr bzw. zum Ticketablauf an diese Sitzung gebunden.

== Synchronisation und Abgrenzung ==

Eine transparente 16 × 16-Pixel-HTML-Brücke auf dem BrightSign hält die Verbindung zum vorhandenen WebSocket-Relay; sie spielt selbst kein Video. Sie bleibt sichtbar, um Hintergrund-Timer-Drosselung zu vermeiden. Sie nutzt weder Node.js noch abgeschaltete HTTPS-/Web-Sicherheitsprüfungen. BrightAuthor und das Plugin kommunizieren lokal über BSMessagePort/PostJSMessage.

Das Plugin greift ausschließlich auf den nativen Player der Zone Video or Images zu, wenn dessen tatsächliche Quelle die eigene native Wasser-Datei aus dem Asset-Pool ist. Die separate, stumme Datei hat einen anderen Inhalt/Hash als die bestehende Wasser-Datei. Dadurch werden die bisherige Medienauswahl und der HDMI-Eingang nicht mitgesteuert.

Alle 250 ms werden echte Position und Dauer abgefragt. Spulbefehle werden erst bestätigt, wenn die abgefragte Position das Ziel bis auf 200 ms erreicht hat; nach fünf Sekunden wird stattdessen ein Fehler gemeldet. Rückmeldungen sind an Sitzung und konkrete Abfrage gebunden; alte Messungen werden verworfen. Der Smartphone-Ton übernimmt die bestehende Uhrabgleich-/Driftkorrektur: größere Abweichungen durch Positionssprung, kleinere über maximal ±2 % Abspielgeschwindigkeit. Die lokale Einstellung zur Audioverzögerung berücksichtigt den LED-Prozessor und Kopfhörer.

Bei fehlendem Smartphone-Heartbeat bzw. fehlender Audio-Bereitschaft pausiert der Film. Ein unabhängiger BrightScript-Timer pausiert auch bei ausgefallener WebSocket-/HTML-Brücke nach spätestens ungefähr 1,8 Sekunden. Verbindungsverlust setzt die Startabsicht zurück; eine erneute Freigabe ist nötig. Fehlen dem Smartphone frische Positionsmeldungen, pausiert sein Ton. Ticketablauf und Stationsfreigabe verwenden die vorhandene Infrastruktur.

Native und Electron-Videoanzeigen haben getrennte Verbindungen und Schlüssel. Native Besucher dürfen nur `50-nativewater`, keine Electron-Befehle und keine anderen Filme aufrufen. Der vorhandene HTML-Videokanal bleibt bestehen.

== Vor Ort prüfen ==

- Nach Veröffentlichung: Das bisherige Trailer-/HDMI-/Aquarium-Verhalten bleibt benutzbar.
- Wasser starten, Pause, mehrere Sprünge vor/zurück und an die Enden, Fortsetzung sowie Sprachwechsel testen.
- Den Tonversatz mit Kopfhörern am echten Counter abstimmen. Mobilfunk, LED-Verarbeitung und Bluetooth erlauben ohne Messung kein Versprechen bildgenauer Synchronität.
- Smartphone-Verbindung kurz trennen: Film muss pausieren. Danach bewusst erneut starten.
- Zur Auswahl und Ticketablauf testen: Trailer/IDLE muss die Station wieder freigeben.
- Nach Filmende muss die Smartphone-Seite Film beendet anzeigen.

Geprüft: 65 automatisierte Servertests auf dem VPS; Syntaxanalyse des BrightScript-Plugins ohne Fehler; Browserablauf mit simulierten nativen Rückmeldungen; alle sieben öffentlichen Frontend-Dateien per SHA-256 bestätigt. Noch offen: BrightAuthor-Öffnen/Veröffentlichen, reale BrightSign-API-Rückmeldungen und die wahrnehmbare Synchronisation am LED-Counter.

Technische Referenzen: [roVideoPlayer](https://docs.brightsign.biz/develop/rovideoplayer), [roHtmlWidget](https://docs.brightsign.biz/develop/rohtmlwidget), [offizielles HTMLZoneMessage-Beispiel](https://github.com/brightsign/BrightAuthor-Plugins/tree/master/HTMLZoneMessage).

== Serverinstallation bestaetigt ==
15.10.2026: Alle 65 Tests und Ausgangsstandpruefungen bestanden. Oeffentliche API meldet nativevideo=true. Relay und Ticketablauf-Waechter aktiv. Sicherung: /var/backups/mutec-realtime/native-20261015T095543Z-4083237. Geraeteschluessel eingerichtet, bestehender DISPLAY_KEY und MegBes-Programme unveraendert. Veroeffentlichung der BrightAuthor-Projektkopie und realer Synchronisationstest am XT1144 noch nicht bestaetigt.

== Erster Hardwaretest und Pfaderkennung ==
15.10.2026: Erster Test zeigt vorzeitig laufenden Film und fehlende Positionsrueckmeldung. Das bereitgestellte Player-Protokoll bestaetigt BrightSignOS 8.5.53.2 und die eigene 97-Sekunden-Datei. Der Player protokolliert absolute Linux-Pfade unter /storage/sd/pool/, die bisherige Normalisierung beruecksichtigte nur sd:/ und file:-Praefixe. Plugin v2 normalisiert auch diesen Pfad und akzeptiert geboxte String-/Zahlenwerte. Initialisierung und erste Dateierkennung werden ohne Schluessel im Player-Log protokolliert. Lokale Projektkopie aktualisiert, Syntaxanalyse bestanden. Erneute BrightAuthor-Veroeffentlichung und Hardwarebestaetigung stehen aus; kein neues Serverupdate erforderlich.

== Produktionspfade erhalten ==
Auf Nutzerwunsch bleiben alle bestehenden Medienpfade exakt aus dem Originalprojekt erhalten (Laufwerk H, Tinetronics Local). Auch zukuenftige Generierungen veraendern diese Pfade nicht. Projektkopie, Plugin und native MP4 werden direkt auf H im vorhandenen Counter-Hauptverzeichnis erwartet. Die drei Dateien aus dem lokalen BrightSign-Hauptverzeichnis einmalig dorthin uebernehmen; kein Unterordner NativeVideo. Keine manuelle Pfadkorrektur im XML notwendig. Die lokalen C-Pfade dienen nur der Dateipruefung und werden nicht mehr in die Projektkopie geschrieben.

== Diagnose und Befehlsuebergabe vom 16.10.2026 ==
Ein neues Player-Protokoll liegt noch nicht vor. Der Player ist erreichbar, die Diagnose ist per Digest-Anmeldung geschuetzt. Plugin v3 meldet HTML-Ladezustand, JavaScript-/WebSocket-Verbindung, Uhrabgleich, Sitzungszuordnung und Erkennung der nativen Datei in getrennten Schritten; es protokolliert selbst keine Schluessel oder Nachrichteninhalte. Die BPF und H-Pfade bleiben unveraendert. Der Web-Teil wurde veroeffentlicht und oeffentlich geprueft. Steuerbefehle werden nun in einer begrenzten Warteschlange gehalten statt bei noch offener Bestaetigung verworfen; bei Trennung/Sitzungswechsel wird die Warteschlange geloescht. Ausfuehrbarer BrightScript-Test mit Player-Attrappen besteht fuer Pfaderkennung, Intro-Pause, Start, Spulen, Audio-Bereitschaft und Quellenabgrenzung. Browsertest mit simulierten nativen Rueckmeldungen besteht, einschliesslich unmittelbar aufeinanderfolgendem Spulen/Pause. Fuer den echten Player nur mutecNative.brs im Counter-Hauptverzeichnis ersetzen und die bestehende Projektkopie neu veroeffentlichen. Kein Serverupdate noetig. Hardwareursache und Synchronisation noch nicht bestaetigt.

== Neustart der Hardwarepruefung am 16.10.2026 ==
Nutzer meldet Abstuerze des Players im Zusammenhang mit dem Plugin und ist zur Original-BPF zurueckgekehrt. Native Gesamtsteuerung weiterhin nicht erfolgreich am Geraet bestaetigt. Statt weiterer Integration wurden zwei isolierte SD-Tests mit genau einem eigenen nativen Player erstellt; siehe [[MUTEC – Native Video-Labortest]]. Vorhandene Praesentation, H-Pfade und VPS unveraendert. Bestimmte Absturzursache noch nicht belegt.

MUTEC – Native Video-Labortest

2026-10-16T09:46:30Z

Clawtronics: Isolierte native SD-Labortests nach Player-Abstuerzen vorbereitet; Hardwaretest offen

= MUTEC: Isolierter nativer Video-Labortest =

Stand 16.10.2026. Der Nutzer berichtet Abstuerze mit dem bisherigen mutecNative-Plugin und ist zur Originalpraesentation MUTEC2026 Counter XT1144.bpf zurueckgekehrt. Die konkrete Ursache ist nicht bewiesen. Die bestaetigte Player-Version ist BrightSignOS 8.5.53.2.

== Zweck ==
Native Wiedergabe und elementare Steuerung zuerst ohne BrightAuthor-Plugin, HTML-Renderer, WebSocket, MegBes oder Smartphone-Audio pruefen. Die frueheren Server-/Browsertests belegen die Nachrichtenlogik, keine Stabilitaet des BrightSign-Runtimes.

== Bereitgestellte Dateien ==
Lokal: C:\tinetronics Claw\R&D\MUTEC\BrightSign\Native-Labortest. Archiv im Codex-Arbeitsordner: outputs/MUTEC-Native-Labortest.zip.

* 01-Nur-Film: Eigenstaendiges autorun.brs mit genau einem roVideoPlayer und originaler Wasser.mp4; Dauerschleife, keine Netzwerksteuerung.
* 02-Film-mit-Steuerung: Eigener roVideoPlayer, pausierter Start, feste lokale MP4, Start/Pause/Spulen und echte Positionsabfrage ueber separaten UDP-Port 41050.
* PC-Steuerung: Lokale Browseroberflaeche mit Python-Standardbibliothek; nur Loopback-Port 18150, Standardziel 192.168.14.50. Kein MegBes-Port, keine beliebigen Zielbefehle. Python 3 und LAN-Erreichbarkeit erforderlich.
* Anleitung.md beschreibt den SD-Test und die Auswertung.

Es handelt sich um eigenstaendige SD-Testprogramme, keine BPF-Projekte. Ausschliesslich eine separate Test-SD bei freier Station verwenden; die Produktions-SD unveraendert aufbewahren. Zum Kartentausch Player ausschalten. Zuerst den Inhalt von 01-Nur-Film ins SD-Hauptverzeichnis kopieren und drei Durchlaeufe beobachten. Erst nach stabilem Test 1 die autorun.brs aus Test 2 einsetzen und die PC-Steuerung starten. Spruenge werden angenommen und danach anhand der gemessenen Position bestaetigt; die Oberflaeche zeigt diesen Unterschied.

== Diagnose und naechste Schritte ==
Scheitert bereits Test 1, native Wiedergabe, MP4, SD und Firmware/Decoder untersuchen. Scheitert nur Test 2, den letzten elementaren Player-Aufruf untersuchen. Sind beide stabil, als getrennten Schritt eine minimale BrightAuthor-Praesentation pruefen; danach erst die WebSocket-Anbindung und Smartphone-Audio ergaenzen.

Moegliche spaetere Architektur: WebSocket-Gateway auf dem vorhandenen PC, einfacher lokaler Steuer-/Positionskanal zum BrightSign. Der Film bleibt nativ auf dem BrightSign, ein zusaetzlicher HTML-Renderer fuer WebSocket auf dem Player entfaellt. Noch nicht implementiert.

== Pruefung ==
Beide Skripte syntaktisch geprueft. Die echte BrightScript-Befehlsfunktion wurde mit Player-Attrappen ausgefuehrt. Drei Python-Tests pruefen Eingaben, UDP-Antwortzuordnung und Timeout. Browser/HTTP/UDP-Test mit Loopback-Attrappe bestanden, einschliesslich abgeschlossener Spruenge und erneuter Bedienbarkeit. Originalfilm in beiden Paketen bytegleich; Original-BPF unveraendert. Keine Aenderung an Produktionspraesentation, H-Pfaden, VPS oder Frontend. Hardwaretests sind offen. Kein Firmwareupdate durchgefuehrt oder vorausgesetzt.

[https://docs.brightsign.biz/develop/rovideoplayer BrightSign: roVideoPlayer] und [https://docs.brightsign.biz/develop/rodatagramsocket BrightSign: roDatagramSocket].

MUTEC – Native BrightSign-Videos

2026-10-16T09:10:04Z

Clawtronics: Gezielte Player-Diagnose v3 und verlustfreie Befehlsuebergabe vorbereitet und getestet

MUTEC – Native BrightSign-Videos

2026-10-15T10:23:38Z

Clawtronics: Projekt, Plugin und Film auf Nutzerwunsch direkt im Counter-Hauptverzeichnis

MUTEC – Native BrightSign-Videos

2026-10-15T10:22:42Z

Clawtronics: Produktionspfade auf H dauerhaft erhalten; neue Dateien unter Counter/NativeVideo

= MUTEC: Native BrightSign-Videos =

Stand: 15.10.2026. Frontend veröffentlicht; Serverpaket am 15.10.2026 erfolgreich als root installiert; 65 Tests bestanden. BrightAuthor-Projektkopie erstellt, noch nicht am XT1144 getestet/veröffentlicht.

== Aktivieren ==

Bei freier Station 50 als root auf dem VPS:

```bash
bash /home/clawtronics/mutec-native-video-update/apply-native-video-update.sh
```

Das Paket prüft 65 Tests und den aktuellen Stand aller 20 Quelldateien. Es sichert und ersetzt drei Relay-Dateien, ergänzt einen eigenen privaten `NATIVE_DISPLAY_KEY` in der vorhandenen Umgebungsdatei und startet den Dienst neu. Bei einem Fehler werden Dateien und Umgebung zurückgesetzt. MegBes-external/internal, der bestehende DISPLAY_KEY, Bestenlisten und der Ticketablauf-Wächter bleiben erhalten. Die neue Funktion ist über `nativevideo: true` in der öffentlichen capabilities-Antwort erkennbar.

Anschließend diese Projektkopie mit BrightAuthor Classic öffnen und auf Station 50 veröffentlichen:

`C:\tinetronics Claw\R&D\MUTEC\BrightSign\NativeVideo\MUTEC2026 Counter XT1144 - Native Wasser.bpf`

Das Originalprojekt wurde nicht geändert. Die Kopie ist auf XT1144 eingestellt, enthält das Plugin `mutecNative` und die zusätzliche Szene `Native Wasser`. Alle vorhandenen Medienpfade bleiben wie im Original auf dem Produktionslaufwerk H erhalten. Die neuen Dateien liegen fuer die Veroeffentlichung unter Counter/NativeVideo. Diesen Ordner auf dem Produktivrechner neben Main und Header ablegen. Die Pruefung gegen die lokale Spiegelung fand keine fehlenden Medien. Die eigene Datei `MUTEC-Native-Wasser.mp4` wurde ohne erneute Videokodierung aus Wasser erzeugt, ohne Audiospur. Sie hat dieselbe Bildgröße 1376 × 430 und dieselbe Dauer von 97 Sekunden. Die vorhandene Zonenanordnung und Ausgabeauflösung bleiben erhalten.

Das Plugin enthält einen privaten, ausschließlich für diesen nativen Anzeigekanal gültigen Geräteschlüssel. Die Datei bleibt im lokalen BrightAuthor-Projekt und wird mit auf den Player veröffentlicht; sie gehört nicht auf den öffentlichen Webserver. Der Schlüssel ist bereits passend im Serverpaket hinterlegt und muss nicht vom Besucher eingegeben werden.

Die BrightSignOS-Version ist noch unbekannt. Die WebSocket-Brücke setzt einen modernen HTML-Renderer voraus; sie ist für die Sprachfunktionen von Chromium 87 (BrightSignOS 8.5) vorbereitet, einschließlich randomUUID-Ersatz. Ein tatsächlicher Kompatibilitätstest auf dem XT1144 ist erforderlich. Der Installer aktualisiert keine Player-Firmware.

Smartphone-Auswahlseite neu laden. Neuer Eintrag: **Wasser · BrightSign**. Electron ist für dieses Angebot nicht beteiligt und braucht keinen neuen Reiter.

== Ablauf ==

1. Mit MegBes-Ticket anmelden und Wasser · BrightSign wählen. Exklusive Reservierung von Station 50, Befehl `50-nativewater`.
2. Die eigene BrightAuthor-Szene spielt die lokale MP4 über den nativen Decoder. Das Plugin hält die Wiedergabe für die Smartphone-Freigabe an.
3. Zwei Infokarten auf dem Smartphone bestätigen, Ton aktivieren und starten. Deutsch/Englisch, Pause, Zeitleiste, ±10 Sekunden und Kapitel Start stehen zur Verfügung.
4. Zur Auswahl sendet wie bei den anderen exklusiven Angeboten `50-Trailer` und gibt die Sitzung frei. Filmende bleibt bis zur Rückkehr bzw. zum Ticketablauf an diese Sitzung gebunden.

== Synchronisation und Abgrenzung ==

Eine transparente 16 × 16-Pixel-HTML-Brücke auf dem BrightSign hält die Verbindung zum vorhandenen WebSocket-Relay; sie spielt selbst kein Video. Sie bleibt sichtbar, um Hintergrund-Timer-Drosselung zu vermeiden. Sie nutzt weder Node.js noch abgeschaltete HTTPS-/Web-Sicherheitsprüfungen. BrightAuthor und das Plugin kommunizieren lokal über BSMessagePort/PostJSMessage.

Das Plugin greift ausschließlich auf den nativen Player der Zone Video or Images zu, wenn dessen tatsächliche Quelle die eigene native Wasser-Datei aus dem Asset-Pool ist. Die separate, stumme Datei hat einen anderen Inhalt/Hash als die bestehende Wasser-Datei. Dadurch werden die bisherige Medienauswahl und der HDMI-Eingang nicht mitgesteuert.

Alle 250 ms werden echte Position und Dauer abgefragt. Spulbefehle werden erst bestätigt, wenn die abgefragte Position das Ziel bis auf 200 ms erreicht hat; nach fünf Sekunden wird stattdessen ein Fehler gemeldet. Rückmeldungen sind an Sitzung und konkrete Abfrage gebunden; alte Messungen werden verworfen. Der Smartphone-Ton übernimmt die bestehende Uhrabgleich-/Driftkorrektur: größere Abweichungen durch Positionssprung, kleinere über maximal ±2 % Abspielgeschwindigkeit. Die lokale Einstellung zur Audioverzögerung berücksichtigt den LED-Prozessor und Kopfhörer.

Bei fehlendem Smartphone-Heartbeat bzw. fehlender Audio-Bereitschaft pausiert der Film. Ein unabhängiger BrightScript-Timer pausiert auch bei ausgefallener WebSocket-/HTML-Brücke nach spätestens ungefähr 1,8 Sekunden. Verbindungsverlust setzt die Startabsicht zurück; eine erneute Freigabe ist nötig. Fehlen dem Smartphone frische Positionsmeldungen, pausiert sein Ton. Ticketablauf und Stationsfreigabe verwenden die vorhandene Infrastruktur.

Native und Electron-Videoanzeigen haben getrennte Verbindungen und Schlüssel. Native Besucher dürfen nur `50-nativewater`, keine Electron-Befehle und keine anderen Filme aufrufen. Der vorhandene HTML-Videokanal bleibt bestehen.

== Vor Ort prüfen ==

- Nach Veröffentlichung: Das bisherige Trailer-/HDMI-/Aquarium-Verhalten bleibt benutzbar.
- Wasser starten, Pause, mehrere Sprünge vor/zurück und an die Enden, Fortsetzung sowie Sprachwechsel testen.
- Den Tonversatz mit Kopfhörern am echten Counter abstimmen. Mobilfunk, LED-Verarbeitung und Bluetooth erlauben ohne Messung kein Versprechen bildgenauer Synchronität.
- Smartphone-Verbindung kurz trennen: Film muss pausieren. Danach bewusst erneut starten.
- Zur Auswahl und Ticketablauf testen: Trailer/IDLE muss die Station wieder freigeben.
- Nach Filmende muss die Smartphone-Seite Film beendet anzeigen.

Geprüft: 65 automatisierte Servertests auf dem VPS; Syntaxanalyse des BrightScript-Plugins ohne Fehler; Browserablauf mit simulierten nativen Rückmeldungen; alle sieben öffentlichen Frontend-Dateien per SHA-256 bestätigt. Noch offen: BrightAuthor-Öffnen/Veröffentlichen, reale BrightSign-API-Rückmeldungen und die wahrnehmbare Synchronisation am LED-Counter.

Technische Referenzen: [roVideoPlayer](https://docs.brightsign.biz/develop/rovideoplayer), [roHtmlWidget](https://docs.brightsign.biz/develop/rohtmlwidget), [offizielles HTMLZoneMessage-Beispiel](https://github.com/brightsign/BrightAuthor-Plugins/tree/master/HTMLZoneMessage).

== Serverinstallation bestaetigt ==
15.10.2026: Alle 65 Tests und Ausgangsstandpruefungen bestanden. Oeffentliche API meldet nativevideo=true. Relay und Ticketablauf-Waechter aktiv. Sicherung: /var/backups/mutec-realtime/native-20261015T095543Z-4083237. Geraeteschluessel eingerichtet, bestehender DISPLAY_KEY und MegBes-Programme unveraendert. Veroeffentlichung der BrightAuthor-Projektkopie und realer Synchronisationstest am XT1144 noch nicht bestaetigt.

== Erster Hardwaretest und Pfaderkennung ==
15.10.2026: Erster Test zeigt vorzeitig laufenden Film und fehlende Positionsrueckmeldung. Das bereitgestellte Player-Protokoll bestaetigt BrightSignOS 8.5.53.2 und die eigene 97-Sekunden-Datei. Der Player protokolliert absolute Linux-Pfade unter /storage/sd/pool/, die bisherige Normalisierung beruecksichtigte nur sd:/ und file:-Praefixe. Plugin v2 normalisiert auch diesen Pfad und akzeptiert geboxte String-/Zahlenwerte. Initialisierung und erste Dateierkennung werden ohne Schluessel im Player-Log protokolliert. Lokale Projektkopie aktualisiert, Syntaxanalyse bestanden. Erneute BrightAuthor-Veroeffentlichung und Hardwarebestaetigung stehen aus; kein neues Serverupdate erforderlich.

== Produktionspfade erhalten ==
Auf Nutzerwunsch bleiben alle bestehenden Medienpfade exakt aus dem Originalprojekt erhalten (Laufwerk H, Tinetronics Local). Auch zukuenftige Generierungen veraendern diese Pfade nicht. Plugin und native MP4 werden auf H im Unterordner NativeVideo des vorhandenen Counter-Verzeichnisses erwartet. Den vorbereiteten Ordner NativeVideo mit Projekt, Plugin und MP4 einmalig auf den Produktivrechner uebernehmen. Keine manuelle Pfadkorrektur im XML notwendig. Die lokalen C-Pfade dienen nur der Dateipruefung und werden nicht mehr in die Projektkopie geschrieben.

MUTEC – Native BrightSign-Videos

2026-10-15T10:21:29Z

Clawtronics: Ersten Hardwaretest und Korrektur der nativen Dateipfaderkennung dokumentiert

= MUTEC: Native BrightSign-Videos =

Stand: 15.10.2026. Frontend veröffentlicht; Serverpaket am 15.10.2026 erfolgreich als root installiert; 65 Tests bestanden. BrightAuthor-Projektkopie erstellt, noch nicht am XT1144 getestet/veröffentlicht.

== Aktivieren ==

Bei freier Station 50 als root auf dem VPS:

```bash
bash /home/clawtronics/mutec-native-video-update/apply-native-video-update.sh
```

Das Paket prüft 65 Tests und den aktuellen Stand aller 20 Quelldateien. Es sichert und ersetzt drei Relay-Dateien, ergänzt einen eigenen privaten `NATIVE_DISPLAY_KEY` in der vorhandenen Umgebungsdatei und startet den Dienst neu. Bei einem Fehler werden Dateien und Umgebung zurückgesetzt. MegBes-external/internal, der bestehende DISPLAY_KEY, Bestenlisten und der Ticketablauf-Wächter bleiben erhalten. Die neue Funktion ist über `nativevideo: true` in der öffentlichen capabilities-Antwort erkennbar.

Anschließend diese Projektkopie mit BrightAuthor Classic öffnen und auf Station 50 veröffentlichen:

`C:\tinetronics Claw\R&D\MUTEC\BrightSign\NativeVideo\MUTEC2026 Counter XT1144 - Native Wasser.bpf`

Das Originalprojekt wurde nicht geändert. Die Kopie ist auf XT1144 eingestellt, enthält das Plugin `mutecNative` und die zusätzliche Szene `Native Wasser`. Alle vorhandenen Medienpfade wurden auf den lokalen BrightSign-Ordner umgestellt; bei der Prüfung waren keine Dateien vermisst. Die eigene Datei `MUTEC-Native-Wasser.mp4` wurde ohne erneute Videokodierung aus Wasser erzeugt, ohne Audiospur. Sie hat dieselbe Bildgröße 1376 × 430 und dieselbe Dauer von 97 Sekunden. Die vorhandene Zonenanordnung und Ausgabeauflösung bleiben erhalten.

Das Plugin enthält einen privaten, ausschließlich für diesen nativen Anzeigekanal gültigen Geräteschlüssel. Die Datei bleibt im lokalen BrightAuthor-Projekt und wird mit auf den Player veröffentlicht; sie gehört nicht auf den öffentlichen Webserver. Der Schlüssel ist bereits passend im Serverpaket hinterlegt und muss nicht vom Besucher eingegeben werden.

Die BrightSignOS-Version ist noch unbekannt. Die WebSocket-Brücke setzt einen modernen HTML-Renderer voraus; sie ist für die Sprachfunktionen von Chromium 87 (BrightSignOS 8.5) vorbereitet, einschließlich randomUUID-Ersatz. Ein tatsächlicher Kompatibilitätstest auf dem XT1144 ist erforderlich. Der Installer aktualisiert keine Player-Firmware.

Smartphone-Auswahlseite neu laden. Neuer Eintrag: **Wasser · BrightSign**. Electron ist für dieses Angebot nicht beteiligt und braucht keinen neuen Reiter.

== Ablauf ==

1. Mit MegBes-Ticket anmelden und Wasser · BrightSign wählen. Exklusive Reservierung von Station 50, Befehl `50-nativewater`.
2. Die eigene BrightAuthor-Szene spielt die lokale MP4 über den nativen Decoder. Das Plugin hält die Wiedergabe für die Smartphone-Freigabe an.
3. Zwei Infokarten auf dem Smartphone bestätigen, Ton aktivieren und starten. Deutsch/Englisch, Pause, Zeitleiste, ±10 Sekunden und Kapitel Start stehen zur Verfügung.
4. Zur Auswahl sendet wie bei den anderen exklusiven Angeboten `50-Trailer` und gibt die Sitzung frei. Filmende bleibt bis zur Rückkehr bzw. zum Ticketablauf an diese Sitzung gebunden.

== Synchronisation und Abgrenzung ==

Eine transparente 16 × 16-Pixel-HTML-Brücke auf dem BrightSign hält die Verbindung zum vorhandenen WebSocket-Relay; sie spielt selbst kein Video. Sie bleibt sichtbar, um Hintergrund-Timer-Drosselung zu vermeiden. Sie nutzt weder Node.js noch abgeschaltete HTTPS-/Web-Sicherheitsprüfungen. BrightAuthor und das Plugin kommunizieren lokal über BSMessagePort/PostJSMessage.

Das Plugin greift ausschließlich auf den nativen Player der Zone Video or Images zu, wenn dessen tatsächliche Quelle die eigene native Wasser-Datei aus dem Asset-Pool ist. Die separate, stumme Datei hat einen anderen Inhalt/Hash als die bestehende Wasser-Datei. Dadurch werden die bisherige Medienauswahl und der HDMI-Eingang nicht mitgesteuert.

Alle 250 ms werden echte Position und Dauer abgefragt. Spulbefehle werden erst bestätigt, wenn die abgefragte Position das Ziel bis auf 200 ms erreicht hat; nach fünf Sekunden wird stattdessen ein Fehler gemeldet. Rückmeldungen sind an Sitzung und konkrete Abfrage gebunden; alte Messungen werden verworfen. Der Smartphone-Ton übernimmt die bestehende Uhrabgleich-/Driftkorrektur: größere Abweichungen durch Positionssprung, kleinere über maximal ±2 % Abspielgeschwindigkeit. Die lokale Einstellung zur Audioverzögerung berücksichtigt den LED-Prozessor und Kopfhörer.

Bei fehlendem Smartphone-Heartbeat bzw. fehlender Audio-Bereitschaft pausiert der Film. Ein unabhängiger BrightScript-Timer pausiert auch bei ausgefallener WebSocket-/HTML-Brücke nach spätestens ungefähr 1,8 Sekunden. Verbindungsverlust setzt die Startabsicht zurück; eine erneute Freigabe ist nötig. Fehlen dem Smartphone frische Positionsmeldungen, pausiert sein Ton. Ticketablauf und Stationsfreigabe verwenden die vorhandene Infrastruktur.

Native und Electron-Videoanzeigen haben getrennte Verbindungen und Schlüssel. Native Besucher dürfen nur `50-nativewater`, keine Electron-Befehle und keine anderen Filme aufrufen. Der vorhandene HTML-Videokanal bleibt bestehen.

== Vor Ort prüfen ==

- Nach Veröffentlichung: Das bisherige Trailer-/HDMI-/Aquarium-Verhalten bleibt benutzbar.
- Wasser starten, Pause, mehrere Sprünge vor/zurück und an die Enden, Fortsetzung sowie Sprachwechsel testen.
- Den Tonversatz mit Kopfhörern am echten Counter abstimmen. Mobilfunk, LED-Verarbeitung und Bluetooth erlauben ohne Messung kein Versprechen bildgenauer Synchronität.
- Smartphone-Verbindung kurz trennen: Film muss pausieren. Danach bewusst erneut starten.
- Zur Auswahl und Ticketablauf testen: Trailer/IDLE muss die Station wieder freigeben.
- Nach Filmende muss die Smartphone-Seite Film beendet anzeigen.

Geprüft: 65 automatisierte Servertests auf dem VPS; Syntaxanalyse des BrightScript-Plugins ohne Fehler; Browserablauf mit simulierten nativen Rückmeldungen; alle sieben öffentlichen Frontend-Dateien per SHA-256 bestätigt. Noch offen: BrightAuthor-Öffnen/Veröffentlichen, reale BrightSign-API-Rückmeldungen und die wahrnehmbare Synchronisation am LED-Counter.

Technische Referenzen: [roVideoPlayer](https://docs.brightsign.biz/develop/rovideoplayer), [roHtmlWidget](https://docs.brightsign.biz/develop/rohtmlwidget), [offizielles HTMLZoneMessage-Beispiel](https://github.com/brightsign/BrightAuthor-Plugins/tree/master/HTMLZoneMessage).

== Serverinstallation bestaetigt ==
15.10.2026: Alle 65 Tests und Ausgangsstandpruefungen bestanden. Oeffentliche API meldet nativevideo=true. Relay und Ticketablauf-Waechter aktiv. Sicherung: /var/backups/mutec-realtime/native-20261015T095543Z-4083237. Geraeteschluessel eingerichtet, bestehender DISPLAY_KEY und MegBes-Programme unveraendert. Veroeffentlichung der BrightAuthor-Projektkopie und realer Synchronisationstest am XT1144 noch nicht bestaetigt.

== Erster Hardwaretest und Pfaderkennung ==
15.10.2026: Erster Test zeigt vorzeitig laufenden Film und fehlende Positionsrueckmeldung. Das bereitgestellte Player-Protokoll bestaetigt BrightSignOS 8.5.53.2 und die eigene 97-Sekunden-Datei. Der Player protokolliert absolute Linux-Pfade unter /storage/sd/pool/, die bisherige Normalisierung beruecksichtigte nur sd:/ und file:-Praefixe. Plugin v2 normalisiert auch diesen Pfad und akzeptiert geboxte String-/Zahlenwerte. Initialisierung und erste Dateierkennung werden ohne Schluessel im Player-Log protokolliert. Lokale Projektkopie aktualisiert, Syntaxanalyse bestanden. Erneute BrightAuthor-Veroeffentlichung und Hardwarebestaetigung stehen aus; kein neues Serverupdate erforderlich.

MUTEC – WebSocket-Steuerung

2026-10-15T10:13:01Z

Clawtronics: Erfolgreiche Serverinstallation und oeffentliche nativevideo-Freigabe bestaetigt

= MUTEC v2 – Einrichtung mit MegBes-Ticket =

Stand: 09.10.2026. Das MUTEC-Frontend und die QR-Zieladresse des Ticket-Monitors tine wurden auf den Webspace hochgeladen und per Prüfsumme sowie HTTPS geprüft. Der Administrator hat den separaten WebSocket-Dienst auf dem VPS installiert: sieben Tests erfolgreich, systemd aktiv und lokaler Health-Check erfolgreich. Die öffentliche API-Route beantwortet den CORS-Preflight mit HTTP 204. Der Ticket-Login funktioniert laut Gerätetest. Google Maps und die Electron-Anzeige funktionieren laut Gerätetest. Die Projektzuordnung im Ticket-Monitor wurde anschließend korrigiert; dessen erneute Prüfung und die vollständige Geräteabnahme stehen aus. v2 ersetzt die früheren Pakete mit CONTROL_TOKEN.

== Aktuelle Inbetriebnahme: Google Maps und Electron ==

Nachtrag: Die Google-Karte funktioniert laut Gerätetest auf dem Smartphone. Chrome auf PC 166 zeigt die Karte mit DISPLAY_KEY und übernimmt die Smartphone-Bewegungen. Der verbleibende Electron-Fehler wurde im Programm gefunden und am 09.10.2026 korrigiert: loadConfiguredView hing den Parameter aquariumReload als Text hinter das URL-Fragment. Dadurch wurde der Zusatz Teil des DISPLAY_KEY und die Anzeige wies ihn ab. Die URL wird nun mit URL und searchParams erzeugt, sodass der Parameter vor dem unveränderten Fragment steht. Quellcode electron-main.js und resources/app.asar unter \\192.168.14.166\C-Platte\xampp\htdocs\aquasphaere\aquarium wurden gesichert und korrigiert. Die Konfiguration liegt für die gepackte Anwendung neben der EXE in dist/win-unpacked/views.json und enthält bereits einen formal gültigen Schlüssel. Vier URL-Fälle je Quellcodeversion wurden geprüft, das gepackte Ergebnis zurückgelesen. Der Administrator hat nach dem Neustart die Kartenanzeige in Electron bestätigt.

Die Google-Maps-Diagnose der öffentlichen Kartenanzeige liefert <code>RefererNotAllowedMapError</code> für https://www.tinetronics.de/mutec/control/display.html. Der eingebundene Google-Schlüssel endet auf iJd80U. Bei genau diesem Schlüssel unter Google Cloud → APIs und Dienste → Anmeldedaten → Website-Einschränkungen die Freigabe https://www.tinetronics.de/* prüfen und speichern. Danach einige Minuten warten und die Kartenseite neu laden. Die konkrete Diagnose weist auf die Website-Freigabe hin; ein neues Relay-Paket ist dafür nicht erforderlich.

Die Electron-Meldung „Diese Anzeige ist noch nicht in Electron eingerichtet“ bedeutet, dass der private DISPLAY_KEY fehlt. Auf dem VPS mit <code>sudo grep '^DISPLAY_KEY=' /etc/mutec-realtime.env</code> lokal ablesen. Nur den Wert hinter dem Gleichheitszeichen in views.json als https://www.tinetronics.de/mutec/control/display.html#displayKey=WERT einsetzen. Den Schlüssel nicht in Wiki oder Chat veröffentlichen. Electron anschließend neu starten. Der Schlüssel berechtigt ausschließlich die Anzeige und ersetzt keinen Besucher-Ticket-Code.

== Ergebnis und Bedienung ==

MegBes-Ticket → Auswahlmenü → Aqua, Karte oder Medien. Keine Stationseingabe und kein zusätzliches Besucher-Passwort. Alle Anwendungen belegen Station 50 exklusiv als REMOTE. Andere Besucher dürfen das Auswahlmenü öffnen, aber den belegten Bildschirm nicht übernehmen. „Zur Auswahl“ und „Abmelden“ geben Station 50 über die vorhandene MegBes-Stationsabmeldung frei. Eine stationsseitige IDLE-Meldung beendet die bisherige Steuersitzung spätestens beim nächsten Befehl, einer neuen Auswahl oder nach etwa zehn Sekunden.

Der PC 166 bleibt das Ziel der bestehenden UDP-Befehle. Die Karte sendet 166-maps für Electron und 50-maps für den HDMI-Eingang des BrightSign. Es wird keine zusätzliche native Stationsgruppe oder Backend-Erweiterung eingeführt. megbes-external und megbes-internal bleiben unverändert.

== Pakete ==

* MUTEC-v2-server.tar.gz: separater Node-WebSocket-Dienst, Installer, systemd-Datei, zwei nginx-Weiterleitungen und sieben Tests.
* MUTEC-v2-frontend.zip: aktualisierte Dateien für den bereits vorhandenen FTP-Ordner /tinetronics_de/mutec. Vorhandene Bilder, Audios, Bibliotheken und Aquarium-Dateien bleiben Voraussetzung.
* views-tine.example.json: vollständiges Beispiel der Electron-Ansichten. Den privaten Anzeigeschlüssel einsetzen.

== 1. Vorhandene MegBes-Konfiguration prüfen ==

Auf dem zentralen Server 87.106.33.238 läuft megbes-external-tine. Der lokale MegBes-Server mit megbes-internal wird weiterhin über die vorhandene Projektkonfiguration angesprochen. Keine Installation in BrightSign oder Electron und kein Austausch der MegBes-Programme.

Voraussetzung sind die bestehende Ticket-Sicherheit und der bereits von MegBes unterstützte Modus intern kontrollierter Stationen. Im aktuellen Quellcode heißen die Einstellungen megbes.security=true (External) und megbes.internal.station.controlled=true (External und Internal). Die bestehenden Umgebungsvariablen heißen MEGBES_SECURITY und MEGBES_INTERNAL_STATION_CONTROLLED. Aktuelle effektive Werte prüfen: Wiki und OpenClaw enthalten unterschiedliche historische Angaben zum tine-Stationsmodus. Diese Schalter nicht ungeprüft ändern; der Stationsmodus betrifft das ganze Projekt.

Station 50 muss im Ruhezustand IDLE melden, nicht OPEN. OPEN ist die normale MegBes-Freigabe für Mehrfachbedienung und wird von dieser MUTEC-Version abgewiesen. BrightSign-Start-/Timeout-Meldungen für Station 50 entsprechend auf idle einstellen. Eine regelmäßige OPEN-Meldung während der Bedienung darf REMOTE nicht überschreiben. Das stationsseitige Timeout muss nach beendeter Bedienung IDLE senden können.

Der Dienst verwendet ausschließlich vorhandene Endpunkte:

<pre>POST /enter-system Ticket aktivieren (Frontend)
GET /verify Ticket prüfen
GET /media-station?station=50 Station anmelden
GET /media-station/status/50 REMOTE und Berechtigung prüfen
DELETE /media-station Station abmelden
POST /video-command erlaubte UDP-Befehle senden</pre>

Die bestehende Anmeldung kann trotz fehlgeschlagener interner Reservierung HTTP 200 liefern. Deshalb prüft das Relay vor und nach der Anmeldung den tatsächlichen Stationsstatus. Ein 403, OPEN, TOUCHSCREEN oder unerwarteter Zustand erlaubt keine Übernahme. Vor dem Start wird auch die Erreichbarkeit/Berechtigung für PC 166 geprüft; PC 166 wird nicht separat reserviert.

Für das gleiche Ticket soll keine zweite Anwendung außerhalb MUTEC parallel eine andere MegBes-Station anmelden: MegBes verwaltet pro Benutzer eine aktuelle Station. Die exklusive MUTEC-Nutzung gilt für den angeschlossenen Bildschirm und die über dieses Frontend angebotenen Funktionen.

== 2. WebSocket-Dienst auf 87.106.33.238 installieren ==

Als Administrator das Archiv in ein privates Arbeitsverzeichnis auf dem zentralen Plesk-Server kopieren und auspacken:

<pre>mkdir -p ~/mutec-v2-setup
cd ~/mutec-v2-setup
tar -xzf /pfad/zur/MUTEC-v2-server.tar.gz
cd MUTEC-v2-server
sudo bash install.sh</pre>

Der Installer verwendet das vorhandene Plesk-Node unter /opt/plesk/node/24/bin/node. Er erzeugt den Dienstbenutzer mutec-realtime, installiert festgelegte Abhängigkeiten und startet den Dienst ausschließlich auf 127.0.0.1:8089. Kein zusätzlicher öffentlicher Port. Ein vorhandener MUTEC-Relay wird vorher unter /var/backups/mutec-realtime privat gesichert. Ein vorhandener DISPLAY_KEY bleibt erhalten; CONTROL_TOKEN aus v1 entfällt. Der Installer verändert keine MegBes-Container oder deren Konfiguration.

<pre>sudo systemctl status mutec-realtime --no-pager
curl --fail http://127.0.0.1:8089/health</pre>

Erwartet: aktiver Dienst und JSON mit version 2. Health bestätigt den laufenden Relay-Prozess, noch nicht MegBes-Reservierung oder Hardware-Ausgabe.

== 3. Zwei Weiterleitungen in Plesk ergänzen ==

Bei tine.megbes.de → Apache & nginx-Einstellungen → Zusätzliche nginx-Anweisungen den Inhalt von nginx-tine.conf ergänzen. Vorhandene MegBes-Anweisungen erhalten. Die Datei enthält /mutec-control-ws für WebSockets und /mutec-control-api/ für Steuersitzungen. Speichern und prüfen:

<pre>sudo nginx -t</pre>

Öffentlich: wss://tine.megbes.de/mutec-control-ws und https://tine.megbes.de/mutec-control-api. Bestehende Ticket-/MegBes-Routen bleiben unverändert. Es wird kein Geheimwert in nginx eingetragen.

== 4. Website über FTP aktualisieren ==

Den bisherigen Ordner /tinetronics_de/mutec vollständig sichern. Danach den Inhalt von MUTEC-v2-frontend.zip darüber kopieren, Unterordner beibehalten. Dieser Ordner liegt auf dem Website-Host 217.160.0.178, nicht auf dem MegBes-VPS. realtime/ gehört nicht in den öffentlichen Webordner.

Google Maps verwendet den bestehenden Browserschlüssel in control/config.js. Maps JavaScript API und Abrechnung müssen aktiv sein; https://www.tinetronics.de/* ist nach deiner Angabe bereits freigegeben. PHP benötigt mindestens 8.0 mit cURL, ausgehendes HTTPS zu tine.megbes.de sowie die bestehenden Schreibrechte für Aqua und die Medien-Dateien. Schreibende PHP-Aufrufe prüfen die passende Steuersitzung jetzt serverseitig.

Die Ticket-Generation unter megbes.de/tickets/tine verwendet jetzt in js/project-const.js das absolute QR-Ziel https://www.tinetronics.de/mutec/. Der vorhandene Ticket-Code wird als systemCode übertragen; das Frontend aktiviert ihn und öffnet anschließend das Auswahlmenü. ticket.html lädt die aktualisierte Konfiguration mit einer Dateiversion. Den laufenden Ticket-Monitor nach dem Upload einmal neu laden. Die Änderung gilt für die Ticket-Generation des Projekts tine.

Besucher öffnen https://www.tinetronics.de/mutec/ und melden sich mit einem gültigen tine-Ticket an. Direkte Bedienseiten führen ohne Ticket oder passende Steuersitzung zum Login beziehungsweise zum Menü zurück. Die bisherige Medienoberfläche liegt nun unter remote.html.

== 5. Electron einmalig einrichten ==

Für Besucher gibt es keinen Zusatzcode. Die unbeaufsichtigte Electron-Anzeige benötigt einen privaten, rein lesenden DISPLAY_KEY. Der Installer erzeugt ihn in /etc/mutec-realtime.env. Er gehört weder ins Wiki noch in control/config.js.

Den Schlüssel als Administrator lokal aus der geschützten Datei entnehmen und den Platzhalter in views-tine.example.json ersetzen. Die maps-Ansicht erhält:

<pre>https://www.tinetronics.de/mutec/control/display.html#displayKey=DISPLAY_KEY_HIER_EINSETZEN</pre>

Das Fragment wird nicht als HTTP-Abfrage an den Webserver gesendet. Die Anzeige speichert es im Electron-Profil und entfernt es aus der sichtbaren Adresse. Nach Löschen des Electron-Profils erneut einrichten. views.json bleibt eine lokale Administrator-Datei. Der Schlüssel erlaubt ausschließlich den Empfang der Kartenereignisse, keine Stationsteuerung.

views.json auf PC 166 anpassen und Electron über das bestehende Verfahren neu starten. Die bisherige Aqua- und YouTube-URL bleiben wie in deiner Konfiguration. Karten-Auswahl: 166-maps und 50-maps. Aqua-Auswahl: 166-aqua und 50-aqua; deren bisherige HDMI-Umschaltung ebenfalls vor Ort prüfen.

== 6. Abnahme mit zwei Smartphones ==

# Ohne Ticket dürfen Bedienseiten keine Befehle oder Schreibzugriffe zulassen.
# Mit gültigem Ticket: Login → Menü → Aqua, Karte oder Medien.
# Ein zweites Ticket darf das Menü öffnen, aber keine Anwendung übernehmen. Auch Aqua ist exklusiv.
# „Zur Auswahl“ bei Besucher 1: Station 50 wird frei; Besucher 2 kann übernehmen. Alte Steuertokens müssen unwirksam sein.
# Stationsseitiges IDLE/Timeout für 50 auslösen: bisherige Sitzung verliert die Kontrolle; neue Auswahl erhält eine neue Reservierung.
# Karte verschieben und zoomen: gleicher Mittelpunkt, Zoom und Ausschnitt in Electron. Unterschiedliche Displayformate werden mit Rändern ausgeglichen; Verzögerung ist netzabhängig.
# Bedien-Tab schließen/Verbindung verlieren: lokale Relay-Sitzung läuft nach maximal etwa 55 Sekunden aus und meldet Station 50 ab, sofern MegBes erreichbar und das Ticket gültig ist.
# Relay-Ausfall, ungültiges Ticket oder MegBes-Ausfall: Station 50 muss über das bestehende Hardware-IDLE-Timeout frei werden. Es wird keine neue native 30-Sekunden-Reservierung eingeführt.
# Aqua-Tier speichern, Bewegungen sowie Medien-/YouTube-/Nachrichtenformulare prüfen. Featurefremde oder ungültige Tokens dürfen keine Dateien schreiben.
# UDP-Empfang und HDMI-Ausgabe am BrightSign tatsächlich prüfen.

Ein offener Bedien-Tab erneuert die Relay-Sitzung alle zehn Sekunden. Diese Verlängerung setzt keinen neuen nativen MegBes-Stationszeitstempel. Die vorhandenen MegBes-/Hardware-Zeitregeln bleiben maßgeblich. Nach einer stationsseitigen IDLE-Meldung wird nicht automatisch erneut reserviert: der Besucher muss neu auswählen.

Hier bestanden sieben Node-Tests: Ticket-/NoAuth-Abwehr, exklusive Belegung und konkurrierende Auswahl, IDLE-Abbruch, OPEN-Abweisung, Statusprüfung trotz irreführendem Anmelde-200, Befehlsrechte sowie HTTP/CORS/WebSocket-Rollen und Wiederverbindung. Lokal wurden Login, Menü, Belegung/Freigabe und Seitenzugriff mit simuliertem Backend geprüft. PHP-Syntax wurde geprüft; alle vier schreibenden Endpunkte wiesen Anfragen ohne Ticket mit HTTP 401 ab. Die QR-Erzeugung wurde mit simuliertem Backend geprüft, ohne Live-Tickets zu erzeugen. Echte Google-Karte, autorisierte PHP-Schreibvorgänge auf dem Website-Host und die Geräteausgabe bleiben Teil der Vor-Ort-Abnahme.

== 7. Fehlersuche und Rückkehr zum bisherigen Betrieb ==

* 401: Ticket/Sitzung ungültig, erneut anmelden.
* 409: Bildschirm belegt oder native Reservierung verloren; zur Auswahl zurückkehren.
* 503 mit Stationsstatus-Hinweis: bestehende controlled-Konfiguration und Erreichbarkeit prüfen; kein Backend-Patch erforderlich.
* OPEN-Hinweis: Station 50 muss idle melden. OPEN erlaubt mehrere Benutzer und ist hier ungeeignet.
* nginx 502: Relay-Dienst und Port prüfen.
* Google-Karte fehlt: API-Aktivierung, Website-Freigabe und Browser-Konsole prüfen.
* PHP-Schreiben scheitert: cURL, HTTPS-Erreichbarkeit, Token-Weiterleitung und Schreibrechte prüfen.

<pre>sudo journalctl -u mutec-realtime -n 80 --no-pager</pre>

Keine Tickets/Schlüssel in Logkopien übernehmen. Rollback: Relay stoppen, die beiden nginx-Ergänzungen entfernen und den gesicherten FTP-Ordner wiederherstellen. Die Installer-Sicherung enthält den vorherigen Relay-Ordner, dessen Umgebungsdatei und systemd-Datei, soweit vorhanden. MegBes-Programme werden nicht ersetzt und brauchen daher keinen Programm-Rollback.

== 8. Später auf messe wechseln ==

Nach separater Abnahme der vorhandenen Ticket-/Stationskonfiguration:

* js/project-const.js: EXTERNAL_SERVER_URL=https://messe.megbes.de und CUSTOMER=messe; aqua/js/project-const.js für Konsistenz mitführen.
* control/config.js: websocketUrl=wss://messe.megbes.de/mutec-control-ws, apiUrl=https://messe.megbes.de/mutec-control-api, room=messe-mutec-map.
* auth-config.php: relay_url auf https://messe.megbes.de/mutec-control-api.
* Dienst anhalten, /etc/mutec-realtime.env MEGBES_URL und CONTROL_ROOM auf messe ändern; nginx-Ergänzungen bei messe.megbes.de installieren; Dienst starten.

tine und messe nicht gleichzeitig auf dieselbe Relay-Instanz zeigen lassen. Für parallelen Betrieb eine zweite Instanz mit eigenem Port, Dienst, Umgebungsdatei und DISPLAY_KEY verwenden. Räume und Tickets bleiben projektgetrennt. Installierte Versionen, Prüfdatum und Abnahmeergebnis auf den Wiki-Projektseiten nachtragen, ohne Geheimwerte.

== Modularität und Ereignisprotokoll ==

Zugriff (realtime/access.js), Transport (server.js), Ereignisvalidatoren (protocol.js), Browser-Transport (control/client.js) und Karte (control/map.js) sind getrennt. Zukünftige Anwendungen ergänzen Feature-Freigaben/Befehlslisten und ihre Ereignisvalidatoren; Ticket und Stationssperre bleiben zentral.

Join: v=1, type=join, room=tine-mutec-map, role=controller oder display, accessToken. Der Controller verwendet ein kurzlebiges Relay-Token, die Anzeige den privaten DISPLAY_KEY. Kein Ticketcode im WebSocket-URL-Query.

<pre>{"v":1,"type":"event","topic":"map.camera","seq":1,"payload":{"lat":51.3397,"lng":12.3731,"zoom":13,"aspect":0.6}}</pre>

map.camera wird als letzter Zustand gespeichert und bei Wiederverbindung übertragen. seq steigt je Verbindung. input.pointer (phase/id/x/y, normalisierte Koordinaten) und input.orientation (alpha/beta/gamma in Grad) haben vorbereitete Validatoren. Neigungssteuerung und Sensorberechtigung sind noch kein implementiertes Bedienfeature. Relay-Grenze: 120 Nachrichten je Sekunde/Verbindung; Kartenmodul: höchstens etwa 30 Aktualisierungen/Sekunde. Nur der aktuelle Karten-Controller darf Ereignisse an Anzeigen senden.

== Ticket-Anmeldung – Korrektur vom 09.10.2026 ==

Die Anmeldung wurde zusätzlich mit eigenen Testtickets am laufenden tine-Backend und auf der veröffentlichten MUTEC-Seite geprüft. Aktivierung und anschließende Prüfung antworteten mit HTTP 200; der Browser erreichte das Auswahlmenü. Keine Station wurde dafür reserviert oder per UDP umgeschaltet.

Die Fehlerbehandlung wurde korrigiert: Ein Fehler der Steuersitzung verwirft kein bereits geprüftes MegBes-Ticket. Alte Steuersitzungen blockieren den Menü-Einstieg nicht. Ticket-Prüfungen umgehen den Browser-Cache. Nach erfolgreicher Aktivierung kann derselbe Browser eine gescheiterte Prüfung wiederholen, ohne erneut /enter-system aufzurufen. Bereits benutzte fremde Tickets werden weiterhin abgewiesen. Fünf zusätzliche Tests bestätigen diese Fälle. Sieben geänderte Website-Dateien wurden gesichert, hochgeladen und per Prüfsumme bestätigt; Versionskennung mutec3.

Der Administrator hat anschließend den erfolgreichen Ticket-Login auf dem Smartphone bestätigt. Bei künftigen Anmeldefehlern zeigt die Oberfläche den genauen Anmeldeschritt und HTTP-Status. Ein neuer Code auf dem Ticket-Monitor ist nach erfolgreicher Aktivierung normal.

== Sporadische Ticket-Prüfung: Untersuchung vom 09.10.2026 ==

=== Ursache und Korrektur der Projektzuordnung ===

Die später vom Administrator gelieferten Logs zeigen zur fehlgeschlagenen /verify-Anfrage „User known but not valid for customer“. Im geprüften MegBes-Quellcode nimmt /ticket den optionalen Query-Parameter customer entgegen. AuthMediaStationBaseService sucht unverbrauchte Tickets nach genau diesem customer und ticketMonitorNumber. Der bisherige tine-Monitor übergab keinen customer, also wurde nach customer=null und Monitor 1111 gesucht. In der gemeinsamen Datenbank können dabei Tickets aus anderen Projekten zurückgegeben werden. /enter-system prüft nur Existenz und Verbrauch, während /verify zusätzlich den Kunden des zugehörigen AuthObject mit dem laufenden Projekt vergleicht. Das erklärt die erfolgreiche Aktivierung mit anschließender 401. Die vorherigen Tests mit eigener Monitor-Nummer konnten diesen gemeinsamen Pool nicht abdecken. Die Cache-/Wiederholungsänderung allein behebt diese Ursache nicht.

Korrigiert am 09.10.2026: tickets/tine/js/ticket.js ruft jetzt /ticket?customer=tine&ticketMonitorNumber=1111 auf; der Kundenname wird aus CUSTOMER gelesen und URL-kodiert. ticket.html lädt die Datei mit Versionskennung 20261009-customer1. Beide Dateien sind lokal auf der Freigabe PC 134 und auf dem Webserver unter /megbes/tickets/tine gesichert, veröffentlicht und per Prüfsumme bestätigt. Der Abruf über https://www.megbes.de/tickets/tine wurde ebenfalls geprüft. Zwölf eigene Live-Testtickets mit customer=tine wurden erfolgreich aktiviert und jeweils dreimal geprüft. Der QR-Test prüft jetzt zusätzlich die ausdrückliche Projektzuordnung und Monitor-Nummer.

Den laufenden Ticket-Monitor vollständig neu laden (Strg+F5) und erst danach einen neu angezeigten QR-Code scannen. Alte QR-Codes können noch aus dem bisherigen Pool stammen. Keine MegBes-Programme oder Datenbankeinträge wurden für diese Korrektur verändert. Andere Ticket-Monitore/Templates sollten bei einer späteren separaten Prüfung ebenfalls den Projektnamen ausdrücklich mitsenden; diese Änderung betrifft ausschließlich tine. Die Prüfung des betroffenen Monitors nach dessen Neustart steht noch aus.

Der Administrator meldet erfolgreiche Ticket-Aktivierung und anschließend sporadisch HTTP 401 von /verify, auch mit frischen Codes und verschiedenen Browsern. Zwölf eigene Testtickets am getrennten Test-Monitor wurden erfolgreich aktiviert und jeweils dreimal geprüft. Zwei direkte Browser-Anmeldungen erreichten ebenfalls das Menü. Diese Tests reservierten keine Station und schalteten keine Geräte um. Zu diesem frühen Prüfzeitpunkt war die Ursache noch nicht nachgewiesen; die anschließend gelieferten Serverlogs und der Ticket-Abruf sind im vorstehenden Abschnitt ausgewertet.

Die Frontend-Version mutec4 versieht jede /verify-Anfrage mit einem unabhängigen, geheimnisfreien mutec_check-Parameter und cache:no-store. Eine 401 wird nach 250 und 750 Millisekunden mit neuer Adresse wiederholt. Nur ein erfolgreicher Prüfstatus erlaubt den Einstieg; drei 401 bleiben gesperrt. /enter-system wird dabei nicht erneut aufgerufen, fremde bereits verwendete Codes bleiben abgewiesen. Acht Frontend-Tests bestätigen unter anderem temporäre und dauerhafte 401 sowie die getrennte Behandlung von 403. Die Änderung schützt gegen veraltete Prüfantworten und kurze Übergangsfehler, belegt aber nicht, dass einer dieser Fälle die Ursache des gemeldeten Problems ist. Sieben Website-Dateien wurden gesichert, hochgeladen und per Prüfsumme bestätigt. Eine weitere Anmeldung mit frischem Testticket erreichte auf der veröffentlichten Version das Menü, auch mit einem Code mit führenden Nullen. Der tatsächlich verwendete Monitor https://www.megbes.de/tickets/tine/login.html und seine vier zugehörigen HTML-/JS-Dateien entsprechen den lokalen Quellen, verwenden tine und Monitor 1111 und werden mit no-cache/no-store ausgeliefert. Eine erneute Prüfung am betroffenen Ticket-Monitor steht aus. Keine MegBes-Backend-Änderungen und kein neuer Relay-Installationsschritt.

== Zur Auswahl: Trailer und IDLE ==

Die Frontend-Version mutec5 fordert beim Klick auf „Zur Auswahl“ die Freigabe mit DELETE /mutec-control-api/session?returnToTrailer=1 an. Das aktualisierte separate Relay prüft Ticket und aktive Belegung, sendet über die bestehende MegBes-API genau 50-Trailer und meldet anschließend die Station ab. Der BrightSign kann nach seiner Trailer-Umschaltung selbst IDLE melden. Senden und Freigabe werden in derselben Warteschlange ausgeführt, damit eine neue MUTEC-Sitzung nicht dazwischen übernehmen kann. Die normalen Feature-Befehlslisten werden nicht erweitert.

Bei einem Sendefehler bleibt das Token im Browser erhalten und die Fehlermeldung erlaubt einen erneuten Versuch. Bereits entfernte oder fremde Sitzungen schicken keinen Trailer an einen neuen Bediener. Abmelden und automatische Freigaben sind unverändert; diese Ergänzung betrifft den Auswahl-Button in Karte, Aqua und Medien. Zehn Relay-Tests und zehn Frontend-Tests sind erfolgreich, einschließlich tatsächlicher HTTP-Route, Befehlsreihenfolge, Ticket-Widerruf, verlorener Belegung und wiederholbarer Sendefehler.

Der Root-Administrator muss das vorbereitete Update einmal ausführen: bash /home/clawtronics/mutec-trailer-update/apply-update.sh. Es prüft das Paket, testet vor dem Austausch, sichert und ersetzt ausschließlich access.js, server.js und test/relay.test.js des separaten Relays und startet mutec-realtime neu. Fehler führen zur Wiederherstellung. /etc/mutec-realtime.env und DISPLAY_KEY werden nicht verändert. Health muss anschließend returnToTrailer:true enthalten. Frontend-Dateien müssen mit der neuen Versionskennung hochgeladen sein. Bis zur Installation des Relay-Updates bleibt dessen bisheriges Freigabeverhalten aktiv. Nach der Installation Bedienseite neu laden und die tatsächliche Trailer-/IDLE-Reaktion von Station 50 prüfen.

Siehe auch [[Web-Frontend entwickeln]], [[UDP und Stationszustände]], [[Tine]] und [[Messe]].

[[Kategorie:MegBes]]
[[Kategorie:Frontend]]
[[Kategorie:Entwicklung]]

== Papierflug mit Smartphone-Neigung ==
Stand 10.10.2026: [[MUTEC – Papierflug]] ergänzt eine modulare three.js-Anwendung mit Neigungs- und Touch-Steuerung, Ringen, Punkten und Rückkanal zum Smartphone. Frontend veröffentlicht, Electron-Reiter flight auf PC 166 vorbereitet; separates Relay-Update geprüft und zur root-Installation bereitgestellt. Keine Änderungen an megbes-external/megbes-internal. Die Installation und der Flug mit echten Sensoren sind noch zu bestätigen. Vollständige Einrichtung und Protokollbeschreibung auf der verlinkten Seite.

== Pong mit eingeschränktem Gastzugang ==
Stand 10.10.2026: [[MUTEC – Pong]] ergänzt Pong gegen den Computer oder einen zweiten Smartphone-Spieler. Spieler 1 reserviert Station 50 per MegBes-Ticket. Ein kurzlebiger, einmaliger QR-Code erlaubt dem Gast ausschließlich den rechten Schläger; keine Ticket-, UDP-, Neustart- oder Stationsbefugnisse. Frontend veröffentlicht, Electron-Reiter pong auf PC 166 ergänzt. Separates Relay-Update mit 17 Prüfungen auf dem VPS vorbereitet; root-Installation und Abnahme mit zwei Smartphones stehen aus. Keine Änderungen an megbes-external/megbes-internal. Einrichtung, Berechtigungsmodell und Protokoll auf der verlinkten Seite.

== HTML-Video mit Smartphone-Ton ==
[[MUTEC – HTML-Video]] ergänzt Video in Electron mit Play/Pause, Spulen, Kapiteln, Sprachwahl und laufender Audio-Zeitkorrektur. Frontend hochgeladen, Electron konfiguriert, Relay durch root installiert und video:true geprüft. Details und Abnahme auf der verlinkten Seite. Keine Änderungen am MegBes-Backend.

== Arcade-Erweiterung ==
Stand 11.10.2026: [[MUTEC – Arcade]] dokumentiert das zusätzlich angebotene Pöng mit Zweifinger-Steuerung und eingeschränktem Gastzugang, Papierflug mit Ringanimationen/Serien/Bonusringen und dauerhafter dreistelliger Arcade-Bestenliste sowie Finde den Ort mit serverseitiger Hinweisausgabe und Wertung. Spiel-Sounds sind auf dem Smartphone zuschaltbar. Wichtige Anzeigen liegen in der mittleren Bildhälfte; Karte synchronisiert die Nord-Süd-Ausdehnung. Aqua-Navigation und JSON-Token-Transport wurden korrigiert. Frontend hochgeladen, Relay vom Administrator installiert (24 Tests), öffentliche Funktionen geprüft. Electron-Reiter poeng ergänzt; Neustart und Hardware-Abnahme vor Ort. MegBes-external/-internal unverändert.

== Intro, Spiel und Schluss ==
[[MUTEC – Spielablauf]] beschreibt die Infokarten, getrennten Spiel-/Ergebnisansichten und den zustimmungspflichtigen Gastbeitritt für Pong/Pöng mit beidseitiger Bereitschaft und Countdown. 32 Servertests und Browserprüfungen bestanden. Frontend hochgeladen; Serverpaket unter /home/clawtronics/mutec-flow-update vom Administrator installiert. Alle 32 Tests und die echte Schreibprüfung bestanden; gameFlow ist öffentlich aktiviert. Der Installer korrigiert auch die Schreibfreigabe für /opt/mutec-realtime/data, ohne bestehende Bestenlisten zu ersetzen. MegBes-Programme bleiben unverändert.

== Freigabe nach Ticketablauf ==
Der Administrator hat das Ticketablauf-Update installiert; mutec-realtime und mutec-expiry-watchdog.timer wurden anschließend als aktiv geprüft. Ein separater privater root-Wächter liest ausschließlich die vorhandenen Mongo-Ticket-/Stationsmetadaten und verwendet die bestehende mTLS-Verbindung zu tine-dyndns.megbes.de:18921. Nur tine / Station 50: Abgelaufene REMOTE-Belegung → 50-Trailer → Hardware-IDLE abwarten, gegebenenfalls vorhandenen nativen Reset mit bestätigtem IDLE. Gültige oder unbekannte aktuelle Belegungen sowie fremde/OPEN/TOUCHSCREEN-Belegung werden nicht umgeschaltet. Prüfung etwa alle zehn Sekunden; bei Verbindungsfehlern erneuter Versuch. Besitzer-Zwischenspeicher privat unter /var/lib/mutec-expiry-watchdog, keine Tickets/JWT/Schlüssel. Mongo wird nicht verändert. Relay-Steuerrechte enden sofort; fehlgeschlagene Freigaben bleiben vorgemerkt. Keine Änderungen an megbes-external/-internal und kein öffentlicher administrativer Endpunkt. Die Hardware-Freigabe ist vor Ort zu prüfen.

== Mobile Pong-Einladung ==
Stand 12.10.2026: Für Pong und Pöng wurde der QR-Code vom LED-Counter auf das Smartphone von Spieler 1 verlegt. Der Counter enthält kein QR-/Einladungspanel mehr; seine Punkteanzeige liegt mittig. Letzte Infokarte: '1 Spieler starten' gegen den Computer oder '2 Spieler' für einen großen unverzerrten QR-Code auf dem eigenen Smartphone. Nach ausdrücklicher Zweispielerwahl im Intro und Gastbeitritt gilt die Einladung bereits als Zustimmung. Bei einer späteren Einladung über den 2-Spieler-Button im laufenden Spiel bleibt die Computerrunde bis zur ausdrücklichen Annahme erhalten. Gast-Infokarten, Bereitschaft und Countdown bleiben bestehen. Gäste erhalten keine weiteren MegBes-Rechte.

Neue Relay-Route POST /mutec-control-api/pong/invite: Nur der aktuelle Besitzer seiner eigenen Pong-/Pöng-Sitzung darf eine kurzlebige einmalige Einladung abrufen. Gäste, fremde Module und abgelaufene Sitzungen sind ausgeschlossen. Der Display-Schlüssel wird nicht an das Smartphone übergeben. Frontend hochgeladen und Browserprüfung mit getrennten Smartphones/Display bestanden. Serverpaket unter /home/clawtronics/mutec-invite-update vorbereitet; 38 Tests auf dem VPS bestanden. Root-Installation steht noch aus: bash /home/clawtronics/mutec-invite-update/apply-invite-update.sh. Der Installer sichert und ersetzt nur server.js und den Relay-Test, prüft den unveränderten Ausgangsstand und startet den Relay neu. Flight-Wettbewerb, Bestenlisten, Ticketablauf-Wächter, DISPLAY_KEY und MegBes-external/-internal bleiben erhalten. Danach Smartphone-Seiten und Electron-Webseiten neu laden.

== Einheitliche Spiele und Bestenlisten ==
Stand 13.10.2026: [[MUTEC – Einheitliche Spiele]] dokumentiert optionale Zweispielerrunden auch für Finde den Ort, vier getrennte Top-10-Listen ausschließlich auf der Electron-Anzeige vor/nach dem Spiel und eigene qualifizierte Arcade-Einträge für Besitzer/Gast. Pong/Pöng werten Tore und aktive Zeit mit Siegbonus. Die vorhandene Flight-Wertung und die Karte mit getrennten Kameras/Hinweisen bleiben erhalten. Frontend hochgeladen und geprüft; 48 Servertests auf dem VPS bestanden. Serverpaket unter /home/clawtronics/mutec-unified-update am 13.10.2026 erfolgreich installiert; alle 48 Tests und die Schreibpruefung bestanden. Die oeffentliche API meldet unifiedGames=true; Relay und Ticketablauf-Waechter sind aktiv. Daten, Schlüssel, Objects, HTML-Video und MegBes-Programme bleiben erhalten.

== Native BrightSign-Videos ==
Stand 15.10.2026: [[MUTEC – Native BrightSign-Videos]] dokumentiert den eigenen Smartphone-Menuepunkt fuer Wasser mit nativer BrightAuthor-Wiedergabe auf Station 50, echter Positionsrueckmeldung und Smartphone-Ton. Frontend veroeffentlicht, Serverpaket am 15.10.2026 mit 65 bestandenen Tests installiert. Oeffentliche API bestaetigt nativevideo=true; Relay und Ticketablauf-Waechter aktiv. BrightAuthor-Veroeffentlichung und Hardwaretest noch ausstehend.

MUTEC – Native BrightSign-Videos

2026-10-15T10:13:01Z

Clawtronics: Erfolgreiche Serverinstallation und oeffentliche nativevideo-Freigabe bestaetigt

MUTEC – WebSocket-Steuerung

2026-10-15T09:45:23Z

Clawtronics: Native Wasser-Wiedergabe mit Smartphone-Ton und getrenntem Steuerkanal vorbereitet

= MUTEC v2 – Einrichtung mit MegBes-Ticket =

Stand: 09.10.2026. Das MUTEC-Frontend und die QR-Zieladresse des Ticket-Monitors tine wurden auf den Webspace hochgeladen und per Prüfsumme sowie HTTPS geprüft. Der Administrator hat den separaten WebSocket-Dienst auf dem VPS installiert: sieben Tests erfolgreich, systemd aktiv und lokaler Health-Check erfolgreich. Die öffentliche API-Route beantwortet den CORS-Preflight mit HTTP 204. Der Ticket-Login funktioniert laut Gerätetest. Google Maps und die Electron-Anzeige funktionieren laut Gerätetest. Die Projektzuordnung im Ticket-Monitor wurde anschließend korrigiert; dessen erneute Prüfung und die vollständige Geräteabnahme stehen aus. v2 ersetzt die früheren Pakete mit CONTROL_TOKEN.

== Aktuelle Inbetriebnahme: Google Maps und Electron ==

Nachtrag: Die Google-Karte funktioniert laut Gerätetest auf dem Smartphone. Chrome auf PC 166 zeigt die Karte mit DISPLAY_KEY und übernimmt die Smartphone-Bewegungen. Der verbleibende Electron-Fehler wurde im Programm gefunden und am 09.10.2026 korrigiert: loadConfiguredView hing den Parameter aquariumReload als Text hinter das URL-Fragment. Dadurch wurde der Zusatz Teil des DISPLAY_KEY und die Anzeige wies ihn ab. Die URL wird nun mit URL und searchParams erzeugt, sodass der Parameter vor dem unveränderten Fragment steht. Quellcode electron-main.js und resources/app.asar unter \\192.168.14.166\C-Platte\xampp\htdocs\aquasphaere\aquarium wurden gesichert und korrigiert. Die Konfiguration liegt für die gepackte Anwendung neben der EXE in dist/win-unpacked/views.json und enthält bereits einen formal gültigen Schlüssel. Vier URL-Fälle je Quellcodeversion wurden geprüft, das gepackte Ergebnis zurückgelesen. Der Administrator hat nach dem Neustart die Kartenanzeige in Electron bestätigt.

Die Google-Maps-Diagnose der öffentlichen Kartenanzeige liefert <code>RefererNotAllowedMapError</code> für https://www.tinetronics.de/mutec/control/display.html. Der eingebundene Google-Schlüssel endet auf iJd80U. Bei genau diesem Schlüssel unter Google Cloud → APIs und Dienste → Anmeldedaten → Website-Einschränkungen die Freigabe https://www.tinetronics.de/* prüfen und speichern. Danach einige Minuten warten und die Kartenseite neu laden. Die konkrete Diagnose weist auf die Website-Freigabe hin; ein neues Relay-Paket ist dafür nicht erforderlich.

Die Electron-Meldung „Diese Anzeige ist noch nicht in Electron eingerichtet“ bedeutet, dass der private DISPLAY_KEY fehlt. Auf dem VPS mit <code>sudo grep '^DISPLAY_KEY=' /etc/mutec-realtime.env</code> lokal ablesen. Nur den Wert hinter dem Gleichheitszeichen in views.json als https://www.tinetronics.de/mutec/control/display.html#displayKey=WERT einsetzen. Den Schlüssel nicht in Wiki oder Chat veröffentlichen. Electron anschließend neu starten. Der Schlüssel berechtigt ausschließlich die Anzeige und ersetzt keinen Besucher-Ticket-Code.

== Ergebnis und Bedienung ==

MegBes-Ticket → Auswahlmenü → Aqua, Karte oder Medien. Keine Stationseingabe und kein zusätzliches Besucher-Passwort. Alle Anwendungen belegen Station 50 exklusiv als REMOTE. Andere Besucher dürfen das Auswahlmenü öffnen, aber den belegten Bildschirm nicht übernehmen. „Zur Auswahl“ und „Abmelden“ geben Station 50 über die vorhandene MegBes-Stationsabmeldung frei. Eine stationsseitige IDLE-Meldung beendet die bisherige Steuersitzung spätestens beim nächsten Befehl, einer neuen Auswahl oder nach etwa zehn Sekunden.

Der PC 166 bleibt das Ziel der bestehenden UDP-Befehle. Die Karte sendet 166-maps für Electron und 50-maps für den HDMI-Eingang des BrightSign. Es wird keine zusätzliche native Stationsgruppe oder Backend-Erweiterung eingeführt. megbes-external und megbes-internal bleiben unverändert.

== Pakete ==

* MUTEC-v2-server.tar.gz: separater Node-WebSocket-Dienst, Installer, systemd-Datei, zwei nginx-Weiterleitungen und sieben Tests.
* MUTEC-v2-frontend.zip: aktualisierte Dateien für den bereits vorhandenen FTP-Ordner /tinetronics_de/mutec. Vorhandene Bilder, Audios, Bibliotheken und Aquarium-Dateien bleiben Voraussetzung.
* views-tine.example.json: vollständiges Beispiel der Electron-Ansichten. Den privaten Anzeigeschlüssel einsetzen.

== 1. Vorhandene MegBes-Konfiguration prüfen ==

Auf dem zentralen Server 87.106.33.238 läuft megbes-external-tine. Der lokale MegBes-Server mit megbes-internal wird weiterhin über die vorhandene Projektkonfiguration angesprochen. Keine Installation in BrightSign oder Electron und kein Austausch der MegBes-Programme.

Voraussetzung sind die bestehende Ticket-Sicherheit und der bereits von MegBes unterstützte Modus intern kontrollierter Stationen. Im aktuellen Quellcode heißen die Einstellungen megbes.security=true (External) und megbes.internal.station.controlled=true (External und Internal). Die bestehenden Umgebungsvariablen heißen MEGBES_SECURITY und MEGBES_INTERNAL_STATION_CONTROLLED. Aktuelle effektive Werte prüfen: Wiki und OpenClaw enthalten unterschiedliche historische Angaben zum tine-Stationsmodus. Diese Schalter nicht ungeprüft ändern; der Stationsmodus betrifft das ganze Projekt.

Station 50 muss im Ruhezustand IDLE melden, nicht OPEN. OPEN ist die normale MegBes-Freigabe für Mehrfachbedienung und wird von dieser MUTEC-Version abgewiesen. BrightSign-Start-/Timeout-Meldungen für Station 50 entsprechend auf idle einstellen. Eine regelmäßige OPEN-Meldung während der Bedienung darf REMOTE nicht überschreiben. Das stationsseitige Timeout muss nach beendeter Bedienung IDLE senden können.

Der Dienst verwendet ausschließlich vorhandene Endpunkte:

<pre>POST /enter-system Ticket aktivieren (Frontend)
GET /verify Ticket prüfen
GET /media-station?station=50 Station anmelden
GET /media-station/status/50 REMOTE und Berechtigung prüfen
DELETE /media-station Station abmelden
POST /video-command erlaubte UDP-Befehle senden</pre>

Die bestehende Anmeldung kann trotz fehlgeschlagener interner Reservierung HTTP 200 liefern. Deshalb prüft das Relay vor und nach der Anmeldung den tatsächlichen Stationsstatus. Ein 403, OPEN, TOUCHSCREEN oder unerwarteter Zustand erlaubt keine Übernahme. Vor dem Start wird auch die Erreichbarkeit/Berechtigung für PC 166 geprüft; PC 166 wird nicht separat reserviert.

Für das gleiche Ticket soll keine zweite Anwendung außerhalb MUTEC parallel eine andere MegBes-Station anmelden: MegBes verwaltet pro Benutzer eine aktuelle Station. Die exklusive MUTEC-Nutzung gilt für den angeschlossenen Bildschirm und die über dieses Frontend angebotenen Funktionen.

== 2. WebSocket-Dienst auf 87.106.33.238 installieren ==

Als Administrator das Archiv in ein privates Arbeitsverzeichnis auf dem zentralen Plesk-Server kopieren und auspacken:

<pre>mkdir -p ~/mutec-v2-setup
cd ~/mutec-v2-setup
tar -xzf /pfad/zur/MUTEC-v2-server.tar.gz
cd MUTEC-v2-server
sudo bash install.sh</pre>

Der Installer verwendet das vorhandene Plesk-Node unter /opt/plesk/node/24/bin/node. Er erzeugt den Dienstbenutzer mutec-realtime, installiert festgelegte Abhängigkeiten und startet den Dienst ausschließlich auf 127.0.0.1:8089. Kein zusätzlicher öffentlicher Port. Ein vorhandener MUTEC-Relay wird vorher unter /var/backups/mutec-realtime privat gesichert. Ein vorhandener DISPLAY_KEY bleibt erhalten; CONTROL_TOKEN aus v1 entfällt. Der Installer verändert keine MegBes-Container oder deren Konfiguration.

<pre>sudo systemctl status mutec-realtime --no-pager
curl --fail http://127.0.0.1:8089/health</pre>

Erwartet: aktiver Dienst und JSON mit version 2. Health bestätigt den laufenden Relay-Prozess, noch nicht MegBes-Reservierung oder Hardware-Ausgabe.

== 3. Zwei Weiterleitungen in Plesk ergänzen ==

Bei tine.megbes.de → Apache & nginx-Einstellungen → Zusätzliche nginx-Anweisungen den Inhalt von nginx-tine.conf ergänzen. Vorhandene MegBes-Anweisungen erhalten. Die Datei enthält /mutec-control-ws für WebSockets und /mutec-control-api/ für Steuersitzungen. Speichern und prüfen:

<pre>sudo nginx -t</pre>

Öffentlich: wss://tine.megbes.de/mutec-control-ws und https://tine.megbes.de/mutec-control-api. Bestehende Ticket-/MegBes-Routen bleiben unverändert. Es wird kein Geheimwert in nginx eingetragen.

== 4. Website über FTP aktualisieren ==

Den bisherigen Ordner /tinetronics_de/mutec vollständig sichern. Danach den Inhalt von MUTEC-v2-frontend.zip darüber kopieren, Unterordner beibehalten. Dieser Ordner liegt auf dem Website-Host 217.160.0.178, nicht auf dem MegBes-VPS. realtime/ gehört nicht in den öffentlichen Webordner.

Google Maps verwendet den bestehenden Browserschlüssel in control/config.js. Maps JavaScript API und Abrechnung müssen aktiv sein; https://www.tinetronics.de/* ist nach deiner Angabe bereits freigegeben. PHP benötigt mindestens 8.0 mit cURL, ausgehendes HTTPS zu tine.megbes.de sowie die bestehenden Schreibrechte für Aqua und die Medien-Dateien. Schreibende PHP-Aufrufe prüfen die passende Steuersitzung jetzt serverseitig.

Die Ticket-Generation unter megbes.de/tickets/tine verwendet jetzt in js/project-const.js das absolute QR-Ziel https://www.tinetronics.de/mutec/. Der vorhandene Ticket-Code wird als systemCode übertragen; das Frontend aktiviert ihn und öffnet anschließend das Auswahlmenü. ticket.html lädt die aktualisierte Konfiguration mit einer Dateiversion. Den laufenden Ticket-Monitor nach dem Upload einmal neu laden. Die Änderung gilt für die Ticket-Generation des Projekts tine.

Besucher öffnen https://www.tinetronics.de/mutec/ und melden sich mit einem gültigen tine-Ticket an. Direkte Bedienseiten führen ohne Ticket oder passende Steuersitzung zum Login beziehungsweise zum Menü zurück. Die bisherige Medienoberfläche liegt nun unter remote.html.

== 5. Electron einmalig einrichten ==

Für Besucher gibt es keinen Zusatzcode. Die unbeaufsichtigte Electron-Anzeige benötigt einen privaten, rein lesenden DISPLAY_KEY. Der Installer erzeugt ihn in /etc/mutec-realtime.env. Er gehört weder ins Wiki noch in control/config.js.

Den Schlüssel als Administrator lokal aus der geschützten Datei entnehmen und den Platzhalter in views-tine.example.json ersetzen. Die maps-Ansicht erhält:

<pre>https://www.tinetronics.de/mutec/control/display.html#displayKey=DISPLAY_KEY_HIER_EINSETZEN</pre>

Das Fragment wird nicht als HTTP-Abfrage an den Webserver gesendet. Die Anzeige speichert es im Electron-Profil und entfernt es aus der sichtbaren Adresse. Nach Löschen des Electron-Profils erneut einrichten. views.json bleibt eine lokale Administrator-Datei. Der Schlüssel erlaubt ausschließlich den Empfang der Kartenereignisse, keine Stationsteuerung.

views.json auf PC 166 anpassen und Electron über das bestehende Verfahren neu starten. Die bisherige Aqua- und YouTube-URL bleiben wie in deiner Konfiguration. Karten-Auswahl: 166-maps und 50-maps. Aqua-Auswahl: 166-aqua und 50-aqua; deren bisherige HDMI-Umschaltung ebenfalls vor Ort prüfen.

== 6. Abnahme mit zwei Smartphones ==

# Ohne Ticket dürfen Bedienseiten keine Befehle oder Schreibzugriffe zulassen.
# Mit gültigem Ticket: Login → Menü → Aqua, Karte oder Medien.
# Ein zweites Ticket darf das Menü öffnen, aber keine Anwendung übernehmen. Auch Aqua ist exklusiv.
# „Zur Auswahl“ bei Besucher 1: Station 50 wird frei; Besucher 2 kann übernehmen. Alte Steuertokens müssen unwirksam sein.
# Stationsseitiges IDLE/Timeout für 50 auslösen: bisherige Sitzung verliert die Kontrolle; neue Auswahl erhält eine neue Reservierung.
# Karte verschieben und zoomen: gleicher Mittelpunkt, Zoom und Ausschnitt in Electron. Unterschiedliche Displayformate werden mit Rändern ausgeglichen; Verzögerung ist netzabhängig.
# Bedien-Tab schließen/Verbindung verlieren: lokale Relay-Sitzung läuft nach maximal etwa 55 Sekunden aus und meldet Station 50 ab, sofern MegBes erreichbar und das Ticket gültig ist.
# Relay-Ausfall, ungültiges Ticket oder MegBes-Ausfall: Station 50 muss über das bestehende Hardware-IDLE-Timeout frei werden. Es wird keine neue native 30-Sekunden-Reservierung eingeführt.
# Aqua-Tier speichern, Bewegungen sowie Medien-/YouTube-/Nachrichtenformulare prüfen. Featurefremde oder ungültige Tokens dürfen keine Dateien schreiben.
# UDP-Empfang und HDMI-Ausgabe am BrightSign tatsächlich prüfen.

Ein offener Bedien-Tab erneuert die Relay-Sitzung alle zehn Sekunden. Diese Verlängerung setzt keinen neuen nativen MegBes-Stationszeitstempel. Die vorhandenen MegBes-/Hardware-Zeitregeln bleiben maßgeblich. Nach einer stationsseitigen IDLE-Meldung wird nicht automatisch erneut reserviert: der Besucher muss neu auswählen.

Hier bestanden sieben Node-Tests: Ticket-/NoAuth-Abwehr, exklusive Belegung und konkurrierende Auswahl, IDLE-Abbruch, OPEN-Abweisung, Statusprüfung trotz irreführendem Anmelde-200, Befehlsrechte sowie HTTP/CORS/WebSocket-Rollen und Wiederverbindung. Lokal wurden Login, Menü, Belegung/Freigabe und Seitenzugriff mit simuliertem Backend geprüft. PHP-Syntax wurde geprüft; alle vier schreibenden Endpunkte wiesen Anfragen ohne Ticket mit HTTP 401 ab. Die QR-Erzeugung wurde mit simuliertem Backend geprüft, ohne Live-Tickets zu erzeugen. Echte Google-Karte, autorisierte PHP-Schreibvorgänge auf dem Website-Host und die Geräteausgabe bleiben Teil der Vor-Ort-Abnahme.

== 7. Fehlersuche und Rückkehr zum bisherigen Betrieb ==

* 401: Ticket/Sitzung ungültig, erneut anmelden.
* 409: Bildschirm belegt oder native Reservierung verloren; zur Auswahl zurückkehren.
* 503 mit Stationsstatus-Hinweis: bestehende controlled-Konfiguration und Erreichbarkeit prüfen; kein Backend-Patch erforderlich.
* OPEN-Hinweis: Station 50 muss idle melden. OPEN erlaubt mehrere Benutzer und ist hier ungeeignet.
* nginx 502: Relay-Dienst und Port prüfen.
* Google-Karte fehlt: API-Aktivierung, Website-Freigabe und Browser-Konsole prüfen.
* PHP-Schreiben scheitert: cURL, HTTPS-Erreichbarkeit, Token-Weiterleitung und Schreibrechte prüfen.

<pre>sudo journalctl -u mutec-realtime -n 80 --no-pager</pre>

Keine Tickets/Schlüssel in Logkopien übernehmen. Rollback: Relay stoppen, die beiden nginx-Ergänzungen entfernen und den gesicherten FTP-Ordner wiederherstellen. Die Installer-Sicherung enthält den vorherigen Relay-Ordner, dessen Umgebungsdatei und systemd-Datei, soweit vorhanden. MegBes-Programme werden nicht ersetzt und brauchen daher keinen Programm-Rollback.

== 8. Später auf messe wechseln ==

Nach separater Abnahme der vorhandenen Ticket-/Stationskonfiguration:

* js/project-const.js: EXTERNAL_SERVER_URL=https://messe.megbes.de und CUSTOMER=messe; aqua/js/project-const.js für Konsistenz mitführen.
* control/config.js: websocketUrl=wss://messe.megbes.de/mutec-control-ws, apiUrl=https://messe.megbes.de/mutec-control-api, room=messe-mutec-map.
* auth-config.php: relay_url auf https://messe.megbes.de/mutec-control-api.
* Dienst anhalten, /etc/mutec-realtime.env MEGBES_URL und CONTROL_ROOM auf messe ändern; nginx-Ergänzungen bei messe.megbes.de installieren; Dienst starten.

tine und messe nicht gleichzeitig auf dieselbe Relay-Instanz zeigen lassen. Für parallelen Betrieb eine zweite Instanz mit eigenem Port, Dienst, Umgebungsdatei und DISPLAY_KEY verwenden. Räume und Tickets bleiben projektgetrennt. Installierte Versionen, Prüfdatum und Abnahmeergebnis auf den Wiki-Projektseiten nachtragen, ohne Geheimwerte.

== Modularität und Ereignisprotokoll ==

Zugriff (realtime/access.js), Transport (server.js), Ereignisvalidatoren (protocol.js), Browser-Transport (control/client.js) und Karte (control/map.js) sind getrennt. Zukünftige Anwendungen ergänzen Feature-Freigaben/Befehlslisten und ihre Ereignisvalidatoren; Ticket und Stationssperre bleiben zentral.

Join: v=1, type=join, room=tine-mutec-map, role=controller oder display, accessToken. Der Controller verwendet ein kurzlebiges Relay-Token, die Anzeige den privaten DISPLAY_KEY. Kein Ticketcode im WebSocket-URL-Query.

<pre>{"v":1,"type":"event","topic":"map.camera","seq":1,"payload":{"lat":51.3397,"lng":12.3731,"zoom":13,"aspect":0.6}}</pre>

map.camera wird als letzter Zustand gespeichert und bei Wiederverbindung übertragen. seq steigt je Verbindung. input.pointer (phase/id/x/y, normalisierte Koordinaten) und input.orientation (alpha/beta/gamma in Grad) haben vorbereitete Validatoren. Neigungssteuerung und Sensorberechtigung sind noch kein implementiertes Bedienfeature. Relay-Grenze: 120 Nachrichten je Sekunde/Verbindung; Kartenmodul: höchstens etwa 30 Aktualisierungen/Sekunde. Nur der aktuelle Karten-Controller darf Ereignisse an Anzeigen senden.

== Ticket-Anmeldung – Korrektur vom 09.10.2026 ==

Die Anmeldung wurde zusätzlich mit eigenen Testtickets am laufenden tine-Backend und auf der veröffentlichten MUTEC-Seite geprüft. Aktivierung und anschließende Prüfung antworteten mit HTTP 200; der Browser erreichte das Auswahlmenü. Keine Station wurde dafür reserviert oder per UDP umgeschaltet.

Die Fehlerbehandlung wurde korrigiert: Ein Fehler der Steuersitzung verwirft kein bereits geprüftes MegBes-Ticket. Alte Steuersitzungen blockieren den Menü-Einstieg nicht. Ticket-Prüfungen umgehen den Browser-Cache. Nach erfolgreicher Aktivierung kann derselbe Browser eine gescheiterte Prüfung wiederholen, ohne erneut /enter-system aufzurufen. Bereits benutzte fremde Tickets werden weiterhin abgewiesen. Fünf zusätzliche Tests bestätigen diese Fälle. Sieben geänderte Website-Dateien wurden gesichert, hochgeladen und per Prüfsumme bestätigt; Versionskennung mutec3.

Der Administrator hat anschließend den erfolgreichen Ticket-Login auf dem Smartphone bestätigt. Bei künftigen Anmeldefehlern zeigt die Oberfläche den genauen Anmeldeschritt und HTTP-Status. Ein neuer Code auf dem Ticket-Monitor ist nach erfolgreicher Aktivierung normal.

== Sporadische Ticket-Prüfung: Untersuchung vom 09.10.2026 ==

=== Ursache und Korrektur der Projektzuordnung ===

Die später vom Administrator gelieferten Logs zeigen zur fehlgeschlagenen /verify-Anfrage „User known but not valid for customer“. Im geprüften MegBes-Quellcode nimmt /ticket den optionalen Query-Parameter customer entgegen. AuthMediaStationBaseService sucht unverbrauchte Tickets nach genau diesem customer und ticketMonitorNumber. Der bisherige tine-Monitor übergab keinen customer, also wurde nach customer=null und Monitor 1111 gesucht. In der gemeinsamen Datenbank können dabei Tickets aus anderen Projekten zurückgegeben werden. /enter-system prüft nur Existenz und Verbrauch, während /verify zusätzlich den Kunden des zugehörigen AuthObject mit dem laufenden Projekt vergleicht. Das erklärt die erfolgreiche Aktivierung mit anschließender 401. Die vorherigen Tests mit eigener Monitor-Nummer konnten diesen gemeinsamen Pool nicht abdecken. Die Cache-/Wiederholungsänderung allein behebt diese Ursache nicht.

Korrigiert am 09.10.2026: tickets/tine/js/ticket.js ruft jetzt /ticket?customer=tine&ticketMonitorNumber=1111 auf; der Kundenname wird aus CUSTOMER gelesen und URL-kodiert. ticket.html lädt die Datei mit Versionskennung 20261009-customer1. Beide Dateien sind lokal auf der Freigabe PC 134 und auf dem Webserver unter /megbes/tickets/tine gesichert, veröffentlicht und per Prüfsumme bestätigt. Der Abruf über https://www.megbes.de/tickets/tine wurde ebenfalls geprüft. Zwölf eigene Live-Testtickets mit customer=tine wurden erfolgreich aktiviert und jeweils dreimal geprüft. Der QR-Test prüft jetzt zusätzlich die ausdrückliche Projektzuordnung und Monitor-Nummer.

Den laufenden Ticket-Monitor vollständig neu laden (Strg+F5) und erst danach einen neu angezeigten QR-Code scannen. Alte QR-Codes können noch aus dem bisherigen Pool stammen. Keine MegBes-Programme oder Datenbankeinträge wurden für diese Korrektur verändert. Andere Ticket-Monitore/Templates sollten bei einer späteren separaten Prüfung ebenfalls den Projektnamen ausdrücklich mitsenden; diese Änderung betrifft ausschließlich tine. Die Prüfung des betroffenen Monitors nach dessen Neustart steht noch aus.

Der Administrator meldet erfolgreiche Ticket-Aktivierung und anschließend sporadisch HTTP 401 von /verify, auch mit frischen Codes und verschiedenen Browsern. Zwölf eigene Testtickets am getrennten Test-Monitor wurden erfolgreich aktiviert und jeweils dreimal geprüft. Zwei direkte Browser-Anmeldungen erreichten ebenfalls das Menü. Diese Tests reservierten keine Station und schalteten keine Geräte um. Zu diesem frühen Prüfzeitpunkt war die Ursache noch nicht nachgewiesen; die anschließend gelieferten Serverlogs und der Ticket-Abruf sind im vorstehenden Abschnitt ausgewertet.

Die Frontend-Version mutec4 versieht jede /verify-Anfrage mit einem unabhängigen, geheimnisfreien mutec_check-Parameter und cache:no-store. Eine 401 wird nach 250 und 750 Millisekunden mit neuer Adresse wiederholt. Nur ein erfolgreicher Prüfstatus erlaubt den Einstieg; drei 401 bleiben gesperrt. /enter-system wird dabei nicht erneut aufgerufen, fremde bereits verwendete Codes bleiben abgewiesen. Acht Frontend-Tests bestätigen unter anderem temporäre und dauerhafte 401 sowie die getrennte Behandlung von 403. Die Änderung schützt gegen veraltete Prüfantworten und kurze Übergangsfehler, belegt aber nicht, dass einer dieser Fälle die Ursache des gemeldeten Problems ist. Sieben Website-Dateien wurden gesichert, hochgeladen und per Prüfsumme bestätigt. Eine weitere Anmeldung mit frischem Testticket erreichte auf der veröffentlichten Version das Menü, auch mit einem Code mit führenden Nullen. Der tatsächlich verwendete Monitor https://www.megbes.de/tickets/tine/login.html und seine vier zugehörigen HTML-/JS-Dateien entsprechen den lokalen Quellen, verwenden tine und Monitor 1111 und werden mit no-cache/no-store ausgeliefert. Eine erneute Prüfung am betroffenen Ticket-Monitor steht aus. Keine MegBes-Backend-Änderungen und kein neuer Relay-Installationsschritt.

== Zur Auswahl: Trailer und IDLE ==

Die Frontend-Version mutec5 fordert beim Klick auf „Zur Auswahl“ die Freigabe mit DELETE /mutec-control-api/session?returnToTrailer=1 an. Das aktualisierte separate Relay prüft Ticket und aktive Belegung, sendet über die bestehende MegBes-API genau 50-Trailer und meldet anschließend die Station ab. Der BrightSign kann nach seiner Trailer-Umschaltung selbst IDLE melden. Senden und Freigabe werden in derselben Warteschlange ausgeführt, damit eine neue MUTEC-Sitzung nicht dazwischen übernehmen kann. Die normalen Feature-Befehlslisten werden nicht erweitert.

Bei einem Sendefehler bleibt das Token im Browser erhalten und die Fehlermeldung erlaubt einen erneuten Versuch. Bereits entfernte oder fremde Sitzungen schicken keinen Trailer an einen neuen Bediener. Abmelden und automatische Freigaben sind unverändert; diese Ergänzung betrifft den Auswahl-Button in Karte, Aqua und Medien. Zehn Relay-Tests und zehn Frontend-Tests sind erfolgreich, einschließlich tatsächlicher HTTP-Route, Befehlsreihenfolge, Ticket-Widerruf, verlorener Belegung und wiederholbarer Sendefehler.

Der Root-Administrator muss das vorbereitete Update einmal ausführen: bash /home/clawtronics/mutec-trailer-update/apply-update.sh. Es prüft das Paket, testet vor dem Austausch, sichert und ersetzt ausschließlich access.js, server.js und test/relay.test.js des separaten Relays und startet mutec-realtime neu. Fehler führen zur Wiederherstellung. /etc/mutec-realtime.env und DISPLAY_KEY werden nicht verändert. Health muss anschließend returnToTrailer:true enthalten. Frontend-Dateien müssen mit der neuen Versionskennung hochgeladen sein. Bis zur Installation des Relay-Updates bleibt dessen bisheriges Freigabeverhalten aktiv. Nach der Installation Bedienseite neu laden und die tatsächliche Trailer-/IDLE-Reaktion von Station 50 prüfen.

Siehe auch [[Web-Frontend entwickeln]], [[UDP und Stationszustände]], [[Tine]] und [[Messe]].

[[Kategorie:MegBes]]
[[Kategorie:Frontend]]
[[Kategorie:Entwicklung]]

== Papierflug mit Smartphone-Neigung ==
Stand 10.10.2026: [[MUTEC – Papierflug]] ergänzt eine modulare three.js-Anwendung mit Neigungs- und Touch-Steuerung, Ringen, Punkten und Rückkanal zum Smartphone. Frontend veröffentlicht, Electron-Reiter flight auf PC 166 vorbereitet; separates Relay-Update geprüft und zur root-Installation bereitgestellt. Keine Änderungen an megbes-external/megbes-internal. Die Installation und der Flug mit echten Sensoren sind noch zu bestätigen. Vollständige Einrichtung und Protokollbeschreibung auf der verlinkten Seite.

== Pong mit eingeschränktem Gastzugang ==
Stand 10.10.2026: [[MUTEC – Pong]] ergänzt Pong gegen den Computer oder einen zweiten Smartphone-Spieler. Spieler 1 reserviert Station 50 per MegBes-Ticket. Ein kurzlebiger, einmaliger QR-Code erlaubt dem Gast ausschließlich den rechten Schläger; keine Ticket-, UDP-, Neustart- oder Stationsbefugnisse. Frontend veröffentlicht, Electron-Reiter pong auf PC 166 ergänzt. Separates Relay-Update mit 17 Prüfungen auf dem VPS vorbereitet; root-Installation und Abnahme mit zwei Smartphones stehen aus. Keine Änderungen an megbes-external/megbes-internal. Einrichtung, Berechtigungsmodell und Protokoll auf der verlinkten Seite.

== HTML-Video mit Smartphone-Ton ==
[[MUTEC – HTML-Video]] ergänzt Video in Electron mit Play/Pause, Spulen, Kapiteln, Sprachwahl und laufender Audio-Zeitkorrektur. Frontend hochgeladen, Electron konfiguriert, Relay durch root installiert und video:true geprüft. Details und Abnahme auf der verlinkten Seite. Keine Änderungen am MegBes-Backend.

== Arcade-Erweiterung ==
Stand 11.10.2026: [[MUTEC – Arcade]] dokumentiert das zusätzlich angebotene Pöng mit Zweifinger-Steuerung und eingeschränktem Gastzugang, Papierflug mit Ringanimationen/Serien/Bonusringen und dauerhafter dreistelliger Arcade-Bestenliste sowie Finde den Ort mit serverseitiger Hinweisausgabe und Wertung. Spiel-Sounds sind auf dem Smartphone zuschaltbar. Wichtige Anzeigen liegen in der mittleren Bildhälfte; Karte synchronisiert die Nord-Süd-Ausdehnung. Aqua-Navigation und JSON-Token-Transport wurden korrigiert. Frontend hochgeladen, Relay vom Administrator installiert (24 Tests), öffentliche Funktionen geprüft. Electron-Reiter poeng ergänzt; Neustart und Hardware-Abnahme vor Ort. MegBes-external/-internal unverändert.

== Intro, Spiel und Schluss ==
[[MUTEC – Spielablauf]] beschreibt die Infokarten, getrennten Spiel-/Ergebnisansichten und den zustimmungspflichtigen Gastbeitritt für Pong/Pöng mit beidseitiger Bereitschaft und Countdown. 32 Servertests und Browserprüfungen bestanden. Frontend hochgeladen; Serverpaket unter /home/clawtronics/mutec-flow-update vom Administrator installiert. Alle 32 Tests und die echte Schreibprüfung bestanden; gameFlow ist öffentlich aktiviert. Der Installer korrigiert auch die Schreibfreigabe für /opt/mutec-realtime/data, ohne bestehende Bestenlisten zu ersetzen. MegBes-Programme bleiben unverändert.

== Freigabe nach Ticketablauf ==
Der Administrator hat das Ticketablauf-Update installiert; mutec-realtime und mutec-expiry-watchdog.timer wurden anschließend als aktiv geprüft. Ein separater privater root-Wächter liest ausschließlich die vorhandenen Mongo-Ticket-/Stationsmetadaten und verwendet die bestehende mTLS-Verbindung zu tine-dyndns.megbes.de:18921. Nur tine / Station 50: Abgelaufene REMOTE-Belegung → 50-Trailer → Hardware-IDLE abwarten, gegebenenfalls vorhandenen nativen Reset mit bestätigtem IDLE. Gültige oder unbekannte aktuelle Belegungen sowie fremde/OPEN/TOUCHSCREEN-Belegung werden nicht umgeschaltet. Prüfung etwa alle zehn Sekunden; bei Verbindungsfehlern erneuter Versuch. Besitzer-Zwischenspeicher privat unter /var/lib/mutec-expiry-watchdog, keine Tickets/JWT/Schlüssel. Mongo wird nicht verändert. Relay-Steuerrechte enden sofort; fehlgeschlagene Freigaben bleiben vorgemerkt. Keine Änderungen an megbes-external/-internal und kein öffentlicher administrativer Endpunkt. Die Hardware-Freigabe ist vor Ort zu prüfen.

== Mobile Pong-Einladung ==
Stand 12.10.2026: Für Pong und Pöng wurde der QR-Code vom LED-Counter auf das Smartphone von Spieler 1 verlegt. Der Counter enthält kein QR-/Einladungspanel mehr; seine Punkteanzeige liegt mittig. Letzte Infokarte: '1 Spieler starten' gegen den Computer oder '2 Spieler' für einen großen unverzerrten QR-Code auf dem eigenen Smartphone. Nach ausdrücklicher Zweispielerwahl im Intro und Gastbeitritt gilt die Einladung bereits als Zustimmung. Bei einer späteren Einladung über den 2-Spieler-Button im laufenden Spiel bleibt die Computerrunde bis zur ausdrücklichen Annahme erhalten. Gast-Infokarten, Bereitschaft und Countdown bleiben bestehen. Gäste erhalten keine weiteren MegBes-Rechte.

Neue Relay-Route POST /mutec-control-api/pong/invite: Nur der aktuelle Besitzer seiner eigenen Pong-/Pöng-Sitzung darf eine kurzlebige einmalige Einladung abrufen. Gäste, fremde Module und abgelaufene Sitzungen sind ausgeschlossen. Der Display-Schlüssel wird nicht an das Smartphone übergeben. Frontend hochgeladen und Browserprüfung mit getrennten Smartphones/Display bestanden. Serverpaket unter /home/clawtronics/mutec-invite-update vorbereitet; 38 Tests auf dem VPS bestanden. Root-Installation steht noch aus: bash /home/clawtronics/mutec-invite-update/apply-invite-update.sh. Der Installer sichert und ersetzt nur server.js und den Relay-Test, prüft den unveränderten Ausgangsstand und startet den Relay neu. Flight-Wettbewerb, Bestenlisten, Ticketablauf-Wächter, DISPLAY_KEY und MegBes-external/-internal bleiben erhalten. Danach Smartphone-Seiten und Electron-Webseiten neu laden.

== Einheitliche Spiele und Bestenlisten ==
Stand 13.10.2026: [[MUTEC – Einheitliche Spiele]] dokumentiert optionale Zweispielerrunden auch für Finde den Ort, vier getrennte Top-10-Listen ausschließlich auf der Electron-Anzeige vor/nach dem Spiel und eigene qualifizierte Arcade-Einträge für Besitzer/Gast. Pong/Pöng werten Tore und aktive Zeit mit Siegbonus. Die vorhandene Flight-Wertung und die Karte mit getrennten Kameras/Hinweisen bleiben erhalten. Frontend hochgeladen und geprüft; 48 Servertests auf dem VPS bestanden. Serverpaket unter /home/clawtronics/mutec-unified-update am 13.10.2026 erfolgreich installiert; alle 48 Tests und die Schreibpruefung bestanden. Die oeffentliche API meldet unifiedGames=true; Relay und Ticketablauf-Waechter sind aktiv. Daten, Schlüssel, Objects, HTML-Video und MegBes-Programme bleiben erhalten.

== Native BrightSign-Videos ==
Stand 15.10.2026: [[MUTEC – Native BrightSign-Videos]] dokumentiert den eigenen Smartphone-Menuepunkt fuer Wasser mit nativer BrightAuthor-Wiedergabe auf Station 50, echter Positionsrueckmeldung und Smartphone-Ton. Frontend veroeffentlicht, Serverpaket mit 65 Tests vorbereitet. Root-Installation und Hardwaretest nach BrightAuthor-Veroeffentlichung noch ausstehend.

MUTEC – Native BrightSign-Videos

2026-10-15T09:45:23Z

Clawtronics: Native Wasser-Wiedergabe mit Smartphone-Ton und getrenntem Steuerkanal vorbereitet

= MUTEC: Native BrightSign-Videos =

Stand: 15.10.2026. Frontend veröffentlicht; Serverpaket vorbereitet, noch nicht als root installiert. BrightAuthor-Projektkopie erstellt, noch nicht am XT1144 getestet/veröffentlicht.

== Aktivieren ==

Bei freier Station 50 als root auf dem VPS:

```bash
bash /home/clawtronics/mutec-native-video-update/apply-native-video-update.sh
```

Das Paket prüft 65 Tests und den aktuellen Stand aller 20 Quelldateien. Es sichert und ersetzt drei Relay-Dateien, ergänzt einen eigenen privaten `NATIVE_DISPLAY_KEY` in der vorhandenen Umgebungsdatei und startet den Dienst neu. Bei einem Fehler werden Dateien und Umgebung zurückgesetzt. MegBes-external/internal, der bestehende DISPLAY_KEY, Bestenlisten und der Ticketablauf-Wächter bleiben erhalten. Die neue Funktion ist über `nativevideo: true` in der öffentlichen capabilities-Antwort erkennbar.

Anschließend diese Projektkopie mit BrightAuthor Classic öffnen und auf Station 50 veröffentlichen:

`C:\tinetronics Claw\R&D\MUTEC\BrightSign\NativeVideo\MUTEC2026 Counter XT1144 - Native Wasser.bpf`

Das Originalprojekt wurde nicht geändert. Die Kopie ist auf XT1144 eingestellt, enthält das Plugin `mutecNative` und die zusätzliche Szene `Native Wasser`. Alle vorhandenen Medienpfade wurden auf den lokalen BrightSign-Ordner umgestellt; bei der Prüfung waren keine Dateien vermisst. Die eigene Datei `MUTEC-Native-Wasser.mp4` wurde ohne erneute Videokodierung aus Wasser erzeugt, ohne Audiospur. Sie hat dieselbe Bildgröße 1376 × 430 und dieselbe Dauer von 97 Sekunden. Die vorhandene Zonenanordnung und Ausgabeauflösung bleiben erhalten.

Das Plugin enthält einen privaten, ausschließlich für diesen nativen Anzeigekanal gültigen Geräteschlüssel. Die Datei bleibt im lokalen BrightAuthor-Projekt und wird mit auf den Player veröffentlicht; sie gehört nicht auf den öffentlichen Webserver. Der Schlüssel ist bereits passend im Serverpaket hinterlegt und muss nicht vom Besucher eingegeben werden.

Die BrightSignOS-Version ist noch unbekannt. Die WebSocket-Brücke setzt einen modernen HTML-Renderer voraus; sie ist für die Sprachfunktionen von Chromium 87 (BrightSignOS 8.5) vorbereitet, einschließlich randomUUID-Ersatz. Ein tatsächlicher Kompatibilitätstest auf dem XT1144 ist erforderlich. Der Installer aktualisiert keine Player-Firmware.

Smartphone-Auswahlseite neu laden. Neuer Eintrag: **Wasser · BrightSign**. Electron ist für dieses Angebot nicht beteiligt und braucht keinen neuen Reiter.

== Ablauf ==

1. Mit MegBes-Ticket anmelden und Wasser · BrightSign wählen. Exklusive Reservierung von Station 50, Befehl `50-nativewater`.
2. Die eigene BrightAuthor-Szene spielt die lokale MP4 über den nativen Decoder. Das Plugin hält die Wiedergabe für die Smartphone-Freigabe an.
3. Zwei Infokarten auf dem Smartphone bestätigen, Ton aktivieren und starten. Deutsch/Englisch, Pause, Zeitleiste, ±10 Sekunden und Kapitel Start stehen zur Verfügung.
4. Zur Auswahl sendet wie bei den anderen exklusiven Angeboten `50-Trailer` und gibt die Sitzung frei. Filmende bleibt bis zur Rückkehr bzw. zum Ticketablauf an diese Sitzung gebunden.

== Synchronisation und Abgrenzung ==

Eine transparente 16 × 16-Pixel-HTML-Brücke auf dem BrightSign hält die Verbindung zum vorhandenen WebSocket-Relay; sie spielt selbst kein Video. Sie bleibt sichtbar, um Hintergrund-Timer-Drosselung zu vermeiden. Sie nutzt weder Node.js noch abgeschaltete HTTPS-/Web-Sicherheitsprüfungen. BrightAuthor und das Plugin kommunizieren lokal über BSMessagePort/PostJSMessage.

Das Plugin greift ausschließlich auf den nativen Player der Zone Video or Images zu, wenn dessen tatsächliche Quelle die eigene native Wasser-Datei aus dem Asset-Pool ist. Die separate, stumme Datei hat einen anderen Inhalt/Hash als die bestehende Wasser-Datei. Dadurch werden die bisherige Medienauswahl und der HDMI-Eingang nicht mitgesteuert.

Alle 250 ms werden echte Position und Dauer abgefragt. Spulbefehle werden erst bestätigt, wenn die abgefragte Position das Ziel bis auf 200 ms erreicht hat; nach fünf Sekunden wird stattdessen ein Fehler gemeldet. Rückmeldungen sind an Sitzung und konkrete Abfrage gebunden; alte Messungen werden verworfen. Der Smartphone-Ton übernimmt die bestehende Uhrabgleich-/Driftkorrektur: größere Abweichungen durch Positionssprung, kleinere über maximal ±2 % Abspielgeschwindigkeit. Die lokale Einstellung zur Audioverzögerung berücksichtigt den LED-Prozessor und Kopfhörer.

Bei fehlendem Smartphone-Heartbeat bzw. fehlender Audio-Bereitschaft pausiert der Film. Ein unabhängiger BrightScript-Timer pausiert auch bei ausgefallener WebSocket-/HTML-Brücke nach spätestens ungefähr 1,8 Sekunden. Verbindungsverlust setzt die Startabsicht zurück; eine erneute Freigabe ist nötig. Fehlen dem Smartphone frische Positionsmeldungen, pausiert sein Ton. Ticketablauf und Stationsfreigabe verwenden die vorhandene Infrastruktur.

Native und Electron-Videoanzeigen haben getrennte Verbindungen und Schlüssel. Native Besucher dürfen nur `50-nativewater`, keine Electron-Befehle und keine anderen Filme aufrufen. Der vorhandene HTML-Videokanal bleibt bestehen.

== Vor Ort prüfen ==

- Nach Veröffentlichung: Das bisherige Trailer-/HDMI-/Aquarium-Verhalten bleibt benutzbar.
- Wasser starten, Pause, mehrere Sprünge vor/zurück und an die Enden, Fortsetzung sowie Sprachwechsel testen.
- Den Tonversatz mit Kopfhörern am echten Counter abstimmen. Mobilfunk, LED-Verarbeitung und Bluetooth erlauben ohne Messung kein Versprechen bildgenauer Synchronität.
- Smartphone-Verbindung kurz trennen: Film muss pausieren. Danach bewusst erneut starten.
- Zur Auswahl und Ticketablauf testen: Trailer/IDLE muss die Station wieder freigeben.
- Nach Filmende muss die Smartphone-Seite Film beendet anzeigen.

Geprüft: 65 automatisierte Servertests auf dem VPS; Syntaxanalyse des BrightScript-Plugins ohne Fehler; Browserablauf mit simulierten nativen Rückmeldungen; alle sieben öffentlichen Frontend-Dateien per SHA-256 bestätigt. Noch offen: BrightAuthor-Öffnen/Veröffentlichen, reale BrightSign-API-Rückmeldungen und die wahrnehmbare Synchronisation am LED-Counter.

Technische Referenzen: [roVideoPlayer](https://docs.brightsign.biz/develop/rovideoplayer), [roHtmlWidget](https://docs.brightsign.biz/develop/rohtmlwidget), [offizielles HTMLZoneMessage-Beispiel](https://github.com/brightsign/BrightAuthor-Plugins/tree/master/HTMLZoneMessage).

MUTEC – WebSocket-Steuerung

2026-10-13T09:37:55Z

Clawtronics: Erfolgreiche Installation und oeffentliche Erreichbarkeit bestaetigt

MUTEC – Arcade

2026-10-13T09:37:55Z

Clawtronics: Erfolgreiche Installation und oeffentliche Erreichbarkeit bestaetigt

Frontend: neue Auswahl Pöng zusätzlich zu Pong, Finde den Ort und Papierflug-Upgrade. Relevante Anzeigen liegen in der mittleren Bildhälfte. Aqua-Navigation steht oberhalb des Inhalts; der gleiche Relay-Token wird zusätzlich im JSON-Body geprüft, wenn PHP den Authorization-Header verliert.

== Installation ==
Das Serverpaket liegt auf dem VPS in /home/clawtronics/mutec-arcade-update. Als root, während Station 50 frei ist:
<code>bash /home/clawtronics/mutec-arcade-update/apply-arcade-update.sh</code>
Die Installation prüft 24 Servertests, sichert geänderte Dateien und startet den Dienst neu. Schlüssel, Umgebungsdatei und MegBes-Programme bleiben erhalten. Das private Datenverzeichnis /opt/mutec-realtime/data gehört dem Dienst mutec-realtime. Vorhandene Bestenlisten werden nicht ersetzt.
Nach Installation Electron neu starten, damit der zusätzlich eingetragene Reiter poeng geladen wird. Auf dem Smartphone die Auswahl neu laden.

== Regeln ==
* Pöng: Zwei Finger führen die Enden; feste Schlägerlänge, eigene Hälfte. Start gegen Computer, Gast per einmaligem QR-Code. Gast kann ausschließlich rechts steuern, ohne MegBes-Rechte. Sieben Punkte entscheiden.
* Flug: 60 Sekunden, genau 42 Ringe, davon 8 dicke Bonusringe. Seedabhängig unregelmäßige Abstände. 100 Basispunkte, Streak-Multiplikator steigt alle fünf Treffer bis ×5; dicke Ringe zusätzlich ×5. Fehlversuch setzt Streak zurück. Treffer drehen, wachsen und verschwinden; verpasste Ringe werden rot. Drei Wolkenformen. Zehn beste Ergebnisse mit drei Zeichen A–Z/0–9, nur vom angemeldeten Besucher nach Display-Endergebnis eintragbar.
* Ortssuche: Acht deutsche Städte (Berlin, Hamburg, München, Köln, Dresden, Leipzig, Stuttgart, Kiel), zufällig ohne direkte Wiederholung. Vier Hinweise, alle acht Sekunden. Stadtzentrum im Fadenkreuz innerhalb 1,5 km bei Zoom mindestens 11 für 1,2 Sekunden. 120 Sekunden Zeit; Punkte max(50, gerundet(1000 − 5×Sekunden − 90×abgeschlossene 8-Sekunden-Zeitstufen)). Beim Timeout null Punkte. Kein Zielkoordinatenversand an Browser während der Suche. Liste in realtime/arcade.js erweiterbar.
* Zoom: Höhenabhängige Anpassung des Display-Zooms entspricht gleicher Nord-Süd-Ausdehnung; seitlich zeigt das breitere Display mehr Karte.
* Sounds: freiwillig auf dem Smartphone aktivieren. Lokale Synthese, keine Audio-Dateien. Display sendet nur freigegebene Effektarten, Gäste können keine Effekte auslösen.

== Protokoll und Module ==
poeng.paddle: ax/ay/bx/by jeweils 0..1, active boolean. Der Relay ergänzt side anhand der Rolle. poeng.action/restart nur Besitzer; poeng.status nur Display. Einladung nutzt weiterhin /pong/guest und ist fest an Spiel UND Feature gebunden.
map.game/action=start nur Kartenbesitzer. map.camera ergänzt viewportHeight. map.game.status wird vom Relay für Besitzer und Display erzeugt.
flight.result/runId,score,hits nur authentifiziertes Flight-Display nach passendem Steuerlauf. POST /flight/highscores nimmt ausschließlich runId und dreistelligen name vom aktiven Flight-Besitzer an. GET /flight/highscores liefert öffentliche Top-10, ohne Tickets/Schlüssel.
game.sound/kind,id nur Spiele-Display; Empfänger sind Besitzer und gegebenenfalls Gast derselben Sitzung. Keine Wiederholung alter Effekte.

== Vor Ort prüfen ==
Zweifingersteuerung auf zwei echten Smartphones, LED-Lesbarkeit/QR-Scan, Audio im Hallenumfeld, Ring-Animationen und Namenseingabe nach vollen 60 Sekunden. Aqua-Tier speichern und Eingang ins Aquarium prüfen. Die lokale Browserprüfung verwendet nur einen simulierten MegBes-Server; sie steuert keine Hardware an.

== Installationsstand ==
11.10.2026: Frontend veröffentlicht, Relay durch Administrator installiert (24/24 Prüfungen erfolgreich), öffentliche Capabilities und Bestenliste geprüft. Electron-Reiter poeng eingetragen; Neustart von Electron erforderlich. Aqua-Syntax auf PHP 8.3 geprüft; JSON-Token erreicht die serverseitige Berechtigungsprüfung auch ohne Authorization-Header. Die erfolgreiche Tierübertragung mit echtem Ticket und die LED-Abnahme erfolgen vor Ort.

== Intro, Spiel und Schluss ==
[[MUTEC – Spielablauf]] beschreibt die Infokarten, getrennten Spiel-/Ergebnisansichten und den zustimmungspflichtigen Gastbeitritt für Pong/Pöng mit beidseitiger Bereitschaft und Countdown. 32 Servertests und Browserprüfungen bestanden. Frontend hochgeladen; Serverpaket unter /home/clawtronics/mutec-flow-update vom Administrator installiert. Alle 32 Tests und die echte Schreibprüfung bestanden; gameFlow ist öffentlich aktiviert. Der Installer korrigiert auch die Schreibfreigabe für /opt/mutec-realtime/data, ohne bestehende Bestenlisten zu ersetzen. MegBes-Programme bleiben unverändert.

== Mobile Pong-Einladung ==
Stand 12.10.2026: Für Pong und Pöng wurde der QR-Code vom LED-Counter auf das Smartphone von Spieler 1 verlegt. Der Counter enthält kein QR-/Einladungspanel mehr; seine Punkteanzeige liegt mittig. Letzte Infokarte: '1 Spieler starten' gegen den Computer oder '2 Spieler' für einen großen unverzerrten QR-Code auf dem eigenen Smartphone. Nach ausdrücklicher Zweispielerwahl im Intro und Gastbeitritt gilt die Einladung bereits als Zustimmung. Bei einer späteren Einladung über den 2-Spieler-Button im laufenden Spiel bleibt die Computerrunde bis zur ausdrücklichen Annahme erhalten. Gast-Infokarten, Bereitschaft und Countdown bleiben bestehen. Gäste erhalten keine weiteren MegBes-Rechte.

Neue Relay-Route POST /mutec-control-api/pong/invite: Nur der aktuelle Besitzer seiner eigenen Pong-/Pöng-Sitzung darf eine kurzlebige einmalige Einladung abrufen. Gäste, fremde Module und abgelaufene Sitzungen sind ausgeschlossen. Der Display-Schlüssel wird nicht an das Smartphone übergeben. Frontend hochgeladen und Browserprüfung mit getrennten Smartphones/Display bestanden. Serverpaket unter /home/clawtronics/mutec-invite-update vorbereitet; 38 Tests auf dem VPS bestanden. Root-Installation steht noch aus: bash /home/clawtronics/mutec-invite-update/apply-invite-update.sh. Der Installer sichert und ersetzt nur server.js und den Relay-Test, prüft den unveränderten Ausgangsstand und startet den Relay neu. Flight-Wettbewerb, Bestenlisten, Ticketablauf-Wächter, DISPLAY_KEY und MegBes-external/-internal bleiben erhalten. Danach Smartphone-Seiten und Electron-Webseiten neu laden.

== Einheitliche Spiele und Bestenlisten ==
Stand 13.10.2026: [[MUTEC – Einheitliche Spiele]] dokumentiert optionale Zweispielerrunden auch für Finde den Ort, vier getrennte Top-10-Listen ausschließlich auf der Electron-Anzeige vor/nach dem Spiel und eigene qualifizierte Arcade-Einträge für Besitzer/Gast. Pong/Pöng werten Tore und aktive Zeit mit Siegbonus. Die vorhandene Flight-Wertung und die Karte mit getrennten Kameras/Hinweisen bleiben erhalten. Frontend hochgeladen und geprüft; 48 Servertests auf dem VPS bestanden. Serverpaket unter /home/clawtronics/mutec-unified-update am 13.10.2026 erfolgreich installiert; alle 48 Tests und die Schreibpruefung bestanden. Die oeffentliche API meldet unifiedGames=true; Relay und Ticketablauf-Waechter sind aktiv. Daten, Schlüssel, Objects, HTML-Video und MegBes-Programme bleiben erhalten.

MUTEC – Spielablauf

2026-10-13T09:37:54Z

Clawtronics: Erfolgreiche Installation und oeffentliche Erreichbarkeit bestaetigt

MUTEC – Einheitliche Spiele

2026-10-13T09:37:54Z

Clawtronics: Erfolgreiche Installation und oeffentliche Erreichbarkeit bestaetigt

MUTEC – WebSocket-Steuerung

2026-10-13T09:25:35Z

Clawtronics: Gemeinsame Zweispieler-/Bestenlistenstruktur, Kartenduell und Pong-Zeitwertung vorbereitet

= MUTEC v2 – Einrichtung mit MegBes-Ticket =

Stand: 09.10.2026. Das MUTEC-Frontend und die QR-Zieladresse des Ticket-Monitors tine wurden auf den Webspace hochgeladen und per Prüfsumme sowie HTTPS geprüft. Der Administrator hat den separaten WebSocket-Dienst auf dem VPS installiert: sieben Tests erfolgreich, systemd aktiv und lokaler Health-Check erfolgreich. Die öffentliche API-Route beantwortet den CORS-Preflight mit HTTP 204. Der Ticket-Login funktioniert laut Gerätetest. Google Maps und die Electron-Anzeige funktionieren laut Gerätetest. Die Projektzuordnung im Ticket-Monitor wurde anschließend korrigiert; dessen erneute Prüfung und die vollständige Geräteabnahme stehen aus. v2 ersetzt die früheren Pakete mit CONTROL_TOKEN.

== Aktuelle Inbetriebnahme: Google Maps und Electron ==

Nachtrag: Die Google-Karte funktioniert laut Gerätetest auf dem Smartphone. Chrome auf PC 166 zeigt die Karte mit DISPLAY_KEY und übernimmt die Smartphone-Bewegungen. Der verbleibende Electron-Fehler wurde im Programm gefunden und am 09.10.2026 korrigiert: loadConfiguredView hing den Parameter aquariumReload als Text hinter das URL-Fragment. Dadurch wurde der Zusatz Teil des DISPLAY_KEY und die Anzeige wies ihn ab. Die URL wird nun mit URL und searchParams erzeugt, sodass der Parameter vor dem unveränderten Fragment steht. Quellcode electron-main.js und resources/app.asar unter \\192.168.14.166\C-Platte\xampp\htdocs\aquasphaere\aquarium wurden gesichert und korrigiert. Die Konfiguration liegt für die gepackte Anwendung neben der EXE in dist/win-unpacked/views.json und enthält bereits einen formal gültigen Schlüssel. Vier URL-Fälle je Quellcodeversion wurden geprüft, das gepackte Ergebnis zurückgelesen. Der Administrator hat nach dem Neustart die Kartenanzeige in Electron bestätigt.

Die Google-Maps-Diagnose der öffentlichen Kartenanzeige liefert <code>RefererNotAllowedMapError</code> für https://www.tinetronics.de/mutec/control/display.html. Der eingebundene Google-Schlüssel endet auf iJd80U. Bei genau diesem Schlüssel unter Google Cloud → APIs und Dienste → Anmeldedaten → Website-Einschränkungen die Freigabe https://www.tinetronics.de/* prüfen und speichern. Danach einige Minuten warten und die Kartenseite neu laden. Die konkrete Diagnose weist auf die Website-Freigabe hin; ein neues Relay-Paket ist dafür nicht erforderlich.

Die Electron-Meldung „Diese Anzeige ist noch nicht in Electron eingerichtet“ bedeutet, dass der private DISPLAY_KEY fehlt. Auf dem VPS mit <code>sudo grep '^DISPLAY_KEY=' /etc/mutec-realtime.env</code> lokal ablesen. Nur den Wert hinter dem Gleichheitszeichen in views.json als https://www.tinetronics.de/mutec/control/display.html#displayKey=WERT einsetzen. Den Schlüssel nicht in Wiki oder Chat veröffentlichen. Electron anschließend neu starten. Der Schlüssel berechtigt ausschließlich die Anzeige und ersetzt keinen Besucher-Ticket-Code.

== Ergebnis und Bedienung ==

MegBes-Ticket → Auswahlmenü → Aqua, Karte oder Medien. Keine Stationseingabe und kein zusätzliches Besucher-Passwort. Alle Anwendungen belegen Station 50 exklusiv als REMOTE. Andere Besucher dürfen das Auswahlmenü öffnen, aber den belegten Bildschirm nicht übernehmen. „Zur Auswahl“ und „Abmelden“ geben Station 50 über die vorhandene MegBes-Stationsabmeldung frei. Eine stationsseitige IDLE-Meldung beendet die bisherige Steuersitzung spätestens beim nächsten Befehl, einer neuen Auswahl oder nach etwa zehn Sekunden.

Der PC 166 bleibt das Ziel der bestehenden UDP-Befehle. Die Karte sendet 166-maps für Electron und 50-maps für den HDMI-Eingang des BrightSign. Es wird keine zusätzliche native Stationsgruppe oder Backend-Erweiterung eingeführt. megbes-external und megbes-internal bleiben unverändert.

== Pakete ==

* MUTEC-v2-server.tar.gz: separater Node-WebSocket-Dienst, Installer, systemd-Datei, zwei nginx-Weiterleitungen und sieben Tests.
* MUTEC-v2-frontend.zip: aktualisierte Dateien für den bereits vorhandenen FTP-Ordner /tinetronics_de/mutec. Vorhandene Bilder, Audios, Bibliotheken und Aquarium-Dateien bleiben Voraussetzung.
* views-tine.example.json: vollständiges Beispiel der Electron-Ansichten. Den privaten Anzeigeschlüssel einsetzen.

== 1. Vorhandene MegBes-Konfiguration prüfen ==

Auf dem zentralen Server 87.106.33.238 läuft megbes-external-tine. Der lokale MegBes-Server mit megbes-internal wird weiterhin über die vorhandene Projektkonfiguration angesprochen. Keine Installation in BrightSign oder Electron und kein Austausch der MegBes-Programme.

Voraussetzung sind die bestehende Ticket-Sicherheit und der bereits von MegBes unterstützte Modus intern kontrollierter Stationen. Im aktuellen Quellcode heißen die Einstellungen megbes.security=true (External) und megbes.internal.station.controlled=true (External und Internal). Die bestehenden Umgebungsvariablen heißen MEGBES_SECURITY und MEGBES_INTERNAL_STATION_CONTROLLED. Aktuelle effektive Werte prüfen: Wiki und OpenClaw enthalten unterschiedliche historische Angaben zum tine-Stationsmodus. Diese Schalter nicht ungeprüft ändern; der Stationsmodus betrifft das ganze Projekt.

Station 50 muss im Ruhezustand IDLE melden, nicht OPEN. OPEN ist die normale MegBes-Freigabe für Mehrfachbedienung und wird von dieser MUTEC-Version abgewiesen. BrightSign-Start-/Timeout-Meldungen für Station 50 entsprechend auf idle einstellen. Eine regelmäßige OPEN-Meldung während der Bedienung darf REMOTE nicht überschreiben. Das stationsseitige Timeout muss nach beendeter Bedienung IDLE senden können.

Der Dienst verwendet ausschließlich vorhandene Endpunkte:

<pre>POST /enter-system Ticket aktivieren (Frontend)
GET /verify Ticket prüfen
GET /media-station?station=50 Station anmelden
GET /media-station/status/50 REMOTE und Berechtigung prüfen
DELETE /media-station Station abmelden
POST /video-command erlaubte UDP-Befehle senden</pre>

Die bestehende Anmeldung kann trotz fehlgeschlagener interner Reservierung HTTP 200 liefern. Deshalb prüft das Relay vor und nach der Anmeldung den tatsächlichen Stationsstatus. Ein 403, OPEN, TOUCHSCREEN oder unerwarteter Zustand erlaubt keine Übernahme. Vor dem Start wird auch die Erreichbarkeit/Berechtigung für PC 166 geprüft; PC 166 wird nicht separat reserviert.

Für das gleiche Ticket soll keine zweite Anwendung außerhalb MUTEC parallel eine andere MegBes-Station anmelden: MegBes verwaltet pro Benutzer eine aktuelle Station. Die exklusive MUTEC-Nutzung gilt für den angeschlossenen Bildschirm und die über dieses Frontend angebotenen Funktionen.

== 2. WebSocket-Dienst auf 87.106.33.238 installieren ==

Als Administrator das Archiv in ein privates Arbeitsverzeichnis auf dem zentralen Plesk-Server kopieren und auspacken:

<pre>mkdir -p ~/mutec-v2-setup
cd ~/mutec-v2-setup
tar -xzf /pfad/zur/MUTEC-v2-server.tar.gz
cd MUTEC-v2-server
sudo bash install.sh</pre>

Der Installer verwendet das vorhandene Plesk-Node unter /opt/plesk/node/24/bin/node. Er erzeugt den Dienstbenutzer mutec-realtime, installiert festgelegte Abhängigkeiten und startet den Dienst ausschließlich auf 127.0.0.1:8089. Kein zusätzlicher öffentlicher Port. Ein vorhandener MUTEC-Relay wird vorher unter /var/backups/mutec-realtime privat gesichert. Ein vorhandener DISPLAY_KEY bleibt erhalten; CONTROL_TOKEN aus v1 entfällt. Der Installer verändert keine MegBes-Container oder deren Konfiguration.

<pre>sudo systemctl status mutec-realtime --no-pager
curl --fail http://127.0.0.1:8089/health</pre>

Erwartet: aktiver Dienst und JSON mit version 2. Health bestätigt den laufenden Relay-Prozess, noch nicht MegBes-Reservierung oder Hardware-Ausgabe.

== 3. Zwei Weiterleitungen in Plesk ergänzen ==

Bei tine.megbes.de → Apache & nginx-Einstellungen → Zusätzliche nginx-Anweisungen den Inhalt von nginx-tine.conf ergänzen. Vorhandene MegBes-Anweisungen erhalten. Die Datei enthält /mutec-control-ws für WebSockets und /mutec-control-api/ für Steuersitzungen. Speichern und prüfen:

<pre>sudo nginx -t</pre>

Öffentlich: wss://tine.megbes.de/mutec-control-ws und https://tine.megbes.de/mutec-control-api. Bestehende Ticket-/MegBes-Routen bleiben unverändert. Es wird kein Geheimwert in nginx eingetragen.

== 4. Website über FTP aktualisieren ==

Den bisherigen Ordner /tinetronics_de/mutec vollständig sichern. Danach den Inhalt von MUTEC-v2-frontend.zip darüber kopieren, Unterordner beibehalten. Dieser Ordner liegt auf dem Website-Host 217.160.0.178, nicht auf dem MegBes-VPS. realtime/ gehört nicht in den öffentlichen Webordner.

Google Maps verwendet den bestehenden Browserschlüssel in control/config.js. Maps JavaScript API und Abrechnung müssen aktiv sein; https://www.tinetronics.de/* ist nach deiner Angabe bereits freigegeben. PHP benötigt mindestens 8.0 mit cURL, ausgehendes HTTPS zu tine.megbes.de sowie die bestehenden Schreibrechte für Aqua und die Medien-Dateien. Schreibende PHP-Aufrufe prüfen die passende Steuersitzung jetzt serverseitig.

Die Ticket-Generation unter megbes.de/tickets/tine verwendet jetzt in js/project-const.js das absolute QR-Ziel https://www.tinetronics.de/mutec/. Der vorhandene Ticket-Code wird als systemCode übertragen; das Frontend aktiviert ihn und öffnet anschließend das Auswahlmenü. ticket.html lädt die aktualisierte Konfiguration mit einer Dateiversion. Den laufenden Ticket-Monitor nach dem Upload einmal neu laden. Die Änderung gilt für die Ticket-Generation des Projekts tine.

Besucher öffnen https://www.tinetronics.de/mutec/ und melden sich mit einem gültigen tine-Ticket an. Direkte Bedienseiten führen ohne Ticket oder passende Steuersitzung zum Login beziehungsweise zum Menü zurück. Die bisherige Medienoberfläche liegt nun unter remote.html.

== 5. Electron einmalig einrichten ==

Für Besucher gibt es keinen Zusatzcode. Die unbeaufsichtigte Electron-Anzeige benötigt einen privaten, rein lesenden DISPLAY_KEY. Der Installer erzeugt ihn in /etc/mutec-realtime.env. Er gehört weder ins Wiki noch in control/config.js.

Den Schlüssel als Administrator lokal aus der geschützten Datei entnehmen und den Platzhalter in views-tine.example.json ersetzen. Die maps-Ansicht erhält:

<pre>https://www.tinetronics.de/mutec/control/display.html#displayKey=DISPLAY_KEY_HIER_EINSETZEN</pre>

Das Fragment wird nicht als HTTP-Abfrage an den Webserver gesendet. Die Anzeige speichert es im Electron-Profil und entfernt es aus der sichtbaren Adresse. Nach Löschen des Electron-Profils erneut einrichten. views.json bleibt eine lokale Administrator-Datei. Der Schlüssel erlaubt ausschließlich den Empfang der Kartenereignisse, keine Stationsteuerung.

views.json auf PC 166 anpassen und Electron über das bestehende Verfahren neu starten. Die bisherige Aqua- und YouTube-URL bleiben wie in deiner Konfiguration. Karten-Auswahl: 166-maps und 50-maps. Aqua-Auswahl: 166-aqua und 50-aqua; deren bisherige HDMI-Umschaltung ebenfalls vor Ort prüfen.

== 6. Abnahme mit zwei Smartphones ==

# Ohne Ticket dürfen Bedienseiten keine Befehle oder Schreibzugriffe zulassen.
# Mit gültigem Ticket: Login → Menü → Aqua, Karte oder Medien.
# Ein zweites Ticket darf das Menü öffnen, aber keine Anwendung übernehmen. Auch Aqua ist exklusiv.
# „Zur Auswahl“ bei Besucher 1: Station 50 wird frei; Besucher 2 kann übernehmen. Alte Steuertokens müssen unwirksam sein.
# Stationsseitiges IDLE/Timeout für 50 auslösen: bisherige Sitzung verliert die Kontrolle; neue Auswahl erhält eine neue Reservierung.
# Karte verschieben und zoomen: gleicher Mittelpunkt, Zoom und Ausschnitt in Electron. Unterschiedliche Displayformate werden mit Rändern ausgeglichen; Verzögerung ist netzabhängig.
# Bedien-Tab schließen/Verbindung verlieren: lokale Relay-Sitzung läuft nach maximal etwa 55 Sekunden aus und meldet Station 50 ab, sofern MegBes erreichbar und das Ticket gültig ist.
# Relay-Ausfall, ungültiges Ticket oder MegBes-Ausfall: Station 50 muss über das bestehende Hardware-IDLE-Timeout frei werden. Es wird keine neue native 30-Sekunden-Reservierung eingeführt.
# Aqua-Tier speichern, Bewegungen sowie Medien-/YouTube-/Nachrichtenformulare prüfen. Featurefremde oder ungültige Tokens dürfen keine Dateien schreiben.
# UDP-Empfang und HDMI-Ausgabe am BrightSign tatsächlich prüfen.

Ein offener Bedien-Tab erneuert die Relay-Sitzung alle zehn Sekunden. Diese Verlängerung setzt keinen neuen nativen MegBes-Stationszeitstempel. Die vorhandenen MegBes-/Hardware-Zeitregeln bleiben maßgeblich. Nach einer stationsseitigen IDLE-Meldung wird nicht automatisch erneut reserviert: der Besucher muss neu auswählen.

Hier bestanden sieben Node-Tests: Ticket-/NoAuth-Abwehr, exklusive Belegung und konkurrierende Auswahl, IDLE-Abbruch, OPEN-Abweisung, Statusprüfung trotz irreführendem Anmelde-200, Befehlsrechte sowie HTTP/CORS/WebSocket-Rollen und Wiederverbindung. Lokal wurden Login, Menü, Belegung/Freigabe und Seitenzugriff mit simuliertem Backend geprüft. PHP-Syntax wurde geprüft; alle vier schreibenden Endpunkte wiesen Anfragen ohne Ticket mit HTTP 401 ab. Die QR-Erzeugung wurde mit simuliertem Backend geprüft, ohne Live-Tickets zu erzeugen. Echte Google-Karte, autorisierte PHP-Schreibvorgänge auf dem Website-Host und die Geräteausgabe bleiben Teil der Vor-Ort-Abnahme.

== 7. Fehlersuche und Rückkehr zum bisherigen Betrieb ==

* 401: Ticket/Sitzung ungültig, erneut anmelden.
* 409: Bildschirm belegt oder native Reservierung verloren; zur Auswahl zurückkehren.
* 503 mit Stationsstatus-Hinweis: bestehende controlled-Konfiguration und Erreichbarkeit prüfen; kein Backend-Patch erforderlich.
* OPEN-Hinweis: Station 50 muss idle melden. OPEN erlaubt mehrere Benutzer und ist hier ungeeignet.
* nginx 502: Relay-Dienst und Port prüfen.
* Google-Karte fehlt: API-Aktivierung, Website-Freigabe und Browser-Konsole prüfen.
* PHP-Schreiben scheitert: cURL, HTTPS-Erreichbarkeit, Token-Weiterleitung und Schreibrechte prüfen.

<pre>sudo journalctl -u mutec-realtime -n 80 --no-pager</pre>

Keine Tickets/Schlüssel in Logkopien übernehmen. Rollback: Relay stoppen, die beiden nginx-Ergänzungen entfernen und den gesicherten FTP-Ordner wiederherstellen. Die Installer-Sicherung enthält den vorherigen Relay-Ordner, dessen Umgebungsdatei und systemd-Datei, soweit vorhanden. MegBes-Programme werden nicht ersetzt und brauchen daher keinen Programm-Rollback.

== 8. Später auf messe wechseln ==

Nach separater Abnahme der vorhandenen Ticket-/Stationskonfiguration:

* js/project-const.js: EXTERNAL_SERVER_URL=https://messe.megbes.de und CUSTOMER=messe; aqua/js/project-const.js für Konsistenz mitführen.
* control/config.js: websocketUrl=wss://messe.megbes.de/mutec-control-ws, apiUrl=https://messe.megbes.de/mutec-control-api, room=messe-mutec-map.
* auth-config.php: relay_url auf https://messe.megbes.de/mutec-control-api.
* Dienst anhalten, /etc/mutec-realtime.env MEGBES_URL und CONTROL_ROOM auf messe ändern; nginx-Ergänzungen bei messe.megbes.de installieren; Dienst starten.

tine und messe nicht gleichzeitig auf dieselbe Relay-Instanz zeigen lassen. Für parallelen Betrieb eine zweite Instanz mit eigenem Port, Dienst, Umgebungsdatei und DISPLAY_KEY verwenden. Räume und Tickets bleiben projektgetrennt. Installierte Versionen, Prüfdatum und Abnahmeergebnis auf den Wiki-Projektseiten nachtragen, ohne Geheimwerte.

== Modularität und Ereignisprotokoll ==

Zugriff (realtime/access.js), Transport (server.js), Ereignisvalidatoren (protocol.js), Browser-Transport (control/client.js) und Karte (control/map.js) sind getrennt. Zukünftige Anwendungen ergänzen Feature-Freigaben/Befehlslisten und ihre Ereignisvalidatoren; Ticket und Stationssperre bleiben zentral.

Join: v=1, type=join, room=tine-mutec-map, role=controller oder display, accessToken. Der Controller verwendet ein kurzlebiges Relay-Token, die Anzeige den privaten DISPLAY_KEY. Kein Ticketcode im WebSocket-URL-Query.

<pre>{"v":1,"type":"event","topic":"map.camera","seq":1,"payload":{"lat":51.3397,"lng":12.3731,"zoom":13,"aspect":0.6}}</pre>

map.camera wird als letzter Zustand gespeichert und bei Wiederverbindung übertragen. seq steigt je Verbindung. input.pointer (phase/id/x/y, normalisierte Koordinaten) und input.orientation (alpha/beta/gamma in Grad) haben vorbereitete Validatoren. Neigungssteuerung und Sensorberechtigung sind noch kein implementiertes Bedienfeature. Relay-Grenze: 120 Nachrichten je Sekunde/Verbindung; Kartenmodul: höchstens etwa 30 Aktualisierungen/Sekunde. Nur der aktuelle Karten-Controller darf Ereignisse an Anzeigen senden.

== Ticket-Anmeldung – Korrektur vom 09.10.2026 ==

Die Anmeldung wurde zusätzlich mit eigenen Testtickets am laufenden tine-Backend und auf der veröffentlichten MUTEC-Seite geprüft. Aktivierung und anschließende Prüfung antworteten mit HTTP 200; der Browser erreichte das Auswahlmenü. Keine Station wurde dafür reserviert oder per UDP umgeschaltet.

Die Fehlerbehandlung wurde korrigiert: Ein Fehler der Steuersitzung verwirft kein bereits geprüftes MegBes-Ticket. Alte Steuersitzungen blockieren den Menü-Einstieg nicht. Ticket-Prüfungen umgehen den Browser-Cache. Nach erfolgreicher Aktivierung kann derselbe Browser eine gescheiterte Prüfung wiederholen, ohne erneut /enter-system aufzurufen. Bereits benutzte fremde Tickets werden weiterhin abgewiesen. Fünf zusätzliche Tests bestätigen diese Fälle. Sieben geänderte Website-Dateien wurden gesichert, hochgeladen und per Prüfsumme bestätigt; Versionskennung mutec3.

Der Administrator hat anschließend den erfolgreichen Ticket-Login auf dem Smartphone bestätigt. Bei künftigen Anmeldefehlern zeigt die Oberfläche den genauen Anmeldeschritt und HTTP-Status. Ein neuer Code auf dem Ticket-Monitor ist nach erfolgreicher Aktivierung normal.

== Sporadische Ticket-Prüfung: Untersuchung vom 09.10.2026 ==

=== Ursache und Korrektur der Projektzuordnung ===

Die später vom Administrator gelieferten Logs zeigen zur fehlgeschlagenen /verify-Anfrage „User known but not valid for customer“. Im geprüften MegBes-Quellcode nimmt /ticket den optionalen Query-Parameter customer entgegen. AuthMediaStationBaseService sucht unverbrauchte Tickets nach genau diesem customer und ticketMonitorNumber. Der bisherige tine-Monitor übergab keinen customer, also wurde nach customer=null und Monitor 1111 gesucht. In der gemeinsamen Datenbank können dabei Tickets aus anderen Projekten zurückgegeben werden. /enter-system prüft nur Existenz und Verbrauch, während /verify zusätzlich den Kunden des zugehörigen AuthObject mit dem laufenden Projekt vergleicht. Das erklärt die erfolgreiche Aktivierung mit anschließender 401. Die vorherigen Tests mit eigener Monitor-Nummer konnten diesen gemeinsamen Pool nicht abdecken. Die Cache-/Wiederholungsänderung allein behebt diese Ursache nicht.

Korrigiert am 09.10.2026: tickets/tine/js/ticket.js ruft jetzt /ticket?customer=tine&ticketMonitorNumber=1111 auf; der Kundenname wird aus CUSTOMER gelesen und URL-kodiert. ticket.html lädt die Datei mit Versionskennung 20261009-customer1. Beide Dateien sind lokal auf der Freigabe PC 134 und auf dem Webserver unter /megbes/tickets/tine gesichert, veröffentlicht und per Prüfsumme bestätigt. Der Abruf über https://www.megbes.de/tickets/tine wurde ebenfalls geprüft. Zwölf eigene Live-Testtickets mit customer=tine wurden erfolgreich aktiviert und jeweils dreimal geprüft. Der QR-Test prüft jetzt zusätzlich die ausdrückliche Projektzuordnung und Monitor-Nummer.

Den laufenden Ticket-Monitor vollständig neu laden (Strg+F5) und erst danach einen neu angezeigten QR-Code scannen. Alte QR-Codes können noch aus dem bisherigen Pool stammen. Keine MegBes-Programme oder Datenbankeinträge wurden für diese Korrektur verändert. Andere Ticket-Monitore/Templates sollten bei einer späteren separaten Prüfung ebenfalls den Projektnamen ausdrücklich mitsenden; diese Änderung betrifft ausschließlich tine. Die Prüfung des betroffenen Monitors nach dessen Neustart steht noch aus.

Der Administrator meldet erfolgreiche Ticket-Aktivierung und anschließend sporadisch HTTP 401 von /verify, auch mit frischen Codes und verschiedenen Browsern. Zwölf eigene Testtickets am getrennten Test-Monitor wurden erfolgreich aktiviert und jeweils dreimal geprüft. Zwei direkte Browser-Anmeldungen erreichten ebenfalls das Menü. Diese Tests reservierten keine Station und schalteten keine Geräte um. Zu diesem frühen Prüfzeitpunkt war die Ursache noch nicht nachgewiesen; die anschließend gelieferten Serverlogs und der Ticket-Abruf sind im vorstehenden Abschnitt ausgewertet.

Die Frontend-Version mutec4 versieht jede /verify-Anfrage mit einem unabhängigen, geheimnisfreien mutec_check-Parameter und cache:no-store. Eine 401 wird nach 250 und 750 Millisekunden mit neuer Adresse wiederholt. Nur ein erfolgreicher Prüfstatus erlaubt den Einstieg; drei 401 bleiben gesperrt. /enter-system wird dabei nicht erneut aufgerufen, fremde bereits verwendete Codes bleiben abgewiesen. Acht Frontend-Tests bestätigen unter anderem temporäre und dauerhafte 401 sowie die getrennte Behandlung von 403. Die Änderung schützt gegen veraltete Prüfantworten und kurze Übergangsfehler, belegt aber nicht, dass einer dieser Fälle die Ursache des gemeldeten Problems ist. Sieben Website-Dateien wurden gesichert, hochgeladen und per Prüfsumme bestätigt. Eine weitere Anmeldung mit frischem Testticket erreichte auf der veröffentlichten Version das Menü, auch mit einem Code mit führenden Nullen. Der tatsächlich verwendete Monitor https://www.megbes.de/tickets/tine/login.html und seine vier zugehörigen HTML-/JS-Dateien entsprechen den lokalen Quellen, verwenden tine und Monitor 1111 und werden mit no-cache/no-store ausgeliefert. Eine erneute Prüfung am betroffenen Ticket-Monitor steht aus. Keine MegBes-Backend-Änderungen und kein neuer Relay-Installationsschritt.

== Zur Auswahl: Trailer und IDLE ==

Die Frontend-Version mutec5 fordert beim Klick auf „Zur Auswahl“ die Freigabe mit DELETE /mutec-control-api/session?returnToTrailer=1 an. Das aktualisierte separate Relay prüft Ticket und aktive Belegung, sendet über die bestehende MegBes-API genau 50-Trailer und meldet anschließend die Station ab. Der BrightSign kann nach seiner Trailer-Umschaltung selbst IDLE melden. Senden und Freigabe werden in derselben Warteschlange ausgeführt, damit eine neue MUTEC-Sitzung nicht dazwischen übernehmen kann. Die normalen Feature-Befehlslisten werden nicht erweitert.

Bei einem Sendefehler bleibt das Token im Browser erhalten und die Fehlermeldung erlaubt einen erneuten Versuch. Bereits entfernte oder fremde Sitzungen schicken keinen Trailer an einen neuen Bediener. Abmelden und automatische Freigaben sind unverändert; diese Ergänzung betrifft den Auswahl-Button in Karte, Aqua und Medien. Zehn Relay-Tests und zehn Frontend-Tests sind erfolgreich, einschließlich tatsächlicher HTTP-Route, Befehlsreihenfolge, Ticket-Widerruf, verlorener Belegung und wiederholbarer Sendefehler.

Der Root-Administrator muss das vorbereitete Update einmal ausführen: bash /home/clawtronics/mutec-trailer-update/apply-update.sh. Es prüft das Paket, testet vor dem Austausch, sichert und ersetzt ausschließlich access.js, server.js und test/relay.test.js des separaten Relays und startet mutec-realtime neu. Fehler führen zur Wiederherstellung. /etc/mutec-realtime.env und DISPLAY_KEY werden nicht verändert. Health muss anschließend returnToTrailer:true enthalten. Frontend-Dateien müssen mit der neuen Versionskennung hochgeladen sein. Bis zur Installation des Relay-Updates bleibt dessen bisheriges Freigabeverhalten aktiv. Nach der Installation Bedienseite neu laden und die tatsächliche Trailer-/IDLE-Reaktion von Station 50 prüfen.

Siehe auch [[Web-Frontend entwickeln]], [[UDP und Stationszustände]], [[Tine]] und [[Messe]].

[[Kategorie:MegBes]]
[[Kategorie:Frontend]]
[[Kategorie:Entwicklung]]

== Papierflug mit Smartphone-Neigung ==
Stand 10.10.2026: [[MUTEC – Papierflug]] ergänzt eine modulare three.js-Anwendung mit Neigungs- und Touch-Steuerung, Ringen, Punkten und Rückkanal zum Smartphone. Frontend veröffentlicht, Electron-Reiter flight auf PC 166 vorbereitet; separates Relay-Update geprüft und zur root-Installation bereitgestellt. Keine Änderungen an megbes-external/megbes-internal. Die Installation und der Flug mit echten Sensoren sind noch zu bestätigen. Vollständige Einrichtung und Protokollbeschreibung auf der verlinkten Seite.

== Pong mit eingeschränktem Gastzugang ==
Stand 10.10.2026: [[MUTEC – Pong]] ergänzt Pong gegen den Computer oder einen zweiten Smartphone-Spieler. Spieler 1 reserviert Station 50 per MegBes-Ticket. Ein kurzlebiger, einmaliger QR-Code erlaubt dem Gast ausschließlich den rechten Schläger; keine Ticket-, UDP-, Neustart- oder Stationsbefugnisse. Frontend veröffentlicht, Electron-Reiter pong auf PC 166 ergänzt. Separates Relay-Update mit 17 Prüfungen auf dem VPS vorbereitet; root-Installation und Abnahme mit zwei Smartphones stehen aus. Keine Änderungen an megbes-external/megbes-internal. Einrichtung, Berechtigungsmodell und Protokoll auf der verlinkten Seite.

== HTML-Video mit Smartphone-Ton ==
[[MUTEC – HTML-Video]] ergänzt Video in Electron mit Play/Pause, Spulen, Kapiteln, Sprachwahl und laufender Audio-Zeitkorrektur. Frontend hochgeladen, Electron konfiguriert, Relay durch root installiert und video:true geprüft. Details und Abnahme auf der verlinkten Seite. Keine Änderungen am MegBes-Backend.

== Arcade-Erweiterung ==
Stand 11.10.2026: [[MUTEC – Arcade]] dokumentiert das zusätzlich angebotene Pöng mit Zweifinger-Steuerung und eingeschränktem Gastzugang, Papierflug mit Ringanimationen/Serien/Bonusringen und dauerhafter dreistelliger Arcade-Bestenliste sowie Finde den Ort mit serverseitiger Hinweisausgabe und Wertung. Spiel-Sounds sind auf dem Smartphone zuschaltbar. Wichtige Anzeigen liegen in der mittleren Bildhälfte; Karte synchronisiert die Nord-Süd-Ausdehnung. Aqua-Navigation und JSON-Token-Transport wurden korrigiert. Frontend hochgeladen, Relay vom Administrator installiert (24 Tests), öffentliche Funktionen geprüft. Electron-Reiter poeng ergänzt; Neustart und Hardware-Abnahme vor Ort. MegBes-external/-internal unverändert.

== Intro, Spiel und Schluss ==
[[MUTEC – Spielablauf]] beschreibt die Infokarten, getrennten Spiel-/Ergebnisansichten und den zustimmungspflichtigen Gastbeitritt für Pong/Pöng mit beidseitiger Bereitschaft und Countdown. 32 Servertests und Browserprüfungen bestanden. Frontend hochgeladen; Serverpaket unter /home/clawtronics/mutec-flow-update vom Administrator installiert. Alle 32 Tests und die echte Schreibprüfung bestanden; gameFlow ist öffentlich aktiviert. Der Installer korrigiert auch die Schreibfreigabe für /opt/mutec-realtime/data, ohne bestehende Bestenlisten zu ersetzen. MegBes-Programme bleiben unverändert.

== Freigabe nach Ticketablauf ==
Der Administrator hat das Ticketablauf-Update installiert; mutec-realtime und mutec-expiry-watchdog.timer wurden anschließend als aktiv geprüft. Ein separater privater root-Wächter liest ausschließlich die vorhandenen Mongo-Ticket-/Stationsmetadaten und verwendet die bestehende mTLS-Verbindung zu tine-dyndns.megbes.de:18921. Nur tine / Station 50: Abgelaufene REMOTE-Belegung → 50-Trailer → Hardware-IDLE abwarten, gegebenenfalls vorhandenen nativen Reset mit bestätigtem IDLE. Gültige oder unbekannte aktuelle Belegungen sowie fremde/OPEN/TOUCHSCREEN-Belegung werden nicht umgeschaltet. Prüfung etwa alle zehn Sekunden; bei Verbindungsfehlern erneuter Versuch. Besitzer-Zwischenspeicher privat unter /var/lib/mutec-expiry-watchdog, keine Tickets/JWT/Schlüssel. Mongo wird nicht verändert. Relay-Steuerrechte enden sofort; fehlgeschlagene Freigaben bleiben vorgemerkt. Keine Änderungen an megbes-external/-internal und kein öffentlicher administrativer Endpunkt. Die Hardware-Freigabe ist vor Ort zu prüfen.

== Mobile Pong-Einladung ==
Stand 12.10.2026: Für Pong und Pöng wurde der QR-Code vom LED-Counter auf das Smartphone von Spieler 1 verlegt. Der Counter enthält kein QR-/Einladungspanel mehr; seine Punkteanzeige liegt mittig. Letzte Infokarte: '1 Spieler starten' gegen den Computer oder '2 Spieler' für einen großen unverzerrten QR-Code auf dem eigenen Smartphone. Nach ausdrücklicher Zweispielerwahl im Intro und Gastbeitritt gilt die Einladung bereits als Zustimmung. Bei einer späteren Einladung über den 2-Spieler-Button im laufenden Spiel bleibt die Computerrunde bis zur ausdrücklichen Annahme erhalten. Gast-Infokarten, Bereitschaft und Countdown bleiben bestehen. Gäste erhalten keine weiteren MegBes-Rechte.

Neue Relay-Route POST /mutec-control-api/pong/invite: Nur der aktuelle Besitzer seiner eigenen Pong-/Pöng-Sitzung darf eine kurzlebige einmalige Einladung abrufen. Gäste, fremde Module und abgelaufene Sitzungen sind ausgeschlossen. Der Display-Schlüssel wird nicht an das Smartphone übergeben. Frontend hochgeladen und Browserprüfung mit getrennten Smartphones/Display bestanden. Serverpaket unter /home/clawtronics/mutec-invite-update vorbereitet; 38 Tests auf dem VPS bestanden. Root-Installation steht noch aus: bash /home/clawtronics/mutec-invite-update/apply-invite-update.sh. Der Installer sichert und ersetzt nur server.js und den Relay-Test, prüft den unveränderten Ausgangsstand und startet den Relay neu. Flight-Wettbewerb, Bestenlisten, Ticketablauf-Wächter, DISPLAY_KEY und MegBes-external/-internal bleiben erhalten. Danach Smartphone-Seiten und Electron-Webseiten neu laden.

== Einheitliche Spiele und Bestenlisten ==
Stand 13.10.2026: [[MUTEC – Einheitliche Spiele]] dokumentiert optionale Zweispielerrunden auch für Finde den Ort, vier getrennte Top-10-Listen ausschließlich auf der Electron-Anzeige vor/nach dem Spiel und eigene qualifizierte Arcade-Einträge für Besitzer/Gast. Pong/Pöng werten Tore und aktive Zeit mit Siegbonus. Die vorhandene Flight-Wertung und die Karte mit getrennten Kameras/Hinweisen bleiben erhalten. Frontend hochgeladen und geprüft; 48 Servertests auf dem VPS bestanden. Serverpaket unter /home/clawtronics/mutec-unified-update vorbereitet, root-Installation noch ausstehend. Daten, Schlüssel, Objects, HTML-Video und MegBes-Programme bleiben erhalten.

MUTEC – Arcade

2026-10-13T09:25:34Z

Clawtronics: Gemeinsame Zweispieler-/Bestenlistenstruktur, Kartenduell und Pong-Zeitwertung vorbereitet

Frontend: neue Auswahl Pöng zusätzlich zu Pong, Finde den Ort und Papierflug-Upgrade. Relevante Anzeigen liegen in der mittleren Bildhälfte. Aqua-Navigation steht oberhalb des Inhalts; der gleiche Relay-Token wird zusätzlich im JSON-Body geprüft, wenn PHP den Authorization-Header verliert.

== Installation ==
Das Serverpaket liegt auf dem VPS in /home/clawtronics/mutec-arcade-update. Als root, während Station 50 frei ist:
<code>bash /home/clawtronics/mutec-arcade-update/apply-arcade-update.sh</code>
Die Installation prüft 24 Servertests, sichert geänderte Dateien und startet den Dienst neu. Schlüssel, Umgebungsdatei und MegBes-Programme bleiben erhalten. Das private Datenverzeichnis /opt/mutec-realtime/data gehört dem Dienst mutec-realtime. Vorhandene Bestenlisten werden nicht ersetzt.
Nach Installation Electron neu starten, damit der zusätzlich eingetragene Reiter poeng geladen wird. Auf dem Smartphone die Auswahl neu laden.

== Regeln ==
* Pöng: Zwei Finger führen die Enden; feste Schlägerlänge, eigene Hälfte. Start gegen Computer, Gast per einmaligem QR-Code. Gast kann ausschließlich rechts steuern, ohne MegBes-Rechte. Sieben Punkte entscheiden.
* Flug: 60 Sekunden, genau 42 Ringe, davon 8 dicke Bonusringe. Seedabhängig unregelmäßige Abstände. 100 Basispunkte, Streak-Multiplikator steigt alle fünf Treffer bis ×5; dicke Ringe zusätzlich ×5. Fehlversuch setzt Streak zurück. Treffer drehen, wachsen und verschwinden; verpasste Ringe werden rot. Drei Wolkenformen. Zehn beste Ergebnisse mit drei Zeichen A–Z/0–9, nur vom angemeldeten Besucher nach Display-Endergebnis eintragbar.
* Ortssuche: Acht deutsche Städte (Berlin, Hamburg, München, Köln, Dresden, Leipzig, Stuttgart, Kiel), zufällig ohne direkte Wiederholung. Vier Hinweise, alle acht Sekunden. Stadtzentrum im Fadenkreuz innerhalb 1,5 km bei Zoom mindestens 11 für 1,2 Sekunden. 120 Sekunden Zeit; Punkte max(50, gerundet(1000 − 5×Sekunden − 90×abgeschlossene 8-Sekunden-Zeitstufen)). Beim Timeout null Punkte. Kein Zielkoordinatenversand an Browser während der Suche. Liste in realtime/arcade.js erweiterbar.
* Zoom: Höhenabhängige Anpassung des Display-Zooms entspricht gleicher Nord-Süd-Ausdehnung; seitlich zeigt das breitere Display mehr Karte.
* Sounds: freiwillig auf dem Smartphone aktivieren. Lokale Synthese, keine Audio-Dateien. Display sendet nur freigegebene Effektarten, Gäste können keine Effekte auslösen.

== Protokoll und Module ==
poeng.paddle: ax/ay/bx/by jeweils 0..1, active boolean. Der Relay ergänzt side anhand der Rolle. poeng.action/restart nur Besitzer; poeng.status nur Display. Einladung nutzt weiterhin /pong/guest und ist fest an Spiel UND Feature gebunden.
map.game/action=start nur Kartenbesitzer. map.camera ergänzt viewportHeight. map.game.status wird vom Relay für Besitzer und Display erzeugt.
flight.result/runId,score,hits nur authentifiziertes Flight-Display nach passendem Steuerlauf. POST /flight/highscores nimmt ausschließlich runId und dreistelligen name vom aktiven Flight-Besitzer an. GET /flight/highscores liefert öffentliche Top-10, ohne Tickets/Schlüssel.
game.sound/kind,id nur Spiele-Display; Empfänger sind Besitzer und gegebenenfalls Gast derselben Sitzung. Keine Wiederholung alter Effekte.

== Vor Ort prüfen ==
Zweifingersteuerung auf zwei echten Smartphones, LED-Lesbarkeit/QR-Scan, Audio im Hallenumfeld, Ring-Animationen und Namenseingabe nach vollen 60 Sekunden. Aqua-Tier speichern und Eingang ins Aquarium prüfen. Die lokale Browserprüfung verwendet nur einen simulierten MegBes-Server; sie steuert keine Hardware an.

== Installationsstand ==
11.10.2026: Frontend veröffentlicht, Relay durch Administrator installiert (24/24 Prüfungen erfolgreich), öffentliche Capabilities und Bestenliste geprüft. Electron-Reiter poeng eingetragen; Neustart von Electron erforderlich. Aqua-Syntax auf PHP 8.3 geprüft; JSON-Token erreicht die serverseitige Berechtigungsprüfung auch ohne Authorization-Header. Die erfolgreiche Tierübertragung mit echtem Ticket und die LED-Abnahme erfolgen vor Ort.

== Intro, Spiel und Schluss ==
[[MUTEC – Spielablauf]] beschreibt die Infokarten, getrennten Spiel-/Ergebnisansichten und den zustimmungspflichtigen Gastbeitritt für Pong/Pöng mit beidseitiger Bereitschaft und Countdown. 32 Servertests und Browserprüfungen bestanden. Frontend hochgeladen; Serverpaket unter /home/clawtronics/mutec-flow-update vom Administrator installiert. Alle 32 Tests und die echte Schreibprüfung bestanden; gameFlow ist öffentlich aktiviert. Der Installer korrigiert auch die Schreibfreigabe für /opt/mutec-realtime/data, ohne bestehende Bestenlisten zu ersetzen. MegBes-Programme bleiben unverändert.

== Mobile Pong-Einladung ==
Stand 12.10.2026: Für Pong und Pöng wurde der QR-Code vom LED-Counter auf das Smartphone von Spieler 1 verlegt. Der Counter enthält kein QR-/Einladungspanel mehr; seine Punkteanzeige liegt mittig. Letzte Infokarte: '1 Spieler starten' gegen den Computer oder '2 Spieler' für einen großen unverzerrten QR-Code auf dem eigenen Smartphone. Nach ausdrücklicher Zweispielerwahl im Intro und Gastbeitritt gilt die Einladung bereits als Zustimmung. Bei einer späteren Einladung über den 2-Spieler-Button im laufenden Spiel bleibt die Computerrunde bis zur ausdrücklichen Annahme erhalten. Gast-Infokarten, Bereitschaft und Countdown bleiben bestehen. Gäste erhalten keine weiteren MegBes-Rechte.

Neue Relay-Route POST /mutec-control-api/pong/invite: Nur der aktuelle Besitzer seiner eigenen Pong-/Pöng-Sitzung darf eine kurzlebige einmalige Einladung abrufen. Gäste, fremde Module und abgelaufene Sitzungen sind ausgeschlossen. Der Display-Schlüssel wird nicht an das Smartphone übergeben. Frontend hochgeladen und Browserprüfung mit getrennten Smartphones/Display bestanden. Serverpaket unter /home/clawtronics/mutec-invite-update vorbereitet; 38 Tests auf dem VPS bestanden. Root-Installation steht noch aus: bash /home/clawtronics/mutec-invite-update/apply-invite-update.sh. Der Installer sichert und ersetzt nur server.js und den Relay-Test, prüft den unveränderten Ausgangsstand und startet den Relay neu. Flight-Wettbewerb, Bestenlisten, Ticketablauf-Wächter, DISPLAY_KEY und MegBes-external/-internal bleiben erhalten. Danach Smartphone-Seiten und Electron-Webseiten neu laden.

== Einheitliche Spiele und Bestenlisten ==
Stand 13.10.2026: [[MUTEC – Einheitliche Spiele]] dokumentiert optionale Zweispielerrunden auch für Finde den Ort, vier getrennte Top-10-Listen ausschließlich auf der Electron-Anzeige vor/nach dem Spiel und eigene qualifizierte Arcade-Einträge für Besitzer/Gast. Pong/Pöng werten Tore und aktive Zeit mit Siegbonus. Die vorhandene Flight-Wertung und die Karte mit getrennten Kameras/Hinweisen bleiben erhalten. Frontend hochgeladen und geprüft; 48 Servertests auf dem VPS bestanden. Serverpaket unter /home/clawtronics/mutec-unified-update vorbereitet, root-Installation noch ausstehend. Daten, Schlüssel, Objects, HTML-Video und MegBes-Programme bleiben erhalten.

MUTEC – Spielablauf

2026-10-13T09:25:34Z

Clawtronics: Gemeinsame Zweispieler-/Bestenlistenstruktur, Kartenduell und Pong-Zeitwertung vorbereitet