Schaltbare Steckdosen spielen in FHEM eine große Rolle. Einige von ihnen sind jedoch nicht nur zum einfachen Schalten da, sondern messen zusätzlich auch die aktuelle Leistung und den Stromverbrauch des angeschlossenen Gerätes. Ein Beispiel ist da die PCA301-Steckdose von ELV oder der Zwischenstecker von HomeMatic.
Da liegt es doch Nahe, aus den gemessenen Werte sich den Stromverbrauch des angeschlossenen Gerätes zu errechnen und in einem Balkendiagram darzustellen. Genau darum wird es in diesem Blogbeitrag gehen. Ich werde euch zeigen, wir ihr die Readings einer PCA301-Steckdose auswertet und euch daraus ein Dummy mit den Tages-, Monats, Jahres- und Gesamtverbrauch und den jeweiligen Stromkosten erstellt.
Vorbereitung
Bevor man mit dem Auswerten der Readings beginnen kann, muss natürlich die Steckdose selbst eingebunden werden. Mehr Infos dazu auf meinem Blogbeitrag. Folgende Anweisungen beziehen sich auf die Readings der PCA301-Steckdosen. Solltet ihr andere Leistungsmessgeräte verwenden, müsst ihr die Readings entsprechend anpassen.
Einrichtung in FHEM
Der komplette Aufbau besteht aus je einem Dummy für die Gesamt-, Jahres-, Monats, und Tageswerte. Die Dummys besitzen dann je ein Reading für den Verbrauch und für die Stromkosten. Die Dummys für die Gesamt-, Jahren- und Monatswerte besitzen zudem ein Reading für den Tagesverbrauch. Aus diesem Reading wird dann entsprechend der Gesamt-, Jahres- bzw. Monatswert errechnet.
Das Reading Tagesverbrauch wird dann über ein at-Device mit dem gemessen Wert der Steckdose beschrieben. Die anderen Readings werden jeweils im Dummy über das userReadings-Attribut selbst erzeugt.
Zusätzlich wird im at-Device das aktuelle Datum abgefragt, um zu überprüfen, ob eines der Readings zurückgesetzt werden muss. Am ersten Tag eines Monats wird zum Beispiel das Reading Verbrauch des Monats-Dummys auf Null gesetzt.
Zum Schluss wird noch eine readingsGroup erstellt, um die Werte in einem Device zusammen zu haben.
Dummys
Wie oben bereits erwähnt, wird je ein Dummy für die Gesamt-, Jahres-, Monats- und Tageswerte erstellt.
define WZStromkostenGesamt dummy; define WZStromkostenJahr dummy; define WZStromkostenMonat dummy; define WZStromkostenTag dummy
Damit die später eingerichteten Readings ordnungsgemäß verarbeitet und angezeigt werden, werden den Dummys ein paar Attribute mitgegeben. Angefangen mit dem Gesamt-Dummy.
Attribut „alias“, damit der unschöne Name überschrieben wird:
attr WZStromkostenGesamt alias Gesamt
Attribut „room“ für die Raumzuordnung:
attr WZStromkostenGesamt room Stromkosten
Mit dem Attribut „group“ werden die Dummys zusammengefasst:
attr WZStromkostenGesamt group WZ-Stromkosten
Die Attribute „alias“, „room“ und „group“ können natürlich je nach Wunsch angepasst werden.
Attribut "stateFormat" fügt die Readings in die Device-Übersicht:
attr WZStromkostenGesamt stateFormat {sprintf("%.2f kWh - %.2f €",ReadingsVal("WZStromkostenGesamt", "Verbrauch",0), ReadingsVal("WZStromkostenGesamt","Kosten",0))}
Attribut „userReadings“ fügt das Reading „Verbrauch“ hinzu, welches den Tageswert stetig aufaddiert und das Reading „Kosten“, welches den Verbrauchswert mit dem aktuellen Strompreis multipliziert.
attr WZStromkostenGesamt userReadings Verbrauch monotonic {ReadingsVal("WZStromkostenGesamt","Tagesverbrauch",0)},Kosten {ReadingsVal("WZStromkostenGesamt","Verbrauch",0)*0.2507}
Diese Attribute anschließend auch für die beiden Dummys „WZStromkostenJahr“ und „WZStromkostenMonat“ einrichten. Bei den Attributen „stateFormat“ und „userReadings“ entsprechend die Devices im ReadingsVal anpassen.
Für das Dummy „WZStromkostenTag“ können die Attribute „alias“, „room“ und „stateFormat“ ebenfalls übernommen werden. Das Attribut „userReadings“ wird jedoch etwas abgewandelt:
attr WZStromkostenTag userReadings Kosten {ReadingsVal("WZStromkostenTag","Verbrauch",0)*0.2507}
Hier wird nur noch das Reading „Kosten“ erstellt. Das Verbrauchs-Reading wird später über das at-Device erzeugt.
at-Device
Nachdem die Dummys erstellt wurden, kann man damit beginnen, diese mit Leben zu füllen. Verwendet wird dafür ein at-Device, welches zunächst wie folgt definiert wird:
define atWZStromkosten at +*00:01:00 a
Über den DEF-Editor passen wir das at-Device nun an:
+*00:01:00 {my $a = (ReadingsVal("WZ_Entertainment","consumption",0));fhem("setreading WZStromkostenTag Verbrauch $a");fhem("setreading WZStromkostenMonat Tagesverbrauch $a");fhem("setreading WZStromkostenJahr Tagesverbrauch $a");fhem("setreading WZStromkostenGesamt Tagesverbrauch $a");if(($hour==0) && ($min==0)){fhem("set WZ_Entertainment reset")} if(($hour==0) && ($min==0) && ($mday==1)){fhem("setreading WZStromkostenMonat Verbrauch 0")}if(($hour==0) && ($min==0) && ($yday==1)){fhem("setreading WZStromkostenJahr Verbrauch 0")}}
Nachtrag 01.03.2017: Heute zum 1. des Monats, habe ich festgestellt, dass das Zurücksetzen am Anfang des Monats nicht geklappt hat. Grund war der Einsatz von „elsif“. Es wird dann nämlich nur die erste Bedienung ausgeführt (die Tageszurücksetzung). Die anderen Abfragen werden dann gar nicht mehr überprüft. Durch den Einsatz von drei getrennten if-Abfragen sollte es nun aber klappen. Der Code oben wurde bereits angepasst.
Zuerst wird die Variable „a“ erzeugt, diese beinhaltet den gemessenen Stromverbrauch der PCA301-Steckdose. Solltet ihr hier andere Devices für die Messung verwenden, mit eventuell anderen Readings, müsst ihr diesen Eintrag entsprechend anpassen.
Anschließend wird das Reading „Verbrauch“ vom Tages-Dummy mit diesem Wert gesetzt. Die anderen Dummys bekommen diesen Wert als Reading „Tagesverbrauch“. Aus diesem Reading wird innerhalb der Dummys zum Beispiel der Jahresverbrauch erstellt, siehe Attribut „userReadings“ der Dummys.
Nachdem die Readings gefüttert wurden, beginnt die Zeitabfrage. Zuerst wird nach der Uhrzeit „00:00“ gefragt. Ist dies der Fall, wird die Verbrauchsmessung der PCA301-Steckdose („WZ_Entertainment“) auf Null gesetzt. Die zweite Abfrage überprüft, ob ein neuer Monat begonnen hat. In diesem Fall, wird der Monatsverbrauch auf Null gesetzt. Die letzte Abfrage ist für den Jahreswechsel zuständig. Bei einem Jahreswechsel wird das Jahresverbrauch entsprechend auf Null gesetzt.
Wurde das ordnungsgemäß at-Device eingerichtet, werden die Dummys nun mit den entsprechenden Werten gespeißt und die Berechnung des Monats-, Jahres- und Gesamtverbrauch beginnt.
Zu Beginn sieht es noch etwas unspektakulär aus, da es zwischen den Zeiträumen keinen Unterschied gibt. Aber das wird sich ja mit der Zeit ändern.
readingsGroup
Wer möchte, kann die Readings noch in einer „readingsGroup“ zusammen fassen. Dies erleichtert zum Beispiel ein späteres Verschieben in einen anderen Raum, da nur noch für die „readingsGroup“ das room-Attribut angepasst werden muss. Des Weiteren lässt sich diese Gruppe visuell besser anpassen als eine Gruppierung über das group-Attribut.
define GroupWZStromkosten readingsGroup < >,<Verbrauch>,<Kosten> WZStromkostenGesamt:Verbrauch,Kosten WZStromkostenJahr:Verbrauch,Kosten WZStromkostenMonat:Verbrauch,Kosten WZStromkostenTag:Verbrauch,Kosten
Anstatt nun die ganzen Dummys in den Raum „Wohnzimmer“ zu verschieben, muss ich nun nur diese Gruppe in den gewünschten Raum verschieben.
attr GroupWZStromkosten room Wohnzimmer
Auch hier setze ich wieder das alias-Attribut:
attr GroupWZStromkosten alias Stromkosten
Wer möchte kann gerne noch das Aussehen der Gruppe anpassen. Ich zum Beispiel habe die Schriftgröße auf 18px erhöht und Wertebereiche den Farben grün, orange und rot zugeordnet.
attr GroupWZStromkosten valueStyle {if($DEVICE eq "WZStromkostenJahr" && $READING eq "Verbrauch" && $VALUE > 1800){'style="color:red"'}elsif($DEVICE eq "WZStromkostenJahr" && $READING eq "Verbrauch" && $VALUE > 1080){'style="color:orange"'}elsif($DEVICE eq "WZStromkostenJahr" && $READING eq "Verbrauch" && $VALUE > 0) {'style="color:green"'}elsif($DEVICE eq "WZStromkostenJahr" && $READING eq "Kosten" && $VALUE > 460){'style="color:red"'}elsif($DEVICE eq "WZStromkostenJahr" && $READING eq "Kosten" && $VALUE > 275){'style="color:orange"'}elsif($DEVICE eq "WZStromkostenJahr" && $READING eq "Kosten" && $VALUE > 0){'style="color:green"'}elsif($DEVICE eq "WZStromkostenMonat" && $READING eq "Verbrauch" && $VALUE > 150){'style="color:red"'}elsif($DEVICE eq "WZStromkostenMonat" && $READING eq "Verbrauch" && $VALUE > 90){'style="color:orange"'}elsif($DEVICE eq "WZStromkostenMonat" && $READING eq "Verbrauch" && $VALUE > 0){'style="color:green"'}elsif($DEVICE eq "WZStromkostenMonat" && $READING eq "Kosten" && $VALUE > 38){'style="color:red"'}elsif($DEVICE eq "WZStromkostenMonat" && $READING eq "Kosten" && $VALUE > 23){'style="color:orange"'}elsif($DEVICE eq "WZStromkostenMonat" && $READING eq "Kosten" && $VALUE > 0){'style="color:green"'}elsif($DEVICE eq "WZStromkostenTag" && $READING eq "Verbrauch" && $VALUE > 5){'style="color:red"'}elsif($DEVICE eq "WZStromkostenTag" && $READING eq "Verbrauch" && $VALUE > 3){'style="color:orange"'}elsif($DEVICE eq "WZStromkostenTag" && $READING eq "Verbrauch" && $VALUE > 0){'style="color:green"'}elsif($DEVICE eq "WZStromkostenTag" && $READING eq "Kosten" && $VALUE > 1.25){'style="color:red"'}elsif($DEVICE eq "WZStromkostenTag" && $READING eq "Kosten" && $VALUE > 0.75){'style="color:orange"'}elsif($DEVICE eq "WZStromkostenTag" && $READING eq "Kosten" && $VALUE > 0){'style="color:green"'} }
Die Wertebereiche könnt ihr natürlich entsprechend anpassen.
attr GroupWZStromkosten style style="font-size:18px"
Zum Schluss wird noch das Format der Werte angepasst und die Einheit hinzugefügt.
attr GroupWZStromkosten valueFormat {Kosten => "%.2f €", Verbrauch => "%.2f kWh"}
FileLog
Damit später auch ein Diagramm erstellt werden kann, müssen die Werte in ein FileLog gespeichert werden. Ich habe mich für ein extra FileLog für die Stromkosten entschieden.
define StromkostenLOG FileLog ./log/StromkostenLOG-%Y-%m.log WZStromkostenGesamt:.*|WZStromkostenJahr:.*|WZStromkostenMonat:.*|WZStromkostenTag:.*
Wer möchte, kann natürlich die Werte auch in ein vorhandenes FileLog schreiben.
Für das Diagramm wird später der Kosten-Wert vom Dummy „WZStromkostenGesamt“ verwendet. Dennoch schreibe ich auch die Tages-, Monats- und Jahreswerte in das LogFile. Dies erleichtert zum Beispiel, dass spätere Erstellen von einem Monatsdiagramm. Am Anfang ist dies jedoch aufgrund der geringen Anzahl an Werten nicht zu empfehlen.
Balkendiagramm
Nachdem das FileLog erstellt wurde, kann mit dem Definieren des Diagramms begonnen werden. Wie oben schon erwähnt, habe ich mir zuerst nur ein Diagramm aus den Tageswerten erstellt.
define SVGStromkosten SVG StromkostenLOG:SVG_StromkostenLOG:CURRENT
Das Erstellen des SVG-Plots geht natürlich auch über das LogFile und dann über „Create SVG Plot“.
Bevor man nun das Diagramm weiter definiert, ist für eine korrekte Anzeige notwendig den Zeitraum auf einen Monat festzulegen.
attr SVGStromkosten fixedrange month
Optional kann noch die Größe des Diagramms, der Raum und ein Alias festgelegt werden. Ich verwende eine einheitliche Größe von 800×200 Pixel.
attr SVGStromkosten plotsize 800,200attr SVGStromkosten room Wohnzimmerattr SVGStromkosten alias Stromkosten
Um nun das gewünschte Balkendiagramm angezeigt zu bekommen, habe ich folgende Einstellungen vorgenommen. Wie oben schon erwähnt, verwende ich den Kosten-Werte vom Dummy „WZStromkostenGesamt“.
Wichtig ist hier der Eintrag im Feld „functions“. „delta-d“ sorgt dafür, dass aus dem Gesamt-Kostenwert immer nur die Kosten des Tages angezeigt werden, bzw. die Differenz von den Gesamtkosten gegenüber des Wertes vom letzten Tag. Kurz gesagt, die anfallenden Kosten eines Tages.
Wer möchte, kann nun natürlich auch ein Diagramm für den täglichen Verbrauch in kWh erstellen. Oder anstelle von Tagesdiagrammen ein Stundendiagramm erstellen. Dazu einfach die Function „delta-d“ zu „delta-h“ ändern. Achtet jedoch darauf, dass für jedes Diagramm ein seperates FileLog benötigt wird.
Absofort wird von jedem Tag ein Balken mit den angefallenen täglichen Stromkosten des gemessenen Gerätes erstellt. Zusammen mit der readingsGroup hat man nun eine sehr gute Übersicht über die angefallenden Stromkosten.
Messdaten mehrerer Steckdosen zusammenfügen
Die oben beschriebene Anleitung beschreibt das Visualisieren von Messdaten eines Messgerätes. In diesem Fall eine PCA-301-Steckdose. Hat man jedoch mehrere Mess-Steckdosen im Einsatz, kann es nützlich sein, alle Messwerte zusammenzuführen und somit den Gesamtverbrauch aller Steckdosen anzeigen zu lassen.
In meinem Fall habe ich zuerst die oben beschriebenen Schritte auch für meine zweite PCA-310-Steckdose im Arbeitszimmer durchgefüht und besitze nun folgende Dummys:
- WZStromkostenGesamt
- WZStromkostenJahr
- WZStromkostenMonat
- WZStromkostenTag
- AZStromkostenGesamt
- AZStromkostenJahr
- AZStromkostenMonat
- AZStromkostenTag
Die neu hinzugekommenen Dummys (AZStromkostenGesamt …) werden ebenfalls durch ein at-Device mit den Werten gefüttert und innerhalb der Dummys werden die Kosten berechnet. Mehr dazu in den oberen Schritten. Das Anlegen einer readingsGroup, FileLog und eines Diagramms sind optional und werden für folgende Schritte nicht unbedingt benötigt.
Für die Zusammenfassung der Messwert werden ebenfalls vier Dummys angelegt.
define StromkostenGesamt dummy; define StromkostenJahr dummy; define StromkostenMonat dummy; define StromkostenTag dummy;
Auch diese Dummys bekommen wieder ein paar Attribute. Jeweils für die einzelnen Dummys entsprechend anpassen.
attr StromkostenGesamt alias Gesamt; attr StromkostenGesamt room Stromkosten; attr StromkostenGesamt group Gesamt-Stromkosten; attr StromkostenGesamt stateFormat {sprintf("%.2f kWh - %.2f €",ReadingsVal("StromkostenGesamt", "Verbrauch",0),ReadingsVal("StromkostenGesamt","Kosten",0))}
Im Gegensatz zu den Dummys für die einzelnen Geräte, muss bei den Gesamt-Dummys der Verbrauch nicht über „monotonic“ errechnet werden. Hier erhalten alle Dummys den Verbrauchswert später über das at-Device, welches ja nur noch die einzelnen Werte zusammen zählen muss. Die Kosten könnte man auch über das at-Device zusammen zählen lassen, ich habe mich jedoch dafür entschieden, diese wieder im Dummy selber zu errechnen.
attr StromkostenGesamt userReadings Kosten {ReadingsVal("StromkostenGesamt","Verbrauch",0)*0.2507}
Genau wie bei den beiden einzelnen Messgeräte (PCA301-Steckdose) werden für die Dummys des Gesamtverbrauches ebenfalls ein at-Device angelegt.
define atGesamtStromkosten at +*00:01:00 a
Über den DEF-Editor wird das at-Device nun mit Leben befüllt:
+*00:01:00 {my $a = (ReadingsVal("WZStromkostenGesamt","Verbrauch",0));my $b = (ReadingsVal("WZStromkostenJahr","Verbrauch",0));my $c = (ReadingsVal("WZStromkostenMonat","Verbrauch",0));my $d = (ReadingsVal("WZStromkostenTag","Verbrauch",0));my $e = (ReadingsVal("AZStromkostenGesamt","Verbrauch",0));my $f = (ReadingsVal("AZStromkostenJahr","Verbrauch",0));my $g = (ReadingsVal("AZStromkostenMonat","Verbrauch",0));my $h = (ReadingsVal("AZStromkostenTag","Verbrauch",0));my $Gesamt = $a + $e;my $Jahr = $b + $f;my $Monat = $c + $g;my $Tag = $d + $h;fhem("setreading StromkostenGesamt Verbrauch $Gesamt"); fhem("setreading StromkostenJahr Verbrauch $Jahr"); fhem("setreading StromkostenMonat Verbrauch $Monat"); fhem("setreading StromkostenTag Verbrauch $Tag");}
Das at-Device besorgt sich nun die Werte der beiden PCA301-Steckdosen und rechnet die jeweils zusammen. Anschließend übermittelt es die errechneten Werte an die vier Gesamt-Dummys.
Absofort werden die Messwerte (Gesamt, Jahr, Monat und Tag) der beiden Mess-Steckdosen zusammengerechnet und in in den erstellen Dummys übersichtlich dargestellt. Wer möchte kann natürlich auch von den Gesamt-Dummys eine readingsGroup oder ein Diagramm erstellen. Mehr Infos dazu, entnehmt ihr aus den vorangegangenen Schritten.
Mir ist zwar bewusst, dass es eine Menga zu definieren gibt. Das Ergebniss hat mich jedoch überzeugt. Ich habe somit einen guten Überblick über die angefallenen Stromkosten. Hat man nun zum Beispiel eine Mess-Steckdose über, so kann man diese ja als mobiles Messgerät definieren und somit Langzeittests von unterschiedichen Geräten durchführen. Stromfresser hat man dann schnell ermittelt.
Ich hoffe ich konnte euch meine Idee der Stromkosten- und Verbrauchsanalyse etwas näher bringen. Solltet ihr Ideen haben, wie man dies eleganter reallisiert, könnt ihr gerne ein Kommentar hinterlassen. Ich bin für jede Idee dankbar.
Hallo.
Ich habe mir deinen Blog durchgelesen und soweit auch umgesetzt.
Jedoch habe ich ein Problem. Ich habe eine Revolt Messsteckdose die folgende Daten funkt (siehe unten)
energy ist der bis dato gesamt gemessene Verbrauch. power der Momentane Verbrauch.
Welchen von den beiden readings soll verwendet werden ?
Ich habe erstmal energy benutzt. Da passt dann aber der Tagesverbrauch nicht zusammen.
Hast du einen Tip ?
avgpower
173.81
2017-02-11 08:10:42
current
0.69
2017-02-11 08:11:48
energy
637.83
2017-02-11 08:11:48
frequency
50
2017-02-11 08:11:48
pf
0.82
2017-02-11 08:11:48
power
128.9
2017-02-11 08:11:48
state
P: 128.9 E: 637.83 V: 230 C: 0.69 F: 50 Pf: 0.82
2017-02-11 08:11:48
voltage
230
2017-02-11 08:11:48
Hallo Sasha,
So wie ich es sehe, ist das Reading „energy“ schon das richtige. Wie du schon sagst, ist dies der gesamte Verbrauch in kWh. Das Reading „power“ ist dann die aktuelle Leistung in W. Ich weiß jetzt nicht, was die Revolt-Steckdosen so für Funktionen haben, aber du benötigst ja nicht den Gesamtverbrauch (Energy) sondern ja nur den Tagesverbrauch. Deswegen sage ich ja, dass um 0:00 Uhr die Steckdose auf 0 gesetzt wird –> set WZ_Entertainment reset
Dadurch wird das Reading „consumption“ auf 0 gesetzt. Wenn deine Steckdose das auch kann, also durch ein reset-Befehl das Reading Energy auf 0 setzen, dann klappt es mit diesem Reading.
Wenn die Revolt jedoch kein Verbrauchs-Reading (kWh) haben, welches man durch reset auf 0 setzen kann, dann muss das at-Device bisschen anders aussehen.
Für die Dummys (deren Readings Verbrauch bzw. Tagesverbrauch) muss ja dann innerhalb des at-Devises muss der letzte Wert von Enegry am Vortag jeweils vom aktuellen Wert abgezogen werden, um nur den Tagesverbrauch zu bekommen.
Für den Graph müsste es aber reichen das Reading Energy in ein LogFile zu schreiben. Durch die Funktion „delta-d“ im Graph wird ja dann automatisch die Tages-Differenz gebildet.
Bin dieses Wochenden unterwegs, ich werde aber mal nächste Woche schauen wie man es am besten löst. Die PCA301-Steckdosen haben ja auch ein Reading, welches wie Energy ist -> consumptionTotal. Hier wird auch der Gesamt-Verbrauch abgespeichert, welches nicht durch reset auf 0 gesetzt wird.
Gruß Daniel
Hallo, hat jemand dazu eine Lösung gefunden? Mein Homematic Stromzähler kann ich auch über den energy Reading nicht nullen, der überträgt immer summiert weiter. Daher wird der Tagesverbrauch immer falsch. Gibt es eine Alternative für if(($hour==0) && ($min==0)){
fhem(„set WZ_Entertainment reset“)}
Es gibt ein Modul statistics. Dort kannst du für die Homematic-Dose ein Reading hinzufügen und das lässt sich einzeln oder je Reading reseten.
define mystatisticsenergie statistics Server
attr mystatisticsenergie deltaReadings Server
attr mystatisticsenergie room Statistiken
attr mystatisticsenergie singularReadings Server:energy:Delta:Day
fhem(„set mystatisticsenergie resetStatistics all“)}
Hallo Daniel.
Danke für deine Antwort. Das Reading „energy“ ist das was die Steckdose bis jetzt komplett gemessen hat.
Ich kann es zwar per „setreading energy 0“ zurück setzen, allerdings nur bis zur nächsten Übertragung der Steckdose. Es gibt auch keine Funktion, um dieses Reading zurück zu setzen, leider.
Ein Resetfunktion für die Dose gibt es nicht. Das heisst, man muss dann immer um 00:00 Uhr die Differenz bilden !?!
Das Reading „power“ ist der aktuelle Verbrauch.
Danke für deine Antwort und für den tollen Blog !!!
Gruß
Sascha
Hallo Daniel,
ENDLICH !!!
Endlich gibt es eine vernünftige Definition und Statistik der PCA301 Dosen für Tages-/Monats-/Jahreswerte. Bin begeistert.
Frage: Da ich 6 dieser Dosen habe, bläst es mir die logfiles so richtig voll. Eben aktuell jede Minute alle Werte.
Wie könnte man das performanter machen, so dass ggf. nur mit eventonchangereading oder nur täglich geloggt wird ?
Hallo Jörg,
bei sechs Steckdosen kommen natürlich eine Menge an Einträgen. Eine Möglichkeit ist natürlich das LogFile bisschen zu reduzieren, in dem man nun das gebrauchte Reading „WZStromkostenGesamt:Kosten“ ins LogFile schreibt. Dafür dann einfach die Definition des LogFiles ändern bzw. ein neues erstellen:
define StromkostenLOG FileLog ./log/StromkostenLOG-%Y-%m.log
WZStromkostenGesamt:Kosten.*
Eine zweite Möglchekt ist das Arbeiten mit event-on-change-reading. Dann wird nur ein Event bzw. ein LogFile-Eintrag bei Wert-Änderung geschrieben.
attr WZStromkostenGesamt event-on-change-reading .*
Für die andern Dummys entsprechend auch. Sollte sich nun aber ewig nichts ändern, dann wird auch kein Eintrag gespeichert. Deswegen eine Zeit festlegen, nach der spätestens ein Eintrag geschrieben werden soll.
attr WZStromkostenGesamt event-min-intervall 3600
So wird mindestens jede Stunde ein LogFile-Eintrag geschrieben.
Hat man nun aber ein Gerät welches durchgehend Strom verbraucht, so hat man ja dann immer noch jede Minute einen Eintrag. Da würde es eventuell helfen, im at-Device ein paar Spielerein zu betreiben.
Entweder das Intervall des at-Devices erhöhen, was aber dann wiederum dazu führt, dass die Abfrage-Zeitpunkte eventuell nicht mehr erwischt werden –> zB alle 5 Minuten nur –> 23:52, 23:57, 00:02 –> 0:00 ist es also nie. Deswegen ist diese Lösung eher kontraproduktiv. Man könnte dies dann verhindern, indem man nicht auf 0:00 fragt, sondern einen Bereich –> zwischen 23:55 und 0:05. Oder halt einfach guckt wann das at-Device Mitternachts auslöst.
Andere Möglchkeit ist das Abfragen innerhalb des at-Devices des aktuellen Wertes. Also gucken welcher Wert aktuelle in den Readings „Verbrauch bzw. Tagesverbrauch“ ist und überprüfen ob die Änderung zum aktuellen Verbrauch der Steckdosen größer x ist. Und erst dann die Readings aktualisieren. So hat man dann kleine Änderung erstmal rausgefiltert ohne das durch das event-on-change-reading ein Event für eine Änderung von 0,01 kWh ausgelöst wird. Mein PC zum Beispiel ist nachts auch immer im Standby. Verbraucht dann halt nicht viel. Aber immer noch so viel, dass alle paar Minuten eine Änderung des Verbrauchs stattfindet und somit ein Eintrag im LogFile. Trotz event-on-change-reading.
Ich bin jetzt am Wochenden unterwegs. Ich werde aber mal Anfang nächster Woche selber mal bisschen rum probieren, was am besten funktioniert. Schließlich will ich meine PCA301-Familie auch nach und nach erweitern. Und mit dem LogFile ist das ja dann wirklich ein Problem.
Hoffe ich konnte dir aber schonmal ein paar Tipps geben.
Gruß Daniel
Hallo Daniel,
ich habe mal event-on-change-reading .*
eingebaut. Wie du vermutest hattest, bringt es nicht soo viel. Mich wunderst, dass du da keine Performanceprobleme hast. Zwr ist meine Pi auch nur zu ca. 30% ausgelastet – aber in dem Moment in dem dann jede Minute die PCA gelesen und die Werte wiederum ins filelog geschrieben werden, „tanzt“ der perfmon.
Eine Lösung wäre daher toll.
Grüße
Jörg
Hallo Jörg,
mit der Auslastung finde ich etwas komisch. Selbst wenn man 10 Steckdose hat, die minütlich einen Wert loggen, sollte das doch den Raspberry nicht so ins schwitzen bringen.
Ich logge zwar aktuell nur zwei Steckdosen (jeweils minütlich, nur den Gesamt-Kosten-Wert –> alos zwei Werte jede Minute). Ich habe jedoch auch bestimmt um die 20 Sensoren, bei denen ich minütlich die Werte logge. Dann kommen noch die Traffic-Werte meiner Fritz-Box dazu (alle drei Minuten) und die Werte der beiden Steckdosen um die Leistung (in W) plotten zu können, da logge ich alle 5 Sekunden jeweils den Power-Wert.
Insgesammt komme ich also auch auf eine nicht allzu kleine Anzahl an Einträgen. Mein Raspberry 3 hat dennoch immer nur eine Auslastung von 3-5% – Spitzenwerte von maximal 10%.
Wie aber schon erwähnt, eine Möglichkeit ist das Vergrößern des Intervalls oder mit dem Attribut event-on-change-reading bzw. event-min-intervall zu arbeiten.
Oder halt komplett auf das kontinuierliche loggen verzichten und nur einmal am Tag den Kostenwert loggen:
define atStromkostenDailyLog at *23:59:00 {
my $Kosten = ReadingsVal("WZStromkostenGesamt","Kosten",0);
fhem("setreading WZStromkostenGesamt DailyKosten Kosten");
}
So wird immer um 23:59 Uhr das Reading „DailyKosten“ mit dem am Tag angefallenen Kostenwert gesetzt. Mit einem LogFile kann man dann dieses erstellte Reading loggen und hat somit nur ein Wert pro Tag:
define StromkostenLOG FileLog ./log/StromkostenLOG-%Y-%m.log WZStromkostenGesamt:DailyKosten:.*
Oder man loggt nur alle zwei Stunden:
define atStromkostenDailyLog at +*02:00:00 {
my $Kosten = ReadingsVal("WZStromkostenGesamt","Kosten",0);
fhem("setreading WZStromkostenGesamt DailyKosten Kosten");
}
Nachteil ist dann aber, dass das Diagramm sich nicht stetig mit verändert, sondern halt nur sobald neue Werte im Logfile erscheinen. Entweder also jeden Tag oder halte alle 2 Stunden.
Du kannst die oben beschrieben Lösung ja mal testen und schauen ob es bezüglich der Auslastung hilft.
Gruß Daniel
Hallo Daniel,
wieder mal super Arbeit von Dir! Vielen Dank dafür. Hat auf Anhieb funktioniert, obwohl ich andere Steckdosen verwende. Perfekt! Weiter so!
Hallo,
ich habe deine Anleitung aufmerksam studiert.
Dennoch verstehe ich das mit dem readings nicht ganz.
Ich habe eine HOmematic HM-ES-TX-WM.
Im Channel_01 (Bereich Wohnung_IEC_01) habe ich die readings energy und power.
Wo und wie muss ich jetzt dieses reading Bsp. energy in dein Script einfügen ?
Vorab Danke
Hallo André,
ich kenne jetzt die Homematic-Steckdosen nicht, aber so wie es aussieht, ist das Reading „energy“ das Verbrauchsreading.
Dieses Reading muss dann im eingerichteten at-Device abgefragt werden.
Folgende Zeile muss angepasst werden:
my $a = (ReadingsVal(„WZ_Entertainment“,“consumption“,0));
Anstatt „consumption“ vom Device „WZ_Entertainemnt“ muss dann das energy-Reading deiner Homematic-Steckdose abgefragt werden.
Gruß Daniel
Weiter oben in den Kommentaren benutzt auch einer die Homematic-Steckdosen. Zum Reseten des Readings muss du dann mit dem Modul „Statistic“ arbeiten. Mehr Infos weiter oben in den Kommentaren.
Gruß Daniel
Hallo Daniel,
Danke für die klasse Anleitung.
Ich habe deine Anleitung für mich noch um die aktuelle Leistung ergänzt.Funktioniert wunderbar. Ich habe nur einen Schönheitsfehler,
Die Gruppe scheint Tag, Monat Jahr usw. alphabetisch zu sortieren und „Leistung“ steht jetzt einfach mitten drin. Gibt es eine Möglichkeit die Reihenfolge festzulegen?
Besten Dank
Jan
Hallo Jan,
schau dir mal das Attribut „sortby“ an. Damit kannst du Devices innerhalb einer Gruppe sortieren. Zum Beispiel:
attr Leistung sortby 1
attr Tag sortby 2
attr Monat sortby 3
usw.
Gruß Daniel
Super anleitung, ich suche zur Zeit genau so etwas, nur zum loggen der Heizkostenzähler. Vielleicht schaffe ich es die Anleitung auf meine Zwecke umzubasteln.
Hallo Daniel
Ich benutze einen nodemcu für Hausstrom, Wärmepumpe, Trinkwasser Verbrauch. Mit ist aufgefallen das der Eintrag zum Reset den nodemcu resetet und er alle Daten Verliert ich habe es Mal abgeänderte in reboot Mal schauen ob es funktioniert.
LG Andre
if(($hour==0) && ($min==0)){
fhem("set WZ_Entertainment reset")}
Hallo.
Ich habe mir 3 PCA301 bestellt. Kann man die mit einem nanoCUL betreiben, oder braucht man da was anderes? Vielen Dank.
Hallo Björn,
Für die PCA301-Steckdosen eignet sich der JeeLinkClone am besten. Hier mein Blogbeitrag zum Thema.
Gruß Daniel
Hallo Daniel,
ich habe bis hier hin alles gemacht, aber ich weiß nicht, wie ich die abgewandelten Befehle aussehen sollen.
Kannst du mir die angepassten Befehle für Jahr, Monat, Woche uns Tag schicken?
Ich blicke da nicht durch!!! 🙁
Vielen Dank!
Gruß
DJSirius