Hallo Martin,
wie interpretiere ich diese Meldung im Logfile?
2017.03.28 17:25:18 3: CUL_HM fl_Lichtaktor repeat, level C8 instead of 00
Der Aktor ist ein HM-LC-Sw1-DR und ansonsten korrekt eingerichtet.
Internals:
CFGFN
DEF 40DE0D
IODev hmuart
LASTInputDev hmuart
MSGCNT 9
NAME fl_Lichtaktor
NOTIFYDEV global
NR 102
NTFY_ORDER 50-fl_Lichtaktor
STATE off
TYPE CUL_HM
hmuart_MSGCNT 9
hmuart_RAWMSG 0403005418800240DE0D34C3680101000057
hmuart_RSSI -84
hmuart_TIME 2017-03-28 17:25:20
lastMsg No:18 - t:02 s:40DE0D d:34C368 0101000057
protLastRcv 2017-03-28 17:25:20
protSnd 9 last_at:2017-03-28 17:25:19
protState CMDs_done
rssi_at_hmuart cnt:9 lst:-84 min:-84 avg:-81.66 max:-79
rssi_hmuart avg:-84.44 min:-87 lst:-87 cnt:9 max:-81
Helper:
Dblog:
Devicemsg:
Fhemdblog:
TIME 1490714720.05292
VALUE off (to hmvccu)
Level:
Fhemdblog:
TIME 1490714720.05292
VALUE 0
Levelmissed:
Fhemdblog:
TIME 1490714718.17128
VALUE desired:0
Pct:
Fhemdblog:
TIME 1490714720.05292
VALUE 0
State:
Fhemdblog:
TIME 1490714720.05292
VALUE off
Timedon:
Fhemdblog:
TIME 1490714720.05292
VALUE off
Readings:
2017-03-28 17:25:20 CommandAccepted yes
2017-02-19 19:58:13 D-firmware 2.8
2017-02-19 19:58:13 D-serialNr MEQ1563378
2017-03-21 11:43:51 PairedTo 0x34C368
2017-02-19 19:58:17 R-pairCentral 0x34C368
2017-02-19 19:58:18 R-powerUpAction off
2017-02-19 19:58:18 R-sign off
2017-03-21 11:43:51 RegL_00. 02:01 0A:34 0B:C3 0C:68 15:FF 18:00 00:00
2017-03-21 11:43:52 RegL_01. 08:00 30:06 57:24 56:00 93:11 94:3A 00:00
2017-03-28 17:25:20 deviceMsg off (to hmvccu)
2017-03-28 17:25:20 level 0
2017-03-28 17:25:18 levelMissed desired:0
2017-03-28 17:25:20 pct 0
2017-03-27 23:16:25 powerOn 2017-03-27 23:16:25
2017-03-28 17:25:20 recentStateType ack
2017-03-28 17:25:20 state off
2017-03-28 17:25:20 timedOn off
Helper:
HM_CMDNR 24
cSnd 1134C36840DE0D0201000000,1134C36840DE0D0201000000
mId 00F0
rxType 1
supp_Pair_Rep 0
Expert:
def 1
det 0
raw 1
tpl 0
Io:
newChn +40DE0D,00,00,00
nextSend 1490714720.13209
rxt 0
vccu hmvccu
p:
40DE0D
00
00
00
prefIO:
hmuart
Mrssi:
mNo 18
Io:
hmuart -82
Prt:
bErr 0
sProc 0
Rspwait:
Q:
qReqConf
qReqStat
Role:
chn 1
dev 1
prs 1
Rssi:
At_hmuart:
avg -81.6666666666667
cnt 9
lst -84
max -79
min -84
Hmuart:
avg -84.4444444444444
cnt 9
lst -87
max -81
min -87
Shadowreg:
Tmpl:
Attributes:
IODev hmuart
IOgrp hmvccu:hmuart
autoReadReg 0_off
expert 2_raw
firmware 2.8
model HM-LC-Sw1-DR
peerIDs 00000000,
room 18 Flur
serialNr MEQ1563378
subType switch
webCmd statusRequest:toggle:on:off
...eine Antwort hierzu würde mich auch interessieren.
Ich erhalte seit Kurzem diese Meldung bei einem HM-MOD-Re-8
VG,
al
Hallo,
Dimmer reagieren unter Umständen sensibel auf die Unterschreitung der Mindestlast. Habt ihr LED daran angeschlossen?
Umgangen werden kann dies durch entsprechendes Setzen eines Registers. Dazu mal in die Commandref schauen.
VG
Sedikit
Gesendet von iPad mit Tapatalk
Beide Aktoren sind Schalter, keine Dimmer.
Level C8 entspricht 200 und ist das Gegenstück zu 0. FHEM übersetzt das intern auf 100 (= on) und off.
Irgendwie wird ein unerwarteter Schaltzustand zurückgemeldet.
In betateilchens Auszug fällt auf, dass laut einem mit "levelMissed" bezeichneten Internal wohl der Aktor zurückmelden _sollte_, dass er einen Ausschaltbefehl bekommen hat (was man in FHEM sonst mit "set_off" im Status zu sehen bekommt. Anscheinend quittert der Aktor auch was, aber das zurückkommende entspricht nicht den Erwartungen. Nichtsdestotrotz folgt 2s später eine Vollzugsmeldung mit korrektem Wert.
Im Auszug liegen die rssi zudem bedenklich niedrig. Denkbar, dass es hier Verfälschungen und Ausfälle durch zu niedrigen Funkpegel gibt. Wäre aber außergewöhnlich aus meiner bescheidenen Kenntnis.
Nun wäre interessant wie das beim Re-8 aussieht
Gesendet von meinem SM-G900FD mit Tapatalk
auch hier sind die logs interessant.
Wenn ein Kommando kommt einen Level zu setzen (schalter haben bei eq3 die gleichen Level wie dimmer, aber nur 2 Stufen: 0 und 100%)prüft FHEM ob dieser in der Antwort auch erreicht ist. Ist das nicht der Fall kommt diese Meldung: Gewünschter Zustand entspricht nicht dem gemeldeten.
Da einige Devices "zicken" (eQ3 hat einige Varianten in der FW-Verarbeitung) kann ich mir schon vorstellen, dass die Überwachung getunt werden könnte. Dazu braucht es logs.