Kaufempfehlung Zeitschaltuhr / Referenzzeit mit Offsets

[willisurf]

Das Logikmodul hat ja 99 Kanäle. Ein recht pragmatischer Ansatz wäre mit einem Teil alle sinnvollen Weckzeiten als ZSU umzusetzen (z.B. im 10min Abstand), dann mit einem weiteren Teil Logikkanälen gesteuert über ein Byte eine Auswahl der passenden Zeit zu machen (TOR, Vergleich etc ist ja alles vorhanden) und dann die Zeitstaffelung mit weiteren Kanälen wie gewünscht umzusetzen.

[FrankOverIP]

Der Vorschlag könnte wohl funktionieren, aber es streubt sich einiges in mir das so umzusetzen. Das ist ja eher eine asymptotische Annäherung an eine Lösung. Wie geschrieben, schaue ich da lieber erstmal an, wie weit ich mich als ABAP-Entwickler mit PlattformIO zurechtfinde.

[coko]

kommt dir aber [...] abends im Bett in den Sinn, dass du das morgen gerne eine halbe Stunde später starten würdest, oder? Der Kern meiner Frage ist ja, dass ich die Startzeit für alle davon abgeleiteten Aktionen von außen ändern möchte.

Wie viel Variation und Einstellgenauigkeit brauchst Du denn?

Mit anderen OpenKNX-Modulen gibt es noch weitere Möglichkeiten:

• Mit den Zustandsautomaten könntest Du zwischen verschiedenen Verzögerungen wählen. Je Verzögerung dann einen Ruhezustand, einen Verzögszustand und einen Zwischenzustand zum Start der Sequenz. Ggf. reicht da auch ein gemeinsamer wenn täglich auf einen Standardwert zurückgefallen werden soll
• Die CountDown-Funktion in den Funktionsblöcken erlaubt in gewissem Rahmen die Vorgabe der Laufzeit per KO. Falls Du noch einen MDT GT2 hast, dann kannst Du AFAIR auch direkt einen Byte-Wert einstellen der sich dafür nutzen lässt

Dazu bräuchteat Du entsprechend die StateEngine (nur Logik und viele Zustandsauromaten) oder den Raumcontroller (alle genannten Module und noch weitere)

[willisurf]

Wie geschrieben, schaue ich da lieber erstmal an, wie weit ich mich als ABAP-Entwickler mit PlattformIO zurechtfinde.

Kann ich gut verstehen. Bei Fragen zum Logikmodul hilft Waldemar mumpf sicher gerne. Wichtig wäre keine zusätzlichen KOs zu verwenden, aber bei Zeitschaltuhrkanälen stehen die zwei Eingangs-KOs ja zur Verfügung.

[FrankOverIP]

Wie viel Variation und Einstellgenauigkeit brauchst Du denn?

Danke für die Ideen, aber eigentlich will ich das alles gar nicht - es macht ein simples Problem zu einer ziemlich komplexen Konfiguration. Ich möchte eine Bezugszeit, die von außen kommt - eine beliebige Uhrzeit. Damit kann ich dann arbeiten und den Rest davon ableiten. Solange ich diese Bezugszeit nicht flexibel von außen mitgeben kann, ist das alles nur Basteln auf hohem Niveau. Es soll einfacher werden durch die neue Lösung, sonst lohnt es nicht.

[FrankOverIP]

Wichtig wäre keine zusätzlichen KOs zu verwenden, aber bei Zeitschaltuhrkanälen stehen die zwei Eingangs-KOs ja zur Verfügung.

Solange ich das nicht selbst mal gesehen habe, ist eine Diskussion darüber vermutlich müßig. Aber meine Vorstellung wäre genau, dass ich einen Eingang habe für eine Referenzzeit - danach kann dann sogar so etwas wie eine Treppenlichtfunktion ausreichend sein. Feiertage und Urlaubstage sind im ZSU-Modul ja offenbar bereits drin.

[coko]

Ich möchte eine Bezugszeit, die von außen kommt - eine beliebige Uhrzeit. Damit kann ich dann arbeiten und den Rest davon ableiten.

