[neues feature] WeekdayTimer mit weekprofile steuern

[persching]

Also wenn ich die Wahl hätte, dann würde ich natürlich auch die Variante

Code Auswählen Erweitern

set WP_Thermostate restore_topic Urlaub
sinnvoll finden.

Und natürlich hast du recht, dass man an den Profilen selten etwas ändert bzw. wenn dann nur punktuell. Beim ersten erstellen ist es dann so wie du sagst, da muss man halt durch.

Wir können das gerne machen, dass du mir bei den notifys hilfst und ich kann dann den Wiki-Artikel schreiben, wenn ich selbst durchblicke, wie alles funktioniert.

[Beta-User]

Kannst das ja mal austesten, ob das klappt mit dem "restore_topic" => der "Ziel"-WDT sollte dann jeweils nach einem Topic-Wechsel ein anderes Profil haben (ggf. browser-refresh machen, dann sieht man das auch direkt in den Internals).

Was das/die notify angeht, würde ich vorschlagen, das in "unserem" anderen Thread zu diskutieren (kannst ja den Thread-Titel anpassen), die Allgemeinheit hier wird sich dann eher wieder für das Ergebnis interessieren; bitte dort die Rahmenbedingungen etwas klarer ziehen. Ich habe dort einige Devices in CONDITION gesehen, aber nicht, warum die wie gefüllt werden mit welchem gewünschten Ergebnis.
Für die dortige Frage habe ich noch eine Vermutung: der WDT mag es nämlich nicht so, wenn man sowohl $we wie !$we (bzw. 78) für einen Schaltzeitpunkt verwendet. Will man "immer" schalten, sollte man das schlicht weglassen, sonst wird erst mal geprüft, ob $we ist, und das war es dann (was den state angeht; die timer werden trotzdem im Hintergrund richtig ermittelt und angefahren, aber die Readings sind unbrauchbar)...

Was die Ersteinrichtung angeht:
In weekprofile gibt es auch die Option, Profile zu kopieren, damit geht es ggf. ab dem 2. dann schneller.

[persching]

Ich hab das mit dem restore_topic mal probiert, aber das hat nichts bewirkt. Es gab keine Fehlermeldung, aber es hat auch kein Profil umgeschaltet. Ich habe dazu ein Topic "Abwesenheit:Alle" erstellt. Gemeint ist damit, dass alle Thermostate auf 18°C schalten, wenn RESIDENCE auf "verreist" steht (sprich, wenn alle Handys länger als 18 Stunden nicht mehr im WLAN waren).
Aber irgendwie ist da noch ein Denkfehler drin. Ich kann dem WDT mit

Code Auswählen Erweitern

set WDT_Flur weekprofile WP_Thermostate:Abwesenheit:Alle zuweisen. Weiterhin kann ich danach irgendwann wieder mit

Code Auswählen Erweitern

set WDT_Flur weekprofile WP_Thermostate:Urlaub:Flur zuweisen und alles ist wieder wie an einem Urlaubstag (=nicht arbeiten und zuhause). Woher soll aber nun der WDT wissen, dass er auf das Topic "Abwesenheit/Urlaub/..." reagieren soll?? Bei mir steht im Reading weekprofiles immer nur das aktuell aktivierte. Oder ist der Denkfehler bei mir, dass ich nur ein einziges weekprofile für die Thermostate erstellt habe und der Rest wird mit Topics und Namen umgeschaltet?? Mit der Variante die ich gerade verwende müsste ich ja noch sagen können auf welche Topics der WDT alles reagieren soll.

[Beta-User]

Zu restore_topic:

commandref sagt

Therefore a user attribute 'weekprofile' with the weekprofile name without the topic name have to exist in the device.

Also solltest du das nochmal wiederholen, nachdem du das userAttr "weekprofile" angelegt hast:

Code Auswählen Erweitern

