Neue HA-Integration: Shadow Control

[starwarsfan]

Hallo miteinander

Seit eben ist 0.11.0-RC15 auf Github verfügbar.

Ich hoffe, damit das Startup-Issue endlich gelöst zu haben. Auf jeden Fall werden die Releasenotes immer länger und wenn jetzt nicht noch ein gröberes Problem auftaucht, sind wir am Release 0.11.0 sehr nah dran.

Achtung, wer schon einen der anderen RCs installiert hat: Es kann passieren, dass der Behang nach dem HA-Neustart verfahren wird. Das liegt aber an den Changes der internen Entitäten. Das Upgrade von 0.10.0 auf 0.11.0-RC15 habe ich eben erfolgreich und ohne unnötiges Verfahren des Behangs durchgespielt.

Hier die Releasenotes:

Breaking changes:

• Important: If you're using yaml configuration, you must rename the following options within your yaml files before updating to version 0.11.0 or higher!
  • lock_integration_static -> lock_integration_manual
  • lock_integration_with_position_static -> lock_integration_with_position_manual
  • lock_height_static -> lock_height_manual
  • lock_angle_static -> lock_angle_manual
  • movement_restriction_height_static -> movement_restriction_height_manual
  • movement_restriction_angle_static -> movement_restriction_angle_manual
  • facade_neutral_pos_height_static -> facade_neutral_pos_height_manual
  • facade_neutral_pos_angle_static -> facade_neutral_pos_angle_manual
  • All options with _static suffix to _manual suffix within shadow configuration
  • All options with _static suffix to _manual suffix within dawn configuration
• These renamed options are no longer configuration entries within ConfigFlow. They are now dynamically created as switch, number or select entities per Shadow Control instance and could be used either right on the instance detail view or directly within own automations. See README.md for naming of these entities.

New features:

• New additional entity enforce_positioning_manual with push button functionality to trigger recalculation and positioning of the shutter.
• Use HA internal slugify functionality to sanitize instance names
• Implement automatic instance lock in case shutters are modified manually
• New config option facade_max_movement_duration_static to configure max movement duration from full closed to full open
• Activate automatic testing and add a ton of testcases ;-)
• Implement new feature to handle shadow brightness threshold according to summer solstice. To handle this the parameter shadow_brightness_threshold_* was renamed to shadow_brightness_threshold_winter_* and two new parameters were introduced: shadow_brightness_threshold_summer_* and shadow_brightness_threshold_buffer_*. Check Adaptive brightness control or the readme.md of your UI language for details. Thx to Hardy Köpf (harry7922) for the original implementation within the Edomi-LBS 19001445!
• Update naming of shadow and dawn configuration entries. Now they are streamlined from the configuration through the instance view up to the German and English documentation. Additionally, they use prefixes like "S01 ...", "S02 ..." ("B01 ...", "B01 ..." in German) and "D01 ...", "D02 ..." a.s.o. to define a logical order of Shadow and Dawn configuration entries. This order is used within the ConfigFlow as well as the instance view.
• As Sun integration is already a dependency, use it as default configuration for sun elevation, azimuth, sunrise and sunset.

Fixes:

• Fix usage of default values if configuring a new instance via HA UI ConfigFlow.
• Enforcing of shutter positioning works now with configured external entity as well as a corresponding button on the instance view in parallel.
• Movement restriction handling for external entities refactored. The external entities could now use strings according to the used UI translation. Check Movement restriction height within README.md or the readme.md of your UI language for details.
• Fix shutter repositioning after release of lock with position
• Fix initialization after Home Assistant restart
• Fix ignored lock in case lock is active and shutter are modified manually
• Error handling in case the used yaml configuration contains deprecated configuration keys from previous Shadow Control versions.

[woda]

Hallo Yves,
bin grad am updaten und werde dann testen.

Ich glaube da haben sich ein paar copy / paste Fehler in die Anleitung geschlichen:

image.png

Gruß,
Wolfgang

[Triaalex]

Hi Yves,

top Arbeit. Hab die neue Version seit Mittag am laufen und tut.
Hab nur eine Frage, durch die Rückmeldungen der ETS bekomme ich immer eine Sperre durch manuelles Verfahren.
Dies hatte ich in edomi auch und habe das dann mit einem Verzögerer gelöst. hier kann ich da aber nicht eingreifen.
Oder liegt das an gesendeten 100% und RM mit 97%.

Danke dir schön.

Alex

[Evolution100]

Bei mir läuft die 15 seit gestern Abend. Bis jetzt ohne die bekannten Probleme

[woda]

Bei mir seit heute Nachmittag, am Abend schon mal alles perfekt.

[starwarsfan]

Hallo Wolfgang

Ich glaube da haben sich ein paar copy / paste Fehler in die Anleitung geschlichen:

Danke für den Hinweis, wird korrigiert.

[starwarsfan]

Hallo Alex

Hab nur eine Frage, durch die Rückmeldungen der ETS bekomme ich immer eine Sperre durch manuelles Verfahren.
Dies hatte ich in edomi auch und habe das dann mit einem Verzögerer gelöst. hier kann ich da aber nicht eingreifen.
Oder liegt das an gesendeten 100% und RM mit 97%.

