Support Thread für VALVES

[TubeHead]

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

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

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

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

[jkriegl]

Frage: valvesPollInterval sind Minuten?

[TubeHead]

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

Frage: 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...

[Beta-User]

commandref (sollte doch sogar beim Attribut direkt angeezeigt werden?):

<li><b>valvesPollInterval &lt;interval&gt;</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.

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

[jkriegl]

Kann bei valvesPollInterv nur auswählen 1 2 3 .. 15 20 25 .. 60 90 120 .. 900

[Beta-User]

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

[F_Klee]

Was sagt bei dir "version VALVES"?

Code Auswählen Erweitern

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


[Beta-User]

39_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.

einfach 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".

[Beta-User]

39_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!

[F_Klee]

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.

[Beta-User]

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.

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:

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

[F_Klee]

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.

[Beta-User]

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

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*   

[jkriegl]

Wenn ich mich richtig erinnere, muss die Summe der Gewichte gleich der Anzahl der Geräte sein. Kann momentan leider nicht nachschauen.