Eintastenbedienung mit Richtungsvorgabe: MDT Glastaster + Jalousieaktor

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

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

[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

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

Ich empfinde so was als zwar als logisch, aber nicht ergonomisch, nachvollziehbar, verhersehbar und damit "kaputt".

Kann man so sehen. Deine Wünsche wirst du mMn nicht mit den von dir verwendeten Geräten erreichen können. KNX bietet mit der Wippenbedienung genau das an, was du willst. Ansonsten kauf dir andere Aktoren oder Sensoren oder bastel dir etwas.
Viel Erfolg dabei, Florian

[Abrradratra]

Das habe ich dann doch selten erlebt, dass alle Bewohner die Automatik so akzeptieren. Bei der Heizung bin ich voll bei dir.
Aber sehr gut dass das bei dir so funktioniert

Bei mir würde das zu Krieg führen, da das Handy nicht immer am Mann ist werden hier noch recht oft die Taster bemüht.

[DerStandart]

Rollladen oben haben will obwohl die Automatik ihn geschlossen

Also ich nehme dann das Handy zur Hand oder gehen zum zentral verbauten Touchmonitor, navigiere dort in den entsprechenden Raum und fahre den Rolladen hoch. Dadurch, dass das nur ungefähr 3x im Jahr vorkommt (genau so wie das Verstellen des Sollwerts der Heizung) ist das absolut vernünftig nutzbar.

Die Automatiken sind hier so ausgearbeitet, dass keine manuelle Bedienung notwendig ist. Wie gesagt, vielleicht gibt es mal 3 Ausnahmen im Jahr. Dauerhafte Ausnahme ist das Gästezimmer. Dort liegt der Rollladen auch auf dem Taster. Wenn Besuch da ist, wird in der Visu "Übernachtungsbesuch" aktiviert, sodass das Gästezimmer aus sämtlichen Automatismen ausgenommen ist.

[TabSel]

...Und was ist, wenn man den Rollladen oben haben will obwohl die Automatik ihn geschlossen hat?...

Das ist auch eine Prämisse hier im Haus. Manuelle Bedienung hat immer Vorrang vor einem Automatismus. Und ich will die Rollos (-Automatik manuell über-) steuern können.

[TabSel]

...Was ist denn der Grund für das Drücken nach oben?

ist mir egal, ich möchte dass ein Tastendruck
1) immer eine VOR DEM TASTENDRUCK immer geliche, bekannte Aktion zur Folge hat und
2) auch immer zu dieser Aktion führt. Alles andere fühlt sich für mich "kaputt" an.

Bei Einzeltasten-Rollo-Bedienung im KNX-Standard stört mich dass ich 1) vor dem Tastendruck nicht weiß ob der Rollo hoch oder runter fahren wird und bei der Lösung "druck lang = ab, druck kurz = auf" stört mich dass 2) der Tastendruck nix macht, wenn die Gesamtverfahrzeit 25Sek noch nicht abgelaufen ist und der Rollo gar nicht fährt. Innerhalb 25Sek muss es nicht mal ICH sein der den Rollo wieder runter machen will, d.h. wir beide in der Küche, ICH mache den Rollo ganz hoch, meine Frau störts, möcht Ihn wieder ein Stück runter machen, drückt lang und es passiert nix. Erst der zweite lange Druck oder der erste lange Druck nach Verfahrzeit macht was.

Ich empfinde so was als zwar als logisch, aber nicht ergonomisch, nachvollziehbar, verhersehbar und damit "kaputt".

Und auf dem KNX-Preisniveau ist es mir gestattet zu jammern *lach*