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

Raymund · 01 Februar 2020, 21:36:41

Auch die Position des Lesekopfes (genau) über den/der IR-LED kann bedeutsam sein. Ich konnte damit meine Lesefehler zwar nicht ausschalten aber doch reduzieren. Die "Pünktchen" auf dem Zählergehäuse müssen übrigens nicht automatisch richtig positioniert sein. Also mal seitlich "reinlinsen" ...

KölnSolar · 02 Februar 2020, 08:09:14

Ich denke, Raymund hat ne Menge Tipps gegeben, wie man dem Problem von "disconnects"(state=opened, aber kein Datenempfang;state wechselt auf disconnected...)auf die Spur kommen kann.
Ihr müsst auch mal zusammenfassend Eure Installation u. das Problem mit den verschiedenen Problemlösungsversuchen u. deren Erfolg beschreiben. Ist schon schwierig über die verteilten Posts die verschiedenenen Situationen(Norbert, Michael....) nachzuvollziehen.

Was sind Eure workarounds ? physisches disconnect/reconnect, defmod, get device update, FHEM-reboot, Systemreboot, delete/define device.....

Ich selber hab mittlerweile 3 pushende Zählertypen und über Jahre noch nie das beschriebene Problem mit serial-USB-Lesekopf gehabt.

ZitatDas letzte Telegramm wurde nicht vollständig empfangen.

Hi Stefan, aber dann müsste doch beim nächsten Datensatz wieder alles funktionieren, oder ?

@Norbert: Mir ist jetzt nur Dein interval=30 aufgefallen. Was passiert, wenn Du mal ein größeres Intervall nimmst ? (nur so ne Idee)
Grüße Markus

Icinger · 02 Februar 2020, 08:37:49

ZitatHi Stefan, aber dann müsste doch beim nächsten Datensatz wieder alles funktionieren, oder ?

Nein, weil ja noch immer auf das Ende des vergangenen gewartet wird.

KölnSolar · 02 Februar 2020, 08:51:41

Ich glaub ich verstehe. Aber irgendwann müsste das Modul das "warten" ja beenden und den "Puffer" leeren. $:-\$ Unvollständige/Fehlerhafte Datensätze kann es ja immer mal geben.
Ist das bei allen Zählertypen gleich oder zwischen pushenden u. pollenden unterschiedlich ?
Edit: Und bei Norbert ist der buffer scheinbar leer.

Zitat
helper:
BUFFER
EoM -1

michael.winkler · 02 Februar 2020, 13:56:18

Danke dass sich jetzt mal jemand dem Thema annimmt. Wie ich schon geschrieben habe, habe ich im LOG Einträge stehen, womit das Modul wohl auf Fehler stößt. Kurz darauf meldet das Modul einen disconnect. Dieser bleibt auch so lange auf disconnect bis ich entweder den FHEM Server neu startet oder das Device von mal mit einem DEF aktualisiere. Ich denke auch dass das SML Paket nicht vollständig ist, oder einfach falsche Informationen liefert. Allerdings bin ich der Meinung das genau sowas das Modul abfangen sollte.

Aktuell behelfe ich mir mit einem Workaround.

Ich habe mit einen "AT" mit folgendem Inhalt angelegt:

Code Auswählen


+*00:00:10 { 
	my $PowerAge = ReadingsAge("myPowerMeter","power",0);
	if    ($PowerAge >= 130) {
		if (ReadingsAge("myPowerMeter","startSML",0) >= 60) {
			Log3 "watchdog",3,"myPowerMeter start SML! ReadingAage=$PowerAge";
			fhem "modify myPowerMeter 10.10.2.3:23 SML";
			fhem "setreading myPowerMeter startSML $PowerAge"		
		}
	}
	elsif ($PowerAge >= 65 ) {
		if (ReadingsAge("myPowerMeter","startESP",0) >= 200) {
			Log3 "watchdog",3,"myPowerMeter start ESP! ReadingAage=$PowerAge";
			fhem "set haus.strom.esp reboot";
			fhem "setreading myPowerMeter startESP $PowerAge"		
		}
	}
}

