HM-SEC-SD-2 neu

[dokle]

Erstmal Dankeschön für die rege Beteiligung an meiner Herausforderung. 

Also vorweg, mir ist durchaus klar, dass es zu 99% Sinnvoll ist, einen echten Alarm nur am auslösenden Melder quittieren zu können.
Dennoch hatte ich die Hoffnung, dass es per Funk doch irgendwie möglich ist - notfalls werde ich den Taster am Melder halt Hardwareseitig angreifen müssen.

Die Lösung mit dem Besenstiel ist mir auch schon eingefallen, weshalb ich das meinem Vater erstmal als Übergangslösung angeraten hatte.
Eine weitere Minimierung des Dunstes scheidet aufgrund der baulichen Begebenheiten leider aus.

Vielleicht steckt ja jemand von Euch so tief im Funkprotokoll drin, dass es über ein modifiziertes Paket / raw message, o.ä. doch noch möglich wäre, eine Quittierung per Funk zu setzen?!

Die VDS Zertifizierung ist mir pers. egal. Der RM wäre an dem Ort ohnehin nicht gesetzl. vorgeschrieben, da kein Schlafraum o. Fluchtweg. Weil er trotzdem Sinnvoll ist, hängt er ja auch da. Als Feuerwehrmann hab ich jede Woche mind. zwei Einsätze aufgrund von RM-Fehlalarmen im privaten Bereich, so ganz vermeiden lassen sich die scheinbar Herstellerübergreifend also nicht - egal ob Baumarktmelder nach DIN EN 14604, oder Premiummelder mit zusätzlicher VDS, Kriwan, etc. Zertifizierung.

[MCh76]

Hallo zusammen,

ich verzweifle an der Einrichtung meiner drei HM-SEC-SD-2 in FHEM.
Ich bin den kompletten Thread durchgegangen, habe die verschiedenen WiKi Artikel studiert (auch zu VCUL) und scheitere immer nach dem pairen der SD mit der VCCU. Zunächst sieht es mit dem Pairing beim ersten SD gut aus, sobald ich allerdings statusRequest beim SD anfordere resultiert das ganze in MISSING ACK. Beim zweiten SD dagegen scheint nicht mal das initale Pairing an VCCU zu klappen.
Ich bin über jede Hilfe dankbar.

List auf CUL:

Code Auswählen Erweitern

Internals:
   CMDS       BbCFiAZNkGMKUYRTVWXefmLltux
   CUL1_MSGCNT 36
   CUL1_TIME  2018-01-16 19:23:07
   Clients    :CUL_HM:HMS:CUL_IR:STACKABLE_CC:TSSTACKED:STACKABLE:
   DEF        /dev/ttyACM0@38400 1234
   DeviceName /dev/ttyACM0@38400
   FD         10
   FHTID      1234
   NAME       CUL1
   NR         24
   NR_CMD_LAST_H 29
   PARTIAL   
   RAWMSG     A0DD8A61065ABDD123456060100002D
   RSSI       -51.5
   STATE      Initialized
   TYPE       CUL
   VERSION    V 1.66 CUL868
   initString X21
Ar
   owner_CCU  VCCU
   MatchList:
     1:CUL_HM   ^A....................
     8:HMS      ^810e04....(1|5|9).a001
     D:CUL_IR   ^I............
     H:STACKABLE_CC ^\*
     M:TSSTACKED ^\*
     N:STACKABLE ^\*
   READINGS:
     2017-11-20 22:02:10   ccconf          freq:868.300MHz bWidth:101KHz rAmpl:33dB sens:8dB
     2018-01-16 17:52:38   cmds             B b C F i A Z N k G M K U Y R T V W X e f m L l t u x
     2018-01-16 19:13:03   raw             is000FFFFF0FF0
     2018-01-16 19:23:07   state           Initialized
   XMIT_TIME:
     1516124080.06869
     1516124086.04581
     1516124086.573
     1516124086.66725
     1516124086.85075
     1516124765.36176
     1516124771.25142
     1516124771.76676
     1516124925.7172
     1516124926.08047
     1516124926.25627
     1516124926.52065
     1516124926.77993
     1516124927.04118
     1516126680.35391
     1516126685.75902
     1516126918.12676
     1516126918.37897
     1516126918.63995
     1516126918.9019
     1516126919.16226
     1516126919.42329
     1516126987.44391
     1516127220.68055
     1516127223.73714
     1516127230.1936
     1516127233.98853
     1516127282.81266
     1516127288.66573
   helper:
     64C6DD:
       QUEUE:
     65ABDD:
       QUEUE:
