[neues feature] WeekdayTimer mit weekprofile steuern

Begonnen von Beta-User, 19 November 2019, 13:26:15

Vorheriges Thema - Nächstes Thema

Beta-User

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
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

sledge

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

Beta-User

 :) 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-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

sledge

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

Beta-User

#4
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!
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

sledge

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

Beta-User

#6
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).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

sledge

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

Beta-User

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-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Beta-User

#9
...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
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Karflyer

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

Beta-User

Thx.

Ist zum Glück nur ein Warning, bitte mal so ändern:
$overrulewday = 1 if defined $st[3] && $st[3] eq "w";
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Karflyer

ZitatThx.

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

Beta-User

#13
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...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Beta-User

#14
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
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Risiko

#15
Anbei eine erste Testversion von weekprofile, die WDT unterstütz.

Viel Spaß beim Testen.

Beta-User

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-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Beta-User

#17
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:true
Fü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|w
Der 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
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

SibbeH

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, 3xCUNO, MAX Thermostat, MAX Wandthermostat, HM, HmIP. UWZ, WeekProfile

Beta-User

#19
 :) 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...)
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

SibbeH

Raspberry Pi, CULV3, 3xCUNO, MAX Thermostat, MAX Wandthermostat, HM, HmIP. UWZ, WeekProfile

Beta-User

#21
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?
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Risiko

Aus meiner Sicht spricht nichts gegen eine Aufnahme im svn (wenn das die Fragen war?)
Habe weekprofile eingecheckt.

Beta-User

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-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Risiko

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.

Beta-User

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-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Beta-User

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-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Risiko

Zitat von: Beta-User am 01 Dezember 2019, 15:06:13
Im Wiki zu weekprofile habe ich jetzt ein paar Takte geschrieben, hoffe, das ist ok so.
Prima, aus meiner Sicht ok.

Zitat von: Beta-User am 01 Dezember 2019, 15:06:13
Würde dazu vorschlagen, dass wir einen kurzen gemeinsamen Text dazu entwerfen, ich versuch mal was vorzubereiten?
Ok. Schreib aber nochmal wo genau.

moustic999

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,

Beta-User

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-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

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):
attr <knx-thermostat-name> eventMap { (whatever was there before & ) usr=>{'22.0'=>'dtp20 01','12.0'=>'dtp20 02','18.0'=>'dtp20 03' } }
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

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).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

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):
attr <eq3-bt-thermostat-name> eventMap { usr=>{'6.0'=>'4.5','off'=>'4.5'} }
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

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  :) ...)
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

JamBay

Zitat von: Beta-User am 20 Dezember 2019, 16:50:24
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.

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.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

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

Zitat von: persching am 29 Dezember 2019, 19:35:46
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.

Zitat von: persching am 29 Dezember 2019, 19:35:46
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-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

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:

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

Zitat von: persching am 30 Dezember 2019, 10:35:03
Ich muss sagen, dass ich mit den notify überhaupt nicht zurecht komme [...]
Deswegen hatte ich Hilfe angeboten; wie gesagt: mir geht es umgekehrt ;) .

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

ZitatUnd 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_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:
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...

ZitatEtwas 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-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

persching

Also wenn ich die Wahl hätte, dann würde ich natürlich auch die Variante
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.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

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

Beta-User

Zu restore_topic:

commandref sagt
ZitatTherefore 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-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

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

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...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

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).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

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).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

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...?
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

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?
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

persching

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

dlehmann69

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 6.0 Development auf Ubuntu 20.04 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

persching

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.

guhu

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,deCONZ,Brennenstuhl-Steckdosen,-FB
Module:ENIGMA2,SONOS,FRITZBOX,FB_CALLLIST,WDT_TIMER,VCONTROL300,WITHINGS

persching

Zitat von: guhu 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.

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

Beta-User

Zitat von: guhu am 10 Januar 2020, 20:25:55
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 :) .

ZitatWas 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-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

guhu

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

dlehmann69

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 6.0 Development auf Ubuntu 20.04 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

