[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