MUTEC – WebSocket-Steuerung

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 separate WebSocket-Dienst auf dem VPS ist noch nicht durch diesen Upload installiert; die Geräteabnahme steht aus. v2 ersetzt die früheren Pakete mit CONTROL_TOKEN.

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:

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

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:

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

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.

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

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:

sudo nginx -t

Ö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:

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

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

1. Ohne Ticket dürfen Bedienseiten keine Befehle oder Schreibzugriffe zulassen.
2. Mit gültigem Ticket: Login → Menü → Aqua, Karte oder Medien.
3. Ein zweites Ticket darf das Menü öffnen, aber keine Anwendung übernehmen. Auch Aqua ist exklusiv.
4. „Zur Auswahl“ bei Besucher 1: Station 50 wird frei; Besucher 2 kann übernehmen. Alte Steuertokens müssen unwirksam sein.
5. Stationsseitiges IDLE/Timeout für 50 auslösen: bisherige Sitzung verliert die Kontrolle; neue Auswahl erhält eine neue Reservierung.
6. Karte verschieben und zoomen: gleicher Mittelpunkt, Zoom und Ausschnitt in Electron. Unterschiedliche Displayformate werden mit Rändern ausgeglichen; Verzögerung ist netzabhängig.
7. 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.
8. 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.
9. Aqua-Tier speichern, Bewegungen sowie Medien-/YouTube-/Nachrichtenformulare prüfen. Featurefremde oder ungültige Tokens dürfen keine Dateien schreiben.
10. 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.

sudo journalctl -u mutec-realtime -n 80 --no-pager

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.

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

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 vom Besucher gemeldete Smartphone-Fehler ließ sich im Testbrowser nicht reproduzieren. Eine erneute Prüfung auf dem betroffenen Gerät steht aus. Falls sie erneut scheitert, zeigt die Oberfläche nun den genauen Anmeldeschritt und HTTP-Status. Ein neuer Code auf dem Ticket-Monitor ist nach erfolgreicher Aktivierung normal.

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