Probleme mit dem Triggern von Web-UI Scripten

[RaHe67]

Hallo,

ich bekomme die Steurung meiner Jalousie über das Astro-Script einfach nicht hin und benötige Hilfe von Experten.
Z.B. das Runterfahren 45 Min nach Sonnenuntergang (mit Zeiteingrenzung)

Bitte beachten bei mir ist der Jalousie Motor verdreht angeschlossen, somit Behanghöhe 100% Jalousie geschlossen.

Das Programm habe ich unten angehängt und ich habe Variablen zur Diagnose (in den Scripten) hinzugefügt um das Anstossen der Wenn-Dann-Sonst Zweige zu beobachten.

Script Dann Zweig:

Code: Alles auswählen

var zeitStempel= dom.GetObject("Tageszeit_hh.mm").State();
dom.GetObject("Runter_Triggered").State(zeitStempel)

Script Sonst Zweig

Code: Alles auswählen

var zeitStempel= dom.GetObject("Tageszeit_hh.mm").State();
dom.GetObject("Runter_Triggered2").State(zeitStempel)

Was ich beobachte ist:
Das Programm wurde bei mir z.B heute nur getriggert (mit Ablauf des Sonst-Zweiges) als es die Aktualisierung "Minuten_vor_SU" < -45 Minuten gab.
Angezeigt durch "Runter_Triggered2" = 16.42

Um 18.30 Tageszeit_hh.mm hätte ich aber eine Aktualisierung erwartet, die effektiv im Wenn-Zweig landet, da alle weiteren Bedingungen erfüllt sind.
(ein Programm-Aufruf müsste meiner Meinung nach durch die Bedingung "Tageszeit_hh.mm im Wertebereich größer als 18.30 bei Akualisierung auslösen" getriggert werden).

Es wurde aber weder Wenn noch Sonst-Zweig abgearbeitet wie man in den Screenshots erkennen kann.

Ich bin leider ratlos Ich bekomme das Scripting einfach nicht zuverlässig hin.

Folgendes habe ich bereits (mehrfach) probiert - entsprechend den Hinweisen die ich hier an verschiedenen Stellen gefunden habe:

-Neustart des Raspi
-Neuanlegen der Programme
-Aufteilen einesWenn Dann Sonst Programmes in zwei Wenn-Dann (für Jalousie Rauf und Runter). Hier existiert der Sonst Zweig nur um die Systemvariable zu schreiben, um den Sonst Durchlauf anzuzeigen
-Raspberrymatic Update auf Version RaspberryMatic 2.29.23.20171118 von Vorgängerversion
-Löschen von leeren Bedingungen, die ich ursprünglich mal hatte.

Habe ich was übersehen, einen Denkfehler oder was kann ich tun?

Gruß Ralf

[RaHe67]

Hallo,

nach weiterer Beobachtung:

Die Systemvariablen tageszeit_hh.mm und Minuten_vor_SU werden wie erwartet im 3 min Takt neu berechnet, und haben die erwarteten Werte.

Allerdings ist der letzte Aufruf heute um tageszeit-hh.mm 16.42, und zwar im Sonst Zweig (wir haben gerade 19:55).
D.h. die Änderung von "Minuten_vor_SU" im Wertebereich kleiner als -45.00 (bei Änderung) hat passend ausgelöst (die Zeit müsste stimmen).
Was nicht ausgelöst hat (es gab keine Aktualisierung meiner Testvariablen mehr) ist offensichtlich "tageszeit_hh.mm > größer als 18.30" auf aktualisieren.
Zu dieser Zeit hätte ich zumindest einen Aufruf erwartet.
Btw, das Gegenstück für Jalousie_rauf triggert auch auf tageszeit_hh.mm, nur mit einer anderen Bedinung / Zeit.

Hat irgendwer eine Idee? Ist das Vorgehen falsch / ungeschickt?

Gruß Ralf

[RaHe67]

Da ich das Thema doch für mich geklärt haben möchte, pushe ich das ganze weiter

Habe meine Programme mittlerweile umgestellt auf "Auslösen bei Aktualisierung" auf "Tagestszeit_hh.mm"
Alle anderen Variablen werden nur geprüft. Damit geht alles.
Genauso könnte ich das Astro-Skript so umstellen, dass die zusätzlichen Zeitbedingungen dort abgearbeitet werden.

Trotzdem, mir fehlt das Verständnis für die Trigger "bei Änderung" im WebUI und ich möchte eigentlich die Auslösung des Programmes so weit wie möglich minimieren.

