ZWave class Meter; ich brauche das Reading power ohne die Einheit ( W -> Watt )

[jsberg]

Hallo,

ich habe schone eine Menge Sensoren in meiner FHEM Installation.
Der neueste ist ein AEOTEC Home Energy Meter ( ZW095 ).
Funktioniert soweit gut, hier haben Andere scheinbar schon viel Vorarbeit geleistet. Danke dafür! 

Da ich die Werte ( Leistung und Energie ) über MQTT und Telegraf auf einen Influxdb Server schieben möchte bräuchte ich das Reading "power" und "energy" ohne den String "W" bzw "kWh".
Ich möchte einfach mit

Code Auswählen Erweitern

attr HW_Meter mqttPublish power:topic={"$base/HWmeter"} power:qos=2 power:retain=0
die Werte zum mqtt server schicken.
Das funktionert wunderbar mit meinen DS18B20 Sensoren und auch mit dem SMAInverter Modul mit meinem SB3000.
Bei beiden gibt es readings ohne einen String für die Einheit.
Ich würde gerne eine entsprechende Anpassung in meinem FHEM vornehmen.

Mir ist klar das man es vermutlich auch mit Perl Code hinbekommt ( chop() oder split()  ? ) aber ich finde es irgendwie sinnvoller als reading einfach einen Wert ( float oder integer ) zu haben den man dann problemlos weiterverarbeiten kann.
Einen String für die Einheit kann man dann ja bei schicken Visualisierungen immer noch hinzufügen.

Mein PERL level reicht zur Zeit noch nicht um das alleine hinzubekommen.

Danke schon mal für alle Hinweise.

Gruss

Jörg

[MadMax-FHEM]

ReadingsNum liefert nur den "Zahlenanteil" eines Readings...

Entweder das einbauen (statt split/chomp etc.) oder ein userReadings, dort dann per ReadingsNum nur den Zahlenwert auslesen und dann das "neue" Reading übertragen...

Gruß, Joachim

[rudolfkoenig]

Um das Problem zu loesen gibt es mehrere Wege:
- Readingswerte kann man mit dem readingsChange Modul anpassen.
- mit userReadings kann man eigene Readings basteln, z.bsp. indem man mit der ReadingsNum Perl Funktion aus einem "gemischten" Text die Zahlenwerte rauszuholt

Dieser Beitrag waere im MQTT Bereich  vmtl. besser aufgehoben, da MQTT_GENERIC_BRIDGE womoeglich auch was an den Daten aendern kann.

[jsberg]

Vielen Dank für die ganzen Vorschläge!

Werde ich mir alle angucken, und vermutlich auch irgendetwas in die Richtung temporär verwenden.
Ich sagte ja schon das es vermutlich zig Möglichkeiten gibt das nachträglich wieder zu entfernen.
Nicht nur in mqtt. Auch weiter hinten in der Kette ( Telegraf input und output plugin ) kann man sicher nochmal manipulieren.

Auf Dauer schwebt mir aber eher eine Lösung vor wo ich nicht bei jedem Sensor den ich integriere wieder alles entfernen muss.
Sehe ich das richtig das die Sensoren nur die Zahlen liefern und der Rest im ZWave Modul zugefügt wird?
Dann müßte ich dort ansetzen?
Vielleicht ein "privates" Modul was die Meter Class entsprechend anpasst?
Ich muss mich erstmal weiter in die "Logik" von Fhem einarbeiten.

Grundsätzlich fände ich es eleganter wenn ich die "redundanten" Strings dort unterbinde wo sie entstehen.
Bei den DS18B20 und beim SMA Modul wird ja auch kein "W", "kWh", "s", "C" hinzugefügt.
Kann ich ja immer noch machen "wenn" ich es irgendwo anzeigen will.

Gruss

Jörg

[rudolfkoenig]

Sehe ich das richtig das die Sensoren nur die Zahlen liefern und der Rest im ZWave Modul zugefügt wird?

Nein, die Sensoren liefern Zahlen, Genauigkeit und Einheit.
Diese Daten werden in der Funktion ZWave_meterParse() zum Readingswert gewandelt.

Vielleicht ein "privates" Modul was die Meter Class entsprechend anpasst?

Das kann man machen, man sollte aber danach auf FHEM-Updates verzichten, und in ein paar Jahren nicht auf die Idee kommen, weitere/neue Geraete einzubinden.

[Beta-User]

MQTT_GENERIC_BRIDGE womoeglich auch was an den Daten aendern kann.

Konkreter Vorschlag:

Code Auswählen Erweitern

attr HW_Meter mqttPublish power:topic={"$base/HWmeter"} power:qos=2 power:retain=0 power:expression={$value=~m,(-?\d+(\.\d+)?),?$1:undef}

[jsberg]

Danke füe alle Vorschläge.

