HM-Skript zur einfachen Sonnenstandsberechnung Script

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

Moderator: Co-Administratoren

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, 22:56

Baxxy hat geschrieben:
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...
Hier gibt es nicht mal ein "ungleich"...

Im Übrigen würde das wahrscheinlich auch nicht viel bringen, solange das Programm mit der Änderung (egal in welche Richtung) getriggert wird. Auch jeder andere Wert ungleich 0 (im konkreten Fall jeder nach 360° erfasste Wert) wird zu diesem Ergebnis führen.

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, 23:10

thfrank hat geschrieben:
01.06.2021, 22:56
Hier gibt es nicht mal ein "ungleich"...
Tja, das ist... Pech. :wink:
thfrank hat geschrieben:
01.06.2021, 22:56
Im Übrigen würde das wahrscheinlich auch nicht viel bringen,
Doch tut es.
Azimut_Protokoll.JPG
Grüße
Baxxy

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, 23:28

Baxxy hat geschrieben:
01.06.2021, 23:10
Doch tut es.
Hast du die SV manuell gesetzt? Wäre ne schnelle Sonne ansonsten :mrgreen:

Wie gesagt, Programm springt bei mir auch bei Azimut 0,9 oder 1,5 oder was auch immer an, eben der erste erfasste Wert nach den 360°.

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, 23:42

thfrank hat geschrieben:
01.06.2021, 23:28
Hast du die SV manuell gesetzt?
Klar, reines Testszenario mit Fast Forward. :mrgreen:
thfrank hat geschrieben:
01.06.2021, 23:28
eben der erste erfasste Wert nach den 360°.
Verstehe. Der Workaround würde auch nur funktionieren wenn der erste vom Script geschriebene Wert exakt 0.0 ist. Dachte das wäre immer der Fall (beim Azimut).
Aber nützt ja nix denn die CCUx das nicht kann. :x

Grüße
Baxxy

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

Re: HM-Skript zur einfachen Sonnenstandsberechnung Script

Beitrag von Xel66 » 01.06.2021, 23:50

Baxxy hat geschrieben:
01.06.2021, 23:42
Der Workaround würde auch nur funktionieren wenn der erste vom Script geschriebene Wert exakt 0.0 ist. Dachte das wäre immer der Fall (beim Azimut).
Nein, ist eher nicht der Fall, da die Berechnung ja zyklisch erfolgt. Dort genau den Wert von 0,000° zu treffen, halte ich für statistisch hinreichend unwahrscheinlich.

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 » 02.06.2021, 00:20

Xel66 hat geschrieben:
01.06.2021, 23:50
statistisch hinreichend unwahrscheinlich
Stimmt natürlich. Ich hatte mich nur am Diagramm auf Eugens Webseite zum Script orientiert ohne das zu prüfen.

Grüße
Baxxy

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 » 02.06.2021, 07:34

Matsch hat geschrieben:
01.06.2021, 22:38
Immer noch nicht verstanden?
[...]
Nicht der Azimut führt zur Ausführung von DANN, sondern die geringe Helligkeit.
ja, das hab ich schon verstanden oder besser gesagt akzeptiert, dass das die Logik der CCU ist. Aber es ging hier ja auch um das Verständnis und die allgemeine (Menschen)Logik...

Meine Abfrage ist vereinfacht wir folgt:

- WENN Azimut > 280 (bei Änderung)
ODER
- WENN Helligkeit < 3000 (bei Änderung)
DANN...
- Markise hoch


Der erwartete Ablauf (ich schätze mal für 99 von 100 Personen ohne CCU) wäre ein Start, wenn der Sonnenstand die 280 über- oder die Helligkeit die 3000 unterschreitet.

Die CCU macht das auch, nur darüber hinaus startet sie auch, wenn die Änderung des Azimuts entgegengesetzt ist und die Helligkeit sich überhaupt nicht verändert hat. Das find ich schon einigermaßen schwer nachzuvollziehen und das ist ja auch der Grund, warum man sich mit verschachtelten Abfragen so schwer tut (wir reden ja gerade mal von einer Logikebene!).

Keine Ahnung, wie andere Smart Home-Anlagen das regeln, aber als Programmierer bei Apple oder Google würde man dafür wahrscheinlich keinen Preis gewinnen...

Vielleicht hat das ganze ja aber auch einen tieferen Sinn, der sich mir noch nicht erschlossen hat.

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 » 02.06.2021, 09:09

Wenn dein Programm nur diesen Teil enthalten würde, würde es auch wie erwartet funktionieren.
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 +++

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 » 02.06.2021, 10:20

thfrank hat geschrieben:
02.06.2021, 07:34
Vielleicht hat das ganze ja aber auch einen tieferen Sinn, der sich mir noch nicht erschlossen hat.
Sinn eher weniger, sondern vermutlich (?) eher Einschränkung der Möglichkeiten durch den Unterbau. Ein solides C++-Projekt würde so wohl eher nicht reagieren.
Ein "normales" ereignisgesteuertes System (z.B. OSEK, AUTOSAR) untersucht die Korrektheit der Triggerbedingung im Systemkern, BEVOR es ein Programm aufruft und nicht erst im Programm selbst. Aber so isses halt - und nicht die einzige kuriose Besonderheit des Systems.

Daher immer wieder: Programme so einfach wie nur möglich halten und splitten, so blöd das auch anmutet.

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

Re: 0 > 270?

Beitrag von Xel66 » 02.06.2021, 13:53

thfrank hat geschrieben:
02.06.2021, 07:34
Die CCU macht das auch, nur darüber hinaus startet sie auch, wenn die Änderung des Azimuts entgegengesetzt ist und die Helligkeit sich überhaupt nicht verändert hat.
Nein tut sie nicht. Die prüft die Bedinungen in der im Handbuch zur WebUI beschriebenen Weise, weil sich der Trigger des Programmes über den definierten Grenzwert geändert hat. Diese Prüfung ist Bestandteil des Programmes. Gibt es dann eben eine andere Bedingung, die ein WAHR ergibt, dann wird das zugehörige DANN ausgeführt. Sicher ist das Verhalten nicht so, wie man es von anderen Steuerungen her kennt, aber es ist dokumentiert und wenn man davon weiß, kann man das auch handhaben. Diese Kernkomponenten wurden wie die gesammte Arbeitsweise der CCU-Firmware ressourcenschonend angelegt, als so einige der Wettbewerbsprotagonisten noch nicht mal ein einziges derartiges Produkt auf dem Markt hatten und ist letztendlich der damaligen Performance einer CCU1 geschuldet.

Im Zuge der Produktpflege (CCU1/2/3) wurde eben Rücksicht auch auf die Abwärtskompatibilität genommen und das ist eben das, was dann mitgeschleift wird. Mit der Rechenpower heutiger Kleinstrechner sind solche Vorgehensweisen nicht mehr notwendig. Ist halt historisch gewachsen. Heutzutage werden Schleifen in Scripts programmiert und die rennen endlos durch, um vielleicht ein, zwei Schaltbefehle am Tag zu generieren (wenn überhaupt). Die CCU-Firmware ist ereignisgetriggert angelegt. Somit müssen nicht ständig die Programme durchrennen und den Prozessor beschäftigen, sondern es wird erst in die Routinen verzweigt, wenn ein entsprechendes Ereignis erkannt wurde. Und viele Ereignisse werden ja nur im Abstand von Minuten angeliefert. Da ist ein solches Vorgehen durchaus zielführend. Dass es heutzutage anders gemacht würde, steht außer Frage.

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!“