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

[Icinger]

Hi Tanya,

hab mir das jetzt nochmal angeschaut.
Die Readings stimmen genau mit den Werten überein, die ich aus deinen Daten herausbekommen:

zB Daten für reading "total_feed":

Code: [Auswählen]

77 07 01 00 02 08 00 FF -> 62A2 01 621E 52FF 5513F00BEB 01
Leerschritte und "->" habe ich mal eingefügt.
Übersetzt lt. OBIS-Standard heisst das:
77 -> Start eines Eintrags
07 -> (T/L-Feld) Länge 7 Bytes ( =dieses und 6 folgende)
01 00 02 08 00 FF -> Die Obis-Adresse (=1-0:2.8.0*255)

Dann kommt zuerst ein Status-Byte:
62 -> (T/L-Feld) Typ unsigned, Länge 2 Bytes ( =dieses und 1 folgendes)
A2 -> Richtung ("in" oder "out")

Dann kommt ein "Time"-field, das nicht benutzt wird:
01 -> (T/L-Feld) Typ String, Länge 1 Bytes ( =dieses und KEIN folgendes)

Dann kommt die Einheit:
62 -> (T/L-Feld) Typ unsigned, Länge 2 Bytes ( =dieses und 1 folgendes)
1E -> Watt-Stunden

Dann kommt der Scaler, der wird später mit dem Wert multipliziert
52 -> (T/L-Feld) Typ signed Integer,  Länge 2 Bytes ( =dieses und 1 folgendes)
FF -> gibt -1, also Richtung "out"
Oh, da hatte ich noch nen Fehler bei der Berechnung vom Scaler, Komma war um eine Stele verschoben.

Jetzt fehlt nur noch der Wert:
55 -> (T/L-Feld) Typ signed Int32,  Länge 5 Bytes ( =dieses und 4 folgendes)
13F00BEB -> ergibt umgerechnet 334498795

01 -> Kennzeichnet das Ende des Frames.

334498795 * Scaler von vorhin (255 = -1) gibt dann -334498795 Wh

Der Wert würde soweit also stimmen, wenn ich nicht nen krassen Denkfehler irgendwo habe, oder?

lg, Stefan

[tenya]

Hi Stefan,

Es stimmen auch alle Werte außer dem Power Wert während der Einspeisung. Bei Bezug stimmt der Wert dagegen.

[Icinger]

Sorry, Fehler gefunden, so sollte es jetzt passen

Code: [Auswählen]

    2016-04-21 14:01:19   ManufID         HAG
     2016-04-21 14:01:19   PublicKey       5A35-0882-EC00-4172-55E4-7368-C5BA-68EC-2009-2246-1CAF-EA58-F778-1768-E5D1-8
FBE-2AD1-CD76-1307-D488-B1B5-60C8-46B1-1326-01
     2016-04-21 10:09:00   Status          386
     2016-04-21 10:09:39   Version         HAG\06-48-41-47-01-04-C5-37-63-3F
     2016-04-21 14:01:19   dir_total_consumption out
     2016-04-21 14:01:19   dir_total_feed  out
     2016-04-21 14:01:19   power           -3194
     2016-04-21 10:09:00   power_L1        1
     2016-04-21 10:09:00   power_L2        137
     2016-04-21 10:09:00   power_L3        1
     2016-03-28 18:25:07   state           disconnected
     2016-04-21 14:01:19   total_consumption 8964784.3
     2016-04-21 14:01:19   total_consumption_Ch1 8963784.3
     2016-04-21 14:01:19   total_consumption_Ch2 1000
     2016-04-21 14:01:19   total_feed      33449879.5
     2016-04-21 14:01:19   total_feed_Ch1  33448879.5
     2016-04-21 14:01:19   total_feed_Ch2  1000

Ich checke heute abend ein Update dazu ein.

[Omega-5]

Dann kommt der Scaler, der wird später mit dem Wert multipliziert
52 -> (T/L-Feld) Typ signed Integer,  Länge 2 Bytes ( =dieses und 1 folgendes)
FF -> gibt -1, also Richtung "out"
Oh, da hatte ich noch nen Fehler bei der Berechnung vom Scaler, Komma war um eine Stele verschoben.

Hallo Stefan,

die Interpretation des scalers ist so nicht richtig. Ich habe nochmal in die Beschreibung des SML-Datenprotokolls geschaut.
Der Wert von scaler gibt den Exponenten zur Basis 10 an, er ist immer positiv.
52 FF --> scaler (int8) -1 = *10^-1 = /10

