Vis Reaktionszeiten
-
Hallo,
gefühlt reagiert vis langsamer als DashUI. Ich lasse mir z.B. anzeigen, daß ein Fenster offen ist. Es dauert aber recht lange, bis eine Zustandsänderung an den Tablets sichtbar wird.
Was sind die zeitbestimmenden Parameter und wie kann man sie beeinflussen? Was sind vernünftige Wertebereiche für diese Parameter?
Beim Rega-Adapter habe ich Polling aktiviert mit 30 Sekunden.
Die unterschiedlichen Anzeigegeräte reagieren verschieden schnell.
Am schnellsten der Windows PC z.B. mit Firefox. von einigen Sekunden bis etwas über 30 Sekunden schon beobachtet.
Nur wenig langsamer ist der Nexus 7 mit Android KitKat und Boat Browser.
Unerträglich langsam hingegen ist der Archos 8" mit Android 4.0 und Boat Browser.
Kann ich bei den Tablets das Timing beeinflussen?
-
Hi,
zu den Systemvariablen hatte ich auch so etwas festgestellt.
Bluefox hat dies allerdings aufgeklärt:
http://forum.iobroker.org/viewtopic.php?f=17&t=758
Hilft dir das schon weiter ?
Gruß
Michael
-
Klingt gut, aber was ist "BidCoS-RF:50.PRESS_SHORT"? Das steht auch in den Einstellungen des HM-Adapters.
Ist das eine der 50 virtuellen Kanäle der CCU? Eventuell gerade die #50? Die habe ich schon in Gebrauch. Vielleicht kann ich das in den Adaptereinstellungen auf 49 ändern. Mal testen.
Scheint nicht wirklich viel gebracht zu haben. Kanal50 ist bei mir schon belegt und mit Kanal 49 ergibt sich kein Geschwindigkeitsvorteil.
Die Reaktionszeiten auf meinem Windows-PC und dem Nexus schwanken weiterhin bis ca. 30 Sekunden.
DerArchos Arnova hängt fast 4 Minuten hinterher. Das geht gar nicht. Kann man da an der Browsereinstellung etwas verändern?
-
Also erst einmal das allgemeine:
Die views werden auf dem client geändert.
Die Geschwindigkeit hängt allein von dessen performance ab. Ein Archos ist deutlich weniger motorisiert als ein nexus7!
Zusätzlich ist die vom Browser verwendete JavaScript engine noch an der Geschwindigkeit beteiligt.
Die Daten, die über hm-rpc kommen (Datenpunkte) werden direkt verarbeitet. Daten von hm-Rega (Variable, Programme) nur wenn gepollt wird (um tante Rega nicht abzuschiessen ist das default intervwll 30 sec.) oder…
Der in der konfig definierte virtuelle Taster gedrückt wird.
Wenn man in allen Programmen, die eine systemvariable verändern zusätzlich noch diese virtuellen Taster auslöst, braucht man gar nicht mehr zu Pollen, die Daten werden refresht, wenn der Taster ausgelöst wird.
Gruß
Rainer
-
Vielen Dank, erst mal.
Experimentelle Befunde:
Der virtuelle Taster scheint bei mir nicht zu funktionieren. Mußte allerdings auf 49 ausweichen, weil 50 bei mir bereits anderweitig belegt.
Das Arnova war billig, aber dennoch viel zu teuer, gemessen an der Zeit, die es mich schon gekostet hat.
Habe beim Arnova jetzt 3 Dinge verändert, und es kann bei der vis-Anzeige momentan mit dem Nexus fast Schritt halten:
1. Reboot
2. Wechsel von Boat Browser (neuestes Update) auf Firefox (ältere Version)
3. Wechsel von einer neu angelegten, auf den 8" Bildschirm angepaßten View-Kopie (mit höheren Widget-#) auf die ursprüngliche View. Darin sind die widget-# kleiner.
Wie gesagt, ist die Arnova-Anzeige gerade fast so schnell wie die des Nexus. Werde beobachten, ob das so bleibt, oder ob sich da mit der Zeit der Speicher zumüllt.
Die Zeitliche Abfolge sieht bei mir zur Zeit so aus (Stichprobe).
1. Sensor wird ausgelöst.
2. Nach 8 Sekunden ändert sich die Anzeige der CCU1. Btw. die Tablets sollen u.a. diese Anzeige ersetzen, damit ich die CCU1 durch was schnelleres ersetzen kann.
3. nach weiteren 28 sec, also insegsamt 34 sec. ändern sich die Anzeigen der Tablets
Ich habe eine zentrale Routine, die die Anzeige der CCU1 bedient, wenn sich der Anzeigeinhalt ändern soll. Diese Routine ruft eine weitere auf, die ein Diplay-Ein Kommando für die Tablets und auch den Bidcos-RF49 press short Tastendruck auslöst. Diese Routine wird auch von einem Bewegungsmelder ausgelöst. Das Displayanschalten kann man beobachten, das Programm wird also durchlaufen.
Worauf triggere ich? Gute Frage. Das Programm welches die Änderungen vornimmt, wird selbst durch Geräteevents angesteuert. Aber es handelt Stringvariablen, also Systemvariablen. Und diese Systemvariablen werden von den vis-widgets eingelesen und angezeigt. Dann triggere ich auf die hm-Rega und der BidCos RF49 short_press sollte ja eigentlich eine Beschleunigung bewirken. Tut er aber nicht.
Wenn ich das recht verstanden habe, wäre die Visualisierung schneller, wenn man die ganze Visualisierung an den Geräten selbst und nicht an Systemvariablen (Strings) fest machen würde. Kann ich mir mal überlegen, wenn die CCU1 hier einen Nachfolger erhalten hat und das Programmieren nicht nur aus Warterei besteht.
-
Vielleicht kann ich mich hier mal anhängen.
Ich habe mehrere Tablets in Verwendung. Darunter auch ein Sony Z3 Tablet. Also eigentlich recht schnell vom Prozessor.
Leider ist es so, ich schalte das Display an. Vis ist bereits geöffnet. Leider stimmen dann die Stati nicht, oder sie aktualisieren sich in diesem Moment teilweise.
Aber wenn ich dann z.B. ein Licht einschalten will, dann passiert erstmal nichts. Das Icon zeigt bereits eingeschaltet.
Wenn ich allerdings das VIS schließe und direkt neu aufmache, dann funktioniert es erstmal reibungslos.
Alles Android (Chrome). LXCCU auf Cubie und IoBroker auf Raspi2.
Wäre schön wenn mir jemand einen Tip geben kann wie ich die Sache beschleunigen kann.
Gruß Sebbo
-
Ich lasse das WLAN immer an, auch bei ausgeschaltetem Display. Bisher blieb die Verbindung stabil. Jedenfalls stabiler als bei DashUI. Das Thema Schnelligkeit ist ein anderes und noch nicht gelöst, s.o.
Einstellungen:
Natürlich muß in den Android-Einstellungen: "WLAN im Ruhemodus aktiviert lassen" eingestellt sein. Zu finden in ->Einstellungen -> WLAN ->Kontextmenue -> Erweitert
Weckmechanismus beschrieben unter: http://homematic-forum.de/forum/viewtop … 7&p=219484
-
Ja, Wlan ist bei allen Geräten immer an. Manchmal ist der Status einer Lampe aktuell und manchmal nicht. Da kann ich bis zu einer Minute warten. Dann steht vielleicht kurz " Server nicht erreichbar " und dann gehts. Selbst wenn das Display an bleibt würde nach ein paar Minuten die Reaktion immer langsamer. Und am Tablet kann es eigentlich nicht liegen. Da es auf allen gestesten Geräten ähnlich ist.
Vielleicht komm ich ja noch drauf woran es liegt.
gruß Sebbo
-
Da kann ich bis zu einer Minute warten. ` Ja, ist bei mir ähnlich. Vielleicht eine halbe Minute
@Sebbo:Dann steht vielleicht kurz " Server nicht erreichbar " und dann gehts. ` Das hatte ich bei DashUi häufiger. Bei IoBrober hatte ich das noch nie grundlos. Also bisher nur, wenn ich irgendwas neu gestartet habe. Im Normalbetrieb bleibt selbst mein lahmes Arnova verbunden. Ich habe allerdings immer die Versorgung angeschlossen. So gehen die Tablets nie in den Tiefschlaf, sondern dunkeln nur das Display ab. Nach dem Wecken durch WoLi steht die Verbindung.
Die langsamen Reaktionszeiten habe ich auch, was auch der Auslöser zu diesem Thread war, Und die Sache mit dem Trigger BidCoS-RF:50.PRESS_SHORT (oder bei mir BidCoS-RF:49.PRESS_SHORT) scheint bei mir (noch) nicht zu funktionieren.
-
Moin.
Gibt es hier schon etwas neues?
Habe ebenfalls das Problem das, sobald der Browser (Chrome auf android) in den Hintergrund geht oder das Handy Display kurz aus war (wlan aktiv) vis sehr träge bis gar nicht mehr reagiert…
Gerade bei Handynutzung ist eine dauernder Reload der Seite doch nervig.
Ausserdem ist nicht ersichtlich ob die Daten jetzt korrekt sind oder nicht...
Jemand einen Workaround gefunden?
Bis denne
MrLee
-
Hi ho,
kann ich, mit Safari auf iPad, nicht bestätigen.
Bei mir ist der Viewwechsel in rund 1 Sekunde erledigt - früher war's recht zäh, aber jetzt ist schön.
Gruß,
Eric
-
Moin,
View Wechsel ist auch bei mir perfekt. Nur Update und Steuern von Aktoren ist nach sleep nicht mehr oder ewig langsam gegeben…..
Bis denne
Mr Lee
3449_xiaomi_gateway.png
