Neues Modul: Easymeter (ersetzt durch 47_OBIS)

[willybauss]

Das o.g. Problem hat sich mit einem Update gelöst. Danke nochmal an Stefan, der sich wirklich viel Zeit für mich genommen hat.

Ich möchte nun die Lösung vorstellen, die ich mit ihm zusammen erarbeitet habe.

Problem:
Mein Zähler gibt mir keine Leistungswerte, sondern nur Zählerstände, also z.B.

Code Auswählen Erweitern


2016-02-13 19:48:31 OBIS Hausstrom_Zaehler Version: EMH5----eHZ-E0028E
2016-02-13 19:48:31 OBIS Hausstrom_Zaehler Owner: 20836181
2016-02-13 19:48:31 OBIS Hausstrom_Zaehler energy_total: 11561.3388
2016-02-13 19:48:31 OBIS Hausstrom_Zaehler feed_total: 33053.4175
2016-02-13 19:48:31 OBIS Hausstrom_Zaehler Status: 82
2016-02-13 19:48:31 OBIS Hausstrom_Zaehler Serial: 0002477555


Die Lösung, um dennoch an Leistungswerte zu kommen, liegt in userReadings mit dem Modifier differential:

das Reading wird auf die Differenz zw. dem aktuellen und dem vorherigen Wert, geteilt durch die Sekunden zw. der aktuellen Zeit und der letzten Auswertung, sekundengenau.

Das Ergebnis wird noch mit 3600000 multipliziert und man erhält die momentane Leistung in Watt - dummerweise mit 13 Nachkommastellen, die durch die Differential-Berechnung verursacht werden. Deshalb wird ein weiteres userReading nachgeschaltet, das die Nachkommastellen abschneidet. Für Verbrauch und Einspeisung (PV-Anlage) sieht das dann so aus:

attr Hausstrom_Zaehler userReadings P_Bezug_temp:energy_total differential { ReadingsVal("Hausstrom_Zaehler","energy_total",0)*3600000 }, P_Einsp_temp:feed_total differential { ReadingsVal("Hausstrom_Zaehler","feed_total",0)*3600000 },  P_Bezug_Watt { sprintf("%.0f",ReadingsVal("Hausstrom_Zaehler","P_Bezug_temp",0)) },  P_Einsp_Watt { sprintf("%.0f",ReadingsVal("Hausstrom_Zaehler","P_Einsp_temp",0)) }

Im Logfile landen dann nur die Endwerte durch

Code Auswählen Erweitern

define FileLog_Hausstrom_Zaehler FileLog /mnt/fhem/log/Hausstrom_Zaehler-%Y-%m.log Hausstrom_Zaehler:P.*Watt.*



Logfile:

Code Auswählen Erweitern



2016-02-13_20:05:28 Hausstrom_Zaehler P_Bezug_Watt: 286
2016-02-13_20:05:28 Hausstrom_Zaehler P_Einsp_Watt: 0



Nachtrag:
Statistische Werte erhalte ich mit dem statistics-Modul:

Code Auswählen Erweitern


define Hausstrom_Zaehlerstand statistics Hausstrom_Zaehler
attr Hausstrom_Zaehlerstand ignoreDefaultAssignments 1
attr Hausstrom_Zaehlerstand minAvgMaxReadings energy_total,feed_total
attr Hausstrom_Zaehlerstand room Stromzaehler
attr Hausstrom_Zaehlerstand singularReadings Hausstrom_Zaehler:energy_total:Max:(Day|Month|Year)|Hausstrom_Zaehler:feed_total:Max:(Day|Month|Year)


Wenn es aber nur um die Monatswerte der Zählerstände geht genügt auch einfach

Code Auswählen Erweitern


define GetZaehlerstand_Verbrauch_Month at *00:00:01 IF ($mday == 1) ( setreading Hausstrom_Zaehler Zaehlerstand_Verbrauch [Hausstrom_Zaehler:energy_total] )
attr GetZaehlerstand_Verbrauch_Month room Stromzaehler
define GetZaehlerstand_Einspeis_Month at *00:00:01 IF ($mday == 1) ( setreading Hausstrom_Zaehler Zaehlerstand_Einspeis [Hausstrom_Zaehler:energy_feed] )
attr GetZaehlerstand_Einspeis_Month room Stromzaehler

[Markus Bloch]

Hallo icinger,

ich habe gerade im SVN gesehen, dass du dein neues Modul 47_OBIS.pm eingecheckt hast. Beim Durchsehen sind mir dabei ein paar Sachen aufgefallen, die dir mitgeben möchte.

Du benutzt die Log3-Funktion wiefolgt:

Code Auswählen Erweitern

Log3 $hash,4,"Baudrate is $baudrate";

Im FHEM Log kann man später so aber nicht mehr erkennen, welches Modul denn diese Meldung erzeugt hat. Ich empfehle daher immer den Modulname, sowie den Name der Definition mit einzufügen. Bspw:

Code Auswählen Erweitern

Log3 $hash,4,"OBIS ($name) - Baudrate is $baudrate";

Man sollte möglichst auf globale Variablen verzichten:

Code Auswählen Erweitern

my $buffer = "";
my $Zeit = 0;
my $speed=0;
my %channels = ( "21"=>"energy_L1",
                 "41"=>"energy_L2",
                 "61"=>"energy_L3",
                 "32"=>"voltage_L1",
                 "52"=>"voltage_L2",
                 "72"=>"voltage_L3",
                 "31"=>"power_L1",
                 "51"=>"power_L2",
                 "71"=>"power_L3",
                 "2"=>"feed_L1",
                 "4"=>"feed_L2",
                 "6"=>"feed_L3",
                 "1"=>"energy_current");

my %devices ;

Du benutzt zum Beispiel die globale Variable $buffer um eingehende Daten zu puffern. Das funktioniert aber nur, solange man nur eine OBIS Definition in FHEM benutzt und nicht weitere. Desweiteren kann man nie sicher sein, dass evtl. ein anderes Modul ebenfalls eine globale Variable $buffer nutzt. Im Fall von $buffer rate ich dir die Zeile "my $buffer = "";" zu löschen und im restlichen Code $buffer durch $hash->{helper}{BUFFER} zu ersetzen. Damit ist der Buffer für das jeweilige Gerät direkt im Gerätehash angesiedelt und kommt sich mit anderen OBIS-Definitionen nicht ins Gehege.

Die Variable $Zeit wird im gesamten Code nicht verwendet. Die Variable $speed ist ebenfalls Definitionsspezifisch und sollte ähnlich wie $buffer nach $hash->{helper}{SPEED} wandern.

Alle Variablen die unter $hash->{helper}... angesiedelt sind, werden in der FHEMWEB-Oberfläche auf der Detailseite zwar nicht angezeigt. Wenn man aber ein "list <NAME>" eingibt, sieht man diese dennoch. Dort sollte man interne Hilfsvariablen ansiedeln die für dich als Entwickler wichtig sind, für den Nutzer aber eher uninteressant.

Die Variable %channels kann durchaus als globale Variable belassen, man sollte aber den Modulnamen als Präfix davorschreiben, damit diese Variable nicht durch andere Module evtl. auch benutzt wird und sich dann Überschneidungen ergeben. Ich würde daher vorschlagen die Variable %channels umzubenennen in %OBIS_channels.

Die Variable %devices würde ich ebenfalls versuchen zu vermeiden. Evtl. durch einmaligem bilden des Hashs in der DefineFn und abspeichern unter $hash->{helper}... oder man bildet einmalig den Request-String und speichert sich den in $hash->{helper} ab.

Am Schluss von deinem Perl-Code kommt bei dir eine Zeile:

Code Auswählen Erweitern

"Cogito, ergo sum.";

Die solltest du besser ändern in:

Code Auswählen Erweitern

1;

Macht im Ergebnis zwar kein Unterschied, so ist es aber gleich mit allen anderen Modulen, falls sich am Modul-Lademechanismus etwas ändern sollte, hätte dein Modul dann ein Problem.

So wie ich das momentan sehe, benötigst du keine InitFn, da du keinerlei Initialisierung in deiner InitFn durchführst. Du könntest also in der DefineFn dein Device mit DevIo_OpenDev($hash, 0, undef);
öffnen und die InitFn entsorgen.

Ich kann dir gerne wenn du magst als Hilfe zur Seite stehen bei allgemeinen Fragen zur Modulentwicklung.

Viele Grüße

Markus

[Icinger]

Hi Markus,

danke für die Tips, werd ich doch gleich nochmal schnell ändern

lg, Stefan

[Norbert_G]

Hallo Allerseits,

ist es eigentlich auch denkbar, einen HM-ES-TX-WM für die Messwerterfassung einzusetzen?

[Icinger]

Beim HM-ES-TX-WM bekommst du doch sowieso ein reading mit den Powerwerten?!? (zumindest laut FHEM-WIKI)

Code Auswählen Erweitern

Event     |Beispielswert
battery*  |ok
energy    |10186.6
power     |283
current   |0
voltage   |0
frequency |50
eState    |E: 10186.6 P: 283 I: 0 U: 0 f: 50
boot      |off

Da brauchst du kein OBIS-Modul mehr dazu.

lg, Stefan

[FunkOdyssey]

Könnte man das Eingangsposting evtl. ein wenig überarbeiten und darauf hinweisen, dass "47_OBIS.pm" nun offiziell in FHEM vorhanden ist. Und das OBIS quasi der Nachfolger von Easymeter.pm ist? Das waren zwar nur drei Seiten, die man lesen muss. Aber beim ersten Kontakt mit diesem Thread war es ein wenig verwirrend für mich und vielleicht auch für andere.



Hat jemand Lust mal ein Foto von der Hardware reinzustellen? Ich kann mir das irgendwie noch nicht vorstellen. Das wäre wirklich nett.

