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

– Aussperrschutz und Beschattung ausschließen

Hallo Linos,

du hast nichts falsch gemacht – beides waren Fehler bei mir, und beide sind
in 2.17.0 behoben.

1. Der Aussperrschutz galt bei den Dashboard-Knöpfen nicht. Die
Bereichsknöpfe rufen die cover-Dienste direkt auf, damit Home Assistant die
Rechte je Entität prüft (so bleibt das Panel auch für Mitbewohner ohne
Adminrechte bedienbar). Der Aussperrschutz sitzt aber im Backend – und war
damit ausgerechnet an der Stelle wirkungslos, an der man ihn am ehesten
braucht. „Esszimmer rechts" hat lock_protection mit Mindesthöhe 100 %; über
den Dienst shutter_pilot.sun_protect_group wäre er bei offener Tür gar nicht
gefahren, über den Knopf fuhr er auf 40. Ab 2.17.0 klemmen Runter,
Sonnenschutz und Lüften
auch im Panel auf die Mindesthöhe.

2. „Esszimmer rechts" soll gar nicht beschattet werden. Dafür gibt es jetzt
im Rollladenformular den Haken „An der Beschattung teilnehmen" – abwählen,
fertig. Zeitplan, Lüften und Fensterkontakt laufen weiter, er fährt morgens
hoch wie alle anderen. Deine beiden Ideen hätten das nicht sauber gelöst:
Beschattungsposition auf 100 % heißt „beschatte ihn, indem du ihn öffnest"
(und er zählt dann als beschattet, was das automatische Hochfahren blockiert),
und den Bereich ohne Beschattung anzulegen nimmt sie den anderen zwei
Esszimmer-Rollläden mit weg.

Zwei Sachen aus deinem Export nebenbei, die du wahrscheinlich nicht so wolltest:

  • Bei „Esszimmer rechts" und „Gäste beide" sind eigene Werte für
    Sonnenhöhe/Fensterrichtung hinterlegt, aber „Eigene Ausrichtung" ist aus –
    es gelten die Bereichswerte (90°–300°). Nach dem Abwählen der Beschattung ist
    das bei „Esszimmer rechts" egal, bei „Gäste beide" nicht.
  • Der Bedingungs-Slot c (Lichtsensor ≥ 2800 lx) steht in allen fünf
    Bereichen und ist die einzige Bedingung, die gerade nicht erfüllt ist. Das ist
    vermutlich Absicht (abends 53 lx), nur zur Sicherheit erwähnt.

Danke fürs Melden – der erste Punkt war ein echtes Loch.


## @Smons – Rollläden fahren morgens nicht hoch

Moin Smons,

**gefunden, und es ist ein Fehler bei mir.** In 2.17.0 behoben.

Alle deine Süd-Rollläden stehen im Export auf `0 %` mit **Quelle: manual**, und
dein Bereich steht auf **Manuelle Übersteuerung: „nie"**. Das bedeutet: eine
von Hand gefahrene Position blockiert das automatische Öffnen bis zum nächsten
Schließen. Gelöscht wurde diese Markierung bisher aber **nur von einer

automatischen Fahrt**. Wer abends selbst zufährt – Wandschalter, eigene

Automation oder der Runter-Knopf im Shutter-Pilot-Dashboard –, bekam damit nie
wieder ein automatisches Auf. Genau das ist bei dir passiert, und es ist der
Grund, warum um 6:38 nichts kam.

Ab 2.17.0 gilt: eine Handposition, die **eine der Schließpositionen dieses

Rollladens** ist (bei dir 0 %), ist keine Übersteuerung, sondern das, was die

Automatik selbst gefahren wäre. Eine Position **dazwischen** – etwa 50 % zum
Abdunkeln – bleibt eine Übersteuerung wie bisher.
Die Uhrzeit selbst stimmte: Sonnenaufgang 06:38 liegt sauber in deinem Fenster

`sun_earliest_up 06:30` / `sun_latest_up 07:00`. Die Rechnung war also richtig,

gefahren ist nur keiner.

Eine Sache, die du trotzdem prüfen solltest, weil sie am selben Morgen
mitgespielt haben kann: Im Bereich **„Süd"** steht `sun_we_earliest_up` auf

**09:00**, und an einem Tag, den `binary_sensor.arbeitstag` als *keinen*

