Betatester für neues Modul AutoShuttersControl gesucht!

[FunkOdyssey]

ASC wäre doch richtig, oder? Nicht ACS? 

[Papaloewe]

Super, endlich ein Modul dafür. 

Habe ich etwas überlesen, oder gibt es zur Zeit noch keine Wochentags- Feiertags-, Ferien-Berücksichtigung?

Gruß Thomas

[CoolTux]

ASC wäre doch richtig, oder? Nicht ACS? 

Jepp. Gut aufgepasst. Danke

[CoolTux]

Super, endlich ein Modul dafür. 

Habe ich etwas überlesen, oder gibt es zur Zeit noch keine Wochentags- Feiertags-, Ferien-Berücksichtigung?

Gruß Thomas

Hallo Thomas,

Aktuell ist noch keine Kalenderunterstützung implementiert.


Grüße

[Benni]

ASC wäre doch richtig, oder? Nicht ACS? 

Jepp. Gut aufgepasst. Danke

Hier noch eine Zwischenfrage von den Mitlesern aus der letzten Reihe  :

Wäre es der Übersicht nicht dienlicher, dieses Kürzel auch als Präfix für die Readings und die Attribute zu nehmen? "AutoShutterControl_" finde ich schon ziemlich lange, wenn auch zugegebenermaßen eindeutiger 

gb#

[CoolTux]

Hier noch eine Zwischenfrage von den Mitlesern aus der letzten Reihe  :

Wäre es der Übersicht nicht dienlicher, dieses Kürzel auch als Präfix für die Readings und die Attribute zu nehmen? "AutoShutterControl_" finde ich schon ziemlich lange, wenn auch zugegebenermaßen eindeutiger 

gb#

Die Idee finde ich gut, Problem. Bei 3 Buchstaben ist die Möglichkeit groß daß es das schon gibt.
Ansonsten würde ich Dir aber Recht geben.

[CoolTux]

Zu dem Zusammenfassen mehrerer Presence-Devices als Hilfsmittel noch eine RAW-Definition für eine Structure:

Code Auswählen Erweitern

define rr_Parents structure eltern rr_Mann rr_Frau
attr rr_Parents clientstate_behavior relative
attr rr_Parents clientstate_priority asleep gotosleep awoken home absent
attr rr_Parents group Persons
attr rr_Parents icon user_unknown
attr rr_Parents room Steuerung
attr rr_Parents userReadings lastState:(home|awoken|asleep|gotosleep|absent) { OldValue($name) }und als Muster ein Weekdaytimer für meinen "Mann"-Dummy, damit der sich erst mal "bewegt". Gibt's in ähnlicher Form auch für

Hier würde ich eher sowas empfehlen

Code Auswählen Erweitern


userReadings
attr rr_Parents userReadings lastState:(home|awoken|gotosleep|asleep|absent) { ReadingsVal(ReadingsVal($name,'LastDevice','none'),'lastState','none') }


[CoolTux]

Habe mir gerade das Thema Wochenende, Ferien und Feiertag angeschaut. Das ist ja im Script doch Recht einfach gelöst. Quasi für alles. Aber nun heißst es ja nicht das wenn ich Urlaub habe, meine Tochter nicht aufstehen muß wenn sie Schule hat. Also sollte Ihr Rollo schon noch hochfahren wenn die Sonne auf ist.


Wenn man sich das ganze auf Basis vom Residentsmodul an schaut ist das eh einfacher. Die Rolladen fährt erst wenn meine Tochter auf awoken oder home steht. Das passiert automatisch wenn Ihr Wecker klingelt.
Daher frage ich mich ob das mit dem Kalender überhaupt Sinn macht.

[marvin78]

Das kommt wohl auf die Struktur des Haushalts, der Familie und die Räume an. Nicht jeder Rollladen hängt in einem Schlafzimmer. Bestimmte Rollläden möchte man ggf. anders öffnen.

[Beta-User]

Moin,
kann sein, dass dsa auch an irgendwas anderem lag, aber evtl. ist das sehr unschön, daher die Bitte um Prüfung, ob der aktuelle Code nicht bei der Erstellung der Timer in eine Dauerschleife läuft:

Habe heute frühmorgens die pm getauscht und einen reload durchgeführt.

Danach schien erst mal alles normal zu sein (habe noch an einen der wdt was geändert). Nachdem dann die Rolläden heute morgen nicht gefahren sind, ergab ein Blick ins log tausende Einträge mit dem Muster:

2018.09.06 07:30:52 2: AutoShuttersControl (Rolladenautomatik) - CreateSunRiseSetShuttersTimer, neuer Sunset: 1 neuer Sunrise: 1
2018.09.06 07:30:53 2: AutoShuttersControl (Rolladenautomatik) - CreateSunRiseSetShuttersTimer, neuer Sunset: 1 neuer Sunrise: 1

Kann auch an irgendwas liegen, was ich drumrum gemacht habe... Habe die pm jetzt erst mal umbenannt.

Gruß, Beta-User

[CoolTux]

Moin,
kann sein, dass dsa auch an irgendwas anderem lag, aber evtl. ist das sehr unschön, daher die Bitte um Prüfung, ob der aktuelle Code nicht bei der Erstellung der Timer in eine Dauerschleife läuft:

Habe heute frühmorgens die pm getauscht und einen reload durchgeführt.

Danach schien erst mal alles normal zu sein (habe noch an einen der wdt was geändert). Nachdem dann die Rolläden heute morgen nicht gefahren sind, ergab ein Blick ins log tausende Einträge mit dem Muster:

2018.09.06 07:30:52 2: AutoShuttersControl (Rolladenautomatik) - CreateSunRiseSetShuttersTimer, neuer Sunset: 1 neuer Sunrise: 1
2018.09.06 07:30:53 2: AutoShuttersControl (Rolladenautomatik) - CreateSunRiseSetShuttersTimer, neuer Sunset: 1 neuer Sunrise: 1

Kann auch an irgendwas liegen, was ich drumrum gemacht habe... Habe die pm jetzt erst mal umbenannt.

Gruß, Beta-User

Ja läuft er, die Beobachtung hatte ich auch. Schuld ist die structure welche alle seine Attribute an die Roomate Dummys weiter reicht.  War zu mindest bei mir so. Kontrolliere bitte einmal Deine structure und Deine roomate Dummys.
Am besten ein List hier rein werfen. Ich hab es auch erst heute morgen mitbekommen. Und erst nachdem ich die strukture gestern Abend angelegt hatte.

[CoolTux]

Ok Vergiss meine Aussage, das war es wohl nicht.

Es ist der Timer. Wenn die Zeit für den Timer in der Vergangenheit liegt dann passiert genau das. Jetzt muss ich nur noch finden wieso er Daten aus der Vergangenheit bekommt.

[CoolTux]

Ich habe auf Github eine HotFix Version eingespielt welche die Dauerschleife verhindert. Bitte unbedingt einspielen bis ich das Problem an sich identifiziert habe.


Sorry

[kjmEjfu]

Habe mir gerade das Thema Wochenende, Ferien und Feiertag angeschaut. Das ist ja im Script doch Recht einfach gelöst. Quasi für alles. Aber nun heißst es ja nicht das wenn ich Urlaub habe, meine Tochter nicht aufstehen muß wenn sie Schule hat. Also sollte Ihr Rollo schon noch hochfahren wenn die Sonne auf ist.


Wenn man sich das ganze auf Basis vom Residentsmodul an schaut ist das eh einfacher. Die Rolladen fährt erst wenn meine Tochter auf awoken oder home steht. Das passiert automatisch wenn Ihr Wecker klingelt.
Daher frage ich mich ob das mit dem Kalender überhaupt Sinn macht.

Ich bin da, wenig überraschend, für weitgehende Flexibilität. Sprich grundsätzlich die Attribute am ASC-Device allgemeingültig haben, aber mit der Möglichkeit die in allen Rolladen-Devices zu überschreiben. Dadurch lassen sich dann alle Möglichkeiten, die man sich nur irgendwie ausdenken mag, entsprechend umsetzen.

Derzeit (Nutzung vom Cluni Quellcode) habe ich auch awoken und asleep eingebunden, lasse aber bei Wechseln in einen dieser Status einfach nur Zeit vom jeweiligen at (Rollo_hoch bzw. Rollo_runter) auf jetzt plus zwei Sekunden setzen. (Wobei ich auch noch die Uhrzeit abfrage, damit die Kinder nicht mitten in der Nacht die Rollos in ihren Zimmern hochfahren können, weil sie meinen jetzt wach zu sein

[Beta-User]

Danke für die schnelle Analyse.

Im Moment ist die Moduldatei umbenannt und läuft daher nicht, reaktivieren folgt dann heute abend.


Was den Nebenschauplatz structure angeht:
a) Es dürfte in der Tat so sein, dass das userreading dazu führt, dass der eigentlich nur für die structure gedachte Wert für lastState wieder an die beteiligten Devices zurückvererbt wird. Das ist wenig zielführend  - unabhängig von der Frage, welcher Inhalt denn eigentlich der richtige ist.

Evtl. könnte man auf "setreading" ausweichen, wenn nicht wäre der Vorschlag dazu: (Mind. hier) die OldReadings-Mechanismen (über das attribut "attr <structure> oldreadings state") nutzen. Im Ergebnis würde man also bei den roommate-Devices immer erst nach lastState sehen. Ist das undef: OldReadingsVal(<structure>,'state',"unknown").

b) Es leuchtet mir noch nicht so richtig ein, wieso der lastState aus dem letzten triggernden Device aktualisiert werden soll, wenn sich der Wert der structure dadurch nicht ändert. Also: Mann ist zuhause, Frau absent => structure: home. Mann geht ins Bett => structure asleep mit lastState home (egal, ob von Mann oder structure). Frau kommt nach Hause. structure => weiterhin asleep, aber da ein Reading sich geändert hat, wird userreading getriggert. ABER eigentlich stimmt _kein_ Ergebnis: structure war schon asleep => falsch, Frau war absent => auch m.E. nicht richtig.

Irgendwie beschleicht mich der Verdacht, dass userreadings hier nicht das Gelbe vom Ei ist und man vermutlich stattdessen ein notify auf den state der structure(s) legen und damit ein setreading ausführen sollte (in dem Rahmen sollte es auch nicht triggern, oder?).

Gruß, Beta-User