MAX! Temperatur-Scanner
Der MAX! Temperatur-Scanner ist ein Perl-Skript, das die kontinuierliche Temperatur-Aufzeichnung von MAX-Thermostaten ermöglicht.
Features
- kontinuierliche Erfassung von Temperatur und Ventil-Position
- Berücksichtigung der System-Ressourcen (dutycycle, credits)
- derzeit wird nur CUL unterstützt (Lösung für CUBE geplant)
- gleichberechtigte zeitliche Bearbeitung der Thermostate (Round-Robin-Prinzip)
- Ermittlung der optimalen Scan-Rate über die Anzahl der eingebundenen Thermostate
Zielsetzung des WIKI-Artikels
Hier werden Fragen und Erkenntnisse zum Thema dargestellt, da der Forums-Eintrag für viele Anwender nicht mehr überschaubar ist.
Der Artikel wird sukzessive erweitert.
Aktuelle Version
Im Anhang zu folgendem Forumsbeitrag MaxScan Version 1.04c
Voraussetzungen
- derzeit nur mit CUL möglich
- prüfen, ob die Funkverbindung stabil und weitgehend fehlerfrei ist
- möglichst wenig Einträge in der Log-Datei der Form; diese weisen auf eine schlechte Funkverbindung hin. In diesem Fall wird der CUL bis zu 3x den Befehl wiederholen und dabei jede Menge Credits verbraten. Damit wird der Scanner inaktiv bleiben, da häufig zu wenig Credits vorhanden sind.
2013.11.01 02:12:33 2: CUL_MAX_SendQueueHandler: Missing ack from 0905a5 for 0b0b00401234560905a50062
- wenn letzteres passiert, dann gibt CUL etwa folgendes aus
2013.11.01 14:12:50 2: CUL_MAX_SendQueueHandler: Not enough credit! credit10ms is 6, but we need 121. Waiting 115 seconds.
Dies kann auch dann auftreten, wenn ein anderer Mechanismus ausserhalb des Scanners permanent sendet ohne Rücksicht auf die Credits.
- Deaktivierung des Thermostat-internen Zeitschaltprogrammes
- Man muss dafür sorgen, dass das Automatik-Programm im Thermostat selbst praktisch inaktiv ist.
- Dies erreicht man durch Reduzierung der Schaltpunkte auf ein Minimum. (also 1 Schaltpunkt um 00.00 Uhr).
- Um 00:05 Uhr wir dann vom Heating_Control oder einem anderen Mechanismus nochmals sicherheitshalber der für diese Zeit gewünschte Sollwert festgelegt.
Inbetriebnahme
- aktuell freigegebene Version von 99_UtilsMaxScan.pm in das Verzeichnis /opt/fhem/FHEM kopieren.
- Bei den Thermostaten, die gescannt werden sollen, das Attribut scanTemp setzen via
attr VT_HW scanTemp 1
- das Wochenprogramm im Thermostat selbst praktisch löschen via
set VT_HW weekProfile Mon 15 Tue 15 Wed 15 Thu 15 Fri 15 Sat 15 Sun 15
- auf keinen Fall das Attribut keepAuto setzen
- wenn der Scanner in Zusammenhang mit HeatingControl (Wochenschaltprogramm) eingesetzt werden soll (was Sinn macht), dann ist das Setzen der Solltemperatur über MaxScan_SetTemp zu realisieren
define HC_FOR_VT_HW Heating_Control VT_HW 23:00|eco 12345|04:00|comfort {MaxScan_SetTemp("@","%");;}
- ist ein ShutterContact mit dem Thermostat assoziiert, dann muss man dies bekannt machen mit dem UserReading
attr VT_HW userReadings watchShutter { return "SHUTTER.HW";;}
- FHEM neu starten
Hinweis
Je höher der Wert von Attribut verbose, umso weniger Ausgaben erhält man in der Log-Datei.
(Dies wird in einer der künftigen Versionen geändert, genau umgekehrt implementiert und damit konform zu den anderen Modulen)
Mechanismen
Das Problem
Der Hersteller der MAX-Thermostate hat diese so konzipiert, dass die gemessene Temperatur und Ventilstellung nur übertragen werden, wenn sich Folgendes ändert:
- die Ventilstellung
- die Betriebsart (mode: auto,manu,temporary,boost)
Es kann der Fall eintreten, dass über Stunden keine Temperatur an FHEM übertragen wird.
Der Lösungsansatz
Die vorliegende Skript verfolgt den Ansatz die Betriebsart des Thermostats regelmässig umzuschalten via
AUTO ==> MANU
<Wartezeit mindestens 3 Minuten>
MANU ==> AUTO
Dies veranlasst das Thermostat regelmässig die gewünschten Werte an FHEM (den gepaarten Transceiver) zu senden.
Allerdings: Die Umschaltung des Modes kann nur zusammen mit der Angabe des Sollwertes erfolgen.
Ergebnis
ohne Scanner
mit Scanner
Ressourcen
Die Sendezeit jedes Teilnehmers ist auf 1% begrenzt.
Konkret bedeutet dies, dass ein CUL ca. 33 Telegramme pro Stunde senden kann. Der MAX-Scanner darf nicht alle Ressourcen für sich beanspruchen, sondern sieht seine Aufgabe als nachrangig.
Erst wenn mehr als 300 Credits (von max. 900 möglichen) zur Verfügung stehen, wird das Skript aktiv.
Fragen und Antworten
Sollwert am Thermostat wird manuell verstellt
Manchmal wird der manuell am Thermostat geänderte Sollwert überschrieben
Wenn der Sollwert manuell am Thermostat verändert wird, kann es bis zu 3 Minuten dauern, bis dieser an FHEM gemeldet wird. Wenn der Scanner in dieser Wartezeit aktiv wird, wird er den soeben geänderten Sollwert überschreiben.
Wenn HeatingControl (Zeitschaltprogramm von FHEM) oder das thermostat-interne Zeitschaltprogramm aktiv ist, kann es ebenfalls zum Überschreiben des Sollwerts kommen.
Mehrere Thermostate in einer Gruppe
Wenn mehrere Thermostate in einer Gruppe vereinigt sind (Raumlösung nach ELV), dann darf nur ein einziges Thermostat vom Scanner bedient werden, da die anderen Thermostate von diesem synchronisiert werden. Also das Attribut "scanTemp" nur bei einem Repräsentanten der Gruppe aktivieren.
Was ist zu tun wenn, Thermostate zusammen mit einem Wandthermostat eingesetzt werden ?
In diesem Fall ist der Scanner überflüssig, da das Wandthermostat ohnehin eine detaillierte Kurve des Istwertes liefert.
Sind Fensterkontakte sinnvoll ?
Auf den ersten Blick scheinen sie das zu sein, da man meint Energie zu sparen. Hierzu gibt es jedoch auch eine andere Betrachtungsweise wie dieser Link zeigt: Sinn und Unsinn von Fensterkontakten
Das Thermostat ist auch ohne Fensterkontakt mit Hilfe der "Temperatur-Sturz-Erkennung" in der Lage zu festzustellen, dass ein Fenster offen ist. Der zuvor genannte Link präferiert diese Methode.
Aber auch die Temperatur-Sturz-Erkennung stellt hinterher wieder fix die 17 Grad ein.
Ausserdem ist diese wie hier im Beispiel im Hochsommer angesprungen (Tür wurde zum Abkühlen geöffnet).
Diese Problem kann man vermutlich mit einer WindowOpenDuration von 0 beheben, ausserdem ist im Hochsommer die Heizung ohnehin ausgeschalten.
Folgende Nachteile haben die Max-Fensterkontakte:
- es gibt keine Verzögerungszeit, das Thermostat schliesst sofort, wenn das Fenster geöffnet wird. Das mag bei einem normalen Fenster noch akzeptabel sein, nicht aber bei Türen.
- wenn das Thermostat im Auto-Modus ist und der Fensterkontakt geht von aktiv zu inaktiv(Fenster wieder geschlossen), dann stellt das Thermostat fix 17 Grad ein, also nicht den zuvor eingestellten Sollwert (Dieses Verhalten betrachten viele als Design-Fehler)
Kann der Scanner mit Fensterkontakten umgehen ?
Der Scanner versucht das Problem der fixen 17 Grad nach Schliessen des Fensters zu korrigieren. Hierzu braucht er jedoch die Information welcher Fensterkontakt für das jeweilige Thermostat zuständig ist.
Ausserdem wäre es fatal, wenn der Scanner in der Phase des offenen Fenster den Sollwert überschreiben würde. Bei offenen Fenster ist der Scanner inaktiv, er schaltet also den Modus nicht mehr um. Da auch HeatingControl in dieser Phase einen neuen Sollwert setzen könnte, fängt der Scanner auch dieses ab, merkt sich den Sollwert und setzt ihn verzögert, nachdem das Fenster wieder geschlossen wurde.
Was ist denn, wenn ich noch einen zweiten Fensterkontakt habe ?
Derzeit wird nur 1 ShutterContact unterstützt. Möglicherweise wird in einer der nächsten Versionen die Funktionalität erweitert.
Was passiert, wenn der Boost-Mode aktiviert wurde ?
Sobald dies der Scanner erkennt, stellt er seine Aktivität ein, bis wieder der Modus Auto oder Manu erscheint.
Ausblick
Scanner als Modul ausführen
- Scanner wird nicht mehr als Skript, sondern als Modul ausgeführt.
- pro Thermostat ist dann eine Definition in fhem.cfg vorzunehmen.
- Wochenprofil als Attribut
- automatischer Abgleich des Wochenprofils mit dem Thermostat
- Fensterkontakt zuordnen