Werte aus MDT Zeitschaltuhr ohne zyklisches Senden

[maxheld83]

Ich wollte mir mit einer MDT Zeitschaltuhr Zirkadianische Beleuchtung (unterschiedliche Farbtemperatur in Abhängigkeit vom Sonnenstand) auf meinen MDT LED Aktoren einrichten. (Das "native" Human-Centered Lighting (HCL) in den MDT LED Aktoren hat einen Nachteil, dazu unten -- hier aber nicht weiter relevant).

Dazu habe ich in der Zeitschaltuhr ein entsprechendes Programm eingerichtet, was via "Wert senden" die passende Farbtemperatur auf den Bus sendet. Der LED Aktor liest das dann von einer gemeinsamen GA.

Soweit so gut; wenn der LED Aktor durchgehend anbleibt, funktioniert das auch wie am Schnürchen.

Das Problem entsteht, wenn der LED Aktor eine Zeitschalt "verpasst", und danach angeschaltet wird. Dann ignoriert er die laut Zeitschaltuhr gültige Farbtemperatur, und startet mit was auch immer als "Einschaltverhalten" im LED Aktor hinterlegt ist (etwa: "Letzter Wert/Sequenz").
Das kann hässliche Folgen haben, etwa wenn der LED Aktor zuletzt kaltweiß war, und es aber spät abends ist. Dann ist man wieder wach .

Ich habe den LED Aktor Eingang für die Farbtemperatur in der GA mit "KSA" gesetzt, den Zeitschaltuhr Ausgang mit "KLÜ".

Ich dachte mir, das müsste dafür sorgen, dass der LED Aktor beim einschalten mit einem Telegramm "GroupValueRead-Telegram" bei der Zeitschaltuhr nachfragt, was wohl gerade der gültige/letzte Wert für die Farbtemperatur ist.

Das scheint aber nicht der Fall.

Ich habe einen Workaround gefunden, aber schön ist der nicht (s.u.) -- und irgendwie beschleicht mich das Gefühl, das ich etwas falsch mache oder falsch verstehe.

Wie kann ich den *letzten* Wert der Zeitschaltuhr bei einem (bisher) ausgeschalteten Aktor abgreifen?

Ps: Workaround ist, dass ich die Zeitschaltuhr den Wert alle Minute zyklisch senden lasse, sowie (!) zusätzlich das "native" HCL im LED Aktor angeschaltet habe. So gibt's zumindest kein hartes Erwachen mit kaltweiss. Aber es dimmt trotzdem blöd rum und ausserdem ist jetzt quasi die Farbtemperatur an *zwei* stellen definiert, was Murks ist.
Pps.: Warum nicht nur das native HCL aus dem LED Aktor nehmen? Das bietet leider nur Farbtemperatur-Dimmung nach Uhrzeit oder nach Sonnenstand. Dummerweise passt beides nicht so wirklich, weil man etwa mit Sonnenstand im Winter bis 11:00 morgens bei warmweiss rumdümpeln würde. Die MDT Zeitschaltuhr bietet ein sehr praktisches "nach Sonnenaufgang aber frühestens/spätestens bis xx:xx Uhr". Das passt perfekt.

[gbglace]

Der LED Aktor liest das dann von einer gemeinsamen GA.

Sowas passiert nicht im KNX.

Der Aktor bekommt es mit einem Telegramm mit der GA geliefert, sofern die ZSU es auch aktiv sendet (Ü) Flag gesetzt.

Ich dachte mir, das müsste dafür sorgen, dass der LED Aktor beim einschalten mit einem Telegramm "GroupValueRead-Telegram" bei der Zeitschaltuhr nachfragt, was wohl gerade der gültige/letzte Wert für die Farbtemperatur ist.

Das scheint aber nicht der Fall.

Nein das macht kein KNX Gerät so.

Es gibt ein I Flag, wenn man das setzt dann fragt ein Gerät nach einem Reboot aktiv auf dem Bus per Lesetelegramm und bekommt dann vom ZSU gerät, welches das L-Flag hat den dort zuletzt bekannten wert als Antwort gesendet und kann dann wegen dem A-Flag diese Antwort auch in sich aufnehmen. Denn S >> ich interessiere mich für reguläre group Value write telegramme, A >> ich interessiere mich für GroupValue Response Telegramme.

Mit nur diesen beiden Geräten, wirst nur diese beiden Workarounds realisiert bekommen.

Du wirst dann aber noch eine Erweiterung benötigen.

Also die GA mit dem Farbtemperaturwert hat die Verbindung an der ZUS, dem Aktor und einer weiteren Logik.

Die Logik ist dann so eine Art TOR, wenn der EIN-Befehl zum Aktor kommt, geht das auch auf diese Logik und diese sendet dann quasi bedarfsgerecht den letzten Farbtemperaturwert nochmal raus.

[gbglace]

Der LED Aktor liest das dann von einer gemeinsamen GA.

Sowas passiert nicht im KNX.

Der Aktor bekommt es mit einem Telegramm mit der GA geliefert, sofern die ZSU es auch aktiv sendet (Ü) Flag gesetzt.

Ich dachte mir, das müsste dafür sorgen, dass der LED Aktor beim einschalten mit einem Telegramm "GroupValueRead-Telegram" bei der Zeitschaltuhr nachfragt, was wohl gerade der gültige/letzte Wert für die Farbtemperatur ist.

Das scheint aber nicht der Fall.

Nein das macht kein KNX Gerät so.

Es gibt ein I Flag, wenn man das setzt dann fragt ein Gerät nach einem Reboot aktiv auf dem Bus per Lesetelegramm und bekommt dann vom ZSU gerät, welches das L-Flag hat den dort zuletzt bekannten wert als Antwort gesendet und kann dann wegen dem A-Flag diese Antwort auch in sich aufnehmen. Denn S >> ich interessiere mich für reguläre group Value write telegramme, A >> ich interessiere mich für GroupValue Response Telegramme.

