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

[herrmannj]

Hi,

passiert das mit set cmd = 'state' mit allen convertern ? Kann mir grad keinen Reim drauf machen und ja, das war mal besser

Beim cache Vorsicht bitte: der cache in den sv Einstellungen hat nichts mit dem dom zu tun. Da wird einfach das (compilierte) Ergebnis von den twig templates in sv (im dir sv/temp/) zwischengespeichert. Sprich: hat keinen Effekt auf den Inhalt von dom.

Data-ajax=false wiederum hat einen Effekt auf den Inhalt vom Dom (wird größer). Der driver geht zwar nur über $.mobile.activepage, wird aber vmtl langsamer aktualisieren weil der dom insgesamt umfangreicher ist.

Das mit dem reconnect ist natürlcih nur ein hack, lass uns das schnell wieder wegmachen, das war schon beim wvc so ein Graus

Trotzdem ist da was nicht koscher: soweit ich das sehe geht der driver in line 215 auch bei reconnect über "monitor". Monitor sorgt automatisch dafür das fronthem alle GAD an sv sendet (um genau die Lücke zwischen dis und reconnect zu schliessen).

Teil 2 der nicht koscher ist: das mit dem cache (im Zusammenhang mit reconnect bei Dir). Der cache (wenn wir hier über den selben sprechen) ist nur Serverseitig (!) nicht im client. Ergo kann der keinen Einfluss auf die Inhalte (in den widgets) haben - ich denk mal da klemmt was anderes.

Über welche menge GAD sprechen wir (Summe über alle Seiten ?). Magst Du mal bitte testen ob sich der domotiga driver da gleich verhält (logisch ohne den re-connect Teil).

Danke und Grüße
Jörg

[marvin78]

Ich konnte es bei Direct und OnOff feststellen. Die anderen habe ich nicht getestet und dazu komme ich auch nicht so schnell. Es ist aber definitiv so reproduzierbar.

Der Twig-Cache hat ohnehin kaum Auswirkungen, von dem spreche ich nicht. Ich rede vom jQuery-Mobile DOM-Cache (den ich mir mitlerweile auskommentiert habe). Es ist logisch, dass die Aktualisierung der gads langsamer wird, wenn die Elemente im DOM in ihrer Zahl wachsen. Da ist es (fast) egal, ob der Driver nur über mobile.activepage geht. Der Treiber hat immer mehr "Mühe", die Elemente zu finden und dann ist es auf einmal nicht mehr egal, wie wieviele Elemente man insgesamt auf seinen Pages hat (ich spreche hier nicht von gads).

Was die nicht Aktualisierung von Widgets nach einem reconnect angeht kann ich nur Beobachtungen schildern. Hier habe ich mir den Driver nicht näher ansehen können. Ich verweile mit dem Tablet auf einer Statusseite. Dieses wird etwa 3 Stunden nicht durch Bewegung aktiviert und wenn man dann wieder davor steht, wird tatsächlich die aktuelle Seite mit allen gads aktualisiert (langsam aber sicher). Geht man mit dem Zurückbutton oder aber auch mit einem Link auf eine data-ajax=true Seite und hat den DOM-Cache an, passiert es, dass auf der aufgerufenen Seite (die man vor den 3 Stunden Pause schon einmal aufgerufen hatte) nicht alle gads aktuell sind (und auch nicht aktualisiert werden, wenn sie nicht tatsächlich einen neuen Wert erhalten - sie haben den Wert vor der Pause und nicht den, der aktuell anliegt). Besser kann ich das kaum beschreiben. Hat man data-ajax auf false und den DOM Cache aus, passiert das logischerweise nicht. Dann sieht man zwar, wie sich langsam die gads aufbauen aber das geht dann recht schnell, sodass flüssiges Arbeiten möglich ist (dank des Treibers der nicht mehr blockt).

[ftobi]

Hallo,

mit dem aktuellen Treiber hab ich das Verhalten aus dem angehängten Video. Also alle Änderungen, seit das Tablet zugeklappt wurde, werden im Zeitraffer "nachgereicht". Könnte man jetzt als Feature bezeichnen, ist aber glaube ich nicht so gedacht
Tritt bei mir nur mit Chrome auf Android 4.4 auf. Das Tablet bleibt als fronthemDevice in FHEM auch auf connected stehen.
Mit dem Domotiga-Treiber ist alles gut.

