Rolläden sollen auf bleiben

[Sonicmaster]

Hallo,

Soll Situation: Wenn Terassentür offen ist, sollen die Rollladen auch heraufgefahren bleiben, auch wenn der Lichtsensor meldet das der Wert überschritten ist.

CCU3 FW: 3.51.6
HMIP-BROLL 1.6.2
HMIP-SWDO-I 1.16.10
HMIP-SLO 1.0.16

Zwei Direkt Programme die auf dem HMIP-Broll:4 Kanal zielen.

1. SLO -> Broll:4 wenn oberer Grenzwert überschritten (35.000 Lux) fahr auf Behanghöhe 40%.
2. SWDO-I - Broll:4 wenn Tür offen, dann hoch und oben dauerhaft

Das ganze funktioniert auch super, doch leider fährt die Rollade wieder auf 40% wenn der SLO mehr als 35.000 Lux sendet und die Terassentür offen steht.

Ich betreibe meine Homematic seit 2 Monaten, und hab auch schon einige Programme geschrieben. Direktprogramme habe ich auch einige, aber die sind alle nur einfach. Heißt Direktprogramme wo nun drei Aktoren im Spiel sind habe ich nur an diesem Broll. Ich hab mir auch mal das PDF von Homematic durchgelesen wo es um die virtuellen Kanäle geht, aber so richtig schlau draus wie ich das nun in dieser Situation einsetzte werde ich auch nicht.
Daher wäre es nett wenn ich Unterstützung bekomme.

Gruß

Sonicmaster

[dtp]

Das dürfte mir Direktverknüpfungen schwer zu realisieren sein, weil DVs nicht untereinander abhängig konfiguriert werden können. Dafür gibt es WebUI-Programme. Also einfach nur den Zustand des Fenstersensors prüfen, wenn der Helligkeitssensor das Programm zum Hochfahren triggert.

Wahrscheinlich wäre es etwas mit Kanonen auf Spatzen geschossen, aber du könntest sowas auch mit meinem zBSP (siehe Signatur) umsetzen.

[Xel66]

Das ganze funktioniert auch super, doch leider fährt die Rollade wieder auf 40% wenn der SLO mehr als 35.000 Lux sendet und die Terassentür offen steht.

Das Programm tut also das, was Du auch programmiert hast. Aber es wäre zielführend, die Programme als Screenshot hier im Forum einzustellen. Nacherzählungen sind fast immer unvollständig.

Ich hab mir auch mal das PDF von Homematic durchgelesen wo es um die virtuellen Kanäle geht, aber so richtig schlau draus wie ich das nun in dieser Situation einsetzte werde ich auch nicht.

Damit hast Du aber schon mal einen möglichen Lösungsansatz. Lass das Programm, welches den Rollladen bei geöffneter Tür auf den Kanal 5 den Sollwert vorgeben (und bei geschlossener Tür wieder auf 0%). In den Geräteeinstellungen stellst Du die logische Verknüpfung der Kanäle auf "OR (höherer Pegel hat Priorität)", was auch die Defaulteinstellung ist. Die Beschattungshöhe (40%) lässt Du auf den Kanal 4 setzen. Somit bleibt der Rollladen oben, solange der Sollwert im Kanal 5 auf 100% steht und fährt bem Schließen der Tür auf die vorherige bzw. Beschattungsstellung. Das war es schon. Solltest Du die virtuellen Kanäle nicht sehen, musst Du die Kindersicherung ausschalten (Einstellungen/Benutzerverwaltung "vereinfachte Konfiguration..." - Häkchen raus),

Gruß Xel66

[dtp]

Stellt sich mir jetzt die ergänzende Frage, was ein Direktprogramm ist.

[Xel66]

... was ein Direktprogramm ist.

Ich würde mal interpretieren, dass dieses ein Programm ist, welches direkt auf den Aktor zugreift im Gegensatz zu Programmen, welche z.B. "nur" Systemvariablen setzen. Aber letztendlich: Programm ist Programm.

Gruß Xel66

[Sonicmaster]

Tschuldigung 'Direkte Verknüpfung'. Asche über mein Haupt! Danke Werde es gleich mal ausprobieren und berichten.

[dtp]

Tschuldigung 'Direkte Verknüpfung'.

So hatte ich es ja auch interpretiert.

[alsk1]

Man könnte doch den Türkontakt mit Kanal 5 oder 6 verknüpfen und den Sonnensensor mit Kanal 4 als Beispiel. Dann hätte der Türkontakt immer Priorität.

[Xel66]

Leider funktioniert diese Lösung auch nicht unter allen Umständen optimal oder wie vorgesehen. Man kann nur einen Statuswechsel bei erkanntem Öffnungs- oder Schließvorgang auswählen. Also nicht gezielt bei Tür auf --> Rollladen 100% und Tür zu ---> Rollladen 0% zuordnen. Erklärungstext in der WebUI: Mit jedem Öffnen / Schliessen des Fenster- und Türkontaktes fährt die Markise / der Rollladen im Wechsel ganz hoch bzw. ganz herunter (Toggle-Funktion)...

