Modul weekprofile + FHEMWEB widget

[VolkerGBenner]

Das Problem bei MAX! ist, dass die in den Thermostaten gespeicherten Wochenprofile nicht ausgelesen werden können. Das kann nicht einmal der original CUBE. Deswegen muss man ja auch bei einem Cube-Reset alles neu einrichten und das wo man da nichtmal ein Backup machen kann.

Wenn in FHEM falsche oder keine Wochenprofile angezeigt werden, heißt das nicht, dass auch in den Thermostaten (Wand- oder HK) falsche Programme liegen. Was du einmal auf die Thermostate geschickt hast bleibt da auch bis du ein Werksreset machst oder etwas neues hinschickst. Bei den Wandthermostaten läßt sich für den aktuellen Tag das Programm an der unteren Punktlinie ja so grob ablesen. Das Menü ist nunmal leider nach dem Pairing nicht mehr zugänglich.

[kadettilac89]

wenn es nur dazu dient die anzeige beim reboot gerade zu ziehen kannst du ja ein notify auf reboot setzen und dann mit "set <weekprofile> send_to_device <device> senden. das machts du aktuell manuell.


Beispiel des reboot-notify. das beispiel sendet ein mail, musst halt die entsprechenden set-befehle eintragen.

Code Auswählen Erweitern


defmod ntf_global_INITIALIZED notify global:INITIALIZED {DebianMail('xxxxx','FHEM Restarted',':','')}


[LHBL2003]

Hallo Risiko und co.,

Es geht um das Thema, das Homatic Thermostate und Wandthermostate nicht korrekt geladen werden.
Probleme sind solche Dinge wie: MUARTLGW HomeMaticLGW: queue is full, dropping packet
Bereits erwähnt in Antwort #444 am: 25 Oktober 2018, 19:29:29

Ich habe daraufhin mal das Problem versucht zu analysieren, da du ja MAX Systeme hast.
Ich muss sagen, dass es bei mir seit November sehr zuverlässig und Fehlerfrei funktioniert. Dadurch ist aber mindestens ein Punkt entstanden, der bei jeden Update übergebügelt werden würde. Deshalb würde ich mich freuen, wenn du dir diesen Beitrag durchlesen würdest. Vielen Dank vorab.

Problem Vermeidung Nr.1 queue is full, dropping packet:

Ich habe das ganze Problem aushebeln können, indem ich meine 17 Devices zeitversetzt lade.
In meinem Fall habe ich dafür gesorgt, das die Profile mit je einem Versetzt von einer Minute abgesendet werden.
Dadurch kommt es zu keinen "queue is full".

Hierzu musste ich deinen Quellcode (FHEM/98_weekprofile.pm) etwas von dir angepasst werden (Datei auch im Angang):

Zeile 25 bis 31 (Deklaration):

Code Auswählen Erweitern


#HEMPEL
use DateTime; # Verweis auf DateTime Lib

#HEMPEL
#Zeitverzögerung wann das letzte Profil geplant gesendet wird
#Initialzeit liegt in der Vergangenheit
my $DATETIME_WHEN_THE_LAST_PROFILE_IS_SEND = DateTime->new( year => 1999, month => 1, day => 1 );


Zeile 414 bis 450 (Verhalten beim HM Devices --> Befehle werden im 60 Sekunden Zyklus ausgelöst und im Logfile Dokumentiert):

Code Auswählen Erweitern


      #HEMPEL
      my $datetimenow = DateTime->now(); #Aktuelle Zeit als UTC Zeit
      $datetimenow->set_time_zone( 'local' ); #Aktuelle Zeit in lokaler Zeitzone
     
      #Jedes Profil wird Verzögert an das Device gesendet um die Meldung "queue is full, dropping packet" zu unterbinden.
      if ($type eq "CUL_HM") {
         
          Log3 $me, 1, "$me --> Zeitpunkt wann aktuell das letzte Profil Übertragen wird. ($DATETIME_WHEN_THE_LAST_PROFILE_IS_SEND)";
     
          #Wenn aktuell keine Profile Zeitverzögert übertragen werden, dann sende das gemeldete Profil sofort.
          #Ansonsten
          #Wenn in der letzten Sekunde bereits ein Profil übertragen wurde, dann sende das nächste um x Sekunden Zeitverzögert.
          #Werden noch weitere Profile zum senden gemeldet, so werden diese ebenso Zeitverzögert nach dem letzten Profil eingereiht.
          if ($DATETIME_WHEN_THE_LAST_PROFILE_IS_SEND->epoch < $datetimenow->epoch-1)
          {
              #Aktuelle Uhrzeit als Auslösezeit für das senden Merken
              $DATETIME_WHEN_THE_LAST_PROFILE_IS_SEND = $datetimenow;
              Log3 $me, 1, "$me Profil wird jetzt an $device übergeben. ($DATETIME_WHEN_THE_LAST_PROFILE_IS_SEND)";
          }
          else
          {
              #Zeitpunkt der letzten geplanten Übertragung + 60 Sekunden. (TODO: Dieser Wert sollte dynamisch angebbar sein. Dann kann jeder sein Optimum ermitteln.)
              $DATETIME_WHEN_THE_LAST_PROFILE_IS_SEND = $DATETIME_WHEN_THE_LAST_PROFILE_IS_SEND->add(seconds => 60);
              Log3 $me, 1, "$me Profil wird 60 Sekunden nach der letzten geplanten Übertragung an $device gesendet. ($DATETIME_WHEN_THE_LAST_PROFILE_IS_SEND)";
          }
     
          #Zeit zwischen jetzt und geplanten Senden in Sekunden.
          my $SleepTime = $datetimenow->subtract_datetime_absolute($DATETIME_WHEN_THE_LAST_PROFILE_IS_SEND)->seconds;
          Log3 $me, 1, "$me Geplante SleepTime in Sekunden. ($SleepTime)";
     
          #Übertrage das Profil Zeitverzögert. (Fhem Sleep damit das System nicht einfriert.)
          $ret = fhem("sleep $SleepTime; $cmd",1);
      }
      else{
          #ORIGINAL
          $ret = fhem($cmd,1);
      }


