EDOMI-Releases/Updates | Aktuell: Version 2.03

[Jue]

ich habe im Docker folgende Portzuweisung vorgenommen:

Lokal 42902 auf 8080 tcp

Edomi meint aber lapidar:

VISU

583

Socket failed to open at port 8080: Cannot assign requested address

Firewall am NAS ist aus...

Hast du es jetzt hinbekommen? Hab das gleiche Problem im Docker.

lg

Jürgen

[EPIX]

nein, leider noch nicht....

[gaert]

SeatSLF
Nein, das ist so nicht vorgesehen. Wie bei allen anderen Visuelementen auch wird bei einem Seitenaufruf das dyn. Design entsprechend dem KO-Wert (erneut) angewendet. Für mehr Flexibilität kannst Du doch einfach den entsprechenden Befehl ("Visu: Sprachausgabe") verwenden - dieser funktioniert unabhängig von einem Visuelement.

@KNXFan1970
Kann ich leider nix zu sagen - auf meinem iPad2 funktioniert es trotz Standby wunderbar. Aber Apple baut ja ständig irgendwas Neues in Safari/iOS ein - insb. "Energiespar-Gedöhns" (was dann häufig zu irgendwelchen Problemen beim "nicht-Sparen" führt...). Wenn Du den roten Kringel siehst, versucht die Visu den Kontakt zum Server via "AJAX" herzustellen - der Websocket ist also jetzt noch gar nicht aktiv. Erst wenn die Kontaktaufnahme gelingt, wird der Websocket aktiviert. Die Projektaktivierung hat hiermit eher wenig zu tun, vermutlich genügt es die Browserseite neu zu laden.

[KNXFan1970]

@KNXFan1970
.... Wenn Du den roten Kringel siehst, versucht die Visu den Kontakt zum Server via "AJAX" herzustellen - der Websocket ist also jetzt noch gar nicht aktiv. Erst wenn die Kontaktaufnahme gelingt, wird der Websocket aktiviert. Die Projektaktivierung hat hiermit eher wenig zu tun, vermutlich genügt es die Browserseite neu zu laden.

Leider reicht es nicht die Browserseite neu zu laden. Eher scheint die Kommunikation 'blockiert' zu sein. Eine Kontaktaufnahme aller(!) iPads ist dann nicht mehr möglich. Bisher konnte ich es nur via Projektaktivierung wieder zum Laufen bringen. Merkwürdig...

[basaltnischl]

Ist bei meinen iPads nicht so ... funktioniert nach dem Abschalten.
Nur das iPad 1 will nicht mehr.

[gaert]

Aktiviere doch mal das Visu-Logging in der edomi.ini, evtl. ergeben sich hier neue Erkenntnisse. Ein Neuladen der Seite sollte eigentlich immer helfen, denn schließlich starteten die Client-Scripte dann alle neu und "vergessen" alles zuvor gewesene

[SeatSLF]

@gaert: das Visuelement Sprachausgabe nutze ich

[gaert]

Äh... Ja... Daher der Tipp den *Befehl* zur Sprachausgabe stattdessen zu nutzen.

[tger977]

Hallo zusammen,

Update ist bei mir auch drauf, die Visu reagiert wirklich nun deutlich schneller und ich bilde mir ein auch mit deutlich weniger Traffic, was bei schlechtem Mobilnetz sich positiv äußert!

gaert Nun ist mir aufgefallen, dass nach Nutzung der Visu, wenn keine andere App in den Vordergrund gebracht wird und der Bildschirm (nach einiger Zeit) erwartungsgemäß abschaltet, im Anschluß - nach Aufwecken des iPad - mitunter die Visu nicht mehr reagiert und auch kein neuer Aufruf mehr möglich ist. Man bleibt in diesem Fall beim 'roten rotierenden Startkreis' hängen. Danach ist von keinem iPad mehr ein Start der Visu möglich.

ich habe hier ähnliche Probleme... Bei mir kommt auch der rote Kringel und zwar immer nachdem ich über Nacht das WLAN abgeschaltet und dann morgens wieder aktiviert habe. Beim Wiederstart vom WLAN der Fritzbox kommt leider die Visu nicht mehr in Gang. Bei mir hilft es jedoch das WLAN manuell nochmal zu deaktivieren und dann wieder zu aktivieren?! Eine Projektaktivierung brauche ich nicht, ist aber genauso wenig WAF tauglich.

Vielleicht hat da nochjemand eine Idee was man anschauen kann. Das Visulog habe ich jetzt mal aktiviert...

Gruß
Andi

