Hallo zap,
ich habe nach wie vor das Problem, dass die Einstellungen meines Regensensors nach Update und Neustart verändert werden - und zwar wie ich meine falsch.
Ein weiterer Neustart hat dagegen scheinbar nichts verändert. Es scheint nur in Verbindung mit Update zu passieren.
Ist aktuell so definiert:
defmod HM_Sen_RD_O_PEQ2220547 HMCCUDEV PEQ2220547
attr HM_Sen_RD_O_PEQ2220547 controldatapoint 2.STATE
attr HM_Sen_RD_O_PEQ2220547 devStateIcon dry:weather_sun rain:weather_rain
attr HM_Sen_RD_O_PEQ2220547 statedatapoint 1.STATE
attr HM_Sen_RD_O_PEQ2220547 webCmd control
attr HM_Sen_RD_O_PEQ2220547 widgetOverride control:iconSwitch,off,ios-on-blue,on,ios-off
Ich verliere hier immer wieder die Attribute controldatapoint, statedatapoint und auch devStateIcon und der Default macht für mich leider keinen Sinn.
Dort wird als statedatapoint dann immer 2.STATE verwendet. Das ist aber die Heizung und es ist eben primär ein Regensensor (was in 1.STATE steht), daher finde ich, dass das dann auch in state stehen sollte. Da man aber nur die Heizung ein- und ausschalten kann, ist das mein controldatapoint.
Wie ich mir die Anzeige aufgehübscht habe, ist jetzt mal zweitranging - aber "heimlich" überschrieben werden sollte das trotzdem nicht.
Diesmal hab ichs recht schnell gemerkt und fhem.cfg war noch korrekt, so dass ich es einfach korrigieren konnte.
Auf Channels wollte ich es jetzt nicht unbedingt aufteilen, da ich es in einem Device übersichtlicher finde und auch eine Menge Abhängigkeiten habe.
Gruß,
Jörg
Was für ein Devicetype ist das?
Hi zap,
meinst du "RAINDETECTOR_HEAT"?
Anbei einfach noch ein list.
Internals:
DEF PEQ2220547
FUUID 6308d79b-f33f-b127-cb91-14bc1c1de2adb9fe
IODev d_ccu
NAME HM_Sen_RD_O_PEQ2220547
NR 480
STATE off
TYPE HMCCUDEV
ccuaddr PEQ2220547
ccudevstate active
ccuif BidCos-RF
ccuname Aussen - HM-Sen-RD-O PEQ2220547
ccurolectrl RAINDETECTOR_HEAT
ccurolestate RAINDETECTOR_HEAT
ccusubtype HM-Sen-RD-O
ccutype HM-Sen-RD-O
eventCount 9
firmware 1.4
readonly no
Helper:
DBLOG:
1.STATE:
logdb:
TIME 1666644900.00644
VALUE dry
2.STATE:
logdb:
TIME 1666528938.78001
VALUE off
hmstate:
logdb:
TIME 1666622444.98954
VALUE off
READINGS:
2022-10-24 16:40:44 1.STATE dry
2022-10-23 14:42:18 2.INHIBIT unlocked
2022-10-23 14:42:18 2.STATE off
2022-10-23 14:42:18 2.WORKING false
2022-10-23 14:41:47 IODev d_ccu
2022-10-23 14:42:18 activity alive
2022-10-23 14:42:18 control off
2022-10-24 16:40:44 devstate ok
2022-10-24 16:40:44 hmstate off
2022-10-23 14:42:18 rssidevice -255
2022-10-23 14:42:18 rssipeer -255
2022-10-23 14:42:18 sign off
2022-10-23 14:42:18 state off
hmccu:
channels 3
detect 3
devspec PEQ2220547
forcedev 0
nodefaults 1
role 0:MAINTENANCE,1:RAINDETECTOR,2:RAINDETECTOR_HEAT
setDefaults 0
cmdlist:
get
set on-till off:noArg on:noArg on-for-timer toggle:noArg
control:
chn 2
dpt STATE
dp:
0.AES_KEY:
VALUES:
NVAL 0
ONVAL 0
OSVAL off
OVAL 0
SVAL off
VAL 0
0.CONFIG_PENDING:
VALUES:
NVAL false
ONVAL false
OSVAL false
OVAL false
SVAL false
VAL false
0.DEVICE_IN_BOOTLOADER:
VALUES:
NVAL false
ONVAL false
OSVAL false
OVAL false
SVAL false
VAL false
0.RSSI_DEVICE:
VALUES:
NVAL -255
ONVAL -255
OSVAL -255
OVAL 1
SVAL -255
VAL 1
0.RSSI_PEER:
VALUES:
NVAL -255
ONVAL -255
OSVAL -255
OVAL 1
SVAL -255
VAL 1
0.STICKY_UNREACH:
VALUES:
NVAL false
ONVAL false
OSVAL false
OVAL false
SVAL false
VAL false
0.UNREACH:
VALUES:
NVAL false
ONVAL false
OSVAL alive
OVAL false
SVAL alive
VAL false
0.UPDATE_PENDING:
VALUES:
NVAL false
ONVAL false
OSVAL false
OVAL false
SVAL false
VAL false
1.STATE:
VALUES:
NVAL 0
ONVAL 1
OSVAL rain
OVAL 1
SVAL dry
VAL 0
2.INHIBIT:
VALUES:
NVAL false
ONVAL false
OSVAL unlocked
OVAL false
SVAL unlocked
VAL false
2.STATE:
VALUES:
NVAL false
ONVAL false
OSVAL off
OVAL false
SVAL off
VAL false
2.WORKING:
VALUES:
NVAL false
ONVAL false
OSVAL false
OVAL false
SVAL false
VAL false
roleCmds:
get:
set:
off:
channel 2
role RAINDETECTOR_HEAT
subcount 1
syntax V:STATE:0
usage off
subcmd:
000:
args 0
dpt STATE
fnc
max 1
min 0
parname STATE
partype 3
ps VALUES
scn 000
unit
on:
channel 2
role RAINDETECTOR_HEAT
subcount 1
syntax V:STATE:1
usage on
subcmd:
000:
args 1
dpt STATE
fnc
max 1
min 0
parname STATE
partype 3
ps VALUES
scn 000
unit
on-for-timer:
channel 2
role RAINDETECTOR_HEAT
subcount 2
syntax V:ON_TIME:?duration V:STATE:1
usage on-for-timer duration
subcmd:
000:
args
dpt ON_TIME
fnc
max 85825945.600000
min 0.000000
parname duration
partype 2
ps VALUES
scn 000
unit s
001:
args 1
dpt STATE
fnc
max 1
min 0
parname STATE
partype 3
ps VALUES
scn 001
unit
on-till:
channel 2
role RAINDETECTOR_HEAT
subcount 2
syntax V:ON_TIME:?time V:STATE:1
usage on-till time
subcmd:
000:
args
dpt ON_TIME
fnc
max 85825945.600000
min 0.000000
parname time
partype 2
ps VALUES
scn 000
unit s
001:
args 1
dpt STATE
fnc
max 1
min 0
parname STATE
partype 3
ps VALUES
scn 001
unit
state:
chn 2
dpt STATE
Attributes:
alias Regensensor
devStateIcon dry:weather_sun rain:weather_rain
group Wetter
room Aussen
webCmd control
widgetOverride control:iconSwitch,off,ios-on-blue,on,ios-off
Verwendest Du delayedinit oder ccudelay bei der Definition vom I/O Device?
Ja, hab ccudelay=180
die CCU läuft in piVCCU und braucht eine Weile beim Reboot
Jörg
Ich kann es nicht reproduzieren. Auch mit ccudelay nicht. Ich setze die Attribute, speichere die Config, stoppe FHEM. Dann starte ich FHEM wieder und beide Attribute sind vorhanden, obwohl sie nicht auf die Default Datenpunkte verweisen.
Danke fürs schauen.
So richtig deterministisch ist das für mich auch nicht. Ich habe jetzt nur zum wiederholten Male festgestellt, dass die Werte vom Sensor so verstellt wurden, dass er mich mich unbrauchbar wurde.
Dann schau ich mal dass ich beim nächsten update entsprechend configs, logfiles, lists .... wegsichere.
Ob es jetzt es das Update war und/oder der Reboot - schwer zu sagen.
Melde mich wenn es erneut Auftritt und ich Daten habe.
Jörg
Es ist wieder passiert.
Die Attribute controldatapoint und statedatapoint sind einfach verschwunden.
FHEM wurde seitdem weder geupdated noch neu gestartet.
Bei einem kurzen Blick auf den Code sehe ich dass
SetDefaultAttributes()
möglicherweise die Attribute löschen könnte
push @removeAttr, 'statechannel', 'statedatapoint' if ($detect->{defSCh} != -1);
push @removeAttr, 'controlchannel', 'controldatapoint', 'statevals' if ($detect->{defCCh} != -1);
Aber das sollte doch "im laufenden Betrieb" gar nicht aufgerufen werden, oder?
Sonst werden die Attribute nur bei "CreateDevice" angefasst und das ist ja noch unwahrscheinlicher.
Sehr seltsam aber auch sehr lästig, bin schon versucht die Attribute automatisiert regelmässig zu setzen.
Edit: Habe jetzt nochmal in der logdb gewühlt und ich logge hmstate mit. Anscheinend habe ich es einfach länger nicht gemerkt und es gibt doch einen Zusammenhang mit FHEM Neustart:
2022.10.23 14:42:12.150 2: HMCCURPCPROC [d_rpc001065HmIP_RF] CB2010001025001065 NewDevice received 148 device and channel specifications
Und 6 Sekunden später habe ich den ersten "falschen" hmstate Eintrag in der LogDB.
Ich kann es aber mit einem erneute "shutdown restart" nicht reproduzieren. Da müssen irgendwie weitere Bedingungen zusammenspielen.
@Adimarantis Danke für den Hinweis. Könnte tatsächlich die Ursache sein.