Man könnte sich noch überlegen ob man die Zeitangabe (in meinem Beispiel 60 Sek.) konfigurierbar gestaltet, damit jeder seinen eigenen Wert ermitteln könnte.
Aber mit 60 Sekunden fährt man sehr gut.

Beim Auslösen des T (Restore topic) Buttons werden dann folgende Logfile Einträge erzeugt:
Dort kann man sehen welches Thermostat wann seine Daten bekommt:

Code Auswählen Erweitern


2018.12.27 15:32:00.550 1: weekprofile --> Zeitpunkt wann aktuell das letzte Profil Übertragen wird. (1999-01-01T00:00:00)
2018.12.27 15:32:00.551 1: weekprofile Profil wird jetzt an OG_Gaestezimmer_THERMOSTAT_Clima übergeben. (2018-12-27T15:32:00)
2018.12.27 15:32:00.552 1: weekprofile Geplante SleepTime in Sekunden. (0)
2018.12.27 15:32:00.641 1: weekprofile --> Zeitpunkt wann aktuell das letzte Profil Übertragen wird. (2018-12-27T15:32:00)
2018.12.27 15:32:00.644 1: weekprofile Profil wird 60 Sekunden nach der letzten geplanten Übertragung an EG_Flur_THERMOSTAT_Clima gesendet. (2018-12-27T15:33:00)
2018.12.27 15:32:00.644 1: weekprofile Geplante SleepTime in Sekunden. (60)
2018.12.27 15:32:00.733 1: weekprofile --> Zeitpunkt wann aktuell das letzte Profil Übertragen wird. (2018-12-27T15:33:00)
2018.12.27 15:32:00.737 1: weekprofile Profil wird 60 Sekunden nach der letzten geplanten Übertragung an EG_Bad_THERMOSTAT_Clima gesendet. (2018-12-27T15:34:00)
2018.12.27 15:32:00.737 1: weekprofile Geplante SleepTime in Sekunden. (120)
2018.12.27 15:32:00.811 1: weekprofile --> Zeitpunkt wann aktuell das letzte Profil Übertragen wird. (2018-12-27T15:34:00)
2018.12.27 15:32:00.813 1: weekprofile Profil wird 60 Sekunden nach der letzten geplanten Übertragung an OG_Kinderzimmer_WANDTHERMOSTAT_Climate gesendet. (2018-12-27T15:35:00)
2018.12.27 15:32:00.814 1: weekprofile Geplante SleepTime in Sekunden. (180)
2018.12.27 15:32:00.883 1: weekprofile --> Zeitpunkt wann aktuell das letzte Profil Übertragen wird. (2018-12-27T15:35:00)
2018.12.27 15:32:00.885 1: weekprofile Profil wird 60 Sekunden nach der letzten geplanten Übertragung an EG_WohnEsszimmer_WANDTHERMOSTAT_Climate gesendet. (2018-12-27T15:36:00)
2018.12.27 15:32:00.886 1: weekprofile Geplante SleepTime in Sekunden. (240)
2018.12.27 15:32:00.954 1: weekprofile --> Zeitpunkt wann aktuell das letzte Profil Übertragen wird. (2018-12-27T15:36:00)
2018.12.27 15:32:00.957 1: weekprofile Profil wird 60 Sekunden nach der letzten geplanten Übertragung an OG_Bad_HK2_WANDTHERMOSTAT_Climate gesendet. (2018-12-27T15:37:00)
2018.12.27 15:32:00.957 1: weekprofile Geplante SleepTime in Sekunden. (300)
2018.12.27 15:32:01.026 1: weekprofile --> Zeitpunkt wann aktuell das letzte Profil Übertragen wird. (2018-12-27T15:37:00)
2018.12.27 15:32:01.028 1: weekprofile Profil wird 60 Sekunden nach der letzten geplanten Übertragung an OG_Bad_HK2_THERMOSTAT_Clima gesendet. (2018-12-27T15:38:00)
2018.12.27 15:32:01.029 1: weekprofile Geplante SleepTime in Sekunden. (360)
2018.12.27 15:32:01.097 1: weekprofile --> Zeitpunkt wann aktuell das letzte Profil Übertragen wird. (2018-12-27T15:38:00)
2018.12.27 15:32:01.099 1: weekprofile Profil wird 60 Sekunden nach der letzten geplanten Übertragung an EG_Buero_THERMOSTAT_Clima gesendet. (2018-12-27T15:39:00)
2018.12.27 15:32:01.100 1: weekprofile Geplante SleepTime in Sekunden. (419)
2018.12.27 15:32:01.169 1: weekprofile --> Zeitpunkt wann aktuell das letzte Profil Übertragen wird. (2018-12-27T15:39:00)
2018.12.27 15:32:01.171 1: weekprofile Profil wird 60 Sekunden nach der letzten geplanten Übertragung an EG_Wohnzimmer_THERMOSTAT_Clima gesendet. (2018-12-27T15:40:00)
2018.12.27 15:32:01.171 1: weekprofile Geplante SleepTime in Sekunden. (479)
2018.12.27 15:32:01.254 1: weekprofile --> Zeitpunkt wann aktuell das letzte Profil Übertragen wird. (2018-12-27T15:40:00)
2018.12.27 15:32:01.256 1: weekprofile Profil wird 60 Sekunden nach der letzten geplanten Übertragung an OG_Schlafzimmer_THERMOSTAT_Clima gesendet. (2018-12-27T15:41:00)
2018.12.27 15:32:01.257 1: weekprofile Geplante SleepTime in Sekunden. (539)
2018.12.27 15:32:01.334 1: weekprofile --> Zeitpunkt wann aktuell das letzte Profil Übertragen wird. (2018-12-27T15:41:00)
2018.12.27 15:32:01.336 1: weekprofile Profil wird 60 Sekunden nach der letzten geplanten Übertragung an OG_Schlafzimmer_WANDTHERMOSTAT_Climate gesendet. (2018-12-27T15:42:00)
2018.12.27 15:32:01.337 1: weekprofile Geplante SleepTime in Sekunden. (599)
2018.12.27 15:32:01.412 1: weekprofile --> Zeitpunkt wann aktuell das letzte Profil Übertragen wird. (2018-12-27T15:42:00)
2018.12.27 15:32:01.414 1: weekprofile Profil wird 60 Sekunden nach der letzten geplanten Übertragung an EG_Flur_WANDTHERMOSTAT_Climate gesendet. (2018-12-27T15:43:00)
2018.12.27 15:32:01.415 1: weekprofile Geplante SleepTime in Sekunden. (659)
2018.12.27 15:32:01.489 1: weekprofile --> Zeitpunkt wann aktuell das letzte Profil Übertragen wird. (2018-12-27T15:43:00)
2018.12.27 15:32:01.491 1: weekprofile Profil wird 60 Sekunden nach der letzten geplanten Übertragung an KG_Bad_THERMOSTAT_Clima gesendet. (2018-12-27T15:44:00)
2018.12.27 15:32:01.492 1: weekprofile Geplante SleepTime in Sekunden. (719)
2018.12.27 15:32:01.566 1: weekprofile --> Zeitpunkt wann aktuell das letzte Profil Übertragen wird. (2018-12-27T15:44:00)
2018.12.27 15:32:01.568 1: weekprofile Profil wird 60 Sekunden nach der letzten geplanten Übertragung an EG_Buero_WANDTHERMOSTAT_Climate gesendet. (2018-12-27T15:45:00)
2018.12.27 15:32:01.569 1: weekprofile Geplante SleepTime in Sekunden. (779)
2018.12.27 15:32:01.643 1: weekprofile --> Zeitpunkt wann aktuell das letzte Profil Übertragen wird. (2018-12-27T15:45:00)
2018.12.27 15:32:01.645 1: weekprofile Profil wird 60 Sekunden nach der letzten geplanten Übertragung an OG_Bad_HK1_WANDTHERMOSTAT_Climate gesendet. (2018-12-27T15:46:00)
2018.12.27 15:32:01.645 1: weekprofile Geplante SleepTime in Sekunden. (839)
2018.12.27 15:32:01.720 1: weekprofile --> Zeitpunkt wann aktuell das letzte Profil Übertragen wird. (2018-12-27T15:46:00)
2018.12.27 15:32:01.722 1: weekprofile Profil wird 60 Sekunden nach der letzten geplanten Übertragung an OG_Bad_HK1_THERMOSTAT_Clima gesendet. (2018-12-27T15:47:00)
2018.12.27 15:32:01.723 1: weekprofile Geplante SleepTime in Sekunden. (899)
2018.12.27 15:32:01.804 1: weekprofile --> Zeitpunkt wann aktuell das letzte Profil Übertragen wird. (2018-12-27T15:47:00)
2018.12.27 15:32:01.807 1: weekprofile Profil wird 60 Sekunden nach der letzten geplanten Übertragung an EG_Esszimmer_THERMOSTAT_Clima gesendet. (2018-12-27T15:48:00)
2018.12.27 15:32:01.808 1: weekprofile Geplante SleepTime in Sekunden. (959)
2018.12.27 15:32:01.890 1: weekprofile --> Zeitpunkt wann aktuell das letzte Profil Übertragen wird. (2018-12-27T15:48:00)
2018.12.27 15:32:01.892 1: weekprofile Profil wird 60 Sekunden nach der letzten geplanten Übertragung an EG_Bad_WANDTHERMOSTAT_Climate gesendet. (2018-12-27T15:49:00)
2018.12.27 15:32:01.893 1: weekprofile Geplante SleepTime in Sekunden. (1019)
2018.12.27 15:32:01.973 1: weekprofile --> Zeitpunkt wann aktuell das letzte Profil Übertragen wird. (2018-12-27T15:49:00)
2018.12.27 15:32:01.975 1: weekprofile Profil wird 60 Sekunden nach der letzten geplanten Übertragung an OG_Kinderzimmer_THERMOSTAT_Clima gesendet. (2018-12-27T15:50:00)
2018.12.27 15:32:01.976 1: weekprofile Geplante SleepTime in Sekunden. (1079)

