[73_AutoShuttersControl.pm] Rolllos automatisiert steuern - Version 0.8.x

[CoolTux]

Nach dem kompletten Neuaufsetzen des ASC-Moduls nicht mehr vorhanden.

LG

pah

Hallo Peter,

Super, ein Hoffnungsschimmer 
Bitte beobachte mal noch ein paar Tage.


Grüße
Marko

[roman1528]

Moin CoolTux und danke für deine Antworten.

Wie genau kommst Du denn auf diese Annahme? Der Wert vom Helligkeitssensor wird zur direkten Steuerung für die Morgens und Abendsfahrt verwendet. Sofern brightness in ASC_Up und ASC_Down steht.

Dann ist doch alles gut. Ich habe möglicherweise die CommandRef falsch interpretiert. "Werte bei dem Schaltbedingungen für Sonnenauf- und -untergang geprüft werden sollen."
Wird dann trotzdem noch ASC_Time_Up/Down_Early/Late beachtet? Wäre mir schon wichtig, dass der Rollladen erst hoch fährt wenn auch die Zeit es zulässt.

Genau so funktioniert es auch.

Na dann ist doch alles schick. Dann waren meine Beobachtungen falsch. Vielleicht aber auch durch etwas Chaos meinerseits in den ganz schön vielen Attributen verursacht.

ASC selbst benötigt immer einen trigger. Es schaltet also nicht wirklich von alleine. Hier wäre gut zu wissen was genau Du wie gemacht und eingestellt hast. Möglichkeit wäre Fenster geschlossen, wobei das glaube mittlerweile abgefangen werden sollte.

Fenster geschlossen habe ich nicht. Es war offen. Zudem es beide Rollladen gemacht haben. Mein Lichtsensor (HM) liefert zyklisch Daten. Eventuell wurde ASC dadurch getriggert, weil noch dunkel und nicht ASC_Time_Up_Early. Also sollte ich wohl doch ASC_BlockingTime_afterManual setzen? Aber wie lange? Es ist ja unterschiedlich wann ich manuell steuere und wann es hell/dunkel wird.

Das mit dem doppelt ist seltsam. Mach mal ein set createNewNotifyDev. Mal schauen ob es besser wird.

createNewNotifyDev hat da tatsächlich Abhilfe geschaffen... Jetzt steht das Richtige drin.

Desweiteren fällt mir auf das Du als ClosedPos bei einem 80 zu stehen. Das ist Unsinn. ClosedPos muss immer die unterste Position abbilden. Also geschlossen.

Und genau das sollte unteranderem der User entscheiden wie weit er seinen Rollladen schließen möchte. Ich habe hier 80 eingestellt, weil im Schlafzimmer die "Schlitze" vom Rollladen offen bleiben sollen. Er soll also nur auf dem Fensterbrett aufliegen.

Wichtig ist auch zu wissen das die per Attribut gesetzen Positionen immer abweichen müssen von der default Positionen welche im Modul schon für die Attribute vorhanden sind. 50 ist zum Beispiel für PrivacyPos vorgesehen. Du müsstes also wenn dann 40 oder 45 machen.

Da wäre eine Liste der Defaults sehr hilfreich, als sich durch die CommandRef wühlen zu müssen. Obwohl ich auch das als irrelevant ansehen würde, weil ASC zwischen Shading_Pos und Privacy_Pos unterschieden sollte, auch wenn die Werte gleich sind.
Ich könnte hier also auch 51 einstellen, in der Hoffnung, dass der Rollladen dann auch immer brav 51 reported? Also besser 55. Und wenn ich PrivacyPos auf z.B. 62 festlege... wird dann der Default von PrivacyPos ignoriert und ich kann bei ShadingPos 50 einstellen?

Warum kann ich die Ventilate_Pos nicht auch auf "open/0" stellen? Wenn ich lüften möchte, dann aber auch richtig XD

Das wäre mir noch wichtig. Ventilate_Pos sollte man auch auf "open/0" stellen können.

Grüße^^

[CoolTux]

Moin CoolTux und danke für deine Antworten.

