[Testversion] Heating_Control=>WeekdayTimer

[Beta-User]

Hallo zusammen,

anbei mal eine erste Testversion, um die hier angekündigte allgemeine Umstellung anzuschieben:

Was die weitere Roadmap angeht, war die Idee, mittelfristig Abschied von Heating_Control zu nehmen. Dafür muß WeekdayTimer (aus dem sowieso die Mehrzahl der Funktionen "geborgt" sind) noch ein paar Erweiterungen bekommen, was aber nicht so schwierig sein sollte.

Dem Vorschlag von Wzut hier folgend

b. Ich würde zuerst  WeekdayTimer auf einen Stand bringen das man ein Heating_Control  Device 1:1 ohne Änderung auf WeekdayTimer umstellen kann.

anbei eine erst mal nur grob angetestete Version, die das (fast) 1:1 ermöglichen sollte:

- das Attribut für die Fensterkontakte heißt in der Version nicht "windowSensor", sondern etwas generischer "WDT_delayedExecutionDevices"; eine Idee wäre, da zukünftig evtl. noch weitere Typen oder beliebige Bedingungen (Device:Reading:Vergleichswert:Vergleichsanweisung) aufnehmen zu können
- Da wir Heating_Control-Devices und "normale" WDT-Devices irgendwie gesondert behandeln sollten, gibt es ein neues Attribut "WDT_Group".
Das hat folgenden Hintergrund: es gibt in Heating_Control einen Funktionsaufruf via Perl (Heating_Control_SetAllTemps()), der auch im Wiki entsprechend dokumentiert ist, darüber hinaus gibt es noch einen zweiten (Heating_Control_SetTemp()). SetAllTemps() hat bisher "nur" alle Devices des Typs Heating_Control angesprochen. Da mir Perl-Aufrufe nicht mehr zeitgemäß erschienen sind, gibt es jetzt ein entsprechendes set, das mit dem weiteren Argument dann zwischen single, WDT_Group und all global (also alle, einschl. WDT) unterscheiden kann.

Wer also von Heating_Control zu WeekdayTimer wechseln will und/oder beim Testen helfen (ich hatte bisher keine Heating_Control-Devices definiert und wenn, dann wäre es nur ein Typ Hardware, zum anderen betrifft das dann ALLE WeekdayTimer-user, selbst wenn die die Funktionalität (erst mal) gar nicht nutzen!...):

- Modul durch beigefügte Version tauschen (Rechte beachten)
- RAW-Definition aufrufen, bisherige Definition kopieren (in einen geeigneten Editor wie Notepad++ oder kate) und dort wie folgt ändern:
-- defmod auf WeekdayTimer
-- attr ... windowSensor zu attr ... WDT_delayedExecutionDevices umbenennen
-- attr ... WDT_Group exHC_Device ergänzen
- altes Device löschen
- mit RAW-Import geänderte Definition vollst. übernehmen
- speichern
=> hoffen, dass alles funktioniert wie vorher .

Sollten ein paar Mutige bestätigen, dass das klappt, würde ich das Modul (ggf. etwas weiter bereinigt, der Code geht m.E. etwas durcheinander) bei Gelegenheit einchecken und dann damit anfangen, den Heating_Control-Code um eine "transferriere nach WDT-Funktion" und einige Warnhinweise auf deprecated ergänzen.

Wer bei Heating_Control bleiben will: auch kein Problem, das Modul kommt nur ggf. nach Contrib und wird nicht weiter supported.

(Hoffentlich) viel Spaß beim Testen bzw. keine Probleme...

Beta-User

EDIT: Anhang aktualisiert, set-Funktion umbenannt.
EDIT 2: Testversion für Heating_Control angefügt

[amenomade]

Test läuft.

Mir ist nicht klar, was ich in WDT_Group eintragen muss.
Ich nutze die setTemp Funktion in folgendem Kontext:
Jedes Zimmer hat 2 HC Devices: ein HC und ein HC_zuHause, die durch die "condition" Value(di_automatik) auf active oder inactive gesetzt werden.
Wenn ich di_automatik ändere, wird HC active und HC_zuHause inactive, oder umgekehrt. Und gleichzeitig möchte ich im Thermostat die entspr Temperatur setzen, um sofort die richtige Temperatur zu kriegen, und nicht bis zum nächsten Schaltpunkt des Programs warten

Code Auswählen Erweitern

defmod nt_di_Automatik DOIF ([di_Automatik:"auto"]) \
{Heating_Control_SetTemp("di_HC")}\
DOELSEIF ([di_Automatik:"zuhause"])\
{Heating_Control_SetTemp("di_HC_zuHause")}\
DOELSE\

Dazu brauche ich ab und zu gleichzeitig alle richtige Temperaturen von allen aktiven HC zu setzen: setAllTemp

[Beta-User]

Danke erst mal für das feedback und die Fragen !

Mir ist nicht klar, was ich in WDT_Group eintragen muss.

Irgendwas beliebiges, ein Beispiel hatte ich ja genannt. Um die identische Funktion wie bisher zu haben für alle übertragenen HC-Devices einheitlich, in deinem Setting ginge es jetzt z.B. auch raumweise (macht hier keinen Sinn) oder an/abwesenheitsbezogen.

Dazu brauche ich ab und zu gleichzeitig alle richtige Temperaturen von allen aktiven HC zu setzen: setAllTemp

