aufgrund des versterbens meines alten regensensors hab ich mir einen neuen gegönnt.
anlernen ging,m auch der sensorteil und die heizung wurden auf anhieb erkannt und richtig eingetraegn.
eins set getdeviceinfo und getconfig waren auch kein problem.
dann hab ich versuchsweise die heizung eingeschaltet - ging.
ausschalten nicht mehr. er werkelt und meint missing ack
folende liste flutet mir jetzt das logfile:
2021.09.17 16:32:55 1: PERL WARNING: Use of uninitialized value $d in hash element at fhem.pl line 4681.
2021.09.17 16:32:55 1: stacktrace:
2021.09.17 16:32:55 1: main::__ANON__ called by fhem.pl (4681)
2021.09.17 16:32:55 1: main::AttrVal called by ./FHEM/10_CUL_HM.pm (10820)
2021.09.17 16:32:55 1: main::CUL_HM_assignIO called by ./FHEM/10_CUL_HM.pm (11014)
2021.09.17 16:32:55 1: main::CUL_HM_procQs called by fhem.pl (3427)
2021.09.17 16:32:55 1: main::HandleTimeout called by fhem.pl (695)
2021.09.17 16:32:55 1: PERL WARNING: Use of uninitialized value $d in hash element at fhem.pl line 4681.
2021.09.17 16:32:55 1: stacktrace:
2021.09.17 16:32:55 1: main::__ANON__ called by fhem.pl (4681)
2021.09.17 16:32:55 1: main::AttrVal called by fhem.pl (2229)
2021.09.17 16:32:55 1: main::fhem_setIoDev called by fhem.pl (2252)
2021.09.17 16:32:55 1: main::AssignIoPort called by ./FHEM/10_CUL_HM.pm (10838)
2021.09.17 16:32:55 1: main::CUL_HM_assignIO called by ./FHEM/10_CUL_HM.pm (11014)
2021.09.17 16:32:55 1: main::CUL_HM_procQs called by fhem.pl (3427)
2021.09.17 16:32:55 1: main::HandleTimeout called by fhem.pl (695)
2021.09.17 16:32:55 1: PERL WARNING: Use of uninitialized value $d in hash element at fhem.pl line 2793.
2021.09.17 16:32:55 1: stacktrace:
2021.09.17 16:32:55 1: main::__ANON__ called by fhem.pl (2793)
2021.09.17 16:32:55 1: main::getAllAttr called by fhem.pl (4700)
2021.09.17 16:32:55 1: main::fhem_devSupportsAttr called by fhem.pl (4711)
2021.09.17 16:32:55 1: main::setReadingsVal called by fhem.pl (2234)
2021.09.17 16:32:55 1: main::fhem_setIoDev called by fhem.pl (2252)
2021.09.17 16:32:55 1: main::AssignIoPort called by ./FHEM/10_CUL_HM.pm (10838)
2021.09.17 16:32:55 1: main::CUL_HM_assignIO called by ./FHEM/10_CUL_HM.pm (11014)
2021.09.17 16:32:55 1: main::CUL_HM_procQs called by fhem.pl (3427)
2021.09.17 16:32:55 1: main::HandleTimeout called by fhem.pl (695)
2021.09.17 16:32:55 1: PERL WARNING: Use of uninitialized value $ID in concatenation (.) or string at ./FHEM/10_CUL_HM.pm line 10842.
2021.09.17 16:32:55 1: stacktrace:
2021.09.17 16:32:55 1: main::__ANON__ called by ./FHEM/10_CUL_HM.pm (10840)
2021.09.17 16:32:55 1: main::CUL_HM_assignIO called by ./FHEM/10_CUL_HM.pm (11014)
2021.09.17 16:32:55 1: main::CUL_HM_procQs called by fhem.pl (3427)
2021.09.17 16:32:55 1: main::HandleTimeout called by fhem.pl (695)
2021.09.17 16:32:55 1: PERL WARNING: Use of uninitialized value $devname in hash element at fhem.pl line 875.
2021.09.17 16:32:55 1: stacktrace:
2021.09.17 16:32:55 1: main::__ANON__ called by fhem.pl (875)
2021.09.17 16:32:55 1: main::IsDummy called by fhem.pl (1040)
2021.09.17 16:32:55 1: main::IOWrite called by ./FHEM/10_CUL_HM.pm (10840)
2021.09.17 16:32:55 1: main::CUL_HM_assignIO called by ./FHEM/10_CUL_HM.pm (11014)
2021.09.17 16:32:55 1: main::CUL_HM_procQs called by fhem.pl (3427)
2021.09.17 16:32:55 1: main::HandleTimeout called by fhem.pl (695)
2021.09.17 16:32:55 1: HMUARTLGW hmLan2 write: init:
2021.09.17 16:33:09 1: PERL WARNING: Use of uninitialized value $d in hash element at fhem.pl line 4681.
2021.09.17 16:33:09 1: stacktrace:
2021.09.17 16:33:09 1: main::__ANON__ called by fhem.pl (4681)
2021.09.17 16:33:09 1: main::AttrVal called by ./FHEM/10_CUL_HM.pm (10820)
2021.09.17 16:33:09 1: main::CUL_HM_assignIO called by ./FHEM/10_CUL_HM.pm (11014)
2021.09.17 16:33:09 1: main::CUL_HM_procQs called by fhem.pl (3427)
2021.09.17 16:33:09 1: main::HandleTimeout called by fhem.pl (695)
der sensor:Internals:
CFGFN
DEF 70FEFD
FUUID 6144a1ac-f33f-f543-43d9-bce56284ce3f8bf0
IODev hmLan2
LASTInputDev hmLan2
MSGCNT 485
NAME HM_70FEFD
NR 64574
NTFY_ORDER 50-HM_70FEFD
STATE MISSING ACK
TYPE CUL_HM
channel_01 HM_70FEFD_Rain
channel_02 HM_70FEFD_Heating
disableNotifyFn 1
hmLan2_MSGCNT 485
hmLan2_RAWMSG 0403000E84800270FEFD322433010200000B
hmLan2_RSSI -14
hmLan2_TIME 2021-09-17 16:34:03
lastMsg No:84 - t:02 s:70FEFD d:322433 010200000B
protCmdDel 1
protCmdPend 1 CMDs_pending
protLastRcv 2021-09-17 16:34:03
protRcv 129 last_at:2021-09-17 16:34:03
protResnd 3 last_at:2021-09-17 16:34:18
protResndFail 1 last_at:2021-09-17 16:34:23
protSnd 130 last_at:2021-09-17 16:34:03
protState CMDs_pending
rssi_at_hmLan2 cnt:486 min:-45 max:-13 avg:-18.68 lst:-14
rssi_hmLan2 cnt:447 min:-34 max:-10 avg:-15.38 lst:-11
CL:
Authenticated 0
BUF
FD 16
FW_ID 69595
LASTACCESS 1631889542
NAME handyWEB_192.168.178.51_12816
NR 69594
PEER 192.168.178.51
PORT 12816
SNAME handyWEB
SSL
STATE Connected
TEMPORARY 1
TYPE FHEMWEB
canAsyncOutput 1
READINGS:
2021-09-17 16:38:12 state Connected
READINGS:
2021-09-17 16:11:00 CommandAccepted yes
2021-09-17 16:32:12 D-firmware 1.4
2021-09-17 16:32:12 D-serialNr REQ0400646
2021-09-17 16:34:03 IODev hmLan2
2021-09-17 16:24:02 PairedTo 0x322433
2021-09-17 16:24:02 RegL_00. 00:00 02:00 0A:32 0B:24 0C:33 14:06 18:00
2021-09-17 16:24:02 cfgState updating
2021-09-17 16:34:23 commState CMDs_pending
2021-09-17 16:31:40 powerOn 2021-09-17 16:31:40
2021-09-17 16:34:23 state MISSING ACK
cmdStack:
++A01132243370FEFD0202000000
helper:
HM_CMDNR 133
PONtest 1
cSnd 1132243370FEFD0202000000,1132243370FEFD0202000000
cfgStateUpdt 1
lastMsgTm 1631889243.21104
mId 00A7
peerFriend peerAct,peerVirt
peerOpt 4:sensRain
regLst 0,1,4p
rxType 1
supp_Pair_Rep 0
cmds:
TmplKey :no:1631887793.19347
TmplTs 1631887793.19347
cmdKey 0:1:0::HM_70FEFD:00A7:00:
cmdLst:
assignHmKey noArg
clear [(readings|trigger|register|oldRegs|rssi|msgEvents|{msgErrors}|attack|all)]
deviceRename -newName-
fwUpdate -filename- [-bootTime-]
getConfig noArg
getDevInfo noArg
getRegRaw (List0|List1|List2|List3|List4|List5|List6|List7) [-peerChn-]
peerSmart -peerOpt-
raw -data- [...]
regBulk -list-.-peerChn- -addr1:data1- [-addr2:data2-]...
regSet [(prep|{exec})] -regName- -value- [-peerChn-]
reset noArg
sign [(on|{off})]
tplDel -tplDel-
trgEventL -peer- -condition-
trgEventS -peer- -condition-
trgPressL [(-peer-|{all})]
trgPressS [(-peer-|{all})]
unpair noArg
lst:
condition dry,rain
peer
peerOpt 4k12v_schalter1,4k12v_schalter2,4k12v_schalter3,4k12v_schalter4,schlafzimmer_rollo,solaranlage_kuehlung,wohnzimmer_buero_licht_Dim,wohnzimmer_buero_licht_Dim_V_01,wohnzimmer_buero_licht_Dim_V_02,wohnzimmer_gang_gz_licht_Dim,wohnzimmer_gang_gz_licht_Dim_V_01,wohnzimmer_gang_gz_licht_Dim_V_02,wohnzimmer_gang_sz_licht_Dim,wohnzimmer_gang_sz_licht_Dim_V_01,wohnzimmer_gang_sz_licht_Dim_V_02,wohnzimmer_rollo_strasse,wohnzimmer_rollo_terrasse,wohnzimmer_sofa_licht_Dim,wohnzimmer_sofa_licht_Dim_V_01,wohnzimmer_sofa_licht_Dim_V_02
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 +70FEFD,00,00,00
nextSend 1631889243.29267
rxt 0
vccu vccu
p:
70FEFD
00
00
00
prefIO:
mRssi:
mNo 84
io:
hmLan2:
-6
-6
peerIDsH:
prt:
bErr 0
sProc 2
tryMsg:
q:
qReqConf
qReqStat
regCollect:
role:
dev 1
rssi:
at_hmLan2:
avg -18.6831275720165
cnt 486
lst -14
max -13
min -45
hmLan2:
avg -15.3870246085011
cnt 447
lst -11
max -10
min -34
shadowReg:
tmpl:
Attributes:
IOgrp vccu:hmLan2
autoReadReg 4_reqStatus
expert rawReg
firmware 1.4
model HM-SEN-RD-O
serialNr REQ0400646
subType sensRain
webCmd getConfig:clear msgEvents
die heizungInternals:
CFGFN
DEF 70FEFD02
FUUID 6144a1ac-f33f-f543-5287-d777c8f701e9da53
NAME HM_70FEFD_Heating
NR 64576
NTFY_ORDER 50-HM_70FEFD_Heating
STATE set_off noArg
TYPE CUL_HM
chanNo 02
device HM_70FEFD
disableNotifyFn 1
CL:
Authenticated 0
BUF
FD 32
FW_ID 69594
LASTACCESS 1631889589
NAME handyWEB_192.168.178.51_10512
NR 69393
PEER 192.168.178.51
PORT 10512
SNAME handyWEB
SSL
STATE Connected
TEMPORARY 1
TYPE FHEMWEB
canAsyncOutput 1
READINGS:
2021-09-17 16:37:04 state Connected
READINGS:
2021-09-17 16:34:03 CommandAccepted yes
2021-09-17 16:24:02 cfgState updating
2021-09-17 16:34:23 commState CMDs_pending
2021-09-17 16:34:03 recentStateType ack
2021-09-17 16:34:23 state set_off noArg
2021-09-17 16:34:03 timedOn off
2021-09-17 16:34:03 trigLast fhem:02
helper:
dlvl 00
dlvlCmd ++A01132243370FEFD0202000000
getCfgListNo
cmds:
TmplKey :no:1631887793.22246
TmplTs 1631887793.22246
cmdKey 1:0:0::HM_70FEFD:00A7:02:
cmdLst:
clear [(readings|trigger|register|oldRegs|rssi|msgEvents|{msgErrors}|attack|all)]
getConfig noArg
getRegRaw (List0|List1|List2|List3|List4|List5|List6|List7) [-peerChn-]
off noArg
on noArg
on-for-timer -sec-
on-till -time-
peerBulk -peer1,peer2,...- [({set}|unset)]
regBulk -list-.-peerChn- -addr1:data1- [-addr2:data2-]...
regSet [(prep|{exec})] -regName- -value- [-peerChn-]
toggle noArg
tplDel -tplDel-
tplSet_0 -tplChan-
lst:
condition dry,off,on,rain
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
param:
peerIDsH:
role:
chn 1
tmpl:
Attributes:
model HM-SEN-RD-O
die regenanzeige:Internals:
CFGFN
DEF 70FEFD01
FUUID 6144a1ac-f33f-f543-1214-e7785144cc8f71d4
NAME HM_70FEFD_Rain
NR 64575
NTFY_ORDER 50-HM_70FEFD_Rain
STATE dry
TYPE CUL_HM
chanNo 01
device HM_70FEFD
disableNotifyFn 1
CL:
Authenticated 0
BUF
FD 15
FW_ID 69595
LASTACCESS 1631889693
NAME handyWEB_192.168.178.51_7089
NR 69593
PEER 192.168.178.51
PORT 7089
SNAME handyWEB
SSL
STATE Connected
TEMPORARY 1
TYPE FHEMWEB
canAsyncOutput 1
READINGS:
2021-09-17 16:38:12 state Connected
OLDREADINGS:
READINGS:
2021-09-17 16:24:03 RegL_01. 00:00 08:00 22:64 23:00 30:06 87:0B 88:54 8B:0B 8C:22 8F:85 91:82
2021-09-17 16:24:02 cfgState updating
2021-09-17 16:34:23 commState CMDs_pending
2021-09-17 16:31:40 recentStateType info
2021-09-17 16:34:23 regen dry
2021-09-17 16:31:40 state dry
2021-09-17 16:31:40 timedOn off
helper:
peerIDsRaw ,00000000
peerIDsState complete
cmds:
TmplKey :no:1631887793.22283
TmplTs 1631887793.22283
cmdKey 1:0:0::HM_70FEFD:00A7:01:
cmdLst:
clear [(readings|trigger|register|oldRegs|rssi|msgEvents|{msgErrors}|attack|all)]
getConfig noArg
getRegRaw (List0|List1|List2|List3|List4|List5|List6|List7) [-peerChn-]
peerBulk -peer1,peer2,...- [({set}|unset)]
peerChan 0 -actChn- [({single})] [({set}|unset)] [actor|remote|both]
regBulk -list-.-peerChn- -addr1:data1- [-addr2:data2-]...
regSet [(prep|{exec})] -regName- -value- [-peerChn-]
tplDel -tplDel-
tplSet_0 -tplChan-
lst:
condition dry,dry,rain,rain
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
peerIDsH:
00000000 broadcast
regCollect:
role:
chn 1
shadowReg:
tmpl:
Attributes:
model HM-SEN-RD-O
peerIDs 00000000
userReadings regen { ReadingsVal($name,"state",0); }
der hm_lam ist beta users einer vom 26.8.
kann man mir helfen?
NACHTRAG:
ich hab mal meinen alten regensensor aus fehm gelöscht, nach einem restart ist auch der neue sensor weg (und ja, ich hatte gespeichert *g*)
ich bin verwirrt ... werd nach dem abendessen nochmal ganz neu anlernen, mal schauen, was passiert.
o.k. ich hab's problem gefunden und kann notfalls damit leben, aber vielleicht sollts ein wissender gegenprüfen.
fhem erkennt sehr flott alles, ich kann auch pairen und es geht auch alles.
ich darf nur kein devicerename machen. er benennt zwar alles richtig um, aber dann spinnt die geschichte.
mal ohne umbenennen warten - wenn er dann auch spinnt, müßt es eh schnell gehen, bis mein log schreit.
Kannst du das nach Homematic verschieben und: das war CUL_HM-rename (set ... deviceRename ...), richtig?
Welche version (meine gepatchte oder aktuelle svn oder was früheres)?
das ist die "mittlere" version deiner gepatchten datei, also nicht die neueste, sondern die um den 26.8. rum. das was wir dann probiert haben, bis die warnings nicht mehr kahmen.
das verhalten ist beim umbenennen ganz lustig - ich benenne das direkt im set des geräts auf der weboberfläche um.
das hauptgerät und auch die 2 kanäle werden umbenannt. aber die kanäle glauben immer noch, sie wären mit dem alten namen verbunden - auch nach speichern und nem restart.
btw - rennt jetzt immer noch, wenn ichs nicht umbenenne. es tauchen auch die alten 2 kanäle vom kaputten sensor nicht mehr auf, wies beim ersten mal der fall war. komisches verhalten, ich hatte die dinger gelöscht, gespeichert und neu gestartet.
somit lass ichs lieber mal. das ist nun mehr eher für dich/andere, die da vielleicht nen generellen fehler drin sehen ...
Martin hatte da noch was gedreht, was ich auch noch nicht ganz durchschaut habe, warum das greift, müßte mal in Ruhe die ganzen Nebenbezüge durchgehen.
Aber: irgendwas in der Initialisierung der Geräte ist wieder an der richtigen Stelle, von daher wäre es klasse, wenn du die neuesten Versionen (gerne gepatcht) daraufhin mal testen könntest.
mach ich morgen ... muß ich was beachten oder mit warnings/fehlern rechnen?
was is eigentlich grad das aktuelle? hab da irgendwie den überblick verloren, oder meinst das offizielle?
ne dumme frage nebenbei zum gerät ansich:
ists eigentlich unmöglich, die infos zu rain und heating aus den states der jeweiligen kanälen in eigenes reading zu nehmen?
Zum Gerät kann ich nichts sagen, aber es würde mich wundern, wenn du auf die Frage hier eine Antwort bekommst: Du bist immer noch in "Home Connect"...
Ansonsten fiele mir nur das Stichwort readingsProxy ein.
Was die Versionen angeht: Martin hat ins svn eine Version eingestellt, die einen Teil der Probleme löst. In deinem warnings-Thread gibt's dann darauf aufbauend noch eine von mir gepatchte CUL_HM, die dann mAn. noch weitere Probleme löst. Leider noch nicht alles... (attr tempListTmpl geht weiter nicht)
immer diese hetzerei *g* ich hab mich nun ent-connected.
warum schau ich eigentlich vor jedem restart ins forum, ob irgendwo ein roter beitrag vom system über ne neue version steh? da muß ich ja dann irgendwann mal martins neue version verpennt haben, oder foppt mich das system?
auf gut deutsch, kann ich endlich die sperre rausnehmen und cul_hm offiziell saugen. gut, mach ich.
mit templates hab ich eh nix am hut, wird nur genommen, wenns mir gesagt wird ...
gut, ich restarte mal mit neuem cul_hm und berichte.
nachtrag:
geht zumindest mal alles - inkl. meines regensensors.
3% load in den ersten 5 sek. is auch der übliche wert ... hatte ich die tage auch schon andere werte.
logfile bleibt auch leer .... juhuu, wir haben "grundfunktion" *g*
aja, wegen der gewünschten readings ... das hatten ma schon beim damaligen super gau mit doif.
das funzt jetzt ja auch beim doif, wenn du dich an addstateevent hältst, aber auch ned so wirklich, wenn du weitere spielereien, wie z.b. "IF"'s im ausführungsteil hast. ist dann wieder das übliche geht-geht nicht-vielleicht-oder auch nicht spielchen ohne jeglichen fehlermeldung, nur mit (über/unter)reaktion der doifs.
der einfachste weg, da alle eventuelle probleme raus zu nehmen, wäre halt ein reading, daß nur on/off und dry/rain anzeigt. gerne auch im sensor selber und nicht in den kanälen (das wäre aber nur die kür).
alles andere wird sonst eh wieder nur mimimi, wenns wieder los geht, wer dran schuld is. doif, hm oder der dumme user beim schlechten programmieren.
mir fällt so mal rund um den tag nix besonderes auf - weder an meiner neuen hardware, noch am neuen cul_hm (der aktuelle, offizielle)
nach nem restart meint er 2021.09.19 08:58:05 1: CUL_HM start inital cleanup
2021.09.19 08:58:06 1: CUL_HM finished initial cleanup
aber das wars auch schon an besonderheiten ...
Wenn zwischen den beiden Zeilen nichts steht, scheint auch alles "sauber" zu sein, was peerings etc. angeht. Du hast demnach keine Geräte, die AES nutzen (oder keine VCCU)?
Die (noch?) nicht integrierten patch-Vorschläge sind nichts großes, lediglich die internen Datenstrukturen zu helper->io->ioList werden direkt beim Systemstart so gesetzt, wie wenn man nachträglich IOList ändert (von daher gehe ich davon aus, dass das initiale Fehlen unbeabsichtigt ist, und die AES-Geschichte irgendwie stört), und man kann stateFormat auch bei CUL_HM-Geräten via FHEMWEB setzen... (Weiß nicht, ob ich noch was vergessen habe).
Ergo dürfte auch "meine" Fassung keine neuen Probleme verursachen.
vccu hab ich, über die auch alles gepaired wird
peerings ... nö
aes ... nö, früher mal ja
Zitatund man kann stateFormat auch bei CUL_HM-Geräten via FHEMWEB setzen...
was meinst damit, großer meischter?
Versuche einfach mal, ein stateFormat an einem beliebigen CUL_HM-Gerät zu ändern, ohne die cfg zu editieren ;) .
Unklar, ob noch ein Problem besteht.
Das cleanup bei reboot geht recht fix bei dir. Erfreulich.
Die patches von beta-user bitte einmal zukommen lassen. Wird die nächsten Wochen nichts, aber ich werde es durchgehen. PM wäre gut, ggf mit links zu den\dem Beitrag. Dann rutscht es nicht nach hinten.
Readings kann ich schon optimieren. Aber nicht alles! Das konzept von "readings im kanal welcher sie meldet" und "ändern des Inhalts damit eventonchange" funktioniert.
Alles andere kann man mit userreadings und stateformat sowieso selbst erledigen.
Mein Traum ist immernoch ein abstraktionslayer über culhm...der würde zusammenfassen was man braucht.. Vielleicht nie... Eigentlich macht tablet UI so etwas
Zitat von: Beta-User am 19 September 2021, 09:49:52
Versuche einfach mal, ein stateFormat an einem beliebigen CUL_HM-Gerät zu ändern, ohne die cfg zu editieren ;) .
ja, aber warum? oder besser: was schreib ich dann da hin, wenn ich nur on/off und dry/rain dort sehen will und sich das ganze auch noch wie jedes andere reading verhalten und nicht , wenns grad lustig ist, zu "flimmern" beginnen soll?
ich merke auf jeden fall folgendes: leg ich ein userreading an, daß den state ausliest, dann hab ich in den doifs damit die selben probleme wie mit dem state selber - irgendwie auch logisch, denk ich.
Hallo ratman
Zitat von: the ratman am 17 September 2021, 16:42:52
aufgrund des versterbens meines alten regensensors hab ich mir einen neuen gegönnt.
ausschalten nicht mehr. er werkelt und meint missing ack
So ein aehnliches Problem hatte ich auch gerade.
Habe meinen neuen Drehgriffsensor zum Anlernen und programmieren mit ins Buero genommen, woch auch einer meiner HMLANs steht.
Gab immer wieder ein "Missing Ack"
Dann habe ich einfach den Abstand zu jedem HMLAN auf min. 4 m eingehalten (aus dem Raum raus gegangen) und schon hat alles geklappt.
Ein Versuch Wert!
Gruß
Sailor
@Sailor:
ZitatIch habe das jetzt mal mit ins WIKI für den HMLAN unter "Bekannte Probleme" mit aufgenommen.
Das ist ein Thema, das nicht nur HMLAN betrifft, sondern alle Homematic-Interfaces bzw. teils auch die Kommunikation zwischen gepeerten Komponenten. Leider konnte ich das nicht mehr am richtigen Ort anmerken, weil jemand die Forenregeln nicht beachtet hat und den Thread geschlossen...
Zitat von: the ratman am 19 September 2021, 12:44:57
ja, aber warum?
Es ist m.E. nicht die Frage, warum man stateFormat bei CUL_HM-Geräten setzen will (da ist state mAn. in der Regel richtig aussagekräftig und das Setzen meistens überflüssig), sondern es geht darum, dass es als "gehärtetes" Attribut angesehen wird, und sich das Modul (ich hoffe: unbeabsichtigt) weigert, Wünsche des Users überhaupt entgegenzunehmen. Von daher ist
Zitat von: martinp876 am 19 September 2021, 10:06:43
Alles andere kann man mit userreadings und stateformat sowieso selbst erledigen.
nicht passend, weil stateFormat "zu" ist...
Zitat
ich merke auf jeden fall folgendes: leg ich ein userreading an, daß den state ausliest, dann hab ich in den doifs damit die selben probleme wie mit dem state selber - irgendwie auch logisch, denk ich.
Ja, das wird genauso oft (mit) getriggert wie state. Du müßtest auf was anders in der Auswertung gehen bzw. dem Trigger für das userReadings, nehme ich mal an.
@Martin:
Bei mir dauert das deutlich länger mit dem initial cleanup:
2021.09.18 13:13:50 1: CUL_HM start inital cleanup
2021.09.18 13:13:50 1: PERL WARNING: Use of uninitialized value in substitution (s///) at ./FHEM/10_CUL_HM.pm line 10715.
2021.09.18 13:13:50 3: Device Balkontuer added to ActionDetector with 028:00 time
2021.09.18 13:13:50 3: Device Bewegungsmelder_1 added to ActionDetector with 000:10 time
[...mehr ActionDetector]
2021.09.18 13:13:52 3: Device Thermostat_Wohnzimmer_SSW added to ActionDetector with 000:10 time
2021.09.18 13:13:55 1: CUL_HM finished initial cleanup
(10715 ist nicht die Zeile der offiziellen Version).
Dabei ist der Punkt aber der: bei HMinfo steht verbose auf 2, tatsächlich werden ganz viele getConfig-Befehle abgesetzt, die mAn. auch "doppelt und dreifach" sind. Evtl. besteht auch eine Verbindung zwischen dem und den "missing ack"-Geschichten von @Sailor und @the ratman dahingehend, dass die Sendequeue unnötig voll ist?
Da wir grade dabei sind: Mein CUL (steht unter VCCU-Kontrolle) taucht neuerdings auch mit "komischen" Meldungen im Log auf:
2021.09.18 13:55:52 3: CUL_HM set Virtueller_FK_SZ postEvent open
2021.09.18 13:55:52 3: CUL_0: Unknown code ? (remove:2E7A30 is unknown) Use one of A B b C e F G h i K k L l M m N R T t U u V W X x Y Z, help me!
Der virtuelle Fensterkontakt ist - wie der Name schon sagt - ein Kanal von einem virtuellen CUL_HM-Gerät, der wiederum gepeert ist mit dem fraglichen Thermostat (HM-CC-RT-DN), genauer: dem WindowRec-Kanal.
irgendwas haut mit dem regensensor nicht wirklich hin ...
die regenmeldung kommt nicht immer, wenn sie kommen sollte.
seit 2 stunden jetzt nieselts hier vor sich hin. die regenmeldung kam erst, nachdem ich ein "set getconfig" gemacht hab.
letzteres ist auch affenschnell abgearbeitet worden. keine warnigs oder fehler im log ...
schaut hier einfach so aus, als ob der kanal einfach selbsständig nix machen würde. aber auch erst nach einer gewissen zeit. wenn ichs ned besser wüßte, würd ich sagen, der geht schlafen und wacht nimma auf. als ich gestern nach dem zusammenbau noch mit nem glas wasser getestet hab, war der sofort mit regen da.
dies aber bitte mit vorsicht zu genießen. ich hab das ding schon wieder am dach angeschraubt, kanns also nur schwer spontan testen.
sniffe die raw messages vom sensor, dann siehst du, wann er was zu melden hat.
sind die event-...-attribute richtig gesetzt?
is bei mir alles auf standard
sniffen? womit und wie?
und das problem generell: wie krieg ich ohne regensensor mit, daß es regnet? nur weil der nix sendet, heißts ja nicht unbedingt, daß er nicht funktioniert.
wird mir wohl nix anderes übrig bleiben ... abbauen und unter "laborbedienungen" regnen lassen *g*.
sniffen: kennst du schon => "attr name_io logIDs name_sensor"
dann würde ich im eventmonitor alle events vom sensor "filtern" und zusätzlich die option fhem.log einschalten.
dann hat man alles zusammen im blick.
laborbedingungen sind natürlich optimal ;)
(oder mit wasserpistole/gartenschlauch beschiessen?)
leider nix mit gartenschlauch ... zu weit oben.
mal schauen, wann ich mich motivieren kann.
heute früh hat er wenigstens richtig "dry" gemeldet - das gibt mal hoffnung auf fehleinschätzungen meinerseits *g*
eh klar, daß es die nächsten tage nicht regnen soll hier. kann also dauern, bis ich mir sicher sein kann.
war wohl doch meine ungeduld.
nachbar hat mir seine pumpe geborgt - die kommt bis zum sensor. 3 mal probiert, 3 mal gefunzt.
ein bissi lahm ist der beim dry-melden, obwohl ich ihn von 5 min auf 30 sek. gedrückt hab - aber damit kann ich leben.
derzeit also mal entwarnung, bis mir neues mimimi für euch einfällt.
wie immer: thx für euer gehirnschmalz!
sodale ...
ich bin mir jetzt relativ sicher, dass der sensor physikalisch funktioniert.
bliebe nur noch mein problem mit dem state.
ich will nicht drüber streiten, ob da doif, homematic, die sonnenfleckenaktivität, oder sonst was schuld ist ... generell gibt's hier probleme, die mit einem eigenen reading ausgenommen werden könnten.
hier funzt alles, was mit doif und hm zu tun hat. sobald ich aber "addstateevent" mit rein nehmen muss, geht's nur mehr meistens.
manches mal kriegt das doif dann scheinbar nicht mit, dass sich was geändert hat. ist halt grad bei der regen erkennung, die meine rollos usw. fahren soll, extrem nervig.
die bitte also: eigene readings für den regensensor (wenigstens den regen-kanal). und wenn's andere sensoren gibt, die sich ähnlich verhalten, werden die entsprechenden leute sicher auch keine beschwerden haben, wenn's neue readings gibt.
Zitatsobald ich aber "addstateevent" mit rein nehmen muss, geht's nur mehr meistens.
hört sich an wie ein wackelkontakt, den es aber sicherlich nicht gibt. ;)
vermutlich passt dort deine "filterung" nicht richtig.
ein separates rain reading wäre schon hilfreich.
aber auch ohne muss und wird es eine
immer funktionierende lösung geben.
sagen wir's mal so: wenn/sobald es mal ein eigenes reading gibt, sind wir alle schlauer *g*
das ist grad auch der dümmste sensor zum rumprobieren hier.
ich hab jetzt übrigens ein schönes bspl. für das nicht richtige funzen von doif's im zusammenhang mit meinem regensensor.
ich hab ein doif, dass schreibt je nach zustand des hauses (z.b. tag/nacht) für meinen regenplot nicht nur rain/dry, sondern auch noch verschiedene zahlen. dazu wird die heizung dann auch gleich passend geschaltet.
so kann ich dann im plot unter anderem abbilden, wenn am tag die heizung des sensor rennt, in der nacht aber nicht.
bspl. (AUSZUG):(
[HM_70FEFD_Rain:"^state: rain$"]
and [$SELF:zustand] eq "an"
)
( set HM_70FEFD_Heating on-for-timer 300 )
( setreading $SELF regen_echt 255 )
DOELSEIF ## 02
(
[HM_70FEFD_Rain:"^state: rain$"]
and [$SELF:zustand] eq "aus"
)
( set HM_70FEFD_Heating off)
( setreading $SELF regen_echt 130 )
"addStateEvent" ist dabei natürlich ein.
ändert sich jetzt beim aufstehen der zustand von [$SELF:zustand] auf "an", passiert trotz passender werte im sensor mal gar nix ... das war früher (bevor dieses dämliche "ich-schreibe-alles-in-state-rein"-desaster begonnen hat) 100% funktionabel.
ich denke, du verknüpfst (and) einen zustand von $self mit einem event (rain/dry) vom sensor.
wenn sich ein zustand ändert, kann nie gleichzeitig ein anderes event auftreten. vermutlich triggert das doif erst, wenn das rain event kommt und gleichzeitig der zustand von $self passt.
solange du den unterschied von zustand und event nicht verstehst oder verstehen willst, werden deine doifs nur zufällig so funktionieren, wie du es erwartest.
dir fehlt also der fall, dass sich der zustand von $self auf an ändert während gleichzeitig der zustand des sensors auf rain steht.
hier kommt jetzt wahrscheinlich erschwerend hinzu, dass im state vom sensor channel nicht nur rain/dry auftauchen kann.
ich würde als erstes ein "funktionierendes" userreading im sensor anlegen, dass rain/dry aus dem state filtert.
deins kopiert ja nur den state.
vermutlich wärst du im doif bereich mit diesem problem besser dran.
da fällt mir ein, dass du auch wieder dein altes (ganz schlechtes) doif nutzen könntest, wenn du ein neues attribut nutzt.
https://forum.fhem.de/index.php/topic,120240.msg1169707.html#msg1169707 (https://forum.fhem.de/index.php/topic,120240.msg1169707.html#msg1169707)
weitere neue readings bringen aber wieder die gleichen probleme.
Zitatwenn sich ein zustand ändert, kann nie gleichzeitig ein anderes event auftreten. vermutlich triggert das doif erst, wenn das rain event kommt und gleichzeitig der zustand von $self passt.
der $self zustand ändert sich normal nur 1 mal am tag.
und wie gesagt: genau so hats immer schon gefunzt - nur seitdem state so gesprächig wurde ists auf einmal ein problem.
Zitatich würde als erstes ein "funktionierendes" userreading im sensor anlegen, dass rain/dry aus dem state filtert.
deins kopiert ja nur den state.
wie würde das aussehen? kann zwar generelles zeug anlegen (von mir selber abschreiben *g*), aber filtern ist nicht so meines - kannst mir das hier rein schreiben bittescheen?
wenn das kein zufall ist
https://forum.fhem.de/index.php/topic,123154.msg1176834.html#msg1176834 (https://forum.fhem.de/index.php/topic,123154.msg1176834.html#msg1176834)
das userreading muss ich erst testen.
userreading meinst jetzt direkt am sensor mit rain/dry?
weil dafür wäre ich dir sehr, sehr dankbar.
scheint mir irgendwie sympathischer als das im doif zu machen - egal, auf welche art dort ...
und wahrscheinlich kann ich das dann noch öfter brauchen.
eigentlich ganz einfach, wie beim notify
attr HM_70FEFD_Rain userReadings regen:(rain|dry) {ReadingsVal($name,"state","no_state")}
und am besten in jeder entity grundsätzlich "attr event-on-change-reading .*"
ich danke dir!
ja, drum verwend ich normal auch lieber doif und noch nie ein notify - weils kein perl braucht *g*