[73_AutoShuttersControl.pm] Rolllos automatisiert steuern - Version 0.10

[Reinhard.M]

Ich dachte, dass war Absicht von dir. Mit dem Punkt wird es Floating und sollte wiederum einen numerischen Vergleich erlauben, oder?

[Beta-User]

Schon. Aber ASC würde dann uU nicht mehr fahren, weil 3.66 die Zielposition wäre, das Reading aber 3 meldet => es wird als manuelle Zwischendurch-Fahrt bewertet...

[Reinhard.M]

Wäre für mich jetzt kein Thema da alle Positionen unterschiedliche pct Werte haben. Aber die Bewertung durch das ASC ist für mich ein Thema, ich versuche es weiterhin zu verstehen... 

[Beta-User]

Afaik geht ASC davon aus, dass der Aktor immer GENAU das macht, was die Fahranweisung seitens ASC ist. Haut das aus irgendwelchen Gründen nicht hin, unterstellt ASC, dass jemand nach der letzten Fahranweisung manuell eingegriffen hat, was dann (für eine gewisse Zeit) Vorrang hat. Und 3.66 ist halt nicht genau 3.

[Reinhard.M]

Afaik geht ASC davon aus, dass der Aktor immer GENAU das macht, was die Fahranweisung seitens ASC ist. Haut das aus irgendwelchen Gründen nicht hin, unterstellt ASC, dass jemand nach der letzten Fahranweisung manuell eingegriffen hat, was dann (für eine gewisse Zeit) Vorrang hat. Und 3.66 ist halt nicht genau 3.

Bitte nicht falsch verstehen, ich möchte weder "Besserwissen" noch eine langatmige Diskussion lostreten. Ich bin absoluter Perl Anfänger und möchte schlicht lernen und verstehen.
Soweit ich es verstehe ist Perl sehr schwach typisiert und es gibt bei einem numerischen Vergleich keine Unterscheidung zwischen Integer und Floating Point. Wenn ich also "2.4 > 2" vergleiche wird es auch als numerischer Vergleich ausgeführt und richtig bewertet. Wenn ich aber "2,4 > 2" vergleiche, wird es von Perl als String betrachtet und eine Warning ausgegeben. Den Floating Point Ansatz hatte ich auch schon einmal früher verwendet um zwei Positions Attributen quasi den gleichen Wert zuzuweisen ohne das ASC deswegen nicht fährt. Damals hatte ich 0 und 0.0001 für die Open und ComfortOpen Position verwendet. Auf Grund deines Posts habe ich gerade an einem Dummy die Floating Point Annahme nochmals verifiziert und mit ASC funktioniert auch ein Unterschied in der Nachkommastelle. Insofern also eher ein Vorteil mit Floating Point zu arbeiten.
Was ich aber bislang einfach nicht auf die Reihe kriege ist, wann ASC eine Fahrt unterbindet und wann nicht. Ich beobachte es immer wieder, dass eine Fahrt ausgelöst wir obwohl es nicht sollte und umgekehrt. Und alles bislang nicht deterministisch. Oder ich habe noch nicht alle Parameter dafür im Auge. Da bei mir die anscheinend absolut gleiche Fahrt mal ausgelöst wird und mal nicht, kann ich auch keine Fehlerbeschreibung liefern. Zumindest noch nicht.

Gruß Reinhard

P.S.: Bei Interesse können wir gerne OT weiterdiskutieren, ich möchte diese Thread nicht noch länger werden lassen

[Borkk]

Hi zusammen,

ich doktore gerade an der Installtion eines Freundes rum, bei ihm fahren einzelne Rollos einfach nicht in die "ComfortOpen" oder "Ventilate" Stellung. Und das obwohl sie exakt genauso konfiguriert sind wie andere Rollos bei denen es funktioniert. Auch die Fensterkontakte (HM-IP - threestate) sind gleich konfiguriert und arbeiten einwandfrei.

