Bei meinem LED-Dimmer funktioniert nach dem gestrigen HM-Update das langsame Auf- und Abdimmen nicht mehr.
Stattdessen werden die LEDs schlagartig ein bzw. ausgeschaltet, anders ausgedrückt: die Rampenzeiten werden nicht mehr berücksichtigt.
Mit der Vorversion (10_CUL_HM.pm 22503 2020-07-31 14:29:19Z martinp876 und HMConfig.pm, die ich davor gesichert habe) klappt es noch.
Ich vermute, dass es mit dem Homematic-Update zusammenhängt.
Kann ich durch obligatorisches Angeben der RampOn-/Off-Time dieses Verhalten erzwingen, oder wird dieser Fehler noch behoben?
Vielen Dank!
Gruß,
Friedhelm
---EDIT: (Device und Channel-List)
List des Devices:
Internals:
CFGFN ./FHEM/fhem_geraete.cfg
DEF 64824D
FUUID 5c444ff2-f33f-26cd-86fe-300d80d46b350df7
IODev myHmUART
LASTInputDev myHmUART
MSGCNT 17
NAME Licht_Treppe
NOTIFYDEV global
NR 71
STATE CMDs_done
TYPE CUL_HM
channel_01 Licht_Treppe_Dim
channel_02 Licht_Treppe_Dim_V_01
channel_03 Licht_Treppe_Dim_V_02
lastMsg No:BE - t:10 s:64824D d:FF3004 0100000000
myHmUART_MSGCNT 17
myHmUART_RAWMSG 0501003CBEA01064824DFF30040100000000
myHmUART_RSSI -60
myHmUART_TIME 2020-10-06 11:07:05
protLastRcv 2020-10-06 11:07:05
protRcv 17 last_at:2020-10-06 11:07:05
protSnd 27 last_at:2020-10-06 11:07:05
protState CMDs_done
rssi_at_myHmUART cnt:17 min:-61 max:-57 avg:-59.7 lst:-60
rssi_myHmUART cnt:3 min:-60 max:-59 avg:-59.66 lst:-60
READINGS:
2019-01-19 16:35:50 CommandAccepted yes
2019-01-19 16:35:49 D-firmware 2.9
2019-01-19 16:35:49 D-serialNr OEQ2081492
2020-10-06 11:07:01 PairedTo 0xFF3004
2019-01-19 16:35:54 R-pairCentral 0xFF3004
2020-10-06 11:07:01 RegL_00. 00:00 02:01 06:A1 0A:FF 0B:30 0C:04 15:FF 18:00 1E:01
2020-10-06 11:07:00 cfgState updating
2020-10-06 11:07:05 commState CMDs_done
2019-12-03 10:48:37 powerOn 2019-12-03 10:48:37
2020-10-06 11:07:05 state CMDs_done
helper:
HM_CMDNR 190
cSnd 01FF300464824D03040000000001,01FF300464824D0303
mId 0067
peerFriend
peerOpt -:dimmer
regLst 0
rxType 1
supp_Pair_Rep 0
cmds:
TmplKey :no:1601973489.13107
TmplTs 1601973489.13107
cmdKey :0:1:0::0067:01
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] ... [-PeerChannel-]
getSerial noArg
getVersion noArg
pair noArg
raw data ...
regBulk -list-.-peerChn- -addr1:data1- -addr2:data2- ...
regSet [prep|exec] -regName- -value- ... [-peerChannel-]
reset noArg
tplDel tmplt
tplSet_0 -tplChan-
unpair noArg
lst:
peer
peerOpt
tplChan
tplPeer
expert:
def 1
det 0
raw 1
tpl 0
io:
newChn +64824D,00,00,00
nextSend 1601975226.07844
rxt 0
vccu VCCU
p:
64824D
00
00
00
prefIO:
myHmUART
mRssi:
mNo BE
io:
myHmUART:
-56
-56
prt:
bErr 0
sProc 0
rspWait:
q:
qReqConf
qReqStat
regCollect:
role:
dev 1
prs 1
rpt:
IO myHmUART
flg A
ts 1601975225.78238
ack:
HASH(0x2ae70c8)
BE8002FF300464824D00
rssi:
at_myHmUART:
avg -59.7058823529412
cnt 17
lst -60
max -57
min -61
myHmUART:
avg -59.6666666666667
cnt 3
lst -60
max -59
min -60
shadowReg:
tmpl:
Attributes:
IODev myHmUART
IOgrp VCCU:myHmUART
alias Licht_Treppe
autoReadReg 5_readMissing
expert defReg,rawReg
firmware 2.9
model HM-LC-DIM1PWM-CV
serialNr OEQ2081492
subType dimmer
webCmd getConfig:clear msgEvents
List des Channels:
Internals:
CFGFN ./FHEM/fhem_geraete.cfg
DEF 64824D01
FUUID 5c444ff2-f33f-26cd-00d7-361e72f806f31c7a
NAME Licht_Treppe_Dim
NOTIFYDEV global
NR 73
NTFY_ORDER 50-Licht_Treppe_Dim
STATE 0%
TYPE CUL_HM
chanNo 01
device Licht_Treppe
READINGS:
2020-10-06 10:17:59 CommandAccepted yes
2019-01-19 16:35:55 R-characteristic square
2019-01-19 16:35:55 R-logicCombination or
2019-01-19 16:35:55 R-powerUpAction off
2019-01-19 16:35:55 R-sign off
2020-10-06 08:32:56 RegL_01. 00:00 08:00 30:06 32:50 34:4B 35:50 56:00 57:24 58:01 59:01
2020-10-06 08:33:26 cfgState ok
2020-10-06 10:18:04 deviceMsg off (to VCCU)
2020-10-06 10:18:04 dim stop:off
2020-10-06 10:18:04 level 0
2020-10-06 10:04:56 levelMissed desired:100
2020-10-06 10:18:04 overheat off
2020-10-06 10:18:04 overload off
2020-10-06 10:18:04 pct 0
2020-10-06 10:18:04 phyLevel 0
2020-10-06 10:18:04 recentStateType info
2020-10-06 10:18:04 reduced off
2020-10-06 10:18:04 state off
2020-10-06 10:18:04 timedOn off
2020-10-06 10:17:59 trigLast fhem:02
helper:
dlvlCmd ++A011FF300464824D0201000320FFFF
peerFriend peerSens,peerVirt
peerOpt 3:dimmer
regLst 1,3p
cmds:
TmplKey :no:1601972089.94491
TmplTs 1601972089.94491
cmdKey :1:0:0::0067:01
cmdLst:
clear [readings|trigger|register|oldRegs|rssi|msgEvents|msgErrors|attack|all]
down [-changeValue-] [-ontime-] [-ramptime-] ...
getConfig noArg
getRegRaw [List0|List1|List2|List3|List4|List5|List6] ... [-PeerChannel-]
inhibit [on|off]
off noArg
old noArg
on noArg
on-for-timer -ontime- [-ramptime-]...
on-till -time- [-ramptime-]...
pct [-value-|old] ... [-ontime-] [-ramptime-]
peerBulk -peer1,peer2,...- [set|unset]
peerIODev [IO] -btn- [set|unset]... not for future use
peerSmart -peerOpt-
press [long|short] -peer- [-repCount(long only)-] [-repDelay-] ...
regBulk -list-.-peerChn- -addr1:data1- -addr2:data2- ...
regSet [prep|exec] -regName- -value- ... [-peerChannel-]
sign [on|off]
statusRequest noArg
stop noArg
toggle noArg
tplDel tmplt
tplSet_0 -tplChan-
up [-changeValue-] [-ontime-] [-ramptime-] ...
lst:
peer
tplChan
tplPeer
dir:
cur stop
rct down
expert:
def 1
det 0
raw 1
tpl 0
role:
chn 1
tmpl:
vDim:
idPhy 64824D01
idV2 64824D02
idV3 64824D03
Attributes:
alias Licht_Treppe_Dim
eventMap eventMap on:100% off:0%
group Licht
model HM-LC-DIM1PWM-CV
peerIDs 00000000,
room Licht/Rolladen,Übersicht
webCmd pct:on:off
Ich habe das gleiche Problem, aber bei allen HM-Dimmern!
Leider hatte sich vor kurzem (zumindest bei mir, hatte lange kein Update mehr gemacht) auch das Verhalten mit weiteren Zeichen (%, ...) im set-Befehl geändert, weshalb ich erstmal die Zeit finden musste alle webCmds und eventMaps anzupassen. Das war sehr ärgerlich, da ich davon im Changelog nichts mitbekommen habe und zahlreiche automatisierte Dimmabläufe nicht mehr funktionierten. In fhemWeb gab es dann eine Fehlermeldung, aber im Log stand dazu leider nichts. Im HUE-System funktionieren %-Zeichen noch, also dürfte es nur eine Änderung in CUL_HM sein.
Aber zurück zum Dimmer Problem:
Wenn man den set-Befehl um eine eigene Ramp-Zeit ergänzt z.B. set HM-Dimmer 80 0 2 funktioniert das gemächliche Dimmen zwischen Werten ganz normal.
Im Logfile fällt dann auf, dass bei normalen Dimmvorgängen nicht mehr der Standart-Ramp-Wert angehängt wird, sondern nur 0 0:
2020.10.18 11:58:36.958 3: CUL_HM set HM-Dimmer pct 40 0 0
2020.10.18 11:58:43.369 3: CUL_HM set HM-Dimmer statusRequest noArg
2020.10.18 11:58:44.718 3: CUL_HM set HM-Dimmer pct 90 0 0
2020.10.18 11:58:51.062 3: CUL_HM set HM-Dimmer statusRequest noArg
2020.10.18 11:59:06.096 3: CUL_HM set HM-Dimmer pct 40 0 2
2020.10.18 12:08:04.971 3: CUL_HM set HM-Schalter on noArg
Da sich dieses Verhalten vor kurzem geändert hat und in der Commandref immer noch folgendes steht, gehe ich von einem Fehler aus.
Auszug Commandref:
0 - 100 [on-time] [ramp-time]
Setzt den Aktor auf den gegeben Wert (In Prozent) mit einer Auflösung von 0.5.
Bei Dimmern ist optional die Angabe von "on-time" und "ramp-time" möglich, beide in Sekunden mit 0.1s Abstufung.
"On-time" verhält sich analog dem "on-for-timer".
"Ramp-time" beträgt standardmäßig 2.5s, 0 bedeutet umgehend.
Es wäre schön, dem kann sich jemand annehmen, mit der Modulprogrammierung habe ich mich noch nie beschäftigt.
Außerdem ist das noArg-Anhängsel bei allen einfachen Schaltbefehlen und statusRequests neu. Ob das Sinn macht, sei dahingestellt.
Hmm so wie ich das sehe ist das Problem nach wie vor vorhanden?!
Bin nämlich grade auch über das gleiche Problem gestolpert. Ich wurde fast blind als ich per FHEM die neuen LEDs im Garten eingeschaltet habe und die sofort auf 100% waren ;-)