2018.12.27 15:32:01.991 3: CUL_HM set OG_Gaestezimmer_THERMOSTAT_Clima tempListMon prep 04:30 20.0 07:00 20.0 12:45 20.0 19:00 23.5 24:00 20.0
2018.12.27 15:32:01.993 3: CUL_HM set OG_Gaestezimmer_THERMOSTAT_Clima tempListTue prep 04:30 20.0 07:00 20.0 12:45 20.0 19:00 23.5 24:00 20.0
2018.12.27 15:32:01.995 3: CUL_HM set OG_Gaestezimmer_THERMOSTAT_Clima tempListWed prep 04:30 20.0 07:00 20.0 12:45 20.0 19:00 23.5 24:00 20.0
2018.12.27 15:32:01.997 3: CUL_HM set OG_Gaestezimmer_THERMOSTAT_Clima tempListThu prep 04:30 20.0 07:00 20.0 12:45 20.0 19:00 23.5 24:00 20.0
2018.12.27 15:32:01.999 3: CUL_HM set OG_Gaestezimmer_THERMOSTAT_Clima tempListFri prep 04:30 20.0 07:00 20.0 12:45 20.0 19:00 23.5 24:00 20.0
2018.12.27 15:32:02.000 3: CUL_HM set OG_Gaestezimmer_THERMOSTAT_Clima tempListSat prep 09:00 20.0 20:00 23.5 24:00 20.0

