EIBD-Cache, read, write-Attributen, Statusanzeige

[perf]

ich denk mal drauf rum, wie man das so konstruiert, das in Sonderfällen (Logikverknüfungen im Aktor, ...) auch das richtige rauskommt..
Denke da an einen Trick (das age haben/bekommen wir nicht, aber..)

(und ich hätte ein paar Ideen das auch persistent zu kompensieren, wenns mit PL wirklich nicht geht.. Das Thema ist ziemlich Artverwandt mit den DALI-Stati des N141/01 [x128], wofür ich HS-BS und Plugin geschrieben habe..)

Intressant!

/Per

[makki]

Nun, wir alle erstellen glaube ich langweilige Listen seit wir denken können mit Excel, da ist nichts schlechtes dran

Die Sache könnte man mit einem foreach etwas kürzen, ist aber eher kosmetik; ich denk mal drauf rum, wie man das so konstruiert, das in Sonderfällen (Logikverknüfungen im Aktor, ...) auch das richtige rauskommt..
Denke da an einen Trick (das age haben/bekommen wir nicht, aber..)

Makki

[perf]

Also, es sieht nur so aus:

if ( $msg{'apci'} eq "A_GroupValue_Write" ) {
	plugin_log($plugname,'dst'.$msg{'dst'});
    given ( $msg{'dst'} ) {
        when ('0/0/1') {
            knx_write( '7/0/100', $msg{'value'} );
            knx_write( '7/2/100', $msg{'value'} );
            knx_write( '1/3/110', $msg{'value'} );
            knx_write( '2/0/101', $msg{'value'} );
            knx_write( '2/5/102', $msg{'value'} );
            knx_write( '5/5/101', $msg{'value'} );
            knx_write( '6/4/120', $msg{'value'} );
            knx_write( '4/0/100', $msg{'value'} );
            knx_write( '2/1/101', $msg{'value'} );
            knx_write( '2/1/103', $msg{'value'} );
            knx_write( '2/3/101', $msg{'value'} );
            knx_write( '3/0/100', $msg{'value'} );
            knx_write( '3/1/100', $msg{'value'} );
            knx_write( '3/2/100', $msg{'value'} );
            knx_write( '5/0/100', $msg{'value'} );
            knx_write( '5/0/110', $msg{'value'} );
            knx_write( '6/0/100', $msg{'value'} );
            knx_write( '6/1/100', $msg{'value'} );
            knx_write( '6/2/100', $msg{'value'} );
            knx_write( '6/3/100', $msg{'value'} );
            knx_write( '6/4/110', $msg{'value'} );
            knx_write( '5/2/100', $msg{'value'} );
            knx_write( '5/2/110', $msg{'value'} );
            knx_write( '1/2/111', $msg{'value'} );
            knx_write( '6/2/104', $msg{'value'} );
            knx_write( '6/2/102', $msg{'value'} );
            knx_write( '6/1/105', $msg{'value'} );
            knx_write( '6/1/107', $msg{'value'} );
            knx_write( '6/0/105', $msg{'value'} );
            knx_write( '7/1/102', $msg{'value'} );
            knx_write( '6/0/102', $msg{'value'} );
            knx_write( '5/3/102', $msg{'value'} );
            knx_write( '5/3/104', $msg{'value'} );
            knx_write( '5/3/106', $msg{'value'} );
            knx_write( '5/1/102', $msg{'value'} );
            knx_write( '6/4/102', $msg{'value'} );
            knx_write( '5/1/104', $msg{'value'} );
            knx_write( '6/3/102', $msg{'value'} );
            knx_write( '6/3/104', $msg{'value'} );
            knx_write( '5/3/108', $msg{'value'} );
        }
        when ('0/0/2') {
            knx_write( '7/0/100', $msg{'value'} );
            knx_write( '7/2/100', $msg{'value'} );
            knx_write( '1/3/110', $msg{'value'} );
            knx_write( '2/0/101', $msg{'value'} );
            knx_write( '2/5/102', $msg{'value'} );
            knx_write( '5/5/101', $msg{'value'} );
            knx_write( '6/4/120', $msg{'value'} );
            knx_write( '4/0/100', $msg{'value'} );
            knx_write( '2/1/101', $msg{'value'} );
            knx_write( '2/1/103', $msg{'value'} );
            knx_write( '2/3/101', $msg{'value'} );
            knx_write( '3/0/100', $msg{'value'} );
            knx_write( '3/1/100', $msg{'value'} );
            knx_write( '3/2/100', $msg{'value'} );
            knx_write( '5/0/100', $msg{'value'} );
            knx_write( '5/0/110', $msg{'value'} );
            knx_write( '6/1/100', $msg{'value'} );
            knx_write( '6/2/100', $msg{'value'} );
            knx_write( '5/2/100', $msg{'value'} );
            knx_write( '5/2/110', $msg{'value'} );
            knx_write( '1/2/111', $msg{'value'} );
            knx_write( '6/2/104', $msg{'value'} );
            knx_write( '6/2/102', $msg{'value'} );
            knx_write( '6/1/105', $msg{'value'} );
            knx_write( '6/1/107', $msg{'value'} );
            knx_write( '7/1/102', $msg{'value'} );
            knx_write( '5/3/102', $msg{'value'} );
            knx_write( '5/3/104', $msg{'value'} );
            knx_write( '5/3/106', $msg{'value'} );
            knx_write( '5/1/102', $msg{'value'} );
            knx_write( '5/1/104', $msg{'value'} );
            knx_write( '5/3/108', $msg{'value'} );
        }

usw usw - 375 Zeilen. Das kann ja keiner benutzen.

Mein Hauptwerkzeug im Beruf ist Excel - ich habe xml aus dem knxproj genommen (knxproj=zip), und im Excel manipuliert.

/Per

[makki]

Ich freue mich
a) über alle Plugins im SVN
b) hat man ja vielleicht noch Ideen oder ein anderer kann es zumindest brauchen
(und ich hätte ein paar Ideen das auch persistent zu kompensieren, wenns mit PL wirklich nicht geht.. Das Thema ist ziemlich Artverwandt mit den DALI-Stati des N141/01 [x128], wofür ich HS-BS und Plugin geschrieben habe..)

