HM-CC-RT-DN Störung nach PI neustart

[Kollejoe]

Hallo Leute,

ich habe ein Problem mit dem ständig auftretendem Kommunikationsfehler bei gepeerten HM-CC-RT-DN Thermostaten.
Ich habe schon alles mögliche, hier im Forum und dem Wiki beschriebene probiert und komme nicht weiter.
Ehrlichgesagt bin ich langsam am verzweifeln.

Ich habe FHEM als Docker Container im Portainer auf einem RPI 4 laufen.
Ich benutze das HM-MOD-RPI-PCB Funkmodul auf einem Wemos D1 Mini welches ich als HMUARTLGW in FHEM eingebunden habe.
Das ganze läuft natürlich mit einer VCCU in FHEM.

Die Grundkonfiguration funktioniert wunderbar.
Ich kann die Thermostate erfolgreich pairen und benutzen!

Gerne würde ich Xiaomi Temperatursensoren mit den Weather Channel der Thermosatate peeren.
Die Sensordaten lese ich über MQTT in FHEM ein, das Gateway ist ein Sonoff ZbBridge.

All diese Dinge funktionieren soweit gut.

Wenn ich die virtuelle Temperatur Channel nach der (Anleitung im Wiki) mit den Weather Channel der Thermosatate peere, funktioniert das erstmal ohne Probleme.

Aber jedes mal wenn ich mein PI reboote, springen alle Thermostate wieder auf die interne Temperatur und die Thermostate zeigen ein Kommunikationsfehler (Antenne Blinkt).
Alles andere funktioniert nur eben nicht die Übernahme der externen Temperatur.

HMinfo configCheck und peerXref sehen gut aus!

Das Hier beschriebene Vorgehen mit dem cyclicMsgOffset bringt leider keinen Erfolg!

Wie gesagt der Fehler tritt immer nach einem neustart des PI auf. Dieser dauert gerade mal ein paar Minuten, somit würde ich jetzt mal ausschließen, dass der RT 15min lang keinen Wert von seinem (virtuellen) Peer bekommt.
Es kann zwar sein, dass die Temperatur des Xiaomi Sensors sich eine gute weile nicht ändern, aber das ist nur vereinzelt.
Vor allem, es fallen alle 8 RT gleichzeitig aus. Das wäre für mich ein Zeichen, dass es nicht an den internen "Temperaturübergabe-Zeiten" liegt.

Hat jemand eine Idee, ich drehe hier langsam durch 

Danke
Niko

[Beta-User]

Meine _Vermutung_ wäre, dass das mit den Verzögerungen aufgrund WLAN zusammenhängt - FHEM muss das Timing überwachen, damit jeder Thermostat jeweils zum richtigen Zeitpunkt seine virtuellen Daten bekommt. Wenn es in Sende- und Empfangsrichtung zwischen FHEM und dem IO delays gibt, dauert das entsprechend lange, bis die Synchrinisation wieder passt.

Abhilfemaßnahme wäre wohl ein "direkteres" IO.

Der Link zeigt übrigens vermutlich nicht auf die richtige Wiki-Seite, und ich setze voraus, dass du eine etwas ältere oder eine sehr neue Version von CUL_HM im Einsatz hast. Dazwischen waren mal Probleme angesagt (verlorene Peers und so).

[Kollejoe]

Hey Danke für den Hinweis, habe nun den Richtigen Link drin:
https://wiki.fhem.de/wiki/HM-CC-RT-DN_Funk-Heizk%C3%B6rperthermostat

Bezüglich des IOs: Ich kenne 2 Leute die ebenfalls den Wemos benutzen und keine derartigen Probleme haben :/ Der einzige Unterschied ist, dass sie kein PI sondern einen Rechner/Server benutzen und vermutlich eine ältere FHEM version haben.
Ich finde das mit dem Wemos eine super Lösung und würde gern dran halten, bzw es nur ändern wenn ich sicher bin, dass es zu 100% an dem WLAN Modul liegt.

Bin mir nicht sicher ob es rein an den WLAN Timings liegt, ich konnte tagelang die RTs mit gepeerten temperaturen einwandfrei nutzen. Aber jedes mal nach einem reset tretten die Fehler sofort auf.
Das HM Modul ist bei dem reset ja noch online. D.h. wenn FHEM hochfährt ist das HMUART wieder sofort da. Oder verstehe ich etwas falsch?

Wie fine ich meine CUL_HM Version raus? Bzw kann ich einfach die CUL_HM updaten ohne das restliche System?

Grüße
Niko

[LuckyDay]

Im Prinzip muß sich der RT auf den Virtuellen Temp Cannel wieder syncen nach Fhem restart.

Wenn jetzt jemand regelmäßig ein Fhemrestart macht, zerstört er auch den Sync Rhythmus seines RTs!

Diese wird zu bestimmten Zeiten als broadcast gesendet. Diese Zeiten kennt der RT und hält sich kurzfristig empfangsbereit.

Hier wird beschrieben, wie man das Sendeintervall von Fhem beeinflussen kann.
https://forum.fhem.de/index.php/topic,45735.msg572806.html#msg572806

[Beta-User]

Aber jedes mal nach einem reset tretten die Fehler sofort auf.

"reset" klingt nach unsauberem Neustart. Dann sind ggf. nach der Anleitung im Wiki die Daten zu alt und werden gelöscht (dass MUSS so sein!). Also: Sauber runterfahren _könnte_ das Problem schon minimieren.

Wie fine ich meine CUL_HM Version raus? Bzw kann ich einfach die CUL_HM updaten ohne das restliche System?

a) Bitte die im Anfängerbereich gepinnten Beiträge lesen, da sollte auch was zu "was muss ich liefern" und "wie finde ich diese Infos" stehen. Deine Beschreibung ist jedenfalls lückenhaft. Quickfix: "help version"
b) Isolierte updates sind in der Regel nicht zu empfehlen. Im Moment würde ich - trotz mancher Wackeligkeiten bzgl. CUL_HM ein Gesamtupdate empfehlen. Besonders alt kann deine Installation ja nicht sein, wenn du zigbee2tasmota nutzt - das geht nämlich nur mit den MQTT2-Modulen einigermaßen erträglich.
Solltest du zufällig ComforAir nutzen, schließe das vom update aus, bis das nächste update dafür im svn ist.
Sonst ist mWn. im Moment nichts problematisch.

[Kollejoe]

Hallo Leute,

ich wollte nun nochmal Berichten.

So wie es ausschaut lag mein Problem an einer alten CUL_HM version (oder an einem anderen veralteten modul).
Schenbar hat die Docker_Hub version ein "fehlerhaftes"Modul drin.

Nach einem Internen Update läuft alles stabil!
Die RTs springen zwar immer noch hin und wieder auf die interne Temperatur, aber das liegt daran, dass meine Xiaomi Temperatursensoren hin und wieder über 30min kein Update schicken.
Sobald ein ein Temperatur-Update gibt fangen sich die RTs wieder!

An alle die FHEM auf einem RPI über Docker mit selben Problemen laufen haben:
Macht ein Update wie HIER beschrieben.

Isolierte updates sind in der Regel nicht zu empfehlen. Im Moment würde ich - trotz mancher Wackeligkeiten bzgl. CUL_HM ein Gesamtupdate empfehlen. Besonders alt kann deine Installation ja nicht sein, wenn du zigbee2tasmota nutzt - das geht nämlich nur mit den MQTT2-Modulen einigermaßen erträglich.

Danke für den Tipp Beta-User!

Grüße
Niko