2018.12.27 15:32:02.485 3: CUL_HM set OG_Gaestezimmer_THERMOSTAT_Clima tempListSun exec 09:00 20.0 20:00 23.5 24:00 20.0
2018.12.27 15:32:09.405 3: CUL_HM set EG_Kueche_Schaltsteckdose_Dunstabzugshaube off
2018.12.27 15:33:00.650 3: CUL_HM set EG_Flur_THERMOSTAT_Clima tempListMon prep 04:30 20.0 07:00 22.0 12:45 20.0 22:00 22.0 24:00 20.0
2018.12.27 15:33:00.653 3: CUL_HM set EG_Flur_THERMOSTAT_Clima tempListTue prep 04:30 20.0 07:00 22.0 12:45 20.0 22:00 22.0 24:00 20.0
2018.12.27 15:33:00.657 3: CUL_HM set EG_Flur_THERMOSTAT_Clima tempListWed prep 04:30 20.0 07:00 22.0 12:45 20.0 22:00 22.0 24:00 20.0
2018.12.27 15:33:00.661 3: CUL_HM set EG_Flur_THERMOSTAT_Clima tempListThu prep 04:30 20.0 07:00 22.0 12:45 20.0 22:00 22.0 24:00 20.0
2018.12.27 15:33:00.665 3: CUL_HM set EG_Flur_THERMOSTAT_Clima tempListFri prep 04:30 20.0 07:00 22.0 12:45 20.0 22:00 22.0 24:00 20.0

