MUTEC – WebSocket-Steuerung: Unterschied zwischen den Versionen
Frontend- und Ticket-Upload dokumentiert; WebSocket-VPS-Installation weiterhin offen |
Erfolgreiche Serverinstallation und oeffentliche nativevideo-Freigabe bestaetigt |
||
| (16 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt) | |||
| Zeile 1: | Zeile 1: | ||
= MUTEC v2 – Einrichtung mit MegBes-Ticket = | = 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 | 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 == | == Aktuelle Inbetriebnahme: Google Maps und Electron == | ||
Die Google- | 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 Electron-Meldung „Diese Anzeige ist noch nicht in Electron eingerichtet“ bedeutet, dass der private DISPLAY_KEY fehlt. Auf dem VPS mit | 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 == | == Ergebnis und Bedienung == | ||
| Zeile 148: | Zeile 150: | ||
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. | 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]]. | Siehe auch [[Web-Frontend entwickeln]], [[UDP und Stationszustände]], [[Tine]] und [[Messe]]. | ||
| Zeile 154: | Zeile 178: | ||
[[Kategorie:Frontend]] | [[Kategorie:Frontend]] | ||
[[Kategorie:Entwicklung]] | [[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. | |||