Shutter Pilot – Rollladensteuerung für Home Assistant (HACS, komplett per Klick konfigurierbar)

schubi · 8. August 2026 um 12:55

Shutter Pilot 2.8.1 ist raus – zweite Runde zu denselben zwei Meldungen, diesmal mit dem Export aus 2.8.0 in der Hand. @MartyBr @heinzie

Der Fensterkontakt reagierte nicht (heinzie)
Zwei Fehler, jeder für sich schon ausreichend:

„open" traf bei einem binary_sensor nie zu. Das Formular bot „on", „open", „true" und „offen" an – ein binary_sensor meldet aber ausschließlich on oder off. Wer „open" wählte, hatte einen Kontakt konfiguriert, der dauerhaft als geschlossen galt: kein Lüften, keine Rückfahrt, kein Aussperrschutz. Und weil nie ein Zweig lief, stand darüber auch keine einzige Zeile im Log. Deshalb ging es auch mit anderen Kontakten nicht.

Die gängigen Schreibweisen gelten jetzt als gleichbedeutend. Zusätzlich steht off zur Wahl – manche Kontakte melden andersherum – und unter dem Feld steht, was deine Entität gerade meldet. Welcher der beiden Werte „offen" bedeutet, hängt am Gerät und war bisher nirgends abzulesen.

Der Kontakt erreichte einen beschatteten Rollladen nicht. Reagiert wurde nur, wenn der Rollladen (nahezu) geschlossen war. Die Beschattung parkt ihn auf halber Höhe – weder zu noch offen –, also fiel er durch die Prüfung. Wer nachmittags die Terrassentür öffnete, stand vor dem heruntergefahrenen Rollladen. Die Rangfolge ist Fensterkontakt → Beschattung → Lüften; jetzt gilt sie auch hier. Ein tagsüber offener Rollladen bleibt unverändert in Ruhe.

Dazu behoben: Endete die Beschattung bei offenem Fenster, fuhr der Rollladen beim Schließen auf die Beschattungsposition zurück – Stunden später.

