HM-SEC-SD-2 neu

[Otto123]

Du findest die Anleitung im Wiki ist anders?
https://wiki.fhem.de/wiki/HM-SEC-SD_Rauchmelder#virtueller_TeamLead

Gruß Otto

[ioT4db]

Du kannst nicht einen x-beliebigen Kanal als Leader verwenden. Ein "virtueller Leader" ist ein reines FHEM Konzept, das gibt's normal nicht. Was auch heisst dass der virtuelle Leader für die Peers aussehen muss wie ein echter Rauchmelder. Und echte Melder haben nur einen Kanal, nämlich die Nummer 1.

Hi,
ich hab meine ersten 3 SD2 erfolgreich angelernt. Soweit scheint alles zu funktionieren. Übrigens mit einem nanoCUL (V 1.66 nanoCUL868)!

Nun noch eine Frage: Deine obige Erklärung klingt logisch. Bedeutet das also, dass ich bei mehreren Teams je Team einen virtuellen Teamlead (z.B. define TeamDev CUL_HM 111111) mit eben GENAU EINEN Channel (z.B. TeamDev_Btn1) haben DARF?
bzw. anders ausgedrückt: Ich kann meine verschiedenen (zukünftigen) Teams nicht über mehrere Channels (z.B. TeamDev_Btn2) des selben Teamleads verwalten?

Danke schonmal für Eure Mühe
VG...

[MarcelK]

Nun noch eine Frage: Deine obige Erklärung klingt logisch. Bedeutet das also, dass ich bei mehreren Teams je Team einen virtuellen Teamlead (z.B. define TeamDev CUL_HM 111111) mit eben GENAU EINEN Channel (z.B. TeamDev_Btn1) haben DARF?
bzw. anders ausgedrückt: Ich kann meine verschiedenen (zukünftigen) Teams nicht über mehrere Channels (z.B. TeamDev_Btn2) des selben Teamleads verwalten?

Ohne den Quellcode der Firmware kann man das natürlich nie mit 100%iger Sicherheit sagen. Aber rein vom Prinzip her ist es so wie ich geschrieben habe, TeamLeads im HM System machen nichts weiter als ihre HM-Adresse den anderen als gemeinsame Team-Adresse zur Verfügung zu stellen. FHEM und die virtuelle Leads entkoppeln das von einem physikalischen Leader und nehmen eine beliebig gewählte Adresse dafür, aber anonsten ist das Prinzip gleich. Die Kanal-Info wird vermutlich von den Meldern komplett ignoriert.

[Gunther]

Ich habe immer noch extreme Probleme mit meinen (bisher) 5 Rauchmeldern.

Ich hatte jetzt einige Tage 2, die sauber eingebunden waren. Die anderen 3 mit unreachable.
Nun habe ich eben einen versucht mit einem virtuellen Kanal zu Pairen. Dieser Rauchmelder ist jetzt auf IOerr gegangen.
Der andere ebenfalls auf unreachable.

Ich brauche da Eure Hilfe. 
Was kann ich tun? Welche Infos braucht Ihr, um mir zu helfen?

[Otto123]

Hi Gunther,

Wenn die SD unreachable sind, welchen Sinn macht es dann zu versuchen sie mit einem virtuellen Kanal zu PEEREN?

Basis ist: Sie müssen alle sauber in FHEM eingebunden und gepairt sein. Sonst machen weitere Aktionen keine Sinn.

Mit hmInfo configCheck kannst Du prüfen ob alles in Ordnung ist.

Gruß Otto

[Gunther]

Hallo Otto,

das Peeren habe ich mit den bis dato funktionierenden RM versucht. Danach sind die in die beschriebenen Fehlzustände gegangen.

Ich habe vermutlich aufgrund der RM ständig Disconnects / Overloads an meinen beiden HMLAN (laufen über VCCU). Außerdem ist mein FHEM sehr langsam: z. B. Öffnen von Devices über die Oberfläche dauert extrem lange.
Wie kann ich die RM aus FHEM rausnehmen um zu prüfen, ob die Fehler dadurch verursacht werden?

[Otto123]

Hallo Gunther,

aber dann stimmt etwas anderes nicht. Dann musst Du suchen warum dein FHEM nicht reagiert, vermutlich hast Du irgendwelche Endlosschleifen laufen die das System belasten.
Mit apptime würde ich als erstes suchen -> https://fhem.de/commandref.html#apptime

Gruß Otto

[Gernott]

Hallo an alle Geplagten
Habe seit heute zwei von den Bosch-SD2 und bin beim pairing leicht verzweifelt. Die Dinger sind echt zickig. Mit dem hmusb neben meinem Schreibtisch ging gar nichts. Der SD2 hat einfach vor sich hin geblinkt. Variation des Abstandes bis zu einigen Metern hat auch nicht geholfen. Habe dann die Teile in den Keller zum hmlan getragen und dort ging es sofort. So etwas hatte ich bisher mit keinem Homematic-Gerät.
Die weitere Kommunikation war dann unauffällig. - Vielleicht hilft es ja jemandem.

Gruß
G.

[Gunther]

Hallo Gunther,

aber dann stimmt etwas anderes nicht. Dann musst Du suchen warum dein FHEM nicht reagiert, vermutlich hast Du irgendwelche Endlosschleifen laufen die das System belasten.
Mit apptime würde ich als erstes suchen -> https://fhem.de/commandref.html#apptime

