Neue HA-Integration: Shadow Control

[Triaalex]

Bei mir verhält sich die Beschattung auch etwas komisch, ich verwende ja auch Mode 2.
Musste aber bei mir von Anfang an den Angel Invertiert dass es gepasst hat, hängt aber evtl. auch mit SMI zusammen.

Ich versuch morgen mal einen Log zu erstellen.

Hi unclsam,

eigentlich kann das invertieren nicht richtig sein. Wenn du deine Cover über HA verfährst dann läuft das doch auch richtig? 100% bedeutet geschlossene Lamelle und geschlossene Höhe in den Aktoren. Ist das bei dir anders?

Ich denke, dass das ganze mit dem Mode 2 zusammenhängt. Ich habe heute mal 3 Raffstore produktiv genommen. sind im Nebengebäude. Diese lasse ich jetzt einfach mal mit Debug laufen und sende das Ganze dann an Yves.
Muss mir dann bitte nur einer helfen, denn mit dem aktuellen Update bekomme ich keine Log`s mehr raus??

Ich hatte den LBS in edomi jahrelang ohne Probleme am laufen auch mit Mode2 und alles lief super. Daher verstehe ich gerade das Ganze nicht wirklich, zumal sich Raffstore unterschiedlich verhalten, obwohl diese gleich konfiguriert sind.

Ich schätze die Arbeit und vor allem das Engagement von Yves sehr und möchte mich auch hier nochmals bei ihm bedanken, dass er sich das "antut".

mfg Alex

[Triaalex]

Hallo Alex



Das sieht verdächtig nach einem Problem bei Mode2-Behang aus. Könntest Du zum Test einen der Raffs auf Mode1 konfigurieren? Die Beschattung wird dann natürlich nicht vernünftig funktionieren aber die Frage ist, ob/was dann berechnet wird!? Und natürlich wäre auch das Debug-Log von Interesse, sowohl bei Mode2 als auch Mode1.

Hi Yves,

denke ich auch. Habe gerade mit unclesam geschrieben. Wenn du mir dann bitte helfen könntest, die Log`s raus zu bekommen, denn mit den Befehlen und Pfaden legt er nichts an, bzw. läuft auch im Terminal nichts durch. Dies scheint seit dem letzten Update so zu sein. Vorher habe ich ja die Yaml gesichert, wie wir geschrieben haben.

Wie läuft das eigentlich mit der Sperre, wenn du 2 Raffstore (Cover) unter einem Baustein hast? Welcher sperrt dann, welche RM wird berücksichtigt? Dies habe ich ausgeschlossen, da ich jedes Cover einzeln behandle. Wie verhält sich der neue Entsperren-Button? Entsperrt der Alles? (Bausteinsperre, Sperre mit Zwangsposition?)

Was hat sich in der Berechnung zu edomi geändert?

bis dann Alex

[starwarsfan]

Hallo Alex

Wenn du mir dann bitte helfen könntest, die Log`s raus zu bekommen, denn mit den Befehlen und Pfaden legt er nichts an, bzw. läuft auch im Terminal nichts durch. Dies scheint seit dem letzten Update so zu sein. Vorher habe ich ja die Yaml gesichert, wie wir geschrieben haben.

So wie es in #230 geschrieben wurde, da hat sich nichts dran geändert. Ich sehe nur gerade, dass ich das in der Doku noch nachführen muss.

Wie läuft das eigentlich mit der Sperre, wenn du 2 Raffstore (Cover) unter einem Baustein hast? Welcher sperrt dann, welche RM wird berücksichtigt?

Zitat aus der Dokumentation:

Behang-Entitäten
(yaml: target_cover_entity)

Hier werden die zu steuernden Behang-Entitäten verbunden. Es können beliebig viele davon gleichzeitig gesteuert werden. Allerdings empfiehlt es sich, nur die Storen zu steuern, welche sich auf der gleichen Fassade befinden, also das gleiche Azimut haben. Für die weiteren internen Berechnungen wird der erste konfigurierte Behang herangezogen. Alle anderen Storen werden identisch positioniert.

Sprich, der erste konfigurierte Behang wird ausgewertet, alle anderen lediglich identisch positioniert. Im Umkehrschluss heisst das, dass nur beim ersten konfigurierten Behang eine manuelle Manipulation zum Autolock führt.

Aber explizit getestet habe ich das mit dem Autolock und mehr als einem Cover nicht explizit. Solltest Du das machen, lass' mich bitte wissen, wie es sich verhält.

Wie verhält sich der neue Entsperren-Button? Entsperrt der Alles? (Bausteinsperre, Sperre mit Zwangsposition?)

Ja, der sollte eigentlich alles entsperren, wobei es hauptsächlich um den Autolock geht. Für die anderen Sperrvarianten gilt das natürlich nur solange, wie darauf keine eigenen Entitäten konfiguriert wurden.

Was hat sich in der Berechnung zu edomi geändert?

Grundsätzlich nichts, es steckt die gleiche Überlegung dahinter. Allerdings funktioniert die Cover-Interaktion bei HA völlig anders als unter Edomi, daher braucht's ja auch den zusätzlichen Parameter mit der maximalen Cover-Laufzeit.

[starwarsfan]

Hallo miteinander

Ich denke, dass das ganze mit dem Mode 2 zusammenhängt.

Möglich ist alles...

Ich hatte den LBS in edomi jahrelang ohne Probleme am laufen auch mit Mode2 und alles lief super. Daher verstehe ich gerade das Ganze nicht wirklich, zumal sich Raffstore unterschiedlich verhalten, obwohl diese gleich konfiguriert sind.

Das kann ich mir allerdings nicht vorstellen, irgendwo muss es einen Unterschied geben...

Ich schätze die Arbeit und vor allem das Engagement von Yves sehr und möchte mich auch hier nochmals bei ihm bedanken, dass er sich das "antut".

Joa danke, immer wieder eine Herausforderung...

[Triaalex]

Hi,

als kurzen Zwischenstand aus Laiensicht . Es sieht so aus, dass bei sehr spitzem Sonnenwinkel (Azimut) zum Store diese Fehlerberechnung kommt

image.pngimage.png
und wohl kein Lamellenwinkel berechnet werden kann, daher kommt eine 0 zurück und die Store sind 100% nach innen geschlossen. Ab einem bestimmten Winkel, so scheint`s, kommt die Berechnung zustande und alles läuft top. Bis wieder eine bestimmter "spitzer" Winkel erreicht wird und er wieder mit "0" antwortet. Wirs`d du auch in den Storen (Log`s) dann sehen, sende ich dir zu!

Das 1ste Problem, dass er über den "0-Status" nicht hinauskam erklärt sich mir mit der "doppelten" RM und daraus resultieren der Sperre. Dann blieb er bei "0" und das Spiel begann von neuem. Habe ich gelöst mit erheblich höherer Laufzeit. Ist bei mir o.k. da ich keinen Lichtstreifen benötige, denn beides wird wohl nicht funktionieren.

Zum Thema Sperren, hier brauche ich keine Entitäten, denn diese sind doch bei dir schon als Slider und Nummern angelegt. Diese beschreibe ich einfach. Ich hab`s noch nicht getestet, wie das mit dem "Entsperren" dann läuft. Muss ich mir mal ansehen, denn es wäre fatal, wenn mein Fenster(Tür) eine Zwangsposition auslöst, 0% und 0%, weil ich im Garten bin und jemand (Kind on Board) drückt dann auf dem Dash den Button und ich steh dann da und komm nicht rein. Melde mich dazu.

Ich habe von Edomi zu HA alle Eingaben 1:1 übernommen. Habe ich 100 Mal überprüft, da ich am Anfang immer an meinen Eingaben gezweifelt habe. Ich hatte nur ein paar Krücken bauen müssen. 1. Verzögerung RM vom Bus, 2. Autolock nach einer Stunde entsperren, und noch einen entprellten Sonneneingang, damit er nicht bei "Sonnenschwankungen" ein "Auf-Zu Spiel" veranstaltet. Habe ich jetzt wieder.

Auszug Log als Zip. Nur SC Infos!

Alex

[Triaalex]

Hi



Ja klar, siehe was ich oben geschrieben habe und was die Lösung dafür ist. Du solltest Dir den Konfig-Export anschauen, das für jede Instanz machen und daraus die yaml-Konfigurationen erzeugen.

Nachtrag: Das Log wird seit einiger Zeit anders verwaltet, daher hat sich das Cmd zur Logausgabe geändert:

ha core logs -f

Hi Yves,

brauchst du nicht mehr so machen.

Einstellungen => System => Prorokoll oben Rechts das Menü => unveränderte Protokolle anzeigen und dann downloaden , da kannst du auch die Zeilenanzahl angeben oder direkt rauskopieren.

Hab ich gerade nachgelesen und so dein Log erstellt.

Das Thema Entsperren-Button wirkt auf alle Sperren ausser man steuert dies über einen eigenen Helfer (Entität), wie du geschrieben hast.
Habe ich gerade probiert.

Kannst du mir das erklären?
image.png
image.pngMuss die Elevation zudem nicht immer gleich sein? Welche Formel steckt da dahinter. Denn meine Raffstore sind schon lange im Schatten, ab ca. 11,5° real. Mit Puffer bei mir 10° Wie muss ich die Umrechnung anstellen, dass das passt?

Alex

[Triaalex]

Guten Morgen Yves,

anbei der aktuelle Auszug des Fehlers.

2026-02-28 09:13:25.468 DEBUG (MainThread) [shadow_control.wohnen_rechts] State change for entity: switch.wohnen_rechts_sperren_mit_zwangsposition
2026-02-28 09:13:25.468 DEBUG (MainThread) [shadow_control.wohnen_rechts] Old state: unavailable
2026-02-28 09:13:25.468 DEBUG (MainThread) [shadow_control.wohnen_rechts] New state: off
2026-02-28 09:13:25.468 INFO (MainThread) [shadow_control.wohnen_rechts] Lock with position was disabled and simple lock already disabled
2026-02-28 09:13:25.468 DEBUG (MainThread) [shadow_control.wohnen_rechts] Checking if facade is in sun
2026-02-28 09:13:25.468 DEBUG (MainThread) [shadow_control.wohnen_rechts] sun_entry_angle: 110.0, sun_exit_angle: 257.0, sun_exit_angle_calc: 147.0, azimuth_calc: 17.89
2026-02-28 09:13:25.468 DEBUG (MainThread) [shadow_control.wohnen_rechts] Current sun position (a:e): 127.89°:19.02°, facade: 187.0°
2026-02-28 09:13:25.468 DEBUG (MainThread) [shadow_control.wohnen_rechts] Virtual deep and height of the sun against the facade: 0.513391483659243, 0.34471811186378687, effektive Elevation: 33.87949375956154
2026-02-28 09:13:25.468 DEBUG (MainThread) [shadow_control.wohnen_rechts] Finished facade check:
-> Real azimuth 127.89° and facade at 187.0° -> IN sun (from 110.0° to 257.0°)
-> Effective elevation 33.9° for given elevation of 19.0° -> IN min-max-range (20.0°-90.0°)
2026-02-28 09:13:25.468 DEBUG (MainThread) [shadow_control.wohnen_rechts] Starting calculation of shutter height
2026-02-28 09:13:25.468 DEBUG (MainThread) [shadow_control.wohnen_rechts] width_of_light_strip is 0. No height calculation required. Using default height 100.0%.
2026-02-28 09:13:25.468 DEBUG (MainThread) [shadow_control.wohnen_rechts] Shutter height 100.00% fits stepping or stepping is 0. No adjustment.
2026-02-28 09:13:25.468 DEBUG (MainThread) [shadow_control.wohnen_rechts] Checking if facade is in sun
2026-02-28 09:13:25.468 DEBUG (MainThread) [shadow_control.wohnen_rechts] sun_entry_angle: 110.0, sun_exit_angle: 257.0, sun_exit_angle_calc: 147.0, azimuth_calc: 17.89
2026-02-28 09:13:25.468 DEBUG (MainThread) [shadow_control.wohnen_rechts] Current sun position (a:e): 127.89°:19.02°, facade: 187.0°
2026-02-28 09:13:25.468 DEBUG (MainThread) [shadow_control.wohnen_rechts] Virtual deep and height of the sun against the facade: 0.513391483659243, 0.34471811186378687, effektive Elevation: 33.87949375956154
2026-02-28 09:13:25.468 DEBUG (MainThread) [shadow_control.wohnen_rechts] Finished facade check:
-> Real azimuth 127.89° and facade at 187.0° -> IN sun (from 110.0° to 257.0°)
-> Effective elevation 33.9° for given elevation of 19.0° -> IN min-max-range (20.0°-90.0°)
2026-02-28 09:13:25.468 DEBUG (MainThread) [shadow_control.wohnen_rechts] Starting calculation of shutter angle
2026-02-28 09:13:25.468 DEBUG (MainThread) [shadow_control.wohnen_rechts] Relative azimuth: 59.11°, effective slat width: 41.1 mm (given: 80.0 mm)
2026-02-28 09:13:25.468 WARNING (MainThread) [shadow_control.wohnen_rechts] Argument for asin() out of valid range (-1 <= arg <= 1). Current value: 1.3139040076561765. Unable to compute angle, returning 0.0
2026-02-28 09:13:25.468 INFO (MainThread) [shadow_control.wohnen_rechts] Calculated position (100.0%, 0.0%) differs from forced position (0.0%, 0.0%) -> enforcing position update
2026-02-28 09:13:25.468 DEBUG (MainThread) [shadow_control.wohnen_rechts] Checking if facade is in sun
2026-02-28 09:13:25.469 DEBUG (MainThread) [shadow_control.wohnen_rechts] sun_entry_angle: 110.0, sun_exit_angle: 257.0, sun_exit_angle_calc: 147.0, azimuth_calc: 17.89
2026-02-28 09:13:25.469 DEBUG (MainThread) [shadow_control.wohnen_rechts] Current sun position (a:e): 127.89°:19.02°, facade: 187.0°
2026-02-28 09:13:25.469 DEBUG (MainThread) [shadow_control.wohnen_rechts] Virtual deep and height of the sun against the facade: 0.513391483659243, 0.34471811186378687, effektive Elevation: 33.87949375956154
2026-02-28 09:13:25.469 DEBUG (MainThread) [shadow_control.wohnen_rechts] Finished facade check:
-> Real azimuth 127.89° and facade at 187.0° -> IN sun (from 110.0° to 257.0°)
-> Effective elevation 33.9° for given elevation of 19.0° -> IN min-max-range (20.0°-90.0°)
2026-02-28 09:13:25.469 DEBUG (MainThread) [shadow_control.wohnen_rechts] Current shutter state (before processing): NEUTRAL (0)
2026-02-28 09:13:25.469 DEBUG (MainThread) [shadow_control.wohnen_rechts] Handle NEUTRAL
2026-02-28 09:13:25.469 DEBUG (MainThread) [shadow_control.wohnen_rechts] Checking if facade is in sun
2026-02-28 09:13:25.469 DEBUG (MainThread) [shadow_control.wohnen_rechts] sun_entry_angle: 110.0, sun_exit_angle: 257.0, sun_exit_angle_calc: 147.0, azimuth_calc: 17.89
2026-02-28 09:13:25.469 DEBUG (MainThread) [shadow_control.wohnen_rechts] Current sun position (a:e): 127.89°:19.02°, facade: 187.0°
2026-02-28 09:13:25.469 DEBUG (MainThread) [shadow_control.wohnen_rechts] Virtual deep and height of the sun against the facade: 0.513391483659243, 0.34471811186378687, effektive Elevation: 33.87949375956154
2026-02-28 09:13:25.469 DEBUG (MainThread) [shadow_control.wohnen_rechts] Finished facade check:
-> Real azimuth 127.89° and facade at 187.0° -> IN sun (from 110.0° to 257.0°)
-> Effective elevation 33.9° for given elevation of 19.0° -> IN min-max-range (20.0°-90.0°)
2026-02-28 09:13:25.469 DEBUG (MainThread) [shadow_control.wohnen_rechts] self._check_if_facade_is_in_sun and self._is_shadow_handling_activated
2026-02-28 09:13:25.469 DEBUG (MainThread) [shadow_control.wohnen_rechts] Starting _position_shutter with target height 0.00% and angle 0.00% (is_initial_run: False, lock_state: UNLOCKED)
2026-02-28 09:13:25.469 DEBUG (MainThread) [shadow_control.wohnen_rechts] Canceling timer.
2026-02-28 09:13:25.469 DEBUG (MainThread) [shadow_control.wohnen_rechts] Services availability (cover.js_wohnen_rechts): set_cover_position=True, set_cover_tilt_position=True
2026-02-28 09:13:25.469 DEBUG (MainThread) [shadow_control.wohnen_rechts] Enforcing position update
2026-02-28 09:13:25.469 DEBUG (MainThread) [shadow_control.wohnen_rechts] Setting position to 0.0% (current: 0.0) for entity_id cover.js_wohnen_rechts.
2026-02-28 09:13:25.470 DEBUG (MainThread) [shadow_control.wohnen_rechts] Setting tilt position to 0.0% (current: 0.0) for entity_id cover.js_wohnen_rechts.
2026-02-28 09:13:25.470 DEBUG (MainThread) [shadow_control.wohnen_rechts] Angle of 0.0% equates to 0.0° (min_slat_angle=0.0, angle_offset=0.0)
2026-02-28 09:13:25.470 DEBUG (MainThread) [shadow_control.wohnen_rechts] Positioning tracking updated: 0.0% / 0.0° at 2026-02-28 08:13:25.470269+00:00
2026-02-28 09:13:25.470 DEBUG (MainThread) [shadow_control.wohnen_rechts] _position_shutter finished.
2026-02-28 09:13:25.470 DEBUG (MainThread) [shadow_control.wohnen_rechts] State 0 (NEUTRAL): Moving shutter to neutral position (0.0%, 0.0%).
2026-02-28 09:13:25.470 DEBUG (MainThread) [shadow_control.wohnen_rechts] New shutter state after processing: NEUTRAL (0)

image.png

Ich hoffe das hilft dir weiter.

Alex

[starwarsfan]

Hi

anbei der aktuelle Auszug des Fehlers.

Naja, ein Fehler isses ja grundsätzlich nicht sondern nur eine Warnung, von daher erstmal unkritisch. Die Sinus-Berechnung funktioniert eben im Grenzbereich nicht, das hat nichts mit der Integration zu tun, das war beim Edomi-LBS auch schon so. Aber bevor ich hier etwas sinnvolles in Erfahrung bringen kann, fehlt mir noch immer Deine Konfiguration...

[Triaalex]

Hi



Naja, ein Fehler isses ja grundsätzlich nicht sondern nur eine Warnung, von daher erstmal unkritisch. Die Sinus-Berechnung funktioniert eben im Grenzbereich nicht, das hat nichts mit der Integration zu tun, das war beim Edomi-LBS auch schon so. Aber bevor ich hier etwas sinnvolles in Erfahrung bringen kann, fehlt mir noch immer Deine Konfiguration...

Hi,
sorry. Anbei alle als zip
Im edomi ist das bei mir nicht zum tragen gekommen? Der LBS kippte nie "0".

Also das "Problem" habe ich mal so gelöst, dass ich den min. Winkel auf 65° gesetzt habe.

Weiter ist mir aufgefallen, dass es für den Winkeloffset keine Entität (fest oder variabel) gibt, daher kann man diesen nicht beschreiben. Das wäre aber wichtig, wenn man z.B. ab einer bestimmten Temp. 5° mehr haben möchte.



Alex

[starwarsfan]

Hallo Alex

Anbei alle als zip

Danke für Log und Konfig aber um das jetzt aus X separaten Instanzen auseinanderzupflücken fehlt mir die Zeit. Bitte aktiviere den Debug-Mode für einen Behang und schick mir davon das Log.

[starwarsfan]

Hallo Alex

brauchst du nicht mehr so machen.

Einstellungen => System => Prorokoll oben Rechts das Menü => unveränderte Protokolle anzeigen und dann downloaden , da kannst du auch die Zeilenanzahl angeben oder direkt rauskopieren.

Danke, gerade in die Doku eingearbeitet.

[starwarsfan]

Hallo nochmal

Bitte bei Logs keine Screenshots sondern immer Text posten! Das ist sonst sehr umständlich weil man a) keine Ausschnitte davon für die Fehlersuche verwenden und man b) sich nicht auf Teile davon beziehen kann.

Kannst du mir das erklären?
image.png
image.pngMuss die Elevation zudem nicht immer gleich sein? Welche Formel steckt da dahinter. Denn meine Raffstore sind schon lange im Schatten, ab ca. 11,5° real. Mit Puffer bei mir 10° Wie muss ich die Umrechnung anstellen, dass das passt?

• Die sport-Fassade hat ein Azimut von 119°, die bibliothek-Fassade jedoch 187°.
• Bei der sport-Fassade ist die Sonne aus dem konfigurierten Bereich schon raus, daher gibt es dort keine effektive Elevation für die aktuelle Elevation von 5.4°
• Bei der bibliothek-Fassade scheint die Sonne noch drauf, daher wird hier eine effektive Elevation berechnet und die ist in dem Fall 12.3°. Als min-max ist der Bereich von 10° bis 90° konfiguriert, also ist diese Fassade noch in der Sonne. Siehe auch die Erklärung dazu hier in der Dokumentation.

[starwarsfan]

Hi

Weiter ist mir aufgefallen, dass es für den Winkeloffset keine Entität (fest oder variabel) gibt, daher kann man diesen nicht beschreiben. Das wäre aber wichtig, wenn man z.B. ab einer bestimmten Temp. 5° mehr haben möchte.

Es ist nicht vorgesehen, das dynamisch zu machen, da sich eine Fassadenkonfiguration zur Laufzeit nicht ändert. Dieser Wert ist ein Korrekturfaktor für den Grenzbereich. Wenn Du das dynamisch anpassen willst, dann wäre das via B07 Maximaler Lamellenwinkel sowie dessen Pendant für den Dämmerungsbetrieb zu machen.