attr WDT_Flur userAttr weekprofile
attr WDT_Flur weekprofile Flur
Dann sollte weekprofile erkennen können, dass eine Topic-Änderung bei allen Profilen, die das betreffende Topic kennen auch an den WDT "auszurollen" ist. Es muß daher auch eine Topic/Profil-Kombination "Abwesenheit:Flur" geben.

So wie ich das verstehe ein Beispiel. Es gibt in WP_Thermostate zwei Thermostate (Flur und Wohnzimmer) und drei Topics (Urlaub, Anwesenheit und Abwesenheit). Dann sollte es 6 Kombinationen geben:
- Urlaub:Flur, Anwesenheit:Flur und Abwesenheit:Flur sowie
- Urlaub:Wohnzimmer, Anwesenheit:Wohnzimmer und Abwesenheit:Wohnzimmer.
"set WP_Thermostate restore_topic Anwesenheit" sollte jetzt (bei an beiden gesetzten entsprechenden userAttribs) das jeweils unter dem Topic "Anwesenheit" gespeicherte Profil an beide WDT ausliefern. Das muß aber nicht dasselbe sein (kann aber eine 1:1-Kopie sein).

Dass im WDT immer nur das jeweils aktuell gesetzte steht, ist soweit korrekt.

Als notify für den "verreist"-Fall sollte dann eigentlich schon sowas passen:

Code Auswählen Erweitern

define n_WDT_Verreist_setzen notify Familie:verreist WP_Thermostate restore_topic Abwesenheit
(Muß man nur aufpassen, dass sich da nicht was ins Gehege kommt, wenn mehrere Bedingungen gleichzeitig eintreffen können bzw. der letzte Zustand wiederhergestellt werden soll, z.B. wenn die Putzfrau wieder weg ist...)

[persching]

Mit dem userAttr weekprofile funktioniert das mit dem restore_topic einwandfrei. Wenn man dort jetzt noch mit Komma getrennt mehrere Sachen angeben könnte, dann wäre das perfekt. Dann könnte man nämlich z.B. ein Topic "Off:Alle" erstellen und kann somit im Sommer mit

Code Auswählen Erweitern

set WP_Thermostate restore_topic Off alle Thermostate gleichzeitig auf einen Wert setzen.
Natürlich kann man für jeden Thermostat natürlich nochmal ein eigenes Topic anlegen (also "Off:Wohnzimmer, Off:Kueche, Off:Flur, ...") aber ich finde das ist ja gerade der Vorteil, dass man weekprofile definieren kann und die jedem WDT zuweisen kann. Ich besitze 10 Thermostate in meinem Haus und warum sollte ich da 10x das gleiche erstellen. Zwar geht es mit dem kopieren recht schnell, aber spätestens dann, wenn man etwas ändern will, dann erkennt man den Vorteil von dem One-for-all-Topic...

Wäre ein

Code Auswählen Erweitern

attr WDT_Flur weekprofile Flur,Alle möglich?? Es wäre ja nur optional und man muss es nicht verwenden.

[Beta-User]

Hmm,

vorab mal: Cool, dass das so zackig vorangeht bei dir!

Was die Fragen angeht: ich bin bei weekprofile auch noch nicht durch alle Verästelungen durch, aber da gab es die Option, Referenzen zu nutzen. Damit verlinkt man dann eigentlich nur auf ein anderes Profil. Könnte des Rätsels relativ einfache Lösung für "all off" sein?

Ansonsten kannst du ja vielleicht für so einen "Sonderfall" wie das allgemeine Ausschalten auch schlicht einen anderen set-Befehl nehmen....? Man muß dann halt (aber sowieso..!) dafür sorgen, dass nicht was anderes einen gegenteiligen anderen Befehl absetzt . Du bist jedenfalls bei anderen Settern weder bei weekprofile noch bei WeekdayTimer auf das im userAttr angegebene Profil beschränkt, das ist "nur" ein (ziemlich cooles) Hilfsmittel im Rahmen vom "Topic"-Modus  . Könnte man z.B. auch via devspec abgrenzen (z.B. alle Geräte vom TYPE WeekdayTimer, die ein weekprofiles-Reading haben).

