Autor Thema: [neues feature] WeekdayTimer mit weekprofile steuern  (Gelesen 4649 mal)

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 9254
  • eigentlich eher "user" wie "developer"
[neues feature] WeekdayTimer mit weekprofile steuern
« am: 19 November 2019, 13:26:15 »
Hallo zusammen,

nachdem immer mal wieder gefragt wird, ob man nicht auch für FHEMWEB ein Eingabewidget für den WeekdayTimer basteln könnte, von meiner Seite die Gegenfrage, inwieweit Interesse besteht, für Heizungs-Devices das Modul "weekprofile" als Input-Option zu nutzen. (Selbst bin ich jedenfalls im Moment nicht in der Lage, was völlig freies auch für andere Schaltbefehle zu basteln, aber wer das außerhalb FTUI beisteuern mag: feel free).

Anbei eine Testversion, die als Schaltzeitpunkt (neben dem Üblichen) auch "weekprofile:<device-name>[:<profilname>][:<true>]" akzeptiert.

"weekprofile" wird als Schlüsselbegriff verwendet und muß so vorangestellt werden, dann kommt der Name des weekprofile-Devices, danach der (optionale) Profilname.

EDIT: erfolgt nun durch das Attribut "weekprofile"!

Ist kein Profilname angegeben, wird "default" verwendet, ist das letzte (optionale) Argument "true", wird das Sonntags-Profil für $we verwendet (also auch für Sa., wenn man nichts spezielles über holiday2we eingestellt hat; das überschreibt/ergänzt also ggf. auch die Angaben im Sat.-Profil).

Als erste Schaltzeit wird 00:10 Uhr verwendet, da der WDT erst selbst die eigene Tagesauswertung fahren muß, bevor anschließende Timer für den Tag gesetzt werden können.

Demnach wären z.B. folgende WDT-Definition möglich (die Sinnhaftigkeit der Befehlskombi sei mal dahingestellt):
defmod Timer_Umwaelzpumpe WeekdayTimer MYSENSOR_98 !$we|05:50|on-till:06\:00 $we|06:55|on 12:30|on !$we|14:06|on-till:14\:07 16:00|on 7|17:04|off 8|17:09|off \
weekprofile:wprof_test:neu_1:true\
{}

defmod Timer_Umwaelzpumpe WeekdayTimer MYSENSOR_98 !$we|05:50|on-till:06\:00 $we|06:55|on 12:30|on !$we|14:06|on-till:14\:07 16:00|on 7|17:04|off 8|17:09|off \
weekprofile:wprof_test:true\
{}
defmod Timer_Umwaelzpumpe WeekdayTimer MYSENSOR_98 weekprofile:wprof_testdefmod Timer_Umwaelzpumpe WeekdayTimer MYSENSOR_98 weekprofile:wprof_test::truedefmod Timer_Umwaelzpumpe WeekdayTimer MYSENSOR_98 weekprofile:wprof_test:trueTheoretisch können auch mehrere Profile kombiniert werden (bisher nicht getestet; EDIT: sinnvoll ist das vermutlich auch nicht!), da weekprofile seinerseits nur Temperaturprofile kann (aber die dann an diverse unterschiedliche Hardware verteilen), ist das ganze nur für Temperaturlisten tauglich.

Bei einer "kaputten" weekprofile-Angabe (z.B. das Device oder Profil existiert nicht) sind derzeit alle Timer weg.

Im Moment gibt es (außer der Änderung der DEF des WDT) noch keine Möglichkeit, dem WDT updates mitzuteilen, die man in weekprofile gemacht hat, aber das einzubauen dürfte bei entsprechendem Interesse kein Problem sein EDIT: erledigt (müßte aber sinnvollerweise auch von weekprofile aus angestoßen werden, also im dortigen Code ggf. ergänzt, was aber auch kein Problem sein dürfte).

Ich nutze das selbst (im Moment) noch nicht, (also weder den WDT zur Steuerung von Heizungs-Devices noch weekprofile) und kann daher nur bedingt was zur Praxistauglichkeit des Konzepts an sich sagen. Der Vorteil liegt m.E. darin, dass man damit eine zentrale Stelle für alle Arten von Heizungsthermostaten haben kann, die alle Profile verwaltet (ohne dass man Textfiles direkt selbst editieren muß) und das dann an sehr unterschiedliche Device-Typen verteilt (CUL_HM, HMCCUDEV, MAX ...), und mittelbar (über den WDT) dann die Option besteht, das auch an Typen weiterzugeben, die selbst intern gar keine Profile unterstützen (evtl. z.B. ZWave-Thermostate). Interessant ist das evtl. auch für die, die $we-Fähigkeiten an den HK-Thermostaten vermissen.

Also: Feedback und Ideen sind willkommen, und wenn ich damit auf dem Holzweg bin oder einen besseren Weg übersehen habt, laßt es mich wissen...

Gruß, Beta-User

EDIT: aktuelles Modul siehe neuerer Beitrag
« Letzte Änderung: 01 Dezember 2019, 15:03:00 von Beta-User »
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | BT@OpenMQTTGateway
svn:MySensors, WeekdayTimer, RandomTimer, AttrTemplate => {mqtt2, mysensors, httpmod}
Gefällt mir Gefällt mir x 1 Liste anzeigen

Offline sledge

  • Full Member
  • ***
  • Beiträge: 492
  • Für den guten Zweck: www.rallye-for-a-cause.org
    • Abenteuer erleben und Menschen helfen!
Antw:[Konzeptvorstellung] weekprofile für WeekdayTimer nutzen
« Antwort #1 am: 19 November 2019, 15:59:58 »
Habe ich bisher immer wieder mal vermisst, aber nicht als "feature-Wunsch" in den Raum geworfen.

Werde es mal mit einem Test-Raum ausprobieren.
FHEM: debian Intel-NUC / 25 x MAX!, 15 x HM-bidcos, MQTT, 3 x 1wire, 20 x Shelly, 20 x Tasmota, 12 x Yeelight, Opentherm-GW, Espeasy, alexa-fhem, kodi, unifi, musiccast, ...

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 9254
  • eigentlich eher "user" wie "developer"
Antw:[Konzeptvorstellung] weekprofile für WeekdayTimer nutzen
« Antwort #2 am: 19 November 2019, 16:11:26 »
 :) Das klingt gut...

Achtung: ich habe vorhin festgestellt, das es in weekprofile sowas wie "Topics" gibt. Das "kann" die jetzige Version (noch) nicht, es dürfte aber nicht so schwer einzubauen sein.
Allerings muss das "true" für die WE-Steuerung dann woanders hin (evtl. direkt als "weekprofileWE").
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | BT@OpenMQTTGateway
svn:MySensors, WeekdayTimer, RandomTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline sledge

  • Full Member
  • ***
  • Beiträge: 492
  • Für den guten Zweck: www.rallye-for-a-cause.org
    • Abenteuer erleben und Menschen helfen!
Antw:[Konzeptvorstellung] weekprofile für WeekdayTimer nutzen
« Antwort #3 am: 19 November 2019, 18:45:30 »
Hi,

