[ASC] Variable driveUp / Down zeiten aus einem Kalender übernehmen

[flummy1978]

Hallo zusammen,

in Anlehnung an die Anfänge aus dem ASC Thread (Ab Beitrag #425, hab ich das hier mal ausgegliedert. Ich denke es ist im Sinne aller, dass wir den ASC Beitrag nicht zuspammen. Jetzt geht es ja nur noch sekundär um ASC selbst, sondern vielmehr die Zusammenarbeit mit Perl / ASC und Calendar

@ms_steini,
@edition
@sonstige_Nachtschicht oder sonstige variable Zeiten interessierte

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

Ich hab Eure beiden Vorschläge mal zusammen genommen und etwas rumgebastelt. Was ich nicht hinbekomme ist in dem Einzeiler noch den Unterschied zu erkennen ob ich wirklich eine Zeit zurückbekomme (falls der Eintrag im Kalender mal nicht da ist) - Vielleicht kann mir hier jemand ja helfen (Wird dann derzeit noch nicht abgefangen) **

Code Auswählen Erweitern

{ (fhem('get fhem_cal events format:custom="$T1" limit:from=0d,to=+1d filter:field(summary)=~"SZ1"')) }
Das hab ich jetzt in meinem TestRollo in das Attribut "ASC_Time_Up_Early" eingefügt. ASC_Time_Up_Late ist dann eine lange Zeit nach der im Kalender eingetragenen.

Hinzu ist es notwendig im Calender Device noch folgendes Attribut einzugestellen:

Code Auswählen Erweitern

defaultTimeFormat %H:%M

$T1 gibt dann HH:MM zurück
SZ1 Heisst der Kalendereintrag bei mir (weil ich ggf für mehrere Rollos variable Zeiten einstellen möchte)
filter +1 Tag (ich meine auch dass edition richtig liegt mit dem erstellen des Timers NACH der driveUp Zeit)

Dann habe ich für das entsprechende Device die Timer neu erstellt und es wird dort aktuell die Zeit aus dem Kalender für morgen angezeigt. Nun bin ich mal gespannt ob das morgen auch korrekt fährt. Dann muss ich nur noch die Zeiten an meine Schichten anpassen Vielleicht hilft es ja jemandem anderen auch Sieht also soweit korrekt aus.....

Bisher noch nicht gelöst:

Was mich massivst stört und ich die Quelle noch nicht gefunden habe sind unzählige Einträge im Log:

Code Auswählen Erweitern


2020.08.05 15:36:39.436 3: get fhem_cal events format:custom="$T1" limit:from=0d,to=+1d filter:field(summary)=~"SZ1" : 11:00
2020.08.05 15:36:39.439 3: get fhem_cal events format:custom="$T1" limit:from=0d,to=+1d filter:field(summary)=~"SZ1" : 11:00
2020.08.05 15:36:39.444 3: get fhem_cal events format:custom="$T1" limit:from=0d,to=+1d filter:field(summary)=~"SZ1" : 11:00
2020.08.05 15:36:39.447 3: get fhem_cal events format:custom="$T1" limit:from=0d,to=+1d filter:field(summary)=~"SZ1" : 11:00
usw
Im betroffenem Rollo, ASC Device UND im Calendar Device Verbose 2 einzustellen ware semi - erfolgreich (gefühlt weniger, aber noch nicht alle Meldungen weg)

Falls jemand für ** eine einfache Lösung weiß bin ich nicht abgeneigt. Mir fehlt da ein einfaches Verständniss wie ich auf $T1 aus der calendar Abfrage zurückgreifen kann. Sobald ich das weiß wäre

Code Auswählen Erweitern

{ (fhem('get fhem_cal events format:custom="$T1" limit:from=0d,to=+1d filter:field(summary)=~"SZ1"') =~ /\d\d:\d\d/ ? "x?x?x?" : "14:00") } wahrscheinlich dann die Lösung?

Viele Grüße
Andreas

[Otto123]

Was mich massivst stört und ich die Quelle noch nicht gefunden habe sind unzählige Einträge im Log:

Hallo Andreas,

aus meiner Sicht fragst Du den Kalender mit hoher Frequenz ab (alle 3 ms ). Verhindern kannst Du die Einträge im Log mit einer ,1 am Ende des Aufrufes.

Code Auswählen Erweitern

fhem('get ....',1)
Aber die Abfragefrequenz solltest Du ändern.

Gruß Otto

[flummy1978]

Hey Otto,

vielen herzlichen Dank für diese mega turbo Antwort

OK Eintrag verhindern - Nein lieber nicht (aber gut zu wissen, wie es ginge) Wenn der Befehl ausgeführt wird, darf es auch im Log auftauchen.

Die Frage ist, WARUM wird es alle 3 Sek abgefragt. Es kann NUR das ASC drauf zugreifen, weil ich diesen "get fhem_cal..... - " Eintrag NUR in dem entsprechendem Attribut oben stehen habe

Kurzer ASC_DEBUG Log, bestätigt leider meine Befürchtung:

Code Auswählen Erweitern

ASC_DEBUG!!! 2020.08. 5 16:23:35 - EventProcessingShadingBrightness: dum_JALOU_Gang - Nummerischer Brightness-Wert wurde erkannt. Der Brightness Average Wert ist: 66418 RainProtection: unprotected WindProtection: unprotected
2020.08.05 16:23:35.756 3: get fhem_cal events format:custom="$T1" limit:from=0d,to=+1d filter:field(summary)=~"SZ1" : 11:00
2020.08.05 16:23:35.758 3: get fhem_cal events format:custom="$T1" limit:from=0d,to=+1d filter:field(summary)=~"SZ1" : 11:00

ASC_DEBUG!!! 2020.08. 5 16:23:35 - FnIsDay: dum_JALOU_Gang Allgemein: 1
2020.08.05 16:23:35.763 3: get fhem_cal events format:custom="$T1" limit:from=0d,to=+1d filter:field(summary)=~"SZ1" : 11:00
2020.08.05 16:23:35.766 3: get fhem_cal events format:custom="$T1" limit:from=0d,to=+1d filter:field(summary)=~"SZ1" : 11:00
2020.08.05 16:23:35.771 3: get fhem_cal events format:custom="$T1" limit:from=0d,to=+1d filter:field(summary)=~"SZ1" : 11:00
2020.08.05 16:23:35.774 3: get fhem_cal events format:custom="$T1" limit:from=0d,to=+1d filter:field(summary)=~"SZ1" : 11:00

ASC_DEBUG!!! 2020.08. 5 16:23:35 - FnIsDay: dum_JALOU_Gang Allgemein: 1
2020.08.05 16:23:35.778 3: get fhem_cal events format:custom="$T1" limit:from=0d,to=+1d filter:field(summary)=~"SZ1" : 11:00
2020.08.05 16:23:35.781 3: get fhem_cal events format:custom="$T1" limit:from=0d,to=+1d filter:field(summary)=~"SZ1" : 11:00

ASC_DEBUG!!! 2020.08. 5 16:23:35 - ShadingProcessing: dum_JALOU_Gang - Übergebende Werte - Azimuth:237.7, Elevation: 42.8, Brightness: 66418, OutTemp: 30, Azimut Beschattung: 110, Azimut Endschattung: 315, Ist es nach der Zeitblockadezeit: NEIN, Das Rollo ist in der Beschattung und wurde manuell gefahren: NEIN, Ist es nach der Hälfte der Beschattungswartezeit: JA
2020.08.05 16:23:35.782 4: AutoShuttersControl (AUTO_RolloSteuerung) - Shading Processing, Rollladen: dum_JALOU_Gang Azimuth: 237.7 Elevation: 42.8 Brightness: 66418 OutTemp: 30

Sehr sehr ungünstig ... Sobald ein Event  das entsprechende Device erreicht, fragt er also auch die Zeiten ab 

Hier wäre wohl CoolTux oder andere Supercracks was Perl angeht gefragt, mit der Frage ob das vermeidbar wäre.......

Grüße
Andreas

[Beta-User]

Hm, die Abfragehäufigkeit kommt vermutlich aus dem ASC-Modul; das muß ja für jeden Rollladen entsprechend berechnet werden, und ich bin überfragt, wie oft das im laufenden Betrieb pro Rollladen gemacht wird. Das läßt sich wenn, dann nur sehr schwer ändern!

Was das Rückgabeformat angeht: Das kann man auch explizit angeben. Aus meinem "mache holiday-Code":

Code Auswählen Erweitern

my @holidaysraw = split(/\n/,(fhem 'get Familienkalender events format:custom="4 $T1 $T2 $S" timeFormat:"%m-%d" limit:count=10 filter:field(summary)=~".*[fF]erie.*"'));;\ Dann kannst du auch feststellen, ob $holidaysraw[0] existiert... 
Generell glaube ich immer noch, dass für solche Anwendungsfälle ROOMMATE-basierte Varianten besser/effizienter sind. Aus dem anderen Thread hatte ich den Einwand mitgenommen, dass du keinen Schalter nutzen willst, und lieber eine automatisierte Lösung via Kalender haben willst. Wie wäre es mit folgendem Konzept:

Reagiere auf das calendar-Event "Nachtschicht endet" (es gibt irgendwo im Forum ein "Tante-Erna-kommt zu Besuch"-Code-Beispiel von betateilchen dazu). Setze deinen ROOMMATE dann (entsprechend der üblichen Zeiten) auf "komme nach hause", "geh schlafen" und "schlafe", und irgendwann dann auch wieder auf "wach"; das ganze Timer-basiert, und der ROOMMATE bekommt dann noch (bis zum Aufwachen) ein Reading "nach Nachtschicht" als Flag, das alle möglichen Routinen abschaltet, die Querschießen könnten?
Hätte auch den Vorteil, dass du beim entsprechenden Schichtende-Event noch weitere Infos auswerten könntest, die ggf. zusätzlich zu berücksichtigen wären, v.a. Urlaub oder Freischichten.

Just my2ct.

[Otto123]

Falsche Zeiteinheit! Es sind nicht 3 sekunden es sind 3 milli sekunden! Es ergibt ca300 Abfragen pro sekunde! Da entsteht schon etwas unnütze Wärme
2020.08.05 16:23:35.771
2020.08.05 16:23:35.774

Irgendwas produziert also Events in der Frequenz, ich denke da läuft eine wilde Schleife.

[Beta-User]

Ob Events produziert werden, ist eine andere Frage, es ist nur eben vermutlich so, dass die Frage häufig geklärt werden muß, ob grade Tag oder Nacht ist...
(Das sollte man sich mal intensiver ansehen, scheint mir insgesamt ineffizient gelöst zu sein, was aber auch damit zu tun hat, dass die Diskussion über "Perl erlauben" in den Attributen recht neu sein dürfte; allerdings bin ich mir nicht so ganz sicher, ob das auch indirekt ähnlich läuft, wenn man mit Astro steuert).

[flummy1978]

Aloha,

vielen herzlichen Dank für Eure Beteiligung an meinen Gedankengängen, bzw dem Ablauf

Schade, das hätte jetzt so schön sein können..... Grundsätzlich hätte es sehr gut funktioniert, aber ein Aufruf alle 0,003 sek ist mir dann doch etwas arg viel. Was allerdings auch meine Vermutung von annodazumal bestätigt wird, als ich mal in anbetrach des Debug Logs festgestellt hab, dass die Abfrage: isDay imho etwas arg oft aufgerufen wurde. In diesem fall wirds wohl dann nochmal bestätigt. Ganz unabhängig von "meinem" Perl Aufruf in dieser Zeile der dann 2 x 4x und 2x innerhalb von <20 msek aufgerufen wird, wird eben in der gleichen Zeit auch 2 x die FnIsDay vom ASC aufgerufen. Ich denke hier geht doch wirklich einiges an Effizienz verloren ;(

Ich muss ehrlichweise sagen, dass ich dort auch gerne mal ein wenig suchen würde um vielleicht einen Teil zu finden. Aber mit der Umstellung des Modules in der 10er Version ist es für jemanden unerfahreneren noch schwieriger geworden den Coden nachzuvollziehen. Ich kann manche Funktionen z.B. gar nicht wiederfinden -.- 
Aber alleine die getTimeUpEarly (was wohl dann im msek Takt die Meldungen produziert) wird allein im Helper Modul für diverse Sachen 15 x insg aufgerufen. Da wird natürlich ein Schuh draß, dass ich nach einem Einzigen Event bereits 8 Einträge davon habe....

Was das Rückgabeformat angeht: Das kann man auch explizit angeben. Aus meinem "mache holiday-Code":

Code Auswählen Erweitern

my @holidaysraw = split(/\n/,(fhem 'get Familienkalender events format:custom="4 $T1 $T2 $S" timeFormat:"%m-%d" limit:count=10 filter:field(summary)=~".*[fF]erie.*"'));;\ Dann kannst du auch feststellen, ob $holidaysraw[0] existiert... 
Generell glaube ich immer noch, dass für solche Anwendungsfälle ROOMMATE-basierte Varianten besser/effizienter sind. Aus dem anderen Thread hatte ich den Einwand mitgenommen, dass du keinen

Das werde ich mir nochmal anschauen und sicherlich auch für andere Auswertungen nutzen können. Vielen Dank für das Beispiel Beta

Reagiere auf das calendar-Event "Nachtschicht endet" (es gibt irgendwo im Forum ein "Tante-Erna-kommt zu Besuch"-Code-Beispiel von betateilchen dazu).....

Ich hab mich immer etwas vor den Roommate  Möglichkeiten gedrückt, weil ich einfach "Angst" hatte, durch eine falsche Einstellung, oder fehlerhaften residents Zustand auf einmal die Rolläden mitten in der Nacht ein eigenleben entwickeln könnten. Nachdem ich aber mit dem G-Tag bereits sehr zuverlässige Anwesenheitskontrolle hab, wird es wohl doch darauf zurückführen, dass ich es über eine Roommate + Kalender Kombination lösen werde / muss.

Viele Grüße
Andreas