Wo soll die Uhrzeit denn herkommen? Mir ist spontan kein KNX-Gerät bekannt, das Zeiten auf den Bus senden kann, die nicht der aktuellen Uhrzeit entsprechen. Kann es natürlich geben (DPTs für sowas existieren), aber wäre nach meinem Eindruck eher exotisch. Es braucht dann auch eine genaue Verhaltensdefinitionen: Soll die Uhrzeit immer nur für den nächsten Tag genutzt werden, oder auf Dauer bis zum nächsten Update? Wie soll mit den angegebenen Wochentagen umgegangen werden? Zeit gibt es auf dem Bus (DPT10 und DPT19) nur in Kombination mit einer Wochentagangabe, auch wenn man die weggelassen werden kann. Bei Zeitangabe mit heutigem Wochentag darf das nicht einfach dazu führen, dass morgen etwas passiert. Bei DPT19 ergeben sich noch weitere Fragestellungen, die geklärt werden müssen wenn man sowas sauber umsetzen will.

es macht ein simples Problem zu einer ziemlich komplexen Konfiguration

Ich sehe das nicht als so komplex. Du bräuchtest: Funktionsblock Count-Down mit Start durch Minuten-Vorgabe, Logik-Kanal 1 als ZSU, Logik-Kanal 2 mit Tor getriggert durch Kanal 1 zur Weitergabe des voreingestellten Offsets an den Count-Down, Ggf. Logik-Kanal3 zum Vorhalten des Minuten-Offsets inkl. Speicher-Möglichkeit. Verstellen des Minuten-Offsets über z.B. MDT GT2 mit Wert senden / Wert verschieben erlaubt dann ein direktes Einstellen der Verzögerung über einen Zeitraum von über 4 Stunden. Natürlich nicht so intuitiv mit der Einstellung auf Minuten-Ebene, aber etwas was jetzt schon relativ schnell umsetzbar wäre mit dem Raumcontroller. Schneller als eine entsprechende Erweiterung zu implementieren.

Ergänzung: Bei Umsetzung der Offset-Verstellung über einen Zustandsautomaten wäre sogar noch die Anzeige der Konfiguration als Uhrzeit möglich (über Text). Damit wäre es intuitiver in der Bedienung.

[gbglace]

Naja wer behauptet das die Referenzzeit vorgabe aus dem KNX kommen muss.

Sowas wie der TwS ist ja jetzt nicht das Gespräch chte Kaliber. Aber in dem dortigen ZSU Modulen kann man als Input einen quasi CRON String über geben.

Wenn dort der Bezug zu den Tagen fix definiert ist, bleibt die Definitive in der Stunde/Minute/Sekunde. Diese Teil Strings lassen sich auch in Visuelementen verstellen und dann wird das in der ZSU als Zeit angenommen.

Ab der ZSU hat man dann ja alle Freiheit mit einfachen Verzögerungen die nachfolgenden Sequenzen abzubilden. Der Startpunkt ist dann aber i der Visu flexibel.

[FrankOverIP]

Sowas wie der TwS ist ja jetzt nicht das Gespräch chte Kaliber. Aber in dem dortigen ZSU Modulen kann man als Input einen quasi CRON String über geben.

Ich musste jetzt erstmal schauen, wofür wohl TwS steht - das ist ein Timberwolf-Server, ja? Mal unabhängig von Preisschild, wäre eine CRON-artige Definition absolut geeignet, meine Anforderung zu erfüllen. Bei den 800 Euro bekomme ich zwar Schnappatmung, aber gäbe es diesen CRON-String als KO? Könnte ich den also aus beliebigen (KNX-fähigen) Umgebungen beschreiben?

[gbglace]

Ja das TWS steht für Timberwolf Server.

Naja bei sowas wie X1 und anderen Server-Lösungen gibt es natürlich sehr ähnlich mächtige Lösungen mit dann ähnlichen Preistickets. Für eine reine ZSU Lösung muss der Schmerz dann schon groß sein für ein solches Invest. Aber Haben ist immer besser als brauchen ;-).

Nur eben ganz nativ als kleines KNX-Bauteil für an der quasi 100 EUR Klasse oder weniger, ist das Scenario so derzeit nicht abbildbar.

[CaptainFuture]

Wie wäre denn https://github.com/XKNX/xknx mit cron? So ein Python-Script ist in 5 Minuten hingeschrieben und in cron eingehängt. Betriebssystem und Hardware Deiner Wahl, das einzige was Du sonst noch brauchst ist ein KNX-IP-Router oder -Koppler, aber den gibt es garantiert schon.
Logik im handwerklichen Sinne eines Programmierers ist bei KNX "in Hardware" immer nur als Krücke abbildbar. Und teuer. Entweder Du steigst auf ein SPS-ähnliches System um (leider alles ziemlich proprietär und halt auch wieder etwas "beschränkt"), oder Du machst es in Python selbst.
Alternativ wäre natürlich noch OpenHAB oder HA zu nennen, wenn Du mit FHEM nicht prinzipiell unzufrieden warst.