[FR] Oberfläche/Funktion zum Einstellen der Timer Bausteine

[FabKNX]

Funktional ist es da mit Sicherheit einfacher erstmal mit der Definition der Zeitfenster zu beginnen.

Einfach wäre am Anfang erstmal prima.

[StefanW]

Guten Morgen zusammen und danke für diesen hervorragenden Thread und die tolle Diskussion!

Wie auch immer so etwas am Ende dann genau aussieht - es sollte übersichtlich und intuitiv sein, und nur die Funktionen enthalten die selbsterklärend sind und die jeder versteht. Integriert in das Objekt-Konzept, so dass ich bei Bedarf mit dem Zustand einer ZSU auch im Logikeditor weiter arbeiten kann - für die komplexen Anwendungsfälle.

Ja, genau richtig, so ist es auch gedacht.

Oder baut man gleich eine eigene GUI. Ich meine wahrgenommen zu haben, dass sowieso besonders in Sachen ZSU der Wunsch nach einer eigenen, einfacheren GUI besteht, weil vielen der Logik-Editor zu komplex ist.

Ja, so sehen wir das auch. Mittelfristig wollen wir viele Funktionen, die heute von Hand in Logik-Editoren abgebildet werden, in einer eigenen GUI handeln. Dazu gehören vor allem alle Klassiker:

1. Zeitschaltuhr / Kalender
2. Beschattung
3. Beleuchtungssteuerung / Szenen (TImberwolf Illumination Engine, "TIE")
4. Heizungsregelungen
5. Verbrauchs- und Energiemesseung aller Art
6. Energiespeicherung & Verteilung, Lademanagement E-Auto(s)

Es soll eben ganz einfach werden. Trotzdem kann jeder wie er möchte auch mit dem Logik-Editor arbeiten und mit anderen Tools im Docker.

Das wichtigste Entwicklungsziel für den Timberwolf Server ist "Einfach, aber ohne Grenzen".

Und selbst als Freund des Logik-Editors würde ich meine Kalender / Zeitschaltuhren lieber in einer separaten übersichtlichen Oberfläche pflegen - solange die Ergebnisse/Zustände wiederum als Objekte im Logik-Editor weiter verarbeitet werden können.

Jep, es entstehen einfach "Zeitobjekte" die genutzt werden können.

Wobei man mehrere Objekte - für einen Schaltvorgang - zur Auswahl haben sollen dürfte:

A: Das eigentliche Schaltobjekt (Ein/Aus)
B: Ein "dimmendes" Objekt das entlang einer Dimmkurve / Zeit hochfährt (also 0-100% in X Sekunden)
C: Ein Objekt dass Auskunft gibt über den nächsten Schaltzeitpunkt (damit man das in der Visu anzeigen oder was damit berechnen kann)
D: Ein Objekt, das wie ein Countdown (rückwärts zählend) die Zeit bis zum Schaltzeitpunkt anzeigt (damit man das in der Visu anzeigen kann "ACHTUNG in 1 Minute wird der Rasen gesprengt. Tick Tick Bumm")
E: Womöglich auch ein Sperrobjekt, damit man diesen Zeitschaltuhreintrag auch unterbinden kann.

Ob es dass alles dann schon im ersten Wurf geben wird, weiß ich nicht, aber zumindest ist es das, was ich dazu im Kopf habe.

Die eigene GUI für ZSU wird es geben im Hintergrund wird aber wahrscheinlich die gleiche LE, bzw. Eine Instanz davon laufen, man muss da ja das Rad nicht neu erfinden.

Richtig analysiert Göran, wie immer

