FHEMWiki - Benutzerbeiträge [de]

MAX! Temperatur-Scanner

2013-12-02T08:38:06Z

Shorty81:

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.

== Aktuelle Version ==
<strike>
Im Anhang zu folgendem Forumsbeitrag [http://forum.fhem.de/index.php/topic,11624.msg100703.html#msg100703 MaxScan Version 1.04c]</strike>

Im Anhang zu folgendem Forumsbeitrag [http://forum.fhem.de/index.php/topic,11624.msg111299.html#msg111299 MaxScan Version 1.05a]

=== Voraussetzungen ===

==== Qualität der Funkverbindung ====
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>
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.

==== Ausreichend Credits ====
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>
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.

==== Einrichten des Thermostat-internen Wochenprogrammes ====
Anders als bei den Vorgängerversionen <=1.04 ist nun ab Version 1.05 zwingend das Thermostat-interne
Wochenprogramm notwendig. 
D.h. dies muss in den Readings des Thermostats 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.
 
Das bei früheren Versionen eingesetzte Heating_Control kann somit entfallen.

=== 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 nach den Bedürfnissen einstellen
* auf''' keinen''' Fall das Attribut keepAuto setzen
* mit dem userReading "onlyAutoMode" kann der Scan-Modus ModeChange festgelegt werden
<pre>attr HT.JOHN userReadings onlyAutoMode { return "1";;}</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'''

'''Hinweis''' 
Je kleiner der Wert von Attribut verbose, umso weniger Ausgaben erhält man in der Log-Datei.

== 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. 
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 wird 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.
<pre>attr HT.JOHN userReadings onlyAutoMode { return "1";;}</pre>

'''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 ====
[[Datei:2013_12_MaxScanner_Vorher.png|ohne Scanner]]

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

==== mit Scanner (ScanMode=DesiredChange) ====
[[Datei:13_12_01_Scanner_DesiredChange.png|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 dieser Link zeigt:
[http://www.elv.de/topic/tuer-fensterkontakt-sinn-und-unsinn.html 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.

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

=== Unterstützt der Scanner auch den MAX-ECO-Taster ? ===
Nein. Dies wird für künftige Versionen geplant.

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

== Im Kochtopf ==
* Modul-Entwicklung zum Scanner
** Scanner wird nicht mehr als Skript, sondern als Modul ausgeführt.
** pro Thermostat ist dann eine Definition in fhem.cfg vorzunehmen.

== Ausblick==
=== Scanner als Modul ausführen ===

* Wochenprofil als Attribut
* automatischer Abgleich des Wochenprofils mit dem Thermostat
* Fensterkontakt zuordnen
* ECO-Taster integrieren

[[Kategorie:MAX]]

MAX! Temperatur-Scanner

2013-12-01T23:28:04Z

Shorty81: /* ModeChange */

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.

== Aktuelle Version ==
<strike>
Im Anhang zu folgendem Forumsbeitrag [http://forum.fhem.de/index.php/topic,11624.msg100703.html#msg100703 MaxScan Version 1.04c]</strike>

Im Anhang zu folgendem Forumsbeitrag [http://forum.fhem.de/index.php/topic,11624.msg111299.html#msg111299 MaxScan Version 1.05a]

=== Voraussetzungen ===

==== Qualität der Funkverbindung ====
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>
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.

==== Ausreichend Credits ====
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>
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.

==== Einrichten des Thermostat-internen Wochenprogrammes ====
Anders als bei den Vorgängerversionen <=1.04 ist nun ab Version 1.05 zwingend das Thermostat-interne
Wochenprogramm notwendig. 
D.h. dies muss in den Readings des Thermostats 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.
 
Das bei früheren Versionen eingesetzte Heating_Control kann somit entfallen.

=== 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 nach den Bedürfnissen einstellen
* auf''' keinen''' Fall das Attribut keepAuto setzen
* mit dem userReading "onlyAutoMode" kann der Scan-Modus ModeChange festgelegt werden
<pre>attr HT.JOHN userReadings onlyAutoMode { return "1";;}</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'''

'''Hinweis''' 
Je kleiner der Wert von Attribut verbose, umso weniger Ausgaben erhält man in der Log-Datei.

== 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. 
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 wird 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.
<pre>attr HT.JOHN userReadings onlyAutoMode { return "1";;}</pre>

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

=== Vor-/ Nachteile der Modi ===
==== ModeChange ====
Vorteil: Wenn das Ventil weniger Bewegungen macht, reduziert sich die Geräuschbelastung. Bietet sich etwa für Schlaf- und Kinderzimmer an.

Nachteil: Fällt FHEM aus, während das Thermostat gerade im MANU-Modus steht, wird der eingestellte Sollwert nicht mehr geändert!

==== DesiredChange ====
Vorteil: Sicherheitsfanatiker, die den Ausfall von FHEM fürchten, setzen auf diesen Modus. Die Thermostate laufen wie geplant weiter,
auch wenn FHEM ausfällt.

Nachteil: Mehr Ventilbewegungen, ggf. kürze Lebensdauer der Batterien.

=== Ergebnis ===

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

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

==== mit Scanner (ScanMode=DesiredChange) ====
[[Datei:13_12_01_Scanner_DesiredChange.png|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 dieser Link zeigt:
[http://www.elv.de/topic/tuer-fensterkontakt-sinn-und-unsinn.html 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.

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

=== Unterstützt der Scanner auch den MAX-ECO-Taster ? ===
Nein. Dies wird für künftige Versionen geplant.

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

== Im Kochtopf ==
* Modul-Entwicklung zum Scanner
** Scanner wird nicht mehr als Skript, sondern als Modul ausgeführt.
** pro Thermostat ist dann eine Definition in fhem.cfg vorzunehmen.

== Ausblick==
=== Scanner als Modul ausführen ===

* Wochenprofil als Attribut
* automatischer Abgleich des Wochenprofils mit dem Thermostat
* Fensterkontakt zuordnen
* ECO-Taster integrieren

[[Kategorie:MAX]]

MAX! Temperatur-Scanner

2013-12-01T23:25:59Z

Shorty81:

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.

== Aktuelle Version ==
<strike>
Im Anhang zu folgendem Forumsbeitrag [http://forum.fhem.de/index.php/topic,11624.msg100703.html#msg100703 MaxScan Version 1.04c]</strike>

Im Anhang zu folgendem Forumsbeitrag [http://forum.fhem.de/index.php/topic,11624.msg111299.html#msg111299 MaxScan Version 1.05a]

=== Voraussetzungen ===

==== Qualität der Funkverbindung ====
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>
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.

==== Ausreichend Credits ====
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>
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.

==== Einrichten des Thermostat-internen Wochenprogrammes ====
Anders als bei den Vorgängerversionen <=1.04 ist nun ab Version 1.05 zwingend das Thermostat-interne
Wochenprogramm notwendig. 
D.h. dies muss in den Readings des Thermostats 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.
 
Das bei früheren Versionen eingesetzte Heating_Control kann somit entfallen.

=== 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 nach den Bedürfnissen einstellen
* auf''' keinen''' Fall das Attribut keepAuto setzen
* mit dem userReading "onlyAutoMode" kann der Scan-Modus ModeChange festgelegt werden
<pre>attr HT.JOHN userReadings onlyAutoMode { return "1";;}</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'''

'''Hinweis''' 
Je kleiner der Wert von Attribut verbose, umso weniger Ausgaben erhält man in der Log-Datei.

== 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. 
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 wird 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.
<pre>attr HT.JOHN userReadings onlyAutoMode { return "1";;}</pre>

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

=== Vor-/ Nachteile der Modi ===
==== ModeChange ====
Vorteil: Wenn das Ventil weniger Bewegungen macht, reduziert sich die Geräuschbelastung. Bietet sich etwa für Schlaf- und Kinderzimmer an.
Nachteil: Fällt FHEM aus, während das Thermostat gerade im MANU-Modus steht, wird der eingestellte Sollwert nicht mehr geändert!

==== DesiredChange ====
Vorteil: Sicherheitsfanatiker, die den Ausfall von FHEM fürchten, setzen auf diesen Modus. Die Thermostate laufen wie geplant weiter,
auch wenn FHEM ausfällt.

Nachteil: Mehr Ventilbewegungen, ggf. kürze Lebensdauer der Batterien.

=== Ergebnis ===

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

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

==== mit Scanner (ScanMode=DesiredChange) ====
[[Datei:13_12_01_Scanner_DesiredChange.png|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 dieser Link zeigt:
[http://www.elv.de/topic/tuer-fensterkontakt-sinn-und-unsinn.html 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.

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

=== Unterstützt der Scanner auch den MAX-ECO-Taster ? ===
Nein. Dies wird für künftige Versionen geplant.

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

== Im Kochtopf ==
* Modul-Entwicklung zum Scanner
** Scanner wird nicht mehr als Skript, sondern als Modul ausgeführt.
** pro Thermostat ist dann eine Definition in fhem.cfg vorzunehmen.

== Ausblick==
=== Scanner als Modul ausführen ===

* Wochenprofil als Attribut
* automatischer Abgleich des Wochenprofils mit dem Thermostat
* Fensterkontakt zuordnen
* ECO-Taster integrieren

[[Kategorie:MAX]]

MAX! Temperatur-Scanner

2013-12-01T23:25:15Z

Shorty81:

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.

== Aktuelle Version ==
<strike>
Im Anhang zu folgendem Forumsbeitrag [http://forum.fhem.de/index.php/topic,11624.msg100703.html#msg100703 MaxScan Version 1.04c]</strike>

Im Anhang zu folgendem Forumsbeitrag [http://forum.fhem.de/index.php/topic,11624.msg111299.html#msg111299 MaxScan Version 1.05a]

=== Voraussetzungen ===

==== Qualität der Funkverbindung ====
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>
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.

==== Ausreichend Credits ====
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>
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.

==== Einrichten des Thermostat-internen Wochenprogrammes ====
Anders als bei den Vorgängerversionen <=1.04 ist nun ab Version 1.05 zwingend das Thermostat-interne
Wochenprogramm notwendig. 
D.h. dies muss in den Readings des Thermostats 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.
 
Das bei früheren Versionen eingesetzte Heating_Control kann somit entfallen.

=== 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 nach den Bedürfnissen einstellen
* auf''' keinen''' Fall das Attribut keepAuto setzen
* mit dem userReading "onlyAutoMode" kann der Scan-Modus ModeChange festgelegt werden
<pre>attr HT.JOHN userReadings onlyAutoMode { return "1";;}</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'''

'''Hinweis''' 
Je kleiner der Wert von Attribut verbose, umso weniger Ausgaben erhält man in der Log-Datei.

== 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. 
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 wird 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.
<pre>attr HT.JOHN userReadings onlyAutoMode { return "1";;}</pre>

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

=== Vor-/ Nachteile der Modi ===
==== ModeChange ====
Vorteil: Wenn das Ventil weniger Bewegungen macht, reduziert sich die Geräuschbelastung. Bietet sich etwa für Schlaf- und Kinderzimmer an.
Nachteil: Fällt FHEM aus, während das Thermostat gerade im MANU-Modus steht, wird der eingestellte Sollwert nicht mehr geändert!

==== DesiredChange ====
Vorteil: Sicherheitsfanatiker, die den Ausfall von FHEM fürchten, setzen auf diesen Modus. Die Thermostate laufen wie geplant weiter,
auch wenn FHEM ausfällt.

Nachteil: Mehr Ventilbewegungen, ggf. kürze Lebensdauer der Batterien.

=== Ergebnis ===

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

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

==== mit Scanner (ScanMode=DesiredChange) ====
[[Datei:13_12_01_Scanner_DesiredChange.png|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 dieser Link zeigt:
[http://www.elv.de/topic/tuer-fensterkontakt-sinn-und-unsinn.html 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.

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

=== Unterstützt der Scanner auch den MAX-ECO-Taster ? ===
Nein. Dies wird für künftige Versionen geplant.

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

== Im Kochtopf ==
* Modul-Entwicklung zum Scanner
** Scanner wird nicht mehr als Skript, sondern als Modul ausgeführt.
** pro Thermostat ist dann eine Definition in fhem.cfg vorzunehmen.

== Ausblick==
=== Scanner als Modul ausführen ===

* Wochenprofil als Attribut
* automatischer Abgleich des Wochenprofils mit dem Thermostat
* Fensterkontakt zuordnen
* ECO-Taster integrieren

[[Kategorie:MAX]]

RSL 2-Draht Einbauschalter

2013-12-01T23:13:54Z

Shorty81:

Conrad Funk-Einbauschalter 2-Draht RSL (Intertechno kompatibel), zum Einbau in Montagedosen / Unterputzdosen auch ohne Neutralleiter und unter Verwendung des normalen Schalters.
== Eigenschaften ==
Der wesentliche Vorteil des Conrad Funk-Einbauschalter 2-Draht ist, dass er lediglich den Aussenleiter ("Phase") benötigt, um betrieben zu werden. In vielen Installationen befindet sich in der Unterputzwanddose für den Lichtschalter kein Neutrallleiter ("Nullleiter"), sodass die üblichen FS20 oder HomeMatic Unterputzschalter nicht verwendet werden können. In der klassischen Elektroinstallation wird in der Wandose nur der Aussenleiter geschaltet und der Rückleiter auf anderem Wege zur Lichtfassung geführt. Der Conrad Funk-Einbauschalter 2-Draht benötigt tatsächlich nur den ankommenden und abgehenden (geschalteten) Aussenleiter. Er bezieht seine Stromversorgung vermutlich aus den Potentialunterschieden der beiden Aussenleiterstränge auch im ausgeschaltetem Zustand, hierbei wird wahrscheinlich das Neutralleiterpotential durch den zu schaltenden Verbraucher genutzt. Vermutlich aus diesem Grunde kann der Schalter nicht verwendet werden, wenn der zu schaltende Verbraucher eine Leuchtstoffröhre ist.

Überdies benötigt der Conrad Funk-Einbauschalter 2-Draht keinen Taster zur Vor-Ort-Betätigung, sondern die zwei herausgeführten Schaltdrähte können mittels des vorher verbauten Schalters aus einem normalen Schalterprogramm betrieben werden. Der Schalter wird hierbei wie ein Toggle verwendet. D.h., egal welche Stellung der Schalter hat, der Conrad Funk-Einbauschalter 2-Draht kann vollständig per Funk geschaltet werden, der lokale mechanische Schalter ändert bei jeder Betätigung den Schaltzustand.

Vorteile des Conrad Funk-Einbauschalter 2-Draht gegenüber FS20 und HM Unterputzschaltern wie [[FS20 SU Unterputz-Funk-Schalter]]:

* benötigt nur Aussenleiter zur Stromversorgung
* dünner als FS20 Unterputzschalter, daher leichter auch hinter dem normalen Lichtschalter einbaubar
* benötigt keinen Taster, sondern kann mit (vorhandenem) Schalter betrieben werden
* RSL Funk, also kompatibel mit Intertechno 433 Mhz

== Hinweise zum Betrieb mit FHEM ==
Der Conrad Funk-Einbauschalter 2-Draht hat keine Kodierschalter, sondern muss angelernt werden. Da dazu der gewünschte Intertechnokanal drei Sekunden lang senden muss, ist ein Anlernen mit FHEM nicht möglich, da FHEM ununterbrochenes Senden nicht beherrscht. Der Schalter kann aber leicht mit einer gängigen Intertechno Fernbedienung wie z.b. einer YCT-100 angelernt werden. (Es muss eine IT Fernbedienung sein, bei der man die Adresse selber einstellen kann, das ist bei der YCT-100 der Fall. Nicht geeignet sind die Fernbedienungen, der Code fest ist, wie z.b. die aus den IT 1500 Sets).
Dann den [[Intertechno_Code_Berechnung#originales_Intertechno_System|Code ermitteln]] und in Fhem eintragen.

Einmal angelernt ist eine Schaltung per FHEM kein Problem.

== Einbindung in Tasterschaltungen ==
Die Installation verläuft analog zur Verwendung mit Schaltern.
Das Ergebnis der Betätigung eines Tasters (zum Beispiel im Flur) hängt vom Zustand des angeschlossenen Stromstoßrelais ab. War es vorher eingeschaltet, dann wird ausgeschaltet und umgekehrt. Das wird häufig durch eine mechanische Verriegelung, ähnlich der eines Kugelschreibers, erreicht, die einmal eingreift und beim erneuten Betätigen wieder gelöst wird.

Würde der RSL-2-Drahtschalter nun lediglich mit ON eingeschaltet, würde ein Dauerstrom zum Relais fließen (Ergebnis: das Relais summt permanent).
Um dies zu verhindern und nur einen kurzen Impuls zu senden, muss der RSL-Schalter umgehend nach der Betätigung wieder auf OFF gesetzt werden.
Dies geschieht mit folgender Lösung via at:
<pre>define Tasterschaltung notify RSL:on set RSL off</pre>

== Bekannte Probleme ==
Die Schaltleistung des Conrad Funk-Einbauschalter ist mit 300 Watt ohmscher und 100 Watt induktiver Last deutlich geringer als die anderer Produkte, für Licht aber völlig ausreichend.

Nicht geeignet, wenn im zu schaltetenden Stromkreis nur Leuchtstoffröhren zu schalten sind.

Bei schlechter Funklage hilft ggf. das Drehen des Schalters in der Wanddose um 90 Grad.

Bei Tasterschaltungen wird der tatsächliche State nie in FHEM erfasst, da
a) der Schalter immer wieder auf OFF gesetzt wird
b) in der Regel mehrere Taster im Flur vorhanden sind, deren Betätigung FHEM nicht mitbekommt

== Links ==

[[Kategorie:Other Components]]

RSL 2-Draht Einbauschalter

2013-12-01T23:05:02Z

Shorty81:

Conrad Funk-Einbauschalter 2-Draht RSL (Intertechno kompatibel), zum Einbau in Montagedosen / Unterputzdosen auch ohne Neutralleiter und unter Verwendung des normalen Schalters.
== Eigenschaften ==
Der wesentliche Vorteil des Conrad Funk-Einbauschalter 2-Draht ist, dass er lediglich den Aussenleiter ("Phase") benötigt, um betrieben zu werden. In vielen Installationen befindet sich in der Unterputzwanddose für den Lichtschalter kein Neutrallleiter ("Nullleiter"), sodass die üblichen FS20 oder HomeMatic Unterputzschalter nicht verwendet werden können. In der klassischen Elektroinstallation wird in der Wandose nur der Aussenleiter geschaltet und der Rückleiter auf anderem Wege zur Lichtfassung geführt. Der Conrad Funk-Einbauschalter 2-Draht benötigt tatsächlich nur den ankommenden und abgehenden (geschalteten) Aussenleiter. Er bezieht seine Stromversorgung vermutlich aus den Potentialunterschieden der beiden Aussenleiterstränge auch im ausgeschaltetem Zustand, hierbei wird wahrscheinlich das Neutralleiterpotential durch den zu schaltenden Verbraucher genutzt. Vermutlich aus diesem Grunde kann der Schalter nicht verwendet werden, wenn der zu schaltende Verbraucher eine Leuchtstoffröhre ist.

Überdies benötigt der Conrad Funk-Einbauschalter 2-Draht keinen Taster zur Vor-Ort-Betätigung, sondern die zwei herausgeführten Schaltdrähte können mittels des vorher verbauten Schalters aus einem normalen Schalterprogramm betrieben werden. Der Schalter wird hierbei wie ein Toggle verwendet. D.h., egal welche Stellung der Schalter hat, der Conrad Funk-Einbauschalter 2-Draht kann vollständig per Funk geschaltet werden, der lokale mechanische Schalter ändert bei jeder Betätigung den Schaltzustand.

Vorteile des Conrad Funk-Einbauschalter 2-Draht gegenüber FS20 und HM Unterputzschaltern wie [[FS20 SU Unterputz-Funk-Schalter]]:

* benötigt nur Aussenleiter zur Stromversorgung
* dünner als FS20 Unterputzschalter, daher leichter auch hinter dem normalen Lichtschalter einbaubar
* benötigt keinen Taster, sondern kann mit (vorhandenem) Schalter betrieben werden
* RSL Funk, also kompatibel mit Intertechno 433 Mhz

== Hinweise zum Betrieb mit FHEM ==
Der Conrad Funk-Einbauschalter 2-Draht hat keine Kodierschalter, sondern muss angelernt werden. Da dazu der gewünschte Intertechnokanal drei Sekunden lang senden muss, ist ein Anlernen mit FHEM nicht möglich, da FHEM ununterbrochenes Senden nicht beherrscht. Der Schalter kann aber leicht mit einer gängigen Intertechno Fernbedienung wie z.b. einer YCT-100 angelernt werden. (Es muss eine IT Fernbedienung sein, bei der man die Adresse selber einstellen kann, das ist bei der YCT-100 der Fall. Nicht geeignet sind die Fernbedienungen, der Code fest ist, wie z.b. die aus den IT 1500 Sets).
Dann den [[Intertechno_Code_Berechnung#originales_Intertechno_System|Code ermitteln]] und in Fhem eintragen.

Einmal angelernt ist eine Schaltung per FHEM kein Problem.

== Einbindung in Tasterschaltungen ==
Die Installation verläuft analog zur Verwendung mit Schaltern.
Das Ergebnis der Betätigung eines Tasters (zum Beispiel im Flur) hängt vom Zustand des angeschlossenen Stromstoßrelais ab. War es vorher eingeschaltet, dann wird ausgeschaltet und umgekehrt. Das wird häufig durch eine mechanische Verriegelung, ähnlich der eines Kugelschreibers, erreicht, die einmal eingreift und beim erneuten Betätigen wieder gelöst wird.

Würde der RSL-2-Drahtschalter nun lediglich mit ON eingeschaltet, würde ein Dauerstrom zum Relais fließen (Ergebnis: das Relais summt permanent).
Um dies zu verhindern und nur einen kurzen Impuls zu senden, muss der RSL-Schalter umgehend nach der Betätigung wieder auf OFF gesetzt werden.
Dies geschieht mit folgender Lösung via at:

''define Tasterschaltung notify RSL:on set RSL off''

== Bekannte Probleme ==
Die Schaltleistung des Conrad Funk-Einbauschalter ist mit 300 Watt ohmscher und 100 Watt induktiver Last deutlich geringer als die anderer Produkte, für Licht aber völlig ausreichend.

Nicht geeignet, wenn im zu schaltetenden Stromkreis nur Leuchtstoffröhren zu schalten sind.

Bei schlechter Funklage hilft ggf. das Drehen des Schalters in der Wanddose um 90 Grad.

Bei Tasterschaltungen wird der tatsächliche State nie in FHEM erfasst, da
a) der Schalter immer wieder auf OFF gesetzt wird
b) in der Regel mehrere Taster im Flur vorhanden sind, deren Betätigung FHEM nicht mitbekommt

== Links ==

[[Kategorie:Other Components]]

RSL 2-Draht Einbauschalter

2013-12-01T23:03:46Z

Shorty81:

Conrad Funk-Einbauschalter 2-Draht RSL (Intertechno kompatibel), zum Einbau in Montagedosen / Unterputzdosen auch ohne Neutralleiter und unter Verwendung des normalen Schalters.
== Eigenschaften ==
Der wesentliche Vorteil des Conrad Funk-Einbauschalter 2-Draht ist, dass er lediglich den Aussenleiter ("Phase") benötigt, um betrieben zu werden. In vielen Installationen befindet sich in der Unterputzwanddose für den Lichtschalter kein Neutrallleiter ("Nullleiter"), sodass die üblichen FS20 oder HomeMatic Unterputzschalter nicht verwendet werden können. In der klassischen Elektroinstallation wird in der Wandose nur der Aussenleiter geschaltet und der Rückleiter auf anderem Wege zur Lichtfassung geführt. Der Conrad Funk-Einbauschalter 2-Draht benötigt tatsächlich nur den ankommenden und abgehenden (geschalteten) Aussenleiter. Er bezieht seine Stromversorgung vermutlich aus den Potentialunterschieden der beiden Aussenleiterstränge auch im ausgeschaltetem Zustand, hierbei wird wahrscheinlich das Neutralleiterpotential durch den zu schaltenden Verbraucher genutzt. Vermutlich aus diesem Grunde kann der Schalter nicht verwendet werden, wenn der zu schaltende Verbraucher eine Leuchtstoffröhre ist.

Überdies benötigt der Conrad Funk-Einbauschalter 2-Draht keinen Taster zur Vor-Ort-Betätigung, sondern die zwei herausgeführten Schaltdrähte können mittels des vorher verbauten Schalters aus einem normalen Schalterprogramm betrieben werden. Der Schalter wird hierbei wie ein Toggle verwendet. D.h., egal welche Stellung der Schalter hat, der Conrad Funk-Einbauschalter 2-Draht kann vollständig per Funk geschaltet werden, der lokale mechanische Schalter ändert bei jeder Betätigung den Schaltzustand.

Vorteile des Conrad Funk-Einbauschalter 2-Draht gegenüber FS20 und HM Unterputzschaltern wie [[FS20 SU Unterputz-Funk-Schalter]]:

* benötigt nur Aussenleiter zur Stromversorgung
* dünner als FS20 Unterputzschalter, daher leichter auch hinter dem normalen Lichtschalter einbaubar
* benötigt keinen Taster, sondern kann mit (vorhandenem) Schalter betrieben werden
* RSL Funk, also kompatibel mit Intertechno 433 Mhz

== Hinweise zum Betrieb mit FHEM ==
Der Conrad Funk-Einbauschalter 2-Draht hat keine Kodierschalter, sondern muss angelernt werden. Da dazu der gewünschte Intertechnokanal drei Sekunden lang senden muss, ist ein Anlernen mit FHEM nicht möglich, da FHEM ununterbrochenes Senden nicht beherrscht. Der Schalter kann aber leicht mit einer gängigen Intertechno Fernbedienung wie z.b. einer YCT-100 angelernt werden. (Es muss eine IT Fernbedienung sein, bei der man die Adresse selber einstellen kann, das ist bei der YCT-100 der Fall. Nicht geeignet sind die Fernbedienungen, der Code fest ist, wie z.b. die aus den IT 1500 Sets).
Dann den [[Intertechno_Code_Berechnung#originales_Intertechno_System|Code ermitteln]] und in Fhem eintragen.

Einmal angelernt ist eine Schaltung per FHEM kein Problem.

== Einbindung in Tasterschaltungen ==
Die Installation verläuft analog zur Verwendung mit Schaltern.
Das Ergebnis der Betätigung eines Tasters (zum Beispiel im Flur) hängt vom Zustand des angeschlossenen Stromstoßrelais ab. War es vorher eingeschaltet, dann wird ausgeschaltet und umgekehrt. Das wird häufig durch eine mechanische Verriegelung, ähnlich der eines Kugelschreibers, erreicht, die einmal eingreift und beim erneuten Betätigen wieder gelöst wird.

Würde der RSL-2-Drahtschalter nun lediglich mit ON eingeschaltet, würde ein Dauerstrom zum Relais fließen (Ergebnis: das Relais summt permanent).
Um dies zu verhindern und nur einen kurzen Impuls zu senden, muss der RSL-Schalter umgehend nach der Betätigung wieder auf OFF gesetzt werden.
Dies geschieht mit folgender Lösung via at:

define Tasterschaltung notify RSL:on set RSL off

== Bekannte Probleme ==
Die Schaltleistung des Conrad Funk-Einbauschalter ist mit 300 Watt ohmscher und 100 Watt induktiver Last deutlich geringer als die anderer Produkte, für Licht aber völlig ausreichend.

Nicht geeignet, wenn im zu schaltetenden Stromkreis nur Leuchtstoffröhren zu schalten sind.

Bei schlechter Funklage hilft ggf. das Drehen des Schalters in der Wanddose um 90 Grad.

Bei Tasterschaltungen wird der tatsächliche State nie in FHEM erfasst, da
a) der Schalter immer wieder auf OFF gesetzt wird
b) in der Regel mehrere Taster im Flur vorhanden sind, deren Betätigung FHEM nicht mitbekommt

== Links ==

[[Kategorie:Other Components]]