erste beta - fronthem, smartVISU (closed, Bitte die Anschlussthreads benutzen)

[kennymc.c]

Ich hab ein Probleme mit einem einfachen Switch. Der ist ganz normal mit reading:state, converter:OnOff und cmd set: state definiert. Allerdings wird dieser im SV immer wieder auf On gesetzt, sobald man ihn ausschaltet. In Fhem bleibt er auf off. Im Log sieht man, dass Fronthem direkt nachdem Ausschalten wieder eine State-Änderung an SV schickt, die er irgendwoher bekommen hat.

Code Auswählen Erweitern

ipc Fronthem:127.0.0.1:33186 (ws): receive {"log":{"level":4,"cmd":"log","text":"ws send to client{\"cmd\":\"item\",\"items\":[\"IT_Deckenfluter_sw\",\"1\"]}"}}
ipc Fronthem:127.0.0.1:33186 (ws): ws send to client{"cmd":"item","items":["IT_Deckenfluter_sw","1"]}
Mit toggle als cmd set kann man ihn zumindest über SV normal schalten aber der state wird trotzdem wieder zurück gesetzt. Woran kann das liegen?
Hab auch schon versucht beim Schalter den gesendeten Wert direkt auf On/Off zu ändern und dann in Fhem auf Direct zu stellen, aber dann ist der Effekt genau das Gegenteil wie vorher und der Schalter wird immer wieder auf off zurückgesetzt.

Leider hab ich auch noch sehr oft das Problem, dass die GAD-Listen nicht in den Device-Details zu sehen sind. Erst nach einem Fhem-Neustart tauchen sie wieder auf.

[herrmannj]

Das was zurückkommt ist normal und gewollt.

Der Effekt ist: sv setzt den (fhem) Schalter - der setzt ein event ab und das Event triggert den sv Schalter.
Hast Du ein mapping am Schalter gesetzt oder etwas in der Art ? Welche Version von fronthem ?

vg
jörg

[bgewehr]

@kenny poste mal den Switch code {{ ... }}

[HCS]

@herrmannj: auch wenn es nun einen GAD-Filter auf Treiberseite gibt, wäre es praktisch, wenn man das auch der fronthem-Seite hätte. Also einfach ein Attribut, in dem man eine regex definieren kann, die die mit "monitor" geschickten GADs filtert.
Wäre das kurzfristig machbar?
Ich könnte das gut für die Treiber-Experimente brauchen, da einige Test-Treiber-Varianten nicht filtern und ich so die unerwünschten GADs von fronthem fernhalten könnte.

Ich baue gerade einen Test-Treiber, der den Zeitverlauf der einzelnen Schritte beim Laden einer page anzeigt (auch auf Telefonen und Tablets)
Damit können wir dann mal schauen, wo auf verschieden Systemen der Hirsch im Wald seine Zeit vertödelt und gezielt das Feuer eröffnen. 

[herrmannj]

ja ich wollte da auch nachher noch bei, muss mich aber vorher um andere Sachen kümmern.

Mein Idee wäre das ich zum testen was einbaue wo 300 (1000?) GAD künstlich in fronthem erzeugt werden. Die wollte ich mit dem timestamp ihrer Geburts füttern.

In sv könntte man den timestamp wann sie abgeholt werden ergänzen und beides in basic value darstellen. Wenn wir Dein System nehmen (mit den vom script erzeugten GAD) könnte man die rauskopieren und mit eine calc auswerten.

Ansonsten sollten wir noch die lifecycle events des DOM und von query in die console geben - dann hätten wir doch schon mal eine Anfang ?

vg
jörg

[HCS]

OK, mit meinem "Mess-Treiber" und dem was Du beschreibst haben wir dann zwei Tests, die verschiedene interessante Daten liefern sollten.

Was mir aus Deiner Antwort nun nicht klar wurde: bekomme ich den regex Filter auf fronthem-Seite oder nicht?

[herrmannj]

Ich dachte Du brauchst das zum testen und das wäre damit erledigt ?

Was genau meinst Du mit fernhalten ? Der Aufbau der cfg und das beantworten sind unterschiedliche Dinge und passieren an unterschiedlichen Stellen

vg
jörg

[kennymc.c]

