Eigentlich scheint die Programmierung einer Homematic doch eine ganz einfache Sache zu sein. Die WENN…DANN-Sprache entspricht ja auch unserer Denklogik, aber speziell die Homematic WebUI-Logik hat mir persönlich anfangs doch einige Verständnisprobleme bereitet. Vielleicht war der Grund, daß ich mit Hardware- und Software-Logik beruflich vorbelastet bin und man dann leicht in bestimmten Denkmustern verfangen ist. Mit diesem Artikel möchte ich einerseits klar machen, was in der CCU wie funktioniert und möchte andererseits Interessierten eine Hilfestellung zur Einarbeitung in die WebUI-Logik geben.
So funktioniert (vermutlich) die WebUI-Logik
Bewußt wurde in der Überschrift „vermutlich“ hinzugefügt, weil ich kaum entsprechende Erklärungen und Erläuterungen zum Thema gefunden habe. Im Homematic-Forum sind einige gute Hinweise zu diesem Thema, die für ein grundlegendes Verständnis hilfreich sind.
Der Hauptunterschied der WebUI-Logik im Vergleich zu einer nahezu gleichzeitig und parallel arbeitenden Hardware-Logik (mit UND oder OR Gattern usw.) ist, daß die Homematic-Software „ereignisorientiert“ funktioniert. Die Software arbeitet nicht kontinuierlich das programmierte Logikschema ab, sondern ist nur dann aktiv, wenn Ereignisse oder Veränderungen stattfinden. Das hat den Vorteil, daß der jeweilige Prozess nur dann behandelt wird, wenn er auch Behandlung benötigt. Wenn in dem jeweiligen Prozess nichts passiert, dann nimmt der Prozess auch keine Rechenkapazität in Anspruch. So kann selbst ein relativ rechenschwacher Computer eine relativ große Zahl von Prozessen steuern und trotzdem relativ schnell reagieren.
Versuchen wir mal, mit einem einfachen Beispiel die Funktion kennenzulernen:
Es handelt sich um die einfache UND-Verknüpfung von zwei Logiksignalen A und B. Nur wenn beide 1 sind , dann ist auch der Ausgang C=1. Die zeitliche Darstellung einer bestimmten Sequenz eines A-Signals und eines B-Signals führt mit der UND-Verknüpfung zu einem C-Signal, was exakt nur dann 1 ist , wenn A und B gleichzeitig 1 sind. So kennen wir die Logik und so denken wir manchmal, daß auch so die Homematic funktioniert. Die Homematic arbeitet aber ereignisorientiert: Die Eingangsbedingungen bekommen bei der WebUI-Programmierung dazu ein zusätzliches ereignisorientiertes Kennzeichen:
Entweder bei Aktualisierung auslösen oder bei Änderung auslösen oder nur prüfen .
Mit diesem Kennzeichen wird nun festgelegt, ob überhaupt und wie oft das Programm logisch durchlaufen wird. Zum Verständnis schauen wir uns mal das nächste Bild genauer an:
Auf der CCU laufen vier Hauptprozesse ab:
– Program-Execution
Hier werden die vom Anwender erstellten WebUI-Programme abgearbeitet. Das Ergebnis sind in der Regel Aktorbefehle oder Wertzuordnungen für selbst definierte sog. Systemvariable.
– Outputs-Management
Die Aktorbefehle aus den User-Programmen werden in diesem Prozess in Stell- und Schaltgrößen für die verwendeten Aktoren umgesetzt.
– Events-Management
Hier sind alle Bedingungen aus allen User-Programmen gesammelt. Jeder Bedingung sind Programme zugeordnet, in denen genau diese Bedingung verwendet wird.
– Inputs-Management
In diesem Prozess werden die Sensoren und Aktorzustände regelmäßig abgefragt. Ein Timer erzeugt ein aktuelles Zeitsignal.
Das Zusammenspiel der vier Prozesse ist folgendermaßen:
Im Inputs Management wird regelmäßig geschaut, ob sich der neue Wert vom alten Wert unterscheidet. Im Unterschiedsfall signalisiert dieser Prozess ein Ereignis (Event) an den Event-Manager. Wenn das Signal sich nicht verändert hat, dann passiert nichts. Wenn ein Event signalisiert wird, dann prüft das Events-Management in der Liste alle Bedingungen, ob und welche Bedingungen zutreffen. Diese positiven Bedingungen werden nun mit einem „roten Punkt“ gekennzeichnet . Jeder Event mit einem roten Punkt bekommt nun einer Behandlung in der Form, daß alle Programme, in denen diese konkrete Bedingung verwendet wird, ausgeführt werden müssen. Das Programmausführen übernimmt nun der Program-Execution-Prozess, indem er zyklisch beim Events-Management nachschaut , ob und welche Events mit einem roten Punkt gekennzeichnet sind. Wenn das Programm ausgeführt wurde, dann wird der rote Punkt wieder gelöscht; das zugehörige Ereignis wurde ja abgearbeitet. Auf diese Art und Weise kann die CCU eigentlich nicht überlastet werden, weil im Überlastfall fast alle Events mit roten Punkten gekennzeichnet sind und es eben länger dauert, bis alle behandelt werden. Im schlimmsten Fall werden die Events nochmal auf rot gesetzt, bevor überhaupt eine Behandlung(und damit Löschung des roten Punktes) stattgefunden hat. Dann „verschluckt“ die CCU möglicherweise einige Aktionen!
Aber man muß sehr positiv anmerken, daß eine solche ereignisorientierte Steuerung bei den in der Hausautomation vorkommenden meist langsamen Veränderungen eine ausgezeichnete und effektive Steuerungsart ist.
Die gute Frage: Änderung, Aktualisierung oder Prüfen
Bei der Programmierung eines neuen WebUI-Programmes hat der Anfänger oft ein Problem mit der Entscheidung für das richtige Ereignis-Attribut: Änderung/Aktualisierung/Prüfen. Dabei ist die richtige Wahl entscheidend für die richtige Funktion des Programmes. Am Beispiel der UND-Verknüpfung zweier Eingangsgrößen A und B zur Ausgangsgröße C soll das verdeutlicht werden.
Zuerst schauen wir uns an, was passiert, wenn beide Eingangsbedingungen A und B das Attribut Änderung haben (Bild oben links) . In diesem Fall läuft das Programm insgesamt 4 mal durch; jedesmal wenn eine Eingangsbedingung sich verändert hat. Die Programmdurchläufe (violette Pfeile) erfolgen kurz nach Eintritt der Änderungen. Wie lange „kurz“ ist hängt davon ab, wieviele Ereignisse gerade abgearbeitet werden. Dementsprechend zeitverschoben entsteht das Ergebnis C (blaue Linie). Im Vergleich zu einer idealen UND-Verknüpfung ( grüne strichlierte Linie) haben wir durch die Zeitverzögerung nur geringe Unterschiede.
Im Beispiel oben rechts hat die Eingangsbedingung A das Attribut Änderung, B wird nur geprüft. In diesem Fall werden nur zwei Programmdurchläufe angestossen, währenddessen die UND-Bedingung nicht erfüllt ist. Ergebnis ist, daß das Ausgangssignal null bleibt.
Im umgekehrten Fall, A hat Attribut Prüfen und B hat Attribut Änderung (Bild unten links), entsteht ein völlig anderes Ergebnis. Auch hier wird das Programm nur zweimal durchlaufen, aber während des ersten Durchlaufes geht C auf 1 und während des zweiten Durchlaufes geht C auf 0; aber viel später als bei der idealen UND-Verknüpfung!
Im letzen Beispiel (Bild unten rechts) mit beiden Eingangsbedingungen mit dem Attribut Prüfen passiert am Ausgangssignal gar nichts.
Man sieht an den Beispielen, daß die Wahl des Ereignis-Attributs ganz entscheidend für die Funktion ist.
Mit dem Attribut Aktualisieren ( siehe folgendes Bild) wird die Sache noch komplizierter! Wenn eine oder mehrere Eingangsbedingungen das Attribut Aktualisieren haben, dann wird jedesmal, wenn das Eingangssignal aktualisiert wird, das komplette Programm durchlaufen. Und das kann unter Umständen sehr häufig sein. Bei einem Temperatursensor beispielsweise alle 3 Minuten. Positiv ist, daß das Ausgangssignal sehr nahe an die ideale Verknüpfung kommt. Wenn Rechnerbelastung keine Rolle spielen würde, dann wären Lösungen mit dem Attribut Aktualisieren eigentlich sehr gut. Aber das ist nur theoretisch, denn in der Praxis führt ein häufiger Gebrauch von Aktualisieren zu einer Überlastung der CCU !
Also das Attribut Aktualisieren nur in Ausnahmfällen verwenden !
Man muß immer berücksichtigen, daß bei einem Programmdurchlauf auch immer das komplette Programm mit sonst wenn und sonst durchlaufen wird. Gerade wenn viele verschiedene Eingangsgrößen logisch verknüpft werden, dann sollte man sich das verwendete Ereignisattribut jeder Eingangsgröße genau überlegen, weil jede Größe mit Änderung die Häufigkeit für einen Programmdurchlauf erhöht.
