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

[ms_steini]

Schichtdienst:

ich habe ein wenig herumexperimentiert und es leider nicht wirklich geschafft im Attribute "ASC_Time_Up_Early" mit Perl den vorhandenen ical Schichtkalender abzufragen.
Das geht schon, aber zu viele Log Meldungen, Probleme mit vorhandener ReadingsGroup und und und, war mir dann doch zu viel Arbeit.

ABER, vielleicht habe ich ja den Vogel von hinten durch die Brust erschossen.........

der Schicht/Dienstplan ist vorhanden, z.B. "defmod Schichtplan Calendar ical url http://xxxxx.xxx.xxx/schichtplan.ics 10800"

dann ein DoIf mit Zeitangabe erstellen:   

Code Auswählen Erweitern

defmod DOIF_Schichttermin DOIF ([00:05:00]) \
(attr EG.Rollo.Buero.Fenster ASC_Time_Up_Early {(fhem('get Schichtplan events format:custom="$U" limit:from=-1d,to=0d') =~ "_Nacht" ? "14:00":"06:00")};;\
attr EG.Rollo.Buero.Fenster ASC_Time_Up_Late {(fhem('get Schichtplan events format:custom="$U" limit:from=-1d,to=0d') =~ "_Nacht" ? "14:00":"09:15")};;\
)

um 00:05 wird einfach nur der ical Schichtplan.ics  abgefragt und die Attribute im Device mit der gewünschten Uhrzeit gefüllt.

3 mal getestet und funktioniert so für mich.

vielleicht kann ja der ein oder andere damit etwas anfangen.....

[flummy1978]

um 00:05 wird einfach nur der ical Schichtplan.ics  abgefragt und die Attribute im Device mit der gewünschten Uhrzeit gefüllt.

3 mal getestet und funktioniert so für mich.

Vielen Dank fürs dranbleiben ... führt aber dann zur Meldung dass ungespeicherte Änderungen vorhanden sind oder ?

Ich werde mich dem auch noch mal widmen, wenn ich etwas mehr Lust auf Basteleien hab

Grüße
Andreas

[ms_steini]

ja klar, das schon. Aber man kann ja ein save hinterschicken

[hhhdg]

Hallo Andreas,

sorry, ich hatte das gelesen, aber wohl falsch verstanden.

Was aber in meinen Augen 90% der Fehler erschlagen würde, wären markante Infos (Im Modul bsw wenn man entsprechende Attribute auswählt) dass es zwei GANZ WICHTIGE Einschränkungen beim Setup gibt:
1. Positionen dürfen sich innerhalb eines Rollos nicht überschneiden - Auch ASC_Closed_Pos 100 night 99 ASC_Shading_Pos 98 ASC_ComfortOpen_Pos 97 usw... sind bereits unterschiedliche Positionen.
2. Sensoren dürfen sich im ASC Device nicht überschneiden - D.h. wurde bereits die Temperatur vom Wettermodul genommen so muss für die Regen oder Windinfos ein anderes Device / Dummy zwischen gelegt werden.

Du meinst mit Überschneiden, das Positionswerte (also die gleichen Zahlen) nicht identisch gesetzt werden dürfen, damit das Modul unterscheiden kann, in welchem Zustand es das Fenster zuletzt gefahren hat? Ich hatte vermutet Sie müssen nur einer Reihenfolge genügen (OpenPos < ComfortOpenPos < Shading < ... < ClosedPos, ggf. sogar mit <= anstelle <) und dass du das mit "überschneiden" gemeint hast. Auf jeden Fall sind ja solch Logiken drin, die Rollos in diesem Fall nicht fahren, wenn sie schon weiter auf sind als die anzufahrende Stellung wäre...

Dennoch wird ein paar Zeilen weiter vorn im Source-Code OpenPos anstelle von VentilatePos benutzt, wenn 'terrace' und 'twostate' gesetzt sind. In beiden Fällen ohne Prüfung auf 0 oder undef - deshalb hatte ich mich gefragt, warum hier explizit verhindert wird auf 0 zu fahren, während für twostates an Terrassentüren OpenPos genutzt wird, das ja i.d.R. der Wert 0 haben wird.

