[OBIS V2] - Jetzt auch mit SML-Unterstützung

[Icinger]

Hi Folks,

Ab sofort unterstützt 47_OBIS auch den SML-Standard.
Da SML ja nichts anderes als codierte OBIS-Meldungen sind, habe ich gemeinsam mit matzefisi das SMLUSB mit meinem OBIS verschmolzen.

Somit sollten jetzt ziemlich viele Smartmeter, die über USB, RS232, RS485 und sonstiges ausgelesen werden, mit einem Modul erreicht.

Die Grundfunktionalität ist gelich geblieben, neu ist hinzugekommen:

1) MeterType: SML
Wie der Name schon sagt, werden hiermit SML-Meter ausgelesen.
Die SMLDaten werden ins OBIS-Format konvertiert und als Readings bereitgestellt.
zB:

Code: [Auswählen]

define MyObis OBIS /dev/ttyVoltcraft@9600,7,E,1 SML
2) Attribut unitReadings
Wer es unbedingt will, kann hiermit an die Readings die passenden Units anhängen

Das Update bekommt ihr ab morgen früh mittels FHEM-Update automatisch.

Danke nochmal an matzefisi und immi fürs Testen, Tips und die allgemeine Unterstützung.

Für zusätzliche Wünsche, Anregungen, Beschwerden uns sonstiges bin ich natürlich jederzeit für euch erreichbar.

lg, Stefan

[Icinger]

So, da ich gestern Abend wenig Zeit hatte, hier nochmal ein paar weitere Infos zum Modul:

1) Define:

Code: [Auswählen]

define myObis OBIS <schnittstelle> <metertyp>Metertyp kann hier sein:
VSM102 -> Voltcraft VSM102
Dieser Meter (und manche andere) senden nicht automatisch ihre Daten, sondern brauchen erst eine Anfrage vom Programm.
Soweit ich bisher gesehen habe, ist diese Anfrage bei vielen gleich, also kann das VSM102 evtl. auch bei anderen Metern genutzt werden.

Standard -> Plain OBIS
Für Smartmeter, die ihre Daten als reine OBIS-Meldungen ohne auffroderung senden.

SML -> SML-codierte OBIS-Daten
Wie der Name schon sagt Mit diesem Metertyp wird das SMLUSB-Modul ersetzt.

2) Attribute:
interval
Das Interval in Sekunden, in denen die Daten vom Smartmeter abgerufen werden.
Wird einerseits benutzt beim VSM102-Typ, wo die Daten ja abgerufen werden müssen.
Andererseits auch in Kombination mit dem Polling-Mode (siehe unten) interessant.

offset_feed
offset_energy
Hiermit kann der Gesamt-Zählerstand um den angegebenen Wert angepasst werden.
Mein Zähler hängt zB hinter dem Ferraris-Zähler meines Stromversorgers.
Damit kann ich meinen Zähler an den offiziellen Zählerstand anpassen.

channels
Wenn man die Channel-Readings umbenennen will, oder einen Channel hat, der vom Modul nicht abgedeckt wird,
kann hiermit ein Perl-Array angegeben werden, welches zusätzlich zu den Internen Zuordnungen durchsucht wird.
zB:

Code: [Auswählen]

attr myObis channels {"21"=>"energy_L1","41"=>"energy_L2","61"=>"energy_L3","31"=>"power_L1","51"=>"power_L2","71"=>"power_L3","1"=>"energy_current","1.8"=>"energy_total","2.8"=>"feed_total"}
directions
Manche Zähler senden die Stromrichtung (von / zum) EVU in einem Statusbyte mit.
Dies ergibt dann zusätzliche Readings:

Code: [Auswählen]

     2016-04-08 19:41:54   dir_total_consumption in
     2016-04-08 19:41:45   dir_total_feed  out
"in/out" sind hier als Standard vorgegeben, können aber mit diesem Attribut geändert werden.
zB:

