Transform KNX: DPT1.001: Aus 0 macht 0x80?

[tuxedo]

Hallo zusammen,

meine ersten gehversuche mit meinem CV Setup und meinem eigenen backend sind etwas holprig:

Ich habe ein Switch-Widget mit dem ich gerne eine Lampe schalten möchte.

in der Visu Cofig steht das:

        <switch on_value="1" off_value="0" mapping="On_Off" styling="Green_Red" bind_click_to_widget="true">
          <label>Licht Büro<icon name="control_on_off"/></label>
          <address transform="DPT:1.001" mode="readwrite">1/1/130</address>
          <address transform="DPT:1.001" mode="read">1/4/130</address>
        </switch>

Wird auch angezeigt. Drücke ich da nun drauf, wird versucht "aus" (off_value=0) zu senden. Im Backend kommt aber "0x80" an... 80? Der Hex-Wert für aus in KNX ist 0x00???

hab das dann mit dem JS Debugger in Chrome verfolgt, und bin hierauf gestoßen:


transform_knx.js

.
.
.
Transform.addTransform( 'DPT', {
  '1.001': {
    name  : 'DPT_Switch',
    encode: function( phy ){
      return (phy | 0x80).toString( 16 );
    },
    decode: function( hex ){
      return parseInt( hex , 16 );
    }
  },
.
.
.

Versteh ich nicht... Warum wird der Wert mit 0x80 ver-order-t?

Hab die 80 an anderer Stelle im Transform-Code wieder gefunden. Versteh's aber immer noch nicht.

Kann mir mal jemand einen Zaunpfahl entgegen werfen?

[jolt]

Riecht irgendwie nach APCI wenn du mich fragst...

[tuxedo]

An sowas hab ich auch schon gedacht. Aber knxd als Backend nimmt doch keine apci-telegrammabschnitte entgegen? Der fügt den rohwert ja selbst ein und konvertiert/rechnet um wenn nötig, oder?

[jolt]

Ich wäre mir da nicht so sicher. Leider ist der Backend Code für normalsterbliche wie mich nicht gerade intuitiv. Da wird auf jedenfall ziemlich viel gebastelt und Low Level mit dem knxd gesprochen. Eine Suche nach 0x80 liefert auch einen Kandidaten:

https://github.com/knxd/knxd/blob/ma...ite-cgi.c#L252

Passt soweit ich es überblicke nicht auf deinen Fall, aber zeigt das hier wilde Annahmen und "Protokolle" existieren die man so erst einmal nicht unbedingt erwarten würde...

[tuxedo]

Danke für den Zaunpfahl. Da hätte ich auch drauf kommen können da nach zu schauen.

Hab den Code mal auf dem Kopf gestellt:

Da scheint etwas undokumentiert zu sein:

Statt "a" für die Adresse und "v" für den Wert, kann man hier wohl auch "d" mit DPT mitschicken.
Wenn der nicht mitgeschickt wird, dann ist der 0. Und im Fall von 0 befindet man sich exakt an der Stelle die du rausgesucht hast.

Und hier geht es um Byte 1 im APDU. Schaut man in der Spec nach (Vol3. Part3, Chapter 7, Application Layer, Seite 4), dann steht hier das Bit 7 und 6 in Byte 1 "10" sein müssen. Bit 5..0 sind dann die Daten.

Da ich eine 0 schicken wollte, sind die Daten ebenfalls 0.

Zusammengebaut
10 + 000000 -> 10000000 (bin) --> 0x80 (hex)

Zu deutsch: CV verodert den Wert deshalb mit 0x80, weil damit gleich die APDU Byte1 gebaut wird.

Schickt man "d=1" mit (für DPT1), dann entfällt der Check auf 0x80. Stattdessen werden nur die rechten 6 Bits vom Wert genommen (0x3f) und auf das byte1 drauf-geodert.



--> Alles in allem: wirklich doof gelöst. Vor allem weil "d=" im CV Protokoll nicht dokumentiert ist, und CV sich daraum auch nicht kümmert. Stattdessen wird "workaround-artig" der Wert von CV so angepasst dass das knxd backend ihn ohne zu murren frisst.

Somit ist der knx_transform-Teil in CV keine KNX Transformation des DPTs in einen Raw-Hex-Wert (wie man ihn in der ETS im Gruppenmonitor so schön mitlesen kann, und wie man es hier erwartet hätte), sondern eine Transformation des Werts in den entsprechenden Wert für Byte1 der APDU.

Der knx-transform-Teil ist somit nicht spezifisch für KNX, sondern für das knxd Backend. --> Der Name ist also äußerst irreführend.

Klingt nach einem Workaround für einen Workaround.


Muss jetzt mal schauen wie ich das mit meinem Backend mache. Dachte eigtl. ich kann hier auf bestehendes zurückgreifen. Aber entweder muss ich irgendwie mit RAW-Werten klarkommen, oder ich muss "transform_knx.js" kopieren, den 0x80 blödsinn entfernen und einen neuen Transformationsprefix schaffen (vllt. statt "DPT:1.001" dann "HEX:1.001") ...

Kommentare? Vorschläge?

[jolt]

Ich würde im Backend ein Flag einführen: needsAPCIHack. Das setzt dann nur das knx Backend. Das Flag müsste man dann irgendwie nach transform_knx.js tunneln. Kenne leider den Code nicht, hoffentlich geht das ohne größere Klimmzüge.

[tuxedo]

Ich glaube du hast dich kompliziert ausgedrückt...

Vielleicht meinst du das hier:
Beim Login in knxd dem Client ein Flag mitteilen: "Hey, ich brauch den Hack". Der Client kann dann in abhängigkeit davon in seinem knx-transform entweder die APCI-hack-Variante, oder die erwartete "hex string"Variante zurückliefern.

Da würde man halt bis auf weiteres (vermutlich für ewig) den Hack mit sich rumschleifen. Würde gehen, wäre aber halt nicht ganz so schön.

Am besten wäre es, der knxd würde in seinem write-cgi mit hex-Werten ohne den Hack klarkommen. Dann könnte man die knx transformation gerade ziehen.
Hätte den Nachteil dass die Anwender den knxd auf den neusten Stand bringen müssten um mit der neusten CV arbeiten zu können.

Oder man lässt alles wie es ist (never change a running system) und führt einfach eine Transformation ein, die das macht was man erwartet hätte (zumindest ich hab hier, wie beim read, einen hex-string erwartet) und vergibt einen eindeutigen, sprechenden Namen. Sowas wie "RAW_DPT:......" oder "HEX_DPT" oder oder oder.

Letzteres wäre dann lediglich für "zukünftige KNX Backends" von Interesse (so wie meines). OH hat ja eh ein eigenes Format.

ODER man baut den CV gleich so, dass man ohne großes Zutun Plugin-Artig ein neues backend hinzufügen kann?! Dann kann jeder backend-Entwickler sein Süppchen kochen (was auch seine Vor- und Nachteile hat).

Am liebsten wäre es mir CV würde ein Standardformat für KNX vorgeben.
Man könnte jetzt argumentieren, dass man das bestehende knxd Backend als Referenz nehmen und als Standard-Weg im Protokoll festlegen könnte. Aber mal ehrlich:
Lesen als Hexwert und senden als (0x80 | Hexwert) ist irgendwie doof.

Wäre doch toll wenn hin und rückweg gleich wären.

[tuxedo]

Puuh, ich komme vom hundertstel ins tausendstel:

KNX unterscheidet zwischen <1byte Daten und >=1byte Daten.

Im ersten Fall wird z.b. das Schalt-Bit für AN (0x01) auf KNX Protokollebene zu 0x80|0x01 --> 0x81 .. Also komprimiert in einem Byte
Sende ich aber mit DPT5.005 die Zahl 1 (0x01), so wird daraus auf KNX Protokollebene 0x80 0x01 .. Also zwei Byte.

Im Backend würde von der Visu aber jedesmal 0x01 ankommen.

So ein Mist. Wie weiß ich jetzt im Backend ob ich 0x81 oder 0x80 0x01 senden muss?!
Hmmpf.

[Chris M.]

Die CometVisu (also das Protokoll, der Client, die Lib, ...) wissen erst mal nichts vom KNX.
Was Du hier siehst ist im transform_knx.js, was auf dem CometVisu Protokoll aufsetzt (denke an Schichten-Modell). Da wird zwischen dem übersetzt was das eibd/knxd Backend braucht und was JavaScript so intern nutzt. Ein anderes Backend (wie OH) wird hier andere Übersetzungen brauchen.

Und damit kommen wir auch schon zu den 0x80. Der KNX kennt Datentypen die kleiner als 8 Bit sind. Aber wenn ich mich darum kümmern wollen täte, müsste ich zwischen groupwrite und groupswritre unterscheiden - oder einfach maskieren und als Byte verschicken...

[jolt]

Kannst du nicht wissen

Entweder du schickst den Wert + DPT Typ getrennt an das Backend oder halt einen bereits KNX konform encodierten Wert.

Beides sind (meiner Meinung) nach aber nur Workarounds. Hier finde ich die openHAB Lösung ziemlich smart. Man hat nur eine Stelle wo man seine GA's definiert (und ggf. den Typ). Nämlich in den Items Config Dateien. In der Visu und sonst wo in openHAB arbeitet man dann nur noch mit symbolischen Namen und muss sich keinen Kopf darum machen welches Encoding gerade gebraucht wird und wie die KNX Adresse gerade ist etc etc.

Sowas fehlt dem knxd noch, eine items Config Datei wo man seine GA's definiert und das DPT Mapping hinterlegen kann. Eine entsprechende Diskussion gab es hier mal: https://github.com/knxd/knxd/issues/7

Mich nervt es total, dass man an 10 verschieden Stellen seine Gruppen Adressen hinterlegen muss (ETS, Visu, Logic Engine, Eibd, etc etc) Das macht Ändern einer GA extrem ineffizient bis unmöglich. Einer der Gründe warum ich auf openHAB als mein Backend setze.

[Chris M.]

Sowas fehlt dem knxd noch, eine items Config Datei wo man seine GA's definiert und das DPT Mapping hinterlegen kann. Eine entsprechende Diskussion gab es hier mal: https://github.com/knxd/knxd/issues/7

Mich nervt es total, dass man an 10 verschieden Stellen seine Gruppen Adressen hinterlegen muss (ETS, Visu, Logic Engine, Eibd, etc etc) Das macht Ändern einer GA extrem ineffizient bis unmöglich.

Richtig. Die CV muss aber (leider) mit dem leben was es aktuell gibt.

Wenn der knxd in Zukunft selber De- und Encodieren kann und dies mit lokalem Wissen macht, dann kann die CV da gerne drauf wechseln.

[jolt]

Schon klar, ich wollte nur sagen, wenn man wie tuxedo etwas Neues anfängt (und dazu noch seinen Anspruch es richtig zu machen kennt ), dann würde ich das Pferd so aufzäumen wie in openHAB. Einmal Arbeit in eine vernünftige Items Verwaltung inkl. Typen gesteckt und man profitiert davon an vielen Stellen.

Zumal seine Logik Engine das bestimmt auch nutzen könnte

[Chris M.]

Genau so ist's auch richtig.

Dabei noch ein kleiner Implemntierungshinweis: das CV-Protokoll spezifiziert Namespaces. Gerade wenn man eine Logik-Engine hat und die CV verschiedene Datenquellen anzeigen (z.B. Bus-Daten und interne Logik-Daten) soll kann das interessant sein. Gerade für diesen Anwendungszweck ist das reingekommen...

[tuxedo]

Da wird zwischen dem übersetzt was das eibd/knxd Backend braucht und was JavaScript so intern nutzt. Ein anderes Backend (wie OH) wird hier andere Übersetzungen brauchen.

Ok, verstanden. D.h. die Transformation ist nicht allgemein, sondern Backendspezifisch. Gut.

Kannst du nicht wissen
Entweder du schickst den Wert + DPT Typ getrennt an das Backend oder halt einen bereits KNX konform encodierten Wert.

Nein, hast recht, kann ich nicht wissen. Ist aber die Frage ob ich's wissen muss. Wieso? Komm ich gleich drauf zurück.

Beides sind (meiner Meinung) nach aber nur Workarounds. Hier finde ich die openHAB Lösung ziemlich smart. Man hat nur eine Stelle wo man seine GA's definiert (und ggf. den Typ). Nämlich in den Items Config Dateien.

Nicht ganz korrekt. Wenn man's genau nimmt, hat man's in OH dann bereits zum zweiten mal konfiguriert. Das erste mal war's nämlich in der ETS.
Einer der Gründe warum meine Logik-Engine etwas anders funktioniert: Hier benutzt man statt der Adresse oder eines Namens den man zusätzlich konfiguriert hat, einfach die Bezeichnung der GA wie man sie in ETS hinterlegt hat. Fertig. Damit kann ich in ETS schalten und walten wie ich will und muss nachgelagert nix umkonfigurieren (Solange der GA Name sich nicht ändert).

arbeitet man dann nur noch mit symbolischen Namen und muss sich keinen Kopf darum machen welches Encoding gerade gebraucht wird

Danke, damit hast du mich wieder an etwas erinnert:

Mein ETS parser zieht nicht nur Name und GA aus der .knxproj, sondern auch den DPT. Damit weiß ich eigentlich welche GA welchen DPT braucht.
Oder ist jemanden ein Fall bekannt in der eine GA mit unterschiedlichen DPTs befeuert wird?

Sowas fehlt dem knxd noch, eine items Config Datei wo man seine GA's definiert und das DPT Mapping hinterlegen kann.

Steht theoretisch alles schon in der .knxproj aus der ETS. Wieso nochmal konfigurieren und sicherstellen dass beides zusammenpasst?

Einziger Haken bei der Lösung:

Es kann durchaus GAs geben die entweder in der ETS nicht hinterlegt sind, weil sie von anderen Geräten (Software devices?) benutzt werden, oder sie wurden in ETS hinterlegt, aber kein KO daran gebunden.
In beiden Fällen ist es dann nicht möglich der GA automatisch einen DPT zuzuordnen. Hierfür würde ich ggf. eine separate Konfiogurationsfile benutzen die einer GA einen DPT aufzwingt (und ggf. auch den erkannten Typ aus der .knxproj übergeht). Für die meisten wird das aber nicht relevant sein.

Dabei noch ein kleiner Implemntierungshinweis: das CV-Protokoll spezifiziert Namespaces.

Die habe ich schon gesehen, aber als Unterscheidung verschiedener Adresstypen in einem Backend angesehen.

Zitat der Doku:

NAMESPACE = eine Backend spezifische Repräsentation der Datenquelle, wie z.B. "KNX", "iKO" oder "xPL".

Könnte man theoretisch auch missbrauchen um den DPT der Adresse anzugeben. Aber dann wäre der Name "Namespace" irreführend.
Wenn ich aber z.B. Gruppenadressen von Logikinternen Adressen ("iKO") unterscheiden will, dann ist das prima.
Bin mir noch nicht sicher ob ob hier interne Adressen für die Visu brauchen/unterstützen werde, oder ob ich nicht alles auf GAs auslege was in der Visu angezeigt werden soll.

Viel Text... puuh. Wäre aber toll wenn jemand die hervorgehobene Frage beantworten könnte... Das würde mir weiter helfen.

Gruß und Danke für's mitdenken,
Alex

[jolt]

Mir ist kein Use Case bekannt wo das passiert. Kann eigentlich auch nicht, da man auf Empfängerseite gar nicht wissen kann welches Encoding der Sender benutzt hat. Man kann nur darauf vertrauen das es kompatibel mit der eigenen Vorstellung ist