Bitte auch wieder nicht als zu lösendes Problem meinerseits behandeln, eher als Report an die Devs, die hier großartiges leisten.

Grüße
Tobi

Edith: die Originalwerte kommen mit einer Frequenz von ca. 15-20 Sekunden

[herrmannj]

Hi ftobi,

im Prinzip richtig, allerdings sollte das Verhalten bei dem domotiga und dem fhem treiber gleich sein. Wenn das Tablett sich nicht bei fronthem abmeldet (weil zugeklappt) ist für fronthem nicht zu unterscheiden ob das willentlich geschieht (Deckel) oder ob bspw WLAN unterbrochen ist (weil Störung, zu weit weg und so etwas). Daher sammelt es brav die Events für das device und wenn das device sich auf der gleichen (das macht Deins, das ist der Unterschied) Verbindung wieder meldet bekommt es alles das was es verpasst hat.

Da scheint der fhem driver noch Macken zu haben, Danke für den Report. Das Verhalten in bezug auf disconnect soll identisch zum domotiga sein.

@marvin

ich kann den Effekt nicht nachvollziehen. Es wäre schön wenn Du das strukturiert untersuchst. Am PC kannst Du bei aktivierter console (im browser) genau sehen was der driver macht, dann sehen wir auch wo die events verloren gehen (sich überholen)

vielen Dank, vg
jörg

[bgewehr]

@Jörg: hast Du meinen PR im Fronthem Git mitbekommen bzgl. Schnellsuche im GAD-Editor? Ich nutze das nun schon einige Tage und finde es eine große Hilfe...

[marvin78]

@marvin

ich kann den Effekt nicht nachvollziehen. Es wäre schön wenn Du das strukturiert untersuchst. Am PC kannst Du bei aktivierter console (im browser) genau sehen was der driver macht, dann sehen wir auch wo die events verloren gehen (sich überholen)

Ja das sehe ich. es hat bloß nicht immer mit dem zu tun, was auf dem Bildschirm tatsächlich stattfindet. Zudem habe ich den Effekt nicht am PC. Die Console gibt es aber am Tablet nicht. Ich habe mir beispielsweise eine Javascript-Funktion gebaut, die mir bestimmte Werte einfärbt. Es kommt nun vor, dass das einfärben tatsächlich funktioniert der Wert aber als --- dargestellt wird.

Das ist aber auch nicht das wirklich wichtige an meinem Beitrag. Wichtiger ist die Sache mit dem state.

[herrmannj]

@Jörg: hast Du meinen PR im Fronthem Git mitbekommen bzgl. Schnellsuche im GAD-Editor? Ich nutze das nun schon einige Tage und finde es eine große Hilfe...

Ja hab ich, sorry wollt Dich da auch schon callen. Bin im Augenblick unterwegs und wollt mir das anschauen bevor ich das übernehme weil es doch recht zentral ist - ich komm erst am we dazu.

btw: den fronthemUtils habe ich übernommen, würde aber vorschlagen das "use json" aus dem namespace fhconverter raus zunehmen.  Ohne das getestet zu haben: die ganzen Routinen aus dem JSON package müssten jetzt bei Dir als converter erscheinen (im autocomplete) weil die damit in dem namespace liegen. (richtig ?)

Wenn ja: besser oben im main importieren und aus dem converter einen call nach main::was_auch_immer. In "was_auch_immer" müsste dann das JSON decode stattfinden und als return durchgereicht werden.

vg
jörg

[herrmannj]

Das ist aber auch nicht das wirklich wichtige an meinem Beitrag. Wichtiger ist die Sache mit dem state.

Yepp, ich hab mir das gestern am code angeschaut aber keine naheliegende Erklärung gefunden. Muss ich mir leider auch am we am lebenden objekt anschauen, mach ich heil.

Zu dem driver, wenn das einfärben klappt der Wert aber nicht gesetzt wird, dann kommt er ja in sv an, liegt vielleicht außerhalb des drivers ? Müsstest Du selber einmal jagen, bitte.