[D3ltorohd]

Mal eine kurze Frage. Wie kann ich gewisse Rollos temporär aus der ASC Steuerung nehmen, so das sie nur noch manuell fahren ?

[wk]

Im RolladenDevice den Befehl 'set shutterASCenableToggle' benutzen. Es erscheint eine Auswahl der an- oder auszuschaltenden Rollos.

[eurofinder]

Noch eine Anregung für das wiki zum Modul.

Vielleicht könnten wir einen Abschnitt mit Beispielen anlegen, wo Problemlösungen an Hand von Beispieleinträgen in den entsprechenden Attributen hinterlegt sind.
Mir kommt es auch so vor, als dass einzelne Themen hier immer wieder auftreten.

Mein größter Wunsch für das Modul wäre, dieses intern so umzustrukturieren, dass für jedes Attribut jede Position angewählt werden kann. Vielleicht könnte dazu intern eine Kombination aus aktueller Position und Fahrgrund genutzt werden.
z.B.:
Rollladen befindet sich in Beschattung, mit Position 40. Nun wird Terrassentür geöffnet, damit (ComfortOpen) und Position 100. Beim Schließen wird wieder Position 40 und Shading in gesetzt. Bei Shading Out wird Position auf 100 gesetzt. Wurde der Rollladen manuell gesteuertauf 100 ist der Fahrgrund halt manuell usw. Durch aktuelle Position, Fahrgrund und alte Position und Fahrgrund sollte das doch machbar sein:-)

Nur mal so als Idee.

Gruß
eurofinder
 

[Beta-User]

Noch eine Anregung für das wiki zum Modul.

Vielleicht könnten wir einen Abschnitt mit Beispielen anlegen, wo Problemlösungen an Hand von Beispieleinträgen in den entsprechenden Attributen hinterlegt sind.

Es gibt afaik einen Artikel zu ASC im Wiki-Bereich.

