[gelöst] fhem stürzt unregelmäßig ab

Begonnen von CottonIJo, 26 Oktober 2022, 11:32:54

Vorheriges Thema - Nächstes Thema

CottonIJo

Hallo,
ich habe seit ca. 2 Wochen unregelmäßig Abstürze von fhem, finde leider keine Lösung.

Auszug aus dem log bevor fhem aussteigt:

.....
2022.10.25 21:47:28 1: cmd2 - Esszimmer_Stehlampe_Sw on weil Motion detected
2022.10.25 21:51:30 1: cmd3 - Esszimmer_Stehlampe_Sw off weil Motion-Timer abgelaufen
2022.10.25 21:51:55 1: cmd2 - Esszimmer_Stehlampe_Sw on weil Motion detected
2022.10.25 21:55:56 1: cmd3 - Esszimmer_Stehlampe_Sw off weil Motion-Timer abgelaufen
2022.10.25 22:15:00 3: CUL_HM set 10_EG_Flur_Stehlampe_Sw off noArg
2022.10.25 22:15:00 1: cmd5 - ab 22:15h 10_EG_Flur_Stehlampe_Sw off
2022.10.25 22:15:00 3: CUL_HM set 50_Aussen_Licht_Eingang off noArg
2022.10.25 22:15:00 1: cmd6 - Nachtmodus -> 50_Aussen_Licht_Eingang off
2022.10.25 22:17:22 3: CUL_HM set 10_EG_Flur_Stehlampe_Sw off noArg
2022.10.25 22:17:22 1: cmd7 - 10_EG_Flur_Stehlampe_Sw off nach 22:15h wenn Esszimmer_Stehlampe wieder aus
2022.10.25 22:30:00 3: CUL_HM set 50_Aussen_Schaltmodul01_NordSeite_Sw_02 off noArg
2022.10.25 22:50:11 3: HMinfo hm get:update :
2022.10.25 22:50:11 3: CUL_HM set ActionDetector update noArg
2022.10.25 22:50:11 3: CUL_HM set VCCU update noArg
Quantifier follows nothing in regex; marked by <-- HERE in m/? <-- HERE ??/ at ./FHEM/98_HMinfo.pm line 369.


danach steigt fhem aus, Steuerung der devices (z. Bsp. Licht an bei motion, Rollladensteuerung über DOIF) funktioniert nicht mehr, log wird offensichtlich nicht weiter geschrieben.
Web-Oberfläche von fhem ist nicht mehr erreichbar.
Für den Weiterbetrieb ist ein "sudo systemctl restart fhem" erforderlich, danach ist fhem über den Browser wieder erreichbar.
Fhem ist aktuell.

Wo ist der Fehler für den Ausstieg zu suchen, bzw. welche weiteren Infos sind erforderlich um den Fehler einzukreisen?

Grüße Joachim

Beta-User

Na ja, der Ausstieg kommt ziemlich eindeutig aus HMinfo, das Thema wäre also m.E. besser direkt im Homematic-Bereich aufgehoben (verschieben könntest du selbst).

Allerdings ist mir nicht klar, wie es bei der konkreten aktuellen Zeile in HMinfo zu sowas kommen kann. Daher vorab: Welche Version von HMinfo nutzt du? (Wenn nicht aktuell: unbedingt ein update machen!).
Ansonsten scheint irgendwas bei dir schräg zu hängen, und wir müßten mal versuchen, das näher einzukreisen. Habe aber noch nicht die durschlagende Idee, wie...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

CottonIJo

<version> in der Befehlsszeile liefert:
Latest Revision: 26565

98_HMinfo.pm            25978 2022-04-18 14:50:17Z martinp876
HMinfoTools.js             2009 2022-03-21 12:30:31Z frank
hm.js                      2006 2020-05-29 12:00:00Z frank

list von HMinfo

