Zentralenprogramme - Ein Blick hinter die Objektstruktur

Einrichtung, Anschluss und Programmierung der HomeMatic CCU

Moderator: Co-Administratoren

Antworten
Benutzeravatar
Black
Beiträge: 2035
Registriert: 12.09.2015, 22:31
Wohnort: Wegberg
Hat sich bedankt: 10 Mal
Danksagung erhalten: 31 Mal
Kontaktdaten:

Zentralenprogramme - Ein Blick hinter die Objektstruktur

Beitrag von Black » 21.03.2019, 10:24

Programme und ihre interne Abarbeitung.

Eine allseits beliebte Fehlerquelle, grade für Anfänger, auch alte Hasen fallen schon mal auf das interne Handling der Rega herein.
Zuerst einmal werden wir mal einen Blick dahin, wie die Rega ein CCU Programm abspeichert. Bekannterweise werden alle Daten der CCU wie Geräte, Räume, Gewerke, auch Programme in der Regadom in Form von Objekte gespeichert.

So ist es auch bei Programmen. Man kann dies alles auch händisch mit Scripten darstellen, der Übersicht halber verwende ich dafür allerdings den SDV.
Die Programme befinden sich in der Rega unter dem Object ID_PROGRAMS aufgelistet auf meinem Testsystem sieht das so aus:
PRG1.jpg
Betrachten wir hierbei einmal das Program DEMO

PRG2.jpg

Ein ganz normales CCU Klicki Bunti Programm. Das programm wird repräsentiert durch das programmObject mit der ID8632 und dem namen DEMO.
zu jedem ProgrammObjekt gibt es auch mindestens eine Regel, also ein RegelObject oder auch RULE
PRG3.jpg
Streng genommen kann man sich nun folgendes Programm in der rega in folgender Aufteilung vorstellen:

ProgramRules.jpg

der erste grosse Block, der durch Bedingung: wenn eingeleitet wird, repräsentiert die erste Rule des programme. Zur besseren veranschaulichung das ProgrammObjekt im SDV aufgelöst:

PRG4.jpg

Eine Rule besteht also immer aus einem ConditionObject (Bedingungsobject) und einem DestinationObject (dem Aktionaobject)

Betrachten wir die Conditions:
in dem Bild des Web UI programmes sehen wir in der ersten Rule 2 Conditions, die über oder Verknüpft sind.
Hierbei ist zu Interpretieren:
Condition 0: 00.00 Heisst Rule 0, Condition 0
Condition 1: 00:01: heisst Rule 0, Condition 1
In der Detaildarstellung des SDV ist auch das idarray RuleConditions schon aufgelöst dargestellt, man sieht hier auch die 2 Conditions

schauen wir nun mal in die Condition0:
PRG5.jpg
Man sieht, CndOperatirType= OPERATOR OR, also die Oder verknüpfung der beiden Conditions und den Verweis auf die beiden Singleconditions, die in der ersten Condition enthalten sind.
dargestellt im Listenfeld unter
SC0: 00.00.00
und
SC1: 00.00.01
auch hier im idarray CndSingleConditions der verweis auf die beiden vorhandenen SingleConditions.

auch die erste davon schauen wir uns mal an:
PRG6.jpg
es wird vergleichen: logigtype bei (Conditiontype 1)
trigger bei Änderung (Conditiontype2)
und zwar eine Systemvariable (Leftvaltype19, ivtSystemId) mit der ID 1855 (die Systemvariable AllwasyTrue)

wird verglichen auf RightVal1ValType 2 (Binary - also alles gut, weil die Systemvariable auch Typ Bool ist)
auf den Wert RightVal1 false:

und wie man schaut, ist das genau die erste Zeile des Programmes der WebUI.


Man sieht also, ein programm ist sequenziell aufgebaut.

