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:
<%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:
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:
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:
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:
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:
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
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
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
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
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
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
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
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