HM-Skript zur einfachen Sonnenstandsberechnung Script

Problemlösungen und Hinweise von allgemeinem Interesse zur Haussteuerung mit HomeMatic

Moderator: Co-Administratoren

Matsch
Beiträge: 5359
Registriert: 30.05.2019, 11:37
System: Alternative CCU (auf Basis OCCU)
Wohnort: Chemnitz
Hat sich bedankt: 113 Mal
Danksagung erhalten: 722 Mal

Re: 0 > 270?

Beitrag von Matsch » 01.06.2021, 17:30

thfrank hat geschrieben:
01.06.2021, 15:59
Führt denn die Helligkeit (konkret <3000 Lux) auch zur DANN-Aktivität, wenn sie keine Änderung erfahren hat?
Bitte nochmal die Tipps zur Logik der WebUI durchlesen! Egal, aus welcher WENN-Bedingung ein Trigger erfolgt, das Programm wird immer von ganz oben nach unten abgearbeitet und bei der ersten gefundenen wahren WENN-Bedingung das DANN ausgeführt - egal, aus welcher Zeile der Trigger kam.

Daher ja auch die Empfehlung, in kleine Programme zu splitten, große sind oft bezüglich ihrer Wirkung kaum noch zu überschauen.

thfrank
Beiträge: 248
Registriert: 16.05.2020, 12:54
System: CCU
Hat sich bedankt: 48 Mal
Danksagung erhalten: 1 Mal

Re: HM-Skript zur einfachen Sonnenstandsberechnung Script

Beitrag von thfrank » 01.06.2021, 19:57

Baxxy hat geschrieben:
01.06.2021, 17:09
Und zumindest die Helligkeit < 3000 ist um 00:00 vermutlich immer gegeben.
ja, die ist ziemlich genau 0 :mrgreen:

Xel66
Beiträge: 14086
Registriert: 08.05.2013, 23:33
System: Alternative CCU (auf Basis OCCU)
Wohnort: Nordwürttemberg
Hat sich bedankt: 581 Mal
Danksagung erhalten: 1492 Mal

Re: 0 > 270?

Beitrag von Xel66 » 01.06.2021, 21:05

thfrank hat geschrieben:
01.06.2021, 15:59
...(werd nie verstehen, warum eine Änderung immer in beide und nicht nur in die gewünschte Richtung registriert wird, aber gut).
Die Prüfung "bei Änderung" ist wohl Bestandteil der Prüfung im Programm und wird nicht im Vorfeld gecheckt. Das System meldet an das Programm, dass einer der Trigger eine Änderung erfahren hat. Die Bedingungsprüfung des Programms überprüft dann, ob sich der Wert des Triggers in einer in den betreffenden Parametern im Programm hinterlegten Weise geändert hat (naheliegend durch Vergleich mit LastValue()). Ist dieses der Fall, wird eine weitere Prüfung der verknüpften Bedingungen des Programms angestoßen und in Abhängigkeit von deren Ergebnis ein DANN ausgeführt oder eben auch nicht. Bei letztere Bedingungsprüfung wird der Zeitstempel aktualisiert, auch wenn weder ein DANN oder SONST ausgeführt wurde. Durch ungeschickte Wahl der Trigger eines Progamms kann ein Parmeter, der auf "bei Änderung" steht, auch wie "bei Aktualisierung" wirken. Im Gegensatz zu erster beschriebenen Bedingungsprüfung ist dieses wirklich ein schwer zu ermittelndes Verhalten.

Gruß Xel66
-------------------------------------------------------------------------------------------
524 Kanäle in 146 Geräten und 267 CUxD-Kanäle in 34 CUxD-Geräten:
343 Programme, 334 Systemvariablen und 183 Direktverknüpfungen,
RaspberryMatic Version: 3.65.11.20221005 + Testsystem: CCU2 2.61.7
-------------------------------------------------------------------------------------------
Einsteigerthread, Programmlogik-Thread, WebUI-Handbuch

thfrank
Beiträge: 248
Registriert: 16.05.2020, 12:54
System: CCU
Hat sich bedankt: 48 Mal
Danksagung erhalten: 1 Mal

Re: 0 > 270?

Beitrag von thfrank » 01.06.2021, 21:39