Also bitte her damit

Makki

[perf]

Jetzt gelöst - Wiregate-Plugin macht "syntetische" Rückmeldungen für PL-Aktoren. Das Plugin muss natürlich gepflegt werden - änderingen bei den Zuordningen von Gruppenadressen an die Dimmerkanälen muss entsprechende einträge im Plugin haben.

Diese syntetische GAs können nur gelesen werden wenn sie in der Cache gestzt sind - bei neustart des EIDB sind sie undefiniert. Könnte sicherlich auch im Plugin gemanaged werden.

/Per

[perf]

Ich habe ein paar Lösungsansätze:
- Tatsächlich die Stati senden
- Eine Nebenlogik (Plug-in oder Linknx) für die PL-Geräte, die eine "syntetische" Rückmeldung ausgibt, die nicht an den PL-Bus weitergeleitet wird.

Ich habe jetzt probiert, die Stati von allen Aktoren auf den Bus zu senden. Es funktionert bei einzelnen Geräten und kleinere Gruppen von Geräten, aber überhaupt nicht bei Zentral-Aus.

Aus einem anderen Thread:

Hallo,

ich betreibe eine Powernet-Anlage mit ca. 60 Busteilnehmern. Diese funktioniert perfekt, bis jetzt ist noch kein einziges Telegramm nicht dort angekommen, wo es hin soll.

Man muss aber mit der Programmierung super sorgfältig sein. Powernet kann pro Sekunde nur ca. 5 Telegramme (TP, ja ca. 10) - die dann aber ohne Rücksicht auf Verluste "verschluckt" werden.

Gerade bei Rückmeldungen von Aktoren, z. B. nach "Zentral aus" muss vorsichtig umgegangen werden, da es sonst zur Überlastung kommt, ich selbst bin auch immer bemüht alle Telegramme zu bestätigen "ACK". Das gleiche Problem gibts übrigents bei TP auch, nur dass es dort niemanden interessiert, weils der BUS wegsteckt und solage weiderholt wird bis es durchgeht.

Zyklische Telegramme machen bei mir keine Probleme, da die Wahrscheinlichkeit, das dort mehr als 5 pro Sekunde zusammenkommen doch eher gegen 0 geht.

Ich werde meinen zweiten Ansatz probieren.

/Per

[makki]

Na gut, danke

Auch bei der CV werden die Stati (eibd-Cache) nur bei restart dieses invalidiert - also so gut wie nie, der Trick ist nur das richtig zu benutzen bzw. das zu vermeiden sofern irgend möglich.