Um der Sache auf den Grund zu gehen, wollte ich mir erst mal den Debug anschauen. Da wir aber beide auf DBLog umgestellt haben, stehe ich gerade ein wenig auf dem Schlauch wie ich jetzt an die Debug Ausgabe gelange. Ich habe den Post hier mal verlinkt, falls aus diesem Kreis jemand eine Idee hat. 

https://forum.fhem.de/index.php/topic,123077.0.html


   

[teufelchen]

Hallo,

langsam wird es wieder später hell.

Kann man das teilweise öffnen der Rollos als feste Uhrzeit definieren?
Also den Wert für ASC_PrivacyUpValue_beforeDayOpen nicht in Sekunden vor Öffnung sondern fest um z. B. 6:15 Uhr einstellen?

Code Auswählen Erweitern

ASC_PrivacyUpValue_beforeDayOpen - wie viele Sekunden vor dem morgendlichen öffnen soll der Rollladen in die Sichtschutzposition fahren, oder bei Brightness ab welchem minimum Brightnesswert soll das Rollo in die Privacy Position fahren. Bei Brightness muss zusätzlich zum Zeitwert der Brightnesswert mit angegeben werden 1800:600 bedeutet 30 min vor day open oder bei über einem Brightnesswert von 600 (default: -1)
ASC_PrivacyDownValue_beforeNightClose - wie viele Sekunden vor dem abendlichen schließen soll der Rollladen in die Sichtschutzposition fahren, oder bei Brightness ab welchem minimum Brightnesswert soll das Rollo in die Privacy Position fahren. Bei Brightness muss zusätzlich zum Zeitwert der Brightnesswert mit angegeben werden 1800:300 bedeutet 30 min vor night close oder bei unter einem Brightnesswert von 300 (default: -1)
ASC_PrivacyUp_Pos - Position den Rollladens für den morgendlichen Sichtschutz (default: 50) !!!Verwendung von Perlcode ist möglich, dieser muss in {} eingeschlossen sein. Rückgabewert muss eine positive Zahl/Dezimalzahl sein!!!
ASC_PrivacyDown_Pos - Position den Rollladens für den abendlichen Sichtschutz (default: 50) !!!Verwendung von Perlcode ist möglich, dieser muss in {} eingeschlossen sein. Rückgabewert muss eine positive Zahl/Dezimalzahl sein!!!

[Reinhard.M]

Hallo CoolTux,
ich hoffe du kannst mir helfen, ich komme gerade nicht mehr weiter.
Vorgeschichte: HmIP Jalousie Steuerung die ich aktuell mit festen Zuordnungen über ASC ansteuere. Völlig unabhängig vom aktuellen Stand der Jalousie funktioniert die ASC Fahrt oder auch nicht.  Alle Attribute mit Positionsangaben sind unterschiedlich, es ist Tag, Shading Mode ist explizit aus (Shading Werte sind aber gesetzt).
Die Jalousie ist offen (oben), pct steht auf 100. Das Reading "ASC_Time_DriveDown" zeigt für den heutigen Tag 11:31 an, das wurde korrekt von ASC aus dem Attribut übernommen:

Code Auswählen Erweitern

2021.09.25 11:30:43.656 4: AutoShuttersControl (myASControl) - Devname: global Name: myASControl Notify: $VAR1 = [
          'ATTR HM_JAU_Jalousie ASC_Time_Down_Early 11:31'
        ];
2021.09.25 11:30:43.683 4: AutoShuttersControl (myASControl) - Devname: myASControl Name: myASControl Notify: $VAR1 = [
          'HM_JAU_Jalousie_nextAstroTimeEvent: 25.09.2021 - 11:31'
        ];
ASC_DEBUG!!! 2021.09.25 11:30:47 - FnIsDay: HM_JAU_Jalousie Allgemein: 1