guhu

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,deCONZ,Brennenstuhl-Steckdosen,-FB
Module:ENIGMA2,SONOS,FRITZBOX,FB_CALLLIST,WDT_TIMER,VCONTROL300,WITHINGS

Beta-User

Zitat von: dlehmann69 am 11 Januar 2020, 09:41:57
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-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Beta-User

#69
Zitat von: moustic999 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.
FYI: Latest preview of WDT includes an option to map e.g. temperatures to KNX-specific synatax, see
https://forum.fhem.de/index.php/topic,111401.msg1113061.html#msg1113061 for details (the cref is in english, the KNX example was derived from the eventMap in this thread as reference).

Hope this helps as a workaround for use of weekprofile+WDT+KNX devices...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Wardancer

Hi,

versuche mich gerade daran zu verstehen, wie ich weekprofiles einsetzen könnte. Gibt es mittlerweile ein Beispiel, was jemand einmal posten könnte? Ein einfaches ohne Profile wäre ja schonmal ein Anfang. Ich stehe gerade auf dem Schlauch was ich jetzt wo, wie eintragen müsste und wie ich die WDT-Device(s?) einstellen müsste damit is klappt.

Danke für jeden Denkanstoß :)

guhu

Hier ein Beispiel für meinen Flur:
defmod HCF WeekdayTimer HzThrmst7_Clima weekprofile:weekprf:true {\
my $offset= ReadingsVal("HControl","offset",0);;\
my $tmp=$EVENT - $offset;;\
if ($tmp < 14) { $tmp=$EVENT;;}\
fhem "set $NAME desired-temp $tmp"\
}\

attr HCF userattr Heating_Control Heating_Control_map structexclude weekprofile
attr HCF alias Flur
attr HCF commandTemplate 1
attr HCF disable 0
attr HCF group Heizplan
attr HCF room Flur,Heizung
attr HCF switchInThePast 1

setstate HCF 20.0
setstate HCF 2021-01-01 08:30:00 currValue 20.0
setstate HCF 2020-10-12 21:51:02 disabled 0
setstate HCF 2021-01-01 08:30:00 nextUpdate 2021-01-01 21:00:00
setstate HCF 2021-01-01 08:30:00 nextValue 16.0
setstate HCF 2021-01-01 08:30:00 state 20.0
setstate HCF 2021-01-01 06:00:00 weekprofiles weekprf:default:FlurHO
FHEM 5.9 auf Synology DS918+ (in Docker), HM-CFG-USB2 mit hmlan, HM-CC-RT-DN, HM-SEC-SC-2, nanoCUL,a-culfw,deCONZ,Brennenstuhl-Steckdosen,-FB
Module:ENIGMA2,SONOS,FRITZBOX,FB_CALLLIST,WDT_TIMER,VCONTROL300,WITHINGS

Wardancer

Danke!

soweit ich das jetzt verstanden habe, braucht man weiterhin ein WDT pro Thermostat ( wegen dem Device, was man schalten möchte ), aber wieviele Weeprofiles gibts denn dann sinnvollerweise? Wie habt ihr das gelöst? Ein Weekprofile pro Thermostat, oder pro Thermostat-Gruppe? macht ihr das über Profile? Und wo kommen jetzt die Topics ins Spiel? Topics wären wohl dann sinnvoll, wenn man noch eine Urlaubsschaltung, oder einen Party-Mode möchte, oder?

guhu

ich habe alles in einem Device, ohne Topics gemacht. KISS
FHEM 5.9 auf Synology DS918+ (in Docker), HM-CFG-USB2 mit hmlan, HM-CC-RT-DN, HM-SEC-SC-2, nanoCUL,a-culfw,deCONZ,Brennenstuhl-Steckdosen,-FB
Module:ENIGMA2,SONOS,FRITZBOX,FB_CALLLIST,WDT_TIMER,VCONTROL300,WITHINGS

Beta-User

#74
Zitat von: guhu am 01 Januar 2021, 22:12:26
ich habe alles in einem Device, ohne Topics gemacht. KISS
Danke mal für die Rückmeldung, dass auch das stressfrei funktioniert.