Dann ist doch alles gut. Ich habe möglicherweise die CommandRef falsch interpretiert. "Werte bei dem Schaltbedingungen für Sonnenauf- und -untergang geprüft werden sollen."
Wird dann trotzdem noch ASC_Time_Up/Down_Early/Late beachtet? Wäre mir schon wichtig, dass der Rollladen erst hoch fährt wenn auch die Zeit es zulässt.

Na dann ist doch alles schick. Dann waren meine Beobachtungen falsch. Vielleicht aber auch durch etwas Chaos meinerseits in den ganz schön vielen Attributen verursacht.

Fenster geschlossen habe ich nicht. Es war offen. Zudem es beide Rollladen gemacht haben. Mein Lichtsensor (HM) liefert zyklisch Daten. Eventuell wurde ASC dadurch getriggert, weil noch dunkel und nicht ASC_Time_Up_Early. Also sollte ich wohl doch ASC_BlockingTime_afterManual setzen? Aber wie lange? Es ist ja unterschiedlich wann ich manuell steuere und wann es hell/dunkel wird.

createNewNotifyDev hat da tatsächlich Abhilfe geschaffen... Jetzt steht das Richtige drin.

Und genau das sollte unteranderem der User entscheiden wie weit er seinen Rollladen schließen möchte. Ich habe hier 80 eingestellt, weil im Schlafzimmer die "Schlitze" vom Rollladen offen bleiben sollen. Er soll also nur auf dem Fensterbrett aufliegen.

Da wäre eine Liste der Defaults sehr hilfreich, als sich durch die CommandRef wühlen zu müssen. Obwohl ich auch das als irrelevant ansehen würde, weil ASC zwischen Shading_Pos und Privacy_Pos unterschieden sollte, auch wenn die Werte gleich sind.
Ich könnte hier also auch 51 einstellen, in der Hoffnung, dass der Rollladen dann auch immer brav 51 reported? Also besser 55. Und wenn ich PrivacyPos auf z.B. 62 festlege... wird dann der Default von PrivacyPos ignoriert und ich kann bei ShadingPos 50 einstellen?

Das wäre mir noch wichtig. Ventilate_Pos sollte man auch auf "open/0" stellen können.

Grüße^^

Ich antworte Dir gerne wenn ich wieder gesund bin.

Grüße

[CoolTux]

Guten Morgen,

Moin CoolTux und danke für deine Antworten.

Dann ist doch alles gut. Ich habe möglicherweise die CommandRef falsch interpretiert. "Werte bei dem Schaltbedingungen für Sonnenauf- und -untergang geprüft werden sollen."
Wird dann trotzdem noch ASC_Time_Up/Down_Early/Late beachtet? Wäre mir schon wichtig, dass der Rollladen erst hoch fährt wenn auch die Zeit es zulässt.

Laut Commandref

ASC_Up - astro/time/brightness - bei astro wird Sonnenaufgang berechnet, bei time wird der Wert aus ASC_Time_Up_Early als Fahrzeit verwendet und bei brightness muss ASC_Time_Up_Early und ASC_Time_Up_Late korrekt gesetzt werden. Der Timer läuft dann nach ASC_Time_Up_Late Zeit, es wird aber in der Zeit zwischen ASC_Time_Up_Early und ASC_Time_Up_Late geschaut, ob die als Attribut im Moduldevice hinterlegte Down Wert von ASC_brightnessDriveUpDown erreicht wurde. Wenn ja, wird der Rollladen hoch gefahren (default: astro)

Na dann ist doch alles schick. Dann waren meine Beobachtungen falsch. Vielleicht aber auch durch etwas Chaos meinerseits in den ganz schön vielen Attributen verursacht.

Fenster geschlossen habe ich nicht. Es war offen. Zudem es beide Rollladen gemacht haben. Mein Lichtsensor (HM) liefert zyklisch Daten. Eventuell wurde ASC dadurch getriggert, weil noch dunkel und nicht ASC_Time_Up_Early. Also sollte ich wohl doch ASC_BlockingTime_afterManual setzen? Aber wie lange? Es ist ja unterschiedlich wann ich manuell steuere und wann es hell/dunkel wird.

createNewNotifyDev hat da tatsächlich Abhilfe geschaffen... Jetzt steht das Richtige drin.

Schön das es nun geht. Zum selbstständigen fahren müsste man das nächste mal schauen was im Reading für den Grund der Fahrt angegeben wird.