Ganz nebenbei, obwohl Shading abgeschaltet ist, verbringt ASC allem Anschein nach die meiste Zeit damit die Shading Conditions für die Jalousie zu prüfen. Keine Ahnung ob das die Performance beeinflusst, ich sehe im Log aber fast nichts anderes.
Wenn ich jetzt die Zeit 11:31 erreicht habe passiert einfach nichts! Es gibt keine Überprüfung der Behanghöhe, kein Vergleich mit irgendetwas, einfach nichts. Das einzige was ASC macht ist folgendes:

Code Auswählen Erweitern

2021.09.25 11:31:01.050 4: AutoShuttersControl (myASControl) - Devname: myASControl Name: myASControl Notify: $VAR1 = [
          'HM_JAU_Jalousie_nextAstroTimeEvent: 26.09.2021 - 07:30'
        ];

Es wird der nächste Event eingestellt, der vorherige wird aber nicht (sichtbar) bearbeitet. Wie du in den Code Zeilen sehen kannst ist Debug aktiv und verbose = 5, irgendetwas sollte ich doch sehen, oder? Zumindest sehe ich bei anderen ASC Fahrten der Jalousie etwas, egal ob die Fahrt tatsächlich ausgelöst wird oder nicht.
Ich hoffe du findest Zeit mal darauf zu schauen, das Debugging hilft mir aktuell jedenfalls keinen Millimeter weiter.

Gruß Reinhard

[ch.eick]

Hallo,

langsam wird es wieder später hell.

Kann man das teilweise öffnen der Rollos als feste Uhrzeit definieren?
Also den Wert für ASC_PrivacyUpValue_beforeDayOpen nicht in Sekunden vor Öffnung sondern fest um z. B. 6:15 Uhr einstellen?

Code Auswählen Erweitern

ASC_PrivacyUpValue_beforeDayOpen - wie viele Sekunden vor dem morgendlichen öffnen soll der Rollladen in die Sichtschutzposition fahren, oder bei Brightness ab welchem minimum Brightnesswert soll das Rollo in die Privacy Position fahren. Bei Brightness muss zusätzlich zum Zeitwert der Brightnesswert mit angegeben werden 1800:600 bedeutet 30 min vor day open oder bei über einem Brightnesswert von 600 (default: -1)
ASC_PrivacyDownValue_beforeNightClose - wie viele Sekunden vor dem abendlichen schließen soll der Rollladen in die Sichtschutzposition fahren, oder bei Brightness ab welchem minimum Brightnesswert soll das Rollo in die Privacy Position fahren. Bei Brightness muss zusätzlich zum Zeitwert der Brightnesswert mit angegeben werden 1800:300 bedeutet 30 min vor night close oder bei unter einem Brightnesswert von 300 (default: -1)
ASC_PrivacyUp_Pos - Position den Rollladens für den morgendlichen Sichtschutz (default: 50) !!!Verwendung von Perlcode ist möglich, dieser muss in {} eingeschlossen sein. Rückgabewert muss eine positive Zahl/Dezimalzahl sein!!!
ASC_PrivacyDown_Pos - Position den Rollladens für den abendlichen Sichtschutz (default: 50) !!!Verwendung von Perlcode ist möglich, dieser muss in {} eingeschlossen sein. Rückgabewert muss eine positive Zahl/Dezimalzahl sein!!!

Im schlimmsten Fall verwendest Du Perl und berechnest die Differenz in Sekunden zu Deiner gewünschten Zeit und die Sekunden trägst Du dann als Rückgabe Wert ein. Das wäre aber nur ein workaround

Ich habe sogar so etwas eingetragen, da verändere ich die Zeit in Abhängigkeit zur Season
Also mit Perl kann man echt schmutzige Sachen machen.

Code Auswählen Erweitern


ASC_Time_Down_Early { (ReadingsVal("Astro","ObsSeasonN",0) < 3)?sunset("CIVIL",3600):sunset("CIVIL",10800)}


