Hallo,
mein Problem mit dem Werksreset sind gelöst. Meine beiden Keymatic's funktionieren wieder wie gewohnt. Ein pairing mit FHEM werde ich wahrscheinlich nicht mehr anstreben.
Eine RaspberryMatic wird da wohl als Basis dienen oder ich lasse es nur über Handsender laufen.
Die Lösung brachte in meinem Fall der sehr hilfsbereite technische ELV-Support für eq3-Produkte. Danke nochmal.
Der Herr am Telefon erklärt mir, dass der Werksreset bei mir (verriegeln nach rechts drehen) mit 2 Sek. set-up Taste gefolgt von 10 x "verriegeln" (rechts) gefolgt von 10 x "entriegeln"(links) durchgeführt werden muss.
(Anleitung sagt für mich 2 x 10 x "verriegeln")
Egal, Problem gelöst, ich wieder glücklich und entspannt.
Gruß und vielen Dank für eure Unterstützung!
Nabend,
ich habe ein komisches Phänomen mit der Keymatic und der 4-TastenFernbedienung und brauche bitte eure Weisheit.
Aufbau
rPi3
- FHEM 5.8 (fhem.pl:14348/2017-05-22)
- CUL V3 von Busware mit FW V1.66 CUL868
Keymatic:
- gepaired mit VCCU
- erfolgreich gepeered mit der HM-RC-Key4-2 4-FB (je Taste: lock, unlock, open)
Problem
Mit der Fernbedienung kann ich lock und unlock Kommandos an die Keymatic senden. Open wird als lock oder unlock gesendet (toggle; also je nach KeyMatic-Zustand)
Nur der webcmd kann auch open senden! Was bei meiner Haustür leider das A und O ist, weil draußen keine Klinke.
Ich will aber unbedingt unabhängig von FHEM an der Stelle sein, weil ich nicht immer mein Handy vor der Tür zücken möchte.
Ich habe folgenden unbeantworteten Beitrag zu dem gleichen Finding gefunden:
https://forum.fhem.de/index.php/topic,46769.msg385068.html#msg385068
Meine "short Jump to" (shKeyJtOff und shKeyJtOn) register habe ich aus folgendem Beitrag von Peete (danke):
https://forum.fhem.de/index.php/topic,22467.msg167453.html#msg167453
Also
set <KeyMatic> regSet shKeyJtOff open FB_Key_open
set <KeyMatic> regSet shKeyJtOn open FB_Key_open
@Peete: geht wirklich nur mit peerNeedsBurst sonst nimmt die KeyMatic das TastenKommando der Fernbedienung nicht an. Beim Anlegen der peers waren komischerweise nur lock und unlock richtig auf peerNeedsBurst=on (der open peer war peerNeedsBurst war off und hat daher nichts bewirkt,erst als ich manuell auf on gesetzt habe, wurde der Tastendruck von der FB an der KeyMatic angenommen)
Jemand ne Ahnung was ich falsch gemacht habe?
Hat die RC die Befehle akzeptiert? (also CMD_DONE)
Hast du noch mal die RegTabel nach dem schrieben ausgelesen?
War bei den RC nicht irgendwas, dass man die Taste an der RC drücken muss, damit die Befehle angenommen werden?
Gruß Robert
Hallo Robert,
danke dir für deine Antwort. Die RC arbeitet meiner Meinung sauber und CMDs_done ist im Status.
Ich habe ausserdem verstanden, dass die RC "dumm" ist. Es ist also die KeyMatic, die den Tastendruck annimmt und schaltet so wie man ihr gesagt hat. (set <KeyMatic> regSet shKeyJtOff open FB_Key_open)
Macht sie nur leider nicht.
Noch jemand eine Idee bzw. etwas was ich auslesen könnte?
Hi,
mir kam beim Lesen in den Sinn, ist nicht einfach die RC mit den falschen Kanälen der Keymatic gepeert?
Ich verstehe das Handbuch so.
Ich habe allerdings keine Keymatic und kann nur theoretisch mitreden.
Vielleicht ist das peeren der RC mit der Keymatic in FHEM immer noch eine offene Baustelle?
Vielleicht solltest Du RC und Keymatic standalone peeren und erst dann mit FHEM pairen? Das direkte anlernen ist ja im Handbuch beschrieben.
Nur eine Idee...
Gruß Otto
Dass die Reihenfolge der Tasten auf der FB nicht mit den Kanälen von 1-4 übereinstimmt, ist dir bewusst?
Ohne das komplette Peering wird dir hier keiner helfen können.
Hallo Otto, Markus,
ja Otto, hatte ich mir auch überlegt. Könnte nochmal anfangen und das erst anlernen und dann mit fhem pairen. Weiß du, ob dann die peerings bleiben?
Ja Markus, hast recht, wie lese ich die peers schön aus? Habe da noch wenig Erfahrungen. vielleicht einen Befehle ;-)
Gruß Holger
Zitat von: handy80 am 19 Juni 2017, 14:37:01
Hallo Otto, Markus,
ja Otto, hatte ich mir auch überlegt. Könnte nochmal anfangen und das erst anlernen und dann mit fhem pairen. Weiß du, ob dann die peerings bleiben?
Die bleiben, bis zum Werksreset der Geräte :) oder löschen per Zentrale (FHEM).
Gruß Otto
Hallo Otto,
habe versucht das Abmelden (set keymatic unpair) zu machen. Ich glaube der Befehl wurde nicht richtig angenommen. Auf jeden Fall steht jetzt missing_ack im state und aesKeyNbr auf 02 (war 00 als Zentrale und Keymatic noch funktioniert miteinander geredet haben)
Jetzt geht gar nichts mehr. Ich kann auch den Werkreset nicht durchführen, weil er immer noch auf die Zentrale wartet.
Hilfe, was kann ich machen?
warum unpair? zu spaet.
du hast demnach ein aes problem. werden im device probleme angezeigt? etwas mit aes?
hast du den key geaendert? kennst du den alten noch?
Hi Martin, bin komplett aufgeschmissen.
Dachte mit unpair wäre es am saubersten.
(weil ich Otto's Idee gut fand "Vielleicht solltest Du RC und Keymatic standalone peeren und erst dann mit FHEM pairen?")
Also dachte ich alles Schritt für Schritt rückgängig machen. (peers entfernen und geräte ablernen)
Bei der Fernbedienung hat das unpair sauber funktioniert und um pairTo steht 00000
Bei der KeyMatic steht nach dem unpair immer noch die hmid der vccu
denke auch, dass es ein aes Problem ist, aber welches und wie bekomme ich es gelöst?!
und ja, keys sind alle bekannt.
unpairen halte ch eigentlich noe fuer notwendig.
wenn es probleme mit dem key gibt kann es schwierig werden. ist dein io von eq3? starte es neu. es kann sich keyzuordnungen merken. aber nicht ueber powwer up. ist ein versuch.
nutze einen CUL V3 von Busware. Ich habe die FHEM und der gesamte rPi schon neu gestartet.
list:
Internals:
CUL1_MSGCNT 3
CUL1_RAWMSG A1A01840023DA710000002500194B455130383536373136C0000100::-46.5:CUL1
CUL1_RSSI -46.5
CUL1_TIME 2017-06-20 21:48:43
DEF 23DA71
IODev CUL1
LASTInputDev CUL1
MSGCNT 3
NAME Haustuer
NOTIFYDEV global
NR 214
NTFY_ORDER 50-Haustuer
STATE RESPONSE TIMEOUT:RegisterRead
TYPE CUL_HM
lastMsg No:01 - t:00 s:23DA71 d:000000 2500194B455130383536373136C0000100
peerList SchluesselFernbedienung_unlock,SchluesselFernbedienung_lock,SchluesselFernbedienung_open,
protCmdDel 4
protLastRcv 2017-06-20 21:48:43
protResnd 2 last_at:2017-06-20 21:48:38
protResndFail 2 last_at:2017-06-20 21:48:43
protSnd 2 last_at:2017-06-20 21:48:33
protState CMDs_done_Errors:1
rssi_at_CUL1 cnt:3 avg:-48.5 max:-46.5 min:-51.5 lst:-46.5
Readings:
2017-06-19 22:07:28 CommandAccepted yes
2017-06-20 21:48:43 D-firmware 2.5
2017-06-20 21:48:43 D-serialNr KEQ0856716
2017-06-17 20:20:51 PairedTo 0xB3BEA5
2017-06-18 15:29:09 R-angelLocked 990.09900990099 deg
2017-06-18 15:29:09 R-angelMax 1050.10501050105 deg
2017-06-18 15:29:08 R-angelOpen 120.01200120012 deg
2017-06-11 19:43:05 R-pairCentral 0xB3BEA5
2017-06-18 15:29:08 R-setupPosition 180.01800180018 deg
2017-06-19 22:07:28 aesCommToDev ok
2017-06-19 22:07:28 aesKeyNbr 02
2017-06-20 21:47:59 battery ok
2017-06-20 21:47:59 direction undef
2017-06-20 21:47:59 error none
2017-06-20 21:47:59 lock unlocked
2017-06-20 21:06:55 peerList SchluesselFernbedienung_unlock,SchluesselFernbedienung_lock,SchluesselFernbedienung_open,
2017-06-20 21:47:59 powerOn 2017-06-20 21:47:59
2017-06-20 21:47:59 recentStateType info
2017-06-20 21:48:43 state RESPONSE TIMEOUT:RegisterRead
2017-06-20 21:16:04 trigLast SchluesselFernbedienung_unlock:short
2017-06-18 21:37:21 trig_SchluesselFernbedienung_lock Short_0
2017-06-18 21:38:05 trig_SchluesselFernbedienung_open Short_3
2017-06-20 21:16:04 trig_SchluesselFernbedienung_unlock Short_0
2017-06-20 21:48:19 uncertain permanent
Regl_00.:
VAL
Helper:
HM_CMDNR 40
PONtest 0
cSnd 01B3BEA523DA7101012299390101,01B3BEA523DA7100040000000000
getCfgList all
getCfgListNo ,3
mId 0019
rxType 2
supp_Pair_Rep 1
Expert:
def 1
det 0
raw 1
tpl 0
Io:
newChn +23DA71,00,01,00
nextSend 1497988123.34295
rxt 0
vccu VCCU
p:
23DA71
00
01
00
prefIO:
CUL1
Mrssi:
mNo 01
Io:
CUL1 -44.5
Prt:
bErr 0
sProc 0
Q:
qReqConf
qReqStat 00
Role:
chn 1
dev 1
Rssi:
At_cul1:
avg -48.5
cnt 3
lst -46.5
max -46.5
min -51.5
Tmpl:
Attributes:
IODev CUL1
IOgrp VCCU:CUL1
autoReadReg 4_reqStatus
expert 2_raw
firmware 2.5
model HM-SEC-KEY
msgRepeat 1
peerIDs 00000000,22993901,22993902,22993904,
room CUL_HM,Haus
serialNr KEQ0856716
subType keyMatic
webCmd lock:unlock:open
Kann mir jemand helfen das coding in fhem für unpair (denke irgendwo im modul hm oder?) in meinem Fall zu verstehen? Wo muss ich reinschauen? Wie kann ich mich da zurechtfinden.
Ich will verstehen was da passiert ist und warum das unpair bei der keymatic nicht ankam/verarbeitet werden konnte und warum sie keine Befehle mehr von fhem annimmt. denn ich gehe davon aus, dass ich aus fhem-Sicht alles richtig gemacht habe. Lässt für mich nur den Schluss zu, dass das coding in fhem unvollständig oder fehlerhaft ist.
Moin,
ich kann Dir nicht gezielt helfen, wie schon gesagt. Ich kenne mich auch mit der Behebung von AES Key Problemen nicht gut aus.
Er scheint ja noch gepairt zu sein, was ist wenn Du ein getConfig absetzt? Vorher eventuell set Haustuer clear cmdEvents? Ich weiß nicht mal ob man bei dem SEC-KEY zur Datenübertragung den Configtaster drücken muss oder ob er es so tut.
Gruß Otto
Hallo Otto, clear msgEvents hab ich gemacht, getConfig auch schon.
Kommt bei der keymatic auch an (es taucht dann ein blinkendes Antennensymbol auf) die keymatic meldet eigentlich sofort ohne was zu drücken zurück.
In FHEM zeigt er dann "RESPONSE TIMEOUT:RegisterRead"
Zitat von: handy80 am 20 Juni 2017, 19:18:40
Auf jeden Fall steht jetzt missing_ack im state und aesKeyNbr auf 02 (war 00 als Zentrale und Keymatic noch funktioniert miteinander geredet haben)
Jetzt geht gar nichts mehr. Ich kann auch den Werkreset nicht durchführen, weil er immer noch auf die Zentrale wartet.
Hilfe, was kann ich machen?
Scheinbar ist hier was schief gegangen. Ich weiß leider nicht wie man jetzt weiter vorgeht. Eventuell hat einer von Beiden den falschen Key.
Gruß Otto