Betatester für neues Modul AutoShuttersControl gesucht!

[CoolTux]

Ich habe da ein bisschen was zu geschrieben. Denke das passt soweit.
Danke für Deine Arbeit mit am Wikieintrag.

[FunkOdyssey]

Version 0.1.48 habe ich soeben ins Git geladen.
Unterstützt wird nun Wochenendsteuerung über das Rolladen Attribut AutoShuttersControl_Time_Up_WE_Holiday und im Moduldevice der set Befehl sunriseTimeWeHoliday.
Wenn sunriseTimeWeHoliday auf on steht und man das Attribut AutoShuttersControl_Time_Up_WE_Holiday am Rolladen ändert, wird automatisch der neue Timer gesetzt.
In der Wochenendsteuerung ist auch we2holiday mit enthalten. Extra Kalender folgen noch.

Ehrlich gesagt verstehe ich das derzeit noch nicht.
Ich sehe im Code, dass du unter "Global" das holiday2we-Attribut prüfst. In meinem "holiday"-Device habe ich ja bereits stehen, dass morgen ein Wochenende sein könnte.
Ich brauche dann aber nicht noch zusätzlich unter ASC ein Device hinterlegen, oder?

[CoolTux]

Ehrlich gesagt verstehe ich das derzeit noch nicht.
Ich sehe im Code, dass du unter "Global" das holiday2we-Attribut prüfst. In meinem "holiday"-Device habe ich ja bereits stehen, dass morgen ein Wochenende sein könnte.
Ich brauche dann aber nicht noch zusätzlich unter ASC ein Device hinterlegen, oder?

Nein. Das zusätzliche Device dient der Erkennung weiterer freier Tage. Ausserhalb von Holiday und WE. Ich habe zum Beispiel einen Urlaubskalender als ical. Sobald ein Eintrag im Calendarmodul auf taucht schreibt ein Notify mir in mein DummyKalenderDevice eine 1 rein. Um das aus zu werten, dafür ist das Attribut gedacht. Wird aber noch nicht beachtet.

[Beta-User]

Ich sehe im Code, dass du unter "Global" das holiday2we-Attribut prüfst. In meinem "holiday"-Device habe ich ja bereits stehen, dass morgen ein Wochenende sein könnte.

Habe eben den Code mal kurz angesehen, weil ich heftig darauf hinweisen wollte, dass das holiday-Device _keine_ Info über Wochenende enthält, sondern nur die dort genannten Termine berücksichtigt.

Da sind mir aber zwei Dinge aufgefallen:
- Die neue Funktion IsWe() macht genau dasselbe wie $we, die als globale Variable systemweit verfügbar ist. Der Mehrwert ist mir nicht klar oder habe ich was nicht richtig verstanden?
- In der IsWeTomorrow wird als Variablenname $we verwendet. Könnte zu Konflikten mit der genannten global verfügbaren Variable kommen (ich weiß nicht, ob Perl das ähnlich kapselt wie C); sollte man m.E. sicherheitshalber umbenennen. Und ob die Eingangsabfrage (Zeile 1059) mit "+1" funktioniert? Würde annehmen, dass 6+1 7 ergibt .

[CoolTux]

Habe eben den Code mal kurz angesehen, weil ich heftig darauf hinweisen wollte, dass das holiday-Device _keine_ Info über Wochenende enthält, sondern nur die dort genannten Termine berücksichtigt.

Da sind mir aber zwei Dinge aufgefallen:
- Die neue Funktion IsWe() macht genau dasselbe wie $we, die als globale Variable systemweit verfügbar ist. Der Mehrwert ist mir nicht klar oder habe ich was nicht richtig verstanden?
- In der IsWeTomorrow wird als Variablenname $we verwendet. Könnte zu Konflikten mit der genannten global verfügbaren Variable kommen (ich weiß nicht, ob Perl das ähnlich kapselt wie C); sollte man m.E. sicherheitshalber umbenennen. Und ob die Eingangsabfrage (Zeile 1059) mit "+1" funktioniert? Würde annehmen, dass 6+1 7 ergibt .

$we ist in Modulen und in 99_myUtils Funktionen als Variable nicht verfügbar.
Da ich mit packages arbeite kann ich auch Funktionen benennen die gleich lauten wie in anderen Modulen oder gar in FHEM solange ich die Funktion nicht importiere.
Bleibt am Ende 6+1 = 7 und das lasse ich gelten 

[Beta-User]