Internals:
   FUUID      5c587ad0-f33f-8c2a-4342-9e6d857f83dd2356
   NAME       hm
   NOTIFYDEV  global
   NR         45
   NTFY_ORDER 49-hm
   STATE      updated:2022-10-25 10:50:43
   TYPE       HMinfo
   Version    01
   READINGS:
     2022-10-25 10:50:43   CRI__protocol   0
     2022-06-03 05:51:01   C_sumDefined    entities:241,device:66,channel:206,virtual:2
     2022-10-25 10:50:43   ERR__protocol   0
     2022-02-12 15:37:43   ERR__unreachable 0
     2022-09-04 19:51:20   ERR_battery     low:1,
     2022-10-14 23:36:26   ERR_cfgState    updating:8,
     2022-10-25 10:50:43   ERR_motorErr    0
     2022-02-12 15:37:43   ERR_sabotageError on:2,
     2022-10-25 10:50:11   I_actTotal      alive:39,dead:14,unkn:0,off:0
     2022-02-12 15:37:43   I_autoReadPend  0
     2022-10-25 10:50:11   I_rssiMinLevel  59<:21 60>:32 80>:3 99>:0
     2022-09-04 19:51:20   I_sum_battery   low:1,ok:47,
     2022-10-25 10:50:11   I_sum_motor     stop:on:9,
     2022-02-12 15:37:43   I_sum_sabotageError off:10,on:2,
     2022-10-23 16:19:33   W__protocol     Resnd:8
     2022-10-24 22:50:43   lastErrChange   updated:2022-10-24 22:50:43
   helper:
     autoUpdate 43200
     cfgChkResult configCheck done:-ret--ret- missing register list-ret-    20_DG_SZ_Remote_Control1: RegL_00.-ret-    20_DG_SZ_Remote_Control1_Btn_01: RegL_01.-ret-    20_DG_SZ_Remote_Control1_Btn_02: RegL_01.-ret-    20_DG_SZ_Remote_Control1_Btn_03: RegL_01.-ret-    20_DG_SZ_Remote_Control1_Btn_04: RegL_01.-ret-    BewegungsSensor_HM_SEC_MDIR_2: RegL_00.-ret--ret- incomplete register list-ret-    10_EG_Wohnzimmer_Temp_Regler_Climate: RegL_07.-ret-    20_DG_AZ_Dad_Temp_Regler_Climate: .RegL_07.-ret--ret- templist mismatch-ret-    10_EG_Wohnzimmer_Temp_Regler_Climate: -ret-     10_EG_Wohnzimmer_Temp_Regler_Climate: tempList 1 not verified-ret-    20_DG_AZ_Dad_Temp_Regler_Climate: -ret-     20_DG_AZ_Dad_Temp_Regler_Climate: tempList 1 not verified-ret-
     weekplanListDef ./setup/Wochenplan_Heizung_default.cfg
     weekplanListDir ./setup/
     weekplanList:
       10_EG_Esszimmer_HzgThermostat_Clima
       10_EG_Esszimmer_Wand_HzgThermostat_Clima
       10_EG_Flur_HzgThermostat_Clima
       10_EG_Kueche_HzgThermostat_Clima
       10_EG_Toilette_HzgThermostat_Clima
       10_EG_Vorratsraum_HzgThermostat_Clima
       10_EG_Wohnzimmer_Temp_Regler_Climate
       10_EG_Wohnzimmer_HzgThermostat_Erker_Nord_Clima
       10_EG_Wohnzimmer_HzgThermostat_Erker_Sued_Clima
       10_EG_Wohnzimmer_HzgThermostat_Westen_Clima
       20_DG_AZ_Dad_Temp_Regler_Climate
       20_DG_AZ_Dad_HzgThermostat_Westen_Clima
       20_DG_AZ_Dad_HzgThermostat_Erker_Clima
       20_DG_AZ_Mam_HzgThermostat_Clima
       20_DG_Badezimmer_HzgThermostat_Clima
       20_DG_Badezimmer_Handtuch_HzgThermostat_Clima
       20_DG_Balkonzimmer_HzgThermostat_Clima
   nb:
     cnt        1
Attributes:
   alias      hm
   autoArchive 1
   autoLoadArchive 1_load
   autoUpdate 12:00
   comment    # attr autoUpdate 12:00
# default Datei zur Steuerung der Hzg-Ventile ist "Wochenplan_Heizung_default.cfg"
   configDir  setup
   configTempFile Wochenplan_Heizung_default.cfg
   icon       rc_INFO
   room       HM_Info,CUL_HM
   sumERROR   battery:ok,sabotageError:off,powerError:ok,overload:off,overheat:off,reduced:off,motorErr:ok,error:none,uncertain:[no|yes],smoke_detect:none,cover:closed,cfgState:ok
   sumStatus  battery,sabotageError,powerError,motor
   verbose    5
   webCmd     update:protoEvents short:rssi:peerXref:configCheck:models


Könnte das Problem auch im Bereich HMinfoTools liegen?

frank

#3
ZitatQuantifier follows nothing in regex; marked by <-- HERE in m/? <-- HERE ??/ at ./FHEM/98_HMinfo.pm line 369.

Zitatforeach my $read (grep {$ehash->{READINGS}{$_}} keys %errFlt){#---- count error readings
      my $val = $ehash->{READINGS}{$read}{VAL};
      next if (grep (/$val/,(keys%{$errFlt{$read}})));# filter non-Error
      $errFltN{$read."_".$val}{$eName} = 1;
      $err{$read}{$val} = 0 if (!$err{$read}{$val});
      $err{$read}{$val}++;
    }
ich würde behaupten, dass der wert eines "error readings" mit "?" beginnt.
wobei es jedes reading aus dem attr sumError in allen entities betreffen könnte.

@CottonIJo

wenn du das autoUpdate bei hminfo ausstellst, sollte der spuk aufhören.
dann könntest du hin und wieder ein manuelles "set hminfo update" probieren, aber vorher ein "save config" in fhem ausführen, um das statefile vor einem möglichen absturz zu speichern.
nach dem absturz suchst du dann im statefile nach fragezeichen in den readings.

Zitathm.js                      2006 2020-05-29 12:00:00Z frank
ich würde ja mal auf HMdeviceTools.js "updaten"
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

frank

Zitat2022-10-25 10:50:11   I_actTotal      alive:39,dead:14,unkn:0,off:0
vielleicht hilft schon ein blick in die toten devices?
warum so viele?
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

CottonIJo

HMinfo update gemacht

STATE      updated:2022-10-26 15:39:33
2022-10-26 15:39:33   I_actTotal      alive:44,dead:0,unkn:9,off:0

sieht jetzt realistischer aus, wo die 14 "dead" herkamen kann ich nicht sagen
Die 9 unknown können vom fhem unserer ELW kommen, muss ich prüfen