2018.12.27 15:33:01.191 3: CUL_HM set EG_Flur_THERMOSTAT_Clima tempListSun exec 07:00 20.0 22:00 22.0 24:00 20.0
2018.12.27 15:33:05.915 3: CUL_HM set OG_Gaestezimmer_THERMOSTAT_Clima getConfig
2018.12.27 15:33:32.005 3: CUL_HM set EG_Flur_THERMOSTAT_Clima getConfig
2018.12.27 15:34:00.747 3: CUL_HM set EG_Bad_THERMOSTAT_Clima tempListMon prep 04:30 20.0 07:00 23.5 12:45 20.0 22:00 23.5 24:00 20.0
2018.12.27 15:34:00.759 3: CUL_HM set EG_Bad_THERMOSTAT_Clima tempListTue prep 04:30 20.0 07:00 23.5 12:45 20.0 22:00 23.5 24:00 20.0
2018.12.27 15:34:00.763 3: CUL_HM set EG_Bad_THERMOSTAT_Clima tempListWed prep 04:30 20.0 07:00 23.5 12:45 20.0 22:00 23.5 24:00 20.0
2018.12.27 15:34:00.767 3: CUL_HM set EG_Bad_THERMOSTAT_Clima tempListThu prep 04:30 20.0 07:00 23.5 12:45 20.0 22:00 23.5 24:00 20.0
2018.12.27 15:34:00.771 3: CUL_HM set EG_Bad_THERMOSTAT_Clima tempListFri prep 04:30 20.0 07:00 23.5 12:45 20.0 22:00 23.5 24:00 20.0

2018.12.27 15:34:01.298 3: CUL_HM set EG_Bad_THERMOSTAT_Clima tempListSat exec 07:00 20.0 22:30 23.5 24:00 20.0
2018.12.27 15:35:00.819 3: CUL_HM set OG_Kinderzimmer_WANDTHERMOSTAT_Climate tempListMon prep 04:30 20.0 07:00 23.5 12:45 20.0 22:00 23.5 24:00 20.0
2018.12.27 15:35:00.823 3: CUL_HM set OG_Kinderzimmer_WANDTHERMOSTAT_Climate tempListTue prep 04:30 20.0 07:00 23.5 12:45 20.0 22:00 23.5 24:00 20.0
2018.12.27 15:35:00.827 3: CUL_HM set OG_Kinderzimmer_WANDTHERMOSTAT_Climate tempListWed prep 04:30 20.0 07:00 23.5 12:45 20.0 22:00 23.5 24:00 20.0
2018.12.27 15:35:00.831 3: CUL_HM set OG_Kinderzimmer_WANDTHERMOSTAT_Climate tempListThu prep 04:30 20.0 07:00 23.5 12:45 20.0 22:00 23.5 24:00 20.0
2018.12.27 15:35:00.835 3: CUL_HM set OG_Kinderzimmer_WANDTHERMOSTAT_Climate tempListFri prep 04:30 20.0 07:00 23.5 12:45 20.0 22:00 23.5 24:00 20.0
2018.12.27 15:35:00.838 3: CUL_HM set OG_Kinderzimmer_WANDTHERMOSTAT_Climate tempListSat prep 04:30 20.0 22:00 23.5 24:00 20.0
2018.12.27 15:35:00.880 3: CUL_HM set OG_Kinderzimmer_WANDTHERMOSTAT_Climate tempListSun exec 04:30 20.0 22:00 23.5 24:00 20.0
2018.12.27 15:35:04.898 3: CUL_HM set OG_Kinderzimmer_WANDTHERMOSTAT_Climate getConfig
2018.12.27 15:35:32.037 3: CUL_HM set OG_Gaestezimmer_THERMOSTAT_Clima getConfig
2018.12.27 15:36:00.891 3: CUL_HM set EG_WohnEsszimmer_WANDTHERMOSTAT_Climate tempListMon prep 04:30 20.0 07:00 23.5 12:45 21.0 22:00 23.5 24:00 20.0
2018.12.27 15:36:00.895 3: CUL_HM set EG_WohnEsszimmer_WANDTHERMOSTAT_Climate tempListTue prep 04:30 20.0 07:00 23.5 12:45 21.0 22:00 23.5 24:00 20.0
2018.12.27 15:36:00.899 3: CUL_HM set EG_WohnEsszimmer_WANDTHERMOSTAT_Climate tempListWed prep 04:30 20.0 07:00 23.5 12:45 21.0 22:00 23.5 24:00 20.0
.........usw. für den Rest
 