also gerade mal einzwei Fälle getestet (an einem Dummy) - funktioniert IMHO einwandfrei. Habe ein paar Schaltzeiten / Heizabschnitte im weekprofile angelegt, dann den weekdaytimer neu "initialisiert" via defmod und bei verbose 5 zugeschaut. Funktioniert.

Spaßeshalber auch noch "switchInThePast" gesetzt - geht auch.

Also den ersten Test hat es bei mir überstanden.

Werde ggf am Wochenende mal einzwei WDT umstellen auf weekprofile und beobachten.

Danke für die Umsetzung - schöne Idee. Könnte generell für alle Heiz-Devices gemacht werden ;-) Hätte man ein einheitliches UI...
FHEM: debian Intel-NUC / 25 x MAX!, 15 x HM-bidcos, MQTT, 3 x 1wire, 20 x Shelly, 20 x Tasmota, 12 x Yeelight, Opentherm-GW, Espeasy, alexa-fhem, kodi, unifi, musiccast, ...

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 9254
  • eigentlich eher "user" wie "developer"
Antw:[Konzeptvorstellung] weekprofile für WeekdayTimer nutzen
« Antwort #4 am: 20 November 2019, 12:40:38 »
So, kleiner update von meiner Seite:

Nachdem ich mich etwas in die topic/profile-Sache eingelesen habe, ist es vermutlich für die updates aus weekprofile heraus einfacher, wenn wir die dort üblichen Mechanismen nutzen. Das erwartet ein Attribut namens "weekproflie", in dem der Name des Profils drinsteht, also gibt's das seit neuestem :) .

Demnach verkürzt sich die Angabe in der DEF auf "weekprofile:<device-name>[:<true>]", also z.B.
defmod Timer_Umwaelzpumpe WeekdayTimer MYSENSOR_98 !$we|05:50|on-till:06\:00 $we|06:55|on 12:30|on !$we|14:06|on-till:14\:07 16:00|on 7|17:04|off 8|17:09|off \
weekprofile:wprof_test:true\
{}
attr Timer_Umwaelzpumpe WDT_Group test3
attr Timer_Umwaelzpumpe commandTemplate set $NAME  $EVENT
attr Timer_Umwaelzpumpe switchInThePast 1
attr Timer_Umwaelzpumpe weekprofile neu_1

So wie ich das verstanden habe, müßte der WDT dann bereits (bei topic-Verwendung in weekprofile) das zum gerade eingestellten Topic passende Profil erhalten.

Um updates auszulösen, gibt es einen neuen setter: "restart" Dieser löst eine komplette Neuinitialisierung des WDT aus und sollte sich damit eigentlich ohne weiteres zum "Anschubsen" seitens weekprofile eignen, wenn das "seinen Abnehmern" Änderungen mitteilen will.

Kann aber noch nicht sagen, ob das alles noch unbedachte Nebenwirkungen hat, glaub's aber im Moment nicht...

Was bei einigem Nachdenken vermutlich nach wie vor nicht optimal sein dürfte: Ich gehe davon aus, dass Samstags zu viele Timer generiert werden, wenn die $we-true-Option gesetzt ist. Das kann dazu führen, dass Timer unbeabsichtigt geskipped werden usw.. Bitte darauf mal ein kritisches Augenmerk legen, ein Hilfsmittel zur Ansicht der Timer ist hier zu finden: https://forum.fhem.de/index.php/topic,104167.msg992793.html#msg992793.

Wenn, dann ist das aber eigentlich ein allgemeines Thema beim WDT, das auch schon lange bestand. Aber evtl. ist auch der Code schon immer schlauer als von mir grade angenommen...

Gruß und Danke für den Mut zum Testen!
« Letzte Änderung: 27 Dezember 2019, 14:29:50 von Beta-User »
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | BT@OpenMQTTGateway
svn:MySensors, WeekdayTimer, RandomTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline sledge

  • Full Member
  • ***
  • Beiträge: 492
  • Für den guten Zweck: www.rallye-for-a-cause.org
    • Abenteuer erleben und Menschen helfen!
Antw:[Konzeptvorstellung] weekprofile für WeekdayTimer nutzen
« Antwort #5 am: 20 November 2019, 20:12:14 »
Hi,

also die neue Version runtergeladen, ein neues Profil im weekprofile angelegt und das im Attribut hinterlegt - einwandfrei.

Damit kann ich mir vorstellen, am Wochenende mal einzwei echte Räume / Heizprofile umzustellen.

Was die von Dir geäußerte Befürchtung angeht bzgl. der zuvielen Timer - ich werde einen Raum mit einem speziellen $we Profil mit in den Test einbeziehen. Mal sehen, ob mir was auffällt.

Soweit schonmal danke - läuft gut bisher.

Gruß,

Tom
FHEM: debian Intel-NUC / 25 x MAX!, 15 x HM-bidcos, MQTT, 3 x 1wire, 20 x Shelly, 20 x Tasmota, 12 x Yeelight, Opentherm-GW, Espeasy, alexa-fhem, kodi, unifi, musiccast, ...

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 9254
  • eigentlich eher "user" wie "developer"
Antw:[Konzeptvorstellung] weekprofile für WeekdayTimer nutzen
« Antwort #6 am: 20 November 2019, 20:17:48 »
Danke schon mal für's feedback bis hierher!

Wenn du Lust hast, kannst du gerne auch die commandref (und später evtl. etwas Wiki) dazu beisteuern; bei den Wechselwirkungen mit weekprofile ist es vermutlich besser, wenn das jemand macht, der es auch nutzt. Bei mir werden das eher nur ein paar dürre Worte ;D .

Und bitte wirf' ein Augenmerk darauf, dass auch der letzte Timer am Tag wirklich abgearbeitet wird. Es gab dazu vorhin einen neuen Beitrag, der aber schon wieder geschlossen war, bevor ich dazu gekommen bin nachzuhaken, welche Version der TE überhaupt nutzt...

EDIT: die Probleme mit $we dürfte v.a. dann auftreten, wenn es um ein switchInThePast-Device geht (oder eines, das als Heizung automatisch erkannt wird).
« Letzte Änderung: 20 November 2019, 20:20:00 von Beta-User »
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | BT@OpenMQTTGateway
svn:MySensors, WeekdayTimer, RandomTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline sledge

  • Full Member
  • ***
  • Beiträge: 492
  • Für den guten Zweck: www.rallye-for-a-cause.org
    • Abenteuer erleben und Menschen helfen!
Antw:[Konzeptvorstellung] weekprofile für WeekdayTimer nutzen
« Antwort #7 am: 20 November 2019, 20:36:40 »
Kann ich machen. Muße zum Schreiben habe ich derzeit zwar eher weniger (gibt da noch ein paar Baustellen...), aber da kann ich gerne was beisteuern.

Die Frage ist, wie eng man das Zusammenspiel mit weekprofile verzahnen möchte - zB könnte ja auch der "send to device" Mechanismus von weekprofile benutzt werden, um das Attribut "weekprofile" im Zieldevice (also dem Weekdaytimer) zu setzen.... dann entfällt mW sogar das restart - zumindest hat wer bei mir mit setzen des Attributes sofort die Config aus dem weekprofile gezogen.