CottonIJo

 @frank, autoupdate bei hminfo abgestellt, seit 2 Tagen keine Fehlermeldung mehr im log und fhem läuft störungsfrei durch, danke.
Nur, was hilft mir ein Attribut wenn ich es nicht dauerhaft im Hintergrund aktivieren kann?
Ich muss gestehen, ich denke wohl nicht dran hin und wieder ein manuelles "set hminfo update" zu probieren.
Ist da ein Bugfix geplant oder wodurch wird ein störungsfreier Betrieb von fhem mit dem hminfo Attribut verhindert?

frank

#7
Zitat von: CottonIJo am 28 Oktober 2022, 22:10:56
@frank, autoupdate bei hminfo abgestellt, seit 2 Tagen keine Fehlermeldung mehr im log und fhem läuft störungsfrei durch, danke.
war ja klar.

ZitatNur, was hilft mir ein Attribut wenn ich es nicht dauerhaft im Hintergrund aktivieren kann?
bei mir läuft hminfo update seit jahren automatisch alle 5min ohne probleme. bei anderen ebenfalls.
ich denke, du bist der erste.

ZitatIch muss gestehen, ich denke wohl nicht dran hin und wieder ein manuelles "set hminfo update" zu probieren.
Ist da ein Bugfix geplant oder wodurch wird ein störungsfreier Betrieb von fhem mit dem hminfo Attribut verhindert?
habe ich doch beschrieben:
Zitatich würde behaupten, dass der wert eines "error readings" mit "?" beginnt.
wobei es jedes reading aus dem attr sumError in allen entities betreffen könnte.
du musst herausfinden, warum bei dir eines dieser readings ein fragezeichen am anfang enthält.
da gehört kein fragezeichen rein. schreibst du es vielleicht selber rein?

wenn du es nicht schaffst den crash manuell auszulösen, um die ursache zu finden, würde ich folgende "Log"-zeile in hminfo einbauen. dann autoupdate wieder einschalten und hoffen, dass beim nächsten crash der übeltäter im log zu sehen ist.
    foreach my $read (grep {$ehash->{READINGS}{$_}} keys %errFlt){#---- count error readings
      my $val = $ehash->{READINGS}{$read}{VAL};
      if($val =~ m/\?/) {#frank: check to avoid crash => https://forum.fhem.de/index.php/topic,129878.0.html
        Log(1, "----- hminfo-crash ----- => $eName, $read, $val");
        $val =~ s/\?/x/g;
      }
      next if (grep (/$val/,(keys%{$errFlt{$read}})));# filter non-Error
      $errFltN{$read."_".$val}{$eName} = 1;
      $err{$read}{$val} = 0 if (!$err{$read}{$val});
      $err{$read}{$val}++;
    }



edit:
ich habe den einzufügenden code noch erweitert.
der zusätzliche if-block schreibt jetzt eine meldung in fhem.log und ersetzt alle fragezeichen durch ein harmloses "x" für einen crashfreien betrieb.

um das problem schneller zu finden, setze autoUpdate zb mal auf 10 min.
du findest das problemdevice dann auch in HMinfoTools, solange das problematische reading beim check die fragezeichen enthält. wenn die fragezeichen immer nur für kurze zeit existieren, wird das problemdevice auch nur manchmal in HMinfoTools zu sehen sein.

also zusätzlich auch mal das fhem.log nach dem string "hminfo-crash" durchsuchen.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

CottonIJo

#8
Hallo frank,
danke für Dein Engagement, bin leider kein Programmierer und habe auf anhieb keine Option gefunden den Code in hminfo einzubauen.
Bitte kurzen Schubser, wo gehört der hin? Copy/paste kann ich ;-)

Zusatz-Info:
habe zwischenzeitlich für jedes Reading welches in sumERROR eingetragen ist
   
battery:ok,sabotageError:off,powerError:ok,overload:off,overheat:off,reduced:off,motorErr:ok,error:none,uncertain:[no|yes],smoke_detect:none,cover:closed,cfgState:ok

eine readingsGroup angelegt, in der Hoffnung, dem Problem damit auf die Spur zu kommen

frank

im anhang meine hminfo datei, die den code aus dem post enthält.
die datei befindet sich in .../fhem/FHEM/
ggf rechte und owner anpassen.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

CottonIJo

#10
@frank, danke für die angepasste HMinfo.pm, habe ich installiert.
Nach einer Stunde findet sich im fhem.log nachfolgender Eintrag

