Support Thread für VALVES

[Beta-User]

Hallo zusammen,

werde demnächst VALVES nach contib einchecken, die aktuelle Version wäre dann (FHEM-Kommandofeld) zu bekommen mit

Code Auswählen Erweitern

{ Svn_GetFile('contrib/39_VALVES.pm', 'FHEM/39_VALVES.pm' }

Wer es schon in einer viel früheren Version im Einsatz hat: Bitte dann FHEM neu starten und es nicht per reload versuchen!

Es gibt zu der Vorversion einen Wiki-Artikel: http://www.fhemwiki.de/wiki/VALVES sowie einen Thread: https://forum.fhem.de/index.php/topic,24658.0.html

Der Wiki-Beitrag faßt das ganze gut zusammen und paßt soweit, allerdings gibt es einige kleinere Änderungen, die einem das Leben als Anwender etwas erleichtern sollten, eine commandref und etwas geänderte Benennungen bei den Attributen (die alten Attributnamen funktionieren aber weiter!).

Meine Zusammenfassung der funktionalen Änderungen:

Vorschlag für aktualisierten Code im Anhang und in etwa folgende raw-Definiton:

Code Auswählen Erweitern

define Heizbedarf_Gesamt VALVES
attr Heizbedarf_Gesamt userattr valvesThermostat_Bad_OGWeighting [...]
attr Heizbedarf_Gesamt valvesDeviceList TYPE=CUL_HM:FILTER=model=HM-CC-RT-DN:FILTER=DEF=.{6},ZWave_THERMOSTAT_20
attr Heizbedarf_Gesamt valvesDeviceReading actuator ZWave=reportedState
attr Heizbedarf_Gesamt valvesThermostat_Bad_OGWeighting 0.6
Das Modul sollte (trotz der offiziellen Umbenennung der Gewichtung-Attribute, die (ersatzweise) auch weiter ausgewertet werden) 99,9% kompatibel zu bestehenden Installationen sein. (EDIT: wg. veränderter Gewichtungsbetrachtung ergeben sich ggf. andere rechnerische Werte!)

Änderungen:
- rein Timer-basiert (die NotifyFn() war nur für das Loslaufen erforderlich)
- wenn komplett deaktiviert, gibt es keine Timer mehr, Teil-Deaktivierung via disabledForIntervals sollte möglich sein
- die Ergebniswerte werden als Ganzzahl ausgegeben
- Readings werden per Bulk-update geschrieben (das ist das mit den 0,1% - es kann daher sein, dass Eventhandler hier angepaßt werden müssen)
- devspec statt (nur) komma-separierter Liste (siehe raw oben)
- commandref (en)
- (EDIT:) Mittelwertberechnung verändert; die Durchschnittsgewichtung aller bei der Endberechnung berücksichtigten Thermostate (!) wird auf "1" gemittelt. Damit sollte sich (unterstellt, man hat einen üblichen Wertebereich von 0-100 bzw. 0-99 bei den Ausgangs-valve-Werten) immer auch ein Wert zwischen 0 und 100 ergeben.

Viel Spaß damit!

[F_Klee]

Hallo Beta-User,
zunächst einmal vielen Dank für die Pflege des Moduls. Ich habe es noch nicht im Live-Einsatz, da meine Heizung noch nicht so weit ist und lerne es zur Zeit kennen (zusammen mit den Thermostaten).

Mir ist da eine Idee für eine kleine Verbesserung gekommen. Ich nutze ein EUROtronic EUR_SPIRITZ ZWave-Thermostat. Hier kann man, wie sicher auch bei anderen, das Thermostat deaktivieren. Das Reading thermostatMode zeigt dann "off" statt "heating" oder auch "energySaveHeating" (letzteres nutze ich nicht). Wäre es vielleicht möglich, die Thermostate im Status "off" aus der Berechnung heraus zu nehmen?

Es gibt ja das Attribut "valvesIgnoreDeviceList". Das muss ich natürlich mehr oder weniger statisch definieren. Das Thermostat kann ich aber auch durch manuelle Bedienung in den off-Status bringen. Dann sollte der Heizkörper nicht mehr in die Berechnung einfließen.

Gruß
Frank

[Beta-User]

Hallo F_Klee,
Danke für die Rückmeldung.
Was Thermostate mit "off" angeht, bin ich mir nicht sicher, ob es sinnvoll ist, die aus der Berechnung rauszunehmen, da das Thermostat dann ja schließen sollte und damit "kein Heizbedarf" signalisiert. Dann kann man die Gesamtleistung entsprechend anpassen.
Allerdings sollte es schon heute möglich sein, deine Anforderung zu erfüllen, indem man die "valvesDeviceList" entsprechend ausgestaltet, dass Devices mit einem bestimmten Status gar nicht berücksichtigt werden. Die "getUpdate"-Funktion bildet nämlich bei jedem Berechnungslauf neu das betreffende Array...
Bitte mal damit spielen und berichten, ob es funktioniert .

PS: Habe das mit Eqiva eq-3 Heizkörperthermostat und Tasmota in https://forum.fhem.de/index.php?msg=1291489 gesehen - interessante Sache!
Mir gefällt allerdings zum einen die Vermischung zwischen dem ESP-Device und den Thermostaten nicht so recht (bridge-Device + Thermostat wäre m.E. besser), und zum anderen könnte man das Handling von Profilen ggf. mit weekprofile erleichtern (https://forum.fhem.de/index.php?topic=46117.0), was aber beides ggf. etwas Arbeit sein wird.
Bei Interesse bitte dazu einen neuen Thread im MQTT-Bereich aufmachen, dann könnten wir versuchen, das analog zu zigbee2mqtt zu gestalten (und dann nach dem Senden auch entsprechende timer anlegen, die die aktuellen Status-Infos wieder auslesen...

[F_Klee]

Hallo Beta-User,
ich weiß nicht, ob mein Ansatz für eine Heizungssteuerung korrekt ist. Ziel ist eine Steuerung, die ohne Zugriff per PC o.ä. funktioniert. Meine Mieterin soll einfach an die Heizung gehen, in deren Nähe sie sich gerade befindet und die gewünschte Temperatur einstellen. Häufig ist es so, dass sie tagsüber die aktuelle Therme noch im Nachtmodus hat und erst mit hochdrehen des Thermostats am Heizkörper die Heizung auch in den Tagbetrieb schaltet. Insgesamt gibt es 13 Heizkörper, von denen die meisten also gar nicht in Betrieb sind.

Mein Ansatz sieht vor, dass ich die Heizung anhand des Mittelwerts des Valves-Modul steuere. Im ersten Moment würde ich 50% anstreben, könnte mir aber auch einen anderen Öffnungswinkel vorstellen. Der Gedanke: Je mehr Wasser, desto geringer die Temperatur und damit die Verluste.
Anhand des Wertes von Valves möchte ich dann den Fußpunkt der Heizkurve verschieben. Das hat den Vorteil, dass Änderungen der Außentemperatur direkten Einfluß auf die Vorlauftemperatur haben und nicht erst die Änderung des Wärmeverlusts und damit der Anstieg oder die Absenkung der Innentemperatur abgewartet wird, um zu reagieren.

Wenn bei 13 Thermostaten eines den Öffnungswinkel von 0% auf 100% ändert, so habe ich am Ausgang von Valves eine Änderung von 0% auf 8%. Ich befürchte, dass es schwierig wird darauf zu reagieren, speziell wenn ich 50% anstrebe.
In Valves gibt es ja das Attribut "valvesIgnoreDeviceList". Das macht ja genau das, was ich mir Vorstelle. Die prinzipielle Idee hatte also schon jemand anderes. Das Problem ist nur, dass dieses Attribut statisch ist. Wünschen würde ich mir ein Attribut, in dem ich den Namen des Readings eintrage, das den Status des Thermostats enthält. Das Reading müsste dann nur auf "off" geprüft werden. Alles andere führt zu einer Berücksichtigung des Thermostats bei der Berechnung.

Allerdings sollte es schon heute möglich sein, deine Anforderung zu erfüllen, indem man die "valvesDeviceList" entsprechend ausgestaltet, dass Devices mit einem bestimmten Status gar nicht berücksichtigt werden.

Ich kann mir momentan nicht vorstellen, wie ich das machen müsste. Meine Definition von "valvesDeviceList" lautet "ZWave_THERMOSTAT.*". Dadurch werden automatisch alle ZWave-Thermostate eingebunden.

Gruß
Frank

[Beta-User]

Ich kann mir momentan nicht vorstellen, wie ich das machen müsste. Meine Definition von "valvesDeviceList" lautet "ZWave_THERMOSTAT.*". Dadurch werden automatisch alle ZWave-Thermostate eingebunden.

Die Definition ist seit meiner Überarbeitung eine devspec, so dass die allgemein in FHEM für devspec geltenden Regeln anwendbar sein sollten (wie geschrieben: ich habe das nicht praktisch ausprobiert).

Schau mal, welchen Unterschied diese beiden Zeilen beim list-Befehl ergeben:

Code Auswählen Erweitern

list ZWave_THERMOSTAT.*
list ZWave_THERMOSTAT.*:FILTER=state!~offDas sollte 1:1 auch mit dem define gehen; das was per ignore-Attribut (dort aber "leider" im Moment nur per Name) definiert wird, ist imModul-Code selbst "auch nur" die Gegenausnahme und entspricht (anders umgesetzt) dem, was die FILTER-Anweisung macht...

Ob das heizungstechnisch sinnvoll ist, was du da vor hast, ist eine andere Frage. Sehr oberflächliche Einschätzung: Vermutlich kann VALVES helfen, aber z.B. die Reation auf das Einschalten eines Thermostats würde ich per notify umsetzen, sonst dauert es tendenziell zu lange, bis deine Mieterin einen Effekt spürt.
MAn. ist der Ventilöffnungsgrad ein guter Indikator für die Frage, ob Wärmeanforderung und Wärmelieferung in einem guten Gleichgewicht sind, und da ist ein "mittlerer" Öffnungsgrad vermutlich "gut" - aber eben eher in einer Langzeitbetrachtung. Für eine "Startphase" würde ich eher die aktuelle Differenz zwischen Soll- und Ist-Temperatur zugrunde legen (und eben die Außentemperatur), und damit eine "Anschubfinanzierung" machen. Nach 15-30 Min. ist dann VALVES (hoffentlich) eingependelt...

[F_Klee]

Sorry, hatte gar nicht mitbekommen, dass du geantwortet hast.

Ich habe folgendes Attribut definiert

Code Auswählen Erweitern

valvesDeviceList ZWave_THERMOSTAT.*:FILTER=thermostatMode!~offEs funktioniert.

Die Idee mit dem notify hat was. Danke!

Nächsten Monat kommt die Wärmepumpe. Dann wird es spannend.