Grundsätzliche Überlegungen zum Einsatz von FHEM beim Max! System

[fermoll]

Meine Erfahrungen mit der Max! Steuerung der letzten Tage und einige Stränge , die sich mit dem gleichen Problem beschäftigen:
http://forum.fhem.de/index.php/topic,19669.15.html
http://forum.fhem.de/index.php/topic,33892.0.html

haben mich bewogen, dieses Thema zu beginnen.

1.  Ich benutze in meinem 3 Familienhaus das Max! System seit ca. 2011. Zuerst mit einem Cube , 14 HT's und 8 HT+. Da ich festgestellt habe, dass der Cube  nicht in der Lage war, über vier Ebenen mit den HT's Kontakte aufrecht zu erhalten, habe ich einen 2. Cube installiert, der die beiden oberen Ebenen steuert. Das System funktioniert mit der ELV Software recht ordentlich. Allerdings ist diese kaum verwendbar. Deshalb habe ich Max!Buddy ausprobiert, das von dem Ersteller aber wohl nicht mehr weiterentwickelt wird. ELV hat(te) aber auch keine Veranlassung, die Interna des Systems zu veröffentlichen. Die Entwicklung basierte auf eigenen Recherchen der Verfasser.

Vor einigen Tagen habe ich begonnen, die Steuerung in meiner Parterrewohnung mit 10 HT's mit dem TemperaturScanner  transparenter zu gestalten. Das hatte zur Folge, dass das System nach einiger Zeit voll aus dem Ruder gelaufen ist, wie es im 2.Link oben geschildert wurde. Dabei wurde auch z.B. an einem Thermostat der Urlaubsmodus eingeschaltet, der zwar im Handbuch des HT beschrieben ist, dessen Verwendung aber in keiner SW auftaucht.
Bei den HT+ scheint er gar nicht mehr implementiert zu sein.

2.  Die ursprüngliche Aufgabe des Max! war, die Thermostate über ein Web-Interface zentral schaltbar zu machen, ja sogar aus dem Internet über einen Server bei ELV. Eine Steuerung im Sinne von PWM war eigentlich nur zwischen HT's in einem Raum und einem Wandthermostaten vorgesehen.

Die Einbindung von "fremden" Geräten war und ist m.E. von ELV (EQ-3) nicht gewünscht.

3. Seit 2 Jahren verwende ich mit mehr oder weniger Erfolg FHEM bei der Steuerung, wechsle aber auch häufiger auf ELV-Max! und Max!Buddy, vor allem dann, wenn die Steuerung mit FHEM Probleme macht. Deshalb war für mich die Imlementierung des oncommand sehr nützlich, allerdings auch grenzwertig, wie im folgenden deutlich werden soll.
Bei der Suche nach der Ursache der Probleme zeigte Max!Buddy, dass DutyCycle bei 100% war. Ich habe dann FHEM angehalten und den Cube aus- und wieder angeschaltet. Zwei Tage ohne FHEM hat das System funktioniert. Damit konnte eine Fehlfunktion des Cube ausgeschlossen werden. Blieb also FHEM.
Ich betreibe zwei Cubes, im 2.Stock mit vier und im Parterre mit 10 HT's. Bei drei HT's im 2.Stock ist der Scanner aktiv, im Parterre bei einem. Im Parterre wird der Cube mit 17% dutycycle belastet, im 2.Stock mit 57-60%. Bei beiden habe ich die oncommand-Funktion entfernt. Sie scheint aber für die Cubes keine Belastung darzustellen.
Da der CUL auch der 1% Regel unterliegt, dürften die Bedingungen bei seiner Verwendung die gleichen sein.
Jetzt nach ca. 10 Stunden sind keine Unregelmäßigkeiten zu beobachten.
Mein Fazit zu den geschilderten Vorfällen in den Links: Man sollte nicht Dinge verlangen, die bei der Konzeption der Hardware nicht vorgesehen sind, z.B. die Rückgabe der HT_Temperatur, unabhängig davon, dass diese auch noch ungenau sein kann. Von einer durch Offset korrigierten Temperatur will ich schon gar nicht reden.
Der Temperaturscanner sollte nur mit Vorsicht genutzt werden, da er Wege geht, die in der Hardware gar nicht vorgesehen sind.

PS:
Ich war gerade im Forum von ELV. Da ist der Frust riesengroß, vor allem, was die Anbindung von Max! an das Portal anbelangt. Da ist man mit FHEM wirklich sehr viel besser dran.

[fermoll]

Nach Recherchan in diesem Teil des Forums habe ich den Eindruck gewonnen, dass viele Nutzer sich nicht bewusst sind, was die einzelnen Komponenten leisten, vor allem aber, was sie nicht leisten können. Als Beispiel möchte ich anführen, dass ein Nutzer bemängelt, dass der HT nicht die Offset-koorigierte Temperatur zurückliefert.