Arbeitstag meldet, gilt genau dieser Wert – dann wäre 06:38 auf 09:00
geschoben worden. Aus dem Export lässt sich der Sensorzustand nicht ablesen;
schau bei Gelegenheit nach, ob er an dem Morgen `on` war. (Am Ergebnis hätte es
nichts geändert – der Merker „manuell" hätte auch um 09:00 blockiert.)

Zwei weitere Kleinigkeiten aus dem Export:

* Ebenfalls in **„Süd"**: eine Wochenend-Obergrenze fehlt und fällt auf

`sun_latest_up` (07:00) zurück. Die untere Wochenendgrenze 09:00 liegt damit

**hinter** der oberen; es gewinnt die untere, also 09:00. Falls du am

Wochenende 09:00 willst, passt das – sonst trag `sun_we_latest_up` mit ein.

* An **„Tina"**, **„Schlafzimmer Tür"**, **„Wohnzimmer Ost"**, **„Gästebad"**,

**„Gästezimmer"** und **„Küche"** hat der Fensterkontakt keinen Kipp-Zustand.

Der Kontakt ist damit zweiwertig, und gefahren wird immer

`position_when_window_tilted` (50 %) – auch bei „offen".

`position_when_window_open` (100 %) wird nie benutzt. Der Export sagt das

inzwischen an jedem betroffenen Rollladen.

@c.radi – Bereich Schlafzimmer fährt weder hoch noch runter

Guten Morgen c.radi,

zwei Fehler bei mir, einer bei dir. Die beiden Fehler sind in 2.17.0
behoben.

1. Der „hoch"-Knopf fuhr den deaktivierten Rollladen mit. Richtig gesehen,
das war falsch. Ein Gruppenknopf im Dashboard ist der Bereich, der handelt –
der Schalter am Rollladen gilt also, und er steht zwei Zeilen über dem Knopf.
Ab 2.17.0 überspringen die Bereichsknöpfe abgeschaltete Rollläden. Die kleinen
Knöpfe in der Rollladenzeile fahren ihn weiterhin – genau damit prüfst du
ihn, wenn er repariert ist.

2. Eine blockierte Richtung fror die andere ein. Shutter Pilot merkt sich je
Rollladen, ob er „oben" oder „unten" gilt, damit er nicht zweimal am Tag in
dieselbe Richtung fährt. Gepflegt wurde das bisher nur von eigenen Fahrten. In
deinem Export steht „Schlafzimmer rechts" unter heute schon runtergefahren –
seit dem letzten Neuladen vor gut zwei Tagen. Blieb das Hochfahren einmal aus,
galt er ab da für immer als unten, und die Abendfahrt fiel ebenfalls aus.
Ihn von Hand hochzuziehen half nicht, weil das niemand mitgeschrieben hat. Ab
2.17.0 zählen Fahrten von Hand mit.

3. Und jetzt der Teil, den ich nicht patchen kann. Dein Helligkeitssensor
ist sensor.0_0_aussen_nord_bewegungsmelder_beleuchtungsstarke – die
Beleuchtungsstärke eines Bewegungsmelders. Solche Sensoren melden meist nur
bei Bewegung einen neuen Wert, und der Helligkeitsmodus reagiert auf genau
diese Meldungen. In deinem Hoch-Fenster 06:30–07:00 bewegt sich morgens
draußen an der Nordseite oft niemand, also kommt kein Wert und es fährt nichts.

Zwei Wege:

  • Sauber: einen Helligkeitssensor nehmen, der zyklisch meldet (ein reiner
    Lux-Sensor, oder ein Template-Sensor, der den Wert regelmäßig fortschreibt).
  • Sofort: deine Frist „spätestens hoch" nutzen – die hängt am Minutentakt
    und braucht keinen Sensorwert. Sie steht bei dir auf 07:15, dein
    Hoch-Fenster endet aber um 07:00. Das ist erlaubt und funktioniert, sieht
    aber verkehrt aus. Wenn du „zwischen 6:30 und 7:00 hoch" willst, setz
    w_up_to auf 07:15 oder die Frist auf 07:00.

Für dein zweites Ziel – „abends mit Dämmerung runter" – passt der
Helligkeitsmodus grundsätzlich, aber mit demselben Sensorproblem. Die Frist
„spätestens runter 22:00" hast du ja schon gesetzt, die greift auf jeden Fall.

Und noch ein Haken, den du gesetzt hast und der leicht in Vergessenheit gerät:
im Bereich „Schlafen" steht „Am Wochenende nicht hochfahren" auf an. An
jedem Tag, den binary_sensor.workday_sensor als freien Tag meldet – also auch
an Feiertagen –, fährt dort morgens gar nichts hoch, unabhängig von allem
oben. Runterfahren und Beschattung laufen weiter.

Noch ein Hinweis: die Bereiche „Arbeiten" und „Wohnen" stehen beide auf
Automatik aus. In „Arbeiten" berechnet der Export bei „Arbeitszimmer links"
sogar „Ergebnis: beschatten" – gefahren wird trotzdem nichts, weil die
Bereichsautomatik aus ist. Falls das Absicht ist:

@pcsv17 – zweite Beschattungsposition

Hi pcsv17,

beides gibt es ab 2.17.0.

Binär geschaltet: Die Bedingung stellst du am Bereich ein (Abschnitt
Sonnenschutz, ganz unten: „Zweite Beschattungsposition"), die Position am
Rollladen. Dasselbe Paar wie beim abweichenden Schließen. Als Bedingung geht
alles, was Shutter Pilot sonst auch nimmt: ein input_boolean, ein Schalter,
ein Zeitplan, ein Zahlenwert mit Hysterese (z. B. „ab 28 °C, wieder aus unter
25") oder eine Liste von Zuständen. Trifft sie zu, fahren alle Rollläden mit
hinterlegter zweiter Position dorthin – auch mitten in einer laufenden
Beschattung
, nicht erst beim nächsten Mal.

Variabel per Entität: Im Rollladenformular gibt es das Feld
„Beschattungsposition aus Entität". Trag dort ein input_number, einen
Template-Sensor oder irgendetwas ein, das eine Zahl von 0 bis 100 liefert. Die
gewinnt über beide festen Positionen und wirkt sofort. Ist der Wert unlesbar
oder außerhalb 0–100, gilt weiter die eingestellte Position – eine Beschattung,
die aussetzt, weil ein Template gerade nichts liefert, wäre der schlechtere
Ausfall.

Beides ist optional; wer nichts einträgt, merkt keinen Unterschied.

v2.17.0 – Aussperrschutz an den Dashboard-Knöpfen, zweite Beschattungsposition

Vier Beiträge aus dem Forum an einem Tag – drei davon waren Fehler bei mir. Zwei hängen zusammen: die Knöpfe im Dashboard fuhren an einem Teil der Automatik vorbei.

:lady_beetle: Behoben

Der Aussperrschutz galt bei den Dashboard-Knöpfen nicht

„Ich habe den Button ‚Sonnenschutz’ betätigt und es sind alle Rollläden gefahren, auch der mit Aussperrschutz." — Linos

Genau so war es. Die Dienste close_group und sun_protect_group klemmen die Zielposition seit jeher auf die Mindesthöhe – die Knöpfe im Panel aber rufen die cover-Dienste direkt auf. Das ist Absicht (nur so prüft Home Assistant die Rechte je Entität, und nur so bleibt das Panel für Mitbewohner ohne Adminrechte bedienbar), hieß aber: der Aussperrschutz war ausgerechnet dort wirkungslos, wo man ihn am ehesten braucht – mit offener Terrassentür daneben.

Ab jetzt klemmen „Runter", „Sonnenschutz" und „Lüften" auch im Panel auf die Mindesthöhe.

Die Gruppenknöpfe fuhren abgeschaltete Rollläden mit

„Betätige ich den ‚hoch’-Button werden beide Rolläden bedient, obwohl der linke deaktiviert ist. Der ist aktuell defekt." — c.radi, unabhängig auch Linos

Ein Gruppenknopf ist der Bereich, der handelt – der Schalter am Rollladen gilt also, und er steht zwei Zeilen über dem Knopf.

Womit gefahren wird Schalter am Rollladen gilt?
Bereichsknöpfe auf der Dashboard-Karte ja (neu)
kleine Knöpfe in der Rollladenzeile nein
Dienste open_group, close_group, … nein

Die letzten beiden sind der Weg „von Hand" – genau damit prüft man einen Antrieb, wenn er repariert ist.

Von Hand zufahren sperrte das automatische Hochfahren – dauerhaft

„Meine Rollläden sollten heute morgen um 6:38 bei Sonnenaufgang hochfahren. Leider haben Sie das nicht." — Smons

Wer abends selbst schließt – Wandschalter, eigene Automation oder der Runter-Knopf im Dashboard – erzeugt eine Position mit der Quelle „manuell". Bei der Einstellung Manuelle Übersteuerung: „nie" blockiert die das Öffnen bis zum nächsten Schließen. Gelöscht wurde diese Markierung bisher aber nur von einer automatischen Fahrt. Wer immer von Hand schloss, bekam also nie wieder ein automatisches Auf.

Jetzt gilt: eine Handposition, die eine der Schließpositionen dieses Rollladens ist, ist keine Übersteuerung, sondern das, was die Automatik selbst gefahren wäre. Eine Position dazwischen – etwa 50 % zum Abdunkeln – bleibt eine Übersteuerung wie bisher.

Eine blockierte Fahrtrichtung fror die andere ein

„Der Bereich Schlafzimmer fährt weder hoch noch runter." — c.radi

Shutter Pilot merkt sich je Rollladen, ob er „oben" oder „unten" gilt, damit er nicht zweimal am Tag in dieselbe Richtung fährt. Gepflegt wurde das nur von eigenen Fahrten. Blieb das Hochfahren einmal aus, galt der Rollladen ab da für immer als „unten" – und die Abendfahrt fiel ebenfalls aus. Ihn von Hand hochzuziehen half nicht, weil das niemand mitschrieb.

Fahrten von Hand zählen jetzt mit, aber nur an den beiden Enden: eine Position dazwischen sagt nichts darüber, in welcher Tageshälfte der Rollladen steht.

Kleinigkeiten

  • Lüften kannte den Aussperrschutz nicht. ventilate_group fährt nach unten wie jedes Schließen, klemmte die Position aber als einziger Fahrweg nicht.

  • Der Dateiname des Exports stand in UTC, der Kopf des Berichts in Ortszeit – zwei Stunden Unterschied. Beim Vergleich zweier Exporte sah der neuere nach dem älteren aus.

:sparkles: Neu

Zweite Beschattungsposition

„Wäre es möglich, eine 2. Beschattungsposition anzulegen, die binär aktiviert wird, oder die eine Beschattungsposition variabel per Entität zu verändern?" — pcsv17

Beides. Eine Beschattungsposition ist ein Kompromiss: tief genug gegen die Mittagshitze heißt an einem milden Tag unnötig dunkel.

Wo einstellen Was
Bereich → Sonnenschutz die Bedingung, unter der die zweite gilt
Rollladen → Positionen die zweite Position selbst

Dasselbe Paar wie beim abweichenden Schließen. Als Bedingung geht alles, was Shutter Pilot sonst auch nimmt: ein input_boolean, ein Schalter, ein Zeitplan, ein Zahlenwert mit Hysterese („ab 28 °C, wieder aus unter 25") oder eine Liste von Zuständen. Sie greift sofort, auch mitten in einer laufenden Beschattung.

Stufenlos geht über das Feld „Beschattungsposition aus Entität" am Rollladen: ein input_number, ein Template-Sensor, irgendetwas mit einer Zahl von 0 bis 100. Die gewinnt über beide festen Positionen. Ist der Wert unlesbar oder außerhalb 0–100, gilt weiter die eingestellte Position – eine Beschattung, die aussetzt, weil ein Template gerade nichts liefert, wäre der schlechtere Ausfall.

Einen einzelnen Rollladen von der Beschattung ausnehmen

„Wie schließe ich den Rollladen generell aus dem Beschatten aus?" — Linos

Neuer Haken im Rollladenformular: „An der Beschattung teilnehmen" (Vorgabe: an). Abwählen nimmt nur die Beschattung heraus – Zeitplan, Lüften und Fensterkontakt laufen weiter, und der Rollladen fährt morgens hoch wie alle anderen. Steht er beim Abwählen gerade auf Beschattungshöhe, wird er freigegeben statt dort eingefroren.

:light_bulb: Der Automatik-Schalter am Rollladen ist etwas anderes: der hält jede automatische Fahrt an, auch das Öffnen am Morgen. Er ist für den defekten Antrieb gedacht.

Der Export beantwortet „warum fährt er morgens nicht hoch"

Bisher stand dazu nichts im Bericht: jede Sperre auf diesem Weg ist lautlos und hinterlässt keinen Merker – zu sehen war nur, dass nichts gefahren ist, und das ist das Symptom, nicht die Ursache.

Der Export nennt jetzt je Rollladen den Hauptschalter, die Bereichs- und Rollladenautomatik, die Wochenend- und „nicht hochfahren"-Sperre und eine blockierende Handposition samt ihrem Wert. Dazu die gerade geltende Beschattungsposition und woher sie kommt – und eine Warnung, wenn eine zweite Position hinterlegt ist, für die es im Bereich gar keine Bedingung gibt.

:counterclockwise_arrows_button: Was ändert sich für mich?

Wenn du nichts einstellst: Die vier Fehler oben sind weg. Am spürbarsten für alle, die abends von Hand zufahren – bei denen fährt jetzt wieder etwas hoch.

Die neuen Felder sind alle optional. Wer sie leer lässt, merkt keinen Unterschied.

Eine Umbenennung im Export: Die Merker heißen jetzt „gilt als oben" und „gilt als unten" statt „heute schon hoch-/runtergefahren". Das stimmte schon vorher nicht ganz – sie überleben den Tageswechsel und werden seit dieser Version auch von Fahrten von Hand gesetzt.

Super, vielen Dank für das schnelle Feeddback. Ich werde mal nach vernüfntigen Helligkeitssensoren Ausschau halten. Der von HomeaticIP ist nun leider schon zum zweiten mal defekt.

Das Arbeitszimmer hatte ich angefangen anzulegen, wollte aber erstmal in einem Bereich testen. Mir fehlt einfach Zeit….

Gruß
Christian

Hi @Schubi
vielen dank ich werde das heute Abend testen.
Eines ist mir noch aufgefallen:
Ich habe eine Balkontür mit Fensterkontakt.
Wenn ich die Tür öffne soll das Rollo komplett hochfahren (um hinauszugehen :smiley: ), daher habe ich auch den Aussperrschutz aktiv. Das Rollo fährt aber nur in diese Position, wenn es vorher ganz geschlossen war. Wurde das Rollo manuell auf z.B 45 % gefahren und ich öffne dann die Tür passiert nichts. Unabhängig von dem Aussperrschutz fährt er beim öffnen auch nicht die Position “bei Fenster offen” an. Ich denke mal das ist der manuellen Fahrt geschulded. Aber bei der Tür sollte das öffnen priorität haben.

Mein HomematicIP Helligkeitssensor ist zwar nicht defekt aber mir fällt jetzt eher auf die Füße, dass er nur in eine Himmelsrichtung schaut.

Die letzten Tage wurden meine Schatten-Bedingung echt stark auf die Probe gestellt → überspitzt gesagt: der Helligkeitssensor hat „dunkel“ gemessen im Norden und im Süden hätte beschatte werden können.

Aufgrund der neuen Fähigkeit mit ShutterPilot Beschattung per Ausrichtung zu fahren überlege ich meine Bedingungen plausibler zu gestalten.

Wetterstation, die Helligkeit von oben kommend erfassen (ecowitt ws90 wohl ganz gut) oder über den PV-Ertrag (ich habe drei Ausrichtungen). Allerdings fehlt mir noch der Schubs in die richtige Richtung bzw Erfahrung für „richtiges“ Beschattung-messen

Hallo @Schubi

vielen Dank für die Rückmeldung.

Alle meine Rollläden sind gestern Abend automatisch durch Shutter Pilot geschlossen worden, dann hätte doch heute Morgen die Automatik auch greifen müssen an einem Arbeitstag um 6.38.

Ich teste mit der neuen Version und melde mich erneut, wenn es nicht funktioniert.

Danke für die weiteren Hinweise, die ich korrigiert habe.

Noch ein Vorschlag zum Dashboard:

Ich fände noch ein möglichst kompakter Block oberhalb der Bereiche sinnvoll, der Aktionen und Informationen bereitstellt, die für alle Bereiche gelten.

Aktionen:

  • Alle Rollläden hoch
  • Alle Rolläden runter
  • Alle Rolläden stop
  • Automatik für alle aus
  • Automatik für alle an
  • Beschattung für alle aus (wo verwendet)
  • Beschattung für alle an (wo verwendet)
  • Lüften

Informationen:

  • Nächster Sonnenaufgang
  • Nächster Sonnenuntergang
  • Aktuelle Elevation
  • Aktueller Azimut
  • Höchsttemperatur heute
  • Wetterlage heute

Gruß
Horst

@Schubi , hier würde ich mich anschließen allerdings mit Entitäten → für das HA-Dashboard.

Wenn ich noch „wünsch dir was“ machen darf​:sweat_smile: Sensor.Entität als Statusanzeige. Ich hätte die Idee

  • primär-status: Geöffnet / Geschlossen
  • sekundär-status: „Beschattung aktiv Ost, Süd“

Hallo Schubi,

Erst einmal vielen Dank für die neuen Versionen. Ich habe sie installiert und zur Info angehängt. Ich gehe gleich noch mal darauf ein. Zuerst zu deinen Fragen:

Beide Markisen sind über das Somfy Connectivity Kit mit Overkiz in MA eingebunden

Im ausgefahrenen Zustand zigt der Druck auf die Stopptaste vom Dashboard keinerlei Reaktion

Die My-Positon habe ich ungefähr bei 50% festgelegt.

Bei der letzten Frage weiß ich nicht, ob ich an der richtigen Stelle geschaut habe. Bei mir ist der Pfad Werkzeuge > Zustände. Unter Entität steht dort “button.terasse_markise_hinten_my_position” und bei Zustand Datum und Uhrzeit wo ich es heute über HA “gedrückt” habe.

Nun zu meinen Beobachtungen:

Das Feststellen des oberen Bereiches funktioniert nur teilweise, soll heißen auf dem Android Handy funktioniert es aber auf dem Android Tablet leider nicht. Weder im Quer- noch im Hochformat.

Das Gleiche trifft für die Änderung des Lux-Wertes zu.

Die Sensoren habe ich jetzt korrigiert, muss morgen aber mal schauen, da mir heute vor Einspielung der neuen Version bei dem Bereich “ Wohnbereich Seite” etwas komisch vorkam. Dort sollen beide Rolladen grundsätzlich immer hoch sein und nur zur Beschattung runter fahren und nach Beendigung wieder rauf fahren. Deswegen ist der Modus auf Helligkeit gestellt. Eingegrenzt werden soll das ganze duch die Zeit, nicht vor 11Uhr und auch nur über 20ºC. Heute kam es mir so vor, als wenn die Helligkeit nicht beachtet wurde sondern nur die Zeit. Aber wie gesagt ich schaue mir das morgen noch mal an.

Der neue Modus “Kein Zeitplan” kann meine beiden Abwesenheitsbereiche leider nicht ersetzen. Die “Rollade Küche vorne” ist zum Hochfahren dem Bereich “Wohnbereich vorne”zugeordnet und benötigt keinerlei Beschattung oder Sonnenschutz. Bei Anwesenheit wird sie immer manuell zu unterschiedlichen Zeiten runter gefahren.

Die “Rollade Zimmer vorne” ist genau umgekehrt. Diese wird bei Anweseheit immer manuell zu unterschiedlichen Zeiten hochgefahren und nur bei Abwesenheit nach Sonnenstand hochgefahren. Sonnenschutz und runterfahren abends erfolgt über die Automatik.

Gruß

Wolf

Shutter pilot 2.17.txt (26,9 KB)

@wolfvs – My-Position, Tablet, und „Wohnbereich Seite"

Hallo Wolf,

danke für die Antworten – eine davon war der fehlende Baustein.

button.terasse_markise_hinten_my_position – genau das war die Lücke

Damit ist die My-Position kein Rätsel mehr, sondern ein Knopfdruck. Im
Markisenformular gibt es unter „Antrieb meldet keine Position" jetzt zwei neue
Felder:

  • „My"-Position – die Entität, also genau dein button.…_my_position
  • Welcher Position entspricht „My" – bei dir laut deiner Angabe 50 %

Jede Fahrt, die höchstens 15 % daneben liegt, drückt dann diesen Knopf, statt
auf einen Endanschlag auszuweichen.

Warum das für dich wichtig ist: an beiden Markisen ist „Ausfahrlänge nach
Sonnenhöhe" eingeschaltet (hinten 50–100 %, vorne 60–100 %), und beide melden
keine Position (blind_drive, im Export steht „Position jetzt: –“). Ohne
My-Position wird aus jedem Wert ab 50 % schlicht „ganz ausfahren” – die
Nachführung hat bei dir bisher also gar nichts bewirkt. Mit der My-Position
werden die 50 % bzw. 60 % zu einer echten Stellung.

Der Export sagt das jetzt auch von selbst: er nennt bei einem Antrieb ohne
Positionierung, welches Kommando gefahren wird, und warnt, wenn die
Nachführung an so einem Antrieb läuft.

Die Stopptaste

„Im ausgefahrenen Zustand zeigt der Druck auf die Stopptaste keinerlei
Reaktion." Das passt zusammen: cover.stop_cover sagt dem Motor „halt an" –
wenn er ohnehin steht, hat er nichts anzuhalten. Bei RTS ist Stop-im-Stillstand
das My-Kommando, über Overkiz aber offenbar nicht durchgereicht. Nimm dafür
deinen My-Knopf; genau deshalb ist er jetzt eingebaut.

Feststehende Reiter und Lux-Feld: Handy ja, Tablet nein

Beides waren echte Fehler, beide behoben:

  • Reiter: der Rückfall für ältere Browser machte das Panel selbst zum
    Scrollbereich, und ein „feststehendes" Element darin klebt an nichts. Auf
    Browsern, die den moderneren Weg kennen, fiel das nicht auf – auf der
    WebView deines Tablets schon. Der Rückfall ist weg.
  • Lux-Feld: das Feld zeichnete sich bei jedem Tastendruck neu, und auf
    manchen Android-WebViews springt dabei der Cursor. Jetzt wird erst beim
    Verlassen des Feldes neu gezeichnet.

Ich kann beides nicht auf deinem Tablet nachstellen – sag bitte Bescheid, ob es
mit 2.18.0 geht.

„Wohnbereich Seite" – kein Fehler, der falsche Modus

„Dort sollen beide Rolladen grundsätzlich immer hoch sein und nur zur
Beschattung runter fahren und nach Beendigung wieder rauf. Heute kam es mir so
vor, als wenn die Helligkeit nicht beachtet wurde sondern nur die Zeit."

Das ist genau das, was passiert – nur ist es kein Fehler, sondern die Folge
deiner Werte. Dein Sensor ist der Außen-Helligkeitssensor der Wetterstation;
der meldet im Sommer Zehntausende Lux. Deine Schwelle „Hoch" steht auf 2000.
Sobald das Zeitfenster 11:00–16:00 aufgeht, ist die Schwelle also längst
überschritten – es sieht aus, als entscheide nur die Uhr, weil die Helligkeit
zu dem Zeitpunkt nie die Frage ist.

Für „immer oben, nur zur Beschattung runter" ist der richtige Modus seit 2.16.0
„Kein Zeitplan". Dann fährt gar nichts nach Uhrzeit oder Helligkeit, es
gelten nur Beschattung und Lüften – und am Ende des Beschattungstags wird immer
geöffnet. Dein Haken „Am Ende des Beschattungstags öffnen" steht ohnehin schon
auf ja.

Zwei Werte, die dabei auffallen: In diesem Bereich ist die Sonnenhöhe
abgeschaltet
(elevation_enabled: nein) und die Fensterrichtung steht auf
125°–345°, also über 220° Spanne. Damit ist die Geometrie praktisch immer
erfüllt, und die einzige echte Bedingung ist deine Temperatur über 20 °C – die
Beschattung läuft dort im Sommer also fast durchgehend. Wenn das so gewollt
ist, ist alles gut; wenn nicht, ist die Sonnenhöhe der Hebel.

Die Abwesenheitsbereiche

„Der neue Modus ‚Kein Zeitplan’ kann meine beiden Abwesenheitsbereiche leider
nicht ersetzen."

Richtig, und das ist auch nicht sein Zweck. Deine Bereiche „Abwesend hoch" und
„Abwesend runter" sollen ja bei Abwesenheit fahren – sie stehen nur auf
Automatik aus, solange du da bist. Das ist genau der richtige Aufbau: zwei
Bereiche, die du über ihren Automatik-Schalter
(switch.shutter_pilot_auto_abwesend_hoch / …_runter) mit deiner
Anwesenheitserkennung ein- und ausschaltest. „Kein Zeitplan" wäre das Gegenteil
davon – ein Bereich, der nie fährt.

Zum Schluss zwei Zeilen aus deinem Export

  • „Markise Terasse hinten": die Automatik dieser Markise steht auf aus. Der
    Bericht rechnet die Beschattung durch und kommt auf „beschatten", gefahren
    wird aber nichts. Falls das nicht Absicht ist: der Schalter ist
    switch.shutter_pilot_markise_markise_terasse_hinten.
  • „Rolladen Wohnzimmer" und „Zimmer hinten": dort steht die Automatik am
    Rollladen auf aus – die fahren also gar nicht mit.

@Smons und @Linos – der Block für alle Bereiche

Hallo Horst, hallo Linos,

ihr wolltet dasselbe von zwei Seiten – Horst im Panel, Linos „mit Entitäten,
fürs HA-Dashboard". Es gibt jetzt beides.

Im Panel

Über den Bereichskarten steht ein neuer Block „Alle Bereiche":

  • Hoch · Stop · Runter · Sonnenschutz · Lüften für alle Rollläden auf einmal
  • Automatik alle an / aus und Beschattung alle an / aus
  • darunter: Sonnenaufgang, Sonnenuntergang, aktuelle Elevation, aktueller
    Azimut, Höchsttemperatur heute, Wetterlage heute

Damit ist Horsts Liste vollständig abgedeckt, bis auf einen Punkt: „Automatik
für alle aus" gab es schon – das ist der Hauptschalter oben im Panel bzw.
switch.shutter_pilot_system. Der Knopf im neuen Block schaltet stattdessen
jeden Bereich einzeln um; das ist der Unterschied zwischen „die Integration
pausiert" und „jeder Bereich ist aus".

Für ein HA-Dashboard

Dienste: area_id ist ab jetzt bei allen Gruppen-Diensten optional.
Ohne Bereich gilt der Dienst fürs ganze Haus – „alle Rollläden hoch" ist damit
ein Aufruf statt einer je Bereich:

action: shutter_pilot.open_group      # ohne Daten = alle Bereiche

Neu dazu: shutter_pilot.stop_group. Insgesamt also open_group,
close_group, stop_group, sun_protect_group, ventilate_group und
retract_awnings. Kein Rollladen fährt dabei doppelt: der Hoch-Dienst filtert
über den Hoch-Bereich, die Runter-Dienste über den Runter-Bereich.

Statusanzeige (Linos’ „wünsch dir was"): neu ist
sensor.shutter_pilot_status.

  • Primärstatus = der Zustand: open, closed oder partial
  • Sekundärstatus = Attribute: shading_active (ja/nein) und
    shading_areas – die Namen der Bereiche, die gerade beschattet werden
  • dazu open, closed, partial, awnings_extended, awnings_retracted

Deine Beispielzeile „Beschattung aktiv Ost, Süd" ist damit ein Einzeiler:

{{ state_attr('sensor.shutter_pilot_status','shading_areas') | join(', ') }}

Markisen zählen bewusst getrennt: eine eingefahrene Markise ist in Ruhe, nicht
„das Haus ist zu".

Was es schon gab und wofür ich bewusst keine neue Entität gebaut habe:

Wunsch Entität
Automatik alle an/aus switch.shutter_pilot_system
Automatik je Bereich switch.shutter_pilot_auto_<bereich>
Beschattung je Bereich switch.shutter_pilot_sonnenschutz_<bereich>
Sonnenauf-/-untergang, Elevation, Azimut sun.sun (Attribute von Home Assistant)
Höchsttemperatur / Wetterlage heute sensor.shutter_pilot_forecast_temp_max_peak, sensor.shutter_pilot_forecast_condition

Einen globalen Beschattungsschalter habe ich absichtlich weggelassen: der
müsste seinen Zustand aus den Bereichen ableiten und wieder zurückschreiben,
und jedes Zurückschreiben lädt bei Shutter Pilot den Config-Entry neu. Eine
Schaltergruppe in Home Assistant (Helfer ▸ Gruppe) tut dasselbe ohne diesen
Preis – und der Knopf im Panel schaltet ohnehin alle auf einmal.

## @pcsv17 – die Balkontür, die nur aus dem Geschlossenen reagiert

Hallo pcsv17,

**das war ein Fehler bei mir**, und du hast ihn genau beschrieben: „Das Rollo

fährt aber nur in diese Position, wenn es vorher ganz geschlossen war. Wurde
das Rollo manuell auf z. B. 45 % gefahren und ich öffne dann die Tür, passiert
nichts."

Dahinter steckt eine Prüfung, die es gut meinte: der Fensterkontakt soll
mittags **nicht** einen offenen Rollladen herunterziehen, nur weil jemand ein
Fenster kippt. Deshalb reagierte er nur aus dem geschlossenen Zustand heraus.

Die Prüfung war aber **richtungsblind** – und der Aussperrschutz ist auf diesem
Weg das Einzige, was überhaupt nach *oben* fährt. Genau der Haken also, wegen
dem man ihn setzt, war damit ausgesperrt.

Ab 2.18.0 wird zusätzlich gefragt, in welche Richtung die Fahrt ginge: **würde

sie den Rollladen öffnen, wird gefahren – egal, wo er steht.** Dein Fall: 45 %,
Tür auf, Kipp-Position 30 %, vom Aussperrschutz auf 95 % geklemmt → 95 liegt
über 45, also fährt er hoch. Beim Schließen der Tür geht er auf die 45 %
zurück, auf denen du ihn geparkt hattest.

Der ursprüngliche Zweck bleibt: steht der Rollladen ohne Aussperrschutz offen,
zieht ihn ein Fenster weiterhin nicht herunter.

### Der zweite Teil deiner Meldung ist eine Einstellungssache

„Unabhängig von dem Aussperrschutz fährt er beim Öffnen auch nicht die Position
‚bei Fenster offen’ an."

Das stimmt, und es liegt an deinem Kontakt: In deinem Screenshot steht nur

**ein** Schieber, „Position bei Fenster gekippt". Das heißt, dein Kontakt ist

zweiwertig – er meldet nur „zu" und „nicht zu", nicht „gekippt" gegen „offen".

Die Information, dass die Tür ganz aufsteht, gibt es dann schlicht nicht, und
Shutter Pilot fährt in beiden Fällen die Kipp-Position. „Position bei Fenster
offen" wird bei dir nie benutzt (das steht seit 2.8.2 auch so im

Einstellungs-Export).

Für „Tür auf → Rollladen ganz hoch" also einfach:

* **Position bei Fenster gekippt** von 30 % auf **100 %**, oder

* **Mindest-Position wenn Tür offen** von 95 % auf **100 %**

Beides führt zum selben Ergebnis. Wenn du „gekippt" und „offen" wirklich
unterscheiden willst, bräuchte es einen Kontakt mit drei Zuständen oder eine
zweite Entität für „gekippt" – dafür gibt es im Formular das Feld

„Zusätzlicher Sensor für gekippt".

v2.18.0 – Aussperrschutz aus jeder Stellung, Block für alle Bereiche, My-Position Latest

:lady_beetle: Behoben
Der Aussperrschutz griff nicht, wenn der Rollladen halb offen stand
„Das Rollo fährt aber nur in diese Position, wenn es vorher ganz geschlossen war. Wurde das Rollo manuell auf z. B. 45 % gefahren und ich öffne dann die Tür, passiert nichts." — pcsv17

Dahinter steckt eine Prüfung, die es gut meinte: der Fensterkontakt soll mittags nicht einen offenen Rollladen herunterziehen, nur weil jemand ein Fenster kippt. Deshalb reagierte er nur aus dem geschlossenen Zustand heraus.

Nur war die Prüfung richtungsblind – und der Aussperrschutz ist auf diesem Weg das Einzige, was überhaupt nach oben fährt. Genau der Haken also, wegen dem man ihn setzt, war ausgesperrt.

Jetzt wird zusätzlich gefragt, wohin die Fahrt ginge: würde sie den Rollladen öffnen, wird gefahren – egal, wo er steht.

Situation vorher jetzt
Rollladen bei 45 %, Tür auf, Mindesthöhe 95 % nichts fährt auf 95 %, beim Schließen zurück auf 45 %
Rollladen ganz offen, kein Aussperrschutz nichts nichts – unverändert
Derselbe Fall steckte auch in zwei Exporten von Wolf und in bjoergs Schlafzimmer, ohne dass er als solcher erkennbar war.

Die Anhaak-Kästchen sahen aus wie Eingabefelder
„Bei einigen Anhaak-Kästchen ist es ein wenig schwierig die Zugehörigkeit zu erkennen." — bjoerg

Haken und Text stehen jetzt nebeneinander, und zwischen den Einstellungen liegt eine feine Trennlinie – genau das Gewünschte.

Ein Schutzsensor mit Textzuständen sperrte die Markise dauerhaft
„Mein Regensensor liefert nur ‚nass’ und ‚trocken’." — bjoerg

Das Formular bot beim Markisenschutz nur Zahlenfelder an. Und dort gilt ein Wert, den man nicht mit einer Schwelle vergleichen kann, als Gefahr – ein Sensor, der „trocken" meldet, hätte die Markise also dauerhaft gesperrt und eingefahren, während daneben eine Schwelle steht, die so aussieht, als würde sie geprüft.

Beim Wind-, Regen- und Frostsensor gibt es jetzt dieselbe Zustandsliste wie bei den Beschattungsbedingungen: anklicken, welche Zustände Gefahr bedeuten. Der Export benennt den Fall zusätzlich, falls er irgendwo übersehen wurde.

Zwei Tablet-Fehler
„Das Feststellen des oberen Bereiches funktioniert auf dem Android Handy, aber auf dem Android Tablet leider nicht. Das Gleiche trifft für die Änderung des Lux-Wertes zu." — Wolf

Beides echte Fehler, beide behoben:

Feststehende Reiter: der Rückfall für ältere Browser machte das Panel selbst zum Scrollbereich – und ein „feststehendes" Element darin klebt an nichts. Auf moderneren Browsern fiel das nicht auf, auf älteren WebViews schon.
Lux-Zahlenfeld: das Feld zeichnete sich bei jedem Tastendruck neu; auf manchen Android-WebViews springt dabei der Cursor. Jetzt wird erst beim Verlassen des Feldes neu gezeichnet.
:sparkles: Neu
Ein Block für alle Bereiche, oben im Dashboard
„Ich fände noch einen möglichst kompakten Block oberhalb der Bereiche sinnvoll, der Aktionen und Informationen bereitstellt, die für alle Bereiche gelten." — Smons

Genau das steht jetzt dort:

Hoch · Stop · Runter · Sonnenschutz · Lüften für alle Rollläden auf einmal
Automatik alle an / aus und Beschattung alle an / aus
Sonnenaufgang, Sonnenuntergang, aktuelle Elevation, aktueller Azimut, Höchsttemperatur heute, Wetterlage heute
Dieselben Aktionen als Dienste und Entitäten
„Hier würde ich mich anschließen, allerdings mit Entitäten → für das HA-Dashboard." — Linos

area_id ist ab jetzt bei allen Gruppen-Diensten optional. Ohne Bereich gilt der Dienst fürs ganze Haus – „alle Rollläden hoch" ist damit ein Aufruf statt einer je Bereich:

action: shutter_pilot.open_group # ohne Daten = alle Bereiche
Neu dazu: shutter_pilot.stop_group.

Neuer Sensor sensor.shutter_pilot_status – Linos’ „wünsch dir was", eins zu eins:

Was Wo
Primär-Status: geöffnet / geschlossen der Zustand: open, closed, partial
Sekundär-Status: „Beschattung aktiv Ost, Süd" Attribut shading_areas
Zahlen je Gruppe open, closed, partial, awnings_extended, awnings_retracted
{{ state_attr(‘sensor.shutter_pilot_status’,‘shading_areas’) | join(', ') }}
Markisen zählen bewusst getrennt: eine eingefahrene Markise ist in Ruhe, nicht „das Haus ist zu".

„Bei offenem Fenster schon auf die Lüftungsposition fahren"
„Müsste dann aber nicht die Jalousie auf die Position für ‚gekippt’ fahren? Im Schlafzimmer hat sich gar nichts bewegt." — bjoerg

Richtig – bisher blieb ein Rollladen mit vorgemerkter Nachholfahrt einfach stehen, wo er stand. Nicht einmal die Teilfahrt, die der Fensterkontakt gefahren hätte.

Neuer Haken im Rollladenformular, direkt unter „Fahrt nach dem Schließen nachholen": der Rollladen fährt abends so weit, wie es der Aussperrschutz zulässt, und die volle Fahrt bleibt vorgemerkt, bis das Fenster zugeht.

:warning: Vorgabe: aus. Eine Änderung, die ungefragt in jeder zufriedenen Anlage abends Rollläden bewegt, wäre schlimmer als der bisherige Zustand.

„My"-Position für Antriebe ohne Positionsmeldung
„Unter Entität steht dort button.terasse_markise_hinten_my_position." — Wolf

Damit ist die Frage aus 2.16.0 beantwortet. Somfy RTS und Verwandte kennen eine dritte, am Motor angelernte Stellung; Overkiz bietet sie als Knopf an. Im Formular unter „Antrieb meldet keine Position" gibt es jetzt zwei Felder: die Entität und den Prozentwert, dem sie entspricht.

Jede Fahrt, die höchstens 15 % daneben liegt, drückt dann diesen Knopf. Erst damit bedeutet „Ausfahrlänge nach Sonnenhöhe" an so einem Antrieb überhaupt etwas – ohne sie wird aus jedem Wert ab 50 % schlicht „ganz ausfahren".

ann.

:counterclockwise_arrows_button: Was ändert sich für mich?
Wenn du nichts einstellst: Der Aussperrschutz greift jetzt auch dann, wenn der Rollladen nicht ganz zu war – das ist die einzige Verhaltensänderung, und sie fährt ausschließlich nach oben. Formular und Panel sehen aufgeräumter aus.

Die neuen Felder sind alle optional, der Haken „Bei offenem Fenster schon auf die Lüftungsposition fahren" ist bewusst aus.

Für Markisen mit Textsensoren (Regen als „nass"/„trocken") lohnt ein Blick in die Einstellungen: dort die Zustände ankreuzen, die Gefahr bedeuten.

v2.19.0 – das leere Feld, das eine 0 war Latest

:lady_beetle: Behoben
Ein leer gelassenes Schwellenfeld wurde als 0 gespeichert

Unter „Beschatten ab" steht ein zweites Feld, „Aufheben unter". Leer lassen
heißt laut Hinweis: derselbe Wert wie oben. Genau das ging nicht — ein leeres
Feld wurde beim Speichern zur echten Zahl 0.

Und 0 bedeutet an einem Helligkeits-, Strahlungs- oder Windsensor etwas ganz
anderes, nämlich: nie wieder aufheben. Die Beschattung ging einmal an und
blieb unten, auch wenn es draußen dunkel wurde. Beim Markisenschutz war es noch
schärfer: „Einfahren ab 0" heißt, dass die Markise gar nicht mehr ausfährt.

Betroffen waren alle Schwellenpaare, die leer bleiben dürfen — Beschattung,
abweichendes Schließen, Frost, Lüften, „nicht hochfahren" und der
Markisenschutz. Leere Felder bleiben jetzt leer.

Bitte einmal nachsehen: Wer den Wert schon in seiner Konfiguration hat,
merkt von der Reparatur nichts. Der Einstellungs-Export sagt es jetzt: in der
Bedingungstabelle steht ein Hinweis, wenn ein Aufhebepunkt bei 0 liegt. Zum
Beheben genügt es, das Feld zu leeren und zu speichern.

Gelöschte Bereiche und Rollläden ließen ihre Entitäten stehen

Wer einen Rollladen oder eine Markise löschte, behielt die zugehörigen
Schalter und Sensoren als Karteileichen — Spook meldet sie als „nicht
existierende Entität". Ärgerlich wird das beim Wiederanlegen: der Name ist noch
belegt, und der neue Schalter heißt dann …_2. Beide Lösch-Befehle räumen
jetzt vollständig auf.

:counterclockwise_arrows_button: Was ändert sich für mich?
Nichts, was von allein etwas bewegt — beides sind Reparaturen. Ein Blick in den
Einstellungs-Export lohnt sich aber: er benennt jetzt, wenn irgendwo eine 0 als
Aufhebepunkt steht.

Alte Karteileichen im Entitätsregister räumt das Update nicht rückwirkend weg;
die lassen sich in Home Assistant unter Einstellungen ▸ Geräte & Dienste ▸
Entitäten löschen.

Hi @Schubi

das mit der Tür scheint zu funktionieren.:+1:

Ich habe da noch einen anderen Fall. Und zwar möchte ich zum Beispiel tagsüber mein Baby hinlegen. Dafür habe ich mir einen Schalter gebaut, damit das Rollo auf circa 20 % runterfährt. Wenn ich den Schalter deaktiviere, fährt das Rollo wieder hoch. Danach macht die Automatik aber leider nicht mehr weiter, da das ja ein manueller Eingriff. Beziehungsweise wäre es gut, wenn die Automatik sich nochmal aktiviert und ggf. auch nochmal auf beschatten fährt. Ich möchte aber nicht in den Einstellungen einstellen, dass die Automatik immer Vorrang hat. Vielleicht wäre es gut, wenn man einen Trigger hätte, der die Position anfährt, in der die Automatik jetzt eigentlich wäre. Oder vielleicht hast du eine bessere Idee, wie man das umsetzen könnte.

v2.20.0 – Dachfenster

:sparkles: Neu: Dachfenster

Ein Wunsch aus dem Forum (hollizone): Dachfenster, die bei Regen von allein zugehen.

Neben Rollläden und Markisen gibt es jetzt einen dritten Tab: Dachfenster. Dahinter steckt dieselbe Maschine wie bei den Markisen — nur zeigt die Gefahr in die andere Richtung. Eine Markise muss einfahren, wenn es bläst; ein Dachfenster muss zu, wenn es regnet.

Wie es fährt

Ein Dachfenster läuft in keinem Zeitplan mit. Uhrzeit, Helligkeit und Sonnenstand bewegen es nicht.

  • Geöffnet wird es über die Bedingungen seines Bereichs. Am häufigsten die Innentemperatur: „über 24 °C kippen, unter 22 °C wieder zu". Sonnenhöhe und Fensterrichtung lassen sich dafür abschalten — dann bleibt eine reine Bedingungssteuerung.

  • Geschlossen wird es vom Schutz.

Drei Stellungen statt zwei:

Stellung Bedeutung Vorgabe
Geschlossen die sichere — dorthin fährt der Schutz 0 %
Lüftungsstellung so weit öffnet es, solange die Bedingung gilt 30 %
Ganz offen nur für den Auf-Knopf von Hand 100 %

Regen-, Wind- und Frostschutz

Dieselben drei Sensoren wie bei den Markisen, unter Einstellungen, mit derselben Mechanik: Binärsensor, Zahlenwert mit Ein- und Ausschaltschwelle oder Zustandsliste — dazu eine Sperrzeit je Sensor. Nach dem letzten Tropfen bleibt das Fenster noch die eingestellte Zeit zu und öffnet erst danach wieder, sofern die Bedingung noch gilt.

Ein Sensor, der nichts mehr meldet, sperrt sofort und schließt nach einer Karenzzeit. An einem Fenster ist das die richtige Richtung: „ich weiß es nicht" heißt zu.

Für eine Ecowitt ist die Regenrate der richtige Wert (sensor.*_rain_rate, mm/h) — nicht die Tagessumme, die rechnet hoch und geht nach dem Regen nicht mehr herunter.

Kleinigkeiten dazu

  • Trägt schon ein Rollladen dieselbe Cover-Entität, bietet das Formular an, ihn als Dachfenster zu übernehmen — und räumt dabei die Felder weg, die dort nichts bedeuten.

  • sensor.shutter_pilot_status zählt Dachfenster getrennt (windows_open, windows_closed). Ein gekipptes Dachfenster macht das Haus nicht „offen".

:warning: Bitte einmal lesen

Zwischen dem ersten Tropfen und dem geschlossenen Fenster liegen die Wetterstation, Home Assistant und die Laufzeit des Motors. Bei einem plötzlichen Schauer ist Wasser im Raum, bevor das Fenster zu ist.

Ein Regensensor am Fenster selbst — Velux und Roto haben so etwas — schließt ohne diese Kette. Shutter Pilot ist der Komfort obendrauf, nicht der Ersatz dafür. Derselbe Hinweis steht im Formular.

:counterclockwise_arrows_button: Was ändert sich für mich?

Nichts. Wer keine Dachfenster anlegt, merkt vom Update nichts: ein Eintrag ohne Geräteart ist weiterhin ein Rollladen, es gibt keine Umstellung an bestehenden Daten.

Hallo @Schubi, ähnliches habe ich gestern Abend auch bemerkt…
Alle Rolll. bereits runtergefahren → einer wurde von Hand hoch gefahren → dieser wurde sofort wieder runter gefahren durch Automatik → am nächsten Morgen sind alle Rolll. nicht mehr automatisch hoch gefahren.

Leider bin ich noch nicht auf dem neuesten Stand und kann noch nichts konkreteres dazu beitragen. Vielleicht ist das Thema aber auch schon geklärt

v2.21.0 – Automatik wieder übernehme

:lady_beetle: Behoben

Die Beschattung holte einen von aussen verstellten Rollladen nie zurück

Wer einen eigenen Schalter oder eine eigene Automation gebaut hat, die einen Rollladen verstellt, kannte das: danach machte die Automatik nicht mehr weiter.

Dahinter steckte mehr als die manuelle Übersteuerung. Solange der Merker „ist beschattet" steht, folgt die Beschattung nur einer geänderten Zielposition — dass der Rollladen längst woanders steht, weil ihn jemand von aussen gefahren hat, sah sie nicht. Der Rollladen stand danach offen in der Sonne, während intern weiterhin „beschattet" vermerkt war.

:sparkles: Neu: shutter_pilot.resume_automation

Ein Dienst, der einen Rollladen an die Automatik zurückgibt:

  • löscht die manuelle Übersteuerung,

  • vergisst den Beschattungs-Merker,

  • und fährt sofort auf die Position, die gerade gilt — Beschattungshöhe, wenn beschattet werden soll, sonst offen oder geschlossen je nach Tageshälfte.

action: shutter_pilot.resume_automation
data:
  entity_id: cover.kinderzimmer

Beide Angaben sind optional: entity_id für einzelne Rollläden, area_id für einen Bereich — ohne beides gilt der Dienst fürs ganze Haus.

Der typische Einsatz: ein Schalter, der ein Zimmer abdunkelt (Mittagsschlaf, Heimkino, Gästezimmer). Am Ende der Automation den Dienst aufrufen, und die Automatik macht nahtlos weiter — ohne dass in den Bereichseinstellungen „Automatik hat Vorrang" umgestellt werden muss.

Warum ein Dienst und nicht von allein?

Weil nur die Person im Raum weiß, wann das Nickerchen vorbei ist. Würde die Beschattung von selbst merken, dass der Rollladen verstellt wurde, zöge sie ihn eine Minute nach dem Abdunkeln wieder hoch — das Gegenteil dessen, wofür die manuelle Übersteuerung da ist.

:counterclockwise_arrows_button: Was ändert sich für mich?

Nichts, solange der Dienst nicht aufgerufen wird. Das bisherige Verhalten bleibt unverändert.