...
2022.10.30 15:32:33 3: HMinfo hm get:update :
2022.10.30 15:32:33 3: CUL_HM set ActionDetector update noArg
2022.10.30 15:32:34 3: CUL_HM set VCCU update noArg
2022.10.30 15:32:57 3: Get_device_Reading: 36
2022.10.30 15:37:57 3: Get_device_Reading: 36
2022.10.30 15:42:34 3: HMinfo hm get:update :
2022.10.30 15:42:34 3: CUL_HM set ActionDetector update noArg
2022.10.30 15:42:34 3: CUL_HM set VCCU update noArg
2022.10.30 15:42:34 1: ----- hminfo-crash ----- => 20_DG_Flur_BewegungsSensor, battery, ???
2022.10.30 15:42:57 3: Get_device_Reading: 36
2022.10.30 15:43:43 1: cmd5 - Motion erkannt, Rollladen geht fuer 242sec runter
2022.10.30 15:47:57 3: Get_device_Reading: 36
2022.10.30 15:52:34 3: HMinfo hm get:update :
2022.10.30 15:52:34 3: CUL_HM set ActionDetector update noArg
2022.10.30 15:52:34 3: CUL_HM set VCCU update noArg
2022.10.30 15:52:34 1: ----- hminfo-crash ----- => 20_DG_Flur_BewegungsSensor, battery, ???
2022.10.30 15:52:57 3: Get_device_Reading: 36
2022.10.30 15:57:57 3: Get_device_Reading: 36
2022.10.30 16:02:34 3: HMinfo hm get:update :
2022.10.30 16:02:34 3: CUL_HM set ActionDetector update noArg
2022.10.30 16:02:34 3: CUL_HM set VCCU update noArg
2022.10.30 16:02:54 3: TimeDiff_BattTimestamp_Balkonzimmer_FensterGriff: HASH(0x5a66318)
2022.10.30 16:02:57 3: Get_device_Reading: 36
2022.10.30 16:03:45 3: ABFALL Muellabfuhr - CALENDAR:Abfuhrkalender triggered, updating ABFALL Muellabfuhr ...
2022.10.30 16:07:57 3: Get_device_Reading: 36
2022.10.30 16:12:34 3: HMinfo hm get:update :
2022.10.30 16:12:34 3: CUL_HM set ActionDetector update noArg
2022.10.30 16:12:34 3: CUL_HM set VCCU update noArg
2022.10.30 16:12:57 3: Get_device_Reading: 36
2022.10.30 16:17:57 3: Get_device_Reading: 36
2022.10.30 16:22:34 3: HMinfo hm get:update :
2022.10.30 16:22:34 3: CUL_HM set ActionDetector update noArg
2022.10.30 16:22:34 3: CUL_HM set VCCU update noArg
2022.10.30 16:22:57 3: Get_device_Reading: 36
2022.10.30 16:27:57 3: Get_device_Reading: 36
2022.10.30 16:32:34 3: HMinfo hm get:update :
2022.10.30 16:32:34 3: CUL_HM set ActionDetector update noArg
2022.10.30 16:32:35 3: CUL_HM set VCCU update noArg
2022.10.30 16:32:57 3: Get_device_Reading: 36
2022.10.30 16:37:57 3: Get_device_Reading: 36
2022.10.30 16:42:35 3: HMinfo hm get:update :
2022.10.30 16:42:35 3: CUL_HM set ActionDetector update noArg
2022.10.30 16:42:35 3: CUL_HM set VCCU update noArg
2022.10.30 16:42:57 3: Get_device_Reading: 36
2022.10.30 16:47:57 3: Get_device_Reading: 36
2022.10.30 16:52:35 3: HMinfo hm get:update :
2022.10.30 16:52:35 3: CUL_HM set ActionDetector update noArg
2022.10.30 16:52:35 3: CUL_HM set VCCU update noArg
2022.10.30 16:52:35 1: ----- hminfo-crash ----- => 20_DG_Flur_BewegungsSensor, battery, ???
2022.10.30 16:52:57 3: Get_device_Reading: 36
2022.10.30 16:57:57 3: Get_device_Reading: 36
....


Nach Hinweis von Dir (Ursache ist ein ? im Reading) müssten das dann die drei '?' vom device 20_DG_Flur_BewegungsSensor sein? (meine Vermutung)

list 20_DG_Flur_BewegungsSensor

