[73_AutoShuttersControl.pm] - aktuelle Entwicklerversionen zum testen

[Vorhand]

Meine leider nicht. Ich vermute, dass es an der bzw. den Messungen liegt. Man müsste wissen, was da an Helligkeit und Temperatur ankommt.
Gibt es noch ein attr, welches die Beschattung separat aktiviert?

[CoolTux]

Dann schalte mal verbinde 4 beim ASC an

[Vorhand]

Du meintest verbose auf 4?
Beschattung hat jetzt funktioniert. Nachdem ich bei ASC_BrightnessSensor
TSL2561:luminosity -1:-1 eingetragen habe, gingen jeweils nach ca. 20 s die Läden herunter.
Ich hatte vorher die div. Lichtsensoren in eine readingsGroup eingetragen und da wurde der Teil
luminosity -1:-1 nicht übernommen - also bei jedem Laden zu Fuß.
Jetzt stehen alle bei 80.
Cloudy und Sunny hatte ich ebenfalls in der readingsGroup Beschattung ergänzt. Mit einem Wert oberhalb der aktuellen Lichtstärke bei Cloudy wollte ich erreichen, dass die Läden wieder hochfahren.
Im ASC wurde dann auch Shading out angezeigt, aber gefahren ist keiner!?

[CoolTux]

Hallo. Super das schon mal etwas ging.
Ich hatte heute auch eine seltsame Beobachtung. Die Rollläden sind in die Beschattung gefahren, danach habe ich FHEM neu gestartet dann sind die Rolläden aus der Beschattung gefahren was korrekt war aber danach sind sie leider rein gar nicht mehr rein gefahren.

[CoolTux]

Du meintest verbose auf 4?
Beschattung hat jetzt funktioniert. Nachdem ich bei ASC_BrightnessSensor
TSL2561:luminosity -1:-1 eingetragen habe, gingen jeweils nach ca. 20 s die Läden herunter.
Ich hatte vorher die div. Lichtsensoren in eine readingsGroup eingetragen und da wurde der Teil
luminosity -1:-1 nicht übernommen - also bei jedem Laden zu Fuß.
Jetzt stehen alle bei 80.
Cloudy und Sunny hatte ich ebenfalls in der readingsGroup Beschattung ergänzt. Mit einem Wert oberhalb der aktuellen Lichtstärke bei Cloudy wollte ich erreichen, dass die Läden wieder hochfahren.
Im ASC wurde dann auch Shading out angezeigt, aber gefahren ist keiner!?

Ja verbose 4. Ich muss schauen was passiert wenn man für Morgens und Abends mit Brightness fahren will und dem entsprechend ASC_BrightnessSensor setzt. Eigentlich sollte dann dennoch die Beschattungsfunktion aufgerufen werden.

[Beta-User]

Ich hatte zwar gestern nur einen oberflächlichen Blick drüber geworfen, bin aber der Meinung: ja!

Huete morgen stehen die Timer bereits vor dem morgendlichen Fahren wieder auf morgen. Da am Fr. (1. Tag uptime) - jedenfalls nach meiner Erinnerung - korrekt gefahren wurde, liegt das entweder an $we oder an dem Umstand, dass es nicht die erstmalige Timerberechnung nach dem Start war, sondern eine spätere...

Auszug aus dem list (ist eine zu lang laufende Jalousie):

Code Auswählen Erweitern

READINGS:
2019-03-30 19:22:12   ASC_ShuttersLastDrive manual
     2019-03-30 19:20:57   ASC_Time_DriveDown 31.03.2019 - 20:22
     2019-03-30 19:20:57   ASC_Time_DriveUp  1.04.2019 - 09:30

[CoolTux]

Dann muss ich mir das heute Abend mal anschauen. Ich gehe auch gleich noch mal den Code durch.

[CoolTux]

Ich denke ich habe das Problem mit den falschen Sunrise Zeiten gefunden.

[Vorhand]

Nach wie vor geht nicht das Entschatten.
Grenzwert Sunny wurde so eingestellt, dass er vom Wert der Brightnessmessung überschritten wurde. Kurz darauf gingen die Läden runter in die ShdPos.
Jetzt habe ich durch Verdunkelung den Messwert reduziert, so dass er den eingestellten Cloudy Wert unterschritt. Eigentlich sollten die Läden nach der Wartezeit wieder hochfahren. Tun sie leider nicht.
Beobachtung: das ASC Icon zeigt nach wie vor die Sonne mit dem Wert Shading in an. Wenn man get ASControlDG showShuttersinformation aufruft, erscheint bei allen Läden ShadingInfo out mit der aktuellen Uhrzeit.
Wenn ich dann einen renew der Zeiten veranlasse verschwindet das Sonnen Icon, aber die Läden gehen trotzdem nicht hoch.

