'x' outside of string in unpack at ./FHEM/00_TUL.pm line 692

Begonnen von Norbert.Roller, 25 Juli 2016, 19:04:58

Vorheriges Thema - Nächstes Thema

Norbert.Roller

Hi,
seit der Umstellung von eibd auf KNX erhalte ich immer obigen Fehler (ohne Uhrzeit im Log) mit einem Beenden / Absturz von FHEM.

In der Config steht:

define KNX_Gateway TUL eibd:localhost 0.1.0
attr KNX_Gateway useEIB 0

Der Fehler erscheint willkürlich und ohne Zusammenhang zu vorangegangenen Ereignissen. Mal täglich und mal nur alle 3-4 Tage.

Hat jemand eine Idee, wo und wie ich den Fehler suchen und beheben kann ?

Nachtrag: Obwohl alle Verweise auf eibd entfernt sind bekomme ich immer noch die Warnmeldung.

Using EIB is deprecated. Please migrate to KNX soon. Module 10_EIB is not maintained any longer. If you still want to use the module EIB,
   please set the attribute useEIB to 1 within the tul-device. Please keep in mind, that 10_KNX has a changed syntax regarding the definition, arguments and readings. Please refer to the commandref.
   As well 10_EIB and 10_KNX are compatible to daemon eibd and knxd.


Andi291

Hallo Norbert,

die "Warnmeldung" steht auf vielfachen Wunsch da. Leider kann ich zum Zeitpunkt des Starts vom FHEM nicht abfragen, ob überhaupt noch EIB-devices definiert sind . Insofern: bitte einfach zur Kenntnis nehmen. Kein Bug, sondern Feature.

Wegen Deines eigentlichen Problemes:
Bekannt ist mir das Thema nicht. Es passiert jedenfalls beim decodieren einer eingehenden Nachricht. Ein Zeitstempel und die letzte eingegangene Nachricht wären fürs erste recht hilfreich.
Grob geraten tippe ich auf ein schlecht geformtes Telegramm.

Welche Busanbindung nutzt Du? Hoffentlich nicht TUL ohne eibd oder kndx?

Grüße, Andi

smurfix

#2
Zitat von: Andi291 am 26 Juli 2016, 19:46:55
Grob geraten tippe ich auf ein schlecht geformtes Telegramm.

Welche Busanbindung nutzt Du? Hoffentlich nicht TUL ohne eibd oder kndx?
Schlechte Telegramme dürfen nicht zum Crash führen ... da macht man doch bitte ein eval() drumherum.

Die Busanbindung steht da schon!

Norbert.Roller

Hi, sorry war mal ein paar Tage in der Sonne :-)
Leider mit einigen Abstürzen von FHEM im Haus. Mit anderen Worten das Problem läuft einfach regelmäßig alle 1-3 Tage weiter und ist somit eigentlich gut trace bar.

Von der Hardware ist ein IPR/S2.1 oder ein IPS/S2.1 von ABB als IP<->KNX Gateway verbaut.

Kann ich diesen eval() auch selbst einfügen? Kann selbst eigentlich gut programmieren, jedoch kein Perl :-(
Ich nehme mal an, dass es um diese Zeile geht:

my ($src, $dst,$bytes) = unpack("nnxa*", $buf);

beim unpack Command gibt es nachfolgende Hinweise:
... passing a pointer value that's not known to be valid is likely to have disastrous consequences.
If there are more pack codes or if the repeat count of a field or a group is larger than what the remainder of the input string allows, the result is not well defined: the repeat count may be decreased, or unpack may produce empty strings or zeros, or it may raise an exception....


Wie kann ich den Zeitstempel bekommen, wenn im LOG keiner angezeigt wird? Detailstufe des Log erhöhen?
Die Meldungen vor dem Absturz liegen oft mehre Minuten / Stunden in der Vergangenheit und es gibt keine Regelmäßigkeit zu erkennen.

Danke für die Unterstützung.

Norbert.Roller

Ich habe nochmal ein wenig zur "unpack"-Funktion nachgelesen und es sieht für mich so aus, als wenn das Telegramm nur aus zwei Adressen ohne Datenpaket besteht.
'nnxa' löst sich für mich etwa so auf:
n = 16 Bit Adresse
n = 16 Bit Adresse
x = rekursiv lesen oder überspringen (?)
a = byte wert (?)

Nur welches Gerät solch ein defektes Paket schickt ?
Oder kommt es am Ende aus dem EIBD Programm, was auf dem Raspberry als Deamon werkelt ?

Am besten wäre ein LOG Output des $buf zu erzeugen, wenn der Fehler auftritt, nur dafür reichen meine Kenntnisse leider nicht aus. Extrem viel Betrieb ist auf dem KNX-Bus nicht und somit könnte ich ein großes LOG in kauf nehmen.

Andi291

#5
Hallo Norbert,

es sei Dir vegönnt :-)

