kontinuierliche Temperaturausgabe mit MAX-Thermostaten

Begonnen von Zwer2k, 26 Februar 2013, 01:03:14

Vorheriges Thema - Nächstes Thema

Joachim

Moin Jurij,
hier das Log:
Vorraussetzungen wie in meinem letzten Post geschrieben, fhem.log gelöscht, fhem.save gelöscht, FHEM gestartet.


2013.03.01 07:55:34.083 1: Including /var/media/ftp/System/tools/fhem/fhem.cfg
2013.03.01 07:55:36.292 3: telnetPort: port 7072 opened
2013.03.01 07:55:37.434 3: WEB: port 8083 opened
2013.03.01 07:55:37.453 3: WEBphone: port 8084 opened
2013.03.01 07:55:37.471 3: WEBtablet: port 8085 opened
2013.03.01 07:55:37.981 1: Including ./FHEM/Max.cfg
2013.03.01 07:55:39.032 1: Including ./FHEM/OneWire.cfg
2013.03.01 07:55:40.189 3: Opening 1_Wire device /dev/ttyUSB0
2013.03.01 07:56:02.394 3: Setting 1_Wire baudrate to 9600
2013.03.01 07:56:02.439 3: 1_Wire device opened
2013.03.01 07:56:02.441 1: OWX: Serial device /dev/ttyUSB0 defined
2013.03.01 07:56:02.599 1: OWX: 1-Wire bus 1_Wire: interface master DS2480 re-detected
2013.03.01 07:56:02.865 3: OWTHERM: Device Temp_Sensor_Badezimmer defined.
2013.03.01 07:56:02.922 3: OWTHERM: Device Temp_Sensor_Buero defined.
2013.03.01 07:56:02.980 3: OWTHERM: Device Temp_Sensor_Flur defined.
2013.03.01 07:56:03.038 3: OWTHERM: Device Temp_Sensor_GaesteWC defined.
2013.03.01 07:56:03.093 3: OWTHERM: Device Temp_Sensor_Gaestezimmer defined.
2013.03.01 07:56:03.151 3: OWTHERM: Device Temp_Sensor_Keller defined.
2013.03.01 07:56:03.204 3: OWTHERM: Device Temp_Sensor_Kueche defined.
2013.03.01 07:56:03.262 3: OWTHERM: Device Temp_Sensor_Schlafzimmer defined.
2013.03.01 07:56:03.323 3: OWTHERM: Device Temp_Sensor_Wohnzimmer defined.
2013.03.01 07:56:03.479 3: OWTHERM: Device OWX_01_AB6F73140000 defined.
2013.03.01 07:56:03.512 3: OWTHERM: Device Temp_Sensor_Kuehlschrank defined.
2013.03.01 07:56:03.570 3: OWTHERM: Device Temp_Sensor_Kuehltruhe defined.
2013.03.01 07:56:03.618 1: Including ./FHEM/FileLog.cfg
2013.03.01 07:56:04.081 1: Including ./FHEM/WHR960.cfg
2013.03.01 07:56:04.178 3: Opening WHR960 device /dev/ttyUSB1
2013.03.01 07:56:04.191 3: Setting WHR960 baudrate to 9600
2013.03.01 07:56:04.223 3: WHR960 device opened
2013.03.01 07:56:04.803 2: SecurityCheck:  WEB,WEBphone,WEBtablet has no basicAuth attribute. telnetPort has no password/globalpassword attribute.  Restart fhem for a new check if the problem is fixed, or set the global attribute motd to none to supress this message.
2013.03.01 07:56:04.808 0: Server started with 57 defined entities (version Fhem 5.3 (DEVELOPMENT), $Id: fhem.pl 2803 2013-02-25 11:04:38Z rudolfkoenig $, pid 20539)
2013.03.01 07:56:04.812 3: Opening Max_Cube device 172.16.19.100:62910
2013.03.01 07:56:04.844 3: Max_Cube device opened
2013.03.01 07:56:13.420 3: Zeile 15  therm HK_Regler_Badezimmer
2013.03.01 07:56:13.423 1: HK_Regler_Badezimmer-Fri Mar  1 07:56:13 2013-1362124573-Fri Mar  1 08:11:57 2013-1362125517
2013.03.01 07:56:13.443 3: Zeile 15  therm HK_Regler_Buero
2013.03.01 07:56:13.446 1: HK_Regler_Buero-Fri Mar  1 07:56:13 2013-1362124573-Fri Mar  1 08:11:57 2013-1362125517
2013.03.01 07:56:13.459 3: Zeile 15  therm HK_Regler_Flur
2013.03.01 07:56:13.462 1: HK_Regler_Flur-Fri Mar  1 07:56:13 2013-1362124573-Fri Mar  1 08:11:58 2013-1362125518
2013.03.01 07:56:13.474 3: Zeile 15  therm HK_Regler_GaesteWC
2013.03.01 07:56:13.478 1: HK_Regler_GaesteWC-Fri Mar  1 07:56:13 2013-1362124573-Fri Mar  1 08:11:57 2013-1362125517
2013.03.01 07:56:13.490 3: Zeile 15  therm HK_Regler_Gaestezimmer
2013.03.01 07:56:13.493 1: HK_Regler_Gaestezimmer-Fri Mar  1 07:56:13 2013-1362124573-Fri Mar  1 08:11:57 2013-1362125517
2013.03.01 07:56:13.505 3: Zeile 15  therm HK_Regler_Kueche
2013.03.01 07:56:13.509 1: HK_Regler_Kueche-Fri Mar  1 07:56:13 2013-1362124573-Fri Mar  1 08:11:56 2013-1362125516
2013.03.01 07:56:13.521 3: Zeile 15  therm HK_Regler_Schlafzimmer
2013.03.01 07:56:13.524 1: HK_Regler_Schlafzimmer-Fri Mar  1 07:56:13 2013-1362124573-Fri Mar  1 08:11:56 2013-1362125516
2013.03.01 07:56:13.536 3: Zeile 15  therm HK_Regler_Wohnzimmer_li
2013.03.01 07:56:13.540 1: HK_Regler_Wohnzimmer_li-Fri Mar  1 07:56:13 2013-1362124573-Thu Jan  1 00:15:45 1970-945


