CCU im Reboot geht irgendwie nicht

[Chemieka]

Hallo
Ich habe mehrere Programme welche beim Reboot ausgeführt werden obwohl ich die Variable in den Programmen habe.
Um genau zu sein habe ich für meine Poolpumpensteuerung drei Programme um sie zu aktivieren nutze ich 3 Variablen (Pro1,Pro2,Pro3)
Ich wähle also Programm 3, nach dem Reboot ist die Variable jedes mal wieder deaktiviert. Also schauen wir welche Programme mit dieser Variablen arbeiten. Es sind nur 4 und ich füge sie mal an. Warum wird meine Progtrammwahl immer deaktiviert?
Das gleiche passiert auch immer mit den HUE Lampen. Zum verrückt werden.

[Black]

dein programm wird nicht (nicht ausgeführt), das ist dein Denkfehler:

jedes Programm, welches aktiviert ist, wird beim Systemstart in der reihenfolge ihres Auftretens in der ID_PROGRAMS liste getriggert.

Heisst, das Programm wird angestossen und arbeitet nun die Programconditions durch.
Im wenn teil, stösst es auf Reboot, also ist der teil False, also wird der Wenn Teil nicht abgearbeitet,

und schon im ersten programm hast du den Sonst part, der dann durchlaufen wird und wo deaktiviert wird

Black

[Chemieka]

OK das verstehe ich nur zum Teil. Nehmen wir mal Programm eins. Was schlägst du vor?

[Chemieka]

Bei Programm 1 würde es so gehen?

[Black]

man kann jetzt meinen Stil nicht unbedingt verallgemeinern, aber...

ich schreib alle meine Programme in etwa immer so:

oben nur die triggerbedingung:

bei dir wäre es Bidcos:37 bei Tastendruck kurz

und dann so ein Script in diesem Stilim Dann Teil: das ganze ohne Sonst

Code: Alles auswählen

object oscr= dom.GetObject ("$src$");
if (oscr) {
   !- Aufruf erfolgte nicht durch reboot, sondern nur durch BidCos-RF37
   object oPRG1= dom.GetObject (ID_SYSTEM_VARIABLES).Get ("POOL PROGRAMM 1");
   oPRG1.State (! (oPRG1.State () ));
   dom.GetObject (ID_SYSTEM_VARIABLES).Get ("POOL PROGRAMM 2").State (false);
   dom.GetObject (ID_SYSTEM_VARIABLES).Get ("POOL PROGRAMM 3").State (false);
   dom.GetObject (ID_SYSTEM_VARIABLES).Get ("POOL PROGRAMM MANUELL").State (false);
}  

[Chemieka]

Du machst quasi alles über Skript. Ich habe die Variante oben in der Zwischenzeit auch in die anderen Programme eingefügt also aus sonst immer sonst,wenn gemacht (wie im Beispiel) und ich glaube es geht so.
Danke dir fürs "auf die Sprünge helfen"

[Black]

Yap... viele Wege führen nach Rom und sind auch ok.

Dein Ansatz sollte auch zielführend sein. Fürs gedankliche anschubsen sind wir ja im Forum da

Greetz black

[nimmnenkeks]

man könnte die Programme auch so gestalten, dass sie beim Systemstart (solange CCU im Reboot ist) gar nix machen, bis der Systemstart abgeschlossen ist und erst dann auf den/die Trigger reagieren.
Zusätzlich könnte man die Programme in eine Startreihenfolge zwingen, dass sie auch erst dann ausgeführt werden, wenn bestimmte Zusatzparameter im Vorfeld gesetzt werden müssen, bzw. erforderlich sind.

Geht man diesen Weg und hält sich an einen best. Programmaufbau hat man IMHO somit auch eine wesentlich verbesserte Übersicht in den Programmen selbst und kann diese besser strukturieren, indem sich etwaige Zusatzparameter für die Programmweiterführung "Dann mach DAS" meist alle in einem Programm in einem Abwasch erledigen lassen.

Die Prüfung von SysVars beim Systemstart und der damit manchmal damit verbundenen nicht gewollten Programmstarts lassen sich leicht durch das Ersetzen von Logikvariablen in Wertelisten ändern (in diesen wird als erster Wert "unbekannt" eingetragen). Enstsprechende SysVars werden beim Systemstart einfach auf 0/unbekannt gesetzt und sorgen in den Programmen als (im Betrieb) mit diesem Wert zu keinen unerwünschten Programmabarbeitungen.

Lässt sich auch leicht ohne Scripte umsetzen.

Diese Vorgehensweise und Umsetzung hat BadenPower in einem Fred ausführlich beschrieben.

Ist nur eine weitere Möglichkeit..

[Xel66]

man könnte ....
Zusätzlich könnte man ...