Code: [Auswählen]

{"<"=>"←",">"=>"→"}um die Richtung als Pfeile zu erhalten (← / →)

alignTime
Nur in Kombination mit interval nutzbringend.
Mit diesem Attribut wird das Interval auf die hier angegebene Zeit angepasst.
Selbe funktionalität wie beim at.
Bei einem interval von 600 (=10 Minuten) und aligbTime von "00:00:00" wird immer um hh:00:00, hh:10:00, hh:20:00 usw. abgerufen.

pollingMode
Da es bei Metern, die ihre Daten im Sekundentakt senden, teilweise zu erhöhter CPU-Last kommt, kann hiermit auf den FHEM-internen Polling-Mechanismus umgeschaltet werden.
Hierbei werden die Daten nicht mehr Event-basiert abgerufen, sondern nur mehr ca. alle 5 Sekunden.
Nachteil: Damit kann sich evtl. eine leichte Verzögerung im Abrufen der Daten ergeben.

So, hoffe mal, das war ein wenig Informativ

Schönes Wochenende euch allen,

Stefan

[KölnSolar]

Hi Stefan, da musste ich natürlich sofort aktualisieren, um zu testen,ob dann auch die bekannten kleineren Fehler bereinigt sind. Sind sie ! Danke !

Läuft für ASCII-OBIS fast wie gehabt, lediglich an den Readings zu current und power hat sich etwas unschön verändert: Wie vom device gelesen, werden nun führende Nullen angezeigt, by power(channels x1) auch das ggfs. vorhandene + Vorzeichen
Schönes Wochenende
Markus

[Icinger]

Hi Markus,

danke für die Meldung.
Sollte beides mit dem Fix von morgen früh beseitigt sein (oder du holsts dir gleich aus dem SVN).

lg, Stefan

[KölnSolar]

prima. geht.
macht das automatische setzen von event-on-change-reading beim define eigentlich Sinn ? Ich lösch es nach jedem Restart wieder, da ich nur die Leistung logge.
Grüße Markus

[Icinger]

Bei jenen, deren Meter in Sekundentakt die Daten senden macht das durchaus Sinn.

Und bei allen anderen dürfte es mMn nicht wirklich zu Nebeneffekten führen (Ausser, du willst zB auch im Minutentakt die Daten loggen, obwohl sie sich nicht ändern)

War ein User-Wunsch, kann ich gerne auch wieder entfernen, wenns wem stört.

[KölnSolar]

dafür hast Du doch pollingMode und interval eingebaut ;-)
ich verstehe Attribute als Mittel zur individuellen Konfiguration und es ist doch eher unüblich die per Modul zu setzen. In meinem Fall brauche ich das event als trigger für mein userreading, welches sich möglicherweise verändert: die Zählerleistung ist zwar unverändert aber Erzeugung und Verbrauch haben sich möglicherweise geändert.
Ich fänds ohne besser. Warte mal noch andere Meinungen ab.
Grüße Markus

[immi]

Hi Markus
mea culpa
ich habe event-on-change-reading vorgeschlagen.
Ich habe an newbie gedacht:

Code: [Auswählen]

define xxx obis /dev/usb
define xxxlog filelog log.txt xxxDamit werden mehrere GB data pro Tag generiert, bei Meeter die in Sekundentakt arbeiten
...aber Publickey bleibt immer gleich, Version auch....
deswegen event-on-change-reading "by default" macht  sinn für newbie.

Erfahrene FHEM Users können immer folgende Behfel in fhem.cfg eintragen

Code: [Auswählen]

define xxx obis /dev/usb
deleteattr xxx event-on-change-reading
Hi Stefan
other topic
by next bugfix, if you want, you can add a hint in the obis-reference-manual.
47_obis works out-of-the.box well also over a ser2net connection
e.g.

Code: [Auswählen]

