Eintastenbedienung mit Richtungsvorgabe: MDT Glastaster + Jalousieaktor

[ElectricAl]

... bekommst doch vom MDT-Aktor ein "Ist oben" bzw. ein "Ist unten". Verbinde doch beide mit dem Stop-KO.

mumpf Vielen Dank für diesen wichtigen Hinweis, damit konnte ich das "Problem" der Eintastenbedienung mit SOC nun auch endlich bei mir nachvollziehen und lösen.

Da „ist-oben/unten“ berechnet ist und nichts mit der physikalischen Pos des Rollos zu tun hat muss die Pos aber regelmäßig kalibriert werden. Daher muss das Stop gefiltert werden.

Ich verzögere das Senden des Stop mithilfe des Logikmoduls um 2s, damit kann ich etwaige Positionsungenauigkeiten bisher sehr gut überbrücken. Es stellt sich mir jedoch folgende Frage:
Ich habe im MDT Rolladenaktor eine Fahrzeitverlängerung von 5% eingestellt, bei einer "Auf"-Laufzeit von 27s würde dies ja eine Verlängerung von 1,35s bedeuten. Ist der Aktor dadurch dann bei einer vollständigen Auf-Fahrt von kompletter geschlossener Position aus automatisch "erneut" kalibriert - da ja die Gesamtverfahrenszeit inkl. Verlängerung abgelaufen ist und das Stop Signal erst nach 2s gesendet wird? Oder macht dieses "späte" Stop die automatische Kalibrierung zunichte?

[tobiasr]

Im Herbst/Winter wirds schneller dunkel nach Sonnenuntergang und der Wunsch zu zu machen damit man nicht reinsieht ist schon da noch bevor die 15 min. um sind. Muss also erweitert werden, bis dahin wird manuell zugemacht.

Allein hier sieht man schon sehr gut den Unterschied: Bei meinen Eltern kam der Wunsch auf, dass die Rollläden im Winter durch den Sonnenuntergang viel zu früh runter gehen und das künstlich um STUNDEN verzögert werden soll, weil man sich sonst eingesperrt fühlt. Dass jemand reingucken kann, ist kaum gegeben.

Die 'Kinder' wollen nie mittags nochmal schlafen, die Sonne kommt niemals doch an einem Baum vorbei. Viele Automatismen gehen auch nur bei relativ ähnlichen Tagesabläufen. Wir wohnen z.B: mit vier Personen und jeder steht vollkommen unterschiedlich auf. Das auch noch abhängig vom Schichtplan, der obendrein alle 7 Wochentage beinhalten kann und natürlich für jeden anders aussieht. Teilweise sind die Arbeitszeiten auch total gegenläufig. So steht der eine auf, 10min nach dem der andere überhaupt erst ins Bett geht.

Auf meinem kombinierten Schlaf- und Arbeitszimmer steht im Sommer von ~7-13 Uhr voll die Sonne. Wenn ich Termine außer Haus habe braucht der Rollladen überhaupt nicht fahren, zumindest nicht vor ~13 Uhr. Ich kann das aber auch an keiner speziellen Handlung festmachen (z.B. wenn ich den Computer starte, dürfen die Rollläden hochfahren), weil ich vielleicht nurnoch schnell eine E-Mail verschicken möchte, das geht auch mit elektrischem Licht.

[Beleuchtfix]

Das ist mir zu unkonkret als das ich es einfach so akzeptieren würde.

Göran, es können nicht alle Leute so genial programmieren und ihren Bedarf analysieren wie du
Besonders wenn mehrere Personen davon beeinflusst werden und in dem Haus Wohnen können die Interessen sich wesentlich unterscheiden. Wobei die genaue Definition der Bedürfnisse wohl am schwierigsten ist. Zu sagen oder zu denken, jetzt müsste die Jalousie diese Position haben ist viel einfacher, als mir ist es zu dunkel weil die Wolken zu dicht sind, der Baum Schatten wirft oder ….
Gruß Florian

[TabSel]