Wie fixiert ihr das Ganze am Easymeter?

[Norbert_G]

Ich habe aber bedauerlicherweise keine ordentlichen Daten bei Einsatz des HM-ES-TX-WM. Mein Easymeter liefert scheinbar auch keine n-Impulse pro kWh. Es werden irgendwelche anderen Werte ausgegeben, die sich nicht sinnvoll darstellen(lassen). Laut Aussage meines Energieversorgers handelt es sich um direkte Ausgaben der Zählerstände.

Ich bin da derzeit ein wenig ratlos.

Vielleicht gibt es ja einen Ansatz, mit dem ich an vernünftige Daten kommen kann. Ich bin für jeden Hinweis dankbar.

[CoolTux]

Ich habe auch den HM-ES-TX-WM zusammen mit den Ferrariezähler. Alle Angaben bezüglich Verbrauch sind in W/h angegeben. Wo genau liegt Dein Problem? Wenn Du lieber eine Angabe in kW/h haben willst musst Du nur ein Userreading anlegen.



Grüße

[willybauss]

Hat jemand Lust mal ein Foto von der Hardware reinzustellen? Ich kann mir das irgendwie noch nicht vorstellen. Das wäre wirklich nett.

Wie fixiert ihr das Ganze am Easymeter?

Die Hardware (Lesekopf) ist hier ganz gut zu sehen, bis auf die Tatsache, dass es in dem Bericht um einen SML-Zähler geht, mit dem das OBIS-Modul nichts anfangen kann. Im Lesekopf ist ein Magnet eingebaut, der ihn am Zähler festhält. Das ist in der Spec solcher Zähler auch ausdrücklich so beschrieben, also erlaubt.

[FunkOdyssey]

Ich ging bis gerade davon aus, dass das IR Signal von oben abgenommen wird.
Ich habe hier etwas gefunden: http://www.forum-raspberrypi.de/Thread-haus-stromzaehler-easymeter-q3da-auslesen-und-in-datenbank-speichern
Ist das nicht der hier gewählte Weg?

[Crawler]

Funk Odyssey genauso habe ich es bei mir gemacht wie in deinem Link
Ich werde mal ein Bild von meinem mit reinstellen

[willybauss]

Ich ging bis gerade davon aus, dass das IR Signal von oben abgenommen wird.

Ich gehe davon aus, dass das IR-Signal bei jedem Zähler da abgenommen wird, wo die IR-LED sitzt und raus sendet. Bei mir ist das eben vorne, bei dem Zähler in Deinem Bild ist es oben.

[FunkOdyssey]

Sorry, aber ich habe vorne und oben eine LED. Nachdem was ich beim schnellen Recherchieren lesen konnte, sind die Daten anscheinend unterschiedliche. Wenigstens was das OBIS-Modul angehen soll.
Aber wenn es bei dir so funktioniert, dann ist es doch auch perfekt.
Ich habe noch keine Praxiserfahrung. Daher frage ich ja.

[willybauss]

Es gibt das Interface mit 2 Öffnungen, das bei mir vorne ist. Hier werden die Daten in D0 (Klarschrift) oder SML (binär verschlüsselt)  gesendet. Je nach Zähler kann diese Schnittstelle unidirektional (=> Zähler sendet pausenlos von sich aus) oder bidirektional (Zähler sendet nur nach Aufforderung) sein. Nur für die bidirektionale Variante braucht man die 2. Öffnung, die dann einen IR-Empfänger beherbergt. Sobald an diesem IR-Empfänger das richtige Signal (Datenanforderung) ankommt, antwortet er. Für die unidirektionale Variante braucht man nur 1 Öffnung, die 2. ist funktionslos.

Und dann gibt es noch eine LED (bei mir rot, bei mir ebenfalls vorne), die im Rythmus des Stromverbrauchs blinkt, z.B. 10000 mal pro kWh. Auch diese kann man auswerten, aber da kommt halt kein Text oder Daten raus, sondern nur rote Lichtimpulse, die man zählt, um den Stromverbrauch zu ermitteln. Diese Methode funktioniert nicht bei Zweirichtungszählern, weil man die Stromrichtung nicht am blinken erkennen kann => keine Unterscheidung zwischen Verbrauch und Einspeisung.


Nachtrag:
Und dann gibt es an der Zählerrückseite, für den Benutzer unzugänglich (verplombt), noch eine weitere SML-Schnittstelle, über die der Netzversorger den Zähler konfigurieren könnte, z.B. Tarif, Firmwareupdate usw. Auch da sollen lt. Datenblatt meines Zählers OBIS-Daten in D0 oder SML raus kommen.

[FunkOdyssey]

Danke für die Erklärung.
Ich hatte vermutet, dass du an der blinkenden roten LED deine Messungen durchführst. Das hatte mich verwundert. Mir war nicht klar, dass du beide Varianten vorne hast. Mea culpa.