HM-CC-RT-DN und virtueller Temperatursensor (Netatmo)

[HardwareW]

Hi,

aufgrund der unbefriedigenden Temperaturmesswerte des HM-CC-RT-DN haben wir die Thermostate mit virtuellen Temperatursensoren, die über Netatmos gefüttert werden, gepeered.

Mittels: set -virtuellerSensor- peerChan 0 -HM Thermostat- single

Die Netatmo API liefert etwa alle 10min neue Werte, die wir dann an am virtuellen Sensor gesetzt haben.

Das hat auf den ersten Blick funktioniert. Jedoch ist uns nun aufgefallen, dass es immer wieder vorkommt, dass zwischendurch die Thermostate einzeln Ihre eigene Messwerte schicken (wirklich nur einmal. Dann wieder den des virtuellen Sensors). Das führt dazu, dass die Thermostate aufgrund der teils starken Temperatursprünge zwischen 0 und 100 % Ventilöffnung oszillieren.

Wir haben nun testweise (seit heute Mittag um 17 Uhr) das Intervall mit dem die virtuellen Sensoren gesetzt auf 2min erhöht. Also setzten die Temperatur, obwohl kein neuer Wert da ist. Bei unseren älteren Thermostaten (FW 1.0) ist das Problem weiterhin aufgetreten, bei den neuen (FW 1.3) ist bisher Ruhe.

Ist das ein bekanntes Problem? Muss man mit einer bestimmen Frequenz setzen, um das Verhalten des Wandthermostats zu simulieren?

[tpm88]

Hallo,

ja - das Problem ist schon länger bekannt. Siehe u.a. hier meinen Post von vor knapp einem Jahr:

Code Auswählen Erweitern

http://forum.fhem.de/index.php/topic,19686.msg137522.html#msg137522

Bei mir läuft es jetzt mittlerweile allerdings sehr stabil. Der RT-DN mit gepeertem virtuellen Sensor hat mittlerweile FW1.4. FHEM läuft auf einem CubieTruck mit dem HM-CFG-USB2 als HomeMatic IO Device. Temperatursprünge sind nur noch sehr selten, wen überhaupt im Bereich von einem pro Tag. Ohne es belegen zu können, habe ich die "Fenster offen" Erkennung des RT-DN in Verdacht, da manchmal dazwischenzufunken.

Lustigerweise habe ich mich von der anderen Richtung (noch häufigere Temperatur Updates des virtuellen Sensor) genähert und setze per at jetzt ebenfalls (nur noch) alle 2min die Temperatur.

Eine bestimmte "richtige" Frequenz dabei gibt es aber nicht. Das HM Modul in FHEM muß den nächsten Zeitpunkt des Aufwachens des Thermostat im ms Bereich korrekt berechnen, um just dann dem Thermostat die Temperatur des virtuellen Sensors zu senden. Das Timing bei HM ist kritisch. Ist der FHEM-Server zu diesem Zeitpunkt gerade mit etwas anderen beschäftigt, kann es vorkommen, daß das Übermitteln der Temperatur fehlschlägt. Meines Wissens fällt der RT-DN aber erst auf seinen eingebauten Wert zurück, wenn mehrmals hinterander kein externer Istwert empfangen wurde.

Gruß
Tobias

[Gruvol]

Hallo  ihr beiden,

ich habe mir in den letzten Tagen auch das Thermostat zugelegt und die angegeben Werte sind ja echt unterirdisch. Ich habe auch eine Netatmo und würde gerne diese Werte dort einfließen lassen.

Eine Sache ist mir noch nicht ganz klar. Muss man diesen virtuellen Temperatursensor noch separat anlegen oder kann man einfach den PeerChannel ausführen?

Ich habe folgendes ausgeführt: set netatmo_M03_00_00_02_7a_10 peerChan 0 HM_Livingroom_Weather single set

Habe ich dort was falsch gemacht?
Ich hoffe, ihr könnt mir helfen

Danke und viele Grüße

[tpm88]

Hallo Gruvol,

bitte hier nachlesen: http://www.fhemwiki.de/wiki/HM-CC-RT-DN_Funk-Heizkörperthermostat#Temperatursensoren

Gruß
Tobias


Gesendet von iPad mit Tapatalk

[kleinerDrache]

hatte früher mal Intertechnos als Virtuelle Sensoren da gab es die gleichen Probleme. Geholfen hat bei mir die DN's im Burst Mode Laufen zu haben. Heisst die wachen nicht mehr nur in Intervallen auf sondern können direkt geweckt werden. Kostet angeblich etwas mehr Batterie (hab seit etwas mehr als 1 Jahr immer noch den ersten Satz drinn) und erzeugt mehr last auf dem Funkband (1% Regel hat auch noch nie gezündet). Denke das ist ne Glaubensfrage ob man Burst nutzt oder nicht mir hat es geholfen.

PS. hab Mittlerweile Wandthermostate damit geht es perfekt aber immer noch mit aktivem burst.