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.6Das 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.

[TubeHead]

Kurze Frage:
Wird daran noch entwickelt?

Mir ist leider erst jetzt aufgefallen, dass VALVES den Mittelwert (valve_average) nur noch als Ganzzahl auswirft, obwohl rein rechnerisch dort fast immer ein Dezimalbruch herauskommen müsste; Eingabewerte sind sechs Temperaturen resp. Feuchtewerte mit jeweils einer Dezimalstelle.
Muss auch mal funktioniert haben, da ich in beiden ein UserReading hatte zwecks Rundung auf eine Dezimalstelle (Temperatur) resp. Ganzzahl (Luftfeuchte). Die (vermeintlich) aktuelle 39_VALVES.pm aus dem SVN läuft bei mir nicht. Die produziert massig Fehler und bricht dann ab.

Habe ich da eine Info versäumt? Wäre ja bei dem Umfang von FHEM nicht unwahrscheinlich.

LG
Andi

[Beta-User]

Kurze Frage:
Wird daran noch entwickelt?

Wenn es Probleme gibt, ggf. schon...

Mir ist leider erst jetzt aufgefallen, dass VALVES den Mittelwert (valve_average) nur noch als Ganzzahl auswirft, obwohl rein rechnerisch dort fast immer ein Dezimalbruch herauskommen müsste; Eingabewerte sind sechs Temperaturen resp. Feuchtewerte mit jeweils einer Dezimalstelle.

https://forum.fhem.de/index.php?msg=1219913 => Ganzzahl ist Absicht, maacht ja keinen Sinn, wegen minimalster Änderungen Events zu produzieren...

Die (vermeintlich) aktuelle 39_VALVES.pm aus dem SVN läuft bei mir nicht. Die produziert massig Fehler und bricht dann ab.

Hmmmm, habe grade gesehen, dass bei mir noch die Version aus dem Thread von 2022 läuft. Das müßte aber die gewesen sein, die dann mit neuer Revisionsnummer im svn-contrib gelandet ist.

Da du aber Ganzzahlen hast, muss die Version doch eigentlich laufen, das paßt für mich nicht recht zusammen. Du hast nach dem Download FHEM neu gestartet? Sonst wären Prototype mismatch-Warnings die logische Folge...
Bitte daher etwas mehr Info, wie die Fehlermeldungen im log aussehen (wenn es was anderes ist).

[F_Klee]

Dazu hätte ich auch noch eine Anmerkung. Meine Wärmepumpe wärmt inzwischen. Allerdings scheint VALVES nicht richtig zu rechnen. Hier ein Beispiel:

Du darfst diesen Dateianhang nicht ansehen.

average kann ja eigentlich nicht größer als max werden.

Jetzt muss ich doch noch einmal nachfragen: Wird VALVES eigentlich per UPDATE aktualisiert oder muss ich da noch Hand anlegen?

[Beta-User]

Hier ein Beispiel:

Kann den screenshot nicht öffnen...

Bitte einfach "copy for Forum" verwenden und das ggf. auszugsweise posten, ist einfacher.

Ansonsten kann ich Rechenfehler nicht ausschließen.

Jetzt muss ich doch noch einmal nachfragen: Wird VALVES eigentlich per UPDATE aktualisiert oder muss ich da noch Hand anlegen?

Es liegt in contrib. Du mußt updates also ggf. dort selbst runterziehen (bisher liegt da aber nur die initiale (von mir überarbeitete) Version).

[F_Klee]

Hier ein Beispiel:

Kann den screenshot nicht öffnen...

Bitte einfach "copy for Forum" verwenden und das ggf. auszugsweise posten, ist einfacher.

Ansonsten kann ich Rechenfehler nicht ausschließen.

Code Auswählen Erweitern

