ElabNET Technik Forum

Ich fände es gut, wenn wir eine inhaltlich tiefgehender Diskussion zu einer "einfachen ZSU" von der allgemeinen Umfrage abkapseln und daher fange ich hier einfach mal an.

Angestoßen vom Kommentar in viewtopic.php?f=9&t=2761&p=31382#p31382

StefanW hat geschrieben: ↑Fr Mär 26, 2021 5:34 pm Was GENAU gehört in die Visu? Die Einstellmöglichkeit oder die Engine, welche das Ereignis dann auch ausführt? Soll die VISU zum eingestellten Zeitpunkt das Ereignis auslösen? Läuft die Visu dann auch rund um die Uhr? Oder soll der TWS die Events auslösen, aber von der Visu fernbedient werden?

Meine persönliche Meinung:
Die Engine gehört in den die TWS-Oberfläche und ich würde sie mir da sogar als Logik-Modul wünschen (dann haben wir maximale Freigheitsgrade), aber dafür fehlen aktuell auch noch Datentypen für Zeiten und Datum.

Eine Visu wie die CV dient ausschließlich der Bedienung und als Einstellort.

Deshalb sehe ich auch für die ZSU das Thema MQTT als notwendig...ein User würde wählen können, ob die ZSU im Enginemodul / Logikmodul parametriert oder per KNX, MQTT-Parameter eingestellt wird (also quasi mittels DOS-Verschaltung).

Somit hat Jeder die Möglichkeit die Einstellung da zu machen, wo es ihm beliebt. Nicht jeder - aber ich glaube viele - TWS-Nutzer haben eine CV. Für mache ZSU's reicht eine Einstellng durch den "Home-Admin" der auch die TWS bedienen kann. Aber andere sollen von der ganzen Familie beinflussbar sein...

Da der TWS bis dato keine eigene Visu hat und hier auf CV setzt (für mich nach wie vor eine sehr gute Allianz, ich brauche nichts Anderes) würde ich mir in der CV ein ZSU-Widget wünschen.

StefanW hat geschrieben: ↑Fr Mär 26, 2021 5:34 pm Was GENAU gehört in die Visu? Die Einstellmöglichkeit oder die Engine, welche das Ereignis dann auch ausführt? Soll die VISU zum eingestellten Zeitpunkt das Ereignis auslösen? Läuft die Visu dann auch rund um die Uhr? Oder soll der TWS die Events auslösen, aber von der Visu fernbedient werden?

In Kombination einer Visu gibt es meiner Meinung nach nur einen sinnvollen Ansatz:
- Die ZSU selbst muss im TWS laufen um Events auslösen zu können
- Eine Visu stellt die Parameter bereit (Ein-/Ausschaltzeitpunkt, Wiederholung, evtl. Kalendertag usw., evtl. sogar die Auswahl eines bestimmten Ziels)

