Hallo Schubi,
Noch eine Rückmeldung von mir zum Feststellen der oberen Leiste auf dem Tablet.
Das funktioniert jetzt aber seit der aktuellen Version kann ich auf dem Tablet bei der Auswahl von einzeinen Rolladen und Markisen den Einstellungsmodus nicht mehr aufrufen. Es erscheint eine Fehlermeldung: awning is not defined. Auf dem Handy funktioniert es.
Guten Morgen @Schubi,
in der Version 2.21.0 hab ich Probleme beim Bearbeiten von Rollladen:
Darüber hinaus hätte ich noch eine Bitte für meinen inneren Monk. Könntest du vielleicht die Rollläden in der Rollladen-Ansicht alphabetisch sortieren (also nach Name)?
Vielen Dank im Voraus!
Viele Grüße, Charly
Hi,
ich muss mich erst einmal bedanken. Mit den neuen Funktionen ist der WAF gestiegen 
Die resume-Funktion funktioniert soweit. Wenn man das Rollo aber auf 0% gefahren hat und ich glaube die Beschattung gerade nicht greift, dann fährt das Rollo beim aktivieren der resume-Funktion nicht mehr nach oben. Das zweite Rollo, dass nicht bei 0% war, fährt dann nach oben, genau wie es sein soll.
Die alphabetische Sortierung gibt es — dein innerer Monk hat recht, das hätte von Anfang an so sein sollen. Sortiert wird nach dem Namen (mit Umlauten und Zahlen richtig: „Küche 2" vor „Küche 10"). Markisen und Dachfenster ebenso.
Danke fürs Nachtesten — und der WAF-Punkt geht runter aufs Haus 
Dein 0-%-Fall ist ein Fehler von mir, und ein lehrreicher. Der Dienst hat sich gemerkt, wohin ein Rollladen zuletzt gefahren wurde. Wer von Hand ganz zufährt, landet damit in der Schublade „gilt als unten" — und resume hat daraus gelesen „die Automatik will ihn unten haben". Also hat er genau die Übersteuerung zementiert, die er aufheben sollte. Dein zweites Rollo lag nicht bei 0 % und war deshalb nicht betroffen — dass dir das aufgefallen ist, war der entscheidende Hinweis.
Jetzt fragt der Dienst den Zeitplan: steht als Nächstes eine Abwärtsfahrt an, gehört der Rollladen bis dahin nach oben — egal wo er gerade steht. Aus 0 % fährt er also mittags hoch.
Ein Sonderfall bleibt bewusst so: in einem Bereich ohne Zeitplan gibt es keine „Position, in der die Automatik jetzt wäre" außer der Beschattung. Greift die nicht, lässt der Dienst den Rollladen stehen, statt eine Endlage zu raten.
Bitte zeitnah aktualisieren. In 2.20.0/2.21.0 ließ sich das Bearbeiten-Formular nicht mehr öffnen, sobald ein zweiter Rollladen (bzw. eine zweite Markise oder ein zweites Dachfenster) angelegt war. Entschuldigt bitte — das war mein Fehler.
Behoben„awning is not defined" beim Bearbeiten oder Anlegen
Beim Einbau der Dachfenster habe ich eine Variable umbenannt und zwei Verwendungen übersehen. Betroffen war der Block „Einstellungen übernehmen von …" — und den gibt es erst ab dem zweiten Eintrag derselben Geräteart. Deshalb ging der erste Rollladen und der zweite nicht, deshalb ging es auf einem Gerät und auf dem anderen nicht.
Es ist gültige Syntax, die Prüfung beim Bauen fand also nichts. Das Panel wird ab jetzt bei jedem Push vollständig durchgerendert — alle Ansichten, alle Formulare, alle Bereichsmodi, ausdrücklich mit mehreren Einträgen je Art. Dieser Fehler wäre damit nicht rausgegangen.
Ein Dachfenster wurde aufgerissen statt geschlossen
Beim Nachstellen einer Meldung gefunden, und der wiegt schwerer: fiel die Bedingung weg (Raum kühlt ab), fuhr die Freigabe auf position_open. Bei einer Markise heißt das „eingefahren" — bei einem Fenster „weit auf". Das Fenster stand danach offen statt zu. Bei Regen wäre das Wasser im Haus gewesen, also genau der Schaden, gegen den die Geräteart gebaut wurde.
Guten Morgen, ich habe auch das Problem, der Bearbeitung von Rolläden, mir wird aber das Update auf 2.21.1 nicht angezeigt.
Versuch’s mal mit “Erneut heruntladen” über die 3 Punkte rechts oben:
Danke, das hat geholfen.
BehobenDie Kipp-Position wurde nicht angefahren, wenn der Aussperrschutz höher stand
Gemeldet von einem Nutzer mit einem Fenstergriff, der offen / gekippt / geschlossen meldet: Kipp-Position 30 %, Mindesthöhe des Aussperrschutzes 95 % — gefahren wurden immer 95 %.
Nachgerechnet mit seinen Werten:
| Griff | erkannt | Ziel | tatsächlich gefahren |
|---|---|---|---|
| offen | offen | 95 % | 95 % |
| gekippt | gekippt | 30 % | 95 % ← |
| geschlossen | geschlossen | – | – |
Der Zustand wird also richtig erkannt und die Kipp-Position richtig bestimmt. Geklemmt wird einen Schritt später: der Aussperrschutz griff bei offenem und gekipptem Fenster. Eine Kipp-Position unterhalb der Mindesthöhe war damit grundsätzlich unerreichbar — sie ließ sich eintragen, stand im Formular und wurde nie gefahren.
Der Aussperrschutz gilt jetzt nur noch bei ganz geöffnetem Fenster. Durch einen Kippspalt steigt niemand — dort gibt es den Fall nicht, gegen den er schützt. Und die Kipp-Position ist genau dafür da, dass bei gekippt etwas anderes gilt als bei offen.
Für zweiwertige Kontakte ändert sich nichts. Ein einfacher Fensterkontakt meldet „offen", nie „gekippt" — dort klemmt der Aussperrschutz weiterhin, und der Rollladen fährt nicht vor die offene Terrassentür.
GeändertDer Kopierknopf überträgt jetzt auch die Bereiche
Bisher blieben Hoch- und Runter-Bereich außen vor. Die Idee war, dass genau sie zwei sonst gleiche Rollläden unterscheiden — in der Praxis ist es umgekehrt: wer „Einstellungen übernehmen von …" drückt, legt fast immer einen zweiten Rollladen im selben Bereich an.
Entität, Name, Fenstersensoren und die Geräteart bleiben weiterhin unangetastet.
Wer einen Aussperrschutz und eine Kipp-Position unterhalb der Mindesthöhe eingestellt hat, bekommt ab jetzt die Kipp-Position, die dort steht. Genau das war die Absicht beim Eintragen — vorher wurde sie stillschweigend überschrieben.
Ich habe leider noch einen Fehler gefunden. Version ist 2.21.2
Ich habe einen Rolladen im Bereich Arbeiten, mit einem Sensor für offen, gekippt, geschlossen. DIe Positionen für offen und gekippt werden korrekt angefahren, wenn der Rolladen bereits unten ist, also zur Abendzeit. Aber die Position für geschlossen wird nicht angefahren, da fährt er den Rolladen auf 74%. Die habe ich aber nirgendwo eingestellt.
Dein Support hier ist übrigens überwältigend. Vielen Dank
Gruß
Christian
shutter-pilot-2026-09-02-21-16.txt (9,7 KB)
Hallo c.radi,
danke – und die 74 war der ganze Hinweis. Genau das, was du geschrieben hast:
die Zahl steht in keiner deiner Einstellungen. Deine Schließposition ist 0,
die Fensterpositionen sind 100 und 15, die Beschattung 50. Eine Zahl, die kein
Formular kennt, kommt aus einer Messung – nicht aus einer Entscheidung. Das war
ein Fehler, und er ist gefunden.
Was passiert ist
Beim Schließen des Fensters fährt Shutter Pilot nicht auf die Schließposition,
sondern auf die Höhe zurück, auf der der Rollladen stand, bevor du das Fenster
geöffnet hast. Das ist so gewollt – nach einer Nachtlüftung soll er nicht
plötzlich oben stehen.
Diese Höhe wurde aber als Momentaufnahme der gemeldeten Position gemerkt. Steht
der Rollladen still, ist das richtig. Fährt er gerade, ist es eine Zahl mitten
aus dem Fahrweg. Und genau das ist dein Ablauf zur Abendzeit: die Helligkeit
fährt den Rollladen herunter, du gehst ans Fenster und öffnest es, während er
noch unterwegs ist. In dem Moment ist er zufällig bei 74 %.
Ich habe das mit deinen Werten nachgestellt, nicht geraten:
Abendfahrt 100 -> 0, unterwegs bei 74 %
Fenster auf -> gemerkt: 74 · gefahren: 100 <- hier entsteht der Fehler
Fenster gekippt -> gefahren: 15
Fenster zu -> gefahren: 74
Die letzte Zeile ist dein Bericht, auf das Prozent. Und danach rührt sich
nichts mehr – die nächste geplante Fahrt kommt erst am Morgen. Deshalb sah es
so aus, als würde die Schließposition ignoriert: sie war nie im Spiel, es war
die falsch gemerkte Rückfahrhöhe.
Was ich geändert habe (2.21.3)
Gemerkt wird jetzt, wo der Rollladen steht, nicht was er gerade meldet:
solange er fährt, gilt das Ziel, das die Automatik ihm zuletzt geschickt hat.
In deinem Fall also die 0 – und beim Schließen des Fensters fährt er dorthin
zurück, wo er ohne das Fenster längst gewesen wäre.
Zwei Dinge noch, die dazugehören:
opening / closing), verhalten sich unverändert. Von außen ist dort nichtEin Test hält deinen Ablauf jetzt fest, damit das nicht zurückkommt.
Und danke für das Lob – aber der Verdienst liegt bei euch: fast jeder Fehler
der letzten Wochen kam aus einem Satz, den jemand nebenbei geschrieben hat.
Viele Grüße
Der Rollladen, der auf einer Zahl parkte, die niemand eingestellt hatDanke an c.radi – und der Hinweis stand in seinem eigenen Satz: „Die habe
ich aber nirgendwo eingestellt." Genau so war es. Eine Zahl, die in keinem
Formular steht, kommt aus einer Messung und nicht aus einer Entscheidung.
Beim Schließen des Fensters fährt Shutter Pilot nicht auf die
Schließposition, sondern auf die Höhe zurück, auf der der Rollladen vor dem
Öffnen des Fensters stand. Das ist so gewollt – nach einer Nachtlüftung soll er
nicht plötzlich oben stehen.
Diese Höhe wurde als Momentaufnahme der gemeldeten Position gemerkt. Steht
der Rollladen dabei still, ist das richtig. Fährt er gerade, ist es eine Zahl
mitten aus dem Fahrweg – und genau dort parkte er dann später.
Das ist kein Sonderfall, sondern der abendliche Normalfall: die Automatik fährt
die Rollläden herunter, man geht ans Fenster und öffnet es, während der
Rollladen noch unterwegs ist.
| Schritt | Vorher | Jetzt |
|---|---|---|
| Abendfahrt 100 % → 0 %, unterwegs bei 74 % | ||
| Fenster auf | gemerkt: 74 % | gemerkt: 0 % (das Ziel der Fahrt) |
| Fenster gekippt | gefahren: 15 % | gefahren: 15 % |
| Fenster zu | gefahren: 74 %  |
gefahren: 0 %  |
Und danach rührte sich nichts mehr – die nächste geplante Fahrt kommt erst am
Morgen.
Nichts, solange Fenster nur bei stehendem Rollladen bewegt werden.
Wer das Fenster öffnet, während der Rollladen gerade fährt, bekommt beim
Schließen jetzt die Position, auf die die Automatik unterwegs war. Bisher blieb
er auf einer zufälligen Zwischenhöhe stehen.
Beim automatischen Lüften steckte derselbe Fehler – der Minutentakt konnte
die Abendfahrt genauso mitten im Weg treffen. Mitrepariert.
Ein Antrieb, der Home Assistant nicht meldet, dass er gerade fährt (kein
opening / closing), verhält sich unverändert. Von außen ist dort nicht zu
erkennen, dass eine gemeldete Position nur eine Durchgangszahl ist. Die meisten
Antriebe melden es.
Vielen Dank für den Fix. Funktioniert nun auch, aber….
Wenn das Fenster auf gekippt steht wird der Rolladen gar nicht geschlossen. Meine Erwartungshaltung wäre, er wird in die Stellung für “gekippt” gefahren.
Gruß
Christian
Hallo Christian,
danke fürs Nachschauen — und diesmal habe ich gute Nachrichten und eine kleine Entschuldigung dabei: kaputt ist nichts, ich habe es nur schlecht beschriftet.
Ich habe deine Werte aus dem Export nochmal durch die echten Funktionen laufen lassen. Bei „Arbeitszimmer links" steht „Nachholen wenn Fenster offen" auf an. Dieser Haken tut genau das, was er verspricht: kommt die Schließzeit, während das Fenster offen ist, wird die Fahrt vorgemerkt und erst ausgeführt, wenn das Fenster wieder zugeht. Bis dahin bleibt der Rollladen absichtlich stehen.
Und das gilt eben auch für ein gekipptes Fenster — nur stand das nirgends. Der Haken hieß „wenn Fenster offen", der darunter ebenso, und beide Hinweistexte auch. Dass du daraus nicht ableiten konntest, dass „gekippt" mitgemeint ist, ist völlig nachvollziehbar; das ist mein Fehler und nicht deiner.
Was du willst, gibt es schon — es ist der zweite Haken direkt darunter:
Bei offenem oder gekipptem Fenster schon auf die Lüftungsposition fahren
Damit fährt dein Rollladen abends sofort auf 15 % (deine Kipp-Position), wenn das Fenster gekippt ist, bzw. auf 100 %, wenn es ganz offen steht. Die volle Fahrt auf 0 % bleibt trotzdem vorgemerkt und wird nachgeholt, sobald du das Fenster schließt. Genau deine Erwartungshaltung.
Nachgerechnet mit deinen Werten:
Fenster ohne den Haken mit dem Haken
gekippt fährt nichts 15 %
ganz offen fährt nichts 100 %
zu volle Fahrt auf 0 % volle Fahrt auf 0 %
Warum der Haken nicht von Haus aus an ist: eingeschaltet würde er in jeder Anlage, in der bisher alles passt, jeden Abend Rollläden bewegen, die vorher stehen geblieben sind. Solche stillen Verhaltensänderungen mache ich ungern ungefragt.
In 2.21.4 (gerade raus) habe ich zwei Dinge geändert:
Die Beschriftungen nennen jetzt beides — „offen oder gekippt" — und der Hinweis sagt zusätzlich, welche Position gefahren wird. Und der Einstellungs-Export beantwortet die Frage künftig von selbst: Steht die Nachholfunktion an und der Haken darunter aus, schreibt der Bericht an genau diesem Rollladen hin, dass zur Schließzeit gar nichts fährt, solange ein Fenster offen oder gekippt ist — samt beider Positionen und dem Zustand, den dein Kontakt gerade meldet. Bisher stand die Antwort in keiner Zeile des Berichts, weil ein nie angefasster Haken auch nirgends auftaucht.
Du warst übrigens der Zweite mit genau dieser Meldung — der Erste hat 2.18.0 ausgelöst. Beim zweiten Mal ist es dann keine Ausnahme mehr, sondern eine schlechte Beschriftung. Danke, dass du sie gefunden hast.
Nach dem Update bitte einmal den Browser hart neu laden (Strg+F5), sonst zeigt das Panel noch die alten Texte.
Viele Grüße
Die Beschriftung, die nur die Hälfte genannt hatDanke an c.radi für die Rückmeldung zu 2.21.3: „Wenn das Fenster auf gekippt steht, wird der Rolladen gar nicht geschlossen. Meine Erwartungshaltung wäre, er wird in die Stellung für ‚gekippt’ gefahren."
Nachgerechnet mit seinen Werten — und diesmal war nichts kaputt. Es fehlte ein Haken, den er nicht finden konnte, weil er nach etwas anderem klang.
Der Haken „Nachholen wenn Fenster offen" tut genau das, was er verspricht: kommt die Schließzeit, während das Fenster offen ist, wird die Fahrt vorgemerkt und erst ausgeführt, wenn das Fenster zugeht. Bis dahin bleibt der Rollladen stehen.
Das gilt seit jeher auch für ein gekipptes Fenster — nur stand das nirgends. Beide Haken und beide Hinweistexte sprachen ausschließlich von „offen":
| bisher | jetzt | |
|---|---|---|
| erster Haken | Nachholen wenn Fenster offen | Nachholen wenn Fenster offen oder gekippt |
| zweiter Haken | Bei offenem Fenster schon auf die Lüftungsposition fahren | Bei offenem oder gekipptem Fenster schon auf die Lüftungsposition fahren |
Wer ein gekipptes Fenster hat, ordnet die beiden Haken seinem Fall damit gar nicht erst zu.
GeändertDie Beschriftungen nennen jetzt beides — in allen elf Sprachen. Der Hinweis unter dem zweiten Haken sagt zusätzlich, welche Position gefahren wird: die für „offen" bzw. die für „gekippt", so weit es der Aussperrschutz zulässt.
Der Einstellungs-Export erklärt es selbst. Steht die Nachholfunktion an und der Haken darunter aus, sagt der Bericht am betroffenen Rollladen jetzt:
„Nachholen wenn Fenster offen oder gekippt" ist an, „Bei offenem oder gekipptem Fenster schon auf die Lüftungsposition fahren" ist aus – solange das Fenster offen oder gekippt ist, fährt dieser Rollladen zur Schließzeit gar nicht. Die volle Fahrt wird vorgemerkt und erst beim Schließen des Fensters ausgeführt. Mit dem zweiten Haken fährt er schon jetzt auf
position_when_window_open(100 %) bzw.position_when_window_tilted(15 %). Das Fenster steht gerade gekippt.
Bisher stand die Antwort in keiner Zeile des Berichts — der Haken taucht dort nicht einmal auf, solange ihn niemand angefasst hat. Das ist die zweite Meldung dieser Art (die erste führte zu 2.18.0: „im Schlafzimmer hat sich gar nichts bewegt").
Am Verhalten nichts. Es ändern sich nur Beschriftungen und der Export.
Wer möchte, dass sein Rollladen zur Schließzeit schon jetzt auf die Kipp- bzw. Offen-Position fährt statt stehen zu bleiben, setzt im Rollladen-Formular unter „Nachholen wenn Fenster offen oder gekippt" den Haken darunter. Die volle Fahrt bleibt dann trotzdem vorgemerkt und wird beim Schließen des Fensters nachgeholt.
Die Vorgabe bleibt bewusst aus: eingeschaltet würde sie in jeder zufriedenen Anlage jeden Abend Rollläden bewegen, die bisher stehen geblieben sind.
Nach dem Update bitte den Browser neu laden (Strg+F5 / ⌘+Shift+R), damit das Panel die neuen Texte zieht.
Echt ein geiles Teil, bin schwer begeisertert! 
Wo sollte man denn den Fensterstatus sehen? Klar, in den Einstellungen sehe ich das ein Fenster beispielsweise gekippt ist aber sollte ich das sonst noch wo sehen?
Gäbe es vielleicht die Möglichkeit den Fensterstatus und ggf. des Status des Rollos (Beschattung, geschlossen, etc) ins Dashboard aufzunehmen? Könnte man ja vielleicht optional anzeigen lassen.
Die Markise, die abends von selbst gehtEin Wunsch aus dem Forum (bjoerg): eine Markise soll abends bei Dämmerung einfahren – aber niemals automatisch wieder ausfahren, schon gar nicht, wenn niemand zuhause ist.
Ein neuer Abschnitt „Bei Dämmerung einfahren" in jedem Markisenformular. Ein eigener Sensor (Helligkeit, Sonnenhöhe oder ein Schalter) löst eine einmalige Einfahrt aus – wird es morgens wieder hell, passiert nichts: die Markise bleibt drin, bis jemand sie von Hand ausfährt oder die Beschattung (falls eingeschaltet) das übernimmt.
Das ist bewusst kein Teil der bestehenden Beschattung: Die fährt bei Bedarf aus und wieder ein – dieselbe Bedingung würde am nächsten Tag erneut auslösen und die Markise wieder ausfahren. Genau das sollte diese Funktion vermeiden.
Für die Schwelle gilt „dunkler als" ohne eigenes Ankreuzen, genau wie bei Frost und Eis. Ein Schalter oder Binärsensor liest „an" als dunkel, mit derselben „Bedeutung umkehren"-Checkbox wie beim Wind-, Regen- und Frostschutz.
Anders als der Wind-/Regen-/Frostschutz (der bewusst jeden Schalter ignoriert – eine Böe darf nicht davon abhängen, ob jemand die Automatik ausgeschaltet hat) respektiert diese neue Funktion Hauptschalter, Bereichsautomatik und die Automatik der Markise selbst. Es ist eine Komfortfunktion, keine Sicherheitsfunktion.
Nichts, solange die neue Sensor-Auswahl leer bleibt. Erst ein eingetragener Sensor aktiviert die Funktion.
Wetterschutz konnte umgangen werdenresume_automation ist laut Doku ausdrücklich nur für Rollläden gedacht,
konnte aber bisher auch Markisen und Dachfenster erreichen – und fragte dort
vor der letzten Fahrt nicht ab, ob Wind, Regen oder Frost sie gerade sperren.
Im schlimmsten Fall wurde ein durch Regen gesperrtes Dachfenster trotzdem
wieder geöffnet. Der Dienst fasst geschützte Geräte jetzt gar nicht mehr an,
zusätzlich mit einer eigenen Sicherheitsprüfung direkt vor jeder Fahrt.
Rollladen konnte nachts von selbst wieder öffnenNach einer nachgeholten Abendfahrt (Fenster war beim Zufahren noch offen)
merkte sich der Fenstertrigger die falsche Höhe für eine spätere,
unabhängige Lüftung in der Nacht – der Rollladen konnte sich dadurch mitten
in der Nacht auf die alte Beschattungshöhe zurückstellen. Behoben.
Markise blieb nach der Dämmerungs-Einfahrt „vergessen“Eine Markise, die abends bei Dämmerung automatisch einfuhr, konnte danach
dauerhaft von der Beschattung übersehen werden – besonders bei
abgeschalteter Sonnenhöhen-Prüfung. Beschattung und Dämmerungsfunktion
stimmen sich jetzt sauber ab: Wind-, Regen- und Frostschutz behalten dabei
weiterhin die höchste Priorität.
Nichts an der Bedienung. Wer resume_automation bisher auf eine Markise
oder ein Dachfenster angewendet hat, sieht dort künftig keine Fahrt mehr –
der Dienst war dafür nie vorgesehen. Normale Rollläden ohne diese
Kombinationen verhalten sich unverändert.
Hallo zusammen,
ich habe derzeit noch ein Problem oder vielleicht sehe ich auch den Wald vor lauter Bäumen nicht mehr. Ist ech super, was du (@Schubi ) hier gebaut hast und auf alle Wünsche eingehst. Aber zurück zu meinem Problem:
Wenn ich morgens aufstehe, den Rollladen manuell hochfahre und anschließend (nicht während des öffnens) das Fenster öffne und nach ein paar Minuten wieder schließe, fährt anschließend der Rollladen wieder herunter, das das automatische Öffnen (Sonnenstand + Zeit) erst später erfolgt. Eigentlich dachte ich, dass ein manuelles Eingreifen dies unterbinden sollte.
Gibt es vielleicht doch irgendwo die Möglichkeit das einzustellen und ich finde es einfach nur nicht?
Ansonsten handhabe ich es wie immer, es sollte ggf. nur ein Feature-Wunsch sein, wenn es für die Mehrheit so sinnvoll ist.
Vielen Dank im Voraus und viele Grüße
Charly
PS: @Schubi bald hast du endlich Ruhe vor uns, weil die Beschattungs-Saison demnächst endet 