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

alkazaa · 03 November 2021, 08:54:37

Zitat von: gvzdus am 02 November 2021, 21:17:48
Puh, da war Icinger aber weit weg von der Version, auf der ich gearbeitet habe!....Ich habe mit einem Merge angefangen. ...Da kommt viel Testing auf Dich zu, wenn Du dran bleiben möchtest

Super! und vielen Dank!
Und natürlich bleibe ich dran.

-Franz

cwagner · 11 November 2021, 18:12:38

[gelöst mit Patch aus folgender Nachricht] Vielen Dank für dieses wertvolle Modul, mit dem ich nun seit Monaten sowohl den Strombezug wie auch die Solar-Erzeugung logge. Allerdings spuckt mir die Solarerzeugung jetzt in der dunklen Jahreszeit ordentlich in meine Suppe der Eigenverbrauchsoptimierung. Bei Dunkelheit liefert die Solarmodule natürlich 0 W. Aber der Stringwechselrichter hat einen Eigenverbrauch und tankt alle paar Sekunden laut Display des digitalen Zählers kurzzeitig 3 W, dargestellt als -3W.

Im Reading Power würde ich nun -3 erwarten (oder 3W ohne Vorzeichen), nichts da: ich kriege irrsinnige 652.29 (manchmal .48)

Code Auswählen

2021.11.11 17:39:25 5: OBIS (Solar) - Msg-Parse: /
2021.11.11 17:39:25 5: OBIS (Solar) - Msg-Parse: 1-0:96.50.1*1(DZG*var)
2021.11.11 17:39:25 5: OBIS (Solar) - Msg 1-0:96.50.1*1(DZG*var) is of type ManufID2
2021.11.11 17:39:25 5: OBIS (Solar) - Msg-Parse: 1-0:96.1.0*255(
DZG*var)
2021.11.11 17:39:25 5: OBIS (Solar) - Msg-Parse: 1-0:1.8.0*255(>2939113.7*Wh)
2021.11.11 17:39:25 5: OBIS (Solar) - Msg 1-0:1.8.0*255(>2939113.7*Wh) is of type Counter
2021.11.11 17:39:25 4: OBIS (Solar) - Set total_consumption to 2939113.7
2021.11.11 17:39:25 5: OBIS (Solar) - Msg-Parse: 1-0:2.8.0*255(13314.4*Wh)
2021.11.11 17:39:25 5: OBIS (Solar) - Msg 1-0:2.8.0*255(13314.4*Wh) is of type Counter
2021.11.11 17:39:25 5: OBIS (Solar) - Msg-Parse: 1-0:16.7.0*255(0*W)
2021.11.11 17:39:25 5: OBIS (Solar) - Msg 1-0:16.7.0*255(0*W) is of type Channels
2021.11.11 17:39:25 5: OBIS (Solar) - Msg-Parse: !
2021.11.11 17:39:26 5: OBIS (Solar) - SML-Parse 1B1B1B1B010101017605900C7008620062007263010176010102310B0A01445A470003969F7F7262016502D007FA620263BF79007605910C7008620062007263070177010B0A01445A470003969F7F070100620AFFFF7262016502D007FA7577070100603201010172620162006200520004445A470177070100600100FF017262016200620052000B0A01445A470003969F7F0177070100010800FF641C18047262016200621E52FF6501C079210177070100020800FF017262016200621E52FF640208180177070100100700FF017262016200621B52FE53FECD010101638B2D007605920C70086200620072630201710163B85B0000001B1B1B1B1A02B11E
2021.11.11 17:39:26 5: OBIS (Solar) - Full message-> 1B1B1B1B010101017605900C7008620062007263010176010102310B0A01445A470003969F7F7262016502D007FA620263BF79007605910C7008620062007263070177010B0A01445A470003969F7F070100620AFFFF7262016502D007FA7577070100603201010172620162006200520004445A470177070100600100FF017262016200620052000B0A01445A470003969F7F0177070100010800FF641C18047262016200621E52FF6501C079210177070100020800FF017262016200621E52FF640208180177070100100700FF017262016200621B52FE53FECD010101638B2D007605920C70086200620072630201710163B85B0000001B1B1B1B1A02B11E
2021.11.11 17:39:26 4: OBIS (Solar) - MSG IS: 
/
1-0:96.50.1*1(DZG*var)
1-0:96.1.0*255(
DZG*var)
1-0:1.8.0*255(<2939113.7*Wh)
1-0:2.8.0*255(13314.4*Wh)
1-0:16.7.0*255(652.29*W)
!

