Rollladen Steuerung

[Black]

ein Sonst teil wird aber definitiv bei einem Neustart aufgerufen. (so die Condition bedingungen Falsch waren natürlich)

du nimmst dir ein klitzekleines Programm:

Zeitmodul jetzt mittags ausserhalb der zeitspanne, triggerung nur prüfen.
richtigerweise wird das programm im Betriebsfall nie triggern (wäre auch ein typischer Anfängerfehler, Hilfe mein programm löst net aus)

ok, dann 2 scripteinzeiler

im Dann zweig:

Code: Alles auswählen

dom.GetObject("CUxD.CUX2801001:1.SYSLOG").State("Ich war der dann Teil, Innherhalb der zeit");

und im Sonst Zweig:

Code: Alles auswählen

dom.GetObject("CUxD.CUX2801001:1.SYSLOG").State("Ich war der Sonst Teil, ausserhalb der zeit");

Programm abspeichern und dann

reboot

was wird nun im Systemprotoll als Eintrag stehen ?
richitg, das hier:

Code: Alles auswählen

Aug  7 12:31:54 homematic-ccu2 daemon.info cuxd[575]: CUX2801001:1 Ich war der Sonst Teil, ausserhalb der zeit

heisst, das programm wurde ausgelöst. (von dem neustart)
und: es wurde wie erwartet der Sonst Teil abgearbeitet (logisch, die Zeit ist ja auch ausserhalb der zeitspanne)


Zu dervon dir beschriebenen Methode, ist die frage in wieweit solche Konstrukte dann Anfängertauglich und Alltagstauglich sind.
ich benutze bei mir (den Aufbau kennst du ja) folgende Struktur

(Ausschnitt aus einem realen programm auf meinem produktivsystem)

In der WebUI stehen alle bedingungen drin, die das Script auslösen können, (NICHT die Logig, nur die Trigger) alle verodert, am Ende allwaystrue ist immer wahr, so das ein trigger immer das Scriptr auslöst.

die Scriptstruktur ist dann folgende

Code: Alles auswählen

(...)
object  oSRC        = dom.GetObject ("$src$");  <<-- Hiermit wird der auslösende Trigger bestimmt, oder eben NULL
boolean bNeu        = false; !- Neuberechnen
string  sLogger     = "logger -t AstroTriggerNeu -p user.debug ";