Dein einziger Fehler ist: die Zentral-GA in der Visu auf dem Schalter und das nicht-übertragen/aktualisieren des Schaltstatus

Makki

[perf]

Sag mir mal bitte eine einzige Visu, die dieses Perpetuum mobile "intelligenter" löst - ohne "meine spezielle Sonderlocke" und/oder gravierende Nachteile für gewöhnliche Installationen (?)

Nein, ich glaube nicht das eine andere Visu das intelligenter löst. Ich meinte nur, dass bei einer Thick Server-Thin Client-Lösung die Stati nicht so oft initialisiert werden müssen - nur bei Neustart des Servers.

/Per

[makki]

Ich habe ein paar Lösungsansätze:
- Tatsächlich die Stati senden

Ich schätze das ist der beste

- Eine Nebenlogik (Plug-in oder Linknx) für die PL-Geräte, die eine "syntetische" Rückmeldung ausgibt, die nicht an den PL-Bus weitergeleitet wird.

Da kommt immer irgendwann murks bei raus.. Natürlich kann man das so konstruieren, das es im spezifischen Fall "scheinbar" funktioniert, aber in dem Moment wo andere Faktoren (Logik-Verknüpfungen im Aktor, ext. Logik, Sperren, ...) dazukommen fallen solche hilfs-konstrukte auf die Nase..

..oder andere Visu-Architekturen ist aber das ein Init bei CV sehr oft vorkommt, was nicht der Fall bei den alternativen ist.

Sag mir mal bitte eine einzige Visu, die dieses Perpetuum mobile "intelligenter" löst - ohne "meine spezielle Sonderlocke" und/oder gravierende Nachteile für gewöhnliche Installationen (?)

Makki

[perf]

Vielen Dank für die Antworten!

Ich habe ein paar Lösungsansätze:
- Tatsächlich die Stati senden
- Eine Nebenlogik (Plug-in oder Linknx) für die PL-Geräte, die eine "syntetische" Rückmeldung ausgibt, die nicht an den PL-Bus weitergeleitet wird.

Dir ist aber klar: das "Problem" wird damit nur vom Zentral-Aus auf den Visu-Start verschoben - und verdoppelt! Damit hätten wir dann nämlich 220 Telegramme und eben genau das soll der Cache verhindern..

Ja, das Lesen beim Visu-Start war keine gute Idee.

Aber nochmal zu Sicherheit: die CV verhält sich im Betrieb exakt so wie ein KNX-Taster: Telegramme kommen in der richtigen Reihenfolge, es "gewinnt" das letzte.

Das ist bei deinen Tastern nicht anders (nur setzten die garkeine Lesetelegramme ab), nach (Bus)Spannungsausfall sind die Stati undefiniert.

Hörende GA's haben natürlich ihren Sinn, funktioniert in der CV ja auch 1:1 analog einem KNX-Gerät.

Wie mans dreht und wendet, die Lösung sucht hier das Problem - das man mit jeglicher anderer Visu/Gerät auch hätte.

Der Unterschied zwischen CV und konventionelle Tastern oder andere Visu-Architekturen ist aber das ein Init bei CV sehr oft vorkommt, was nicht der Fall bei den alternativen ist.

/Per

[makki]

Also gut, suchen wir mal das Problem für die Lösung

Erstmal, ich kenne PL praktisch nicht, kann mir aber nicht vorstellen, das 50 Statustelegramme das bedienen der Rolladen verhindern; das Telegramm mogelt sich schon zwischendurch rein.. Lässt sich ja leicht testen:
for i in {1..100}; do groupwrite local:/tmp/eib 13/5/6 FF; sleep .1; done

Bei einem Aus wurde sowohl "Aus" als "Dimmwert 0" gemeldet werden.

Fast alle mir bekannten Geräte senden den Status nur bei Wertänderung bzw. lassen sich so einstellen - also würden mitnichten 110 Telegramme bei Zentral-Aus auflaufen - sondern nur soviele, wie vorher an waren..

Ich will erreichen, dass die einzeln-GA vom Bus gelesen wird beim start in einem frischen Browser.

Dir ist aber klar: das "Problem" wird damit nur vom Zentral-Aus auf den Visu-Start verschoben - und verdoppelt! Damit hätten wir dann nämlich 220 Telegramme und eben genau das soll der Cache verhindern..
Also ich bleib dabei, das es immer sinnvoller ist, Statustelegramme abzusetzen als vom Bus zu lesen..

