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

Begonnen von jsberg, 22 Februar 2022, 19:49:18

Vorheriges Thema - Nächstes Thema

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
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
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

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

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

ZitatVielleicht 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

Zitat von: rudolfkoenig am 22 Februar 2022, 20:04:20
MQTT_GENERIC_BRIDGE womoeglich auch was an den Daten aendern kann.

Konkreter Vorschlag:
attr HW_Meter mqttPublish power:topic={"$base/HWmeter"} power:qos=2 power:retain=0 power:expression={$value=~m,(-?\d+(\.\d+)?),?$1:undef}
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

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.

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  ;D )

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
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

Beta-User

Zitat von: rudolfkoenig am 22 Februar 2022, 20:04:20
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!
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

MadMax-FHEM

Zitat von: Beta-User am 25 Februar 2022, 11:15:59
Das habt ihr (=MadMax-FHEM und jsberg) euch angeschaut?

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

Aber ja, geht nat. auch... 8)

EDIT: aber man muss halt (einiges) folgendes im Auge behalten
Zitat von: https://wiki.fhem.de/wiki/ReadingsChange
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.

Zitat von: Beta-User am 25 Februar 2022, 11:15:59
userReadings ohne trigger sind gruselig!

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

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

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

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:
Zitat von: jsberg am 25 Februar 2022, 11:01:00
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...
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

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

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

Gruss

Jörg

Flachzange

Ich wärme das hier mal auf. Meine EnOcean-Geräte wurden um einige Meter-Steckerdosen im ZWave-Umfeld bereichert. Da die Readings den Wert und die Einheit enthalten funktionierten die bekannten Berechnungen nicht mehr. Ich habe mich jetzt mit ReadingsChange beholfen, so wie von Beta-User empfohlen. Aber irgendwie wäre es doch schöner und sauberer, wenn Wert und Einheit getrennt wären. Bei EnOcean habe ich dafür zwei Readings, einen für den Wert und einen für die Einheit.