VG
   Christian

[CoolTux]

Hallo CoolTux,
ich hoffe du kannst mir helfen, ich komme gerade nicht mehr weiter.
Vorgeschichte: HmIP Jalousie Steuerung die ich aktuell mit festen Zuordnungen über ASC ansteuere. Völlig unabhängig vom aktuellen Stand der Jalousie funktioniert die ASC Fahrt oder auch nicht.  Alle Attribute mit Positionsangaben sind unterschiedlich, es ist Tag, Shading Mode ist explizit aus (Shading Werte sind aber gesetzt).
Die Jalousie ist offen (oben), pct steht auf 100. Das Reading "ASC_Time_DriveDown" zeigt für den heutigen Tag 11:31 an, das wurde korrekt von ASC aus dem Attribut übernommen:

Code Auswählen Erweitern

2021.09.25 11:30:43.656 4: AutoShuttersControl (myASControl) - Devname: global Name: myASControl Notify: $VAR1 = [
          'ATTR HM_JAU_Jalousie ASC_Time_Down_Early 11:31'
        ];
2021.09.25 11:30:43.683 4: AutoShuttersControl (myASControl) - Devname: myASControl Name: myASControl Notify: $VAR1 = [
          'HM_JAU_Jalousie_nextAstroTimeEvent: 25.09.2021 - 11:31'
        ];
ASC_DEBUG!!! 2021.09.25 11:30:47 - FnIsDay: HM_JAU_Jalousie Allgemein: 1

Ganz nebenbei, obwohl Shading abgeschaltet ist, verbringt ASC allem Anschein nach die meiste Zeit damit die Shading Conditions für die Jalousie zu prüfen. Keine Ahnung ob das die Performance beeinflusst, ich sehe im Log aber fast nichts anderes.
Wenn ich jetzt die Zeit 11:31 erreicht habe passiert einfach nichts! Es gibt keine Überprüfung der Behanghöhe, kein Vergleich mit irgendetwas, einfach nichts. Das einzige was ASC macht ist folgendes:

Code Auswählen Erweitern

2021.09.25 11:31:01.050 4: AutoShuttersControl (myASControl) - Devname: myASControl Name: myASControl Notify: $VAR1 = [
          'HM_JAU_Jalousie_nextAstroTimeEvent: 26.09.2021 - 07:30'
        ];

Es wird der nächste Event eingestellt, der vorherige wird aber nicht (sichtbar) bearbeitet. Wie du in den Code Zeilen sehen kannst ist Debug aktiv und verbose = 5, irgendetwas sollte ich doch sehen, oder? Zumindest sehe ich bei anderen ASC Fahrten der Jalousie etwas, egal ob die Fahrt tatsächlich ausgelöst wird oder nicht.
Ich hoffe du findest Zeit mal darauf zu schauen, das Debugging hilft mir aktuell jedenfalls keinen Millimeter weiter.

Gruß Reinhard

11:30 Uhr ist Vormittag. Du hast also Simuliert. Ist das Rollo kurz vorher von Hand hochgefahren?

Zeig bitte ein list vom ASC und dem Rollo während der Simulationszeit.

[Reinhard.M]

Das Rollo wurde um 07:00 Uhr per Hand hochgefahren, weit vor der Blocking Zeit (1200). Es gibt ja auch wie gesagt keinerlei Auswertung für das Device wie ich es zum Beispiel bei anderen gesehen habe. Ich habe heute um 15:34 nochmals eine Simulation gemacht, die manuelle Fahrt ist ebenfalls wieder Stunden vorbei. Du findest alles in den Dateianhängen. In dieser Version habe ich mal den Vorschlag von Beta-User getestet. Funktioniert bei "Down" genau so wenig wie die Version mit festen Zuordnungen. Wie vor einigen Tagen schon einmal gepostet ist bei den festen Zuordnungen auch etwas schief. Bei mir funktionieren sie nur als "FesteZuordnung" und nicht als "30:FesteZuordnung" wie in der Commandref beschrieben.