Gedacht hatte ich das aber MIT Topics, und ich finde, das ist ebenfalls simpel, wenn man's mal verstanden hat...

Mal eine Erweiterung des Code-Beispiels:

1. Verbindung vom weekprofile-Device (weekprf) zum WeekdayTimer herstellen:
attr HCF weekprofile FlurUnter der "entity" "Flur" ist dann (mind. der Heizkörper "HzThrmst7_Clima") bekannt. Das könnten auch mehrere sein.

2. weekprofile-Device (weekprf) für Topic-Nutzung zulassen:
attr weekprf useTopics 1


3. Beispiele für Profile im topic:entity-Format (weekprofiles ist mein weekprofile-Device):
get weekprofiles profile_data default:Flurliefert:

{"Mon":{"temp":["19.0","21.5","20.5","21.0","19.0"],"time":["05:30","08:00","12:30","22:00","24:00"]},"Thu":{"temp":["19.0","21.5","20.5","21.0","19.0"],"time":["05:30","08:00","12:30","22:00","24:00"]},"Fri":{"temp":["19.0","21.5","20.5","21.0","19.0"],"time":["05:30","08:00","12:30","23:00","24:00"]},"Tue":{"time":["05:30","08:00","12:30","22:00","24:00"],"temp":["19.0","21.5","20.5","21.0","19.0"]},"Wed":{"time":["05:30","08:00","12:30","22:00","24:00"],"temp":["19.0","21.5","20.5","21.0","19.0"]},"Sun":{"time":["06:00","22:30","24:00"],"temp":["19.0","22.0","19.0"]},"Sat":{"temp":["19.0","22.0","20.5"],"time":["06:00","22:30","24:00"]}}
get weekprofiles profile_data Ferien:Flur
{"Tue":{"temp":["19.5","22.5","21.0","22.5","20.0"],"time":["06:30","07:30","09:00","22:30","24:00"]},"Wed":{"time":["06:30","07:30","09:00","22:30","24:00"],"temp":["19.5","22.5","21.0","22.5","20.0"]},"Sat":{"time":["06:30","07:30","09:00","22:30","24:00"],"temp":["19.0","20.0","21.0","22.0","20.0"]},"Sun":{"time":["06:30","07:30","09:00","22:30","24:00"],"temp":["19.0","20.0","21.0","22.5","20.0"]},"Thu":{"time":["06:30","07:30","09:00","22:30","24:00"],"temp":["19.5","22.5","21.0","22.5","20.0"]},"Mon":{"temp":["19.5","22.5","21.0","22.5","20.0"],"time":["06:30","07:30","09:00","22:30","24:00"]},"Fri":{"time":["06:30","07:30","09:00","22:30","24:00"],"temp":["19.5","22.5","21.0","22.5","20.0"]}} (Das ist weekprofile-intern nur eine Referenz auf ein anderes Profil).
Du kannst dann ja testweise diese Daten einfach mal nehmen und beide Profile mal als Musterprofile in weekprf anlegen. Das geht mit den obigen JSON schnell und einfach, z.B.:
set weekprofiles profile_data Ferien:Flur {"Tue":{"temp":["19.5","22.5","21.0","22.5","20.0"],"time":["06:30","07:30","09:00","22:30","24:00"]},"Wed":{"time":["06:30","07:30","09:00","22:30","24:00"],"temp":["19.5","22.5","21.0","22.5","20.0"]},"Sat":{"time":["06:30","07:30","09:00","22:30","24:00"],"temp":["19.0","20.0","21.0","22.0","20.0"]},"Sun":{"time":["06:30","07:30","09:00","22:30","24:00"],"temp":["19.0","20.0","21.0","22.5","20.0"]},"Thu":{"time":["06:30","07:30","09:00","22:30","24:00"],"temp":["19.5","22.5","21.0","22.5","20.0"]},"Mon":{"temp":["19.5","22.5","21.0","22.5","20.0"],"time":["06:30","07:30","09:00","22:30","24:00"]},"Fri":{"time":["06:30","07:30","09:00","22:30","24:00"],"temp":["19.5","22.5","21.0","22.5","20.0"]}}