Und das mit den mehreren Werten im userAttr: Hast du das mal angetestet? Evtl. funktioniert es ja bereits...

[persching]

Ja per Komma getrennte Werte hatte ich bei weekprofile eingetragen und es hat nicht funktioniert. Und das verhindern eines anderen Falls kann man mit DOIF (ja ich weiß, schon wieder das... ) sehr gut steuern, da man ja ein if, elseif und else bauen kann und somit sollte am Ende nur ein Topic gesetzt sein.
Ich mach das so, dass ich ein Dummy habe bei dem ich ein Profil auswähle (Auto, Manuell, Minimal und Off). Auto unterscheidet dann nochmal ob heute ein Arbeitstag oder kein Arbeitstag ist und ob Handys im WLAN eingebucht sind oder nicht. Bei manuell wird einfach die gewählte Temperatur dauerhaft gehalten und bei Minimal wird nur morgens und abends geheizt (Übergangszeit). Und genau so würde ich dann die Topics auch steuern.

[Beta-User]

if elsif usw. gibt es auch im "normalen" Perl, damit "kann" auch notify...

Das mit der Vorauswahl in einem Dummy leuchtet mir nicht (in dem Umfang) ein. Ich habe z.B. einen Dummy, der Heizperiode an/aus wiedergibt, aber z.B. Urlaub geht eigentlich doch besser direkt in die PRESENCE-Devices ein, oder? (Ich habe dafür eine calendar-Auswerteroutine und würde Readings an den Presence-Devices setzen).

Tendenziell sollte es ausreichen, den  Anwesenheitsstatus aller Bewohner auszuwerten (bzw. ein zusätzlich evtl. paar Readings der Bewohner).

[persching]

Ich weiß auch nicht, ob das jetzt alles die beste Lösung ist, aber ich hab mir das mal so ausgedacht und bin zufrieden. Den Dummy schalte ich ja auch eher selten um. Im Frühjahr von Auto auf Minimal, im Sommer dann von Minimal auf Off und im Herbst der umgekehrte Weg. Im Auto-Profil wird dann natürlich die Anwesenheit per PRESENCE unterschieden. Aber nur mit der Anwesenheit komme ich nicht hin, weil an keinen Arbeitstagen (ca. 7.30 Uhr) fange ich viel später an zu heizen, als an Arbeitstagen (4.45 Uhr). Und vielleicht ist auch der Begriff "Urlaub" in meinen letzten Beiträgen vermischt worden mit "kein Arbeitstag". Ich hab das jetzt mit der Umstellung auf weekprofile umbenannt. "Urlaub" ist was "kein Arbeitstag" war, und bedeutet nicht Arbeiten, aber trotzdem zuhause. "Abwesend" ist dann länger nicht zuhause.
Die Unterscheidung "Minimal" benötige ich auch, weil es in der Übergangsphase gefühlt tagsüber noch warm genug ist, aber die Thermostate trotzdem schon heizen würden. Ich hab dann auch noch bei diesem Profil eine Rückführung an meine Zentralheizung. Wenn die Thermostate über einen bestimmten Wert öffnen, dann wird die Heizung von Warmwasser auf Warmwasser+Heizen umgeschaltet. Wenn die Thermostate dann wieder schließen, dann wird wieder auf nur Warmwasser umgeschaltet. So ist es dann so, dass die Heizung nur morgens und abends an ist... oder eben an Tagen an denen es mal draußen nicht so warm ist.
Darum denke ich, dass ich nicht nur mit "Heizphase an/aus" auskommen würde... Aber ich glaube das ist eine Frage, die jeder für sich entscheiden muss. Vielleicht bringt meine detailierte Unterscheidung auch überhaupt gar nix...

[Beta-User]

So wie du das schilderst, paßt das schon, es kommt ja auch immer darauf an, wie man was verwendet, und die Quantität der manuellen Umschaltvorgänge scheint ja gering zu sein .

