Hauptmenü

MaxValveSetting

Begonnen von John, 17 April 2013, 20:05:30

Vorheriges Thema - Nächstes Thema

John

Mit MaxValveSetting könnte man eine hydraulische Fehlanpassung einzelner Heizkörper korrigieren,
da man die Ventilöffnung und somit den Durchfluss begrenzt.

Daher ist diese Funktion durchaus von Interesse.

Ich habe ein unterschiedliches Verhalten von HeatingThermostat und HeatingThermostatPlus bezüglich maxValveSetting
festgestellt:

Ablauf HeatingThermostat:

# maxValveSetting ist 100
set HT.V1 desiredTemperature on

# thermostat fährt auf und meldet die neue valveposition
2013-04-17 16:36:27 MAX HT.V1 valveposition: 100

# nun maxValvesetting auf 80%
set HT.V1 maxValveSetting 80

# Thermostat fährt zu, nach kurzer Zeit kommt auch die Rückmeldung an
2013-04-17 16:36:27 MAX HT.V1 valveposition: 80


Ablauf bei HeatingThermostatPlus:

# maxValveSetting ist 100
set HT.V2 desiredTemperature on

# thermostat fährt auf und meldet die neue valveposition
2013-04-17 16:36:27 MAX HT.V2 valveposition: 100

# nun maxValveSetting auf 80%
set HT.V2 maxValveSetting 80

# keine Reaktion am Thermostat und keine Rückmeldung in den Events


Bei HeatingThermostatPlus scheint MaxValveSetting nicht zu funktionieren.

Gibt es hierzu eine Erklärung oder Erkenntnisse von anderen Anwendern ?

John

CubieTruck Docker Node-Red Tasmota Shelly Homematic-IP

Matthias Gehre

Würde mich auch interessieren.

John

Fragen an Alle die über einen Cube UND Max-Thermostat+ verfügen:

1. Gibt es in der Original-Software zum Cube die Möglichkeit die maximmale Ventilstellung einzustellen ?

2. Gibt es die Möglichkeit die Ventilstellung abzufragen ?

wenn, beides mit Ja beantwortet werden kann:

3. bitte folgendes am Thermostat+ versuchen:

a. desiredTemperature auf ON stellen und abwarten (akkustisches Feedback) bis die Ventilfahrt zu Ende ist
   Ventilstellung ablesen

b.  desiredTemperatur auf OFF stellen
   Ventilstellung ablesen

c. Maximale Ventilstellung auf 80% (oder anderer von 100% unterschiedlicher Wert)
   desiredTemperature auf ON stellen
   Ventilstellung ablesen


4. Infos zu den Ventilstellungen bitte zurückmelden

5. ggf bei ELV Support anfragen
   Wenn sich unter 3c die Ventilstellung nicht bei 80% einstellt, bitte den ELV-Support anfragen
   und die Antwort zurückmelden.

   

Vielen Dank an die Unterstützer im Voraus.


John
CubieTruck Docker Node-Red Tasmota Shelly Homematic-IP

pet22

Hi John,

1. Gibt es in der Original-Software zum Cube die Möglichkeit die maximmale Ventilstellung einzustellen ?

Weder bei der aktuellen Software ELV Software für den Cube noch bei der Software von eQ-3 finde ich einen Menüpunkt für HT und HT+.
Der bei mir vorhandene HT gekoppelt mit einem WT+ arbeitet aber zuverlässig mit maxValveSetting- und valveOffset-Werten (reduziert
das Sauna-/ Kühlschrank Feeling in der Einschwingphase). 2 HT+ zeigen keine Wirkung bei maxValveSetting. valveOffset habe ich nicht
ausprobiert, da es nicht benötigt wird.