!- Überprüfen welcher Trigger das Script aufgerufen hatte  
if (oSRC ) { !- Aufruf erfolgte mit gültigem SRC
  	if (oSRC.ID () == oRolloUp.ID () ) {
(...)
}
!- Aufruf ohne Trigger oder mit Mitternacht: --> Neu Berechnen Astro 
if ((!oSRC) || bNeu) {  	
  (...)
}

if (!oSRC) {  <<-- das ist die erkennung, ob Progtamm manuell oder beim Booten aufgerufen wurde
	!- Programm ohne Trigger aufgerufen beim Booten
	!- Astrozustand berechnen
}	  	
  	 

viele wege führen nach Rom, ich bin halt da Scriptlastig. Mit Sicherheit nicht allgemeingültig, auch vllt zu schwer für einen Anfänger, aber absolut stable.



Black

[nimmnenkeks]

auch wenn im "SONST" kein Haken im Retriggern vorhanden ist, wie in dem Programm


bzw. wie in allen im o.g. Fred aufgeführten Programmen?


BG Keks

[Black]

natürlich... spasseshalber bei mir grade im testprogramm haken rausgemacht gespeichert ... Neustart...

und wie erwartet im Protokoll:

Code: Alles auswählen

Aug  7 13:01:58 homematic-ccu2 daemon.info cuxd[577]: CUX2801001:1 Ich war der Sonst Teil, ausserhalb der zeit

und wenn ich im Zeitmodul die Zeitspanne auf bis 14:00 Uhr änder und das dingen neu boote (Jetztzeit 13:18), erfolgt wie erwartet die Ausgabe im Syslog:

Code: Alles auswählen

Aug  7 13:18:17 homematic-ccu2 daemon.info cuxd[575]: CUX2801001:1 Ich war der dann Teil, Innherhalb der zeit

Black

[Xel66]

So, nun habe ich auch mal meine Test-CCU2 bemüht und ein paar Systemvariablen als mögliche Trigger und als Protokollausgabe sowie ein paar simple Programme angelegt. Als erstes das Testszenario.

Man sieht die von mir angelegten Protokollvariablen vom Typ "Text", die in den Programmen mit Inhalt gefüllt werden können, wenn die zugehörige Bedingung ein WAHR ergibt. Diesen "Trick" nutze ich in meinem Produktivsystem auch, um bestimmte Programmläufe und Zustände im Systemprotokoll abzulegen. Das ist die einfachste Art, eigene Einträge dort zu hinterlegen.

Oben die angelegten Programme, die an Einfachheit kaum noch zu übertreffen sind. Um eine gegenseitige Beeinflussung der Systemvariablen auszuschließen, habe ich für jedes Testszenarion eigene Protokoll- und Trigger-Variablen angelegt. Als Bedingung des jeweiligen Programms der gleiche Trigger in komplementären Zuständen. Ein Programm mit und eines ohne SONST. Dazu noch zwei Programme für den Test des Zeitmoduls mit einem Zeitbereich, der beim Reboot um 14:40 Uhr ein Mal FALSCH (06:00 bis 12:00 Uhr) und ein Mal WAHR (12:00 bis 18:00 Uhr) ist. Und als einfacher Test noch ein Programm ohne Bedingung im WENN. Nach der Anlage der Systemvariablen und Programme erfolgte ein normales Ausloggen, um die Änderungen abzuspeichern. Nach erneutem Login habe ich über die GUI einen Reboot ausgelöst.

Das Ergebnis:

Nun ja, ganze drei Einträge vom Reboot und den Programmen, und nur Programme mit erfolgreicher Bedingungsprüfung haben einen Zeitstempel bekommen, weil diese beim Systemstart durchlaufen wurden. Das Zeitmodultestprogramm mit FALSCHem Zeitbereich (06:00 bis 12:00 Uhr) zum Rebootzeitpunkt um 14:40 Uhr hat keinen bekommen.

So, und nun? Warum wird das Zeitprogramm nicht durchlaufen, bzw. erhält keinen Zeitstempel, wenn doch alle Progrmme beim Systemstart "gestartet" werden? Weil die Bedingungsprüfung nicht erfolgreich war. Gäbe es ein SONST, hätte auch dieses Programm einen Zeitstempel. Alle anderen Programme hatten irgendein gültiges Prüfungsergebnis. Darum ist es auch irreführend, dass behauptet wird, alle Programme werden bei Systemstart getriggert. Das entspricht schlichtweg nicht den mit einfachen Mitteln beobachtbaren Abläufen. Es erfolgt lediglich eine Bedinungsprüfung, wie im Normalbetrieb danach auch, nur dass es hier keinen Trigger (Statusänderung oder - aktualisierung) gibt, sondern die Bedingungen so geprüft werden, wie sie im WENN oder SONST WENN hinterlegt sind. Nur bei einem Ergebnis der Bedingungsprüfung erhält das Programm unabhängig von Ergebnis (DANN- oder SONST-Pfad) einen Zeitstempel. Programme, die durch eine Statusrückmeldung eines abgefragten Aktors getriggert werden, durchlaufen logischerweise auch eine Bedingungsprüfung. Auch dieses kann zu unerwartetem Aktionen führen, entspricht aber dem beobachtbaren Gesamtkonzept der Programmtriggerung und -abarbeitung.

Gruß Xel66

EDIT: letztes Bild gegen eines mit dem aktuellen Inhalt der Systemvariablen nach Reboot ausgetauscht.

[Sammy]

Warum taucht im Protokoll kein "TESTBOOT_mit _Sonst - dann-Zweig" auf?
Dieser Zweig muss ja eigentlich auch abgearbeitet worden sein. Oder kollidiert das aus irgendeinem Grund mit dem anderen Programm, welches auch TESTPROTOKOLL_O beschreibt?

Das ist momentan der einzige Widerspruch, den ich sehe (wenn ich nichts übersehen habe). Ansonsten passen die Ergebnisse sowohl zu Deiner (Xel66) Theorie, als auch zu der anderen. Lediglich die Definitionen von "Ausgeführt" usw. sind in den 2 Lagern ja unterschiedlich. Nach der anderen Theorie hätte auch keiner mit anderen Ergebnissen gerechnet, außer die von mir oben genannte Seltsamkeit.

Gruß Sammy

[Black]

aus diesem Grunde, um Querschlüsse da auszuschliessen, habe ich in meinem Test über .SYSLOG direkt in das "richtige" Systemprotokoll der CCU geschrieben.

nicht das Protokoll der Rega, das hat die ein oder andere Macke, wenns um Strings geht, wurde auch schon mal gezeigt.

Black

[Xel66]

Warum taucht im Protokoll kein "TESTBOOT_mit _Sonst - dann-Zweig" auf?

Ich vermute Race Condition mit zwei WAHRen Prüfungen und zeitgleichem Zugriff auf die Systemvariable. Ich werde das mal mit Blacks Methode nachtesten. An Hand des Screenshots der Zeitstempel sieht man ja, dass dort eine Bedingungsprüfung gelaufen ist. Somit müsste entweder der eine oder der andere Inhalt der Systemvariable geloggt werden. Gibt ja nur die beiden Möglichkeiten.

Nach der anderen Theorie hätte auch keiner mit anderen Ergebnissen gerechnet...

Eher nicht, denn nach der vorherrschenden und eben nicht nachzuvollziehenden Meinung müssten dann alle Programme einen Zeitstempel zumindest des Bootzeitpunktes tragen. Und dem ist ja nun nachweislich (nicht nur auf meiner Test-CCU) nicht so.

Gruß Xel66

[Black]

Alle Programme haben bei mir auch nicht einen zeitstempel nach dem Boot... trotzdem wurden diese bearbeitet...

[Xel66]

So, Test gefahren mit dem Programm mit enthaltenen SONST. Das Ergebnis sieht so aus:

Die eingefügte Systemvariable (Mehrfachauswahl FALSCH,DANN,SONST) hat nach dem Reboot den Inhalt "DANN" angenommen. Der String wurde jedoch nicht in die Systemvariable geschrieben. Ist wohl das von Black beschriebene String-Problem. Passend zum Umschalten der Systemvariable findet sich im Systemprotokoll der im Programm hinterlegte Eintrag:

Code: Alles auswählen

Aug  7 17:36:29 homematic-ccu2 daemon.info cuxd[392]: CUX2801001:1 DANN-Zweig des TESTBOOT_mit_SONST-Programms

Alle Programme haben bei mir auch nicht einen zeitstempel nach dem Boot... trotzdem wurden diese bearbeitet...

Logisch, auch in dem Beispielprogramm wurde das Zeitmodul auf Gültigkeit geprüft. Wie auch sonst sollte dessen Gültigkeit durch das System bewertet werden. Trotzdem wurde das Programm nicht durchlaufen (also weder ein DANN noch ein SONST ausgeführt) und darum auch kein Zeitstempel gesetzt. Programme mit z.B. einem Taster als Trigger erhalten auch keinen Zeitstempel.

Gruß Xel66

[Black]

@xel66
kannst du mir mal screenshot von dem Programm mit dem zeitprogeramm schicken wo kein zeitstempel drin ist.

Und da du auch den SDV hast, biite von dem programm einma auflösen in die Rules / Subrules und mit davon auch mal den Screenshoot ...

mir schwant da etwas....

oder probiere mal bitte mit dem SDV folgendes:

dein programm bestand nur aus

also keine subrules da drin ? so wie hier ?

wenn das so war dann geh bitte indein Programm füge mal eine Sonst bedingung hinzu, lösche die wieder und schaue nun nochmal in den SDV.
hast du da nun wie ich im 2. Bild eine leere Subrule ? (Achtung, neu Suchen, das programm hat ne neue ID gekriegt durch das editieren)

und ums spassig zu machen: machst du mal einen neustart und guggst mal ob das programm nun einen zeitstempel hat ?

ich bin mal gespannt.

Ums vorwegzunehmen: bei mir hatte das programm, nachdem die Subrule drin war, einen zeitstempel nach dem boot.
und ums richtig nebelös zu machen

du guggst dir die das programm mit der leeren Sonst bedingung, aber der vorhandenen Subrule im SDV an
dann merkst oder markierst dir die ID der obersten Objectes (name PrgRule, Type Rule).

Wenn eine Subrule übrigens eine etwas zum Ausführen hat ,also was zum Ausführem im SOnst zweig exisitert , erkennst du das an den SD0 bzw dem SingleDestinationObject, was das Ausführende beschreibt

Hier Blau markiert


dann im Scripteditor folgende Zeile:

Code: Alles auswählen

object o1= dom.GetObject (IDDesObjetes);
o1.RuleDelSubRule ();  

danach nochmal im SDV das Object angucken

Subrule ist weg

neustart machen.

upss. kein zeitstempel ?


Black