Ich habe ein Problem, was ich mir nicht erklären kann. Über MQTT kommen von einem Sensor mehrere Daten in einem Event-Block an, diese werden in di_counter_new verarbeitet, es werden dort paar Readings geschrieben, auf die ein weiteres DOIF di_energie die passenden Daten für Visualisierung aufbereitet. Das Empfangen der Daten mit der dazugehörigen Verarbeitung führt bereits zum Verbindungsverlust zum Webserver mit der berüchtigten Fehlermeldung "connection lost ..."
Hier ein Auszug mit apptime
name function max count total average maxDly avgDly TS Max call param Max call
CUL CUL_Read 1186 241 48216.52 200.07 0.00 0.00 24.03. 18:00:13 HASH(CUL)
MQTT2_FHEM_Server_192.168.178.141_52669 MQTT2_SERVER_Read 638 1193 100571.22 84.30 0.00 0.00 24.03. 19:16:31 HASH(MQTT2_FHEM_Server_192.168.178.141_52669)
tmr-__ANON__ HASH(0x5db15a8) 523 300 95630.63 318.77 0.00 0.00 24.03. 18:04:31 HASH(MQTT2_FHEM_Server_192.168.178.141_52669)
di_counter_new DOIF_Notify 484 3213 167227.06 52.05 0.00 0.00 24.03. 18:04:31 HASH(di_counter_new); HASH(MQTT2_DVES_C58DCB)
HMLAN HMLAN_Read 437 3775 66525.77 17.62 0.00 0.00 24.03. 22:57:39 HASH(HMLAN)
MQTT2_FHEM_Server_192.168.178.130_52752 MQTT2_SERVER_Read 405 7330 196193.16 26.77 0.00 0.00 24.03. 19:01:00 HASH(MQTT2_FHEM_Server_192.168.178.130_52752)
tmr-CUL_HM_procQs CUL_HM_procQs 399 11 1947.14 177.01 4.18 1.39 24.03. 18:38:09 CUL_HM_procQs
sigduino CODE(0x5612348) 344 2054 11311.20 5.51 0.00 0.00 24.03. 18:50:25 HASH(sigduino)
tmr-__ANON__ HASH(0x2ea9eb0) 331 3864 33015.36 8.54 0.00 0.00 24.03. 18:04:46 HASH(MQTT2_FHEM_Server_192.168.178.130_52752)
tmr-DOIF_SleepTrigger HASH(0x32cd360) 314 2 431.99 215.99 2.25 1.40 24.03. 22:01:32 HASH(di_Zirkulation)
tmr-CUL_HM_motionCheck HM_36152C_Motion 290 19 839.52 44.19 33.92 3.84 24.03. 22:43:32 HM_36152C_Motion:motionCheck
di_temp_hum DOIF_Notify 277 73 8762.65 120.04 0.00 0.00 24.03. 18:41:32 HASH(di_temp_hum); HASH(Aussensensor)
tmr-ESPEasy_statusRequest HASH(0x5544528) 243 59 1888.20 32.00 297.27 14.44 24.03. 19:08:05 HASH(ESPEasy_Eingang_CO2)
di_energie DOIF_Notify 243 2425 102312.02 42.19 0.00 0.00 24.03. 18:06:31 HASH(di_energie); HASH(di_counter_new)
tmr-DOIF_SleepTrigger HASH(0x3b5eb58) 224 2 431.68 215.84 1.11 1.02 24.03. 20:53:15 HASH(di_Flur)
tmr-CUL_HM_ActCheck ActionDetector 218 30 461.91 15.40 42.20 2.92 24.03. 18:07:26 ActionDetector
Alarm_ausloesen DOIF_Notify 216 14 219.38 15.67 0.00 0.00 24.03. 22:42:20 HASH(Alarm_ausloesen); HASH(Schloss)
Alarm_LED CUL_HM_Set 214 12 220.49 18.37 0.00 0.00 24.03. 22:42:20 HASH(Alarm_LED); Alarm_LED; on
di_Wetter DOIF_Notify 213 73 8654.20 118.55 0.00 0.00 24.03. 18:07:37 HASH(di_Wetter); HASH(Wetter)
Garage_Schalter CUL_HM_Set 209 15 415.05 27.67 0.00 0.00 24.03. 20:53:15 HASH(Garage_Schalter); Garage_Schalter; on-for-
Die betroffenen Module mit ihren maximalen Verarbeitungszeiten sind :
MQTT2_FHEM_Server_192.168.178.141_52669 MQTT2_SERVER_Read 638
di_counter_new DOIF_Notify 484
di_energie DOIF_Notify 243
di_energie macht die Aufbereitung für die card-Darstellung. Vier Readings aus einem Eventblock aufzubereiten scheint gerade noch zu funktionieren, wenn ich eine weitere card hinzunehme kommt es bereits zum Abbruch der Verbindung - warum?
Die maximale Verarbeitung dauert dort gerade 243 Millisekunden, das kann doch nicht das Problem sein.
Das apptime Output suggeriert, dass Du die Ursache von "Connetion lost" in Blockieren von FHEM vermutest.
Das ist nicht per se der Fall, ein { sleep(60) } alleine fuehrt nicht zu der "Connection lost" Meldung (gerade getestet), selbst ein FHEMWEB-Schalter, was ich waehrend des sleeps gedrueckt habe, wurde nach dem Ende des sleeps umgestellt.
Ich habe auch in der "44 DOIF-Cards" Testkonfiguration mit {sleep(60)} keine Probleme gesehen, allerdings sind das eher tote DOIF-Cards.
Steht in der JavaScript-Console was ungewoehnliches?
Danke für´s Feedback.
Ich konnte mir das auch nicht vorstellen.
Ich habe auch zig cards bei mir ohne Probleme laufen.
Zuvor hatte ich die gleichen cards über mehrere MQTT-Devices bedient ohne Probleme, nachdem ich die Sensoren über Tasmota auf ein Gerät umgestellt habe (siehe https://forum.fhem.de/index.php/topic,97959.msg1214276.html#msg1214276), kamen auch die Probleme.
Ich habe mir eingebildet, dass es damit zu tun hat, dass statt zeitlich verteilter Events über mehrere MQTT-Devices, jetzt alle auf einmal kommen.
Die Meldung kommt auch dann, wenn die cards gar nicht angezeigt werden.
Wenn ich zuhause bin, werde ich mir die Sache auf der JavaScript-Console genauer anschauen.
Hier ein Auszug aus der javascript console:
15:03:24.784 Rcvd: ["#FHEMWEB:WEBHOME","doifUpdateCell('di_vaillant','doifId','di_vaillant_uiTable_c_2_1_0_0','<svg xmlns=\u0022http://www.w3.org/2000/...(12645)
fhemweb.js:572 15:03:29.800 Rcvd: ["#FHEMWEB:WEBHOME","doifUpdateCell('Aktuell','doifId','Aktuell_uiTable_c_2_0_0_0','<svg xmlns=\u0022http://www.w3.org/2000/svg\u002...(17296)
fhemweb.js:572 15:03:29.801 Rcvd: ["#FHEMWEB:WEBHOME","doifUpdateCell('di_auriol','doifId','di_auriol_uiTable_c_0_1_0_0','<svg xmlns=\u0022http://www.w3.org/2000/svg\...(17813)
fhemweb.js:572 15:03:34.285 ERRMSG:Connection lost, trying a reconnect every 5 seconds.<
fhemweb.js:572 15:03:39.194 ERRMSG:<
fhemweb.js:572 15:03:39.290 Inform-channel opened (HTTP) with filter room=CUL%5fEM
fhemweb.js:572 15:03:39.341 Rcvd: ["di_counter_new","initialized","<div id=\u0022di_counter_new\u0022 title=\u0022initialized\u0022 class=\u0022col2\u0022>initialize...(141)
fhemweb.js:572 15:03:39.342 Rcvd: ["MQTT2_DVES_C58DCB","???","<div id=\u0022MQTT2_DVES_C58DCB\u0022 title=\u0022???\u0022 class=\u0022col2\u0022>???</div>"]
fhemweb.js:572 15:03:52.751 Rcvd: ["#FHEMWEB:WEBHOME","doifUpdateCell('Aktuell','doifId','Aktuell_uiTable_c_3_0_0_0','<svg xmlns=\u0022http://www.w3.org/2000/svg\u002...(17331)
fhemweb.js:572 15:03:52.752 Rcvd: ["#FHEMWEB:WEBHOME","doifUpdateCell('di_icon_bar_bsp','doifId','di_icon_bar_bsp_uiTable_c_0_1_0_0','<svg xmlns=\u0022http://www.w3.o...(9038)
fhemweb.js:572 15:03:52.752 Rcvd: ["#FHEMWEB:WEBHOME","doifUpdateCell('di_icon_svg','doifId','di_icon_svg_uiTable_c_1_3_0_0','<svg xmlns=\u0022http://www.w3.org/2000/...(9030)
fhemweb.js:572 15:03:52.753 Rcvd: ["#FHEMWEB:WEBHOME","doifUpdateCell('di_icon_svg','doifId','di_icon_svg_uiTable_c_0_3_0_0','<svg xmlns=\u0022http://www.w3.org/2000/...(8443)
fhemweb.js:572 15:04:10.436 Rcvd: ["#FHEMWEB:WEBHOME","doifUpdateCell('di_icon_bar_bsp','doifId','di_icon_bar_bsp_uiTable_c_0_3_0_0','<svg xmlns=\u0022http://www.w3.o...(5272)
fhemweb.js:572 15:04:10.437 Rcvd: ["#FHEMWEB:WEBHOME","doifUpdateCell('di_icon_ring','doifId','di_icon_ring_uiTable_c_1_1_0_0','<svg xmlns=\u0022http://www.w3.org/200...(5524)
fhemweb.js:572 15:04:10.491 Rcvd: ["#FHEMWEB:WEBHOME","doifUpdateCell('di_vaillant','doifId','di_vaillant_uiTable_c_3_0_0_0','<svg xmlns=\u0022http://www.w3.org/2000/...(12184)
fhemweb.js:572 15:04:14.583 Rcvd: ["#FHEMWEB:WEBHOME","doifUpdateCell('Klima','doifId','Klima_uiTable_c_0_0_0_0','<svg xmlns=\u0022http://www.w3.org/2000/svg\u0022 vi...(6500)
fhemweb.js:572 15:04:14.584 Rcvd: ["#FHEMWEB:WEBHOME","doifUpdateCell('Klima','doifId','Klima_uiTable_c_0_1_0_0','<svg xmlns=\u0022http://www.w3.org/2000/svg\u0022 vi...(4939)
fhemweb.js:572 15:04:14.636 Rcvd: ["#FHEMWEB:WEBHOME","doifUpdateCell('di_Heizung_temp','doifId','di_Heizung_temp_uiTable_c_0_2_0_0','<svg xmlns=\u0022http://www.w3.o...(4662)
fhemweb.js:572 15:04:14.638 Rcvd: ["#FHEMWEB:WEBHOME","doifUpdateCell('di_temp_ring','doifId','di_temp_ring_uiTable_c_1_1_0_0','<svg xmlns=\u0022http://www.w3.org/200...(2096)
fhemweb.js:572 15:04:14.639 Rcvd: ["#FHEMWEB:WEBHOME","doifUpdateCell('di_vaillant','doifId','di_vaillant_uiTable_c_2_1_0_0','<svg xmlns=\u0022http://www.w3.org/2000/...(12645)
fhemweb.js:572 15:04:26.421 Rcvd: ["#FHEMWEB:WEBHOME","doifUpdateCell('Klima','doifId','Klima_uiTable_c_0_1_0_0','<svg xmlns=\u0022http://www.w3.org/2000/svg\u0022 vi...(4935)
fhemweb.js:572 15:04:26.422 Rcvd: ["#FHEMWEB:WEBHOME","doifUpdateCell('di_Heizung_temp','doifId','di_Heizung_temp_uiTable_c_0_3_0_0','<svg xmlns=\u0022http://www.w3.o...(4055)
fhemweb.js:572 15:04:26.481 Rcvd: ["#FHEMWEB:WEBHOME","doifUpdateCell('di_vaillant','doifId','di_vaillant_uiTable_c_2_2_0_0','<svg xmlns=\u0022http://www.w3.org/2000/...(12892)
fhemweb.js:572 15:04:32.144 Rcvd: ["#FHEMWEB:WEBHOME","doifUpdateCell('Aktuell','doifId','Aktuell_uiTable_c_1_0_0_0','<div style=\u0022display:inline-table;color:silv...(205)
fhemweb.js:572 15:04:34.260 ERRMSG:Connection lost, trying a reconnect every 5 seconds.<
fhemweb.js:572 15:04:39.164 ERRMSG:<
fhemweb.js:572 15:04:39.267 Inform-channel opened (HTTP) with filter room=CUL%5fEM
fhemweb.js:572 15:04:39.303 Rcvd: ["di_counter_new","initialized","<div id=\u0022di_counter_new\u0022 title=\u0022initialized\u0022 class=\u0022col2\u0022>initialize...(141)
fhemweb.js:572 15:04:39.304 Rcvd: ["MQTT2_DVES_C58DCB","???","<div id=\u0022MQTT2_DVES_C58DCB\u0022 title=\u0022???\u0022 class=\u0022col2\u0022>???</div>"]
fhemweb.js:572 15:04:40.727 Rcvd: ["#FHEMWEB:WEBHOME","doifUpdateCell('di_icon_bar_bsp','doifId','di_icon_bar_bsp_uiTable_c_0_3_0_0','<svg xmlns=\u0022http://www.w3.o...(5275)
fhemweb.js:572 15:04:40.727 Rcvd: ["#FHEMWEB:WEBHOME","doifUpdateCell('di_icon_ring','doifId','di_icon_ring_uiTable_c_1_1_0_0','<svg xmlns=\u0022http://www.w3.org/200...(5529)
fhemweb.js:572 15:04:40.781 Rcvd: ["#FHEMWEB:WEBHOME","doifUpdateCell('di_vaillant','doifId','di_vaillant_uiTable_c_3_0_0_0','<svg xmlns=\u0022http://www.w3.org/2000/...(12189)
fhemweb.js:572 15:04:52.748 Rcvd: ["#FHEMWEB:WEBHOME","doifUpdateCell('Aktuell','doifId','Aktuell_uiTable_c_3_0_0_0','<svg xmlns=\u0022http://www.w3.org/2000/svg\u002...(17331)
fhemweb.js:572 15:04:52.749 Rcvd: ["#FHEMWEB:WEBHOME","doifUpdateCell('di_icon_bar_bsp','doifId','di_icon_bar_bsp_uiTable_c_0_1_0_0','<svg xmlns=\u0022http://www.w3.o...(9038)
fhemweb.js:572 15:04:52.750 Rcvd: ["#FHEMWEB:WEBHOME","doifUpdateCell('di_icon_svg','doifId','di_icon_svg_uiTable_c_1_3_0_0','<svg xmlns=\u0022http://www.w3.org/2000/...(9030)
fhemweb.js:572 15:04:52.751 Rcvd: ["#FHEMWEB:WEBHOME","doifUpdateCell('di_icon_svg','doifId','di_icon_svg_uiTable_c_0_3_0_0','<svg xmlns=\u0022http://www.w3.org/2000/...(8439)
fhemweb.js:572 15:05:10.468 Rcvd: ["#FHEMWEB:WEBHOME","doifUpdateCell('di_icon_bar_bsp','doifId','di_icon_bar_bsp_uiTable_c_0_3_0_0','<svg xmlns=\u0022http://www.w3.o...(5275)
fhemweb.js:572 15:05:10.469 Rcvd: ["#FHEMWEB:WEBHOME","doifUpdateCell('di_icon_ring','doifId','di_icon_ring_uiTable_c_1_1_0_0','<svg xmlns=\u0022http://www.w3.org/200...(5529)
fhemweb.js:572 15:05:10.530 Rcvd: ["#FHEMWEB:WEBHOME","doifUpdateCell('di_vaillant','doifId','di_vaillant_uiTable_c_3_0_0_0','<svg xmlns=\u0022http://www.w3.org/2000/...(12189)
fhemweb.js:572 15:05:27.024 Rcvd: ["#FHEMWEB:WEBHOME","doifUpdateCell('Klima','doifId','Klima_uiTable_c_0_2_0_0','<svg xmlns=\u0022http://www.w3.org/2000/svg\u0022 vi...(6353)
fhemweb.js:572 15:05:27.025 Rcvd: ["#FHEMWEB:WEBHOME","doifUpdateCell('di_Heizung_temp','doifId','di_Heizung_temp_uiTable_c_0_4_0_0','<svg xmlns=\u0022http://www.w3.o...(5486)
fhemweb.js:572 15:05:27.081 Rcvd: ["#FHEMWEB:WEBHOME","doifUpdateCell('di_icon_temp_temp_ring','doifId','di_icon_temp_temp_ring_uiTable_c_0_1_0_0','<svg xmlns=\u0022h...(6384)
fhemweb.js:572 15:05:27.082 Rcvd: ["#FHEMWEB:WEBHOME","doifUpdateCell('di_temp_ring','doifId','di_temp_ring_uiTable_c_2_1_0_0','<svg xmlns=\u0022http://www.w3.org/200...(2068)
fhemweb.js:572 15:05:27.083 Rcvd: ["#FHEMWEB:WEBHOME","doifUpdateCell('di_vaillant','doifId','di_vaillant_uiTable_c_4_2_0_0','<svg xmlns=\u0022http://www.w3.org/2000/...(19618)
fhemweb.js:572 15:05:34.270 ERRMSG:Connection lost, trying a reconnect every 5 seconds.<
fhemweb.js:572 15:05:39.181 ERRMSG:<
fhemweb.js:572 15:05:39.277 Inform-channel opened (HTTP) with filter room=CUL%5fEM
fhemweb.js:572 15:05:39.385 Rcvd: ["di_counter_new","initialized","<div id=\u0022di_counter_new\u0022 title=\u0022initialized\u0022 class=\u0022col2\u0022>initialize...(141)
fhemweb.js:572 15:05:39.386 Rcvd: ["MQTT2_DVES_C58DCB","???","<div id=\u0022MQTT2_DVES_C58DCB\u0022 title=\u0022???\u0022 class=\u0022col2\u0022>???</div>"]
fhemweb.js:572 15:05:40.754 Rcvd: ["#FHEMWEB:WEBHOME","doifUpdateCell('di_icon_bar_bsp','doifId','di_icon_bar_bsp_uiTable_c_0_3_0_0','<svg xmlns=\u0022http://www.w3.o...(5272)
fhemweb.js:572 15:05:40.755 Rcvd: ["#FHEMWEB:WEBHOME","doifUpdateCell('di_icon_ring','doifId','di_icon_ring_uiTable_c_1_1_0_0','<svg xmlns=\u0022http://www.w3.org/200...(5524)
fhemweb.js:572 15:05:40.818 Rcvd: ["#FHEMWEB:WEBHOME","doifUpdateCell('di_vaillant','doifId','di_vaillant_uiTable_c_3_0_0_0','<svg xmlns=\u0022http://www.w3.org/2000/...(12184)
fhemweb.js:572
Ich sehe hier keinen Zusammenhang mit der Fehlermeldung, die hier regelmäßig erscheint.
genau alle 60s.
Zitat von: frank am 25 März 2022, 15:18:04
genau alle 60s.
ja, und genau im Zusammenhang mit.
fhemweb.js:572 15:03:39.341 Rcvd: ["di_counter_new","initialized","<div id=\u0022di_counter_new\u0022 title=\u0022initialized\u0022 class=\u0022col2\u0022>initialize...(141)
fhemweb.js:572 15:03:39.342 Rcvd: ["MQTT2_DVES_C58DCB","???","<div id=\u0022MQTT2_DVES_C58DCB\u0022 title=\u0022???\u0022 class=\u0022col2\u0022>???</div>"]
Wie ich bereits beschrieben habe reagiert di_counter_new auf die Events vom MQTT-Device, welches alle 60 Sekunden Nachrichten vom MQTT-Device empfängt.
Sieht man in "attr global verbose 5" Log was?
Hier scheint der Hund begraben zu sein:
MQTT2_FHEM_Server_192.168.178.141_59396 DVES_C58DCB PUBLISH tele/tasmota_C58DCB/STATE:{"Time":"2022-03-25T15:29:35","Uptime":"5T02:13:30","UptimeSec":440010,"Heap":22,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":19,"MqttCount":19,"Wifi":{"AP":1,"SSId":"FRITZ!Box 7490 2.4","BSSId":"34:31:C4:46:8B:9A","Channel":11,"Mode":"11n","RSSI":58,"Signal":-71,"LinkCount":1,"Downtime":"0T00:00:03"}}
2022.03.25 15:29:34.989 5: MQTT2_FHEM_Server: dispatch autocreate=simple\000DVES_C58DCB\000tele/tasmota_C58DCB/STATE\000{"Time":"2022-03-25T15:29:35","Uptime":"5T02:13:30","UptimeSec":440010,"Heap":22,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":19,"MqttCount":19,"Wifi":{"AP":1,"SSId":"FRITZ!Box 7490 2.4","BSSId":"34:31:C4:46:8B:9A","Channel":11,"Mode":"11n","RSSI":58,"Signal":-71,"LinkCount":1,"Downtime":"0T00:00:03"}}
2022.03.25 15:29:34.990 4: MQTT2_DEVICE_Parse: MQTT2_DVES_C58DCB tele/tasmota_C58DCB/STATE => { json2nameValue($EVENT, 'STATE_', $JSONMAP) }
2022.03.25 15:29:34.994 5: Starting notify loop for MQTT2_DVES_C58DCB, 23 event(s), first is STATE_LoadAvg: 19
2022.03.25 15:29:35.023 5: Starting notify loop for di_counter_new, 1 event(s), first is MQTT2_DVES_C58DCB.total_w.day: 415
2022.03.25 15:29:35.068 5: End notify loop for di_counter_new
2022.03.25 15:29:35.070 5: Starting notify loop for di_counter_new, 1 event(s), first is MQTT2_DVES_C58DCB.total_pv.day: 22.509
2022.03.25 15:29:35.160 5: End notify loop for di_counter_new
2022.03.25 15:29:35.162 5: Starting notify loop for di_counter_new, 1 event(s), first is MQTT2_DVES_C58DCB.total_c.day: -1.951
2022.03.25 15:29:35.207 5: End notify loop for di_counter_new
2022.03.25 15:29:35.208 5: Starting notify loop for di_counter_new, 1 event(s), first is MQTT2_DVES_C58DCB.total_f.day: 16.607
2022.03.25 15:29:35.375 5: End notify loop for di_counter_new
2022.03.25 15:29:35.383 5: End notify loop for MQTT2_DVES_C58DCB
2022.03.25 15:29:35.383 4: MQTT2_FHEM_Server_192.168.178.141_59396 DVES_C58DCB PUBLISH tele/tasmota_C58DCB/SENSOR:{"Time":"2022-03-25T15:29:35","COUNTER":{"C1":123296,"C2":2192},"MT681":{"Total_in":1269.274,"Power_cur":-1008,"Total_out":821.192,"Meter_id":"090149534b0005002910"}}
2022.03.25 15:29:35.384 5: MQTT2_FHEM_Server: dispatch autocreate=simple\000DVES_C58DCB\000tele/tasmota_C58DCB/SENSOR\000{"Time":"2022-03-25T15:29:35","COUNTER":{"C1":123296,"C2":2192},"MT681":{"Total_in":1269.274,"Power_cur":-1008,"Total_out":821.192,"Meter_id":"090149534b0005002910"}}
2022.03.25 15:29:35.384 4: MQTT2_DEVICE_Parse: MQTT2_DVES_C58DCB tele/tasmota_C58DCB/SENSOR => { json2nameValue($EVENT, 'SENSOR_', $JSONMAP) }
2022.03.25 15:29:35.387 5: Starting notify loop for MQTT2_DVES_C58DCB, 13 event(s), first is SENSOR_MT681_Total_out: 821.192
2022.03.25 15:29:35.416 5: Starting notify loop for di_counter_new, 1 event(s), first is MQTT2_DVES_C58DCB.total_w.day: 415
2022.03.25 15:29:35.460 5: End notify loop for di_counter_new
2022.03.25 15:29:35.462 5: Starting notify loop for di_counter_new, 1 event(s), first is MQTT2_DVES_C58DCB.total_pv.day: 22.531
2022.03.25 15:29:35.556 5: End notify loop for di_counter_new
2022.03.25 15:29:35.557 5: Starting notify loop for di_counter_new, 1 event(s), first is MQTT2_DVES_C58DCB.total_c.day: -1.951
2022.03.25 15:29:35.602 5: End notify loop for di_counter_new
2022.03.25 15:29:35.604 5: Starting notify loop for di_counter_new, 1 event(s), first is MQTT2_DVES_C58DCB.total_f.day: 16.625
2022.03.25 15:29:35.732 4: Closing connection WEBHOME_127.0.0.1_51954 due to full buffer in FW_Notify
2022.03.25 15:29:35.763 4: Closing connection WEBHOME_192.168.178.71_58532 due to full buffer in FW_Notify
2022.03.25 15:29:35.792 5: End notify loop for di_counter_new
2022.03.25 15:29:35.796 5: End notify loop for MQTT2_DVES_C58DCB
2022.03.25 15:29:35.797 5: alexa: read: [2022-3-25 3:29:35 PM] [FHEM] longpoll ended, reconnect in: 200msec
2022.03.25 15:29:35.936 5: alexa: read: [2022-3-25 3:29:35 PM] [FHEM] trying longpoll to listen for fhem events
2022.03.25 15:29:35.936 5: alexa: read: [2022-3-25 3:29:35 PM] [FHEM] starting longpoll: http://127.0.0.1:8086/fhem?XHR=1&inform=type=status;addglobal=1;filter=.*;since=1648218389.045;fmt=JSON×tamp=1648218575933
2022.03.25 15:29:35.936 4: Connection accepted from WEBHOME_127.0.0.1_51986
Das passiert dann, wenn im FHEM-Schreib-Puffer bereits 1MB drin ist, und man zusaetzlich was draufschreiben will.
Die Pruefung ist da, damit verklemmte Verbindungen (wie ein ausgeschalteter Rechner) FHEM nicht aufblasen.
Beim ersten Write kann man beliebig grosse Daten schreiben.
In dem aktuellen Fall wird vmtl. 1MB+ als Statusaenderung in mehreren Stuecken aber direkt hinterenander geschrieben.
Optionen:
- die Daten im DOIF auf einmal schicken
- die Daten im DOIF leicht zeitversetzt schicken
- im Framework neben dem Puffer einen Zeitstempel fuehren, und die Pruefung erst dann durchfuehren, wenn die vorhandenen Daten "alt" sind.
OK. Dann, weiß ich, wo ich anpassen muss.
Hiermit wird eine Aktualisierung eines Elementes vorgenommen:
FW_directNotify("#FHEMWEB:$_", "doifUpdateCell('$pn','doifId','$doifId','$value','display:inline-table;$style')","");
Kann ich auch mehrere doifUpdateCell-Befehle hintereinander angeben oder muss man doifUpdateCell umschreiben?
Ist halt Javascript, was per eval ausgefuehrt wird.
Mehrere doifUpdateCells mit ; getrennt sollte funktionieren.
Zitat von: rudolfkoenig am 25 März 2022, 18:41:50
Ist halt Javascript, was per eval ausgefuehrt wird.
Mehrere doifUpdateCells mit ; getrennt sollte funktionieren.
OK. Dann probieren wir es mal.
Zitat von: Damian am 25 März 2022, 19:13:29
OK. Dann probieren wir es mal.
Schade eigentlich - hat nicht geholfen, Problem besteht immer noch.
Pro DOIF_Notify wird jetzt FW_directNotify nur einmal aufgerufen:
my $update_output="";
foreach my $table ("uiTable","uiState") {
if (defined $hash->{Regex}{$table}) {
foreach $device ("$dev->{NAME}","") {
if (defined $hash->{Regex}{$table}{$device}) {
foreach my $doifId (keys %{$hash->{Regex}{$table}{$device}}) {
my $readingregex=CheckRegexpDoIf($hash,$table,$dev->{NAME},$doifId,$eventa,$eventas);
$update_output.=DOIF_UpdateCell($hash,$doifId,$hash->{NAME},$readingregex) if (defined($readingregex));
}
}
}
if (defined ($hash->{helper}{DOIF_eventas})) { #$SELF events
foreach my $doifId (keys %{$hash->{Regex}{$table}{$hash->{NAME}}}) {
my $readingregex=CheckRegexpDoIf($hash,$table,$hash->{NAME},$doifId,$hash->{helper}{DOIF_eventa},$hash->{helper}{DOIF_eventas});
$update_output.=DOIF_UpdateCell($hash,$doifId,$hash->{NAME},$readingregex) if (defined($readingregex));
}
}
}
}
if ($update_output) {
map {
FW_directNotify("#FHEMWEB:$_", $update_output,"");
} devspec2array("TYPE=FHEMWEB");
}
leider wird in der Fehlermeldung nicht angezeigt, was im Puffer alles drin steht.
Zitatleider wird in der Fehlermeldung nicht angezeigt, was im Puffer alles drin steht.
Du koenntest in fhem.pl/addToWriteBuffer(), Zeile 6404 (vor dem return 0) $hash->{$wbName} ausgeben.
Falls Du mir was zum Nachstellen bauen kannst (irgendetwas mit defmod DOIF, trigger, oder { code }), dann werde ich versuchen das Problem in fhem.pl zu loesen, mit Zeitstempel, wie ich das vorhin beschrieben habe.
Zitat von: rudolfkoenig am 27 März 2022, 11:35:03
Du koenntest in fhem.pl/addToWriteBuffer(), Zeile 6404 (vor dem return 0) $hash->{$wbName} ausgeben.
Falls Du mir was zum Nachstellen bauen kannst (irgendetwas mit defmod DOIF, trigger, oder { code }), dann werde ich versuchen das Problem in fhem.pl zu loesen, mit Zeitstempel, wie ich das vorhin beschrieben habe.
Ich habe mal was zusammengestellt:
Hier ein Device, welches das MQTT-Device simuliert, indem es alle 10 Sekunden (Zeitspanne kannst du anpassen) in einem Eventblock Readings schreibt:
defmod d_test_mqtt DOIF {[+10];;\
set_Reading_Begin();;\
set_Reading_Update("total_w",1);;\
set_Reading_Update("total_pv",2);;\
set_Reading_Update("total_c",3);;\
set_Reading_Update("total_f",4);;\
set_Reading_Update("total_h",5);;\
set_Reading_Update("total_hc",6);;\
set_Reading_Update("total_hwc",7);;\
set_Reading_Update("total_w2",8);;\
set_Reading_Update("total_pv2",9);;\
set_Reading_Update("total_c2",10);;\
set_Reading_Update("total_f2",11);;\
set_Reading_Update("total_h2",12);;\
set_Reading_Update("total_hc2",13);;\
set_Reading_Update("total_hwc2",14);;\
set_Reading_End(1);;\
}
attr d_test_mqtt room CUL_EMDieses Device reagiert auf die obigen Readings, berechnet und schreibt ein paar eigene Readings und lässt sie über cards visualisieren:
defmod di_counter_test DOIF subs {\
## Device Reading \
push (@{$_counter},["d_test_mqtt","total_w"]);; ## Wasserzähler\
push (@{$_counter},["d_test_mqtt","total_pv"]);; ## Solarenergie\
push (@{$_counter},["d_test_mqtt","total_c"]);; ## Bezugszähler\
push (@{$_counter},["d_test_mqtt","total_f"]);; ## Einspeisezähler \
push (@{$_counter},["d_test_mqtt","total_h"]);; ## Gasverbrauch Heizung + Warmwasser\
push (@{$_counter},["d_test_mqtt","total_hc"]);; ## Gasverbrauch Heizung\
push (@{$_counter},["d_test_mqtt","total_hwc"]);; ## Gasverbrauch Warmwasser \
push (@{$_counter},["d_test_mqtt","total_w2"]);; ## Wasserzähler\
push (@{$_counter},["d_test_mqtt","total_pv2"]);; ## Solarenergie\
push (@{$_counter},["d_test_mqtt","total_c2"]);; ## Bezugszähler\
push (@{$_counter},["d_test_mqtt","total_f2"]);; ## Einspeisezähler \
push (@{$_counter},["d_test_mqtt","total_h2"]);; ## Gasverbrauch Heizung + Warmwasser\
push (@{$_counter},["d_test_mqtt","total_hc2"]);; ## Gasverbrauch Heizung\
push (@{$_counter},["d_test_mqtt","total_hwc2"]);; ## Gasverbrauch Warmwasser \
\
sub midnight { ## Diese Funktion wird um Mitternacht ausgeführt\
my ($device,$reading,$mday,$yday)=@_;;\
set_Reading("$device.$reading.day_counter",ReadingsVal($device, $reading,0));; \
set_Reading("$device.$reading.last_day",get_Reading("$device.$reading.day",0),1);;\
set_Reading("$device.$reading.day",0,1);;\
set_Reading ("$1.$2.month",int((ReadingsVal($device, $reading,0)-(get_Reading("$1.$2.month_counter",0)))*1000)/1000,1);;\
set_Reading ("$1.$2.year",int((ReadingsVal($device, $reading,0)-(get_Reading("$1.$2.year_counter",0)))*1000)/1000,1);;\
\
if ($mday == 1) {\
set_Reading("$device.$reading.month_counter",ReadingsVal($device, $reading,0));;\
set_Reading("$device.$reading.last_month",get_Reading("$device.$reading.month",0),1);;\
set_Reading("$device.$reading.month",0,1);;\
}\
if ($yday == 1) {\
set_Reading("$device.$reading.year_counter",ReadingsVal($device, $reading,0));;\
set_Reading("$device.$reading.last_year",get_Reading("$device.$reading.year",0),1);;\
set_Reading("$device.$reading.year",0,1);;\
}\
}\
\
sub init_readings {\
my ($device,$reading)=@_;;\
if (get_Reading("$device.$reading.day_counter","") eq "") { ## Initialisierung der Readings\
## aktuellen Zählerstand initialisieren\
set_Reading("$device.$reading.last_counter",ReadingsVal($device, $reading,0));;\
set_Reading("$device.$reading.day_counter",ReadingsVal($device, $reading,0));; \
##set_Reading("$device.$reading.month_counter",ReadingsVal($device, $reading,0));;\
##set_Reading("$device.$reading.year_counter",ReadingsVal($device, $reading,0));;\
\
set_Reading ("$device.$reading.day",0);; ## aktueller Tagesverbrauch\
set_Reading ("$device.$reading.month",0);; ## aktueller Monatsverbrauch\
set_Reading ("$device.$reading.year",0);; ## aktueller Jahresverbrauch\
set_Reading ("$device.$reading.last_day",0);; ## Verbrauch des letzten Tages\
set_Reading ("$device.$reading.last_month",0);; ## Verbrauch des letzten Monats\
set_Reading ("$device.$reading.last_year",0);; ## Verbrauch des letzten Jahres\
## Log definieren\
fhem ("defmod log.counter.$device.$reading FileLog ./log/counter.$device.$reading.log $SELF:$device.$reading.last_(day|month|year):.*");;\
fhem ("attr log.counter.$device.$reading room Filelogs");;\
}\
\
}\
} ## Ende subs-Block\
\
mid {[00:01];; ## Sicherung der Daten um Mitternacht\
for (my $i=0;;$i<@{$_counter};;$i++) { ## Für jeden Zähler wird die Funktion midnight aufgerufen\
midnight($_counter[$i][0],$_counter[$i][1],$mday,$yday);;\
}\
}\
\
init { ## initialisierung aller Readings\
for (my $i=0;;$i<@{$_counter};;$i++) {## Für jeden Zähler werden Readings über die Funktion init_readings initialisiert\
init_readings($_counter[$i][0],$_counter[$i][1]);;\
}\
}\
\
DEF TPL_stat (\
day_count_$1_$2 { ## bei einem Event des Zählers, wird der tägliche, monatliche und jährliche Verbrauch im jeweiligen Reading festgehalten\
## $1 Zählerdevice, $2 Zählerreading\
\
my $diff = int(([$1:$2,0]-(get_Reading("$1.$2.last_counter",0)))*1000)/1000;;\
if ($diff < 0 and get_Reading("$1.$2.last_counter",0) > 0 or $diff > 0 and get_Reading("$1.$2.last_counter",0) < 0) { ## Wenn der Zähler zurückgesetzt wurde, dann Zählerstände zurückrechnen\
set_Reading("$1.$2.day_counter",-(get_Reading("$1.$2.day",0)));;\
set_Reading("$1.$2.month_counter",-(get_Reading("$1.$2.month",0)));;\
set_Reading("$1.$2.year_counter",-(get_Reading("$1.$2.year",0)));;\
}\
set_Reading ("$1.$2.last_counter",[$1:$2,0]);;\
set_Reading ("$1.$2.day",int(([$1:$2,0]-(get_Reading("$1.$2.day_counter",0)))*1000)/1000,1);;\
##set_Reading ("$1.$2.month",int(([$1:$2,0]-(get_Reading("$1.$2.month_counter",0)))*1000)/1000,1);;\
##set_Reading ("$1.$2.year",int(([$1:$2,0]-(get_Reading("$1.$2.year_counter",0)))*1000)/1000,1);;\
}\
)\
\
\
## Pro Zähler wird über eine FOR-Schleife ein day_count_<Device>_<Reading>-Block generiert\
FOR(@{$_counter},TPL_stat($1$1,$1$2)) ## $1$1 entspricht dem Device, $1$2 entspricht dem Reading
attr di_counter_test room CUL_EM
attr di_counter_test uiTable {package ui_Table} ## Optionale Visualisierung der Energie-Verbräuche/-Produktion im DOIF-Device\
card([di_counter_test:d_test_mqtt.total_w.day:100col1w],"Wasser in l pro Tag","sani_water_tap",0,500,90,0,"Liter",undef,"1","130,,1,0,1,,200","0,0,0,0")|\
card([di_counter_test:d_test_mqtt.total_w.month:100col365d],"Wasser in l pro Monat","sani_water_tap",0,10000,90,0,"Liter",undef,"0","130,,1,0,1,,200","0,0,0,0")\
\
card([[di_counter_test:d_test_mqtt.total_pv.day:100col1w],[di_counter_test:d_test_mqtt.total_f.day:100col1w]],"Solarenergie in kWh pro Tag","solar_icon",-25,25,0,90,["PV","Einsp."],undef,"1","130,,1,0,1,,200","0,0,0,0,2")|\
##card([di_counter_test:d_test_mqtt.total_pv.day:100col1w],"Solarenergie in kWh pro Tag","solar_icon",-25,25,0,90,"PV",undef,"1","130,,1,0,1,,200","0,0,0,0,2")\
card([[di_counter_test:d_test_mqtt.total_pv.month:100col365d],[di_counter_test:d_test_mqtt.total_f.month:100col365d]],"Solarenergie in kWh pro Monat","solar_icon",-300,300,0,90,["PV","Einsp."],undef,"1","130,,1,0,1,,200","0,0,0,0,2")\
\
card([[di_counter_test:d_test_mqtt.total_f.day:100col1w],[di_counter_test:d_test_mqtt.total_c.day:100col1w]],"Elektrizität in kWh pro Tag","fa_bolt",-25,25,0,90,["Ertrag","Bezug"],undef,"1","130,,1,0,1,,200","0,0,0,0,2")|\
card([[di_counter_test:d_test_mqtt.total_f.month:100col365d],[di_counter_test:d_test_mqtt.total_c.month:100col365d]],"Elektrizität in kWh pro Monat","fa_bolt",-300,300,0,90,["Ertrag","Bezug"],undef,"1","130,,1,0,1,,200","0,0,0,0,2")\
\
card([[di_counter_test:d_test_mqtt.total_h.day:100col1w],[di_counter_test:d_test_mqtt.total_hwc.day:100col1w]],"Heizenergie in kWh pro Tag","sani_boiler_temp",0,100,90,0,["Gesamt","Wasser"],undef,"1","130,,1,0,1,,200","0,0,0,0,2")|\
card([[di_counter_test:d_test_mqtt.total_h.month:100col365d],[di_counter_test:d_test_mqtt.total_hwc.month:100col365d]],"Heizenergie in kWh pro Monat","sani_boiler_temp",0,1500,90,0,["Gesamt","Wasser"],undef,"1","130,,1,0,1,,200","0,0,0,0,2")\
\
card([di_counter_test:d_test_mqtt.total_w2.day:100col1w],"Wasser in l pro Tag","sani_water_tap",0,500,90,0,"Liter",undef,"1","130,,1,0,1,,200","0,0,0,0")|\
card([di_counter_test:d_test_mqtt.total_w2.month:100col365d],"Wasser in l pro Monat","sani_water_tap",0,10000,90,0,"Liter",undef,"0","130,,1,0,1,,200","0,0,0,0")\
\
card([[di_counter_test:d_test_mqtt.total_pv2.day:100col1w],[di_counter_test:d_test_mqtt.total_f2.day:100col1w]],"Solarenergie in kWh pro Tag","solar_icon",-25,25,0,90,["PV","Einsp."],undef,"1","130,,1,0,1,,200","0,0,0,0,2")|\
##card([di_counter_test:d_test_mqtt.total_pv.day:100col1w],"Solarenergie in kWh pro Tag","solar_icon",-25,25,0,90,"PV",undef,"1","130,,1,0,1,,200","0,0,0,0,2")\
card([[di_counter_test:d_test_mqtt.total_pv2.month:100col365d],[di_counter_test:d_test_mqtt.total_f2.month:100col365d]],"Solarenergie in kWh pro Monat","solar_icon",-300,300,0,90,["PV","Einsp."],undef,"1","130,,1,0,1,,200","0,0,0,0,2")\
\
##card([[di_counter_test:d_test_mqtt.total_f2.day:100col1w],[di_counter_test:d_test_mqtt.total_c2.day:100col1w]],"Elektrizität in kWh pro Tag","fa_bolt",-25,25,0,90,["Ertrag","Bezug"],undef,"1","130,,1,0,1,,200","0,0,0,0,2")|\
##card([[di_counter_test:d_test_mqtt.total_f2.month:100col365d],[di_counter_test:d_test2_mqtt.total_c2.month:100col365d]],"Elektrizität in kWh pro Monat","fa_bolt",-300,300,0,90,["Ertrag","Bezug"],undef,"1","130,,1,0,1,,200","0,0,0,0,2")\
\
card([[di_counter_test:d_test_mqtt.total_h2.day:100col1w],[di_counter_test:d_test_mqtt.total_hwc2.day:100col1w]],"Heizenergie in kWh pro Tag","sani_boiler_temp",0,100,90,0,["Gesamt","Wasser"],undef,"1","130,,1,0,1,,200","0,0,0,0,2")|\
card([[di_counter_test:d_test_mqtt.total_h2.month:100col365d],[di_counter_test:d_test_mqtt.total_hwc2.month:100col365d]],"Heizenergie in kWh pro Monat","sani_boiler_temp",0,1500,90,0,["Gesamt","Wasser"],undef,"1","130,,1,0,1,,200","0,0,0,0,2")Damit kann ich den Fehler bei mir nachstellen.
Danke fuer die Konfiguration.
Ich habe fhem.pl so angepasst, dass die Puffer-Begrenzung erst nach dem ersten syswrite geprueft wird, damit gibt es bei mir kein connection lost mehr.
Um zu vermeiden, dass man bei jedem Event megabyteweise Daten an dem Browser geschickt werden, koennte man FHEMWEB-Widgets / JavaScript verwenden. Diese werden bei einem Event nur mit dem neuen Wert benachrichtigt, und das ermoeglicht auch eine Interaktion mit dem Widget.
Zitat von: rudolfkoenig am 28 März 2022, 11:09:53
Danke fuer die Konfiguration.
Ich habe fhem.pl so angepasst, dass die Puffer-Begrenzung erst nach dem ersten syswrite geprueft wird, damit gibt es bei mir kein connection lost mehr.
Um zu vermeiden, dass man bei jedem Event megabyteweise Daten an dem Browser geschickt werden, koennte man FHEMWEB-Widgets / JavaScript verwenden. Diese werden bei einem Event nur mit dem neuen Wert benachrichtigt, und das ermoeglicht auch eine Interaktion mit dem Widget.
Ok, Danke. Ich werde es später zuhause testen.
Aber in der aktuellen (eingecheckten) Version von DOIF, mit der du getestet hast, werden ja nur die Änderungen per FW_directNotify geschickt und zwar nur von der Zellen-ID (card) des jeweiligen Events. Klar, bei card werden die Daten im Array auf der Perlseite aufgrund eines Events verschoben, dadurch muss der Plot neu berechnet und übertragen werden, aber das sind ja im Normalfall auch nur 72 Zahlenpaare und der html-Code für eine card. Das Problem ist offenbar die Anzahl der Events, die auf einmal kommen.
Auf der anderen Seite ist die erste Übertragung des vollständigen HTML-Codes von 44 cards in 0,1 Sekunden erledigt, dann sollten Daten von 6 cards beim Update (da kommen bei mir die ersten Probleme) eigentlich kein Problem darstellen.
Um die Datenmenge beim Update zu reduzieren, müsste die Aufbereitung des Plots, am besten der ganzen card, auf der javascript-Seite laufen, aber dafür müsste man den Code neu schreiben.
Ich kann bestätigen, dass das Problem nicht mehr aufkommt :)
Ich habe schon länger in Planung FHEM-SVG-Widgets zu programmieren, vielleicht gelingt mir das auch für card. Aber erst mal läuft es ja.
Zu früh gefreut, Abbruch kommt zwar nicht regelmäßig wie zuvor, aber leider unregelmäßig alle paar Minuten, vermutlich zufällig wie die Daten gerade zusammentreffen:
22:15:48.380 Rcvd: ["#FHEMWEB:WEBHOME","doifUpdateCell('di_vaillant','doifId','di_vaillant_uiTable_c_3_0_0_0','<svg xmlns=\u0022http://www.w3.org/2000/...(12185)
fhemweb.js:572 22:15:54.401 ERRMSG:Connection lost, trying a reconnect every 5 seconds.<
fhemweb.js:572 22:15:59.303 ERRMSG:<
fhemweb.js:572 22:15:59.403 Inform-channel opened (HTTP) with filter room=Status
fhemweb.js:572 22:16:03.867 Rcvd:
fhemweb.js:572 22:16:03.867 Rcvd: ["#FHEMWEB:WEBHOME","doifUpdateCell('Klima','doifId','Klima_uiTable_c_0_1_0_0','<svg xmlns=\u0022http://www.w3.org/2000/svg\u0022 vi...(4948)
fhemweb.js:572
Ich koennte die Grenze von 1MB in fhem.pl erhoehen, bin aber nicht sicher, dass das die richtige Strategie ist.
Kannst Du fuer diesen Fall auch was zum Nachstellen bauen?
Zitat von: rudolfkoenig am 29 März 2022, 22:35:58
Ich koennte die Grenze von 1MB in fhem.pl erhoehen, bin aber nicht sicher, dass das die richtige Strategie ist.
Kannst Du fuer diesen Fall auch was zum Nachstellen bauen?
Wann wird der Puffer eigentlich zurückgesetzt?
Sieht man alle Daten, die geschickt werden, auf der Console?
Man kann hier die Datenmengen zusammenrechnen, sie betragen immer paar KByte, pro Tabellenzelle mit card.
Hier der vollständige Output zwischen zwei Abbrüchen:
fhemweb.js:572 22:29:54.274 ERRMSG:Connection lost, trying a reconnect every 5 seconds.<
fhemweb.js:572 22:29:59.176 ERRMSG:<
fhemweb.js:572 22:29:59.278 Inform-channel opened (HTTP) with filter room=Status
fhemweb.js:572 22:30:06.336 Rcvd:
fhemweb.js:572 22:30:06.336 Rcvd: ["#FHEMWEB:WEBHOME","doifUpdateCell('Klima','doifId','Klima_uiTable_c_0_2_0_0','<svg xmlns=\u0022http://www.w3.org/2000/svg\u0022 vi...(6357)
fhemweb.js:572 22:30:06.337 Rcvd: ["#FHEMWEB:WEBHOME","doifUpdateCell('di_Heizung_temp','doifId','di_Heizung_temp_uiTable_c_0_5_0_0','<svg xmlns=\u0022http://www.w3.o...(5486)
fhemweb.js:572 22:30:06.408 Rcvd: ["#FHEMWEB:WEBHOME","doifUpdateCell('di_icon_temp_temp_ring','doifId','di_icon_temp_temp_ring_uiTable_c_0_1_0_0','<svg xmlns=\u0022h...(6388)
fhemweb.js:572 22:30:08.396 Rcvd: ["#FHEMWEB:WEBHOME","doifUpdateCell('di_vaillant','doifId','di_vaillant_uiTable_c_4_2_0_0','<svg xmlns=\u0022http://www.w3.org/2000/...(19571)
fhemweb.js:572 22:30:18.344 Rcvd: ["#FHEMWEB:WEBHOME","doifUpdateCell('di_icon_bar_bsp','doifId','di_icon_bar_bsp_uiTable_c_0_3_0_0','<svg xmlns=\u0022http://www.w3.o...(5275)
fhemweb.js:572 22:30:18.344 Rcvd: ["#FHEMWEB:WEBHOME","doifUpdateCell('di_icon_ring','doifId','di_icon_ring_uiTable_c_1_1_0_0','<svg xmlns=\u0022http://www.w3.org/200...(5529)
fhemweb.js:572 22:30:18.397 Rcvd: ["#FHEMWEB:WEBHOME","doifUpdateCell('di_vaillant','doifId','di_vaillant_uiTable_c_3_0_0_0','<svg xmlns=\u0022http://www.w3.org/2000/...(12185)
fhemweb.js:572 22:30:48.578 Rcvd: ["#FHEMWEB:WEBHOME","doifUpdateCell('di_icon_bar_bsp','doifId','di_icon_bar_bsp_uiTable_c_0_3_0_0','<svg xmlns=\u0022http://www.w3.o...(5275)
fhemweb.js:572 22:30:48.579 Rcvd: ["#FHEMWEB:WEBHOME","doifUpdateCell('di_icon_ring','doifId','di_icon_ring_uiTable_c_1_1_0_0','<svg xmlns=\u0022http://www.w3.org/200...(5525)
fhemweb.js:572 22:30:48.636 Rcvd: ["#FHEMWEB:WEBHOME","doifUpdateCell('di_vaillant','doifId','di_vaillant_uiTable_c_3_0_0_0','<svg xmlns=\u0022http://www.w3.org/2000/...(12181)
fhemweb.js:572 22:30:51.595 Rcvd: ["#FHEMWEB:WEBHOME","doifUpdateCell('di.icon.bar','doifId','di.icon.bar_uiTable_c_0_1_0_0','<svg xmlns=\u0022http://www.w3.org/2000/...(6175)
fhemweb.js:572 22:30:51.595 Rcvd: ["#FHEMWEB:WEBHOME","doifUpdateCell('di.icon.bar','doifId','di.icon.bar_uiTable_c_1_1_0_0','<svg xmlns=\u0022http://www.w3.org/2000/...(6183)
fhemweb.js:572 22:30:51.647 Rcvd: ["#FHEMWEB:WEBHOME","doifUpdateCell('di.icon.bar','doifId','di.icon.bar_uiTable_c_2_1_0_0','<svg xmlns=\u0022http://www.w3.org/2000/...(6178)
fhemweb.js:572 22:30:51.648 Rcvd: ["#FHEMWEB:WEBHOME","doifUpdateCell('di.icon.bar','doifId','di.icon.bar_uiTable_c_4_1_0_0','<svg xmlns=\u0022http://www.w3.org/2000/...(6303)
fhemweb.js:572 22:30:51.649 Rcvd: ["#FHEMWEB:WEBHOME","doifUpdateCell('di.icon.bar','doifId','di.icon.bar_uiTable_c_5_1_0_0','<svg xmlns=\u0022http://www.w3.org/2000/...(6179)
fhemweb.js:572 22:30:51.649 Rcvd: ["#FHEMWEB:WEBHOME","doifUpdateCell('di.icon.bar','doifId','di.icon.bar_uiTable_c_3_1_0_0','<svg xmlns=\u0022http://www.w3.org/2000/...(6175)
fhemweb.js:572 22:30:51.649 Rcvd: ["#FHEMWEB:WEBHOME","doifUpdateCell('di_auriol','doifId','di_auriol_uiTable_c_0_2_0_0','<svg xmlns=\u0022http://www.w3.org/2000/svg\...(17762)
fhemweb.js:572 22:30:51.650 Rcvd: ["#FHEMWEB:WEBHOME","doifUpdateCell('di_icon_hum_bar','doifId','di_icon_hum_bar_uiTable_c_2_1_0_0','<svg xmlns=\u0022http://www.w3.o...(6184)
fhemweb.js:572 22:30:51.651 Rcvd: ["#FHEMWEB:WEBHOME","doifUpdateCell('di_icon_hum_bar','doifId','di_icon_hum_bar_uiTable_c_5_1_0_0','<svg xmlns=\u0022http://www.w3.o...(6185)
fhemweb.js:572 22:30:51.651 Rcvd: ["#FHEMWEB:WEBHOME","doifUpdateCell('di_icon_hum_bar','doifId','di_icon_hum_bar_uiTable_c_0_1_0_0','<svg xmlns=\u0022http://www.w3.o...(6181)
fhemweb.js:572 22:30:51.652 Rcvd: ["#FHEMWEB:WEBHOME","doifUpdateCell('di_icon_hum_bar','doifId','di_icon_hum_bar_uiTable_c_4_1_0_0','<svg xmlns=\u0022http://www.w3.o...(6309)
fhemweb.js:572 22:30:51.652 Rcvd: ["#FHEMWEB:WEBHOME","doifUpdateCell('di_icon_hum_bar','doifId','di_icon_hum_bar_uiTable_c_3_1_0_0','<svg xmlns=\u0022http://www.w3.o...(6181)
fhemweb.js:572 22:30:51.653 Rcvd: ["#FHEMWEB:WEBHOME","doifUpdateCell('di_icon_hum_bar','doifId','di_icon_hum_bar_uiTable_c_1_1_0_0','<svg xmlns=\u0022http://www.w3.o...(6189)
fhemweb.js:572 22:30:51.653 Rcvd: ["#FHEMWEB:WEBHOME","doifUpdateCell('di_icon_hum_ring','doifId','di_icon_hum_ring_uiTable_c_0_1_0_0','<svg xmlns=\u0022http://www.w3...(3989)
fhemweb.js:572 22:30:51.654 Rcvd: ["#FHEMWEB:WEBHOME","doifUpdateCell('di_icon_hum_ring','doifId','di_icon_hum_ring_uiTable_c_2_1_0_0','<svg xmlns=\u0022http://www.w3...(2036)
fhemweb.js:572 22:30:51.654 Rcvd: ["#FHEMWEB:WEBHOME","doifUpdateCell('di_icon_hum_ring','doifId','di_icon_hum_ring_uiTable_c_1_1_0_0','<svg xmlns=\u0022http://www.w3...(3986)
fhemweb.js:572 22:30:51.654 Rcvd: ["#FHEMWEB:WEBHOME","doifUpdateCell('di_icon_svg','doifId','di_icon_svg_uiTable_c_0_1_0_0','<svg xmlns=\u0022http://www.w3.org/2000/...(3981)
fhemweb.js:572 22:30:51.655 Rcvd: ["#FHEMWEB:WEBHOME","doifUpdateCell('di_icon_svg','doifId','di_icon_svg_uiTable_c_1_1_0_0','<svg xmlns=\u0022http://www.w3.org/2000/...(4570)
fhemweb.js:572 22:30:51.655 Rcvd: ["#FHEMWEB:WEBHOME","doifUpdateCell('di_icon_temp_hum_ring','doifId','di_icon_temp_hum_ring_uiTable_c_2_1_0_0','<svg xmlns=\u0022htt...(5071)
fhemweb.js:572 22:30:51.656 Rcvd: ["#FHEMWEB:WEBHOME","doifUpdateCell('di_icon_temp_hum_ring','doifId','di_icon_temp_hum_ring_uiTable_c_0_1_0_0','<svg xmlns=\u0022htt...(5070)
fhemweb.js:572 22:30:51.656 Rcvd: ["#FHEMWEB:WEBHOME","doifUpdateCell('di_icon_temp_hum_ring','doifId','di_icon_temp_hum_ring_uiTable_c_1_1_0_0','<svg xmlns=\u0022htt...(5106)
fhemweb.js:572 22:30:51.657 Rcvd: ["#FHEMWEB:WEBHOME","doifUpdateCell('di_icon_temp_temp_ring','doifId','di_icon_temp_temp_ring_uiTable_c_1_1_0_0','<svg xmlns=\u0022h...(5157)
fhemweb.js:572 22:30:51.657 Rcvd: ["#FHEMWEB:WEBHOME","doifUpdateCell('di_temp_hum','doifId','di_temp_hum_uiTable_c_0_1_0_0','<svg xmlns=\u0022http://www.w3.org/2000/...(2604)
fhemweb.js:572 22:30:51.658 Rcvd: ["#FHEMWEB:WEBHOME","doifUpdateCell('di_temp_hum','doifId','di_temp_hum_uiTable_c_5_1_0_0','<svg xmlns=\u0022http://www.w3.org/2000/...(4810)
fhemweb.js:572 22:30:51.722 Rcvd: ["#FHEMWEB:WEBHOME","doifUpdateCell('di_temp_hum','doifId','di_temp_hum_uiTable_c_6_1_0_0','<svg xmlns=\u0022http://www.w3.org/2000/...(4737)
fhemweb.js:572 22:30:51.722 Rcvd: ["#FHEMWEB:WEBHOME","doifUpdateCell('di_temp_hum','doifId','di_temp_hum_uiTable_c_3_1_0_0','<svg xmlns=\u0022http://www.w3.org/2000/...(4746)
fhemweb.js:572 22:30:51.723 Rcvd: ["#FHEMWEB:WEBHOME","doifUpdateCell('di_temp_hum','doifId','di_temp_hum_uiTable_c_4_1_0_0','<svg xmlns=\u0022http://www.w3.org/2000/...(4867)
fhemweb.js:572 22:30:51.724 Rcvd: ["#FHEMWEB:WEBHOME","doifUpdateCell('di_temp_hum','doifId','di_temp_hum_uiTable_c_2_1_0_0','<svg xmlns=\u0022http://www.w3.org/2000/...(4742)
fhemweb.js:572 22:30:51.725 Rcvd: ["#FHEMWEB:WEBHOME","doifUpdateCell('di_temp_hum','doifId','di_temp_hum_uiTable_c_7_1_0_0','<svg xmlns=\u0022http://www.w3.org/2000/...(4739)
fhemweb.js:572 22:30:51.726 Rcvd: ["#FHEMWEB:WEBHOME","doifUpdateCell('di_temp_hum','doifId','di_temp_hum_uiTable_c_1_1_0_0','<svg xmlns=\u0022http://www.w3.org/2000/...(4739)
fhemweb.js:572 22:30:51.726 Rcvd: ["#FHEMWEB:WEBHOME","doifUpdateCell('di_temp_hum_ring','doifId','di_temp_hum_ring_uiTable_c_1_1_0_0','<svg xmlns=\u0022http://www.w3...(2924)
fhemweb.js:572 22:30:51.727 Rcvd: ["#FHEMWEB:WEBHOME","doifUpdateCell('di_temp_hum_ring','doifId','di_temp_hum_ring_uiTable_c_2_1_0_0','<svg xmlns=\u0022http://www.w3...(2925)
fhemweb.js:572 22:30:51.727 Rcvd: ["#FHEMWEB:WEBHOME","doifUpdateCell('di_temp_hum_ring','doifId','di_temp_hum_ring_uiTable_c_3_1_0_0','<svg xmlns=\u0022http://www.w3...(2962)
fhemweb.js:572 22:30:51.728 Rcvd: ["#FHEMWEB:WEBHOME","doifUpdateCell('di_temp_hum_ring','doifId','di_temp_hum_ring_uiTable_c_0_1_0_0','<svg xmlns=\u0022http://www.w3...(2924)
fhemweb.js:572 22:30:51.728 Rcvd: ["#FHEMWEB:WEBHOME","doifUpdateCell('di_uiTable_hum','doifId','di_uiTable_hum_uiTable_c_1_1_1_0','63.1 %','display:inline-table...(185)
fhemweb.js:572 22:30:51.729 Rcvd: ["#FHEMWEB:WEBHOME","doifUpdateCell('di_uiTable_wetter','doifId','di_uiTable_wetter_uiTable_c_0_1_0_0','<svg xmlns=\u0022http://www....(2930)
fhemweb.js:572 22:30:54.364 ERRMSG:Connection lost, trying a reconnect every 5 seconds.<
fhemweb.js:572 22:30:59.274 ERRMSG:<Sie werden nach meinem Verständnis hier ca. eine Minute lang gesammelt, bis es wieder knallt.
Also die Summe der angezeigten Daten beträgt: 265756, das ist weniger als 1 MB.
Ist der Puffer pro WEB-Instanz oder für alle?
Können Daten von anderen WEB-Instanzen, die auf der Console nicht angezeigt werden, dazukommen?
Edit: übrigens die meisten Daten sind im Output nicht von cards, sondern von svg-Ringen oder svg-bars. cards sind die mit 10-20 KB.
ZitatWann wird der Puffer eigentlich zurückgesetzt?
Das sind die gepufferten Daten, die ueber diese eine Verbindung rausgeschickt werden muessen.
Der Puffer wird nicht zurueckgesetzt, sondern verkleinert, bis alles weg ist, und dann geloescht.
Wenn kein Puffer da ist, oder mit dem Schreiben (mit syswrite) noch nicht begonnen wurde, greift der Zaehler nicht.
ZitatAlso die Summe der angezeigten Daten beträgt: 265756, das ist weniger als 1 MB.
Auf der Client-Seite was zu zaehlen ist sinnfrei, was zaehlt ist das, was im Server ist, d.h. noch nicht zum Client geschickt werden konnte.
Die erstellte Seite kann beliebig gross sein, aber die Benachrichtigung fuer diese Seite kann man nur bis zu 1MB an gepufferten(!) Daten haben. Damit wird das Problem der "verklemmten Verbindungen" geloest, z.Bsp. wenn ein Notebook mit einem offenen Event-Monitor geschlossen wird.
OK. Dann muss man das Problem anderes analysieren.
Ich denke, ich baue eine Ausgabe des Puffers im log ein, um zu schauen, was wann drin ist.
An der Ausgabe der javascript-console kann man aber immerhin erkennen in welcher Größenordnung die einzelnen Updates der Zellen sind: 4- 20 KB pro Update.
Es müssten sich also schon recht viele einzelne Ausgaben angesammelt haben, wenn man damit den Puffer von 1 MB sprengen will.
Die Vergrößerung des Puffers wird vermutlich das Problem nicht lösen. Ich werde das Problem bei mir im Live-System untersuchen, weil es sonst schwierig sein dürfte, ein komplexes System zu simulieren.
Ich habe mir den Puffer anzeigen lassen, der ging bei mir bis 1,3 MB. Was auffiel, waren bestimmte card-Zellen, die 270 KB groß waren, also viel größer als die anderen cards. Tja die Lösung des Rätsels war ganz einfach - man sollte nicht bestimmte eingecheckte icons nutzen, wie bei mir konkret solar_icon mit ca. 235 KB. Nur gut, dass ich das gefrierschrank-Icon nicht genommen hatte mit knapp 1 MB. Hätte man die beiden in devStateIcon kombiniert, dann hätte es je nach Konstellation genauso geknallt.
Ich bin dafür eine maximale Größe für eingecheckt Icons vorzugeben, denn die obigen Icons kann man wesentlich platzsparender gestalten, wenn man weiß was man tut.
ZitatIch bin dafür eine maximale Größe für eingecheckt Icons vorzugeben, denn die obigen Icons kann man wesentlich platzsparender gestalten, wenn man weiß was man tut.
Ich habe dagegen nichts einzuwenden, aber der Maintainer sollte involviert werden.
Ich gehe davon aus, dass die erwaehnten Icons aus einem Bitmap nach SVG konvertiert wurden, und die Aufloesung/Qualitaet des Ausgangsbildes nicht optimal war.
Ich habe zwei Optimierungsmethoden gefunden:
- scour (Kommandozeilenprogramm), was beim solar_icon.png die Datei auf 83%, bei gefrierschrank_icon auf 79% komprimieren konnte.
- inkscape, Path->Simplify, was bei solar_icon auf 21% (49k) kam, bei gefrierschrank_icon auf 40%. Die Unterschiede sind bei 300x300 Pixel merkbar (aber nicht unbedingt schlechter), bei der voreingestellten Groesse von 32x32 sehe ich keine Unterschiede.
Apropos gefrierschrank: es existiert ein openautomation/gefrierschrank.svg mit 1.5k(!) und ein fhemSVG/gefrierschrank_icon.svg mit 920k.
Die beiden Bilder legen nahe, dass einer vom anderen kopiert wurde.
Auf 32x32 schaut das kleine Bild mAn besser aus.
Nachtrag: Ich haette es ja denken koennen: die gleiche Situation mit solar.svg vs. solar_icon.svg.
ich sag´s, denn sie wissen nicht was sie tun, gerade wenn aus 1,5 KB 960 KB wird.
Das Problem ist, dass man sich als Anwender darauf verlässt, eingecheckte Icons ohne Einschränkungen nutzen zu können.
Ich gehe davon aus, dass die Zuständigen möglichst schnell diese Icons ersetzen. Und hier der Anfang der Liste :)
fhem@raspberrypi:~/www/images/fhemSVG$ ls -S -l
insgesamt 10084
-rw-r--r-- 1 fhem dialout 941642 Aug 17 2020 gefrierschrank_icon.svg
-rw-r--r-- 1 fhem dialout 423703 Aug 17 2020 sprinkler_icon.svg
-rw-r--r-- 1 fhem dialout 419312 Feb 3 2018 rc_TV1_on.svg
-rw-r--r-- 1 fhem dialout 270578 Aug 17 2020 kuehlschrank_small.svg
-rw-r--r-- 1 fhem dialout 235113 Aug 17 2020 it_raspberry.svg
-rw-r--r-- 1 fhem dialout 234856 Aug 17 2020 solar_icon.svg
-rw-r--r-- 1 fhem dialout 187891 Aug 17 2020 wintergarten_icon.svg
-rw-r--r-- 1 fhem dialout 177096 Aug 17 2020 kuehlschrank_big.svg
-rw-r--r-- 1 fhem dialout 95779 Aug 17 2020 springbrunnen_icon.svg
-rw-r--r-- 1 fhem dialout 69515 Aug 17 2020 it_raspberry_logo.svg
-rw-r--r-- 1 fhem dialout 64098 Feb 23 2021 Siemens_synco_QAX910.svg
-rw-r--r-- 1 fhem dialout 59586 Feb 23 2021 Botvac_VR200.svg
-rw-r--r-- 1 fhem dialout 59117 Aug 23 2019 air_compressor.svg
-rw-r--r-- 1 fhem dialout 58372 Feb 3 2018 DIN_rail_housing.svg
-rw-r--r-- 1 fhem dialout 54547 Dez 23 18:33 Gartenabfall.svg
-rw-r--r-- 1 fhem dialout 45633 Aug 17 2020 wasserzaehler_icon.svg
-rw-r--r-- 1 fhem dialout 37685 Aug 17 2020 stromzaehler_icon.svg
-rw-r--r-- 1 fhem dialout 34510 Feb 3 2018 fts_sunblind_50.svg
-rw-r--r-- 1 fhem dialout 34356 Feb 3 2018 fts_sunblind_80.svg
-rw-r--r-- 1 fhem dialout 33643 Feb 23 2021 krippe.svg
-rw-r--r-- 1 fhem dialout 33375 Feb 3 2018 fts_sunblind_0.svg
-rw-r--r-- 1 fhem dialout 33368 Feb 3 2018 fts_sunblind_40.svg
-rw-r--r-- 1 fhem dialout 33351 Feb 3 2018 fts_sunblind_10.svg
-rw-r--r-- 1 fhem dialout 33346 Feb 3 2018 fts_sunblind_60.svg
-rw-r--r-- 1 fhem dialout 33344 Feb 3 2018 fts_sunblind_30.svg
-rw-r--r-- 1 fhem dialout 33342 Feb 3 2018 fts_sunblind_20.svg
-rw-r--r-- 1 fhem dialout 33264 Feb 3 2018 fts_sunblind_90.svg
-rw-r--r-- 1 fhem dialout 33260 Feb 3 2018 fts_sunblind_70.svg
-rw-r--r-- 1 fhem dialout 30965 Feb 3 2018 sunblind_50.svg
-rw-r--r-- 1 fhem dialout 30837 Feb 3 2018 sunblind_80.svg
-rw-r--r-- 1 fhem dialout 29827 Feb 3 2018 sunblind_0.svg
-rw-r--r-- 1 fhem dialout 29827 Feb 3 2018 sunblind_60.svg
-rw-r--r-- 1 fhem dialout 29823 Feb 3 2018 sunblind_40.svg
-rw-r--r-- 1 fhem dialout 29803 Feb 3 2018 sunblind_10.svg
-rw-r--r-- 1 fhem dialout 29800 Feb 3 2018 sunblind_30.svg
-rw-r--r-- 1 fhem dialout 29792 Feb 3 2018 sunblind_20.svg
-rw-r--r-- 1 fhem dialout 29746 Feb 3 2018 sunblind_90.svg
-rw-r--r-- 1 fhem dialout 29741 Feb 3 2018 sunblind_70.svg
-rw-r--r-- 1 fhem dialout 24992 Feb 3 2018 fts_sunblind_100.svg
Zitat von: Damian am 02 April 2022, 14:13:56
ich sag´s, denn sie wissen nicht was sie tun, gerade wenn aus 1,5 KB 960 KB wird.
Das Problem ist, dass man sich als Anwender darauf verlässt, eingecheckte Icons ohne Einschränkungen nutzen zu können.
Ich gehe davon aus, dass die Zuständigen möglichst schnell diese Icons ersetzen. Und hier der Anfang der Liste :)
fhem@raspberrypi:~/www/images/fhemSVG$ ls -S -l
insgesamt 10084
-rw-r--r-- 1 fhem dialout 941642 Aug 17 2020 gefrierschrank_icon.svg
-rw-r--r-- 1 fhem dialout 423703 Aug 17 2020 sprinkler_icon.svg
-rw-r--r-- 1 fhem dialout 419312 Feb 3 2018 rc_TV1_on.svg
-rw-r--r-- 1 fhem dialout 270578 Aug 17 2020 kuehlschrank_small.svg
-rw-r--r-- 1 fhem dialout 235113 Aug 17 2020 it_raspberry.svg
-rw-r--r-- 1 fhem dialout 234856 Aug 17 2020 solar_icon.svg
-rw-r--r-- 1 fhem dialout 187891 Aug 17 2020 wintergarten_icon.svg
-rw-r--r-- 1 fhem dialout 177096 Aug 17 2020 kuehlschrank_big.svg
-rw-r--r-- 1 fhem dialout 95779 Aug 17 2020 springbrunnen_icon.svg
-rw-r--r-- 1 fhem dialout 69515 Aug 17 2020 it_raspberry_logo.svg
-rw-r--r-- 1 fhem dialout 64098 Feb 23 2021 Siemens_synco_QAX910.svg
-rw-r--r-- 1 fhem dialout 59586 Feb 23 2021 Botvac_VR200.svg
-rw-r--r-- 1 fhem dialout 59117 Aug 23 2019 air_compressor.svg
-rw-r--r-- 1 fhem dialout 58372 Feb 3 2018 DIN_rail_housing.svg
-rw-r--r-- 1 fhem dialout 54547 Dez 23 18:33 Gartenabfall.svg
Danke für den Tipp :-)
@Rudi: Kannst Du die paar SVG's eindampfen? Habe keine Inkscape
Gruß und Dank
Wuppi
Hallo,
Die Arbeit sollte (teilweise) schon mal gemacht worden sein.
https://forum.fhem.de/index.php/topic,12605.msg1119674.html#msg1119674 (https://forum.fhem.de/index.php/topic,12605.msg1119674.html#msg1119674)
Lg, Gerhard
Zitat@Rudi: Kannst Du die paar SVG's eindampfen? Habe keine Inkscape
Ich habe jetzt die u.g. Liste durchgearbeitet:
gefrierschrank_icon.svg 941642 => 1562 (aus openautomation)
sprinkler_icon.svg 423703 => 10736 (aus der verlinkten Diskussion)
rc_TV1_on.svg 419312 unveraendert, enthaelt ein Bitmap. Sollte mAn entfernt werden.
kuehlschrank_small.svg 270578 => 12550 (aus der verlinkten Diskussion)
it_raspberry.svg 235113 unveraendert, ist aber mAn als icon ungeeignet, sollte entfernt werden.
solar_icon.svg 234856 => 1776 (aus openautomation)
wintergarten_icon.svg 187891 => 16834 (aus der verlinkten Diskussion)
springbrunnen_icon.svg 95779 => 48808 (mit inkscape Ctrl-L)
Die Anderen werden nach inkscape Vereinfachung zwar etwas kleiner, aber auch etwas haesslicher, und die Ersparnis ist mAn nicht gerechtfertigt.
Beim Experimentieren mit kuehlschrank_big (habs in inkscape nachgemalt) habe ich gelernt, dass die standard FHEMWEB-Faerbe-Methode (fill:#000000 zu ersetzen) mit inkscape nicht intuitiv ist: man muss gefuellte Flaechen (wie rect) verwenden, statt dicke Linien zu malen.
Danach habe ich openautomation/gefrierschank.svg bewundert, und kapiert, dass es mit einem Texteditor erstellt wurde.
Ich habe daraufhin kuehlschrank_big.svg mit der gleichen Methode nachgebaut: aus 177096 Bytes sind 916 geworden.
@gestein: Danke fuer deine Arbeit!
Zitat von: rudolfkoenig am 06 April 2022, 12:43:43
Danach habe ich openautomation/gefrierschank.svg bewundert, und kapiert, dass es mit einem Texteditor erstellt wurde.
Ich habe daraufhin kuehlschrank_big.svg mit der gleichen Methode nachgebaut: aus 177096 Bytes sind 916 geworden.
Wie effizient ein SVG-Icon erstellt ist, sieht man sofort, wenn man sich den HTML-Code anschaut. Die von Hand "programmierten" Icons benutzen effizient HTML-Elemente, wie Kreise, Rechtecke, Linien usw. Alles was automatisch generiert ist, bedient sich Sachen wie path, um von Pixel zu Pixel Linien zu ziehen oder einzelne Pixel zu setzen. Und es leuchtet sofort ein, dass z. B. einen Kreis aus Linien zu bauen, keine gute Idee sein kann :)
Ich muss den Thread noch mal aufwärmen, weil ich wieder Verbindungabbrüche habe.
Was mir aufgefallen ist, dass addToWriteBuffer mehrfach für die gleichen IDs aufgerufen wird.
Im DOIF habe ich folgenden Code für das Update von Tabellenzellen:
map {
FW_directNotify("#FHEMWEB:$_", "doifUpdateCell('$pn','doifId','$doifId','$value','display:inline-table;$style')","");
} devspec2array("TYPE=FHEMWEB") if ($value ne "");
Beim List TYPE=FHEMWEB kommt:
WEBHOME
WEBHOME_127.0.0.1_43716
WEBHOME_192.168.178.133_49415
WEBHOME_192.168.178.133_49416
WEBHOME_192.168.178.133_49417
WEBIconia
Geöffnet habe ich nur eine FHEM-Seite im Browser auf diesem PC.
In addToWriteBuffer habe ich eine Testausgabe mit den ersten Zeichen der Nachricht eingebaut und den Buffer auf 2 MB erhöht, um zu sehen wie weit der gefüllt wird:
if(!defined($hash->{$wbName})) {
$hash->{$wbName} = $txt;
} elsif($nolimit || length($hash->{$wbName}) < 2048000) {
$hash->{$wbName} .= $txt;
Log (1, "len wbName: ".length($hash->{$wbName})." len txt: ".length($txt)." txt: ".substr($txt,0,300));
} else {
return 0;
}
so sehen die Ausgaben von zwei Zellen-Updates:
2023.04.30 20:38:16.421 1: len wbName: 968787 len txt: 14903 txt: ["#FHEMWEB:WEBHOME","doifUpdateCell('Aktuell','doifId','Aktuell_uiTable_c_6_0_0_0','<svg xmlns=\u0022http://www.w3.org/2000/svg\u0022 viewBox=\u002210 0 180 112\u0022 width=\u0022234\u0022 height=\u0022145\u0022 style=\u0022width:234px; height:145px;\u0022><defs><linearGradient id=\u0022gradcardback
2023.04.30 20:38:16.423 1: len wbName: 968787 len txt: 14903 txt: ["#FHEMWEB:WEBHOME","doifUpdateCell('Aktuell','doifId','Aktuell_uiTable_c_6_0_0_0','<svg xmlns=\u0022http://www.w3.org/2000/svg\u0022 viewBox=\u002210 0 180 112\u0022 width=\u0022234\u0022 height=\u0022145\u0022 style=\u0022width:234px; height:145px;\u0022><defs><linearGradient id=\u0022gradcardback
2023.04.30 20:38:16.425 1: len wbName: 987954 len txt: 14903 txt: ["#FHEMWEB:WEBHOME","doifUpdateCell('Aktuell','doifId','Aktuell_uiTable_c_6_0_0_0','<svg xmlns=\u0022http://www.w3.org/2000/svg\u0022 viewBox=\u002210 0 180 112\u0022 width=\u0022234\u0022 height=\u0022145\u0022 style=\u0022width:234px; height:145px;\u0022><defs><linearGradient id=\u0022gradcardback
2023.04.30 20:38:16.442 1: len wbName: 985084 len txt: 16297 txt: ["#FHEMWEB:WEBHOME","doifUpdateCell('di_counter_new','doifId','di_counter_new_uiTable_c_4_4_0_0','<svg xmlns=\u0022http://www.w3.org/2000/svg\u0022 viewBox=\u002210 0 200 112\u0022 width=\u0022260\u0022 height=\u0022145\u0022 style=\u0022width:260px; height:145px;\u0022><defs><linearGradient id=\u00
2023.04.30 20:38:16.445 1: len wbName: 985084 len txt: 16297 txt: ["#FHEMWEB:WEBHOME","doifUpdateCell('di_counter_new','doifId','di_counter_new_uiTable_c_4_4_0_0','<svg xmlns=\u0022http://www.w3.org/2000/svg\u0022 viewBox=\u002210 0 200 112\u0022 width=\u0022260\u0022 height=\u0022145\u0022 style=\u0022width:260px; height:145px;\u0022><defs><linearGradient id=\u00
2023.04.30 20:38:16.447 1: len wbName: 1004251 len txt: 16297 txt: ["#FHEMWEB:WEBHOME","doifUpdateCell('di_counter_new','doifId','di_counter_new_uiTable_c_4_4_0_0','<svg xmlns=\u0022http://www.w3.org/2000/svg\u0022 viewBox=\u002210 0 200 112\u0022 width=\u0022260\u0022 height=\u0022145\u0022 style=\u0022width:260px; height:145px;\u0022><defs><linearGradient id=\u00
D.h. das ZellenUpdate wird statt einmal drei mal pro Zelle ausgeführt und bei mehreren SVG-Diagrammen kommt es im originalen fhem.pl zum Verbindungsabbruch, weil 1 MB überschritten wird.
Ich habe jetzt noch den Hash-Namen in der Ausgabe hinzugefügt:
2023.05.01 12:34:27.828 1: name:WEBHOME_127.0.0.1_32986 len wbName:1010125 len txt:16303 txt:["#FHEMWEB:WEBHOME","doifUpdateCell('di_counter_new','doifId','di_counter_new_uiTable_c_4_4_0_0','<svg xmlns=\u0022http:
2023.05.01 12:34:27.830 1: name:WEBHOME_192.168.178.80_52735 len wbName:1009101 len txt:16303 txt:["#FHEMWEB:WEBHOME","doifUpdateCell('di_counter_new','doifId','di_counter_new_uiTable_c_4_4_0_0','<svg xmlns=\u0022http:
2023.05.01 12:34:27.832 1: name:WEBHOME_192.168.178.133_56294 len wbName:1009101 len txt:16303 txt:["#FHEMWEB:WEBHOME","doifUpdateCell('di_counter_new','doifId','di_counter_new_uiTable_c_4_4_0_0','<svg xmlns=\u0022http:
Es handelt sich offenbar um verschiedene Verbindungen (es waren bewusst zwei Browser von verschiedenen Rechnern auf der gleichen Seite) - das wäre dann ok. Sollte ich ggf. Update auf localhost unterbinden? Das würde aber das Problem nicht beheben.
Das Problem ist, dass eine SVG-Grafik je nach Aufwand über 30 KB hat (mit icons noch mehr), wenn man nun über dreißig Grafiken auf einem Bildschirm hat, dann kommt man schon an die Grenze.
Der Aufbau einer solchen kompletten Seite (offenbar mehrere MB groß) dauert lediglich Bruchteile einer Sekunde, dann erscheint es nicht sinnvoll Teile davon (ID-Update) bereits durch 1 MB zu begrenzen.
Die nächste Frage stellt sich, wie lange würden 2 MB halten?
Bei mir ging der Buffer bereits auf 1,6 MB hoch.
Oder braucht man eine andere Erkennung von toten Verbindung?
Normalerweise wird eine Seite vom FHEMWEB und den betroffenen Modulen berechnet, und komplett an dem Browser geliefert.
Wenn man die Seite dynamisch aufbauen will, dann sollte ein JavaScript die Daten anfordern, z.Bsp. werden die SVGs bei plotEmbed=2 so geladen.
FW_directNotify ist nicht fuer inkrementellen Aufbau der Seite gedacht, sondern um Statusaenderungen mitzuteilen, oder ein Dialog asynchron einzublenden.
Die 1MB greift auch nur beim inkrementellen erweitern der Daten, d.h. nicht beim ersten mal.
Naja, es geht ja hier nur um Statusänderungen und nicht um einen neuen Seitenaufbau.
Das Problem wird einfach durch mehrere Events in einem Eventblock ausgelöst.
Vier Sensoren hängen an einem Device, wenn dieses im Minutentakt die Zählerdaten übermittelt, dann sollen deren Status und alles was damit zusammenhängt aktualisiert werden.
Es wird also keine neue Seite aufgebaut.
Da hier aber kein Text sich ändert, sondern ggf. auch ein Diagramm, so muss das Diagramm (oder zumindest dessen Daten) übertragen werden, was mit 20-30KB nicht mehr als ein SVG-Icon ist.
Das Problem tritt natürlich nur dann auf, wenn zufälligerweise viele Änderung auf einer Seite ausgelöst durch einen Eventblock zu erfolgen haben (siehe Anhang).
Spricht etwas gegen die einfache Lösung den Buffer auf 2 MB zu erhöhen?