Control Byte does not match expected mask

[MarcelT]

Guten Morgen,

nachdem ich jetzt über Monate Logdateien von historischer Größe erzeugt habe - und zwar über Zeilen wie diesen

Code Auswählen Erweitern


2015.12.01 07:09:09 3: Control Byte 0x9c does not match expected mask 0xB0
2015.12.01 07:09:09 3: TUL EIB refused message: 9c11032514e2008000
2015.12.01 07:09:09 3: Control Byte 0x9c does not match expected mask 0xB0
2015.12.01 07:09:09 3: TUL EIB refused message: 9c11032514e2008000
2015.12.01 07:09:09 3: Control Byte 0x9c does not match expected mask 0xB0
2015.12.01 07:09:09 3: TUL EIB refused message: 9c11032514e2008000
2015.12.01 07:09:13 3: Control Byte 0x9c does not match expected mask 0xB0
2015.12.01 07:09:13 3: TUL EIB refused message: 9c11032523e2008000

und nach Lektüre des Beitrags von Matthias Urlichs vom 3.9.2015 unter http://www.meintechblog.de/2014/06/knx-eib-gateway-in-fhem-einbinden/

für mich sieht das so aus, als wäre der entsprechende test im FHEM-Modul falsch. Da steht (beim mir in Datei FHEM/00_TUL.pm Zeile 747):

if(($ctrl & 0xB0)!=0xB0)

Die entsprechende Codestelle im knxd sieht ganz anders aus, da steht stattdessen (auf FHEM übersetzt):

if(($ctrl & 0xD0)!=0x90)

Ersetz diese Zeile doch mal und schau nach ob das was bringt.

habe ich die Änderung in 00_TUL.pm (bei mir ist es Zeile 776) durchgeführt. Seitdem ist Ruhe, aber so richtig verstanden warum die ursprüngliche Zeile falsch sein soll habe ich nicht. Habe ich durch die Änderung vielleicht jetzt einfach nur die Fehlerprüfung abgeschaltet, oder ist es wirklich ein Codefehler der allgemein behoben werden sollte?

Viele Grüße
Marcel

[Andi291]

Morgen!

Dazu gab es schon einige Beiträge. Ich hab mich damit auch schon länger auseinander gesetzt.

Fakten dazu:

1. Der Fehler tritt nur auf, wenn die TUL ohne EIBD/KNXD betrieben wird
2. Die Auftretenswahrscheinlichkeit geht massiv runter, wenn die Geschwindigkeit auf 38000bps begrenzt wird
3. Der Fehler scheint gehäuft aufzutreten, wenn gerade viel Verkehr auf dem Bus ist

Der Unterschied zwischen 0xB? und 0xC? liegt wohl darin, dass im einen Fall eine Sendewiderholung in den unteren Layern (Interpretation: Kollision) vorliegt, im anderen Fall nicht. Allerdings bin ich protokollmäßig nicht fit genug, um das tiefer zu analysieren.

Bis dato habe ich von allen Usern, die zwischen TUL und FHEM den EIBD/KNXD zwischengeschaltet haben, nichts mehr gehört. Der KNXD kann damit wohl umgehen und kapselt den Zustand (Fehler würd ich es nicht nennen).

Drum meine Empfehlung:
KNXD einbauen!

Grüße, Andi

P.S.: Wenn ändern müsste man eigentlich so ändern:

Code Auswählen Erweitern

if ((($ctrl & 0xB0)!=0xB0) and (($ctrl & 0x90)!=0x90)). Oder das Wiederholungsbit gleich ignorieren:

Code Auswählen Erweitern

if (($ctrl & 0x90)!=0x90). Die von Dir genannte Variante hätte zwar die gleiche Auswirkung, ist aber nicht korrekt (1?01 wird mit 10?1 verglichen).
Kannst gerne ein wenig experimentieren. Wenn was brauchbares rumkommt, checke ich das gerne in.

Quelle:
https://de.wikipedia.org/wiki/KNX-Standard#Paket-Struktur

[smurfix]

Meiner Ansicht nach ist der Test nicht in Ordnung; er hat schlicht das falsche Bit geprüft und funktionierte daher nur zufällig.

Nebenbei bemerkt dachte ich eigentlich, ich hätte das auch hier irgendwo eingekippt ...

[Andi291]

Abend!

Kann sein - muss mir entweder entgangen sein, oder war vor meiner Zeit

Welches Bit würdest Du prüfen?

Grüße, Andi

[MarcelT]

kurzer Zwischenstand von mir:

smurfix hatte natürlich Recht - war Zufall weil in den letzten Stunden gar nichts über den Bus lief; das hatte ich natürlich mal wieder nicht bedacht. So bald ich ein paar Rolläden schalte geht es wieder los.

Mit der Datenrate habe ich auch schon gespielt und sie bis auf 9600 heruntergesetzt, was aber an der Meldungshäufigkeit überhaupt nichts geändert hatte. Verkehr auf dem Bus ist bei mir minimalst weil bisher nur "manuell" über FHEM-Browserseite Rolläden verfahren werden. Ich meine zu glauben, dass die Meldung JEDES Mal kommt wenn FHEM auch nur einen einzigen Befehl auf den Bus gibt.

Wenn es sich durch Zwischenschalten von knxd lösen lässt ist das vielleicht die einfachste Variante. Bei der knxd-Installation habe ich mich aber so dämlich angestellt, dass ich ihn nicht zum Laufen bekommen habe. Das fand ich dann eine gute Gelegenheit die Wheezy-Installation komplett neu aufzusetzen.

[MarcelT]

knxd installiert, Meldung dauerhaft verschwunden. Bin zufrieden, zumal ich jetzt auch ETS und FHEM parallel zugreifen lassen kann was vorher nicht ging.

Leider gehtd er knxd-Autostart nicht - aber dafür habe ich einen anderen Forumsbeitrag gefunden, da klinke ich mich mal ein.

[Andi291]

Morgen!

Der Vollständigkeit halber: wie im anderen Thread erwähnt, habe ich an der TUL noch ein wenig getuned. Änderungen sind eingechecked.

@Marcel: wenn Du es nochmal direkt mit dem TUL-Sitck probieren könntest, wär ich nicht undankbar :-P

Den Thread bitte zu machen.

Grüße, ANdi

[MarcelT]

so, lang ists her, und FHEM hat bei mir nach dem update wieder direkt auf den TUL Zugriff. Die ursprünglichen Meldung taucht nicht mehr in der Logdatei auf. nach wie vor funktioniert sonst alles problemlos. So gesehen alles super jetzt.

Vielen Dank an dich, Andi!

Grüße
Marcel