Hallo zusammen,
bisher hatte ich 5 Heizkörperthermostate HM-CC-DN und einen Fensterkontakt HM-Sec-SC0, ohne VCCU an eine nanoCUL, problemlos im Betrieb. Dann habe ich eine VCCU angelegt. Bisher ging auch noch alles.
Dann habe ich 2 neue HM-CC-DNs und 2 HM-Sec-SC0s bekommen.
Seitdem habe ich immense Probleme. Alle 3 Fensterkontakte melden nicht richtig. Manchmal gar nicht, manchmal melden sie das Öffnen aber nicht mehr das Schließen. Die Heizkörperthermostate habe ich bis auf eines scheinbar wieder auf Spur. Das eine das nicht geht, ist aber ein "altes" welches die ganze Zeit funktionierte. "getConfig" und drücken des "Config Knopfes" (einen Config Button haben alle meine Geräte nicht - ich denke man muß anlernen startet?) bringt nichts, außer dass noch mehr Kommandos in der Warteschleife hängen. Neues Anlernen der Fensterkontakte funtkioniert auch nicht richtig, auch nicht nach Reset.
Bei den Heizkrperthermostaten waren die Channels Clima und ClimaTeam des jeweil mit dem Channel eines anderen gepeert...
Ich hoffe ich muß nur noch etwas warten, hoffe aber mir kann jemand helfen alles wieder auf Spur zu bekommen. Vielleicht habe ich auch irgendwo was falsch gemacht, das ganze HM System scheint sehr anfälig zu sein...?
Hier mal die protoEvents:
protoEvents send to devices done:
name :State |CmdPend |Snd |Resnd #CmdDel |ResndFail |Nack |IOerr
HM_60B7DE : - | - | - | - # - | - | - | -
HM_Badezimmer : done | - | 18 | 2 # - | - | - | -
HM_Esszimmer : done | - | 89 | 1 # - | - | 1 | -
HM_Flur : done | - | 9 | - # - | - | - | -
HM_Kinderzimmer : done | - | 7 | - # - | - | - | -
HM_Kueche : done | - | 19 | 2 # - | - | - | -
HM_Schlafzimmer : pending | 10 pending| 12 | 1 # - | - | - | -
HM_Wohnzimmer : done | - | 12 | 1 # - | - | - | -
essz_fenster : pending | 9 pending| - | - # - | - | - | -
schlfz_fensterkontakt : done | - | 7 | 1 # - | - | - | -
====================================================================================================================
sum 0 |19 |173 |8 #0 |0 |1 |0
CUL_HM queue length:0
requests pending
----------------
autoReadReg :
recent : none
status request : HM_60B7DE
autoReadReg wakeup : HM_68D467
status request wakeup:
autoReadTest : essz_fenster
IODevs:CUL_1:Initialized condition:-
Und configCheck:
configCheck done:
missing register list
essz_fenster: RegL_00.,RegL_01.
peer list incomplete. Use getConfig to read it.
incomplete: essz_fenster:
Hallo,
Alle Homematic Geräte haben einen "Knopf" der als Anlerntaste/Configtaster/Config Button/wie auch immer man das sonst noch nennen könnte.
Bei dem SCO ist es der kleine Knopf auf der Oberseite, der auch leuchtet wenn Daten übertragen werden. Bei dem SCO ist es wichtig diesen Taster zu drücken OHNE den Sensor auszulösen (auf oder zu machen)
Der SCO arbeitet mit AES, kann also sein, das die Meldung wirklich keiner empfängt solange er nicht angemeldet ist.
Gruß Otto
Hallo ,
also beim SC0 den Anlernknopf kurz drücken und bei den Thermostaten dann das Anlernen starten?
Angemeldet sind die SC0 ja, bis auf den in der Küche, der mag nicht mehr... trotzdem kommen die Meldungen nicht an.
Kann es sein, dass irgendein Stack oder Buffer o.ä. mittlerweile so voll gelaufen ist dass nichts mehr geht? Kann man da was ablöschen?
essz_fenster hat augenscheinlich ein Problem. Da fehlen Register.
Wenn die HM geräte an einer Zentrale angelernt sind (pairen), kannst Du sie nicht mehr ohne zutun der Zentrale untereinander anlernen(peeren)!
Zeigt doch mal ein list essz_fenster
Ich habe keinen CUL aber das hier sieht komisch aus:
ZitatIODevs:CUL_1:Initialized condition:-
Sieht bei mir so aus:
ZitatIODevs:HMLAN1:opened pending=0 condition:ok
HMUART1:opened condition:ok
ser2netUart:opened condition:ok
Zeig mal noch ein list von Deiner VCCU.
ZitatKann es sein, dass irgendein Stack oder Buffer o.ä. mittlerweile so voll gelaufen ist dass nichts mehr geht? Kann man da was ablöschen?
Du kannst beim Device set clear msgEvents machen. Damit verschwinden die alten CMDs pending. Generell müssen die CMDs aber abgearbeitet werden, bedeutet Datenübertragung und im Falle SCO Config Taster drücken.
Hier das list von essz_fenster:
Internals:
CFGFN
CUL_1_MSGCNT 1
CUL_1_RAWMSG A1A02840068D4670000001000C75045513035373536313680810101::-83.5:CUL_1
CUL_1_RSSI -83.5
CUL_1_TIME 2019-09-27 07:46:12
DEF 68D467
FUUID 5d8da224-f33f-47f9-8cf7-5e417626ab465844
IODev CUL_1
LASTInputDev CUL_1
MSGCNT 1
NAME essz_fenster
NOTIFYDEV global
NR 868
STATE ???
TYPE CUL_HM
chanNo 01
lastMsg No:02 - t:00 s:68D467 d:000000 1000C75045513035373536313680810101
protCmdPend 12 CMDs_pending
protLastRcv 2019-09-27 07:46:12
protRcv 2 last_at:2019-09-27 07:46:12
protState CMDs_pending
rssi_at_CUL_1 cnt:2 min:-83.5 max:-83.5 avg:-83.5 lst:-83.5
READINGS:
2019-09-27 07:46:12 Activity alive
2019-09-27 07:46:12 D-firmware 1.0
2019-09-27 07:46:12 D-serialNr PEQ0575616
2019-09-27 07:46:12 R-pairCentral set_0xF10000
cmdStack:
++A001F1000068D46700050000000000
++A001F1000068D467000802010AF10B000C00
++A001F1000068D4670006
++A001F1000068D46700040000000000
++A001F1000068D46701040000000001
++A001F1000068D4670103
++A001F1000068D46700040000000000
++A001F1000068D46701040000000001
++A001F1000068D4670103
++A001F1000068D46700040000000000
++A001F1000068D46701040000000001
++A001F1000068D4670103
helper:
HM_CMDNR 2
PONtest 1
getCfgList all
getCfgListNo ,4
mId 00C7
peerFriend peerAct,peerVirt
peerOpt 4:threeStateSensor
regLst 0,1,4p
rxType 28
supp_Pair_Rep 0
expert:
def 1
det 0
raw 1
tpl 0
io:
newChn +68D467,02,00,00
nextSend 1569563172.54166
prefIO
rxt 2
vccu
p:
68D467
00
00
00
mRssi:
mNo 02
io:
CUL_1:
-81.5
-81.5
prt:
bErr 0
sProc 2
q:
qReqConf
qReqStat
role:
chn 1
dev 1
rssi:
at_CUL_1:
avg -83.5
cnt 2
lst -83.5
max -83.5
min -83.5
shadowReg:
tmpl:
Attributes:
IODev CUL_1
IOgrp VCCU:CUL_1
actCycle 002:50
actStatus alive
alias Esszimmer Fensterkontakt
autoReadReg 4_reqStatus
devStateIcon on:fts_window_2w_open_lr off:fts_window_2w
expert 2_raw
firmware 1.0
group Fensterkontakte
icon hm-sec-win
model HM-SEC-SCO
room Steuerung->Hardware
serialNr PEQ0575616
subType threeStateSensor
und hier die vccu - braucht man die überhaupt? Hab das Gefühl die Probleme sind erst, seit ich die angelegt habe...
Internals:
CUL_1_MSGCNT 8
CUL_1_RAWMSG A0C05864168D45E0000000103C8::-79:CUL_1
CUL_1_RSSI -79
CUL_1_TIME 2019-09-27 09:38:31
DEF F10000
FUUID 5d81d90a-f33f-47f9-b63b-f9aa268e81107c24
IODev CUL_1
LASTInputDev CUL_1
MSGCNT 8
NAME VCCU
NOTIFYDEV global
NR 331
NTFY_ORDER 50-VCCU
STATE CUL_1:ok
TYPE CUL_HM
assignedIOs CUL_1
channel_01 VCCU_Btn1
channel_02 VCCU_Btn2
channel_03 VCCU_Btn3
READINGS:
2019-09-27 09:31:56 IOopen 1
2019-09-27 09:31:56 state CUL_1:ok
2019-09-27 09:38:31 unknown_68D45E received
helper:
HM_CMDNR 80
cfgChkResult No regs found for:
mId FFF0
peerFriend peerSens,peerAct
peerOpt -:virtual
regLst 0
rxType 1
ack:
expert:
def 1
det 0
raw 0
tpl 0
io:
prefIO
vccu
ioList:
CUL_1
mRssi:
mNo
prt:
bErr 0
sProc 0
q:
qReqConf
qReqStat
role:
dev 1
vrt 1
rssi:
shadowReg:
tmpl:
nb:
cnt 1
Attributes:
IODev CUL_1
IOList CUL_1
group Geräte
icon hue_bridge
model CCU-FHEM
modelForce CCU-FHEM
room Steuerung->Hardware
subType virtual
webCmd virtual:update
Das unknown recieved kommt vom Küchenfensterkontakt, der jetzt endlich sich gemeldet hat.
Zitatrssi_at_CUL_1 cnt:2 min:-83.5 max:-83.5 avg:-83.5 lst:-83.5
READINGS:
2019-09-27 07:46:12 R-pairCentral set_0xF10000
Der essz_fenster ist nicht fertig angelernt, bei R-pairCentral darf kein set_ stehen. Und er ist sehr weit weg. Ein rssi unterhalb -80 kann gehen, muss aber nicht. mit 83,5 liegst Du auf alle Fälle im Grenzbereich.
Der VCCU fehlt das attr IOgrp, sie sagt aber der IO sei ok. Wie gesagt, ich weiß nicht was bei ihm stehen muss.
Die Fensterkontakte SCO sind etwas zickig, da ist der CUL sicher auch kein guter IO. Hast Du die TS Firmwware drauf? Ist dringend zu empfehlen, oder besser ein richtiger Homematic IO.
Also die IOgrp hab ich eingetragen sollte denke ich auch "VCCU:CUL_1" sein oder?
Firmware auf dem CUL ist die:
V 1.26.02 a-culfw Build: 275 (2018-02-07_20-27-53) nanoCUL868 (F-Band: 868MHz)
Ich habe noch einen 2. CUL rumliegen (nicht angeschossen) da wäre die 1.67 culfw drauf.
Der essz_fenster ist etwa 5m entfernt, auf der selben Etage, ohne Türen oder Metallwände....
Nein nur IOgrp VCCU - aber das ist eh momentan nichts was mit deinem Problem zu tun hat. ;)
Frag mich nicht zur CUL Firmware, da kann ich Dich nur bitten Dich durchzulesen ;)
https://wiki.fhem.de/wiki/HomeMatic#FHEM_als_Zentrale
Ich weiß nur das CUL nicht so doll für Homematic ist.
ZitatDer essz_fenster ist etwa 5m entfernt, auf der selben Etage, ohne Türen oder Metallwände....
Dann ist aber generell was "kaputt" - solche Werte kenne ich nur bei Betonwänden dazwischen.
Versteh nicht, warum das aufeinmal nicht mehr klappt. Der Schlafzimmer Kontakt ist so viel weiter entfernt auf einem anderen Stockwerk und hatte funktioniert... Hab den Esszimmer kontakt neu angelegt als device, auch für die Küche steht trotzdem:
R-pairCentral: set_0xF10000
Schade, das Aufsteckmodul kann ich nicht nutzen, da ich da ein zigbee modul stecken habe...
es genügt in der regel nicht, den config button nur 1x zu drücken. besonders, wenn die kommunikation wegen schlechtem funk und schlechtem timing ständig abbricht.
wenn also beim device pending cmds anstehen, nach dem erlöschen der flackernden led erneut drücken.
und immer wiederholen bis alle cmds abgearbeitet sind.
eventuell das device zum anlernen und konfigurieren, erst einmal in die nähe des gateways bringen.
aes abschalten (sign=off) verbessert sicherlich auch die kommunikation, da deutlich weniger "gequatscht" werden muss.
Je öfter ich den Button drücke, desto mehr Commands sind in der Warteschleife...
ist der fk nun näher am gateway?
Ja, bin auch ein Stück weiter. Mittlerweile wieder am Fenster meldet er korrekt. Allerdings bringt configCheck:
PairedTo mismatch to IODev kueche_fensterkontakt paired:0x000000 IO attr: F10000.
Zum Pairing habe ich die VCCU mit HM_PairForSec genommen.
ZitatJa, bin auch ein Stück weiter.
nee, ganz am anfang. :)
das kommt, wenn man unnötiger weise resettet.
auch devices löschen ist kontraproduktiv.
Werd ich so schnell auch nicht mehr machen. Und missing RegLists interessieren mich erstmal auch nicht. Solange es funktioniert sollte man die Finger davon lassen.
Die Fensterkontakte werden eh nicht gepeert, die Steuerung übernimmt FHEM.
musst du wissen.
sag aber später nicht, dass der fk schon gepairt war.
Nein, der war definitv nicht gepairt. Er sollte an der VCCU angelernt werden, ist jetzt aber mit dem CUL_1 gepairt. Das gleiche gilt für den Esszimmer Kontakt. Der mittlerweile auch wieder läuft. Dieser meldet allerdings keinen PairTo missmatch.
Vielleicht mache ich mal unpair und nochmal neu. Bin aber eigenltich froh, dass es wieder läuft soweit.
Internals:
CFGFN
CUL_1_MSGCNT 101
CUL_1_RAWMSG A0CAE844168D45E000000017200::-81.5:CUL_1
CUL_1_RSSI -81.5
CUL_1_TIME 2019-09-27 11:23:09
DEF 68D45E
FUUID 5d8dcad0-f33f-47f9-370f-ee37a344955bb9a0
IODev CUL_1
LASTInputDev CUL_1
MSGCNT 101
NAME kueche_fensterkontakt
NOTIFYDEV global
NR 453
STATE closed
TYPE CUL_HM
chanNo 01
lastMsg No:AE - t:41 s:68D45E d:000000 017200
protCmdDel 41
protLastRcv 2019-09-27 11:23:09
protRcv 101 last_at:2019-09-27 11:23:09
protResnd 12 last_at:2019-09-27 11:13:22
protResndFail 4 last_at:2019-09-27 11:18:00
protSnd 51 last_at:2019-09-27 11:18:19
protState CMDs_done
rssi_at_CUL_1 cnt:102 min:-91 max:-52.5 avg:-72.87 lst:-81.5
READINGS:
2019-09-27 11:19:11 Activity alive
2019-09-27 11:19:11 D-firmware 1.0
2019-09-27 11:19:11 D-serialNr PEQ0575625
2019-09-27 11:18:18 PairedTo 0x000000
2019-09-27 10:55:28 R-cyclicInfoMsg on
2019-09-27 10:55:28 R-eventDlyTime 0 s
2019-09-27 11:18:18 R-pairCentral 0x000000
2019-09-27 10:55:28 R-sabotageMsg on
2019-09-27 11:04:55 R-sign on
2019-09-27 11:18:18 RegL_00. 00:00 02:00 09:01 0A:00 0B:00 0C:00 10:01 14:06
2019-09-27 11:18:19 RegL_01. 00:00 08:01 20:9C 21:00 30:06
2019-09-27 11:12:13 aesKeyNbr 00
2019-09-27 11:22:42 alive yes
2019-09-27 11:23:09 battery ok
2019-09-27 11:23:09 contact closed (to broadcast)
2019-09-27 11:22:42 recentStateType info
2019-09-27 11:22:42 sabotageError off
2019-09-27 11:23:09 state closed
2019-09-27 10:50:01 trigDst_broadcast noConfig
2019-09-27 11:23:09 trigger_cnt 114
helper:
HM_CMDNR 174
cSnd 01F1000068D45E01040000000001,01F1000068D45E0103
mId 00C7
peerFriend peerAct,peerVirt
peerIDsRaw ,00000000
peerOpt 4:threeStateSensor
regLst 0,1,4p
rxType 28
supp_Pair_Rep 0
expert:
def 1
det 0
raw 1
tpl 0
io:
newChn +68D45E,00,00,00
nextSend 1569576190.00575
prefIO
rxt 2
vccu CUL_1
p:
68D45E
00
00
00
mRssi:
mNo AE
io:
CUL_1:
-79.5
-79.5
prt:
bErr 0
sProc 0
rspWait:
q:
qReqConf
qReqStat
regCollect:
role:
chn 1
dev 1
rssi:
at_CUL_1:
avg -72.8774509803922
cnt 102
lst -81.5
max -52.5
min -91
shadowReg:
tmpl:
Attributes:
IODev CUL_1
IOgrp VCCU:CUL_1
actCycle 002:50
actStatus alive
alias Küche Fensterkontakt
autoReadReg 5_readMissing
devStateIcon open:fts_window_1wbb_open closed:fts_window_1w
expert 2_raw
firmware 1.0
group Fensterkontakte
icon hm-sec-win
model HM-SEC-SCO
peerIDs 00000000,
room Steuerung->Hardware
serialNr PEQ0575625
subType threeStateSensor
So nachdem ich dem Rat gefolgt bin und alle fk mal in die Nähe des Raspi gelegt hatte, sind die Missing RegisterList ziemlich verschwunden, bei einem fehlt noch was.
Allerdings bringen alle an der VCCU angelernten fk den PairedTo missmatch. Die IDs zeigen, dass die fk mit dem CUL gepairt sind, aber erwarten mit der VCCU gepairt zu sein.
Zum Anlernen habe ich aber definitv in der VCCU das
set hmPairForSec 60
gesetzt, nicht im CUL...
Funktionieren tut aber alles
ich denke, du solltest dich mal intensiv mit dem thema "pairen" beschäftigen. siehe wiki und einsteiger.pdf/homematic-anhang.
2019-09-27 11:18:18 R-pairCentral 0x000000
das bedeutet: nicht gepairt.
hast du überhaupt das perl modul für aes installiert?
libcrypt-rijndael-perl
Zitat von: frank am 27 September 2019, 10:26:48
aes abschalten (sign=off) verbessert sicherlich auch die kommunikation, da deutlich weniger "gequatscht" werden muss.
Aber das abschalten geht doch nur wenn er gepairt ist? Bei den SCO ist doch von Hause aus sign on.
ZitatJe öfter ich den Button drücke, desto mehr Commands sind in der Warteschleife...
@brown78 Das müssen weniger werden. Datenübertragung sieht man daran, das die LED hektisch blinkt. Wenn sie ruhig blinkt geht er nur in den Anlernmodus und wartet.
Und man darf den Kontakt nicht auslösen! Dann blinkt er auch hektisch, aber die Nachrichten werden offenbar verworfen. Danach muss man von vorn beginnen!
Und pairen erfordert 3 Dinge:
1. Ruhe
2. Ruhe
3. Ruhe
und kein löschen, kein reset usw...
Zitat von: brown78 am 27 September 2019, 10:17:02
Schade, das Aufsteckmodul kann ich nicht nutzen, da ich da ein zigbee modul stecken habe...
Faule Ausrede :)
Das "Aufsteckmodul" geht auch über USB, LAN, WLAN https://wiki.fhem.de/wiki/HM-MOD-RPI-PCB_HomeMatic_Funkmodul_f%C3%BCr_Raspberry_Pi
ZitatAber das abschalten geht doch nur wenn er gepairt ist? Bei den SCO ist doch von Hause aus sign on.
ja, logisch.
irgend wann wird es wohl mal klappen mit pairen, und dann sofort abschalten.
Und wie sollte ich die Dinger dann pairen? Ich setze die VCCU auf PairForSec 600 und drücke den Knopf am fk. Wenn nicht gepairt warum empfange ich dann die Signale, auch getConfig funktionierte vorhin...
Zitat von: Otto123 am 27 September 2019, 14:30:49
Faule Ausrede :)
Das "Aufsteckmodul" geht auch über USB, LAN, WLAN https://wiki.fhem.de/wiki/HM-MOD-RPI-PCB_HomeMatic_Funkmodul_f%C3%BCr_Raspberry_Pi
Wenn ich Mal Zeit hab befasse ich mich damit. Dank Kind und Meisterschule ist Zeit Mangelware ;D
Zitat von: frank am 27 September 2019, 14:07:13
ich denke, du solltest dich mal intensiv mit dem thema "pairen" beschäftigen. siehe wiki und einsteiger.pdf/homematic-anhang.
2019-09-27 11:18:18 R-pairCentral 0x000000
das bedeutet: nicht gepairt
hast du überhaupt das perl modul für aes installiert?
libcrypt-rijndael-perl
Jetzt ja
Zitat von: brown78 am 27 September 2019, 14:44:10
Und wie sollte ich die Dinger dann pairen? Ich setze die VCCU auf PairForSec 600 und drücke den Knopf am fk. Wenn nicht gepairt warum empfange ich dann die Signale, auch getConfig funktionierte vorhin...
empfangen kann "jeder" - steuern (konfigurieren) geht erst nach pairen.
Erstmal noch die Gretchenfrage:
Was sagt dies in der FHEM Kommandozeile
{qx(dpkg -s libcrypt-rijndael-perl)}Ich nehme immer set VCCU hmPairForSec 120
dann den Taster kurz drücken, nicht den Kontakt/Sensor auslösen
es muss hektisch blinkern
warten
nochmal Taster kurz drücken, nicht den Kontakt/Sensor auslösen
es muss hektisch blinkern - wenn es langsam blinkert ist die Übertragung abgeschlossen. Entweder nochmal kurz drücken blinken hört auf, oder warten bis blinken aufhört
Wenn Register fehlen:
set getConfig machen
dann den Taster kurz drücken, nicht den Kontakt/Sensor auslösen
es muss hektisch blinkern
warten
nochmal Taster kurz drücken, nicht den Kontakt/Sensor auslösen
es muss hektisch blinkern - wenn es langsam blinkert ist die Übertragung abgeschlossen. Entweder nochmal kurz drücken blinken hört auf, oder warten bis blinken aufhört
Ok, dann mach ich das dann Mal. Hektisch geblinkt haben die Dinger nicht. Orange geblinkt ca. 2x dann grün. Da dachte ich, cool gepairt....
Na dann nochmal alle abmontieren und richtig pairen.
Danke für eure geduldige Hilfe!
ZitatNa dann nochmal alle abmontieren und richtig pairen.
Warum? Da besteht die Gefahr, dass Du den Sensor auslöst ;) und den Klebstreifen bekommt man praktisch nicht ab, oder hast Du geschraubt?
Zitat von: Otto123 am 27 September 2019, 15:06:33
Warum? Da besteht die Gefahr, dass Du den Sensor auslöst ;) und den Klebstreifen bekommt man praktisch nicht ab, oder hast Du geschraubt?
Nein, hab schon andere Klebestreifen drann - brutal die originalen oder? Zwecks besserem Empfang hätte ich sie halt wieder abgenommen.
Zitat von: Otto123 am 27 September 2019, 14:58:48
empfangen kann "jeder" - steuern (konfigurieren) geht erst nach pairen.
Erstmal noch die Gretchenfrage:
Was sagt dies in der FHEM Kommandozeile
{qx(dpkg -s libcrypt-rijndael-perl)}
Ich nehme immer set VCCU hmPairForSec 120
dann den Taster kurz drücken, nicht den Kontakt/Sensor auslösen
es muss hektisch blinkern
warten
nochmal Taster kurz drücken, nicht den Kontakt/Sensor auslösen
es muss hektisch blinkern - wenn es langsam blinkert ist die Übertragung abgeschlossen. Entweder nochmal kurz drücken blinken hört auf, oder warten bis blinken aufhört
Wenn Register fehlen:
set getConfig machen
dann den Taster kurz drücken, nicht den Kontakt/Sensor auslösen
es muss hektisch blinkern
warten
nochmal Taster kurz drücken, nicht den Kontakt/Sensor auslösen
es muss hektisch blinkern - wenn es langsam blinkert ist die Übertragung abgeschlossen. Entweder nochmal kurz drücken blinken hört auf, oder warten bis blinken aufhört
Also, ich habe VCCU hmPairForSec 120 gemacht, dann den Button am fk gedrückt, blinkt einmal orange dann gleich grün. Button gedrückt, blinkt langsam. GetConfig, Button gedrückt, blinkt langsam. Beim 3. mal getConfig dann schnelleres Blinken. Alle Befehle abgearbeitet aber PairedTo 0x000000
Edit: Raspi Neustart hats gebracht!
Zitatbrutal die originalen oder?
Mein Tipp: "Seifenschneider" bzw. Zahnseide langes Stück, dazwischen gehen und den dünnen Schaumstoff auf "sägen", Dann den Kleber entfernen/abziehen/abrollen/radieren
???
{qx(dpkg -s libcrypt-rijndael-perl)} ???
Das mit pairedTo 0x000000 ist irgendein Zwischenzustand, da stimmt was nicht.
Zitat von: Otto123 am 27 September 2019, 15:20:40
Mein Tipp: "Seifenschneider" bzw. Zahnseide langes Stück, dazwischen gehen und den dünnen Schaumstoff auf "sägen", Dann den Kleber entfernen/abziehen/abrollen/radieren
??? {qx(dpkg -s libcrypt-rijndael-perl)} ???
Das mit pairedTo 0x000000 ist irgendein Zwischenzustand, da stimmt was nicht.
libcrypt-rijndael-perl hab ich gerade installiert, danach der Neustart und der erste fk konnte erfolgreich gepairt werden!
Package: libcrypt-rijndael-perl
Status: install ok installed
Priority: optional
Section: perl
Installed-Size: 50
Maintainer: Debian Perl Group <pkg-perl-maintainers@lists.alioth.debian.org>
Architecture: armhf
Source: libcrypt-rijndael-perl (1.13-1)
Version: 1.13-1+b2
Depends: perl (>= 5.24.1~rc3-3), perlapi-5.24.1, libc6 (>= 2.4)
Description: Perl module implementing the Rijndael algorithm
Crypt::Rijndael is a Perl module that provides an XS-based implementation of
the Advanced Encryption Standard (AES) algorithm Rijndael, designed by Joan
Daemen and Vincent Rijmen.
Homepage: https://metacpan.org/release/Crypt-Rijndael
Puh der Küchen fk ziert sich wie ein Zicklein am Milcheimer... Blinkt hektisch, dann rot.
aesCommToDev fail
hast du schon mal mit eigenen aes keys "gespielt"?
wenn nicht, mach mal einen werkreset am fk, wie in der bedienungsanleitung beschrieben. anschliessend pairen.
manchmal braucht es auch mehrere anläufe. aber zwischendurch nichts löschen, sondern "drüberpairen".
Zitat von: frank am 27 September 2019, 17:14:52
hast du schon mal mit eigenen aes keys "gespielt"?
wenn nicht, mach mal einen werkreset am fk, wie in der bedienungsanleitung beschrieben. anschliessend pairen.
manchmal braucht es auch mehrere anläufe. aber zwischendurch nichts löschen, sondern "drüberpairen".
Nein, gespielt mit aes keys hab ich noch nicht. Hab mehrere Anläufe versucht, auch mit Reset, ohne das device zu löschen. Manchmal blinkt es grün, dann steht bei PairTo und PairCentral set_0xF10000. Ein getConfig bringt dann nur wieder ein "Nack" und rotes quittieren.
Ich mache jetzt erstmal Feierabend. Ich danke Euch nochmals für Eure Hilfe!
Morgen werde ich es nach der Schule nochmal probieren, ansonsten versuche ich den fk umzutauschen.
Einen schönen Freitag Abend wünsche ich!
Also der eine fk will einfach nicht. Zum Thema TS-fw habe ich mal den Tread überflogen. So wie ich das verstanden habe, wird aus dem CUL dann auch eine neues device, muß man dann alle Gerät neu pairen?
Wäre schön wenn jemand mit Erfahrung mit dem flashen der TS-fw mir das etwas erklären könnte, vielen Dank schon mal.
Ich kann Dir nur das mit dem pairen erklären: Nein musst Du nicht.
Das Pairing hängt an der HMId der Zentrale (VCCU / IO) und ist im Gerät eingetragen. Wenn Du die HMId der Zentrale nicht änderst brauchst Du nicht neu pairen.
Eh Du Dir den Stress miit dem CUL machst, hol Dir doch lieber einen IO von Homematic. 20€ für das RPI Modul ::)
Gruß Otto
Zitat von: Otto123 am 28 September 2019, 13:36:39
Ich kann Dir nur das mit dem pairen erklären: Nein musst Du nicht.
Das Pairing hängt an der HMId der Zentrale (VCCU / IO) und ist im Gerät eingetragen. Wenn Du die HMId der Zentrale nicht änderst brauchst Du nicht neu pairen.
Eh Du Dir den Stress miit dem CUL machst, hol Dir doch lieber einen IO von Homematic. 20€ für das RPI Modul ::)
Gruß Otto
Gilt das auch für Geräte, die vor anlegen der VCCU schon angelegt waren?
Ok. ok ich schau mir das mit dem IO nochmal an ;D
Ich brauche quasi zusätzlich zum IO einen USB zu TTL Wandler CP2102, dann 4 Kontakte verlöten und gut ist?
Pairen bräuchte ich dann auch nichts, da Geräte in der VCCU gespeichert?
-Klingt machbar...
Die VCCU hat eine 6 stellige ID (System ID, Zentralen ID wie immer man sagen will)
diese ID bekommt der zugeordnete IO - der hat also die Gleiche.
Beim Pairen wird diese ID im Gerät (Aktor Sensor) gespeichert. Ab da reagiert das Gerät nur noch auf Befehle von dieser ID.
In der VCCU oder im IO ist nichts geheimnisvolles unsichtbares gespeichert. Die Konfiguration steht sichtbar in der Zentrale / FHEM.
Pairen brauchst Du nicht zusätzlich, aber: was bisher nicht gepairt ist, ist natürlich danach auch erstmal nicht gepairt :)
Ah ok, vielen Dank für die Erläuterung!
Das ist dann die hmID des CUL, die die beim define der VCCU angegeben wurde.
So, nachdem der letzte FK sich einfach nicht pairen lassen will, habe ich beim bekannten Händler für HM Bausätze angerufen und bekomme Ersatz geliefert.
Der HM-MOD mit USB Adapter ist auch bestellt und ne ordentliche Antenne dazu, da kann ich dann wieder ein bisschen basteln.
Eine schöne Woche Euch!