Nur leider wird der TemperaturOffset nicht mit in die Anzeige der Ist-Temperatur mit einberechnet.

Es wird nur leider vergessen, dass das im MAX! System nicht vorgesehen ist. Zum anderen muss man immer bedenken, dass die Kommunikation zwischen den HT's, den anderen Komponenten und dem Cube oder auch dem CUL durch die 1 % Regel eingeschränkt ist.
Es ist eben so, dass der Temp.Scanner den Cube und den HT mit einem Trick überlistet. Die Folge war in meinem Fall, dass der Cube anfing zu spinnen.
Es wäre für neue Nutzer des MAX! Systems m.E. sinnvoll, sich auch einmal mit dem MAX! Frontend auseinanderzusetzen und dann zu überlegen, was mit FHEM möglich ist. Da ich das System schon genutzt habe, bevor ich etwas von FHEM gehört habe, habe ich vielleicht einen Vorteil.
Hier nun die Steuerung des HT mit FHEM:
(http://offset.jpg)
Mit dem Set Befehl kann der HT programmiert werden, wie das mit dem MAX!-Frontend möglich ist. Für das Wochenprogramm gibt es mittlerweile auch eine komfortable Lösung.
Mit dem ATTR-Befehl, kann man FHEM anweisen, wie es mit den Informationen des HT umgehen und ihn manipulieren kann, z.B. mit dem Temp.Scanner.
(Ich musste zwei Bilder machen, um das zu dokumentieren.)
Mit den verschiedenen ATTR-Befehlen bin ich noch nicht sehr vertraut.

[fermoll]

Einige der von mir verwendeten HT's zeigen völlig falsche Temperaturwerte an. Das liegt daran, dass sie versteckt verbaut sind. Besonders der HT in meiner Küche befindet sich unter einer Arbeitsplatte mit Lüftungsgitter und ist teilweise von einem Unterschrank verdeckt. Der Thermostat, der vor der Umstellung auf MAX! verbaut war, hatte einen externen Fühler, der oberhalb der Arbeitsplatte montiert war.  Der Temperaturunterschied zu einem externen Thermometer S300TH über CUNO beträgt ca. 4 -5 °C.
Der Temperaturfühler des HT befindet sich hinter dem Rändelrad des HT, wie aus den Fotos von MaxBuddy.de hervorgeht, im 2. Foto.
http://www.maxbuddy.de/heizkorperthermostat-nackt/
Es handelt sich um einen NTC 103F3435FST. Der Umbau des HT wird z.B. im ELV-Forum diskutiert:
http://www.elv.de/topic/umbau-des-temperaturfuehlers.html
Ich halte es für kaum machbar, mit FHEM ,  Temp.Scanner und einem externen Thermometer eine Regelung durchzuführen. Das ist m.E. nur mit einem Wandthermostaten sinnvoll . Der Grund ist die 1% Regel, die sowohl für den Cube als auch den CUL gilt.

Im Übrigen verstehen sich meine beiden Cubes seit zwei Tagen mit FHEM, ohne Zicken zu machen

Dabei zeigt der Cube im Parterre (meine Wohnung) ca. 20% DutyCycle, der im 2.Stock (momentan unbewohnt) ca. 50-60 %. Im Parterre versorgt er 10 HT's, einen mit Scantemp, Verbose 2, der obere vier HT's, davon drei mit ScanTemp Verbose 1 u. 2.

Mein Fazit:

Eine Steuerung im Sinne PWM scheint mir mit FHEM und ScanTemp nicht sinnvoll. Die Machbarkeit des Umbaus des HT habe ich noch nicht verfolgt. Bleibt nur die Korrektur über den Offset.

[reichi]

Oder der Einsatz von Wandthermostaten an den enstprechenden stellen
Diese liefern übrigens sehr sehr regelmäßig ganz von alleine die aktuelle Temperatur (ganz ohne Tricks und Cheats).

[John]

Hallo fermoll,

Eine Steuerung im Sinne PWM scheint mir mit FHEM und ScanTemp nicht sinnvoll. Die Machbarkeit des Umbaus des HT habe ich noch nicht verfolgt. Bleibt nur die Korrektur über den Offset.

Was du mit PWM bei einem analogen Stellglied bezwecken willst ist mir unklar.
Aber man kann ein Max-Thermostat tatsächlich seiner ganzen Regel-Aktivität berauben und es nur noch als reines analoges Stellglied einsetzen
und zwar ganz ohne Umbau der Hardware.

Ich habe dies hier beschrieben.
http://www.fhemwiki.de/wiki/MAX!_Thermostat_f%C3%BCr_die_Fussbodenheizung
Der Regelung wird auf FHEM verlagert. Damit regele ich nun seit 2 Jahre mit guten Erfolg die zuvor nur "mitlaufende" Fußbodenheizung
meines Bades.
Das Problem ist ähnlich deinem, der Temperatursensor im HT ist unbrauchbar, da sich der HT nicht im Bad befindet.
Ausserdem regelt sich  eine Fusbodenheizung doch anders als einen Heizkörper.


Konkret: du kannst einen in FHEM verfügbaren Istwert verwenden und diesen auf das Modul PID20 aufschalten.
Weiterhin wird PID20 das Max-Thermostat als Stellglied zugeordnet.
Man kann die Aktivität des PID20 in weiten Grenzen steuern und so die Credit-Belastung stark reduzieren.

Eine weitere theoretische Möglichkeit wäre mit fakeWT zu arbeiten, aber hierzu habe ich kaum Erfahrungen.

John

PS:
mit dem Offset-Thema habe ich mich vor Jahren befasst als ich die Istwerte meiner HTs kalibriert habe und konnte  keine
Fehlfunktion feststellen (verwende CUL).
Der gemeldet Istwert wurde nach der Korrektur parallel verschoben.

[fermoll]

Der Unterschied zwischen deiner Fußbodenheizung und meiner Konfiguration liegt darin, dass ich 10 ( bzw. 4) HT's verwende, du wohl offensichtlich einen oder wenige. Das gilt auch für die Systeme, die in den Links beschrieben wurden und wird wohl auch die meisten Nutzer von MAX betreffen. Zum anderen ist das System Fußbodenheizung träge und nicht mit der Steuerung von normalen Heizkörpern zu vergleichen.
Auf jeden Fall beobachte ich bei meinem Beispiel mit 4 HT's, von denen drei mit Temp.Scanner abgefragt werden, einen DUtyCycle zwischen 50 u. 60%. Dabei stehen die Thermostate alle konstant auf 6 °C, da die Räume im Moment nicht genutzt werden. Es wäre interessant, herauszufinden, wie die Belastung wäre, wenn eine Steuerung verwendet wird, wie du sie bei der Fußbodenhaizung beschreibst. Auf jeden Fall ist das System in meiner Wohnung mit 10 HT's völlig aus dem Ruder gelaufen, wobei nur drei oder vier mit dem Scanner protokolliert wurden, und zwar nur in einer Richtung.

PS: Ich bin kein Spezialist für Regeltechnik.

[John]

@fermol

, du wohl offensichtlich einen oder wenige

falsch, wäre auch ziemlich schwierig den MaxScanner zu entwicklen, wenn man nur 1 Thermostat in Gebrauch hat.

Zum anderen ist das System Fußbodenheizung träge und nicht mit der Steuerung von normalen Heizkörpern zu vergleichen

Dank dir für den Hinweis, war aber nur als Anwendungsfall gedacht, wie man ein Max-Thermostat als Stellglied einsetzen kann.

Ich empfehle dir die Anschaffung eines Wand-Thermostats.

John

[fermoll]

Der Wandthermostat wäre in meinem Fall Wohnzimmer mit 2 HT's hinter Gardinen sicher eine Option. Für die Küche mit dem einen stark verdeckten HT aber zu viel des Guten. Ich habe zwei Möglichkeiten, den Thermostaten mit dem ScanTemp zu beobachten und mit externem Thermometer zu kontrollieren. Der Offset könnte dann per Hand kontrolliert werden oder , wenn das nicht reicht, einfach die Temp. anders eingestellt werden.
Zum anderen muss ich berücksichtigen, dass ein großer Durchgang vom Wohnzimmer zur Küche vorhanden ist. Man könnte dann den Küchen HT zusammen mit denen des Wohnzimmers steuern.

Ich habe in der letzten Stunde den Scanner im 2.Stock ausgeschaltet, der drei HT's protokolliert hat. Der Dutycycle ist sofort auf  0% gefallen.

[fermoll]

Bisher war ich immer davon ausgegangen, dass das Verbose-Attribut nur bei Global angewendet wird. Nachdem ich mich nach dem Störfall intensiver mit dem DutyCycle auseinendegesetzt habe, habe ich jedoch festgestellt, dass viele Geräte - vielleicht sogar alle - mit diesem Attr. gesteuert werden können.
Ich meine, mal gelesen zu haben, dass bei Geräten, die kein Verbose gesetzt haben, die globale Einstellung verwendet wird.
Ich gehe jetzt erst einmal nur von meinem  MAX! Fall aus, der nur den Cube und bis zu 10 HT's berücksichtigt. Die Frage ist, ob die Verwendung von Verbose bei den HT's einen Einfluss auf den Scanner hat, was den DutyCycle anbelangt.