Hallo,
ich habe das Problem, dass bei der Abfrage mehrerer Werte aus MQTT2-Datenübertragungen in einem DOIF (Ansteuerung Zirkulationspumpe) regelmäßig Freezes von bis zu 30 sec. Dauer erfolgen und mein HM485, der zur Jalousiesteuerung verwendet wird, einen reboot macht. Im ungünstigsten Fall, so heute, fahren dann die Jalousien nicht.
Auszug aus dem Log:
2021.01.08 17:00:27.499 1: 192.168.178.47:1000 disconnected, waiting to reappear (HM485_LAN)
2021.01.08 17:00:27.997 1: [Freezemon] myFreezemon: possible freeze starting at 17:00:05, delay is 22.997 possibly caused by: tmr-DOIF_SleepTrigger(di_ZirkuPumpe_AN)
2021.01.08 17:00:28.307 3: HM485_LAN: connected to device 192.168.178.47:1000
2021.01.08 17:00:28.307 1: 192.168.178.47:1000 reappeared (HM485_LAN)
2021.01.08 17:00:28.550 3: HM485_LAN: Lan Device Information
2021.01.08 17:00:28.551 3: HM485_LAN: Protocol-Version: 01
2021.01.08 17:00:28.551 3: HM485_LAN: Interface-Type: eQ3-HMW-LGW
2021.01.08 17:00:28.551 3: HM485_LAN: Firmware-Version: 1.0.4
2021.01.08 17:00:28.551 3: HM485_LAN: Serial-Number: LEQ0636394
2021.01.08 17:00:28.551 3: HM485_LAN: Initialize the interface
2021.01.08 17:04:20.637 3: WetterNetatmo: poll (ACCOUNT)
Zur Erklärung: Die Zirku-Pumpe hängt über eine 1-wire Anbindung (Schaltung von PAH) an einem Raspi (01) im Technikraum, der über MQTT2 mit dem Hauptraspi (03B) kommuniziert. Ich frage im DOIF der Zirku-Pumpe im Raspi 03B die Speichertemperatur (kommt über ebusd und MQTT2) sowie die Vor- und Rücklauftemperatur (1-wire Sensoren über MQTT2) ab, erstelle den Schaltbefehl und sende ihn über MQTT2 an den Raspi01.
Internals:
DEF ([SteigStr:state] eq "home" and [?MQTT2_RPI02:VT_Zirku_RPI02] < 43 and [?MQTT2_ebusd_zeo:SpeichertempOben] > 43) (set du_ZirkuStatus_set EIN) (set du_ZirkuStatus_set AUS) ## Jemand kommt heim und Vorlauf kalt und Speichertemp hoch genug: Pumpe für WAIT-Sekunden an
DOELSEIF ([?SteigStr:state] eq "home" and [?MQTT2_RPI02:VT_Zirku_RPI02] < 43 and [?MQTT2_ebusd_zeo:SpeichertempOben] > 35 and ([de_Bew_OG_Bad_Motion] eq "motion" or [Licht_BadOG_Spiegel] eq "on")) (set du_ZirkuStatus_set EIN) (set du_ZirkuStatus_set AUS)## Jemand daheim und Bewegung oder Licht im Bad UND VT-Temp < X °C und Speichertemp hoch genug: Pumpe für WAIT-Sekunden EIN. CMD==1.1 erreicht Verlängerung des Timers
DOELSEIF ([?SteigStr:state] eq "home" and [?MQTT2_RPI02:VT_Zirku_RPI02] < 43 and [?MQTT2_ebusd_zeo:SpeichertempOben] > 35 and [?MQTT2_RPI02:RT_Zirku_RPI02] < 30 and ([05:10-7:00,+:45|Mo Di Mi Do Fr] or [07:00-8:30,+:30|WE] or [17:00-22:00,+:45])) (set du_ZirkuStatus_set EIN) (set du_ZirkuStatus_set AUS) ## Jemand Zuhause und Einschaltzeit UND VT-Temp < X °C UND RT-Temp < Y °C: Pumpe für WAIT-Sekunden EIN
## DOELSEIF ([?SteigStr:state] eq "home" and [?MQTT2_RPI02:VT_Zirku_RPI02] < 48 and [?MQTT2_RPI02:RT_Zirku_RPI02] < 32 and ([05:10-7:00,+:45|Mo Di Mi Do Fr] or [07:00-8:30,+:30|WE] or [17:00-22:00,+:45|Mo Di Mi Do Fr WE])) (set du_ZirkuStatus_set EIN) (set du_ZirkuStatus_set AUS) ## Jemand Zuhause und Einschaltzeit UND VT-Temp < X °C UND RT-Temp < Y °C: Pumpe für WAIT-Sekunden EIN
FUUID 5c8373ac-f33f-6b6f-7d37-f3b3bb5aac357c84
MODEL FHEM
NAME di_ZirkuPumpe_AN
NOTIFYDEV SteigStr,Licht_BadOG_Spiegel,global,de_Bew_OG_Bad_Motion
NR 1729
NTFY_ORDER 50-di_ZirkuPumpe_AN
STATE Zeit AUS
TYPE DOIF
VERSION 23235 2020-11-25 22:42:28
READINGS:
2021-01-08 17:30:05 Device Licht_BadOG_Spiegel
2021-01-08 17:07:27 cmd 3.2
2021-01-08 17:07:27 cmd_event timer_7
2021-01-08 17:07:27 cmd_nr 3
2021-01-08 17:07:27 cmd_seqnr 2
2021-01-08 17:30:05 e_Licht_BadOG_Spiegel_STATE off
2021-01-07 12:49:40 e_SteigStr_state home
2021-01-08 17:05:03 e_de_Bew_OG_Bad_Motion_STATE noMotion
2021-01-03 10:39:43 mode enabled
2021-01-08 17:07:27 state Zeit AUS
2021-01-08 07:00:00 timer_01_c03 09.01.2021 05:10:00|MoDiMiDoFr
2021-01-08 07:00:00 timer_02_c03 09.01.2021 07:00:00|MoDiMiDoFr
2021-01-08 08:30:00 timer_04_c03 09.01.2021 07:00:00|WE
2021-01-08 08:30:00 timer_05_c03 09.01.2021 08:30:00|WE
2021-01-07 22:00:00 timer_07_c03 08.01.2021 17:00:00
2021-01-07 22:00:00 timer_08_c03 08.01.2021 22:00:00
2021-01-08 17:00:00 timer_09_c03 08.01.2021 17:45:00
2021-01-08 17:07:27 wait_timer no timer
Regex:
accu:
cond:
Licht_BadOG_Spiegel:
0:
1:
&STATE ^Licht_BadOG_Spiegel$
2:
SteigStr:
0:
state ^SteigStr$:^state:
1:
2:
de_Bew_OG_Bad_Motion:
0:
1:
&STATE ^de_Bew_OG_Bad_Motion$
2:
attr:
cmdState:
0:
Home EIN
Home AUS
1:
Bad EIN
Bad AUS
2:
Zeit EIN
Zeit AUS
wait:
0:
0
360
1:
0
120
2:
rand(5)
420
waitdel:
condition:
0 ::ReadingValDoIf($hash,'SteigStr','state') eq "home" and ::ReadingValDoIf($hash,'MQTT2_RPI02','VT_Zirku_RPI02') < 43 and ::ReadingValDoIf($hash,'MQTT2_ebusd_zeo','SpeichertempOben') > 43
1 ::ReadingValDoIf($hash,'SteigStr','state') eq "home" and ::ReadingValDoIf($hash,'MQTT2_RPI02','VT_Zirku_RPI02') < 43 and ::ReadingValDoIf($hash,'MQTT2_ebusd_zeo','SpeichertempOben') > 35 and (::InternalDoIf($hash,'de_Bew_OG_Bad_Motion','STATE') eq "motion" or ::InternalDoIf($hash,'Licht_BadOG_Spiegel','STATE') eq "on")
2 ::ReadingValDoIf($hash,'SteigStr','state') eq "home" and ::ReadingValDoIf($hash,'MQTT2_RPI02','VT_Zirku_RPI02') < 43 and ::ReadingValDoIf($hash,'MQTT2_ebusd_zeo','SpeichertempOben') > 35 and ::ReadingValDoIf($hash,'MQTT2_RPI02','RT_Zirku_RPI02') < 30 and (::DOIF_time($hash,0,1,$wday,$hms,"MoDiMiDoFr") or ::DOIF_time($hash,3,4,$wday,$hms,"WE") or ::DOIF_time($hash,6,7,$wday,$hms))
days:
0 MoDiMiDoFr
1 MoDiMiDoFr
2 MoDiMiDoFr
3 WE
4 WE
5 WE
do:
0:
0 set du_ZirkuStatus_set EIN
1 set du_ZirkuStatus_set AUS
1:
0 set du_ZirkuStatus_set EIN
1 set du_ZirkuStatus_set AUS
2:
0 set du_ZirkuStatus_set EIN
1 set du_ZirkuStatus_set AUS
3:
helper:
DEVFILTER ^global$|^SteigStr$|^Licht_BadOG_Spiegel$|^de_Bew_OG_Bad_Motion$
NOTIFYDEV global|SteigStr|Licht_BadOG_Spiegel|de_Bew_OG_Bad_Motion
event 6.LEVEL: off,5.LEVEL: off,hmstate: off
globalinit 1
last_timer 9
sleepdevice timer_7
sleepsubtimer -1
sleeptimer -1
timerdev
timerevent timer_7
triggerDev Licht_BadOG_Spiegel
timerevents:
timer_7
timereventsState:
timer_7
triggerEvents:
6.LEVEL: off
5.LEVEL: off
hmstate: off
triggerEventsState:
6.LEVEL: off
5.LEVEL: off
hmstate: off
internals:
all de_Bew_OG_Bad_Motion:STATE Licht_BadOG_Spiegel:STATE
interval:
0 -1
1 0
3 -1
4 3
6 -1
7 6
intervalfunc:
2 ::DOIF_time($hash,0,1,$wday,$hms,"MoDiMiDoFr")
5 ::DOIF_time($hash,3,4,$wday,$hms,"WE")
8 ::DOIF_time($hash,6,7,$wday,$hms)
intervaltimer:
0 2
1 2
3 5
4 5
6 8
7 8
localtime:
0 1610165400
1 1610172000
3 1610172000
4 1610177400
6 1610121600
7 1610139600
8 1610124300
readings:
all SteigStr:state
realtime:
0 05:10:00
1 07:00:00
3 07:00:00
4 08:30:00
6 17:00:00
7 22:00:00
8 17:45:00
time:
0 05:10:00
1 7:00
2 +:45
3 07:00:00
4 8:30
5 +:30
6 17:00:00
7 22:00:00
8 +:45
timeCond:
0 2
1 2
2 2
3 2
4 2
5 2
6 2
7 2
8 2
timer:
0 0
1 0
2 0
3 0
4 0
5 0
6 0
7 0
8 0
timers:
2 0 1 2 3 4 5 6 7 8
trigger:
triggertime:
1610124300:
localtime 1610124300
hash:
1610139600:
localtime 1610139600
hash:
1610165400:
localtime 1610165400
hash:
1610172000:
localtime 1610172000
hash:
1610177400:
localtime 1610177400
hash:
uiState:
uiTable:
Attributes:
cmdState Home EIN, Home AUS | Bad EIN, Bad AUS | Zeit EIN, Zeit AUS
comment 30.12.20: Abfrage Speichertemperatur ergänzt, da ansonsten bei zu niedriger Speichertemp. die Pumpe immer läuft.
do always
room 2.1_OG_Bad,3.4_Technik,9.8.1_DOIF
timerWithWait 1
verbose 5
wait 0,360:0,120:rand(5),420
Gehe ich richtig in der Annahme, dass die Abfrage der MQTT2-Werte den Freeze verursachen?
Wenn ja wie kann ich das umgehen? Wäre eine Lösung, die Werte in Dummies oder eine ReadingsGroup zu schreiben und diese dann abzufragen? Es sind ja keine zeitkritischen Werte und würde somit auch funktionieren.
Grüße Jürgen
Grüße Jürgen
Ob Du ein Reading eines MQTT-Devices oder ein Reading eines dummys abfragst, macht es keinen Unterschied.
Ich glaube, dass was freezemon zeigt eher eine Konzequenz als die Ursache ist.
Kann man die Log ab 17:00:00 sehen?
Das Log-File ab 16:57:
2021.01.08 16:57:20.480 3: HMinfo hm get:update :
2021.01.08 16:57:20.481 3: CUL_HM set ActionDetector update noArg
2021.01.08 16:57:20.496 3: CUL_HM set VCCU update noArg
2021.01.08 16:57:51.035 1: [Freezemon] myFreezemon: possible freeze starting at 16:57:50, delay is 1.032 possibly caused by: tmr-FRITZBOX_Readout_Start(N/A) tmr-FRITZBOX_Readout_Start(N/A)
2021.01.08 16:59:31.149 3: MQTT2_DEVICE set GSP1_Lampe_Bewohner5 on
2021.01.08 16:59:31.187 3: MQTT2_DEVICE set GSP1_Lampe_Bewohner3 on
2021.01.08 17:00:27.499 1: 192.168.178.47:1000 disconnected, waiting to reappear (HM485_LAN)
2021.01.08 17:00:27.997 1: [Freezemon] myFreezemon: possible freeze starting at 17:00:05, delay is 22.997 possibly caused by: tmr-DOIF_SleepTrigger(di_ZirkuPumpe_AN)
2021.01.08 17:00:28.307 3: HM485_LAN: connected to device 192.168.178.47:1000
2021.01.08 17:00:28.307 1: 192.168.178.47:1000 reappeared (HM485_LAN)
2021.01.08 17:00:28.550 3: HM485_LAN: Lan Device Information
2021.01.08 17:00:28.551 3: HM485_LAN: Protocol-Version: 01
2021.01.08 17:00:28.551 3: HM485_LAN: Interface-Type: eQ3-HMW-LGW
2021.01.08 17:00:28.551 3: HM485_LAN: Firmware-Version: 1.0.4
2021.01.08 17:00:28.551 3: HM485_LAN: Serial-Number: LEQ0636394
2021.01.08 17:00:28.551 3: HM485_LAN: Initialize the interface
2021.01.08 17:04:20.637 3: WetterNetatmo: poll (ACCOUNT)
Ich musste heute morgen um 04:20 ins Bad und da springt über den Bewegungsmelder auch die Zirkulationspumpe an. Wieder ein Ausstieg des HM485. Ich habe den Eindruck, dass der Raspi dann auf irgendeine Rückmeldung wartet und daher nicht mehr rechtzeitig zum Programmteil des HM485 kommt, kenne mich aber in der Abarbeitung eines FHEM-Programmes auf dem raspi nicht aus.
2021.01.09 04:17:28.401 3: HMinfo hm get:update :
2021.01.09 04:17:28.403 3: CUL_HM set ActionDetector update noArg
2021.01.09 04:17:28.423 3: CUL_HM set VCCU update noArg
2021.01.09 04:20:21.971 1: [Freezemon] myFreezemon: possible freeze starting at 04:19:48, delay is 33.97 possibly caused by: tmr-PRESENCE_StartLocalScan(Handy_Bewohner3_LP) tmr-HOMEMODE_GetUpdate(Home)
2021.01.09 04:20:22.180 1: 192.168.178.47:1000 disconnected, waiting to reappear (HM485_LAN)
2021.01.09 04:20:23.741 1: [Freezemon] myFreezemon: possible freeze starting at 04:20:22, delay is 1.739 possibly caused by: tmr-CUL_HM_procQs(N/A) tmr-SamsungAV_Init(SamsungQ85) tmr-MQTT::GENERIC_BRIDGE::timerProc(myMQTT_GenericBridge) tmr-RESIDENTStk_DurationTimer(rr_Bewohner1_DurationTimer) tmr-SYSMON_Update(sysmonRPI1) tmr-RESIDENTStk_DurationTimer(rr_Bewohner2_DurationTimer) tmr-RESIDENTStk_DurationTimer(rr_Bewohner3_DurationTimer) tmr-MQTT2_SERVER_keepaliveChecker(MQTT2_FHEM_Server) tmr-HM485_LAN_KeepAlive(HM485_LAN) tmr-HttpUtils_Err(N/A) tmr-RESIDENTStk_DurationTimer(rr_Bewohner4_DurationTimer) tmr-RESIDENTStk_DurationTimer(SteigStr_DurationTimer) tmr-CODE(0x45514b0)(GetUpdate) tmr-ENIGMA2_GetStatus(vuduo2) tmr-HMUARTLGW_CheckCredits(myHMUARTGPIO) tmr-Robonect_GetUpdate(Robby) tmr-PRESENCE_StartLocalScan(Handy_Bewohner5) tmr-PRESENCE_StartLocalScan(Handy_Bewohner5_LP)
2021.01.09 04:20:24.015 3: HM485_LAN: connected to device 192.168.178.47:1000
2021.01.09 04:20:24.015 1: 192.168.178.47:1000 reappeared (HM485_LAN)
2021.01.09 04:20:24.771 3: HM485_LAN: Lan Device Information
2021.01.09 04:20:24.771 3: HM485_LAN: Protocol-Version: 01
2021.01.09 04:20:24.771 3: HM485_LAN: Interface-Type: eQ3-HMW-LGW
2021.01.09 04:20:24.771 3: HM485_LAN: Firmware-Version: 1.0.4
2021.01.09 04:20:24.772 3: HM485_LAN: Serial-Number: LEQ0636394
2021.01.09 04:20:24.772 3: HM485_LAN: Initialize the interface
2021.01.09 04:27:28.510 3: HMinfo hm get:update :
Wenn ich das Problem nicht beseitigen kann, muss ich die Ansteuerung der ZirkuPumpe ausschalten oder ändern. Wäre sehr nachteilig, da ich damit dafür sorgen will, dass warmes Wasser zur Verfügung steht ohne dass die Pumpe ständig läuft oder dass zuerst ewig (sicher 2 Minuten bei uns) kaltes Wasser kommt.
Grüße Jürgen
Da gibt es nicht nur den DOIF, der ein "possible freeze" meldet, sondern viele andere.
Vielleicht kannst Du mit apptime etwas sehen. https://fhem.de/commandref.html#apptime
Habe jetzt über Nacht apptime laufen lassen. Wie vermutet ist es die Zirku-Pumpe, aber ich verstehe nicht warum. Die Timer, die ich gesetzt habe, stoppen doch FHEM nicht in der Programmausführung sondern laufen im Hintergrund.
active-timers: 234; max-active timers: 264; max-timer-load: 45 min-tmrHandlingTm: 0.0ms; max-tmrHandlingTm: 38519.0ms; totAvgDly: 23.6ms
name function max count total average maxDly avgDly TS Max call param Max call
tmr-DOIF_SleepTrigger HASH(0x6483a00) 38518 5 39887.26 7977.45 21367 19025 10.01. 07:00:43 HASH(di_ZirkuPumpe_AN)
du_ZirkuStatus_set dummy_Set 38484 8 60939.77 7617.47 0.00 0.00 10.01. 07:00:43 HASH(du_ZirkuStatus_set); du_ZirkuStatus_set; EIN
myMQTT_GenericBridge MQTT::GENERIC_BRIDGE::Notify 38474 121236 71649.00 0.59 0.00 0.00 10.01. 07:00:43 HASH(myMQTT_GenericBridge); HASH(du_ZirkuStatus_set)
CUL_0 CUL_Read 11523 13253 373343.43 28.17 0.00 0.00 10.01. 11:59:46 HASH(CUL_0)
di_ZirkuPumpe_AN DOIF_Notify 11358 3396 22550.89 6.64 0.00 0.00 10.01. 11:59:46 HASH(di_ZirkuPumpe_AN); HASH(de_Bew_OG_Bad_Motion)
di_Bad_OG_Licht_Spiegel DOIF_Notify 3560 2613 8801.71 3.37 0.00 0.00 10.01. 07:55:09 HASH(di_Bad_OG_Licht_Spiegel); HASH(de_Bew_OG_Bad_Motion)
FileLog_Zirkupumpe FileLog_Log 3179 121236 122217.01 1.01 0.00 0.00 10.01. 07:00:17 HASH(FileLog_Zirkupumpe); HASH(myMQTT_GenericBridge)
di_check_batterie DOIF_Notify 2542 121236 97641.71 0.81 0.00 0.00 10.01. 07:00:23 HASH(di_check_batterie); HASH(myMQTT_GenericBridge)
eventTypes eventTypes_Notify 2519 121236 37583.99 0.31 0.00 0.00 10.01. 07:00:26 HASH(eventTypes);
Sollte ich zusätzlich die Ballung an Ausführungen um 07:00 etwas auseinanderziehen? Kann das eine Verbesserung bringen wobei es sicherlich nicht das Hauptproblem mit der Zirku-Pumpe löst.
Grüße Jürgen
Zitat von: bmwfan am 10 Januar 2021, 12:25:24
Die Timer, die ich gesetzt habe, stoppen doch FHEM nicht in der Programmausführung sondern laufen im Hintergrund.
Wie genau hast Du das gemacht?
Gemacht? Das DOIF aus Post 1 sehe ich als Verursacher des ganzen Problems.
Ich vermute nur, da ich viele DOIF mit Timern habe und keines FHEM stoppt, dass Timer von DOIF keine Abarbeitungsstop des Programmes zur Folge haben. Ich muss aber sagen, dass ich mich früher beruflich nur mit Assembler-Programmierung beschäftigt habe, andere Programmiersprachen nicht kenne und daher nur Vermutungen anstellen kann, wie FHEM die Befehle abarbeitet.
Zitat von: bmwfan am 10 Januar 2021, 17:09:04
Gemacht? Das DOIF aus Post 1 sehe ich als Verursacher des ganzen Problems.
Ich vermute nur, da ich viele DOIF mit Timern habe und keines FHEM stoppt, dass Timer von DOIF keine Abarbeitungsstop des Programmes zur Folge haben. Ich muss aber sagen, dass ich mich früher beruflich nur mit Assembler-Programmierung beschäftigt habe, andere Programmiersprachen nicht kenne und daher nur Vermutungen anstellen kann, wie FHEM die Befehle abarbeitet.
Im DOIF werden Timer über FHEM-Standardmechanismen gesetzt. Ich glaube nicht, dass es am Timer liegt.
Ich hatte vernutet, dass FHEM auf eine Antwort des Devices warete, wenn es abgefragt wird. Da ich mehrere Temperaturen ausd er MQTT-Datenübertragung abfrage, ging mein Verdacht in diese Richtung.
Um 07:00 spricht cmd3 an, das 3 Kriterien aus MQTT-Übertragungen abfragt. 2 sind Temperaturen, die mit 1-wire gemessen werden und ein Kriterium kommt vom ebusd der Heizung. Gesetzt wird nur ein Dummy und nach einem Timer wieder rückgesetzt. Das Setzen und Rücksetzen.
Kann es etwas mit timerwithwait == 1 oder den wait-timern des cmd3 "rand(5),420" zu tun haben? 420 soll die Laufzeit der Zirkupumpe sein und rand(5) hatte ich gesetzt, da ich vermutet hatte dass um 07:00 zu viele DOIF starten und die Freeze daher kommen.
Zitat von: bmwfan am 10 Januar 2021, 17:32:21
Ich hatte vernutet, dass FHEM auf eine Antwort des Devices warete, wenn es abgefragt wird. Da ich mehrere Temperaturen ausd er MQTT-Datenübertragung abfrage, ging mein Verdacht in diese Richtung.
Um 07:00 spricht cmd3 an, das 3 Kriterien aus MQTT-Übertragungen abfragt. 2 sind Temperaturen, die mit 1-wire gemessen werden und ein Kriterium kommt vom ebusd der Heizung. Gesetzt wird nur ein Dummy und nach einem Timer wieder rückgesetzt. Das Setzen und Rücksetzen.
Kann es etwas mit timerwithwait == 1 oder den wait-timern des cmd3 "rand(5),420" zu tun haben? 420 soll die Laufzeit der Zirkupumpe sein und rand(5) hatte ich gesetzt, da ich vermutet hatte dass um 07:00 zu viele DOIF starten und die Freeze daher kommen.
DOIF_SleepTrigger ist die Ausführung des verzögerten Befehls. Man kann davon ausgeben, das DOIF beim Absetzen des Befehls hängt.
Zitat von: bmwfan am 10 Januar 2021, 17:32:21
Ich hatte vernutet, dass FHEM auf eine Antwort des Devices warete, wenn es abgefragt wird. Da ich mehrere Temperaturen ausd er MQTT-Datenübertragung abfrage, ging mein Verdacht in diese Richtung.
Da klingt ein wenig die Fehlvorstellung durch, dass da erst irgendeine Gegenstelle kontaktiert werden würde. Es wird hier aber afaik nur ein Reading gelesen (wie schon von amenomade erläutert), und selbst wenn z.B. ein "get" aufgerufen würde: MQTT läuft aber in der Regel völlig asynchron, es würde dann also die Message versendet und dann gewarten ob/was zurückkommt, und dann würde man durch eine spätere ReadingsVa()-Abfrage den aktuellen Wert _wie er FHEM bekannt ist_ mitgeteilt bekommen.
Dann war ich da doch auf einer völlig falschen Fährte, wobei die das Problem für mich schon erklärt hätte.
Woher kommen aber dann die Freeze um 07:00 Uhr, wenn die Zirku-Pumpe über dieses DOIF angeht und apptime ja auch die Verzögerung von der Zirku-Üumpe kommend anzeigt?
Zitat von: bmwfan am 10 Januar 2021, 19:06:03
Dann war ich da doch auf einer völlig falschen Fährte, wobei die das Problem für mich schon erklärt hätte.
Woher kommen aber dann die Freeze um 07:00 Uhr, wenn die Zirku-Pumpe über dieses DOIF angeht und apptime ja auch die Verzögerung von der Zirku-Üumpe kommend anzeigt?
Also, wie schon gesagt: vermutlich Symptom und nicht Ursache.
Wenn FHem aus irgendeinem Grund lahm ist, dann reagieren alle Fhem-Devices, es sei DOIF oder andere, auch lahm und dann melden freezemon und apptime lange Antwortzeiten.