Problem Vermeidung Nr.2 R_tempList_State meldet incomplete und bleibt ewig bestehen:

Überblick:
Jedes Thermostat hat ein "...Clima" Device Element, dieses beinhaltet die Readings R_0_tempListSat bis R_6_tempListFri.
Die ...tempList... Reading Informationen werden angepasst, sobald das Thermostat seine aktuellen Informationen zurücksendet.

Aktuelles Verhalten:
Beim auslösend der Befehle zum übertragen der Temperaturinformationen wird der Reading Status "R_tempList_State" auf incomplete gesetzt.
Sobald die Daten tatsächlich an das Thermostat gesendet werden (HMLANGW Logik arbeitet die übergebenen Befehle ab),
sendet dieses Modul auch den Befehl GetConfig, damit die aktuellen Temperatureinstellungen zurückgemeldet werden.
Die zurückgemeldeten Einstellungen werden dann normalerweise in die Readings R_0_tempListSat bis R_6_tempListFri eingetragen.

Das Problem ist aber, das die Schnittstelle gut beschäftigt und ab und an keine Rückmeldung durch GetConfig erfolgt.
Das sorgt dafür, das weiterhin in FEHM veraltete Daten in den Readings R_0_tempListSat bis R_6_tempListFri stehen, obwohl das Thermostat Tagelang bereits die neuen Temperaturdaten benutzt. Demzufolge hat man dann beim Wechsel zwischen zwei Wochenprofielen riesige Probleme, denn die weekprofile Logik schaut ob sich die Daten zwischen dem zu seidenen Profil und den Readings R_0_tempListSat bis R_6_tempListFri unterscheidet (beachtet aber nicht das "incomplete", was ich aktuell auch noch nicht abgefangen habe.)
Der Status R_tempList_State bleibt also bis zum nächsten auslösen und erfolgreich abgearbeiteten GetConfig auf incomplet. (Wenn es keiner auslöst also ewig.)

Lösungsansatz:
Daher habe ich bei mir ein Notify angelegt (n_Check_HM_tempList_State) evtl. kann man die Logik auch im WeekProfil Modul verheiraten:

Das Notify prüft ob irgend ein ...Clima Device Element bei irgend einen der ...tempList_State den Status incomplet besitzt.
Sobald dies der Fall ist wird temorär ein "at" Modul im Raum "Temp" angelegt, welches nach 3 Minuten und 30 Sekunden erneut ein "GetConfig" für das Thermostat auslöst.
3 Minuten und 30 Sekunden daher, weil ja die HM Thermostate im Normalfall alle 3 Minuten aufgaben abarbeiten und in den ersten 3 Minuten ja erst einmal die Daten gesendet werden und mit etwas Glück auf das normale GetConfig funktioniert.
Dies wird solange durchgeführt, bis der Staus ..tempList_State nicht mehr incomplet ist.
Sobald das überprüfte incomplet verschwunden ist, wird auch das "AT" Modul entfernt, damit keine GetConfig Anforderungen mehr ausgelöst werden.

Mann könnte das zwar auf über viele Watchdogs erledigen. Aber dann benötige massig viele Watchdogs, denn ein Wandthermostat könnte ja 3 Profile besitzen.

Code Auswählen Erweitern


.*THERMOSTAT_Clima:.*_tempList_State:.* {
     # Log Präfix, der vorweg angegeben wird
     my $LogPrefix = "n_Check_HM_tempList_State:";
     my $ReadingName = (split(":",$EVTPART0))[0];

     #$NAME = Name vom Device welches überwacht werden soll (NOTIFYDEV)
     #$EVENT = Wert des Readings der gelesen wird
     #Log3 ($LogPrefix, 1, "$LogPrefix: name=$NAME event=$EVENT");

     if($EVENT eq "R_tempList_State: incomplete")
     {
        Log3 ($LogPrefix, 1, "Das Device $NAME meldet $EVENT. GetConfig wird in 3 Minute und 30 Sekunden ausgelöst um erneut die Daten abzufragen." );
             
        if(Value("$NAME"."$ReadingName"."_NewSetGetConfig") ne "")
        {
            Log3 ($LogPrefix, 1, "$NAME"."$ReadingName"."_NewSetGetConfig wurde schon angelegt, also erst mal löschen.");
            fhem ("delete $NAME"."$ReadingName"."_NewSetGetConfig");
        }
       
        fhem ("define $NAME"."_NewSetGetConfig at +00:03:30 set $NAME getConfig");
     }
     else
     {
        if(Value("$NAME"."$ReadingName"."_NewSetGetConfig") ne "")
        {
            Log3 ($LogPrefix, 1, "Das Device $NAME meldet $EVENT. GetConfig Timer wird gelöscht.");
            fhem ("delete $NAME"."$ReadingName"."_NewSetGetConfig");
        }
     }
}


