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

[papa]

Kennst Du das hier ?
https://forum.fhem.de/index.php/topic,117864.msg1124767.html#msg1124767

[ioT4db]

Kennst Du das hier ?
https://forum.fhem.de/index.php/topic,117864.msg1124767.html#msg1124767

hi,
danke für den Tipp, kannte ich noch nicht!
Da scheint sich ja einiges zu tun. Lesestoff für heut abend

VG

[stefanru]

Hi,

ich habe 2 digitale Strohmzähler per ESP8266 und OBIS angeschlossen.
Das tut soweit wunderbar.
Leider ist mir jetzt in den letzten Wochen 2 mal FHEM abgestürzt.
Am Ende des Fhem logs stand:
2021.03.07 20:25:53 1: PERL WARNING: Integer overflow in hexadecimal number at ./FHEM/47_OBIS.pm line 440.
Cannot pack Inf with 'C' at ./FHEM/47_OBIS.pm line 440.

Ist das der Grund des Absturzes?

Gruß,
Stefan

[gvzdus]

Ich vermute: Ja.

Zeile 440 passt dazu, dass Du die letzte Version verwendest. Mir fehlt die Phantasie, was den Fehler auslöst.

Ich habe mal die ganze Parse-Funktion in einen eval-Block gesteckt, der einen Absturz verhindern *sollte*, und stattdessen hoffentlich die Input-Daten loggt. Deswegen packe ich sie auch nicht ins SVN, sondern erst mal nur hier in den Thread.

Anleitung:
Auf den Server bringen und restarten.
Nach 4 Wochen oder so bitte mal das Logfile nach "OBIS ($name) - Crashed with $@ on parsing buffer $buffer" (also natürlich ohne die Variablen) durchsuchen - vielleicht findet sich was.

Hoffe, es hilft!

[Funnel]

Hallo zusammen,

ich habe ein Problem mit meinem eHZ, welcher an meinem Volkszähler einwandfrei läuft, in FHEM mit 47_OBIS.pm aber nicht alle Daten anzeigt. Im Volkszähler sehe ich die Daten

   
• 1.8.0
• 2.8.0
• 16.7.0

wogegen in FHEM 1.8.0 nicht angezeigt wird.



Parsen der Daten mittels libSML aus dem Volkszähler Projekt:

Code Auswählen Erweitern

1-0:96.50.1*1#EMH#
1-0:96.1.0*255#0a 01 45 4d 48 00 00 7e ab 77 #
1-0:1.8.0*255#1157075.6#Wh
1-0:2.8.0*255#2780614.9#Wh
1-0:16.7.0*255#35#W
1-0:96.50.1*1#EMH#
1-0:96.1.0*255#0a 01 45 4d 48 00 00 7e ab 77 #
1-0:1.8.0*255#1157075.6#Wh
1-0:2.8.0*255#2780614.9#Wh
1-0:16.7.0*255#6#W
1-0:96.50.1*1#EMH#
1-0:96.1.0*255#0a 01 45 4d 48 00 00 7e ab 77 #
1-0:1.8.0*255#1157075.6#Wh
1-0:2.8.0*255#2780614.9#Wh
1-0:16.7.0*255#-28#W
1-0:96.50.1*1#EMH#
1-0:96.1.0*255#0a 01 45 4d 48 00 00 7e ab 77 #
1-0:1.8.0*255#1157075.6#Wh
1-0:2.8.0*255#2780614.9#Wh
1-0:16.7.0*255#-28#W
1-0:96.50.1*1#EMH#
1-0:96.1.0*255#0a 01 45 4d 48 00 00 7e ab 77 #
1-0:1.8.0*255#1157075.6#Wh
1-0:2.8.0*255#2780614.9#Wh
1-0:16.7.0*255#16#W
1-0:96.50.1*1#EMH#
1-0:96.1.0*255#0a 01 45 4d 48 00 00 7e ab 77 #
1-0:1.8.0*255#1157075.6#Wh
1-0:2.8.0*255#2780614.9#Wh
1-0:16.7.0*255#39#W




FHEM Log der gleichen Daten:

Code Auswählen Erweitern


2021.03.09 17:21:03 5: OBIS (EHZ) - Msg-Parse: /

