Bekomme keine Geräte mehr gepairt

[merasil]

Hallo,

Setzt Du den HM-MOD-UART in den Pairing-Modus (set myHmUART hmPairForSec 60), bevor Du versuchst den RT zu pairen?

Viele Grüße
  Michael

Ja mache ich. Es kommt mir auch so vor, dass log Nachrichten fehlen, wenn ich verbiss auf 1 statt 3 stelle.
Der log ist komplett von Fhem-Start über Start von Pairing-Modus bis am Thermostat die 30s abgelaufen sind

[andreas_n]

Habe versucht die Situation nachzustellen. 

In diesem Zuge habe bei ein laufendes Thermostat  zurückgesetzt und versucht dieses neu an HMLAN1 zu pairen.
-> Geht nicht, Device erkannt aber nicht gepaired -> "R-pairCentral  set_0x2BAC06" und "state CMDs_pending"
Ich glaube ich habe nun die gleiche Situation....   

Denke ich habe jetzt alle Möglichkeiten die das Forum zu bieten hat durchgespielt. (5h)
Incl. Werkseinstellung (rES) am Menu und via Batterie entfernen.

Es geht einfach nicht mehr. Dabei stellt sich die Situation wie oben beschrieben dar. (Nach dem Start wird einfach von 30->0 runtergezählt)

Update:
Ich habe es nun doch noch geschafft . Logisch ist es zwar nicht aber ich habe nach dem Erkennen des Thermostats...
set clear readings
set clear trigger
set clear msgEvents
set clear msgErrors
Danach den Anlernprocess nochmals vollständig angestoßen (ohne das Termostat zuvor zu löschen)
-> Erfolg

[merasil]

Kann bestätigen, dass das funktioniert!!!! Danke Andreas! Also doch ein Bug in der Software???

Hat sowohl mit dem neuen als auch mit dem alten geklappt!
Scheint auch nur die Thermostate (HM-CC-RT-DN) zu betreffen. Ich habe extra nochmal die optischen und magnetischen Fenstersensoren + den Wassermelder überprüft. Bei denen geht das Pairing ohne Probleme.

[merasil]

Sorry, dass ich das alte Ding nochmal hoch hole, aber...
geht es sonst niemandem so, dass er die Thermostate nicht richtig angelernt bekommt? Es ist echt mega nervig neue Teile so einfügen zu müssen, wie andreas das beschrieben hat. Ich hab ja wirklich etliche Sachen ausprobiert inkl. neuem PI und neu aufgespieltem OS und FHEM. Das muss doch ein Bug im Modul sein oder etwa nicht?

[Nitaro]

Hallo zusammen,

ich stolper heute über selbiges Problem.
Neue Thermos kann ich nicht vernünftig pairen, 3 ganz neue versucht. Alte kann ich auch nicht mehr
pairen, auch nicht mit dem beschriebenen Prozedere.

Heute ist mir dabei aufgefallen, das mir alle vorhandenen Thermos "Missing ACK" anzeigen obwohl
mal alle problemlos funktioniert haben.

Dabei motzen alle:

Code Auswählen Erweitern

missing register list
    HM_6A0A87_Clima: RegL_01.,RegL_07.
    HM_6A0A87_ClimaTeam: RegL_01.
    HM_6A0A87_WindowRec: RegL_03.HM_7B9004_chn-01,RegL_01.,RegL_07.HM_7B9004_chn-01
    HM_6A0A87_remote: RegL_01.
    HM_6A0AA6_Clima: RegL_01.,RegL_07.
    HM_6A0AA6_ClimaTeam: RegL_01.
    HM_6A0AA6_Climate: RegL_01.
    HM_6A0AA6_Weather: RegL_01.
    HM_6A0AA6_WindowRec: RegL_03.HM_2701A3_chn-01,RegL_03.HM_AE4099_chn-01,RegL_01.,RegL_07.HM_2701A3_chn-01,RegL_07.HM_AE4099_chn-01
    HM_6A0AA6_remote: RegL_01.
    HM_6A0B14: RegL_00.
    HM_6A0B14_Clima: RegL_01.,RegL_07.
    HM_6A0B14_ClimaTeam: RegL_01.
    HM_6A0B14_Climate: RegL_01.
    HM_6A0B14_Weather: RegL_01.
    HM_6A0B14_WindowRec: RegL_03.HM_7B9004_chn-01,RegL_01.,RegL_07.HM_7B9004_chn-01
    HM_6A0B14_remote: RegL_01.
    HM_6A1F49_Clima: RegL_07.
    HM_6A1F49_ClimaTeam: RegL_01.
    HM_6A1F49_WindowRec: RegL_03.HM_8800C3_chn-01,RegL_07.HM_8800C3_chn-01
    HM_6A1F49_remote: RegL_01.