2021.11.11 17:39:26 5: OBIS (Solar) - Msg-Parse: /
2021.11.11 17:39:26 5: OBIS (Solar) - Msg-Parse: 1-0:96.50.1*1(DZG*var)
2021.11.11 17:39:26 5: OBIS (Solar) - Msg 1-0:96.50.1*1(DZG*var) is of type ManufID2
2021.11.11 17:39:26 5: OBIS (Solar) - Msg-Parse: 1-0:96.1.0*255(
DZG*var)
2021.11.11 17:39:26 5: OBIS (Solar) - Msg-Parse: 1-0:1.8.0*255(<2939113.7*Wh)
2021.11.11 17:39:26 5: OBIS (Solar) - Msg 1-0:1.8.0*255(<2939113.7*Wh) is of type Counter
2021.11.11 17:39:26 4: OBIS (Solar) - Set total_consumption to 2939113.7
2021.11.11 17:39:26 5: OBIS (Solar) - Msg-Parse: 1-0:2.8.0*255(13314.4*Wh)
2021.11.11 17:39:26 5: OBIS (Solar) - Msg 1-0:2.8.0*255(13314.4*Wh) is of type Counter
2021.11.11 17:39:26 5: OBIS (Solar) - Msg-Parse: 1-0:16.7.0*255(652.29*W)
2021.11.11 17:39:26 5: OBIS (Solar) - Msg 1-0:16.7.0*255(652.29*W) is of type Channels
2021.11.11 17:39:26 5: OBIS (Solar) - Msg-Parse: !
2021.11.11 17:39:27 5: OBIS (Solar) - SML-Parse 1B1B1B1B010101017605930C7008620062007263010176010102310B0A01445A470003969F7F7262016502D007FB6202632AD4007605940C7008620062007263070177010B0A01445A470003969F7F070100620AFFFF7262016502D007FB7577070100603201010172620162006200520004445A470177070100600100FF017262016200620052000B0A01445A470003969F7F0177070100010800FF641C18047262016200621E52FF6501C079210177070100020800FF017262016200621E52FF640208180177070100100700FF017262016200621B52FE53FEBD010101635D5B007605950C700862006200726302017101633F2B0000001B1B1B1B1A020FC5
2021.11.11 17:39:27 5: OBIS (Solar) - Full message-> 1B1B1B1B010101017605930C7008620062007263010176010102310B0A01445A470003969F7F7262016502D007FB6202632AD4007605940C7008620062007263070177010B0A01445A470003969F7F070100620AFFFF7262016502D007FB7577070100603201010172620162006200520004445A470177070100600100FF017262016200620052000B0A01445A470003969F7F0177070100010800FF641C18047262016200621E52FF6501C079210177070100020800FF017262016200621E52FF640208180177070100100700FF017262016200621B52FE53FEBD010101635D5B007605950C700862006200726302017101633F2B0000001B1B1B1B1A020FC5
2021.11.11 17:39:27 4: OBIS (Solar) - MSG IS: 
/
1-0:96.50.1*1(DZG*var)
1-0:96.1.0*255(
DZG*var)
1-0:1.8.0*255(<2939113.7*Wh)
1-0:2.8.0*255(13314.4*Wh)
1-0:16.7.0*255(652.13*W)
!

Was mache ich falsch/was läuft falsch? Hat jemand eine hilfreiche Idee?

Vielen Dank fürs Hirnen schon im Voraus!

Christian

gvzdus · 11 November 2021, 21:48:51

Erstmal vorab: Ich habe es "per Hand" dekodiert:

Du findest die Sequenz in Deinem "Full-Message":

Code Auswählen

# We should have now an 7 element array: reading(0), status(1), valTime(2), unit(3), scaler(4), data(5)
070100100700FF = reading 1.0.16.7.0.255
01             = status
72             = valtime
 6201
 6200
621B           = unit, 1B = Watt
52FE           = scaler = -2
53FECD         = data = 65229 in unsigned, -7 in signed => eigentlich -0,07 W
01
01
01

Wie Du siehst (oder nach dem Einlesen in das Kodieren nachvollziehen kannst): Eigentlich kommt super-sauber da -0,07 W raus aus der ersten Zeile. Nun gibt es aber einen ekeligen Bug in DZG-Zählern: Sie haben fälschlich unsigned als signed kodiert. Dafür gibt es im Code einen Hack, den DZG-Hack. Du findest ihn hier im Code:

Code Auswählen

      if ($tltype==0x50 && $len<4 && $isobis && $cntdown==2 && $result[0]=~/^1-0:16\.7\.0/ && $hash->{helper}{DZGHACK}) {
                $tltype = 0x60;
      }

Genau diese Stelle scheint sich bei Dir zu rächen: Weil es ein DZG-Zähler ist, der "signed" sagt, eine kurze Länge hat (< 4), es um das Werte-Feld und OBIS-Zahl 1.0.16.7.0 geht ("if"-Statement in Worten), macht der Code aus dem int ein unsigned int und damit die hohe Zahl.

Den Hack habe ich vor 1-2 Jahren eingebaut, findest Du früher hier im Thread. Vorschlag: Kommentiere diese 3 Zeilen mal aus, und gucke, ob Du damit definitiv glücklicher bist. (FHEM neu starten o.ä. ist natürlich nötig, damit das Auskommentieren oder Löschen wirksam wird). Sollte DZG Zähler in Umlauf gesetzt haben, die den Bug nicht mehr haben, dann würde ich den Hack nicht fest verdrahten, sondern "wegkonfigurierbar" machen.

Also: Schuld ist ein alter Fehler in den DZG-Zählern. Vielleicht ist er inzwischen behoben.

cwagner · 11 November 2021, 22:55:19

Zitat von: gvzdus am 11 November 2021, 21:48:51
Dafür gibt es im Code einen Hack, den DZG-Hack. Du findest ihn hier im Code:

Code Auswählen Erweitern
if ($tltype==0x50 && $len<4 && $isobis && $cntdown==2 && $result[0]=~/^1-0:16\.7\.0/ && $hash->{helper}{DZGHACK}) { $tltype = 0x60; }

Genau diese Stelle scheint sich bei Dir zu rächen: Weil es ein DZG-Zähler ist, der "signed" sagt, eine kurze Länge hat (< 4), es um das Werte-Feld und OBIS-Zahl 1.0.16.7.0 geht ("if"-Statement in Worten), macht der Code aus dem int ein unsigned int und damit die hohe Zahl.

Vielen Dank für diesen schnellen, kompetenten Hinweis: Funktioniert bei mir jetzt seit einer halben Stunde

Obis decodiert die "Selbstvorstellung" des Zählers: ManufID2 DZG*var

Christian

gvzdus · 11 November 2021, 23:44:36

Wenn Du mir einen Gefallen tun magst: Such' doch mal hier in diesem Thread mit der Suche nach "dem anderen" DZG-Nutzer! Der hat das Problem, der hatte den Patch für vzlogger rausgesucht, und hat ihn dann mir geschickt und ich habe es eingebaut. Wenn man irgendwie automatisch zwischen "kaputt" und "heile" unterscheiden kann (indem Ihr vergleicht: Mein Zähler sagt X, Deiner Y), wäre es natürlich am besten. Die ganz saubere Welt wäre natürlich, DZG anzuschreiben und zu sagen: "Sagt mal: Wie kriegt man am besten Euren Bug von damals gefixt?".

Ich versuch' nur, möglichst viele Leute glücklich zu machen...

karpate · 25 November 2021, 08:20:01

Hallo,

ich habe gestern ein Update auf die Version von
47_OBIS.pm 25147 2021-10-29 15:14:14Z gvzdus
gemacht.
Seit dem wird beim Zählerstand ein Richtungszeichen vorangestellt (1.8.0_Verbrauch >11270024.3). Das hat natürlich zur Folge das das Stateformat nicht berechnet werden kann und der ElectricityCalculator so ebenfalls nicht rechnen kann.
Ist es möglich das Richtungszeichen aus dem Reading "1.8.0_Verbrauch" wieder zu entfernen oder mus sich über ein Userreading gehen?
Danke

Code Auswählen

Internals:
   DEF        /dev/ttyUSB0@9600,8,N,1 SML
   DeviceName /dev/ttyUSB0@9600,8,N,1
   FD         9
   FUUID      61274e18-f33f-bd3b-9521-a0d3f514cac0ad18
   MeterType  SML
   NAME       ITR_Stromzaehler
   NR         20
   PARTIAL    
   STATE      Aktuell: 312.0 W, Verbrauch: 0 kWh seit 25.11., 08:15.
   TYPE       OBIS
   READINGS:
     2021-11-25 08:15:49   1.8.0_Verbrauch >11269431.8
     2021-11-25 08:15:49   2.8.0_Einspeisung 0
     2021-11-25 08:15:49   ManufID2        ITR
     2021-11-25 08:15:49   power           312
     2021-11-24 20:02:19   state           opened
   helper:
     BUFFER     
     DIRECTIONSUM >
     EoM        1
     LastPacketTime 1637824549.91025
     SPEED      5
     SPEED2     5
     TRIGGERTIME 1637780539.29366
     Channels:
       1-0:1.8.0*255 1.8.0_Verbrauch
       1-0:2.8.0*255 2.8.0_Einspeisung
     DEVICES:
       
       10
       
     RULECACHE:
       1-0:16.7.0*255 Channels
       1-0:96.50.1*1 ManufID2
     directions:
       <          pwr feeding
       >          pwr consuming
Attributes:
   channels   {"1-0:2.8.0*255"=>"2.8.0_Einspeisung","1-0:1.8.0*255"=>"1.8.0_Verbrauch"}
   interval   10
   pollingMode on
   room       Stromzähler
   stateFormat { sprintf "Aktuell: %.1f W, Verbrauch: %i kWh seit %s.",ReadingsVal($name,"power",0),ReadingsVal($name,"1.8.0_Verbrauch",0)/1000,POSIX::strftime("%-d.%-m., %H:%M",localtime(time_str2num(ReadingsTimestamp($name,"energyOffset",0)))); }

Edit:
Laut commandref habe ich nun das Attribut "directions" eingefügt. Dieses erzeugt auch die beiden Readings "total_consumption" und "total_feed". Allerdings wird "total_consumption" nicht in dem gleichen Intervall (=10s) aktualisiert wie z.B. "power" oder "1.8.0_Verbrauch". Bisher wurde es nicht mehr aktualisiert...
Jemand einen Tipp?

Code Auswählen