Dazu muss die ZSU aber natürlich universell genug sein, je nach Anwendungsfall entsprechende Einstellparameter eben auch als externe Parameter empfangen zu können.
Insgesamt kommt der Baustein von Robert (viewtopic.php?f=65&t=2555&p=28700&hilit=ZSU#p28700) dem glaube ich schon recht Nahe.


Was sich aber über eine Visu wohl eher schwieriger realisieren lässt sind komplexere Zeit Schaltuhren wie "Einschalten bei Sonnenaufgang + 20 Minuten, nicht jedoch aber vor 6 Uhr, aber auch nicht 8 Uhr".
Ebenso eine komplexe Wochenübersicht mit beliebigen Zeitfenstern die An oder Aus signalisieren (siehe viewtopic.php?f=24&t=1174&p=14910#p14910).
Diese beiden Anwendungsfälle wären wohl eher etwas für die TWS Oberfläche. Oder zumindest würde mir kein sinnvoller Weg einfallen eine solche Menge anf Informationen sinnvoll von einem System (Visu) and die ZSU (TWS) zu übertragen, da hier wohl beids aus einer Hand kommen müsste.

VG
Earl

Hier mal als Anregung ein Screenshot von der ZSU in einem alten, bereits abgekündigten 4" KNX Panel an meiner Wand: Sowas hilft bei uns schon sehr weit , z.B. auch um Nachtabsenkungen in einer Heizungsanlage zu programmieren oder eine sehr einfache Balkon-Bewässerungssteuerung zu realiseren und das kann auch die ganze Familie bedienen. Durch die 4 Kalenderblätter unten im Bild kann, man grundsätzlich 4 unterschiedliche Tageseinstellungen á 6 Schaltpunkte realisieren... Ansich ist das ja kein Hexenwerk, aber ohne Array-Datenpunkt (geht doch bestimmt bei MQTT, oder) wirde das dann schon sehr nervig.

Ja die Visu hat nur die Knöpfe, die man sich auch irgendwie selbst bauen und anordnen kann. Die ZSU muss eben Objekte für die Eingangs / und Ausgangsparameter bereitstellen.
Solche ZSU extern bedienbar, können natürlich relativ Einfach gehalten werden.

Gerechnet ausgewertet verglichen getriggert usw. sollte immer im TWS werden.
Soweit haben die beiden oben das gut umschrieben was man so braucht.

Sven meint bestimmt das er die Zeitschaltuhr an sich und die Verbindung nach Außen ( Eingangswerte und Ausgangswerte) selbst definiert.
Die Frau oder andere sollen dann auf einer anderen Seite nur die Schaltzeiten anpassen können und die Uhr aktiv oder inaktiv schalten.

@Robosoc Richtig?

Sun1453 hat geschrieben: ↑Fr Mär 26, 2021 7:46 pm Die Frau oder andere sollen dann auf einer anderen Seite nur die Schaltzeiten anpassen können und die Uhr aktiv oder inaktiv schalten.
@Robosoc Richtig?

Jo, genau so meinte ich es.
Und so wie Earl es oben auch geschrieben hat...richtig komplexe ZSU brauchen nicht in der Visu einstellbar sein, denn die wird vermutlich eh zu 99% nur der "Home-Admin" programmieren können

Das eine ZSU auf einem Logik-Server und nicht in der Visu laufen muss ist klar. Die soll schließlich auch schalten, wenn gerade keine Visu an ist

Praktische Anwendungen einer ZSU können beliebig komplex werden (5 Min vor Sonnenaufgang aber nicht vor 7 Uhr aber auch nicht nach 8 Uhr, am Wochenende aber anders, während eines Feiertags doch nochmal andern und bei Urlaub, entweder wie Feiertag, oder, wenn abwesend, dann doch eher wie es die Anwesenheitssimulation vorgibt, usw.), aber dann ist eigentlich schon das Thema ZSU und Logik vermischt. Daher sollte dringend die ZSU von der Logik sauber getrennt werden.
Für die Visu Schnittstelle bleibt dann das Ändern von ZUS Einstellungen (und nicht mehr das generieren der Logik dazu).

Hier wäre wichtig zu wissen, was denn über die Visu konkret einstellbar sein sollte, also was ein ZSU-Widget können sollte. Denn zum einen hängt ja die Visu davon ab, aber zum anderen die ZSU Logik.

Ich persönlich könnte mir als relevant vorstellen:
- Uhrzeit
- Sonnenstandsabhängige Uhrzeit (z.B. Dämmerung) + Offset
- Auswahl der 7 Wochentage + Feiertag + Urlaub
- das ganze ggf. mehrmals am Tag
- Verschiedene verschiedenen Werte (z.B. Dim-Werte und nicht nur Ein/Aus)

Das ganze als Mock-Up könnte dann z.B. so aussehen:

Hallo zusammen,

nun, der Gedanke wäre, dass die Konfiguration (und auch die Abfrage der jetzigen Einstellungen) durch die Visu über ein Array (genauer Json) erfolgen, das per MQTT versendet / abonniert wird. Ich muss da noch ein wenig drauf rumbrüten, aber folgende Gedanken:

1. Es gibt (beliebig) viele ZSU-Gruppen, eine jede Gruppe ist ein komplexer Eintrag. Eine Gruppe hat eine eindeutige ID und eine Bezeichnung, die man dann auch in der Visu anzeigen müsste, weil das Widget müsste in der Lage sein, durch die verschiedenen ZSU-Gruppen "wischen" zu lassen.

2. Ablauf im ZSU-Subsystem des Timberwolf Servers. Eine Gruppe bedient EIN Objekt, dieses ist beliebig verknüpfbar mit dem Objektsystem

3. Womöglich stellt man auch Ablaufgruppen zur Verfügung, die eine zeitliche Abfolge von Ereignissen bedienen, diese kann von einer ZSU-Gruppe ausgelöst werden (womit komplexere Abläufe möglich sind)

4. Die Einstellung einer ZSU-Gruppe können per API nach außen geöffnet. mithin abgerufen und eingestellt werden. Eine solche API kann per Rest oder auch MQTT abgebildet werden (letztlich ist das nur der Transportmechanismus für ein json mit der Konfig der ZSU Gruppe)


Fragen:

- Feiertag kann komplex sein. WESSEN Feiertag? Bei einem Paar, das an der Grenze zu einem Bundesland wohnt und der eine in dem einen und der andere in dem anderen Bundesland arbeitet, kann das schon unterschiedliche sein. Das gleiche bei verschiedenen Konfessionen. Für die Kids kann wiederum etwas anderes gelten (Ferienkalender). Kommt man mit einer Feiertagsdefinition hin, oder muss man mehrere Kalender unterstützen, die benannt wären und um die eine solche Visu wissen müsste?

lg

Stefan

Hmm also das mit der Visu ist OK, Ich hoffe nur das ich auch in der TWS Oberfläche eine komplette ZSU-Funktion editieren kann und nicht zwangsweise auf eine Visu angewiesen bin.

Feiertage sehe ich da weniger als ein Problem an, die sind schon für alle gleich. Die Frage ist nur ist der erste Weihnachtsfeiertag oder Frauentag für einen selbst ein relevanter Tag in der ZSU. Insofern wäre ein Feiertag nichts anderes wie Mo, Di, Mi. Allerdings wäre eine solche ZSU dann womöglich nicht mehr so einfach über eine Visu bedienbar, weil man dann nicht nur die 7 Wochentage sondern auch noch einen langen Katalog an Feiertagen zur Auswahl mitschicken müsste. Bei den Ferien, ja das ginge nur über die Einbindung von externen Kalendern. Analog die Mülltermine, Info 2 Tage vor gelbe Säcke usw.

StefanW hat geschrieben: ↑Sa Mär 27, 2021 4:31 pm Fragen:

- Feiertag kann komplex sein. WESSEN Feiertag? [...]

Wenn etwas komplex ist - wie eben die Frage nach dem Feiertag - dann lautet die Frage nicht was man dafür braucht, sondern: Wie bekomme ich die Komplexität reduziert?
Bei Feiertagen dürfte sich das dadurch einfach lösen lassen, dass nicht der TWS festlegt was ein Feiertag ist, sondern der Anwender. Am einfachsten in einem Online-Kalender(*), den der TWS dann als Basis hernehmen kann.

So kann der Anwender ganz leicht festlegen ob nun Buß- und Bettag ein Feiertag ist oder nicht. Oder ob doch eher die jüdischen Feiertage relevant sind, oder die des Nachbar-Bundeslandes, oder ...

Und über genau die gleiche Schnittstelle kann die Information, ob gerade Urlaub ist oder nicht, eingeholt werden. Bei geschickter Auswertung sogar ob Urlaub zu Hause oder Urlaub mit Verreisen (= Abwesenheitssimulation aktivieren).

Oder ob heute Müllleerung ist und wenn ja welcher. Ob evtl. eine Pop-Up-Nachricht auf ein Handy geschickt werden soll, dass eine (und wenn ja welche) der Mülltonnen raus gestellt werden muss.

---
(*) Bitte nicht auf die Idee kommen und selber einen Online-Kalender bauen zu wollen. Die sind auch sehr komplex. Und Anwender wollen das Nutzen was sie schon haben und mit dem Handy synchronisiert ist. Und in dem die Müll-Termine vom lokalen Entsorgungsunternehmen aboniert sind.