...man lernt nie aus, da war ja was...

Danke für die Rückmeldung.

(Irgendwie irritierend, dass $wday geht, aber das in der commandref bei den Perl Specials in einem Atemzug mit $we auftaucht)

[CoolTux]

...man lernt nie aus, da war ja was...

Danke für die Rückmeldung.

(Irgendwie irritierend, dass $wday geht, aber das in der commandref bei den Perl Specials in einem Atemzug mit $we auftaucht)

$wday wird ja auch als Variable im Modul deklariert und über die Funktion localtime(gettimeofday()); befüllt.

[CoolTux]

gefixte Version 0.1.49 ist nun Online. Vielen vielen Dank für die gute Aufmerksamkeit.



Grüße

[Beta-User]

Thx für die Info.

Insgesamt auch irgendwie unbefriedigend, dass da jeder Modulautor doch wieder die Funktion selber einbauen muß; aber eine einfachere Lösung scheint es ja nicht zu geben... Lassen wir das auf sich beruhen, oder?

[CoolTux]

Jepp.

Es gibt ja auch keine wirkliche Funktion für $we, das $we wurde lediglich bei AnalyzePerlCommand() abgearbeitet. Also sehr sehr FHEM intern.

[kjmEjfu]

Bin gerade im Wiki über

AutoShuttersControl_Time_Up_WE_Holiday         Sunrise frühste Zeit zum hochfahren am Wochenende und/oder Urlaub (we2holiday wird beachtet), Achtung sollte nicht größer sein wie AutoShuttersControl_Time_Up_Late sonst wird AutoShuttersControl_Time_Up_Late verwendet

gestolpert.

Finde ich nicht ganz so ideal.

Das Attribut AutoShuttersControl_Time_Up_Late benutze ich doch, um z.B. bei Nutzung von CIVIL zu erzwingen, dass das Rollo nicht erst um ~10 Uhr hochfährt, sondern spätestens zum festgelegten Zeitpunkt.

Bei AutoShuttersControl_Time_Up_WE_Holiday will ich doch aber vielleicht das Rollo erst um 11 Uhr hochfahren lassen, weil ich am Wochenende richtig lange schlafe.

Wenn ich dafür nun aber AutoShuttersControl_Time_Up_Late verlängern muss, dann fahren die Rollos im tiefsten Winter auch an normalen Tagen erst sehr spät hoch. Frauen haben dann schnell so einen "ich fühle mich eingesperrt"-Moment 

[CoolTux]

Also ich kann es entweder so machen wie bis jetzt, oder ich nehme AutoShuttersControl_Time_Up_Late komplett aus der Berechnung am Wochenende und Feiertagen raus. Dann fährt er definitiv um AutoShuttersControl_Time_Up_WE_Holiday hoch.
Was wäre den Usern lieber?

[Beta-User]

Zur Anmerkung von kjmEjufu: Ging mir im ersten Moment auch so, dann habe ich das vorläufig auf die Seite gestellt.

(Vermeiden kann man das, indem man den Resident asleep legt, oder?)
(In meiner eigenen Gedankenwelt gab es am WE auch mal 2 Werte = hier zwei Attribute; braucht es m.E. nicht)

Spricht was dagegen, den Up_Late-Timer $we abfragen zu lassen und dann erforderlichenfalls zu prüfen, ob Up_WE_Holiday bereits um ist? (Wenn nein: neuer Timer auf diese Zeit).
Oder noch besser: gleich bei der Erstellung des Timers zu prüfen, ob "tomorrow" nicht "none" ist und dann _zu prüfen, ob die WE-Time später ist als die "Late". Wenn ja: fixer Timer, ansonsten eben "normal" (ggf. mit Astro-Berechnung)? (Der Vergleich sollte sich hier ja zur Abwechslung mit einem "gt" machen lassen, oder?)

[CoolTux]

Das prüfen ob late kleiner ist wie we passiert automatisch.
Ich werde late rausnehmen für das WE und somit fährt er auf jeden Fall zum WE Zeitpunkt wenn die Bewohner auf sind, wenn nicht dann eh nicht.

[C0mmanda]

Auch wenn es schon hinreichend diskutiert wurde:

Ich finde es sehr unschön extra ein dummy-Device + notify anlegen zu müssen um die holiday-Funktion nutzen zu können.
(1|0 muss beim Device im state stehen).
Ich habe ja schließlich schon ein holiday-Device.

Gruß