Xel66 hat geschrieben:
01.06.2021, 21:05
Die Bedingungsprüfung des Programms überprüft dann, ob sich der Wert des Triggers in einer in den betreffenden Parametern im Programm hinterlegten Weise geändert hat (naheliegend durch Vergleich mit LastValue()).
aber das ist doch offenbar gerade nicht so, oder? In meinem konkreten Programm ist die Abfrage Azimut >= 280°. 0° ist nun definitiv nicht größer als 280°, es hat sich lediglich eine Änderung ergeben (und zwar entgegen der im Programm hinterlegten Abfrage, Azimut ist jetzt kleiner als 280°)
Xel66 hat geschrieben:
01.06.2021, 21:05
Bei letztere Bedingungsprüfung wird der Zeitstempel aktualisiert, auch wenn weder ein DANN oder SONST ausgeführt wurde.
Was bedeutet der Zeitstempel?
Xel66 hat geschrieben:
01.06.2021, 21:05
Durch ungeschickte Wahl der Trigger eines Progamms kann ein Parmeter, der auf "bei Änderung" steht, auch wie "bei Aktualisierung" wirken.
was wäre denn an dieser Stelle eine geschickte(re) Wahl des Triggers, die eine "bei Aktualisierung"-Funktion vermeiden würde?

Thomas

MichaelN
Beiträge: 9562
Registriert: 27.04.2020, 10:34
System: CCU
Hat sich bedankt: 696 Mal
Danksagung erhalten: 1608 Mal

Re: HM-Skript zur einfachen Sonnenstandsberechnung Script

Beitrag von MichaelN » 01.06.2021, 21:44

Jedes "oder" Konstrukt in ein eigenes Programm packen.
LG, Michael.

Wenn du eine App zur Bedienung brauchst, dann hast du kein Smarthome.

Wettervorhersage über AccuWeather oder OpenWeatherMap+++ Rollladensteuerung 2.0 +++ JSON-API-Ausgaben auswerten +++ undokumentierte Skript-Befehle und Debugging-Tipps +++

Xel66
Beiträge: 14086
Registriert: 08.05.2013, 23:33
System: Alternative CCU (auf Basis OCCU)
Wohnort: Nordwürttemberg
Hat sich bedankt: 581 Mal
Danksagung erhalten: 1492 Mal

Re: 0 > 270?

Beitrag von Xel66 » 01.06.2021, 22:00

thfrank hat geschrieben:
01.06.2021, 21:39
aber das ist doch offenbar gerade nicht so, oder? In meinem konkreten Programm ist die Abfrage Azimut >= 280°. 0° ist nun definitiv nicht größer als 280°, es hat sich lediglich eine Änderung ergeben (und zwar entgegen der im Programm hinterlegten Abfrage, Azimut ist jetzt kleiner als 280°)
Ich habe vor "ewigen" Zeiten mit einer Test-CCU diverse Analysen gemacht und verschiedenste Trigger und Programmverknüpfungen durchgespielt. Und dort hat sich dieses Verhalten gezeigt. Was sich aber dort geändert hat, dass die Bedingung >280° beim Sprung auf 0° definitiv über den angelegten Grenzwert gesprungen ist. Und dieses wird eben durch die Programmroutine geprüft.

Ungünstige Konstellationen sind zum Beispiel die mehrfache Verwendung des gleichen Triggers innerhalb eines Programms (verUNDete oder verODERte Bedingung oder in einem SONST WENN). Sowas kann Dir vorzüglich ein Bein stellen und das Programm verhält sich "merkwürdig". Daher ist es ein guter Ratschlag, anstatt Monsterprogramme mit vielen Bedingungen oder SONST WENN lieber separate Programme mit schlankerer Struktur anzulegen. So bleibt das Programmverhalten vorhersagbar.

Gruß Xel66
-------------------------------------------------------------------------------------------
524 Kanäle in 146 Geräten und 267 CUxD-Kanäle in 34 CUxD-Geräten:
343 Programme, 334 Systemvariablen und 183 Direktverknüpfungen,
RaspberryMatic Version: 3.65.11.20221005 + Testsystem: CCU2 2.61.7
-------------------------------------------------------------------------------------------
Einsteigerthread, Programmlogik-Thread, WebUI-Handbuch

Benutzeravatar
Baxxy
Beiträge: 10648
Registriert: 18.12.2018, 15:45
System: Alternative CCU (auf Basis OCCU)
Hat sich bedankt: 597 Mal
Danksagung erhalten: 2180 Mal

Re: HM-Skript zur einfachen Sonnenstandsberechnung Script

Beitrag von Baxxy » 01.06.2021, 22:24