eQ-3 gibt beim HT folgendes an (http://www.eq-3.de/max-raumloesung-produktdetail/items/bc-rt-trx-cyg.html)
"Passt sich durch adaptive Regelung und zusätzliche, optionale Ventilbegrenzung der Heizkörperdimension an,
ein hydraulischer Abgleich am Heizkörper ist nicht nötig"

Beim HT+ fehlt dieser Satz in der Spezifikation: http://www.eq-3.de/max-heizkoerpersteuerung-produktdetail/items/max-heizkoerperthermostat.html

Gruss

Pet22
Debian 11/ Intel Atom MB/ CUL V3/ Raspberrymatic/ Homematic classic, Homematic IP, WTs & HTs

John

Hallo pet22,

vielen Dank für Deine Antwort.

nachdem du Wandthermostat und HT+ produktkonform betreibst könntest du beim ELV Support anfragen,
warum bei HT+ MaxValveSetting nicht funktioniert im Gegensatz zu den normalen HTs.

Dann hätten wir eine klare Aussage vom Hersteller.

John
CubieTruck Docker Node-Red Tasmota Shelly Homematic-IP

pet22

Hallo John,

vielleicht habe ich es etwas umständlich ausgedrückt. Hier nochmals die Kurzfassung:

* HT zusammen mit WT+ verhalten sich produktkonform;
* WT+ stand-alone verhält sich produktkonform. Es gibt keinen Hinweis, dass die Ventilstellung begrenzt werden kann;

Wie im ELV Forum nachzulesen sind Feature Requests nicht sehr erfolgreich.
Evtl. gibt es ja weitere Menüpunkte bei der sogenannten MAX Hauslösung, dh. "Steuerung über das Internet" in der ELV Terminologie (meine Konfiguration ist lieblos mit autocreate erzeugt worden). Sobald ich mehr Zeit habe, mache ich den nächsten Versuch mit dem Cube.

Gruß

Pet22
Debian 11/ Intel Atom MB/ CUL V3/ Raspberrymatic/ Homematic classic, Homematic IP, WTs & HTs

John

Besten dank für die Unterstützung,
dann warten wir mal ab.

John
CubieTruck Docker Node-Red Tasmota Shelly Homematic-IP

John

Und es geht doch:


Desired Temperature


desi auf ON gesetzt, damit wir MaxValveSetting testen können
2013-06-08 11:37:10 MAX HT.WOZI desiredTemperature on

<<2 Befehl wird von CUL versendet>>
2013-06-08 11:37:11 MAX HT.WOZI mode: manual
2013-06-08 11:37:11 MAX HT.WOZI battery: ok
2013-06-08 11:37:11 MAX HT.WOZI desiredTemperature: 30.5
2013-06-08 11:37:11 MAX HT.WOZI valveposition: 0
2013-06-08 11:37:11 MAX HT.WOZI 30.5 °C

es dauert 1.5 Min bis das Ventil den Befehl hörbar ausführt
danach
2013-06-08 11:39:35 MAX HT.WOZI battery: ok
2013-06-08 11:39:35 MAX HT.WOZI desiredTemperature: 30.5
2013-06-08 11:39:35 MAX HT.WOZI valveposition: 100
2013-06-08 11:39:35 MAX HT.WOZI temperature: 26.2
2013-06-08 11:39:35 MAX HT.WOZI 30.5 °C


MaxValveSetting
maxvalve setting auf vonn 100 auf 80

<<1 Befehl wird an FHEM abgesetzt>>
2013-06-08 11:41:09 MAX HT.WOZI maxValveSetting 80

<<2 Befehl wird von CUL versendet>>
2013-06-08 11:41:10 MAX HT.WOZI mode: manual
2013-06-08 11:41:10 MAX HT.WOZI battery: ok
2013-06-08 11:41:10 MAX HT.WOZI desiredTemperature: 30.5
2013-06-08 11:41:10 MAX HT.WOZI valveposition: 100
2013-06-08 11:41:10 MAX HT.WOZI 30.5 °C

<<3 Bestätigung vom Ventil>>
2013-06-08 11:41:11 MAX HT.WOZI maxValveSetting: 80
2013-06-08 11:41:11 MAX HT.WOZI 30.5 °C

Nach ca. 3 Minuten erfolgt hörbar die  Ausführung, ohne weitere Rückmeldung
im Event-Monitor.

Damit können auch die Plus-Thermostate den MaxValeSetting realisieren und wir können dies für den
hydraulischen Abgleich einsetzen.

John
CubieTruck Docker Node-Red Tasmota Shelly Homematic-IP

pet22

Hallo John,

yep, funktioniert wie von dir beschrieben - danke !!

Somit sind die Plots eigentlich ziemlich nutzlos, wenn measurementOffset ne 0 und/ oder maxValveSetting < 100%

Gruss

Pet22
Debian 11/ Intel Atom MB/ CUL V3/ Raspberrymatic/ Homematic classic, Homematic IP, WTs & HTs

John

Hi pet22,

ZitatSomit sind die Plots eigentlich ziemlich nutzlos, wenn measurementOffset ne 0 und/ oder maxValveSetting < 100%

measurementOffset nutze ich zur Korrektur des Istwertes, das finde ich sehr brauchbar und nützlich.

ValvePosition bezieht sich auf den Arbeitsbereich zwischen valveOffset und maxValveSetting.

Beispiel
  valveOffset= 10%  maxValveSetting= 80%
  Der Arbeitsbereich bewegt sich also zwischen 10% und 80% des Ursprungsbereiches.

  valvePosition bezieht sich jetzt jedoch auf den Arbeitsbereich und zeigt nach wie vor Werte von 0..100% an.
 
Insofern kann ich wenig Nutzloses entdecken.

John
CubieTruck Docker Node-Red Tasmota Shelly Homematic-IP

pet22

Hi John,

bei mir gibt es (1) HT zusammen mit WT+ und (2) HT+ folgende Diskrepanz:

* HT: Logs und Plot zeigt ValvePosition zwischen 0% und maxValveSetting; dh. maxValveSetting = 50% werden als 50% angezeigt

* HT+: wie von dir beschrieben, der Arbeitsbereich zwischen valveOffset und maxValveSetting wird von 0% - 100% angezeigt; dh. maxValveSetting = 50% wird als 100% angezeigt

* HT+: measurementOffset wird bei Logs und Plots nicht berücksichtigt. Entfällt logischweise bei der Kombination HT mit WT+

Nachdem ich heute Abend ein Firmwareupdate für den Cube entdeckt habe (https://www.max-portal.elv.de/downloads/MAX_Releasenotes.htm), nächster Versuch - keine Änderung. Sobald die nächste Heizperiod beginnt, muss ich halt pro HT+ ein individuelles gplot File erzeugen. Eine andere Idee habe ich im Moment nicht.

HIH

Pet22
Debian 11/ Intel Atom MB/ CUL V3/ Raspberrymatic/ Homematic classic, Homematic IP, WTs & HTs

John

Hallo pet22,
wir haben das Thema measurementOffset schon mal behandelt in diesem Thread

Link

Allerdings verwende ich einen CUL.
HT und HT+ verhalten sich hier gleichwertig.
Die Messwerte kommen allesamt korrigiert also korrekt an.

John
CubieTruck Docker Node-Red Tasmota Shelly Homematic-IP

pet22

Hi John,

mea culpa - hatte den Thread leider nicht gelesen. Offensichtlich gibt es da einen Unterschied zwischen Betrieb mit Cube und CUL.
Nachdem ich die Zeilen mit einem kleinen Zusatz wieder eingefügt habe, ist die Temperaturanzeige in den Plots korrekt:

   my $measOffset = MAX_ReadingsVal($shash,"measurementOffset");
   $measuredTemperature -= $measOffset if($measuredTemperature ne "" and $measOffset ne "" and ($shash->{type} =~ /HeatingThermostatPlus/));

Um die tatsächliche Ventilöffnung bei bei HT und HT+ im Plot anzuzeigen, habe folgendes geändert:

   #readingsBulkUpdate($shash, "valveposition", $valveposition);
   readingsBulkUpdate($shash, "valveposition", int($valveposition*MAX_ReadingsVal($shash,"maxValveSetting")/100)) if($shash->{type} =~ /HeatingThermostatPlus/);
   readingsBulkUpdate($shash, "valveposition", $valveposition) if($shash->{type} !~ /HeatingThermostatPlus/);

Mit der von Matthias Gehre empfohlenen Änderung (Link) läuft es nun
perfekt. Mit meinen rudimentären Perl Kenntnissen finde ich leider keine Möglichkeit, um zwischen CUL und CUBE Betrieb zu unterscheiden.
Bei CUL Betrieb sind ja anscheinend diese Klimmzüge unnötig.

Gruss

Pet22
Debian 11/ Intel Atom MB/ CUL V3/ Raspberrymatic/ Homematic classic, Homematic IP, WTs & HTs

Matthias Gehre

Probiert mal die 10_MAX aus dem Anhang. Die sollte den Workaround nur aktivieren, wenn der CUBE benutzt wird.

pet22

Hallo Matthias,

vielen Dank für den Patch. Sofern Zeile 618 auskommentiert wird läuft es problemlos mit dem Cube. Mal abwarten, was die CUL Anwender herausfinden.
M.E. könnte die vereinfachte Version auch so aussehen:

    if($measuredTemperature ne "") {
      readingsBulkUpdate($shash, "temperature", sprintf("%2.1f",$measuredTemperature));
      if($shash->{type} =~ /HeatingThermostatPlus/ and $hash->{TYPE} eq "MAXLAN") {
        readingsBulkUpdate($shash, "valveposition", int($valveposition*MAX_ReadingsVal($shash,"maxValveSetting")/100));
      } else {
        readingsBulkUpdate($shash, "valveposition", $valveposition);
      }
      Log 1, "backend type: $hash->{TYPE}";
    }

Zusätzlich sollte

      Log 1, "backend type: $hash->{TYPE}";

auf
      Log 5, "backend type: $hash->{TYPE}";

geändert werden, da es ziemlich schnell das Log füllt. Ich nehme an, es war nur zum Testen gemeint.


Nach einem Kaltstart fallen nun auch folgende Meldungen an:

       MAX: Invalid value 34.9019607843137 for READING maxValveSetting. Forcing to 100

Soweit ich das im Momnet nachprüfen kann, betrifft es aber nur FHEMWEB, die HT Plots zeigen nach wie vor den korrekten Wert an.
Die folgende Änderung behebt bei mir diesen Effekt:

      #readingsBulkUpdate($shash, "maxValveSetting", $args[9]);
      #readingsBulkUpdate($shash, "valveOffset", $args[10]);
      readingsBulkUpdate($shash, "maxValveSetting", int($args[9]));
      readingsBulkUpdate($shash, "valveOffset", int($args[10]));

Nochmals vielen Dank und Gruss

Pet22
Debian 11/ Intel Atom MB/ CUL V3/ Raspberrymatic/ Homematic classic, Homematic IP, WTs & HTs

pet22

Nachtrag nach ca. 5h:

WT+ und HT loggen bei mir in dasselbe Log-File:

Zitatdefine FileLog_max.kinderzimmer FileLog /var/log/fhem/cache/max.kinderzimmer-%Y-%m.log max.kinderzimmer:(battery|desiredTemperature|valveposition).*|thermo.kinderzimmer:(battery|temperature).*

Seit ich den Patch geladen habe, werden keine Werte mehr ins Log-File geschrieben. Bisher

Zitatif($measuredTemperature ne "") {
readingsBulkUpdate($shash, "temperature", sprintf("%2.1f",$measuredTemperature));
if($shash->{type} =~ /HeatingThermostatPlus/ and $hash->{TYPE} eq "MAXLAN") {
readingsBulkUpdate($shash, "valveposition", int($valveposition*MAX_ReadingsVal($shash,"maxValveSetting")/100));
} else {
readingsBulkUpdate($shash, "valveposition", $valveposition);
}
Log 1, "backend type: $hash->{TYPE}";
}

Abhilfe ab ca. Zeile 617

ZitatreadingsBulkUpdate($shash, "desiredTemperature", sprintf("%2.1f",$desiredTemperature)) if($desiredTemperature != 0);
    if($measuredTemperature ne "") {
      readingsBulkUpdate($shash, "temperature", sprintf("%2.1f",$measuredTemperature));
    }
    if($shash->{type} =~ /HeatingThermostatPlus/ and $hash->{TYPE} eq "MAXLAN") {
        readingsBulkUpdate($shash, "valveposition", int($valveposition*MAX_ReadingsVal($shash,"maxValveSetting")/100));
    } else {
        readingsBulkUpdate($shash, "valveposition", $valveposition);
    }    readingsBulkUpdate($shash, "desiredTemperature", sprintf("%2.1f",$desiredTemperature)) if($desiredTemperature != 0);
    if($measuredTemperature ne "") {
      readingsBulkUpdate($shash, "temperature", sprintf("%2.1f",$measuredTemperature));
    }
    if($shash->{type} =~ /HeatingThermostatPlus/ and $hash->{TYPE} eq "MAXLAN") {
        readingsBulkUpdate($shash, "valveposition", int($valveposition*MAX_ReadingsVal($shash,"maxValveSetting")/100));
    } else {
        readingsBulkUpdate($shash, "valveposition", $valveposition);
    }

Wie bereits im vorigen Beitrag erwähnt:

Zitat#readingsBulkUpdate($shash, "maxValveSetting", $args[9]);
#readingsBulkUpdate($shash, "valveOffset", $args[10]);
readingsBulkUpdate($shash, "maxValveSetting", int($args[9]));
readingsBulkUpdate($shash, "valveOffset", int($args[10]));

Bisher läuft das mit dem Cube ohne weitere Probleme.

Gruss

Pet22
Debian 11/ Intel Atom MB/ CUL V3/ Raspberrymatic/ Homematic classic, Homematic IP, WTs & HTs

Matthias Gehre

Hab ein paar Fixes committed, bitte testen.

pet22

Danke wird sofort getestet, wenn verfügbar.

Allerdings habe ich etwas Zweifel bei:

   #Send wakeUp, so we can send the weekprofile pakets without preamble
    #Disabled for now. Seems like the first packet is lost. Maybe inserting a delay after the wakeup will fix this
    #MAX_WakeUp($hash) if( @args > 2 );


Evtl. wäre

MAX_WakeUp($hash) if( @args > 2 and $hash->{TYPE} ne "MAXLAN" );


eine Lösung, die sowohl bei Cube als auch CUL funktioniert.

Gruss

Pet22
Debian 11/ Intel Atom MB/ CUL V3/ Raspberrymatic/ Homematic classic, Homematic IP, WTs & HTs

pet22

Hallo Matthias,

ich habe heute Morgen ein Update gemacht. Bisher habe ich keine Fehlermeldungen erhalten. Es läuft also mit dem CUBE hervorragend.

Kleine Nebenwirkungen: Die Heizungsthermostate stehen gegenwärtig auf Frostschutz, d.h. comfortTemperature=
ecoTemperature=desiredTemperature=minimumTemperature=4.5. Dies erzeugt z.B. folgende Meldungen im Log:

ZitatMAX: Invalid value 4.5 for READING comfortTemperature. Forcing to 21
MAX: Invalid value 4.5 for READING minimumTemperature. Forcing to off
etc.

Abhilfe - diese Zeile in 10_MAX.pm

sub validTemperature { return $_[0] eq "on" || $_[0] eq "off" || ($_[0] ~~ /^\d+(\.[05])?$/ && $_[0] >= 5 && $_[0] <= 30); }


ersetzen mit

sub validTemperature { return $_[0] eq "on" || $_[0] eq "off" || ($_[0] ~~ /^\d+(\.[05])?$/ && $_[0] >= 4.5 && $_[0] <= 30.5); }


Nochmals vielen Dank und Gruss

Pet22


Debian 11/ Intel Atom MB/ CUL V3/ Raspberrymatic/ Homematic classic, Homematic IP, WTs & HTs

Matthias Gehre

Meines Erachtens ist "4.5" keine zulässige Temperatur. 4.5 wird intern benutzt, um den Zustand "off" zu codieren.
D.h. wenn du deine Thermostate auf "off" stellst, dann gibt es keinen Frostschutz. Die Regelung ist inaktiv.
Trotzdem sollte
  MAX: Invalid value 4.5 for READING minimumTemperature. Forcing to off
nicht auftreten. Eigentlich müsste der Wert 4.5 direkt als off interpretiert werden und es dürfte zu keinem
"Invalid value" kommen. Wann kommt den diese Meldung? Verbose 5 Log dazu?

Zu dem MAX_WakeUp:
Da habe ich etwas die Übersicht verloren. Wer hat bei eingeschaltetem MAX_WakeUp Probleme mit verlorenen
Packeten (=> Missing Ack) mit CUL gehabt? Wer mit Cube?
Ich dachte, es geht nur mit dem CUL nicht, aber anscheinend ging es bei dir auch mit dem Cube nicht?

John

Hallo Matthias,

ZitatD.h. wenn du deine Thermostate auf "off" stellst, dann gibt es keinen Frostschutz.

Das steht in der Bedienungsanleitung anders.

Zitat17. Frostschutzbetrieb aktivieren
...
Drehen Sie das Stellrad im manuellen Betrieb so lange
nach links, bis im Display ,,OFF" erscheint.

Frostschutz kann meiner Meinung nach nicht deaktiviert werden.

Ein weiteres Problem:
Da MinimalTemperature auf 5.0 Grad begrenzt wird, kann man tatsächlich über das Stellrad OFF nicht mehr einstellen.

Es gibt also wirklich keinen Grund 4.5 Grad nicht zuzulassen.


John
CubieTruck Docker Node-Red Tasmota Shelly Homematic-IP

Matthias Gehre

minimumTemperature kann man auf "off" stellen, nur nicht auf "4.5". Deswegen
  sub validTemperature { return $_[0] eq "on" || $_[0] eq "off" || ($_[0] ~~ /^\d+(\.[05])?$/ && $_[0] >= 5 && $_[0] <= 30); }
So jedenfalls mein Intention. Ich kann es gerade nicht testen.
Also
  set HZ minimumTemperature off
sollte gehen. Ist auch der Default-Wert.

Bei dem Frostschutz hast du wohl recht.

pet22

Matthias,

das fragliche Config File sieht so aus

## Init routine
define bad.init at *10:45:00 { \
{fhem("set max.bad ecoTemperature off")};; \
{fhem("set max.bad comfortTemperature off")};; \
}


Gestern hatte ich measurementOffset verändert, dann kamen die Log Einträge. Wenn die Limits erhöht werden, sind sie verschwunden.

Ofensichtlich hatte ich beim gestrigen Testen/ Spielen einiges mehr verdreht. Log Meldung von heute:

Zitat2013.06.30 07:49:00 2: MAX: Invalid value  for READING windowOpenTemperature. Forcing to 12
2013.06.30 07:49:00 2: MAX: Invalid value  for READING windowOpenDuration. Forcing to 15
2013.06.30 07:49:00 2: MAX: Invalid value  for READING measurementOffset. Forcing to 0

Verursacher ist folgender Teil im Config File für einen WT+:

define kizi.init.wt at *07:49:00 { \
{fhem("set thermo.kinderzimmer ecoTemperature off")};; \
{fhem("set thermo.kinderzimmer comfortTemperature off")};; \
}


Vermutung: da für alle WT(+)/ HT(+) dasselbe Array benutzt wird, werden die factory defaults eingesetzt.

Gruss

Pet22
Debian 11/ Intel Atom MB/ CUL V3/ Raspberrymatic/ Homematic classic, Homematic IP, WTs & HTs

Matthias Gehre

Also tretten die Meldungen
Zitat2013.06.30 07:49:00 2: MAX: Invalid value for READING windowOpenTemperature. Forcing to 12
2013.06.30 07:49:00 2: MAX: Invalid value for READING windowOpenDuration. Forcing to 15
2013.06.30 07:49:00 2: MAX: Invalid value for READING measurementOffset. Forcing to 0
reproduzierbar immer nach
Zitatset thermo.kinderzimmer ecoTemperature off
auf? Oder nur einmalig?

pet22

Matthias,

ZitatZu dem MAX_WakeUp:
Da habe ich etwas die Übersicht verloren. Wer hat bei eingeschaltetem MAX_WakeUp Probleme mit verlorenen
Packeten (=> Missing Ack) mit CUL gehabt? Wer mit Cube?
Ich dachte, es geht nur mit dem CUL nicht, aber anscheinend ging es bei dir auch mit dem Cube nicht?

Probleme bestanden nur bei CUBE Nutzern (siehe Beitrag Link). Nachdem der Ptach verteilt wurde, hat sich aber kein CUL Benutzer beschwert. Allerdings wird das weekProfile ja auch nicht gerade jeden Tag verändert .................

Gruss

Pet22
Debian 11/ Intel Atom MB/ CUL V3/ Raspberrymatic/ Homematic classic, Homematic IP, WTs & HTs

pet22

Ich setz mich mal heute Abend hin und drehe den Loglevel auf 5. Die Tests hatte ich mir gestern grob notiert. Also müsste es reproduzierbare Ergebisse geben.

Gruss

Pet22
Debian 11/ Intel Atom MB/ CUL V3/ Raspberrymatic/ Homematic classic, Homematic IP, WTs & HTs

pet22

Hallo Matthias,

ZitatAlso tretten die Meldungen
Zitat:

    2013.06.30 07:49:00 2: MAX: Invalid value for READING windowOpenTemperature. Forcing to 12
    2013.06.30 07:49:00 2: MAX: Invalid value for READING windowOpenDuration. Forcing to 15
    2013.06.30 07:49:00 2: MAX: Invalid value for READING measurementOffset. Forcing to 0


reproduzierbar immer nach
Zitat:

    set thermo.kinderzimmer ecoTemperature off


auf? Oder nur einmalig?

Die Meldungen kommen immer um 07:49 und nur einmal/ Tag. Wie ich in der Zwischenzeit festgestellt habe, war das aber immer schon so.
Hintergrund: ich habe einen Satz von Config Files in ein Directory/ Jahreszeit kopiert. ecoTemperature/
comfortTemperature sind einmal definiert, so dass ich es nicht im weekProfile suchen muss. Umgeschaltet wird per dummy switch.
Im Sommer macht es allerdings wenig Sinn und wird bei Gelegenheit bereinigt.

Test für minimumTemperature "off" bzw. "4.5" mit 10_MAX.pm vom Samstag, CUL inaktiv

* 20:25 set thermo.kinderzimmer weekProfile Sun 6
* 20:28 set thermo.kinderzimmer weekProfile Sun off
* 20:31 set thermo.kinderzimmer comfortTemperature 18
* 20:34 set thermo.kinderzimmer ecoTemperature 16
* 20:37 set max.bad measurementOffset 2
* 20:40 set max.bad measurementOffset 1.5

HIH

Pet22
Debian 11/ Intel Atom MB/ CUL V3/ Raspberrymatic/ Homematic classic, Homematic IP, WTs & HTs