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

[Homalix99]

Hallo !
Ich habe eine Frage an den Modulautor.
OBIS läuft sein 10 Monaten stabil, nur kommt es alle paar Monate vor, dass der Zweirichtungszähler (Fa. EMH, Typ P) aus unerfindlichen Gründen undefinierte SML-Daten auswirft, welche vom Modul als Readings interpretiert wird (siehe unten).

Code Auswählen Erweitern


Internals:
   DEF        /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AH065FCR-if00-port0 SML
   DeviceName /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AH065FCR-if00-port0
   FD         32
   MeterType  SML
   NAME       ZRZ
   NR         1218
   PARTIAL   
   STATE      opened
   TYPE       OBIS
   .attraggr:
   .attreocr:
     .*
   .attrminint:
     10
   .userReadings:
     HASH(0x5252db8)
     HASH(0x5300bd0)
   READINGS:
     2019-03-22 04:46:55   0.0.0.0.27.255  0
     2019-03-29 23:15:47   0.11.10.1.69.255 643620
     2019-02-19 02:00:40   0.118.5.3.203.255 0
     2019-03-30 18:58:50   0.118.5.4.104.255 459007
     2019-03-31 07:25:32   0.118.5.4.106.255 -93
     2019-03-23 13:36:16   0.118.5.4.75.255 3327118.7
     2019-03-29 23:15:57   10.11.10.1.69.255 590340
     2019-03-29 23:17:27   100.11.10.1.69.255 192960
     2019-03-29 23:17:37   110.11.10.1.69.255 555060
     2019-03-29 23:17:57   130.11.10.1.69.255 594260
     2019-03-29 23:18:07   140.11.10.1.69.255 336120
     2019-03-29 23:18:27   160.11.10.1.69.255 637690
     2019-03-29 23:18:37   170.11.10.1.69.255 524670
     2019-03-29 23:18:47   180.11.10.1.69.255 117140
     2019-03-29 23:18:57   190.11.10.1.69.255 203310
     2019-03-29 23:16:07   20.11.10.1.69.255 229670
     2019-03-29 23:19:07   200.11.10.1.69.255 505770
     2019-03-29 23:19:17   210.11.10.1.69.255 455010
     2019-03-29 23:19:27   220.11.10.1.69.255 517110
     2019-03-29 23:19:37   230.11.10.1.69.255 413640
     2019-03-29 23:19:47   240.11.10.1.69.255 307520
     2019-03-29 23:19:57   250.11.10.1.69.255 224950
     2019-03-29 23:16:17   30.11.10.1.69.255 517170
     2019-03-29 23:16:27   40.11.10.1.69.255 273690
     2019-03-29 23:16:37   50.11.10.1.69.255 317270
     2019-03-29 23:16:47   60.11.10.1.69.255 42250
     2019-03-29 23:16:57   70.11.10.1.69.255 212440
     2019-03-29 23:17:07   80.11.10.1.69.255 313150
     2019-03-29 23:17:17   90.11.10.1.69.255 109560
     2019-04-05 10:57:43   Hersteller      EMH
     2019-04-05 10:57:43   Power.av        -341.640
     2019-04-05 10:57:43   Powerconsumption 270
     2019-04-05 10:57:43   ZRZ_Status      1865988
     2019-04-05 10:57:43   power           -346
     2019-04-05 10:57:43   power_L1        -136
     2019-04-05 10:57:43   power_L2        -24
     2019-04-05 10:57:43   power_L3        -188
     2019-04-04 13:02:56   state           opened
     2019-04-05 10:57:43   total_consumption 1826726.1
     2019-04-05 10:57:43   total_feed      3575439.7
   helper:
     BUFFER     
     EoM        1
     SPEED      5
     TRIGGERTIME 1554375776.3594
     Channels:
       1.0.36.7.0.255 power_L1
       1.0.56.7.0.255 power_L2
       1.0.76.7.0.255 power_L3
       1.0.96.5.0.255 ZRZ_Status
       1.0.96.50.1.255 Hersteller
     DEVICES:
       
       10
       
     directions:
     history:
       ARRAY(0x2867158)
       ARRAY(0x491ea10)
       ARRAY(0x58eb7c8)
       ARRAY(0x2883988)
       ARRAY(0x5a3a0a8)
       ARRAY(0x5c699f8)
       ARRAY(0x5ac0698)
       ARRAY(0x590b100)
       ARRAY(0x5aa7298)
       ARRAY(0x30a2708)
       ARRAY(0x59b6108)
       ARRAY(0x59afad0)
       ARRAY(0x49b5298)
       ARRAY(0x28001a8)
       ARRAY(0x58d54e8)
       ARRAY(0x28833e8)
       ARRAY(0x58d5800)
       ARRAY(0x58961b8)
       ARRAY(0x5dad600)
       ARRAY(0x592f170)
       ARRAY(0x5b24848)
       ARRAY(0x592dcc8)
       ARRAY(0x479e1d8)
       ARRAY(0x5900498)
       ARRAY(0x5ae0ad0)
