[Featurewunsch] Zeitschaltuhr mit Astrofunktion

[saegefisch]

Hallo Christian,

ich hätt' da noch ein Wunsch...
Seit 2 Tagen ziehe ich nun final vom gira HS auf edomi um und bin an meiner zweitletzten Baustelle angelangt: Zeitschaltuhren. Im HS habe ich recht ausgiebig die Astro-Funktion der ZSU genutzt, da ich nur wenig zu festen Zeiten schalte, sondern meist abhängig von der Sonne (Rollläden, energieintensive Verbraucher an der PV,...).
Mit der Forensuche nach "Astro" gab es nicht viel, daher scheint das Thema tatsächlich noch recht frisch. Daher die offene Frage, ob man die ZSU nicht wie folgt erweitern könnte:

• 2 Zusätzliche Eingangs-KOs im Format "HH:MM:SS" für Sonnenaufgang (SA) und Sonnenuntergang (SU).
• Die Quelle der beiden kann man sich beliebig gestalten, z.B. aus einer der vielen Optionen des LBS 19000151 (thx@Michael:grandios!). So kann jeder sich seine am besten passende Astro-Quelle frei wählen.
• In der ZSU je Schaltzeit eine neue Option "Zeit" (wie aktuell, ist ganz wunderbar) oder "Astro"
• Bei "Astro" würde die aus dem neuen KO zu gelieferte Zeit als SA und SU angeboten, zu dem man ein Offset angeben kann in +-hh:mm für die Zeitschaltpunkte. Default ist Offset 00:00. Natürlich auch mit Wahl der Wochentage, Datumsangaben und dynamisch in der Visu nutzbar, sonst wär's ja auch in einem LBS besser aufgehoben.
• Um undefinierte Zustände abzufangen schaltet eine Astro-Schaltzeit nicht, wenn die Eingangs nicht oder nicht formatgetreu versorgt sind.
• Um das Wunschkonzert in die "Zugabe" zu verlängern: Es wäre gut, wenn man optional Abhängigkeiten definieren könnte für "nicht vor xx:xx" oder "nicht nach xx:xx). Damit bekommt man das wirklich beste aus 2 (Zeit-)Welten:
  • Ganz einfach: Die optionale Angabe einer zusätzlichen festen Zeit an einer Astro-Schaltzeit mit Schalter "nicht vor" oder "nicht nach". Einfach, aber nicht ganz konsistent, wenn man mal die Zeit-Schaltzeiten ändern möchte (wäre dann auch in der Astro-Schaltzeit nötig). Ohne Angabe wirkt die Astro-Zeit "pur".
  • Schöner wäre, wenn man einer Astro-Schaltzeit einen anderen bereits definierten Zeitpunkt per "nicht vor" oder "nicht nach" zuordnen könnte. Wenn man nichts zuordnet arbeite jeder Zeitpunkt wie bisher disjunkt.
  • Extremer von Flexibilität und Aufwand wäre, wenn man Schaltzeiten einer zusätzlichen Schaltgruppe (z.B: "morgens", "abends") innerhalb einer ZSU zuordnen und mit Flag in ODER- oder UND-Abhängigkeiten bringen könnte:
    Nur Astro-Zeitpunkt: Astro wirkt.
    Nur Zeit-Zeitpunkt: Zeit wirkt.
    Astro- und Zeit-Schaltzeit per UND: "Astro, aber nie vor 6:30".
    Astro- und Zeit-Schaltzeit per ODER: "Astro, aber nie nach 6:30".
    Eine Schaltgruppe hätte einen Namen hat, den Schalter "UND" oder "ODER" und den KO-Wert für alle Schaltpunkte innerhalb der Schaltgruppe. Für diesen Logik wäre auch eine andere Darstellung denkbar (okay, hier beginnt ein noch größerer Aufwand...). Getrennte Darstellung der Zeitpunkte nach Schaltgruppen.

Natürlich ginge das auch per Logik und LBS irgendwie. Aber es erscheint mir eine sinnvolle Weiterentwicklung, die nicht in eine gesonderte LBS-Lösung sollte, da sonst die Aktionszeiten z.B: eines Rollladen nicht mehr an einer Stelle transparent wäre (ZSU in der Visu). Und wir machen ja gute IT und wollen "die eine Wahrheit"...

Wie immer bin ich gespannt auf Deine Rückmeldung!

Viele Grüße,
Carsten

[gaert]

