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

[jolt]

Ach ja, du hast natürlich Recht mit der ETS. Deswegen exportiere ich meine Items auch per Script aus der ETS Konfig. Und genau so etwas sollte man allgemein für knxd & Co zur Verfügung stellen. Dann brauchen Leute wie du und ich nicht unsere Spezial Hacks

[tuxedo]

Und genau so etwas sollte man allgemein für knxd & Co zur Verfügung stellen. Dann brauchen Leute wie du und ich nicht unsere Spezial Hacks

Wieso Spezial-Hack? Meine Implementierung nutzt die .knxproj Datei direkt so wie sie ist ;-) Ich cache lediglich das parse-Ergebnis um nicht bei jedem Start den parse-Aufwand zu haben.

[jolt]

Genau, du hast deine Lösung, ich habe meine Lösung, für knxd und openHAB bräuchte man noch eine Lösung etc etc. Schön wäre doch wenn nicht jeder das Rad neu erfinden müsste oder? Das meinte ich mit Hack. Nicht unbedingt deine spezifische Umsetzung.

[tuxedo]

Ja, aber CV ist doch Bus-Unabhängig und hat keinen Schimmer was das Backend anbietet und was nicht?

Wie willst du da CV-technisch etwas auf einen Nenner bringen?
Du kannst höchstens die CV sauber mit einem Plugin-Konzept für Backends erweitern. Weil jetzt ist nicht klar wo man überall anfassen und was hinzufügen muss um ein neues Backend zu benutzen. Hier eine client.js, dort ein transform, das dann noch hier und da "eintragen"....

Wenn man wüsste: Ok, ich muss diese JS-"Klasse" schreiben/überschreiben und noch ein transform.js basteln und alles zusammen in einen neuen Ordner namens "MeinTollesBackend" im Unterverzeichnis "backends" werfen, dann wäre das schön sauber einheitlich.

Oder meinst du was ganz anderes?

[Chris M.]

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?

Jain.

Ja:
Man kann das nutzen um implizit Typen zu wandeln - z.B. Szene in Byte. Ist aber nicht "legal".
Wesentlich häufiger dürfte man hier ein Problem bekommen wenn man sieht wie schlecht die DTPs implementiert sind - selbst die ETS kennt nicht alles was im Standard steht. Erst mal wichtig ist zwar was vor dem Punkt steht - aber manchmal ist das hinten auch relevant (ist 0xFF jetzt 100% oder 255%?)

Nein:
Es ist nicht sauber. Und auf Byte-Ebene muss es kompatibel sein, sonst gibt's Chaos bei den Bus-Teilnehmern.

Oder anders:
In der heilen Welt hat jede GA exakt einen DTP. Wenn das nicht der Fall ist würde ich das als "undefiniert" bezeichnet - also ist alles erlaubt. Auch das Licht auszuschalten

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

Sagt ja keiner dass man das für den knxd nochmal konfigurieren müsste :P
Der könnte auch direkt die .knxproj einlesen oder per Übersetz-Skript ein optimiertes Datenformat vorgesetzt bekommen.

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.

