Frage zu: Kommunikationsobjekt mit Datentyp "2 Byte non DPT" mit openHAB auslesen

[Wurschtel]

Hallo ...

ich habe mein Problem aus "KNX" hierher verschoben:

Der ABB Jalousieaktor JRA/S x.y.5.1 sendet bei Änderung oder Anforderung über ein Kommunikationsobjekt als "2 Byte non DPT" Statusinformationen zu jedem Ausgang.

Es heißt in der zugehörigen Doku:
Im Low Byte (Bit Nr. 0…7) stehen die Informationen zum aktuellen Betriebszustand.
Im High Byte (Bit Nr. 8…15) werden weitere Infos zum Antrieb (Fehler, Bewegungsrichtung usw.) übermittelt.

Ich stehe nun komplett auf'm Schlauch. Im ETS5 Gruppenmonitor sehe ich zwar, daß etwas über die zugeordnete GA über den Bus huscht, aber wie ich kommen ich an diese Infos ran? Die Sache mit dem "non DPT" ist mir schleierhaft.

Könnte mir bitte jemand helfen, ein passendes item anzulegen?.
Die Telegrammwerte der Bits 0 bis 15 sind jeweils 0 oder 1.

Gruß
Thomas

[udo1toni]

Mal wieder ein Beispiel für nicht-Standardkonforme Realisierung Du musst die Telegramme als 2-Byte Wert einlesen (z.B. DPT 7.001 könnte gehen) und den erhaltenen Wert anschließend selbst entschlüsseln:

Number MyLong {knx="7.001:1/2/3"}
Switch MyBit0
Switch MyBit1
Switch MyBit2
...
Switch MyBit14
Switch MyBit15

rule "decode"
when
Item MyLong received command
then
    var tmp = MyLong.state as DecimalType
    var state = tmp.toBigDecimal.toBigInteger
    if(state.testBit(0)) MyBit0.postUpdate(ON) else MyBit0.postUpdate(OFF)
    if(state.testBit(1)) MyBit1.postUpdate(ON) else MyBit1.postUpdate(OFF)
    if(state.testBit(2)) MyBit2.postUpdate(ON) else MyBit2.postUpdate(OFF)
...
    if(state.testBit(14)) MyBit14.postUpdate(ON) else MyBit14.postUpdate(OFF)
    if(state.testBit(15)) MyBit15.postUpdate(ON) else MyBit15.postUpdate(OFF)
end

Vermutlich gibt es wie immer auch eine elegantere Lösung
Eventuell willst Du auch nur einen Bruchteil der Bits auswerten, oder vielleicht auch garkeine davon, sondern eher die interessanten, die eigene Kommunikationsobjekte haben siehe hier

[Wurschtel]

Ah ja .... wie du siehst, steige ich immer tiefer in die Materie ein!
Deine Bemerkung zu "nicht-Standardkonforme Realisierung" bezog sich doch hoffentlich auf ABB .......

Ich glaube aber zu erkennen, wie ich das Ding anpacken muß. Die ABB Schlüsseltabelle liegt neben mir.
Ich setze mich mal dran .....

Merci

[Wurschtel]

Öhem ..... dat klappt!!!

[udo1toni]

Ja, das "nicht standardkonform" bezog sich auf ABB. Hauptsache ist ja, das Du es rausgewurschtelt hast

[Wurschtel]

Joooo .... daß man in solchen Fällen Telegramme z.B. als 2-Byte Wert einlesen und den Wert anschließend wie entschlüsseln kann, muß man aber auch erst einmal wissen. Warum dann auch noch z.B. DPT 7.001 gehört schon in die Abteilung "Geheimwissen" ..... .

Im Zusammenhang mit der ABB-Dokumentation und dem was mir der Gruppenmonitor ausgibt, bin ich auf eine weitere Merkwürdigkeit gestoßen.
Ich schreibe es nachher mal kurz zusammen!

[Wurschtel]

Ich habe die Merkwürdigkeit mal da hin

https://knx-user-forum.de/forum/öffe...pen#post966010

gepackt. Hat ja nichts mit openHAB zu tun.

[udo1toni]

