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
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
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.
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
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.
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}
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
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
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!
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
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...
Werde ich mir anschauen, Danke.
Bisher läuft es aber scheinbar problemlos.
MIt welchen Problemen sollte ich rechnen?
Gruss
Jörg
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...
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
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.
ZitatDa die Readings den Wert und die Einheit enthalten funktionierten die bekannten Berechnungen nicht mehr.
Welche denn?
Gibt es noch von weiteren Benutzern Interesse an einem Attribut, damit die Einheiten nicht ausgegeben werden?
Ohne Einheit finde ich besser.
Ich habe ein noUnits Attribut fuer die ZWave Instanzen eingebaut.
Klappt aber bei mir noch nicht.
Zitatluminance 2000 Lux 2024-10-27 12:05:14
Zitat0_ZWave.pm 29298 2024-10-26 11:27:37Z rudolfkoenig
00_ZWDongle.pm 28748 2024-04-04 21:47:39Z rudolfkoenig
Ich habe nur die METER Klasse geaendert, dein Beispiel ist SENSOR_MULTILEVEL.
Das habe ich jetzt nachgeholt, da ich aber kein passendes Geraet habe, konnte ich es nicht testen.
Wenn es nicht funktioniert, dann bitte ein "attr ZWDongle verbose 4" Mitschitt eines Nachrichts hier anhaengen.
Eigentlich haette ich so eine Nachricht gerne in jedem Fall :)
Klappt Danke
steinel/xled-home-2.xml
Zitat2024.10.27 16:13:58 4: ZWDongle_Read POE_ZW_Prim_OG: rcvd 011301 (answer ZW_SEND_DATA), sending ACK
2024.10.27 16:13:58 4: ZWDongle_Read POE_ZW_Prim_OG: rcvd 00133100000d01a97f7f7f7f02010320000000010100007f7f7f7f7f (request ZW_SEND_DATA), sending ACK
2024.10.27 16:13:58 4: CMD:ZW_SEND_DATA ID:00 ARG:000d01a97f7f7f7f02010320000000010100007f7f7f7f7f CB:31
2024.10.27 16:13:58 4: POE_ZW_Prim_OG transmit OK for CB 31, target BM_L1
2024.10.27 16:13:58 4: ZWDongle_Read POE_ZW_Prim_OG: rcvd 000400a30a600d03003105030a07d0a9000120 (request APPLICATION_COMMAND_HANDLER), sending ACK
2024.10.27 16:13:58 4: CMD:APPLICATION_COMMAND_HANDLER ID:a3 ARG:0a600d03003105030a07d0a9000120 CB:00
steinel/rs-led-d2.xml
Zitat2024.10.27 16:20:15 4: ZWDongle_Read POE_ZW_Prim_OG: rcvd 011301 (answer ZW_SEND_DATA), sending ACK
2024.10.27 16:20:15 4: ZWDongle_Read POE_ZW_Prim_OG: rcvd 00133300000100b57f7f7f7f00000300000000030100007f7f7f7f7f (request ZW_SEND_DATA), sending ACK
2024.10.27 16:20:15 4: CMD:ZW_SEND_DATA ID:00 ARG:000100b57f7f7f7f00000300000000030100007f7f7f7f7f CB:33
2024.10.27 16:20:15 4: POE_ZW_Prim_OG transmit OK for CB 33, target BM_L2
2024.10.27 16:20:15 4: ZWDongle_Read POE_ZW_Prim_OG: rcvd 000400440a600d03003105030a07d0ad0000 (request APPLICATION_COMMAND_HANDLER), sending ACK
2024.10.27 16:20:15 4: CMD:APPLICATION_COMMAND_HANDLER ID:44 ARG:0a600d03003105030a07d0ad0000 CB:00
2024.10.27 16:20:15 4: ZWDongle_Read POE_ZW_Prim_OG: rcvd 000400440a600d03003105030a07d0b20000 (request APPLICATION_COMMAND_HANDLER), sending ACK
2024.10.27 16:20:15 4: CMD:APPLICATION_COMMAND_HANDLER ID:44 ARG:0a600d03003105030a07d0b20000 CB:00
2024.10.27 16:20:26 4: ZWDongle_Read POE_ZW_Prim_OG: rcvd 000400aa0a600d02003105030a000ba80000 (request APPLICATION_COMMAND_HANDLER), sending ACK
2024.10.27 16:20:26 4: CMD:APPLICATION_COMMAND_HANDLER ID:aa ARG:0a600d02003105030a000ba80000 CB:00
qubino/ZMNHADx.xml
Zitat2024.11.01 21:59:51 3: ZWave get Sw_01.02 smStatus
2024.11.01 21:59:51 4: ZWDongle_Read POE_ZW_Prim_OG: rcvd 011301 (answer ZW_SEND_DATA), sending ACK
2024.11.01 21:59:51 4: ZWDongle_Read POE_ZW_Prim_OG: rcvd 00130e00000900a47f7f7f7f01010300000000020300007f7f7f7f7f (request ZW_SEND_DATA), sending ACK
2024.11.01 21:59:51 4: CMD:ZW_SEND_DATA ID:00 ARG:000900a47f7f7f7f01010300000000020300007f7f7f7f7f CB:0e
2024.11.01 21:59:51 4: POE_ZW_Prim_OG transmit OK for CB 0e, target Sw_01
2024.11.01 21:59:51 4: ZWDongle_Read POE_ZW_Prim_OG: rcvd 000400370a600d02003105012200aba40000 (request APPLICATION_COMMAND_HANDLER), sending ACK
2024.11.01 21:59:51 4: CMD:APPLICATION_COMMAND_HANDLER ID:37 ARG:0a600d02003105012200aba40000 CB:00
Zitat von: rudolfkoenig am 26 Oktober 2024, 13:29:16Ich habe ein noUnits Attribut fuer die ZWave Instanzen eingebaut.
Vielen Dank, funktioniert auch hier!