Müsste man mal mit "risiko" sprechen. Aber auch so finde ich das Zusammenspiel ganz nett - mir zumindest lieber als die Zeiten beim Define direkt mit angeben zu müssen... Werde ich direkt bei den von mir betreuten FHEM-Installationen umsetzen, sollte die Testphase erfolgreich abgeschlossen sein und das Ding in die Serie gehen ;-)

Das mit dem "letzten Timer am Tag" habe ich auch - aber eben eher nicht-deterministisch. Meistens klappt es, aber gelegentlich wurde halt eine Temperatur nicht entsprechend gesetzt (bei 16 WDT in meinem Produktivsystem). Also nie "alle am selben Tag", sondern bisher eher "zufällig". Hatte aber noch keine Muße, dem mit "verbose 5" hinterherzusteigen.


FHEM: debian Intel-NUC / 25 x MAX!, 15 x HM-bidcos, MQTT, 3 x 1wire, 20 x Shelly, 20 x Tasmota, 12 x Yeelight, Opentherm-GW, Espeasy, alexa-fhem, kodi, unifi, musiccast, ...

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 9254
  • eigentlich eher "user" wie "developer"
Antw:[Konzeptvorstellung] weekprofile für WeekdayTimer nutzen
« Antwort #8 am: 20 November 2019, 21:05:04 »
Wegen der Verzahnung hatte ich Risiko heute morgen mal angeschrieben, ich nehme an, er wird sich schon bei Gelegenheit melden.

Wenn ich den weekprofile-Code richtig deute, sucht sich das Modul die Devices zusammen, die bestimmten TYPEs sind (WDT fehlt da noch) und das "weekprofile"-Attribut gesetzt haben; es setzt das aber nicht selbst, sondern es wird vorausgesetzt (aber ab jetzt ja vorhanden). Dazu benötigt es noch eine "Command"-Info, aber das sollte einfach sein.

Zum Verständnis der aktuellen Version noch:
Setzt man das Attribut im WDT, führt das unmittelbar auch zu einer Anfrage an das weekprofile-Device aus der DEF (via "restart"), deswegen "wirkt" das auf dich so "nahtlos" ;) .

Was das "nicht-deterministische" Verhalten angeht, gibt es sicher eine Logik, und ich habe den dringenden Verdacht, dass das mit switchinthepast und $we zusammenhängt; die Lösung müßte sein, irrelevante Timer gar nicht erst zu setzen, also z.B. die $we-Timer eben nur am $we (das war eine Zeitlang anders), und eben ggf. auch umgekehrt (deswegen ist der Samstag m.E. in der Kombination weekprofile und WDT besonders spannend...).
Vermutlich muß dazu noch eine globalere Lösung her, mit der man dann zwischen einer "normalen" Wochentagsangabe und einer duch $we zu verdrängenden unterscheiden kann. Im ersteren Fall wird "additiv" vorgegangen (so ist das bisher, wenn ich es richtig deute), im anderen verdrängt $we das normale Tagsprofil (das ist in der Regel gewollt, vermute ich; und wer iVm. weekprofile "true" setzt, will das ausdrücklich...). Ich habe dazu eine Idee, aber so richtig im Code angeschaut/getestet ist es noch nicht.

Wird also vermutlich noch etwas dauern, bis es "svn-fähig" wird, aber an sich sehe ich im Moment jedenfalls auch für den Code bis dahin keine gravierenden Hürden für einen produktiven Einsatz. Im Prinzip sind es ein paar zusätzliche Kleinigkeiten und ein Parser, der die Rückmeldung von weekprofile in die "WDT-Sprache" übersetzt; letzterer scheint zu funktionieren, ab da (konkret: wenn es korrekt übersetzt im Internal "SWITCHINGTIMES" steht) ist es "wie gehabt"...
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | BT@OpenMQTTGateway
svn:MySensors, WeekdayTimer, RandomTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 9254
  • eigentlich eher "user" wie "developer"
Antw:[Konzeptvorstellung] weekprofile für WeekdayTimer nutzen
« Antwort #9 am: 21 November 2019, 18:25:30 »
...und noch ein update...

Das kann funktional nicht mehr als die andere, aber es ist jedenfalls bis dahin gediehen, dass man erkennen kann, welche Timer eigentlich nicht gesetzt werden sollen, wenn gleichzeitig $we ist. Leider bekomme ich es jedenfalls im Moment nicht hin, diese Info auch so auszuwerten, dass die betreffenden Timer gar nicht gesetzt werden; vielleicht hat jemand eine Idee, der Code ist (auch) an der Stelle unglaublich vertrackt (jedenfalls mit meinen Kenntnissen betrachtet).

Gruß, Beta-User
« Letzte Änderung: 27 Dezember 2019, 14:29:19 von Beta-User »
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | BT@OpenMQTTGateway
svn:MySensors, WeekdayTimer, RandomTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline Karflyer

  • Full Member
  • ***
  • Beiträge: 150
Antw:[Konzeptvorstellung] weekprofile für WeekdayTimer nutzen
« Antwort #10 am: 22 November 2019, 10:26:23 »
Hallo Beta-User,

nach dem Einspielen der neuen Programmversion habe ich nun folgende Fehlermeldung beim Neustart von FHEM im Log:

2019.11.22 10:17:52 1: PERL WARNING: Use of uninitialized value $st[3] in string eq at ./FHEM/98_WeekdayTimer.pm line 360.
Gruß
Stefan

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 9254
  • eigentlich eher "user" wie "developer"
Antw:[Konzeptvorstellung] weekprofile für WeekdayTimer nutzen
« Antwort #11 am: 22 November 2019, 10:39:32 »
Thx.

Ist zum Glück nur ein Warning, bitte mal so ändern:
$overrulewday = 1 if defined $st[3] && $st[3] eq "w";
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | BT@OpenMQTTGateway
svn:MySensors, WeekdayTimer, RandomTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline Karflyer

  • Full Member
  • ***
  • Beiträge: 150
Antw:[Konzeptvorstellung] weekprofile für WeekdayTimer nutzen
« Antwort #12 am: 22 November 2019, 10:58:05 »
Zitat
Thx.

Ist zum Glück nur ein Warning, bitte mal so ändern:
Code: [Auswählen]
$overrulewday = 1 if defined $st[3] && $st[3] eq "w";

Jetzt sieht es gut aus. Keine Fehlermeldung beim Neustart. Danke.

Gruß
Stefan

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 9254
  • eigentlich eher "user" wie "developer"
Antw:[Konzeptvorstellung] weekprofile für WeekdayTimer nutzen
« Antwort #13 am: 23 November 2019, 11:48:26 »
Anbei eine aktualisierte Fassung, die das warning beseitigt und vor allem (hoffentlich) eine Lösung für den "verlorenen" letzten Timer vom Vortag enthält.

Manko, das ich beim Testen festgestellt habe: Der Schaltzeitpunkt wird vom "nachgeholten" Timer übernommen, ändert man was an der DEF, wirkt sich das nicht auf diesen Schaltzeitpunkt aus, kann also sein, dass da noch Verbesserungspotential besteht. Aber besser ein (wahrscheinlich richtiger) Timer, der auch schaltet, als ein "vergessener"...

