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

Begonnen von Icinger, 08 April 2016, 19:54:44

Vorheriges Thema - Nächstes Thema

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:
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
Verwende deine Zeit nicht mit Erklärungen. Die Menschen hören (lesen) nur, was sie hören (lesen) wollen. (c) Paulo Coelho

Icinger

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

1) Define:
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: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:
     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:
{"<"=>"←",">"=>"→"}
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
Verwende deine Zeit nicht mit Erklärungen. Die Menschen hören (lesen) nur, was sie hören (lesen) wollen. (c) Paulo Coelho

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
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

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
Verwende deine Zeit nicht mit Erklärungen. Die Menschen hören (lesen) nur, was sie hören (lesen) wollen. (c) Paulo Coelho

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
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

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.
Verwende deine Zeit nicht mit Erklärungen. Die Menschen hören (lesen) nur, was sie hören (lesen) wollen. (c) Paulo Coelho

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
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

immi

Hi Markus
mea culpa
ich habe event-on-change-reading vorgeschlagen.
Ich habe an newbie gedacht:
define xxx obis /dev/usb
define xxxlog filelog log.txt xxx

Damit 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
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.
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

RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

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:
ZitatBei 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
Verwende deine Zeit nicht mit Erklärungen. Die Menschen hören (lesen) nur, was sie hören (lesen) wollen. (c) Paulo Coelho

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
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

Icinger

Zitat64 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 8)
Verwende deine Zeit nicht mit Erklärungen. Die Menschen hören (lesen) nur, was sie hören (lesen) wollen. (c) Paulo Coelho

willybauss

64841 Watt klingt verdächtig nach 216 - 695 , also 695 Watt Einspeisung. Läuft da ne Variable über?
FHEM auf Raspberry Pi B und 2B; THZ (THZ-303SOL), CUL_HM, TCM-EnOcean, SamsungTV, JSONMETER, SYSMON, OBIS, STATISTICS

Omega-5

Zitat von: willybauss am 17 April 2016, 10:36:40
64841 Watt klingt verdächtig nach 216 - 695 , also 695 Watt Einspeisung. Läuft da ne Variable über?

Oder signed / unsigned ?  -695W

Gruß Friedrich
RaspberryPi2, nanoCUL, 3x DS18B20, FS20: 4x Funk-Schalter ST-4, LaCrosseGW,
HomeMatic: HMLAN, HM-WDS10-TH-O, HM_MYS_RelaisBoard,
I2C: HYT221 über modifiziertes Modul I2_I2C_SHT21.pm (Q&D),