Bitte: Wer mag, kann einfach die betreffenden Textbausteile als Vorschlag da einkippen (muß nicht formatiert sein, aber wenn, dann bitte möglichst (!) im Wiki-Format) und in den Wiki-Thread einkippen. Ich werde das dann versuchen einzubauen, falls nicht jemand anderes sich darum kümmern mag.
Insbesondere eine Art FAQ-Liste wäre m.E. gut und vermutlich auch nicht allzu aufwendig in der Erstellung? (Sowas ist eine Fleißaufgabe, evtl. würde es für's erste reichen, das ganze als simple Stichwort+Linkliste direkt auf die passenden Forums-Postings zu gestalten? Ausformulieren könnte man dann bei Bedarf später, aber es wäre schon mal das Material etwas geordneter?)

Was features angeht: das mit der internen Liste kommt mir bekannt vor, wäre aber mMn. im Moment wohl besser auf github aufgehoben, da kann man das dann auch leichter priorisieren. Für den Moment würde ich das als "Schönheitsfehler mit dem Potential zur Dauerirritation bei Einsteigern" betrachten?

[flummy1978]

Hey,

sorry, ich hatte das gelesen, aber wohl falsch verstanden.
Du meinst mit Überschneiden, das Positionswerte (also die gleichen Zahlen) nicht identisch gesetzt werden dürfen, damit das Modul unterscheiden kann, in welchem Zustand es das Fenster zuletzt gefahren hat?

Exakt, genau das ist es .... ** CoolTux hat es so angefangen und darauf mehr oder weniger das Ganze Modul aufgebaut, das Ganze jetzt (partiell) zu ändern, wäre imho 1. SEHR aufwändig 2. sehr verwirrend (warum gehen auf einmal gleiche Positionen) 3. Unnötig (Wer erkennt schon den Rolladenunterschied zwischen 48 und 47 ? Das ist AUSSCHLIEßLICH fürs Modul und dessen Funktion wichtig)

Zu Deinem Problem:
Ich bin mir nicht sicher, aber ich meine ComfortOpen und Twostate beisst sich. Wenn ich sichergehen will, dass ich nicht ausgesperrt werde, dann sicherlich nicht abhängig von einem Modul / RasPi oder ähnlichem Für die eigentliche Funktion musst Du mal nach einem Beitrag von mir im Bezug auf Terrasse und TwoState, da hatte CoolTux mir eine entsprechende Lösung vorgestellt, die ich mitterweile abgewandelt eingesetzt habe - Weil mir wichtig ist, dass die Außenjalousie in diesem Fall SOFORT wieder runter fährt, wenn ich die Tür aufgemacht habe und damit Beschattung unterbrochen habe - auch dann wenn die Tür noch Spalt offen ist und nicht ganz offen.  (Habs gefunden: # 67 in dem Bereich war das)

@Eurofinder:

Durch aktuelle Position, Fahrgrund und alte Position und Fahrgrund sollte das doch machbar sein:-)

Siehe **
und zum "größten Wunsch" ... nur zu, bau es ein , wirklich nur meine bescheidenen eigenen 2 cent:
Wenn man einmal den Grund weiß, warum es so ist. Muss ich mich damit abfinden, dass der Modulautor das eben so gemacht hat. CoolTux hat darauf die kompletten Berechnungen, Verriegelungen und und und aufgebaut. Er wird das ganz sicher nicht mehr ändern und es wäre in meinen Augen auch sinnlos. Aus welchen Grund sollte eine Position ZWINGEND 40 und nicht 39 sein ? Warum muss es 3x 90 sein und nicht 89,90 und 91 ? Den optischen Unterschied erkennt man am Rollo imho niemals.

Bitte nicht falsch verstehen.... Ich verstehe, wenn man ALLE seine Ausnahmen etc vom Modul abgedeckt haben möchte, aber wir haben hier bereits eine Eierlegende Wollmichsau, sie muss nicht noch mehr Besonderheiten und Ausnahmen abdecken als es ohnehin schon passiert Hierzu gibt es dann die Möglichkeiten außen herum seine Ausnahme selbst zu führen, oder im Modul die Änderung selbst vornehmen (wie ich es im ROLLO Modul auch schon mal gemacht habe)

Viele Grüße
Andreas

[Beta-User]

@flummy1978:
Auch wenn der Hinweis ok ist, dass es diese Einschränkung mit den verschiedenen Positionen schon immer gab: zwingend ist das nicht, und teils ist es afaik auch nicht so einfach, Zwischenwerte anzufahren, weil manche Module das nicht erlauben, Zwischenpositionen runden, ....
Kurz: Es gibt teils gute Gründe, das für verbesserungsfähig zu erachten, und es ist darüber hinaus auch immer wieder ein "Stolpersteinchen" für Einsteiger. Es wäre daher auch nach meiner persönlichen Ansicht erstrebenswert, das möglichst durch eine andere Logik zu ersetzen.

Aber dringend ist das nicht, da sind wir uns einig, dass man in den meisten Fällen sehr gut mit den Einschränkungen leben kann (und es ggf. auch workarounds gibt, die man zumindest zum Teil im "Hardwarethread" finden kann (Falls jemand jetzt was einfallen sollte: Da ist Platz für weitere Lösungen...)).

[ms_steini]

ich verstehe das nicht, kann mir das bitte jemand erklären:

wenn ich in den Attribeuten vom Device Perl Code nutze

Code Auswählen Erweitern

attr EG.Rollo.Buero.Fenster ASC_Time_Up_Early { (ReadingsVal('Schichtplan','Schicht_Gestern_Nachtdienst',0) == 1 ? '15:10':'06:00') }
attr EG.Rollo.Buero.Fenster ASC_Time_Up_Late { (ReadingsVal('Schichtplan','Schicht_Gestern_Nachtdienst',0) == 1 ? '15:15':'06:30') }

und das Attribut "ASC_Up" auf brightness steht, tut sich da gar nichts, obwohl im ASC "Next DriveUp 04.08.2020 - 15:15:01" steht.
Stelle ich das Attribut "ASC_Up" auf "time" funktionieren die Attribute "ASC_Time_Up_Early" und "ASC_Time_Up_Late" mit Perl
Das Attribut "ASC_brightnessDriveUpDown 20.00:0.51" in ASC ist gesetzt.
Trage ich eine normale Uhrzeit in  ASC_Time_Up_Early und  ASC_Time_Up_Late ein (ohne Perl) funktioniert es auch.

[amenomade]

ich verstehe das nicht, kann mir das bitte jemand erklären:

wenn ich in den Attribeuten vom Device Perl Code nutze

Code Auswählen Erweitern

attr EG.Rollo.Buero.Fenster ASC_Time_Up_Early { (ReadingsVal('Schichtplan','Schicht_Gestern_Nachtdienst',0) == 1 ? '15:10':'06:00') }
attr EG.Rollo.Buero.Fenster ASC_Time_Up_Late { (ReadingsVal('Schichtplan','Schicht_Gestern_Nachtdienst',0) == 1 ? '15:15':'06:30') }

und das Attribut "ASC_Up" auf brightness steht, tut sich da gar nichts, obwohl im ASC "Next DriveUp 04.08.2020 - 15:15:01" steht.
Stelle ich das Attribut "ASC_Up" auf "time" funktionieren die Attribute "ASC_Time_Up_Early" und "ASC_Time_Up_Late" mit Perl
Das Attribut "ASC_brightnessDriveUpDown 20.00:0.51" in ASC ist gesetzt.
Trage ich eine normale Uhrzeit in  ASC_Time_Up_Early und  ASC_Time_Up_Late ein (ohne Perl) funktioniert es auch.

Das würde mich sehr interessieren, wenn mittlerweile Perl Code in diesen Attribute unterstützt wäre. Ich lese mit...

[flummy1978]

Aloha zusammen,

ich verstehe das nicht, kann mir das bitte jemand erklären:

wenn ich in den Attribeuten vom Device Perl Code nutze

Code Auswählen Erweitern

attr EG.Rollo.Buero.Fenster ASC_Time_Up_Early { (ReadingsVal('Schichtplan','Schicht_Gestern_Nachtdienst',0) == 1 ? '15:10':'06:00') }
attr EG.Rollo.Buero.Fenster ASC_Time_Up_Late { (ReadingsVal('Schichtplan','Schicht_Gestern_Nachtdienst',0) == 1 ? '15:15':'06:30') }

und das Attribut "ASC_Up" auf brightness steht, tut sich da gar nichts, obwohl im ASC "Next DriveUp 04.08.2020 - 15:15:01" steht.
Stelle ich das Attribut "ASC_Up" auf "time" funktionieren die Attribute "ASC_Time_Up_Early" und "ASC_Time_Up_Late" mit Perl
Das Attribut "ASC_brightnessDriveUpDown 20.00:0.51" in ASC ist gesetzt.
Trage ich eine normale Uhrzeit in  ASC_Time_Up_Early und  ASC_Time_Up_Late ein (ohne Perl) funktioniert es auch.

Erklärung nein, lediglich die Vermutung, mal in Erinnerung zu haben, dass CoolTux in seinen Sachen auch immer mal wieder berücksichtigt hat ob isday 0|1 ist. Bedeutet, es KANN sein, dass manche Fahrten nicht funktionieren, obwohl sie korrekt eingestellt sind, weil diese zu den Tages / Nachtfahrten gehören, die jeweils nur einmal pro Tag vorkommen (dürfen). Ob das ausgerechnet in Deinem Fall so ist, kann ich Dir nicht sagen, aber wäre eine Möglichkeit.
Daher teste ich sowas immer indem ich ein Dummy Rollo mit entsprechenden Attributen belege und es mitlogge, was dort passiert.
In DIESEM speziellem Fall, wäre die Frage: MÜSSEN diese Rolläden nach Brightness fahren ? Wäre es hier nicht einfacher nach Zeit zu agieren und entsprechend ob Nachtschicht oder nicht belegen?

Und aaaahhhja .. .das könnte es sein: Hast Du nach der Änderung createnewNotify und newTimer gemacht ? (auch wenn dort die richtige Zeit steht kann es manchmal passieren, dass die Timer nicht sofort neu übernommen werden, sondern erst beim neuen Erstellen des Timers - z.B. durch manuelles erstellen oder nach der nächsten Fahrt)


@Beta-User: Ich weiss nicht ob ich Deinen Einwand jetzt richtig verstanden habe, aber es ist nunmal in dem Modul so, dass für viele Funktionen, die Positionen nicht gleich sein dürfen? Und ....

Kurz: Es gibt teils gute Gründe, das für verbesserungsfähig zu erachten, und es ist darüber hinaus auch immer wieder ein "Stolpersteinchen" für Einsteiger. Es wäre daher auch nach meiner persönlichen Ansicht erstrebenswert, das möglichst durch eine andere Logik zu ersetzen.

Das hätte ich mir auch ursprünglich gewünscht aber so ist es nunmal (leider) nicht und man muss damit umzugehen lernen. Ich denke einfach, sämtliche Logiken aus dieser Einschränkung zu nehmen, käme einem Neuschreiben des Moduls gleich.
Stolpersteinchen ist imho vor allem deshalb, weil CoolTux wie ich schon mal sagte, die Leute verwöhnt hat und ihnen das nicht gesagt hat, sondern die Lösung präsentiert hat. D.h. die Leute lesen / lernen weniger und lassen sich schneller die fertige Lösung präsentieren

@amenomade:

Das würde mich sehr interessieren, wenn mittlerweile Perl Code in diesen Attribute unterstützt wäre. Ich lese mit...

Schau mal in #422 das ist es doch was Du meinst oder nicht ?

    ASC_Time_Up_Early       05:00    Sonnenaufgang frühste Zeit zum Hochfahren !!!Verwendung von Perlcode ist möglich, dieser muss in {} eingeschlossen sein. Rückgabewert muss ein Zeitformat in Form HH:MM[:SS] sein!!!
    ASC_Time_Up_Late       08:30    Sonnenaufgang späteste Zeit zum Hochfahren  !!!Verwendung von Perlcode ist möglich, dieser muss in {} eingeschlossen sein. Rückgabewert muss ein Zeitformat in Form HH:MM[:SS] sein!!!

Viele Grüße
Andreas

[edition]

Guten Abend

Ich habe die Idee, die Sache mit der Nachtschicht über roommate zu steuern aufgegeben, nachdem ich gesehen habe, was ms_steini gemacht hat.
Da ich den Googlekalender ohnehin in fhem habe und auch das dazugehörige CALVIEW, setze ich einfach das Reading aus dem CALVIEW in die Attribute.

Code Auswählen Erweitern

ASC_Time_Up_Early {ReadingsVal("Kalenderauszug3","tomorrow_001_btime","")}
ASC_Time_Up_Late {ReadingsVal("Kalenderauszug3","tomorrow_001_etime","")}

Ich nehme die Zeiten aus dem tomorrow Termin, weil der neue Timer ja erstellt wird, nachdem der Rollladen hochgefahren ist.

Ich hoffe, ich habe da keinen Denkfehler. Aktuell steht jedenfalls in der Information Summary 05.08.2020 - 08:55:01 als next Drive Up für den Rollladen im Schlafzimmer.

[xerion]

Abend zusammen,

ich habe mit der v.0.10.5 das Problem, das nach einem FHEM Neustart das Attribut "ASC_ShuttersPlace" gelöscht wird. Ist mit aufgefallen, das bei meinem Terrassenfenster auf einmal das Rollo trotz geöffneten Fenster geschlossen wurde.

Kann jemand das Verhalten bei sich auch nachstellen?