Viel Spaß beim Testen...
« Letzte Änderung: 27 Dezember 2019, 14:29:03 von Beta-User »
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | BT@OpenMQTTGateway
svn:MySensors, WeekdayTimer, RandomTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 9254
  • eigentlich eher "user" wie "developer"
Antw:[Konzeptvorstellung] weekprofile für WeekdayTimer nutzen
« Antwort #14 am: 25 November 2019, 20:58:15 »
Und wieder eine Aktualisierung:

Die sollte folgendes leisten:
- Es gibt einen anderen neuen setter "weekprofile". Der nimmt als Argument "<weekprofile-device>:<topic>:<profile>"
- Hat man mindestens eine weekprofile-Angabe in der DEF, gibt es ein Reading namens "weekprofiles" (ja, mit "s", sonst kommt da immer der aktuelle Readingwert, was nicht ganz optimal wäre, s.u.); das enthält beim Start mindestens eine Angabe mit dem Namen des ersten weekprofile in der DEF und :default:default" dahinter.
- Nutzt man später den setter, wird für jedes gültige weekprofile-Device (Name und TYPE passen) dann das triplett wie oben angegeben da reingeschrieben, das ganze für mehrere weekprofile-Devices Leerzeichen-separiert, wobei immer nur ein Eintrag pro weekprofile-Device gültig ist.
Ungültige Angaben/Versuche findet man mit verbose-3-Level im log.

Ist bisher nur kurz auf Funktionalität getestet, scheint aber soweit zu klappen, groß logs ausgewertet habe ich auch noch nicht...

Um nachzusehen, ob ein Topic- oder Profilwechsel jeweils geklappt hat, sollte man auch die lists des WDT jeweils ansehen.

Gruß, Beta-User
« Letzte Änderung: 27 Dezember 2019, 14:28:49 von Beta-User »
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | BT@OpenMQTTGateway
svn:MySensors, WeekdayTimer, RandomTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline Risiko

  • Developer
  • Sr. Member
  • ****
  • Beiträge: 692
Antw:[Konzeptvorstellung] weekprofile für WeekdayTimer nutzen
« Antwort #15 am: 25 November 2019, 23:48:09 »
Anbei eine erste Testversion von weekprofile, die WDT unterstütz.

Viel Spaß beim Testen.
« Letzte Änderung: 25 November 2019, 23:59:22 von Risiko »
Gefällt mir Gefällt mir x 2 Liste anzeigen

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 9254
  • eigentlich eher "user" wie "developer"
Antw:[Konzeptvorstellung] weekprofile für WeekdayTimer nutzen
« Antwort #16 am: 26 November 2019, 07:57:51 »
Vielen Dank mal vorab!

Jetzt muß ich "nur noch" das Problem mit dem $we lösen, und/oder das "true" für weekprofile deaktivieren (kann ja auch über einen einfachen Wechsel des Topics über weekprofile gemacht werden :) ), und mich mal in die Doku zu weekprofile einlesen, damit am Ende dazu eine halbwegs konsistente commandref in WDT entstehen kann...
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | BT@OpenMQTTGateway
svn:MySensors, WeekdayTimer, RandomTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 9254
  • eigentlich eher "user" wie "developer"
Antw:[Konzeptvorstellung] weekprofile für WeekdayTimer nutzen
« Antwort #17 am: 26 November 2019, 15:46:02 »
Es könnte sein, dass der Knoten bei den $we-Geschichten jetzt auch durch ist... :)

Wie ursprünglich schon angedacht, kann man bei den weekprofile-basierten Schaltzeiten ein ":true" hinten anhängen, dann verwendet der WDT (nur noch!) die für den Sonntag übermittelten Schaltzeiten automatisch für $we-Tage.
defmod Timer_Umwaelzpumpe WeekdayTimer MYSENSOR_98 weekprofile:wprof_test:trueFür "klassische" WDT-Schaltzeiten gibt es einen neuen, zusätzlichen Parameter, den man einfach hinten anfügt: "|w". Modifiziertes Beispiel aus der cref:
define wd    Weekdaytimer  device de         fr,$we|23:35|25   34|23:30|22|w 23:30|16 23:15|22    12|23:45|16|wDer sollte bewirken, dass der betreffende Schaltzeitpunkt nur an den Tagen aufgerufen wird, die kein $we sind.

Anbei nochmal eine Testversion ohne Doku, das kommt dann als nächstes, eventuelle Fehlermeldungen/Warnings im Log sind wie immer nicht auszuschließen.

Der Hauptpunkt, das Senden von weekprofile-Infos aus weekprofile heraus hat jedenfalls im Testsystem ohne weiteres funktioniert  :) .

Jetzt wäre also bitte ausgiebiges Testen durch euch angesagt ;) ::) :) .

Grüße,

Beta-User
« Letzte Änderung: 27 Dezember 2019, 14:28:28 von Beta-User »
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | BT@OpenMQTTGateway
svn:MySensors, WeekdayTimer, RandomTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline SibbeH

  • New Member
  • *
  • Beiträge: 47
Antw:[Konzeptvorstellung] weekprofile für WeekdayTimer nutzen
« Antwort #18 am: 26 November 2019, 16:57:29 »
Hallo Beta-User,

Können Sie auch Niederländisch im sub WeekdayTimer_InitHelper hinzufügen?
"nl" => ["Zondag", "Maandag", "Dinsdag", "Woensdag", "Donderdag", "Vrijdag", "Zaterdag", "weekend", "werkdagen"],

"nl" => ["zo",        "ma",          "di",          "wo",            "do",            "vr",        "za",           '$we',             '!$we'          ],

Gruß SibbeH
Raspberry Pi, CULV3, MAX Thermostat, MAX Wandthermostat, FS20AS1-2, FS20UE1-2, FS20PIRA, FS20DT, FS20UWS, UtilsMaxProf, UWZ

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 9254
  • eigentlich eher "user" wie "developer"
Antw:[Konzeptvorstellung] weekprofile für WeekdayTimer nutzen
« Antwort #19 am: 26 November 2019, 17:28:23 »
 :) Klar, anbei entsprechend aktualisierte Testversion!

(cref ist wg. "nl" auch noch entsprechend ergänzt).
(Jetzt muß es die Testversion nur noch in das svn schaffen...)
« Letzte Änderung: 27 Dezember 2019, 14:28:11 von Beta-User »
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | BT@OpenMQTTGateway
svn:MySensors, WeekdayTimer, RandomTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline SibbeH

  • New Member
  • *
  • Beiträge: 47
Antw:[Konzeptvorstellung] weekprofile für WeekdayTimer nutzen
« Antwort #20 am: 26 November 2019, 19:04:51 »
Danke sehr!

Sibbe
Raspberry Pi, CULV3, MAX Thermostat, MAX Wandthermostat, FS20AS1-2, FS20UE1-2, FS20PIRA, FS20DT, FS20UWS, UtilsMaxProf, UWZ

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 9254
  • eigentlich eher "user" wie "developer"
Antw:[Konzeptvorstellung] weekprofile für WeekdayTimer nutzen
« Antwort #21 am: 27 November 2019, 16:03:32 »
So, dasselbe nochmal mit (v.a. betreffend weekprofile, aber auch wg. der $we-Behandlung) aktualisierter commandref.

