Temperatur-Scanner für MAX-Thermostate

Begonnen von John, 12 März 2013, 09:44:59

Vorheriges Thema - Nächstes Thema

oduudo

Hallo John, hallo Harald,
hab die neue Version eingespielt und sieht echt klasse aus.
Eine Frage hab ich noch, Harald hatte das schon angesprochen:
Gibt es eine Lösung, wenn ich 2 Tage nicht zu Hause bin, die Ventile komplett auf eco zu schalten?
Kann im Mietshaus nicht die Therme ausschalten, sondern muß die Ventile steuern. Will halt verhindern, daß das Wochenprogramm die Ventile hochdreht, wenn ich weg bin.
vielen Dank für Deine Arbeit, John.
Udo
RPI4b mit FHEM
CCU3
HM, HmIP diverse Komponenten (Fenster, Rolladen, Themostate, Steckdosen, Fernsteuerungen ...)

hobu

Zitat von: oduudo am 01 Dezember 2013, 03:39:18
Gibt es eine Lösung, wenn ich 2 Tage nicht zu Hause bin, die Ventile komplett auf eco zu schalten?
Als Lösungsansatz:
Ich würde für den/die Tage das Wochenprogramm des Tages mit "set weekProfile ..." dann auf den jeweiligen Eco-Wert des Thermostaten setzen.

In Verbindung mit dem Kalender-Modul sicher eine schnelle und autarke Lösung. Das Rücksetzen auf das alte Tagesprogramm ist wohl etwas kniffliger, da dieses ja "irgendwo" zwischengespeichert und zeitgerecht wieder ausgelesen werden muss. Kann man sicher in der fhem.cfg vorhalten, aber ich finde das irgendwie unelegant.

Raspberry Pi (Model B)
HM-CFG-USB, HM-CC-RT-DN, HM-LC-SW1-FM, HM-Dis-WM55, HM-FK-SCO

stgeran

Noch eine Frage: Wer ist für die Reglung des Thermostates "verantwortlich"? Das Thermostat selbst oder der Scanner? Grund der Frage: Wie kann ich das "Überschwingen" minimieren? Ich gebe z.B. 22°C vor und der Scanner zeigt, daß die Temperatur bis 23,9°C steigt. Das Ventil hat während dieser Zeit 100% Öffnung.
FHEM auf Raspberry
CSM 866MHz für EM1010 mit Strom und Gaszähler
CUL 866MHz für MAX! Radiator Thermostat 
CUL 433MHz für Innen und Aussen Temp
HMLAN für HM-LC-Sw1-PI-2

John

Hallo stgeran,

ZitatWer ist für die Reglung des Thermostates "verantwortlich"?
Die Regelung liegt nach wie vor im Thermostat selbst.
Also ist das Thermostat zunächst "verantwortlich".

Allerdings ändert der Scanner im Modus "onlyAutoMode" den Sollwert um 0.5 Grad, damit eine Übertragung des Istwertes
angeregt wird. Das beeinflusst natürlich auch den Regler, da sich die Regeldifferenz ändert.
Der Scanner wird aber die Änderung immer in die Richtung einer sich vergroessernden Sollwertabweichung durchführen.

Beispiel.
Sollwert im Thermostat nach Wochenprofil : 18
Fall A:
Istwert   17
Sollwert A von Scanner gesetzt : 18.5
Sollwert B von Scanner gesetzt : 18.0
Der Scanner wechselt also von 18 auf 18.5 und zurück.


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

ZitatWie kann ich das "Überschwingen" minimieren?
Überschwingen kann viele technische Ursachen haben.
Es wäre hilfreich, wenn du hierzu einen neuen Thread aufmachen könntest, damit sich nicht alle Probleme hier "versammeln".
Wir können dann dort weiter diskutieren.

John



CubieTruck Docker Node-Red Tasmota Shelly Homematic-IP

oduudo

Hallo Hobu,