define HZ_Heizbedarf VALVES
attr HZ_Heizbedarf userattr valvesZWave_THERMOSTAT.*Weighting valvesZWave_THERMOSTAT_4Weighting valvesZWave_THERMOSTAT_6Weighting valvesZWave_THERMOSTAT_7Weighting valvesZWave_THERMOSTAT_8Weighting valvesZWave_THERMOSTAT_9Weighting valvesZWave_THERMOSTAT_DWeighting
attr HZ_Heizbedarf group Heizungssteuerung
attr HZ_Heizbedarf room _Heizung
attr HZ_Heizbedarf userReadings valve_av {my $val = ReadingsVal($name,"state",0);; return 0 if $val eq "attr valvesDeviceList is empty";; ReadingsNum($name,"state",0)}
attr HZ_Heizbedarf valvesDeviceList ZWave_THERMOSTAT.*:FILTER=thermostatMode!~off
attr HZ_Heizbedarf valvesDeviceReading valve
attr HZ_Heizbedarf valvesZWave_THERMOSTAT_7Weighting 0.5
#   FUUID      63c57e12-f33f-b2df-32a5-cad86276360f01cd
#   NAME       HZ_Heizbedarf
#   NR         102
#   STATE      53
#   TYPE       VALVES
#   eventCount 7006
#   OLDREADINGS:
#   READINGS:
#     2024-10-15 09:36:44   raw_average     62
#     2024-10-15 09:38:24   state           53
#     2024-10-13 22:01:03   valveDetail_ZWave_THERMOSTAT_4 pos:25 calc:25 time:2024-10-13 22:00:44
#     2024-10-15 09:39:44   valveDetail_ZWave_THERMOSTAT_7 pos:86 calc:43 time:2024-10-15 09:30:49
#     2024-10-15 09:39:44   valveDetail_ZWave_THERMOSTAT_8 pos:37 calc:37 time:2024-10-15 09:38:20
#     2024-10-14 09:40:31   valveDetail_ZWave_THERMOSTAT_9 pos:0 calc:0 time:2024-10-14 09:28:02
#     2024-10-03 08:48:00   valveDetail_ZWave_THERMOSTAT_D pos:0 calc:0 time:2024-10-03 08:48:00
#     2024-10-13 22:00:44   valve_ZWave_THERMOSTAT_4 25
#     2024-10-15 09:30:49   valve_ZWave_THERMOSTAT_7 43
#     2024-10-15 09:38:20   valve_ZWave_THERMOSTAT_8 37
#     2024-10-14 09:28:02   valve_ZWave_THERMOSTAT_9 0
#     2024-10-03 08:48:00   valve_ZWave_THERMOSTAT_D 0
#     2024-10-15 09:39:44   valve_av        53
#     2024-10-15 09:38:24   valve_average   53
#     2024-10-15 09:30:53   valve_max       43
#     2024-10-15 09:38:24   valve_min       37
#   helper:
#     valvesDeviceReading:
#       valvesDeviceReading valve
#
setstate HZ_Heizbedarf 53
setstate HZ_Heizbedarf 2024-10-15 09:36:44 raw_average 62
setstate HZ_Heizbedarf 2024-10-15 09:38:24 state 53
setstate HZ_Heizbedarf 2024-10-13 22:01:03 valveDetail_ZWave_THERMOSTAT_4 pos:25 calc:25 time:2024-10-13 22:00:44
setstate HZ_Heizbedarf 2024-10-15 09:39:44 valveDetail_ZWave_THERMOSTAT_7 pos:86 calc:43 time:2024-10-15 09:30:49
setstate HZ_Heizbedarf 2024-10-15 09:39:44 valveDetail_ZWave_THERMOSTAT_8 pos:37 calc:37 time:2024-10-15 09:38:20
setstate HZ_Heizbedarf 2024-10-14 09:40:31 valveDetail_ZWave_THERMOSTAT_9 pos:0 calc:0 time:2024-10-14 09:28:02
setstate HZ_Heizbedarf 2024-10-03 08:48:00 valveDetail_ZWave_THERMOSTAT_D pos:0 calc:0 time:2024-10-03 08:48:00
setstate HZ_Heizbedarf 2024-10-13 22:00:44 valve_ZWave_THERMOSTAT_4 25
setstate HZ_Heizbedarf 2024-10-15 09:30:49 valve_ZWave_THERMOSTAT_7 43
setstate HZ_Heizbedarf 2024-10-15 09:38:20 valve_ZWave_THERMOSTAT_8 37
setstate HZ_Heizbedarf 2024-10-14 09:28:02 valve_ZWave_THERMOSTAT_9 0
setstate HZ_Heizbedarf 2024-10-03 08:48:00 valve_ZWave_THERMOSTAT_D 0
setstate HZ_Heizbedarf 2024-10-15 09:39:44 valve_av 53
setstate HZ_Heizbedarf 2024-10-15 09:38:24 valve_average 53
setstate HZ_Heizbedarf 2024-10-15 09:30:53 valve_max 43
setstate HZ_Heizbedarf 2024-10-15 09:38:24 valve_min 37



