Logikmodul: Dynamischer Timer / Zeitschaltuhr mit externem Zieldatum (z. B. Urlaubsrückkehr) autark auf dem Bus?

[henfri]

Hallo,

ich nutze das OpenKNX Logikmodul intensiv im Haus und bräuchte euren Rat hierzu:

Ausgangssituation / Use Case
Ich möchte meine Heizung bei Abwesenheit/Urlaub für einen definierten Zeitraum absenken (Räume über KNX-Heizungsaktoren auf Nacht/Frost, Wärmeerzeuger im Keller auf Absenkung).
Die Vorgabe des Rückreisedatums erfolgt über Home Assistant (z. B. per Datumswähler).

Anforderung: Autarkie auf dem Bus (Server-Ausfallschutz)
Wenn ich für zwei Wochen in den Urlaub fahre und währenddessen der Server/Home Assistant abstürzt oder offline geht, darf das Haus bei der Rückkehr nicht kalt bleiben. Die Rückkehr in den Normalbetrieb muss daher autark auf dem Bus ablaufen können, ohne dass HA zum Umschaltzeitpunkt zwingend erreichbar sein muss.

Was ich bisher in der Doku & den Modulen geprüft habe:
Zeitschaltuhren (Tages- und Jahresschaltuhr):
* Die Schaltzeitpunkte werden laut Applikationsbeschreibung rein statisch in der ETS parametriert.
* Es gibt nach meinem Verständnis kein Kommunikationsobjekt, um eine Schaltzeit dynamisch per Bus (z. B. DPT 19.001 oder DPT 10/11) von extern vorzugeben oder anzupassen.

Fragen:
1. Best Practice / Workaround: Übersehe ich eine Möglichkeit, wie man mit den bestehenden Bausteinen einen variablen Countdown / Timer über mehrere Tage/Wochen realisieren kann?
2. Feature-Gedanke: Wäre es für das Logikmodul denkbar, Zeitschaltuhren oder Treppenlicht-Timer mit einem dynamischen Zielzeit- oder Restlaufzeit-KO auszustatten?

• Beispielsweise ein Eingang für einen absoluten Schaltzeitpunkt via **DPT 19.001** (Datum & Uhrzeit)
• Oder ein KO für eine variable Verzögerungszeit mit größerem Wertebereich (z. B. Stunden/Tage via DPT 12 oder DPT 14)?

Wie löst ihr solche autarken Langzeit-Timer auf reiner KNX-/OpenKNX-Ebene?

Viele Grüße
Hendrik

[r4id]

Da du das Reisedatum über HA eingibst, übermittelst du das Rückreisedatum über eine GA an das Logikmodul.
Mit der Option "Eingangswert speichern und beim nächsten Neustart als Vorbelegung nutzen" am Eingang einer Logik speicherst du den Wert.
Dann noch auswerten, ob das Datum erreicht ist und wieder eine entsprechende GA setzten für die Heizungsaktoren.

Da musst du erst mal nichts mit Zeitschaltuhren machen

[r4id]

Mir ist noch eine Möglichkeit eingefallen.

Du gibst über HA den "Start" Absenken und die "Tage" wie lange du ab diesem Zeitpunkt im Urlaub bist.
Über eine ZSU kannst du dir einen täglichen Trigger erstellen und die Tage in einem weiteren Logkkanal herunter zählen.
Sobald 0 erreicht ist, wird die Absenkung verlassen.

[mumpf]

hendrik: Du hast recht, das Logikmodul kann keinerlei dynamische Zeitbehandlung, nur statische Zeitschaltuhren. Hintergrund ist, dass DPT19, was eine externe (und damit dynamische) Zeitsteuerung ermöglichen würde, ein 8 Byte KO ist. damit würde ich auf einen Schlag den KO-Speicher vom Logikmodul verdoppeln. Da das Logikmodul recht ressourcenarm gebaut ist, damit es in jede Applikation von uns reinpasst, habe ich bisher gescheut, diesen Schritt zu gehen. DPT10 und DPT11 als Eingänge zu implementieren ist eher mühevoll, aber denkbar - hab ich aber bisher nicht gemacht. Deine Einschätzung ist also korrekt, nativ mit Zeitangaben kommst Du nicht weiter.

Mit aktuellen Mitteln kommst Du mit dem 2. Vorschlag von r4id weiter: Du rechnest im HA die eingegebene Zielzeit in ein Delta um und setzt einen Zählwert, der vom Logikmodul auf 0 runtergezählt wird. Beim erreichen von 0 macht er dann seine Aktion und bleibt stehen, bis der Zähler erneut gesetzt wird. Ich würde die Auflösung aber in Minuten (oder zumindest Stunden) und nicht in Tagen wählen. Den Minutentrigger würde ich über eine Zeitschaltuhr gestalten und nicht über "zyklisch senden jede Minute", denn letzteres driftet über lange Zeit sicherlich mehr als eine Zeitschaltuhr.

Auch der 1. Vorschlag von r4id ist machbar, ich glaube er ist aber erklärungsbedürftig. Vergleich von Zeit/Datum geht nämlich nur indirekt. Das Logikmodul kann DPT10 und DPT11 nicht nativ, aber es kann 3-Byte-KO auswerten über DPT232.600 (RGB-Wert). Dieser DPT ist somit zuweisungskompatibel zu DPT10/DPT11.

Somit kannst Du eine Logik bauen, die 2 DPT232-Werte empfängt und auf Differenz 0 vergleicht (Eingang als Differenzintervall). Der eine Eingang wird vom aktuellen Datum versorgt, der 2. wird von HA mit dem Zieldatum gesetzt. Hier muss in HA dann das eingegebene Zieldatum binär korrekt in das passende DPT11-Binärformat umgerechnet werden. Wenn man Datum+Zeit hat, braucht mal 3 Logikkanäle: 1xDatumvergleich, 1xZeitvergleich, 1xUND. Will man es mit Zeit machen, muss man darauf achten, dass die Zeit auch häufig genug auf den Bus gesendet wird und beim Differenzintervall eine passende Toleranz angegeben wird (z.B. 60 oder 100).