Attributes:
   hmId       123456
   icon       cul_cul
   rfmode     HomeMatic
   room       90_Homematic,99_Geraete

List auf VCCU:

Code Auswählen Erweitern

Internals:
   CUL1_MSGCNT 5
   CUL1_RAWMSG A0C89867020DCB7000000002858::-101:CUL1
   CUL1_RSSI  -101
   CUL1_TIME  2018-01-16 18:42:15
   DEF        123456
   IODev      CUL1
   LASTInputDev CUL1
   MSGCNT     5
   NAME       VCCU
   NOTIFYDEV  global
   NR         59
   NTFY_ORDER 50-VCCU
   STATE      CUL1:ok,
   TYPE       CUL_HM
   assignedIOs CUL1
   protState  Info_Cleared
   READINGS:
     2018-01-16 18:42:15   unknown_20DCB7  received
   helper:
     HM_CMDNR   34
     mId        FFF0
     regLst     ,0
     rxType     1
     ack:
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     io:
       prefIO     
       vccu       
       ioList:
         CUL1
     mRssi:
       mNo       
     prt:
       bErr       0
       sProc      0
       rspWait:
     q:
       qReqConf   
       qReqStat   
     role:
       chn        1
       dev        1
       vrt        1
Attributes:
   IODev      CUL1
   IOList     CUL1
   expert     2_defReg+raw
   model      CCU-FHEM
   room       90_Homematic
   subType    virtual
   webCmd     virtual:update

List auf SD:

Code Auswählen Erweitern

Internals:
   CFGFN     
   CUL1_MSGCNT 15
   CUL1_RAWMSG A0EB6A61064C6DD123456060100002A::-49.5:CUL1
   CUL1_RSSI  -49.5
   CUL1_TIME  2018-01-16 18:46:11
   DEF        64C6DD
   IODev      CUL1
   LASTInputDev CUL1
   MSGCNT     15
   NAME       HM_64C6DD
   NOTIFYDEV  global
   NR         128
   STATE      MISSING ACK
   TYPE       CUL_HM
   lastMsg    No:B6 - t:10 s:64C6DD d:123456 060100002A
   protCmdDel 6
   protLastRcv 2018-01-16 18:46:11
   protResnd  8 last_at:2018-01-16 19:28:08
   protResndFail 6 last_at:2018-01-16 19:28:13
   protSnd    25 last_at:2018-01-16 19:28:02
   protState  CMDs_done_Errors:1
   rssi_CUL1  cnt:1 lst:-42 min:-42 avg:-42 max:-42
   rssi_at_CUL1 cnt:15 lst:-49.5 avg:-47.6 min:-53 max:-44
   READINGS:
     2018-01-16 18:05:48   Activity        alive
     2018-01-16 18:05:44   CommandAccepted yes
     2018-01-16 18:05:43   D-firmware      1.0
     2018-01-16 18:05:43   D-serialNr      OEQ2013449
     2018-01-16 18:34:46   PairedTo        0x123456
     2018-01-16 18:05:47   R-pairCentral   0x123456
     2018-01-16 18:34:46   RegL_00.          02:01 0A:99 0B:18 0C:93 16:00 1F:00 00:00
     2018-01-16 18:05:44   aesCommToDev    ok
     2018-01-16 18:05:44   aesKeyNbr       00
     2018-01-16 18:46:11   alarmTest       ok
     2018-01-16 18:46:11   battery         ok
     2018-01-16 18:46:11   level           0
     2018-01-16 18:46:11   recentStateType info
     2018-01-16 18:34:46   sdRepeat        off
     2018-01-16 18:46:11   smokeChamber    ok
     2018-01-16 19:28:13   state           MISSING ACK
   helper:
     HM_CMDNR   184
     cSnd       0112345664C6DD010E,0112345664C6DD010E
     mId        00AA
     peerIDsRaw ,00000000
     regLst     ,0
     rxType     6
     supp_Pair_Rep 0
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     io:
       newChn     +64C6DD,00,00,00
       nextSend   1516124771.86082
       prefIO     
       rxt        0
       vccu       
       p:
         64C6DD
         00
         00
         00
     mRssi:
       mNo        B6
       io:
         CUL1       -47.5
     prt:
       bErr       0
       sProc      0
       helper:
         prt:
           rspWait:
     q:
       qReqConf   
       qReqStat   
     role:
       chn        1
       dev        1
     rpt:
       IO         CUL1
       flg        A
       ts         1516124771.76631
       ack:
         HASH(0x26023b8)
         B6800212345664C6DD00
     rssi:
       CUL1:
         avg        -42
         cnt        1
         lst        -42
         max        -42
         min        -42
       at_CUL1:
         avg        -47.6
         cnt        15
         lst        -49.5
         max        -44
         min        -53
     shadowReg:
