OWX - analoge Sensorwerte mit Formel umrechnen

[tomster]

Servus zusammen!

Ich habe einen Ultraschallsensor, den ich mittels DS2438 an FHEM angebunden habe. Die Grundfunktion ist dabei auch wunderbar gegeben (er misst). Nur bringt mir natürlich die bloße Ausgabe der Entfernungswerte von 1-5V nicht sonderlich viel. Deshalb wollte ich die Werte mittels einer Funktion in eine Volumenangabe für meinen Heizöltank umwandeln.
Wenn ich nun aber Folgendes in die fhem.cfg eintrage:

Code Auswählen Erweitern


define OWX_26 OWMULTI DS2438 1FDB6B012345 100
attr OWX_26_ room Keller
attr OWX_26_ VFunction ((V-1)+(V-1)*1.5)
attr OWX_26_ VName Heizoel|Volume
attr OWX_26_ VUnit Liter|lt

dann versagt der DS2438 seinen Dienst. Sprich, der ausgelesene Wert des Sensors wird nicht mehr aktualisiert.
Leider habe ich zu den "V"-Attributen nichts in der commandref gefunden. Daher meine Frage:
Was mache ich falsch?

[UweH]

Teste mal diese Funktionen in Verbindung mit Deinen Anforderungen. Ich hatte ein ähnliches Problem mit VFunction und habe dann diese Lösung gefunden:

Code Auswählen Erweitern

stateFormat: {sprintf("%.2f",ReadingsVal($name,"P",0))." W/m²"}

userReadings: P {(ReadingsVal($name,"voltage",0)*0.2145)}

Damit wird mit einem Lichtsensor die Sonneneinstrahlung gemessen. P ist die Leistung in W/m², "voltage" die Eingangsspannung am DS2438.

[Prof. Dr. Peter Henning]

Das ist erstaunlich.

Erstens funktioniert die Eingabe einer VFunction normalerweise problemlos - ich betreibe z.B. einen DS2438 mit den folgenden Attributen:

define A.OWM OWMULTI DS2438 4CAE54010000 300
attr A.OWM IODev OWX_UG
attr A.OWM VFunction (11.6552*V**4+7.10835*V**2-0.569557)/(V**2 + 1)
attr A.OWM VName rH(p)|humidity
attr A.OWM VUnit percent|%
attr A.OWM group climateSensor
attr A.OWM model DS2438
attr A.OWM room Aussenbereich

Zweitens stehen die (Kurz-)Anleitungen zu den V-Attributen sehr wohl in der commandref.

Damit ergeben sich verschiedene Fragen:
- Welche Modulversion wird hier verwendet ?
- Was bedeutet "wird nicht mehr aktualisiert" ? Was ist mit den Werten für Temperatur und VDD ?

LG

pah

[UweH]

Bei mir führt VFunction überhaupt keine Berechnungen aus, noch nicht mal VDD +1 oder ähnliches.

Versionsnummern:
00_OWX.pm 6392 2014-08-11
21_OWMULTI.pm 6379 2014-08-07

[tomster]

Sorry, Wiesn-bedingt gibt's erst jetzt eine Antwort.

Zweitens stehen die (Kurz-)Anleitungen zu den V-Attributen sehr wohl in der commandref.

Stimmt. Hab ich wohl übersehen, oder beim Suchen einen Schreibfehler gehabt. 1:0 für Dich

Damit ergeben sich verschiedene Fragen:
- Welche Modulversion wird hier verwendet ?
- Was bedeutet "wird nicht mehr aktualisiert" ? Was ist mit den Werten für Temperatur und VDD ?

00_OWX.pm 2737 2013-02-15 22:05:08Z ntruchsess
21_OWMULTI.pm 3044 2013-04-07 17:42:56Z pahenning

Wird OWX nicht über ein "normales" Update auf den neusten Stand gebracht, oder sind UweH's Versionen noch nicht freigegebene aus dem SVN?

--edit--
Upsala! Hatte wohl doch noch kein Update auf dieser FHEM-Instanz gemacht. Wohl der Fluch, wenn man mehrere FHEM-Maschinchen rumstehen hat...
Nun hab ich:
00_OWX.pm 6392 2014-08-11 15:25:00Z ntruchsess
21_OWMULTI.pm 6379 2014-08-07 22:31:34Z ntruchsess

Der Fehler mit der "falschen" Voltage-Anzeige bleibt aber...
--edit--