[F_Klee]

Ach, übrigens: Keine Panik. Ich bastle eh noch an der Steuerung. Mein Hauptproblem ist momentan die Anwenderin 

[Beta-User]

Ach, übrigens: Keine Panik.

Von Panik keine Spur, muss mich nur halt auch erst wieder in das Thema eindenken und ggf. schauen, was da wie vercodet ist, der Kern ist ja nicht von mir...

Was sagt bei dir "version VALVES"?

[TubeHead]

Wenn es Probleme gibt, ggf. schon...

... das ist gut zu wissen 

https://forum.fhem.de/index.php?msg=1219913 => Ganzzahl ist Absicht, maacht ja keinen Sinn, wegen minimalster Änderungen Events zu produzieren...

Ok, das hatte ich nicht gesehen. Grundsätzlich aus meiner Sicht richtig, aber halt nicht in jedem Fall...

Da du aber Ganzzahlen hast, muss die Version doch eigentlich laufen, das paßt für mich nicht recht zusammen. Du hast nach dem Download FHEM neu gestartet? Sonst wären Prototype mismatch-Warnings die logische Folge...
Bitte daher etwas mehr Info, wie die Fehlermeldungen im log aussehen (wenn es was anderes ist).

Zwischenzeitlich habe ich ja wieder die laufende Version; war ja nicht dumm und hatte vorher ein Backup gemacht 
Aber wenn Du möchtest, nehme ich noch mal die aus dem SVN und pappe das Log hier an.

Ansonsten bin ich mir ziemlich sicher, dass vor langer Zeit der Wert in valve_average ebenfalls ein Dezimalbruch war. Ich füttere halt sechs werte mit einer Nachkommastelle ein und müsste, nach Adam Riese, nach der internen Berechnung auch mindestens einen Wert mit mindestens einer Nachkommastelle heraus bekommen. Aber irgendwie ist das im Laufe der Zeit wohl bei einem Update abhandengekommen; ich hatte ja nicht aus Jux und Dollerei ein ...

Code Auswählen Erweitern

userReadings = state { use Math::Round qw/nearest/; nearest('0.1', (ReadingsVal($name,"valve_average",0))); }
... da drin stehen.

Aber wenn das in Zukunft mit den Ganzzahlen so bleiben soll, dann muss ich das mal umbauen und eine Alternative suchen. Es macht das Modul halt etwas weniger universell, wenn das intern bereits behandelt wird.

EDIT:
39_VALVES.pm 27119 2023-01-25 20:10:56Z Beta-User

EDIT 2:
Mal vielleicht ne blöde Frage: Wäre es denn nicht möglich, intern ein weiteres Attribut like "DecimalPlaces" einzubauen, so das der Anwender das so setzen kann, wie er es benötigt? Also quasi das, was ich via UserReadings gemacht habe, intern über Attribut gesteuert?

[Beta-User]

39_VALVES.pm 27119 2023-01-25 20:10:56Z Beta-User

Das ist also die letzte aus dem svn-contrib. Scheint doch zu laufen...

Ok, das hatte ich nicht gesehen. Grundsätzlich aus meiner Sicht richtig, aber halt nicht in jedem Fall...

Kannst du mir einen Anwendungsfall nennen, bei dem es bei einer üblichen Scala von 0-100/0-99 auf Nachkommastellen ankäme?

Aber wenn das in Zukunft mit den Ganzzahlen so bleiben soll, dann muss ich das mal umbauen und eine Alternative suchen. Es macht das Modul halt etwas weniger universell, wenn das intern bereits behandelt wird.

Im Moment kommt mir das mit "weniger universell" etwas theoretisch vor, und du bist auch der erste, den das mit den Ganzzahlen irgendwie zu stören scheint. Wenn ich mich recht entsinne, gab es mal jemanden, der irgendeine andere Skalierung hatte, und da haben wir es mit einem userReadings-Eintrag am Ausgangsdevice gefixt, die das "normalisiert" hat (auf eine Skala 0-100 gemappt).