[73_AutoShuttersControl.pm] Neues Modul zum automatisierten steuern von Rolläden

[stefanpf]

narf....gerade ist der Groschen aber pfennigweise gefallen - sorry

- Mir war gerade aufgefallen, dass mein Ubiquiti Gelumpe anscheinend seit dem letzten Firmware Update keine ordentlichen IPV6 Adressen mehr verteilt und
  deswegen meine Google-Kalender nicht mehr aktualisiert werden (dann klappt's auch nicht mit der Urlaubssteuerung  )

- Dann war ich der Meinung ich hätte (wie früher im Script) ein Urlaubsreading oder device hinterlegt .... warum ich immer, dass habe ich wohl durcheinander gebracht

- Nachdem ich geschnallt habe, dass mit we2holiday in der Hilfe eigentlich "holiday2we" gemeint ist wurde es dann hell, also die "ASC_Time_Up_WE_Holiday" wird verwendet

Code Auswählen Erweitern

foreach my $h2we ( split( ",", AttrVal( "global", "holiday2we", "" ) ) )

Sehe ich das richtig, dass ich statt einem Holiday Device/File auch einen Dummy mit den Readings state / tomorrow / yesterday anlegen können müsste, den ich per DOIF aus meinen Kalender füttere?
Ich denke da an so etwas in diese Richtung...

Code Auswählen Erweitern


defmod du_Rolladen_FT_Urlaub dummy;
attr du_Rolladen_FT_Urlaub group Kalender;
attr du_Rolladen_FT_Urlaub room 99_Srv.Anwesenheit;

setreading du_Rolladen_FT_Urlaub state none;
setreading du_Rolladen_FT_Urlaub tomorrow test;
setreading du_Rolladen_FT_Urlaub yesterday none;

attr global holiday2we du_Rolladen_FT_Urlaub;

defmod di_UrlaubFeiertag2Dummy.today DOIF (  [cal_Google_SPVP_Urlaub_calview:c-today] > 0 )  (setreading du_Rolladen_FT_Urlaub today ja;;)  DOELSE (setreading du_Rolladen_FT_Urlaub today none;;)
attr di_UrlaubFeiertag2Dummy.today do always
attr di_UrlaubFeiertag2Dummy.today group Kalender
attr di_UrlaubFeiertag2Dummy.today icon helper_doif
attr di_UrlaubFeiertag2Dummy.today room 92_Srv.Automat,99_Srv.Anwesenheit

defmod di_UrlaubFeiertag2Dummy.tomorrow DOIF (  [cal_Google_SPVP_Urlaub_calview:c-tomorrow] > 0 )  (setreading du_Rolladen_FT_Urlaub tomorrow ja;;)  DOELSE (setreading du_Rolladen_FT_Urlaub tomorrow none;;)
attr di_UrlaubFeiertag2Dummy.tomorrow do always
attr di_UrlaubFeiertag2Dummy.tomorrow group Kalender
attr di_UrlaubFeiertag2Dummy.tomorrow icon helper_doif
attr di_UrlaubFeiertag2Dummy.tomorrow room 92_Srv.Automat,99_Srv.Anwesenheit



Zumindest in der Trockenübung sieht das ganz gut aus

[CoolTux]

narf....gerade ist der Groschen aber pfennigweise gefallen - sorry

- Mir war gerade aufgefallen, dass mein Ubiquiti Gelumpe anscheinend seit dem letzten Firmware Update keine ordentlichen IPV6 Adressen mehr verteilt und
  deswegen meine Google-Kalender nicht mehr aktualisiert werden (dann klappt's auch nicht mit der Urlaubssteuerung  )

- Dann war ich der Meinung ich hätte (wie früher im Script) ein Urlaubsreading oder device hinterlegt .... warum ich immer, dass habe ich wohl durcheinander gebracht

- Nachdem ich geschnallt habe, dass mit we2holiday in der Hilfe eigentlich "holiday2we" gemeint ist wurde es dann hell, also die "ASC_Time_Up_WE_Holiday" wird verwendet

Code Auswählen Erweitern

foreach my $h2we ( split( ",", AttrVal( "global", "holiday2we", "" ) ) )

Sehe ich das richtig, dass ich statt einem Holiday Device/File auch einen Dummy mit den Readings state / tomorrow / yesterday anlegen können müsste, den ich per DOIF aus meinen Kalender füttere?
Ich denke da an so etwas in diese Richtung...

Code Auswählen Erweitern


defmod du_Rolladen_FT_Urlaub dummy;
attr du_Rolladen_FT_Urlaub group Kalender;
attr du_Rolladen_FT_Urlaub room 99_Srv.Anwesenheit;

setreading du_Rolladen_FT_Urlaub state none;
setreading du_Rolladen_FT_Urlaub tomorrow test;
setreading du_Rolladen_FT_Urlaub yesterday none;

attr global holiday2we du_Rolladen_FT_Urlaub;

defmod di_UrlaubFeiertag2Dummy.today DOIF (  [cal_Google_SPVP_Urlaub_calview:c-today] > 0 )  (setreading du_Rolladen_FT_Urlaub today ja;;)  DOELSE (setreading du_Rolladen_FT_Urlaub today none;;)
attr di_UrlaubFeiertag2Dummy.today do always
attr di_UrlaubFeiertag2Dummy.today group Kalender
attr di_UrlaubFeiertag2Dummy.today icon helper_doif
attr di_UrlaubFeiertag2Dummy.today room 92_Srv.Automat,99_Srv.Anwesenheit

defmod di_UrlaubFeiertag2Dummy.tomorrow DOIF (  [cal_Google_SPVP_Urlaub_calview:c-tomorrow] > 0 )  (setreading du_Rolladen_FT_Urlaub tomorrow ja;;)  DOELSE (setreading du_Rolladen_FT_Urlaub tomorrow none;;)
attr di_UrlaubFeiertag2Dummy.tomorrow do always
attr di_UrlaubFeiertag2Dummy.tomorrow group Kalender
attr di_UrlaubFeiertag2Dummy.tomorrow icon helper_doif
attr di_UrlaubFeiertag2Dummy.tomorrow room 92_Srv.Automat,99_Srv.Anwesenheit



Zumindest in der Trockenübung sieht das ganz gut aus

Danke Dir für die Meldung mit dem Typo. Habe ich eben mal korrigiert.
Ob Dein DOIF geht weiß ich nicht, es reicht aber wenn der Dummy 0 und 1 als Wert bekommt. Und es reichen da auch die Readings state und tomottow.


Grüße

[FunkOdyssey]

Das mit dem -1 im ASC_BlockingTime_afterManual ist irgendwie nicht so gut.

Das war ja nur eine Idee, dieses Attribut für diesen anderen Zweck zu benutzen.
Gibt es denn vielleicht andere Ansätze?

Wenn ich das auswerte wird er nie fahren, es sei denn ich werte vorher aus ob er heute schon manuell gefahren wurde. Denn wenn er gestern manuell gefahren wurde soll er ja heute fahren.

Ich habe mich mit der Logik in der Programmierung nicht beschäftigt. Ich kann das aber nachvollziehen, dass die Abgrenzung schwierig wird.
Als Anwender sehe ich eigentlich zwei Termine: morgens runter und abends hoch
Und es wäre von Vorteil, wenn man die Möglichkeit hätte, diese Fahrt nachträglich zu korrigieren. Diese Abweichung wird doch später von der Folgefahrt (z.B. abends) wieder geheilt und alles ist wieder gut. Bzw. es würde nicht einmal mehr gefahren werden, weil die Positionsdaten vermutlich schon übereinstimmen.

Es geht also darum das Ihr wenn Ihr heute einmal manuell fahrt der Rolladen HEUTE nicht mehr automatisiert fährt. Aber morgen soll das wieder hinfällig sein, oder heute beim Sonnenuntergang?

Jein. Es soll bis zur nächsten ASC-Runde (morgens oder abends) nichts mehr korrigiert werden.
Ich denke auch, dass dieses Thema spätestens bei der Beschattung im Sommer wieder hochkommen wird und mehr Anwender sich eine manuelle Korrektur wünschen.
Was ist, wenn die Beschattung die Jalousien auf 30% runterfährt; es aber so warm ist, dass man den Raum lieber komplett abdunkeln möchte. Dann würde immer wieder hochgefahren werden.
Oder anders: Es wurde auf 30% beschattet und es ziehen Wolken auf. Dann will ich wieder Licht in den Zimmern haben und fahre die Jalousien wieder hoch. ASC würde dies wieder nach (default: aktuell) 20min korrigieren.

Okay: Man kann die Zeiten über ASC_BlockingTime_afterManual konfigurieren. Aber warum sollte ich dann alle n-Minuten die Jalousien wieder hoch- oder runterfahren. Ich kämpfe den ganzen Tag gegen ASC und die Motoren werden irgendwann den Geist aufgeben.

Ich finde das albern. Du weisst nicht wer wann das letzte mal den Rolladen manuell gefahren hat, und musst Abends beim zu Bett gehen nach der letzten eingestellten Zeit schauen ob überall zu ist. Aber was ist wenn Du früher ins Bett gehst?

Bei uns im Hause sind immer noch die Menschen, die schlussendlich festlegen wie es sein soll. Die ASC-Steuerung verstehe ich nur als Unterstützung und als Vorschlag. Korrigieren soll aber der Mensch immer können.

Wir sind das gewohnt, dass ich manuell korrigierte Öffnung/Schließungen auch selber wieder schließen bzw. öffnen muss. Und spätestens mit der nächsten Fahrt (morgen oder abends) wird das ja sowieso wieder geheilt.

Irgendwie Sinnlos. Dann lieber mit der blockingtime und Ihr stellt sie euch einfach nur groß genug ein. Wegen meiner 6 Stunden oder so.

Damit verschiebe ich das Problem aber nur. Und evtl. vergrößere ich die Fehlerquellen, da ich mich wintertags dann wundere, wieso die Jalousien gar nicht mehr fahren.
Spätestens Öffnen = 10:00 Uhr
Frühestens Schließen = 16:00 Uhr
BlockingTime = 6 Stunden
=> Problem

Selbst wenn ich die Zeiten immer anpassen würde und die Zeiträume gedanklich berücksichtige, würde ich irgendwann definitiv von einer zusätzlichen sporadischen Fahrt überrascht werden.

Wie ich hier schon zuvor erwähnte, sind gerade die sporadischen Fahrten das Problem:

Beispiel 1:
Man hält den Kopf aus dem Fenster (ohne Fensterkontakt) und will sich das Feuerwerk anschauen => ASC beschließt, die Jalousie nach 20min zu schließen. Echt unglücklich.

Beispiel 2:
Man geht durch die Terrassentür nach draussen, die lt. ASC eigentlich unten sein sollte und man manuell geöffnet hat. Plötzlich wird manuell gefahren und man steht in der Kälte.

Beispiel 3:
Man hat die Jalousie abends ein wenig nachkorrigiert, um mehr Lüftungsschlitze zu haben und ASC überschreibt diese Position nach n-Minuten wieder.
Meine Frau drückt abends mehrfach die Taster, um ihre gerade gewünschten Lüftungsschlitze anzufahren. Die würde mir den Hals umdrehen, wenn nach dem neuesten Fix nun die BlockTimeAfterManual aktiv werden.
Das Problem ist ja, dass der Positionswert 20% nicht immer wirklich 20% sind. Je nachdem wie ich die Zeiten gemessen habe, ob der Motor warm ist oder ob die Jalousie öffnet oder schließt, ist die Jalousieposition immer ein wenig abweichend. Das geht weder mit Z-Wave noch mit Homematic wirklich perfekt. Also muss man hin und wieder manuell korrigieren. Die Jalousien werden nur in Sekundenbruchteilen kurz gefahren.
ASC würde dies wieder überschreiben.

Ehrlich gesagt würde mich sicher noch viel mehr Beispiele einfallen.

Mir wäre es wirklich wichtig, dass ASC die manuellen Anpassung auf keinen Fall wieder korrigiert.
Ich kann weder Frau noch Kinder zumuten, mehrmals am Tag die Werte in FHEM neu zu setzen. Und das nur, weil die Straßenlampe vielleicht gerade zu hell durch die Jalousie scheint (Beispiel 4).

[CoolTux]

Ich schaue es mir die Tage noch mal an.
Ausschlaggebend wird das Attribut blockingAfterManual werden. Ich versuchen das dann bei -1 weiter aus zu werten.
Dies kann ich aber wenn nur für alle Fahrten des Modules am selbigen Tag wie die manuelle Fahrt war machen. Es wird dann also auch nie eine Beschattung geben sollte Deine Frau frühs mal kurz den Rolladen bewegt haben.

[majestro84]

Ich schaue es mir die Tage noch mal an.
Ausschlaggebend wird das Attribut blockingAfterManual werden. Ich versuchen das dann bei -1 weiter aus zu werten.
Dies kann ich aber wenn nur für alle Fahrten des Modules am selbigen Tag wie die manuelle Fahrt war machen. Es wird dann also auch nie eine Beschattung geben sollte Deine Frau frühs mal kurz den Rolladen bewegt haben.

Gucke dir sonst doch noch Mal Clunis Steuerung an ich meine da hat das ganz gut funktioniert. Evtl schaffe ich es die Tage auch Mal in den Code zu gucken wie er es realisiert hatte
Gruß Alex

[jobvanes]

Gerade mal ein Update gemacht und jetzt bekomme ich folgende Fehler Meldung:

configfile: AutoShuttersControl: unknown attribute ASC_timeUpHolidayDevice. Type 'attr AutoShuttersControl ?' for a detailed list.
AutoShuttersControl: unknown attribute ASC_timeUpHolidayReading. Type 'attr AutoShuttersControl ?' for a detailed list.

Hab ich etwas verpasst bei der Entwicklung vom Modul? Bis jetzt lief dieses ohne Probleme. 

Mit freundlichen Grüßen,
Job

[CoolTux]

Wenn Du da eine Logik drin siehst bin ich ganz ihr. Alleine nur den Code zu übernehmen geht aber nicht. Ein Skript zu schreiben wo at's und notify's definiert werden ist was anderes wie ein Modul zu entwickeln. Wenn benötige ich also die Logik, nicht den Code.
Habe mal eben geschaut was da für Attribute sind, habe aber diesbezüglich leider nichts weiter gefunden.

[CoolTux]

Gerade mal ein Update gemacht und jetzt bekomme ich folgende Fehler Meldung:

configfile: AutoShuttersControl: unknown attribute ASC_timeUpHolidayDevice. Type 'attr AutoShuttersControl ?' for a detailed list.
AutoShuttersControl: unknown attribute ASC_timeUpHolidayReading. Type 'attr AutoShuttersControl ?' for a detailed list.

Hab ich etwas verpasst bei der Entwicklung vom Modul? Bis jetzt lief dieses ohne Probleme. 

Mit freundlichen Grüßen,
Job

Das ist voll okay. Ist eine Warnung. Die beiden Attribute fallen weg und Du hast sie wohl gesetzt gehabt. Aber die waren eh ohne Funktion.

[majestro84]

Wenn Du da eine Logik drin siehst bin ich ganz ihr. Alleine nur den Code zu übernehmen geht aber nicht. Ein Skript zu schreiben wo at's und notify's definiert werden ist was anderes wie ein Modul zu entwickeln. Wenn benötige ich also die Logik, nicht den Code.
Habe mal eben geschaut was da für Attribute sind, habe aber diesbezüglich leider nichts weiter gefunden.

Ja mir ging es auch um die Logik dahinter. Aber ich meine wenn ich nach dem schließen am Abend die Rolllade bewegt habe müsste ich sie später alleine schließen. Sie wurde dann von Skript nicht mehr gefahren. Erst dann am morgen wieder zum öffnen oder wenn es am Tag war zur Beschattung. So in etwa hätte ich mir dann das mit der -1 vorgestellt das ASC erst beim nächsten ASC Event (Abends, Morgens, Beschattung, self-defense usw) wieder fährt.

[CoolTux]

Ja mir ging es auch um die Logik dahinter. Aber ich meine wenn ich nach dem schließen am Abend die Rolllade bewegt habe müsste ich sie später alleine schließen. Sie wurde dann von Skript nicht mehr gefahren. Erst dann am morgen wieder zum öffnen oder wenn es am Tag war zur Beschattung. So in etwa hätte ich mir dann das mit der -1 vorgestellt das ASC erst beim nächsten ASC Event (Abends, Morgens, Beschattung, self-defense usw) wieder fährt.

Das ist auch beim Modul so. Nach schließen bewegen sich die Rolläden auch nicht mehr. Ausserdem das Fenster wird geöffnet oder man hat Brightness aktiv und ist noch zwischen frühste Zeit und späteste Zeit.

[Beetle2003]

Hallo,

ich habe alle Homematik Rolloaktoren auf ASC 2 gestellt. Das Rollo an der Wohnzimmertür steht auf o da es nicht gesteuert werden soll.

Regelmässig erhalte ich folgende Meldung:
please set attribute ASC with value 1 or 2 in all auto controlled shutter devices and then execute 'set DEVICENAME scanForShutters'

Was kann ich dagegen machen? Woher kommt die Meldung?

[CoolTux]

Nimm bitte alle event-on-* Attribute aus dem ASC Device und speichere ab. Danach Neustart bitte machen.

[majestro84]

Das ist auch beim Modul so. Nach schließen bewegen sich die Rolläden auch nicht mehr. Ausserdem das Fenster wird geöffnet oder man hat Brightness aktiv und ist noch zwischen frühste Zeit und späteste Zeit.

OK das heißt bei Brightness muss ich es über ASC_BlockingTime_afterManual regeln das ASC aus der spätesten Zeit raus ist richtig? Bei Astro wäre dann ASC_BlockingTime_afterManual eigentlich für diesen Fall egal.
Gruß Alex

[CoolTux]

Korrekt.

[Dersch]

Ich muss mal wegen dem SelfDefense nachrfragen denn ich glaube das habe ich nicht kapiert. Wollte es heute mal Testen und nix ging runter obwohl der Türkontakt geöffnet war.

Ich habe im Modul Device als ASC_residentsDevice den Namen meines Residents Moduls angegeben. Und unter ASC_residentsDeviceReading presence.
selfDefense steht auf "on"

Muss ich nun im Rolladendevice nochmals das Resident Modul angeben oder nicht? Oder ist das nur der Fall wenn abweichend vom Moduldevice ein anderes Resident Modul greifen soll?

Wie ist der Ablauf im ASC Modul wenn selfDefense greift? Schaut er auf das Resident Modul und prüft nach triggern auf "absent" welcher Türsensor auf "open" steht?

Code Auswählen Erweitern

ASC_ShuttersPlace - window/terrace - Wenn dieses Attribut auf terrace gesetzt ist, das Residence Device in den Status "done" geht und SelfDefence aktiv ist, wird das Rollo geschlossen

Warum "done"? Du meinst "gone" oder?