Naja, das ist keine große Magie letztlich werden über den Bus Telegramme verschiedener Länge geschickt, also 1Bit, 2Bit, 4Bit, 8Bit (=1Byte), 2Byte, 3Byte, 4Byte...
Wenn ich mich richtig erinnere, kann im Telegramm auch noch eine Information über den DPT mitgegeben werden, über den DPT wird auf jeden Fall definiert, wie der Inhalt des Telegramms zu verstehen ist (also z.B., ob das eine Bit für ON/OFF, OPEN/CLOSED, UP/DOWN ALARM/NO ALARM usw. steht).

Es bleibt aber ein Bit, so oder so, und genauso funktioniert das auch mit den mehrwertigen Telegrammen. Es kann knifflig werden, falls z.B. bei Mehr-Byte-Telegrammen die Reihenfolge MSB/LSB vertauscht ist, aber wenn die Daten ohnehin über eine eigene Funktion ausgewertet werden, muss man ja sowieso wissen, was man tut

Ansonsten sind die DPT vor allem wichtig, um sicherzustellen, dass die Busteilnehmer sich gegenseitig verstehen. Ob man einen Prozentwert nun als 0-100% Öffnung, 0-100% Luftfeuchte oder 0-100% Helligkeit interpretiert, bleibt sich gleich, insofern ist zumindest der hintere Teil des DPT meist nicht so wichtig.

Der vordere Teil verrät dann die Anzahl Bits, und wie sie grundsätzlich zu verstehen sind, also z.B., ob ein Byte 0-255 bedeutet, oder 0-100 (mit einer Auflösung von ~0,4%), oder gar 0-25,5, also Auflösung 0,1, vorzeichenlos oder nicht, ob Float oder Integer (bei den Mehrbytigen natürlich). Falls man Daten auf Bitebene analysieren will, muss man eigentlich nur aufpassen, dass openHAB die Daten nicht "überinterpretiert" und in einem vernünftigen Format ablegt, also z.B. nicht als Float speichert, sondern als long Integer, insofern muss man natürlich aufpassen, welchen "Schummel-DPT" man angibt.

[vento66]

0-100 und 0-255 ist das selbe... Schick doch mal einem Jalousieaktor die 127 als DPT 5.003 und was macht der? Er fährt auf 50%

[Wurschtel]

"Schummel-DPT" gefällt mir!

Was den ganzen DPT-Informationsgehalt anbelangt (wie der Inhalt des Telegramms zu verstehen ist usw usw) ist mir noch nicht die für mich richtige Doku über den Weg gelaufen.

Grundsätzlich hast du aber recht: Ein bit ist und bleibt ein bit ....... und sollte nicht wärmer als 6° sein!

[udo1toni]

Dokumentation wäre z.B. das hier. Ist allerdings auf englisch, dafür aber die offizielle Quelle.

@vento66: Es geht ja eben darum, dass der DPT die Information liefert, wie das Telegram zu interpretieren ist. Es ist schon klar, dass es dem Busteilnehmer herzlich egal ist, welchen DPT Du zum Senden irgendwo hinterlegst, der Busteilnehmer sieht nur, dass ein Byte ankommt und wertet es anhand der internen Programmierung aus, eine 128 ist dann bei einem Rollladenaktor halt 50%.
Wenn Du 128 an ein Display schickst, welches ein signed Byte erwartet, um ein Integer darzustellen dann steht halt "-127" im Display, obwohl der Rollladen immer noch auf die Hälfte fährt. Und da man in openHAB die Daten auch konkret auswertet, muss openHAB auch eine rudimentäre Vorstellung davon haben, was das für Daten sind, wenn Du die Daten aber selbst auswertest, spielt der DPT nur für die Breite des Registers und die Reihenfolge der Informationen eine Rolle.

[Wurschtel]

Der Doku-Link läuft bei mir irgendwie ins Leere (Die von dir besuchte Seite versucht, dich an eine ungültige URL weiterzuleiten.) .....

[vento66]

Der Sollte funktionieren:

http://www.knx.org/fileadmin/template/documents/downloads_support_menu/KNX_tutor_seminar_page/Advanced_documentation/05_Interworking_E1209.pdf

[Wurschtel]

Jupppppppppppps ... der hat funktioniert!
Danke