Probleme mit Knob Widget und readingsGroup Aktualisierung im FHEMWEB

gero · 03 März 2015, 14:39:57

Hallo,

bei dem Versuch mein Frontend für mein Wandtablet zu verschönern, bin ich auf ein Problem gestossen:

Ich verwende eine readingsGroup, um Temperatur- und Heizungsinformationen im Floorplan darzustellen (siehe Bield unten).
(Der Fehler läßt sich aber auch unabhängig vom Floorplan im FHEMWEB Frontend nachstellen)

Meine readingsGroup ist zur Zeit wie folgt definiert:

Code Auswählen

<%temperature_humidity>,<T>,<Tsoll>,<>,<F>,<H> .*.TF:temperature,desired@{$DEVICE=~s/.TF/.MAX.HT.pid/;$DEVICE;},state@{$DEVICE=~s/.TF/.MAX.HT.pid.proxy/;$DEVICE;},windowicon@{$DEVICE=~s/.TF/.MAX.FK.dummy/;$DEVICE;},humidity

Hier noch die komplette Ausgabe vom list Befehl:

Code Auswählen

Internals: 
   DEF        <%temperature_humidity>,<T>,<Tsoll>,<>,<F>,<H> .*.TF:temperature,desired@{$DEVICE=~s/.TF/.MAX.HT.pid/;$DEVICE;},state@{$DEVICE=~s/.TF/.MAX.HT.pid.proxy/;$DEVICE;},windowicon@{$DEVICE=~s/.TF/.MAX.FK.dummy/;$DEVICE;},humidity 
   NAME       rg_LaCrosse 
   NR         30 
   NTFY_ORDER 50-rg_LaCrosse 
   STATE      Initialized 
   TYPE       readingsGroup 
   mayBeVisible 1 
   CHANGETIME: 
   Content: 
     DB.TF      1 
     DG.BZ.TF   1 
     DG.FL.TF   1 
     DG.KI.JA.TF 1 
     DG.KI.SI.TF 1 
     DG.SZ.TF   1 
     EG.BZ.TF   1 
     EG.GA.TF   1 
     EG.HZ.TF   1 
     EG.KR.TF   1 
     OG.BZ.TF   1 
     OG.EZ.TF   1 
     OG.WZ.TF   1 
   Content2: 
     DG.BZ.MAX.FK.dummy 1 
     DG.BZ.MAX.HT.pid 1 
     DG.BZ.MAX.HT.pid.proxy 1 
     DG.FL.MAX.FK.dummy 1 
     DG.FL.MAX.HT.pid 1 
     DG.FL.MAX.HT.pid.proxy 1 
     DG.KI.JA.MAX.FK.dummy 1 
     DG.KI.JA.MAX.HT.pid 1 
     DG.KI.JA.MAX.HT.pid.proxy 1 
     DG.KI.SI.MAX.FK.dummy 1 
     DG.KI.SI.MAX.HT.pid 1 
     DG.KI.SI.MAX.HT.pid.proxy 1 
     DG.SZ.MAX.FK.dummy 1 
     DG.SZ.MAX.HT.pid 1 
     DG.SZ.MAX.HT.pid.proxy 1 
     OG.BZ.MAX.FK.dummy 1 
     OG.EZ.MAX.FK.dummy 1 
     OG.EZ.MAX.HT.pid 1 
     OG.EZ.MAX.HT.pid.proxy 1 
     OG.WZ.MAX.FK.dummy 1 
     OG.WZ.MAX.HT.pid 1 
     OG.WZ.MAX.HT.pid.proxy 1 
   DEVICES: 
     ARRAY(0x1ef6ec8) 
     ARRAY(0x1b758a8) 
     ARRAY(0x1e41278) 
     ARRAY(0x185b428) 
     ARRAY(0x1ff2f98) 
     ARRAY(0x229ca58) 
     ARRAY(0x1fa0eb0) 
     ARRAY(0x1f91220) 
     ARRAY(0x1ef6a48) 
     ARRAY(0x1b70ef0) 
     ARRAY(0x1f06cd0) 
     ARRAY(0x1b6dd80) 
     ARRAY(0x1fc31b0) 
     ARRAY(0x1efa630) 
   DEVICES2: 
     ARRAY(0x1ef6ec8) 
     ARRAY(0x1efa630) 
     ARRAY(0x1f06cd0) 
     ARRAY(0x1b6dd80) 
     ARRAY(0x1b70ef0) 
     ARRAY(0x1ef6a48) 
     ARRAY(0x1fc31b0) 
     ARRAY(0x1ff2f98) 
     ARRAY(0x1b758a8) 
     ARRAY(0x185b428) 
     ARRAY(0x1e41278) 
     ARRAY(0x1f91220) 
     ARRAY(0x229ca58) 
     ARRAY(0x1fa0eb0) 
     ARRAY(0x1e8d790) 
     ARRAY(0x1e8d880) 
     ARRAY(0x1f91850) 
     ARRAY(0x1b721b8) 
     ARRAY(0x1e80890) 
     ARRAY(0x1f5e638) 
     ARRAY(0x1dacdc8) 
     ARRAY(0x1e80698) 
     ARRAY(0x1f5deb8) 
     ARRAY(0x1f5e650) 
     ARRAY(0x1ef2b40) 
     ARRAY(0x1e83188) 
     ARRAY(0x1dad440) 
     ARRAY(0x1f06ce8) 
     ARRAY(0x745d20) 
     ARRAY(0x1ef2918) 
     ARRAY(0x1bd9d00) 
     ARRAY(0x1f5d990) 
     ARRAY(0x1b726f8) 
     ARRAY(0x1dad098) 
     ARRAY(0x1b72698) 
     ARRAY(0x126b788) 
   Fhem: 
     lastDefChange 11 
     last_update 1425388631.39142 
   Helper: 
     DEF 
     mapping    %ALIAS 
     nameStyle  style="color:yellow;font-weight:bold" 
     valueFormat {rgValueFormat($DEVICE,$READING,$VALUE);} 
     valueStyle {rgValueStyle($DEVICE,$READING,$VALUE);} 
     Commands: 
       battery.low set %DEVICE replaceBatteryForSec 60 
       state      state: 
     Valuecolumn: 
       humidity   5 
       windowicon 4 
     Valueicon: 
       battery.low batterie@red 
       battery.ok batterie@lightgreen 
       onoff.0    fts_window_1w@lightgreen 
       onoff.1    fts_window_1w_open@red 
       state      %devStateIcon 
       windowicon.0 fts_window_1w@lightgreen 
       windowicon.1 fts_window_1w_open@red 
       windowicon.2 fts_window_1w_open@yellow 
