[NEUHEIT] ZSU Baustein (Zeitschaltuhr)

[Chris M.]

Erst mal: Eine "Uhrzeit" ist ein erstaunlich komplexes Ding, was man gar nicht glaubt, weil man ja täglich mit "Zeit" konfrontiert ist. Es gibt Zeitzonen, Uhrzeitumstellung (teilweise zu unterschiedlichen Daten je nach Ort), Schaltsekunden, ... Dass die Konnex der Uhrzeit auch noch den Wochentag dazu gepackt hat macht das nicht wirklich besser.
Spätestens wenn man versucht Zeitdauern zu berechnen wird das entweder ungenau oder eklig.

Aber nun zur konkreten Frage:

Das Clock-Widget unterstützt doch MQTT jetzt schon, oder?
Was erwartet das Plugin momentan als Formatierung im MQTT...eine vergleichbare Formatierung wie im KNX DPTS 10.001 definiert oder eine Zeit in Sekunden seit 00:00:00?

Hier ist die Antwort simpel: Den Widgets (wie z.B. Clock) ist das Backend (wie KNX, OpenHAB oder MQTT) vollkommen egal, die arbeiten mit JavaScript Variablen. Die werden über die in der Config eingestellten Transformation befüllt mit dem Wert aus dem Backend befüllt. Und bei MQTT gibt aktuell keine Transformation für Uhrzeiten (oder Daten).

Was implementiert ist kann in dieser Datei gesehen werden: https://github.com/CometVisu/CometVisu/ ... ms/Mqtt.js

=> Es gibt aktuell Zahlen und String, so wie ein JSON-Objekt - wobei letzteres v.a. zum Lesen funktioniert.

Eine Transformation für Uhrzeit und auch Datum lässt sich aber schnell implementieren. Wichtig wäre da nur zu wissen in welchem Format die üblicher Weise gesendet wird.

[Robosoc]

Alles klar, dann wäre meine Meinung schnell gebildet. MQTT hat nix zu tun mit KNX und somit braucht es auf keinen Fall die komplexe Struktur eines DPT 10.001.

Die Sekunden ab Mitternacht finde ich sehr hilfreich und für jeden Schnell nachvollziehbar.

Den Wochentag würde ich ebenfalls weglassen. Kann man sich bei Bedarf in einem einfachen Integer mit Mapping dazuholen.

Und dann passt es auch schon super zum TWS Umgang mit dem supi-dupi 10.001.

[SchlaubySchlu]

Ich habe noch eine Frage zum Trigger-Eingang, was macht der jetzt genau?
Brauche ich den, wie ist der genau zu verwenden? Du schreibst vorn etwas von, wenn man einen Retrigger des Aussgangsignal will dann soll man den Trigger setzten.

Ich möchte eine Funktion realisieren das ich mit einem Slider die Re-Trigger-Zeit einstellen kann. Also wenn der Slider auf 0 ist dann erfolgt kein Re-Trigger, wenn der Slider >0 bis 60 hat dann soll ein Re-Trigger des Ausgangssignal nach dieser Zeit erfolgen.

Noch eine Frage, kann es sein das die ZSU nur reagiert, wenn der Ein-/Ausschaltzeitpunkt von der Aktuellen Zeit "überfahren" wird?
Oder anders gefragt, wenn es z.b. aktuell 14:10 Uhr ist, die Einschaltzeit auf 14:00 gesetzt wird und Ausschaltzeit auf 15:00 dann wird der Ausgang der ZSU nicht gesetzt. WEnn es jedoch aktuell 13:59 ist, und somit die Einschaltzeit von 14:00 in der Zukunft liegt, dann schaltet die ZSU wie gewünscht.

Gruß
Ralf

[SchlaubySchlu]

Nach dem ich jetzt ja schon über ein Jahr an der Thematik arbeite wollte ich nun meine aktuell implementation vorstellen

Verwendete Logic-Bausteine:
- Aktuell 4 ZSU-Bauteine von Robosoc
- "Sicherung" der Settings der ZSU-Bauteine über je einen Persistance-Bautein. Diesen triggere ich zusätzlich noch 4 mal am Tag, weil ich sonst immer mal wieder Probleme mit der Visu hatte.
- "Sicherung" der Zeitschaltuhrsettings für jedes zu schaltenden Objekt durch einen Persistance-Baustein
- Multiplexer dex-binär für jedes zu schaltenden Objekt, zur Auswahl der aktivierten Zeitschaltuhren für das Objekt
- AND zur Verknüpfung des zu schaltenden Objekt mit der aktivierten Zeitschaltuhr (1 bis 4)

Oberfläche Zeitschaltuhren:
Die Oberfläche schaut wie folgt aus und sollte eigentlich selbserklärend sein. Die Funktion Intervalltrigger ist aktuell noch nicht in betrieb (siehe voriger Post)


Oberfläche zu schaltende Objekte:
Zu den zu schaltenden Objekte (Steckdose / Beleuchtung) habe ich einen Parameter "Zeitschaltuhr" hinzugefühgt, mit dem wenn die gewünscht die Zeitschaltuhr 1 bis 4 und alle Kombinationen (insgesamt 2^4) ausgewählt werden können.


Im Beispiel ist aktuell die Zeitschaltuhr 1 und 2 selektiert, welche dann auf die Steckdose an der Eingangstüre wirken.
Die Selektion der Zeitschaltuhr für dieses Objekt wird dann mit Hilfe eines dec2bin Multiplexer für jede Zeitschaltuhr "decodiert". Dieses "decoiderte" enable/disable für jede der 4 ZSUs enabled über ein AND die Verbindung des Ausgangs jeder einzelnen ZSU auf das zu schaltende Objekt.

Ich hoffe das kann man verstehen, ansonsten einfach nachfragen

KNX-Objekte am Bus
für jede ZSU:
- ZSU enable / dissable
- ZSU Intervalltrigger
- ZSU Einschaltzeit Stunde
- ZSU Einschaltzeit Minute
- ZSU Ausschaltzeit Stunde
- ZSU Ausschaltzeit Minute
- ZSU Ausgang

für jedes zu schaltende Objekt:
- Zeitschaltuhr-Selektor

Vielleicht hilft meine Umsetzung jemanden oder vielleicht habt ihr noch eine Idee für eine Verbesserung.

Das Ganze läuft soweit seid einigen Tagen stabil.

Gruß
Ralf

[SchlaubySchlu]

Hallo Robert,
ich habe ja immer noch "deine" Zeitschaltuhr in benutzung, die soweit auch gut funktioniert.
Einzig was mich etwas Stört ist, das die Zeitschaltuhr nur "richtig" funktioniert wenn die aktuelle Uhrzeit vor der Einschaltzeit und Ausschaltzeit liegt. Wenn ich z.B. um 17:00 die Zeitschaltuhr mit AN=16:00 und AUS=19:00 "programieren" dann passiert nichts.
Ist das so gewollt von dir oder habe ich da ewas falsch umgesetzt?

Gruß
Ralf