Hallo zusammen,
werde demnächst VALVES nach contib einchecken, die aktuelle Version wäre dann (FHEM-Kommandofeld) zu bekommen mit
{ 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:
Zitat von: Beta-User am 29 April 2022, 13:33:22Vorschlag für aktualisierten Code im Anhang und in etwa folgende raw-Definiton:
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!
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
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...
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.
ZitatAllerdings 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
Zitat von: F_Klee am 07 Dezember 2023, 15:51:26Ich 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:
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...
Sorry, hatte gar nicht mitbekommen, dass du geantwortet hast.
Ich habe folgendes Attribut definiert
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.
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
Zitat von: TubeHead am 15 Oktober 2024, 09:06:02Kurze Frage:
Wird daran noch entwickelt?
Wenn es Probleme gibt, ggf. schon...
ZitatMir 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...
ZitatDie (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).
Dazu hätte ich auch noch eine Anmerkung. Meine Wärmepumpe wärmt inzwischen. Allerdings scheint VALVES nicht richtig zu rechnen. Hier ein Beispiel:
Screenshot 2024-10-15 091621.png
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?
Zitat von: F_Klee am 15 Oktober 2024, 09:34:04Hier 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.
Zitat von: F_Klee am 15 Oktober 2024, 09:34:04Jetzt 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).
Zitat von: Beta-User am 15 Oktober 2024, 09:37:52Zitat von: F_Klee am 15 Oktober 2024, 09:34:04Hier 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.
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
Ach, übrigens: Keine Panik. Ich bastle eh noch an der Steuerung. Mein Hauptproblem ist momentan die Anwenderin ;D
Zitat von: F_Klee am 15 Oktober 2024, 09:46:55Ach, ü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"?
Zitat von: Beta-User am 15 Oktober 2024, 09:27:18Wenn es Probleme gibt, ggf. schon...
... das ist gut zu wissen ;D
Zitat von: Beta-User am 15 Oktober 2024, 09:27:18https://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...
Zitat von: Beta-User am 15 Oktober 2024, 09:27:18Da 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 ...
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?
Zitat von: TubeHead am 15 Oktober 2024, 10:37:0839_VALVES.pm 27119 2023-01-25 20:10:56Z Beta-User
Das ist also die letzte aus dem svn-contrib. Scheint doch zu laufen...
Zitat von: TubeHead am 15 Oktober 2024, 10:37:08Ok, 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?
Zitat von: TubeHead am 15 Oktober 2024, 10:37:08Aber 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).
Zitat von: Beta-User am 15 Oktober 2024, 10:56:33Das ist also die letzte aus dem svn-contrib. Scheint doch zu laufen...
Ok, dann scheint hier beim Kopieren was anderes schiefgelaufen zu sein; war halt schon mitten in der Nacht ^^
Zitat von: Beta-User am 15 Oktober 2024, 10:56:33Kannst du mir einen Anwendungsfall nennen, bei dem es bei einer üblichen Scala von 0-100/0-99 auf Nachkommastellen ankäme?
Den habe ich Dir ja geliefert, wenn man es eben nicht explizit für Ventilstellungen resp. für Anwendungen benutzt, die einen Bereich von 0-100 abdecken, sondern wie ich für Temperaturen, Luftfeuchte oder was auch immer.
Aber ist ja alles gut. Es ist nun alles geklärt, was ich wissen wollte. Ich hatte nur noch immer im Kopf, dass VALVES halt auch für andere Dinge wie z.B. meine Anwendung gut zu gebrauchen ist. Ich hatte halt nicht damit gerechnet, dass sich die Entwicklung mehr in Richtung zur Spezialisierung Richtung Namensgebung entwickelt. Deshalb habe ich nachgefragt und jetzt bin ich schlauer.
Also vielen lieben Dank für die schnelle und ausgiebige Klärung!
Zitat von: TubeHead am 15 Oktober 2024, 10:37:08EDIT 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?
Hätte ich fast übersehen, nachträgliche edits sind in der Richtung immer gefährlich.
Werde mal drüber nachdenken, das sind im Code nur zwei sprintf-Anweisungen...
Frage: valvesPollInterval sind Minuten?
Zitat von: Beta-User am 15 Oktober 2024, 11:42:20Werde mal drüber nachdenken, das sind im Code nur zwei sprintf-Anweisungen...
Ich mach' mal einen auf Schlau, obwohl ich vom Code keinen Blassen habe:
Du arbeitest doch intern sicherlich mit dem Perl MATH-Modul? Dann könnte man doch für den Rundungsparameter in "nearest('0.1',value,0)" einfach den Wert aus dem Attribut einsetzen und fettisch, oder nicht?
Zitat von: jkriegl am 15 Oktober 2024, 14:44:34Frage: valvesPollInterval sind Minuten?
So weit mir bekannt:
Ja Oh warte... Geht nicht aus der Doku hervor, aber da es bei allen anderen Modulen i.d.R. Sekunden sind, vermute ich auch hier selbiges...
commandref (sollte doch sogar beim Attribut direkt angeezeigt werden?):
Zitat<li><b>valvesPollInterval <interval></b><br>
Polling interval (in seconds, between 1 to 900) between each attempt to update values. Defaults for compability reasons to 10.</li>
Intern wird InternalTimer verwendet, da ist die übliche Basisgröße auch Sekunden.
Zitat von: TubeHead am 15 Oktober 2024, 14:51:52Du arbeitest doch intern sicherlich mit dem Perl MATH-Modul?
Nope. Da Perl intern sowieso nicht "dauerhaft" zwischen Zahlen und Text unterscheidet, sind das (wie geschrieben) simples sprintf-Anweisungen.
Kann bei valvesPollInterv nur auswählen 1 2 3 .. 15 20 25 .. 60 90 120 .. 900
Zitat von: jkriegl am 16 Oktober 2024, 11:52:10Kann bei valvesPollInterv nur auswählen 1 2 3 .. 15 20 25 .. 60 90 120 .. 900
Was stört dich dabei?
Man kann per direkter Eingabe (attr xy ...) auch andere Werte zwischen 1 und 900 auswählen.
Und wenn du keine Attributhilfe angezeigt bekommst, in der genau das auch drinsteht, nutzt du entweder einen style im Frontend, der das nicht unterstützt, oder eine alte Version. Letzteres geht auch, wird hier in diesem Thread aber nicht supportet.
Zitat von: Beta-User am 15 Oktober 2024, 09:56:50Was sagt bei dir "version VALVES"?
File Rev Last Change
39_VALVES.pm 27119 2023-01-25 20:10:56Z Beta-User
doif.js 24438 2021-05-14 18:08:18Z Ellert
f18.js 28896 2024-05-22 09:01:58Z rudolfkoenig
fhemweb.js 28198 2023-11-22 16:22:22Z rudolfkoenig
fhemweb_readingsGroup.js 15189 2017-10-03 17:53:27Z justme1968
Zitat von: F_Klee am 16 Oktober 2024, 12:39:4439_VALVES.pm 27119 2023-01-25 20:10:56Z Beta-User
Hmmm, also die aktuelle.
Habe zwar jetzt mal kurz über den Code geschaut, aber noch keine Idee, wo das mit den unplausiblen Werten herkommen könnte.
Zitat von: TubeHead am 15 Oktober 2024, 14:51:52einfach den Wert aus dem Attribut einsetzen
Zumindest das sollte in der angehängten Version funktionieren, allerdings bisher ungetestet (=bitte melden, falls es Probleme damit gibt!). Attribut "decimals".
EDIT: Aktualisierte Version im svn, scheint zu funktionieren mit "decimals".
Zitat von: F_Klee am 16 Oktober 2024, 12:39:4439_VALVES.pm 27119 2023-01-25 20:10:56Z Beta-User
Hmmmm, habe jetzt etwas über dem Code gebrütet und auch mal mein eigenes VALVES-Device stichprobenartig gecheckt. Habe leider keine Ahnung, wo der aufgezeigte Rechenfehler herkommen könnte. Vielleicht, weil bei mir hier auch einige Gewichtungen drin sind? Aber eigentlich ist das dann "1", wenn nichts anderes da steht... Seltsam, das... Also falls jemand anderes eine Idee dazu hat oder wenigstens dieselbe Beobachtung: Bitte melden!
Habe mal ein wenig gespielt. Es scheint am Attribut "valvesZWave_THERMOSTAT_7Weighting" zu liegen. Ich habe es auf 0.5 gesetzt. Wenn ich es lösche rechnet VALVES richtig. Das Reading "raw_average" zeigt auch bei gesetztem Weighting den korrekten Wert ohne Gewichtung. In "calc" in valveDetail steht auch die halbe Ventilöffnung.
Ich habe mal in den Programmcode rein geschaut. Die Variable $corr erschließt sich mir nicht. Eigentlich müsste doch die Ventilöffnung multipliziert mit Weighting in die Rechnung eingehen. ::) Ich muss aber gestehen, dass ich mit Perl nicht klar komme.
Zitat von: F_Klee am 23 Oktober 2024, 21:54:19Ich habe mal in den Programmcode rein geschaut. Die Variable $corr erschließt sich mir nicht. Eigentlich müsste doch die Ventilöffnung multipliziert mit Weighting in die Rechnung eingehen. ::) Ich muss aber gestehen, dass ich mit Perl nicht klar komme.
Hatte eben beim Durchsehen auch kurz gezuckt und mir die Frage gestellt, warum das gg. dem Code von Florian geändert ist. Bin dann auf folgendes gestoßen:
Zitat von: Beta-User am 29 April 2022, 13:33:22- (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.
Ob
- der Gedanke an sich korrekt ist (dein Einwand) und
- das rechnerisch korrekt umgesetzt ist,
wäre zu klären. Die Logik im Code ist jedenfalls die, dass die Summe aller Korrekturen ermittelt wird, aus diesen der Mittelwert ermittelt und der dann nochmal als Divisor für den rechnerischen Mittelwert (der dein erwartetes Ergebnis wäre) verwendet wird.
Von daher kann es schon sein, dass das gewichtete Gesamtergebnis in der Tat größer ist als jeder einzelne Thermostat-Wert...
Damit ist geklärt, wie sich der Wert auswirkt und es nicht das ist, was ich erwartet habe. Allerdings habe ich überhaupt keine Ahnung, wofür man das nutzen kann. Da das durchaus interessant sein kann wäre es schön, wenn ein Heizungsexperte ein paar Informationen beisteuern könnte. Wäre sicher etwas für das Wiki.
Ich selbst wollte eigentlich einen Heizkörper, der weniger wichtig ist (zweiter, etwas schwächerer Heizkörper im Essbereich des Wohnzimmers), mit einem geringeren Wert in die Berechnung eingehen lassen. Ich werde es mal über die Priorisierung versuchen (alle Heizkörper bis auf die unwichtigeren werden priorisiert).
Ansonsten klappt es super.
Zitat von: F_Klee am 25 Oktober 2024, 13:32:36Ich selbst wollte eigentlich einen Heizkörper, der weniger wichtig ist (zweiter, etwas schwächerer Heizkörper im Essbereich des Wohnzimmers), mit einem geringeren Wert in die Berechnung eingehen lassen. Ich werde es mal über die Priorisierung versuchen (alle Heizkörper bis auf die unwichtigeren werden priorisiert).
Bin im Moment etas unschlüssig, ob es nicht schlicht eine Interpretationsfrage ist: Wenn du einen hast, der weniger wichtig ist, werden alle (also v.a. auch die anderen) relativ angehoben. Bei dir sind es "4,5" als Gesamtgewicht für 5 Thermostate, also sollte m.E. das Gesamtergebnis dann um 1/9 angehoben werden.
Komisch ist nur, dass das in deinem list so nicht gepaßt hatte. *Kopfkratz*
Wenn ich mich richtig erinnere, muss die Summe der Gewichte gleich der Anzahl der Geräte sein. Kann momentan leider nicht nachschauen.
Zitat von: jkriegl am 27 Oktober 2024, 11:15:04Wenn ich mich richtig erinnere, muss die Summe der Gewichte gleich der Anzahl der Geräte sein. Kann momentan leider nicht nachschauen.
Das war meiner Erinnerung nach früher mal so.
Da mir das nicht einleuchtend vorkam, wenn man das mit "ignore-high/low" (bzw. "prio")-Attributen kombiniert, hatte ich versucht, es rechnerisch im Code abzubilden, dass immer ein "Effektivgewicht" aller (ggf. mehrfach) berücksichtigten Thermostate von "1/1" rauskommt. Bin nur nicht mehr sicher, dass das korrekt rechnet. Das list von F_Klee gibt mir immer noch zu denken... (Also bitte melden, falls jemand da Verbesserungsvorschläge hat).
Ich fahre seit etlichen Jahren einen anderen Ansatz. Jeder Thermostat hat bei mir ein userReading "powerpart", das berechnet wird aus der Ventilstellung, der (effektiven) Heizkörperbreite und der Anzahl der Lamellen. "Effektiv" deshalb, weil ich in vier Räumen komplett abweichende Heizkörpergeometrien habe. Man könnte die Angaben der (effektiven) Breite und der Lamellenzahl auch durch eine einzige Kennung ersetzen, und so einzelne Heizkörper priorisieren.
Der gesamte Heizbedarf ist deshalb eine dimensionslose Größe als Summe aller dieser powerpart-Werte, die man beliebig skalieren kann.
Zum VALVES-Modul ist zu sagen, dass die doppelte Normierung (der Gewichte und des Endergebnisses) ziemlich sinnlos ist. Es reicht, das Endergebnis auf den gewünschten Skalenbereich abzubilden.
Mit dem hydraulischen Abgleich hat das nicht wirklich etwas zu tun. Denn der soll ja nicht den gesamten Heizbedarf nach den Bedarfen der Einzel-Heizkörper steuern. Sondern, ganz im Gegenteil, die Bedarfe der Einzel-Heizkörper aneinander anpassen. Damit nicht der HK im Dachgeschoss kalt bleibt, wenn man im Wohnzimmer die Heizung aufdreht.
Ich habe schon 2016 in den "SmartHome Hacks" erhebliche Zweifel an dem Konzept des hydraulischen Abgleichs angemeldet - und zwar aus allgemeinen physikalischen Grundsätzen heraus. Es macht nämlich gar keinen Sinn, alle Heizkörper gleich zu versorgen. Manche werden das nie benötigen, weil die lokale Regelung den "nackten" Bedarf überschreibt. Es macht daher viel mehr Sinn, bei elektronischen Heizungsreglern mit dem Temperaturoffset zu spielen. Und den ggf. lokal an den Bedarf anzupassen.
LG
pah
Zitat von: Prof. Dr. Peter Henning am 13 November 2024, 17:54:10Ich fahre seit etlichen Jahren einen anderen Ansatz. Jeder Thermostat hat bei mir ein userReading "powerpart", das berechnet wird aus der Ventilstellung, der (effektiven) Heizkörperbreite und der Anzahl der Lamellen. "Effektiv" deshalb, weil ich in vier Räumen komplett abweichende Heizkörpergeometrien habe. Man könnte die Angaben der (effektiven) Breite und der Lamellenzahl auch durch eine einzige Kennung ersetzen, und so einzelne Heizkörper priorisieren.
Ist denn dein "powerpart" in irgendeiner Form nicht linear? Falls es linear ist, dürfte das im Endeffekt auf dasselbe rauslaufen wie ein "weighting" in VALVES. (Ob man Priorisierungen etc. braucht, die halt da waren, darüber kann man vermutlich lange diskutieren. Da die im code drin waren, werde ich nicht anfangen, das in Frage zu stellen. Wer es nutzen will: go ahead).
Zitat von: Prof. Dr. Peter Henning am 13 November 2024, 17:54:10Zum VALVES-Modul ist zu sagen, dass die doppelte Normierung (der Gewichte und des Endergebnisses) ziemlich sinnlos ist. Es reicht, das Endergebnis auf den gewünschten Skalenbereich abzubilden.
"sinnlos" bedeutet "mathematisch falsch" oder "eigentlich nicht mehr notwendig"?
Nach meinen bisherigen Erfahrungen gibt das "normierte" Ergebnis eigentlich einen ganz brauchbaren Indikator, aber letztlich muss man das Endergebnis imo eigentlich immer irgendwie (weiter) interpretieren, weil letztlich die einzelnen Ventilstellungen ja auch u.a. von der (vom den thermostaten angenommenen) Vorlauftemperaturen und deren Differenz zur Solltemperatur abhängen. So ein Haushalt mit seiner Heizung etc. ist halt insgesamt ein mehr oder weniger träges, aber dynamisches Temperatur-Gesamtsystem.
Zitat von: Prof. Dr. Peter Henning am 13 November 2024, 17:54:10Mit dem hydraulischen Abgleich hat das nicht wirklich etwas zu tun.
Bisher war in diesem Thread oder bei VALVES auch der hydraulische Abgleich kein wirkliches Thema. Meine Erfahrungen in der eigenen Hütte: Es macht Sinn, sich mit der Versorgungssituation einzelner Heizkörper zu beschäftigen, um "hydraulische Kurzschlüsse" zu vermeiden, jedenfalls, wenn man die Heizung teilautonom entscheiden lassen will, wie viel Wärme sie ins System schubsen darf. Wenn die aus den falschen Gründen glaubt, der Heizbedarf sei gedeckt, ist das ein Problem.
Über alles andere zu dem Thema kann man vermutlich wirklich streiten. Aber bitte nicht hier.
Du missverstehst mich - ich meine damit keineswegs, dass das Ergebnis anders ist. Sondern nur der Ansatz. Ja, der ist linear, basiert aber nicht auf einem irgendwie zu erratenden Gewichtsfaktor, sondern der Größe des Heizkörpers. Ich halte es für denkbar, dass mit meinem Ansatz ziemlich dasselbe herauskommt, wie mit dem VALVES-Modul
Doppelte Normierung: Sinnlos heißt nicht "falsch" - sondern es ist einfach eine doppelte Rechnung.
Der hydraulische Abgleich wurde in einem der Posts unten erwähnt, aber eben im falschen Kontext.
@F_Klee: Nein, Heizungsexperte bin ich nicht - nur ausgewiesener Thermodynamiker. Und schüttele über solche Dinge wie den hydraulischen Abgleich einfach nur den Kopf. Das ist nämlich eine reine Gelddrucklizenz für Heizungsbauer, er kostet in der Regel genauso viel, wie die Förderung durch den Bund beträgt.
Für diejenigen, die an dieser Aussage zweifeln: Es ist für den Durchfluss durch einen Heizkörper vollkommen unerheblich, ob ich diesen Fluss am Eingangsventil=Thermostat oder durch ein Rücklaufventil begrenze. Das bedeutet, dass man mit einem System aus gescheit eingestellten elektronischen Thermostaten jeden hydraulischen Abgleich der Rücklaufventile ersetzen kann. Noch einfacher ausgedrückt: Stellt man fest, dass ein Heizkörper/Raum zu warm oder zu kalt wird => Offset in den Thermostaten setzen.
Und warum das für VALVES durchaus relevant sein könnte: Es ist nicht nur das Endergebnis relevant. Sondern man könnte durchaus auch den berechneten Wärmebedarf der einzelnen Heizkörper auf Ausreißer überprüfen, ggf. noch mit der gemessenen Raumtemperatur im Tandem.
Witzig fände ich eine Anzeige in Tabellenform: Für jeden Heizkörper/Raum die über den Tag integrierte Wärmemenge und die Durchschnittstemperatur. Oder noch komfortabler: Das Ganze stundenweise aufgeschlüsselt. Das wäre eine Hilfe beim Erkennen von Wärmelecks, hydraulischen Kurzschlüssen und ähnlichem. Mal sehen, vielleicht finde ich Zeit, das als Codeschnipsel zu implementieren.
LG
pah
@pah - Vielleicht eine allgemeine Anmerkung: Es war und ist mir weiter ziemlich unklar, warum das Thema (sinnvolle) "Heizungssteuerung" in FHEM allgemein und speziell im Wiki gefühlt unglaublich stiefmütterlich behandelt wird (abgesehen von "Heizung aus bei offenen Fenstern" und "ein bißchen weekprofile" (das imo leider kaum ein user richtig versteht) ). Kann sein, dass sich das Großthema in deinen Büchern besser aufbereitet findet, aber im Prinzip erschien mir VALVES so ziemlich der einzige Ansatz, dazu irgendeine "normierte" (Teil-) Basis für irgendwelche Automatismen bereitzustellen, und von daher finden sich auch in dem alten Thread ein paar allgemeine Dinge wie das mit dem Abgleich.
Gerne können wir VALVES (oder sonst was) gerne weiter ausbauen, wie gesagt, finde ich das (Gesamtthema) eigentlich zu wichtig, um es so stiefmütterlich zu behandeln.
Dazu würde dann gerne auch ein Abschnitt gehören, wie man mit "weighting" (oä./etc.) sinnvoll umgeht. Bei mit entspricht das übrigens auch im wesentlichen der Wärmeleistung der einzelnen HK (-Gruppen).