Bin etwas hin und her gerissen....
Die Umrechnung im Backend macht es bzgl. der Konfiguration leicht.
Aber mit der Transformation im Frontend/der Visu hat man noch die Möglichkeit anpassungen vorzunehmen. z.B. das Thema Nachkommastellen und die Rundung solcher.
Max, hast du eine Art Konfigurationsmöglichkeit pro Adresse im Backend? D.h. die eine Adresse so, und die andere Adresse, vom gleichen Typ anders ausgeben?
Hab mir den Satz nochmal durch den Kopf gehen lassen: Eigentlich liegt es nicht in der Natur der Sache. Wenn ich vom Backend den Wert einer Adresse anfordere die eine Temperatur darstellt, dann muss da ein Temperaturwert zurück kommen.
Eigentlich kann man nur drüber streiten ob eine oder zwei Nachkommestellen. Eigentlich eindeutig.
Aber es gibt auch Ausnahmen: DPT2 ... Wie würde man das angeben? Prinzipiell auch als 1 und 0. Je nachdem ob geschaltet/an oder nicht/aus. Aber es gibt da noch das Control-Bit. Da müsste man sich dann etwas überlegen. z.B. 0/1/c0/c1 ... Und auf der Visuseite macht man damit dann was? Richtig, man müsste es wieder transformieren/ausseinander nehmen. In diesem Fall wäre es geschickter man würde den Rohwert übermitteln. Dann kann man es sich auf Visu-Seite noch aussuchen was man damit macht. Das gleiche könnte man aber auch von 0/1/c0/c1 sagen.
Vorteil der Transformation im Backend: Man muss in den meisten Fällen keine Transformation in der Visu konfigurieren.
Aber es gibt ja auch ausnahmen... Ich hab noch keinen Schimmer was es alles für Controls in CV gibt und was die so von sich geben.
DPT3.008 "Control blinds" transportiert wie DPT2 einen zusammengesetzten Wert: Einmal die Richtung, und einmal die Schrittweite.
Hier fehlt mir noch die Praxiserfahrung ob man solche Fälle in der Visu braucht und was z.B. die CV da an Daten von sich gibt wenn man den entsprechenden Button drückt... oder ob solche Fälle einfach durch einen alternativen Ansatz abgefangen und vermieden werden.
Meine gestrigte Tendenz zur Transformation in der Visu schwankt gerade wieder in die andere Richtung.
ABER ich überlege gerade ob ich das nicht mit dem NAMESPACE aus dem CV Protokoll abdecke. Der ist eigentlich dafür gedacht Adressarten voneinander zu unterscheiden, bzw. auch im Fall von KNX GAs von iKOs...
Aber in diesem Fall könnte man den Namespace auch verwenden, um zwischen RAW und TRANSFORMED umzuschalten. Somit könnte man ein und dieselbe Adresse einmal im Rohformat und einmal im bereits tansformierten Format abrufen. Würde dann aber keinen großen Aufwand betreiben für die Visu eine Transformationsklasse zu basteln, da dies ja nur in Ausnahme/Sonderfällen benötigt wird.
Aktuell grübel ich noch über der Architektur für den zentralen KNX-Teil des KAD/Backends... Werde hier experimentieren und ne weile testen müssen.
Die Umrechnung im Backend macht es bzgl. der Konfiguration leicht.
Aber mit der Transformation im Frontend/der Visu hat man noch die Möglichkeit anpassungen vorzunehmen. z.B. das Thema Nachkommastellen und die Rundung solcher.
Max, hast du eine Art Konfigurationsmöglichkeit pro Adresse im Backend? D.h. die eine Adresse so, und die andere Adresse, vom gleichen Typ anders ausgeben?
Das man dafür Typen o.ä. in der Visu hinterlegen muss, liegt m.M.n. in der Natur der Sache und ist "normal".
Eigentlich kann man nur drüber streiten ob eine oder zwei Nachkommestellen. Eigentlich eindeutig.
Aber es gibt auch Ausnahmen: DPT2 ... Wie würde man das angeben? Prinzipiell auch als 1 und 0. Je nachdem ob geschaltet/an oder nicht/aus. Aber es gibt da noch das Control-Bit. Da müsste man sich dann etwas überlegen. z.B. 0/1/c0/c1 ... Und auf der Visuseite macht man damit dann was? Richtig, man müsste es wieder transformieren/ausseinander nehmen. In diesem Fall wäre es geschickter man würde den Rohwert übermitteln. Dann kann man es sich auf Visu-Seite noch aussuchen was man damit macht. Das gleiche könnte man aber auch von 0/1/c0/c1 sagen.
Vorteil der Transformation im Backend: Man muss in den meisten Fällen keine Transformation in der Visu konfigurieren.
Aber es gibt ja auch ausnahmen... Ich hab noch keinen Schimmer was es alles für Controls in CV gibt und was die so von sich geben.
DPT3.008 "Control blinds" transportiert wie DPT2 einen zusammengesetzten Wert: Einmal die Richtung, und einmal die Schrittweite.
Hier fehlt mir noch die Praxiserfahrung ob man solche Fälle in der Visu braucht und was z.B. die CV da an Daten von sich gibt wenn man den entsprechenden Button drückt... oder ob solche Fälle einfach durch einen alternativen Ansatz abgefangen und vermieden werden.
Meine gestrigte Tendenz zur Transformation in der Visu schwankt gerade wieder in die andere Richtung.
ABER ich überlege gerade ob ich das nicht mit dem NAMESPACE aus dem CV Protokoll abdecke. Der ist eigentlich dafür gedacht Adressarten voneinander zu unterscheiden, bzw. auch im Fall von KNX GAs von iKOs...
Aber in diesem Fall könnte man den Namespace auch verwenden, um zwischen RAW und TRANSFORMED umzuschalten. Somit könnte man ein und dieselbe Adresse einmal im Rohformat und einmal im bereits tansformierten Format abrufen. Würde dann aber keinen großen Aufwand betreiben für die Visu eine Transformationsklasse zu basteln, da dies ja nur in Ausnahme/Sonderfällen benötigt wird.
Aktuell grübel ich noch über der Architektur für den zentralen KNX-Teil des KAD/Backends... Werde hier experimentieren und ne weile testen müssen.
Kommentar