Attributes: 
   DbLogExclude .* 
   alias      Klima 
   commands   { "battery.low" => "set %DEVICE replaceBatteryForSec 60", "state" => "state:" } 
   fp_frontend1 29,56,0, 
   fp_frontend_temperatur 20,172,0,, 
   group      Overview 
   mapping    %ALIAS 
   nameStyle  style="color:yellow;font-weight:bold" 
   noheading  1 
   notime     1 
   room       1.00_Temperatur 
   sortDevices 1 
   sortby     0 
   style      class="block wide rg_LaCrosse" 
   valueColumn { windowicon =>4, humidity => 5 } 
   valueFormat {rgValueFormat($DEVICE,$READING,$VALUE);} 
   valueIcon  { state => '%devStateIcon', 'battery.ok' => 'batterie@lightgreen', 'battery.low' => 'batterie@red', 'onoff.0' => 'fts_window_1w@lightgreen', 'onoff.1' => 'fts_window_1w_open@red','windowicon.0' => 'fts_window_1w@lightgreen', 'windowicon.1' => 'fts_window_1w_open@red', 'windowicon.2' => 'fts_window_1w_open@yellow'  } 
   valueStyle {rgValueStyle($DEVICE,$READING,$VALUE);}

Zu jedem PID20 Device gibt es ein readingsProxy mit der Endung MAX.HT.pid.proxy, den ich zum Einstellen der Temperatur verwende. Das devStateIcon zeigt einen Heizkörper, der entsprechend der Ventilöffnung eingefärbt ist. Bei Klich auf dieses Icon, wird ein Popup mit dem Knob Widget dargestellt.