Den Reboot für das ESP Modul könnte man sich sparen. Führe Ihn aber trotzdem vorsorglich aus. Im Februar Log habe ich bis jetzt folgende Einträge.

Code Auswählen


2020.02.01 16:27:28.275 3: myPowerMeter start ESP! ReadingAage=67
2020.02.01 16:28:38.275 3: myPowerMeter start SML! ReadingAage=137
2020.02.01 16:29:38.275 3: myPowerMeter start SML! ReadingAage=197
2020.02.01 19:40:48.275 3: myPowerMeter start ESP! ReadingAage=69
2020.02.01 19:41:58.275 3: myPowerMeter start SML! ReadingAage=139
2020.02.01 19:42:58.275 3: myPowerMeter start SML! ReadingAage=199
2020.02.02 02:50:08.275 3: myPowerMeter start ESP! ReadingAage=69
2020.02.02 02:51:18.275 3: myPowerMeter start SML! ReadingAage=139
2020.02.02 02:52:18.275 3: myPowerMeter start SML! ReadingAage=199
2020.02.02 13:24:28.275 3: myPowerMeter start ESP! ReadingAage=68
2020.02.02 13:25:38.275 3: myPowerMeter start SML! ReadingAage=138
2020.02.02 13:27:48.275 3: myPowerMeter start ESP! ReadingAage=128
2020.02.02 13:27:58.277 3: myPowerMeter start SML! ReadingAage=138
2020.02.02 13:28:58.275 3: myPowerMeter start SML! ReadingAage=198
2020.02.02 13:37:08.275 3: myPowerMeter start ESP! ReadingAage=70
2020.02.02 13:38:08.274 3: myPowerMeter start SML! ReadingAage=130
2020.02.02 13:39:08.275 3: myPowerMeter start SML! ReadingAage=190

Daran sieht man das es sehr regelmäßig auftritt.

Gruß
Michael

Icinger · 02 Februar 2020, 14:17:10

Disconnects sind was anderes als unvollständige Pakete.
Ich kann im Modul nicht einfach so mirnichts dirnichts ein Reconnect machen. Woher soll ich wissen, dass das (Lesekopf, USB-Wandler o.ä.) nicht willentlich abgesteckt wurde?

Das OBIS führt von sich aus keinen Disconnect aus, somit liegt das entweder an FHEM oder aus Hardware-Ebene.

Bin aber für realistische Vorschläge, wie man das abfangen kann, durchaus offen.

michael.winkler · 02 Februar 2020, 14:23:25

Zitat von: Icinger am 02 Februar 2020, 14:17:10
Disconnects sind was anderes als unvollständige Pakete.
Ich kann im Modul nicht einfach so mirnichts dirnichts ein Reconnect machen. Woher soll ich wissen, dass das (Lesekopf, USB-Wandler o.ä.) nicht willentlich abgesteckt wurde?

Das OBIS führt von sich aus keinen Disconnect aus, somit liegt das entweder an FHEM oder aus Hardware-Ebene.

Bin aber für realistische Vorschläge, wie man das abfangen kann, durchaus offen.

wie kann man feststellen warum ein disconnect geschehen ist?

Folgendes habe ich bei den Disconnects im FHEM LOG stehen:

Code Auswählen


