39_VALVES - kleines Helferlein um Positionen von Heizungsthermostate auszuwerten

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

Vorheriges Thema - Nächstes Thema

Maui

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.

Morgennebel

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

Maui

Danke. Aber ich will ja die einzelnen Valve-Stellungen visualisieren und nicht den Schnitt.

Morgennebel

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


makruna


MAC66666

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?
FHEM @ Ubuntu 20.04 VM@ Windows 2019 Hyper-V @ NVMe
MAXCube als CUL_MAX (Thermostate)
MAXCube als SlowRF (FS20, wird durch ESPs ersetzt, teilweise geschehen)
Einige ESPs mit ESPEasy, zwei GHoma und ein Sonoff Tasmota

Wzut

Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

MAC66666

bin etwas eingerostet und war nie sooo tief in FHEM drin ;) Hilf mir auf die Sprünge ;)
FHEM @ Ubuntu 20.04 VM@ Windows 2019 Hyper-V @ NVMe
MAXCube als CUL_MAX (Thermostate)
MAXCube als SlowRF (FS20, wird durch ESPs ersetzt, teilweise geschehen)
Einige ESPs mit ESPEasy, zwei GHoma und ein Sonoff Tasmota

Wzut

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.
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

MAC66666

ah, ja logisch... Das passiert, wenn man nur einmal im Jahr am FHEM bastelt. Man muss sich immer wieder alles neu draufschaffen. Danke Dir!
FHEM @ Ubuntu 20.04 VM@ Windows 2019 Hyper-V @ NVMe
MAXCube als CUL_MAX (Thermostate)
MAXCube als SlowRF (FS20, wird durch ESPs ersetzt, teilweise geschehen)
Einige ESPs mit ESPEasy, zwei GHoma und ein Sonoff Tasmota

Beta-User

Hallo Florian,
hallo zusammen,

nachdem jüngst (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
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Beta-User

Hmm, es besteht demnach kein Interesse/Bedarf?

Oder ist es schlicht die falsche Jahreszeit...?
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Maista

@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

Maui

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