Rollladen steuern - HmIP-BROLL vs. HmIP-FROLL

[steho]

Hallo zusammen!

In der Hoffnung, dass hier noch jemand mitliest - und des Rätsels Lösung kennt...

Ich hatte an den Fenstern zur Terrasse schon vor einiger Zeit die Fenstergriffsensoren auf HmIP-SRH umgerüstet (die älteren Homematic HM-SEC-RHS waren mir zu unzuverlässig) und jetzt als konsequenter Schritt dann auch die Rollladenaktoren auf HmIP-BROLL.

Kanal 4 der BROLLs spreche ich über die Taster bzw. Beschattungs- / Nachtprogramm an,

Kanal 5 habe ich wie hier am Anfang beschrieben jeweils mit den zugehörigen HmIP-SRH direkt verknüpft und die Experten-Einstellungen wie folgt eingestellt:

Das funktioniert auch im Prinzip wie gewünscht, nur leider fahren die Rollläden nicht zuverlässig wieder auf die vorherige Position zurück, sofern z.B. die Beschattung aktiv war. Kanal 4 steht dann (auch) auf 100%, also offen.
Kurioserweise klappt es ab und zu, ich weiß aber nicht, warum

Hier mal exemplarisch das Programm für die Beschattung:

Der Fehler präsentiert sich dann so, dass Kanal 4 auf 40% steht, die Bedingungen für Beschattung als zuvor "wahr" waren, ich öffne die Tür, der HmIP-SRH setzt Kanal 5 vom BROLL auf 100% (mit OR verknüpft) und der Rollladen fährt auf.
Nach 2-3 Minuten schließe ich die Tür wieder, Kanal 5 springt auch wie erwartet auf 0%, aber Kanal 4 steht auf 100%.

Falls jemand einen offensichtlichen Fehler in meiner Verknüpfen / den Parametern sieht, wäre ich da sehr dankbar - ich stehe da grad auf'm Schlauch...

Gruß,

Holger

[MichaelN]

Stell den Kanal 4 auf protokolliert und schau, wann er auf 100% geht. Dann findest du vielleicht die Ursache. Eine vergessene DV oder Programm.

[steho]

Ich hatte den Aktor schon "komplett" auf protokolliert gestellt, konnte aber damit nicht so recht was anfangen - wenn's funktioniert, dann stand halt ganz normal 40% drin und wenn nicht 100%, also kurz nachdem der Griff geschlossen wurde. Daher dachte ich erst, dass in meiner DV was nicht stimmt, kenne mich ehrlich gesagt mit den Expertenparametern nicht wirklich aus und hatte es nur übernommen.

Wenn ich mein "Schatten-Programm" manuell danach triggere, dann geht sie auch auf 40% und ein anschließender Test: Griff auf, fährt hoch - 20 Sekunden warten - Griff zu fährt auf 40%.

Es gibt auch nur das Nacht- und Schattenprogramm sowie die DV vom Griff auf Kanal 5 - aber ich hab jetzt nur mal Kanal 4 & 5 auf protokollieren gesetzt und versuche mal mein Glück.

Aber danke für den Hinweis!

[MichaelN]

Wenn der SRH das auslöst, gibt es evt noch ein vergessenes Programm?

[steho]

So, jetzt scheint es zu funktionieren - aber einen Fehler hab ich trotzdem nicht gefunden.

Hab die DV nochmal gelöscht, BROLL abgelernt, Werkseinstellungen, angelernt und die DV neu erstellt - geht.

Keine Ahnung, was da los war - hatte am WE noch zwei weitere BROLLs in anderen Räumen verbaut und quasi die gleichen Programme/DVs erstellt(umgestellt), funzte auf Anhieb - daher die beiden in der Küche/Esszimmer nochmal komplett auf Anfang.

Wird mal Zeit, dass ich mir die "Experten-Parameter" mal genauer ansehe, hab mich da jetzt schon viel zu lange erfolgreich vor gedrückt

[Tiro]

Habe in den letzten Tagen viel zum Thema Rollladen Steuerung, Aussperrschutz und virtuelle Kanäle hier im Forum gelesen und dabei viel gelernt. Allen Aktiven dafür Dankeschön. Dieser Thread scheint mir immer noch aktiv zu sein, so dass ich hier mal mit meinen ersten Beitrag die für mich gefundene Lösung zurückspiegeln möchte. Vielleicht kann ja jemand damit etwas anfangen.

Zielssetzung ist der Aussperrschutz für den speziellen Fall einer Kipp-SchiebeTerrassentür (das ist wichig, da die Lösung mit eine reinen Schwebe-Schiebe nicht funktioniert), welcher sich ausschließlich über Direktverknüpfungen (DV) realiseren lässt, um die Abhängigkeit von der CCU auszuschließen. Das häufig beschriebene Problem, dass der Aussperrschutz getriggert durch eine DV mit einem HmIP-SWDO-2 beim öffnen der Tür, beim schließen nicht zurück gesetzt wird, kann mittels eines zweiten HmIP-SWDO-2 gelöst werden. Netter Nebeneffekt: Man dann sogar unterschieden, ob die Tür gekippt oder geöffnet ist. Der HmIP-SRH passt nämlich in der Regel nicht auf die Griffe einer Kipp-Schiebe-Tür (preislich hält sich das die Waage)