Und wie kann ein Lesevorgang bewirkt werden?

Stand jetzt: aus der Visu garnicht - ist der Wert im Cache wird er verwendet - ist er es nicht, wird einmalig ein Lesetelegramm abgesetzt.

Ein möglicher "Workaround", spontane Idee, wäre z.B. ein paar Minuten nach dem Zentral-Aus mit einem Plugin das lesen der GA's zu erzwingen (knx_read, age=1)

Das Problem wäre gelöst, wenn EIBD auch ein Alter der gecacheten Werten ausgeben würde.

Hin oder her, das wäre in manchen Konstellationen IMHO durchaus wünschenswert - tut er aber nicht.
Dafür müsste man zwei eibd-APIs, Backend und CV-client ändern..

Aber nochmal zu Sicherheit: die CV verhält sich im Betrieb exakt so wie ein KNX-Taster: Telegramme kommen in der richtigen Reihenfolge, es "gewinnt" das letzte.
Beim Init "gewinnt" letztlich die höchste GA.
Das ist bei deinen Tastern nicht anders (nur setzten die garkeine Lesetelegramme ab), nach (Bus)Spannungsausfall sind die Stati undefiniert.

KNX ist flexibler als das. Man muss nicht unbedingt diese Prinzipen folgen, um ein gut funktionierendes System aufbauen zu können. Warum gibt es sonst überhaupt die Möglichkeit mehrere hörende GAs bei Tastern anzugeben?

Wie sagt PeterPan immer so schön: Man kann
Man kann auch auf der linken Strassenseite im Rückwärtsgang fahren, nur wurde das gefährt nicht dafür ausgelegt und man bekommt nen steifen Hals..
Hörende GA's haben natürlich ihren Sinn, funktioniert in der CV ja auch 1:1 analog einem KNX-Gerät.

In der Tat haben meine Dimmer (BJ) nicht separate Schaltstatus-KO. Wenn der Übertragungs-Flag gesetzt ist wird auf der sendende GA des Schalt-KOs rückgemeldet wenn eine andere GA ein ein/aus bewirkt hat. Der Schaltstatus kann von der sendende GA gelesen werden. (Macht eigentlich kein Unterschied für unsere Diskussion.)

Richtig..
Also einfach das Ü beim Schaltstatus setzen, macht max. 55 Telegramme und fertig.

Ja, wie macht man das? 10000 Telegramme auf einem gemeinsamen Medium??

Ja, so macht man das.. Es sind allerdings praktisch (s.o.) wesentlich weniger da nur Änderungen gesendet werden - Aber Fakt: der Status muss raus, sonst gibts inkonsistente Zustandsanzeigen.


Lange Rede, das einzige was ich mir Alternativ sinnvoll vorstellen könnte ist:
a) o.g. Workaround (im Prinzip gibt es sowas z.B. im HS als Watch-Adresse* das wäre aber Job einer sep. Logik o.ä., nicht der Visu)
-> Allerdings löst auch das Dein "Problem" nicht, weil statt max. 110 Statustelegrammen beim Zentral-Aus haben wir dann wieder immer 220 (110 lesen+AW) auf der Strippe..
b) Eine Möglichkeit im CV-Client, bestimmte Adressen nicht beim Init sondern nur "im Betrieb" abzufragen - aber auch das löst das Problem nur partiell und ist ein fürchterlicher Quirk..
c) Für einen Sonderfall eibd, Backend, CV-client umstricken - zu Lasten von Traffic und Responsezeit (Cache=3ms, Lese/AW-Telegramm=100-150ms bei TP1) - in allen normalen Installationen

Wie mans dreht und wendet, die Lösung sucht hier das Problem - das man mit jeglicher anderer Visu/Gerät auch hätte.

Makki


*

Watch-Adresse
Jedem Kommunikationsobjekt können beliebig viele Watch-Objekte zugeordnet werden. Wenn diese Gruppenadresse auf dem Bus oder im HS/FS geändert wird, wird der Wert des EIB-Objektes auf dem Bus abgefragt. Hier werden beispielsweise Dimm-Objekte und Schaltobjekte zum Helligkeitswert eines Dimmers eingetragen.