Hier hatte ich dazu auch mal was geschrieben:
Zitat von: Beta-User am 23 Dezember 2020, 10:14:04
In das Eingabefeld (so man das überhaupt direkt nutzen will...!?!) gehören:
set <m2-devicename> weekprofile <weekprofile-devicename> <weekprofile-identifier>
<weekprofile-identifier> ist dabei ein Paar aus <topic>:<entity>.

Rund um diesen Beitrag sollte da etwas mehr dazu zu finden sein, gilt hier 1:1 genauso.

Kurzfassung:
(Mind.) ein weekprofile-Device muss existieren, dort sollte useTopics aktiviert sein.
Dann sollte es da einige Profile geben, wobei eben immer das, was "dasselbe Ziel" hat, unter einer "entity" gruppiert wird.
Im m2-Device sollte diese "entity" dann im Attribut "weekprofile" angegeben sein, damit weekprofile seine "Clients" darüber findet. (Im Moment sollte da der Name des m2-Device drin stehen, das kann man aber ändern). Nach jeder Anpassung des Attributs bitte einmal die DEF des m2-Device anfassen, damit weekprofile seine Clients aktualisiert.

Dann kann man über einen Topic-Wechsel direkt alle Clients ansteuern, weekprofile sendet dann genau den passenden Befehl an die "Schnittstelle" weekprofile-setter am m2-Device.
Ist zwar zu MQTT2_DEVICE, aber die Funktionalität ist hier wie dort identisch...

Es wäre gut, wenn jemand mal eine kleine Muster-Implementierung für's Wiki liefern würde; ich fand das ganze auch relativ komplex, bis das erst mal stand. Jetzt ist es so einfach, wie ich mir das ursprünglich mal gedacht hatte.

An der Stelle mal mein Testcode (!) für den Spirit. Der ist im Hauswirtschaftsraum, der hin und wieder auch zum Wäschetrocknen genutzt wird. Dann soll da geheizt werden, sonst nur ein Grundlevel gehalten, die Umschaltung der Topics macht ein THRESHOLD, der auf die Raumsensor-humidity "hört". Dabei macht es keinen Unterschied, ob da nur der eine WDT diese "entity" repräsentiert, oder ob es mehrere sind (oder auch "echte" HK-Thermostate direkt addressiert werden, was weekprofile ja auch kann), oder ob dann noch weitere Device da sind, die dieselben Topics kennen:get weekprofiles profile_data normal:Abstellkammer
{"Sat":{"time":["08:00","10:00","12:00","13:00","17:00","18:00","24:00"],"temp":["18.0","19.0","18.5","19.0","18.0","18.5","18.0"]},"Sun":{"temp":["18.0","19.0","18.5","19.0","18.0","18.5","18.0"],"time":["08:10","10:10","12:10","13:10","17:10","18:10","24:00"]},"Tue":{"time":["08:00","10:00","12:00","13:00","17:00","18:00","24:00"],"temp":["18.0","19.0","18.5","19.0","18.0","18.5","18.0"]},"Wed":{"time":["08:00","10:00","12:00","13:00","17:00","18:00","24:00"],"temp":["18.0","19.0","18.5","19.0","18.0","18.5","18.0"]},"Fri":{"time":["08:00","10:00","12:00","13:00","17:00","18:00","24:00"],"temp":["18.0","19.0","18.5","19.0","18.0","18.5","18.0"]},"Thu":{"time":["08:00","10:00","12:00","13:00","17:00","18:00","24:00"],"temp":["18.0","19.0","18.5","19.0","18.0","18.5","18.0"]},"Mon":{"time":["08:00","10:00","12:00","13:00","17:00","18:00","24:00"],"temp":["18.0","19.0","18.5","19.0","18.0","18.5","18.0"]}}get weekprofiles profile_data Trocknen:Abstellkammer{"Sat":{"time":["24:00"],"temp":["22.0"]},"Sun":{"temp":["22.0"],"time":["24:00"]},"Wed":{"temp":["22.0"],"time":["24:00"]},"Tue":{"time":["24:00"],"temp":["22.0"]},"Fri":{"time":["24:00"],"temp":["22.0"]},"Mon":{"time":["24:00"],"temp":["22.0"]},"Thu":{"time":["24:00"],"temp":["22.0"]}}defmod thd_Abstellkammer THRESHOLD Raumfuehler_Abstellkammer:humidity:3:60 weekprofiles |set @ restore_topic Trocknen|set @ restore_topic normal|0
attr thd_Abstellkammer desiredActivate 1
attr thd_Abstellkammer state_cmd1_gt on
attr thd_Abstellkammer state_cmd2_lt off