und FHEM bleibt bei 99% stehen

Gruß Joachim
FHEM aktuellste Version auf FB 7570 und 7390 mit Zebradem Toolbox Freetz
FHEM auf Raspberry
1-Wire mit LinkUSBi und Rs-Pi ds2482-800  1-Wire-9 Board; Max mit Cube, HMLAN
div. 1-Wire Sensoren; MAX-Thermostaten; Homematic-Komponenten, Zehnder KWL über RS-232

Zwer2k

Hallo Joachim,

Füg mal die Zeile
next if (($th_time eq '') || ($th_val eq '') || ($th_mode eq ''));
nach der Zeile
my $th_mode = $defs{$therm}{READINGS}{"mode"}{VAL};
ein.

Das wird damit bewirkt:
So lange eine von den Variablen $th_time, $th_val oder $th_mode nicht gesetzt ist, darf der Script nicht fortfahren.
Die Aufzeichnung von einem Thermostat startet erst wenn der Thermostat seine Werte geliefert hat, durch das ändern des "mode" von auto in manual für 2 Min. kann die Ausgabe erzwungen werden.
     

Komischerweise hat bei dir aber nur der HK_Regler_Wohnzimmer_li-Fri keine Werte geliefert, alle anderen passen ja.

Joachim

Moin Jurij,

Die Zeile

next if (($th_time eq '') || ($th_val eq '') || ($th_mode eq ''));

Habe ich eingefügt, und das hängen von FHEM ist damit beseitigt.

Jetzt taucht das nächste Problem auf,

Der Cube sendet leider alte Werte, so dass eine kontinuirliche Temperaturausgabe nicht hinhaut.

(siehe Anhang / see attachement)

Ich muss mich jetzt wohl doch in Deinen Code hineinfummeln, um die Auto<>Manuell Umschalltung alle
x Minuten zu erzwingen.

Gruß Joachim
FHEM aktuellste Version auf FB 7570 und 7390 mit Zebradem Toolbox Freetz
FHEM auf Raspberry
1-Wire mit LinkUSBi und Rs-Pi ds2482-800  1-Wire-9 Board; Max mit Cube, HMLAN
div. 1-Wire Sensoren; MAX-Thermostaten; Homematic-Komponenten, Zehnder KWL über RS-232

Zwer2k

Hallo Joachim,

hab leider kein CUBE sondern nur ein CUL.