Beide Varianten gehen jetzt schon, ich halte die Variante mit dem Zähler für leichter realisierbar, aber weil sie ein Delta-Verfahren repräsentiert, wird bei einem Stromausfall von 8h im Urlaub auch die Heizung 8h später eingeschaltet. Die Variante mit DPT232 hat einen absoluten Zeitpunkt als Referenz, muss aber sicherstellen, dass ein passendes Zeittelegramm zum Schaltzeitpunkt auf dem Bus ist.

Das ist mit aktuellem Stand möglich,
Gruß, Waldemar

[henfri]

Danke Euch Beiden.

Wenn ich es richtig sehe, dann hat der 1. Vorschlag von r4id den Nachteil, dass bei einem Stromausfall das Schalt-Datum um die Dauer des Ausfall verschoben wird.
Der Vorschlag von Waldemar hat den Nachteil, dass nur das exakt gleiche Datum gematcht wird. Ein Stromausfall am ganzen Anschalttag würde dazu führen, dass das Anschalten komplett verpasst wird.

Richtig?

Ich denke, beide Probleme sind sehr theoretischer Natur - es geht eher um das Verständnis.

[ReinerDaniel]

Also ich schalte via VPN und HA von standby einen Tag vor Urlaubsende wieder auf Komfort.
Und ja, wenn HA während des Urlaubes abstürzt, könnte ich noch via Homekit oder PROKNX zurükc auf Komfort schalten.
Unn wenn es keinen Strom gibt, würde meine WP eh nicht heizen.

[coko]

Beim Countdown in den Functionblöcken gibt es noch eine Möglichkeit die Zeitspanne per KO vorzugeben. Bin aber nicht sicher ob das diesen Anwendungsfall mit abdecken würde. Einen Stromausfall würde das wohl auch nicht über stehen.

[mumpf]

Der Vorschlag von Waldemar hat den Nachteil, dass nur das exakt gleiche Datum gematcht wird. Ein Stromausfall am ganzen Anschalttag würde dazu führen, dass das Anschalten komplett verpasst wird.

Naja, der Stromausfall am Anschalttag würde nicht funktionieren, weil dann kein Strom zum Einschalten da wäre . Wenn am Anschalttag irgendwann der Strom wieder da ist, würde auch das Datum (für den Vergleich) funktionieren und damit auch eingeschaltet werden. Arbeitest Du auch mit der Zeit, würde der ZEITpunkt für das Einschalten womöglich während des Stromausfalls liegen und damit dann verpasst werden.
Bei der Zeit könnte man beim Differenzintervall aber auch nicht auf gleich, sondern auf größer prüfen. Da aber binär (auf Zahlenwerte und nicht wirklich auf Zeit) geprüft wird, müsste man schauen, was das überhaupt heißt. Semantisch ist es eben nicht "später" sondern "größer", was man prüft. Offensichtlicher Fall: 1 Uhr Nachts ist später als 23 Uhr vom Vortag, aber sicher ist 1 nicht größer 23.

Hab mal eben geschaut, DPT10 ist:
Byte 0 Bit 7-5: Wochentag
Byte 0 Bit 4-0: Stunde
Byte 1 Bit 7-0: Minute
Byte 2 Bit 7-0: Sekunde

Eben gelesen: 0x6B3B32 ist Wed 11:59:50, also
von 0x6B die oberen 3 Bits sind 011 = 3 = Mittwoch
von 0x6B die unteren 5 Bits sind 01011 = 11 = 11 Uhr
0x3B ergibt 59 = Minute 59.
0x32 ergibt 50 = Sekunde 50.
Als Dezimalwert ergibt das 7.027.506, das ist monoton steigend und damit auch auf größer vergleichbar.
Also könnte man so auch "verpasste" Telegramme am selben Tag hinbekommen.

Ist auch nur für das Verständnis analysiert

Gruß, Waldemar

P.S. Monoton steigend, aber mit Lücken.
Nach Wed 11:59:59 (0x6B3B3B = 7.027.515) kommt Wed 12:00:00 (0x6C0000 = 7.077.888)

[willisurf]

Monoton steigend

Funktioniert das auch, wenn der Wochentag einen „Overflow“ hat?

[coko]

Funktioniert das auch, wenn der Wochentag einen „Overflow“ hat?

Dann nicht mehr. Müsste man dann doch noch mit Datum zusammenrechnen (bzw. durch Bit-Operationen kombinieren).

[mumpf]

Geht ja nur um die Zeit, das Datum würde man ja extra prüfen.

Gruß, Waldemar

[henfri]

Naja, der Stromausfall am Anschalttag würde nicht funktionieren, weil dann kein Strom zum Einschalten da wäre . Wenn am Anschalttag irgendwann der Strom wieder da ist, würde auch das Datum (für den Vergleich) funktionieren und damit auch eingeschaltet werden

Ja, es geht ja darum, dass sobald der Strom wieder da ist - und das auch am nächsten Tag - geschaltet wird.

Also ich schalte via VPN und HA von standby einen Tag vor Urlaubsende wieder auf Komfort.
Und ja, wenn HA während des Urlaubes abstürzt, könnte ich noch via Homekit oder PROKNX zurükc auf Komfort schalten.
Unn wenn es keinen Strom gibt, würde meine WP eh nicht heizen.

Ja, manuell an und aus schalten kann ich heute auch schon ;-)