@kenny poste mal den Switch code {{ ... }}

Code Auswählen Erweitern

{{ basic.switch('IT_Deckenfluter', 'IT_Deckenfluter_sw', icon1~'light_light_dim_100.png', icon0~'light_light_dim_00.png') }}

Hast Du ein mapping am Schalter gesetzt oder etwas in der Art ? Welche Version von fronthem ?

Ich hab per EventMap on auf Ein und off auf Aus gemappt. Hab es jetzt Testweise rausgenommen un nun funktioniert es wie es soll.

[HCS]

Ich dachte Du brauchst das zum testen und das wäre damit erledigt ?

Was genau meinst Du mit fernhalten ? Der Aufbau der cfg und das beantworten sind unterschiedliche Dinge und passieren an unterschiedlichen Stellen

Kann ich immer noch gebrauchen, genau wie die sortierten GADs in der fhserver.fronthem.cfg
Ich habe reichlich GADs in SV, die ich in FHEM auf keinen Fall haben will. Das sind die Test-GADs und alle GADs, die mein addon driver erledigt.
Die filtert üblicherweise mein driver aus.
Wenn ich aber zum Testen mal den Domotiga oder einen meiner Test-driver verwende, dann sind die GADs drüben in FHEM und da wird man sie nur sehr mühsam wieder los.

Mit fernhalten meine ich folgendes: der driver schickt zu Begin mit "monitor" die Liste der GADs, die fronthem liefern soll. Die kommen bei Dir irgendwo rein, vermutlich hier wohl: fronthemDevice_fromDriver
if ($msg->{message}->{cmd} eq 'monitor')
Wenn man nun ein attribut definieren könnte, das eine regex enthält, die die GADs, die du in $msg->{message}->{items} hast, direkt mal filtert, bevor irgend etwas weiter damit gemacht wird, könnte man festlegen, welche GADs in fronthem völlig ignoriert werden sollen.

Betrachte es als ein Art spam-filter für fronthem


Speed-Test:
Ich habe den test-driver mal erste Messungen machen lassen. Siehe angehängte screenshots. Einmal auf dem Laptop und einmal auf dem Telefon (Nexus 5)
Die Zahlen (Nexus) sind so zu lesen:
driver init: SV hat den driver initialisiert
driver run: SV hat den driver gestartet, der früheste Zeitpunkt etwas zu tun.
monitor sent: es wurde das "monitor" command an fronthem gesendet und in diesem Fall 300 GADs angefordert.
first GAD received: das erste der 300 GADs wude von fronthem geliefert aber noch nicht in SV verarbeitet
first GAD handled: das GAD wurde verarbeitet, bedeutet, der Wert wird in SV angezeigt
50 GADs handled: es wurden 50 GADs von fronthem gesendet und in SV verarbeitet und angezeigt

Erkenntnisse (bezogen auf das Nexus 5):
die ersten 330ms gehen drauf, bis die GAD-Liste mit monitor bei fronthem abgeliefert ist
19 ms um das erste GAD zu verarbeiten. Das ist die Zeit, die der driver braucht, um es, nachdem er es von fronthem erhalten hat, in SV den Wert anziegen zu lassen
800ms für die 50 GADs von fronthem aus zu übertragen und in SV zu verarbeiten, dass sie angezeigt werden.
Das sind rund 16ms pro GAD.
Ab dem Moment, ab dem der driver überhaupt ins Spiel kommt, sind das 1,3 Sekunden, um 50 GADs anzuzeigen.

Das Laptop ist natürlich um Welten schneller.

Ich werde den test-driver noch etwas überarbeiten und dann in den nächsten Tagen zur Verfügung stellen, dann können auch ander Anwender mal Zeiten ermitteln, dass wir sehen, wo die langsamen Systeme die Zeit lassen.

[HCS]

@karl0123: hast Du in deiner menu.html in den links

Code Auswählen Erweitern

<a class="ui-btn ui-corner-all" id="menu-overview" data-ajax="false" href="index.php?page=page_overview">
data-ajax="true" oder data-ajax="false" ?

[herrmannj]

Ich habe gerade einige Messungen zum Thema timing gemacht.

Ergebnis auf einem schon etwas betagteren Notebook:

Das erzeugen der GAD in fronthem benötigt etwa 4ms, die Übertragung benötigt recht konstant 25ms das aktualisieren des widgets von smartVisu knapp 100ms.

Die Folge ist das bei sehr hoher GAD Anzahl der nächste Wert vorliegt wenn ein Widget aktualisiert wurde und sofort in den event handler gesprungen wird ohne das die Jquery UI Zeit hat auf user Input zu reagieren.

Das liegt im Design von smartVisu (in Teilen Jquery). Mit einer queue lässt sich das tatsächlich nicht abfedern. Ich teste in Kürze einige Alternativen (fifo mit Timeout), denke das wird funktionieren.

Zum cache ist mir noch aufgefallen: karl spricht vom DOM Cache, das mag den einen oder anderen vielleicht verleiten den Button Cache in der sv config Seite abzuschalten. Der steuert jedoch den twig cache und sollte im produktiven Betrieb tunlichst angeschaltet bleiben (bringt deutlich speed). Der DOM Cache, auf der anderen Hand, ist ein spezielles jquery feature das im source von smartVisu gesteuert wird, ob das dort per default enabled kann ich nicht sagen, habs nicht untersucht. Wenn ja macht es sicher Sinn das abzuschalten, da müsste Karl noch mal sagen wo er das abgeschaltet hat.

vg
jörg

[chris1284]

ich habe ein komisches problem wenn ich den Pagecache aktiviere... ich hatte ihn vor einiger zeit mal kurz an, dann wieder aus.
aktiviere ich den Pagecache nun erneut wird in uraltes design angezeigt. egal was ich mache (windos temp leeren, firefox cache leeren, refreshen ...) es änder sich nicht auf das aktuelle. wo kannich noch ansetzen?

EDIT: www/smartvisu/temp löschen... könnt ihr dafür ein script einbauen das zu machen? evtl in smartvisu einstellungen einen punkt "clear cache" 
winscp  um auf dem server den cache zu leeren ist eine sehr schlechte lösung wenn man nicht am rechner sondern zb am handy/tablet sitzt...

[bgewehr]

Mir ist noch folgendes aufgefallen: wenn ich auf iOS SV als Web-App benutze, dann wird beim Aufruf der App immer die Index Seite neu geladen. Das dauert so etwa 3-5s, ebenso wie alle weiteren Seiten, wenn sie das erste Mal geladen werden. Danach kann ich fast ohne Verzögerung zwischen den Seiten wechseln, kein Kringel, keine Ladezeit. Warum kann man eigentlich zu einer Web-App nicht hinwechseln, ohne dass sie neu geladen wird?

[herrmannj]

ich habe ein komisches problem wenn ich den Pagecache aktiviere... ich hatte ihn vor einiger zeit mal kurz an, dann wieder aus.
aktiviere ich den Pagecache nun erneut wird in uraltes design angezeigt. egal was ich mache (windos temp leeren, firefox cache leeren, refreshen ...) es änder sich nicht auf das aktuelle. wo kannich noch ansetzen?

EDIT: www/smartvisu/temp löschen... könnt ihr dafür ein script einbauen das zu machen? evtl in smartvisu einstellungen einen punkt "clear cache" 
winscp  um auf dem server den cache zu leeren ist eine sehr schlechte lösung wenn man nicht am rechner sondern zb am handy/tablet sitzt...

Der Cache muss nur gelehrt werden wenn man die Seiten-Programmierung verändert.

vg
jörg

[herrmannj]

Mir ist noch folgendes aufgefallen: wenn ich auf iOS SV als Web-App benutze, dann wird beim Aufruf der App immer die Index Seite neu geladen. Das dauert so etwa 3-5s, ebenso wie alle weiteren Seiten, wenn sie das erste Mal geladen werden. Danach kann ich fast ohne Verzögerung zwischen den Seiten wechseln, kein Kringel, keine Ladezeit. Warum kann man eigentlich zu einer Web-App nicht hinwechseln, ohne dass sie neu geladen wird?

So funktionieren Webapps, die Seite wird wie im browser geladen. Für alles andere brächte man eine app in der Seiten lokal vorgehalten werden - plus: - jquery mobile ist langsam und muss die Seite initialisieren.

vg
jörg