HomeMatic-Forum / FHZ-Forum

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.

thfrank hat geschrieben: ↑

01.06.2021, 22:56

Hier gibt es nicht mal ein "ungleich"...

Tja, das ist... Pech.

thfrank hat geschrieben: ↑

01.06.2021, 22:56

Im Übrigen würde das wahrscheinlich auch nicht viel bringen,

Doch tut es. Grüße
Baxxy

Baxxy hat geschrieben: ↑

01.06.2021, 23:10

Doch tut es.

Hast du die SV manuell gesetzt? Wäre ne schnelle Sonne ansonsten

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°.

thfrank hat geschrieben: ↑

01.06.2021, 23:28

Hast du die SV manuell gesetzt?

Klar, reines Testszenario mit Fast Forward.

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.

Grüße
Baxxy

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

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

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

Wenn dein Programm nur diesen Teil enthalten würde, würde es auch wie erwartet funktionieren.

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.

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