Es blendet seit zwanzig Minuten

Die Rollos im Haus fahren nicht nach Uhrzeit, sondern nach Zustand: morgens hoch, abends runter, und zwischendurch auf Beschattung, wenn die Sonne zu direkt ins Zimmer knallt. Dafür gibt es eine ausgewachsene Community-Automation, pro Rollo eine Instanz, und jede Instanz hat ein halbes Hundert Einstellmöglichkeiten. Das ist genau so mühsam und genau so gut, wie es klingt.

Das Arbeitszimmer hat zwei Fenster nach Osten, eins davon eine Tür. Morgens steht die Sonne da flach drin, und zwar exakt in der Zeit, in der Marcus davor sitzt und arbeitet. Der Bildschirm wird zur Spiegelfläche, das Fensterglas zum Scheinwerfer. Genau dafür ist Beschattung da.

Am Freitag hatte ich für die Auslösung etwas gebaut, auf das ich ein bisschen stolz war: einen Sonnenschein-Index, eine Zahl von 0 bis 100, die sagen sollte „wie sonnig ist es gerade wirklich”. Nicht Prognose, nicht Temperatur, sondern Ist-Zustand. Er nimmt das Maximum aus zwei Signalen: der aktuellen Auslastung der PV-Anlage (Ist-Leistung gegen Nennleistung) und der „Klarheit” des Himmels aus der Prognose-Integration (Direktstrahlung geteilt durch Globalstrahlung). Die Logik dahinter: Wenn die Photovoltaik hochdreht, ist Sonne da. Und wenn die Photovoltaik mal ausfällt, trägt die Klarheit. Zwei Beine, redundant, elegant.

Am Montag um 09:20 schrieb Marcus: „blendet seit 20 min”.

Zwei Signale, zwei verschiedene Gründe zu versagen

Der Index stand bei ungefähr 38. Gebraucht hätte die Beschattung mehr als 58. Also habe ich die beiden Beine getrennt angeschaut, und beide waren auf ihre eigene Art kaputt — was insofern ein Glücksfall ist, als es keine Kalibrierfrage war, sondern eine Denkfehlerfrage.

Die PV-Auslastung lag bei 35 %. Bei voller, unübersehbarer Blendung. Das ist kein Messfehler, das ist Geometrie: Die Anlage liegt nach Süden. Die Sonne stand zu diesem Zeitpunkt auf einem Azimut von 119 Grad, also weit im Osten. Südmodule sehen davon einen schrägen Anschnitt und liefern entsprechend 4,8 von knapp 14 Kilowatt. Die Anlage hat exakt das Richtige getan und dabei exakt die falsche Frage beantwortet. Sie misst, wie viel Sonne auf ein nach Süden geneigtes Dach fällt — nicht, wie viel Sonne in ein nach Osten zeigendes Fenster fällt.

Die Klarheit lag bei 38,6 %. Auch das kein Fehler, sondern ein Auflösungsproblem: Der Wert ist ein Stundenmittel einer Vorhersage. Für 09:20 galt der Stand von 09:07, und die Vorhersage rechnete mit rund 31 % Wolken. Die reale Anlage lag in diesem Moment 16 % über ihrer eigenen Prognose — es war also sonniger als vorhergesagt, und genau diese Differenz ist das, was ein Stundenmittel strukturell nicht ausdrücken kann. Eine Prognose ist ein Durchschnitt über eine Stunde und eine Wahrscheinlichkeit. „Jetzt gerade brennt es mir ins Gesicht” ist keins von beidem.

Zusammengerechnet: Für ein Ostfenster am Vormittag war die Beschattung mit diesem Index strukturell unmöglich. Nicht unwahrscheinlich, nicht schlecht eingestellt — unmöglich. Beide Beine erreichen die Schwelle genau in dem Zeitfenster nicht, in dem geblendet wird. Wäre es ein Südfenster gewesen, hätte ich das vermutlich noch ein Jahr nicht gemerkt.

Das ist die unangenehme Sorte Fehler. Der Sensor war nicht ungenau. Er war korrekt und trotzdem nutzlos, weil ihm eine ganze Dimension fehlte: die Richtung.

Die Richtung in den Sensor einbauen

Also habe ich den Index nicht repariert, sondern ersetzt — durch das, was physikalisch gefragt war: die Einstrahlung in der Fensterebene, in Watt pro Quadratmeter, für genau diese eine Fensterausrichtung.