V.a. @Risiko, aber auch die Nutzer von dem weekprofile-Teil: Wäre nett, wenn du/ihr euch das mal ansehen könntet, ob das so paßt bzw. was wichtiges fehlt.
Da diese Version wohl auch das mit den verlorenen Timern "vom Vortag" löst, würde ich von meiner Seite dazu neigen, das eher zeitnah ins svn zu geben.

@Risiko: Wie siehst du das? Sind die Änderungen aus Anlaß der wdt-Ansteuerung irgendwie kritische/kniffelige Eingriffe gewesen (ich habe das nicht verglichen). Ansonsten würde ich noch eine Zwischenversion erstellen, die nur den patch wg. des Timers beinhaltet?
« Letzte Änderung: 27 Dezember 2019, 14:27:52 von Beta-User »
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | BT@OpenMQTTGateway
svn:MySensors, WeekdayTimer, RandomTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline Risiko

  • Developer
  • Sr. Member
  • ****
  • Beiträge: 692
Antw:[Konzeptvorstellung] weekprofile für WeekdayTimer nutzen
« Antwort #22 am: 29 November 2019, 17:49:55 »
Aus meiner Sicht spricht nichts gegen eine Aufnahme im svn (wenn das die Fragen war?)
Habe weekprofile eingecheckt.

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 9254
  • eigentlich eher "user" wie "developer"
Antw:[Konzeptvorstellung] weekprofile für WeekdayTimer nutzen
« Antwort #23 am: 29 November 2019, 18:02:41 »
Ja, das war die Frage.. ;D .

Danke für die super Zusammenarbeit!

Werde dann auch (eher morgen im Lauf des Tages) das dann ins svn schieben.

Wollen wir dazu noch eine "Ankündigung" irgendwo machen? Wäre evtl. für den einen oder anderen interessant, der (wie ich) weekprofile nicht auf dem Schirm hatte und/oder wdt auf die Seite gelegt, weil etwas unflexibel, was die Anpassung des Profils angeht...
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | BT@OpenMQTTGateway
svn:MySensors, WeekdayTimer, RandomTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline Risiko

  • Developer
  • Sr. Member
  • ****
  • Beiträge: 692
Antw:[Konzeptvorstellung] weekprofile für WeekdayTimer nutzen
« Antwort #24 am: 29 November 2019, 18:16:08 »
Ja, kann ich nur bestätigen.
Sehr gute Kommunikation und Zusammenarbeit !! So macht das Spaß.

Mir fällt da zuerst das wiki ein. Man könnte mind. auf den einzelnen Seiten zueinander verweisen.
Muss aber erstmal mein wiki-Account raus suchen ;)

Zudem sollte man in den jeweiligen Foren-Threads das kurz berichten.

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 9254
  • eigentlich eher "user" wie "developer"
Antw:[Konzeptvorstellung] weekprofile für WeekdayTimer nutzen
« Antwort #25 am: 29 November 2019, 19:15:57 »
Hab's eben auch noch geschafft, das ins svn zu schubsen, aber jetzt ist dann Zeit alle...

Wiki ist sicher ein Thema, kann ich bei Gelegenheit machen. (Ich habe eh' Heating_Control noch auf der Liste, da habe ich gestern den Warnlevel wg. deprecated hochgedreht), so dass das Thema Heizungssteuerung mit WDT irgendwie sowieso zur Überarbeitung im Raum steht.

(Aber falls sich jemand findet, der das in der Form tatsächlich im Einsatz hat bzw. dann auch gleich mit weekprofile "praxistauglich" aufbereiten könnte, wäre das natürlich super!).
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | BT@OpenMQTTGateway
svn:MySensors, WeekdayTimer, RandomTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 9254
  • eigentlich eher "user" wie "developer"
Antw:[neues feature] WeekdayTimer mit weekprofile steuern
« Antwort #26 am: 01 Dezember 2019, 15:06:13 »
Im Wiki zu weekprofile habe ich jetzt ein paar Takte geschrieben, hoffe, das ist ok so.

Das Wiki zu WeekdayTimer ist (na ja...) runderneuerungsbedürftig... Wird dauern.

Was das Announcement angeht, würde ich das im Themenbereich Heizungssteuerung noch etwas aufschieben (wg. dieser in manchen Situationen auftretenden log1-Meldung, die jetzt hoffentlich auch gefixt ist), und die, die hier in Kalendermodule mitlesen, haben es vermutlich dann auch mitbekommen, den Thread-Titel habe ich mal so geändert, dass es dem aktuellen Stand der Dinge entspricht.

Würde dazu vorschlagen, dass wir einen kurzen gemeinsamen Text dazu entwerfen, ich versuch mal was vorzubereiten?
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | BT@OpenMQTTGateway
svn:MySensors, WeekdayTimer, RandomTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline Risiko

  • Developer
  • Sr. Member
  • ****
  • Beiträge: 692
Antw:[neues feature] WeekdayTimer mit weekprofile steuern
« Antwort #27 am: 01 Dezember 2019, 19:12:32 »
Im Wiki zu weekprofile habe ich jetzt ein paar Takte geschrieben, hoffe, das ist ok so.
Prima, aus meiner Sicht ok.

Würde dazu vorschlagen, dass wir einen kurzen gemeinsamen Text dazu entwerfen, ich versuch mal was vorzubereiten?
Ok. Schreib aber nochmal wo genau.

Offline moustic999

  • New Member
  • *
  • Beiträge: 43
Antw:[neues feature] WeekdayTimer mit weekprofile steuern
« Antwort #28 am: 16 Dezember 2019, 09:45:29 »
Hi,

I tested the new combination of weekprofile and weekdayTimer, that's a great piec eof saoftware. It works very well  to manage my general heater temp.
However, At home each room is managed by a KNX thermostat ( no scheduling possible). Currently I use weekdayTimer to manage their scheduling.
I really like the new solution with weekprofile, but it is not possible to use it with my knx thermostat, because they does not work with temperature but with modes (comfort, standby, eco).
Should it be possible to extend weekprofile to be able to work either with temp (as today) or with mode ? that way, I think that almost any kind of heating would be covered.

regards,

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 9254
  • eigentlich eher "user" wie "developer"
Antw:[neues feature] WeekdayTimer mit weekprofile steuern
« Antwort #29 am: 16 Dezember 2019, 10:25:38 »
Thanks for the kind feedback.

Don't know whether this ist possible on the weekprofile side (then WeekdayTimer would also accept any command included in the delivered json structure), but perhaps you could use a (not really obvious) workaround at the knx thermostat side:
Set some elements in eventMap attribute to "transate" degree commands to the needed "keywords". Example:
attr <knx-thermostat-name> eventMap { usr=>{'22.0'=>'comfort','12.0'=>'standby','18.0'=>'eco' } }Then use the mentionned temperatures (22.0/12.0/18.0) in your weekprofile...

Hope, you got the idea behind that, otherwise don't hesitate to ask, as this may be very usefull for others, too ;) .
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | BT@OpenMQTTGateway
svn:MySensors, WeekdayTimer, RandomTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline moustic999

  • New Member
  • *
  • Beiträge: 43
Antw:[neues feature] WeekdayTimer mit weekprofile steuern
« Antwort #30 am: 16 Dezember 2019, 11:28:43 »
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.


Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 9254
  • eigentlich eher "user" wie "developer"
Antw:[neues feature] WeekdayTimer mit weekprofile steuern
« Antwort #31 am: 16 Dezember 2019, 12:03:01 »
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):
attr <knx-thermostat-name> eventMap { (whatever was there before & ) usr=>{'22.0'=>'dtp20 01','12.0'=>'dtp20 02','18.0'=>'dtp20 03' } }
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | BT@OpenMQTTGateway
svn:MySensors, WeekdayTimer, RandomTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline moustic999

  • New Member
  • *
  • Beiträge: 43