Internals:
   DEF        /dev/ttyUSB0@9600,8,N,1 SML
   DeviceName /dev/ttyUSB0@9600,8,N,1
   FD         9
   FUUID      61274e18-f33f-bd3b-9521-a0d3f514cac0ad18
   MeterType  SML
   NAME       ITR_Stromzaehler
   NR         20
   PARTIAL    
   STATE      Aktuell: 313.0 W, Verbrauch: 11269 kWh seit 25.11., 09:51.
   TYPE       OBIS
   READINGS:
     2021-11-25 09:51:44   1.8.0_Verbrauch >11270024.3
     2021-11-25 09:51:44   2.8.0_Einspeisung 0
     2021-11-25 09:51:44   ManufID2        ITR
     2021-11-25 09:51:44   power           313
     2021-11-24 20:02:19   state           opened
     2021-11-25 09:18:21   total_consumption 11269811
     2021-11-25 09:18:21   total_feed      0
   helper:
     BUFFER     v	J���
     DIRECTIONSUM >
     EoM        -1
     LastPacketTime 1637830304.93766
     SPEED      5
     SPEED2     5
     TRIGGERTIME 1637780539.29366
     directions pwr feeding
     Channels:
       1-0:1.8.0*255 1.8.0_Verbrauch
       1-0:2.8.0*255 2.8.0_Einspeisung
     DEVICES:
       
       10
       
     RULECACHE:
       1-0:1.8.0*255 Counter
       1-0:16.7.0*255 Channels
       1-0:2.8.0*255 Counter
       1-0:96.50.1*1 ManufID2
Attributes:
   channels   {"1-0:2.8.0*255"=>"2.8.0_Einspeisung","1-0:1.8.0*255"=>"1.8.0_Verbrauch"}
   directions ">" => "pwr consuming", "<"=>"pwr feeding"
   interval   10
   pollingMode on
   room       Stromzähler
   stateFormat { sprintf "Aktuell: %.1f W, Verbrauch: %i kWh seit %s.",ReadingsVal($name,"power",0),ReadingsVal($name,"total_consumption",0)/1000,POSIX::strftime("%-d.%-m., %H:%M",localtime(time_str2num(ReadingsTimestamp($name,"energyOffset",0)))); }

Edit2:
habe wieder auf diese Version downgraded, damit wird dem Zählerstand kein Richtungszeichen vorangestellt.
47_OBIS.pm 24225 2021-04-12 11:37:25Z gvzdus

gvzdus · 26 November 2021, 10:54:02

Hi, sorry, dass es kaputt gegangen ist!
Du findest auf Seite 88 um den 1. September den Grund für die Änderung. Ich hatte damals mit meinem ISKRA-Zähler die Änderung getestet, und bei mir war alles okay.

Ich denke, dass man das Fixen kann (und werde es tun). Könntest Du Dein OBIS-Device bitte kurz auf Loglevel 5 stellen und mir eine Log-Zeile mit "Full-Message" schicken, in der "total_consumption" übermittelt wird? Dann kann ich Deine Situation debuggen.

Du findest Backups der Vorversion übrigens immer unter /opt/fhem/restoreDir - von da kannst Du danach die Ursprungsversion, die noch lief, erst einmal zurück kopieren.

karpate · 26 November 2021, 12:04:33

Hi, kein Problem. Habe wie du beschreibst die Vorgängerversion wiederhergestellt.

Hier das Verbose 5 Log und die Full message.

Danke und Gruß

Code Auswählen

2021.11.26 12:02:07 5: DevIo_SimpleWrite ITR_Stromzaehler: 
2021.11.26 12:02:07 4: OBIS (ITR_Stromzaehler) - Wrote 
2021.11.26 12:02:07 5: OBIS (ITR_Stromzaehler) - Internal timer set to 2021-11-26 12:02:17
2021.11.26 12:02:08 5: OBIS (ITR_Stromzaehler) - SML-Parse 1B1B1B1B0101010176094AAF100402E21EE26200620072650000010176010109000000000506B9950B0A01495452000349F040726201650506BA4F0163E9CF0076094AAF100402E21EE36200620072650000070177010B0A01495452000349F040070100620AFFFF726201650506BA4F75770701006032010101010101044954520177070100600100FF010101010B0A01495452000349F0400177070100010800FF65001C010401621E52FF690000000006B9BD400177070100020800FF0101621E52FF6900000000000000000177070100100700FF0101621B52005500000E0E01010163B2690076094AAF100402E21EE462006200726500000201710163A4CE0000001B1B1B1B1A028700
2021.11.26 12:02:08 5: OBIS (ITR_Stromzaehler) - Full message-> 1B1B1B1B0101010176094AAF100402E21EE26200620072650000010176010109000000000506B9950B0A01495452000349F040726201650506BA4F0163E9CF0076094AAF100402E21EE36200620072650000070177010B0A01495452000349F040070100620AFFFF726201650506BA4F75770701006032010101010101044954520177070100600100FF010101010B0A01495452000349F0400177070100010800FF65001C010401621E52FF690000000006B9BD400177070100020800FF0101621E52FF6900000000000000000177070100100700FF0101621B52005500000E0E01010163B2690076094AAF100402E21EE462006200726500000201710163A4CE0000001B1B1B1B1A028700
2021.11.26 12:02:08 4: OBIS (ITR_Stromzaehler) - MSG IS: 
/
1-0:96.50.1*1(ITR)
1-0:96.1.0*255(
ITRI@)
1-0:1.8.0*255(11283590.4*Wh)
1-0:2.8.0*255(0*Wh)
1-0:16.7.0*255(3598*W)
!