Ich befürchte das wird öfters passieren als man denkt. Hier mal schnell was gebastelt, da ein Provisorium - und schon ist man mitten drinnen. (Und wenn man eine Logik-Engine nutzt die nicht in die ETS bidirektional eingebunden ist geht's um so schneller. Ist meine persönliche Erfahrung )

Was immer geht um halbwegs Fail-Safe zu sein: für jede Daten-Breite eine Default-Codierung annehmen - also einfach in einen Integer übersetzen.

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.

Ne, ist nicht für DTP gedacht. Sondern genau für die iKOs.

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.

AFAIK gibt es ein verbreitetes System das die iKOs einfach auf "höhere" GAs mappt.
-> Vorteil: Du bleibst in einer Struktur
-> Nachteil: nicht sprechend und nicht intuitiv.

Ich finde sprechende Namen ansprechender. Ist aber meine Meinung.

[tuxedo]

Jain.

Ja:
Man kann das nutzen um implizit Typen zu wandeln - z.B. Szene in Byte. Ist aber nicht "legal".

Was nicht zulässig ist, sollte man lassen.

Nein:
Es ist nicht sauber. Und auf Byte-Ebene muss es kompatibel sein, sonst gibt's Chaos bei den Bus-Teilnehmern.

Versteh ich nicht.

Oder anders:
In der heilen Welt hat jede GA exakt einen DTP. Wenn das nicht der Fall ist würde ich das als "undefiniert" bezeichnet - also ist alles erlaubt. Auch das Licht auszuschalten

Ich befürchte das wird öfters passieren als man denkt. Hier mal schnell was gebastelt, da ein Provisorium - und schon ist man mitten drinnen. (Und wenn man eine Logik-Engine nutzt die nicht in die ETS bidirektional eingebunden ist geht's um so schneller. Ist meine persönliche Erfahrung )
Was immer geht um halbwegs Fail-Safe zu sein: für jede Daten-Breite eine Default-Codierung annehmen - also einfach in einen Integer übersetzen.

In den untiefen der .knxproj gibt es zwei Varianten der DPT Zuordnung:

Entweder es steht mehr oder weniger direkt im Umfeld der GA im XML,
ODER
man schaut sich die KOs die die GA bedienen, schaut dann nach deren KO-Definition im Device-Abschnitt nach was da für ein DPT für dieses KO vorgeschrieben ist.

Wenn man beides berücksichtigt, hat man eigentlich für jede GA die in der ETS von einem Device verwendet wird ein DPT.
Die ETS selbst meckert ja sofort wenn man inkompatible DPTs auf einer GA versucht zu mischen.
Was ich noch nicht probiert habe ist das mischen von theoretisch kompatiblen DPTs... Müsste ich mal schauen ob die ETS da auch meckert. Wenn ja, dann könnte man da schonmal sicher sein dass die ETS konsistente und saubere Daten liefert.

Für GAs die noch keinem Gerät zugeordnet sind (weil diese GA vielleicht einem Software-Device/Bastelprojekt ala HeliosKwlRemote bedient wird und das Gerät deshalb nicht in der ETS auftaucht), könnte der Parser eine Konfigurationsdatei ausspucken (zusammen mit einer fetten Hinweismeldung auf diesen Umstand) die man dann selbst füllt.
Mir ist sonst kein Weg bekannt wie man in ETS einer GA einen DPT zuordnet wenn kein Geräte/KOs dafür vorhanden ist.
Auf der anderen Seite wurde schon erkannt wie man eine ETS Produktdatenbank im XML Schema erstellt und signiert, so dass sie von der ETS gelesen werden kann. Damit ließen sich für die Software-Devices und andere Basteleien eine ETS Konfiguration anlegen. Es reicht ja wenn man die KOs auf die GAs verknüpfen kann. "Programmieren" des Software-Devices ist ja nicht wirklich notwendig (auch wenn's schön wäre).
Aber auch den genannten Weg mit der extra Konfig-File für diese Ausnahmen finde ich noch praktikabel (und vor allem einfacher zu lösen).

Mal schauen wohin der Weg führt.

Ich finde sprechende Namen ansprechender. Ist aber meine Meinung.

Einer der Gründe warum meine LogikEngine die GA-Namen aus der ETS verwendet... ;-)

[tuxedo]

Hab eben meinen Parser nochmal gecheckt:

Wenn ein KNX Gerät in seiner KO-Definition keinen Typ angegeben hat, kann man den selbst in ETS in den Eigenschaften des jeweiligen KO einen eintragen.

Das funktioniert ziemlich gut. Allerdings sind es bei mir etliche KOs die ich hier "nachziehen" muss weil MDT in der Produktdatenbank nix hinterlegt hat. In der Beschreibung des KOs steht der Typ textuell meist drin. Aber der DPT ist eben nicht gesetzt.

Wenn man in der ETS nun durchgeht und sich alle KOs seiner Geräte anschaut (nur die Spalte "Datentyp"), hat man schnell einen Überblick wo noch etwas fehlt.

Hab das mal eben nachgezogen und mein Parser-Test wirft nur noch eine GA mit unbekanntem DPT: Meine Test GA die nirgendwo weiter von einem KO benutzt wird.

--> Perfekt.

Widme mich jetzt wieder dem Backend... Eine eigene Transformation brauch ich glaub nicht mehr: Die Konvertierung macht dann das Backend ;-) Es muss nur mit "konvertierbaren" Werten gefüttert werden