Meldung Im Busmonitor: Data length not matching DPT

[Robert_Mini]

Ich bekomme im Busmonitor ein Warndreieck mit der Meldung "Data length not matching DPT".
Dies betrifft einen Read-request vom WG auf ein Statusobjekt, das nur bei Änderung sendet (aktives Rückmeldeobjekt), und daher zyklisch vom WG gelesen werden muss.

Irgendwie werde ich aus diesem Hinweis nicht ganz schlau bzw. weiß ich nicht, wie ich diese Meldung wegbekommen könnte.
Hintergrund: Ich vermute ein Problem mit den Influx-Diagrammen in der CV damit.

lg
Robert

[StefanW]

Erklärung:

Im KNX System haben alle Geräte Ihre Objekte, das sind die Funktionen, Werte, Einstellungen die von den Geräten zur Verfügung gestellt werden. Diese sind in der Regel fix eingestellt, also das Objekt 0815 im Aktor steht seitens des Herstellers beispielweise für "Ein / Aus". Andere sind Sperrobjekte oder Rückmeldeobjekte.

Damit nun die Objekte des Präsenzmelders ("Erkennung aktiviert") mit dem Aktor sprechen kann ("Relais an") braucht es die Gruppenadressen. Das ist, was diese binäre Information auf dem Bus transportiert.

Diese fixen Objekte bei den Herstellern haben vorbelegte EIS / Datenpunkte / Datenpunkttypen (hier wäre es "Boolean").

==> Leider läßt es die ETS zu, dass diese GAs auch abweichende DPT bekommen. Es ist sogar möglich, an ein Objekt mehrere GAs zu binden und alle haben unterschiedliche DPT Einstellungen - obwol sich der Datenpunkttyp nach dem sendenden Device richten wird.

==> Der Timberwolf Server ließt nun solche DPT aus dem Projektfile ein und wenn dort für die GA etwas anderes einbgestellt wird, als was das sendende Device tatsächlich sendet, dann interpretiert er es falsch, wobei er das nur merkt, wenn er eine andere Bitlänge erwartet, als er bekommt.

==> Prüfe bitte mit der ETS, was 1.1.254 (Dummy?) tatsächlich sendet (ein Byte) und was in der GA für 5/0/18 für ein DPT definiert wurde (vermutlich etwas anderes als 1 Byte).

Korriegieren und fertig. Oder wir haben einen Fehler im Busmonitor (aber bislang lag es an den Einstellungen beim Kunden)

lg

Stefan

[Robert_Mini]

Ich schau mir das an. Der Dummy ist das WG, der DPT ist 5, sollte vermutlich 5.001 sein.
Ich wundere mich nur, dass ein read-Telegramm einen Wert hat.

Robert

[S. Kolbinger]

Hallo Robert,

Ich denke, es handelt sich hier um einen Fehler beim Dekodieren von Read-Requests und nicht in deinen Einstellungen.

Wie hier schon mal beschrieben:
viewtopic.php?p=4289#p4289

Wir in der nächsten Release behoben sein.

Grüsse,
Stefan Kolbinger

[Robert_Mini]

Danke @S. Kolbinger!
Könnte damit auch die influx db "verfälscht" werden?
Ich kann nämlich GAs, die durch read-requests abgefragt und dann eine Antwort senden, nicht in der CV darstellen, in Grafana hab ich's noch nicht probiert.

Robert

[S. Kolbinger]

Hi Robert,

die influxdb ist davon nicht betroffen.
Dort werden beide Telegramme (Read und Response) gespeichert.
Du kannst dir ja mal die entsprechende GA in Grafana anschauen, ob es da zu dem Zeitpunkt einen Wert gibt und evtl. die Telegramme im Raw-Format anschauen.
Hier ist die KNX-Statistik-Seite ganz brauchbar.

Grüsse,
Stefan Kolbinger

[S. Kolbinger]

Hallo @Robert_Mini ,

ich habe mich gerade auf deinen TWS117 eingeloggt.
Die Antwort-Telegramme werden richtig in influxdb abgespeichert, mit den entsprechenden "Val"-Werten.
Mit folgendem Query bekommt man das in Grafana auch angzeigt:

Code: Alles auswählen

SELECT "Val" FROM "KNX_LINE27" WHERE ("GA" = '5/0/18') AND $timeFilter

Ich weiß jetzt leider nicht, wie die CV auf die influxdb zugreift und warum dort die Werte nicht zurück geliefert werden.
Hast du da vielleicht die entsprechende Query parat?

Gruß,
Stefan Kolbinger

[Robert_Mini]

Hallo Stefan!

Das Thema mit der CV hat andere Ursachen => offensichtlich erwartet die CV per default alle 300s einen Wert.
Siehe: viewtopic.php?p=6458#p6458

Diskussion läuft noch.

Robert