Dazu gibt es jetzt die setter - einzelne mit single, setAllTemp wäre "group" (entsprechend der Gruppe, der das Device angehört, das den set-Befehl bekommt; damit ersetzt du die Perl-Kommandos.

Hoffe, das ist jetzt etwas klarer.

[amenomade]

Also...  Ich muss

Code Auswählen Erweitern

{Heating_Control_SetTemp("di_HC")}
durch

Code Auswählen Erweitern

(set di_HC single)
erstezen?

Und {Heating_Control_SetAllTemp()} durch was?

[Beta-User]

Also...  Ich muss

Code Auswählen Erweitern

{Heating_Control_SetTemp("di_HC")}
durch

Code Auswählen Erweitern

(set di_HC single)
erstezen?

Und {Heating_Control_SetAllTemp()} durch was?

Der single-Befehl ist fast korrekt. So sollte es klappen:

Code Auswählen Erweitern

set di_HC setTimer singlestatt "{Heating_Control_SetAllTemp()}" sollte "set di_HC setTimer group" funktionieren, vorausgesetzt, bei di_HC ist das Attribut "WDT_Group" auf irgendeinen Wert gesetzt und alle anderen Devices, die gleichzeitig mit diesem zu schalten sind, haben genau denselben Wert.

also:

Code Auswählen Erweitern

attr di_HC WDT_Group exHC_Device
attr di_HC_zuHause WDT_Group exHC_Device
attr xy_HC WDT_Group exHC_Device
attr xy_HC_zuHause WDT_Group exHC_Device
sollte dazu führen, dass ein "set di_HC_zuHause setTimer group" alle diese 4 Geräte prüft bzw. schaltet. Ein set auf eines der anderen drei würde dasselbe bewirken.

Hier kannst du jetzt aber prüfen, ob es Sinn macht, zwei Gruppen zu bilden (HC_zuhause und HC_away), und dann gleich nur die Gruppe mit setTimer anzusprechen, die grade zutrifft .

[amenomade]

Ok, diesmal hab ich verstanden! Danke

[Beta-User]

Kein Ding, die ursprüngliche Anleitung war eventuell auch etwas "dünn" (und außerdem die Formatierung mal wieder kaputt *grrrr*).

Bitte auch um Rückmeldung zu den Benennungen; jetzt könnte man die bei Bedarf noch recht einfach verbessern, wenn es erst mal mehr Leute so im Einsatz haben, wird das schwieriger. Ich hatte zunächst gar keine so klare Vorstellung, was eigentlich der Effekt sein soll und habe daher den Funktionsnamen (aus WDT) genommen. Kommt mir aber nicht unbedingt wie der Weisheit letzter Schluß vor, daher die Frage.

[amenomade]

Naja... zu bessere Verständnis hätte ich "setTimer" eher "setTemp" genannt.

Wegen WDT_group habe ich zuerst überlegt, ob das besser mit HC_group wäre, aber das Modul ist jetzt WeekdayTimer und nicht mehr Heating_Control. In dem Sinn ist WDT_group vielleicht schlechter für die Transition, aber doch besser für die Zukunft

[amenomade]

Naja... zu bessere Verständnis hätte ich "setTimer" eher "setTemp" genannt.

Wobei... WeekdayTimer ist auch nicht nur für Heizungsthermostate gedacht. setTemp hätte für Rollos keinen Sinn.

[amenomade]

IM Device Specific Help habe ich:

If you want to have set all WeekdayTimer their current value (after a temperature lowering phase holidays) you can call the function WeekdayTimer_SetParm("WD-device") or WeekdayTimer_SetAllParms().
This call can be automatically coupled to a dummy by a notify:
define dummyNotify notify Dummy:. * {WeekdayTimer_SetAllTemps()}

Strange

[Beta-User]

Naja... zu bessere Verständnis hätte ich "setTimer" eher "setTemp" genannt.

Hatte ich in der Tat kurz überlegt. Der Punkt ist aber der: Man kann mit der Funktion alle WDT-Devices auf den aktuellen Wert setzen, wenn sie switchInThePast gesetzt haben oder als "heating" erkannt werden (weil sie in gängigen Formaten Temperaturen als setter haben).

Das ist also sehr viel generischer als nur Temperatur. (Aber eigentlich auch was anderes als "Timer").
Nächster Ansatz wäre gewesen, ein "executeNow" draus zu machen. Paßt aber auch nicht, weil "Fensterkontakte" und delayCondition beachtet werden. Also vielleicht "redoSetCheck"?

Wenn jemand was cleveres einfällt: genau darum frage ich...

(gilt auch für group und global; letzteres könnte auch "all_WDTs" heißen?)

(die cref habe ich nur auf die Schnelle upgedated, dürfte automatisiertes search&replace sein, das kommt (hoffentlich ) raus; danke für den Hinweis...)

[amenomade]

WeekdayTimer_SetParm("WD-device") or WeekdayTimer_SetAllParms().

Das heisst aber, es gab schon Perl Funktionen, Ersatz zu HC_SetTemp und setAllTemp?

[amenomade]

Wenn Du dabei bist, wünsche ich mir ein FHEMWEB Widget à la Weekprofile https://wiki.fhem.de/wiki/Weekprofile#FHEMWEB_Widget

Vielleicht aber eine andere Baustelle

[Beta-User]

Das heisst aber, es gab schon Perl Funktionen, Ersatz zu HC_SetTemp und setAllTemp?

Es gab Perl-Funktionen, aber in Heating_Control. Über die Gründe, warum das in der cref des WDT steht, mag ich nicht spekulieren, sachlich ist es m.E. schon immer falsch gewesen, hat aber funktioniert, wenn HC auch geladen war...

Ich sehe im Moment keinen Vorteil, wenn man Perl-Funktionen anbietet, und unter altem Namen würde ich die ungern beibehalten, es ist für neue Nutzer sonst vermutlich sehr schlecht nachvollziehbar, was das soll. Aber bitte: Ihr seid die User, ihr dürft euch äußern .

Das mit dem widget ist mir - zumindest im Moment - eine ganze Ecke zu hoch (und evtl. ein javascript-Thema, und da bin ich dann definitiv raus). War ein Thema, das igami angehen wollte, wenn er mal mehr Zeit hat (u.a. deswegen wäre es auch gut, nur ein Modul im Hintergrund beachten zu müssen). Aber wenn jemand Lust hat, und sowas beisteuern mag und kann: gerne!

[amenomade]

Code Auswählen Erweitern

1110 ########################################################################
1111 sub WeekdayTimer_SetParm($) {
1112   my ($name) = @_;
1113
1114   my $hash = $modules{WeekdayTimer}{defptr}{$name};
1115   if(defined $hash) {
1116      WeekdayTimer_DeleteTimer($hash);
1117      WeekdayTimer_SetTimer($hash);
1118   }
1119 }
1120 ################################################################################
1121 sub WeekdayTimer_SetAllParms() {            # {WeekdayTimer_SetAllParms()}
1122
1123   my @wdNamen = sort keys %{$modules{WeekdayTimer}{defptr}};
1124   foreach my $wdName ( @wdNamen ) {
1125      WeekdayTimer_SetParm($wdName);
1126   }
1127   Log3 undef,  3, "WeekdayTimer_SetAllParms() done on: ".join(" ",@wdNamen );
1128 }
1129
steht aber doch in 98_WeekdayTimer.pm

Aber egal. Ich finde deine Lösung mit set Kommandos viel schöner als auf Perl wechseln zu müssen. Mehr in der Philosophie von Fhem

[Beta-User]

steht aber doch in 98_WeekdayTimer.pm

Danke für den Hinweis!
(Grummel, manchmal sollte man die cref vielleicht intensiver lesen , sonst wäre mir ohne deinen Hinweis nicht aufgefallen, dass wir hier eine unnötige Doppelung haben, nur weil die Funktionen anders angeordnet sind als im HC-code... Ergo werde ich das so umbauen, dass für die set-Aufrufe diese Funktionsaufrufe genutzt werden, aber mit der neuen Option des gruppenweisen Aufrufens).

Aber egal. Ich finde deine Lösung mit set Kommandos viel schöner als auf Perl wechseln zu müssen. Mehr in der Philosophie von Fhem

Vielleicht gibst du mir noch Rückmeldung zur Benennung? Kann mich da auch an dem vorhandenen "setParm" orientieren und statt global "all" zulassen, die Gruppe dann mit "WDT_group", damit es zum Attributnamen besser paßt?

[amenomade]

Ich mag "set <name> setTimer xxx" nicht, da es für mich nach (Zeit-)Timer, also Verzögerung, klingt.
"set <name> setParm xxx" ist m.M.n. in dem Sinn besser, aber set...set... naja...

Mir ist auch etwas wie "current" aufgefallen: "set <name> currentParm all|group|single" oder  "set <name> currentValue all|group|single" finde ich nicht schlecht

WDT_group ist OK

Warum soll ich aber der einzige sein, der eine Meinung hat?

[Beta-User]

Hmmm, in der Regel lesen die meisten erst mal mit, bis ihnen was gar nicht gefällt.

Das mit setset fand ich auch nicht so prickelnd, das mit dem impliziten Hinweis auf den geltenen Parametersatz finde ich eigentlich ganz gut. Würde jetzt noch ein "apply" davor setzen (statt "set..."), und das ganze noch mit einer "Richtung" ergänzen, also:

Code Auswählen Erweitern

set <name> applyCurrentParamsTo all|WDT_group|single
Werde etwas brauchen, bis das dann Eingang in die nächste Testversion findet, solange bleibt für dich bzw. die bisher nur Mitlesenden Zeit, noch was kreativeres vorzuschlagen .

[eurofinder]

Die Kombination

Code Auswählen Erweitern

set <name> applyCurrentParamsTo all|WDT_group|single
finde ich schon etwas zu viel.

Wenn ich ein set-Kommando absetze, sollte klar sein, dass ich die aktuellen (current) Werte ändern (apply) will.

Daher mein Vorschlag:

Code Auswählen Erweitern

set <name> WDT_Params all|WDT_group|single

Gruß
eurofinder

[Beta-User]

Lesen ja doch noch andere hier mit ...

Kann mit dem neuen Vorschlag auch gut leben, hätte aber vielleich noch eine ganz andere Variante:

Code Auswählen Erweitern

set <device> switchInThePast (this|WDT_group|TYPE)

Ist zwar auch lang, aber der Zusammenhang zwischen dem Attribut und dem setter wäre so evtl. durch den ersten Teil klarer. Der zweite Parametrierungsteil wäre dann noch etwas "sprechender"(?). Die Länge finde ich nicht so dramatisch, denn händisch eingeben wird man das sowieso in den seltensten Fällen (und ich mache grade mit eine ZWave-Schalter rum, da sind die Commands teilweise noch deutlich länger...).
Wer die Funktionalität benötigt, wird in der Regel sowieso in die cref und/oder das Wiki schauen bzw. das in FHEMWEB mal austesten, wo sich die Angebote aus den dropdowns ablesen lassen .

[amenomade]

switchInThePast: ein set und ein Attribut mit gleichem Name finde ich eher irreführend (auch wenn es irgendwie ja eine Abhängigkeit gibt). Daher lieber die Variante von eurofinder.

[Beta-User]

So,

Im ersten Beitrag gibt's ein aktualisiertes Modul, war dann am Ende gar nicht so dramatisch, das vollends aufzubohren.

Jetzt kann (=optional!) WeekdayTimer_SetAllParms()auch mit einem Gruppennamen aufgerufen werden, die set-Aufrufe ohne Perl entsprechen dem Vorschlag von eurofinder:

Code Auswählen Erweitern

set <name> WDT_Params single|WDT_group|all

Wäre nett, wenn sich noch ein, zwei Tester finden würden .

[Beta-User]

Im ersten Post jetzt auch eine (hoffentlich finale) Fassung von Heating_Control.

Da gibt es ein neues "set" mit dem sich HC-Geräte einfach auf WeekdayTimer umstellen lassen, alle kommen dann in eine Gruppe, so dass sie auch zukünftig miteinander geschaltet werden können.

Der Anwender muß dann nur seinen Code durchsuchen, ob er irgendwo die Perl-Aufrufe aus HC nutzt. Das läßt sich leider nicht so einfach automatisiert umstellen.

Danach das "save" nicht vergessen...

Rückmeldung wäre nett, ansonsten gehe ich davon aus, dass das ganze recht unproblematisch ist und checke das bei Gelegenheit ein .

[maseb]

Hallo,

ich habe mir die Testversion von WeekdayTimer installiert.

Bei einem WeekdayTimer Device erhalte ich im LOG eine Fehlermeldung

2019.05.11 15:56:34 3 : [HZ_WZ_2] TYPE 'dummy' of CUL_FHTTK_9b6e10 not yet supported, CUL_FHTTK_9b6e10 ignored - inform maintainer

Das ist ein FS20 Fenster Sensor der über FHEM2FHEM angeschlossen ist und als attr HZ_WZ_2 WDT_delayedExecutionDevices angelegt ist.

Kann man da etwas machen?

Grüße
Rudi

[Beta-User]

@all zur Info:

Da bisher keine kritischen Rückmeldungen kamen, habe ich die beiden Module eben in's svn geladen, die kommen also morgen via update.

Für das Ausphasen des HC habe ich noch keinen Zeitplan.

Das ist ein FS20 Fenster Sensor der über FHEM2FHEM angeschlossen ist und als attr HZ_WZ_2 WDT_delayedExecutionDevices angelegt ist.

Frage: war das vorher ein HC-Device, das mit dem dummy-FK "konnte" (dürfte eigentlich auch vorher nicht gegangen sein), oder ist das ein feature request?

Im Moment sollte es anders gehen: über eine Perl-Funktion im entsprechenden Attribut.

Was ich gerne noch machen würde, wäre die "Devices"-Sektion mit entsprechenden (vereinfachten) Abfragemöglichkeiten zu ergänzen. Das kann aber etwas dauern...

[maseb]

Ja das war vorher ein HC Device. Mit diesem lief das dummy als attr WindowSensor.

Jetzt mit WeekdayTimer eben nicht mehr.

Im Moment sollte es anders gehen: über eine Perl-Funktion im entsprechenden Attribut.

Kannst du mir verraten wie..

Grüße
Rudi

[Beta-User]

Ich habe eben ins svn eine aktualisierte Version eingecheckt, die mit [Oo]pen.* in _state_ bei dummy-Geräten klarkommen sollte.

Da das bei dir ein FHTTK ist, kann es sein, dass f2f das auch nach Window (?) spiegelt, nicht in state. Dann bitte ein userreading anlegen, das Window-Events nach state doppelt.

Ansonsten sollte eigentlich ein

Code Auswählen Erweitern

ReadingsVal("CUL_FHTTK_9b6e10","state","closed") =~ /open/
als delayedExecutionCond funktionieren.

Wenn das nicht klappt bitte die möglichen Readings bzw. Reading-Werte liefern (ggf. ein list).

[ToKa]

Hi beta-user,

bin gerade dabei mein Heating_Control Devices auf das neue WeekdayTimer umzustellen. Zwei Dinge sind mir dabei aufgefallen bzw. funktionieren nicht:
1. Meine ReadingsGroup Devices, welche die Heating_Control Device verwendet haben, haben beim Umstellen den Bezug zum Device verloren. Kann man aber durch manuelles Ändern wieder herstellen.
2. Das Alias Attribut wird nicht übernommen. Aber auch manuell leicht wieder ergänzbar.
3. Ich habe in meinen Heating_Control Devices eine stateFormat Anweisung verwendet, mit der die neue Version von WeekdayTimer Probleme hat.

Code Auswählen Erweitern

{\
my $cValue = ReadingsVal("E2_ez_THKV_Heizkoerper_Fenster_hC_01","currValue","");;\
my $idx = index($cValue,":");;\
if ($idx != -1) {\
$cValue = substr($cValue,0,$idx);;\
}\
my $nValue = ReadingsVal("E2_ez_THKV_Heizkoerper_Fenster_hC_01","nextValue","");; \
$idx = index($nValue,":");;\
if ($idx != -1) {\
$nValue = substr($nValue,0,$idx);;\
}\
return "nächste Schaltung: ".ReadingsVal("E2_ez_THKV_Heizkoerper_Fenster_hC_01","nextUpdate","")." ".$cValue." ==> ".$nValue\
}

Die Fehlermeldung lautet:
Error evaluating E2_ez_THKV_Heizkoerper_Fenster_hC_01 stateFormat: Experimental aliasing via reference not enabled at (eval 14507) line 2.

Muss ich hier in meinem stateFormat was ändern oder muss hier im Modul noch etwas angepasst werden?

Beste Grüße und toll, dass Du die Module zusammenführst.
Torsten

[Beta-User]

2. Das Alias Attribut wird nicht übernommen. Aber auch manuell leicht wieder ergänzbar.

Moin,
hast du mir etwas mehr Info zum Umfeld? Klingt danach, als wären es die Testersionen gewesen iVm. einem älteren FHEM? (Das FUUID noch nicht kennt, weswegen statt der FUUID in dem RAW-Array das erste Attribut rausgeworfen wird).

1. Meine ReadingsGroup Devices, welche die Heating_Control Device verwendet haben, haben beim Umstellen den Bezug zum Device verloren. Kann man aber durch manuelles Ändern wieder herstellen.

Danke für den Hinweis; läßt sich vermutlich auch nicht vollständig abfangen, wenn z.B. der Modultyp mit abgefragt wird oder das anders benannte Attribut.

3. Ich habe in meinen Heating_Control Devices eine stateFormat Anweisung verwendet, mit der die neue Version von WeekdayTimer Probleme hat.

Hmm, bist du sicher, dass das auf die Umstellung zurückzuführen ist, un dnicht z.B. auf einen update der Perl-Version? An sich hat HC intern eigentlich nur Funktionen aus WDT verwendet und (fast) alles war ansonsten gleich. Wenn es das mit dem Perl-update nicht ist, muß ich mir das mal ansehen...

[majestro84]

So haben dann auch mal von Heat Control umgestellt bis jetzt sieht alles gut aus.
Haben ein manuell umgestellt und das andere Heat Contol Device mit dem neuen set Befehl

Code Auswählen Erweitern

converttoWDT im Heat Control hat super funtioniert.
Vielen Dank
Alex

[Beta-User]

So haben dann auch mal von Heat Control umgestellt bis jetzt sieht alles gut aus.

Danke für die Rückmeldung und das Testen!

Gehe ich recht in der Annahme, dass du einfach die Module genommen hast, die am WE über das update verteilt wurden, und FHEM auch ansonsten diesem Stand entspricht?

Bin mal gespannt, was ToKa rückmeldet, wo die diversen Schwierigkeiten bei ihm im einzelnen herkamen.

[majestro84]

Genau habe heute ein Thema Update mit den Modulen gemacht und alles mit diesen Versionen getestet

[ToKa]

Hallo Beta-User,

Klingt danach, als wären es die Testersionen gewesen iVm. einem älteren FHEM? (Das FUUID noch nicht kennt, weswegen statt der FUUID in dem RAW-Array das erste Attribut rausgeworfen wird).

fhem war aktuell (Update 11.05.2019) als ich gestern dann das Update und die Umstellung auf das neue WeekdayTimer gemacht habe. Meine Geräte hatten alle eine FUUID.

Danke für den Hinweis; läßt sich vermutlich auch nicht vollständig abfangen, wenn z.B. der Modultyp mit abgefragt wird oder das anders benannte Attribut.

Hatte weder den Modultyp noch den Alias in der RG, aber vielleicht bentuzt RG das ja intern.

Hmm, bist du sicher, dass das auf die Umstellung zurückzuführen ist, un dnicht z.B. auf einen update der Perl-Version? An sich hat HC intern eigentlich nur Funktionen aus WDT verwendet und (fast) alles war ansonsten gleich. Wenn es das mit dem Perl-update nicht ist, muß ich mir das mal ansehen...

Schwer zu sagen, da ich mir das stateFormat schon lange nicht mehr angeschaut habe, da die Geräte über die RG dargestellt werden. Ein Perl-Update habe ich zumindest nicht bewusst gemacht oder mitbekommen, dass es auf meinem PI eines gegeben hätte. Aktuell handelt es sich um die Version: This is perl 5, version 24, subversion 1 (v5.24.1). Ich habe nun nach dem Fehler gegoogelt und es gab sogar einen Treffer hier im Forum. Es lag an den doppelten ;; bzw. den \. Nachdem ich diese entfernt habe, ist das stateformat wieder ok.

Funktional konnte ich bislang keinen Unterschied oder gar Fehler feststellen.

Beste Grüße
Torsten

[Beta-User]

Moin ToKa,

Danke für die Rückmeldungen, wegen des Verlusts des alias-Attributs muß ich wohl nochmal nachbessern, da scheint in der Tat zu viel rauszufliegen, hoffe, ich kann das zeitnah einchecken.

Ob die RG wegen des lösch-Befehls direkt verändert wird? (Müßte man testen, das wäre dann aber kaum ohne größeren Aufwand zu ändern...)

Das mit dem stateFormat dürfte geklärt sein, oder?

[ToKa]

Hallo Beta-User,

für alle denen noch die Umstellung bevorsteht, wäre es sicherlich gut, wenn der Alias erhalten bleibt. Ist ja kein exotisches Attribut.

RG hat ja nicht jeder im Einsatz - vielleicht reicht ja ein Hinweise in der Doku. Ja stateFormat ist geklärt.

Beste Grüße
Torsten

[Beta-User]

Das mit alias sollte "gegessen" sein (genauer: ab morgigem update).

Wg. RG muß ich mal sehen, bisher habe ich noch keine Idee, warum da was genau passiert... Vielleicht findet sich noch eine Erklärung, aber nach meinem bisherigen Eindruck sollten RG's eigentlich nicht betroffen sein, die nur mit dem Namen operieren, aber vielleicht übersehe ich da auch was.

Insgesamt scheint es ja trotzdem so zu sein, dass die Umstellung eine einmalige kleine Angelegenheit ist.

[Marlen]

Hallo,
ich hab gester ein Update gemacht, seit dem geht mein Heating_Control nicht mehr.
Ich bin jetzt auf diesen Beitrag gestoßen.
Scheinbar gibt es das Modul nicht mehr.
Allerdings ist in meinem Heatin_Controll auch kein Attribut converttoWDT.
Was mach ich falsch und vor allem wie bekommt man sowas schneller mit.

LG
  Marlen

[Beta-User]

Dass das Modul "deprecated" ist, ist seit ca. 8 Monaten angekündigt, seitdem gab es (beim Systemstart) auch entsprechende Verbose 3-Meldungen, die seit ca. 7-8 Wochen auch mit Verbose 1 ausgegeben werden.

Um das jetzt zu "reparieren", kannst du das Modul aus contrib laden, z.B. so:

Code Auswählen Erweitern

{ Svn_GetFile("contrib/98_Heating_Control.pm", "FHEM/98_Heating_Control.pm") }
Um die alten Devices wieder zu aktivieren, muß FHEM anschließend mit der alten fhem.cfg gestartet werden.

Danach kannst du das entweder so weiter laufen lassen (es wird nicht mehr aus "FHEM" entfernt werden, ich werde bei updates@WeekdayTimer aber auch nicht mehr danach schauen, ob es mit Heating_Contol zusammenarbeitet), oder den Code dazu nutzen, die Umstellung zu machen und dann hinterher Heating_Control wieder aus FHEM löschen.

Eventuell schaust du bei der Gelegenheit, ob es Sinn macht, das neue Feature "weekprofile" bei WeekdayTimer auszutesten .

[Marlen]

Was heißt mit der alten FHEM.cfg gestartet werden.....wodurch hat die sich verändert?

[Beta-User]

In die laufende Konfiguration wird nur geladen, was zulässig ist. Wenn du also ein Modul aus dem Modulverzeichnis (hier durch update) löschst, wird das betreffende define nicht ausgeführt.
Speicherst du dann die geladene Konfiguration, ist das betreffende Device nicht mehr in der fhem.cfg zu finden... Kurz: Du darst nicht speichern, dann sollte alles beim alten sein (u.a. wegen solcher Effekte hat man irgendwann die Möglichkeiten begrenzt, die Konfiguration automatisiert zu speichern...).

[Marlen]

Aber die Device sind doch da.
Funktionieren aber nicht.
Dachte gelesen zu haben, dass es einen converter gegeben hat.

LG Marlen

Gesendet von meinem Mi 9T mit Tapatalk

[Marlen]

Ich hab gerade mal den WeekdayTimer probiert, kann das sein, dass man da keine Befehle mit ausführen kann?

Ich hab halt immer recht viele Befehle mit drin:

Code Auswählen Erweitern

Zeitschaltuhr_Aquarium Mo-So|04:00|RGB0225.000.050.000 Mo-So|06:30|RGB0000.000.100.100 Mo-So|11:30|aus Mo-So|15:30|RGB0000.000.100.100 Mo-So|16:30|RGB0000.000.100.100 Mo-So|20:00|RGB0012.050.012.000 Mo-So|21:00|RGB0006.025.006.000 Mo-So|22:28|RGB0003.012.003.000 Mo-So|23:00|RGB0001.005.001.000.000 Mo-So|23:59|aus {
######## Farben als reading ######
fhem "setreading Farben_Zeitschaltuhr_Aquarium Farbe $EVENT";
######r## Beleuchtung
if ($EVENT eq "RGB0000.000.100.100") {# Haupt-Beleuchtung
fhem "setreading Farben_Zeitschaltuhr_Aquarium Beleuchtung Haupt";
#fhem "set MQTT_Aquarium $EVENT";
fhem "set Aquatium_Farbe_dmy $EVENT";
}elsif ($EVENT eq "aus") {
#fhem "set MQTT_Aquarium RGB0000.000.000.000";
fhem "set Aquatium_Farbe_dmy RGB0000.000.000.000";
fhem "setreading Farben_Zeitschaltuhr_Aquarium Beleuchtung Aus";
}elsif (Value("Alarmanlage_Status") eq "Unscharf") { # aus schalten, kein Bewohner da
#fhem "set MQTT_Aquarium $EVENT";
fhem "set Aquatium_Farbe_dmy $EVENT";
fhem "setreading Farben_Zeitschaltuhr_Aquarium Beleuchtung Ambiente";
}else{
fhem "setreading Farben_Zeitschaltuhr_Aquarium Beleuchtung Ambiente";
}
}

LG
  Marlen

[Beta-User]

Nochmal zur Erläuterung:
WeekdayTimer ist das Modul, das praktisch den kompletten Code enthält, Heating_Control war nur eine Art wrapper für WDT, es werden intern WeekdayTimer-Funktionen genutzt. Fast der einzige "eigene" Code in dem HC-Modul ist der "converter", nach dem du suchst. Dass der da steht und nicht woanders, macht  auch Sinn, denn es wird intern "list"-Code genutzt, um die Konfiguration der _geladenen_ HC-Devices nach WDT zu "übersetzen". Das setzt aber voraus, dass die betreffenden Devices überhaupt vorhanden sind, was nicht der Fall ist, wenn sie zwar noch in der fhem.cfg stehen, aber mangels Moduldatei das define nicht ausgeführt werden kann...

Kurz:
Halte dich bitte einfach an die Anleitung aus meinem letzten Post und schau nicht nur auf das, was (noch!) in deiner fhem.cfg steht.

WDT kann zwischenzeitlich noch ein paar Dinge mehr als HC, aber wie gesagt auch alles, was HC kann (nur die "führe jetzt aus"-Aufrufe haben sich etwas geändert) deswegen macht es mMn. Sinn, nur noch dieses Modul anzubieten.

Der WDT aus dem letzten Post wird vermutlich funktionieren, wenn er als HC-Device funktioniert hatte. Hat er aber vermutlich nicht in vollem Umfang, denn da ist  ein Problem drin, nämlich die überflüssige Angabe "Mo-So". Das "zerschießt" aus irgendeinem mir noch nicht bekannten Grund die Darstellung der Readings (funktionieren müßte er trotzdem, aber man sieht es eben nicht). Versuch's mal mit folgenden Zeitangaben in der ersten Zeile

Code Auswählen Erweitern

Zeitschaltuhr_Aquarium 04:00|RGB0225.000.050.000 06:30|RGB0000.000.100.100 11:30|aus 15:30|RGB0000.000.100.100 16:30|RGB0000.000.100.100 20:00|RGB0012.050.012.000 21:00|RGB0006.025.006.000 22:28|RGB0003.012.003.000 23:00|RGB0001.005.001.000.000 23:59|aus {
######## Farben als reading ######
[...]

[Marlen]

Ja, aber warum wurden nach meinem letzten Update die HC Device noch angezeigt, wenn doch durch den Update das HC Modul gelöscht wurde?
Ist das dann schon irgendwie einfach im WTD gelaufen....? Kann doch nicht sein!
Irgendwie wird bei einen WTD der nur On OFF macht, das WTD dann zwar auf on oder off gesetzt, aber der Code darunter ignoriert!

LG
  Marlen

[Beta-User]

Sorry Marlen, aber das ist ein ziemliches Ratespiel, das wir hier veranstalten...

Fakt ist: Wenn irgendein Modul nicht da ist, wird ein eintsprechendes define nicht ausgeführt, wenn FHEM neu gestartet wird, wie nach einem update üblich. Anders gesagt: aus einem Heating_Control-Device wird niemals automatisch ein WeekdayTimer!
Solange FHEM nicht neu gestartet wird, passiert auch mit bereits geladenem Code nichts...

Zu dem zweiten Thema ("Irgendwie wird bei einen WTD der nur On OFF macht...") möchte ich dich bitten, einen neuen Thread aufzumachen und dort freundlicherweise auch ein list von dem Ding einzustellen... (Diese mehrzeilige Schreibweise, die du in dem anderen verwendet hast, ist was neues, und nicht dafür gedacht, dass man den Code auch noch kommentiert. Wenn du das willst/brauchst, solltest du myUtils-Code aufrufen, da sollte das kein Problem sein...)

[Marlen]

Sorry, dass ich hier für so ein durcheinander sorge.

Gestern ist mein System den Bach herunter gegangen und war nicht mehr erreichbar, sodass ich es neu aufsetzen musste.

Das "gute" daren ist, das mein HC wieder vorhanden ist und funktioniert.

Was kann ich jetzt mit

Code Auswählen Erweitern

set convert machen?

Kann dann der WDT keinen mehrzeiligen Code?

LG
   Marlen

[Beta-User]

also:

Beide Module (WDT und HC) müssen halbwegs aktuell sein. Ich würde dazu ein update empfehlen (das den HC-Code löscht!) und ein anschließendes

Code Auswählen Erweitern

{ Svn_GetFile("contrib/98_Heating_Control.pm", "FHEM/98_Heating_Control.pm") }
das ihn wieder einfügt. Erst _danach_ ein shutdown restart.

Dann kannst du aus irgendeinem HC-Gerät heraus die Umwandlung anschubsen, damit werden alle HC's in WDT's umgewandelt und einer eigenen Gruppe zugewiesen.... Du mußt nur noch speichern und sicherstellen, dass der "alte" HC-Code, um alle Devices zu aktualisieren (setAllTemps()) durch den neuen Aufruf ersetzt wird und auch diese Änderung(en) gespeichert sind. Aber das steht auch irgendwo (in der cref des HC, denke ich).


WDT "kann" auch mehrzeiligen Code, das Problem an dem von dir gezeigten war/ist, dass er zu allem Überfluß auch noch Kommentare enthält. Und das geht ziemlich sicher nicht, und ich gedenke im Moment auch nicht irgendwas einzubauen, um Kommentare zuzulassen. Dafür gibt es das Attribut comment oder myUtils (da kümmert sich dann Perl selbst darum, die Kommentare zu ignorieren).

[Marlen]

Du mußt nur noch speichern und sicherstellen, dass der "alte" HC-Code, um alle Devices zu aktualisieren (setAllTemps()) durch den neuen Aufruf ersetzt wird und auch diese Änderung(en) gespeichert sind.

Hallo,

was meinst du damit.

LG
  Marlen

[Beta-User]

? Warum schreibt man eigentlich commandref?!?

Zitat aus der von Heating_Control:

Achtung:
Heating Control wird nicht weiter gepflegt ("deprecated"). WeekdayTimer bietet identische Funktionalität, bei (annähernd) gleicher Syntax. Um alle Heating_Control Devices zu WeekdayTimer umzustellen, genügt ein set <name> ConvertToWDT, wobei als <name> ein beliebiges Heating_Control device angegeben werden kann. Die WeekdayTimer werden mit denselben Namen erstellt, alle früheren HC Geräte erhalten ein WDT_Group-Attribut mit Inhalt former_HC, so dass sie auch in Zukunft miteinander geschalten werden können. Statt des Aufrufs Heating_Control_SetTemp("HC-device") bzw. Heating_Control_SetAllTemps() steht Ihnen set <name> WDT_Params single oder set <name> WDT_Params WDT_Group zur Verfügung, sowie WeekdayTimer_SetParm("WD-device"), WeekdayTimer_SetAllParms() bzw. WeekdayTimer_SetAllParms("former_HC"), wenn Sie Perl nutzen möchten (former_HC ist hier nur ein Beispiel, es können beliebige Gruppennamen verwendet werden. 

Und weiter:

Wenn du beispielsweise nach einer Temperaturabsenkungsphase erreichen willst, dass  alle Heating_Controls ihren aktuellen Wert einstellen sollen, kannst du die Funktion Heating_Control_SetTemp("HC-device") or Heating_Control_SetAllTemps() aufrufen.
Dieser Aufruf kann per notify automatisch an ein dummy gekoppelt werden:
define HeizStatus2            notify Heizung:.*                          {Heating_Control_SetAllTemps()}

Ob du diese Aufrufe überhaupt verwendet hattest, kann ich nicht sagen, das mußt du selbst wissen bzw. prüfen. Hilfsmittel, (die ich aber nicht zu erläutern gedenke!) wären "grep" bzw. "configdb search"...

[Marlen]

Ok, hab jetzt erfolgreich auf WeekDayTimer umgestellt, war ja dann doch nicht so schlimm.

Aber wie bekomme ich das in Zukunft mit?

LG
  Marlen

[Beta-User]

Warum hätte es schlimm sein sollen?

Und was bedeutet "das" in diesem Zusammenhang:

Aber wie bekomme ich das in Zukunft mit?

Im Moment stehen keine wesentlichen Änderungen bei WDT im Raum... Die Abkündigung von HC erfolgte u.a. über die CHANGED-file und das log. Die CHANGED kann man sich in der vollen Länge jederzeit ansehen und auch nach dem durchsuchen, was einen interessiert (nicht nur WDT, sondern alle offiziellen Module betreffend), z.B. hier auch online: https://svn.fhem.de/trac/browser/trunk/fhem/CHANGED.

Und ins eigene FHEM-log sollte man sowieso von Zeit zu Zeit mal sehen...

[Marlen]

im FHEM-log steht sowas?

Dann kann man ja ein Notify darauf setzen, oder?

LG
  Marlen

[Beta-User]

M.E. doppelt nicht sinnvoll:

notify reagiert nicht per default auf irgendwas, was ein Modul in ein log schreibt. Das kann man zwar auf Umwegen erreichen, ABER:

Dann brauchst du immer noch einen klaren Trigger, den du aber nicht kennst, weil du nie wissen kannst, was für eine Info sich der jeweilige Modulautor ausgedacht hat...

MMn. ist es schlicht und ergreifend so, dass man hin und wieder halt (auf vielen Ebenen!) ein update machen sollte, und spätestens dann z.B. ins FHEM-Log schauen, ob da was zu finden ist, was "interessant" ist. Wenn du das betr. FHEM jeweils kurz nach einem Monatswechsel machst, ist das Log auch noch nicht so lang...

Kurz: die Logfile ist dazu da, hin und wieder mal auf Probleme durchgesehen zu werden. Das gilt natürlich vor allem dann, wenn man es selbst bemerkt, dass da vielleicht was "verbogen" ist, aber auch schon weit im Vorfeld ist ein ganz allgemeines Thema. Aus Perl-Warnings werden irgendwann eventuell Fehler und dann ggf. Programmabstürze. Nicht gleich, aber im Verlauf mehrerer Monate und Jahre kann das eben sein (oder manchmal auch nicht, wenn sich genügend Leute finden, die bessere Ideen und Lösungen haben). Da heißt es dann z.B. Jahre im Voraus: "... is deprecated here (and will be fatal in Perl xyz ...". Dann kann man weit im Vorfeld den eigenen Code ändern bzw. die Maintainer darauf hinweisen, dass da was unangenehmes am Horizont ist, und gut ist...

Punkt, aus, Basta!

[tomspatz]

Ich setzte hier mal an.
Habe soeben ein Update von meinm "alten" fhem gemacht.

Code Auswählen Erweitern

SVN rev:18080
fhem.pl:18029/2018-12-22

Alle alten Heating_Control sind noch vorhanden oder geblieben. Scheinen auchzu funktionieren. Ein konvertieren oben in der Eingabezeile schlägt fehl.
Auch an einem device selbst

Code Auswählen Erweitern

set <name> ConvertToWDT
ist das gar nicht in den sets zu sehen.

Das die Module raus müssen ist mir schon klar, interessieren würde mich nur ob ich da etwas falsch mache. Oder das es einfach in dem aktuellen fhem so ist.
unter /opt/fhem/FHEM/ ist auch die alte 98_Heating_Control.pm drin gebleben.

Also einfach per Hand neue WDT nach dem selben Muster anlegen ??

LG
Tom

[amenomade]

Hab dir schon im anderen Thread geantwortet: das Modul wurde durch das "update" nicht aktualisiert, da es jetzt in contrib/deprecated ist.
Du musst es aus contrib/deprecated holen, und in ./FHEM speichern. So hättest Du die fehlenede Befehle.

Aber ja, einfach manuell mit der gleichen Syntax als WDT definieren sollte funktionieren. Du musst auch gucken, ob Du die Perl Funktionen des Moduls wie setAllTemps() irgendwo benutzt hast, und entspr durch die von WDT erstetzen.

[tomspatz]

grrrr.....
ja das neu anlegen ist kein Problem. Ich verstehe nur nicht was ich da her holen soll wenn es noch da ist?

[amenomade]

Vergleich mal die Version die Du in ./FHEM hast mit der Version die Du in ./contrib/deprecated hast.

Versionnummer ist jeweils in der esten Zeile.

[Beta-User]

grrrr.....
ja das neu anlegen ist kein Problem. Ich verstehe nur nicht was ich da her holen soll wenn es noch da ist?

Wenn es noch da ist (was nach einem update nicht mehr der Fall sein sollte), ist ja erst mal alles "roger", und den Umstieg hat amenomade ja eigentlich auch gut erklärt.

Vielleicht nochmal eine Zusammenfassung der relevanten Fragestellungen:

1. Sollte man auf WeekdayTimer umstellen?
Unbedingt, denn selbst, wenn man es wieder zum laufen bekommt (z.B. mit der svn-contrib-Version), ist das nur eine Übergangslösung. Ich werde den HC-Code nicht mehr supporten und irgendwann in der näheren Zukunft vermutlich auch die Kompabilität brechen!

2. Hat das Nachteile?
Nicht wirklich. Es gibt ein paar Punkte, die man wissen sollte:
Heating_Control (HC) nutzt intern zu 80+% WeekdayTimer (WDT)-Code. Alles, was HC konnte, kann WDT auch.

Beide Module enthalten Perl-Kommandos, mit denen man jeweils nur die Devices vom Typ HC oder WDT ansprechen konnte. Da zukünftig dann alles WDT sind, muß man
- zum einen dann den Aufruf auf die WDT-Syntax umstellen und
- zum anderen die betreffenden "Gruppen" irgendwie auseinanderhalten.
Dafür gibt es (vermutlich nur) im WDT das betreffende Attribut.

3. Hat das Vorteile oder ist das nur Aufwand?
Zum Aufwand: HC nutzt eine (eingeschränkte) WDT-Syntax im define, man kann also die bisherigen Definitionen aus der cfg 1:1 weiterbenutzen, man muß nur den Modulnamen ändern (wie das konkret am einfachsten geht: s.u.). Der effektive Umstellungs-Aufwand ist daher relativ gering, wer unbedingt die alte Aufrufsyntax aus HC beibehalten will, kann das auch über einen eigenen myUtils-Wrapper oä. machen.

Die Umstellung hat dann aber m.E. v.a. für bisherige HC-Nutzer auch Vorteile:
- Man kann über die Gruppen-Option einfacher Teilgruppen ansprechen, das ganze ist ja nicht auf die Unterscheidung zwischen WDT und (ehemaligen) HC beschränkt...
- Vermutlich funktioniert das weekprofile-feature nur mit WDT. Damit kann dann auch das Nebeneinander zwischen vielen HC-Devices für unterschiedliche Szenarien entfallen, man tauscht einfach das betreffende Profil über WDT oder weekprofile aus (bitte ggf. erst mal die commandref konsultieren).

4. Wie macht man die Umstellung konkret?
a) Check deine Spracheinstellungen: WDT alt war default auf DE eingestellt, WDT heute zieht die Spracheinstellung aus global, wenn sie nicht lokal codiert wurde (was weiter möglich ist). Wichtig ist halt, dass ggf. die "Buchstaben-Tage" auch zur jeweils aktiven Spracheinstellung paßt. Ich empfehle Umstellung auf nummerische Syntax, also z.B. Di/Tue=>2.

b) Man kann dann entweder das HC-Modul aus dem contrib holen. Macht dann Sinn, wenn alles up-to-date ist und die HC-Devices nicht mehr geladen wurden. Nach dem Kopieren des Modulcodes FHEM neu starten und dann die Umstellungsroutine starten.
Dann noch die Aufruf-Frage aus dem alten HC-Modul klären und auf WDT umstellen und checken, ob das Löschen der alten HC-Devices irgendwo anders Nebenwirkungen hat - afaik kann das sein, wenn man LightScene nutzt und darin HC anspricht. Das registriert nämlich das Löschen des Geräts und entfernt es dann auch aus der LightScene. Kann man reparieren, indem man die config des Moduls aus einem Backup holt bzw. vorher wegspeichert und dann wieder drüberkopiert.
Zukünftig wird es ggf. notwendig sein, aus dem contrib-Zweig auch noch ein "legacy-WDT"-Modul zu laden (das wird meine letzte Aktion in Bezug auf HC sein!).

c) Wer vor dem Umdate mit "list -r TYPE=Heating_Control" eine Teilkopie der Konfiguration rauszieht, kann einfach dann das update machen, in den define/defmod-Anweisungen Heating_Control durch WeekdayTimer ersetzen und sollte dann bei jedem (ehemaligen) HC-Gerät noch ein passendes Gruppen-Attribut setzen.