Setz doch bitte mal bei Tul das Verbose-Level auf 5.

Obwohl ich der Modulautor von KNX bin, bin ich mit Perl nicht so fit. Die TUL habe ich nur "geerbt".
Wenn ich Smurfix Anregung richtig interpretiere, müssten folgende Zeilen in der TUL Hilfe geben:

alt:
my ($src, $dst,$bytes) = unpack("nnxa*", $buf);

neu:
eval {my ($src, $dst,$bytes) = unpack("nnxa*", $buf)};
if($@) {Log (0, error while parsing message: $buf)};


Einen Fehler im KNXD schließe ich eigentlich aus. Da sind keinerlei negative RM bekannt. Eher tippe ich auf ein schlecht geformtes Telegramm eines Busteilnehmers gepaart mit nicht ausreichender Robustheit der TUL.

Grüße, Andi

Norbert.Roller

Hallo Andi,
danke das du dir die Zeit für mein Problem nimmt.

Das mit dem Verbose Level auf 5 beim TUL hatte ich gestern morgen schon gemacht und warte jetzt auf den nächsten Absturz.

Nach dem nächsten Absturz setze ich deine Änderung ein und teste dann weiter.

Norbert.Roller

Hallo Andi,
gestern war es dann wieder so weit und das FHEM hat sich beendet. Leider ohne neue Erkenntnisse.
Ich baue jetzt mal deine Änderungen in das 00_TUL ein und lasse es weiter laufen.

2016.08.05 07:59:08 5: sending Cwa00100
2016.08.05 07:59:08 5: sending Cwa00101
2016.08.05 07:59:08 5: SimpleRead msg.type: write, msg.src: 0000, msg.dst: a001
2016.08.05 07:59:08 5: SimpleRead data: 00
2016.08.05 07:59:08 4: KNX_Gateway: C0000wa00100
2016.08.05 07:59:08 5: KNX_Gateway dispatch C0000wa00100
2016.08.05 07:59:08 5: enter parse: hash: HASH(0x2794598) name: KNX_Gateway, msg: C0000wa00100
2016.08.05 07:59:08 5: exit parse
2016.08.05 07:59:08 5: sending Cwa00101
'x' outside of string in unpack at ./FHEM/00_TUL.pm line 692.


Andi291

Hallo Norbert,

mach das - wenns klappt ist das aber maximal ein Workaround (Abfangen des Fehlers).

Das Problem scheint mir hier:
2016.08.05 07:59:08 5: SimpleRead msg.type: write, msg.src: 0000, msg.dst: a001

Der Absender "0" schickt um 07:59:08 auf die Gruppenadresse 10/0/1.

Der Fehler dürfte meiner Meinung nach behoben sein, sobald der Absender eine gültige Geräteadresse hat...

Grüße, Andi

Norbert.Roller

Hallo Andi,

