MDT Jalousieaktor Lüftungsfunktion - Problem bei einem Fenster

[musikfipsi2003]

Hallo zusammen,

Zuerst am Besten ein wenig Hintergrundinfo:
Wir haben letztes Jahr unser Haus fertiggestellt und unter anderem habe ich für die Rollläden am Jalousieaktor (MDT 0810.02) die Lüftungsfunktion aktiviert. Wenn das Fenster bereits offen war und der Rollladen runtergefahren wurde (auf 100%) dann dauerte es max. 20 sec (Binäreingang sendet zyklisch alle 20sec) und der Rollladen fuhr automatisch zurück auf 80%. Das hat 10 Monate lange tadellos funktioniert. Vor kurzem hatte der Energieversorger bei uns in der Einfahrt einen Kabelbrand, was leider einen Überspannungsschaden zur Folge hatte. Ich musste einen Dimmaktor und eben auch diesen Jalousieaktor tauschen. Nach Einbau des neuen Aktors (auch MDT 0810.02) habe ich einfach die Physikalische Adresse und das Applikationsprogramm hochgeladen.

Nun zum Problem:
Seitdem funktioniert die Lüftungsfunktion bei EINEM Fenster (Kanal F) nicht mehr. Wenn das Fenster offen ist und der Rollladen runter gefahren wird auf 100%, dann dauert es normal wie oben schon beschrieben max. 20sec und der Rollladen sollte zurück auf 80% fahren. Bei ALLEN außer diesem Fenster funktioniert das auch noch tadellos. Aber bei diesem einen Fenster funktioniert es immer nur beim ersten Mal, nachdem ich das Applikationsprogramm neu hochgeladen habe. Danach nicht mehr. Der Binäreingang sendet lt. Gruppenmonitor den Status "Fenster offen" alle 20sec auf den Bus.
Man muss dann das Fenster schließen und nochmal öffnen, dann fährt der Rollladen auf 80%.

Kann sich jemand von euch dieses Verhalten erklären?

Danke!

[Kaffeetrinker]

Müsste jetzt in den Parametern der Lüftungsfunktion schauen. Gibt es da eine Einstellung wie Aktion nur bei Wertänderung? Oder so. Vielleicht mal aus versehen angeklickt. Muss ja eigentlich am Kanal F liegen

[musikfipsi2003]

Gerade nachgeschaut, gibt es dort leider nicht, habe Kanal F nochmal mit Kanal G verglichen (bei G funktioniert alles einwandfrei). Es gibt keinerlei Unterschied in der Parametrierung.
Komisch finde ich folgendes Verhalten. Das Fenster ist offen und der Kontakt/Binäreingang sendet das auch zyklisch alle 20sec. Der Rollladen bleibt aber unbeeindruckt bei 100%. Wird das Fenster nun geschlossen (Kontakt/Binäreingang sendet 1) und danach wieder geöffnet (Kontakt/Binäreingang sendet 0) dann fährt der Rollladen auf 80%. Als ob ihn die zyklische Meldung gar nicht interessieren würde...
Habe in der Zwischenzweit auch eine Aktualisierung der Applikation gemacht (hatte vorher noch 3.1 und jetzt die neuere 3.4). Hat leider auch nicht geholfen...

[Beleuchtfix]

Und du programmierst auch die komplette Applikation, nicht nur pattiell? Du kannst auch Kanal F und G gleichzeitig einstellen (STRG Taste drücken beim Anklicken) dann zeigt er nur die Parameter an, die identisch sind. Vielleicht findest du doch nich etwas.

Viel Erfolg Florian

[musikfipsi2003]

