Ich würde gerne mal eine Idee in den Raum stellen. Ich messe meinen gesamten Stromverbrauch im Haus mit einem EM1000.
Das funktioniert soweit auch ganz gut. Einige Geräte u.a. die Waschmaschine habe ich mit DECT200 ausgestattet um den Verbrauch zu messen.
Nun das ganze Haus mit solchen Dosen auszustatten sprengt mein Taschengeld welches in von meiner Frau bekomme :-)
Nun zur Idee
Wie wäre es, wenn es ein globales Attribut "Verbauch ~" bei jedem Device als festen Wert eingetragen würde. Dann müsste man nur die Geräte
die den Status "on" oder pct > 0 usw. haben durchzählen um den geschätzten Verbrauch darzustellen (in einem Zeitintervall 1min o.ä.). Diesen könnte man dann vom Gesamtverbrauch
abziehen und würde so über die Zeit zu einer einigermaßen reellen Rechnung kommen. Sofern ein Verbrauchsmesser eingesetzt wird, kann auch der "echte"
Verbrauchswert für die Messung hinzugezogen werden.
So jetzt bin ich gespannt auf Eure Antworten?
Ich finde die Idee klasse.
Damit kann man zumindest mal eine theoretische Verbrauchskurve errechnen. Müsste man für jedes Gerät dann eben einmal in einer Art Datenbank hinterlegen (am Besten nicht in einem Modul, sondern in einer großen HASH Tabelle, die jedes Modul nutzen kann). Dabei müssten natürlich verschiedene Status berücksichtigt werden wie An, Aus, Standby. Toll wäre natürlich auch, wenn die Werte dann im tatsächlichen Device vom Nutzer manuell überschrieben werden könnten. Sprich: Man ist einmal mit einem Messer durch die Wohnung gelaufen und hat den Verbrauch pro Gerät tatsächlich einmal gemessen und dann trägt man das dort einmal ein.
Ist dann alles sicherlich nicht 100% korrekt am Ende, aber wenn man mit sowas schon bei 90-95% landen würde, wäre das ja schon super!
Zitat von: Loredo am 11 September 2014, 15:47:43
Müsste man für jedes Gerät dann eben einmal in einer Art Datenbank hinterlegen
Ich denke hier recht es aus ein entsprechendes Attribut ggf. auch global zur Verfügung zu stellen.
Ggf. auch perl interpretierbar. So könnte man auch den Verbrauch von dimmbarem annähernd abschätzen in dem man im Attribut z.B. eine Formel hinterlegt.
Ich hatte das mal testweise für meine Dimmer und Glühbirnen und Halogenstrahler mit Trafo getestet.
Der eingestellt Dimmwert entsprach in etwa der verbrauchten Energie. Also 50% Dimmwert = 50% Energieverbrauch.
Sowas steht bei mir auch noch auf dem Programm, dachte dabei vor allem an Geräte die konstant viel Strom verbrauchen, Lampen z.B.
Na dann sind wir schon einmal vier Personen! Wie bekommen wir denn so ein globales Attribut in FHEM rein?
Ich denke da müssen wir Rudi schon von überzeugen, oder?
Mit einem globalen Attribut alleine ist es aber nicht getan ;-)
Das Attribut braucht auch einen Standardwert, sonst müsste ja jeder für seine Geräte zwingend den Stromverbrauch messen. Ich finde, wenn einmal jemand gemessen hat, kann man das mal als Referenzwert festhalten und damit allen leicht verfügbar machen.
Außerdem braucht es natürlich noch einen Automatismus, der dann entsprechende Readings in den Geräten aktualisiert. Das kann man krückenhaft mit jeder Menge Notifies machen oder einmal gescheit. Ich wäre für letzteres ;)
Ich überlege mal, wie ich da was umsetzen könnte. Ich könnte das dann direkt im Quellcode veröffentlichen und nötige Änderungen an Bestandscode mit Rudi absprechen bzw. ihm Patches zum abnicken schicken.
Zitat von: Loredo am 11 September 2014, 17:22:15
Mit einem globalen Attribut alleine ist es aber nicht getan ;-)
Das Attribut braucht auch einen Standardwert, sonst müsste ja jeder für seine Geräte zwingend den Stromverbrauch messen. Ich finde, wenn einmal jemand gemessen hat, kann man das mal als Referenzwert festhalten und damit allen leicht verfügbar machen.
Außerdem braucht es natürlich noch einen Automatismus, der dann entsprechende Readings in den Geräten aktualisiert. Das kann man krückenhaft mit jeder Menge Notifies machen oder einmal gescheit. Ich wäre für letzteres ;)
Ich überlege mal, wie ich da was umsetzen könnte. Ich könnte das dann direkt im Quellcode veröffentlichen und nötige Änderungen an Bestandscode mit Rudi absprechen bzw. ihm Patches zum Abnicken schicken.
Hey prima! Ich bin zwar ein Perl-Noob aber wenn ich dir irgendwie behilflich sein kann sag' bitte Bescheid.
Ansonsten melde ich mich als Betatester und Wiki-Schreiber an! :-)
PS: Bierchen gibt's natürlich auch beim nächsten Treffen (Karlsruhe?)
Ein globales Attribut kann man auch selbst als userattr an global definieren. Denn Rest könnte ein dafür geschriebenes Modul tun. Wie etwa dewpoint-Modul.
zum schaltzeiten/verbraucht/... auswerten gibt es doch das HourCounter modul (http://www.fhemwiki.de/wiki/HourCounter (http://www.fhemwiki.de/wiki/HourCounter)). vielleicht braucht es nur ein bisschen schnittstellen code um die einfachen fälle mit so einem standard attribut abzudecken.
gruss
andre
Zitat von: hexenmeister am 11 September 2014, 17:25:14
Ein globales Attribut kann man auch selbst als userattr an global definieren. Denn Rest könnte ein dafür geschriebenes Modul tun. Wie etwa dewpoint-Modul.
Würde ich persönlich jetzt nur ungern in einem Modul benutzen. Das Attribut hat ja nicht umsonst "User" im Namen; finde es sollte nur für custom Sachen genutzt werden :)
Ist auch kein Problem ein globales Attribut zu definieren. Das kann jedes Modul auch selbst in den HASH schreiben.
Ich mache mal einen Entwurf.
Zitat von: Loredo am 11 September 2014, 17:22:15
Das Attribut braucht auch einen Standardwert, sonst müsste ja jeder für seine Geräte zwingend den Stromverbrauch messen.
Nicht zwingend.
Wenn kein Attribut vergeben, dann gibt es für das entsprechende Device ebend keine Messung.
Zitatkann man das mal als Referenzwert festhalten und damit allen leicht verfügbar machen.
Jeder weis doch am besten genau was für ein Gerät an einem Aktor drann hängt. Was willst du da denn noch "verfügbar" machen.
Bei Lichtquellen reicht in der Regel ein Blick auf die Verpackung oder an die "Lampe"
Und natürlich muss es noch ein Modul, was auch immer geben, der die "virtuellen Verbrauchdaten" verarbeitet.
Ggf. bekommt jedes Device welches das Attribut definiert hat ein neues Reading was z.B. einmal bei einem Statusupdate des Devices aktualisiert wird.
Das kann man dann sogar Plotten
Zitat von: hexenmeister am 11 September 2014, 17:25:14
Ein globales Attribut kann man auch selbst als userattr an global definieren. Denn Rest könnte ein dafür geschriebenes Modul tun. Wie etwa dewpoint-Modul.
Zitat von: Dirk am 11 September 2014, 17:32:44
Nicht zwingend.
Wenn kein Attribut vergeben, dann gibt es für das entsprechende Device ebend keine Messung.
Aus technischer Sicht richtig. "Brauchen" war das bayerische "brauchen", was nicht zwangsweise eine Notwendigkeit impliziert (ich wohne wohl schon zu lange hier ;) ).Gemeint war allerdings, dass es benutzerfreundlich ist, bereits bei möglichst vielen Geräten den Standardverbrauchswert zu haben.Zitat von: Dirk am 11 September 2014, 17:32:44Jeder weis doch am besten genau was für ein Gerät an einem Aktor drann hängt. Was willst du da denn noch "verfügbar" machen.
Ich möchte dem Nutzer ersparen, extra bei jedem Gerät auf die Suche nach der Watt-Angabe zu machen.Zitat von: Dirk am 11 September 2014, 17:32:44Bei Lichtquellen reicht in der Regel ein Blick auf die Verpackung oder an die "Lampe"
So man die Packung noch hat ;)
Die Herstellerangaben können allerdings auch mal gehörig abweichen. Oftmals sind auch nur die Leistungswerte des Netzteils aufgedruckt, die aber mit dem tatsächlichen Verbrauch in der Praxis gar nichts gemein haben müssen.
Zitat von: Dirk am 11 September 2014, 17:32:44Ggf. bekommt jedes Device welches das Attribut definiert hat ein neues Reading was z.B. einmal bei einem Statusupdate des Devices aktualisiert wird.Das kann man dann sogar Plotten
Genau so.
Zitat von: Loredo am 11 September 2014, 17:50:23
So man die Packung noch hat
Und mit welchen Daten soll der Benutzer dann die Lampe in der DB finden?
"Osram 25 W E14"? Dann kann ich die 25 W auch gleich in das Attribut eintragen.
Sofern sehe ich in so einer DB noch keinen wirklichen Sinn. Was für Geräte sollen da aufgenommen werden?
HiFi Geräte, Fernseher usw. werden sich für diese Art der Verbrauchsermittlung nicht eignen weil der Verbrauch hier zu sehr vom Nutzerverhalten abhängt.
Genauso mit Waschmaschine Kühlschränken usw.
Daher bleibt hier fast nur die Beleuchtung übrig.
Und die Verbrauchsangabe steht hier in der Regel auf dem Lampensockel.
Oder übersehe ich noch was?
ZitatDie Herstellerangaben können allerdings auch mal gehörig abweichen.
Wenn man es recht genau haben will, kommt man um die eigene Messung dann eh nicht drum herum.
ZitatOftmals sind auch nur die Leistungswerte des Netzteils aufgedruckt, die aber mit dem tatsächlichen Verbrauch in der Praxis gar nichts gemein haben müssen.
Die Leistungswerte des Netzteiles geben nur an wie viel das Netzteil liefern kann. Und auch hier ist das Gerät dahinter für den Verbrauch zuständig. Und das müsste bei der geplanten Erfassung einen kontinuierlichen Verbrauch haben. Ansonsten wird das wirklich nur eine sehr ungenaue Schätzung.
Zitat von: justme1968 am 11 September 2014, 17:30:22
zum schaltzeiten/verbraucht/... auswerten gibt es doch das HourCounter modul
Das halte ich auch für die beste und einfachste Lösung. Betriebszeiten der Geräte erfassen und per Userreading und Faktor für den Stromverbrauch diesen berechnen.
Allerdings interessiert mich der Verbrauch möglichst vieler Geräte überhaupt nicht. Ich messe nur den Haus- Gesamtverbrauch und wenn ich ein Gerät als Stromfresser in Verdacht habe, logge ich es für kurze Zeit um mir einen Überblick zu verschaffen. Dazu reicht eine "temporäre" Messdose oder ein einfacher Energiemonitor. Was diese Lösung auch nicht kann: Schleichend steigenden Verbrauch anzeigen.
Dazu könnte man zusätzlich zum Erfassen der eingeschalteten Geräte, deren virtuellen Stromverbrauch addieren und mit dem Aktualverbrauch des Hauses vergleichen. Also wenn Gerät A+B+C an sind und der Gesamtverbrauch seteigt über Wert X, verbraucht eines der Geräte mehr als es sollte.
Gruß
Frank
Hallo!
Schaut mal hier http://forum.fhem.de/index.php/topic,17506.msg114979.html#msg114979
Mit dem script hat das schon ganz gut funktioniert. Geht aber nur mit on/off und ist nicht wirklich schön programmiert ;) Das modul das daraus entstanden ist aber nur mehr oder weniger lauffähig. Müsste suchen ob das noch irgendwo zu finden ist.
Hallo,
zu dem Thema habe ich mir auch ein paar Gedanken gemacht und werde mal in den nächsten Wochen dazu auch etwas programmieren.
Ansatz:
1. Ich habe zwei DECT200, die liefern ja über das reading "power" direkt den Stromverbrauch.
2. Meine FS20 liefern die Infos, ob etwas ein- oder ausgeschaltet wird.
3. Dann gibt es noch permanent eingeschaltete Verbraucher, die ich auch erfassen möchte.
4. Dann verbleiben noch die nicht erfassten Geräte, wie z.B. Herd.
Ich würde ein eigenes Modul hierfür entwerfen. Über die notifyFN bekommt das Modulalle events mit. Ich würde auf den TYPE schauen (z.B. DECT200 und da "power" auswerten) oder z.B. FS20 (da ein / aus auswerten).
Bei den devices, die nur ein- und aus liefern, muss dann in einem reading der Verbrauch hinterlegt werden. Alle Geräte, bei denen der Verbrauch hinterlegt ist, werden dann von dem Modul erfasst und der Verbrauch gespeichert.
Nun zur Erfassung des Verbrauchs:
a) Entweder liest man den vom Sockel der Lampe ab (Beispiel) und setzt dann
setreading Lampe1 power 15
b( oder man macht das mit Modul-Unterstützung und einer DECT200.
set meinEnergieMonitor measure myTV ts
myTV ist das zu messende Gerät
ts die Messsteckdose (DECT200).
Wird myTV über fhem eingeschaltet, so wird auch der Verbrauch mit Hilfe von ts gemessen und die Kalibrierung dann im reading power von myTV hinterlegt.
Die permanenten Verbraucher, wie z.B. Fritzbox, Heizungsanlage usw. werden als dummys angelegt und auf "ein" gesetzt.
Um Statistiken machen zu können, wird von den erfassten devices das "group" Attribut ausgewertet. Das ist bei mir z.B. "Beleuchtung", "Media" usw.
Wenn ich das hab, dann sehe ich mal weiter, was ich mit den Daten noch so mache.
Da ich keine Möglichkeit habe, meinen Stromzähler automatisch zu erfassen, mache ich das derzeit per Hand einmal im Monat und trage das in fhem ein, um so den durchschnittlichen Monatsverbrauch und den zu erwarteten Jahresverbrauch zu berechnen.
Das würde ich dann mit dem EM verknüpfen.
Die Lösung hat den Vorteil, das in fhem nichts geändert werden muss, lediglich der Verbrauch wird als reading bei den Geräten hinterlegt.
Gruß
Elektrolurch
Hört sich gut an! Ich stelle mich schon einmal als Betatester bereit!
Zitatmuss dann in einem reading der Verbrauch hinterlegt werden
Nicht Reading sondern Attribut.
Reading ist fuer das Modul vorgesehen, um Daten die gespeichert werden, zu setzen.
Der Benutzer sollte Attribute setzen. userReading ist mehr oder weniger eine Fehlentwicklung.
Hallo,
für bestehende devices kann man doch keine Attribute hinzufügen?
Die Liste wird doch bei der Moduldefinition mit "attrlist" festgelegt oder der Energiemonitor müsste beim Start alle Module, die er nutzen soll, lesen und dann überall an die attrlist noch ein Attribut anhängen. Und dann muss man noch aufpassen, ob die Module schon geladen sind.
Meiner Meinung nach ist der Stromverbrauch auch ein Wert des devices und kann dort als reading hinterlegt werden.
Gruß
Elektrolurch
mit addToAttrList kann ein modul neue globale attribute definieren.
die leistung die pro device konfiguriert werden
müsste gehört in ein attribut. der wert wird ein mal vom anwender gesetzt und nie mehr verändert.
der daraus über die schaltzeiten berechnete verbrauch gehört in ein reading. der ändert sich ständig.
genauso ein tatsächlich gemessener verbrauch. der ghört auch in ein reading.
gruss
andre
Zitatmit addToAttrList kann ein modul neue globale attribute definieren.
Und der Benutzer erweitert "attr global userattr".
Wird von vielen Modulen wie FHEMWEB (icon/webcmd/devStateIcon/etc), structure, usw. verwendet.
ZitatUnd der Benutzer erweitert "attr global userattr".
Das macht sich sehr gut! Hat mir schon öfter den Umweg über einen Dummy erspart - in Verbindung mit der ebenfalls sehr schönen "Fehlentwicklung" userReadings. :)
Bin mir nicht sicher, ob das die ganze Problematik erfasst, aber ich hatte wegen ähnlicher Interessen meinerseits in das statistics-Modul "Dauer der Status" eingefügt. Das erfasst die Zeit, die ein bestimmter Gerätewert einen bestimmten Wert hat und könnte dann mit den jeweiligem Attribut multipliziert werden.
Hallo,
so, ein Modul EM ist im entstehen, dank Regenwetter.
Bisher vorgesehene/implementierte Features:
1. Die Attribute power-on und power-off können bei jedem device hinterlegt werden. power-on ist z.B. für eine 15 W Energiesparlampe 15, power-off wäre dann der Eigenstromverbrauch, typ. 0.5 W des Schaltaktors.
2. Jeder Schaltvorgang des devices (Trigger ist =~m/(on|ein).*/ und entsprechend off und aus)wird über ein globales notify aufgezeichnet und den daraus resultierenden Stromverbrauch errechnet.
3. Die Stromverbrauchswerte werden als reading beim device je Stunde,Tag,Monat und Jahr gesammelt. Das Rücksetzen erfolgt jeweils zu Beginn der nächsten Zeitperiode.
Das Setzen dieser Werte generiert events, die dann in ein log geschrieben werden können und für einen plot zur Verfügung stehen.
4. EM sammelt zusätzlich die Verbrauchswerte gem. der Gruppen, in denen sich die devices befinden, z.B. group = "Beleuchtung" oder "Mediaanlage".
Die Gruppenwerte gehen auch wieder in hour,day,month und year - readings.
5. Dauerverbraucher, wie z.B. Kühlschrank usw. können über dummys erfasst werden.
Dazu schliesst man temporär den Verbraucher über eine DECT200 an und setzt:
set myEM measure <Verbrauchder> <probe>
und lässt die Messung eine zeitlang laufen, um so automatisch den Mittelwert errechnen zu lassen (sinnvoll bei Kühlschrank)
mit
set myEM measure stop
wird die Messung beendet und das Attribut power-on beim <Verbraucher> gesetzt.
Soweit erst einmal der erste Ansatz.
Ich habe für die Verbrauchsmessung nur DECT200 hier, es gibt ja aber auch andere Funksteckdosen, die den aktuellen Verbrauch übertragen. Wenn diese mit integriert werden sollen, benötige ich einige Angaben dazu:
1. Type (fhem-Typ)
2. Wie heißt das reading, welches den aktuellen Verbrauchswert überträgt? (Bei der DECT200 sieht das so aus: "power: 150 W". Der EM triggert hier also auf "Power:")
3. Wie oft wird der Verbrauchswert übertragen? (bei der DECT200 1 x je Minute).
Noch Anregungen?
Gruß
Elektrolurch
anregungen und vorschläge:
- wenn die devices direkt schon den verbrauch und nicht nur die last liefern ist es vielleicht genauer diesen zu verwenden und nicht selber zu integrieren. da müsste man nur vorsehen das der wert zwischendurch auf 0 gesetzt werden kann.
- die zeit zwischen readings sollte nicht fest eingetragen werden sondern direkt aus den events abgeleitet werden
- vielleicht wäre es gut zusätzlich zu on und off auch noch dim werte auszuwerten ?
- was spricht dagegen auch wochen werte zu haben?
- wie wäre es zusätzlich zu den gruppen noch mal 'alles' werte zu haben?
- das mit den gruppen sollte auch gehen wenn ein device in mehreren gruppen ist um z.b. stockwerksweise zu gruppieren.
- wie wäre es wenn man haus oder stockwerks zähler mit den obigen gruppen 'verrechnen' kann um die nicht direkt erfasste differenz zu bekommen. also z.b. haus zähler minus alle erfassten devices oder zähler wohnzimmer minus alle im wohnzimmer erfassten devices. letzteres könnte dann z.b. alles - medienanlage = beleuchtung ergeben.
- die PCA301 und EC3000 haben power und consumption readings
ich hoffe du bist jetzt nicht erschlagen :)
gruss
andre
Zitat:
- wenn die devices direkt schon den verbrauch und nicht nur die last liefern ist es vielleicht genauer diesen zu verwenden und nicht selber zu integrieren. da müsste man nur vorsehen das der wert zwischendurch auf 0 gesetzt werden kann.
Bei der DECT200 steht der summierte Verbrauch in einem reading "energy", der scheint aber seitens der Fritzbox auch nur aufintegriert zu werden...
Da eine Änderung von "energy" kein event generiert, ist das mit dem von aussen initiierten Zurücksetzen ein Problem, da man den Zeitpunkt nicht mitbekommt.
Zitat:
- die zeit zwischen readings sollte nicht fest eingetragen werden sondern direkt aus den events abgeleitet werden
Was meinst Du damit. Ich triggere den EM auf ein|on|off|aus|power:
Um den Verbrauch je Stunde zu ermittlen, und bspw. eine Lampe, die nur an einem Aktor mit ein|aus hängt kann ja länger als eine Stunde brennen, läuft der EM einmal je Stunde und sammelt die Werte aller devices mit dem Attribut power-on ein und kumuliert sie.
Zitat:
- vielleicht wäre es gut zusätzlich zu on und off auch noch dim werte auszuwerten ?
Ja, in der Version 1.5
Zitat:
- was spricht dagegen auch wochen werte zu haben?
Eigentlich nichts. Fängt die Woche mit Sonntag oder Montag an?
Ok. Eingebaut. Und die Woche fängt mit Montag an.
Zitat:
- wie wäre es zusätzlich zu den gruppen noch mal 'alles' werte zu haben?
Ok. Eingebaut und auch die Räume habe ich noch mit eingebaut.
Kann man jetzt über Attribute use-groups und use-rooms ein- und ausschalten.
Zitat:
- das mit den gruppen sollte auch gehen wenn ein device in mehreren gruppen ist um z.b. stockwerksweise zu gruppieren.
Mit den mehreren Gruppen hatte ich nicht bedacht.....
Ist der Trenner bei mehreren Gruppen eindeutig? ',' oder ' ' oder beides? Wegen dem split auf das Attribut 'group'.
Zitat:
- wie wäre es wenn man haus oder stockwerks zähler mit den obigen gruppen 'verrechnen' kann um die nicht direkt erfasste differenz zu bekommen. also z.b. haus zähler minus alle erfassten devices oder zähler wohnzimmer minus alle im wohnzimmer erfassten devices. letzteres könnte dann z.b. alles - medienanlage = beleuchtung ergeben.
Ja. War auch das Endziel, denn ich habe leider keinen "elektrisch" auslesbaren Stromzähler und erfasse die Werte einmal monatlich per Hand und berechne die Jahresprognose.
Daher auch der Ansatz mit den dummys für Kühlschrank und anderen Verbrauchern.
Wobei die Idee im Hinterkopf war, den dummy ev. auch ein- und auszuschalten, wenn ich aus anderen 'Daten "erraten" kann, das der Verbraucher ein- oder ausgeschaltet wurde.
(z.B. Umwälzpumpe für den Heizkreis oder ein Licht mit normalen Schalter aber einem Bewegungsmelder in der Nähe + Dunkel)
Zitat:
- die PCA301 und EC3000 haben power und consumption readings
Sind das auch die exakten fhem-types?
comsuption = energy, also 'Gesamtverbrauch?
Zitat:
ich hoffe du bist jetzt nicht erschlagen :)
Na, lieber jetzt ein paar Dinge mehr berücksichtigen, als nachher das Konzept über den Haufen werfen.
Habe sowieso erst einmal zwei Wochen über das Thema nachgedacht, bevor ich eine Zeile Code gebaut habe.
Dann das Modul-Grundgeräst...
Um letzten Sonntag war dann der 'Tag der Kreativität...
Gruß
Elektrolurch
Uh das nimmt ja wirklich schon konkrete Formen an! ich bin begeistert Jungs!
Da ich Besitzer zweier DECT200 finde ich das mit dem erfassen der "echten" gemittelten Werte genial!
Die von André erwähnte Funktion die Dim Statuswerte zu erfassen finde ich auch klasse! Wenn dann wuerde es mich auch freuen, wenn wir Homematic beachten würden und demnach das äquivalente "pct" Reading.
Zur Mustererkennung: da ich einen Durchlauferhitzer habe würde ich mich über eine Funktion, ähnlich wie Threshold freuen, die erkennt ob z.B mehr als 5kw in den letzten 5 Minuten vom CUL_EM gemeldet wurden.
Ich sage jetzt schon einmal Danke fuer die super konstruktiven Vorschlaege hier im Forum und besonders an Elektrolurch fuer die Umsetzung! Ich bin wirklich begeistert was hier alles mit FHEM und Co umgesetzt werden kann! Klasse!
Hallo,
könnte man auch berücksichtigen, dass ein Verbraucher mehr Leistungsstufen als on/off hat? Meine Lüftung hat z.B 10 Stufen , welche jeweils eine charakteristische Leistung haben. Die jeweilige Leistungsstufe ist fhem bekannt, so dass man den Momentanverbrauch daraus ableiten könnte.
VG Marcus
Hallo,
Zitat:
wuerde es mich auch freuen, wenn wir Homematic beachten würden und demnach das äquivalente "pct" Reading.
wenn die nicht on/off oder ein/aus liefern, dann müsste ich schon wissen, was die tun. Das reading sagt mir garnichts.
Habe leider keine Homematik.
Einen threshold sehe ich erst mal nicht vor.Aber für die innerhalb einer Stunde gesammlten "Strom-Ereignisse" für Gruppe oder Raum kann man per Attribut einschalten, dass diese seitens EM neue Events erzeugen. Ansonsten werden diese nur stündlich beim Update der Counter für Gruppen, Räume oder 'Alle' erzeugt.
Per userreading und Differenz könnte man dann einen threshold generieren.
dim ist nicht so ganz trivial, da EM ja nur die Zustandsänderungen mitbekommt und immer erst bei Änderungen den Verbrauch berechnet, muss also 1 x Mal Historie pflegen.
Mein Ziel ist es erst einmal die beschriebene Basisfunktion fehlerfrei zum Laufen zu bekommen, ich muss ja auch nachprüfen, ob das Teil richtig rechnet.
Mein erster Test war jedenfalls schon mal positiv....
Gruß
Elektrolurch
Ich glaube hier entsteht etwas feines, deswegen hefte ich mich mal hier an...
Werden komponenten wie HUE bulbs & Stripes auch integriert? Und zum messen und mitteln der Verbrauchswerte auch andere Messteckdosen wie z.b. Homematic und PCA301 eingebaut?
@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
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.
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
- 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
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
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?
sammeln und konzept ist eine gute idee. aber nicht versuchen dann in der ersten versuon alles zu erschlagen.
Zitat von: justme1968 am 26 September 2014, 13:59:41
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!
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
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!
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
Mache dir keinen Stress! Es ist fertig wenn es fertig ist!
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
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.
BeispielappCountsPerHour 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 (http://forum.fhem.de/index.php/topic,28017.msg209074.html#msg209074)
ZitatWenn 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
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.
HourCounter ist inoffiziell.
Wiki findest du hier
http://www.fhemwiki.de/wiki/HourCounter (http://www.fhemwiki.de/wiki/HourCounter)
Die Sourcen hier
http://forum.fhem.de/index.php/topic,12216.0.html (http://forum.fhem.de/index.php/topic,12216.0.html)
John
In statistics arbeite ich mit der Rampenlösung, werte aber auch Events aus und speichere den letzten Wert in ....Last.
PS: Im statistics Modul ist auch schon das zeitliche Erfassen der Gerätezustände enthalten. Was fehlt, ist das multiplizieren mit der Leistung.
Hallo tupol,
ich habe kein Problem damit, wenn der HourCounter in statistics aufginge. Die Frage nach dem Unterschied wurde ja schön öfter gestellt. Für die User wäre es einfacher mit einem anstelle mit 2 Modulen zu arbeiten.
Gleichzeitig sollte diese Diskussion eine Hilfe für Elektrolurch sein, um den Unterschied zu erkennen.
Allerdings sehe ich nach dem ersten überfliegen hier einige Probleme:
A. Kernfunktion
Der HourCounter vermisst den zeitlichen Abstand zwischen 2 beliebigen Ereignissen und zwar sowohl die EIN-, wie die AUS- Zeiten.
Da er nicht eindeutig einem Device zugeordnet werden kann, ist der Container für die Readings die Instanz vom Hourcounter selbst.
Die Repräsentation dieser Readings ist einfach verarbeitbar in weiterführenden UserReadings, da diese als einfache Zahlen vorliegen (z.B. um über die Einschaltzeit den Energieverbrauch zu bestimmen).
Beispiel: (Einheit in Sekunden)
pulseTimeIncrement 359 2014-10-18 11:52:05
pulseTimeOverall 6634186 2014-10-18 11:52:05
pulseTimePerDay 7400 2014-10-18 11:52:05
...
pauseTime...
Ist das mit Statistics möglich ?
B. Beliebige Events
Der HourCounter ist nicht an bestimmte vordefinierte Readings gebunden. Diese können analog zu notify frei festgelegt werden.
Hat hier Statistics Einschränkungen ?
(es ist mir nicht gelungen das onoff Ereignis meines Max-Fensterkontaktes einzubinden, aber vielleicht verstehe ich noch nicht alles)
John
Statistics misst bei Geräten ohne Messwerten die Dauer des "State". Dass sollte dann auch beim MAX Fenster-Kontakt gehen. Habe aber keinen zum Testen.
Edit: Habe gerade meinen Fehler entdeckt. Der HourCounter ist ja was ganz anderes als statistics. Es geht ja da um Anzahl/Zeiteinheit. Statistics macht nur Statistiken. D.h. es könnte z.B. den Messwert von HourCounter weiter verarbeiten. Mein Hinweis auf statistics ging auch in Richtung Energiemessung, nicht in Richtung Ersatz hourCounter.
Gruß
tupol
Ok.
Die Fortschreibung der Werte über die verschiedenen Zeiteinheiten steckt eh nur in einer Funktion. Habe das jetzt zweigleisig gemacht, d.h. "Rampe" für die laufende Zeiteinheit und jeweils ein reading, was die Werte der letzten Zeiteinheit behinhaltet, z.B.:
Beleuchtung-power-daily und Beleuchtung-power-daily-last
EM sammelt die Werte je device, summiert in total auf und je nach dem, ob das device ein group und/oder room-Attribut hat noch summarisch in group oder room.
Gruß
Elektrolurch
Hallo,
nach einigen Wochen Tests ist jetzt die Beta von
"Neues Modul EM - EnergieMonitor" fertig und hier zu finden:
http://forum.fhem.de/index.php/topic,30055.0.html
Gruß
Elektrolurch