Bleibt ggf. die Frage, wie du (kein) Arbeitstag festlegst; wenn das z.B. jeden Tag über ein Calendar-Event (oder ein holiday-device) passiert, würde es reichen, dieses Event auszuwerten und dann ggf. später über "vorübergehend alle außer Haus"/Presence nachzusteuern bzw. als weiteren Trigger zu verwenden. Ohne Events könnte man ein "Früh-morgens-at" bauen, das den passenden Basis-Topic für den Tag wählt und dann Event-basiert nachregeln. Ich würde dazu einen Perl-myUtils-Code vorschlagen, der aus allen Stellen heraus (at/notify) aufgerufen werden kann, kurz alles durchcheckt und ggf. bei Änderungsbedarf dann das Topic setzt (bzw. die "alles aus"-Anweisung schickt).

Wichtig ist halt, dass am Ende die Lösung zu deinen Anforderungen paßt und du weißt, wie man es ggf. wartet und weiterentwickeln kann  . (Sorry, ich bin etwas "empfindlich", was extensive Dummy-Nutzung angeht und das "Umpacken" von überflüssigen Infos und hatte was in diese Richtung vermutet. Hast du aber gut erklärt, dass es Sinn macht bzw. hier gar nicht der Fall ist).

[persching]

Arbeitstag oder nicht wird aktuell hauptsächlich über Ferien und Feiertage gesteuert. Das ist ausreichend genau...

[Beta-User]

OK, dann bleibt die Frage, ob das "Arbeitstag" jeden Tag vor 4:45 Uhr ein Event wirft (oder mehrere), oder ob man besser timer-basiert arbeitet...?

[persching]

Seit ein paar Tagen läuft das mit den WDT iVm weekprofile soweit ganz ok. Aber ich hatte jetzt festgestellt, dass ja der erste Schaltpunkt um 00:10 Uhr ist. Soweit stimmt das dann ja auch. In den Tagen wo es bei uns Nachts aber auch wieder über 7°C sind schaltet meine Heizung wieder in die Nachtabsenkung und somit werden alle Thermostate auf 17°C eingestellt, dass sie nicht versuchen eine Temperatur zu regeln, die aufgrund der Nachtabsenkung gar nicht möglich ist. Hierfür hab ich einen Dummy "Absenkung_Dummy" mit den Werten true oder false. Weiterhin hat jeder Thermostat außer der im Flur mindestens einen Fensterkontakt. Dazu gibt es also jeweils ein oder zwei Einträge bei WDT_delayedExecutionDevices. Soweit funktioniert das alles prima. Heute wollte ich nun eine Funktion in myUtils programmieren, die je WDT ein true oder false zurückliefert, wenn eine weitere Bedingung die Ausführung verhindern soll. Dazu hab ich dann also unter delayedExecutionCond die Funktion aufgerufen. Auch das funktioniert. Es liefert passend true oder false zurück, ABER im Laufe der Zeit waren dann alle WDT im state "window open", selbst der im Flur, bei dem es gar kein WDT_delayedExecutionDevices gibt. Ist es gar nicht vorgesehen, dass man sowohl WDT_delayedExecutionDevices und auch delayedExecutionCond verwenden kann?? Bzw was passiert, wenn die gleiche Funktion innerhalb von Sekunden von verschiedenen WDT aufgerufen wird???

[Beta-User]

Muß das ggf. nochmal näher untersuchen, habe das aber so im Kopf, dass "window open" für jede Art der Verzögerung steht - das könnte also passen, wenn alle eine Perl-Funktion haben; der Status wechselt eben zum jeweiligen Schaltzeitpunkt, nur da wird ausgewertet, solange nicht verzögert ist. Die Funktionen kommen sich auch mit ziemlicher Sicherheit nicht ins Gehege...

Allerdings frage ich mich, ob es nicht einfacher wäre, ein Topic "Nachtabsenkung" zu nutzen?

[persching]

Stimmt an das Topic "Nachtabsenkung" hab ich gar nicht gedacht.. Ich probiere es mal aus...