Das was in dem Modul unter “mehr” steht sind eigentlich die mithörenden Adressen. Prinzipiel ist das von Symcon schon richtig umgesetzt. Nur sucht man sich erst wieder einen Wolf, wenn die Aktoren nicht richtig vom Hersteller eingestellt sind. Das kommt noch aus den Anfangszeiten von KNX wo es noch keine Statusobjekt gab, wegen knappen Speicher. Da gab es die mithörenden Adressen. Heute allerdings wird vieles über Statusobjekt realisiert, aber auch nicht immer konsequent - es ist heute einfach ein gemischtwarenladen. Das Thema hatte ich mit dem MDT Support besprochen. In diesem Fall hat mal am Beispiel Rolladenaktor keine Chanche den Status aktiv über eine Gruppenadresse abzufragen bzw. regelmäßig senden zu lassen. Das geht nur über Requestanfragen auf Gruppenadressen, dessen Kommunikatiosnobjekt das Flag “Lesen” gesetzt haben.
Smycon hat dazu sogar eine Unterstützung: Skript zum Auslesen der Zustände vom Bus
Ich hatte mir das Thema Rückmeldeobjekt vor langer Zeit einmal genauer zugeführt und mir dazu eine Doku gemacht, um nicht jedesmal wieder neu einstigen zu müssen. Anbei ein Auszug. Wer die komplette Doku haben möchte, gerne Privatnachricht hinterlassen.
Rückmeldeobjekte
Wichtig zu wissen ist, dass ein Kommunikationsobjekt nur eine Gruppenadresse senden kann (es ist sendent). Die nachfolgenden Adressen, die zugeordnet sind, sind hörend zu interpretieren!!
Siehe in der Datei Flags.docx mehr zum Thema Flags. Darin wird beschrieben, wie die Kommunikationsobjekte sich gegenseitig abhören, um mitzubekommen ob sich der Status geändert hat. Bei alten Sensoren wurde noch kein Statuseingang verbaut, da Speicherplatz gering war. Man musste das mit Flags lösen. Hat man Gruppenadressen, die mehrere Lichter gleichzeitig schalten sollen, dann wird es mit den Flags unmöglich den Status zu interpretieren. Dann hat man beim Umschalten das Verhalten, dass sich nichts tut. Erst beim nochmaligen Schalten wird erst reagiert.
Die neueren Sensoren haben fast alle Eingänge für Statusobjekte. Die heißen dann „Wert für Umschaltung“, oder ähnlich. Da kann dann der Status des Aktorkanals direkt mit der Taste des Tastsensors verbunden werden. Ändert sich der Zustand, dann bekommt der Taster das sofort mit.
Hat der Taster kein entsprechenden Eingang oder sind kompliziertere Schaltungen vorhanden, dann greift man auf das „hörende“ Kommunikationsobjekt zurück.
Beispiel:
Zwei Leuchten am Bett. Eine links, eine rechts. Jede Seite hat auch einen Schalter um die Leuchten jeweils separat schalten zu können. Außerdem gibt es einen Schalter am Eingang, der die beiden Leuchten zentral zusammen schalten kann.
1/1/3 Gruppe schaltet Leuchte rechts (Taste Taster rechts und Aktor Kanal A)
1/1/4 Gruppe schaltet Leuchte links (Taste Taster links und Aktor Kanal B)
1/1/2 Gruppe schaltet Leuchte rechts und links (Taste Taster Eingang und Aktor Kanal A und B)
Taster rechts schaltet Gruppe 1/1/3
Taster links schaltet Gruppe 1/1/4
Taster Eingang schaltet Gruppe 1/1/2
Das sind die jeweils ersten Gruppenadressen, die zu den Kommunikationsobjekten gesetzt wurden. Das funktioniert auch soweit. Nur bekommen die Geräte nichts voneinander mit, wenn die geschaltet werden. Das lässt sich auch über Flags nicht lösen, weil verschiedene Gruppen geschaltet werden. Die Taster können nur innerhalb der Gruppe lauschen.
Die Lösung ist die „hörende“ Adresse, die als zweites oder fortfolgend zum Kommunikationsobjekt gesetzt wird.
Taster rechts schaltet Gruppe 1/1/3, 1/1/2
Taster links schaltet Gruppe 1/1/4, 1/1/2
Taster Eingang schaltet Gruppe 1/1/2
Der Taster rechts beispielsweise hört nun auf Adresse 1/1/2 und passt seinen Status entsprechend an, wenn der Taster Eingang geschaltet wird. Bedenke! Nur die erste Adresse auf dem Kommunikationsobjekt ist schreibend! Die fortfolgenden sind hörend!! Nicht zu verwechseln mit „lesend“!! Lesend wäre, wenn aktiv ein diverses Kommunikationsobjekt abgefragt wird.
[…]