das stimmt vermutlich, ist aber auch ein Prozess der sich über ein Jahr hinziehen kann bis man es zufriedenstellend individualisiert vollautomatisiert hat, währenddessen man noch vermehrt manuell bedienen muss. Zumindest hier so: bisher 15 min. nach Sonnenuntergang gingen Rollo im EG auf 75% (Schlitze offen). Passt im Sommer. Im Herbst/Winter wirds schneller dunkel nach Sonnenuntergang und der Wunsch zu zu machen damit man nicht reinsieht ist schon da noch bevor die 15 min. um sind. Muss also erweitert werden, bis dahin wird manuell zugemacht.

ALLES von Beginn an hat wohl niemand hier berücksichtigt?

also ist eine manuelle Bedienung des Hauses immer irgendwie notwendig, und wenn’s nur der einmalige Sonderfall ist…

[gbglace]

Das ist mir zu unkonkret als das ich es einfach so akzeptieren würde.

Bitte klare Beispiele, damit man auch über Gegenmaßnahmen in Richtung vollständigerer Automatisierung nachdenken kann.

Gerade bei Neubauprojekten hat man wohl gerade noch in der Planungsphase die Möglichkeiten Gegenzusteuern. In Bestandesobjekten mit vermutlich reduzierten Sensorwerten und Logikmöglichkeiten kann das sein das vieles nicht abgedeckt werden kann. Aber wenn es gerade neu gemacht wird versucht man das doch besser direkt zu vermeiden.

Ich bin immernoch der Meinung das man Rollos zu 98% automasieren kann. Und 2% sind dann nicht mehr wirklich oft und regelmäßig.

[fwiehl]

Aber ansonsten Frage ich mich eher warum ist es da notwendig manuell die Rollos zu verfahren?

Man glaubt garnicht, wie oft man manuell eingreifen muss, weil das Wetter und der Alltag doch anders ist als die KNX-Welt....

[gbglace]

Was Ihr sucht ist nen Garagentorantrieb, da bin ich froh das das Rollo im Haus dann doch viel mehr kann..

Zur Simulation würde ich dann eher langen Tastendruck startet Bewegung und kurz stoppt einbauen, damit lässt sich dann der Rollo doch besser positionieren bei manueller Bedienung.

Aber ansonsten Frage ich mich eher warum ist es da notwendig manuell die Rollos zu verfahren?

[fwiehl]

Gibt es hierzu neue Erkenntnisse? Ich habe folgende Geräte
MDT Glastaster BE-GT2Tx.02 II
MDT Jalousieaktor JAL 0810M.02

und möchte ebenfalls per Einzel-Tastenfunktion den Rollladen wie folgt bewegen:
kurzer Tastendruck: Rollladen fährt nach unten
weiterer kurzer Tastendruck: Rollladen stoppt
weiterer kurzer Tastendruck: Rollladen fährt nach oben (entgegengesetzte Richtung)

aktuell habe ich es im Standard so eingestellt, dass bei kurzem Tastendruck sich der Rollladen bewegt und bei einem weiteren kurzen Tastendruck der Rollladen in die entgegengesetzte Richtung fährt und bei langem Tastendruck anhält.
Die Bedienung finde ich aber auch wie mein Vorredner eher unnatürlich.
Das Single Object Control habe ich deaktiviert. Wenn es aktiviert ist dann fährt der Rollladen beim zweiten kurzen Tastendruck immer in die gleiche Richtung ohne Richtungswechsel.

[DerStandart]

SOC macht dir übrigens auch Probleme, wenn plötzlich Zentralfunktionen oder Automatismen mit eingreifen, da bringt der zweite Tastendruck nämlich das Teil zum stehen bzw die Automatik hält deine manuelle Fahrt an.

Ich prüfe daher am Anfang einer jeden Automatik das Objekt "Verfahrstatus" der entsprechenden Kanäle, damit eben genau das nicht passiert. Klappt hervorragend.

[Beleuchtfix]

Ich bin dagegen, der Rekalibrierung halte ich für wesentlich wichtiger als auf einen Tastendruck bei deinem Konzept verzichten zu können. Rekalibrierung braucht jeder, dein Konzept eher wenige.

SOC macht dir übrigens auch Probleme, wenn plötzlich Zentralfunktionen oder Automatismen mit eingreifen, da bringt der zweite Tastendruck nämlich das Teil zum stehen bzw die Automatik hält deine manuelle Fahrt an.

Gruß
Florian

[tobiasr]