2021.11.26 12:02:08 5: OBIS (ITR_Stromzaehler) - Msg-Parse: /
2021.11.26 12:02:08 5: OBIS (ITR_Stromzaehler) - Msg-Parse: 1-0:96.50.1*1(ITR)
2021.11.26 12:02:08 5: OBIS (ITR_Stromzaehler) - Msg 1-0:96.50.1*1(ITR) is of type ManufID2
2021.11.26 12:02:08 5: OBIS (ITR_Stromzaehler) - Msg-Parse: 1-0:96.1.0*255(
ITRI@)
2021.11.26 12:02:08 5: OBIS (ITR_Stromzaehler) - Msg-Parse: 1-0:1.8.0*255(11283590.4*Wh)
2021.11.26 12:02:08 5: OBIS (ITR_Stromzaehler) - Msg-Parse: 1-0:2.8.0*255(0*Wh)
2021.11.26 12:02:08 5: OBIS (ITR_Stromzaehler) - Msg-Parse: 1-0:16.7.0*255(3598*W)
2021.11.26 12:02:08 5: OBIS (ITR_Stromzaehler) - Msg 1-0:16.7.0*255(3598*W) is of type Channels
2021.11.26 12:02:08 5: OBIS (ITR_Stromzaehler) - Msg-Parse: !

gvzdus · 26 November 2021, 14:36:53

Hmmh. Bei mir erscheint mit Deinen Daten die Zeile total_consumption (das ist 1.8.0) ohne ">".
Könntest Du bitte einmal probieren, was ohne Dein "channels" kommt? Also, wenn es der "Default-Name" "total_consumption" ist?

Der pollmode mit 10 Sekunden ist nicht wirklich optimal: Da nicht immer alle Werte gesendet werden, könnte es sein, dass Dir da Werte, die sich nicht mit jedem Paket ändern, durch die Lappen gehen.

Ich bin jetzt das Wochenende erst mal weg vom Rechner...

karpate · 26 November 2021, 15:39:23

wünsche schönes Wochenende

welches Interval wäre zu empfehlen?

Da habe ich nicht mitgedacht, das Verbose Log5 jetzt von der aktuellen 47_OBIS.pm Version

Code Auswählen

2021.11.26 15:32:50 5: DevIo_SimpleWrite ITR_Stromzaehler: 
2021.11.26 15:32:50 4: OBIS (ITR_Stromzaehler) - Wrote 
2021.11.26 15:32:50 5: OBIS (ITR_Stromzaehler) - Internal timer set to 2021-11-26 15:33:00
2021.11.26 15:32:51 5: OBIS (ITR_Stromzaehler) - SML-Parse 1B1B1B1B0101010176094AAF100402E2B30B6200620072650000010176010109000000000506EAF80B0A01495452000349F040726201650506EBB20163073B0076094AAF100402E2B30C6200620072650000070177010B0A01495452000349F040070100620AFFFF726201650506EBB275770701006032010101010101044954520177070100600100FF010101010B0A01495452000349F0400177070100010800FF65001C010401621E52FF690000000006BA404D0177070100020800FF0101621E52FF6900000000000000000177070100100700FF0101621B520055000001960101016333130076094AAF100402E2B30D6200620072650000020171016363B70000001B1B1B1B1A02E994
2021.11.26 15:32:51 5: OBIS (ITR_Stromzaehler) - Full message-> 1B1B1B1B0101010176094AAF100402E2B30B6200620072650000010176010109000000000506EAF80B0A01495452000349F040726201650506EBB20163073B0076094AAF100402E2B30C6200620072650000070177010B0A01495452000349F040070100620AFFFF726201650506EBB275770701006032010101010101044954520177070100600100FF010101010B0A01495452000349F0400177070100010800FF65001C010401621E52FF690000000006BA404D0177070100020800FF0101621E52FF6900000000000000000177070100100700FF0101621B520055000001960101016333130076094AAF100402E2B30D6200620072650000020171016363B70000001B1B1B1B1A02E994
2021.11.26 15:32:51 4: OBIS (ITR_Stromzaehler) - MSG IS: 
/
1-0:96.50.1*1(ITR)
1-0:96.1.0*255(
ITRI@)
1-0:1.8.0*255(>11286945.3*Wh)
1-0:2.8.0*255(0*Wh)
1-0:16.7.0*255(406*W)
!