Der Export sagt jetzt mehr
Drei Dinge, die in MartyBrs Bericht drinstanden und trotzdem nicht zu sehen waren: die Einheit neben dem Wert („559,7 W/m²" neben Schwelle „30000" erklärt sich von selbst, „559,7" nicht), ein Hinweis, wenn die Automatik aus ist und die Entscheidung gar nicht gefahren wird, und die Erklärung der stillen Haken – ein hinter einem Sensor auf unknown heißt „blockiert nicht", nicht „erfüllt".

@MartyBr – dein Export beantwortet es
sensor.gw3000a_wifi4133_solarstrahlung meldet 559,7 – deine Schwelle steht auf 30.000. Das ist Sonnenstrahlung in W/m², die geht bei voller Sonne bis etwa 1000. Fünfstellige Werte liefert nur dein zweiter Sensor, sensor.solarstrahlung_lux (gerade 70.914). Acht deiner zehn Rollläden hängen am W/m²-Sensor mit Lux-Schwellen – da kann nie etwas erfüllt werden. Deine zwei am Lux-Sensor rechnen dagegen sauber: „Rollo Küche" steht in deinem eigenen Bericht auf Ergebnis: beschatten.

Sensor angleichen – entweder überall sensor.solarstrahlung_lux, oder beim W/m²-Sensor bleiben und auf ~350 / ~250 gehen. Nicht mischen.
Azimut ist keine Spanne. 40/130, 130/220, 205/320, 355/359 – der zweite Wert ist der Aufhebepunkt unterhalb des ersten und wird verworfen, wenn er darüber liegt. Übrig bleibt „Azimut ≥ 40", also den ganzen Tag. Für eine Himmelsrichtungs-Spanne nimm „Nur bei passender Fensterrichtung" – die kann von–bis und rechnet den Nulldurchgang mit.
Vier Temperatursensoren melden unknown – die blockieren absichtlich nicht, tun bei dir also schlicht nichts.
Bereiche und Rollläden stehen auf Automatik aus – solange das so bleibt, passiert nichts, egal was die Prüfung sagt.
Bei „Rollo Küche" steht eine vierte Bedingung mit 2/70 ohne Sensor – verrutschte Elevationswerte, wirkungslos, kannst du löschen.

Nach dem Update bitte einmal Strg+F5, sonst zeigt das Panel die alte Fassung.

MartyBr · 8. August 2026 um 13:43

Ich habe nun die Sensoren “Solarstrahlung” getauscht gegen “Solarstrahlung_Lux”. Da bin ich wohl in die falsche Zeile gerutscht.

Die Himmelsrichtung habe ich aufgrund deines Hinweises geändert. Nun sind auch die ersten drei Rollos im Westen heruntergefahren!

Vielen Dank für deine Hilfe.

Gruß

Martin

schubi · 8. August 2026 um 13:54

Seit 2.8.1 sind drei Versionen dazugekommen. Zwei davon gehen auf @Linos’ ausführliches Feedback zurück, eine noch auf @heinzie s Fensterkontakt. Aktuell ist 2.9.1.

2.8.2 – Der Schieber, der nichts tat
Ein Fensterkontakt ohne eigenen Kipp-Zustand meldet nur offen und zu – „gekippt" kann er nicht unterscheiden. Shutter Pilot fährt in dem Fall bewusst die Kipp-Position, auch wenn das Fenster ganz offen steht.

Im Formular standen trotzdem zwei Schieber untereinander, und der obere hieß „Position bei Fenster offen" – also genau der, den man in dieser Situation anfasst. @heinzie hatte dort 97 % eingestellt und bekam die 98 % vom Feld darunter, ohne irgendwo sehen zu können warum.

Ohne Kipp-Zustand steht jetzt ein Schieber da, auf dem Wert der tatsächlich gefahren wird. Trägst du einen Kipp-Zustand ein, erscheinen wieder beide. Der Hinweistext daneben war obendrein falsch – er sprach vom geschlossenen Rollladen, was seit 2.8.1 doppelt nicht mehr stimmt.

2.9.0 – Neu: Sensor „Vorhersage Tageshöchstwert"
@Linos hat gefragt, ob es ein Problem ist, dass die Höchsttemperatur über den Tag schwankt. Ja, und zwar genau das, was er befürchtet hat.

Eine Tagesvorhersage wird im Lauf des Tages fortgeschrieben, und die meisten Quellen setzen sie herunter, sobald die Spitze vorbei ist. Um 21 Uhr steht bei „Höchsttemperatur heute" womöglich 25 °C, obwohl es um 15 Uhr 28 °C hatte. Genau dann wird aber eine Bedingung wie „nur halb schließen, wenn es über 26 °C hatte" geprüft – gegen eine Zahl, die sich klammheimlich davongestohlen hat.

Der neue Sensor hält den höchsten Wert des Tages fest und steigt bis Mitternacht nur noch.

Wofür Welcher Sensor
Entscheidungen am Tag (beschatten) Vorhersage Höchsttemperatur
Entscheidungen am Abend (abweichendes Schließen, Nachtlüftung) Vorhersage Tageshöchstwert
2.9.0 – „Warte auf passende Sonnenhöhe" stand da, wenn die Sonnenhöhe passte
Der Satz erschien immer dann, wenn die Geometrie stimmte und der Sonnenschutz trotzdem nicht aktiv war. Wer wie @Linos 0°–90° einstellte, bekam ihn den ganzen Tag und suchte den Fehler bei der Elevation – dabei lag er woanders. Das Dashboard sagt jetzt, woran es wirklich hängt: Sonnenhöhe daneben, falsche Himmelsrichtung, oder Geometrie passt und die Bedingungen fehlen noch.

2.9.1 – Die Formulare klappen auf und zu
Bereich, Rollladen und Einstellungen waren je eine einzige lange Bahn – das Bereichsformular über 20 Felder am Stück. Jede Überschrift ist jetzt ein Schalter, und zugeklappt bleibt sie mit einer kurzen Erklärung stehen:

Der Aufbau ist damit auf einen Blick zu lesen, statt ihn zu erscrollen. Fünf Überschriften hatten vorher gar keine Erklärung – die haben jetzt eine. Was du auf- oder zuklappst, merkt sich dein Browser. Und keine Sorge um deine Werte: ein zugeklappter Abschnitt wird nur nicht angezeigt, gespeichert wird immer der ganze Datensatz.

Kleinkram aus derselben Runde
Bereich duplizieren – Knopf in der Bereichsliste, öffnet eine Kopie zum Umbenennen. ID und Automatik-Schalter bleiben leer, damit die Kopie nicht am Schalter des Originals hängt.
Die Offsets erklären ihr Vorzeichen. Die Schieber gehen von −60 bis +60, nur stand nirgends in welche Richtung. Es gilt: Plus verschiebt nach hinten, Minus nach vorn – −15 fährt eine Viertelstunde vor Sonnenaufgang. An der Rechnung ändert sich nichts.
Bereiche stehen überall alphabetisch – vorher stand derselbe Bereich im Dashboard woanders als im Bereiche-Tab.
Shutter Pilots eigene Entitäten stehen in der Auswahlliste ganz oben. Die Vorhersage-Sensoren sind genau für die Bedingungsfelder gedacht, standen aber irgendwo zwischen tausend fremden.
@Linos, deine Lüften-Frage
Du hast selbst richtig getippt: für dein Ziel – nachts nicht ganz schließen, damit Luft durchzieht – ist Abweichendes Schließen das Richtige, nicht Automatisches Lüften.

Der Unterschied: Abweichendes Schließen bestimmt die Schließposition beim regulären Runterfahren (Bedingung erfüllt → 50 % statt 0 %). Automatisches Lüften fährt zwischendurch auf und wieder zurück.

Also: im Bereich unter „Abweichendes Schließen" die Bedingung setzen – Vorhersage Tageshöchstwert ab 26 °C – und bei den betreffenden Rollläden die abweichende Schließposition auf 50 %.

Zwei Punkte bewusst nicht umgesetzt
Kompass-Mehrfachauswahl (N + NO + O gleichzeitig anklicken): Daraus muss am Ende wieder ein Von-Bis-Bereich werden. „N + O" ohne NO gibt es nicht – es würde stillschweigend 0°–90° ergeben. Genau diese Verwechslung von Spanne und Punktepaar war in 2.8.0 ein echter Fehler, den sich ein anderer Nutzer eingefangen hat. Als Feature nachbauen möchte ich sie nicht.

Nicknol · 8. August 2026 um 14:36

Die Lösung fürs Lüften (Ventilation) erscheint mir (unnötig?) komplex und verwirrend.
Ich verwende für meine Rollladensteuerung 4 definierte Positionen:

Offen
Geschlossen
Sonnenschutz
Lüften

Beim gewöhnlichen (Sonnenstand / Uhrzeit) Öffnen bzw Schließen wird - wenn keine anderen Bedingungen zutreffen - auf die Positionen für Offen bzw Geschlossen gefahren.

Fenster offen/oder wird geöffnet und kein Sonnenschutz nötig, aber Rollladen geschlossen bzw im geschlossen Fenster: Ventilationsposition

Tür offen/oder wird geöffnet: egal was ist, der Rollladen bleibt offen oder wird geöffnet - Aussperrschutz

Sonnenschutz für Fenster: Egal ob offen oder geschlossen, beim Zutreffen der Sonnenschutzbedingungen wird der Rollladen auf die Sonnenschutzposition gefahren. Wichtiger als Lüften!! (bei mir)

Sonnenschutz für Türen: Wenn Tür geschlossen und Zutreffen der Sonnenschutzbedingungen wird der Rollladen auf die Sonnenschutzposition gefahren.

Damit ist Lüften in der Nacht kein Problem Die Position ist klar: Lüftungsposition.
Wird das Fenster geschlossen, fährt der Rollladen runter.

schubi · 9. August 2026 um 18:35

Shutter Pilot 2.10.0 — zwei Meldungen abgearbeitet, @heinzie und @Linos. Danke euch beiden.

Der nachgeholte Rollladen blieb am nächsten Morgen unten (@heinzie)

Abends fahren alle runter, einer bleibt wegen offenem Fenster oben und wird vorgemerkt, nach dem Schließen holt er nach — und am nächsten Morgen fährt alles hoch außer ihm. Der Nachhol-Zweig setzte die Merker „heute schon hoch-/runtergefahren" nicht, der Rollladen galt also weiter als „heute hochgefahren". Genau danach filtert der nächste Morgen.

Und der Beifang: die Diagnose hat gelogen

Beim Beginn eines Fahrzyklus wurde die Merkliste durch eine neue ersetzt, während intern weiter auf die alte geschrieben wurde. Ergebnis: Diagnose und Export zeigten „heute schon hochgefahren" dauerhaft leer, obwohl eine ganz andere Liste entschied. Das stand in jedem Export, den ihr mir bisher geschickt habt — und ich habe es geglaubt. Jetzt zeigen beide dasselbe.

Zwei Bedingungen für „Abweichendes Schliessen" (@Linos)

„Der Tag war warm" allein ist selten die ganze Regel — „und jemand ist zu Hause" ist die andere Hälfte. Die zweite erscheint, sobald die erste steht; beide müssen dann zutreffen. Typisches Paar: Vorhersage Tageshöchstwert ab 26 °C plus Anwesenheitssensor. Bestehende Einstellungen bleiben unverändert.

„Beschatten ab" stand auch dort, wo nichts beschattet wird (@Linos)

Deine Frage, ob das ein Formfehler ist oder die Bedingungen ungewollt am Sonnenschutz hängen: Formfehler. Funktional hingen sie nie am Sonnenschutz, es waren nur überall dessen Beschriftungen — samt Hinweis auf „durchziehende Wolken", auch bei Frost und Lüften. Außerhalb des Sonnenschutzes heißt es jetzt „Trifft zu ab".

Nach dem Update bitte einmal Strg+F5.

schubi · 9. August 2026 um 19:01

Shutter Pilot 2.10.1 — drei Wünsche, @charly166 und @hollizone. Der dritte Punkt kam beim Prüfen des ersten heraus und betrifft alle, die einen Bereich neu anlegen.

„Sonnenhöhe prüfen" lässt sich abschalten

@charly166 hat Helligkeitssensoren rund ums Haus verteilt und wollte die nutzen, ohne Elevation und Azimut einstellen zu müssen. Die Himmelsrichtung war schon immer optional, und Bedingungen lassen sich seit jeher pro Rollladen hinterlegen — ein Sensor je Fenster ging also bereits. Nur die Sonnenhöhe wurde immer geprüft. Jetzt gibt es dafür einen Haken, je Bereich und je Rollladen: aus heißt, allein die Bedingungen entscheiden. Wer einen Lux-Sensor am Fenster hat, lässt den entscheiden — der misst die Sonne ja bereits.

Raumtemperatur auf der Dashboard-Karte

@hollizone s Wunsch. Optionaler Sensor je Bereich (Bereich → Grunddaten), rein zur Anzeige — er entscheidet nichts. Ein toter oder fehlender Sensor lässt die Zeile weg. Wer die Temperatur als Bedingung will, trägt sie weiterhin unter „Sonnenschutz" oder „Abweichendes Schliessen" ein.

Und der Fund dabei: neue Bereiche beschatteten tagsüber nie

Beim Nachsehen für charly bin ich über die Vorgabe gestolpert: ein neu angelegter Bereich stand auf 0°–15° Sonnenhöhe. Die Mittagssonne steht im Sommer bei 60°. Wer einen Bereich anlegte, den Sonnenschutz einschaltete, seine Bedingung eintrug und sonst nichts änderte, bekam Beschattung nur kurz nach Sonnenaufgang und vor Sonnenuntergang — und suchte den Fehler dann bei den Bedingungen. Das dürfte hinter einigen „warum beschattet er nicht"-Fragen stecken.

Neue Bereiche starten jetzt mit 0°–90°. Bestehende behalten ihre Werte — wenn bei dir 0–15 steht und die Beschattung nie kam, ist das der Grund. Einmal nachziehen.

Nach dem Update bitte einmal Strg+F5.

hollizone · 10. August 2026 um 04:21

Guten Morgen @schubi, ich bedanke mich für die Ergänzung der Temperaturanzeige. Außerdem finde ich es richtig klasse wie schnell und flexibel du auf Wünsche und Anregungen von uns reagierst Eine Bedienungsfrage ist bei mir noch offen: Wenn ich z.b. Abends die Rollladen automatisch schließen möchte ( Zeit, Lux oder Sonnenstand) allerdings Morgens manuell öffnen möchte muss ich was eintragen? Sonnenschutz tagsüber soll aktiv sein. VG

schubi · 10. August 2026 um 05:45

Danke dir! Ja, das geht – aber nicht über einen Haken, sondern über die Trennung von Hoch- und Runter-Bereich. Ein Rollladen hat ja zwei Bereiche: einen fürs Hochfahren und einen fürs Runterfahren, und die dürfen verschieden sein.

Rezept:

Einen zweiten Bereich anlegen, z. B. „Nur manuell hoch". Modus Zeit, die Uhrzeiten sind egal.
Bei den betroffenen Rollläden im Rollläden-Tab „Bereich hoch" auf diesen neuen Bereich stellen, „Bereich runter" bleibt dein bisheriger Bereich.
Den Schalter dieses neuen Bereichs ausschalten – im Dashboard die Bereichszeile, oder in HA switch.shutter_pilot_nur_manuell_hoch.
Damit fährt abends alles wie gehabt zu (Zeit, Lux oder Sonnenstand – ganz egal, das steckt im Runter-Bereich), und automatisch hochgefahren wird nie. Der Sonnenschutz bleibt vollständig aktiv, denn Beschattung, Lüften und die abweichende Schließposition hängen alle am Runter-Bereich, und der ist ja eingeschaltet.

Zwei Dinge, die dich sonst überraschen würden:

Wenn du morgens mal nicht von Hand öffnest und die Beschattung greift, fährt der Rollladen auf die Beschattungsposition – die Beschattung fährt auch aus dem Geschlossenen heraus dorthin.
Wandert die Sonne aus dem Fenster oder fällt eine Bedingung weg, fährt er auf „offen" zurück. Das ist die Freigabe der Beschattung, nicht das Morgen-Hochfahren. Nur am Tagesende (Sonne unter der eingestellten Mindesthöhe) bleibt er stehen, wo er ist.
Dass man die Automatik direkt am Rollladen getrennt für hoch und runter ein-/ausschalten kann, wäre die saubere Lösung dafür – wolfvs hat sich in diesem Thread gerade dasselbe gewünscht. Steht damit auf der Liste.

MartyBr · 10. August 2026 um 06:39

Meine Bereiche umfassen mehrere Räume. Zum Beispiel der Schlafbereich umfasst “Schlafzimmer”, “Ankleidezimmer” und “Badezimmer” mit unterschiedlichen Temperaturen. Ich glaube daher, dass der Temperatursensor zu den Rollos gehört. Da ich zur Beschattung Elevation, Azimuth, Solareinstrahlung und die Raumtemperatur nehmen, ist der Temperatursensor schon bei Rollos eingetragen.

schubi · 10. August 2026 um 12:26

Shutter Pilot 2.10.2 – der Aussperrschutz greift jetzt überall

Kurze Version: ein Einstellungs-Export aus dem Forum hat einen Fehler gefunden, den bisher niemand gemeldet hatte. Danke, Wolf.

Der Aussperrschutz galt beim Fensterkontakt nicht

Der Aussperrschutz sorgt dafür, dass ein Rollladen sich nicht vor der offenen Terrassentür schließt. Er hat an jedem automatischen Fahrweg gegriffen – Zeitplan, Helligkeit, Beschattung. Nur an einem nicht: ausgerechnet an dem, der ausschließlich bei offenem Fenster fährt.

Wen es betrifft: Rollläden mit Fensterkontakt, bei denen die Position „bei offenem Fenster" niedriger eingestellt ist als die Mindesthöhe des Aussperrschutzes. Besonders leicht passiert das bei einem Kontakt ohne Kipp-Zustand – der ist zweiwertig, gefahren wird dann immer die Kipp-Position.

Was passierte: Terrassentür auf, Rollladen fährt zu. Genau das, was die Einstellung verhindern soll.

Warum erst jetzt? Bis 2.8.0 erreichte der Fensterkontakt nur einen (nahezu) geschlossenen Rollladen – der fuhr dann von 0 auf 0, und der fehlende Deckel fiel nicht auf. Seit 2.8.1 nimmt auch der beschattete Rollladen den Kontakt an, und damit fährt er von 50 auf 0. Ein Fix hat eine alte Lücke scharf gestellt, ohne sie zu berühren.

„Bericht herunterladen" tat auf Android nichts

Der Knopf reagierte, die Datei kam nie an. Zwei Ursachen, am Rechner beide unsichtbar. Beide behoben. (Falls es bei euch trotzdem hakt: der Knopf Kopieren daneben funktioniert überall.)

Der Einstellungs-Export sagt jetzt mehr

Der Bericht ist seit 2.8.0 das Werkzeug für „warum fährt er nicht". Drei Dinge, die er bisher verschwiegen hat:

Er sagt, wenn die Merker gerade erst geleert wurden. Jedes Speichern im Panel lädt die Integration neu, und dabei fangen „beschattete Rollläden", „heute schon hochgefahren" und die wartenden Nachhol-Fahrten wieder bei null an. Wer direkt nach einer Änderung exportierte – also fast jeder – bekam eine Tabelle voller Striche und obendrein den Hinweis, das zu melden. Jetzt steht der Zeitpunkt des letzten Ladens dabei, mit der Erklärung.

Er benennt zwei Einstellungen, die dastehen und nichts tun:

Einstellung	warum sie wirkungslos ist
Eigene Werte für Sonnenhöhe/Fensterrichtung am Rollladen	„Eigene Ausrichtung" ist nicht angehakt → es gelten die Werte des Bereichs
Position für „Fenster offen"	Kontakt ohne Kipp-Zustand ist zweiwertig → gefahren wird immer die Kipp-Position

Beide standen bisher in der Tabelle wie jeder wirksame Wert, und nichts unterschied sie.

Warnung, wenn die Lux-Schwellen verkehrt herum stehen

Im Helligkeitsmodus wird oberhalb der Hoch-Schwelle hochgefahren und unterhalb der Runter-Schwelle runter. Die Hoch-Schwelle gehört also über die Runter-Schwelle. Steht sie darunter, gilt zwischen den beiden Werten beides gleichzeitig – überschneiden sich dann noch die Zeitfenster, pendelt der Rollladen.

Das Formular sagt das jetzt direkt unter den beiden Schiebern. Gleiche Art Hinweis wie bei den Bedingungsschwellen seit 2.8.0.

. Update über HACS, Browser neu laden – fertig. Es ändert sich keine Einstellung.

Wer einen Fensterkontakt mit Aussperrschutz nutzt, sollte danach einmal nachsehen, ob die Position bei offenem Fenster überhaupt so gemeint war – bisher konnte sie den Aussperrschutz unterlaufen, ohne dass es auffiel.

schubi · 10. August 2026 um 17:42

v2.10.3 – der Haken, den niemand gelesen hat

Ein Fehler, den der Einstellungs-Export sichtbar gemacht hat – gefunden nicht in
der Frage, die gestellt wurde, sondern in einer Zeile der Tabelle daneben.

Behoben

„Sonnenhöhe prüfen" wirkte am einzelnen Rollladen nicht.

Der Haken kam in 2.10.1 – für Bereich und Rollladen. Am Rollladen wurde er
auch gespeichert und angezeigt, aber die Beschattung hat ihn nie gelesen: dort
entschied weiterhin die Einstellung des Bereichs.

Betroffen ist, wer an einem einzelnen Fenster die Höhenprüfung abschalten
wollte – typischerweise das Fenster mit dem eigenen Helligkeitssensor. Der
Haken stand auf „aus", geprüft wurde trotzdem.

	vorher	jetzt
Haken am Bereich	wirkt	wirkt
Haken am Rollladen, „Eigene Ausrichtung" an	wirkungslos	wirkt
Haken am Rollladen, „Eigene Ausrichtung" aus	wirkungslos	es gilt der Bereich (wie bei allen Geometriewerten)

Geändert

Der Bericht lädt als .txt herunter. Inhalt und Aufbau sind unverändert –
nur die Endung ändert sich, damit sich die Datei im Forum hochladen lässt
(.md steht dort nicht auf der erlaubten Liste). Wer den Bericht wie bisher
einfügt statt hochlädt, merkt keinen Unterschied.

Der Export benennt eine abgeschaltete Höhenprüfung, die niemand liest.
Steht sie am Rollladen auf „aus", während „Eigene Ausrichtung" aus ist, dann
entscheidet der Bereich – der Haken stand bisher in der Tabelle wie jeder
wirksame Wert. Eingeschaltet bleibt er unerwähnt: das ist die Vorgabe.

Was ändert sich für mich?

Nichts, solange die Höhenprüfung überall eingeschaltet ist – das ist die
Vorgabe. Wer den Haken an einem Rollladen abgeschaltet hatte, bekommt ab jetzt
das Verhalten, das er eingestellt hat: dieser Rollladen beschattet dann allein
nach seinen Bedingungen, unabhängig davon, wie hoch die Sonne steht. Zusammen
mit „Eigene Ausrichtung" – ohne diesen Schalter gilt weiterhin der Bereich.

Danke an Wolf für den Export. Zwei Berichte, zwei Fehler, die vorher
niemand gemeldet hatte.

hollizone · 11. August 2026 um 04:13

Guten Morgen in die Runde, mir ist noch eine Kleinigkeit aufgefallen, vielleicht ist es aber auch ein Bedienungsfehler von mir. Ich steuer meine Rollladen aktuell via Lux- Stärke. Nun kommen wir langsam in die dunkle Jahreszeit und hier würde ich zusätzlich zum Lux Wert noch eine Zeit benötigen zu der der Rollladen spätestens öffnet wenn Lux Wert noch nicht erreicht ist. Oder mache ich hier einen Denkfehler? Parallel obwohl es bereits einen anderen Lösungsweg gibt fände ich es gut wenn durch weglassen der Öffnungszeit von-bis automatisch ein manuelles Öffnen hinterlegt wird. Vielen Dank

schubi · 11. August 2026 um 05:54

Hallo hollizone,

kein Denkfehler – das gab es wirklich nicht. Die Zeitfenster im
Helligkeitsmodus erlauben eine Fahrt nur, ausgelöst hat bisher immer allein
der Lux-Wert. Wird die Schwelle im Winter tagelang nicht erreicht, bleibt der
Rollladen unten.

Ist in 2.11.0 drin. Je Bereich zwei neue Einstellungen:

Einstellung	Wirkung
Spätestens hochfahren um	öffnet zu dieser Uhrzeit, unabhängig vom Lux-Wert
Spätestens runterfahren um	schließt zu dieser Uhrzeit, unabhängig vom Lux-Wert

Beide sind einzeln abschaltbar und standardmäßig aus – genau wie du es
vorgeschlagen hast. Wer sie nicht einschaltet, merkt vom Update nichts. Fürs
Wochenende gibt es je einen eigenen Wert; lässt du ihn leer, gilt der Wert der
Woche.

Zwei Dinge, damit die Frist nicht stört:

Sie bewegt keinen Rollladen, der ohnehin schon in diese Richtung gefahren
ist. Hat der Lux-Wert morgens um 07:20 geöffnet, passiert um 09:00 nichts mehr.
Beschattung und eine manuelle Position haben weiterhin Vorrang, und eine
Frist, die heute schon vorbei ist, wird nach einem Neustart nicht nachgeholt.

Die Felder stehen im Bereich unter Zeitplan, direkt unter den Sonnengrenzen.
Nach dem Update bitte einmal den Browser neu laden (Strg+F5), sonst zeigt Home
Assistant das alte Panel.

Zum zweiten Teil deines Vorschlags – Öffnungszeit weglassen = kein automatisches
Öffnen: das habe ich bewusst nicht mitgemacht. Ein leeres Feld heißt heute
„immer erlaubt", also genau das Gegenteil, und eine Umdeutung würde bei allen
Bestandsanlagen das Verhalten kippen. Wenn ein Bereich gar nicht automatisch
öffnen soll, ist der Weg weiterhin, ihm nur einen Runter-Bereich zu geben.

VG
Schubi

hollizone · 11. August 2026 um 08:02

@schubi Vielen Dank für die Umsetzung

Viktor · 11. August 2026 um 09:29

Hallo schubi,

baue vielleicht noch ein check ein, damit rollos nicht mehrfach hinzugefügt werden können. Ich habe mich versehentlich verklickt und hatte ein rollo zwei mal, jedoch in unterschiedlichen Bereichen.

Dies führte dazu das es im Minutentakt hin und her fuhr.

Mir ist es erst im export aufgefallen.

schubi · 11. August 2026 um 11:27

Shutter Pilot 2.11.1 ist da

Zwei Versionen an einem Tag – hier beides auf einmal, weil ihr beim Update
direkt auf 2.11.1 landet.

2.11.1 – kein Rollladen mehr doppelt

Viktor hat einen Fehler gefunden, den vorher niemand gemeldet hatte: Ein
Rollladen ließ sich versehentlich zweimal anlegen – bei ihm mit zwei
verschiedenen Bereichen. Die Folge war ein Rollladen, der im Minutentakt hoch
und runter fuhr: jeder der beiden Einträge entscheidet für sich, und die
beiden widersprechen sich jede Minute aufs Neue. In der Liste sieht man den
Doppeleintrag kaum – Viktor ist er selbst erst im Einstellungs-Export
aufgefallen.

Ab 2.11.1 ist das dicht:

Wo	Was passiert
Panel	Warnung direkt unter der Auswahl, sobald die Cover-Entität schon belegt ist – mit dem Namen des bestehenden Eintrags
Server	ein zweiter Eintrag für dieselbe Cover-Entität wird abgelehnt
Export	bestehende Doppeleinträge werden im Bericht benannt, bei beiden Zeilen

Den vorhandenen Eintrag zu bearbeiten geht unverändert. Und: Bestehende
Doppeleinträge räumt die Integration nicht von selbst weg – welcher der
beiden Bereiche gewinnen soll, kann nur ihr wissen. Ein Blick in den Export
zeigt euch, ob ihr betroffen seid.

2.11.0 – feste Uhrzeit im Helligkeitsmodus

Aus einer Meldung von hollizone: In der dunklen Jahreszeit wird die
Lux-Schwelle tagelang nie erreicht, und die Rollläden bleiben unten. Die
Zeitfenster helfen nicht – sie erlauben eine Fahrt nur, sie lösen keine aus.

Neu je Bereich: „Spätestens hochfahren um" und „Spätestens runterfahren
um". Beide sind einzeln einschaltbar und stehen standardmäßig auf aus –
wer zufrieden ist, merkt vom Update nichts. Wochenendwerte fallen wie überall
auf die Wochentagswerte zurück.

Die Frist bewegt keinen Rollladen, der ohnehin schon in diese Richtung gefahren
ist; Beschattung und eine manuelle Position haben weiterhin Vorrang, und nach
einem Neustart wird eine bereits vergangene Frist nicht nachgeholt.

Nach dem Update bitte einmal den Browser neu laden (Strg+F5), sonst zeigt
Home Assistant noch das alte Panel.

Danke an Viktor – so ein Bericht ist Gold wert, gerade weil das Symptom
(„fährt ständig hin und her") nach einem Automatik-Fehler aussieht und nicht
nach einem Doppeleintrag. Und danke an hollizone und Wolf, deren
Meldungen in 2.11.0 und 2.10.3 stecken.

hollizone · 11. August 2026 um 14:41

Vielen Dank für die Umsetzung

schubi · 11. August 2026 um 16:10

v2.12.0 – Markisensteuerung mit Wind- und Regenschutz

Markisen sind da

Der am häufigsten gewünschte Punkt aus dem Forum und der Umfrage: Shutter Pilot steuert jetzt auch Markisen – mit einem eigenen Tab und, vor allem, mit dem Teil, der eine Markisensteuerung erst betriebssicher macht: Wind-, Regen- und Frostschutz.

Für alle, die nur Rollläden haben, ändert sich nichts. Es kommt ein Tab dazu, der leer bleibt, bis du dort eine Markise anlegst.

Was eine Markise anders macht

Eine Markise ist kein umgedrehter Rollladen. Zwei Dinge sind grundlegend anders, und beide sind berücksichtigt:

Sie fährt in keinem Zeitplan mit. Uhrzeit, Helligkeit, Sonnenauf- und -untergang bewegen sie nicht. Ausgefahren wird sie allein von der Beschattung – und die rechnet mit genau denselben Regeln, die du von den Rollläden kennst: Sonnenhöhe, Fensterrichtung, bis zu vier Zusatzbedingungen, Beschattungszeitraum, Haltezeit gegen durchziehende Wolken.

Sie hat nur zwei Positionen statt fünf:

Position	Bedeutung	Vorgabe
Ruhestellung	eingefahren, wenn keine Beschattung nötig ist	0 %
Beschattung	ausgefahren zum Beschatten	100 %

Fensterkontakt, Aussperrschutz, Lamellen, abweichende Schließposition, Frostposition und automatisches Lüften gibt es an einer Markise nicht – das Formular zeigt sie gar nicht erst.

Wind-, Regen- und Frostschutz

Der Teil, ohne den das Ganze nicht verantwortbar wäre.

Unter Einstellungen trägst du Wind-, Regen- und Temperatursensor ein. Sie gelten für jede Markise im Haus. Beim Wind darf eine einzelne Markise davon abweichen: eigener Sensor (ein Balkon hinterm Haus sieht anderen Wind als die Terrasse) oder nur eigene Schwellen (ein kleiner Gelenkarm muss früher rein als eine Kassette am selben Sensor). Regen und Frost bleiben global – die fallen überm ganzen Haus gleich.

Wie es wirkt:

Über der Einfahrschwelle fährt die Markise sofort ein und darf nicht mehr ausfahren.
Freigegeben wird sie erst wieder unter der zweiten Schwelle und nach einer Sperrzeit (Vorgabe 20 min bei Wind, 30 min bei Regen). Eine Bö ist nach zwanzig Sekunden vorbei – die Markise soll trotzdem nicht sofort wieder heraus. Jede neue Überschreitung startet die Zeit von vorn.
Reagiert wird in Sekunden, nicht im Minutentakt: der Schutz hängt direkt an den Sensoren.

Wichtig zu wissen: Der Schutz gilt auch bei ausgeschaltetem Hauptschalter und ausgeschalteter Automatik. Hauptschalter aus, Bereichsautomatik aus, Markisen-Automatik aus – eingefahren wird trotzdem.

Das ist eine bewusste Abweichung von der sonst geltenden Rangfolge. Ein Schutz, der sich versehentlich abschalten lässt, ist keiner. Abschalten geht absichtlich: den Sensor entfernen.

Wenn der Sensor ausfällt: Meldet er unavailable oder unknown, weiß niemand, was der Wind tut. Ausgefahren wird dann ab der ersten Sekunde nicht mehr. Eine bereits ausgefahrene Markise wird aber erst nach einer Karenzzeit (Vorgabe 10 min) hereingeholt – ein Sensor, der beim Neustart kurz aussetzt, soll nicht das ganze Haus einfahren.

Ausfahrlänge nach Sonnenhöhe

Optional, standardmäßig aus. Steht die Sonne hoch, reicht wenig Ausfall; sinkt sie, braucht dieselbe Fläche mehr. Zwei Stützpunkte, gerade Linie dazwischen:

Sonne steht hoch bei 60°  →  ausfahren auf  60 %
Sonne steht tief bei 20°  →  ausfahren auf 100 %

Dazu eine Mindeständerung (Vorgabe 10 %). Ohne die liefe der Antrieb jede Minute ein paar Prozent – der sicherste Weg, ein Getriebe zu verschleißen.

Neue Entitäten, Dienst und Ereignis

Art	Name	Wofür
Binärsensor	`binary_sensor.shutter_pilot_<name>_sperre`	`on`, solange die Markise nicht ausfahren darf. Attribute: Grund und Restzeit
Schalter	`switch.shutter_pilot_markise_<name>`	Automatik je Markise (der Schutz gilt trotzdem)
Dienst	`shutter_pilot.retract_awnings`	Alle Markisen sofort einfahren, ohne Staffelung – für eine angekündigte Sturmwarnung. Bereich optional
Ereignis	`shutter_pilot_awning_retracted`	Mit `entity_id` und `reasons` – für eigene Push-Nachrichten

Behoben: Antriebe ohne Positionsmeldung

Betrifft auch Rollläden. Viele Markisenmotoren und etliche ältere Rollladenantriebe kennen nur auf, stop und zu. Shutter Pilot schickte trotzdem immer einen Positionsbefehl – der scheitert an solchen Antrieben, und seit 2.8.0 wird eine gescheiterte Fahrt jede Minute wiederholt. Aus einem stummen Fehler wurde also eine Endlosschleife.

Jetzt wird selbstständig auf „ganz auf" bzw. „ganz zu" ausgewichen. Eine Teilposition an so einem Antrieb steht einmal als Warnung im Log.

Der Export beantwortet „warum ist die Markise nicht draußen"

Je Markise eine Tabelle mit Wert, Einheit, Schwellen und Ergebnis je Schutz, dazu die Freigabezeit:

Wind  sensor.wind  34,1 km/h  einfahren ab 30 / frei unter 15  ⛔ wind
Ergebnis: gesperrt · Grund: wind
Freigabe frühestens in 12 min.

Und eine Warnung, die vermutlich einigen Ärger erspart: misst dein Windsensor in m/s und die Schwelle sieht nach km/h aus, steht das im Bericht. Faktor 3,6 daneben heißt, die Markise fährt nie ein. (25 km/h sind rund 7 m/s.)

Bestehenden Rollladen als Markise übernehmen

Du hast die Markise schon als Rollladen angelegt? Wähle im Markisen-Tab dieselbe Cover-Entität aus – dann erscheint ein Knopf „Als Markise übernehmen". Fenster-, Lamellen- und Schließ-Einstellungen werden dabei gelöscht statt stehengelassen, und die beiden Positionen auf die Markisen-Vorgabe gesetzt.

Was ändert sich für mich?

Du hast …	… dann
nur Rollläden	nichts ändert sich. Ein leerer Tab kommt dazu
einen Antrieb ohne Positionsmeldung	er fährt jetzt überhaupt, statt es jede Minute vergeblich zu versuchen
eine Markise	Tab „Markisen", Sensoren unter Einstellungen eintragen, fertig

Nach dem Update den Browser einmal neu laden (Strg+F5 / Cmd+Shift+R), sonst zeigt das Panel die alte Fassung.

Unter der Haube

Markisen liegen in derselben Liste wie die Rollläden, unterschieden durch einen einzigen neuen Schlüssel. Dadurch gelten Fahrtkontrolle, Positionsspeicher, globaler Mindestabstand, manuelle Übersteuerung und die Doppel-Eintrag-Sperre aus 2.11.1 unverändert – ohne dass an bestehenden Konfigurationen etwas migriert werden muss.