hjk Vielleicht könnt ihr in der Firmware hier etwas nachbessern? Der Aktor weiß ja ziemlich genau, dass er jetzt in den letzten Prozent (gerade beim Öffnen ggf. schon nicht mehr sichtbar) bzw. schon in der Fahrzeitverlängerung ist.

[DerStandart]

Kann aber auch einfach am fehlenden Umfang der Automatik liegen.

Das würde ich auch vermuten.

Man muss natürlich auch Lebensumstände berücksichtigen. Wenn meine Frau und ich täglich zu wechselnden und nicht vorhersehbaren Uhrzeiten arbeiten würden, dann waren einige Automatiken hier auch wirkungslos bzw. nicht realisierbar.

Wir reden hier auch nicht über "wenn Helligkeit größer 100 Lux, dann Rollläden hoch". Die Logiken / Automatiken hier sind recht umfangreich. Da kommen schnell mal 100 bis 200 Zeilen Code zusammen. Nicht jede Logik sitzt sofort perfekt, sondern muss 1 bis 2 Mal nachgearbeitet werden, weil man vergessen hat, bestimmte Situationen zu berücksichtigen.

Grundsätzlich, wenn es die Lebenssituationen zulassen, versuche ich auch, dies in Kundensystemen so umzusetzen. Dabei kommen unterschiedliche Umfänge zusammen, denn so wie jeder Mensch anders ist hat auch jeder einen anderen Bedarf an Automatiken. Meistens schaffe ich es aber, spätestens 6 Monate nach Einzug die Hälfte aller Rollläden von den Tastern zu verbannen

[TabSel]

und damit startet die Verfahrzeit wieder und ein Tastendruck bei SOC bewirkt während der Gesamtfahrzeit ein Stop selbst wenn Rollo stoppte weil ganz oben. Also nein, das würde nicht funktionieren.

“ist-oben/unten“ mit dem „stop“-KO des Aktors verbinden, wie auch mumpf schrieb. Da „ist-oben/unten“ berechnet ist und nichts mit der physikalischen Pos des Rollos zu tun hat muss die Pos aber regelmäßig kalibriert werden. Daher muss das Stop gefiltert werden. Meiner Meinung nach am Besten dann wenn die Gesamtfahrzeit großteils abgelaufen ist, d.h. wenn der Rollo von „ist-unten/oben“ ohne stop bis „ist-oben/unten“ fuhr, und/oder einmal täglich bei der ersten Auf-/Abfahrt egal von welcher Position. In diesem Fall dann stop nicht schreiben, der Rollo fährt dann weiter in seine Endlage, die Gesamtverfahrzeit wird ablaufen, der nächste Tastendruck bewirkt danach kein Stop sondern gleich eine Reaktion und die Pos ist kalibriert.

[tobiasr]

Wäre es vielleicht besser, mithilfe der Logik mitzuhören: Wie lange ist 'ist oben' bzw 'ist unten' her (länger als die 5% Fahrweg) und dann ggf. den Tasterbefehl zu duplizieren? Der Taster selbst stoppt jetzt also den Aktor, die Duplizierung aus der Logik fährt ihn wieder los.

[TabSel]

TabSel…

Waldemar, genau so hab ich das seit Wochen am Laufen.

aber ich stelle eben fest dass sich “ist-oben/unten” “verschiebt”, also der Rollo im Lauf der Zeit schon z.B. “ist-oben” sendet obwohl er auf etwa 5% hängt. Dadurch sende ich das STOP-verursachende SOC zu früh, das Rollo hängt, und geht auch nicht mehr weiter hoch, da bei jeder Fahrt sofort ein SOC gesendet wird weil der Aktor “ist-oben” sendet…

warum sich das “ist-oben” im Vergleich zur tatsächlichen Physik verändert ist mir (noch) nicht klar, das verstehe ich noch nicht. Bis Dahin werde ich nen Workaround basteln der zB. bei der ersten morgendlichen Auffahrt von “ist-unten” bis “ist-oben” bei “ist-oben” KEIN STOP-verursachendes SOC schreibt und der Rollo damit ganz nach oben fährt.

wenn jemand ne Erklärung beisteuern könnte warum
sich die Korrelation “ist-oben” zur Rollo-Pos ändert, dann nur immer her damit, vielleicht hab ich auch nen Einstellungsfehler…