Ok, vielen Dank für eure Unterstützung, aber der MDT Support hat mir mitgeteilt, dass dieses Verhalten in der neuen Hardwareversion (ich habe seit dem Tausch R5.1) so gewünscht ist. Mir fiel nicht auf, dass sich die Hardwareversion beim Tausch geändert hat. Dass es nur bei diesem einen Kanal aufgetreten ist war purer Zufall. Wenn ich den Supportmitarbeiter richtig verstanden habe, dann werden absolute Positionen intern gesperrt, bis einmal ein "Zu-Signal" vom Fensterkontakt kommt. Wir konnten es dann per Fernwartung bei anderen Rollläden am gleichen Aktor nachstellen. Bei dem einen wo ich dachte dass es funktioniert ist es so, dass er nach wie vor auf einem Aktor der alten R4.x hängt. Um das Verhalten wiederherzustellen werde ich nun entweder auf eine Logikfunktion ausweichen, oder ich muss mir bei den Parametern die Variante mit 2 FK (geöffnet/gekippt) probieren. Hier wurde mir gesagt, dass er im Fall von gekippt die absoluten Positionen nicht sperren sollte.
Persönlich finde ich es nicht sinnvoll, dass das geändert wurde, weil wenn ein Fenster bereits offen ist und der Rollladen fährt auf 100% - zb. weil ich vom Tablet im Wohnzimmer alle Rollläden schließen will, oder weil eine Automatikfunktion das so macht - will ich doch als Benutzer, dass der Raum weiter belüftet wird. Es kann doch nicht sein, dass ich dann extra in den Raum gehen muss um das Fenster zu schließen oder zu öffnen nachdem der Rollladen zugemacht wurde. Die Denkweise erschließt sich mir nicht so ganz, weil es ja Lüftungsfunktion heißt aber gut...

[hjk]

Wenn ich den Supportmitarbeiter richtig verstanden habe, dann werden absolute Positionen intern gesperrt, bis einmal ein "Zu-Signal" vom Fensterkontakt kommt.

Das passiert nur, wenn die Fensterkontakte unüblich eingestellt sind. Normal Fenster zu Wert 0 und Fenster auf Wert 1.
Wenn das genau umgekehrt (unüblich) ist, ist intern das Fenter auf, da der Aktor nach Neustart eine 0 auf das Objekt hat.
Bei üblicher Programmierung (Fenster zu Wert 0), tritt das nicht auf. Wenn der Fensterkontakt zyklisch sendet, kommt der richtige Zustand nach der Zykluszeit.

Wie ist das Verhalten wenn Fenster offen eingestellt? Da wird ja die abs. Sperre aktiviert sein. Du kannst die abs. Sperre auch rausnehnem.
Vielleicht habe ich das Problem aber auch nicht richtig verstanden.

[evolution]

Normal Fenster zu Wert 0 und Fenster auf Wert 1.

Du meintest das bestimmt anders herum? Denn üblich ist verschlossen = 1 und geöffnet = 0.

[hjk]

Ich kenne das nur mit offen = 1.
Häufig wird das auch für die normale Sperrfunktion benötigt, 1 = gesperrt/Aussperrschutz.

[evolution]

Verschlossen = 1 ergibt sich aus dem Sicherheitgedanken, dass der Zustand aktiv zurückgemeldet werden muss und jeder unbestimmte Zustand nicht diesem Zustand zugeordnet werden darf. Praktisches Beispiel ist ein Neustart des Systems; so wird das Fenster so lange als offen gewertet, bis die Auswertung (des Binäreingangs) eine aktive Verschluss-Meldung zurückgibt. Auch ist das technisch so gelöst, indem der Reed-Kontakt erst mit dem Verschließen (Magnet über dem Reed-Kontakt) geschlossen wird, was ein zusätzlicher Schutz gegen Manipulation darstellt. Der Binärkontakt wertet dann also bei einem verschlossenen Fenster eine 1 aus und so sollte man das auch weiterhin behandeln, um die Auswertung des sicherheitsrelevanten Verschlussstatus aufrecht zu erhalten - denn eine 0 kann auch ein unbestimmter Zustand sein. Das ist im übrigen bei allen gängigen Fensterkontakten exakt so umgesetzt.
Beim Kippen des Fensters ist es gerade anders herum. Hier wird meist (aber leider nicht immer) eine 1 für den Gekippt-Status ausgegeben, da nicht sicherheitsrelevant.

[BadSmiley]

Logisch ist Fenster zu = 1, da elektrisch gesehen auch ein high anliegt. Im KNX werden Trigger/Events mit einer 1 ausgelöst. I. D. R. Soll bei einem geschlossenen Fenster nichts passieren, also ergibt dies eine 0. Bei geöffnet Fenster soll der Rollo gesperrt werden an der Türe = 1, die Heizung auf Frostschutz gehen = 1 usw. Eine sperre ist bei einer 1 aktiv. Ansonsten wurde man mit einer Freigabe arbeiten. Ich kenne die Handhabung in vielen Visualisierungen auch nur so, das eine 1 ein geöffnetes Fenster anzeigt und einen 0 ein geschlossenes. Da sind sich die Hersteller alle ziemlich einig.

[hjk]

Verschlossen = 1 ergibt sich aus dem Sicherheitgedanken, ...

