HM-Sen-MDIR-WM55: Kein Pearing möglich...

[M_I_B]

Hallo liebe Leute,

habe seit gestern mit anderem HM- Geraffel u.a. auch so eine Kombi erhalten.
Um gleich zur Sache zu kommen: Ich bekomme das Ding einfach nicht ordentlich gepairt 
Ungezählte Pearingversuche, mit und ohne Factory- Reset, mit und ohne Löschen des Codes in der CFG, mit direktem Pearing via HMid, ... Nichts hilft.
Das Höchste der Gefühle ist ein "R-pairCentral set_0xF10000". Darüber geht es nicht hinaus. Auch ein getConfig endet mit z.B. "protCmdPend 9 CMDs pending" und einem "state MISSING ACK". Auch das "in Ruhe lassen" über Nacht hat darin rein gar nichts geändert.

Mache ich da wieder mal was falsch? Kann ich mir nicht vorstellen; die anderen 5 HM- Geräte haben ja auch schmerzfrei funktioniert und Martin hat mich ja oft genug getriggert

Könnte es sein, das dieses Teil ne Macke hat?

Hier mal der aktuelle List:

Code Auswählen Erweitern

Internals:
   CFGFN      /opt/fhem/tastdimm.cfg
   DEF        4A1975
   IODev      SCC2
   LASTInputDev SCC2
   MSGCNT     4
   NAME       HM4TB1
   NR         198
   SCC2_MSGCNT 4
   SCC2_RAWMSG A1A0784004A1975F100001100DB4D45513138343936373981230000::-48:SCC2
   SCC2_RSSI  -48
   SCC2_TIME  2016-06-04 14:20:24
   STATE      MISSING ACK
   TYPE       CUL_HM
   channel_01 HM4TB1_1
   channel_02 HM4TB1_2
   channel_03 HM4TB1_3
   lastMsg    No:07 - t:00 s:4A1975 d:F10000 1100DB4D45513138343936373981230000
   protCmdDel 10
   protLastRcv 2016-06-04 14:20:24
   protResnd  3 last_at:2016-06-04 14:19:28
   protResndFail 1 last_at:2016-06-04 14:20:28
   protSnd    6 last_at:2016-06-04 14:20:24
   protState  CMDs_done_Errors:1
   rssi_at_SCC2 avg:-46.75 lst:-48 max:-45 min:-48 cnt:4
   Readings:
     2016-06-04 14:09:57   CommandAccepted yes
     2016-06-04 14:20:24   D-firmware      1.1
     2016-06-04 14:20:24   D-serialNr      MEQ1849679
     2016-06-04 14:09:56   R-pairCentral   set_0xF10000
     2016-06-04 14:20:28   state           MISSING ACK
   Helper:
     HM_CMDNR   8
     cSnd       01F100004A197500050000000000,01F100004A197500050000000000
     mId        00DB
     rxType     28
     Expert:
       def        1
       det        0
       raw        1
       tpl        0
     Io:
       newChn     +4A1975,00,00,00
       nextSend   1465042824.90882
       prefIO
       rxt        2
       vccu
       p:
         4A1975
         00
         00
         00
     Mrssi:
       mNo        07
       Io:
         SCC2       -46
     Prt:
       bErr       0
       mmcS       1
       sProc      0
       mmcA:
         ++A001F100004A197500050000000000
     Q:
       qReqConf
       qReqStat
     Role:
       dev        1
     Rssi:
       At_scc2:
         avg        -46.75
         cnt        4
         lst        -48
         max        -45
         min        -48
     Shadowreg:
       RegL_00.    02:01 0A:F1 0B:00 0C:00
     Tmpl:
Attributes:
   IODev      SCC2
   alias      Taster / PIR
   autoReadReg 4_reqStatus
   expert     2_raw
   firmware   1.1
   group      Sensoren
   model      HM-Sen-MDIR-WM55
   msgRepeat  3
   room       EG.Schlafzimmer
   serialNr   MEQ1849679
   sortby     30
   subType    motionAndBtn
   webCmd     getConfig:clear msgEvents

[LuckyDay]

lastMsg    No:07 - t:00 s:4A1975 d:F10000 1100DB4D45513138343936373981230000