leider stolpere ich über meine mangelhaften Perl Kenntnisse und kann den nachfolgenden Fehler nicht selbst auflösen.
Ich benötigte noch einmal deine Hilfe, bitte :-(

Der Code sieht jetzt so aus:
sub decode_eibd($)
{
    my ($buf) = @_;
    my $drl = 0xe1; # dummy value
    my %msg;
    my @data;
#    my ($src, $dst,$bytes) = unpack("nnxa*", $buf);
    eval {my ($src, $dst,$bytes) = unpack("nnxa*", $buf)};
    if ($@) {Log (0, error while parsing message: $buf)};
    my $apci;

    $apci = vec($bytes, 3, 2);


Als Fehler erhalte ich im LOG:

2016.08.06 07:01:45 1: reload: Error:Modul 00_TUL deactivated:
syntax error at ./FHEM/00_TUL.pm line 695, near "error while"
Global symbol "$bytes" requires explicit package name at ./FHEM/00_TUL.pm line 698, <$fh> line 62.
Global symbol "$bytes" requires explicit package name at ./FHEM/00_TUL.pm line 700, <$fh> line 62.
Global symbol "$src" requires explicit package name at ./FHEM/00_TUL.pm line 710, <$fh> line 62.
Global symbol "$dst" requires explicit package name at ./FHEM/00_TUL.pm line 711, <$fh> line 62.
Global symbol "$bytes" requires explicit package name at ./FHEM/00_TUL.pm line 713, <$fh> line 62.
Global symbol "$bytes" requires explicit package name at ./FHEM/00_TUL.pm line 713, <$fh> line 62.
Global symbol "$bytes" requires explicit package name at ./FHEM/00_TUL.pm line 715, <$fh> line 62.



Andi291

Hihi...ich muss mich auch immer durchhangeln - ist mein erster Perl-Projekt :-)

Probier mal:
if ($@) {Log (0, "error while parsing message: $buf")};

Norbert.Roller

Hi,
ich glaube es hängt an der EVAL Zeile.
Habe trotzdem deine Änderung ausprobiert, hat aber den gleichen Fehler gebracht.

Global symbol "$bytes" requires explicit package name at ./FHEM/00_TUL.pm line 698, <$fh> line 62.

Irgendwas stört ihn am eval in dieser Form. Habe schon mächtig gegoogled. Die Zeile sieht für mich aber OK aus. Bin ratlos....

eval {my ($src, $dst,$bytes) = unpack("nnxa*", $buf)};

Bei Microsoft VBA hatte ich sowas auchs con mal und da mußt man das "explicit" definieren, aber das wäre ja auf Ebene FHEM. Macht also keinen Sinn.



Andi291

Hallo Norbert,

versuch mal was anderes:

    my $buf = @_;
    my $drl = 0xe1; # dummy value
    my %msg;
    my @data;   
    my $apci;

my $src = unpack ("n", $buf);
my $dst = unpack ("n", substr(2, $buf));
my $bytes = unpack ("a*", substr(5, $buf));

    $apci = vec($bytes, 3, 2);


Grüße, Andi

Norbert.Roller

Hallo Andi,
ich habe das jetzt eingebaut und FHEM wirft keinen Fehler beim Starten. (Eval ist ja auch nicht dabei).

Mal sehen wie die Fehlermeldung beim nächsten Absturz ist. Ob es die Adressen sind oder das Datenpaket.
Heute um 6Uhr war der Letzte Absturz >:(, also dauert es sicherlich bis morgen.

Norbert.Roller

Ohhh Nein. Von wegen kein Problem beim Starten. Jetzt hat er Probleme, wenn die Funktion aufgerufen wird und stolpert über:


2016.08.08 09:31:17 1: PERL WARNING: Argument "^AdM-^CM-&\0M-\0\r^T" isn't numeric in substr at ./FHEM/00_TUL.pm line 699.
2016.08.08 09:31:18 1: PERL WARNING: Argument "^AdM-^CM-%\0M-\0\rM-^?" isn't numeric in substr at ./FHEM/00_TUL.pm line 699.
....
Baue es wieder aus. Sorry.