Attributes:
   IODev      CUL1
   IOgrp      VCCU:CUL1
   actCycle   099:00
   actStatus  alive
   autoReadReg 4_reqStatus
   expert     2_raw
   firmware   1.0
   model      HM-SEC-SD-2
   msgRepeat  1
   peerIDs    00000000,
   room       CUL_HM
   serialNr   OEQ2013449
   subType    smokeDetector
   webCmd     statusRequest

List auf SD2:

Code Auswählen Erweitern


Internals:
   CFGFN     
   CUL1_MSGCNT 16
   CUL1_RAWMSG A0DD8A61065ABDD12345606010000::-51.5:CUL1
   CUL1_RSSI  -51.5
   CUL1_TIME  2018-01-16 19:23:07
   DEF        65ABDD
   IODev      CUL1
   LASTInputDev CUL1
   MSGCNT     16
   NAME       HM_65ABDD
   NOTIFYDEV  global
   NR         237
   STATE      MISSING ACK
   TYPE       CUL_HM
   lastMsg    No:D8 - t:10 s:65ABDD d:123456 06010000
   protCmdDel 3
   protLastRcv 2018-01-16 19:23:07
   protResnd  3 last_at:2018-01-16 19:42:10
   protResndFail 3 last_at:2018-01-16 19:42:14
   protSnd    16 last_at:2018-01-16 19:42:04
   protState  CMDs_done_Errors:1
   rssi_at_CUL1 cnt:16 lst:-51.5 avg:-50.03 min:-53.5 max:-43.5
   READINGS:
     2018-01-16 19:21:58   Activity        alive
     2018-01-16 19:21:59   CommandAccepted yes
     2018-01-16 19:21:58   D-firmware      1.0
     2018-01-16 19:21:58   D-serialNr      OEQ2014225
     2018-01-16 18:48:45   R-pairCentral   set_0x123456
     2018-01-16 19:21:59   aesCommToDev    ok
     2018-01-16 19:21:59   aesKeyNbr       00
     2018-01-16 19:23:07   alarmTest       ok
     2018-01-16 19:23:07   battery         ok
     2018-01-16 19:23:07   level           0
     2018-01-16 19:23:07   recentStateType info
     2018-01-16 19:21:58   sdRepeat        invalid
     2018-01-16 19:23:07   smokeChamber    ok
     2018-01-16 19:42:14   state           MISSING ACK
   helper:
     HM_CMDNR   218
     cSnd       0112345665ABDD010E,0112345665ABDD010E
     mId        00AA
     regLst     ,0
     rxType     6
     supp_Pair_Rep 0
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     io:
       newChn     +65ABDD,00,00,00
       nextSend   1516126987.53835
       prefIO     
       rxt        0
       vccu       
       p:
         65ABDD
         00
         00
         00
     mRssi:
       mNo        D8
       io:
         CUL1       -49.5
     prt:
       bErr       0
       sProc      0
       helper:
         prt:
           rspWait:
     q:
       qReqConf   00
       qReqStat   
     role:
       chn        1
       dev        1
     rpt:
       IO         CUL1
       flg        A
       ts         1516126987.44331
       ack:
         HASH(0x36ca748)
         D8800212345665ABDD00
     rssi:
       at_CUL1:
         avg        -50.03125
         cnt        16
         lst        -51.5
         max        -43.5
         min        -53.5
     shadowReg:
       RegL_00.    02:01 0A:99 0B:18 0C:93