Alles schön und gut - aber leider muss ich Dich enttäuschen... Die ZSU ist eine ZSU - nicht mehr und nicht weniger. Alles andere muss/kann per Logik erledigt werden - sonst artet das irgendwann aus in Biorythmus, Feiertage, Urlaubstage, Mondphase etc.

[saegefisch]

Genau! Das gute wäre: Mit dieser Lösung kann sich jeder alle seine "Verrücktheiten" generisch abdecken. Wenn man statt "Astro" auch noch die Bezeichnung wählen kann oder es nur "extern" nennt, kann man an die ZSU über die beiden zusätzlichen KO statt an die Sonne auch an den Mond, die Jupiter-Umlaufbahn oder an einen Biorhythmus oder Feiertagskalender hängen (da ja bei einem nicht validen Werte nicht ausgeführt wird). Daher muss das geradezu noch rein.
Weißt Du, welche Abhängigkeit Deines Lebens Dir morgen in den Sinn kommt? Schwupps - Du wärst vorbereitet!


Nachtrag: Spaß beiseite (mit einem Körnchen Wahrheit)...ich würde die "harten Fakten" der Sonnenabhängigkeit im Tagesablauf (immerhin macht sie unseren Tag hell und das Leben möglich) doch etwas anders einordnen, als viele andere Einflussfaktoren, zu denen jeder sicher unterschiedliche Meinungen hat. Daher bleibt das Argument der Transparenz. Wenn ich so "harte Fakten" wie Schaltzeitpunkte in Abhängigkeit vom Lauf der Sonne in einen LBS oder Logik lege, wird ein Aktor irgendwie intransparent in der Visu.

Wenn ich meine Gartenbewässerung vom Mondkalender abhängig machen will, könnte das gleiche Argument gelten (daher: siehe generischer Lösungsvorschlag oben), aber dennoch würde ich das anders, sprich: nicht so wichtig einordnen. Hey...Christian...nur die Sonne noch, dann eigene Visu...

[gaert]

Ich bleibe trotzdem dabei, auch wenn du's sehr Unterhaltsam beschrieben hast. Eine Zeitschaltuhr sollte m.E. die Zeit als Schaltkriterium berücksichtigen (daher der Name). Alles andere wäre keine ZSU, sondern eine Sonnenstandsuhr oder Dämmerungsschalter etc.

[saegefisch]

Schade, schade... aber immerhin...gut gebrüllt hat der Löwe..

Nun: Hilfe.. mir gehen die Argumente aus...

[LynnBayer]

Dann liegt es ja anscheinend nur am Namen Benennen wir das Ganze doch einfach um in Schalten nach bestimmten Kriterien

[gaert]

Auch ne Lösung

Ja nee - bekanntermaßen ist das Grundkonzept von EDOMI der "kleinste gemeinsame Nenner". Es werden also Basis-Features bereitgestellt, die durch Logiken etc. erweitert werden können. Dies erfordert zwar u.U. etwas Hirnschmalz, ist aber am Ende flexibler und vielseitiger. Sonst nähern wir uns am Ende einer "Klick-Klick-Fertig"-Visu (oder Logik), die zwar einfach einzurichten ist aber für jede von der "Norm" abweichende Idee unbrauchbar ist (QC...)

[DerSeppel]

Schade, Astro-Funktionen sind für mich auch ein Killer-Kriterium.
Nutze das für fast alle Rollläden.

Vor allem im Urlaub gut als Anwesenheitssimulation light. Einfach SU+Zufallsoffset.

Klar geht das über LBS. Aber gut wäre es eben, wenn das ganze mit hohem WAF zu bedienen ist.
Die Holde wird wohl kaum den Logik Editor bemühen um den Sonnenuntergangs-Offset für den Rolladen beim Junior anzupassen.

Mal sehen ob man das irgendwie mit den verfügbaren Mitteln ansprechend umgesetzt bekommt.
Wäre aber schön, wenn es zumindest als nieder-priores Feature auf die ToDo Liste käme. Falls dir mal nichts anderes zum Umsetzen einfällt.

[gaert]

Der entsprechende LBS kann bestimmt mit einem KO für den Offset belegt werden - und dieses wiederum per Visu verändert werden

[saegefisch]