Kurz: man kann mit einem einzigen kurzen Befehl den kompletten Heizmodus eines Gebäudes umstellen, indem man das Topic wechselt. Ich finde das eher KISS als dann jeden WDT oder Thermostaten einzeln anfassen zu müssen ;) .
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

guhu

Danke, Beta-User, sehr schön.
Kann man so machen, wenn die verschiedenen Szenarien gleich sind, also bspw. "normal" und "Ferien".
Das ist so bei mir nicht der Fall. Ich habe für alle ein gewisses Wochenprogramm, manche Räume werden über Anwesenheit verschiedener Personen gesteuert, weil ich Kinder habe, die nur ab und zu da sind. Der jeweilige Raum wird dann über Presence gesteuert. Und dann eben eine generelle Übersteuerung, wenn jemand außer der Reihe zu Hause ist ("Ferien").
Dann finde ich das so -in Zusammenhang mit dem Homemode-Modul-einfach.
FHEM 5.9 auf Synology DS918+ (in Docker), HM-CFG-USB2 mit hmlan, HM-CC-RT-DN, HM-SEC-SC-2, nanoCUL,a-culfw,deCONZ,Brennenstuhl-Steckdosen,-FB
Module:ENIGMA2,SONOS,FRITZBOX,FB_CALLLIST,WDT_TIMER,VCONTROL300,WITHINGS

Beta-User

 :)
Klar, die Kombinationsmöglichkeiten sind vielfältig, ich wollte auch nur zeigen, wie das mit den Topics gedacht war und funktionieren _kann_...

Bei mir ist das mit der Präsenzfrage einiger Mitbewohner ähnlich, nur dass ich den Löwenanteil der Thermostate (CUL_HM) jetzt von weekprofile direkt "füttern" lasse und dann nur das Profil schlicht dadurch umgehe, dass ich auf "manual" umstelle, wenn in manchen Räumen/Bereichen keiner da ist...

Vermutlich kann man auch sehr komplexe Belegungs-Strukturen über Referenz-Profile abbilden, aber soweit bin ich auch noch nicht durchgedrungen bzw. hatte bisher den Bedarf auch nicht.

Das schöne ist ja, dass jeder sich das so zusammenstellen kann, wie er will. Habe halt festgestellt, dass das mit den Topics sich als erklärungsbedürftiger rausgestellt hat, wie ich ursprünglich mal gedacht hatte; daher eben auch mal ein Beispiel zum (hoffentlich) relativ einfachen Nachbauen ;D .
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Wardancer

Morgen zusammen,

ich glaube bei mir ist der Groschen gefallen, danke an die Beispiele! Und was ja richtig toll ist, sind die Referenzen im weekprofile .... ich hab hier, genauso wie ihr, einige Räume, die ich nur nach Anwesenheit von bestimmten Personen. unterschiedlich heize, und ich hatte schon befürchtet, dass ich dann alle Profile, die sich nicht verändern kopieren muss. Aber mit den Referenzen ist das super gelöst!
Jetzt brauch ich nur noch mal ne Stunde um das umzustellen :) .... Ich sag mal Bescheid wenn ich durch bin. Vielleicht ist mein Beispiel dann hinreciehdn komplex für den Wiki, oder so? Mal schauen

VG

guhu

