[36_Senec.pm] FHEM module zur Integration eines SENEC Speicher und MeinSenec

[HGButte]

Hallo Hubert und Uwe,

ich habe die neue Version V2.20.2 neben meiner 2. stufigen Python-Variante installiert
und bin auf folgendes Problem gestoßen.
Ich habe freeze-Einträge mit hohen Werten im System (siehe Bild).
Das Intervall der V2.20.2 beträgt jetzt 2,5 Stunden - vorher jede Stunde dann waren es noch mehr freeze Einträge.
Ich weiß, das der API-Aufruf manchmal 3 bis 4 Sekunden dauert - je nach Laune ....
Gibt es eine Idee die Abfragen - asynchron oder im Hintergrund - zu starten?

Code Auswählen Erweitern

1 - 2025-10-15_[Log]: s:20:35:57 e:20:36:06 f:9.22 d:tmr-FHEM::Senec::periodicCallLocal(N/A)

1 - 2025-10-16_[Log]: s:01:27:37 e:01:27:45 f:8.553 d:tmr-FHEM::Senec::periodicCallLocal(N/A)

1 - 2025-10-16_[Log]: s:03:35:00 e:03:35:03 f:3.156 d:tmr-at_Exec(at_zwave_fix)

1 - 2025-10-16_[Log]: s:06:19:17 e:06:19:25 f:8.622 d:tmr-FHEM::Senec::periodicCallLocal(N/A)

1 - 2025-10-16_[Log]: s:11:10:57 e:11:11:05 f:8.53 d:tmr-FHEM::Senec::periodicCallLocal(N/A)

1 - 2025-10-16_[Log]: s:16:02:37 e:16:02:45 f:8.948 d:tmr-SYSMON_Update(sysmon) tmr-FHEM::Senec::periodicCallLocal(N/A)

1 - 2025-10-16_[Log]: s:20:54:17 e:20:54:25 f:8.558 d:tmr-FHEM::Senec::periodicCallLocal(N/A)

1 - 2025-10-17_[Log]: s:01:45:57 e:01:46:05 f:8.306 d:tmr-FHEM::Senec::periodicCallLocal(N/A)

1 - 2025-10-17 _[Log]: s:03:35:00 e:03:35:03 f:3.142 d:tmr-ZWave_wakeupTimer(Thermostat_WZ) tmr-at_Exec(at_zwave_fix)

1 - 2025-10-17_[Log]: s:06:37:37 e:06:37:46 f:9.57 d:tmr-FHEM::Senec::periodicCallLocal(N/A)

1 - 2025-10-17_[Log]: s:11:29:17 e: 11:29:25 f:8.795 d:tmr-FHEM::Senec::periodicCallLocal(N/A)

1 - 2025-10-17_[Log]: s:16:20:57 e: 16:21:05 f:8.501 d:tmr-FHEM::Senec::periodicCallLocal(N/A)

1 - 2025-10-17_[Logl: s:21:12:37 e:21:12:45 f:8.594 d:tmr-ZWave_wakeup Timer(Thermostat_Bad) tmr-FHEM::Senec::periodicCallLocal(N/A)

1 - 2025-10-18_[Log]: s:02:04:17 e:02:04:25 f:8.331 d:tmr-FHEM::Senec::periodicCallLocal(N/A)

1 - 2025-10-18_[Log]: s:06:55:57 e:06:56:05 f:8.477 d:tmr-FHEM::Senec::periodicCallLocal(N/A)

1 - 2025-10-18_[Log]: s:11:47:37 e:11:47:45 f:8.369 d:tmr-FHEM::Senec::periodicCallLocal(N/A)

1 - 2025-10-18_[Log]: s:16:39:17 e: 16:39:26 f:9.273 d:tmr-FHEM::Senec::periodicCallLocal(N/A)

1 - 2025-10-18_[Log]: s:21:30:57 e:21:31:05 f:8.404 d:tmr-FHEM::Senec::periodicCallLocal(N/A)

1 - 2025-10-19_[Log]: s:02:22:37 e:02:22:45 f:8.53 d:tmr-FHEM::Senec::periodicCallLocal(N/A)

1 - 2025-10-19_[L0g]: s:07:14:17 e:07:14:25 f:8.539 d:tmr-FHEM::Senec::periodicCallLocal(N/A)

LG
C.K.

Das Problem habe ich. Daher habe ich das Senec Modul vor einiger Zeit auf einen separaten FHEM umgezogen wo das nicht stört.

@Hubert schaust du dir das an?
Ansonsten würde ich mir das demnächst mal anschauen.

[carlos]

Also ich habe die Abfragen alle mit HttpUtils_NonblockingGet implementiert, außer dem initial connect.
Von daher kann ich nicht beurteilen woher die freezes kommen.
Da sind ja auch noch andere mit dabei, von daher tippe ich mal auf ein Netzwerk Problem.
Aber das läßt sich so aus der Ferne nicht analysieren.
Ich denke nicht das das am modul liegt.

Gruß

Hubert