vg
jörg

[bgewehr]

1) Ja hab ich, sorry wollt Dich da auch schon callen. Bin im Augenblick unterwegs und wollt mir das anschauen bevor ich das übernehme weil es doch recht zentral ist - ich komm erst am we dazu.

2)  Ohne das getestet zu haben: die ganzen Routinen aus dem JSON package müssten jetzt bei Dir als converter erscheinen (im autocomplete) weil die damit in dem namespace liegen. (richtig ?)

3) Wenn ja: besser oben im main importieren und aus dem converter einen call nach main::was_auch_immer. In "was_auch_immer" müsste dann das JSON decode stattfinden und als return durchgereicht werden.

1) ok, bin gespannt, was Du dazu sagst
2) stimmt, das stört!
3) schaue ich mir an!

gute Reise!


Gesendet von meinem iPad mit Tapatalk

[HCS]

Ich lese so nebenbei mit,bin aber erst am WE wieder in der Lage, mir das genauer anzuschauen. Bis da hin bitte etwas Geduld und am Besten experimentierten und Infos sammeln.

[bgewehr]

@Jörg: meinst Du sowas:

Code Auswählen Erweitern


package main;

use JSON;

sub decodejson($) {
  return decode_json(@_);
} 


was dann hier verwendet wird:

Code Auswählen Erweitern


package fronthem;

{
    $param->{gad} = $gad;
$param->{gadval} = main::decodejson(main::ReadingsVal($device, $reading, ''));
$param->{gads} = [];
    return undef;
  }


Klappt irgendwie noch nicht so richtig...

[herrmannj]

das sieht soweit gut aus. Versuch mal aus

Code Auswählen Erweitern


sub decodejson($) {
  return decode_json(@_);
} 

das:

Code Auswählen Erweitern

sub decodejson($) {
  return decode_json($_[0]);
} 

Und vielleicht einen längeren sub Namen (zB myfhutils_decodejson) um Konflikte mit anderen Modulen zu vermeiden. (Das ist der gleiche namespace in dem all fhem, alle module und alle helper sind).

Btw, teste auch mal Umlaute. Das issue mit den UTF8 Umlauten lag in der Verwendung von to_JSON vs. encode_JSON. Abhängig davon wie der input ist (shit komplex - da gehts um utf8 Charakterstream vs UTF8 bytestream, ich geh nicht weiter ins detail) konvertiert jeweils einer von beiden falsch, bzw fhem stürzt komplett ab. Insgesamt hab e ich festgestellt ist es daher eine gute Idee das xxxJSON in ein eval zu packen.

vg
jörg

[bgewehr]

Code Auswählen Erweitern

sub decodejson($) {
  return decode_json($_[0]);
} 

Btw, teste auch mal Umlaute.

So, das funktioniert nun korrekt!
https://github.com/bgewehr/fronthem-1/commit/dbc3f54ddee3ff0416076d97546e14728d5c74c6#diff-46b6826e5550b920b097b5caf2de66e9R42

Umlaute:
Scheint bei mir zu gehen, ich muss noch einen Härtefall generieren... ü ist schon mal richtig...

[Pythonf]

Wäre es möglich eine Funktion im FronthemDevice zu implementieren, die alle nicht gesetzten GADs in FHEM zu diesem Zeitpunkt löscht oder gibt es die eventuell schon?
Quasi für den Fall, dass man eine andere Page in SV aufgerufen hat, aber den Treiber in FHEM nicht deaktiviert hat.
Oder gibt es einen einfachen Weg die GADs zu löschen?

Beste Grüße
Fabian

[herrmannj]

So, das funktioniert nun korrekt!
https://github.com/bgewehr/fronthem-1/commit/dbc3f54ddee3ff0416076d97546e14728d5c74c6#diff-46b6826e5550b920b097b5caf2de66e9R42

Umlaute:
Scheint bei mir zu gehen, ich muss noch einen Härtefall generieren... ü ist schon mal richtig...

oh schön. (Aus dem Kopf) müsste "decode" an der Stelle auch richtig sein.

vg
jörg