KNX-Integration fehlerhafte DPT-Dekodierung bei DPT 16.001

[tsb2001]

Hallo zusammen,

hat irgendwer eine Idee, was das sein könnte?

Ich habe einen MDT AKH und habe dort pro Kanal die Diagnoseobjekte als Gruppenadresse zugewiesen.
Die Daten kommen auch ordnungsgemäß in der Diagnoseansicht der ETS an.

Sieht dann so aus:
image.png

Im Homeassistant kommt das dann als Warnung mit:

DPT decoding error. Telegram from 1.0.14 to 5/3/13 with payload <DPTArray value="[0x57,0x69,0x20,0x48,0x20,0x50,0x57,0x4d,0x20,0x42, 0x59,0x54,0x45,0x30]" /> can't be decoded by DPTSwitch: <CouldNotParseTelegram description="Invalid payload type for DPTSwitch" expected_type="DPTBinary" payload="<DPTArray value="[0x57,0x69,0x20,0x48,0x20,0x50,0x57,0x4d,0x20,0x42, 0x59,0x54,0x45,0x30]" />"/>

Konfiguriert ist der so:
image.png

Was mich wundert:

1. der DPT ist vom Typ als "latin_1" definiert, was dem DPT 16.001 entspricht
2. es kommt "Invalid payload type für DPTSwitch" und er verlangt ein "DPTBinary", obwohl der DPT16.001 dazu (mit latin_1) konfiguriert ist
3. der Aktor sendet - richtig - ein "DPTArray"

Nun kommt das interessante:
Im Normalbetrieb bekomme ich das trotzdem so angezeigt, er dekodiert trotzdem richtig
image.png

Ärgere ich den Aktor nun und nehme dem die Spannung weg, dekodiert er wieder richtig, wirft aber trotzdem die Fehlermeldung (Warnung) mit dem ähnlichen Inhalt wie oben (klar, das Array ist anders gefüllt, muss ja 230V-Fehler beinhalten)

Das Ergebnis passt aber auch dann:
image.png

Fazit: technisch funktioniert es, aber das Protokoll läuft trotzdem voll.

Was kann da sein?

[henfri]

Der Bus Monitor verwendet die Dpt aus dem ETS Projekt.

Es scheint, als hättest du in der yaml die entities als Switch/binary konfiguriert. Das fehlt in deinem Screenshot

[tsb2001]

yaml die entities als Switch/binary konfiguriert

Nöö,
der läuft ganz einfach unter der Entität als "sensor" in der KNX-Integration als "latin_1" der den DPT dann passend dekodieren sollte. Zumindest nach der Anleitung der KNX-Integration:
image.png

Direkt oben drüber rufe ich noch ganz andere Dinge ab, die alle nicht binär sind:
z.B. illuminace (DPT 9.004) als Helligkeitswert, time_period_sec (DPT 7.002) als Nachlaufzeit; die funktionieren alle einwandfrei):
Da ist nix mit binär, die binären DPTs kommen an einer ganz anderen Stelle...
image.png

Das kann es also schon mal nicht sein...

[henfri]

can't be decoded by DPTSwitch: <CouldNotParseTelegram description="Invalid payload type for DPTSwitch" expected_type="DPTBinary"

[zenvy]

Also, der Sensor funktioniert wie gewünscht aber trotzdem kommen im Log Dekodierungsfehler. Hast du die gleiche GA bei einem Switch gesetzt? Durchsuche mal deine yaml nach der GA und schaue ob die nur einmal vorkommt.

[tsb2001]

Hast du die gleiche GA bei einem Switch gesetzt?

Schade, das hätte sein können.
Aber das Suchergebnis wirft mir tatsächlich nur einmal die Adresse aus:
image.png

Aber die Idee war schon nicht schlecht...
...und genau das hat mich zum passenden Gedanken geführt denn:

Vorher wurde dieser gesamte KNX-Adressbereich für einen Theben Cheops genutzt.

Ich habe die Adressen geändert, daher könnte es sein, dass bis vor vier Wochen die 5/3/13 tatsächlich eine binäre Adresse beinhaltet hat.
Aber seit dem hat das System schon dutzende Neustarts gehabt, inklusive häufiger einem neugestarteten Host.

EDIT: Gefunden!!!
In der hochgeladenen Projektdatei verbirgt sich die alte Gruppenadresse.
Es war die 5/3/13 als "Stellantrieb gestört" mit dem DPT 1.001 vom Theben Cheops.
Die habe ich nämlich noch nicht aktualisiert. Das ist auch der Grund, warum er bei den höheren Adressen nicht meckert, die waren vorher nie vergeben.

Vielleicht kann meti etwas dazu sagen, warum in der YAML der richtige Code steht, aber aus dem hochgeladenen Projekt der (alte und falsche) Datenpunkt ausgewertet wird und das einen Fehler im Protokoll generiert...

image.png

EDIT: Um die frage auszuformulieren: Warum dekodiert er zunächst mit den aktuellen und richtigen Datenpunkten aus der YAML, generiert ein richtiges Ergebnis UND startet offensichtlich einen zweiten Dekodierungsversuch mit der Projektdatei, die dann wegen älterem Datenstand da was binäres im Bauch hat und wirft dann den Fehler?
Doppelt gemoppelt ist in dem Fall eher Fehleranfällig...

[tsb2001]

Zur Info: Projektdatei gelöscht, Fehler weg!

[henfri]

Warum dekodiert er zunächst mit den aktuellen und richtigen Datenpunkten aus der YAML, generiert ein richtiges Ergebnis UND startet offensichtlich einen zweiten Dekodierungsversuch mit der Projektdatei

Das hatte ich in meiner ersten Antwort ja schon geschrieben.

meti es ist natürlich so schwer zu debuggen.

Eine Fehlermeldung (und kein Traceback) dass das Telegam mit

• Dem DPT aus der Yaml

Oder

• Dem DPT aus der Projekt Datei

Nicht dekoriert werden konnte wäre gut.
tsb2001vielleicht machst du dazu einen issue. Das bevorzugt meti

[tsb2001]

machst du dazu einen issue. Das bevorzugt

Und ich bevorzuge fast seit 50 Jahren die deutsche Sprache. Daher bin ich über dieses Forum froh, dass ich mich da austauschen kann und ich auch was verstehe.

Für einen „issue“ in Github fehlt mir leider die sprachliche Kompetenz; daher wird es vermutlich dort - zumindest von mir - niemand erfahren werden…