HM-CC-RT-DN Entpeeren funktioniert nicht-Wie FHEM von falschen Werten bereinigen

Begonnen von Ruggy, 23 Februar 2019, 16:50:03

Vorheriges Thema - Nächstes Thema

Ruggy

 dann muss ich mit das Modul CUL_HM anschauen...

Weil, wenn es ungünstig läuft kommt die Regelung evtl. durcheinander? Angenommen der externe hat z. b. 20° und liefert keinen Wert mehr; der interne schaltet sich ein und liefert z. b. einen Wert von 24°, dann liefert der externe wieder den Wert von 20°.
Die Ventile würden dann hin und her regeln?

Beim at ist es so, dass er den Wert 20° bekommen würde, wenn der sensor ausfällt und keinen wert liefert.

Beta-User

Zitat von: Ruggy am 26 März 2019, 16:49:23
dann muss ich mit das Modul CUL_HM anschauen...
Jein. Eher nochmal die Doku zum Thema virtueller Temperatursensor für Homematic.
ZitatWeil, wenn es ungünstig läuft kommt die Regelung evtl. durcheinander? Angenommen der externe hat z. b. 20° und liefert keinen Wert mehr; der interne schaltet sich ein und liefert z. b. einen Wert von 24°, dann liefert der externe wieder den Wert von 20°.
Die Ventile würden dann hin und her regeln?
Im ungünstigsten Fall kommt es ggf. tatsächlich zu unnötigen Adaptionsfahrten des Reglers in der Konstellation, dass der (3.) Sensor zu selten was liefert.

Das müßte man dann aber m.E. ANDERS lösen., denn:
ZitatBeim at ist es so, dass er den Wert 20° bekommen würde, wenn der sensor ausfällt und keinen wert liefert.
Wenn du dieses at meinst, ist dein Verständnis m.E. ein anderes als die tatsächliche Funktionsweise ;) :define at_WOH_virt_Temperatur_1 at +*00:05 { my $T=(ReadingsVal("WOH_LUFTFEUCHTE","temperature",20.0));; fhem "set WOH_virt_Temperatur_1_Sensor1 virtTemp $T";;}
Dafür müßte m.E. ein watchdog definiert werden (es sei denn, der oder eine vergleichbare Funktion schriebe schon was in WOH_LUFTFEUCHTE, was aber das Pferd von hinten aufgezäumt wäre...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

Ruggy

Mein Verständnis hierzu ist annähernd gleich null  :-\ ;)

In einem von dem Blogs (ich habe verstanden bzgl. den Blogs  8) ) wurde es aber so erklärt, dass wenn WOH_LUFTFEUCHTE keinen Wert liefert automatisch die 20.0 gesetzt werden.

Evtl. kann man dies ja auch mit notify irgendwie bewerkstelligen?

Habe jetzt ne zeitlang den Event Monitor mitlaufen lassen und nach dem Wohnzimmersensor filtern lassen. Die Aktualisierung ist anscheinend recht unregelmäßig. die letzten 30 min wurde nicht mehr aktualisiert.
Auch nicht so ideal. Ob das normal ist? Muss ich getrennt davon mal recherchieren

Ich lasse es noch ne weile mal mitlaufen.
Füge hier ausnahmsweise davon mal einen Screenshot ein, da ich nicht weiß wie/ob ich dies jetzt noch rückwirkend zeigen kann.


Beta-User

Kann schon sein, dass das in dem Blog so steht. Aber wenn, müßte irgendwo auch erläutert sein, dass das nur klappt, wenn der Readingwert aktiv gelöscht wird ;) . Denn nur dann ist kein Readingwert da und ReadingsVal() liefert den gesetzten Defaultwert zurück. Ansonsten ist ReadingsVal() egal, wie alt der vorhandene Wert ist...

Das Stichwort watchdog hatte ich genannt, oder? Versuch mal nachzudenken, was der hier wohl helfen könnte.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors