Strommessung einmal anders?

[justme1968]

@elektrolurch:

- die readings für die PCA301 und EC3000 sind power und consumption. type und reading genau so wörtlich.

- die beiden und auch der hm stecker liefern events auch für den verbrauch.

- es wäre klasse wenn pct, dim, und andere stufen zwischen on und off eingebaut werden.

@der-Lolo:

- die hue devices sollten über on/off und später dann über dim bzw pct ganz normal funktionieren

gruss
  andre

[der-Lolo]

Das Reading im 2ten Kanal von Homematics HM-ES-PMSw1-Pl heisst schlicht power es steht auch aufsummiert zur Verfügung, nennt sich dann energy - das zählt alle Verbräuche zusammen während der Zwischenstecker unter Strom war, wird die Sicherung ausgeschaltet, oder der Stecker aus der Steckdose gezogen wird energy genullt.

[Elektrolurch]

Hallo,

Zitat:
- es wäre klasse wenn pct, dim, und andere stufen zwischen on und off eingebaut werden.
Was ist das? pct, Welchem power-Anteil in % entspricht das?

Wenn man über die dim-Problematik mal nachdenkt, ist das nicht so ganz trivial, weil z.B. ein FS20 - Schalter bspw. bei längerem Drücken ein dimup,dimdown oder dimupdown sendet und nicht einen %-Wert.
Dann müsste ich für FS20 eine Liste der verfügbaren dim-Werte hinterlegen und entsprechend des vorherigen Zustandes den nächsten berechnen. Und wie sehen die dim-Stufen bei Homeatic aus oder bei beliebigen anderen Dimmern?
Und dann kann das Verhalten zwischen FS20 und Homematik der Dimmer noch anders sein:
Beispiel:
1. Dim-Wert einstellen
2. ausschalten
3. Einschalten (geht der auf den letzten dim-Wert oder auf 100% ?

Also, nicht so ganz trivial und ev. auch nicht universell lösbar.

energy / consumption

Würde ich nicht auswerten, wegen der nicht zeitlich "terminirbaren" Rücksetz-Problematik.

Das gleiche tritt vmtl. nämlich schon bei "on-for-timer" events auf, wenn nicht "follow-on-timer" gesetzt ist. Und wenn das gesetzt ist (muss ich noch ausprobieren), generiert fhem dann tatsächlich nach Ablauf des timers in dem fs20 - device ein Event "off", was dannn vom EM notify ausgewertet werden kann? Oder sorgt das Attribut "follow-on-timer" nur dafür, dass der state des devices gesetzt wird?


Für andere Zwischenwerte, die nicht dim sind,  könnte ich mir nur als sinnvolle Lösung einen hook vorstellen:
so als Beispiel:

Attribut:
user-events step1|step2|step3 # regex für events des device
user-power-method EM_mein_onitor
ist dann eine Routine die bei user-events auftreten mit dem hash des EM, dem Device und dem event aufgerufen wird.
Darin wird dann vom Anwender selbst der Verbrauch seit dem letztten Ereignis berechnet und im reading des devices unter power-hourly gespeichert.

Das würde ich als die sinnvollste Lösung für beliebige "Stromereignisse" ansehen.
Die Berechnung der Statistiken erfolgt immer aus der Ableitung der Werte in "power-hourly" und ist damit dann unabhängig von den devices.

Gruß

Elektrolurch

[justme1968]

- bei fs20 hast du mit dem dim recht. bei devices die bidirektional kommunizieren geht es aber. da hast du normalerweise ein reading in dem der aktuelle stand drin steht. bei den meisten devices ist das pct. da steht ein wert zwischen 0 und 100 drin. für fs20 gibt es vermutlich keine universelle lösung.

- follow-on-for timer betrifft nur devices die keine rückmeldung geben und den timer trotzdem intern handhaben. hier wird  dann ein interner timer verwendet damit fhem den state korrekt widerspiegelt wenn das device von sich aus abschaltet. es gibt ein ganz normales event. das ganze betrifft aber glaube ich nur fs20.

- wie wäre es der regex für eine stufe gleich den power wert zuzuordnen? bei deinem vorschlag müsstet du zumindest di zeit mit übergeben. sonst muss die routine selber zeiten aufsummieren.

gruss
  andre

[Elektrolurch]

Hallo,

1. zu dim
bei FS20 sehe ich da schwarz, da beim Einschalten "ein" der Dimmer erst einmal auf den alten Wert geht, fhem aber auch nur "ein" anzeigt. Solange FS20 Taster direkt die devices ansteuern, dürfte man das mit dem Dimmen nicht richtig tracken können.
2. PCT: ist das generell so, dass hier bei Homematic immer der aktuelle "dim" - Wert drin steht? Da ich keine Homematic habe, kann ich das nicht nachvfollziehen und bräuchte da schon genaue Informationen, wie ein,aus und pct bzw. dim-Events zusammenspielen.


3. zu dem hook:
Der bekommt den hash des devices mit und hat somit auf die vom EM angelegten internen Werte zugriff, wie z.B. ontime und offtime.
power-hourly steht beim device in einem reading. Die hook-Routine müsste den dann selbst korrekt inkrementieren.
Die Frage ist nur, bei welchem event die Routine angesprungen werden soll, denn der EM soll ja standardmäsig on/off etc abarbeiten. Icfh hatte bei dem hook zunächst einmal an die Frage nach dem Lüfter mit den mehreren Stufen gedacht. Die Zwischenstufen würde dann die hook-Routine abarbeiten, on/off standardmässig von EM.
Wobei mir jetzt beim Nachdenken aufgefallen ist, dass das so wahrscheinlich gar nicht geht.
Beispiel:

'Der Lüfter steht auf step3 und geht nach off.
Der Verbrauch berechnet sich nun aus der Differenz der Zeit, wann der Lüfter auf step3 gegangen ist und der Zeit, wann das off kam. Multipliziert mit dem Verbrauchswert für step3.
Da "off" jetzt für den EM ein Standardereignis wäre, aber nichts von den Verbrauchsswerten für steps weiß, kann er nur die Differenz zwischen on und off berechnen.
Der Trigger für den hook bezüglich der "unknown" event zu machen (die in dem regex stehen), ist wohl kein gangbarer Weg.
Stattdessen könnte man die Erweiterbarkeit device-abhängig machen. Dann muss der user für diese "besonderen" device komplett selbst den Energieverbrauch berechnen lassen....
Hauptsache er befüllt power-hourly korrekt.

Wobei es dabei auch noch einmal eine Besonderheit zu berücksichtigen gilt:

Wie schon "power-hourly" besagt, dieser Wert wird einmal pro Stunde in die nächst höhren Zeiteinheitsverbrauchswerte übernommen und dann wieder auf 0 zurückgesetzt.
Das setzt aber voraus, dass der EM die Art und Weise der Verbrauchsberechnung kennt.
Hintergedanke dabei ist, dass ja eine Lampe vor der stündlichen Verbrauchswerteaktualisierung und danach noch brennen kann. Der EM geht daher hin und tut so, als wäre zum stündlichen Berechnungstermin die Lampe "kurz" ausgeschaltet worden, d.h. holt den "power-hourly" Wert ab und setzt die internen timer powerontime und powerofftime auf die aktuelle Zeit.
Und an dieser Stelle müsste jetzt die hook-Routine sich genauso verhalten, bzw. vom EM aufrufbar sein, sozusagen also seine Messung machen und alles auf den aktuellen Zeitpunkt setzen....

Gruß


Elektrolurch

[P.A.Trick]

Uh das wird alles komplexer als ich gedacht habe. Soll ich die ganzen Anforderungen und Gedanken mal in ein Konzept pressen?
Wäre das für Euch hilfreich?

[justme1968]

sammeln und konzept ist eine gute idee. aber nicht versuchen dann in der ersten versuon alles zu erschlagen.

[P.A.Trick]

sammeln und konzept ist eine gute idee. aber nicht versuchen dann in der ersten versuon alles zu erschlagen.

Ja ich bin da eher auch für den pragmatischen Weg des 80% Ansatzes Bis jetzt ist der Thread ja noch recht übersichtlich!

[Elektrolurch]

Hallo,

man kann das Thema in zwei Teile aufspalten:

a) aus dem device per notify den aktuellen Verbrauch ermitteln.
Stand: on/off und hinterlegter Stromverbrauch für on und off als Attribut.
oder
powr, für devices mit Verbrauchsmessung.
b) Die Statistik, die stündlich aktualisiert wird
Da ist derzeit implementiert:
1. group des devices. Alle Verbrauchswerte von devices mit gleicher group werden gesammelt.
Dabei werden auch mehrere groups bei einem device berücksichtigt.
2. Das gleiche für rooms
3. Das Sammeln der Verbrauchsdaten lässt sich für groups und rooms gesondert per Attribut ein- und ausschalten.
4. all, da werden alle Verbraucher gesammelt.
5. readings des EM:
all-power-hourly, all-power-daily, all-power-weekly, all-power-monthly, all-power-yearly
dto. für die Namen der groups und rooms, die EM sammelte.
z.B. Wohnzimmer-power-hourly....
oder
Beleuchtung-power-hourly...
Media-power-hourly

Als nächstes werde ich, damit ich auch vernünftig testen kann, ein

set <EM> reset <name> bauen,
wobei <name> ein group-Name, rom-Name, ein device-Name oder 'all' sein kann.


b) ist unabhängig von den zu erfassenden devices.
Für a) einen echt universellen, und auch erweiterbaren Ansatz zu finden, ist etwas tricky.

Hinweis für Vorschläge (siehe auch oben)
Man muss hier zwei Aspekte berücksichtigen:

1. Ein event, was vom device kommt und eine Änderung des Stromverbrauches signalisiert. Zu diesem Zeitpunkt muss der Verbrauch seit dem letzten Ereignis (s.u.) ermittelt werden.
2. Das Ereignis "stündliche Aktualisierung der Statistik" Der Stromverbrauch muss ermittelt werden und der Zähler muss zurück gesetzt werden.

Alles was über on/off hinaus geht als Schaltzustand, muss vermutlich individuell in irgend einer Form hinzufügbar sein (als Name einer externen perl-Routine) oder über den TYPPE  des devices.

Gruß

Elektrolurch

[P.A.Trick]

Hey das liest sich schon super! Wenn du eine Alpha Version fertig hast, biete ich mich gerne als Tester an!
PS: habe heute mal mit Threshold versucht meinen Durchlauferhitzer zu erkennen! Das klappt eigentlich ganz gut, da ich keine Verbrauch über 7 KWh habe. Auch der Gesamtverbrauch des Hauses kommt nie in diesen Bereich!

[Elektrolurch]

Noch ein bisschen Geduld. Es sind schon ca. 800 Zeilen Code geworden und in den nächsten Tagen will ich mit dem Testen anfangen und noch einmal eine vollständige Revision durchführen.

Gruß

Elektrolurch

[P.A.Trick]

Mache dir keinen Stress! Es ist fertig wenn es fertig ist!

[Elektrolurch]

Hallo,

hatteleider keine Zeit und komme erst jetzt wieder am Wochenende zum "Energiemonitor".
Dabei hätte ich jetzt zu folgendem Punkt mal gerne eure Meinung gehört. Es geht um die Fortschreibung der gesammelten Werte über Stunde,Tag,Woche,Monat,jahr.

Da gibt es zwei Ansätze:

1. Alle Zähler für Stunde,Tag,Woche,Monat und Jahr werden im "Stundentakt" um den Wert der letzten Energiemessung der vergangenen Stunde erhöht. Jeweils an den Zeitgrenzen, also bspw. um 0 Uhr wird dann der Tageszähler auf 0 zurückgesetzt, am Monatsanfang der Monatszähler usw.
Man erhält dann pro Zähler "Rampen" und für jeden Zähler stündliche Events.
2. Jeder Zähler enthält den Wert der letzten (nicht aktuellen) Zeiteinheit, d.h. z.B. die 24 Werte des Stundenzählers müssen intern aufsummiert werden und werden dann genau um 0 Uhr in den Tageszähler geschrieben, der dann den Energieverbrauch des letzten Tages enthält.
So entstehen keine "Rampen" und man kann sich z.B. über die Definition eines logs einen entsprechenden Plot über den Tages-, Wochen- oder Monatsverbrauch anzeigen lassen.
Für den Jahresverbrauch gibt es dann aber pro Jahr auch nur einen Wert.
Das Problem ist hierbei, dass man nicht mit einfachen Überlauffunktionen arbeiten kann, denn vier Wochen sind bspw. mal nicht ein Monat usw. d.h. intern aufwendiger in der Verwaltung.


Beide Versionen haben Vor- und Nachteile.

Also, auf zur Diskussion.

Gruß

Elektrolurch

[John]

Hi Elektrolurch,

ich hab beim Entwickeln vom Hourcounter beide Variante realisiert.

Die *Temp Readings nehmen die einzelnen Inkremente auf.
Die Ziel-Readings werden nur beim Wechsel des Inkrement-Zeitraumes aktualisiert.

Beispiel
appCountsPerHour            Stundenzähler, wird bei Stundenwechsel aktualisiert
appCountsPerHourTemp    Arbeitszähler zu appCountsPerHour

Beim Stundenwechsel wird der Arbeitszähler in den eigentlichen Zielwert appCountsPerHour kopiert.

Somit sind beide von dir vorgestellten Varianten realisiert.

Vielleicht hilft dir ja der Source-Code vom HourCounter etwas weiter. Hier werden Stunden, Tages, Wochen, Monats und Jahreswerte realisiert.

Jede Aktualisierung der kumulativen Readings löst wiederum einen Event aus, was nicht trivial ist, da FHEM normalerweise innerhalb eines Events nicht nochmals einen auslösen kann. Aber auch dazu findest du im Skript die Lösung.

Hierzu gerade heute von Rudi nochmal die Bestätigung
http://forum.fhem.de/index.php/topic,28017.msg209074.html#msg209074

Wenn man ein Reading R fuer Geraet G aus einem Notify fuer dieses Geraet G setzt, dann wird fuer R kein Event generiert.
Gilt fuer Events generell, ist nicht notify-spezifisch.

John

[Elektrolurch]

Ok. Danke für den Tipp. Ohne internen Zähler wird man nicht auskommen.
Frage: Wie heißt die Datei vom hour-counter?
Dann schaue ich mir mal da den Code an und werde ggfgfs. auch die Namenskonvention übernehmen.