FHEM - Hausautomations-Systeme > MAX

Temperatur-Scanner für MAX-Thermostate

<< < (3/169) > >>

Zwer2k:
Hallo John,

das mit den Credits, Round-Robin und auch Aufnahme von scanTemp-Attribut bzw. des kompletten Skripts ins Repository hört sich super an.
So wie ich es verstehe, passt du dein Script an Heating_Control an und hebelst damit das interne Wochenprofil von den Thermostaten aus. Ist dann noch überhaupt möglich die Temperatur und Modus (auto/manuell) am Thermostat einzustellen?
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). 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 .
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).

John:
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:

--- Zitat ---So wie ich es verstehe, passt du dein Script an Heating_Control an
--- Ende Zitat ---

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.


--- Zitat ---hebelst damit das interne Wochenprofil von den Thermostaten aus
--- Ende Zitat ---

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.


--- Zitat ---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)
--- Ende Zitat ---

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.


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

--- Ende Zitat ---

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.


--- Zitat ---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).
--- Ende Zitat ---


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
Link
ausführlich erläutert.

John

Marcel_R:
Salut John,

Ich melde mich auch als eventueller Beta-Tester für die nächste Version.

Ich habe aktuell 10 MAX Heizkörperthermostate am Laufen. Der CUL ist an einer FB7270, Firmware-Version: 54.05.23 (Austria/Schweiz Edition, d.h. ohne FHEM-Integration in die FB-FW -> FHEM auf einem USB-Stick).

Es scheint mir, dass das Aufspielen der jetzigen Version keinen grossen Sinn macht (Anzahl verfügbarer Time-Slots / 10 Thermostate ergibt keine höhere Datenrate, eventuell Zeitfunktion-Probleme wegen der FB7270). Deshalb warte ich gespannt auf die nächste Version ...

Gruss
Marcel

John:
Das neue Skript läuft nun seit einigen Tagen erfolgreich auf meinem Raspberry Pi, so dass ich es guten Gewissens freigeben kann.

Ich möchte vor allem die FHEM-User mit Fritzbox bitten, das Skript zu testen und die Ergebnisse zurück zu melden.

Folgendes hat sich geändert:

Interner Timer
Ich verwende nun einen internen Timer so dass der bisherige At-Befehl in FHEM.cfg nicht mehr notwendig ist.

Kompatibel mit der Fritz-Box
Ich habe die verdächtigen Module entfernt und beschränke mich auf ein Minimum von Abhängigkeiten.
Die Datums/Zeitverarbeitung habe ich dafür komplett geändert und bin auf das serialisierte Format des HiRes Paketes gegangen.

Logging-Level hängt nun am Thermostat
Logging kann nun für jedes einzelnen Thermostat eingestellt werden.
Je kleiner der loglevel , um so gesprächiger wird das Skript.

Verbessertes Round Robin
Ich sortiere die Thermostate nach dem nächsten Abfragedatum, vorher war es schlicht die Reihenfolge der Definition,
die die Reihenfolge in der Schleife bestimmte.

Optimierte Wartezeit
Wenn dem Skript die Credits fehlen, wartet es nicht einfach nur 3 Minuten, sondern berechnet aus dem Credit-Bedarf heraus intelligent die optimale Wartezeit.
Damit reduzieren sich die Log-Einträge

Begrenzung auf 32 Thermostate
Mehr lasse ich nicht zu wegen der 32 Timeslots pro Stunde.

Neuer Parameter in der WEB-Darstellung beim Thermostat
Hier findet sich nun nach dem ersten Scan der Parameter "nextTemperatureScan". Der zeigt das an, was der Name vespricht den Zeitpunkt des nächsten geplanten Scans für das Thermostat.

Vorbereitet für die Integration in 10_MAX.pm
Wenn die Rückmeldungen positiv sind, wäre es ggf. sinnvoll das Skript direkt in 10_MAX.pm zu integrieren, so daß neue User es einfacher hätten diese Funktion zu nutzen.
Dann könnte man das schon vorbereitet Attribut "scanTemp" nutzen (derzeit auskommentiert), um über die Definition des Thermostats die Scan-Funktion freizuschalten.


Inbetriebsetzung:

Sollte der AT-Timer von der alten Version noch in FHEM.cfg vorhanden sein, dann diesen bitte löschen.
(define at_MaxScan at +*00:00:10 { MaxScan("HT_ZIMMER01 HT_ZIMMER01 HT_ZIMMER03",15 );;})

Im übrigen ist wie zuvor 99_MaxScan.pm ist in das Verzeichnis /opt/fhem/FHEM zu kopieren.

Ich freue mich auf zahlreiche Rückmeldungen.

John

Marcel_R:
Das war ja eine extrem schnelle Antwort. Danke vielmals!

Ich habe auch sofort geschaut, ob ich einen MAX-Heizkörperthermostat zum Laufen kriege. But no such luck.

PuTTY meldet mir beim Versuch fhem zu starten:  
Undefined subroutine &main::timelocal called at ./FHEM/99_MaxScan.pm line 25.

Vermutlich habe ich bei der Inbetriebsetzung ein (oder mehrere) faulen Eier gelegt. Was ich gemacht habe:
Ich kopierte die Datei 99_MaxScan.pm in das Verzeichnis /.../fhem/FHEM.

In die Datei fhem.cfg fügte ich ein:
define HC_1_Buero Heating_Control HKT_1_Buero 07:00:19_22:00:16
ich setzte nachstehnden Befehle ab:
set HKT_1_Buero weekProfile Mon 15 Tue 15 Wed 15 Thu 15 Fri 15 Sat 15 Sun 15
shutdown

HTH
Marcel

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete

Zur normalen Ansicht wechseln