Man könnte vieles. Aber man könnte bei der Anlage von Programmen auch ganz einfach mal gedanklich einen Systemstart durchgehen. Beispiel: man hat ein einfaches Rollladenprogramm und möchte, dass die Rollladen von 22:00 Uhr bis 06:00 Uhr geschlossen sind. Dieses legt man in einem Programm als Zeitspanne an. Erfolgt dann ein Reboot, wird geprüft, ob die aktuelle Uhrzeit innerhalb dieses Zeitraumes liegt und die Rollladen entsprechend verfahren. So ist es vom Hersteller gedacht. Legt man beide Befehle als Einzelbefehle zu den entsprechenden Uhrzeiten an, wird kein Rollladen verfahren (es sei denn, es ist gerade laut Beispiel 22:00 oder 06:00 Uhr). Die CCU stellt eben alles so hin, wie es für die aktuelle Datenlage (Systemvariable, Statusrückmeldungen etc.) laut der angelegten Programme "richtig" ist.

Beachtet man diese Arbeitsweise der CCU sind auch keine Würgarounds mit zwangsweise Setzen von irgendwelchen Variablen u.ä. notwendig. Es gibt natürlich Ausnahmen, die sich durch ein solches Vorgehen nicht abdecken lassen. Für diese kann man dann eben die Version mit der originalen Anwesenheitsvariable benutzen. Die sollten aber eigentlich in der Minderheit sein, denn es eben nicht so, dass "alle Programme bei Systemstart gestartet" werden. Es wird lediglich eine Bedingungsprüfung entsprechend der gespeicherten und rückgemeldeten Statusinformationen der Aktoren, Sensoren und Systemvariablen durchgeführt. Ergibt eine dieser Prüfungen in einem WENN oder SONST WENN ein WAHR, dann wird das dazugehörige DANN ausgeführt. Stolperfallen sind eben Programme, die ein SONST enthalten. Diese Aktion lässt sich auch mit dem Anwesenheitsvariablen-Workaround nicht umgehen (im Gegenteil).

Gruß Xel66

[nimmnenkeks]

man könnte ....
Zusätzlich könnte man ...

Man könnte vieles..
Die CCU stellt eben alles so hin, wie es für die aktuelle Datenlage (Systemvariable, Statusrückmeldungen etc.) laut der angelegten Programme "richtig" ist.

Beachtet man diese Arbeitsweise der CCU sind auch keine Würgarounds mit zwangsweise Setzen von irgendwelchen Variablen u.ä. notwendig. Es gibt natürlich Ausnahmen, die sich durch ein solches Vorgehen nicht abdecken lassen.

Nun der TE hat um Input gebeten, und wenn er diese Methode/Vorgehensweise nicht kennt kann er sie auch nicht ausprobieren.
Es ist schließlich jedem User selbst überlassen

Es soll auch User geben, die Daten aus einer CSV auslesen und in SysVars schreiben, was lt Deiner Aussage auch nicht sinnvoll einzusetzen ist.
Komisch läuft seit Jahren ohne irgendwelche Vorkommnisse ohne Probleme.
In diesem Beispiel sind wesentlich feinere Abstimmungsmöglichkeiten bei Sonnendaten bezogenen Daten möglich.
viewtopic.php?f=19&t=35505

Es gibt zig Anwendungsszenarien, die von einem geordneten Systemstart profitieren.
Nach einem Reboot eben "aktuelle Daten sammeln" (anyway ob per Skript oder Programm) und nicht die getriggergen Programme mit veralteten Systemvariablenwerte laufen lassen (Bsp. ein in der Zwischenzeit geöffnetes Fenster).

Für diese kann man dann eben die Version mit der originalen Anwesenheitsvariable benutzen. Die sollten aber eigentlich in der Minderheit sein, denn es eben nicht so, dass "alle Programme bei Systemstart gestartet" werden. Es wird lediglich eine Bedingungsprüfung entsprechend der gespeicherten und rückgemeldeten Statusinformationen der Aktoren, Sensoren und Systemvariablen durchgeführt.

Ist natürlich dumm, wenn in der Zwischenzeit die Zustände der Systemvariablen nicht mehr mit der Wirklichkeit übereinstimmen (s.o.).

Ergibt eine dieser Prüfungen in einem WENN oder SONST WENN ein WAHR, dann wird das dazugehörige DANN ausgeführt. Stolperfallen sind eben Programme, die ein SONST enthalten. Diese Aktion lässt sich auch mit dem Anwesenheitsvariablen-Workaround nicht umgehen (im Gegenteil).

Gruß Xel66

Hier noch einmal zum nachlesen und ggf. zum verstehen

"Reboot mit System und Ablauflogik"
viewtopic.php?f=31&t=39187&p=386406&hil ... nd#p386406

Dort beschreibt BadenPower ja die entsprechenden Vorgehensweisen für einen geordneten Reboot.

Weiterhing wird ja auch sehr schön beschrieben, wie er seine Programmstruktur aufgebaut hat.
Hält man die ein, sieht man bei einem Reboot sehr schön in den Protokolleinträgen, dass alle Programme getriggert werden,

aaaaaaaaaaaber

diese absolut gar nix machen, außer einen Eintrag in das Systemprotokoll mit dem entsprechenden Eintrag "HEADER -- Programm XY"!
Da könen ellenlange "Sonst" - in den Programmen stehen, sie werden während des Reboots einfach nicht ausgeführt

..