Es scheint so zu sein, das diese Trigger nicht immer zuverlässig kommen. Kennt jemand Probleme mit mehrfach verwendeten "Änderungs"-Triggern? Ich bekomme zwar eine Menge Infos hier in dem Forum, aber konkrete Hinweise darauf habe ich nicht gefunden.

Ich benutze in dem WebUI Beispiel oben ja zwei verschiedene "Änderungs-Trigger" auf "Tagszeit_hh.mm". Die scheinen momentan bei mir nie auszulösen.
Der einzige "Änderungs-Trigger" der funktioniert ist der auf "Minuten_vor_SU".
Gibt es evt. Beschränkungen auf einen "Änderungs-Trigger"?

Allen einen guten Rutsch und ein frohes neues Jahr.

Ralf

[manfredh]

Ohne jetzt deine Beschreibungen und Programm(e) näher anzusehen (dazu gleich mehr):

Das Triggern auf Änderung startet ein Programm nur, wenn explizit die definierte Änderung stattfindet. Also z.B. wenn die SV Minuten_vor_SU von -46 auf -45 oder zurück springt. Deren Wahrheitsgehalt wird jedoch bei jedem Programmlauf geprüft.

Nun zu meinem "dazu gleich mehr":
Ich habe deinen Eingangspost wohl gesehen. Es gab aber drei Dinge, die mich gleich auf "weiter" klicken haben lassen:

- Warum bist du nicht willens / in der Lage, den falsch angeschlossenen Rollladenaktor richtig anzuklemmen? Der Gedanke, der da aufblitzt: "Wenn einer schon dazu nicht in der Lage ist..."

- Warum in aller Welt muss man die Uhrzeit in einer Systemvariablen abbilden, die auch noch im 3-Sekundentakt aktualisiert wird?

- Kann man einen solch (unnötigerweise) komplexen Zusammenhang nicht einfach mal auf einen einfachen Status zusammendampfen und ihn dann (wenn er funktioniert) Stück für Strück auf die gewünschte Größe aufblasen? Einfach um festzustellen, in welcher Phase / bei hinzufügen welchen Details die Fehlfunktion auftritt.

So entsteht der (möglicherweise falsche) Eindruck, dass jemand etwas hochkomplexes zusammengestrickt hat, ohne sich vorher mit den Basics zu befassen.

Gruß
Manfred

[RaHe67]

Manfredh erstmal Danke für Deine Antwort. Vielleicht bringt mich das ja näher an das eigentliche Problem.

Zu Deinen Anmerkungen:

Das Triggern auf Änderung startet ein Programm nur, wenn explizit die definierte Änderung stattfindet. Also z.B. wenn die SV Minuten_vor_SU von -46 auf -45 oder zurück springt. Deren Wahrheitsgehalt wird jedoch bei jedem Programmlauf geprüft.

Das ist mir durchaus bewusst. Das war genau der Sinn der Übung um nur zu dedizierten Zeitpunkten einen Trigger zu bekommen, nämlich genau dann, wie Du es beschrieben hast. Für Minuten_vor_SU funktioniert das auch wie ich beschrieben habe, für tageszeit_mm.hh merkwürdigerweise nicht.

Warum bist du nicht willens / in der Lage, den falsch angeschlossenen Rollladenaktor richtig anzuklemmen? Der Gedanke, der da aufblitzt: "Wenn einer schon dazu nicht in der Lage ist..."

Kann ich dir Erklären: Der Rolladenmotor ist verdreht (rauf/runter) angeschlossen, und der Aktor in der Dose Übertapeziert - so dass ich die Korrektur lieber in der Software mache bevor ich das wieder aufreiße. Da habe ich aber in der Eingangsmail drauf hingewiesen ...

- Kann man einen solch (unnötigerweise) komplexen Zusammenhang nicht einfach mal auf einen einfachen Status zusammendampfen und ihn dann (wenn er funktioniert) Stück für Strück auf die gewünschte Größe aufblasen? Einfach um festzustellen, in welcher Phase / bei hinzufügen welchen Details die Fehlfunktion auftritt.