Hintergrund: Die Watchobjekte sind entstanden aus der Forderung, dass der HS/FS den richtigen Helligkeitswert (%) anzeigen soll (also den aktuellen Status). Wenn also im Gebäude mit einem Tastsensor ein 1-bit- oder ein 4-bit Telegramm ausgesendet wird, verändert sich der Helligkeitswert. Dieser wird aber von normalen (älteren) Dimmaktoren nicht aktualisiert. Deshalb hängt man an den Helligkeitswert, der zur Anzeige im HS/FS dient, das Schalten und das Dimmen als Watchgruppenadresse mit an. Wenn dort etwas passiert, wird das Kommunikationsobjekt (Helligkeitswert) auf dem Bus abgefragt.

Besitzt ein moderner Dimmaktor ein Rückmeldeobjekt für den Helligkeitswert, dann kann auf Watchgruppenadressen verzichtet werden.

[perf]

Ein paar Kommentare noch:

Es geht um das Grundprinzip von KNX, das hier eigentlich schon ziemlich stringent umgesetzt ist:
- Event-getrieben
- Schalt != Rückmeldung
- Zentral/Sperrobjekt != Status

KNX ist flexibler als das. Man muss nicht unbedingt diese Prinzipen folgen, um ein gut funktionierendes System aufbauen zu können. Warum gibt es sonst überhaupt die Möglichkeit mehrere hörende GAs bei Tastern anzugeben?

Also, in der reinen Lehre hat jeder (z.B.) Dimmer-Kanal 5 Kommunikations-Objekte:
- Schalten (Write-only) - geht die Visu NICHTS an ausser zum SENDEN des Schaltbefehls.
- Schaltstatus (Read-Only - Lesbar, sendet bei Änderung)
- Dimmwert setzen (Write-only) - geht die Visu NICHTS an ausser zum SENDEN des Dimmwerts.
- Dimmwert-Status (Read-Only - Lesbar, sendet bei Änderung)
- rel. Dimmen 4bit (Write-only) - geht die Visu noch viel weniger an... s.o.

Nein, richtig ist die Status-GA, weder die Schalt-GA noch die Zentral-GA sollten in der Visu "read" sein.

Stichwort Readonly/Writeonly..

In der Tat haben meine Dimmer (BJ) nicht separate Schaltstatus-KO. Wenn der Übertragungs-Flag gesetzt ist wird auf der sendende GA des Schalt-KOs rückgemeldet wenn eine andere GA ein ein/aus bewirkt hat. Der Schaltstatus kann von der sendende GA gelesen werden. (Macht eigentlich kein Unterschied für unsere Diskussion.)

In all diesen Konstellationen wird man niemals auf einen vernünftigen, konsistenten Anzeigezustand kommen, wenn man das nicht genau so durchzieht.

Doch! Ausser direkt nach einer Umprogrammierung. Glücklicherweise sprechen wir hier von Status-LEDs von Taster und Anzeigezustand von Switches in einem Browser über das Status von Lampen. Garagentor sollte man mit auf jeden fall mit härterer Rückmeldung machen.

Wie machen das wohl grosse Installationen mit 5500 Dimmern?

Ja, wie macht man das? 10000 Telegramme auf einem gemeinsamen Medium??

Therotetisch ginge das, es bleibt nur mumpitz/Zufall, wenn SCHALT&STATUS-GA's falsch eingesetzt/vermischt werden.

Ja, wenn man falsch macht funktioniert es nicht. Es war nicht mein Plan, es falsch zu machen.

/Per

[perf]

Hmm, nochmal drüber nachdenken und den KNX seinen Job tun lassen - es geht nicht darum möglichst viele Telegramme zu sparen

Ich habe bewusst (weil ich die Frage übergreifend prinzipiell gesehen habe, und viele Forumsteilnehmer negative Vorurteile haben) nicht erwähnt, dass mein System ca 70% KNX PowerLine ist. KNX PL verkraftet sechs Telegramme pro Sekunde, und ich möchte auch direkt nach einem Zentral-Aus z.B. die Jalousien runterfahren können. Abgesehen vom CV ist das trotz der Grösse des Systems kein Problem - auch nicht die Status-LEDs bei einem korrekten Zustand zu halten - wenn man intelligent auf separate (unnötige) Rückmeldungs-Telegramme verzichtet. Auch der Durchsatz von KNX TP ist ja nicht unendlich - 50 Telegramme pro Sekunde.