Du hast doch geschrieben, dass es zuvor funktioniert hat, du hattest nur Probleme nach löschen von fhem.save. Ist es so?
Wenn ja, dann muss es an der Zeile hängen.
next if (($th_time eq '') || ($th_val eq '') || ($th_mode eq ''));


Hab hier mal paar Loging-Zeilen eingebaut. Was gibt der Code aus?
Setze am besten den Interval runter auf 6 Min.

sub ForceMAXTempUpdate {
  my $UpdateInterval = $_[0];
  my @UpdateThermostat =  @{$_[1]};

  $UpdateInterval++ if ($UpdateInterval % 2 != 0);
  foreach my $therm (@UpdateThermostat) {
    my $curTime = gmtime() + localtime()->tzoffset;
    if ((!defined($main::NextUpdate{$therm}{"NextUpdate"})) || ($curTime>$main::NextUpdate{$therm}{"NextUpdate"})){
      my $th_time = $defs{$therm}{READINGS}{"temperature"}{TIME};
      my $th_val = $defs{$therm}{READINGS}{"desiredTemperature"}{VAL};
      my $th_mode = $defs{$therm}{READINGS}{"mode"}{VAL};
      Log (1, "-1-".$therm."-".$th_time."-".$th_val."-".$th_mode);
      next if (($th_time eq '') || ($th_val eq '') || ($th_mode eq ''));
      my $tempTime=Time::Piece->strptime($th_time, "%Y-%m-%d %H:%M:%S");
      my $nextPlan = $tempTime + $UpdateInterval * 60 - 15;
      my $nextUpd = $nextPlan;
      Log (1, "-2-".$therm."-".$curTime."".$curTime->epoch."-".$nextUpd."-".$nextUpd->epoch);
      $nextUpd = $nextUpd + 60 * 2 while($curTime->epoch > $nextUpd->epoch);

      Log (1, "-3-".$therm."-".$main::NextUpdate{$therm}{"NextUpdate"});
      if (defined($main::NextUpdate{$therm}{"NextUpdate"})){
        Log (1, "-4-".$therm."-".$main::NextUpdate{$therm}{"Started"});
        if (!defined($main::NextUpdate{$therm}{"Started"})){
          Log (1, "-5-".$therm."-".$nextPlan);
          if ($nextPlan > $main::NextUpdate{$therm}{"NextUpdate"}) {
            $main::NextUpdate{$therm}{"NextUpdate"} = $nextUpd;
            return;
          }
          if (($th_mode eq "auto") || ($th_mode eq "manual")){
            fhem("set ".$therm." desiredTemperature "
                 .($th_mode eq "manual" ? "auto" : "")." ".$th_val);
            $main::NextUpdate{$therm}{"Started"} = $curTime;
            $main::NextUpdate{$therm}{"temp"} = $th_val;
            $main::NextUpdate{$therm}{"mode"} = $th_mode;
          }
        } else {
          my $oldMode = $main::NextUpdate{$therm}{"mode"};
          my $oldTemp = $main::NextUpdate{$therm}{"temp"};
          Log (1, "-6-".$therm."-".$tempTime);
          if ($tempTime > $main::NextUpdate{$therm}{"Started"}){
            if (($th_mode eq ($oldMode eq "auto" ? "manual" : "auto")) && ($th_val eq $main::NextUpdate{$therm}{"temp"})){
              fhem("set ".$therm." desiredTemperature ".($oldMode eq "auto" ? "auto " : "").$oldTemp);
            }
            undef $main::NextUpdate{$therm}{"Started"};
            $main::NextUpdate{$therm}{"NextUpdate"} = $nextUpd;
          } else {
            if ($curTime > $main::NextUpdate{$therm}{"Started"} + 60 * 4) {
              fhem("set ".$therm." desiredTemperature ".($oldMode eq "auto" ? "auto " : "").$oldTemp);
              undef $main::NextUpdate{$therm}{"Started"};
              $main::NextUpdate{$therm}{"NextUpdate"} = $nextUpd;
            }
          }
        }
      } else {
        $main::NextUpdate{$therm} = ();
        $main::NextUpdate{$therm}{"NextUpdate"} = $nextUpd;
      }
      $main::NextUpdate{$therm}{"CurTime"} = $curTime;
    }
  }
}

Joachim

Hallo Jurij,

ich muß wohl an meinen Formulierungen arbeiten,
Mit dem funktionieren meinte ich die herausnahme von Date/Time.

