FHZ Protokoll Kenner gefragt BUG im Device::SerialPort

[andiwi]

Hallo,

ich hoffe niemanden zu nerven. Aber ich bin jetzt nochmals ins Debugging der FHZ eingestiegen.

Ich hatte ja in einem andere Thread schon die Autocreate Prolematik angesprochen, dass es da zu Fehlern mit der FHZ bzw 2 FHZ's kommt.

Mein jetztiges Debugging der 10_FS20.pm ergab, dass bereits in der Message-Queue falsche Daten drin sind. $msg enthält falsche Daten, die zu weiteren Fehlern führen.

Nachdem ich Breakpoints im FHZ Modul gesetzt habe, ist mir aufgefallen, dass schon RAW nach allen paar Stunden, manchmal Tagen Fehler der FHZ ankommen.

dies hab ich jetzt mal mit dem elv.pl der FHZ4Linux Seite nachvollziehen können.

von Device::SerialPort erhalte ich z.B folgendes defekte Daten:

Got: 810c04de 0909 a001 4e2e 44006902
[810c]
[04e30909a0014e]
[2e4b006702]
Got: 810c04e3 0909 a001 4e2e 4b006702
[810c810c041609]
[09a0014e2e7e006702]
main::(elvf.pl:94):           print "unknown device\n";

im Header der letzten Message ist der Message Header dupliziert statt 810C04.. steht dort 810C810C04 - meines Erachtens ein Bug in der Input Funktion des Port Treiber.

Meine Fragen vor allem an Rudi bestehen zu 2 Stellen in der FHZ.pm

welche Funktion hat folgender Code. Wurde da evtl ein Workaround für den Bug geschrieben. Ein function 0x81 ist mir nicht bekannt...

if(substr($fhzdata,2,1) eq $msgstart) { # Skip function 0x81
<------>$fhzdata = substr($fhzdata, 2);
<------>next;
      }


zum anderen kommt es beim Einlesen der FHZ bei einem Fehler Paket zu weiteren, weil nicht auf den nächsten korrekten Header getriggert wird. Wäre im folgenden Code nicht besser nach dem nächsten Startcode zu suchen, statt den ganzen Buffer zu verwerfen, da ja beim nächsten Read der Header wieder an Stelle x statt auf 0 steht..

if($len>20) {
      Log 4,
<------> "Oversized message (" . unpack('H*',$fhzdata) . "), dropping it ...";
      $fhzdata = "";
      next;
    }

Testweise hab ich jetzt mal das elv.pl Programm von input auf Read umgestellt. Werden die Woche dann von den aktuellen Ergebnissen berichten.

kurzes Update: die Fehler kommen nicht vom Port Treiber (auch bei der Read Funktion), sondern sind auch beim Kernel Debugging des FTDI_sio schon vorhanden. Also kommen von der FHZ diese Daten. Eine zweite FHZ produziert bei mir exakt dieselben Wunderpakete.

Gruß Andreas

[andiwi]

hier nun das versprochene Update der Fehleranalyse.

das Anlegen von Devices mit falschem Hauscode stammt weder von einem Bug im Serial Port Treiber noch von der FHEM Software.

Das Tracen der RAW Messages meiner beiden FHZ lies immer wieder folgenden Code auftauchen:

1.)

810c810c04ad0909a00109230000

in diesem Messages ist einfach der Header dupliziert. In der FHEM Software, wird dieser dann aufgrund CRC Fehlers in der Regel um die ersten 2 Bytes gekürzt. Beim 2. Anlauf stimmt die Message dann, sofern die CRC korrekt ist. Da ich 2 FHZ's im Einsatz habe, konnte ich feststellen, dass von der einen der duplizierte Header von der anderen der normale ankam. In manchen Fällen ist die Message nach Entfernen des duplizierten Header brauchbar, manchmal stimmt aber auch dann die CRC nicht.

Wo diese Fehler herkommen, ist nicht messbar. ob in den FHT's auf der Luflinie oder in den FHZ's ist fraglich...

2.)

folgende falsche Pakete kommen auch zeitweise vor, was meinen Glauben in die FHZ fast sterben lies.

810c04b50101a001105c0000a600

dies scheint ein normales FS20 Paket zu sein, ist es aber nicht! Auf der andern FHZ kommt das Paket nämlich auch rein dort sieht es aber anders aus:

810c04c50909a001105c0000a600 (hoffe da ich das richtige rauskopiert habe und die CRC valid ist)

und in der Tat, ein FS20 mit Hauscode 105C gibt es im Haus nicht, jedoch einen FHT.

ich konnte es erst nicht glauben, hatte aber dann aus meiner Windows Eigenentwicklung noch einen ca 50MB großen RAW Logfile - und auch dort sind alle solchen defekten Pakete drin.

Resultat für mich - Autocreate bei Verwendung von FHZ's in FHEM immer aus - sonst hat man nach 1-2 Tagen Schrott in den Devices.

Vielleicht hilft die Info dem einen oder anderen, der selbst auf solche ungültigen Devices durch Autocreate in Verbindung mit einer oder mehreren FHZ's gestossen ist.

Lob nochmals an die FHEM Software und alle Entwickler.

so und jetzt wollen wir mal in die Produktion gehen.....

Gruß Andreas