Hi,
ich habe sowohl zwei HM-Sen-MDIR-O-2 als auch einen HM-Sen-MDIR-WM55. Die HM-Sen-MDIR-O-2 haben ein Reading "battery", aber HM-Sen-MDIR-WM55 hat keins. Wenn ich mir die XML-Dateien zu beiden ansehe, dann haben beide das hier:
<parameter id="LOWBAT" ui_flags="service" operations="read,event">
<logical type="boolean"/>
<physical type="integer" interface="internal" value_id="LOWBAT"/>
</parameter>
Ich kann dazu keine Unterschiede feststellen.
Fehlt da bei der Implementierung des HM-Sen-MDIR-WM55 etwas?
Gruß,
Thorsten
Zitat von: Thorsten Pferdekaemper am 25 Mai 2016, 15:09:00
Fehlt da bei der Implementierung des HM-Sen-MDIR-WM55 etwas?
Nein. Meine 3 haben ein battery Reading (im Hauptdevice).
Hmm... Dann muss ich das wohl persönlich nehmen.
Hier ist ein List von dem Ding:
Internals:
CFGFN
DEF 4A17B1
HMLAN1_MSGCNT 184
HMLAN1_RAWMSG E4A17B1,0000,0231ABC1,FF,FFBC,DFA2414A17B123A3F403469D60
HMLAN1_RSSI -68
HMLAN1_TIME 2016-05-25 14:20:50
IODev HMLAN1
LASTInputDev HMLAN1
MSGCNT 184
NAME tr_BewegungUnten
NR 37462
STATE CMDs_done
TYPE CUL_HM
channel_01 tr_BewegungUnten_Btn01
channel_02 tr_BewegungUnten_Btn02
channel_03 tr_BewegungUnten_Motion
lastMsg No:DF - t:41 s:4A17B1 d:23A3F4 03469D60
protCmdDel 3
protLastRcv 2016-05-25 14:20:49
protNack 1 last_at:2016-05-24 22:08:50
protSnd 197 last_at:2016-05-25 14:20:50
protState CMDs_done
rssi_at_HMLAN1 avg:-69.13 min:-86 max:-45 lst:-68 cnt:184
Readings:
2016-05-24 22:19:49 CommandAccepted yes
2016-05-24 22:19:48 D-firmware 1.1
2016-05-24 22:19:48 D-serialNr MEQ1851536
2016-05-24 21:39:35 PairedTo 0x23A3F4
2016-05-24 21:39:35 R-pairCentral 0x23A3F4
2016-05-24 21:39:35 RegL_00. 02:01 0A:23 0B:A3 0C:F4 14:03 18:00 00:00
2016-05-25 14:20:50 state CMDs_done
Desired-temp:
Helper:
HM_CMDNR 223
cSnd 0123A3F44A17B103040000000001,0123A3F44A17B10303
mId 00DB
rxType 28
Expert:
def 1
det 1
raw 1
tpl 1
Io:
newCh 1
newChn +4A17B1,00,00,00
nextSend 1464178850.08231
prefIO
rxt 2
vccu
p:
4A17B1
00
00
00
Mrssi:
mNo DF
Io:
HMLAN1 -66
Prt:
bErr 0
sProc 0
sleeping 0
try 1
Rspwait:
Q:
qReqConf
qReqStat
Role:
dev 1
Rpt:
IO HMLAN1
flg A
ts 1464178849.99932
ack:
HASH(0x3e4d758)
DF800223A3F44A17B101019D00
HASH(0x3e4d758)
DF800223A3F44A17B100
Rssi:
At_hmlan1:
avg -69.1358695652174
cnt 184
lst -68
max -45
min -86
Shadowreg:
Tmpl:
Attributes:
IODev HMLAN1
autoReadReg 4_reqStatus
expert 251_anything
firmware 1.1
model HM-Sen-MDIR-WM55
room Treppenhaus
serialNr MEQ1851536
subType motionAndBtn
webCmd getConfig:clear msgEvents
Ansonsten funktioniert das Teil soweit. Da ist nirgends was mit battery. Was könnte da bei mir anders sein?
Gruß,
Thorsten
Ich nehme an, ein getConfig gefolgt von Druck auf Anlernknopf hast du schon gemacht? Firmware ist jedenfalls die gleiche, wie bei meinen.
Ich kann mich dunkel erinnern, dass es in den Untiefen des Forums einen Thread gibt, der das battery Reading behandelt. Ich glaube aber darin geht es in der Hauptsache um die Tatsache, dass es sich nicht aktualisert (bzw. nur wenn die Batterie leer ist).
Ahem, nein, das habe ich noch nicht gemacht. Allerdings hätte ich erwartet, dass das beim Pairing zumindest am Anfang einmal automatisch passiert. Ich probier's mal aus.
mal sehen was ich alles elesen habe:
GetConfig:
das kommando wird abgesetzt wenn autoReadReg gesetzt ist und das Device bereit ist. Nachdem es sich um ein lacyConfig device handelt werden kommandos gesendet wenn man anlernen drückt (wie beschrieben) oder wenn das device einen trigger sendet (also motion) UND der Kanal den trigger an die Zentrale sendet.
Das Device sendet an die Zentrale wenn NICHT gepeert ist ODER mit einem Kanal der Zentrale
Daher habe ich EINEN Kanal der VCCU (also virtuell) der mit ALLEN lacyConfig kanälen (zumindest einem im Device) gepeert ist.
=> wenn ich meinem MDIR-O ein Kommando schicke (regSet,... getConfig) muss ich einmal vor dem MDIR spazieren gehen -> es kommt ein trigger und die Kommandos können verarbeitet werden.
Analog geht das bei allen lacy-Config. Wenn es ein push-button ist muss man eben den button pushen.
Battery:
kommt beim MDIR mit den Zyklischen Statusmeldungen. Mit diesen werden auch die Brightness Werte gesendet. Kommen diese nicht gibt es auch keine Battery.
Dass Battery auch in der Statusmeldung kommt ist nicht gesichert, somit nicht eingebaut.
Zitat von: marvin78 am 25 Mai 2016, 15:21:04
Ich nehme an, ein getConfig gefolgt von Druck auf Anlernknopf hast du schon gemacht?
Das habe ich jetzt versucht, keine Änderung. "battery" erscheint immer noch nicht.
Zitat
Ich kann mich dunkel erinnern, dass es in den Untiefen des Forums einen Thread gibt, der das battery Reading behandelt. Ich glaube aber darin geht es in der Hauptsache um die Tatsache, dass es sich nicht aktualisert (bzw. nur wenn die Batterie leer ist).
Das scheint auch Martins Ansatz zu sein. Sendet das Teil bei Dir regelmäßige Events?
Zitat von: martinp876 am 26 Mai 2016, 10:16:42
mal sehen was ich alles elesen habe:
GetConfig:
...
Get config funktioniert bei mir wie erwartet. Wenn ich das Kommando absetze und mich danach mal kurz vor dem Sensor sehen lasse, dann wird alles verarbeitet. ...allerdings immer noch kein "battery".
ZitatBattery:
kommt beim MDIR mit den Zyklischen Statusmeldungen. Mit diesen werden auch die Brightness Werte gesendet. Kommen diese nicht gibt es auch keine Battery.
Aha. Zu den zyklischen Statusmeldungen gibt es ja schon ein paar Sachen. Allerdings werde ich da nicht so ganz schlau draus. Einerseits wird da von "regSet cyclicInfoMsg on" geschrieben, aber auch von "captInInterval". Was sollte man da am ehesten verwenden? ...bzw: Was ist der Unterschied?
Gruß,
Thorsten
capture in Interval hat doch nichts mit zyklischen Messages zu tun. Schon einmal übersetzt?
"fange auch im Interval". Fangen kann man sicher nur Trigger. Das interval kann also nur das Capture-interval sein.
Du stellst ein, dass ein Trigger alle x (z.B. 240s) wiederholt wird. Also 240s = Interval Wenn sich nun einer während der 240s bewegt wird dies als trigger gesehen und nach 240S gesendet.
Mit einem Zyklischen Senden von Brightness hat es offensichtlich garnichts zu tun.
Hi,
dann habe ich mich vom Konjunktiv im fhemwiki verwirren lassen.
Ich werde mal das mit cyclicInfoMsg ausprobieren.
Danke&Gruß,
Thorsten
ZitatAha. Zu den zyklischen Statusmeldungen gibt es ja schon ein paar Sachen. Allerdings werde ich da nicht so ganz schlau draus. Einerseits wird da von "regSet cyclicInfoMsg on" geschrieben, aber auch von "captInInterval". Was sollte man da am ehesten verwenden?
Guggst du hier - musste ich auch erst ausprobieren.
https://forum.fhem.de/index.php/topic,35704.msg454458.html#msg454458 (https://forum.fhem.de/index.php/topic,35704.msg454458.html#msg454458)
captInInterval habe ich nur im Channel gefunden
cyclicInfoMsg habe ich nur im Device gefunden.
Im Device habe ich aber ein Reading battery das bei meinem Versuchs-mdir-wm55 mit cyclicInfoMsg on regelmässig aktualisiert wird - klar, ein Reading battery macht im Channel auch nicht viel Sinn.
Theoretisch könnte man die beiden Threads auch zusammenführen.
Hallo,
habe beim durchstöbern diesen alten Thread gefunden.
Da ich genau das gleiche Problem habe, wollte ich erstmal hier fragen, bevor ich einen neuen Thread öffne.
Gab es eine Lösung für das Problem?
Wäre natürlich super, nicht immer auf verdacht die Batterien tauschen zu müssen ;D
Gruß
Felix
Hallo zusammen,
Auch ich bin auf diesen alten thread gestoßen, da mir gerade dasselbe Problem aufgefallen ist - kein battery-Reading:
Internals:
DEF 4A1D21
IODev hmusb
LASTInputDev hmusb
MSGCNT 505
NAME motion_portal
NOTIFYDEV global
NR 911
STATE CMDs_done
TYPE CUL_HM
channel_01 motion_portal_Btn_01
channel_02 motion_portal_Btn_02
channel_03 motion_portal_Motion
hmusb_MSGCNT 505
hmusb_RAWMSG E4A1D21,0000,BCE88E47,FF,FFC0,5EA2414A1D2142424203A65C76
hmusb_RSSI -64
hmusb_TIME 2017-12-03 09:41:04
lastMsg No:5E - t:41 s:4A1D21 d:424242 03A65C76
protLastRcv 2017-12-03 09:41:04
protSnd 975 last_at:2017-12-03 09:41:04
protState CMDs_done
rssi_at_hmusb min:-71 avg:-63.44 lst:-64 max:-61 cnt:505
READINGS:
2016-09-13 01:01:15 CommandAccepted yes
2016-06-15 22:13:39 D-firmware 1.1
2016-06-15 22:13:39 D-serialNr MEQ1848739
2017-12-02 20:15:06 PairedTo 0x424242
2016-06-15 22:18:51 R-pairCentral 0x424242
2017-12-02 20:15:06 RegL_00. 02:01 0A:42 0B:42 0C:42 14:03 18:00 00:00
2017-11-28 13:41:13 motion off
2017-12-03 09:41:04 state CMDs_done
helper:
HM_CMDNR 94
cSnd 014242424A1D2103040000000001,014242424A1D210303
mId 00DB
rxType 28
supp_Pair_Rep 0
expert:
def 1
det 0
raw 1
tpl 0
io:
newCh 1
newChn +4A1D21,00,01,00
nextSend 1512290464.79948
prefIO
rxt 2
vccu
p:
4A1D21
00
01
00
mRssi:
mNo 5E
io:
hmusb -62
prt:
bErr 0
sProc 0
sleeping 0
rspWait:
q:
qReqConf
qReqStat
role:
dev 1
rpt:
IO hmusb
flg A
ts 1512290464.72706
ack:
HASH(0x1d5fe68)
5E80024242424A1D2101015C00
HASH(0x1d5fe68)
5E80024242424A1D2100
rssi:
at_hmusb:
avg -63.4435643564357
cnt 505
lst -64
max -61
min -71
shadowReg:
tmpl:
Attributes:
IODev hmusb
autoReadReg 4_reqStatus
expert 2_raw
firmware 1.1
model HM-Sen-MDIR-WM55
room CUL_HM,portal
serialNr MEQ1848739
subType motionAndBtn
webCmd getConfig:clear msgEvents
Dem von Puschel w.u. verlinkten Thread konnte ich keine Lösung entnehmen bzw. ich habe nicht verstanden, was genau ich tun könnte.
Habt Ihr das denn behoben bekommen?
Grüße
Martin
Problem hat sich bei mir durch Firmware-Update auf 1.20 gelöst, jetzt ist das Reading da.