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.
Aber das ganze Auto-Lock-Handling hat's heftigst in sich! Ich habe heute schon wieder recht umfangreiche interne Umbauten gemacht, um das Locking in Griff zu bekommen. Ich bin mir nicht sicher, ob sich das überhaupt zu 100% sauber lösen lässt oder ob es dabei nicht immer einen gewissen Graubereich gibt.
Wie auch immer, ich will versuchen, den nächsten RC zeitnah freizugeben und bitte um ausgiebige Tests. Details dann im entsprechenden Posting dazu.
Die Spannung steigt gerade. Daumen drücken, dass es sich jetzt wie gewünscht verhält...
Hier mal etwas Prosa, wie das jetzt funktoniert.
Via facade_max_movement_duration_static wird konfiguriert, wie lange das Verfahren des Behangs maximal dauert
Started eine SC-Instanz eine Positionierung, wird gleichzeitig ein Timer mit der Laufzeit aus facade_max_movement_duration_static gestartet
Kommen während der Laufzeit des Timers Positionsmeldungen des Behangs an der SC-Instanz an, werden diese "gemerkt" aber es erfolgt keine weitere Aktion
Ist der Timer abgelaufen, wird die letzte eingegangene Position mit der berechneten Position vergleichen
Sind die beiden Werte gleich: Alles gut, keine Sperre
Unterscheiden sich die Werte: SC-Instanz sperrt sich
Damit wird der Fall abgedeckt, dass SC den Behang bspw. schliessen will und jemand stoppt diese Bewegung manuell.
Aber es geht natürlich noch weiter:
Es geht eine Positionsmeldung an der SC-Instanz ein
Die Instanz prüft, ob der obige Timer läuft.
Ja, Timer läuft:
Position merken und keine weitere Aktion
Nein, Timer läuft nicht:
eingegangene Position mit der zuletzt berechneten Position vergleichen
Sind die beiden Werte gleich: Alles gut, keine Sperre
Unterscheiden sich die Werte: SC-Instanz sperrt sich
Der zweite Teil hier entspricht dem zweiten Teil von Variante 1 oben. Wichtig ist, dass die konfigurierte Fahrzeit auf jeden Fall die tatsächliche Fahrzeit abgedeckt. Damit erfolgt die Sperre der Instanz bei händischer Modifikation entweder sofort mit der Rückmeldung des Aktors (wenn der Timer gerade nicht läuft) oder spätestens nach dem Ablauf des Timers.
IMHO sollten sich damit alle Varianten abbilden lassen oder? Was meint ihr? Habe ich etwas übersehen?
Zuletzt geändert von starwarsfan; 02.01.2026, 16:48.
Ich hätte aber einen kleinen Verbesserungswunsch ggf. hast du das aber schon integriert... Wenn ein sperren durch einen manuellen Eingriff geschieht wäre es dann möglich einen sperrstatus von z.B 3 einzuführen so würde man auf Anhieb erkennen warum die Integration gesperrt ist und man könnte auch mit einer Automation darauf reagieren z.B manuelle aktionen nach 60 Minuten automatisch entspannen
Hallo Yves, es scheinen alle manuellen Fälle abgedeckt.
Das Entsperren muss dann über eine eigene Automation laufen.
Im einfachsten Fall 1x pro Tag, aber wann? Es wird dann ja sofort positioniert.
Für (m)einen Fall sehe ich noch keine Verbesserung:
Im Badezimmer sperre ich die Rollos, solange das Licht an ist.
Damit wird verhindert, dass morgens die Rollos öffnen während jemand duscht.
Abends macht das beim Lüften Probleme:
1. Rollos auf
2. Licht aus
3. Rollos fahren zu, da beim Ausschalten des Lichts die Sperre aufgehoben und dadurch die Position neu berechnet wird.
Wie kann ich die Automatik sperren, ohne beim aufheben eine Neupositionierung auszulösen?
Es soll im Prinzip erst bei der nächsten Situationsveränderung eine Positionierung erfolgen (ala EDOMI SBC).
vielleicht würde der meine Automation an dieser Stelle weiterhelfen:
Beim Öffnen des fensters, werde ich die Integration mit zwangsposition auf komplett auf. dadurch werde ich Jalousie auf und Die Integration sperrt sich mit Sperrcode 2 Wenn ich Das Fenster schließe, hebe ich die zwangssperre auf gehe also auf Sperrcode 0 und überlasse Der Integration das Fahren an die passende Stelle. Also nachts wieder komplett zu. das klappte der mit der 0.10 perfekt
Damit wird in diesem Beispiel der Max-Winkel für die Dämmerung auf 80% geändert, wenn das Fenster geöffnet oder gekippt wird. Mit dieser Variante komme ich völlig ohne Sperren aus.
Davon gibt's natürlich noch andere Ausprägungen aber die Idee sollte klar sein.
Das Entsperren muss dann über eine eigene Automation laufen.
Im einfachsten Fall 1x pro Tag, aber wann? Es wird dann ja sofort positioniert.
Dass dann direkt positioniert wird, ist im Moment eine offene Frage. Ich habe so viel umgebaut in den letzten Tagen, das muss ich erst nochmal am lebenden Objekt prüfen. Ich habe den aktuellen Code seit heute Nachmittag bei mir im Haus installiert und bis jetzt hat das wie gewünscht funktioniert. Morgen früh wenn's hell wird, wird sich zeigen, ob das nun auch in die andere Richtung sauber läuft.
Was mich an der Stelle aber schonmal sehr freut ist, dass es nun auch endlich mit den automatisierten Tests voran geht. Ich konnte heute schonmal sämtliche Entity-Klassen auf eine Coverage von über 80% bringen. Wen's interessiert, Details siehe hier.
Stay tuned!
Zuletzt geändert von starwarsfan; 02.01.2026, 22:25.
starwarsfan, ich wollte man anfragen, wie sich die Automation heute morgen geschlagen hat?
Einen Verbesserungswunsch hätte ich trotzdem nochmal.. (hatte ich schon mal vor langer Zeit eingebracht).
Wie kann ich aus dem Dashboard heraus die Integration sicher "ausschalten". Aktuell mach ich das bei den Geräten, dies kann ich aber ja nicht auf das Dashboard legen. Alternativ habe ich die Erweiterung spook schon eingerichtet, damit kann man Devices deaktivieren und das dann auch vom Dashboard aus. Nur nach dem Aktivieren, muss ich HA Neustarteten damit die SC Intgration wieder verfügbar ist. Oder gibts eine einfachere Alternative?
Einen Verbesserungswunsch hätte ich trotzdem nochmal.. (hatte ich schon mal vor langer Zeit eingebracht).
Wie kann ich aus dem Dashboard heraus die Integration sicher "ausschalten".
Wie damals schon geschrieben, gibt es jeweils separate Switches, um die Beschattungs- bzw. die Dämmerungssteuerung zu deaktivieren.
Soeben habe ich den RC12 freigegeben. Bei mir funktioniert jetzt das automatische Sperren, soweit wie ich es bis jetzt testen konnte. Das direkte Positionieren nach dem Entsperren konnte ich auch nicht mehr beobachten.
Was mir ziemlich Kopfzerbrechen bereitet hat und schlussendlich gar nichts mit der Integration zu tun hatte: Unbedingt darauf achten, dass die KNX-Konfiguration der Covers richtig ist! Das bezieht sich das insbesondere auf die Settings travelling_time_down und travelling_time_up. Diese Werte dürfen auf keinen Fall grösser sein, als das was unter max_movement_duration konfiguriert wurde, anderenfalls wird sich die Integration immer selbst sperren.
Der Vollständigkeit halber hier die Releasenotes der bis dato eingebauten Changes:
Breaking change:
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!
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 additional entity enforce_positioning_manual with push button functionality to trigger recalculation and positioning of the shutter.
Fix usage of default values if configuring a new instance via HA UI ConfigFlow.
Use HA internal slugify functionality to sanitize instance names
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
Implement automatic instance lock in case shutters are modified manually
New config option max_movement_duration to define duration from full closed to full open
Zuletzt geändert von starwarsfan; 03.01.2026, 16:46.
Chaos...
nach einem HA Neustart fuhren die nicht gesperrten Rollos, trotz Dunkelheit nach oben. Beim Versuch die Rollos wieder zu schließen fuhren sie nach erreichen der unteren Endposition erneut nach oben. Danach haben sich die Automatiken wegen veränderter Position selbst gesperrt.
Ich muss jetzt mit den Tests aufhören, das gibt Stress.
Offtopic, wie ich das vermisse, da hatte ich Jahre lang Ruhe und volle Kontrolle:
Das war jeweils meine EDOMI Rollo-Automatisierung:
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