Hi!
Ich habe den Homematic Repeater HM-Sys-sRP-Pl mit dem Code von hier (https://github.com/jp112sdl/Beispiel_AskSinPP/tree/master/examples/HM-Sys-sRP-Pl) nachgebaut. Die Hardware läuft und er ist in meinem FHEM als HM_Repeater gepairt. Leider schaffe es nicht ihn richtig zu konfigurieren:
set HM_Repeater setRepeat 1 SchuKo4 VCCU no
sollte die Steckdose SchuKo4 zum Repeaten hinzufügen. Leider reagiert die Steckdose nicht. Die zugehörigen Readings bleiben bei:
repPeer_01 FFFFFF unknown no fail .
Egal wie ich den Repeater konfiguriere, ich habe immer den oben gezeigten Status von repPeer_01. Ich habe auch den Kanal 2 konfiguriert, ich habe des öfteren getConfig probiert, und auch die Konfiguration über repPeers versucht - alles ohne Erfolg.
Läuft bei Jemanden der AskSin++ Repeater über FHEM?
Hat Jemand Tipps, was ich machen könnte?
Hi,
bist Du sicher, dass Du die VCCU nehmen musst?
https://wiki.fhem.de/wiki/HM-Sys-sRP-Pl_Funk-Zwischenstecker_Repeater
Ich hatte mal einen (https://forum.fhem.de/index.php?topic=69215.0) :) der Vorteil gegenüber einem IO im Zusammenspiel mit FHEM hat sich mir nie erschlossen.
Der macht doch nur auf dem "Feld" Sinn, wo eine Zentrale zwischen zwei Geräten nicht hinkommt?
Gruß Otto
Lieber Otto,
danke für deine schnelle Antwort!
Zitat von: Otto123 am 27 März 2022, 00:50:10
bist Du sicher, dass Du die VCCU nehmen musst?
https://wiki.fhem.de/wiki/HM-Sys-sRP-Pl_Funk-Zwischenstecker_Repeater
Meinst du ich soll statt VCCU direkt das Device nehmen, also bei mir HMUART (hängt als /dev/ttyUSB0 am RPI)?
Oder fragst du, ob ich überhaupt VCCU in meinem System brauche?
Zitat
Ich hatte mal einen (https://forum.fhem.de/index.php?topic=69215.0) :) der Vorteil gegenüber einem IO im Zusammenspiel mit FHEM hat sich mir nie erschlossen.
Der macht doch nur auf dem "Feld" Sinn, wo eine Zentrale zwischen zwei Geräten nicht hinkommt?
Ich habe Homematic Steckdosen im Garten, wo die externe Antenne auf lediglich RSSI < -85 dB kommt. Die Steckdosen schalten sehr unzuverlässig. Alle Lösungen über WLAN kommen leider auch nicht in Frage - selektiv das Signal für zwei Steckdosen zu verstärken war für mich das naheliegende. Früher hatte ich den Original Repeater, leider geht er nicht mehr.
Inzwischen habe ich herausgefunden, dass der AskSin++-Repeater, wenn am PC angeschlossen, die Register über COM Monitor ausgibt und somit kann ich auch die Konfiguration überprüfen. Ich habe nun tatsächlich geschafft Steckdosen zu schalten :). Habe aber noch nicht ganz verstanden aber wann es geht und wann nicht. Hat dazu Jemand Erfahrung (in FHEM funktionieren die Repeater-Readings leider nicht).
lG; Piotr
Hallo Piotr,
ich hatte das Teil nie in Betrieb. Mit Deiner VCCU ist erstmal alles gut. :)
Ich habe den Wiki Artikel so verstanden: Man trägt den wirklichen IO ein und nicht die VCCU.
Primär hatte ich das mal so verstanden: Reichweitenverlängerung von Gerät zu Gerät die miteinander gepeert sind!
peer1 - Repeater - peer2
Also peer1 kennt Repeater und Repeater kennt peer2 und peer1 kennt peer2
Ja, wenn ich jetzt drüber nachdenke, kann ein Gerät natürlich auch ein HM IO sein.
Ich habe bei mir in die kritischen Bereiche einfach einen weiteren IO per LAN gebracht.
Gruß Otto
Lieber Otto,
es funktioniert tatsächlich mit VCCU. Allerdings habe, von hier (https://forum.fhem.de/index.php/topic,26256.msg214045.html#msg214045) inspiriert zwei Einträge pro Schalter gemacht:
set HM_Repeater setRepeat 1 SchuKo4 VCCU no
set HM_Repeater setRepeat 2 VCCU SchuKo4 no
Ob das sinnvoll ist, weiß ich nicht, aber es funktioniert 8).
Schade nur, dass die Readings in FHEM nicht funktionieren - die Programmierung des Repeaters wird in den FHEM nicht übernommen. Das kann man wahrscheinlich nachprogrammieren, aber ich kenne mich zu wenig aus. Vielleicht liest Jemand mit, der sich besser auskennt als ich :-\. Für jeden Tipp bin ich dankbar...
lg; Piotr
zeig mal ein list vom device.
Aber gerne:
Internals:
DEF 007601
FUUID 623f8b75-f33f-d8d1-3759-8827ba49ecd7eda3
HMUART_MSGCNT 1
HMUART_RAWMSG 05010047398210007601123456060100004F
HMUART_RSSI -71
HMUART_TIME 2022-03-27 22:18:15
IODev HMUART
LASTInputDev HMUART
MSGCNT 1
NAME HM_Repeater
NR 433
NTFY_ORDER 48-HM_Repeater
STATE ok
TYPE CUL_HM
chanNo 01
disableNotifyFn 1
lastMsg No:39 - t:10 s:007601 d:123456 060100004F
peerList FFFFFFFF
protCmdDel 2
protLastRcv 2022-03-27 22:18:15
protRcv 1 last_at:2022-03-27 22:18:15
protResnd 6 last_at:2022-03-27 21:48:08
protResndFail 2 last_at:2022-03-27 21:48:14
protSnd 3 last_at:2022-03-27 22:18:15
protState CMDs_done
rssi_HMUART cnt:1 min:-79 max:-79 avg:-79 lst:-79
rssi_at_HMUART cnt:1 min:-71 max:-71 avg:-71 lst:-71
READINGS:
2022-03-27 12:17:24 CommandAccepted yes
2022-03-26 22:53:58 D-firmware 1.0
2022-03-26 22:53:58 D-serialNr PIOTR01
2022-03-27 22:18:15 IODev HMUART
2022-03-27 12:18:59 PairedTo 0x123456
2022-03-27 12:18:59 RegL_00. 00:00 0A:12 0B:34 0C:56 17:00
2022-03-27 12:19:27 RegL_02. 00:00 01:3A 02:B7 03:C3 04:12 05:34 06:56 07:00 08:12 09:34 0A:56 0B:3A 0C:B7 0D:C3 0E:00 0F:47 10:57 11:60 12:12 13:34 14:56 15:00 16:12 17:34 18:56 19:47 1A:57 1B:60 1C:00 1D:00 1E:00 1F:00 20:00 21:00 22:00 23:00 24:00 25:00 26:00 27:00 28:00 29:00 2A:00 2B:00 2C:00 2D:00 2E:00 2F:00 30:00 31:00 32:00 33:00 34:00 35:00 36:00 37:00 38:00 39:00 3A:00 3B:00 3C:00 3D:00 3E:00 3F:00 40:00 41:00 42:00 43:00 44:00 45:00 46:00 47:00 48:00 49:00 4A:00 4B:00 4C:00 4D:00 4E:00 4F:00 50:00 51:00 52:00 53:00 54:00 55:00 56:00 57:00 58:00 59:00 5A:00 5B:00 5C:00 5D:00 5E:00 5F:00 60:00 61:00 62:00 63:00 64:00 65:00 66:00 67:00 68:00 69:00 6A:00 6B:00 6C:00 6D:00 6E:00 6F:00 70:00 71:00 72:00 73:00 74:00 75:00 76:00 77:00 78:00 79:00 7A:00 7B:00 7C:00 7D:00 7E:00 7F:00 80:00 81:00 82:00 83:00 84:00 85:00 86:00 87:00 88:00 89:00 8A:00 8B:00 8C:00 8D:00 8E:00 8F:00 90:00 91:00 92:00 93:00 94:00 95:00 96:00 97:00 98:00 99:00 9A:00 9B:00 9C:00 9D:00 9E:00 9F:00 A0:00 A1:00 A2:00 A3:00 A4:00 A5:00 A6:00 A7:00 A8:00 A9:00 AA:00 AB:00 AC:00 AD:00 AE:00 AF:00 B0:00 B1:00 B2:00 B3:00 B4:00 B5:00 B6:00 B7:00 B8:00 B9:00 BA:00 BB:00 BC:00 BD:00 BE:00 BF:00 C0:00 C1:00 C2:00 C3:00 C4:00 C5:00 C6:00 C7:00 C8:00 C9:00 CA:00 CB:00 CC:00 CD:00 CE:00 CF:00 D0:00 D1:00 D2:00 D3:00 D4:00 D5:00 D6:00 D7:00 D8:00 D9:00 DA:00 DB:00 DC:00 DD:00 DE:00 DF:00 E0:00 E1:00 E2:00 E3:00 E4:00 E5:00 E6:00 E7:00 E8:00 E9:00 EA:00 EB:00 EC:00 ED:00 EE:00 EF:00 F0:00 F1:00 F2:00 F3:00 F4:00 F5:00 F6:00 F7:00 F8:00 F9:00 FA:00 FB:00 FC:00
2022-03-27 22:18:15 battery ok
2022-03-27 12:20:27 cfgState ok
2022-03-27 22:18:15 commState CMDs_done
2022-03-27 22:18:15 flags 0
2022-03-27 21:17:30 peerList FFFFFFFF
2022-03-26 22:54:05 powerOn 2022-03-26 22:54:05
2022-03-27 22:18:15 recentStateType info
2022-03-27 12:19:27 repPeer_01 FFFFFF dst>- no fail
2022-03-27 12:19:27 repPeer_02 undefined
2022-03-27 12:19:27 repPeer_03 undefined
2022-03-27 12:19:27 repPeer_04 undefined
2022-03-27 12:19:27 repPeer_05 undefined
2022-03-27 12:19:27 repPeer_06 undefined
2022-03-27 12:19:27 repPeer_07 undefined
2022-03-27 12:19:27 repPeer_08 undefined
2022-03-27 12:19:27 repPeer_09 undefined
2022-03-27 12:19:27 repPeer_10 undefined
2022-03-27 12:19:27 repPeer_11 undefined
2022-03-27 12:19:27 repPeer_12 undefined
2022-03-27 12:19:27 repPeer_13 undefined
2022-03-27 12:19:27 repPeer_14 undefined
2022-03-27 12:19:27 repPeer_15 undefined
2022-03-27 12:19:27 repPeer_16 undefined
2022-03-27 12:19:27 repPeer_17 undefined
2022-03-27 12:19:27 repPeer_18 undefined
2022-03-27 12:19:27 repPeer_19 undefined
2022-03-27 12:19:27 repPeer_20 undefined
2022-03-27 12:19:27 repPeer_21 undefined
2022-03-27 12:19:27 repPeer_22 undefined
2022-03-27 12:19:27 repPeer_23 undefined
2022-03-27 12:19:27 repPeer_24 undefined
2022-03-27 12:19:27 repPeer_25 undefined
2022-03-27 12:19:27 repPeer_26 undefined
2022-03-27 12:19:27 repPeer_27 undefined
2022-03-27 12:19:27 repPeer_28 undefined
2022-03-27 12:19:27 repPeer_29 undefined
2022-03-27 12:19:27 repPeer_30 undefined
2022-03-27 12:19:27 repPeer_31 undefined
2022-03-27 12:19:27 repPeer_32 undefined
2022-03-27 12:19:27 repPeer_33 undefined
2022-03-27 12:19:27 repPeer_34 undefined
2022-03-27 12:19:27 repPeer_35 undefined
2022-03-27 12:19:27 repPeer_36 undefined
2022-03-27 22:18:15 state ok
helper:
HM_CMDNR 57
cSnd 01123456007601010E,01123456007601010E
lastMsgTm 1648412295.52685
mId 0076
peerFriend
peerIDsState complete
peerOpt p:repeater
regLst 0,2
rxType 1
supp_Pair_Rep 0
cmds:
TmplKey FFFFFFFF:no:1648408650.39413
TmplTs 1648408650.39413
cmdKey 1:1:0::HM_Repeater:0076:01:FFFFFFFF
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-]
inhibit [(on|{off})]
peerBulk -peer1,peer2,...- [({set}|unset)]
peerSmart -peerOpt-
raw -data- [...]
regBulk -list-.-peerChn- -addr1:data1- [-addr2:data2-]...
regSet [(prep|{exec})] -regName- -value- [-peerChn-]
reset noArg
setRepeat -noX- -sendName- -recName- 'bdcast'(yes|no)
statusRequest noArg
tplDel -tplDel-
tplSet_0 -tplChan-
tplSet_FFFFFFFF -tplPeer-
unpair noArg
lst:
condition slider,0,1,255
peer FFFFFFFF
peerOpt remove_FFFFFFFF
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 0
newChn +007601,00,00,00
nextSend 1648412295.60753
rxt 0
vccu VCCU
p:
007601
00
00
00
prefIO:
HMUART
mRssi:
mNo 39
io:
HMUART:
-69
-69
peerIDsH:
00000000 broadcast
FFFFFFFF FFFFFFFF
prt:
bErr 0
sProc 0
tryMsg:
q:
qReqConf
qReqStat
role:
chn 1
dev 1
rssi:
HMUART:
avg -79
cnt 1
lst -79
max -79
min -79
at_HMUART:
avg -71
cnt 1
lst -71
max -71
min -71
tmpl:
Attributes:
IOgrp VCCU:HMUART
autoReadReg 4_reqStatus
expert rawReg
firmware 1.0
model HM-SYS-SRP-PL
peerIDs 00000000,FFFFFFFF
repPeers FFFFFF:-:n, , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , ,
room Unsorted
serialNr PIOTR01
subType repeater
webCmd getConfig:clear msgEvents
lg; Piotr
die repPeers werden ja sicherlich in registerliste 2 gespeichert.
schalte mal die register anzeige sichtbar: bei "attr expert" zusätzlich option allReg setzen.
eventuell anschliessend noch ein set getconfig.
poste dann noch ein aktuelles list.
die eq3 seriennummer hat ja immer 10 stellen, deine nicht. vermutlich ändert das aber nichts.
ich habe mal in 10_cul_hm.pm gestöbert und das forum nach "RegL_02" durchsucht.
scheinbar funktioniert dein homebrew device besser als das original.
nur in deiner RegL_02 sind die daten so zu sehen, wie eq3 sie im xml file vom repeater beschreibt (ADDRESS_SENDER, ADDRESS_RECEIVER, BROADCAST_BEHAVIOR):
00:00
01:3A 02:B7 03:C3 04:12 05:34 06:56 07:00 # SchuKo4 => VCCU no
08:12 09:34 0A:56 0B:3A 0C:B7 0D:C3 0E:00 # VCCU => SchuKo4 no
0F:47 10:57 11:60 12:12 13:34 14:56 15:00 # aktor2 => VCCU no
16:12 17:34 18:56 19:47 1A:57 1B:60 1C:00 # VCCU => aktor2 no
1D:00 1E:00 1F:00 20:00 21:00 22:00 23:00
24:00 25:00 26:00 27:00 28:00 29:00 2A:00
...
die readings werden in der funktion CUL_HM_repReadings gesetzt.
allerdings werden sie dort aus daten der eingelesenen peers (siehe attr peerIDs) geparst und nicht aus den daten der registerliste.
vermutlich wird beim original repeater keine korrekte liste 2 gesendet, sondern statt dessen "verstümmelte" daten in der peerlist ausgegeben.
entweder baut martin auch das parsen von liste2 ein, oder du baust in die fw die "defekte" peerliste ein.
sniffe doch mal ein getconfig vom repeater.
als workaround könntest du auch zb über notify das reading RegL_02. überwachen und ggf in eigene "lesbare" readings überführen.
dazu müsstest du allerdings nach folgender anweisung zunächst events für dieses reading aktivieren: https://forum.fhem.de/index.php/topic,112825.msg1184583.html#msg1184583 (https://forum.fhem.de/index.php/topic,112825.msg1184583.html#msg1184583)
Hallo Frank,
Zitatvermutlich wird beim original repeater keine korrekte liste 2 gesendet, sondern statt dessen "verstümmelte" daten in der peerlist ausgegeben.
Es ist etwas "kaputter" beim HM-SYS-SRP-PL.
Gesetzt wird über Liste 2. Auslesen geht über die peers.
In List 2 kommt nur
RegL_02. 00:00 08:00(was natürlich beim Setzen auch wieder die Systematik stört).
Daher muss man auch darauf achten, die Reps von 1 aufwärts durchgängig zu füllen, sonst fällt das Parsen der "peers" auf die Nase, da das Ende der Peers bei einem leeren Eintrag zwischendrin als Ende der peers interpretiert wird.
Gruß, Ansgar.
hallo ansgar,
so in etwa hatte ich code und forum auch verstanden.
theoretisch könnte man beim lesen von liste2 die bytes zählen und wenn man 36x7=252 bytes bekommt, zusätzlich 36 "echte" register readings (R-repPeer_xx) erzeugen.
verwundert bin ich noch vom peer=FFFFFFFF bei @petibub.
wenn der wirklich so gelesen wird, könnte man damit sogar die "fake" readings und das attr repPeers unterdrücken.
ZitatDaher muss man auch darauf achten, die Reps von 1 aufwärts durchgängig zu füllen, sonst fällt das Parsen der "peers" auf die Nase, da das Ende der Peers bei einem leeren Eintrag zwischendrin als Ende der peers interpretiert wird.
hast du einen original repeater?
nach dem code hätte ich gedacht, dass es eventuell auch mit "lücken" funktionieren könnte.
Hallo Frank,
Zitattheoretisch könnte man beim lesen von liste2 die bytes zählen und wenn man 36x7=252 bytes bekommt, zusätzlich 36 "echte" register readings (R-repPeer_xx) erzeugen.
Hier mal ein get config meines original HM-SYS-SRP-PL Repeaters 3991DE.
2022.03.29 20:35:10.198 4: TSCUL_send: CUNX_HM868 382964 As 10 9D A001 F11034 3991DE 00040000000000
2022.03.29 20:35:10.201 4: TSCUL_XmitDlyHM: CUNX_HM868 id:3991DE rtoms:2241
2022.03.29 20:35:10.234 4: TSCUL_Parse: CUNX_HM868 16111635 A F103 12862708 01 10 9D A001 F11034 3991DE 00040000000000 _CCAdly:4
2022.03.29 20:35:10.367 4: TSCUL_Parse: CUNX_HM868 16111764 A F101 12862856 00 14 9D A010 3991DE F11034 0202010AF10B100C3406A6 -34.5dB
2022.03.29 20:35:10.401 4: TSCUL_Write: CUNX_HM868 sending As0A9D8002F110343991DE00
2022.03.29 20:35:10.478 4: TSCUL_Parse: CUNX_HM868 16111880 A F103 12862952 01 0A 9D 8002 F11034 3991DE 00 _CCAdly:4 _dhmSt:96
2022.03.29 20:35:10.595 4: TSCUL_Parse: CUNX_HM868 16111997 A F101 12863096 00 0C 9E A010 3991DE F11034 030000 -35dB
2022.03.29 20:35:10.652 4: TSCUL_Write: CUNX_HM868 sending As0A9E8002F110343991DE00
2022.03.29 20:35:10.662 4: TSCUL_Write: CUNX_HM868 sending As0BAEA001F110343991DE0103
2022.03.29 20:35:10.667 4: TSCUL_send: CUNX_HM868 383433 As 0B AE A001 F11034 3991DE 0103
2022.03.29 20:35:10.669 4: TSCUL_XmitDlyHM: CUNX_HM868 id:3991DE rtoms:2240
2022.03.29 20:35:10.726 4: TSCUL_Parse: CUNX_HM868 16112129 A F103 12863192 01 0A 9E 8002 F11034 3991DE 00 _CCAdly:4 _dhmSt:96
2022.03.29 20:35:10.826 4: TSCUL_Parse: CUNX_HM868 16112229 A F103 12863288 01 0B AE A001 F11034 3991DE 0103 _CCAdly:4 _dhmSt:192
2022.03.29 20:35:10.949 4: TSCUL_Parse: CUNX_HM868 16112346 A F101 12863440 00 1A AE A010 3991DE F11034 012A133F0156C580012A133F0056C58000 -34.5dB
2022.03.29 20:35:11.010 4: TSCUL_Write: CUNX_HM868 sending As0AAE8002F110343991DE00
2022.03.29 20:35:11.064 4: TSCUL_Parse: CUNX_HM868 16112466 A F103 12863536 01 0A AE 8002 F11034 3991DE 00 _CCAdly:4 _dhmSt:96
2022.03.29 20:35:11.190 4: TSCUL_Parse: CUNX_HM868 16112592 A F101 12863688 00 16 AF A010 3991DE F11034 01F1103400F110340000000000 -34.5dB
2022.03.29 20:35:11.252 4: TSCUL_Write: CUNX_HM868 sending As0AAF8002F110343991DE00
2022.03.29 20:35:11.261 4: TSCUL_Write: CUNX_HM868 sending As10BFA001F110343991DE01040000000002
2022.03.29 20:35:11.266 4: TSCUL_send: CUNX_HM868 384033 As 10 BF A001 F11034 3991DE 01040000000002
2022.03.29 20:35:11.268 4: TSCUL_XmitDlyHM: CUNX_HM868 id:3991DE rtoms:2241
2022.03.29 20:35:11.328 4: TSCUL_Parse: CUNX_HM868 16112731 A F103 12863784 01 0A AF 8002 F11034 3991DE 00 _CCAdly:4 _dhmSt:96
2022.03.29 20:35:11.408 4: TSCUL_Parse: CUNX_HM868 16112811 A F103 12863880 01 10 BF A001 F11034 3991DE 01040000000002 _CCAdly:4 _dhmSt:192
2022.03.29 20:35:11.530 4: TSCUL_Parse: CUNX_HM868 16112927 A F101 12864024 00 0C BF A010 3991DE F11034 030800 -33.5dB
2022.03.29 20:35:11.554 4: TSCUL_Write: CUNX_HM868 sending As0ABF8002F110343991DE00
2022.03.29 20:35:11.643 4: TSCUL_Parse: CUNX_HM868 16113045 A F103 12864120 01 0A BF 8002 F11034 3991DE 00 _CCAdly:4 _dhmSt:96
2022.03.29 20:35:11.767 4: TSCUL_Parse: CUNX_HM868 16113169 A F101 12864264 00 0C C0 A010 3991DE F11034 030077 -33.5dB
2022.03.29 20:35:11.906 4: TSCUL_Write: CUNX_HM868 sending As0AC08002F110343991DE00
2022.03.29 20:35:11.928 4: TSCUL_Parse: CUNX_HM868 16113331 A F103 12864360 01 0A C0 8002 F11034 3991DE 00 _CCAdly:4 _dhmSt:96
repPeers 01 bis 06 sind gesetzt (Namen durch Ids ersetzt):
repPeer_01 2A133F dst>broadcast yes ok 2022-03-29 20:35:11
repPeer_02 56C580 dst>broadcast yes ok 2022-03-29 20:35:11
repPeer_03 2A133F dst>F11034 no ok 2022-03-29 20:35:11
repPeer_04 56C580 dst>F11034 no ok 2022-03-29 20:35:11
repPeer_05 F11034 dst>2A133F no ok 2022-03-29 20:35:11
repPeer_06 F11034 dst>56C580 no ok 2022-03-29 20:35:11
Die ausgelesenen Peers werden mit dem Attributinhalt repPeers abgeglichen, wobei "channel" 01 gesetztem broadcastflag entspricht. Ist das Attribut repPeers futsch ist die vollständige config futsch, da das jeweilige Ziel nicht geliefert wird.
Bytes zählen hilft also nichts bei den peers, da nicht die ganze Liste als peers geliefert wird.
Sollte Dir ein Trick auffallen oder bekannt sein, wie man Liste 2 zum Auslesen "freischalten" kann, immer her damit. ;-)
In meiner Sonderversion habe ich die Repeaterbehendlung bezüglich Setzen und Löschen von repPeers angepasst, um keine Lücken in der Befüllung aufkommen zu lassen.
So viel nur als Info für die Unterschiede zum homebrew, damit auch das original nutzbar bleibt (/wird). ;-)
Zitatverwundert bin ich noch vom peer=FFFFFFFF bei @petibub
eventuell 0xff = leeres Byte im EEPROM ? Oder Absicht? Das müsste jemand im Code des homebrew verifizieren, wenn es als Unterscheidungsmerkmal herhalten soll.
Allerdings gibt es schon eine modellabhängige Behandlung von Sonderfällen in CUL_HM, die sinnvollerweise anzustreben wäre.
Gruß, Ansgar.
Hallo Martin, hallo Frank,
ich habe mal in HM_Config
,"0076" => {name=>"HM-SYS-SRP-PL" ,st=>'repeater' ,cyc=>'' ,rxt=>'' ,lst=>'p,1,2' ,chn=>"",} # repeater
gesetzt, also Liste 1 ergänzt.
Ergebnis:
RegL_01. 00:00 08:00
RegL_02. 00:00 08:00
Dann habe ich den AES Key gesetzt, sowie sign auf on.
Setzten der repPeers geschieht nun mit AES und:
RegL_01. 00:00 08:01
RegL_02. 00:00 08:01
D.h. der original HM-SYS-SRP-PL liefert in Liste 2 fälschlicherweise Liste 1.
Aber mit der kleinen Änderung in HM_Config macht er AES, was er ja auch können soll. Der Repeater hat
D-firmware 1.2
Gruß, Ansgar.
hallo ansgar,
du kannst wohl gedanken lesen. ;)
weitere ideen:
es gibt ja noch das register 0x17 in liste0 mit "spannendem" namen COMPATIBILITY_MODE)
<paramset type="MASTER" id="repeater_dev_master">
<parameter id="COMPATIBILITY_MODE" operations="read,write">
<logical type="boolean" default="false" />
<physical type="integer" interface="config" list="0" index="23" size="0.1" />
</parameter>
</paramset>
ein vergleich der daten, die ich gefunden habe, zeigt einen weiteren eq3 bug beim lesen dieses registers (zufallsdaten?):
2015-11-22 23:56:31 RegL_00: 00:00 02:01 0A:26 0B:36 0C:65 A8:89 #moonsorrox (original fw 1.2)
2021-03-10 12:57:35 RegL_00. 00:00 02:01 0A:FF 0B:23 0C:45 23:BA #Gueco315 (original fw 1.2)
2022-03-29 20:35:10 RegL_00. 00:00 02:01 0A:F1 0B:10 0C:34 06:A6 #noansi (original fw 1.2)
2022-03-27 12:18:59 RegL_00. 00:00 0A:12 0B:34 0C:56 17:00 #petibub (homebrew fw 1.0)
ausserdem zeigt der repeater wie viele andere devices das "unbekannte" register 0x02.
beim pairen meines fensterkontaktes sec-sc mit debmatic war mir aufgefallen, das eq3 devices ggf sofort automatisch konfiguriert ohne zuvor die daten gelesen zu haben. beim sc wird zb immer register 02:01 in liste0 und register 08:01 in liste1 gesetzt.
denkbar wäre also eine spezielle basis konfiguration der 3 register 02/liste0, 17/liste0 und 08/liste1, bei der die bugs nicht auftreten/auffallen, da eq3 das device immer mit dieser konfiguration betreibt.
mit den erfahrungen vom sec-sc wäre am wahrscheinlichsten, dass 02:01/liste0 und 08:01/liste1 gesetzt werden (das hast du ja jetzt bereits). da der wert von register 17/liste0 unbekannt ist, würde ich dieses mal auf 0 und 1 setzen.
eine andere "schräge" idee wäre, dass das auslesen der peers die fw negativ beeinflusst. "echtes" peeren ist nach meinem verständnis des eq3 xml-files ja nicht vorgesehen.
<channel index="1" type="REPEATER">
<link_roles />
fhem liest ja erst die peers und danach dann die register von liste2.
ich würde mal das lesen der peers im code abschalten, dann den repeater eine weile stromlos schalten, und anschliessend die registerlisten auslesen.
Das 0x02 Register und die Firmware-Version lassen sich mit wenig Aufwand im Homebrew anpassen.
Das wird aber am Verhalten nichts ändern. Aber vielleicht funktioniert dann die Gegenseite dann besser.
Hallo Frank,
zum spannenden "Compatibility Mode" ist hier https://de.elv.com/forum/kompatibilitaetsmodus-2264 (https://de.elv.com/forum/kompatibilitaetsmodus-2264) zu lesen, dass damit wohl das LowBat Bit bei weitergeleiteten Nachrichten gelöscht werden kann.
Das wegen älterer Fernbedienungen, die beim Hören ihrer eigenen message mit lowBat Bit die rote Led wegen Fehlinterpretation leuchten lassen.
Gelesen wird Register 0x17 vom Repeater als Zufallswert.
2022.04.01 18:21:14.515 4: TSCUL_Parse: CUNX_HM868 15617672 A F101 11531272 00 14 EF A010 3991DE F11034 0202010AF10B100C34[b]18B0[/b] -32.5dB
2022.04.01 18:22:33.927 4: TSCUL_Parse: CUNX_HM868 15697076 A F101 11610408 00 14 27 A010 3991DE F11034 0202010AF10B100C34[b]B7D7[/b] -34dB
2022.04.01 18:22:42.386 4: TSCUL_Parse: CUNX_HM868 15705543 A F101 11618856 00 14 5C A010 3991DE F11034 0202010AF10B100C34[b]602C[/b] -35dB
2022.04.01 18:41:07.701 4: TSCUL_Parse: CUNX_HM868 00033613 A F101 12720160 00 14 33 A010 3991DE F11034 0202010AF10B100C34[b]1AB2[/b] -33.5dB
2022.04.01 18:41:20.999 4: TSCUL_Parse: CUNX_HM868 00046942 A F101 12733592 00 14 68 A010 3991DE F11034 0202010AF10B100C34[b]8C78[/b] -32dB
2022.04.01 18:41:33.533 4: TSCUL_Parse: CUNX_HM868 00059475 A F101 12746100 00 14 9D A010 3991DE F11034 0202010AF10B100C34[b]A16D[/b] -34dB
2022.04.01 18:41:48.582 4: TSCUL_Parse: CUNX_HM868 00074524 A F101 12761056 00 14 D2 A010 3991DE F11034 0202010AF10B100C34[b]3602[/b] -35.5dB
Also zufällige Registernummer und zufälliger Wert. Muss man also erst mal irgendwas draus machen, z.B. fix 0x17/0x00, damit man es anschließend regulär setzen kann. Netterweise ein vergleichbares Fehlverhalten, wie beim HM-MOD-RE-8 Firmware 1.2. :)
@Papa: Das Homebrew müsste die "peers" ebenso liefern, wie es der original Repeater tut. Also SourceID + Burst Bit für jeden gesetzten repPeers Eintrag.
Ansonsten müsste nach meinem CUL_HM Verständnis der Homebrew Repeater eine eigene Model Id bekommen und entsprechend anders in CUL_HM behandelt werden, damit das mit den Sonderbehandlungen im Rahmen bleibt.
Ich rechne mal nicht damit, dass eq3 die Bugs im original Repeater noch gerade biegt. Somit sind die Bugs leider "Normalverhalten". :(
Nebenbei, wie ist das Repeat Timing beim Homebrew Repeater. Ich hatte mal was um die 45ms für den Empfang einer wiederholten message gemessen. Das ist ebenfalls wichtig einzuhalten, damit auch eine Kommunikation stattfinden kann. Nur für das weiterleiten von broadcasts von z.B. Temperatursensoren spielt es keine Rolle.
Gruß, Ansgar.
Hallo Frank,
compMode kann ich nun setzen, freilich ohne es lesen zu können.
Keine Änderung bezüglich Liste 2, egal ob 0x17 = 00, 01 oder FE. :(
Zitatfhem liest ja erst die peers und danach dann die register von liste2.
ich würde mal das lesen der peers im code abschalten, dann den repeater eine weile stromlos schalten, und anschliessend die registerlisten auslesen.
Leider auch damit kein Erfolg. :(
Dafür muss übrigens nicht der Code geändert werden. In HMConfig reicht:
,"0076" => {name=>"HM-SYS-SRP-PL" ,st=>'repeater' ,cyc=>'' ,rxt=>'' ,lst=>'1,2,p' ,chn=>"",} # repeater
um erst die Listen 0, 1 und 2 zu lesen und dann erst die peers.
nur "zugehört":
2022.04.01 22:47:56.533 4: TSCUL_Parse: CUNX_HM868 14842479 A F001 10697880 00 0D 00 A410 3991DE F11034 06000000 -40.5dB
2022.04.01 22:47:56.666 4: TSCUL_Parse: CUNX_HM868 14842612 A F001 10698000 00 0A 00 8002 F11034 3991DE 00 -44.5dB
2022.04.01 22:47:58.786 4: TSCUL_Parse: CUNX_HM868 14844728 A F001 10700096 00 0E 01 A410 3991DE F11034 060100002A -36dB
2022.04.01 22:47:58.874 4: TSCUL_Parse: CUNX_HM868 14844820 A F001 10700212 00 0A 01 8002 F11034 3991DE 00 -44dB
2022.04.01 22:48:02.784 4: TSCUL_Parse: CUNX_HM868 14848730 A F001 10704012 00 10 02 A001 F11034 3991DE 00040000000000 -44dB
2022.04.01 22:48:02.891 4: TSCUL_Parse: CUNX_HM868 14848834 A F001 10704136 00 14 02 A010 3991DE F11034 0202010AF10B100C340000 -33.5dB
2022.04.01 22:48:03.007 4: TSCUL_Parse: CUNX_HM868 14848954 A F001 10704252 00 0A 02 8002 F11034 3991DE 00 -45dB
2022.04.01 22:48:03.052 4: TSCUL_Parse: CUNX_HM868 14848998 A F001 10704352 00 10 12 A001 F11034 3991DE 01040000000001 -44.5dB
2022.04.01 22:48:03.299 4: TSCUL_Parse: CUNX_HM868 14849244 A F001 10704620 00 10 12 A001 F11034 3991DE 01040000000001 -44.5dB
2022.04.01 22:48:03.420 4: TSCUL_Parse: CUNX_HM868 14849362 A F001 10704740 00 0C 12 A010 3991DE F11034 030801 -33dB
2022.04.01 22:48:03.531 4: TSCUL_Parse: CUNX_HM868 14849477 A F001 10704852 00 0A 12 8002 F11034 3991DE 00 -43.5dB
2022.04.01 22:48:03.653 4: TSCUL_Parse: CUNX_HM868 14849599 A F001 10704976 00 0C 13 A010 3991DE F11034 030000 -33.5dB
2022.04.01 22:48:03.771 4: TSCUL_Parse: CUNX_HM868 14849717 A F001 10705092 00 0A 13 8002 F11034 3991DE 00 -43.5dB
2022.04.01 22:48:03.872 4: TSCUL_Parse: CUNX_HM868 14849818 A F001 10705192 00 10 23 A001 F11034 3991DE 01040000000002 -44dB
2022.04.01 22:48:03.995 4: TSCUL_Parse: CUNX_HM868 14849937 A F001 10705312 00 0C 23 A010 3991DE F11034 030801 -33.5dB
2022.04.01 22:48:04.106 4: TSCUL_Parse: CUNX_HM868 14850051 A F001 10705424 00 0A 23 8002 F11034 3991DE 00 -43.5dB
2022.04.01 22:48:04.228 4: TSCUL_Parse: CUNX_HM868 14850174 A F001 10705548 00 0C 24 A010 3991DE F11034 03002A -35dB
2022.04.01 22:48:04.348 4: TSCUL_Parse: CUNX_HM868 14850294 A F001 10705664 00 0A 24 8002 F11034 3991DE 00 -44dB
2022.04.01 22:48:04.443 4: TSCUL_Parse: CUNX_HM868 14850389 A F001 10705764 00 0B 34 A001 F11034 3991DE 0103 -44dB
2022.04.01 22:48:04.583 4: TSCUL_Parse: CUNX_HM868 14850524 A F001 10705896 00 1A 34 A010 3991DE F11034 012A133F0156C58001F1103400F1103400 -34.5dB
2022.04.01 22:48:04.781 4: TSCUL_Parse: CUNX_HM868 14850727 A F001 10706008 00 0A 34 8002 F11034 3991DE 00 -43.5dB
2022.04.01 22:48:04.825 4: TSCUL_Parse: CUNX_HM868 14850771 A F001 10706132 00 0E 35 A010 3991DE F11034 0100000000 -33.5dB
2022.04.01 22:48:04.946 4: TSCUL_Parse: CUNX_HM868 14850892 A F001 10706248 00 0A 35 8002 F11034 3991DE 00 -44dB
Gruß, Ansgar.
Wow! Ich liebe die FHEM Community - Vielen Dank für die Unterstützung. Leider steige ich technisch aus, weil ich zu wenig vom Homematic Protokoll und seiner Anbindung in FHEM verstehe. Aber, dass ich die Information über die verbundenen Geräte in RegL_02 ablesen kann, das hilft mir schon viel weiter.
@Frank: soll ich noch ein "list" posten, oder hat sich das durch die Diskussion inzwischen erledigt?
@Papa: Firmware-Version kann ich ändern, aber beim 0x02 Register steig ich aus.
Dadurch, dass der Repeater nun läuft und ich notfalls aus RegL_02 die Konfiguration entziffern kann, ist mein Ziel erreicht. Danke Allen für die Unterstützung (und die AskSin++ Bibliothek :) ).
lg; Piotr
Hallo Piotr,
Du kannst mal im aktuellen 10_CUL_HM.pm nach Zeile 10289 also nach
sub CUL_HM_repReadings($) { # parse repeater
my ($hash)=@_;
folgenden Code ergänzen:
if (my $regl2 = ReadingsVal($hash->{NAME}, ($hash->{helper}{expert}{raw} ? '' : '.').'RegL_02.', undef)) {
if ($regl2 =~ m/00:00/s) { # list 2 complete?
my @regl2vals = split(/ /, $regl2);
if (int(@regl2vals) >= 253) { # complete list 2 from homebrew repeater (only!)
my @repPeers = ();
for my $rg (@regl2vals) { # interpret repPeers from list 2
next if (!$rg);
my ($idx, $val) = split(/:/, $rg);
next if ($idx eq '00');
$idx -= 1;
$val = hex($val);
my $p = int($idx / 7);
if (!defined($repPeers[$p])) {
my %rph = ( src => 0,
dst => 0,
brdcst => 0 );
$repPeers[$p] = \%rph;
}
my $b = $idx - $p*7;
if ($b < 3) { # source ID
$repPeers[$p]->{src} += $val << ($b*8);
}
elsif ($b < 6) { # destination ID
$repPeers[$p]->{dst} += $val << (($b-3)*8);
}
else { # broadcast flag
$repPeers[$p]->{brdcst} = $val;
}
}
$hash->{helper}{peerIDsRaw} = ''; # build peerIDsRaw from list 2
my $rpav = '';
for my $pr (@repPeers) {
$hash->{helper}{peerIDsRaw} .= sprintf(",%06X%02X", $pr->{src}, $pr->{brdcst});
$rpav .= $pr->{src} ? sprintf("%06X:%06X:", $pr->{src}, $pr->{dst}).($pr->{brdcst}?'y':'n').',' : ' ,';
}
$rpav =~ s/,$//;
$attr{$hash->{NAME}}->{repPeers} = $rpav; # set attr repPeers from list 2
$hash->{helper}{peerIDsRaw} .= ',00000000';
}
}
}
Damit sollten die repPeers nach einem getConfig angezeigt werden, sofern mir kein Gedankenfehler unterlaufen ist.
Gruß, Ansgar.
Alternativ kannst Du auch mal den anghängten Sketch testen. Ich habe mal die Version, das Register 0x02 und das Auslesen der Peers angepasst. Allerdings habe ich nur geprüft, dass der Code durch den Complier geht und nicht wirklich getestet.
Lieber papa,
es hat tatsächlich geholfen, die repPeer_XX werden jetzt von FHEM empfangen und dargestellt. Vielen Dank!
lg; Piotr
PS: Erst jetzt dazugekommen, weil es den Spannungsregler am Arduino zerrissen hat und ich erst eine robuste Ersatzlösung basteln musste. Jetzt läuft der Repeater als Insellösung von Solarzellen gespeist :).