Ja, bei Alarmanlagen wird das so gemacht.
Standard ist aber 1 = Sperrfunktion = offen. Ansonsten wird das ohne externe Logik bei kaum einem Aktor auf dem Markt funktionieren.
Aber das ist hier auch nicht das Kernthema.

[evolution]

Ja, bei Alarmanlagen wird das so gemacht.

Und dieses Prinzip ist natürlich auch auf KNX-Anlagen übertragbar.

Standard ist aber 1 = Sperrfunktion = offen. Ansonsten wird das ohne externe Logik bei kaum einem Aktor auf dem Markt funktionieren.

Eure Jalousieaktoren bieten doch gerade die Möglichkeit die Sperren mit 0 oder 1 zu definieren.
Sperrfunktion MDT Jalousieaktor.PNG
Das ist doch gerade ein weiterer Vorteil, den Ihr mit Euren Jalousieaktoren bietet...

Aber das ist hier auch nicht das Kernthema.

Genau. Soll jeder machen, wie er es für richtig hält.

[musikfipsi2003]

Hallo an alle und erstmal danke für die rege Beteiligung. Ob der FK nun verkehrt herum arbeitet oder nicht sollte doch in meinem Szenario grundsätzlich egal sein, denn ob jetzt bei offenem Fenster eine 1 oder eine 0 kommt kann ich ja am Binäreingang einstellen.
Es ist halt einfach so, dass es in der R4.x noch super funktioniert hat und in der R5.x nicht mehr. Der Ablauf im Gruppenmonitor ist bei meinem Szenario folgender:
1. Fenster ist zu, Binäreingang sendet 1 zyklisch alle 20sec
2. Fenster wird irgendwann geöffnet, BE sendet ab sofort zyklisch 0 weil offen
3. Rollladen wird runter gefahren
4. Rollladen meldet Status 100%
5. Irgendwann kommt dann die zyklische Meldung vom BE mit 0 weil offen
6. Rollladen fährt retour auf Lüftungsposition, meldet Status 80%
7. Rollladen wird hoch gefahren
8. Rollladen meldet Status 0%
BIS HIER HAT ALLES FUNKTIONIERT WIE ES SOLL. ABER DAS FENSTER IST NOCH IMMER OFFEN:
9. Rollladen fährt runter
10. Rollladen meldet 100%
11. BE sendet zyklisch wieder seine 0 weil nach wie vor offen
12. Rollladen macht nichts, weil zwischendurch das Fenster nie geschlossen wurde, laut neuer R5.x das aber zwischendurch der Fall sein MUSS.

Ich habe auch leider auch keine zwei FKs pro Fenster verbaut, weil mir das zu übertrieben vorkam. Rechtlich gesehen ist ja auch ein gekipptes Fenster ein offenes... Viellicht gibt es Anwendungen wo man das differenzieren will, aber für meine einfache Lüftungsfunktion sollte es eigentlich reichen.

Und grundsätzlich sehe ich das mit den 0/1 bei offen/verschlossen gleich wie Evolution. Das sind Kontakte die direkt von Internorm verbaut wurden und das stand auch so beschrieben, dass die 1 für ein geschlossenes Fenster und die 0 für ein offenes steht. Mir wurde das dann auch im Zusammenhang mit dem Sabotageschutz erklärt, falls mal jemand das Kabel durchschneidet oder so...

Aber nochmal: Für mich ist diese Anpassung in der neuen R5.x einfach nicht nachvollziehbar. Zumindest aus Sicht des Endanwenders denn es handelt sich bei dem Parameter ja auch um die Lüftungsfunktion

[ewfwd]

Aber das ist hier auch nicht das Kernthema.

Auch wenns nicht das Kernthema ist aber ich habe folgende Ideen noch für ein eventuelles Update des Aktors:
1. Für Auf/Ab Zentralfunktion ne Verzögerung für die einzelnen Kanäle dass die Relais nicht alle komplett gleichzeitig schalten
2. Eine Art "Feueralarm" wäre hilfreich, sprich ein Objekt worüber man die Rolladen hochfahren könnte, welches die aktuellen Sperren aber ignoriert, bzw Einstellbares Verhalten ob dieses Objekt die Sperre ignoriert oder nicht.

[hjk]

In der neuen aktuellen Datenbank gibt es einen Brandalarm. Der wird über die Alarmpriortät aktiviert und hat immer die höchste Prio.
Wird der Brandalarm aktiviert, fällt der Regenalarm weg.
Funktioniert mit allen Geräten der 2. Generation.

Was bringt die Verzögerung der Kanäle bei der Zentralfunktion?