2021.03.09 17:21:03 5: OBIS (EHZ) - Msg-Parse: 1-0:2.8.0*255(2780607.2*Wh)
2021.03.09 17:21:03 5: OBIS (EHZ) - Msg 1-0:2.8.0*255(2780607.2*Wh) is of type Counter
2021.03.09 17:21:03 5: OBIS (EHZ) - Msg-Parse: 1-0:16.7.0*255(-41*W)
2021.03.09 17:21:03 5: OBIS (EHZ) - Msg 1-0:16.7.0*255(-41*W) is of type Channels
2021.03.09 17:21:03 5: OBIS (EHZ) - Msg-Parse: !
2021.03.09 17:21:04 5: OBIS (EHZ) - SML-Parse 1B1B1B1B010101017605020278396200620072630101760107FFFFFFFFFFFF0500AB7D690B0A01454D4800007EAB7772620165013B3024620163C1B10076050202783A62006200726307017707FFFFFFFFFFFF0B0A01454D4800007EAB77070100620AFFFF726
20165013B30247577070100603201010101010104454D480177070100600100FF010101010B0A01454D4800007EAB770177070100010800FF641CB10472620165013B3024621E52FF64B08E040177070100020800FF0172620165013B3024621E52FF6501A849780177070100100700FF0101621B52005224010101637C
2C0076050202783B6200620072630201710163A75C0000001B1B1B1B1A029FE1
2021.03.09 17:21:04 5: OBIS (EHZ) - Full message-> 1B1B1B1B010101017605020278396200620072630101760107FFFFFFFFFFFF0500AB7D690B0A01454D4800007EAB7772620165013B3024620163C1B10076050202783A62006200726307017707FFFFFFFFFFFF0B0A01454D4800007EAB77070100620AFF
FF72620165013B30247577070100603201010101010104454D480177070100600100FF010101010B0A01454D4800007EAB770177070100010800FF641CB10472620165013B3024621E52FF64B08E040177070100020800FF0172620165013B3024621E52FF6501A849780177070100100700FF0101621B5200522401010
1637C2C0076050202783B6200620072630201710163A75C0000001B1B1B1B1A029FE1
2021.03.09 17:21:04 5: OBIS (EHZ) - Telegram=1B1B1B1B010101017605020278396200620072630101760107FFFFFFFFFFFF0500AB7D690B0A01454D4800007EAB7772620165013B3024620163C1B10076050202783A62006200726307017707FFFFFFFFFFFF0B0A01454D4800007EAB77070100620AFFFF7262
0165013B30247577070100603201010101010104454D480177070100600100FF010101010B0A01454D4800007EAB770177070100010800FF641CB10472620165013B3024621E52FF64B08E040177070100020800FF0172620165013B3024621E52FF6501A849780177070100100700FF0101621B52005224010101637C2
C0076050202783B6200620072630201710163A75C0000001B1B1B1B1A029FE1
2021.03.09 17:21:04 5: OBIS (EHZ) - Telegram=0177070100100700FF0101621B52005224010101637C2C0076050202783B6200620072630201710163A75C0000001B1B1B1B1A029FE1
2021.03.09 17:21:04 4: OBIS (EHZ) - MSG IS: 
/
1-0:2.8.0*255(2780607.2*Wh)
1-0:16.7.0*255(36*W)
!

