Hallo zusammen,
ich habe ein Wallboard angelegt, welche immer den Bereitschaftsmodus zeigen soll. Nun zeigt es aber ständig an bitte warten. Wenn ich in den Einstellungen Alarmierung aktiviere zeigt er sofort die Alarmierung an. An was kann das liegen?
Hallo Florian,
da ist im Release ein Bug drin.
Das Wallboard sendet leider im derzeitigen Release keine Bereitschaftskonfiguration, wenn ein Alarm offen ist und dieser Haken gesetzt ist.
Die Alarmzuweisung zu den Wallboards wurde mittlerweile abgeändert und löst dann unter anderem dieses Problem.
Das neue Release sollte hoffentlich nicht mehr lange auf sich warten lassen.
Schöne Grüße
Stefan
Hallo Florian,
die Version 1.4.0 (BERLIN) ist auf der Website als Download verfügbar. Bitte mal mit der neuesten Version testen, der Fehler sollte nun auch behoben sein.
Grüße
Wir haben die Version Berlin V1.4.1 und greifen übers lokale Netzwerk auf die Weboberfläche des Servers zu. Wenn wir ein Wallboard mit der Standardkonfiguration der Widgets für den Bereitschaftsmodus erstellen und über den blauen Button öffnen wollen, öffnet sich ein neuer Tab mit dem Hintergrundbild. Es erscheint dann aber nur der blaue Ladekreis und es erscheinen keine Widgets. Beim öffnen des Editiermodus unter Widgets hinzufügen gibt es auch keine Widgets zum auswählen.
Portfreigaben 5010 und 5020 sind in der Config eingegeben und die beiden Plugins rest API und Wallboardplugin sind aktiviert.
Hi Martin,
wie ist denn Dein Server genau installiert?
Grüße
Jens
Hi Jens,
haben den Server über Docker Compose installiert.
Da wir noch keine Domain haben, haben wir in Nginx Proxi Manager noch nichts konfiguriert.
Wir haben im Compose File wie uns @Dazza erklärt hat, die Ports 5000 für die Weboberfläche und 5010:5020 zum testen des Wallboards hinzugefügt.
Hey,
habt ihr also in der yml folgendes stehen?
ports:
- '5000:5000'
- '5010:5010'
- '5020:5020'
momentan
5000:5000
5010:5020
zuerst hatten wir es so:
5000:5000
5010:5010
5020:5020
da hat sich das Wallboard aber nicht öffnen lassen
"Canno Get /Wallboard/Wallboard .
Wir probieren es nochmal so, vielleicht hatten wir davor nur ein Plugin zum aktivieren vergessen.
Melde mich wieder
Okay alles klar also es sollten rechts und links immer die gleiche Ports stehen
5000:5000
5010:5010
5020:5020
Tragt das so in der yml ein. Vergesst dann nicht nochmal neu docker compose up -d auszuführen und überprüft danach nochmal, ob die Plugins aktiv sind.
Und nach dem Plugin aktivieren einmal einen Neustart ausführen im Adminpanel.
Jetzt funktioniert es 
. Vielen Dank.
Euer Support ist echt spitze.
Das freut mich sehr.
Falls es wieder was gibt einfach fragen und viel Spaß beim Wallboard bauen 
Hallo,
ich habe leider seit heute ein ähnliches Problem.
Server läuft auf Debian 11 und der Alarmiator wurde über den Docker composer Installationsleitfaden installiert.
Das komische daran. Das Wallboard hat heute Nacht noch funktioniert. Nun kommt nur noch der Ladekringel (beim Editor und beim Wallboard)
Ich kann auch in den Logfiles nichts finden, das es irgend ein Problem geben würde.
Folgende Sachen wurden schon versucht:
In der Firewall sind die Ports 80 und 443 freigegeben.
Die Alarmiator App funktioniert auch.
KATSYS Anbindung funktioniert ebenfalls.
Gib es weitere Logfiles die man prüfen könnte oder gibt es Tests die man ausführen könnte um das ganze weiter eingrenzen zu können?
oder gibt es eine Übersicht was für Werte gesetzt sein müssen, damit das funktioniert.
Ich hoffe ihr könnt mir helfen.
Vielen Dank gruß Andreas
Hallo,
Ladekringel bedeutet das er keine Daten über die Websocket Verbindung empfängt oder keine Verbindung zum Websocket möglich ist.
Logs würden da nur die Browser Logs helfen, wenn man F12 drückt, aber pauschal zu sagen es liegt an dem und dem ist schwierig, grad wenn es wohl schonmal ging.
Websocket ist die Thematik mit dem Port 5020 (intern)
Ok danke das hat mir schon mal geholfen. Das problem liegt dann da:
GET http://*************.de:5020/socket.io/?EIO=3&transport=polling&t=OQyajxR net::ERR_CONNECTION_REFUSED
Im Docker Composer yml waren folgende Ports:
ports:
- '80:80'
- '81:81'
- '443:443'
ich hab nun den - ‚5020:5020‘ auch hinzugefügt hat aber leider auch nichts gebracht:
Die Konfig im Proxy:
Es sieht auch so aus als wäre der Port im docker Container verfügbar:
root@0886580cd5cf:/alarmiatorserver# netstat -tulpn
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 127.0.0.11:39965 0.0.0.0:* LISTEN -
tcp6 0 0 :::5010 :::* LISTEN 43/node
tcp6 0 0 :::5020 :::* LISTEN 44/node
tcp6 0 0 :::5000 :::* LISTEN 8/node
udp 0 0 127.0.0.11:44220 0.0.0.0:* -
Auf dem Server selbst sind die Ports ebenfalls verfügbar.
root@alarmiator-test:~# netstat -tulpn
Aktive Internetverbindungen (Nur Server)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 664/docker-proxy
tcp 0 0 0.0.0.0:81 0.0.0.0:* LISTEN 643/docker-proxy
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 414/sshd: /usr/sbin
tcp 0 0 0.0.0.0:443 0.0.0.0:* LISTEN 623/docker-proxy
tcp6 0 0 :::80 :::* LISTEN 672/docker-proxy
tcp6 0 0 :::81 :::* LISTEN 651/docker-proxy
tcp6 0 0 :::22 :::* LISTEN 414/sshd: /usr/sbin
tcp6 0 0 :::443 :::* LISTEN 629/docker-proxy
udp 0 0 0.0.0.0:68 0.0.0.0:* 370/dhclient
Ich kann momentan echt nicht sagen wo es gerade hängt.
Der Datenaustausch zwischen Browser (WallBoard) und docker sollte doch folgendermaßen gehen oder.
Browser > URL > Router > Proxy > Docker Container
Wenn man Router den Port 5020 nicht explizit freigeben muss, sollte das doch eigentlich funktionieren.
kann auch sein das ich mal wieder den Wald vor lauter Bäumen nicht sehe 
Grundsätzlich hast du schon recht, allerdings musst du fürn Proxy über HTTPS gehen und nicht über HTTP. Wenn du über HTTPS gehst, sollte alles auch so funktionieren wie es soll.
Die Compose File ist bewusst so gestaltet das es über den Proxy und HTTPS funktioniert. Wenn davon bewusst abgewichen wird, dann muss man es eben selbstständig die Ports etc anpassen.
Ich weiß nicht warum aber nun gehts
Einzig was ich gemacht hab socket.io entfernt und wieder neu hinzugefügt.
Das Komische dran ist ja das ich den Port 5020 erst nachdem es nicht mehr funktioniert hat im yml hinzugefügt hab.
bin mal gespannt ob es morgen früh auch noch geht. Danke für die extrem schnelle hilfe. Echt Hammer.
Ich geh mal davon aus das die Proxykonfigs so nicht stimmen also wenns ist bitte gern berichtigen. Danke
Ich vermute du hast dich nun über https verbunden 
Falls ja, dann kannst den 5020 wieder rauswerfen
Hey was hast du jetzt genau geändert?
Die Reverse Proxy Einstellung sieht so aus wie im Handbuch. Hast du davor einfach vergessen die Location hinzuzufügen oder hast du auch was an der docker-compose.yml geändert?
War es einfach nur, dass du dich davor nicht per https verbinden wolltest, was den Reverse Proxy versucht zu umgehen?
Freut mich auf jeden Fall, dass es wieder geht.
Netzwerktechnisch bin ich net so gut aufgestellt.
Du meinst den 5020 aus der composer yml?
Ok mache ich morgen gleich.
In der URL ganz am Anfang https:// anstatt http:// und dann läuft alles auch über den Proxy und man braucht keinen 5020.
Bedeutet deine Änderung hatte keine Auswirkung, du hast einfach durch zufall die HTTPS Route genommen.