[steffen79]

gaert spricht etwas dagegen den websocket nicht auf serverIP sondern auf die aktuell benutzte Adresse zu öffnen?
Also:

/usr/local/edomi/www/visu/include/js/main.js
// socket=new WebSocket('ws://'+serverIp+':'+serverPort);
socket=new WebSocket('ws://'+window.location.host+':'+serverPort);

Da ist man flexibler wenn man Edomi von aussen über bestimmte Forwardings aufruft...

Gruß,
Steffen

[baumhaus123]

ich habe hier ähnliche Probleme... Bei mir kommt auch der rote Kringel und zwar immer nachdem ich über Nacht das WLAN abgeschaltet und dann morgens wieder aktiviert habe. Beim Wiederstart vom WLAN der Fritzbox kommt leider die Visu nicht mehr in Gang. Bei mir hilft es jedoch das WLAN manuell nochmal zu deaktivieren und dann wieder zu aktivieren?! Eine Projektaktivierung brauche ich nicht, ist aber genauso wenig WAF tauglich.

Vielleicht hat da nochjemand eine Idee was man anschauen kann. Das Visulog habe ich jetzt mal aktiviert...

Ich muss die Probleme bei mir leider bestätigen. Bisher konnte ich keine Systematik erkennen, mit der ich das Problem bewusst provozieren kann. Bei einem "Ausgehenlassen" des Gerätes (bei mir iPhone 6S, aktuellstes iOS 10.3.3) funktioniert es meistens bei erneuten starten wie gehabt. Irgendwann komme ich dann aber auch nicht mehr in die Visu, und zwar von keinem Gerät aus (weder anderes iPhone noch über macOS). Nach ein paar Minuten geht es dann aber wieder, ohne dass ich etwas tun musste (Projektaktivierung o.Ä.). Werde das mit dem WLAN-Reconnect mal testen, wenn das Problem wieder auftritt.

[gaert]

Da kann ich leider nix machen - das muss Apple lösen Bei meinem iPad2 (iOS 9) verhält es sich so:

Wenn ich das iPad in den Standby versetze (mit geöffneter Visu), bleibt die Verbindung noch einige Minuten (?) bestehen und die Visu arbeitet beim Einschalten sofort weiter. Nach längerer Zeit (genau weiß ich das nicht) im Standby (also quasi Aus) ist die Visu zunächst eingefroren, es wird also kein Kringel angezeigt sondern die "funktionslose" letzte Visuseite. Die Visu reagiert dann auf nix - aber: Nach ca. 30 Sekunden werden plötzlich sämtliche aufgelaufenen Klicks hintereinander verarbeitet! Das iPad "merkt" also durchaus noch was während keine Reaktion erfolgt. Offenbar muss der Websocket in iOS erstmal irgendwie warmlaufen

Allerdings stört mich das alles nicht die Bohne, denn das "Wand-iPad" ist 24/7 eingeschaltet und zeigt brav die Visu an. Das bisschen Strom gönne ich mir einfach mal

[gaert]

gaert spricht etwas dagegen den websocket nicht auf serverIP sondern auf die aktuell benutzte Adresse zu öffnen?
Also:

/usr/local/edomi/www/visu/include/js/main.js
// socket=new WebSocket('ws://'+serverIp+':'+serverPort);
socket=new WebSocket('ws://'+window.location.host+':'+serverPort);

Funktioniert das denn bei Dir ohne Weiteres? Denn der Server kennt die WAN-IP in diesem Kontext nicht und bindet den Socket an die LAN-IP.

Falls dies zuverlässig funktioniert kann ich das gerne so übernehmen (also window.location.host statt die LAN-IP).

[Winni]

Falls dies zuverlässig funktioniert kann ich das gerne so übernehmen (also window.location.host statt die LAN-IP).

Bei mir klappts, bin aber erst seit 4 Stunden auf 1.52 und die Modifikation ist seit 1 Stunde aktiv

[steffen79]

Bei mir klappt das bisher auch absolut problemlos. Ggf sollte man nochmal prüfen ob nicht window.location.hostname "richtiger" ist.
Ich sehe da eigentlich kein Nachteil: Edomi soll sich weiter ruhig an seine feste lokale LAN binden. Nur funktioniert mein aktuelles port-forwarding-client-auth-https-setup nur, wenn edomi nicht immer stur zur 192.168.x.y verbindet - sondern auf dasselbe ding, was ich auch in den browser schreibe.

Mir fällt gerade kein Beispiel ein, wo das von Nachteil oder Gefahr sein könnte...?