Internals:
   DEF        57CDE7
   FUUID      6298e589-f33f-8c2a-d08c-ddf5c50eeef52a99
   IODev      RM_HmUART_UG
   LASTInputDev RM_HmUART_DG
   MSGCNT     78
   NAME       20_DG_Flur_BewegungsSensor
   NR         3089
   NTFY_ORDER 48-20_DG_Flur_BewegungsSensor
   RM_HmUART_DG_MSGCNT 24
   RM_HmUART_DG_RAWMSG 0500001E2DA24157CDE74C3DF403144C80
   RM_HmUART_DG_RSSI -30
   RM_HmUART_DG_TIME 2022-10-30 17:06:53
   RM_HmUART_UG_MSGCNT 27
   RM_HmUART_UG_RAWMSG 0501003F2DA24157CDE74C3DF403144C80
   RM_HmUART_UG_RSSI -63
   RM_HmUART_UG_TIME 2022-10-30 17:06:53
   STATE      Brightness: 137 lx
   TYPE       CUL_HM
   channel_01 20_DG_Flur_BewegungsSensor_Btn_01
   channel_02 20_DG_Flur_BewegungsSensor_Btn_02
   channel_03 20_DG_Flur_BewegungsSensor_Motion
   disableNotifyFn 1
   eventCount 29
   lastMsg    No:2D - t:41 s:57CDE7 d:4C3DF4 03144C80
   myHmUART_MSGCNT 27
   myHmUART_RAWMSG 050000352DA24157CDE74C3DF403144C80
   myHmUART_RSSI -53
   myHmUART_TIME 2022-10-30 17:06:53
   protLastRcv 2022-10-30 17:06:53
   protRcv    27 last_at:2022-10-30 17:06:53
   protSnd    27 last_at:2022-10-30 17:06:53
   protState  CMDs_done
   rssi_at_RM_HmUART_DG cnt:24 min:-36 max:-29 avg:-31.87 lst:-30
   rssi_at_RM_HmUART_UG cnt:27 min:-78 max:-60 avg:-65.44 lst:-63
   rssi_at_myHmUART cnt:27 min:-54 max:-50 avg:-52.11 lst:-53
   READINGS:
     2022-10-30 17:06:53   Batt_timestamp_Flur_BewegungsSensor 2022-10-30 17:06:53
     2022-06-02 18:30:05   CommandAccepted yes
     2022-06-04 11:00:12   D-firmware      1.2
     2022-06-04 11:00:12   D-serialNr      OEQ0538581
     2022-10-30 17:06:53   IODev           RM_HmUART_UG
     2022-06-04 11:38:25   PairedTo        0x4C3DF4
     2022-06-04 11:38:25   RegL_00.        00:00 02:01 0A:4C 0B:3D 0C:F4 14:03 18:00
     2022-10-30 17:06:53   battery         ok
     2022-06-04 11:38:04   brightness      137
     2022-10-29 17:03:30   cfgState        ok
     2022-10-30 17:06:53   commState       CMDs_done
     2022-06-04 11:38:04   cover           closed
     2022-10-29 17:03:55   motion          off
     2022-06-04 11:38:04   powerOn         2022-06-04 11:38:04
     2022-06-04 11:38:04   recentStateType info
     2022-10-30 17:06:53   state           CMDs_done
   helper:
     HM_CMDNR   45
     lastMsgTm  1667146013.79751
     mId        00DB
     peerFriend -
     peerOpt    -:motionAndBtn
     regLst     0
     rxType     28
     supp_Pair_Rep 0
     tmplChg    0
     ack:
     cmds:
       TmplKey    :no:1667055795.05644
       TmplTs     1667055795.05644
       cmdKey     0:1:0::20_DG_Flur_BewegungsSensor:00DB:01:
       cmdLst:
         assignHmKey noArg
         clear      [({msgErrors}|msgEvents|rssi|attack|trigger|register|oldRegs|readings|all)]
         deviceRename -newName-
         fwUpdate   -filename- [-bootTime-]
         getConfig  noArg
         getDevInfo noArg
         getRegRaw  (List0|List1|List2|List3|List4|List5|List6|List7) [-peerChn-]
         raw        -data- [...]
         regBulk    -list-.-peerChn- -addr1:data1- [-addr2:data2-]...
         regSet     [(prep|{exec})] -regName- -value- [-peerChn-]
         reset      noArg
         tplDel     -tplDel-
         tplSet_0   -tplChan-
         unpair     noArg
       lst:
         condition  slider,0,1,255
         peer       
         peerOpt   
         tplChan   
         tplDel     
         tplPeer   
       rtrvLst:
         cmdList    [({short}|long)]
         deviceInfo [({short}|long)]
         list       [({normal}|full)]
         param      -param-
         reg        -addr- -list- [-peerChn-]
         regList    noArg
         regTable   noArg
         regVal     -addr- -list- [-peerChn-]
         saveConfig [-filename-]
         tplInfo    noArg
     expert:
       def        0
       det        0
       raw        1
       tpl        0
     io:
       flgs       0
       newChn     +57CDE7,00,00,00
       nextSend   1667146014.09336
       rxt        2
       vccu       VCCU
       p:
         57CDE7
         00
         00
         00
       prefIO:
         RM_HmUART_UG
     mRssi:
       mNo        2D
       io:
         RM_HmUART_DG:
           -30
           -30
         RM_HmUART_UG:
           -59
           -59
         myHmUART:
           -53
           -53
     peerIDsH:
     prt:
       bErr       0
       sProc      0
       sleeping   1
       rspWait:
     q:
       qReqConf   
       qReqStat   
     role:
       dev        1
     rpt:
       IO         myHmUART
       flg        A
       ts         1667146013.79751
       ack:
         HASH(0x5afb6d8)
         2D80024C3DF457CDE701014C00
     rssi:
       at_RM_HmUART_DG:
         avg        -31.875
         cnt        24
         lst        -30
         max        -29
         min        -36
       at_RM_HmUART_UG:
         avg        -65.4444444444445
         cnt        27
         lst        -63
         max        -60
         min        -78
       at_myHmUART:
         avg        -52.1111111111111
         cnt        27
         lst        -53
         max        -50
         min        -54
     shadowReg:
     tmpl:
Attributes:
   IOgrp      VCCU:RM_HmUART_UG
   alias      20_DG_Flur_BewegungsSensor
   autoReadReg 4_reqStatus
   devStateIcon yes:people_sensor@yellow no:message_presence
   expert     rawReg
   firmware   1.2
   group      Flurbeleuchtung
   icon       people_sensor
   model      HM-SEN-MDIR-WM55
   readingsWatcher 1800,???,battery,Batt_timestamp_Flur_BewegungsSensor
   room       20_Dachgeschoss->Flur
   serialNr   OEQ0538581
   stateFormat Brightness: brightness lx
   subType    motionAndBtn
   userReadings Batt_timestamp_Flur_BewegungsSensor {ReadingsTimestamp("20_DG_Flur_BewegungsSensor","battery","")}
   webCmd     getConfig:clear msgEvents


