[Testversion] Heating_Control=>WeekdayTimer

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