Autor Thema: ZWave class Meter; ich brauche das Reading power ohne die Einheit ( W -> Watt )  (Gelesen 1587 mal)

Offline jsberg

  • New Member
  • *
  • Beiträge: 5
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=0die 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


Offline MadMax-FHEM

  • Hero Member
  • *****
  • Beiträge: 12133
  • NIVEAu ist keine Creme...
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)

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 25396
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.

Offline jsberg

  • New Member
  • *
  • Beiträge: 5
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

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 25396
Zitat
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.

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

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 18346
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-T620@Debian 11, 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

Offline jsberg

  • New Member
  • *
  • Beiträge: 5
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

Offline MadMax-FHEM

  • Hero Member
  • *****
  • Beiträge: 12133
  • NIVEAu ist keine Creme...
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)

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 18346
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-T620@Debian 11, 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

Offline MadMax-FHEM

  • Hero Member
  • *****
  • Beiträge: 12133
  • NIVEAu ist keine Creme...
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.

userReadings ohne trigger sind gruselig!

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

Gruß, Joachim
« Letzte Änderung: 25 Februar 2022, 11:25:25 von MadMax-FHEM »
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)

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 18346
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-T620@Debian 11, 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

Offline jsberg

  • New Member
  • *
  • Beiträge: 5
Werde ich mir anschauen, Danke.
Bisher läuft es aber scheinbar problemlos.
MIt welchen Problemen sollte ich rechnen?

Gruss

Jörg

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 18346
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...
Server: HP-T620@Debian 11, 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

Offline jsberg

  • New Member
  • *
  • Beiträge: 5
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