d) Wer den setAllTemps-Befehl auch bei WDT genutzt hatte, sollte ggf. dann auch hier die Gruppenfunktion verwenden.

Done...

5. Was sollte man dann noch tun, wenn man von einer älteren Installation her kommt?
Beschäftigt euch mit den neuen Optionen:
- weekprofile hatte ich schon genannt. Soweit mir Rückmeldungen dazu vorliegen, sind alle, die die Kombi nutzen sehr zufrieden!
- Spracheinstellung checken (s.o.)
- WDT kann seit einiger Zeit auch Wochentage an $we-Tagen übersteuern, das ist der optionale letzte Parameter "w" in den Schaltzeitpunkten bzw. das "true" bei weekprofile-DEF.

Hoffe, damit alle evtl. verbliebenen Unklarheiten beseitigt zu haben und wünsche viel Erfolg bei der Umstellung!

Gruß, Beta-User

[tomspatz]

@Beta-User
vielen dank für die ausführliche Erklärung.
Eigentlich ist mir ALLS was du schreibst bzw. schon gelesen habe bewusst.
Was ich halt nur nicht verstehe das das "alte" noch einwandfrei funzt. Bin davon ausgegangen das es dann tatsächlich erst noch aus  ./contrib/deprecated kopiert werden muss. Da es dort aber nicht ist allerdings weiterhin die "alte" Version unter  /opt/fhem/FHEM/ vorhanden war mir das alles "komisch".

