Der PHP Layer läuft bei mir noch im Testbetrieb. Ich habe vor das script irgendwann vor Ende des Jahres hier zu posten.
Hier schon mal die Beschreibung für alle die sich dafür interessieren :
Kommunikation`s Manager IPS <-> HOMEMATIC CCU
1.) Ausgangssituation
Die Kommunikation von IPS zum Endgerät (DEVICE) einer HOMEMATIC Installation hat eine Reihe von „Bottlenecks“ die unter Umständen dazu führen können das entweder
[ul]
[li]a. der Zustand des DEVICE in IPS nicht richtig wiedergegeben wird
[/li]
[li]b. das Device nicht geschaltet wird
[/li]
[li]c. die Kommunikation zwischen IPS und der HOMEMATIC CCU (Socket) zum Erliegen kommt
[/li]
[li]d. die HOMEMATIC CCU abstürzt.
[/li]
[li]
[/li][/ul]
Die Bottlenecks lassen sich wie folgt erklären:
[ul]
[li]a. Der Funkkanal zwischen DEVICE und CCU kann überlastet werden. Das trifft auf den Sende- wie auch auf den Empfangskanal zu. Die CCU wie auch die DEVICES unternehmen nur eine begrenzte Anzahl von Verbindungsversuchen und brechen dann unter Umständen ab ohne das geschaltet wurde oder das ein Update über den Zustand erfolgen konnte.
[/li]
[li]b. Die CCU muss als zentraler Knoten alle Änderungen richtig speichern und weitergeben. Überschreitet die zu verarbeitende Menge an Daten einen Grenzwert stürzen Teilkomponenten der CCU Software ab. Das kann insbesondere dann zu zusätzlichen Problemen mit der Konsistenz der Daten auf der CCU führen wenn zum Zeitpunkt einer Überlastung ein neues DEVICE an der CCU angelernt wird.
[/li][li]
[/li][/ul]
IPS ist ein echtes Ereignisgesteuertes Multitasking System mit Realtime Charakter. Der Programmierer muss um eine Überlastung von IPS sowie aller Folgekomponenten (XML / CCU / DEVICE) zu vermeiden, verhindern das Überlast Situationen auftreten.
Eine typische Situation könnte dadurch entstehen wenn man zum Beispiel die Warmwasser (Umwälz) Pumpe nur dann anschalten will wenn warmes Wasser auch gebraucht wird. Nutzt man dazu mehrere Bewegungsmelder die jede Bewegung an IPS weitergeben um über eine Eventsteuerung die Warmwasserpumpe anzuschalten kann, wenn zum Beispiel mehrere Personen im Haus sind, dass dazu führen das das IPS Programm mehrfach gleichzeitig gestartet wird um die Warmwasser Pumpe gleichzeitig Ein und Auszuschalten. Natürlich kann man beim Programmieren darauf achten das eine solche (unsinnige) Situation vermieden wird.
Eine ähnliche Situation kann sich ergeben wenn die Bewegungsmelder im Haus dazu genutzt werden um Lichter ein und auszuschalten oder um eine Alarmanlage oder auch mehrere 16-LED-Display`s zur Anzeige von Bewegungen in den verschiedenen Räumen des Hauses über IPS anzusteuern.
Die Ansteuerung von Rollläden (in diesem Fall 22) kann man über das Schließen der Haustür auslösen. In IPS kann das dazu führen das wie in meinem Fall 22 parallel laufende Instanzen versuchen 22 DEVICES anzusteuern und wenn die Haustür auch die Beleuchtung ansteuert kommen in diesem Fall nochmals 10 DEVICES dazu also insgesamt 32 parallel laufende Prozesse über IPS- XML – CCU – DEVICE und das in beide Richtungen.
Der Datenverkehr zwischen IPS und der CCU bzw. dem DEVICE könnte auch reduziert werden wenn ein DEVICE nur dann geschaltet wird wenn sich der IST Zustand vom SOLL Zustand unterscheidet. In den meisten Fällen funktioniert das auch, allerdings nicht immer. Das kann dann zu kritischen Situationen führen wenn zum Beispiel die Heizung ausgeschaltet werden soll und IPS glaubt der Befehl war erfolgreich (Variablen des DEVICE) aber in Wirklichkeit hat in bestimmten Fällen die CCU bzw. das DEVICE den Befehl nie ausgeführt. Da ab diesem Zeitpunkt die Raumtemperatur nur noch steigen kann und IPS glaubt das die HEIZUNG bereits ausgeschaltet ist kann dieser Fehler nur noch durch manuellen Eingriff behoben werden. Es muss daher eine Möglichkeit gefunden werden diese Situation zeitnah zu korrigieren.
Lösungsansatz
Es bietet sich an eine zentrale Kommunikations Schnittstelle zur Ansteuerung der CCU zu implementieren um die zuvor genannten Probleme zu behandeln. Die Schnittstelle ist in der Lage die folgenden Situationen zu managen :
[ul]
[li]Die Schnittstelle wird über einen WaitEX Befehl aufgerufen um auf dieser Ebene die Kausalität der Ereignisse zu gewährleisten.
[/li]
[li] Durch die Nutzung einer Semaphore wird sichergestellt das ein Device nie gleichzeitig mehrfach angesteuert wird
[/li]
[li] Wann immer ein DEVICE angesteuert wird, legt IPS den Zeitpunkt in einer eignen Schnittstellen Datenbank ab (Herzlichen Dank an Stele99 für die Scripts im Forum http://www.ip-symcon.de/forum/threads/20529-Script-(Klasse)-um-dauerhaft-Variablen-bzw-Arrays-zu-speichern]), das heißt der Zeitpunkt des letzten erfolgreichen Verändern des Devices wird gespeichert. Die Schnittstelle vergleicht IST und SOLL nur wenn der Zeitpunkt der letzten Änderung der DEVICE Zustandsvariablen in der (Original) IPS Datenbank identisch bzw. jünger ist als der Zeitpunkt in der Datenbank der Schnittstelle. Für den Fall das der Eintrag in der IPS Datenbank älter ist wird das DEVICE auf jeden Fall angesteuert da aus irgendwelchen Gründen der letzte Schaltbefehl nicht in der Status Variable des Devices gespeichert wurde. Für den Fall der Eintrag in der IPS Datenbank aktuell ist wird geprüft ob der IST Zustand vom SOLL Zustand abweicht und bei Bedarf wird das DEVICE angesteuert. Für den Fall das es sich bei dem DEVICE um einen Jalousienaktor handelt wird das zeitverhalten mit in die Bewertung einbezogen. Dazu untersucht das Programm ob sich der Aktor bereits in die richtige Richtung bewegt und schaltet nur dann, falls das nicht der Fall ist bzw. wenn das nicht zutrifft, wenn die Endposition vom SOLL Wert abweicht. Das aktivieren der Aufzeichnung der Variablenwerte in der IPS Datenbank erfolgt automatisch.
[/li]
[li] Wenn ein DEVICE geschaltet wird überprüft das Programm die Rückmeldung von IPS. Bei negativer Quittung wird der Zustand des DEVICE bei der CCU aktiv abgefragt und falls das Ergebnis positiv ist (IST = SOLL) wird die Fehlerroutine abgebrochen. Für den Fall einer Abweichung wird das DEVICE so lange geschaltet bis entweder SOLL mit IST übereinstimmt oder die maximale Anzahl der Ansteuerungsversuche erreicht wurde. In diesem Fall wird mit einer Fehlermeldung abgebrochen.
[/li]
[li] DEVICES die nicht erfolgreich angesteuert werden konnten, werden in eine Liste eingetragen und zukünftig nicht mehr dem SOLL = IST vergleich unterworfen, das heißt sie werden ab sofort immer angesteuert da der echte physikalische Zustand des Geräts nicht mit Bestimmtheit ermittelt werden kann. Der Nutzer kann DEVICES die sehr häufig geschaltet werden und die von Ihrer Funktion nicht zu kritischen Fehlersituationen führen können (z.B. LED Display) in eine Liste eintragen. Diese DEVICES werden von der Fehlerbehandlung ausgenommen da sich der Fehler nach einer gewissen Anzahl von Ansteuerungen meistens von selbst korrigiert.
[/li]
[li] In einer weiteren Liste können DEVICES abgelegt werden die unter keinen Umständen angesteuert werden dürfen (z.B. Sonnenschutzrollos auf dem Dach im Winter wenn Schnee auf dem Fenster liegen kann)
[/li]
[li] Zur Überwachung der Schnittstelle gibt es eine Reihe von Statistik Funktionen die detailliert Auskunft geben über :
[/li]
[li] Wirkungsgrad der Schnittstelle (Verhältnis von Programm Ansteuerungen eines DEVICES zu echten Schaltvorgängen) in meinem Fall führen bei Anwesenheit nur ca. 4% aller Befehle zu einer CCU Ansteuerung und bei Abwesenheit sogar nur 2%.
[/li]
[li] Grafische Darstellung der (echten) Nachrichten an jede CCU pro Minute um Stoßzeiten zu ermitteln und das Programm verhalten zu optimieren. Im Verlauf der Entwicklung der Schnittstelle konnte der Spitzenwert von 50 Nachrichten/Min. auf 20 Nachrichten/Minute optimiert werden.
[/li]
[li] Das Auftreten der verschiedenen Fehler wird aufgezeichnet und erlaubt dem Nutzer Zusammenhänge besser zu verstehen und Gegenmaßnahmen zu ergreifen wie zum Beispiel die Verteilung von Devices auf verschiedene CCU`s.
[/li]
[li] Für jedes genutzte DEVICE gibt es eine Information wie oft es angesteuert wurde und wie oft der Zeitstempel nicht aktuell war (Absoluter Wert und Prozentual) Die prozentuale Veränderung kann grafisch ausgewertet werden um das Zeitverhalten des Fehlers zu verstehen.
[/li][/ul]
:D:D:D:D:D:D
