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
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...
<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?
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"
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?
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
@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?
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.
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
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.
@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
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 (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=.*)
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?
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 (https://ccu3-update.homematic.com/firmware/download?cmd=download&serial=0&product=HM-SEN-MDIR-WM55)
HM-DIS-EP-WM55: 1.2.0 (https://ccu3-update.homematic.com/firmware/download?cmd=download&serial=0&product=HM-DIS-EP-WM55)
Darüberhinaus muss auch die fw-Version im FHEM-Device erscheinen - imho entweder im reading D-firmware oder Attribut firmware.
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
ZitatAm schlimmsten ist die unterschiedliche Implementierung des Batteriestatus, die einen zeigen den batteryLevel in Volt, die anderen können nur Ok.
nicht ganz, oder?
alle bat devices haben batstatus.
einige devices haben
zusätzlich batlevel plus das zugehörige register lowbatlimit, das die schwelle für batstatus einstellt.
ZitatUnd 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".
zum messen der batterie muss ein device zunächst mal wach sein und die messung sollte möglichst unter grösster belastung stattfinden, damit sie auch einigermassen aussagekräftig ist. für eine lange batterielaufzeit wird also per default (
cyclicInfoMsg=off) der batteriewert nur beim "normalen" aufwachen eines sensors gemessen und als "beiwerk" mitgeliefert.
beim bm also gleichzeitig mit motion und cover.
dass ein homematic batdevice vom einlegen einer neuen batterie bis zum sterben durch leere batterie
nie lowbat gemeldet hat, kann meiner meinung nach nur einen grund haben:
cyclicInfoMsg wurde nicht eingeschaltet und das device ist zum ende der batterielaufzeit sehr lange nicht aufgewacht.
bei homematic batstatus sind meine erfahrungen eher umgekehrt => lowbat wird für meinen geschmack in der regel viel zu früh gemeldet. teilweise monate vor dem ausfall; ich habe auch schon von jahren gelesen.
ZitatEine Ü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.
nein, man muss nur grundsätzlich
cyclicInfoMsg einschalten, da mit dieser message auch immer der batstatus gemeldet wird.
wenn dein readingswatcher mit 30min timeout bei dem bm ständig reagiert, hast du
cyclicInfoMsg nicht gesetzt, gehst nicht oft genug am bm vorbei oder hast den timeout schlecht gewählt.
der homematic
actiondetector würde in etwa das gleiche tun, wenn du ihn mit "attr actCycle 000:30" einschaltest, allerdings ohne das battery reading zu manipulieren. dafür gibt es on top das reading Activity, das ggf dead meldet.
ausserdem checkt hminfo das gesamte system nach dead devices und HMinfoTools generiert eine übersichtliche tabelle, in der dead devices eigentlich immer ganz oben zu finden sind. nur devices mit attack meldungen sind ggf noch höher angesiedelt.
#####################
hilfreich ist auch die kenntnis der zu erwartenden laufzeit, die eine batterie in einem device erreicht, bis sie lowbat meldet und/oder bis sie leer ist. so kann man eventuell auch ohne lowbat meldungen "rechtzeitig" wechseln. das ist zb auch interessant für die rauchmelder sec-sd-1, da diese leider immer gleichzeitig mit der ersten lowbat meldung piepen.
HMinfoTools unterstützt dies durch vorgefertigte batterie-wechsel-infos, die über einen klick auf das battery-icon ggf editiert und im attribut comment gespeichert werden können.
ZitatbatChange: 2022-11-01 12:58:28 (oldBat: low since 2022-09-02 08:37:35)
batChange: => timestamp des klick-zeitpunktes
oldBat: => value und timestamp des battery readings zum zeitpunkt des klickens.
damit der zeitpunkt der ersten lowbat meldung einigermassen realistisch ist, müssen für das reading battery die attribute event-on-change-reading und timestamp-on-change-reading gesetzt sein. #####
leider ist das nur die halbe wahrheit, denn es kann manchmal vorkommen, dass sich eine batterie nach einem lowbat wieder erholt und erneut ok meldet.
wenn es jemanden interessiert, wann die batterie wirklich das erste mal lowbat hatte und dieser zeitpunkt im attribut comment notiert werden soll, kann man mit den folgenden 2 notifys in allen devices, die ein battery reading haben, 2 zusätzliche readings anlegen lassen, wodurch die speicherung der aller ersten lowbat meldung möglich wird.
batNotOkCtr zählt die events von low/critical und batNotOkFirstTime speichert den zeitpunkt des ersten events von low/critical.
.*:battery:.(low|critical) {
fhem("sleep 0.1; setreading $NAME batNotOkCtr ".(ReadingsVal($NAME,"batNotOkCtr",0) +1));
}.*:batNotOkCtr:.(0|1) {
if(ReadingsVal($NAME,"batNotOkCtr",0) == 1) {
fhem("sleep 0.1; setreading $NAME batNotOkFirstTime ".ReadingsTimestamp($NAME,"batNotOkCtr","?"));
}
else {
fhem("sleep 0.1; setreading $NAME batNotOkFirstTime waiting...");
}
}wenn HMinfoTools die 2 zusätzlichen readings findet, wird:
1. der timestamp aus dem reading batNotOkFirstTime für den oldBat eintrag im dialog verwendet.
2. der zähler batNotOkCtr wird beim schreiben des attr comment über den dialog wieder auf 0 gesetzt.
3. das battery-icon wird gelb dargestellt stat grün, wenn "battery=ok & batNotOkCtr > 0" ist, also nach einer batterieerholung.
4. der tooltip des battery-icons zeigt zusätzlich den wert des zählers batNotOkCtr an.
1. und 2. ist bereits mit der aktuellen version 2009 möglich
3. und 4. ab version 2010, die bei mir bereits läuft.
Hallo frank, danke für die Mühe die Du dir machst technisches Wissen zu vermitteln und für die Hilfestellungen mehr Licht in das Dunkel zu bringen.
Ich werde Deine Empfehlungen in die betroffenen devices einbauen und beobachten ob sich die dann ergebenden Informationen nutzen lassen verlässlicher auf den Status des Batteriezustands reagieren zu können.
HMinfo nutze ich jetzt auch in dem von Dir empfohlenen Umfang.
Meine Sorgenkinder sind alle devices die kein Reading batteryLevel haben, den man als Grenzwert schön abfragen kann.
Ich kann mich aber Deiner Meinung bezüglich der Notwendigkeit von Attributen, um den Batteriezustand ermitteln zu können, nicht ganz anschließen.
Ich erwarte von einem Gerät, welches "OK" senden kann, dass es auch zustandsbedingt "nicht OK" sendet, sonst brauche ich die Meldung nicht.
Als Anwender erwarte ich nicht, dass ich hier Aufwand investieren muss damit es verwendbar funktioniert.
Auf Firmware-Seite kann es kein Hexenwerk sein von sich aus zyklisch eine Meldung an den Master (fhem oder CCUx) zu schicken.
Was ist das für ein Ansatz, lebenswichtige Attribute nur zu senden, wenn ich angestoßen werde oder eine Aktion angefordert wird?
Ich habe an jedem Kellerfenster unseres Hauses je einen Sensor am Rahmen und am Fenstergriff, im Winter werden die Fenster seltener als im Sommer geöffnet.
Ergo ist es mir schon mehrfach passiert, dass der Batteriestatus auf "OK" stand, die Batterie(n) aber leer war(en)
Weder in der Bedienungsanleitung von EQ3 noch im Wiki von fhem steht drin, dass empfohlen wird eine Batterieüberwachung in fhem zu implementieren.
Jetzt würde mich interessieren, bin ich der Einzige der nicht weiß, dass man und wie man hier selbst Abhilfe schaffen sollte (Attribute setzen) oder geht es Anderen ebenso?
Grüße Joachim
ZitatAuf Firmware-Seite kann es kein Hexenwerk sein von sich aus zyklisch eine Meldung an den Master (fhem oder CCUx) zu schicken.
ist es ja auch nicht. per default ist es aber nun mal ausgeschaltet.
vermutlich weil die devices auch ohne zentrale genutzt werden können und in diesem fall eine zyklische meldung nur unnötig batterielaufzeit kostet.
das einschalten von cyclicInfoMsg wird auch im wiki empfohlen, und nicht nur an einer stelle. ;)
https://wiki.fhem.de/wiki/HM-SEC-SC_T%C3%BCr-Fensterkontakt#Batteriestatus_aktivieren (https://wiki.fhem.de/wiki/HM-SEC-SC_T%C3%BCr-Fensterkontakt#Batteriestatus_aktivieren)
https://wiki.fhem.de/wiki/HomeMatic_Type_threeStateSensor (https://wiki.fhem.de/wiki/HomeMatic_Type_threeStateSensor)
https://wiki.fhem.de/wiki/Trick_der_Woche#Juni_2014 (https://wiki.fhem.de/wiki/Trick_der_Woche#Juni_2014)
mit der 98_HMinfo.pm von hier https://forum.fhem.de/index.php/topic,120857.msg1243902.html#msg1243902 (https://forum.fhem.de/index.php/topic,120857.msg1243902.html#msg1243902) ist es auch möglich das "attr hminfo sumERROR" mit dem eintrag "batNotOkCtr:0" zu erweitern, damit in HMinfoTools.js auch devices einen fehler zeigen, bei denen das reading batNotOkCtr > 0 ist.
also auch devices, die aktuell batstatus=ok haben, aber bereits mindestens einmal low hatten (batterie hat sich nach einem low nochmal erholt)
@frank, ok, bin bezüglich fhem wieder etwas schlauer geworden.
Noch eine Frage zu cyclicInfoMsg beim HM-RC-4-3 (Fernbedienung)
Das Reading gibt es bei dem device wohl nicht.
Dies führt dazu, dass trotz actCycle = 002:00 das device bis zu einem Tastendruck dead bleibt.
Somit bleibt eine gewisse Ungenauigkeit der aktuellen Kapazität der Batterie?
Oder gibt es hier einen Parameter den man hilfsweise setzen könnte?
Internals:
CFGFN ./FHEM/include/fhem_dachgeschoss.cfg
DEF 6AAE22
FUUID 5d188579-f33f-8c2a-cff1-0e60579bc9bcbaa9
IODev myHmUART
LASTInputDev RM_HmUART_UG
MSGCNT 15
NAME 20_DG_SZ_Remote_Control2
NR 993
NTFY_ORDER 48-20_DG_SZ_Remote_Control2
RM_HmUART_UG_MSGCNT 8
RM_HmUART_UG_RAWMSG 05000047F1A2406AAE224C3DF44212
RM_HmUART_UG_RSSI -71
RM_HmUART_UG_TIME 2022-11-03 07:19:30
STATE CMDs_done
TYPE CUL_HM
channel_01 20_DG_SZ_Remote_Control2_Btn_01
channel_02 20_DG_SZ_Remote_Control2_Btn_02
channel_03 20_DG_SZ_Remote_Control2_Btn_03
channel_04 20_DG_SZ_Remote_Control2_Btn_04
disableNotifyFn 1
eventCount 7
lastMsg No:F1 - t:40 s:6AAE22 d:4C3DF4 4212
myHmUART_MSGCNT 7
myHmUART_RAWMSG 05010041F1A2406AAE224C3DF44212
myHmUART_RSSI -65
myHmUART_TIME 2022-11-03 07:19:30
protLastRcv 2022-11-03 07:19:30
protRcv 8 last_at:2022-11-03 07:19:30
protSnd 2 last_at:2022-11-03 07:19:30
protState CMDs_done
rssi_at_RM_HmUART_UG cnt:8 min:-77 max:-70 avg:-73.12 lst:-71
rssi_at_myHmUART cnt:7 min:-79 max:-65 avg:-71.14 lst:-65
READINGS:
2022-11-03 09:25:07 Activity dead
2022-11-04 11:17:37 Batt_timestamp_SZ_Remote_Control2 2022-11-03 07:19:30
2019-06-30 12:10:04 CommandAccepted yes
2019-06-30 12:10:03 D-firmware 1.1
2019-06-30 12:10:03 D-serialNr PEQ0781061
2022-11-03 07:19:30 IODev myHmUART
2022-03-14 08:05:58 PairedTo 0x4C3DF4
2019-06-30 12:10:05 R-pairCentral 0x4C3DF4
2022-03-14 08:05:58 RegL_00. 00:00 02:01 0A:4C 0B:3D 0C:F4 18:00
2022-03-13 10:51:43 alive yes
2022-11-03 07:19:30 battery ok
2022-11-04 11:17:37 cfgState ok
2022-11-03 07:19:30 commState CMDs_done
2022-03-13 10:51:43 powerOn 2022-03-13 10:51:43
2022-03-13 10:51:43 recentStateType info
2022-11-03 07:19:30 state CMDs_done
helper:
HM_CMDNR 241
lastMsgTm 1667456370.19748
mId 00D4
peerFriend -
peerOpt -:remote
regLst 0
rxType 28
supp_Pair_Rep 0
tmplChg 0
ack:
cmds:
TmplKey :no:1667306714.58214
TmplTs 1667306714.58214
cmdKey 0:1:0::20_DG_SZ_Remote_Control2:00D4: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 1
det 0
raw 1
tpl 0
io:
flgs 0
newChn +6AAE22,00,00,00
nextSend 1667456370.49369
rxt 2
vccu VCCU
p:
6AAE22
00
00
00
prefIO:
RM_HmUART_DG
mRssi:
mNo F1
io:
RM_HmUART_UG:
-71
-71
myHmUART:
-61
-61
peerIDsH:
prt:
bErr 0
sProc 0
sleeping 1
rspWait:
q:
qReqConf
qReqStat
role:
dev 1
rpt:
IO myHmUART
flg A
ts 1667456370.19748
ack:
HASH(0x29a36a8)
F180024C3DF46AAE2200
rssi:
at_RM_HmUART_UG:
avg -73.125
cnt 8
lst -71
max -70
min -77
at_myHmUART:
avg -71.1428571428572
cnt 7
lst -65
max -65
min -79
shadowReg:
tmpl:
Attributes:
IOgrp VCCU:RM_HmUART_DG
actCycle 002:00
actStatus dead
alias 20_DG_SZ_Remote_Control2
autoReadReg 5_readMissing
comment Btn_02 - Taste ganz oben
"long" - Rollladen ganz auf
"short" - Rollladen 10%-Schritt hoch
Btn_01 - Taste 2. von oben
"long" - Abschattung 45%
"short" - Rollladen "stop"
Btn_04 - Taste 3. von oben
"long" - Abschattung 20%
"short" - Rollladen "stop"
Btn_03 - Taste ganz unten
"long" - Rollladen ganz zu
"short" - Rollladen 10%-Schritt runter
event-on-change-reading .*
expert defReg,rawReg
firmware 1.1
group Remote-Control
icon it_remote
model HM-RC-4-3
room 20_Dachgeschoss->Schlafzimmer
serialNr PEQ0781061
subType remote
userReadings Batt_timestamp_SZ_Remote_Control2 {ReadingsTimestamp("20_DG_SZ_Remote_Control2","battery","")}
webCmd getConfig:clear msgEvents
Grüße Joachim
bei der fb gibt es wohl keine möglichkeit zum einstellen.
eventuell sendet diese aber per default trotzdem regelmässig, da sie angeblich den mode wakeup unterstützt. allerdings bleibt die frage, in welchem abstand diese meldungen kommen könnten.
das müsstest du wohl selber testen.
dann wären die eingestellten 2 std für den actiondetector vielleicht nur zu kurz gewählt.
den längsten zyklus, den ich kenne, haben die rauchmelder mit etwa 3 tagen. da setzt cul_hm den actioncycle automatisch auf 99 std.
wie oft wird sie denn benutzt?
falls sie in der regel 1x die woche benutzt wird, könntest du zb 168 std setzen. falls trotzdem mal dead kommt, wäre das eine erinnerung zum knöpfchen drücken.
eine woche sollten batterien mindestens nach der ersten low meldung noch funktionieren, eher mehr denke ich. es sei denn sie sind tief in einer handtasche vergraben und werden aus versehen durch andere gegenstände permanent gedrückt. ;)
Danke, probier ich aus.