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

[Dragonos2000]

Da das Thema Oberfläche zum Thema Timer/Zeitschaltuhr m.E. recht verzettelt in mehreren Threads kursiert und inhaltlich kaum mehr zusammenführbar ist, eröffne ich diesen Thread, um die Informationen, Ideen und Anforderungen zu bündeln.
Außerdem hat ElabNet um weiteren Input, auch Zeichnungen wie sowas aussehen könnte, für die Entwicklung gebeten.
Ich würde es dabei gerne auf die Oberfläche und Funktionen zum Einstellen einer ZSU/eines Timers beschränken.

Also los geht's: Haut Eure Ideen und Zeichnungen raus...

[Dragonos2000]

Vorschlag/Idee: Implementierung in 2 Teilen
1) Logikbaustein, mit Integer Eingängen für Tag, Stunden, Minuten, usw. inkl. Validierung der eingegebenen Werte, der daraus einen Cron-String erstellt, mit dem die Timer-Bausteine gefüttert werden können
2) Web-Oberfläche zur Bedienung des Bausteins aus 1)

Das würde die Freiheitsgrade erhöhen, da einige KNX-Sensoren und auch die meisten Visus die Möglichkeit für Integer Eingaben bieten, die sich dann nutzen ließen.

[EarlBacid]

Grundfunktionalität der ZSU wäre vor Allem, dass es sowohl eine Einschalt- als auch Ausschaltzeit gibt.

Schön wäre natürlich, wenn man diese erweitern könnte auf mehrere Einscahlt- und mehrere Auschaltzeiten, das ist aber Optional, da dies im Zweifelsfall auch über den Cron-Strin erreichbar ist (siehe dazu https://www.freeformatter.com/cron-expr ... uartz.html)

Schön wäre auch, wenn anstelle der Ausschaltzeit auch ein Timer (idealerweise incl. Input als Alternative zu statisch definiertem) existiert, in dem man dann "Einschaltzeit + X" als Auschaltzeitpunkt festlegen kann, und der sich dementsprechend automatisch anpasst wenn der Einschaltzeitpunkt verändert wird.

[bodo]

Hoi

Ich würde dann gerne mit den Einschaltzeiten rechnen in der/einer Logik.

[EarlBacid]

Kannst du dafür mal ein Beispiel nennen was genau du machen und erreichen wollen würdest?

[tger977]

also bei mir sieht das in EDOMI so aus:

das ist mein Schlafzimmerwecker. Über die Visu bzw. per Logik wird die Weckzeit eingestellt und der Wecker grundsätzlich aktiviert. Über den Offsetbaustein wird dann z.B. 180min vor der nächsten Weckzeit die Heizung aus der Nachtabsenkung hochgefahren, 45min vorher dann die Handtuchheizkörper aktiviert, die Warmwasserzirkulationspumpe eingeschaltet und dann mit der eigentlichen Weckzeit Musik eingespielt, das Tag/Nachtobjekt getriggert, WLAN im Haus aktiviert, die Visutablets eingeschaltet...

[FabKNX]

Das wäre mir schon zu kompliziert.
Eine Maske, Startzeit und Endzeit instellbar wäre der erste Schritt.

[StefanW]

Danke Andi, gefällt mir.

Bitte mehr solcher Beiträge, wo andere etwas was besser machen

Merci

Stefan

[tger977]

Hallo Stefan,

etwas OT, aber da Du es ansprichst:

ui, da würde ich sehr lange schreiben müssen und so viele FR würde ich euch im Moment auch gar nicht antun wollen...

In EDOMI gibt es mehrere hundert Logikbaustein mittlerweile und ich habe auch dutzende davon im Einsatz. Einige Beispiele: mehrere Alexa LBS, ics Kalendereinbindung, UDP Messages verarbeiten/senden, Denon AVR, IR-Trans, Hostchecks, Telegram senden/empfangen, WakeOnLan, Wetterbericht, Unwetterwarnung, Alarmanlage, Netzwerkkameras (Alarmauswertung, Bilder in Kameraarchiv), Fritzbox steuern (WLAN, GastWLAN, DECT Anrufe für Alarme,...), Fritzbox auswerten (Anrufliste), Verbrauchswerte berechnen (Statistik), DMX Steuerung, Geräte per ModBus (z.B. SunSpec PV Wechselrichteranbindung), http API's incl. JSON Handling (z.B. Nuki Haustürschloss), MQTT, Möglichkeit von Sequenzen mit festem Zeitablauf und noch ein paar Kleinigkeiten mehr. Bei mir redet alles im Haus miteinander.

Ich hadere mit den Logiken im TW leider immernoch aufgrund der mir persönlich fehlenden Übersicht, das kann EDOMI aus meiner Sicht einfach viel besser wenn man mehrere Einzellogiken zu einer Gesamtlogik zusammenbauen muss, da kann ich das ganze auch gut dokumentieren und verstehe es dann auch noch einigen Monaten noch was ich da gemacht habe. Mal ein Beispiel meiner Zirkulationspumpenlogik für das Warmwasser (über jeweils einen 1w Temp sensor von euch an Vor- und Rücklauf und die Präsenzmelder in allen Räumen mit Warmwassernutzung):



Da frag ich mich wie das im TW aussehen soll und dann später mal noch nachvollziehbar / wartbar sein soll?

Was aber echt nervt bei EDOMI ist die mittlerweile extrem lange Projektaktivierung bei Änderungen (das kann bei meinem Projekt schon mal 5min dauern, wehe man macht dann einen Fehler und muss nochmal ran...)

[gbglace]

Hi Andi,

der Vorteil des TWS LE ist dabei, das es bei dieser Logik wahrscheinlich viel weniger Elemente sein müssten um zu funktionieren.
Ich sehe da inhaltlich viele UND mit Schwellwertvergleichern, das kann der TWS LE deutlich kompakter abbilden und ist auch nachvollziehbar, ohne das der LE-Code aufgeklappt betrachtet wird.

Der Tendenz-Baustein im EDOMI ist kompakter als im aktuellen TWS-LE, weil das hier mit Timer usw. noch einige Bausteine bedarf.