Wie sieht die eigentliche Lösung nun aus:

Die 2 Fensterkontakte werden werden oben (KT-A) und unten (KT-B) jeweils seitlich an der Terrassentür abgebracht. Folgende Logik ergibt sich:

KT-A On UND KT-B Off = Tür gekippt
KT-A On UND KT-B On = Tür offen
KT-A Off UND KT-B Off = Tür geschlossen
KT-A Off UND KT-B On = Tür kaputt

Jetzt können 2 DV erstellt werden:

KT-A auf den 2. virtuellen Kanal (Ch 5) des BROLL / FROLL und zwar Richtung "Schließen" (von ON auf OFF) zur Behangposition 0% (= Aufhebung des Aussperrschutzes)

KT-B auf den 2. virtuellen Kanal (Ch 5) des BROLL / FROLL und zwar Richtung "Öffnen" (von OFF auf ON) und Behangposition 100% (= Aktivieren des Aussperrschutzes)

Jetzt musst man nur noch Kanel 4 und 5 des BROLL / FROLL OR verknüpfen, dann klappt es mit dem Aussperrschutz nur mit DV. Zusätzlich kann man über die Abfrage der Kontakte noch den Kippstatus erfahren.

Vllt hilfts es dem ein oder anderen. Falls ich zu ausführlich war, möge man es mir verzeihen. Dies ist mein erster Post.

[Xel66]

Das häufig beschriebene Problem, dass der Aussperrschutz getriggert durch eine DV mit einem HmIP-SWDO-2 beim öffnen der Tür, beim schließen nicht zurück gesetzt wird, kann mittels eines zweiten HmIP-SWDO-2 gelöst werden.

Eine zwar kostenintensive, aber prima Lösung. Schöner wäre es natürlich, wenn der Hersteller das Problem grundsätzlich lösen würde.

Gruß Xel66

[derLaie]

Hallo zusammen,

auch ich möchte mich erst mal ganz herzlich für die vielen Infos bedanken, die ich hier schon erhalten durfte!

Nach einem Wechsel von AP zu CCU3 stehe ich halt auch vor der Herausforderung den Aussperrschutz zu realisieren. Dabei unterscheidet sich meine Zielvorgabe von der grundsätzlich hier besprochenen dadurch, dass ich eigentlich nur den Aussperrschutz des AP nachbauen möchte, also lediglich bei Status offen des SWDO2 verhindern möchte, dass die Zeitsteuerung greift. Ein aktives anfahren irgendeiner Position in Abhängigkeit des Status der Terrassentüre möchte ich ausdrücklich nicht. Zum einen haben wir keine Haustiere, die Kinder sind alt genug um diesen Satz zu verstehen:„Wenn nicht gleich die Rollade wieder oben ist, änder ich das Passwort vom WLAN!“ und ich möchte auch nicht, dass die Rollade (wieder) hoch fährt, nur weil ich die Türe zum lüften öffne, oder
(wieder) runter, wenn ich sie nach dem lüften wieder schließe. Vor allem im Sommer gilt es auch zu vermeiden, dass morgens die Rollade Astro-getriggert hoch fährt, obwohl alle noch im Bett liegen und die Türe die Nacht über zum lüften geöffnet war und immer noch ist. Daher fand ich den kurzzeitig angesprochenen Ansatz Kanal 7 inaktiv zu schalten großartig, leider wurde das aber nicht weiter behandelt.

Da bei einer DV als Ziel des SWDO2 immer ein Fahrkanal ist, der Eventtype immer eine Zielposition der Rollade oder eine Fahrtrichtung der Rollade zur Folge hat, scheidet meiner Meinung nach eine DV auch im Expertenmodus für mich in diesem Fall aus.
Auch kommt für mich (denke ich) die ständige logische Vergleichsrechnung verschiedener Werte nicht in Betracht, da ich durch den Status des SWDO nie irgendeine Fahrt vornehmen, sondern nur jede Fahrt durch das Zeitprofil/Wochenprogramm verhindern möchte, völlig egal wo irgendwo welche Zielposition vorgegeben ist. Daher habe ich die logische Verknüpfung bei allen drei Kanälen auf Kanal inaktiv gesetzt. Dadurch konnte ich in der "Simulation" des Rolladenaktors über das UI unter Status und Bedienung erstmal auf allen drei Kanälen fahren wie ich es wollte.

Nach Test mit dem Wochenprogramm und der Fahrt auf 0% konnte ich dann aber mit keinem Kanal mehr nach oben fahren. Auch logisch, da ja jede Berechnung eines Ausgangspegels mit 0% anfängt.

Nachdem ich Kanal 6 wieder auf OR gesetzt habe und in der Obefläche einen Sollwert von 100 eingegeben hatte konnte ich wieder fahren, diesmal natürlich mit der Einschränkung mit Kanal 4 und Kanal 5 max. bis zum Sollwert von Kanal 6 fahren zu können. Das bedeutete aber im Extremfall von Sollwert Kanal 6= 0%, dass sogar das rauf fahren auf Kanal 4 und 5 letztendlich zum runterfahren führte - getreu der Logik
3.) fahre zum Wert von Kanal 4/5
2.) fahre max. bis Sollwert Kanal 6 bzw. des lberechneten Ausgangspegels
1.) fahre auf jeden Fall!