Die Umstellung auf WDT und somit der Abschied vom HC ist kein Problem, bislang.

schönen Sonntag

Tom

[Beta-User]

vielen dank für die ausführliche Erklärung.

Nix für, ich mußte das sowieso mal für's Wiki zusammenschreiben... Ist jetzt hier zu finden: https://wiki.fhem.de/wiki/Heating_Control#Umstellung_auf_Weekdaytimer

Eigentlich ist mir ALLS was du schreibst bzw. schon gelesen habe bewusst.
Was ich halt nur nicht verstehe das das "alte" noch einwandfrei funzt. Bin davon ausgegangen das es dann tatsächlich erst noch aus  ./contrib/deprecated kopiert werden muss. Da es dort aber nicht ist allerdings weiterhin die "alte" Version unter  /opt/fhem/FHEM/ vorhanden war mir das alles "komisch".

Na ja, kann durchaus sein, dass du mal ein update-exclude gesetzt hattest und damit die Verschiebe-Aktion nie stattgefunden hat o.ä.. Da "das alte" HC "schon ewig" eigentlich ein verkappter WDT ist, der Code von dem jeweils vorhandenen WDT "borgt", ist es kein Wunder, dass das weiter funktioniert hat (und jetzt weiter 1:1 funktioniert).
Ich will nur eben nicht mehr bei jedem Anfassen von WDT darauf achten müssen, dass es auch noch für HC "paßt", ohne dass das irgendjemandem einen echten Vorteil bringt, daher mußte HC eben irgendwann "weg"...