Es gibt auch die Möglichkeit das der scaler weitere Werte annimmt.

Code: [Auswählen]

52FD = 10^-3 (x0,001)
52FE = 10^-2 (x0,01)
52FF = 10^-1 (x0,1)
5200 = 10^0 (x1)
5201 = 10^1 (x10)
5202 = 10^2 (x100)
Die Richtung wird nur durch das Statusbyte angegeben.

Gruß Friedrich

[Icinger]

Hallo Friedrich,

ja, so hab ich sie eh berechnet:

Code: [Auswählen]

10**unpack("c", pack("C", hex($scaler)))
lg, Stefan

PS: Update ist grade commited worden.

[KölnSolar]

Hi Stefan,
nach Update startet fhem nicht mehr

Undefined subroutine &main::OBIS_Set called at fhem.pl line 3163.

Zeile 73 war in der vorherigen Version auskommentiert. Wieder kommentiert, läufts.
Ich bin aber beim Reload(bei mir ohne metertype definiert) und nachfolgendes modify wieder auf den Bug gestoßen, dass SML vorbesetzt wurde. Schnell ein modify mit metertype=Standard und alles war gut. Außerdem funktioniert nach einem reload bzw. modify der pollingMode nicht mehr, zumindest steigt die CPU-Last danach wieder deutlich an. pollingMode abgeschaltet und wieder eingeschaltet und dann läuft es wieder wie es soll.
Schönes Wochenende Markus
Edit: Irrtum bzgl. pollingMode: der Zähler lief gar nicht mehr: Ich kann machen was ich will, aber pollingMode will nur nach Restart 

[tenya]

Jup musst die Zeile auch auskommentieren. Dafür wird jetzt die Momentanpower angezeigt :-)
-430W für gerade abgelesen Einspeisung.

[Icinger]

Undefined subroutine &main::OBIS_Set called at fhem.pl line 3163.

Sorry, mein Fehler, hab zum Testen diverser SML-Daten eine OBIS_Set in einer externen Datei liegen.
Hab vergessen, das beim release auszukommentieren.

lg, Stefan

[rretsiem]

Hallo,

Nachdem ich seit heute ebenfalls einen USB Lesekopf vom volkszaehler.org Projekt besitze und diesen montiert habe, komme ich mit dem OBIS Modul irgendwie noch nicht so klar.
Also Auslesen geht schon einmal, aber außer "power" wird bei mir nichts ausgelesen. Der Wert von Power als momentane Leistung scheint plausibel.

Ich vermute ich muss irgendwas mit den "channels" attribute "mappen", aber ich habe keine Ahnung wie diese Channels denn überhaupt definiert sind, die Beispiele hier im Thread sagen ja z.B. 71=>power_L3, aber wo sehe ich denn den Kanal 71?

Ist ein EMH Zähler: http://www.emh-metering.com/de/produkte/ehz-i/ der laut Beschreibung das SML Protokoll spricht.

[KölnSolar]