Nun wird ein programm nur ausgelöst, wenn es getriggert wird, also ein Ereignis (bei Änderung, bei aktualierung) eintritt. Wenn ein trigger eintritt, wird dieses Programmobjekt genommen und ersteinmal ausgewertet.
Als beispiel dazu mal ein Innenblick in ein Zeitmodul, hier ist angegebem bei Triggerauslösuung, welches Programm zur bearbeitung aus der Schublade gezogen werdne soll, hier in dem Beispiel das Programm ID 9047 mit dem Namen TESTZEITM
PRG7.jpg
Wenn also ein Trigger ausgelöst wurde, wird als das Programmobject der Prüfung unterzogen, was nun gemacht werden soll. Dazu geht nun die Rega streng durch die Objekte und ihre Unterobjekte durch. und fängt dabei über das Programmobject mit der Rule 0 an, geht dabei in das Conditionobject und fängt an zu prüfen, ob am Ende der logischen Überprüfung des ConditionObjektes ein Logisch true bei Rauskommt.
Wenn ja, werden die Aktionen unter Destination abgearbeitet und das Programm ist fertig.
Wenn nein, wir die nächste Rule genommen, hier im Beispiel Subrule Rule 01 und die Überprüfung wird da genauso über das Conditonsobject durchgeführt, bei Erfolgt wird die die Destinationliste der Rule abgearbeitet und ende, bei nein, die nächste Rule.
Ist die Letzte Rule die Sonst Rule (Elseifflag=false) dann wird, so vorhanden, dann dort die DestinationList abgearbeitet.

hierbei verstecken sich nun einige mögliche Stolperstellen.

Beispiel: Alarmzone2 würde in dem WebUI Programm triggern.
heisst, die Rega zieht das Programmobject aus der Schublade, und fängt an, Rule 0

