Hallo,
ich betreibe meine HM-SEC-SD-2 seit einigen Jahren an FHEM mit HM-CFG-USB. Alles gut soweit: AES ist aktiv, virtueller Team Lead.
Nun möchte ich auf RaspMatic wechseln. Allerdings schaffe ich es nicht, den HM-SEC-SD-2 dort anzulernen: Egal was ich versuche, das Gerät erscheint nie im Posteingang und die LED am HM-SEC-SD-2 blinkt bis zum Timeout orange.
Ich habe bereits folgendes probiert:
* HM-SEC-SD-2 mittels reset von FHEM trennen
* HM-SEC-SD-2 mittels unpair von FHEM trennen
* Am HM-SEC-SD-2 auf Werkseinstellungen zurückgesetzt
Nichts davon bringt etwas.
Am FHEM kann ich den HM-SEC-SD-2 jederzeit wieder anlernen, das funktioniert einwandfrei. Ebenfalls konnte ich alle sonstigen Komponenten an RaspMatic anlernen, auch kein Problem.
Nur HM-SEC-SD-2 und RaspMatic ignorieren sich konsequent.
Hat jemand eine Idee hierzu? Muss ich noch irgend etwas besonderes tun, damit der HM-SEC-SD-2 wieder jungfräulich ist?
Viele Grüße,
Breti
Hallo,
ich hae das gleich vor wie du, nur mit einem HM-SEC-MDIR-2. Ich kann an fhem auch alles mit lesen nur an der CCU lässt es sich nicht richtig pairen.
Hast du zwischenzeitlich das Problem lösen können?
Grüße
Hallo,
leider nein, ich habe keine neuen Erkenntnisse :-(.
Viele Grüße,
Breti
Hi,
set ... reset sollte das Gerät von FHEM trennen
Zitatreset
Rücksetzen des Geräts auf Werkseinstellungen. Muss danach erneut verbunden werden um es mit FHEM zu nutzen.
Allerdings muss es wirklich gepairt sein und es muss eine Chance haben diesen Befehl zu verarbeiten.
Ein Werksreset am Gerät muss danach ordentlich quittiert werden (Handbuch) sonst ist das Gerät nicht abgelernt.
list von den Geräten könnte helfen, die Ferndiagnose zu verbessern.
Gruß Otto
Ich habe gestern und heute nun nochmal ein wenig weitergetestet.
Vorab: Alle 5 Rauchmelder scheinen sich identisch zu verhalten. Es handelt sich also nicht um einen Einzeldefekt.
Hier ein Beispiel für einen durchgeführten Reset:
fhem> list sz_rm
Internals:
DEF 4C7FF5
FUUID 5c55b435-f33f-a627-59f6-4d55fae78b63c4b6
HMUSB_MSGCNT 2
HMUSB_RAWMSG R8ABE443D,0001,5D9406F1,FF,FFC6,D0A6104C7FF5B1036F0601000031
HMUSB_RSSI -58
HMUSB_TIME 2020-06-06 19:47:04
IODev HMUSB
LASTInputDev HMUSB
MSGCNT 2
NAME sz_rm
NOTIFYDEV global
NR 213
NTFY_ORDER 50-sz_rm
STATE off
TYPE CUL_HM
chanNo 01
lastMsg No:D0 - t:10 s:4C7FF5 d:B1036F 0601000031
peerList gl_rm_team,
protLastRcv 2020-06-06 19:47:04
protRcv 1 last_at:2020-06-06 19:47:04
protSnd 2 last_at:2020-06-06 19:47:04
protSndB 1 last_at:2020-06-06 19:47:04
protState CMDs_done
rssi_HMUSB cnt:1 min:-49 max:-49 avg:-49 lst:-49
rssi_at_HMUSB cnt:2 min:-58 max:-58 avg:-58 lst:-58
READINGS:
2020-06-06 19:50:41 Activity alive
2016-07-10 18:57:57 CommandAccepted yes
2016-07-10 19:23:24 D-firmware 1.0
2016-07-10 19:23:24 D-serialNr NEQ0446436
2019-01-07 19:03:13 PairedTo 0xB1036F
2016-07-10 18:55:45 R-pairCentral 0xB1036F
2019-01-07 19:03:13 RegL_00. 00:00 02:01 0A:B1 0B:03 0C:6F 16:00 1F:00
2016-07-10 18:57:57 aesCommToDev ok
2016-07-10 18:57:57 aesKeyNbr 02
2020-06-06 19:47:04 alarmTest ok
2020-06-06 19:47:04 battery ok
2020-06-06 19:47:04 level 0
2020-06-06 19:46:34 peerList gl_rm_team,
2019-09-20 07:48:31 powerOn 2019-09-20 07:48:31
2020-06-06 19:47:04 recentStateType info
2019-01-07 19:03:13 sdRepeat off
2020-06-06 19:47:04 smokeChamber ok
2017-09-08 13:09:38 smoke_detect none
2020-06-06 19:47:04 state off
2017-09-08 13:09:38 teamCall from gl_rm_team_dev:00
2016-07-10 19:23:29 trigLast gl_rm_team:150
2016-07-10 19:23:29 trig_gl_rm_team 150
2016-07-10 18:56:26 trigger_cnt 2
helper:
HM_CMDNR 208
cSnd ,01B1036F4C7FF5010E
mId 00AA
peerFriend peerSD
peerOpt p:smokeDetector
regLst 0
rxType 6
supp_Pair_Rep 0
expert:
def 1
det 0
raw 1
tpl 0
io:
newChn +4C7FF5,00,01,00
nextSend 1591465625.03107
rxt 0
vccu vccu
p:
4C7FF5
00
01
00
prefIO:
HMUSB
mRssi:
mNo D0
io:
HMUSB:
-52
-52
prt:
bErr 0
sProc 0
rspWait:
q:
qReqConf
qReqStat
role:
chn 1
dev 1
rpt:
IO HMUSB
flg A
ts 1591465624.80415
ack:
HASH(0x1b9f808)
D08002B1036F4C7FF500
rssi:
HMUSB:
avg -49
cnt 1
lst -49
max -49
min -49
at_HMUSB:
avg -58
cnt 2
lst -58
max -58
min -58
shadowReg:
tmpl:
Attributes:
IODev HMUSB
IOgrp vccu:HMUSB
actCycle 099:00
actStatus alive
alias Sz Rauchmelder
autoReadReg 5_readMissing
expert 2_raw
firmware 1.0
model HM-SEC-SD-2
msgRepeat 1
peerIDs 00000000,11111101,
room Schlafzimmer
serialNr NEQ0446436
subType smokeDetector
webCmd statusRequest
fhem> set sz_rm reset
fhem> list sz_rm
Internals:
DEF 4C7FF5
FUUID 5c55b435-f33f-a627-59f6-4d55fae78b63c4b6
HMUSB_MSGCNT 6
HMUSB_RAWMSG E4C7FF5,0000,5D9CFA7F,FF,FFBC,8086104C7FF500000006010000
HMUSB_RSSI -68
HMUSB_TIME 2020-06-06 19:56:51
IODev HMUSB
LASTInputDev HMUSB
MSGCNT 6
NAME sz_rm
NOTIFYDEV global
NR 213
NTFY_ORDER 50-sz_rm
STATE off
TYPE CUL_HM
chanNo 01
lastMsg No:80 - t:10 s:4C7FF5 d:000000 06010000
peerList gl_rm_team,
protEvt_AESCom-ok 1 last_at:2020-06-06 19:56:47
protLastRcv 2020-06-06 19:56:51
protRcv 3 last_at:2020-06-06 19:56:51
protResnd 1 last_at:2020-06-06 19:56:46
protSnd 3 last_at:2020-06-06 19:56:43
protSndB 3 last_at:2020-06-06 19:56:46
protState CMDs_done
rssi_HMUSB cnt:1 min:-49 max:-49 avg:-49 lst:-49
rssi_at_HMUSB cnt:5 min:-70 max:-58 avg:-64.8 lst:-68
READINGS:
2020-06-06 19:50:41 Activity alive
2020-06-06 19:56:47 CommandAccepted yes
2016-07-10 19:23:24 D-firmware 1.0
2016-07-10 19:23:24 D-serialNr NEQ0446436
2019-01-07 19:03:13 PairedTo 0xB1036F
2016-07-10 18:55:45 R-pairCentral 0xB1036F
2019-01-07 19:03:13 RegL_00. 00:00 02:01 0A:B1 0B:03 0C:6F 16:00 1F:00
2020-06-06 19:56:47 aesCommToDev ok
2020-06-06 19:56:47 aesKeyNbr 02
2020-06-06 19:56:51 alarmTest ok
2020-06-06 19:56:51 battery ok
2020-06-06 19:56:51 level 0
2020-06-06 19:46:34 peerList gl_rm_team,
2020-06-06 19:56:51 powerOn 2020-06-06 19:56:51
2020-06-06 19:56:51 recentStateType info
2019-01-07 19:03:13 sdRepeat off
2020-06-06 19:56:51 smokeChamber ok
2017-09-08 13:09:38 smoke_detect none
2020-06-06 19:56:51 state off
2017-09-08 13:09:38 teamCall from gl_rm_team_dev:00
2016-07-10 19:23:29 trigLast gl_rm_team:150
2016-07-10 19:23:29 trig_gl_rm_team 150
2016-07-10 18:56:26 trigger_cnt 2
helper:
HM_CMDNR 128
cSnd 01B1036F4C7FF5010E,11B1036F4C7FF50400
mId 00AA
peerFriend peerSD
peerOpt p:smokeDetector
regLst 0
rxType 6
supp_Pair_Rep 0
expert:
def 1
det 0
raw 1
tpl 0
io:
newChn +4C7FF5,00,01,00
nextSend 1591466211.48473
rxt 0
vccu vccu
p:
4C7FF5
00
01
00
prefIO:
HMUSB
mRssi:
mNo 80
io:
HMUSB:
-64
-64
prt:
bErr 0
sProc 0
q:
qReqConf
qReqStat
role:
chn 1
dev 1
rssi:
HMUSB:
avg -49
cnt 1
lst -49
max -49
min -49
at_HMUSB:
avg -64.8
cnt 5
lst -68
max -58
min -70
shadowReg:
tmpl:
Attributes:
IODev HMUSB
IOgrp vccu:HMUSB
actCycle 099:00
actStatus alive
alias Sz Rauchmelder
autoReadReg 5_readMissing
expert 2_raw
firmware 1.0
model HM-SEC-SD-2
msgRepeat 1
peerIDs 00000000,11111101,
room Schlafzimmer
serialNr NEQ0446436
subType smokeDetector
webCmd statusRequest
fhem>
Nach dem set...reset habe ich den Anlernen-Knopf am Rauchmelder gedrückt gehalten. Nach wenigen Sekunden hat der Rauchmelder mit rot-grün-gelb quittiert, danach ist dann das obige zweite list entstanden.
Sicherheitshalber habe ich danach nochmals einen Werksreset am Rauchmelder selber durchgeführt. Also Knopf diesmal lange gedrückt gehalten: Erst orange blinkend, dann rot blinkend, dann loslassen - rot-grün-gelb. Alles wie erwartet nach Anleitung.
Trotzdem gelingt es mir weiterhin nicht, auch nur einen der fünf Rauchmelder an der Raspberrymatic CCU anzulernen. Die ignorieren sich weiterhin komplett. Die Installation ist eigentlich fast identisch zu vorher: Ein HM-CFG-USB hängt am Raspberry Pi, auf dem HMLAND läuft. An den dockt dann wahlweise FHEM (lokal auf dem gleichen Raspi installiert) oder Raspberrrymatic (als VM auf dem Synology-NAS) an (es ist jeweils nur eines von beiden aktiv). Alle anderen Komponenten - Heizung, Licht, Bewegungsmelder - konnte ich völlig problemlos umziehen. Nur diese Luxus-Rauchmelder weigern sich mit störrischer Ignoranz.
Laut Anleitung kann man ja auch mehrere Rauchmelder ohne Zentrale direkt miteinander koppeln, in dem man beide in den Anlernmodus bringt. Auch das funktioniert: Erst orangenes Blinken, dann grünes Leuchten und fertig. Direkt beim ersten Versuch haben sich beide gefunden und verbunden.
Ich versteh's einfach nicht!
Hi,
einige Readings sind alt, wird also nach Deiner Beschreibung schon so sein, dass er abgelernt ist.
Was mir jetzt nur dazu einfällt: Die SD2 brauchen für den Betrieb in FHEM ein zusätzliches Modul (https://wiki.fhem.de/wiki/HM-SEC-SD_Rauchmelder). "Der HM-SEC-SD-2 Rauchmelder arbeitet mit aesCBC, ..."
Ist das der Unterschied zu all Deinen anderen Komponenten? Fehlt da noch was in Deiner Einrichtung?
Gruß Otto
Zitat von: Otto123 am 07 Juni 2020, 11:15:36
Was mir jetzt nur dazu einfällt: Die SD2 brauchen für den Betrieb in FHEM ein zusätzliches Modul (https://wiki.fhem.de/wiki/HM-SEC-SD_Rauchmelder). "Der HM-SEC-SD-2 Rauchmelder arbeitet mit aesCBC, ..."
Ist das der Unterschied zu all Deinen anderen Komponenten? Fehlt da noch was in Deiner Einrichtung?
Hmmm... also in FHEM hat das Ding so funktioniert, da sollte alles installiert gewesen sein. Raspberrymatic kommt als komplettes Image, das wird einfach als VM ausgeführt, da kann ich nichts drin hinzufügen oder löschen. Manche sicherheitskritische Sensoren bindet er aber standardmäßig mit AES ein, z.B. die Drehgriffkontakte. Dabei habe ich keine Fehler bemerkt (wobei ich die Signatur jeweils direkt wieder deaktiviert habe, weil ich die RHS nur zur Heizungssteuerung nutze).
Ich habe gerade mal bei EQ-3 ein Ticket aufgemacht, ich vermute aber mal, dass die das direkt wieder schließen werden, weil nicht deren CCU. Wenn dem so ist, versuche ich es nochmal im Raspberrymatic Forum. Zuerst dachte ich, dass ich die Teile nicht richtig von FHEM ablerne, darum habe ich es bislang hier versucht, aber mittlerweile bin ich recht sicher, dass das Ablernen funktioniert.
Für den Moment habe ich die 5 Stück nun erstmal nur ohne Zentrale miteinander verbunden. Das hat fehlerfrei funktioniert, die haben sich alle direkt beim ersten Versuch gefunden.
ich sage: "set reset" funktioniert nicht.
das 2. list zeigt zb immer noch key2 und cmds_done.
solange der sd einen key2 hat funktioniert kein werkreset am device direkt, also überflüssig.
sind alle komponenten upToDate?
1. fhem, 2. usbstick, 3. hmland
danach ein "set reset" sniffen, wie im wiki beschrieben.
alternativ kann man auch der ccu die hmid von fhem zuweisen und dann dort pairen und bei erfolg resetten.
Zitat von: frank am 07 Juni 2020, 11:55:48
ich sage: "set reset" funktioniert nicht.
das 2. list zeigt zb immer noch key2 und cmds_done.
Hmmm.... aber der Rauchmelder bestätigt es zumindest beim langen Drücken des Tasters mit rot-grün-orange anstatt gelb zu blinken. Wie er eine reguläre Konfigurationsänderung quittieren würde, weiß ich gerade nicht, ich würde aber eher grün vermuten wie beim direkten anlernen mehrerer Rauchmelder untereinander ohne Zentrale. rot-grün-orange ist doch eigentlich immer eine Bestätigung für einen Reset?
Zitat von: frank am 07 Juni 2020, 11:55:48
solange der sd einen key2 hat funktioniert kein werkreset am device direkt, also überflüssig.
Aber der Werksreset am Device wird doch bestätigt mit rot-grün-orange und ich kann die Geräte anschließend auch direkt miteinander koppeln ohne Zentrale. Das dürfte doch beides nicht funktionieren, wenn die nicht komplett zurückgesetzt wurden?
Zitat von: frank am 07 Juni 2020, 11:55:48
sind alle komponenten upToDate?
1. fhem, 2. usbstick, 3. hmland
FHEM habe ich schon länger nicht mehr aktualisiert, weil ich es ja eigentlich nicht mehr nutze:
# $Id: fhem.pl 19964 2019-08-08 09:21:00Z rudolfkoenig $
Der HM-CFG-USB hat die aktuellste Firmware drauf, hmland läuft in Version 0.102-git.
Zitat von: frank am 07 Juni 2020, 11:55:48
danach ein "set reset" sniffen, wie im wiki beschrieben.
alternativ kann man auch der ccu die hmid von fhem zuweisen und dann dort pairen und bei erfolg resetten.
OK, danke - sieht nach einem größeren Projekt aus :-/. Zum Setzen der hmid in der CCU habe ich gerade diesen Thread gefunden:
https://forum.fhem.de/index.php?topic=91211.0 (https://forum.fhem.de/index.php?topic=91211.0)
Dummerweise habe ich alle anderen Aktoren, und das sind einige, ja schon durch zurücksetzen und neu anlernen umgezogen, die hängen nun also alle an der neuen hmid. Dumm gelaufen, hätte ich mal lieber vorher gefragt...
Ich könnte ja einfach eine neue VM mit einem nackten Raspberrymatic neu aufsetzen, nur um die HM-SEC-SD-2 daran zu versuchen. Was genau müsste ich denn dann aus der FHEM Installation übernehmen? Die hmid und den Sicherheitsschlüssel, so wie ich ihn damals im Klartext eingetragen habe, bevor ihn FHEM verschleiert hat?
du kannst die hmid ja nur vorrübergehend ändern, bis die sd hoffentlich resettet sind.
in der zwischenzeit kann die ccu halt nicht mit dem rest quatschen.
nach meinen erfahrungen mit dem eq3 usb konfigurator müsste beim pairen dann die frage nach dem key kommen.
angeblich gibt es auch manchmal probleme mit sonderzeichen im key. könnte das zutreffen?
Zitat von: frank am 07 Juni 2020, 12:25:36
du kannst die hmid ja nur vorrübergehend ändern, bis die sd hoffentlich resettet sind.
in der zwischenzeit kann die ccu halt nicht mit dem rest quatschen.
nach meinen erfahrungen mit dem eq3 usb konfigurator müsste beim pairen dann die frage nach dem key kommen.
Ah OK, das wusste ich nicht.
Zitat von: frank am 07 Juni 2020, 12:25:36
angeblich gibt es auch manchmal probleme mit sonderzeichen im key. könnte das zutreffen?
Nein, sind keine Sonderzeichen drin. Nur Groß- und Kleinbuchstaben.
in der gerade heruntergeladenen ba sehe ich unter werkreset keine beschreibung für das led blinken nach der ausführung.
buntes geblinker kenne ich eigentlich nicht als bestätigung, eher mal nach erfolgreichem initialisieren nach booten.
das könnte ja hier durchaus zutreffen, da die batterie fest verbaut ist.
hattest du beim werkreset auch schon anderes geblinker für eventuellen misserfolg?
wie hattest du das pairen an der ccu gemacht?
mit oder ohne serial?
Zitat von: frank am 07 Juni 2020, 12:39:46
in der gerade heruntergeladenen ba sehe ich unter werkreset keine beschreibung für das led blinken nach der ausführung.
buntes geblinker kenne ich eigentlich nicht als bestätigung, eher mal nach erfolgreichem initialisieren nach booten.
das könnte ja hier durchaus zutreffen, da die batterie fest verbaut ist.
Hast Recht.
Zitat von: frank am 07 Juni 2020, 12:39:46
hattest du beim werkreset auch schon anderes geblinker für eventuellen misserfolg?
Nicht, dass ich mich erinnern könnte.
Zitat von: frank am 07 Juni 2020, 12:39:46
wie hattest du das pairen an der ccu gemacht?
mit oder ohne serial?
Ich hab heute nur über 60s Anlernmodus probiert, aber in der Vergangenheit auch über Serial. Beides gleichermaßen ergebnislos.
Habe meine Raspmatic VM gecloned und dann damit gespielt.
In der Datei /usr/local/etc/config/ids habe ich meine hmid aus FHEM eingetragen.
Laut https://forum.fhem.de/index.php/topic,83934.30.html (https://forum.fhem.de/index.php/topic,83934.30.html) soll es dezimal wie hexadezimal funktionieren. Ich habe beides probiert, also
BidCoS-Address = 11????51
sowie
BidCoS-Address = 0xB????F
Und danach jeweils die Raspmatic neu gestartet. Leider wie gehabt ohne Erfolg: Der Rauchmelder sieht die Zentrale nicht und blinkt unbeeindruckt orange.
Anlernen mit Seriennummer bringt die Meldung:
Homematic Funk Anlernen mit Seriennummer neq000???? fehlgeschlagen. Überprüfen Sie die Seriennummer.
Edit: Trotz der nun auf die alte hmid geänderten Datei auf der Raspmatic kann ich weiterhin die Geräte schalten, die direkt an die Raspmatic angelernt wurden, mit der neuen ID. Ist das normal?
ZitatTrotz der nun auf die alte hmid geänderten Datei auf der Raspmatic kann ich weiterhin die Geräte schalten, die direkt an die Raspmatic angelernt wurden, mit der neuen ID. Ist das normal?
nee, dann wird die "falsche" hmid genutzt.
falsche datei geändert?
Ich hab die Datei
/usr/local/etc/config/ids
geändert.
Die sieht so aus:
BidCoS-Address = 11????51
SerialNumber = GEQ00?????
Und argghh jetzt hab ich das Chaos komplett... ich wollte testweise den Sicherheitsschlüssel ändern in der gecloneten CCU, nicht wissend, dass er dann gleich loslegt und den auf alle Geräte verteilt... und nun hänge ich da irgendwo mittendrin. Die netzbetriebenen Geräte haben ihn sich gezogen, die anderen warten auf einen Druck auf den Konfigurationstaster.
Was für ein Chaos. Alles kaputt in wenigen Minuten.
Ansonsten gibt es noch /var/ids, aber da ist keine ID eingetragen:
root@raspmatic:/usr/local/etc/config# cat /var/ids
BidCoS-Address=
SerialNumber=
root@raspmatic:/usr/local/etc/config#
in var/ids stehen bei mir die original werte des io (hmuart).
geändert habe ich usr/local/etc/config. damit sendet meine debmatic seit änderung.
BidCoS-Address=0x1ACE1F
SerialNumber=NEQ0230329
-rw-r--r-- 1 root root 48 Oct 29 2019 ids
ich habe fast den verdacht, dass deine ccu sowieso schon die hmid deines fhem nutzt.
hmids muss mann nicht unkenntlich machen.
zeig mal ein list vom hmusb aus fhem.
Zitat von: deimos am 13 Januar 2020, 08:18:24
Hi,
/var/ids hat immer die BidCos Adresse des physikalisch eingebauten Funkmoduls. Die Datei /usr/local/etc/config/ids wird beim ersten Start nach einem Werksreset aus dieser generiert und wird danach für die Installation beibehalten, will heißen, sie wandert in ein Backup und damit ggf. auch auf eine andere CCU. Zum eigentlichen Funken nutzt der rfd bzw. der multimacd der CCU dann immer die ID aus /usr/local/etc/config/ids. Dadurch wird sichergestellt, dass deine Installation auch nach einem Zentralenwechsel weiter funktioniert, ohne dass man alle Geräte neu an die Zentrale anmelden müsste.
Viele Grüße
Alex
Zitat von: frank am 07 Juni 2020, 16:37:51
ich habe fast den verdacht, dass deine ccu sowieso schon die hmid deines fhem nutzt.
hmids muss mann nicht unkenntlich machen.
zeig mal ein list vom hmusb aus fhem.
Arghh... du hast völlig Recht! Ich habe gerade nochmal meine originale Raspmatic VM gestartet, die ID darin ist die gleiche, die ich auch bei FHEM gesetzt habe, nur halt Dezimal statt Hexadezimal. Darum habe ich das nicht bemerkt, weil ich die aus FHEM eben hexadezimal übertragen hatte... man man man.
Die /usr/local/etc/config/ids auf raspmatic sieht unverpfuscht so aus:
root@raspmatic:/usr/local/etc/config# cat ids
BidCoS-Address = 11600751
SerialNumber = GEQ0073165
root@raspmatic:/usr/local/etc/config# ls -lisa ids
1835020 4 -rw-r--r-- 1 root root 53 Dec 18 22:09 ids
root@raspmatic:/usr/local/etc/config#
In FHEM sieht es so aus:
fhem> list HMUSB
Internals:
DEF 127.0.0.1:1000
DeviceName 127.0.0.1:1000
FD 9
FUUID 5c55b3ff-f33f-a627-7183-94309ff0c5a08180
HMUSB_MSGCNT 114
HMUSB_TIME 2020-06-07 21:53:06
IFmodel USB
NAME HMUSB
NR 25
NTFY_ORDER 50-HMUSB
PARTIAL
RAWMSG R90580427,0001,632DDC14,FF,FFCA,6180021A7C47B1036F0102220034
RSSI -54
STATE opened
TYPE HMLAN
XmitOpen 2
assignedIDsCnt 49
msgKeepAlive dlyMax:50.235 bufferMin:-45
msgLoadCurrent 46
msgLoadHistoryAbs 5min steps: 2/0/0/0/0/0/0/0/0/0/0/0
owner B1036F
owner_CCU vccu
uptime 019 462:12:29.844
READINGS:
2020-06-07 21:51:35 D-HMIdAssigned B1036F
2020-06-07 21:51:35 D-HMIdOriginal 121EC5
2020-06-07 21:51:35 D-firmware 0.967
2020-06-07 21:51:35 D-serialNr GEQ0073165
2020-06-07 21:51:36 Xmit-Events ok:1 disconnected:1 init:1
2020-06-07 21:51:36 cond ok
2020-06-07 21:53:04 loadLvl batchLevel
2017-04-03 22:50:18 prot_ERROR-Overload last
2017-04-03 23:20:17 prot_Warning-HighLoad last
2020-06-07 21:50:19 prot_disconnected last
2020-06-07 21:50:19 prot_init last
2019-12-21 02:19:41 prot_keepAlive last
2020-06-07 21:51:36 prot_ok last
2016-12-16 00:00:39 prot_timeout last
2020-06-07 21:50:19 state opened
helper:
assIdCnt 49
assIdRep 49
info 03C7,GEQ0073165,121EC5,B1036F
setTime 48570
cnd:
0 1
253 1
255 1
ids:
101E28:
cfg +101E28,00,01,00
name wz_fb_sitzecke
1023C1:
cfg +1023C1,00,01,00
chn 02
flg 0
msg
name bz_sa_licht
to 1591559506.33684
1023C7:
cfg +1023C7,00,01,00
chn 02
flg 0
msg
name wz_sa_tv
to 1591559519.51688
107385:
cfg +107385,00,01,00
name bz_wt_waschbecken
10F77A:
cfg +10F77A,00,01,00
name sz_wt_bettlicht
110F5B:
cfg +110F5B,00,01,00
chn 01
flg 0
msg
name ku_sa_licht
to 1591559506.95376
11159E:
cfg +11159E,00,01,00
chn 01
flg 0
msg
name az_sa_licht
to 1591559503.55556
11A9AD:
cfg +11A9AD,00,01,00
chn 01
flg 0
msg
name sz_sa_bettlicht
to 1591559512.67597
11D319:
cfg +11D319,00,01,00
chn 02
flg 0
msg
name bz_sa_radio
to 1591559506.53122
11D460:
cfg +11D460,00,01,00
name wf_wt_tuerspr
1234F3:
cfg +1234F3,00,01,00
name az_fg_fenster
12FA0F:
cfg +12FA0F,00,01,00
name az_hv_heizung
12FB4F:
cfg +12FB4F,00,01,00
chn 03
flg 0
msg
name az_ht_heizung
to 1591559563.01391
149A5C:
cfg +149A5C,00,01,00
name wz_fg_tuer
150DFE:
cfg +150DFE,00,01,00
name sz_fg_fenster
150E16:
cfg +150E16,00,01,00
name wz_fg_fenster
150E6B:
cfg +150E6B,00,01,00
name ku_fg_fenster
163542:
cfg +163542,00,01,00
name bz_fg_fenster
185FBC:
cfg +185FBC,00,01,00
name te_bm_bewegung
18847C:
cfg +18847C,00,01,00
chn 01
flg 0
msg
name wz_da_licht_essecke
to 1591559514.94762
1930CB:
cfg +1930CB,00,01,00
chn 01
flg 0
msg
name az_sa_leselampe
to 1591559502.41808
19A018:
cfg +19A018,00,01,00
name hf_sk_briefkasten
19D87F:
cfg +19D87F,00,01,00
name ku_hv_heizung
1A79D2:
cfg +1A79D2,02,01,00
flg 0
msg
name ku_ht_heizung
to 1591559517.05459
1A79FA:
cfg +1A79FA,02,01,00
flg 0
msg
name sz_ht_heizung
to 1591559507.26408
1A7BA9:
cfg +1A7BA9,02,01,00
flg 0
msg
name wz_ht_heizung
to 1591559509.64929
1A7BC1:
cfg +1A7BC1,00,01,00
chn 03
flg 0
msg
name wf_ht_heizung
to 1591559552.35771
1A7C47:
cfg +1A7C47,02,01,00
chn 03
flg 1
msg
name bz_ht_heizung
to 1591559588.77367
1A84A8:
cfg +1A84A8,00,01,00
name sz_hv_heizung
1A8565:
cfg +1A8565,00,01,00
name bz_hv_heizung
1A86B7:
cfg +1A86B7,00,01,00
name wz_hv_heizung_fenster
1A86F0:
cfg +1A86F0,00,01,00
name wf_hv_heizung
1ABB9C:
cfg +1ABB9C,00,01,00
chn 02
flg 0
msg
name ku_sa_radio
to 1591559509.3489
1C47C0:
cfg +1C47C0,00,01,00
name wz_hv_heizung_wand
236F83:
cfg +236F83,00,01,00
name sz_wt_tuer
236F96:
cfg +236F96,00,01,00
name az_wt_tuer
2FB959:
cfg +2FB959,00,01,00
name ku_wt_tisch
2FB978:
cfg +2FB978,00,01,00
name wz_wt_flurtuer1
2FB994:
cfg +2FB994,00,01,00
name wz_wt_flurtuer2
2FB9D3:
cfg +2FB9D3,00,01,00
name bz_wt_tuer
48CA69:
cfg +48CA69,00,01,00
chn 01
flg 0
msg
name wf_rm
to 1591559518.84654
48CBCF:
cfg +48CBCF,00,01,00
chn 00
flg 0
msg
name az_rm
to 1591559528.7124
4C688E:
cfg +4C688E,00,01,00
chn 01
flg 0
msg
name ar_rm
to 1591559503.79153
4C7FF0:
cfg +4C7FF0,00,01,00
chn 01
flg 0
msg
name wz_rm
to 1591559520.86016
4C7FF5:
cfg +4C7FF5,00,01,00
chn 01
flg 0
msg
name sz_rm
to 1591559515.64397
4E5629:
cfg +4E5629,00,01,00
name wf_tk_wohnungstuer
4E5F15:
cfg +4E5F15,00,01,00
name sz_bm_bett
522A40:
cfg +522A40,00,01,00
chn 01
flg 0
msg
name wz_da_sitzecke
to 1591559515.26391
619BC5:
cfg +619BC5,00,01,00
chn 01
flg 0
msg
name sz_da_licht
to 1591559542.978
k:
BufMin -45
DlyMax 50.235
Next 1591559609.60108
Start 1591559584.60108
loadLvl:
bl 40
a:
99
90
40
0
h:
0 low
40 batchLevel
90 high
99 suspended
log:
all 0
sys 0
ids:
ARRAY(0xa70618)
q:
HMcndN 0
answerPend 1
hmLanQlen 1
keepAliveRec 1
keepAliveRpt 0
loadLastMax 46
loadNo 10
scnt 9
ald:
2
0
0
0
0
0
0
0
0
0
0
0
apIDs:
1A7C47
ref:
hmtL 1663947716
kTs 0
offL 1589895636897
sysL 1591559584613
Attributes:
hmId B1036F
hmLanQlen 1_min
loadLevel 0:low,40:batchLevel,90:high,99:suspended
fhem>
Das ist umgerechnet die gleiche ID und war es somit auch schon von Anfang an, warum auch immer?!?. Der Systemschlüssel ist nun auch gleich gesetzt, ich habe die Konfigurationstaster aller Batteriegeräte gedrückt, alle Servicemeldungen sind nun verschwunden.
Nur die blöden Rauchmelder stellen sich weiterhin stur. Nix zu machen.
Der eQ-3 Support möchte mir nicht weiterhelfen, teilt nur allgemein mit:
ZitatNach dem erfolgreichen Zurücksetzen des Rauchmelders blinkt dieser rot-grün-orange auf, da das Gerät einen Neustart durchführt.
Somit werden die Rauchmelder korrekt zurückgesetzt.
Wie belastbar diese Aussage ist, ist natürlich fraglich.
da plan b nicht funktioniert, würde ich mit plan a weitermachen.
also über fhem, alles updaten und den vorgang sniffen.
und ottos hinweis beachten.
ist die volle funktionsfähigkeit unter fhem denn noch gegeben? peeren, pairen, alarm, teamcall, etc.
Ich bin einen Schritt weiter... die virtuelle CCU verweigert die Anmeldung, warum auch immer. Hier das Log der CCU:
Jan 13 16:14:04 raspmatic syslog.info syslogd started: BusyBox v1.32.0
Jan 13 16:14:04 raspmatic user.notice kernel: klogd started: BusyBox v1.32.0 (2020-12-25 23:00:47 CET)
Jan 13 16:14:11 raspmatic user.debug rfd: GEQ0073165 RX: HHM-USB-IF,03C7,GEQ0073165,121EC5,B1036F,85EADE08,0030,06^M
Jan 13 16:14:16 raspmatic user.debug rfd: Entering install mode for 60 s
Jan 13 16:14:20 raspmatic user.debug rfd: NEQ0004389's type is HM-Sec-SD-2
Jan 13 16:14:20 raspmatic user.debug rfd: Device firmware version is 1.0
Jan 13 16:14:20 raspmatic user.debug rfd: TX: @4233092083 0xB1036F -> 0x48CBCF CONFIG_START [GEQ0073165]: CNT=1,RPTEN=1,RPTED=0,BIDI=1,BURST=1,WAKEUP=0,WAKEMEUP=0,BCAST=0,TYPE=0x01 CONFIG_CHANNEL = 0 CONFIG_PEER_ADDRESS = 0x000000 CONFIG_PEER_CHANNEL = 0 CONFIG_PARAM_LIST = 0
Jan 13 16:14:20 raspmatic user.err rfd: BidcosInterfaceConcentrator::SendFrame(): Interface does not support desired burst type.
Jan 13 16:14:20 raspmatic user.debug rfd: Event: NEQ0004389:0.UNREACH=true
Jan 13 16:14:20 raspmatic user.debug rfd: HSSXmlRpcEventDispatcher::Handle send 1 events
Jan 13 16:14:20 raspmatic user.debug rfd: Event: NEQ0004389:0.STICKY_UNREACH=true
Jan 13 16:14:20 raspmatic user.debug rfd: HSSXmlRpcEventDispatcher::Handle send 2 events
Jan 13 16:14:20 raspmatic user.debug rfd: HSSXmlRpcEventDispatcher::Handle send completed
Jan 13 16:14:20 raspmatic user.debug rfd: HSSXmlRpcEventDispatcher::Handle send 1 events
Jan 13 16:14:20 raspmatic user.debug rfd: SendFrame failed 1 times: @4233092083 0xB1036F -> 0x48CBCF CONFIG_START [GEQ0073165]: CNT=1,RPTEN=1,RPTED=0,BIDI=1,BURST=1,WAKEUP=0,WAKEMEUP=0,BCAST=0,TYPE=0x01 CONFIG_CHANNEL = 0 CONFIG_PEER_ADDRESS = 0x000000 CONFIG_PEER_CHANNEL = 0 CONFIG_PARAM_LIST = 0
Jan 13 16:14:20 raspmatic user.warn rfd: Peering with NEQ0004389 failed
Jan 13 16:14:20 raspmatic user.debug rfd: Deleting persistent data for device NEQ0004389
Jan 13 16:14:20 raspmatic user.debug rfd: HSSXmlRpcEventDispatcher::Handle send completed
Jan 13 16:14:21 raspmatic user.debug rfd: GEQ0073165 RX: HHM-USB-IF,03C7,GEQ0073165,121EC5,B1036F,85EB0637,0030,06^M
Jan 13 16:14:23 raspmatic user.debug rfd: NEQ0004389's type is HM-Sec-SD-2
Jan 13 16:14:23 raspmatic user.debug rfd: Device firmware version is 1.0
Jan 13 16:14:23 raspmatic user.debug rfd: TX: @4233095071 0xB1036F -> 0x48CBCF CONFIG_START [GEQ0073165]: CNT=1,RPTEN=1,RPTED=0,BIDI=1,BURST=1,WAKEUP=0,WAKEMEUP=0,BCAST=0,TYPE=0x01 CONFIG_CHANNEL = 0 CONFIG_PEER_ADDRESS = 0x000000 CONFIG_PEER_CHANNEL = 0 CONFIG_PARAM_LIST = 0
Jan 13 16:14:23 raspmatic user.err rfd: BidcosInterfaceConcentrator::SendFrame(): Interface does not support desired burst type.
Jan 13 16:14:23 raspmatic user.debug rfd: Event: NEQ0004389:0.UNREACH=true
Jan 13 16:14:23 raspmatic user.debug rfd: HSSXmlRpcEventDispatcher::Handle send 1 events
Jan 13 16:14:23 raspmatic user.debug rfd: Event: NEQ0004389:0.STICKY_UNREACH=true
Jan 13 16:14:23 raspmatic user.debug rfd: SendFrame failed 1 times: @4233095071 0xB1036F -> 0x48CBCF CONFIG_START [GEQ0073165]: CNT=1,RPTEN=1,RPTED=0,BIDI=1,BURST=1,WAKEUP=0,WAKEMEUP=0,BCAST=0,TYPE=0x01 CONFIG_CHANNEL = 0 CONFIG_PEER_ADDRESS = 0x000000 CONFIG_PEER_CHANNEL = 0 CONFIG_PARAM_LIST = 0
Jan 13 16:14:23 raspmatic user.warn rfd: Peering with NEQ0004389 failed
Auf FHEM Seite können wir da wohl nichts mehr erforschen.
neues jahr, neuer elan? ;)
soweit ich weiss, nutzen die sd2 einen besonderen burst mode. scheinbar wird dieser mode nicht mit dem usb gateway unterstützt.
seltsam.
Jan 13 16:14:23 raspmatic user.err rfd: BidcosInterfaceConcentrator::SendFrame(): Interface does not support desired burst type.
das würde zumindestens einiges erklären.
Zitat von: frank am 13 Januar 2021, 20:26:26
neues jahr, neuer elan? ;)
Ja, so kann man das sagen ;-). Das ist so ein Nervthema, auf das ich immer nur phasenweise Lust habe...
Zitat von: frank am 13 Januar 2021, 20:26:26
soweit ich weiss, nutzen die sd2 einen besonderen burst mode. scheinbar wird dieser mode nicht mit dem usb gateway unterstützt.
seltsam.
Jan 13 16:14:23 raspmatic user.err rfd: BidcosInterfaceConcentrator::SendFrame(): Interface does not support desired burst type.
das würde zumindestens einiges erklären.
Hm ja, sowas mag es sein. Fragt sich nur, warum FHEM diesen Modus nicht braucht...
ZitatFragt sich nur, warum FHEM diesen Modus nicht braucht...
ich würde eher sagen: über hmland/cul_hm wird dieser tripple-burst mode erfolgreich genutzt.
die frage ist also: warum kann raspberrymatic das nicht auch?
mach doch dort mal eine anfrage mit dem gezeigten log.
Zitat von: frank am 13 Januar 2021, 20:58:42
ich würde eher sagen: über hmland/cul_hm wird dieser tripple-burst mode erfolgreich genutzt.
die frage ist also: warum kann raspberrymatic das nicht auch?
Tja... das ist die Frage.
Zitat von: frank am 13 Januar 2021, 20:58:42
mach doch dort mal eine anfrage mit dem gezeigten log.
Hab ich schon... https://homematic-forum.de/forum/viewtopic.php?f=65&t=64392
Leider ohne Ergebnis.
Entschuldigung wenn ich das hier noch mal hoch hole. Da ich derzeit das gleiche Problem habe, wie ist das hier ausgegangen? Hast du dir inzwischen neue Rauchmelder gekauft? :D Oder gibt es andere Erkenntnisse? HM-LAN Adapter macht nämlich genau das gleiche. Ich werde mir jetzt aber mal eine CCU2 ausleihen und es damit versuchen.
Das war nicht lösbar mit dem HMLAND und HM-CFG-USB. Mir hat dann jemand einen https://github.com/stan23/myPCBs/tree/master/HB-MOD-UART-USB verkauft, den ich als zweiten Sender nur für die HM-SEC-SD-2 an der Raspberrymatic betreibe. Der Rest bleibt am HM-CFG-USB, weil der durch die freie Platzierung im LAN bei mir eine bessere Reichweite hat.
Vielen Dank für den Hinweis. Schade. Ich bin auch weiterhin erfolglos geblieben. UART USB klingt nicht schlecht. Da die Rauchmelder eigentlich sehr zuverlässig sind, möchte ich sie auch gerne behalten. Hatte bisher nur 'berechtigte' Alarme und keinen einzigen Fehlalarm.
Gruß
Robert
Ich kann es nun bestätigen - Anlernen über die CCU2 ist möglich. Nur HMLAN Config Adapter und vermutlich auch HMUSB ist anscheinend nicht möglich mit Raspberrymatic oder der Original Home Matic Software. Man benötigt zumindest eine CCU2 dafür. Oder eben fhem, damit ging es problemlos (merkwürdig). Da es für den HMLAN anscheinend keinen Support mehr gibt wird das Problem wohl eher ungelöst bleiben. Ich werde mir eine CCU2 besorgen und sie zum Gateway umbauen oder einen LAN Gateway. Hoffe das es dann funktioniert.
CCU2 als Gateway umbauen - Rauchmelder anlernen - alles perfekt. Zumindest eine Lösung. Merkwürdigerweise scheinen die Rauchmelder dann auch mit dem HM-LAN Adapter zu funktionieren :) Zumindest wenn man das Interface in Rasperrymatic entsprechend zuordnet bzw. die Zuordnung nicht statisch festlegt (roaming).