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

[gvzdus]

Nee, war positiv gemeint: PDF vom Hersteller dabei, Output klar: Konnte man runterlesen.

[SouzA]

Nee, war positiv gemeint: PDF vom Hersteller dabei, Output klar: Konnte man runterlesen.

Dann is ja gut...   
Nochmals vielen Dank für das Modul und für die Hilfe!
Klasse Arbeit!   

Bis denn
SouzA

[SouzA]

Hallo,

ich hätte da noch einmal eine Frage.
Was bedeutet folgende Fehlermeldung:

Code Auswählen Erweitern

2021.10.15 14:24:51 3: 2nd TL-byte != 0, reserved according spec
2021.10.15 14:24:51 1: PERL WARNING: Use of uninitialized value $v1 in substitution (s///) at ./FHEM/47_OBIS.pm line 713.
2021.10.15 14:25:21 3: 2nd TL-byte != 0, reserved according spec
Hab ich was falsch eingestellt?

Thx und bis denn
SouzA

Und noch eine Frage dazu:
Warum ist der Befehl für das update eigentlich ein get und nicht ein set?
Mit dem set hätte man vielleicht noch die Möglichkeit einen Button als webcmd zu basteln

[gvzdus]

Dass entweder "ich" (bzw. Ur-Autor Stefan) oder der Hersteller die Spec nicht richtig gelesen hat

Vorschlag: Schneide auf "verbose 5" die Rohdaten mit, bis der Fehler auftritt. Dann kann ich mal gucken... Die Rohdaten (also konkret nur das Beispiel drum rum) kannst Du mir auch per Privatnachricht schicken.

[cs-online]

Und noch eine Frage dazu:
Warum ist der Befehl für das update eigentlich ein get und nicht ein set?
Mit dem set hätte man vielleicht noch die Möglichkeit einen Button als webcmd zu basteln

Du kannst doch ein WebCmd UPDATE setzen und dann ein Eventmap darauf legen oder ?   
/get update:UPDATE/

Grüße

Christian

[SouzA]

Du kannst doch ein WebCmd UPDATE setzen und dann ein Eventmap darauf legen oder ?   
/get update:UPDATE/

Grüße

Christian

Danke für den Tipp...
Allerdings bekomme ich dann die Fehlermeldung im Anhang.

Bis denn
SouzA

[alkazaa]

[UPDATE:]
Ich habe das unten beschriebene Problem nun doch selbst gelöst bekommen:
In der 47_OBIS.pm habe ich nach Zeile 601 eingefügt:

Code Auswählen Erweitern

if ($hash->{MeterType} eq "MT382") {sleep(1)};
Außerdem habe ich nach Zeile 174 eingefügt:

Code Auswählen Erweitern

    "MT382" => ["/?!".chr(13).chr(10),    600,    chr(6)."0".$hash->{helper}{SPEED}."0".chr(13).chr(10)],


[Ursprüngliche Problembeschreibung:]
Ich bekomme seit einiger Zeit nur verstümmelte Antworten von meinem E-Zähler ISKRA MT382.

Das ganze liegt eber wohl nicht am Zähler oder am optischen USB-Interface, denn mit einem experimentellen 47_OBIS.pm, das mir Stefan Guttmann vor einiger Zeit zur Verfügung gestellt hatte, klappt die Kommunikation anscheinend. (Das Modul hat aber paar andere Macken, weshalb ich gern mit dem 'offiziellen' 47_OBIS.pm arbeiten möchte).

Mangels Perl-Kenntnissen komme ich leider nicht allein weiter und wäre für Hilfe dankbar.

Beste Grüße
Franz


Hier das device listing und ein log-Auszug bei Verwendung des offiziellen 47_OBIS.pm:

Code Auswählen Erweitern


Internals:
   CFGFN     
   DEF        /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A9078004-if00-port0@300,7,E,1 VSM102
   DeviceName /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A9078004-if00-port0@300,7,E,1
   FD         29
   FUUID      61792fe1-f33f-a50b-e07f-77fa04a29d60d90a
   MeterType  VSM102
   NAME       E_Zaehler
   NR         1161
   PARTIAL   
   STATE      opened
   TYPE       OBIS
   READINGS:
     2021-10-27 12:58:39   1.0.1.8.0       4468.88
     2021-10-27 12:58:40   1.0.1.8.1       4468.88
     2021-10-27 12:58:41   1.0.1.8.2       0
     2021-10-27 12:58:42   1.0.1.8.3       0
     2021-10-27 12:58:43   1.0.1.8.4       0
     2021-10-27 12:58:44   1.0.2.8.0       1481.98
     2021-10-27 12:55:35   Version         ?!
     2021-10-27 12:54:25   state           opened
   helper:
     BUFFER     
     EoM        1
     LastPacketTime 1635332324.31737
     SPEED      0
     SPEED2     0
     TRIGGERTIME 1635332065.95239
     Channels:
     DEVICES:
       /?!

       150
       000

     RULECACHE:
       1-0:1.8.0  unknown
       1-0:1.8.1  unknown
       1-0:1.8.2  unknown
       1-0:1.8.3  unknown
       1-0:1.8.4  unknown
       1-0:2.8.0  unknown
Attributes:
   interval   150
   pollingMode on
   room       E,HWR,Haus
   unitReadings off
   verbose    5
 

und hier ein log-AUszug mit verbose=5:

Code Auswählen Erweitern

2021.10.27 12:56:03 5: OBIS (E_Zaehler) - Internal timer set to 2021-10-27 12:58:33
2021.10.27 12:56:03 5: OBIS (E_Zaehler) - Msg-Parse: /?!
2021.10.27 12:56:03 5: DevIo_SimpleWrite E_Zaehler: 063030300d0a
2021.10.27 12:56:03 5: OBIS (E_Zaehler) - Msg-Parse: 000
2021.10.27 12:56:09 5: OBIS (E_Zaehler) - Msg-Parse: -nU*%kE7Bk
Bk&$jRJ2r
sB:;J*J
Jk&jRJ2r
s
C
#K*"5::J*J
Jk&jRJ:sJ:sBJk&kRrJr
C
+2Kk&kRrJrC;Kk&kR
s:sB
s*J*R[W)
2021.10.27 12:56:09 5: OBIS (E_Zaehler) - Msg-Parse: 1-0:1.8.0(004468.75*kWh)
2021.10.27 12:56:10 5: OBIS (E_Zaehler) - Msg-Parse: 1-0:1.8.1(004468.75*kWh)
2021.10.27 12:56:11 5: OBIS (E_Zaehler) - Msg-Parse: 1-0:1.8.2(000000.00*kWh)
2021.10.27 12:56:12 5: OBIS (E_Zaehler) - Msg-Parse: 1-0:1.8.3(000000.00*kWh)
2021.10.27 12:56:13 5: OBIS (E_Zaehler) - Msg-Parse: 1-0:1.8.4(000000.00*kWh)
2021.10.27 12:56:14 5: OBIS (E_Zaehler) - Msg-Parse: 1-0:2.8.0(001481.98*kWh)
2021.10.27 12:56:14 5: OBIS (E_Zaehler) - Msg-Parse: !


[gvzdus]

Moin, ich habe mich jetzt etwas in den Code versenkt. Ich selber gehöre zu den Glücklichen mit einem Zähler, der ohne Initialisierung und insbesondere ohne 300/9600 Baud-Umschaltung fröhlich vor sich hin plappert...

An die Allgemeinheit:
Gibt es jemanden, der 47_OBIS

• Mit Initialisierung
• Mit Speed-Umschaltung

nutzt?

Deine Zeile "602" kann ich nicht zuordnen. Ich hätte keine Probleme damit, die Definition "MT382" hinzuzunehmen - aber "sleep" ist wirklich megahäßlich in FHEM - da bleibt tatsächlich alles 1 Sekunde stehen. Selbst speziell für den MT382 würde ich das gerne verstehen. Du kannst auch einfach Deinen "kompletten" Code hier als Anhang ranhängen.

Zum MT382 finde ich keine (Detail)-Doku, aber für den MT171 beschreiben die Kollegen von volkszaehler.org, dass er eben von 300 Baud auf 9600 hochgeschaltet werden kann.

Noch eine Frage: Hast Du mal "interval" und "pollmode" entfernt und geguckt, wie sich der Zähler "im Dauerbetrieb" macht?

[alkazaa]

Moin, und danke für die Rückmeldung.

Deine Zeile "602" kann ich nicht zuordnen. Ich hätte keine Probleme damit, die Definition "MT382" hinzuzunehmen - aber "sleep" ist wirklich megahäßlich in FHEM - da bleibt tatsächlich alles 1 Sekunde stehen. Selbst speziell für den MT382 würde ich das gerne verstehen.

Dass sleep() irgendwie häßlich ist, ist mir auch klar. Auf die Idee, vor dem Senden des ACK noch etwas zu warten, war ich durch den Beitrag https://wiki.volkszaehler.org/hardware/channels/meters/power/edl-ehz/iskraemeco_mt372 gekommen, in dem empfohlen wird, vor dem ACK diverse NUL characters zu senden (Ich hab vom MT372 fröhlich auf das MT382 verallgemeinert). Das mit den NUL's hab ich auch probiert, ging auch irgendwie, aber selbst bei acht NUL's noch nicht reproduzierbar. Da hab ich halt das brutale sleep() genommen. Habe auch versucht, mit usleep() die Zeit zu optimieren, es ging aber erst ab 900 msec, und deshalb habe ich dann gleich 1 sec genommen.

Du kannst auch einfach Deinen "kompletten" Code hier als Anhang ranhängen.

Hängt an... (hab Änderungen mit alkazaa kommentiert)

Zum MT382 finde ich keine (Detail)-Doku, aber für den MT171 beschreiben die Kollegen von volkszaehler.org, dass er eben von 300 Baud auf 9600 hochgeschaltet werden kann.

Manual des MT382 hänge ich ebenfalls an. Laut Angaben auf S. 83 sollte Baudumschaltung funktionieren.

Noch eine Frage: Hast Du mal "interval" und "pollmode" entfernt und geguckt, wie sich der Zähler "im Dauerbetrieb" macht?

Werde ich testen und rückmelden.

Danke und beste Grüße
Franz

[gvzdus]

Moin, danke für die ausführlichen Rückmeldungen!
Okay, den Sinn verstehe ich jetzt. Ich kann das übernehmen, der Typ ist ja eh "Deine" Erfindung - insofern wird es niemanden stören, aber Dir helfen.
Da ich aber keine Chance habe, das "Ping-Pong" und die Umschaltung des Speeds zu testen, kann ich da nichts weiterentwickeln.
Mein Raspi / FHEM hat eine Fülle von Steueraufgaben, für mich wäre ein regelmäßiger 1-Sekunden-Freeze nicht akzeptabel - aber das kann ja bei Dir anders sein. Falls FHEM noch mehr bei Dir machen soll, würde ich über vzlogger und die MQTT-Anbindung nachdenken, insbesondere, falls ein "Nicht-Polling" bei Dir nicht funktioniert, also die Pause regelmäßig sein muss.

[alkazaa]

Moin!
Ich habe jetzt die unschöne Sache mit dem "sleep 1" wieder komplett entfernt. Es geht jetzt aber trotzdem (einigermaßen), weil ich die zusätzlichen NUL characters vor dem ACK (=chr(6)) in der device definitions-Tabelle wieder eingefügt habe. Dass das beim ersten Versuch nicht reproduzierbar ging, lag vielleicht daran, dass ich im Putty Terminal mit "tail -f /opt/fhem/log/fhem-2021-10.log" in Echtzeit die log Datei überwachen wollte. 
(Das obige "einigermaßen" bezieht sich darauf, dass der als 1. response kommende Gerätetyp immer noch z.T. verstümmelt kommt. Aber der ist mir nicht wichtig.)

Also ist jetzt meine einzige Änderung an der 47_OBIS.pm die Zeile

Code Auswählen Erweitern

"MT382" => ["/?!".chr(13).chr(10),    600,    chr(0).chr(0).chr(0).chr(0).chr(0).chr(0).chr(6)."0".$hash->{helper}{SPEED}."0".chr(13).chr(10)],#this line added by alkazaa in der "my %devs=..." Definitionstabelle. (Die Zeile kann man vielleicht eleganter schreiben...)


Zu Deiner Frage an die Allgemeinheit

An die Allgemeinheit:
Gibt es jemanden, der 47_OBIS

• Mit Speed-Umschaltung

nutzt?

vermute ich, dass da wenig kommen wird: ich hab mal in diesem thread nach dem Stichwort 'umschaltung' gesucht, und dabei nur Teil-Diskussionen gefunden, die mehr oder weniger im Sande verliefen. Scheint also noch niemand wirklich zu nutzen.

Ich werde aber mal weiter rumprobieren...

[gvzdus]

Hi, ist so erst einmal eingecheckt, also ab morgen vormittag dann offiziell per Update.

[alkazaa]

Moin!
Ich schrieb:

Ich werde aber mal weiter rumprobieren...  (an der Baudumschaltung)

Die gute Nachricht: ich habe es nun irgendwie hinbekommen.

Die weniger gute ist das irgendwie:

   
• ich habe nicht die 47_OBIS.pm aus dem SVN genommen, sondern eine per PN von Icinger erhaltene Experimentalversion (hänge ich hier nochmal an)
• auch mit der Version klappt die Umschaltung nur genau einmal, und zwar direkt nach dem define des Gerätes
• damit es regelmäßig funktioniert, habe ich als workaround ein at eingesetzt, das vor jedem get ein defmod durchführt (das hatte Icinger in Beitrag #907 dieses threads bereits erwähnt, es ist aber anscheinend nicht in der per PN gesendeten Version implementiert, daher das at)
• die vom Modul gelieferten readings heißen z.B. nicht 1.0.1.8.0, sondern 1.0:1.8.0 (der Doppelpunkt wird beim Start von FHEM angemeckert, es funktioniert aber trotzdem)
• interessanterweise ist das Senden mehrerer NUL characters vor den ACK nicht erforderlich!
• Langzeitstabilitätstest läuft noch

Die experimentelle Icinger-Version mit der aktuellen zusammenzuführen dürfte für mich mangels Perl Kenntnissen fast unmöglich sein, da die Struktur der beiden Versionen sehr unterschiedlich aussieht.

Aber vielleicht erbarmt sich jemand...

Code Auswählen Erweitern

Internals:
   DEF        /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A9078004-if00-port0@300,7,E,1 VSM102 9600
   DeviceName /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A9078004-if00-port0@9600,7,E,1
   FD         19
   FUUID      617c6140-f33f-a50b-098c-eb709092f2f27ef3
   MeterType  VSM102
   NAME       E_Zaehler
   NR         136
   PARTIAL   
   STATE      opened
   TYPE       OBIS
   Helper:
     DBLOG:
       feed_280:
         logdb:
           TIME       1635587330.90736
           VALUE      1488.11
       feed_L1:
         logdb:
           TIME       1635587330.74844
           VALUE      0.00
       power:
         logdb:
           TIME       1635587330.74844
           VALUE      1.813
       power_2:
         logdb:
           TIME       1635587330.76355
           VALUE      0.480000000010477
   OLDREADINGS:
     2021-10-30 11:46:20   1.0:1.8.0       4499.98
   READINGS:
     2021-10-30 11:48:50   0.0:96.1.1      3149534B30303737303935393133
     2021-10-30 11:48:50   0.0:97.97.0     0
     2021-10-30 11:48:50   1.0:0.9.1       114848
     2021-10-30 11:48:50   1.0:0.9.2       211030
     2021-10-30 11:48:50   1.0:1.8.0       4500
     2021-10-30 11:48:50   1.0:1.8.1       4500
     2021-10-30 11:48:50   1.0:1.8.2       0
     2021-10-30 11:48:50   1.0:1.8.3       0
     2021-10-30 11:48:50   1.0:1.8.4       0
     2021-10-30 11:48:50   1.0:2.8.0       1488.11
     2021-10-30 10:42:35   Version         ISK
     2021-10-30 11:48:50   feed_280        1488.11
     2021-10-30 11:48:50   feed_L1         0.00
     2021-10-30 11:48:50   power           1.813
     2021-10-30 11:48:50   power_2         0.480000000010477
     2021-10-30 11:48:50   state           opened
   helper:
     BUFFER     
     DEV1       /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A9078004-if00-port0@300,7,E,1
     DEV2       /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A9078004-if00-port0@9600,7,E,1
     EoM        1
     SPEED      5
     SPEED1     0
     TRIGGERTIME 1635587329.10676
     Channels:
     DEVICES:
       /?!
       600
       050
Attributes:
   DbLogInclude (power|power_2|feed_280|feed_L1)
   oldreadings .*1.8.0, .*2.8.0
   pollingMode on
   room       E,HWR,Haus
   unitReadings off
   userReadings feed_L1:power.* {my $a=0.0; if (ReadingsVal("PVAnlage","AC_Power",0.0) > 0.0 and ReadingsVal($NAME,"power",0.01) <= 0.0) {$a = 3600.0 * (ReadingsVal($NAME,"1.0:2.8.0",0.0)-OldReadingsVal($NAME,"1.0:2.8.0",0.0))/(time -time_str2num(OldReadingsTimestamp($NAME,"1.0:2.8.0",0.0)))};
sprintf "%.2f", $a
},
power_2:1.0:1.8.0.* {3600.0 * (ReadingsVal($NAME,"1.0:1.8.0",0.0)-OldReadingsVal($NAME,"1.0:1.8.0",0.0))/(time -time_str2num(OldReadingsTimestamp($NAME,"1.0:1.8.0",0.0)))},
feed_280:1.0:2.8.0.* {ReadingsVal("E_Zaehler","1.0:2.8.0",0.0)}

   verbose    3

Code Auswählen Erweitern

Internals:
   COMMAND    defmod E_Zaehler OBIS /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A9078004-if00-port0@300,7,E,1 VSM102 9600 ; get E_Zaehler update
   DEF        +*00:02:30 defmod E_Zaehler OBIS /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A9078004-if00-port0@300,7,E,1 VSM102 9600 ; get E_Zaehler update
   FUUID      617d066a-f33f-a50b-6904-6191f256ebbc2a8d
   NAME       E_Zaehler_Read
   NR         137
   NTM        11:53:49
   PERIODIC   yes
   RELATIVE   yes
   REP        -1
   STATE      Next: 11:53:49
   TIMESPEC   00:02:30
   TRIGGERTIME 1635587629.09939
   TRIGGERTIME_FMT 2021-10-30 11:53:49
   TYPE       at
   READINGS:
     2021-10-30 11:51:19   state           Next: 11:53:49
Attributes:
   disable    0

[alkazaa]

Moin!
Ich schrieb:

Ich werde aber mal weiter rumprobieren...  (an der Baudumschaltung)

Die gute Nachricht: ich habe es nun irgendwie hinbekommen.      Die weniger gute ist das irgendwie:

Das 'irgendwie' kann ich nun etwas genauer angeben:

   
• ich habe nicht die 47_OBIS.pm aus dem SVN genommen, sondern eine per PN von Icinger erhaltene Experimentalversion (hänge ich hier nochmal an)
• auch mit der Version klappt die Umschaltung nur genau einmal, und zwar direkt nach dem define des Gerätes --> stimmt nicht, hab meinen Fehler gefunden
• damit es regelmäßig funktioniert, habe ich als workaround ein at eingesetzt, das vor jedem get ein defmod durchführt (das hatte Icinger in Beitrag #907 dieses threads bereits erwähnt, es ist aber anscheinend nicht in der per PN gesendeten Version implementiert, daher das at) --> ist natürlich nun nicht mehr nötig
• die vom Modul gelieferten readings heißen z.B. nicht 1.0.1.8.0, sondern 1.0:1.8.0 (der Doppelpunkt wird beim Start von FHEM angemeckert, es funktioniert aber trotzdem)
• interessanterweise ist das Senden mehrerer NUL characters vor den ACK nicht erforderlich!
• Langzeitstabilitätstest läuft noch --> scheint stabil zu laufen, wenn man nicht (wie ich zuletzt) ständig unterqualifiziert am source code herumfummelt
• das attribut interval gibt es bei der Experimentalversion nicht; man muss es in der device-Definitionsliste im source code eintragen

Die SVN Version von 47_OBIS.pm kann die Speedumschaltung nicht, da dort eine subroutine speedchange() nicht definiert ist. In der Experimentalversion wird speedchange() zweimal in der subroutine Parse() aufgerufen.

Ich trau mir momentan noch nicht zu, die Versionen unfallfrei zusammenzuführen.
Des ist meine device Definition:

Code Auswählen Erweitern

defmod E_Zaehler OBIS /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A9078004-if00-port0@300,7,E,1 MT382 9600

Beste Grüße
Franz

[gvzdus]

Puh, da war Icinger aber weit weg von der Version, auf der ich gearbeitet habe!
Ich bin über ein paar Fragmente gestolpert, die wohl nie so recht funktioniert haben. In Deiner Version ergibt es Sinn. Ich habe mit einem Merge angefangen. Die Parametrisierung mit den Attributen "init1" und "init2" werde ich aber z.B. nicht unterstützen. Und: Da kommt viel Testing auf Dich zu, wenn Du dran bleiben möchtest