MUTEC – WebSocket-Steuerung: Unterschied zwischen den Versionen

← Zum vorherigen Versionsunterschied Zum nächsten Versionsunterschied →

@@ Zeile 1: / Zeile 1: @@
 = 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-Freigabe und Electron-Anzeigeschlüssel müssen noch eingerichtet werden; die vollständige Geräteabnahme steht aus. v2 ersetzt die früheren Pakete mit CONTROL_TOKEN.
+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. Electron vollständig beenden und erneut starten; die Abnahme nach diesem Neustart steht noch aus.
+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 `RefererNotAllowedMapError` 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 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 `sudo grep '^DISPLAY_KEY=' /etc/mutec-realtime.env` 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.
+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 &#x27;^DISPLAY_KEY=&#x27; /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 ==
@@ Zeile 153: / Zeile 153: @@
 == Sporadische Ticket-Prüfung: Untersuchung vom 09.10.2026 ==
-### Ursache und Korrektur der Projektzuordnung
+=== 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.
@@ Zeile 161: / Zeile 161: @@
 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. Die sporadische Ursache ist noch nicht nachgewiesen.
+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.