Das ganze hatte wunderbar funktioniert, bis ich im readingsProxy das knob widget eingebaut habe.
Hier ein Beispiel:

Code Auswählen

Internals: 
   DEF        DG.BZ.MAX.HT.pid:desired 
   DEVICE     DG.BZ.MAX.HT.pid 
   NAME       DG.BZ.MAX.HT.pid.proxy 
   NR         365 
   NTFY_ORDER 50-DG.BZ.MAX.HT.pid.proxy 
   READING    desired 
   STATE      19.0 
   TYPE       readingsProxy 
   CHANGETIME: 
   Content: 
     DG.BZ.MAX.HT.pid 1 
   Readings: 
     2015-03-03 08:28:26   lastCmd         20 
     2015-03-03 14:22:00   state           19.0 
Attributes: 
   DbLogExclude .* 
   devStateIcon {devStateHeatingIcon("DG.BZ.MAX.HT.pid")} 
   setFn      {my $temp=sprintf("%.1f",$CMD);fhem("set $DEVICE desired $temp");; return undef} 
   setList    state:knob,min:16,max:25,step:0.5,fgColor:red,anglearc:180,angleoffset:270,bgcolor:blue,width:250,displayPrevious:false,lineCap:round 
   valueFn    {sprintf("%.1f",$VALUE)} 
   webCmd     state

Seit diesem Zeitpunkt wurde der Status der Fenster nicht mehr aktualisiert (longpoll ist aktiv).
Bei der Fehleranalyse ist mir zuerst in der Javascriptconsole des Browser aufgefallen, dass bei einem Update des Fensterstatus die Verbindung zwischen Browser und fhem getrennt wird:

Code Auswählen

 14:17:44.950 Longpoll with filter fp_frontend_temperatur=.%2B;iconPath=frontend_temperatur
fhemweb.js:194 14:17:52.229 Rcvd: 
fhemweb.js:194 14:17:52.229 ERRMSG:Connection lost, trying a reconnect every 5 seconds.<
fhemweb.js:194 14:17:57.130 ERRMSG:<
fhemweb.js:194

Folgende Meldung ist im Logfile zu sehen:

Code Auswählen

Closing connection FHEMWEB:192.168.178.31:48118 due to full buffer in FW_Notify

Das Problem scheint zu sein, dass alle Knob Elemente (auch wenn das Popup nicht sichtbar ist) komplett übertragen werden.
Ich habe zusätzlich in der fhem.pl in der Funktion addToWritebuffer ein paar Ausgaben gemacht:

Code Auswählen

2015.03.03 10:49:55 1: addToWritebuffer full 208584

Den Ausgabe des Inhaltes des Buffers habe ich wieder entfernt, weil das Forum wohl nicht soviel Text verträgt.

Hat vielleicht irgendjemand eine Idee, ob und wie das Problem zu lösen ist?
Ist die Beschränkung des Buffers in der Funktion addToWritebuffer sinnvoll und notwendig?
Kann man das Knob Widget abändern, so dass nur die kompletten Daten übertragen werden, wenn es auch wirklich angezeigt wird?

Gruß,
Gero

gero · 04 März 2015, 14:25:58

Ich habe jetzt testweise die Längenbegrenzung des Buffers in der fhem.pl Funktion addToWritebuffer von 102400 auf 1024000 geändert.
Zur Zeit läuft alles ohne Probleme.