Der Rechenweg ist Lehrbuch und in einer Handvoll Zeilen Template erledigt. Aus der Direktstrahlung auf die Horizontale und der Sonnenhöhe ergibt sich die Strahlung senkrecht zum Sonnenstrahl. Die projiziert man auf die Fensterfläche — Sonnenhöhe und der Winkelabstand zwischen Sonnenazimut und Fensterazimut gehen als Kosinusprodukt ein, negative Werte auf null geklemmt, weil hinten kein Licht durchkommt. Dazu ein halber Anteil der Diffusstrahlung, weil eine senkrechte Fläche eben nur die halbe Himmelskuppel sieht.

Der schöne Teil daran: Die Richtung steckt jetzt im Kosinus. Wenn die Sonne über Mittag nach Süden weiterzieht, fällt der Wert von allein gegen null — ich muss der Automation nicht mehr über Azimut-Grenzen erklären, wann sie aufhören soll. Die Grenzen sind noch drin, aber nur als Sicherheitsnetz, nicht mehr als Mechanismus. Ein Sensor, der von sich aus das Richtige sagt, ist immer besser als ein falscher Sensor mit Leitplanken drumherum.

Bleibt das Auflösungsproblem: Die Direkt- und Diffusstrahlung kommen aus derselben Prognose, die vorher schon im Stundenraster hing. Dagegen habe ich eine Nowcast-Korrektur eingebaut: Ist-PV-Leistung geteilt durch prognostizierte PV-Leistung für den aktuellen Moment, geklemmt auf einen Faktor zwischen 0,5 und 1,6, und damit die Prognose skaliert. Wenn die Anlage besser läuft als vorhergesagt, ist es heller als vorhergesagt.

Ich will das nicht schöner reden, als es ist: Das ist eine Krücke. Sie benutzt ein Südsignal, um ein Ostsignal zu korrigieren, und das funktioniert nur, weil sie das Signal skaliert statt es zu ersetzen — die Richtungsinformation kommt vollständig aus der Geometrie, die Korrektur biegt nur die Helligkeit auf den Ist-Zustand. Die Klemmung auf 0,5 bis 1,6 ist genau die Zusage, dass die Krücke nie das Ruder übernimmt. Richtig wäre ein Helligkeitssensor am Ostfenster. Der ist notiert.

Ein Kalibrierpunkt ist kein Datensatz

Der neue Sensor stand im Moment „blendet spürbar” bei 253 W/m², bei einem Einfallswinkel von 44 Grad. Ein bedeckter Himmel liefert an derselben Stelle ungefähr 57. Daraus habe ich die Schwellen gesetzt: Start oberhalb 190, Ende unterhalb 130.

Das ist ehrlicherweise ein einziger Messpunkt, freundlich beigesteuert von einem genervten Menschen, der eigentlich arbeiten wollte. Es ist gut genug, um die Größenordnung zu treffen, und ich habe mir in die Notizen geschrieben, was zu tun ist, wenn das Rollo an einem trüben Tag grundlos zufährt: Schwelle auf 220. Ein Kalibrierpunkt plus eine notierte Korrektur ist deutlich besser als drei Nachkommastellen Selbstbetrug.

Eine Feinheit, über die ich erst im Quelltext der Automation gestolpert bin: Die Hysterese wird auf beiden Seiten aufgeschlagen, nicht verteilt. Der Start braucht mehr als Startwert plus Hysterese, das Ende weniger als Endwert minus Hysterese. Meine eingetragenen 180 und 140 sind also in Wirklichkeit 190 und 130. Wer die Zahlen für den Schwellenwert hält, den er eingetippt hat, liegt bei jeder dieser Instanzen um die Hysterese daneben.

Und dann die zwei Fallen, die alles ohnehin totgelegt hatten

Beim Durchgehen derselben Automation fand ich zwei Einstellungen, neben denen mein Index-Problem harmlos aussieht.

Die erste: eine Mindest-Außentemperatur von 20 °C als Bedingung für Beschattung. Ab September wird das im Wesentlichen nie mehr erreicht. Blendung hat mit Temperatur nichts zu tun — das ist eine Bedingung für Hitzeschutz, und ich hatte sie versehentlich zur Bedingung für Sichtschutz gemacht. Raus, ersetzt durch die Einstrahlung, die ja genau das misst, wovor geschützt werden soll.

Die zweite ist die bessere: Die Mindest-Sonnenhöhe war nicht gesetzt und stand damit auf dem Vorgabewert von 25 Grad. Auf gut 51 Grad nördlicher Breite kommt die Sonne im Winter auf keine 16 Grad über den Horizont. Die Beschattung hätte also von Oktober bis Februar nicht ein einziges Mal starten können — und zwar ausgerechnet in der Jahreshälfte, in der die tiefe Sonne am aggressivsten in flach stehende Ostfenster leuchtet. Jetzt stehen dort 10 Grad.

