KNX/EIB Auffälligkeiten bei Lüftungsfunktion mit MDT Jalousieaktor

[GKap]

Hallo Leute!

Ich habe unlängst MDT Jalousieaktoren JAL-0810.02 in Betrieb genommen. Dabei ist mir folgendes aufgefallen:

Lüftungsfunktion mit 2 Kontakten bei Rollladen, Kundenwunsch ist:
Fenster gekippt: Lüftungsstellung (d.h. 90%, so dass die Schlitze aufgehen)
Fenster geöffnet: ganz auf
Fenster geschlossen: Stellung wie vorher
Grundsätzlich funktioniert das auch, allerdings gibt es eine Unschönheit:
Die Fenster haben Verschluss- und Kippkontakte. Wird der Griff langsam von der Stellung nach unten auf wagrecht und dann weiter nach oben zum Kippen gedreht, passiert folgendes: Die Rollladen fahren ganz nach oben und danach auf 90%.
Wird der Griff schnell von "Zu" auf "Kipp" gedreht, fahren die Rolladen gleich auf 90%.
Ist ja auch logisch, da der Verschlusskontakt als erstes anspricht. Hier fehlt m.E. im Aktor ein einstellbares Timeout, so dass man genügend Zeit hat, den Griff nach oben zu drehen!

Bei Raffstores ist das Verhalten sinngemäß gleich.

Wenn die Beschattung aktiv ist, dann erfolgt auch bei sehr schnellem Drehen des Griffes von "Zu" auf "Kipp" die unerwünschte Fahrt nach oben und wieder runter.

Weiters ist m.E. ungünstig, dass solche Fahrten nicht unterbrechbar sind. D.h. wenn man ein Fenster öffnet und gleich wieder schließt, erfolgt trotzdem eine vollständige Fahrt nach oben und wieder nach unten!

Lässt sich dieses Verhalten verbessern?

Gruß
GKap

[hjk]

Da ist was faul mit den Binäreingängen. Die Kontakte werden intern 1s verzögert und dann ausgewertet. Das reicht auch für eine langsame Bedienung. Anscheinend werden die Kontakte verzögert gesendet. Das kann man im Gruppenmonitor sehen.
Wenn alles richtig eingestellt ist, gibt es kein Problem.

[DerStandart]

Bei mir ist es anders, aber vergleichbar:
Wenn ich den Griff von "Zu" auf "Auf" stelle und dann das Fenster öffne, dann gibt es in dem Moment, wo der Griff" auf "Auf" ist, der Fensterflügel aber noch nicht geöffnet ist, den Zustand, dass nur ein Binäreingang "offen" meldet. Es ist dann also so, dass der Rollladen erstmal auf 85% fährt, kurz pausiert und dann weiter auf 0% fährt.
Es ist mir noch nie aufgefallen, aber wenn ich das Fenster wirklich innerhalb von einer Sekunde öffne, also beide Binäreingänge innerhalb von einer Sekunde den Zustand melden, dann fährt es sofort ohne Unterbrechung ganz nach oben. Kommt bei der realen Bedienung hier aber nur sehr sehr selten vor.

Ich habe noch einen anderen Fehler entdeckt.
Ich habe SOC aktiviert. Nehmen wir an, der Rollladen ist oben. Fenster wird geöffnet und nach 10 Sekunden wieder geschlossen. Nach weiteren 5 Sekunden wird ein Fahrbefehl geschickt. Dieser wird, wenn er innerhalb der theoretischen Fahrzeit kommt, vom Aktor aber nicht als Fahrbefehl, sondern als Stop interpretiert. Wunderschön zu sehen am Diagnoseobjekt. Dieses sendet "Window Close". Nachdem der Fahrbefehl kommt, sendet es "Stop". Das hat zur Folge, dass die Fahrt nicht ausgeführt wird und man noch mal den Fahrbefehl senden muss. Diesbezüglich bin ich noch mit dem Support in Kontakt.

Und, wo wir schon dabei sind:
Nach einem normalen Fahrbefehl stehen die Diagnoseobjekte in sehr vielen Fällen auf "Abs Lock", anstatt auf "Up" oder "Down". Das Diagnoseobjekt ist also - was das angeht - unbrauchbar. Ich kann nie unterscheiden, ob zuletzt die absolute Position gesperrt oder ein Fahrbefehl ausgeführt wurde. Die ist laut MDT Support normal.

[Burgerking]

Morgen, darf ich mich einklinken?

Bei einem Kanal funktioniert die Lüftungsfunktion nicht, obwohl genau eingestellt wie alle anderen:

Und zwar fährt der Raffstore wie gewollt beim öffnen auf 25%, aber wenn ich die Türe wieder schließe nicht mehr runter?

Was kann das sein? Gibt es einen Bug im Kanal G?

Danke für die Hilfe und lg

[hjk]

Wie wäre es mit einer Gruppenmonitoraufnahme und den Einstellungen? Dannk ann man sehen, was falsch geht. Einen Bug im Kanal G kann ich ausschließen.

[GKap]

Da ist was faul mit den Binäreingängen.

Es gibt in diesem Fall keine Binäreingänge. Sowohl Verschluss- als auch Kippkontakte laufen über eine ABB GM/A 8.1.

Die Kontakte werden intern 1s verzögert und dann ausgewertet. Das reicht auch für eine langsame Bedienung. Anscheinend werden die Kontakte verzögert gesendet.

Gefühlsmäßig kommt mir die Verzögerung kleiner als 1s vor. Eine Verzögerung beim Weg Kontakt -> Alarmanlage -> KNX -> Aktor kann sich nicht auswirken, wenn alle Telegramme gleich verzögert am Aktor ankommen würden, würde der Behang etwas später losfahren, es würde aber nichts an der zu kurzen Verzögerung im Aktor ändern!

Wenn die Beschattung aktiv ist, dann gibt es, wie ich bereits oben beschrieben habe, gar keine Verzögerung, auch bei sehr schnellem Drehen des Griffes von "Zu" auf "Kipp" wird erst einmal die Höhe für "Offen" angefahren!

Wenn die Fahrten wenigstens unterbrechbar wären, d.h. wenn ein Fenster gekippt wird, während der Behang fährt, dann wäre das schon eine wesentliche Verbesserung!

Gruß
GKap

[hjk]

Da wird das Problem wohl von der GMA kommen. Ohne Gruppenmonitoraufnahme können wir aber nur vermuten.
Klar ist, bei Verwendung von Binäreingängen gibt es definitiv keinerlei Probleme, die Kombination ist zigtausenfach im Einsatz.
Also erstmal aufzeichnen und schauen was passiert. Zur Not muss man die Ausgänge der Alarmanlage über eine Logik ziehen.

[Burgerking]

Wie wäre es mit einer Gruppenmonitoraufnahme und den Einstellungen? Dannk ann man sehen, was falsch geht. Einen Bug im Kanal G kann ich ausschließen.

ok, dann wird ich mir das mal im Gruppenmonitor ansehen und mich melden...
lg

[EML]

Das ist aber nicht die Differenzfahrt die der Aktor automatisch nach dem einspielen macht?
Dann wäre es nur beim ersten Mal nach dem einspielen. Nur so eine Idee die mir im Kopf kam.