Die Umstellung auf WDT und somit der Abschied vom HC ist kein Problem, bislang.

Thx für die Rückmeldung!

Wie geschrieben: für die, die schon länger kein update mehr gemacht hatten und von HC her kommen, lohnt sich mAn. mal ein intensiverer Blick auf die Neuerungen in WDT .

[tomspatz]

cool
Noch ne Frage, vorher:

Code Auswählen Erweitern

defmod HeizungsteuerungAenderung notify Heizungssteuerung:.* {Heating_Control_SetAllTemps()}
Jetzt für ALLE WDT:

Code Auswählen Erweitern

defmod HeizungsteuerungAenderung notify Heizungssteuerung:.* {WeekdayTimer_SetAllParms()}
Oder auf eine bestimmte Gruppe mit WDT_Group

Code Auswählen Erweitern

defmod HeizungsteuerungAenderung notify Heizungssteuerung:.* {WeekdayTimer_SetAllParms(group_name)}
group_name jeweils ohne "" , richtig ??

[Beta-User]

Mit, sonst Erzeuger du bareword-Logeinträge....

[Beta-User]

Nachträge noch:
- Beim manuellen Wechsel von HC nach WDT muss der Inhalt von windowSensor nach delayedExecutionDevices;

- statt des Perl-Aufrufs