von der last Msg, hat er das R-pairCentral   set_0xF10000 angenommen,

hast du nicht bereits das hm-lan ufo daheim? den SCC2 hätte ich schon lange entsorgt,

[M_I_B]

von der last Msg, hat er das R-pairCentral   set_0xF10000 angenommen,

Jupp, aber weiter geht's halt ums verrecken nicht. Die anderen "Neugeräte" (3 x HM-LC-Dim1TPBU-FM, 2 x HM-PB-6-WM55, 3 x HM-PB-2-WM55) haben problemlos funktioniert, also sollte man meinen, das so'n schnödes Psselding auch tut ...

hast du nicht bereits das hm-lan ufo daheim? den SCC2 hätte ich schon lange entsorgt,

Ja, aber durch die Masse der parallelen Baustellen hier bin ich noch nicht mit meinem PoE für das Ufo weiter gekommen ...

[martinp876]

Das pairing ist nicht verifiziert. Also getconfig. Wenn es mit scc nicht funktioniert muss hmlan ran.

[Thorsten Pferdekaemper]

Hi,
hast Du mal den hinteren Knopf gedrückt?
Gruß,
   Thorsten

[M_I_B]

@Thorsten: Na klar, bestimmt inzwischen gefühlte 1000 mal ...

@Martin: Tja, GetConfig läuft wie gesagt auf jede Menge "CMD's pending" und solche Sachen wir "MISSING ACK" oder "TimeOut reading Register" u.ä. ... Ich werde wohl das Projekt PoE für das UFO erstmal aufschieben und das Ding mal provisorisch in betrieb nehmen müssen. Mal sehen, ob es damit besser resp. überhaupt funktioniert...

[M_I_B]

... so ... Das UFO ist erstmal provisorisch in Betrieb gegangen. Hat aber anfänglich auch nicht wirklich funktioniert. Erst der 2. oder 3. Neustart des UFO brachte dann den gewünschten Erfolg, warum auch immer.
Allerdings weiß ich nun, wie schnell die 1% Grenze erreicht ist Ein paar mal GetConfig und schon ist Schulz... Das Problem hatte ich mit dem SCC nie...
Ist zwar bestimmt schon 1000 mal gefragt worden, aber ich tue es zum 1001. mal: Kann man irgendwie per Hard- oder Software-Hack diese 1% Regel zumindest im UFO lahm legen? Das nervt ungemein, wenn man gerade ein Problemkind in Gang bringen will und das UFO mittendrin den Sendebetrieb einstellt ... Ich verstehe die BNA sowieso nicht; mit jedem anderen Proto kann ich senden bis die Nase glüht. Da jukt es niemanden, wenn ein z.B. IT-Sender 24/7 einen Träger setzt....
Dazu noch eine Frage: Könnte ich das UFO und den SCC parallel betreiben, so das der SCC den Sendebetrieb und das UFO den Empfangsbetrieb beim Testen übernimmt und im normalem Betrieb beide nach RSSI Prio senden?

[marvin78]

Ist zwar bestimmt schon 1000 mal gefragt worden, aber ich tue es zum 1001. mal: Kann man irgendwie per Hard- oder Software-Hack diese 1% Regel zumindest im UFO lahm legen?

Nein. Und das ist sehr gut so.

Dazu noch eine Frage: Könnte ich das UFO und den SCC parallel betreiben, so das der SCC den Sendebetrieb und das UFO den Empfangsbetrieb beim Testen übernimmt und im normalem Betrieb beide nach RSSI Prio senden?

Schau dir VCCU an.

[M_I_B]

Nein. Und das ist sehr gut so.

"Nein" ist schon mal ne Antwort die ich ungern höre
Aber mach mich mal schlau, warum das d.E. "gut so" ist? Ich sehe da nichts gutes dran... Im "Normalbetrieb" werden die 1% i.d.R. nicht erreicht, also spielt es da eh keine Rolle. Aber wenn z.B. kurz vor einem "Gefahrenfall" das Limit erreicht ist und im Gefahrenfall nicht mehr gesendet wird (Einbruch-, Feuer-, Gasalarm / Schließen von Feuertüren und Fenstern / Einschalten von Licht und Alarmgebern / ...), ist das eine ziemlich "unschöne" Situation.