Ich weiß nicht ob die CCUx das auch kann...
Mit RaspberryMatic könnte man das Ausführen durch "Sonne_Azimut" 0.0 um 00:00 Uhr unterbinden. Das Programm landet dann im SONST...

Dazu die 3 mittleren ODER-Bedingungen separieren und jeweils wie folgt verUNDen...
Trigger_00_Azimut.JPG
Ist nicht gerade die beste Vorgehensweise, aber als Workaround nutzbar.

Grüße
Baxxy

Matsch
Beiträge: 5359
Registriert: 30.05.2019, 11:37
System: Alternative CCU (auf Basis OCCU)
Wohnort: Chemnitz
Hat sich bedankt: 113 Mal
Danksagung erhalten: 722 Mal

Re: 0 > 270?

Beitrag von Matsch » 01.06.2021, 22:31

thfrank hat geschrieben:
01.06.2021, 21:39
Was bedeutet der Zeitstempel?
Na, er zeigt dir, wann das Programm das letzte Mal aufgerufen wurde, egal, ob dabei irgendeine festgelegte WENN-Bedingung wahr war oder nicht.

Matsch
Beiträge: 5359
Registriert: 30.05.2019, 11:37
System: Alternative CCU (auf Basis OCCU)
Wohnort: Chemnitz
Hat sich bedankt: 113 Mal
Danksagung erhalten: 722 Mal

Re: 0 > 270?

Beitrag von Matsch » 01.06.2021, 22:38

thfrank hat geschrieben:
01.06.2021, 21:39
Xel66 hat geschrieben:
01.06.2021, 21:05
Die Bedingungsprüfung des Programms überprüft dann, ob sich der Wert des Triggers in einer in den betreffenden Parametern im Programm hinterlegten Weise geändert hat (naheliegend durch Vergleich mit LastValue()).
aber das ist doch offenbar gerade nicht so, oder? In meinem konkreten Programm ist die Abfrage Azimut >= 280°. 0° ist nun definitiv nicht größer als 280°, es hat sich lediglich eine Änderung ergeben (und zwar entgegen der im Programm hinterlegten Abfrage, Azimut ist jetzt kleiner als 280°)
Immer noch nicht verstanden?
Wenn der Azimut von 360 auf 0° springt (Mitternacht), wird das Programm getriggert, weil sich die Bedingung ändert und der Azimut nicht mehr >280° ist.
Zwar ist die Bedingung dann falsch und führt auch gar nicht zum Ergebnis "wahr", aber nun werden auch alle anderen WENN-Bedingungen abgeprüft.
Und da ja die Bedingung < 3000 lx wahr ist und verODERt ist, ist auch das Gesamtergebnis wahr.
Nicht der Azimut führt zur Ausführung von DANN, sondern die geringe Helligkeit.

Xel66
Beiträge: 14086
Registriert: 08.05.2013, 23:33
System: Alternative CCU (auf Basis OCCU)
Wohnort: Nordwürttemberg
Hat sich bedankt: 581 Mal
Danksagung erhalten: 1492 Mal

Re: 0 > 270?

Beitrag von Xel66 » 01.06.2021, 22:52

Matsch hat geschrieben:
01.06.2021, 22:38
Nicht der Azimut führt zur Ausführung von DANN, sondern die geringe Helligkeit.
Genau! Der Sprung von 360° auf 0° löst nur eine Bedingungsprüfung aus, und dann passiert das, was ich in meinem Beitrag vom 01.06.2021 um 13:57 Uhr meinte, als ich das Prüfen "von oben nach unten" beschrieb. Die zu diesem Zeitpunkt WAHRe Bedingung (Helligkeit) führt dann zum Ausführen des DANN, unabhängig davon, dass die Bedingungsprüfung in einem ganz anderen Zweig getriggert wurde. Diese Eigenart ist halt der Punkt, der ständig zur Verwirrung führt. Hat man das aber mal gefressen, lassen sich auch die Programmläufe und Trigger nachvollziehen und das Programmverhalten ist vorhersagbar.

Gruß Xel66
-------------------------------------------------------------------------------------------
524 Kanäle in 146 Geräten und 267 CUxD-Kanäle in 34 CUxD-Geräten:
343 Programme, 334 Systemvariablen und 183 Direktverknüpfungen,
RaspberryMatic Version: 3.65.11.20221005 + Testsystem: CCU2 2.61.7
-------------------------------------------------------------------------------------------
Einsteigerthread, Programmlogik-Thread, WebUI-Handbuch

Antworten

Zurück zu „HomeMatic Tipps & Tricks - keine Fragen!“