Code Auswählen Erweitern

defmod HeizungsteuerungAenderung notify Heizungssteuerung:.* {WeekdayTimer_SetAllParms("group_name")}kann man auch den setter an einem der zur Gruppe gehörenden WDT verwenden:

Code Auswählen Erweitern

defmod HeizungsteuerungAenderung notify Heizungssteuerung:.* set <wdt-name> WDT_params WDT_Group

Tendenziell würde ich aber empfehlen, das Gesamtkonstrukt mal anzusehen. Wenn du heute für einen Raum z.B. mehrere WDT definiert hast mit unterschiedlichen Profilen, von denen immer nur einer aktiv ist, kannst du die Profile auch in weekprofile hinterlegen und das ganze dann nur über einen WDT abbilden.
Dann wird nämlich einfach nur der "topic" am weekprofile-Device umgestellt, und der (bzw. dann eben mehrere/alle) WDT bekommen ihr neues Profil. Damit hat man (mit weekprofile) eine Stelle, an der der eigentliche Inhalt verwaltet wird .

[tomspatz]

ja das macht dann der Perl-Aufuf überflüssig.
Wenn ich noch etwas mir wünschen dürfte.....
Wenn man einem WeekdayTimer eine WDT_Group zuordnet, wäre es cool wenn diese dann in anderen WDT devices schon "auswählbar" wäre.
verstehst du mich?? 