Schau dir VCCU an.

Jo, danke. Mache ich

[marvin78]

"Nein" ist schon mal ne Antwort die ich ungern höre
Aber mach mich mal schlau, warum das d.E. "gut so" ist?

Ganz einfach gesagt: Weil es vom Regulierer so vorgeschrieben ist. Etwas komplizierter ausgedrückt (und auch die Erklärung, warum ich es "gut so" finde):  http://fhemwiki.de/wiki/1%25_Regel (es geht dabei um effektive Nutzung mehrerer Teilnehmer - gäbe es die Regel nicht, würde ggf. auf kurz oder lang in gewissen Haushalten nichts mehr funktionieren). Hättest du die Möglichkeit, die Regel auf zu heben (die du faktisch hast - mehr dazu findest du sicher hier im Forum -  das Nein, war das offizielle Nein), wäre Chaos in gewissen Wohnbedingungen vorprogrammiert.

[M_I_B]

gäbe es die Regel nicht, würde ggf. auf kurz oder lang in gewissen Haushalten nichts mehr funktionieren

Naja... ich denke (und stütze mich da auf berufliche Erfahrungswerte), wenn die Regel eine "10% Regel" wäre, würde das immer noch auch bei großen Installationen problemlos funktionieren. ABer es ist müßig, sich darüber zu streiten, da die Regel nun mal existiert ...

... die Regel auf zu heben (die du faktisch hast - mehr dazu findest du sicher hier im Forum ...

Ja, Stecker ziehen... Das war das Einzige, was ich hier im Forum finden konnte. Bei einer fertigen Installation eher unpraktisch resp. nicht durchführbar, wenn niemand vor Ort ist. Oder habe ich falsch gesucht? Wenn ja, stoß mich doch bitte mal mit der Nase drauf... Denn wenn ich 3-4 mal ein Reload Config mache, ist schon Schicht im Schacht. Im Moment habe ich mir damit geholfen, das ich vor das Netzteil des UFO eine IT-Steckdose gesetzt habe; bei IT gibt es solch eine Regel zum Glück nicht ^^

[dev0]

Statt Stecker ziehen kannst Du den HMLAN auch booten
Aber das 3-4x reload/restart einen Overload auslösen habe ich bei mir noch nicht festgestellt.

[M_I_B]

Statt Stecker ziehen kannst Du den HMLAN auch booten

Du hast Dir heute den Titel "Mein Held des Tages" verdient  Habe ich über die SuFu nicht finden können... Dann bau ich mal ne Automatik zusammen

Aber das 3-4x reload/restart einen Overload auslösen habe ich bei mir noch nicht festgestellt.

Naja, das war jetzt vielleicht etwas übertrieben und die Anzahl aus den Fingern gesogen, aber oft kann ich einen Reload nicht machen. Das ist mir die vergangenen Tage oft passiert; ich mach mal eine Strichliste ...

[M_I_B]

... noch mal zum Thema "Aber das 3-4x reload/restart einen Overload auslösen habe ich bei mir noch nicht festgestellt." ...

Das sieht dann z.B. so aus:

Code Auswählen Erweitern

2016.06.12 23:09:25.568 1: HMLAN_Parse: UFO1 new condition ok
2016.06.12 23:09:36.529 1: HMLAN_Parse: UFO1 new condition Warning-HighLoad
2016.06.12 23:09:51.688 1: HMLAN_Parse: UFO1 new condition ERROR-Overload
2016.06.12 23:10:09.166 1: 192.168.1.198:1000 disconnected, waiting to reappear (UFO1) ### ab hier zieht die Reset-Automatik
2016.06.12 23:10:09.176 1: HMLAN_Parse: UFO1 new condition disconnected
2016.06.12 23:10:09.403 1: 192.168.1.198:1000 reappeared (UFO1)
2016.06.12 23:10:09.411 1: HMLAN_Parse: UFO1 new condition init
2016.06.12 23:10:09.658 1: HMLAN_Parse: UFO1 new condition ok