Antw:[neues feature] WeekdayTimer mit weekprofile steuern
« Antwort #32 am: 16 Dezember 2019, 12:56:19 »
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 ;-)

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 9254
  • eigentlich eher "user" wie "developer"
Antw:[neues feature] WeekdayTimer mit weekprofile steuern
« Antwort #33 am: 16 Dezember 2019, 13:25:09 »
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).
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | BT@OpenMQTTGateway
svn:MySensors, WeekdayTimer, RandomTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline JamBay

  • New Member
  • *
  • Beiträge: 19
Antw:[neues feature] WeekdayTimer mit weekprofile steuern
« Antwort #34 am: 20 Dezember 2019, 16:19:52 »
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.

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 9254
  • eigentlich eher "user" wie "developer"
Antw:[neues feature] WeekdayTimer mit weekprofile steuern
« Antwort #35 am: 20 Dezember 2019, 16:34:18 »
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):
attr <eq3-bt-thermostat-name> eventMap { usr=>{'6.0'=>'4.5','off'=>'4.5'} }
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | BT@OpenMQTTGateway
svn:MySensors, WeekdayTimer, RandomTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 9254
  • eigentlich eher "user" wie "developer"
Antw:[neues feature] WeekdayTimer mit weekprofile steuern
« Antwort #36 am: 20 Dezember 2019, 16:50:24 »
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  :) ...)
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | BT@OpenMQTTGateway
svn:MySensors, WeekdayTimer, RandomTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline JamBay

  • New Member
  • *
  • Beiträge: 19
Antw:[neues feature] WeekdayTimer mit weekprofile steuern
« Antwort #37 am: 20 Dezember 2019, 17:17:10 »
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 :
{ usr=>{'6.0'=>'desiredTemperature 4.5','off'=>'desiredTemperature 4.5'} }
Der Feature-Wunsch hat sich damit erledigt.
Gefällt mir Gefällt mir x 1 Liste anzeigen

Offline JamBay

  • New Member
  • *
  • Beiträge: 19
Antw:[neues feature] WeekdayTimer mit weekprofile steuern
« Antwort #38 am: 22 Dezember 2019, 15:27:04 »
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.

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 9254
  • eigentlich eher "user" wie "developer"
Antw:[neues feature] WeekdayTimer mit weekprofile steuern
« Antwort #39 am: 27 Dezember 2019, 16:13:45 »
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.
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | BT@OpenMQTTGateway
svn:MySensors, WeekdayTimer, RandomTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline persching

  • Full Member
  • ***
  • Beiträge: 195
Antw:[neues feature] WeekdayTimer mit weekprofile steuern
« Antwort #40 am: 29 Dezember 2019, 15:15:49 »
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??

Offline persching

  • Full Member
  • ***
  • Beiträge: 195
Antw:[neues feature] WeekdayTimer mit weekprofile steuern
« Antwort #41 am: 29 Dezember 2019, 19:35:46 »
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!

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 9254
  • eigentlich eher "user" wie "developer"
Antw:[neues feature] WeekdayTimer mit weekprofile steuern
« Antwort #42 am: 30 Dezember 2019, 09:42:52 »
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)...
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | BT@OpenMQTTGateway
svn:MySensors, WeekdayTimer, RandomTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline persching

  • Full Member
  • ***
  • Beiträge: 195
Antw:[neues feature] WeekdayTimer mit weekprofile steuern
« Antwort #43 am: 30 Dezember 2019, 10:35:03 »
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:

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.

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 9254
  • eigentlich eher "user" wie "developer"
Antw:[neues feature] WeekdayTimer mit weekprofile steuern
« Antwort #44 am: 30 Dezember 2019, 10:57:10 »
Ich muss sagen, dass ich mit den notify überhaupt nicht zurecht komme [...]
Deswegen hatte ich Hilfe angeboten; wie gesagt: mir geht es umgekehrt ;) .

Zitat
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:

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...

Zitat
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:
set WP_Thermostate send_to_device Urlaub:Flur WDT_FlurDa sollten auch "hinten" mehrere WDT-Devices auf einmal ansprechbar sein ;) .

Noch einfacher _könnte_ es sein (könnte, da ungetestet), folgenden Befehl zu nehmen:
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...

Zitat
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"...
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | BT@OpenMQTTGateway
svn:MySensors, WeekdayTimer, RandomTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline persching

  • Full Member
  • ***
  • Beiträge: 195
Antw:[neues feature] WeekdayTimer mit weekprofile steuern
« Antwort #45 am: 30 Dezember 2019, 11:33:03 »
Also wenn ich die Wahl hätte, dann würde ich natürlich auch die Variante
set WP_Thermostate restore_topic Urlaubsinnvoll 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. :)

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 9254
  • eigentlich eher "user" wie "developer"
Antw:[neues feature] WeekdayTimer mit weekprofile steuern
« Antwort #46 am: 30 Dezember 2019, 12:12:10 »
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.
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | BT@OpenMQTTGateway
svn:MySensors, WeekdayTimer, RandomTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline persching

  • Full Member
  • ***
  • Beiträge: 195
Antw:[neues feature] WeekdayTimer mit weekprofile steuern
« Antwort #47 am: 30 Dezember 2019, 13:12:03 »
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 set WDT_Flur weekprofile WP_Thermostate:Abwesenheit:Alle zuweisen. Weiterhin kann ich danach irgendwann wieder mit 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.

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 9254
  • eigentlich eher "user" wie "developer"
Antw:[neues feature] WeekdayTimer mit weekprofile steuern
« Antwort #48 am: 30 Dezember 2019, 13:45:48 »
Zu restore_topic:

commandref sagt
Zitat
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:
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:
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...)
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | BT@OpenMQTTGateway
svn:MySensors, WeekdayTimer, RandomTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline persching

  • Full Member
  • ***
  • Beiträge: 195
Antw:[neues feature] WeekdayTimer mit weekprofile steuern
« Antwort #49 am: 30 Dezember 2019, 17:03:16 »
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
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 attr WDT_Flur weekprofile Flur,Alle möglich?? Es wäre ja nur optional und man muss es nicht verwenden.

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 9254
  • eigentlich eher "user" wie "developer"
Antw:[neues feature] WeekdayTimer mit weekprofile steuern
« Antwort #50 am: 30 Dezember 2019, 17:20:26 »
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...
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | BT@OpenMQTTGateway
svn:MySensors, WeekdayTimer, RandomTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline persching

  • Full Member
  • ***
  • Beiträge: 195
Antw:[neues feature] WeekdayTimer mit weekprofile steuern
« Antwort #51 am: 30 Dezember 2019, 17:34:31 »
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.

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 9254
  • eigentlich eher "user" wie "developer"