Ich habe jetzt das neue Script eingebunden, wie immer alle Logs und die fhem.save gelöscht, das intervall auf 6 Min
gestellt, und der übersichtlichkeit halber nur HK_Regler_Buero und HK_Regler_Wohnzimmer_re in deinem Script laufen. Dann FHEM neu gestartet.
Da die Logs relativ lang sind, sind diese im Anhang.

Gruß Joachim
FHEM aktuellste Version auf FB 7570 und 7390 mit Zebradem Toolbox Freetz
FHEM auf Raspberry
1-Wire mit LinkUSBi und Rs-Pi ds2482-800  1-Wire-9 Board; Max mit Cube, HMLAN
div. 1-Wire Sensoren; MAX-Thermostaten; Homematic-Komponenten, Zehnder KWL über RS-232

Zwer2k

Hallo Joachim,

da von dem Cube nicht der Zeitpunkt der Temperaturerfassung geliefert wird, kann auch nicht optimale Zeitpunkt für die Auto<>Manuell Schaltung berechnet werden, d.h. es muss nach der Umschaltung 2 Min. gewartet werden bis die Wiederherstellung des Zustandes erfolgen kann.

Hab mal den Code angepasst. Es sollte automatisch zwischen Thermostaten die an Cul oder Cube hängen unterschieden werden (bei Thermostaten an Cube sollte Wert von IODev ungleich CULMAX* sein).
Sollte es nicht funktionieren, dann mal mit 60*3 an Stelle von 60*2 testen. Ansonsten die Log-Zeilen wider einfügen und die Logs posten.

sub ForceMAXTempUpdate {
  my $UpdateInterval = $_[0];
  my @UpdateThermostat =  @{$_[1]};

  $UpdateInterval++ if ($UpdateInterval % 2 != 0);
  foreach my $therm (@UpdateThermostat) {
    my $curTime = gmtime() + localtime()->tzoffset;
    my $onCUL = (index($defs{$therm}{IODev}{NAME}, 'CULMAX') >= 0);
    if ((!defined($main::NextUpdate{$therm}{"NextUpdate"})) || ($curTime>$main::NextUpdate{$therm}{"NextUpdate"})){
      my $th_time = $defs{$therm}{READINGS}{"temperature"}{TIME};
      my $th_val = $defs{$therm}{READINGS}{"desiredTemperature"}{VAL};
      my $th_mode = $defs{$therm}{READINGS}{"mode"}{VAL};
      next if (($th_time eq '') || ($th_val eq '') || ($th_mode eq ''));
      my $tempTime=Time::Piece->strptime($th_time, "%Y-%m-%d %H:%M:%S");
      my $nextPlan = $tempTime + $UpdateInterval * 60 - 15;
      my $nextUpd = $nextPlan;
      $nextUpd = $nextUpd + 60 * 2 while($curTime > $nextUpd);
      if (defined($main::NextUpdate{$therm}{"NextUpdate"})){
        if (!defined($main::NextUpdate{$therm}{"Started"})){
          if (($onCUL) && ($nextPlan > $main::NextUpdate{$therm}{"NextUpdate"})) {
            $main::NextUpdate{$therm}{"NextUpdate"} = $nextUpd;
            return;
          }
          if (($th_mode eq "auto") || ($th_mode eq "manual")){
            fhem("set ".$therm." desiredTemperature "
                 .($th_mode eq "manual" ? "auto" : "")." ".$th_val);
            $main::NextUpdate{$therm}{"Started"} = $curTime;
            $main::NextUpdate{$therm}{"temp"} = $th_val;
            $main::NextUpdate{$therm}{"mode"} = $th_mode;
          }
        } elsif (($onCUL) || ($curTime>$main::NextUpdate{$therm}{"Started"}+60*2)) {
          my $oldMode = $main::NextUpdate{$therm}{"mode"};
          my $oldTemp = $main::NextUpdate{$therm}{"temp"};
          if ($tempTime > $main::NextUpdate{$therm}{"Started"}){
            if (($th_mode eq ($oldMode eq "auto" ? "manual" : "auto")) && ($th_val eq $main::NextUpdate{$therm}{"temp"})){
              fhem("set ".$therm." desiredTemperature ".($oldMode eq "auto" ? "auto " : "").$oldTemp);
            }
            undef $main::NextUpdate{$therm}{"Started"};
            $main::NextUpdate{$therm}{"NextUpdate"} = $nextUpd;
          } else {
            if ($curTime > $main::NextUpdate{$therm}{"Started"} + 60 * 4) {
              fhem("set ".$therm." desiredTemperature ".($oldMode eq "auto" ? "auto " : "").$oldTemp);
              undef $main::NextUpdate{$therm}{"Started"};
              $main::NextUpdate{$therm}{"NextUpdate"} = $nextUpd;
            }
          }
        }
      } else {
        $main::NextUpdate{$therm} = ();
        $main::NextUpdate{$therm}{"NextUpdate"} = $nextUpd;
      }
      $main::NextUpdate{$therm}{"CurTime"} = $curTime;
    }
  }
}