Und genau das sollte unteranderem der User entscheiden wie weit er seinen Rollladen schließen möchte. Ich habe hier 80 eingestellt, weil im Schlafzimmer die "Schlitze" vom Rollladen offen bleiben sollen. Er soll also nur auf dem Fensterbrett aufliegen.

Das mag wohl sein, allerdings gibt es die derzeitige Logik nicht her. Bedeutet für den User entweder er nimmt etwas anderes zum Steuern oder lebt damit nicht alles selbst bestimmen zu können. Daher ja auch AUTOMATIK.
Es gibt im übrigen das Attribut SleppPosition die kannst Du verwenden.
Ich ich habe vor die interne Logik in absehbarer Zeit zu ändern.

Da wäre eine Liste der Defaults sehr hilfreich, als sich durch die CommandRef wühlen zu müssen. Obwohl ich auch das als irrelevant ansehen würde, weil ASC zwischen Shading_Pos und Privacy_Pos unterschieden sollte, auch wenn die Werte gleich sind.

Siehe oben

Ich könnte hier also auch 51 einstellen, in der Hoffnung, dass der Rollladen dann auch immer brav 51 reported? Also besser 55. Und wenn ich PrivacyPos auf z.B. 62 festlege... wird dann der Default von PrivacyPos ignoriert und ich kann bei ShadingPos 50 einstellen?

Ja das kannst Du

Das wäre mir noch wichtig. Ventilate_Pos sollte man auch auf "open/0" stellen können.
Grüße^^

Mit der Änderung der internen Logik sollte es nach meinen Überlegungen eigentlich funktionieren. Bis dahin gilt. Es geht nicht.


Grüße
Marko

[roman1528]

Guten Morgen,

Laut Commandref

Schön das es nun geht. Zum selbstständigen fahren müsste man das nächste mal schauen was im Reading für den Grund der Fahrt angegeben wird.

Das mag wohl sein, allerdings gibt es die derzeitige Logik nicht her. Bedeutet für den User entweder er nimmt etwas anderes zum Steuern oder lebt damit nicht alles selbst bestimmen zu können. Daher ja auch AUTOMATIK.
Es gibt im übrigen das Attribut SleppPosition die kannst Du verwenden.
Ich ich habe vor die interne Logik in absehbarer Zeit zu ändern.

Siehe oben

Ja das kannst Du

Mit der Änderung der internen Logik sollte es nach meinen Überlegungen eigentlich funktionieren. Bis dahin gilt. Es geht nicht.


Grüße
Marko

Danke 

[xerion]

Hallo CoolTux,

ich habe folgendes Phänomen. Ich nutze für die Steuerung Brightness und in der Küche zusätzlich Privacy Down/Up über Brightness. Da es in der Brightness Variante noch keine Weekend Steuerung gibt, habt ich mir mit at und doif etwas gebastelt.
Am Wochenende um 01:00 Uhr wird per at "set ASC ascEnable off" gesetzt. Das öffnen der Rollos übernimmt dann das doif. Wenn es Wochenende ist wird um 12:00 Uhr wieder per at "set ASC ascEnable on" gesetzt damit Abends die gewohnte Steuerung wieder funktioniert. Das funktioniert bis hierhin auch ohne Probleme.

Aber wenn ich jetzt Abends vor den Privacy Down Wert die Fenster noch geöffnet habe, dann fahren diese trotz geöffneten Fenster in die Privacy Position, was auch noch normal sein sollte. Aber wenn ich dann später die Fenster schließe, fahren die Rollos nach oben und werden nicht geschlossen und das ist nicht normal. Das Problem habe ich aber nur am WE. In der Woche klappt es . Kommt ASC mit dem on/off nicht klar oder was kann es noch sein?

Nachtrag:
Als Fahrgrund steht auch:
   window closed at day

[Vorhand]

Hab' noch mal eine Verständnisfrage zu folgender Aussage der Commandref:
"ASC_freezeTemp - Temperatur, ab welcher der Frostschutz greifen soll und der Rollladen nicht mehr fährt. Der letzte Fahrbefehl wird gespeichert."

