MAX! Temperatur-Scanner: Unterschied zwischen den Versionen

Aus FHEMWiki
(Ersetzung von Forum-Links mit Vorlage Link2Forum)
 
(49 dazwischenliegende Versionen von 4 Benutzern werden nicht angezeigt)
Zeile 5: Zeile 5:
* kontinuierliche Erfassung von Temperatur und Ventil-Position  
* kontinuierliche Erfassung von Temperatur und Ventil-Position  
* Berücksichtigung der System-Ressourcen (dutycycle, credits)
* Berücksichtigung der System-Ressourcen (dutycycle, credits)
* derzeit wird nur CUL unterstützt (Lösung für CUBE geplant)
* [[MAX#CUL_MAX|CUL]] und [[MAX#MAXLAN|CUBE]] werden unterstützt
* gleichberechtigte zeitliche Bearbeitung der Thermostate (Round-Robin-Prinzip)
* gleichberechtigte zeitliche Bearbeitung der Thermostate (Round-Robin-Prinzip)
* Ermittlung der optimalen Scan-Rate über die Anzahl der eingebundenen Thermostate
* Ermittlung der optimalen Scan-Rate über die Anzahl der eingebundenen Thermostate
* 2 Scan-Modi stehen zur Verfügung (DesiredChange + ModeChange)


== Zielsetzung des WIKI-Artikels ==
== Zielsetzung des WIKI-Artikels ==
Zeile 14: Zeile 15:
Der Artikel wird sukzessive erweitert.
Der Artikel wird sukzessive erweitert.


== Aktuelle Version ==
== Voraussetzungen ==
Im Anhang zu folgendem Forumsbeitrag [http://forum.fhem.de/index.php/topic,11624.msg100703.html#msg100703 MaxScan Version 1.04c]
 
=== Voraussetzungen ===
==== Derzeit nur mit CUL möglich ====
Eine Lösung für den Cube ist in Vorbereitung
 
==== Qualität der Funkverbindung ====
==== Qualität der Funkverbindung ====
In der Log-Datei sollten möglichst wenig Einträge der nachfolgenden Form auftreten
In der Log-Datei sollten möglichst wenig Einträge der nachfolgenden Form auftreten
<pre>2013.11.01 02:12:33 2: CUL_MAX_SendQueueHandler: Missing ack from 0905a5 for 0b0b0040123456xxxxxxxxx</pre>
<pre>2013.11.01 02:12:33 2: CUL_MAX_SendQueueHandler: Missing ack from 0905a5 for 0b0b0040123456xxxxxxxxx</pre>
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.
Diese weisen auf eine schlechte Funkverbindung hin. In diesem Fall wird  der CUL bis zu 3x den Befehl wiederholen und dabei jede Menge Credits verbrauchen. Damit wird  der Scanner inaktiv bleiben, da häufig zu wenige Credits vorhanden sind.


==== Ausreichend Credits ====
==== Ausreichend Credits ====
Der Scanner kann nicht aktiv werden, wenn gehäuft Log-Einträge der nachfolgenden Form auftreten.
Der Scanner kann nicht aktiv werden, wenn gehäuft Log-Einträge der nachfolgenden Form auftreten.
<pre>2013.11.01 14:12:50 2: CUL_MAX_SendQueueHandler: Not enough credit! credit10ms is 6, but we need 121. Waiting 115 seconds.</pre>
<pre>2013.11.01 14:12:50 2: CUL_MAX_SendQueueHandler: Not enough credit! credit10ms is 6, but we need 121. Waiting 115 seconds.</pre>
Die Ursache hierfür kann neben funktechnischen Problem auch sein, wenn ein anderer Mechanismus ausserhalb des Scanners permanent sendet, ohne Rücksicht auf die Credits.
Die Ursache hierfür kann neben funktechnischen Problem auch sein, dass ein anderer Mechanismus ausserhalb des Scanners permanent sendet, ohne Rücksicht auf die Credits zu nehmen.


==== Deaktivierung des Thermostat-internen Zeitschaltprogrammes ====
==== Einrichten des Thermostat-internen Wochenprogrammes ====


Man muss dafür sorgen, dass das Automatik-Programm im Thermostat selbst praktisch inaktiv ist.
Die Readings des Wochenprogramms müssen erscheinen. Der Scanner greift ausgiebig auf diese Informationen zurück. Ein manuelles Verstellen des Sollwertes ist nur bis zu dem nächsten Schaltzeitpunkt des Wochenprogramms gültig. Danach wird je nach ScanMode das Thermostat selbst oder der Scanner den Sollwert gemäß den Einstellungen des Wochenprogramms ändern.
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
<pre>attr VT_HW scanTemp 1</pre>
* das Wochenprogramm im Thermostat selbst praktisch löschen via
<pre>set VT_HW weekProfile Mon 15 Tue 15 Wed 15 Thu 15 Fri 15 Sat 15 Sun 15 </pre>
* 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
<pre>define HC_FOR_VT_HW Heating_Control VT_HW 23:00|eco 12345|04:00|comfort {MaxScan_SetTemp("@","%");;}</pre>
* ist ein ShutterContact mit dem Thermostat assoziiert, dann muss man dies bekannt machen mit dem UserReading
<pre>attr VT_HW userReadings watchShutter { return "SHUTTER.HW";;}</pre>
* '''FHEM neu starten'''


'''Bitte folgendes beachten:'''


'''Hinweis'''<br />
Es gibt im Zusammenhang mit dem Wochenprogramm ein Problem mit dem letzten Schaltpunkt des Tages.
Je höher der Wert von Attribut verbose, umso weniger Ausgaben erhält man in der Log-Datei.
Der Workaround wurde  {{Link2Forum|Topic=17231|Message=112738|LinkText=hier}}
beschrieben.


(Dies wird in einer der künftigen Versionen geändert, genau umgekehrt implementiert und damit konform zu den anderen Modulen)
<big>Man muss dafür sorgen, dass man kurz vor Ende des Tages noch einen Schaltpunkt setzt.</big>


== Mechanismen ==
== Mechanismen ==
Zeile 61: Zeile 43:
* die Ventilstellung
* die Ventilstellung
* die Betriebsart (mode: auto,manu,temporary,boost)
* die Betriebsart (mode: auto,manu,temporary,boost)
* der Sollwert
Es kann der Fall eintreten, dass über Stunden keine Temperatur an FHEM übertragen wird. Damit sind Aufzeichnungen für Temperatur und Ventilstellung wenig aussagekräftig.


=== Der Lösungsansatz ===
==== Triggerung per Mode-Umschaltung (ModeChange) ====
Dies ist der Default-Mode des Scanners.
Hier wird der Ansatz verfolgt, die Betriebsart des Thermostats regelmässig umzuschalten via
:AUTO ==> MANU
<Wartezeit mindestens 3 Minuten>
:MANU ==> AUTO


Es kann der Fall eintreten, dass über Stunden keine Temperatur an FHEM übertragen wird.
Dies veranlasst das Thermostat, regelmässig die gewünschten Werte an FHEM (den gepaarten Transceiver) zu senden.


=== Der Lösungsansatz ===
==== Triggerung per Sollwert-Umschaltung (DesiredChange) ====
Die vorliegende Skript verfolgt den Ansatz die Betriebsart des Thermostats regelmässig umzuschalten via<br /><br />
Durch Änderung des Sollwertes kann ebenso die Übertragung des Istwertes am Thermostat initiiert werden.
AUTO ==> MANU<br />
 
<Wartezeit mindestens 3 Minuten><br />
Der Scanner ändert den vorgegebenen Sollwert um 0.5 Grad. Er wird hierbei die Änderung immer in die Richtung einer sich vergroessernden Regelabweichung durchführen.
MANU ==> AUTO<br /><br />
 
Dieser Modus wird durch die Definition des UserReadings "onlyAutoMode" festgelegt.
:<code>attr HT.JOHN userReadings onlyAutoMode { return "1";;}</code>
 
'''Beispiel:'''


Dies veranlasst das Thermostat regelmässig die gewünschten Werte an FHEM (den gepaarten Transceiver) zu senden.
Sollwert im Thermostat nach Wochenprofil: 18
Fall A:
----
* Istwert  17
* Sollwert A von Scanner gesetzt : 18.5
* Sollwert B von Scanner gesetzt : 18.0
* Der Scanner wechselt also von 18 auf 18.5 und zurück.


'''Allerdings:'''  Die Umschaltung des Modes kann nur zusammen mit der Angabe des Sollwertes erfolgen.
Fall B:
----
* Istwert  19
* Sollwert A von Scanner gesetzt : 17.5
* Sollwert B von Scanner gesetzt : 18.0
* Der Scanner wechselt also von 18 auf 17.5 und zurück.


=== Ergebnis ===
=== Ergebnis ===
==== ohne Scanner ====
==== ohne Scanner ====
[[Datei:2013_12_MaxScanner_Vorher.png|ohne Scanner]]
[[Datei:2013_12_MaxScanner_Vorher.png|ohne Scanner]]


==== mit Scanner ====
==== mit Scanner (ScanMode=ModeChange) ====
[[Datei:2013_12_MaxScanner_Nachher.png|mit Scanner]]
[[Datei:13_12_01_Scanner_ModeChange.png|mit Scanner]]
 
==== mit Scanner (ScanMode=DesiredChange) ====
[[Datei:13_12_01_Scanner_DesiredChange.png|mit Scanner]]


=== Ressourcen ===
=== Ressourcen ===
Zeile 92: Zeile 101:


== Fragen und Antworten ==
== Fragen und Antworten ==
=== Sollwert am Thermostat wird manuell verstellt ===
=== Welchen ScanMode soll ich wählen? ===
<blockquote>Manchmal wird der manuell am Thermostat geänderte Sollwert überschrieben</blockquote>
Nachfolgende Punkte können als Entscheidungskriterium dienen:
----
 
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.
'''ModeChange'''
* keine Änderung des Sollwertes nötig
* damit ist das Ventil "ruhiger", da sich die Regeldifferenz nicht durch den Scanner-Betrieb ändert.
 
'''DesiredChange'''
* der Auto-Modus wird niemals verlassen
* Falls FHEM ausfällt, wird das Thermostat das gespeicherte Wochenprogramm nutzen
 
=== Was passiert, wenn der Sollwert am Thermostat manuell verstellt wird? ===
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. In diesem Fall bliebe die manuelle Änderung wirkungslos.
 
Wird die manuelle Änderung des Sollwertes vom Scanner erkannt, so gilt dieser bis zum nächsten Schaltpunkt des internen Wochenprogrammes.


Wenn HeatingControl (Zeitschaltprogramm von FHEM) oder das thermostat-interne Zeitschaltprogramm aktiv
=== Mehrere Thermostate in einer Gruppe? ===
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.
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 ?===
 
=== 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.
In diesem Fall ist der Scanner überflüssig, da das Wandthermostat ohnehin eine detaillierte Kurve des Istwertes liefert.


=== Sind Fensterkontakte sinnvoll ? ===
=== 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:
Auf den ersten Blick scheinen sie das zu sein, da man meint Energie zu sparen. Hierzu gibt es jedoch auch eine andere Betrachtungsweise wie die Seite
[http://www.elv.de/topic/tuer-fensterkontakt-sinn-und-unsinn.html Sinn und Unsinn von Fensterkontakten]
[http://www.elv.de/topic/tuer-fensterkontakt-sinn-und-unsinn.html Sinn und Unsinn von Fensterkontakten] zeigt.


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.  
Das Thermostat ist auch ohne Fensterkontakt mit Hilfe der "Temperatur-Sturz-Erkennung" in der Lage festzustellen, dass ein Fenster offen ist. Der zuvor genannte Link präferiert diese Methode.  


[[Datei:2013_11_02_Scanner_TSturz.png|Sturz-Temperatur-Erkennung]]


[[Datei:2013_11_02_Scanner_TSturz.png|Sturz-Temperatur-Erkennung]]
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 vermutlich mit einer WindowOpenDuration von 0 behoben werden, ausserdem ist im Hochsommer die Heizung ohnehin ausgeschaltet.
<br />
<br />
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:
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.
* 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)
* 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 ? ===
=== Berücksichtigt der Scanner die Temperatur-Sturz-Erkennung? ===
Der Scanner versucht das Problem der fixen 17 Grad nach Schliessen des Fensters zu korrigieren.
Wenn desiredTemperature=WindowsOpenTemperature, dann stellt der Scanner seine Arbeit ein. Ansonsten würde er durch aktive Modeumschaltung die WindowsOpenTemperature dauerhaft setzen.
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.
=== Kann der Scanner mit Fensterkontakten umgehen? ===
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.
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.


=== Was ist denn, wenn ich noch einen zweiten Fensterkontakt habe ? ===
Ausserdem wäre es fatal, wenn der Scanner in der Phase des offenen Fensters den Sollwert überschreiben würde. Bei offenem Fenster ist der Scanner inaktiv, er schaltet also den Modus nicht mehr um.
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 ? ===
=== 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.
Sobald dies der Scanner erkennt, stellt er seine Aktivität ein, bis wieder der Modus Auto oder Manu erscheint.


== Ausblick==
=== Unterstützt der Scanner auch den MAX-ECO-Taster? ===
=== Scanner als Modul ausführen ===
Nein.
* Scanner wird nicht mehr als Skript, sondern als Modul ausgeführt.
 
* pro Thermostat ist dann eine Definition in fhem.cfg vorzunehmen.
=== Beeinflusst der Scanner den Regelmechanismus des Thermostats? ===
* Wochenprofil als Attribut
Im Prinzip nicht. Jedoch wird in der Betriebsart "DesiredChange" der Sollwert geringfügig um +/- 0.5 Grad im Sinne einer sich vergrößernden Regeldifferenz verändert.
* automatischer Abgleich des Wochenprofils mit dem Thermostat
 
* Fensterkontakt zuordnen
== Die Modul-Variante ==
 
Die Modul-Variante ist seit dem 10.01.2016 Bestandteil von  FHEM.
 
=== Voraussetzungen ===
* ggf. vorhandene Script-Variante sollte deaktiviert werden (99_UtilsMaxScan löschen/verschieben)
 
=== Inbetriebnahme ===
* Scanner Modul definieren
<pre>
define Scanner MaxScanner
attr Scanner verbose 1
</pre>
 
* die bestehende Max-Thermostate verfügen nun automatisch über neue Attribute, die den Scanner betreffen
* die meisten Scanner-spezfischen Attribute beginnen immer mit "scn"
* im folgende Beispiel wird das Thermostat HT.JOHN betrachtet:
<pre>
define HT.JOHN MAX HeatingThermostat 066666
</pre>
* das Thermostat wird für den Scanner freigegeben
<pre>attr HT.JOHN scanTemp 1</pre>
* wir wählen die Betriebsart Mode-Change
<pre>attr HT.JOHN scnProcessByDesiChange 0</pre>
* wir können 0..n ShutterContacts definieren, getrennt durch Komma
<pre>attr HT.JOHN scnShutterList SHUTTER.JOHN,SHUTTER.BRENNER</pre>
* verbose liefert ausführliche Infos im Logger
<pre>attr HT.JOHN verbose 4</pre>
 
=== Attribute Thermostat===
{| class="wikitable sortable"
|-
! Parameter !! Wertebereich !! Default !! Beschreibung
|-
|scanTemp||[0,1]||0||wenn 1, wird das Thermostat vom Scanner berücksichtigt
|-
|scnProcessByDesiChange||[0,1]||0||wenn 1, wird das Thermostat über die Änderung von desiredTemperature (DesiredChange) getriggert, ansonsten über die Änderung des Modes (ModeChange)
|-
|scnModeHandling||[NOCHANGE,AUTO,MANUAL]||AUTO|||wenn scnProcessByDesiChange aktiviert ist, kann man hier entscheiden, wie mit dem MODE verfahren werden soll. Wenn AUTO, wird der Scanner immer den Mode "auto" vorgeben, wenn MANUAL, den Mode "manual" sobald der Sollwert zum
Thermostat geschrieben wird. Ist hingegen NOCHANGE gewählt, so wird der aktuelle am Thermostat angewählte Mode belassen.
|-
|scnShutterList||||||Liste von assoziierten Max-Fensterkontakten (ShutterContacts), die durch ein Komma getrennt werden.
Der Scanner benötigt diese, um ein geöffnetes Fenster umgehend zu erkennen. Er erkennt ein offenes Fenster auch ohne Fensterkontakt, wenn gilt "aktueller Sollwert" = WindowOpenTemperature. Das Thermostat geht nach erkanntem Temperaturabfall auf diesen Wert.
 
|}
=== Attribute Scanner===
{| class="wikitable sortable"
|-
! Parameter !! Wertebereich !! Default !! Beschreibung
|-
|disable||[0,1]||0|| wenn 1, dann wird der Scanner gesperrt und ist somit inaktiv.
|-
|scnCreditThreshold||[150..600]||300|| die Mindestanzahl von verfügbaren Credits, ab der der Scanner mit dem Triggern der Thermostate beginnt
|-
|scnMinInterval||[3..60]||3|| die Mindestwartezeit in Minuten, nach der der Scanner ein Thermostate erneut triggert; diese wird nur berücksichtigt, wenn sie höher ist, als die berechnete Wartezeit, die sich aus der Anzahl der Thermostate ergibt.
|-
|}
 
=== Background ===
 
==== Hilfe zur Diagnose der Abläufe ====
Ein wichtiges Hilfsmittel ist der Event-Monitor. Mit der Filter-Einstellung "MAX.*" werden nur noch die MAX-relevanten Events dargestellt.
 
Interpretation der Ausgabe:<br/>
<pre>
2016-01-06 21:24:43 MAX HT.BAD desiredTemperature auto 20.0 <-- Triggern des Thermostats durch Scanner
 
2016-01-06 21:24:50 MAX HT.BAD mode: auto            --> Rückmeldung vom Thermostat
2016-01-06 21:24:50 MAX HT.BAD RSSI: -54              --> Rückmeldung vom Thermostat
2016-01-06 21:24:56 MAX HT.BAD temperature: 20.2      --> Rückmeldung vom Thermostat
</pre>
 
Hier erscheinen also die zu Thermostat gesendeten Informationen ebenso, wie die empfangenen.
Empfangene Informationen sind meist mit einem ":" gekennzeichnet.


[[Kategorie:MAX]]
[[Kategorie:MAX]]

Aktuelle Version vom 19. März 2017, 20:49 Uhr

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)
  • CUL und CUBE werden unterstützt
  • gleichberechtigte zeitliche Bearbeitung der Thermostate (Round-Robin-Prinzip)
  • Ermittlung der optimalen Scan-Rate über die Anzahl der eingebundenen Thermostate
  • 2 Scan-Modi stehen zur Verfügung (DesiredChange + ModeChange)

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.

Voraussetzungen

Qualität der Funkverbindung

In der Log-Datei sollten möglichst wenig Einträge der nachfolgenden Form auftreten

2013.11.01 02:12:33 2: CUL_MAX_SendQueueHandler: Missing ack from 0905a5 for 0b0b0040123456xxxxxxxxx

Diese weisen auf eine schlechte Funkverbindung hin. In diesem Fall wird der CUL bis zu 3x den Befehl wiederholen und dabei jede Menge Credits verbrauchen. Damit wird der Scanner inaktiv bleiben, da häufig zu wenige Credits vorhanden sind.

Ausreichend Credits

Der Scanner kann nicht aktiv werden, wenn gehäuft Log-Einträge der nachfolgenden Form auftreten.

2013.11.01 14:12:50 2: CUL_MAX_SendQueueHandler: Not enough credit! credit10ms is 6, but we need 121. Waiting 115 seconds.

Die Ursache hierfür kann neben funktechnischen Problem auch sein, dass ein anderer Mechanismus ausserhalb des Scanners permanent sendet, ohne Rücksicht auf die Credits zu nehmen.

Einrichten des Thermostat-internen Wochenprogrammes

Die Readings des Wochenprogramms müssen erscheinen. Der Scanner greift ausgiebig auf diese Informationen zurück. Ein manuelles Verstellen des Sollwertes ist nur bis zu dem nächsten Schaltzeitpunkt des Wochenprogramms gültig. Danach wird je nach ScanMode das Thermostat selbst oder der Scanner den Sollwert gemäß den Einstellungen des Wochenprogramms ändern.

Bitte folgendes beachten:

Es gibt im Zusammenhang mit dem Wochenprogramm ein Problem mit dem letzten Schaltpunkt des Tages. Der Workaround wurde hier beschrieben.

Man muss dafür sorgen, dass man kurz vor Ende des Tages noch einen Schaltpunkt setzt.

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)
  • der Sollwert

Es kann der Fall eintreten, dass über Stunden keine Temperatur an FHEM übertragen wird. Damit sind Aufzeichnungen für Temperatur und Ventilstellung wenig aussagekräftig.

Der Lösungsansatz

Triggerung per Mode-Umschaltung (ModeChange)

Dies ist der Default-Mode des Scanners. Hier wird der Ansatz verfolgt, 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.

Triggerung per Sollwert-Umschaltung (DesiredChange)

Durch Änderung des Sollwertes kann ebenso die Übertragung des Istwertes am Thermostat initiiert werden.

Der Scanner ändert den vorgegebenen Sollwert um 0.5 Grad. Er wird hierbei die Änderung immer in die Richtung einer sich vergroessernden Regelabweichung durchführen.

Dieser Modus wird durch die Definition des UserReadings "onlyAutoMode" festgelegt.

attr HT.JOHN userReadings onlyAutoMode { return "1";;}

Beispiel:

Sollwert im Thermostat nach Wochenprofil: 18

Fall A:


  • Istwert 17
  • Sollwert A von Scanner gesetzt : 18.5
  • Sollwert B von Scanner gesetzt : 18.0
  • Der Scanner wechselt also von 18 auf 18.5 und zurück.

Fall B:


  • Istwert 19
  • Sollwert A von Scanner gesetzt : 17.5
  • Sollwert B von Scanner gesetzt : 18.0
  • Der Scanner wechselt also von 18 auf 17.5 und zurück.

Ergebnis

ohne Scanner

ohne Scanner

mit Scanner (ScanMode=ModeChange)

mit Scanner

mit Scanner (ScanMode=DesiredChange)

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

Welchen ScanMode soll ich wählen?

Nachfolgende Punkte können als Entscheidungskriterium dienen:

ModeChange

  • keine Änderung des Sollwertes nötig
  • damit ist das Ventil "ruhiger", da sich die Regeldifferenz nicht durch den Scanner-Betrieb ändert.

DesiredChange

  • der Auto-Modus wird niemals verlassen
  • Falls FHEM ausfällt, wird das Thermostat das gespeicherte Wochenprogramm nutzen

Was passiert, wenn der Sollwert am Thermostat manuell verstellt wird?

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. In diesem Fall bliebe die manuelle Änderung wirkungslos.

Wird die manuelle Änderung des Sollwertes vom Scanner erkannt, so gilt dieser bis zum nächsten Schaltpunkt des internen Wochenprogrammes.

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 die Seite Sinn und Unsinn von Fensterkontakten zeigt.

Das Thermostat ist auch ohne Fensterkontakt mit Hilfe der "Temperatur-Sturz-Erkennung" in der Lage festzustellen, dass ein Fenster offen ist. Der zuvor genannte Link präferiert diese Methode.

Sturz-Temperatur-Erkennung

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 vermutlich mit einer WindowOpenDuration von 0 behoben werden, ausserdem ist im Hochsommer die Heizung ohnehin ausgeschaltet.

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

Berücksichtigt der Scanner die Temperatur-Sturz-Erkennung?

Wenn desiredTemperature=WindowsOpenTemperature, dann stellt der Scanner seine Arbeit ein. Ansonsten würde er durch aktive Modeumschaltung die WindowsOpenTemperature dauerhaft setzen.

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 Fensters den Sollwert überschreiben würde. Bei offenem Fenster ist der Scanner inaktiv, er schaltet also den Modus nicht mehr um.

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.

Unterstützt der Scanner auch den MAX-ECO-Taster?

Nein.

Beeinflusst der Scanner den Regelmechanismus des Thermostats?

Im Prinzip nicht. Jedoch wird in der Betriebsart "DesiredChange" der Sollwert geringfügig um +/- 0.5 Grad im Sinne einer sich vergrößernden Regeldifferenz verändert.

Die Modul-Variante

Die Modul-Variante ist seit dem 10.01.2016 Bestandteil von FHEM.

Voraussetzungen

  • ggf. vorhandene Script-Variante sollte deaktiviert werden (99_UtilsMaxScan löschen/verschieben)

Inbetriebnahme

  • Scanner Modul definieren
define Scanner MaxScanner
attr Scanner verbose 1
  • die bestehende Max-Thermostate verfügen nun automatisch über neue Attribute, die den Scanner betreffen
  • die meisten Scanner-spezfischen Attribute beginnen immer mit "scn"
  • im folgende Beispiel wird das Thermostat HT.JOHN betrachtet:
define HT.JOHN MAX HeatingThermostat 066666
  • das Thermostat wird für den Scanner freigegeben
attr HT.JOHN scanTemp 1
  • wir wählen die Betriebsart Mode-Change
attr HT.JOHN scnProcessByDesiChange 0
  • wir können 0..n ShutterContacts definieren, getrennt durch Komma
attr HT.JOHN scnShutterList SHUTTER.JOHN,SHUTTER.BRENNER
  • verbose liefert ausführliche Infos im Logger
attr HT.JOHN verbose 4

Attribute Thermostat

Parameter Wertebereich Default Beschreibung
scanTemp [0,1] 0 wenn 1, wird das Thermostat vom Scanner berücksichtigt
scnProcessByDesiChange [0,1] 0 wenn 1, wird das Thermostat über die Änderung von desiredTemperature (DesiredChange) getriggert, ansonsten über die Änderung des Modes (ModeChange)
scnModeHandling [NOCHANGE,AUTO,MANUAL] AUTO wenn scnProcessByDesiChange aktiviert ist, kann man hier entscheiden, wie mit dem MODE verfahren werden soll. Wenn AUTO, wird der Scanner immer den Mode "auto" vorgeben, wenn MANUAL, den Mode "manual" sobald der Sollwert zum

Thermostat geschrieben wird. Ist hingegen NOCHANGE gewählt, so wird der aktuelle am Thermostat angewählte Mode belassen.

scnShutterList Liste von assoziierten Max-Fensterkontakten (ShutterContacts), die durch ein Komma getrennt werden.

Der Scanner benötigt diese, um ein geöffnetes Fenster umgehend zu erkennen. Er erkennt ein offenes Fenster auch ohne Fensterkontakt, wenn gilt "aktueller Sollwert" = WindowOpenTemperature. Das Thermostat geht nach erkanntem Temperaturabfall auf diesen Wert.

Attribute Scanner

Parameter Wertebereich Default Beschreibung
disable [0,1] 0 wenn 1, dann wird der Scanner gesperrt und ist somit inaktiv.
scnCreditThreshold [150..600] 300 die Mindestanzahl von verfügbaren Credits, ab der der Scanner mit dem Triggern der Thermostate beginnt
scnMinInterval [3..60] 3 die Mindestwartezeit in Minuten, nach der der Scanner ein Thermostate erneut triggert; diese wird nur berücksichtigt, wenn sie höher ist, als die berechnete Wartezeit, die sich aus der Anzahl der Thermostate ergibt.

Background

Hilfe zur Diagnose der Abläufe

Ein wichtiges Hilfsmittel ist der Event-Monitor. Mit der Filter-Einstellung "MAX.*" werden nur noch die MAX-relevanten Events dargestellt.

Interpretation der Ausgabe:

2016-01-06 21:24:43 MAX HT.BAD desiredTemperature auto 20.0 <-- Triggern des Thermostats durch Scanner
  
2016-01-06 21:24:50 MAX HT.BAD mode: auto             --> Rückmeldung vom Thermostat
2016-01-06 21:24:50 MAX HT.BAD RSSI: -54              --> Rückmeldung vom Thermostat
2016-01-06 21:24:56 MAX HT.BAD temperature: 20.2      --> Rückmeldung vom Thermostat

Hier erscheinen also die zu Thermostat gesendeten Informationen ebenso, wie die empfangenen. Empfangene Informationen sind meist mit einem ":" gekennzeichnet.