[teufelchen]

Im schlimmsten Fall verwendest Du Perl und berechnest die Differenz in Sekunden zu Deiner gewünschten Zeit und die Sekunden trägst Du dann als Rückgabe Wert ein. Das wäre aber nur ein workaround

Ich habe sogar so etwas eingetragen, da verändere ich die Zeit in Abhängigkeit zur Season
Also mit Perl kann man echt schmutzige Sachen machen.

Code Auswählen Erweitern


ASC_Time_Down_Early { (ReadingsVal("Astro","ObsSeasonN",0) < 3)?sunset("CIVIL",3600):sunset("CIVIL",10800)}


VG
   Christian

@ CoolTux: Gibt es noch einen einfacheren, direkten Weg?

@ ch.eick: Wenn der Weg über Perl geht:
Lese ich über Getter "SunriseUnixTime" die Zeit aus wann ASC die Fahrt berechnet hat.
Dann ziehe ich mir daraus (weiß aber noch nicht wie) Tag, Monat und Jahr.
Erstelle mir mit timelocal aus meiner Wunschzeit und den oben gewonnenen Werten für Tag, Monat und Jahr wieder eine Unixzeit (= meine PrivacyUpTime)
Nun vergleiche ich SunriseUnixTime < meine PrivacyUpTime dann 0 ansonsten SunriseUnixTime > meine PrivacyUpTime dann SunriseUnixTime  - meine PrivacyUpTime

[CoolTux]

@ CoolTux: Gibt es noch einen einfacheren, direkten Weg?

@ ch.eick: Wenn der Weg über Perl geht:
Lese ich über Getter "SunriseUnixTime" die Zeit aus wann ASC die Fahrt berechnet hat.
Dann ziehe ich mir daraus (weiß aber noch nicht wie) Tag, Monat und Jahr.
Erstelle mir mit timelocal aus meiner Wunschzeit und den oben gewonnenen Werten für Tag, Monat und Jahr wieder eine Unixzeit (= meine PrivacyUpTime)
Nun vergleiche ich SunriseUnixTime < meine PrivacyUpTime dann 0 ansonsten SunriseUnixTime > meine PrivacyUpTime dann SunriseUnixTime  - meine PrivacyUpTime

ASC bietet da keinen einfacheren Weg bezüglich Deines Wunsches.

[CoolTux]

Auf meinen Git im testing Zweig gibt eine leicht gepatchte Version welche von einem User erstellt wurde. Der Patch fährt Nachts Markisen bei Wind unprotected ein. Dies war bisher ja nicht der Fall.

[CoolTux]

Das Rollo wurde um 07:00 Uhr per Hand hochgefahren, weit vor der Blocking Zeit (1200). Es gibt ja auch wie gesagt keinerlei Auswertung für das Device wie ich es zum Beispiel bei anderen gesehen habe. Ich habe heute um 15:34 nochmals eine Simulation gemacht, die manuelle Fahrt ist ebenfalls wieder Stunden vorbei. Du findest alles in den Dateianhängen. In dieser Version habe ich mal den Vorschlag von Beta-User getestet. Funktioniert bei "Down" genau so wenig wie die Version mit festen Zuordnungen. Wie vor einigen Tagen schon einmal gepostet ist bei den festen Zuordnungen auch etwas schief. Bei mir funktionieren sie nur als "FesteZuordnung" und nicht als "30:FesteZuordnung" wie in der Commandref beschrieben.

Deine Konfiguration ist nicht korrekt

Code Auswählen Erweitern

ASC_ComfortOpen_Pos 99.100
ASC_Open_Pos 100.100

So etwas gibt es gar nicht. Wenn dann 99:100 oder 100:100 wenn es um Lamellen geht.