Also:
Wir hatten ja vor Weihnachten die MasterSlave Objekte umgestellt. Ich hatte das dann mal hier durchexerziert und es war wirklich bescheiden: Für jeden Slave 30 verschiedene MasterSlave-GAs, also bei 2 Slaves schon 60 GAs. Das macht wenig Spaß. Also hatte ich mit der Konnex gesprochen und nach einem zertifizierbaren Ausweg gesucht.
Naja, wir haben da was gefunden und das wurde so akzeptiert. Es geht wieder zurück zu einem Master-Slave, das nun anders aufgebaut ist. D.h. es werden wieder 40 Kommandos => Alles geändert, neu eingereicht.
Dann kam aber das Problem der Wildcardcommandos:
Es gibt z.B. DIMMER _PERCENT, welches direkt an Dimmer Prozentwerte schickt. Dies ist ok und KNX-konform.
Aber z.B. ein Kommando FARBE _COLOR wäre problematisch. So wie geplant schickt dieses für Gelb eine Zahl z.B. 2. Es bleibt dann dem Anwender überlassen, dies mit einer Logikmaschine in den Farbton zu wandeln und dann einen 3 Byte RGB-Wert zu schicken. Aber: So darf das nicht sein, weil ja die Konnex eben 3 Byte Werte für Farben definiert. Also müssten wir hier in der Applikation 3 Byte Werte auswählbar machen. Nicht standardisiert vorhanden wäre z.B. _FRACTION (EIN HALB, EIN DRITTEL, EIN VIERTEL). Hier könnte man die Enumeration mit einer Zahl daher realisieren, allerdings muss das dann auch ein eigenes Objekt werden.
Man kann sich denken, dass eine Realisierung der Wildcardkommandos daher zum einen den KNX-Stack sprengen würden (zuviele Objekte) und zum anderen wäre eine Dynamik in der Entwicklung äußerst schwierig.
Nun die schlechte Nachricht. Es gibt nur noch das _PERCENT Wildcard.
Die gute: Es ist nur eine Sache des Sprachkörpers. Wenn also jemand einen nicht KNX-konformen Sprachkörper lädt ...
Mal schauen, vielleicht haben wir morgen ja die nötigen Unterlagen.
Wir hatten ja vor Weihnachten die MasterSlave Objekte umgestellt. Ich hatte das dann mal hier durchexerziert und es war wirklich bescheiden: Für jeden Slave 30 verschiedene MasterSlave-GAs, also bei 2 Slaves schon 60 GAs. Das macht wenig Spaß. Also hatte ich mit der Konnex gesprochen und nach einem zertifizierbaren Ausweg gesucht.
Naja, wir haben da was gefunden und das wurde so akzeptiert. Es geht wieder zurück zu einem Master-Slave, das nun anders aufgebaut ist. D.h. es werden wieder 40 Kommandos => Alles geändert, neu eingereicht.
Dann kam aber das Problem der Wildcardcommandos:
Es gibt z.B. DIMMER _PERCENT, welches direkt an Dimmer Prozentwerte schickt. Dies ist ok und KNX-konform.
Aber z.B. ein Kommando FARBE _COLOR wäre problematisch. So wie geplant schickt dieses für Gelb eine Zahl z.B. 2. Es bleibt dann dem Anwender überlassen, dies mit einer Logikmaschine in den Farbton zu wandeln und dann einen 3 Byte RGB-Wert zu schicken. Aber: So darf das nicht sein, weil ja die Konnex eben 3 Byte Werte für Farben definiert. Also müssten wir hier in der Applikation 3 Byte Werte auswählbar machen. Nicht standardisiert vorhanden wäre z.B. _FRACTION (EIN HALB, EIN DRITTEL, EIN VIERTEL). Hier könnte man die Enumeration mit einer Zahl daher realisieren, allerdings muss das dann auch ein eigenes Objekt werden.
Man kann sich denken, dass eine Realisierung der Wildcardkommandos daher zum einen den KNX-Stack sprengen würden (zuviele Objekte) und zum anderen wäre eine Dynamik in der Entwicklung äußerst schwierig.
Nun die schlechte Nachricht. Es gibt nur noch das _PERCENT Wildcard.
Die gute: Es ist nur eine Sache des Sprachkörpers. Wenn also jemand einen nicht KNX-konformen Sprachkörper lädt ...
Mal schauen, vielleicht haben wir morgen ja die nötigen Unterlagen.
Kommentar