Freezes durch Abfrage mehrere MQTT2-Device?

bmwfan · 08 Januar 2021, 17:54:10

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:

Code Auswählen

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.

Code Auswählen

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

amenomade · 09 Januar 2021, 03:26:19

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?

bmwfan · 09 Januar 2021, 17:58:15

Das Log-File ab 16:57:

Code Auswählen

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.

Code Auswählen

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

amenomade · 09 Januar 2021, 18:24:15

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

bmwfan · 10 Januar 2021, 12:25:24

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.

Code Auswählen

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

Code Auswählen


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

amenomade · 10 Januar 2021, 17:04:48

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?

bmwfan · 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.

Damian · 10 Januar 2021, 17:20:04

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.

bmwfan · 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.

Damian · 10 Januar 2021, 17:44:32

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.

Beta-User · 10 Januar 2021, 18:01:25

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.

bmwfan · 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?

amenomade · 10 Januar 2021, 19:09:41

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.