UZSU: Sonnenaufgang mit "Grad" Offset

[Sisamiwe]

Hallo,
ich würde gern meine Rollladen mit der UZSU steuern. Bislang habe ich das einfach mit einem crontab im item gemacht
Dabei lasse ich bspw. die Rollladen 8 Winkelminuten vor Sonnenaufgang fahren. (sunrise-8)

Läßt sich dies auch mit dem UZSU Plugin umsetzen?
In der Doku habe ich dazu nichts gefunden.

Danke.

[smai]

Unterdessen habe ich mir das
Funktioniert das mit der Sonne in UZSU überhaupt richtig?
Auf Zeile 210 des Plugins scheint es einen Fehler zu haben, da müsste meines Erachtens ein _ vor sun stehen.

Vielleicht können 2ndsky oder auch Orion etwas dazu sagen?

[ratzi82]

Läßt sich dies auch mit dem UZSU Plugin umsetzen?

Ich kann eine Bestätigung für sunrise-6 bzw. sunset-6 geben, das nutze ich über das UZSU Plugin schon ziemlich lange für die Steuerung meiner Rollos.
Für das UZSU Widget benutze ich eine alte Version von Orion und da funktioniert das im Experten-Modus.

Gruß,
Henning

[Orion]

Hi,

das mit _sun würde ich auch so sehen (auch wenn ich das Plugin nicht geschrieben habe). Im Widget ist der Parameteraufruf unterstützt, aber nur im Modus Minuten. Das Plugin unterstützt (nach Theorie) sowohl Winkelgrad als auch Zeit in Minuten, im Widget hatte ich nur Minuten umgesetzt.

Grüsse

Michel

[smai]

ratzi82 du nutzt wohl -6m, wenn Orion ja selbst sagt, dass er due Grad nicht implementiert hat.
Ich bin aber daran, dies umzusetzen. Sollte nicht weiter schwierig sein.

Orion weisst du, ob dies auch vin FHEM in der gleichen Art unterstützt wird?

[ratzi82]

du nutzt wohl -6m, wenn Orion ja selbst sagt, dass er due Grad nicht implementiert hat.

Nein ich nutze nicht Minuten sondern Winkelgrad, allerdings im Experten Modus des Widgets.

Siehe screenshot:

UZSU-screenshot.png

Gruß,
Henning

[smai]

Ok, dann wusste wohl Orion selbst nicht mehr, dass dies einmal möglich war.
In der neusten Version, die ich als Vorlage genommen hatte, war auch der Expertenmodus bereits mit einzelnen Auswahlfeldern und nicht als einfaches input.

[Orion]

...
Stimmt, da war mal was. Ich hatte das widget so gebaut, dass man den Formatstring ohne Unterstützung einfach eingeben kann. Der wurde dann ohne Prüfung einfach durchgeschoben. War allerdings sehr fehlerträchtig, weil keine Formatprüfung und das Plugin reagiert auf falsche Format manchmal sehr unkontrolliert (sieht keinen Fehler, tut aber nicht). Daher ist das wieder herausgeflogen -> zu viele Supportanfragen wegen Fehlern und auch keine Kompatibilität zu FHEM.
...

[Orion]

...
FHEM nutzt eine andere Art, die struct Daten (im RRULE format) zu verarbeiten. Da kommt man mit dem Eingabestring gar nicht weiter. Das Interface, das Bernd Gewehr seitens FHEM implementiert hat nutzt einen JSON Konstrukt zur Übergabe, welches aus dem Struct gebildet wird. Mit ihm hatte ich ein paar Erweiterungen eingebaut, die das Plugin auf der smarthomeNG Seite nicht auswertet, aber im struct enthalten sind. So gibt es "holidays" und ein paar dinge mehr, weil FHEM z.B. ein Funktion zur Feiertags Anzeige hat (und da wird u.U. anders geschaltet).
...

Hier mal ein paar Hinweise (einfach mal bei Github in die issues reinschauen: https://github.com/mworion/uzsu_widget/issues/34)

[smai]

Also versteh ich das richtig: FHEM nutzt nur die timeMin, timeMax und timeOffset? Da gibt es also keine Möglichkeit für Grad offset.
Bei SHNG habe ich bereits gesehen, da wird nur das zusammengesetzte time beachtet.

[Orion]

Sorry nicht korrekt ausgedrückt. Für smarthome muss ich beim Laden immer den RRULE String parsen und anschließend zusammensetzen, FHEM nutzt direct ein Struct dafür. Dies hat mehr Optionen als smarthomeNG. Da gibt es weekday, weekend, conditioned execute etc. hab’s nicht mehr im Kopf, ist aber die issues und die Doku in den Kommentaren des Widgets beschrieben.

Michel

[smai]

Ok, ich habe oben zu sehr gekürzt, es nutzt natürlich nicht ausschliesslich die erwähnten Felder.
Aber es nutzt nicht das zusammengesetzte time, in dem sowas steht wie "18:00<sunset+6m<20:00". Sondern es kennt { timeCron: "sunset", timeOffset: 6, timeMin: "18:00", timeMax : "20:00" }

Worauf ich eigentlich hinaus will: Kennt dies UZSU in FHEM eine Möglichkeit, den Offset in Grad zu setzen?

[Orion]

Ich glaube nicht. kenne mich aber nicht genau aus. Was ich von Bernd verstanden habe gibt es ein Adapter Script (in perl, wie FHEM geschrieben ist), welches die Informationen aus dem JSON struct umbaut und in die schaltuhr Logik des FHEM einbaut. Dort müsste ja eine Umrechnung erfolgen.

Aber er mal ganz anders: eigentlich ist es eine ganz einfache Umrechnung. 24h sind 360 Grad. Warum man zusätzlich zu Minuten auch noch Grad benötigt ist aus meiner Sicht dem Komfort geschuldet. Um die Kompatibilität nicht zu verletzen, würde ich - wenn es überhaupt notwendig ist - die Umrechnung im Widget machen aber nur Minuten speichern. Sonst hat man redundante Daten, die das gleiche beschreiben. Macht eigentlich kein Sinn.

Michel

[smai]

Danke für deine Infos.

Aber er mal ganz anders: eigentlich ist es eine ganz einfache Umrechnung. 24h sind 360 Grad. Warum man zusätzlich zu Minuten auch noch Grad benötigt ist aus meiner Sicht dem Komfort geschuldet.

Das hatte ich im ersten Moment auch gedacht, aber leider stimmt es nicht.
Die Verschiebung bezieht sich nicht auf die Himmelsrichtung sondern auf die Höhe über bzw. unter dem Horizont (Elevation). Diese hängt von Position und Tag im Jahr ab.

Ich habe nun einfach eine zusätzliche Auswahl gemacht, die nur bei SmartHomeNG erscheint. Das sieht dann so aus:
uzsu.png

[Orion]

Jepp, du hast recht. Dein Vorschlag ist klasse. Richtigerweise wird das ganze ja mit dem ephem Paket berechnet. Das hatte in Vergangenheit aber schon ab und zu in der Berechnung im Plugin zu Fehlern geführt. Gerade wenn es mehrere schaltuhren mit sun Einstellung gab. Würde nie wirklich aufgelöst, ist aber im Moment relativ ruhig dazu. Meine Vermutung ist, dass bei einer massenhaften Berechnung der Zeiten über ephem das Problem auftaucht, dass das Paket evt. Nicht Thread safe ist oder mit reentranz ein Problem hat.

michel