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

[no_Legend]

Das müsstest Du die Infos welche bei einem get kommen noch auswerten.
Persönlich würde ich Dir aber die Vorgehensweise von Beta-User ans Herz legen. Ist glaube auch für Dich die einfachste. Und es passiert ja auch automatisiert.

Das mit dem Betreff habe ich gestern schon im Kalender bereich geklärt.
Bin noch nicht dazu gekommen es zu testen.

Das vorgehen mit dem holiday2we ist mir im großen und ganzen Klar.
Muss der Dummy zwingend "tommorow" enthalten?
Was hat das für Auswirkungen wenn es das nicht gibt?

[Beta-User]

Das vorgehen mit dem holiday2we ist mir im großen und ganzen Klar.
Muss der Dummy zwingend "tommorow" enthalten?
Was hat das für Auswirkungen wenn es das nicht gibt?

1. Warum fragst du dann nochmal nach, wenn es im großen und ganzen klar ist?!?
2. tomorrow wird m.E. benötigt, um an den Tagen vor WE (bzw. dem Ferientag) die timer für den nächsten Tag korrekt zu berechnen. So gehen die Rolläden halt ggf. zu früh auf...
Es macht daher Sinn, "rechtzeitig" auch das tomorrow-reading zu setzen.  Ggf. z.B. durch ein at am Tagesbeginn (vor den ersten timerneuberechnungen für den Folgetag), das die Kalendertermine für den kommenden Tag abfragt und dann ggf. in tomorrow einträgt...

Aber dann kannst du eigentlich auch einfach ein holiday erstellen und das vorhandenen code machen lassen .

[Alcamar]

Ich habe n Jalousien und davon eine auf attr ASC_Partymode off gesetzt und damit vom Partymodus ausgeschlossen. Das ASC Device war mit partyMode on definiert.

Beim Hochfahren der Jalousien hätte ich erwartet, dass Partymode gar nicht greift. Aber da habe ich mich getäuscht, vermutlich weil ich die Funktion nur beim Runterfahren benötige. Die Jalousie, die beim Partymodus nicht mitmachen soll, ist gefahren. Alle anderen blieben unten. Bis dahin ist das Verhalten logisch, wenn auch von mir nicht erwartet.
Daraufhin habe ich mir die nächsten geplanten Fahrten angeschaut (showShuttersInformations). Dort standen in der Spalte "Next DriveUp" die Uhrzeiten des Folgetags (Samstag und damit Wochenende) aber das Datum von heute.
Das ist aus meiner Sicht ein Bug. Konsequenterweise müssten dort nun Datum und Uhrzeiten der Wochenendefahrt stehen, oder?

Da der Partymodus, wie oben beschrieben, nicht das gewünschte Verhalten zeigte, habe ich es im ASC Device wieder deaktiviert (set PartyMode off).
Ich nahm an, dass nun die letzten ausgefallenen Fahrten (hoch) sofort nachgeholt werden.
Tatsächlich fuhr aber die Jalousie, die vom Partymodus ausgeschlossen ist, wieder runter.
Alle Jalousien fuhren danach mit der "buggi-Zeit" hoch, also Freitag mit Uhrzeiten vom Wochenende.

Ich nutze das Tool mit wachsender Begeisterung erst seit drei Tagen.

[CoolTux]

Das mit dem Betreff habe ich gestern schon im Kalender bereich geklärt.
Bin noch nicht dazu gekommen es zu testen.

Das vorgehen mit dem holiday2we ist mir im großen und ganzen Klar.
Muss der Dummy zwingend "tommorow" enthalten?
Was hat das für Auswirkungen wenn es das nicht gibt?

Für das ASC Device muss zwingend ein tomorrow rein, sonst kann er nicht darauf achten ob morgen ein sunriseTimeWeHoliday genommen werden soll oder nicht. Da ja die Berechnung der morgendlichen Zeit am Abend davor erfolgt.

[Alcamar]

... und nur weil ich am meckern bin... 
in wiki steht bei den Attributen in den Rolladendevices  bei ASC_ShuttersPlace
...und das Residence Device in den Status "done" geht... muss wohl gone heißen. Versteht man trotzdem.

Wenn es gewünscht ist bzw. nicht nervt, kann ich gerne das eine oder andere Korrekturlesen. Mit technischer Unterstützung kann ich weniger helfen. Aber testen kann ich vielleicht auch das eine oder andere.

Und an dieser Stelle ein großes Dankeschön für das Modul!

[no_Legend]

1. Warum fragst du dann nochmal nach, wenn es im großen und ganzen klar ist?!?
2. tomorrow wird m.E. benötigt, um an den Tagen vor WE (bzw. dem Ferientag) die timer für den nächsten Tag korrekt zu berechnen. So gehen die Rolläden halt ggf. zu früh auf...
Es macht daher Sinn, "rechtzeitig" auch das tomorrow-reading zu setzen.  Ggf. z.B. durch ein at am Tagesbeginn (vor den ersten timerneuberechnungen für den Folgetag), das die Kalendertermine für den kommenden Tag abfragt und dann ggf. in tomorrow einträgt...