Attributes:
   Device_dependend eHZ_History
   channels   {"1.0.96.5.0.255"=>"ZRZ_Status","1.0.96.50.1.255"=>"Hersteller","1.0.36.7.0.255"=>"power_L1","1.0.56.7.0.255"=>"power_L2","1.0.76.7.0.255"=>"power_L3"}
   event-min-interval 10
   event-on-change-reading .*
   group      Verbrauchszähler
   icon       electric_meter_bidirectional
   interval   10
   room       Keller,PV_Anlage
   userReadings Power.av {movingAverage("ZRZ","power",100)},
Powerconsumption {ReadingsVal("PV_WR","SPOT_PACTOT",0) + ReadingsVal("ZRZ","power",0)}
   verbose    0


Dann stehen 20 - 30 schwachsinnige Readings im Objekt und es ist lässtig, immer bis nach unten zu scrollen um die eigentlich interessanten readings zu sehen.
Frage: Kann man so was im Modul abfangen, z. B. mit einem Atrribut "disable_autocreate_readings", was defaultmässig auf 0 (enabled) gesetzt ist (zum erstmaligen Anlegen der gültigen Readings) und dann auf 1 (disable) um dies zu vermeiden?

VG

Alex

[KölnSolar]

Hallo Alex,
bin zwar nicht der Modulautor, aber ignoreUnknown=on sollte Dein Bedürfnis befriedigen.
Grüße Markus

[Homalix99]

Oh danke für den Hinweis. Habe ich in der Referenz nicht gefunden (dort ist es scheinbar nicht dokumentiert). Als Attribut verfügbar und bereits gesetzt. Ich denke das war die Lösung.
VG

Alex

[MPDb]

Hallo an alle,

ich komme mit meinem Zähler nicht weiter - das einzige was ich bekomme ist nicht verständlich.

Im Buffer steht folgendes (etwas beschnitten)

Code Auswählen Erweitern