Sobald ein "incomplete" auftaucht, wird ein Logeintrag mit der Überwachungsinformation im FHEM Log angelegt.

Code Auswählen Erweitern


2018.12.27 15:32:02.024 1: Das Device OG_Gaestezimmer_THERMOSTAT_Clima meldet R_tempList_State: incomplete. GetConfig wird in 3 Minute und 30 Sekunden ausgelöst um erneut die Daten abzufragen.


Frohe Weihnachten und einen Guten Rutsch ins neue Jahr.

[Risiko]

Hallo LHBL2003,

danke für die ausführliche Erklärung. Ich habe es nur überflogen.
Schaue es mit im neuen Jahr näher an.

Guten Rutsch.

Risiko

[Risiko]

Hallo LHBL2003,

ich habe das verzögerte Senden pro Device eingebaut. Habe aber nur die Idee und nicht die eigentliche Implementierung übernommen.
Die Zeit kann man über das Attribut 'send_delay' [Sekunden] einstellen.
Könntest du die Version bitte testen.

Danke.

Risiko.

[LHBL2003]

Hallo Risiko,

danke schon mal für die Bearbeitung. Ich habe die Datei vor etwa 10 Minuten eingespielt und habe das Attribut send_delay auch auf 16 Sek. gestellt.
Aktuell kann ich dir sagen, dass mein FHEM am strick hängt. Denn die Webseite wird nicht geladen.
Gerade habe ich gesehen, dass mein FHEM Log vollläuft. Ich habe dir die Logs im Anhang beigefügt.

- fhem-2019-01-04_Test1.log ist der erste Test gewesen, allerdings mit verbose Level 3

- fhem-2019-01-04_Test2 Mit LOG Level 4.log ist der zweite Test gewesen. Diesen habe ich nach einem Neustart vom Raspberry PI durchgeführt. Aber dann mit dem globalen Attribut "attr global verbose 4".

Gruß Denis

[Risiko]

Hallo Denis,

schon mal vielen Dank.
Ich kann leider nichts Verdächtiges finden.
Aber nochmal zum Verständnis.
Nicht jedes Thermostat z.B. OG_Bad_HK2_THERMOSTAT_Clima hat eine eigene Queue sondern das "Masterdevice" z.B. HMUARTLGW?
Somit macht das Timeout pro Device (Thermostat) keinen Sinn. Also müsste es aus Sicht von weekprofile pro Typ wirken.
Ich habe eine neue Version erstellt.

Risiko

[Risiko]

Hallo.

Eine weitere Version. Nun wirkt das verzögerte Senden auch (wieder) über mehrere weekprofile Instanzen hinweg.
Soll heißen, wenn über weekprofile Profile gesendet werden wird global das verzögerte Senden an einen gleichen Thermostattyp berücksichtigt, sofern send_delay > 0 ist.

Viel Spaß beim Testen.

Nachtrag:
Habe die Version gerade eingecheckt. Das Attribut heißt jetzt sendDelay. Default: 0

[Risiko]

Hallo Denis,

für dein 2. Problem gibt es jetzt das Attribut 'forceCompleteProfile'. Damit wird erzwungen, dass immer das komplette Wochenprofil an das Thermostat gesendet wird und nicht nur Änderungen. Somit ist es auch möglich ein Profil nochmal zu senden.
Vielleicht hilft es dir ja.

Risiko.

[LHBL2003]

Hallo Risiko,

die letzten beiden Beiträge habe ich soeben erst gelesen und noch nicht berücksichtigt.
Aber ich war die Tage dabei die Antwort #456 zu testen.

Zu deiner Frage:

Nicht jedes Thermostat z.B. OG_Bad_HK2_THERMOSTAT_Clima hat eine eigene Queue sondern das "Masterdevice" z.B. HMUARTLGW?

Ja das würde ich auch so sehen. Zumindest kommt das

Code Auswählen Erweitern

Log3($hash, 1, "HMUARTLGW ${name}: queue is full, dropping packet"); aus der 00_HMUARTLGW.pm

Folgendes Ergebnis zum Test:
Das Verzögerte Senden funktioniert zuverlässig. So das mit einer Verzögerung von 60 Sekunden keine "queue is full" Meldungen kommen.
Die Daten werden an das Thermostat bzw. Wandthermostat übermittelt.