ist jetzt in dem Programmbeispiel "allwaytrue" auf false UND >Rollo.AstroTag auf Nacht so ist die Condition der RULE 0 !!! erfüllt (obwohl RULE 1 - Alarmzone2 der eigentliche Auslöser des Programmes war.

Ausgeführt wird aber : die Anweistungsliste unter RuleDestinations der RULE 0, weil dessen Bedingungen als erstes wahr waren.

In dem beschriebenen case wird also CCUBoot auf Running gesetzt und nicht, wie man es vllt erwartet hätte, DI_ATELIER_TUR:1 auf ShopAnwahlZu.

und schon haben wir einen Fehler in dem (logischen) Ablauf unserer programme, der aber kein CCU fehler ist, sondern unserer.

Black
Zuletzt geändert von Black am 21.03.2019, 11:40, insgesamt 2-mal geändert.
Die Wahrheit ist ein Chor aus Wind
Meine Seite, ok noch bisschen im Aufbau

RaspberryMatic 3.47.18.20190918 mit Groundplane Antennenmod und depatchter Favoritensortierung
jede Menge Sensoren und Aktoren, Logamatic 2107 Gateway zum Buderus Kessel
ioBroker unter ProxMox auf NUC als Hauptsteuersystem und Visualisierung
Script Time Scheduler V1.3
SDV 3.09.01 Scripteditor und Objektinspektor

Benutzeravatar
Black
Beiträge: 2035
Registriert: 12.09.2015, 22:31
Wohnort: Wegberg
Hat sich bedankt: 10 Mal
Danksagung erhalten: 31 Mal
Kontaktdaten:

Re: Zentralenprogramme - Ein Blick hinter die Objektstruktur

Beitrag von Black » 21.03.2019, 11:02

Damit erklären sich dann auch die nächsten Punkte.

Neustart der CCU, es werden alle Programme getriggert.
heisst, die Rega zieht alle ihre Programmeobjekte(in der Reihenfolge des Vorkommens in der ID_PROGRAMS Liste) und arbeitet diese wie im ersten Post beschrieben durch. Trifft sie auf auf eine Rule, deren Condition true ist, so wird die Liste unter dem DestinationObjekt abgearbeitet. Auch hier ist die Falle, hat man ein Programm mit vielen Sonst Wenn, ist dieses eine der Bevorzugten Fehlerquellen.

und dann gibts noch den manuellen Start eines Programmes in der WebUI.
Hier gibt die regel, es wird von der ersten Rule blind die DestinationList abgearbeitet, es findet keine Überprüfung der Conditions statt.

Wenn man diesen Aufbau verstanden hat und damit ein bisschen spielen kann und weiss, wie man gezielt dann sequentiell ein gesuchtes SingleCondition oder SingleDestinationObject ansprechen kann
mit diesen möglichkeiten kann man:
1.verzögert um in den Destinations via Script verändern
2. Zeitmodule dynamisieren (nicht mehr nur statisch veränderbar in der WebUI, sondern auch von einem Script heraus, damit frei anpassbar z.b. zeitspannen oder Zeitpunkte) (damit sollten wir aber warten bis zum regaFix von jens)

Black
Die Wahrheit ist ein Chor aus Wind
Meine Seite, ok noch bisschen im Aufbau

RaspberryMatic 3.47.18.20190918 mit Groundplane Antennenmod und depatchter Favoritensortierung
jede Menge Sensoren und Aktoren, Logamatic 2107 Gateway zum Buderus Kessel
ioBroker unter ProxMox auf NUC als Hauptsteuersystem und Visualisierung
Script Time Scheduler V1.3
SDV 3.09.01 Scripteditor und Objektinspektor

gzi
Beiträge: 309
Registriert: 12.01.2015, 23:37

Re: Zentralenprogramme - Ein Blick hinter die Objektstruktur

Beitrag von gzi » 29.03.2019, 08:37

Danke für den tollen Beitrag, Black!

Jetzt frage ich mich auch warum ich SDV nich schon längst installiert habe, so wie ich das ohnehin schon lange tun wollte....

gzi
HomeMatic Sicherheits-Kompendium - SCS, CCU, diverse HM-Aktoren und Sensoren, UPS, SMS, Voice, Mail, HTTPS-Interface usw. (sicheres(!) Port-Forwarding aus dem Internet zur CCU und LAN-Firewall via SCS,100% Datenkraken-frei. wahrscheinlich auch NSA-sicher :-) ) - Checkliste für Auswahl von IP Kameras - Vergleich aktueller HomeMatic Zentralen - und alle Antworten für das gesamte Universum und den Rest

Benutzeravatar
Black
Beiträge: 2035
Registriert: 12.09.2015, 22:31
Wohnort: Wegberg
Hat sich bedankt: 10 Mal
Danksagung erhalten: 31 Mal
Kontaktdaten:

Re: Zentralenprogramme - Ein Blick hinter die Objektstruktur

Beitrag von Black » 02.04.2019, 22:21

gzi hat geschrieben:
29.03.2019, 08:37
Danke für den tollen Beitrag, Black!

Jetzt frage ich mich auch warum ich SDV nich schon längst installiert habe, so wie ich das ohnehin schon lange tun wollte....

gzi
Thnx für die Konstruktive kritik. Die nächste Zeit kommt da auch noch die ein oder andere Ergänzung zu.
Zum Installieren, einfach auf github, runterladen, entpacken, die INI gemäß Anleitung anpassen, Anfragecode erstellen und mir per PM schicken.

gruss, Black
Die Wahrheit ist ein Chor aus Wind
Meine Seite, ok noch bisschen im Aufbau

RaspberryMatic 3.47.18.20190918 mit Groundplane Antennenmod und depatchter Favoritensortierung
jede Menge Sensoren und Aktoren, Logamatic 2107 Gateway zum Buderus Kessel
ioBroker unter ProxMox auf NUC als Hauptsteuersystem und Visualisierung
Script Time Scheduler V1.3
SDV 3.09.01 Scripteditor und Objektinspektor

Antworten

Zurück zu „HomeMatic Zentrale (CCU / CCU2 / CCU3 / Charly)“