Sollte der Laden nach Überschreiten der freezeTemp, den letzten Fahrbefehl ausführen? Also bei mir öffnen! Er tut es nicht!
Oder ist das ganz anders gemeint?
Danke

[CoolTux]

Hab' noch mal eine Verständnisfrage zu folgender Aussage der Commandref:
"ASC_freezeTemp - Temperatur, ab welcher der Frostschutz greifen soll und der Rollladen nicht mehr fährt. Der letzte Fahrbefehl wird gespeichert."

Sollte der Laden nach Überschreiten der freezeTemp, den letzten Fahrbefehl ausführen? Also bei mir öffnen! Er tut es nicht!
Oder ist das ganz anders gemeint?
Danke

Der Code wurde diesbezüglich vor einem Jahr geändert aber die Commandref nicht korekt angepasst. Aktuell soll er gar nichts machen.

[CoolTux]

Hallo CoolTux,

ich habe folgendes Phänomen. Ich nutze für die Steuerung Brightness und in der Küche zusätzlich Privacy Down/Up über Brightness. Da es in der Brightness Variante noch keine Weekend Steuerung gibt, habt ich mir mit at und doif etwas gebastelt.
Am Wochenende um 01:00 Uhr wird per at "set ASC ascEnable off" gesetzt. Das öffnen der Rollos übernimmt dann das doif. Wenn es Wochenende ist wird um 12:00 Uhr wieder per at "set ASC ascEnable on" gesetzt damit Abends die gewohnte Steuerung wieder funktioniert. Das funktioniert bis hierhin auch ohne Probleme.

Aber wenn ich jetzt Abends vor den Privacy Down Wert die Fenster noch geöffnet habe, dann fahren diese trotz geöffneten Fenster in die Privacy Position, was auch noch normal sein sollte. Aber wenn ich dann später die Fenster schließe, fahren die Rollos nach oben und werden nicht geschlossen und das ist nicht normal. Das Problem habe ich aber nur am WE. In der Woche klappt es . Kommt ASC mit dem on/off nicht klar oder was kann es noch sein?

Nachtrag:
Als Fahrgrund steht auch:
   window closed at day

Stimmen denn die Angaben beim Reading ASC_Time_DriveDown?

[Vorhand]

Der Code wurde diesbezüglich vor einem Jahr geändert aber die Commandref nicht korekt angepasst. Aktuell soll er gar nichts machen

Danke.
Wünschen würde ich mir, dass er nach Überschreiten der ASC_freezeTemp, den letzten Befehl ausführt.
Grüße

[CoolTux]

Danke.
Wünschen würde ich mir, dass er nach Überschreiten der ASC_freezeTemp, den letzten Befehl ausführt.
Grüße

Die Temperatur würde noch nie in ASC als Trigger genommen sondern immer lediglich ausgelesen und für Bedingungsabfragen genutzt 

[wk]

Ich habe wie Vorhand gestern Antifreeze probiert und war heute morgen begeistert, dass mein Rolladen "no drive - antifreeze defense" anzeigte.
Aber dann kam auch das Aha-Erlebnis. Der Rolladen ging nicht auf obwohl es in der Zwischenzeit über 7 Grad hat.
Wie ich gerade meine Frage stellen wollte, sah ich Vorhands Post.

Hat jemand eine Idee, wie wir die nachzuholende Fahrt doch noch Triggern können?

[CoolTux]

Ich habe wie Vorhand gestern Antifreeze probiert und war heute morgen begeistert, dass mein Rolladen "no drive - antifreeze defense" anzeigte.
Aber dann kam auch das Aha-Erlebnis. Der Rolladen ging nicht auf obwohl es in der Zwischenzeit über 7 Grad hat.
Wie ich gerade meine Frage stellen wollte, sah ich Vorhands Post.

Hat jemand eine Idee, wie wir die nachzuholende Fahrt doch noch Triggern können?

Fenster auf, Fenster zu 

[wk]

Good joke 

Es ist gerade jetzt die Jahreszeit, wo die Dachliegerolläden morgens noch gefroren sind, aber im Lauf des Vormittags die Sonne das Haus wärmen könnte. Wenn dann keiner daheim ist zum Aufmachen schlägt die Stunde der Automatik.

[CoolTux]

Dann würde ich ein Notify nehmen welches auf die Temp triggert.