Attributes:
   IODev      CUL1
   IOgrp      VCCU:CUL1
   actCycle   099:00
   actStatus  alive
   autoReadReg 4_reqStatus
   expert     2_raw
   firmware   1.0
   model      HM-SEC-SD-2
   msgRepeat  1
   room       CUL_HM
   serialNr   OEQ2014225
   subType    smokeDetector
   webCmd     statusRequest


Und noch eine Frage:
In welchem Abstand kommunizieren die SD denn wenn alles klappt mit der VCCU? Werden da ab und an die Readings der SD aktualisiert, auch wenn kein "Alarm" herrscht?

Danke,
Chris

[Otto123]

Hallo Chris,

ich würde zunächst den CUL als Ursache vermuten. Muss aber nicht richtig sein.
https://wiki.fhem.de/wiki/HomeMatic#FHEM_als_Zentrale

Hast Du den CUL exklusiv für Homematic?

Gruß Otto

[MCh76]

Hallo Otto,
danke für deine Idee und den Link.

Was genau meinst du mit "Hast du den CUL exclusiv für Homematic"?
Ich steuere damit halt noch diverse Funksteckdosen, hab eine HomeKit Integration gemacht im FHEM etc...

Ich bin wirklich verzweifelt. Das initiale Pairing funktioniert, das weist auch das entsprechende Reading aus.
Ich habe nun auch noch der VCCU einen hmKey verpasst und den drei SD's diesen Key assigned.

Sobald ich einen status Request auf die SD ausführe zeigt es in den Readings das Pairing nicht mehr an.

Das HMInfo liefert in der Config Check noch folgendes:

Code Auswählen Erweitern


configCheck done:

missing register list
    HM_64C6DD: RegL_00.
    HM_65ABDD: RegL_00.
    HM_65AEBC: RegL_00.

Register changes pending
    HM_64C6DD
    HM_65ABDD
    HM_65AEBC

peer list incomplete. Use getConfig to read it.
    incomplete: HM_64C6DD:
    incomplete: HM_65AEBC:

peering strange - likely not suitable
    HM_65ABDD not peered!! add SD to any team !!




Die weiteren geplanten Schritte wie virtueller Team Lead brauche ich ja dann sicher erst gar nicht anzugehen.

Gibt es noch irgendwelche Tipps zur Fehlersuche? Leider ist das ganze VCCU/Homematic Thema noch relatives Neuland für mich.

VG,
Chris

[pc1246]

Moin Chris
Was Otto meint, ist ob Du den CUL noch fuer etwas anderes benutzt. Ein CUL ist wohl mit manchen Homematic Geraeten problematisch, und der SD2 gehoert dazu. Das Umschalten tut dann sein uebriges, wenn man Ihn fuer mehrere Protokolle nutzt.
Entscheidend ist aber auch Geduld beim Pairen, das "set_0x123456" weist darauf hin, dass Du nicht ordentlich gepairt hast. Wenn Du dann auch noch anfaengst weitere Schritte zu machen, wie Keys zu vergeben wirst du irgendwann verzweifeln!
Also mach in Ruhe Eins nach dem Anderen, und denke mal ueber eine andere FW fuer den CUL nach. Es gibt wohl inzwischen mehrere Alternativen!
Gruss Christoph