Joachim

Moin Jurij,

hab mal die geänderte Version incl. Logzeilen hineingebastelt.
Das Grundsystem läuft, allerdings gibt es nach einem Komplettneustart inclusive Cube und Löschen von fhem.save noch ein Problem, siehe Log 1.
Erst wenn der Cube das erste mal eine Temperatur gesendet hat, beginnt die regelmäßige Aktualisierung.

Ich habe jetzt mal mit meinen begrenzten Perlkenntnissen folgende Zeilen zusätzlich eingefügt,


if ((!defined($main::NextUpdate{$therm}{"NextUpdate"})) || ($curTime>$main::NextUpdate{$therm}{"NextUpdate"})){
      my $th_time = $defs{$therm}{READINGS}{"temperature"}{TIME};
      ###########################################################
      if ($th_time eq ''){
      $th_time = $defs{$therm}{READINGS}{"desiredTemperature"}{TIME}; # Schoener waere aktuelle Zeit/Systemzeit
      Log 1, "geborgte Zeit $th_time";                                # bzw. direkter Anstoss zum Umschalten
      }                                                               # Auto/Manuell
      ###########################################################
      my $th_val = $defs{$therm}{READINGS}{"desiredTemperature"}{VAL};


siehe Log 2
dann hat man nach spätestens Intervall + 2 Minuten die aktuellen Temperaturen, siehe Log 3

Besten Dank ersteinmal für die Hilfe bis hierher.

Gruß Joachim

FHEM aktuellste Version auf FB 7570 und 7390 mit Zebradem Toolbox Freetz
FHEM auf Raspberry
1-Wire mit LinkUSBi und Rs-Pi ds2482-800  1-Wire-9 Board; Max mit Cube, HMLAN
div. 1-Wire Sensoren; MAX-Thermostaten; Homematic-Komponenten, Zehnder KWL über RS-232

Zwer2k

Hallo Joachim,

das ist kein Problem, sondern es ist so Programmiert. Der Script muss ein definierten Zustand haben, sonst kann der nicht wissen in welchen Zustand der Thermostat anschließend zurückgestellt werden soll. Um Aufzeichnung anzustoßen musst du manuell den Thermostat für 2 Min. in anderen Modus versetzen, wenn ein Messwert geliefert wurde beginnt die Aufzeichnung, anschließend kannst du den Thermostat zurück schalten.

Gruß
Jurij

Joachim

Danke Jurij,

also einmal nach dem Neustart von Hand in FHEM (oder am Thermostat?) den Modus umschalten, und dann rennt es.
Ich lasse das ganze jetzt mal einige Zeit laufen, und schaue, ob sich noch Fragen ergeben.

Gruß Joachim
FHEM aktuellste Version auf FB 7570 und 7390 mit Zebradem Toolbox Freetz
FHEM auf Raspberry
1-Wire mit LinkUSBi und Rs-Pi ds2482-800  1-Wire-9 Board; Max mit Cube, HMLAN
div. 1-Wire Sensoren; MAX-Thermostaten; Homematic-Komponenten, Zehnder KWL über RS-232

John

Ich hab mich mit der Idee und dem Script von Jurij befasst und dieses implementiert.

Die verbesserte Darstellung der Temperatur ist wirklich sehr hilfreich.

Folgende Probleme/ Erfahrungen sind aufgetaucht

a. 3 Minuten Pollzeit statt 2 Minuten
Meine Thermostate (HeatingThermostatPlus) scheinen nicht im 2 sondern im 3 Minuten Takt zu ticken.
Dies lässt sich im Skript einfach anpassen.

   
b.  Credits werden verbraten
bei Abtastrate 9 Minuten und 4 Thermostaten kam es zu folgendem Problem
2013.03.08 10:12:57 2: CUL_MAX_SendQueueHandler: Not enough credit! credit10ms is 2, but we need 110. Waiting 108 seconds.
2013.03.08 10:14:47 2: CUL_MAX_SendQueueHandler: Not enough credit! credit10ms is 2, but we need 110. Waiting 108 seconds.


Wenn wir mit 15 Minuten Scanrate rechnen:
2 Sendepakete pro Tastpunkt (manuell-> auto und zurück)
4 Tastpunkte pro Thermostat pro Stunde  => 8 Sendepakete
bei 4 Thermostatventile => 32 Sendepakete pro Stunde

Laut Link
sind 33 Nachrichten pro Stunde möglich. Dies gilt wohl auch für den CUL.

Damit sehe ich folgende Gefahr:

- das Timing des Scripts selbst ist gestört, da es nicht die Wartezeiten durch Queueing berücksichtigt.
- das Queueing von CULMAX eskaliert, die Queue wird unendlich gross, ebenso die Verzögerung von Sende-Telegrammen
- der zeitliche Kontext geht komplett verloren, so dass z.B. ein neuer Sollwert eines Heating_Controls
  zeitlich stark verzögert und damit unsinnig zur falschen Zeit gesetzt wird.

Es wäre also wichtig die Credits im Auge zu behalten.
Also nur dann eine Temperaturübertragung anstossen, wenn ausreichend Credits vorhanden sind.

Eine mögliche Verbesserung:
kein zwingendes Zurückfallen in die vorherige Betriebsart (manuell-> auto -> manuell)
sondern Beibehalten der neuen Betriebsart.
Dies wird die Sendepakete um die Hälfte reduzieren.
Durch Reduzierung der Schaltpunkte in Automatik z.B. auf 00.00 Uhr und Ausklammern des Schaltzeitpunktes
bei der Erfassung der Temperatur könnte dies erreicht werden.


c. während der Umschaltzeit zu Automatik tritt ein Schaltpunkt ein

Das vorgestellte Prinzip lebt davon, dass die Betriebsart wechselt (auto<>manuell)
Wenn nun im Automatikmodus, auch wenn dieser nur kurz anliegt ein Schaltpunkt ansteht,
wird der Sollwert geändert und vom Skript nicht korrigiert.

Selbst die kurze Zeit von wenigen Sekunden, kann dazu führen, dass ungewollt ein neuer Sollwert
im Auto-Modus eingestellt wird.

Ich habe versucht dieses Problem zu minimieren, durch Reduzierung der Schaltpunkte auf einen einzigen im Wochenprogramm des Thermostats .

weekprofile-3-Tue-temp    15.0 °C          2013-03-08 22:20:02
weekprofile-3-Tue-time    00:00-00:00      2013-03-08 22:20:02

d. Fensterkontakt
Wenn das Thermostatventil mit einem Schutterkontakt gepaired ist, wird beim Öffnen des Fensters als desiredTemperature
die WindowsopenTemperature übertragen. In diesem Zustand, darf desiredTemperature vom ForceMAXTempUpdate nicht gesetzt werden, sonst bleibt  WindowsopenTemperature dauerhaft als Sollwert gesetzt.

e. Latenzprobleme

Es kam tatsächlich vor, dass HeatingControl einen neuen Sollwert setzte und noch bevor die
Rückmeldung kam von ForceMAXTempUpdate ebenfalls der nun jedoch alte Sollwert gesetzt wurde und somit die Änderung von HeatingControl überschrieb.


Eigene Implementierung


Ich habe das modifizierte Skript in einem eigenen Thread vorgestellt:
Link

CubieTruck Docker Node-Red Tasmota Shelly Homematic-IP

svenkoethe

Hallo,

wenn ich das Script so einsetze wie oben beschrieben, dann geht fhem bei mir sofort auf 100% Systemlast und nix geht mehr.

Kann dann nur per Telnet den Prozess killen. (kill force)
Bei Neustart hängt es sofort wieder.
Log-Einträge gibt es dazu leider überhaupt keine (zumindest kann ich keinen Zusammanhang erkennen)

Das ganze sollte laufen auf:
- Synolgy NAS mit den Paketen von Martin Fischer
- CUL 868
- ein MAX Thermostat(Testphase)

Kann mir jmd weiterhelfen ?

Zwer2k

Hallo svenkoethe,

hast du Änderungen aus diesem Post mit übernommen?

Gruß
Jurij

Harald

Hallo Jurij,

ich wollte Dein Skript mal ausprobieren. Leider erhalte ich ich nsch dem Speichern meiner geänderten 99_myUtils.pm folgende Fehlermelddung:

Global symbol "$th_val" requires explicit package name at ./FHEM/99_myUtils.pm in Zeile ....

und im Logfile steht:

2013.06.21 11:10:38 3: Undefined subroutine &main::ForceMAXTempUpdate called at (eval 2140) line 1.

Was habe ich da falsch gemacht? Kannst Du mir evtl. helfen?

Vielen Dank im Voraus

Harald

PS: Hat sich erledigt. War mein Fehler, hatte 1 Zeile zu viel gelöscht :-(  UND ES FUNKTIONIERT ! Besten Dank, Jurij für Deine tolle Arbeit!
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

Leider zu früh gefreut :-(

Telnet meldet mir "Use off uninitialized value in index of ./FHEM/99_myUtils.pm line 66".
Dort steht "    my $onCUL = (index($defs{$therm}{IODev}{NAME}, 'CULMAX') >= 0);  "

Meine Thermostate werden vom Qube gesteuert und nicht vom CUL.

Wie bekomme ich die Fehlermeldung weg?

Viele Grüße

Harald

Nachtrag: So, ich hab's hinbekommen. Ich habe alles, was mit $onCUL zu tun hat, entfernt und die Fehlermeldungen sind weg.
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

Hallo Jurij,

ich habe Dein Modul jetzt bei mir laufen. Allerdings musste ich einiges anpassen (s.o.) Alles andere ist geblieben. Es scheit auch zu klappen. Zumindest werden die Temperaturkurven über den ganzen Tag geschrieben. Vorher hörten sie bei Inaktivität der Ventile (weil über längere Zeit kein Heizen angefordert wurde) einfach mittendrin auf.
So sieht meine fhem.cfg aus:
# kontinuierliche Temperaturausgabe mit MAX-Thermostaten
#
define at_ForceMAXTempUpdate at +*00:03:00 {\
my @MaxThermostate = ("Bad", "Computer", "Flur", "Kueche", "Wohnzimmer1", "Wohnzimmer2", "Wohnzimmer3");;\
my $Interval = 30;;\
&ForceMAXTempUpdate($Interval, \@MaxThermostate);;\
}

Ich habe im fhem.log hin und wieder folgende Meldung:
2013.06.27 00:36:10 1: MAXLAN_ReadSingleResponse: timeout while reading from socket, disconnecting
2013.06.27 00:36:10 1: MAXLAN_ExpectAnswer: Error while waiting for answer H:
2013.06.27 00:36:10 3: set Wohnzimmer1 desiredTemperature  17.0 : MAXLAN_Write: MAXLAN_Connect: MAXLAN_ExpectAnswer: Error while waiting for answer H:

Ich vermute, dass es trotz eines Intervals von 30 Min. gelegentlich (Abstand von ca. 6 Std.) ab und zu Probleme mit DutyCycle gibt. Es sind immerhin 7 Thermostate und der ECO-Taster zu bedienen.

Weiß jemand, in welchem Interval der Qube die Ventile usw. abfragt?

Kann man nicht statt Modeumschaltung vielleicht die Ventilöffnung beeinflussen? Dann könnte man doch beim 1. Durchlauf Ventilöffnung + 2 und beim nächsten -2 setzen. Das würde den Funkverkehr auch halbieren und hätte geringen Einfluss auf die Funktion, oder?
Oder kann man den Qube dazu bewegen, die Ventile als Gruppe zu sehen, so dass nur ein Befehl an alle Ventile gleichzeitig gesendet werden muss?
Entschuldigt bitte meine naiven Fragen. Ich habe bisher keine ordentliche Beschreibung der möglichen Befehle an den Qube gefunden.

Achja, noch eine Frage: Warum ist "at_ForceMAXTempUpdate" auf 10 Sek. gesetzt? Das benötigt doch einiges an Prozessoraktivität. Ist das so erforderlich oder klappt das auch mit den von mir gewählten 3 Min. oder ggf. mit noch längeren Zeiten vernünftig?

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