Temperatur-Scanner für MAX-Thermostate

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

Vorheriges Thema - Nächstes Thema

Harald

#480
Vielen Dank John für den Hinweis,

meine Änderung bewirkt, dass dann, wenn auf ECO-Modus über das Webinterface (für einzelne: desiredTemperature=eco) oder mittels des ECO-Tasters des MAX!-Systems (für alle gemeinsam) auf Eco-Modus geschaltet wurde, dieser Zustand bestehen bleibt, bis wieder auf Auto-Modus geschaltet wird. Das Zurückschalten in den Automodus, wenn ein Schaltpunkt erreicht ist, wird also verhindert.

Ich habe folgende Änderungen eingefügt:nach Zeile ~ 573
+       my $isEco=0;
+ $isEco=1 if (($strMode eq "manual")&&(($numDesiTemp=$numEcoTemp)||($numDesiTemp=$numEcoTemp+0.5)||($numDesiTemp=$numEcoTemp-0.5)));
my $switchDate = (defined($weekProfile)) ? $weekProfile->{nextSwitchDate}:$sdDesiTime; 
        $hash->{helper}{switchDate}    = $switchDate if (!defined($hash->{helper}{switchDate}));   
        # wenn sich switchDate geändert hat, dann lead desi anpassen
    if ($hash->{helper}{switchDate} != $switchDate)
    {
      $hash->{helper}{switchDate}   =  $switchDate;
      $hash->{helper}{leadDesiTemp} =  $normDesiTemp;
      $hash->{helper}{desiredOffset}=  0;
      MaxScan_Log $hash,($MaxScanDEBUGLeadTemp)?2:3,"reset leadDesiTemp:".$hash->{helper}{leadDesiTemp};
   
      # wenn wir in manu sind, muessen wir auf auto umschalten, damit der sollwert uebernommen wird
-     if (($strMode eq "manual") && ($normDesiTemp != $numDesiTemp))
+     if (($strMode eq "manual") && ($normDesiTemp != $numDesiTemp)&&($isEco==0))
      {
        my $cmd="set $therm desiredTemperature auto";
        fhem($cmd);
        MaxScan_Log $hash,($MaxScanDEBUGLeadTemp)?2:3,"switchTime: $cmd";
      } 
      next;  # neuer desired vom schaltprogramm könnte noch nicht da sein, daher hier ende und zeit abwarten
   }
.
.
.
und nach Zeile ~ 728
          my $newTemp =$leadDesiTemp + $hash->{helper}{desiredOffset};
          $cmd="set $therm desiredTemperature auto $newTemp";
+         $cmd="set $therm desiredTemperature $newTemp" if ($isEco==1);
        }
        else      # toggle auto-manu mode, da $numForceAuto=0
        {
          $cmd="set $therm desiredTemperature ".($strMode eq "manual" ? "auto" : "")." $leadDesiTemp";
        }
       
        fhem($cmd);
       
-       MaxScan_Log $hash,($MaxScanDEBUGSet)?2:3,"<<$cmd>>";
+       MaxScan_Log $hash,($MaxScanDEBUGSet)?2:3,"<<$cmd>>, Eco-Mode:$isEco";

Man kann das sicherlich eleganter machen, aber es funktioniert schonmal. Allerdings ist der Tageswechsel noch nicht getestet.

Nochmals besten Dank für die Hilfe und viele Grüße

Harald
Router:AVM7590 1&1 FW:FRITZ!OS 07.56 Anbindung:1&1 50/10 Mb/s, WLAN-Repeater 300E
ELV MAX!Cube, 7xThermostat, ECO, RasPi 4B mit bullseye auf Festplatte,
CUL V 1.67, JeeLink v3_10.1c, nanoCUL, 1xS300TH, 4xHMS100T, 4xELRO, 1xTFA, 2xMAX_FK
ELV MAX!1.4.5, FHEM 5.7 auf RasPi, Kostal PIKO plus

Harald