[MCh76]

Bzgl. Verwendung der CUL für was anderes:
Ich steuere eben ein paar IT-Funksteckdosen, HUE, Harmony-Hub und meine Somfy Markise mit der CUL.

Dazu noch folgende Fragen:
1. )So wie ich Otto und Christoph nun aber verstanden habe, wäre statt der jetzigen CUL für die ganze Homematic Steuerung besser noch
ein "HM-MOD-RPI-PCB HomeMatic Funkmodul für Raspberry_Pi" auf den Raspi aufzustecken und dann alle HM Komponenten auf dieses Device anzulernen?
Liege ich da richtig?

2.) wenn ich das "HM-MOD-RPI-PCB HomeMatic Funkmodul für Raspberry_Pi" eingerichet habe, sollte dann meine bisherige CUL1 auf einen anderen Modus gestellt werden, oder
kann die die im HM bleiben?

3.) wenn ich jetzt einen GetConfig auf die SD durchführe, dann zeigt es mir in den Readings für alle 3 SD ein "paired to" an. Allerdings führt dann scheinbar jeder anschließende
"statusRequest" zu einem Zufallsergebnis...In 60% der Fälle endet der Request allerdings in einem "MISSING ACK". Irgendwie ist das doch seltsam, an der Entfernung der SD zur CUL kann es eigentlich nicht liegen, "bastele" momentan innerhalb eines Raumes und auf einem Abstand von ca. 2,5 metern zwischen SD auf Schreibtisch und CUL.

4.) noch eine Frage zum virtuellen Team und der WiKi Beschreibung:

Code Auswählen Erweitern

Erzeugen eines virtuellen TeamLeads könnte so aussehen:

define TeamDev CUL_HM 111111
set TeamDev virtual 1
rename TeamDev_Btn1 Rauchmelder_Team

Bitte beachten: die HMID muss für die gesamte Installation einmalig sein.

a ) Die "111111" als HMID ist abweichend zu der der VCCU zu wählen nehme ich an?
b) Wofür steht "TeamDev_Btn1" bzw. gibt es auch ein "TeamDev_Btn2" für neue Teams? oder legt man dann ein neues TeamDEV an?

Nochmals vielen Dank für Eure Antworten/Ideen!
VG,
Chris

[pc1246]

Wow
So viele Fragen und so viele interessante Sachen.
Du kannst mit Deinem CUL HUE und Harmony Hub steuern? Schau dir mal IODev an, dann siehst du wer der jeweilige "Chef" ist!
1: Grundsaetzlich koennte man das mit einem ja beantworten. Mache ich aber nicht, da Du Dich so auf einenRPI festlegst. Mit einem Wemos-D1 oder NodeMCU und dem selben Modul bist du flexibler und kannst es auch noch guenstiger positionieren!
2: Ja. Ok war eine Oder Frage, laesst sich aber trotzdem mit Ja beantworten. Da Du ja eine VCCU hast, koennte der CUL so bleiben, Du muesstest dann nur die RM fest ((preferred IO) dem HM-MOD zuordnen. Da es noch andere Devices gibt, die Probleme haben, ist es fraglich ob es Sinn macht. Zudem willst Du ja Somfy und IT mit fdem CUL machen.
3: Du kannst die CUL Problematik nicht wegdiskutieren. Und ich weiss jetzt gar nicht ob meine da nicht auch ab und an mal rummuckeln. Ich werde das Gefuehl nicht los, das die RM sehr gespraechig sind, und irgendwann Ihre Sendegrenze erreicht haben. Insbesondere wenn Du jetzt die ganze Zeit mit denen rummachst.
4:
a: Das ist richtig. Du musst dem Teamlead eine eindeutige HM-ID in Deiner Umgebung verpassen, da es fuer HM ein echtes Mitglied ist!
b: Virtuelle Devices haben mehrere (40?) BTNs. Ist bei der VCCU ganz gut erklaert, wenn ich mich recht erinnere!
Gruss Christoph

[MCh76]

Vielen Dank für die ausführlichen Erklärungen, Namensvetter

zu Punkt 3.)
ich bin aktuell einfach unsicher was ich machen soll (alles über CUL oder doch zusätzliches HM-MOD-RPI-PCB).
Die RM sind eigentlich mein Homematic-"Pilot", habe evtl. vor noch weitere HM Komponenten in FHEM einzubinden und möchte dabei herausfinden
ob alles so tut wie es soll. aktuell fällt es mir als Newbie extrem schwer einzuschätzen, ob jetzt alles so tut wie es soll.
Wann hast du denn für dich entschieden, dass die Anbindung der RM passt? wenn ein Test-Alarm korrekt ankommt im FHEM?

