[neues feature] WeekdayTimer mit weekprofile steuern

[moustic999]

that's more complex and a long story
in KNX, the mode is defined by a standardized DPT ( 20.102 ) with meaningfull name (eco, standby, comfort, etc) mapped by numbers 0->4
Responsible for KNX in fhem does not want to integrate this. https://forum.fhem.de/index.php/topic,91462.0.html
So we already have to work with eventMap in order to translate numbers in their string.

having to configure temperature to match some mode, then convert into some integer, is not really great.

WeekdayTimer already supports any commands as long as your device understand it, it is explained in the commandref. The only needs is to have weekprofile adapted to support the mode instead of the temperature.

[Beta-User]

OK, I see.

I'm not very deep in the weekprofile code, but most likely, adopting to your desires would be quite a lot of work.

I myself have some ideas to allow "changable" other profiles, but don't expect wonders to happen the next weeks or even months.

But how about extending the eventMap with the "translations" you need to deal with temperatures?
Should be no big deal to use something like "dtp20 03" instead of "eco" (I'm not familiar with the knx syntay, but just to get an idea; afaik having several different "in"-codes leading to the same "out"-code should be ok):

Code Auswählen Erweitern

attr <knx-thermostat-name> eventMap { (whatever was there before & ) usr=>{'22.0'=>'dtp20 01','12.0'=>'dtp20 02','18.0'=>'dtp20 03' } }

[moustic999]

as said, WeekdayTimer already supports using the mode directly, so the most missing thing from weekprofile is the fhemweb editor.
I don't think we need to extend a lot eventMap and so on, excpt if someone needs more advanced use of the weekprofile.

but having the possibility to support the mode in weekprofile would ne a nice addition in the future

[Beta-User]

There had been one initial problem:
I'm (at least atm) not capable to write FHEMWEB interface code comparable to what weekprofile already has . Indeed this was one of the main causes to ask for support from weekprofile/@Risiko side . So still the answer to that kind of feature request is: no. (If someone deliveres code, I'd surely have a very close look into that, so feel free ).

Note: There's already an editor available, but not for FHEMWEB, but for FTUI.

It turned out combining weekprofile and WeekdayTimer was a very good idea, as now, one can handle "profiles" for any type of thermostat with just one solution (weekprofile), as long as the targed device "understands" temperature commands (in figures). Now, I'd say that's the big advantage, as one can do that "on the fly" (at runtime) without need of fiddeling around with the WDT definition.

One thing is in my mind: Perhaps it's a good idea to have an "eventMap"-comparable translation option directly implemented in the WDT code. But still, I don't see a big advantage compared to the eventMap option the target device itself offers.
Other (already existing) option would be to develop some kind of Perl translation code as "command" in WeekdayTimer. Should not be very complicated to do.

When talking about thermostats, it forever will be hard to cope to the "dynamics" weekprofile offers in combination with WeekdayTimer, so I'd really recommend to have a closer look to that (using eventMap or the Perl variant mentionned above).

[JamBay]

Eine kleine Bitte hätte ich:
ich nutze EQ3BT Thermostate, hier gibt es kein off, sondern die Wunschtemperatur 4.5 schließt das Thermostat, 4.5 kann ich im WeekProfile aber nicht einstellen.
Kann man das DropDown Menü für die Temperatur um diesen Wert erweitern?

Danke.

[Beta-User]

Ohne @Risiko mit dem feature-Wunsch vorgreifen zu wollen:

Kannst du das mit dem "eventMap-Trick" mal ausprobieren?

Also z.B. die tiefste einstellbare Temperatur (ungetestet auf 6.0 gesetzt) auf 4.5 mappen (bzw. wenn "off" einstellbar ist):

Code Auswählen Erweitern

attr <eq3-bt-thermostat-name> eventMap { usr=>{'6.0'=>'4.5','off'=>'4.5'} }

[Beta-User]

Nachtrag: Es gibt ein Attribut bei weekprofile, um die untere (bzw. obere) Temperatrugrenze zu setzen. Wenn du direkt 4.5 haben willst: setz das auf 4, dann kannst du auch direkt 4.5 auswählen, ganz ohne eventMap...
(Testen wäre trotdem nett!)

(Und dass das "get" dann auch "on" und "off" liefern kann, ist auch cool; damit kann man auch "simple on/off"-Devices so steuern  ...)

[JamBay]

Wenn du direkt 4.5 haben willst: setz das auf 4, dann kannst du auch direkt 4.5 auswählen, ganz ohne eventMap...

