ich habe vor ca. 1 Jahr von Dashboard auf Webfront (mittlerweile V2.6) umgestellt und kämpfe seit längerem mit einem Problem, bei dem ich nicht weiterkomme. Direkt zum Zeitpunkt der Umstellung war dieses Problem für mich noch nicht erkennbar.
Grunsätzlich funktioniert alles wie es soll. Allerdings blockieren einige (nicht alle) Visualisierungen von Variablenprofilen bei wiederholtem Betätigen der zugehörigen Schaltflächen. Mit „Blockieren“ meine ich das Anzeigen der rotierenden „Zahnradflanken“ als „Fortschrittsanzeige/Sanduhr“.
Ich habe z.B. Variablen vom Typ Boolean, die immer bei mehrmaligen Betätigen blockieren und welche vom gleichen Typ, die das nicht tun.
Wenn ich alle Inhalte, des durch die Boolean-Variable ausgelösten Scripts, auskommentiere ändert sich das Verhalten nicht. Ich bekomme in diesem Fall immer 23 Umdrehungen der Fortschrittsanzeige (ca. 23 Sek).
In einem anderen Fall schalte ich mit einer Integer-Variablen durch einen Wertebereich von 30 Fernsehprogrammen (Wertauswahl-Objekt). Das erste Umschalten zwischen 2 benachbarten Programmen funktioniert noch direkt. Alle weiteren Vorgänge erzeugen jeweils die „Sanduhr“. Bis ich beim letzten Programm angekommmen bin, vergehen so mehrere Minuten -> Das ist unbedienbar.
Ich verwende Win7 und FF (aktuell). Die betreffenden Variablen werden nicht geloggt. Das Verhalten ist unabhängig davon wo ich den Browser verwende (Client / Server / auch Android 4.1).
Ich vermute einen Zusammenhang mit der Variablenprofildefinition oder der Position in der Webfronthierarchie, kann damit aber auch völlig falsch liegen.
Hat jemand ähnliche Probleme? In der Suche habe ich nichts vergleichbares gefunden.
Es wäre toll, wenn Ihr mir helfen würdet das Problem zu verstehen. So langsam verliere ich echt die Freude am Webfront.
ich kann das Problem bestaetigen … war drauf und dran selbst ein Thread aufzumachen, habe aber im Moment nicht so richtig Zeit mich um das Thema zu kuemmern.
Ich konnte aber auch seit IPS 2.5 beobachten, das das Problem beim wiederholten Schalten ( 3. - 4. Mal) auftritt. Mit irgendwelchen Skripten hat das m.E. nicht zu tun, das Problem tritt auf bei jeder banalen Variablen, ohne jegliche Funktionalitaet dahinter. Auch ist es reproduzierbar sowohl in Chrome als auch in Firefox.
Was ich bisher herausfinden konnte ist, dass es an der Darstellung / am Rueckkanal zum Browser liegt. Es kann naemlich in der Konsole beobachtet werden, dass der Wert praktisch sofort umgeschaltet wird, aber ewig braucht, bis er im Browser aktualisiert wird.
Ich habe mir das Ganze mit dem Firebug angeschaut:
POST http://localhost:88/data/ips.php?pt=07aa3834f510da2d202c16c6b38064fa&ts=1349617695235 | 200 OK | 37ms dojo.js (line 14)
GET http://localhost:88/data/ips.php?pt=07aa3834f510da2d202c16c6b38064fa&ts=1349617695312&getMessages= | 200 OK | 20.04s
Der Wert wird in 37 ms umgesetzt, allerdings dauert es geschlagene 20 sek. bis der Webfront aktualisiert wird. Witzigerweise sind es, tasaechlich, immer 20 Sekunden!
An der ‚Leitung‘ kann’s nicht liegen, es ist alles auf localhost.
die Firebg-Ausgabe habe ich jetzt nicht verifiziert, aber alles andere trifft auch auf meinen Fall zu.
Bei mir ist das Problem auch irgendwann im Laufe der V2.5 entstanden.
Der Effekt besteht schon sehr lange, und wurde auch schon oft berichtet. Allerdings eher in Verbindung mit leistungsschwachen nicht Windows Clients (Android).
Vom IPS HQ gabs dazu aber leider noch keinen brauchbaren Kommentar.
Horst hat zwar mal etwas von zu wenig maximal möglichen Kommunikations Slots bei alternativen Browsern geschrieben, hmm
Vor etwa 1 1/2 Jahren ist es mir das erste mal aufgefallen. Damals passierte es nur selten am Desktop. Unter Androd aber massiv.
Nun ists auch am Desktop wie bei euch sehr schön reproduzierbar.
u.a. versuchsweise auch bei Buttons die gar keine Funktion dahinter haben.
Soweit ich mich erinnert hatte ich auch mal beobachtet das nur der Client verzögerte ist an dem der Button betätigt wurde. WF welche auf anderen Rechnern liefen zeigten die Variablenänderung sofort an.
Sieht für mich so aus als obs da irgendwelche Timeouts in der Kommunikation geben würde.
Reine Spekulation, ich vermute aber mal das die gerade in mehrere Therads erörterten Probleme mit Safari am IPad auch aus dieser Ecke kommen.
@bbernhard: Das mit den zwei Browsern stimmt: es wird nur im ausloesenden Browser verzoegert, alle anderen Webfronts werden umgehend aktualisiert.
Grundsaetzlich kann ich nur sagen, dass (wenn alles, was wir beobachtet haben, auch stimmt) ich das fuer einen handfesten und schwerwiegenden Bug halte. Ich muss in etwa vier Wochen eine komplexe IPS Installation abliefern, der Kunde wird mir garantiert diesen Fehler um die Ohren hauen. Und zwar zu Recht.
So, Freunde, diese Geschichte hat mir keine Ruhe gegeben.
Ich habe die Sache analysiert und auf einem sehr alten, langsamen Rechner getestet, da kommt es nicht vor.
Deswegen habe ich ‚irgendwie‘ den Eindruck gewonnen, dass IPS vielleicht zu schnell reagiert und der Webfront einfach nicht mitkommt.
Wie dem auch sei: wenn ich eine Verzoegerung von 50 ms im Aktionsskript einbaue, funktioniert’s bei mir einwandfrei. Bei kleineren Werten (10 - 30 ms) besteht das Problem nach wie vor.
Woran das liegt? Vielleicht koennen die IPS Entwickler etwas dazu schreiben.
Sind die 50 ms ein absoluter Wert oder vielleicht systembedingt? Keine Ahnung, ich wuerde mich freuen, wenn Ihr es ausprobiert und Eure Erfahrungen hier postet.
Hier noch der Code:
if ($_IPS['SENDER'] == "WebFront") {
SetValue($_IPS['VARIABLE'], $_IPS['VALUE']);
IPS_Sleep(50); // hiermit verschwindet die Verzoegerung!
}
Viele Gruesse
Adrian
P.S. Auf diesem Wege ein Dankeschoen an meine holde Gattin, die an einem Sonntag nachmittag sicherlich was besseres zu tun gehabt haette, als auf mich zu warten, bis ich das hier gefunden habe :o
Genau das wars! Da wundern wir uns seit Ewigkeiten und dann kommst du und findest die Lösung.
Bei mir reichen übrigens schon 10msec um den Spuk verschwinden zu lassen.
Das erklärt jetzt auch warum es nicht immer und nicht bei allen Buttons aufgetreten ist.
1000 Dank und schöne Grüße, - auch an deine Gattin
bb
Leider hilft bei mir die Verzögerung nicht. Ich habe 20, 50 und 200ms ausprobiert.
Manchmal kann ich 4-mal umschalten, bevor der Browser blockiert. Manchmal nur 2 mal.
Es verhält sich in etwa so, als wenn eine Queue existiert, die irgendwann voll ist und sich nur langsam wieder leert.
@christian: versuch Dich an den richtigen Wert heranzutasten. Ich habe mit 1000 ms angefangen und mich an den fuer mich richtigen Wert herangetastet. Das ist uebrigens keine volle Queue, ganz im Gegenteil: es ist ein Timeout nach 20 sek, wenn vom Server gar keine Antwort kommt. Das kann man mit dem Firebug sehr gut sehen: wenn es klappt, kommt ein JSON mit Inhalt (Werten) vom Server. Wenn es Verzoegerungen gibt, liegt es daran, dass keine Antwort kommt und der Prozess nach 20 sek. automatisch terminiert. Dojo ist schlau genug um keine Fehlermeldung zu werfen, es tut nach 20 sek. also einfach so, als ob ‚alles in Ordnung‘ waere.
@bbernhard: ich freue mich, dass es funktioniert hat. Ich habe hier schon so viel gelernt, es ist eine Freude, wenn ich etwas zurueck geben kann.
Bei meinem Testfall musste die Verzögerung direkt an den Anfang (hatte es zu erst am Ende probiert).
Dieses Script wird durch Änderung der Variable getriggert, die wiederum vom Webfront gesetzt wird.
IPS_Sleep(20);
if ($_IPS["SENDER"]=="Variable") {
if ($_IPS["VALUE"] == false) {
IPS_SetEventActive(39123 /*[Rolladen\Global\Rolladen (Ausstehend)\]*/, true);
IPS_SetEventActive(48704 /*[Rolladen\Global\Rolladen (Ausstehend)\]*/, true);
} else {
IPS_SetEventActive(39123 /*[Rolladen\Global\Rolladen (Ausstehend)\]*/, false);
IPS_SetEventActive(48704 /*[Rolladen\Global\Rolladen (Ausstehend)\]*/, false);
}
echo "Sleep";
#IPS_Sleep(20)bringt an dieser Stelle nicht das gewünschte Ergebnis;
}
Hingegen funktioniert es in diesem Fall mit Sleep am Ende
Cool, Danke auch von mir! Der Busy-Balken ist praktisch weg…
Leider funktioniert der Trick so direkt nicht, wenn man bei einem HomeMatic-Thermostaten den SETPOINT direkt im WebFront visualisiert (und auch schön das Häkchen bei Status emulieren im HM-Konfigurator gemacht hat). Dann läuft das über Standard-Aktion und die rennt scheinbar in genau das gleiche Timing-Problem.
Man könnte wohl vielleicht ein komplett eigenes Skript bauen und den SETPOINT in die entsprechende HM-Variable schreiben, aber das ist mir jetzt auch zuviel… und wenn schon ein Ticket offen ist, wird vielleicht auch das gleich mit behoben…