2021.11.26 15:32:51 5: OBIS (ITR_Stromzaehler) - Msg-Parse: /
2021.11.26 15:32:51 5: OBIS (ITR_Stromzaehler) - Msg-Parse: 1-0:96.50.1*1(ITR)
2021.11.26 15:32:51 5: OBIS (ITR_Stromzaehler) - Msg 1-0:96.50.1*1(ITR) is of type ManufID2
2021.11.26 15:32:51 5: OBIS (ITR_Stromzaehler) - Msg-Parse: 1-0:96.1.0*255(
ITRI@)
2021.11.26 15:32:51 5: OBIS (ITR_Stromzaehler) - Msg-Parse: 1-0:1.8.0*255(>11286945.3*Wh)
2021.11.26 15:32:51 5: OBIS (ITR_Stromzaehler) - Msg-Parse: 1-0:2.8.0*255(0*Wh)
2021.11.26 15:32:51 5: OBIS (ITR_Stromzaehler) - Msg-Parse: 1-0:16.7.0*255(406*W)
2021.11.26 15:32:51 5: OBIS (ITR_Stromzaehler) - Msg 1-0:16.7.0*255(406*W) is of type Channels
2021.11.26 15:32:51 5: OBIS (ITR_Stromzaehler) - Msg-Parse: !
2021.11.26 15:32:51 1: PERL WARNING: Argument ">11286945.3" isn't numeric in division (/) at (eval 57) line 1.
2021.11.26 15:32:51 3: eval:  sprintf "Aktuell: %.1f W, Verbrauch: %i kWh seit %s.",ReadingsVal($name,"power",0),ReadingsVal($name,"1.8.0_Verbrauch",0)/1000,POSIX::strftime("%-d.%-m., %H:%M",localtime(time_str2num(ReadingsTimestamp($name,"energyOffset",0)))); 
2021.11.26 15:33:00 5: DevIo_SimpleWrite ITR_Stromzaehler: 
2021.11.26 15:33:00 4: OBIS (ITR_Stromzaehler) - Wrote 
2021.11.26 15:33:00 5: OBIS (ITR_Stromzaehler) - Internal timer set to 2021-11-26 15:33:10
2021.11.26 15:33:01 5: OBIS (ITR_Stromzaehler) - SML-Parse 1B1B1B1B0101010176094AAF100402E2B3296200620072650000010176010109000000000506EB020B0A01495452000349F040726201650506EBBC016355F50076094AAF100402E2B32A6200620072650000070177010B0A01495452000349F040070100620AFFFF726201650506EBBC75770701006032010101010101044954520177070100600100FF010101010B0A01495452000349F0400177070100010800FF65001C010401621E52FF690000000006BA40580177070100020800FF0101621E52FF6900000000000000000177070100100700FF0101621B5200550000019001010163760E0076094AAF100402E2B32B620062007265000002017101632D1F0000001B1B1B1B1A02B9C8
2021.11.26 15:33:01 5: OBIS (ITR_Stromzaehler) - Full message-> 1B1B1B1B0101010176094AAF100402E2B3296200620072650000010176010109000000000506EB020B0A01495452000349F040726201650506EBBC016355F50076094AAF100402E2B32A6200620072650000070177010B0A01495452000349F040070100620AFFFF726201650506EBBC75770701006032010101010101044954520177070100600100FF010101010B0A01495452000349F0400177070100010800FF65001C010401621E52FF690000000006BA40580177070100020800FF0101621E52FF6900000000000000000177070100100700FF0101621B5200550000019001010163760E0076094AAF100402E2B32B620062007265000002017101632D1F0000001B1B1B1B1A02B9C8
2021.11.26 15:33:01 4: OBIS (ITR_Stromzaehler) - MSG IS: 
/
1-0:96.50.1*1(ITR)
1-0:96.1.0*255(
ITRI@)
1-0:1.8.0*255(>11286946.4*Wh)
1-0:2.8.0*255(0*Wh)
1-0:16.7.0*255(400*W)
!

