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