die Lösung ist nicht sinnvoll machbar. Beim verlassen der Wohnung 5 Thermostaten genau für den Tag das Wochenprofil wegzuschiessen und beim Wiederkommen wieder zu setzen klingt nicht gut.
Ich hatte bisher einen Taster, der beim Wohnung verlassen den Status weg hatte und dann entsprechend alle Temperaturen auf ECO gesetzt hat. Wenn jetzt die Ventile wieder die Steuerung übernehmen geht das halt nicht.
Ich hatte die Hoffnung, dem MAX Scanner einen Wert schicken zu können, der dann alles auf ECO setzt, bis ich durch den Taster den WErt wieder auf normal setze. Ist eigentlich wohl das gleiche wie die Frage von Harald nach dem ECO-Taster, der das wohl für MAX machen würde, ich hab halt noch Homematik mit drin, so daß ich das etwas globaler steuern muß.
Hier im Thread würd mir ne Lösung reichen, den MAX Ventilen das mitteilen zu können. Ich glaub das geht nur innerhalb des Scanners, also nur mit Johns Hilfe.... ;-))

Udo
RPI4b mit FHEM
CCU3
HM, HmIP diverse Komponenten (Fenster, Rolladen, Themostate, Steckdosen, Fernsteuerungen ...)

hobu

Zitat von: oduudo am 01 Dezember 2013, 12:59:41
Beim verlassen der Wohnung 5 Thermostaten genau für den Tag das Wochenprofil wegzuschiessen und beim Wiederkommen wieder zu setzen klingt nicht gut.
Nachvollziehbar...
Bei >4 Thermnostaten ist das ein Heidenaufwand, alles vorzubereiten und nachher wieder korrekt zu setzen.

ZitatIch hatte bisher einen Taster, der beim Wohnung verlassen den Status weg hatte und dann entsprechend alle Temperaturen auf ECO gesetzt hat. Wenn jetzt die Ventile wieder die Steuerung übernehmen geht das halt nicht.
Ich hab' hier auch den ECO-Taster von MAX. Den könnte man dafür hervorragend verwenden, wenn der ECO-Modus denn dauerhaft (d.h. bis zum nächten manuellen Wechsel) aktiv bleiben würde.

Leider bleibt der ECO-Modus ja nur bis zum nächsten Schaltzeitpunkt des programmierten Profils aktiv. Das ist meist auch OK und gewünscht, aber für eine Urlaubsschaltung natürlich nicht verwendbar. Wir bräuchten irgendeine 'thermostatinterne' Variable durch die entschieden werden kann, ob der ECO-Modus wie üblich gehandhabt werden soll oder nur durch manuellen Eingriff deaktiviert werden kann. Dann wäre eine Urlaubsschaltung mit dem ECO-Taster möglich.

Als Idee: Die 'minimumTemperature' im MAX-Thermostaten ist relativ unwichtig.
Ob die nun ein Grad mehr oder weniger hat ist somit egal. Wenn man hier z.B. 10° als normalen Wert annimmt und 9° als Identifikator für 'Urlaub'/'längere Abwesenheit' definiert, hätten wir so ein Reading, auf das geprüft und der Modus entsprechend aus- oder eingeschaltet werden kann.

Ein Thermostat als 'Master' mit entsprechender minimumTemperature reicht für die Entscheidung ob Urlaub oder nicht ja aus.
Raspberry Pi (Model B)
HM-CFG-USB, HM-CC-RT-DN, HM-LC-SW1-FM, HM-Dis-WM55, HM-FK-SCO

John

@ oduudo und @hobu

Die Sache mit den ECO-Tastern werde ich erst nach Abschluss der bisherigen Änderungen angehen.

Ein Workaround bis dahin wäre wie folgt möglich:

Ein Skript, das z.B. via <at>  stündlich ausgeführt wird, erledigt folgendes, wenn ECO-Mode aktiv ist:

Setzen des gewünschten Temperaturwertes bei allen Thermostaten via
set <HT> desiredTemperatur <ECO-Sollwert>

wenn desired nicht mit  dem ECO-Sollwert übereinstimmt.

Der Scanner wird diese Änderung bis zum nächsten Schaltzeitpunkt übernehmen.

Das Skript kann auch häufiger ausgeführt werden, falls nötig, es sollte aber nur dann einen Befehl absetzen, wenn es nötig ist.

John




CubieTruck Docker Node-Red Tasmota Shelly Homematic-IP

Stephan