ich habe die Thermostate auf "manual" stehen, wenn ich sie mit WDT steuere, damit die im Thermostat gespeicherten Profile nicht dem WDT-Profil in die Quere kommen. In den Thermostaten habe ich ein simplifiziertes, aber einigermaßen passendes Profil gespeichert. Sollte also FHEM ausfallen, kann ich die Thermostate von manual auf automatisch umstellen und habe dann ein Notfallprogramm. Mir ist wichtig, dass der ganze Haushalt zur Not auch ohne FHEM läuft.
FHEM 5.9 auf Synology DS918+ (in Docker), HM-CFG-USB2 mit hmlan, HM-CC-RT-DN, HM-SEC-SC-2, nanoCUL,a-culfw,deCONZ,Brennenstuhl-Steckdosen,-FB
Module:ENIGMA2,SONOS,FRITZBOX,FB_CALLLIST,WDT_TIMER,VCONTROL300,WITHINGS

Wardancer

Hallo zusammen,

kurze Rückmeldung von meiner Seite. Ich hab meine Steuerung jetzt komplett auf weekprofile umgestellt und bin überrascht, wie einfach es dann doch ist, wenn man ein paar kleine Sachen beachtet.
Was mich beeindruckt ist wirklich die Aktivierung von einem anderen Heizungsprofil. Da sah mein DoIf doch deutlich komplexer aus mit diversen Attributen die gesetzt werden mussten und dann auch noch nen Save der Config. Jetzt einfach Topic restoren mit einem set Befehl und alles läuft!

Ich hätte halt noch einen Vorschlag zum Vereinfachen: Könnte man nicht einfach wenn man eh im WeekdayTimer-Device per set das weekdaytimer-Profil setzt das ganze auch in das User-Attribut weekprofiles schreiben und saven? Ich fand das jetzt beim einrichten ziemlich doppelt gemoppelt .... Wenn man dann später was von Hand ändern möchte, kann man das ja trotzdem im Attribut hinterlegen ....

golem

Hallo zusammen,

ich stelle meine WeekdayTimer gerade auf eine benutzung mit weekprofile um. Was ich mich noch frage ist ob ich aud dem WDT auslesen kann welches Profig gerade aktiv ist.

Gruß golem
Pi - Max-Lan - 8x max Ht -3x Max WT - Max Fk -modbus umg103- 2x Arduino mit Firmata Ethernet- ws300 - 433Mhz Sender Empfänger - 7x 1wire ds1820

Beta-User

#81
Klar. Das sollte dann im Reading "wekprofiles" zu finden sein. Format: <weekprofile-Device-Name>:<Topic>:<entity>
(als <entity> bezeichne ich den "Namen" aus weekprofile-sicht; das entspricht in der Regel dem, was du für das (WDT-) Device im Attribut weekprofile stehen hast...)

ad:
Zitat von: Wardancer am 10 Januar 2021, 11:53:37
Ich hätte halt noch einen Vorschlag zum Vereinfachen: Könnte man nicht einfach wenn man eh im WeekdayTimer-Device per set das weekdaytimer-Profil setzt das ganze auch in das User-Attribut weekprofiles schreiben und saven? Ich fand das jetzt beim einrichten ziemlich doppelt gemoppelt .... Wenn man dann später was von Hand ändern möchte, kann man das ja trotzdem im Attribut hinterlegen ....
Kann das Anliegen nachvollziehen, aber es ist leider nicht so einfach, das im Code unterzubringen. Da man als User eh' nicht drumrum kommt, sich etwas intensiver mit der Materie zu beschäftigen, werde ich da keine Energie reinstecken.

Zwischenzeitlich ist aber das userattr "verbessert", indem man direkt den Auszug aus der Doku zu weekprofile erhält. Falls da jemand konkrete Verbesserungsvorschläge zum Wording hat, unterstelle ich mal, das @Risiko das gerne übernimmt.

PS: Danke auch für die positiven Rückmeldungen zu dem feature an sich!
Hat mich motiviert, auch das weitere "Zwischenmodul" MQTT2_DEVICE in die Client-Liste mit einbauen zu lassen - leider wurde die Welt dadurch nicht an allen Stellen übersichtlicher, aber ich hoffe auf eure Unterstützung beim "Aufschlauen" weiterer Interessenten (falls es solche gibt).  8)
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files