[gelöst] Repeater HM-Sys-sRP-Pl über AskSin++

petibub · 26 März 2022, 23:10:26

Hi!

Ich habe den Homematic Repeater HM-Sys-sRP-Pl mit dem Code von hier nachgebaut. Die Hardware läuft und er ist in meinem FHEM als HM_Repeater gepairt. Leider schaffe es nicht ihn richtig zu konfigurieren:

Code Auswählen

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:

Code Auswählen

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?

Otto123 · 27 März 2022, 00:50:10

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

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

petibub · 27 März 2022, 12:45:28

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 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

Otto123 · 27 März 2022, 14:21:09

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

petibub · 27 März 2022, 21:39:49

Lieber Otto,

es funktioniert tatsächlich mit VCCU. Allerdings habe, von hier inspiriert zwei Einträge pro Schalter gemacht:

Code Auswählen

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

.

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

frank · 27 März 2022, 22:14:51

zeig mal ein list vom device.

petibub · 27 März 2022, 22:25:53

Aber gerne:

Code Auswählen



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

frank · 28 März 2022, 10:21:33

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.

frank · 28 März 2022, 14:26:04

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):

Code Auswählen

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.

frank · 28 März 2022, 21:02:10

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

noansi · 29 März 2022, 22:48:36

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

Code Auswählen

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.

frank · 31 März 2022, 13:09:56

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.

noansi · 31 März 2022, 20:06:51

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.

Code Auswählen

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):

Code Auswählen

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.

noansi · 31 März 2022, 21:57:25

Hallo Martin, hallo Frank,

ich habe mal in HM_Config

Code Auswählen

 ,"0076" => {name=>"HM-SYS-SRP-PL"           ,st=>'repeater'          ,cyc=>''      ,rxt=>''       ,lst=>'p,1,2'        ,chn=>"",} # repeater

gesetzt, also Liste 1 ergänzt.
Ergebnis:

Code Auswählen

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:

Code Auswählen

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

Code Auswählen

D-firmware 1.2

Gruß, Ansgar.

frank · 01 April 2022, 12:20:58

hallo ansgar,

du kannst wohl gedanken lesen.

weitere ideen:

es gibt ja noch das register 0x17 in liste0 mit "spannendem" namen COMPATIBILITY_MODE)

Code Auswählen

  <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?):

Code Auswählen

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.

Code Auswählen

    <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.