2020.02.01 16:26:51.439 1: PERL WARNING: Use of uninitialized value $b in substitution (s///) at ./FHEM/47_OBIS.pm line 253.
2020.02.01 16:26:51.439 1:     main::__ANON__                      called by ./FHEM/47_OBIS.pm (253)
2020.02.01 16:26:51.439 1:     main::OBIS_Read                     called by fhem.pl (3763)
2020.02.01 19:40:20.824 1: PERL WARNING: Use of uninitialized value $b in substitution (s///) at ./FHEM/47_OBIS.pm line 253.
2020.02.01 19:40:20.824 1:     main::__ANON__                      called by ./FHEM/47_OBIS.pm (253)
2020.02.01 19:40:20.824 1:     main::OBIS_Read                     called by fhem.pl (3763)
2020.02.02 02:49:33.302 1: PERL WARNING: Use of uninitialized value $b in substitution (s///) at ./FHEM/47_OBIS.pm line 253.
2020.02.02 02:49:33.302 1:     main::__ANON__                      called by ./FHEM/47_OBIS.pm (253)
2020.02.02 02:49:33.302 1:     main::OBIS_Read                     called by fhem.pl (3763)
2020.02.02 13:25:55.460 1: PERL WARNING: Use of uninitialized value $b in substitution (s///) at ./FHEM/47_OBIS.pm line 253.
2020.02.02 13:25:55.461 1:     main::__ANON__                      called by ./FHEM/47_OBIS.pm (253)
2020.02.02 13:25:55.461 1:     main::OBIS_Read                     called by fhem.pl (3763)
2020.02.02 13:37:02.074 1: PERL WARNING: Use of uninitialized value $b in substitution (s///) at ./FHEM/47_OBIS.pm line 253.
2020.02.02 13:37:02.074 1:     main::__ANON__                      called by ./FHEM/47_OBIS.pm (253)
2020.02.02 13:37:02.074 1:     main::OBIS_Read                     called by fhem.pl (3763)
2020.02.02 13:37:02.074 1: PERL WARNING: Use of uninitialized value $buf in unpack at ./FHEM/47_OBIS.pm line 410.
2020.02.02 13:37:02.074 1:     main::__ANON__                      called by ./FHEM/47_OBIS.pm (410)
2020.02.02 13:37:02.074 1:     main::OBIS_Parse                    called by ./FHEM/47_OBIS.pm (254)
2020.02.02 13:37:02.074 1:     main::OBIS_Read                     called by fhem.pl (3763)
2020.02.02 13:37:02.075 1: PERL WARNING: Use of uninitialized value $buf in concatenation (.) or string at ./FHEM/47_OBIS.pm line 423.
2020.02.02 13:37:02.075 1:     main::__ANON__                      called by ./FHEM/47_OBIS.pm (423)
2020.02.02 13:37:02.075 1:     main::OBIS_Parse                    called by ./FHEM/47_OBIS.pm (254)
2020.02.02 13:37:02.075 1:     main::OBIS_Read                     called by fhem.pl (3763)
2020.02.02 13:37:02.075 1: PERL WARNING: Use of uninitialized value $buf in concatenation (.) or string at ./FHEM/47_OBIS.pm line 433.
2020.02.02 13:37:02.075 1:     main::__ANON__                      called by ./FHEM/47_OBIS.pm (433)
2020.02.02 13:37:02.075 1:     main::OBIS_Parse                    called by ./FHEM/47_OBIS.pm (254)
2020.02.02 13:37:02.075 1:     main::OBIS_Read                     called by fhem.pl (3763)

Raymund · 02 Februar 2020, 15:23:53

Hallo Michael,

schick' mir mal eines (oder mehrere) von den SML-Files, die den Ärger verursachen. Ich schau mir das an.

Und noch mindestens eines, das keinen Ärger gemacht hat zum Vergleich.

Gruß
Raymund

Raymund · 02 Februar 2020, 16:13:02

ZitatFolgendes habe ich bei den Disconnects im FHEM LOG stehen:

Diese Warnung in Zeile 253 entsteht vermutlich daraus, dass DevIo_SimpleRead keine Daten geliefert hat. Die Variable $b ist dann "leer". Füge dazu in Zeile 251 folgendes hinten an, dass es so aussieht:

Code Auswählen

my $buf = DevIo_DoSimpleRead($hash); return undef unless ($buf);

Dann könnte dies schon einmal Vergangenheit sein. So steht es auch in https://wiki.fhem.de/wiki/DevIo#serielle_Verbindung.

Gruß
Raymund

michael.winkler · 02 Februar 2020, 16:18:33

Zitat von: Raymund am 02 Februar 2020, 15:23:53
Hallo Michael,

schick' mir mal eines (oder mehrere) von den SML-Files, die den Ärger verursachen. Ich schau mir das an.

Und noch mindestens eines, das keinen Ärger gemacht hat zum Vergleich.

Gruß
Raymund

welche Files meinst du, wo finde ich die?

michael.winkler · 02 Februar 2020, 16:22:01

Zitat von: Raymund am 02 Februar 2020, 16:13:02
Dieser Fehler in Zeile 253 entsteht vermutlich daraus, dass DevIo_SimpleRead keine Daten geliefert hat. Die Variable $b ist dann "leer". Füge dazu in Zeile 251 folgendes hinten an, dass es so aussieht:

Code Auswählen Erweitern
my $buf = DevIo_DoSimpleRead($hash); return undef unless ($buf);

Dann könnte dieser Fehler schon einmal Vergangenheit sein. So steht es auch in https://wiki.fhem.de/wiki/DevIo#serielle_Verbindung.

Gruß
Raymund

Wird das noch in das offizielle Modul mit aufgenommen?

Raymund · 02 Februar 2020, 16:36:30

ZitatWird das noch in das offizielle Modul mit aufgenommen?

Validiere doch erst einmal, ob es das auch war.

michael.winkler · 02 Februar 2020, 16:38:17

Zitat von: Raymund am 02 Februar 2020, 16:36:30
Validiere doch erst einmal, ob es das auch war.

OK, mache ich

hast du diese Zeilen auch gesehen?

Code Auswählen


2020.02.02 13:37:02.075 1: PERL WARNING: Use of uninitialized value $buf in concatenation (.) or string at ./FHEM/47_OBIS.pm line 423.
2020.02.02 13:37:02.075 1:     main::__ANON__                      called by ./FHEM/47_OBIS.pm (423)
2020.02.02 13:37:02.075 1:     main::OBIS_Parse                    called by ./FHEM/47_OBIS.pm (254)
2020.02.02 13:37:02.075 1:     main::OBIS_Read                     called by fhem.pl (3763)
2020.02.02 13:37:02.075 1: PERL WARNING: Use of uninitialized value $buf in concatenation (.) or string at ./FHEM/47_OBIS.pm line 433.
2020.02.02 13:37:02.075 1:     main::__ANON__                      called by ./FHEM/47_OBIS.pm (433)
2020.02.02 13:37:02.075 1:     main::OBIS_Parse                    called by ./FHEM/47_OBIS.pm (254)
2020.02.02 13:37:02.075 1:     main::OBIS_Read                     called by fhem.pl (3763)

Raymund · 02 Februar 2020, 16:51:12

Das sieht mir sehr nach einem Folgeproblem aus, weil die Sub OBIS_Parse direkt nach der Warnung aus Zeile 253 aufgerufen wird und die leere Variable $buf weitergereicht wird.

Raymund · 02 Februar 2020, 17:29:08

Zitatwelche Files meinst du, wo finde ich die?

Die SML-Spezifikation (z.B. hier https://www.msxfaq.de/sonst/bastelbude/smartmeter_d0_sml_protokoll.htm) nennt die einzelnen "Datensätze", die die Lesegeräte ausgeben, "Files" oder eben "Dateien". So ein Datensatz fängt mit "1B 1B 1B 1B 01 01 01 01" an und hört mit "1B 1B 1B 1B 1A AF 56 FC" auf, wobei die letzten 6 Bytes eine Prüfsumme enthalten und also variabel sind. Dazwischen liegen die SML-Messages. Die Gesamtanzahl der Zeichen eines solchen Files muss übrigens durch 4 teilbar sein (ohne Rest natürlich

), was schon mal ein erstes Anzeichen für seine "Validität" wäre.

Diese Files solltest Du dem Logfile von FHEM entnehmen können, wenn verbose auf 5 steht.