Das funktioniert ja so astrein, wie kommt man auf sowas?
Beim Mapping muss das ungefähr so aussehen, dann klappt das auch :

Code Auswählen Erweitern

{ usr=>{'6.0'=>'desiredTemperature 4.5','off'=>'desiredTemperature 4.5'} }

Der Feature-Wunsch hat sich damit erledigt.

[JamBay]

So, ich habe jetzt meine Thermostate auf diese Verfahren umgestellt und es funktioniert sehr gut.
Mir ist nur aufgefallen, dass das Profile 'default' welches beim definieren des weekprofile angelegt wird, irgendwann verschwindet, wenn man andere Profile angelegt hat und diese etwas bearbeitet hat.
Den genauen Zeitpunkt, oder was diese Verschwinden auslöst kann ich nicht nachvollziehen.
Ich finde auch keinen Eintrag für default in der Config-Datei (im log Verzeichnis).

Punkt zwei: wenn ich weekprofile für ein device anlege, welches nur on/off versteht, ich also tempOFF auf 0 und tempON auf 0.5 setze steht im Plan so was wie off °C oder on °C.
Vielleicht kannst du das °C in dem Fall unterdrücken?
Ist nur kosmetisch.

[Beta-User]

Danke erst mal für das Feedback  ! (Auf "sowas" kommt man, wenn man entweder einfach etwas rumspielt/testet, mit dem was die cref so zu bieten hat (meine Variante in dem Fall), oder man macht sich die Mühe, das im Quellcode nachzuvollziehen. Ist sogar naheliegender wie das mit dem eventMap...)

Ob bzw. warum ggf. weekprofile irgendwas löscht, kann ich nicht nachvollziehen, ist mir bei meinen Tests nie passiert; solltest du ggf. mal separat testen und dann im entsprechenden Forumsbereich posten (Risiko liest hier vermutlich nur sporadisch mit).

Dto. für das Thema mit "on °C" (ich habe mich nur gefreut, dass es überhaupt geht, das hatte ich nicht auf dem Schirm...).

Was super wäre:
Kannst du irgenwie deine Schritte bzw. ein paar exemplarische Devices "Wiki-tauglich" aufbereiten? Wäre vermutlich für Nachahmer interessant, das nicht nur anhand der commandref nachvollziehen zu können, sondern an einem (Praxis-) Beispiel.

[persching]

Ich wollte mich jetzt an das umsetzen von WDT mit weekprofile machen, aber ehrlich gesagt blick ich da nicht durch was ich jetzt wie definieren muss. Gibt es irgendwo ein durchgängiges Beispiel mit weekprofile, topics und mehreren Thermostaten.
Ich hab ein weekprofile für einen MAX-Thermostat (EG_Flur_T) mit define EG_Flur_Weekprofile weekprofile EG_Flur_T erstellt. Aber hier wurde versucht das weekprofile an den Thermostat zu übertagen. Und im anderen Thread hab ich ja gelernt, dass das nicht das Ziel ist von der Verbindung WDT und weekprofile.

Wie viele weekprofile muss ich denn jetzt erstellen, wenn ich für jeden Thermostat unterscheiden möchte zwischen "Arbeitstage", "Urlaubstage", "Übergangszeit" und "Sommer"? Und wie schalte ich die profile bzw. topics dann um? Mit einem DOIF??

[persching]

Ich glaube ich habe es jetzt verstanden:
Ich definiere ein weekprofile "WP_Thermostate" und darunter dann die Topics "Arbeitstag", "Urlaub", "Übergangszeit"... Bei jedem Topic muss ich dann noch einen Namen angeben und dort unterscheide ich dann z. B. Nach Räumen/Thermostate. Somit ergibt sich eine Kombination aus z. B. Urlaub:Wohnzimmer und das ist jetzt meine Grundlage für den Weekdaytimer "Wohnzimmer". Über verschiedene DOIF kann ich dann dem WDT sein aktuell gültiges Profil zuweisen...

Ich muss sagen, das ist wirklich eine sehr gute Erweiterung von WDT. Danke dafür!

[Beta-User]

Ich glaube ich habe es jetzt verstanden:
[...]

Das sollte soweit passen, auch wenn ich nicht weiß, warum "verschiedene DOIF" erforderlich sein sollten, um jeweils das aktuelle Topic zu ermitteln und zuzuweisen - ich würde das tendenziell innerhalb _einer_ notify(-myUtils)-Routine lösen (in deinem Fall mit (Familie|KAT|HC_Schlafz_Profile) als Auslöser), und wer unbedingt einen anderen Eventhandler wie DOIF, MSwitch... nutzen will, müßte das auch - für jeweils eine Gruppe von Thermostaten - in einem Device unterbringen können.