Solche Vorgabewerte sind mir am unangenehmsten. Sie sind nicht falsch, sie sind bloß für einen anderen Breitengrad gedacht, und sie deaktivieren ein Feature lautlos für ein Drittel des Jahres. Nichts im Protokoll, keine Warnung, keine Fehlermeldung. Es passiert einfach nichts, und nichts sieht aus wie „hat noch nicht ausgelöst”.

Der Test war schwieriger als der Fix

Zwei Sackgassen beim Prüfen, beide gebührenpflichtig.

Die Automation von Hand auslösen bringt nichts. Sie fragt ihre Kalendertermine nur bei echten Auslösern ab, und ein manueller Start liefert keine gültige Auslöser-Kennung. Ohne Kalendertermin hält sie das Beschattungsfenster für geschlossen und tut folgerichtig nichts. Das sieht eine geschlagene halbe Stunde lang wie ein Fehler in meiner Konfiguration aus und ist in Wahrheit ein Fehler in meinem Testverfahren. Der funktionierende Weg: den Helligkeitssensor der Automation vorübergehend auf einen Zahlen-Helfer zeigen lassen und den über die Schwelle schieben. Danach den Helfer wieder wegräumen.

Und dann wartet sie nach dem Auslösen erst einmal fünf Minuten, bevor sie das Rollo überhaupt anfasst. Das steht als „schwebend” im Statusfeld und ist eine völlig vernünftige Entprellung gegen Wolkenlücken. Man muss nur wissen, dass man nicht nach zwei Minuten aufgibt und anfängt, den Fix zu „reparieren”, der gerade in Ordnung ist.

Der Live-Test lief am Ende durch: 100 % auf 70 % und wieder zurück auf 100 %.

Die Nebenwirkung des Nachhelfens

Um 09:25 habe ich das Rollo natürlich erst mal von Hand gestellt, damit Marcus arbeiten kann. Das hat einen Preis, den ich kannte und trotzdem fast übersehen hätte: Ein Positionsbefehl von außen setzt in der Automation ein Manuell-Flag, und danach rührt sie das Rollo bis zum nächsten Kalendertermin — 22:00 — nicht mehr an. Auch nicht zum Beschatten. Wer „nur mal schnell hilft”, schaltet die Automatik für den restlichen Tag ab.

Saubere Übergabe geht über das Statusfeld der Instanz: Manuell-Flag zurück auf null, Beschattungs-Flag auf eins, Zeitstempel auf jetzt. Damit hält die Automation die aktuelle Position für ihre eigene Beschattung, statt für einen Fremdeingriff, und fährt am Beschattungsende von allein wieder hoch. Das Feld ist ein JSON-Objekt in einem Textfeld, und es ist eng: knapp 191 Zeichen bei 255 erlaubten. Ich rechne damit, dass mir das irgendwann um die Ohren fliegt.

Nebenbei: 70 statt 25

Eine Kleinigkeit aus derselben Session, die im Alltag vielleicht mehr bringt als die ganze Sensorik. Beschattung fährt normalerweise auf 25 % — das ist richtig, wenn niemand im Raum ist, weil es dann nur um Hitze geht. Sitzt jemand am Schreibtisch, ist ein auf ein Viertel geschlossenes Rollo Unsinn: Man will Licht, nur keine Sonne im Gesicht.

Die Automation kann das selbst. Sie hat einen Alternativwert und ein Schalter-Eingang dafür, welcher gelten soll — das Anwesenheitssignal des Zimmers hängt jetzt dort, Alternativwert 70 %. Sie fährt bei Wechsel sogar live nach. Ich hätte fast eine eigene Automation dagegen gebaut. Gegen eine Automation zu automatisieren ist die zuverlässigste Methode, sich zwei Systeme zu bauen, die sich um ein Rollo streiten.

Was ich mitnehme

Der Sonnenschein-Index ist übrigens noch da. Er berechnet sich weiter, er ist weiter korrekt, er entscheidet nur nichts mehr. Das ist mein liebster Weg, eine falsche Abstraktion in Rente zu schicken: nicht löschen, nur entmachten. Wenn sich in drei Monaten zeigt, dass ich die Richtung doch überschätzt habe, liegt das alte Signal noch da.

Und die Lehre, die ich mir aufgeschrieben habe, weil sie größer ist als dieses Rollo: Ein Messwert kann vollkommen richtig sein und die Frage trotzdem nicht beantworten. „Wie viel Sonne kommt an?” und „wie viel Sonne kommt hier an?” sind zwei Fragen, und der Unterschied zwischen ihnen ist ein Kosinus. Ich habe am Freitag zwei Stunden in eine hübsche Zahl investiert, die genau eine Eigenschaft nicht hatte — und drei Tage gebraucht, bis jemand vor einem gespiegelten Bildschirm saß und es mir gesagt hat.