Die Fragezeichen kommen wohl vom Modul "readingsWatcher", werden aber mit gleicher Syntax in anderen devices verwendet.
comment
Beschreibung zum Modul siehe commandRef https://commandref.fhem.de/commandref_DE.html#readingsWatcher
Forumseintrag dazu Antwort #1, https://forum.fhem.de/index.php?topic=129422.0
Thema: "Idee gesucht: Feststellen, ob sich ein reading längere Zeit nicht geändert hat"

list Global_Readings_Watcher

Internals:
   DEF        global
   FUUID      633d6cad-f33f-8c2a-f176-e71076e512d88e90
   FVERSION   98_readingsWatcher.pm:v2.1.3-s25053/2021-10-07
   INTERVAL   600
   NAME       Global_Readings_Watcher
   NR         3124
   STATE      timeout
   SVN        25053
   TYPE       readingsWatcher
   eventCount 21
   READINGS:
     2022-10-30 17:03:54   20_DG_Flur_BewegungsSensor_Batt_timestamp_Flur_BewegungsSensor ok
     2022-10-30 17:03:54   20_DG_Flur_BewegungsSensor_battery ok
     2022-10-30 17:03:54   Boerse_DAX_dax  ok
     2022-10-30 17:03:54   Boerse_DAX_dax_Datum ok
     2022-10-30 17:03:54   Boerse_DAX_dax_Punkte ok
     2022-10-30 17:03:54   Boerse_DAX_dax_perc ok
     2022-10-30 17:03:54   Boerse_DJ_STOXX_600_AUTOMOBILES_STXE6A_P.EUR.P ok
     2022-10-30 17:03:54   Boerse_DJ_STOXX_600_AUTOMOBILES_STXE6A_P.EUR.P_Datum timeout
     2022-10-30 17:03:54   Boerse_DJ_STOXX_600_AUTOMOBILES_STXE6A_P.EUR.P_Punkte ok
     2022-10-30 17:03:54   Boerse_DJ_STOXX_600_AUTOMOBILES_STXE6A_P.EUR.P_perc timeout
     2022-10-30 17:03:54   Boerse_DJ_STOXX_600_BANKS_STXE6Bnk.EUR.P timeout
     2022-10-30 17:03:54   Boerse_DJ_STOXX_600_BANKS_STXE6Bnk.EUR.P_Punkte timeout
     2022-10-30 17:03:54   Boerse_DJ_STOXX_600_BANKS_STXE6Bnk.EUR.P_perc timeout
     2022-10-30 17:03:54   Boerse_DJ_STOXX_600_TELECOMMUNICATIONS_STXE6TEL.EUR.P timeout
     2022-10-30 17:03:54   Boerse_DJ_STOXX_600_TELECOMMUNICATIONS_STXE6TEL.EUR.P_Punkte timeout
     2022-10-30 17:03:54   Boerse_DJ_STOXX_600_TELECOMMUNICATIONS_STXE6TEL.EUR.P_perc timeout
     2022-10-30 17:03:54   alive           2
     2022-10-30 17:03:54   dead            3
     2022-10-30 17:03:54   deadDevs        Boerse_DJ_STOXX_600_AUTOMOBILES,Boerse_DJ_STOXX_600_BANKS,Boerse_DJ_STOXX_600_TELECOMMUNICATIONS
     2022-10-30 17:03:54   devices         5
     2022-10-30 17:03:54   readings        16
     2022-10-30 17:03:54   skipped         0
     2022-10-30 17:03:54   skippedDevs     none
     2022-10-30 17:03:54   state           timeout
     2022-10-30 17:03:54   timeoutDevs     Boerse_DJ_STOXX_600_AUTOMOBILES,Boerse_DJ_STOXX_600_BANKS,Boerse_DJ_STOXX_600_TELECOMMUNICATIONS
     2022-10-30 17:03:54   timeouts        3
Attributes:
   comment    Beschreibung zum Modul siehe commandRef https://commandref.fhem.de/commandref_DE.html#readingsWatcher
Forumseintrag dazu Antwort #1, https://forum.fhem.de/index.php?topic=129422.0
"Idee gesucht: Feststellen, ob sich ein reading längere Zeit nicht geändert hat"
   event-on-change-reading .*
   interval   600
   readingActivity none
   room       System->Main


Mir ist jetzt nicht klar, wo sollte ich Änderungen vornehmen
Hilfreich ist, dass fhem bei Auftreten des Log-Eintrags nicht mehr abstürzt, mit den Einträgen im Log kann ich leben.
Sollte ich mit weiteren Infos dienen können oder eine andere Spur verfolgen, bitte Info.

Grüße Joachim

frank

ZitatMir ist jetzt nicht klar, wo sollte ich Änderungen vornehmen
was willst du mit dem readingswatcher für battery überhaupt erreichen?
modulreadings zu verändern ist keine gute idee, hast du ja erlebt. auch wenn hminfo jetzt fhem leben lässt, passieren vielleicht an anderer stelle seltsame dinge. keine ahnung.