[M_I_B]

... also aus meiner Erfahrung sind die RM von Haus aus zickig. Ich will mich aber auch nicht so weit aus dem Fenster lehnen, da ich mich auch noch zu den Anfängern zähle. Aber eines ist gewiss: Einen einzigen Transceiver für verschieden Protokolle und zudem auf verschiedenen Frequenzbereichen zu nutzen, ist eine doofe Idee... Zum einen empfängt der ja i.d.R. nur das Protokoll, auf das er im Define festgelegt wurde, zum anderen sind die Antennen von CUL & Co nicht dafür ausgelegt, auf 433MHz UND 868MHz zu arbeiten. Das geht zwar, wenn man die Antennen selber baut (1/4 Lambda Groundplane für 433MHz passt fast genau als 1/2 Lambda für 868MHZ), aber nur dann.
Ich habe hier 3 SCC (IT=433, HM=868, MAX=868) und zusätzlich noch ein HM-LAN-Gateway (das alte "UFO"). Und obwohl hier alles sauber nach Frequenzen und Proto getrennt ist, tauchen noch genug "Merkwürdigkeiten" auf.

... aber das ist nur meine unmaßgebliche Einschätzung ...

[Otto123]

b) Wofür steht "TeamDev_Btn1" bzw. gibt es auch ein "TeamDev_Btn2" für neue Teams? oder legt man dann ein neues TeamDEV an?

Hallo Chris,

ich glaube das andere ist alles beantwortet.
Der TeamDev Lead muss die Nummer 01 haben!!! Also wenn Du mehrere haben willst musst Du noch einen TeamDev anlegen, Btn2 geht nicht!

Gruß Otto

[MCh76]

... also aus meiner Erfahrung sind die RM von Haus aus zickig. Ich will mich aber auch nicht so weit aus dem Fenster lehnen, da ich mich auch noch zu den Anfängern zähle. Aber eines ist gewiss: Einen einzigen Transceiver für verschieden Protokolle und zudem auf verschiedenen Frequenzbereichen zu nutzen, ist eine doofe Idee... Zum einen empfängt der ja i.d.R. nur das Protokoll, auf das er im Define festgelegt wurde, zum anderen sind die Antennen von CUL & Co nicht dafür ausgelegt, auf 433MHz UND 868MHz zu arbeiten. Das geht zwar, wenn man die Antennen selber baut (1/4 Lambda Groundplane für 433MHz passt fast genau als 1/2 Lambda für 868MHZ), aber nur dann.
Ich habe hier 3 SCC (IT=433, HM=868, MAX=868) und zusätzlich noch ein HM-LAN-Gateway (das alte "UFO"). Und obwohl hier alles sauber nach Frequenzen und Proto getrennt ist, tauchen noch genug "Merkwürdigkeiten" auf.

... aber das ist nur meine unmaßgebliche Einschätzung ...