Ich gebe zu den Sachverhalt hier zu beschreiben ist nicht ganz einfach bzw. Übersichtlich. Aber zum einen funktioniert es, sobald ich nur einen ganz einfache Programmierung wähle (mit einer Variablen), die bietet mir aber nicht die Funktionalität, die ich wünsche. Zum anderen ist ein Teil des Programmes nur zur Diagnose eingefügt, um das Problem weiter einzugrenzen und auch zu dokumentieren (Zeitstempel Runter_Triggered, Runter_Triggered2).
Die Zusatzprüfung auf SU_Triggered ist entstanden um das Klicken des Relais bei doppelter Aktivierung zu unterbinden (und wird um Mitternacht zurückgesetzt).

- Warum in aller Welt muss man die Uhrzeit in einer Systemvariablen abbilden, die auch noch im 3-Sekundentakt aktualisiert wird?

Das Astro-Skript welches bei mir im Hintergrund läuft (und die Uhrzeit berechnet) wird bei mir alle 3 Minunten angestossen - nicht alle 3 Sekunden. Das stellt kein Problem dar oder?

So entsteht der (möglicherweise falsche) Eindruck, dass jemand etwas hochkomplexes zusammengestrickt hat, ohne sich vorher mit den Basics zu befassen.

Ich kann Dir versichern, dass ich mich mit den "Basics" hier schon recht lange befasse. Das schliesst aber nicht aus, dass ich eventuell etwas Grundlegendes übersehen habe.

Edit: Mein Wissen - kann ich Dir versichern -ist mehr als ausreichend sowohl für die Verdrahtung als auch für die Programmierung der Homematic Komponenten - zumindest theoretisch. Und "hochkomplex" würde ich das hier auch nicht gerade bezeichnen - ich sehe das hier eigentlich als noch recht einfachen Anwendungsfall.

Gruß Ralf

[manfredh]

- Warum in aller Welt muss man die Uhrzeit in einer Systemvariablen abbilden, die auch noch im 3-Sekundentakt aktualisiert wird?

Das Astro-Skript welches bei mir im Hintergrund läuft (und die Uhrzeit berechnet) wird bei mir alle 3 Minunten angestossen - nicht alle 3 Sekunden. Das stellt kein Problem dar oder?

Du hast nur den Nebensatz und nicht die eigentliche Frage beantwortet.

Zusatzfrage: wozu muss man eine Uhrzeit berechnen? Eine Uhrzeit ist, auch ohne Script.

[RaHe67]

Hallo ManfredH,

das Anlegen der SystemVariablen "Tageszeit_hh.mm" stammt aus dem

"Universellen Astroskript"
https://www.stall.biz/project/universel ... den-lampen

welches ich als Ausgangsbasis verwendet habe. Auf dieses wird aus diesem Forum aus jeder Ecke verwiesen, so dass
ich es für eine gute Idee gehalten habe, um auf dieser Basis mich in den doch etwas speziellen Homematic Script Syntax einzuarbeiten.

Es wird ja offensichtlich erfolgreich eingesetzt.
Es handelt sich auch nur um eine zusätztliche Systemvariable welche die aktuell (aus dem System ermittelte Zeit) als Zahl - also in einem anderen Format - darstellt.

Code: Alles auswählen

c_zeit = (1.0*system.Date("%H").ToInteger()) +(0.01*system.Date("%M").ToInteger());                      
dom.GetObject("Tageszeit_hh.mm").State(c_zeit);

Da sich andere Systemvariablen (wie z.B. Minuten_vor_SU und Minuten_vor_SA) auch an der Tageszeit orientieren, muss das Script häufig aufgerufen werden (alle 3 Min entsprechend der Vorlage scheint mir da ein gangbarer Weg).

Eine zusätzliche Variable tageszeit_hh.mm ist da wohl kein relevanter Overhead.

Mit dem Script gibt es auch keine Problem, die enthaltenen Variablen werden auch sauber 3-Minütig neu geschrieben.
Das Problem besteht beim Triggern des Programmes, welches nicht so geschieht wie ich mir das vorstelle.

Wie ich weiter oben beschrieben hatte:

Allerdings ist der letzte Aufruf heute um tageszeit-hh.mm 16.42, und zwar im Sonst Zweig (wir haben gerade 19:55).

kann die letzte Triggerung eigentlich nur durch Minuten_vor_SU ausgelöst worden sein, da keine Aufrufe danach weder im 'Wenn'- noch im 'Sonst'-Zweig erfolgt sind (durch das Schreiben der Diagnosevariablen Runter_Triggered und Runter_Triggered2 nachgewiesen).