2021.11.26 15:33:01 5: OBIS (ITR_Stromzaehler) - Msg-Parse: /
2021.11.26 15:33:01 5: OBIS (ITR_Stromzaehler) - Msg-Parse: 1-0:96.50.1*1(ITR)
2021.11.26 15:33:01 5: OBIS (ITR_Stromzaehler) - Msg 1-0:96.50.1*1(ITR) is of type ManufID2
2021.11.26 15:33:01 5: OBIS (ITR_Stromzaehler) - Msg-Parse: 1-0:96.1.0*255(
ITRI@)
2021.11.26 15:33:01 5: OBIS (ITR_Stromzaehler) - Msg-Parse: 1-0:1.8.0*255(>11286946.4*Wh)
2021.11.26 15:33:01 5: OBIS (ITR_Stromzaehler) - Msg-Parse: 1-0:2.8.0*255(0*Wh)
2021.11.26 15:33:01 5: OBIS (ITR_Stromzaehler) - Msg-Parse: 1-0:16.7.0*255(400*W)
2021.11.26 15:33:01 5: OBIS (ITR_Stromzaehler) - Msg 1-0:16.7.0*255(400*W) is of type Channels
2021.11.26 15:33:01 5: OBIS (ITR_Stromzaehler) - Msg-Parse: !
2021.11.26 15:33:01 1: PERL WARNING: Argument ">11286946.4" isn't numeric in division (/) at (eval 58) line 1.
2021.11.26 15:33:01 3: eval:  sprintf "Aktuell: %.1f W, Verbrauch: %i kWh seit %s.",ReadingsVal($name,"power",0),ReadingsVal($name,"1.8.0_Verbrauch",0)/1000,POSIX::strftime("%-d.%-m., %H:%M",localtime(time_str2num(ReadingsTimestamp($name,"energyOffset",0)))); 
2021.11.26 15:33:11 1: PERL WARNING: Argument ">11286947.6" isn't numeric in division (/) at (eval 60) line 1.
2021.11.26 15:33:11 3: eval:  sprintf "Aktuell: %.1f W, Verbrauch: %i kWh seit %s.",ReadingsVal($name,"power",0),ReadingsVal($name,"1.8.0_Verbrauch",0)/1000,POSIX::strftime("%-d.%-m., %H:%M",localtime(time_str2num(ReadingsTimestamp($name,"energyOffset",0)))); 
2021.11.26 15:33:21 1: PERL WARNING: Argument ">11286948.7" isn't numeric in division (/) at (eval 61) line 1.
2021.11.26 15:33:21 3: eval:  sprintf "Aktuell: %.1f W, Verbrauch: %i kWh seit %s.",ReadingsVal($name,"power",0),ReadingsVal($name,"1.8.0_Verbrauch",0)/1000,POSIX::strftime("%-d.%-m., %H:%M",localtime(time_str2num(ReadingsTimestamp($name,"energyOffset",0)))); 
2021.11.26 15:33:31 1: PERL WARNING: Argument ">11286949.8" isn't numeric in division (/) at (eval 62) line 1.
2021.11.26 15:33:31 3: eval:  sprintf "Aktuell: %.1f W, Verbrauch: %i kWh seit %s.",ReadingsVal($name,"power",0),ReadingsVal($name,"1.8.0_Verbrauch",0)/1000,POSIX::strftime("%-d.%-m., %H:%M",localtime(time_str2num(ReadingsTimestamp($name,"energyOffset",0)))); 
2021.11.26 15:34:28 1: PERL WARNING: Argument ">11286950" isn't numeric in division (/) at (eval 328) line 1.
2021.11.26 15:34:28 3: eval:  sprintf "Aktuell: %.1f W, Verbrauch: %i kWh seit %s.",ReadingsVal($name,"power",0),ReadingsVal($name,"1.8.0_Verbrauch",0)/1000,POSIX::strftime("%-d.%-m., %H:%M",localtime(time_str2num(ReadingsTimestamp($name,"energyOffset",0)))); 
2021.11.26 15:34:38 1: PERL WARNING: Argument ">11286958.3" isn't numeric in division (/) at (eval 336) line 1.
2021.11.26 15:34:38 3: eval:  sprintf "Aktuell: %.1f W, Verbrauch: %i kWh seit %s.",ReadingsVal($name,"power",0),ReadingsVal($name,"1.8.0_Verbrauch",0)/1000,POSIX::strftime("%-d.%-m., %H:%M",localtime(time_str2num(ReadingsTimestamp($name,"energyOffset",0)))); 
2021.11.26 15:34:48 1: PERL WARNING: Argument ">11286959.6" isn't numeric in division (/) at (eval 338) line 1.
2021.11.26 15:34:48 3: eval:  sprintf "Aktuell: %.1f W, Verbrauch: %i kWh seit %s.",ReadingsVal($name,"power",0),ReadingsVal($name,"1.8.0_Verbrauch",0)/1000,POSIX::strftime("%-d.%-m., %H:%M",localtime(time_str2num(ReadingsTimestamp($name,"energyOffset",0)))); 
2021.11.26 15:34:58 1: PERL WARNING: Argument ">11286960.8" isn't numeric in division (/) at (eval 340) line 1.
2021.11.26 15:34:58 3: eval:  sprintf "Aktuell: %.1f W, Verbrauch: %i kWh seit %s.",ReadingsVal($name,"power",0),ReadingsVal($name,"1.8.0_Verbrauch",0)/1000,POSIX::strftime("%-d.%-m., %H:%M",localtime(time_str2num(ReadingsTimestamp($name,"energyOffset",0)))); 
2021.11.26 15:35:08 1: PERL WARNING: Argument ">11286962" isn't numeric in division (/) at (eval 341) line 1.
2021.11.26 15:35:08 3: eval:  sprintf "Aktuell: %.1f W, Verbrauch: %i kWh seit %s.",ReadingsVal($name,"power",0),ReadingsVal($name,"1.8.0_Verbrauch",0)/1000,POSIX::strftime("%-d.%-m., %H:%M",localtime(time_str2num(ReadingsTimestamp($name,"energyOffset",0)))); 
2021.11.26 15:35:18 1: PERL WARNING: Argument ">11286963.3" isn't numeric in division (/) at (eval 342) line 1.
2021.11.26 15:35:18 3: eval:  sprintf "Aktuell: %.1f W, Verbrauch: %i kWh seit %s.",ReadingsVal($name,"power",0),ReadingsVal($name,"1.8.0_Verbrauch",0)/1000,POSIX::strftime("%-d.%-m., %H:%M",localtime(time_str2num(ReadingsTimestamp($name,"energyOffset",0)))); 
2021.11.26 15:35:28 1: PERL WARNING: Argument ">11286964.5" isn't numeric in division (/) at (eval 343) line 1.
2021.11.26 15:35:28 3: eval:  sprintf "Aktuell: %.1f W, Verbrauch: %i kWh seit %s.",ReadingsVal($name,"power",0),ReadingsVal($name,"1.8.0_Verbrauch",0)/1000,POSIX::strftime("%-d.%-m., %H:%M",localtime(time_str2num(ReadingsTimestamp($name,"energyOffset",0))));

kuemmling · 30 November 2021, 19:56:10