define myPowerMeter OBIS 10.0.1.13:1234
it is quite usefull if your fhem server is far away from the powermeeter.
as you know my ser2net hardware is just a cheap esp8266 (every other hardware with ser2net is fine)
immi

[KölnSolar]

Hi Immi,
verstehe ich. Owner, Serial, Status und Version(publickey gibt es bei mir nicht) sollten aber schon modulintern seit einiger Zeit nicht wiederholt zu einem Event führen.

@Stefan: Komischerweise habe ich gerade festgestellt, dass dies in der aktuellen Version aber nur für "Version" gilt ?

Macht es dann nicht mehr Sinn, die Attribute pollingMode=on und interval=60 zu setzen ? Damit wären doch die newbies noch mehr vor Datenmüll geschützt und die Systeme sind auch automatisch performanter.

@Stefan: mir ist noch ein kleines Fehlerchen aufgefallen. Bei Definition ohne metertype wurde bei mir der metertype "SML" anstatt "Standard" vorbesetzt.

Grüße
Markus

[tenya]

Hallo,
vielen Dank für das Modul kam genau passend zu meinem IR Lesekopf.
Nun wird bei meinem Hager Zweiwegezähler im Reading Power bei Bezug die korrekte Bezugsleistung in Watt angezeigt. Bei Einspeisung jedoch nicht - kann ich das irgendwie umrechnen?

[Icinger]

Hmm, komisch, dürfte eigentlich nicht sein.
Inwieweit ist der Wert falsch?
Du könntest ihn zB mit einem Userreading umrechnen.

Besser wärs aber, du schickst mir mal nen kompletten Datensatz, wie er vom Lesekopf kommt, dann schau ich, wo da der Fehler liegt.

@Markus:

Bei Definition ohne metertype wurde bei mir der metertype "SML" anstatt "Standard" vorbesetzt.

Eigentlich sollte der Metertyp automatisch auf den richtigen Wert gesetzt werden (SML oder Standard, je nachdem, in welchem Format die Daten kommen)
Werd ich mir auch nochmal ansehen.

Und die automatisch gesetzten Attribute lass ich ganz fallen.
Ich denke, ein User, der das OBIS definiert, sollte mündig genug sein um zu wissen, waelche Attribute er setzen soll/muss.

Die Korrekturen bekommt ihr spätestens am Donnerstag per Update geliefert.

lg, Stefan

[KölnSolar]

hab mir die Werte von tenya mal angesehen. demnach ein 2-tarif-2-richtungszähler ? stimmen die werte mit der anzeige am Zähler überein ? mir kommt die glatt 1000 in beiden Richtungen in Tarif2 arg komisch vor.
@Stefan kann es sein, dass bei Einspeisung ein minus-zeichen nicht oder falsch interpretiert wird ? 64 kW macht die Anlage sicherlich nicht oder ich würd schon mal die Feuerwehr in Rufbereitschaft versetzen ;-)
@tenya mach doch mal ne messreihe, nee besser, wir haben ja fhem, log doch mal den power-wert, dann sieht man schön den Wechsel von Bezug zu Einspeisung
Grüße Markus

[Icinger]

64 kW macht die Anlage sicherlich nicht

Vielleicht will er seinen privaten Atommeiler loggen? **scnr**

THEORETISCH dürfte das nicht falsch berechnet werden, ich rechne mir den Wret und den Scaler genau nach den offiziellen Richtlinien aus.
TATSÄCHLICH wird er scheinbar schon falsch berechnet.

Daher auch die Bitte nach einem kompletten Frame

[willybauss]

64841 Watt klingt verdächtig nach 2¹⁶ - 695 , also 695 Watt Einspeisung. Läuft da ne Variable über?

[Omega-5]

64841 Watt klingt verdächtig nach 2¹⁶ - 695 , also 695 Watt Einspeisung. Läuft da ne Variable über?

Oder signed / unsigned ?  -695W

Gruß Friedrich