Aber dann kannst du eigentlich auch einfach ein holiday erstellen und das vorhandenen code machen lassen .

Zu 1. Nur im großen und ganzen, nicht vollständig. 
zu 2. Dein Code ist nicht schlecht, also nicht falsch verstehen, nur will ich definitiv nicht 4 Googlekalender führen müssen.

Für mich alleine kein Problem, aber nicht wenn du es der Frau noch erklären musst, was wie und wann.

Für das ASC Device muss zwingend ein tomorrow rein, sonst kann er nicht darauf achten ob morgen ein sunriseTimeWeHoliday genommen werden soll oder nicht. Da ja die Berechnung der morgendlichen Zeit am Abend davor erfolgt.

Danke für den Hinweis.
Das mit dem Auswerten des Kalenders mit mehreren Betreffs hab ich gestern im Forum schon geklärt.
Allerdings nur für Aktuelle Termine. Das mit dem Tomorrow muss halt nun noch irgendwie da mit rein.
Wie keine Ahnung, mal schauen.

[Beta-User]

@no_legend:
Wenn es individuell gesteuert werden soll, solltest du nicht holiday2we nehmen, sondern jeweils einen residents-Status und den dann halt passend setzen.

Ansonsten benötigt mein code einen Kalender, der muß aber nicht zwingend nur die Feriendaten beinhalten. Was ich nutze, ist ein gemeinsamer Kalender mit meiner Frau (sie hat also 2), und in dem gemeinsamen stehen dann eben gemeinsame sonstige Termine, Ferien (en Block importiert ohne Benachrichtigungen) und Müllabfuhr (ebenfalls en Block importiert) drin. Es wird dann eben gefiltert, was jeweils benötigt wird.

Es wäre aber z.B. kein größeres Problem, nacheinander mehrere Kalender abzufragen, das daraus kommende Array dann vor der Endauswertung an das Auswertungs-Array anzuhängen und dann erst die Endauswertung zu machen.

Wenn du interessiert bist, können wir das gerne gesondert diskutieren (in deinem Thread oder in meinem Ical2holiday-Thread). Wenn es klappt, übernehme ich das dann gerne auch ins Wiki . Scheint ja v.a. im Zusammenhang mit der ASC ein allg. interessierendes Thema zu sein...

[CoolTux]

Code Auswählen Erweitern

CommandGet(undef,$calDev.' events filter:mode=="upcoming"');

liefert Dir zukünftige Termine. Der einfachheithalber würde ich da aber die Ausgabe begrenzen mit dem entsprechenden Attribut auf einen Tag.

Und bei CommandGet(undef,$calDev.' events filter:mode=="start"'); musst Du auf Langzeittermine noch achten. Also Ganztagstermine welche über mehrere Tage gehen.

Code Auswählen Erweitern

