Hallo Jurij,
Deine Idee die eigentliche ungenutzte Temperatur im Thermostat durch Umschalten des Modes zu nutzen ist grandios.
Damit bekommen wir passable Temperaturprofile, die man gut für Auswertungen verwenden kann.
Mir ist z.B. dadurch schnell klar geworden, dass die Vorlauftemperatur des Kessels unnötig hoch ist.
Zu Deinen Anmerkungen:
So wie ich es verstehe, passt du dein Script an Heating_Control an
Ich gehe davon aus, dass Heating_Control der "Chef" ist. Natürlich können die Nutzer manuell die Temperatur verstellen,
bis zum nächsten Schaltpunkt von Heating_Control.
Das Skript selbst weiss jedoch nichts von Heating_Control und es gibt auch keine Abhängigkeiten.
hebelst damit das interne Wochenprofil von den Thermostaten aus
man muss dieses praktisch deaktivieren und alles dem Heating_Control überlassen. (wie im ersten Beitrag beschrieben)
Dafür gewinnen wir eine Verdopplung der Scan-Rate.
Das behalten von internem Wochenprofil, und Möglichkeit weiterhin am Thermostat direkt Verstellungen vornehmen zu können, inkl. WindowOpen war nämlich mein Ziel (WAF)
Solange das Heating_Control seinen Dienst tut, brauche ich das interne Wochenprofil nicht.
Als Fallback-Lösung wäre es natürlich gut, wenn das Profil des Heating-Controls im internen Profil abgebildet werden würde.
Des weiteren sollte der Skript auch auf einer FritzBox laufen, dazu muss bei alle FB auf Date::Parse und bei FB 7570 auch auf DateTime verzichtet werden. Das einzige was die Boxen zu verstehen scheinen ist Time::Piece->strptime .
Ich teste gerade die nächste Version des Skriptes, das ohne Date::Parse und Time::Piece auskommt, sondern auf Time::HiRes basiert, das fhem.pl selbst verwendet. Somit sollte die FritzBox kein Problem mehr mit dem Skript haben.
Es wäre super wenn wir Vorteile von beiden Skripten in eins zusammen packen könnte, d.h. funktionsfähig sowohl mit Heating_Control auch auch mit internem Wochenprofil, Möglichkeit weiterhin am Thermostat direkt Verstellungen vornehmen zu können, WindowOpen, Credits, Round-Robin, Aufnahme von scanTemp-Attribut und zumindest minimale CUBE-Unterstützung (alles wird mit CUBE vermutlich nicht gehen).
Ich denke zur Zeit über eine Synchroniserung von Heating_Control und dem Thermostat-internen Wochenprofil nach.
Das wäre aus meiner Sicht eine akzeptable Fallback-Lösung sollte FHEM ausfallen. Ausserdem ist dann die Mode-Umschaltung völlig
problemlos, da beide Seiten ohnehin diesselben Sollwerte vorgeben würden.
Wenn wir vom Cube keine Credits erhalten, hat er schlechte Karten,
Das Skript sieht das Scannen der Temperatur als untergeordnete Aufgabe und lässt Luft für die übergeordneten Dinge, wie Sollwerte setzen.
Aber das hab ich ja am Ende deines Threads
Linkausführlich erläutert.
John