Ein getConfig führt dann irgendwann unweigerlich wieder zu einem "MISSSING ACK".

[MadMax-FHEM]

Was für ein IODev?

Einen CUL etc. oder was "Richtiges" (also "echtes" Homematic-Modul)!?

EDIT: aber generell mal alle Message-Queues leeren -> clear und dann langsam Gerät für Gerät entweder noch mal "drüber pairen" (ohne Löschen/Resetten etc.) oder wenn bereits gepaired (R-PairCentral bzw. PairedTo die HMID OHNE set_ ) ein getConfig. Warten oder evtl. mal den "Konfig-Knopf" drücken bis cmds_pending weg ist. Und nochmal: langsam und Gerät für Gerät!!

EDIT2: wenn CUL, dann kann es sein, dass es aktuell einfach "zu viel" ist... Bei Homematic ist das Timing entscheidend! Und bei einem CUL ist fhem IMMER beteiligt (Telegramm auswerten und Ack schicken) bei einem "echten" IO geht einiges "automatisch" und da stimmt dann das Timing gerade bzgl. Acks etc.

Gruß, Joachim

[Nitaro]

Hallo Joachim,

einen Cube

Code Auswählen Erweitern

Internals:
   CMDS       BbCFiAZNEkGMKLUYRTVWXOefhltxz
   Clients    :CUL_HM:HMS:CUL_IR:STACKABLE_CC:TSSTACKED:STACKABLE:
   Cube_MSGCNT 250
   Cube_TIME  2019-09-29 19:32:09
   DEF        192.168.1.132:2323 1134
   DeviceName 192.168.1.132:2323
   FD         46
   FHTID      1134
   FUUID      5cee651d-f33f-bf55-5900-013aa26d8068bf21
   NAME       Cube
   NR         264
   NR_CMD_LAST_H 51
   PARTIAL   
   RAWMSG     A0F3386106A1F490000000AB0CE0C640032
   RSSI       -49
   STATE      Initialized
   TYPE       CUL
   VERSION    V 1.26.05 a-culfw Build: 311 (2018-12-09_19-12-53) CUBe (F-Band: 868MHz)
   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:
     2019-05-29 13:03:48   ccconf          freq:868.300MHz bWidth:101KHz rAmpl:33dB sens:8dB
     2019-09-29 19:06:44   cmds             B b C F i A Z N E k G M K L U Y R T V W X O e f h l t x z
     2019-06-25 08:33:56   raw             No answer
     2019-09-29 19:32:09   state           Initialized
     2019-09-29 11:46:10   uptime          0 00:06:04
     2019-06-25 08:34:01   version         V 1.26.05 a-culfw Build: 311 (2018-12-09_19-12-53) CUBe (F-Band: 868MHz)
   XMIT_TIME:
     1569776825.86026
     1569776847.11491
     1569776866.94006
     1569776867.21624
     1569776867.68119
     1569776868.17591
     1569776951.17032
     1569777016.57249
     1569777023.5088
     1569777125.82855
     1569777165.46568
     1569777171.4373
     1569777171.90714
     1569777286.11909
     1569777293.05319
     1569777312.13041
     1569777345.08007
     1569777417.47217
     1569777417.91722
     1569777432.03949
     1569777432.31051
     1569777436.27177
     1569777436.52217
     1569777436.9937
     1569777438.23147
     1569777438.50337
     1569777438.97574
     1569777439.47031
     1569777462.53731
     1569777462.78327
     1569777463.25618
     1569777463.52728
     1569777463.99773
     1569777464.26953
     1569777464.74095
     1569777465.0137
     1569777465.48426
     1569777465.76654
     1569777466.22815
     1569777466.50046
     1569777466.97058
     1569777467.46502
     1569777482.10648
     1569777482.35559
     1569777482.82594
     1569777483.32063
     1569777513.79378
     1569777532.87059
     1569777563.59109
     1569777744.6913
     1569777911.17655
   helper:
     2009D2:
       QUEUE:
     6A0AA6:
       QUEUE:
     6A0B14:
       QUEUE:
     6A1F49:
       QUEUE:
Attributes:
   hmId       00A100
   icon       wuerfel
   rfmode     HomeMatic
   room       CUL_HM

Noch einen Cube:

Code Auswählen Erweitern

Internals:
   CMDS       BbCFiAZNEkGMKLUYRTVWXOefhltxz
   Clients    :CUL_HM:HMS:CUL_IR:STACKABLE_CC:TSSTACKED:STACKABLE:
   Cube_Ankleide_MSGCNT 305
   Cube_Ankleide_TIME 2019-09-29 19:33:31
   DEF        192.168.1.137:2323 3361
   DeviceName 192.168.1.137:2323
   FD         48
   FHTID      3361
   FUUID      5d1da3e4-f33f-bf55-2fa8-17d68feb5a2fcaee
   NAME       Cube_Ankleide
   NR         273
   NR_CMD_LAST_H 7
   PARTIAL   
   RAWMSG     A0CB984702009D16A0A8700CF47FD
   RSSI       -75.5
   STATE      Initialized
   TYPE       CUL
   VERSION    V 1.26.05 a-culfw Build: 311 (2018-12-09_19-12-53) CUBe (F-Band: 868MHz)
   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:
     2019-09-29 19:06:44   cmds             B b C F i A Z N E k G M K L U Y R T V W X O e f h l t x z
     2019-09-29 19:33:31   state           Initialized
     2019-07-04 09:03:17   version         V 1.26.05 a-culfw Build: 311 (2018-12-09_19-12-53) CUBe (F-Band: 868MHz)
   XMIT_TIME:
     1569776844.88824
     1569776996.0153
     1569777132.76513
     1569777196.93024
     1569777255.15021
     1569777425.59771
     1569778060.0707
   helper:
     2009D3:
       QUEUE:
     2009D4:
       QUEUE:
     6A0A87:
       QUEUE:
Attributes:
   hmId       00A100
   icon       wuerfel
   rfmode     HomeMatic
   room       CUL_HM

Und eine VCCU:

Code Auswählen Erweitern

