hier ein kleines helferlein um einen halbwegs sinnvollen und individuell gewichteten durchschnittswert der ventilpositionen mehrerer heizungsthermostate zu berechnen.
die idee ist quasi aus der not entstanden, es war mir zu umständlich die readings einzeln von einem remote fhem zu holen der selbst remote des systems ist das die daten haben will (rekursivproblem...). so kann ich direkt auf meinem heizungs-rechner mit den daten arbeiten die von einem anderen server verarbeitet werden.
die liste aller thermostate wird in einem attr eingestellt, name des readings in einem weiteren. das modul prüft dann regelmäßig (attr: poll interval) die daten des fhem-devices und berechnet neu wenn ein update vorhanden ist.
für die berechnung kann man folgende einstellungen vorgeben:
-ignoriere niedrigste 0...3 positionen
-ignoriere höchste 0...3 positionen
-ignoriere namentlich genannte devices
-priority-device liste (zählen doppelt)
-optionale einzeleinstellung für jeden thermostat, multipliziere mit attr-wert (zB:0,95 um 5% der position abzuziehen) um schlechten hydraulischen abgleich zu kompensieren
readings:
state ->mittelwert nach oben beschriebener berechnung
valve_<Devicename> -> berechnete virtuelle ventilstellung pro gerät
valveDetail_<Devicename> -> debug info mit details
raw_average -> simpler mittelwert ohne berücksichtigung der gewichtungen (ignores werden auch hier ignoriert)
valve_max -> größte aktuelle ventilöffnung
valve_min -> kleinste aktuelle ventilöffnung
in der theorie sollte es mit allen möglichen thermostaten funktionieren, falls jemand feststellt daß es mit irgendeinem hersteller inkompatibel ist versuche ich gerne das nachzurüsten.
doku ist nicht meine stärke, aber es gibt wie immer den befehl "get attrHelp ....."
LG, florian
# $Id: 39_VALVES.pm 1015 2016-12-04 09:55:00Z Florian Duesterwald $
http://www.fhemwiki.de/wiki/Raumbedarfsabh%C3%A4ngige_Heizungssteuerung (http://www.fhemwiki.de/wiki/Raumbedarfsabh%C3%A4ngige_Heizungssteuerung)
http://www.fhemwiki.de/wiki/VALVES (http://www.fhemwiki.de/wiki/VALVES)
Hallo Florian,
an genau so etwas bastele ich zur Zeit auch herum. Allerdings wollte ich das mit dummys realisieren. Dein Ansatz ist da deutlich schicker ;)
Was ich aber nicht sehe, wo die Gewichtung der einzelnen Heizkörper herkommt. Ich vermute mal, dass jeder Heizkörper nach seiner Größe/Heizleistung in die Mittelwertberechnung einfließt. Korrekt?
Viele Grüße
Christoph
christoph,
die dummy lösung watr mir zu unhandlich, insbesondere das einzelne abrufen vom remote fhem...
ZitatWas ich aber nicht sehe, wo die Gewichtung der einzelnen Heizkörper herkommt. Ich vermute mal, dass jeder Heizkörper nach seiner Größe/Heizleistung in die Mittelwertberechnung einfließt.
zu Deiner frage:
die individuelle gewichtung kann über attr. eingestellt werden.
die attr sind zunächst nicht vorhanden, und werden der attr.List erst hinzugefügt wenn Du attr valvesDeviceList Heizg1,Heizg2,Heitg3,... ausführst. danach ist im attr dropdown valvesHeizg1Gewichtung valvesHeizg2Gewichtung usw.. vorhanden.
(beim start ohne eigenes List attr werden nur die defaults verwendet, dabei auch nicht die extra attr angelegt.)
ich würde statt heizleistung/fläche etc... eher einen individuellen erfahrungswert als maß der dinge nehmen für diese einstellung, man weiß ja, im raum weit weg von der heizung mit dem sehr kleinen heizkörper ist die ventilstellung in der regel eher 60% statt 50%,
d.h. unterschied für das einzelattr wäre 1.2 (durchschnitt(50%) * attr (1.2) = 60%edit (hab ich falsch erklärt):d.h. unterschied für das einzelattr wäre
0.8 (durchschnitt(60%) * attr (0.8) = 50% ->50% werden für die berechnung angenommen obwohl tatsächliche ventilpos. höher
rechnerisch könnte man mit einigem aufwand das verhältnis heizleistung./.wärmebedarf des raums (aus: raumvolumen./.isolierungsqualität./.wunschtemperatur./. ... ... usw) nehmen um auf das gleiche zu kommen. dazu bin ich persönlich jedoch zu bequem ;)
LG, florian
mini-doku
edit: in ersten beitrag des threads verschoben
Hi Florian,
die abzufragenden Ventile müssen als Liste, können nicht als RegEx á la "Aktor.*" eingetragen werden?
Herzliche Grüße
Christian
ja, es muß eine liste sein damit die zusätzlichen attr für die gewichtung sauber generiert werden können
Moin, Florian,
beim ersten Neustart hatte ich eine interessante Liste:
2014.06.18 23:15:11 3: VALVES MAX_Valve has been defined
2014.06.18 23:15:11 3: VALVES MAX_Valve: attribute-value [group] = Heizung changed
2014.06.18 23:15:11 3: VALVES MAX_Valve: attribute-value [room] = Heizung changed
2014.06.18 23:15:11 3: VALVES MAX_Valve attribute-value [valvesDeviceList] = Aktor_Esszimmer,Aktor_Wohnzimmer,Aktor_Kueche,Aktor_Bad_EG,Aktor_Bad_OG,Aktor_Suedzimmer,Aktor_Jula,Aktor_Schlafzimmer changed
2014.06.18 23:15:11 3: VALVES MAX_Valve Heizg_Bad [err] DeviceReading not present
2014.06.18 23:15:11 3: VALVES MAX_Valve Heizg_Buero [err] DeviceReading not present
2014.06.18 23:15:11 3: VALVES MAX_Valve Heizg_WC_unten [err] DeviceReading not present
2014.06.18 23:15:11 3: VALVES MAX_Valve Heizg_Wohnzimmer1 [err] DeviceReading not present
2014.06.18 23:15:11 3: VALVES MAX_Valve Heizg_Wohnzimmer2 [err] DeviceReading not present
2014.06.18 23:15:11 3: VALVES MAX_Valve: attribute-value [valvesDeviceReading] = state changed
2014.06.18 23:15:11 3: VALVES MAX_Valve attribute-value [valvesPollInterval] = 15 changed
2014.06.18 23:15:11 3: VALVES MAX_Valve Aktor_Esszimmer [err] DeviceReading not present
2014.06.18 23:15:11 3: VALVES MAX_Valve Aktor_Wohnzimmer [err] DeviceReading not present
2014.06.18 23:15:11 3: VALVES MAX_Valve Aktor_Kueche [err] DeviceReading not present
2014.06.18 23:15:11 3: VALVES MAX_Valve Aktor_Bad_EG [err] DeviceReading not present
2014.06.18 23:15:11 3: VALVES MAX_Valve Aktor_Bad_OG [err] DeviceReading not present
2014.06.18 23:15:11 3: VALVES MAX_Valve Aktor_Suedzimmer [err] DeviceReading not present
2014.06.18 23:15:11 3: VALVES MAX_Valve Aktor_Jula [err] DeviceReading not present
2014.06.18 23:15:11 3: VALVES MAX_Valve Aktor_Schlafzimmer [err] DeviceReading not present
Da ist im Code noch eine hübsche Liste Deiner 5 Thermostate :-)
Auf der Telnet-Konsole ernte ich haufenweise Use of uninitialized value in addition (+) at ./FHEM/98_VALVES.pm line 236 jeweils in der Anfangsphase nach einem Neustart.
Mein Listing:
Internals:
CFGFN ./FHEM/heizung.cfg
NAME MAX_Valve
NR 774
NTFY_ORDER 50-MAX_Valve
STATE 0
TYPE VALVES
Readings:
2014-06-18 23:48:10 raw_average 0
2014-06-18 23:48:10 state 0
2014-06-18 23:54:04 valveDetail_CC_Bad_EG pos:0 calc:0 time:2014-06-18 23:53:36
2014-06-18 23:54:04 valveDetail_CC_Bad_OG pos:0 calc:0 time:2014-06-18 23:51:45
2014-06-18 23:54:04 valveDetail_CC_Jula pos:0 calc:0 time:2014-06-18 23:51:17
2014-06-18 23:54:04 valveDetail_CC_Kueche pos:0 calc:0 time:2014-06-18 23:53:12
2014-06-18 23:54:04 valveDetail_CC_Schlafzimmer pos:0 calc:0 time:2014-06-18 23:52:58
2014-06-18 23:54:04 valveDetail_CC_Suedzimmer pos:0 calc:0 time:2014-06-18 23:52:49
2014-06-18 23:54:04 valveDetail_CC_Wohnzimmer pos:0 calc:0 time:2014-06-18 23:51:16
2014-06-18 23:53:36 valve_CC_Bad_EG 0
2014-06-18 23:51:45 valve_CC_Bad_OG 0
2014-06-18 23:51:17 valve_CC_Jula 0
2014-06-18 23:53:12 valve_CC_Kueche 0
2014-06-18 23:52:58 valve_CC_Schlafzimmer 0
2014-06-18 23:52:49 valve_CC_Suedzimmer 0
2014-06-18 23:51:16 valve_CC_Wohnzimmer 0
2014-06-18 23:48:10 valve_average 0
2014-06-18 23:31:09 valve_max 0
2014-06-18 23:31:09 valve_min 0
Attributes:
group Heizung
room Heizung
valvesDeviceList CC_Esszimmer,CC_Wohnzimmer,CC_Kueche,CC_Bad_EG,CC_Bad_OG,CC_Suedzimmer,CC_Jula,CC_Schlafzimmer
valvesDeviceReading actuator
valvesPollInterval 15
Herzliche Grüße
Christian
uninitialized val in l.236 habe ich repariert, war ein bug.
ein paar meiner devices waren noch als default hinterlegt, habe ich auch geändert, und gleich noch eine bremse eingebaut: falls die dev list nicht vorhanden ist startet die berechnung nicht und in state steht eine fehlermeldung.
Zitat2014.06.18 23:15:11 3: VALVES MAX_Valve Aktor_Suedzimmer [err] DeviceReading not present
habe jetzt mal die zeit bis zum ersten loop ab fhem-start oder define auf ca.1 minute erhöht. vermute es liegt daran daß die devices (noch) nicht alle da waren, oder die reihenfolge Deiner def's innerhalb der fhem.cfg ist unlogisch gewesen
Attributes:
group Heizung
room Heizung
valvesDeviceList CC_Esszimmer,CC_Wohnzimmer,CC_Kueche,CC_Bad_EG,CC_Bad_OG,CC_Suedzimmer,CC_Jula,CC_Schlafzimmer
valvesDeviceReading actuator
valvesPollInterval 15 handling der inividuellen attr ebenfalls geringfügig updated.
neue version im ersten beitrag des threads.
# $Id: 98_VALVES.pm 1006 2014-06-19 01:50:00Z Florian Duesterwald $grüße, florian
Jo, das passt besser!
Bezüglich des "Esszimmers" war das mein Fehler, aber
im laufenden Betrieb habe ich jetzt erst mal weiter Fehlermeldungen, weil sich VALVES irgendwo aus vorherigen Experimenten etliche ungültige bzw. Testdevices immer noch gemerkt hat und mir diese unter Attribute auch noch z.B. als <DeviceXX>valve anbeitet (inkl. meiner Versuche mit regEXes). Wen oder was muss ich da löschen, um wieder tabula rasa zu haben? set <devicename> reset hat nicht geholfen.
Herzliche Grüße
Christian
die tauchen in der fhem.cfg unter "attr global userattr" auf...
... na, das hätte ich ja auch finden sollen. Danke, stimmt und funzt.
Christian
update:
# $Id: 39_VALVES.pm 1007 2014-06-20 18:00:00Z Florian Duesterwald $
update:
# $Id: 39_VALVES.pm 1008 2014-06-20 23:10:00Z Florian Duesterwald $
update:
# $Id: 39_VALVES.pm 1009 2014-06-21 11:19:00Z Florian Duesterwald $
+attr valvesInitialDelay
+Log level angepaßt
update:
# $Id: 39_VALVES.pm 1010 2014-06-21 15:11:00Z Florian Duesterwald $
attr handling
update:
# $Id: 39_VALVES.pm 1011 2014-06-22 23:51:00Z Florian Duesterwald $
+wiki-link +minor-changes
update:
# $Id: 39_VALVES.pm 1012 2014-06-29 15:35:00Z Florian Duesterwald $
update:
# $Id: 39_VALVES.pm 1014 2014-10-03 11:55:00Z Florian Duesterwald $
hallo
feines teil, nur wie kommt es , dass der Average ohne Wichtungen 99% erreicht obwohl die Messwerte alle kleiner sind?
anbei ein bild davon, die stellgrößen oben sind immer kleiner und trotzdem wird die mittelere Stellgröße unten sogar mal 99%.
Ich hatte mal eine Priority auf der Küche gesetzt aber dann wieder gelöscht, wirkt der evtl noch im hintegrund?
Sonst werden nur die kleinsten 3 ignoriert aber nichts gewichtet.
schon sehr merkwürdig und für mich nicht nachvollziehbar.
(http://bildschirmfoto%202014-10-18%20um%2011.55.04.png)
noch ne frage,
wieso ist der Mittelwert aus 0,0,0,0,0,36 -> 7,2 ?
müsste es nicht 6 sein?
sind doch 6 und nicht 5 geräte, die vor gerade erst 5 minuten abgefragt wurden.
hallo macmattes,
es wäre hilfreich wenn Du Deine VALVES config mal hier einstellen würdest. Ich schau mir das dann im detail an und finde ziemlich sicher auch eine lösung.
mfG florian
hi
ist eigentlich fast nix, eben die 6 geräte und keine wichtungen.
Hatte einmal eine Priorität auf der Küche, und einmal die kleinsten 3 ignorieren.
Beides ist wieder rausgenommen, trotzdem gabs diese Phänomene.
erklärt aber noch nicht warum durch 5 geteilt wird und nicht durch 6.
hab auch mal den reset bedient, vielleicht war noch was gecached?
werd dass mal beobachten,
define valves VALVES
attr valves group Heizung_Vorlaufregler
attr valves room Heizung
attr valves valvesDeviceList FHT_5a06_Dach_Ost,FHT_5c0d_Kinderzimmer_I,FHT_2c01_Kinderzimmer_III,FHT_5522_Kueche,FHT_025b_Schlafzimmer,FHT_4018_Wohnzimmer
attr valves valvesDeviceReading actuator
hallo , da stimmt wirklich irgendwas nicht
der mittelwert müsste raw und average 39,3333 sein und nicht 46,6
der teilt also auch bei 6 ventilen durch 5
(http://bildschirmfoto%202014-10-21%20um%2020.56.27.png)
und noch ein versuch, hab komplett neu definiert, ohne schnickschnack
auch wieder nur durch 5 geteilt
(http://bildschirmfoto%202014-10-21%20um%2021.10.30.png)
Könnte man nicht auch mit einem analogen vorgehen sich verbrauchswerte errechnen?
update:
# $Id: 39_VALVES.pm 1015 2014-10-22 04:35:00Z Florian Duesterwald $
Zitat von: drdownload am 21 Oktober 2014, 21:58:25
Könnte man nicht auch mit einem analogen vorgehen sich verbrauchswerte errechnen?
sicher könnte man aus den ventilstellungen näherungsweise den verbrauch erahnen, denke aber daß es im ergebnis nicht sehr genau wäre. die automatischen ventile könnten sich mehrfach umstellen zwischen zwei aktualisierungen und das rechenergebnis erheblich verfälschen.
LG, florian
nur ne kurze info, alles ok, danke
mit FHTs kommen Warnmeldungen im Log.
2014.11.08 21:02:46 1: PERL WARNING: Argument "0%" isn't numeric in multiplication (*) at ./FHEM/39_VALVES.pm line 205.
2014.11.08 21:02:46 1: PERL WARNING: Argument "0%" isn't numeric in multiplication (*) at ./FHEM/39_VALVES.pm line 205.
2014.11.08 21:02:46 1: PERL WARNING: Argument "4%" isn't numeric in multiplication (*) at ./FHEM/39_VALVES.pm line 205.
2014.11.08 21:02:46 1: PERL WARNING: Argument "36%" isn't numeric in multiplication (*) at ./FHEM/39_VALVES.pm line 205.
2014.11.08 21:02:46 1: PERL WARNING: Argument "9%" isn't numeric in multiplication (*) at ./FHEM/39_VALVES.pm line 205.
2014.11.08 21:02:46 1: PERL WARNING: Argument "15%" isn't numeric in multiplication (*) at ./FHEM/39_VALVES.pm line 205.
Ich habe folgende Zeile 192 geändert von ReadingsVal nach ReadingsNum
#get val
- $pos=ReadingsVal($dev,AttrVal($name,"valvesDeviceReading","valveposition"),"err");
+ $pos=ReadingsNum($dev,AttrVal($name,"valvesDeviceReading","valveposition"),"err");
if(!defined($pos) or ($pos eq "err")){
Log3($name, 4, "VALVES $name ".$_." [$pos] DeviceReading not present");
next;
}
push(@raw_average,$pos);
#calc prio
Hallo,
ich leider das genannte Modul 39_VALVES.pm nirgends finden.
Gibt es das nicht mehr oder wurde die Funktionalität durch ein anderes Modul ersetzt?
Danke.
1. Post
Hallo,
das Modul ist am ersten Beitrag angehangen. Einen anderen Speicherort wüsste ich nicht. Leider meldet sich der Autor des Moduls seit Monaten nicht mehr, daher ist es fraglich, ob und wie es mit dem Modul weitergeht.
Viele Grüße, Ricardo
Zitat von: kpwg am 08 März 2015, 15:06:20
Leider meldet sich der Autor des Moduls seit Monaten nicht mehr, daher ist es fraglich, ob und wie es mit dem Modul weitergeht.
- zeitmangel - -falls fehler auftreten sollten werden die natürlich repariert.
-eine neue version ist derzeit nicht geplant, es kann doch alles was es soll ;)
das modul ist in der fußzeile des ersten beitrages in diesem thread downloadbar, link "39_VALVES.pm".
LG, florian
Kannst du in der Zeile 121 das erzeugen der "userAttr" ändern, damit diese nur in VALVES auftauchen.
foreach(split(/,/,$attrVal)){
- addToAttrList("valves".$_."Gewichtung");
+ addToDevAttrList("$name","valves".$_."Gewichtung");
}
Zitat von: stromer-12 am 13 April 2015, 19:57:49
Kannst du in der Zeile 121 das erzeugen der "userAttr" ändern, damit diese nur in VALVES auftauchen.
foreach(split(/,/,$attrVal)){
- addToAttrList("valves".$_."Gewichtung");
+ addToDevAttrList("$name","valves".$_."Gewichtung");
}
..erledigt. Gruß Florian
Heute nach einen restart waren die Attribute wieder da.
Es muss in der Zeile 178 auch noch geändert werden für den ersten Aufruf:
foreach(split(/,/,AttrVal($name,"valvesDeviceList",""))){
- addToAttrList("valves".$_."Gewichtung");
+ addToDevAttrList("$name","valves".$_."Gewichtung");
}
Gruß
Hallo,
bei der Einbindung von VALVES erhalte ich die folgende Fehlermeldung:
2015.09.07 08:54:22 5: Cmd: >Define HeizBedarf VALVES<
2015.09.07 08:54:22 5: Loading ./FHEM/39_VALVES.pm
2015.09.07 08:54:22 1: PERL WARNING: Subroutine VALVES_Initialize redefined at ./FHEM/39_VALVES.pm line 38.
2015.09.07 08:54:22 1: PERL WARNING: Subroutine VALVES_Define redefined at ./FHEM/39_VALVES.pm line 52.
2015.09.07 08:54:22 1: PERL WARNING: Subroutine VALVES_Undefine redefined at ./FHEM/39_VALVES.pm line 64.
2015.09.07 08:54:22 1: PERL WARNING: Subroutine VALVES_Get redefined at ./FHEM/39_VALVES.pm line 69.
2015.09.07 08:54:22 1: PERL WARNING: Subroutine VALVES_Set redefined at ./FHEM/39_VALVES.pm line 94.
2015.09.07 08:54:22 1: reload: Error:Modul 39_VALVES deactivated:
Not enough arguments for main::addToDevAttrList at ./FHEM/39_VALVES.pm line 120, near ""Gewichtung")"
2015.09.07 08:54:22 0: Not enough arguments for main::addToDevAttrList at ./FHEM/39_VALVES.pm line 120, near ""Gewichtung")"
Was mach ich falsch?
Besten Dank!
Genau das Problem hab ich leider auch ;(
Gruß
Henning
Könnt ja mal diese Testen
Hallo,
1. Mit der Datei aus #39 funktioniert das Modul. Ich hatte vorher das Problem wie in #37 beschrieben.
2. Ich habe FHTs (actuator) und Homematic (ValvePosition) in Betrieb. Wie kann ich bei valvesDeviceReading beide Readings angeben? ValvePosition,actuator bringt die Fehlermeldung, dass die DeviceList leer ist. Kann ich überhaupt beide Systeme in ein "VALVE-Device" packen oder muss ich den Umweg gehen und für FHT/Homematic jeweils ein eigenes "VALVE-Device" anlegen?
Die HM Thermostate haben auch ein actuator Reading im Device, Im Channel ist es ValvePosition.
Moin Moin,
sind wir sicher, daß dieses Modul richtig rechnet?
Ich habe meine ganzen Radiatoren mit Homematic-Ventilen mal konfiguriert und es ergibt sich:
Internals:
CFGFN
NAME V_RadiatorenStatus
NR 1104
NTFY_ORDER 50-V_RadiatorenStatus
STATE 30.8666666666667
TYPE VALVES
Readings:
2016-10-05 13:57:28 raw_average 33.7692307692308
2016-10-05 13:57:28 state 30.8666666666667
2016-10-05 14:00:15 valveDetail_EG.Arbeitszimmer.HeizungLinks_Clima pos:100 calc:100 time:2016-10-05 13:59:52
2016-10-05 14:00:15 valveDetail_EG.Esszimmer.HeizungLinks_Clima pos:100 calc:100 time:2016-10-05 13:58:20
2016-10-05 14:00:15 valveDetail_EG.Esszimmer.HeizungMitte_Clima pos:100 calc:100 time:2016-10-05 13:58:43
2016-10-05 14:00:15 valveDetail_EG.Esszimmer.HeizungRechts_Clima pos:100 calc:100 time:2016-10-05 13:53:41
2016-10-05 14:00:15 valveDetail_EG.Garderobe.Heizung_Clima pos:15 calc:15 time:2016-10-05 13:58:09
2016-10-05 14:00:15 valveDetail_EG.Kueche.HeizungLinks_Clima pos:0 calc:0 time:2016-10-05 13:59:27
2016-10-05 14:00:15 valveDetail_EG.Kueche.HeizungRechts_Clima pos:0 calc:0 time:2016-10-05 13:59:26
2016-10-05 14:00:15 valveDetail_EG.Wintergarten.Heizung_Clima pos:0 calc:0 time:2016-10-05 13:59:23
2016-10-05 14:00:15 valveDetail_OG.Schlafzimmer.HeizungLinks_Clima pos:0 calc:0 time:2016-10-05 13:57:54
2016-10-05 14:00:15 valveDetail_OG.Schlafzimmer.HeizungMitte_Clima pos:0 calc:0 time:2016-10-05 13:59:59
2016-10-05 14:00:15 valveDetail_OG.Schlafzimmer.HeizungRechts_Clima pos:0 calc:0 time:2016-10-05 13:58:20
2016-10-05 14:00:15 valveDetail_OG.Wohnzimmer.HeizungLinks_Clima pos:12 calc:12-priority time:2016-10-05 13:59:53
2016-10-05 14:00:15 valveDetail_OG.Wohnzimmer.HeizungRechts_Clima pos:12 calc:12-priority time:2016-10-05 13:59:13
2016-10-05 13:59:52 valve_EG.Arbeitszimmer.HeizungLinks_Clima 100
2016-10-05 13:58:20 valve_EG.Esszimmer.HeizungLinks_Clima 100
2016-10-05 13:58:43 valve_EG.Esszimmer.HeizungMitte_Clima 100
2016-10-05 13:53:41 valve_EG.Esszimmer.HeizungRechts_Clima 100
2016-10-05 13:58:09 valve_EG.Garderobe.Heizung_Clima 15
2016-10-05 13:59:27 valve_EG.Kueche.HeizungLinks_Clima 0
2016-10-05 13:59:26 valve_EG.Kueche.HeizungRechts_Clima 0
2016-10-05 13:59:23 valve_EG.Wintergarten.Heizung_Clima 0
2016-10-05 13:57:54 valve_OG.Schlafzimmer.HeizungLinks_Clima 0
2016-10-05 13:59:59 valve_OG.Schlafzimmer.HeizungMitte_Clima 0
2016-10-05 13:58:20 valve_OG.Schlafzimmer.HeizungRechts_Clima 0
2016-10-05 13:59:53 valve_OG.Wohnzimmer.HeizungLinks_Clima 12
2016-10-05 13:59:13 valve_OG.Wohnzimmer.HeizungRechts_Clima 12
2016-10-05 13:57:28 valve_average 30.8666666666667
2016-10-05 13:51:27 valve_max 100
2016-10-05 13:00:40 valve_min 0
Attributes:
room EG.HWR
userattr valvesEG.Arbeitszimmer.HeizungLinksGewichtung valvesEG.Arbeitszimmer.HeizungLinks_ClimaGewichtung valvesEG.Esszimmer.HeizungLinksGewichtung valvesEG.Esszimmer.HeizungLinks_ClimaGewichtung valvesEG.Esszimmer.HeizungMitte_ClimaGewichtung valvesEG.Esszimmer.HeizungRechts_ClimaGewichtung valvesEG.Garderobe.Heizung_ClimaGewichtung valvesEG.Kueche.HeizungLinks_ClimaGewichtung valvesEG.Kueche.HeizungRechts_ClimaGewichtung valvesEG.Wintergarten.Heizung_ClimaGewichtung valvesOG.Schlafzimmer.HeizungLinks_ClimaGewichtung valvesOG.Schlafzimmer.HeizungMitte_ClimaGewichtung valvesOG.Schlafzimmer.HeizungRechts_ClimaGewichtung valvesOG.Wohnzimmer.HeizungLinks_ClimaGewichtung valvesOG.Wohnzimmer.HeizungRechts_ClimaGewichtung
valvesDeviceList EG.Arbeitszimmer.HeizungLinks_Clima,EG.Esszimmer.HeizungLinks_Clima,EG.Esszimmer.HeizungMitte_Clima,EG.Esszimmer.HeizungRechts_Clima,EG.Garderobe.Heizung_Clima,EG.Kueche.HeizungLinks_Clima,EG.Kueche.HeizungRechts_Clima,EG.Wintergarten.Heizung_Clima,OG.Schlafzimmer.HeizungLinks_Clima,OG.Schlafzimmer.HeizungMitte_Clima,OG.Schlafzimmer.HeizungRechts_Clima,OG.Wohnzimmer.HeizungLinks_Clima,OG.Wohnzimmer.HeizungRechts_Clima
valvesDeviceReading ValvePosition
valvesPriorityDeviceList OG.Wohnzimmer.HeizungLinks_Clima,OG.Wohnzimmer.HeizungRechts_Clima
D.h. es sind 13 Ventile definiert. Die nicht-Nullwerte sind: 100, 100, 100, 15, 12 (Prio), 12 (Prio).
Nach Dokumentation zählen die Priority-Werte doppelt. Es ergibt sich: (100+100+100+15+2*12+2*12) = 363 / 13 = 27.92 als Ergebnis.
Das Modul berechnet jedoch 30.6666 als valve_average, der identisch zu STATE ist. Eine Diskrepanz von ca. 10%. Ich finde auch keine Berechnung, die zu dem Modulwert von 30.6666 führt...?
Danke, -MN
Zunächst sehe ich 4-mal die 100.
Also Summe 463, da die Prio-Devices doppelt gezählt werden. 463/15=30,866.
"valvesPriorityDeviceList ->devices, die doppelt gezählt werden". Der Wert wird nich verdoppelt, s. calc, sondern es gibt jetzt rechnerisch 15 devices. (nicht doppelt gewichtet, sondern doppelt gezählt)
(*seufz*) Es wird wirklich Zeit für die neue Lesebrille...
Danke für die Erläuterungen...
Ciao, -MN
define AlleVentile VALVES
führt zu
Cannot load module VALVES ...
Modul 39_VALVES liegt im Verzeichnis /opt/fhem/FHEM
Neustart brachte keine Besserung ..
was ist zu tun ?
ls -lah /opt/fhem/FHEM
und Besitzer/Leserechte kontrollieren.
Ciao, -MN
Zitat von: harway2007 am 25 Oktober 2016, 01:07:35
define AlleVentile VALVES
führt zu
Cannot load module VALVES ...
Modul 39_VALVES liegt im Verzeichnis /opt/fhem/FHEM
Neustart brachte keine Besserung ..
was ist zu tun ?
bei mir klappts auch nicht.
Benutzerrechte sind geändert wie bei allen anderen x.pm auch.
Woran könnte es noch liegen?
Im Logfile steht folgendes:
2016.11.30 09:20:52 1: PERL WARNING: Subroutine VALVES_Initialize redefined at ./FHEM/39_VALVES.pm line 38.
2016.11.30 09:20:52 1: PERL WARNING: Subroutine VALVES_Define redefined at ./FHEM/39_VALVES.pm line 52.
2016.11.30 09:20:52 1: PERL WARNING: Subroutine VALVES_Undefine redefined at ./FHEM/39_VALVES.pm line 64.
2016.11.30 09:20:52 1: PERL WARNING: Subroutine VALVES_Get redefined at ./FHEM/39_VALVES.pm line 69.
2016.11.30 09:20:52 1: PERL WARNING: Subroutine VALVES_Set redefined at ./FHEM/39_VALVES.pm line 94.
2016.11.30 09:20:52 1: reload: Error:Modul 39_VALVES deactivated:
Not enough arguments for main::addToDevAttrList at ./FHEM/39_VALVES.pm line 120, near ""Gewichtung")"
2016.11.30 09:20:52 0: Not enough arguments for main::addToDevAttrList at ./FHEM/39_VALVES.pm line 120, near ""Gewichtung")"
Nimm mal die Datei aus Posting #39
Update in #1 hochgeladen. LG florian
Hi,
ich habe eine Frage zur Mittelwertberechnung ... als das was in state steht. Bei mir geht es um Thermostatpositionen, also Werte von 0-100.
Ich habe 7 Heizkörper und Gewichtungen wie folgt vergeben:
HK1: 1
HK2: 5
HK3: 1
HK4: 3
HK5: 1
HK6: 2
HK7: 3
Gemessen werden nun folgende Werte:
HK1: 0
HK2: 100
HK3: 100
HK4: 14
HK5: 100
HK6: 100
HK7: 25
Das führt zu folgenden Readings:
HK1: 0
HK2: 500
HK3: 100
HK4: 42
HK5: 100
HK6: 200
HK7: 75
Soweit korrekt. Der Mittelwert ist aber nun 145,285714286. Erwartet hätte ich etwas zwischen 0 und 100.
Problem scheint zu sein, dass durch 7, also die Anzahl der Heizkörper geteilt wurde und nicht durch 16, was den Gewichtungen entspricht und den meines Erachtens korrekten Wert 63,5625 liefert.
Habe ich den Sinn des Moduls falsch verstanden oder ist das ein Fehler? Der aktuelle Mittelwert hat für mich irgendwie keine Aussage ... ich möchte ja wissen zu wieviel Prozent die Thermostate im gewichteten Mittel auf sind um damit z.B. meinen Vorlauf zu regeln. Aber dazu brauche ich eben eine %-Angabe.
Gruss farion
Hallo Farion!
Im Prinzip habe ich die selbe Heizungsteuerung seit über 2 Jahren erfolgreich im Betrieb. ich habe damals auch viel experimentiert, bin aber dann zum Entschluss gekommen, dass weniger oft mehr ist. Ich habe 3 Stockwerke und habe nur die allerwichtigsten Heizkörper genommen, in deren Räume die meiste Energie benötigt wird. Das waren dann ganze 4 Heizkörper. Der Rest steuert sich ohnehin selbst über die Thermostate, sollte aber auf den Wärmebedarf keine Anforderungen stellen dürfen.
Die Wichtungen habe ich alle wieder auf 1 gesetzt, um einen schönen Durchschnitt zu bekommen. Der Durchschnitt ist mir wichtiger als die 5-fach Bewertung eines einzigen Raumes. Mit einem Dummy und Setlist kann ich die Schwellen einstellen, bei welcher Prozentzahl in die Heizkurve und somit der Vorlauf eingegriffen werden soll. Die Schaltschwellen sind schön überlappt und werden nur alle 20 Minuten geprüft. Zusätzlich ist auch noch die Außentemperatursteuerung voll im Betrieb.
In dem unten angehängten Plot ist die Schaltschwelle auf 64% vorgegeben und man sieht das es zu keinerlei Schwingneigung kommt, auch wenn die Wichtung kurzeitige Sprünge macht. Langfristig bestimmt aber die Wichtung den Vorlauf und schon ab Mittag beginnt die Heizkurve immer flacher zu werden weil die Wichtig stetig sinkt. Die Sprünge im Vorlauf kommen, weil das der interne Vorlauf ist und etwas von der Warmwasserentnahme beeinflusst wird. Außerdem wird auch die internen Pumpe geregelt, was man auch im Vorlauf sieht. Steht die Pumpe, steigt der Vorlauf dieses Messpunktes etwas, ist aber für den Steuerung selbst nicht wichtig.
Zusätzlich steuere ich mit einer 2 Wichtung (je Geschoß) noch Pumpen, die ich auch vorzeitig abschalte bevor sich noch die Ventile zu schließen beginnen. Diese Pumpen sind auch Fussbodenheizungen die ohnehin etwas träger sind und spare so auch noch Strom. Bei einer Wichtung von <=20% schalte ich die komplette Heizung ab (Heizkurve auf 0,2).
Wenn ich in einem Raum mehr Wärme wünsche, erhöhe ich den HM Thermostat und wenn notwendig zieht die Heizkurve nach. Das funktioniert bei einer gleich verteilten Wichtung von 1 sehr gut. Bei dir würde es vermutlich nur auf HK2 reagieren, da du vermutlich keine vernünftigen Schaltschwellen findest würdest weil dieser komplett überbewertet ist. D.h. dein HK2 mit Wichtung 5 bestimmt mehr oder weniger alleine den Vorlauf (außer du wünscht das so). Ich kann mir aber vorstellen, dass hier viel kleinere Werte besser wären.
Ich hoffe ich konnte dir einige zusätzliche Überlegungen zu deinem Vorhaben geben. Ich bin mit Valves voll zufrieden, obwohl ich eigentlich nur die Durchschnittsberechnung nutze.
LG
Du musst die Gewichtung so einstellen, dass deren Summe gleich Anzahl der HK ist.
Also 1/7, 5/7, usw. So klappt es bei mir.
Stimme auch Reinhart zu, nicht unbedingt alle HK zu beteiligen.
Edit: das mit /7 ist natürlich zu einfach gedacht und falsch.
@jkriegl
Okay, das ist eine gute Idee um den Bug zu umgehen. Hätte ich auch selber auf die Idee kommen könne. Danke!
@Reinhart
Ich habe relativ unterschiedliche Zimmer 12-45qm. Die grossen Räume sind tendenziell zu kalt und die kleinen tendenziell zu warm. Das wollte ich mit der Gewichtung steuern - inwiefern mir das gelingt weiss ich noch nicht. Ich probiere mal ein bisschen rum.
Gruss farion
Bitte genau lesen, das ist kein bug (zB:0,95 um 5% abzuziehen).
Genau darauf bin ich ja reingefallen. Es geht ja gerade nicht einfach einen Wert zu verändern. Man muss immer alle Werte von 1 so verändern, dass die Gesamtsumme gleich bleibt. Nehmen wir an ich habe 2 Heizungen und ziehe von einer Heizung 5% ab. Dann habe ich 0,95 + 1. Damit verfälsche ich das Ganze, weil es nicht 2, sondern 1,95 ist. D.h. der Maximalwert in diesem Fall ist 97,5 und nicht 100. Lege ich auf eine Heizung 5% drauf, also 1,05 + 1, kann ich Werte bis 102,5 erreichen. Korrekt ist aber nur der genau 0-100. Also muss ich um eine Differenz von 5% zu erreichen 0,975 + 1,025 nehmen. So ist die Idee wenn ich es richtig verstanden habe.
Genau so ist es.
Das mit /7 ist natürlich falsch. Der berühmte Satz hilft weiter.
... mal ne blöde Frage: Seit wann funktioniert denn das nicht mehr? Habe ich irgendwie nicht mitbekommen ...
Ich hatte das Modul vor längerer Zeit mal im Einsatz, es aber seinerzeit aus verschiedenen Gründen raus genommen. Heute wollte ich das Modul wieder aktivieren und musst efeststellen, das es erst einmal gar nicht mehr vorhanden war, also bei irgend einem Update verschütt gegangen ist. Also habe ich das Modul von hier aus dem ersten Beitrag herunter geladen und ins Verzeichnis /contrib/ geschmissen. Aber auch nach einem Neustart wird das Modum nicht gefunden: "Unknown module VALVES"
Verpeile ich da gerade etwas oder funktioniert das schlicht und ergreifend nicht mehr?
Und wenn es nicht mehr funktioniert, gibt es irgend etwas vergleichbares?
Module in contrib haben sich noch nie laden lassen. Moduldateien gehören immer nach FHEM/
Du hast vollkommen recht ... Hab ich doch was verpeilt :o
Danke für den Hinweis; da hätte ich mir wieder tagelang ne'n Wolf gesucht ::)
Moin, hab da mal ne kleine Frage. Im Modul werden die Readings mit valve_ ja per setReadingsVal angelegt. Diese kann ich allerdings nicht loggen. Gibt es dort vielleicht ähnlich wie beim readingsSingleUpdate ein bool Flag, ob ein Event erzeugt werden soll oder nicht?
Mir ist bewusst, dass ich die valve-Werte aus den einzelnen Devices bekomme, aber wenn ich schon alle in einem Device habe, würde ich gerne den faulen Weg gehen.
Lege Dir für Dein VALVES-Objekt ein stateFormat an:
{sprintf("%.1f",ReadingsVal("V_RadiatorenStatus","state",0))."%"}
V_RadiatorenStatus ist bei mir der Name des VALVES-Objektes. Dann kannst Du ganz normal ein FileLog darauf werfen und die durchschnittliche Ventilposition visualisieren...
Ciao, -MN
Danke. Aber ich will ja die einzelnen Valve-Stellungen visualisieren und nicht den Schnitt.
Die stehen doch in den Readings der Heizungsthermostaten...? Einfach ein FileLog darauf?
Da ist ein Perl-Regexp-Filter - wenn Du Deine Heizungsthermostaten einheitlich benennst, kannst Du das ganz einfach erschlagen.
Ciao, -MN
Hast ja Recht ;) Danke.
Hallo, würde das Mobul es auch gerne wieder bnutzen
Hi, ich betreibe zwei verschiedene Thermostatentypen, entsprechend habe ich zwei unterschiedlich bezeichnete readings... Muss ich ein zweites Valve-Device anlegen oder bekomme ich das irgendwie in einem unter?
Stichwort userReadings ist dein Freund :)
bin etwas eingerostet und war nie sooo tief in FHEM drin ;) Hilf mir auf die Sprünge ;)
naja angenommen du verwendest heute bei den Guten : "valvepostion"
und die Neuen verwenden aber "Valve-Position"
dann musst du den Neuen klar machen das sie ihr Valve-Position auf ein User Reading mit Namen valvepostion umkopieren sollen.
Deine Ventilstellung hat dann halt bei denen zwei Readings.
attr <name> userReadings valvepostion:Valve-Position:.* {ReadingsNum($name, 'Valve-Position', 0)}
die Begriffe <name> , valvepostion und Valve-Position musst du natürlich auf deinen Gegebenheiten anpassen.
ah, ja logisch... Das passiert, wenn man nur einmal im Jahr am FHEM bastelt. Man muss sich immer wieder alles neu draufschaffen. Danke Dir!
Hallo Florian,
hallo zusammen,
nachdem jüngst (https://forum.fhem.de/index.php/topic,127445.0.html (https://forum.fhem.de/index.php/topic,127445.0.html)) mal wieder ein potentieller Anwendungsfall hier aufgetaucht war, habe ich mir meine eigene (eigentlich nur so vor sich hin dümpelnde und mangels Zugriff auf die Therme nicht effektiv genutzte) VALVES-Definition und den Code mal näher angesehen...
Rausgekommen ist ein Vorschlag für aktualisierter 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.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.
@Florian: Falls du überhaupt noch aktiv bist (die letzte Anmeldung war anscheinend vor ca. 2 Jahren), kannst du das gerne weiterverwenden und/oder in den ersten Post übernehmen.
Falls es Interessenten/Tester gibt, würde ich ggf. noch eine gepackagte Version daraus machen (Perlcritics hat nur noch wenig zu mosern) und das ggf. auch entweder in contrib oder den allgemeinen Modulbestand einchecken, mal sehen, auch was Florian ggf. dazu meint.
Grüße,
Beta-User
Hmm, es besteht demnach kein Interesse/Bedarf?
Oder ist es schlicht die falsche Jahreszeit...?
@beta-user
Moin ,
Ich habe Valve vor einiger Zeit entdeckt und habe meine HM-Thermostate damit angebunden. Bisher eigentlich nur zur Anschauung im SVG.
Und wie du ja festgestellt hast, im Sommer passiert nichts weil alle Ventile auf sind ;D
Werd ich auf meine ToDo-Liste setzen und bei Gelegenheit einspielen.
Gruß Gerd
Moin beta-user,
Es ist wohl einfach wirklich nur die falsche Jahreszeit.
Und vielleicht ein wenig allgemeine Abwanderung der User von fhem und dem Forum.
Ich werde es mir im Spätsommer/Herbst auf jeden Fall mal zu Gemüte führen, danke dir.
Nur ganz ohne use case tue ich mich einfach schwer im Sommer damit
Gruss
Maui
OK, Danke erst mal für die Interessensbekundungen!
Das mit dem "virtuellen Leitraum" scheint ja doch nicht komplett uninteressant zu sein ;D ...
Dass das grade wetterbedingt nicht mehr allzu hoch im Kurs steht, liegt "in der Natur der Sache", aber vermutlich werden die Temperaturen irgendwann auch wieder so frostig wie das Klima zu größeren Gas-Lieferanten, und das Interesse am Erkennen des eigenen Spar-Potentials dürfte tendenziell sogar größer sein wie bisher...
Wie dem auch sei, eine gepackagte Version ist grade im Test und kommt dann bei Gelegenheit auch hier als Angebot, und wenn jemand noch was vermißt an dem Modul, wäre jetzt auch die Gelegenheit, das einzukippen ;) .
Ansonsten hatten wir sein Ende Februar ca. 500 Neuanmeldungen im Forum, von daher glaube ich nicht unbedingt, dass das allgemeine Interesse erlahmt ist (es wundert mich eher, dass es so viele sind, weil doch zu fast allem "alles geschrieben" ist...).
Zitat von: Beta-User am 07 Juli 2022, 12:37:29
eine gepackagte Version ist grade im Test und kommt dann bei Gelegenheit auch hier als Angebot, und wenn jemand noch was vermißt an dem Modul, wäre jetzt auch die Gelegenheit, das einzukippen ;) .
Da heute zum einen der erste leichte Morgennebel hier rumgewabert ist und meine Junkers jetzt via CAN->ESP32->MQTT Daten liefert und auch gesteuert werden kann (https://www.mikrocontroller.net/topic/81265 (https://www.mikrocontroller.net/topic/81265) bzw. https://github.com/Neuroquila-n8fall/JunkersControl (https://github.com/Neuroquila-n8fall/JunkersControl) (mit geringfügigen Tweaks)), greife ich den Ball mal wieder auf und liefere erst mal die angekündigte package-Version. (Soweit ich mich entsinne: keine funktionalen Änderungen zu meinem letzten Stand).
Wird vermutlich etwas dauern, bis mir klar ist, wie man das am effektivsten zusammenpuzzelt, aber bei einem "Heizkörper-only"-beheizten Gebäude dürfte nach den Berichten von Dave G. im Mikrocontroller-Forum die Variante mit dem "Leitraum" das Mittel der Wahl sein. VALVES rückt daher in meiner persönlichen Prioritätenliste ziemlich nach vorne ;) .
Jetzt wo die Temperaturen fallen (und die Gaspreise steigen) will ich mich auch mal mit valves bzw. Dem virt. Leitraum beschäftigen.
Allerdings bin ich mir nicht sicher, ob es in meinem Fall nicht sinnvoller wäre ein wenig vorher anzusetzen.
Ich regele nämlich all meine Thermostate mit PID20 und schubse die Ventile nur frühestens alle 15 Min (1% Regel, Verhindern von "Ventil-Zappeln").
Kann ich valves vielleicht einfach so benutzen, dass es statt ventil-devices pid20-devices nutzt und mit deren actuationCalc-reading ein virt. Leitraum erstellt wird?
Wie ändert ihr/du eigentlich die Vorlauf-Temp? Verstellst du Neigung und Niveau oder kommst du direkt an die Vorlauf-Temp?
Edit: hab valves mal eingespielt und zum Test 2 pids auf die Liste gesetzt.
Zur sauberen Berechnung eines gewichteten Mittels müsste ich wohl jetzt noch mit userReadings das actuationCalc reading wie actuation in den Bereich zwischen 0 und 100 begrenzen.
Zitat von: Maui am 16 September 2022, 14:11:25
Kann ich valves vielleicht einfach so benutzen, dass es statt ventil-devices pid20-devices nutzt und mit deren actuationCalc-reading ein virt. Leitraum erstellt wird?
[...]
Edit: hab valves mal eingespielt und zum Test 2 pids auf die Liste gesetzt.
Zur sauberen Berechnung eines gewichteten Mittels müsste ich wohl jetzt noch mit userReadings das actuationCalc reading wie actuation in den Bereich zwischen 0 und 100 begrenzen.
Kenne PID20 bisher nicht, aber den Trick mit dem "passenden Reading per TYPE" scheinst du ja gefunden zu haben. Der Wertebereich dürfte eigentlich sogar gleichgültig sein, solange alle Beteiligten Devices denselbe Range benutzen. Die Korrektur auf "0-100" für Gewichtungen sollte auch mit anderen Wertebereichen klarkommen, das dient nur dazu, das Ergebnis passend zu skalieren.
Zitat von: Maui am 16 September 2022, 14:11:25
Wie ändert ihr/du eigentlich die Vorlauf-Temp? Verstellst du Neigung und Niveau oder kommst du direkt an die Vorlauf-Temp?
Im Moment produktiv noch gar nicht (Dave baut grade die firmware nochmal grundlegend um), aber wenn dann hoffentlich demnächst alles klappt, habe ich vollen Zugriff auf die VLT, mit der Wahl, einfach die Heizkurve anders einzustellen, oder eben noch zusätzlich eine dynamische Adaption zu machen anhand der Ventil-Öffnung (der ESP macht also z.B. etwas wärmer als per Heizkurve zu erwarten, wenn die Ventile insgesamt mehr geöffnet sind als Durchschnitt). Leider klappt bei mir grade der Zugriff auf den CAN-Bus nicht mehr, ich vermute, die ESP-GPIO teilweise abgeschossen zu haben...
Dazu dann die Möglichkeit, die WW-Bereitung per weekprofile/WeekdayTimer zu steuern, Brennersperren zu setzen pi pa po 8) .
Ich nutze trotzdem lieber begrenzte readings mit range (0-100) weil sonst zb ein geöffnetes Fenster eine errechnete Ventilstellung auf -500 bedeutet und somit den Mittelwert unnötig verkleinert.
Vorlauf direkt setzen scheint nicht zu gehen bei Viessmann zumindest krieg ich es grad nicht hin.
Müsste ich dann wohl über Niveau und Neigung gehen. Macht das Gerechne nur leider komplizierter.
An WW-Bereitung arbeite ich bei mir auch schon fleissig, bin aber an sich weg von Zeiten hin zu manuellem Anstossen per fhem also Temp WW-Speicher < x = WW-Bereitung und den Rest der Zeit Abschaltbetrieb.
Nur jetzt im Winter geht das leider nicht so, da Heizen immer WW inkludiert und man die nicht getrennt ansteuern kann.
In der Heiz Zeit mache ich jetzt schon was ähnliches beim Heizen, nämlich ein Wechsel auf nur WW wenn die Temp in den Räumen fast erreicht ist. Viessmann ist sehr gross im modulieren was dann sonst in dem Bereich zu ständigen unnötigen Brennerstarts führt.
Aber ich will den thread hier auch nicht sprengen mit OT.
Ich drück dir die Daumen dass du bald wieder Zugriff auf die Heizung hast und werde mir valves mal genauer angucken und gucken wie ich das mir dann genau bastel mit dem Leitraum.
Moin zusammen,
ich habe mir jetzt die Version von Beta-User installiert und alle meine HM-Heizungsventile eingeben. Die Gewichtung habe ich erst mal aus meiner bisherigen Lösung mit userReadings aus Ventilstellung und Faktor aus Raumgrösse, Heizkörpergrösse und "Erfahrung" übernommen. Ich werde beobachten, wenn die Heizung wieder gebraucht wird, ob das passt. Als nächstes klöppel ich die bisherige Steuerung der Buderus Gasheizung so weit es über die KM200 geht um. Für diese Anpassung finde ich gerade auch die OT Beiträge hier ganz hilfreich :)
Gas Verbrauch für Heisswasser habe ich dank FHEM, Bewegungsmelder, DWD und KM200 schon auf ein Minimum reduziert, ohne dass meine kritischen Mitbewohner sich beschweren. Ziel ist es sparen, ohne den Komfort zu reduzieren. Mal sehen, ob das beim Heizen auch so gut klappt. Dieses Modul wird mit Sicherheit ein wichtiger Baustein dafür.
Gruss
Enno
Nabend,
Ich hab mich bei der Veränderung der Vorlauf-Temp. Jetzt erst einmal bewusst für die Neigung entscheiden, um eine Abhängigkeit der Außentemperatur mit drin zu haben. Also grössere Änderungen bei niedrigeren Temperaturen. Ob das klug war, werde ich dann im Winter sehen.
Das setzen mache ich einfach per doif in 10% Schritten.
Jetzt muss ich nur noch irgendwann die Heizung anwerfen und dann fleissig die Parameter anpassen im Betrieb
:) Dann mal wilkommen beim Experimentieren.
Habe mir vermutlich die CAN-Boards abgeschossen, muss jetzt erst mal auf Ersatz warten...
Hallo,
auf Grund der aktuellen energiepolitischen Lage habe ich mich endlich mal mit den Möglichkeiten meiner Therme (Brötje WBS14F) auseinandergesetzt. Dort habe ich die benutzerdefinierten Eingänge so parametriert, dass ich Trinkwarmwasser- und Heizkreis-Bedarfsanforderung von fhem aus per Tasmota-Relays schalten kann.
Jetzt stellt sich die Frage: Was mache ich damit?
TWW ist eigentlich fast erledigt: Das läuft über Zeitpläne, Anwesenheitsstatus und manuelle Anforderung.
Für die Heizungen scheint das VALVES-Modul ein guter Ansatz. Ich habe 7 FHTs wo ich ja direkt auf die Ventilstellung zugreifen kann. So weit so gut.
Zusätzlich habe ich dann noch 4 Räume in denen ich Fußbodenheizung (FBH) habe. Dort regelt fhem seit Jahren die Temperatur. Es gibt jeweils einen Fühler der die Raumtemperatur misst, diese ist die Führungsgröße für ein PID20-Modul. Direkt unter/auf dem Estrich habe weitere Temperaturfühler welche die Bodentemperatur messen. Mit THRESHOLD und den Bodenfühlern steuere ich recht einfach die Bodentemperatur über An und Aus der Ventile. Der Vorgabewert für THRESHOLD kommt dabei von dem PID20-Modul in Temperaturbereich von 18 bis 28 Grad.
Jetzt die große Frage: Kann ich irgendwie mit VALVES sinnvoll die unterschiedlichen Systeme (FHT & FBH) zusammenführen?
Ich möchte mit VALVES und NOTIFY dann bei einem bestimmten Schwellwert die Bedarfsanforderung an der Therme schalten.
Ich könnte jetzt auf die Ventile gehen (zusätzliches Userreading actuator mit off=0%, on=100%), dass scheint mir aber eher ungeeignet.
Bleibt noch der PID20-Regler, aber irgendwie weiß ich auch nicht so recht wo ich hier ansetzen soll und:
Wie bringe ich VALVES unterschiedliche Wertebereiche zwischen FHT und FBH bei.
Oder ich nehme zwei VALVES und baue die beide in einem Dummy oder-Verknüpft zusammen?
Stehe da etwas auf dem Schlauch und freu mich über hilfreiche Kommentare.
Gruß
sweetie-pie
Also grundsätzlich würde ich die FBH niedriger wichten aufgrund der Trägheit. Und das dann vermutlich alles zusammen in 1 Valves packen. Zb alle nicht-FBH mit Faktor 2 wichten (oder halt auch nach Raum-Wichtung für dich) und die FBH dann eben mit 1.
Und wegen den PID20, da habe ich mir ein userReading gebaut welches nur zwischen 0 und 100 kann und auf actuationCalc geht.
Das Ergebnis aus valves werte ich dann in einem DOIF mit 10min Pause zwischen den commands aus ( Trägheit Heizung) und drehe je nach aktuellem bedarf Heizkurve bzw. Steigung runter bzw. Sogar ganz auf WW-Modus.
Subjektiv betrachtet fahre ich damit bisher sehr gut wobei ich auch weniger heize als sonst und somit natürlich nicht so richtig aussagefähig bin.
Hallo zusammen, ich denke mal, dass ich mich gern aus Benutzersicht in diesen Thread einklinken will.
Kurz zu meinem Anwendungsszenario:
- Alle Räume sind mit HM-CC-RT-DN ausgestattet. Ich kenne also die Ventilstellungen, die sich aus der vorgegebenen Wunschtemperatur für den jeweiligen Raum ergeben
- Ich kenne die Aussentemperatur und sie steht FHEM zur Verfügung. Daraus könnte ich unter Berücksichtigung der Gegebenheiten des Hauses eine Heizkurve / Vorlauf ableiten.
- Die Heizkreispumpe soll nur dann angehen, wenn überhaupt Leistung von den Heizkörpern abgefordert wird. Also eine Ventilstellung > x% von einem oder mehreren Ventilen
- Jetzt baue ich gerade die Heizungsanlage neu. Ein Holzscheitvergaser wird zukünftig den einen Pufferspeicher speisen. Eine Gastherme soll nur dann einspringen, wenn der Holzscheitvergaser aus ist und die Puffertemperatur unter einen Sollwert fällt.
- Wenn der Holzvergaser läuft, dann läuft er. Also muss ich den Vorlauf durch einen Mischer bedarfsgerecht steuern.
Ich denke, Module wie VALVES oder STELLMOTOR können hier gut zusammenarbeiten. Allerdings ist keines der Module offiziell eingecheckt, was mich natürlich bei dieser kritischen Anwendung beunruhigt.
Also, ich habe ein Rieseninteresse an einem solchen Modul, das idealer Weise die entsprechenden Trigger für HK-Pumpe an/aus oder MischerTemp +/- liefern kann.
Vorab mal freut es mich, dass sich doch einige gefunden haben, die das Thema interessiert.
Zitat von: RaspiCOC am 24 Oktober 2022, 12:44:15
Ich denke, Module wie VALVES oder STELLMOTOR können hier gut zusammenarbeiten. Allerdings ist keines der Module offiziell eingecheckt, was mich natürlich bei dieser kritischen Anwendung beunruhigt.
Also, ich habe ein Rieseninteresse an einem solchen Modul, das idealer Weise die entsprechenden Trigger für HK-Pumpe an/aus oder MischerTemp +/- liefern kann.
Na ja, zum einen liegen die Module ja schon eine ganze Zeit hier im Forum bereit und werden von daher voraussichtlich nicht so einfach von der Bildfläche verschwinden, zum anderen hatte ich zum Thema VALVES ja schon angekündigt, dass ich am überlegen bin, ggf. die Pflege offiziell zu übernehmen und das dann - je nachdem - entweder in contrib oder als reguläres Modul mit einzuchecken.
Da ich grade auch am überlegen bin, meine Sommerbasteleien "aufzubohren" und sowohl PV wie auch Solarthermie auf's Dach zu knallen (letzteres dann mit Heizungswasser-Speicher, denke grade so an 800l), wollte ich mir "STELLMOTOR" auch mal ansehen. Bis vorhin war mir auch nicht klar, dass das aus derselben Feder stammt und denselben Status hat. Allerdings kann es auch sein, dass ich den Teil auf eine MCU auslagere oder einfach einen Rollladenaktor dafür verwende...
(Und bzgl. der dahinterstehenden OT-Frage schon klar: PV ist universeller als Thermie, man kann alternativ über einen Durchlauferhitzer nachdenken, ist effektiver und billiger... Der Punkt ist: die fragliche Fläche ist wegen Teilverschattung und dem Zuschnitt nicht wirklich gut für PV geeignet, und das muss sich auch nicht in 10 Jahren gerechnet haben).
Ich bin ehrlich gesagt etwas überrascht, dass dieses Themenfeld bisher nur in der Codeschnipsel-Ecke unterwegs ist. Gern beteilige ich mich mit Ideen und Diskussionen. Hinsichtlich Entwicklung muss ich aber zurücktreten - kann ich schlichtweg nicht.
Vom Gefühl her glaube ich, dass wir hier an der kompliziertesten Ecke der Heizungstechnik unterwegs sind. Es gibt hier so viele Parameter zu berücksichtigen. Ich glaube auch, dass es am Markt keine Out-of-the-Box-Lösung gibt. Auch glaube ich, dass - soweit ich die beiden Modue verstanden habe - VALVES und STELLMOTOR zusammengehören.
OT: Ein 800 Liter Puffer kann schnell knapp werden, wenn es komfortabel sein soll.
Schon mal so ein paar weitere Punkte, die mir so einfallen:
- Die aktuelle Puffertemperatur am Ausgang Heizungsvorlauf entspricht der maximalen erreichbaren Vorlauftemperatur in diesem Augenblick. D.h. diese muss gemessen werden und FHEM sollte sie kennen.
- Dann haben wir noch die tatsächlichen Vorlauftemperaturen vor und hinter dem Mischer. Wenn ich es richtig verstehe, dann kann ich mit dem Mischer immer nur Rücklaufwasser in den Vorlauf einmischen, um die Temperatur herabzusetzen. D.h. ich kann nicht einfach sagen, drehe den Mischer auf 80% und ich habe die gewünschte Vorlauftemperatur. Die kann ich m.E. nur durch das Mischungsverhältnis und die vorhandenen Temperaturen vor und hinter dem Mischer schätze / errechnen.
- Wenn die Heizkreispumpe aus ist, dann sollten sich die Temperaturen vor und hinter dem Mischer angleichen. Auf alle Fälle will ich dann ja keine Regelung des Mischers haben. Wir jetzt aber die Heizkreispumpe angeschaltet, dann muss sich der Mischer wieder an den Sollwert rantasten. Hier frage ich mich, wie schnell ein NTC auf die Temperaturänderung reagiert. Also würden zu schnelle Steuerungsschritte zu einem sinnlosen Herumschwingen des Stellmotors führen. Geht die HK-Pumpe an, dann will ich so schnell wie möglich die angestrebte Vorlauftemperatur bekommen. Die liegt mir aber nicht vor dem Mischer sondern beim Auslass des Puffers vor. Jetzt könnte ich aus der Pufferausgangstemperatur und der aktuellen Temperatur des Rücklaufs ein Mischungsverhältnis errechnen und den Schrittmotor in die halbwegs richtige Richtung fahren.
- Ich könnte auch die Stellungen der Ventile mit einfliessen lassen. Geht ein Ventil auf 100%, also das klassische Guten Morgen Szenario, dann könnte ich die Vorlauftemperatur ja sogar noch etwas höher gehen lassen.
- Dann treibt mich auch noch um, wie man die Heizkennlinie darstellen könnte. Was kenne ich? Aussentemperatur und den energetischen Zustand des Hauses. Also die Frage ob eher steil oder flach kann man sicherlich beantworten. Also könnte man eine Kennlinie vordefinieren. Aber muss die tatsächlich in der Granularität einer mathematischen Funktion vorliegen, oder reicht es nicht einfach 5 Kelvin Schritte zu nehmen, um auch hier viele, viele Stellvorgänge und die sich daraus sicherlich ergebenden Neukalibierungen zu reduzieren?
- Wie oft muss ich denn eigentlich neu kalibrieren? Während des Tags drehe ich den Motor in x-Sekundenschritten auf und zu. Damit müsste man ja eigentlich hinkommen. Irgendwann addieren sich aber Fehler durch die Latenzen zusammen (das hat das Modul Stellmotor ja schon drauf - was aber mit einem kleinen Nachlauf des Motors?
- Und zu guter Letzt haben wir es mit mehreren Devices zu tun. Wir haben HK-Pumpe und wir haben vermutlich 2 Devices für Mischer-auf und Mischer-zu (wobei Mischer-auf und Mischer-zu niemals gleichzeitig aktiv sein dürfen, oder?)
All das kann man sicherlich mit notifies, doifs etc zusammenbauen. Aber, ich denke das wäre zu aufwändig und Fehler finden dürfte grausam werden.
Zitat von: RaspiCOC am 24 Oktober 2022, 16:51:21
Ich bin ehrlich gesagt etwas überrascht, dass dieses Themenfeld bisher nur in der Codeschnipsel-Ecke unterwegs ist. Gern beteilige ich mich mit Ideen und Diskussionen. Hinsichtlich Entwicklung muss ich aber zurücktreten - kann ich schlichtweg nicht.
Na ja, VALVES ist kein Hexenwerk, und vermutlich STELLMOTOR auch nicht. "Kann ich nicht" dachte ich auch mal...
Das Schwierigste ist meistens, erst mal festzulegen, WAS genau passieren soll.
Zitat
Vom Gefühl her glaube ich, dass wir hier an der kompliziertesten Ecke der Heizungstechnik unterwegs sind. Es gibt hier so viele Parameter zu berücksichtigen. Ich glaube auch, dass es am Markt keine Out-of-the-Box-Lösung gibt. Auch glaube ich, dass - soweit ich die beiden Modue verstanden habe - VALVES und STELLMOTOR zusammengehören.
Ich dachte früher auch mal, dass es die "komplizierteste Ecke" sei, habe da aber in der jüngeren Vergangenheit jetzt ein paar "aha"-Erlebnisse gehabt. Vielleicht eine kurze Zusammenfassung meiner aktuellen Gedankenwelt:
- VALVES kann als Indikator dienen, wie groß der aktuelle Wärmebedarf ist
- Ihm fehlt (derzeit jedenfalls noch) jegliche Tendenzaussage (als sowas wie "schnell steigend", "gleichbleibend", "fallend")
- Ein optimiertes Heizungssystem sollte möglichst gleichmäßig laufen, also "schnell sehr heißes Wasser" zu verteilen ist mAn. nicht der richtige Ansatz. Besser ist es, immer gerade soviel Wärme ins System zu geben, wie tatsächlich gebaucht wird => die Ventile sollten sich möglichst wenig bewegen und (nach der "Ersterwärmung") den Tag über irgendwo im Mittelfeld des Einstellbereichs "festgetackert" sein
- Dazu ist die Möglichkeit sinnvoll, die Vorlauftemperatur regeln zu können, und zwar möglichst eben immer "knapp über Minimum". Dazu genügen relativ wenige Parameter, jedenfalls wenn ich den Code von Dave G. für den Junkers-ESP richtig verstanden habe (dazu gibt es eine gute Seite, die den relativ einfachen Verlauf einer Beispiel-Linie zeigt - https://github.com/Neuroquila-n8fall/JunkersControl#heating-parameters).
- Hilfreich ist STELLMOTOR dann, wenn man einen Mischer braucht, um aus "sehr heißem Wasser" dann eben passend temperiertes Wasser zu machen. Ohne Speicher wäre das auch ohne STELLMOTOR gegangen - nur über die Modulationsfunktion der Gastherme, wobei dann in unserem Fall eigentlich der ESP dann die Umrechnung von VALVES-Infos in (relative) Änderungen der Vorlauftemperatur vornehmen sollte (Dave hat das zwischenzeitlich ähnlich gemacht und eine Mittelwertbildung vorgenommen, soweit ich das verstanden habe, jetzt auch mit der Vorgabe, dass die Ventile optimalerweise so um die 30% offen sein sollen).
ZitatOT: Ein 800 Liter Puffer kann schnell knapp werden, wenn es komfortabel sein soll.
Nach einem kurzen Telefonat mit dem voraussichtlichen Leiferanten für den Röhrenkollektor habe ich den jetzt auf 400l verkleinert, und selbst das ist die Obergrenze dessen, was mir bei der vorhandenen Kollektorfläche iVm. der Leitungslänge empfohlen wurde...
Zitat
Schon mal so ein paar weitere Punkte, die mir so einfallen:
- Die aktuelle Puffertemperatur am Ausgang Heizungsvorlauf entspricht der maximalen erreichbaren Vorlauftemperatur in diesem Augenblick. D.h. diese muss gemessen werden und FHEM sollte sie kennen.
- Dann haben wir noch die tatsächlichen Vorlauftemperaturen vor und hinter dem Mischer. Wenn ich es richtig verstehe, dann kann ich mit dem Mischer immer nur Rücklaufwasser in den Vorlauf einmischen, um die Temperatur herabzusetzen. D.h. ich kann nicht einfach sagen, drehe den Mischer auf 80% und ich habe die gewünschte Vorlauftemperatur. Die kann ich m.E. nur durch das Mischungsverhältnis und die vorhandenen Temperaturen vor und hinter dem Mischer schätze / errechnen.
Klar muss man einige Temperaturen erfassen und dann darauf reagieren. Allerdings sollte man m.E. von allzu hektischen Eingriffen Abstand nehmen, sondern praktisch immer erst abwarten, ob eine ergriffene Maßnahme wirkt (und wenn ja wie). Ergo würde ich z.B. in der Regel mit dem letzten Mischerwert starten, wenn die Zirkulationspumpe wieder anläuft (falls man die überhaupt "am Tag" ausmacht).
Dann warten, was am Rücklauf zurückkommt, und wie schnell ggf. auch die Thermostate reagieren - wobei das bei den Homematics ja _Minimum_ 2,5 Minuten sind, bis da was gemeldet wird!
Zitat
- Wenn die Heizkreispumpe aus ist, dann sollten sich die Temperaturen vor und hinter dem Mischer angleichen. Auf alle Fälle will ich dann ja keine Regelung des Mischers haben. Wir jetzt aber die Heizkreispumpe angeschaltet, dann muss
Wie gesagt: lieber etwas warten und ggf. dann auch die Messpunkte so setzen, dass klarer identifizierbar ist, was was ist (Puffertemp im/am Puffer), Vorlauf ein Stück weg vom Mischer, Rücklauf auch etwas vor dem Eingang in den Puffer etc..
ZitatAll das kann man sicherlich mit notifies, doifs etc zusammenbauen. Aber, ich denke das wäre zu aufwändig und Fehler finden dürfte grausam werden.
Weiß noch nicht, ob sich das alles so weit standardisiert runterbrechen läßt, dass man auf eine individuelle Programmierung wirklich verzichten kann und wo es ggf. auch sinnvoll ist, (teil-) autonome Systeme (ähnlich dem Junkers-ESP) vorzusehen und lediglich die zu parametrieren und mit aktuellen Daten zu versorgen.
Prinzipiell scheint es mir so, dass man grade vor dem Hintergrund der immer weiter sich aufdröselnden Möglichkeiten gut daran tut, sich auszutauschen, sonst macht man nämlich am Ende evtl. das Falsche!
Zitat von: Beta-User am 24 Oktober 2022, 17:31:04
- Ein optimiertes Heizungssystem sollte möglichst gleichmäßig laufen, also "schnell sehr heißes Wasser" zu verteilen ist mAn. nicht der richtige Ansatz. Besser ist es, immer gerade soviel Wärme ins System zu geben, wie tatsächlich gebaucht wird => die Ventile sollten sich möglichst wenig bewegen und (nach der "Ersterwärmung") den Tag über irgendwo im Mittelfeld des Einstellbereichs "festgetackert" sein
- Dazu ist die Möglichkeit sinnvoll, die Vorlauftemperatur regeln zu können, und zwar möglichst eben immer "knapp über Minimum". Dazu genügen relativ wenige Parameter, jedenfalls wenn ich den Code von Dave G. für den Junkers-ESP richtig verstanden habe (dazu gibt es eine gute Seite, die den relativ einfachen Verlauf einer Beispiel-Linie zeigt - https://github.com/Neuroquila-n8fall/JunkersControl#heating-parameters).
Von der Physik her würde ich dir da sofort Recht geben, aaaber
-da kommen dann ja auch noch Störgrössen hinzu wie geöffnete Fenster zum Lüften
-oder "dumme" Thermen welche aufgrund des geringen Energiebedarfs anfangen zu takten und somit (zumindest wohl bei mir) dadurch eher mehr Gas verbraten durch häufiges Anspringen.
Ich versuche daher eher wie beim Auto zu "segeln" also bei geringem Wärmebedarf die Therme zum Abstellen zu zwingen.
Das ganze Thema ist halt leider auch immer super individuell und kaum in Gänze auf einen Nenner zu bringen.
Ich bin offen für Austausch und freue mich auf Input oder auch wie du sagst einfach ein Austausch, um die eigenen Fehler festzustellen.
Die Frage ist, ob der Thread hier der richtige Ort dafür ist :)
Zitat von: Maui am 24 Oktober 2022, 19:39:55
Das ganze Thema ist halt leider auch immer super individuell und kaum in Gänze auf einen Nenner zu bringen.
Das ist leider sehr richtig und spricht dafür Kernfunktionen auch getrennt voneinander zu lassen. Den größten Spielraum für einen sinnvollen FHEM Einsatz finden wir aber sicherlich bei hybriden Heizungssystemen mit Puffer. Hier kann FHEM die volle Stärke ausspielen und die ganze Sensorik so einbinden, wie es keine Kauflösung von der Stange kann.
Zitat von: Maui am 24 Oktober 2022, 19:39:55
Die Frage ist, ob der Thread hier der richtige Ort dafür ist :)
Ist er m.E. nicht. Vorschlag: Es gibt einen "Zentralartikel" http://www.fhemwiki.de/wiki/Grundlagen_der_Heizungssteuerung, der eigentlich ganz gut als Start- und Sammelpunt dienen könnte. Vielleicht würde es Sinn machen, ähnlich wie bei den MQTT-Themen oder der Photovoltaik-Eigenverbrauchs-Steuerung dazu eine zentrale Diskussion im Wiki-Bereich zu starten?
Sobald man dann dort ein "Spezialthema" hat, könnte man dazu einen eigenen Thread im passenden Forumsbereich aufmachen...
Zitat von: Maui am 24 Oktober 2022, 19:39:55
Das ganze Thema ist halt leider auch immer super individuell und kaum in Gänze auf einen Nenner zu bringen.
Weiß nicht recht. Die grundlegenden Fragen sind doch eigentlich immer dieselben, nur die Frage der Umsetzung variiert. Erinnert mich ein wenig an Diskussionen rund um das Thema Rollladensteuerung.
Zitat von: RaspiCOC am 24 Oktober 2022, 22:47:43
Das ist leider sehr richtig und spricht dafür Kernfunktionen auch getrennt voneinander zu lassen. Den größten Spielraum für einen sinnvollen FHEM Einsatz finden wir aber sicherlich bei hybriden Heizungssystemen mit Puffer. Hier kann FHEM die volle Stärke ausspielen und die ganze Sensorik so einbinden, wie es keine Kauflösung von der Stange kann.
Prinzipiell sehe ich das ähnlich, bestimmte Teilaspekte sind jeweils bei einem "Spezialisten" für den Teilaspekt vermutlich besser aufgehoben. Das bedeutet aber nicht, dass es nicht sinnvoll erscheint, sich die Verzahnung von verschiedenen Teilen mal anzusehen. M.E. gutes Beispiel für eine bessere wechselseitige Integration ist m.E. weekprofil+WeekdayTimer. Man ändert den "Modus" (Topic), und schon "tickt" die komplette Heizung eines Hauses anders. Was direkt angesprochen werden kann (z.B. CUL_HM) wird direkt auf der Hardware geändert, der Rest geht über WeekdayTimer...
Zitat von: Maui am 24 Oktober 2022, 19:39:55
Von der Physik her würde ich dir da sofort Recht geben, aaaber
-da kommen dann ja auch noch Störgrössen hinzu wie geöffnete Fenster zum Lüften
-oder "dumme" Thermen welche aufgrund des geringen Energiebedarfs anfangen zu takten und somit (zumindest wohl bei mir) dadurch eher mehr Gas verbraten durch häufiges Anspringen.
Ich versuche daher eher wie beim Auto zu "segeln" also bei geringem Wärmebedarf die Therme zum Abstellen zu zwingen.
Auch das sind m.E. "typische Fallgestaltungen", einschließlich der Frage des "Abwürgens" der Heizung, wenn "eigentlich" kein Bedarf besteht (Modul: HCS?)
An der Stelle hat sich übrigens gefühlt meine CAN-Aktion schon gelohnt. Die Therme hängt zwar bis jetzt nur an einem Raumthermostat, aber schon alleine das bewirkt, dass das Ding nicht mehr so häufig anspringt!
Werde jedenfalls bei Gelegenheit mal überlegen, ob ich das VALVES-Modul in contrib einchecke und dann dazu auch einen neuen Thread aufmache.
Benutze valves schon seit längerer Zeit.
Hatte mir ein DOIF gebastelt, das den Vorlauf bei einem bestimmten Heizbedarf (HM-CC-RT-DN Ventilöffnungen ausgewertet) auf- bzw. absenkt. Da ich mit Ausschlägen (Fenster auf/zu) via avg gekämpft habe, ist dieses momentan disabled. Ausserdem sollte nicht zu oft geschaltet werden und die Nachtabsenkung eingehalten werden.
Die Heizkurve ändere ich auf Grund von Erfahrungswerten zur Aussentemperatur.
Werde mich jetzt mal wieder damit beschäftigen. Ist der Heizbedarf hoch, wird WAF problematisch.
Meine Erkenntnisse bisher aus dieser Heizperiode:
- Wenn es wirklich kalt ist < -5 Grad, dann kann (bei meinem ungedämmten Haus) nicht wirklich optimiert werden
- Am meisten kann man rausholen, wenn es relativ warm ist, so ab 5-10 Grad +
- Da macht es dann gefühlt auch einen Unterschied an der Heizkurve zu drehen
- Gleichzeitig lasse ich die Heizung "Segeln", also wenn der virtuelle Leitraum passt, stelle ich die Heizung ab und zwinge sie auch erst einmal 30-60 Min aus zu bleiben.
Ich habe im letzen Jahr auch viel noch versucht an der WW-Bereitung zu optimieren.
Ich weiß Zahlen sind nicht wirklich repräsentativ, weil kein Winter wie der vorige ist, aber ich bin trotzdem bisher zufrieden.
04.21-11.21 : 590m3 Gas
04.22-11.22 : 380m3 Gas
Ich muss natürlich auch zugeben dass ich insgesamt die Temperatur in den Räumen ein wenig runter gedreht habe aber trotzdem motiviert mich die 30% Ersparnis das weiter zu treiben.
Hallo Leute,
da ich demnächst an meine Heizung ran will, lese ich mich gerade in VALVES ein. Dabei habe ich zwei Wiki-Artikel gefunden (Raumbedarfsabhängige Heizungssteuerung und VALVES). Sehen für mich ziemlich gleich aus. Eigentlich scheint mir alles logisch. Wie man anhand des ermittelten Prozentwertes die Heizung ansteuert ist doch ziemlich individuell. Vielleicht sollen in dem ersten Artikel ein paar Beispiele noch ergänzt werden. Dann macht es Sinn. Meine Heizung ist schon etwas älter und wird irgendwann einer Wärmepumpe weichen müssen. Bis dahin brauche ich Input, um meinem Heizungsbauer die richtigen Fragen stellen zu können.
Bei den Readings
valve_max -> Größte aktuelle Ventilöffnung seit letztem Reset
valve_min -> Kleinste aktuelle Ventilöffnung seit letztem Reset
bin ich unsicher. Sind es die aktuell größte und kleinste Ventilöffnung oder die größte und kleinste Ventilöffnung seit dem letzten Reset?
Ist sicher nicht so wichtig. Entscheidend für die Heizungssteuerung ist sicher state.
Momentan muss ich meine Heizkörper erst mal mit Thermostaten ausrüsten. Aber das Ziel steht.
Gruß
Frank
Zitat von: Beta-User am 25 Oktober 2022, 11:07:36
Werde jedenfalls bei Gelegenheit mal überlegen, ob ich das VALVES-Modul in contrib einchecke und dann dazu auch einen neuen Thread aufmache.
Here you are: https://forum.fhem.de/index.php/topic,131849.0.html