Zunächst erst einmal ein riesiges Dankeschön gvzdus für die Entwicklung des OBIS Moduls. Leider kam ich in den letzten Wochen nicht dazu das Thema zu verfolgen. Ich habe nun mit deiner
ausführlichen Antwort aus dem September die Daten noch einmal manuell analysiert. Offensichtlich hat mein Holley DTZ541 auch einen reduzierten Datenmode. Das muss ich später genauer untersuchen.
Nun plagt mich ein neues Problem. Seit gestern ist plötzlich Schluss mit readings. Den Effekt von zeitweisen Aussetzern konnte ich im Oktober durch Neustart des raspis beheben.
Jetzt ist aber ganz Schluss. Der Status ist opened, es kommen aber keine Readings. Auch die Type information bleibt leer. Ein Update heute brachte leider auch nichts.
Hatte jemand schon einmal einen solchen Effekt? Kann ich prüfen ob der Lesekopf noch funktioniert?

Viele Grüße
Nico

gvzdus · 30 November 2021, 20:11:23

Der Basis-Test ist eigentlich simpel:
FHEM beenden, und mit

Code Auswählen

cat /dev/ttyUSB1 | hexdump
gucken, was auf der Schnittstelle ankommt (statt USB1 natürlich ggf. das richtige Device). Ggf. mit Laptop am Zählerschrank und dabei am Lesekopf drehen und schieben.

Das Datenpaket beginnt mit 1b1b1b1b01010101, hier bei 0x18A:

Code Auswählen

0000160 8a7d 2dd9 e2c1 a49a fd9b 5348 e457 89b5
0000170 27e5 1b30 0e2d faa6 ce4f 5c32 69d9 0101
0000180 6301 4935 7600 0005 7af3 1b1b 1b1b 0101
0000190 0101 0576 b86b 626f 6200 7200 0163 7601
00001a0 0101 0105 3d79 0b7b 0109 5349 004b a1e6
00001b0 0101 0663 0078 0576 b86b 6270 6200 7200

Debugging Zähler: Mit meinem iPhone XR im Kameramodus auf den Zähler gerichtet, sehe ich das IR-Signal als sekündliches Lila leuchten.

Wenn da nix kommt: PIN noch einmal eingeben?

gvzdus · 30 November 2021, 20:14:50

Achso, auch immer gerne eine Fehlerquelle: Viele USB-Geräte am Raspi, Reboot, und die Nummern werden neu verlost. Deswegen immer besser über den Gerätenamen ansprechen, bei mir z.B. statt

Code Auswählen

/dev/ttyUSB1 lieber ein

Code Auswählen

/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A106Q3OW-if00-port0. Das ist "mehr sticky".

gvzdus · 30 November 2021, 20:31:28

Zitat von: karpate am 26 November 2021, 15:39:23
welches Interval wäre zu empfehlen?

Überhaupt kein Intervall! Kein "pollingMode"-Attribut, kein "interval"! Ich finde die Verwendung von "interval" sinnvoll, wenn z.B. alle 5 Minuten oder gar stündlich die "Meßwerte" bestimmt werden sollen. Dann ist es auch sinnvoll, die verbrauchte Leistung als Delta der Zählerstände zu ermitteln. Für Anwendungen wie bei mir, nämlich die Verbraucherüberschuss-Steuerung, musst Du eher entweder auf die genauen Werte gehen oder diese Werte mitteln.

Ich habe Deine Werte mal eingelesen, und ja, ich sehe auch im Debug-Log dann das Dekodieren wie:

Code Auswählen

2021.11.30 20:20:52 5: OBIS (ob) - Msg-Parse: 1-0:1.8.0*255(>11286946.4*Wh)

Das Reading ist aber trotzdem ohne Präfix:

Code Auswählen

defmod ob OBIS /tmp/ob
attr ob verbose 5

setstate ob 2 lines in 0.0493559837341309 seconds = 41 lines per second
setstate ob 2021-11-30 20:20:52 ManufID2 ITR
setstate ob 2021-11-30 20:20:52 power 400
setstate ob 2021-11-30 20:20:52 state 2 lines in 0.0493559837341309 seconds = 41 lines per second
setstate ob 2021-11-30 20:20:52 total_consumption 11286946.4
setstate ob 2021-11-30 20:20:52 total_feed 0

(Meine Debug-Funktion: Obis mit File-Namen anlegen liest eine Logdatei auf verbose 5 ein).

Daher meine Frage: Was kommt, wenn Du mal "channels" rauswirfst und den "gottgebenen" Namen "total_consumption" wirken lässt?

kuemmling · 30 November 2021, 20:49:10

Vielen Dank für die schnelle Hilfe.

Code Auswählen

sudo systemctl stop fhem
cat /dev/serial/by-id/usb-Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_0029-if00-port0 | hexdump

brachte nichts. Danach machte ich den Handy-Test mit der IR-LED. Das funktionierte.
Nun drehte ich noch den Sensor, der 2 Monate funktionierte, um 180°.
Danach brachte der USB-Test das gewünschte Ergebnis als Hex-Datenblock.
Neustart von fhem und alles läuft wieder.

Noch einmal herzlichen Dank für die Hilfe. Rätselhaft bleibt es trotzdem.
Viele Grüße
Nico