EDOMI-Releases/Updates | Aktuell: Version 2.03

[gaert]

Gut, dann übernehme ich das mal so - auch wenn Portforwarding wie gesagt keine gute Idee ist.

In der Datei /usr/local/edomi/www/visu/apps/app0.php ziemlich am Ende die folgende Zeile austauschen:

                visu_socket.open('<?echo global_serverIP;?>',<?echo global_visuWebsocketPort;?>);

austauschen gegen:

                visu_socket.open(window.location.host,<?echo global_visuWebsocketPort;?>);

[KNXFan1970]

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.

Merkwürdig ist, dass auch bei mir, wie bei baumhaus123 der Effekt auftritt, dass wenn ein(!) iOS-Gerät die Websocket-Verbindung beim Standby verliert - alle anderen Geräte im Netzwerk auch keine Verbindung mehr bekommen und auch nach Neustart des Browsers - kein Kontakt zum Server via "AJAX" hergestellt werden kann. Leider konnte ich momentan noch nicht weiter testen, da ich vorerst auf 1.51 zurück wechseln musste.

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

[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

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

[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

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

[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

[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

[gaert]

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

[SeatSLF]

@gaert: das Visuelement Sprachausgabe nutze ich

[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

[basaltnischl]

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

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

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