HM-CC-RT-DN als Leitungsfrostschutz?

[Flieger1]

Moin Moin, ich hoffe ihr könnt einem Laien helfen und ihm einen Tipp geben. Ich habe das Problem das mir letztes Jahr die Zuleitung für einen Heizkörper eingefroren ist da die Zuleitung ungünstig verlegt wurde. Der Heizkörper selbst wird so gut wie nie genutzt was natürlich das Einfrieren der Leitung begünstigt.
Meine Überlegung ist nun die Heizung im Winter so alle 2 Stunden für ein paar Minuten zu aktivieren. Doch wie mache ich dies am besten?
Über ein Temperaturprofil das den HM-CC-RT-DN alle paar Stunden öffnet oder über ein Programm?
Ich habe auch eine HM-WDS100-C6-O-2 die man vielleicht in das Programm mit einbinden könnte, zB.  daß das Programm nur ausgeführt wird wenn die Temperatur unter -5 Grad fällt.

Gruß
Flieger1

[Beta-User]

Wenn du die Außentemperatur mit berücksichtigen willst, ist vermutlich ein gelegentliches "boost" via "at" die simpelste Lösung.

[frank]

tempsensor an das rohr an der kältesten stelle?
eventuell sogar als externen sensor mit dem rt peeren?

[Flieger1]

An das Rohr komme ich nicht dran, liegt zwischen der Isolierung und den Dachpfannen.

[Flieger1]

Wie ist das gemeint " via "at" "

[Gisbert]

Hallo Flieger1,

letztlich ist es wurscht, wie du das Einschalten des Heizkörpers gestaltest. Ich würde es mit einem DOIF wie folgt machen:

Code Auswählen Erweitern

define Heikörper_an DOIF ([Aussentemperatur:temperatur]<-5) (set Heizkörper on) (set Heizkörper off) DOELSE (set Heizkörper off)
attr Heizkörper_an do always
attr Heizkörper_an do repeatcmd 6600:60
attr Heizkörper_an repeatsame 0:2
attr Heizkörper_an wait 0,600:0
Namen stehen hier nur symbolisch für deine Devices, natürlich ohne Umlaute in Fhem.
Alle 2 Stunden, wenn die Außentemperatur kleiner -5°C ist, wird der Heizkörper eingeschaltet und nach 10 Minuten ausgeschaltet.

Ungetestet, müsste aber so funktionieren. Deshalb bitte testen.
Falls noch Fragen sind, oder Erklärungen benötigt werden, dann melde dich bitte wieder.

Viele​ Grüße​ Gisbert​

[Beta-User]

Wie ist das gemeint " via "at" "

https://fhem.de/commandref_modular_DE.html#at

Alle 45 Min. die Außentemperatur checken und ggf. ein boost absetzen:

Code Auswählen Erweitern

defmod a_check_frostprot at +*45:00 {return if (ReadingsVal('Aussentemperatur','temperatur',15)>-5;; return fhem('set Heizkoerper boost')}

[Gisbert]

Hallo Beta-User,

ich frag mich immer wiedermal  bei meinen Konstruktionen, wie rechenintensiv das ist.

Bei meinem DOIF-Beispiel muss Fhem immer aktiv werden, wenn ein Event Aussentemperatur, temperatur auftritt, übrigens die Voraussetzung, dass DOIF aktiv wird, d.h. es muss ein Event vorliegen, also ein neuer Temperaturwert.

Ein at schaut nur wiederkehrend im angegebenen Zeitintervall nach, d.h. ist viel seltner aktiv. Der weitere Vorteil ist möglicherweise auch, dass kein Temperatur-Event vorliegen muss, sondern nur ein Wert, der an sich vorhanden sein muss.

Bei sehr vielen DOIFs, geht so was auf die Performance/Rechenzeit? Wahrscheinlich gibt es kein best practice, aber wie handhabst du es im Allgemeinen?

Viele​ Grüße​ Gisbert​

[Beta-User]

Bei sehr vielen DOIFs, geht so was auf die Performance/Rechenzeit? Wahrscheinlich gibt es kein best practice, aber wie handhabst du es im Allgemeinen?

Zum einen "kann" ich DOIF nicht und löse daher alles ohne diese "Mega-schweizer-Kettensäge-hoch2", und zum anderen versuche ich eben erst mal festzustellen, was denn jetzt der pragmatischste Lösungsansatz ist. Hier soll halt alle x Minuten Warmwasser kommen, wenn "kalt" also wird genau das geprüft, und ansonsten eben direkt rausgesprungen, wenn die weitere Prüfung keinen Sinn macht.

Ansonsten sind weniger Eventhandler effektiver, solche mit NOTIFYDEF besser als solche ohne, etc.. Aber das soll hier kein "Performance"-Thread werden. Dazu gibt es mind. schon einen relativ aktuellen.

Aber danke, dass du nachfragst. Mich wundert nämlich immer, wenn DOIF-"Kenner" unbedingt notify/at "loswerden" wollen, obwohl die letzteren in der Regel mit weniger overhead/Attributen/spezieller Syntax auskommen (eben häufig nur "mit etwas Perl")...
(Mir ist schon klar, dass man das at auch durch ein "Timer-DOIF" ersetzen könnte, und das auch nur ein Einzeiler wäre).

[Damian]

Hier steckt jede Menge Vermutungen mit Halbwissen in diesem Thread.

Zur Klarstellung:

1) AT setzt einen internen Timer, genauso wie DOIF bei Definition einer Zeit, beide schlafen sonst - kein Performanceunterschied.

2) DOIF benutzt seit geraumer Zeit NOTIFYDEF-Filter wie notify, ansonsten wird ein eigener Filter definiert, der effizienter arbeitet als notify ohne Filter (z. B. bei vielen Events, die notify/DOIF wecken, aber nichts zu tun ist - das lässt sich sogar messen )

3) Wenn man, nur in bestimmten Zeitabständen (im Stundenintervall) etwas erfragen will, dann ist es effizienter dies per Timer zu machen. Allerding möchte man oft eine unmittelbare Reaktion auf ein Ereignis haben, da ist ein Eventhandler besser. Der Perfomance-Unterschied hängt von der Häufigkeit der Events ab. Man kann normalerweise in FHEM hunderte Eventhandler definieren und das System wird immer noch "Däumchen drehen", wenn nicht zig Events pro Sekunde eintrudeln.

4) Entscheidend für die Performance des Gesamtsystems ist die Häufigkeit von Events, diese lässt sich mit event-on-change-Attributen stark minimieren, ohne dass entscheidende Informationen verloren gehen.