[CoolTux]

Nach wie vor geht nicht das Entschatten.
Grenzwert Sunny wurde so eingestellt, dass er vom Wert der Brightnessmessung überschritten wurde. Kurz darauf gingen die Läden runter in die ShdPos.
Jetzt habe ich durch Verdunkelung den Messwert reduziert, so dass er den eingestellten Cloudy Wert unterschritt. Eigentlich sollten die Läden nach der Wartezeit wieder hochfahren. Tun sie leider nicht.
Beobachtung: das ASC Icon zeigt nach wie vor die Sonne mit dem Wert Shading in an. Wenn man get ASControlDG showShuttersinformation aufruft, erscheint bei allen Läden ShadingInfo out mit der aktuellen Uhrzeit.
Wenn ich dann einen renew der Zeiten veranlasse verschwindet das Sonnen Icon, aber die Läden gehen trotzdem nicht hoch.

Ich bin gerade dabei mir den Code von diversen Funktionen noch einmal an zu schauen. Ich schaue mir das Beschatten auch gleich noch mal an.
Danke für die Info

[CoolTux]

Ich denke ich habe einen Logikfehler in der Beschattung gefunden. Meine Tests heute verliefen sehr gut. Ich werde heute Abend und Morgen früh noch mal was schauen und dann gebe ich die nächste Entwicklerversion morgen früh zum testen frei.

[CoolTux]

Bezüglich Beschattung habe ich eben noch eine Beobachtung gemacht. Bisher dachte ich immer das der Brightnesswert sich immer ändert, war meine Beobachtung immer so.
Heute war er nun 2 mal der selbe hintereinander und mein event-on-change-reading hat das Beschatten verzögert weil kein Event geworfen wurde. Daher habe ich das auf event-on-update-reading gesetzt.

[Beta-User]

Ich denke ich habe das Problem mit den falschen Sunrise Zeiten gefunden.

Für den Fall, dass es noch relevant ist: heute morgen sind die Rollläden zur richtigen Zeit tatsächlich auch gefahren. Scheint also was mit dem $we zu tun zu haben.

[CoolTux]

So es liegt eine neue Developer Version vor.
Ich habe so einiges umgeschrieben. Wie erwähnt hat sich zum Beispiel das Verhalten für das verzögerte fahren geändert.

In der kommenden Version wird die Konfiglogik für das Zeitversetzte fahren geändert. Wer ein tatsächliches zeitversetztes fahren will mit festen Werten lässt in den Rollläden das Attribut
ASC_Drive_Offset auf -1
Setzt
ASC_Drive_OffsetStart auf den Wert der verzögert gefahren werden soll
und im ASC Device selbst kann ASC_shuttersDriveOffset komplett entfernt werden.
Somit fährt der Rollladen dann genau versetzt um die eingestellte Zeit in Sekunden.

Desweiteren konnte ich einige Fehler bereinigen und habe angefangen ausführliche Debugmeldungen ein zu arbeiten. Dazu muß das ASC Attribut debug auf 1 stehen.
Ist der Rollladen als Terrassenrollladen markiert und der Fenster/Tür Status ist offen wird egal wie was eingestellt ist gar nicht mehr gefahren.



Zu guter letzt das Thema Attribute. Ich werde mich die Woche noch mal ran setzen und versuchen das ASC ohne die Attributsverteilung zu installieren. Bzw werde ich die Attribute vergeben welche die Auswahl zwischen 1 und 2 beachten. Die anderen nicht. Sollte das seltsamer  Weise doch gehen werde ich die AttrVal Objekte entsprechend mit defaults belegen.
Abe rdas kommt wenn in eine spätere Version. Ich will die jetzt aktuelle Developer dann erstmal als stabil markieren und verteilen.


Grüße

[Beta-User]

Moin.

VERSION 0.4.0.11beta53 läuft seit eben, naturgemäß kann ich noch nicht viel mehr sagen, wie dass sich die laden läßt .

Gibt es irgendwas, auf das man besonders achten sollte (und sei es "nur" die Überprüfung irgendwelcher Umstellroutinen)?