2021.03.09 17:21:04 5: OBIS (EHZ) - Msg-Parse: /
2021.03.09 17:21:04 5: OBIS (EHZ) - Msg-Parse: 1-0:2.8.0*255(2780607.2*Wh)
2021.03.09 17:21:04 5: OBIS (EHZ) - Msg 1-0:2.8.0*255(2780607.2*Wh) is of type Counter
2021.03.09 17:21:04 5: OBIS (EHZ) - Msg-Parse: 1-0:16.7.0*255(36*W)
2021.03.09 17:21:04 5: OBIS (EHZ) - Msg 1-0:16.7.0*255(36*W) is of type Channels
2021.03.09 17:21:04 5: OBIS (EHZ) - Msg-Parse: !
2021.03.09 17:21:05 5: OBIS (EHZ) - SML-Parse 1B1B1B1B0101010176050202783C6200620072630101760107FFFFFFFFFFFF0500AB7D6A0B0A01454D4800007EAB7772620165013B302562016392890076050202783D62006200726307017707FFFFFFFFFFFF0B0A01454D4800007EAB77070100620AFFFF726
20165013B30257577070100603201010101010104454D480177070100600100FF010101010B0A01454D4800007EAB770177070100010800FF641CB10472620165013B3025621E52FF64B08E040177070100020800FF0172620165013B3025621E52FF6501A849780177070100100700FF0101621B520052030101016335
9A0076050202783E620062007263020171016363570000001B1B1B1B1A020E4A
2021.03.09 17:21:05 5: OBIS (EHZ) - Full message-> 1B1B1B1B0101010176050202783C6200620072630101760107FFFFFFFFFFFF0500AB7D6A0B0A01454D4800007EAB7772620165013B302562016392890076050202783D62006200726307017707FFFFFFFFFFFF0B0A01454D4800007EAB77070100620AFF
FF72620165013B30257577070100603201010101010104454D480177070100600100FF010101010B0A01454D4800007EAB770177070100010800FF641CB10472620165013B3025621E52FF64B08E040177070100020800FF0172620165013B3025621E52FF6501A849780177070100100700FF0101621B5200520301010
163359A0076050202783E620062007263020171016363570000001B1B1B1B1A020E4A
2021.03.09 17:21:05 5: OBIS (EHZ) - Telegram=1B1B1B1B0101010176050202783C6200620072630101760107FFFFFFFFFFFF0500AB7D6A0B0A01454D4800007EAB7772620165013B302562016392890076050202783D62006200726307017707FFFFFFFFFFFF0B0A01454D4800007EAB77070100620AFFFF7262
0165013B30257577070100603201010101010104454D480177070100600100FF010101010B0A01454D4800007EAB770177070100010800FF641CB10472620165013B3025621E52FF64B08E040177070100020800FF0172620165013B3025621E52FF6501A849780177070100100700FF0101621B5200520301010163359
A0076050202783E620062007263020171016363570000001B1B1B1B1A020E4A
2021.03.09 17:21:05 5: OBIS (EHZ) - Telegram=0177070100100700FF0101621B5200520301010163359A0076050202783E620062007263020171016363570000001B1B1B1B1A020E4A
2021.03.09 17:21:05 4: OBIS (EHZ) - MSG IS: 
/
1-0:2.8.0*255(2780607.2*Wh)
1-0:16.7.0*255(3*W)
!



Kann mir jemand hierbei einen Hinweis geben?


Gruß
Thomas

[gvzdus]

Hi Thomas,

wie es aussieht, verhaspelt sich der Parser des Moduls und überspringt Teile der Nachricht. Da muss ich tiefer rein, und vermutlich Teile des Parsers neu schreiben. Setz' Dir bitte eine Benachrichtigung auf den Thread - ich sehe zu, bald zu liefern (= eher in Tagen).

Du hast allen Input geliefert, der nötig ist, um dran zu arbeiten.

Cheers, Georg

[Funnel]

Hi Georg,

danke erstmal für dein Feedback. Was hältst Du von der Idee die libSML zu benutzen anstelle des Parsers in 47_OBIS.pm?

Gruß
Thomas

[gvzdus]

libsml ist ein Haufen Klassen in C++. Natürlich kann man grundsätzlich in Perl C-Libraries einbinden, aber das ist eben hässlich.

Nach dem Review von meinem und Deinen Bytesequenzen, und der Überprüfung, dass libsml strukturiert vorgeht, während der gegenwärtiger Parser versucht, "das Fleisch im Bytestrom herauszufischen", denke ich, dass der strukturierte Ansatz funktionieren kann. Sollte auch nicht so schwer sein.

[Funnel]

Meine Idee wäre eher aus der libSML ein stand alone executable zu bauen (ist bereits als Beispiel "sml_server" vorhanden) und dieses von dem perl Modul als Parser aufrufen zu lassen. Ist zwar auch nicht optimal, da dieser Parser für jede Architektur kompiliert werden müsste, scheint dafür aber recht gut getestet und performant zu sein.

Ein Aufruf von: "cat /dev/ttyUSB0 | ./sml_server -" liefert dann folgendes:

Code Auswählen Erweitern

1-0:96.50.1*1#EMH#
1-0:96.1.0*255#0a 01 45 4d 48 00 00 7e ab 77 #
1-0:1.8.0*255#1159302.2#Wh
1-0:2.8.0*255#2780685.1#Wh
1-0:16.7.0*255#420#W
1-0:96.50.1*1#EMH#
1-0:96.1.0*255#0a 01 45 4d 48 00 00 7e ab 77 #
1-0:1.8.0*255#1159302.3#Wh
1-0:2.8.0*255#2780685.1#Wh
1-0:16.7.0*255#419#W


das wiederum sollte sich problemlos auswerten lassen

[stefanru]

Hi gvzdus,

vielen Dank für die Version mit der ich es Monitoren kann.
Ich werde das tun und ab und zu nach den Fehlermeldungen suchen.
Mit welchem Loglevel werden die Meldungen rausgeschrieben?