Ich halte das vorgehen für sinnvoll, erst das zu Ende zu bringen, was angefangen wurde und erst danach neue Baustellen aufzumachen.
Auch wenn ich sowohl eco-Taster als auch die Unterstützung mehrerer fenszerkontakte sehnlich erwarte. Als echtes Fernziel würde ich mit dann noch eine Heizungssteuerung wünschen, da der Scanner eh schon massiv eingreift und man damit eine one-stop-shopping Lösung hätte.

Gruss
Stephan


Gruß
Stephan

fhem 5.5, Raspi B, CUL V3 868 (max), Arduino Uno R3 conf.firmata v2.05

John

Die neue freigegebene Version  1.05a ist nun fertiggestellt.

Änderungen sind im  Wiki  http://www.fhemwiki.de/wiki/MAX!_Temperatur-Scanner nachzulesen.

Allen die geholfen haben, das Skript zu testen an dieser Stelle vielen Dank.

Die wichtigsten Änderungen

  • Auch CUBE wird nun neben CUL unterstützt.
  • Neuer Scan-Modus "DesiredChange"  ermöglicht das Verbleiben im Auto-Modus des Thermostats.
  • Das Wochenprogramm des Thermostats wird vom Scanner intensiv genutzt und muss nicht mehr "deaktiviert" werden, wie dies bei den Vorgängerversionen nötig war
  • Der Einsatz von HeatingControl ist damit überflüssig
  • Viele grundlegende Änderungen als Vorbereitung für das zukünftige Modul (z.B. verbesserte Log-Ausgabe)

Einige Wünsche wie mehrfache Fensterkontakte und ECO-Schalter bleiben noch offen und werden wohl mit dem Erscheinen der Modulversion berücksichtigt werden.

John
CubieTruck Docker Node-Red Tasmota Shelly Homematic-IP

cotecmania

Der neue Modus ohne HeatingControl gefällt mir gut, da beim Ausfall von FHEM trotzdem alles wie gewohnt weiterläuft.
Kann ich aber weiterhin die Ventile von Hand auf "Manuell" stellen und dieser Modus wird beibehalten, oder wird beim nächsten Schaltpunkt dann vom Scanner wieder in den Automatikmodus gewechselt ?
FHEM auf RaspberryPI B (buster)
2xCUL868 für MAX/Slow_RF, HM-LAN, JeeLink
MAX!/HM-Thermostate, FS20/HM-Rolladenschalter, FS20-EM, LevelJet-Ölstandsmessung, PCA301, IT, KM271, IPCAM, FireTAB10 FTUI

John

Hallo cotecmania
wie im Wiki zu lesen, gilt jede manuelle Verstellung nur bis zum nächsten Schaltpunkt.

Der Schaltpunkt ist hier unabhängig vom Scanner-Mode, er wird immer ausgeführt, entweder vom Thermostat oder vom Scanner.

ZitatKann ich aber weiterhin die Ventile von Hand auf "Manuell" stellen und dieser Modus wird beibehalten, oder wird beim nächsten Schaltpunkt dann vom Scanner wieder in den Automatikmodus gewechselt ?
Das gelingt nur dann dauerhaft, wenn du das Thermostat für den Scanner deaktivierst, in dem das Attribut scanTemp auf 0 gesetzt wird.
Dann gibts natürlich auch keine Kurven mehr.

John

CubieTruck Docker Node-Red Tasmota Shelly Homematic-IP

shorty81

Hi,
leider erschließen sich mir die unterschiedlichen Scanner-Modi nicht, bzw. genauer:

Welcher Mode (ModeChange oder DesiredChange) bietet sich denn für welchen Verwendungszweck an bzw. was sind die jeweiligen Vor- und Nachteile?
Finde im Wiki keinen Anhaltspunkt um eine Entscheidung zu treffen.
Danke!
Raspberry Pi 2 Model B, CUL866, CUL433, JeeLink, HMLan, Homematic, Homebridge via Siri, Philips HUE, Max-Thermostate, Max-Fensterkontakte, AVM 546E, WS1600, RSL, Intertechno, IT+, Elro

John

Hallo shorty81,

aus dem Wiki

ZitatModeChange

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

