http://wiki.fhem.de/w/api.php?action=feedcontributions&user=John&feedformat=atomFHEMWiki - Benutzerbeiträge [de]2024-03-29T11:44:22ZBenutzerbeiträgeMediaWiki 1.39.3http://wiki.fhem.de/w/index.php?title=KostalPiko&diff=22909KostalPiko2017-10-13T20:21:42Z<p>John: /* Inbetriebnahme */</p>
<hr />
<div>{{Infobox Modul<br />
|ModPurpose=KostalPiko erfasst Informationen vom gleichnamigen Wechselrichter der Fa. Kostal; unabhängig davon kann das Modul auch dazu verwendet werden, die Globalstrahlung am Standort für den aktuellen oder nächsten Tag zu ermitteln.<br />
|ModType=d<br />
|ModCmdRef=KOSTALPIKO<br />
|ModForumArea=Codeschnipsel<br />
|ModTechName=23_KOSTALPIKO.pm<br />
|ModOwner=John ([http://forum.fhem.de/index.php?action=profile;u=806 Forum] / [[Benutzer Diskussion:John|Wiki]])}}<br />
Anbindung des Wechselrichters Piko der Fa. Kostal Solar Electric<br />
<br />
== Geräte Beschreibung ==<br />
Der Solar-Wechselrichter Piko der Fa. Kostal liefert über die Geräte-Webseite wichtige technische Informationen wie<br />
* aktuelle Leistung<br />
* Tages-Energie<br />
* Gesamt-Energie<br />
* Strom und Spannung der drei Input-Strings<br />
* Spannung und Leistung der drei Ausgangsphasen<br />
<br />
Das Gerät verfügt über eine Ethernet-Schnittstelle, über die die Webseite des Gerätes erreichbar ist.<br />
<br />
Aber ohne Wechselrichter kann das Modul hilfreich sein: es erfasst von der Seite<br />
:<code><nowiki>http://www.proplanta.de/Wetter/<meineStadt>-Wetter-Heute.html</nowiki></code><br />
bzw.<br />
:<code><nowiki>http://www.proplanta.de/Wetter/<meineStadt>-Wetter-Morgen.html</nowiki></code><br />
Wetterdaten für den heutigen bzw. für den nächsten Tag (siehe unter Readings, diejenigen, die mit "proplanta" gekennzeichnet sind).<br />
<br />
== FHEM-Modul ==<br />
Das Modul 23_KOSTALPIKO.pm übernimmt folgende Aufgaben:<br />
<br />
* Erfassen der Daten aus der Webseite von Piko<br />
* Erfassen der Erwartungswerte für Gobalstrahlung, UV-Index und Sonnenscheindauer von folgender Webseite [http://www.proplanta.de/Agrar-Wetter/Deutschland/]<br />
* über UserReadings kann der zu erwartenden Energieertrag ermittelt und mit der tatsächlich erzeugten Energiemenge verglichen werden.<br />
=== Define ===<br />
Definition des Geräts in der [[Konfiguration|fhem.cfg]]:<br />
:<code>define <name> KOSTALPIKO <ip-adresse-kostal> <user> <password> </code><br />
<br />
'''Beispiel:'''<br />
:<code>define <name> KOSTALPIKO 192.168.178.99 pvserver pvwr </code><br />
<br />
{| class="wikitable sortable"<br />
|-<br />
! Parameter !! Beschreibung<br />
|-<br />
|<name>||FHEM Name des Devices<br />
|-<br />
|<ip-adresse-kostal>||IP-Adresse von Kostal Piko<br />
|-<br />
|<user>||der User-Name für die Einwahl zur Kostal-Webseite<br />
|-<br />
|<password>||das Passwort für die Einwahl zur Kostal-Webseite<br />
|-<br />
|}<br />
<br />
=== Attribute ===<br />
{| class="wikitable sortable"<br />
|-<br />
! Parameter !! Wertebereich !! Default !! Beschreibung<br />
|-<br />
|GR.Interval||uint||3600||Intervall der Aktualisierung der Globalstrahlung in Sekunden<br />
|-<br />
|GR.Link||string||||Link auf die regionalisierte Seite von http://www.proplanta.de/Wetter/<city>-Wetter-Heute.html<br />
|-<br />
|delay||uint||60||Intervall in Sekunden zu Erfassung der Daten von Kostalpiko<br />
|-<br />
|delayCounter||uint||0||Counter bei Nutzung von AC.Power.Fast<br />
|-<br />
|disable||[0,1]||0||Erfassung von Kostalpiko-Daten ist gesperrt, nicht jedoch der Globalstrahlung<br />
|-<br />
|verbose||[0..5]||0||Log-Ausgabe steuern: 0=keine Ausgaben,5=viele Informationen<br />
|-<br />
|}<br />
<br />
=== Setter ===<br />
'''captureGlobalRadiation'''<br />
* Funktion: manuell die sofortige Erfassung der Werte der Proplanta-Seite anstossen<br />
<br />
'''captureKostalData'''<br />
* Funktion: manuell die sofortige Erfassung der Daten von KostalPiko anstossen<br />
<br />
=== Readings ===<br />
* AC.Power, die aktuelle erzeugte Leistung<br />
* AC.Power.Fast, die aktuell erzeugte Leistung im Schnelltast-Modus<br />
* Daily.Energy, die bisher erzeugte Tagesenergie<br />
* Daily.Energy.Last, die erzeugte Energie des letzten Tages, wird um 23:00 Uhr ermittelt.<br />
* Global.Radiation, die Globalstrahlung am gewählten Standort, damit die erwartete Tagesenergie berechnet werden (proplanta)<br />
* Mode, der Status von KostalPiko<br />
* ModeNum, die nummerische Zuordnung zum Status (0=Aus 1=Leerlauf 2=Einspeisen MPP)<br />
* Total.Energy, die erzeugte Gesamtenergie<br />
* generator.1.current, Strom an String 1 [A]<br />
* generator.1.voltage, Spannung an String 1 [V]<br />
* generator.2.current, Strom an String 2 [A]<br />
* generator.2.voltage, Spannung an String 2 [V]<br />
* generator.3.current, Strom an String 3 [A]<br />
* generator.3.voltage, Spannung an String 3 [V]<br />
* output.1.voltage, Spannung an L1 [V]<br />
* output.1.power, Leistung an L1 [W]<br />
* output.2.voltage, Spannung an L2 [V]<br />
* output.2.power, Leistung an L2 [W]<br />
* output.3.voltage, Spannung an L3 [V]<br />
* output.3.power, Leistung an L3 [W]<br />
* sensor.1, Spannung an 1. analogem Eingang [V]<br />
* sensor.2, Spannung an 2. analogem Eingang [V]<br />
* sensor.3, Spannung an 3. analogem Eingang [V]<br />
* sensor.4, Spannung an 4. analogem Eingang [V]<br />
* UV.Index, UV-Index (proplanta)<br />
* sunshine.duration, rel. Sonnenscheindauer [%] (proplanta)<br />
<br />
== Inbetriebnahme ==<br />
* KOSTALPIKO samt Abfrage-Intervall definieren<br />
<pre><br />
define Kostal KOSTALPIKO 192.168.178.99 pvserver pvwr<br />
attr Kostal delay 60<br />
</pre><br />
* Abfrageintervall und WEB-Seite für die Globalstrahlung<br />
<pre><br />
attr Kostal GR.Interval 3600<br />
attr Kostal GR.Link http://www.proplanta.de/Wetter/Straubing-Wetter-Heute.html<br />
</pre><br />
Die passende URL für die Web-Seite am Standort lässt sich wie folgt ermitteln.<br />
(hier am Beispiel der Stadt Straubing)<br /><br />
Diese Seite anwählen<br />
http://www.proplanta.de/Agrar-Wetter/Deutschland/ <br /><br />
Postleitzahl eingeben: 94315<br /><br />
ggf. bei Auswahlbox rechts zusätzlich auswählen --> Button "Aufrufen"<br /><br />
<br /><br />
Am untersten Ende der nun aufgerufenen Seite findet sich der Link zu "Wetterrückbick Straubing" --> Click<br />
<br /><br />
<br />
Auf der nun erscheinenden Seite findet sich ebenfalls am unteren Ende:"Wetteraussichten Heute" - Click<br />
<br /><br />
Nun merken wir uns die URL der aktuellen Seite und tragen diesen beim Attribut GR.Link ein.<br /><br />
(im Beispiel: http://www.proplanta.de/Wetter/Straubing-Wetter-Heute.html)<br /><br /><br />
Auf dieser Seite wird das Modul nach dem Begriff "Globalstrahlung" suchen und den Wert extrahieren.<br />
<br />
* nun legen wir noch ein UserReading an um über die Globalstrahlung die erwartete Energie zu berechnen<br />
wir verwenden die Formel<br />
<pre> Expected Energy = <PV-Fläche> * GlobalStrahlung * Systemnutzungsgrad</pre><br />
und somit (mit PV-Fläche=37qm und Systemnutzungsgrad = 10%)<br /><br />
<pre><br />
attr Kostal userReadings EnergyExpected {return ReadingsVal ("Kostal","Global.Radiation",0)*37*0.10;;}<br />
</pre><br />
<br />
* FileLog für die Aktualwerte<br />
<pre><br />
define Kostal.File FileLog ./log/Kostal-%Y.log Kostal:(AC.Power:|Daily.Energy:|Daily.Energy.Last:|Total.Energy:|ModeNum:|EnergyExpected:).*<br />
attr Kostal.File logtype text<br />
</pre><br />
<br />
* eine passende Grafik über den Plot-Editor erstellen; der Plot-Editor ist über das FileLog-Objekt erreichbar.<br />
[[File:Kostal_filelog.png]]<br />
<br />
* folgende beispielhafte Werte einstellen<br />
[[File:Kostal_chartCreate.png]]<br />
<br />
* ein FileLog für die erzeugte Tages-Energie<br />
<pre><br />
define Kostal.File_2 FileLog ./log/Kostal_2-%Y.log Kostal:(Daily.Energy.Last:).*<br />
attr Kostal.File_2 logtype text<br />
</pre><br />
<br />
* eine passende Grafik über den Plot-Editor erstellen (Attribut fixedrange auf month setzen)<br />
[[File:Kostal_chartMCreate.png]]<br />
<br />
* Turbo-Modus für AC.Power.<br/><br />
AC.Power.Fast hat ja zunächst denselben Wert wie AC.Power.<br/><br />
Wer jedoch das schnelle Reading nutzen will setzt zunächst den Wert von Attribut delay runter z.B auf minütliche Abtastung. <br/><br />
Dann würde jedoch die LogDatei schnell anwachsen, was nicht jeder will.<br/><br />
Daher gibt es das Attribut delayCounter. <br />
Mit delayCounter=5 wird nur AC.Power.Fast minütlich abgetastet, alle anderen Readings werde mit 5 * 60 sec. =300 sec aktualisiert.<br />
<br />
== Fragen und Antworten ==<br />
==== Erfassung der Globalstrahlung ohne KostalPiko ====<br />
;Frage<br />
:Ich habe keinen KostalPiko, kann ich das Modul zur Erfassung der Globalstrahlung verwenden?<br />
;Antwort<br />
:Das ist möglich.<br />Hierzu alles wie im Kapitel Inbetriebnahme beschrieben parametrieren und zusätzlich das Attribut <code>disable 1</code> setzen.<br /> Damit wird KostalPiko nicht angesprochen, jedoch bei vorhandenen GR.* Attributen die Readings der Proplanta-Seite (u.a. eben auch die Globalstrahlung) dennoch erfasst.<br />
<br />
==== Erfassung der Globalstrahlung für den nächsten Tag ====<br />
;Frage<br />
:Kann das Modul zur Erfassung der Globalstrahlung des nächsten Tages verwendet werden?<br />
;Antwort<br />
:Das ist möglich. Dazu muss das Attribut GR.Link von <br /><code>http://www.proplanta.de/Wetter/<meineStadt>-Wetter-'''Heute'''.html <code><br />auf <br /><code>http://www.proplanta.de/Wetter/<meineStadt>-Wetter-'''Morgen'''.html </code> <br />geändert werden.<br />
<br />
== Links ==<br />
* Webseite des Herstellers [http://www.kostal-solar-electric.com Kostal]<br />
* Forenbeitrag zu diesem {{Link2Forum|Topic=24409}}<br />
<br />
[[Kategorie:Other Components]]<br />
[[Kategorie:Energieerzeugungsmessung]]</div>Johnhttp://wiki.fhem.de/w/index.php?title=PID20_-_Der_PID-Regler&diff=13716PID20 - Der PID-Regler2016-01-21T08:24:56Z<p>John: /* I-Anteil auf 0 setzen */</p>
<hr />
<div>{{Infobox Modul<br />
|Name=PID20<br />
|ModPurpose=Regler nach P-I-D Algorithmus<br />
|ModType=d<br />
|ModCmdRef=PID20<br />
|ModForumArea=Automatisierung<br />
|ModTechName=98_PID20.pm<br />
|ModOwner=John ({{Link2FU|806|Forum}} / [[Benutzer Diskussion:John|Wiki]])<br />
}}<br />
'''PID20''' ist ein Modul, das nach dem P-I-D Algorithmus einen Regler realisiert.<br />
<br />
== Projekt-Status ==<br />
Das Modul ist seit dem 26.03.2014 Bestandteil von FHEM.<br />
<br />
== Features ==<br />
* einstellbarer Bewertungs-/Berechnungszyklus<br />
* Überwachung des Istwert-Gebers über dessen Zeitstempel (Sensorausfall)<br />
* Skalierbarkeit der Ausgabehäufigkeit an das Stellglied über Zeit und Mindeständerung<br />
* Zwangsausgabe an das Stellglied nach Ablauf eines einstellbaren Zeitintervalls<br />
* Notstellung des Stellgliedes, falls Istwert-Geber ausgefallen ist<br />
* Begrenzung des Stellbereichs nach oben und unten<br />
* Festlegung der Nachkommastellen (0..5) des Ausgabewertes zum Stellglied<br />
* Festlegen einer minimalen Regelabweichung, ab der der Regler aktiv wird<br />
* Festlegen des Reading-Namens für den Sollwert<br />
* Festlegen des Reading-Namens für den Istwert<br />
* Invertierung des Reglerwirksinns<br />
* Festlegen der minimalen Aktualisierungsrate der Readings<br />
* Festlegen der Proportionalitätskonstanten P,I,D<br />
== Thread im Forum ==<br />
[http://forum.fhem.de/index.php/topic,17067.msg111615.html#msg111615 Diskussion zu PID20 im Forum]<br />
<br />
=== Define ===<br />
:<code>define <name> PID20 sensor[:reading[:regexp]] actor:cmd</code><br />
<br />
=== Attribute ===<br />
{| class="wikitable sortable"<br />
|-<br />
! Parameter !! Wertebereich !! Default !! Beschreibung<br />
|-<br />
|pidActorValueDecPlaces||[0..5]||0||Anzahl der Nachkommastellen für Ausgabewert zu Aktor<br />
|-<br />
|pidActorInterval||uint||180||minimale Wartezeit in Sekunden, bis eine neue Ausgabe an das Stellglied erfolgen kann<br />
|-<br />
|pidActorThreshold||uint||1||Notwendige minimale Änderung zum Altwert der Stellgliedausgabe, damit diese erneut erfolgt<br />
|-<br />
|pidActorErrorAction||[freeze, errorPos]||freeze||legt das Verhalten der Ausgabe zum Stellglied fest, wenn der Istwert nicht innerhalb von <pidSensorTimeout> aktualisiert wurde (Sensor-Ausfall) <br /><br />
freeze: Position des Stellgliedes beibehalten<br /><br />
ErrorPos: Position anfahren, die unter Attribut <pidActorErrorPos> angegeben ist."<br />
|-<br />
|pidActorErrorPos||int||0||Diese Position ist einzunehmen, wenn pidActorErrorAction auf errorPos steht und der Istwert-Geber ausgefallen ist.<br />
|-<br />
|pidActorKeepAlive||uint||1800||Spätestens nach dieser Zeit erfolgt eine Zwangsausgabe an das Stellglied<br />
(wenn PID nicht disabled und nicht stopped)<br />
|-<br />
|pidActorLimitLower||float||0||untere Begrenzung für das Stellglied<br />
|-<br />
|pidActorLimitUpper||float||100||obere Begrenzung für das Stellglied<br />
|-<br />
|pidCalcInterval||uint||60||Berechnungszyklus in Sekunden, nach dem die PID-Berechnung durchgeführt wird.<br />
|-<br />
|pidDeltaTreshold||pos. float||0||wenn die Regeldifferenz(delta) kleiner als pidDeltaThreshold, dann wird der Regler eingefroren (state=idle)<br />
|-<br />
|pidDesiredName||string||desired||Name für das Reading, das den Sollwert für den Regler aufnehmen soll<br />
|-<br />
|pidMeasuredName||string||measured||Name für das Reading, das den Istwert für den Regler aufnehmen soll<br />
|-<br />
|pidSensorTimeout||uint||3600||Zeitlimit in Sekunden, nach dessen Überschreitung der Ausfall des Istwert-Gebers anzunehmen ist<br />
|-<br />
|pidReverseAction||[0,1]||0||Umgekehrter Wirksinn des Reglers<br />
|-<br />
|pidUpdateInterval||uint||300||Zeitlimit in Sekunden, nach der ein Zwangsupdate der Readings erfolgen muss (Kurvendarstellung).<br />
|-<br />
|pidFactor_P||pos. float||25||Proportionalitätskonstante für P-Anteil<br />
<br />
|-<br />
|pidFactor_I||pos. float||0.25||Proportionalitätskonstante für I-Anteil<br />
<br />
|-<br />
|pidFactor_D||pos. float||0||Proportionalitätskonstante für D-Anteil<br />
|-<br />
|disable||[0,1]||0||Freigabe/Sperren des Reglers<br />
|}<br />
<br />
=== Setter ===<br />
'''desired'''<br />
* Funktion: Sollwert einstellen<br />
* Name des Setters kann vom Anwender über das Attribute "pidDesiredName" definiert werden<br />
<br />
'''start'''<br />
* PID nimmt den Betrieb wieder auf, es werden P-, I- und D-Anteil vor dem Stop übernommen<br />
<br />
'''stop'''<br />
* PID geht in den Zustand stopped; alles wird praktisch eingefroren<br />
<br />
'''restart'''<br />
* arbeitet zunächst wie Start, jedoch gibt man an, mit welchen Prozentwert der Stellausgang anfangs stehen soll<br />
<br />
=== Readings ===<br />
[[Datei:13 10 20 Pid readings.png]]<br />
* actuation liefert den tatsächlichen Ausgabewert an das Stellglied<br />
* actuationCalc liefert den internen Rechenwert des Ausgabewertes für das Stellglied(ohne Begrenzung)<br />
* delta, die aktuelle Regeldifferenz<br />
* desired (Name ist variabel), der Sollwert<br />
* measured (Name ist variabel), der aktuelle Wert vom Istwert-geber<br />
* p_p, der P-Anteil des Ausgabewertes für das Stellglied<br />
* p_i, der I-Anteil des Ausgabewertes für das Stellglied<br />
* p_d, der D-Anteil des Ausgabewertes für das Stellglied<br />
* state, der Betriebszustand des Reglers<br />
<br />
'''delta'''<br />
<br />
:<code>delta = desired - measured (also Sollwert-Istwert)</code><br />
<br />
'''actuation'''<br />
<br />
:<code>actuation = actuationCalc</code><br />
<br />
jedoch begrenzt durch pidActorLimitLower und pidActorLimitUpper und formatiert via pidActorValueDecPlaces<br />
<br />
'''actuationCalc'''<br />
<br />
Der Ausgabewert für das Stellglied wird wie folgt berechnet<br />
:<code>actuationCalc = p_p + p_i + p_d</code><br />
<br />
'''state'''<br />
<br />
{| class="wikitable"<br />
|-<br />
! state !! Erläuterung<br />
|-<br />
| disabled || PID-Instanz ist inaktiv<br />
|-<br />
| initializing || Modul wurde initialisiert<br />
|-<br />
| idle || Berechnung ist inaktiv<br />
|-<br />
| processing || Berechnung ist aktiv, Normalbetrieb<br />
|-<br />
| alarm || Ausnahmezustand, z.B. Timout des Istwert-Gebers<br />
|}<br />
<br />
== Inbetriebnahme ==<br />
* PID20 definieren, hier mit HMS100TF als Istwert-Geber für die Temperatur und ein MAX-Thermostat als Stellglied; Auslegung für eine Fußbodenheizung (sehr träge)<br />
:<code>define PID.FUBO PID20 DG.BAD.TF:temperature HT.FUBO:maxValveSetting</code><br />
** <sensor> = "DG.BAD.TF": Name des Istwert-Geber s (HMS100TF)<br />
** <reading> = "temperature": das Reading vom HMS100TF, das die Temperatur liefert<br />
** <regexp> = nicht definiert, wir können also direkt den Wert des Readings verwenden<br />
** <actor> = "HT.FUBO" : Name des MAX-Thermostats, das als Stellglied verwendet wird<br />
** <cmd> = "maxValveSetting" : Das Kommando mit dem PID20 die Stellausgabe realisieren soll<br />
:Letztlich wird mit <actor> und <cmd> Folgendes ausgeführt:<br />
::<code>set <actor> <cmd> <setting-value></code><br />
<br />
'''Zusätzlich noch einige Attribute anpassen:'''<br />
* die Ausgabehäufigkeit an das Stellglied auf 15 Minuten begrenzen<br />
:<code>attr PID.FUBO pidActorInterval 900</code><br />
* nur dann einen Wert an das Stellglied ausgeben, wenn die Differenz zum Altwert >= 5% <br />
:<code>attr PID.FUBO pidActorTreshold 5</code><br />
* Nachommastellen für das Stellglied festlegen; MAX-Thermostate erlauben nur Werte ohne Nachkommastellen<br />
:<code>attr PID.FUBO pidActorValueDecPlaces 0</code><br />
* I-Faktor festlegen; Überlegung: bei einer Regelabweichung von 1 Grad, soll der I-Anteil um 0.2% pro Minute inkrementieren/dekrementieren <br />
:<code>attr PID.FUBO pidFactor_I 0.2</code><br />
* P-Faktor festlegen; Überlegung:Bei einer Regel-Abweichung von 1 Grad, soll der P-Anteil +/-50% betragen<br />
:<code>attr PID.FUBO pidFactor_P 50</code><br />
* Häufigkeit der Events begrenzen: Die Readings werden im Intervall von "pidCalcInterval" aktualisiert. Die damit erzeugten Events kann man mit den Standard-Mechanismen von FHEM begrenzen. Hier wird festgelegt, dass die Readings nur dann einen Event feuern, wenn diese sich tatsächlich ändern. Der Wert hinter dem Doppelpunkt, gibt die Mindeständerung an. Fehlt dieser, feuert jede Änderung einen Event.<br />
:<code>attr PID.FUBO event-on-change-reading actuation:1,actuationCalc:0.5,delta:0.2,desired,measured:0.2,p_d:0.1,p_i:1.0,p_p:1.0</code><br />
* Events feuern, wenn sich über lange Zeit ein Reading nicht ändert: wenn sich z.B. desired über Stunden nicht ändert, so wird kein einziger Event gefeuert. Mit nachfolgender Einstellung erreicht man, dass ein Event auch dann erzeugt wird, wenn sich das Reading nach einer festgelegten Zeit nicht ändert(sinnvoll für Charts, hier z.B. alle 30 Minuten)<br />
:<code>attr PID.FUBO event-min-interval actuation:1800,actuationCalc:1800,delta:1800,desired:1800,measured:1800,p_d:1800,p_i:1800,p_p:1800</code><br />
<br />
'''Chart einrichten'''<br />
<br />
Es ist für das Einstellen der Regel-Faktoren (P,I,D) überaus hilfreich, das Verhalten über die Zeit aufzuzeichnen, um das Verhalten objektiv beurteilen zu können.<br />
<br />
;Zunächst ein Filelog einrichten<br />
:define PID.FUBO.File FileLog ./log/PID.FUBO-%Y.log PID\.FUBO<br />
:attr PID.FUBO.File logtype text<br />
<br />
Danach ein Chart definieren, angelehnt an folgendes Beispiel:<br />
<br />
[[Datei:13_12_03_PID_ChartDef.png]]<br />
<br />
Anbei ein Vorschlag für au<br />
<br />
== Hintergrund-Informationen ==<br />
=== list <pid-name> ===<br />
<pre><br />
Internals:<br />
DEF DG.BAD.TF PID.Actor:state<br />
NAME PID.PID<br />
NR 616<br />
NTFY_ORDER 50-PID.PID<br />
STATE processing<br />
TYPE PID<br />
Readings:<br />
2013-10-20 17:13:41 actuation 97<br />
2013-10-20 17:21:42 actuationCalc 97.2079999999999<br />
2013-10-20 17:21:42 delta 0.199999999999999<br />
2013-10-20 17:13:41 desired 22<br />
2013-10-20 17:13:41 measured 21.8<br />
2013-10-20 17:21:42 p_d 0<br />
2013-10-20 17:21:42 p_i 92.2079999999999<br />
2013-10-20 17:21:42 p_p 4.99999999999998<br />
2013-10-20 17:21:42 state processing<br />
Helper:<br />
actor PID.Actor<br />
actorCommand state<br />
actorErrorAction freeze<br />
actorErrorPos 0<br />
actorInterval 300<br />
actorKeepAlive 1800<br />
actorLimitLower 0<br />
actorLimitUpper 100<br />
actorThreshold 4<br />
actorTimestamp 2013-10-20 17:13:41<br />
actorValueDecPlaces 0<br />
calcInterval 60<br />
deltaGradient 0<br />
deltaOld 0.199999999999999<br />
deltaOldTS 2013-10-20 17:18:07<br />
deltaTreshold 0<br />
desiredName desired<br />
disable 0<br />
factor_D 0<br />
factor_I 0.25<br />
factor_P 25<br />
isWindUP 0<br />
measuredName measured<br />
reading temperature<br />
regexp ([\d\.]*)<br />
reverseAction 0<br />
sensor DG.BAD.TF<br />
sensorTimeout 3600<br />
updateInterval 600<br />
Attributes:<br />
pidActorInterval 300<br />
pidActorTreshold 4<br />
pidActorValueDecPlaces 0<br />
room PID<br />
verbose 4<br />
</pre><br />
<br />
=== Anti-WindUp-Strategie ===<br />
Der integrale Anteil des PID-Reglers wird ohne Gegenmassnahmen auch dann weiter integriert, wenn das Stellglied bereits an seine Grenzen gestossen ist. Dies hat den Nachteil, dass nach einer Reduzierung der Regeldifferenz lange Wartezeiten entstehen können, bis das Stellglied reagiert. Dies nennt man den WindUP-Effekt. Hierzu wurde die folgende Strategie entwickelt:<br />
<br />
[[Datei:13 10 20 PID Windup.png|WindUP]]<br />
<br />
Sobald das rechnerische Stellsignal (Ventilstellung Calc=actuationCalc) die obere Grenze des Stellgliedes überschreitet (pidActorLimitUpper) oder die untere Grenze unterschreitet (pidActorLimitLower), wird die Integration des I-Anteils eingefroren.<br />
<br />
'''Am Beispiel:'''<br />
<br />
An Position L1 überschreitet der rechnerische Ausgabewert des Stellgliedes die obere Grenze (100%). Der I-Anteil verändert sich nicht mehr bis zur Position L2. Hier unterschreitet der Ausgabewert die obere Grenze, der I-Anteil kann wieder verändert werden.<br />
<br />
== Fragen und Antworten ==<br />
=== Wie kann ich den I-Anteil (p_i) im Regler auf 0 setzen ? ===<br />
Dies ist nach folgender Anweisung möglich:<br />
<br />
<pre>set <Pid-Name> restart <p_p + p_d></pre><br />
<br />
=== Temperatur im Raum steigt nicht oder stark verzögert, was kann ich tun? ===<br />
<br />
==== 1. Fehlerquelle: Heizsystem ist nicht ausreichend entlüftet ====<br />
In diesem Fall behindern die Luftblasen im System den Durchfluss des Heizmediums.<br />
<br />
Der Heizkörper erwärmt sich nur teilweise oder "gluckert". Hier ist das Entlüften der Heizkörper angesagt.<br />
<br />
Natürlich können sich die Gasblasen an anderer Stelle befinden. Normalerweise sorgen automatische Entlüfter dafür, dass das Gas entweichen kann.<br />
<br />
Aber auch diese "verkalken" im Lauf der Zeit.<br />
<br />
==== 2. Fehlerquelle: Totzone beim Stellglied ====<br />
Der Temperaturanstieg erfolgt erst ab einer bestimmten Ventilöffnung von xy%.<br />
<br />
Der PID-Regler geht davon aus, dass jede Änderung des Stellausgangs auf die Regelgröße wirkt (also bei Ventil weiter öffnen, wird mehr Wärme abgegeben).<br />
<br />
Ist dies nicht der Fall, wird der PID über die Zeit (I-Anteil) das Ventil weiter öffnen. Allerdings vergeht hierbei Zeit und damit leidet die Regelgüte.<br />
<br />
Es ist also wichtig die Totzone zu ermitteln und im Attribut pidActorLimitLower zu hinterlegen.<br />
<br />
==== 3. Fehlerquelle: Hydraulische Fehlanpassung ====<br />
Wenn einzelne Heizkreise einen sehr kleinen hydraulischen Widerstand aufweisen, kann es passieren, dass Heizkreise mit höherem Widerstand zeitweise unterversorgt sind.<br />
<br />
Erst wenn die gut versorgten Heizkreise die Ventile schließen (Soll-Temperatur ist erreicht), werden die Heizkreise mit hohem Widerstand ausreichend versorgt.<br />
<br />
Dies kann man dank FHEM sehr gut über die Charts nachvollziehen.<br />
<br />
Es ist regelungstechnisch, ökologisch und energetisch absolut sinnvoll geregelte Hocheffizienz-Pumpen im Heizkreis einzusetzen. Diese sorgen für konstanten Druck im Hauptstrang bei sehr geringen Energiebedarf.<br />
<br />
Man kann gezielt den hydraulischen Widerstand einzelner Thermostate erhöhen, indem man deren maximale Ventilöffnung begrenzt.<br />
<br />
Dies erreicht man durch Reduzieren des Wertes pidActorLimitUpper. Dies ist gleichbedeutend mit der Erhöhung des hydraulischen Widerstandes durch voreinstellbare Heizungsventile beim hydraulischen Abgleich.<br />
<br />
== Weblinks ==<br />
* [http://forum.fhem.de/index.php/topic,15060.0.html Initialer Forumseintrag zur Überarbeitung des PID-Moduls]<br />
* [http://de.wikipedia.org/wiki/Regler Wikipedia Regler]<br />
<br />
[[Kategorie:Glossary]]<br />
[[Kategorie:Regelungstechnik]]</div>Johnhttp://wiki.fhem.de/w/index.php?title=MAX!_Temperatur-Scanner&diff=13534MAX! Temperatur-Scanner2016-01-10T13:42:19Z<p>John: /* Was ist denn, wenn ich noch einen zweiten Fensterkontakt habe? */</p>
<hr />
<div>Der '''MAX! Temperatur-Scanner''' ist ein Perl-Skript, das die kontinuierliche Temperatur-Aufzeichnung<br />
von MAX-Thermostaten ermöglicht. <br />
<br />
== Features ==<br />
* kontinuierliche Erfassung von Temperatur und Ventil-Position <br />
* Berücksichtigung der System-Ressourcen (dutycycle, credits)<br />
* CUL und CUBE werden unterstützt<br />
* gleichberechtigte zeitliche Bearbeitung der Thermostate (Round-Robin-Prinzip)<br />
* Ermittlung der optimalen Scan-Rate über die Anzahl der eingebundenen Thermostate<br />
* 2 Scan-Modi stehen zur Verfügung (DesiredChange + ModeChange)<br />
<br />
== Zielsetzung des WIKI-Artikels ==<br />
Hier werden Fragen und Erkenntnisse zum Thema dargestellt, da der Forums-Eintrag für viele Anwender nicht mehr überschaubar ist.<br />
<br />
Der Artikel wird sukzessive erweitert.<br />
<br />
== Voraussetzungen ==<br />
==== Qualität der Funkverbindung ====<br />
In der Log-Datei sollten möglichst wenig Einträge der nachfolgenden Form auftreten<br />
<pre>2013.11.01 02:12:33 2: CUL_MAX_SendQueueHandler: Missing ack from 0905a5 for 0b0b0040123456xxxxxxxxx</pre><br />
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.<br />
<br />
==== Ausreichend Credits ====<br />
Der Scanner kann nicht aktiv werden, wenn gehäuft Log-Einträge der nachfolgenden Form auftreten.<br />
<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><br />
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.<br />
<br />
==== Einrichten des Thermostat-internen Wochenprogrammes ====<br />
<br />
Die Readings Wochenprogrammes 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.<br />
<br />
'''Bitte folgendes beachten:'''<br />
<br />
Es gibt im Zusammenhang mit dem Wochenprogramm ein Problem mit dem letzten Schaltpunkt des Tages. <br />
Der Workaround wurde [http://forum.fhem.de/index.php/topic,17231.msg112738.html#msg112738 hier]<br />
beschrieben.<br />
<br />
<big>Man muss dafür sorgen, dass man kurz vor Ende des Tages noch einen Schaltpunkt setzt.</big><br />
<br />
== Mechanismen ==<br />
=== Das Problem ===<br />
Der Hersteller der MAX-Thermostate hat diese so konzipiert, dass die gemessene Temperatur und Ventilstellung nur übertragen werden, wenn sich Folgendes ändert:<br />
* die Ventilstellung<br />
* die Betriebsart (mode: auto,manu,temporary,boost)<br />
* der Sollwert<br />
<br />
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.<br />
<br />
=== Der Lösungsansatz ===<br />
==== Triggerung per Mode-Umschaltung (ModeChange) ====<br />
Dies ist der Default-Mode des Scanners.<br />
Hier wird der Ansatz verfolgt, die Betriebsart des Thermostats regelmässig umzuschalten via<br />
:AUTO ==> MANU<br />
<Wartezeit mindestens 3 Minuten><br />
:MANU ==> AUTO<br />
<br />
Dies veranlasst das Thermostat, regelmässig die gewünschten Werte an FHEM (den gepaarten Transceiver) zu senden.<br />
<br />
==== Triggerung per Sollwert-Umschaltung (DesiredChange) ====<br />
Durch Änderung des Sollwertes kann ebenso die Übertragung des Istwertes am Thermostat initiiert werden.<br />
<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.<br />
<br />
Dieser Modus wird durch die Definition des UserReadings "onlyAutoMode" festgelegt.<br />
:<code>attr HT.JOHN userReadings onlyAutoMode { return "1";;}</code><br />
<br />
'''Beispiel:'''<br />
<br />
Sollwert im Thermostat nach Wochenprofil: 18<br />
Fall A:<br />
----<br />
* Istwert 17<br />
* Sollwert A von Scanner gesetzt : 18.5<br />
* Sollwert B von Scanner gesetzt : 18.0<br />
* Der Scanner wechselt also von 18 auf 18.5 und zurück.<br />
<br />
Fall B:<br />
----<br />
* Istwert 19<br />
* Sollwert A von Scanner gesetzt : 17.5<br />
* Sollwert B von Scanner gesetzt : 18.0<br />
* Der Scanner wechselt also von 18 auf 17.5 und zurück.<br />
<br />
=== Ergebnis ===<br />
==== ohne Scanner ====<br />
[[Datei:2013_12_MaxScanner_Vorher.png|ohne Scanner]]<br />
<br />
==== mit Scanner (ScanMode=ModeChange) ====<br />
[[Datei:13_12_01_Scanner_ModeChange.png|mit Scanner]]<br />
<br />
==== mit Scanner (ScanMode=DesiredChange) ====<br />
[[Datei:13_12_01_Scanner_DesiredChange.png|mit Scanner]]<br />
<br />
=== Ressourcen ===<br />
Die Sendezeit jedes Teilnehmers ist auf 1% begrenzt.<br />
<br />
Konkret bedeutet dies, dass ein CUL ca. 33 Telegramme pro Stunde senden kann.<br />
Der MAX-Scanner darf nicht alle Ressourcen für sich beanspruchen, sondern sieht seine Aufgabe als nachrangig. <br />
<br />
Erst wenn mehr als 300 Credits (von max. 900 möglichen) zur Verfügung stehen, wird das Skript aktiv.<br />
<br />
== Fragen und Antworten ==<br />
=== Welchen ScanMode soll ich wählen? ===<br />
Nachfolgende Punkte können als Entscheidungskriterium dienen:<br />
<br />
'''ModeChange'''<br />
* keine Änderung des Sollwertes nötig<br />
* damit ist das Ventil "ruhiger", da sich die Regeldifferenz nicht durch den Scanner-Betrieb ändert.<br />
<br />
'''DesiredChange'''<br />
* der Auto-Modus wird niemals verlassen<br />
* Falls FHEM ausfällt, wird das Thermostat das gespeicherte Wochenprogramm nutzen<br />
<br />
=== Was passiert, wenn der Sollwert am Thermostat manuell verstellt wird? ===<br />
Wenn der Sollwert manuell am Thermostat verändert wird, kann es bis zu 3 Minuten dauern, bis dieser an FHEM gemeldet wird.<br />
<br />
Wenn der Scanner in dieser Wartezeit aktiv wird, wird er den soeben geänderten Sollwert überschreiben. In diesem Fall bliebe die manuelle Änderung wirkungslos.<br />
<br />
Wird die manuelle Änderung des Sollwertes vom Scanner erkannt, so gilt dieser bis zum nächsten Schaltpunkt des internen Wochenprogrammes.<br />
<br />
=== Mehrere Thermostate in einer Gruppe? ===<br />
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.<br />
<br />
=== Was ist zu tun wenn, Thermostate zusammen mit einem Wandthermostat eingesetzt werden? ===<br />
In diesem Fall ist der Scanner überflüssig, da das Wandthermostat ohnehin eine detaillierte Kurve des Istwertes liefert.<br />
<br />
=== Sind Fensterkontakte sinnvoll? ===<br />
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 <br />
[http://www.elv.de/topic/tuer-fensterkontakt-sinn-und-unsinn.html Sinn und Unsinn von Fensterkontakten] zeigt.<br />
<br />
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. <br />
<br />
[[Datei:2013_11_02_Scanner_TSturz.png|Sturz-Temperatur-Erkennung]]<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 vermutlich mit einer WindowOpenDuration von 0 behoben werden, ausserdem ist im Hochsommer die Heizung ohnehin ausgeschaltet.<br />
<br />
Folgende Nachteile haben die Max-Fensterkontakte:<br />
* 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.<br />
* 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).<br />
<br />
=== Berücksichtigt der Scanner die Temperatur-Sturz-Erkennung? ===<br />
Wenn desiredTemperature=WindowsOpenTemperature, dann stellt der Scanner seine Arbeit ein. Ansonsten würde er durch aktive Modeumschaltung die WindowsOpenTemperature dauerhaft setzen.<br />
<br />
=== Kann der Scanner mit Fensterkontakten umgehen? ===<br />
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.<br />
<br />
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.<br />
<br />
=== Was passiert, wenn der Boost-Mode aktiviert wurde? ===<br />
Sobald dies der Scanner erkennt, stellt er seine Aktivität ein, bis wieder der Modus Auto oder Manu erscheint.<br />
<br />
=== Unterstützt der Scanner auch den MAX-ECO-Taster? ===<br />
Nein.<br />
<br />
=== Beeinflusst der Scanner den Regelmechanismus des Thermostats? ===<br />
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.<br />
<br />
== Die Modul-Variante ==<br />
<br />
Die Modul-Variante ist seit dem 10.01.2016 Bestandteil von FHEM.<br />
<br />
=== Voraussetzungen ===<br />
* ggf. vorhandene Script-Variante sollte deaktiviert werden (99_UtilsMaxScan löschen/verschieben)<br />
<br />
=== Inbetriebnahme ===<br />
* Scanner Modul definieren<br />
<pre><br />
define Scanner MaxScanner<br />
attr Scanner verbose 1<br />
</pre><br />
<br />
* die bestehende Max-Thermostate verfügen nun automatisch über neue Attribute, die den Scanner betreffen<br />
* die meisten Scanner-spezfischen Attribute beginnen immer mit "scn"<br />
* im folgende Beispiel wird das Thermostat HT.JOHN betrachtet:<br />
<pre><br />
define HT.JOHN MAX HeatingThermostat 066666<br />
</pre><br />
* das Thermostat wird für den Scanner freigegeben<br />
<pre>attr HT.JOHN scanTemp 1</pre><br />
* wir wählen die Betriebsart Mode-Change<br />
<pre>attr HT.JOHN scnProcessByDesiChange 0</pre><br />
* wir können 0..n ShutterContacts definieren, getrennt durch Komma<br />
<pre>attr HT.JOHN scnShutterList SHUTTER.JOHN,SHUTTER.BRENNER</pre><br />
* verbose liefert ausführliche Infos im Logger<br />
<pre>attr HT.JOHN verbose 4</pre><br />
<br />
=== Attribute Thermostat===<br />
{| class="wikitable sortable"<br />
|-<br />
! Parameter !! Wertebereich !! Default !! Beschreibung<br />
|-<br />
|scanTemp||[0,1]||0||wenn 1, wird das Thermostat vom Scanner berücksichtigt<br />
|-<br />
|scnProcessByDesiChange||[0,1]||0||wenn 1, wird das Thermostat über die Änderung von desiredTemperature (DesiredChange) getriggert, ansonsten über die Änderung des Modes (ModeChange)<br />
|-<br />
|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<br />
Thermostat geschrieben wird. Ist hingegen NOCHANGE gewählt, so wird der aktuelle am Thermostat angewählte Mode belassen.<br />
|-<br />
|scnShutterList||||||Liste von assoziierten Max-Fensterkontakten (ShutterContacts), die durch ein Komma getrennt werden. <br />
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.<br />
<br />
|}<br />
=== Attribute Scanner===<br />
{| class="wikitable sortable"<br />
|-<br />
! Parameter !! Wertebereich !! Default !! Beschreibung<br />
|-<br />
|disable||[0,1]||0|| wenn 1, dann wird der Scanner gesperrt und ist somit inaktiv.<br />
|-<br />
|scnCreditThreshold||[150..600]||300|| die Mindestanzahl von verfügbaren Credits, ab der der Scanner mit dem Triggern der Thermostate beginnt<br />
|-<br />
|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.<br />
|-<br />
|}<br />
<br />
=== Background ===<br />
<br />
==== Hilfe zur Diagnose der Abläufe ====<br />
Ein wichtiges Hilfsmittel ist der Event-Monitor. Mit der Filter-Einstellung "MAX.*" werden nur noch die MAX-relevanten Events dargestellt.<br />
<br />
Interpretation der Ausgabe:<br/><br />
<pre><br />
2016-01-06 21:24:43 MAX HT.BAD desiredTemperature auto 20.0 <-- Triggern des Thermostats durch Scanner<br />
<br />
2016-01-06 21:24:50 MAX HT.BAD mode: auto --> Rückmeldung vom Thermostat<br />
2016-01-06 21:24:50 MAX HT.BAD RSSI: -54 --> Rückmeldung vom Thermostat<br />
2016-01-06 21:24:56 MAX HT.BAD temperature: 20.2 --> Rückmeldung vom Thermostat<br />
</pre><br />
<br />
Hier erscheinen also die zu Thermostat gesendeten Informationen ebenso, wie die empfangenen.<br />
Empfangene Informationen sind meist mit einem ":" gekennzeichnet.<br />
<br />
[[Kategorie:MAX]]</div>Johnhttp://wiki.fhem.de/w/index.php?title=MAX!_Temperatur-Scanner&diff=13533MAX! Temperatur-Scanner2016-01-10T13:41:56Z<p>John: /* Kann der Scanner mit Fensterkontakten umgehen? */</p>
<hr />
<div>Der '''MAX! Temperatur-Scanner''' ist ein Perl-Skript, das die kontinuierliche Temperatur-Aufzeichnung<br />
von MAX-Thermostaten ermöglicht. <br />
<br />
== Features ==<br />
* kontinuierliche Erfassung von Temperatur und Ventil-Position <br />
* Berücksichtigung der System-Ressourcen (dutycycle, credits)<br />
* CUL und CUBE werden unterstützt<br />
* gleichberechtigte zeitliche Bearbeitung der Thermostate (Round-Robin-Prinzip)<br />
* Ermittlung der optimalen Scan-Rate über die Anzahl der eingebundenen Thermostate<br />
* 2 Scan-Modi stehen zur Verfügung (DesiredChange + ModeChange)<br />
<br />
== Zielsetzung des WIKI-Artikels ==<br />
Hier werden Fragen und Erkenntnisse zum Thema dargestellt, da der Forums-Eintrag für viele Anwender nicht mehr überschaubar ist.<br />
<br />
Der Artikel wird sukzessive erweitert.<br />
<br />
== Voraussetzungen ==<br />
==== Qualität der Funkverbindung ====<br />
In der Log-Datei sollten möglichst wenig Einträge der nachfolgenden Form auftreten<br />
<pre>2013.11.01 02:12:33 2: CUL_MAX_SendQueueHandler: Missing ack from 0905a5 for 0b0b0040123456xxxxxxxxx</pre><br />
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.<br />
<br />
==== Ausreichend Credits ====<br />
Der Scanner kann nicht aktiv werden, wenn gehäuft Log-Einträge der nachfolgenden Form auftreten.<br />
<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><br />
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.<br />
<br />
==== Einrichten des Thermostat-internen Wochenprogrammes ====<br />
<br />
Die Readings Wochenprogrammes 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.<br />
<br />
'''Bitte folgendes beachten:'''<br />
<br />
Es gibt im Zusammenhang mit dem Wochenprogramm ein Problem mit dem letzten Schaltpunkt des Tages. <br />
Der Workaround wurde [http://forum.fhem.de/index.php/topic,17231.msg112738.html#msg112738 hier]<br />
beschrieben.<br />
<br />
<big>Man muss dafür sorgen, dass man kurz vor Ende des Tages noch einen Schaltpunkt setzt.</big><br />
<br />
== Mechanismen ==<br />
=== Das Problem ===<br />
Der Hersteller der MAX-Thermostate hat diese so konzipiert, dass die gemessene Temperatur und Ventilstellung nur übertragen werden, wenn sich Folgendes ändert:<br />
* die Ventilstellung<br />
* die Betriebsart (mode: auto,manu,temporary,boost)<br />
* der Sollwert<br />
<br />
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.<br />
<br />
=== Der Lösungsansatz ===<br />
==== Triggerung per Mode-Umschaltung (ModeChange) ====<br />
Dies ist der Default-Mode des Scanners.<br />
Hier wird der Ansatz verfolgt, die Betriebsart des Thermostats regelmässig umzuschalten via<br />
:AUTO ==> MANU<br />
<Wartezeit mindestens 3 Minuten><br />
:MANU ==> AUTO<br />
<br />
Dies veranlasst das Thermostat, regelmässig die gewünschten Werte an FHEM (den gepaarten Transceiver) zu senden.<br />
<br />
==== Triggerung per Sollwert-Umschaltung (DesiredChange) ====<br />
Durch Änderung des Sollwertes kann ebenso die Übertragung des Istwertes am Thermostat initiiert werden.<br />
<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.<br />
<br />
Dieser Modus wird durch die Definition des UserReadings "onlyAutoMode" festgelegt.<br />
:<code>attr HT.JOHN userReadings onlyAutoMode { return "1";;}</code><br />
<br />
'''Beispiel:'''<br />
<br />
Sollwert im Thermostat nach Wochenprofil: 18<br />
Fall A:<br />
----<br />
* Istwert 17<br />
* Sollwert A von Scanner gesetzt : 18.5<br />
* Sollwert B von Scanner gesetzt : 18.0<br />
* Der Scanner wechselt also von 18 auf 18.5 und zurück.<br />
<br />
Fall B:<br />
----<br />
* Istwert 19<br />
* Sollwert A von Scanner gesetzt : 17.5<br />
* Sollwert B von Scanner gesetzt : 18.0<br />
* Der Scanner wechselt also von 18 auf 17.5 und zurück.<br />
<br />
=== Ergebnis ===<br />
==== ohne Scanner ====<br />
[[Datei:2013_12_MaxScanner_Vorher.png|ohne Scanner]]<br />
<br />
==== mit Scanner (ScanMode=ModeChange) ====<br />
[[Datei:13_12_01_Scanner_ModeChange.png|mit Scanner]]<br />
<br />
==== mit Scanner (ScanMode=DesiredChange) ====<br />
[[Datei:13_12_01_Scanner_DesiredChange.png|mit Scanner]]<br />
<br />
=== Ressourcen ===<br />
Die Sendezeit jedes Teilnehmers ist auf 1% begrenzt.<br />
<br />
Konkret bedeutet dies, dass ein CUL ca. 33 Telegramme pro Stunde senden kann.<br />
Der MAX-Scanner darf nicht alle Ressourcen für sich beanspruchen, sondern sieht seine Aufgabe als nachrangig. <br />
<br />
Erst wenn mehr als 300 Credits (von max. 900 möglichen) zur Verfügung stehen, wird das Skript aktiv.<br />
<br />
== Fragen und Antworten ==<br />
=== Welchen ScanMode soll ich wählen? ===<br />
Nachfolgende Punkte können als Entscheidungskriterium dienen:<br />
<br />
'''ModeChange'''<br />
* keine Änderung des Sollwertes nötig<br />
* damit ist das Ventil "ruhiger", da sich die Regeldifferenz nicht durch den Scanner-Betrieb ändert.<br />
<br />
'''DesiredChange'''<br />
* der Auto-Modus wird niemals verlassen<br />
* Falls FHEM ausfällt, wird das Thermostat das gespeicherte Wochenprogramm nutzen<br />
<br />
=== Was passiert, wenn der Sollwert am Thermostat manuell verstellt wird? ===<br />
Wenn der Sollwert manuell am Thermostat verändert wird, kann es bis zu 3 Minuten dauern, bis dieser an FHEM gemeldet wird.<br />
<br />
Wenn der Scanner in dieser Wartezeit aktiv wird, wird er den soeben geänderten Sollwert überschreiben. In diesem Fall bliebe die manuelle Änderung wirkungslos.<br />
<br />
Wird die manuelle Änderung des Sollwertes vom Scanner erkannt, so gilt dieser bis zum nächsten Schaltpunkt des internen Wochenprogrammes.<br />
<br />
=== Mehrere Thermostate in einer Gruppe? ===<br />
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.<br />
<br />
=== Was ist zu tun wenn, Thermostate zusammen mit einem Wandthermostat eingesetzt werden? ===<br />
In diesem Fall ist der Scanner überflüssig, da das Wandthermostat ohnehin eine detaillierte Kurve des Istwertes liefert.<br />
<br />
=== Sind Fensterkontakte sinnvoll? ===<br />
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 <br />
[http://www.elv.de/topic/tuer-fensterkontakt-sinn-und-unsinn.html Sinn und Unsinn von Fensterkontakten] zeigt.<br />
<br />
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. <br />
<br />
[[Datei:2013_11_02_Scanner_TSturz.png|Sturz-Temperatur-Erkennung]]<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 vermutlich mit einer WindowOpenDuration von 0 behoben werden, ausserdem ist im Hochsommer die Heizung ohnehin ausgeschaltet.<br />
<br />
Folgende Nachteile haben die Max-Fensterkontakte:<br />
* 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.<br />
* 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).<br />
<br />
=== Berücksichtigt der Scanner die Temperatur-Sturz-Erkennung? ===<br />
Wenn desiredTemperature=WindowsOpenTemperature, dann stellt der Scanner seine Arbeit ein. Ansonsten würde er durch aktive Modeumschaltung die WindowsOpenTemperature dauerhaft setzen.<br />
<br />
=== Kann der Scanner mit Fensterkontakten umgehen? ===<br />
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.<br />
<br />
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.<br />
<br />
=== Was ist denn, wenn ich noch einen zweiten Fensterkontakt habe? ===<br />
Derzeit wird nur 1 ShutterContact unterstützt. Möglicherweise wird in einer der nächsten Versionen die Funktionalität erweitert.<br />
<br />
=== Was passiert, wenn der Boost-Mode aktiviert wurde? ===<br />
Sobald dies der Scanner erkennt, stellt er seine Aktivität ein, bis wieder der Modus Auto oder Manu erscheint.<br />
<br />
=== Unterstützt der Scanner auch den MAX-ECO-Taster? ===<br />
Nein.<br />
<br />
=== Beeinflusst der Scanner den Regelmechanismus des Thermostats? ===<br />
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.<br />
<br />
== Die Modul-Variante ==<br />
<br />
Die Modul-Variante ist seit dem 10.01.2016 Bestandteil von FHEM.<br />
<br />
=== Voraussetzungen ===<br />
* ggf. vorhandene Script-Variante sollte deaktiviert werden (99_UtilsMaxScan löschen/verschieben)<br />
<br />
=== Inbetriebnahme ===<br />
* Scanner Modul definieren<br />
<pre><br />
define Scanner MaxScanner<br />
attr Scanner verbose 1<br />
</pre><br />
<br />
* die bestehende Max-Thermostate verfügen nun automatisch über neue Attribute, die den Scanner betreffen<br />
* die meisten Scanner-spezfischen Attribute beginnen immer mit "scn"<br />
* im folgende Beispiel wird das Thermostat HT.JOHN betrachtet:<br />
<pre><br />
define HT.JOHN MAX HeatingThermostat 066666<br />
</pre><br />
* das Thermostat wird für den Scanner freigegeben<br />
<pre>attr HT.JOHN scanTemp 1</pre><br />
* wir wählen die Betriebsart Mode-Change<br />
<pre>attr HT.JOHN scnProcessByDesiChange 0</pre><br />
* wir können 0..n ShutterContacts definieren, getrennt durch Komma<br />
<pre>attr HT.JOHN scnShutterList SHUTTER.JOHN,SHUTTER.BRENNER</pre><br />
* verbose liefert ausführliche Infos im Logger<br />
<pre>attr HT.JOHN verbose 4</pre><br />
<br />
=== Attribute Thermostat===<br />
{| class="wikitable sortable"<br />
|-<br />
! Parameter !! Wertebereich !! Default !! Beschreibung<br />
|-<br />
|scanTemp||[0,1]||0||wenn 1, wird das Thermostat vom Scanner berücksichtigt<br />
|-<br />
|scnProcessByDesiChange||[0,1]||0||wenn 1, wird das Thermostat über die Änderung von desiredTemperature (DesiredChange) getriggert, ansonsten über die Änderung des Modes (ModeChange)<br />
|-<br />
|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<br />
Thermostat geschrieben wird. Ist hingegen NOCHANGE gewählt, so wird der aktuelle am Thermostat angewählte Mode belassen.<br />
|-<br />
|scnShutterList||||||Liste von assoziierten Max-Fensterkontakten (ShutterContacts), die durch ein Komma getrennt werden. <br />
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.<br />
<br />
|}<br />
=== Attribute Scanner===<br />
{| class="wikitable sortable"<br />
|-<br />
! Parameter !! Wertebereich !! Default !! Beschreibung<br />
|-<br />
|disable||[0,1]||0|| wenn 1, dann wird der Scanner gesperrt und ist somit inaktiv.<br />
|-<br />
|scnCreditThreshold||[150..600]||300|| die Mindestanzahl von verfügbaren Credits, ab der der Scanner mit dem Triggern der Thermostate beginnt<br />
|-<br />
|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.<br />
|-<br />
|}<br />
<br />
=== Background ===<br />
<br />
==== Hilfe zur Diagnose der Abläufe ====<br />
Ein wichtiges Hilfsmittel ist der Event-Monitor. Mit der Filter-Einstellung "MAX.*" werden nur noch die MAX-relevanten Events dargestellt.<br />
<br />
Interpretation der Ausgabe:<br/><br />
<pre><br />
2016-01-06 21:24:43 MAX HT.BAD desiredTemperature auto 20.0 <-- Triggern des Thermostats durch Scanner<br />
<br />
2016-01-06 21:24:50 MAX HT.BAD mode: auto --> Rückmeldung vom Thermostat<br />
2016-01-06 21:24:50 MAX HT.BAD RSSI: -54 --> Rückmeldung vom Thermostat<br />
2016-01-06 21:24:56 MAX HT.BAD temperature: 20.2 --> Rückmeldung vom Thermostat<br />
</pre><br />
<br />
Hier erscheinen also die zu Thermostat gesendeten Informationen ebenso, wie die empfangenen.<br />
Empfangene Informationen sind meist mit einem ":" gekennzeichnet.<br />
<br />
[[Kategorie:MAX]]</div>Johnhttp://wiki.fhem.de/w/index.php?title=MAX!_Temperatur-Scanner&diff=13532MAX! Temperatur-Scanner2016-01-10T13:40:20Z<p>John: /* Wie kann man den ScanMode nachträglich ändern? */</p>
<hr />
<div>Der '''MAX! Temperatur-Scanner''' ist ein Perl-Skript, das die kontinuierliche Temperatur-Aufzeichnung<br />
von MAX-Thermostaten ermöglicht. <br />
<br />
== Features ==<br />
* kontinuierliche Erfassung von Temperatur und Ventil-Position <br />
* Berücksichtigung der System-Ressourcen (dutycycle, credits)<br />
* CUL und CUBE werden unterstützt<br />
* gleichberechtigte zeitliche Bearbeitung der Thermostate (Round-Robin-Prinzip)<br />
* Ermittlung der optimalen Scan-Rate über die Anzahl der eingebundenen Thermostate<br />
* 2 Scan-Modi stehen zur Verfügung (DesiredChange + ModeChange)<br />
<br />
== Zielsetzung des WIKI-Artikels ==<br />
Hier werden Fragen und Erkenntnisse zum Thema dargestellt, da der Forums-Eintrag für viele Anwender nicht mehr überschaubar ist.<br />
<br />
Der Artikel wird sukzessive erweitert.<br />
<br />
== Voraussetzungen ==<br />
==== Qualität der Funkverbindung ====<br />
In der Log-Datei sollten möglichst wenig Einträge der nachfolgenden Form auftreten<br />
<pre>2013.11.01 02:12:33 2: CUL_MAX_SendQueueHandler: Missing ack from 0905a5 for 0b0b0040123456xxxxxxxxx</pre><br />
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.<br />
<br />
==== Ausreichend Credits ====<br />
Der Scanner kann nicht aktiv werden, wenn gehäuft Log-Einträge der nachfolgenden Form auftreten.<br />
<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><br />
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.<br />
<br />
==== Einrichten des Thermostat-internen Wochenprogrammes ====<br />
<br />
Die Readings Wochenprogrammes 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.<br />
<br />
'''Bitte folgendes beachten:'''<br />
<br />
Es gibt im Zusammenhang mit dem Wochenprogramm ein Problem mit dem letzten Schaltpunkt des Tages. <br />
Der Workaround wurde [http://forum.fhem.de/index.php/topic,17231.msg112738.html#msg112738 hier]<br />
beschrieben.<br />
<br />
<big>Man muss dafür sorgen, dass man kurz vor Ende des Tages noch einen Schaltpunkt setzt.</big><br />
<br />
== Mechanismen ==<br />
=== Das Problem ===<br />
Der Hersteller der MAX-Thermostate hat diese so konzipiert, dass die gemessene Temperatur und Ventilstellung nur übertragen werden, wenn sich Folgendes ändert:<br />
* die Ventilstellung<br />
* die Betriebsart (mode: auto,manu,temporary,boost)<br />
* der Sollwert<br />
<br />
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.<br />
<br />
=== Der Lösungsansatz ===<br />
==== Triggerung per Mode-Umschaltung (ModeChange) ====<br />
Dies ist der Default-Mode des Scanners.<br />
Hier wird der Ansatz verfolgt, die Betriebsart des Thermostats regelmässig umzuschalten via<br />
:AUTO ==> MANU<br />
<Wartezeit mindestens 3 Minuten><br />
:MANU ==> AUTO<br />
<br />
Dies veranlasst das Thermostat, regelmässig die gewünschten Werte an FHEM (den gepaarten Transceiver) zu senden.<br />
<br />
==== Triggerung per Sollwert-Umschaltung (DesiredChange) ====<br />
Durch Änderung des Sollwertes kann ebenso die Übertragung des Istwertes am Thermostat initiiert werden.<br />
<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.<br />
<br />
Dieser Modus wird durch die Definition des UserReadings "onlyAutoMode" festgelegt.<br />
:<code>attr HT.JOHN userReadings onlyAutoMode { return "1";;}</code><br />
<br />
'''Beispiel:'''<br />
<br />
Sollwert im Thermostat nach Wochenprofil: 18<br />
Fall A:<br />
----<br />
* Istwert 17<br />
* Sollwert A von Scanner gesetzt : 18.5<br />
* Sollwert B von Scanner gesetzt : 18.0<br />
* Der Scanner wechselt also von 18 auf 18.5 und zurück.<br />
<br />
Fall B:<br />
----<br />
* Istwert 19<br />
* Sollwert A von Scanner gesetzt : 17.5<br />
* Sollwert B von Scanner gesetzt : 18.0<br />
* Der Scanner wechselt also von 18 auf 17.5 und zurück.<br />
<br />
=== Ergebnis ===<br />
==== ohne Scanner ====<br />
[[Datei:2013_12_MaxScanner_Vorher.png|ohne Scanner]]<br />
<br />
==== mit Scanner (ScanMode=ModeChange) ====<br />
[[Datei:13_12_01_Scanner_ModeChange.png|mit Scanner]]<br />
<br />
==== mit Scanner (ScanMode=DesiredChange) ====<br />
[[Datei:13_12_01_Scanner_DesiredChange.png|mit Scanner]]<br />
<br />
=== Ressourcen ===<br />
Die Sendezeit jedes Teilnehmers ist auf 1% begrenzt.<br />
<br />
Konkret bedeutet dies, dass ein CUL ca. 33 Telegramme pro Stunde senden kann.<br />
Der MAX-Scanner darf nicht alle Ressourcen für sich beanspruchen, sondern sieht seine Aufgabe als nachrangig. <br />
<br />
Erst wenn mehr als 300 Credits (von max. 900 möglichen) zur Verfügung stehen, wird das Skript aktiv.<br />
<br />
== Fragen und Antworten ==<br />
=== Welchen ScanMode soll ich wählen? ===<br />
Nachfolgende Punkte können als Entscheidungskriterium dienen:<br />
<br />
'''ModeChange'''<br />
* keine Änderung des Sollwertes nötig<br />
* damit ist das Ventil "ruhiger", da sich die Regeldifferenz nicht durch den Scanner-Betrieb ändert.<br />
<br />
'''DesiredChange'''<br />
* der Auto-Modus wird niemals verlassen<br />
* Falls FHEM ausfällt, wird das Thermostat das gespeicherte Wochenprogramm nutzen<br />
<br />
=== Was passiert, wenn der Sollwert am Thermostat manuell verstellt wird? ===<br />
Wenn der Sollwert manuell am Thermostat verändert wird, kann es bis zu 3 Minuten dauern, bis dieser an FHEM gemeldet wird.<br />
<br />
Wenn der Scanner in dieser Wartezeit aktiv wird, wird er den soeben geänderten Sollwert überschreiben. In diesem Fall bliebe die manuelle Änderung wirkungslos.<br />
<br />
Wird die manuelle Änderung des Sollwertes vom Scanner erkannt, so gilt dieser bis zum nächsten Schaltpunkt des internen Wochenprogrammes.<br />
<br />
=== Mehrere Thermostate in einer Gruppe? ===<br />
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.<br />
<br />
=== Was ist zu tun wenn, Thermostate zusammen mit einem Wandthermostat eingesetzt werden? ===<br />
In diesem Fall ist der Scanner überflüssig, da das Wandthermostat ohnehin eine detaillierte Kurve des Istwertes liefert.<br />
<br />
=== Sind Fensterkontakte sinnvoll? ===<br />
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 <br />
[http://www.elv.de/topic/tuer-fensterkontakt-sinn-und-unsinn.html Sinn und Unsinn von Fensterkontakten] zeigt.<br />
<br />
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. <br />
<br />
[[Datei:2013_11_02_Scanner_TSturz.png|Sturz-Temperatur-Erkennung]]<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 vermutlich mit einer WindowOpenDuration von 0 behoben werden, ausserdem ist im Hochsommer die Heizung ohnehin ausgeschaltet.<br />
<br />
Folgende Nachteile haben die Max-Fensterkontakte:<br />
* 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.<br />
* 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).<br />
<br />
=== Berücksichtigt der Scanner die Temperatur-Sturz-Erkennung? ===<br />
Wenn desiredTemperature=WindowsOpenTemperature, dann stellt der Scanner seine Arbeit ein. Ansonsten würde er durch aktive Modeumschaltung die WindowsOpenTemperature dauerhaft setzen.<br />
<br />
=== Kann der Scanner mit Fensterkontakten umgehen? ===<br />
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.<br />
<br />
Ausserdem wäre es fatal, wenn der Scanner in der Phase des offenen Fenster den Sollwert überschreiben würde. Bei offenem Fenster ist der Scanner inaktiv, er schaltet also den Modus nicht mehr um.<br />
<br />
=== Was ist denn, wenn ich noch einen zweiten Fensterkontakt habe? ===<br />
Derzeit wird nur 1 ShutterContact unterstützt. Möglicherweise wird in einer der nächsten Versionen die Funktionalität erweitert.<br />
<br />
=== Was passiert, wenn der Boost-Mode aktiviert wurde? ===<br />
Sobald dies der Scanner erkennt, stellt er seine Aktivität ein, bis wieder der Modus Auto oder Manu erscheint.<br />
<br />
=== Unterstützt der Scanner auch den MAX-ECO-Taster? ===<br />
Nein.<br />
<br />
=== Beeinflusst der Scanner den Regelmechanismus des Thermostats? ===<br />
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.<br />
<br />
== Die Modul-Variante ==<br />
<br />
Die Modul-Variante ist seit dem 10.01.2016 Bestandteil von FHEM.<br />
<br />
=== Voraussetzungen ===<br />
* ggf. vorhandene Script-Variante sollte deaktiviert werden (99_UtilsMaxScan löschen/verschieben)<br />
<br />
=== Inbetriebnahme ===<br />
* Scanner Modul definieren<br />
<pre><br />
define Scanner MaxScanner<br />
attr Scanner verbose 1<br />
</pre><br />
<br />
* die bestehende Max-Thermostate verfügen nun automatisch über neue Attribute, die den Scanner betreffen<br />
* die meisten Scanner-spezfischen Attribute beginnen immer mit "scn"<br />
* im folgende Beispiel wird das Thermostat HT.JOHN betrachtet:<br />
<pre><br />
define HT.JOHN MAX HeatingThermostat 066666<br />
</pre><br />
* das Thermostat wird für den Scanner freigegeben<br />
<pre>attr HT.JOHN scanTemp 1</pre><br />
* wir wählen die Betriebsart Mode-Change<br />
<pre>attr HT.JOHN scnProcessByDesiChange 0</pre><br />
* wir können 0..n ShutterContacts definieren, getrennt durch Komma<br />
<pre>attr HT.JOHN scnShutterList SHUTTER.JOHN,SHUTTER.BRENNER</pre><br />
* verbose liefert ausführliche Infos im Logger<br />
<pre>attr HT.JOHN verbose 4</pre><br />
<br />
=== Attribute Thermostat===<br />
{| class="wikitable sortable"<br />
|-<br />
! Parameter !! Wertebereich !! Default !! Beschreibung<br />
|-<br />
|scanTemp||[0,1]||0||wenn 1, wird das Thermostat vom Scanner berücksichtigt<br />
|-<br />
|scnProcessByDesiChange||[0,1]||0||wenn 1, wird das Thermostat über die Änderung von desiredTemperature (DesiredChange) getriggert, ansonsten über die Änderung des Modes (ModeChange)<br />
|-<br />
|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<br />
Thermostat geschrieben wird. Ist hingegen NOCHANGE gewählt, so wird der aktuelle am Thermostat angewählte Mode belassen.<br />
|-<br />
|scnShutterList||||||Liste von assoziierten Max-Fensterkontakten (ShutterContacts), die durch ein Komma getrennt werden. <br />
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.<br />
<br />
|}<br />
=== Attribute Scanner===<br />
{| class="wikitable sortable"<br />
|-<br />
! Parameter !! Wertebereich !! Default !! Beschreibung<br />
|-<br />
|disable||[0,1]||0|| wenn 1, dann wird der Scanner gesperrt und ist somit inaktiv.<br />
|-<br />
|scnCreditThreshold||[150..600]||300|| die Mindestanzahl von verfügbaren Credits, ab der der Scanner mit dem Triggern der Thermostate beginnt<br />
|-<br />
|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.<br />
|-<br />
|}<br />
<br />
=== Background ===<br />
<br />
==== Hilfe zur Diagnose der Abläufe ====<br />
Ein wichtiges Hilfsmittel ist der Event-Monitor. Mit der Filter-Einstellung "MAX.*" werden nur noch die MAX-relevanten Events dargestellt.<br />
<br />
Interpretation der Ausgabe:<br/><br />
<pre><br />
2016-01-06 21:24:43 MAX HT.BAD desiredTemperature auto 20.0 <-- Triggern des Thermostats durch Scanner<br />
<br />
2016-01-06 21:24:50 MAX HT.BAD mode: auto --> Rückmeldung vom Thermostat<br />
2016-01-06 21:24:50 MAX HT.BAD RSSI: -54 --> Rückmeldung vom Thermostat<br />
2016-01-06 21:24:56 MAX HT.BAD temperature: 20.2 --> Rückmeldung vom Thermostat<br />
</pre><br />
<br />
Hier erscheinen also die zu Thermostat gesendeten Informationen ebenso, wie die empfangenen.<br />
Empfangene Informationen sind meist mit einem ":" gekennzeichnet.<br />
<br />
[[Kategorie:MAX]]</div>Johnhttp://wiki.fhem.de/w/index.php?title=MAX!_Temperatur-Scanner&diff=13531MAX! Temperatur-Scanner2016-01-10T13:39:31Z<p>John: /* Aktuelle Version */</p>
<hr />
<div>Der '''MAX! Temperatur-Scanner''' ist ein Perl-Skript, das die kontinuierliche Temperatur-Aufzeichnung<br />
von MAX-Thermostaten ermöglicht. <br />
<br />
== Features ==<br />
* kontinuierliche Erfassung von Temperatur und Ventil-Position <br />
* Berücksichtigung der System-Ressourcen (dutycycle, credits)<br />
* CUL und CUBE werden unterstützt<br />
* gleichberechtigte zeitliche Bearbeitung der Thermostate (Round-Robin-Prinzip)<br />
* Ermittlung der optimalen Scan-Rate über die Anzahl der eingebundenen Thermostate<br />
* 2 Scan-Modi stehen zur Verfügung (DesiredChange + ModeChange)<br />
<br />
== Zielsetzung des WIKI-Artikels ==<br />
Hier werden Fragen und Erkenntnisse zum Thema dargestellt, da der Forums-Eintrag für viele Anwender nicht mehr überschaubar ist.<br />
<br />
Der Artikel wird sukzessive erweitert.<br />
<br />
== Voraussetzungen ==<br />
==== Qualität der Funkverbindung ====<br />
In der Log-Datei sollten möglichst wenig Einträge der nachfolgenden Form auftreten<br />
<pre>2013.11.01 02:12:33 2: CUL_MAX_SendQueueHandler: Missing ack from 0905a5 for 0b0b0040123456xxxxxxxxx</pre><br />
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.<br />
<br />
==== Ausreichend Credits ====<br />
Der Scanner kann nicht aktiv werden, wenn gehäuft Log-Einträge der nachfolgenden Form auftreten.<br />
<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><br />
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.<br />
<br />
==== Einrichten des Thermostat-internen Wochenprogrammes ====<br />
<br />
Die Readings Wochenprogrammes 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.<br />
<br />
'''Bitte folgendes beachten:'''<br />
<br />
Es gibt im Zusammenhang mit dem Wochenprogramm ein Problem mit dem letzten Schaltpunkt des Tages. <br />
Der Workaround wurde [http://forum.fhem.de/index.php/topic,17231.msg112738.html#msg112738 hier]<br />
beschrieben.<br />
<br />
<big>Man muss dafür sorgen, dass man kurz vor Ende des Tages noch einen Schaltpunkt setzt.</big><br />
<br />
== Mechanismen ==<br />
=== Das Problem ===<br />
Der Hersteller der MAX-Thermostate hat diese so konzipiert, dass die gemessene Temperatur und Ventilstellung nur übertragen werden, wenn sich Folgendes ändert:<br />
* die Ventilstellung<br />
* die Betriebsart (mode: auto,manu,temporary,boost)<br />
* der Sollwert<br />
<br />
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.<br />
<br />
=== Der Lösungsansatz ===<br />
==== Triggerung per Mode-Umschaltung (ModeChange) ====<br />
Dies ist der Default-Mode des Scanners.<br />
Hier wird der Ansatz verfolgt, die Betriebsart des Thermostats regelmässig umzuschalten via<br />
:AUTO ==> MANU<br />
<Wartezeit mindestens 3 Minuten><br />
:MANU ==> AUTO<br />
<br />
Dies veranlasst das Thermostat, regelmässig die gewünschten Werte an FHEM (den gepaarten Transceiver) zu senden.<br />
<br />
==== Triggerung per Sollwert-Umschaltung (DesiredChange) ====<br />
Durch Änderung des Sollwertes kann ebenso die Übertragung des Istwertes am Thermostat initiiert werden.<br />
<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.<br />
<br />
Dieser Modus wird durch die Definition des UserReadings "onlyAutoMode" festgelegt.<br />
:<code>attr HT.JOHN userReadings onlyAutoMode { return "1";;}</code><br />
<br />
'''Beispiel:'''<br />
<br />
Sollwert im Thermostat nach Wochenprofil: 18<br />
Fall A:<br />
----<br />
* Istwert 17<br />
* Sollwert A von Scanner gesetzt : 18.5<br />
* Sollwert B von Scanner gesetzt : 18.0<br />
* Der Scanner wechselt also von 18 auf 18.5 und zurück.<br />
<br />
Fall B:<br />
----<br />
* Istwert 19<br />
* Sollwert A von Scanner gesetzt : 17.5<br />
* Sollwert B von Scanner gesetzt : 18.0<br />
* Der Scanner wechselt also von 18 auf 17.5 und zurück.<br />
<br />
=== Ergebnis ===<br />
==== ohne Scanner ====<br />
[[Datei:2013_12_MaxScanner_Vorher.png|ohne Scanner]]<br />
<br />
==== mit Scanner (ScanMode=ModeChange) ====<br />
[[Datei:13_12_01_Scanner_ModeChange.png|mit Scanner]]<br />
<br />
==== mit Scanner (ScanMode=DesiredChange) ====<br />
[[Datei:13_12_01_Scanner_DesiredChange.png|mit Scanner]]<br />
<br />
=== Ressourcen ===<br />
Die Sendezeit jedes Teilnehmers ist auf 1% begrenzt.<br />
<br />
Konkret bedeutet dies, dass ein CUL ca. 33 Telegramme pro Stunde senden kann.<br />
Der MAX-Scanner darf nicht alle Ressourcen für sich beanspruchen, sondern sieht seine Aufgabe als nachrangig. <br />
<br />
Erst wenn mehr als 300 Credits (von max. 900 möglichen) zur Verfügung stehen, wird das Skript aktiv.<br />
<br />
== Fragen und Antworten ==<br />
=== Welchen ScanMode soll ich wählen? ===<br />
Nachfolgende Punkte können als Entscheidungskriterium dienen:<br />
<br />
'''ModeChange'''<br />
* keine Änderung des Sollwertes nötig<br />
* damit ist das Ventil "ruhiger", da sich die Regeldifferenz nicht durch den Scanner-Betrieb ändert.<br />
<br />
'''DesiredChange'''<br />
* der Auto-Modus wird niemals verlassen<br />
* Falls FHEM ausfällt, wird das Thermostat das gespeicherte Wochenprogramm nutzen<br />
<br />
=== Wie kann man den ScanMode nachträglich ändern? ===<br />
Man kann das userReading ändern, so dass es 0 liefert<br />
:<code>attr HT.JOHN userReadings onlyAutoMode { return "0";;}</code><br />
<br />
oder man löscht das userReading durch<br />
* Löschen aus dem attribut userReading<br />
* und Löschen des vorhandenen userReadings via<br />
:<code>deletereading HT.JOHN onlyAutoMode </code><br />
<br />
=== Was passiert, wenn der Sollwert am Thermostat manuell verstellt wird? ===<br />
Wenn der Sollwert manuell am Thermostat verändert wird, kann es bis zu 3 Minuten dauern, bis dieser an FHEM gemeldet wird.<br />
<br />
Wenn der Scanner in dieser Wartezeit aktiv wird, wird er den soeben geänderten Sollwert überschreiben. In diesem Fall bliebe die manuelle Änderung wirkungslos.<br />
<br />
Wird die manuelle Änderung des Sollwertes vom Scanner erkannt, so gilt dieser bis zum nächsten Schaltpunkt des internen Wochenprogrammes.<br />
<br />
=== Mehrere Thermostate in einer Gruppe? ===<br />
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.<br />
<br />
=== Was ist zu tun wenn, Thermostate zusammen mit einem Wandthermostat eingesetzt werden? ===<br />
In diesem Fall ist der Scanner überflüssig, da das Wandthermostat ohnehin eine detaillierte Kurve des Istwertes liefert.<br />
<br />
=== Sind Fensterkontakte sinnvoll? ===<br />
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 <br />
[http://www.elv.de/topic/tuer-fensterkontakt-sinn-und-unsinn.html Sinn und Unsinn von Fensterkontakten] zeigt.<br />
<br />
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. <br />
<br />
[[Datei:2013_11_02_Scanner_TSturz.png|Sturz-Temperatur-Erkennung]]<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 vermutlich mit einer WindowOpenDuration von 0 behoben werden, ausserdem ist im Hochsommer die Heizung ohnehin ausgeschaltet.<br />
<br />
Folgende Nachteile haben die Max-Fensterkontakte:<br />
* 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.<br />
* 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).<br />
<br />
=== Berücksichtigt der Scanner die Temperatur-Sturz-Erkennung? ===<br />
Wenn desiredTemperature=WindowsOpenTemperature, dann stellt der Scanner seine Arbeit ein. Ansonsten würde er durch aktive Modeumschaltung die WindowsOpenTemperature dauerhaft setzen.<br />
<br />
=== Kann der Scanner mit Fensterkontakten umgehen? ===<br />
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.<br />
<br />
Ausserdem wäre es fatal, wenn der Scanner in der Phase des offenen Fenster den Sollwert überschreiben würde. Bei offenem Fenster ist der Scanner inaktiv, er schaltet also den Modus nicht mehr um.<br />
<br />
=== Was ist denn, wenn ich noch einen zweiten Fensterkontakt habe? ===<br />
Derzeit wird nur 1 ShutterContact unterstützt. Möglicherweise wird in einer der nächsten Versionen die Funktionalität erweitert.<br />
<br />
=== Was passiert, wenn der Boost-Mode aktiviert wurde? ===<br />
Sobald dies der Scanner erkennt, stellt er seine Aktivität ein, bis wieder der Modus Auto oder Manu erscheint.<br />
<br />
=== Unterstützt der Scanner auch den MAX-ECO-Taster? ===<br />
Nein.<br />
<br />
=== Beeinflusst der Scanner den Regelmechanismus des Thermostats? ===<br />
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.<br />
<br />
== Die Modul-Variante ==<br />
<br />
Die Modul-Variante ist seit dem 10.01.2016 Bestandteil von FHEM.<br />
<br />
=== Voraussetzungen ===<br />
* ggf. vorhandene Script-Variante sollte deaktiviert werden (99_UtilsMaxScan löschen/verschieben)<br />
<br />
=== Inbetriebnahme ===<br />
* Scanner Modul definieren<br />
<pre><br />
define Scanner MaxScanner<br />
attr Scanner verbose 1<br />
</pre><br />
<br />
* die bestehende Max-Thermostate verfügen nun automatisch über neue Attribute, die den Scanner betreffen<br />
* die meisten Scanner-spezfischen Attribute beginnen immer mit "scn"<br />
* im folgende Beispiel wird das Thermostat HT.JOHN betrachtet:<br />
<pre><br />
define HT.JOHN MAX HeatingThermostat 066666<br />
</pre><br />
* das Thermostat wird für den Scanner freigegeben<br />
<pre>attr HT.JOHN scanTemp 1</pre><br />
* wir wählen die Betriebsart Mode-Change<br />
<pre>attr HT.JOHN scnProcessByDesiChange 0</pre><br />
* wir können 0..n ShutterContacts definieren, getrennt durch Komma<br />
<pre>attr HT.JOHN scnShutterList SHUTTER.JOHN,SHUTTER.BRENNER</pre><br />
* verbose liefert ausführliche Infos im Logger<br />
<pre>attr HT.JOHN verbose 4</pre><br />
<br />
=== Attribute Thermostat===<br />
{| class="wikitable sortable"<br />
|-<br />
! Parameter !! Wertebereich !! Default !! Beschreibung<br />
|-<br />
|scanTemp||[0,1]||0||wenn 1, wird das Thermostat vom Scanner berücksichtigt<br />
|-<br />
|scnProcessByDesiChange||[0,1]||0||wenn 1, wird das Thermostat über die Änderung von desiredTemperature (DesiredChange) getriggert, ansonsten über die Änderung des Modes (ModeChange)<br />
|-<br />
|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<br />
Thermostat geschrieben wird. Ist hingegen NOCHANGE gewählt, so wird der aktuelle am Thermostat angewählte Mode belassen.<br />
|-<br />
|scnShutterList||||||Liste von assoziierten Max-Fensterkontakten (ShutterContacts), die durch ein Komma getrennt werden. <br />
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.<br />
<br />
|}<br />
=== Attribute Scanner===<br />
{| class="wikitable sortable"<br />
|-<br />
! Parameter !! Wertebereich !! Default !! Beschreibung<br />
|-<br />
|disable||[0,1]||0|| wenn 1, dann wird der Scanner gesperrt und ist somit inaktiv.<br />
|-<br />
|scnCreditThreshold||[150..600]||300|| die Mindestanzahl von verfügbaren Credits, ab der der Scanner mit dem Triggern der Thermostate beginnt<br />
|-<br />
|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.<br />
|-<br />
|}<br />
<br />
=== Background ===<br />
<br />
==== Hilfe zur Diagnose der Abläufe ====<br />
Ein wichtiges Hilfsmittel ist der Event-Monitor. Mit der Filter-Einstellung "MAX.*" werden nur noch die MAX-relevanten Events dargestellt.<br />
<br />
Interpretation der Ausgabe:<br/><br />
<pre><br />
2016-01-06 21:24:43 MAX HT.BAD desiredTemperature auto 20.0 <-- Triggern des Thermostats durch Scanner<br />
<br />
2016-01-06 21:24:50 MAX HT.BAD mode: auto --> Rückmeldung vom Thermostat<br />
2016-01-06 21:24:50 MAX HT.BAD RSSI: -54 --> Rückmeldung vom Thermostat<br />
2016-01-06 21:24:56 MAX HT.BAD temperature: 20.2 --> Rückmeldung vom Thermostat<br />
</pre><br />
<br />
Hier erscheinen also die zu Thermostat gesendeten Informationen ebenso, wie die empfangenen.<br />
Empfangene Informationen sind meist mit einem ":" gekennzeichnet.<br />
<br />
[[Kategorie:MAX]]</div>Johnhttp://wiki.fhem.de/w/index.php?title=MAX!_Temperatur-Scanner&diff=13530MAX! Temperatur-Scanner2016-01-10T13:38:30Z<p>John: /* Aktuelle Version */</p>
<hr />
<div>Der '''MAX! Temperatur-Scanner''' ist ein Perl-Skript, das die kontinuierliche Temperatur-Aufzeichnung<br />
von MAX-Thermostaten ermöglicht. <br />
<br />
== Features ==<br />
* kontinuierliche Erfassung von Temperatur und Ventil-Position <br />
* Berücksichtigung der System-Ressourcen (dutycycle, credits)<br />
* CUL und CUBE werden unterstützt<br />
* gleichberechtigte zeitliche Bearbeitung der Thermostate (Round-Robin-Prinzip)<br />
* Ermittlung der optimalen Scan-Rate über die Anzahl der eingebundenen Thermostate<br />
* 2 Scan-Modi stehen zur Verfügung (DesiredChange + ModeChange)<br />
<br />
== Zielsetzung des WIKI-Artikels ==<br />
Hier werden Fragen und Erkenntnisse zum Thema dargestellt, da der Forums-Eintrag für viele Anwender nicht mehr überschaubar ist.<br />
<br />
Der Artikel wird sukzessive erweitert.<br />
<br />
== Aktuelle Version ==<br />
=== Voraussetzungen ===<br />
==== Qualität der Funkverbindung ====<br />
In der Log-Datei sollten möglichst wenig Einträge der nachfolgenden Form auftreten<br />
<pre>2013.11.01 02:12:33 2: CUL_MAX_SendQueueHandler: Missing ack from 0905a5 for 0b0b0040123456xxxxxxxxx</pre><br />
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.<br />
<br />
==== Ausreichend Credits ====<br />
Der Scanner kann nicht aktiv werden, wenn gehäuft Log-Einträge der nachfolgenden Form auftreten.<br />
<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><br />
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.<br />
<br />
==== Einrichten des Thermostat-internen Wochenprogrammes ====<br />
<br />
Die Readings Wochenprogrammes 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.<br />
<br />
'''Bitte folgendes beachten:'''<br />
<br />
Es gibt im Zusammenhang mit dem Wochenprogramm ein Problem mit dem letzten Schaltpunkt des Tages. <br />
Der Workaround wurde [http://forum.fhem.de/index.php/topic,17231.msg112738.html#msg112738 hier]<br />
beschrieben.<br />
<br />
<big>Man muss dafür sorgen, dass man kurz vor Ende des Tages noch einen Schaltpunkt setzt.</big><br />
<br />
== Mechanismen ==<br />
=== Das Problem ===<br />
Der Hersteller der MAX-Thermostate hat diese so konzipiert, dass die gemessene Temperatur und Ventilstellung nur übertragen werden, wenn sich Folgendes ändert:<br />
* die Ventilstellung<br />
* die Betriebsart (mode: auto,manu,temporary,boost)<br />
* der Sollwert<br />
<br />
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.<br />
<br />
=== Der Lösungsansatz ===<br />
==== Triggerung per Mode-Umschaltung (ModeChange) ====<br />
Dies ist der Default-Mode des Scanners.<br />
Hier wird der Ansatz verfolgt, die Betriebsart des Thermostats regelmässig umzuschalten via<br />
:AUTO ==> MANU<br />
<Wartezeit mindestens 3 Minuten><br />
:MANU ==> AUTO<br />
<br />
Dies veranlasst das Thermostat, regelmässig die gewünschten Werte an FHEM (den gepaarten Transceiver) zu senden.<br />
<br />
==== Triggerung per Sollwert-Umschaltung (DesiredChange) ====<br />
Durch Änderung des Sollwertes kann ebenso die Übertragung des Istwertes am Thermostat initiiert werden.<br />
<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.<br />
<br />
Dieser Modus wird durch die Definition des UserReadings "onlyAutoMode" festgelegt.<br />
:<code>attr HT.JOHN userReadings onlyAutoMode { return "1";;}</code><br />
<br />
'''Beispiel:'''<br />
<br />
Sollwert im Thermostat nach Wochenprofil: 18<br />
Fall A:<br />
----<br />
* Istwert 17<br />
* Sollwert A von Scanner gesetzt : 18.5<br />
* Sollwert B von Scanner gesetzt : 18.0<br />
* Der Scanner wechselt also von 18 auf 18.5 und zurück.<br />
<br />
Fall B:<br />
----<br />
* Istwert 19<br />
* Sollwert A von Scanner gesetzt : 17.5<br />
* Sollwert B von Scanner gesetzt : 18.0<br />
* Der Scanner wechselt also von 18 auf 17.5 und zurück.<br />
<br />
=== Ergebnis ===<br />
==== ohne Scanner ====<br />
[[Datei:2013_12_MaxScanner_Vorher.png|ohne Scanner]]<br />
<br />
==== mit Scanner (ScanMode=ModeChange) ====<br />
[[Datei:13_12_01_Scanner_ModeChange.png|mit Scanner]]<br />
<br />
==== mit Scanner (ScanMode=DesiredChange) ====<br />
[[Datei:13_12_01_Scanner_DesiredChange.png|mit Scanner]]<br />
<br />
=== Ressourcen ===<br />
Die Sendezeit jedes Teilnehmers ist auf 1% begrenzt.<br />
<br />
Konkret bedeutet dies, dass ein CUL ca. 33 Telegramme pro Stunde senden kann.<br />
Der MAX-Scanner darf nicht alle Ressourcen für sich beanspruchen, sondern sieht seine Aufgabe als nachrangig. <br />
<br />
Erst wenn mehr als 300 Credits (von max. 900 möglichen) zur Verfügung stehen, wird das Skript aktiv.<br />
<br />
== Fragen und Antworten ==<br />
=== Welchen ScanMode soll ich wählen? ===<br />
Nachfolgende Punkte können als Entscheidungskriterium dienen:<br />
<br />
'''ModeChange'''<br />
* keine Änderung des Sollwertes nötig<br />
* damit ist das Ventil "ruhiger", da sich die Regeldifferenz nicht durch den Scanner-Betrieb ändert.<br />
<br />
'''DesiredChange'''<br />
* der Auto-Modus wird niemals verlassen<br />
* Falls FHEM ausfällt, wird das Thermostat das gespeicherte Wochenprogramm nutzen<br />
<br />
=== Wie kann man den ScanMode nachträglich ändern? ===<br />
Man kann das userReading ändern, so dass es 0 liefert<br />
:<code>attr HT.JOHN userReadings onlyAutoMode { return "0";;}</code><br />
<br />
oder man löscht das userReading durch<br />
* Löschen aus dem attribut userReading<br />
* und Löschen des vorhandenen userReadings via<br />
:<code>deletereading HT.JOHN onlyAutoMode </code><br />
<br />
=== Was passiert, wenn der Sollwert am Thermostat manuell verstellt wird? ===<br />
Wenn der Sollwert manuell am Thermostat verändert wird, kann es bis zu 3 Minuten dauern, bis dieser an FHEM gemeldet wird.<br />
<br />
Wenn der Scanner in dieser Wartezeit aktiv wird, wird er den soeben geänderten Sollwert überschreiben. In diesem Fall bliebe die manuelle Änderung wirkungslos.<br />
<br />
Wird die manuelle Änderung des Sollwertes vom Scanner erkannt, so gilt dieser bis zum nächsten Schaltpunkt des internen Wochenprogrammes.<br />
<br />
=== Mehrere Thermostate in einer Gruppe? ===<br />
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.<br />
<br />
=== Was ist zu tun wenn, Thermostate zusammen mit einem Wandthermostat eingesetzt werden? ===<br />
In diesem Fall ist der Scanner überflüssig, da das Wandthermostat ohnehin eine detaillierte Kurve des Istwertes liefert.<br />
<br />
=== Sind Fensterkontakte sinnvoll? ===<br />
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 <br />
[http://www.elv.de/topic/tuer-fensterkontakt-sinn-und-unsinn.html Sinn und Unsinn von Fensterkontakten] zeigt.<br />
<br />
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. <br />
<br />
[[Datei:2013_11_02_Scanner_TSturz.png|Sturz-Temperatur-Erkennung]]<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 vermutlich mit einer WindowOpenDuration von 0 behoben werden, ausserdem ist im Hochsommer die Heizung ohnehin ausgeschaltet.<br />
<br />
Folgende Nachteile haben die Max-Fensterkontakte:<br />
* 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.<br />
* 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).<br />
<br />
=== Berücksichtigt der Scanner die Temperatur-Sturz-Erkennung? ===<br />
Wenn desiredTemperature=WindowsOpenTemperature, dann stellt der Scanner seine Arbeit ein. Ansonsten würde er durch aktive Modeumschaltung die WindowsOpenTemperature dauerhaft setzen.<br />
<br />
=== Kann der Scanner mit Fensterkontakten umgehen? ===<br />
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.<br />
<br />
Ausserdem wäre es fatal, wenn der Scanner in der Phase des offenen Fenster den Sollwert überschreiben würde. Bei offenem Fenster ist der Scanner inaktiv, er schaltet also den Modus nicht mehr um.<br />
<br />
=== Was ist denn, wenn ich noch einen zweiten Fensterkontakt habe? ===<br />
Derzeit wird nur 1 ShutterContact unterstützt. Möglicherweise wird in einer der nächsten Versionen die Funktionalität erweitert.<br />
<br />
=== Was passiert, wenn der Boost-Mode aktiviert wurde? ===<br />
Sobald dies der Scanner erkennt, stellt er seine Aktivität ein, bis wieder der Modus Auto oder Manu erscheint.<br />
<br />
=== Unterstützt der Scanner auch den MAX-ECO-Taster? ===<br />
Nein.<br />
<br />
=== Beeinflusst der Scanner den Regelmechanismus des Thermostats? ===<br />
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.<br />
<br />
== Die Modul-Variante ==<br />
<br />
Die Modul-Variante ist seit dem 10.01.2016 Bestandteil von FHEM.<br />
<br />
=== Voraussetzungen ===<br />
* ggf. vorhandene Script-Variante sollte deaktiviert werden (99_UtilsMaxScan löschen/verschieben)<br />
<br />
=== Inbetriebnahme ===<br />
* Scanner Modul definieren<br />
<pre><br />
define Scanner MaxScanner<br />
attr Scanner verbose 1<br />
</pre><br />
<br />
* die bestehende Max-Thermostate verfügen nun automatisch über neue Attribute, die den Scanner betreffen<br />
* die meisten Scanner-spezfischen Attribute beginnen immer mit "scn"<br />
* im folgende Beispiel wird das Thermostat HT.JOHN betrachtet:<br />
<pre><br />
define HT.JOHN MAX HeatingThermostat 066666<br />
</pre><br />
* das Thermostat wird für den Scanner freigegeben<br />
<pre>attr HT.JOHN scanTemp 1</pre><br />
* wir wählen die Betriebsart Mode-Change<br />
<pre>attr HT.JOHN scnProcessByDesiChange 0</pre><br />
* wir können 0..n ShutterContacts definieren, getrennt durch Komma<br />
<pre>attr HT.JOHN scnShutterList SHUTTER.JOHN,SHUTTER.BRENNER</pre><br />
* verbose liefert ausführliche Infos im Logger<br />
<pre>attr HT.JOHN verbose 4</pre><br />
<br />
=== Attribute Thermostat===<br />
{| class="wikitable sortable"<br />
|-<br />
! Parameter !! Wertebereich !! Default !! Beschreibung<br />
|-<br />
|scanTemp||[0,1]||0||wenn 1, wird das Thermostat vom Scanner berücksichtigt<br />
|-<br />
|scnProcessByDesiChange||[0,1]||0||wenn 1, wird das Thermostat über die Änderung von desiredTemperature (DesiredChange) getriggert, ansonsten über die Änderung des Modes (ModeChange)<br />
|-<br />
|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<br />
Thermostat geschrieben wird. Ist hingegen NOCHANGE gewählt, so wird der aktuelle am Thermostat angewählte Mode belassen.<br />
|-<br />
|scnShutterList||||||Liste von assoziierten Max-Fensterkontakten (ShutterContacts), die durch ein Komma getrennt werden. <br />
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.<br />
<br />
|}<br />
=== Attribute Scanner===<br />
{| class="wikitable sortable"<br />
|-<br />
! Parameter !! Wertebereich !! Default !! Beschreibung<br />
|-<br />
|disable||[0,1]||0|| wenn 1, dann wird der Scanner gesperrt und ist somit inaktiv.<br />
|-<br />
|scnCreditThreshold||[150..600]||300|| die Mindestanzahl von verfügbaren Credits, ab der der Scanner mit dem Triggern der Thermostate beginnt<br />
|-<br />
|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.<br />
|-<br />
|}<br />
<br />
=== Background ===<br />
<br />
==== Hilfe zur Diagnose der Abläufe ====<br />
Ein wichtiges Hilfsmittel ist der Event-Monitor. Mit der Filter-Einstellung "MAX.*" werden nur noch die MAX-relevanten Events dargestellt.<br />
<br />
Interpretation der Ausgabe:<br/><br />
<pre><br />
2016-01-06 21:24:43 MAX HT.BAD desiredTemperature auto 20.0 <-- Triggern des Thermostats durch Scanner<br />
<br />
2016-01-06 21:24:50 MAX HT.BAD mode: auto --> Rückmeldung vom Thermostat<br />
2016-01-06 21:24:50 MAX HT.BAD RSSI: -54 --> Rückmeldung vom Thermostat<br />
2016-01-06 21:24:56 MAX HT.BAD temperature: 20.2 --> Rückmeldung vom Thermostat<br />
</pre><br />
<br />
Hier erscheinen also die zu Thermostat gesendeten Informationen ebenso, wie die empfangenen.<br />
Empfangene Informationen sind meist mit einem ":" gekennzeichnet.<br />
<br />
[[Kategorie:MAX]]</div>Johnhttp://wiki.fhem.de/w/index.php?title=MAX!_Temperatur-Scanner&diff=13529MAX! Temperatur-Scanner2016-01-10T13:35:50Z<p>John: /* Im Kochtopf */</p>
<hr />
<div>Der '''MAX! Temperatur-Scanner''' ist ein Perl-Skript, das die kontinuierliche Temperatur-Aufzeichnung<br />
von MAX-Thermostaten ermöglicht. <br />
<br />
== Features ==<br />
* kontinuierliche Erfassung von Temperatur und Ventil-Position <br />
* Berücksichtigung der System-Ressourcen (dutycycle, credits)<br />
* CUL und CUBE werden unterstützt<br />
* gleichberechtigte zeitliche Bearbeitung der Thermostate (Round-Robin-Prinzip)<br />
* Ermittlung der optimalen Scan-Rate über die Anzahl der eingebundenen Thermostate<br />
* 2 Scan-Modi stehen zur Verfügung (DesiredChange + ModeChange)<br />
<br />
== Zielsetzung des WIKI-Artikels ==<br />
Hier werden Fragen und Erkenntnisse zum Thema dargestellt, da der Forums-Eintrag für viele Anwender nicht mehr überschaubar ist.<br />
<br />
Der Artikel wird sukzessive erweitert.<br />
<br />
== Aktuelle Version ==<br />
Im Anhang zu folgendem Forumsbeitrag [http://forum.fhem.de/index.php/topic,11624.msg68237.html#msg68237 MaxScan Version 1.05c]<br />
<br />
=== Voraussetzungen ===<br />
==== Qualität der Funkverbindung ====<br />
In der Log-Datei sollten möglichst wenig Einträge der nachfolgenden Form auftreten<br />
<pre>2013.11.01 02:12:33 2: CUL_MAX_SendQueueHandler: Missing ack from 0905a5 for 0b0b0040123456xxxxxxxxx</pre><br />
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.<br />
<br />
==== Ausreichend Credits ====<br />
Der Scanner kann nicht aktiv werden, wenn gehäuft Log-Einträge der nachfolgenden Form auftreten.<br />
<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><br />
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.<br />
<br />
==== Einrichten des Thermostat-internen Wochenprogrammes ====<br />
Anders als bei den Vorgängerversionen <=1.04 ist nun ab Version 1.05 zwingend das Thermostat-interne<br />
Wochenprogramm notwendig.<br />
<br />
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.<br />
<br />
Das bei früheren Versionen eingesetzte Heating_Control kann somit entfallen.<br />
<br />
'''Bitte folgendes beachten:'''<br />
<br />
Es gibt im Zusammenhang mit dem Wochenprogramm ein Problem mit dem letzten Schaltpunkt des Tages. <br />
Der Workaround wurde [http://forum.fhem.de/index.php/topic,17231.msg112738.html#msg112738 hier]<br />
beschrieben.<br />
<br />
<big>Man muss dafür sorgen, dass man kurz vor Ende des Tages noch einen Schaltpunkt setzt.</big><br />
<br />
=== Inbetriebnahme ===<br />
* aktuell freigegebene Version von 99_UtilsMaxScan.pm in das Verzeichnis /opt/fhem/FHEM kopieren.<br />
* Bei den Thermostaten, die gescannt werden sollen, das Attribut scanTemp setzen via<br />
<pre>attr VT_HW scanTemp 1</pre><br />
* das Wochenprogramm im Thermostat nach den Bedürfnissen einstellen<br />
* auf''' keinen''' Fall das Attribut keepAuto setzen<br />
* mit dem userReading "onlyAutoMode" kann der Scan-Modus ModeChange festgelegt werden<br />
<pre>attr HT.JOHN userReadings onlyAutoMode { return "1";;}</pre> <br />
* ist ein ShutterContact mit dem Thermostat assoziiert, dann muss man dies bekannt machen mit dem UserReading<br />
<pre>attr VT_HW userReadings watchShutter { return "SHUTTER.HW";;}</pre><br />
* '''FHEM neu starten'''<br />
<br />
'''Hinweis'''<br /><br />
Je kleiner der Wert von Attribut verbose, umso weniger Ausgaben erhält man in der Log-Datei.<br />
<br />
== Mechanismen ==<br />
=== Das Problem ===<br />
Der Hersteller der MAX-Thermostate hat diese so konzipiert, dass die gemessene Temperatur und Ventilstellung nur übertragen werden, wenn sich Folgendes ändert:<br />
* die Ventilstellung<br />
* die Betriebsart (mode: auto,manu,temporary,boost)<br />
* der Sollwert<br />
<br />
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.<br />
<br />
=== Der Lösungsansatz ===<br />
==== Triggerung per Mode-Umschaltung (ModeChange) ====<br />
Dies ist der Default-Mode des Scanners.<br />
Hier wird der Ansatz verfolgt, die Betriebsart des Thermostats regelmässig umzuschalten via<br />
:AUTO ==> MANU<br />
<Wartezeit mindestens 3 Minuten><br />
:MANU ==> AUTO<br />
<br />
Dies veranlasst das Thermostat, regelmässig die gewünschten Werte an FHEM (den gepaarten Transceiver) zu senden.<br />
<br />
==== Triggerung per Sollwert-Umschaltung (DesiredChange) ====<br />
Durch Änderung des Sollwertes kann ebenso die Übertragung des Istwertes am Thermostat initiiert werden.<br />
<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.<br />
<br />
Dieser Modus wird durch die Definition des UserReadings "onlyAutoMode" festgelegt.<br />
:<code>attr HT.JOHN userReadings onlyAutoMode { return "1";;}</code><br />
<br />
'''Beispiel:'''<br />
<br />
Sollwert im Thermostat nach Wochenprofil: 18<br />
Fall A:<br />
----<br />
* Istwert 17<br />
* Sollwert A von Scanner gesetzt : 18.5<br />
* Sollwert B von Scanner gesetzt : 18.0<br />
* Der Scanner wechselt also von 18 auf 18.5 und zurück.<br />
<br />
Fall B:<br />
----<br />
* Istwert 19<br />
* Sollwert A von Scanner gesetzt : 17.5<br />
* Sollwert B von Scanner gesetzt : 18.0<br />
* Der Scanner wechselt also von 18 auf 17.5 und zurück.<br />
<br />
=== Ergebnis ===<br />
==== ohne Scanner ====<br />
[[Datei:2013_12_MaxScanner_Vorher.png|ohne Scanner]]<br />
<br />
==== mit Scanner (ScanMode=ModeChange) ====<br />
[[Datei:13_12_01_Scanner_ModeChange.png|mit Scanner]]<br />
<br />
==== mit Scanner (ScanMode=DesiredChange) ====<br />
[[Datei:13_12_01_Scanner_DesiredChange.png|mit Scanner]]<br />
<br />
=== Ressourcen ===<br />
Die Sendezeit jedes Teilnehmers ist auf 1% begrenzt.<br />
<br />
Konkret bedeutet dies, dass ein CUL ca. 33 Telegramme pro Stunde senden kann.<br />
Der MAX-Scanner darf nicht alle Ressourcen für sich beanspruchen, sondern sieht seine Aufgabe als nachrangig. <br />
<br />
Erst wenn mehr als 300 Credits (von max. 900 möglichen) zur Verfügung stehen, wird das Skript aktiv.<br />
<br />
== Fragen und Antworten ==<br />
=== Welchen ScanMode soll ich wählen? ===<br />
Nachfolgende Punkte können als Entscheidungskriterium dienen:<br />
<br />
'''ModeChange'''<br />
* keine Änderung des Sollwertes nötig<br />
* damit ist das Ventil "ruhiger", da sich die Regeldifferenz nicht durch den Scanner-Betrieb ändert.<br />
<br />
'''DesiredChange'''<br />
* der Auto-Modus wird niemals verlassen<br />
* Falls FHEM ausfällt, wird das Thermostat das gespeicherte Wochenprogramm nutzen<br />
<br />
=== Wie kann man den ScanMode nachträglich ändern? ===<br />
Man kann das userReading ändern, so dass es 0 liefert<br />
:<code>attr HT.JOHN userReadings onlyAutoMode { return "0";;}</code><br />
<br />
oder man löscht das userReading durch<br />
* Löschen aus dem attribut userReading<br />
* und Löschen des vorhandenen userReadings via<br />
:<code>deletereading HT.JOHN onlyAutoMode </code><br />
<br />
=== Was passiert, wenn der Sollwert am Thermostat manuell verstellt wird? ===<br />
Wenn der Sollwert manuell am Thermostat verändert wird, kann es bis zu 3 Minuten dauern, bis dieser an FHEM gemeldet wird.<br />
<br />
Wenn der Scanner in dieser Wartezeit aktiv wird, wird er den soeben geänderten Sollwert überschreiben. In diesem Fall bliebe die manuelle Änderung wirkungslos.<br />
<br />
Wird die manuelle Änderung des Sollwertes vom Scanner erkannt, so gilt dieser bis zum nächsten Schaltpunkt des internen Wochenprogrammes.<br />
<br />
=== Mehrere Thermostate in einer Gruppe? ===<br />
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.<br />
<br />
=== Was ist zu tun wenn, Thermostate zusammen mit einem Wandthermostat eingesetzt werden? ===<br />
In diesem Fall ist der Scanner überflüssig, da das Wandthermostat ohnehin eine detaillierte Kurve des Istwertes liefert.<br />
<br />
=== Sind Fensterkontakte sinnvoll? ===<br />
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 <br />
[http://www.elv.de/topic/tuer-fensterkontakt-sinn-und-unsinn.html Sinn und Unsinn von Fensterkontakten] zeigt.<br />
<br />
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. <br />
<br />
[[Datei:2013_11_02_Scanner_TSturz.png|Sturz-Temperatur-Erkennung]]<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 vermutlich mit einer WindowOpenDuration von 0 behoben werden, ausserdem ist im Hochsommer die Heizung ohnehin ausgeschaltet.<br />
<br />
Folgende Nachteile haben die Max-Fensterkontakte:<br />
* 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.<br />
* 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).<br />
<br />
=== Berücksichtigt der Scanner die Temperatur-Sturz-Erkennung? ===<br />
Wenn desiredTemperature=WindowsOpenTemperature, dann stellt der Scanner seine Arbeit ein. Ansonsten würde er durch aktive Modeumschaltung die WindowsOpenTemperature dauerhaft setzen.<br />
<br />
=== Kann der Scanner mit Fensterkontakten umgehen? ===<br />
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.<br />
<br />
Ausserdem wäre es fatal, wenn der Scanner in der Phase des offenen Fenster den Sollwert überschreiben würde. Bei offenem Fenster ist der Scanner inaktiv, er schaltet also den Modus nicht mehr um.<br />
<br />
=== Was ist denn, wenn ich noch einen zweiten Fensterkontakt habe? ===<br />
Derzeit wird nur 1 ShutterContact unterstützt. Möglicherweise wird in einer der nächsten Versionen die Funktionalität erweitert.<br />
<br />
=== Was passiert, wenn der Boost-Mode aktiviert wurde? ===<br />
Sobald dies der Scanner erkennt, stellt er seine Aktivität ein, bis wieder der Modus Auto oder Manu erscheint.<br />
<br />
=== Unterstützt der Scanner auch den MAX-ECO-Taster? ===<br />
Nein.<br />
<br />
=== Beeinflusst der Scanner den Regelmechanismus des Thermostats? ===<br />
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.<br />
<br />
== Die Modul-Variante ==<br />
<br />
Die Modul-Variante ist seit dem 10.01.2016 Bestandteil von FHEM.<br />
<br />
=== Voraussetzungen ===<br />
* ggf. vorhandene Script-Variante sollte deaktiviert werden (99_UtilsMaxScan löschen/verschieben)<br />
<br />
=== Inbetriebnahme ===<br />
* Scanner Modul definieren<br />
<pre><br />
define Scanner MaxScanner<br />
attr Scanner verbose 1<br />
</pre><br />
<br />
* die bestehende Max-Thermostate verfügen nun automatisch über neue Attribute, die den Scanner betreffen<br />
* die meisten Scanner-spezfischen Attribute beginnen immer mit "scn"<br />
* im folgende Beispiel wird das Thermostat HT.JOHN betrachtet:<br />
<pre><br />
define HT.JOHN MAX HeatingThermostat 066666<br />
</pre><br />
* das Thermostat wird für den Scanner freigegeben<br />
<pre>attr HT.JOHN scanTemp 1</pre><br />
* wir wählen die Betriebsart Mode-Change<br />
<pre>attr HT.JOHN scnProcessByDesiChange 0</pre><br />
* wir können 0..n ShutterContacts definieren, getrennt durch Komma<br />
<pre>attr HT.JOHN scnShutterList SHUTTER.JOHN,SHUTTER.BRENNER</pre><br />
* verbose liefert ausführliche Infos im Logger<br />
<pre>attr HT.JOHN verbose 4</pre><br />
<br />
=== Attribute Thermostat===<br />
{| class="wikitable sortable"<br />
|-<br />
! Parameter !! Wertebereich !! Default !! Beschreibung<br />
|-<br />
|scanTemp||[0,1]||0||wenn 1, wird das Thermostat vom Scanner berücksichtigt<br />
|-<br />
|scnProcessByDesiChange||[0,1]||0||wenn 1, wird das Thermostat über die Änderung von desiredTemperature (DesiredChange) getriggert, ansonsten über die Änderung des Modes (ModeChange)<br />
|-<br />
|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<br />
Thermostat geschrieben wird. Ist hingegen NOCHANGE gewählt, so wird der aktuelle am Thermostat angewählte Mode belassen.<br />
|-<br />
|scnShutterList||||||Liste von assoziierten Max-Fensterkontakten (ShutterContacts), die durch ein Komma getrennt werden. <br />
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.<br />
<br />
|}<br />
=== Attribute Scanner===<br />
{| class="wikitable sortable"<br />
|-<br />
! Parameter !! Wertebereich !! Default !! Beschreibung<br />
|-<br />
|disable||[0,1]||0|| wenn 1, dann wird der Scanner gesperrt und ist somit inaktiv.<br />
|-<br />
|scnCreditThreshold||[150..600]||300|| die Mindestanzahl von verfügbaren Credits, ab der der Scanner mit dem Triggern der Thermostate beginnt<br />
|-<br />
|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.<br />
|-<br />
|}<br />
<br />
=== Background ===<br />
<br />
==== Hilfe zur Diagnose der Abläufe ====<br />
Ein wichtiges Hilfsmittel ist der Event-Monitor. Mit der Filter-Einstellung "MAX.*" werden nur noch die MAX-relevanten Events dargestellt.<br />
<br />
Interpretation der Ausgabe:<br/><br />
<pre><br />
2016-01-06 21:24:43 MAX HT.BAD desiredTemperature auto 20.0 <-- Triggern des Thermostats durch Scanner<br />
<br />
2016-01-06 21:24:50 MAX HT.BAD mode: auto --> Rückmeldung vom Thermostat<br />
2016-01-06 21:24:50 MAX HT.BAD RSSI: -54 --> Rückmeldung vom Thermostat<br />
2016-01-06 21:24:56 MAX HT.BAD temperature: 20.2 --> Rückmeldung vom Thermostat<br />
</pre><br />
<br />
Hier erscheinen also die zu Thermostat gesendeten Informationen ebenso, wie die empfangenen.<br />
Empfangene Informationen sind meist mit einem ":" gekennzeichnet.<br />
<br />
[[Kategorie:MAX]]</div>Johnhttp://wiki.fhem.de/w/index.php?title=MAX!_Temperatur-Scanner&diff=13528MAX! Temperatur-Scanner2016-01-10T13:35:15Z<p>John: /* Die Modul-Variante (Beta-Version) */</p>
<hr />
<div>Der '''MAX! Temperatur-Scanner''' ist ein Perl-Skript, das die kontinuierliche Temperatur-Aufzeichnung<br />
von MAX-Thermostaten ermöglicht. <br />
<br />
== Features ==<br />
* kontinuierliche Erfassung von Temperatur und Ventil-Position <br />
* Berücksichtigung der System-Ressourcen (dutycycle, credits)<br />
* CUL und CUBE werden unterstützt<br />
* gleichberechtigte zeitliche Bearbeitung der Thermostate (Round-Robin-Prinzip)<br />
* Ermittlung der optimalen Scan-Rate über die Anzahl der eingebundenen Thermostate<br />
* 2 Scan-Modi stehen zur Verfügung (DesiredChange + ModeChange)<br />
<br />
== Zielsetzung des WIKI-Artikels ==<br />
Hier werden Fragen und Erkenntnisse zum Thema dargestellt, da der Forums-Eintrag für viele Anwender nicht mehr überschaubar ist.<br />
<br />
Der Artikel wird sukzessive erweitert.<br />
<br />
== Aktuelle Version ==<br />
Im Anhang zu folgendem Forumsbeitrag [http://forum.fhem.de/index.php/topic,11624.msg68237.html#msg68237 MaxScan Version 1.05c]<br />
<br />
=== Voraussetzungen ===<br />
==== Qualität der Funkverbindung ====<br />
In der Log-Datei sollten möglichst wenig Einträge der nachfolgenden Form auftreten<br />
<pre>2013.11.01 02:12:33 2: CUL_MAX_SendQueueHandler: Missing ack from 0905a5 for 0b0b0040123456xxxxxxxxx</pre><br />
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.<br />
<br />
==== Ausreichend Credits ====<br />
Der Scanner kann nicht aktiv werden, wenn gehäuft Log-Einträge der nachfolgenden Form auftreten.<br />
<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><br />
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.<br />
<br />
==== Einrichten des Thermostat-internen Wochenprogrammes ====<br />
Anders als bei den Vorgängerversionen <=1.04 ist nun ab Version 1.05 zwingend das Thermostat-interne<br />
Wochenprogramm notwendig.<br />
<br />
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.<br />
<br />
Das bei früheren Versionen eingesetzte Heating_Control kann somit entfallen.<br />
<br />
'''Bitte folgendes beachten:'''<br />
<br />
Es gibt im Zusammenhang mit dem Wochenprogramm ein Problem mit dem letzten Schaltpunkt des Tages. <br />
Der Workaround wurde [http://forum.fhem.de/index.php/topic,17231.msg112738.html#msg112738 hier]<br />
beschrieben.<br />
<br />
<big>Man muss dafür sorgen, dass man kurz vor Ende des Tages noch einen Schaltpunkt setzt.</big><br />
<br />
=== Inbetriebnahme ===<br />
* aktuell freigegebene Version von 99_UtilsMaxScan.pm in das Verzeichnis /opt/fhem/FHEM kopieren.<br />
* Bei den Thermostaten, die gescannt werden sollen, das Attribut scanTemp setzen via<br />
<pre>attr VT_HW scanTemp 1</pre><br />
* das Wochenprogramm im Thermostat nach den Bedürfnissen einstellen<br />
* auf''' keinen''' Fall das Attribut keepAuto setzen<br />
* mit dem userReading "onlyAutoMode" kann der Scan-Modus ModeChange festgelegt werden<br />
<pre>attr HT.JOHN userReadings onlyAutoMode { return "1";;}</pre> <br />
* ist ein ShutterContact mit dem Thermostat assoziiert, dann muss man dies bekannt machen mit dem UserReading<br />
<pre>attr VT_HW userReadings watchShutter { return "SHUTTER.HW";;}</pre><br />
* '''FHEM neu starten'''<br />
<br />
'''Hinweis'''<br /><br />
Je kleiner der Wert von Attribut verbose, umso weniger Ausgaben erhält man in der Log-Datei.<br />
<br />
== Mechanismen ==<br />
=== Das Problem ===<br />
Der Hersteller der MAX-Thermostate hat diese so konzipiert, dass die gemessene Temperatur und Ventilstellung nur übertragen werden, wenn sich Folgendes ändert:<br />
* die Ventilstellung<br />
* die Betriebsart (mode: auto,manu,temporary,boost)<br />
* der Sollwert<br />
<br />
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.<br />
<br />
=== Der Lösungsansatz ===<br />
==== Triggerung per Mode-Umschaltung (ModeChange) ====<br />
Dies ist der Default-Mode des Scanners.<br />
Hier wird der Ansatz verfolgt, die Betriebsart des Thermostats regelmässig umzuschalten via<br />
:AUTO ==> MANU<br />
<Wartezeit mindestens 3 Minuten><br />
:MANU ==> AUTO<br />
<br />
Dies veranlasst das Thermostat, regelmässig die gewünschten Werte an FHEM (den gepaarten Transceiver) zu senden.<br />
<br />
==== Triggerung per Sollwert-Umschaltung (DesiredChange) ====<br />
Durch Änderung des Sollwertes kann ebenso die Übertragung des Istwertes am Thermostat initiiert werden.<br />
<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.<br />
<br />
Dieser Modus wird durch die Definition des UserReadings "onlyAutoMode" festgelegt.<br />
:<code>attr HT.JOHN userReadings onlyAutoMode { return "1";;}</code><br />
<br />
'''Beispiel:'''<br />
<br />
Sollwert im Thermostat nach Wochenprofil: 18<br />
Fall A:<br />
----<br />
* Istwert 17<br />
* Sollwert A von Scanner gesetzt : 18.5<br />
* Sollwert B von Scanner gesetzt : 18.0<br />
* Der Scanner wechselt also von 18 auf 18.5 und zurück.<br />
<br />
Fall B:<br />
----<br />
* Istwert 19<br />
* Sollwert A von Scanner gesetzt : 17.5<br />
* Sollwert B von Scanner gesetzt : 18.0<br />
* Der Scanner wechselt also von 18 auf 17.5 und zurück.<br />
<br />
=== Ergebnis ===<br />
==== ohne Scanner ====<br />
[[Datei:2013_12_MaxScanner_Vorher.png|ohne Scanner]]<br />
<br />
==== mit Scanner (ScanMode=ModeChange) ====<br />
[[Datei:13_12_01_Scanner_ModeChange.png|mit Scanner]]<br />
<br />
==== mit Scanner (ScanMode=DesiredChange) ====<br />
[[Datei:13_12_01_Scanner_DesiredChange.png|mit Scanner]]<br />
<br />
=== Ressourcen ===<br />
Die Sendezeit jedes Teilnehmers ist auf 1% begrenzt.<br />
<br />
Konkret bedeutet dies, dass ein CUL ca. 33 Telegramme pro Stunde senden kann.<br />
Der MAX-Scanner darf nicht alle Ressourcen für sich beanspruchen, sondern sieht seine Aufgabe als nachrangig. <br />
<br />
Erst wenn mehr als 300 Credits (von max. 900 möglichen) zur Verfügung stehen, wird das Skript aktiv.<br />
<br />
== Fragen und Antworten ==<br />
=== Welchen ScanMode soll ich wählen? ===<br />
Nachfolgende Punkte können als Entscheidungskriterium dienen:<br />
<br />
'''ModeChange'''<br />
* keine Änderung des Sollwertes nötig<br />
* damit ist das Ventil "ruhiger", da sich die Regeldifferenz nicht durch den Scanner-Betrieb ändert.<br />
<br />
'''DesiredChange'''<br />
* der Auto-Modus wird niemals verlassen<br />
* Falls FHEM ausfällt, wird das Thermostat das gespeicherte Wochenprogramm nutzen<br />
<br />
=== Wie kann man den ScanMode nachträglich ändern? ===<br />
Man kann das userReading ändern, so dass es 0 liefert<br />
:<code>attr HT.JOHN userReadings onlyAutoMode { return "0";;}</code><br />
<br />
oder man löscht das userReading durch<br />
* Löschen aus dem attribut userReading<br />
* und Löschen des vorhandenen userReadings via<br />
:<code>deletereading HT.JOHN onlyAutoMode </code><br />
<br />
=== Was passiert, wenn der Sollwert am Thermostat manuell verstellt wird? ===<br />
Wenn der Sollwert manuell am Thermostat verändert wird, kann es bis zu 3 Minuten dauern, bis dieser an FHEM gemeldet wird.<br />
<br />
Wenn der Scanner in dieser Wartezeit aktiv wird, wird er den soeben geänderten Sollwert überschreiben. In diesem Fall bliebe die manuelle Änderung wirkungslos.<br />
<br />
Wird die manuelle Änderung des Sollwertes vom Scanner erkannt, so gilt dieser bis zum nächsten Schaltpunkt des internen Wochenprogrammes.<br />
<br />
=== Mehrere Thermostate in einer Gruppe? ===<br />
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.<br />
<br />
=== Was ist zu tun wenn, Thermostate zusammen mit einem Wandthermostat eingesetzt werden? ===<br />
In diesem Fall ist der Scanner überflüssig, da das Wandthermostat ohnehin eine detaillierte Kurve des Istwertes liefert.<br />
<br />
=== Sind Fensterkontakte sinnvoll? ===<br />
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 <br />
[http://www.elv.de/topic/tuer-fensterkontakt-sinn-und-unsinn.html Sinn und Unsinn von Fensterkontakten] zeigt.<br />
<br />
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. <br />
<br />
[[Datei:2013_11_02_Scanner_TSturz.png|Sturz-Temperatur-Erkennung]]<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 vermutlich mit einer WindowOpenDuration von 0 behoben werden, ausserdem ist im Hochsommer die Heizung ohnehin ausgeschaltet.<br />
<br />
Folgende Nachteile haben die Max-Fensterkontakte:<br />
* 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.<br />
* 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).<br />
<br />
=== Berücksichtigt der Scanner die Temperatur-Sturz-Erkennung? ===<br />
Wenn desiredTemperature=WindowsOpenTemperature, dann stellt der Scanner seine Arbeit ein. Ansonsten würde er durch aktive Modeumschaltung die WindowsOpenTemperature dauerhaft setzen.<br />
<br />
=== Kann der Scanner mit Fensterkontakten umgehen? ===<br />
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.<br />
<br />
Ausserdem wäre es fatal, wenn der Scanner in der Phase des offenen Fenster den Sollwert überschreiben würde. Bei offenem Fenster ist der Scanner inaktiv, er schaltet also den Modus nicht mehr um.<br />
<br />
=== Was ist denn, wenn ich noch einen zweiten Fensterkontakt habe? ===<br />
Derzeit wird nur 1 ShutterContact unterstützt. Möglicherweise wird in einer der nächsten Versionen die Funktionalität erweitert.<br />
<br />
=== Was passiert, wenn der Boost-Mode aktiviert wurde? ===<br />
Sobald dies der Scanner erkennt, stellt er seine Aktivität ein, bis wieder der Modus Auto oder Manu erscheint.<br />
<br />
=== Unterstützt der Scanner auch den MAX-ECO-Taster? ===<br />
Nein.<br />
<br />
=== Beeinflusst der Scanner den Regelmechanismus des Thermostats? ===<br />
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.<br />
<br />
== Im Kochtopf ==<br />
(realisierte Punkte der Modul-Variante sind fett ausgewiesen)<br />
<br />
* '''Scanner wird nicht mehr als Skript, sondern als Modul ausgeführt'''<br />
* '''Mindestwert für Scan-Intervall, der nicht unterschritten werden darf'''<br />
* '''Möglichkeit mehrere Fensterkontakte einem Thermostat zuzuweisen'''<br />
* Verzögerte Reaktion nach Aktivieren des Fensterkontakts<br />
* Möglichkeit eine Gruppe von Thermostaten auf Eco-Mode zu schalten (z.B. ausgelöst über ECO-Taster)<br />
* Gruppenbildung über mehrere Thermostate (für Eco-Taster)<br />
* '''Fix: wenn bei desriredtemperatur ON,OFF anstelle einer Zahl erscheint.'''<br />
<br />
== Die Modul-Variante ==<br />
<br />
Die Modul-Variante ist seit dem 10.01.2016 Bestandteil von FHEM.<br />
<br />
=== Voraussetzungen ===<br />
* ggf. vorhandene Script-Variante sollte deaktiviert werden (99_UtilsMaxScan löschen/verschieben)<br />
<br />
=== Inbetriebnahme ===<br />
* Scanner Modul definieren<br />
<pre><br />
define Scanner MaxScanner<br />
attr Scanner verbose 1<br />
</pre><br />
<br />
* die bestehende Max-Thermostate verfügen nun automatisch über neue Attribute, die den Scanner betreffen<br />
* die meisten Scanner-spezfischen Attribute beginnen immer mit "scn"<br />
* im folgende Beispiel wird das Thermostat HT.JOHN betrachtet:<br />
<pre><br />
define HT.JOHN MAX HeatingThermostat 066666<br />
</pre><br />
* das Thermostat wird für den Scanner freigegeben<br />
<pre>attr HT.JOHN scanTemp 1</pre><br />
* wir wählen die Betriebsart Mode-Change<br />
<pre>attr HT.JOHN scnProcessByDesiChange 0</pre><br />
* wir können 0..n ShutterContacts definieren, getrennt durch Komma<br />
<pre>attr HT.JOHN scnShutterList SHUTTER.JOHN,SHUTTER.BRENNER</pre><br />
* verbose liefert ausführliche Infos im Logger<br />
<pre>attr HT.JOHN verbose 4</pre><br />
<br />
=== Attribute Thermostat===<br />
{| class="wikitable sortable"<br />
|-<br />
! Parameter !! Wertebereich !! Default !! Beschreibung<br />
|-<br />
|scanTemp||[0,1]||0||wenn 1, wird das Thermostat vom Scanner berücksichtigt<br />
|-<br />
|scnProcessByDesiChange||[0,1]||0||wenn 1, wird das Thermostat über die Änderung von desiredTemperature (DesiredChange) getriggert, ansonsten über die Änderung des Modes (ModeChange)<br />
|-<br />
|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<br />
Thermostat geschrieben wird. Ist hingegen NOCHANGE gewählt, so wird der aktuelle am Thermostat angewählte Mode belassen.<br />
|-<br />
|scnShutterList||||||Liste von assoziierten Max-Fensterkontakten (ShutterContacts), die durch ein Komma getrennt werden. <br />
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.<br />
<br />
|}<br />
=== Attribute Scanner===<br />
{| class="wikitable sortable"<br />
|-<br />
! Parameter !! Wertebereich !! Default !! Beschreibung<br />
|-<br />
|disable||[0,1]||0|| wenn 1, dann wird der Scanner gesperrt und ist somit inaktiv.<br />
|-<br />
|scnCreditThreshold||[150..600]||300|| die Mindestanzahl von verfügbaren Credits, ab der der Scanner mit dem Triggern der Thermostate beginnt<br />
|-<br />
|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.<br />
|-<br />
|}<br />
<br />
=== Background ===<br />
<br />
==== Hilfe zur Diagnose der Abläufe ====<br />
Ein wichtiges Hilfsmittel ist der Event-Monitor. Mit der Filter-Einstellung "MAX.*" werden nur noch die MAX-relevanten Events dargestellt.<br />
<br />
Interpretation der Ausgabe:<br/><br />
<pre><br />
2016-01-06 21:24:43 MAX HT.BAD desiredTemperature auto 20.0 <-- Triggern des Thermostats durch Scanner<br />
<br />
2016-01-06 21:24:50 MAX HT.BAD mode: auto --> Rückmeldung vom Thermostat<br />
2016-01-06 21:24:50 MAX HT.BAD RSSI: -54 --> Rückmeldung vom Thermostat<br />
2016-01-06 21:24:56 MAX HT.BAD temperature: 20.2 --> Rückmeldung vom Thermostat<br />
</pre><br />
<br />
Hier erscheinen also die zu Thermostat gesendeten Informationen ebenso, wie die empfangenen.<br />
Empfangene Informationen sind meist mit einem ":" gekennzeichnet.<br />
<br />
[[Kategorie:MAX]]</div>Johnhttp://wiki.fhem.de/w/index.php?title=MAX!_Temperatur-Scanner&diff=13527MAX! Temperatur-Scanner2016-01-10T13:32:57Z<p>John: /* Inbetriebnahme */</p>
<hr />
<div>Der '''MAX! Temperatur-Scanner''' ist ein Perl-Skript, das die kontinuierliche Temperatur-Aufzeichnung<br />
von MAX-Thermostaten ermöglicht. <br />
<br />
== Features ==<br />
* kontinuierliche Erfassung von Temperatur und Ventil-Position <br />
* Berücksichtigung der System-Ressourcen (dutycycle, credits)<br />
* CUL und CUBE werden unterstützt<br />
* gleichberechtigte zeitliche Bearbeitung der Thermostate (Round-Robin-Prinzip)<br />
* Ermittlung der optimalen Scan-Rate über die Anzahl der eingebundenen Thermostate<br />
* 2 Scan-Modi stehen zur Verfügung (DesiredChange + ModeChange)<br />
<br />
== Zielsetzung des WIKI-Artikels ==<br />
Hier werden Fragen und Erkenntnisse zum Thema dargestellt, da der Forums-Eintrag für viele Anwender nicht mehr überschaubar ist.<br />
<br />
Der Artikel wird sukzessive erweitert.<br />
<br />
== Aktuelle Version ==<br />
Im Anhang zu folgendem Forumsbeitrag [http://forum.fhem.de/index.php/topic,11624.msg68237.html#msg68237 MaxScan Version 1.05c]<br />
<br />
=== Voraussetzungen ===<br />
==== Qualität der Funkverbindung ====<br />
In der Log-Datei sollten möglichst wenig Einträge der nachfolgenden Form auftreten<br />
<pre>2013.11.01 02:12:33 2: CUL_MAX_SendQueueHandler: Missing ack from 0905a5 for 0b0b0040123456xxxxxxxxx</pre><br />
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.<br />
<br />
==== Ausreichend Credits ====<br />
Der Scanner kann nicht aktiv werden, wenn gehäuft Log-Einträge der nachfolgenden Form auftreten.<br />
<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><br />
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.<br />
<br />
==== Einrichten des Thermostat-internen Wochenprogrammes ====<br />
Anders als bei den Vorgängerversionen <=1.04 ist nun ab Version 1.05 zwingend das Thermostat-interne<br />
Wochenprogramm notwendig.<br />
<br />
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.<br />
<br />
Das bei früheren Versionen eingesetzte Heating_Control kann somit entfallen.<br />
<br />
'''Bitte folgendes beachten:'''<br />
<br />
Es gibt im Zusammenhang mit dem Wochenprogramm ein Problem mit dem letzten Schaltpunkt des Tages. <br />
Der Workaround wurde [http://forum.fhem.de/index.php/topic,17231.msg112738.html#msg112738 hier]<br />
beschrieben.<br />
<br />
<big>Man muss dafür sorgen, dass man kurz vor Ende des Tages noch einen Schaltpunkt setzt.</big><br />
<br />
=== Inbetriebnahme ===<br />
* aktuell freigegebene Version von 99_UtilsMaxScan.pm in das Verzeichnis /opt/fhem/FHEM kopieren.<br />
* Bei den Thermostaten, die gescannt werden sollen, das Attribut scanTemp setzen via<br />
<pre>attr VT_HW scanTemp 1</pre><br />
* das Wochenprogramm im Thermostat nach den Bedürfnissen einstellen<br />
* auf''' keinen''' Fall das Attribut keepAuto setzen<br />
* mit dem userReading "onlyAutoMode" kann der Scan-Modus ModeChange festgelegt werden<br />
<pre>attr HT.JOHN userReadings onlyAutoMode { return "1";;}</pre> <br />
* ist ein ShutterContact mit dem Thermostat assoziiert, dann muss man dies bekannt machen mit dem UserReading<br />
<pre>attr VT_HW userReadings watchShutter { return "SHUTTER.HW";;}</pre><br />
* '''FHEM neu starten'''<br />
<br />
'''Hinweis'''<br /><br />
Je kleiner der Wert von Attribut verbose, umso weniger Ausgaben erhält man in der Log-Datei.<br />
<br />
== Mechanismen ==<br />
=== Das Problem ===<br />
Der Hersteller der MAX-Thermostate hat diese so konzipiert, dass die gemessene Temperatur und Ventilstellung nur übertragen werden, wenn sich Folgendes ändert:<br />
* die Ventilstellung<br />
* die Betriebsart (mode: auto,manu,temporary,boost)<br />
* der Sollwert<br />
<br />
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.<br />
<br />
=== Der Lösungsansatz ===<br />
==== Triggerung per Mode-Umschaltung (ModeChange) ====<br />
Dies ist der Default-Mode des Scanners.<br />
Hier wird der Ansatz verfolgt, die Betriebsart des Thermostats regelmässig umzuschalten via<br />
:AUTO ==> MANU<br />
<Wartezeit mindestens 3 Minuten><br />
:MANU ==> AUTO<br />
<br />
Dies veranlasst das Thermostat, regelmässig die gewünschten Werte an FHEM (den gepaarten Transceiver) zu senden.<br />
<br />
==== Triggerung per Sollwert-Umschaltung (DesiredChange) ====<br />
Durch Änderung des Sollwertes kann ebenso die Übertragung des Istwertes am Thermostat initiiert werden.<br />
<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.<br />
<br />
Dieser Modus wird durch die Definition des UserReadings "onlyAutoMode" festgelegt.<br />
:<code>attr HT.JOHN userReadings onlyAutoMode { return "1";;}</code><br />
<br />
'''Beispiel:'''<br />
<br />
Sollwert im Thermostat nach Wochenprofil: 18<br />
Fall A:<br />
----<br />
* Istwert 17<br />
* Sollwert A von Scanner gesetzt : 18.5<br />
* Sollwert B von Scanner gesetzt : 18.0<br />
* Der Scanner wechselt also von 18 auf 18.5 und zurück.<br />
<br />
Fall B:<br />
----<br />
* Istwert 19<br />
* Sollwert A von Scanner gesetzt : 17.5<br />
* Sollwert B von Scanner gesetzt : 18.0<br />
* Der Scanner wechselt also von 18 auf 17.5 und zurück.<br />
<br />
=== Ergebnis ===<br />
==== ohne Scanner ====<br />
[[Datei:2013_12_MaxScanner_Vorher.png|ohne Scanner]]<br />
<br />
==== mit Scanner (ScanMode=ModeChange) ====<br />
[[Datei:13_12_01_Scanner_ModeChange.png|mit Scanner]]<br />
<br />
==== mit Scanner (ScanMode=DesiredChange) ====<br />
[[Datei:13_12_01_Scanner_DesiredChange.png|mit Scanner]]<br />
<br />
=== Ressourcen ===<br />
Die Sendezeit jedes Teilnehmers ist auf 1% begrenzt.<br />
<br />
Konkret bedeutet dies, dass ein CUL ca. 33 Telegramme pro Stunde senden kann.<br />
Der MAX-Scanner darf nicht alle Ressourcen für sich beanspruchen, sondern sieht seine Aufgabe als nachrangig. <br />
<br />
Erst wenn mehr als 300 Credits (von max. 900 möglichen) zur Verfügung stehen, wird das Skript aktiv.<br />
<br />
== Fragen und Antworten ==<br />
=== Welchen ScanMode soll ich wählen? ===<br />
Nachfolgende Punkte können als Entscheidungskriterium dienen:<br />
<br />
'''ModeChange'''<br />
* keine Änderung des Sollwertes nötig<br />
* damit ist das Ventil "ruhiger", da sich die Regeldifferenz nicht durch den Scanner-Betrieb ändert.<br />
<br />
'''DesiredChange'''<br />
* der Auto-Modus wird niemals verlassen<br />
* Falls FHEM ausfällt, wird das Thermostat das gespeicherte Wochenprogramm nutzen<br />
<br />
=== Wie kann man den ScanMode nachträglich ändern? ===<br />
Man kann das userReading ändern, so dass es 0 liefert<br />
:<code>attr HT.JOHN userReadings onlyAutoMode { return "0";;}</code><br />
<br />
oder man löscht das userReading durch<br />
* Löschen aus dem attribut userReading<br />
* und Löschen des vorhandenen userReadings via<br />
:<code>deletereading HT.JOHN onlyAutoMode </code><br />
<br />
=== Was passiert, wenn der Sollwert am Thermostat manuell verstellt wird? ===<br />
Wenn der Sollwert manuell am Thermostat verändert wird, kann es bis zu 3 Minuten dauern, bis dieser an FHEM gemeldet wird.<br />
<br />
Wenn der Scanner in dieser Wartezeit aktiv wird, wird er den soeben geänderten Sollwert überschreiben. In diesem Fall bliebe die manuelle Änderung wirkungslos.<br />
<br />
Wird die manuelle Änderung des Sollwertes vom Scanner erkannt, so gilt dieser bis zum nächsten Schaltpunkt des internen Wochenprogrammes.<br />
<br />
=== Mehrere Thermostate in einer Gruppe? ===<br />
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.<br />
<br />
=== Was ist zu tun wenn, Thermostate zusammen mit einem Wandthermostat eingesetzt werden? ===<br />
In diesem Fall ist der Scanner überflüssig, da das Wandthermostat ohnehin eine detaillierte Kurve des Istwertes liefert.<br />
<br />
=== Sind Fensterkontakte sinnvoll? ===<br />
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 <br />
[http://www.elv.de/topic/tuer-fensterkontakt-sinn-und-unsinn.html Sinn und Unsinn von Fensterkontakten] zeigt.<br />
<br />
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. <br />
<br />
[[Datei:2013_11_02_Scanner_TSturz.png|Sturz-Temperatur-Erkennung]]<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 vermutlich mit einer WindowOpenDuration von 0 behoben werden, ausserdem ist im Hochsommer die Heizung ohnehin ausgeschaltet.<br />
<br />
Folgende Nachteile haben die Max-Fensterkontakte:<br />
* 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.<br />
* 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).<br />
<br />
=== Berücksichtigt der Scanner die Temperatur-Sturz-Erkennung? ===<br />
Wenn desiredTemperature=WindowsOpenTemperature, dann stellt der Scanner seine Arbeit ein. Ansonsten würde er durch aktive Modeumschaltung die WindowsOpenTemperature dauerhaft setzen.<br />
<br />
=== Kann der Scanner mit Fensterkontakten umgehen? ===<br />
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.<br />
<br />
Ausserdem wäre es fatal, wenn der Scanner in der Phase des offenen Fenster den Sollwert überschreiben würde. Bei offenem Fenster ist der Scanner inaktiv, er schaltet also den Modus nicht mehr um.<br />
<br />
=== Was ist denn, wenn ich noch einen zweiten Fensterkontakt habe? ===<br />
Derzeit wird nur 1 ShutterContact unterstützt. Möglicherweise wird in einer der nächsten Versionen die Funktionalität erweitert.<br />
<br />
=== Was passiert, wenn der Boost-Mode aktiviert wurde? ===<br />
Sobald dies der Scanner erkennt, stellt er seine Aktivität ein, bis wieder der Modus Auto oder Manu erscheint.<br />
<br />
=== Unterstützt der Scanner auch den MAX-ECO-Taster? ===<br />
Nein.<br />
<br />
=== Beeinflusst der Scanner den Regelmechanismus des Thermostats? ===<br />
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.<br />
<br />
== Im Kochtopf ==<br />
(realisierte Punkte der Modul-Variante sind fett ausgewiesen)<br />
<br />
* '''Scanner wird nicht mehr als Skript, sondern als Modul ausgeführt'''<br />
* '''Mindestwert für Scan-Intervall, der nicht unterschritten werden darf'''<br />
* '''Möglichkeit mehrere Fensterkontakte einem Thermostat zuzuweisen'''<br />
* Verzögerte Reaktion nach Aktivieren des Fensterkontakts<br />
* Möglichkeit eine Gruppe von Thermostaten auf Eco-Mode zu schalten (z.B. ausgelöst über ECO-Taster)<br />
* Gruppenbildung über mehrere Thermostate (für Eco-Taster)<br />
* '''Fix: wenn bei desriredtemperatur ON,OFF anstelle einer Zahl erscheint.'''<br />
<br />
== Die Modul-Variante (Beta-Version) ==<br />
<br />
Die Modul-Variante ist derzeit in der Testphase. Sie soll die die Skript-Variante mittelfristig ablösen.<br />
<br />
=== Voraussetzungen ===<br />
* Download von Modul 98_MaxScanner.pm in das Modul-Verzeichnis von FHEM ([http://forum.fhem.de/index.php/topic,11624.msg68237.html#msg68237 Beitrag mit Download])<br />
* die Script-Variante sollte deaktiviert werden (99_UtilsMaxScan löschen/verschieben)<br />
* FHEM neu starten<br />
<br />
=== Inbetriebnahme ===<br />
* Scanner Modul definieren<br />
<pre><br />
define Scanner MaxScanner<br />
attr Scanner verbose 1<br />
</pre><br />
<br />
* die bestehende Max-Thermostate verfügen nun automatisch über neue Attribute, die den Scanner betreffen<br />
* die meisten Scanner-spezfischen Attribute beginnen immer mit "scn"<br />
* im folgende Beispiel wird das Thermostat HT.JOHN betrachtet:<br />
<pre><br />
define HT.JOHN MAX HeatingThermostat 066666<br />
</pre><br />
* das Thermostat wird für den Scanner freigegeben<br />
<pre>attr HT.JOHN scanTemp 1</pre><br />
* wir wählen die Betriebsart Mode-Change<br />
<pre>attr HT.JOHN scnProcessByDesiChange 0</pre><br />
* wir können 0..n ShutterContacts definieren, getrennt durch Komma<br />
<pre>attr HT.JOHN scnShutterList SHUTTER.JOHN,SHUTTER.BRENNER</pre><br />
* verbose liefert ausführliche Infos im Logger<br />
<pre>attr HT.JOHN verbose 4</pre><br />
<br />
=== Attribute Thermostat===<br />
{| class="wikitable sortable"<br />
|-<br />
! Parameter !! Wertebereich !! Default !! Beschreibung<br />
|-<br />
|scnEnabled||[0,1]||0||wenn 1, wird das Thermostat vom Scanner berücksichtigt<br />
|-<br />
|scnProcessByDesiChange||[0,1]||0||wenn 1, wird das Thermostat über die Änderung von desiredTemperature (DesiredChange) getriggert, ansonsten über die Änderung des Modes (ModeChange)<br />
|-<br />
|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<br />
Thermostat geschrieben wird. Ist hingegen NOCHANGE gewählt, so wird der aktuelle am Thermostat angewählte Mode belassen.<br />
|-<br />
|scnShutterList||||||Liste von assoziierten Max-Fensterkontakten (ShutterContacts), die durch ein Komma getrennt werden. <br />
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.<br />
<br />
|}<br />
=== Attribute Scanner===<br />
{| class="wikitable sortable"<br />
|-<br />
! Parameter !! Wertebereich !! Default !! Beschreibung<br />
|-<br />
|disable||[0,1]||0|| wenn 1, dann wird der Scanner gesperrt und ist somit inaktiv.<br />
|-<br />
|scnCreditThreshold||[150..600]||300|| die Mindestanzahl von verfügbaren Credits, ab der der Scanner mit dem Triggern der Thermostate beginnt<br />
|-<br />
|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.<br />
|-<br />
|}<br />
<br />
=== Background ===<br />
<br />
==== Hilfe zur Diagnose der Abläufe ====<br />
Ein wichtiges Hilfsmittel ist der Event-Monitor. Mit der Filter-Einstellung "MAX.*" werden nur noch die MAX-relevanten Events dargestellt.<br />
<br />
Interpretation der Ausgabe:<br/><br />
<pre><br />
2016-01-06 21:24:43 MAX HT.BAD desiredTemperature auto 20.0 <-- Triggern des Thermostats durch Scanner<br />
<br />
2016-01-06 21:24:50 MAX HT.BAD mode: auto --> Rückmeldung vom Thermostat<br />
2016-01-06 21:24:50 MAX HT.BAD RSSI: -54 --> Rückmeldung vom Thermostat<br />
2016-01-06 21:24:56 MAX HT.BAD temperature: 20.2 --> Rückmeldung vom Thermostat<br />
</pre><br />
<br />
Hier erscheinen also die zu Thermostat gesendeten Informationen ebenso, wie die empfangenen.<br />
Empfangene Informationen sind meist mit einem ":" gekennzeichnet.<br />
<br />
[[Kategorie:MAX]]</div>Johnhttp://wiki.fhem.de/w/index.php?title=MAX!_Temperatur-Scanner&diff=13523MAX! Temperatur-Scanner2016-01-10T11:24:43Z<p>John: /* Voraussetzungen */</p>
<hr />
<div>Der '''MAX! Temperatur-Scanner''' ist ein Perl-Skript, das die kontinuierliche Temperatur-Aufzeichnung<br />
von MAX-Thermostaten ermöglicht. <br />
<br />
== Features ==<br />
* kontinuierliche Erfassung von Temperatur und Ventil-Position <br />
* Berücksichtigung der System-Ressourcen (dutycycle, credits)<br />
* CUL und CUBE werden unterstützt<br />
* gleichberechtigte zeitliche Bearbeitung der Thermostate (Round-Robin-Prinzip)<br />
* Ermittlung der optimalen Scan-Rate über die Anzahl der eingebundenen Thermostate<br />
* 2 Scan-Modi stehen zur Verfügung (DesiredChange + ModeChange)<br />
<br />
== Zielsetzung des WIKI-Artikels ==<br />
Hier werden Fragen und Erkenntnisse zum Thema dargestellt, da der Forums-Eintrag für viele Anwender nicht mehr überschaubar ist.<br />
<br />
Der Artikel wird sukzessive erweitert.<br />
<br />
== Aktuelle Version ==<br />
Im Anhang zu folgendem Forumsbeitrag [http://forum.fhem.de/index.php/topic,11624.msg68237.html#msg68237 MaxScan Version 1.05c]<br />
<br />
=== Voraussetzungen ===<br />
==== Qualität der Funkverbindung ====<br />
In der Log-Datei sollten möglichst wenig Einträge der nachfolgenden Form auftreten<br />
<pre>2013.11.01 02:12:33 2: CUL_MAX_SendQueueHandler: Missing ack from 0905a5 for 0b0b0040123456xxxxxxxxx</pre><br />
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.<br />
<br />
==== Ausreichend Credits ====<br />
Der Scanner kann nicht aktiv werden, wenn gehäuft Log-Einträge der nachfolgenden Form auftreten.<br />
<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><br />
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.<br />
<br />
==== Einrichten des Thermostat-internen Wochenprogrammes ====<br />
Anders als bei den Vorgängerversionen <=1.04 ist nun ab Version 1.05 zwingend das Thermostat-interne<br />
Wochenprogramm notwendig.<br />
<br />
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.<br />
<br />
Das bei früheren Versionen eingesetzte Heating_Control kann somit entfallen.<br />
<br />
'''Bitte folgendes beachten:'''<br />
<br />
Es gibt im Zusammenhang mit dem Wochenprogramm ein Problem mit dem letzten Schaltpunkt des Tages. <br />
Der Workaround wurde [http://forum.fhem.de/index.php/topic,17231.msg112738.html#msg112738 hier]<br />
beschrieben.<br />
<br />
<big>Man muss dafür sorgen, dass man kurz vor Ende des Tages noch einen Schaltpunkt setzt.</big><br />
<br />
=== Inbetriebnahme ===<br />
* aktuell freigegebene Version von 99_UtilsMaxScan.pm in das Verzeichnis /opt/fhem/FHEM kopieren.<br />
* Bei den Thermostaten, die gescannt werden sollen, das Attribut scanTemp setzen via<br />
<pre>attr VT_HW scanTemp 1</pre><br />
* das Wochenprogramm im Thermostat nach den Bedürfnissen einstellen<br />
* auf''' keinen''' Fall das Attribut keepAuto setzen<br />
* mit dem userReading "onlyAutoMode" kann der Scan-Modus ModeChange festgelegt werden<br />
<pre>attr HT.JOHN userReadings onlyAutoMode { return "1";;}</pre> <br />
* ist ein ShutterContact mit dem Thermostat assoziiert, dann muss man dies bekannt machen mit dem UserReading<br />
<pre>attr VT_HW userReadings watchShutter { return "SHUTTER.HW";;}</pre><br />
* '''FHEM neu starten'''<br />
<br />
'''Hinweis'''<br /><br />
Je kleiner der Wert von Attribut verbose, umso weniger Ausgaben erhält man in der Log-Datei.<br />
<br />
== Mechanismen ==<br />
=== Das Problem ===<br />
Der Hersteller der MAX-Thermostate hat diese so konzipiert, dass die gemessene Temperatur und Ventilstellung nur übertragen werden, wenn sich Folgendes ändert:<br />
* die Ventilstellung<br />
* die Betriebsart (mode: auto,manu,temporary,boost)<br />
* der Sollwert<br />
<br />
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.<br />
<br />
=== Der Lösungsansatz ===<br />
==== Triggerung per Mode-Umschaltung (ModeChange) ====<br />
Dies ist der Default-Mode des Scanners.<br />
Hier wird der Ansatz verfolgt, die Betriebsart des Thermostats regelmässig umzuschalten via<br />
:AUTO ==> MANU<br />
<Wartezeit mindestens 3 Minuten><br />
:MANU ==> AUTO<br />
<br />
Dies veranlasst das Thermostat, regelmässig die gewünschten Werte an FHEM (den gepaarten Transceiver) zu senden.<br />
<br />
==== Triggerung per Sollwert-Umschaltung (DesiredChange) ====<br />
Durch Änderung des Sollwertes kann ebenso die Übertragung des Istwertes am Thermostat initiiert werden.<br />
<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.<br />
<br />
Dieser Modus wird durch die Definition des UserReadings "onlyAutoMode" festgelegt.<br />
:<code>attr HT.JOHN userReadings onlyAutoMode { return "1";;}</code><br />
<br />
'''Beispiel:'''<br />
<br />
Sollwert im Thermostat nach Wochenprofil: 18<br />
Fall A:<br />
----<br />
* Istwert 17<br />
* Sollwert A von Scanner gesetzt : 18.5<br />
* Sollwert B von Scanner gesetzt : 18.0<br />
* Der Scanner wechselt also von 18 auf 18.5 und zurück.<br />
<br />
Fall B:<br />
----<br />
* Istwert 19<br />
* Sollwert A von Scanner gesetzt : 17.5<br />
* Sollwert B von Scanner gesetzt : 18.0<br />
* Der Scanner wechselt also von 18 auf 17.5 und zurück.<br />
<br />
=== Ergebnis ===<br />
==== ohne Scanner ====<br />
[[Datei:2013_12_MaxScanner_Vorher.png|ohne Scanner]]<br />
<br />
==== mit Scanner (ScanMode=ModeChange) ====<br />
[[Datei:13_12_01_Scanner_ModeChange.png|mit Scanner]]<br />
<br />
==== mit Scanner (ScanMode=DesiredChange) ====<br />
[[Datei:13_12_01_Scanner_DesiredChange.png|mit Scanner]]<br />
<br />
=== Ressourcen ===<br />
Die Sendezeit jedes Teilnehmers ist auf 1% begrenzt.<br />
<br />
Konkret bedeutet dies, dass ein CUL ca. 33 Telegramme pro Stunde senden kann.<br />
Der MAX-Scanner darf nicht alle Ressourcen für sich beanspruchen, sondern sieht seine Aufgabe als nachrangig. <br />
<br />
Erst wenn mehr als 300 Credits (von max. 900 möglichen) zur Verfügung stehen, wird das Skript aktiv.<br />
<br />
== Fragen und Antworten ==<br />
=== Welchen ScanMode soll ich wählen? ===<br />
Nachfolgende Punkte können als Entscheidungskriterium dienen:<br />
<br />
'''ModeChange'''<br />
* keine Änderung des Sollwertes nötig<br />
* damit ist das Ventil "ruhiger", da sich die Regeldifferenz nicht durch den Scanner-Betrieb ändert.<br />
<br />
'''DesiredChange'''<br />
* der Auto-Modus wird niemals verlassen<br />
* Falls FHEM ausfällt, wird das Thermostat das gespeicherte Wochenprogramm nutzen<br />
<br />
=== Wie kann man den ScanMode nachträglich ändern? ===<br />
Man kann das userReading ändern, so dass es 0 liefert<br />
:<code>attr HT.JOHN userReadings onlyAutoMode { return "0";;}</code><br />
<br />
oder man löscht das userReading durch<br />
* Löschen aus dem attribut userReading<br />
* und Löschen des vorhandenen userReadings via<br />
:<code>deletereading HT.JOHN onlyAutoMode </code><br />
<br />
=== Was passiert, wenn der Sollwert am Thermostat manuell verstellt wird? ===<br />
Wenn der Sollwert manuell am Thermostat verändert wird, kann es bis zu 3 Minuten dauern, bis dieser an FHEM gemeldet wird.<br />
<br />
Wenn der Scanner in dieser Wartezeit aktiv wird, wird er den soeben geänderten Sollwert überschreiben. In diesem Fall bliebe die manuelle Änderung wirkungslos.<br />
<br />
Wird die manuelle Änderung des Sollwertes vom Scanner erkannt, so gilt dieser bis zum nächsten Schaltpunkt des internen Wochenprogrammes.<br />
<br />
=== Mehrere Thermostate in einer Gruppe? ===<br />
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.<br />
<br />
=== Was ist zu tun wenn, Thermostate zusammen mit einem Wandthermostat eingesetzt werden? ===<br />
In diesem Fall ist der Scanner überflüssig, da das Wandthermostat ohnehin eine detaillierte Kurve des Istwertes liefert.<br />
<br />
=== Sind Fensterkontakte sinnvoll? ===<br />
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 <br />
[http://www.elv.de/topic/tuer-fensterkontakt-sinn-und-unsinn.html Sinn und Unsinn von Fensterkontakten] zeigt.<br />
<br />
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. <br />
<br />
[[Datei:2013_11_02_Scanner_TSturz.png|Sturz-Temperatur-Erkennung]]<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 vermutlich mit einer WindowOpenDuration von 0 behoben werden, ausserdem ist im Hochsommer die Heizung ohnehin ausgeschaltet.<br />
<br />
Folgende Nachteile haben die Max-Fensterkontakte:<br />
* 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.<br />
* 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).<br />
<br />
=== Berücksichtigt der Scanner die Temperatur-Sturz-Erkennung? ===<br />
Wenn desiredTemperature=WindowsOpenTemperature, dann stellt der Scanner seine Arbeit ein. Ansonsten würde er durch aktive Modeumschaltung die WindowsOpenTemperature dauerhaft setzen.<br />
<br />
=== Kann der Scanner mit Fensterkontakten umgehen? ===<br />
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.<br />
<br />
Ausserdem wäre es fatal, wenn der Scanner in der Phase des offenen Fenster den Sollwert überschreiben würde. Bei offenem Fenster ist der Scanner inaktiv, er schaltet also den Modus nicht mehr um.<br />
<br />
=== Was ist denn, wenn ich noch einen zweiten Fensterkontakt habe? ===<br />
Derzeit wird nur 1 ShutterContact unterstützt. Möglicherweise wird in einer der nächsten Versionen die Funktionalität erweitert.<br />
<br />
=== Was passiert, wenn der Boost-Mode aktiviert wurde? ===<br />
Sobald dies der Scanner erkennt, stellt er seine Aktivität ein, bis wieder der Modus Auto oder Manu erscheint.<br />
<br />
=== Unterstützt der Scanner auch den MAX-ECO-Taster? ===<br />
Nein.<br />
<br />
=== Beeinflusst der Scanner den Regelmechanismus des Thermostats? ===<br />
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.<br />
<br />
== Im Kochtopf ==<br />
(realisierte Punkte der Modul-Variante sind fett ausgewiesen)<br />
<br />
* '''Scanner wird nicht mehr als Skript, sondern als Modul ausgeführt'''<br />
* '''Mindestwert für Scan-Intervall, der nicht unterschritten werden darf'''<br />
* '''Möglichkeit mehrere Fensterkontakte einem Thermostat zuzuweisen'''<br />
* Verzögerte Reaktion nach Aktivieren des Fensterkontakts<br />
* Möglichkeit eine Gruppe von Thermostaten auf Eco-Mode zu schalten (z.B. ausgelöst über ECO-Taster)<br />
* Gruppenbildung über mehrere Thermostate (für Eco-Taster)<br />
* '''Fix: wenn bei desriredtemperatur ON,OFF anstelle einer Zahl erscheint.'''<br />
<br />
== Die Modul-Variante (Beta-Version) ==<br />
<br />
Die Modul-Variante ist derzeit in der Testphase. Sie soll die die Skript-Variante mittelfristig ablösen.<br />
<br />
=== Voraussetzungen ===<br />
* Download von Modul 98_MaxScanner.pm in das Modul-Verzeichnis von FHEM ([http://forum.fhem.de/index.php/topic,11624.msg68237.html#msg68237 Beitrag mit Download])<br />
* die Script-Variante sollte deaktiviert werden (99_UtilsMaxScan löschen/verschieben)<br />
* FHEM neu starten<br />
<br />
=== Inbetriebnahme ===<br />
* Scanner Modul definieren<br />
<pre><br />
define Scanner MaxScanner<br />
attr Scanner verbose 1<br />
</pre><br />
<br />
* die bestehende Max-Thermostate verfügen nun automatisch über neue Attribute, die den Scanner betreffen<br />
* alle Scanner-spezfischen Attribute beginnen immer mit "scn"<br />
* im folgende Beispiel wird das Thermostat HT.JOHN betrachtet:<br />
<pre><br />
define HT.JOHN MAX HeatingThermostat 066666<br />
</pre><br />
* das Thermostat wird für den Scanner freigegeben<br />
<pre>attr HT.JOHN scnEnabled 1</pre><br />
* wir wählen die Betriebsart Mode-Change<br />
<pre>attr HT.JOHN scnProcessByDesiChange 0</pre><br />
* wir können 0..n ShutterContacts definieren, getrennt durch Komma<br />
<pre>attr HT.JOHN scnShutterList SHUTTER.JOHN,SHUTTER.BRENNER</pre><br />
* verbose liefert ausführliche Infos im Logger<br />
<pre>attr HT.JOHN verbose 4</pre><br />
<br />
=== Attribute Thermostat===<br />
{| class="wikitable sortable"<br />
|-<br />
! Parameter !! Wertebereich !! Default !! Beschreibung<br />
|-<br />
|scnEnabled||[0,1]||0||wenn 1, wird das Thermostat vom Scanner berücksichtigt<br />
|-<br />
|scnProcessByDesiChange||[0,1]||0||wenn 1, wird das Thermostat über die Änderung von desiredTemperature (DesiredChange) getriggert, ansonsten über die Änderung des Modes (ModeChange)<br />
|-<br />
|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<br />
Thermostat geschrieben wird. Ist hingegen NOCHANGE gewählt, so wird der aktuelle am Thermostat angewählte Mode belassen.<br />
|-<br />
|scnShutterList||||||Liste von assoziierten Max-Fensterkontakten (ShutterContacts), die durch ein Komma getrennt werden. <br />
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.<br />
<br />
|}<br />
=== Attribute Scanner===<br />
{| class="wikitable sortable"<br />
|-<br />
! Parameter !! Wertebereich !! Default !! Beschreibung<br />
|-<br />
|disable||[0,1]||0|| wenn 1, dann wird der Scanner gesperrt und ist somit inaktiv.<br />
|-<br />
|scnCreditThreshold||[150..600]||300|| die Mindestanzahl von verfügbaren Credits, ab der der Scanner mit dem Triggern der Thermostate beginnt<br />
|-<br />
|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.<br />
|-<br />
|}<br />
<br />
=== Background ===<br />
<br />
==== Hilfe zur Diagnose der Abläufe ====<br />
Ein wichtiges Hilfsmittel ist der Event-Monitor. Mit der Filter-Einstellung "MAX.*" werden nur noch die MAX-relevanten Events dargestellt.<br />
<br />
Interpretation der Ausgabe:<br/><br />
<pre><br />
2016-01-06 21:24:43 MAX HT.BAD desiredTemperature auto 20.0 <-- Triggern des Thermostats durch Scanner<br />
<br />
2016-01-06 21:24:50 MAX HT.BAD mode: auto --> Rückmeldung vom Thermostat<br />
2016-01-06 21:24:50 MAX HT.BAD RSSI: -54 --> Rückmeldung vom Thermostat<br />
2016-01-06 21:24:56 MAX HT.BAD temperature: 20.2 --> Rückmeldung vom Thermostat<br />
</pre><br />
<br />
Hier erscheinen also die zu Thermostat gesendeten Informationen ebenso, wie die empfangenen.<br />
Empfangene Informationen sind meist mit einem ":" gekennzeichnet.<br />
<br />
[[Kategorie:MAX]]</div>Johnhttp://wiki.fhem.de/w/index.php?title=MAX!_Temperatur-Scanner&diff=13507MAX! Temperatur-Scanner2016-01-08T22:05:39Z<p>John: /* Common Notify */</p>
<hr />
<div>Der '''MAX! Temperatur-Scanner''' ist ein Perl-Skript, das die kontinuierliche Temperatur-Aufzeichnung<br />
von MAX-Thermostaten ermöglicht. <br />
<br />
== Features ==<br />
* kontinuierliche Erfassung von Temperatur und Ventil-Position <br />
* Berücksichtigung der System-Ressourcen (dutycycle, credits)<br />
* CUL und CUBE werden unterstützt<br />
* gleichberechtigte zeitliche Bearbeitung der Thermostate (Round-Robin-Prinzip)<br />
* Ermittlung der optimalen Scan-Rate über die Anzahl der eingebundenen Thermostate<br />
* 2 Scan-Modi stehen zur Verfügung (DesiredChange + ModeChange)<br />
<br />
== Zielsetzung des WIKI-Artikels ==<br />
Hier werden Fragen und Erkenntnisse zum Thema dargestellt, da der Forums-Eintrag für viele Anwender nicht mehr überschaubar ist.<br />
<br />
Der Artikel wird sukzessive erweitert.<br />
<br />
== Aktuelle Version ==<br />
Im Anhang zu folgendem Forumsbeitrag [http://forum.fhem.de/index.php/topic,11624.msg68237.html#msg68237 MaxScan Version 1.05c]<br />
<br />
=== Voraussetzungen ===<br />
==== Qualität der Funkverbindung ====<br />
In der Log-Datei sollten möglichst wenig Einträge der nachfolgenden Form auftreten<br />
<pre>2013.11.01 02:12:33 2: CUL_MAX_SendQueueHandler: Missing ack from 0905a5 for 0b0b0040123456xxxxxxxxx</pre><br />
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.<br />
<br />
==== Ausreichend Credits ====<br />
Der Scanner kann nicht aktiv werden, wenn gehäuft Log-Einträge der nachfolgenden Form auftreten.<br />
<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><br />
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.<br />
<br />
==== Einrichten des Thermostat-internen Wochenprogrammes ====<br />
Anders als bei den Vorgängerversionen <=1.04 ist nun ab Version 1.05 zwingend das Thermostat-interne<br />
Wochenprogramm notwendig.<br />
<br />
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.<br />
<br />
Das bei früheren Versionen eingesetzte Heating_Control kann somit entfallen.<br />
<br />
'''Bitte folgendes beachten:'''<br />
<br />
Es gibt im Zusammenhang mit dem Wochenprogramm ein Problem mit dem letzten Schaltpunkt des Tages. <br />
Der Workaround wurde [http://forum.fhem.de/index.php/topic,17231.msg112738.html#msg112738 hier]<br />
beschrieben.<br />
<br />
<big>Man muss dafür sorgen, dass man kurz vor Ende des Tages noch einen Schaltpunkt setzt.</big><br />
<br />
=== Inbetriebnahme ===<br />
* aktuell freigegebene Version von 99_UtilsMaxScan.pm in das Verzeichnis /opt/fhem/FHEM kopieren.<br />
* Bei den Thermostaten, die gescannt werden sollen, das Attribut scanTemp setzen via<br />
<pre>attr VT_HW scanTemp 1</pre><br />
* das Wochenprogramm im Thermostat nach den Bedürfnissen einstellen<br />
* auf''' keinen''' Fall das Attribut keepAuto setzen<br />
* mit dem userReading "onlyAutoMode" kann der Scan-Modus ModeChange festgelegt werden<br />
<pre>attr HT.JOHN userReadings onlyAutoMode { return "1";;}</pre> <br />
* ist ein ShutterContact mit dem Thermostat assoziiert, dann muss man dies bekannt machen mit dem UserReading<br />
<pre>attr VT_HW userReadings watchShutter { return "SHUTTER.HW";;}</pre><br />
* '''FHEM neu starten'''<br />
<br />
'''Hinweis'''<br /><br />
Je kleiner der Wert von Attribut verbose, umso weniger Ausgaben erhält man in der Log-Datei.<br />
<br />
== Mechanismen ==<br />
=== Das Problem ===<br />
Der Hersteller der MAX-Thermostate hat diese so konzipiert, dass die gemessene Temperatur und Ventilstellung nur übertragen werden, wenn sich Folgendes ändert:<br />
* die Ventilstellung<br />
* die Betriebsart (mode: auto,manu,temporary,boost)<br />
* der Sollwert<br />
<br />
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.<br />
<br />
=== Der Lösungsansatz ===<br />
==== Triggerung per Mode-Umschaltung (ModeChange) ====<br />
Dies ist der Default-Mode des Scanners.<br />
Hier wird der Ansatz verfolgt, die Betriebsart des Thermostats regelmässig umzuschalten via<br />
:AUTO ==> MANU<br />
<Wartezeit mindestens 3 Minuten><br />
:MANU ==> AUTO<br />
<br />
Dies veranlasst das Thermostat, regelmässig die gewünschten Werte an FHEM (den gepaarten Transceiver) zu senden.<br />
<br />
==== Triggerung per Sollwert-Umschaltung (DesiredChange) ====<br />
Durch Änderung des Sollwertes kann ebenso die Übertragung des Istwertes am Thermostat initiiert werden.<br />
<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.<br />
<br />
Dieser Modus wird durch die Definition des UserReadings "onlyAutoMode" festgelegt.<br />
:<code>attr HT.JOHN userReadings onlyAutoMode { return "1";;}</code><br />
<br />
'''Beispiel:'''<br />
<br />
Sollwert im Thermostat nach Wochenprofil: 18<br />
Fall A:<br />
----<br />
* Istwert 17<br />
* Sollwert A von Scanner gesetzt : 18.5<br />
* Sollwert B von Scanner gesetzt : 18.0<br />
* Der Scanner wechselt also von 18 auf 18.5 und zurück.<br />
<br />
Fall B:<br />
----<br />
* Istwert 19<br />
* Sollwert A von Scanner gesetzt : 17.5<br />
* Sollwert B von Scanner gesetzt : 18.0<br />
* Der Scanner wechselt also von 18 auf 17.5 und zurück.<br />
<br />
=== Ergebnis ===<br />
==== ohne Scanner ====<br />
[[Datei:2013_12_MaxScanner_Vorher.png|ohne Scanner]]<br />
<br />
==== mit Scanner (ScanMode=ModeChange) ====<br />
[[Datei:13_12_01_Scanner_ModeChange.png|mit Scanner]]<br />
<br />
==== mit Scanner (ScanMode=DesiredChange) ====<br />
[[Datei:13_12_01_Scanner_DesiredChange.png|mit Scanner]]<br />
<br />
=== Ressourcen ===<br />
Die Sendezeit jedes Teilnehmers ist auf 1% begrenzt.<br />
<br />
Konkret bedeutet dies, dass ein CUL ca. 33 Telegramme pro Stunde senden kann.<br />
Der MAX-Scanner darf nicht alle Ressourcen für sich beanspruchen, sondern sieht seine Aufgabe als nachrangig. <br />
<br />
Erst wenn mehr als 300 Credits (von max. 900 möglichen) zur Verfügung stehen, wird das Skript aktiv.<br />
<br />
== Fragen und Antworten ==<br />
=== Welchen ScanMode soll ich wählen? ===<br />
Nachfolgende Punkte können als Entscheidungskriterium dienen:<br />
<br />
'''ModeChange'''<br />
* keine Änderung des Sollwertes nötig<br />
* damit ist das Ventil "ruhiger", da sich die Regeldifferenz nicht durch den Scanner-Betrieb ändert.<br />
<br />
'''DesiredChange'''<br />
* der Auto-Modus wird niemals verlassen<br />
* Falls FHEM ausfällt, wird das Thermostat das gespeicherte Wochenprogramm nutzen<br />
<br />
=== Wie kann man den ScanMode nachträglich ändern? ===<br />
Man kann das userReading ändern, so dass es 0 liefert<br />
:<code>attr HT.JOHN userReadings onlyAutoMode { return "0";;}</code><br />
<br />
oder man löscht das userReading durch<br />
* Löschen aus dem attribut userReading<br />
* und Löschen des vorhandenen userReadings via<br />
:<code>deletereading HT.JOHN onlyAutoMode </code><br />
<br />
=== Was passiert, wenn der Sollwert am Thermostat manuell verstellt wird? ===<br />
Wenn der Sollwert manuell am Thermostat verändert wird, kann es bis zu 3 Minuten dauern, bis dieser an FHEM gemeldet wird.<br />
<br />
Wenn der Scanner in dieser Wartezeit aktiv wird, wird er den soeben geänderten Sollwert überschreiben. In diesem Fall bliebe die manuelle Änderung wirkungslos.<br />
<br />
Wird die manuelle Änderung des Sollwertes vom Scanner erkannt, so gilt dieser bis zum nächsten Schaltpunkt des internen Wochenprogrammes.<br />
<br />
=== Mehrere Thermostate in einer Gruppe? ===<br />
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.<br />
<br />
=== Was ist zu tun wenn, Thermostate zusammen mit einem Wandthermostat eingesetzt werden? ===<br />
In diesem Fall ist der Scanner überflüssig, da das Wandthermostat ohnehin eine detaillierte Kurve des Istwertes liefert.<br />
<br />
=== Sind Fensterkontakte sinnvoll? ===<br />
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 <br />
[http://www.elv.de/topic/tuer-fensterkontakt-sinn-und-unsinn.html Sinn und Unsinn von Fensterkontakten] zeigt.<br />
<br />
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. <br />
<br />
[[Datei:2013_11_02_Scanner_TSturz.png|Sturz-Temperatur-Erkennung]]<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 vermutlich mit einer WindowOpenDuration von 0 behoben werden, ausserdem ist im Hochsommer die Heizung ohnehin ausgeschaltet.<br />
<br />
Folgende Nachteile haben die Max-Fensterkontakte:<br />
* 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.<br />
* 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).<br />
<br />
=== Berücksichtigt der Scanner die Temperatur-Sturz-Erkennung? ===<br />
Wenn desiredTemperature=WindowsOpenTemperature, dann stellt der Scanner seine Arbeit ein. Ansonsten würde er durch aktive Modeumschaltung die WindowsOpenTemperature dauerhaft setzen.<br />
<br />
=== Kann der Scanner mit Fensterkontakten umgehen? ===<br />
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.<br />
<br />
Ausserdem wäre es fatal, wenn der Scanner in der Phase des offenen Fenster den Sollwert überschreiben würde. Bei offenem Fenster ist der Scanner inaktiv, er schaltet also den Modus nicht mehr um.<br />
<br />
=== Was ist denn, wenn ich noch einen zweiten Fensterkontakt habe? ===<br />
Derzeit wird nur 1 ShutterContact unterstützt. Möglicherweise wird in einer der nächsten Versionen die Funktionalität erweitert.<br />
<br />
=== Was passiert, wenn der Boost-Mode aktiviert wurde? ===<br />
Sobald dies der Scanner erkennt, stellt er seine Aktivität ein, bis wieder der Modus Auto oder Manu erscheint.<br />
<br />
=== Unterstützt der Scanner auch den MAX-ECO-Taster? ===<br />
Nein.<br />
<br />
=== Beeinflusst der Scanner den Regelmechanismus des Thermostats? ===<br />
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.<br />
<br />
== Im Kochtopf ==<br />
(realisierte Punkte der Modul-Variante sind fett ausgewiesen)<br />
<br />
* '''Scanner wird nicht mehr als Skript, sondern als Modul ausgeführt'''<br />
* '''Mindestwert für Scan-Intervall, der nicht unterschritten werden darf'''<br />
* '''Möglichkeit mehrere Fensterkontakte einem Thermostat zuzuweisen'''<br />
* Verzögerte Reaktion nach Aktivieren des Fensterkontakts<br />
* Möglichkeit eine Gruppe von Thermostaten auf Eco-Mode zu schalten (z.B. ausgelöst über ECO-Taster)<br />
* Gruppenbildung über mehrere Thermostate (für Eco-Taster)<br />
* '''Fix: wenn bei desriredtemperatur ON,OFF anstelle einer Zahl erscheint.'''<br />
<br />
== Die Modul-Variante (Beta-Version) ==<br />
<br />
Die Modul-Variante ist derzeit in der Testphase. Sie soll die die Skript-Variante mittelfristig ablösen.<br />
<br />
=== Voraussetzungen ===<br />
* Download von Modul 98_MaxScanner.pm in das Modul-Verzeichnis von FHEM<br />
* die Script-Variante sollte deaktiviert werden (alle ScanTemp-Attribute auf 0 stellen oder 99_UtilsMaxScan löschen/verschieben)<br />
* FHEM neu starten<br />
<br />
=== Inbetriebnahme ===<br />
* Scanner Modul definieren<br />
<pre><br />
define Scanner MaxScanner<br />
attr Scanner verbose 1<br />
</pre><br />
<br />
* die bestehende Max-Thermostate verfügen nun automatisch über neue Attribute, die den Scanner betreffen<br />
* alle Scanner-spezfischen Attribute beginnen immer mit "scn"<br />
* im folgende Beispiel wird das Thermostat HT.JOHN betrachtet:<br />
<pre><br />
define HT.JOHN MAX HeatingThermostat 066666<br />
</pre><br />
* das Thermostat wird für den Scanner freigegeben<br />
<pre>attr HT.JOHN scnEnabled 1</pre><br />
* wir wählen die Betriebsart Mode-Change<br />
<pre>attr HT.JOHN scnProcessByDesiChange 0</pre><br />
* wir können 0..n ShutterContacts definieren, getrennt durch Komma<br />
<pre>attr HT.JOHN scnShutterList SHUTTER.JOHN,SHUTTER.BRENNER</pre><br />
* verbose liefert ausführliche Infos im Logger<br />
<pre>attr HT.JOHN verbose 4</pre><br />
<br />
=== Attribute Thermostat===<br />
{| class="wikitable sortable"<br />
|-<br />
! Parameter !! Wertebereich !! Default !! Beschreibung<br />
|-<br />
|scnEnabled||[0,1]||0||wenn 1, wird das Thermostat vom Scanner berücksichtigt<br />
|-<br />
|scnProcessByDesiChange||[0,1]||0||wenn 1, wird das Thermostat über die Änderung von desiredTemperature (DesiredChange) getriggert, ansonsten über die Änderung des Modes (ModeChange)<br />
|-<br />
|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<br />
Thermostat geschrieben wird. Ist hingegen NOCHANGE gewählt, so wird der aktuelle am Thermostat angewählte Mode belassen.<br />
|-<br />
|scnShutterList||||||Liste von assoziierten Max-Fensterkontakten (ShutterContacts), die durch ein Komma getrennt werden. <br />
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.<br />
<br />
|}<br />
=== Attribute Scanner===<br />
{| class="wikitable sortable"<br />
|-<br />
! Parameter !! Wertebereich !! Default !! Beschreibung<br />
|-<br />
|disable||[0,1]||0|| wenn 1, dann wird der Scanner gesperrt und ist somit inaktiv.<br />
|-<br />
|scnCreditThreshold||[150..600]||300|| die Mindestanzahl von verfügbaren Credits, ab der der Scanner mit dem Triggern der Thermostate beginnt<br />
|-<br />
|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.<br />
|-<br />
|}<br />
<br />
=== Background ===<br />
<br />
==== Hilfe zur Diagnose der Abläufe ====<br />
Ein wichtiges Hilfsmittel ist der Event-Monitor. Mit der Filter-Einstellung "MAX.*" werden nur noch die MAX-relevanten Events dargestellt.<br />
<br />
Interpretation der Ausgabe:<br/><br />
<pre><br />
2016-01-06 21:24:43 MAX HT.BAD desiredTemperature auto 20.0 <-- Triggern des Thermostats durch Scanner<br />
<br />
2016-01-06 21:24:50 MAX HT.BAD mode: auto --> Rückmeldung vom Thermostat<br />
2016-01-06 21:24:50 MAX HT.BAD RSSI: -54 --> Rückmeldung vom Thermostat<br />
2016-01-06 21:24:56 MAX HT.BAD temperature: 20.2 --> Rückmeldung vom Thermostat<br />
</pre><br />
<br />
Hier erscheinen also die zu Thermostat gesendeten Informationen ebenso, wie die empfangenen.<br />
Empfangene Informationen sind meist mit einem ":" gekennzeichnet.<br />
<br />
[[Kategorie:MAX]]</div>Johnhttp://wiki.fhem.de/w/index.php?title=MAX!_Temperatur-Scanner&diff=13485MAX! Temperatur-Scanner2016-01-06T20:32:10Z<p>John: /* Common Notify */</p>
<hr />
<div>Der '''MAX! Temperatur-Scanner''' ist ein Perl-Skript, das die kontinuierliche Temperatur-Aufzeichnung<br />
von MAX-Thermostaten ermöglicht. <br />
<br />
== Features ==<br />
* kontinuierliche Erfassung von Temperatur und Ventil-Position <br />
* Berücksichtigung der System-Ressourcen (dutycycle, credits)<br />
* CUL und CUBE werden unterstützt<br />
* gleichberechtigte zeitliche Bearbeitung der Thermostate (Round-Robin-Prinzip)<br />
* Ermittlung der optimalen Scan-Rate über die Anzahl der eingebundenen Thermostate<br />
* 2 Scan-Modi stehen zur Verfügung (DesiredChange + ModeChange)<br />
<br />
== Zielsetzung des WIKI-Artikels ==<br />
Hier werden Fragen und Erkenntnisse zum Thema dargestellt, da der Forums-Eintrag für viele Anwender nicht mehr überschaubar ist.<br />
<br />
Der Artikel wird sukzessive erweitert.<br />
<br />
== Aktuelle Version ==<br />
Im Anhang zu folgendem Forumsbeitrag [http://forum.fhem.de/index.php/topic,11624.msg68237.html#msg68237 MaxScan Version 1.05c]<br />
<br />
=== Voraussetzungen ===<br />
==== Qualität der Funkverbindung ====<br />
In der Log-Datei sollten möglichst wenig Einträge der nachfolgenden Form auftreten<br />
<pre>2013.11.01 02:12:33 2: CUL_MAX_SendQueueHandler: Missing ack from 0905a5 for 0b0b0040123456xxxxxxxxx</pre><br />
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.<br />
<br />
==== Ausreichend Credits ====<br />
Der Scanner kann nicht aktiv werden, wenn gehäuft Log-Einträge der nachfolgenden Form auftreten.<br />
<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><br />
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.<br />
<br />
==== Einrichten des Thermostat-internen Wochenprogrammes ====<br />
Anders als bei den Vorgängerversionen <=1.04 ist nun ab Version 1.05 zwingend das Thermostat-interne<br />
Wochenprogramm notwendig.<br />
<br />
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.<br />
<br />
Das bei früheren Versionen eingesetzte Heating_Control kann somit entfallen.<br />
<br />
'''Bitte folgendes beachten:'''<br />
<br />
Es gibt im Zusammenhang mit dem Wochenprogramm ein Problem mit dem letzten Schaltpunkt des Tages. <br />
Der Workaround wurde [http://forum.fhem.de/index.php/topic,17231.msg112738.html#msg112738 hier]<br />
beschrieben.<br />
<br />
<big>Man muss dafür sorgen, dass man kurz vor Ende des Tages noch einen Schaltpunkt setzt.</big><br />
<br />
=== Inbetriebnahme ===<br />
* aktuell freigegebene Version von 99_UtilsMaxScan.pm in das Verzeichnis /opt/fhem/FHEM kopieren.<br />
* Bei den Thermostaten, die gescannt werden sollen, das Attribut scanTemp setzen via<br />
<pre>attr VT_HW scanTemp 1</pre><br />
* das Wochenprogramm im Thermostat nach den Bedürfnissen einstellen<br />
* auf''' keinen''' Fall das Attribut keepAuto setzen<br />
* mit dem userReading "onlyAutoMode" kann der Scan-Modus ModeChange festgelegt werden<br />
<pre>attr HT.JOHN userReadings onlyAutoMode { return "1";;}</pre> <br />
* ist ein ShutterContact mit dem Thermostat assoziiert, dann muss man dies bekannt machen mit dem UserReading<br />
<pre>attr VT_HW userReadings watchShutter { return "SHUTTER.HW";;}</pre><br />
* '''FHEM neu starten'''<br />
<br />
'''Hinweis'''<br /><br />
Je kleiner der Wert von Attribut verbose, umso weniger Ausgaben erhält man in der Log-Datei.<br />
<br />
== Mechanismen ==<br />
=== Das Problem ===<br />
Der Hersteller der MAX-Thermostate hat diese so konzipiert, dass die gemessene Temperatur und Ventilstellung nur übertragen werden, wenn sich Folgendes ändert:<br />
* die Ventilstellung<br />
* die Betriebsart (mode: auto,manu,temporary,boost)<br />
* der Sollwert<br />
<br />
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.<br />
<br />
=== Der Lösungsansatz ===<br />
==== Triggerung per Mode-Umschaltung (ModeChange) ====<br />
Dies ist der Default-Mode des Scanners.<br />
Hier wird der Ansatz verfolgt, die Betriebsart des Thermostats regelmässig umzuschalten via<br />
:AUTO ==> MANU<br />
<Wartezeit mindestens 3 Minuten><br />
:MANU ==> AUTO<br />
<br />
Dies veranlasst das Thermostat, regelmässig die gewünschten Werte an FHEM (den gepaarten Transceiver) zu senden.<br />
<br />
==== Triggerung per Sollwert-Umschaltung (DesiredChange) ====<br />
Durch Änderung des Sollwertes kann ebenso die Übertragung des Istwertes am Thermostat initiiert werden.<br />
<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.<br />
<br />
Dieser Modus wird durch die Definition des UserReadings "onlyAutoMode" festgelegt.<br />
:<code>attr HT.JOHN userReadings onlyAutoMode { return "1";;}</code><br />
<br />
'''Beispiel:'''<br />
<br />
Sollwert im Thermostat nach Wochenprofil: 18<br />
Fall A:<br />
----<br />
* Istwert 17<br />
* Sollwert A von Scanner gesetzt : 18.5<br />
* Sollwert B von Scanner gesetzt : 18.0<br />
* Der Scanner wechselt also von 18 auf 18.5 und zurück.<br />
<br />
Fall B:<br />
----<br />
* Istwert 19<br />
* Sollwert A von Scanner gesetzt : 17.5<br />
* Sollwert B von Scanner gesetzt : 18.0<br />
* Der Scanner wechselt also von 18 auf 17.5 und zurück.<br />
<br />
=== Ergebnis ===<br />
==== ohne Scanner ====<br />
[[Datei:2013_12_MaxScanner_Vorher.png|ohne Scanner]]<br />
<br />
==== mit Scanner (ScanMode=ModeChange) ====<br />
[[Datei:13_12_01_Scanner_ModeChange.png|mit Scanner]]<br />
<br />
==== mit Scanner (ScanMode=DesiredChange) ====<br />
[[Datei:13_12_01_Scanner_DesiredChange.png|mit Scanner]]<br />
<br />
=== Ressourcen ===<br />
Die Sendezeit jedes Teilnehmers ist auf 1% begrenzt.<br />
<br />
Konkret bedeutet dies, dass ein CUL ca. 33 Telegramme pro Stunde senden kann.<br />
Der MAX-Scanner darf nicht alle Ressourcen für sich beanspruchen, sondern sieht seine Aufgabe als nachrangig. <br />
<br />
Erst wenn mehr als 300 Credits (von max. 900 möglichen) zur Verfügung stehen, wird das Skript aktiv.<br />
<br />
== Fragen und Antworten ==<br />
=== Welchen ScanMode soll ich wählen? ===<br />
Nachfolgende Punkte können als Entscheidungskriterium dienen:<br />
<br />
'''ModeChange'''<br />
* keine Änderung des Sollwertes nötig<br />
* damit ist das Ventil "ruhiger", da sich die Regeldifferenz nicht durch den Scanner-Betrieb ändert.<br />
<br />
'''DesiredChange'''<br />
* der Auto-Modus wird niemals verlassen<br />
* Falls FHEM ausfällt, wird das Thermostat das gespeicherte Wochenprogramm nutzen<br />
<br />
=== Wie kann man den ScanMode nachträglich ändern? ===<br />
Man kann das userReading ändern, so dass es 0 liefert<br />
:<code>attr HT.JOHN userReadings onlyAutoMode { return "0";;}</code><br />
<br />
oder man löscht das userReading durch<br />
* Löschen aus dem attribut userReading<br />
* und Löschen des vorhandenen userReadings via<br />
:<code>deletereading HT.JOHN onlyAutoMode </code><br />
<br />
=== Was passiert, wenn der Sollwert am Thermostat manuell verstellt wird? ===<br />
Wenn der Sollwert manuell am Thermostat verändert wird, kann es bis zu 3 Minuten dauern, bis dieser an FHEM gemeldet wird.<br />
<br />
Wenn der Scanner in dieser Wartezeit aktiv wird, wird er den soeben geänderten Sollwert überschreiben. In diesem Fall bliebe die manuelle Änderung wirkungslos.<br />
<br />
Wird die manuelle Änderung des Sollwertes vom Scanner erkannt, so gilt dieser bis zum nächsten Schaltpunkt des internen Wochenprogrammes.<br />
<br />
=== Mehrere Thermostate in einer Gruppe? ===<br />
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.<br />
<br />
=== Was ist zu tun wenn, Thermostate zusammen mit einem Wandthermostat eingesetzt werden? ===<br />
In diesem Fall ist der Scanner überflüssig, da das Wandthermostat ohnehin eine detaillierte Kurve des Istwertes liefert.<br />
<br />
=== Sind Fensterkontakte sinnvoll? ===<br />
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 <br />
[http://www.elv.de/topic/tuer-fensterkontakt-sinn-und-unsinn.html Sinn und Unsinn von Fensterkontakten] zeigt.<br />
<br />
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. <br />
<br />
[[Datei:2013_11_02_Scanner_TSturz.png|Sturz-Temperatur-Erkennung]]<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 vermutlich mit einer WindowOpenDuration von 0 behoben werden, ausserdem ist im Hochsommer die Heizung ohnehin ausgeschaltet.<br />
<br />
Folgende Nachteile haben die Max-Fensterkontakte:<br />
* 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.<br />
* 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).<br />
<br />
=== Berücksichtigt der Scanner die Temperatur-Sturz-Erkennung? ===<br />
Wenn desiredTemperature=WindowsOpenTemperature, dann stellt der Scanner seine Arbeit ein. Ansonsten würde er durch aktive Modeumschaltung die WindowsOpenTemperature dauerhaft setzen.<br />
<br />
=== Kann der Scanner mit Fensterkontakten umgehen? ===<br />
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.<br />
<br />
Ausserdem wäre es fatal, wenn der Scanner in der Phase des offenen Fenster den Sollwert überschreiben würde. Bei offenem Fenster ist der Scanner inaktiv, er schaltet also den Modus nicht mehr um.<br />
<br />
=== Was ist denn, wenn ich noch einen zweiten Fensterkontakt habe? ===<br />
Derzeit wird nur 1 ShutterContact unterstützt. Möglicherweise wird in einer der nächsten Versionen die Funktionalität erweitert.<br />
<br />
=== Was passiert, wenn der Boost-Mode aktiviert wurde? ===<br />
Sobald dies der Scanner erkennt, stellt er seine Aktivität ein, bis wieder der Modus Auto oder Manu erscheint.<br />
<br />
=== Unterstützt der Scanner auch den MAX-ECO-Taster? ===<br />
Nein.<br />
<br />
=== Beeinflusst der Scanner den Regelmechanismus des Thermostats? ===<br />
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.<br />
<br />
== Im Kochtopf ==<br />
(realisierte Punkte der Modul-Variante sind fett ausgewiesen)<br />
<br />
* '''Scanner wird nicht mehr als Skript, sondern als Modul ausgeführt'''<br />
* '''Mindestwert für Scan-Intervall, der nicht unterschritten werden darf'''<br />
* '''Möglichkeit mehrere Fensterkontakte einem Thermostat zuzuweisen'''<br />
* Verzögerte Reaktion nach Aktivieren des Fensterkontakts<br />
* Möglichkeit eine Gruppe von Thermostaten auf Eco-Mode zu schalten (z.B. ausgelöst über ECO-Taster)<br />
* Gruppenbildung über mehrere Thermostate (für Eco-Taster)<br />
* '''Fix: wenn bei desriredtemperatur ON,OFF anstelle einer Zahl erscheint.'''<br />
<br />
== Die Modul-Variante (Beta-Version) ==<br />
<br />
Die Modul-Variante ist derzeit in der Testphase. Sie soll die die Skript-Variante mittelfristig ablösen.<br />
<br />
=== Voraussetzungen ===<br />
* Download von Modul 98_MaxScanner.pm in das Modul-Verzeichnis von FHEM<br />
* die Script-Variante sollte deaktiviert werden (alle ScanTemp-Attribute auf 0 stellen oder 99_UtilsMaxScan löschen/verschieben)<br />
* FHEM neu starten<br />
<br />
=== Inbetriebnahme ===<br />
* Scanner Modul definieren<br />
<pre><br />
define Scanner MaxScanner<br />
attr Scanner verbose 1<br />
</pre><br />
<br />
* die bestehende Max-Thermostate verfügen nun automatisch über neue Attribute, die den Scanner betreffen<br />
* alle Scanner-spezfischen Attribute beginnen immer mit "scn"<br />
* im folgende Beispiel wird das Thermostat HT.JOHN betrachtet:<br />
<pre><br />
define HT.JOHN MAX HeatingThermostat 066666<br />
</pre><br />
* das Thermostat wird für den Scanner freigegeben<br />
<pre>attr HT.JOHN scnEnabled 1</pre><br />
* wir wählen die Betriebsart Mode-Change<br />
<pre>attr HT.JOHN scnProcessByDesiChange 0</pre><br />
* wir können 0..n ShutterContacts definieren, getrennt durch Komma<br />
<pre>attr HT.JOHN scnShutterList SHUTTER.JOHN,SHUTTER.BRENNER</pre><br />
* verbose liefert ausführliche Infos im Logger<br />
<pre>attr HT.JOHN verbose 4</pre><br />
<br />
=== Attribute Thermostat===<br />
{| class="wikitable sortable"<br />
|-<br />
! Parameter !! Wertebereich !! Default !! Beschreibung<br />
|-<br />
|scnEnabled||[0,1]||0||wenn 1, wird das Thermostat vom Scanner berücksichtigt<br />
|-<br />
|scnProcessByDesiChange||[0,1]||0||wenn 1, wird das Thermostat über die Änderung von desiredTemperature (DesiredChange) getriggert, ansonsten über die Änderung des Modes (ModeChange)<br />
|-<br />
|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<br />
Thermostat geschrieben wird. Ist hingegen NOCHANGE gewählt, so wird der aktuelle am Thermostat angewählte Mode belassen.<br />
|-<br />
|scnShutterList||||||Liste von assoziierten Max-Fensterkontakten (ShutterContacts), die durch ein Komma getrennt werden. <br />
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.<br />
<br />
|}<br />
=== Attribute Scanner===<br />
{| class="wikitable sortable"<br />
|-<br />
! Parameter !! Wertebereich !! Default !! Beschreibung<br />
|-<br />
|disable||[0,1]||0|| wenn 1, dann wird der Scanner gesperrt und ist somit inaktiv.<br />
|-<br />
|scnCreditThreshold||[150..600]||300|| die Mindestanzahl von verfügbaren Credits, ab der der Scanner mit dem Triggern der Thermostate beginnt<br />
|-<br />
|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.<br />
|-<br />
|}<br />
<br />
=== Background ===<br />
<br />
==== Common Notify ====<br />
Der Scanner erzeugt automatisch ein Notify MAXSCANNER.COMMON.EVENT. Dieses ist im Bereich "Unsorted" zu finden.<br/><br/><br />
Hier werden alle für den Scanner wichtigen Events gefiltert, so daß dieser auf Änderungen umgehend reagieren kann.<br/><br />
Das Notify wird beim Neustart von FHEM oder bei Ausführen des set Befehls "Initialize" erzeugt, aber nur dann, wenn das Notify<br />
noch nicht existiert oder es aufgrund neuer Gegebenheiten (ShutterContact, Thermostat) zu ändern ist.<br />
<br />
==== Hilfe zur Diagnose der Abläufe ====<br />
Ein wichtiges Hilfsmittel ist der Event-Monitor. Mit der Filter-Einstellung "MAX.*" werden nur noch die MAX-relevanten Events dargestellt.<br />
<br />
Interpretation der Ausgabe:<br/><br />
<pre><br />
2016-01-06 21:24:43 MAX HT.BAD desiredTemperature auto 20.0 <-- Triggern des Thermostats durch Scanner<br />
<br />
2016-01-06 21:24:50 MAX HT.BAD mode: auto --> Rückmeldung vom Thermostat<br />
2016-01-06 21:24:50 MAX HT.BAD RSSI: -54 --> Rückmeldung vom Thermostat<br />
2016-01-06 21:24:56 MAX HT.BAD temperature: 20.2 --> Rückmeldung vom Thermostat<br />
</pre><br />
<br />
Hier erscheinen also die zu Thermostat gesendeten Informationen ebenso, wie die empfangenen.<br />
Empfangene Informationen sind meist mit einem ":" gekennzeichnet.<br />
<br />
[[Kategorie:MAX]]</div>Johnhttp://wiki.fhem.de/w/index.php?title=MAX!_Temperatur-Scanner&diff=13481MAX! Temperatur-Scanner2016-01-06T20:10:56Z<p>John: /* Common Notify */</p>
<hr />
<div>Der '''MAX! Temperatur-Scanner''' ist ein Perl-Skript, das die kontinuierliche Temperatur-Aufzeichnung<br />
von MAX-Thermostaten ermöglicht. <br />
<br />
== Features ==<br />
* kontinuierliche Erfassung von Temperatur und Ventil-Position <br />
* Berücksichtigung der System-Ressourcen (dutycycle, credits)<br />
* CUL und CUBE werden unterstützt<br />
* gleichberechtigte zeitliche Bearbeitung der Thermostate (Round-Robin-Prinzip)<br />
* Ermittlung der optimalen Scan-Rate über die Anzahl der eingebundenen Thermostate<br />
* 2 Scan-Modi stehen zur Verfügung (DesiredChange + ModeChange)<br />
<br />
== Zielsetzung des WIKI-Artikels ==<br />
Hier werden Fragen und Erkenntnisse zum Thema dargestellt, da der Forums-Eintrag für viele Anwender nicht mehr überschaubar ist.<br />
<br />
Der Artikel wird sukzessive erweitert.<br />
<br />
== Aktuelle Version ==<br />
Im Anhang zu folgendem Forumsbeitrag [http://forum.fhem.de/index.php/topic,11624.msg68237.html#msg68237 MaxScan Version 1.05c]<br />
<br />
=== Voraussetzungen ===<br />
==== Qualität der Funkverbindung ====<br />
In der Log-Datei sollten möglichst wenig Einträge der nachfolgenden Form auftreten<br />
<pre>2013.11.01 02:12:33 2: CUL_MAX_SendQueueHandler: Missing ack from 0905a5 for 0b0b0040123456xxxxxxxxx</pre><br />
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.<br />
<br />
==== Ausreichend Credits ====<br />
Der Scanner kann nicht aktiv werden, wenn gehäuft Log-Einträge der nachfolgenden Form auftreten.<br />
<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><br />
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.<br />
<br />
==== Einrichten des Thermostat-internen Wochenprogrammes ====<br />
Anders als bei den Vorgängerversionen <=1.04 ist nun ab Version 1.05 zwingend das Thermostat-interne<br />
Wochenprogramm notwendig.<br />
<br />
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.<br />
<br />
Das bei früheren Versionen eingesetzte Heating_Control kann somit entfallen.<br />
<br />
'''Bitte folgendes beachten:'''<br />
<br />
Es gibt im Zusammenhang mit dem Wochenprogramm ein Problem mit dem letzten Schaltpunkt des Tages. <br />
Der Workaround wurde [http://forum.fhem.de/index.php/topic,17231.msg112738.html#msg112738 hier]<br />
beschrieben.<br />
<br />
<big>Man muss dafür sorgen, dass man kurz vor Ende des Tages noch einen Schaltpunkt setzt.</big><br />
<br />
=== Inbetriebnahme ===<br />
* aktuell freigegebene Version von 99_UtilsMaxScan.pm in das Verzeichnis /opt/fhem/FHEM kopieren.<br />
* Bei den Thermostaten, die gescannt werden sollen, das Attribut scanTemp setzen via<br />
<pre>attr VT_HW scanTemp 1</pre><br />
* das Wochenprogramm im Thermostat nach den Bedürfnissen einstellen<br />
* auf''' keinen''' Fall das Attribut keepAuto setzen<br />
* mit dem userReading "onlyAutoMode" kann der Scan-Modus ModeChange festgelegt werden<br />
<pre>attr HT.JOHN userReadings onlyAutoMode { return "1";;}</pre> <br />
* ist ein ShutterContact mit dem Thermostat assoziiert, dann muss man dies bekannt machen mit dem UserReading<br />
<pre>attr VT_HW userReadings watchShutter { return "SHUTTER.HW";;}</pre><br />
* '''FHEM neu starten'''<br />
<br />
'''Hinweis'''<br /><br />
Je kleiner der Wert von Attribut verbose, umso weniger Ausgaben erhält man in der Log-Datei.<br />
<br />
== Mechanismen ==<br />
=== Das Problem ===<br />
Der Hersteller der MAX-Thermostate hat diese so konzipiert, dass die gemessene Temperatur und Ventilstellung nur übertragen werden, wenn sich Folgendes ändert:<br />
* die Ventilstellung<br />
* die Betriebsart (mode: auto,manu,temporary,boost)<br />
* der Sollwert<br />
<br />
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.<br />
<br />
=== Der Lösungsansatz ===<br />
==== Triggerung per Mode-Umschaltung (ModeChange) ====<br />
Dies ist der Default-Mode des Scanners.<br />
Hier wird der Ansatz verfolgt, die Betriebsart des Thermostats regelmässig umzuschalten via<br />
:AUTO ==> MANU<br />
<Wartezeit mindestens 3 Minuten><br />
:MANU ==> AUTO<br />
<br />
Dies veranlasst das Thermostat, regelmässig die gewünschten Werte an FHEM (den gepaarten Transceiver) zu senden.<br />
<br />
==== Triggerung per Sollwert-Umschaltung (DesiredChange) ====<br />
Durch Änderung des Sollwertes kann ebenso die Übertragung des Istwertes am Thermostat initiiert werden.<br />
<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.<br />
<br />
Dieser Modus wird durch die Definition des UserReadings "onlyAutoMode" festgelegt.<br />
:<code>attr HT.JOHN userReadings onlyAutoMode { return "1";;}</code><br />
<br />
'''Beispiel:'''<br />
<br />
Sollwert im Thermostat nach Wochenprofil: 18<br />
Fall A:<br />
----<br />
* Istwert 17<br />
* Sollwert A von Scanner gesetzt : 18.5<br />
* Sollwert B von Scanner gesetzt : 18.0<br />
* Der Scanner wechselt also von 18 auf 18.5 und zurück.<br />
<br />
Fall B:<br />
----<br />
* Istwert 19<br />
* Sollwert A von Scanner gesetzt : 17.5<br />
* Sollwert B von Scanner gesetzt : 18.0<br />
* Der Scanner wechselt also von 18 auf 17.5 und zurück.<br />
<br />
=== Ergebnis ===<br />
==== ohne Scanner ====<br />
[[Datei:2013_12_MaxScanner_Vorher.png|ohne Scanner]]<br />
<br />
==== mit Scanner (ScanMode=ModeChange) ====<br />
[[Datei:13_12_01_Scanner_ModeChange.png|mit Scanner]]<br />
<br />
==== mit Scanner (ScanMode=DesiredChange) ====<br />
[[Datei:13_12_01_Scanner_DesiredChange.png|mit Scanner]]<br />
<br />
=== Ressourcen ===<br />
Die Sendezeit jedes Teilnehmers ist auf 1% begrenzt.<br />
<br />
Konkret bedeutet dies, dass ein CUL ca. 33 Telegramme pro Stunde senden kann.<br />
Der MAX-Scanner darf nicht alle Ressourcen für sich beanspruchen, sondern sieht seine Aufgabe als nachrangig. <br />
<br />
Erst wenn mehr als 300 Credits (von max. 900 möglichen) zur Verfügung stehen, wird das Skript aktiv.<br />
<br />
== Fragen und Antworten ==<br />
=== Welchen ScanMode soll ich wählen? ===<br />
Nachfolgende Punkte können als Entscheidungskriterium dienen:<br />
<br />
'''ModeChange'''<br />
* keine Änderung des Sollwertes nötig<br />
* damit ist das Ventil "ruhiger", da sich die Regeldifferenz nicht durch den Scanner-Betrieb ändert.<br />
<br />
'''DesiredChange'''<br />
* der Auto-Modus wird niemals verlassen<br />
* Falls FHEM ausfällt, wird das Thermostat das gespeicherte Wochenprogramm nutzen<br />
<br />
=== Wie kann man den ScanMode nachträglich ändern? ===<br />
Man kann das userReading ändern, so dass es 0 liefert<br />
:<code>attr HT.JOHN userReadings onlyAutoMode { return "0";;}</code><br />
<br />
oder man löscht das userReading durch<br />
* Löschen aus dem attribut userReading<br />
* und Löschen des vorhandenen userReadings via<br />
:<code>deletereading HT.JOHN onlyAutoMode </code><br />
<br />
=== Was passiert, wenn der Sollwert am Thermostat manuell verstellt wird? ===<br />
Wenn der Sollwert manuell am Thermostat verändert wird, kann es bis zu 3 Minuten dauern, bis dieser an FHEM gemeldet wird.<br />
<br />
Wenn der Scanner in dieser Wartezeit aktiv wird, wird er den soeben geänderten Sollwert überschreiben. In diesem Fall bliebe die manuelle Änderung wirkungslos.<br />
<br />
Wird die manuelle Änderung des Sollwertes vom Scanner erkannt, so gilt dieser bis zum nächsten Schaltpunkt des internen Wochenprogrammes.<br />
<br />
=== Mehrere Thermostate in einer Gruppe? ===<br />
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.<br />
<br />
=== Was ist zu tun wenn, Thermostate zusammen mit einem Wandthermostat eingesetzt werden? ===<br />
In diesem Fall ist der Scanner überflüssig, da das Wandthermostat ohnehin eine detaillierte Kurve des Istwertes liefert.<br />
<br />
=== Sind Fensterkontakte sinnvoll? ===<br />
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 <br />
[http://www.elv.de/topic/tuer-fensterkontakt-sinn-und-unsinn.html Sinn und Unsinn von Fensterkontakten] zeigt.<br />
<br />
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. <br />
<br />
[[Datei:2013_11_02_Scanner_TSturz.png|Sturz-Temperatur-Erkennung]]<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 vermutlich mit einer WindowOpenDuration von 0 behoben werden, ausserdem ist im Hochsommer die Heizung ohnehin ausgeschaltet.<br />
<br />
Folgende Nachteile haben die Max-Fensterkontakte:<br />
* 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.<br />
* 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).<br />
<br />
=== Berücksichtigt der Scanner die Temperatur-Sturz-Erkennung? ===<br />
Wenn desiredTemperature=WindowsOpenTemperature, dann stellt der Scanner seine Arbeit ein. Ansonsten würde er durch aktive Modeumschaltung die WindowsOpenTemperature dauerhaft setzen.<br />
<br />
=== Kann der Scanner mit Fensterkontakten umgehen? ===<br />
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.<br />
<br />
Ausserdem wäre es fatal, wenn der Scanner in der Phase des offenen Fenster den Sollwert überschreiben würde. Bei offenem Fenster ist der Scanner inaktiv, er schaltet also den Modus nicht mehr um.<br />
<br />
=== Was ist denn, wenn ich noch einen zweiten Fensterkontakt habe? ===<br />
Derzeit wird nur 1 ShutterContact unterstützt. Möglicherweise wird in einer der nächsten Versionen die Funktionalität erweitert.<br />
<br />
=== Was passiert, wenn der Boost-Mode aktiviert wurde? ===<br />
Sobald dies der Scanner erkennt, stellt er seine Aktivität ein, bis wieder der Modus Auto oder Manu erscheint.<br />
<br />
=== Unterstützt der Scanner auch den MAX-ECO-Taster? ===<br />
Nein.<br />
<br />
=== Beeinflusst der Scanner den Regelmechanismus des Thermostats? ===<br />
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.<br />
<br />
== Im Kochtopf ==<br />
(realisierte Punkte der Modul-Variante sind fett ausgewiesen)<br />
<br />
* '''Scanner wird nicht mehr als Skript, sondern als Modul ausgeführt'''<br />
* '''Mindestwert für Scan-Intervall, der nicht unterschritten werden darf'''<br />
* '''Möglichkeit mehrere Fensterkontakte einem Thermostat zuzuweisen'''<br />
* Verzögerte Reaktion nach Aktivieren des Fensterkontakts<br />
* Möglichkeit eine Gruppe von Thermostaten auf Eco-Mode zu schalten (z.B. ausgelöst über ECO-Taster)<br />
* Gruppenbildung über mehrere Thermostate (für Eco-Taster)<br />
* '''Fix: wenn bei desriredtemperatur ON,OFF anstelle einer Zahl erscheint.'''<br />
<br />
== Die Modul-Variante (Beta-Version) ==<br />
<br />
Die Modul-Variante ist derzeit in der Testphase. Sie soll die die Skript-Variante mittelfristig ablösen.<br />
<br />
=== Voraussetzungen ===<br />
* Download von Modul 98_MaxScanner.pm in das Modul-Verzeichnis von FHEM<br />
* die Script-Variante sollte deaktiviert werden (alle ScanTemp-Attribute auf 0 stellen oder 99_UtilsMaxScan löschen/verschieben)<br />
* FHEM neu starten<br />
<br />
=== Inbetriebnahme ===<br />
* Scanner Modul definieren<br />
<pre><br />
define Scanner MaxScanner<br />
attr Scanner verbose 1<br />
</pre><br />
<br />
* die bestehende Max-Thermostate verfügen nun automatisch über neue Attribute, die den Scanner betreffen<br />
* alle Scanner-spezfischen Attribute beginnen immer mit "scn"<br />
* im folgende Beispiel wird das Thermostat HT.JOHN betrachtet:<br />
<pre><br />
define HT.JOHN MAX HeatingThermostat 066666<br />
</pre><br />
* das Thermostat wird für den Scanner freigegeben<br />
<pre>attr HT.JOHN scnEnabled 1</pre><br />
* wir wählen die Betriebsart Mode-Change<br />
<pre>attr HT.JOHN scnProcessByDesiChange 0</pre><br />
* wir können 0..n ShutterContacts definieren, getrennt durch Komma<br />
<pre>attr HT.JOHN scnShutterList SHUTTER.JOHN,SHUTTER.BRENNER</pre><br />
* verbose liefert ausführliche Infos im Logger<br />
<pre>attr HT.JOHN verbose 4</pre><br />
<br />
=== Attribute Thermostat===<br />
{| class="wikitable sortable"<br />
|-<br />
! Parameter !! Wertebereich !! Default !! Beschreibung<br />
|-<br />
|scnEnabled||[0,1]||0||wenn 1, wird das Thermostat vom Scanner berücksichtigt<br />
|-<br />
|scnProcessByDesiChange||[0,1]||0||wenn 1, wird das Thermostat über die Änderung von desiredTemperature (DesiredChange) getriggert, ansonsten über die Änderung des Modes (ModeChange)<br />
|-<br />
|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<br />
Thermostat geschrieben wird. Ist hingegen NOCHANGE gewählt, so wird der aktuelle am Thermostat angewählte Mode belassen.<br />
|-<br />
|scnShutterList||||||Liste von assoziierten Max-Fensterkontakten (ShutterContacts), die durch ein Komma getrennt werden. <br />
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.<br />
<br />
|}<br />
=== Attribute Scanner===<br />
{| class="wikitable sortable"<br />
|-<br />
! Parameter !! Wertebereich !! Default !! Beschreibung<br />
|-<br />
|disable||[0,1]||0|| wenn 1, dann wird der Scanner gesperrt und ist somit inaktiv.<br />
|-<br />
|scnCreditThreshold||[150..600]||300|| die Mindestanzahl von verfügbaren Credits, ab der der Scanner mit dem Triggern der Thermostate beginnt<br />
|-<br />
|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.<br />
|-<br />
|}<br />
<br />
=== Background ===<br />
<br />
==== Common Notify ====<br />
Der Scanner erzeugt automatisch ein Notify MAXSCANNER.COMMON.EVENT. Dieses ist im Bereich "Unsorted" zu finden.<br/><br/><br />
Hier werden alle für den Scanner wichtigen Events gefiltert, so daß dieser auf Änderungen umgehend reagieren kann.<br/><br />
Das Notify wird beim Neustart von FHEM oder bei Ausführen des set Befehls "Initialize" erzeugt, aber nur dann, wenn das Notify<br />
noch nicht existiert oder es aufgrund neuer Gegebenheiten (ShutterContact, Thermostat) zu ändern ist.<br />
<br />
<br />
<br />
[[Kategorie:MAX]]</div>Johnhttp://wiki.fhem.de/w/index.php?title=MAX!_Temperatur-Scanner&diff=13479MAX! Temperatur-Scanner2016-01-06T20:04:38Z<p>John: /* Background */</p>
<hr />
<div>Der '''MAX! Temperatur-Scanner''' ist ein Perl-Skript, das die kontinuierliche Temperatur-Aufzeichnung<br />
von MAX-Thermostaten ermöglicht. <br />
<br />
== Features ==<br />
* kontinuierliche Erfassung von Temperatur und Ventil-Position <br />
* Berücksichtigung der System-Ressourcen (dutycycle, credits)<br />
* CUL und CUBE werden unterstützt<br />
* gleichberechtigte zeitliche Bearbeitung der Thermostate (Round-Robin-Prinzip)<br />
* Ermittlung der optimalen Scan-Rate über die Anzahl der eingebundenen Thermostate<br />
* 2 Scan-Modi stehen zur Verfügung (DesiredChange + ModeChange)<br />
<br />
== Zielsetzung des WIKI-Artikels ==<br />
Hier werden Fragen und Erkenntnisse zum Thema dargestellt, da der Forums-Eintrag für viele Anwender nicht mehr überschaubar ist.<br />
<br />
Der Artikel wird sukzessive erweitert.<br />
<br />
== Aktuelle Version ==<br />
Im Anhang zu folgendem Forumsbeitrag [http://forum.fhem.de/index.php/topic,11624.msg68237.html#msg68237 MaxScan Version 1.05c]<br />
<br />
=== Voraussetzungen ===<br />
==== Qualität der Funkverbindung ====<br />
In der Log-Datei sollten möglichst wenig Einträge der nachfolgenden Form auftreten<br />
<pre>2013.11.01 02:12:33 2: CUL_MAX_SendQueueHandler: Missing ack from 0905a5 for 0b0b0040123456xxxxxxxxx</pre><br />
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.<br />
<br />
==== Ausreichend Credits ====<br />
Der Scanner kann nicht aktiv werden, wenn gehäuft Log-Einträge der nachfolgenden Form auftreten.<br />
<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><br />
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.<br />
<br />
==== Einrichten des Thermostat-internen Wochenprogrammes ====<br />
Anders als bei den Vorgängerversionen <=1.04 ist nun ab Version 1.05 zwingend das Thermostat-interne<br />
Wochenprogramm notwendig.<br />
<br />
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.<br />
<br />
Das bei früheren Versionen eingesetzte Heating_Control kann somit entfallen.<br />
<br />
'''Bitte folgendes beachten:'''<br />
<br />
Es gibt im Zusammenhang mit dem Wochenprogramm ein Problem mit dem letzten Schaltpunkt des Tages. <br />
Der Workaround wurde [http://forum.fhem.de/index.php/topic,17231.msg112738.html#msg112738 hier]<br />
beschrieben.<br />
<br />
<big>Man muss dafür sorgen, dass man kurz vor Ende des Tages noch einen Schaltpunkt setzt.</big><br />
<br />
=== Inbetriebnahme ===<br />
* aktuell freigegebene Version von 99_UtilsMaxScan.pm in das Verzeichnis /opt/fhem/FHEM kopieren.<br />
* Bei den Thermostaten, die gescannt werden sollen, das Attribut scanTemp setzen via<br />
<pre>attr VT_HW scanTemp 1</pre><br />
* das Wochenprogramm im Thermostat nach den Bedürfnissen einstellen<br />
* auf''' keinen''' Fall das Attribut keepAuto setzen<br />
* mit dem userReading "onlyAutoMode" kann der Scan-Modus ModeChange festgelegt werden<br />
<pre>attr HT.JOHN userReadings onlyAutoMode { return "1";;}</pre> <br />
* ist ein ShutterContact mit dem Thermostat assoziiert, dann muss man dies bekannt machen mit dem UserReading<br />
<pre>attr VT_HW userReadings watchShutter { return "SHUTTER.HW";;}</pre><br />
* '''FHEM neu starten'''<br />
<br />
'''Hinweis'''<br /><br />
Je kleiner der Wert von Attribut verbose, umso weniger Ausgaben erhält man in der Log-Datei.<br />
<br />
== Mechanismen ==<br />
=== Das Problem ===<br />
Der Hersteller der MAX-Thermostate hat diese so konzipiert, dass die gemessene Temperatur und Ventilstellung nur übertragen werden, wenn sich Folgendes ändert:<br />
* die Ventilstellung<br />
* die Betriebsart (mode: auto,manu,temporary,boost)<br />
* der Sollwert<br />
<br />
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.<br />
<br />
=== Der Lösungsansatz ===<br />
==== Triggerung per Mode-Umschaltung (ModeChange) ====<br />
Dies ist der Default-Mode des Scanners.<br />
Hier wird der Ansatz verfolgt, die Betriebsart des Thermostats regelmässig umzuschalten via<br />
:AUTO ==> MANU<br />
<Wartezeit mindestens 3 Minuten><br />
:MANU ==> AUTO<br />
<br />
Dies veranlasst das Thermostat, regelmässig die gewünschten Werte an FHEM (den gepaarten Transceiver) zu senden.<br />
<br />
==== Triggerung per Sollwert-Umschaltung (DesiredChange) ====<br />
Durch Änderung des Sollwertes kann ebenso die Übertragung des Istwertes am Thermostat initiiert werden.<br />
<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.<br />
<br />
Dieser Modus wird durch die Definition des UserReadings "onlyAutoMode" festgelegt.<br />
:<code>attr HT.JOHN userReadings onlyAutoMode { return "1";;}</code><br />
<br />
'''Beispiel:'''<br />
<br />
Sollwert im Thermostat nach Wochenprofil: 18<br />
Fall A:<br />
----<br />
* Istwert 17<br />
* Sollwert A von Scanner gesetzt : 18.5<br />
* Sollwert B von Scanner gesetzt : 18.0<br />
* Der Scanner wechselt also von 18 auf 18.5 und zurück.<br />
<br />
Fall B:<br />
----<br />
* Istwert 19<br />
* Sollwert A von Scanner gesetzt : 17.5<br />
* Sollwert B von Scanner gesetzt : 18.0<br />
* Der Scanner wechselt also von 18 auf 17.5 und zurück.<br />
<br />
=== Ergebnis ===<br />
==== ohne Scanner ====<br />
[[Datei:2013_12_MaxScanner_Vorher.png|ohne Scanner]]<br />
<br />
==== mit Scanner (ScanMode=ModeChange) ====<br />
[[Datei:13_12_01_Scanner_ModeChange.png|mit Scanner]]<br />
<br />
==== mit Scanner (ScanMode=DesiredChange) ====<br />
[[Datei:13_12_01_Scanner_DesiredChange.png|mit Scanner]]<br />
<br />
=== Ressourcen ===<br />
Die Sendezeit jedes Teilnehmers ist auf 1% begrenzt.<br />
<br />
Konkret bedeutet dies, dass ein CUL ca. 33 Telegramme pro Stunde senden kann.<br />
Der MAX-Scanner darf nicht alle Ressourcen für sich beanspruchen, sondern sieht seine Aufgabe als nachrangig. <br />
<br />
Erst wenn mehr als 300 Credits (von max. 900 möglichen) zur Verfügung stehen, wird das Skript aktiv.<br />
<br />
== Fragen und Antworten ==<br />
=== Welchen ScanMode soll ich wählen? ===<br />
Nachfolgende Punkte können als Entscheidungskriterium dienen:<br />
<br />
'''ModeChange'''<br />
* keine Änderung des Sollwertes nötig<br />
* damit ist das Ventil "ruhiger", da sich die Regeldifferenz nicht durch den Scanner-Betrieb ändert.<br />
<br />
'''DesiredChange'''<br />
* der Auto-Modus wird niemals verlassen<br />
* Falls FHEM ausfällt, wird das Thermostat das gespeicherte Wochenprogramm nutzen<br />
<br />
=== Wie kann man den ScanMode nachträglich ändern? ===<br />
Man kann das userReading ändern, so dass es 0 liefert<br />
:<code>attr HT.JOHN userReadings onlyAutoMode { return "0";;}</code><br />
<br />
oder man löscht das userReading durch<br />
* Löschen aus dem attribut userReading<br />
* und Löschen des vorhandenen userReadings via<br />
:<code>deletereading HT.JOHN onlyAutoMode </code><br />
<br />
=== Was passiert, wenn der Sollwert am Thermostat manuell verstellt wird? ===<br />
Wenn der Sollwert manuell am Thermostat verändert wird, kann es bis zu 3 Minuten dauern, bis dieser an FHEM gemeldet wird.<br />
<br />
Wenn der Scanner in dieser Wartezeit aktiv wird, wird er den soeben geänderten Sollwert überschreiben. In diesem Fall bliebe die manuelle Änderung wirkungslos.<br />
<br />
Wird die manuelle Änderung des Sollwertes vom Scanner erkannt, so gilt dieser bis zum nächsten Schaltpunkt des internen Wochenprogrammes.<br />
<br />
=== Mehrere Thermostate in einer Gruppe? ===<br />
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.<br />
<br />
=== Was ist zu tun wenn, Thermostate zusammen mit einem Wandthermostat eingesetzt werden? ===<br />
In diesem Fall ist der Scanner überflüssig, da das Wandthermostat ohnehin eine detaillierte Kurve des Istwertes liefert.<br />
<br />
=== Sind Fensterkontakte sinnvoll? ===<br />
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 <br />
[http://www.elv.de/topic/tuer-fensterkontakt-sinn-und-unsinn.html Sinn und Unsinn von Fensterkontakten] zeigt.<br />
<br />
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. <br />
<br />
[[Datei:2013_11_02_Scanner_TSturz.png|Sturz-Temperatur-Erkennung]]<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 vermutlich mit einer WindowOpenDuration von 0 behoben werden, ausserdem ist im Hochsommer die Heizung ohnehin ausgeschaltet.<br />
<br />
Folgende Nachteile haben die Max-Fensterkontakte:<br />
* 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.<br />
* 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).<br />
<br />
=== Berücksichtigt der Scanner die Temperatur-Sturz-Erkennung? ===<br />
Wenn desiredTemperature=WindowsOpenTemperature, dann stellt der Scanner seine Arbeit ein. Ansonsten würde er durch aktive Modeumschaltung die WindowsOpenTemperature dauerhaft setzen.<br />
<br />
=== Kann der Scanner mit Fensterkontakten umgehen? ===<br />
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.<br />
<br />
Ausserdem wäre es fatal, wenn der Scanner in der Phase des offenen Fenster den Sollwert überschreiben würde. Bei offenem Fenster ist der Scanner inaktiv, er schaltet also den Modus nicht mehr um.<br />
<br />
=== Was ist denn, wenn ich noch einen zweiten Fensterkontakt habe? ===<br />
Derzeit wird nur 1 ShutterContact unterstützt. Möglicherweise wird in einer der nächsten Versionen die Funktionalität erweitert.<br />
<br />
=== Was passiert, wenn der Boost-Mode aktiviert wurde? ===<br />
Sobald dies der Scanner erkennt, stellt er seine Aktivität ein, bis wieder der Modus Auto oder Manu erscheint.<br />
<br />
=== Unterstützt der Scanner auch den MAX-ECO-Taster? ===<br />
Nein.<br />
<br />
=== Beeinflusst der Scanner den Regelmechanismus des Thermostats? ===<br />
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.<br />
<br />
== Im Kochtopf ==<br />
(realisierte Punkte der Modul-Variante sind fett ausgewiesen)<br />
<br />
* '''Scanner wird nicht mehr als Skript, sondern als Modul ausgeführt'''<br />
* '''Mindestwert für Scan-Intervall, der nicht unterschritten werden darf'''<br />
* '''Möglichkeit mehrere Fensterkontakte einem Thermostat zuzuweisen'''<br />
* Verzögerte Reaktion nach Aktivieren des Fensterkontakts<br />
* Möglichkeit eine Gruppe von Thermostaten auf Eco-Mode zu schalten (z.B. ausgelöst über ECO-Taster)<br />
* Gruppenbildung über mehrere Thermostate (für Eco-Taster)<br />
* '''Fix: wenn bei desriredtemperatur ON,OFF anstelle einer Zahl erscheint.'''<br />
<br />
== Die Modul-Variante (Beta-Version) ==<br />
<br />
Die Modul-Variante ist derzeit in der Testphase. Sie soll die die Skript-Variante mittelfristig ablösen.<br />
<br />
=== Voraussetzungen ===<br />
* Download von Modul 98_MaxScanner.pm in das Modul-Verzeichnis von FHEM<br />
* die Script-Variante sollte deaktiviert werden (alle ScanTemp-Attribute auf 0 stellen oder 99_UtilsMaxScan löschen/verschieben)<br />
* FHEM neu starten<br />
<br />
=== Inbetriebnahme ===<br />
* Scanner Modul definieren<br />
<pre><br />
define Scanner MaxScanner<br />
attr Scanner verbose 1<br />
</pre><br />
<br />
* die bestehende Max-Thermostate verfügen nun automatisch über neue Attribute, die den Scanner betreffen<br />
* alle Scanner-spezfischen Attribute beginnen immer mit "scn"<br />
* im folgende Beispiel wird das Thermostat HT.JOHN betrachtet:<br />
<pre><br />
define HT.JOHN MAX HeatingThermostat 066666<br />
</pre><br />
* das Thermostat wird für den Scanner freigegeben<br />
<pre>attr HT.JOHN scnEnabled 1</pre><br />
* wir wählen die Betriebsart Mode-Change<br />
<pre>attr HT.JOHN scnProcessByDesiChange 0</pre><br />
* wir können 0..n ShutterContacts definieren, getrennt durch Komma<br />
<pre>attr HT.JOHN scnShutterList SHUTTER.JOHN,SHUTTER.BRENNER</pre><br />
* verbose liefert ausführliche Infos im Logger<br />
<pre>attr HT.JOHN verbose 4</pre><br />
<br />
=== Attribute Thermostat===<br />
{| class="wikitable sortable"<br />
|-<br />
! Parameter !! Wertebereich !! Default !! Beschreibung<br />
|-<br />
|scnEnabled||[0,1]||0||wenn 1, wird das Thermostat vom Scanner berücksichtigt<br />
|-<br />
|scnProcessByDesiChange||[0,1]||0||wenn 1, wird das Thermostat über die Änderung von desiredTemperature (DesiredChange) getriggert, ansonsten über die Änderung des Modes (ModeChange)<br />
|-<br />
|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<br />
Thermostat geschrieben wird. Ist hingegen NOCHANGE gewählt, so wird der aktuelle am Thermostat angewählte Mode belassen.<br />
|-<br />
|scnShutterList||||||Liste von assoziierten Max-Fensterkontakten (ShutterContacts), die durch ein Komma getrennt werden. <br />
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.<br />
<br />
|}<br />
=== Attribute Scanner===<br />
{| class="wikitable sortable"<br />
|-<br />
! Parameter !! Wertebereich !! Default !! Beschreibung<br />
|-<br />
|disable||[0,1]||0|| wenn 1, dann wird der Scanner gesperrt und ist somit inaktiv.<br />
|-<br />
|scnCreditThreshold||[150..600]||300|| die Mindestanzahl von verfügbaren Credits, ab der der Scanner mit dem Triggern der Thermostate beginnt<br />
|-<br />
|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.<br />
|-<br />
|}<br />
<br />
=== Background ===<br />
<br />
==== Common Notify ====<br />
Der Scanner erzeugt automatisch ein Notify MAXSCANNER.COMMON.EVENT. Dieses ist im Bereich "Unsorted" zu finden.<br/><br/><br />
Hier werden alle für den Scanner wichtigen Events gefiltert, so daß dieser auf Änderungen umgehend reagieren kann.<br/><br />
Das Notify wird beim Neustart von FHEM oder bei Ausführen des set Befehls "Initialize" erzeugt, aber nur dann, wenn das Notify<br />
noch nicht existiert oder es sich aufgrund neuer Gegebenheiten (ShutterContact, Thermostat) zu ändern ist.<br />
<br />
<br />
<br />
[[Kategorie:MAX]]</div>Johnhttp://wiki.fhem.de/w/index.php?title=MAX!_Temperatur-Scanner&diff=13477MAX! Temperatur-Scanner2016-01-06T19:42:17Z<p>John: /* Unterstützt der Scanner auch den MAX-ECO-Taster? */</p>
<hr />
<div>Der '''MAX! Temperatur-Scanner''' ist ein Perl-Skript, das die kontinuierliche Temperatur-Aufzeichnung<br />
von MAX-Thermostaten ermöglicht. <br />
<br />
== Features ==<br />
* kontinuierliche Erfassung von Temperatur und Ventil-Position <br />
* Berücksichtigung der System-Ressourcen (dutycycle, credits)<br />
* CUL und CUBE werden unterstützt<br />
* gleichberechtigte zeitliche Bearbeitung der Thermostate (Round-Robin-Prinzip)<br />
* Ermittlung der optimalen Scan-Rate über die Anzahl der eingebundenen Thermostate<br />
* 2 Scan-Modi stehen zur Verfügung (DesiredChange + ModeChange)<br />
<br />
== Zielsetzung des WIKI-Artikels ==<br />
Hier werden Fragen und Erkenntnisse zum Thema dargestellt, da der Forums-Eintrag für viele Anwender nicht mehr überschaubar ist.<br />
<br />
Der Artikel wird sukzessive erweitert.<br />
<br />
== Aktuelle Version ==<br />
Im Anhang zu folgendem Forumsbeitrag [http://forum.fhem.de/index.php/topic,11624.msg68237.html#msg68237 MaxScan Version 1.05c]<br />
<br />
=== Voraussetzungen ===<br />
==== Qualität der Funkverbindung ====<br />
In der Log-Datei sollten möglichst wenig Einträge der nachfolgenden Form auftreten<br />
<pre>2013.11.01 02:12:33 2: CUL_MAX_SendQueueHandler: Missing ack from 0905a5 for 0b0b0040123456xxxxxxxxx</pre><br />
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.<br />
<br />
==== Ausreichend Credits ====<br />
Der Scanner kann nicht aktiv werden, wenn gehäuft Log-Einträge der nachfolgenden Form auftreten.<br />
<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><br />
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.<br />
<br />
==== Einrichten des Thermostat-internen Wochenprogrammes ====<br />
Anders als bei den Vorgängerversionen <=1.04 ist nun ab Version 1.05 zwingend das Thermostat-interne<br />
Wochenprogramm notwendig.<br />
<br />
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.<br />
<br />
Das bei früheren Versionen eingesetzte Heating_Control kann somit entfallen.<br />
<br />
'''Bitte folgendes beachten:'''<br />
<br />
Es gibt im Zusammenhang mit dem Wochenprogramm ein Problem mit dem letzten Schaltpunkt des Tages. <br />
Der Workaround wurde [http://forum.fhem.de/index.php/topic,17231.msg112738.html#msg112738 hier]<br />
beschrieben.<br />
<br />
<big>Man muss dafür sorgen, dass man kurz vor Ende des Tages noch einen Schaltpunkt setzt.</big><br />
<br />
=== Inbetriebnahme ===<br />
* aktuell freigegebene Version von 99_UtilsMaxScan.pm in das Verzeichnis /opt/fhem/FHEM kopieren.<br />
* Bei den Thermostaten, die gescannt werden sollen, das Attribut scanTemp setzen via<br />
<pre>attr VT_HW scanTemp 1</pre><br />
* das Wochenprogramm im Thermostat nach den Bedürfnissen einstellen<br />
* auf''' keinen''' Fall das Attribut keepAuto setzen<br />
* mit dem userReading "onlyAutoMode" kann der Scan-Modus ModeChange festgelegt werden<br />
<pre>attr HT.JOHN userReadings onlyAutoMode { return "1";;}</pre> <br />
* ist ein ShutterContact mit dem Thermostat assoziiert, dann muss man dies bekannt machen mit dem UserReading<br />
<pre>attr VT_HW userReadings watchShutter { return "SHUTTER.HW";;}</pre><br />
* '''FHEM neu starten'''<br />
<br />
'''Hinweis'''<br /><br />
Je kleiner der Wert von Attribut verbose, umso weniger Ausgaben erhält man in der Log-Datei.<br />
<br />
== Mechanismen ==<br />
=== Das Problem ===<br />
Der Hersteller der MAX-Thermostate hat diese so konzipiert, dass die gemessene Temperatur und Ventilstellung nur übertragen werden, wenn sich Folgendes ändert:<br />
* die Ventilstellung<br />
* die Betriebsart (mode: auto,manu,temporary,boost)<br />
* der Sollwert<br />
<br />
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.<br />
<br />
=== Der Lösungsansatz ===<br />
==== Triggerung per Mode-Umschaltung (ModeChange) ====<br />
Dies ist der Default-Mode des Scanners.<br />
Hier wird der Ansatz verfolgt, die Betriebsart des Thermostats regelmässig umzuschalten via<br />
:AUTO ==> MANU<br />
<Wartezeit mindestens 3 Minuten><br />
:MANU ==> AUTO<br />
<br />
Dies veranlasst das Thermostat, regelmässig die gewünschten Werte an FHEM (den gepaarten Transceiver) zu senden.<br />
<br />
==== Triggerung per Sollwert-Umschaltung (DesiredChange) ====<br />
Durch Änderung des Sollwertes kann ebenso die Übertragung des Istwertes am Thermostat initiiert werden.<br />
<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.<br />
<br />
Dieser Modus wird durch die Definition des UserReadings "onlyAutoMode" festgelegt.<br />
:<code>attr HT.JOHN userReadings onlyAutoMode { return "1";;}</code><br />
<br />
'''Beispiel:'''<br />
<br />
Sollwert im Thermostat nach Wochenprofil: 18<br />
Fall A:<br />
----<br />
* Istwert 17<br />
* Sollwert A von Scanner gesetzt : 18.5<br />
* Sollwert B von Scanner gesetzt : 18.0<br />
* Der Scanner wechselt also von 18 auf 18.5 und zurück.<br />
<br />
Fall B:<br />
----<br />
* Istwert 19<br />
* Sollwert A von Scanner gesetzt : 17.5<br />
* Sollwert B von Scanner gesetzt : 18.0<br />
* Der Scanner wechselt also von 18 auf 17.5 und zurück.<br />
<br />
=== Ergebnis ===<br />
==== ohne Scanner ====<br />
[[Datei:2013_12_MaxScanner_Vorher.png|ohne Scanner]]<br />
<br />
==== mit Scanner (ScanMode=ModeChange) ====<br />
[[Datei:13_12_01_Scanner_ModeChange.png|mit Scanner]]<br />
<br />
==== mit Scanner (ScanMode=DesiredChange) ====<br />
[[Datei:13_12_01_Scanner_DesiredChange.png|mit Scanner]]<br />
<br />
=== Ressourcen ===<br />
Die Sendezeit jedes Teilnehmers ist auf 1% begrenzt.<br />
<br />
Konkret bedeutet dies, dass ein CUL ca. 33 Telegramme pro Stunde senden kann.<br />
Der MAX-Scanner darf nicht alle Ressourcen für sich beanspruchen, sondern sieht seine Aufgabe als nachrangig. <br />
<br />
Erst wenn mehr als 300 Credits (von max. 900 möglichen) zur Verfügung stehen, wird das Skript aktiv.<br />
<br />
== Fragen und Antworten ==<br />
=== Welchen ScanMode soll ich wählen? ===<br />
Nachfolgende Punkte können als Entscheidungskriterium dienen:<br />
<br />
'''ModeChange'''<br />
* keine Änderung des Sollwertes nötig<br />
* damit ist das Ventil "ruhiger", da sich die Regeldifferenz nicht durch den Scanner-Betrieb ändert.<br />
<br />
'''DesiredChange'''<br />
* der Auto-Modus wird niemals verlassen<br />
* Falls FHEM ausfällt, wird das Thermostat das gespeicherte Wochenprogramm nutzen<br />
<br />
=== Wie kann man den ScanMode nachträglich ändern? ===<br />
Man kann das userReading ändern, so dass es 0 liefert<br />
:<code>attr HT.JOHN userReadings onlyAutoMode { return "0";;}</code><br />
<br />
oder man löscht das userReading durch<br />
* Löschen aus dem attribut userReading<br />
* und Löschen des vorhandenen userReadings via<br />
:<code>deletereading HT.JOHN onlyAutoMode </code><br />
<br />
=== Was passiert, wenn der Sollwert am Thermostat manuell verstellt wird? ===<br />
Wenn der Sollwert manuell am Thermostat verändert wird, kann es bis zu 3 Minuten dauern, bis dieser an FHEM gemeldet wird.<br />
<br />
Wenn der Scanner in dieser Wartezeit aktiv wird, wird er den soeben geänderten Sollwert überschreiben. In diesem Fall bliebe die manuelle Änderung wirkungslos.<br />
<br />
Wird die manuelle Änderung des Sollwertes vom Scanner erkannt, so gilt dieser bis zum nächsten Schaltpunkt des internen Wochenprogrammes.<br />
<br />
=== Mehrere Thermostate in einer Gruppe? ===<br />
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.<br />
<br />
=== Was ist zu tun wenn, Thermostate zusammen mit einem Wandthermostat eingesetzt werden? ===<br />
In diesem Fall ist der Scanner überflüssig, da das Wandthermostat ohnehin eine detaillierte Kurve des Istwertes liefert.<br />
<br />
=== Sind Fensterkontakte sinnvoll? ===<br />
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 <br />
[http://www.elv.de/topic/tuer-fensterkontakt-sinn-und-unsinn.html Sinn und Unsinn von Fensterkontakten] zeigt.<br />
<br />
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. <br />
<br />
[[Datei:2013_11_02_Scanner_TSturz.png|Sturz-Temperatur-Erkennung]]<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 vermutlich mit einer WindowOpenDuration von 0 behoben werden, ausserdem ist im Hochsommer die Heizung ohnehin ausgeschaltet.<br />
<br />
Folgende Nachteile haben die Max-Fensterkontakte:<br />
* 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.<br />
* 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).<br />
<br />
=== Berücksichtigt der Scanner die Temperatur-Sturz-Erkennung? ===<br />
Wenn desiredTemperature=WindowsOpenTemperature, dann stellt der Scanner seine Arbeit ein. Ansonsten würde er durch aktive Modeumschaltung die WindowsOpenTemperature dauerhaft setzen.<br />
<br />
=== Kann der Scanner mit Fensterkontakten umgehen? ===<br />
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.<br />
<br />
Ausserdem wäre es fatal, wenn der Scanner in der Phase des offenen Fenster den Sollwert überschreiben würde. Bei offenem Fenster ist der Scanner inaktiv, er schaltet also den Modus nicht mehr um.<br />
<br />
=== Was ist denn, wenn ich noch einen zweiten Fensterkontakt habe? ===<br />
Derzeit wird nur 1 ShutterContact unterstützt. Möglicherweise wird in einer der nächsten Versionen die Funktionalität erweitert.<br />
<br />
=== Was passiert, wenn der Boost-Mode aktiviert wurde? ===<br />
Sobald dies der Scanner erkennt, stellt er seine Aktivität ein, bis wieder der Modus Auto oder Manu erscheint.<br />
<br />
=== Unterstützt der Scanner auch den MAX-ECO-Taster? ===<br />
Nein.<br />
<br />
=== Beeinflusst der Scanner den Regelmechanismus des Thermostats? ===<br />
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.<br />
<br />
== Im Kochtopf ==<br />
(realisierte Punkte der Modul-Variante sind fett ausgewiesen)<br />
<br />
* '''Scanner wird nicht mehr als Skript, sondern als Modul ausgeführt'''<br />
* '''Mindestwert für Scan-Intervall, der nicht unterschritten werden darf'''<br />
* '''Möglichkeit mehrere Fensterkontakte einem Thermostat zuzuweisen'''<br />
* Verzögerte Reaktion nach Aktivieren des Fensterkontakts<br />
* Möglichkeit eine Gruppe von Thermostaten auf Eco-Mode zu schalten (z.B. ausgelöst über ECO-Taster)<br />
* Gruppenbildung über mehrere Thermostate (für Eco-Taster)<br />
* '''Fix: wenn bei desriredtemperatur ON,OFF anstelle einer Zahl erscheint.'''<br />
<br />
== Die Modul-Variante (Beta-Version) ==<br />
<br />
Die Modul-Variante ist derzeit in der Testphase. Sie soll die die Skript-Variante mittelfristig ablösen.<br />
<br />
=== Voraussetzungen ===<br />
* Download von Modul 98_MaxScanner.pm in das Modul-Verzeichnis von FHEM<br />
* die Script-Variante sollte deaktiviert werden (alle ScanTemp-Attribute auf 0 stellen oder 99_UtilsMaxScan löschen/verschieben)<br />
* FHEM neu starten<br />
<br />
=== Inbetriebnahme ===<br />
* Scanner Modul definieren<br />
<pre><br />
define Scanner MaxScanner<br />
attr Scanner verbose 1<br />
</pre><br />
<br />
* die bestehende Max-Thermostate verfügen nun automatisch über neue Attribute, die den Scanner betreffen<br />
* alle Scanner-spezfischen Attribute beginnen immer mit "scn"<br />
* im folgende Beispiel wird das Thermostat HT.JOHN betrachtet:<br />
<pre><br />
define HT.JOHN MAX HeatingThermostat 066666<br />
</pre><br />
* das Thermostat wird für den Scanner freigegeben<br />
<pre>attr HT.JOHN scnEnabled 1</pre><br />
* wir wählen die Betriebsart Mode-Change<br />
<pre>attr HT.JOHN scnProcessByDesiChange 0</pre><br />
* wir können 0..n ShutterContacts definieren, getrennt durch Komma<br />
<pre>attr HT.JOHN scnShutterList SHUTTER.JOHN,SHUTTER.BRENNER</pre><br />
* verbose liefert ausführliche Infos im Logger<br />
<pre>attr HT.JOHN verbose 4</pre><br />
<br />
=== Attribute Thermostat===<br />
{| class="wikitable sortable"<br />
|-<br />
! Parameter !! Wertebereich !! Default !! Beschreibung<br />
|-<br />
|scnEnabled||[0,1]||0||wenn 1, wird das Thermostat vom Scanner berücksichtigt<br />
|-<br />
|scnProcessByDesiChange||[0,1]||0||wenn 1, wird das Thermostat über die Änderung von desiredTemperature (DesiredChange) getriggert, ansonsten über die Änderung des Modes (ModeChange)<br />
|-<br />
|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<br />
Thermostat geschrieben wird. Ist hingegen NOCHANGE gewählt, so wird der aktuelle am Thermostat angewählte Mode belassen.<br />
|-<br />
|scnShutterList||||||Liste von assoziierten Max-Fensterkontakten (ShutterContacts), die durch ein Komma getrennt werden. <br />
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.<br />
<br />
|}<br />
=== Attribute Scanner===<br />
{| class="wikitable sortable"<br />
|-<br />
! Parameter !! Wertebereich !! Default !! Beschreibung<br />
|-<br />
|disable||[0,1]||0|| wenn 1, dann wird der Scanner gesperrt und ist somit inaktiv.<br />
|-<br />
|scnCreditThreshold||[150..600]||300|| die Mindestanzahl von verfügbaren Credits, ab der der Scanner mit dem Triggern der Thermostate beginnt<br />
|-<br />
|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.<br />
|-<br />
|}<br />
[[Kategorie:MAX]]</div>Johnhttp://wiki.fhem.de/w/index.php?title=MAX!_Temperatur-Scanner&diff=13476MAX! Temperatur-Scanner2016-01-06T19:41:38Z<p>John: /* Kann der Scanner mit Fensterkontakten umgehen? */</p>
<hr />
<div>Der '''MAX! Temperatur-Scanner''' ist ein Perl-Skript, das die kontinuierliche Temperatur-Aufzeichnung<br />
von MAX-Thermostaten ermöglicht. <br />
<br />
== Features ==<br />
* kontinuierliche Erfassung von Temperatur und Ventil-Position <br />
* Berücksichtigung der System-Ressourcen (dutycycle, credits)<br />
* CUL und CUBE werden unterstützt<br />
* gleichberechtigte zeitliche Bearbeitung der Thermostate (Round-Robin-Prinzip)<br />
* Ermittlung der optimalen Scan-Rate über die Anzahl der eingebundenen Thermostate<br />
* 2 Scan-Modi stehen zur Verfügung (DesiredChange + ModeChange)<br />
<br />
== Zielsetzung des WIKI-Artikels ==<br />
Hier werden Fragen und Erkenntnisse zum Thema dargestellt, da der Forums-Eintrag für viele Anwender nicht mehr überschaubar ist.<br />
<br />
Der Artikel wird sukzessive erweitert.<br />
<br />
== Aktuelle Version ==<br />
Im Anhang zu folgendem Forumsbeitrag [http://forum.fhem.de/index.php/topic,11624.msg68237.html#msg68237 MaxScan Version 1.05c]<br />
<br />
=== Voraussetzungen ===<br />
==== Qualität der Funkverbindung ====<br />
In der Log-Datei sollten möglichst wenig Einträge der nachfolgenden Form auftreten<br />
<pre>2013.11.01 02:12:33 2: CUL_MAX_SendQueueHandler: Missing ack from 0905a5 for 0b0b0040123456xxxxxxxxx</pre><br />
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.<br />
<br />
==== Ausreichend Credits ====<br />
Der Scanner kann nicht aktiv werden, wenn gehäuft Log-Einträge der nachfolgenden Form auftreten.<br />
<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><br />
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.<br />
<br />
==== Einrichten des Thermostat-internen Wochenprogrammes ====<br />
Anders als bei den Vorgängerversionen <=1.04 ist nun ab Version 1.05 zwingend das Thermostat-interne<br />
Wochenprogramm notwendig.<br />
<br />
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.<br />
<br />
Das bei früheren Versionen eingesetzte Heating_Control kann somit entfallen.<br />
<br />
'''Bitte folgendes beachten:'''<br />
<br />
Es gibt im Zusammenhang mit dem Wochenprogramm ein Problem mit dem letzten Schaltpunkt des Tages. <br />
Der Workaround wurde [http://forum.fhem.de/index.php/topic,17231.msg112738.html#msg112738 hier]<br />
beschrieben.<br />
<br />
<big>Man muss dafür sorgen, dass man kurz vor Ende des Tages noch einen Schaltpunkt setzt.</big><br />
<br />
=== Inbetriebnahme ===<br />
* aktuell freigegebene Version von 99_UtilsMaxScan.pm in das Verzeichnis /opt/fhem/FHEM kopieren.<br />
* Bei den Thermostaten, die gescannt werden sollen, das Attribut scanTemp setzen via<br />
<pre>attr VT_HW scanTemp 1</pre><br />
* das Wochenprogramm im Thermostat nach den Bedürfnissen einstellen<br />
* auf''' keinen''' Fall das Attribut keepAuto setzen<br />
* mit dem userReading "onlyAutoMode" kann der Scan-Modus ModeChange festgelegt werden<br />
<pre>attr HT.JOHN userReadings onlyAutoMode { return "1";;}</pre> <br />
* ist ein ShutterContact mit dem Thermostat assoziiert, dann muss man dies bekannt machen mit dem UserReading<br />
<pre>attr VT_HW userReadings watchShutter { return "SHUTTER.HW";;}</pre><br />
* '''FHEM neu starten'''<br />
<br />
'''Hinweis'''<br /><br />
Je kleiner der Wert von Attribut verbose, umso weniger Ausgaben erhält man in der Log-Datei.<br />
<br />
== Mechanismen ==<br />
=== Das Problem ===<br />
Der Hersteller der MAX-Thermostate hat diese so konzipiert, dass die gemessene Temperatur und Ventilstellung nur übertragen werden, wenn sich Folgendes ändert:<br />
* die Ventilstellung<br />
* die Betriebsart (mode: auto,manu,temporary,boost)<br />
* der Sollwert<br />
<br />
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.<br />
<br />
=== Der Lösungsansatz ===<br />
==== Triggerung per Mode-Umschaltung (ModeChange) ====<br />
Dies ist der Default-Mode des Scanners.<br />
Hier wird der Ansatz verfolgt, die Betriebsart des Thermostats regelmässig umzuschalten via<br />
:AUTO ==> MANU<br />
<Wartezeit mindestens 3 Minuten><br />
:MANU ==> AUTO<br />
<br />
Dies veranlasst das Thermostat, regelmässig die gewünschten Werte an FHEM (den gepaarten Transceiver) zu senden.<br />
<br />
==== Triggerung per Sollwert-Umschaltung (DesiredChange) ====<br />
Durch Änderung des Sollwertes kann ebenso die Übertragung des Istwertes am Thermostat initiiert werden.<br />
<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.<br />
<br />
Dieser Modus wird durch die Definition des UserReadings "onlyAutoMode" festgelegt.<br />
:<code>attr HT.JOHN userReadings onlyAutoMode { return "1";;}</code><br />
<br />
'''Beispiel:'''<br />
<br />
Sollwert im Thermostat nach Wochenprofil: 18<br />
Fall A:<br />
----<br />
* Istwert 17<br />
* Sollwert A von Scanner gesetzt : 18.5<br />
* Sollwert B von Scanner gesetzt : 18.0<br />
* Der Scanner wechselt also von 18 auf 18.5 und zurück.<br />
<br />
Fall B:<br />
----<br />
* Istwert 19<br />
* Sollwert A von Scanner gesetzt : 17.5<br />
* Sollwert B von Scanner gesetzt : 18.0<br />
* Der Scanner wechselt also von 18 auf 17.5 und zurück.<br />
<br />
=== Ergebnis ===<br />
==== ohne Scanner ====<br />
[[Datei:2013_12_MaxScanner_Vorher.png|ohne Scanner]]<br />
<br />
==== mit Scanner (ScanMode=ModeChange) ====<br />
[[Datei:13_12_01_Scanner_ModeChange.png|mit Scanner]]<br />
<br />
==== mit Scanner (ScanMode=DesiredChange) ====<br />
[[Datei:13_12_01_Scanner_DesiredChange.png|mit Scanner]]<br />
<br />
=== Ressourcen ===<br />
Die Sendezeit jedes Teilnehmers ist auf 1% begrenzt.<br />
<br />
Konkret bedeutet dies, dass ein CUL ca. 33 Telegramme pro Stunde senden kann.<br />
Der MAX-Scanner darf nicht alle Ressourcen für sich beanspruchen, sondern sieht seine Aufgabe als nachrangig. <br />
<br />
Erst wenn mehr als 300 Credits (von max. 900 möglichen) zur Verfügung stehen, wird das Skript aktiv.<br />
<br />
== Fragen und Antworten ==<br />
=== Welchen ScanMode soll ich wählen? ===<br />
Nachfolgende Punkte können als Entscheidungskriterium dienen:<br />
<br />
'''ModeChange'''<br />
* keine Änderung des Sollwertes nötig<br />
* damit ist das Ventil "ruhiger", da sich die Regeldifferenz nicht durch den Scanner-Betrieb ändert.<br />
<br />
'''DesiredChange'''<br />
* der Auto-Modus wird niemals verlassen<br />
* Falls FHEM ausfällt, wird das Thermostat das gespeicherte Wochenprogramm nutzen<br />
<br />
=== Wie kann man den ScanMode nachträglich ändern? ===<br />
Man kann das userReading ändern, so dass es 0 liefert<br />
:<code>attr HT.JOHN userReadings onlyAutoMode { return "0";;}</code><br />
<br />
oder man löscht das userReading durch<br />
* Löschen aus dem attribut userReading<br />
* und Löschen des vorhandenen userReadings via<br />
:<code>deletereading HT.JOHN onlyAutoMode </code><br />
<br />
=== Was passiert, wenn der Sollwert am Thermostat manuell verstellt wird? ===<br />
Wenn der Sollwert manuell am Thermostat verändert wird, kann es bis zu 3 Minuten dauern, bis dieser an FHEM gemeldet wird.<br />
<br />
Wenn der Scanner in dieser Wartezeit aktiv wird, wird er den soeben geänderten Sollwert überschreiben. In diesem Fall bliebe die manuelle Änderung wirkungslos.<br />
<br />
Wird die manuelle Änderung des Sollwertes vom Scanner erkannt, so gilt dieser bis zum nächsten Schaltpunkt des internen Wochenprogrammes.<br />
<br />
=== Mehrere Thermostate in einer Gruppe? ===<br />
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.<br />
<br />
=== Was ist zu tun wenn, Thermostate zusammen mit einem Wandthermostat eingesetzt werden? ===<br />
In diesem Fall ist der Scanner überflüssig, da das Wandthermostat ohnehin eine detaillierte Kurve des Istwertes liefert.<br />
<br />
=== Sind Fensterkontakte sinnvoll? ===<br />
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 <br />
[http://www.elv.de/topic/tuer-fensterkontakt-sinn-und-unsinn.html Sinn und Unsinn von Fensterkontakten] zeigt.<br />
<br />
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. <br />
<br />
[[Datei:2013_11_02_Scanner_TSturz.png|Sturz-Temperatur-Erkennung]]<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 vermutlich mit einer WindowOpenDuration von 0 behoben werden, ausserdem ist im Hochsommer die Heizung ohnehin ausgeschaltet.<br />
<br />
Folgende Nachteile haben die Max-Fensterkontakte:<br />
* 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.<br />
* 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).<br />
<br />
=== Berücksichtigt der Scanner die Temperatur-Sturz-Erkennung? ===<br />
Wenn desiredTemperature=WindowsOpenTemperature, dann stellt der Scanner seine Arbeit ein. Ansonsten würde er durch aktive Modeumschaltung die WindowsOpenTemperature dauerhaft setzen.<br />
<br />
=== Kann der Scanner mit Fensterkontakten umgehen? ===<br />
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.<br />
<br />
Ausserdem wäre es fatal, wenn der Scanner in der Phase des offenen Fenster den Sollwert überschreiben würde. Bei offenem Fenster ist der Scanner inaktiv, er schaltet also den Modus nicht mehr um.<br />
<br />
=== Was ist denn, wenn ich noch einen zweiten Fensterkontakt habe? ===<br />
Derzeit wird nur 1 ShutterContact unterstützt. Möglicherweise wird in einer der nächsten Versionen die Funktionalität erweitert.<br />
<br />
=== Was passiert, wenn der Boost-Mode aktiviert wurde? ===<br />
Sobald dies der Scanner erkennt, stellt er seine Aktivität ein, bis wieder der Modus Auto oder Manu erscheint.<br />
<br />
=== Unterstützt der Scanner auch den MAX-ECO-Taster? ===<br />
Nein. Dies wird für künftige Versionen geplant.<br />
<br />
=== Beeinflusst der Scanner den Regelmechanismus des Thermostats? ===<br />
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.<br />
<br />
== Im Kochtopf ==<br />
(realisierte Punkte der Modul-Variante sind fett ausgewiesen)<br />
<br />
* '''Scanner wird nicht mehr als Skript, sondern als Modul ausgeführt'''<br />
* '''Mindestwert für Scan-Intervall, der nicht unterschritten werden darf'''<br />
* '''Möglichkeit mehrere Fensterkontakte einem Thermostat zuzuweisen'''<br />
* Verzögerte Reaktion nach Aktivieren des Fensterkontakts<br />
* Möglichkeit eine Gruppe von Thermostaten auf Eco-Mode zu schalten (z.B. ausgelöst über ECO-Taster)<br />
* Gruppenbildung über mehrere Thermostate (für Eco-Taster)<br />
* '''Fix: wenn bei desriredtemperatur ON,OFF anstelle einer Zahl erscheint.'''<br />
<br />
== Die Modul-Variante (Beta-Version) ==<br />
<br />
Die Modul-Variante ist derzeit in der Testphase. Sie soll die die Skript-Variante mittelfristig ablösen.<br />
<br />
=== Voraussetzungen ===<br />
* Download von Modul 98_MaxScanner.pm in das Modul-Verzeichnis von FHEM<br />
* die Script-Variante sollte deaktiviert werden (alle ScanTemp-Attribute auf 0 stellen oder 99_UtilsMaxScan löschen/verschieben)<br />
* FHEM neu starten<br />
<br />
=== Inbetriebnahme ===<br />
* Scanner Modul definieren<br />
<pre><br />
define Scanner MaxScanner<br />
attr Scanner verbose 1<br />
</pre><br />
<br />
* die bestehende Max-Thermostate verfügen nun automatisch über neue Attribute, die den Scanner betreffen<br />
* alle Scanner-spezfischen Attribute beginnen immer mit "scn"<br />
* im folgende Beispiel wird das Thermostat HT.JOHN betrachtet:<br />
<pre><br />
define HT.JOHN MAX HeatingThermostat 066666<br />
</pre><br />
* das Thermostat wird für den Scanner freigegeben<br />
<pre>attr HT.JOHN scnEnabled 1</pre><br />
* wir wählen die Betriebsart Mode-Change<br />
<pre>attr HT.JOHN scnProcessByDesiChange 0</pre><br />
* wir können 0..n ShutterContacts definieren, getrennt durch Komma<br />
<pre>attr HT.JOHN scnShutterList SHUTTER.JOHN,SHUTTER.BRENNER</pre><br />
* verbose liefert ausführliche Infos im Logger<br />
<pre>attr HT.JOHN verbose 4</pre><br />
<br />
=== Attribute Thermostat===<br />
{| class="wikitable sortable"<br />
|-<br />
! Parameter !! Wertebereich !! Default !! Beschreibung<br />
|-<br />
|scnEnabled||[0,1]||0||wenn 1, wird das Thermostat vom Scanner berücksichtigt<br />
|-<br />
|scnProcessByDesiChange||[0,1]||0||wenn 1, wird das Thermostat über die Änderung von desiredTemperature (DesiredChange) getriggert, ansonsten über die Änderung des Modes (ModeChange)<br />
|-<br />
|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<br />
Thermostat geschrieben wird. Ist hingegen NOCHANGE gewählt, so wird der aktuelle am Thermostat angewählte Mode belassen.<br />
|-<br />
|scnShutterList||||||Liste von assoziierten Max-Fensterkontakten (ShutterContacts), die durch ein Komma getrennt werden. <br />
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.<br />
<br />
|}<br />
=== Attribute Scanner===<br />
{| class="wikitable sortable"<br />
|-<br />
! Parameter !! Wertebereich !! Default !! Beschreibung<br />
|-<br />
|disable||[0,1]||0|| wenn 1, dann wird der Scanner gesperrt und ist somit inaktiv.<br />
|-<br />
|scnCreditThreshold||[150..600]||300|| die Mindestanzahl von verfügbaren Credits, ab der der Scanner mit dem Triggern der Thermostate beginnt<br />
|-<br />
|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.<br />
|-<br />
|}<br />
[[Kategorie:MAX]]</div>Johnhttp://wiki.fhem.de/w/index.php?title=MAX!_Temperatur-Scanner&diff=13475MAX! Temperatur-Scanner2016-01-06T19:30:25Z<p>John: /* Im Kochtopf */</p>
<hr />
<div>Der '''MAX! Temperatur-Scanner''' ist ein Perl-Skript, das die kontinuierliche Temperatur-Aufzeichnung<br />
von MAX-Thermostaten ermöglicht. <br />
<br />
== Features ==<br />
* kontinuierliche Erfassung von Temperatur und Ventil-Position <br />
* Berücksichtigung der System-Ressourcen (dutycycle, credits)<br />
* CUL und CUBE werden unterstützt<br />
* gleichberechtigte zeitliche Bearbeitung der Thermostate (Round-Robin-Prinzip)<br />
* Ermittlung der optimalen Scan-Rate über die Anzahl der eingebundenen Thermostate<br />
* 2 Scan-Modi stehen zur Verfügung (DesiredChange + ModeChange)<br />
<br />
== Zielsetzung des WIKI-Artikels ==<br />
Hier werden Fragen und Erkenntnisse zum Thema dargestellt, da der Forums-Eintrag für viele Anwender nicht mehr überschaubar ist.<br />
<br />
Der Artikel wird sukzessive erweitert.<br />
<br />
== Aktuelle Version ==<br />
Im Anhang zu folgendem Forumsbeitrag [http://forum.fhem.de/index.php/topic,11624.msg68237.html#msg68237 MaxScan Version 1.05c]<br />
<br />
=== Voraussetzungen ===<br />
==== Qualität der Funkverbindung ====<br />
In der Log-Datei sollten möglichst wenig Einträge der nachfolgenden Form auftreten<br />
<pre>2013.11.01 02:12:33 2: CUL_MAX_SendQueueHandler: Missing ack from 0905a5 for 0b0b0040123456xxxxxxxxx</pre><br />
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.<br />
<br />
==== Ausreichend Credits ====<br />
Der Scanner kann nicht aktiv werden, wenn gehäuft Log-Einträge der nachfolgenden Form auftreten.<br />
<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><br />
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.<br />
<br />
==== Einrichten des Thermostat-internen Wochenprogrammes ====<br />
Anders als bei den Vorgängerversionen <=1.04 ist nun ab Version 1.05 zwingend das Thermostat-interne<br />
Wochenprogramm notwendig.<br />
<br />
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.<br />
<br />
Das bei früheren Versionen eingesetzte Heating_Control kann somit entfallen.<br />
<br />
'''Bitte folgendes beachten:'''<br />
<br />
Es gibt im Zusammenhang mit dem Wochenprogramm ein Problem mit dem letzten Schaltpunkt des Tages. <br />
Der Workaround wurde [http://forum.fhem.de/index.php/topic,17231.msg112738.html#msg112738 hier]<br />
beschrieben.<br />
<br />
<big>Man muss dafür sorgen, dass man kurz vor Ende des Tages noch einen Schaltpunkt setzt.</big><br />
<br />
=== Inbetriebnahme ===<br />
* aktuell freigegebene Version von 99_UtilsMaxScan.pm in das Verzeichnis /opt/fhem/FHEM kopieren.<br />
* Bei den Thermostaten, die gescannt werden sollen, das Attribut scanTemp setzen via<br />
<pre>attr VT_HW scanTemp 1</pre><br />
* das Wochenprogramm im Thermostat nach den Bedürfnissen einstellen<br />
* auf''' keinen''' Fall das Attribut keepAuto setzen<br />
* mit dem userReading "onlyAutoMode" kann der Scan-Modus ModeChange festgelegt werden<br />
<pre>attr HT.JOHN userReadings onlyAutoMode { return "1";;}</pre> <br />
* ist ein ShutterContact mit dem Thermostat assoziiert, dann muss man dies bekannt machen mit dem UserReading<br />
<pre>attr VT_HW userReadings watchShutter { return "SHUTTER.HW";;}</pre><br />
* '''FHEM neu starten'''<br />
<br />
'''Hinweis'''<br /><br />
Je kleiner der Wert von Attribut verbose, umso weniger Ausgaben erhält man in der Log-Datei.<br />
<br />
== Mechanismen ==<br />
=== Das Problem ===<br />
Der Hersteller der MAX-Thermostate hat diese so konzipiert, dass die gemessene Temperatur und Ventilstellung nur übertragen werden, wenn sich Folgendes ändert:<br />
* die Ventilstellung<br />
* die Betriebsart (mode: auto,manu,temporary,boost)<br />
* der Sollwert<br />
<br />
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.<br />
<br />
=== Der Lösungsansatz ===<br />
==== Triggerung per Mode-Umschaltung (ModeChange) ====<br />
Dies ist der Default-Mode des Scanners.<br />
Hier wird der Ansatz verfolgt, die Betriebsart des Thermostats regelmässig umzuschalten via<br />
:AUTO ==> MANU<br />
<Wartezeit mindestens 3 Minuten><br />
:MANU ==> AUTO<br />
<br />
Dies veranlasst das Thermostat, regelmässig die gewünschten Werte an FHEM (den gepaarten Transceiver) zu senden.<br />
<br />
==== Triggerung per Sollwert-Umschaltung (DesiredChange) ====<br />
Durch Änderung des Sollwertes kann ebenso die Übertragung des Istwertes am Thermostat initiiert werden.<br />
<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.<br />
<br />
Dieser Modus wird durch die Definition des UserReadings "onlyAutoMode" festgelegt.<br />
:<code>attr HT.JOHN userReadings onlyAutoMode { return "1";;}</code><br />
<br />
'''Beispiel:'''<br />
<br />
Sollwert im Thermostat nach Wochenprofil: 18<br />
Fall A:<br />
----<br />
* Istwert 17<br />
* Sollwert A von Scanner gesetzt : 18.5<br />
* Sollwert B von Scanner gesetzt : 18.0<br />
* Der Scanner wechselt also von 18 auf 18.5 und zurück.<br />
<br />
Fall B:<br />
----<br />
* Istwert 19<br />
* Sollwert A von Scanner gesetzt : 17.5<br />
* Sollwert B von Scanner gesetzt : 18.0<br />
* Der Scanner wechselt also von 18 auf 17.5 und zurück.<br />
<br />
=== Ergebnis ===<br />
==== ohne Scanner ====<br />
[[Datei:2013_12_MaxScanner_Vorher.png|ohne Scanner]]<br />
<br />
==== mit Scanner (ScanMode=ModeChange) ====<br />
[[Datei:13_12_01_Scanner_ModeChange.png|mit Scanner]]<br />
<br />
==== mit Scanner (ScanMode=DesiredChange) ====<br />
[[Datei:13_12_01_Scanner_DesiredChange.png|mit Scanner]]<br />
<br />
=== Ressourcen ===<br />
Die Sendezeit jedes Teilnehmers ist auf 1% begrenzt.<br />
<br />
Konkret bedeutet dies, dass ein CUL ca. 33 Telegramme pro Stunde senden kann.<br />
Der MAX-Scanner darf nicht alle Ressourcen für sich beanspruchen, sondern sieht seine Aufgabe als nachrangig. <br />
<br />
Erst wenn mehr als 300 Credits (von max. 900 möglichen) zur Verfügung stehen, wird das Skript aktiv.<br />
<br />
== Fragen und Antworten ==<br />
=== Welchen ScanMode soll ich wählen? ===<br />
Nachfolgende Punkte können als Entscheidungskriterium dienen:<br />
<br />
'''ModeChange'''<br />
* keine Änderung des Sollwertes nötig<br />
* damit ist das Ventil "ruhiger", da sich die Regeldifferenz nicht durch den Scanner-Betrieb ändert.<br />
<br />
'''DesiredChange'''<br />
* der Auto-Modus wird niemals verlassen<br />
* Falls FHEM ausfällt, wird das Thermostat das gespeicherte Wochenprogramm nutzen<br />
<br />
=== Wie kann man den ScanMode nachträglich ändern? ===<br />
Man kann das userReading ändern, so dass es 0 liefert<br />
:<code>attr HT.JOHN userReadings onlyAutoMode { return "0";;}</code><br />
<br />
oder man löscht das userReading durch<br />
* Löschen aus dem attribut userReading<br />
* und Löschen des vorhandenen userReadings via<br />
:<code>deletereading HT.JOHN onlyAutoMode </code><br />
<br />
=== Was passiert, wenn der Sollwert am Thermostat manuell verstellt wird? ===<br />
Wenn der Sollwert manuell am Thermostat verändert wird, kann es bis zu 3 Minuten dauern, bis dieser an FHEM gemeldet wird.<br />
<br />
Wenn der Scanner in dieser Wartezeit aktiv wird, wird er den soeben geänderten Sollwert überschreiben. In diesem Fall bliebe die manuelle Änderung wirkungslos.<br />
<br />
Wird die manuelle Änderung des Sollwertes vom Scanner erkannt, so gilt dieser bis zum nächsten Schaltpunkt des internen Wochenprogrammes.<br />
<br />
=== Mehrere Thermostate in einer Gruppe? ===<br />
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.<br />
<br />
=== Was ist zu tun wenn, Thermostate zusammen mit einem Wandthermostat eingesetzt werden? ===<br />
In diesem Fall ist der Scanner überflüssig, da das Wandthermostat ohnehin eine detaillierte Kurve des Istwertes liefert.<br />
<br />
=== Sind Fensterkontakte sinnvoll? ===<br />
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 <br />
[http://www.elv.de/topic/tuer-fensterkontakt-sinn-und-unsinn.html Sinn und Unsinn von Fensterkontakten] zeigt.<br />
<br />
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. <br />
<br />
[[Datei:2013_11_02_Scanner_TSturz.png|Sturz-Temperatur-Erkennung]]<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 vermutlich mit einer WindowOpenDuration von 0 behoben werden, ausserdem ist im Hochsommer die Heizung ohnehin ausgeschaltet.<br />
<br />
Folgende Nachteile haben die Max-Fensterkontakte:<br />
* 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.<br />
* 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).<br />
<br />
=== Berücksichtigt der Scanner die Temperatur-Sturz-Erkennung? ===<br />
Wenn desiredTemperature=WindowsOpenTemperature, dann stellt der Scanner seine Arbeit ein. Ansonsten würde er durch aktive Modeumschaltung die WindowsOpenTemperature dauerhaft setzen.<br />
<br />
=== Kann der Scanner mit Fensterkontakten umgehen? ===<br />
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.<br />
<br />
Ausserdem wäre es fatal, wenn der Scanner in der Phase des offenen Fenster den Sollwert überschreiben würde. Bei offenem 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.<br />
<br />
=== Was ist denn, wenn ich noch einen zweiten Fensterkontakt habe? ===<br />
Derzeit wird nur 1 ShutterContact unterstützt. Möglicherweise wird in einer der nächsten Versionen die Funktionalität erweitert.<br />
<br />
=== Was passiert, wenn der Boost-Mode aktiviert wurde? ===<br />
Sobald dies der Scanner erkennt, stellt er seine Aktivität ein, bis wieder der Modus Auto oder Manu erscheint.<br />
<br />
=== Unterstützt der Scanner auch den MAX-ECO-Taster? ===<br />
Nein. Dies wird für künftige Versionen geplant.<br />
<br />
=== Beeinflusst der Scanner den Regelmechanismus des Thermostats? ===<br />
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.<br />
<br />
== Im Kochtopf ==<br />
(realisierte Punkte der Modul-Variante sind fett ausgewiesen)<br />
<br />
* '''Scanner wird nicht mehr als Skript, sondern als Modul ausgeführt'''<br />
* '''Mindestwert für Scan-Intervall, der nicht unterschritten werden darf'''<br />
* '''Möglichkeit mehrere Fensterkontakte einem Thermostat zuzuweisen'''<br />
* Verzögerte Reaktion nach Aktivieren des Fensterkontakts<br />
* Möglichkeit eine Gruppe von Thermostaten auf Eco-Mode zu schalten (z.B. ausgelöst über ECO-Taster)<br />
* Gruppenbildung über mehrere Thermostate (für Eco-Taster)<br />
* '''Fix: wenn bei desriredtemperatur ON,OFF anstelle einer Zahl erscheint.'''<br />
<br />
== Die Modul-Variante (Beta-Version) ==<br />
<br />
Die Modul-Variante ist derzeit in der Testphase. Sie soll die die Skript-Variante mittelfristig ablösen.<br />
<br />
=== Voraussetzungen ===<br />
* Download von Modul 98_MaxScanner.pm in das Modul-Verzeichnis von FHEM<br />
* die Script-Variante sollte deaktiviert werden (alle ScanTemp-Attribute auf 0 stellen oder 99_UtilsMaxScan löschen/verschieben)<br />
* FHEM neu starten<br />
<br />
=== Inbetriebnahme ===<br />
* Scanner Modul definieren<br />
<pre><br />
define Scanner MaxScanner<br />
attr Scanner verbose 1<br />
</pre><br />
<br />
* die bestehende Max-Thermostate verfügen nun automatisch über neue Attribute, die den Scanner betreffen<br />
* alle Scanner-spezfischen Attribute beginnen immer mit "scn"<br />
* im folgende Beispiel wird das Thermostat HT.JOHN betrachtet:<br />
<pre><br />
define HT.JOHN MAX HeatingThermostat 066666<br />
</pre><br />
* das Thermostat wird für den Scanner freigegeben<br />
<pre>attr HT.JOHN scnEnabled 1</pre><br />
* wir wählen die Betriebsart Mode-Change<br />
<pre>attr HT.JOHN scnProcessByDesiChange 0</pre><br />
* wir können 0..n ShutterContacts definieren, getrennt durch Komma<br />
<pre>attr HT.JOHN scnShutterList SHUTTER.JOHN,SHUTTER.BRENNER</pre><br />
* verbose liefert ausführliche Infos im Logger<br />
<pre>attr HT.JOHN verbose 4</pre><br />
<br />
=== Attribute Thermostat===<br />
{| class="wikitable sortable"<br />
|-<br />
! Parameter !! Wertebereich !! Default !! Beschreibung<br />
|-<br />
|scnEnabled||[0,1]||0||wenn 1, wird das Thermostat vom Scanner berücksichtigt<br />
|-<br />
|scnProcessByDesiChange||[0,1]||0||wenn 1, wird das Thermostat über die Änderung von desiredTemperature (DesiredChange) getriggert, ansonsten über die Änderung des Modes (ModeChange)<br />
|-<br />
|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<br />
Thermostat geschrieben wird. Ist hingegen NOCHANGE gewählt, so wird der aktuelle am Thermostat angewählte Mode belassen.<br />
|-<br />
|scnShutterList||||||Liste von assoziierten Max-Fensterkontakten (ShutterContacts), die durch ein Komma getrennt werden. <br />
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.<br />
<br />
|}<br />
=== Attribute Scanner===<br />
{| class="wikitable sortable"<br />
|-<br />
! Parameter !! Wertebereich !! Default !! Beschreibung<br />
|-<br />
|disable||[0,1]||0|| wenn 1, dann wird der Scanner gesperrt und ist somit inaktiv.<br />
|-<br />
|scnCreditThreshold||[150..600]||300|| die Mindestanzahl von verfügbaren Credits, ab der der Scanner mit dem Triggern der Thermostate beginnt<br />
|-<br />
|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.<br />
|-<br />
|}<br />
[[Kategorie:MAX]]</div>Johnhttp://wiki.fhem.de/w/index.php?title=MAX!_Temperatur-Scanner&diff=13473MAX! Temperatur-Scanner2016-01-06T19:24:17Z<p>John: /* Voraussetzungen */</p>
<hr />
<div>Der '''MAX! Temperatur-Scanner''' ist ein Perl-Skript, das die kontinuierliche Temperatur-Aufzeichnung<br />
von MAX-Thermostaten ermöglicht. <br />
<br />
== Features ==<br />
* kontinuierliche Erfassung von Temperatur und Ventil-Position <br />
* Berücksichtigung der System-Ressourcen (dutycycle, credits)<br />
* CUL und CUBE werden unterstützt<br />
* gleichberechtigte zeitliche Bearbeitung der Thermostate (Round-Robin-Prinzip)<br />
* Ermittlung der optimalen Scan-Rate über die Anzahl der eingebundenen Thermostate<br />
* 2 Scan-Modi stehen zur Verfügung (DesiredChange + ModeChange)<br />
<br />
== Zielsetzung des WIKI-Artikels ==<br />
Hier werden Fragen und Erkenntnisse zum Thema dargestellt, da der Forums-Eintrag für viele Anwender nicht mehr überschaubar ist.<br />
<br />
Der Artikel wird sukzessive erweitert.<br />
<br />
== Aktuelle Version ==<br />
Im Anhang zu folgendem Forumsbeitrag [http://forum.fhem.de/index.php/topic,11624.msg68237.html#msg68237 MaxScan Version 1.05c]<br />
<br />
=== Voraussetzungen ===<br />
==== Qualität der Funkverbindung ====<br />
In der Log-Datei sollten möglichst wenig Einträge der nachfolgenden Form auftreten<br />
<pre>2013.11.01 02:12:33 2: CUL_MAX_SendQueueHandler: Missing ack from 0905a5 for 0b0b0040123456xxxxxxxxx</pre><br />
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.<br />
<br />
==== Ausreichend Credits ====<br />
Der Scanner kann nicht aktiv werden, wenn gehäuft Log-Einträge der nachfolgenden Form auftreten.<br />
<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><br />
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.<br />
<br />
==== Einrichten des Thermostat-internen Wochenprogrammes ====<br />
Anders als bei den Vorgängerversionen <=1.04 ist nun ab Version 1.05 zwingend das Thermostat-interne<br />
Wochenprogramm notwendig.<br />
<br />
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.<br />
<br />
Das bei früheren Versionen eingesetzte Heating_Control kann somit entfallen.<br />
<br />
'''Bitte folgendes beachten:'''<br />
<br />
Es gibt im Zusammenhang mit dem Wochenprogramm ein Problem mit dem letzten Schaltpunkt des Tages. <br />
Der Workaround wurde [http://forum.fhem.de/index.php/topic,17231.msg112738.html#msg112738 hier]<br />
beschrieben.<br />
<br />
<big>Man muss dafür sorgen, dass man kurz vor Ende des Tages noch einen Schaltpunkt setzt.</big><br />
<br />
=== Inbetriebnahme ===<br />
* aktuell freigegebene Version von 99_UtilsMaxScan.pm in das Verzeichnis /opt/fhem/FHEM kopieren.<br />
* Bei den Thermostaten, die gescannt werden sollen, das Attribut scanTemp setzen via<br />
<pre>attr VT_HW scanTemp 1</pre><br />
* das Wochenprogramm im Thermostat nach den Bedürfnissen einstellen<br />
* auf''' keinen''' Fall das Attribut keepAuto setzen<br />
* mit dem userReading "onlyAutoMode" kann der Scan-Modus ModeChange festgelegt werden<br />
<pre>attr HT.JOHN userReadings onlyAutoMode { return "1";;}</pre> <br />
* ist ein ShutterContact mit dem Thermostat assoziiert, dann muss man dies bekannt machen mit dem UserReading<br />
<pre>attr VT_HW userReadings watchShutter { return "SHUTTER.HW";;}</pre><br />
* '''FHEM neu starten'''<br />
<br />
'''Hinweis'''<br /><br />
Je kleiner der Wert von Attribut verbose, umso weniger Ausgaben erhält man in der Log-Datei.<br />
<br />
== Mechanismen ==<br />
=== Das Problem ===<br />
Der Hersteller der MAX-Thermostate hat diese so konzipiert, dass die gemessene Temperatur und Ventilstellung nur übertragen werden, wenn sich Folgendes ändert:<br />
* die Ventilstellung<br />
* die Betriebsart (mode: auto,manu,temporary,boost)<br />
* der Sollwert<br />
<br />
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.<br />
<br />
=== Der Lösungsansatz ===<br />
==== Triggerung per Mode-Umschaltung (ModeChange) ====<br />
Dies ist der Default-Mode des Scanners.<br />
Hier wird der Ansatz verfolgt, die Betriebsart des Thermostats regelmässig umzuschalten via<br />
:AUTO ==> MANU<br />
<Wartezeit mindestens 3 Minuten><br />
:MANU ==> AUTO<br />
<br />
Dies veranlasst das Thermostat, regelmässig die gewünschten Werte an FHEM (den gepaarten Transceiver) zu senden.<br />
<br />
==== Triggerung per Sollwert-Umschaltung (DesiredChange) ====<br />
Durch Änderung des Sollwertes kann ebenso die Übertragung des Istwertes am Thermostat initiiert werden.<br />
<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.<br />
<br />
Dieser Modus wird durch die Definition des UserReadings "onlyAutoMode" festgelegt.<br />
:<code>attr HT.JOHN userReadings onlyAutoMode { return "1";;}</code><br />
<br />
'''Beispiel:'''<br />
<br />
Sollwert im Thermostat nach Wochenprofil: 18<br />
Fall A:<br />
----<br />
* Istwert 17<br />
* Sollwert A von Scanner gesetzt : 18.5<br />
* Sollwert B von Scanner gesetzt : 18.0<br />
* Der Scanner wechselt also von 18 auf 18.5 und zurück.<br />
<br />
Fall B:<br />
----<br />
* Istwert 19<br />
* Sollwert A von Scanner gesetzt : 17.5<br />
* Sollwert B von Scanner gesetzt : 18.0<br />
* Der Scanner wechselt also von 18 auf 17.5 und zurück.<br />
<br />
=== Ergebnis ===<br />
==== ohne Scanner ====<br />
[[Datei:2013_12_MaxScanner_Vorher.png|ohne Scanner]]<br />
<br />
==== mit Scanner (ScanMode=ModeChange) ====<br />
[[Datei:13_12_01_Scanner_ModeChange.png|mit Scanner]]<br />
<br />
==== mit Scanner (ScanMode=DesiredChange) ====<br />
[[Datei:13_12_01_Scanner_DesiredChange.png|mit Scanner]]<br />
<br />
=== Ressourcen ===<br />
Die Sendezeit jedes Teilnehmers ist auf 1% begrenzt.<br />
<br />
Konkret bedeutet dies, dass ein CUL ca. 33 Telegramme pro Stunde senden kann.<br />
Der MAX-Scanner darf nicht alle Ressourcen für sich beanspruchen, sondern sieht seine Aufgabe als nachrangig. <br />
<br />
Erst wenn mehr als 300 Credits (von max. 900 möglichen) zur Verfügung stehen, wird das Skript aktiv.<br />
<br />
== Fragen und Antworten ==<br />
=== Welchen ScanMode soll ich wählen? ===<br />
Nachfolgende Punkte können als Entscheidungskriterium dienen:<br />
<br />
'''ModeChange'''<br />
* keine Änderung des Sollwertes nötig<br />
* damit ist das Ventil "ruhiger", da sich die Regeldifferenz nicht durch den Scanner-Betrieb ändert.<br />
<br />
'''DesiredChange'''<br />
* der Auto-Modus wird niemals verlassen<br />
* Falls FHEM ausfällt, wird das Thermostat das gespeicherte Wochenprogramm nutzen<br />
<br />
=== Wie kann man den ScanMode nachträglich ändern? ===<br />
Man kann das userReading ändern, so dass es 0 liefert<br />
:<code>attr HT.JOHN userReadings onlyAutoMode { return "0";;}</code><br />
<br />
oder man löscht das userReading durch<br />
* Löschen aus dem attribut userReading<br />
* und Löschen des vorhandenen userReadings via<br />
:<code>deletereading HT.JOHN onlyAutoMode </code><br />
<br />
=== Was passiert, wenn der Sollwert am Thermostat manuell verstellt wird? ===<br />
Wenn der Sollwert manuell am Thermostat verändert wird, kann es bis zu 3 Minuten dauern, bis dieser an FHEM gemeldet wird.<br />
<br />
Wenn der Scanner in dieser Wartezeit aktiv wird, wird er den soeben geänderten Sollwert überschreiben. In diesem Fall bliebe die manuelle Änderung wirkungslos.<br />
<br />
Wird die manuelle Änderung des Sollwertes vom Scanner erkannt, so gilt dieser bis zum nächsten Schaltpunkt des internen Wochenprogrammes.<br />
<br />
=== Mehrere Thermostate in einer Gruppe? ===<br />
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.<br />
<br />
=== Was ist zu tun wenn, Thermostate zusammen mit einem Wandthermostat eingesetzt werden? ===<br />
In diesem Fall ist der Scanner überflüssig, da das Wandthermostat ohnehin eine detaillierte Kurve des Istwertes liefert.<br />
<br />
=== Sind Fensterkontakte sinnvoll? ===<br />
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 <br />
[http://www.elv.de/topic/tuer-fensterkontakt-sinn-und-unsinn.html Sinn und Unsinn von Fensterkontakten] zeigt.<br />
<br />
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. <br />
<br />
[[Datei:2013_11_02_Scanner_TSturz.png|Sturz-Temperatur-Erkennung]]<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 vermutlich mit einer WindowOpenDuration von 0 behoben werden, ausserdem ist im Hochsommer die Heizung ohnehin ausgeschaltet.<br />
<br />
Folgende Nachteile haben die Max-Fensterkontakte:<br />
* 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.<br />
* 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).<br />
<br />
=== Berücksichtigt der Scanner die Temperatur-Sturz-Erkennung? ===<br />
Wenn desiredTemperature=WindowsOpenTemperature, dann stellt der Scanner seine Arbeit ein. Ansonsten würde er durch aktive Modeumschaltung die WindowsOpenTemperature dauerhaft setzen.<br />
<br />
=== Kann der Scanner mit Fensterkontakten umgehen? ===<br />
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.<br />
<br />
Ausserdem wäre es fatal, wenn der Scanner in der Phase des offenen Fenster den Sollwert überschreiben würde. Bei offenem 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.<br />
<br />
=== Was ist denn, wenn ich noch einen zweiten Fensterkontakt habe? ===<br />
Derzeit wird nur 1 ShutterContact unterstützt. Möglicherweise wird in einer der nächsten Versionen die Funktionalität erweitert.<br />
<br />
=== Was passiert, wenn der Boost-Mode aktiviert wurde? ===<br />
Sobald dies der Scanner erkennt, stellt er seine Aktivität ein, bis wieder der Modus Auto oder Manu erscheint.<br />
<br />
=== Unterstützt der Scanner auch den MAX-ECO-Taster? ===<br />
Nein. Dies wird für künftige Versionen geplant.<br />
<br />
=== Beeinflusst der Scanner den Regelmechanismus des Thermostats? ===<br />
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.<br />
<br />
== Im Kochtopf ==<br />
<br />
* Scanner wird nicht mehr als Skript, sondern als Modul ausgeführt.<br />
* Mindestwert für Scan-Intervall, der nicht unterschritten werden darf<br />
* Möglichkeit mehrere Fensterkontakte einem Thermostat zuzuweisen<br />
* Verzögerte Reaktion nach Aktivieren des Fensterkontakts<br />
* Möglichkeit eine Gruppe von Thermostaten auf Eco-Mode zu schalten (z.B. ausgelöst über ECO-Taster)<br />
* Gruppenbildung über mehrere Thermostate (für Eco-Taster)<br />
* Fix: wenn bei desriredtemperatur ON,OFF anstelle einer Zahl erscheint.<br />
<br />
<br />
== Die Modul-Variante (Beta-Version) ==<br />
<br />
Die Modul-Variante ist derzeit in der Testphase. Sie soll die die Skript-Variante mittelfristig ablösen.<br />
<br />
=== Voraussetzungen ===<br />
* Download von Modul 98_MaxScanner.pm in das Modul-Verzeichnis von FHEM<br />
* die Script-Variante sollte deaktiviert werden (alle ScanTemp-Attribute auf 0 stellen oder 99_UtilsMaxScan löschen/verschieben)<br />
* FHEM neu starten<br />
<br />
=== Inbetriebnahme ===<br />
* Scanner Modul definieren<br />
<pre><br />
define Scanner MaxScanner<br />
attr Scanner verbose 1<br />
</pre><br />
<br />
* die bestehende Max-Thermostate verfügen nun automatisch über neue Attribute, die den Scanner betreffen<br />
* alle Scanner-spezfischen Attribute beginnen immer mit "scn"<br />
* im folgende Beispiel wird das Thermostat HT.JOHN betrachtet:<br />
<pre><br />
define HT.JOHN MAX HeatingThermostat 066666<br />
</pre><br />
* das Thermostat wird für den Scanner freigegeben<br />
<pre>attr HT.JOHN scnEnabled 1</pre><br />
* wir wählen die Betriebsart Mode-Change<br />
<pre>attr HT.JOHN scnProcessByDesiChange 0</pre><br />
* wir können 0..n ShutterContacts definieren, getrennt durch Komma<br />
<pre>attr HT.JOHN scnShutterList SHUTTER.JOHN,SHUTTER.BRENNER</pre><br />
* verbose liefert ausführliche Infos im Logger<br />
<pre>attr HT.JOHN verbose 4</pre><br />
<br />
=== Attribute Thermostat===<br />
{| class="wikitable sortable"<br />
|-<br />
! Parameter !! Wertebereich !! Default !! Beschreibung<br />
|-<br />
|scnEnabled||[0,1]||0||wenn 1, wird das Thermostat vom Scanner berücksichtigt<br />
|-<br />
|scnProcessByDesiChange||[0,1]||0||wenn 1, wird das Thermostat über die Änderung von desiredTemperature (DesiredChange) getriggert, ansonsten über die Änderung des Modes (ModeChange)<br />
|-<br />
|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<br />
Thermostat geschrieben wird. Ist hingegen NOCHANGE gewählt, so wird der aktuelle am Thermostat angewählte Mode belassen.<br />
|-<br />
|scnShutterList||||||Liste von assoziierten Max-Fensterkontakten (ShutterContacts), die durch ein Komma getrennt werden. <br />
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.<br />
<br />
|}<br />
=== Attribute Scanner===<br />
{| class="wikitable sortable"<br />
|-<br />
! Parameter !! Wertebereich !! Default !! Beschreibung<br />
|-<br />
|disable||[0,1]||0|| wenn 1, dann wird der Scanner gesperrt und ist somit inaktiv.<br />
|-<br />
|scnCreditThreshold||[150..600]||300|| die Mindestanzahl von verfügbaren Credits, ab der der Scanner mit dem Triggern der Thermostate beginnt<br />
|-<br />
|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.<br />
|-<br />
|}<br />
[[Kategorie:MAX]]</div>Johnhttp://wiki.fhem.de/w/index.php?title=MAX!_Temperatur-Scanner&diff=13457MAX! Temperatur-Scanner2016-01-05T11:52:48Z<p>John: /* Attribute Scanner */</p>
<hr />
<div>Der '''MAX! Temperatur-Scanner''' ist ein Perl-Skript, das die kontinuierliche Temperatur-Aufzeichnung<br />
von MAX-Thermostaten ermöglicht. <br />
<br />
== Features ==<br />
* kontinuierliche Erfassung von Temperatur und Ventil-Position <br />
* Berücksichtigung der System-Ressourcen (dutycycle, credits)<br />
* CUL und CUBE werden unterstützt<br />
* gleichberechtigte zeitliche Bearbeitung der Thermostate (Round-Robin-Prinzip)<br />
* Ermittlung der optimalen Scan-Rate über die Anzahl der eingebundenen Thermostate<br />
* 2 Scan-Modi stehen zur Verfügung (DesiredChange + ModeChange)<br />
<br />
== Zielsetzung des WIKI-Artikels ==<br />
Hier werden Fragen und Erkenntnisse zum Thema dargestellt, da der Forums-Eintrag für viele Anwender nicht mehr überschaubar ist.<br />
<br />
Der Artikel wird sukzessive erweitert.<br />
<br />
== Aktuelle Version ==<br />
Im Anhang zu folgendem Forumsbeitrag [http://forum.fhem.de/index.php/topic,11624.msg68237.html#msg68237 MaxScan Version 1.05c]<br />
<br />
=== Voraussetzungen ===<br />
==== Qualität der Funkverbindung ====<br />
In der Log-Datei sollten möglichst wenig Einträge der nachfolgenden Form auftreten<br />
<pre>2013.11.01 02:12:33 2: CUL_MAX_SendQueueHandler: Missing ack from 0905a5 for 0b0b0040123456xxxxxxxxx</pre><br />
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.<br />
<br />
==== Ausreichend Credits ====<br />
Der Scanner kann nicht aktiv werden, wenn gehäuft Log-Einträge der nachfolgenden Form auftreten.<br />
<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><br />
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.<br />
<br />
==== Einrichten des Thermostat-internen Wochenprogrammes ====<br />
Anders als bei den Vorgängerversionen <=1.04 ist nun ab Version 1.05 zwingend das Thermostat-interne<br />
Wochenprogramm notwendig.<br />
<br />
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.<br />
<br />
Das bei früheren Versionen eingesetzte Heating_Control kann somit entfallen.<br />
<br />
'''Bitte folgendes beachten:'''<br />
<br />
Es gibt im Zusammenhang mit dem Wochenprogramm ein Problem mit dem letzten Schaltpunkt des Tages. <br />
Der Workaround wurde [http://forum.fhem.de/index.php/topic,17231.msg112738.html#msg112738 hier]<br />
beschrieben.<br />
<br />
<big>Man muss dafür sorgen, dass man kurz vor Ende des Tages noch einen Schaltpunkt setzt.</big><br />
<br />
=== Inbetriebnahme ===<br />
* aktuell freigegebene Version von 99_UtilsMaxScan.pm in das Verzeichnis /opt/fhem/FHEM kopieren.<br />
* Bei den Thermostaten, die gescannt werden sollen, das Attribut scanTemp setzen via<br />
<pre>attr VT_HW scanTemp 1</pre><br />
* das Wochenprogramm im Thermostat nach den Bedürfnissen einstellen<br />
* auf''' keinen''' Fall das Attribut keepAuto setzen<br />
* mit dem userReading "onlyAutoMode" kann der Scan-Modus ModeChange festgelegt werden<br />
<pre>attr HT.JOHN userReadings onlyAutoMode { return "1";;}</pre> <br />
* ist ein ShutterContact mit dem Thermostat assoziiert, dann muss man dies bekannt machen mit dem UserReading<br />
<pre>attr VT_HW userReadings watchShutter { return "SHUTTER.HW";;}</pre><br />
* '''FHEM neu starten'''<br />
<br />
'''Hinweis'''<br /><br />
Je kleiner der Wert von Attribut verbose, umso weniger Ausgaben erhält man in der Log-Datei.<br />
<br />
== Mechanismen ==<br />
=== Das Problem ===<br />
Der Hersteller der MAX-Thermostate hat diese so konzipiert, dass die gemessene Temperatur und Ventilstellung nur übertragen werden, wenn sich Folgendes ändert:<br />
* die Ventilstellung<br />
* die Betriebsart (mode: auto,manu,temporary,boost)<br />
* der Sollwert<br />
<br />
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.<br />
<br />
=== Der Lösungsansatz ===<br />
==== Triggerung per Mode-Umschaltung (ModeChange) ====<br />
Dies ist der Default-Mode des Scanners.<br />
Hier wird der Ansatz verfolgt, die Betriebsart des Thermostats regelmässig umzuschalten via<br />
:AUTO ==> MANU<br />
<Wartezeit mindestens 3 Minuten><br />
:MANU ==> AUTO<br />
<br />
Dies veranlasst das Thermostat, regelmässig die gewünschten Werte an FHEM (den gepaarten Transceiver) zu senden.<br />
<br />
==== Triggerung per Sollwert-Umschaltung (DesiredChange) ====<br />
Durch Änderung des Sollwertes kann ebenso die Übertragung des Istwertes am Thermostat initiiert werden.<br />
<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.<br />
<br />
Dieser Modus wird durch die Definition des UserReadings "onlyAutoMode" festgelegt.<br />
:<code>attr HT.JOHN userReadings onlyAutoMode { return "1";;}</code><br />
<br />
'''Beispiel:'''<br />
<br />
Sollwert im Thermostat nach Wochenprofil: 18<br />
Fall A:<br />
----<br />
* Istwert 17<br />
* Sollwert A von Scanner gesetzt : 18.5<br />
* Sollwert B von Scanner gesetzt : 18.0<br />
* Der Scanner wechselt also von 18 auf 18.5 und zurück.<br />
<br />
Fall B:<br />
----<br />
* Istwert 19<br />
* Sollwert A von Scanner gesetzt : 17.5<br />
* Sollwert B von Scanner gesetzt : 18.0<br />
* Der Scanner wechselt also von 18 auf 17.5 und zurück.<br />
<br />
=== Ergebnis ===<br />
==== ohne Scanner ====<br />
[[Datei:2013_12_MaxScanner_Vorher.png|ohne Scanner]]<br />
<br />
==== mit Scanner (ScanMode=ModeChange) ====<br />
[[Datei:13_12_01_Scanner_ModeChange.png|mit Scanner]]<br />
<br />
==== mit Scanner (ScanMode=DesiredChange) ====<br />
[[Datei:13_12_01_Scanner_DesiredChange.png|mit Scanner]]<br />
<br />
=== Ressourcen ===<br />
Die Sendezeit jedes Teilnehmers ist auf 1% begrenzt.<br />
<br />
Konkret bedeutet dies, dass ein CUL ca. 33 Telegramme pro Stunde senden kann.<br />
Der MAX-Scanner darf nicht alle Ressourcen für sich beanspruchen, sondern sieht seine Aufgabe als nachrangig. <br />
<br />
Erst wenn mehr als 300 Credits (von max. 900 möglichen) zur Verfügung stehen, wird das Skript aktiv.<br />
<br />
== Fragen und Antworten ==<br />
=== Welchen ScanMode soll ich wählen? ===<br />
Nachfolgende Punkte können als Entscheidungskriterium dienen:<br />
<br />
'''ModeChange'''<br />
* keine Änderung des Sollwertes nötig<br />
* damit ist das Ventil "ruhiger", da sich die Regeldifferenz nicht durch den Scanner-Betrieb ändert.<br />
<br />
'''DesiredChange'''<br />
* der Auto-Modus wird niemals verlassen<br />
* Falls FHEM ausfällt, wird das Thermostat das gespeicherte Wochenprogramm nutzen<br />
<br />
=== Wie kann man den ScanMode nachträglich ändern? ===<br />
Man kann das userReading ändern, so dass es 0 liefert<br />
:<code>attr HT.JOHN userReadings onlyAutoMode { return "0";;}</code><br />
<br />
oder man löscht das userReading durch<br />
* Löschen aus dem attribut userReading<br />
* und Löschen des vorhandenen userReadings via<br />
:<code>deletereading HT.JOHN onlyAutoMode </code><br />
<br />
=== Was passiert, wenn der Sollwert am Thermostat manuell verstellt wird? ===<br />
Wenn der Sollwert manuell am Thermostat verändert wird, kann es bis zu 3 Minuten dauern, bis dieser an FHEM gemeldet wird.<br />
<br />
Wenn der Scanner in dieser Wartezeit aktiv wird, wird er den soeben geänderten Sollwert überschreiben. In diesem Fall bliebe die manuelle Änderung wirkungslos.<br />
<br />
Wird die manuelle Änderung des Sollwertes vom Scanner erkannt, so gilt dieser bis zum nächsten Schaltpunkt des internen Wochenprogrammes.<br />
<br />
=== Mehrere Thermostate in einer Gruppe? ===<br />
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.<br />
<br />
=== Was ist zu tun wenn, Thermostate zusammen mit einem Wandthermostat eingesetzt werden? ===<br />
In diesem Fall ist der Scanner überflüssig, da das Wandthermostat ohnehin eine detaillierte Kurve des Istwertes liefert.<br />
<br />
=== Sind Fensterkontakte sinnvoll? ===<br />
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 <br />
[http://www.elv.de/topic/tuer-fensterkontakt-sinn-und-unsinn.html Sinn und Unsinn von Fensterkontakten] zeigt.<br />
<br />
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. <br />
<br />
[[Datei:2013_11_02_Scanner_TSturz.png|Sturz-Temperatur-Erkennung]]<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 vermutlich mit einer WindowOpenDuration von 0 behoben werden, ausserdem ist im Hochsommer die Heizung ohnehin ausgeschaltet.<br />
<br />
Folgende Nachteile haben die Max-Fensterkontakte:<br />
* 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.<br />
* 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).<br />
<br />
=== Berücksichtigt der Scanner die Temperatur-Sturz-Erkennung? ===<br />
Wenn desiredTemperature=WindowsOpenTemperature, dann stellt der Scanner seine Arbeit ein. Ansonsten würde er durch aktive Modeumschaltung die WindowsOpenTemperature dauerhaft setzen.<br />
<br />
=== Kann der Scanner mit Fensterkontakten umgehen? ===<br />
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.<br />
<br />
Ausserdem wäre es fatal, wenn der Scanner in der Phase des offenen Fenster den Sollwert überschreiben würde. Bei offenem 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.<br />
<br />
=== Was ist denn, wenn ich noch einen zweiten Fensterkontakt habe? ===<br />
Derzeit wird nur 1 ShutterContact unterstützt. Möglicherweise wird in einer der nächsten Versionen die Funktionalität erweitert.<br />
<br />
=== Was passiert, wenn der Boost-Mode aktiviert wurde? ===<br />
Sobald dies der Scanner erkennt, stellt er seine Aktivität ein, bis wieder der Modus Auto oder Manu erscheint.<br />
<br />
=== Unterstützt der Scanner auch den MAX-ECO-Taster? ===<br />
Nein. Dies wird für künftige Versionen geplant.<br />
<br />
=== Beeinflusst der Scanner den Regelmechanismus des Thermostats? ===<br />
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.<br />
<br />
== Im Kochtopf ==<br />
<br />
* Scanner wird nicht mehr als Skript, sondern als Modul ausgeführt.<br />
* Mindestwert für Scan-Intervall, der nicht unterschritten werden darf<br />
* Möglichkeit mehrere Fensterkontakte einem Thermostat zuzuweisen<br />
* Verzögerte Reaktion nach Aktivieren des Fensterkontakts<br />
* Möglichkeit eine Gruppe von Thermostaten auf Eco-Mode zu schalten (z.B. ausgelöst über ECO-Taster)<br />
* Gruppenbildung über mehrere Thermostate (für Eco-Taster)<br />
* Fix: wenn bei desriredtemperatur ON,OFF anstelle einer Zahl erscheint.<br />
<br />
<br />
== Die Modul-Variante (Beta-Version) ==<br />
<br />
Die Modul-Variante ist derzeit in der Testphase. Sie soll die die Skript-Variante mittelfristig ablösen.<br />
<br />
=== Voraussetzungen ===<br />
* Download von Modul 98_MaxScanner.pm in das Modul-Verzeichnis von FHEM<br />
* die Script-Variante sollte deaktiviert werden (alle ScanTemp-Attribute auf 0 stellen)<br />
* FHEM neu starten<br />
<br />
=== Inbetriebnahme ===<br />
* Scanner Modul definieren<br />
<pre><br />
define Scanner MaxScanner<br />
attr Scanner verbose 1<br />
</pre><br />
<br />
* die bestehende Max-Thermostate verfügen nun automatisch über neue Attribute, die den Scanner betreffen<br />
* alle Scanner-spezfischen Attribute beginnen immer mit "scn"<br />
* im folgende Beispiel wird das Thermostat HT.JOHN betrachtet:<br />
<pre><br />
define HT.JOHN MAX HeatingThermostat 066666<br />
</pre><br />
* das Thermostat wird für den Scanner freigegeben<br />
<pre>attr HT.JOHN scnEnabled 1</pre><br />
* wir wählen die Betriebsart Mode-Change<br />
<pre>attr HT.JOHN scnProcessByDesiChange 0</pre><br />
* wir können 0..n ShutterContacts definieren, getrennt durch Komma<br />
<pre>attr HT.JOHN scnShutterList SHUTTER.JOHN,SHUTTER.BRENNER</pre><br />
* verbose liefert ausführliche Infos im Logger<br />
<pre>attr HT.JOHN verbose 4</pre><br />
<br />
=== Attribute Thermostat===<br />
{| class="wikitable sortable"<br />
|-<br />
! Parameter !! Wertebereich !! Default !! Beschreibung<br />
|-<br />
|scnEnabled||[0,1]||0||wenn 1, wird das Thermostat vom Scanner berücksichtigt<br />
|-<br />
|scnProcessByDesiChange||[0,1]||0||wenn 1, wird das Thermostat über die Änderung von desiredTemperature (DesiredChange) getriggert, ansonsten über die Änderung des Modes (ModeChange)<br />
|-<br />
|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<br />
Thermostat geschrieben wird. Ist hingegen NOCHANGE gewählt, so wird der aktuelle am Thermostat angewählte Mode belassen.<br />
|-<br />
|scnShutterList||||||Liste von assoziierten Max-Fensterkontakten (ShutterContacts), die durch ein Komma getrennt werden. <br />
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.<br />
<br />
|}<br />
=== Attribute Scanner===<br />
{| class="wikitable sortable"<br />
|-<br />
! Parameter !! Wertebereich !! Default !! Beschreibung<br />
|-<br />
|disable||[0,1]||0|| wenn 1, dann wird der Scanner gesperrt und ist somit inaktiv.<br />
|-<br />
|scnCreditThreshold||[150..600]||300|| die Mindestanzahl von verfügbaren Credits, ab der der Scanner mit dem Triggern der Thermostate beginnt<br />
|-<br />
|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.<br />
|-<br />
|}<br />
[[Kategorie:MAX]]</div>Johnhttp://wiki.fhem.de/w/index.php?title=MAX!_Temperatur-Scanner&diff=13456MAX! Temperatur-Scanner2016-01-05T10:19:14Z<p>John: /* Modul-Version neue Attribute des Thermostat s*/</p>
<hr />
<div>Der '''MAX! Temperatur-Scanner''' ist ein Perl-Skript, das die kontinuierliche Temperatur-Aufzeichnung<br />
von MAX-Thermostaten ermöglicht. <br />
<br />
== Features ==<br />
* kontinuierliche Erfassung von Temperatur und Ventil-Position <br />
* Berücksichtigung der System-Ressourcen (dutycycle, credits)<br />
* CUL und CUBE werden unterstützt<br />
* gleichberechtigte zeitliche Bearbeitung der Thermostate (Round-Robin-Prinzip)<br />
* Ermittlung der optimalen Scan-Rate über die Anzahl der eingebundenen Thermostate<br />
* 2 Scan-Modi stehen zur Verfügung (DesiredChange + ModeChange)<br />
<br />
== Zielsetzung des WIKI-Artikels ==<br />
Hier werden Fragen und Erkenntnisse zum Thema dargestellt, da der Forums-Eintrag für viele Anwender nicht mehr überschaubar ist.<br />
<br />
Der Artikel wird sukzessive erweitert.<br />
<br />
== Aktuelle Version ==<br />
Im Anhang zu folgendem Forumsbeitrag [http://forum.fhem.de/index.php/topic,11624.msg68237.html#msg68237 MaxScan Version 1.05c]<br />
<br />
=== Voraussetzungen ===<br />
==== Qualität der Funkverbindung ====<br />
In der Log-Datei sollten möglichst wenig Einträge der nachfolgenden Form auftreten<br />
<pre>2013.11.01 02:12:33 2: CUL_MAX_SendQueueHandler: Missing ack from 0905a5 for 0b0b0040123456xxxxxxxxx</pre><br />
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.<br />
<br />
==== Ausreichend Credits ====<br />
Der Scanner kann nicht aktiv werden, wenn gehäuft Log-Einträge der nachfolgenden Form auftreten.<br />
<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><br />
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.<br />
<br />
==== Einrichten des Thermostat-internen Wochenprogrammes ====<br />
Anders als bei den Vorgängerversionen <=1.04 ist nun ab Version 1.05 zwingend das Thermostat-interne<br />
Wochenprogramm notwendig.<br />
<br />
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.<br />
<br />
Das bei früheren Versionen eingesetzte Heating_Control kann somit entfallen.<br />
<br />
'''Bitte folgendes beachten:'''<br />
<br />
Es gibt im Zusammenhang mit dem Wochenprogramm ein Problem mit dem letzten Schaltpunkt des Tages. <br />
Der Workaround wurde [http://forum.fhem.de/index.php/topic,17231.msg112738.html#msg112738 hier]<br />
beschrieben.<br />
<br />
<big>Man muss dafür sorgen, dass man kurz vor Ende des Tages noch einen Schaltpunkt setzt.</big><br />
<br />
=== Inbetriebnahme ===<br />
* aktuell freigegebene Version von 99_UtilsMaxScan.pm in das Verzeichnis /opt/fhem/FHEM kopieren.<br />
* Bei den Thermostaten, die gescannt werden sollen, das Attribut scanTemp setzen via<br />
<pre>attr VT_HW scanTemp 1</pre><br />
* das Wochenprogramm im Thermostat nach den Bedürfnissen einstellen<br />
* auf''' keinen''' Fall das Attribut keepAuto setzen<br />
* mit dem userReading "onlyAutoMode" kann der Scan-Modus ModeChange festgelegt werden<br />
<pre>attr HT.JOHN userReadings onlyAutoMode { return "1";;}</pre> <br />
* ist ein ShutterContact mit dem Thermostat assoziiert, dann muss man dies bekannt machen mit dem UserReading<br />
<pre>attr VT_HW userReadings watchShutter { return "SHUTTER.HW";;}</pre><br />
* '''FHEM neu starten'''<br />
<br />
'''Hinweis'''<br /><br />
Je kleiner der Wert von Attribut verbose, umso weniger Ausgaben erhält man in der Log-Datei.<br />
<br />
== Mechanismen ==<br />
=== Das Problem ===<br />
Der Hersteller der MAX-Thermostate hat diese so konzipiert, dass die gemessene Temperatur und Ventilstellung nur übertragen werden, wenn sich Folgendes ändert:<br />
* die Ventilstellung<br />
* die Betriebsart (mode: auto,manu,temporary,boost)<br />
* der Sollwert<br />
<br />
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.<br />
<br />
=== Der Lösungsansatz ===<br />
==== Triggerung per Mode-Umschaltung (ModeChange) ====<br />
Dies ist der Default-Mode des Scanners.<br />
Hier wird der Ansatz verfolgt, die Betriebsart des Thermostats regelmässig umzuschalten via<br />
:AUTO ==> MANU<br />
<Wartezeit mindestens 3 Minuten><br />
:MANU ==> AUTO<br />
<br />
Dies veranlasst das Thermostat, regelmässig die gewünschten Werte an FHEM (den gepaarten Transceiver) zu senden.<br />
<br />
==== Triggerung per Sollwert-Umschaltung (DesiredChange) ====<br />
Durch Änderung des Sollwertes kann ebenso die Übertragung des Istwertes am Thermostat initiiert werden.<br />
<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.<br />
<br />
Dieser Modus wird durch die Definition des UserReadings "onlyAutoMode" festgelegt.<br />
:<code>attr HT.JOHN userReadings onlyAutoMode { return "1";;}</code><br />
<br />
'''Beispiel:'''<br />
<br />
Sollwert im Thermostat nach Wochenprofil: 18<br />
Fall A:<br />
----<br />
* Istwert 17<br />
* Sollwert A von Scanner gesetzt : 18.5<br />
* Sollwert B von Scanner gesetzt : 18.0<br />
* Der Scanner wechselt also von 18 auf 18.5 und zurück.<br />
<br />
Fall B:<br />
----<br />
* Istwert 19<br />
* Sollwert A von Scanner gesetzt : 17.5<br />
* Sollwert B von Scanner gesetzt : 18.0<br />
* Der Scanner wechselt also von 18 auf 17.5 und zurück.<br />
<br />
=== Ergebnis ===<br />
==== ohne Scanner ====<br />
[[Datei:2013_12_MaxScanner_Vorher.png|ohne Scanner]]<br />
<br />
==== mit Scanner (ScanMode=ModeChange) ====<br />
[[Datei:13_12_01_Scanner_ModeChange.png|mit Scanner]]<br />
<br />
==== mit Scanner (ScanMode=DesiredChange) ====<br />
[[Datei:13_12_01_Scanner_DesiredChange.png|mit Scanner]]<br />
<br />
=== Ressourcen ===<br />
Die Sendezeit jedes Teilnehmers ist auf 1% begrenzt.<br />
<br />
Konkret bedeutet dies, dass ein CUL ca. 33 Telegramme pro Stunde senden kann.<br />
Der MAX-Scanner darf nicht alle Ressourcen für sich beanspruchen, sondern sieht seine Aufgabe als nachrangig. <br />
<br />
Erst wenn mehr als 300 Credits (von max. 900 möglichen) zur Verfügung stehen, wird das Skript aktiv.<br />
<br />
== Fragen und Antworten ==<br />
=== Welchen ScanMode soll ich wählen? ===<br />
Nachfolgende Punkte können als Entscheidungskriterium dienen:<br />
<br />
'''ModeChange'''<br />
* keine Änderung des Sollwertes nötig<br />
* damit ist das Ventil "ruhiger", da sich die Regeldifferenz nicht durch den Scanner-Betrieb ändert.<br />
<br />
'''DesiredChange'''<br />
* der Auto-Modus wird niemals verlassen<br />
* Falls FHEM ausfällt, wird das Thermostat das gespeicherte Wochenprogramm nutzen<br />
<br />
=== Wie kann man den ScanMode nachträglich ändern? ===<br />
Man kann das userReading ändern, so dass es 0 liefert<br />
:<code>attr HT.JOHN userReadings onlyAutoMode { return "0";;}</code><br />
<br />
oder man löscht das userReading durch<br />
* Löschen aus dem attribut userReading<br />
* und Löschen des vorhandenen userReadings via<br />
:<code>deletereading HT.JOHN onlyAutoMode </code><br />
<br />
=== Was passiert, wenn der Sollwert am Thermostat manuell verstellt wird? ===<br />
Wenn der Sollwert manuell am Thermostat verändert wird, kann es bis zu 3 Minuten dauern, bis dieser an FHEM gemeldet wird.<br />
<br />
Wenn der Scanner in dieser Wartezeit aktiv wird, wird er den soeben geänderten Sollwert überschreiben. In diesem Fall bliebe die manuelle Änderung wirkungslos.<br />
<br />
Wird die manuelle Änderung des Sollwertes vom Scanner erkannt, so gilt dieser bis zum nächsten Schaltpunkt des internen Wochenprogrammes.<br />
<br />
=== Mehrere Thermostate in einer Gruppe? ===<br />
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.<br />
<br />
=== Was ist zu tun wenn, Thermostate zusammen mit einem Wandthermostat eingesetzt werden? ===<br />
In diesem Fall ist der Scanner überflüssig, da das Wandthermostat ohnehin eine detaillierte Kurve des Istwertes liefert.<br />
<br />
=== Sind Fensterkontakte sinnvoll? ===<br />
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 <br />
[http://www.elv.de/topic/tuer-fensterkontakt-sinn-und-unsinn.html Sinn und Unsinn von Fensterkontakten] zeigt.<br />
<br />
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. <br />
<br />
[[Datei:2013_11_02_Scanner_TSturz.png|Sturz-Temperatur-Erkennung]]<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 vermutlich mit einer WindowOpenDuration von 0 behoben werden, ausserdem ist im Hochsommer die Heizung ohnehin ausgeschaltet.<br />
<br />
Folgende Nachteile haben die Max-Fensterkontakte:<br />
* 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.<br />
* 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).<br />
<br />
=== Berücksichtigt der Scanner die Temperatur-Sturz-Erkennung? ===<br />
Wenn desiredTemperature=WindowsOpenTemperature, dann stellt der Scanner seine Arbeit ein. Ansonsten würde er durch aktive Modeumschaltung die WindowsOpenTemperature dauerhaft setzen.<br />
<br />
=== Kann der Scanner mit Fensterkontakten umgehen? ===<br />
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.<br />
<br />
Ausserdem wäre es fatal, wenn der Scanner in der Phase des offenen Fenster den Sollwert überschreiben würde. Bei offenem 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.<br />
<br />
=== Was ist denn, wenn ich noch einen zweiten Fensterkontakt habe? ===<br />
Derzeit wird nur 1 ShutterContact unterstützt. Möglicherweise wird in einer der nächsten Versionen die Funktionalität erweitert.<br />
<br />
=== Was passiert, wenn der Boost-Mode aktiviert wurde? ===<br />
Sobald dies der Scanner erkennt, stellt er seine Aktivität ein, bis wieder der Modus Auto oder Manu erscheint.<br />
<br />
=== Unterstützt der Scanner auch den MAX-ECO-Taster? ===<br />
Nein. Dies wird für künftige Versionen geplant.<br />
<br />
=== Beeinflusst der Scanner den Regelmechanismus des Thermostats? ===<br />
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.<br />
<br />
== Im Kochtopf ==<br />
<br />
* Scanner wird nicht mehr als Skript, sondern als Modul ausgeführt.<br />
* Mindestwert für Scan-Intervall, der nicht unterschritten werden darf<br />
* Möglichkeit mehrere Fensterkontakte einem Thermostat zuzuweisen<br />
* Verzögerte Reaktion nach Aktivieren des Fensterkontakts<br />
* Möglichkeit eine Gruppe von Thermostaten auf Eco-Mode zu schalten (z.B. ausgelöst über ECO-Taster)<br />
* Gruppenbildung über mehrere Thermostate (für Eco-Taster)<br />
* Fix: wenn bei desriredtemperatur ON,OFF anstelle einer Zahl erscheint.<br />
<br />
<br />
== Die Modul-Variante (Beta-Version) ==<br />
<br />
Die Modul-Variante ist derzeit in der Testphase. Sie soll die die Skript-Variante mittelfristig ablösen.<br />
<br />
=== Voraussetzungen ===<br />
* Download von Modul 98_MaxScanner.pm in das Modul-Verzeichnis von FHEM<br />
* die Script-Variante sollte deaktiviert werden (alle ScanTemp-Attribute auf 0 stellen)<br />
* FHEM neu starten<br />
<br />
=== Inbetriebnahme ===<br />
* Scanner Modul definieren<br />
<pre><br />
define Scanner MaxScanner<br />
attr Scanner verbose 1<br />
</pre><br />
<br />
* die bestehende Max-Thermostate verfügen nun automatisch über neue Attribute, die den Scanner betreffen<br />
* alle Scanner-spezfischen Attribute beginnen immer mit "scn"<br />
* im folgende Beispiel wird das Thermostat HT.JOHN betrachtet:<br />
<pre><br />
define HT.JOHN MAX HeatingThermostat 066666<br />
</pre><br />
* das Thermostat wird für den Scanner freigegeben<br />
<pre>attr HT.JOHN scnEnabled 1</pre><br />
* wir wählen die Betriebsart Mode-Change<br />
<pre>attr HT.JOHN scnProcessByDesiChange 0</pre><br />
* wir können 0..n ShutterContacts definieren, getrennt durch Komma<br />
<pre>attr HT.JOHN scnShutterList SHUTTER.JOHN,SHUTTER.BRENNER</pre><br />
* verbose liefert ausführliche Infos im Logger<br />
<pre>attr HT.JOHN verbose 4</pre><br />
<br />
=== Attribute Thermostat===<br />
{| class="wikitable sortable"<br />
|-<br />
! Parameter !! Wertebereich !! Default !! Beschreibung<br />
|-<br />
|scnEnabled||[0,1]||0||wenn 1, wird das Thermostat vom Scanner berücksichtigt<br />
|-<br />
|scnProcessByDesiChange||[0,1]||0||wenn 1, wird das Thermostat über die Änderung von desiredTemperature (DesiredChange) getriggert, ansonsten über die Änderung des Modes (ModeChange)<br />
|-<br />
|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<br />
Thermostat geschrieben wird. Ist hingegen NOCHANGE gewählt, so wird der aktuelle am Thermostat angewählte Mode belassen.<br />
|-<br />
|scnShutterList||||||Liste von assoziierten Max-Fensterkontakten (ShutterContacts), die durch ein Komma getrennt werden. <br />
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.<br />
<br />
|}<br />
<br />
<br />
[[Kategorie:MAX]]</div>Johnhttp://wiki.fhem.de/w/index.php?title=MAX!_Temperatur-Scanner&diff=13431MAX! Temperatur-Scanner2016-01-02T22:18:07Z<p>John: /* Modul-Variante (Beta-Version)*/</p>
<hr />
<div>Der '''MAX! Temperatur-Scanner''' ist ein Perl-Skript, das die kontinuierliche Temperatur-Aufzeichnung<br />
von MAX-Thermostaten ermöglicht. <br />
<br />
== Features ==<br />
* kontinuierliche Erfassung von Temperatur und Ventil-Position <br />
* Berücksichtigung der System-Ressourcen (dutycycle, credits)<br />
* CUL und CUBE werden unterstützt<br />
* gleichberechtigte zeitliche Bearbeitung der Thermostate (Round-Robin-Prinzip)<br />
* Ermittlung der optimalen Scan-Rate über die Anzahl der eingebundenen Thermostate<br />
* 2 Scan-Modi stehen zur Verfügung (DesiredChange + ModeChange)<br />
<br />
== Zielsetzung des WIKI-Artikels ==<br />
Hier werden Fragen und Erkenntnisse zum Thema dargestellt, da der Forums-Eintrag für viele Anwender nicht mehr überschaubar ist.<br />
<br />
Der Artikel wird sukzessive erweitert.<br />
<br />
== Aktuelle Version ==<br />
Im Anhang zu folgendem Forumsbeitrag [http://forum.fhem.de/index.php/topic,11624.msg68237.html#msg68237 MaxScan Version 1.05c]<br />
<br />
=== Voraussetzungen ===<br />
==== Qualität der Funkverbindung ====<br />
In der Log-Datei sollten möglichst wenig Einträge der nachfolgenden Form auftreten<br />
<pre>2013.11.01 02:12:33 2: CUL_MAX_SendQueueHandler: Missing ack from 0905a5 for 0b0b0040123456xxxxxxxxx</pre><br />
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.<br />
<br />
==== Ausreichend Credits ====<br />
Der Scanner kann nicht aktiv werden, wenn gehäuft Log-Einträge der nachfolgenden Form auftreten.<br />
<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><br />
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.<br />
<br />
==== Einrichten des Thermostat-internen Wochenprogrammes ====<br />
Anders als bei den Vorgängerversionen <=1.04 ist nun ab Version 1.05 zwingend das Thermostat-interne<br />
Wochenprogramm notwendig.<br />
<br />
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.<br />
<br />
Das bei früheren Versionen eingesetzte Heating_Control kann somit entfallen.<br />
<br />
'''Bitte folgendes beachten:'''<br />
<br />
Es gibt im Zusammenhang mit dem Wochenprogramm ein Problem mit dem letzten Schaltpunkt des Tages. <br />
Der Workaround wurde [http://forum.fhem.de/index.php/topic,17231.msg112738.html#msg112738 hier]<br />
beschrieben.<br />
<br />
<big>Man muss dafür sorgen, dass man kurz vor Ende des Tages noch einen Schaltpunkt setzt.</big><br />
<br />
=== Inbetriebnahme ===<br />
* aktuell freigegebene Version von 99_UtilsMaxScan.pm in das Verzeichnis /opt/fhem/FHEM kopieren.<br />
* Bei den Thermostaten, die gescannt werden sollen, das Attribut scanTemp setzen via<br />
<pre>attr VT_HW scanTemp 1</pre><br />
* das Wochenprogramm im Thermostat nach den Bedürfnissen einstellen<br />
* auf''' keinen''' Fall das Attribut keepAuto setzen<br />
* mit dem userReading "onlyAutoMode" kann der Scan-Modus ModeChange festgelegt werden<br />
<pre>attr HT.JOHN userReadings onlyAutoMode { return "1";;}</pre> <br />
* ist ein ShutterContact mit dem Thermostat assoziiert, dann muss man dies bekannt machen mit dem UserReading<br />
<pre>attr VT_HW userReadings watchShutter { return "SHUTTER.HW";;}</pre><br />
* '''FHEM neu starten'''<br />
<br />
'''Hinweis'''<br /><br />
Je kleiner der Wert von Attribut verbose, umso weniger Ausgaben erhält man in der Log-Datei.<br />
<br />
== Mechanismen ==<br />
=== Das Problem ===<br />
Der Hersteller der MAX-Thermostate hat diese so konzipiert, dass die gemessene Temperatur und Ventilstellung nur übertragen werden, wenn sich Folgendes ändert:<br />
* die Ventilstellung<br />
* die Betriebsart (mode: auto,manu,temporary,boost)<br />
* der Sollwert<br />
<br />
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.<br />
<br />
=== Der Lösungsansatz ===<br />
==== Triggerung per Mode-Umschaltung (ModeChange) ====<br />
Dies ist der Default-Mode des Scanners.<br />
Hier wird der Ansatz verfolgt, die Betriebsart des Thermostats regelmässig umzuschalten via<br />
:AUTO ==> MANU<br />
<Wartezeit mindestens 3 Minuten><br />
:MANU ==> AUTO<br />
<br />
Dies veranlasst das Thermostat, regelmässig die gewünschten Werte an FHEM (den gepaarten Transceiver) zu senden.<br />
<br />
==== Triggerung per Sollwert-Umschaltung (DesiredChange) ====<br />
Durch Änderung des Sollwertes kann ebenso die Übertragung des Istwertes am Thermostat initiiert werden.<br />
<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.<br />
<br />
Dieser Modus wird durch die Definition des UserReadings "onlyAutoMode" festgelegt.<br />
:<code>attr HT.JOHN userReadings onlyAutoMode { return "1";;}</code><br />
<br />
'''Beispiel:'''<br />
<br />
Sollwert im Thermostat nach Wochenprofil: 18<br />
Fall A:<br />
----<br />
* Istwert 17<br />
* Sollwert A von Scanner gesetzt : 18.5<br />
* Sollwert B von Scanner gesetzt : 18.0<br />
* Der Scanner wechselt also von 18 auf 18.5 und zurück.<br />
<br />
Fall B:<br />
----<br />
* Istwert 19<br />
* Sollwert A von Scanner gesetzt : 17.5<br />
* Sollwert B von Scanner gesetzt : 18.0<br />
* Der Scanner wechselt also von 18 auf 17.5 und zurück.<br />
<br />
=== Ergebnis ===<br />
==== ohne Scanner ====<br />
[[Datei:2013_12_MaxScanner_Vorher.png|ohne Scanner]]<br />
<br />
==== mit Scanner (ScanMode=ModeChange) ====<br />
[[Datei:13_12_01_Scanner_ModeChange.png|mit Scanner]]<br />
<br />
==== mit Scanner (ScanMode=DesiredChange) ====<br />
[[Datei:13_12_01_Scanner_DesiredChange.png|mit Scanner]]<br />
<br />
=== Ressourcen ===<br />
Die Sendezeit jedes Teilnehmers ist auf 1% begrenzt.<br />
<br />
Konkret bedeutet dies, dass ein CUL ca. 33 Telegramme pro Stunde senden kann.<br />
Der MAX-Scanner darf nicht alle Ressourcen für sich beanspruchen, sondern sieht seine Aufgabe als nachrangig. <br />
<br />
Erst wenn mehr als 300 Credits (von max. 900 möglichen) zur Verfügung stehen, wird das Skript aktiv.<br />
<br />
== Fragen und Antworten ==<br />
=== Welchen ScanMode soll ich wählen? ===<br />
Nachfolgende Punkte können als Entscheidungskriterium dienen:<br />
<br />
'''ModeChange'''<br />
* keine Änderung des Sollwertes nötig<br />
* damit ist das Ventil "ruhiger", da sich die Regeldifferenz nicht durch den Scanner-Betrieb ändert.<br />
<br />
'''DesiredChange'''<br />
* der Auto-Modus wird niemals verlassen<br />
* Falls FHEM ausfällt, wird das Thermostat das gespeicherte Wochenprogramm nutzen<br />
<br />
=== Wie kann man den ScanMode nachträglich ändern? ===<br />
Man kann das userReading ändern, so dass es 0 liefert<br />
:<code>attr HT.JOHN userReadings onlyAutoMode { return "0";;}</code><br />
<br />
oder man löscht das userReading durch<br />
* Löschen aus dem attribut userReading<br />
* und Löschen des vorhandenen userReadings via<br />
:<code>deletereading HT.JOHN onlyAutoMode </code><br />
<br />
=== Was passiert, wenn der Sollwert am Thermostat manuell verstellt wird? ===<br />
Wenn der Sollwert manuell am Thermostat verändert wird, kann es bis zu 3 Minuten dauern, bis dieser an FHEM gemeldet wird.<br />
<br />
Wenn der Scanner in dieser Wartezeit aktiv wird, wird er den soeben geänderten Sollwert überschreiben. In diesem Fall bliebe die manuelle Änderung wirkungslos.<br />
<br />
Wird die manuelle Änderung des Sollwertes vom Scanner erkannt, so gilt dieser bis zum nächsten Schaltpunkt des internen Wochenprogrammes.<br />
<br />
=== Mehrere Thermostate in einer Gruppe? ===<br />
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.<br />
<br />
=== Was ist zu tun wenn, Thermostate zusammen mit einem Wandthermostat eingesetzt werden? ===<br />
In diesem Fall ist der Scanner überflüssig, da das Wandthermostat ohnehin eine detaillierte Kurve des Istwertes liefert.<br />
<br />
=== Sind Fensterkontakte sinnvoll? ===<br />
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 <br />
[http://www.elv.de/topic/tuer-fensterkontakt-sinn-und-unsinn.html Sinn und Unsinn von Fensterkontakten] zeigt.<br />
<br />
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. <br />
<br />
[[Datei:2013_11_02_Scanner_TSturz.png|Sturz-Temperatur-Erkennung]]<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 vermutlich mit einer WindowOpenDuration von 0 behoben werden, ausserdem ist im Hochsommer die Heizung ohnehin ausgeschaltet.<br />
<br />
Folgende Nachteile haben die Max-Fensterkontakte:<br />
* 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.<br />
* 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).<br />
<br />
=== Berücksichtigt der Scanner die Temperatur-Sturz-Erkennung? ===<br />
Wenn desiredTemperature=WindowsOpenTemperature, dann stellt der Scanner seine Arbeit ein. Ansonsten würde er durch aktive Modeumschaltung die WindowsOpenTemperature dauerhaft setzen.<br />
<br />
=== Kann der Scanner mit Fensterkontakten umgehen? ===<br />
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.<br />
<br />
Ausserdem wäre es fatal, wenn der Scanner in der Phase des offenen Fenster den Sollwert überschreiben würde. Bei offenem 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.<br />
<br />
=== Was ist denn, wenn ich noch einen zweiten Fensterkontakt habe? ===<br />
Derzeit wird nur 1 ShutterContact unterstützt. Möglicherweise wird in einer der nächsten Versionen die Funktionalität erweitert.<br />
<br />
=== Was passiert, wenn der Boost-Mode aktiviert wurde? ===<br />
Sobald dies der Scanner erkennt, stellt er seine Aktivität ein, bis wieder der Modus Auto oder Manu erscheint.<br />
<br />
=== Unterstützt der Scanner auch den MAX-ECO-Taster? ===<br />
Nein. Dies wird für künftige Versionen geplant.<br />
<br />
=== Beeinflusst der Scanner den Regelmechanismus des Thermostats? ===<br />
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.<br />
<br />
== Im Kochtopf ==<br />
<br />
* Scanner wird nicht mehr als Skript, sondern als Modul ausgeführt.<br />
* Mindestwert für Scan-Intervall, der nicht unterschritten werden darf<br />
* Möglichkeit mehrere Fensterkontakte einem Thermostat zuzuweisen<br />
* Verzögerte Reaktion nach Aktivieren des Fensterkontakts<br />
* Möglichkeit eine Gruppe von Thermostaten auf Eco-Mode zu schalten (z.B. ausgelöst über ECO-Taster)<br />
* Gruppenbildung über mehrere Thermostate (für Eco-Taster)<br />
* Fix: wenn bei desriredtemperatur ON,OFF anstelle einer Zahl erscheint.<br />
<br />
<br />
== Die Modul-Variante (Beta-Version) ==<br />
<br />
Die Modul-Variante ist derzeit in der Testphase. Sie soll die die Skript-Variante mittelfristig ablösen.<br />
<br />
=== Voraussetzungen ===<br />
* Download von Modul 98_MaxScanner.pm in das Modul-Verzeichnis von FHEM<br />
* die Script-Variante sollte deaktiviert werden (alle ScanTemp-Attribute auf 0 stellen)<br />
* FHEM neu starten<br />
<br />
=== Inbetriebnahme ===<br />
* Scanner Modul definieren<br />
<pre><br />
define Scanner MaxScanner<br />
attr Scanner verbose 1<br />
</pre><br />
<br />
* die bestehende Max-Thermostate verfügen nun automatisch über neue Attribute, die den Scanner betreffen<br />
* alle scannerspezfischen Attribute beginnen immer mit "scn"<br />
* im folgende Beispiel wird das Thermostat HT.JOHN betrachtet:<br />
<pre><br />
define HT.JOHN MAX HeatingThermostat 066666<br />
</pre><br />
* das Thermostat wird für den Scanner freigegeben<br />
<pre>attr HT.JOHN scnEnabled 1</pre><br />
* wir wählen die Betriebsart Mode-Change<br />
<pre>attr HT.JOHN scnProcessByDesiChange 0</pre><br />
* wir können 0..n ShutterContacts definieren, getrennt durch Komma<br />
<pre>attr HT.JOHN scnShutterList SHUTTER.JOHN,SHUTTER.BRENNER</pre><br />
* verbose liefert ausführliche Infos im Logger<br />
<pre>attr HT.JOHN verbose 4</pre><br />
<br />
<br />
[[Kategorie:MAX]]</div>Johnhttp://wiki.fhem.de/w/index.php?title=HourCounter&diff=13405HourCounter2015-12-30T19:41:15Z<p>John: Änderungen im Zusammenhang mit FHEM 5.7 (EVTPART0,EVTPART1)</p>
<hr />
<div>{{Infobox Modul<br />
|ModPurpose=HourCounter dient zum Zählen von Ereignissen und zur Erfassung von Betriebs-/Ruhe-Zeiten<br />
|ModType=h<br />
<!-- |ModCmdRef=LightScene -- nicht erforderlich, da Modultyp x --><br />
|ModForumArea=MAX<br />
|ModTechName=98_HourCounter.pm<br />
|ModOwner=John ([http://forum.fhem.de/index.php?action=profile;u=806 Forum] / [[Benutzer Diskussion:John|Wiki]])}}<br />
<br />
<br />
[[HourCounter]] ist ein Perl-Modul, das die Anzahl von Ereignissen erfasst. Bei bipolaren Ereignissen wird zusätzlich die Puls- sowie die Pausendauer ermittelt. Im vorliegenden Beispiel wird ein Betriebsstundenzähler mit einem MAX-Fensterkontakt realisiert.<br />
<br />
== Features ==<br />
* Ermittlung von Betriebsstunden, Auslastung, Verbräuchen, Schalthäufigkeiten<br />
* Ermittlung der Häufigkeit, Puls- Pausendauer pro Tag<br />
* Ermittlung der Puls-/Pausendauer der letzten Schaltperiode<br />
* Bereitstellung von Ereignissen zur Fortführung der Kumulation für Tages-, Wochen- und Monatswerte<br />
* unterstützende Funktionen zur Ablage von Tages-, Wochen- und Monatswerten<br />
<br />
== Zielsetzung des WIKI-Artikels ==<br />
Erläuterung der Funktionalität zur weiterführenden Diskussion im [http://forum.fhem.de/index.php/topic,12216.msg72596.html#msg72596 Forum].<br />
<br />
== Aktuelle Version ==<br />
Das Modul ist seit dem 24.10.2014 Bestandteil von FHEM.<br />
<br />
== Definition ==<br />
=== Abstrakt ===<br />
<pre>define <name> HourCounter <regexp_for_ON> [<regexp_for_Off>]</pre><br />
<br />
<regexp_for_ON> ist ein regulärer Ausdruck der das Ereignis beschreibt.<br />
<br />
Wenn auch [<regexp_for_Off>] definiert ist, so sprechen wir von einem bipolarem Ereignis, das einen <br />
EIN- sowie einen AUS-Zustand aufweist.<br />
<br />
<regexp_for_ON> beschreibt in diesem Fall die positive Flanke,[<regexp_for_Off>] die negative Flanke. Die Struktur des regexp-Ausdruckes ist analog zu jener beim Notify aufgebaut.<br />
<br />
===Konkret===<br />
<pre>define CN.Test HourCounter SHUTTER.JOHN:onoff:.1 SHUTTER.JOHN:onoff:.0</pre><br />
Hier wird der HourCounter CN.TEST definiert.<br />
Ein MAX-Fensterkontakt mit Namen SHUTTER.JOHN wird als Ereignis-Geber verwendet.<br />
Das Reading "onoff" wird als Trigger für unserem Zähler genutzt.<br />
Bei den Fensterkontakten sehen diese Ereignisse wie folgt aus:<br />
<pre><br />
2013-11-15 23:19:12 MAX SHUTTER.JOHN onoff: 1<br />
....<br />
2013-11-15 23:19:24 MAX SHUTTER.JOHN onoff: 0<br />
</pre><br />
<br />
Soll ein Dummy als Ereignis-Geber verwendet werden, lautet die Definition wie folgt:<br />
<pre> define CN.Test HourCounter myDummy:1 myDummy:0</pre><br />
<br />
Die neue Instanz weist folgende Struktur auf:<br />
<br />
<pre><br />
Internals:<br />
CFGFN <br />
DEF SHUTTER.JOHN:onoff:.1 SHUTTER.JOHN:onoff:.0<br />
NAME CN.Test<br />
NR 738<br />
NTFY_ORDER 50-CN.Test<br />
STATE 1<br />
TYPE HourCounter<br />
Readings:<br />
2014-02-04 20:59:22 clearDate 2014-02-04 20:59:22<br />
2014-02-04 20:59:57 countsOverall 1<br />
2014-02-04 20:59:57 countsPerDay 1<br />
2014-02-04 20:59:57 pauseTimeIncrement 35<br />
2014-02-04 20:59:57 pauseTimeOverall 35<br />
2014-02-04 20:59:57 pauseTimePerDay 35<br />
2014-02-04 21:00:01 pulseTimeIncrement 4<br />
2014-02-04 21:00:01 pulseTimeOverall 4<br />
2014-02-04 21:00:01 pulseTimePerDay 4<br />
2014-02-04 20:59:57 state 1<br />
2014-02-04 21:00:00 tickHour 1<br />
2014-02-04 21:00:01 value 0<br />
Helper:<br />
OFF_Regexp SHUTTER.JOHN:onoff:.0<br />
ON_Regexp SHUTTER.JOHN:onoff:.1<br />
calledByEvent <br />
changedTimestamp 2014-02-04 21:00:01<br />
forceClear <br />
forceDayChange <br />
forceHourChange <br />
forceMonthChange <br />
forceWeekChange <br />
isFirstRun <br />
sdRoundHourLast 1391544000<br />
value 0<br />
cmdQueue:<br />
</pre><br />
<br />
Damit nicht zu viele Ereignisse in den Log-Dateien landen, kann man diese sinnvoll einschränken, so daß<br />
nur Änderungen das Feuern von Events auslösen<br />
<pre><br />
attr CN.BRENNER event-on-change-reading .*<br />
</pre><br />
Wenn sich nun jedoch über Stunden und Tage nichts ändert, sieht man in den Charts keine Daten mehr.<br />
Mit dieser Anweisung wird erreicht, daß alle Readings nach Aktualisierung spätesten nach 1 Stunden einen Event feuern, auch wenn sich der Wert nicht ändert.<br />
Eine Ausnahme hiervon sollen machen die tick*-Readings, deren Events sollen immer sofort gefeuert werden, <br />
wenn sie aktualisiert werden.<br />
<pre><br />
attr CN.BRENNER event-min-interval tick.*:0,.*:3600<br />
</pre><br />
<br />
== Readings ==<br />
{| class="wikitable sortable"<br />
|-<br />
! Reading !! class="unsortable" | Beschreibung <br />
|-<br />
| clearDate || Datum, zu dem alle kumulativen Readings über set .. clear gelöscht wurden<br />
|-<br />
| countsOverall || Absolutzähler für das Auftreten des ON-Ereignisses<br />
|-<br />
| countsPerDay || Tageszähler für das Auftreten des ON-Ereignisses<br />
|-<br />
| pauseTimeIncrement || Zeitdauer der Pausen-Phase in Sekunden ; wird zyklisch aktualisiert<br />
|-<br />
| pauseTimeEdge || Zeitdauer der letzten komplettierten Pausen-Phase<br />
|-<br />
| pauseTimeOverall || Zeitdauer in Sekunden über alle aufgetretenen Pause-Phasen<br />
|-<br />
| pauseTimePerDay || Zeitdauer in Sekunden über alle aufgetretenen Pause-Phasen des akt. Tages<br />
|-<br />
| pulseTimeIncrement || Zeitdauer der Puls-Phase in Sekunden ; wird zyklisch aktualisiert<br />
|-<br />
| pulseTimeEdge || Zeitdauer der letzten komplettierten Pulse-Phase<br />
|-<br />
| pulseTimeOverall || Zeitdauer in Sekunden über alle aufgetretenen Puls-Phasen<br />
|-<br />
| pulseTimePerDay || Zeitdauer in Sekunden über alle aufgetretenen Puls-Phasen des akt. Tages<br />
|-<br />
| value || Aktueller Schaltzustand gemäss ON/OFF Ereignis,<br /><br />
mit 1=letztes Ereignis war ON-Ereignis <br /><br />
und 0=letztes Ereignis war OFF-Ereignis<br />
|-<br />
| tickUpdated || Event wird gefeuert, wenn die operativen Readings beschrieben worden sind (nicht unbedingt gändert)<br />
|-<br />
| tickChanged || Event wird nach Änderung von value gefeuert<br />
|-<br />
| tickDay || Event wird nach Tageswechsel gefeuert bevor die Tageszähler resettiert werden<br />
|-<br />
| tickHour || Event wird nach Stundenwechsel gefeuert<br />
|-<br />
| tickWeek || Event wird nach Wochenwechsel gefeuert<br />
|-<br />
| tickMonth || Event wird nach Monatswechsel gefeuert<br />
|-<br />
| tickYear || Event wird nach Jahreswechsel gefeuert<br />
|-<br />
| forceHourChange || simuliert einen Stundenwechsel<br />
|-<br />
| forceDayChange || simuliert einen Tageswechsel<br />
|-<br />
| forceWeekChange || simuliert einen Wochenwechsel<br />
|-<br />
| forceMonthChange || simuliert einen Monatswechsel<br />
|-<br />
| forceYearChange || simuliert einen Jahreswechsel<br />
|}<br />
<br />
== Web-Oberfläche ==<br />
[[Datei:13_11_15_HourCounter_Face.png|HourCounter]]<br />
<br />
== Anwendung ==<br />
Nachfolgende Darstellung zeigt das Einschaltverhalten eines Heizungskessels zusammen mit den <br />
abgeleiteten Werten.<br />
<br />
[[Datei:13_11_15_HourCounter_Chart.png]]<br />
<br />
* die Kurve "Brenner EIN" zeigt die Trigger-Signale des ON/OFF Filters, also das Ein-/Ausschalten des Brenners<br />
* die Kurve "Brenner-Starts" zeigt die über den Tag aufgelaufenen Starts, also chronologisch das Anwachsen von Reading countsPerDay<br />
* die Kurve "Betriebsstunden" zeigt die aufgelaufene Zeit aus dem Reading pulseTimePerDay umgerechnet zu Stunden<br />
* die Kurve "Dauer" zeigt die Dauer des letzten Pulses in Sekunden<br />
* die Kurve Auslastung zeigt das Verhältnis des Readings pulseTimePerDay zur seit Tagesbeginn vergangenen Zeit.<br />
<br />
=== Chart der Aktualwerte ===<br />
Wir benötigen hierzu ein File-Archiv für die aufgelaufenen Daten.<br />
<pre>define CN.Test.File FileLog ./log/CN.Test-%Y.log (CN\.Test:.*)</pre><br />
Man erhält nach den ersten Ereignissen Einträge in folgender Form:<br />
<pre><br />
2013-11-16_12:45:40 CN.Test value: 1<br />
2013-11-16_12:45:40 CN.Test 1<br />
2013-11-16_12:46:21 CN.Test pulseTimeIncrement: 41 <br />
2013-11-16_12:46:21 CN.Test pulseTimePerDay: 41<br />
2013-11-16_12:46:21 CN.Test pulseTimeOverall: 41<br />
2013-11-16_12:46:21 CN.Test value: 0<br />
2013-11-16_12:50:38 CN.Test countsPerDay: 2<br />
2013-11-16_12:50:38 CN.Test countsOverall: 2<br />
2013-11-16_12:50:38 CN.Test pauseTimeIncrement: 257<br />
2013-11-16_12:50:38 CN.Test pauseTimePerDay: 756<br />
2013-11-16_12:50:38 CN.Test pauseTimeOverall: 756<br />
2013-11-16_12:50:38 CN.Test value: 1<br />
2013-11-16_12:50:38 CN.Test 2<br />
</pre><br />
<br />
Nun kann man den Chart definieren:<br />
[[Datei:13_11_16_HourCounter_ChartBuild_01.png]]<br />
<br />
Für die Kurve "Brenner EIN" verwenden wir CN.Test.value. Damit diese als unterste Kurve dargestellt wird transformieren wir den Wert 1 auf -2 und alle anderen (also die 0) auf -21 mit folgender Funktion:<br />
<pre>$fld[3]=~"1"?-2:-19</pre><br />
Die "Brenner Starts" können wir direkt von countsPerDay ableiten.<br /><br /><br />
Für die "Betriebsstunden" verwenden wir pulseTimePerDay. Da diese in Sekunden vorliegen teilen wir den Wert durch 3600, um Stunden zu erhalten.<br />
<pre>$fld[3]/=3600</pre><br />
Als letzten versorgen wir noch die Kurve "Dauer" mit pulseTimeIncrement. Da wir diese in Minuten haben wollen ist ebenfalls eine Umformung nötig.<br />
<pre>$fld[3]/=60</pre><br />
<br />
Somit sind die Basis-Kurven angelegt.<br />
<br />
=== Erweiterungen ===<br />
Es wurden im Forum viele Wünsche formuliert, weitere Funktionalitäten für den HourCounter einzuführen.<br />
<br />
* Aggregation über bestimmte oder ganz freie Zeiträume<br />
* komplexe Berechnungen, die zum Verbrauch führen<br />
* Zuordnung von Verbräuchen zu unterschiedlichen Countern nach bestimmten Bedingungen<br />
<br />
Vor allem die Aggregation erfasster Werte in Stunden-, Tages-, Wochen- und Monatswerten ist eine sinnvolle<br />
Erweiterung bei der Verbrauchserfassung.<br />
<br />
HourCounter bietet Schnittstellen an, die es ermöglichen, das Modul selbst mit neuen Eigenschaften zu erweitern.<br />
<br />
Die Referenz-Implementierung in 99_UtilsHourCounter.pm zeigt, wie dies skript-technisch zu realisieren ist.<br />
<br />
==== Installation ====<br />
Die jeweils aktuelle Version von 99_UtilsHourCounter kann über diesen <br />
[http://sourceforge.net/p/fhem/code/HEAD/tree/trunk/fhem/contrib/99_UtilsHourCounter.pm?format=raw Link] bezogen werden.<br />
<br /><br /><br />
Die Datei ist in da Unterverzeichnis FHEM vom FHEM-Homverzeichnis zu kopieren.<br />
<br /><br />
z.B. bei Raspberry Pi: /opt/fhem/FHEM<br />
<br /><br /><br />
Nach dem Kopieren und einen Neustart von FHEM kann man überprüfen, ob FHEM diese Datei findet.<br />
Wenn man das Menü "Edit Files " anwählt, wird auch 99_UtilsHourCounter angezeigt.<br />
<br />
==== Readings ====<br />
99_UtilsHourCounter erweitert den HourCounter um folgende Funktionen:<br />
{| class="wikitable sortable"<br />
|-<br />
! Reading !! class="unsortable" | Beschreibung<br />
|-<br />
| appCountsPerHour || Stundenzähler, wird bei Stundenwechsel aktualisiert<br />
|-<br />
| appCountsPerHourTemp || Arbeitszähler zu appCountsPerHour<br />
|-<br />
| appCountsPerDay || Tageszähler, wird bei Tageswechsel aktualisiert (Arbeitszähler ist countsPerDay)<br />
|-<br />
| appCountsPerWeek || Wochenzähler, wird bei Wochenwechsel aktualisiert<br />
|-<br />
| appCountsPerWeekTemp || Arbeitszähler zu appCountsPerWeek<br />
|-<br />
| appCountsPerMonth || Monatszähler, wird bei Monatswechsel aktualisiert<br />
|-<br />
| appCountsPerMonthTemp || Arbeitszähler zu appCountsPerMonth<br />
|-<br />
| appCountsPerYear || Jahreszähler, wird bei Jahreswechsel aktualisiert<br />
|-<br />
| appCountsPerYearTemp || Arbeitszähler zu appCountsPerYear<br />
|-<br />
| appOpHoursPerDay || Betriebsstunden des Tages<br />
|-<br />
| appOpHoursPerDayTemp || Arbeitszähler zu appOpHoursPerDay<br />
|-<br />
| appOpHoursPerWeek || Betriebsstunden der Woche<br />
|-<br />
| appOpHoursPerWeekTemp || Arbeitszähler zu appOpHoursPerWeek<br />
|-<br />
| appOpHoursPerMonth || Betriebsstunden des Monats<br />
|-<br />
| appOpHoursPerMonthTemp || Arbeitszähler appOpHoursPerMonth<br />
|-<br />
| appOpHoursPerYear || Betriebsstunden des Jahres<br />
|-<br />
| appOpHoursPerYearTemp || Arbeitszähler appOpHoursPerYear<br />
|-<br />
| appUtilization || Auslastung = pulseTimePerDay /(vergangene Sekunden seit Tagesbeginn) * 100<br />
|-<br />
| appUtilizationTemp || Arbeitsvariable zu appUtilization<br />
|}<br />
Beginn der Woche ist jeweils der Sonntag.<br /><br />
<br />
Mit folgender Anweisung aktivieren wir die Erweiterungen: <br />
:<code>define CN.EVENT notify CN\..*:tick.* { appHCNotify("$NAME","$EVTPART0","$EVTPART1");;}</code><br />
<br />
Spätestens nach einer steigenden und einer fallenden Flanke sind die zuvor genannten app*-Readings zu sehen.<br />
{{Randnotiz|RNTyp=Info|RNText=Die gezeigten define-Anweisungen müssen jeweils in einer Zeile stehen (keine Zeilenumbrüche!).}}<br />
<br />
Die neuen Readings werden automatisch in den "Setter" der Web-Oberflächen aufgenommen. Dies gilt für alle Readings, die mit "app" beginnen.<br />
<br />
Somit können die neuen Readings beliebig manipuliert werden.<br />
<br />
<br />
===== Für Anfänger die noch keine Erfahrungen mit Regular Expressions haben:=====<br />
Benennt eure Hourcounter nach dem Muster CN.<euer Wunschname>. Dann wird der notify immer funktionieren.<br /><br />
<br />
Beispiel: statt "PelletsCounter" wählt den Namen "CN.PelletsCounter"<br />
<br />
==== Archiv für Tages-/Wochen-/Monats-/Jahreswerte anlegen ====<br />
Nun wollen wir die aggregierten Werte in eine eigene Datei speichern. Dies gelingt mit <br />
:<code>define CN.Test.FileDay FileLog ./log/CN.Test-Day-%Y.log CN.Test:app\w*(Utilization|PerHour|PerDay|PerWeek|PerMonth|PerYear)(?!Temp).* </code><br />
<br />
<br />
Im Klartext:<br />
* verwende alle Werte des Counters CN.Test, deren Reading mit "app" beginnt<br />
* und die einen der Terme appUtilization|PerHour|PerDay|PerWeek|PerMonth|PerYear beinhalten<br />
* und die danach nicht dem Term "Temp" beinhalten<br />
<br />
== Fragen und Antworten ==<br />
==== Betriebsstundenzähler über Leistungsmessung ableiten ====<br />
'''Frage:'''<br />
Ich würde gerne zählen, wenn ich mehr Strom als Standy verbrauche (also mehr als 2Watt)<br />
und keine Betriebsstunden zählen, wenn der Verbrauch unter 2 Watt ist. Ist das möglich?<br />
<br />
<u>Beispiel für die Events</u><br />
<pre><br />
013-11-18_19:40:32 XXX power: 1.9<br />
2013-11-18_19:40:32 XXX consumption: 2<br />
2013-11-18_19:40:32 XXX consumptionTotal: 2<br />
2013-11-18_19:40:36 XXX power: 27<br />
2013-11-18_19:40:36 XXX consumption: 2<br />
2013-11-18_19:40:36 XXX consumptionTotal: 2<br />
2013-11-18_19:40:42 XXX power: 34.6<br />
2013-11-18_19:40:42 XXX consumption: 2 <br />
</pre><br />
<br />
'''Antwort'''<br />
Die hier vorgestellte Lösung überprüft ob der Wert des Events power eine oder zwei Ziffern vor dem Komma hat.<br />
Deshalb wir hier erst gezählt, wenn die Schwelle von 10Watt überschritten wird. <br />
<pre><br />
define CN.Test HourCounter XXX:power:\s[0-9]{2,}(\.[0-9]{1,3})*$ XXX:power:\s[0-9]{1}(\.[0-9]{1,3})*$<br />
</pre><br />
Erläuterung zu <regexp_for_ON> = XXX:power:\s[0-9]{2,}(\.[0-9]{1,3})*$<br />
* "XXX" bezeichnet das Device, der Term danach ist der regexp-Filte für das On-Ereignis<br />
* "power:" das Ereignis muss mit diesem Term beginnen<br />
* "\s" es muss ein Leerzeichen folgen<br />
* "[0-9]{2,}" es müssen mindestens 2 Ziffern folgen<br />
* "(\.[0-9]{1,3})*" wenn ein Punkt folgt, dann müssen auf diesen mindestens 1..3 Ziffern folgen<br />
* "$" danach darf kein weiteres Zeichen mehr folgen<br />
<br />
'''Antwort Möglichkeit 2'''<br />
In dieser Lösung bekommt das entsprechende Device was mit HourCounter überwacht werden soll ein userReadings "onoff". Dieses Reading wird dann zum Schalten von Hour Counter verwendet:<br />
<pre><br />
define GPIO4_DS18B20_Waermepumpe_Vorlauf GPIO4 28-000005956079<br />
attr GPIO4_DS18B20_Waermepumpe_Vorlauf alias Wärmepumpe Vorlauf<br />
attr GPIO4_DS18B20_Waermepumpe_Vorlauf model DS18B20<br />
attr GPIO4_DS18B20_Waermepumpe_Vorlauf room GPIO4<br />
attr GPIO4_DS18B20_Waermepumpe_Vorlauf userReadings onoff {(ReadingsVal("GPIO4_DS18B20_Waermepumpe_Vorlauf","temperature",0) >28)?1:0;;}<br />
<br />
define Waermepumpe_HourCounter HourCounter GPIO4_DS18B20_Waermepumpe_Vorlauf:onoff:.1 GPIO4_DS18B20_Waermepumpe_Vorlauf:onoff:.0<br />
attr Waermepumpe_HourCounter room 2_Fussbodenheizung<br />
</pre><br />
Erläuterungen zu dem Code: "{(ReadingsVal("GPIO4_DS18B20_Waermepumpe_Vorlauf","temperature",0) >28)?1:0;;}"<br />
* "(ReadingsVal("GPIO4_DS18B20_Waermepumpe_Vorlauf","temperature",0) >28)" Diese Bedingung für das userReadings onoff prüft bei jedem Event, ob der Wert von temperature größer als 28 ist. <br />
* "?1:0" Ist dies der Fall wird das userReading onoff auf 1 gesetzt andernfalls auf 0.<br />
Auf Basis deses UserReadings wird dann der HourCounter definiert:<br />
* "GPIO4_DS18B20_Waermepumpe_Vorlauf:onoff:.1" Einschaltbedingung für HourCounter<br />
* "GPIO4_DS18B20_Waermepumpe_Vorlauf:onoff:.0" Abschaltbedingung für Hour Counter<br />
<br />
==== Welche Anwendungsfälle sind denkbar ? ====<br />
[http://forum.fhem.de/index.php/topic,12216.msg175163.html#msg175163 Aus dem Forum]<br />
* Betriebsstundenzähler für meine "Fliegenkiller-Steckdose"<br />
* Nutzungsdauer beschränken für TV,Internet oder Spielkonsolen für entnervte Eltern<br />
* Nutzungsdauer ermitteln zur Energieeinsparung (Klimageräte, Ventilatoren, Dunstabzugshauben etc.)<br />
* Lüftungsverhalten ermitteln (wie lange Fenster pro Tag geöffnet)<br />
<br />
[http://forum.fhem.de/index.php/topic,12216.msg195358.html#msg195358 Brenner Starts/Verbrauch + akkumulierte Werte]<br />
<br />
[http://forum.fhem.de/index.php/topic,12216.msg196358.html#msg196358 Ölverbrauch+Solar-Ladung]<br />
<br />
[http://voizchat.de/gaszaehler-verbrauch-erfassen-mit-fhem-und-raspberry-gpio/ Gaszähler mit HourCounter realisieren]<br />
==== Seltene Schaltvorgänge ====<br />
Die Schaltvorgänge sind über den Tag sehr wenige. Die Aktualisierung erfolgt immer erst<br />
bei der negativen Flanke. Wie kann man eine häufigere Aktualisierung erreichen ?<br />
<br />
'''Antwort'''<br />
<br />
Ab Version 1.0.0.6 ist wurde das Attribut "interval" eingeführt; es ist auf 60 Minuten voreingestellt und kann von 5..60 im 5 Minuten-Raster festgelegt werden.<br />
Es bestimmt, nach welcher Zeit Puls-/Pausendauer aktualisiert werden sollen, unabhängig vom Auftreten einer Schaltflanke.<br />
<br />
==== Korrekte Darstellung der akkumulierten Daten im Chart ====<br />
'''Frage'''<br />
<br />
"appCountsPerDay: 4" bezieht sich auf die Counts des Tages 2014-06-16, trägt aber selbst den Zeitstempel 2014-06-17 und wird demnach in einem Chart auch über den Tag " 2014-06-17" dargestellt.<br />
Das Problem betrifft alle akkumulierten Daten des HourCounters.<br />
Wie erreicht man im Chart die korrekte Darstellung ?<br />
<br />
<br />
'''Antwort'''<br />
<br />
Das Thema wurde [http://forum.fhem.de/index.php/topic,12216.msg239929.html#msg239929 hier] disktuiert.<br />
Eine Lösung findet man mit [http://www.fhemwiki.de/wiki/LogProxy LogProxy].<br />
Damit läßt sich ein negativer Offset für die X-Achse definieren, so daß die Daten wieder korrekt dargestellt werden.<br />
<br />
[[Kategorie:MAX]]<br />
[[Kategorie:HOWTOS]]<br />
[[Kategorie:Heizungssteuerung]]</div>Johnhttp://wiki.fhem.de/w/index.php?title=HourCounter&diff=12690HourCounter2015-10-28T07:56:15Z<p>John: Hifle für Anfänger bei notify</p>
<hr />
<div>{{Infobox Modul<br />
|ModPurpose=HourCounter dient zum Zählen von Ereignissen und zur Erfassung von Betriebs-/Ruhe-Zeiten<br />
|ModType=h<br />
<!-- |ModCmdRef=LightScene -- nicht erforderlich, da Modultyp x --><br />
|ModForumArea=MAX<br />
|ModTechName=98_HourCounter.pm<br />
|ModOwner=John ([http://forum.fhem.de/index.php?action=profile;u=806 Forum] / [[Benutzer Diskussion:John|Wiki]])}}<br />
<br />
<br />
[[HourCounter]] ist ein Perl-Modul, das die Anzahl von Ereignissen erfasst. Bei bipolaren Ereignissen wird zusätzlich die Puls- sowie die Pausendauer ermittelt. Im vorliegenden Beispiel wird ein Betriebsstundenzähler mit einem MAX-Fensterkontakt realisiert.<br />
<br />
== Features ==<br />
* Ermittlung von Betriebsstunden, Auslastung, Verbräuchen, Schalthäufigkeiten<br />
* Ermittlung der Häufigkeit, Puls- Pausendauer pro Tag<br />
* Ermittlung der Puls-/Pausendauer der letzten Schaltperiode<br />
* Bereitstellung von Ereignissen zur Fortführung der Kumulation für Tages-, Wochen- und Monatswerte<br />
* unterstützende Funktionen zur Ablage von Tages-, Wochen- und Monatswerten<br />
<br />
== Zielsetzung des WIKI-Artikels ==<br />
Erläuterung der Funktionalität zur weiterführenden Diskussion im [http://forum.fhem.de/index.php/topic,12216.msg72596.html#msg72596 Forum].<br />
<br />
== Aktuelle Version ==<br />
Das Modul ist seit dem 24.10.2014 Bestandteil von FHEM.<br />
<br />
== Definition ==<br />
=== Abstrakt ===<br />
<pre>define <name> HourCounter <regexp_for_ON> [<regexp_for_Off>]</pre><br />
<br />
<regexp_for_ON> ist ein regulärer Ausdruck der das Ereignis beschreibt.<br />
<br />
Wenn auch [<regexp_for_Off>] definiert ist, so sprechen wir von einem bipolarem Ereignis, das einen <br />
EIN- sowie einen AUS-Zustand aufweist.<br />
<br />
<regexp_for_ON> beschreibt in diesem Fall die positive Flanke,[<regexp_for_Off>] die negative Flanke. Die Struktur des regexp-Ausdruckes ist analog zu jener beim Notify aufgebaut.<br />
<br />
===Konkret===<br />
<pre>define CN.Test HourCounter SHUTTER.JOHN:onoff:.1 SHUTTER.JOHN:onoff:.0</pre><br />
Hier wird der HourCounter CN.TEST definiert.<br />
Ein MAX-Fensterkontakt mit Namen SHUTTER.JOHN wird als Ereignis-Geber verwendet.<br />
Das Reading "onoff" wird als Trigger für unserem Zähler genutzt.<br />
Bei den Fensterkontakten sehen diese Ereignisse wie folgt aus:<br />
<pre><br />
2013-11-15 23:19:12 MAX SHUTTER.JOHN onoff: 1<br />
....<br />
2013-11-15 23:19:24 MAX SHUTTER.JOHN onoff: 0<br />
</pre><br />
<br />
Soll ein Dummy als Ereignis-Geber verwendet werden, lautet die Definition wie folgt:<br />
<pre> define CN.Test HourCounter myDummy:1 myDummy:0</pre><br />
<br />
Die neue Instanz weist folgende Struktur auf:<br />
<br />
<pre><br />
Internals:<br />
CFGFN <br />
DEF SHUTTER.JOHN:onoff:.1 SHUTTER.JOHN:onoff:.0<br />
NAME CN.Test<br />
NR 738<br />
NTFY_ORDER 50-CN.Test<br />
STATE 1<br />
TYPE HourCounter<br />
Readings:<br />
2014-02-04 20:59:22 clearDate 2014-02-04 20:59:22<br />
2014-02-04 20:59:57 countsOverall 1<br />
2014-02-04 20:59:57 countsPerDay 1<br />
2014-02-04 20:59:57 pauseTimeIncrement 35<br />
2014-02-04 20:59:57 pauseTimeOverall 35<br />
2014-02-04 20:59:57 pauseTimePerDay 35<br />
2014-02-04 21:00:01 pulseTimeIncrement 4<br />
2014-02-04 21:00:01 pulseTimeOverall 4<br />
2014-02-04 21:00:01 pulseTimePerDay 4<br />
2014-02-04 20:59:57 state 1<br />
2014-02-04 21:00:00 tickHour 1<br />
2014-02-04 21:00:01 value 0<br />
Helper:<br />
OFF_Regexp SHUTTER.JOHN:onoff:.0<br />
ON_Regexp SHUTTER.JOHN:onoff:.1<br />
calledByEvent <br />
changedTimestamp 2014-02-04 21:00:01<br />
forceClear <br />
forceDayChange <br />
forceHourChange <br />
forceMonthChange <br />
forceWeekChange <br />
isFirstRun <br />
sdRoundHourLast 1391544000<br />
value 0<br />
cmdQueue:<br />
</pre><br />
<br />
Damit nicht zu viele Ereignisse in den Log-Dateien landen, kann man diese sinnvoll einschränken, so daß<br />
nur Änderungen das Feuern von Events auslösen<br />
<pre><br />
attr CN.BRENNER event-on-change-reading .*<br />
</pre><br />
Wenn sich nun jedoch über Stunden und Tage nichts ändert, sieht man in den Charts keine Daten mehr.<br />
Mit dieser Anweisung wird erreicht, daß alle Readings nach Aktualisierung spätesten nach 1 Stunden einen Event feuern, auch wenn sich der Wert nicht ändert.<br />
Eine Ausnahme hiervon sollen machen die tick*-Readings, deren Events sollen immer sofort gefeuert werden, <br />
wenn sie aktualisiert werden.<br />
<pre><br />
attr CN.BRENNER event-min-interval tick.*:0,.*:3600<br />
</pre><br />
<br />
== Readings ==<br />
{| class="wikitable sortable"<br />
|-<br />
! Reading !! class="unsortable" | Beschreibung <br />
|-<br />
| clearDate || Datum, zu dem alle kumulativen Readings über set .. clear gelöscht wurden<br />
|-<br />
| countsOverall || Absolutzähler für das Auftreten des ON-Ereignisses<br />
|-<br />
| countsPerDay || Tageszähler für das Auftreten des ON-Ereignisses<br />
|-<br />
| pauseTimeIncrement || Zeitdauer der Pausen-Phase in Sekunden ; wird zyklisch aktualisiert<br />
|-<br />
| pauseTimeEdge || Zeitdauer der letzten komplettierten Pausen-Phase<br />
|-<br />
| pauseTimeOverall || Zeitdauer in Sekunden über alle aufgetretenen Pause-Phasen<br />
|-<br />
| pauseTimePerDay || Zeitdauer in Sekunden über alle aufgetretenen Pause-Phasen des akt. Tages<br />
|-<br />
| pulseTimeIncrement || Zeitdauer der Puls-Phase in Sekunden ; wird zyklisch aktualisiert<br />
|-<br />
| pulseTimeEdge || Zeitdauer der letzten komplettierten Pulse-Phase<br />
|-<br />
| pulseTimeOverall || Zeitdauer in Sekunden über alle aufgetretenen Puls-Phasen<br />
|-<br />
| pulseTimePerDay || Zeitdauer in Sekunden über alle aufgetretenen Puls-Phasen des akt. Tages<br />
|-<br />
| value || Aktueller Schaltzustand gemäss ON/OFF Ereignis,<br /><br />
mit 1=letztes Ereignis war ON-Ereignis <br /><br />
und 0=letztes Ereignis war OFF-Ereignis<br />
|-<br />
| tickUpdated || Event wird gefeuert, wenn die operativen Readings beschrieben worden sind (nicht unbedingt gändert)<br />
|-<br />
| tickChanged || Event wird nach Änderung von value gefeuert<br />
|-<br />
| tickDay || Event wird nach Tageswechsel gefeuert bevor die Tageszähler resettiert werden<br />
|-<br />
| tickHour || Event wird nach Stundenwechsel gefeuert<br />
|-<br />
| tickWeek || Event wird nach Wochenwechsel gefeuert<br />
|-<br />
| tickMonth || Event wird nach Monatswechsel gefeuert<br />
|-<br />
| tickYear || Event wird nach Jahreswechsel gefeuert<br />
|-<br />
| forceHourChange || simuliert einen Stundenwechsel<br />
|-<br />
| forceDayChange || simuliert einen Tageswechsel<br />
|-<br />
| forceWeekChange || simuliert einen Wochenwechsel<br />
|-<br />
| forceMonthChange || simuliert einen Monatswechsel<br />
|-<br />
| forceYearChange || simuliert einen Jahreswechsel<br />
|}<br />
<br />
== Web-Oberfläche ==<br />
[[Datei:13_11_15_HourCounter_Face.png|HourCounter]]<br />
<br />
== Anwendung ==<br />
Nachfolgende Darstellung zeigt das Einschaltverhalten eines Heizungskessels zusammen mit den <br />
abgeleiteten Werten.<br />
<br />
[[Datei:13_11_15_HourCounter_Chart.png]]<br />
<br />
* die Kurve "Brenner EIN" zeigt die Trigger-Signale des ON/OFF Filters, also das Ein-/Ausschalten des Brenners<br />
* die Kurve "Brenner-Starts" zeigt die über den Tag aufgelaufenen Starts, also chronologisch das Anwachsen von Reading countsPerDay<br />
* die Kurve "Betriebsstunden" zeigt die aufgelaufene Zeit aus dem Reading pulseTimePerDay umgerechnet zu Stunden<br />
* die Kurve "Dauer" zeigt die Dauer des letzten Pulses in Sekunden<br />
* die Kurve Auslastung zeigt das Verhältnis des Readings pulseTimePerDay zur seit Tagesbeginn vergangenen Zeit.<br />
<br />
=== Chart der Aktualwerte ===<br />
Wir benötigen hierzu ein File-Archiv für die aufgelaufenen Daten.<br />
<pre>define CN.Test.File FileLog ./log/CN.Test-%Y.log (CN\.Test:.*)</pre><br />
Man erhält nach den ersten Ereignissen Einträge in folgender Form:<br />
<pre><br />
2013-11-16_12:45:40 CN.Test value: 1<br />
2013-11-16_12:45:40 CN.Test 1<br />
2013-11-16_12:46:21 CN.Test pulseTimeIncrement: 41 <br />
2013-11-16_12:46:21 CN.Test pulseTimePerDay: 41<br />
2013-11-16_12:46:21 CN.Test pulseTimeOverall: 41<br />
2013-11-16_12:46:21 CN.Test value: 0<br />
2013-11-16_12:50:38 CN.Test countsPerDay: 2<br />
2013-11-16_12:50:38 CN.Test countsOverall: 2<br />
2013-11-16_12:50:38 CN.Test pauseTimeIncrement: 257<br />
2013-11-16_12:50:38 CN.Test pauseTimePerDay: 756<br />
2013-11-16_12:50:38 CN.Test pauseTimeOverall: 756<br />
2013-11-16_12:50:38 CN.Test value: 1<br />
2013-11-16_12:50:38 CN.Test 2<br />
</pre><br />
<br />
Nun kann man den Chart definieren:<br />
[[Datei:13_11_16_HourCounter_ChartBuild_01.png]]<br />
<br />
Für die Kurve "Brenner EIN" verwenden wir CN.Test.value. Damit diese als unterste Kurve dargestellt wird transformieren wir den Wert 1 auf -2 und alle anderen (also die 0) auf -21 mit folgender Funktion:<br />
<pre>$fld[3]=~"1"?-2:-19</pre><br />
Die "Brenner Starts" können wir direkt von countsPerDay ableiten.<br /><br /><br />
Für die "Betriebsstunden" verwenden wir pulseTimePerDay. Da diese in Sekunden vorliegen teilen wir den Wert durch 3600, um Stunden zu erhalten.<br />
<pre>$fld[3]/=3600</pre><br />
Als letzten versorgen wir noch die Kurve "Dauer" mit pulseTimeIncrement. Da wir diese in Minuten haben wollen ist ebenfalls eine Umformung nötig.<br />
<pre>$fld[3]/=60</pre><br />
<br />
Somit sind die Basis-Kurven angelegt.<br />
<br />
=== Erweiterungen ===<br />
Es wurden im Forum viele Wünsche formuliert, weitere Funktionalitäten für den HourCounter einzuführen.<br />
<br />
* Aggregation über bestimmte oder ganz freie Zeiträume<br />
* komplexe Berechnungen, die zum Verbrauch führen<br />
* Zuordnung von Verbräuchen zu unterschiedlichen Countern nach bestimmten Bedingungen<br />
<br />
Vor allem die Aggregation erfasster Werte in Stunden-, Tages-, Wochen- und Monatswerten ist eine sinnvolle<br />
Erweiterung bei der Verbrauchserfassung.<br />
<br />
HourCounter bietet Schnittstellen an, die es ermöglichen, das Modul selbst mit neuen Eigenschaften zu erweitern.<br />
<br />
Die Referenz-Implementierung in 99_UtilsHourCounter.pm zeigt, wie dies skript-technisch zu realisieren ist.<br />
<br />
==== Installation ====<br />
Die jeweils aktuelle Version von 99_UtilsHourCounter kann über diesen <br />
[http://sourceforge.net/p/fhem/code/HEAD/tree/trunk/fhem/contrib/99_UtilsHourCounter.pm?format=raw Link] bezogen werden.<br />
<br /><br /><br />
Die Datei ist in da Unterverzeichnis FHEM vom FHEM-Homverzeichnis zu kopieren.<br />
<br /><br />
z.B. bei Raspberry Pi: /opt/fhem/FHEM<br />
<br /><br /><br />
Nach dem Kopieren und einen Neustart von FHEM kann man überprüfen, ob FHEM diese Datei findet.<br />
Wenn man das Menü "Edit Files " anwählt, wird auch 99_UtilsHourCounter angezeigt.<br />
<br />
==== Readings ====<br />
99_UtilsHourCounter erweitert den HourCounter um folgende Funktionen:<br />
{| class="wikitable sortable"<br />
|-<br />
! Reading !! class="unsortable" | Beschreibung<br />
|-<br />
| appCountsPerHour || Stundenzähler, wird bei Stundenwechsel aktualisiert<br />
|-<br />
| appCountsPerHourTemp || Arbeitszähler zu appCountsPerHour<br />
|-<br />
| appCountsPerDay || Tageszähler, wird bei Tageswechsel aktualisiert (Arbeitszähler ist countsPerDay)<br />
|-<br />
| appCountsPerWeek || Wochenzähler, wird bei Wochenwechsel aktualisiert<br />
|-<br />
| appCountsPerWeekTemp || Arbeitszähler zu appCountsPerWeek<br />
|-<br />
| appCountsPerMonth || Monatszähler, wird bei Monatswechsel aktualisiert<br />
|-<br />
| appCountsPerMonthTemp || Arbeitszähler zu appCountsPerMonth<br />
|-<br />
| appCountsPerYear || Jahreszähler, wird bei Jahreswechsel aktualisiert<br />
|-<br />
| appCountsPerYearTemp || Arbeitszähler zu appCountsPerYear<br />
|-<br />
| appOpHoursPerDay || Betriebsstunden des Tages<br />
|-<br />
| appOpHoursPerDayTemp || Arbeitszähler zu appOpHoursPerDay<br />
|-<br />
| appOpHoursPerWeek || Betriebsstunden der Woche<br />
|-<br />
| appOpHoursPerWeekTemp || Arbeitszähler zu appOpHoursPerWeek<br />
|-<br />
| appOpHoursPerMonth || Betriebsstunden des Monats<br />
|-<br />
| appOpHoursPerMonthTemp || Arbeitszähler appOpHoursPerMonth<br />
|-<br />
| appOpHoursPerYear || Betriebsstunden des Jahres<br />
|-<br />
| appOpHoursPerYearTemp || Arbeitszähler appOpHoursPerYear<br />
|-<br />
| appUtilization || Auslastung = pulseTimePerDay /(vergangene Sekunden seit Tagesbeginn) * 100<br />
|-<br />
| appUtilizationTemp || Arbeitsvariable zu appUtilization<br />
|}<br />
Beginn der Woche ist jeweils der Sonntag.<br /><br />
<br />
Mit folgender Anweisung aktivieren wir die Erweiterungen: <br />
:<code><br />
define CN.EVENT notify CN\..*:tick.* { appHCNotify("%NAME","%EVTPART0","%EVTPART1");;}<br />
</code><br />
<br />
Spätestens nach einer steigenden und einer fallenden Flanke sind die zuvor genannten app*-Readings zu sehen.<br />
{{Randnotiz|RNTyp=Info|RNText=Die gezeigten define-Anweisungen müssen jeweils in einer Zeile stehen (keine Zeilenumbrüche!).}}<br />
<br />
Die neuen Readings werden automatisch in den "Setter" der Web-Oberflächen aufgenommen. Dies gilt für alle Readings, die mit "app" beginnen.<br />
<br />
Somit können die neuen Readings beliebig manipuliert werden.<br />
<br />
<br />
===== Für Anfänger die noch keine Erfahrungen mit Regular Expressions haben:=====<br />
Benennt eure Hourcounter nach dem Muster CN.<euer Wunschname>. Dann wird der notify immer funktionieren.<br /><br />
<br />
Beispiel: statt "PelletsCounter" wählt den Namen "CN.PelletsCounter"<br />
<br />
==== Archiv für Tages-/Wochen-/Monats-/Jahreswerte anlegen ====<br />
Nun wollen wir die aggregierten Werte in eine eigene Datei speichern. Dies gelingt mit <br />
:<code>define CN.Test.FileDay FileLog ./log/CN.Test-Day-%Y.log CN.Test:app\w*(Utilization|PerHour|PerDay|PerWeek|PerMonth|PerYear)(?!Temp).* </code><br />
<br />
<br />
Im Klartext:<br />
* verwende alle Werte des Counters CN.Test, deren Reading mit "app" beginnt<br />
* und die einen der Terme appUtilization|PerHour|PerDay|PerWeek|PerMonth|PerYear beinhalten<br />
* und die danach nicht dem Term "Temp" beinhalten<br />
<br />
== Fragen und Antworten ==<br />
==== Betriebsstundenzähler über Leistungsmessung ableiten ====<br />
'''Frage:'''<br />
Ich würde gerne zählen, wenn ich mehr Strom als Standy verbrauche (also mehr als 2Watt)<br />
und keine Betriebsstunden zählen, wenn der Verbrauch unter 2 Watt ist. Ist das möglich?<br />
<br />
<u>Beispiel für die Events</u><br />
<pre><br />
013-11-18_19:40:32 XXX power: 1.9<br />
2013-11-18_19:40:32 XXX consumption: 2<br />
2013-11-18_19:40:32 XXX consumptionTotal: 2<br />
2013-11-18_19:40:36 XXX power: 27<br />
2013-11-18_19:40:36 XXX consumption: 2<br />
2013-11-18_19:40:36 XXX consumptionTotal: 2<br />
2013-11-18_19:40:42 XXX power: 34.6<br />
2013-11-18_19:40:42 XXX consumption: 2 <br />
</pre><br />
<br />
'''Antwort'''<br />
Die hier vorgestellte Lösung überprüft ob der Wert des Events power eine oder zwei Ziffern vor dem Komma hat.<br />
Deshalb wir hier erst gezählt, wenn die Schwelle von 10Watt überschritten wird. <br />
<pre><br />
define CN.Test HourCounter XXX:power:\s[0-9]{2,}(\.[0-9]{1,3})*$ XXX:power:\s[0-9]{1}(\.[0-9]{1,3})*$<br />
</pre><br />
Erläuterung zu <regexp_for_ON> = XXX:power:\s[0-9]{2,}(\.[0-9]{1,3})*$<br />
* "XXX" bezeichnet das Device, der Term danach ist der regexp-Filte für das On-Ereignis<br />
* "power:" das Ereignis muss mit diesem Term beginnen<br />
* "\s" es muss ein Leerzeichen folgen<br />
* "[0-9]{2,}" es müssen mindestens 2 Ziffern folgen<br />
* "(\.[0-9]{1,3})*" wenn ein Punkt folgt, dann müssen auf diesen mindestens 1..3 Ziffern folgen<br />
* "$" danach darf kein weiteres Zeichen mehr folgen<br />
<br />
'''Antwort Möglichkeit 2'''<br />
In dieser Lösung bekommt das entsprechende Device was mit HourCounter überwacht werden soll ein userReadings "onoff". Dieses Reading wird dann zum Schalten von Hour Counter verwendet:<br />
<pre><br />
define GPIO4_DS18B20_Waermepumpe_Vorlauf GPIO4 28-000005956079<br />
attr GPIO4_DS18B20_Waermepumpe_Vorlauf alias Wärmepumpe Vorlauf<br />
attr GPIO4_DS18B20_Waermepumpe_Vorlauf model DS18B20<br />
attr GPIO4_DS18B20_Waermepumpe_Vorlauf room GPIO4<br />
attr GPIO4_DS18B20_Waermepumpe_Vorlauf userReadings onoff {(ReadingsVal("GPIO4_DS18B20_Waermepumpe_Vorlauf","temperature",0) >28)?1:0;;}<br />
<br />
define Waermepumpe_HourCounter HourCounter GPIO4_DS18B20_Waermepumpe_Vorlauf:onoff:.1 GPIO4_DS18B20_Waermepumpe_Vorlauf:onoff:.0<br />
attr Waermepumpe_HourCounter room 2_Fussbodenheizung<br />
</pre><br />
Erläuterungen zu dem Code: "{(ReadingsVal("GPIO4_DS18B20_Waermepumpe_Vorlauf","temperature",0) >28)?1:0;;}"<br />
* "(ReadingsVal("GPIO4_DS18B20_Waermepumpe_Vorlauf","temperature",0) >28)" Diese Bedingung für das userReadings onoff prüft bei jedem Event, ob der Wert von temperature größer als 28 ist. <br />
* "?1:0" Ist dies der Fall wird das userReading onoff auf 1 gesetzt andernfalls auf 0.<br />
Auf Basis deses UserReadings wird dann der HourCounter definiert:<br />
* "GPIO4_DS18B20_Waermepumpe_Vorlauf:onoff:.1" Einschaltbedingung für HourCounter<br />
* "GPIO4_DS18B20_Waermepumpe_Vorlauf:onoff:.0" Abschaltbedingung für Hour Counter<br />
<br />
==== Welche Anwendungsfälle sind denkbar ? ====<br />
[http://forum.fhem.de/index.php/topic,12216.msg175163.html#msg175163 Aus dem Forum]<br />
* Betriebsstundenzähler für meine "Fliegenkiller-Steckdose"<br />
* Nutzungsdauer beschränken für TV,Internet oder Spielkonsolen für entnervte Eltern<br />
* Nutzungsdauer ermitteln zur Energieeinsparung (Klimageräte, Ventilatoren, Dunstabzugshauben etc.)<br />
* Lüftungsverhalten ermitteln (wie lange Fenster pro Tag geöffnet)<br />
<br />
[http://forum.fhem.de/index.php/topic,12216.msg195358.html#msg195358 Brenner Starts/Verbrauch + akkumulierte Werte]<br />
<br />
[http://forum.fhem.de/index.php/topic,12216.msg196358.html#msg196358 Ölverbrauch+Solar-Ladung]<br />
<br />
[http://voizchat.de/gaszaehler-verbrauch-erfassen-mit-fhem-und-raspberry-gpio/ Gaszähler mit HourCounter realisieren]<br />
==== Seltene Schaltvorgänge ====<br />
Die Schaltvorgänge sind über den Tag sehr wenige. Die Aktualisierung erfolgt immer erst<br />
bei der negativen Flanke. Wie kann man eine häufigere Aktualisierung erreichen ?<br />
<br />
'''Antwort'''<br />
<br />
Ab Version 1.0.0.6 ist wurde das Attribut "interval" eingeführt; es ist auf 60 Minuten voreingestellt und kann von 5..60 im 5 Minuten-Raster festgelegt werden.<br />
Es bestimmt, nach welcher Zeit Puls-/Pausendauer aktualisiert werden sollen, unabhängig vom Auftreten einer Schaltflanke.<br />
<br />
==== Korrekte Darstellung der akkumulierten Daten im Chart ====<br />
'''Frage'''<br />
<br />
"appCountsPerDay: 4" bezieht sich auf die Counts des Tages 2014-06-16, trägt aber selbst den Zeitstempel 2014-06-17 und wird demnach in einem Chart auch über den Tag " 2014-06-17" dargestellt.<br />
Das Problem betrifft alle akkumulierten Daten des HourCounters.<br />
Wie erreicht man im Chart die korrekte Darstellung ?<br />
<br />
<br />
'''Antwort'''<br />
<br />
Das Thema wurde [http://forum.fhem.de/index.php/topic,12216.msg239929.html#msg239929 hier] disktuiert.<br />
Eine Lösung findet man mit [http://www.fhemwiki.de/wiki/LogProxy LogProxy].<br />
Damit läßt sich ein negativer Offset für die X-Achse definieren, so daß die Daten wieder korrekt dargestellt werden.<br />
<br />
[[Kategorie:MAX]]<br />
[[Kategorie:HOWTOS]]<br />
[[Kategorie:Heizungssteuerung]]</div>Johnhttp://wiki.fhem.de/w/index.php?title=HourCounter&diff=12558HourCounter2015-10-17T13:57:52Z<p>John: /* Archiv für Tages-/Wochen-/Monats-/Jahreswerte anlegen - Regexp korrigiert*/</p>
<hr />
<div>{{Infobox Modul<br />
|ModPurpose=HourCounter dient zum Zählen von Ereignissen und zur Erfassung von Betriebs-/Ruhe-Zeiten<br />
|ModType=h<br />
<!-- |ModCmdRef=LightScene -- nicht erforderlich, da Modultyp x --><br />
|ModForumArea=MAX<br />
|ModTechName=98_HourCounter.pm<br />
|ModOwner=John ([http://forum.fhem.de/index.php?action=profile;u=806 Forum] / [[Benutzer Diskussion:John|Wiki]])}}<br />
<br />
<br />
[[HourCounter]] ist ein Perl-Modul, das die Anzahl von Ereignissen erfasst. Bei bipolaren Ereignissen wird zusätzlich die Puls- sowie die Pausendauer ermittelt. Im vorliegenden Beispiel wird ein Betriebsstundenzähler mit einem MAX-Fensterkontakt realisiert.<br />
<br />
== Features ==<br />
* Ermittlung von Betriebsstunden, Auslastung, Verbräuchen, Schalthäufigkeiten<br />
* Ermittlung der Häufigkeit, Puls- Pausendauer pro Tag<br />
* Ermittlung der Puls-/Pausendauer der letzten Schaltperiode<br />
* Bereitstellung von Ereignissen zur Fortführung der Kumulation für Tages-, Wochen- und Monatswerte<br />
* unterstützende Funktionen zur Ablage von Tages-, Wochen- und Monatswerten<br />
<br />
== Zielsetzung des WIKI-Artikels ==<br />
Erläuterung der Funktionalität zur weiterführenden Diskussion im [http://forum.fhem.de/index.php/topic,12216.msg72596.html#msg72596 Forum].<br />
<br />
== Aktuelle Version ==<br />
Das Modul ist seit dem 24.10.2014 Bestandteil von FHEM.<br />
<br />
== Definition ==<br />
=== Abstrakt ===<br />
<pre>define <name> HourCounter <regexp_for_ON> [<regexp_for_Off>]</pre><br />
<br />
<regexp_for_ON> ist ein regulärer Ausdruck der das Ereignis beschreibt.<br />
<br />
Wenn auch [<regexp_for_Off>] definiert ist, so sprechen wir von einem bipolarem Ereignis, das einen <br />
EIN- sowie einen AUS-Zustand aufweist.<br />
<br />
<regexp_for_ON> beschreibt in diesem Fall die positive Flanke,[<regexp_for_Off>] die negative Flanke. Die Struktur des regexp-Ausdruckes ist analog zu jener beim Notify aufgebaut.<br />
<br />
===Konkret===<br />
<pre>define CN.Test HourCounter SHUTTER.JOHN:onoff:.1 SHUTTER.JOHN:onoff:.0</pre><br />
Hier wird der HourCounter CN.TEST definiert.<br />
Ein MAX-Fensterkontakt mit Namen SHUTTER.JOHN wird als Ereignis-Geber verwendet.<br />
Das Reading "onoff" wird als Trigger für unserem Zähler genutzt.<br />
Bei den Fensterkontakten sehen diese Ereignisse wie folgt aus:<br />
<pre><br />
2013-11-15 23:19:12 MAX SHUTTER.JOHN onoff: 1<br />
....<br />
2013-11-15 23:19:24 MAX SHUTTER.JOHN onoff: 0<br />
</pre><br />
<br />
Soll ein Dummy als Ereignis-Geber verwendet werden, lautet die Definition wie folgt:<br />
<pre> define CN.Test HourCounter myDummy:1 myDummy:0</pre><br />
<br />
Die neue Instanz weist folgende Struktur auf:<br />
<br />
<pre><br />
Internals:<br />
CFGFN <br />
DEF SHUTTER.JOHN:onoff:.1 SHUTTER.JOHN:onoff:.0<br />
NAME CN.Test<br />
NR 738<br />
NTFY_ORDER 50-CN.Test<br />
STATE 1<br />
TYPE HourCounter<br />
Readings:<br />
2014-02-04 20:59:22 clearDate 2014-02-04 20:59:22<br />
2014-02-04 20:59:57 countsOverall 1<br />
2014-02-04 20:59:57 countsPerDay 1<br />
2014-02-04 20:59:57 pauseTimeIncrement 35<br />
2014-02-04 20:59:57 pauseTimeOverall 35<br />
2014-02-04 20:59:57 pauseTimePerDay 35<br />
2014-02-04 21:00:01 pulseTimeIncrement 4<br />
2014-02-04 21:00:01 pulseTimeOverall 4<br />
2014-02-04 21:00:01 pulseTimePerDay 4<br />
2014-02-04 20:59:57 state 1<br />
2014-02-04 21:00:00 tickHour 1<br />
2014-02-04 21:00:01 value 0<br />
Helper:<br />
OFF_Regexp SHUTTER.JOHN:onoff:.0<br />
ON_Regexp SHUTTER.JOHN:onoff:.1<br />
calledByEvent <br />
changedTimestamp 2014-02-04 21:00:01<br />
forceClear <br />
forceDayChange <br />
forceHourChange <br />
forceMonthChange <br />
forceWeekChange <br />
isFirstRun <br />
sdRoundHourLast 1391544000<br />
value 0<br />
cmdQueue:<br />
</pre><br />
<br />
Damit nicht zu viele Ereignisse in den Log-Dateien landen, kann man diese sinnvoll einschränken, so daß<br />
nur Änderungen das Feuern von Events auslösen<br />
<pre><br />
attr CN.BRENNER event-on-change-reading .*<br />
</pre><br />
Wenn sich nun jedoch über Stunden und Tage nichts ändert, sieht man in den Charts keine Daten mehr.<br />
Mit dieser Anweisung wird erreicht, daß alle Readings nach Aktualisierung spätesten nach 1 Stunden einen Event feuern, auch wenn sich der Wert nicht ändert.<br />
Eine Ausnahme hiervon sollen machen die tick*-Readings, deren Events sollen immer sofort gefeuert werden, <br />
wenn sie aktualisiert werden.<br />
<pre><br />
attr CN.BRENNER event-min-interval tick.*:0,.*:3600<br />
</pre><br />
<br />
== Readings ==<br />
{| class="wikitable sortable"<br />
|-<br />
! Reading !! class="unsortable" | Beschreibung <br />
|-<br />
| clearDate || Datum, zu dem alle kumulativen Readings über set .. clear gelöscht wurden<br />
|-<br />
| countsOverall || Absolutzähler für das Auftreten des ON-Ereignisses<br />
|-<br />
| countsPerDay || Tageszähler für das Auftreten des ON-Ereignisses<br />
|-<br />
| pauseTimeIncrement || Zeitdauer der Pausen-Phase in Sekunden ; wird zyklisch aktualisiert<br />
|-<br />
| pauseTimeEdge || Zeitdauer der letzten komplettierten Pausen-Phase<br />
|-<br />
| pauseTimeOverall || Zeitdauer in Sekunden über alle aufgetretenen Pause-Phasen<br />
|-<br />
| pauseTimePerDay || Zeitdauer in Sekunden über alle aufgetretenen Pause-Phasen des akt. Tages<br />
|-<br />
| pulseTimeIncrement || Zeitdauer der Puls-Phase in Sekunden ; wird zyklisch aktualisiert<br />
|-<br />
| pulseTimeEdge || Zeitdauer der letzten komplettierten Pulse-Phase<br />
|-<br />
| pulseTimeOverall || Zeitdauer in Sekunden über alle aufgetretenen Puls-Phasen<br />
|-<br />
| pulseTimePerDay || Zeitdauer in Sekunden über alle aufgetretenen Puls-Phasen des akt. Tages<br />
|-<br />
| value || Aktueller Schaltzustand gemäss ON/OFF Ereignis,<br /><br />
mit 1=letztes Ereignis war ON-Ereignis <br /><br />
und 0=letztes Ereignis war OFF-Ereignis<br />
|-<br />
| tickUpdated || Event wird gefeuert, wenn die operativen Readings beschrieben worden sind (nicht unbedingt gändert)<br />
|-<br />
| tickChanged || Event wird nach Änderung von value gefeuert<br />
|-<br />
| tickDay || Event wird nach Tageswechsel gefeuert bevor die Tageszähler resettiert werden<br />
|-<br />
| tickHour || Event wird nach Stundenwechsel gefeuert<br />
|-<br />
| tickWeek || Event wird nach Wochenwechsel gefeuert<br />
|-<br />
| tickMonth || Event wird nach Monatswechsel gefeuert<br />
|-<br />
| tickYear || Event wird nach Jahreswechsel gefeuert<br />
|-<br />
| forceHourChange || simuliert einen Stundenwechsel<br />
|-<br />
| forceDayChange || simuliert einen Tageswechsel<br />
|-<br />
| forceWeekChange || simuliert einen Wochenwechsel<br />
|-<br />
| forceMonthChange || simuliert einen Monatswechsel<br />
|-<br />
| forceYearChange || simuliert einen Jahreswechsel<br />
|}<br />
<br />
== Web-Oberfläche ==<br />
[[Datei:13_11_15_HourCounter_Face.png|HourCounter]]<br />
<br />
== Anwendung ==<br />
Nachfolgende Darstellung zeigt das Einschaltverhalten eines Heizungskessels zusammen mit den <br />
abgeleiteten Werten.<br />
<br />
[[Datei:13_11_15_HourCounter_Chart.png]]<br />
<br />
* die Kurve "Brenner EIN" zeigt die Trigger-Signale des ON/OFF Filters, also das Ein-/Ausschalten des Brenners<br />
* die Kurve "Brenner-Starts" zeigt die über den Tag aufgelaufenen Starts, also chronologisch das Anwachsen von Reading countsPerDay<br />
* die Kurve "Betriebsstunden" zeigt die aufgelaufene Zeit aus dem Reading pulseTimePerDay umgerechnet zu Stunden<br />
* die Kurve "Dauer" zeigt die Dauer des letzten Pulses in Sekunden<br />
* die Kurve Auslastung zeigt das Verhältnis des Readings pulseTimePerDay zur seit Tagesbeginn vergangenen Zeit.<br />
<br />
=== Chart der Aktualwerte ===<br />
Wir benötigen hierzu ein File-Archiv für die aufgelaufenen Daten.<br />
<pre>define CN.Test.File FileLog ./log/CN.Test-%Y.log (CN\.Test:.*)</pre><br />
Man erhält nach den ersten Ereignissen Einträge in folgender Form:<br />
<pre><br />
2013-11-16_12:45:40 CN.Test value: 1<br />
2013-11-16_12:45:40 CN.Test 1<br />
2013-11-16_12:46:21 CN.Test pulseTimeIncrement: 41 <br />
2013-11-16_12:46:21 CN.Test pulseTimePerDay: 41<br />
2013-11-16_12:46:21 CN.Test pulseTimeOverall: 41<br />
2013-11-16_12:46:21 CN.Test value: 0<br />
2013-11-16_12:50:38 CN.Test countsPerDay: 2<br />
2013-11-16_12:50:38 CN.Test countsOverall: 2<br />
2013-11-16_12:50:38 CN.Test pauseTimeIncrement: 257<br />
2013-11-16_12:50:38 CN.Test pauseTimePerDay: 756<br />
2013-11-16_12:50:38 CN.Test pauseTimeOverall: 756<br />
2013-11-16_12:50:38 CN.Test value: 1<br />
2013-11-16_12:50:38 CN.Test 2<br />
</pre><br />
<br />
Nun kann man den Chart definieren:<br />
[[Datei:13_11_16_HourCounter_ChartBuild_01.png]]<br />
<br />
Für die Kurve "Brenner EIN" verwenden wir CN.Test.value. Damit diese als unterste Kurve dargestellt wird transformieren wir den Wert 1 auf -2 und alle anderen (also die 0) auf -21 mit folgender Funktion:<br />
<pre>$fld[3]=~"1"?-2:-19</pre><br />
Die "Brenner Starts" können wir direkt von countsPerDay ableiten.<br /><br /><br />
Für die "Betriebsstunden" verwenden wir pulseTimePerDay. Da diese in Sekunden vorliegen teilen wir den Wert durch 3600, um Stunden zu erhalten.<br />
<pre>$fld[3]/=3600</pre><br />
Als letzten versorgen wir noch die Kurve "Dauer" mit pulseTimeIncrement. Da wir diese in Minuten haben wollen ist ebenfalls eine Umformung nötig.<br />
<pre>$fld[3]/=60</pre><br />
<br />
Somit sind die Basis-Kurven angelegt.<br />
<br />
=== Erweiterungen ===<br />
Es wurden im Forum viele Wünsche formuliert, weitere Funktionalitäten für den HourCounter einzuführen.<br />
<br />
* Aggregation über bestimmte oder ganz freie Zeiträume<br />
* komplexe Berechnungen, die zum Verbrauch führen<br />
* Zuordnung von Verbräuchen zu unterschiedlichen Countern nach bestimmten Bedingungen<br />
<br />
Vor allem die Aggregation erfasster Werte in Stunden-, Tages-, Wochen- und Monatswerten ist eine sinnvolle<br />
Erweiterung bei der Verbrauchserfassung.<br />
<br />
HourCounter bietet Schnittstellen an, die es ermöglichen, das Modul selbst mit neuen Eigenschaften zu erweitern.<br />
<br />
Die Referenz-Implementierung in 99_UtilsHourCounter.pm zeigt, wie dies skript-technisch zu realisieren ist.<br />
<br />
==== Installation ====<br />
Die jeweils aktuelle Version von 99_UtilsHourCounter kann über diesen <br />
[http://sourceforge.net/p/fhem/code/HEAD/tree/trunk/fhem/contrib/99_UtilsHourCounter.pm?format=raw Link] bezogen werden.<br />
<br /><br /><br />
Die Datei ist in da Unterverzeichnis FHEM vom FHEM-Homverzeichnis zu kopieren.<br />
<br /><br />
z.B. bei Raspberry Pi: /opt/fhem/FHEM<br />
<br /><br /><br />
Nach dem Kopieren und einen Neustart von FHEM kann man überprüfen, ob FHEM diese Datei findet.<br />
Wenn man das Menü "Edit Files " anwählt, wird auch 99_UtilsHourCounter angezeigt.<br />
<br />
==== Readings ====<br />
99_UtilsHourCounter erweitert den HourCounter um folgende Funktionen:<br />
{| class="wikitable sortable"<br />
|-<br />
! Reading !! class="unsortable" | Beschreibung<br />
|-<br />
| appCountsPerHour || Stundenzähler, wird bei Stundenwechsel aktualisiert<br />
|-<br />
| appCountsPerHourTemp || Arbeitszähler zu appCountsPerHour<br />
|-<br />
| appCountsPerDay || Tageszähler, wird bei Tageswechsel aktualisiert (Arbeitszähler ist countsPerDay)<br />
|-<br />
| appCountsPerWeek || Wochenzähler, wird bei Wochenwechsel aktualisiert<br />
|-<br />
| appCountsPerWeekTemp || Arbeitszähler zu appCountsPerWeek<br />
|-<br />
| appCountsPerMonth || Monatszähler, wird bei Monatswechsel aktualisiert<br />
|-<br />
| appCountsPerMonthTemp || Arbeitszähler zu appCountsPerMonth<br />
|-<br />
| appCountsPerYear || Jahreszähler, wird bei Jahreswechsel aktualisiert<br />
|-<br />
| appCountsPerYearTemp || Arbeitszähler zu appCountsPerYear<br />
|-<br />
| appOpHoursPerDay || Betriebsstunden des Tages<br />
|-<br />
| appOpHoursPerDayTemp || Arbeitszähler zu appOpHoursPerDay<br />
|-<br />
| appOpHoursPerWeek || Betriebsstunden der Woche<br />
|-<br />
| appOpHoursPerWeekTemp || Arbeitszähler zu appOpHoursPerWeek<br />
|-<br />
| appOpHoursPerMonth || Betriebsstunden des Monats<br />
|-<br />
| appOpHoursPerMonthTemp || Arbeitszähler appOpHoursPerMonth<br />
|-<br />
| appOpHoursPerYear || Betriebsstunden des Jahres<br />
|-<br />
| appOpHoursPerYearTemp || Arbeitszähler appOpHoursPerYear<br />
|-<br />
| appUtilization || Auslastung = pulseTimePerDay /(vergangene Sekunden seit Tagesbeginn) * 100<br />
|-<br />
| appUtilizationTemp || Arbeitsvariable zu appUtilization<br />
|}<br />
Beginn der Woche ist jeweils der Sonntag.<br /><br />
<br />
Mit folgender Anweisung aktivieren wir die Erweiterungen: <br />
:<code><br />
define CN.EVENT notify CN\..*:tick.* { appHCNotify("%NAME","%EVTPART0","%EVTPART1");;}<br />
</code><br />
<br />
Spätestens nach einer steigenden und einer fallenden Flanke sind die zuvor genannten app*-Readings zu sehen.<br />
{{Randnotiz|RNTyp=Info|RNText=Die gezeigten define-Anweisungen müssen jeweils in einer Zeile stehen (keine Zeilenumbrüche!).}}<br />
<br />
Die neuen Readings werden automatisch in den "Setter" der Web-Oberflächen aufgenommen. Dies gilt für alle Readings, die mit "app" beginnen.<br />
<br />
Somit können die neuen Readings beliebig manipuliert werden.<br />
<br />
==== Archiv für Tages-/Wochen-/Monats-/Jahreswerte anlegen ====<br />
Nun wollen wir die aggregierten Werte in eine eigene Datei speichern. Dies gelingt mit <br />
:<code>define CN.Test.FileDay FileLog ./log/CN.Test-Day-%Y.log CN.Test:app\w*(Utilization|PerHour|PerDay|PerWeek|PerMonth|PerYear)(?!Temp).* </code><br />
<br />
<br />
Im Klartext:<br />
* verwende alle Werte des Counters CN.Test, deren Reading mit "app" beginnt<br />
* und die einen der Terme appUtilization|PerHour|PerDay|PerWeek|PerMonth|PerYear beinhalten<br />
* und die danach nicht dem Term "Temp" beinhalten<br />
<br />
== Fragen und Antworten ==<br />
==== Betriebsstundenzähler über Leistungsmessung ableiten ====<br />
'''Frage:'''<br />
Ich würde gerne zählen, wenn ich mehr Strom als Standy verbrauche (also mehr als 2Watt)<br />
und keine Betriebsstunden zählen, wenn der Verbrauch unter 2 Watt ist. Ist das möglich?<br />
<br />
<u>Beispiel für die Events</u><br />
<pre><br />
013-11-18_19:40:32 XXX power: 1.9<br />
2013-11-18_19:40:32 XXX consumption: 2<br />
2013-11-18_19:40:32 XXX consumptionTotal: 2<br />
2013-11-18_19:40:36 XXX power: 27<br />
2013-11-18_19:40:36 XXX consumption: 2<br />
2013-11-18_19:40:36 XXX consumptionTotal: 2<br />
2013-11-18_19:40:42 XXX power: 34.6<br />
2013-11-18_19:40:42 XXX consumption: 2 <br />
</pre><br />
<br />
'''Antwort'''<br />
Die hier vorgestellte Lösung überprüft ob der Wert des Events power eine oder zwei Ziffern vor dem Komma hat.<br />
Deshalb wir hier erst gezählt, wenn die Schwelle von 10Watt überschritten wird. <br />
<pre><br />
define CN.Test HourCounter XXX:power:\s[0-9]{2,}(\.[0-9]{1,3})*$ XXX:power:\s[0-9]{1}(\.[0-9]{1,3})*$<br />
</pre><br />
Erläuterung zu <regexp_for_ON> = XXX:power:\s[0-9]{2,}(\.[0-9]{1,3})*$<br />
* "XXX" bezeichnet das Device, der Term danach ist der regexp-Filte für das On-Ereignis<br />
* "power:" das Ereignis muss mit diesem Term beginnen<br />
* "\s" es muss ein Leerzeichen folgen<br />
* "[0-9]{2,}" es müssen mindestens 2 Ziffern folgen<br />
* "(\.[0-9]{1,3})*" wenn ein Punkt folgt, dann müssen auf diesen mindestens 1..3 Ziffern folgen<br />
* "$" danach darf kein weiteres Zeichen mehr folgen<br />
<br />
'''Antwort Möglichkeit 2'''<br />
In dieser Lösung bekommt das entsprechende Device was mit HourCounter überwacht werden soll ein userReadings "onoff". Dieses Reading wird dann zum Schalten von Hour Counter verwendet:<br />
<pre><br />
define GPIO4_DS18B20_Waermepumpe_Vorlauf GPIO4 28-000005956079<br />
attr GPIO4_DS18B20_Waermepumpe_Vorlauf alias Wärmepumpe Vorlauf<br />
attr GPIO4_DS18B20_Waermepumpe_Vorlauf model DS18B20<br />
attr GPIO4_DS18B20_Waermepumpe_Vorlauf room GPIO4<br />
attr GPIO4_DS18B20_Waermepumpe_Vorlauf userReadings onoff {(ReadingsVal("GPIO4_DS18B20_Waermepumpe_Vorlauf","temperature",0) >28)?1:0;;}<br />
<br />
define Waermepumpe_HourCounter HourCounter GPIO4_DS18B20_Waermepumpe_Vorlauf:onoff:.1 GPIO4_DS18B20_Waermepumpe_Vorlauf:onoff:.0<br />
attr Waermepumpe_HourCounter room 2_Fussbodenheizung<br />
</pre><br />
Erläuterungen zu dem Code: "{(ReadingsVal("GPIO4_DS18B20_Waermepumpe_Vorlauf","temperature",0) >28)?1:0;;}"<br />
* "(ReadingsVal("GPIO4_DS18B20_Waermepumpe_Vorlauf","temperature",0) >28)" Diese Bedingung für das userReadings onoff prüft bei jedem Event, ob der Wert von temperature größer als 28 ist. <br />
* "?1:0" Ist dies der Fall wird das userReading onoff auf 1 gesetzt andernfalls auf 0.<br />
Auf Basis deses UserReadings wird dann der HourCounter definiert:<br />
* "GPIO4_DS18B20_Waermepumpe_Vorlauf:onoff:.1" Einschaltbedingung für HourCounter<br />
* "GPIO4_DS18B20_Waermepumpe_Vorlauf:onoff:.0" Abschaltbedingung für Hour Counter<br />
<br />
==== Welche Anwendungsfälle sind denkbar ? ====<br />
[http://forum.fhem.de/index.php/topic,12216.msg175163.html#msg175163 Aus dem Forum]<br />
* Betriebsstundenzähler für meine "Fliegenkiller-Steckdose"<br />
* Nutzungsdauer beschränken für TV,Internet oder Spielkonsolen für entnervte Eltern<br />
* Nutzungsdauer ermitteln zur Energieeinsparung (Klimageräte, Ventilatoren, Dunstabzugshauben etc.)<br />
* Lüftungsverhalten ermitteln (wie lange Fenster pro Tag geöffnet)<br />
<br />
[http://forum.fhem.de/index.php/topic,12216.msg195358.html#msg195358 Brenner Starts/Verbrauch + akkumulierte Werte]<br />
<br />
[http://forum.fhem.de/index.php/topic,12216.msg196358.html#msg196358 Ölverbrauch+Solar-Ladung]<br />
<br />
[http://voizchat.de/gaszaehler-verbrauch-erfassen-mit-fhem-und-raspberry-gpio/ Gaszähler mit HourCounter realisieren]<br />
==== Seltene Schaltvorgänge ====<br />
Die Schaltvorgänge sind über den Tag sehr wenige. Die Aktualisierung erfolgt immer erst<br />
bei der negativen Flanke. Wie kann man eine häufigere Aktualisierung erreichen ?<br />
<br />
'''Antwort'''<br />
<br />
Ab Version 1.0.0.6 ist wurde das Attribut "interval" eingeführt; es ist auf 60 Minuten voreingestellt und kann von 5..60 im 5 Minuten-Raster festgelegt werden.<br />
Es bestimmt, nach welcher Zeit Puls-/Pausendauer aktualisiert werden sollen, unabhängig vom Auftreten einer Schaltflanke.<br />
<br />
==== Korrekte Darstellung der akkumulierten Daten im Chart ====<br />
'''Frage'''<br />
<br />
"appCountsPerDay: 4" bezieht sich auf die Counts des Tages 2014-06-16, trägt aber selbst den Zeitstempel 2014-06-17 und wird demnach in einem Chart auch über den Tag " 2014-06-17" dargestellt.<br />
Das Problem betrifft alle akkumulierten Daten des HourCounters.<br />
Wie erreicht man im Chart die korrekte Darstellung ?<br />
<br />
<br />
'''Antwort'''<br />
<br />
Das Thema wurde [http://forum.fhem.de/index.php/topic,12216.msg239929.html#msg239929 hier] disktuiert.<br />
Eine Lösung findet man mit [http://www.fhemwiki.de/wiki/LogProxy LogProxy].<br />
Damit läßt sich ein negativer Offset für die X-Achse definieren, so daß die Daten wieder korrekt dargestellt werden.<br />
<br />
[[Kategorie:MAX]]<br />
[[Kategorie:HOWTOS]]<br />
[[Kategorie:Heizungssteuerung]]</div>Johnhttp://wiki.fhem.de/w/index.php?title=HourCounter&diff=9726HourCounter2015-02-01T09:45:12Z<p>John: /* Installation Überprüfung*/</p>
<hr />
<div>{{Infobox Modul<br />
|ModPurpose=HourCounter dient zum Zählen von Ereignissen und zur Erfassung von Betriebs-/Ruhe-Zeiten<br />
|ModType=h<br />
<!-- |ModCmdRef=LightScene -- nicht erforderlich, da Modultyp x --><br />
|ModForumArea=MAX<br />
|ModTechName=98_HourCounter.pm<br />
|ModOwner=John ([http://forum.fhem.de/index.php?action=profile;u=806 Forum] / [[Benutzer Diskussion:John|Wiki]])}}<br />
<br />
<br />
[[HourCounter]] ist ein Perl-Modul, das die Anzahl von Ereignissen erfasst. Bei bipolaren Ereignissen wird zusätzlich die Puls- sowie die Pausendauer ermittelt. Im vorliegenden Beispiel wird ein Betriebsstundenzähler mit einem MAX-Fensterkontakt realisiert.<br />
<br />
== Features ==<br />
* Ermittlung von Betriebsstunden, Auslastung, Verbräuchen, Schalthäufigkeiten<br />
* Ermittlung der Häufigkeit, Puls- Pausendauer pro Tag<br />
* Ermittlung der Puls-/Pausendauer der letzten Schaltperiode<br />
* Bereitstellung von Ereignissen zur Fortführung der Kumulation für Tages-, Wochen- und Monatswerte<br />
* unterstützende Funktionen zur Ablage von Tages-, Wochen- und Monatswerten<br />
<br />
== Zielsetzung des WIKI-Artikels ==<br />
Erläuterung der Funktionalität zur weiterführenden Diskussion im [http://forum.fhem.de/index.php/topic,12216.msg72596.html#msg72596 Forum].<br />
<br />
== Aktuelle Version ==<br />
Das Modul ist seit dem 24.10.2014 Bestandteil von FHEM.<br />
<br />
== Definition ==<br />
=== Abstrakt ===<br />
<pre>define <name> HourCounter <regexp_for_ON> [<regexp_for_Off>]</pre><br />
<br />
<regexp_for_ON> ist ein regulärer Ausdruck der das Ereignis beschreibt.<br />
<br />
Wenn auch [<regexp_for_Off>] definiert ist, so sprechen wir von einem bipolarem Ereignis, das einen <br />
EIN- sowie einen AUS-Zustand aufweist.<br />
<br />
<regexp_for_ON> beschreibt in diesem Fall die positive Flanke,[<regexp_for_Off>] die negative Flanke. Die Struktur des regexp-Ausdruckes ist analog zu jener beim Notify aufgebaut.<br />
<br />
===Konkret===<br />
<pre>define CN.Test HourCounter SHUTTER.JOHN:onoff:.1 SHUTTER.JOHN:onoff:.0</pre><br />
Hier wird der HourCounter CN.TEST definiert.<br />
Ein MAX-Fensterkontakt mit Namen SHUTTER.JOHN wird als Ereignis-Geber verwendet.<br />
Das Reading "onoff" wird als Trigger für unserem Zähler genutzt.<br />
Bei den Fensterkontakten sehen diese Ereignisse wie folgt aus:<br />
<pre><br />
2013-11-15 23:19:12 MAX SHUTTER.JOHN onoff: 1<br />
....<br />
2013-11-15 23:19:24 MAX SHUTTER.JOHN onoff: 0<br />
</pre><br />
<br />
Soll ein Dummy als Ereignis-Geber verwendet werden, lautet die Definition wie folgt:<br />
<pre> define CN.Test HourCounter myDummy:1 myDummy:0</pre><br />
<br />
Die neue Instanz weist folgende Struktur auf:<br />
<br />
<pre><br />
Internals:<br />
CFGFN <br />
DEF SHUTTER.JOHN:onoff:.1 SHUTTER.JOHN:onoff:.0<br />
NAME CN.Test<br />
NR 738<br />
NTFY_ORDER 50-CN.Test<br />
STATE 1<br />
TYPE HourCounter<br />
Readings:<br />
2014-02-04 20:59:22 clearDate 2014-02-04 20:59:22<br />
2014-02-04 20:59:57 countsOverall 1<br />
2014-02-04 20:59:57 countsPerDay 1<br />
2014-02-04 20:59:57 pauseTimeIncrement 35<br />
2014-02-04 20:59:57 pauseTimeOverall 35<br />
2014-02-04 20:59:57 pauseTimePerDay 35<br />
2014-02-04 21:00:01 pulseTimeIncrement 4<br />
2014-02-04 21:00:01 pulseTimeOverall 4<br />
2014-02-04 21:00:01 pulseTimePerDay 4<br />
2014-02-04 20:59:57 state 1<br />
2014-02-04 21:00:00 tickHour 1<br />
2014-02-04 21:00:01 value 0<br />
Helper:<br />
OFF_Regexp SHUTTER.JOHN:onoff:.0<br />
ON_Regexp SHUTTER.JOHN:onoff:.1<br />
calledByEvent <br />
changedTimestamp 2014-02-04 21:00:01<br />
forceClear <br />
forceDayChange <br />
forceHourChange <br />
forceMonthChange <br />
forceWeekChange <br />
isFirstRun <br />
sdRoundHourLast 1391544000<br />
value 0<br />
cmdQueue:<br />
</pre><br />
<br />
Damit nicht zu viele Ereignisse in den Log-Dateien landen, kann man diese sinnvoll einschränken, so daß<br />
nur Änderungen das Feuern von Events auslösen<br />
<pre><br />
attr CN.BRENNER event-on-change-reading .*<br />
</pre><br />
Wenn sich nun jedoch über Stunden und Tage nichts ändert, sieht man in den Charts keine Daten mehr.<br />
Mit dieser Anweisung wird erreicht, daß alle Readings nach Aktualisierung spätesten nach 1 Stunden einen Event feuern, auch wenn sich der Wert nicht ändert.<br />
Eine Ausnahme hiervon sollen machen die tick*-Readings, deren Events sollen immer sofort gefeuert werden, <br />
wenn sie aktualisiert werden.<br />
<pre><br />
attr CN.BRENNER event-min-interval tick.*:0,.*:3600<br />
</pre><br />
<br />
== Readings ==<br />
{| class="wikitable sortable"<br />
|-<br />
! Reading !! class="unsortable" | Beschreibung <br />
|-<br />
| clearDate || Datum, zu dem alle kumulativen Readings über set .. clear gelöscht wurden<br />
|-<br />
| countsOverall || Absolutzähler für das Auftreten des ON-Ereignisses<br />
|-<br />
| countsPerDay || Tageszähler für das Auftreten des ON-Ereignisses<br />
|-<br />
| pauseTimeIncrement || Zeitdauer der Pausen-Phase in Sekunden ; wird zyklisch aktualisiert<br />
|-<br />
| pauseTimeEdge || Zeitdauer der letzten komplettierten Pausen-Phase<br />
|-<br />
| pauseTimeOverall || Zeitdauer in Sekunden über alle aufgetretenen Pause-Phasen<br />
|-<br />
| pauseTimePerDay || Zeitdauer in Sekunden über alle aufgetretenen Pause-Phasen des akt. Tages<br />
|-<br />
| pulseTimeIncrement || Zeitdauer der Puls-Phase in Sekunden ; wird zyklisch aktualisiert<br />
|-<br />
| pulseTimeEdge || Zeitdauer der letzten komplettierten Pulse-Phase<br />
|-<br />
| pulseTimeOverall || Zeitdauer in Sekunden über alle aufgetretenen Puls-Phasen<br />
|-<br />
| pulseTimePerDay || Zeitdauer in Sekunden über alle aufgetretenen Puls-Phasen des akt. Tages<br />
|-<br />
| value || Aktueller Schaltzustand gemäss ON/OFF Ereignis,<br /><br />
mit 1=letztes Ereignis war ON-Ereignis <br /><br />
und 0=letztes Ereignis war OFF-Ereignis<br />
|-<br />
| tickUpdated || Event wird gefeuert, wenn die operativen Readings beschrieben worden sind (nicht unbedingt gändert)<br />
|-<br />
| tickChanged || Event wird nach Änderung von value gefeuert<br />
|-<br />
| tickDay || Event wird nach Tageswechsel gefeuert bevor die Tageszähler resettiert werden<br />
|-<br />
| tickHour || Event wird nach Stundenwechsel gefeuert<br />
|-<br />
| tickWeek || Event wird nach Wochenwechsel gefeuert<br />
|-<br />
| tickMonth || Event wird nach Monatswechsel gefeuert<br />
|-<br />
| tickYear || Event wird nach Jahreswechsel gefeuert<br />
|-<br />
| forceHourChange || simuliert einen Stundenwechsel<br />
|-<br />
| forceDayChange || simuliert einen Tageswechsel<br />
|-<br />
| forceWeekChange || simuliert einen Wochenwechsel<br />
|-<br />
| forceMonthChange || simuliert einen Monatswechsel<br />
|-<br />
| forceYearChange || simuliert einen Jahreswechsel<br />
|}<br />
<br />
== Web-Oberfläche ==<br />
[[Datei:13_11_15_HourCounter_Face.png|HourCounter]]<br />
<br />
== Anwendung ==<br />
Nachfolgende Darstellung zeigt das Einschaltverhalten eines Heizungskessels zusammen mit den <br />
abgeleiteten Werten.<br />
<br />
[[Datei:13_11_15_HourCounter_Chart.png]]<br />
<br />
* die Kurve "Brenner EIN" zeigt die Trigger-Signale des ON/OFF Filters, also das Ein-/Ausschalten des Brenners<br />
* die Kurve "Brenner-Starts" zeigt die über den Tag aufgelaufenen Starts, also chronologisch das Anwachsen von Reading countsPerDay<br />
* die Kurve "Betriebsstunden" zeigt die aufgelaufene Zeit aus dem Reading pulseTimePerDay umgerechnet zu Stunden<br />
* die Kurve "Dauer" zeigt die Dauer des letzten Pulses in Sekunden<br />
* die Kurve Auslastung zeigt das Verhältnis des Readings pulseTimePerDay zur seit Tagesbeginn vergangenen Zeit.<br />
<br />
=== Chart der Aktualwerte ===<br />
Wir benötigen hierzu ein File-Archiv für die aufgelaufenen Daten.<br />
<pre>define CN.Test.File FileLog ./log/CN.Test-%Y.log (CN\.Test:.*)</pre><br />
Man erhält nach den ersten Ereignissen Einträge in folgender Form:<br />
<pre><br />
2013-11-16_12:45:40 CN.Test value: 1<br />
2013-11-16_12:45:40 CN.Test 1<br />
2013-11-16_12:46:21 CN.Test pulseTimeIncrement: 41 <br />
2013-11-16_12:46:21 CN.Test pulseTimePerDay: 41<br />
2013-11-16_12:46:21 CN.Test pulseTimeOverall: 41<br />
2013-11-16_12:46:21 CN.Test value: 0<br />
2013-11-16_12:50:38 CN.Test countsPerDay: 2<br />
2013-11-16_12:50:38 CN.Test countsOverall: 2<br />
2013-11-16_12:50:38 CN.Test pauseTimeIncrement: 257<br />
2013-11-16_12:50:38 CN.Test pauseTimePerDay: 756<br />
2013-11-16_12:50:38 CN.Test pauseTimeOverall: 756<br />
2013-11-16_12:50:38 CN.Test value: 1<br />
2013-11-16_12:50:38 CN.Test 2<br />
</pre><br />
<br />
Nun kann man den Chart definieren:<br />
[[Datei:13_11_16_HourCounter_ChartBuild_01.png]]<br />
<br />
Für die Kurve "Brenner EIN" verwenden wir CN.Test.value. Damit diese als unterste Kurve dargestellt wird transformieren wir den Wert 1 auf -2 und alle anderen (also die 0) auf -21 mit folgender Funktion:<br />
<pre>$fld[3]=~"1"?-2:-19</pre><br />
Die "Brenner Starts" können wir direkt von countsPerDay ableiten.<br /><br /><br />
Für die "Betriebsstunden" verwenden wir pulseTimePerDay. Da diese in Sekunden vorliegen teilen wir den Wert durch 3600, um Stunden zu erhalten.<br />
<pre>$fld[3]/=3600</pre><br />
Als letzten versorgen wir noch die Kurve "Dauer" mit pulseTimeIncrement. Da wir diese in Minuten haben wollen ist ebenfalls eine Umformung nötig.<br />
<pre>$fld[3]/=60</pre><br />
<br />
Somit sind die Basis-Kurven angelegt.<br />
<br />
=== Erweiterungen ===<br />
Es wurden im Forum viele Wünsche formuliert, weitere Funktionalitäten für den HourCounter einzuführen.<br />
<br />
* Aggregation über bestimmte oder ganz freie Zeiträume<br />
* komplexe Berechnungen, die zum Verbrauch führen<br />
* Zuordnung von Verbräuchen zu unterschiedlichen Countern nach bestimmten Bedingungen<br />
<br />
Vor allem die Aggregation erfasster Werte in Stunden-, Tages-, Wochen- und Monatswerten ist eine sinnvolle<br />
Erweiterung bei der Verbrauchserfassung.<br />
<br />
HourCounter bietet Schnittstellen an, die es ermöglichen, das Modul selbst mit neuen Eigenschaften zu erweitern.<br />
<br />
Die Referenz-Implementierung in 99_UtilsHourCounter.pm zeigt, wie dies skript-technisch zu realisieren ist.<br />
<br />
==== Installation ====<br />
Die jeweils aktuelle Version von 99_UtilsHourCounter kann über diesen <br />
[http://sourceforge.net/p/fhem/code/HEAD/tree/trunk/fhem/contrib/99_UtilsHourCounter.pm?format=raw Link] bezogen werden.<br />
<br /><br /><br />
Die Datei ist in da Unterverzeichnis FHEM vom FHEM-Homverzeichnis zu kopieren.<br />
<br /><br />
z.B. bei Raspberry Pi: /opt/fhem/FHEM<br />
<br /><br /><br />
Nach dem Kopieren und einen Neustart von FHEM kann man überprüfen, ob FHEM diese Datei findet.<br />
Wenn man das Menü "Edit Files " anwählt, wird auch 99_UtilsHourCounter angezeigt.<br />
<br />
==== Readings ====<br />
99_UtilsHourCounter erweitert den HourCounter um folgende Funktionen:<br />
{| class="wikitable sortable"<br />
|-<br />
! Reading !! class="unsortable" | Beschreibung<br />
|-<br />
| appCountsPerHour || Stundenzähler, wird bei Stundenwechsel aktualisiert<br />
|-<br />
| appCountsPerHourTemp || Arbeitszähler zu appCountsPerHour<br />
|-<br />
| appCountsPerDay || Tageszähler, wird bei Tageswechsel aktualisiert (Arbeitszähler ist countsPerDay)<br />
|-<br />
| appCountsPerWeek || Wochenzähler, wird bei Wochenwechsel aktualisiert<br />
|-<br />
| appCountsPerWeekTemp || Arbeitszähler zu appCountsPerWeek<br />
|-<br />
| appCountsPerMonth || Monatszähler, wird bei Monatswechsel aktualisiert<br />
|-<br />
| appCountsPerMonthTemp || Arbeitszähler zu appCountsPerMonth<br />
|-<br />
| appCountsPerYear || Jahreszähler, wird bei Jahreswechsel aktualisiert<br />
|-<br />
| appCountsPerYearTemp || Arbeitszähler zu appCountsPerYear<br />
|-<br />
| appOpHoursPerDay || Betriebsstunden des Tages<br />
|-<br />
| appOpHoursPerDayTemp || Arbeitszähler zu appOpHoursPerDay<br />
|-<br />
| appOpHoursPerWeek || Betriebsstunden der Woche<br />
|-<br />
| appOpHoursPerWeekTemp || Arbeitszähler zu appOpHoursPerWeek<br />
|-<br />
| appOpHoursPerMonth || Betriebsstunden des Monats<br />
|-<br />
| appOpHoursPerMonthTemp || Arbeitszähler appOpHoursPerMonth<br />
|-<br />
| appOpHoursPerYear || Betriebsstunden des Jahres<br />
|-<br />
| appOpHoursPerYearTemp || Arbeitszähler appOpHoursPerYear<br />
|-<br />
| appUtilization || Auslastung = pulseTimePerDay /(vergangene Sekunden seit Tagesbeginn) * 100<br />
|-<br />
| appUtilizationTemp || Arbeitsvariable zu appUtilization<br />
|}<br />
Beginn der Woche ist jeweils der Sonntag.<br /><br />
<br />
Mit folgender Anweisung aktivieren wir die Erweiterungen: <br />
:<code><br />
define CN.EVENT notify CN\..*:tick.* { appHCNotify("%NAME","%EVTPART0","%EVTPART1");;}<br />
</code><br />
<br />
Spätestens nach einer steigenden und einer fallenden Flanke sind die zuvor genannten app*-Readings zu sehen.<br />
{{Randnotiz|RNTyp=Info|RNText=Die gezeigten define-Anweisungen müssen jeweils in einer Zeile stehen (keine Zeilenumbrüche!).}}<br />
<br />
Die neuen Readings werden automatisch in den "Setter" der Web-Oberflächen aufgenommen. Dies gilt für alle Readings, die mit "app" beginnen.<br />
<br />
Somit können die neuen Readings beliebig manipuliert werden.<br />
<br />
==== Archiv für Tages-/Wochen-/Monats-/Jahreswerte anlegen ====<br />
Nun wollen wir die aggregierten Werte in eine eigene Datei speichern. Dies gelingt mit <br />
:<code>define CN.Test.FileDay FileLog ./log/CN.Test-Day-%Y.log CN.Test:app\w+ (Utilization|PerHour|PerDay|PerWeek|PerMonth|PerYear)(?!Temp).* </code><br />
<br />
<br />
Im Klartext:<br />
* verwende alle Werte des Counters CN.Test, deren Reading mit "app" beginnt<br />
* und die einen der Terme appUtilization|PerHour|PerDay|PerWeek|PerMonth|PerYear beinhalten<br />
* und die danach nicht dem Term "Temp" beinhalten<br />
<br />
== Fragen und Antworten ==<br />
==== Betriebsstundenzähler über Leistungsmessung ableiten ====<br />
'''Frage:'''<br />
Ich würde gerne zählen, wenn ich mehr Strom als Standy verbrauche (also mehr als 2Watt)<br />
und keine Betriebsstunden zählen, wenn der Verbrauch unter 2 Watt ist. Ist das möglich?<br />
<br />
<u>Beispiel für die Events</u><br />
<pre><br />
013-11-18_19:40:32 XXX power: 1.9<br />
2013-11-18_19:40:32 XXX consumption: 2<br />
2013-11-18_19:40:32 XXX consumptionTotal: 2<br />
2013-11-18_19:40:36 XXX power: 27<br />
2013-11-18_19:40:36 XXX consumption: 2<br />
2013-11-18_19:40:36 XXX consumptionTotal: 2<br />
2013-11-18_19:40:42 XXX power: 34.6<br />
2013-11-18_19:40:42 XXX consumption: 2 <br />
</pre><br />
<br />
'''Antwort'''<br />
Die hier vorgestellte Lösung überprüft ob der Wert des Events power eine oder zwei Ziffern vor dem Komma hat.<br />
Deshalb wir hier erst gezählt, wenn die Schwelle von 10Watt überschritten wird. <br />
<pre><br />
define CN.Test HourCounter XXX:power:\s[0-9]{2,}(\.[0-9]{1,3})*$ XXX:power:\s[0-9]{1}(\.[0-9]{1,3})*$<br />
</pre><br />
Erläuterung zu <regexp_for_ON> = XXX:power:\s[0-9]{2,}(\.[0-9]{1,3})*$<br />
* "XXX" bezeichnet das Device, der Term danach ist der regexp-Filte für das On-Ereignis<br />
* "power:" das Ereignis muss mit diesem Term beginnen<br />
* "\s" es muss ein Leerzeichen folgen<br />
* "[0-9]{2,}" es müssen mindestens 2 Ziffern folgen<br />
* "(\.[0-9]{1,3})*" wenn ein Punkt folgt, dann müssen auf diesen mindestens 1..3 Ziffern folgen<br />
* "$" danach darf kein weiteres Zeichen mehr folgen<br />
<br />
'''Antwort Möglichkeit 2'''<br />
In dieser Lösung bekommt das entsprechende Device was mit HourCounter überwacht werden soll ein userReadings "onoff". Dieses Reading wird dann zum Schalten von Hour Counter verwendet:<br />
<pre><br />
define GPIO4_DS18B20_Waermepumpe_Vorlauf GPIO4 28-000005956079<br />
attr GPIO4_DS18B20_Waermepumpe_Vorlauf alias Wärmepumpe Vorlauf<br />
attr GPIO4_DS18B20_Waermepumpe_Vorlauf model DS18B20<br />
attr GPIO4_DS18B20_Waermepumpe_Vorlauf room GPIO4<br />
attr GPIO4_DS18B20_Waermepumpe_Vorlauf userReadings onoff {(ReadingsVal("GPIO4_DS18B20_Waermepumpe_Vorlauf","temperature",0) >28)?1:0;;}<br />
<br />
define Waermepumpe_HourCounter HourCounter GPIO4_DS18B20_Waermepumpe_Vorlauf:onoff:.1 GPIO4_DS18B20_Waermepumpe_Vorlauf:onoff:.0<br />
attr Waermepumpe_HourCounter room 2_Fussbodenheizung<br />
</pre><br />
Erläuterungen zu dem Code: "{(ReadingsVal("GPIO4_DS18B20_Waermepumpe_Vorlauf","temperature",0) >28)?1:0;;}"<br />
* "(ReadingsVal("GPIO4_DS18B20_Waermepumpe_Vorlauf","temperature",0) >28)" Diese Bedingung für das userReadings onoff prüft bei jedem Event, ob der Wert von temperature größer als 28 ist. <br />
* "?1:0" Ist dies der Fall wird das userReading onoff auf 1 gesetzt andernfalls auf 0.<br />
Auf Basis deses UserReadings wird dann der HourCounter definiert:<br />
* "GPIO4_DS18B20_Waermepumpe_Vorlauf:onoff:.1" Einschaltbedingung für HourCounter<br />
* "GPIO4_DS18B20_Waermepumpe_Vorlauf:onoff:.0" Abschaltbedingung für Hour Counter<br />
<br />
==== Welche Anwendungsfälle sind denkbar ? ====<br />
[http://forum.fhem.de/index.php/topic,12216.msg175163.html#msg175163 Aus dem Forum]<br />
* Betriebsstundenzähler für meine "Fliegenkiller-Steckdose"<br />
* Nutzungsdauer beschränken für TV,Internet oder Spielkonsolen für entnervte Eltern<br />
* Nutzungsdauer ermitteln zur Energieeinsparung (Klimageräte, Ventilatoren, Dunstabzugshauben etc.)<br />
* Lüftungsverhalten ermitteln (wie lange Fenster pro Tag geöffnet)<br />
<br />
[http://forum.fhem.de/index.php/topic,12216.msg195358.html#msg195358 Brenner Starts/Verbrauch + akkumulierte Werte]<br />
<br />
[http://forum.fhem.de/index.php/topic,12216.msg196358.html#msg196358 Ölverbrauch+Solar-Ladung]<br />
<br />
[http://voizchat.de/gaszaehler-verbrauch-erfassen-mit-fhem-und-raspberry-gpio/ Gaszähler mit HourCounter realisieren]<br />
==== Seltene Schaltvorgänge ====<br />
Die Schaltvorgänge sind über den Tag sehr wenige. Die Aktualisierung erfolgt immer erst<br />
bei der negativen Flanke. Wie kann man eine häufigere Aktualisierung erreichen ?<br />
<br />
'''Antwort'''<br />
<br />
Ab Version 1.0.0.6 ist wurde das Attribut "interval" eingeführt; es ist auf 60 Minuten voreingestellt und kann von 5..60 im 5 Minuten-Raster festgelegt werden.<br />
Es bestimmt, nach welcher Zeit Puls-/Pausendauer aktualisiert werden sollen, unabhängig vom Auftreten einer Schaltflanke.<br />
<br />
==== Korrekte Darstellung der akkumulierten Daten im Chart ====<br />
'''Frage'''<br />
<br />
"appCountsPerDay: 4" bezieht sich auf die Counts des Tages 2014-06-16, trägt aber selbst den Zeitstempel 2014-06-17 und wird demnach in einem Chart auch über den Tag " 2014-06-17" dargestellt.<br />
Das Problem betrifft alle akkumulierten Daten des HourCounters.<br />
Wie erreicht man im Chart die korrekte Darstellung ?<br />
<br />
<br />
'''Antwort'''<br />
<br />
Das Thema wurde [http://forum.fhem.de/index.php/topic,12216.msg239929.html#msg239929 hier] disktuiert.<br />
Eine Lösung findet man mit [http://www.fhemwiki.de/wiki/LogProxy LogProxy].<br />
Damit läßt sich ein negativer Offset für die X-Achse definieren, so daß die Daten wieder korrekt dargestellt werden.<br />
<br />
[[Kategorie:MAX]]<br />
[[Kategorie:HOWTOS]]</div>Johnhttp://wiki.fhem.de/w/index.php?title=HourCounter&diff=9725HourCounter2015-02-01T09:42:54Z<p>John: /* Installation Pfadangabe spezifiziert*/</p>
<hr />
<div>{{Infobox Modul<br />
|ModPurpose=HourCounter dient zum Zählen von Ereignissen und zur Erfassung von Betriebs-/Ruhe-Zeiten<br />
|ModType=h<br />
<!-- |ModCmdRef=LightScene -- nicht erforderlich, da Modultyp x --><br />
|ModForumArea=MAX<br />
|ModTechName=98_HourCounter.pm<br />
|ModOwner=John ([http://forum.fhem.de/index.php?action=profile;u=806 Forum] / [[Benutzer Diskussion:John|Wiki]])}}<br />
<br />
<br />
[[HourCounter]] ist ein Perl-Modul, das die Anzahl von Ereignissen erfasst. Bei bipolaren Ereignissen wird zusätzlich die Puls- sowie die Pausendauer ermittelt. Im vorliegenden Beispiel wird ein Betriebsstundenzähler mit einem MAX-Fensterkontakt realisiert.<br />
<br />
== Features ==<br />
* Ermittlung von Betriebsstunden, Auslastung, Verbräuchen, Schalthäufigkeiten<br />
* Ermittlung der Häufigkeit, Puls- Pausendauer pro Tag<br />
* Ermittlung der Puls-/Pausendauer der letzten Schaltperiode<br />
* Bereitstellung von Ereignissen zur Fortführung der Kumulation für Tages-, Wochen- und Monatswerte<br />
* unterstützende Funktionen zur Ablage von Tages-, Wochen- und Monatswerten<br />
<br />
== Zielsetzung des WIKI-Artikels ==<br />
Erläuterung der Funktionalität zur weiterführenden Diskussion im [http://forum.fhem.de/index.php/topic,12216.msg72596.html#msg72596 Forum].<br />
<br />
== Aktuelle Version ==<br />
Das Modul ist seit dem 24.10.2014 Bestandteil von FHEM.<br />
<br />
== Definition ==<br />
=== Abstrakt ===<br />
<pre>define <name> HourCounter <regexp_for_ON> [<regexp_for_Off>]</pre><br />
<br />
<regexp_for_ON> ist ein regulärer Ausdruck der das Ereignis beschreibt.<br />
<br />
Wenn auch [<regexp_for_Off>] definiert ist, so sprechen wir von einem bipolarem Ereignis, das einen <br />
EIN- sowie einen AUS-Zustand aufweist.<br />
<br />
<regexp_for_ON> beschreibt in diesem Fall die positive Flanke,[<regexp_for_Off>] die negative Flanke. Die Struktur des regexp-Ausdruckes ist analog zu jener beim Notify aufgebaut.<br />
<br />
===Konkret===<br />
<pre>define CN.Test HourCounter SHUTTER.JOHN:onoff:.1 SHUTTER.JOHN:onoff:.0</pre><br />
Hier wird der HourCounter CN.TEST definiert.<br />
Ein MAX-Fensterkontakt mit Namen SHUTTER.JOHN wird als Ereignis-Geber verwendet.<br />
Das Reading "onoff" wird als Trigger für unserem Zähler genutzt.<br />
Bei den Fensterkontakten sehen diese Ereignisse wie folgt aus:<br />
<pre><br />
2013-11-15 23:19:12 MAX SHUTTER.JOHN onoff: 1<br />
....<br />
2013-11-15 23:19:24 MAX SHUTTER.JOHN onoff: 0<br />
</pre><br />
<br />
Soll ein Dummy als Ereignis-Geber verwendet werden, lautet die Definition wie folgt:<br />
<pre> define CN.Test HourCounter myDummy:1 myDummy:0</pre><br />
<br />
Die neue Instanz weist folgende Struktur auf:<br />
<br />
<pre><br />
Internals:<br />
CFGFN <br />
DEF SHUTTER.JOHN:onoff:.1 SHUTTER.JOHN:onoff:.0<br />
NAME CN.Test<br />
NR 738<br />
NTFY_ORDER 50-CN.Test<br />
STATE 1<br />
TYPE HourCounter<br />
Readings:<br />
2014-02-04 20:59:22 clearDate 2014-02-04 20:59:22<br />
2014-02-04 20:59:57 countsOverall 1<br />
2014-02-04 20:59:57 countsPerDay 1<br />
2014-02-04 20:59:57 pauseTimeIncrement 35<br />
2014-02-04 20:59:57 pauseTimeOverall 35<br />
2014-02-04 20:59:57 pauseTimePerDay 35<br />
2014-02-04 21:00:01 pulseTimeIncrement 4<br />
2014-02-04 21:00:01 pulseTimeOverall 4<br />
2014-02-04 21:00:01 pulseTimePerDay 4<br />
2014-02-04 20:59:57 state 1<br />
2014-02-04 21:00:00 tickHour 1<br />
2014-02-04 21:00:01 value 0<br />
Helper:<br />
OFF_Regexp SHUTTER.JOHN:onoff:.0<br />
ON_Regexp SHUTTER.JOHN:onoff:.1<br />
calledByEvent <br />
changedTimestamp 2014-02-04 21:00:01<br />
forceClear <br />
forceDayChange <br />
forceHourChange <br />
forceMonthChange <br />
forceWeekChange <br />
isFirstRun <br />
sdRoundHourLast 1391544000<br />
value 0<br />
cmdQueue:<br />
</pre><br />
<br />
Damit nicht zu viele Ereignisse in den Log-Dateien landen, kann man diese sinnvoll einschränken, so daß<br />
nur Änderungen das Feuern von Events auslösen<br />
<pre><br />
attr CN.BRENNER event-on-change-reading .*<br />
</pre><br />
Wenn sich nun jedoch über Stunden und Tage nichts ändert, sieht man in den Charts keine Daten mehr.<br />
Mit dieser Anweisung wird erreicht, daß alle Readings nach Aktualisierung spätesten nach 1 Stunden einen Event feuern, auch wenn sich der Wert nicht ändert.<br />
Eine Ausnahme hiervon sollen machen die tick*-Readings, deren Events sollen immer sofort gefeuert werden, <br />
wenn sie aktualisiert werden.<br />
<pre><br />
attr CN.BRENNER event-min-interval tick.*:0,.*:3600<br />
</pre><br />
<br />
== Readings ==<br />
{| class="wikitable sortable"<br />
|-<br />
! Reading !! class="unsortable" | Beschreibung <br />
|-<br />
| clearDate || Datum, zu dem alle kumulativen Readings über set .. clear gelöscht wurden<br />
|-<br />
| countsOverall || Absolutzähler für das Auftreten des ON-Ereignisses<br />
|-<br />
| countsPerDay || Tageszähler für das Auftreten des ON-Ereignisses<br />
|-<br />
| pauseTimeIncrement || Zeitdauer der Pausen-Phase in Sekunden ; wird zyklisch aktualisiert<br />
|-<br />
| pauseTimeEdge || Zeitdauer der letzten komplettierten Pausen-Phase<br />
|-<br />
| pauseTimeOverall || Zeitdauer in Sekunden über alle aufgetretenen Pause-Phasen<br />
|-<br />
| pauseTimePerDay || Zeitdauer in Sekunden über alle aufgetretenen Pause-Phasen des akt. Tages<br />
|-<br />
| pulseTimeIncrement || Zeitdauer der Puls-Phase in Sekunden ; wird zyklisch aktualisiert<br />
|-<br />
| pulseTimeEdge || Zeitdauer der letzten komplettierten Pulse-Phase<br />
|-<br />
| pulseTimeOverall || Zeitdauer in Sekunden über alle aufgetretenen Puls-Phasen<br />
|-<br />
| pulseTimePerDay || Zeitdauer in Sekunden über alle aufgetretenen Puls-Phasen des akt. Tages<br />
|-<br />
| value || Aktueller Schaltzustand gemäss ON/OFF Ereignis,<br /><br />
mit 1=letztes Ereignis war ON-Ereignis <br /><br />
und 0=letztes Ereignis war OFF-Ereignis<br />
|-<br />
| tickUpdated || Event wird gefeuert, wenn die operativen Readings beschrieben worden sind (nicht unbedingt gändert)<br />
|-<br />
| tickChanged || Event wird nach Änderung von value gefeuert<br />
|-<br />
| tickDay || Event wird nach Tageswechsel gefeuert bevor die Tageszähler resettiert werden<br />
|-<br />
| tickHour || Event wird nach Stundenwechsel gefeuert<br />
|-<br />
| tickWeek || Event wird nach Wochenwechsel gefeuert<br />
|-<br />
| tickMonth || Event wird nach Monatswechsel gefeuert<br />
|-<br />
| tickYear || Event wird nach Jahreswechsel gefeuert<br />
|-<br />
| forceHourChange || simuliert einen Stundenwechsel<br />
|-<br />
| forceDayChange || simuliert einen Tageswechsel<br />
|-<br />
| forceWeekChange || simuliert einen Wochenwechsel<br />
|-<br />
| forceMonthChange || simuliert einen Monatswechsel<br />
|-<br />
| forceYearChange || simuliert einen Jahreswechsel<br />
|}<br />
<br />
== Web-Oberfläche ==<br />
[[Datei:13_11_15_HourCounter_Face.png|HourCounter]]<br />
<br />
== Anwendung ==<br />
Nachfolgende Darstellung zeigt das Einschaltverhalten eines Heizungskessels zusammen mit den <br />
abgeleiteten Werten.<br />
<br />
[[Datei:13_11_15_HourCounter_Chart.png]]<br />
<br />
* die Kurve "Brenner EIN" zeigt die Trigger-Signale des ON/OFF Filters, also das Ein-/Ausschalten des Brenners<br />
* die Kurve "Brenner-Starts" zeigt die über den Tag aufgelaufenen Starts, also chronologisch das Anwachsen von Reading countsPerDay<br />
* die Kurve "Betriebsstunden" zeigt die aufgelaufene Zeit aus dem Reading pulseTimePerDay umgerechnet zu Stunden<br />
* die Kurve "Dauer" zeigt die Dauer des letzten Pulses in Sekunden<br />
* die Kurve Auslastung zeigt das Verhältnis des Readings pulseTimePerDay zur seit Tagesbeginn vergangenen Zeit.<br />
<br />
=== Chart der Aktualwerte ===<br />
Wir benötigen hierzu ein File-Archiv für die aufgelaufenen Daten.<br />
<pre>define CN.Test.File FileLog ./log/CN.Test-%Y.log (CN\.Test:.*)</pre><br />
Man erhält nach den ersten Ereignissen Einträge in folgender Form:<br />
<pre><br />
2013-11-16_12:45:40 CN.Test value: 1<br />
2013-11-16_12:45:40 CN.Test 1<br />
2013-11-16_12:46:21 CN.Test pulseTimeIncrement: 41 <br />
2013-11-16_12:46:21 CN.Test pulseTimePerDay: 41<br />
2013-11-16_12:46:21 CN.Test pulseTimeOverall: 41<br />
2013-11-16_12:46:21 CN.Test value: 0<br />
2013-11-16_12:50:38 CN.Test countsPerDay: 2<br />
2013-11-16_12:50:38 CN.Test countsOverall: 2<br />
2013-11-16_12:50:38 CN.Test pauseTimeIncrement: 257<br />
2013-11-16_12:50:38 CN.Test pauseTimePerDay: 756<br />
2013-11-16_12:50:38 CN.Test pauseTimeOverall: 756<br />
2013-11-16_12:50:38 CN.Test value: 1<br />
2013-11-16_12:50:38 CN.Test 2<br />
</pre><br />
<br />
Nun kann man den Chart definieren:<br />
[[Datei:13_11_16_HourCounter_ChartBuild_01.png]]<br />
<br />
Für die Kurve "Brenner EIN" verwenden wir CN.Test.value. Damit diese als unterste Kurve dargestellt wird transformieren wir den Wert 1 auf -2 und alle anderen (also die 0) auf -21 mit folgender Funktion:<br />
<pre>$fld[3]=~"1"?-2:-19</pre><br />
Die "Brenner Starts" können wir direkt von countsPerDay ableiten.<br /><br /><br />
Für die "Betriebsstunden" verwenden wir pulseTimePerDay. Da diese in Sekunden vorliegen teilen wir den Wert durch 3600, um Stunden zu erhalten.<br />
<pre>$fld[3]/=3600</pre><br />
Als letzten versorgen wir noch die Kurve "Dauer" mit pulseTimeIncrement. Da wir diese in Minuten haben wollen ist ebenfalls eine Umformung nötig.<br />
<pre>$fld[3]/=60</pre><br />
<br />
Somit sind die Basis-Kurven angelegt.<br />
<br />
=== Erweiterungen ===<br />
Es wurden im Forum viele Wünsche formuliert, weitere Funktionalitäten für den HourCounter einzuführen.<br />
<br />
* Aggregation über bestimmte oder ganz freie Zeiträume<br />
* komplexe Berechnungen, die zum Verbrauch führen<br />
* Zuordnung von Verbräuchen zu unterschiedlichen Countern nach bestimmten Bedingungen<br />
<br />
Vor allem die Aggregation erfasster Werte in Stunden-, Tages-, Wochen- und Monatswerten ist eine sinnvolle<br />
Erweiterung bei der Verbrauchserfassung.<br />
<br />
HourCounter bietet Schnittstellen an, die es ermöglichen, das Modul selbst mit neuen Eigenschaften zu erweitern.<br />
<br />
Die Referenz-Implementierung in 99_UtilsHourCounter.pm zeigt, wie dies skript-technisch zu realisieren ist.<br />
<br />
==== Installation ====<br />
Die jeweils aktuelle Version von 99_UtilsHourCounter kann über diesen <br />
[http://sourceforge.net/p/fhem/code/HEAD/tree/trunk/fhem/contrib/99_UtilsHourCounter.pm?format=raw Link] bezogen werden.<br />
<br /><br /><br />
Die Datei ist in da Unterverzeichnis FHEM vom FHEM-Homverzeichnis zu kopieren.<br />
<br /><br />
z.B. bei Raspberry Pi: /opt/fhem/FHEM<br />
<br />
==== Readings ====<br />
99_UtilsHourCounter erweitert den HourCounter um folgende Funktionen:<br />
{| class="wikitable sortable"<br />
|-<br />
! Reading !! class="unsortable" | Beschreibung<br />
|-<br />
| appCountsPerHour || Stundenzähler, wird bei Stundenwechsel aktualisiert<br />
|-<br />
| appCountsPerHourTemp || Arbeitszähler zu appCountsPerHour<br />
|-<br />
| appCountsPerDay || Tageszähler, wird bei Tageswechsel aktualisiert (Arbeitszähler ist countsPerDay)<br />
|-<br />
| appCountsPerWeek || Wochenzähler, wird bei Wochenwechsel aktualisiert<br />
|-<br />
| appCountsPerWeekTemp || Arbeitszähler zu appCountsPerWeek<br />
|-<br />
| appCountsPerMonth || Monatszähler, wird bei Monatswechsel aktualisiert<br />
|-<br />
| appCountsPerMonthTemp || Arbeitszähler zu appCountsPerMonth<br />
|-<br />
| appCountsPerYear || Jahreszähler, wird bei Jahreswechsel aktualisiert<br />
|-<br />
| appCountsPerYearTemp || Arbeitszähler zu appCountsPerYear<br />
|-<br />
| appOpHoursPerDay || Betriebsstunden des Tages<br />
|-<br />
| appOpHoursPerDayTemp || Arbeitszähler zu appOpHoursPerDay<br />
|-<br />
| appOpHoursPerWeek || Betriebsstunden der Woche<br />
|-<br />
| appOpHoursPerWeekTemp || Arbeitszähler zu appOpHoursPerWeek<br />
|-<br />
| appOpHoursPerMonth || Betriebsstunden des Monats<br />
|-<br />
| appOpHoursPerMonthTemp || Arbeitszähler appOpHoursPerMonth<br />
|-<br />
| appOpHoursPerYear || Betriebsstunden des Jahres<br />
|-<br />
| appOpHoursPerYearTemp || Arbeitszähler appOpHoursPerYear<br />
|-<br />
| appUtilization || Auslastung = pulseTimePerDay /(vergangene Sekunden seit Tagesbeginn) * 100<br />
|-<br />
| appUtilizationTemp || Arbeitsvariable zu appUtilization<br />
|}<br />
Beginn der Woche ist jeweils der Sonntag.<br /><br />
<br />
Mit folgender Anweisung aktivieren wir die Erweiterungen: <br />
:<code><br />
define CN.EVENT notify CN\..*:tick.* { appHCNotify("%NAME","%EVTPART0","%EVTPART1");;}<br />
</code><br />
<br />
Spätestens nach einer steigenden und einer fallenden Flanke sind die zuvor genannten app*-Readings zu sehen.<br />
{{Randnotiz|RNTyp=Info|RNText=Die gezeigten define-Anweisungen müssen jeweils in einer Zeile stehen (keine Zeilenumbrüche!).}}<br />
<br />
Die neuen Readings werden automatisch in den "Setter" der Web-Oberflächen aufgenommen. Dies gilt für alle Readings, die mit "app" beginnen.<br />
<br />
Somit können die neuen Readings beliebig manipuliert werden.<br />
<br />
==== Archiv für Tages-/Wochen-/Monats-/Jahreswerte anlegen ====<br />
Nun wollen wir die aggregierten Werte in eine eigene Datei speichern. Dies gelingt mit <br />
:<code>define CN.Test.FileDay FileLog ./log/CN.Test-Day-%Y.log CN.Test:app\w+ (Utilization|PerHour|PerDay|PerWeek|PerMonth|PerYear)(?!Temp).* </code><br />
<br />
<br />
Im Klartext:<br />
* verwende alle Werte des Counters CN.Test, deren Reading mit "app" beginnt<br />
* und die einen der Terme appUtilization|PerHour|PerDay|PerWeek|PerMonth|PerYear beinhalten<br />
* und die danach nicht dem Term "Temp" beinhalten<br />
<br />
== Fragen und Antworten ==<br />
==== Betriebsstundenzähler über Leistungsmessung ableiten ====<br />
'''Frage:'''<br />
Ich würde gerne zählen, wenn ich mehr Strom als Standy verbrauche (also mehr als 2Watt)<br />
und keine Betriebsstunden zählen, wenn der Verbrauch unter 2 Watt ist. Ist das möglich?<br />
<br />
<u>Beispiel für die Events</u><br />
<pre><br />
013-11-18_19:40:32 XXX power: 1.9<br />
2013-11-18_19:40:32 XXX consumption: 2<br />
2013-11-18_19:40:32 XXX consumptionTotal: 2<br />
2013-11-18_19:40:36 XXX power: 27<br />
2013-11-18_19:40:36 XXX consumption: 2<br />
2013-11-18_19:40:36 XXX consumptionTotal: 2<br />
2013-11-18_19:40:42 XXX power: 34.6<br />
2013-11-18_19:40:42 XXX consumption: 2 <br />
</pre><br />
<br />
'''Antwort'''<br />
Die hier vorgestellte Lösung überprüft ob der Wert des Events power eine oder zwei Ziffern vor dem Komma hat.<br />
Deshalb wir hier erst gezählt, wenn die Schwelle von 10Watt überschritten wird. <br />
<pre><br />
define CN.Test HourCounter XXX:power:\s[0-9]{2,}(\.[0-9]{1,3})*$ XXX:power:\s[0-9]{1}(\.[0-9]{1,3})*$<br />
</pre><br />
Erläuterung zu <regexp_for_ON> = XXX:power:\s[0-9]{2,}(\.[0-9]{1,3})*$<br />
* "XXX" bezeichnet das Device, der Term danach ist der regexp-Filte für das On-Ereignis<br />
* "power:" das Ereignis muss mit diesem Term beginnen<br />
* "\s" es muss ein Leerzeichen folgen<br />
* "[0-9]{2,}" es müssen mindestens 2 Ziffern folgen<br />
* "(\.[0-9]{1,3})*" wenn ein Punkt folgt, dann müssen auf diesen mindestens 1..3 Ziffern folgen<br />
* "$" danach darf kein weiteres Zeichen mehr folgen<br />
<br />
'''Antwort Möglichkeit 2'''<br />
In dieser Lösung bekommt das entsprechende Device was mit HourCounter überwacht werden soll ein userReadings "onoff". Dieses Reading wird dann zum Schalten von Hour Counter verwendet:<br />
<pre><br />
define GPIO4_DS18B20_Waermepumpe_Vorlauf GPIO4 28-000005956079<br />
attr GPIO4_DS18B20_Waermepumpe_Vorlauf alias Wärmepumpe Vorlauf<br />
attr GPIO4_DS18B20_Waermepumpe_Vorlauf model DS18B20<br />
attr GPIO4_DS18B20_Waermepumpe_Vorlauf room GPIO4<br />
attr GPIO4_DS18B20_Waermepumpe_Vorlauf userReadings onoff {(ReadingsVal("GPIO4_DS18B20_Waermepumpe_Vorlauf","temperature",0) >28)?1:0;;}<br />
<br />
define Waermepumpe_HourCounter HourCounter GPIO4_DS18B20_Waermepumpe_Vorlauf:onoff:.1 GPIO4_DS18B20_Waermepumpe_Vorlauf:onoff:.0<br />
attr Waermepumpe_HourCounter room 2_Fussbodenheizung<br />
</pre><br />
Erläuterungen zu dem Code: "{(ReadingsVal("GPIO4_DS18B20_Waermepumpe_Vorlauf","temperature",0) >28)?1:0;;}"<br />
* "(ReadingsVal("GPIO4_DS18B20_Waermepumpe_Vorlauf","temperature",0) >28)" Diese Bedingung für das userReadings onoff prüft bei jedem Event, ob der Wert von temperature größer als 28 ist. <br />
* "?1:0" Ist dies der Fall wird das userReading onoff auf 1 gesetzt andernfalls auf 0.<br />
Auf Basis deses UserReadings wird dann der HourCounter definiert:<br />
* "GPIO4_DS18B20_Waermepumpe_Vorlauf:onoff:.1" Einschaltbedingung für HourCounter<br />
* "GPIO4_DS18B20_Waermepumpe_Vorlauf:onoff:.0" Abschaltbedingung für Hour Counter<br />
<br />
==== Welche Anwendungsfälle sind denkbar ? ====<br />
[http://forum.fhem.de/index.php/topic,12216.msg175163.html#msg175163 Aus dem Forum]<br />
* Betriebsstundenzähler für meine "Fliegenkiller-Steckdose"<br />
* Nutzungsdauer beschränken für TV,Internet oder Spielkonsolen für entnervte Eltern<br />
* Nutzungsdauer ermitteln zur Energieeinsparung (Klimageräte, Ventilatoren, Dunstabzugshauben etc.)<br />
* Lüftungsverhalten ermitteln (wie lange Fenster pro Tag geöffnet)<br />
<br />
[http://forum.fhem.de/index.php/topic,12216.msg195358.html#msg195358 Brenner Starts/Verbrauch + akkumulierte Werte]<br />
<br />
[http://forum.fhem.de/index.php/topic,12216.msg196358.html#msg196358 Ölverbrauch+Solar-Ladung]<br />
<br />
[http://voizchat.de/gaszaehler-verbrauch-erfassen-mit-fhem-und-raspberry-gpio/ Gaszähler mit HourCounter realisieren]<br />
==== Seltene Schaltvorgänge ====<br />
Die Schaltvorgänge sind über den Tag sehr wenige. Die Aktualisierung erfolgt immer erst<br />
bei der negativen Flanke. Wie kann man eine häufigere Aktualisierung erreichen ?<br />
<br />
'''Antwort'''<br />
<br />
Ab Version 1.0.0.6 ist wurde das Attribut "interval" eingeführt; es ist auf 60 Minuten voreingestellt und kann von 5..60 im 5 Minuten-Raster festgelegt werden.<br />
Es bestimmt, nach welcher Zeit Puls-/Pausendauer aktualisiert werden sollen, unabhängig vom Auftreten einer Schaltflanke.<br />
<br />
==== Korrekte Darstellung der akkumulierten Daten im Chart ====<br />
'''Frage'''<br />
<br />
"appCountsPerDay: 4" bezieht sich auf die Counts des Tages 2014-06-16, trägt aber selbst den Zeitstempel 2014-06-17 und wird demnach in einem Chart auch über den Tag " 2014-06-17" dargestellt.<br />
Das Problem betrifft alle akkumulierten Daten des HourCounters.<br />
Wie erreicht man im Chart die korrekte Darstellung ?<br />
<br />
<br />
'''Antwort'''<br />
<br />
Das Thema wurde [http://forum.fhem.de/index.php/topic,12216.msg239929.html#msg239929 hier] disktuiert.<br />
Eine Lösung findet man mit [http://www.fhemwiki.de/wiki/LogProxy LogProxy].<br />
Damit läßt sich ein negativer Offset für die X-Achse definieren, so daß die Daten wieder korrekt dargestellt werden.<br />
<br />
[[Kategorie:MAX]]<br />
[[Kategorie:HOWTOS]]</div>Johnhttp://wiki.fhem.de/w/index.php?title=HourCounter&diff=9182HourCounter2015-01-05T08:39:47Z<p>John: /* Seltene Schaltvorgänge */</p>
<hr />
<div>{{Infobox Modul<br />
|ModPurpose=HourCounter dient zum Zählen von Ereignissen und zur Erfassung von Betriebs-/Ruhe-Zeiten<br />
|ModType=h<br />
<!-- |ModCmdRef=LightScene -- nicht erforderlich, da Modultyp x --><br />
|ModForumArea=MAX<br />
|ModTechName=98_HourCounter.pm<br />
|ModOwner=John ([http://forum.fhem.de/index.php?action=profile;u=806 Forum] / [[Benutzer Diskussion:John|Wiki]])}}<br />
<br />
<br />
[[HourCounter]] ist ein Perl-Modul, das die Anzahl von Ereignissen erfasst. Bei bipolaren Ereignissen wird zusätzlich die Puls- sowie die Pausendauer ermittelt. Im vorliegenden Beispiel wird ein Betriebsstundenzähler mit einem MAX-Fensterkontakt realisiert.<br />
<br />
== Features ==<br />
* Ermittlung von Betriebsstunden, Auslastung, Verbräuchen, Schalthäufigkeiten<br />
* Ermittlung der Häufigkeit, Puls- Pausendauer pro Tag<br />
* Ermittlung der Puls-/Pausendauer der letzten Schaltperiode<br />
* Bereitstellung von Ereignissen zur Fortführung der Kumulation für Tages-, Wochen- und Monatswerte<br />
* unterstützende Funktionen zur Ablage von Tages-, Wochen- und Monatswerten<br />
<br />
== Zielsetzung des WIKI-Artikels ==<br />
Erläuterung der Funktionalität zur weiterführenden Diskussion im [http://forum.fhem.de/index.php/topic,12216.msg72596.html#msg72596 Forum].<br />
<br />
== Aktuelle Version ==<br />
Das Modul ist seit dem 24.10.2014 Bestandteil von FHEM.<br />
<br />
== Definition ==<br />
=== Abstrakt ===<br />
<pre>define <name> HourCounter <regexp_for_ON> [<regexp_for_Off>]</pre><br />
<br />
<regexp_for_ON> ist ein regulärer Ausdruck der das Ereignis beschreibt.<br />
<br />
Wenn auch [<regexp_for_Off>] definiert ist, so sprechen wir von einem bipolarem Ereignis, das einen <br />
EIN- sowie einen AUS-Zustand aufweist.<br />
<br />
<regexp_for_ON> beschreibt in diesem Fall die positive Flanke,[<regexp_for_Off>] die negative Flanke. Die Struktur des regexp-Ausdruckes ist analog zu jener beim Notify aufgebaut.<br />
<br />
===Konkret===<br />
<pre>define CN.Test HourCounter SHUTTER.JOHN:onoff:.1 SHUTTER.JOHN:onoff:.0</pre><br />
Hier wird der HourCounter CN.TEST definiert.<br />
Ein MAX-Fensterkontakt mit Namen SHUTTER.JOHN wird als Ereignis-Geber verwendet.<br />
Das Reading "onoff" wird als Trigger für unserem Zähler genutzt.<br />
Bei den Fensterkontakten sehen diese Ereignisse wie folgt aus:<br />
<pre><br />
2013-11-15 23:19:12 MAX SHUTTER.JOHN onoff: 1<br />
....<br />
2013-11-15 23:19:24 MAX SHUTTER.JOHN onoff: 0<br />
</pre><br />
<br />
Soll ein Dummy als Ereignis-Geber verwendet werden, lautet die Definition wie folgt:<br />
<pre> define CN.Test HourCounter myDummy:1 myDummy:0</pre><br />
<br />
Die neue Instanz weist folgende Struktur auf:<br />
<br />
<pre><br />
Internals:<br />
CFGFN <br />
DEF SHUTTER.JOHN:onoff:.1 SHUTTER.JOHN:onoff:.0<br />
NAME CN.Test<br />
NR 738<br />
NTFY_ORDER 50-CN.Test<br />
STATE 1<br />
TYPE HourCounter<br />
Readings:<br />
2014-02-04 20:59:22 clearDate 2014-02-04 20:59:22<br />
2014-02-04 20:59:57 countsOverall 1<br />
2014-02-04 20:59:57 countsPerDay 1<br />
2014-02-04 20:59:57 pauseTimeIncrement 35<br />
2014-02-04 20:59:57 pauseTimeOverall 35<br />
2014-02-04 20:59:57 pauseTimePerDay 35<br />
2014-02-04 21:00:01 pulseTimeIncrement 4<br />
2014-02-04 21:00:01 pulseTimeOverall 4<br />
2014-02-04 21:00:01 pulseTimePerDay 4<br />
2014-02-04 20:59:57 state 1<br />
2014-02-04 21:00:00 tickHour 1<br />
2014-02-04 21:00:01 value 0<br />
Helper:<br />
OFF_Regexp SHUTTER.JOHN:onoff:.0<br />
ON_Regexp SHUTTER.JOHN:onoff:.1<br />
calledByEvent <br />
changedTimestamp 2014-02-04 21:00:01<br />
forceClear <br />
forceDayChange <br />
forceHourChange <br />
forceMonthChange <br />
forceWeekChange <br />
isFirstRun <br />
sdRoundHourLast 1391544000<br />
value 0<br />
cmdQueue:<br />
</pre><br />
<br />
Damit nicht zu viele Ereignisse in den Log-Dateien landen, kann man diese sinnvoll einschränken, so daß<br />
nur Änderungen das Feuern von Events auslösen<br />
<pre><br />
attr CN.BRENNER event-on-change-reading .*<br />
</pre><br />
Wenn sich nun jedoch über Stunden und Tage nichts ändert, sieht man in den Charts keine Daten mehr.<br />
Mit dieser Anweisung wird erreicht, daß alle Readings nach Aktualisierung spätesten nach 1 Stunden einen Event feuern, auch wenn sich der Wert nicht ändert.<br />
Eine Ausnahme hiervon sollen machen die tick*-Readings, deren Events sollen immer sofort gefeuert werden, <br />
wenn sie aktualisiert werden.<br />
<pre><br />
attr CN.BRENNER event-min-interval tick.*:0,.*:3600<br />
</pre><br />
<br />
== Readings ==<br />
{| class="wikitable sortable"<br />
|-<br />
! Reading !! class="unsortable" | Beschreibung <br />
|-<br />
| clearDate || Datum, zu dem alle kumulativen Readings über set .. clear gelöscht wurden<br />
|-<br />
| countsOverall || Absolutzähler für das Auftreten des ON-Ereignisses<br />
|-<br />
| countsPerDay || Tageszähler für das Auftreten des ON-Ereignisses<br />
|-<br />
| pauseTimeIncrement || Zeitdauer der Pausen-Phase in Sekunden ; wird zyklisch aktualisiert<br />
|-<br />
| pauseTimeEdge || Zeitdauer der letzten komplettierten Pausen-Phase<br />
|-<br />
| pauseTimeOverall || Zeitdauer in Sekunden über alle aufgetretenen Pause-Phasen<br />
|-<br />
| pauseTimePerDay || Zeitdauer in Sekunden über alle aufgetretenen Pause-Phasen des akt. Tages<br />
|-<br />
| pulseTimeIncrement || Zeitdauer der Puls-Phase in Sekunden ; wird zyklisch aktualisiert<br />
|-<br />
| pulseTimeEdge || Zeitdauer der letzten komplettierten Pulse-Phase<br />
|-<br />
| pulseTimeOverall || Zeitdauer in Sekunden über alle aufgetretenen Puls-Phasen<br />
|-<br />
| pulseTimePerDay || Zeitdauer in Sekunden über alle aufgetretenen Puls-Phasen des akt. Tages<br />
|-<br />
| value || Aktueller Schaltzustand gemäss ON/OFF Ereignis,<br /><br />
mit 1=letztes Ereignis war ON-Ereignis <br /><br />
und 0=letztes Ereignis war OFF-Ereignis<br />
|-<br />
| tickUpdated || Event wird gefeuert, wenn die operativen Readings beschrieben worden sind (nicht unbedingt gändert)<br />
|-<br />
| tickChanged || Event wird nach Änderung von value gefeuert<br />
|-<br />
| tickDay || Event wird nach Tageswechsel gefeuert bevor die Tageszähler resettiert werden<br />
|-<br />
| tickHour || Event wird nach Stundenwechsel gefeuert<br />
|-<br />
| tickWeek || Event wird nach Wochenwechsel gefeuert<br />
|-<br />
| tickMonth || Event wird nach Monatswechsel gefeuert<br />
|-<br />
| tickYear || Event wird nach Jahreswechsel gefeuert<br />
|-<br />
| forceHourChange || simuliert einen Stundenwechsel<br />
|-<br />
| forceDayChange || simuliert einen Tageswechsel<br />
|-<br />
| forceWeekChange || simuliert einen Wochenwechsel<br />
|-<br />
| forceMonthChange || simuliert einen Monatswechsel<br />
|-<br />
| forceYearChange || simuliert einen Jahreswechsel<br />
|}<br />
<br />
== Web-Oberfläche ==<br />
[[Datei:13_11_15_HourCounter_Face.png|HourCounter]]<br />
<br />
== Anwendung ==<br />
Nachfolgende Darstellung zeigt das Einschaltverhalten eines Heizungskessels zusammen mit den <br />
abgeleiteten Werten.<br />
<br />
[[Datei:13_11_15_HourCounter_Chart.png]]<br />
<br />
* die Kurve "Brenner EIN" zeigt die Trigger-Signale des ON/OFF Filters, also das Ein-/Ausschalten des Brenners<br />
* die Kurve "Brenner-Starts" zeigt die über den Tag aufgelaufenen Starts, also chronologisch das Anwachsen von Reading countsPerDay<br />
* die Kurve "Betriebsstunden" zeigt die aufgelaufene Zeit aus dem Reading pulseTimePerDay umgerechnet zu Stunden<br />
* die Kurve "Dauer" zeigt die Dauer des letzten Pulses in Sekunden<br />
* die Kurve Auslastung zeigt das Verhältnis des Readings pulseTimePerDay zur seit Tagesbeginn vergangenen Zeit.<br />
<br />
=== Chart der Aktualwerte ===<br />
Wir benötigen hierzu ein File-Archiv für die aufgelaufenen Daten.<br />
<pre>define CN.Test.File FileLog ./log/CN.Test-%Y.log (CN\.Test:.*)</pre><br />
Man erhält nach den ersten Ereignissen Einträge in folgender Form:<br />
<pre><br />
2013-11-16_12:45:40 CN.Test value: 1<br />
2013-11-16_12:45:40 CN.Test 1<br />
2013-11-16_12:46:21 CN.Test pulseTimeIncrement: 41 <br />
2013-11-16_12:46:21 CN.Test pulseTimePerDay: 41<br />
2013-11-16_12:46:21 CN.Test pulseTimeOverall: 41<br />
2013-11-16_12:46:21 CN.Test value: 0<br />
2013-11-16_12:50:38 CN.Test countsPerDay: 2<br />
2013-11-16_12:50:38 CN.Test countsOverall: 2<br />
2013-11-16_12:50:38 CN.Test pauseTimeIncrement: 257<br />
2013-11-16_12:50:38 CN.Test pauseTimePerDay: 756<br />
2013-11-16_12:50:38 CN.Test pauseTimeOverall: 756<br />
2013-11-16_12:50:38 CN.Test value: 1<br />
2013-11-16_12:50:38 CN.Test 2<br />
</pre><br />
<br />
Nun kann man den Chart definieren:<br />
[[Datei:13_11_16_HourCounter_ChartBuild_01.png]]<br />
<br />
Für die Kurve "Brenner EIN" verwenden wir CN.Test.value. Damit diese als unterste Kurve dargestellt wird transformieren wir den Wert 1 auf -2 und alle anderen (also die 0) auf -21 mit folgender Funktion:<br />
<pre>$fld[3]=~"1"?-2:-19</pre><br />
Die "Brenner Starts" können wir direkt von countsPerDay ableiten.<br /><br /><br />
Für die "Betriebsstunden" verwenden wir pulseTimePerDay. Da diese in Sekunden vorliegen teilen wir den Wert durch 3600, um Stunden zu erhalten.<br />
<pre>$fld[3]/=3600</pre><br />
Als letzten versorgen wir noch die Kurve "Dauer" mit pulseTimeIncrement. Da wir diese in Minuten haben wollen ist ebenfalls eine Umformung nötig.<br />
<pre>$fld[3]/=60</pre><br />
<br />
Somit sind die Basis-Kurven angelegt.<br />
<br />
=== Erweiterungen ===<br />
Es wurden im Forum viele Wünsche formuliert, weitere Funktionalitäten für den HourCounter einzuführen.<br />
<br />
* Aggregation über bestimmte oder ganz freie Zeiträume<br />
* komplexe Berechnungen, die zum Verbrauch führen<br />
* Zuordnung von Verbräuchen zu unterschiedlichen Countern nach bestimmten Bedingungen<br />
<br />
Vor allem die Aggregation erfasster Werte in Stunden-, Tages-, Wochen- und Monatswerten ist eine sinnvolle<br />
Erweiterung bei der Verbrauchserfassung.<br />
<br />
HourCounter bietet Schnittstellen an, die es ermöglichen, das Modul selbst mit neuen Eigenschaften zu erweitern.<br />
<br />
Die Referenz-Implementierung in 99_UtilsHourCounter.pm zeigt, wie dies skript-technisch zu realisieren ist.<br />
<br />
==== Installation ====<br />
Die jeweils aktuelle Version von 99_UtilsHourCounter kann über diesen <br />
[http://sourceforge.net/p/fhem/code/HEAD/tree/trunk/fhem/contrib/99_UtilsHourCounter.pm?format=raw Link] bezogen werden.<br />
<br />
==== Readings ====<br />
99_UtilsHourCounter erweitert den HourCounter um folgende Funktionen:<br />
{| class="wikitable sortable"<br />
|-<br />
! Reading !! class="unsortable" | Beschreibung<br />
|-<br />
| appCountsPerHour || Stundenzähler, wird bei Stundenwechsel aktualisiert<br />
|-<br />
| appCountsPerHourTemp || Arbeitszähler zu appCountsPerHour<br />
|-<br />
| appCountsPerDay || Tageszähler, wird bei Tageswechsel aktualisiert (Arbeitszähler ist countsPerDay)<br />
|-<br />
| appCountsPerWeek || Wochenzähler, wird bei Wochenwechsel aktualisiert<br />
|-<br />
| appCountsPerWeekTemp || Arbeitszähler zu appCountsPerWeek<br />
|-<br />
| appCountsPerMonth || Monatszähler, wird bei Monatswechsel aktualisiert<br />
|-<br />
| appCountsPerMonthTemp || Arbeitszähler zu appCountsPerMonth<br />
|-<br />
| appCountsPerYear || Jahreszähler, wird bei Jahreswechsel aktualisiert<br />
|-<br />
| appCountsPerYearTemp || Arbeitszähler zu appCountsPerYear<br />
|-<br />
| appOpHoursPerDay || Betriebsstunden des Tages<br />
|-<br />
| appOpHoursPerDayTemp || Arbeitszähler zu appOpHoursPerDay<br />
|-<br />
| appOpHoursPerWeek || Betriebsstunden der Woche<br />
|-<br />
| appOpHoursPerWeekTemp || Arbeitszähler zu appOpHoursPerWeek<br />
|-<br />
| appOpHoursPerMonth || Betriebsstunden des Monats<br />
|-<br />
| appOpHoursPerMonthTemp || Arbeitszähler appOpHoursPerMonth<br />
|-<br />
| appOpHoursPerYear || Betriebsstunden des Jahres<br />
|-<br />
| appOpHoursPerYearTemp || Arbeitszähler appOpHoursPerYear<br />
|-<br />
| appUtilization || Auslastung = pulseTimePerDay /(vergangene Sekunden seit Tagesbeginn) * 100<br />
|-<br />
| appUtilizationTemp || Arbeitsvariable zu appUtilization<br />
|}<br />
Beginn der Woche ist jeweils der Sonntag.<br /><br />
<br />
Mit folgender Anweisung aktivieren wir die Erweiterungen: <br />
:<code><br />
define CN.EVENT notify CN\..*:tick.* { appHCNotify("%NAME","%EVTPART0","%EVTPART1");;}<br />
</code><br />
<br />
Spätestens nach einer steigenden und einer fallenden Flanke sind die zuvor genannten app*-Readings zu sehen.<br />
{{Randnotiz|RNTyp=Info|RNText=Die gezeigten define-Anweisungen müssen jeweils in einer Zeile stehen (keine Zeilenumbrüche!).}}<br />
<br />
Die neuen Readings werden automatisch in den "Setter" der Web-Oberflächen aufgenommen. Dies gilt für alle Readings, die mit "app" beginnen.<br />
<br />
Somit können die neuen Readings beliebig manipuliert werden.<br />
<br />
==== Archiv für Tages-/Wochen-/Monats-/Jahreswerte anlegen ====<br />
Nun wollen wir die aggregierten Werte in eine eigene Datei speichern. Dies gelingt mit <br />
:<code>define CN.Test.FileDay FileLog ./log/CN.Test-Day-%Y.log CN.Test:app\w+ (Utilization|PerHour|PerDay|PerWeek|PerMonth|PerYear)(?!Temp).* </code><br />
<br />
<br />
Im Klartext:<br />
* verwende alle Werte des Counters CN.Test, deren Reading mit "app" beginnt<br />
* und die einen der Terme appUtilization|PerHour|PerDay|PerWeek|PerMonth|PerYear beinhalten<br />
* und die danach nicht dem Term "Temp" beinhalten<br />
<br />
== Fragen und Antworten ==<br />
==== Betriebsstundenzähler über Leistungsmessung ableiten ====<br />
'''Frage:'''<br />
Ich würde gerne zählen, wenn ich mehr Strom als Standy verbrauche (also mehr als 2Watt)<br />
und keine Betriebsstunden zählen, wenn der Verbrauch unter 2 Watt ist. Ist das möglich?<br />
<br />
<u>Beispiel für die Events</u><br />
<pre><br />
013-11-18_19:40:32 XXX power: 1.9<br />
2013-11-18_19:40:32 XXX consumption: 2<br />
2013-11-18_19:40:32 XXX consumptionTotal: 2<br />
2013-11-18_19:40:36 XXX power: 27<br />
2013-11-18_19:40:36 XXX consumption: 2<br />
2013-11-18_19:40:36 XXX consumptionTotal: 2<br />
2013-11-18_19:40:42 XXX power: 34.6<br />
2013-11-18_19:40:42 XXX consumption: 2 <br />
</pre><br />
<br />
'''Antwort'''<br />
<pre><br />
define CN.Test HourCounter XXX:power:\s[0-9]{2,}(\.[0-9]{1,3})*$ XXX:power:\s[0-9]{1}(\.[0-9]{1,3})*$<br />
</pre><br />
Erläuterung zu <regexp_for_ON> = XXX:power:\s[0-9]{2,}(\.[0-9]{1,3})*$<br />
* "XXX" bezeichnet das Device, der Term danach ist der regexp-Filte für das On-Ereignis<br />
* "power:" das Ereignis muss mit diesem Term beginnen<br />
* "\s" es muss ein Leerzeichen folgen<br />
* "[0-9]{2,}" es müssen mindestens 2 Ziffern folgen<br />
* "(\.[0-9]{1,3})*" wenn ein Punkt folgt, dann müssen auf diesen mindestens 1..3 Ziffern folgen<br />
* "$" danach darf kein weiteres Zeichen mehr folgen<br />
<br />
==== Welche Anwendungsfälle sind denkbar ? ====<br />
[http://forum.fhem.de/index.php/topic,12216.msg175163.html#msg175163 Aus dem Forum]<br />
* Betriebsstundenzähler für meine "Fliegenkiller-Steckdose"<br />
* Nutzungsdauer beschränken für TV,Internet oder Spielkonsolen für entnervte Eltern<br />
* Nutzungsdauer ermitteln zur Energieeinsparung (Klimageräte, Ventilatoren, Dunstabzugshauben etc.)<br />
* Lüftungsverhalten ermitteln (wie lange Fenster pro Tag geöffnet)<br />
<br />
[http://forum.fhem.de/index.php/topic,12216.msg195358.html#msg195358 Brenner Starts/Verbrauch + akkumulierte Werte]<br />
<br />
[http://forum.fhem.de/index.php/topic,12216.msg196358.html#msg196358 Ölverbrauch+Solar-Ladung]<br />
<br />
[http://voizchat.de/gaszaehler-verbrauch-erfassen-mit-fhem-und-raspberry-gpio/ Gaszähler mit HourCounter realisieren]<br />
==== Seltene Schaltvorgänge ====<br />
Die Schaltvorgänge sind über den Tag sehr wenige. Die Aktualisierung erfolgt immer erst<br />
bei der negativen Flanke. Wie kann man eine häufigere Aktualisierung erreichen ?<br />
<br />
'''Antwort'''<br />
<br />
Ab Version 1.0.0.6 ist wurde das Attribut "interval" eingeführt; es ist auf 60 Minuten voreingestellt und kann von 5..60 im 5 Minuten-Raster festgelegt werden.<br />
Es bestimmt, nach welcher Zeit Puls-/Pausendauer aktualisiert werden sollen, unabhängig vom Auftreten einer Schaltflanke.<br />
<br />
==== Korrekte Darstellung der akkumulierten Daten im Chart ====<br />
'''Frage'''<br />
<br />
"appCountsPerDay: 4" bezieht sich auf die Counts des Tages 2014-06-16, trägt aber selbst den Zeitstempel 2014-06-17 und wird demnach in einem Chart auch über den Tag " 2014-06-17" dargestellt.<br />
Das Problem betrifft alle akkumulierten Daten des HourCounters.<br />
Wie erreicht man im Chart die korrekte Darstellung ?<br />
<br />
<br />
'''Antwort'''<br />
<br />
Das Thema wurde [http://forum.fhem.de/index.php/topic,12216.msg239929.html#msg239929 hier] disktuiert.<br />
Eine Lösung findet man mit [http://www.fhemwiki.de/wiki/LogProxy LogProxy].<br />
Damit läßt sich ein negativer Offset für die X-Achse definieren, so daß die Daten wieder korrekt dargestellt werden.<br />
<br />
[[Kategorie:MAX]]<br />
[[Kategorie:HOWTOS]]</div>Johnhttp://wiki.fhem.de/w/index.php?title=Benutzer_Diskussion:John&diff=9014Benutzer Diskussion:John2014-12-27T14:54:47Z<p>John: /* Vorschaufunktion */</p>
<hr />
<div>Artikel HourCounter:<br />
<br />
John, könntest du in Erwägung ziehen, in Zukunft beim Anlegen von Artikeln die VORSCHAU zu benutzen? Der fragliche Artikel hat über 30 Edits, zum Teil nur wenige Bytes innerhalb von Minuten. Das Problem ist, dass einem das ganze Aktivitätenlog zuschreibt, das ich aber aus Maintaincegründen wenigstens ab und an überfliegen muss. Machts nicht leicher wenn alleine für ein Artikel 100 Zeilen da drin stehen.<br />
<br />
Grüsse,<br />
[[Benutzer:Soulman|Soulman]] ([[Benutzer Diskussion:Soulman|Diskussion]]) 18:51, 16. Nov. 2013 (CET)<br />
<br />
Hallo Soulman,<br />
ich werde mich bemühen, diesen Aspekt in Zukunft besser zu berücksichtigen.<br />
<br />
Gruß<br />
John<br />
<br />
== PIDxx Artikel ==<br />
<br />
Hallo John, <br />
<br />
wenn Du Unterstützung brauchst bei der Gestaltung der Artikel zu PID, insbesondere<br />
* welche Seiten<br />
* welche Seitentitel<br />
* welche Kategorien<br />
* Struktur<br />
* Wiki-Syntax...<br />
dann lass es mich / uns bitte wissen. Aber möglichst in der derzeitigen Phase nicht so viel neu anlegen / umbenennen / ... (bedeutet nachher alles zusätzlichen Aufwand). <br />
<br />
Was mir im Augenblick noch fehlt:<br />
* ist die Kategorie "Regelungstechnik" sinnvoll (gibt es Aussicht auf weitere Artikel in der Kategorie?)<br />
* In einem der Artikel sollte (knapp - kein Wikipedia-tauglicher Rundumschlag) erläutert sein, was PID überhaupt ist und was das Modul machen soll<br />
* Warum gibt es "PID" und "PID20 - Der PID-Regler" als eigene Artikel?<br />
* Mindestens einer der Artikel gehört nicht in die Kategorie "Glossary"<br />
<br />
Wichtig: bitte nicht als Kritik verstehen, sondern als Angebot, eine runde, verständliche Beschreibung für das Thema hinzubekommen.<br />
<br />
--[[Benutzer:Ph1959de|Greetz, Peter]] ([[Benutzer Diskussion:Ph1959de|Diskussion]]) 09:44, 3. Dez. 2013 (CET)<br />
:<hr /><br />
:<ph1959de>Ich hole mal "Wiki-üblich" die Diskussion (von "meiner" Diskussionsseite) dahin zurück, wo sie begonnen wurde...</ph1959de><br />
:<hr /><br />
:Hallo Peter, zu Deiner Anmerkung:<br />
:"In einem der Artikel sollte (knapp - kein Wikipedia-tauglicher Rundumschlag) erläutert sein, was PID überhaupt ist und was das Modul machen soll"<br />
<br />
:ich sehe folgende Probleme:<br />
:* die Foreneinträge werden teilweise derart lang, daß jedermann den Überblick verliert<br />
:* die CommandRef ist in ihrer komprimierten Form nicht in der Lage, komplexe Themen und Fragestellungen darzustellen und zu klären<br />
:* ich, als Entwickler, sehe mich immer wieder denselben Fragen gegenüber, obwohl diese schon zig-fach beantwortet wurden; gleichzeitig ist es oft für die Anwender schwierig diese Antworten im Forum zu finden<br />
:* ich sehe daher das Wiki als ideale Plattform und alle Fragestellungen und die genaue technische Erläuterung zu den Modulen darzulegen<br />
:* der Artikel zum Max-Scanner gibt mir Recht, die Aufrufe sind innerhalb kurzer Zeit von wenigen 100 auf 1300 gestiegen<br />
:* das kollidiert natürlich mit deiner Forderung nach "Knappheit des Artikels"<br />
:* für mich als Entwickler ist das WIKI in der von mir genutzten Form eine Entlastung, da viele Fragen, vorab von den Anwendern selbst geklärt werden können<br />
:* ich verweise explizit am Anfang eines Threads auf die entsprechende Wiki Seite, um den Usern die Informationsfindung zu erleichtern.<br />
<br />
:Wenn dies alles nicht in dieser Form unerwünscht ist kannst du mir vielleicht einen besseren Weg weisen. Entwickeln und die Anwender bei Fragen zu unterstützen braucht eine Menge Zeit.<br />
:Da ist jedes Hilfsmittel willkommen.<br />
:John<br />
<br />
:<hr /><br />
::Oh, dann hast Du mich leider doch falsch verstanden. <br />
<br />
::Natürlich ist es sinnvoll, die Informationen aus (den verschiedenen) Forenthreads im Wiki zu konsolidieren. Daher ja auch mein Angebot zur Unterstützung. Mir ging es primär um Wiki-spezifische Aspekte wie z.B. den generellen Aufbau von Artikeln.<br />
<br />
::Konkret auf die PID-Artikel bezogen heißt das jetzt: ich fange an zu lesen ... und stelle fest, dass ich nicht wirklich weiß, was PID überhaupt bedeutet. Und daraus (wie auch aus Deinen verschiedenen Ansätzen, den Artikel aufzusetzen) habe ich den Eindruck bekommen, dass Du noch auf der Suche nach der geeigneten Struktur für die Dokumentation Deines Moduls bist.<br />
<br />
::Meine "Forderung" nach Knappheit bezog sich ausschließlich auf die Erläuterung zu "PID" als Begriff, nicht auf die Dokumentation des Moduls und dem ganzen "Drumherum".<br />
<br />
::Auf einen neuen Versuch für eine konstruktive Zusammenarbeit --[[Benutzer:Ph1959de|Greetz, Peter]] ([[Benutzer Diskussion:Ph1959de|Diskussion]]) 10:57, 3. Dez. 2013 (CET)<br />
<br />
== Hochgeladene Dateien löschen ==<br />
wie kann man nicht mehr benötigte hochgeladene Grafikdateien löschen ? (Logo 012.png)<br />
:<hr /><br />
:Das können nur Administratoren - wenn Du Dicher bist, kann ich die Datei für Dich löschen. Einen "etablierten" Weg haben wir dafür (noch) nicht. Alternativ hättest Du aber auch selbst die Datei einfach auf einen neuen Namen "verschieben" können. Vielleicht bietet sich ja demnächst noch mal eine Gelegenheit dazu. --[[Benutzer:Ph1959de|Peter]] ([[Benutzer Diskussion:Ph1959de|Diskussion]]) 12:18, 27. Dez. 2014 (UTC)<br />
<br />
::<hr /><br />
::Hallo Peter, danke für die Antwort, so muss ich nicht weiter danach suchen.<br />
::[[Benutzer:John|John]]<br />
<br />
== Vorschaufunktion ==<br />
Hallo John,<br />
<br />
vielen Dank für Deine Beiträge zum Fhem-Wiki.<br />
[[Datei:Vorschau (de).png|rechts|350px|verweis=Hilfe:Seite bearbeiten|Schaltfläche „Vorschau zeigen“]]<br />
Mir ist aufgefallen, dass Du kurz hintereinander mehrere kleine Änderungen an einem Artikel vorgenommen hast. Solche sollten jedoch gesammelt durchgeführt werden, damit die [http://de.wikipedia.org/wiki/Wikipedia:Hilfe:Versionen Versionsgeschichte] für andere Benutzer übersichtlich und nachvollziehbarer bleibt. Daher ist es stets zu empfehlen, die Schaltfläche {{Taste|[http://de.wikipedia.org/wiki/Wikipedia:Hilfe:Seite_bearbeiten#Vorschau_und_Speichern Vorschau zeigen]}} unterhalb des Artikels zu benutzen (siehe Bild). Das erlaubt Dir zudem, Deine Änderungen auf Richtigkeit zu überprüfen, bevor Du sie durch Klicken auf {{Taste|Seite speichern}} veröffentlichst und sie in der Versionsgeschichte des Artikels sowie den [http://de.wikipedia.org/wiki/Wikipedia:Hilfe:Beobachtungsliste Beobachtungslisten] anderer Benutzer erscheinen.<br />
<br />
Solltest Du eine größere Überarbeitung aus Sorge vor [http://de.wikipedia.org/wiki/Wikipedia:Hilfe:Bearbeitungskonflikt Bearbeitungskonflikten] in viele Einzeländerungen aufgeteilt haben, könnte der Textbaustein <nowiki>{{Baustelle}}</nowiki> nützlich sein.<br />
<br />
Trage zudem vor dem Speichern bitte immer eine kurze Zusammenfassung der Änderungen in das Feld [http://de.wikipedia.org/wiki/Wikipedia:Hilfe:Zusammenfassung_und_Quellen Zusammenfassung] ein.<br />
<br />
Danke und viele Grüße --[[Benutzer:Ph1959de|Peter]] ([[Benutzer Diskussion:Ph1959de|Diskussion]]) 12:18, 27. Dez. 2014 (UTC)<br />
::<hr /><br />
:Hallo Peter, <br />
: * ich nutzte die Vorschau natürlich, auch wenn es nicht immer so aussieht<br />
: * ich schreibe bisher nur Wikis zu Modulen, die ich programmiert habe<br />
: <br /><br />
: ich sehe folgende Probleme deinem Wunsch nachzukommen<br />
:<br />
: * eine großes Wiki als Ganzes zu editieren ist "grauenhaft", es fehlt jeder Überblick im kleinen Editor-Fenster<br />
: * es gibt keine Undo-Funktion, wenn man einen Fehler macht muss man alles verwerfen<br />
: * ich investiere viel Energie beim Programmieren der Module, das Wiki zu schreiben muss daher einfach sein<br />
: * das ist es unter den gegebenen Umständen, wenn ich partiell editieren kann<br />
: * die meisten Wikis schreibe ich unmittelbar nach dem Programmieren, da ist mein Wissen noch aktuell; aber mit meiner Aufmerksamkeit ist es nicht mehr weit her.<br />
: * meine oberste Priorität ist es nicht, dies mit möglichst wenige Wiki-Version umzusetzen, sondern das überhaupt "gebacken" zu bekommen<br />
: * ich freue mich, wenn du mir Lösungen zeigen kannst, mit denen ich leben kann<br />
: John</div>Johnhttp://wiki.fhem.de/w/index.php?title=Benutzer_Diskussion:John&diff=9013Benutzer Diskussion:John2014-12-27T14:32:49Z<p>John: /* Hochgeladene Dateien löschen */</p>
<hr />
<div>Artikel HourCounter:<br />
<br />
John, könntest du in Erwägung ziehen, in Zukunft beim Anlegen von Artikeln die VORSCHAU zu benutzen? Der fragliche Artikel hat über 30 Edits, zum Teil nur wenige Bytes innerhalb von Minuten. Das Problem ist, dass einem das ganze Aktivitätenlog zuschreibt, das ich aber aus Maintaincegründen wenigstens ab und an überfliegen muss. Machts nicht leicher wenn alleine für ein Artikel 100 Zeilen da drin stehen.<br />
<br />
Grüsse,<br />
[[Benutzer:Soulman|Soulman]] ([[Benutzer Diskussion:Soulman|Diskussion]]) 18:51, 16. Nov. 2013 (CET)<br />
<br />
Hallo Soulman,<br />
ich werde mich bemühen, diesen Aspekt in Zukunft besser zu berücksichtigen.<br />
<br />
Gruß<br />
John<br />
<br />
== PIDxx Artikel ==<br />
<br />
Hallo John, <br />
<br />
wenn Du Unterstützung brauchst bei der Gestaltung der Artikel zu PID, insbesondere<br />
* welche Seiten<br />
* welche Seitentitel<br />
* welche Kategorien<br />
* Struktur<br />
* Wiki-Syntax...<br />
dann lass es mich / uns bitte wissen. Aber möglichst in der derzeitigen Phase nicht so viel neu anlegen / umbenennen / ... (bedeutet nachher alles zusätzlichen Aufwand). <br />
<br />
Was mir im Augenblick noch fehlt:<br />
* ist die Kategorie "Regelungstechnik" sinnvoll (gibt es Aussicht auf weitere Artikel in der Kategorie?)<br />
* In einem der Artikel sollte (knapp - kein Wikipedia-tauglicher Rundumschlag) erläutert sein, was PID überhaupt ist und was das Modul machen soll<br />
* Warum gibt es "PID" und "PID20 - Der PID-Regler" als eigene Artikel?<br />
* Mindestens einer der Artikel gehört nicht in die Kategorie "Glossary"<br />
<br />
Wichtig: bitte nicht als Kritik verstehen, sondern als Angebot, eine runde, verständliche Beschreibung für das Thema hinzubekommen.<br />
<br />
--[[Benutzer:Ph1959de|Greetz, Peter]] ([[Benutzer Diskussion:Ph1959de|Diskussion]]) 09:44, 3. Dez. 2013 (CET)<br />
:<hr /><br />
:<ph1959de>Ich hole mal "Wiki-üblich" die Diskussion (von "meiner" Diskussionsseite) dahin zurück, wo sie begonnen wurde...</ph1959de><br />
:<hr /><br />
:Hallo Peter, zu Deiner Anmerkung:<br />
:"In einem der Artikel sollte (knapp - kein Wikipedia-tauglicher Rundumschlag) erläutert sein, was PID überhaupt ist und was das Modul machen soll"<br />
<br />
:ich sehe folgende Probleme:<br />
:* die Foreneinträge werden teilweise derart lang, daß jedermann den Überblick verliert<br />
:* die CommandRef ist in ihrer komprimierten Form nicht in der Lage, komplexe Themen und Fragestellungen darzustellen und zu klären<br />
:* ich, als Entwickler, sehe mich immer wieder denselben Fragen gegenüber, obwohl diese schon zig-fach beantwortet wurden; gleichzeitig ist es oft für die Anwender schwierig diese Antworten im Forum zu finden<br />
:* ich sehe daher das Wiki als ideale Plattform und alle Fragestellungen und die genaue technische Erläuterung zu den Modulen darzulegen<br />
:* der Artikel zum Max-Scanner gibt mir Recht, die Aufrufe sind innerhalb kurzer Zeit von wenigen 100 auf 1300 gestiegen<br />
:* das kollidiert natürlich mit deiner Forderung nach "Knappheit des Artikels"<br />
:* für mich als Entwickler ist das WIKI in der von mir genutzten Form eine Entlastung, da viele Fragen, vorab von den Anwendern selbst geklärt werden können<br />
:* ich verweise explizit am Anfang eines Threads auf die entsprechende Wiki Seite, um den Usern die Informationsfindung zu erleichtern.<br />
<br />
:Wenn dies alles nicht in dieser Form unerwünscht ist kannst du mir vielleicht einen besseren Weg weisen. Entwickeln und die Anwender bei Fragen zu unterstützen braucht eine Menge Zeit.<br />
:Da ist jedes Hilfsmittel willkommen.<br />
:John<br />
<br />
:<hr /><br />
::Oh, dann hast Du mich leider doch falsch verstanden. <br />
<br />
::Natürlich ist es sinnvoll, die Informationen aus (den verschiedenen) Forenthreads im Wiki zu konsolidieren. Daher ja auch mein Angebot zur Unterstützung. Mir ging es primär um Wiki-spezifische Aspekte wie z.B. den generellen Aufbau von Artikeln.<br />
<br />
::Konkret auf die PID-Artikel bezogen heißt das jetzt: ich fange an zu lesen ... und stelle fest, dass ich nicht wirklich weiß, was PID überhaupt bedeutet. Und daraus (wie auch aus Deinen verschiedenen Ansätzen, den Artikel aufzusetzen) habe ich den Eindruck bekommen, dass Du noch auf der Suche nach der geeigneten Struktur für die Dokumentation Deines Moduls bist.<br />
<br />
::Meine "Forderung" nach Knappheit bezog sich ausschließlich auf die Erläuterung zu "PID" als Begriff, nicht auf die Dokumentation des Moduls und dem ganzen "Drumherum".<br />
<br />
::Auf einen neuen Versuch für eine konstruktive Zusammenarbeit --[[Benutzer:Ph1959de|Greetz, Peter]] ([[Benutzer Diskussion:Ph1959de|Diskussion]]) 10:57, 3. Dez. 2013 (CET)<br />
<br />
== Hochgeladene Dateien löschen ==<br />
wie kann man nicht mehr benötigte hochgeladene Grafikdateien löschen ? (Logo 012.png)<br />
:<hr /><br />
:Das können nur Administratoren - wenn Du Dicher bist, kann ich die Datei für Dich löschen. Einen "etablierten" Weg haben wir dafür (noch) nicht. Alternativ hättest Du aber auch selbst die Datei einfach auf einen neuen Namen "verschieben" können. Vielleicht bietet sich ja demnächst noch mal eine Gelegenheit dazu. --[[Benutzer:Ph1959de|Peter]] ([[Benutzer Diskussion:Ph1959de|Diskussion]]) 12:18, 27. Dez. 2014 (UTC)<br />
<br />
::<hr /><br />
::Hallo Peter, danke für die Antwort, so muss ich nicht weiter danach suchen.<br />
::[[Benutzer:John|John]]<br />
<br />
== Vorschaufunktion ==<br />
Hallo John,<br />
<br />
vielen Dank für Deine Beiträge zum Fhem-Wiki.<br />
[[Datei:Vorschau (de).png|rechts|350px|verweis=Hilfe:Seite bearbeiten|Schaltfläche „Vorschau zeigen“]]<br />
Mir ist aufgefallen, dass Du kurz hintereinander mehrere kleine Änderungen an einem Artikel vorgenommen hast. Solche sollten jedoch gesammelt durchgeführt werden, damit die [http://de.wikipedia.org/wiki/Wikipedia:Hilfe:Versionen Versionsgeschichte] für andere Benutzer übersichtlich und nachvollziehbarer bleibt. Daher ist es stets zu empfehlen, die Schaltfläche {{Taste|[http://de.wikipedia.org/wiki/Wikipedia:Hilfe:Seite_bearbeiten#Vorschau_und_Speichern Vorschau zeigen]}} unterhalb des Artikels zu benutzen (siehe Bild). Das erlaubt Dir zudem, Deine Änderungen auf Richtigkeit zu überprüfen, bevor Du sie durch Klicken auf {{Taste|Seite speichern}} veröffentlichst und sie in der Versionsgeschichte des Artikels sowie den [http://de.wikipedia.org/wiki/Wikipedia:Hilfe:Beobachtungsliste Beobachtungslisten] anderer Benutzer erscheinen.<br />
<br />
Solltest Du eine größere Überarbeitung aus Sorge vor [http://de.wikipedia.org/wiki/Wikipedia:Hilfe:Bearbeitungskonflikt Bearbeitungskonflikten] in viele Einzeländerungen aufgeteilt haben, könnte der Textbaustein <nowiki>{{Baustelle}}</nowiki> nützlich sein.<br />
<br />
Trage zudem vor dem Speichern bitte immer eine kurze Zusammenfassung der Änderungen in das Feld [http://de.wikipedia.org/wiki/Wikipedia:Hilfe:Zusammenfassung_und_Quellen Zusammenfassung] ein.<br />
<br />
Danke und viele Grüße --[[Benutzer:Ph1959de|Peter]] ([[Benutzer Diskussion:Ph1959de|Diskussion]]) 12:18, 27. Dez. 2014 (UTC)</div>Johnhttp://wiki.fhem.de/w/index.php?title=Benutzer_Diskussion:John&diff=9000Benutzer Diskussion:John2014-12-27T11:20:19Z<p>John: /* Hochgeladene Dateien löschen */</p>
<hr />
<div>Artikel HourCounter:<br />
<br />
John, könntest du in Erwägung ziehen, in Zukunft beim Anlegen von Artikeln die VORSCHAU zu benutzen? Der fragliche Artikel hat über 30 Edits, zum Teil nur wenige Bytes innerhalb von Minuten. Das Problem ist, dass einem das ganze Aktivitätenlog zuschreibt, das ich aber aus Maintaincegründen wenigstens ab und an überfliegen muss. Machts nicht leicher wenn alleine für ein Artikel 100 Zeilen da drin stehen.<br />
<br />
Grüsse,<br />
[[Benutzer:Soulman|Soulman]] ([[Benutzer Diskussion:Soulman|Diskussion]]) 18:51, 16. Nov. 2013 (CET)<br />
<br />
Hallo Soulman,<br />
ich werde mich bemühen, diesen Aspekt in Zukunft besser zu berücksichtigen.<br />
<br />
Gruß<br />
John<br />
<br />
== PIDxx Artikel ==<br />
<br />
Hallo John, <br />
<br />
wenn Du Unterstützung brauchst bei der Gestaltung der Artikel zu PID, insbesondere<br />
* welche Seiten<br />
* welche Seitentitel<br />
* welche Kategorien<br />
* Struktur<br />
* Wiki-Syntax...<br />
dann lass es mich / uns bitte wissen. Aber möglichst in der derzeitigen Phase nicht so viel neu anlegen / umbenennen / ... (bedeutet nachher alles zusätzlichen Aufwand). <br />
<br />
Was mir im Augenblick noch fehlt:<br />
* ist die Kategorie "Regelungstechnik" sinnvoll (gibt es Aussicht auf weitere Artikel in der Kategorie?)<br />
* In einem der Artikel sollte (knapp - kein Wikipedia-tauglicher Rundumschlag) erläutert sein, was PID überhaupt ist und was das Modul machen soll<br />
* Warum gibt es "PID" und "PID20 - Der PID-Regler" als eigene Artikel?<br />
* Mindestens einer der Artikel gehört nicht in die Kategorie "Glossary"<br />
<br />
Wichtig: bitte nicht als Kritik verstehen, sondern als Angebot, eine runde, verständliche Beschreibung für das Thema hinzubekommen.<br />
<br />
--[[Benutzer:Ph1959de|Greetz, Peter]] ([[Benutzer Diskussion:Ph1959de|Diskussion]]) 09:44, 3. Dez. 2013 (CET)<br />
:<hr /><br />
:<ph1959de>Ich hole mal "Wiki-üblich" die Diskussion (von "meiner" Diskussionsseite) dahin zurück, wo sie begonnen wurde...</ph1959de><br />
:<hr /><br />
:Hallo Peter, zu Deiner Anmerkung:<br />
:"In einem der Artikel sollte (knapp - kein Wikipedia-tauglicher Rundumschlag) erläutert sein, was PID überhaupt ist und was das Modul machen soll"<br />
<br />
:ich sehe folgende Probleme:<br />
:* die Foreneinträge werden teilweise derart lang, daß jedermann den Überblick verliert<br />
:* die CommandRef ist in ihrer komprimierten Form nicht in der Lage, komplexe Themen und Fragestellungen darzustellen und zu klären<br />
:* ich, als Entwickler, sehe mich immer wieder denselben Fragen gegenüber, obwohl diese schon zig-fach beantwortet wurden; gleichzeitig ist es oft für die Anwender schwierig diese Antworten im Forum zu finden<br />
:* ich sehe daher das Wiki als ideale Plattform und alle Fragestellungen und die genaue technische Erläuterung zu den Modulen darzulegen<br />
:* der Artikel zum Max-Scanner gibt mir Recht, die Aufrufe sind innerhalb kurzer Zeit von wenigen 100 auf 1300 gestiegen<br />
:* das kollidiert natürlich mit deiner Forderung nach "Knappheit des Artikels"<br />
:* für mich als Entwickler ist das WIKI in der von mir genutzten Form eine Entlastung, da viele Fragen, vorab von den Anwendern selbst geklärt werden können<br />
:* ich verweise explizit am Anfang eines Threads auf die entsprechende Wiki Seite, um den Usern die Informationsfindung zu erleichtern.<br />
<br />
:Wenn dies alles nicht in dieser Form unerwünscht ist kannst du mir vielleicht einen besseren Weg weisen. Entwickeln und die Anwender bei Fragen zu unterstützen braucht eine Menge Zeit.<br />
:Da ist jedes Hilfsmittel willkommen.<br />
:John<br />
<br />
:<hr /><br />
::Oh, dann hast Du mich leider doch falsch verstanden. <br />
<br />
::Natürlich ist es sinnvoll, die Informationen aus (den verschiedenen) Forenthreads im Wiki zu konsolidieren. Daher ja auch mein Angebot zur Unterstützung. Mir ging es primär um Wiki-spezifische Aspekte wie z.B. den generellen Aufbau von Artikeln.<br />
<br />
::Konkret auf die PID-Artikel bezogen heißt das jetzt: ich fange an zu lesen ... und stelle fest, dass ich nicht wirklich weiß, was PID überhaupt bedeutet. Und daraus (wie auch aus Deinen verschiedenen Ansätzen, den Artikel aufzusetzen) habe ich den Eindruck bekommen, dass Du noch auf der Suche nach der geeigneten Struktur für die Dokumentation Deines Moduls bist.<br />
<br />
::Meine "Forderung" nach Knappheit bezog sich ausschließlich auf die Erläuterung zu "PID" als Begriff, nicht auf die Dokumentation des Moduls und dem ganzen "Drumherum".<br />
<br />
::Auf einen neuen Versuch für eine konstruktive Zusammenarbeit --[[Benutzer:Ph1959de|Greetz, Peter]] ([[Benutzer Diskussion:Ph1959de|Diskussion]]) 10:57, 3. Dez. 2013 (CET)<br />
<br />
== Hochgeladene Dateien löschen ==<br />
<br />
wie kann man nicht mehr benötigte hochgeladene Grafikdateien löschen ? (Logo 012.png)</div>Johnhttp://wiki.fhem.de/w/index.php?title=Benutzer_Diskussion:John&diff=8999Benutzer Diskussion:John2014-12-27T11:19:34Z<p>John: /* Hochgeladene Dateine löschen */</p>
<hr />
<div>Artikel HourCounter:<br />
<br />
John, könntest du in Erwägung ziehen, in Zukunft beim Anlegen von Artikeln die VORSCHAU zu benutzen? Der fragliche Artikel hat über 30 Edits, zum Teil nur wenige Bytes innerhalb von Minuten. Das Problem ist, dass einem das ganze Aktivitätenlog zuschreibt, das ich aber aus Maintaincegründen wenigstens ab und an überfliegen muss. Machts nicht leicher wenn alleine für ein Artikel 100 Zeilen da drin stehen.<br />
<br />
Grüsse,<br />
[[Benutzer:Soulman|Soulman]] ([[Benutzer Diskussion:Soulman|Diskussion]]) 18:51, 16. Nov. 2013 (CET)<br />
<br />
Hallo Soulman,<br />
ich werde mich bemühen, diesen Aspekt in Zukunft besser zu berücksichtigen.<br />
<br />
Gruß<br />
John<br />
<br />
== PIDxx Artikel ==<br />
<br />
Hallo John, <br />
<br />
wenn Du Unterstützung brauchst bei der Gestaltung der Artikel zu PID, insbesondere<br />
* welche Seiten<br />
* welche Seitentitel<br />
* welche Kategorien<br />
* Struktur<br />
* Wiki-Syntax...<br />
dann lass es mich / uns bitte wissen. Aber möglichst in der derzeitigen Phase nicht so viel neu anlegen / umbenennen / ... (bedeutet nachher alles zusätzlichen Aufwand). <br />
<br />
Was mir im Augenblick noch fehlt:<br />
* ist die Kategorie "Regelungstechnik" sinnvoll (gibt es Aussicht auf weitere Artikel in der Kategorie?)<br />
* In einem der Artikel sollte (knapp - kein Wikipedia-tauglicher Rundumschlag) erläutert sein, was PID überhaupt ist und was das Modul machen soll<br />
* Warum gibt es "PID" und "PID20 - Der PID-Regler" als eigene Artikel?<br />
* Mindestens einer der Artikel gehört nicht in die Kategorie "Glossary"<br />
<br />
Wichtig: bitte nicht als Kritik verstehen, sondern als Angebot, eine runde, verständliche Beschreibung für das Thema hinzubekommen.<br />
<br />
--[[Benutzer:Ph1959de|Greetz, Peter]] ([[Benutzer Diskussion:Ph1959de|Diskussion]]) 09:44, 3. Dez. 2013 (CET)<br />
:<hr /><br />
:<ph1959de>Ich hole mal "Wiki-üblich" die Diskussion (von "meiner" Diskussionsseite) dahin zurück, wo sie begonnen wurde...</ph1959de><br />
:<hr /><br />
:Hallo Peter, zu Deiner Anmerkung:<br />
:"In einem der Artikel sollte (knapp - kein Wikipedia-tauglicher Rundumschlag) erläutert sein, was PID überhaupt ist und was das Modul machen soll"<br />
<br />
:ich sehe folgende Probleme:<br />
:* die Foreneinträge werden teilweise derart lang, daß jedermann den Überblick verliert<br />
:* die CommandRef ist in ihrer komprimierten Form nicht in der Lage, komplexe Themen und Fragestellungen darzustellen und zu klären<br />
:* ich, als Entwickler, sehe mich immer wieder denselben Fragen gegenüber, obwohl diese schon zig-fach beantwortet wurden; gleichzeitig ist es oft für die Anwender schwierig diese Antworten im Forum zu finden<br />
:* ich sehe daher das Wiki als ideale Plattform und alle Fragestellungen und die genaue technische Erläuterung zu den Modulen darzulegen<br />
:* der Artikel zum Max-Scanner gibt mir Recht, die Aufrufe sind innerhalb kurzer Zeit von wenigen 100 auf 1300 gestiegen<br />
:* das kollidiert natürlich mit deiner Forderung nach "Knappheit des Artikels"<br />
:* für mich als Entwickler ist das WIKI in der von mir genutzten Form eine Entlastung, da viele Fragen, vorab von den Anwendern selbst geklärt werden können<br />
:* ich verweise explizit am Anfang eines Threads auf die entsprechende Wiki Seite, um den Usern die Informationsfindung zu erleichtern.<br />
<br />
:Wenn dies alles nicht in dieser Form unerwünscht ist kannst du mir vielleicht einen besseren Weg weisen. Entwickeln und die Anwender bei Fragen zu unterstützen braucht eine Menge Zeit.<br />
:Da ist jedes Hilfsmittel willkommen.<br />
:John<br />
<br />
:<hr /><br />
::Oh, dann hast Du mich leider doch falsch verstanden. <br />
<br />
::Natürlich ist es sinnvoll, die Informationen aus (den verschiedenen) Forenthreads im Wiki zu konsolidieren. Daher ja auch mein Angebot zur Unterstützung. Mir ging es primär um Wiki-spezifische Aspekte wie z.B. den generellen Aufbau von Artikeln.<br />
<br />
::Konkret auf die PID-Artikel bezogen heißt das jetzt: ich fange an zu lesen ... und stelle fest, dass ich nicht wirklich weiß, was PID überhaupt bedeutet. Und daraus (wie auch aus Deinen verschiedenen Ansätzen, den Artikel aufzusetzen) habe ich den Eindruck bekommen, dass Du noch auf der Suche nach der geeigneten Struktur für die Dokumentation Deines Moduls bist.<br />
<br />
::Meine "Forderung" nach Knappheit bezog sich ausschließlich auf die Erläuterung zu "PID" als Begriff, nicht auf die Dokumentation des Moduls und dem ganzen "Drumherum".<br />
<br />
::Auf einen neuen Versuch für eine konstruktive Zusammenarbeit --[[Benutzer:Ph1959de|Greetz, Peter]] ([[Benutzer Diskussion:Ph1959de|Diskussion]]) 10:57, 3. Dez. 2013 (CET)<br />
<br />
== Hochgeladene Dateien löschen ==<br />
<br />
wie kann man nicht mehr benötigte hochgeladene Grafikdateien löschen ?</div>Johnhttp://wiki.fhem.de/w/index.php?title=Benutzer_Diskussion:John&diff=8998Benutzer Diskussion:John2014-12-27T11:19:19Z<p>John: Neuer Abschnitt /* Hochgeladene Dateine löschen */</p>
<hr />
<div>Artikel HourCounter:<br />
<br />
John, könntest du in Erwägung ziehen, in Zukunft beim Anlegen von Artikeln die VORSCHAU zu benutzen? Der fragliche Artikel hat über 30 Edits, zum Teil nur wenige Bytes innerhalb von Minuten. Das Problem ist, dass einem das ganze Aktivitätenlog zuschreibt, das ich aber aus Maintaincegründen wenigstens ab und an überfliegen muss. Machts nicht leicher wenn alleine für ein Artikel 100 Zeilen da drin stehen.<br />
<br />
Grüsse,<br />
[[Benutzer:Soulman|Soulman]] ([[Benutzer Diskussion:Soulman|Diskussion]]) 18:51, 16. Nov. 2013 (CET)<br />
<br />
Hallo Soulman,<br />
ich werde mich bemühen, diesen Aspekt in Zukunft besser zu berücksichtigen.<br />
<br />
Gruß<br />
John<br />
<br />
== PIDxx Artikel ==<br />
<br />
Hallo John, <br />
<br />
wenn Du Unterstützung brauchst bei der Gestaltung der Artikel zu PID, insbesondere<br />
* welche Seiten<br />
* welche Seitentitel<br />
* welche Kategorien<br />
* Struktur<br />
* Wiki-Syntax...<br />
dann lass es mich / uns bitte wissen. Aber möglichst in der derzeitigen Phase nicht so viel neu anlegen / umbenennen / ... (bedeutet nachher alles zusätzlichen Aufwand). <br />
<br />
Was mir im Augenblick noch fehlt:<br />
* ist die Kategorie "Regelungstechnik" sinnvoll (gibt es Aussicht auf weitere Artikel in der Kategorie?)<br />
* In einem der Artikel sollte (knapp - kein Wikipedia-tauglicher Rundumschlag) erläutert sein, was PID überhaupt ist und was das Modul machen soll<br />
* Warum gibt es "PID" und "PID20 - Der PID-Regler" als eigene Artikel?<br />
* Mindestens einer der Artikel gehört nicht in die Kategorie "Glossary"<br />
<br />
Wichtig: bitte nicht als Kritik verstehen, sondern als Angebot, eine runde, verständliche Beschreibung für das Thema hinzubekommen.<br />
<br />
--[[Benutzer:Ph1959de|Greetz, Peter]] ([[Benutzer Diskussion:Ph1959de|Diskussion]]) 09:44, 3. Dez. 2013 (CET)<br />
:<hr /><br />
:<ph1959de>Ich hole mal "Wiki-üblich" die Diskussion (von "meiner" Diskussionsseite) dahin zurück, wo sie begonnen wurde...</ph1959de><br />
:<hr /><br />
:Hallo Peter, zu Deiner Anmerkung:<br />
:"In einem der Artikel sollte (knapp - kein Wikipedia-tauglicher Rundumschlag) erläutert sein, was PID überhaupt ist und was das Modul machen soll"<br />
<br />
:ich sehe folgende Probleme:<br />
:* die Foreneinträge werden teilweise derart lang, daß jedermann den Überblick verliert<br />
:* die CommandRef ist in ihrer komprimierten Form nicht in der Lage, komplexe Themen und Fragestellungen darzustellen und zu klären<br />
:* ich, als Entwickler, sehe mich immer wieder denselben Fragen gegenüber, obwohl diese schon zig-fach beantwortet wurden; gleichzeitig ist es oft für die Anwender schwierig diese Antworten im Forum zu finden<br />
:* ich sehe daher das Wiki als ideale Plattform und alle Fragestellungen und die genaue technische Erläuterung zu den Modulen darzulegen<br />
:* der Artikel zum Max-Scanner gibt mir Recht, die Aufrufe sind innerhalb kurzer Zeit von wenigen 100 auf 1300 gestiegen<br />
:* das kollidiert natürlich mit deiner Forderung nach "Knappheit des Artikels"<br />
:* für mich als Entwickler ist das WIKI in der von mir genutzten Form eine Entlastung, da viele Fragen, vorab von den Anwendern selbst geklärt werden können<br />
:* ich verweise explizit am Anfang eines Threads auf die entsprechende Wiki Seite, um den Usern die Informationsfindung zu erleichtern.<br />
<br />
:Wenn dies alles nicht in dieser Form unerwünscht ist kannst du mir vielleicht einen besseren Weg weisen. Entwickeln und die Anwender bei Fragen zu unterstützen braucht eine Menge Zeit.<br />
:Da ist jedes Hilfsmittel willkommen.<br />
:John<br />
<br />
:<hr /><br />
::Oh, dann hast Du mich leider doch falsch verstanden. <br />
<br />
::Natürlich ist es sinnvoll, die Informationen aus (den verschiedenen) Forenthreads im Wiki zu konsolidieren. Daher ja auch mein Angebot zur Unterstützung. Mir ging es primär um Wiki-spezifische Aspekte wie z.B. den generellen Aufbau von Artikeln.<br />
<br />
::Konkret auf die PID-Artikel bezogen heißt das jetzt: ich fange an zu lesen ... und stelle fest, dass ich nicht wirklich weiß, was PID überhaupt bedeutet. Und daraus (wie auch aus Deinen verschiedenen Ansätzen, den Artikel aufzusetzen) habe ich den Eindruck bekommen, dass Du noch auf der Suche nach der geeigneten Struktur für die Dokumentation Deines Moduls bist.<br />
<br />
::Meine "Forderung" nach Knappheit bezog sich ausschließlich auf die Erläuterung zu "PID" als Begriff, nicht auf die Dokumentation des Moduls und dem ganzen "Drumherum".<br />
<br />
::Auf einen neuen Versuch für eine konstruktive Zusammenarbeit --[[Benutzer:Ph1959de|Greetz, Peter]] ([[Benutzer Diskussion:Ph1959de|Diskussion]]) 10:57, 3. Dez. 2013 (CET)<br />
<br />
== Hochgeladene Dateine löschen ==<br />
<br />
wie kann man nicht mehr benötigte hochgeladene Grafikdateien löschen ?</div>Johnhttp://wiki.fhem.de/w/index.php?title=HourCounter&diff=8790HourCounter2014-12-09T23:20:22Z<p>John: /* Konkret */</p>
<hr />
<div>{{Infobox Modul<br />
|ModPurpose=HourCounter dient zum Zählen von Ereignissen und zur Erfassung von Betriebs-/Ruhe-Zeiten<br />
|ModType=h<br />
<!-- |ModCmdRef=LightScene -- nicht erforderlich, da Modultyp x --><br />
|ModForumArea=MAX<br />
|ModTechName=98_HourCounter.pm<br />
|ModOwner=John ([http://forum.fhem.de/index.php?action=profile;u=806 Forum] / [[Benutzer Diskussion:John|Wiki]])}}<br />
<br />
<br />
[[HourCounter]] ist ein Perl-Modul, das die Anzahl von Ereignissen erfasst. Bei bipolaren Ereignissen wird zusätzlich die Puls- sowie die Pausendauer ermittelt. Im vorliegenden Beispiel wird ein Betriebsstundenzähler mit einem MAX-Fensterkontakt realisiert.<br />
<br />
== Features ==<br />
* Ermittlung von Betriebsstunden, Auslastung, Verbräuchen, Schalthäufigkeiten<br />
* Ermittlung der Häufigkeit, Puls- Pausendauer pro Tag<br />
* Ermittlung der Puls-/Pausendauer der letzten Schaltperiode<br />
* Bereitstellung von Ereignissen zur Fortführung der Kumulation für Tages-, Wochen- und Monatswerte<br />
* unterstützende Funktionen zur Ablage von Tages-, Wochen- und Monatswerten<br />
<br />
== Zielsetzung des WIKI-Artikels ==<br />
Erläuterung der Funktionalität zur weiterführenden Diskussion im [http://forum.fhem.de/index.php/topic,12216.msg72596.html#msg72596 Forum].<br />
<br />
== Aktuelle Version ==<br />
Das Modul ist seit dem 24.10.2014 Bestandteil von FHEM.<br />
<br />
== Definition ==<br />
=== Abstrakt ===<br />
<pre>define <name> HourCounter <regexp_for_ON> [<regexp_for_Off>]</pre><br />
<br />
<regexp_for_ON> ist ein regulärer Ausdruck der das Ereignis beschreibt.<br />
<br />
Wenn auch [<regexp_for_Off>] definiert ist, so sprechen wir von einem bipolarem Ereignis, das einen <br />
EIN- sowie einen AUS-Zustand aufweist.<br />
<br />
<regexp_for_ON> beschreibt in diesem Fall die positive Flanke,[<regexp_for_Off>] die negative Flanke. Die Struktur des regexp-Ausdruckes ist analog zu jener beim Notify aufgebaut.<br />
<br />
===Konkret===<br />
<pre>define CN.Test HourCounter SHUTTER.JOHN:onoff:.1 SHUTTER.JOHN:onoff:.0</pre><br />
Hier wird der HourCounter CN.TEST definiert.<br />
Ein MAX-Fensterkontakt mit Namen SHUTTER.JOHN wird als Ereignis-Geber verwendet.<br />
Das Reading "onoff" wird als Trigger für unserem Zähler genutzt.<br />
Bei den Fensterkontakten sehen diese Ereignisse wie folgt aus:<br />
<pre><br />
2013-11-15 23:19:12 MAX SHUTTER.JOHN onoff: 1<br />
....<br />
2013-11-15 23:19:24 MAX SHUTTER.JOHN onoff: 0<br />
</pre><br />
<br />
Soll ein Dummy als Ereignis-Geber verwendet werden, lautet die Definition wie folgt:<br />
<pre> define CN.Test HourCounter myDummy:1 myDummy:0</pre><br />
<br />
Die neue Instanz weist folgende Struktur auf:<br />
<br />
<pre><br />
Internals:<br />
CFGFN <br />
DEF SHUTTER.JOHN:onoff:.1 SHUTTER.JOHN:onoff:.0<br />
NAME CN.Test<br />
NR 738<br />
NTFY_ORDER 50-CN.Test<br />
STATE 1<br />
TYPE HourCounter<br />
Readings:<br />
2014-02-04 20:59:22 clearDate 2014-02-04 20:59:22<br />
2014-02-04 20:59:57 countsOverall 1<br />
2014-02-04 20:59:57 countsPerDay 1<br />
2014-02-04 20:59:57 pauseTimeIncrement 35<br />
2014-02-04 20:59:57 pauseTimeOverall 35<br />
2014-02-04 20:59:57 pauseTimePerDay 35<br />
2014-02-04 21:00:01 pulseTimeIncrement 4<br />
2014-02-04 21:00:01 pulseTimeOverall 4<br />
2014-02-04 21:00:01 pulseTimePerDay 4<br />
2014-02-04 20:59:57 state 1<br />
2014-02-04 21:00:00 tickHour 1<br />
2014-02-04 21:00:01 value 0<br />
Helper:<br />
OFF_Regexp SHUTTER.JOHN:onoff:.0<br />
ON_Regexp SHUTTER.JOHN:onoff:.1<br />
calledByEvent <br />
changedTimestamp 2014-02-04 21:00:01<br />
forceClear <br />
forceDayChange <br />
forceHourChange <br />
forceMonthChange <br />
forceWeekChange <br />
isFirstRun <br />
sdRoundHourLast 1391544000<br />
value 0<br />
cmdQueue:<br />
</pre><br />
<br />
Damit nicht zu viele Ereignisse in den Log-Dateien landen, kann man diese sinnvoll einschränken, so daß<br />
nur Änderungen das Feuern von Events auslösen<br />
<pre><br />
attr CN.BRENNER event-on-change-reading .*<br />
</pre><br />
Wenn sich nun jedoch über Stunden und Tage nichts ändert, sieht man in den Charts keine Daten mehr.<br />
Mit dieser Anweisung wird erreicht, daß alle Readings nach Aktualisierung spätesten nach 1 Stunden einen Event feuern, auch wenn sich der Wert nicht ändert.<br />
Eine Ausnahme hiervon sollen machen die tick*-Readings, deren Events sollen immer sofort gefeuert werden, <br />
wenn sie aktualisiert werden.<br />
<pre><br />
attr CN.BRENNER event-min-interval tick.*:0,.*:3600<br />
</pre><br />
<br />
== Readings ==<br />
{| class="wikitable sortable"<br />
|-<br />
! Reading !! class="unsortable" | Beschreibung <br />
|-<br />
| clearDate || Datum, zu dem alle kumulativen Readings über set .. clear gelöscht wurden<br />
|-<br />
| countsOverall || Absolutzähler für das Auftreten des ON-Ereignisses<br />
|-<br />
| countsPerDay || Tageszähler für das Auftreten des ON-Ereignisses<br />
|-<br />
| pauseTimeIncrement || Zeitdauer der Pausen-Phase in Sekunden ; wird zyklisch aktualisiert<br />
|-<br />
| pauseTimeEdge || Zeitdauer der letzten komplettierten Pausen-Phase<br />
|-<br />
| pauseTimeOverall || Zeitdauer in Sekunden über alle aufgetretenen Pause-Phasen<br />
|-<br />
| pauseTimePerDay || Zeitdauer in Sekunden über alle aufgetretenen Pause-Phasen des akt. Tages<br />
|-<br />
| pulseTimeIncrement || Zeitdauer der Puls-Phase in Sekunden ; wird zyklisch aktualisiert<br />
|-<br />
| pulseTimeEdge || Zeitdauer der letzten komplettierten Pulse-Phase<br />
|-<br />
| pulseTimeOverall || Zeitdauer in Sekunden über alle aufgetretenen Puls-Phasen<br />
|-<br />
| pulseTimePerDay || Zeitdauer in Sekunden über alle aufgetretenen Puls-Phasen des akt. Tages<br />
|-<br />
| value || Aktueller Schaltzustand gemäss ON/OFF Ereignis,<br /><br />
mit 1=letztes Ereignis war ON-Ereignis <br /><br />
und 0=letztes Ereignis war OFF-Ereignis<br />
|-<br />
| tickUpdated || Event wird gefeuert, wenn die operativen Readings beschrieben worden sind (nicht unbedingt gändert)<br />
|-<br />
| tickChanged || Event wird nach Änderung von value gefeuert<br />
|-<br />
| tickDay || Event wird nach Tageswechsel gefeuert bevor die Tageszähler resettiert werden<br />
|-<br />
| tickHour || Event wird nach Stundenwechsel gefeuert<br />
|-<br />
| tickWeek || Event wird nach Wochenwechsel gefeuert<br />
|-<br />
| tickMonth || Event wird nach Monatswechsel gefeuert<br />
|-<br />
| tickYear || Event wird nach Jahreswechsel gefeuert<br />
|-<br />
| forceHourChange || simuliert einen Stundenwechsel<br />
|-<br />
| forceDayChange || simuliert einen Tageswechsel<br />
|-<br />
| forceWeekChange || simuliert einen Wochenwechsel<br />
|-<br />
| forceMonthChange || simuliert einen Monatswechsel<br />
|-<br />
| forceYearChange || simuliert einen Jahreswechsel<br />
|}<br />
<br />
== Web-Oberfläche ==<br />
[[Datei:13_11_15_HourCounter_Face.png|HourCounter]]<br />
<br />
== Anwendung ==<br />
Nachfolgende Darstellung zeigt das Einschaltverhalten eines Heizungskessels zusammen mit den <br />
abgeleiteten Werten.<br />
<br />
[[Datei:13_11_15_HourCounter_Chart.png]]<br />
<br />
* die Kurve "Brenner EIN" zeigt die Trigger-Signale des ON/OFF Filters, also das Ein-/Ausschalten des Brenners<br />
* die Kurve "Brenner-Starts" zeigt die über den Tag aufgelaufenen Starts, also chronologisch das Anwachsen von Reading countsPerDay<br />
* die Kurve "Betriebsstunden" zeigt die aufgelaufene Zeit aus dem Reading pulseTimePerDay umgerechnet zu Stunden<br />
* die Kurve "Dauer" zeigt die Dauer des letzten Pulses in Sekunden<br />
* die Kurve Auslastung zeigt das Verhältnis des Readings pulseTimePerDay zur seit Tagesbeginn vergangenen Zeit.<br />
<br />
=== Chart der Aktualwerte ===<br />
Wir benötigen hierzu ein File-Archiv für die aufgelaufenen Daten.<br />
<pre>define CN.Test.File FileLog ./log/CN.Test-%Y.log (CN\.Test:.*)</pre><br />
Man erhält nach den ersten Ereignissen Einträge in folgender Form:<br />
<pre><br />
2013-11-16_12:45:40 CN.Test value: 1<br />
2013-11-16_12:45:40 CN.Test 1<br />
2013-11-16_12:46:21 CN.Test pulseTimeIncrement: 41 <br />
2013-11-16_12:46:21 CN.Test pulseTimePerDay: 41<br />
2013-11-16_12:46:21 CN.Test pulseTimeOverall: 41<br />
2013-11-16_12:46:21 CN.Test value: 0<br />
2013-11-16_12:50:38 CN.Test countsPerDay: 2<br />
2013-11-16_12:50:38 CN.Test countsOverall: 2<br />
2013-11-16_12:50:38 CN.Test pauseTimeIncrement: 257<br />
2013-11-16_12:50:38 CN.Test pauseTimePerDay: 756<br />
2013-11-16_12:50:38 CN.Test pauseTimeOverall: 756<br />
2013-11-16_12:50:38 CN.Test value: 1<br />
2013-11-16_12:50:38 CN.Test 2<br />
</pre><br />
<br />
Nun kann man den Chart definieren:<br />
[[Datei:13_11_16_HourCounter_ChartBuild_01.png]]<br />
<br />
Für die Kurve "Brenner EIN" verwenden wir CN.Test.value. Damit diese als unterste Kurve dargestellt wird transformieren wir den Wert 1 auf -2 und alle anderen (also die 0) auf -21 mit folgender Funktion:<br />
<pre>$fld[3]=~"1"?-2:-19</pre><br />
Die "Brenner Starts" können wir direkt von countsPerDay ableiten.<br /><br /><br />
Für die "Betriebsstunden" verwenden wir pulseTimePerDay. Da diese in Sekunden vorliegen teilen wir den Wert durch 3600, um Stunden zu erhalten.<br />
<pre>$fld[3]/=3600</pre><br />
Als letzten versorgen wir noch die Kurve "Dauer" mit pulseTimeIncrement. Da wir diese in Minuten haben wollen ist ebenfalls eine Umformung nötig.<br />
<pre>$fld[3]/=60</pre><br />
<br />
Somit sind die Basis-Kurven angelegt.<br />
<br />
=== Erweiterungen ===<br />
Es wurden im Forum viele Wünsche formuliert, weitere Funktionalitäten für den HourCounter einzuführen.<br />
<br />
* Aggregation über bestimmte oder ganz freie Zeiträume<br />
* komplexe Berechnungen, die zum Verbrauch führen<br />
* Zuordnung von Verbräuchen zu unterschiedlichen Countern nach bestimmten Bedingungen<br />
<br />
Vor allem die Aggregation erfasster Werte in Stunden-, Tages-, Wochen- und Monatswerten ist eine sinnvolle<br />
Erweiterung bei der Verbrauchserfassung.<br />
<br />
HourCounter bietet Schnittstellen an, die es ermöglichen, das Modul selbst mit neuen Eigenschaften zu erweitern.<br />
<br />
Die Referenz-Implementierung in 99_UtilsHourCounter.pm zeigt, wie dies skript-technisch zu realisieren ist.<br />
<br />
==== Installation ====<br />
Die jeweils aktuelle Version von 99_UtilsHourCounter kann über diesen <br />
[http://sourceforge.net/p/fhem/code/HEAD/tree/trunk/fhem/contrib/99_UtilsHourCounter.pm?format=raw Link] bezogen werden.<br />
<br />
==== Readings ====<br />
99_UtilsHourCounter erweitert den HourCounter um folgende Funktionen:<br />
{| class="wikitable sortable"<br />
|-<br />
! Reading !! class="unsortable" | Beschreibung<br />
|-<br />
| appCountsPerHour || Stundenzähler, wird bei Stundenwechsel aktualisiert<br />
|-<br />
| appCountsPerHourTemp || Arbeitszähler zu appCountsPerHour<br />
|-<br />
| appCountsPerDay || Tageszähler, wird bei Tageswechsel aktualisiert (Arbeitszähler ist countsPerDay)<br />
|-<br />
| appCountsPerWeek || Wochenzähler, wird bei Wochenwechsel aktualisiert<br />
|-<br />
| appCountsPerWeekTemp || Arbeitszähler zu appCountsPerWeek<br />
|-<br />
| appCountsPerMonth || Monatszähler, wird bei Monatswechsel aktualisiert<br />
|-<br />
| appCountsPerMonthTemp || Arbeitszähler zu appCountsPerMonth<br />
|-<br />
| appCountsPerYear || Jahreszähler, wird bei Jahreswechsel aktualisiert<br />
|-<br />
| appCountsPerYearTemp || Arbeitszähler zu appCountsPerYear<br />
|-<br />
| appOpHoursPerDay || Betriebsstunden des Tages<br />
|-<br />
| appOpHoursPerDayTemp || Arbeitszähler zu appOpHoursPerDay<br />
|-<br />
| appOpHoursPerWeek || Betriebsstunden der Woche<br />
|-<br />
| appOpHoursPerWeekTemp || Arbeitszähler zu appOpHoursPerWeek<br />
|-<br />
| appOpHoursPerMonth || Betriebsstunden des Monats<br />
|-<br />
| appOpHoursPerMonthTemp || Arbeitszähler appOpHoursPerMonth<br />
|-<br />
| appOpHoursPerYear || Betriebsstunden des Jahres<br />
|-<br />
| appOpHoursPerYearTemp || Arbeitszähler appOpHoursPerYear<br />
|-<br />
| appUtilization || Auslastung = pulseTimePerDay /(vergangene Sekunden seit Tagesbeginn) * 100<br />
|-<br />
| appUtilizationTemp || Arbeitsvariable zu appUtilization<br />
|}<br />
Beginn der Woche ist jeweils der Sonntag.<br /><br />
<br />
Mit folgender Anweisung aktivieren wir die Erweiterungen: <br />
:<code><br />
define CN.EVENT notify CN\..*:tick.* { appHCNotify("%NAME","%EVTPART0","%EVTPART1");;}<br />
</code><br />
<br />
Spätestens nach einer steigenden und einer fallenden Flanke sind die zuvor genannten app*-Readings zu sehen.<br />
{{Randnotiz|RNTyp=Info|RNText=Die gezeigten define-Anweisungen müssen jeweils in einer Zeile stehen (keine Zeilenumbrüche!).}}<br />
<br />
Die neuen Readings werden automatisch in den "Setter" der Web-Oberflächen aufgenommen. Dies gilt für alle Readings, die mit "app" beginnen.<br />
<br />
Somit können die neuen Readings beliebig manipuliert werden.<br />
<br />
==== Archiv für Tages-/Wochen-/Monats-/Jahreswerte anlegen ====<br />
Nun wollen wir die aggregierten Werte in eine eigene Datei speichern. Dies gelingt mit <br />
:<code>define CN.Test.FileDay FileLog ./log/CN.Test-Day-%Y.log CN.Test:app\w+ (Utilization|PerHour|PerDay|PerWeek|PerMonth|PerYear)(?!Temp).* </code><br />
<br />
<br />
Im Klartext:<br />
* verwende alle Werte des Counters CN.Test, deren Reading mit "app" beginnt<br />
* und die einen der Terme appUtilization|PerHour|PerDay|PerWeek|PerMonth|PerYear beinhalten<br />
* und die danach nicht dem Term "Temp" beinhalten<br />
<br />
== Fragen und Antworten ==<br />
==== Betriebsstundenzähler über Leistungsmessung ableiten ====<br />
'''Frage:'''<br />
Ich würde gerne zählen, wenn ich mehr Strom als Standy verbrauche (also mehr als 2Watt)<br />
und keine Betriebsstunden zählen, wenn der Verbrauch unter 2 Watt ist. Ist das möglich?<br />
<br />
<u>Beispiel für die Events</u><br />
<pre><br />
013-11-18_19:40:32 XXX power: 1.9<br />
2013-11-18_19:40:32 XXX consumption: 2<br />
2013-11-18_19:40:32 XXX consumptionTotal: 2<br />
2013-11-18_19:40:36 XXX power: 27<br />
2013-11-18_19:40:36 XXX consumption: 2<br />
2013-11-18_19:40:36 XXX consumptionTotal: 2<br />
2013-11-18_19:40:42 XXX power: 34.6<br />
2013-11-18_19:40:42 XXX consumption: 2 <br />
</pre><br />
<br />
'''Antwort'''<br />
<pre><br />
define CN.Test HourCounter XXX:power:\s[0-9]{2,}(\.[0-9]{1,3})*$ XXX:power:\s[0-9]{1}(\.[0-9]{1,3})*$<br />
</pre><br />
Erläuterung zu <regexp_for_ON> = XXX:power:\s[0-9]{2,}(\.[0-9]{1,3})*$<br />
* "XXX" bezeichnet das Device, der Term danach ist der regexp-Filte für das On-Ereignis<br />
* "power:" das Ereignis muss mit diesem Term beginnen<br />
* "\s" es muss ein Leerzeichen folgen<br />
* "[0-9]{2,}" es müssen mindestens 2 Ziffern folgen<br />
* "(\.[0-9]{1,3})*" wenn ein Punkt folgt, dann müssen auf diesen mindestens 1..3 Ziffern folgen<br />
* "$" danach darf kein weiteres Zeichen mehr folgen<br />
<br />
==== Welche Anwendungsfälle sind denkbar ? ====<br />
[http://forum.fhem.de/index.php/topic,12216.msg175163.html#msg175163 Aus dem Forum]<br />
* Betriebsstundenzähler für meine "Fliegenkiller-Steckdose"<br />
* Nutzungsdauer beschränken für TV,Internet oder Spielkonsolen für entnervte Eltern<br />
* Nutzungsdauer ermitteln zur Energieeinsparung (Klimageräte, Ventilatoren, Dunstabzugshauben etc.)<br />
* Lüftungsverhalten ermitteln (wie lange Fenster pro Tag geöffnet)<br />
<br />
[http://forum.fhem.de/index.php/topic,12216.msg195358.html#msg195358 Brenner Starts/Verbrauch + akkumulierte Werte]<br />
<br />
[http://forum.fhem.de/index.php/topic,12216.msg196358.html#msg196358 Ölverbrauch+Solar-Ladung]<br />
<br />
[http://voizchat.de/gaszaehler-verbrauch-erfassen-mit-fhem-und-raspberry-gpio/ Gaszähler mit HourCounter realisieren]<br />
==== Seltene Schaltvorgänge ====<br />
Die Schaltvorgänge sind über den Tag sehr wenige. Die Aktualisierung erfolgt immer erst<br />
bei der negativen Flanke. Wie kann man eine häufigere Aktualisierung erreichen ?<br />
<br />
'''Antwort'''<br />
<br />
Ab Version 1.0.0.6 ist wurde das Attribut "interval" eingeführt; es ist auf 60 Minuten voreingestellt und kann von 5..60 im 5 Minuten-Raster festgelegt werden.<br />
Es bestimmt, nach welcher Zeit Puls-/Pausendauer aktualisiert werden sollen, unabhängig vom Auftreten einer Schaltflanke.<br />
<br />
<br />
[[Kategorie:MAX]]<br />
[[Kategorie:HOWTOS]]</div>Johnhttp://wiki.fhem.de/w/index.php?title=HourCounter&diff=8789HourCounter2014-12-09T23:10:43Z<p>John: /* Readings */</p>
<hr />
<div>{{Infobox Modul<br />
|ModPurpose=HourCounter dient zum Zählen von Ereignissen und zur Erfassung von Betriebs-/Ruhe-Zeiten<br />
|ModType=h<br />
<!-- |ModCmdRef=LightScene -- nicht erforderlich, da Modultyp x --><br />
|ModForumArea=MAX<br />
|ModTechName=98_HourCounter.pm<br />
|ModOwner=John ([http://forum.fhem.de/index.php?action=profile;u=806 Forum] / [[Benutzer Diskussion:John|Wiki]])}}<br />
<br />
<br />
[[HourCounter]] ist ein Perl-Modul, das die Anzahl von Ereignissen erfasst. Bei bipolaren Ereignissen wird zusätzlich die Puls- sowie die Pausendauer ermittelt. Im vorliegenden Beispiel wird ein Betriebsstundenzähler mit einem MAX-Fensterkontakt realisiert.<br />
<br />
== Features ==<br />
* Ermittlung von Betriebsstunden, Auslastung, Verbräuchen, Schalthäufigkeiten<br />
* Ermittlung der Häufigkeit, Puls- Pausendauer pro Tag<br />
* Ermittlung der Puls-/Pausendauer der letzten Schaltperiode<br />
* Bereitstellung von Ereignissen zur Fortführung der Kumulation für Tages-, Wochen- und Monatswerte<br />
* unterstützende Funktionen zur Ablage von Tages-, Wochen- und Monatswerten<br />
<br />
== Zielsetzung des WIKI-Artikels ==<br />
Erläuterung der Funktionalität zur weiterführenden Diskussion im [http://forum.fhem.de/index.php/topic,12216.msg72596.html#msg72596 Forum].<br />
<br />
== Aktuelle Version ==<br />
Das Modul ist seit dem 24.10.2014 Bestandteil von FHEM.<br />
<br />
== Definition ==<br />
=== Abstrakt ===<br />
<pre>define <name> HourCounter <regexp_for_ON> [<regexp_for_Off>]</pre><br />
<br />
<regexp_for_ON> ist ein regulärer Ausdruck der das Ereignis beschreibt.<br />
<br />
Wenn auch [<regexp_for_Off>] definiert ist, so sprechen wir von einem bipolarem Ereignis, das einen <br />
EIN- sowie einen AUS-Zustand aufweist.<br />
<br />
<regexp_for_ON> beschreibt in diesem Fall die positive Flanke,[<regexp_for_Off>] die negative Flanke. Die Struktur des regexp-Ausdruckes ist analog zu jener beim Notify aufgebaut.<br />
<br />
===Konkret===<br />
<pre>define CN.Test HourCounter SHUTTER.JOHN:onoff:.1 SHUTTER.JOHN:onoff:.0</pre><br />
Hier wird der HourCounter CN.TEST definiert.<br />
Ein MAX-Fensterkontakt mit Namen SHUTTER.JOHN wird als Ereignis-Geber verwendet.<br />
Das Reading "onoff" wird als Trigger für unserem Zähler genutzt.<br />
Bei den Fensterkontakten sehen diese Ereignisse wie folgt aus:<br />
<pre><br />
2013-11-15 23:19:12 MAX SHUTTER.JOHN onoff: 1<br />
....<br />
2013-11-15 23:19:24 MAX SHUTTER.JOHN onoff: 0<br />
</pre><br />
<br />
Soll ein Dummy als Ereignis-Geber verwendet werden, lautet die Definition wie folgt:<br />
<pre> define CN.Test HourCounter myDummy:1 myDummy:0</pre><br />
<br />
Die neue Instanz weist folgende Struktur auf:<br />
<br />
<pre><br />
Internals:<br />
CFGFN <br />
DEF SHUTTER.JOHN:onoff:.1 SHUTTER.JOHN:onoff:.0<br />
NAME CN.Test<br />
NR 738<br />
NTFY_ORDER 50-CN.Test<br />
STATE 1<br />
TYPE HourCounter<br />
Readings:<br />
2014-02-04 20:59:22 clearDate 2014-02-04 20:59:22<br />
2014-02-04 20:59:57 countsOverall 1<br />
2014-02-04 20:59:57 countsPerDay 1<br />
2014-02-04 20:59:57 pauseTimeIncrement 35<br />
2014-02-04 20:59:57 pauseTimeOverall 35<br />
2014-02-04 20:59:57 pauseTimePerDay 35<br />
2014-02-04 21:00:01 pulseTimeIncrement 4<br />
2014-02-04 21:00:01 pulseTimeOverall 4<br />
2014-02-04 21:00:01 pulseTimePerDay 4<br />
2014-02-04 20:59:57 state 1<br />
2014-02-04 21:00:00 tickHour 1<br />
2014-02-04 21:00:01 value 0<br />
Helper:<br />
OFF_Regexp SHUTTER.JOHN:onoff:.0<br />
ON_Regexp SHUTTER.JOHN:onoff:.1<br />
calledByEvent <br />
changedTimestamp 2014-02-04 21:00:01<br />
forceClear <br />
forceDayChange <br />
forceHourChange <br />
forceMonthChange <br />
forceWeekChange <br />
isFirstRun <br />
sdRoundHourLast 1391544000<br />
value 0<br />
cmdQueue:<br />
</pre><br />
<br />
== Readings ==<br />
{| class="wikitable sortable"<br />
|-<br />
! Reading !! class="unsortable" | Beschreibung <br />
|-<br />
| clearDate || Datum, zu dem alle kumulativen Readings über set .. clear gelöscht wurden<br />
|-<br />
| countsOverall || Absolutzähler für das Auftreten des ON-Ereignisses<br />
|-<br />
| countsPerDay || Tageszähler für das Auftreten des ON-Ereignisses<br />
|-<br />
| pauseTimeIncrement || Zeitdauer der Pausen-Phase in Sekunden ; wird zyklisch aktualisiert<br />
|-<br />
| pauseTimeEdge || Zeitdauer der letzten komplettierten Pausen-Phase<br />
|-<br />
| pauseTimeOverall || Zeitdauer in Sekunden über alle aufgetretenen Pause-Phasen<br />
|-<br />
| pauseTimePerDay || Zeitdauer in Sekunden über alle aufgetretenen Pause-Phasen des akt. Tages<br />
|-<br />
| pulseTimeIncrement || Zeitdauer der Puls-Phase in Sekunden ; wird zyklisch aktualisiert<br />
|-<br />
| pulseTimeEdge || Zeitdauer der letzten komplettierten Pulse-Phase<br />
|-<br />
| pulseTimeOverall || Zeitdauer in Sekunden über alle aufgetretenen Puls-Phasen<br />
|-<br />
| pulseTimePerDay || Zeitdauer in Sekunden über alle aufgetretenen Puls-Phasen des akt. Tages<br />
|-<br />
| value || Aktueller Schaltzustand gemäss ON/OFF Ereignis,<br /><br />
mit 1=letztes Ereignis war ON-Ereignis <br /><br />
und 0=letztes Ereignis war OFF-Ereignis<br />
|-<br />
| tickUpdated || Event wird gefeuert, wenn die operativen Readings beschrieben worden sind (nicht unbedingt gändert)<br />
|-<br />
| tickChanged || Event wird nach Änderung von value gefeuert<br />
|-<br />
| tickDay || Event wird nach Tageswechsel gefeuert bevor die Tageszähler resettiert werden<br />
|-<br />
| tickHour || Event wird nach Stundenwechsel gefeuert<br />
|-<br />
| tickWeek || Event wird nach Wochenwechsel gefeuert<br />
|-<br />
| tickMonth || Event wird nach Monatswechsel gefeuert<br />
|-<br />
| tickYear || Event wird nach Jahreswechsel gefeuert<br />
|-<br />
| forceHourChange || simuliert einen Stundenwechsel<br />
|-<br />
| forceDayChange || simuliert einen Tageswechsel<br />
|-<br />
| forceWeekChange || simuliert einen Wochenwechsel<br />
|-<br />
| forceMonthChange || simuliert einen Monatswechsel<br />
|-<br />
| forceYearChange || simuliert einen Jahreswechsel<br />
|}<br />
<br />
== Web-Oberfläche ==<br />
[[Datei:13_11_15_HourCounter_Face.png|HourCounter]]<br />
<br />
== Anwendung ==<br />
Nachfolgende Darstellung zeigt das Einschaltverhalten eines Heizungskessels zusammen mit den <br />
abgeleiteten Werten.<br />
<br />
[[Datei:13_11_15_HourCounter_Chart.png]]<br />
<br />
* die Kurve "Brenner EIN" zeigt die Trigger-Signale des ON/OFF Filters, also das Ein-/Ausschalten des Brenners<br />
* die Kurve "Brenner-Starts" zeigt die über den Tag aufgelaufenen Starts, also chronologisch das Anwachsen von Reading countsPerDay<br />
* die Kurve "Betriebsstunden" zeigt die aufgelaufene Zeit aus dem Reading pulseTimePerDay umgerechnet zu Stunden<br />
* die Kurve "Dauer" zeigt die Dauer des letzten Pulses in Sekunden<br />
* die Kurve Auslastung zeigt das Verhältnis des Readings pulseTimePerDay zur seit Tagesbeginn vergangenen Zeit.<br />
<br />
=== Chart der Aktualwerte ===<br />
Wir benötigen hierzu ein File-Archiv für die aufgelaufenen Daten.<br />
<pre>define CN.Test.File FileLog ./log/CN.Test-%Y.log (CN\.Test:.*)</pre><br />
Man erhält nach den ersten Ereignissen Einträge in folgender Form:<br />
<pre><br />
2013-11-16_12:45:40 CN.Test value: 1<br />
2013-11-16_12:45:40 CN.Test 1<br />
2013-11-16_12:46:21 CN.Test pulseTimeIncrement: 41 <br />
2013-11-16_12:46:21 CN.Test pulseTimePerDay: 41<br />
2013-11-16_12:46:21 CN.Test pulseTimeOverall: 41<br />
2013-11-16_12:46:21 CN.Test value: 0<br />
2013-11-16_12:50:38 CN.Test countsPerDay: 2<br />
2013-11-16_12:50:38 CN.Test countsOverall: 2<br />
2013-11-16_12:50:38 CN.Test pauseTimeIncrement: 257<br />
2013-11-16_12:50:38 CN.Test pauseTimePerDay: 756<br />
2013-11-16_12:50:38 CN.Test pauseTimeOverall: 756<br />
2013-11-16_12:50:38 CN.Test value: 1<br />
2013-11-16_12:50:38 CN.Test 2<br />
</pre><br />
<br />
Nun kann man den Chart definieren:<br />
[[Datei:13_11_16_HourCounter_ChartBuild_01.png]]<br />
<br />
Für die Kurve "Brenner EIN" verwenden wir CN.Test.value. Damit diese als unterste Kurve dargestellt wird transformieren wir den Wert 1 auf -2 und alle anderen (also die 0) auf -21 mit folgender Funktion:<br />
<pre>$fld[3]=~"1"?-2:-19</pre><br />
Die "Brenner Starts" können wir direkt von countsPerDay ableiten.<br /><br /><br />
Für die "Betriebsstunden" verwenden wir pulseTimePerDay. Da diese in Sekunden vorliegen teilen wir den Wert durch 3600, um Stunden zu erhalten.<br />
<pre>$fld[3]/=3600</pre><br />
Als letzten versorgen wir noch die Kurve "Dauer" mit pulseTimeIncrement. Da wir diese in Minuten haben wollen ist ebenfalls eine Umformung nötig.<br />
<pre>$fld[3]/=60</pre><br />
<br />
Somit sind die Basis-Kurven angelegt.<br />
<br />
=== Erweiterungen ===<br />
Es wurden im Forum viele Wünsche formuliert, weitere Funktionalitäten für den HourCounter einzuführen.<br />
<br />
* Aggregation über bestimmte oder ganz freie Zeiträume<br />
* komplexe Berechnungen, die zum Verbrauch führen<br />
* Zuordnung von Verbräuchen zu unterschiedlichen Countern nach bestimmten Bedingungen<br />
<br />
Vor allem die Aggregation erfasster Werte in Stunden-, Tages-, Wochen- und Monatswerten ist eine sinnvolle<br />
Erweiterung bei der Verbrauchserfassung.<br />
<br />
HourCounter bietet Schnittstellen an, die es ermöglichen, das Modul selbst mit neuen Eigenschaften zu erweitern.<br />
<br />
Die Referenz-Implementierung in 99_UtilsHourCounter.pm zeigt, wie dies skript-technisch zu realisieren ist.<br />
<br />
==== Installation ====<br />
Die jeweils aktuelle Version von 99_UtilsHourCounter kann über diesen <br />
[http://sourceforge.net/p/fhem/code/HEAD/tree/trunk/fhem/contrib/99_UtilsHourCounter.pm?format=raw Link] bezogen werden.<br />
<br />
==== Readings ====<br />
99_UtilsHourCounter erweitert den HourCounter um folgende Funktionen:<br />
{| class="wikitable sortable"<br />
|-<br />
! Reading !! class="unsortable" | Beschreibung<br />
|-<br />
| appCountsPerHour || Stundenzähler, wird bei Stundenwechsel aktualisiert<br />
|-<br />
| appCountsPerHourTemp || Arbeitszähler zu appCountsPerHour<br />
|-<br />
| appCountsPerDay || Tageszähler, wird bei Tageswechsel aktualisiert (Arbeitszähler ist countsPerDay)<br />
|-<br />
| appCountsPerWeek || Wochenzähler, wird bei Wochenwechsel aktualisiert<br />
|-<br />
| appCountsPerWeekTemp || Arbeitszähler zu appCountsPerWeek<br />
|-<br />
| appCountsPerMonth || Monatszähler, wird bei Monatswechsel aktualisiert<br />
|-<br />
| appCountsPerMonthTemp || Arbeitszähler zu appCountsPerMonth<br />
|-<br />
| appCountsPerYear || Jahreszähler, wird bei Jahreswechsel aktualisiert<br />
|-<br />
| appCountsPerYearTemp || Arbeitszähler zu appCountsPerYear<br />
|-<br />
| appOpHoursPerDay || Betriebsstunden des Tages<br />
|-<br />
| appOpHoursPerDayTemp || Arbeitszähler zu appOpHoursPerDay<br />
|-<br />
| appOpHoursPerWeek || Betriebsstunden der Woche<br />
|-<br />
| appOpHoursPerWeekTemp || Arbeitszähler zu appOpHoursPerWeek<br />
|-<br />
| appOpHoursPerMonth || Betriebsstunden des Monats<br />
|-<br />
| appOpHoursPerMonthTemp || Arbeitszähler appOpHoursPerMonth<br />
|-<br />
| appOpHoursPerYear || Betriebsstunden des Jahres<br />
|-<br />
| appOpHoursPerYearTemp || Arbeitszähler appOpHoursPerYear<br />
|-<br />
| appUtilization || Auslastung = pulseTimePerDay /(vergangene Sekunden seit Tagesbeginn) * 100<br />
|-<br />
| appUtilizationTemp || Arbeitsvariable zu appUtilization<br />
|}<br />
Beginn der Woche ist jeweils der Sonntag.<br /><br />
<br />
Mit folgender Anweisung aktivieren wir die Erweiterungen: <br />
:<code><br />
define CN.EVENT notify CN\..*:tick.* { appHCNotify("%NAME","%EVTPART0","%EVTPART1");;}<br />
</code><br />
<br />
Spätestens nach einer steigenden und einer fallenden Flanke sind die zuvor genannten app*-Readings zu sehen.<br />
{{Randnotiz|RNTyp=Info|RNText=Die gezeigten define-Anweisungen müssen jeweils in einer Zeile stehen (keine Zeilenumbrüche!).}}<br />
<br />
Die neuen Readings werden automatisch in den "Setter" der Web-Oberflächen aufgenommen. Dies gilt für alle Readings, die mit "app" beginnen.<br />
<br />
Somit können die neuen Readings beliebig manipuliert werden.<br />
<br />
==== Archiv für Tages-/Wochen-/Monats-/Jahreswerte anlegen ====<br />
Nun wollen wir die aggregierten Werte in eine eigene Datei speichern. Dies gelingt mit <br />
:<code>define CN.Test.FileDay FileLog ./log/CN.Test-Day-%Y.log CN.Test:app\w+ (Utilization|PerHour|PerDay|PerWeek|PerMonth|PerYear)(?!Temp).* </code><br />
<br />
<br />
Im Klartext:<br />
* verwende alle Werte des Counters CN.Test, deren Reading mit "app" beginnt<br />
* und die einen der Terme appUtilization|PerHour|PerDay|PerWeek|PerMonth|PerYear beinhalten<br />
* und die danach nicht dem Term "Temp" beinhalten<br />
<br />
== Fragen und Antworten ==<br />
==== Betriebsstundenzähler über Leistungsmessung ableiten ====<br />
'''Frage:'''<br />
Ich würde gerne zählen, wenn ich mehr Strom als Standy verbrauche (also mehr als 2Watt)<br />
und keine Betriebsstunden zählen, wenn der Verbrauch unter 2 Watt ist. Ist das möglich?<br />
<br />
<u>Beispiel für die Events</u><br />
<pre><br />
013-11-18_19:40:32 XXX power: 1.9<br />
2013-11-18_19:40:32 XXX consumption: 2<br />
2013-11-18_19:40:32 XXX consumptionTotal: 2<br />
2013-11-18_19:40:36 XXX power: 27<br />
2013-11-18_19:40:36 XXX consumption: 2<br />
2013-11-18_19:40:36 XXX consumptionTotal: 2<br />
2013-11-18_19:40:42 XXX power: 34.6<br />
2013-11-18_19:40:42 XXX consumption: 2 <br />
</pre><br />
<br />
'''Antwort'''<br />
<pre><br />
define CN.Test HourCounter XXX:power:\s[0-9]{2,}(\.[0-9]{1,3})*$ XXX:power:\s[0-9]{1}(\.[0-9]{1,3})*$<br />
</pre><br />
Erläuterung zu <regexp_for_ON> = XXX:power:\s[0-9]{2,}(\.[0-9]{1,3})*$<br />
* "XXX" bezeichnet das Device, der Term danach ist der regexp-Filte für das On-Ereignis<br />
* "power:" das Ereignis muss mit diesem Term beginnen<br />
* "\s" es muss ein Leerzeichen folgen<br />
* "[0-9]{2,}" es müssen mindestens 2 Ziffern folgen<br />
* "(\.[0-9]{1,3})*" wenn ein Punkt folgt, dann müssen auf diesen mindestens 1..3 Ziffern folgen<br />
* "$" danach darf kein weiteres Zeichen mehr folgen<br />
<br />
==== Welche Anwendungsfälle sind denkbar ? ====<br />
[http://forum.fhem.de/index.php/topic,12216.msg175163.html#msg175163 Aus dem Forum]<br />
* Betriebsstundenzähler für meine "Fliegenkiller-Steckdose"<br />
* Nutzungsdauer beschränken für TV,Internet oder Spielkonsolen für entnervte Eltern<br />
* Nutzungsdauer ermitteln zur Energieeinsparung (Klimageräte, Ventilatoren, Dunstabzugshauben etc.)<br />
* Lüftungsverhalten ermitteln (wie lange Fenster pro Tag geöffnet)<br />
<br />
[http://forum.fhem.de/index.php/topic,12216.msg195358.html#msg195358 Brenner Starts/Verbrauch + akkumulierte Werte]<br />
<br />
[http://forum.fhem.de/index.php/topic,12216.msg196358.html#msg196358 Ölverbrauch+Solar-Ladung]<br />
<br />
[http://voizchat.de/gaszaehler-verbrauch-erfassen-mit-fhem-und-raspberry-gpio/ Gaszähler mit HourCounter realisieren]<br />
==== Seltene Schaltvorgänge ====<br />
Die Schaltvorgänge sind über den Tag sehr wenige. Die Aktualisierung erfolgt immer erst<br />
bei der negativen Flanke. Wie kann man eine häufigere Aktualisierung erreichen ?<br />
<br />
'''Antwort'''<br />
<br />
Ab Version 1.0.0.6 ist wurde das Attribut "interval" eingeführt; es ist auf 60 Minuten voreingestellt und kann von 5..60 im 5 Minuten-Raster festgelegt werden.<br />
Es bestimmt, nach welcher Zeit Puls-/Pausendauer aktualisiert werden sollen, unabhängig vom Auftreten einer Schaltflanke.<br />
<br />
<br />
[[Kategorie:MAX]]<br />
[[Kategorie:HOWTOS]]</div>Johnhttp://wiki.fhem.de/w/index.php?title=HourCounter&diff=8788HourCounter2014-12-09T23:08:59Z<p>John: /* Readings erweitert*/</p>
<hr />
<div>{{Infobox Modul<br />
|ModPurpose=HourCounter dient zum Zählen von Ereignissen und zur Erfassung von Betriebs-/Ruhe-Zeiten<br />
|ModType=h<br />
<!-- |ModCmdRef=LightScene -- nicht erforderlich, da Modultyp x --><br />
|ModForumArea=MAX<br />
|ModTechName=98_HourCounter.pm<br />
|ModOwner=John ([http://forum.fhem.de/index.php?action=profile;u=806 Forum] / [[Benutzer Diskussion:John|Wiki]])}}<br />
<br />
<br />
[[HourCounter]] ist ein Perl-Modul, das die Anzahl von Ereignissen erfasst. Bei bipolaren Ereignissen wird zusätzlich die Puls- sowie die Pausendauer ermittelt. Im vorliegenden Beispiel wird ein Betriebsstundenzähler mit einem MAX-Fensterkontakt realisiert.<br />
<br />
== Features ==<br />
* Ermittlung von Betriebsstunden, Auslastung, Verbräuchen, Schalthäufigkeiten<br />
* Ermittlung der Häufigkeit, Puls- Pausendauer pro Tag<br />
* Ermittlung der Puls-/Pausendauer der letzten Schaltperiode<br />
* Bereitstellung von Ereignissen zur Fortführung der Kumulation für Tages-, Wochen- und Monatswerte<br />
* unterstützende Funktionen zur Ablage von Tages-, Wochen- und Monatswerten<br />
<br />
== Zielsetzung des WIKI-Artikels ==<br />
Erläuterung der Funktionalität zur weiterführenden Diskussion im [http://forum.fhem.de/index.php/topic,12216.msg72596.html#msg72596 Forum].<br />
<br />
== Aktuelle Version ==<br />
Das Modul ist seit dem 24.10.2014 Bestandteil von FHEM.<br />
<br />
== Definition ==<br />
=== Abstrakt ===<br />
<pre>define <name> HourCounter <regexp_for_ON> [<regexp_for_Off>]</pre><br />
<br />
<regexp_for_ON> ist ein regulärer Ausdruck der das Ereignis beschreibt.<br />
<br />
Wenn auch [<regexp_for_Off>] definiert ist, so sprechen wir von einem bipolarem Ereignis, das einen <br />
EIN- sowie einen AUS-Zustand aufweist.<br />
<br />
<regexp_for_ON> beschreibt in diesem Fall die positive Flanke,[<regexp_for_Off>] die negative Flanke. Die Struktur des regexp-Ausdruckes ist analog zu jener beim Notify aufgebaut.<br />
<br />
===Konkret===<br />
<pre>define CN.Test HourCounter SHUTTER.JOHN:onoff:.1 SHUTTER.JOHN:onoff:.0</pre><br />
Hier wird der HourCounter CN.TEST definiert.<br />
Ein MAX-Fensterkontakt mit Namen SHUTTER.JOHN wird als Ereignis-Geber verwendet.<br />
Das Reading "onoff" wird als Trigger für unserem Zähler genutzt.<br />
Bei den Fensterkontakten sehen diese Ereignisse wie folgt aus:<br />
<pre><br />
2013-11-15 23:19:12 MAX SHUTTER.JOHN onoff: 1<br />
....<br />
2013-11-15 23:19:24 MAX SHUTTER.JOHN onoff: 0<br />
</pre><br />
<br />
Soll ein Dummy als Ereignis-Geber verwendet werden, lautet die Definition wie folgt:<br />
<pre> define CN.Test HourCounter myDummy:1 myDummy:0</pre><br />
<br />
Die neue Instanz weist folgende Struktur auf:<br />
<br />
<pre><br />
Internals:<br />
CFGFN <br />
DEF SHUTTER.JOHN:onoff:.1 SHUTTER.JOHN:onoff:.0<br />
NAME CN.Test<br />
NR 738<br />
NTFY_ORDER 50-CN.Test<br />
STATE 1<br />
TYPE HourCounter<br />
Readings:<br />
2014-02-04 20:59:22 clearDate 2014-02-04 20:59:22<br />
2014-02-04 20:59:57 countsOverall 1<br />
2014-02-04 20:59:57 countsPerDay 1<br />
2014-02-04 20:59:57 pauseTimeIncrement 35<br />
2014-02-04 20:59:57 pauseTimeOverall 35<br />
2014-02-04 20:59:57 pauseTimePerDay 35<br />
2014-02-04 21:00:01 pulseTimeIncrement 4<br />
2014-02-04 21:00:01 pulseTimeOverall 4<br />
2014-02-04 21:00:01 pulseTimePerDay 4<br />
2014-02-04 20:59:57 state 1<br />
2014-02-04 21:00:00 tickHour 1<br />
2014-02-04 21:00:01 value 0<br />
Helper:<br />
OFF_Regexp SHUTTER.JOHN:onoff:.0<br />
ON_Regexp SHUTTER.JOHN:onoff:.1<br />
calledByEvent <br />
changedTimestamp 2014-02-04 21:00:01<br />
forceClear <br />
forceDayChange <br />
forceHourChange <br />
forceMonthChange <br />
forceWeekChange <br />
isFirstRun <br />
sdRoundHourLast 1391544000<br />
value 0<br />
cmdQueue:<br />
</pre><br />
<br />
== Readings ==<br />
{| class="wikitable sortable"<br />
|-<br />
! Reading !! class="unsortable" | Beschreibung <br />
|-<br />
| clearDate || Datum, zu dem alle kumulativen Readings über set .. clear gelöscht wurden<br />
|-<br />
| countsOverall || Absolutzähler für das Auftreten des ON-Ereignisses<br />
|-<br />
| countsPerDay || Tageszähler für das Auftreten des ON-Ereignisses<br />
|-<br />
| pauseTimeIncrement || Zeitdauer der Pausen-Phase in Sekunden ; wird zyklisch aktualisiert<br />
|-<br />
| pauseTimeEdge || Zeitdauer der letzten komplettierten Pausen-Phase<br />
|-<br />
| pauseTimeOverall || Zeitdauer in Sekunden über alle aufgetretenen Pause-Phasen<br />
|-<br />
| pauseTimePerDay || Zeitdauer in Sekunden über alle aufgetretenen Pause-Phasen des akt. Tages<br />
|-<br />
| pulseTimeIncrement || Zeitdauer der Puls-Phase in Sekunden ; wird zyklisch aktualisiert<br />
|-<br />
| pulseTimeEdge || Zeitdauer der letzten komplettierten Pulse-Phase<br />
|-<br />
| pulseTimeOverall || Zeitdauer in Sekunden über alle aufgetretenen Puls-Phasen<br />
|-<br />
| pulseTimePerDay || Zeitdauer in Sekunden über alle aufgetretenen Puls-Phasen des akt. Tages<br />
|-<br />
| value || Aktueller Schaltzustand gemäss ON/OFF Ereignis,<br /><br />
mit 1=letztes Ereignis war ON-Ereignis <br /><br />
und 0=letztes Ereignis war OFF-Ereignis<br />
|-<br />
| tickUpdated || Event wird gefeuert, wenn die operativen Readings beschrieben worden sind (nicht unbedingt gändert)<br />
|-<br />
| tickChanged || Event wird nach Änderung von value gefeuert<br />
|-<br />
| tickDay || Event wird nach Tageswechsel gefeuert bevor die Tageszähler resettiert werden<br />
|-<br />
| tickHour || Event wird nach Stundenwechsel gefeuert<br />
|-<br />
| tickWeek || Event wird nach Wochenwechsel gefeuert<br />
|-<br />
| tickMonth || Event wird nach Monatswechsel gefeuert<br />
|-<br />
| tickYear || Event wird nach Jahreswechsel gefeuert<br />
|-<br />
| forceHourChange || simuliert einen Stundenwechsel<br />
|-<br />
| forceDayChange || simuliert einen Tageswechsel<br />
|-<br />
| forceWeekChange || simuliert einen Wochenwechsel<br />
|-<br />
| forceMonthChange || simuliert einen Monatswechsel<br />
|-<br />
| forceYearChange || simuliert einen Jahreswechsel<br />
|}<br />
<br />
== Web-Oberfläche ==<br />
[[Datei:13_11_15_HourCounter_Face.png|HourCounter]]<br />
<br />
== Anwendung ==<br />
Nachfolgende Darstellung zeigt das Einschaltverhalten eines Heizungskessels zusammen mit den <br />
abgeleiteten Werten.<br />
<br />
[[Datei:13_11_15_HourCounter_Chart.png]]<br />
<br />
* die Kurve "Brenner EIN" zeigt die Trigger-Signale des ON/OFF Filters, also das Ein-/Ausschalten des Brenners<br />
* die Kurve "Brenner-Starts" zeigt die über den Tag aufgelaufenen Starts, also chronologisch das Anwachsen von Reading countsPerDay<br />
* die Kurve "Betriebsstunden" zeigt die aufgelaufene Zeit aus dem Reading pulseTimePerDay umgerechnet zu Stunden<br />
* die Kurve "Dauer" zeigt die Dauer des letzten Pulses in Sekunden<br />
* die Kurve Auslastung zeigt das Verhältnis des Readings pulseTimePerDay zur seit Tagesbeginn vergangenen Zeit.<br />
<br />
=== Chart der Aktualwerte ===<br />
Wir benötigen hierzu ein File-Archiv für die aufgelaufenen Daten.<br />
<pre>define CN.Test.File FileLog ./log/CN.Test-%Y.log (CN\.Test:.*)</pre><br />
Man erhält nach den ersten Ereignissen Einträge in folgender Form:<br />
<pre><br />
2013-11-16_12:45:40 CN.Test value: 1<br />
2013-11-16_12:45:40 CN.Test 1<br />
2013-11-16_12:46:21 CN.Test pulseTimeIncrement: 41 <br />
2013-11-16_12:46:21 CN.Test pulseTimePerDay: 41<br />
2013-11-16_12:46:21 CN.Test pulseTimeOverall: 41<br />
2013-11-16_12:46:21 CN.Test value: 0<br />
2013-11-16_12:50:38 CN.Test countsPerDay: 2<br />
2013-11-16_12:50:38 CN.Test countsOverall: 2<br />
2013-11-16_12:50:38 CN.Test pauseTimeIncrement: 257<br />
2013-11-16_12:50:38 CN.Test pauseTimePerDay: 756<br />
2013-11-16_12:50:38 CN.Test pauseTimeOverall: 756<br />
2013-11-16_12:50:38 CN.Test value: 1<br />
2013-11-16_12:50:38 CN.Test 2<br />
</pre><br />
<br />
Nun kann man den Chart definieren:<br />
[[Datei:13_11_16_HourCounter_ChartBuild_01.png]]<br />
<br />
Für die Kurve "Brenner EIN" verwenden wir CN.Test.value. Damit diese als unterste Kurve dargestellt wird transformieren wir den Wert 1 auf -2 und alle anderen (also die 0) auf -21 mit folgender Funktion:<br />
<pre>$fld[3]=~"1"?-2:-19</pre><br />
Die "Brenner Starts" können wir direkt von countsPerDay ableiten.<br /><br /><br />
Für die "Betriebsstunden" verwenden wir pulseTimePerDay. Da diese in Sekunden vorliegen teilen wir den Wert durch 3600, um Stunden zu erhalten.<br />
<pre>$fld[3]/=3600</pre><br />
Als letzten versorgen wir noch die Kurve "Dauer" mit pulseTimeIncrement. Da wir diese in Minuten haben wollen ist ebenfalls eine Umformung nötig.<br />
<pre>$fld[3]/=60</pre><br />
<br />
Somit sind die Basis-Kurven angelegt.<br />
<br />
=== Erweiterungen ===<br />
Es wurden im Forum viele Wünsche formuliert, weitere Funktionalitäten für den HourCounter einzuführen.<br />
<br />
* Aggregation über bestimmte oder ganz freie Zeiträume<br />
* komplexe Berechnungen, die zum Verbrauch führen<br />
* Zuordnung von Verbräuchen zu unterschiedlichen Countern nach bestimmten Bedingungen<br />
<br />
Vor allem die Aggregation erfasster Werte in Stunden-, Tages-, Wochen- und Monatswerten ist eine sinnvolle<br />
Erweiterung bei der Verbrauchserfassung.<br />
<br />
HourCounter bietet Schnittstellen an, die es ermöglichen, das Modul selbst mit neuen Eigenschaften zu erweitern.<br />
<br />
Die Referenz-Implementierung in 99_UtilsHourCounter.pm zeigt, wie dies skript-technisch zu realisieren ist.<br />
<br />
==== Installation ====<br />
Die jeweils aktuelle Version von 99_UtilsHourCounter kann über diesen <br />
[http://sourceforge.net/p/fhem/code/HEAD/tree/trunk/fhem/contrib/99_UtilsHourCounter.pm?format=raw Link] bezogen werden.<br />
<br />
==== Readings ====<br />
99_UtilsHourCounter erweitert den HourCounter um folgende Funktionen:<br />
{| class="wikitable sortable"<br />
|-<br />
! Reading !! class="unsortable" | Beschreibung<br />
|-<br />
| appCountsPerHour || Stundenzähler, wird bei Stundenwechsel aktualisiert<br />
|-<br />
| appCountsPerHourTemp || Arbeitszähler zu appCountsPerHour<br />
|-<br />
| appCountsPerDay || Tageszähler, wird bei Tageswechsel aktualisiert (Arbeitszähler ist countsPerDay)<br />
|-<br />
| appCountsPerWeek || Wochenzähler, wird bei Wochenwechsel aktualisiert<br />
|-<br />
| appCountsPerWeekTemp || Arbeitszähler zu appCountsPerWeek<br />
|-<br />
| appCountsPerMonth || Monatszähler, wird bei Monatswechsel aktualisiert<br />
|-<br />
| appCountsPerMonthTemp || Arbeitszähler zu appCountsPerMonth<br />
|-<br />
| appCountsPerYear || Jahreszähler, wird bei Jahreswechsel aktualisiert<br />
|-<br />
| appCountsPerYearTemp || Arbeitszähler zu appCountsPerYear<br />
|-<br />
| appOpHoursPerDay || Betriebsstunden des Tages<br />
|-<br />
| appOpHoursPerDayTemp || Arbeitszähler zu appOpHoursPerDay<br />
|-<br />
| appOpHoursPerWeek || Betriebsstunden der Woche<br />
|-<br />
| appOpHoursPerWeekTemp || Arbeitszähler zu appOpHoursPerWeek<br />
|-<br />
| appOpHoursPerMonth || Betriebsstunden des Monats<br />
|-<br />
| appOpHoursPerMonthTemp || Arbeitszähler appOpHoursPerMonth<br />
|-<br />
| appOpHoursPerYear || Betriebsstunden des Jahres<br />
|-<br />
| appOpHoursPerYearTemp || Arbeitszähler appOpHoursPerYear<br />
|-<br />
| appUtilization || Auslastung = pulseTimePerDay /(vergangene Sekunden seit Tagesbeginn) * 100<br />
|-<br />
| appUtilizationTemp || Arbeitsvariable zu appUtilization<br />
|}<br />
Beginn der Woche ist jeweils der Sonntag.<br /><br />
<br />
Mit folgender Anweisung aktivieren wir die Erweiterungen: <br />
:<code>define CN.Event notify CN.Test:(countsOverall:|value:|tickHour:|tickDay:|tickWeek:|tickMonth:|tickYear:).* {appHCNotify("%NAME","%EVTPART0","%EVTPART1");;}</code><br />
<br />
Spätestens nach einer steigenden und einer fallenden Flanke sind die zuvor genannten app*-Readings zu sehen.<br />
{{Randnotiz|RNTyp=Info|RNText=Die gezeigten define-Anweisungen müssen jeweils in einer Zeile stehen (keine Zeilenumbrüche!).}}<br />
<br />
Die neuen Readings werden automatisch in den "Setter" der Web-Oberflächen aufgenommen. Dies gilt für alle Readings, die mit "app" beginnen.<br />
<br />
Somit können die neuen Readings beliebig manipuliert werden.<br />
<br />
==== Archiv für Tages-/Wochen-/Monats-/Jahreswerte anlegen ====<br />
Nun wollen wir die aggregierten Werte in eine eigene Datei speichern. Dies gelingt mit <br />
:<code>define CN.Test.FileDay FileLog ./log/CN.Test-Day-%Y.log CN.Test:app\w+ (Utilization|PerHour|PerDay|PerWeek|PerMonth|PerYear)(?!Temp).* </code><br />
<br />
<br />
Im Klartext:<br />
* verwende alle Werte des Counters CN.Test, deren Reading mit "app" beginnt<br />
* und die einen der Terme appUtilization|PerHour|PerDay|PerWeek|PerMonth|PerYear beinhalten<br />
* und die danach nicht dem Term "Temp" beinhalten<br />
<br />
== Fragen und Antworten ==<br />
==== Betriebsstundenzähler über Leistungsmessung ableiten ====<br />
'''Frage:'''<br />
Ich würde gerne zählen, wenn ich mehr Strom als Standy verbrauche (also mehr als 2Watt)<br />
und keine Betriebsstunden zählen, wenn der Verbrauch unter 2 Watt ist. Ist das möglich?<br />
<br />
<u>Beispiel für die Events</u><br />
<pre><br />
013-11-18_19:40:32 XXX power: 1.9<br />
2013-11-18_19:40:32 XXX consumption: 2<br />
2013-11-18_19:40:32 XXX consumptionTotal: 2<br />
2013-11-18_19:40:36 XXX power: 27<br />
2013-11-18_19:40:36 XXX consumption: 2<br />
2013-11-18_19:40:36 XXX consumptionTotal: 2<br />
2013-11-18_19:40:42 XXX power: 34.6<br />
2013-11-18_19:40:42 XXX consumption: 2 <br />
</pre><br />
<br />
'''Antwort'''<br />
<pre><br />
define CN.Test HourCounter XXX:power:\s[0-9]{2,}(\.[0-9]{1,3})*$ XXX:power:\s[0-9]{1}(\.[0-9]{1,3})*$<br />
</pre><br />
Erläuterung zu <regexp_for_ON> = XXX:power:\s[0-9]{2,}(\.[0-9]{1,3})*$<br />
* "XXX" bezeichnet das Device, der Term danach ist der regexp-Filte für das On-Ereignis<br />
* "power:" das Ereignis muss mit diesem Term beginnen<br />
* "\s" es muss ein Leerzeichen folgen<br />
* "[0-9]{2,}" es müssen mindestens 2 Ziffern folgen<br />
* "(\.[0-9]{1,3})*" wenn ein Punkt folgt, dann müssen auf diesen mindestens 1..3 Ziffern folgen<br />
* "$" danach darf kein weiteres Zeichen mehr folgen<br />
<br />
==== Welche Anwendungsfälle sind denkbar ? ====<br />
[http://forum.fhem.de/index.php/topic,12216.msg175163.html#msg175163 Aus dem Forum]<br />
* Betriebsstundenzähler für meine "Fliegenkiller-Steckdose"<br />
* Nutzungsdauer beschränken für TV,Internet oder Spielkonsolen für entnervte Eltern<br />
* Nutzungsdauer ermitteln zur Energieeinsparung (Klimageräte, Ventilatoren, Dunstabzugshauben etc.)<br />
* Lüftungsverhalten ermitteln (wie lange Fenster pro Tag geöffnet)<br />
<br />
[http://forum.fhem.de/index.php/topic,12216.msg195358.html#msg195358 Brenner Starts/Verbrauch + akkumulierte Werte]<br />
<br />
[http://forum.fhem.de/index.php/topic,12216.msg196358.html#msg196358 Ölverbrauch+Solar-Ladung]<br />
<br />
[http://voizchat.de/gaszaehler-verbrauch-erfassen-mit-fhem-und-raspberry-gpio/ Gaszähler mit HourCounter realisieren]<br />
==== Seltene Schaltvorgänge ====<br />
Die Schaltvorgänge sind über den Tag sehr wenige. Die Aktualisierung erfolgt immer erst<br />
bei der negativen Flanke. Wie kann man eine häufigere Aktualisierung erreichen ?<br />
<br />
'''Antwort'''<br />
<br />
Ab Version 1.0.0.6 ist wurde das Attribut "interval" eingeführt; es ist auf 60 Minuten voreingestellt und kann von 5..60 im 5 Minuten-Raster festgelegt werden.<br />
Es bestimmt, nach welcher Zeit Puls-/Pausendauer aktualisiert werden sollen, unabhängig vom Auftreten einer Schaltflanke.<br />
<br />
<br />
[[Kategorie:MAX]]<br />
[[Kategorie:HOWTOS]]</div>Johnhttp://wiki.fhem.de/w/index.php?title=PID20_-_Der_PID-Regler&diff=8616PID20 - Der PID-Regler2014-11-29T11:16:57Z<p>John: /* Inbetriebnahme */</p>
<hr />
<div>'''PID20''' ist ein Modul, das nach dem P-I-D Algorithmus einen Regler realisiert.<br />
<br />
== Projekt-Status ==<br />
<br />
Das Modul ist seit dem 26.03.2014 Bestandteil von FHEM.<br />
<br />
== Features ==<br />
* einstellbarer Bewertungs-/Berechnungszyklus<br />
* Überwachung des Istwert-Gebers über dessen Zeitstempel (Sensorausfall)<br />
* Skalierbarkeit der Ausgabehäufigkeit an das Stellglied über Zeit und Mindeständerung<br />
* Zwangsausgabe an das Stellglied nach Ablauf eines einstellbaren Zeitintervalls<br />
* Notstellung des Stellgliedes, falls Istwert-Geber ausgefallen ist<br />
* Begrenzung des Stellbereichs nach oben und unten<br />
* Festlegung der Nachkommastellen (0..5) des Ausgabewertes zum Stellglied<br />
* Festlegen einer minimalen Regelabweichung, ab der der Regler aktiv wird<br />
* Festlegen des Reading-Namens für den Sollwert<br />
* Festlegen des Reading-Namens für den Istwert<br />
* Invertierung des Reglerwirksinns<br />
* Festlegen der minimalen Aktualisierungsrate der Readings<br />
* Festlegen der Proportionalitätskonstanten P,I,D<br />
== Thread im Forum ==<br />
[http://forum.fhem.de/index.php/topic,17067.msg111615.html#msg111615 Diskussion zu PID20 im Forum]<br />
<br />
=== Define ===<br />
<code><br />
define <name> PID20 sensor[:reading[:regexp]] actor:cmd <br />
</code><br />
<br />
=== Attribute ===<br />
{| class="wikitable sortable"<br />
|-<br />
! Parameter !! Wertebereich !! Default !! Beschreibung<br />
|-<br />
|pidActorValueDecPlaces||[0..5]||0||Anzahl der Nachkommastellen für Ausgabewert zu Aktor<br />
|-<br />
|pidActorInterval||uint||180||minimale Wartezeit in Sekunden, bis eine neue Ausgabe an das Stellglied erfolgen kann<br />
|-<br />
|pidActorThreshold||uint||1||Notwendige minimale Änderung zum Altwert der Stellgliedausgabe, damit diese erneut erfolgt<br />
|-<br />
|pidActorErrorAction||[freeze, errorPos]||freeze||legt das Verhalten der Ausgabe zum Stellglied fest, wenn der Istwert nicht innerhalb von <pidSensorTimeout> aktualisiert wurde (Sensor-Ausfall) <br /><br />
freeze: Position des Stellgliedes beibehalten<br /><br />
ErrorPos: Position anfahren, die unter Attribut <pidActorErrorPos> angegeben ist."<br />
|-<br />
|pidActorErrorPos||int||0||Diese Position ist einzunehmen, wenn pidActorErrorAction auf errorPos steht und der Istwert-Geber ausgefallen ist.<br />
|-<br />
|pidActorKeepAlive||uint||1800||Spätestens nach dieser Zeit erfolgt eine Zwangsausgabe an das Stellglied<br />
(wenn PID nicht disabled und nicht stopped)<br />
|-<br />
|pidActorLimitLower||float||0||untere Begrenzung für das Stellglied<br />
|-<br />
|pidActorLimitUpper||float||100||obere Begrenzung für das Stellglied<br />
|-<br />
|pidCalcInterval||uint||60||Berechnungszyklus in Sekunden, nach dem die PID-Berechnung durchgeführt wird.<br />
|-<br />
|pidDeltaTreshold||pos. float||0||wenn die Regeldifferenz(delta) kleiner als pidDeltaThreshold, dann wird der Regler eingefroren (state=idle)<br />
|-<br />
|pidDesiredName||string||desired||Name für das Reading, das den Sollwert für den Regler aufnehmen soll<br />
|-<br />
|pidMeasuredName||string||measured||Name für das Reading, das den Istwert für den Regler aufnehmen soll<br />
|-<br />
|pidSensorTimeout||uint||3600||Zeitlimit in Sekunden, nach dessen Überschreitung der Ausfall des Istwert-Gebers anzunehmen ist<br />
|-<br />
|pidReverseAction||[0,1]||0||Umgekehrter Wirksinn des Reglers<br />
|-<br />
|pidUpdateInterval||uint||300||Zeitlimit in Sekunden, nach der ein Zwangsupdate der Readings erfolgen muss (Kurvendarstellung).<br />
|-<br />
|pidFactor_P||pos. float||25||Proportionalitätskonstante für P-Anteil<br />
<br />
|-<br />
|pidFactor_I||pos. float||0.25||Proportionalitätskonstante für I-Anteil<br />
<br />
|-<br />
|pidFactor_D||pos. float||0||Proportionalitätskonstante für D-Anteil<br />
|-<br />
|disable||[0,1]||0||Freigabe/Sperren des Reglers<br />
|}<br />
<br />
=== Setter ===<br />
'''desired'''<br />
* Funktion: Sollwert einstellen<br />
* Name des Setters kann vom Anwender über das Attribute "pidDesiredName" definiert werden<br />
<br />
'''start'''<br />
* PID nimmt den Betrieb wieder auf, es werden P-, I- und D-Anteil vor dem Stop übernommen<br />
<br />
'''stop'''<br />
* PID geht in den Zustand stopped; alles wird praktisch eingefroren<br />
<br />
'''restart'''<br />
* arbeitet zunächst wie Start, jedoch gibt man an, mit welchen Prozentwert der Stellausgang anfangs stehen soll<br />
<br />
=== Readings ===<br />
[[Datei:13 10 20 Pid readings.png]]<br />
* actuation liefert den tatsächlichen Ausgabewert an das Stellglied<br />
* actuationCalc liefert den internen Rechenwert des Ausgabewertes für das Stellglied(ohne Begrenzung)<br />
* delta, die aktuelle Regeldifferenz<br />
* desired (Name ist variabel), der Sollwert<br />
* measured (Name ist variabel), der aktuelle Wert vom Istwert-geber<br />
* p_p, der P-Anteil des Ausgabewertes für das Stellglied<br />
* p_i, der I-Anteil des Ausgabewertes für das Stellglied<br />
* p_d, der D-Anteil des Ausgabewertes für das Stellglied<br />
* state, der Betriebszustand des Reglers<br />
<br />
'''delta'''<br />
<code><br />
delta = desired - measured (also Sollwert-Istwert)<br />
</code><br />
<br />
'''actuation'''<br />
<code><br />
actuation = actuationCalc<br />
</code><br />
jedoch begrenzt durch pidActorLimitLower und pidActorLimitUpper <br />
und formatiert via pidActorValueDecPlaces<br />
<br />
<br />
'''actuationCalc'''<br />
<br />
Der Ausgabewert für das Stellglied wird wie folgt berechnet<br />
<br />
<code><br />
actuationCalc = p_p + p_i + p_d<br />
</code><br />
<br />
'''state'''<br />
<br />
{| class="wikitable"<br />
|-<br />
! state !! Erläuterung<br />
|-<br />
| disabled || PID-Instanz ist inaktiv<br />
|-<br />
| initializing || Modul wurde initialisiert<br />
|-<br />
| idle || Berechnung ist inaktiv<br />
|-<br />
| processing || Berechnung ist aktiv, Normalbetrieb<br />
|-<br />
| alarm || Ausnahmezustand, z.B. Timout des Istwert-Gebers<br />
|}<br />
<br />
== Inbetriebnahme ==<br />
* PID20 definieren, hier mit HMS100TF als Istwert-Geber für die Temperatur und ein MAX-Thermostat als Stellglied; Auslegung für eine Fußbodenheizung (sehr träge)<br />
<pre>define PID.FUBO PID20 DG.BAD.TF:temperature HT.FUBO:maxValveSetting</pre><br />
:* <sensor> = "DG.BAD.TF": Name des Istwert-Geber s (HMS100TF)<br />
:* <reading> = "temperature": das Reading vom HMS100TF, das die Temperatur liefert<br />
:* <regexp> = nicht definiert, wir können also direkt den Wert des Readings verwenden<br />
:* <actor> = "HT.FUBO" : Name des MAX-Thermostats, das als Stellglied verwendet wird<br />
:* <cmd> = "maxValveSetting" : Das Kommando mit dem PID20 die Stellausgabe realisieren soll<br />
<br /><br />
Letztlich wird mit <actor> und <cmd> Folgendes ausgeführt<br />
<pre>set <actor> <cmd> <setting-value> </pre><br />
<br />
'''zusätzlich noch einige Attribute anpassen'''<br />
* die Ausgabehäufigkeit an das Stellglied auf 15 Minuten begrenzen<br />
<pre>attr PID.FUBO pidActorInterval 900</pre><br />
* nur dann einen Wert an das Stellglied ausgeben, wenn die Differenz zum Altwert >= 5% <br />
<pre>attr PID.FUBO pidActorTreshold 5</pre><br />
* Nachommastellen für das Stellglied festlegen; MAX-Thermostate erlauben nur Werte ohne Nachkommastellen<br />
<pre>attr PID.FUBO pidActorValueDecPlaces 0</pre><br />
* I-Faktor festlegen; Überlegung: bei einer Regelabweichung von 1 Grad, soll der I-Anteil um 0.2% pro Minute inkrementieren/dekrementieren <br />
<pre>attr PID.FUBO pidFactor_I 0.2</pre><br />
* P-Faktor festlegen; Überlegung:Bei einer Regel-Abweichung von 1 Grad, soll der P-Anteil +/-50% betragen<br />
<pre>attr PID.FUBO pidFactor_P 50</pre><br />
* Häufigkeit der Events begrenzen: Die Readings werden im Intervall von "pidCalcInterval" aktualisiert. Die damit erzeugten Events kann man mit den Standard-Mechanismen von FHEM begrenzen. Hier wird festgelegt, daß die Readings nur dann einen Event feuern, wenn diese sich tatsächlich ändern. Der Wert hinter dem Doppelpunkt, gibt die Mindeständerung an. Fehlt dieser feuert jede Änderung einen Event.<br />
<pre>attr PID.FUBO event-on-change-reading actuation:1,actuationCalc:0.5,delta:0.2,desired,measured:0.2,p_d:0.1,p_i:1.0,p_p:1.0</pre><br />
* Events feuern, wenn sich über lange Zeit eine Reading nicht ändert: Wenn sich z.B. desired über Stunden nicht ändert, so wird kein einziger Event gefeuert. Mit nachfolgender Einstellung erreicht man, dass ein Event auch dann erzeugt wird, wenn sich das Reading nach einer festgelegten Zeit nicht ändert.(sinnvoll für Charts, hier z.B. alle 30 Minuten).<br />
<pre>attr PID.FUBO event-min-interval actuation:1800,actuationCalc:1800,delta:1800,desired:1800,measured:1800,p_d:1800,p_i:1800,p_p:1800</pre><br />
<br />
'''Chart einrichten'''<br/><br />
Es ist für das Einstellen der Regel-Faktoren (P,I,D) überaus hilfreich, das Verhalten über die Zeit aufzuzeichnen, um das Verhalten objektiv beurteilen zu können.<br/><br />
<br />
;Zunächst ein Filelog einrichten<br/><br />
:define PID.FUBO.File FileLog ./log/PID.FUBO-%Y.log PID\.FUBO<br />
:attr PID.FUBO.File logtype text<br />
<br />
Danach ein Chart definieren, angelehnt an folgendem Beispiel:<br />
<br />
[[Datei:13_12_03_PID_ChartDef.png]]<br />
<br />
<br />
Anbei ein Vorschlag für au<br />
<br />
== Hintergrund-Informationen ==<br />
=== list <pid-name> ===<br />
<code><br />
Internals:<br />
DEF DG.BAD.TF PID.Actor:state<br />
NAME PID.PID<br />
NR 616<br />
NTFY_ORDER 50-PID.PID<br />
STATE processing<br />
TYPE PID<br />
Readings:<br />
2013-10-20 17:13:41 actuation 97<br />
2013-10-20 17:21:42 actuationCalc 97.2079999999999<br />
2013-10-20 17:21:42 delta 0.199999999999999<br />
2013-10-20 17:13:41 desired 22<br />
2013-10-20 17:13:41 measured 21.8<br />
2013-10-20 17:21:42 p_d 0<br />
2013-10-20 17:21:42 p_i 92.2079999999999<br />
2013-10-20 17:21:42 p_p 4.99999999999998<br />
2013-10-20 17:21:42 state processing<br />
Helper:<br />
actor PID.Actor<br />
actorCommand state<br />
actorErrorAction freeze<br />
actorErrorPos 0<br />
actorInterval 300<br />
actorKeepAlive 1800<br />
actorLimitLower 0<br />
actorLimitUpper 100<br />
actorThreshold 4<br />
actorTimestamp 2013-10-20 17:13:41<br />
actorValueDecPlaces 0<br />
calcInterval 60<br />
deltaGradient 0<br />
deltaOld 0.199999999999999<br />
deltaOldTS 2013-10-20 17:18:07<br />
deltaTreshold 0<br />
desiredName desired<br />
disable 0<br />
factor_D 0<br />
factor_I 0.25<br />
factor_P 25<br />
isWindUP 0<br />
measuredName measured<br />
reading temperature<br />
regexp ([\d\.]*)<br />
reverseAction 0<br />
sensor DG.BAD.TF<br />
sensorTimeout 3600<br />
updateInterval 600<br />
Attributes:<br />
pidActorInterval 300<br />
pidActorTreshold 4<br />
pidActorValueDecPlaces 0<br />
room PID<br />
verbose 4<br />
<br />
</code><br />
<br />
=== Anti-WindUp-Strategie ===<br />
Der integrale Anteil des PID-Reglers wird ohne Gegenmassnahmen auch dann weiter integriert,<br />
wenn das Stellglied bereits an seine Grenzen gestossen ist.<br />
Dies hat den Nachteil, dass nach einer Reduzierung der Regeldifferenz lange Wartezeiten entstehen können, bis das<br />
Stellglied reagiert.<br />
Dies nennt man den WindUP-Effekt.<br />
Hierzu wurde die folgende Strategie entwickelt:<br />
<br />
[[Datei:13 10 20 PID Windup.png|WindUP]]<br />
<br />
Sobald das rechnerische Stellsignal (Ventilstellung Calc=actuationCalc) die obere Grenze des Stellgliedes überschreitet (pidActorLimitUpper) oder die untere Grenze unterschreitet (pidActorLimitLower), wird die Integration des I-Anteils eingefroren.<br />
<br />
<br />
'''Am Beispiel:'''<br />
An Position L1 überschreitet der rechnerische Ausgabewert des Stellgliedes die obere Grenze (100%).<br />
Der I-Anteil verändert sich nicht mehr bis zur Position L2. Hier unterschreitet der Ausgabewert die <br />
obere Grenze, der I-Anteil kann wieder verändert werden.<br />
<br />
== Fragen und Antworten ==<br />
=== Temperatur im Raum steigt nicht oder stark verzögert, was kann ich tun ? ===<br />
<br />
==== 1.Fehlerquelle : Heizsystem ist nicht ausreichend entlüftet ====<br />
In diesem Fall behindern die Luftblasen im System den Durchfluss des Heizmediums.<br/><br />
Der Heizkörper erwärmt sich nur teilweise oder "gluckert".<br />
Hier ist das Entlüften der Heizkörper angesagt.<br/><br/><br />
Natürlich können sich die Gasblasen an anderer Stelle befinden. <br />
Normalerweise sorgen automatische Entlüfter, dass das Gas entweichen kann.<br/><br />
Aber auch diese "verkalken" im Lauf der Zeit.<br />
<br />
==== 2.Fehlerquelle : Totzone beim Stellglied ====<br />
Der Temperaturanstieg erfolgt erst ab einer bestimmten Ventilöffnung von xy%.<br/><br />
Der PID-Regler geht davon aus, dass jede Änderung des Stellausgangs auf die Regelgröße wirkt<br/><br />
(also bei Ventil weiter öffnen, wird mehr Wärme abgegeben)<br/><br/><br />
Ist dies nicht der Fall, wird der PID über die Zeit (I-Anteil) das Ventil weiter öffnen.<br/><br />
Allerdings vergeht hierbei Zeit und damit leidet die Regelgüte.<br/><br/><br />
<br />
Es ist also wichtig die Totzone zu ermitteln und im Attribut pidActorLimitLower zu hinterlegen.<br />
<br />
==== 3.Fehlerquelle : Hydraulische Fehlanpassung ====<br />
Wenn einzelnen Heizkreise einen sehr kleinen hydraulischen Widerstand aufweisen, kann es passieren<br />
das Heizkreise mit höherem Widerstand zeitweise unterversorgt sind.<br/><br/><br />
Erst wenn die gut versorgten Heizkreise die Ventile schließen (Soll-Temperatur ist erreicht),<br />
werden die Heizkreise mit hohem Widerstand ausreichend versorgt.<br/><br/><br />
Dies kann man dank FHEM sehr gut über die Charts nachvollziehen.<br/><br />
Es ist regelungstechnisch, ökologisch und energetisch absolut sinnvoll geregelte Hocheffizienz-Pumpen<br />
im Heizkreis einzusetzen. Diese sorgen für konstanten Druck im Hauptstrang bei sehr geringen Energiebedarf.<br/><br />
<br />
Man kann gezielt den hydraulischen Widerstand einzelner Thermostate erhöhen, indem man deren maximale Ventilöffnung begrenzt.<br/><br />
<br />
Dies erreicht man durch Reduzieren des Wertes pidActorLimitUpper.<br/><br />
Dies ist gleichbedeutend mit der Erhöhung der hydraulischen Widerstandes durch voreinstellbare Heizungsventile beim hydraulischen Abgleich.<br />
<br />
== Weblinks ==<br />
<br />
* [http://forum.fhem.de/index.php/topic,15060.0.html Initialer Forumseintrag zur Überarbeitung des PID-Moduls]<br />
* [http://de.wikipedia.org/wiki/Regler Wikipedia Regler]<br />
<br />
[[Kategorie:Glossary]]<br />
[[Kategorie:Regelungstechnik]]</div>Johnhttp://wiki.fhem.de/w/index.php?title=PID20_-_Der_PID-Regler&diff=8615PID20 - Der PID-Regler2014-11-29T11:14:08Z<p>John: /* Inbetriebnahme */</p>
<hr />
<div>'''PID20''' ist ein Modul, das nach dem P-I-D Algorithmus einen Regler realisiert.<br />
<br />
== Projekt-Status ==<br />
<br />
Das Modul ist seit dem 26.03.2014 Bestandteil von FHEM.<br />
<br />
== Features ==<br />
* einstellbarer Bewertungs-/Berechnungszyklus<br />
* Überwachung des Istwert-Gebers über dessen Zeitstempel (Sensorausfall)<br />
* Skalierbarkeit der Ausgabehäufigkeit an das Stellglied über Zeit und Mindeständerung<br />
* Zwangsausgabe an das Stellglied nach Ablauf eines einstellbaren Zeitintervalls<br />
* Notstellung des Stellgliedes, falls Istwert-Geber ausgefallen ist<br />
* Begrenzung des Stellbereichs nach oben und unten<br />
* Festlegung der Nachkommastellen (0..5) des Ausgabewertes zum Stellglied<br />
* Festlegen einer minimalen Regelabweichung, ab der der Regler aktiv wird<br />
* Festlegen des Reading-Namens für den Sollwert<br />
* Festlegen des Reading-Namens für den Istwert<br />
* Invertierung des Reglerwirksinns<br />
* Festlegen der minimalen Aktualisierungsrate der Readings<br />
* Festlegen der Proportionalitätskonstanten P,I,D<br />
== Thread im Forum ==<br />
[http://forum.fhem.de/index.php/topic,17067.msg111615.html#msg111615 Diskussion zu PID20 im Forum]<br />
<br />
=== Define ===<br />
<code><br />
define <name> PID20 sensor[:reading[:regexp]] actor:cmd <br />
</code><br />
<br />
=== Attribute ===<br />
{| class="wikitable sortable"<br />
|-<br />
! Parameter !! Wertebereich !! Default !! Beschreibung<br />
|-<br />
|pidActorValueDecPlaces||[0..5]||0||Anzahl der Nachkommastellen für Ausgabewert zu Aktor<br />
|-<br />
|pidActorInterval||uint||180||minimale Wartezeit in Sekunden, bis eine neue Ausgabe an das Stellglied erfolgen kann<br />
|-<br />
|pidActorThreshold||uint||1||Notwendige minimale Änderung zum Altwert der Stellgliedausgabe, damit diese erneut erfolgt<br />
|-<br />
|pidActorErrorAction||[freeze, errorPos]||freeze||legt das Verhalten der Ausgabe zum Stellglied fest, wenn der Istwert nicht innerhalb von <pidSensorTimeout> aktualisiert wurde (Sensor-Ausfall) <br /><br />
freeze: Position des Stellgliedes beibehalten<br /><br />
ErrorPos: Position anfahren, die unter Attribut <pidActorErrorPos> angegeben ist."<br />
|-<br />
|pidActorErrorPos||int||0||Diese Position ist einzunehmen, wenn pidActorErrorAction auf errorPos steht und der Istwert-Geber ausgefallen ist.<br />
|-<br />
|pidActorKeepAlive||uint||1800||Spätestens nach dieser Zeit erfolgt eine Zwangsausgabe an das Stellglied<br />
(wenn PID nicht disabled und nicht stopped)<br />
|-<br />
|pidActorLimitLower||float||0||untere Begrenzung für das Stellglied<br />
|-<br />
|pidActorLimitUpper||float||100||obere Begrenzung für das Stellglied<br />
|-<br />
|pidCalcInterval||uint||60||Berechnungszyklus in Sekunden, nach dem die PID-Berechnung durchgeführt wird.<br />
|-<br />
|pidDeltaTreshold||pos. float||0||wenn die Regeldifferenz(delta) kleiner als pidDeltaThreshold, dann wird der Regler eingefroren (state=idle)<br />
|-<br />
|pidDesiredName||string||desired||Name für das Reading, das den Sollwert für den Regler aufnehmen soll<br />
|-<br />
|pidMeasuredName||string||measured||Name für das Reading, das den Istwert für den Regler aufnehmen soll<br />
|-<br />
|pidSensorTimeout||uint||3600||Zeitlimit in Sekunden, nach dessen Überschreitung der Ausfall des Istwert-Gebers anzunehmen ist<br />
|-<br />
|pidReverseAction||[0,1]||0||Umgekehrter Wirksinn des Reglers<br />
|-<br />
|pidUpdateInterval||uint||300||Zeitlimit in Sekunden, nach der ein Zwangsupdate der Readings erfolgen muss (Kurvendarstellung).<br />
|-<br />
|pidFactor_P||pos. float||25||Proportionalitätskonstante für P-Anteil<br />
<br />
|-<br />
|pidFactor_I||pos. float||0.25||Proportionalitätskonstante für I-Anteil<br />
<br />
|-<br />
|pidFactor_D||pos. float||0||Proportionalitätskonstante für D-Anteil<br />
|-<br />
|disable||[0,1]||0||Freigabe/Sperren des Reglers<br />
|}<br />
<br />
=== Setter ===<br />
'''desired'''<br />
* Funktion: Sollwert einstellen<br />
* Name des Setters kann vom Anwender über das Attribute "pidDesiredName" definiert werden<br />
<br />
'''start'''<br />
* PID nimmt den Betrieb wieder auf, es werden P-, I- und D-Anteil vor dem Stop übernommen<br />
<br />
'''stop'''<br />
* PID geht in den Zustand stopped; alles wird praktisch eingefroren<br />
<br />
'''restart'''<br />
* arbeitet zunächst wie Start, jedoch gibt man an, mit welchen Prozentwert der Stellausgang anfangs stehen soll<br />
<br />
=== Readings ===<br />
[[Datei:13 10 20 Pid readings.png]]<br />
* actuation liefert den tatsächlichen Ausgabewert an das Stellglied<br />
* actuationCalc liefert den internen Rechenwert des Ausgabewertes für das Stellglied(ohne Begrenzung)<br />
* delta, die aktuelle Regeldifferenz<br />
* desired (Name ist variabel), der Sollwert<br />
* measured (Name ist variabel), der aktuelle Wert vom Istwert-geber<br />
* p_p, der P-Anteil des Ausgabewertes für das Stellglied<br />
* p_i, der I-Anteil des Ausgabewertes für das Stellglied<br />
* p_d, der D-Anteil des Ausgabewertes für das Stellglied<br />
* state, der Betriebszustand des Reglers<br />
<br />
'''delta'''<br />
<code><br />
delta = desired - measured (also Sollwert-Istwert)<br />
</code><br />
<br />
'''actuation'''<br />
<code><br />
actuation = actuationCalc<br />
</code><br />
jedoch begrenzt durch pidActorLimitLower und pidActorLimitUpper <br />
und formatiert via pidActorValueDecPlaces<br />
<br />
<br />
'''actuationCalc'''<br />
<br />
Der Ausgabewert für das Stellglied wird wie folgt berechnet<br />
<br />
<code><br />
actuationCalc = p_p + p_i + p_d<br />
</code><br />
<br />
'''state'''<br />
<br />
{| class="wikitable"<br />
|-<br />
! state !! Erläuterung<br />
|-<br />
| disabled || PID-Instanz ist inaktiv<br />
|-<br />
| initializing || Modul wurde initialisiert<br />
|-<br />
| idle || Berechnung ist inaktiv<br />
|-<br />
| processing || Berechnung ist aktiv, Normalbetrieb<br />
|-<br />
| alarm || Ausnahmezustand, z.B. Timout des Istwert-Gebers<br />
|}<br />
<br />
== Inbetriebnahme ==<br />
* PID20 definieren, hier mit HMS100TF als Istwert-Geber für die Temperatur und ein MAX-Thermostat als Stellglied; Auslegung für eine Fußbodenheizung (sehr träge)<br />
<pre>define PID.FUBO PID20 DG.BAD.TF:temperature HT.FUBO:maxValveSetting</pre><br />
:* <sensor> = "DG.BAD.TF": Name des Istwert-Geber s (HMS100TF)<br />
:* <reading> = "temperature": das Reading vom HMS100TF, das die Temperatur liefert<br />
:* <regexp> = nicht definiert, wir können also direkt den Wert des Readings verwenden<br />
:* <actor> = "HT.FUBO" : Name des MAX-Thermostats, das als Stellglied verwendet wird<br />
:* <cmd> = "maxValveSetting" : Das Kommando mit dem PID20 die Stellausgabe realisieren soll<br />
<br /><br />
Letztlich wird mit <actor> und <cmd> Folgendes ausgeführt<br />
<pre>set <actor> <cmd> <setting-value> </pre><br />
<br />
'''zusätzlich noch einige Attribute anpassen'''<br />
* die Ausgabehäufigkeit an das Stellglied auf 15 Minuten begrenzen<br />
<pre>attr PID.FUBO pidActorInterval 900</pre><br />
* nur dann einen Wert an das Stellglied ausgeben, wenn die Differenz zum Altwert >= 5% <br />
<pre>attr PID.FUBO pidActorTreshold 5</pre><br />
* Nachommastellen für das Stellglied festlegen; MAX-Thermostate erlauben nur Werte ohne Nachkommastellen<br />
<pre>attr PID.FUBO pidActorValueDecPlaces 0</pre><br />
* I-Faktor festlegen; Überlegung: bei einer Regelabweichung von 1 Grad, soll der I-Anteil um 0.2% pro Minute inkrementieren/dekrementieren <br />
<pre>attr PID.FUBO pidFactor_I 0.2</pre><br />
* P-Faktor festlegen; Überlegung:Bei einer Regel-Abweichung von 1 Grad, soll der P-Anteil +/-50% betragen<br />
<pre>attr PID.FUBO pidFactor_P 50</pre><br />
* Häufigkeit der Events begrenzen: Die Readings werden im Intervall von "pidCalcInterval" aktualisiert. Die damit erzeugten Events kann man mit den Standard-Mechanismen von FHEM begrenzen. Hier wird festgelegt, daß die Readings nur dann einen Event feuern, wenn diese sich tatsächlich ändern. Der Wert hinter dem Doppelpunkt, gibt die Mindeständerung an. Fehlt dieser feuert jede Änderung einen Event.<br />
<pre>attr PID.FUBO event-on-change-reading actuation:1,actuationCalc:0.5,delta:0.2,desired,measured:0.2,p_d:0.1,p_i:1.0,p_p:1.0</pre><br />
* Events feuern, wenn sich über lange Zeit eine Reading nicht ändert: Wenn sich z.B. desired über Stunden nicht ändert, so wird kein einziger Event gefeuert. Mit nachfolgender Einstellung erreicht man, dass ein Event auch dann erzeugt wird, wenn sich das Reading nach einer festgelegten Zeit nicht ändert.(sinnvoll für Charts, hier z.B. alle 30 Minuten).<br />
<pre>attr PID.FUBO event-min-interval actuation:1800,actuationCalc:1800,delta:1800,desired:1800,measured:1800,p_d:1800,p_i:1800,p_p:1800</pre><br />
<br />
'''Chart einrichten'''<br/><br />
Es ist für das Einstellen der Regel-Faktoren (P,I,D) überaus hilfreich, das Verhalten über die Zeit aufzuzeichnen, um das Verhalten objektiv beurteilen zu können.<br/><br />
<br />
;Zunächst ein Filelog einrichten<br/><br />
:define PID.PID.File FileLog ./log/PID.PID-%Y.log PID\.PID<br />
:attr PID.PID.File logtype text<br />
<br />
Danach ein Chart definieren, angelehnt an folgendem Beispiel:<br />
<br />
[[Datei:13_12_03_PID_ChartDef.png]]<br />
<br />
<br />
Anbei ein Vorschlag für au<br />
<br />
== Hintergrund-Informationen ==<br />
=== list <pid-name> ===<br />
<code><br />
Internals:<br />
DEF DG.BAD.TF PID.Actor:state<br />
NAME PID.PID<br />
NR 616<br />
NTFY_ORDER 50-PID.PID<br />
STATE processing<br />
TYPE PID<br />
Readings:<br />
2013-10-20 17:13:41 actuation 97<br />
2013-10-20 17:21:42 actuationCalc 97.2079999999999<br />
2013-10-20 17:21:42 delta 0.199999999999999<br />
2013-10-20 17:13:41 desired 22<br />
2013-10-20 17:13:41 measured 21.8<br />
2013-10-20 17:21:42 p_d 0<br />
2013-10-20 17:21:42 p_i 92.2079999999999<br />
2013-10-20 17:21:42 p_p 4.99999999999998<br />
2013-10-20 17:21:42 state processing<br />
Helper:<br />
actor PID.Actor<br />
actorCommand state<br />
actorErrorAction freeze<br />
actorErrorPos 0<br />
actorInterval 300<br />
actorKeepAlive 1800<br />
actorLimitLower 0<br />
actorLimitUpper 100<br />
actorThreshold 4<br />
actorTimestamp 2013-10-20 17:13:41<br />
actorValueDecPlaces 0<br />
calcInterval 60<br />
deltaGradient 0<br />
deltaOld 0.199999999999999<br />
deltaOldTS 2013-10-20 17:18:07<br />
deltaTreshold 0<br />
desiredName desired<br />
disable 0<br />
factor_D 0<br />
factor_I 0.25<br />
factor_P 25<br />
isWindUP 0<br />
measuredName measured<br />
reading temperature<br />
regexp ([\d\.]*)<br />
reverseAction 0<br />
sensor DG.BAD.TF<br />
sensorTimeout 3600<br />
updateInterval 600<br />
Attributes:<br />
pidActorInterval 300<br />
pidActorTreshold 4<br />
pidActorValueDecPlaces 0<br />
room PID<br />
verbose 4<br />
<br />
</code><br />
<br />
=== Anti-WindUp-Strategie ===<br />
Der integrale Anteil des PID-Reglers wird ohne Gegenmassnahmen auch dann weiter integriert,<br />
wenn das Stellglied bereits an seine Grenzen gestossen ist.<br />
Dies hat den Nachteil, dass nach einer Reduzierung der Regeldifferenz lange Wartezeiten entstehen können, bis das<br />
Stellglied reagiert.<br />
Dies nennt man den WindUP-Effekt.<br />
Hierzu wurde die folgende Strategie entwickelt:<br />
<br />
[[Datei:13 10 20 PID Windup.png|WindUP]]<br />
<br />
Sobald das rechnerische Stellsignal (Ventilstellung Calc=actuationCalc) die obere Grenze des Stellgliedes überschreitet (pidActorLimitUpper) oder die untere Grenze unterschreitet (pidActorLimitLower), wird die Integration des I-Anteils eingefroren.<br />
<br />
<br />
'''Am Beispiel:'''<br />
An Position L1 überschreitet der rechnerische Ausgabewert des Stellgliedes die obere Grenze (100%).<br />
Der I-Anteil verändert sich nicht mehr bis zur Position L2. Hier unterschreitet der Ausgabewert die <br />
obere Grenze, der I-Anteil kann wieder verändert werden.<br />
<br />
== Fragen und Antworten ==<br />
=== Temperatur im Raum steigt nicht oder stark verzögert, was kann ich tun ? ===<br />
<br />
==== 1.Fehlerquelle : Heizsystem ist nicht ausreichend entlüftet ====<br />
In diesem Fall behindern die Luftblasen im System den Durchfluss des Heizmediums.<br/><br />
Der Heizkörper erwärmt sich nur teilweise oder "gluckert".<br />
Hier ist das Entlüften der Heizkörper angesagt.<br/><br/><br />
Natürlich können sich die Gasblasen an anderer Stelle befinden. <br />
Normalerweise sorgen automatische Entlüfter, dass das Gas entweichen kann.<br/><br />
Aber auch diese "verkalken" im Lauf der Zeit.<br />
<br />
==== 2.Fehlerquelle : Totzone beim Stellglied ====<br />
Der Temperaturanstieg erfolgt erst ab einer bestimmten Ventilöffnung von xy%.<br/><br />
Der PID-Regler geht davon aus, dass jede Änderung des Stellausgangs auf die Regelgröße wirkt<br/><br />
(also bei Ventil weiter öffnen, wird mehr Wärme abgegeben)<br/><br/><br />
Ist dies nicht der Fall, wird der PID über die Zeit (I-Anteil) das Ventil weiter öffnen.<br/><br />
Allerdings vergeht hierbei Zeit und damit leidet die Regelgüte.<br/><br/><br />
<br />
Es ist also wichtig die Totzone zu ermitteln und im Attribut pidActorLimitLower zu hinterlegen.<br />
<br />
==== 3.Fehlerquelle : Hydraulische Fehlanpassung ====<br />
Wenn einzelnen Heizkreise einen sehr kleinen hydraulischen Widerstand aufweisen, kann es passieren<br />
das Heizkreise mit höherem Widerstand zeitweise unterversorgt sind.<br/><br/><br />
Erst wenn die gut versorgten Heizkreise die Ventile schließen (Soll-Temperatur ist erreicht),<br />
werden die Heizkreise mit hohem Widerstand ausreichend versorgt.<br/><br/><br />
Dies kann man dank FHEM sehr gut über die Charts nachvollziehen.<br/><br />
Es ist regelungstechnisch, ökologisch und energetisch absolut sinnvoll geregelte Hocheffizienz-Pumpen<br />
im Heizkreis einzusetzen. Diese sorgen für konstanten Druck im Hauptstrang bei sehr geringen Energiebedarf.<br/><br />
<br />
Man kann gezielt den hydraulischen Widerstand einzelner Thermostate erhöhen, indem man deren maximale Ventilöffnung begrenzt.<br/><br />
<br />
Dies erreicht man durch Reduzieren des Wertes pidActorLimitUpper.<br/><br />
Dies ist gleichbedeutend mit der Erhöhung der hydraulischen Widerstandes durch voreinstellbare Heizungsventile beim hydraulischen Abgleich.<br />
<br />
== Weblinks ==<br />
<br />
* [http://forum.fhem.de/index.php/topic,15060.0.html Initialer Forumseintrag zur Überarbeitung des PID-Moduls]<br />
* [http://de.wikipedia.org/wiki/Regler Wikipedia Regler]<br />
<br />
[[Kategorie:Glossary]]<br />
[[Kategorie:Regelungstechnik]]</div>Johnhttp://wiki.fhem.de/w/index.php?title=HourCounter&diff=8551HourCounter2014-11-21T22:05:10Z<p>John: /* Welche Anwendungsfälle sind denkbar ? */</p>
<hr />
<div>{{Infobox Modul<br />
|ModPurpose=HourCounter dient zum Zählen von Ereignissen und zur Erfassung von Betriebs-/Ruhe-Zeiten<br />
|ModType=h<br />
<!-- |ModCmdRef=LightScene -- nicht erforderlich, da Modultyp x --><br />
|ModForumArea=MAX<br />
|ModTechName=98_HourCounter.pm<br />
|ModOwner=John ([http://forum.fhem.de/index.php?action=profile;u=806 Forum] / [[Benutzer Diskussion:John|Wiki]])}}<br />
<br />
<br />
[[HourCounter]] ist ein Perl-Modul, das die Anzahl von Ereignissen erfasst. Bei bipolaren Ereignissen wird zusätzlich die Puls- sowie die Pausendauer ermittelt. Im vorliegenden Beispiel wird ein Betriebsstundenzähler mit einem MAX-Fensterkontakt realisiert.<br />
<br />
== Features ==<br />
* Ermittlung von Betriebsstunden, Auslastung, Verbräuchen, Schalthäufigkeiten<br />
* Ermittlung der Häufigkeit, Puls- Pausendauer pro Tag<br />
* Ermittlung der Puls-/Pausendauer der letzten Schaltperiode<br />
* Bereitstellung von Ereignissen zur Fortführung der Kumulation für Tages-, Wochen- und Monatswerte<br />
* unterstützende Funktionen zur Ablage von Tages-, Wochen- und Monatswerten<br />
<br />
== Zielsetzung des WIKI-Artikels ==<br />
Erläuterung der Funktionalität zur weiterführenden Diskussion im [http://forum.fhem.de/index.php/topic,12216.msg72596.html#msg72596 Forum].<br />
<br />
== Aktuelle Version ==<br />
Das Modul ist seit dem 24.10.2014 Bestandteil von FHEM.<br />
<br />
== Definition ==<br />
=== Abstrakt ===<br />
<pre>define <name> HourCounter <regexp_for_ON> [<regexp_for_Off>]</pre><br />
<br />
<regexp_for_ON> ist ein regulärer Ausdruck der das Ereignis beschreibt.<br />
<br />
Wenn auch [<regexp_for_Off>] definiert ist, so sprechen wir von einem bipolarem Ereignis, das einen <br />
EIN- sowie einen AUS-Zustand aufweist.<br />
<br />
<regexp_for_ON> beschreibt in diesem Fall die positive Flanke,[<regexp_for_Off>] die negative Flanke. Die Struktur des regexp-Ausdruckes ist analog zu jener beim Notify aufgebaut.<br />
<br />
===Konkret===<br />
<pre>define CN.Test HourCounter SHUTTER.JOHN:onoff:.1 SHUTTER.JOHN:onoff:.0</pre><br />
Hier wird der HourCounter CN.TEST definiert.<br />
Ein MAX-Fensterkontakt mit Namen SHUTTER.JOHN wird als Ereignis-Geber verwendet.<br />
Das Reading "onoff" wird als Trigger für unserem Zähler genutzt.<br />
Bei den Fensterkontakten sehen diese Ereignisse wie folgt aus:<br />
<pre><br />
2013-11-15 23:19:12 MAX SHUTTER.JOHN onoff: 1<br />
....<br />
2013-11-15 23:19:24 MAX SHUTTER.JOHN onoff: 0<br />
</pre><br />
<br />
Soll ein Dummy als Ereignis-Geber verwendet werden, lautet die Definition wie folgt:<br />
<pre> define CN.Test HourCounter myDummy:1 myDummy:0</pre><br />
<br />
Die neue Instanz weist folgende Struktur auf:<br />
<br />
<pre><br />
Internals:<br />
CFGFN <br />
DEF SHUTTER.JOHN:onoff:.1 SHUTTER.JOHN:onoff:.0<br />
NAME CN.Test<br />
NR 738<br />
NTFY_ORDER 50-CN.Test<br />
STATE 1<br />
TYPE HourCounter<br />
Readings:<br />
2014-02-04 20:59:22 clearDate 2014-02-04 20:59:22<br />
2014-02-04 20:59:57 countsOverall 1<br />
2014-02-04 20:59:57 countsPerDay 1<br />
2014-02-04 20:59:57 pauseTimeIncrement 35<br />
2014-02-04 20:59:57 pauseTimeOverall 35<br />
2014-02-04 20:59:57 pauseTimePerDay 35<br />
2014-02-04 21:00:01 pulseTimeIncrement 4<br />
2014-02-04 21:00:01 pulseTimeOverall 4<br />
2014-02-04 21:00:01 pulseTimePerDay 4<br />
2014-02-04 20:59:57 state 1<br />
2014-02-04 21:00:00 tickHour 1<br />
2014-02-04 21:00:01 value 0<br />
Helper:<br />
OFF_Regexp SHUTTER.JOHN:onoff:.0<br />
ON_Regexp SHUTTER.JOHN:onoff:.1<br />
calledByEvent <br />
changedTimestamp 2014-02-04 21:00:01<br />
forceClear <br />
forceDayChange <br />
forceHourChange <br />
forceMonthChange <br />
forceWeekChange <br />
isFirstRun <br />
sdRoundHourLast 1391544000<br />
value 0<br />
cmdQueue:<br />
</pre><br />
<br />
== Readings ==<br />
{| class="wikitable sortable"<br />
|-<br />
! Reading !! class="unsortable" | Beschreibung <br />
|-<br />
| clearDate || Datum, zu dem alle kumulativen Readings über set .. clear gelöscht wurden<br />
|-<br />
| countsOverall || Absolutzähler für das Auftreten des ON-Ereignisses<br />
|-<br />
| countsPerDay || Tageszähler für das Auftreten des ON-Ereignisses<br />
|-<br />
| pauseTimeIncrement || Zeitdauer in Sekunden der Pause-Phase der letzten Periode<br />
|-<br />
| pauseTimeOverall || Zeitdauer in Sekunden über alle aufgetretenen Pause-Phasen<br />
|-<br />
| pauseTimePerDay || Zeitdauer in Sekunden über alle aufgetretenen Pause-Phasen des akt. Tages<br />
|-<br />
| pulseTimeIncrement || Zeitdauer in Sekunden der Puls-Phase der letzten Periode<br />
|-<br />
| pulseTimeOverall || Zeitdauer in Sekunden über alle aufgetretenen Puls-Phasen<br />
|-<br />
| pulseTimePerDay || Zeitdauer in Sekunden über alle aufgetretenen Puls-Phasen des akt. Tages<br />
|-<br />
| value || Aktueller Schaltzustand gemäss ON/OFF Ereignis,<br /><br />
mit 1=letztes Ereignis war ON-Ereignis <br /><br />
und 0=letztes Ereignis war OFF-Ereignis<br />
|-<br />
| tickDay || Event wird nach Tageswechsel gefeuert bevor die Tageszähler resettiert werden<br />
|-<br />
| tickHour || Event wird nach Stundenwechsel gefeuert<br />
|-<br />
| tickWeek || Event wird nach Wochenwechsel gefeuert<br />
|-<br />
| tickMonth || Event wird nach Monatswechsel gefeuert<br />
|-<br />
| tickYear || Event wird nach Jahreswechsel gefeuert<br />
|-<br />
| forceHourChange || simuliert einen Stundenwechsel<br />
|-<br />
| forceDayChange || simuliert einen Tageswechsel<br />
|-<br />
| forceWeekChange || simuliert einen Wochenwechsel<br />
|-<br />
| forceMonthChange || simuliert einen Monatswechsel<br />
|-<br />
| forceYearChange || simuliert einen Jahreswechsel<br />
|}<br />
<br />
== Web-Oberfläche ==<br />
[[Datei:13_11_15_HourCounter_Face.png|HourCounter]]<br />
<br />
== Anwendung ==<br />
Nachfolgende Darstellung zeigt das Einschaltverhalten eines Heizungskessels zusammen mit den <br />
abgeleiteten Werten.<br />
<br />
[[Datei:13_11_15_HourCounter_Chart.png]]<br />
<br />
* die Kurve "Brenner EIN" zeigt die Trigger-Signale des ON/OFF Filters, also das Ein-/Ausschalten des Brenners<br />
* die Kurve "Brenner-Starts" zeigt die über den Tag aufgelaufenen Starts, also chronologisch das Anwachsen von Reading countsPerDay<br />
* die Kurve "Betriebsstunden" zeigt die aufgelaufene Zeit aus dem Reading pulseTimePerDay umgerechnet zu Stunden<br />
* die Kurve "Dauer" zeigt die Dauer des letzten Pulses in Sekunden<br />
* die Kurve Auslastung zeigt das Verhältnis des Readings pulseTimePerDay zur seit Tagesbeginn vergangenen Zeit.<br />
<br />
=== Chart der Aktualwerte ===<br />
Wir benötigen hierzu ein File-Archiv für die aufgelaufenen Daten.<br />
<pre>define CN.Test.File FileLog ./log/CN.Test-%Y.log (CN\.Test:.*)</pre><br />
Man erhält nach den ersten Ereignissen Einträge in folgender Form:<br />
<pre><br />
2013-11-16_12:45:40 CN.Test value: 1<br />
2013-11-16_12:45:40 CN.Test 1<br />
2013-11-16_12:46:21 CN.Test pulseTimeIncrement: 41 <br />
2013-11-16_12:46:21 CN.Test pulseTimePerDay: 41<br />
2013-11-16_12:46:21 CN.Test pulseTimeOverall: 41<br />
2013-11-16_12:46:21 CN.Test value: 0<br />
2013-11-16_12:50:38 CN.Test countsPerDay: 2<br />
2013-11-16_12:50:38 CN.Test countsOverall: 2<br />
2013-11-16_12:50:38 CN.Test pauseTimeIncrement: 257<br />
2013-11-16_12:50:38 CN.Test pauseTimePerDay: 756<br />
2013-11-16_12:50:38 CN.Test pauseTimeOverall: 756<br />
2013-11-16_12:50:38 CN.Test value: 1<br />
2013-11-16_12:50:38 CN.Test 2<br />
</pre><br />
<br />
Nun kann man den Chart definieren:<br />
[[Datei:13_11_16_HourCounter_ChartBuild_01.png]]<br />
<br />
Für die Kurve "Brenner EIN" verwenden wir CN.Test.value. Damit diese als unterste Kurve dargestellt wird transformieren wir den Wert 1 auf -2 und alle anderen (also die 0) auf -21 mit folgender Funktion:<br />
<pre>$fld[3]=~"1"?-2:-19</pre><br />
Die "Brenner Starts" können wir direkt von countsPerDay ableiten.<br /><br /><br />
Für die "Betriebsstunden" verwenden wir pulseTimePerDay. Da diese in Sekunden vorliegen teilen wir den Wert durch 3600, um Stunden zu erhalten.<br />
<pre>$fld[3]/=3600</pre><br />
Als letzten versorgen wir noch die Kurve "Dauer" mit pulseTimeIncrement. Da wir diese in Minuten haben wollen ist ebenfalls eine Umformung nötig.<br />
<pre>$fld[3]/=60</pre><br />
<br />
Somit sind die Basis-Kurven angelegt.<br />
<br />
=== Erweiterungen ===<br />
Es wurden im Forum viele Wünsche formuliert, weitere Funktionalitäten für den HourCounter einzuführen.<br />
<br />
* Aggregation über bestimmte oder ganz freie Zeiträume<br />
* komplexe Berechnungen, die zum Verbrauch führen<br />
* Zuordnung von Verbräuchen zu unterschiedlichen Countern nach bestimmten Bedingungen<br />
<br />
Vor allem die Aggregation erfasster Werte in Stunden-, Tages-, Wochen- und Monatswerten ist eine sinnvolle<br />
Erweiterung bei der Verbrauchserfassung.<br />
<br />
HourCounter bietet Schnittstellen an, die es ermöglichen, das Modul selbst mit neuen Eigenschaften zu erweitern.<br />
<br />
Die Referenz-Implementierung in 99_UtilsHourCounter.pm zeigt, wie dies skript-technisch zu realisieren ist.<br />
<br />
==== Installation ====<br />
Die jeweils aktuelle Version von 99_UtilsHourCounter kann über diesen <br />
[http://sourceforge.net/p/fhem/code/HEAD/tree/trunk/fhem/contrib/99_UtilsHourCounter.pm?format=raw Link] bezogen werden.<br />
<br />
==== Readings ====<br />
99_UtilsHourCounter erweitert den HourCounter um folgende Funktionen:<br />
{| class="wikitable sortable"<br />
|-<br />
! Reading !! class="unsortable" | Beschreibung<br />
|-<br />
| appCountsPerHour || Stundenzähler, wird bei Stundenwechsel aktualisiert<br />
|-<br />
| appCountsPerHourTemp || Arbeitszähler zu appCountsPerHour<br />
|-<br />
| appCountsPerDay || Tageszähler, wird bei Tageswechsel aktualisiert (Arbeitszähler ist countsPerDay)<br />
|-<br />
| appCountsPerWeek || Wochenzähler, wird bei Wochenwechsel aktualisiert<br />
|-<br />
| appCountsPerWeekTemp || Arbeitszähler zu appCountsPerWeek<br />
|-<br />
| appCountsPerMonth || Monatszähler, wird bei Monatswechsel aktualisiert<br />
|-<br />
| appCountsPerMonthTemp || Arbeitszähler zu appCountsPerMonth<br />
|-<br />
| appCountsPerYear || Jahreszähler, wird bei Jahreswechsel aktualisiert<br />
|-<br />
| appCountsPerYearTemp || Arbeitszähler zu appCountsPerYear<br />
|-<br />
| appOpHoursPerDay || Betriebsstunden des Tages<br />
|-<br />
| appOpHoursPerDayTemp || Arbeitszähler zu appOpHoursPerDay<br />
|-<br />
| appOpHoursPerWeek || Betriebsstunden der Woche<br />
|-<br />
| appOpHoursPerWeekTemp || Arbeitszähler zu appOpHoursPerWeek<br />
|-<br />
| appOpHoursPerMonth || Betriebsstunden des Monats<br />
|-<br />
| appOpHoursPerMonthTemp || Arbeitszähler appOpHoursPerMonth<br />
|-<br />
| appOpHoursPerYear || Betriebsstunden des Jahres<br />
|-<br />
| appOpHoursPerYearTemp || Arbeitszähler appOpHoursPerYear<br />
|-<br />
| appUtilization || Auslastung = pulseTimePerDay /(vergangene Sekunden seit Tagesbeginn) * 100<br />
|-<br />
| appUtilizationTemp || Arbeitsvariable zu appUtilization<br />
|}<br />
Beginn der Woche ist jeweils der Sonntag.<br /><br />
<br />
Mit folgender Anweisung aktivieren wir die Erweiterungen: <br />
:<code>define CN.Event notify CN.Test:(countsOverall:|value:|tickHour:|tickDay:|tickWeek:|tickMonth:|tickYear:).* {appHCNotify("%NAME","%EVTPART0","%EVTPART1");;}</code><br />
<br />
Spätestens nach einer steigenden und einer fallenden Flanke sind die zuvor genannten app*-Readings zu sehen.<br />
{{Randnotiz|RNTyp=Info|RNText=Die gezeigten define-Anweisungen müssen jeweils in einer Zeile stehen (keine Zeilenumbrüche!).}}<br />
<br />
Die neuen Readings werden automatisch in den "Setter" der Web-Oberflächen aufgenommen. Dies gilt für alle Readings, die mit "app" beginnen.<br />
<br />
Somit können die neuen Readings beliebig manipuliert werden.<br />
<br />
==== Archiv für Tages-/Wochen-/Monats-/Jahreswerte anlegen ====<br />
Nun wollen wir die aggregierten Werte in eine eigene Datei speichern. Dies gelingt mit <br />
:<code>define CN.Test.FileDay FileLog ./log/CN.Test-Day-%Y.log CN.Test:app\w+ (Utilization|PerHour|PerDay|PerWeek|PerMonth|PerYear)(?!Temp).* </code><br />
<br />
<br />
Im Klartext:<br />
* verwende alle Werte des Counters CN.Test, deren Reading mit "app" beginnt<br />
* und die einen der Terme appUtilization|PerHour|PerDay|PerWeek|PerMonth|PerYear beinhalten<br />
* und die danach nicht dem Term "Temp" beinhalten<br />
<br />
== Fragen und Antworten ==<br />
==== Betriebsstundenzähler über Leistungsmessung ableiten ====<br />
'''Frage:'''<br />
Ich würde gerne zählen, wenn ich mehr Strom als Standy verbrauche (also mehr als 2Watt)<br />
und keine Betriebsstunden zählen, wenn der Verbrauch unter 2 Watt ist. Ist das möglich?<br />
<br />
<u>Beispiel für die Events</u><br />
<pre><br />
013-11-18_19:40:32 XXX power: 1.9<br />
2013-11-18_19:40:32 XXX consumption: 2<br />
2013-11-18_19:40:32 XXX consumptionTotal: 2<br />
2013-11-18_19:40:36 XXX power: 27<br />
2013-11-18_19:40:36 XXX consumption: 2<br />
2013-11-18_19:40:36 XXX consumptionTotal: 2<br />
2013-11-18_19:40:42 XXX power: 34.6<br />
2013-11-18_19:40:42 XXX consumption: 2 <br />
</pre><br />
<br />
'''Antwort'''<br />
<pre><br />
define CN.Test HourCounter XXX:power:\s[0-9]{2,}(\.[0-9]{1,3})*$ XXX:power:\s[0-9]{1}(\.[0-9]{1,3})*$<br />
</pre><br />
Erläuterung zu <regexp_for_ON> = XXX:power:\s[0-9]{2,}(\.[0-9]{1,3})*$<br />
* "XXX" bezeichnet das Device, der Term danach ist der regexp-Filte für das On-Ereignis<br />
* "power:" das Ereignis muss mit diesem Term beginnen<br />
* "\s" es muss ein Leerzeichen folgen<br />
* "[0-9]{2,}" es müssen mindestens 2 Ziffern folgen<br />
* "(\.[0-9]{1,3})*" wenn ein Punkt folgt, dann müssen auf diesen mindestens 1..3 Ziffern folgen<br />
* "$" danach darf kein weiteres Zeichen mehr folgen<br />
<br />
==== Welche Anwendungsfälle sind denkbar ? ====<br />
[http://forum.fhem.de/index.php/topic,12216.msg175163.html#msg175163 Aus dem Forum]<br />
* Betriebsstundenzähler für meine "Fliegenkiller-Steckdose"<br />
* Nutzungsdauer beschränken für TV,Internet oder Spielkonsolen für entnervte Eltern<br />
* Nutzungsdauer ermitteln zur Energieeinsparung (Klimageräte, Ventilatoren, Dunstabzugshauben etc.)<br />
* Lüftungsverhalten ermitteln (wie lange Fenster pro Tag geöffnet)<br />
<br />
[http://forum.fhem.de/index.php/topic,12216.msg195358.html#msg195358 Brenner Starts/Verbrauch + akkumulierte Werte]<br />
<br />
[http://forum.fhem.de/index.php/topic,12216.msg196358.html#msg196358 Ölverbrauch+Solar-Ladung]<br />
<br />
[http://voizchat.de/gaszaehler-verbrauch-erfassen-mit-fhem-und-raspberry-gpio/ Gaszähler mit HourCounter realisieren]<br />
==== Seltene Schaltvorgänge ====<br />
Die Schaltvorgänge sind über den Tag sehr wenige. Die Aktualisierung erfolgt immer erst<br />
bei der negativen Flanke. Wie kann man eine häufigere Aktualisierung erreichen ?<br />
<br />
'''Antwort'''<br />
<br />
Ab Version 1.0.0.6 ist wurde das Attribut "interval" eingeführt; es ist auf 60 Minuten voreingestellt und kann von 5..60 im 5 Minuten-Raster festgelegt werden.<br />
Es bestimmt, nach welcher Zeit Puls-/Pausendauer aktualisiert werden sollen, unabhängig vom Auftreten einer Schaltflanke.<br />
<br />
<br />
[[Kategorie:MAX]]<br />
[[Kategorie:HOWTOS]]</div>Johnhttp://wiki.fhem.de/w/index.php?title=MAX!_Temperatur-Scanner&diff=8352MAX! Temperatur-Scanner2014-11-04T19:11:22Z<p>John: /* Aktuelle Version */</p>
<hr />
<div>Der '''MAX! Temperatur-Scanner''' ist ein Perl-Skript, das die kontinuierliche Temperatur-Aufzeichnung<br />
von MAX-Thermostaten ermöglicht. <br />
<br />
== Features ==<br />
* kontinuierliche Erfassung von Temperatur und Ventil-Position <br />
* Berücksichtigung der System-Ressourcen (dutycycle, credits)<br />
* CUL und CUBE werden unterstützt<br />
* gleichberechtigte zeitliche Bearbeitung der Thermostate (Round-Robin-Prinzip)<br />
* Ermittlung der optimalen Scan-Rate über die Anzahl der eingebundenen Thermostate<br />
* 2 Scan-Modi stehen zur Verfügung (DesiredChange + ModeChange)<br />
<br />
== Zielsetzung des WIKI-Artikels ==<br />
Hier werden Fragen und Erkenntnisse zum Thema dargestellt, da der Forums-Eintrag für viele Anwender nicht mehr überschaubar ist.<br />
<br />
Der Artikel wird sukzessive erweitert.<br />
<br />
== Aktuelle Version ==<br />
Im Anhang zu folgendem Forumsbeitrag [http://forum.fhem.de/index.php/topic,11624.msg68237.html#msg68237 MaxScan Version 1.05c]<br />
<br />
=== Voraussetzungen ===<br />
==== Qualität der Funkverbindung ====<br />
In der Log-Datei sollten möglichst wenig Einträge der nachfolgenden Form auftreten<br />
<pre>2013.11.01 02:12:33 2: CUL_MAX_SendQueueHandler: Missing ack from 0905a5 for 0b0b0040123456xxxxxxxxx</pre><br />
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.<br />
<br />
==== Ausreichend Credits ====<br />
Der Scanner kann nicht aktiv werden, wenn gehäuft Log-Einträge der nachfolgenden Form auftreten.<br />
<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><br />
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.<br />
<br />
==== Einrichten des Thermostat-internen Wochenprogrammes ====<br />
Anders als bei den Vorgängerversionen <=1.04 ist nun ab Version 1.05 zwingend das Thermostat-interne<br />
Wochenprogramm notwendig.<br />
<br />
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.<br />
<br />
Das bei früheren Versionen eingesetzte Heating_Control kann somit entfallen.<br />
<br />
'''Bitte folgendes beachten:'''<br />
<br />
Es gibt im Zusammenhang mit dem Wochenprogramm ein Problem mit dem letzten Schaltpunkt des Tages. <br />
Der Workaround wurde [http://forum.fhem.de/index.php/topic,17231.msg112738.html#msg112738 hier]<br />
beschrieben.<br />
<br />
<big>Man muss dafür sorgen, dass man kurz vor Ende des Tages noch einen Schaltpunkt setzt.</big><br />
<br />
=== Inbetriebnahme ===<br />
* aktuell freigegebene Version von 99_UtilsMaxScan.pm in das Verzeichnis /opt/fhem/FHEM kopieren.<br />
* Bei den Thermostaten, die gescannt werden sollen, das Attribut scanTemp setzen via<br />
<pre>attr VT_HW scanTemp 1</pre><br />
* das Wochenprogramm im Thermostat nach den Bedürfnissen einstellen<br />
* auf''' keinen''' Fall das Attribut keepAuto setzen<br />
* mit dem userReading "onlyAutoMode" kann der Scan-Modus ModeChange festgelegt werden<br />
<pre>attr HT.JOHN userReadings onlyAutoMode { return "1";;}</pre> <br />
* ist ein ShutterContact mit dem Thermostat assoziiert, dann muss man dies bekannt machen mit dem UserReading<br />
<pre>attr VT_HW userReadings watchShutter { return "SHUTTER.HW";;}</pre><br />
* '''FHEM neu starten'''<br />
<br />
'''Hinweis'''<br /><br />
Je kleiner der Wert von Attribut verbose, umso weniger Ausgaben erhält man in der Log-Datei.<br />
<br />
== Mechanismen ==<br />
=== Das Problem ===<br />
Der Hersteller der MAX-Thermostate hat diese so konzipiert, dass die gemessene Temperatur und Ventilstellung nur übertragen werden, wenn sich Folgendes ändert:<br />
* die Ventilstellung<br />
* die Betriebsart (mode: auto,manu,temporary,boost)<br />
* der Sollwert<br />
<br />
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.<br />
<br />
=== Der Lösungsansatz ===<br />
==== Triggerung per Mode-Umschaltung (ModeChange) ====<br />
Dies ist der Default-Mode des Scanners.<br />
Hier wird der Ansatz verfolgt, die Betriebsart des Thermostats regelmässig umzuschalten via<br />
:AUTO ==> MANU<br />
<Wartezeit mindestens 3 Minuten><br />
:MANU ==> AUTO<br />
<br />
Dies veranlasst das Thermostat, regelmässig die gewünschten Werte an FHEM (den gepaarten Transceiver) zu senden.<br />
<br />
==== Triggerung per Sollwert-Umschaltung (DesiredChange) ====<br />
Durch Änderung des Sollwertes kann ebenso die Übertragung des Istwertes am Thermostat initiiert werden.<br />
<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.<br />
<br />
Dieser Modus wird durch die Definition des UserReadings "onlyAutoMode" festgelegt.<br />
:<code>attr HT.JOHN userReadings onlyAutoMode { return "1";;}</code><br />
<br />
'''Beispiel:'''<br />
<br />
Sollwert im Thermostat nach Wochenprofil: 18<br />
Fall A:<br />
----<br />
* Istwert 17<br />
* Sollwert A von Scanner gesetzt : 18.5<br />
* Sollwert B von Scanner gesetzt : 18.0<br />
* Der Scanner wechselt also von 18 auf 18.5 und zurück.<br />
<br />
Fall B:<br />
----<br />
* Istwert 19<br />
* Sollwert A von Scanner gesetzt : 17.5<br />
* Sollwert B von Scanner gesetzt : 18.0<br />
* Der Scanner wechselt also von 18 auf 17.5 und zurück.<br />
<br />
=== Ergebnis ===<br />
==== ohne Scanner ====<br />
[[Datei:2013_12_MaxScanner_Vorher.png|ohne Scanner]]<br />
<br />
==== mit Scanner (ScanMode=ModeChange) ====<br />
[[Datei:13_12_01_Scanner_ModeChange.png|mit Scanner]]<br />
<br />
==== mit Scanner (ScanMode=DesiredChange) ====<br />
[[Datei:13_12_01_Scanner_DesiredChange.png|mit Scanner]]<br />
<br />
=== Ressourcen ===<br />
Die Sendezeit jedes Teilnehmers ist auf 1% begrenzt.<br />
<br />
Konkret bedeutet dies, dass ein CUL ca. 33 Telegramme pro Stunde senden kann.<br />
Der MAX-Scanner darf nicht alle Ressourcen für sich beanspruchen, sondern sieht seine Aufgabe als nachrangig. <br />
<br />
Erst wenn mehr als 300 Credits (von max. 900 möglichen) zur Verfügung stehen, wird das Skript aktiv.<br />
<br />
== Fragen und Antworten ==<br />
=== Welchen ScanMode soll ich wählen? ===<br />
Nachfolgende Punkte können als Entscheidungskriterium dienen:<br />
<br />
'''ModeChange'''<br />
* keine Änderung des Sollwertes nötig<br />
* damit ist das Ventil "ruhiger", da sich die Regeldifferenz nicht durch den Scanner-Betrieb ändert.<br />
<br />
'''DesiredChange'''<br />
* der Auto-Modus wird niemals verlassen<br />
* Falls FHEM ausfällt, wird das Thermostat das gespeicherte Wochenprogramm nutzen<br />
<br />
=== Wie kann man den ScanMode nachträglich ändern? ===<br />
Man kann das userReading ändern, so dass es 0 liefert<br />
:<code>attr HT.JOHN userReadings onlyAutoMode { return "0";;}</code><br />
<br />
oder man löscht das userReading durch<br />
* Löschen aus dem attribut userReading<br />
* und Löschen des vorhandenen userReadings via<br />
:<code>deletereading HT.JOHN onlyAutoMode </code><br />
<br />
=== Was passiert, wenn der Sollwert am Thermostat manuell verstellt wird? ===<br />
Wenn der Sollwert manuell am Thermostat verändert wird, kann es bis zu 3 Minuten dauern, bis dieser an FHEM gemeldet wird.<br />
<br />
Wenn der Scanner in dieser Wartezeit aktiv wird, wird er den soeben geänderten Sollwert überschreiben. In diesem Fall bliebe die manuelle Änderung wirkungslos.<br />
<br />
Wird die manuelle Änderung des Sollwertes vom Scanner erkannt, so gilt dieser bis zum nächsten Schaltpunkt des internen Wochenprogrammes.<br />
<br />
=== Mehrere Thermostate in einer Gruppe? ===<br />
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.<br />
<br />
=== Was ist zu tun wenn, Thermostate zusammen mit einem Wandthermostat eingesetzt werden? ===<br />
In diesem Fall ist der Scanner überflüssig, da das Wandthermostat ohnehin eine detaillierte Kurve des Istwertes liefert.<br />
<br />
=== Sind Fensterkontakte sinnvoll? ===<br />
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 <br />
[http://www.elv.de/topic/tuer-fensterkontakt-sinn-und-unsinn.html Sinn und Unsinn von Fensterkontakten] zeigt.<br />
<br />
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. <br />
<br />
[[Datei:2013_11_02_Scanner_TSturz.png|Sturz-Temperatur-Erkennung]]<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 vermutlich mit einer WindowOpenDuration von 0 behoben werden, ausserdem ist im Hochsommer die Heizung ohnehin ausgeschaltet.<br />
<br />
Folgende Nachteile haben die Max-Fensterkontakte:<br />
* 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.<br />
* 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).<br />
<br />
=== Berücksichtigt der Scanner die Temperatur-Sturz-Erkennung? ===<br />
Wenn desiredTemperature=WindowsOpenTemperature, dann stellt der Scanner seine Arbeit ein. Ansonsten würde er durch aktive Modeumschaltung die WindowsOpenTemperature dauerhaft setzen.<br />
<br />
=== Kann der Scanner mit Fensterkontakten umgehen? ===<br />
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.<br />
<br />
Ausserdem wäre es fatal, wenn der Scanner in der Phase des offenen Fenster den Sollwert überschreiben würde. Bei offenem 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.<br />
<br />
=== Was ist denn, wenn ich noch einen zweiten Fensterkontakt habe? ===<br />
Derzeit wird nur 1 ShutterContact unterstützt. Möglicherweise wird in einer der nächsten Versionen die Funktionalität erweitert.<br />
<br />
=== Was passiert, wenn der Boost-Mode aktiviert wurde? ===<br />
Sobald dies der Scanner erkennt, stellt er seine Aktivität ein, bis wieder der Modus Auto oder Manu erscheint.<br />
<br />
=== Unterstützt der Scanner auch den MAX-ECO-Taster? ===<br />
Nein. Dies wird für künftige Versionen geplant.<br />
<br />
=== Beeinflusst der Scanner den Regelmechanismus des Thermostats? ===<br />
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.<br />
<br />
== Im Kochtopf ==<br />
<br />
* Scanner wird nicht mehr als Skript, sondern als Modul ausgeführt.<br />
* Mindestwert für Scan-Intervall, der nicht unterschritten werden darf<br />
* Möglichkeit mehrere Fensterkontakte einem Thermostat zuzuweisen<br />
* Verzögerte Reaktion nach Aktivieren des Fensterkontakts<br />
* Möglichkeit eine Gruppe von Thermostaten auf Eco-Mode zu schalten (z.B. ausgelöst über ECO-Taster)<br />
* Gruppenbildung über mehrere Thermostate (für Eco-Taster)<br />
* Fix: wenn bei desriredtemperatur ON,OFF anstelle einer Zahl erscheint.<br />
<br />
<br />
[[Kategorie:MAX]]</div>Johnhttp://wiki.fhem.de/w/index.php?title=MAX!_Temperatur-Scanner&diff=8308MAX! Temperatur-Scanner2014-11-01T09:58:07Z<p>John: /* Im Kochtopf */</p>
<hr />
<div>Der '''MAX! Temperatur-Scanner''' ist ein Perl-Skript, das die kontinuierliche Temperatur-Aufzeichnung<br />
von MAX-Thermostaten ermöglicht. <br />
<br />
== Features ==<br />
* kontinuierliche Erfassung von Temperatur und Ventil-Position <br />
* Berücksichtigung der System-Ressourcen (dutycycle, credits)<br />
* CUL und CUBE werden unterstützt<br />
* gleichberechtigte zeitliche Bearbeitung der Thermostate (Round-Robin-Prinzip)<br />
* Ermittlung der optimalen Scan-Rate über die Anzahl der eingebundenen Thermostate<br />
* 2 Scan-Modi stehen zur Verfügung (DesiredChange + ModeChange)<br />
<br />
== Zielsetzung des WIKI-Artikels ==<br />
Hier werden Fragen und Erkenntnisse zum Thema dargestellt, da der Forums-Eintrag für viele Anwender nicht mehr überschaubar ist.<br />
<br />
Der Artikel wird sukzessive erweitert.<br />
<br />
== Aktuelle Version ==<br />
<strike><br />
Im Anhang zu folgendem Forumsbeitrag [http://forum.fhem.de/index.php/topic,11624.msg100703.html#msg100703 MaxScan Version 1.04c]<br />
<br />
Im Anhang zu folgendem Forumsbeitrag [http://forum.fhem.de/index.php/topic,11624.msg111299.html#msg111299 MaxScan Version 1.05a]<br />
</strike><br /><br />
Im Anhang zu folgendem Forumsbeitrag [http://forum.fhem.de/index.php/topic,11624.msg150984.html#msg150984 MaxScan Version 1.05c]<br />
<br />
=== Voraussetzungen ===<br />
==== Qualität der Funkverbindung ====<br />
In der Log-Datei sollten möglichst wenig Einträge der nachfolgenden Form auftreten<br />
<pre>2013.11.01 02:12:33 2: CUL_MAX_SendQueueHandler: Missing ack from 0905a5 for 0b0b0040123456xxxxxxxxx</pre><br />
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.<br />
<br />
==== Ausreichend Credits ====<br />
Der Scanner kann nicht aktiv werden, wenn gehäuft Log-Einträge der nachfolgenden Form auftreten.<br />
<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><br />
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.<br />
<br />
==== Einrichten des Thermostat-internen Wochenprogrammes ====<br />
Anders als bei den Vorgängerversionen <=1.04 ist nun ab Version 1.05 zwingend das Thermostat-interne<br />
Wochenprogramm notwendig.<br />
<br />
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.<br />
<br />
Das bei früheren Versionen eingesetzte Heating_Control kann somit entfallen.<br />
<br />
'''Bitte folgendes beachten:'''<br />
<br />
Es gibt im Zusammenhang mit dem Wochenprogramm ein Problem mit dem letzten Schaltpunkt des Tages. <br />
Der Workaround wurde [http://forum.fhem.de/index.php/topic,17231.msg112738.html#msg112738 hier]<br />
beschrieben.<br />
<br />
<big>Man muss dafür sorgen, dass man kurz vor Ende des Tages noch einen Schaltpunkt setzt.</big><br />
<br />
=== Inbetriebnahme ===<br />
* aktuell freigegebene Version von 99_UtilsMaxScan.pm in das Verzeichnis /opt/fhem/FHEM kopieren.<br />
* Bei den Thermostaten, die gescannt werden sollen, das Attribut scanTemp setzen via<br />
<pre>attr VT_HW scanTemp 1</pre><br />
* das Wochenprogramm im Thermostat nach den Bedürfnissen einstellen<br />
* auf''' keinen''' Fall das Attribut keepAuto setzen<br />
* mit dem userReading "onlyAutoMode" kann der Scan-Modus ModeChange festgelegt werden<br />
<pre>attr HT.JOHN userReadings onlyAutoMode { return "1";;}</pre> <br />
* ist ein ShutterContact mit dem Thermostat assoziiert, dann muss man dies bekannt machen mit dem UserReading<br />
<pre>attr VT_HW userReadings watchShutter { return "SHUTTER.HW";;}</pre><br />
* '''FHEM neu starten'''<br />
<br />
'''Hinweis'''<br /><br />
Je kleiner der Wert von Attribut verbose, umso weniger Ausgaben erhält man in der Log-Datei.<br />
<br />
== Mechanismen ==<br />
=== Das Problem ===<br />
Der Hersteller der MAX-Thermostate hat diese so konzipiert, dass die gemessene Temperatur und Ventilstellung nur übertragen werden, wenn sich Folgendes ändert:<br />
* die Ventilstellung<br />
* die Betriebsart (mode: auto,manu,temporary,boost)<br />
* der Sollwert<br />
<br />
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.<br />
<br />
=== Der Lösungsansatz ===<br />
==== Triggerung per Mode-Umschaltung (ModeChange) ====<br />
Dies ist der Default-Mode des Scanners.<br />
Hier wird der Ansatz verfolgt, die Betriebsart des Thermostats regelmässig umzuschalten via<br />
:AUTO ==> MANU<br />
<Wartezeit mindestens 3 Minuten><br />
:MANU ==> AUTO<br />
<br />
Dies veranlasst das Thermostat, regelmässig die gewünschten Werte an FHEM (den gepaarten Transceiver) zu senden.<br />
<br />
==== Triggerung per Sollwert-Umschaltung (DesiredChange) ====<br />
Durch Änderung des Sollwertes kann ebenso die Übertragung des Istwertes am Thermostat initiiert werden.<br />
<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.<br />
<br />
Dieser Modus wird durch die Definition des UserReadings "onlyAutoMode" festgelegt.<br />
:<code>attr HT.JOHN userReadings onlyAutoMode { return "1";;}</code><br />
<br />
'''Beispiel:'''<br />
<br />
Sollwert im Thermostat nach Wochenprofil: 18<br />
Fall A:<br />
----<br />
* Istwert 17<br />
* Sollwert A von Scanner gesetzt : 18.5<br />
* Sollwert B von Scanner gesetzt : 18.0<br />
* Der Scanner wechselt also von 18 auf 18.5 und zurück.<br />
<br />
Fall B:<br />
----<br />
* Istwert 19<br />
* Sollwert A von Scanner gesetzt : 17.5<br />
* Sollwert B von Scanner gesetzt : 18.0<br />
* Der Scanner wechselt also von 18 auf 17.5 und zurück.<br />
<br />
=== Ergebnis ===<br />
==== ohne Scanner ====<br />
[[Datei:2013_12_MaxScanner_Vorher.png|ohne Scanner]]<br />
<br />
==== mit Scanner (ScanMode=ModeChange) ====<br />
[[Datei:13_12_01_Scanner_ModeChange.png|mit Scanner]]<br />
<br />
==== mit Scanner (ScanMode=DesiredChange) ====<br />
[[Datei:13_12_01_Scanner_DesiredChange.png|mit Scanner]]<br />
<br />
=== Ressourcen ===<br />
Die Sendezeit jedes Teilnehmers ist auf 1% begrenzt.<br />
<br />
Konkret bedeutet dies, dass ein CUL ca. 33 Telegramme pro Stunde senden kann.<br />
Der MAX-Scanner darf nicht alle Ressourcen für sich beanspruchen, sondern sieht seine Aufgabe als nachrangig. <br />
<br />
Erst wenn mehr als 300 Credits (von max. 900 möglichen) zur Verfügung stehen, wird das Skript aktiv.<br />
<br />
== Fragen und Antworten ==<br />
=== Welchen ScanMode soll ich wählen? ===<br />
Nachfolgende Punkte können als Entscheidungskriterium dienen:<br />
<br />
'''ModeChange'''<br />
* keine Änderung des Sollwertes nötig<br />
* damit ist das Ventil "ruhiger", da sich die Regeldifferenz nicht durch den Scanner-Betrieb ändert.<br />
<br />
'''DesiredChange'''<br />
* der Auto-Modus wird niemals verlassen<br />
* Falls FHEM ausfällt, wird das Thermostat das gespeicherte Wochenprogramm nutzen<br />
<br />
=== Wie kann man den ScanMode nachträglich ändern? ===<br />
Man kann das userReading ändern, so dass es 0 liefert<br />
:<code>attr HT.JOHN userReadings onlyAutoMode { return "0";;}</code><br />
<br />
oder man löscht das userReading durch<br />
* Löschen aus dem attribut userReading<br />
* und Löschen des vorhandenen userReadings via<br />
:<code>deletereading HT.JOHN onlyAutoMode </code><br />
<br />
=== Was passiert, wenn der Sollwert am Thermostat manuell verstellt wird? ===<br />
Wenn der Sollwert manuell am Thermostat verändert wird, kann es bis zu 3 Minuten dauern, bis dieser an FHEM gemeldet wird.<br />
<br />
Wenn der Scanner in dieser Wartezeit aktiv wird, wird er den soeben geänderten Sollwert überschreiben. In diesem Fall bliebe die manuelle Änderung wirkungslos.<br />
<br />
Wird die manuelle Änderung des Sollwertes vom Scanner erkannt, so gilt dieser bis zum nächsten Schaltpunkt des internen Wochenprogrammes.<br />
<br />
=== Mehrere Thermostate in einer Gruppe? ===<br />
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.<br />
<br />
=== Was ist zu tun wenn, Thermostate zusammen mit einem Wandthermostat eingesetzt werden? ===<br />
In diesem Fall ist der Scanner überflüssig, da das Wandthermostat ohnehin eine detaillierte Kurve des Istwertes liefert.<br />
<br />
=== Sind Fensterkontakte sinnvoll? ===<br />
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 <br />
[http://www.elv.de/topic/tuer-fensterkontakt-sinn-und-unsinn.html Sinn und Unsinn von Fensterkontakten] zeigt.<br />
<br />
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. <br />
<br />
[[Datei:2013_11_02_Scanner_TSturz.png|Sturz-Temperatur-Erkennung]]<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 vermutlich mit einer WindowOpenDuration von 0 behoben werden, ausserdem ist im Hochsommer die Heizung ohnehin ausgeschaltet.<br />
<br />
Folgende Nachteile haben die Max-Fensterkontakte:<br />
* 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.<br />
* 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).<br />
<br />
=== Berücksichtigt der Scanner die Temperatur-Sturz-Erkennung? ===<br />
Wenn desiredTemperature=WindowsOpenTemperature, dann stellt der Scanner seine Arbeit ein. Ansonsten würde er durch aktive Modeumschaltung die WindowsOpenTemperature dauerhaft setzen.<br />
<br />
=== Kann der Scanner mit Fensterkontakten umgehen? ===<br />
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.<br />
<br />
Ausserdem wäre es fatal, wenn der Scanner in der Phase des offenen Fenster den Sollwert überschreiben würde. Bei offenem 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.<br />
<br />
=== Was ist denn, wenn ich noch einen zweiten Fensterkontakt habe? ===<br />
Derzeit wird nur 1 ShutterContact unterstützt. Möglicherweise wird in einer der nächsten Versionen die Funktionalität erweitert.<br />
<br />
=== Was passiert, wenn der Boost-Mode aktiviert wurde? ===<br />
Sobald dies der Scanner erkennt, stellt er seine Aktivität ein, bis wieder der Modus Auto oder Manu erscheint.<br />
<br />
=== Unterstützt der Scanner auch den MAX-ECO-Taster? ===<br />
Nein. Dies wird für künftige Versionen geplant.<br />
<br />
=== Beeinflusst der Scanner den Regelmechanismus des Thermostats? ===<br />
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.<br />
<br />
== Im Kochtopf ==<br />
<br />
* Scanner wird nicht mehr als Skript, sondern als Modul ausgeführt.<br />
* Mindestwert für Scan-Intervall, der nicht unterschritten werden darf<br />
* Möglichkeit mehrere Fensterkontakte einem Thermostat zuzuweisen<br />
* Verzögerte Reaktion nach Aktivieren des Fensterkontakts<br />
* Möglichkeit eine Gruppe von Thermostaten auf Eco-Mode zu schalten (z.B. ausgelöst über ECO-Taster)<br />
* Gruppenbildung über mehrere Thermostate (für Eco-Taster)<br />
* Fix: wenn bei desriredtemperatur ON,OFF anstelle einer Zahl erscheint.<br />
<br />
<br />
[[Kategorie:MAX]]</div>Johnhttp://wiki.fhem.de/w/index.php?title=MAX!_Temperatur-Scanner&diff=8307MAX! Temperatur-Scanner2014-11-01T09:57:01Z<p>John: /* Ausblick */</p>
<hr />
<div>Der '''MAX! Temperatur-Scanner''' ist ein Perl-Skript, das die kontinuierliche Temperatur-Aufzeichnung<br />
von MAX-Thermostaten ermöglicht. <br />
<br />
== Features ==<br />
* kontinuierliche Erfassung von Temperatur und Ventil-Position <br />
* Berücksichtigung der System-Ressourcen (dutycycle, credits)<br />
* CUL und CUBE werden unterstützt<br />
* gleichberechtigte zeitliche Bearbeitung der Thermostate (Round-Robin-Prinzip)<br />
* Ermittlung der optimalen Scan-Rate über die Anzahl der eingebundenen Thermostate<br />
* 2 Scan-Modi stehen zur Verfügung (DesiredChange + ModeChange)<br />
<br />
== Zielsetzung des WIKI-Artikels ==<br />
Hier werden Fragen und Erkenntnisse zum Thema dargestellt, da der Forums-Eintrag für viele Anwender nicht mehr überschaubar ist.<br />
<br />
Der Artikel wird sukzessive erweitert.<br />
<br />
== Aktuelle Version ==<br />
<strike><br />
Im Anhang zu folgendem Forumsbeitrag [http://forum.fhem.de/index.php/topic,11624.msg100703.html#msg100703 MaxScan Version 1.04c]<br />
<br />
Im Anhang zu folgendem Forumsbeitrag [http://forum.fhem.de/index.php/topic,11624.msg111299.html#msg111299 MaxScan Version 1.05a]<br />
</strike><br /><br />
Im Anhang zu folgendem Forumsbeitrag [http://forum.fhem.de/index.php/topic,11624.msg150984.html#msg150984 MaxScan Version 1.05c]<br />
<br />
=== Voraussetzungen ===<br />
==== Qualität der Funkverbindung ====<br />
In der Log-Datei sollten möglichst wenig Einträge der nachfolgenden Form auftreten<br />
<pre>2013.11.01 02:12:33 2: CUL_MAX_SendQueueHandler: Missing ack from 0905a5 for 0b0b0040123456xxxxxxxxx</pre><br />
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.<br />
<br />
==== Ausreichend Credits ====<br />
Der Scanner kann nicht aktiv werden, wenn gehäuft Log-Einträge der nachfolgenden Form auftreten.<br />
<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><br />
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.<br />
<br />
==== Einrichten des Thermostat-internen Wochenprogrammes ====<br />
Anders als bei den Vorgängerversionen <=1.04 ist nun ab Version 1.05 zwingend das Thermostat-interne<br />
Wochenprogramm notwendig.<br />
<br />
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.<br />
<br />
Das bei früheren Versionen eingesetzte Heating_Control kann somit entfallen.<br />
<br />
'''Bitte folgendes beachten:'''<br />
<br />
Es gibt im Zusammenhang mit dem Wochenprogramm ein Problem mit dem letzten Schaltpunkt des Tages. <br />
Der Workaround wurde [http://forum.fhem.de/index.php/topic,17231.msg112738.html#msg112738 hier]<br />
beschrieben.<br />
<br />
<big>Man muss dafür sorgen, dass man kurz vor Ende des Tages noch einen Schaltpunkt setzt.</big><br />
<br />
=== Inbetriebnahme ===<br />
* aktuell freigegebene Version von 99_UtilsMaxScan.pm in das Verzeichnis /opt/fhem/FHEM kopieren.<br />
* Bei den Thermostaten, die gescannt werden sollen, das Attribut scanTemp setzen via<br />
<pre>attr VT_HW scanTemp 1</pre><br />
* das Wochenprogramm im Thermostat nach den Bedürfnissen einstellen<br />
* auf''' keinen''' Fall das Attribut keepAuto setzen<br />
* mit dem userReading "onlyAutoMode" kann der Scan-Modus ModeChange festgelegt werden<br />
<pre>attr HT.JOHN userReadings onlyAutoMode { return "1";;}</pre> <br />
* ist ein ShutterContact mit dem Thermostat assoziiert, dann muss man dies bekannt machen mit dem UserReading<br />
<pre>attr VT_HW userReadings watchShutter { return "SHUTTER.HW";;}</pre><br />
* '''FHEM neu starten'''<br />
<br />
'''Hinweis'''<br /><br />
Je kleiner der Wert von Attribut verbose, umso weniger Ausgaben erhält man in der Log-Datei.<br />
<br />
== Mechanismen ==<br />
=== Das Problem ===<br />
Der Hersteller der MAX-Thermostate hat diese so konzipiert, dass die gemessene Temperatur und Ventilstellung nur übertragen werden, wenn sich Folgendes ändert:<br />
* die Ventilstellung<br />
* die Betriebsart (mode: auto,manu,temporary,boost)<br />
* der Sollwert<br />
<br />
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.<br />
<br />
=== Der Lösungsansatz ===<br />
==== Triggerung per Mode-Umschaltung (ModeChange) ====<br />
Dies ist der Default-Mode des Scanners.<br />
Hier wird der Ansatz verfolgt, die Betriebsart des Thermostats regelmässig umzuschalten via<br />
:AUTO ==> MANU<br />
<Wartezeit mindestens 3 Minuten><br />
:MANU ==> AUTO<br />
<br />
Dies veranlasst das Thermostat, regelmässig die gewünschten Werte an FHEM (den gepaarten Transceiver) zu senden.<br />
<br />
==== Triggerung per Sollwert-Umschaltung (DesiredChange) ====<br />
Durch Änderung des Sollwertes kann ebenso die Übertragung des Istwertes am Thermostat initiiert werden.<br />
<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.<br />
<br />
Dieser Modus wird durch die Definition des UserReadings "onlyAutoMode" festgelegt.<br />
:<code>attr HT.JOHN userReadings onlyAutoMode { return "1";;}</code><br />
<br />
'''Beispiel:'''<br />
<br />
Sollwert im Thermostat nach Wochenprofil: 18<br />
Fall A:<br />
----<br />
* Istwert 17<br />
* Sollwert A von Scanner gesetzt : 18.5<br />
* Sollwert B von Scanner gesetzt : 18.0<br />
* Der Scanner wechselt also von 18 auf 18.5 und zurück.<br />
<br />
Fall B:<br />
----<br />
* Istwert 19<br />
* Sollwert A von Scanner gesetzt : 17.5<br />
* Sollwert B von Scanner gesetzt : 18.0<br />
* Der Scanner wechselt also von 18 auf 17.5 und zurück.<br />
<br />
=== Ergebnis ===<br />
==== ohne Scanner ====<br />
[[Datei:2013_12_MaxScanner_Vorher.png|ohne Scanner]]<br />
<br />
==== mit Scanner (ScanMode=ModeChange) ====<br />
[[Datei:13_12_01_Scanner_ModeChange.png|mit Scanner]]<br />
<br />
==== mit Scanner (ScanMode=DesiredChange) ====<br />
[[Datei:13_12_01_Scanner_DesiredChange.png|mit Scanner]]<br />
<br />
=== Ressourcen ===<br />
Die Sendezeit jedes Teilnehmers ist auf 1% begrenzt.<br />
<br />
Konkret bedeutet dies, dass ein CUL ca. 33 Telegramme pro Stunde senden kann.<br />
Der MAX-Scanner darf nicht alle Ressourcen für sich beanspruchen, sondern sieht seine Aufgabe als nachrangig. <br />
<br />
Erst wenn mehr als 300 Credits (von max. 900 möglichen) zur Verfügung stehen, wird das Skript aktiv.<br />
<br />
== Fragen und Antworten ==<br />
=== Welchen ScanMode soll ich wählen? ===<br />
Nachfolgende Punkte können als Entscheidungskriterium dienen:<br />
<br />
'''ModeChange'''<br />
* keine Änderung des Sollwertes nötig<br />
* damit ist das Ventil "ruhiger", da sich die Regeldifferenz nicht durch den Scanner-Betrieb ändert.<br />
<br />
'''DesiredChange'''<br />
* der Auto-Modus wird niemals verlassen<br />
* Falls FHEM ausfällt, wird das Thermostat das gespeicherte Wochenprogramm nutzen<br />
<br />
=== Wie kann man den ScanMode nachträglich ändern? ===<br />
Man kann das userReading ändern, so dass es 0 liefert<br />
:<code>attr HT.JOHN userReadings onlyAutoMode { return "0";;}</code><br />
<br />
oder man löscht das userReading durch<br />
* Löschen aus dem attribut userReading<br />
* und Löschen des vorhandenen userReadings via<br />
:<code>deletereading HT.JOHN onlyAutoMode </code><br />
<br />
=== Was passiert, wenn der Sollwert am Thermostat manuell verstellt wird? ===<br />
Wenn der Sollwert manuell am Thermostat verändert wird, kann es bis zu 3 Minuten dauern, bis dieser an FHEM gemeldet wird.<br />
<br />
Wenn der Scanner in dieser Wartezeit aktiv wird, wird er den soeben geänderten Sollwert überschreiben. In diesem Fall bliebe die manuelle Änderung wirkungslos.<br />
<br />
Wird die manuelle Änderung des Sollwertes vom Scanner erkannt, so gilt dieser bis zum nächsten Schaltpunkt des internen Wochenprogrammes.<br />
<br />
=== Mehrere Thermostate in einer Gruppe? ===<br />
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.<br />
<br />
=== Was ist zu tun wenn, Thermostate zusammen mit einem Wandthermostat eingesetzt werden? ===<br />
In diesem Fall ist der Scanner überflüssig, da das Wandthermostat ohnehin eine detaillierte Kurve des Istwertes liefert.<br />
<br />
=== Sind Fensterkontakte sinnvoll? ===<br />
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 <br />
[http://www.elv.de/topic/tuer-fensterkontakt-sinn-und-unsinn.html Sinn und Unsinn von Fensterkontakten] zeigt.<br />
<br />
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. <br />
<br />
[[Datei:2013_11_02_Scanner_TSturz.png|Sturz-Temperatur-Erkennung]]<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 vermutlich mit einer WindowOpenDuration von 0 behoben werden, ausserdem ist im Hochsommer die Heizung ohnehin ausgeschaltet.<br />
<br />
Folgende Nachteile haben die Max-Fensterkontakte:<br />
* 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.<br />
* 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).<br />
<br />
=== Berücksichtigt der Scanner die Temperatur-Sturz-Erkennung? ===<br />
Wenn desiredTemperature=WindowsOpenTemperature, dann stellt der Scanner seine Arbeit ein. Ansonsten würde er durch aktive Modeumschaltung die WindowsOpenTemperature dauerhaft setzen.<br />
<br />
=== Kann der Scanner mit Fensterkontakten umgehen? ===<br />
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.<br />
<br />
Ausserdem wäre es fatal, wenn der Scanner in der Phase des offenen Fenster den Sollwert überschreiben würde. Bei offenem 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.<br />
<br />
=== Was ist denn, wenn ich noch einen zweiten Fensterkontakt habe? ===<br />
Derzeit wird nur 1 ShutterContact unterstützt. Möglicherweise wird in einer der nächsten Versionen die Funktionalität erweitert.<br />
<br />
=== Was passiert, wenn der Boost-Mode aktiviert wurde? ===<br />
Sobald dies der Scanner erkennt, stellt er seine Aktivität ein, bis wieder der Modus Auto oder Manu erscheint.<br />
<br />
=== Unterstützt der Scanner auch den MAX-ECO-Taster? ===<br />
Nein. Dies wird für künftige Versionen geplant.<br />
<br />
=== Beeinflusst der Scanner den Regelmechanismus des Thermostats? ===<br />
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.<br />
<br />
== Im Kochtopf ==<br />
** Scanner wird nicht mehr als Skript, sondern als Modul ausgeführt.<br />
** Mindestwert für Scan-Intervall, der nicht unterschritten werden darf<br />
** Möglichkeit mehrere Fensterkontakte einem Thermostat zuzuweisen<br />
** Verzögerte Reaktion nach Aktivieren des Fensterkontakts<br />
** Möglichkeit eine Gruppe von Thermostaten auf Eco-Mode zu schalten (z.B. ausgelöst über ECO-Taster)<br />
** Gruppenbildung über mehrere Thermostate (für Eco-Taster)<br />
** Fix: wenn bei desriredtemperatur ON,OFF anstelle einer Zahl erscheint.<br />
<br />
<br />
[[Kategorie:MAX]]</div>Johnhttp://wiki.fhem.de/w/index.php?title=MAX!_Temperatur-Scanner&diff=8306MAX! Temperatur-Scanner2014-11-01T09:52:23Z<p>John: /* Im Kochtopf */</p>
<hr />
<div>Der '''MAX! Temperatur-Scanner''' ist ein Perl-Skript, das die kontinuierliche Temperatur-Aufzeichnung<br />
von MAX-Thermostaten ermöglicht. <br />
<br />
== Features ==<br />
* kontinuierliche Erfassung von Temperatur und Ventil-Position <br />
* Berücksichtigung der System-Ressourcen (dutycycle, credits)<br />
* CUL und CUBE werden unterstützt<br />
* gleichberechtigte zeitliche Bearbeitung der Thermostate (Round-Robin-Prinzip)<br />
* Ermittlung der optimalen Scan-Rate über die Anzahl der eingebundenen Thermostate<br />
* 2 Scan-Modi stehen zur Verfügung (DesiredChange + ModeChange)<br />
<br />
== Zielsetzung des WIKI-Artikels ==<br />
Hier werden Fragen und Erkenntnisse zum Thema dargestellt, da der Forums-Eintrag für viele Anwender nicht mehr überschaubar ist.<br />
<br />
Der Artikel wird sukzessive erweitert.<br />
<br />
== Aktuelle Version ==<br />
<strike><br />
Im Anhang zu folgendem Forumsbeitrag [http://forum.fhem.de/index.php/topic,11624.msg100703.html#msg100703 MaxScan Version 1.04c]<br />
<br />
Im Anhang zu folgendem Forumsbeitrag [http://forum.fhem.de/index.php/topic,11624.msg111299.html#msg111299 MaxScan Version 1.05a]<br />
</strike><br /><br />
Im Anhang zu folgendem Forumsbeitrag [http://forum.fhem.de/index.php/topic,11624.msg150984.html#msg150984 MaxScan Version 1.05c]<br />
<br />
=== Voraussetzungen ===<br />
==== Qualität der Funkverbindung ====<br />
In der Log-Datei sollten möglichst wenig Einträge der nachfolgenden Form auftreten<br />
<pre>2013.11.01 02:12:33 2: CUL_MAX_SendQueueHandler: Missing ack from 0905a5 for 0b0b0040123456xxxxxxxxx</pre><br />
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.<br />
<br />
==== Ausreichend Credits ====<br />
Der Scanner kann nicht aktiv werden, wenn gehäuft Log-Einträge der nachfolgenden Form auftreten.<br />
<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><br />
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.<br />
<br />
==== Einrichten des Thermostat-internen Wochenprogrammes ====<br />
Anders als bei den Vorgängerversionen <=1.04 ist nun ab Version 1.05 zwingend das Thermostat-interne<br />
Wochenprogramm notwendig.<br />
<br />
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.<br />
<br />
Das bei früheren Versionen eingesetzte Heating_Control kann somit entfallen.<br />
<br />
'''Bitte folgendes beachten:'''<br />
<br />
Es gibt im Zusammenhang mit dem Wochenprogramm ein Problem mit dem letzten Schaltpunkt des Tages. <br />
Der Workaround wurde [http://forum.fhem.de/index.php/topic,17231.msg112738.html#msg112738 hier]<br />
beschrieben.<br />
<br />
<big>Man muss dafür sorgen, dass man kurz vor Ende des Tages noch einen Schaltpunkt setzt.</big><br />
<br />
=== Inbetriebnahme ===<br />
* aktuell freigegebene Version von 99_UtilsMaxScan.pm in das Verzeichnis /opt/fhem/FHEM kopieren.<br />
* Bei den Thermostaten, die gescannt werden sollen, das Attribut scanTemp setzen via<br />
<pre>attr VT_HW scanTemp 1</pre><br />
* das Wochenprogramm im Thermostat nach den Bedürfnissen einstellen<br />
* auf''' keinen''' Fall das Attribut keepAuto setzen<br />
* mit dem userReading "onlyAutoMode" kann der Scan-Modus ModeChange festgelegt werden<br />
<pre>attr HT.JOHN userReadings onlyAutoMode { return "1";;}</pre> <br />
* ist ein ShutterContact mit dem Thermostat assoziiert, dann muss man dies bekannt machen mit dem UserReading<br />
<pre>attr VT_HW userReadings watchShutter { return "SHUTTER.HW";;}</pre><br />
* '''FHEM neu starten'''<br />
<br />
'''Hinweis'''<br /><br />
Je kleiner der Wert von Attribut verbose, umso weniger Ausgaben erhält man in der Log-Datei.<br />
<br />
== Mechanismen ==<br />
=== Das Problem ===<br />
Der Hersteller der MAX-Thermostate hat diese so konzipiert, dass die gemessene Temperatur und Ventilstellung nur übertragen werden, wenn sich Folgendes ändert:<br />
* die Ventilstellung<br />
* die Betriebsart (mode: auto,manu,temporary,boost)<br />
* der Sollwert<br />
<br />
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.<br />
<br />
=== Der Lösungsansatz ===<br />
==== Triggerung per Mode-Umschaltung (ModeChange) ====<br />
Dies ist der Default-Mode des Scanners.<br />
Hier wird der Ansatz verfolgt, die Betriebsart des Thermostats regelmässig umzuschalten via<br />
:AUTO ==> MANU<br />
<Wartezeit mindestens 3 Minuten><br />
:MANU ==> AUTO<br />
<br />
Dies veranlasst das Thermostat, regelmässig die gewünschten Werte an FHEM (den gepaarten Transceiver) zu senden.<br />
<br />
==== Triggerung per Sollwert-Umschaltung (DesiredChange) ====<br />
Durch Änderung des Sollwertes kann ebenso die Übertragung des Istwertes am Thermostat initiiert werden.<br />
<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.<br />
<br />
Dieser Modus wird durch die Definition des UserReadings "onlyAutoMode" festgelegt.<br />
:<code>attr HT.JOHN userReadings onlyAutoMode { return "1";;}</code><br />
<br />
'''Beispiel:'''<br />
<br />
Sollwert im Thermostat nach Wochenprofil: 18<br />
Fall A:<br />
----<br />
* Istwert 17<br />
* Sollwert A von Scanner gesetzt : 18.5<br />
* Sollwert B von Scanner gesetzt : 18.0<br />
* Der Scanner wechselt also von 18 auf 18.5 und zurück.<br />
<br />
Fall B:<br />
----<br />
* Istwert 19<br />
* Sollwert A von Scanner gesetzt : 17.5<br />
* Sollwert B von Scanner gesetzt : 18.0<br />
* Der Scanner wechselt also von 18 auf 17.5 und zurück.<br />
<br />
=== Ergebnis ===<br />
==== ohne Scanner ====<br />
[[Datei:2013_12_MaxScanner_Vorher.png|ohne Scanner]]<br />
<br />
==== mit Scanner (ScanMode=ModeChange) ====<br />
[[Datei:13_12_01_Scanner_ModeChange.png|mit Scanner]]<br />
<br />
==== mit Scanner (ScanMode=DesiredChange) ====<br />
[[Datei:13_12_01_Scanner_DesiredChange.png|mit Scanner]]<br />
<br />
=== Ressourcen ===<br />
Die Sendezeit jedes Teilnehmers ist auf 1% begrenzt.<br />
<br />
Konkret bedeutet dies, dass ein CUL ca. 33 Telegramme pro Stunde senden kann.<br />
Der MAX-Scanner darf nicht alle Ressourcen für sich beanspruchen, sondern sieht seine Aufgabe als nachrangig. <br />
<br />
Erst wenn mehr als 300 Credits (von max. 900 möglichen) zur Verfügung stehen, wird das Skript aktiv.<br />
<br />
== Fragen und Antworten ==<br />
=== Welchen ScanMode soll ich wählen? ===<br />
Nachfolgende Punkte können als Entscheidungskriterium dienen:<br />
<br />
'''ModeChange'''<br />
* keine Änderung des Sollwertes nötig<br />
* damit ist das Ventil "ruhiger", da sich die Regeldifferenz nicht durch den Scanner-Betrieb ändert.<br />
<br />
'''DesiredChange'''<br />
* der Auto-Modus wird niemals verlassen<br />
* Falls FHEM ausfällt, wird das Thermostat das gespeicherte Wochenprogramm nutzen<br />
<br />
=== Wie kann man den ScanMode nachträglich ändern? ===<br />
Man kann das userReading ändern, so dass es 0 liefert<br />
:<code>attr HT.JOHN userReadings onlyAutoMode { return "0";;}</code><br />
<br />
oder man löscht das userReading durch<br />
* Löschen aus dem attribut userReading<br />
* und Löschen des vorhandenen userReadings via<br />
:<code>deletereading HT.JOHN onlyAutoMode </code><br />
<br />
=== Was passiert, wenn der Sollwert am Thermostat manuell verstellt wird? ===<br />
Wenn der Sollwert manuell am Thermostat verändert wird, kann es bis zu 3 Minuten dauern, bis dieser an FHEM gemeldet wird.<br />
<br />
Wenn der Scanner in dieser Wartezeit aktiv wird, wird er den soeben geänderten Sollwert überschreiben. In diesem Fall bliebe die manuelle Änderung wirkungslos.<br />
<br />
Wird die manuelle Änderung des Sollwertes vom Scanner erkannt, so gilt dieser bis zum nächsten Schaltpunkt des internen Wochenprogrammes.<br />
<br />
=== Mehrere Thermostate in einer Gruppe? ===<br />
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.<br />
<br />
=== Was ist zu tun wenn, Thermostate zusammen mit einem Wandthermostat eingesetzt werden? ===<br />
In diesem Fall ist der Scanner überflüssig, da das Wandthermostat ohnehin eine detaillierte Kurve des Istwertes liefert.<br />
<br />
=== Sind Fensterkontakte sinnvoll? ===<br />
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 <br />
[http://www.elv.de/topic/tuer-fensterkontakt-sinn-und-unsinn.html Sinn und Unsinn von Fensterkontakten] zeigt.<br />
<br />
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. <br />
<br />
[[Datei:2013_11_02_Scanner_TSturz.png|Sturz-Temperatur-Erkennung]]<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 vermutlich mit einer WindowOpenDuration von 0 behoben werden, ausserdem ist im Hochsommer die Heizung ohnehin ausgeschaltet.<br />
<br />
Folgende Nachteile haben die Max-Fensterkontakte:<br />
* 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.<br />
* 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).<br />
<br />
=== Berücksichtigt der Scanner die Temperatur-Sturz-Erkennung? ===<br />
Wenn desiredTemperature=WindowsOpenTemperature, dann stellt der Scanner seine Arbeit ein. Ansonsten würde er durch aktive Modeumschaltung die WindowsOpenTemperature dauerhaft setzen.<br />
<br />
=== Kann der Scanner mit Fensterkontakten umgehen? ===<br />
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.<br />
<br />
Ausserdem wäre es fatal, wenn der Scanner in der Phase des offenen Fenster den Sollwert überschreiben würde. Bei offenem 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.<br />
<br />
=== Was ist denn, wenn ich noch einen zweiten Fensterkontakt habe? ===<br />
Derzeit wird nur 1 ShutterContact unterstützt. Möglicherweise wird in einer der nächsten Versionen die Funktionalität erweitert.<br />
<br />
=== Was passiert, wenn der Boost-Mode aktiviert wurde? ===<br />
Sobald dies der Scanner erkennt, stellt er seine Aktivität ein, bis wieder der Modus Auto oder Manu erscheint.<br />
<br />
=== Unterstützt der Scanner auch den MAX-ECO-Taster? ===<br />
Nein. Dies wird für künftige Versionen geplant.<br />
<br />
=== Beeinflusst der Scanner den Regelmechanismus des Thermostats? ===<br />
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.<br />
<br />
== Im Kochtopf ==<br />
** Scanner wird nicht mehr als Skript, sondern als Modul ausgeführt.<br />
** Mindestwert für Scan-Intervall, der nicht unterschritten werden darf<br />
** Möglichkeit mehrere Fensterkontakte einem Thermostat zuzuweisen<br />
** Verzögerte Reaktion nach Aktivieren des Fensterkontakts<br />
** Möglichkeit eine Gruppe von Thermostaten auf Eco-Mode zu schalten (z.B. ausgelöst über ECO-Taster)<br />
** Gruppenbildung über mehrere Thermostate (für Eco-Taster)<br />
** Fix: wenn bei desriredtemperatur ON,OFF anstelle einer Zahl erscheint.<br />
<br />
== Ausblick==<br />
=== Scanner als Modul ausführen ===<br />
* Wochenprofil als Attribut <br />
* automatischer Abgleich des Wochenprofils mit dem Thermostat<br />
* Fensterkontakt zuordnen<br />
* ECO-Taster integrieren<br />
<br />
[[Kategorie:MAX]]</div>Johnhttp://wiki.fhem.de/w/index.php?title=MAX!_Temperatur-Scanner&diff=8305MAX! Temperatur-Scanner2014-11-01T09:51:11Z<p>John: /* Im Kochtopf */</p>
<hr />
<div>Der '''MAX! Temperatur-Scanner''' ist ein Perl-Skript, das die kontinuierliche Temperatur-Aufzeichnung<br />
von MAX-Thermostaten ermöglicht. <br />
<br />
== Features ==<br />
* kontinuierliche Erfassung von Temperatur und Ventil-Position <br />
* Berücksichtigung der System-Ressourcen (dutycycle, credits)<br />
* CUL und CUBE werden unterstützt<br />
* gleichberechtigte zeitliche Bearbeitung der Thermostate (Round-Robin-Prinzip)<br />
* Ermittlung der optimalen Scan-Rate über die Anzahl der eingebundenen Thermostate<br />
* 2 Scan-Modi stehen zur Verfügung (DesiredChange + ModeChange)<br />
<br />
== Zielsetzung des WIKI-Artikels ==<br />
Hier werden Fragen und Erkenntnisse zum Thema dargestellt, da der Forums-Eintrag für viele Anwender nicht mehr überschaubar ist.<br />
<br />
Der Artikel wird sukzessive erweitert.<br />
<br />
== Aktuelle Version ==<br />
<strike><br />
Im Anhang zu folgendem Forumsbeitrag [http://forum.fhem.de/index.php/topic,11624.msg100703.html#msg100703 MaxScan Version 1.04c]<br />
<br />
Im Anhang zu folgendem Forumsbeitrag [http://forum.fhem.de/index.php/topic,11624.msg111299.html#msg111299 MaxScan Version 1.05a]<br />
</strike><br /><br />
Im Anhang zu folgendem Forumsbeitrag [http://forum.fhem.de/index.php/topic,11624.msg150984.html#msg150984 MaxScan Version 1.05c]<br />
<br />
=== Voraussetzungen ===<br />
==== Qualität der Funkverbindung ====<br />
In der Log-Datei sollten möglichst wenig Einträge der nachfolgenden Form auftreten<br />
<pre>2013.11.01 02:12:33 2: CUL_MAX_SendQueueHandler: Missing ack from 0905a5 for 0b0b0040123456xxxxxxxxx</pre><br />
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.<br />
<br />
==== Ausreichend Credits ====<br />
Der Scanner kann nicht aktiv werden, wenn gehäuft Log-Einträge der nachfolgenden Form auftreten.<br />
<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><br />
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.<br />
<br />
==== Einrichten des Thermostat-internen Wochenprogrammes ====<br />
Anders als bei den Vorgängerversionen <=1.04 ist nun ab Version 1.05 zwingend das Thermostat-interne<br />
Wochenprogramm notwendig.<br />
<br />
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.<br />
<br />
Das bei früheren Versionen eingesetzte Heating_Control kann somit entfallen.<br />
<br />
'''Bitte folgendes beachten:'''<br />
<br />
Es gibt im Zusammenhang mit dem Wochenprogramm ein Problem mit dem letzten Schaltpunkt des Tages. <br />
Der Workaround wurde [http://forum.fhem.de/index.php/topic,17231.msg112738.html#msg112738 hier]<br />
beschrieben.<br />
<br />
<big>Man muss dafür sorgen, dass man kurz vor Ende des Tages noch einen Schaltpunkt setzt.</big><br />
<br />
=== Inbetriebnahme ===<br />
* aktuell freigegebene Version von 99_UtilsMaxScan.pm in das Verzeichnis /opt/fhem/FHEM kopieren.<br />
* Bei den Thermostaten, die gescannt werden sollen, das Attribut scanTemp setzen via<br />
<pre>attr VT_HW scanTemp 1</pre><br />
* das Wochenprogramm im Thermostat nach den Bedürfnissen einstellen<br />
* auf''' keinen''' Fall das Attribut keepAuto setzen<br />
* mit dem userReading "onlyAutoMode" kann der Scan-Modus ModeChange festgelegt werden<br />
<pre>attr HT.JOHN userReadings onlyAutoMode { return "1";;}</pre> <br />
* ist ein ShutterContact mit dem Thermostat assoziiert, dann muss man dies bekannt machen mit dem UserReading<br />
<pre>attr VT_HW userReadings watchShutter { return "SHUTTER.HW";;}</pre><br />
* '''FHEM neu starten'''<br />
<br />
'''Hinweis'''<br /><br />
Je kleiner der Wert von Attribut verbose, umso weniger Ausgaben erhält man in der Log-Datei.<br />
<br />
== Mechanismen ==<br />
=== Das Problem ===<br />
Der Hersteller der MAX-Thermostate hat diese so konzipiert, dass die gemessene Temperatur und Ventilstellung nur übertragen werden, wenn sich Folgendes ändert:<br />
* die Ventilstellung<br />
* die Betriebsart (mode: auto,manu,temporary,boost)<br />
* der Sollwert<br />
<br />
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.<br />
<br />
=== Der Lösungsansatz ===<br />
==== Triggerung per Mode-Umschaltung (ModeChange) ====<br />
Dies ist der Default-Mode des Scanners.<br />
Hier wird der Ansatz verfolgt, die Betriebsart des Thermostats regelmässig umzuschalten via<br />
:AUTO ==> MANU<br />
<Wartezeit mindestens 3 Minuten><br />
:MANU ==> AUTO<br />
<br />
Dies veranlasst das Thermostat, regelmässig die gewünschten Werte an FHEM (den gepaarten Transceiver) zu senden.<br />
<br />
==== Triggerung per Sollwert-Umschaltung (DesiredChange) ====<br />
Durch Änderung des Sollwertes kann ebenso die Übertragung des Istwertes am Thermostat initiiert werden.<br />
<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.<br />
<br />
Dieser Modus wird durch die Definition des UserReadings "onlyAutoMode" festgelegt.<br />
:<code>attr HT.JOHN userReadings onlyAutoMode { return "1";;}</code><br />
<br />
'''Beispiel:'''<br />
<br />
Sollwert im Thermostat nach Wochenprofil: 18<br />
Fall A:<br />
----<br />
* Istwert 17<br />
* Sollwert A von Scanner gesetzt : 18.5<br />
* Sollwert B von Scanner gesetzt : 18.0<br />
* Der Scanner wechselt also von 18 auf 18.5 und zurück.<br />
<br />
Fall B:<br />
----<br />
* Istwert 19<br />
* Sollwert A von Scanner gesetzt : 17.5<br />
* Sollwert B von Scanner gesetzt : 18.0<br />
* Der Scanner wechselt also von 18 auf 17.5 und zurück.<br />
<br />
=== Ergebnis ===<br />
==== ohne Scanner ====<br />
[[Datei:2013_12_MaxScanner_Vorher.png|ohne Scanner]]<br />
<br />
==== mit Scanner (ScanMode=ModeChange) ====<br />
[[Datei:13_12_01_Scanner_ModeChange.png|mit Scanner]]<br />
<br />
==== mit Scanner (ScanMode=DesiredChange) ====<br />
[[Datei:13_12_01_Scanner_DesiredChange.png|mit Scanner]]<br />
<br />
=== Ressourcen ===<br />
Die Sendezeit jedes Teilnehmers ist auf 1% begrenzt.<br />
<br />
Konkret bedeutet dies, dass ein CUL ca. 33 Telegramme pro Stunde senden kann.<br />
Der MAX-Scanner darf nicht alle Ressourcen für sich beanspruchen, sondern sieht seine Aufgabe als nachrangig. <br />
<br />
Erst wenn mehr als 300 Credits (von max. 900 möglichen) zur Verfügung stehen, wird das Skript aktiv.<br />
<br />
== Fragen und Antworten ==<br />
=== Welchen ScanMode soll ich wählen? ===<br />
Nachfolgende Punkte können als Entscheidungskriterium dienen:<br />
<br />
'''ModeChange'''<br />
* keine Änderung des Sollwertes nötig<br />
* damit ist das Ventil "ruhiger", da sich die Regeldifferenz nicht durch den Scanner-Betrieb ändert.<br />
<br />
'''DesiredChange'''<br />
* der Auto-Modus wird niemals verlassen<br />
* Falls FHEM ausfällt, wird das Thermostat das gespeicherte Wochenprogramm nutzen<br />
<br />
=== Wie kann man den ScanMode nachträglich ändern? ===<br />
Man kann das userReading ändern, so dass es 0 liefert<br />
:<code>attr HT.JOHN userReadings onlyAutoMode { return "0";;}</code><br />
<br />
oder man löscht das userReading durch<br />
* Löschen aus dem attribut userReading<br />
* und Löschen des vorhandenen userReadings via<br />
:<code>deletereading HT.JOHN onlyAutoMode </code><br />
<br />
=== Was passiert, wenn der Sollwert am Thermostat manuell verstellt wird? ===<br />
Wenn der Sollwert manuell am Thermostat verändert wird, kann es bis zu 3 Minuten dauern, bis dieser an FHEM gemeldet wird.<br />
<br />
Wenn der Scanner in dieser Wartezeit aktiv wird, wird er den soeben geänderten Sollwert überschreiben. In diesem Fall bliebe die manuelle Änderung wirkungslos.<br />
<br />
Wird die manuelle Änderung des Sollwertes vom Scanner erkannt, so gilt dieser bis zum nächsten Schaltpunkt des internen Wochenprogrammes.<br />
<br />
=== Mehrere Thermostate in einer Gruppe? ===<br />
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.<br />
<br />
=== Was ist zu tun wenn, Thermostate zusammen mit einem Wandthermostat eingesetzt werden? ===<br />
In diesem Fall ist der Scanner überflüssig, da das Wandthermostat ohnehin eine detaillierte Kurve des Istwertes liefert.<br />
<br />
=== Sind Fensterkontakte sinnvoll? ===<br />
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 <br />
[http://www.elv.de/topic/tuer-fensterkontakt-sinn-und-unsinn.html Sinn und Unsinn von Fensterkontakten] zeigt.<br />
<br />
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. <br />
<br />
[[Datei:2013_11_02_Scanner_TSturz.png|Sturz-Temperatur-Erkennung]]<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 vermutlich mit einer WindowOpenDuration von 0 behoben werden, ausserdem ist im Hochsommer die Heizung ohnehin ausgeschaltet.<br />
<br />
Folgende Nachteile haben die Max-Fensterkontakte:<br />
* 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.<br />
* 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).<br />
<br />
=== Berücksichtigt der Scanner die Temperatur-Sturz-Erkennung? ===<br />
Wenn desiredTemperature=WindowsOpenTemperature, dann stellt der Scanner seine Arbeit ein. Ansonsten würde er durch aktive Modeumschaltung die WindowsOpenTemperature dauerhaft setzen.<br />
<br />
=== Kann der Scanner mit Fensterkontakten umgehen? ===<br />
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.<br />
<br />
Ausserdem wäre es fatal, wenn der Scanner in der Phase des offenen Fenster den Sollwert überschreiben würde. Bei offenem 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.<br />
<br />
=== Was ist denn, wenn ich noch einen zweiten Fensterkontakt habe? ===<br />
Derzeit wird nur 1 ShutterContact unterstützt. Möglicherweise wird in einer der nächsten Versionen die Funktionalität erweitert.<br />
<br />
=== Was passiert, wenn der Boost-Mode aktiviert wurde? ===<br />
Sobald dies der Scanner erkennt, stellt er seine Aktivität ein, bis wieder der Modus Auto oder Manu erscheint.<br />
<br />
=== Unterstützt der Scanner auch den MAX-ECO-Taster? ===<br />
Nein. Dies wird für künftige Versionen geplant.<br />
<br />
=== Beeinflusst der Scanner den Regelmechanismus des Thermostats? ===<br />
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.<br />
<br />
== Im Kochtopf ==<br />
* Modul-Entwicklung zum Scanner<br />
** Scanner wird nicht mehr als Skript, sondern als Modul ausgeführt.<br />
** Mindestwert für Scan-Intervall, der nicht unterschritten werden darf<br />
** Möglichkeit mehrere Fensterkontakte einem Thermostat zuzuweisen<br />
** Verzögerte Reaktion nach Aktivieren des Fensterkontakts<br />
** Möglichkeit eine Gruppe von Thermostaten auf Eco-Mode zu schalten (z.B. ausgelöst über ECO-Taster)<br />
** Gruppenbildung über mehrere Thermostate (für Eco-Taster)<br />
** Fix: wenn bei desriredtemperatur ON,OFF anstelle einer Zahl erscheint.<br />
<br />
== Ausblick==<br />
=== Scanner als Modul ausführen ===<br />
* Wochenprofil als Attribut <br />
* automatischer Abgleich des Wochenprofils mit dem Thermostat<br />
* Fensterkontakt zuordnen<br />
* ECO-Taster integrieren<br />
<br />
[[Kategorie:MAX]]</div>Johnhttp://wiki.fhem.de/w/index.php?title=HourCounter&diff=8277HourCounter2014-10-30T19:22:49Z<p>John: /* Welche Anwendungsfälle sind denkbar ? */</p>
<hr />
<div>{{Infobox Modul<br />
|ModPurpose=HourCounter dient zum Zählen von Ereignissen und zur Erfassung von Betriebs-/Ruhe-Zeiten<br />
|ModType=h<br />
<!-- |ModCmdRef=LightScene -- nicht erforderlich, da Modultyp x --><br />
|ModForumArea=MAX<br />
|ModTechName=98_HourCounter.pm<br />
|ModOwner=John ([http://forum.fhem.de/index.php?action=profile;u=806 Forum] / [[Benutzer Diskussion:John|Wiki]])}}<br />
<br />
<br />
[[HourCounter]] ist ein Perl-Modul, das die Anzahl von Ereignissen erfasst. Bei bipolaren Ereignissen wird zusätzlich die Puls- sowie die Pausendauer ermittelt. Im vorliegenden Beispiel wird ein Betriebsstundenzähler mit einem MAX-Fensterkontakt realisiert.<br />
<br />
== Features ==<br />
* Ermittlung von Betriebsstunden, Auslastung, Verbräuchen, Schalthäufigkeiten<br />
* Ermittlung der Häufigkeit, Puls- Pausendauer pro Tag<br />
* Ermittlung der Puls-/Pausendauer der letzten Schaltperiode<br />
* Bereitstellung von Ereignissen zur Fortführung der Kumulation für Tages-, Wochen- und Monatswerte<br />
* unterstützende Funktionen zur Ablage von Tages-, Wochen- und Monatswerten<br />
<br />
== Zielsetzung des WIKI-Artikels ==<br />
Erläuterung der Funktionalität zur weiterführenden Diskussion im [http://forum.fhem.de/index.php/topic,12216.msg72596.html#msg72596 Forum].<br />
<br />
== Aktuelle Version ==<br />
Das Modul ist seit dem 24.10.2014 Bestandteil von FHEM.<br />
<br />
== Definition ==<br />
=== Abstrakt ===<br />
<pre>define <name> HourCounter <regexp_for_ON> [<regexp_for_Off>]</pre><br />
<br />
<regexp_for_ON> ist ein regulärer Ausdruck der das Ereignis beschreibt.<br />
<br />
Wenn auch [<regexp_for_Off>] definiert ist, so sprechen wir von einem bipolarem Ereignis, das einen <br />
EIN- sowie einen AUS-Zustand aufweist.<br />
<br />
<regexp_for_ON> beschreibt in diesem Fall die positive Flanke,[<regexp_for_Off>] die negative Flanke. Die Struktur des regexp-Ausdruckes ist analog zu jener beim Notify aufgebaut.<br />
<br />
===Konkret===<br />
<pre>define CN.Test HourCounter SHUTTER.JOHN:onoff:.1 SHUTTER.JOHN:onoff:.0</pre><br />
Hier wird der HourCounter CN.TEST definiert.<br />
Ein MAX-Fensterkontakt mit Namen SHUTTER.JOHN wird als Ereignis-Geber verwendet.<br />
Das Reading "onoff" wird als Trigger für unserem Zähler genutzt.<br />
Bei den Fensterkontakten sehen diese Ereignisse wie folgt aus:<br />
<pre><br />
2013-11-15 23:19:12 MAX SHUTTER.JOHN onoff: 1<br />
....<br />
2013-11-15 23:19:24 MAX SHUTTER.JOHN onoff: 0<br />
</pre><br />
<br />
Soll ein Dummy als Ereignis-Geber verwendet werden, lautet die Definition wie folgt:<br />
<pre> define CN.Test HourCounter myDummy:1 myDummy:0</pre><br />
<br />
Die neue Instanz weist folgende Struktur auf:<br />
<br />
<pre><br />
Internals:<br />
CFGFN <br />
DEF SHUTTER.JOHN:onoff:.1 SHUTTER.JOHN:onoff:.0<br />
NAME CN.Test<br />
NR 738<br />
NTFY_ORDER 50-CN.Test<br />
STATE 1<br />
TYPE HourCounter<br />
Readings:<br />
2014-02-04 20:59:22 clearDate 2014-02-04 20:59:22<br />
2014-02-04 20:59:57 countsOverall 1<br />
2014-02-04 20:59:57 countsPerDay 1<br />
2014-02-04 20:59:57 pauseTimeIncrement 35<br />
2014-02-04 20:59:57 pauseTimeOverall 35<br />
2014-02-04 20:59:57 pauseTimePerDay 35<br />
2014-02-04 21:00:01 pulseTimeIncrement 4<br />
2014-02-04 21:00:01 pulseTimeOverall 4<br />
2014-02-04 21:00:01 pulseTimePerDay 4<br />
2014-02-04 20:59:57 state 1<br />
2014-02-04 21:00:00 tickHour 1<br />
2014-02-04 21:00:01 value 0<br />
Helper:<br />
OFF_Regexp SHUTTER.JOHN:onoff:.0<br />
ON_Regexp SHUTTER.JOHN:onoff:.1<br />
calledByEvent <br />
changedTimestamp 2014-02-04 21:00:01<br />
forceClear <br />
forceDayChange <br />
forceHourChange <br />
forceMonthChange <br />
forceWeekChange <br />
isFirstRun <br />
sdRoundHourLast 1391544000<br />
value 0<br />
cmdQueue:<br />
</pre><br />
<br />
== Readings ==<br />
{| class="wikitable sortable"<br />
|-<br />
! Reading !! class="unsortable" | Beschreibung <br />
|-<br />
| clearDate || Datum, zu dem alle kumulativen Readings über set .. clear gelöscht wurden<br />
|-<br />
| countsOverall || Absolutzähler für das Auftreten des ON-Ereignisses<br />
|-<br />
| countsPerDay || Tageszähler für das Auftreten des ON-Ereignisses<br />
|-<br />
| pauseTimeIncrement || Zeitdauer in Sekunden der Pause-Phase der letzten Periode<br />
|-<br />
| pauseTimeOverall || Zeitdauer in Sekunden über alle aufgetretenen Pause-Phasen<br />
|-<br />
| pauseTimePerDay || Zeitdauer in Sekunden über alle aufgetretenen Pause-Phasen des akt. Tages<br />
|-<br />
| pulseTimeIncrement || Zeitdauer in Sekunden der Puls-Phase der letzten Periode<br />
|-<br />
| pulseTimeOverall || Zeitdauer in Sekunden über alle aufgetretenen Puls-Phasen<br />
|-<br />
| pulseTimePerDay || Zeitdauer in Sekunden über alle aufgetretenen Puls-Phasen des akt. Tages<br />
|-<br />
| value || Aktueller Schaltzustand gemäss ON/OFF Ereignis,<br /><br />
mit 1=letztes Ereignis war ON-Ereignis <br /><br />
und 0=letztes Ereignis war OFF-Ereignis<br />
|-<br />
| tickDay || Event wird nach Tageswechsel gefeuert bevor die Tageszähler resettiert werden<br />
|-<br />
| tickHour || Event wird nach Stundenwechsel gefeuert<br />
|-<br />
| tickWeek || Event wird nach Wochenwechsel gefeuert<br />
|-<br />
| tickMonth || Event wird nach Monatswechsel gefeuert<br />
|-<br />
| tickYear || Event wird nach Jahreswechsel gefeuert<br />
|-<br />
| forceHourChange || simuliert einen Stundenwechsel<br />
|-<br />
| forceDayChange || simuliert einen Tageswechsel<br />
|-<br />
| forceWeekChange || simuliert einen Wochenwechsel<br />
|-<br />
| forceMonthChange || simuliert einen Monatswechsel<br />
|-<br />
| forceYearChange || simuliert einen Jahreswechsel<br />
|}<br />
<br />
== Web-Oberfläche ==<br />
[[Datei:13_11_15_HourCounter_Face.png|HourCounter]]<br />
<br />
== Anwendung ==<br />
Nachfolgende Darstellung zeigt das Einschaltverhalten eines Heizungskessels zusammen mit den <br />
abgeleiteten Werten.<br />
<br />
[[Datei:13_11_15_HourCounter_Chart.png]]<br />
<br />
* die Kurve "Brenner EIN" zeigt die Trigger-Signale des ON/OFF Filters, also das Ein-/Ausschalten des Brenners<br />
* die Kurve "Brenner-Starts" zeigt die über den Tag aufgelaufenen Starts, also chronologisch das Anwachsen von Reading countsPerDay<br />
* die Kurve "Betriebsstunden" zeigt die aufgelaufene Zeit aus dem Reading pulseTimePerDay umgerechnet zu Stunden<br />
* die Kurve "Dauer" zeigt die Dauer des letzten Pulses in Sekunden<br />
* die Kurve Auslastung zeigt das Verhältnis des Readings pulseTimePerDay zur seit Tagesbeginn vergangenen Zeit.<br />
<br />
=== Chart der Aktualwerte ===<br />
Wir benötigen hierzu ein File-Archiv für die aufgelaufenen Daten.<br />
<pre>define CN.Test.File FileLog ./log/CN.Test-%Y.log (CN\.Test:.*)</pre><br />
Man erhält nach den ersten Ereignissen Einträge in folgender Form:<br />
<pre><br />
2013-11-16_12:45:40 CN.Test value: 1<br />
2013-11-16_12:45:40 CN.Test 1<br />
2013-11-16_12:46:21 CN.Test pulseTimeIncrement: 41 <br />
2013-11-16_12:46:21 CN.Test pulseTimePerDay: 41<br />
2013-11-16_12:46:21 CN.Test pulseTimeOverall: 41<br />
2013-11-16_12:46:21 CN.Test value: 0<br />
2013-11-16_12:50:38 CN.Test countsPerDay: 2<br />
2013-11-16_12:50:38 CN.Test countsOverall: 2<br />
2013-11-16_12:50:38 CN.Test pauseTimeIncrement: 257<br />
2013-11-16_12:50:38 CN.Test pauseTimePerDay: 756<br />
2013-11-16_12:50:38 CN.Test pauseTimeOverall: 756<br />
2013-11-16_12:50:38 CN.Test value: 1<br />
2013-11-16_12:50:38 CN.Test 2<br />
</pre><br />
<br />
Nun kann man den Chart definieren:<br />
[[Datei:13_11_16_HourCounter_ChartBuild_01.png]]<br />
<br />
Für die Kurve "Brenner EIN" verwenden wir CN.Test.value. Damit diese als unterste Kurve dargestellt wird transformieren wir den Wert 1 auf -2 und alle anderen (also die 0) auf -21 mit folgender Funktion:<br />
<pre>$fld[3]=~"1"?-2:-19</pre><br />
Die "Brenner Starts" können wir direkt von countsPerDay ableiten.<br /><br /><br />
Für die "Betriebsstunden" verwenden wir pulseTimePerDay. Da diese in Sekunden vorliegen teilen wir den Wert durch 3600, um Stunden zu erhalten.<br />
<pre>$fld[3]/=3600</pre><br />
Als letzten versorgen wir noch die Kurve "Dauer" mit pulseTimeIncrement. Da wir diese in Minuten haben wollen ist ebenfalls eine Umformung nötig.<br />
<pre>$fld[3]/=60</pre><br />
<br />
Somit sind die Basis-Kurven angelegt.<br />
<br />
=== Erweiterungen ===<br />
Es wurden im Forum viele Wünsche formuliert, weitere Funktionalitäten für den HourCounter einzuführen.<br />
<br />
* Aggregation über bestimmte oder ganz freie Zeiträume<br />
* komplexe Berechnungen, die zum Verbrauch führen<br />
* Zuordnung von Verbräuchen zu unterschiedlichen Countern nach bestimmten Bedingungen<br />
<br />
Vor allem die Aggregation erfasster Werte in Stunden-, Tages-, Wochen- und Monatswerten ist eine sinnvolle<br />
Erweiterung bei der Verbrauchserfassung.<br />
<br />
HourCounter bietet Schnittstellen an, die es ermöglichen, das Modul selbst mit neuen Eigenschaften zu erweitern.<br />
<br />
Die Referenz-Implementierung in 99_UtilsHourCounter.pm zeigt, wie dies skript-technisch zu realisieren ist.<br />
<br />
==== Installation ====<br />
Die jeweils aktuelle Version von 99_UtilsHourCounter kann über diesen <br />
[http://sourceforge.net/p/fhem/code/HEAD/tree/trunk/fhem/contrib/99_UtilsHourCounter.pm?format=raw Link] bezogen werden.<br />
<br />
==== Readings ====<br />
99_UtilsHourCounter erweitert den HourCounter um folgende Funktionen:<br />
{| class="wikitable sortable"<br />
|-<br />
! Reading !! class="unsortable" | Beschreibung<br />
|-<br />
| appCountsPerHour || Stundenzähler, wird bei Stundenwechsel aktualisiert<br />
|-<br />
| appCountsPerHourTemp || Arbeitszähler zu appCountsPerHour<br />
|-<br />
| appCountsPerDay || Tageszähler, wird bei Tageswechsel aktualisiert (Arbeitszähler ist countsPerDay)<br />
|-<br />
| appCountsPerWeek || Wochenzähler, wird bei Wochenwechsel aktualisiert<br />
|-<br />
| appCountsPerWeekTemp || Arbeitszähler zu appCountsPerWeek<br />
|-<br />
| appCountsPerMonth || Monatszähler, wird bei Monatswechsel aktualisiert<br />
|-<br />
| appCountsPerMonthTemp || Arbeitszähler zu appCountsPerMonth<br />
|-<br />
| appCountsPerYear || Jahreszähler, wird bei Jahreswechsel aktualisiert<br />
|-<br />
| appCountsPerYearTemp || Arbeitszähler zu appCountsPerYear<br />
|-<br />
| appOpHoursPerDay || Betriebsstunden des Tages<br />
|-<br />
| appOpHoursPerDayTemp || Arbeitszähler zu appOpHoursPerDay<br />
|-<br />
| appOpHoursPerWeek || Betriebsstunden der Woche<br />
|-<br />
| appOpHoursPerWeekTemp || Arbeitszähler zu appOpHoursPerWeek<br />
|-<br />
| appOpHoursPerMonth || Betriebsstunden des Monats<br />
|-<br />
| appOpHoursPerMonthTemp || Arbeitszähler appOpHoursPerMonth<br />
|-<br />
| appOpHoursPerYear || Betriebsstunden des Jahres<br />
|-<br />
| appOpHoursPerYearTemp || Arbeitszähler appOpHoursPerYear<br />
|-<br />
| appUtilization || Auslastung = pulseTimePerDay /(vergangene Sekunden seit Tagesbeginn) * 100<br />
|-<br />
| appUtilizationTemp || Arbeitsvariable zu appUtilization<br />
|}<br />
Beginn der Woche ist jeweils der Sonntag.<br /><br />
<br />
Mit folgender Anweisung aktivieren wir die Erweiterungen: <br />
:<code>define CN.Event notify CN.Test:(countsOverall:|value:|tickHour:|tickDay:|tickWeek:|tickMonth:|tickYear:).* {appHCNotify("%NAME","%EVTPART0","%EVTPART1");;}</code><br />
<br />
Spätestens nach einer steigenden und einer fallenden Flanke sind die zuvor genannten app*-Readings zu sehen.<br />
{{Randnotiz|RNTyp=Info|RNText=Die gezeigten define-Anweisungen müssen jeweils in einer Zeile stehen (keine Zeilenumbrüche!).}}<br />
<br />
Die neuen Readings werden automatisch in den "Setter" der Web-Oberflächen aufgenommen. Dies gilt für alle Readings, die mit "app" beginnen.<br />
<br />
Somit können die neuen Readings beliebig manipuliert werden.<br />
<br />
==== Archiv für Tages-/Wochen-/Monats-/Jahreswerte anlegen ====<br />
Nun wollen wir die aggregierten Werte in eine eigene Datei speichern. Dies gelingt mit <br />
:<code>define CN.Test.FileDay FileLog ./log/CN.Test-Day-%Y.log CN.Test:app\w+ (Utilization|PerHour|PerDay|PerWeek|PerMonth|PerYear)(?!Temp).* </code><br />
<br />
<br />
Im Klartext:<br />
* verwende alle Werte des Counters CN.Test, deren Reading mit "app" beginnt<br />
* und die einen der Terme appUtilization|PerHour|PerDay|PerWeek|PerMonth|PerYear beinhalten<br />
* und die danach nicht dem Term "Temp" beinhalten<br />
<br />
== Fragen und Antworten ==<br />
==== Betriebsstundenzähler über Leistungsmessung ableiten ====<br />
'''Frage:'''<br />
Ich würde gerne zählen, wenn ich mehr Strom als Standy verbrauche (also mehr als 2Watt)<br />
und keine Betriebsstunden zählen, wenn der Verbrauch unter 2 Watt ist. Ist das möglich?<br />
<br />
<u>Beispiel für die Events</u><br />
<pre><br />
013-11-18_19:40:32 XXX power: 1.9<br />
2013-11-18_19:40:32 XXX consumption: 2<br />
2013-11-18_19:40:32 XXX consumptionTotal: 2<br />
2013-11-18_19:40:36 XXX power: 27<br />
2013-11-18_19:40:36 XXX consumption: 2<br />
2013-11-18_19:40:36 XXX consumptionTotal: 2<br />
2013-11-18_19:40:42 XXX power: 34.6<br />
2013-11-18_19:40:42 XXX consumption: 2 <br />
</pre><br />
<br />
'''Antwort'''<br />
<pre><br />
define CN.Test HourCounter XXX:power:\s[0-9]{2,}(\.[0-9]{1,3})*$ XXX:power:\s[0-9]{1}(\.[0-9]{1,3})*$<br />
</pre><br />
Erläuterung zu <regexp_for_ON> = XXX:power:\s[0-9]{2,}(\.[0-9]{1,3})*$<br />
* "XXX" bezeichnet das Device, der Term danach ist der regexp-Filte für das On-Ereignis<br />
* "power:" das Ereignis muss mit diesem Term beginnen<br />
* "\s" es muss ein Leerzeichen folgen<br />
* "[0-9]{2,}" es müssen mindestens 2 Ziffern folgen<br />
* "(\.[0-9]{1,3})*" wenn ein Punkt folgt, dann müssen auf diesen mindestens 1..3 Ziffern folgen<br />
* "$" danach darf kein weiteres Zeichen mehr folgen<br />
<br />
==== Welche Anwendungsfälle sind denkbar ? ====<br />
[http://forum.fhem.de/index.php/topic,12216.msg175163.html#msg175163 Aus dem Forum]<br />
* Betriebsstundenzähler für meine "Fliegenkiller-Steckdose"<br />
* Nutzungsdauer beschränken für TV,Internet oder Spielkonsolen für entnervte Eltern<br />
* Nutzungsdauer ermitteln zur Energieeinsparung (Klimageräte, Ventilatoren, Dunstabzugshauben etc.)<br />
* Lüftungsverhalten ermitteln (wie lange Fenster pro Tag geöffnet)<br />
<br />
[http://forum.fhem.de/index.php/topic,12216.msg195358.html#msg195358 Brenner Starts/Verbrauch + akkumulierte Werte]<br />
<br />
[http://forum.fhem.de/index.php/topic,12216.msg196358.html#msg196358 Ölverbrauch+Solar-Ladung]<br />
<br />
[http://voizchat.de/gaszaehler-verbrauch-erfassen-mit-fhem-und-raspberry-gpio/ Gaszähler mit HourCounter realisieren]<br />
<br />
[[Kategorie:MAX]]<br />
[[Kategorie:HOWTOS]]</div>Johnhttp://wiki.fhem.de/w/index.php?title=KostalPiko&diff=8227KostalPiko2014-10-25T11:38:25Z<p>John: /* Erfassung der Globalstrahlung ohne KostalPiko */</p>
<hr />
<div>{{Infobox Modul<br />
|ModPurpose=KostalPiko erfasst Informationen vom gleichnamigen Wechselrichter der Fa. Kostal; unabhängig davon kann das Modul auch dazu verwendet werden, die Globalstrahlung am Standort für den aktuellen oder nächsten Tag zu ermitteln.<br />
|ModType=d<br />
<!-- |ModCmdRef=LightScene -- nicht erforderlich, da Modultyp x --><br />
|ModForumArea=Codeschnipsel<br />
|ModTechName=23_KOSTALPIKO.pm<br />
|ModOwner=John ([http://forum.fhem.de/index.php?action=profile;u=806 Forum] / [[Benutzer Diskussion:John|Wiki]])}}<br />
Anbindung des Wechselrichters Piko der Fa. Kostal Solar Electric<br />
<br />
== Geräte Beschreibung ==<br />
Der Solar-Wechselrichter Piko der Fa. Kostal liefert über die Geräte-Webseite wichtige technische Informationen wie<br />
* aktuelle Leistung<br />
* Tages-Energie<br />
* Gesamt-Energie<br />
* Strom und Spannung der drei Input-Strings<br />
* Spannung und Leistung der drei Ausgangsphasen<br />
<br />
Das Gerät verfügt über eine Ethernet-Schnittstelle, über die die Webseite des Gerätes erreichbar ist.<br />
<br />
Aber ohne Wechselrichter kann das Modul hilfreich sein: es erfasst von der Seite<br />
:<code><nowiki>http://www.proplanta.de/Wetter/<meineStadt>-Wetter-Heute.html</nowiki></code><br />
bzw.<br />
:<code><nowiki>http://www.proplanta.de/Wetter/<meineStadt>-Wetter-Morgen.html</nowiki></code><br />
Wetterdaten für den heutigen bzw. für den nächsten Tag (siehe unter Readings, diejenigen, die mit "proplanta" gekennzeichnet sind).<br />
<br />
== FHEM-Modul ==<br />
Das Modul 23_KOSTALPIKO.pm übernimmt folgende Aufgaben:<br />
<br />
* Erfassen der Daten aus der Webseite von Piko<br />
* Erfassen der Erwartungswerte für Gobalstrahlung, UV-Index und Sonnenscheindauer von folgender Webseite [http://www.proplanta.de/Agrar-Wetter/Deutschland/]<br />
* über UserReadings kann der zu erwartenden Energieertrag ermittelt und mit der tatsächlich erzeugten Energiemenge verglichen werden.<br />
=== Define ===<br />
Definition des Geräts in der [[Konfiguration|fhem.cfg]]:<br />
:<code>define <name> KOSTALPIKO <ip-adresse-kostal> <user> <password> </code><br />
<br />
'''Beispiel:'''<br />
:<code>define <name> KOSTALPIKO 192.168.178.99 pvserver pvwr </code><br />
<br />
{| class="wikitable sortable"<br />
|-<br />
! Parameter !! Beschreibung<br />
|-<br />
|<name>||FHEM Name des Devices<br />
|-<br />
|<ip-adresse-kostal>||IP-Adresse von Kostal Piko<br />
|-<br />
|<user>||der User-Name für die Einwahl zur Kostal-Webseite<br />
|-<br />
|<password>||das Passwort für die Einwahl zur Kostal-Webseite<br />
|-<br />
|}<br />
<br />
=== Attribute ===<br />
{| class="wikitable sortable"<br />
|-<br />
! Parameter !! Wertebereich !! Default !! Beschreibung<br />
|-<br />
|GR.Interval||uint||3600||Intervall der Aktualisierung der Globalstrahlung in Sekunden<br />
|-<br />
|GR.Link||string||||Link auf die regionalisierte Seite von http://www.proplanta.de/Wetter/<city>-Wetter-Heute.html<br />
|-<br />
|delay||uint||60||Intervall in Sekunden zu Erfassung der Daten von Kostalpiko<br />
|-<br />
|delayCounter||uint||0||Counter bei Nutzung von AC.Power.Fast<br />
|-<br />
|disable||[0,1]||0||Erfassung von Kostalpiko-Daten ist gesperrt, nicht jedoch der Globalstrahlung<br />
|-<br />
|verbose||[0..5]||0||Log-Ausgabe steuern: 0=keine Ausgaben,5=viele Informationen<br />
|-<br />
|}<br />
<br />
=== Setter ===<br />
'''captureGlobalRadiation'''<br />
* Funktion: manuell die sofortige Erfassung der Werte der Proplanta-Seite anstossen<br />
<br />
'''captureKostalData'''<br />
* Funktion: manuell die sofortige Erfassung der Daten von KostalPiko anstossen<br />
<br />
=== Readings ===<br />
* AC.Power, die aktuelle erzeugte Leistung<br />
* AC.Power.Fast, die aktuell erzeugte Leistung im Schnelltast-Modus<br />
* Daily.Energy, die bisher erzeugte Tagesenergie<br />
* Daily.Energy.Last, die erzeugte Energie des letzten Tages, wird um 23:00 Uhr ermittelt.<br />
* Global.Radiation, die Globalstrahlung am gewählten Standort, damit die erwartete Tagesenergie berechnet werden (proplanta)<br />
* Mode, der Status von KostalPiko<br />
* ModeNum, die nummerische Zuordnung zum Status (0=Aus 1=Leerlauf 2=Einspeisen MPP)<br />
* Total.Energy, die erzeugte Gesamtenergie<br />
* generator.1.current, Strom an String 1 [A]<br />
* generator.1.voltage, Spannung an String 1 [V]<br />
* generator.2.current, Strom an String 2 [A]<br />
* generator.2.voltage, Spannung an String 2 [V]<br />
* generator.3.current, Strom an String 3 [A]<br />
* generator.3.voltage, Spannung an String 3 [V]<br />
* output.1.voltage, Spannung an L1 [V]<br />
* output.1.power, Leistung an L1 [W]<br />
* output.2.voltage, Spannung an L2 [V]<br />
* output.2.power, Leistung an L2 [W]<br />
* output.3.voltage, Spannung an L3 [V]<br />
* output.3.power, Leistung an L3 [W]<br />
* sensor.1, Spannung an 1. analogem Eingang [V]<br />
* sensor.2, Spannung an 2. analogem Eingang [V]<br />
* sensor.3, Spannung an 3. analogem Eingang [V]<br />
* sensor.4, Spannung an 4. analogem Eingang [V]<br />
* UV.Index, UV-Index (proplanta)<br />
* sunshine.duration, rel. Sonnenscheindauer [%] (proplanta)<br />
<br />
== Inbetriebnahme ==<br />
* KOSTALPIKO samt Abfrage-Intervall definieren<br />
<pre><br />
define Kostal KOSTALPIKO 192.168.178.99 pvserver pvwr<br />
attr Kostal delay 60<br />
</pre><br />
* Abfrageintervall und WEB-Seite für die Globalstrahlung<br />
<pre><br />
attr Kostal GR.Interval 3600<br />
attr Kostal GR.Link http://www.proplanta.de/Wetter/Straubing-Wetter-Heute.html<br />
</pre><br />
Die passende URL für die Web-Seite am Standort lässt sich wie folgt ermitteln.<br />
(hier am Beispiel der Stadt Straubing)<br /><br />
Diese Seite anwählen<br />
http://www.proplanta.de/Agrar-Wetter/Deutschland/ <br /><br />
Postleitzahl eingeben: 94315<br /><br />
ggf. bei Auswahlbox rechts zusätzlich auswählen --> Button "Aufrufen"<br /><br />
<br /><br />
Am untersten Ende der nun aufgerufenen Seite findet sich der Link zu "Wetterrückbick Straubing" --> Click<br />
<br /><br />
<br />
Auf der nun erscheinenden Seite findet sich ebenfalls am unteren Ende:"Wetteraussichten Heute" - Click<br />
<br /><br />
Nun merken wir uns die URL der aktuellen Seite und tragen diesen beim Attribut GR.Link ein.<br /><br />
(im Beispiel: http://www.proplanta.de/Wetter/Straubing-Wetter-Heute.html)<br /><br /><br />
Auf dieser Seite wird das Modul nach dem Begriff "Globalstrahlung" suchen und den Wert extrahieren.<br />
<br />
* nun legen wir noch ein UserReading an um über die Globalstrahlung die erwartete Energie zu berechnen<br />
wir verwenden die Formel<br />
<pre> Expected Energy = <PV-Fläche> * GlobalStrahlung * Systemnutzungsgrad</pre><br />
und somit (mit PV-Fläche=37qm und Systemnutzungsgrad = 10%)<br /><br />
<pre><br />
attr Kostal userReadings EnergyExpected:Global.Radiation {return ReadingsVal ("Kostal","Global.Radiation",0)*37*0.10;;}<br />
</pre><br />
<br />
* FileLog für die Aktualwerte<br />
<pre><br />
define Kostal.File FileLog ./log/Kostal-%Y.log Kostal:(AC.Power:|Daily.Energy:|Daily.Energy.Last:|Total.Energy:|ModeNum:|EnergyExpected:).*<br />
attr Kostal.File logtype text<br />
</pre><br />
<br />
* eine passende Grafik über den Plot-Editor erstellen; der Plot-Editor ist über das FileLog-Objekt erreichbar.<br />
[[File:Kostal_filelog.png]]<br />
<br />
* folgende beispielhafte Werte einstellen<br />
[[File:Kostal_chartCreate.png]]<br />
<br />
* ein FileLog für die erzeugte Tages-Energie<br />
<pre><br />
define Kostal.File_2 FileLog ./log/Kostal_2-%Y.log Kostal:(Daily.Energy.Last:).*<br />
attr Kostal.File_2 logtype text<br />
</pre><br />
<br />
* eine passende Grafik über den Plot-Editor erstellen (Attribut fixedrange auf month setzen)<br />
[[File:Kostal_chartMCreate.png]]<br />
<br />
* Turbo-Modus für AC.Power.<br/><br />
AC.Power.Fast hat ja zunächst denselben Wert wie AC.Power.<br/><br />
Wer jedoch das schnelle Reading nutzen will setzt zunächst den Wert von Attribut delay runter z.B auf minütliche Abtastung. <br/><br />
Dann würde jedoch die LogDatei schnell anwachsen, was nicht jeder will.<br/><br />
Daher gibt es das Attribut delayCounter. <br />
Mit delayCounter=5 wird nur AC.Power.Fast minütlich abgetastet, alle anderen Readings werde mit 5 * 60 sec. =300 sec aktualisiert.<br />
<br />
== Fragen und Antworten ==<br />
==== Erfassung der Globalstrahlung ohne KostalPiko ====<br />
;Frage<br />
:Ich habe keinen KostalPiko, kann ich das Modul zur Erfassung der Globalstrahlung verwenden?<br />
;Antwort<br />
:Das ist möglich.<br />Hierzu alles wie im Kapitel Inbetriebnahme beschrieben parametrieren und zusätzlich das Attribut <code>disable 1</code> setzen.<br /> Damit wird KostalPiko nicht angesprochen, jedoch bei vorhandenen GR.* Attributen die Readings der Proplanta-Seite (u.a. eben auch die Globalstrahlung) dennoch erfasst.<br />
<br />
==== Erfassung der Globalstrahlung für den nächsten Tag ====<br />
;Frage<br />
:Kann das Modul zur Erfassung der Globalstrahlung des nächsten Tages verwendet werden?<br />
;Antwort<br />
:Das ist möglich. Dazu muss das Attribut GR.Link von <br /><code>http://www.proplanta.de/Wetter/<meineStadt>-Wetter-'''Heute'''.html <code><br />auf <br /><code>http://www.proplanta.de/Wetter/<meineStadt>-Wetter-'''Morgen'''.html </code> <br />geändert werden.<br />
<br />
== Links ==<br />
* Webseite des Herstellers [http://www.kostal-solar-electric.com Kostal]<br />
* Forenbeitrag zu diesem {{Link2Forum|Topic=24409}}<br />
<br />
[[Kategorie:Other Components]]<br />
[[Kategorie:Energieerzeugungsmessung]]</div>Johnhttp://wiki.fhem.de/w/index.php?title=KostalPiko&diff=8226KostalPiko2014-10-25T11:36:57Z<p>John: /* Readings */ Einheinten hinzugefügt</p>
<hr />
<div>{{Infobox Modul<br />
|ModPurpose=KostalPiko erfasst Informationen vom gleichnamigen Wechselrichter der Fa. Kostal; unabhängig davon kann das Modul auch dazu verwendet werden, die Globalstrahlung am Standort für den aktuellen oder nächsten Tag zu ermitteln.<br />
|ModType=d<br />
<!-- |ModCmdRef=LightScene -- nicht erforderlich, da Modultyp x --><br />
|ModForumArea=Codeschnipsel<br />
|ModTechName=23_KOSTALPIKO.pm<br />
|ModOwner=John ([http://forum.fhem.de/index.php?action=profile;u=806 Forum] / [[Benutzer Diskussion:John|Wiki]])}}<br />
Anbindung des Wechselrichters Piko der Fa. Kostal Solar Electric<br />
<br />
== Geräte Beschreibung ==<br />
Der Solar-Wechselrichter Piko der Fa. Kostal liefert über die Geräte-Webseite wichtige technische Informationen wie<br />
* aktuelle Leistung<br />
* Tages-Energie<br />
* Gesamt-Energie<br />
* Strom und Spannung der drei Input-Strings<br />
* Spannung und Leistung der drei Ausgangsphasen<br />
<br />
Das Gerät verfügt über eine Ethernet-Schnittstelle, über die die Webseite des Gerätes erreichbar ist.<br />
<br />
Aber ohne Wechselrichter kann das Modul hilfreich sein: es erfasst von der Seite<br />
:<code><nowiki>http://www.proplanta.de/Wetter/<meineStadt>-Wetter-Heute.html</nowiki></code><br />
bzw.<br />
:<code><nowiki>http://www.proplanta.de/Wetter/<meineStadt>-Wetter-Morgen.html</nowiki></code><br />
Wetterdaten für den heutigen bzw. für den nächsten Tag (siehe unter Readings, diejenigen, die mit "proplanta" gekennzeichnet sind).<br />
<br />
== FHEM-Modul ==<br />
Das Modul 23_KOSTALPIKO.pm übernimmt folgende Aufgaben:<br />
<br />
* Erfassen der Daten aus der Webseite von Piko<br />
* Erfassen der Erwartungswerte für Gobalstrahlung, UV-Index und Sonnenscheindauer von folgender Webseite [http://www.proplanta.de/Agrar-Wetter/Deutschland/]<br />
* über UserReadings kann der zu erwartenden Energieertrag ermittelt und mit der tatsächlich erzeugten Energiemenge verglichen werden.<br />
=== Define ===<br />
Definition des Geräts in der [[Konfiguration|fhem.cfg]]:<br />
:<code>define <name> KOSTALPIKO <ip-adresse-kostal> <user> <password> </code><br />
<br />
'''Beispiel:'''<br />
:<code>define <name> KOSTALPIKO 192.168.178.99 pvserver pvwr </code><br />
<br />
{| class="wikitable sortable"<br />
|-<br />
! Parameter !! Beschreibung<br />
|-<br />
|<name>||FHEM Name des Devices<br />
|-<br />
|<ip-adresse-kostal>||IP-Adresse von Kostal Piko<br />
|-<br />
|<user>||der User-Name für die Einwahl zur Kostal-Webseite<br />
|-<br />
|<password>||das Passwort für die Einwahl zur Kostal-Webseite<br />
|-<br />
|}<br />
<br />
=== Attribute ===<br />
{| class="wikitable sortable"<br />
|-<br />
! Parameter !! Wertebereich !! Default !! Beschreibung<br />
|-<br />
|GR.Interval||uint||3600||Intervall der Aktualisierung der Globalstrahlung in Sekunden<br />
|-<br />
|GR.Link||string||||Link auf die regionalisierte Seite von http://www.proplanta.de/Wetter/<city>-Wetter-Heute.html<br />
|-<br />
|delay||uint||60||Intervall in Sekunden zu Erfassung der Daten von Kostalpiko<br />
|-<br />
|delayCounter||uint||0||Counter bei Nutzung von AC.Power.Fast<br />
|-<br />
|disable||[0,1]||0||Erfassung von Kostalpiko-Daten ist gesperrt, nicht jedoch der Globalstrahlung<br />
|-<br />
|verbose||[0..5]||0||Log-Ausgabe steuern: 0=keine Ausgaben,5=viele Informationen<br />
|-<br />
|}<br />
<br />
=== Setter ===<br />
'''captureGlobalRadiation'''<br />
* Funktion: manuell die sofortige Erfassung der Werte der Proplanta-Seite anstossen<br />
<br />
'''captureKostalData'''<br />
* Funktion: manuell die sofortige Erfassung der Daten von KostalPiko anstossen<br />
<br />
=== Readings ===<br />
* AC.Power, die aktuelle erzeugte Leistung<br />
* AC.Power.Fast, die aktuell erzeugte Leistung im Schnelltast-Modus<br />
* Daily.Energy, die bisher erzeugte Tagesenergie<br />
* Daily.Energy.Last, die erzeugte Energie des letzten Tages, wird um 23:00 Uhr ermittelt.<br />
* Global.Radiation, die Globalstrahlung am gewählten Standort, damit die erwartete Tagesenergie berechnet werden (proplanta)<br />
* Mode, der Status von KostalPiko<br />
* ModeNum, die nummerische Zuordnung zum Status (0=Aus 1=Leerlauf 2=Einspeisen MPP)<br />
* Total.Energy, die erzeugte Gesamtenergie<br />
* generator.1.current, Strom an String 1 [A]<br />
* generator.1.voltage, Spannung an String 1 [V]<br />
* generator.2.current, Strom an String 2 [A]<br />
* generator.2.voltage, Spannung an String 2 [V]<br />
* generator.3.current, Strom an String 3 [A]<br />
* generator.3.voltage, Spannung an String 3 [V]<br />
* output.1.voltage, Spannung an L1 [V]<br />
* output.1.power, Leistung an L1 [W]<br />
* output.2.voltage, Spannung an L2 [V]<br />
* output.2.power, Leistung an L2 [W]<br />
* output.3.voltage, Spannung an L3 [V]<br />
* output.3.power, Leistung an L3 [W]<br />
* sensor.1, Spannung an 1. analogem Eingang [V]<br />
* sensor.2, Spannung an 2. analogem Eingang [V]<br />
* sensor.3, Spannung an 3. analogem Eingang [V]<br />
* sensor.4, Spannung an 4. analogem Eingang [V]<br />
* UV.Index, UV-Index (proplanta)<br />
* sunshine.duration, rel. Sonnenscheindauer [%] (proplanta)<br />
<br />
== Inbetriebnahme ==<br />
* KOSTALPIKO samt Abfrage-Intervall definieren<br />
<pre><br />
define Kostal KOSTALPIKO 192.168.178.99 pvserver pvwr<br />
attr Kostal delay 60<br />
</pre><br />
* Abfrageintervall und WEB-Seite für die Globalstrahlung<br />
<pre><br />
attr Kostal GR.Interval 3600<br />
attr Kostal GR.Link http://www.proplanta.de/Wetter/Straubing-Wetter-Heute.html<br />
</pre><br />
Die passende URL für die Web-Seite am Standort lässt sich wie folgt ermitteln.<br />
(hier am Beispiel der Stadt Straubing)<br /><br />
Diese Seite anwählen<br />
http://www.proplanta.de/Agrar-Wetter/Deutschland/ <br /><br />
Postleitzahl eingeben: 94315<br /><br />
ggf. bei Auswahlbox rechts zusätzlich auswählen --> Button "Aufrufen"<br /><br />
<br /><br />
Am untersten Ende der nun aufgerufenen Seite findet sich der Link zu "Wetterrückbick Straubing" --> Click<br />
<br /><br />
<br />
Auf der nun erscheinenden Seite findet sich ebenfalls am unteren Ende:"Wetteraussichten Heute" - Click<br />
<br /><br />
Nun merken wir uns die URL der aktuellen Seite und tragen diesen beim Attribut GR.Link ein.<br /><br />
(im Beispiel: http://www.proplanta.de/Wetter/Straubing-Wetter-Heute.html)<br /><br /><br />
Auf dieser Seite wird das Modul nach dem Begriff "Globalstrahlung" suchen und den Wert extrahieren.<br />
<br />
* nun legen wir noch ein UserReading an um über die Globalstrahlung die erwartete Energie zu berechnen<br />
wir verwenden die Formel<br />
<pre> Expected Energy = <PV-Fläche> * GlobalStrahlung * Systemnutzungsgrad</pre><br />
und somit (mit PV-Fläche=37qm und Systemnutzungsgrad = 10%)<br /><br />
<pre><br />
attr Kostal userReadings EnergyExpected:Global.Radiation {return ReadingsVal ("Kostal","Global.Radiation",0)*37*0.10;;}<br />
</pre><br />
<br />
* FileLog für die Aktualwerte<br />
<pre><br />
define Kostal.File FileLog ./log/Kostal-%Y.log Kostal:(AC.Power:|Daily.Energy:|Daily.Energy.Last:|Total.Energy:|ModeNum:|EnergyExpected:).*<br />
attr Kostal.File logtype text<br />
</pre><br />
<br />
* eine passende Grafik über den Plot-Editor erstellen; der Plot-Editor ist über das FileLog-Objekt erreichbar.<br />
[[File:Kostal_filelog.png]]<br />
<br />
* folgende beispielhafte Werte einstellen<br />
[[File:Kostal_chartCreate.png]]<br />
<br />
* ein FileLog für die erzeugte Tages-Energie<br />
<pre><br />
define Kostal.File_2 FileLog ./log/Kostal_2-%Y.log Kostal:(Daily.Energy.Last:).*<br />
attr Kostal.File_2 logtype text<br />
</pre><br />
<br />
* eine passende Grafik über den Plot-Editor erstellen (Attribut fixedrange auf month setzen)<br />
[[File:Kostal_chartMCreate.png]]<br />
<br />
* Turbo-Modus für AC.Power.<br/><br />
AC.Power.Fast hat ja zunächst denselben Wert wie AC.Power.<br/><br />
Wer jedoch das schnelle Reading nutzen will setzt zunächst den Wert von Attribut delay runter z.B auf minütliche Abtastung. <br/><br />
Dann würde jedoch die LogDatei schnell anwachsen, was nicht jeder will.<br/><br />
Daher gibt es das Attribut delayCounter. <br />
Mit delayCounter=5 wird nur AC.Power.Fast minütlich abgetastet, alle anderen Readings werde mit 5 * 60 sec. =300 sec aktualisiert.<br />
<br />
== Fragen und Antworten ==<br />
==== Erfassung der Globalstrahlung ohne KostalPiko ====<br />
;Frage<br />
:Ich habe keinen KostalPiko, kann ich das Modul zur Erfassung der Globalstrahlung verwenden?<br />
;Antwort<br />
:Ab Version 2.0 ist das möglich.<br />Hierzu alles wie im Kapitel Inbetriebnahme beschrieben parametrieren und zusätzlich das Attribut <code>disable 1</code> setzen.<br /> Damit wird KostalPiko nicht angesprochen, jedoch bei vorhandenen GR.* Attributen die Readings der Proplanta-Seite (u.a. eben auch die Globalstrahlung) dennoch erfasst.<br />
<br />
==== Erfassung der Globalstrahlung für den nächsten Tag ====<br />
;Frage<br />
:Kann das Modul zur Erfassung der Globalstrahlung des nächsten Tages verwendet werden?<br />
;Antwort<br />
:Das ist möglich. Dazu muss das Attribut GR.Link von <br /><code>http://www.proplanta.de/Wetter/<meineStadt>-Wetter-'''Heute'''.html <code><br />auf <br /><code>http://www.proplanta.de/Wetter/<meineStadt>-Wetter-'''Morgen'''.html </code> <br />geändert werden.<br />
<br />
== Links ==<br />
* Webseite des Herstellers [http://www.kostal-solar-electric.com Kostal]<br />
* Forenbeitrag zu diesem {{Link2Forum|Topic=24409}}<br />
<br />
[[Kategorie:Other Components]]<br />
[[Kategorie:Energieerzeugungsmessung]]</div>Johnhttp://wiki.fhem.de/w/index.php?title=KostalPiko&diff=8222KostalPiko2014-10-24T14:22:14Z<p>John: </p>
<hr />
<div>{{Infobox Modul<br />
|ModPurpose=KostalPiko erfasst Informationen vom gleichnamigen Wechselrichter der Fa. Kostal; unabhängig davon kann das Modul auch dazu verwendet werden, die Globalstrahlung am Standort für den aktuellen oder nächsten Tag zu ermitteln.<br />
|ModType=d<br />
<!-- |ModCmdRef=LightScene -- nicht erforderlich, da Modultyp x --><br />
|ModForumArea=Codeschnipsel<br />
|ModTechName=23_KOSTALPIKO.pm<br />
|ModOwner=John ([http://forum.fhem.de/index.php?action=profile;u=806 Forum] / [[Benutzer Diskussion:John|Wiki]])}}<br />
Anbindung des Wechselrichters Piko der Fa. Kostal Solar Electric<br />
<br />
== Geräte Beschreibung ==<br />
Der Solar-Wechselrichter Piko der Fa. Kostal liefert über die Geräte-Webseite wichtige technische Informationen wie<br />
* aktuelle Leistung<br />
* Tages-Energie<br />
* Gesamt-Energie<br />
* Strom und Spannung der drei Input-Strings<br />
* Spannung und Leistung der drei Ausgangsphasen<br />
<br />
Das Gerät verfügt über eine Ethernet-Schnittstelle, über die die Webseite des Gerätes erreichbar ist.<br />
<br />
Aber ohne Wechselrichter kann das Modul hilfreich sein: es erfasst von der Seite<br />
:<code><nowiki>http://www.proplanta.de/Wetter/<meineStadt>-Wetter-Heute.html</nowiki></code><br />
bzw.<br />
:<code><nowiki>http://www.proplanta.de/Wetter/<meineStadt>-Wetter-Morgen.html</nowiki></code><br />
Wetterdaten für den heutigen bzw. für den nächsten Tag (siehe unter Readings, diejenigen, die mit "proplanta" gekennzeichnet sind).<br />
<br />
== FHEM-Modul ==<br />
Das Modul 23_KOSTALPIKO.pm übernimmt folgende Aufgaben:<br />
<br />
* Erfassen der Daten aus der Webseite von Piko<br />
* Erfassen der Erwartungswerte für Gobalstrahlung, UV-Index und Sonnenscheindauer von folgender Webseite [http://www.proplanta.de/Agrar-Wetter/Deutschland/]<br />
* über UserReadings kann der zu erwartenden Energieertrag ermittelt und mit der tatsächlich erzeugten Energiemenge verglichen werden.<br />
=== Define ===<br />
Definition des Geräts in der [[Konfiguration|fhem.cfg]]:<br />
:<code>define <name> KOSTALPIKO <ip-adresse-kostal> <user> <password> </code><br />
<br />
'''Beispiel:'''<br />
:<code>define <name> KOSTALPIKO 192.168.178.99 pvserver pvwr </code><br />
<br />
{| class="wikitable sortable"<br />
|-<br />
! Parameter !! Beschreibung<br />
|-<br />
|<name>||FHEM Name des Devices<br />
|-<br />
|<ip-adresse-kostal>||IP-Adresse von Kostal Piko<br />
|-<br />
|<user>||der User-Name für die Einwahl zur Kostal-Webseite<br />
|-<br />
|<password>||das Passwort für die Einwahl zur Kostal-Webseite<br />
|-<br />
|}<br />
<br />
=== Attribute ===<br />
{| class="wikitable sortable"<br />
|-<br />
! Parameter !! Wertebereich !! Default !! Beschreibung<br />
|-<br />
|GR.Interval||uint||3600||Intervall der Aktualisierung der Globalstrahlung in Sekunden<br />
|-<br />
|GR.Link||string||||Link auf die regionalisierte Seite von http://www.proplanta.de/Wetter/<city>-Wetter-Heute.html<br />
|-<br />
|delay||uint||60||Intervall in Sekunden zu Erfassung der Daten von Kostalpiko<br />
|-<br />
|delayCounter||uint||0||Counter bei Nutzung von AC.Power.Fast<br />
|-<br />
|disable||[0,1]||0||Erfassung von Kostalpiko-Daten ist gesperrt, nicht jedoch der Globalstrahlung<br />
|-<br />
|verbose||[0..5]||0||Log-Ausgabe steuern: 0=keine Ausgaben,5=viele Informationen<br />
|-<br />
|}<br />
<br />
=== Setter ===<br />
'''captureGlobalRadiation'''<br />
* Funktion: manuell die sofortige Erfassung der Werte der Proplanta-Seite anstossen<br />
<br />
'''captureKostalData'''<br />
* Funktion: manuell die sofortige Erfassung der Daten von KostalPiko anstossen<br />
<br />
=== Readings ===<br />
* AC.Power, die aktuelle erzeugte Leistung<br />
* AC.Power.Fast, die aktuell erzeugte Leistung im Schnelltast-Modus<br />
* Daily.Energy, die bisher erzeugte Tagesenergie<br />
* Daily.Energy.Last, die erzeugte Energie des letzten Tages, wird um 23:00 Uhr ermittelt.<br />
* Global.Radiation, die Globalstrahlung am gewählten Standort, damit die erwartete Tagesenergie berechnet werden (proplanta)<br />
* Mode, der Status von KostalPiko<br />
* ModeNum, die nummerische Zuordnung zum Status (0=Aus 1=Leerlauf 2=Einspeisen MPP)<br />
* Total.Energy, die erzeugte Gesamtenergie<br />
* generator.1.current, Strom an String 1<br />
* generator.1.voltage, Spannung an String 1<br />
* generator.2.current, Strom an String 2<br />
* generator.2.voltage, Spannung an String 2<br />
* generator.3.current, Strom an String 3<br />
* generator.3.voltage, Spannung an String 3<br />
* output.1.voltage, Spannung an L1<br />
* output.1.power, Leistung an L1<br />
* output.2.voltage, Spannung an L2<br />
* output.2.power, Leistung an L2<br />
* output.3.voltage, Spannung an L3<br />
* output.3.power, Leistung an L3<br />
* sensor.1, Spannung an 1. analogem Eingang<br />
* sensor.2, Spannung an 2. analogem Eingang<br />
* sensor.3, Spannung an 3. analogem Eingang<br />
* sensor.4, Spannung an 4. analogem Eingang<br />
* UV.Index, UV-Index (proplanta)<br />
* sunshine.duration, rel. Sonnenscheindauer (proplanta)<br />
<br />
== Inbetriebnahme ==<br />
* KOSTALPIKO samt Abfrage-Intervall definieren<br />
<pre><br />
define Kostal KOSTALPIKO 192.168.178.99 pvserver pvwr<br />
attr Kostal delay 60<br />
</pre><br />
* Abfrageintervall und WEB-Seite für die Globalstrahlung<br />
<pre><br />
attr Kostal GR.Interval 3600<br />
attr Kostal GR.Link http://www.proplanta.de/Wetter/Straubing-Wetter-Heute.html<br />
</pre><br />
Die passende URL für die Web-Seite am Standort lässt sich wie folgt ermitteln.<br />
(hier am Beispiel der Stadt Straubing)<br /><br />
Diese Seite anwählen<br />
http://www.proplanta.de/Agrar-Wetter/Deutschland/ <br /><br />
Postleitzahl eingeben: 94315<br /><br />
ggf. bei Auswahlbox rechts zusätzlich auswählen --> Button "Aufrufen"<br /><br />
<br /><br />
Am untersten Ende der nun aufgerufenen Seite findet sich der Link zu "Wetterrückbick Straubing" --> Click<br />
<br /><br />
<br />
Auf der nun erscheinenden Seite findet sich ebenfalls am unteren Ende:"Wetteraussichten Heute" - Click<br />
<br /><br />
Nun merken wir uns die URL der aktuellen Seite und tragen diesen beim Attribut GR.Link ein.<br /><br />
(im Beispiel: http://www.proplanta.de/Wetter/Straubing-Wetter-Heute.html)<br /><br /><br />
Auf dieser Seite wird das Modul nach dem Begriff "Globalstrahlung" suchen und den Wert extrahieren.<br />
<br />
* nun legen wir noch ein UserReading an um über die Globalstrahlung die erwartete Energie zu berechnen<br />
wir verwenden die Formel<br />
<pre> Expected Energy = <PV-Fläche> * GlobalStrahlung * Systemnutzungsgrad</pre><br />
und somit (mit PV-Fläche=37qm und Systemnutzungsgrad = 10%)<br /><br />
<pre><br />
attr Kostal userReadings EnergyExpected:Global.Radiation {return ReadingsVal ("Kostal","Global.Radiation",0)*37*0.10;;}<br />
</pre><br />
<br />
* FileLog für die Aktualwerte<br />
<pre><br />
define Kostal.File FileLog ./log/Kostal-%Y.log Kostal:(AC.Power:|Daily.Energy:|Daily.Energy.Last:|Total.Energy:|ModeNum:|EnergyExpected:).*<br />
attr Kostal.File logtype text<br />
</pre><br />
<br />
* eine passende Grafik über den Plot-Editor erstellen; der Plot-Editor ist über das FileLog-Objekt erreichbar.<br />
[[File:Kostal_filelog.png]]<br />
<br />
* folgende beispielhafte Werte einstellen<br />
[[File:Kostal_chartCreate.png]]<br />
<br />
* ein FileLog für die erzeugte Tages-Energie<br />
<pre><br />
define Kostal.File_2 FileLog ./log/Kostal_2-%Y.log Kostal:(Daily.Energy.Last:).*<br />
attr Kostal.File_2 logtype text<br />
</pre><br />
<br />
* eine passende Grafik über den Plot-Editor erstellen (Attribut fixedrange auf month setzen)<br />
[[File:Kostal_chartMCreate.png]]<br />
<br />
* Turbo-Modus für AC.Power.<br/><br />
AC.Power.Fast hat ja zunächst denselben Wert wie AC.Power.<br/><br />
Wer jedoch das schnelle Reading nutzen will setzt zunächst den Wert von Attribut delay runter z.B auf minütliche Abtastung. <br/><br />
Dann würde jedoch die LogDatei schnell anwachsen, was nicht jeder will.<br/><br />
Daher gibt es das Attribut delayCounter. <br />
Mit delayCounter=5 wird nur AC.Power.Fast minütlich abgetastet, alle anderen Readings werde mit 5 * 60 sec. =300 sec aktualisiert.<br />
<br />
== Fragen und Antworten ==<br />
==== Erfassung der Globalstrahlung ohne KostalPiko ====<br />
;Frage<br />
:Ich habe keinen KostalPiko, kann ich das Modul zur Erfassung der Globalstrahlung verwenden?<br />
;Antwort<br />
:Ab Version 2.0 ist das möglich.<br />Hierzu alles wie im Kapitel Inbetriebnahme beschrieben parametrieren und zusätzlich das Attribut <code>disable 1</code> setzen.<br /> Damit wird KostalPiko nicht angesprochen, jedoch bei vorhandenen GR.* Attributen die Readings der Proplanta-Seite (u.a. eben auch die Globalstrahlung) dennoch erfasst.<br />
<br />
==== Erfassung der Globalstrahlung für den nächsten Tag ====<br />
;Frage<br />
:Kann das Modul zur Erfassung der Globalstrahlung des nächsten Tages verwendet werden?<br />
;Antwort<br />
:Das ist möglich. Dazu muss das Attribut GR.Link von <br /><code>http://www.proplanta.de/Wetter/<meineStadt>-Wetter-'''Heute'''.html <code><br />auf <br /><code>http://www.proplanta.de/Wetter/<meineStadt>-Wetter-'''Morgen'''.html </code> <br />geändert werden.<br />
<br />
== Links ==<br />
* Webseite des Herstellers [http://www.kostal-solar-electric.com Kostal]<br />
* Forenbeitrag zu diesem {{Link2Forum|Topic=24409}}<br />
<br />
[[Kategorie:Other Components]]<br />
[[Kategorie:Energieerzeugungsmessung]]</div>Johnhttp://wiki.fhem.de/w/index.php?title=KostalPiko&diff=8221KostalPiko2014-10-24T14:19:51Z<p>John: /* Links */</p>
<hr />
<div>{{Infobox Modul<br />
|ModPurpose=KostalPiko erfasst Informationen vom gleichnamigen Wechselrichter der Fa. Kostal; unabhängig davon kann das Modul auch dazu verwendet werden, die Globalstrahlung am Standort für den aktuellen oder nächsten Tag zu ermitteln.<br />
|ModType=x<br />
<!-- |ModCmdRef=LightScene -- nicht erforderlich, da Modultyp x --><br />
|ModForumArea=Codeschnipsel<br />
|ModTechName=23_KOSTALPIKO.pm<br />
|ModOwner=John ([http://forum.fhem.de/index.php?action=profile;u=806 Forum] / [[Benutzer Diskussion:John|Wiki]])}}<br />
Anbindung des Wechselrichters Piko der Fa. Kostal Solar Electric<br />
<br />
== Geräte Beschreibung ==<br />
Der Solar-Wechselrichter Piko der Fa. Kostal liefert über die Geräte-Webseite wichtige technische Informationen wie<br />
* aktuelle Leistung<br />
* Tages-Energie<br />
* Gesamt-Energie<br />
* Strom und Spannung der drei Input-Strings<br />
* Spannung und Leistung der drei Ausgangsphasen<br />
<br />
Das Gerät verfügt über eine Ethernet-Schnittstelle, über die die Webseite des Gerätes erreichbar ist.<br />
<br />
Aber ohne Wechselrichter kann das Modul hilfreich sein: es erfasst von der Seite<br />
:<code><nowiki>http://www.proplanta.de/Wetter/<meineStadt>-Wetter-Heute.html</nowiki></code><br />
bzw.<br />
:<code><nowiki>http://www.proplanta.de/Wetter/<meineStadt>-Wetter-Morgen.html</nowiki></code><br />
Wetterdaten für den heutigen bzw. für den nächsten Tag (siehe unter Readings, diejenigen, die mit "proplanta" gekennzeichnet sind).<br />
<br />
== FHEM-Modul ==<br />
Das Modul 23_KOSTALPIKO.pm übernimmt folgende Aufgaben:<br />
<br />
* Erfassen der Daten aus der Webseite von Piko<br />
* Erfassen der Erwartungswerte für Gobalstrahlung, UV-Index und Sonnenscheindauer von folgender Webseite [http://www.proplanta.de/Agrar-Wetter/Deutschland/]<br />
* über UserReadings kann der zu erwartenden Energieertrag ermittelt und mit der tatsächlich erzeugten Energiemenge verglichen werden.<br />
=== Define ===<br />
Definition des Geräts in der [[Konfiguration|fhem.cfg]]:<br />
:<code>define <name> KOSTALPIKO <ip-adresse-kostal> <user> <password> </code><br />
<br />
'''Beispiel:'''<br />
:<code>define <name> KOSTALPIKO 192.168.178.99 pvserver pvwr </code><br />
<br />
{| class="wikitable sortable"<br />
|-<br />
! Parameter !! Beschreibung<br />
|-<br />
|<name>||FHEM Name des Devices<br />
|-<br />
|<ip-adresse-kostal>||IP-Adresse von Kostal Piko<br />
|-<br />
|<user>||der User-Name für die Einwahl zur Kostal-Webseite<br />
|-<br />
|<password>||das Passwort für die Einwahl zur Kostal-Webseite<br />
|-<br />
|}<br />
<br />
=== Attribute ===<br />
{| class="wikitable sortable"<br />
|-<br />
! Parameter !! Wertebereich !! Default !! Beschreibung<br />
|-<br />
|GR.Interval||uint||3600||Intervall der Aktualisierung der Globalstrahlung in Sekunden<br />
|-<br />
|GR.Link||string||||Link auf die regionalisierte Seite von http://www.proplanta.de/Wetter/<city>-Wetter-Heute.html<br />
|-<br />
|delay||uint||60||Intervall in Sekunden zu Erfassung der Daten von Kostalpiko<br />
|-<br />
|delayCounter||uint||0||Counter bei Nutzung von AC.Power.Fast<br />
|-<br />
|disable||[0,1]||0||Erfassung von Kostalpiko-Daten ist gesperrt, nicht jedoch der Globalstrahlung<br />
|-<br />
|verbose||[0..5]||0||Log-Ausgabe steuern: 0=keine Ausgaben,5=viele Informationen<br />
|-<br />
|}<br />
<br />
=== Setter ===<br />
'''captureGlobalRadiation'''<br />
* Funktion: manuell die sofortige Erfassung der Werte der Proplanta-Seite anstossen<br />
<br />
'''captureKostalData'''<br />
* Funktion: manuell die sofortige Erfassung der Daten von KostalPiko anstossen<br />
<br />
=== Readings ===<br />
* AC.Power, die aktuelle erzeugte Leistung<br />
* AC.Power.Fast, die aktuell erzeugte Leistung im Schnelltast-Modus<br />
* Daily.Energy, die bisher erzeugte Tagesenergie<br />
* Daily.Energy.Last, die erzeugte Energie des letzten Tages, wird um 23:00 Uhr ermittelt.<br />
* Global.Radiation, die Globalstrahlung am gewählten Standort, damit die erwartete Tagesenergie berechnet werden (proplanta)<br />
* Mode, der Status von KostalPiko<br />
* ModeNum, die nummerische Zuordnung zum Status (0=Aus 1=Leerlauf 2=Einspeisen MPP)<br />
* Total.Energy, die erzeugte Gesamtenergie<br />
* generator.1.current, Strom an String 1<br />
* generator.1.voltage, Spannung an String 1<br />
* generator.2.current, Strom an String 2<br />
* generator.2.voltage, Spannung an String 2<br />
* generator.3.current, Strom an String 3<br />
* generator.3.voltage, Spannung an String 3<br />
* output.1.voltage, Spannung an L1<br />
* output.1.power, Leistung an L1<br />
* output.2.voltage, Spannung an L2<br />
* output.2.power, Leistung an L2<br />
* output.3.voltage, Spannung an L3<br />
* output.3.power, Leistung an L3<br />
* sensor.1, Spannung an 1. analogem Eingang<br />
* sensor.2, Spannung an 2. analogem Eingang<br />
* sensor.3, Spannung an 3. analogem Eingang<br />
* sensor.4, Spannung an 4. analogem Eingang<br />
* UV.Index, UV-Index (proplanta)<br />
* sunshine.duration, rel. Sonnenscheindauer (proplanta)<br />
<br />
== Inbetriebnahme ==<br />
* KOSTALPIKO samt Abfrage-Intervall definieren<br />
<pre><br />
define Kostal KOSTALPIKO 192.168.178.99 pvserver pvwr<br />
attr Kostal delay 60<br />
</pre><br />
* Abfrageintervall und WEB-Seite für die Globalstrahlung<br />
<pre><br />
attr Kostal GR.Interval 3600<br />
attr Kostal GR.Link http://www.proplanta.de/Wetter/Straubing-Wetter-Heute.html<br />
</pre><br />
Die passende URL für die Web-Seite am Standort lässt sich wie folgt ermitteln.<br />
(hier am Beispiel der Stadt Straubing)<br /><br />
Diese Seite anwählen<br />
http://www.proplanta.de/Agrar-Wetter/Deutschland/ <br /><br />
Postleitzahl eingeben: 94315<br /><br />
ggf. bei Auswahlbox rechts zusätzlich auswählen --> Button "Aufrufen"<br /><br />
<br /><br />
Am untersten Ende der nun aufgerufenen Seite findet sich der Link zu "Wetterrückbick Straubing" --> Click<br />
<br /><br />
<br />
Auf der nun erscheinenden Seite findet sich ebenfalls am unteren Ende:"Wetteraussichten Heute" - Click<br />
<br /><br />
Nun merken wir uns die URL der aktuellen Seite und tragen diesen beim Attribut GR.Link ein.<br /><br />
(im Beispiel: http://www.proplanta.de/Wetter/Straubing-Wetter-Heute.html)<br /><br /><br />
Auf dieser Seite wird das Modul nach dem Begriff "Globalstrahlung" suchen und den Wert extrahieren.<br />
<br />
* nun legen wir noch ein UserReading an um über die Globalstrahlung die erwartete Energie zu berechnen<br />
wir verwenden die Formel<br />
<pre> Expected Energy = <PV-Fläche> * GlobalStrahlung * Systemnutzungsgrad</pre><br />
und somit (mit PV-Fläche=37qm und Systemnutzungsgrad = 10%)<br /><br />
<pre><br />
attr Kostal userReadings EnergyExpected:Global.Radiation {return ReadingsVal ("Kostal","Global.Radiation",0)*37*0.10;;}<br />
</pre><br />
<br />
* FileLog für die Aktualwerte<br />
<pre><br />
define Kostal.File FileLog ./log/Kostal-%Y.log Kostal:(AC.Power:|Daily.Energy:|Daily.Energy.Last:|Total.Energy:|ModeNum:|EnergyExpected:).*<br />
attr Kostal.File logtype text<br />
</pre><br />
<br />
* eine passende Grafik über den Plot-Editor erstellen; der Plot-Editor ist über das FileLog-Objekt erreichbar.<br />
[[File:Kostal_filelog.png]]<br />
<br />
* folgende beispielhafte Werte einstellen<br />
[[File:Kostal_chartCreate.png]]<br />
<br />
* ein FileLog für die erzeugte Tages-Energie<br />
<pre><br />
define Kostal.File_2 FileLog ./log/Kostal_2-%Y.log Kostal:(Daily.Energy.Last:).*<br />
attr Kostal.File_2 logtype text<br />
</pre><br />
<br />
* eine passende Grafik über den Plot-Editor erstellen (Attribut fixedrange auf month setzen)<br />
[[File:Kostal_chartMCreate.png]]<br />
<br />
* Turbo-Modus für AC.Power.<br/><br />
AC.Power.Fast hat ja zunächst denselben Wert wie AC.Power.<br/><br />
Wer jedoch das schnelle Reading nutzen will setzt zunächst den Wert von Attribut delay runter z.B auf minütliche Abtastung. <br/><br />
Dann würde jedoch die LogDatei schnell anwachsen, was nicht jeder will.<br/><br />
Daher gibt es das Attribut delayCounter. <br />
Mit delayCounter=5 wird nur AC.Power.Fast minütlich abgetastet, alle anderen Readings werde mit 5 * 60 sec. =300 sec aktualisiert.<br />
<br />
== Fragen und Antworten ==<br />
==== Erfassung der Globalstrahlung ohne KostalPiko ====<br />
;Frage<br />
:Ich habe keinen KostalPiko, kann ich das Modul zur Erfassung der Globalstrahlung verwenden?<br />
;Antwort<br />
:Ab Version 2.0 ist das möglich.<br />Hierzu alles wie im Kapitel Inbetriebnahme beschrieben parametrieren und zusätzlich das Attribut <code>disable 1</code> setzen.<br /> Damit wird KostalPiko nicht angesprochen, jedoch bei vorhandenen GR.* Attributen die Readings der Proplanta-Seite (u.a. eben auch die Globalstrahlung) dennoch erfasst.<br />
<br />
==== Erfassung der Globalstrahlung für den nächsten Tag ====<br />
;Frage<br />
:Kann das Modul zur Erfassung der Globalstrahlung des nächsten Tages verwendet werden?<br />
;Antwort<br />
:Das ist möglich. Dazu muss das Attribut GR.Link von <br /><code>http://www.proplanta.de/Wetter/<meineStadt>-Wetter-'''Heute'''.html <code><br />auf <br /><code>http://www.proplanta.de/Wetter/<meineStadt>-Wetter-'''Morgen'''.html </code> <br />geändert werden.<br />
<br />
== Links ==<br />
* Webseite des Herstellers [http://www.kostal-solar-electric.com Kostal]<br />
* Forenbeitrag zu diesem {{Link2Forum|Topic=24409}}<br />
<br />
[[Kategorie:Other Components]]<br />
[[Kategorie:Energieerzeugungsmessung]]</div>Johnhttp://wiki.fhem.de/w/index.php?title=KostalPiko&diff=8220KostalPiko2014-10-24T14:17:03Z<p>John: /* Beispielhafte Darstellung */</p>
<hr />
<div>{{Infobox Modul<br />
|ModPurpose=KostalPiko erfasst Informationen vom gleichnamigen Wechselrichter der Fa. Kostal; unabhängig davon kann das Modul auch dazu verwendet werden, die Globalstrahlung am Standort für den aktuellen oder nächsten Tag zu ermitteln.<br />
|ModType=x<br />
<!-- |ModCmdRef=LightScene -- nicht erforderlich, da Modultyp x --><br />
|ModForumArea=Codeschnipsel<br />
|ModTechName=23_KOSTALPIKO.pm<br />
|ModOwner=John ([http://forum.fhem.de/index.php?action=profile;u=806 Forum] / [[Benutzer Diskussion:John|Wiki]])}}<br />
Anbindung des Wechselrichters Piko der Fa. Kostal Solar Electric<br />
<br />
== Geräte Beschreibung ==<br />
Der Solar-Wechselrichter Piko der Fa. Kostal liefert über die Geräte-Webseite wichtige technische Informationen wie<br />
* aktuelle Leistung<br />
* Tages-Energie<br />
* Gesamt-Energie<br />
* Strom und Spannung der drei Input-Strings<br />
* Spannung und Leistung der drei Ausgangsphasen<br />
<br />
Das Gerät verfügt über eine Ethernet-Schnittstelle, über die die Webseite des Gerätes erreichbar ist.<br />
<br />
Aber ohne Wechselrichter kann das Modul hilfreich sein: es erfasst von der Seite<br />
:<code><nowiki>http://www.proplanta.de/Wetter/<meineStadt>-Wetter-Heute.html</nowiki></code><br />
bzw.<br />
:<code><nowiki>http://www.proplanta.de/Wetter/<meineStadt>-Wetter-Morgen.html</nowiki></code><br />
Wetterdaten für den heutigen bzw. für den nächsten Tag (siehe unter Readings, diejenigen, die mit "proplanta" gekennzeichnet sind).<br />
<br />
== FHEM-Modul ==<br />
Das Modul 23_KOSTALPIKO.pm übernimmt folgende Aufgaben:<br />
<br />
* Erfassen der Daten aus der Webseite von Piko<br />
* Erfassen der Erwartungswerte für Gobalstrahlung, UV-Index und Sonnenscheindauer von folgender Webseite [http://www.proplanta.de/Agrar-Wetter/Deutschland/]<br />
* über UserReadings kann der zu erwartenden Energieertrag ermittelt und mit der tatsächlich erzeugten Energiemenge verglichen werden.<br />
=== Define ===<br />
Definition des Geräts in der [[Konfiguration|fhem.cfg]]:<br />
:<code>define <name> KOSTALPIKO <ip-adresse-kostal> <user> <password> </code><br />
<br />
'''Beispiel:'''<br />
:<code>define <name> KOSTALPIKO 192.168.178.99 pvserver pvwr </code><br />
<br />
{| class="wikitable sortable"<br />
|-<br />
! Parameter !! Beschreibung<br />
|-<br />
|<name>||FHEM Name des Devices<br />
|-<br />
|<ip-adresse-kostal>||IP-Adresse von Kostal Piko<br />
|-<br />
|<user>||der User-Name für die Einwahl zur Kostal-Webseite<br />
|-<br />
|<password>||das Passwort für die Einwahl zur Kostal-Webseite<br />
|-<br />
|}<br />
<br />
=== Attribute ===<br />
{| class="wikitable sortable"<br />
|-<br />
! Parameter !! Wertebereich !! Default !! Beschreibung<br />
|-<br />
|GR.Interval||uint||3600||Intervall der Aktualisierung der Globalstrahlung in Sekunden<br />
|-<br />
|GR.Link||string||||Link auf die regionalisierte Seite von http://www.proplanta.de/Wetter/<city>-Wetter-Heute.html<br />
|-<br />
|delay||uint||60||Intervall in Sekunden zu Erfassung der Daten von Kostalpiko<br />
|-<br />
|delayCounter||uint||0||Counter bei Nutzung von AC.Power.Fast<br />
|-<br />
|disable||[0,1]||0||Erfassung von Kostalpiko-Daten ist gesperrt, nicht jedoch der Globalstrahlung<br />
|-<br />
|verbose||[0..5]||0||Log-Ausgabe steuern: 0=keine Ausgaben,5=viele Informationen<br />
|-<br />
|}<br />
<br />
=== Setter ===<br />
'''captureGlobalRadiation'''<br />
* Funktion: manuell die sofortige Erfassung der Werte der Proplanta-Seite anstossen<br />
<br />
'''captureKostalData'''<br />
* Funktion: manuell die sofortige Erfassung der Daten von KostalPiko anstossen<br />
<br />
=== Readings ===<br />
* AC.Power, die aktuelle erzeugte Leistung<br />
* AC.Power.Fast, die aktuell erzeugte Leistung im Schnelltast-Modus<br />
* Daily.Energy, die bisher erzeugte Tagesenergie<br />
* Daily.Energy.Last, die erzeugte Energie des letzten Tages, wird um 23:00 Uhr ermittelt.<br />
* Global.Radiation, die Globalstrahlung am gewählten Standort, damit die erwartete Tagesenergie berechnet werden (proplanta)<br />
* Mode, der Status von KostalPiko<br />
* ModeNum, die nummerische Zuordnung zum Status (0=Aus 1=Leerlauf 2=Einspeisen MPP)<br />
* Total.Energy, die erzeugte Gesamtenergie<br />
* generator.1.current, Strom an String 1<br />
* generator.1.voltage, Spannung an String 1<br />
* generator.2.current, Strom an String 2<br />
* generator.2.voltage, Spannung an String 2<br />
* generator.3.current, Strom an String 3<br />
* generator.3.voltage, Spannung an String 3<br />
* output.1.voltage, Spannung an L1<br />
* output.1.power, Leistung an L1<br />
* output.2.voltage, Spannung an L2<br />
* output.2.power, Leistung an L2<br />
* output.3.voltage, Spannung an L3<br />
* output.3.power, Leistung an L3<br />
* sensor.1, Spannung an 1. analogem Eingang<br />
* sensor.2, Spannung an 2. analogem Eingang<br />
* sensor.3, Spannung an 3. analogem Eingang<br />
* sensor.4, Spannung an 4. analogem Eingang<br />
* UV.Index, UV-Index (proplanta)<br />
* sunshine.duration, rel. Sonnenscheindauer (proplanta)<br />
<br />
== Inbetriebnahme ==<br />
* KOSTALPIKO samt Abfrage-Intervall definieren<br />
<pre><br />
define Kostal KOSTALPIKO 192.168.178.99 pvserver pvwr<br />
attr Kostal delay 60<br />
</pre><br />
* Abfrageintervall und WEB-Seite für die Globalstrahlung<br />
<pre><br />
attr Kostal GR.Interval 3600<br />
attr Kostal GR.Link http://www.proplanta.de/Wetter/Straubing-Wetter-Heute.html<br />
</pre><br />
Die passende URL für die Web-Seite am Standort lässt sich wie folgt ermitteln.<br />
(hier am Beispiel der Stadt Straubing)<br /><br />
Diese Seite anwählen<br />
http://www.proplanta.de/Agrar-Wetter/Deutschland/ <br /><br />
Postleitzahl eingeben: 94315<br /><br />
ggf. bei Auswahlbox rechts zusätzlich auswählen --> Button "Aufrufen"<br /><br />
<br /><br />
Am untersten Ende der nun aufgerufenen Seite findet sich der Link zu "Wetterrückbick Straubing" --> Click<br />
<br /><br />
<br />
Auf der nun erscheinenden Seite findet sich ebenfalls am unteren Ende:"Wetteraussichten Heute" - Click<br />
<br /><br />
Nun merken wir uns die URL der aktuellen Seite und tragen diesen beim Attribut GR.Link ein.<br /><br />
(im Beispiel: http://www.proplanta.de/Wetter/Straubing-Wetter-Heute.html)<br /><br /><br />
Auf dieser Seite wird das Modul nach dem Begriff "Globalstrahlung" suchen und den Wert extrahieren.<br />
<br />
* nun legen wir noch ein UserReading an um über die Globalstrahlung die erwartete Energie zu berechnen<br />
wir verwenden die Formel<br />
<pre> Expected Energy = <PV-Fläche> * GlobalStrahlung * Systemnutzungsgrad</pre><br />
und somit (mit PV-Fläche=37qm und Systemnutzungsgrad = 10%)<br /><br />
<pre><br />
attr Kostal userReadings EnergyExpected:Global.Radiation {return ReadingsVal ("Kostal","Global.Radiation",0)*37*0.10;;}<br />
</pre><br />
<br />
* FileLog für die Aktualwerte<br />
<pre><br />
define Kostal.File FileLog ./log/Kostal-%Y.log Kostal:(AC.Power:|Daily.Energy:|Daily.Energy.Last:|Total.Energy:|ModeNum:|EnergyExpected:).*<br />
attr Kostal.File logtype text<br />
</pre><br />
<br />
* eine passende Grafik über den Plot-Editor erstellen; der Plot-Editor ist über das FileLog-Objekt erreichbar.<br />
[[File:Kostal_filelog.png]]<br />
<br />
* folgende beispielhafte Werte einstellen<br />
[[File:Kostal_chartCreate.png]]<br />
<br />
* ein FileLog für die erzeugte Tages-Energie<br />
<pre><br />
define Kostal.File_2 FileLog ./log/Kostal_2-%Y.log Kostal:(Daily.Energy.Last:).*<br />
attr Kostal.File_2 logtype text<br />
</pre><br />
<br />
* eine passende Grafik über den Plot-Editor erstellen (Attribut fixedrange auf month setzen)<br />
[[File:Kostal_chartMCreate.png]]<br />
<br />
* Turbo-Modus für AC.Power.<br/><br />
AC.Power.Fast hat ja zunächst denselben Wert wie AC.Power.<br/><br />
Wer jedoch das schnelle Reading nutzen will setzt zunächst den Wert von Attribut delay runter z.B auf minütliche Abtastung. <br/><br />
Dann würde jedoch die LogDatei schnell anwachsen, was nicht jeder will.<br/><br />
Daher gibt es das Attribut delayCounter. <br />
Mit delayCounter=5 wird nur AC.Power.Fast minütlich abgetastet, alle anderen Readings werde mit 5 * 60 sec. =300 sec aktualisiert.<br />
<br />
== Fragen und Antworten ==<br />
==== Erfassung der Globalstrahlung ohne KostalPiko ====<br />
;Frage<br />
:Ich habe keinen KostalPiko, kann ich das Modul zur Erfassung der Globalstrahlung verwenden?<br />
;Antwort<br />
:Ab Version 2.0 ist das möglich.<br />Hierzu alles wie im Kapitel Inbetriebnahme beschrieben parametrieren und zusätzlich das Attribut <code>disable 1</code> setzen.<br /> Damit wird KostalPiko nicht angesprochen, jedoch bei vorhandenen GR.* Attributen die Readings der Proplanta-Seite (u.a. eben auch die Globalstrahlung) dennoch erfasst.<br />
<br />
==== Erfassung der Globalstrahlung für den nächsten Tag ====<br />
;Frage<br />
:Kann das Modul zur Erfassung der Globalstrahlung des nächsten Tages verwendet werden?<br />
;Antwort<br />
:Das ist möglich. Dazu muss das Attribut GR.Link von <br /><code>http://www.proplanta.de/Wetter/<meineStadt>-Wetter-'''Heute'''.html <code><br />auf <br /><code>http://www.proplanta.de/Wetter/<meineStadt>-Wetter-'''Morgen'''.html </code> <br />geändert werden.<br />
<br />
== Links ==<br />
* Webseite des Herstellers [http://www.kostal-solar-electric.com Kostal]<br />
* Forenbeitrag zu diesem {{Link2Forum|Topic=13508}}<br />
<br />
[[Kategorie:Other Components]]<br />
[[Kategorie:Energieerzeugungsmessung]]</div>John