#481
So, der Tageswechsel klappt auch wie von mir gewünscht. Der ECO-Modus wird weitergeführt, bis wieder auf Auto geschaltet wird.

Ich habe nachdem der ECO-Modus für alle Ventile angewählt war, 2 über die WEB-Oberfläche wieder auf Auto gesetzt. Auch das funktionierte wie gewollt. Diese Ventile standen heute Morgen auf Auto und haben die Räume aufgeheizt.

Weiterhin wurde Ventil Bad gegen 8:00 am Handrad von 20°C auf 24°C gestellt. MaxScan hat brav diese Temperatur gehalten und beim nächsten Schaltpunkt auf den dann programmierte Sollwert gestellt.

Das sind genau die Funktionen, die ich haben wollte. Nochmals herzlichen Dank an John für das Modul und die geleistete Hilfe.

Viele Grüße ind ein schönes Wochenende

Harald
Nachtrag: Meine Änderung funktioniert nur im Modus Umschaltung der Solltemperatur sicher, also  onlyAutoMode { return "1";} !
Bei Auto/Manual, also onlyAutoMode { return "0";} klappt das nicht einwandfrei, da ja der ECO-Modus = manual und Eco-Temperatur ist. Es wird dann  durch die Modus-Umschaltung manchmal der ECO-Mode verlassen und in Auto mit Autotemperatur geschaltet, ist also nicht betriebssicher.
Router:AVM7590 1&1 FW:FRITZ!OS 07.56 Anbindung:1&1 50/10 Mb/s, WLAN-Repeater 300E
ELV MAX!Cube, 7xThermostat, ECO, RasPi 4B mit bullseye auf Festplatte,
CUL V 1.67, JeeLink v3_10.1c, nanoCUL, 1xS300TH, 4xHMS100T, 4xELRO, 1xTFA, 2xMAX_FK
ELV MAX!1.4.5, FHEM 5.7 auf RasPi, Kostal PIKO plus

der-Lolo

Das klingt toll Harald, wäre es auch möglich einen Dummy als Eco Taster einzusetzen? Also z.b. Auf ein abwesend im Kalender?
Eco wäre verreist,Auto wäre ein programmiertes wochenprogramm und Comfort wäre Bluetooth Anwesenheit...
Mit welcher Scan-Methode arbeitest du in diesem fall?

Harald

#483
Hallo der-Lolo,

wie ich oben schon schrieb, nutze ich das MAX!-System incl. Cube und ECO-Taster als autarke Heizungssteuerung. FHEM wird nur zur Überwachung und Anzeige eingesetzt. Darauf ist meine Lösung zugeschnitten. Wie Du sicherlich weißt, ist mit FHEM vieles bis fast alles möglich und damit warscheinlich auch Deine Wünsche, man muss es "nur" programmieren.

John plant, soviel ich weiß, die ECO-Tasterfunktion noch in sein Modul einzubinden. Dann wird es wohl auch für CUL-basierende Systeme funktionieren.
Da ich hoffte, dass eine nur Cube-Lösung auch mit meinen geringen Kenntnissen von FHEM und Perl machbar sei, habe ich mich daran gesetzt und eben oben beschriebene, für mich brauchbare Lösung mit John's Hilfe gefunden. Diese hat schon einige Einschränkungen, wie ich sie auch schon beschrieben habe, die für mich aber nicht relevant sind.

Wenn jemand meine Löung gebrauchen kann oder evtl. weiter entwickelt, würde es mich freuen.

Viele Grüße

Harald
Router:AVM7590 1&1 FW:FRITZ!OS 07.56 Anbindung:1&1 50/10 Mb/s, WLAN-Repeater 300E
ELV MAX!Cube, 7xThermostat, ECO, RasPi 4B mit bullseye auf Festplatte,
CUL V 1.67, JeeLink v3_10.1c, nanoCUL, 1xS300TH, 4xHMS100T, 4xELRO, 1xTFA, 2xMAX_FK
ELV MAX!1.4.5, FHEM 5.7 auf RasPi, Kostal PIKO plus

