DPT Typ aus Telegramm lesen

[herste]

Hallo zusammen,

ich kann leider keine Information darüber finden, ob und wie der DPT Typ in ein KNX Telegramm (TP) eingeschlüsselt ist. Daher ist meine erste Frage, ob man aus dem Payload eines KNX TP Telegramms überhaupt den DPT Typ ableiten kann?

Vielen Dank für Eure Hilfe,
Harry

[givemeone]

Nein, nur die Länge, wieviel bits geschrieben werden. Daraus kann man nur grobe Schlüsse ziehen, nichts zuverlässiges.

[Beleuchtfix]

Wie weiß ich leider nicht, imho wird nur der übergeordnete Typ gesendet, also 1 Bit, 1Byte, 2Byte etc. Im Busmonitor kannst du auch die kompletten Rohdaten anschauen, vielleicht erkennst du da etwas.
Viel Erfolg, Florian

[Klaus Gütter]

Daher ist meine erste Frage, ob man aus dem Payload eines KNX TP Telegramms überhaupt den DPT Typ ableiten kann?

Nein, kann man nicht.

[herste]

Hallo zusammen,

vielen Dank für die schnellen Antworten. Da ich kein Kenner der ETS bin (sondern eher auf Rohdatenebene unterwegs), gibt es evtl. Alternativen die Datentypen mitzubekommen? Könnte man in ETS evtl. eine GA pro Datentyp einrichten und Teilnehmer welche einen GroupValueWrite absetzen dazu bekommen eine "Drop Copy" auf diese GA zu senden? Oder habt Ihr evtl. andere Ideen?

Grüße,
Harry

[Beleuchtfix]

Was willst du erreichen? Bist du Hacker? Vielleicht ist ein Dummy Gerät das, was du brauchst, im Online Katalog mal nach Dummy suchen.
Gruß Florian

[herste]

Hallo Florian,

ich arbeite gerade an einer bidirektionalen KNX <> MQTT Bridge. Wie ein Dummy-Gerät mir hier helfen kann übersteigt leider meine ETS Kenntnisse.

Grüße,
Harry

[Beleuchtfix]

Das übersteigt dann meine Kenntnisse, aber viellicht wäre es einfacher, wenn du erst einmal KNX verstehst.

Gruß Florian

[givemeone]

Und welche Datentypen du benutzt. Binärdaten sind ja recht eindeutig, also dpt1. Wenn du nur das hast, ist alles leicht. Ansonsten geht's einfach nicht zuverlässig. du kannst nur aus dem Export der ETS heraus die Datentypen lesen.

[herste]

Hallo Florian,

ich meine KNX schon recht gut zu verstehen - nur eben von "der anderen Seite aus", also von dem Punkt ausgehend was man auf dem Kabel passiert und man auf dem Oszi sehen kann ;-). ETS ist für mich nur insofern bekannt, als das ich damit das Eigenheim "automatisiert" habe - also nicht tiefer gehend als Sensoren und Aktoren zu verbinden.

@givemeone: Alles klar, vielen Dank. Wäre ein Ansatz denkbar, eine GA pro Datentyp zu bauen und diese extern abzufangen?

Grüße,
Harry

[Klaus Gütter]

Du wirst die Metadaten einer GA aus der ETS benötigen. Dazu hat die ETS einige Exportfunktionen, z.B. den "OPC Export".

[herste]

Hallo Klaus,

ich könnte ja eine GA pro DPT aufbauen, also z.B. 15/0/0 für 1bit, 15/0/1 für 2bit, etc. - damit habe ich auf der Bridge die PA des Absenders und wüsste wie ich den Payload zu parsen hätte.
Ich müsste nur sicherstellen können, dass die Sensoren zusätzlich auf die entsprechenden GA schreiben. Das wäre machbar, oder? Bin natürlich für alle anderen Ideen offen :-)

Grüße,
Harry

[Beleuchtfix]

Das geht nicht, KNX sendet immer nur eine GA! Zu Zuhörer muss wissen, was er erwartet, also musst du dich mit den GAs aus der ETS auseinandersetzen.
Gruß Florian

[Gast1961]

Ich müsste nur sicherstellen können, dass die Sensoren zusätzlich auf die entsprechenden GA schreiben. Das wäre machbar, oder?

Nein, das ist ausgeschlossen. Ein KNX Kommunikationsobjekt schreibt genau auf eine GA. Es kann auf mehreren hören, aber nur auf einer GA senden.

Deine Grundidee, den Absender (physikalsiche Adresse) auszuwerten anstelle der Gruppenadresse klingt ohnehin konzeptionell falsch.

[wknx]

Hast Du schon mal einen Blick in die KNX-Spezifikation geworfen? Kannst Du nach Anmeldung auf knx.org kostenlos herunterlade. Die gibt ziemlich detailiert Aufschluss darüber wie KNX-Telegramme aussehen.

Payload in einem (nicht Long-Frame) Telegramm sind 1 bis 14 Bytes. Du kannst hier also nicht einmal eindeutig bestimmen ob Daten für eine DPT mit 1Bit, 2Bit oder 1Byte gesendet werden. Durch scharfes Hinsehen kann man aus Logsnatürlich trotzdem begründete Vermutungen ableiten.

Könnte man in ETS evtl. eine GA pro Datentyp einrichten und Teilnehmer welche einen GroupValueWrite absetzen dazu bekommen eine "Drop Copy" auf diese GA zu senden? Oder habt Ihr evtl. andere Ideen?

KNX-Geräte senden (je KO) immer nur auf (maximal) eine GA. Wenn Du nun alle gesendeten Werte zusätzlich noch auf eine gemeinsame GA sendest, dann würdest Du damit auch keinen Mehrwert schaffen. Ohne die zugehörige GA kannst Du mit dem Wert nämlich nichts mehr anfangen, weil Du dann unterscheiden kannst ob Licht A oder B geschaltet werden soll, oder es sich um eine Statusrückmeldung von Licht A oder B handelt.

ETS ist für mich nur insofern bekannt, als das ich damit das Eigenheim "automatisiert" habe - also nicht tiefer gehend als Sensoren und Aktoren zu verbinden. […]Wäre ein Ansatz denkbar, eine GA pro Datentyp zu bauen und diese extern abzufangen?

Auch damit würdest Du nichts gewinnen.

Ich kenne mich mit MQTT nicht wirklich aus und habe auch noch nicht genau verstanden was exakt Du erreichen willst. Du wirst nach Meinem Verständnis aber irgendeine Form von Mapping zwischen MQTT-Topics und KNX-GAs benötigen. Ein Dummy-Gerät kann dabei helfen diese Anbindung nach außen in der ETS sichtbar zu machen, weil Du ansonsten vielleicht GAs im Projekt hast die laut ETS nur eine Verknüpfung haben.

Ein ggf. einfacher Ansatz (vielleicht aus MQTT-Sicht aber auch kompletter Unsinn) könnte darin bestehen die GAs und DPTs einfach direkt durch korrespondierende MQTT-Topics abzubilden. Also z.B. die GA 1/2/34 mit DPT 1.001 aufs Topic knx/1_2_34/1_001