Internals:
   Cube_Ankleide_MSGCNT 62
   Cube_Ankleide_RAWMSG A0F7486106AC4F20000000AA8CD0F2F00::-61:Cube_Ankleide
   Cube_Ankleide_RSSI -61
   Cube_Ankleide_TIME 2019-09-29 19:32:04
   Cube_MSGCNT 18
   Cube_RAWMSG A0F7486106AC4F20000000AA8CD0F2F00::-73:Cube
   Cube_RSSI  -73
   Cube_TIME  2019-09-29 19:32:04
   DEF        00A100
   FUUID      5c6c0501-f33f-bf55-5f9a-a348e23485a39728
   IODev      Cube_Ankleide
   LASTInputDev Cube_Ankleide
   MSGCNT     80
   NAME       VCCU
   NOTIFYDEV  global
   NR         208
   NTFY_ORDER 50-VCCU
   STATE      Cube_Ankleide:ok,Cube:ok
   TYPE       CUL_HM
   assignedIOs Cube,Cube_Ankleide
   channel_01 VCCU_Btn1
   lastMsg    No:51 - t:02 s:00A100 d:2009D4 00
   protLastRcv 2019-09-29 19:27:40
   protRcv    54 last_at:2019-09-29 19:27:40
   rssi_at_Cube cnt:7 min:-55 max:-53.5 avg:-54 lst:-54.5
   rssi_at_Cube_Ankleide cnt:51 min:-53.5 max:-50 avg:-51.78 lst:-52.5
   READINGS:
     2019-09-29 19:27:40   CommandAccepted yes
     2019-09-29 19:06:45   IOopen          2
     2019-09-29 19:06:45   state           Cube_Ankleide:ok,Cube:ok
     2019-05-24 15:40:27   unknown_10204D  received
     2019-05-24 19:29:26   unknown_154EA3  received
     2019-07-26 03:45:50   unknown_1A8470  received
     2019-07-14 16:13:38   unknown_2008D0  received
     2019-05-02 12:56:34   unknown_200901  received
     2019-05-02 12:45:12   unknown_200902  received
     2019-02-21 19:20:42   unknown_2009D3  received
     2019-02-22 19:47:42   unknown_2009D4  received
     2019-03-01 10:40:09   unknown_200BD0  received
     2019-05-24 20:11:32   unknown_2701A3  received
     2019-05-24 19:00:40   unknown_2EA1CE  received
     2019-05-24 14:50:56   unknown_3EF29B  received
     2019-06-03 19:33:51   unknown_5B120A  received
     2019-09-29 19:32:04   unknown_6AC4F2  received
     2019-09-28 19:32:59   unknown_6AC508  received
     2019-09-29 18:13:31   unknown_6AC557  received
     2019-05-24 15:21:46   unknown_7497FD  received
     2019-05-23 16:51:17   unknown_7B9004  received
     2019-05-24 16:40:16   unknown_AE4099  received
     2019-05-23 19:11:13   unknown_FD0445  received
   helper:
     HM_CMDNR   81
     mId        FFF0
     peerFriend peerSens,peerAct
     peerOpt    -:virtual
     regLst     0
     rxType     1
     supp_Pair_Rep 0
     ack:
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     io:
       nextSend   1569778060.41661
       prefIO     
       vccu       VCCU
       ioList:
         Cube_Ankleide
         Cube
     mRssi:
       mNo        51
       io:
         Cube:
           -54.5
           -54.5
         Cube_Ankleide:
           -46.5
     prt:
       bErr       0
       sProc      0
       rspWait:
     q:
       qReqConf   
       qReqStat   
     role:
       dev        1
       vrt        1
     rssi:
       at_Cube:
         avg        -54
         cnt        7
         lst        -54.5
         max        -53.5
         min        -55
       at_Cube_Ankleide:
         avg        -51.7843137254902
         cnt        51
         lst        -52.5
         max        -50
         min        -53.5
     tmpl:
Attributes:
   IODev      Cube_Ankleide
   IOList     Cube_Ankleide,Cube
   IOgrp      VCCU
   expert     2_raw
   icon       mqtt_broker
   model      CCU-FHEM
   room       CUL_HM
   subType    virtual
   webCmd     virtual:update

[Nitaro]

EDIT: aber generell mal alle Message-Queues leeren -> clear und dann langsam Gerät für Gerät entweder noch mal "drüber pairen" (ohne Löschen/Resetten etc.) oder wenn bereits gepaired (R-PairCentral bzw. PairedTo die HMID OHNE set_ ) ein getConfig. Warten oder evtl. mal den "Konfig-Knopf" drücken bis cmds_pending weg ist. Und nochmal: langsam und Gerät für Gerät!!

Ich melde mich dann in ein paar Tagen wieder, das wird dauern 

[Otto123]

Ich melde mich dann in ein paar Tagen wieder, das wird dauern 

Nein, erstmal NUR EINEN probieren. Polepole wie die Kenianer sagen

zeig doch mal ein list von einem

[Nitaro]

Nein, erstmal NUR EINEN probieren. Polepole wie die Kenianer sagen

Das führt ja leider zu einem MISSING ACK.

Hier ist ein Device:

Code Auswählen Erweitern