Edit: Änderungen der Tageszeit_hh.mm hätten aber aufgrund des Wenn-Zweigs bereits zu dieser Uhrzeit auslösen müssen ....

Ralf

[manfredh]

Sorry, wenn ich das jetzt möglicherweise auf eine Grundsatzdiskussion zum Thema
"Muss man alles, was man steuert, hochkomplex angehen? Was bringt es, wenn z.B. das abendliche Herunterfahren der Rollladen sekundengenau in Abhängigkeit von Elevation, Azimut und sonstigem Gedöns macht?" führe.

Konkret:
Ich habe auch ein Tageszeitenscript laufen. Nämlich dieses.
Es Verändert mir genau eine (!) Systemvariable, indem es den Tag - abhängig von Sonnenauf- und Untergang sowie einigen festen Uhrzeiten - in Abschnitte unterteilt. Durch weitere Systemvariablen ließen sich dann noch Zwischenschritte schaffen, z.B. "30 Minuten nach Beginn der Abend-Dämmerung".
Das reicht mMn zum Steuern von Rollläden in Abhängigkeit von Sonnenauf- und Untergang.

Und warum man eine Systemvariable, die die Uhrzeit abbildet zur Zeitsteuerung benutzt, obwohl in der CCU eine vernünftige Zeitsteuerung enthalten ist, erschließt sich mir immer noch nicht. Das war eigentlich meine Frage, die ich hier mal anders formuliert habe.

Langer Rede kurzer Sinn:
Kämst du nicht mit einfacheren Mitteln zum gleichen Ziel, also
- Verwendung des oben erwähnten einfacheren Scripts, ggfls. mit einer zusätzlichen SV, um die 45 Minuten vor SU abzubilden,
- Verwendung der Systeminternen Zeitsteuerung?

Gruß
Manfred

[RaHe67]

Hallo Manfred,
Danke, das verlinkte Script kenne ich tatsächlich noch nicht.
Der Einwand ist durchaus berechtigt, dass mein verwendetes Astro-Script eventuell einen overkill darstellt. Zumal ich es auch bis jetzt gar nicht voll ausnutze und wirklich nur zur Sonnenuntergangs / Aufgangszeit Bestimmung nutze.

Allerdings erschliesst sich mir momentan der Bezug zu meinem aktuellen Problem mit den Triggern nicht.

Oder gibt es tatsächlich Probleme mit der Triggerung bei hohe Systemauslastung (in Form von zu häufigem zyklischem Ablauf bzw. verwendung zu vieler SystemVariablen)?
Ich benutze nur dieses Astro-Skript + HM-Detect und habe ungefähr 20 Systemvariablen. Zyklus alle 3 Min.
Ich mag mich (als unerfahrener Homematic Nutzer) täuschen, aber diese Gefahr sehe ich hier auf einer CCU oder auf einem Raspi wie bei mir nicht.

Workarounds fallen mir einige ein, und Deine Variante könnte eine davon sein. Ich möchte aber eigentlich genauer Wissen, woher das Problem kommt und etwas lernen. Nicht rumprobieren bis es geht.
Habe ich die Triggerung verkehrt verstanden (oder wie die CCU Programme abarbeitet), benutze ich das ganze ungeschickt oder handelt es sich eher um einen Bug in der CCU Software?

Wie sind die Erfahrungen von anderen?

Ralf

[Homoran]

Ich arbeite mit Eugens skript und zwar weil:

Was bringt es, wenn z.B. das abendliche Herunterfahren der Rollladen sekundengenau in Abhängigkeit von Elevation, Azimut und sonstigem Gedöns macht

hier NICHTS!
Aber, wenn es um die Beschattung geht und die Sommerzeit bei der Berechnung nicht mit in Betracht gezogen werden soll ist der Azimut schon eine wichtige Hilfe, wenn ich wissen will ob bei einer gewissen Hitzeeinstrahlung die Sonne überhaupt noch in die Fenster scheint.

Das gleiche gilt für einige anderen Funktionen, wenn ich in Abhängigkeit von Höhe über dem Horizont triggern will kann ich über den Azimut gleichzeitig wissen ob die Sonne gerade aufgeht oder uuntergeht.

Bei der Beschattung kann ich (oder das Programm) entscheiden (Jahreszeitenabhängig) ob die Sonne hoch genug steht, dass die Markise einen Schutz bietet, oder die Sonne so tief steht, dass die Sonne darunter in die Fenster scheint und doch die Rolläden runter müssten.....


Gruß
Rainer