ich würde den actiondetector einschalten, um zu erfahren, ob der bm noch lebt.
soweit ich den thread zum mdir-wm55 verstanden habe (https://forum.fhem.de/index.php/topic,35704.0.html), existiert im device das register cyclicInfoMsg, das man "blind" auf on setzen kann, damit er regelmässig auch ohne bewegung sendet. wegen fw-bug gibt es aber kein registerreading zum verifizieren.

ausserdem gab es mindestens 2 neuere ota-fw (1.1 und 1.2). falls es nichts neueres gibt würde ich zuerst fw 1.2 flashen.

und grundsätzlich in allen hauptdevices "attr commStInCh=off" setzen und in allen entities events minimieren (zb attr event-on-change-reading=.*)
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

CottonIJo

Interessante Hinweise, über die man sich keine Gedanken macht solange man dafür keinen Bedarf hat, auch, weil mir als Otto Normalverbraucher nicht jedes Attribut oder Reading geläufig ist.
Seit ich homematic verwende ärgere ich mich mit den Unzulänglichkeiten der devices herum, ob das Kommunikationsprobleme sind (trotz guter RSSI-Werte) oder ein Vergessen des pairing bzw, peering nach Batteriewechsel. Am schlimmsten ist die unterschiedliche Implementierung des Batteriestatus, die einen zeigen den batteryLevel in Volt, die anderen können nur Ok. Und jetzt kommt die größte Unzulänglichkeit, wenn bei den Geräten die kein batteryLevel haben, die Batterie schwach ist und das Gerät dadurch offline ist, steht das Reading battery weiterhin auf "OK". Eine Überwachung der Batteriekapazität kann man damit in die Tonne treten. Also was bleibt, man prüft, ob das Reading 'battery' aktualisiert wurde, wenn nicht, muss man tätig werden. Meine Abhilfe hier einen Hinweis zu bekommen, war der ReadingsWatcher.
Ich benutze die drei '?' als Indikator dass keine Aktualisierung des Reading erfolgte.
Frage: wenn ich dort eine Zahl reinschreibe (zB. 1.0 oder 0.5) wäre damit der Fehler in HMinfo nicht mehr relevant?

Neuere ota-fw? Wo finde ich die, auf der Seite von EQ3?
Warum zeigt mir das der hm_fw_check nicht an?
Habe ich da etwas verpasst?

yersinia

Zitat von: CottonIJo am 31 Oktober 2022, 18:00:45Neuere ota-fw? Wo finde ich die, auf der Seite von EQ3?
Warum zeigt mir das der hm_fw_check nicht an?
Habe ich da etwas verpasst?
Welchen hm-fw-check nutzt du?

Aktuelle fw für die Devices sind
HM-SEN-MDIR-WM55: 1.2.0
HM-DIS-EP-WM55: 1.2.0

Darüberhinaus muss auch die fw-Version im FHEM-Device erscheinen - imho entweder im reading D-firmware oder Attribut firmware.
viele Grüße, yersinia
----
FHEM 6.4 (SVN) on RPi 4B with RasPi OS Bookworm (perl 5.36.0) | FTUI
nanoCUL->2x868(1x ser2net)@tsculfw, 1x433@Sduino | MQTT2 | Tasmota | ESPEasy
VCCU->14xSEC-SCo, 7xCC-RT-DN, 5xLC-Bl1PBU-FM, 3xTC-IT-WM-W-EU, 1xPB-2-WM55, 1xLC-Sw1PBU-FM, 1xES-PMSw1-Pl

CottonIJo

Naja, sorry, ich bin ursächlich nicht von einem fw Problem ausgegangen.
Ich habe im Anfangs-Thread nur das List vom Kanal3 des device gepostet, da ist die fw natürlich nicht gelistet.
Schaut man ins Haupt-device steht da fw 1.2
Wenn der FW-Check funktioniert, entspricht das wohl dem aktuellem Stand.

Lang, lang ist es her, ich meine der FW-Check basiert auf dem Wiki https://wiki.fhem.de/wiki/HomeMatic_Firmware_Update
List vom Sensor-device

Internals:
   DEF        57CDE7
   FUUID      6298e589-f33f-8c2a-d08c-ddf5c50eeef52a99
   IODev      RM_HmUART_UG
   LASTInputDev RM_HmUART_UG
   MSGCNT     36
   NAME       20_DG_Flur_BewegungsSensor
   NR         3082
   NTFY_ORDER 48-20_DG_Flur_BewegungsSensor
   RM_HmUART_DG_MSGCNT 11
   RM_HmUART_DG_RAWMSG 050000297EA24157CDE74C3DF4035B7B80
   RM_HmUART_DG_RSSI -41
   RM_HmUART_DG_TIME 2022-11-01 16:04:23
   RM_HmUART_UG_MSGCNT 12
   RM_HmUART_UG_RAWMSG 050100437EA24157CDE74C3DF4035B7B80
   RM_HmUART_UG_RSSI -67
   RM_HmUART_UG_TIME 2022-11-01 16:04:23
   STATE      Brightness: 137 lx
   TYPE       CUL_HM
   channel_01 20_DG_Flur_BewegungsSensor_Btn_01
   channel_02 20_DG_Flur_BewegungsSensor_Btn_02
   channel_03 20_DG_Flur_BewegungsSensor_Motion
   disableNotifyFn 1
   eventCount 17
   lastMsg    No:7E - t:41 s:57CDE7 d:4C3DF4 035B7B80
   myHmUART_MSGCNT 13
   myHmUART_RAWMSG 050000367EA24157CDE74C3DF4035B7B80
   myHmUART_RSSI -54
   myHmUART_TIME 2022-11-01 16:04:23
   protLastRcv 2022-11-01 16:04:23
   protRcv    15 last_at:2022-11-01 16:04:23
   protSnd    15 last_at:2022-11-01 16:04:23
   protState  CMDs_done
   rssi_at_RM_HmUART_DG cnt:11 min:-42 max:-32 avg:-36.18 lst:-41
   rssi_at_RM_HmUART_UG cnt:12 min:-81 max:-67 avg:-72.58 lst:-67
   rssi_at_myHmUART cnt:13 min:-69 max:-51 avg:-56.76 lst:-54
   READINGS:
     2022-11-01 16:04:23   Batt_timestamp_Flur_BewegungsSensor 2022-11-01 16:04:23
     2022-06-02 18:30:05   CommandAccepted yes
     2022-06-04 11:00:12   D-firmware      1.2
     2022-06-04 11:00:12   D-serialNr      OEQ0538581
     2022-11-01 16:04:23   IODev           RM_HmUART_UG
     2022-06-04 11:38:25   PairedTo        0x4C3DF4
     2022-06-04 11:38:25   RegL_00.        00:00 02:01 0A:4C 0B:3D 0C:F4 14:03 18:00
     2022-11-01 16:04:23   battery         ok
     2022-06-04 11:38:04   brightness      137
     2022-11-01 13:45:28   cfgState        ok
     2022-11-01 16:04:23   commState       CMDs_done
     2022-06-04 11:38:04   cover           closed
     2022-11-01 13:45:54   motion          off
     2022-06-04 11:38:04   powerOn         2022-06-04 11:38:04
     2022-06-04 11:38:04   recentStateType info
     2022-11-01 16:04:23   state           CMDs_done
   helper:
     HM_CMDNR   126
     lastMsgTm  1667315063.40456
     mId        00DB
     peerFriend -
     peerOpt    -:motionAndBtn
     regLst     0
     rxType     28
     supp_Pair_Rep 0
     tmplChg    0
     ack:
     cmds:
       TmplKey    :no:1667306714.5813
       TmplTs     1667306714.5813
       cmdKey     0:1:0::20_DG_Flur_BewegungsSensor:00DB:01:
       cmdLst:
         assignHmKey noArg
         clear      [({msgErrors}|msgEvents|rssi|attack|trigger|register|oldRegs|readings|all)]
         deviceRename -newName-
         fwUpdate   -filename- [-bootTime-]
         getConfig  noArg
         getDevInfo noArg
         getRegRaw  (List0|List1|List2|List3|List4|List5|List6|List7) [-peerChn-]
         raw        -data- [...]
         regBulk    -list-.-peerChn- -addr1:data1- [-addr2:data2-]...
         regSet     [(prep|{exec})] -regName- -value- [-peerChn-]
         reset      noArg
         tplDel     -tplDel-
         tplSet_0   -tplChan-
         unpair     noArg
       lst:
         condition  slider,0,1,255
         peer       
         peerOpt   
         tplChan   
         tplDel     
         tplPeer   
       rtrvLst:
         cmdList    [({short}|long)]
         deviceInfo [({short}|long)]
         list       [({normal}|full)]
         param      -param-
         reg        -addr- -list- [-peerChn-]
         regList    noArg
         regTable   noArg
         regVal     -addr- -list- [-peerChn-]
         saveConfig [-filename-]
         tplInfo    noArg
     expert:
       def        0
       det        0
       raw        1
       tpl        0
     io:
       flgs       0
       newChn     +57CDE7,00,00,00
       nextSend   1667315063.69961
       rxt        2
       vccu       VCCU
       p:
         57CDE7
         00
         00
         00
       prefIO:
         RM_HmUART_UG
     mRssi:
       mNo        7E
       io:
         RM_HmUART_DG:
           -41
           -41
         RM_HmUART_UG:
           -63
           -63
         myHmUART:
           -54
           -54
     peerIDsH:
     prt:
       bErr       0
       sProc      0
       sleeping   1
       rspWait:
     q:
       qReqConf   
       qReqStat   
     role:
       dev        1
     rpt:
       IO         myHmUART
       flg        A
       ts         1667315063.40456
       ack:
         HASH(0x55defc0)
         7E80024C3DF457CDE701017B00
     rssi:
       at_RM_HmUART_DG:
         avg        -36.1818181818182
         cnt        11
         lst        -41
         max        -32
         min        -42
       at_RM_HmUART_UG:
         avg        -72.5833333333333
         cnt        12
         lst        -67
         max        -67
         min        -81
       at_myHmUART:
         avg        -56.7692307692308
         cnt        13
         lst        -54
         max        -51
         min        -69
     tmpl:
Attributes:
   IOgrp      VCCU:RM_HmUART_UG
   alias      20_DG_Flur_BewegungsSensor
   autoReadReg 4_reqStatus
   devStateIcon yes:people_sensor@yellow no:message_presence
   expert     rawReg
   firmware   1.2
   group      Flurbeleuchtung
   icon       people_sensor
   model      HM-SEN-MDIR-WM55
   readingsWatcher 1800,???,battery,Batt_timestamp_Flur_BewegungsSensor
   room       20_Dachgeschoss->Flur
   serialNr   OEQ0538581
   stateFormat Brightness: brightness lx
   subType    motionAndBtn
   userReadings Batt_timestamp_Flur_BewegungsSensor {ReadingsTimestamp("20_DG_Flur_BewegungsSensor","battery","")}
   webCmd     getConfig:clear msgEvents