Hallo zusammen,
ich versuche zwei Thermostate anzulernen. Beide haben FW 1.5. Vorgehen nach Wiki und nach dem Hinweis beim ELV-Forum: https://de.elv.com/forum/neue-firmware-1.5-an-fhem-uart-modul-hm-mod-rpi-pcb-mit-firmware-1.4.1-7481
Bei einem hat er kurz ein richtiges Pairing angegeben --> PairedTo 0xACDBAD
Nun steht bei beiden Geräten --> PairedTo 0x000000
Das IODev ist korrekt, CMDs_pending läuft die ganze Zeit, aber es wird nichts abgearbeitet.
Habe mehrfach Batterien rausgenommen, erneut gepairt, getconfig, burstxmit, keine Besserung... Hat jemand eine Idee?
hmInfo:
configCheck done:
missing register list
WZF_Heizung: RegL_00.
WZF_Heizung_Clima: RegL_01.,RegL_07.
WZF_Heizung_ClimaTeam: RegL_01.
WZF_Heizung_Climate: RegL_01.
WZF_Heizung_Weather: RegL_01.
WZF_Heizung_WindowRec: RegL_01.
WZF_Heizung_remote: RegL_01.
WZT_Heizung: RegL_00.
WZT_Heizung_Clima: RegL_01.
WZT_Heizung_Climate: RegL_01.
WZT_Heizung_Weather: RegL_01.
WZT_Heizung_WindowRec: RegL_01.
Register changes pending
WZF_Heizung:
trigger sent to unpeered device
KB_Fenster: 000000
KB_Fenster: ACDBAD
trigger sent to undefined device
KB_Fenster: 000000
KB_Fenster: ACDBAD
PairedTo mismatch to IODev
WZF_Heizung: paired:set_0x000000 IO attr: ACDBAD.
templist mismatch
KB_Heizung_Clima: KB_Heizung_Clima not found in file ./tempList.cfg
WZF_Heizung_Clima: WZF_Heizung_Clima not found in file ./tempList.cfg
WZT_Heizung_Clima: WZT_Heizung_Clima not found in file ./tempList.cfg
Es geht um WZT_Heizung und WZF_Heizung...
Das 000000 taucht beim HmInfo auch auf.. Was kann das sein?
Zitat von: fhemjan am 25 Oktober 2022, 12:36:12
Das 000000 taucht beim HmInfo auch auf.. Was kann das sein?
das ist die broadcast adresse, also werkszustand.
vermutlich hast du set reset ausgeführt.
edit: drüber pairen, nichts löschen.
Es ist doch immer wieder magisch..
Habe alles noch ein paar Mal gemacht und nun funktioniert es.
Jetzt wiederum ähnliche Problematik beim Fensterkontakt. Ggf. mache ich einen Thread auf...
Besten Dank erst einmal!
Ich habe dasselbe Problem, wie beschrieben und bekomme es nicht hin, den Fensterkontakt mit meiner VCCU zu pairen. Was muss ich genau tun? Ich habe bereits zwei andere Fensterkontakte in Betrieb und die sind richtig gepaired. Nur der neue Kontakt will nicht.
Was kann ich tun?
Zitat von: gent am 27 Oktober 2022, 23:53:27
Was kann ich tun?
Hey.
Mal ein List des fehlerhaften Fensterkontakes anzeigen.
Internals:
CFGFN
CUL_1_MSGCNT 13
CUL_1_RAWMSG A0C3886414C12800000000109C8::-35.5:CUL_1
CUL_1_RSSI -35.5
CUL_1_TIME 2022-10-28 00:03:10
DEF 4C1280
FUUID 635afba3-f33f-8879-cb56-f7eedc70cb64a88b
IODev CUL_1
LASTInputDev CUL_1
MSGCNT 13
NAME HM_4C1280
NR 698
NTFY_ORDER 48-HM_4C1280
STATE open
TYPE CUL_HM
chanNo 01
disableNotifyFn 1
eventCount 39
lastMsg No:38 - t:41 s:4C1280 d:000000 0109C8
protCmdDel 15
protCmdPend 3 CMDs_pending
protLastRcv 2022-10-28 00:03:10
protRcv 14 last_at:2022-10-28 00:03:10
protResnd 4 last_at:2022-10-27 23:56:20
protResndFail 1 last_at:2022-10-27 23:57:10
protSnd 8 last_at:2022-10-27 23:57:07
protState CMDs_pending
rssi_at_CUL_1 cnt:14 min:-44.5 max:-21.5 avg:-33.92 lst:-35.5
READINGS:
2022-10-27 23:57:34 D-firmware 1.0
2022-10-27 23:57:34 D-serialNr NEQ0633086
2022-10-27 23:57:05 IODev CUL_1
2022-10-27 23:54:15 aesKeyNbr 00
2022-10-28 00:03:10 battery ok
2022-10-28 00:04:23 cfgState updating
2022-10-28 00:04:23 commState CMDs_pending
2022-10-28 00:03:10 contact open (to broadcast)
2022-10-28 00:03:10 state open
2022-10-28 00:03:10 trigDst_broadcast noConfig
2022-10-28 00:03:10 trigger_cnt 9
cmdStack:
++A0017533474C128000040000000000
##A0017533474C128001040000000001
##A0017533474C12800103
helper:
HM_CMDNR 56
PONtest 1
cSnd 017533474C1280000802010A750B330C47,017533474C1280000802010A750B330C47
cfgStateUpdt 0
getCfgList all
getCfgListNo ,4
lastMsgTm 1666908190.97841
mId 00C7
peerFriend peerAct,peerVirt
peerOpt 4:threeStateSensor
regLst 0,1,4p
rxType 28
supp_Pair_Rep 0
cfgChk:
idPz00 fail
idRc01 RegL_00.,RegL_01.
idRc03 fail
cmds:
TmplKey :no:1666907048.94279
TmplTs 1666907048.94279
cmdKey 1:1:0::HM_4C1280:00C7:01:
cmdLst:
assignHmKey noArg
clear [({msgErrors}|msgEvents|rssi|attack|trigger|register|oldRegs|readings|all)]
deviceRename -newName-
fwUpdate -filename- [-bootTime-]
getConfig noArg
getDevInfo noArg
getRegRaw (List0|List1|List2|List3|List4|List5|List6|List7) [-peerChn-]
peerBulk -peer1,peer2,...- [({set}|unset)]
peerChan -btnNumber- -actChn- [({single})] [({set}|unset)] [actor|remote|both]
peerSmart -peerOpt-
raw -data- [...]
regBulk -list-.-peerChn- -addr1:data1- [-addr2:data2-]...
regSet [(prep|{exec})] -regName- -value- [-peerChn-]
reset noArg
sign [(on|{off})]
tplDel -tplDel-
tplSet_0 -tplChan-
trgEventL -peer- -condition-
trgEventS -peer- -condition-
trgPressL [(-peer-|{all})]
trgPressS [(-peer-|{all})]
unpair noArg
lst:
condition closed,open,tilted
peer
peerOpt AZ.Heizung_WindowRec,AZ.Heizung_remote,BD.Heizung_WindowRec,BD.Heizung_remote,BD.Thermostat_WindowRec,BD.Thermostat_remote,EG.Heizung_WindowRec,EG.Heizung_remote,EG.Thermostat_WindowRec,EG.Thermostat_remote,EZ1.Heizung_WindowRec,EZ1.Heizung_remote,EZ2.Heizung_WindowRec,EZ2.Heizung_remote,LA1.Heizung_WindowRec,LA1.Heizung_remote,LA2.Heizung_WindowRec,LA2.Heizung_remote,LU.Heizung_WindowRec,LU.Heizung_remote,SZ.Heizung_WindowRec,SZ.Heizung_remote,VCCU_Btn1,WZ.Heizung_WindowRec,WZ.Heizung_remote
tplChan
tplDel
tplPeer
rtrvLst:
cmdList [({short}|long)]
deviceInfo [({short}|long)]
list [({normal}|full)]
param -param-
reg -addr- -list- [-peerChn-]
regList noArg
regTable noArg
regVal -addr- -list- [-peerChn-]
saveConfig [-filename-]
tplInfo noArg
expert:
def 0
det 0
raw 1
tpl 0
io:
flgs 2
newChn +4C1280,02,00,00
nextSend 1666908191.07749
rxt 2
sendWu 1
vccu VCCU
p:
4C1280
00
00
00
prefIO:
mRssi:
mNo 38
io:
CUL_1:
-27.5
-27.5
peerIDsH:
prt:
bErr 0
sProc 2
q:
qReqConf
qReqStat
role:
chn 1
dev 1
rssi:
at_CUL_1:
avg -33.9285714285714
cnt 14
lst -35.5
max -21.5
min -44.5
shadowReg:
RegL_00. 02:01 0A:75 0B:33 0C:47
tmpl:
Attributes:
DbLogExclude .*
IOgrp VCCU:CUL_1
autoReadReg 4_reqStatus
expert rawReg
firmware 1.0
model HM-SEC-SCO
room CUL_HM
serialNr NEQ0633086
subType threeStateSensor
Die Fenstersensoren können ziemlich zickig sein. Hast du den Config-Knopf am Sensor gedrückt? Was passiert dann?
Am besten ist es, wenn man nichts anderes am Sensor macht (also kein Fenster auf/zu).
protCmdPend 3 CMDs_pending
Solange das noch steht, ist der Vorgang noch nicht abgeschlossen
Kannst du mal checken, ob das model bei der VCCU stimmt? (Und allgemein, ob die CUL_HM-Module auf dem neuesten Stand sind bzw. auf frank's Version!)
Hier mein ein List der VCUU. Da habe ich seit Jahren nichts mehr geändert. Und angeblich wird das modell auch automatisch gesetzt. FHEM ist relativ aktuell ich habe das letzte Update Ende September gemacht.
Internals:
CUL_1_MSGCNT 7
CUL_1_RAWMSG A0C0186414C12800000000101C8::-38.5:CUL_1
CUL_1_RSSI -38.5
CUL_1_TIME 2022-10-27 23:41:10
DEF 753347
FUUID 5c4375ed-f33f-8879-db3f-b288dc295512ee39
IODev CUL_1
LASTInputDev CUL_1
MSGCNT 7
NAME VCCU
NOTIFYDEV global
NR 79
NTFY_ORDER 48-VCCU
STATE CUL_1:ok
TYPE CUL_HM
assignedIOs CUL_1
channel_01 VCCU_Btn1
eventCount 10
READINGS:
2022-10-27 23:26:51 IODev CUL_1
2022-10-27 23:26:52 IOopen 1
2022-10-28 00:13:38 cfgState ok
2022-10-27 23:44:17 hmPair name:HM_4C1280 SN: model:HM-SEC-SCO
2022-10-27 23:26:52 state CUL_1:ok
2022-10-23 16:29:34 unknown_36EAD1 received
2022-09-30 15:36:50 unknown_446018 received
2022-10-27 23:41:10 unknown_4C1280 received
2022-10-26 12:41:43 unknown_534C79 received
2022-10-26 12:42:16 unknown_534CB2 received
helper:
HM_CMDNR 230
mId FFF0
peerFriend -
peerOpt -:virtual
regLst
rxType 1
ack:
cmds:
TmplKey :no:1666906012.36669
TmplTs 1666906012.36669
cmdKey 0:1:1::VCCU:FFF0:00:
cmdLst:
assignIO -IO- [({set}|unset)]
clear [(readings|rssi|msgEvents|attack|{msgErrors}|unknownDev)]
defIgnUnknown noArg
hmPairForSec [-sec-]
hmPairSerial -serial-
tplSet_0 -tplChan-
update noArg
virtual [(1..50;1|{1})]
lst:
condition slider,0,1,255
peer
peerOpt
tplChan
tplDel
tplPeer
rtrvLst:
cmdList [({short}|long)]
deviceInfo [({short}|long)]
list [({normal}|full)]
listDevice noArg
param -param-
expert:
def 1
det 0
raw 1
tpl 0
io:
vccu VCCU
ioList:
CUL_1
prefIO:
CUL_1
mRssi:
mNo
peerIDsH:
prt:
bErr 0
sProc 0
q:
qReqConf
qReqStat
role:
dev 1
vrt 1
tmpl:
Attributes:
DbLogExclude .*
IOList CUL_1
IOgrp VCCU:CUL_1
expert defReg,rawReg
icon time_automatic
model CCU-FHEM
room CUL_HM
subType virtual
webCmd virtual:update
Zitat von: darkness am 28 Oktober 2022, 08:14:21
Die Fenstersensoren können ziemlich zickig sein. Hast du den Config-Knopf am Sensor gedrückt? Was passiert dann?
Am besten ist es, wenn man nichts anderes am Sensor macht (also kein Fenster auf/zu).
protCmdPend 3 CMDs_pending
Solange das noch steht, ist der Vorgang noch nicht abgeschlossen
Das steht da jetzt immer noch...
Wenn ich den Knopf drücke blinkt er langsam orange und hört dann auf. Manchmal sehe ich am CUL, dass da beim Drücken des Knopfes auch Aktivität ist. Das entsprechende Device reagiert in FHEM auch auf open/close, aber ich kann den FK nicht mit anderen Geräten peeren.
Was genau müsste ich denn tun, um das Teil komplett in den Ausgangszustand zu versetzen und das Gerät auch wieder aus FHEM zu entfernen?
Für mich zum Verständnis: Dein CUL ist kein HM-Original, oder? In dem Fall wäre ich dann raus
Da gab es, glaube ich, Probleme mit AES usw. Aber das ist gefährliches Halbwissen. Und mit fehlt die wichtige Hälfte :)
ZitatAusgangszustand zu versetzen und das Gerät auch wieder aus FHEM zu entfernen
Bisher ist es nicht mit FHEM verbunden. Du kannst zwar die Nachrichten "mitlesen". Aber Peeren klappt eben nocht nicht, da der Sicherheitsschlüssel noch nicht im Gerät hinterlegt ist.
Bei einem Schalter würde dieser auch keine Befehle von FHEM annehmen.
Für Debian-Systeme: libcrypt-rijndael-perl ist instelliert?
Ich habe schon mehrere Fensterkontakte im Einsatz. Die funktionieren seit etlichen Jahren. Ich wollte nun einen weiteren installieren und der macht eben diese Zicken.
ist cul_hm aktuell?
1. rssi sehen mir zu gut aus => abstand eventuell vergrössern auf 2m
2. cmd stack löschen => set clear msgEvents
3 erneut drüber pairen nichts löschen
4. cmds nur über das "knöpfchen" abholen, nicht über open/close
vorgang sniffen => cul verbose=5, global miliseclog=1
Zitat von: frank am 28 Oktober 2022, 17:21:48
ist cul_hm aktuell?
1. rssi sehen mir zu gut aus => abstand eventuell vergrössern auf 2m
2. cmd stack löschen => set clear msgEvents
3 erneut drüber pairen nichts löschen
4. cmds nur über das "knöpfchen" abholen, nicht über open/close
vorgang sniffen => cul verbose=5, global miliseclog=1
1. Liegt im Moment auf dem Schreibtisch neben dem FHEM-Server. Ist das echt ein Problem? Ich leg' ihn mal 5 m weiter weg
2. habe ich gerade mal gemacht
3. würde ich gerne aber er schafft noch and der getConfig. 3 cmd's pending und ich krieg das nicht weg
4. Mache ich bereits immer so.
Ich berichte
Das übliche timing-Thema? commStInChan (?) setzen. Und Eventhandler optimieren.
anbei mal mein log das FK-device ist 4C1280
Zitat von: Beta-User am 28 Oktober 2022, 18:33:58
Das übliche timing-Thema? commStInChan (?) setzen. Und Eventhandler optimieren.
Ich verstehe leider nur Bahnhof. Sorry, aber was soll ich tun?
2022.10.28 17:33:30.149 1: CUL_HM HM_4C1280 need Crypt::Rijndael to answer signing request with CUL
du solltest einfach öfter mal ins fhem.log schauen. ;)
also das perl modul installieren, damit dein cul aes kann.
Zitat von: gent am 28 Oktober 2022, 17:29:25
2. habe ich gerade mal gemacht
3. würde ich gerne aber er schafft noch and der getConfig. 3 cmd's pending und ich krieg das nicht weg
wenn du clear msgEvents vor dem pairing wirklich gemacht hättest, wären die pending cmds dadurch auch verschwunden.
ausserdem würde der befehl im log zu sehen sein.
trotzdem wurde das getconfig auch ungepairt und ohne aes beim ersten knöpfchen drücken problemlos verarbeitet.
beim nächsten drücken wurde das pairing versucht, was ohne das perl modul Crypt::Rijndael natürlich nicht funktioniert.
erneutes drücken geht dann natürlich auch nicht.
bei den wiederholungen macht cul_hm aber zusätzliche fehler, die mit folgender version beseitigt sein sollten: https://forum.fhem.de/index.php/topic,128599.msg1230045.html#msg1230045 (https://forum.fhem.de/index.php/topic,128599.msg1230045.html#msg1230045)
ZitatIch verstehe leider nur Bahnhof.
das attr commStInCh=off sollte man am besten grundsätzlich in jedem hauptdevice von homematic setzen.
ich freue mich auf ein erfolgreiches sniffen vom pairen.
Das mit Crypt::Rijndael finde ich merkwürdig. Das hatte ich definitv mal installiert, weil ich ja schon 2 Fensterkontakte erfolgreich gepaired habe (und die funktionieren). Kann es sein, dass - wenn einmal erfolgreich gepaired - das Modul nicht mehr notwendig ist für den Betrieb? Dann könnte ich mir nämlich erklären, dass ich, als ich meine FHEM Installation vor 3 Jahren auf einer M2 neu aufgesetzt habe, das Modul tatsächlich vergessen habe. Sonst wäre es einfach verschwunden und das könnte ich mir nicht erklären.
msgEvents habe ich genmacht aber das verbose und das mseclog erst danach eingeschaltet. Die Datei enthält auch erst alles, was danach kam.
Zitatbei den wiederholungen macht cul_hm aber zusätzliche fehler, die mit folgender version beseitigt sein sollten: https://forum.fhem.de/index.php/topic,128599.msg1230045.html#msg1230045
Ist das eine Version, die nicht mit dem normalen Update kommt? Meine Version ist bereits neuer als die Version vom 2.8.2022, die oben erwähnt wurde?
Ansonsten: Pairing hat jetzt funktioniert.
Vielen Dank für Deine Hilfe. Das mit dem fehlenden Perl-Modul habe ich nicht gesehen.
ZitatIst das eine Version, die nicht mit dem normalen Update kommt?
genau.
warum schaltest du aes nicht aus?
nur mit default key macht aes doch gar keinen sinn.
AES ist bei den anderen Kontakten auch an und ich hätte gerne alle Geräte vom gleichen Typ auch identisch konfiguriert.
Beim ganzen herumspielen mit AES / sign ein und aus habe ich aber jetzt bei hminfo configcheck
configCheck done:
Register changes pending
EG.Fenster:
Das bekomme ich auch nicht mehr weg.
Was ist denn da nun wieder los?
set clear trigger hat geholfen
Es ist echt eine Qual, wenn man Dinge, die man vor 4 Jahren zum letzten mal gemacht hat, plötzlich wieder braucht...
P.S.: Wie merkt ihr euch eigentlich Befehle, die ihr in fhem abgesetzt habt, so dass ihr das nachvollziehen könnt? Auf OS-Ebene kann man ja über ab und zu mal die history in ein Textfile sichern, aber in fhem?
ZitatAES ist bei den anderen Kontakten auch an und ich hätte gerne alle Geräte vom gleichen Typ auch identisch konfiguriert.
lässt sich ja überall ausschalten. ;)
sicher ist nur ein eigener key, da der default key jedem bekannt ist.
sinnloses aes mit default key erhöht nur unnötig den funkverkehr und damit die wahrscheinlichkeit eventueller kommunikationsprobleme.
Zitatset clear trigger hat geholfen
vermutlich nur zufall. im code kann ich das nicht erkennen.
clear readings könnte das, oder zb ein erfolgreiches getconfig, oder.... .
ZitatEs ist echt eine Qual, wenn man Dinge, die man vor 4 Jahren zum letzten mal gemacht hat, plötzlich wieder braucht...
könntest du zb im attr comment hinterlegen.
in fhem.log werden die cmds auch gespeichert.