Hallo Community,
ich habe mir das neue HM Gateway (HM-LGW-O-TW-W-EU) zugelegt. Aber das läuft alles andere als rund. Steckdosen melden MISSING ACK, Schalter setzen nicht alle Befehle ab und reagieren mit dauerhaftem blinken, TIMEOUT Fehler...
Ich überlege jetzt einfach ein gebrauchtes altes Gateway über das HMLAN Modul einzubinden. Kennt sich jemand mit dieser Problematik aus? Gibts noch einen andere Tipp außer neues "altes" Gateway?
Hallo,
also der vorzugsweise Weg wäre so:
- VCCU (https://wiki.fhem.de/wiki/Virtueller_Controller_VCCU)definieren
- altes HMLAN als IO der VCCU eintragen
- neues HMUARTLGW definieren
- als zweiten IO der VCCU eintragen
Läuft normalerweise rund wie eine Kugel.
Hast Du so versucht?
Gruß Otto
Hab's nur mit dem neuen Adapter probiert. Den alten gibt's ja nur noch gebraucht und deshalb hab ich mir ein neues bestellt. Eine VCCU habe ich noch nicht definiert. Das werde ich Mal versuchen. Da trage ich das Teil dann einfach als IO ein und verbinde die Schalter nochmal. Habe das bisher direkt mit dem Adapter verbunden.
Morgen nach der Arbeit wird das getestet. Danke für den Tipp!
Sorry dann hab ich Dich falsch verstanden. Ich dachte Du hattest das Alte und wolltest es gegen ein neues tauschen.
Hab ich schief gelesen.
Dann vergiss primär meinen ersten Post. Wobei eine VCCU prinzipiell gut ist.
Was hast Du für ein Problem? Bitte gib mal ein list vom HMUARTLGW und ein list von einem/dem betroffenen Gerät
https://forum.fhem.de/index.php/topic,71806.0.html
Gruß Otto
Hi Otto!
Bin die Woche über nicht zum programmieren gekommen. Werde heute mal ein bisschen weiter rumprobieren. Vllt. lösen sich ja dann Probleme von selber. Ich werde berichten.
Alsooo.... Die Steckdosen gingen jetzt alle ohne Probleme. Was ich dazu gemacht habe ist, mit dem Netfinder Tool von eq3 die Verschlüsselung von dem Gateway aktiviert (die war noch aus). Dann eine VCCU nach Wiki-Anbleitung angelegt und meine drei Steckdosen damit verbunden. Das ging dann auf Anhieb.
Allerdings verbindet FHEM beim ersten Versuch immer die Geräte mit dem LAN Gateway direkt, ohne dass ich dem Sage "PairForSeconds". Er macht es einfach so. Die erscheinen dann direkt als CUL_HM. Das ist doch nicht richtig. ich muss ja erstmal den Befehl fürs Pairen absetzen. Ich lösche die automatisch angelegten Geräte dann und dann sage der VCCU "PairForSeconds 10" und paire die schnell. Aber irgendwas scheint da noch nicht ganz richtig zu sein ??? Jemand ne Idee?
Moin,
das die Geräte in FHEM "erscheinen" ist nicht pairen. Wenn man einfach die "Config Nachricht" auslöst (Configtaster drücken) dann bekommt FHEM das mit und legt schon mal die Gerätedefinition an. Ein Reading PairedTo wird es aber noch nicht geben.
Auf keinen Fall muss man da etwas löschen und besonders schnell sein.
Gib doch mal bitte ein list von dem HMLANLGW, der VCCU und einem vermeintlich gepairtem Gerät.
Gruß Otto
Irgendwie scheint's jetzt zu funktionieren. Nur erscheinen trotzdem noch Geräte, wenn ich die Pairing Taste gedrückt habe, ohne "hmPairForSec" zu setzen. Hier die angefragten list-Outputs:
HM Lan Gateway:Internals:
AssignedPeerCnt 12
CNT 10
Clients :CUL_HM:
DEF 10.0.4.12
DEVCNT 10
DevState 99
DevType LGW
DeviceName 10.0.4.12:2000
FD 14
FUUID 5c5eb067-f33f-0bea-b0e9-8610b5eee196e674
LastOpen 1550401801.11856
NAME Hm.Gateway
NR 26
PARTIAL
RAWMSG 040208
RSSI -61
STATE opened
TYPE HMUARTLGW
XmitOpen 1
model eQ3-HM-LGW
msgLoadCurrent 4
msgLoadHistory 1/2/0/0/0/0/0/0/0/0/0/1
msgLoadHistoryAbs 4/3/1/1/1/1/1/1/1/1/1/1/0
owner EEFF0C
owner_CCU Hm.vccu
Helper:
CreditTimer 14069
FW 66561
Initialized 1
SendCnt 493
AckPending:
LastSendLen:
3
3
Log:
IDs:
PeerQueue:
PendingCMD:
RoundTrip:
Delay 0.00430202484130859
loadLvl:
lastHistory 1550612406.19254
MatchList:
1:CUL_HM ^A......................
Peers:
2CDD19 +2CDD19,00,00,00
3B16A2 +3B16A2,00,00,00
434A2B +434A2B,00,00,00
434A40 +434A40,00,00,00
434F27 +434F27,00,00,00
442288 +442288,00,00,00
45338D +45338D,00,00,00
4759A0 +4759A0,00,00,00
47BB84 +47BB84,00,00,00
564E17 +564E17,00,00,00
564F2A +564F2A,00,00,00
5BBB79 +5BBB79,00,00,00
READINGS:
2019-02-17 12:10:06 D-HMIdAssigned EEFF0C
2019-02-17 12:10:06 D-HMIdOriginal FFFFFF
2019-02-17 12:10:01 D-LANfirmware 1.1.5
2019-02-17 12:10:06 D-firmware 1.4.1
2019-02-17 12:10:01 D-serialNr PEQ0509906
2019-02-17 12:10:01 D-type eQ3-HM-LGW
2019-02-17 12:10:06 cond ok
2019-02-19 22:39:08 load 4
2019-02-17 12:10:06 loadLvl low
2019-02-17 12:10:01 state opened
helper:
keepAlive:
CNT 76
DEVCNT 75
DevState 99
DevType LGW-KeepAlive
DeviceName 10.0.4.12:2001
FD 16
LastOpen 1550401801.19719
NAME Hm.Gateway:keepAlive
NR 117
PARTIAL
STATE opened
TEMPORARY 1
TYPE HMUARTLGW
XmitOpen 0
Helper:
NextKeepAlive 1550612540.894
Log:
Resolve 1
IDs:
READINGS:
2019-02-17 12:10:01 state opened
Attributes:
DbLogExclude .*
alias Homematic LAN Gateway
devStateIcon opened:hm_ccu@blue .*:hm_ccu@red
group Bridges
hmId EEFF0C
icon hm_ccu
lgwPw MyHmLan
room _System
VCCU:Internals:
DEF EEFF0C
FUUID 5c6939b3-f33f-0bea-f2ed-4529273c43f10e2d
Hm.Gateway_MSGCNT 103
Hm.Gateway_RAWMSG 05000035018641434A2B0000000101C8
Hm.Gateway_RSSI -53
Hm.Gateway_TIME 2019-02-17 13:37:19
IODev Hm.Gateway
LASTInputDev Hm.Gateway
MSGCNT 103
NAME Hm.vccu
NOTIFYDEV global
NR 28
NTFY_ORDER 50-Hm.vccu
STATE Hm.Gateway:ok
TYPE CUL_HM
assignedIOs Hm.Gateway
channel_01 Hm.vccu.Wz.Hm.6erSchalter.1
channel_02 Hm.vccu.Wz.Hm.6erSchalter.2
channel_03 Hm.vccu.Wz.Hm.6erSchalter.3
channel_04 Hm.vccu.Wz.Hm.6erSchalter.4
channel_05 Hm.vccu.Wz.Hm.6erSchalter.5
channel_06 Hm.vccu.Wz.Hm.6erSchalter.6
channel_07 Hm.vccu.Bz.Hm.SchalterTuer.1
channel_08 Hm.vccu.Bz.Hm.SchalterTuer.2
channel_09 Hm.vccu.Sz.Hm.SchalterTuer.1
channel_0A Hm.vccu.Sz.Hm.SchalterTuer.2
channel_0B Hm.vccu.Sz.Hm.SchalterBett.1
channel_0C Hm.vccu.Sz.Hm.SchalterBett.2
READINGS:
2019-02-17 12:10:06 IOopen 1
2019-02-17 12:10:06 state Hm.Gateway:ok
2019-02-17 12:27:48 unknown_3B16A2 received
2019-02-17 13:37:19 unknown_434A2B received
2019-02-17 13:33:57 unknown_434A40 received
2019-02-17 13:17:48 unknown_434F27 received
2019-02-17 13:27:16 unknown_442288 received
2019-02-17 11:56:38 unknown_45338D received
2019-02-17 12:13:33 unknown_4759A0 received
2019-02-17 13:09:24 unknown_47BB84 received
2019-02-17 11:50:28 unknown_564E17 received
2019-02-17 12:53:24 unknown_5BBB79 received
helper:
HM_CMDNR 49
mId FFF0
regLst ,0
rxType 1
ack:
expert:
def 1
det 0
raw 1
tpl 0
io:
prefIO
vccu
ioList:
Hm.Gateway
mRssi:
mNo
prt:
bErr 0
sProc 0
rspWait:
q:
qReqConf
qReqStat
role:
dev 1
vrt 1
tmpl:
Attributes:
DbLogExclude .*
IODev Hm.Gateway
IOList Hm.Gateway
alias Homematic VCCU
expert 2_raw
group Bridges (virtuell)
icon hm_ccu@black
model CCU-FHEM
room _System
subType virtual
webCmd virtual:update
Beispielgerät (Zwischenstecker mit Lastmessung):Internals:
DEF 45338D
FUUID 5c693e14-f33f-0bea-50d2-13a57f7e56d7288e
Hm.Gateway_MSGCNT 1159
Hm.Gateway_RAWMSG 0500003D94845E45338D0000008013C20020C30190090B02
Hm.Gateway_RSSI -61
Hm.Gateway_TIME 2019-02-19 22:41:47
IODev Hm.Gateway
LASTInputDev Hm.Gateway
MSGCNT 1159
NAME St.Hm.PC
NOTIFYDEV global
NR 42
NTFY_ORDER 50-St.Hm.PC
STATE CMDs_done
TYPE CUL_HM
channel_01 St.Hm.PC.Schalter
channel_02 St.Hm.PC.Messung
channel_03 St.Hm.PC.LogikLeistung
channel_04 St.Hm.PC.LogikStrom
channel_05 St.Hm.PC.LogikSpannung
channel_06 St.Hm.PC.LogikFrequenz
lastMsg No:94 - t:5E s:45338D d:000000 8013C20020C30190090B02
protCmdDel 3
protLastRcv 2019-02-19 22:41:47
protRcv 1158 last_at:2019-02-19 22:41:47
protResnd 6 last_at:2019-02-17 12:17:38
protResndFail 2 last_at:2019-02-17 12:17:46
protSnd 267 last_at:2019-02-19 22:29:12
protState CMDs_done
rssi_Hm.Gateway cnt:22 min:-43 max:-36 avg:-39.72 lst:-40
rssi_at_Hm.Gateway cnt:1159 min:-72 max:-40 avg:-56.46 lst:-61
READINGS:
2019-02-18 08:08:02 Activity alive
2019-02-17 11:57:28 CommandAccepted yes
2019-02-17 11:57:27 D-firmware 1.6
2019-02-17 11:57:27 D-serialNr NEQ0153697
2019-02-18 08:01:58 PairedTo 0xEEFF0C
2019-02-17 11:57:32 R-pairCentral 0xEEFF0C
2019-02-18 08:01:58 RegL_00. 00:00 02:01 0A:EE 0B:FF 0C:0C 18:00
2019-02-18 08:01:54 powerOn 2019-02-18 08:01:54
2019-02-19 22:29:12 state CMDs_done
helper:
HM_CMDNR 148
PONtest 1
cSnd 01EEFF0C45338D06040000000001,01EEFF0C45338D0603
mId 00AC
regLst ,0
rxType 1
supp_Pair_Rep 0
expert:
def 1
det 0
raw 1
tpl 0
io:
newChn +45338D,00,00,00
nextSend 1550612507.24589
rxt 0
vccu Hm.vccu
p:
45338D
00
00
00
prefIO:
Hm.Gateway
mRssi:
mNo 94
io:
Hm.Gateway:
-57
-57
prt:
bErr 0
sProc 0
rspWait:
q:
qReqConf
qReqStat
regCollect:
role:
dev 1
prs 1
rssi:
Hm.Gateway:
avg -39.7272727272727
cnt 22
lst -40
max -36
min -43
at_Hm.Gateway:
avg -56.46505608283
cnt 1159
lst -61
max -40
min -72
shadowReg:
tmpl:
Attributes:
DbLogExclude .*
IODev Hm.Gateway
IOgrp Hm.vccu:Hm.Gateway
actCycle 000:10
actStatus alive
autoReadReg 4_reqStatus
expert 2_raw
firmware 1.6
model HM-ES-PMSw1-Pl
room hidden
serialNr NEQ0153697
subType powerMeter
webCmd getConfig:clear msgEvents
Was ich vor einiger Zeit, als ich FHEM das erste Mal aufgesetzt habe, nicht hatte ist das Auftauchen der Geräte bei betätigen des Pairing-Knopfes am Gerät, bevor ich nicht in FHEM im Gateway bzw. jetzt der VCCU "hmPairForSec" gesetzt habe.
Wenn sich die Nachbarn jetzt auch Homematic zulegen sollten, ist mein FHEM ja voller Geräte, die ich gar nicht brauche und die mir nicht gehören. Das wäre ja irgendwie sinnlos.
Könnte ich dafür z.B. autocreate deaktivieren und nur dann aktivieren, wenn ich tatsächlich ein neues eigenes Gerät verbinde? Oder gibt es da eine elegantere Möglichkeit?
Was ich aber mittlerweile geschafft habe ist, dass HmInfo keine Config Fehler mehr anzeigt. Eine Zeit lang ist auch der Fehler
ZitatHm.Gateway: Unknown code A14E7845E45338D00000082F3A4000025004508F6FA::-50:Hm.Gateway, help me!
im Log aufgetaucht. Dieser ist aber auch plötzlich weg. Zu meinem Verständnis: Kann mit dem Fehler jemand was anfangen und wieso ist er auf einmal weg?
Der letzte "Fehler" ist ein Hilferuf deines Gateways, weil er Telegramme empfängt die er nicht zuordnen kann. Die VCCU fängt diese ein, legt ein Reading (unknown_ ) und verhindert die Weitergabe zum Log.
Mit rssi -50 ist es aber mit Sicherheit ein Gerät in deinem direktem Umfeld.
Der Zwischenstecker ist ordentlich gepairt, das ist unter Garantie nicht von allein passiert.
Es wird nicht automatisch gepairt, aber Geräte werden angelegt wenn die Configtaste gedrückt wird. Ein gelöschtes aber schon gepairtes Gerät wird allerdings dabei auch vollständig angelegt, falls es keinen Werkreset erfahren hatte.
Die VCCU ist noch nicht vollständig angelegt, schau bitte noch mal ins Wiki und ergänze die Attribute.
Gruß Otto
Mensch Otto, du schläfst wohl nie :P . Danke für deine immer so schnelle und fachliche Hilfe. Ich habe die IOgrp noch gesetzt. Sonst fehlt eigentlich nix mehr, oder übersehe ich was?
Internals:
DEF EEFF0C
FUUID 5c6939b3-f33f-0bea-f2ed-4529273c43f10e2d
Hm.Gateway_MSGCNT 103
Hm.Gateway_RAWMSG 05000035018641434A2B0000000101C8
Hm.Gateway_RSSI -53
Hm.Gateway_TIME 2019-02-17 13:37:19
IODev Hm.Gateway
LASTInputDev Hm.Gateway
MSGCNT 103
NAME Hm.vccu
NOTIFYDEV global
NR 28
NTFY_ORDER 50-Hm.vccu
STATE Hm.Gateway:ok
TYPE CUL_HM
assignedIOs Hm.Gateway
channel_01 Hm.vccu.Wz.Hm.6erSchalter.1
channel_02 Hm.vccu.Wz.Hm.6erSchalter.2
channel_03 Hm.vccu.Wz.Hm.6erSchalter.3
channel_04 Hm.vccu.Wz.Hm.6erSchalter.4
channel_05 Hm.vccu.Wz.Hm.6erSchalter.5
channel_06 Hm.vccu.Wz.Hm.6erSchalter.6
channel_07 Hm.vccu.Bz.Hm.SchalterTuer.1
channel_08 Hm.vccu.Bz.Hm.SchalterTuer.2
channel_09 Hm.vccu.Sz.Hm.SchalterTuer.1
channel_0A Hm.vccu.Sz.Hm.SchalterTuer.2
channel_0B Hm.vccu.Sz.Hm.SchalterBett.1
channel_0C Hm.vccu.Sz.Hm.SchalterBett.2
READINGS:
2019-02-17 12:10:06 IOopen 1
2019-02-17 12:10:06 state Hm.Gateway:ok
2019-02-17 12:27:48 unknown_3B16A2 received
2019-02-17 13:37:19 unknown_434A2B received
2019-02-17 13:33:57 unknown_434A40 received
2019-02-17 13:17:48 unknown_434F27 received
2019-02-17 13:27:16 unknown_442288 received
2019-02-17 11:56:38 unknown_45338D received
2019-02-17 12:13:33 unknown_4759A0 received
2019-02-17 13:09:24 unknown_47BB84 received
2019-02-17 11:50:28 unknown_564E17 received
2019-02-17 12:53:24 unknown_5BBB79 received
helper:
HM_CMDNR 49
mId FFF0
regLst ,0
rxType 1
ack:
expert:
def 1
det 0
raw 1
tpl 0
io:
prefIO
vccu Hm.vccu
ioList:
Hm.Gateway
mRssi:
mNo
prt:
bErr 0
sProc 0
rspWait:
q:
qReqConf
qReqStat
role:
dev 1
vrt 1
tmpl:
Attributes:
DbLogExclude .*
IODev Hm.Gateway
IOList Hm.Gateway
IOgrp Hm.vccu
alias Homematic VCCU
expert 2_raw
group Bridges (virtuell)
icon hm_ccu@black
model CCU-FHEM
room _System
subType virtual
webCmd virtual:update
gut gemacht. Ich sehe jetzt ansonsten nix weiter. ;D
wenn hminfo keine Fehler mehr anzeigt sollte doch jetzt auch alles schick sein. Keine Missing Ack mehr? Alle Geräte lassen sich steuern?
Nope, keine Fehler mehr. Alles von Homematic ist verbunden und lässt sich schalten.
Nur ein vllt Bug oder Firmwareproblem gibt es noch. Einer der drei 2-fach Taster zeigt nur "cmds done" an. Er springt kurz auf den Status der zuletzt gedrückten Taste, aber dann zeigt er wieder cmds done an. Alle anderen machen das nicht. Peering hat aber auch mit allen drei funktioniert. Er quittiert den Tastendruck mit einer grünen LED. Werde das Mal die Tage in Ruhe checken und falls es da keine direkte Lösung gibt, bastel ich mir die Abfragen auf die einzelnen Kanäle des Schalters oder so... Mal sehen. Die zählen die Tastendrücke nämlich richtig.
Wenn es hilft, poste ich auch hier Mal ein List der drei Schalter, wenn ich morgen von der Arbeit komme.
ja mach das, an dem list sieht man ev. was falsch ist.
Beim Frühstück kann man doch auch ein bisschen programmieren.
Hier der List-Output von dem Schalter mit dem Problem:
Internals:
CFGFN
DEF 5BBB79
FUUID 5c694baa-f33f-0bea-be6b-1005eb92f364d78a
Hm.Gateway_MSGCNT 172
Hm.Gateway_RAWMSG 0501002B99A6405BBB79EEFF0C0117
Hm.Gateway_RSSI -43
Hm.Gateway_TIME 2019-02-17 13:01:43
IODev Hm.Gateway
LASTInputDev Hm.Gateway
MSGCNT 172
NAME Bz.Hm.SchalterTuer
NOTIFYDEV global
NR 811
STATE CMDs_done
TYPE CUL_HM
channel_01 Bz.Hm.SchalterTuer.1
channel_02 Bz.Hm.SchalterTuer.2
lastMsg No:99 - t:40 s:5BBB79 d:EEFF0C 0117
protLastRcv 2019-02-17 13:01:43
protRcv 172 last_at:2019-02-17 13:01:43
protSnd 88 last_at:2019-02-17 13:01:43
protState CMDs_done
rssi_at_Hm.Gateway cnt:172 min:-71 max:-43 avg:-59.25 lst:-43
READINGS:
2019-02-17 13:00:27 CommandAccepted yes
2019-02-17 13:00:26 D-firmware 1.4
2019-02-17 13:00:26 D-serialNr OEQ0903570
2019-02-17 12:55:52 PairedTo 0xEEFF0C
2019-02-17 12:55:52 R-pairCentral 0xEEFF0C
2019-02-17 12:55:52 RegL_00. 00:00 02:01 0A:EE 0B:FF 0C:0C
2019-02-17 13:01:43 battery ok
2019-02-17 13:01:43 state CMDs_done
helper:
HM_CMDNR 153
PONtest 1
cSnd 01EEFF0C5BBB790203,01EEFF0C5BBB790204EEFF0C0804
mId 00C2
regLst ,0,1,4p
rxType 28
supp_Pair_Rep 0
expert:
def 1
det 0
raw 1
tpl 0
io:
newCh 1
newChn +5BBB79,00,00,00
nextSend 1550404903.83793
prefIO
rxt 2
vccu
p:
5BBB79
00
00
00
mRssi:
mNo 99
io:
Hm.Gateway:
-35
-35
prt:
bErr 0
sProc 0
sleeping 0
try 1
rspWait:
q:
qReqConf
qReqStat
regCollect:
role:
dev 1
rpt:
IO Hm.Gateway
flg A
ts 1550404903.54398
ack:
HASH(0x32815d0)
998002EEFF0C5BBB7900
rssi:
at_Hm.Gateway:
avg -59.25
cnt 172
lst -43
max -43
min -71
shadowReg:
tmpl:
Attributes:
DbLogExclude .*
IODev Hm.Gateway
IOgrp Hm.vccu:Hm.Gateway
alias Tür
autoReadReg 4_reqStatus
expert 2_raw
firmware 1.4
group Schalter
icon taster
model HM-PB-2-WM55-2
room Badezimmer
serialNr OEQ0903570
subType pushButton
Und hier ein anderer Schalter, bei dem auch die Anzeige richtig funktioniert:
Internals:
CFGFN
DEF 47BB84
FUUID 5c694f27-f33f-0bea-5724-f22d255f9f0ed79c
Hm.Gateway_MSGCNT 104
Hm.Gateway_RAWMSG 0501004521A64047BB84EEFF0C0217
Hm.Gateway_RSSI -69
Hm.Gateway_TIME 2019-02-17 13:13:55
IODev Hm.Gateway
LASTInputDev Hm.Gateway
MSGCNT 104
NAME Sz.Hm.SchalterBett
NOTIFYDEV global
NR 1077
STATE Sz.Hm.SchalterBett.2 Short
TYPE CUL_HM
channel_01 Sz.Hm.SchalterBett.1
channel_02 Sz.Hm.SchalterBett.2
lastMsg No:21 - t:40 s:47BB84 d:EEFF0C 0217
protLastRcv 2019-02-17 13:13:55
protRcv 104 last_at:2019-02-17 13:13:55
protSnd 67 last_at:2019-02-17 13:13:55
protState CMDs_done
rssi_at_Hm.Gateway cnt:104 min:-72 max:-55 avg:-62.81 lst:-69
READINGS:
2019-02-17 13:13:24 CommandAccepted yes
2019-02-17 13:13:23 D-firmware 1.4
2019-02-17 13:13:23 D-serialNr NAA0002173
2019-02-17 13:10:37 PairedTo 0xEEFF0C
2019-02-17 13:10:37 R-pairCentral 0xEEFF0C
2019-02-17 13:10:37 RegL_00. 00:00 02:01 0A:EE 0B:FF 0C:0C
2019-02-17 13:13:55 battery ok
2019-02-17 13:13:55 state Sz.Hm.SchalterBett.2 Short
helper:
HM_CMDNR 33
cSnd 01EEFF0C47BB840203,01EEFF0C47BB840204EEFF0C0C04
mId 006B
regLst ,0,1,4p
rxType 28
supp_Pair_Rep 0
expert:
def 1
det 0
raw 1
tpl 0
io:
newCh 1
newChn +47BB84,00,00,00
nextSend 1550405635.40887
prefIO
rxt 2
vccu
p:
47BB84
00
00
00
mRssi:
mNo 21
io:
Hm.Gateway:
-65
-65
prt:
bErr 0
sProc 0
sleeping 0
try 1
rspWait:
q:
qReqConf
qReqStat
regCollect:
role:
dev 1
rpt:
IO Hm.Gateway
flg A
ts 1550405635.11446
ack:
HASH(0x325bc58)
218002EEFF0C47BB8400
rssi:
at_Hm.Gateway:
avg -62.8173076923077
cnt 104
lst -69
max -55
min -72
shadowReg:
tmpl:
Attributes:
DbLogExclude .*
IODev Hm.Gateway
IOgrp Hm.vccu:Hm.Gateway
alias Bett
autoReadReg 4_reqStatus
expert 2_raw
firmware 1.4
group Schalter
icon taster
model HM-PB-2-WM55
room Schlafzimmer
serialNr NAA0002173
subType pushButton
Es handelt sich beides um die 2er Taster. Das state Reading springt einfach immer wieder auf "CMDs_done" zurück ???
Moin,
naja ob es wirklich ein Problem ist? Ich sehe erstmal keines. Wir reden ja jetzt von der state/STATE Anzeige im Hauptgerät
Ich habe auch einen Fernbedienung wo das Hauptdevice CMDs_done anzeigt. Hab ich mir noch nie Gedanken drüber gemacht.
Eigentlich ist ja der Channel wichtig, Du kannst ja mal schauen ob es in den Channels Unterschiede gibt.
Gruß Otto
Das ist eigentlich kein Fehler. Der Status des Gerätes (!) ist rein informativ, wichtig für die Verarbeitung sind die Stati der Tasterkanäle, genauer gesagt eigentlich nur deren Events. In jedem Fall ist die durch CMDs_done überschriebene Statusmeldung inhaltlich dort noch verfügbar.
CMDs_done kann auch das typische Ergebnis einer nach einem Tastendruck erfolgten Konfigurationsabfrage durch FHEM sein (lazyConfig - ist ein batteriebetriebenes Gerät einmal "wach", werden Konfigurationsnachrichten gleich anschließend ausgetauscht).
edit: Otto war (wieder einmal) schneller ;D
Was mich stutzig gemacht hat ist, dass zwei Schalter im Hauptgerät die zuletzt gedrückten Taste anzeigen und dieser eine nicht.
Arbeiten werde ich dann so oder so mit den Channels, die alle funktionieren. Dennoch ist das irgendwie seltsam.
Beim meinem einen 6er Taster zb wird auch die zuletzt gedrückte Taste angezeigt. Also irgendwie scheint der einen in der Software ne Macke zu haben.