Internals:
   CFGFN     
   DEF        /dev/ttyStrom@9600,7,N,1 Standard
   DeviceName /dev/ttyStrom@9600,7,N,1
   FD         34
   FUUID      5caf98af-f33f-a0bc-0a4a-0aaf823f74c4749c
   MeterType  Standard
   NAME       strom
   NR         50801
   PARTIAL   
   STATE      opened
   TYPE       OBIS
   READINGS:
     2019-04-12 08:00:23   state           opened
   helper:
     BUFFER     ,~6{FY*e{Rfc+9/9(/*vw{|{GQAR9{{l?{cY*ekj/j{{rvR)'i
~;{e{VvkjK'{rvR)'i~v{e{Vv{__VRh)'i;{FY*e{Vf%!qh)'i~Y{e{Vv{[~'R){,~6{FY*e{Rc+9/9(/*vw{|{GQAR9/{{l?{~Y*'K'{rvR)'ic{~;{e{Vvkjoj{{vR)'i'~v{e{Vv{__VRh)'i~v{e{Vv{V%!qh)'i{~Y{e{Vv{[~'R){,~6{FY*e{Rfc+9/9(/*vw|QAR9/{{l?{~Y*ekj/j{{vR)'i
~;{e{Vvkj/j{{vR)'i~v{e{Vv{_^VRh)'i4v{e{Vv{V%!qh)'ic{~Y{e{Vv{[~'R){,~6{FY*e{Rfc+9/9(/*vw{|{GQAR9/{{l?{~Y*ekj/j{{vR)'i
~;{e{VvkjK'{rvR)'i|v{e{Vv{__VRh)'i;{FY*e{V%!qh)'i
ce~Y*e{[~'R){,~6{FY*e{Rc+9/9(/*vw{|{GQAR9{{l?{~Y*ekjj{{vR)'i
~;{e{Vvkj/j{{vR)'i'~v{e{Vv{__VRh)'i|v{e{Vv{Vf%!qh)'i
~Y{esVv{[~'R){,~6{FY*e{Rc+9/9(/*vw|{GQAR9{{l?{~Y*'/j{{vR)'ic{~;{e{Vvkj/j{{vR)'i|v{e{Vv{__VRh)'i|v{e{Vv{V%!qh)'ic{~Y{e{Vv{[~'R){,~6{FY*e{Rfc+9/9(/*vw{|{GQAR9/{{l?{~Y*ekj/j{{vR)'i
~;{{VvkjK'{vR)'i~v{e{Vv{__VRh)'i;{FY*e{V%!qh)'i
~Y{e{Vv{[~'R){,~6{FY*e{Rc
+9/9(o*vw{|{GQAR9/{{c?{e{Vvkjj{{rvR)'i
~;{e{VvkjK'{rvR)'i~v{e{Vv{__VRh)'i~v{e{Vv{Vf%!qh)'i
~Y{e{Vv{[~'R){,~6{FY*e{Rc}-9/9(Kw{|{GQAR9{{l?{~Y*ekjoj{{vR)'i~;{e{Vvkj/j{{vR)'i'~v{e{Vv{__VRh)'i~v{e{Vv{Vf%!qh)'icz~Y{e{Vv{[~'R){,~6{FY*e{Rfc{-9/9(/*vw{|{GQAR9/{{l?{~Y*ekj/j{{vR)'i
~;{e{Vvkjj{{rvR)'i~v{e{Vv{__~VRh)'i;{FY*e{V%!qh)'i
{~Y{e{Vv{[~'R){,~6{FY*e{Rcy+9/9(/*vw{|}QAR9/{{l?{~Y*ekjK'{vR)'i
~;{e{VvkjK'{rvR)'i~v{e{Vv{__VRh)'i~v{e{Vv{V%!qh)'i
~Y{e{Vv{[~'R){,~6{FY*e{Rcw-9/9(/*vw{|{GQAR9/{{~?{e{Vvkj?j{{vR)'i
{~;{e{Vvkj/j{{vR)'i'~v{e{Vv{__VRh)'i~v{e{Vv{Vf%!qh)'i
ce~Y*e{[~'R){,~6{FY*e{Rcu+9/9(/*vw{|{GQAR9/{{l?{~Y*ekj/j{{vR)'i

Zähler ist ein eBZ DD3 2R06 ETA - ODZ1
Lesekopf ist die TTL-Version von Volkszähler

Erst hatte ich den Zähler an einen Raspberry PI Zero W direkt am ttyAMA0 angeschlossen und über ser2net weitergegeben.
vom Zähler habe ich gar keine ausgaben bekommen.
Loopback funktionierte aber - da erhielte ich alles so wieder wie gesendet.

Als ich den Lesekopf an einen FTDI-USB Adapter und dann an den USB Port des RPi angeschlossen habe, bekam ich eine Ausgabe wie oben.
Mit dem Databits, Stopbits und Parity habe ich natürlich auch versucht etwas zu erreichen.

Nächster Versuch ist ein ESP8266 mit EasyESP und dem Serial Server - was ja auch ein ser2net ist.
Gleiches Ergebnis. Auch hier rumgespielt mit den Settings.

Von seriellen Übertragungen habe ich wenig Ahnung.
In der Ausgabe kann ich auch keine Werte erkennen, die da sein sollten

Laut einer im Internet gefunden Anleitung vom DD3 sollte es 7E1 sein - in diesem Thread hatte jemand mit 7E0 erfolgt.
Änderte bei mir wenig.
Es sieht auch komplett anders aus, als bei anderen hier, wenn es falsch war

Hat jemand eine Idee an welche Schraube ich noch drehen könnte? Bin für jeden Tipp Dankbar.
Hatte ja den Lesekopf in Verdacht, aber da das Loopback funktioniert...

Danke
Grüße
Falko

[KölnSolar]

Hi Falko,
Standard ist aber richtig u. nicht evtl. SML ? 

Auch die Baudrate mal runtergedreht ? Ich las von Zählern die wohl nur 300 können. 

Grüße Markus

[Icinger]

Sieht mir verdammt stark nach falscher Baudrate aus.....

Edith: 10 Sekunden Google:

6.1Aufbau derDatentelegramme
TelegrammMode D:nach DIN EN 625056-21
Baudrate:9600 Baud (Z=5)
Byte-Format:(7,even,1)

Du hast aber 7N1 eingestellt!

[cs-online]

Hallo,

ich habe Udos Volkszähler-IR-Kopf an ESP8266 mit ESP Link angebunden, UART-Pins normal, Haken bei Pullup, 9600 Baut, 8N1, RX vom Kopf an TX vom ESP und umgekehrt. Erst nach dem ich die Einstellungen so hatte, kamen in der uConsole auch kryptische Zeichen und dann konnte ich den Zähler in FHEM auch einbinden

Grüße

Christian

[MPDb]

Hallo, 
danke für die Tips.
7E1 hatte ich natürlich als erstes versucht - die Anleitung hatte ich auch gefunden.
War aber ähnlich im Ergebnis und keine Readings wurden erstellt.

Wie gesagt - hatte mit den Einstellungen etwas rumgespielt.
Auf 300 bin ich wiederum nicht runter gegangen - auch mal testen.


ESPLink wiederum habe ich noch nicht probiert.
Werde den ESP neu bespielen.
Wie nimmst Du das die Daten auf dem FHEM Server an?
Socat?

Grüße
Falko

[MPDb]

Hallo nochmal,

mit ESP-Link habe ich ähnlich Ergebnisse.
Wiederrum meldet das Log, das es möglicherweise eine falsche Baudrate ist - spontan habe ich aber keine Möglichkeit gefunden Werte unter 9600 einzugeben.

Muss mal schauen, ob ich irgendwo einen anderen Lesekopf leihen kann bzw den Kopf irgendwo testen kann.

Grüße
Falko

[Icinger]

Also ich kann auf ESPLink mit Version esp-link v3.2.47-g9c6530d die Baudrate von 300 bis 460800 einstellen.

[MPDb]

Mein Fehler,
Hatte Version 2.2.3 gehabt. Da scheint es nicht zu gehen.

Mit Version 3.0.14 kann ich es einstellen. Die aktuellste Version endete bei meinem ESP in einer Bootloop und da sollte man die 3.0.14 nehmen.

Leider scheint mein Problem aber nicht daher zu kommen.
Auch hier habe ich ziemlich die gleichen Daten.
Habe soweit alle Baudraten von 300 bis 57600 versucht.
Im DebugLog stand auch bei alle baudraten

Code Auswählen Erweitern

UART framing error (bad baud rate?)

Wünsche ein paar ruhige Tage
Grüße
Falko

[cs-online]

...hast du mal mit 8N1 bei 9600 Baut probiert ? Bei mir ist der dann in FHEM so eingebunden:

define Stromzaehler OBIS 192.168.2.61:23
attr Stromzaehler ignoreUnknown off
attr Stromzaehler valueBracket both

wobei 192.168.2.61 bei mir die IP vom ESP mit ESP-Link ist. Im ESP-Link mal so wie angehängt konfigurieren. Dran gedacht, RX vom IR-Kopf an TX  vom ESP und umgekehrt zu verdrahten ?

[MPDb]

Moin,

ja habe Deine Einstellungen mal probiert - auch kein Erfolg.
Hatt auch mal die RX/TX Stecker getauscht - da kam dan wie erwartet gar nichts

Entweder sendet mein Zähler seltsam oder am Ende ist mein Lesekopf das Problem.
Der Loopback über einer weissen Fläche klappte zwar, aber wer weiß.

Werde mal schauen, ob ich irgendwo an einen anderen Zähler komme - wenn es mit dem klappt, wäre ich zumindest ein Schritt weiter.

[eisenhauer1987]

Hallo zusammen,

ich möchte hier nochmal auf das Bufferoverflow Thema kommen, welches vor einigen Wochen ein paar Probleme gemacht hatte. Ich hatte dann eine aktuelle Version eingespielt und dachte das Problem wäre damit beseitigt. Es ist auch deutlich besser geworden. Allerdings gibt es immer noch ca. alle 2 Wochen einen Komplettausfall des FHEM wegen OBIS. Damals wurde ja empfohlen das Loglevel hochzusetezn, das habe ich gemacht, hier ist der Auszug:

Code Auswählen Erweitern


2019.03.16 06:53:13 5: OBIS (Stromzaehler1) - Msg-Parse: 1-0:1.8.0*255(4478162.4*Wh)
2019.03.16 06:53:13 5: Msg 1-0:1.8.0*255(4478162.4*Wh) is of type Counter
2019.03.16 06:53:13 4: Set total_consumption to 4478162.4
2019.03.16 06:53:13 5: OBIS (Stromzaehler1) - Msg-Parse: 1-0:16.7.0*255(919*W)
2019.03.16 06:53:13 5: Msg 1-0:16.7.0*255(919*W) is of type Channels
2019.03.16 06:53:13 5: OBIS (Stromzaehler1) - Msg-Parse: !
2019.03.16 06:53:14 5: SML-Parse 1B1B1B1B01010101760501E0A7B06200620072630101760107FFFFFFFFFFFF0500A037E60B0A01454D480000712BFF72620164A0408D620163770700760501E0A7B162006200726307017707FFFFFFFFFFFF0B0A01454D480000712BFF070100620AFFFF72620164A0408D7477070100603201010101010104454D480177070100600100FF010101010B0A01454D480000712BFF0177070100010800FF641C010472620164A0408D621E52FF6502AB503B0177070100100700FF0101621B520053039701010163BD3300760501E0A7B26200620072630201710163BCDB0000001B1B1B1B1A0272F0
2019.03.16 06:53:14 5: OBIS: Full message-> 1B1B1B1B01010101760501E0A7B06200620072630101760107FFFFFFFFFFFF0500A037E60B0A01454D480000712BFF72620164A0408D620163770700760501E0A7B162006200726307017707FFFFFFFFFFFF0B0A01454D480000712BFF070100620AFFFF72620164A0408D7477070100603201010101010104454D480177070100600100FF010101010B0A01454D480000712BFF0177070100010800FF641C010472620164A0408D621E52FF6502AB503B0177070100100700FF0101621B520053039701010163BD3300760501E0A7B26200620072630201710163BCDB0000001B1B1B1B1A0272F0
2019.03.16 06:53:14 5: OBIS: Telegram=1B1B1B1B01010101760501E0A7B06200620072630101760107FFFFFFFFFFFF0500A037E60B0A01454D480000712BFF72620164A0408D620163770700760501E0A7B162006200726307017707FFFFFFFFFFFF0B0A01454D480000712BFF070100620AFFFF72620164A0408D7477070100603201010101010104454D480177070100600100FF010101010B0A01454D480000712BFF0177070100010800FF641C010472620164A0408D621E52FF6502AB503B0177070100100700FF0101621B520053039701010163BD3300760501E0A7B26200620072630201710163BCDB0000001B1B1B1B1A0272F0
2019.03.16 06:53:14 1: PERL WARNING: Integer overflow in hexadecimal number at ./FHEM/47_OBIS.pm line 364.


Könnte das mal einer der Experten Debuggen?

Vielen Dank euch, mohel

Hi,

gibt es zu diesem Problem neue Erkenntnisse? Ich habe das Problem noch immer. Ist eine Lösung in Sicht?

Grüße

[Neuhier]

Weiß nicht, ob das schon irgendwo, in den >500 Beiträgen hier, steht.
Der ED300S geht so:

define S-Zaehler OBIS /dev/ttyUSB0@9600,8,N,1 SML

Habe den an einem RPiZero-W, der hier noch sinnlos rumgammelte.
Dort FHEM drauf und die Daten per FHEM2FHEM abgeholt, fertig.
Lesekopf ist der von Weidmann.