Eintastenbedienung mit Richtungsvorgabe: MDT Glastaster + Jalousieaktor

[mumpf]

TabSel: Du bekommst doch vom MDT-Aktor ein "Ist oben" bzw. ein "Ist unten". Verbinde doch beide mit dem Stop-KO. Eventuell muss Du noch einen Filter nehmen, der nur 1 durchlässt, weiß nicht wie Stop auf 0 reagiert. Aber das ist es eigentlich, oder?

Gruß, Waldemar

[Beleuchtfix]

Das Problem ist, dass der Taster kein Stop sendet sondern der Aktor jeden beliebigen Befehl als Stop nimmt, wenn das Rollo fährt. Und Ist oben/unten sind ja auch errechnet.
Gruß
Florian

[gbglace]

dass alle Bewohner die Automatik so akzeptieren.

Kann aber auch einfach am fehlenden Umfang der Automatik liegen. Ich würde daher erstmal ermitteln welche Szenarien sind es denn die da zu häufiger manueller Korrektur nötigen. und das dann entsprechend in der Automatik/Szenensteuerung berücksichtigen.

[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…

[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]

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.

[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

[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.

[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

[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.

[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.

[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]

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]

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.

[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…