Mit nur diesen beiden Geräten, wirst nur diese beiden Workarounds realisiert bekommen.

Du wirst dann aber noch eine Erweiterung benötigen.

Also die GA mit dem Farbtemperaturwert hat die Verbindung an der ZUS, dem Aktor und einer weiteren Logik.

Die Logik ist dann so eine Art TOR, wenn der EIN-Befehl zum Aktor kommt, geht das auch auf diese Logik und diese sendet dann quasi bedarfsgerecht den letzten Farbtemperaturwert nochmal raus.

[maxheld83]

Danke für die tolle Antwort 🙏 @gbplace.

Es gibt ein I Flag, wenn man das setzt dann fragt ein Gerät nach einem Reboot aktiv auf dem Bus per Lesetelegramm und bekommt dann vom ZSU gerät, welches das L-Flag hat den dort zuletzt bekannten wert als Antwort gesendet und kann dann wegen dem A-Flag diese Antwort auch in sich aufnehmen. Denn S >> ich interessiere mich für reguläre group Value write telegramme, A >> ich interessiere mich für GroupValue Response Telegramme.

Das ist das "Lesen bei Init" Flag, richtig?
Das scheint der LED-Dimmaktor leider nicht zu bieten (schätze, der würde das brauchen).

Verwandtes Thema: Wo kann ich nachlesen/verstehen wann ein Aktor (wie etwa wohl der ausgeschaltete LED-Dimmaktor) ausschaltet bzw. "rebooted"?
Ich hätte jetzt vermutet, dass das nur bei Busspannungsverlust o.ä. passiert, aber nicht wenn einfach nur der Aktor auf "AUS" geschaltet ist.

[maxheld83]

Mit nur diesen beiden Geräten, wirst nur diese beiden Workarounds realisiert bekommen.

Du wirst dann aber noch eine Erweiterung benötigen.

Also die GA mit dem Farbtemperaturwert hat die Verbindung an der ZUS, dem Aktor und einer weiteren Logik.

Die Logik ist dann so eine Art TOR, wenn der EIN-Befehl zum Aktor kommt, geht das auch auf diese Logik und diese sendet dann quasi bedarfsgerecht den letzten Farbtemperaturwert nochmal raus.

Das habe ich noch nicht verstanden.

Du meinst:

1. GA für Dimmaktor Schalten sollte den Ein/Aus Wert noch an ein XOR Logik-Gate Eingang senden?
2. Dieses Logik-Gate hat dann als Output einen Schaltbefehl (?) an die ZSU um nochmal bedarfsgerecht die Farbtemperatur auszugeben.
3. Wegen dem `A`-Flag auf dem Dimmaktor würde dieser dann das `GroupValue Response` Telegramm beachten, und die Farbtemperatur entsprechend implementieren.

Soweit richtig verstanden gbglace?

Das wäre ja eine elegante (fast) "richtige" Lösung.

Ich habe zwar ein paar freie Logik-Blocks (in der ZSU), allerdings scheitere ich an 2). Das Zeitschaltprogramm mit der Farbtemperatur hat keinen Schalteingang um nochmal die Farbtemperatur zu senden o.ä.

Will deine Geduld nicht überstrapazieren gbglace -- wo stehe ich da auf dem Schlauch?

[gbglace]

Ich bin mit den richtigen Logik begriffen auch nicht so firm. Es muss eine Logik sein die einfach immer ohne aktiv zu werden die Wertänderungen von der ZSU aufnimmt. aber nur wenn der EIN-Befehl kommt dann schickt es genau diesen Wert raus.
Damit reduziert man die telegrammlast weil eben keine aktive Leseanfrage an die ZSU geht und Antwort von dieser. Der Ausgang der ZSU hat dann also den Aktor, und diese neue Logik als Empfänger.

Der Aktor nimmt den Wert der ZSU aber nur zur Kenntnis wenn der Kanal EIN ist. Die neue Logik soll ihn immer passiv in sich aufnehmen und dann selbst aktiv weiter reichen wenn das EIN vom Lichtschalter oder sonst wo herkommt.

die Logik braucht also zwei Eingänge einen binären als Trigger und einen im Format der Farbtemperatur und einen Ausgang im Format der Farbtemperatur.

[mumpf]

Falls es DIY sein darf: Genau so was kann das OpenKNX Logikmodul machen. Genauer gesagt, die TOR-Logik.

Insofern lagst Du, Göran, mit den Begriff sehr gut...

Gruß, Waldemar

[maxheld83]

ch bin mit den richtigen Logik begriffen auch nicht so firm. Es muss eine Logik sein die einfach immer ohne aktiv zu werden die Wertänderungen von der ZSU aufnimmt. aber nur wenn der EIN-Befehl kommt dann schickt es genau diesen Wert raus.
Damit reduziert man die telegrammlast weil eben keine aktive Leseanfrage an die ZSU geht und Antwort von dieser. Der Ausgang der ZSU hat dann also den Aktor, und diese neue Logik als Empfänger.

danke gbglace jetzt habe ich es verstanden.

Die Logik-Blöcke in der ZSU bieten leider den entsprechenden Wert (2-Byte) für die Kelvin Farbtemperatur nicht als Ausgang, deshalb kann ich das vorläufig nicht umsetzen.
Da muss ich mich nach einem anderen Logik Bauteil umschauen.

Scheint so als ob der "richtige" Logik Block von MDT das unterstützt.

Oder natürlich das OpenKNX Modul wie von mumpf erwähnt!