Wichtig ist aber!:
Sofern im Reading R_tempList_State (Thermostat) bzw. R_P1_tempList_State (Wandthermostat) nicht "verified" steht,
kann sich das WeekProfil niemals darauf Verlassen, das die aktuellen Daten in R_P1_0_tempListSat bis R_P1_6_tempListFri stimmen.
Soviel ich es in Erinnerung habe, prüfst du ob die Daten in R_P1_0_tempListSat bis. R_P1_6_tempListFri mit den zu sendenden Daten übereinstimmen.
Wenn dies nicht übereinstimmen, dann sendest du diese. Wenn diese übereinstimmen, dann sendest du diese nicht. (Bei z.B. "incomplet" oder "set", muss man dennoch senden. Denn niemand weiß welchen Stand das Device hat.)
Wäre also gut wenn du dies bitte noch berücksichtigen könntest, wenn dies nicht durch das neue Update schon mit kommen wird.
Nachtrag:(Das Forcen wird mit etwas mehr Trafic auf das selbe Ergebnis hinzielen)


Jetzt muss ich nur noch schauen wie man dieses Thema R_tempList_State bzw. R_P1_tempList_State = "incomplet" 100% in den griff bekommt, bzw. zum Standard bringt.
Denn das ewige senden von GetConfig bis mal aus "incomplet" --> "verified" wird ist noch unschön.

So dann mache ich mal ein FHEM update und schaue mir mal die Neuerungen an.

Gruß Denis

[Risiko]

Hallo Denis,

R_tempList_State bzw. R_P1_tempList_State wird nicht berücksichtigt.
Wenn ich es richtig verstehe, dann soll bei einem R_tempList_State != verified immer ein Senden mit force=1 (komplettes Profil) erfolgen?

Was mache ich aber beim Lesen, wenn R_tempList_State != verified ist? So wie jetzt ignorieren?

Risiko.

[LHBL2003]

Hallo Risiko,

R_tempList_State bzw. R_P1_tempList_State wird nicht berücksichtigt.
Wenn ich es richtig verstehe, dann soll bei einem R_tempList_State != verified immer ein Senden mit force=1 (komplettes Profil) erfolgen?

Richtig, folgendes Beispiel:

- Ich sende ein Profil "A" mit jeden R_0_tempListXYZ Tag 20°C (Order jeden Tag andere Daten, wie auch immer)
- Die Daten werden erfolgreich übertragen und auch GetConfig hat geklappt. (R_0_tempListXYZ beinhaltet die Richtigen Daten)

- Ich sende ein Profil "B" mit jeden R_0_tempListXYZ Tag 5°C (Order jeden Tag andere Daten, wie auch immer)
- Die Daten werden erfolgreich übertragen das Device stellt auf 5° ABER GetConfig hat nicht geklappt, mit etwas Pech steht sogar der Status vom Device auf "CMDs_done" aber R_tempList_State bzw. R_P1_tempList_State auf incomplet.

- Jetzt bekomme ich dies nicht mit.
- Ich sende das Profil "A" mit jeden R_0_tempListXYZ Tag 20°C
- Jetzt sagt sich das WeekProfil. Joar, R_0_tempListXYZ stimmen überein. Brauche ich also nicht abarbeiten. (Verdammt R_tempList_State bzw. R_P1_tempList_State ist nicht verified. Die Daten in Fhem stimmen evtl. garnicht mit dem Device überein.)

Was mache ich aber beim Lesen, wenn R_tempList_State != verified ist? So wie jetzt ignorieren?

Also ich habe eine Seite, wo ich von allen Thermostaten die aktuellen Einstellungen Darstelle. (Siehe Anhang: Normalerweise müsste beim Test alle Thermostate bis auf Keller, die selben Einstellungen haben. Da es nicht der Fall ist, weiß ich, dass irgendwelche Einstellungen noch nicht zurückgemeldet wurden.)
Am allerbesten wäre, ein Hinweis, evtl. sogar eine Einfärbung so das man erkennen kann, dass die Daten nicht (bzw. noch nicht) Valide sind.

PS: Früher vor etwa 1 oder 2 Jahren war es übrigens so, dass die Wochentage R_0_tempListXYZ den Status incomplet hatte, solange die Daten nicht aktuell waren. Das ist aber nicht mehr so. Jetzt hat R_tempList_State den Status und R_0_tempListXYZ behält die Daten, bis diese aktualisiert werden. Damit war es früher so, das in deinen Profilen immer incomplet angezeigt wurde (Was eigentlich ein praktischer Nebeneffekt war).


Gruß Denis

[grappa24]

Nach einem Umzug meines FHEM auf einen anderen RasPi sind meine Profile weg. Ich vermute, die Config-Dateien sind separat abgelegt (wo?) und ich hab sie vergessen, umzuziehen?

[LHBL2003]

Meistens liegen die configurationen im Logfile Ordner.

[kadettilac89]

Nach einem Umzug meines FHEM auf einen anderen RasPi sind meine Profile weg. Ich vermute, die Config-Dateien sind separat abgelegt (wo?) und ich hab sie vergessen, umzuziehen?

im Logverzeichnis liegen Dateien weekprofile-*** diese musst du mir umziehen