Ausblick: Aus - räusper - nun ja, gegebenen Anlass habe ich am WE an einem "virtuellen Rolladen" begonnen zu arbeiten. Etwas unfreiwillig, aber tatsächlich macht das ja auch Spaß. Er wird alle Astro-Möglichkeiten, die mir sinnvoll erscheinen ("nicht vor" nicht nach...", Offset,..) abdecken. Als Input kann man Astro oder sonst etwas wählen - Mond oder was auch immer jemand führend für sein Leben sieht aus irgend einem LBS. Ich hoffe, Ende des kommenden WE einen LBS in V1.0 bereit stellen zu können, spätestens aber in 2 Wochen. Meine Rollläden werden - so mein Plan - ausschließlich über diesen LBS angesteuert und nicht mehr direkt. Als ZSU wird ein eigener Eingang angeboten, um auch künftig den Standard verwenden zu können, der (optionale) Astro-Offset wird selber in eine Visu zu integrieren sein.

Tatsächlich brauche ich jetzt bald eine dauerhaft tragfähige Lösung. Dennoch verbleibe weiterhin in der Hoffnung, dass die ZSU den Begriff der "Zeit" irgendwann einmal weiter fasst, denn was sonst ist die Zeit als die Drehung der Erde und damit auch der sich verändernde Lauf der Sonne über die Jahreszeiten. Warum torkelt unsere Erde dabei nur so durch's All...
Uuuups, war das doch wieder ein - verdammt gutes(!!) - Argument für: ZSU darf auch Astro?... Ein Schelm, der... Hammer-Argumentation, oder?

Sollte die ZSU "die Zeit über das Jahr" irgendwann doch abdecken, kann man den LBS einfach weiter verwenden und nur die Astro-Eingänge brach legen bzw. aus der Visu nehmen. Szenen, Vorrang für Feuer und Einbruch,... bleiben auch damit sinnvoll.

Wichtig: Die Lösung ist ausschließlich für Rollläden von Vorteil - ich habe auch nur solche. Für Lamellen oder Store gibt es augenscheinlich bereits LBS-Lösungen.

Viele Grüße,
Carsten

[panzaeron]

@saegefisch Weil ich gerade im anderen Thread auf meinen 121 LBS hingewiesen habe, vielleicht tut der auch seinen Dienst für dich?

[saegefisch]

@panzaeron: Vielen Dank für Deinen Hinweis. Meine Zielrichtung geht aber in eine andere, wenngleich mir manches an Deinem Baustein auch sehr gut gefällt. Mal schauen, wohin es mich treibt. Und wenn wir später 2 oder mehrere LBS dafür haben, dann ist ganz wunderbar, denn Vielfalt ist ja für alle gut.

Auf jeden Fall entlastet mich Dein Hinweis mit meinem Zeitplan - da ich über die Woche im Hotel bin und daher nur ernsthaft am WE daran arbeiten kann.

[saegefisch]

Hallo Christian,

nach dem auch nach ein paar Tagen des Setzen-lassens mein unfassbar gutes Argument vom 4.10. ("Astro ist auch nur Zeit...") wohl nicht gut genug war ... ...


...arbeite ich nun - zunächst unabhängig von einer dedizierten Rollladensteuerung - an einer generischen Konzept mit LBS für das Astro-Thema mit der vorhandenen ZSU: Daher eine andere Frage zur ZSU: Es wäre hilfreich, wenn man einer zu ZSU statt bisher einem Schalt-KO derer 2 hätte und die am besten mit einem kleinen Tag/Kürzel auch parametrisiert werden könnten. Das 2. KO und die Tags wären natürlich optional, um das bestehende Konstrukt unverändert zu lassen. In der ZSU könnte man das auswählen, ob man Ausgang 1 oder 2 den Wert zum Zeitschaltpunkt ausgeben lassen möchte. Neben bestimmt vielen anderen Möglichkeiten dafür schwebt mir vor:

• in ZSU-Definition: zusätzlich 2. Schalt-KO (optional) und zum beiden ein optionales Textfeld (5-10 Zeichen), belegbar z.B. mit "Fix" und "Astro"
• In der ZSU-Ausführung kann man neben dem Wertfeld dann "Fix" oder "Astro" auswählen. So würde es auch angezeigt werden in den Schaltzeiten. Statt bisher z.B. nur "1" würde da stehen "Fix: 1" oder "Astro: 1", je nach dem,was man wählte. Wenn die Tags nicht gepflegt wurden, wird ein Ersatztext ausgegeben. Wenn kein 2. Schalt-KO angegeben wurde, dann besteht gar keine Wahl zur Ausführungszeit.

Ja, natürlich könnte man auch durch eine Prefix die Werte in der vorhandenen ZSU nutzen und z.B. "0", "100", "Sicht" und "A0", "A100", "ASicht" oder sonst etwas nutzen, aber da eine Wertehilfe nicht möglich ist, ist die Verwendung für meine Frau und auch mich dann eher ein Glücksspiel. Mit der obigen Lösung wäre das viel klarer.

Ja, natürlich könnte man zwei ZSU machen, eine für nach gelagerte Astro-Logik, eine ohne. Aber, naja, was soll ich sagen...

Ich ahne Deine Antwort schon, aber man kann ja mal fragen. Eine Lösung ohne Dein Zutun wird für Astro-Wünsche sonst in jedem Fall nicht so harmonisch sein, aber dann weiß ich, wo ist stehe und was meine Optionen sind und werde schauen, was mir dazu einfällt.

Viele Grüße,
Carsten

[saegefisch]

Da man hier alles selber machen muss und niemand einen erhört...

Mein Vorschlag für eine Astro-basierte Rollladen-Steuerung mit Offset-Funktion, die sehr leicht in einer Visu eingebaut werden kann. Kommt ganz ohne Anpassungen an der ZSU aus und ist in Logik und Visu rasch und ohne viel Aufwand einbaubar. Das war zwar ein ganz schöner Exkurs bis hierhin, aber nun läuft das bei mir seit ein paar Tagen bereits produktiv und gut. Hoher WAF!

Die Darstellung der Rollläden visualisiert nun auch korrekt die Schlitze und Schließungsgrad - mit nur zwei Visu-Elementen und 2 Hintergründen allein mit Webmitteln ohne weitere Logik. Erstaunlicherweise passt die Regel "bei (ca.) 180 ist der Rollladen auf dem Fensterbrett" bei mir bei kleinen Fenstern ebenso wie bei großen Türen. Daher reichte mir tatsächlich ein je Hintergrund für die beiden Elemente für alle Rollläden. Aus den 180 klärt sich der Faktor 1.41 in der Design-Definition: 255/180 = 1.41. Die Werte muss man für sich ggf. anpassen; daher hab eich sie fett markiert.

Hinteres Element kümmert sich um die Schlitze von oben nach unten mit:

-webkit-linear-gradient(top,transparent 0%, transparent {#*[B]1.41[/B]/2.55}%, #4a4b50 {#*[B]1.41[/B]/2.55}%, #4a4b50 100%),
-webkit-repeating-linear-gradient(top,#7896ec 0px, #7896ec 10px, #4a4b50 10px, #4a4b50 12px)

Und: Ja, man darf mehrere gradienten hintereinander nutzen und ist auch ein starkes Mittel, um Logik zu vermeiden und in den Browser zu verlagern.

Das vordere Element "macht dann zu" von unten nach oben:

-webkit-linear-gradient(top,rgba(120,150,236,1) 0%,rgba(120,150,236,1) {(#-[B]180[/B])*3.4/2.55}%, rgba(120,150,236,0.1) {(#-[B]180[/B])*3.4/2.55}%, rgba(120,150,236,0.1) 100%)

@Christian: Erstaunlicher Weise liegen die beiden Element zwar im Visueditor übereinander (von den Werten), aber bereits dort und auch in den Screenshost sieht man einen kleinen Versatz (z.B: bei "Küche"). Hast Du eine Idee, wie ich den weg bekomme? Beispiel: Element1: XPos 204, Ypos 108, Breite 10, Höhe 150 | Element 2 exakt gleich: XPos 204, Ypos 108, Breite 10, Höhe 150.

Übersicht und Pop-up. Auf dem Pop-Up sieht man die Astro-Funktion mit Offsets für meine ersten 5 Rollläden: LBS 19000112 - Visu-Beispiel Rollladen-Steuerung 1.JPG
LBS 19000112 - Visu-Beispiel Rollladen-Steuerung 2.JPG



Die Logik dahinter: Rollladen-Szenen über Vergleicher-LBS 19000118, 2x Offset-LBS 1900117 und Astro-ZSU-LBS 19000112: Die Texte erklären hoffentlich die Zusammenhänge hinreichend. LBS 19000112 - Beispiel Rollladen-Steuerung mit Astro-ZSU und Offset und Szenen.JPG

[saegefisch]

Nachtrag zum Hauptthema: Die Astro-ZSU (zusammen mit dem Offset-LBS) kann natürlich zu beliebigen Zwecken abseits von Rollläden verwendet werden (z.B: Eigenverbrauchsoptimierung von Verbrauchern an PV-Anlage). Damit fahre ich meine Warmwasser-Wärmpumpe ganz ohne ZSU, sondern nur mit dem Astro-LBS im Modus "Astro".