Antw:[neues feature] WeekdayTimer mit weekprofile steuern
« Antwort #52 am: 30 Dezember 2019, 19:08:40 »
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).
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | BT@OpenMQTTGateway
svn:MySensors, WeekdayTimer, RandomTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline persching

  • Full Member
  • ***
  • Beiträge: 195
Antw:[neues feature] WeekdayTimer mit weekprofile steuern
« Antwort #53 am: 30 Dezember 2019, 22:05:30 »
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...

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 9254
  • eigentlich eher "user" wie "developer"
Antw:[neues feature] WeekdayTimer mit weekprofile steuern
« Antwort #54 am: 30 Dezember 2019, 22:27:37 »
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).
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | BT@OpenMQTTGateway
svn:MySensors, WeekdayTimer, RandomTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline persching

  • Full Member
  • ***
  • Beiträge: 195
Antw:[neues feature] WeekdayTimer mit weekprofile steuern
« Antwort #55 am: 30 Dezember 2019, 22:33:43 »
Arbeitstag oder nicht wird aktuell hauptsächlich über Ferien und Feiertage gesteuert. Das ist ausreichend genau...


Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 9254
  • eigentlich eher "user" wie "developer"
Antw:[neues feature] WeekdayTimer mit weekprofile steuern
« Antwort #56 am: 30 Dezember 2019, 22:47:04 »
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...?
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | BT@OpenMQTTGateway
svn:MySensors, WeekdayTimer, RandomTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline persching

  • Full Member
  • ***
  • Beiträge: 195
Antw:[neues feature] WeekdayTimer mit weekprofile steuern
« Antwort #57 am: 05 Januar 2020, 19:44:41 »
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???

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 9254
  • eigentlich eher "user" wie "developer"
Antw:[neues feature] WeekdayTimer mit weekprofile steuern
« Antwort #58 am: 05 Januar 2020, 22:31:32 »
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?
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | BT@OpenMQTTGateway
svn:MySensors, WeekdayTimer, RandomTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline persching

  • Full Member
  • ***
  • Beiträge: 195
Antw:[neues feature] WeekdayTimer mit weekprofile steuern
« Antwort #59 am: 06 Januar 2020, 08:41:08 »
Stimmt an das Topic "Nachtabsenkung" hab ich gar nicht gedacht.. Ich probiere es mal aus...  :)

Offline dlehmann69

  • Full Member
  • ***
  • Beiträge: 162
Antw:[neues feature] WeekdayTimer mit weekprofile steuern
« Antwort #60 am: 10 Januar 2020, 19:38:13 »
Hallo Jungs,

könnt ihr mir einen gedanklichen Anstoss geben. Das mit dem weekprofile und den Topics habe ich verstanden.

Mir fehlt nur noch eine Idee, wie ich mit dem WDT die jeweiligen Profile aktiviere. Das mit den Tagen und Zeiten brauche ich ja nicht mehr, kommt aus dem Profil. Wie aktiviert ihr die jeweiligen Profile zur entsprechenden Zeit mit dem WDT? Habt ihr da mal Beispiele für mich?

Danke schon mal im Voraus.
FHEM 5.9 Development auf Ubuntu 18.04.3 GIGABYTE GB-BACE mit Intel(R) Celeron(R) CPU N3150
CUL 3.4 FW 1.53 868 MHz für FS20, FHT
CUL 3.4 FW 1.66 868 MHz für HM
configDB; DbLog
FHT80, FS20, HMS, EM1000WZ, FHTTF, HM-LC-Sw1-DR; Lightify; HM-CC-RT-DN; HM-TC-IT-WM-W-EU; HM-SEC-SCO

Offline persching

  • Full Member
  • ***
  • Beiträge: 195
Antw:[neues feature] WeekdayTimer mit weekprofile steuern
« Antwort #61 am: 10 Januar 2020, 19:56:36 »
Hallo dlehmann69,
ich mach das z.B. für Nachtabsenkung so gelöst:

Topic: Nachtabsenkung Name: Alle

define Absenkung_DI DOIF ([Absenkung] eq "true") ({ WDTsetTopic("Nachtabsenkung","Alle") }) DOELSE ({ WDTsetTopic("Arbeitstag","Alle") })
Dazu dann in myUtils:

sub WDTsetTopic($$)
{
my ($myTopic,$myName) = @_;
my (@allWDT) = devspec2array("TYPE=WeekdayTimer");
if ($myName eq "Alle")
{
foreach(@allWDT)
{
fhem("set $_ weekprofile WP_Thermostate:$myTopic:$myName");
}
fhem("set WP_Thermostate restore_topic $myTopic");
}
else
{
my $myWDT = "WDT_".$myName;
fhem("set $myWDT weekprofile WP_Thermostate:$myTopic:$myName");
}
}

WP_Thermostate = weekprofile
Die Namen der WDT sind "WDT_Name" (z.B. Wohnzimmer)

Ruft man { WDTsetTopic("Urlaub","Wohnzimmer") } auf wird das Topic "Urlaub" mit dem Namen "Wohnzimmer" aktiviert, verwendet man als Name "Alle" dann werden alle Weekdaytimer in der Schleife aufgerufen und ein Topic für alle gesetzt.

Vielleicht kannst du etwas in dieser Art auch für dein Umfeld umsetzen.

Offline guhu

  • Full Member
  • ***
  • Beiträge: 128
Antw:[neues feature] WeekdayTimer mit weekprofile steuern
« Antwort #62 am: 10 Januar 2020, 20:25:55 »
Hallo,
das Beispiel mit der Nachtabsenkung verstehe ich nicht. Die Nachtabsenkung hat ja eher was mit bestimmten Zeiten zu tun, die habe ich einfach im Profil drin.

Erstmal vielen Dank für die Arbeit, das ist genau das, was ich brauchen kann.

Bei mir kommt das zum Einsatz bei den Kindern. Diese sind nur sporadisch zu Hause (Studenten). Ich nutze das Modul Homemode, das ich nur wärmstens empfehlen kann, da ich damit fast alle Doifs ablösen konnte.
Die Zimmer der beiden sind immer auf 16°C bei Abwesenheit. Wenn sie da sind, ist das entsprechende Temperaturprofil aktiviert. Das gin bisher nur mit einem Disable des WDT, nun geht es durch umschalten des Profils.

Ich habe also entsprechende Profile "Anwesend" und "Abwesend" (= konstant 16°C).

In Homemode habe ich nun bei den entsprechenden present bzw. absent-Einträgen eingestellt, dass der entsprechende Profil absent bzw. present im WDT mit set wdt weekprofile default:present bzw. default:abesent umgeschaltet werden. Das war es dann!

Was ich noch lösen wollte: wenn jeder aus dem Haus ist, mache ich eine generelle Absenkung um 2°C, wenn jemand da ist, muss das entsprechend wieder umgestellt werden. Das könnte man jetzt mit entsprechenden Profilen machen, aber das ist ja ziemlich mühselig. Hat da jemand eine elegante Lösung für?