Auch wenn ich beim Schreiben des Postings wohl nicht genau genug/ ausreichend lange beobachtet habe, kann man meine Aussage mit "wird nicht mehr aktualisiert" so stehen lassen. Auf beigefügtem Bild sieht man, dass zwar der v-Meßwert laufend aktualisiert wird, die Voltage-Ausgabe (also der tatsächlich gemessene Sensorwert)(//) seit 02.10. unverändert geblieben ist. Temperatur und VDD werden aber aktualisiert. Sobald ich die v-Attribute lösche, wird aber auch wieder die (vermeintlich) korrekte Voltage-Ausgabe angezeigt/ aktualisiert.
Diese Beobachtung, in Verbindung mit der Tatsache, dass mein Testaufbau den Ultraschallsensor an die Decke strahlen lässt (und diese wohl nur geringfügig ihre Lage im Raum ändern wird) hat mich zur irrtümlichen Annahme geführt, dass gar nichts aktualisiert wird. Richtigerweise müsste eben nun heissen, dass die Volatgeangabe nicht geändert wird. Der Rest schon.

[Prof. Dr. Peter Henning]

Nun, ich denke nicht in Kategorien wie "x:0" - aber wer's mag... Denn jetzt steht es 2:0.

"voltage" wird als reading = Name des Kanals nur verwendet, wenn kein "VName" angegeben wurde. Und wenn ein "VName" angegeben wurde, steht eben noch das alte reading im hash. Kann man mit "deletereading <devicename> voltage" komplett loswerden.

Das macht auch Sinn, denn wenn man einen Kanalnamen vergeben hat, sollte nur dieser nach außen erscheinen.

Wer unbedingt den rohen Kanalwert = gemessene Spannung haben will, sollte dies mit "get <devicename> raw" abfragen.

LG

pah

[tomster]

Ich hab's auch ned so mit x:0, aber Du hattest schlichtweg Recht mit der commadref. Auch wenn die noch etwas schwachbrüstig vertreten ist.
Vielleicht lag's auch an meinem noch nicht upgedateten FHEM-Server. Is aber auch egal.

Danke für die Erklärung. Ich hatte nur das Problem, dass ich meinen Ultraschallsensor halbwegs "eichen"; sprich die VFunction auf Plausibilität/ Korrektheit abklären wollte.  Dabei ist es verständlicherweise von Vorteil, wenn man neben dem VFunctionwert auch den "RAW-Wert" der Voltage-Angabe ich Echtzeit hat. Durch die virtuelle V-Benennung bekommt der Kanal ohnehin den richtigen Namen, egal ob nun der Voltage-Wert im Hintergrund weiter ausgegeben wird oder nicht. Oder siehst Du das nicht so?

[Prof. Dr. Peter Henning]

Nein, sehe ich nicht so.

Wenn ich eine Funktion habe (eben die VFunction), kann ich mir eine Wertetabelle mit dem Taschenrechner sehr viel schneller erstellen, als mir FHEM dies in stundenlangen Messungen liefert.

Oder mit anderen Worten: Eine Funktion ist eine vollständige Theorie im Sinne Poppers, es birgt keinerlei Erkenntnisgewinn, diese noch auf endlich viele Einzelfälle anzuwenden.

LG

pah

[tomster]

Da kann ich dem Grunde nach nicht widersprechen. Wer die Funktion hat, kann sich den RAW-Wert schenken. Zumindest in der Theorie.

In meinem Fall kenne ich die Funktion noch nicht und muß sie mir "zu Fuß" erarbeiten. Und da zwickelt die Praxis der Theorie gelegentlich in's Spiel:
Wenn man mit einem Heizöltank zusammenarbeiten muss um Werte als Grundlage zur Berechnung einer Funktion zu erhalten, dann schränkt das die nachstellbaren "Laborbedingungen" doch etwas arg ein. Man ist auf den (hoffentlich) seltenen Zeitpunkt eines einzelnen Tankvorgangs angewiesen. Und hat dann auch nur das dadurch vorgegebene Zeitfenster zur Verfügung. 1 Mal im Jahr. 15 Minuten. Glaube mir, die RAW-Werte in Echtzeit UND die Werte der VFunction gleichzeitig angezeigt, hätten mir dabei wirklich geholfen...

"Die größte wissenschaftliche Tragödie: Wenn eine häßliche Tatsache eine schöne Theorie ermordet."
Thomas Huxley (den hätt ich jetzt fast unterschlagen. Nicht dass ich noch des Plagiarismus bezichtigt werde...)

[Prof. Dr. Peter Henning]

Ich kann das sehr gut nachvollziehen, wir haben gestern unsere Heizöltanks entsorgen lassen. Deren Form sorgte für eine extrem nichtlineare Abhängigkeit zwischen Füllmenge und Füllhöhe.

Allerdings würde ich hier anders vorgehen, denn wie gesagt: Die Information steckt nicht in Rohwert und Rechenergebnis. Sondern in (Rohwert ODER Funktionswert) UND Ölverbrauch. Also

1. Betriebsstundenzähler am Brenner anbringen. Ölverbrauch je Brennerzeiteinheit ist konstant.
2. Regelmäßig die Füllhöhe messen
3. Aus diesen Rohdaten dann einen Fit erstellen .

LG

pah