nein, an den channels liegt es nicht. die dienen nur der anwenderspezifischen Bezeichnung der readings.
Du liest die SML-Schnittstelle(Infrarot) und nicht die D0(LED-Impulse) ? Vermutlich SML, sonst hättest Du ja kein power.
Hattest Du denn mit anderer Software mehr Daten ?
mach mal bitte ein list devicename und poste das Ergebnis
@Stefan: im Datenblatt steht, dass die Kiste pushed. Könnte das ein Problem bei SML sein ?
Grüße Markus
Edit: gerade erst den screenshot gesehen: sind doch ne menge readings, nur die zählerstände leider noch null ;-(

[rretsiem]

Ich lese via SML Infrarot ab.
Mit dem "minicom" aus dem Volkszähler Wiki erhalte ich aber nur Müll, die Parity (8N1) und Baud 9600 habe ich denke ich korrekt eingestellt. Zumindest scheint das OBIS Modul damit ja auch das Power auszuwerten.

Hier mal der List:

Code: [Auswählen]

Internals:
   DEF        /dev/serial/by-id/usb-Silicon_Labs_CP2104_USB_to_UART_Bridge_Controller_010660A3-if00-port0@9600,8,N,1 SML
   DeviceName /dev/serial/by-id/usb-Silicon_Labs_CP2104_USB_to_UART_Bridge_Controller_010660A3-if00-port0@9600,8,N,1
   FD         12
   MeterType  SML
   NAME       powerMeter
   NR         21
   PARTIAL
   STATE      opened
   TYPE       OBIS
   Readings:
     2016-04-23 23:31:33   ManufID         EMH
     2016-04-23 23:31:33   PublicKey
     2016-04-23 18:16:30   Version         EMH\09-01-45-4D-48-00-00-54-5E-15
     2016-04-23 23:31:12   dir_energy_total in
     2016-04-23 23:31:33   dir_total_consumption in
     2016-04-23 23:31:12   energy_total    0
     2016-04-23 23:31:12   energy_total_Ch1 0
     2016-04-23 23:31:12   energy_total_Ch2 0
     2016-04-23 23:31:33   power           341.1
     2016-04-23 23:31:33   statEnergy_total Hour: 0 Day: 0 Month: 0 Year: 0 (since: 2016-04-23_22:33:27 )
     2016-04-23 23:31:33   statPowerDay    Min: 86.1 Avg: 202.3 Max: 2347.8 (since: 2016-04-23_17:39:54 )
     2016-04-23 23:31:33   statPowerMonth  Min: 86.1 Avg: 202.3 Max: 2347.8 (since: 2016-04-23_17:39:54 )
     2016-04-23 23:31:33   statPowerYear   Min: 86.1 Avg: 202.2 Max: 2347.8 (since: 2016-04-23_17:39:54 )
     2016-04-23 23:28:41   state           opened
     2016-04-23 23:31:33   total_consumption 0
     2016-04-23 23:31:33   total_consumption_Ch1 0
     2016-04-23 23:31:33   total_consumption_Ch2 0
   Helper:
     BUFFER
     EoM        -1
     SPEED      5
     TRIGGERTIME 1461446921.24283
     _98_statistics statPowerMeter
     Channels:
     DEVICES:

       5

     Directions:
Attributes:
   event-min-interval power:10
   interval   5

Merkwürdig ist halt, das nicht mal die "Standards" wie PublicKey, welches ja vermutlich eindeutig definiert ist leer sind.

Hier mal noch ein Auszug aus dem Log mit verbose 5

Code: [Auswählen]

2016.04.23 23:33:36 5: SW:
2016.04.23 23:33:36 5: OBIS (powerMeter) - Internal timer set to 2016-04-23 23:33:41
2016.04.23 23:33:38 3: Telegram=77078181C78203FF0101010104454D4801
2016.04.23 23:33:38 3: Telegram=77070100000009FF010101010B0901454D480000545E1501
2016.04.23 23:33:38 3: Telegram=77070100010800FF6400018201621E52FF56000004A59E01
2016.04.23 23:33:38 3: Telegram=77070100010801FF0101621E52FF56000004A59E01
2016.04.23 23:33:38 3: Telegram=77070100010802FF0101621E52FF56000000000001
2016.04.23 23:33:38 3: Telegram=77070100100700FF0101621B52FF550000041001
2016.04.23 23:33:38 3: Telegram=77078181C78205FF0172620165000491C801018302BFA2B33BE0A7515D36F545E3B1E358C0CA1A245553A9AA93B9EF21898F37CC6DF5571038FC2FE47DB1FDF1AED724C214010101635C24007607000B000BC7706200620072630201710163179100000000
2016.04.23 23:33:38 5: OBIS (powerMeter) - Msg-Parse: /EMH\09-01-45-4D-48-00-00-54-5E-15
2016.04.23 23:33:38 5: OBIS (powerMeter) - Msg-Parse: 129-129:199.130.3*255(EMH)
2016.04.23 23:33:38 5: OBIS (powerMeter) - Msg-Parse: 1-0:0.0.9*255(09-01-45-4D-48-00-00-54-5E-15)
2016.04.23 23:33:38 5: OBIS (powerMeter) - Msg-Parse: 1-0:1.8.0*255(>0*Wh)
2016.04.23 23:33:38 5: OBIS (powerMeter) - Msg-Parse: 1-0:1.8.1*255(0*Wh)
2016.04.23 23:33:38 5: OBIS (powerMeter) - Msg-Parse: 1-0:1.8.2*255(0*Wh)
2016.04.23 23:33:38 5: OBIS (powerMeter) - Msg-Parse: 1-0:16.7.0*255(104*W)
2016.04.23 23:33:38 5: OBIS (powerMeter) - Msg-Parse: 129-129:199.130.5*255()
2016.04.23 23:33:38 5: OBIS (powerMeter) - Msg-Parse: !
2016.04.23 23:33:41 5: SW:
2016.04.23 23:33:41 5: OBIS (powerMeter) - Internal timer set to 2016-04-23 23:33:46
2016.04.23 23:33:44 3: Telegram=77078181C78203FF0101010104454D4801
2016.04.23 23:33:44 3: Telegram=77070100000009FF010101010B0901454D480000545E1501
2016.04.23 23:33:44 3: Telegram=77070100010800FF6400018201621E52FF56000004A5A001
2016.04.23 23:33:44 3: Telegram=77070100010801FF0101621E52FF56000004A5A001
2016.04.23 23:33:44 3: Telegram=77070100010802FF0101621E52FF56000000000001
2016.04.23 23:33:44 3: Telegram=77070100100700FF0101621B52FF550000040B01
2016.04.23 23:33:44 3: Telegram=77078181C78205FF0172620165000491CF01018302BFA2B33BE0A7515D36F545E3B1E358C0CA1A245553A9AA93B9EF21898F37CC6DF5571038FC2FE47DB1FDF1AED724C21401010163A8A1007607000B000BC77C6200620072630201710163E87300000000
2016.04.23 23:33:44 5: OBIS (powerMeter) - Msg-Parse: /EMH\09-01-45-4D-48-00-00-54-5E-15
2016.04.23 23:33:44 5: OBIS (powerMeter) - Msg-Parse: 129-129:199.130.3*255(EMH)
2016.04.23 23:33:44 5: OBIS (powerMeter) - Msg-Parse: 1-0:0.0.9*255(09-01-45-4D-48-00-00-54-5E-15)
2016.04.23 23:33:44 5: OBIS (powerMeter) - Msg-Parse: 1-0:1.8.0*255(>0*Wh)
2016.04.23 23:33:44 5: OBIS (powerMeter) - Msg-Parse: 1-0:1.8.1*255(0*Wh)
2016.04.23 23:33:44 5: OBIS (powerMeter) - Msg-Parse: 1-0:1.8.2*255(0*Wh)
2016.04.23 23:33:44 5: OBIS (powerMeter) - Msg-Parse: 1-0:16.7.0*255(103.5*W)
2016.04.23 23:33:44 5: OBIS (powerMeter) - Msg-Parse: 129-129:199.130.5*255()
2016.04.23 23:33:44 5: OBIS (powerMeter) - Msg-Parse: !


[Icinger]

Hi,

bin grad vom Männerabend heimgekommen.

Für 1-0:1.8.2 liefert der Zähler wirklich einen Wert von 0.
Die restlichen Daten sehen ansich gut aus, muss ich mir anschaun, warum die nicht richtig umgerechnet werden.
Hat sonst noch jemand das Problem mit Null-Werten? Dürfte so eigentlich nicht sein.
Werd ich mir heute im lauf des Tages mal näher ansehen.

lg, Stefan

[willybauss]

Ich habe mich jetzt mal getraut, ein Update zu machen (bin da immer erst etwas zurückhaltend). Ich hatte vorher noch die Version vom 6. März drauf, also ohne SML. Und mein Zähler war einer derer, die Kummer bereitet hatten, weil er die Daten ungefragt pusht, und dadurch die CPU übermäßig beanspruchte.

Nach dem Update läuft alles genauso weiter wie vorher musste ich erst mal die Zeile 73 ($hash->{SetFn} = "OBIS_Set") auskommentieren, damit es lief; anschließend: die Daten kommen im Minutentakt (interval 60) und die CPU-Last bleibt niedrig (pollingMode on). Auch an der define-Zeile musste ich nichts ändern (... -port0@9600,7,E,1), also weiterhin ohne Zählertypangabe.

Super, danke!!!  Bitte das mit der auskommentierten Zeile noch korrigieren.

[Icinger]

@rretsiem:
Hab mir das mal angeschaut, dein Zähler schickt innerhalb des Datenpakets komische Daten mit.

zB PublicKey:

Code: [Auswählen]

2016.04.24 10:24:53 3: Telegram=77078181C78205FF (Status-->)01 7262 (valTime-->)01 6500052093 (unit-->)01 (scaler-->)01 (Daten-->)8302BFA2B33BE0A7515D36F545E3B1E358C0CA1A245553A9AA93B9EF21898F37CC6DF5571038FC2FE47DB1FDF1AED724C214010101633E3C007607000B000D26DF620062007263020171016361B700000000
Die Infos in Klammern habe ich dazugeschrieben.
Die "7262" und "6500052093" sind zwar grundsätzlich gültige T/L-Felder mit Daten, haben aber lt. SML-Standard an dieser Stelle nichts zu suchen.
Auch laut http://wiki.volkszaehler.org/hardware/channels/meters/power/edl-ehz/emh-ehz-h1 haben die da nicht drinnen zu sein.

Ich überlege grade, wie ich solche unnötigen Daten rausfiltern könnte......Vielleicht fällt mir da was dazu ein, aber erstmal bin ich grade noch ratlos.

lg, Stefan

[hf007]

Hallo,

habe gestern auch auf das OBIS Modul umgestellt. Es kommen Daten an aber fhem hängt sich immer wieder auf.
Folgendes taucht im LogFile auf

Code: [Auswählen]

2016.04.24 13:02:14 1: PERL WARNING: substr outside of string at ./FHEM/47_OBIS.pm line 576.
2016.04.24 13:02:14 3: Telegram=77078181C78203FF010101010449534B01
2016.04.24 13:02:14 3: Telegram=77070100000009FF010101010B0649534B01027A20E10901
2016.04.24 13:02:14 3: Telegram=77070100010800FF650000018201621E52FF590000000003DCA61F01
2016.04.24 13:02:14 3: Telegram=77070100010801FF0101621E52FF590000000003DCA61F01
2016.04.24 13:02:14 3: Telegram=77070100010802FF0101621E52FF59000000000000000001
2016.04.24 13:02:14 3: Telegram=770701000F0700FF0101621B520065000000D601
2016.04.24 13:02:14 3: Telegram=77078181C78205FF010101018302FDB1F1A9995BEB528B8BBC630D43696174611B22A94FDCC41F083261A4341586BA67AA3F8892CB4E098EDBFC4CC72F1D01010163B04E0076050AA3D7FB6200620072630201710163719700
2016.04.24 13:03:01 3: Telegram=77078181C78203FF010101010449534B01
2016.04.24 13:03:01 3: Telegram=77070100000009FF010101010B0649534B01027A20E10901
2016.04.24 13:03:01 3: Telegram=77070100010800FF650000018201621E52FF590000000003DCA65501
2016.04.24 13:03:01 3: Telegram=77070100010801FF0101621E52FF590000000003DCA65501
2016.04.24 13:03:01 3: Telegram=77070100010802FF0101621E52FF59000000000000000001
2016.04.24 13:03:01 3: Telegram=770701000F0700FF0101621B520065000000D901
2016.04.24 13:03:01 3: Telegram=77078181C78205FF010101018302FDB1F1A9995BEB528B8BBC630D43696174611B22A94FDCC41F083261A4341586BA67AA3F8892CB4E098EDBFC4CC72F1D010101637FE40076050AA3D89D6200620072630201710163FDC500
2016.04.24 13:04:00 3: Telegram=77078181C78203FF010101010449534B01
2016.04.24 13:04:00 3: Telegram=77070100000009FF010101010B0649534B01027A20E10901
2016.04.24 13:04:00 3: Telegram=77070100010800FF650000018201621E52FF590000000003DCA67901
2016.04.24 13:04:00 3: Telegram=77070100010801FF0101621E52FF590000000003DCA67901
2016.04.24 13:04:00 3: Telegram=77070100010802FF0101621E52FF59000000000000000001
2016.04.24 13:04:00 3: Telegram=770701000F0700FF0101621B520065000000DD01
2016.04.24 13:04:00 3: Telegram=77078181C78205FF010101018302FDB1F1A9995BEB528B8BBC630D43696174611B22A94FDCC41F083261A4341586BA67AA3F8892CB4E098EDBFC4CC72F1D01010163345D0076050AA3D9096200620072630201710163A3FD00
2016.04.24 13:05:02 3: Telegram=77078181C78203FF010101010449534B01
2016.04.24 13:05:02 3: Telegram=77070100000009FF010101010B0649534B01027A20E10901
2016.04.24 13:05:02 3: Telegram=77070100010800FF650000018201621E52FF590000000003DCA69E01
2016.04.24 13:05:02 3: Telegram=77070100010801FF0101621E52FF590000000003DCA69E01
2016.04.24 13:05:02 3: Telegram=77070100010802FF0101621E52FF59000000000000000001
2016.04.24 13:05:02 3: Telegram=770701000F0700FF0101621B520065000000DD01
2016.04.24 13:05:02 3: Telegram=77078181C78205FF010101018302FDB1F1A9995BEB528B8BBC630D43696174611B22A94FDCC41F083261A4341586BA67AA3F8892CB4E098EDBFC4CC72F1D010101633CBA0076050AA3D9786200620072630201710163F8F600
Undefined subroutine &main::OBIS_Set called at fhem.pl line 3163.

Wo könnte der Fehler liegen?
Gruß, hf