und zwar ohne eine Richtungsangabe wie rauf oder runter, da ja sonst gar nicht gefahren worden wäre. Für meinen Geschmack ist das unlogisch, da ich ja die Fahrt mit einer Richtungstaste gestartet habe, die dadurch letztendlich ignoriert wurde und nur der Ausgangswert im Rahmen der Logik angefahren wird. Das "separieren" der Kanäle von der Logik scheint also auch nur begrenzt zu funktionieren, weil es eben doch immer die Rechnung mit 0% gibt.

Um ehrlich zu sein komme ich grad nicht weiter, da letztlich doch immer eine Neuberechnung stattfindet. Mir fehlt in diesem Fall eine ganz schlichte Priorisierung der Kanäle als Möglichkeit der logischen Verknüpfung neben der Berechnung. Dadurch würden sich eigentlich alle hier gewünschten Ziele easy peasy erreichen lassen. Bei mir:

Prio 1. (Kanal X/Y/Z): Tastenfahrten (gesperrt duch nichts)
Prio 2. (Kanal X/Y/Z): WP (durch Status offen gesperrt!)
Prio 3- (Kanal X/Y/Z): nicht belegt.

Für andere hier dann z.B.:

Prio 1. (Kanal X/Y/Z): Anwesenheitsstatus (abwesend=zu // anwesend=kein Effekt)
Prio 2. (Kanal X/Y/Z): Tastenfahrt (durch Status offen gesperrt)
Prio 3. (Kanal X/Y/Z): Wochenplan (durch Status offen gesperrt)

Vielleicht übersehe ich aber auch nur die entsprechende ausgeklügelte Berechnung der drei Kanäle um das gewünschte Ziel zu erreichen. Falls es also hier jemanden gibt, der meine Wunschlösung irgendwie erreicht hat, dann wäre ich für jegliche Hilfe sehr dankbar.

Hier noch mal kurz zusammengefasst: Status SDWO 2 Terrasse=offen => keine Fahrten vom Wochenprogramm
Nicht weniger und auf keinen Fall mehr...

Besten Dank an alle bis hier hin und ab hier

Grüße vom Niederrhein
Stefan

[MichaelN]

Um ehrlich zu sein habe ich den Text nur quer gelesen.

Aber ich glaube, Du unterliegst einem Irrtum. Die virtuellen Kanäle sind (in der STandardeinstelung) untereinander priorisiert.

ALs Bsp BROLL: Kanal 6 überstimmt 5 überstimmt 4.
Wenn Du also erreichen willst, das bei offenem Fenster das Rollo immer oben bleibt, dann Verknüpfe einfach SWDO2 mit dem höchsten Kanal .
bei Offen wird also 100% in Kanal 6 geschrieben und alle Ansteuerung die auf Kanal 4 oder 5 gehen sind damit ausgeknockt.
D.h. dein Wochenprogramm darf natürlich nicht auf Kanal 6 gehen!

[derLaie]

Das ist so leider nicht ganz richtig. Es gibt keine Priorität der einzelnen Kanäle 4-6. Der Ausgangspegel ist vielmehr die Folge der gewählten Verknüpfungsregeln, die Standard auf OR stehen, was heißt: der höhere Wert gewinnt. So gesehen stimmt zwar deine Schlussfolgerung, dass wenn 6 auf 100 steht, es bei hunder bleibt. Das gleiche gilt aber auch, wenn 4 oder 5 auf 100 steht und die jeweils übrigen 2 Kanäle auf 0, die 100 ist Trumpf.

Außerdem bedeutet das setzen einer 100 die gemäß Verknüpfungen auch den Ausgangspegel liefert, dass die Rollade dann auch dorthin fährt. Ich will aber nicht das die Rollade in Abhängigkeit des Status vom SWDO2 irgendwo hin fährt.

Aber so wie es grade aussieht ist Lösung so einfach, dass es mir beinahe peinlich ist.
Die Lösung liegt wohl doch in der "Deaktivierung" des Wochenprogramms im Kanal 7. Dazu habe ich erst mal wieder alles auf Standard gestellt - also WP wieder auf Kanal 4 - und dann 2 mini-Programme geschrieben.
Programm 1 aktiviert den Aussperrschutz, indem es bei Statuswechsel zu offen im Kanal 7 der Rollade den Modus für Kanal 4 auf manuell schaltet und das
Programm 2 deaktiviert den Aussperrschutz, indem es konträr dazu bei Statuswechsel zu geschlossen im Kanal 7 den Modus für Kanal 4 wieder auf automatisch schaltet.

Manchmal sieht man halt den Wald vor lauter Bäumen nicht. Also noch mal danke an alle und hoffentlich hilft dieser simple Ansatz dem ein oder anderen weiter, der, wie ich, nur den Aussperrschutz des APs nachbauen will.