Unter bestimmten Umständen passiert es vermutlich durch schnelle Statuswechsel, dass der Rollladenaktor-Kanal genau invers steht und beim Schließen der Tür auf 100% geht und beim Öffnen auf 0%. Um das wieder hinzubekommen, muss man via WebUI eingreifen. Schön ist anders. Ist bei mir bei Versuchen aber nur ein Mal passiert. Als Erstmaßnahme hatte eine kurze Verzögerung der Statusübermittlung (bei mir 3 Sekunden) durch den Türsensor geholfen. Die habe ich sowieso eingebaut, weil an der Tür zwei TFK (einer HM einer HMIP) sind um gekippt und offen zu unterscheiden (Drehgriffkontakt kann ich dort nicht anbauen) und die unverzögerte Direktverknüpfung zu Alarmierungszwecken zur Innensirene zu gewährleisten.

Ich habe mir beholfen, dass ich in der Direktverknüpfung (TFK--> Rollladenaktor Kanal 59 die Verweildauer im Zustand "oben" einfach auf eine Stunde begrenzt habe. So korrigiert sich der Status von allein nach einer Stunde wieder. Stände die Tür also länger als eine Stunde offen, würde der durch diese Direktverknüpfung geöffnete Rollladen wieder runterlaufen. Auch nicht optimal, aber funktioniert, denn ich lasse die Tür abends selten lange offen stehen. Bei mir hat dieser Rollladen keine Beschattungsfunktion, weil dieses die unter dem Glasdach montierte Markise übernimmt. Er fährt nur abends automatisch runter. Hat der Rollladen die (zeitabhängige) Sollstellung unten und wird manuell oder durch das Öffnen der Terrassentür (oder Rauchalarm) hochgefahren, wird durch ein Programm die Sollstellung korrigiert. Das ist aber auch keine universal einsetzbare Lösung und schon gar nicht autark, weil diese Aufgabe durch die CCU erledigt werden muss. Ich steuere meine Rollladen ausschließlich über Systemvariablen. Es gibt genau pro Rollladen nur ein Programm mit direktem Zugriff auf den Aktor. Alle anderen Programme können nur die Systemvariablen ansteuern. Dadurch kann ich auch vorher korrigierend eingreifen.

Gruß Xel66

[alsk1]

@Xel66

Das kann ich mir gar nicht vorstellen, das so etwas passieren kann das der Türkontakt irgendwann invers arbeitet, zum Beispiel durch einen sehr schnellen Statuswechsel und plötzlich geschlossen=100% Behanghöhe und offen=0% Behanghöhe darstellt.

Die Aktoren haben doch eine zyklische Status Übermittlung? Diese zyklische Status Übermittlung verstehe ich aber bis heute nicht wirklich.... Wenn ich zB einen Rollladen Aktor spannungslos mache und wieder Spannung anlege, dann steht der Aktor auf 0% und bleibt auch auf 0%,obwohl das Rollo oben ist. Hier muss das Rollo 1x manuell gefahren werden und dann stimmt der Zustand des Aktors wieder mit dem Ist Zustand überein.
OK, das könnte ich noch verstehen, weil der Aktor keinen Speicher hat, indem die aktuelle Position vor dem Stromausfall hinterlegt ist.
Dennoch gibt es bei dem Aktor in der WebUI der CCU ja den Punkt "zyklische Status Übermittlung". Wozu?

Wenn ich jedoch einen Türkontakt habe bzw ein Eingangs Modul an dem ein meinetwegen konventioneller Türkontakt angeschaltet ist, so kann dieser ja nur 2 Zustände annehmen (offen oder geschlossen). Hier müsste es ja möglich sein, über eine zyklische Abfrage den aktuellen, tatsächlichen Zustand anzufragen und automatisch wiederherstellen zu lassen, selbst wenn der Sensor plötzlich invers arbeitet?
Es gibt ja keine Zwischenpositionen von 1-99% wie bei einem Rollladen Aktor, sondern nur geöffnet/geschlossen (0% oder 100%).
Würde der Aktor nun zyklisch seinen Status übermitteln, so dürfte eine derartige Falsch Übermittlung jedoch keine Auswirkungen in dem Sinne haben, daß man sich u. U. aussperrt.

Das würde ja bedeuten das man keinen zuverlässigen Aussperrschutz definieren und realisieren kann. Ich stehe vor demselben Problem, das ich an einer Terrassentüre noch einen Aussperrschutz realisieren muss. Derzeit wird dieser Rollladen noch nicht automatisch beschattet (das wird er nie, da nicht benötigt, die Tür ist überdacht und dort fällt keine Sonne herein), aber er wird auch abends nicht automatisch heruntergefahren. Denn diese Tür führt auf Terrasse wo abends nochmal eine geraucht wird und das kann um 22 Uhr sein, um 23 Uhr oder auch mal um 01:00 Uhr morgens.
Daher hatte ich vor über einen konventionellen Magmetkontakt einen Eingang an einem HmIP-FCI zu setzen, der Kanal 5 auf 100% setzt. Dieser Kanal soll dann das Rollo hochfahren (sofern es vorher automatisch heruntergefahren wurde) und somit sperren. Sollte das Rollo noch oben sein, so sollte es über Kanal 5 ein Herunterfahren über Kanal 4 verhindern.
So mein Plan..... Aber anscheinend funktioniert das nicht....??? Bzw ist nicht zuverlässig? Das muss aber zu 100% funktionieren, da wir uns sonst aussperren würden....