Internals:
   CHANGED   
   Cube_Ankleide_MSGCNT 17
   Cube_Ankleide_RAWMSG A0F4986106A1F490000000AB0CE0C6400::-52.5:Cube_Ankleide
   Cube_Ankleide_RSSI -52.5
   Cube_Ankleide_TIME 2019-09-29 20:19:37
   Cube_MSGCNT 17
   Cube_RAWMSG A0F4986106A1F490000000AB0CE0C6400::-48:Cube
   Cube_RSSI  -48
   Cube_TIME  2019-09-29 20:19:37
   DEF        6A1F49
   FUUID      5c51eb41-f33f-bf55-2463-70df08e4f4e9e612
   IODev      Cube_Ankleide
   LASTInputDev Cube
   MSGCNT     34
   NAME       HM_6A1F49
   NOTIFYDEV  global
   NR         164
   NTFY_ORDER 50-HM_6A1F49
   STATE      MISSING ACK
   TYPE       CUL_HM
   channel_01 HM_6A1F49_Weather
   channel_02 HM_6A1F49_Climate
   channel_03 HM_6A1F49_WindowRec
   channel_04 HM_6A1F49_Clima
   channel_05 HM_6A1F49_ClimaTeam
   channel_06 HM_6A1F49_remote
   lastMsg    No:49 - t:10 s:6A1F49 d:000000 0AB0CE0C6400
   protCmdDel 6
   protLastRcv 2019-09-29 20:19:37
   protRcv    13 last_at:2019-09-29 20:19:37
   protResnd  5 last_at:2019-09-29 20:14:42
   protResndFail 1 last_at:2019-09-29 20:17:18
   protSnd    14 last_at:2019-09-29 20:17:15
   protState  CMDs_done_Errors:1
   rssi_at_Cube cnt:17 min:-49 max:-48 avg:-48.64 lst:-48
   rssi_at_Cube_Ankleide cnt:17 min:-52.5 max:-52.5 avg:-52.5 lst:-52.5
   READINGS:
     2019-09-29 20:14:42   Activity        alive
     2019-09-29 20:09:48   CommandAccepted yes
     2019-05-24 08:50:18   D-firmware      1.5
     2019-05-24 08:50:18   D-serialNr      PEQ1191777
     2019-08-30 03:33:24   PairedTo        0x00A100
     2019-05-24 08:51:39   R-backOnTime    10 s
     2019-05-24 08:51:39   R-burstRx       on
     2019-05-24 08:51:39   R-cyclicInfoMsg on
     2019-05-24 08:51:39   R-cyclicInfoMsgDis 0
     2019-05-24 08:51:39   R-pairCentral   0x00A100
     2019-08-30 03:33:24   RegL_00.        00:00 01:01 02:01 09:01 0A:00 0B:A1 0C:00 0E:0A 0F:00 11:00 12:15 16:01 18:00 19:00 1A:00
     2019-09-29 20:19:37   actuator        100
     2019-09-29 20:19:37   battery         ok
     2019-09-29 20:19:37   batteryLevel    2.7
     2019-09-29 20:19:37   desired-temp    22.0
     2019-09-29 20:19:37   measured-temp   20.6
     2019-09-29 20:19:37   motorErr        ok
     2019-08-29 06:54:14   powerOn         2019-08-29 06:54:14
     2019-08-29 06:54:14   recentStateType info
     2019-09-29 20:17:18   state           MISSING ACK
     2019-09-21 23:48:14   time-request    -
     RegL_07.:
       VAL       
   helper:
     HM_CMDNR   73
     cSnd       0100A1006A1F4900040000000007,0100A1006A1F4900040000000007
     mId        0095
     peerFriend
     peerOpt    -:thermostat
     regLst     0
     rxType     140
     supp_Pair_Rep 0
     ack:
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     io:
       newChn     +6A1F49,00,00,00
       nextSend   1569781177.30322
       rxt        2
       vccu       VCCU
       p:
         6A1F49
         00
         00
         00
       prefIO:
         Cube_Ankleide
         Cube
     mRssi:
       mNo        49
       io:
         Cube:
           -48
           -48
         Cube_Ankleide:
           -46.5
           -46.5
     prt:
       bErr       0
       sProc      0
     q:
       qReqConf   
       qReqStat   
     role:
       dev        1
       prs        1
     rssi:
       at_Cube:
         avg        -48.6470588235294
         cnt        17
         lst        -48
         max        -48
         min        -49
       at_Cube_Ankleide:
         avg        -52.5
         cnt        17
         lst        -52.5
         max        -52.5
         min        -52.5
     shRegW:
       07         04
     tmpl:
Attributes:
   IODev      Cube_Ankleide
   IOgrp      VCCU:Cube_Ankleide,Cube
   actCycle   000:10
   actStatus  alive
   alias      Bad_Heizung
   autoReadReg 5_readMissing
   event-on-change-reading .*
   expert     2_raw
   firmware   1.5
   icon       sani_heating
   model      HM-CC-RT-DN
   serialNr   PEQ1191777
   subType    thermostat
   webCmd     getConfig:clear msgEvents:burstXmit



[pc1246]

Moin
Hmmmmm, gepairt ist er!
Cube ist ja nicht zwingend ein natives IO-dev.
Hast du auch welche mit FW 1.4? Das ist auf die Schnelle was mir aufgefallen ist!
Gruss Christoph

[Nitaro]

Moin Christoph,

die haben alle Version 1.5. Fensterkontakte und Temperatursensoren
haben keinerlei Probleme. Nur die Thermostate.

ein ConfigCheck sagt dann folgendes:

Code Auswählen Erweitern

missing register list
    HM_6A0A87_Clima: RegL_07.
    HM_6A0A87_ClimaTeam: RegL_01.
    HM_6A0A87_remote: RegL_01.
    HM_6A0AA6_Clima: RegL_01.,RegL_07.
    HM_6A0AA6_ClimaTeam: RegL_01.
    HM_6A0AA6_remote: RegL_01.
    HM_6A0B14_Clima: RegL_01.,RegL_07.
    HM_6A0B14_ClimaTeam: RegL_01.
    HM_6A0B14_remote: RegL_01.
    HM_6A1F49_Clima: RegL_01.,RegL_07.
    HM_6A1F49_ClimaTeam: RegL_01.
    HM_6A1F49_remote: RegL_01.

[Nitaro]

Hat mal jemand noch einen Hinweis für mich wie ich die umgeflashten MaxCube CUL_HM
sniffen kann ? Ich habe die Einstellungen aus dem Wiki genommen aber sehe da nicht viel
außer resndfail und MISSING ACK.

Jemand hat auch gefragt ob was "richtiges" genommen wird.
Was ist denn was "richtiges" für Homematic ? Ein RPI mit dem Homematic Modul ?
Da hat aber der Threadersteller ja auch das Problem.

[Otto123]

Die Thermostate sind gepairt, es fehlen offenbar "nur" Register.
Es gibt einige HM Geräte die sind sensibel  mit der Datenübertragung, je mehr Daten umso sensibler. Die Homematic IOs (es gibt defakto derzeit nur zwei: das RPI Modul und das Langateway) sind um Längen besser als ein CUL & Co.

Du kannst versuchen die fehlenden Register einzeln zu lesen. Dabei hat der CUL eine bessere Chance, denke ich.
Beispiel:

Code Auswählen Erweitern

set HM_6A1F49_remote getRegRaw List1
Wenn das klappt versuch mal die anderen nach diesem Schema. RegL_01. -> List1

Gruß Otto

[frank]

der configcheck wird ja langsam auch immer besser. es fehlen ja "nur" noch register der chn 4-6.

ohne timing deiner gateways kann es ewig dauern, bis die vielen daten der rt ausgelesen sind.

tip: mach besser getconfig in den channels, die noch angemeckert werden.

denn ein getconfig im hauptdevice pollt immer alle daten von allen channels. bei abbruch der kommunikation, zb wegen timing, ist die wahrscheinlichkeit sehr gross, dass die daten der letzten channel dann nicht mehr kommen.

wenn das immer noch sehr zäh ist, würde ich noch attr burstAccess=1_auto einschalten. das sollte alles beschleunigen.

wenn der configcheck dann clean ist, alle burstaccess attribute löschen und fhem save ausführen, damit die readings im statefile gesichert werden.

bedenke: durch jedes unnötige device löschen und clear readings muss erneut wieder aufwändig das device ausgelesen werden.

ich würde mir wenigstens ein gateway besorgen, das timing kann. zb ein hmuart.