Wenn das Ventil weniger Bewegungen macht, passt es ggf. besser fürs Schlafzimmer.
Nachteil: bei Ausfall von FHEM, kann das Thermostat im MANU-Modus stehen der eingestellte Sollwert ändert sich nicht mehr.

Zitat
DesiredChange

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

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

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

John

CubieTruck Docker Node-Red Tasmota Shelly Homematic-IP

shorty81

#418
Danke für die schnelle Hilfe!

Allerdings kommen meine Thermostate (DesiredChange-Modi) jetzt überhaupt nicht mehr zur Ruhe.
Das war zwar auch so angekündigt, aber der Grad der Aktivität überrascht mich schon...
Das geht doch sicherlich massiv auf die Haltbarkeit?

Chris
Raspberry Pi 2 Model B, CUL866, CUL433, JeeLink, HMLan, Homematic, Homebridge via Siri, Philips HUE, Max-Thermostate, Max-Fensterkontakte, AVM 546E, WS1600, RSL, Intertechno, IT+, Elro

shorty81

#419
Ich habe gerade mal nach nach dem update ins log geschaut, da sind ziemlich viele Einträge drin, die ich mir nicht ganz erklären kann... Ist das normal?
anbei ein Auszug:

2013.12.02 05:28:12 3: [MAX_07a694] MaxScanRun.444 TYPE:CUL_MAX IOName:CULMAX0
2013.12.02 05:28:12 3: [MAX_07a694] MaxScanRun.741 <<set MAX_07a694 desiredTemperature auto 14>>
2013.12.02 05:28:12 3: [MAX_07b0e8] MaxScanRun.430 sdNextScan:2013-12-02 05:29:36 strDesiTime:2013-12-02 05:26:53
2013.12.02 05:28:12 3: [MAX_07b0e8] MaxScanRun.444 TYPE:CUL_MAX IOName:CULMAX0
2013.12.02 05:28:12 3: [MAX_0767c9] MaxScanRun.430 sdNextScan:2013-12-02 05:30:05 strDesiTime:2013-12-02 05:18:22
2013.12.02 05:28:12 3: [MAX_0767c9] MaxScanRun.444 TYPE:CUL_MAX IOName:CULMAX0
2013.12.02 05:28:12 3: [MAX_0766fc] MaxScanRun.430 sdNextScan:2013-12-02 05:31:56 strDesiTime:2013-12-02 05:20:13
2013.12.02 05:28:12 3: [MAX_0766fc] MaxScanRun.444 TYPE:CUL_MAX IOName:CULMAX0
2013.12.02 05:28:12 3: [MAX_0703e4] MaxScanRun.430 sdNextScan:2013-12-02 05:34:32 strDesiTime:2013-12-02 05:22:49
2013.12.02 05:28:12 3: [MAX_0703e4] MaxScanRun.444 TYPE:CUL_MAX IOName:CULMAX0
2013.12.02 05:30:05 3: [MAX_0767c9] MaxScanRun.430 sdNextScan:2013-12-02 05:30:05 strDesiTime:2013-12-02 05:18:22
2013.12.02 05:30:05 3: [MAX_0767c9] MaxScanRun.444 TYPE:CUL_MAX IOName:CULMAX0
2013.12.02 05:30:05 3: [MAX_0767c9] MaxScanRun.741 <<set MAX_0767c9 desiredTemperature auto 15.5>>
2013.12.02 05:30:05 3: [MAX_07a694] MaxScanRun.430 sdNextScan:2013-12-02 05:31:12 strDesiTime:2013-12-02 05:28:29
2013.12.02 05:30:05 3: [MAX_07a694] MaxScanRun.444 TYPE:CUL_MAX IOName:CULMAX0
2013.12.02 05:30:05 3: [MAX_0766fc] MaxScanRun.430 sdNextScan:2013-12-02 05:31:56 strDesiTime:2013-12-02 05:20:13
2013.12.02 05:30:05 3: [MAX_0766fc] MaxScanRun.444 TYPE:CUL_MAX IOName:CULMAX0
Raspberry Pi 2 Model B, CUL866, CUL433, JeeLink, HMLan, Homematic, Homebridge via Siri, Philips HUE, Max-Thermostate, Max-Fensterkontakte, AVM 546E, WS1600, RSL, Intertechno, IT+, Elro