39_VALVES - kleines Helferlein um Positionen von Heizungsthermostate auszuwerten

Begonnen von epsrw1, 18 Juni 2014, 05:05:00

Vorheriges Thema - Nächstes Thema

Morgennebel

ls -lah /opt/fhem/FHEM

und Besitzer/Leserechte kontrollieren.

Ciao, -MN
Einziger Spender an FHEM e.V. mit Dauerauftrag seit >= 24 Monaten

FHEM: MacMini/ESXi, 2-3 FHEM Instanzen produktiv
In-Use: STELLMOTOR, VALVES, PWM-PWMR, Xiaomi, Allergy, Proplanta, UWZ, MQTT,  Homematic, Luftsensor.info, ESP8266, ESERA

theotherhalf

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?
FHEM Anfänger
HM CCU2 mit diversen Komponenten als Steuerung
FHEM mit Floorplan auf Raspi 3 (Raspbian Jessie)  zur Visualisierung (Heizung, Zustände, etc.) und angeschlossenen One-Wire Sensoren
Schnittstelle CCU2 - FHEM mit HMCCU
EBUSD Applikation auf Raspi 2 mit Anbindung an Vaillant Heizung

theotherhalf

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")"
FHEM Anfänger
HM CCU2 mit diversen Komponenten als Steuerung
FHEM mit Floorplan auf Raspi 3 (Raspbian Jessie)  zur Visualisierung (Heizung, Zustände, etc.) und angeschlossenen One-Wire Sensoren
Schnittstelle CCU2 - FHEM mit HMCCU
EBUSD Applikation auf Raspi 2 mit Anbindung an Vaillant Heizung

stromer-12

FHEM (SVN) auf RPi1B mit HMser | ESPLink
FHEM (SVN) virtuell mit HMLAN | HMUSB | CUL

epsrw1

Ich habe keine Ahnung, aber davon wenigstens ganz viel

farion

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
Fhem5.8@Raspi3|~70xHomematic|KM271|1Wire|DoorPi mit DoorPiBoard|GarageDoorSingleButton|Graphite

Reinhart

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
FHEM auf Raspy4 mit Bullseye + SSD, Homematic, ESP8266, ESP32, Sonoff, eBus, NanoCUL, MapleCUL, , MQTT2, Alexa

jkriegl

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.
Rpi 3, Fhem, Cul 868, HM-CC-RT-DN, HM-Sec-Sco, HM-ES-PMSw1-Pl, ebus (Vaillant), ECMD, Telegram, HTTPMOD, Xiaomi, Shelly

farion

@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
Fhem5.8@Raspi3|~70xHomematic|KM271|1Wire|DoorPi mit DoorPiBoard|GarageDoorSingleButton|Graphite

jkriegl

Rpi 3, Fhem, Cul 868, HM-CC-RT-DN, HM-Sec-Sco, HM-ES-PMSw1-Pl, ebus (Vaillant), ECMD, Telegram, HTTPMOD, Xiaomi, Shelly

farion

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.
Fhem5.8@Raspi3|~70xHomematic|KM271|1Wire|DoorPi mit DoorPiBoard|GarageDoorSingleButton|Graphite

jkriegl

Genau so ist es.
Das mit /7 ist natürlich falsch. Der berühmte Satz hilft weiter.
Rpi 3, Fhem, Cul 868, HM-CC-RT-DN, HM-Sec-Sco, HM-ES-PMSw1-Pl, ebus (Vaillant), ECMD, Telegram, HTTPMOD, Xiaomi, Shelly

M_I_B

... 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?

CoolTux

Module in contrib haben sich noch nie laden lassen. Moduldateien gehören immer nach FHEM/
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

M_I_B

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  ::)