Hauptmenü

MaxValveSetting

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

Vorheriges Thema - Nächstes Thema

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