KNX GA Remanent bzw Rollosperre an MDT Aktor

[gulp2k]

Hallo zusammen,

ich bastele an den Rollläden und hab bei mir überall MDT Aktoren dafür.
Leider hatte ich jetzt schon ein paar mal "komisches" Verhalten wie Rollläden gehen nachts auf usw. und das hat den WAF ziemlich reduziert...

Im Aktor kann ich die Rollläden sperren und würde das jetzt abends nachdem die Rollläden alle unten sind machen bis zum nächsten Morgen.
Problem ist das ich kein Status Objekt für die Sperre habe und nicht sicher bin wie ich den Status am besten überwache.

Es geht mit dabei auch z.B. darum das Edomi nach einem Neustart noch weiß ob gesperrt oder nicht.

Folgende Szenarien hab ich mir überlegt:

1. Pro Rolladen ein Remanentes KO, eventuell Periodisch (z.B. Rolladen hoch am Morgen) entsperren.
2. KNX GA für die Sperre mit tracken
3. ?

Irgendwie wär es mit am liebsten das ich die KNX GA irgendwie remanten machen könnte aber das ist ja leider nicht möglich.

Hat noch jemand Ideen dazu?

[baumhaus123]

Hi,

ich habe die MDTs nicht - aber bei einem anderen Aktor hat es bei mir geholfen, beim Sperrobjekt in der ETS einfach das L-Flag zu setzen. Damit kann ich nun den Sperr-Zustand lesen (ist quasi der zuletzt gesetzte Wert) und ggfls. darauf reagieren, funktioniert bisher problemlos. Kannst es ja mal ausprobieren...

[jonofe]

Welcher Aktor ist es denn genau? Die meisten MDT Aktoren haben doch ein Objekt Status Sperre, wenn ich mich richtig erinnere.
Ansonsten würde ich auch das L-Flag setzen und per Initscan bei Projektaktivierung abfragen. KNX GAs remanent macht keinen Sinn, denn EDOMI sollte den echten Status auf dem Bus kennen und den bekommt man für KNX GAs nut per Read-Request.

[hjk]

Ein Sperren über Nacht ist natürlich nicht notwendig. Wenn die Rollladen nachts hochfahren, hat das einen Grund. Der ist zu korrigieren.
Eine Ursache kann z.B. ein Windalarm sein, wo die Überwachungszeit zu knapp eingestellt ist. Ich würde die Telegramme aufzeichen und den Fehler suchen.
Wenn es die 2. Generation ist, auch die Diagnoseobjekte aktivieren.

[gulp2k]

Hi,

ich habe die MDTs nicht - aber bei einem anderen Aktor hat es bei mir geholfen, beim Sperrobjekt in der ETS einfach das L-Flag zu setzen. Damit kann ich nun den Sperr-Zustand lesen (ist quasi der zuletzt gesetzte Wert) und ggfls. darauf reagieren, funktioniert bisher problemlos. Kannst es ja mal ausprobieren...

Das mit dem L-Flag währe natürlich die beste Lösung.

Welcher Aktor ist es denn genau? Die meisten MDT Aktoren haben doch ein Objekt Status Sperre, wenn ich mich richtig erinnere.
Ansonsten würde ich auch das L-Flag setzen und per Initscan bei Projektaktivierung abfragen. KNX GAs remanent macht keinen Sinn, denn EDOMI sollte den echten Status auf dem Bus kennen und den bekommt man für KNX GAs nut per Read-Request.

Sind JAL-0810. Haben auch Status Objekte für so ziemlich alles außer der Sperre.

Ein Sperren über Nacht ist natürlich nicht notwendig. Wenn die Rollladen nachts hochfahren, hat das einen Grund. Der ist zu korrigieren.
Eine Ursache kann z.B. ein Windalarm sein, wo die Überwachungszeit zu knapp eingestellt ist. Ich würde die Telegramme aufzeichen und den Fehler suchen.
Wenn es die 2. Generation ist, auch die Diagnoseobjekte aktivieren.

Das die nicht grundlos fahren ist mir schon klar. Liegt natürlich an meiner Logik aber nachts um 3 will ich die nicht debuggen.
Da soll die lieber machen was Sie will und die Rollläden bleiben einfach wo sie sind.

[jonofe]

Sind JAL-0810. Haben auch Status Objekte für so ziemlich alles außer der Sperre.

Was ist mit KO 34 Status Sperre/Alarme?

[gulp2k]

Was ist mit KO 34 Status Sperre/Alarme?

Ich nehme alles zurück und behaupte das Gegenteil!

Hab ich doch glatt übersehen... Hab nur auf der Sperrseite geschaut und da nichts gefunden.

[WagoKlemme]

Das die nicht grundlos fahren ist mir schon klar. Liegt natürlich an meiner Logik aber nachts um 3 will ich die nicht debuggen.
Da soll die lieber machen was Sie will und die Rollläden bleiben einfach wo sie sind.

Monitorlog gäbe es auch, da steht mit Sicherheit der Übertäter.
Blinder Aktionismus an der Wirkung halte ich für kontraproduktiv, spätestens dann wenn nützliche Funktionen arbeiten sollen.
Deshalb bin ich exakt der Meinung von hjk .
Ich hatte kürzlich ein Problem in einer Logik. Nach Stunden der Fehlersuche, habe ich dann bemerkt, dass ich dummerweise die falschen Ausgangsboxen kopiert hatte !=0 statt !=leer. Da kommt dann halt auch die 0 nicht durch.