Wenn dies dein erster Besuch hier ist, lies bitte zuerst die Hilfe - Häufig gestellte Fragen durch. Du musst dich vermutlich registrieren, bevor du Beiträge verfassen kannst. Klicke oben auf 'Registrieren', um den Registrierungsprozess zu starten. Du kannst auch jetzt schon Beiträge lesen. Suche dir einfach das Forum aus, das dich am meisten interessiert.
Mit dem B07 wird das nicht funktionieren. Denn ich möchte ja bei einer bestimmten Temp. den Winkel erhöhen (25° + 5 ° / 37° + 10°) und ab einer bestimmten Temp 30°
komplett schliessen (dies ist ja auch einfach machbar). So habe ich das bei Edomi gemacht, hat super funktioniert und war top.
Das verstehe ich nicht. Wieso sollte das mit B07 nicht funktionieren? Ich modifiziere meinen Behang bspw. je nach Öffnungstatus der Fenster, das funktioniert problemlos. Kannst Du bitte genauer erklären, was Du da machst und insbesondere was damit nicht gehen würde?
2026-03-01 09:56:02.265 DEBUG (MainThread) [shadow_control.aufenthalt_sud] Starting calculation of shutter angle
2026-03-01 09:56:02.265 DEBUG (MainThread) [shadow_control.aufenthalt_sud] Relative azimuth: 49.68000000000001°, effective slat width: 51.8 mm (given: 80.0 mm)
2026-03-01 09:56:02.265 WARNING (MainThread) [shadow_control.aufenthalt_sud] Argument for asin() out of valid range (-1 <= arg <= 1). Current value: 1.0603131550120828. Unable to compute angle, returning 0.0
2026-03-01 09:56:02.265 INFO (MainThread) [shadow_control.aufenthalt_sud] Calculated position (100.0%, 0.0%) differs from forced position (0.0%, 0.0%) -> enforcing position update
Die Frage ist jedoch, wie sich das genau bei Edomi verhalten hat!? Also was genau hat Edomi dann bei Dir eingestellt? Waren die Lamellen dann waagerecht?
Die Lamellenwinkelberechnung unter Edomi war insofern falsch, als dass sie die Lamellenbreite nicht korrekt behandelt resp. analog der Elevation angepasst hat. Das ist jetzt bei der HA-Portierung korrigiert. Aber das führt nun dazu, dass dabei rechnerisch unmögliche Lamellenbreiten heraus kommen, was entsprechend abgefangen wird.
Triaalex: Ich hab' mal etwas experimentelles eingebaut und damit die Version 0.11.1-RC1 freigegeben. Konkret wird nun im Grenzbereich die Azimut-Korrektur der Lamellen deaktiviert. Bitte lass' mich wissen, wie sich das damit bei Dir verhält. Insbesondere ist interessant, ob und wann Du Durchschein-Effekte feststellst.
Die entsprechende Meldung ist noch immer eine Warnung im Log, was ich jedoch später auf Info oder sogar Debug ändern würde denn das ist kein Problemfall sondern normales Verhalten im Bereich der Offset-Grenzen der Beschattung.
Diese optionale Zeitbeschränkung verhindert, dass der Behang vor der angegebenen Uhrzeit am Morgen öffnet, selbst wenn der Helligkeitsschwellwert überschritten wird. Dies ist nützlich, um zu frühes Öffnen im Sommer zu verhindern, wenn es sehr früh hell wird.
Logik: Der Behang öffnet nur, wenn beide Bedingungen erfüllt sind:
Wochentage: Auf 06:00 setzen, um Öffnen vor 6 Uhr morgens an Arbeitstagen zu verhindern
Wochenende: Eine Entität (input_datetime) verwenden, die via Automation automatisch angepasst wird (z.B. 06:00 Mo-Fr, 08:00 Sa-So)
Sommer-Szenario: Im Sommer wird der Helligkeitsschwellwert bereits um 5 Uhr erreicht, aber der Behang soll erst um 6 Uhr öffnen
Konfiguration:
Entitäts-Variante: Referenziert eine input_datetime-Entität, die die Uhrzeit liefert. Dies ermöglicht dynamische Anpassung (z.B. via Automationen für Wochentag/Wochenende-Unterschiede)
Manuelle Variante: Feste Uhrzeit im Format HH:MM eingeben (z.B. 06:00 für 6 Uhr morgens)
Standardwert: None (Feature deaktiviert - nur Helligkeitsschwellwert gilt)
Format: HH:MM (24-Stunden-Format, z.B. 06:00, 08:30, 23:45)
Diese optionale Zeitbeschränkung stellt sicher, dass der Behang zur angegebenen Uhrzeit am Abend schließt, unabhängig von der Helligkeit. Dies garantiert Privatsphäre oder Sicherheit auch wenn es draußen noch hell ist (z.B. im Sommer).
Logik: Der Behang schließt, wenn eine der Bedingungen erfüllt ist:
Privatsphäre: Behang um 20 Uhr schließen, auch an hellen Sommerabenden
Sicherheit: Sicherstellen, dass Behänge zu einer bestimmten Zeit geschlossen sind, z.B. im Urlaub
Winter-Szenario: Im Winter wird es gegen 17 Uhr dunkel, der Behang schließt früh aufgrund der Helligkeit. Die Zeitbeschränkung hat keine Wirkung.
Sommer-Szenario: Im Sommer ist es um 20 Uhr noch hell, aber die Zeitbeschränkung löst trotzdem das Schließen aus.
Konfiguration:
Entitäts-Variante: Referenziert eine input_datetime-Entität, die die Uhrzeit liefert. Dies ermöglicht dynamische Anpassung (z.B. unterschiedliche Zeiten für verschiedene Jahreszeiten)
Manuelle Variante: Feste Uhrzeit im Format HH:MM eingeben (z.B. 20:00 für 20 Uhr)
Standardwert: None (Feature deaktiviert - nur Helligkeitsschwellwert gilt)
Format: HH:MM (24-Stunden-Format, z.B. 20:00, 21:30, 22:00)
Das verstehe ich nicht. Wieso sollte das mit B07 nicht funktionieren? Ich modifiziere meinen Behang bspw. je nach Öffnungstatus der Fenster, das funktioniert problemlos. Kannst Du bitte genauer erklären, was Du da machst und insbesondere was damit nicht gehen würde?
Guten Morgen,
ich beantworte dir alle Frage in diesem Post.
zunächst modifiziere ich die Behänge mit Hilfe der Sperre mit Zwangsposition. Daher auch meine Frage zum Zurücksetzten "Aller" Sperren.
Der B07 ist doch der Maximale Lamellenwinkel. Bedeutet dieser beschränkt meinen errechneten Winkel. Dies bewirkt genau das Gegenteil von dem, was ich erreichen möchte, wenn dann müsste ich den Minimalen Lamellenwinkel beschreiben, geht aber auch nicht. Denn ich möchte den Winkel ja erhöhen +xx° oder %, da ich mehr schliessen möchte. Das habe ich bis dato immer mit dem Offset gemacht. Funktionierte tadellos. Bei Edomi konntest du ja auf alle "Vorgeben" direkt eine Verknüpfung legen.
Zur Frage, wie sich Edomi verhalten hat, kann ich dir den Winkel nicht mehr sagen, da Edomi nicht mehr läuft. Ich bin der Meinung es war etwa 65% od. 70%, ich denke es war nicht der Durchsichtswinkel, denn der war bei mir 50%. Kann ich aber nicht wirklich beantworten. Das wäre aber auch meine Herangehensweise gewesen, wenn "nicht berechenbar" dann minimaler Lamellenwinkel. So mache ich das jetzt gerade, funktioniert aber nicht immer? Gestern hatte ich da auch wieder die eine oder andere "0" in der Ausführung. Und gerade bei "wenig" Sonnenlicht, da kommt diese "Nichtberechnung" ja vor, ist es unangenehm im Dunkeln zu sitzen. Ich verstehe zwar die "Berechnung" immer noch nicht, denn eigentlich kann dies ja nicht sein. Ich versteh das so, dass du den Winkel der Sonne zur Lamelle berechnest und dann die Lamelle xx° zur Sonne ausrichtest. Das ganze unter Berücksichtigung der Abstünde Lamellen zueinander. Dies bedeutet aber, dass eigentlich eine 0 oder 100 nie vorkommen dürfte, denn das wäre ja waagerecht zur Erdoberfläche? Daher müsste immer eine gewisse Öffnung vorhanden sein.
Danke für die schnelle Reaktion mit dem RC1. Werde ich testen. Kann ich aber erst im Laufe der Woche berichten, denn ich bin aktuell nicht zu Hause. Mal sehen wie ich das schnellstmöglich umsetzen kann. Vielleicht mach ich das mit den Innenkameras. Nur eine Frage, wenn ich das RC1 jetzt einspiele, Bst neu laden mit dem Release, habe ich dann beim nächsten "offiziellen" Release wieder die Vorgehensweise dass ich das dann via Yaml neu einlesen muss. Oder funktioniert das Update dann "normal"? Dann muss ich den min. Lamellenwinkel ausschalten, sonst funktioniert deine experimentelle Logik nicht, oder?
Zu den neuen Optionen. Coole Sache, habe ich bis dato alles via Automationen mit Logik umgesetzt. Daher waren für mich diese beiden Sperren auch so wichtig, denn darüber habe ich das ganze gelöst. Ging ja noch viel weiter, denn ich hatte hier Jahreszeiten, Ferien, Feiertage, Wochenende, Gaststeuerung, Abwesenheit und den Familienkalender mit einbezogen. Ist das in der RC1 auch schon drin, dann sehe ich mir das auch mal an.
die Berechnung scheint jetzt auch morgens zu klappen. Tatsächlich trat auch der alte Fehler nur bei niedrigem Sonnenstand auf. Aktuell läuft es wieder wie bei Edomi
Wir verarbeiten personenbezogene Daten über die Nutzer unserer Website mithilfe von Cookies und anderen Technologien, um unsere Dienste bereitzustellen. Weitere Informationen findest Du in unserer Datenschutzerklärung.
Indem Du unten auf "ICH stimme zu" klickst, stimmst Du unserer Datenschutzerklärung und unseren persönlichen Datenverarbeitungs- und Cookie-Praktiken zu, wie darin beschrieben. Du erkennst außerdem an, dass dieses Forum möglicherweise außerhalb Deines Landes gehostet wird und bist damit einverstanden, dass Deine Daten in dem Land, in dem dieses Forum gehostet wird, gesammelt, gespeichert und verarbeitet werden.
Kommentar