[Beta-User]

Hmm, ich glaube ahnen zu können, was du meinst...
So ähnlich, wie es bei Räumen ist, oder?

Das ist eine Ecke, in der ich mich nicht auskenne und ich bezweifle auch, dass der Nutzen besonders groß ist. Es geht ja um's einmalige Einrichten, und da kann man eigentlich auch ganz gut mit devspec arbeiten (so man weiß, wie es geht). Schau' mal in der commandref_modular nach; "FILTER" kann man auch mehrfach verketten, und "list TYPE=WeekdayTimer WDT_Group" zeigt z.B. an, was wo bereits gesetzt ist...

[tomspatz]

Moin
ich hätte da noch eine Anregung, Wunsch. Angelehnt an dieses notify:

Code Auswählen Erweitern

defmod HeizungsteuerungAenderungWDT notify Heizungssteuerung:.* set HeizungssteuerungWohnzimmerAn WDT_params WDT_Group
attr HeizungsteuerungAenderungWDT comment Bei Änderung von "Heizungssteuerung" werden ALLE Mitglieder der selben Gruppe berücksichtigt.
attr HeizungsteuerungAenderungWDT group Heizung Einstellungen
attr HeizungsteuerungAenderungWDT room Steuerung->Heizung

Bei Änderung von Heizungssteuerung wird der WDT HeizungssteuerungWohnzimmerAn "neugestartet"
Zugleich auch die WDT die derselben Gruppe angehören. Soweit ist es OK.
In meinem Fall sind es ZWave Geräte die am Ende dieser Kette stehen, wenn jetzt 6 Geräte zeitgleich angesprochen werden und darauf antworten gibt das ne Menge an ZWaveFunklast.
Coll fände ich ein ggf. attr welches wenn WDT_Group gesetzt ist die Gruppenmitglieder nacheinander und oder zeiztverzögert behandelt.