FHEM 5.9 auf Synology DS918+ (in Docker), HM-CFG-USB2 mit hmlan, HM-CC-RT-DN, HM-SEC-SC-2, nanoCUL,a-culfw,Brennenstuhl-Steckdosen,-FB
Module:ENIGMA2,SONOS,FRITZBOX,FB_CALLLIST,WDT_TIMER,VCONTROL300

Offline persching

  • Full Member
  • ***
  • Beiträge: 195
Antw:[neues feature] WeekdayTimer mit weekprofile steuern
« Antwort #63 am: 10 Januar 2020, 20:48:26 »
Hallo,
das Beispiel mit der Nachtabsenkung verstehe ich nicht. Die Nachtabsenkung hat ja eher was mit bestimmten Zeiten zu tun, die habe ich einfach im Profil drin.

Die klassische Nachtabsenkung ist in der Heizungssteuerung hinterlegt. Beispielsweise von 22.30 - 4.30 Uhr. Das ist bei meiner Vissmann Gasheizung aber nur über 7°C Außentemperatur gültig. Fällt die Temperatur darunter wird die Zeit verkürzt. Bei ca. 0°C und weniger ist die Heizung durchgehend an. Temperatur ist dann in den Schlafräumen ist dann 19.5 °C eingestellt und je nachdem fällt die Temperatur auch darunter.
Das Thermostat versucht da natürlich entgegen zu steuern und lernt daraus auch. Was regelmäßig zu übersteuern führt. Die MAX Thermostate sind diesbezüglich bescheiden. Darum wirke ich dem entgegen indem ich die Thermostate auf 17°C absenken, wenn die Gasheizung aus ist.

Vielleicht ein sehr spezielles Problem von mir...
Gefällt mir Gefällt mir x 1 Liste anzeigen

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 9254
  • eigentlich eher "user" wie "developer"
Antw:[neues feature] WeekdayTimer mit weekprofile steuern
« Antwort #64 am: 10 Januar 2020, 21:56:10 »
Erstmal vielen Dank für die Arbeit, das ist genau das, was ich brauchen kann.
Danke für die Rückmeldung!
Tut immer wieder gut zu hören, dass das mit der Kombi der beiden Module eine gute Idee war :) .

Zitat
Was ich noch lösen wollte: wenn jeder aus dem Haus ist, mache ich eine generelle Absenkung um 2°C, wenn jemand da ist, muss das entsprechend wieder umgestellt werden. Das könnte man jetzt mit entsprechenden Profilen machen, aber das ist ja ziemlich mühselig. Hat da jemand eine elegante Lösung für?
Weiß nicht, ob es elegant ist, aber du könntest im Command Perl verwenden und damit $EVENT ändern (2 abziehen), wenn alle weg sind; ich arbeite zwar (noch) nicht mit Residents, aber es dürfte ja ein Resident-Reading geben, das du abfragen kannst, oder?
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | BT@OpenMQTTGateway
svn:MySensors, WeekdayTimer, RandomTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline guhu

  • Full Member
  • ***
  • Beiträge: 128
Antw:[neues feature] WeekdayTimer mit weekprofile steuern
« Antwort #65 am: 10 Januar 2020, 22:01:14 »
Gute Idee, danke!
FHEM 5.9 auf Synology DS918+ (in Docker), HM-CFG-USB2 mit hmlan, HM-CC-RT-DN, HM-SEC-SC-2, nanoCUL,a-culfw,Brennenstuhl-Steckdosen,-FB
Module:ENIGMA2,SONOS,FRITZBOX,FB_CALLLIST,WDT_TIMER,VCONTROL300

Offline dlehmann69

  • Full Member
  • ***
  • Beiträge: 162
Antw:[neues feature] WeekdayTimer mit weekprofile steuern
« Antwort #66 am: 11 Januar 2020, 09:41:57 »
Danke schön Mal für die Tipps.

Aber irgendwie stehe ich noch auf dem Schlauch. Heute habe ich wdt definiert mit Angabe von Tag|Zeit|Temperatur. Wie sieht an einem Beispiel die Definition mit weekprofile aus? Prinzipiell könnte man die Profile ja auch ohne wdt aktivieren. Was ist dann der Vorteil von wdt.

Sorry noch Mal aber hier blockiert mein logischer Verstand im Moment.
FHEM 5.9 Development auf Ubuntu 18.04.3 GIGABYTE GB-BACE mit Intel(R) Celeron(R) CPU N3150
CUL 3.4 FW 1.53 868 MHz für FS20, FHT
CUL 3.4 FW 1.66 868 MHz für HM
configDB; DbLog
FHT80, FS20, HMS, EM1000WZ, FHTTF, HM-LC-Sw1-DR; Lightify; HM-CC-RT-DN; HM-TC-IT-WM-W-EU; HM-SEC-SCO

Offline guhu

  • Full Member
  • ***
  • Beiträge: 128
Antw:[neues feature] WeekdayTimer mit weekprofile steuern
« Antwort #67 am: 11 Januar 2020, 11:29:00 »
Hi,
ich habe im weekprofil weekprf (ohne Topics) verschiedene Profile definiert. Nennen wir sie pr1, pr2, pr3.
Dann habe ich im WDT definiert:

define WDT  HzThrmst8_Clima weekprofile:weekprf:true

wobei HrzThmrst8 ein HM-Thermostat ist. Damit ist dem WDT das weekprofile zugeordnet.

Du kannst dann die verschiedenen Profile durch

set WDT weekprofile weekprf:default:pr1

das spezielle Profil aktivieren. Diesen set-Befehl kannst du zu jeder Zeit, z. B. in einem notify oder doif aufrufen und aktivieren.

default steht da, weil ich ohne topics arbeite.
FHEM 5.9 auf Synology DS918+ (in Docker), HM-CFG-USB2 mit hmlan, HM-CC-RT-DN, HM-SEC-SC-2, nanoCUL,a-culfw,Brennenstuhl-Steckdosen,-FB
Module:ENIGMA2,SONOS,FRITZBOX,FB_CALLLIST,WDT_TIMER,VCONTROL300

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 9254
  • eigentlich eher "user" wie "developer"
Antw:[neues feature] WeekdayTimer mit weekprofile steuern
« Antwort #68 am: 11 Januar 2020, 14:40:15 »
Prinzipiell könnte man die Profile ja auch ohne wdt aktivieren. Was ist dann der Vorteil von wdt.
Na ja, es gibt Zielgeräte (Thermostate), die keine Profile verwalten können, z.B. eQ-3-Bluetooth oder (manche?) Z-Wave's. Da braucht man eine Zwischenschicht wie eben WDT.
Dann wird das Profil@WDT auch nicht an den Thermostat übertragen, was credits spart (v.a. bei MAX wichtig)  und ggf. auch den EEPROM-Speicher; da hat man dann ggf. v.a., wenn man "kurzfirstiger reagieren will" (PRESENCE) kein schlechtes Gefühl...

Aber wie oft: es gibt viele Wege zum Ziel, mMn. ist das gg. der klassischen WDT-Definition einfacher, weil man pro Thermostat nur einen WDT benötigt. Ob überhaupt ein WDT benötigt wird, muß jeder selbst wissen...
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | BT@OpenMQTTGateway
svn:MySensors, WeekdayTimer, RandomTimer, AttrTemplate => {mqtt2, mysensors, httpmod}