ReadingsNum lässt sich nicht direkt für mqttPublish verwenden.
Aber mit dem kleinen Umweg über ein userReadings Attribut geht es natürlich.

Code Auswählen Erweitern

attr HWmeter userReadings rawpower { ReadingsNum("HWmeter","power",0) }
attr HWmeter mqttPublish rawpower:topic={"$base/rw/ueberlauf/power"} rawpower:qos=2 rawpower:retain=0

Und auch der Vorschlag von Beta-User geht natürlich ( und zwingt automatisch zum Studium eines regexp
tutorials  )

Iregnwie juckt es mich trotzdem einen Weg zu finden um standardmässig alle Werte eines  device mit "Meter" Fähigkeiten ohne Einheiten anzuzeigen. Die Idee eines "privaten Moduls" war natürlich nur naives Gerede ohne die genaue Funktion des Gesamtsystems wirklich erfasst zu haben.

Ich könnte mir aber vorstellen das man es mit einem Attribut lösen könnte. Wenn dieses gesetzt wäre könnte man in ZWave_meterParse() dann das reading ohne Einheit und sonstige Informationen erzeugen.

Sobald ich auf der steilen Perl/FHEM Lernkurve entsprechend vorangekommen bin werde ich das weiter verfolgen.

Beste Grüsse

Jörg

[MadMax-FHEM]

Warum setzt du nicht bei ALLEN Meter-Devices ein passendes userReadings und nutzt dann nur noch die (immer gleichen) "selbst erzeugten" Readings.

Da ist nicht viel "Lernkurve", funktioniert auch für (zukünftige) andere Devices/Module etc.

Und du musst kein Modul "privatisieren"...

Gruß, Joachim

[Beta-User]

Um das Problem zu loesen gibt es mehrere Wege:
- Readingswerte kann man mit dem readingsChange Modul anpassen.

Das habt ihr (=MadMax-FHEM und jsberg) euch angeschaut?

userReadings ohne trigger sind gruselig!

[MadMax-FHEM]

Das habt ihr (=MadMax-FHEM und jsberg) euch angeschaut?

Angeschaut wäre übertrieben bzw. nicht konkret zu diesem "Problem".

Aber ja, geht nat. auch...

EDIT: aber man muss halt (einiges) folgendes im Auge behalten

ReadingsChange ist abhängig von der Reihenfolge der Events und deren interner Verarbeitung. In dieser "Nahrungskette" steht es ziemlich weit hinten, mit dem Ergebnis, dass zum Beispiel Devices mit Attributen wie event-on-Change-reading fallweise nicht formatiert werden.

userReadings ohne trigger sind gruselig!

Richtig! Aber das lässt sich ja auch "richtig" machen

Gruß, Joachim

[Beta-User]

Na ja, "weit hinten" ist "etwas" untertrieben. Es ist de facto der erste Eventhandler, der "Wind von einer Änderung bekommt"... Ein Event ist aber nötig, klar. MQTT_GENERIC_BRIDGE ist dagegen GAAAANZ weit hinten, und braucht auch ein Event . Wie FileLog etc...

[jsberg]

Werde ich mir anschauen, Danke.
Bisher läuft es aber scheinbar problemlos.
MIt welchen Problemen sollte ich rechnen?

Gruss

Jörg

[Beta-User]

Mein Hinweis bezog sich darauf, dass du anscheinend mit dem "simplen bereinigten publishen" nicht zufrieden warst:

Iregnwie juckt es mich trotzdem einen Weg zu finden um standardmässig alle Werte eines  device mit "Meter" Fähigkeiten ohne Einheiten anzuzeigen. Die Idee eines "privaten Moduls" war natürlich nur naives Gerede ohne die genaue Funktion des Gesamtsystems wirklich erfasst zu haben.

Ich könnte mir aber vorstellen das man es mit einem Attribut lösen könnte. Wenn dieses gesetzt wäre könnte man in ZWave_meterParse() dann das reading ohne Einheit und sonstige Informationen erzeugen.

Sobald ich auf der steilen Perl/FHEM Lernkurve entsprechend vorangekommen bin werde ich das weiter verfolgen.

Aber anscheinend hat sich das erledigt, wenn ich deine jetzige Äußerung richtig deute...

Der (vermutlich gerade aktive) userReadings-Weg ist übrigens die m.E. am wenigsten zu propagierende Variante, Doppelungen von Infos sind meine Sache nicht...

[jsberg]

Nein, falsch gedeutet.
Ich würde das in Zukunft gerne nochmal angehen.

Wäre meiner Meinung nach doch eine saubere Lösung wenn in der Funktion wo das reading entsteht ( ZWave_meterParse() ) je nach Wunsch die Einheit ( und Zusatzinfos ) drangeklebt werden oder eben nicht.
Aber vielleicht ist das auch philosophisch... 

Ich dachte eher das die Verwendung von userReading in Verbindung mit mqttPublish Probleme macht.

Gruss

Jörg