Wiregate, EIBD und CV-backend sind ständig auf dem Bus und kennen die Reihenfolge der Telegramme. Es wäre möglich, die Software-Switches im CV genauso intelligent zu machen wie die Taster.

Ich finde auch, dass es ein genereller Vorteil für CV wäre, wenn der Visu genau das Verhalten von einem funktionierenden KNX-System abbilden könnte. Z.B wennn das Ideal ist, dass aus ETS ein sofort funktionierender Visu hergestellt werden können soll.

/Per

[makki]

Ja, mit Verlaub, da denkst du falsch
Es geht um das Grundprinzip von KNX, das hier eigentlich schon ziemlich stringent umgesetzt ist:
- Event-getrieben
- Schalt != Rückmeldung
- Zentral/Sperrobjekt != Status

Also, in der reinen Lehre hat jeder (z.B.) Dimmer-Kanal 5 Kommunikations-Objekte:
- Schalten (Write-only) - geht die Visu NICHTS an ausser zum SENDEN des Schaltbefehls.
- Schaltstatus (Read-Only - Lesbar, sendet bei Änderung)
- Dimmwert setzen (Write-only) - geht die Visu NICHTS an ausser zum SENDEN des Dimmwerts.
- Dimmwert-Status (Read-Only - Lesbar, sendet bei Änderung)
- rel. Dimmen 4bit (Write-only) - geht die Visu noch viel weniger an... s.o.

Stichwort Readonly/Writeonly..

Und dann vielleicht alle Zentral-aus, lokales Sperrobjekt für Helligkeit, und-Verknüpfung mit dem Garagentor, Stromausfall uvm. Von externen Logiken reden wir jetzt mal garnicht.

In all diesen Konstellationen wird man niemals auf einen vernünftigen, konsistenten Anzeigezustand kommen, wenn man das nicht genau so durchzieht.
Der Cache hilft nur, das nicht bei 5 Visu-Clients 5x110 Lese+Antwort-Telegrammme über den Bus huschen müssen, nimmt einem nicht das Prinzip ab.

Und jetzt kommen wir zu Deinem Problem:

Ich will nicht das jeder Dimmer sein Status auf den Bus meldet, wenn es sich ändert. Das würde bei einem Zentral-Aus 110 Status-Telegramme auslösen, und das kan nicht gut funktionieren.

Warum? Begründung? Stromsparen, Kupfer wird warm?
Das dauert max. 3sek - worst-case - und alle Stati sind zu jedem Zeitpunkt konsistent.

Der Unterschied bei mir ist aber, dass es für mich nicht möglich wäre, das jeder Aktor sein Status nach jede Veränderung ausgibt.

Sollte er aber; Und wieder: Warum nicht?
Wie machen das wohl grosse Installationen mit 5500 Dimmern?

Dagegen wäre es ein kleineres Problem, wenn CV/EIBD die Stati bei Bedarf (d.h. neuer Browser-Session) vom Bus lesen würde -

Therotetisch ginge das, es bleibt nur mumpitz/Zufall, wenn SCHALT&STATUS-GA's falsch eingesetzt/vermischt werden.

welcher GA dann zu lesen wäre - die Zentral-aus-GA oder die einzeln-GA. (Richtig wäre die einzeln-GA.)

Nein, richtig ist die Status-GA, weder die Schalt-GA noch die Zentral-GA sollten in der Visu "read" sein.

Was kann ich tun?

Hmm, nochmal drüber nachdenken und den KNX seinen Job tun lassen - es geht nicht darum möglichst viele Telegramme zu sparen

Makki

[perf]

Für mich ist dieses Verhalten von CV eine Schwäche in der Architektur. Bei eine Server-basierte Visu mit einem "thin client" würden die Switches in der Visu nach der Reihenfolge der Telegramme die auf alle die verknüpften GAs versandt werden aktualisiert werden, unabhängig davon, ob der Client im Moment offen war oder nicht. Dieses Verhalten würde ganz das Verhalten von KNX-Tastern entsprechen.

Bei CV dagegen, dessen Architectur als "thin Server-thick Client" bezeichnet werden kann, funktioniert es nicht nach diesen Prinzip, sondern es hängt alles auf die EIBD-GA-Cache ab, die nicht die mehreren Verknüpfungen der Switches und die Reihenfolge der Telegramme berücksichtigt.

Oder denke ich falsch?

/Per