Ist das verständlich?

[Beta-User]

WDT_delay (oder so) müsste das können, oder?

[tomspatz]

ja z.B. aber nötig m.E. nach nur wenn es in eine Gruppe geht. Und das deley pro Gruppenmitglied.
Wobei eine Verzögerung für einzelne..... wer weiss wofür es gut wäre

[Beta-User]

Na ja, ich hatte hier mal nachgefragt, ob so ein feature überhaupt gewünscht ist, und mangels Rückmeldung dann was in die Richtung so eingebaut, wie es mir sinnvoll erschien. Die Funktionalität noch komplexer zu machen, wäre - wie immer - wohl möglich, aber dann eben vermutlich auch schwieriger zu konfigurieren .
Dem Bauchgefühl nach würde ich sagen: Entweder ein Thermostat ist von "bulk-Änderungen" betroffen, dann macht es ggf. Sinn, die Verzögerung immer einzubauen, oder eben nicht. Wenn dann mal wirklich nur ein "single"-Ereignis ist, ist es in der Regel ja auch nicht schlimm, wenn das sowieso träge System etwas später umgestellt wird.

Aber falls es konkrete Vorschläge gibt (oder mein Bauchgefühl falsch sein sollte), können wir das gerne auch so anpassen, dass es "besser" wird...

[tomspatz]

OK
lass mich es nochmals erklären
5 x WDT
3 x davon in einer WDT_Group

jetzt mache ich bei WDT1 WDT_sendDelay 1, WDT2 WDT_sendDelay 2, WDT3 WDT_sendDelay 3, alle diese sind in einer WDT_Group
Wenn ich jetzt etwas in diese Gruppe schicke, also an WDT1, wird der Befehl ja bei jedem Teilnehmer der Gruppe um die eingestellte Zeit hinausgezögert.

Ist doch exakt was ich brauche, ode meine zu brauchen 

[Beta-User]

Ja, so war das gedacht.