Ausgeführt wird dies letztlich von der bestehenden Logik-Engine. Durch die Einträge in der GUI werden diese dort angelegt (so wie der jetzige Logikenditor die Logik "compiliert" - das ist der LE-Code - wird das auch eine jede andere GUI können.

Sollte StefanK dann dafür neue Grundbausteine kreieren schadet es ja nicht diese auch im "offenen" LE mit nutzbar zu machen.

Jep, wieder richtig. Magst nicht als Funktions-Designer bei uns anfangen. Kannst gerne von Berlin aus arbeiten, wir arbeiten mittlerweile alle virtuell zusammen. Wir haben in unserem Produkt auch Datenbanken...

Die eine oder andere Customlogik bedient sich dann ggf auch solcher Elemente. Manch einer hat das irgendwann schneller als Grundmodul in eine Customlogik gecodet.

Ja, wir wollen nichts beschränken, die Kunden sollen sich da frei fühlen, wie sie das machen wollen.

Die Frage wo das Ergebnis einer ZSU landet ist aber berechtigt. Aber auch hier ist der DOS ja überaus flexibel, den es mit Sicherheit auch als Pop-up geben wird.

Ja, er ist ansich schon ein "PopUp". Der DOS sieht dann einfach die zuvor angelegten Zeitobjekte und die kann er dann beliebig überall verknüpfen.

So kann das Ergebnis entweder direkt auf ein KNX KO als Schalter gehen oder eben erst noch in eine Logik um mit weiteren UND usw. Verbunden zu werden.

Jep, genau richtig.

Ich habe so keine Ahnung vom grafischen Seiten Design/Programmieren. Funktional ist es da mit Sicherheit einfacher erstmal mit der Definition der Zeitfenster zu beginnen. Einfache UND bzw. Sperr Eingänge wären da dann erst nur Schritt zwei. Vom Layout ist es aber ggf besser das direkt zu berücksichtigen. Am Ende sollte man sich aber auch etwas zügeln mit den Zusatzfeatures neben der Zeitfensterdefinition, weil sonst wird diese ZSU GuI zum weiteren LE und wer versucht dann darüber nen Beschattungsbaustein zu bauen.

Ja, man muss die Grenze geschickt ziehen, womöglich wird man das auch ausbauen um weitere Fähigkeiten.

Neben der Auswahl von fixen Terminen im Kalender mit voller Datumsangabe, hätte ich da noch den Bedarf nach generischer Datumsangabe ohne Jahresbezug (halt alle Jahre wieder)

Ja, das nennt man "ewiger Kalender". Das nutzt man für Geburtstage.

und mit relativen Bezügen zu den Feiertagen die immer so im Jahr Schwanken ( Montag nach Totensonntag startet die Weihnachtsbeleuchtung)

Ui, ja, das ist eine interessante Idee. Aber warum nicht. Ist wie bei Astro plus Offset dann eben auch Datum / Ereignis plus Offset (der auch negativ sein kann).

Damit kann man dann einstellen "am dritten Montag im Monat um 10 Minuten vor Sonnenaufgang soll die Beleuchtung von 0 auf 30% über einen Zeitraum von 10 Minuten im Gästezimmer andimmen" (weil dann ist die Tante Erna immer zu Besuch und die steht mit der Sonne auf).

Das mit den variablen Feiertagen find ich gut, da hatten wir schon mal eine Diskussion dazu.Allerdings wird das mit Bundesland, Staat etc. recht schnell aufwändig.

Ja, da wird man flexible einstellbare Kalender anbieten müssen (also beliebig viele) die man verknüpfen kann, weil das kann recht weitreichend werden.


lg

Stefan

[Dragonos2000]

Evtl. kann man sich bezüglich des Kalenders mit den Feiertagen an OpenHAB orientieren (Ephemeris). Bezüglich dem GUI gehe ich mal davon aus, dass Ihr aus den "Human readable" Eingaben bspw. einen Cron String generiert, den Ihr dann die Logikbausteine der LE übergebt.

Eine Herausforderung sehe ich darin, das so zu gestalten, dass die das GUI flexibel auch in anderen Visus nutzbar ist.

[StefanW]

Evtl. kann man sich bezüglich des Kalenders mit den Feiertagen an OpenHAB orientieren (Ephemeris).

Ich kenne leider OpenHAB nicht. Bitte mir immer Screenshots zeigen bitte oder eine URL wo das erklärt ist.

Bezüglich dem GUI gehe ich mal davon aus, dass Ihr aus den "Human readable" Eingaben bspw. einen Cron String generiert, den Ihr dann die Logikbausteine der LE übergebt.

So ähnlich wird das sein.

Eine Herausforderung sehe ich darin, das so zu gestalten, dass die das GUI flexibel auch in anderen Visus nutzbar ist.

Wie ist das gemeint mit "in anderen Visus nutzbar"?

Geht es darum, dass man in einer Visu eine ZSU einrichten kann? Was ich mir vorstellen kann ist, eine bestehende ZSU zu modifizieren, indem die Parameter auch als Objekt eingebunden werden können. Aber weitere ZSU anlegen? Mit Integration beliebiger Kalender? Das wird schwierig.

lg

Stefan

[Matze76]

Das mit den variablen Feiertagen find ich gut, da hatten wir schon mal eine Diskussion dazu.Allerdings wird das mit Bundesland, Staat etc. recht schnell aufwändig.

Ja, zumindest für die Situation in Deutschland würde ich das aber nicht auf Bundeslandebene (oder Stadt, Beispiel Augsburg) herunterbrechen.
Es reicht m.E. aus, die Gesamtheit der gesetzlichen Feiertage (filterbar nach D, A, CH ...) in einem Basis-Feiertagskalender zur Verfügung zu stellen. Jeweils mit einer Funktion aktiviert/nicht aktiviert, so dass die im ganzen Land gültigen Feiertage als aktiv voreingestellt sind, und jeder sich je nach Wohn- oder Arbeitsort weitere Feiertage hinzu aktivieren kann.

Je Feiertag stelle ich mir dann ein Zeit-Objekt vor, sowie aus der Gesamtheit der aktivierten Feiertage ein Objekt "heute ist Feiertag" (true/false) für die weitere Verarbeitung.

Wie Göran schon schrieb, dann noch die Möglichkeit, auf der Basis eines Feiertags-Objekts (bzw. Objekt für eigene "ewige Kalender") weitere eigene Zeitobjekte mit Offset +/- x Tage anzulegen. Für die Weihnachtsbeleuchtung, oder um immer schon eine Woche vor dem Hochzeitstag eine Erinnerung auszulösen

[bodo]

Hoi
Ich benötige das nicht, aber ein Wecker für Schichtarbeit wäre cool. Möglichst für eine gewisse Zeit vorprogrammierbar, z.B. ein 1/4 Jahr. Inclusive Freitage, Feiertage und Ferien.

[Dragonos2000]

Ich kenne leider OpenHAB nicht. Bitte mir immer Screenshots zeigen bitte oder eine URL wo das erklärt ist.

Es geht mir dabei um die Funktionen, hat nichts mit GUI zu tun:
https://www.openhab.org/docs/configurat ... #ephemeris

Eine Herausforderung sehe ich darin, das so zu gestalten, dass die das GUI flexibel auch in anderen Visus nutzbar ist.

Geht es darum, dass man in einer Visu eine ZSU einrichten kann? Was ich mir vorstellen kann ist, eine bestehende ZSU zu modifizieren, indem die Parameter auch als Objekt eingebunden werden können. Aber weitere ZSU anlegen? Mit Integration beliebiger Kalender? Das wird schwierig.

Geht mir um das Modifizieren in einer beliebigen Visu. Entweder dass die Seite als externe URL eingebunden werden kann (Thema der Authentifizierung!) oder, dass über andere Mechanismen (Logiken, KOs,...) die Einstellungen geändert werden können.

Edit 18.12.2019: Zerschossenes Zitat korrigiert

[Matze76]

Aber weitere ZSU anlegen? Mit Integration beliebiger Kalender? Das wird schwierig.

Würde dafür nicht - sofern die Visu es unterstützt - ein Link auf die entsprechende Timberwolf Oberfläche reichen? Vielleicht als spezielle Seite nur für die Visu-Einbindung, in der die Menüs und Schaltflächen links und im Kopf ausgeblendet sind.Grundsätzlich ist die Timberwolf GUI ja auf "touch" und die Nutzung mit mobilen Endgeräten ausgelegt.

[Robert_Mini]

Das sind aus meiner Sicht 2 paar Schuhe:
1) ZSU Logikmodul im Logikeditor, da sollte die Eingabe der Zeit auch über die Visu klappen, d.h. Eingang für Stunde, Minute und Wochentag.

2) ZSU GUI: keine Visu Anbindung, aber Einstellung im TWS Menü.

Robert

[Matze76]

Sehe ich genau so. Meine Aussage bezog sich auch nur auf Anlegen neuer ZSU bzw. Kalender, also 2).

Ein im Logikeditor angelegtes ZSU-Logikmodul sollte natürlich entsprechende Eingänge haben, die man dann wie auch immer "füttern" kann, z. B. aus der Visu.