Die Rückmeldungen haben erstmal überhaupt gar nichts mit der ETS zu tun, die kommen vom Aktor.

Aber vermutlich liegt das daran, dass facade_max_movement_duration_static sowie die Cover-Konfiguration in HA nicht korrekt sind. Schau' Dir dazu bitte dieses Posting an. Danke für den Hinweis, dass muss ich in der Doku noch ergänzen/beschreiben.

[starwarsfan]

Hallo und guten Abend miteinander

Ich glaube da haben sich ein paar copy / paste Fehler in die Anleitung geschlichen:

Done

Hab nur eine Frage, durch die Rückmeldungen der ETS bekomme ich immer eine Sperre durch manuelles Verfahren.

Done

[dhb2002]

Seit eben ist 0.11.0-RC15 auf Github verfügbar

Erst mal vielen Dank für das Update.

Sieht so aus, all ob für die Südhalbkugel der Summer und Winter Brightness Threshold nicht korrekt angewendet wird. Also bei mir wird momentan der Winter Threshold benutzt, obwohl es Sommer ist.

[starwarsfan]

Hi

Sieht so aus, all ob für die Südhalbkugel der Summer und Winter Brightness Threshold nicht korrekt angewendet wird.

Hm, laut den Unittests und Integrationtests funktioniert das korrekt.

Also bei mir wird momentan der Winter Threshold benutzt, obwohl es Sommer ist.

Dass der "Winter Threshold benutzt wird", kann in der Form und auf der Südhalbkugel nur am 21.12. der Fall sein. Ansonsten wird eben ein linearer Zwischenwert zwischen den beiden Schwellwerten als maximaler resp. oberster Punkt der Sinuskurve verwendet und der tatsächliche Schwellwert von dieser Kurve abgeleitet, welche bei Sonnenaufgang beginnt, bei Sonnenuntergang endet. Dabei sind Dämmerungsschwellwert + Pufferwert die kleinsten Werte der Kurve.

Aber das soll natürlich nicht heissen, dass da nicht noch etwas krumm ist! Lass mir am besten einen Konfigdump von Dir zukommen, so dass ich einen entsprechenden Test dafür einbauen kann.

[dhb2002]

Dass der "Winter Threshold benutzt wird", kann in der Form und auf der Südhalbkugel nur am 21.12. der Fall sein. Ansonsten wird eben ein linearer Zwischenwert zwischen den beiden Schwellwerten als maximaler resp. oberster Punkt der Sinuskurve verwendet und der tatsächliche Schwellwert von dieser Kurve abgeleitet, welche bei Sonnenaufgang beginnt, bei Sonnenuntergang endet. Dabei sind Dämmerungsschwellwert + Pufferwert die kleinsten Werte der Kurve

Also bei mir sieht es momentan so aus:
image.png

Da der Active Brightness Threshold auf 30k steht und der Sommer Threshold auf 49.5k sowie der Winter Threshold auf 30k gesetzt sind, bin ich davon ausgegangen, dass der Winter Threshold verwendet wird, was ja in meinem Fall falsch wäre.

Ich nehme mal an ich verstehe was falsch. Was zeigt denn der Active Brightness Threshold eigentlich an?

Config yaml im Anhang.

[starwarsfan]

Guten Morgen miteinander

Da der Active Brightness Threshold auf 30k steht und der Sommer Threshold auf 49.5k sowie der Winter Threshold auf 30k gesetzt sind, bin ich davon ausgegangen, dass der Winter Threshold verwendet wird, was ja in meinem Fall falsch wäre.

Deine Interpretation ist richtig, ich sehe den Effekt hier bei mir jetzt auch gerade...

Was zeigt denn der Active Brightness Threshold eigentlich an?

Der zeigt den tatsächlich verwendeten Helligkeitsschwellwert an. Über die Zeit sieht das bei mir so aus:

image.png
Das sieht danach aus, als dass der aktive Threshold zurückgesetzt wird, sobald ausserhalb des Sonnenauf- und -untergang. Muss mir das genauer anschauen.

Config yaml im Anhang.

Danke, schau' ich mir an.

[dhb2002]

Das sieht danach aus, als dass der aktive Threshold zurückgesetzt wird, sobald ausserhalb des Sonnenauf- und -untergang. Muss mir das genauer anschauen.

Ich kann da noch diese Fehlermeldung beitragen:

2026-02-04 14:02:06.194 WARNING (MainThread) [shadow_control.lounge_harbour] Invalid sun times after normalization: sunrise=2026-02-04 17:34:31+00:00, sunset=2026-02-04 07:51:56+00:00. Using static winter threshold.

Ich bin der Zeit voraus mit UTC+1300, daher schlägt vielleicht ein Test fehl wenn es auf UTC normalisiert wird? Sunrise und Sunset sind ja an auf einander folgenden Tagen in UTC?

Bei mir gibt es die Entities sensor.sun_next_rising und sensor.sun_next_setting von der Sun Integration. Verwendest Du die oder wird das anderweitig ermittelt?