$start = CommandGet(undef,$calDev.' events filter:mode=="start"');
if ( ($start =~ m#(\d+)h# and $1 > 24) or ($start =~ m#(\d+)d# and $1 > 1) or length($upcoming) > 0 );

[no_Legend]

@no_legend:
Wenn es individuell gesteuert werden soll, solltest du nicht holiday2we nehmen, sondern jeweils einen residents-Status und den dann halt passend setzen.

Ansonsten benötigt mein code einen Kalender, der muß aber nicht zwingend nur die Feriendaten beinhalten. Was ich nutze, ist ein gemeinsamer Kalender mit meiner Frau (sie hat also 2), und in dem gemeinsamen stehen dann eben gemeinsame sonstige Termine, Ferien (en Block importiert ohne Benachrichtigungen) und Müllabfuhr (ebenfalls en Block importiert) drin. Es wird dann eben gefiltert, was jeweils benötigt wird.

Es wäre aber z.B. kein größeres Problem, nacheinander mehrere Kalender abzufragen, das daraus kommende Array dann vor der Endauswertung an das Auswertungs-Array anzuhängen und dann erst die Endauswertung zu machen.

Wenn du interessiert bist, können wir das gerne gesondert diskutieren (in deinem Thread oder in meinem Ical2holiday-Thread). Wenn es klappt, übernehme ich das dann gerne auch ins Wiki . Scheint ja v.a. im Zusammenhang mit der ASC ein allg. interessierendes Thema zu sein...

Dann machen wir es ja doch eigentlich gleich.
Abfall hab ich seperat.

Wir machen dazu mal besser einen neuen Thread auf.
Denke es wird sinnvoll sein im Kalender-Bereich zu machen oder?

[Beta-User]

Wir machen dazu mal besser einen neuen Thread auf.
Denke es wird sinnvoll sein im Kalender-Bereich zu machen oder?

Den Beitrag dazwischen von CoolTux hast du gesehen?

Ansonsten: Wenn Fragen/Anmerkungen zu meinem Calendar2holiday-Dingens sind: Hier.
Wenn es darum geht, deine Dummy's zu steuern: bleib in dem bereits von dir eröffneten Thread mit Otto, ich klinke mich ggf. ein.

Allg. nochmal: Du solltest erst mal etwas mit dem Calendar-Modul bzw. dessen Rückmeldungen spielen und experimentieren, also sowas in die Eingabezeile geben:

Code Auswählen Erweitern

get <Kalendername> events format:custom="4 $T1 $T2 $S" timeFormat:"%m-%d" limit:count=10 filter:field(summary)=~".*[fF]erie.*"
Da einfach mal das eine oder andere ändern, weglassen, die möglichen Ausgabeparameter (commandref: variable meaning) testen usw....
Erst dann wird m.E. die jeweilige Auswertelogik dazu auch verständlich.

Und noch eine Bitte:
Lies vor neuen Posts bitte immer auch nochmal durch, was bereits geschrieben steht. Nach meinem persönlichen Geschmack überliest du recht viel und fragst zu schnell nach. Das wirkt jedenfalls auf mich nicht unbedingt ermunternd...

[dk3572]

Bezüglich Kalender habe ich nun eine für mich zufriedenstellende Lösung gefunden.

Es wird dabei bleiben das die zusätzlichen Kalender, also nicht holiday, am besten als Dummy abgebildet werden und sowohl im Reading state als auch im Reading tomorrow mit 0 oder 1 befüllt werden.
Da ich für jedes Thema (Urlaub,Ferien u.s.w.) einen eigenen Kalender habe, reicht es mir zu wissen ob der Kalender ein Ereignis meldet oder nicht. Mich interessiert nicht was das für ein Ereignis ist. Daher habe ich die Kalender wie folgt konfiguriert

Code Auswählen Erweitern


Internals:
   CHANGED   
   DEF        ical url https://URL/basic.ics 86400
   NAME       calendarUrlaubMarko
   NOTIFYDEV  global
   NR         28
   NTFY_ORDER 50-calendarUrlaubMarko
   STATE      triggered
   TYPE       Calendar
   READINGS:
     2018-12-30 06:56:29   calname         Urlaubskalender
     2018-12-30 06:56:29   lastUpdate      2018-12-30 06:55:32
     2017-12-29 09:18:43   modeAlarm       
     2018-12-27 00:00:00   modeAlarmOrStart 2r6pfpqgjdci3is7ptjnm67v3tgooglecom
     2017-12-29 09:18:43   modeAlarmed     
     2018-12-27 19:39:42   modeChanged     
     2018-12-30 06:56:29   modeEnd         dc2ad49235d4490e870c1251861f4c82;309r0ius83ghkbkeebc6d6mm2agooglecom;21ku868ra7cgj4rsd0lu5cq49hgooglecom;6a9rg14a2ikfg5drtsb94j3bd0googlecom;2aa29ktsroucu3jrgucrt92o7bgooglecom;78ike8hnt4qv3dprakav0vvukngooglecom;006ddpeskbqieebohknbmvceeegooglecom;30cs42ua3pjs9bsmipvfikit0ugooglecom
     2018-12-25 19:40:15   modeEnded       
     2018-12-27 00:00:00   modeStart       2r6pfpqgjdci3is7ptjnm67v3tgooglecom
     2018-12-27 19:39:42   modeStarted     
     2018-12-30 06:56:29   modeUpcoming    3rc5kgbbljpeegb4n0hvotrl7ggooglecom;1oh2bqk8o4f81m656s3d3b3qbigooglecom;6m4436usnfu5ibv95a8pf7oajugooglecom;12qefmcrdtqs1ap3iutmvvrs5dgooglecom;6sj5gm88ht1l2eembmf859sr7ggooglecom
     2018-12-30 06:56:29   nextUpdate      2018-12-31 06:55:32
     2018-12-30 06:56:29   nextWakeup      2018-12-31 06:55:32
     2018-12-30 06:56:29   state           triggered
Attributes:
   alias      UrlaubMarko
   event-on-update-reading state
   group      Urlaub
   hideLaterThan 1d
   room       Kalender
   update     async

Entscheidend ist event-on-update-reading state und hideLaterThan 1d. Durch hideLaterThan 1d bekomme ich bei einem get Abruf nur den Termin für den Folgetag und nicht für mehrere folgende Tage angezeigt. Das ist unser tomorrow.
Auch wichtig für den automatisierten Ablauf ist der alias welcher den Kalendernamen ohne das Wort calendar enthalten muß.
Als nächstes habe ich einen Dummy angelegt

Code Auswählen Erweitern


Internals:
   NAME       dummyUrlaubMarko
   NR         63
   STATE      1
   TYPE       dummy
   READINGS:
     2018-12-30 06:56:29   state           1
     2018-12-30 08:08:46   tomorrow        1
Attributes:
   alias      Urlaub Marko
   event-on-change-reading state,tomorrow
   group      Urlaub
   readingList tomorrow,state
   room       Kalender
   setList    tomorrow:0,1 state:0,1

Der Dummy Name wiederum muss den Alias Namen vom Kalenderdevice enthalten und vorneweg das Wort "dummy".

Nun erstellen wir noch ein Notify welches auf alle unsere Kalender (ja ich habe mehrere) triggert

Code Auswählen Erweitern


Internals:
   DEF        calendar.*:triggered { calendarEvents($NAME) }
   NAME       notifySetCalendarDummys
   NOTIFYDEV  calendar.*
   NR         64
   NTFY_ORDER 50-notifySetCalendarDummys
   REGEXP     calendar.*:triggered
   STATE      2018-12-30 07:56:12
   TRIGGERTIME 1546152972.28106
   TYPE       notify
   READINGS:
     2018-12-30 06:55:21   state           active
Attributes:
   room       Kalender

und eine Sub auf ruft.

Code Auswählen Erweitern


sub calendarEvents($) {
    my $calDev  = shift;
    my $value = 0;
    my $start = CommandGet(undef,$calDev.' events filter:mode=="start"');
    my $upcoming = CommandGet(undef,$calDev.' events filter:mode=="upcoming"');

    CommandSet(undef,'dummy'.AttrVal($calDev,'alias',undef).' '.(length($start) > 0 ? 1 : 0) );

    $value = 1 if ( ($start =~ m#(\d+)h# and $1 > 24) or ($start =~ m#(\d+)d# and $1 > 1) or length($upcoming) > 0 );
    CommandSet(undef,'dummy'.AttrVal($calDev,'alias',undef).' tomorrow '.$value);
}


Wird diese Sub aufgerufen wird automatisch je nach Ergebnis der CommandGet Abrufe des Kalenders unsere Dummy Readings state und tomorrow mit 0 oder 1 befüllt..


Und da wir die Dummys ja im global Device im Attribut we2holiday eingetragen haben wird der Status auch entsprechend im ASC ausgewertet.



Grüße


Nachtrag: Ich musste die Sub noch anpassen. Es gibt durchaus Tage wo nichts in upcoming steht aber dennoch der Folgetag ein Termin hat. Serientermine, da steht dann die Anzahl der Stunden oder Tage in start.

Hallo  CoolTux,

auch ich muss wg. der Kalender Integration noch mal nachhaken.

Ich habe deine Lösung 1:1 umgesetzt. Funktioniert soweit.
Aber, wenn ich z.B. einen Termin anlege der von Mo (07.) - heute (11.) geht, wird tomorrow im dummy  auf 1 gesetzt.
Ist das ein Fehler in deinem Code oder mache ich irgendwo einen Fehler?

Danke und VG Dieter

[CoolTux]

Hallo Dieter,

So soll es ja auch sein. Wenn ein Termin ganztags über mehrere Tage geht muss ja auch tomorrow gesetzt werden.

[dk3572]

Hallo Dieter,

So soll es ja auch sein. Wenn ein Termin ganztags über mehrere Tage geht muss ja auch tomorrow gesetzt werden.

das sehe ich anders.
Wenn ich mir z.B. Urlaub eintrage bis heute (11.) und ich morgen arbeiten müsste, darf tomorrow nicht 1 sein.
Oder mache ich einen Denkfehler?
Wechselt tomorrow nach der Fahrt/Berechnung heute abend auf 0?

[CoolTux]

Es sollte aber für tomorrow keine 1 kommen wenn der Urlaub nur bis heute geht.
Wann hat denn die Aktuallisierung statt gefunden und somit der lauf des Notify

[dk3572]

Es sollte aber für tomorrow keine 1 kommen wenn der Urlaub nur bis heute geht.
Wann hat denn die Aktuallisierung statt gefunden und somit der lauf des Notify

Habe es eben zum x-ten mal getestet.
1. Ganztägiger Termin heute (11.) = state 1, tomorrow 0
2. Ganztägiger Termin morgen (12.) = state 0, tomorrow 1
3. Mehrtägiger Termin ab heute (11.) = state 1, tomorrow 1
4. Mehrtägiger Termin bis heute (11.) = state 1, tomorrow 1

Nach jeder Änderung im Google Kalender habe ich im Kalender Modul ein reload gemacht.
Bei 1 - 3 ist ja auch alles korrekt.
Nur bei 4 scheint doch wohl ein Fehler vorzuliegen.

Danke auch für deine Mühe.