Das Thema Sommer/Winter-Umschaltung ist ein gutes Beispiel, bleiben wir mal da dabei.
Ganz grundsätzlich muss man sich klar machen (nicht nur bei KNX, sondern ganz allgemein bei der Automatisierung; wobei manche Systeme das ziemlich verstecken): Was ist ein "Zustand" (und wenn man damit auch noch rechnen möchte muss man es eigentlich auftrennen in: was ist eine Bestandsgröße / Potentialgröße und was die davon abgeleiteten Flussgrößen / Stromgrößen?) und was ist ein "Ereignis" (Event)?
- Ein Zustand ist etwas, da kann ich zu jedem Zeitpunkt mit einem geeigneten Messgerät hingehen und diesen Zustand messen.
Beispiel: Mit einem Kalender kann ich messen ob Sommer oder Winter ist
- Ein Event ist etwas, was einen Zeitpunkt hat, sonst nichts. (Man kann es erweitert auffassen, so dass der Zeitpunkt auch noch einen Wert hat).
Beispiel: der Zeitpunkt des Wechsels von Sommer auf Winter
Damit ist auch klar: einen Event kann man nicht lesen. Er ist da oder eben nicht.
Man kann höchstens in der Vergangenheit nachschlagen wann der Event jeweils kam, oder vorhersagen wann mal wieder einer kommen wird. Das ist dann aber kein Event mehr, diese Informationen sind dann eigentlich schon wieder Zustände.
Oft ist die Information relevant welchen Wert der letzte Event hatte. Diese Information ist dann aber eben ein Zustand. (Z.B. bei einem KNX Block für eine UND-Verknüpfung: der kann nur bei einem Event auf einem Eingang das mit dem letzten Wert auf dem anderen verknüpfen - was aber eben kein Event mehr ist, sondern ein Zustand.)
Anderes Beispiel (weil Wikipedia da das Zustandsdiagramm für hat) ist eine Tür. Die kann offen oder zu sein. Das ist der Zustand. Den kann ich messen. Der Wechsel zwischen geschlossen und offen ist dagegen ein Event. Das ist (in diesem einfachen Modell) nicht mehr messbar, sondern nur ein Zeitpunkt. In Grafisch ist dass dann:
Nach der Definition folgen die Konsequenzen daraus:
- Ein Event ist prinzipbedingt nicht lesbar
- Ein Zustand sollte es nur an exakt einer Stelle geben - wenn es Redundanzen gibt, dann ist die Gefahr hoch, dass sich diese widersprechen. Das muss zwingend vermieden werden!
- Das lässt sich nur vermeiden, wenn bei mehreren potentiellen Quellen eine einzige als gültig definiert ist
Und damit sind wir beim Problem Sommer/Winter und dem Heizungsaktor.
Ist der Heizungsaktor die einzige gültige Quelle für den Zustand ob Sommer oder Winter ist?
Das wäre für mich ein unlogisches Systemdesign (ich hätte diese Information eher bei irgend einer Zeitquelle vermutet), aber möglich. Und schon bei zwei Heizungsaktoren (z.B. weil die Zahl der Heizkreise nicht mehr nur auf einen passen) problematisch: wer von beiden hat denn nun recht, wenn sich die Werte unterscheiden?
KNX bietet hier das notwendige Werkzeug um mit dem Thema Event und Zustand korrekt umzugehen:
Die normalen Telegramme sind Events. Beispielsweise das Event: "Licht EIN" vom Lichtschalter. Der hat aber keinen Zustand, da der gar nicht wissen kann was das Relais im Schaltaktor so macht. Das Telegramm geht zum Schaltaktor, der hat nämlich nun einen Zustand (Relais ist an oder aus). Wenn der Schaltaktor nun geschaltet hat, so stellt der auf einem anderen KO diesen Status bereit. Gerne sendet er den gleich mal bei einer Änderung. Aber er lässt sich auch mit einem Lese-Telegramm auf diesem anderen KO abfragen.
Das Telegramm von diesem anderen KO des Schaltaktors geht nun wieder zurück an den Taster für dessen Status-Eingang. Damit kann der Taster nämlich seine LED ändern, die (hoffentlich!) immer dem Relais-Zustand des Schaltaktors entspricht.
Und, jetzt kommt das geniale bei KNX, lässt sich damit auch leicht die "Alles Aus" Funktion realisieren: man gibt dem Schaltaktor-Event-KO einfach eine weitere GA, die Alles-Aus-GA, auf die der hören soll.
Drückt nun jemand die Alles-Aus-Taste, geht das Aus-Event über die Alles-Aus-GA auf das Event-KO des Schaltaktors. Dem ist vollkommen egal, welches Event das ist, der schaltet nun aus. Ändert folglich ggf. seinen Status. Und gibt diese Info über das Status-KO an die sendende GA da dran. Die ist mit dem Taster-Status-Eingang verbunden. Und somit weiß der Taster, dass nun das Licht aus ist, obwohl er selbst nicht betätigt wurde. Und folglich ist der nächste Tastendruck ein EIN (obwohl der letzte Tastendruck auch schon ein EIN war).
=> Der KNX trennt zwischen Event und Zustand
=> Der KNX kann damit umgehen, wenn zwei getrennte Geräte eigentlich den gleichen Zustand haben sollten (Relais Schaltaktor + LED im Taster)
Wenn manche KNX Geräte das nicht können, oder andere Bus Systeme das grundsätzlich nicht können, so ist das ein reales Problem. Am besten einen Bogen drum machen und etwas nehmen, was das kann.
Und immer überlegen: Ist das ein Event oder ein Zustand? Und wenn es ein Zustand ist: wer ist der Master?
