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:
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
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:
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:
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:
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
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