danke fürs genaue Beschreiben, das war reproduzierbar und tatsächlich ein Fehler. Ursache: Der Fensterkontakt behandelte einen internen Beschattungs-Merker als Grund zu reagieren, egal auf welcher Höhe der Rollladen gerade steht – gedacht war das für den Fall, dass ein beschatteter Rollladen (z. B. auf 25 %) einer offenen Terrassentür im Weg steht. Fährst du den Rollladen von Hand aus der Beschattung heraus, merkt sich die Automatik das nicht automatisch (Absicht, sonst würde jede manuelle Korrektur sofort überschrieben) – der Merker blieb also stehen, obwohl der Rollladen längst oben war. Öffnest du dann das Fenster, hat genau dieser alte Merker die Abwärtsfahrt ausgelöst. Ist in 2.22.3 behoben – einfach über HACS aktualisieren.
Wie sag ich immer nur durch Melden der Fehler kann man sie beheben…
Ein von Hand hochgefahrener Rollladen konnte beim Fensteröffnen wieder herunterfahren
Fuhr man einen Rollladen von Hand voll hoch und öffnete kurz danach ein
Fenster, konnte der Rollladen trotzdem wieder herunterfahren – wegen eines
Beschattungs-Merkers, der die manuelle Fahrt nicht mitbekommen hatte. Der
Fensterkontakt reagiert jetzt nur noch darauf, wenn der Rollladen tatsächlich
noch nicht offen steht.
Eine vorgemerkte Nachhol-Fahrt konnte eine spätere manuelle Fahrt überleben
Stand ein Fenster beim abendlichen Zufahren offen, merkte sich die Automatik
eine Fahrt fürs spätere Schließen des Fensters vor. Wurde der Rollladen in
der Zwischenzeit von Hand woanders hin gefahren, blieb diese Vormerkung
trotzdem bestehen – und konnte den längst anders positionierten Rollladen
beim nächsten Fensterschluss überraschend zurückfahren. Eine erkannte
Handfahrt verwirft die Vormerkung jetzt.
Was ändert sich für mich?
Nichts an der Bedienung. Beide Fehler betrafen ausschließlich das
Zusammenspiel von manuellen Fahrten mit dem Fensterkontakt – wer keine dieser
Situationen hatte, bemerkt keinen Unterschied.
danke für den Export, damit ließ sich das genau nachvollziehen. Es war tatsächlich ein echter Fehler, kein Einstellungsproblem bei dir.
In deinem Export stand dein “Schlafzimmer Links” bei 100 % (also offen), aber unter “Laufender Zustand” führte die Integration ihn trotzdem noch als “gilt als unten”. Genau dieser interne Merker ist es, den die abendliche Automatik fragt, bevor sie einen Rollladen zufährt – stand er schon auf “unten”, hat sie deinen Rollladen als “heute schon erledigt” übersprungen, obwohl er sperrangelweit offen war.
Der Merker war deshalb falsch, weil zwei Stellen ihn nicht korrekt nachgezogen haben, wenn sie einen Rollladen wieder hochgefahren haben: zum einen der Dienst zum Übernehmen der Automatik, zum anderen – und das passt zu deiner Konfiguration – die Beschattungsfreigabe am Ende des Beschattungszeitraums (bei dir aktiv, mit “Am Ende des Beschattungstags öffnen”). Bei dir kommt vermutlich Folgendes zusammen: dein Bereich “Schlafen” hat übers Wochenende eine Sperre fürs morgendliche Hochfahren – die hält den Rollladen morgens korrekt unten. Die Beschattungsfreigabe kennt diese Sperre aber bewusst nicht und öffnet den Rollladen trotzdem im Laufe des Tages, sobald die Beschattung nicht mehr nötig ist. Dabei blieb der alte “unten”-Merker der Sperre unverändert stehen, obwohl der Rollladen längst wieder offen war – und genau der hat abends die eigentliche Fahrt blockiert.
Ist mit 2.22.4 behoben (beide Stellen aktualisieren den Merker jetzt korrekt), schon veröffentlicht und über HACS ziehbar. Ein Update sollte das Problem beheben, ohne dass du an deinen Einstellungen etwas ändern musst.
Danke nochmal fürs genaue Melden samt Export – ohne den wäre das deutlich schwerer zu finden gewesen.
Danke Frank, der Fehler von gestern ist behoben, aber leider gibt es einen weiteren Fehler,
Schlafzimmer ist heute morgen automatisch hoch gefahren. Beim verstellen des Fensters von gekippt auf geschlossen wird der Rolladen gefahren. Das sollte eigentlich nicht passieren, weil wir ja im Tagmodus sind.
Ich habe noch eine Ergänzung: Der linke Rolladen wurde auch nicht beschattet, der rechte schon. Ob das bei 17 Grad sinnvoll ist sei dahingestellt, aber da kann ich ja vielleicht die Optionen/Bedingungen noch anpassen.
danke fürs genaue Beschreiben und den Export. Ich bin sie damit durchgegangen – und die Absicherungen, die genau so einen Fall abfangen sollen (Rückfahrhöhe des Fenstertriggers wird nach jeder automatischen Hochfahrt aufgeräumt), habe ich am echten Code nachgestellt. Sie greifen korrekt, auch mit deinen Werten. Der Export zeigt mir aber nur den Zustand um 08:10, nicht den Ablauf davor – wann genau das Fenster gekippt hat, wann die Hochfahrt lief und was dazwischen an Positionen gemeldet wurde. Ohne diese Zeitfolge würde ich raten statt nachrechnen, und genau das möchte ich bei einer Fahrsteuerung nicht.
Dafür brauche ich einmal das Debug-Log statt des Einstellungs-Exports. So kommst du dran:
Debug-Logging für Shutter Pilot einschalten
Einstellungen → Geräte & Dienste → Shutter Pilot → die drei Punkte beim Eintrag → „Debug-Protokollierung aktivieren".
(Alternativ in der configuration.yaml:
und Home Assistant neu starten.)
Den Fehler einmal frisch auftreten lassen
Am besten genau den Ablauf von heute Morgen wiederholen: Fenster auf „gekippt", warten bis die Automatik hochgefahren ist (oder das gleich abwarten, falls sie es schon war), dann das Fenster auf „geschlossen" stellen und schauen, ob der Rolladen wieder fährt.
Das Log herunterladen
Einstellungen → System → Protokolle → oben rechts „Vollständiges Protokoll herunterladen". Das Debug-Logging bitte danach wieder auf „info" zurückstellen (nicht standardmäßig anlassen, das schreibt sonst dauerhaft sehr viel).
Mir die Log-Datei hier anhängen, am besten mit ungefährer Uhrzeit, wann du das Fenster gekippt und wann du es geschlossen hast – dann kann ich die betreffenden Zeilen direkt zuordnen.
Zum zweiten Punkt (linker Rolladen unbeschattet, rechter beschattet): lass uns den erstmal zurückstellen, bis du einen Blick auf die Bedingungen an den beiden Rollläden geworfen hast – das klang nach etwas, das an euren Einstellungen liegt, nicht am Code.
Danke fürs Dranbleiben – ohne dich wäre so mancher Fehler der letzten Wochen nicht gefunden worden.
Gestern konnte ich den Fehler nachstellen:
Tag1: Die Rolläden werden automatisch morgens hoch gefahren, dann reahiert auch der Fenstersensor nicht mehr.
Tag2: Die Rolläden werden morgens manuell hoch gefahren, danach reagiert der Fenstersensor, und fährt den Rolladen in die gekippt oder geschlossen Position, je nachdem wie das Fenster bedient wird.
Brauchst Du dazu noch Infos?
Und eine Frage habe ich jetzt noch: Für die Beschattung an eher kühleren Tagen muss ich durch externe Steuerung die Beschattung unterbinden, oder? Heute sind es bei uns nur 19 Grad und Bewölkt, aber die Beschattung hatte die Rolläden heruntergefahren.
Mir ist auch noch ein Problem aufgefallen. Wenn ich die resume-Funktion nutze, um einen Bereich wieder zu aktivieren, dann macht er nur ein Rollo, obwohl ich zwei in dem Bereich habe. Ich bin mir jetzt nur nicht ganz sicher, ob das nur Auftritt wenn Beschattung ansteht.
Eine Kleinigkeit ist mir im UI unter Bereiche aufgefallen.
Wenn dort unter Steuerungsmodus Helligkeit ausgewählt wird sind bei der Zeitsteuerung die Werte bei der Lux Hoch- und Lux Runter-Schwelle ausserhalb des Rahmens und damit nicht lesbar.
Einzig im Quermodus auf dem Tablet sind die Werte lesbar.
genau dieser Vergleich der zwei Tage war der Schlüssel – danke dafür. Es ist ein echter Fehler, und er lag exakt im Unterschied zwischen „automatisch hoch" und „von Hand hoch".
Was passiert ist: Wenn du nachts das Fenster kippst, merkt sich der Fensterkontakt-Trigger, wo der Rollladen gerade steht (bei dir 26 %), um nach dem Schließen des Fensters dorthin zurückzufahren. Fährt die Automatik morgens hoch, räumt sie diesen Merker auf – deshalb reagierte an Tag 1 nichts mehr, richtig so. Fährst du von Hand hoch, blieb der Merker stehen, und beim Umstellen von gekippt auf geschlossen hat der Trigger brav auf die gemerkten 26 % „zurückgefahren" – gegen den längst offenen Rollladen.
Ist mit 2.23.0 behoben (schon über HACS ziehbar): eine Handfahrt beendet den Fensterzyklus jetzt genauso wie die Automatik. Nach dem Update bitte Home Assistant einmal neu starten.
Zur Beschattung bei 19 °C: firebowl hat es schon gezeigt – am Bereich unter „Zusätzliche Bedingungen" einen Temperatursensor eintragen (z. B. „Beschatten ab 24 °C, aufheben unter 21 °C"). Dann bleibt die Beschattung an kühlen, bewölkten Tagen aus, ohne dass du von außen eingreifen musst.
danke – das war tatsächlich kaputt, und zwar schon länger, als es aussah. Ich habe es im Browser bei Telefonbreite nachgemessen: Das Zahlenfeld neben dem Schieber hatte die volle Zeilenbreite und hat die Einheit aus dem Rahmen geschoben. Der Fix aus einer früheren Version hat wegen einer CSS-Feinheit nie gegriffen; der Test dazu war grün, obwohl er hätte rot sein müssen. Beides ist in 2.23.0 korrigiert (Feld jetzt 88 px, Einheit steht wieder im Rahmen), und der Test rechnet das nun wirklich nach.
Nach dem HACS-Update einmal Home Assistant neu starten, damit der Panel-Cache frisch ist.
Vier Forumsmeldungen aus zwei Threads – drei Fehler behoben, eine neue Schutzfunktion gegen Sensor-Ausreißer.
Neu: Mindestdauer an der Lux-Schwelle
Was war: Im Helligkeitsmodus reichte eine einzige Sensormeldung unter der Runter-Schwelle, um alle Rollläden des Bereichs zuzufahren. Meldet die Wetterstation nach einem Neustart oder Funkaussetzer kurz 0 lx, fährt am helllichten Tag das ganze Haus zu – so gemeldet um 15:12 Uhr bei 21 000 lx.
Was ändert sich für mich: Je Bereich gibt es im Helligkeitsmodus ein neues Feld „Mindestdauer an der Schwelle" (Minuten). Ist es gesetzt, muss der Lux-Wert so viele Minuten am Stück unter der Runter- bzw. über der Hoch-Schwelle liegen, bevor gefahren wird. Eine Meldung dazwischen, die die Schwelle wieder verlässt, setzt die Uhr zurück. Auch ohne neues Sensor-Ereignis läuft die Frist ab.
Vorgabe
Empfehlung
0 – wie bisher, die erste Meldung fährt
2–3 Minuten. Die echte Dämmerung dauert länger, der Ausreißer nicht.
Behoben
Meldung
Ursache
Jetzt
Nach manuellem Hochfahren fuhr der Rollladen beim Schließen des gekippten Fensters wieder herunter (c.radi)
Der Fenstertrigger hatte sich nachts beim Kippen die Rückfahrhöhe gemerkt. Die automatische Hochfahrt räumt diesen Merker auf – eine Handfahrt tat es nicht.
Eine Handfahrt beendet den Fensterzyklus genauso wie die Automatik.
Ein Antrieb, der nur einen Funkpegel oder Batteriewert meldet, galt als von Hand gefahren
Jede Zustandsänderung des Covers zählte als Fahrt – auch ohne Positionswechsel. Das hob Nachhol-Vormerkungen auf und ließ die nächste Automatikfahrt eine Übersteuerung sehen, die es nie gab.
Ohne Positionswechsel wird nichts angefasst.
resume_automation mit area_id fuhr nur einen von zwei Rollläden (pcsv17)
Der Dienst filterte nur über den Runter-Bereich. Wer morgens raumweise und abends alle zusammen fährt, hat den Raum nur als Hoch-Bereich.
Gemeint sind alle Rollläden, die der Bereich in irgendeiner Richtung fährt.
Lux-Schwellen im Bereichsformular auf Telefon/Tablet hochkant außerhalb des Rahmens (wolfvs)
Die feste Breite des Zahlenfelds hat wegen einer CSS-Spezifitätsfalle nie gewirkt; das Feld nahm die ganze Zeile ein.
Nachgemessen: 88 px statt 349 px, die Einheit steht wieder im Rahmen.
Hinweise
Keine Änderung an bestehenden Einstellungen nötig. Die Mindestdauer ist optional; wer einen Außensensor über MQTT oder Funk hat, sollte sie setzen.
Update über HACS, danach Home Assistant neu starten (Panel-Cache).
ich habe das nachgestellt: mit zwei Rollläden, die denselben Bereich fürs Hoch- und Runterfahren haben, fährt resume_automation beide – mit und ohne anstehende Beschattung. Einen Fall gab es aber, in dem nur einer getroffen wurde: Der Dienst hat bisher nur über den Runter-Bereich gefiltert. Wenn du also morgens raumweise und abends alle zusammen fährst, gehört der zweite Rollladen zum Raum nur als Hoch-Bereich – und wurde übersprungen.
Das ist in 2.23.0 geändert: mit area_id sind jetzt alle Rollläden gemeint, die der Bereich in irgendeiner Richtung fährt.
Falls es nach dem Update weiterhin nur einer ist, schick mir bitte deinen Einstellungs-Export (Einstellungen-Tab, ganz unten) und den genauen Dienstaufruf (mit area_id oder entity_id?), dann rechne ich das mit deinen Werten nach.
stehe gerade irgendwie auf dem Schlauch, verwende Version 2.23 war bei den vorherigen Version bei mir aber auch schon so. Ich habe unter Bereich einen Temperatursensor für die Beschattung ergänzt, dieser funktioniert aber nicht oder ich verstehe die Funktion falsch. Beschattung soll erst ab > 25 wirken, aber er fährt trotzdem aktuell in Beschattung.
Bei den Rollladen habe ich keinen Temperatursensor eingetragen. Habe auch schon einmal einen anderen Temperatursensor probiert, aber gleicher Effekt
das ist kein Fehler, sondern die Hysterese zwischen den beiden Feldern: „Beschatten ab" schaltet die Bedingung ein, aber sie bleibt danach aktiv, bis der Wert unter „Aufheben unter" fällt – nicht schon unter „Beschatten ab". Das soll verhindern, dass die Rollläden bei einem Wert knapp an der Schwelle ständig hin- und herfahren.
Schau mal unter Entwicklerwerkzeuge → Verlauf beim Sensor sensor.temperature_garten_temperature, ob er heute Vormittag schon mal auf/über 25° war (z. B. durch direkte Sonne aufs Gehäuse). Wenn ja, erklärt das die aktive Beschattung, auch wenn er jetzt schon wieder darunter liegt – erst unter 24° löst sie sich.
Falls du das nicht willst und lieber einen scharfen Schwellwert ohne Hysterese hättest: Feld „Aufheben unter" einfach leer lassen – dann gilt derselbe Wert wie „Beschatten ab" (steht auch so im Hinweistext), und die Beschattung schaltet sofort ab, sobald der Sensor unter 25° fällt.
so hatte ich die Funktion auch verstanden.
Jetzt leider wieder der gleiche Effekt. Sind gerade wieder auf Verschattung gefahren. Der aktuelle Temperaturwert ist 14.2. Ich habe die Schwellen vorher nochmal höher gelegt auf 90 /89
Irgendwie wird das bei mir nicht abgefragt.
Wenn in der Übersicht das Feld Sonnenschutz aktiv grün hinterlegt ist bedeutet das doch, das alle Bedingungen für den Bereich erfüllt sind, oder?
Ein von Hand hochgefahrener Rollladen konnte beim Fensteröffnen wieder herunterfahren
Eine vorgemerkte Nachhol-Fahrt konnte eine spätere manuelle Fahrt überleben
Neu: Mindestdauer an der Lux-Schwelle
Behoben
Hinweise
