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 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 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 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.

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 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.

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