Stephan

Ich finde es super, wie hier zusammen gearbeitet wird. Leider kann ich mich zur Zeit nicht am testen beteiligen mangels Heizung. Hoffe, das das bald ein Ende hat.

Gruss
Stephan
   

Gruß
Stephan

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

Stephan

Meine Weekprofile verschwinden aus den Thermostaten.
Damit bin ich nicht der einzige.

http://forum.fhem.de/index.php/topic,17367.0.html

Kann das was mit dem Scanner zu tun haben? Das ist bei mir erst seit 1.05a. Ob der Scanner aber die Ursache ist?


Gruß
Stephan

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

Stephan

Und die Aussage, das man nur einen Tag im Weekprofile ändern muss, damit alle Tage wieder im Wochenprofil erscheinen, trifft bei mir auch zu.
Gruß
Stephan

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

Stephan

Eine Frage an John:

Gibt es die Möglichkeit, das Scanintervall ein bisschen hoch zu setzen. Vielleicht über eine Variable?
Ich orgel immer am credit limit rum und wenn ich kommandos absetzte, dauert es ewig, bs die angenommen werden.

Gruß
Stephan

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

John

Hallo Stephan,
derzeit leider nicht.
In der kommenden Modulvariante will ich das berücksichtigen.

Ich orgel immer am credit limit rum und wenn ich kommandos absetzte, dauert es ewig, bs die angenommen werden.
Der Scanner legt eigentlich erst los, wenn die Credits > 300 sind, da sollte genug Luft für anderes bleiben.

Dies wird über die Variable $numCreditMin gesteuert, mit der kannst du experimentieren.
Wenn du diese höher setzte, bleiben eben mehr in Reserve.

John

CubieTruck Docker Node-Red Tasmota Shelly Homematic-IP

cotecmania

Ist fuer das kommende Modul nur ein allgemeiner ECO-Modus geplant, oder gibt's auch ne Lösung dafür, nur einzelne MAXe auf ECO zu schalten ?
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

Stephan

Zitat von: Stephan am 14 Dezember 2013, 16:12:01
Und die Aussage, das man nur einen Tag im Weekprofile ändern muss, damit alle Tage wieder im Wochenprofil erscheinen, trifft bei mir auch zu.

Nun zum zweiten Male und nicht nur bei einem Thermostat.
Gruß
Stephan

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

Stephan

Jetzt ist bei allen Thermostaten das Programm weg. Ursache ist mir schleierhaft.
Gruß
Stephan

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

Stephan

Die Settings meines HT sehen aus wie im Anhang.
Ein Wochenprofil ist aktiv. Es sieht rund um die Uhr 29 Grad vor.
Stelle ich auf "auto", kommt desired temperature 17 Grad.
Manuell schalten auf 29 Grad funktioniert, nach schalten auf Auto steht wieder 17 Grad am Thermostaten.

Das blicke ich überhaupt nicht. Gibt mir mal bitte jemand einen Tipp?
Gruß
Stephan

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

shorty81

Da schließe ich mich gerne an. Auch bei mir führt Umstellung auf Auto zu 17 Grad DesiredTemp.
Ebenso bei Schaltpunkten aus dem Wochenprofil. Ständig stehen die Thermostate auf 17 Grad ;(
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

@Stephan und @shorty81

wir haben beim weekprofile noch ein ungeklärtes Problem mit den 17 Grad,
das jedoch nicht dem Scanner anzulasten ist.

siehe
http://forum.fhem.de/index.php/topic,17231.msg112738.html#msg112738

hier ist auch der Workaround beschrieben.

Ich hoffe das hilft weiter.

Das Problem der verschwindenden Weekprofiles habe ich noch nicht festgestellt, der Scanner liest diese im übrigen nur aus.

John
CubieTruck Docker Node-Red Tasmota Shelly Homematic-IP