Gruß,
Gero

Dirk · 20 März 2015, 16:04:09

Das kann auf alle Fälle ein Problem sein.
Vor allem Auf "schwächeren" Clients mit wenig Speicher.
Lass das FHEM bei dir mal im Android-Browser eine Weile Laufen und schaue ob das nach ungefähr der selben Zeit nicht mehr Bedienbar ist.
Dann währ das Problem da zu suchen.

Viele Grüße
Dirk

gero · 20 März 2015, 16:14:13

Bis heute läuft mit der Änderung alles völlig problemlos. Mein FHEM läuft ein einem Raspberry B.
Das Megabyte als Sendbuffer scheint er ohne Probleme zu verkraften.

WVC bekommt brav alle Aktualisierungen und es gibt auch keine Disconnects mehr.

Gruß,
Gero

justme1968 · 20 März 2015, 20:04:56

was genau meinst du mit es werden alle knob elemente übertragen?

der js code für den knob ist ganz normal über einen link in der seite eingebettet. er wird nicht über die longpoll verbindung übertragen.

gruß
andre

gero · 20 März 2015, 21:46:43

Ich habe ein paar alte Logs rausgesucht, in denen das Problem zu sehen ist.

addToWrteBuffer_1.log zeigt ein Log auf Verbosity Level 5. mit zusätzlichen Ausgaben in den einzelnen if-else-Zweigen der Funktion addToWriteBuffer. Am Ende wird die Verbindung wegen eines zu vollen WriteBuffers geschlossen.

addToWriteBuffer_2.log lief auf Verbosity Level 3 mit zusätzlicher Ausgabe von Länge und Inhalt der Daten in der Funktion addToWritebuffer.

Zumindest ist in beiden Logs zu sehen, was übertragen wird.

Auf der Gegenseite kann man das Verhalten in der Javascriptconsole sehen.
js_console_out.log ist ein aktueller Mitschnitt meines Systems mit geänderter Buffe-Obergrenze in der fhem.pl. Daher gibt es keinen Verbindungsabbruch. Die Zahlen in Klammern am Ende von nicht vollständigen Zeilen, geben die Anzahl der nich angezeigten Bytes aus.

Gruß,
Gero

justme1968 · 20 März 2015, 22:48:56

das was in den logs auftaucht sind die svg icons die zum browser übertragen werden. das ist das einzige das tatsächlich gross ist und es hat nichts mit dem knob zu tun.

vielleicht gibt es durch den knob einen indirekten effekt wodurch der browser die daten nicht mehr schnell genug ausliest und deshalb auf fhem seite der buffer voll läuft. das popup mit der referenz auf den knob selber sind aber jeweils < 300 byte.

die icons die du verwendest sind deutlich größer (10-13k pro icon) als die 'einfachen' svg icons (1-3k pro icon). d.h. mit deinen 13 devices und 10k pro icon ist der writeBuffer alleine durch die icons komplett voll. wenn es im browser kleine verzögerungen beim auslesen gibt reicht das vermutlich schon um das problem zu triggern.

es gibt irgendwo einen thread bei dem es um probleme mit dem write buffer ging.

vermutlich wäre es unabhängig davon sinnvoll die sani_heating_level_.* icons mal durch einen svg optimizer zu schicken. über 10k pro icon ist eindeutig zu viel für so etwas einfaches.

gruss
andre

gero · 20 März 2015, 22:58:27

Danke für die Analyse.
Da habe ich den knobs wohl voreilig die Schuld gegeben. Wobei die knobs schon einen Einfluß auf das Verhalten haben müssen, da es ohne die Knobs keine Probleme gibt.
Ich werde nochmal testen, ob ich mit etwas optimierteren SVG-Icons auch mit der Bufferbeschränkung von 102400 Byte leben kann. Trotzdem halte ich diese Schranke für etwas zu niedrig angesetzt (selbst auf kleinen Systemen).

Gruß,
Gero