vielen Dank für die Infos Micha.
Wie hast du denn deine 3 SCC hardwaretechnisch verteilt? gerade bei allem was extern vom Raspi ist (wie bei Wemos-D1 oder NodeMCU) frage ich mich auch immer, wo das an sinnvollsten über die Wohnung/Haus hinweg platziert wird, in welchem Gehäuse untergebracht und über welche Quelle die USB-Stromversorgung erfolgt. Bin hier am Ideen sammeln.

[M_I_B]

... die drei SCC's sitzen alle auf einem alten PI2, der lediglich eine Minimalversion von Debian Lite drauf hat. Der hat nis weiter zu tun, als per WLAN die Kommandos von meiner FHEM Hauptinstanz entgegenzunehmen, es über den entsprechenden SCC in die Welt zu funken und natürlich den umgekehrten Weg zu verarbeiten. Fhem läuft bei mir also nicht auf dem System, welches auch den Funk macht...
Technisch hängt der recht zentral im Hausflur. Die SCC sind allerdings modifiziert und haben U.FL Buchsen erhalten, um per PigTail Antennen absetzen zu können. Ist noch nicht ganz WAF- Konform, aber ich arbeite daran
Stromversorgung erfolgt aus einer Abzweigdose; da passte noch ein entkerntes SmartPhone, Steckernetzteil rein. Soll aber mal PoE werden ...

[ioT4db]

Hallo zusammen,

hier auch mal meine Erfahrung bzgl. CUL vs. HM-MOD-RPI-PCB in Verbindung mit SD2.

Also ich kann nur raten sich vom CUL zu verabschieden (jedenfalls im Hinblick auf HM). Ich hatte einen nanoCUL (selbstbau), der auch (für mein anfängliches Empfinden) sehr gut lief.

Die SD2 (habe 9 Stück) hatte ich noch am CUL in Betrieb genommen. Ich habs auch irgendwie hinbekommen, aber ich hatte immer das Problem, dass die Zeit der Kommunikation während des Anlernens zwischen CUL und SD2 zu kurz schien. Also: Pairing gestartet > kurze Zeit später hörte der SD2 auf zu blinken, in Fhem hingen aber noch Befehle fest. Also die Pairing-Taste am SD2 ein weiteres mal drücken und dann wurden die restlichen Befehle abgearbeitet. Es kam auch vor, dass ich ein 3. mal die Pairingtaste am SD2 drücken musste.

OK, irgendwann hatte ich alle SDs sauber drin, aber die Kommunikation schien mir hin und wieder nicht sauber zu sein (wohl eine Auswirkung des timing-Problems).

Irgendwann bin ich auf die Variante HM-MOD-RPI-PCB gestoßen. Den kann man ja vielfach verwenden - direkt am Raspi, an USB löten oder als WLAN-Gateway mit nem WeMos. Einfach flexibel. Preislich kann das allemal mit meinem selbstbau-NanoCUL mithalten.

Das beste an der Sache ist aber, dass die HM-MOD Lösungen bestens läuft, was die Kommunikation anbelangt und obendrein war es bei mir so, dass auch die Funkreichweite deutlich gestiegen ist. Für mich war das die beste Entscheidung.

BTW: mit den SD2 sich in die Homatic-Materie einzuarbeiten ist schon hart. Ich habe mit nem Türkontakt angefangen...

VG...

[M_I_B]

... als WLAN-Gateway mit nem WeMos.

Zwichenfrage: WeMOS mit ESPeasy geflasht und dann per 232TTL dran oder wie? Gibt es dazu was zu lesen?

[ioT4db]

Zwichenfrage: WeMOS mit ESPeasy geflasht und dann per 232TTL dran oder wie? Gibt es dazu was zu lesen?

klar, schau mal:

so bin ich drauf gekommen...

https://forum.fhem.de/index.php/topic,69042.0.html
bzw.
https://forum.fhem.de/index.php?topic=70564.0

Im Anhang noch ein Bildchen (was aus dem ersten Thread stammt)

VG...

Update: zweiter Link war falsch