Gruß Otto

FHEM läuft wieder schnell. Trotzdem habe ich diese Disconnects. Schiebe die ja immer noch auf die HM-SEC-SD-2.
Um den Thread hier nicht aufzublähen mit Dingen, die ggf. nicht hierher führen, habe ich das Thema ausgelagert:
https://forum.fhem.de/index.php/topic,70314.0.html

Freue mich da natürlich auch über Hilfe. 

[pc1246]

Hallo an alle Geplagten
Habe seit heute zwei von den Bosch-SD2 und bin beim pairing leicht verzweifelt. Die Dinger sind echt zickig. Mit dem hmusb neben meinem Schreibtisch ging gar nichts. Der SD2 hat einfach vor sich hin geblinkt. Variation des Abstandes bis zu einigen Metern hat auch nicht geholfen. Habe dann die Teile in den Keller zum hmlan getragen und dort ging es sofort. So etwas hatte ich bisher mit keinem Homematic-Gerät.
Die weitere Kommunikation war dann unauffällig. - Vielleicht hilft es ja jemandem.

Gruß
G.

Hallo Gernott
Was sind denn bitte Bosch-SD2? Ich finde FERION 5000 OW, die nicht kompatibel mit den FERION 3000 OW sind, die wiederum den Homematic-SD aehneln!
Fuer mich deshalb interessant, da ich eventuell einen Draht zu Bosch habe!
Gruss Christoph

[Gernott]

Was sind denn bitte Bosch-SD2? Ich finde FERION 5000 OW

Genau diese.

[Gernott]

Ist das normal, daß configCheck für den virtuellen Teamlead meldet:

Code Auswählen Erweitern

PairedTo missing/unknown
    RM.TeamDev?
RM.TeamDev isd das Device. Im Channel sind die Peers korrekt eingetragen.
Sonst funktioniert soweit alles.

Gruß
G.

[Otto123]

Hi,

definitiv nicht "normal" zumindest meldet er das bei mir nicht.
Zeig mal ein list RM.TeamDev

Meiner hat nur vier readings.

Gruß Otto

[Gernott]

Zeig mal ein list RM.TeamDev
Gruß Otto

Sieht so aus:

Code Auswählen Erweitern


Internals:
   CFGFN
   DEF        111111
   HMLAN1_MSGCNT 46
   HMLAN1_RAWMSG E111111,0000,03D99D8D,FF,FFAC,D9144111111111111101009600000087B22B47
   HMLAN1_RSSI -84
   HMLAN1_TIME 2017-04-09 14:11:10
   IODev      hmusb
   LASTInputDev HMLAN1
   MSGCNT     54
   NAME       RM.TeamDev
   NOTIFYDEV  global
   NR         846
   STATE      CMDs_done
   TYPE       CUL_HM
   channel_01 RM_Team
   hmusb_MSGCNT 8
   hmusb_RAWMSG E111111,0000,CBFBBB76,FF,FFA8,D880021111111EA24B00
   hmusb_RSSI -88
   hmusb_TIME 2017-04-09 14:03:27
   lastMsg    No:D9 - t:41 s:111111 d:111111 01009600000087B22B47
   protCmdDel 4
   protLastRcv 2017-04-09 14:11:10
   protResnd  12 last_at:2017-04-09 14:03:26
   protResndFail 4 last_at:2017-04-09 14:03:32
   protSnd    60 last_at:2017-04-09 14:11:07
   protState  CMDs_done
   rssi_at_HMLAN1 avg:-84.95 min:-95 max:-80 lst:-84 cnt:46
   rssi_at_hmusb avg:-86.87 min:-88 max:-85 lst:-88 cnt:8
   Readings:
     2017-04-09 14:03:12   CommandAccepted yes
     2017-04-09 14:09:20   RegL_00.
     2017-04-09 14:00:25   battery         ok
     2017-04-09 14:11:07   state           CMDs_done
   Helper:
     HM_CMDNR   217
     alarmNo    00
     cSnd       011EA24B11111100040000000000,011EA24B11111100040000000000
     supp_Pair_Rep 0
     Expert:
       def        1
       det        0
       raw        1
       tpl        0
     Io:
       newChn     +111111,00,00,00
       nextSend   1491739870.38796
       rxt        0
       vccu       vccu
       p:
         111111
         00
         00
         00
     Mrssi:
       mNo        D9
       Io:
         HMLAN1     -84
     Prt:
       bErr       0
       sProc      0
       Rspwait:
     Q:
       qReqConf
       qReqStat
     Role:
       dev        1
     Rssi:
       At_hmlan1:
         avg        -84.9565217391304
         cnt        46
         lst        -84
         max        -80
         min        -95
       At_hmusb:
         avg        -86.875
         cnt        8
         lst        -88
         max        -85
         min        -88
     Shadowreg:
     Tmpl:
Attributes:
   IODev      hmusb
   IOgrp      vccu
   autoReadReg 4_reqStatus
   expert     2_raw
   model      virtual_1
   room       Alarm,CUL_HM
   subType    virtual

[Otto123]

hmm, meiner sieht etwas anders aus. Aber nicht das ich jetzt sagen könnte: da ist was völlig falsch. Vielleicht sieht Martin da was?

Gruß Otto