Gruß und vielen Dank,
Stefan

[gvzdus]

@Stefan: Die Meldungen würden im höchsten Loglevel geschrieben - immerhin wurde ja beinahe ein Crash abgewendet

Für alle
Letztlich habe ich mich jetzt mal hingesetzt und konzentriert den (vermeintlich sauberen) Parser implementiert. Außerdem arbeitet der Parser jetzt binär und streamend, also weniger Regex-Overhead und keine Nibble-Vertauschung. Wer in den Code gucken möchte:

Die neue Routine OBIS_Parse_List ist das Herzstück des Parsers und ersetzt die while (/7707/)-Schleife durch einen "richtigen" Parser.

Der Parser läuft bei mir seit ein paar Stunden fehlerfrei, und den Code von Thomas "frisst" er auch. Daher suche ich Freiwillige, die auch ohne Not zur angehängten Version Feedback geben. Besonders interessant wäre, ob - wie vermutet - auch Performance-Vorteile erkennbar sind.

P.S.: Stefan, die Wahrscheinlichkeit ist hoch, dass es am alten Parser lag. Deswegen vielleicht auch lieber diese Version hier verwenden, denn wenn keine Katastrophenmeldungen reinkommen, die ich nicht schnell lösen kann, wird diese Version bald die offizielle sein.

Noch ein Nachtrag: Wer mindestens auf "verbose 3" loggt, könnt mir den Gefallen tun, mal im historischen Logfile nach "OBIS_Ext called" im Logfile zu suchen. Mir erschloss sich nicht der Sinn dieses Codes, und ich habe ihn deaktiviert.

P.S. Version gelöscht, siehe weiter unten.

[Funnel]

Kurzes Feedback von mir: Die neue Version läuft bis jetzt einwandfrei, die Performance ist geringfügig besser geworden.

Vielen Dank für deinen Einsatz!

Gruß
Thomas

[gvzdus]

Danke!

Zur Performance: Bei mir hängen eine Vielzahl von Regeln hinter dem Device. Auch der alte Parser war eigentlich relativ unbeachtlich (allerdings läuft bei mir alles auf Raspi 3 und höher): Die Kette danach kostet die CPU.
Generell finde ich den Pollmode eigentlich Mist. Er ergibt nur Sinn, wenn man nur die absoluten Zählerstände verwertet, also z.B. "Momentan"-Leistung als Delta aus den absoluten Wh-Ständen berechnet. Dann erhält man im einstelligen Watt-Bereich genaue Zahlen erst ab etwa 5 Minuten Intervall.
Daher ist eigentlich meine Zielsetzung, dass der "empfohlene" Einsatz ein permanentes Parsen ist, und wer die Systemlast reduzieren möchte, eher über das Standard-Attribut "event-aggregator" (Lesenswert!!) die Event-Rate reduziert. Nur ein Beispiel, wie ich den Shelly, der mein "Home-Office" misst und abschaltet, und wegen der Schaltnetzteile "verrückt spielt", etwas gedrosselt habe:

Code Auswählen Erweitern

relay_0_power:30:linear:mean

[gvzdus]

Anbei eine neue Version. Heute morgen fand ich FHEM "aufgehängt" vor (100% CPU). Das ist mir bisher eigentlich vielleicht einmal passiert - der Verdacht liegt natürlich beim neuen Modul.

Ich habe daraufhin die Parse-Routine mit einigen 100 MB an Random-Daten beworfen und 2 Stellen im Code verbessert. Mal als "diff" für den Neugierigen:

Code Auswählen Erweitern

< # $Id: 47_OBIS.pm TESTVERSION 2021-03-11 09:06:24Z gvzdus $
---
> # $Id: 47_OBIS.pm TESTVERSION 2021-03-10 15:06:44Z gvzdus $
421d420
<     return undef if ($len>length $_[3] || $len<0);
457c456
<   while ($len-- > 0) {
---
>   while ($len--) {


Hier die geänderte Version:
(Zurückgezogen wegen mutmaßlichem Bug)

[Funnel]

Ich hatte heute 2 Warnings aus dem neuen Modul (die Version von gestern):

Code Auswählen Erweitern

2021.03.11 14:38:37 1: PERL WARNING: substr outside of string at ./FHEM/47_OBIS.pm line 529.
2021.03.11 14:38:37 1: PERL WARNING: Use of uninitialized value in reverse at ./FHEM/47_OBIS.pm line 529.