Ich muss sagen, das ist wirklich eine sehr gute Erweiterung von WDT. Danke dafür!

Danke für das Feedback!

Wie bereits hier geschrieben: Wenn jemand ein echtes Praxis-Beispiel für's Wiki liefern würde, wäre das klasse, wobei ich es begrüßen würde, wenn notify zur Anwendung käme (die anderen Eventhandler kenne ich nicht bzw. verstehe die Funktionsweise nicht, notify ist dagegen eben "core functionality", da kann und will ich dann ggf. auch Unterstützung leisten)...

[persching]

Ich muss sagen, dass ich mit den notify überhaupt nicht zurecht komme. Ich verwende eigentlich immer DOIF, darum ist das eben das was ich kenne.

Nun hab ich eine erneute Frage: muss ich denn nur das Topic aktivieren (als bspw. "Urlaub") oder ist das komplette Topic die Kombination aus Topic und Name?? Ich habe bei dem einen WDT das Topic jetzt so (manuell) aktiviert:

Code Auswählen Erweitern

set WDT_Flur weekprofile WP_Thermostate:Urlaub:Flur

Und das würde ich für alle Thermostate in eine myUtils auslagern und dann nur noch diese Funktion mit dem auszuwählenden Topic aufrufen und alle WDT werden mit dem passenden set-Befehl umgeschaltet.

Etwas ist mir noch aufgefallen, aber das ist wohl eher ein Thema des weekprofiles:
bei mir ist es meistens so, dass sich die Schaltzeiten nur zwischen Wochentagen und Wochenenden unterscheiden. Da wäre es natürlich klasse, wenn man das irgendwie in dem widget zusammen bearbeiten könnte, z.B. durch anhaken der Wochentage, die die gleichen Daten bekommen.

[Beta-User]

Ich muss sagen, dass ich mit den notify überhaupt nicht zurecht komme [...]

Deswegen hatte ich Hilfe angeboten; wie gesagt: mir geht es umgekehrt .

Nun hab ich eine erneute Frage: muss ich denn nur das Topic aktivieren (als bspw. "Urlaub") oder ist das komplette Topic die Kombination aus Topic und Name?? Ich habe bei dem einen WDT das Topic jetzt so (manuell) aktiviert:

Code Auswählen Erweitern

set WDT_Flur weekprofile WP_Thermostate:Urlaub:Flur

Das ist die eine Variante, allerdings habe ich zwischenzeitlich den Eindruck, dass das nicht die einfachste Variante ist . Mehr dazu weiter unten...

Und das würde ich für alle Thermostate in eine myUtils auslagern und dann nur noch diese Funktion mit dem auszuwählenden Topic aufrufen und alle WDT werden mit dem passenden set-Befehl umgeschaltet.

Ohne das getestet zu haben, ist es vermulich einfacher, das über den weekprofile-Weg zu machen; ggf. muß man dazu nicht mal auf die Perl-Ebene runter:

Code Auswählen Erweitern

set WP_Thermostate send_to_device Urlaub:Flur WDT_Flur
Da sollten auch "hinten" mehrere WDT-Devices auf einmal ansprechbar sein .

Noch einfacher _könnte_ es sein (könnte, da ungetestet), folgenden Befehl zu nehmen:

Code Auswählen Erweitern

set WP_Thermostate restore_topic UrlaubDamit sollten sich alle WDT's, die sich auf WP_Thermostate beziehen, auf einen Rutsch aktualisiert werden können. Allerdings bin ich da (noch) nicht durch, ob man dazu noch ein (user-)Attribut an den WDT's setzen muß, oder ob das "einfach so" klappt...
Aber DAS wäre (nach derzeitigem Kenntnis- & Verständnisstand) meine "Wunschvariante" - kurz und knackig, zentrale Admin aller Profile über ein weekprofile-Device...

Etwas ist mir noch aufgefallen, aber das ist wohl eher ein Thema des weekprofiles:
bei mir ist es meistens so, dass sich die Schaltzeiten nur zwischen Wochentagen und Wochenenden unterscheiden. Da wäre es natürlich klasse, wenn man das irgendwie in dem widget zusammen bearbeiten könnte, z.B. durch anhaken der Wochentage, die die gleichen Daten bekommen.

Ist in der Tat ein weekprofiles-Thema, das bitte ggf. dann nochmal separat adressieren; wobei das Ändern der Profile nach meiner Erfahrung eher was seltenes ist, da "muß man halt einmal durch"...