[Gelöst] HM-CC-RT-DN verweigert das Pairen - sendet aber Daten an nanoCUL

[bromosky]

Huhu ihr Lieben,

Lösungsansatz im letzten Beitrag

lange hat es gedauert, nun habe ich mal wieder ein dickes Problem.
Nachdem mein nanoCUL zunehmend den Dienst quittiert und jeden Epileptiker mit seinen zwei LEDs ins Nirwana schicken könnte, habe ich beschlossen die neue a-culfw auf den Arduino zu flashen. Alles top gelaufen. (Normalerweise habe ich das Diskolicht mit dem Entfernen der Spannungsquelle behoben, sprich USB raus und wieder rein.) Jedenfalls ging danach alles wieder prima, bis auf, dass das Heizungsthermostat sich absolut nicht anlernen lassen wollte.

Ich schaute, alles sendet fleißig Daten, meine Temperatursensoren welche über HM laufen, der Türsensor.
Also fix Batterien raus, wieder rein, pairen angestoßen. Wieder nix. Das habe ich etliche Male probiert. Irgendwann schaute ich, wird denn, wenn ich das alte Device lösche, per autocreate ein neues angelegt? Siehe da, mein nanoCUL scheint auch das Thermostat zu empfangen. Nur die 30 Sekunden auf dem Ventil verstreichen, es zeigt keine Verbindung zum CUL an. Aus mir unerklärlichen Gründen empfängt also der CUL Daten, denn er weiß ja um die Anwesenheit des Thermostates, aber Pairen geht partout nicht.
Nun weiter, hmInfo kontaktiert. So viel habe ich dort noch nie gesehen:

Code Auswählen Erweitern

missing register list
    Max_Heizung: RegL_00.
    Max_Heizung_Clima: RegL_01.,RegL_07.
    Max_Heizung_ClimaTeam: RegL_01.
    Max_Heizung_Climate: RegL_01.
    Max_Heizung_Weather: RegL_01.
    Max_Heizung_WindowRec: RegL_01.
    Max_Heizung_remote: RegL_01.
    Max_Sensor: RegL_00.
    Max_Sensor_Values: RegL_01.
    Max_Tur: RegL_00.,RegL_01.
    Sensor_Draussen: RegL_00.
    Sensor_Draussen_Values: RegL_01.

peer list incomplete. Use getConfig to read it.
    incomplete: Max_Heizung_Clima:
    incomplete: Max_Heizung_ClimaTeam:
    incomplete: Max_Heizung_Climate:
    incomplete: Max_Heizung_Weather:
    incomplete: Max_Heizung_WindowRec:
    incomplete: Max_Heizung_remote:
    incomplete: Max_Tur:

peer not verified. Check that peer is set on both sides
    wz_vT_Sensor1 p:Max_Heizung_Weather

templist mismatch
    Max_Heizung_Clima: file: ./tempList.cfg error:Can't open ./tempList.cfg: No such file or directory

Die IT-Steckdosen über den gleichen CUL können auch geschaltet werden. Ich verstehe nicht so recht, wie ich, ohne eine Änderung, außer einem Update, alles so gegen die Wand fahren konnte.
Nun bin ich heillos überfragt. Natürlich, die obligatorische Suche nach einem Thema mit möglicher Lösung wurde erledigt. Leider ohne Erfolg.
Ich hoffe, jemand möge mich erleuchten können und sich kurz hier zu Wort melden, da ich ungern wieder alles von vorn aufsetzen möchte, zumindest den HM-Part.

Ich danke euch,
Grüße, Max!

[pc1246]

Moin
Da sich keiner opfert, will ich mal versuchen zu helfen.
Als erstes der Hinweis, ein CUL ist nicht das IODev der Wahl fuer HM!
Um das HMInfo zu bereinigen, solltest Du mal auf den entsprechenden devices ein getConfig machen. Aber daran denken, dass Du irgendwann zuviel Traffic erzeugst, und der CUL eine Zwangspause macht!
Ein list vom CUL und zumindest vom HM-CC-RT-DN waeren hilfreich. Die anderen drei kannst du aber auch gleich mit einstellen.
Deine Beschreibung mit Batterie raus/rein leuchtet auch nicht ein! Die mittlere Taste lange druecken bringt auch den pairing-Modus.
Gruss Christoph

[Otto123]

Hi,

Code Auswählen Erweitern

Die IT-Steckdosen über den gleichen CUL können auch geschaltet werden. Mehrere Protokolle parallel über einen CUL bei Homematic? Vergiss es ... 

Gruß Otto

[bromosky]

Guten Abend ihr,

danke für eure Antworten. Zuerst möchte ich auf die letzte eingehen.
Ich hatte bis jetzt noch kein Problem damit, den CUL für das Steuern von Homematic und IT-Steckdosen zu missbrauchen. Da die 3 Steckdosen im gleichen Raum sind, wie der Sender komme ich mit der geringeren Reichweite bei 433MHz prima aus. Ansonsten wird ja alles bei 868MHz gefüttert.
Ich verstehe leider nicht, wieso dies nun nicht funktionieren soll, wenn es doch schon seit 6 Monaten einwandfrei läuft.
Letztendlich laufen die Steckdosen ja weiterhin prima.

Weshalb gilt ein CUL nicht als bevorzugtes IODev? Das mein nanoCUL nicht die beste Leistung erbringt, das verstehe ich komplett, aber viele setzen ja auch auf CUL's von Busware usw.
Batterie raus/rein und alle 3 Tasten beim einlegen der Batterien startet das Thermostat in einem Werkszustand. Ist eigentlich das selbe, wie wenn ich es per reset zurücksetze. Habe ich beides probiert. Das Pairing habe ich dann letztendlich wie von dir beschrieben, mit dem Drücken der mittleren Taste, angestoßen. Entschuldigt meine unklare Ausführung.
Die Liste, die benötigt wird vom Thermostat:

Code Auswählen Erweitern

Internals:
   CFGFN     
   DEF        613D91
   FUUID      5cbe5473-f33f-38d4-a0b5-254102358f49c34c
   IODev      nanoCUL
   LASTInputDev nanoCUL
   MSGCNT     1
   NAME       Max_Heizung
   NOTIFYDEV  global
   NR         137
   STATE      CMDs_pending
   TYPE       CUL_HM
   chanNo     01
   channel_01 Max_Heizung_Weather
   channel_02 Max_Heizung_Climate
   channel_03 Max_Heizung_WindowRec
   channel_04 Max_Heizung_Clima
   channel_05 Max_Heizung_ClimaTeam
   channel_06 Max_Heizung_remote
   lastMsg    No:01 - t:00 s:613D91 d:000000 1400954F4551313731323937385900FFFF
   nanoCUL_MSGCNT 1
   nanoCUL_RAWMSG A1A018400613D910000001400954F4551313731323937385900FFFF::-58.5:nanoCUL
   nanoCUL_RSSI -58.5
   nanoCUL_TIME 2019-04-23 01:55:31
   protCmdPend 21 CMDs_pending
   protLastRcv 2019-04-23 01:55:31
   protRcv    2 last_at:2019-04-23 01:55:31
   protState  CMDs_pending
   rssi_at_nanoCUL cnt:2 min:-58.5 max:-58.5 avg:-58.5 lst:-58.5
   READINGS:
     2019-04-23 02:13:30   Activity        dead
     2019-04-23 01:55:31   D-firmware      1.4
     2019-04-23 01:55:31   D-serialNr      OEQ1712978
     2019-04-23 01:55:31   R-pairCentral   set_0x310597
     2019-04-23 21:54:05   state           CMDs_pending
   cmdStack:
     ++A001310597613D9100050000000000
     ++A001310597613D91000802010A310B050C97
     ++A001310597613D910006
     ++A011310597613D9186041E
     ++A011310597613D9186041E
     ++A011310597613D91860409
     ++A011310597613D91860409
     ++A001310597613D9100040000000000
     ++A001310597613D910103
     ++A001310597613D9101040000000001
     ++A001310597613D910203
     ++A001310597613D9102040000000001
     ++A001310597613D910303
     ++A001310597613D9103040000000001
     ++A001310597613D910403
     ++A001310597613D9104040000000001
     ++A001310597613D9100040000000007
     ++A001310597613D910503
     ++A001310597613D9105040000000001
     ++A001310597613D910603
     ++A001310597613D9106040000000001
   helper:
     HM_CMDNR   1
     PONtest    1
     mId        0095
     peerFriend
     peerOpt    -:thermostat
     regLst     0
     rxType     140
     supp_Pair_Rep 0
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     io:
       newChn     +613D91,02,00,00
       nextSend   1555977331.90532
       prefIO     
       rxt        2
       vccu       
       p:
         613D91
         00
         00
         00
     mRssi:
       mNo        01
       io:
         nanoCUL:
           -52.5
           -52.5
     prt:
       bErr       0
       sProc      2
     q:
       qReqConf   
       qReqStat   
     role:
       dev        1
       prs        1
     rssi:
       at_nanoCUL:
         avg        -58.5
         cnt        2
         lst        -58.5
         max        -58.5
         min        -58.5
     shRegW:
       07         04
     shadowReg:
     tmpl:
Attributes:
   DbLogExclude .*
   IODev      nanoCUL
   IOgrp      VCCU:nanoCUL
   actCycle   000:10
   actStatus  dead
   autoReadReg 4_reqStatus
   expert     2_raw
   firmware   1.4
   model      HM-CC-RT-DN
   room       CUL_HM
   serialNr   OEQ1712978
   subType    thermostat
   webCmd     getConfig:clear msgEvents:burstXmit

List vom Türsensor:

Code Auswählen Erweitern

Internals:
   DEF        5F4B27
   FUUID      5c66ee05-f33f-38d4-030d-66b3717fd9d11e09
   IODev      nanoCUL
   LASTInputDev nanoCUL
   MSGCNT     34
   NAME       Max_Tur
   NOTIFYDEV  global
   NR         39
   NTFY_ORDER 50-Max_Tur
   STATE      closed
   TYPE       CUL_HM
   chanNo     01
   lastMsg    No:3B - t:41 s:5F4B27 d:000000 015100
   nanoCUL_MSGCNT 34
   nanoCUL_RAWMSG A0C3B86415F4B27000000015100::-53:nanoCUL
   nanoCUL_RSSI -53
   nanoCUL_TIME 2019-04-23 21:40:53
   protCmdDel 4
   protCmdPend 3 CMDs_pending
   protLastRcv 2019-04-23 21:40:53
   protRcv    34 last_at:2019-04-23 21:40:53
   protResnd  3 last_at:2019-04-23 01:48:41
   protResndFail 1 last_at:2019-04-23 02:30:09
   protSnd    4 last_at:2019-04-23 02:30:06
   protState  CMDs_pending
   rssi_at_nanoCUL cnt:34 min:-54 max:-51.5 avg:-52.75 lst:-53
   READINGS:
     2019-04-23 01:37:03   Activity        alive
     2018-11-08 23:47:26   D-firmware      1.0
     2018-11-08 23:47:26   D-serialNr      OEQ1429255
     2018-11-08 23:47:26   R-pairCentral   set_0x310597
     2018-11-08 23:47:26   aesKeyNbr       00
     2019-04-23 21:39:56   alive           yes
     2019-04-23 21:40:53   battery         ok
     2019-04-23 21:40:53   contact         closed (to broadcast)
     2019-04-23 21:39:56   recentStateType info
     2019-04-23 21:39:56   sabotageError   off
     2019-04-23 21:40:53   state           closed
     2019-04-23 21:40:53   trigDst_broadcast noConfig
     2019-04-23 21:40:53   trigger_cnt     81
   cmdStack:
     ++A0013105975F4B2700040000000000
     ++A0013105975F4B2701040000000001
     ++A0013105975F4B270103
   helper:
     HM_CMDNR   59
     getCfgList all
     getCfgListNo ,4
     mId        00C7
     peerFriend peerAct,peerVirt
     peerOpt    4:threeStateSensor
     regLst     0,1,4p
     rxType     28
     supp_Pair_Rep 0
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     io:
       newChn     +5F4B27,02,00,00
       nextSend   1556048453.52326
       rxt        2
       vccu       VCCU
       p:
         5F4B27
         00
         00
         00
       prefIO:
         nanoCUL
     mRssi:
       mNo        3B
       io:
         nanoCUL:
           -47
           -47
     prt:
       bErr       0
       sProc      2
     q:
       qReqConf   
       qReqStat   
     role:
       chn        1
       dev        1
     rssi:
       at_nanoCUL:
         avg        -52.75
         cnt        34
         lst        -53
         max        -51.5
         min        -54
     shadowReg:
     tmpl:
Attributes:
   DbLogExclude .*
   IODev      nanoCUL
   IOgrp      VCCU:nanoCUL
   actCycle   002:50
   actStatus  alive
   autoReadReg 4_reqStatus
   expert     2_raw
   firmware   1.0
   model      HM-SEC-SCO
   room       10_Max_Zimmer,CUL_HM
   serialNr   OEQ1429255
   subType    threeStateSensor

List vom CUL-HM:

Code Auswählen Erweitern

Internals:
   CMDS       ABCEeFfGiKlMNRTtUVWXxZ
   Clients    :CUL_HM:HMS:CUL_IR:STACKABLE_CC:TSSTACKED:STACKABLE:
   DEF        /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0@38400 0000
   DeviceName /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0@38400
   FD         8
   FHTID      0000
   FUUID      5c66ee01-f33f-38d4-c40d-e884339e572cce30
   NAME       nanoCUL
   NR         20
   NR_CMD_LAST_H 64
   PARTIAL   
   RAWMSG     A0F12A253444029310597010300923218F6
   RSSI       -79
   STATE      Initialized
   TYPE       CUL
   VERSION    V 1.26.06 a-culfw Build: 315 (2019-04-07_19-59-48) nanoCUL868 (F-Band: 868MHz)
   initString X21
Ar
   nanoCUL_MSGCNT 944
   nanoCUL_TIME 2019-04-23 22:22:36
   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-04-23 01:37:01   cmds             A B C E e F f G i K l M N R T t U V W X x Z
     2019-04-23 02:18:55   raw             is00000000000000000000000101000001
     2019-04-23 22:22:36   state           Initialized
     2019-04-23 00:47:54   uptime          0 00:24:36
     2019-04-23 01:42:59   version         V 1.26.06 a-culfw Build: 315 (2019-04-07_19-59-48) nanoCUL868 (F-Band: 868MHz)
   XMIT_TIME:
     1556047362.06549
     1556047407.37769
     1556047527.26244
     1556047539.0351
     1556047573.57862
     1556047715.99674
     1556047724.24955
     1556047725.53041
     1556047862.98791
     1556047946.19981
     1556047985.94834
     1556048123.62704
     1556048158.65125
     1556048302.37475
     1556048316.85236
     1556048460.55531
     1556048462.90947
     1556048479.83475
     1556048590.00918
     1556048656.77349
     1556048659.59991
     1556048768.96249
     1556048833.71128
     1556048856.40074
     1556048933.41305
     1556049010.64741
     1556049053.2336
     1556049083.37013
     1556049187.57545
     1556049219.08175
     1556049250.09288
     1556049340.27437
     1556049364.51238
     1556049446.97823
     1556049447.1773
     1556049447.37111
     1556049510.9777
     1556049541.44609
     1556049541.64517
     1556049541.83128
     1556049643.84738
     1556049667.42878
     1556049718.40223
     1556049809.39199
     1556049840.75465
     1556049895.32914
     1556049936.85034
     1556050037.65735
     1556050072.24882
     1556050114.05794
     1556050234.57398
     1556050249.17155
     1556050276.76246
     1556050424.97604
     1556050426.09013
     1556050431.50043
     1556050558.66473
     1556050603.00754
     1556050628.42558
     1556050742.12014
     1556050779.92376
     1556050825.36202
     1556050911.08373
     1556050956.83489
   helper:
     000000:
       QUEUE:
     444003:
       QUEUE:
     444029:
       QUEUE:
     5F4B27:
       QUEUE:
     613D91:
       QUEUE:
Attributes:
   DbLogExclude .*
   hmId       310597
   rfmode     HomeMatic
   room       96_Geräte

Und der VCCU, falls benötigt:

Code Auswählen Erweitern

   DEF        310597
   FUUID      5c66ee05-f33f-38d4-6dd8-11cdfbb1f8b7f326
   IODev      nanoCUL
   NAME       VCCU
   NOTIFYDEV  global
   NR         21
   NTFY_ORDER 50-VCCU
   STATE      nanoCUL:ok
   TYPE       CUL_HM
   assignedIOs nanoCUL
   channel_01 VCCU_Btn1
   READINGS:
     2019-04-23 22:19:42   IOopen          1
     2019-04-23 00:38:44   R-pairCentral   set_0x000000
     2019-04-23 22:19:42   state           nanoCUL:ok
     2018-11-10 21:11:57   unknown_444003  received
     2018-11-10 20:59:50   unknown_444005  received
     2018-11-10 21:14:53   unknown_444029  received
     2018-11-08 23:17:14   unknown_5F4B27  received
     2019-02-05 22:20:28   unknown_613D91  received
   helper:
     HM_CMDNR   79
     mId        FFF0
     peerFriend peerSens,peerAct
     peerOpt    -:virtual
     regLst     0
     rxType     1
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     io:
       prefIO     
       vccu       VCCU
       ioList:
         nanoCUL
     mRssi:
       mNo       
     prt:
       bErr       0
       sProc      0
     q:
       qReqConf   
       qReqStat   
     role:
       dev        1
       vrt        1
     rssi:
     shadowReg:
     tmpl:
Attributes:
   DbLogExclude .*
   IODev      nanoCUL
   IOList     nanoCUL
   IOgrp      VCCU
   expert     2_raw
   model      CCU-FHEM
   room       96_Geräte
   subType    virtual
   webCmd     virtual:update

Und zu guter Letzt noch das "bereinigte"  (Sensor_Zelt ist zu ignorieren, da dort die Batterien versagt haben):

Code Auswählen Erweitern

missing register list
    Max_Heizung: RegL_00.
    Max_Heizung_Clima: RegL_01.,RegL_07.
    Max_Heizung_ClimaTeam: RegL_01.
    Max_Heizung_Climate: RegL_01.
    Max_Heizung_Weather: RegL_01.
    Max_Heizung_WindowRec: RegL_01.
    Max_Heizung_remote: RegL_01.
    Max_Tur: RegL_00.,RegL_01.
    Sensor_Zelt: RegL_00.
    Sensor_Zelt_Values: RegL_01.

peer list incomplete. Use getConfig to read it.
    incomplete: Max_Heizung_Clima:
    incomplete: Max_Heizung_ClimaTeam:
    incomplete: Max_Heizung_Climate:
    incomplete: Max_Heizung_Weather:
    incomplete: Max_Heizung_WindowRec:
    incomplete: Max_Heizung_remote:
    incomplete: Max_Tur:

peer not verified. Check that peer is set on both sides
    wz_vT_Sensor1 p:Max_Heizung_Weather

templist mismatch
    Max_Heizung_Clima: file: ./tempList.cfg error:Can't open ./tempList.cfg: No such file or directory

Nachdem ich mir das ganze mal angeschaut habe, scheint auch der Türsensor ja  keine Kommandos anzunehmen, lediglich sendet er Daten an den CUL.
Es scheint sich also nicht um das Thermostat zuhanden, sondern der Fehler liegt bei der Konfiguration der VCCU bzw. des CULs. Wobei es ja auch vor dem Wechsel auf die neue Firmware nicht funktioniert hat, bzw. der Fehler erst urplötzlich seit kurzem auftritt.

Im Endeffekt funktionierte es nicht, ich versuchte es mit der Firmware zu beheben, und es geht immernoch nicht. Vielleicht ein Fehler durch ein FHEM-Update?
Ich habe ja nichts verändert und seit dem Roommate-Debakel bin ich etwas zögerlich.

Grüße, Max

[Otto123]

Hallo Max,

warum das nicht funktioniert? Weil Homematic bidrectional kommuniziert, d.h. in beiden Richtungen erfordern die meisten Kommunikationsschritte eine ununterbrochene beidseitige Kommunikation. Jede Frage erfordert eine Antwort, jede Information eine Bestätigung. Gerade beim pairing gehen mehrere Frage/Antworten hin und her.

Wenn da zwischendurch die Tür zufällt ist die Kommunikation gestört. Sicher reicht deine Betriebsart aus um ab und an einen Temperaturwert vom Sensor zu empfangen, aber für viel mehr nicht.

Also tue Dir einen Gefallen und kauf Dir einen IO von Homematic und nutze den CUL für IT.
https://wiki.fhem.de/wiki/HomeMatic#FHEM_als_Zentrale

Gruß Otto

[bromosky]

Nabend Otto,

liege ich in der Annahme richtig, dass der CUL nur die Frequenz wechselt, wenn wirklich auch ein Befehl an eine IT-Steckdose versendet wird?
So müsste doch, sofern kein IT-Befehl versendet wird, eine vollumfängliche Kommunikation zwischen den Homematicgerätschaften und dem CUL möglich sein?
Ich habe nun, um diesen Fehler auszuschließen, dass Pairing nochmal angestoßen. Es funktionierte wieder nicht, obwohl keine Kommandos an die IT's gesendet wurden.

Sicherlich ist deine Art der Kommunikation mit HM-Geräten besser geeignet, da weniger fehleranfällig. Dennoch erschließt sich in meinem Falle nicht die Fehlerquelle. Ich bin ja nicht nur hier um das Ding zum Laufen zu bekommen, sondern weil ich es verstehen will und es mich ziemlich wurmt, es nicht in den Griff zu bekommen.

Grüße, Max.

[Otto123]

Es ist nicht meine Art der Kommunikation, es ist die von Homematic.
Deine Fehlerquelle ist der CUL und dessen Firmware! Die 7 Zeilen nach der Auflistung in dem kurzen Artikel, den ich verlinkt habe, hast Du gelesen?

Aber Du kannst gerne weiter probieren, wenn Du viel Glück hast wird das Pairing irgendwann funktionieren.
Vorher solltest Du in der VCCU folgendes tun

Code Auswählen Erweitern

set VCCU clear unknownDev
und in den Geräten vor neuen Pairingversuch :

Code Auswählen Erweitern

set <> clear msgEvents

Edit:
Unklar ist mir wieso deine VCCU diese Reading hat:

Code Auswählen Erweitern

     2019-04-23 00:38:44   R-pairCentral   set_0x000000

Keine Ahnung wie so etwas passiert
Woher hast Du diese hmId ?   
DEF        310597
Hast Du die schon immer? Hast Du die gewählt? Oder hat die eines Deiner Geräte?
Warum musst Du nach dem CUL Wechsel eigentlich neu pairen?

Gruß Otto

[pc1246]

Moin
@Otto: HM und IT parallel geht schon immer mit dem CUL, der schaltet beim Senden um. Das der CUL halt nicht das IODev der Wahl ist, steht auf einem anderen Blatt, und haben wir jetzt ausreichend eroertert.

@bromosky: Du solltest mal sehen, dass Du Deine devices alle der Reihe nach anlernst. Denn von den beiden Gezeigten ist keiner fertig gepaired. Ruhe und Geduld, sowie eine erneute Lektuere ueber das Pairen sollten Dich zum Ziel fuehren. Wenn Du die devices jedesmal resettest, dann kommst Du natuerlich in einen Teufelskreis! Zudem hast Du mit dem HM-Sec-SCO und dem HM-CC-RT-DN zwei Diven, die schon gerne mehrere Anlaeufe brauchen. Ganz nebenbei, der HM-Sec-SCO ist ein Twostate und nicht Threestate!
Du solltest jetzt einfach mal Ottos Hinweis folgen, und die ganzen Meldungen loeschen, und dann langsam von vorne anfangen, bis das set_0x310597 und CMDs_pending weg ist, und dann zum naechsten device gehen.
Gruss Christoph

[bromosky]

Guten Morgen,

es bedurfte einer weiteren Nachtschicht und einem Backup aus dem Jahre 2018 und schon ließen sich die Geräte wieder pairen.
Alles schien reibungslos zu funktionieren. Nach einem Update all und einem shutdown restart fingen dann wieder die Probleme an.
Ich bin nun dabei, das Backup erneut aufzuspielen und werde diesesmal kein Update ausführen. Ich hatte ja sowieso die Vermutung, dass mir das Update neulich irgendwas gehörig zerschossen hätte.
Ich halte euch aber auf dem Laufenden, ob das wirklich der Weisheits letzter Schluss ist.

Schönen Tag euch allen, Max.

[Otto123]

Hallo Max,
Irgendwie verstehe ich diese Aussagen nicht mehr. Du pairest neu nachdem Du update gemacht hast? Oder was hast Du für Probleme nachdem alles "in Ordung" war und Du update und shutdown restart gemacht hast?

Es geht nur um Homematic Probleme?
Das Du die vorhergehende Version beliebiger, auch einzelner Modul Dateien nach einem update mit restore in sekunden (ohne Nachtschicht  ) wiederherstellen kannst, weißt Du?

Gruß Otto

[bromosky]

Ich melde mich nun auch mal wieder zu Wort.

Vorab, es funktioniert mittlerweile fast alles Tadellos wieder. Der Türsensor zickt zwar, aber ich bin mir sicher, das ich das pairen einfach ein paar mal, wie von @pc1246 beschrieben, behoben bekomme.
Ich habe wieder das Backup als Ausgang benutzt. Ein restore habe ich natürlich mehrfach ausprobiert. Es wollte jedoch nicht den Fehler beheben. Ich nehme an,  da mein CUL seit ca 1,5 Monaten gelegentlich ausfällt, ohne jegliche Änderung an ihm vorgenommen zu haben, das Problem sich irgendwo in FHEM eingeschlichen hat. Dies ist jedoch nur eine Vermutung.
Jedenfalls war es mir möglich, Sensoren und Thermostat alle zu pairen (wie gesagt mit Ausnahme des Türsensors, welcher jedoch den state sendet und mehr brauche ich ja auch nicht). Es ist also alles wieder funktionstüchtig. Nur woran es jetzt genau lag, kann ich noch nicht sagen. Ich werde jetzt, wo ich wirklich alles beim Alten habe, ein Backup machen und dann einfach alles updaten außer den Homematic.pm. Ein Versuch ists ja wert. Jedenfalls hat es nichts mit der Firmware des Sticks oder mit Fehlern der Homematic-Geräte zutun sondern es muss ein Softwarefehler in irgendeinem FHEM-Modul sein.

Das ist der neuste Stand. Ich danke euch Otto und pc1246 für eure Hilfe soweit.

@Otto123
Nein, ich paire nicht neu nach einem Update. Nach einem Update waren die Geräte schlicht nicht mehr gepairt. Shutdown restart wurde natürlich gemacht.
Ich wusste aber dennoch nicht, dass ich einzelne Module wiederherstellen kann aus einem restore?! Ich habe in der commandref gesucht und entweder hatte ich mal wieder Tomaten auf den Augen oder dazu steht nichts?
Wie gesagt, ich werde nach einem Backup die HM.pm ausklammern und dann wissen wir, ob es wirklich an dem Modul liegt.

Grüße, Max.

[Otto123]

Hallo Max,

pairen ist ein Vorgang, bei dem die Zentrale (FHEM) und dein HM Geräte die hmId "austauschen"/gegenseitig bekannt geben. D.h. FHEM kennt seine hmId aus der Definition, das Gerät hat anschließend seine hmId im eigenen Speicher. Das so etwas flächendeckend verloren geht, kann ich mir nicht vorstellen. Bei einzelnen Geräten soll das schon vorgekommen sein.
Es gibt den Fall, das Definition aus FHEM verschwinden, weil ein Update / Modul fehlerhaft war. Hat aber nichts mit pairen zu tun.

Zum restore (ja die Doku ist knapp)  Aber wie so oft kann man einfach ein bisschen rumprobieren um Klarheit zu schaffen.
Gib einfach mal

Code Auswählen Erweitern

restore listin der FHEM Kommandozeile ein.
Dann

Code Auswählen Erweitern

restore list update
Dann mit einem dort angezeigtem Pfad, z.B.

Code Auswählen Erweitern

restore list update/2019-03-23Dann weiter

Code Auswählen Erweitern

restore list update/2019-03-23/FHEM Das Restore von einer Datei ginge so. Beispiel:

Code Auswählen Erweitern

restore update/2019-03-23/FHEM/10_CUL_HM.pm

Achtung manche Module brauchen mehrere Dateien um konsistent zu funktionieren!
Beispiel:
HMConfig.pm + 10_CUL_HM.pm

Gruß Otto

[MadMax-FHEM]

Wie Otto schon geschrieben hat (daher habe ich das "damals" nicht auch noch "bestätigt") und ich (leidlich) selbst erfahren habe ist ein CUL wirklich nichts für Homematic!

Kann klappen (eine Weile) bis: fhem anderes Timing hat/bekommt (was du als "Bug" interpretieren könntest) oder ein Gerät um die Ecke kommt, was eben (noch) empfindlich(er) auf Timing reagiert...

Bei mir war es "damals" der Klingelsensor...

Alles lief gut nur der wollte ums verr.... nicht

Dann bin ich auf die Timing-optimierte FW umgestiegen...
...damit ging dann auch dieses neue (empfindliche) Gerät.

Letzenendes bin ich dann auf eine "vernünftige" IO-/Funk-HW umgestiegen (in meinem Fall: HM-CFG-USB bzw. mittlerweile HMOD-PCB).

Weil folgendes der Fall ist:

Bei Verwendung eines CUL ist dieser "nur" ein Funkmodul.
Die ganzen Telegramme usw. kommen aus fhem.
Wenn fhem etwas langsam reagiert (und das Gerät empfindlich ist), kommen eben (manchmal) ACKS (weil Homematic ist bidirektional: Frage/Befehl - Antwort/ACK) zu spät und dann geht das schief.

Die "timing-optimierte" FW (zusammen mit Anpassungen in Homematic-Modulen) "entspannt" das (etwas) aber es bleibt vom Ablauf wie es ist...
Fhem etwas "langsam" und schon kann ein Problem kommen.
(daher ist auch das zwischendrin senden in anderen Frequenzen nicht gut: weil auch hier währenddessen Meldungen verloren gehen können / nicht müssen: kann klappen kann aber auch schief gehen)

Bei Verwendung eines "echten" Homematic-IOs werden die Acks direkt von dem "Funkmodul" gesendet. D.h. es ist "entkoppelt" von fhem (zumindest bzgl. ACKS) d.h. wenn ein Gerät Daten schickt werden die Pakete (bis zu einem gewissen Grad) gepuffert und schon mal quittiert. D.h. fhem kann sich "etwas Zeit lassen" diese zu bearbeiten...

Daher ist es vermutlich kein (echter) Bug in der neuen fhem Version, sondern (natürlich) ein anderes Timing was eben zu (diesen) Problemen führt (führen kann).

Aber wie immer (da wir ja in einer freien Welt leben und auch fhem "offen" ist): dein System! Lass es laufen, wie es für dich passt...

Gruß, Joachim

[bromosky]

Ich war zu vorlaut und zu voreilig.
Es geht wieder nicht, ohne jegliches zutun. Ihr scheint wirklich alle recht zu haben. Es muss irgendwo einen Fehler in der Kommunikation geben. FHEM hat ja nichts geändert.
Ich war damals froh, den nanoCUL zusammgeschustert zu bekommen und eine günstige Lösung für die Kommunikation gefunden zu haben. Anscheinend ist nun der Punkt gekommen, wo es heißt, kaufste billig, kaufste zwei mal. Ärgerlich, aber nun ist das Kind ja in den Brunnen gefallen.

Der Bausatz HM-MOD-RPI-PCB ist wohl also des Rätsels Lösung. Solangsam wird mir wohl auch die Zeit zu schade (und mein Schlaf zu knapp).
Dort heißt es dann einfach zusammenlöten, aufstecken, in FHEM definieren und mit der VCCU verbinden und alles sollte wieder gehen?
Oder stelle ich mir das jetzt viel zu leicht vor? Denn bei dem lesen des Wikis zu der GPIO-Variante kommen mir ziemlich viele Fragen auf.

Grüße und nochmals vielen Dank für eure Hilfe, besonders an Otto für sein restore-Exkurs. Wieso findet man sowas weder im Wiki noch im Commandref.
Max.

EDIT: Wenn ich mich, an den Blogbeitrag von dir Otto, entlanghangel, so ist es mir möglich die GPIO-Variante auch an dem gleichen RaspberryPi zu betreiben, auf dem auch FHEM läuft, richtig?

[MadMax-FHEM]

Anscheinend ist nun der Punkt gekommen, wo es heißt, kaufste billig, kaufste zwei mal. Ärgerlich, aber nun ist das Kind ja in den Brunnen gefallen.

Ging mir auch so...
...bzw. hatte ich den nanoCUL "parallel" zum Spielen (Testsystem)...
Bis es mir dann zu dumm wurde

ABER: bei dir kann/muss er ja für die anderen Aufgaben (IT oder so) bleiben. War also nicht ganz "umsonst". Und: jetzt kann er sich daruf konzentrieren. Bzw. mit einem anderen Funkmodul (433MHz) sogar richtig gut

Der Bausatz HM-MOD-RPI-PCB ist wohl also des Rätsels Lösung. Solangsam wird mir wohl auch die Zeit zu schade (und mein Schlaf zu knapp).
Dort heißt es dann einfach zusammenlöten, aufstecken, in FHEM definieren und mit der VCCU verbinden und alles sollte wieder gehen?
Oder stelle ich mir das jetzt viel zu leicht vor? Denn bei dem lesen des Wikis zu der GPIO-Variante kommen mir ziemlich viele Fragen auf.

So der Plan...
...der eigentlich so funktionieren sollte.

Grüße und nochmals vielen Dank für eure Hilfe, besonders an Otto für sein restore-Exkurs. Wieso findet man sowas weder im Wiki noch im Commandref.

Jep, danke.
Wusste ich auch noch nicht

EDIT: Wenn ich mich, an den Blogbeitrag von dir Otto, entlanghangel, so ist es mir möglich die GPIO-Variante auch an dem gleichen RaspberryPi zu betreiben, auf dem auch FHEM läuft, richtig?

Hab mich zwar nicht entlang gehangelt

Aber betreibe 2 HMOD-PCB:

einen als Aufsteckmodul auf dem selben PI wo auch fhem läuft (Testsystem 1)

und einen per USB-Adapter auch auf dem selben PI auf dem fhem läuft (Testsystem 2)

Gruß, Joachim

[Otto123]

Im Wiki stehen viele Möglichkeiten.
Grundlegend lötest Du den zusammen und steckst ihn auf die Gpio am den Pi. VCCU hast Du schon, geht damit nahtlos.

Wenn Du fragen zu dem was im Wiki steht oder zu meinem Text (der im Wiki ist auch in Stücken von mir), dann frag einfach

Gruß Otto

P.S. Joachim   
P.P.S. Ja das mit dem restore "Kurs" steht schon lange auf meiner toDo Liste - kommt bald versprochen

[bromosky]

Hallo,

ich habe mich gestern an den Lötkolben gesetzt und es funktioniert alles mit der HMOD-PCB. Alles lies sich wunderbar pairen. Überhaupt gar keine Probleme mehr. Einfach die VCCU auf den anderen Sender umgestellt und fertig wars. Der nanoCUL läuft nun nur noch für IT.
Ich verstehe auch absolut nicht, wieso man so häufig von den CUL's im Homematic-Bereich etwas liest, wenn die HMOD-PCB etwa gleichteuer ist und anscheinend deutlich weniger Fehlerpotential bietet.

Danke nochmals an Otto, für seinen tollen Blogbeitrag. Einfach einmal die wichtigsten Schritte gemacht. Überhaupt kein Hexenwerk. Danke!
Und danke auch an die anderen, die sich hier gemeldet hatten.

Kurzer Lösungsansatz:

Durch falsches Timing kann es offensichtlich zu Fehlern bei der Kommunikation zwischen CUL's und HM-Geräten kommen.
Dieser lies sich bei mir leider nicht mehr beheben, weder durch restore, noch durch mehrmalig erneutes Pairen mit dem nanoCUL.

Die Lösung, welche korrekte Timings herstellen kann und bei mir das Problem gelöst hat, war der Selbstbausatz HMOD-PCB-RPI.
Fix zusammengelötet und folgendes Softwaretechnisch gemacht (Alle Befehle von @Otto123):
Bei mir handelt es sich um einen Raspberry Pi 3B+, deshalb musste ich ergänzen mit:

Code Auswählen Erweitern

sudo nano /boot/config.txt folgenden Text:

Code Auswählen Erweitern

enable_uart=1
dtoverlay=pi3-miniuart-bt
force_turbo=1

Aus

Code Auswählen Erweitern

sudo nano /boot/cmdline.txt löschte ich dann

Code Auswählen Erweitern

console=serial0,115200
Danach

Code Auswählen Erweitern

sudo systemctl disable serial-getty@ttyAMA0.service
Zuletzt noch mit

Code Auswählen Erweitern

sudo nano /etc/init.d/fhem folgendes Einfügen:

Code Auswählen Erweitern

sleep 10
Weiter in der Console mit:

Code Auswählen Erweitern

wget https://raw.githubusercontent.com/eq-3/occu/ee68faf77e42ed5e3641790b43a710a3301cea7e/firmware/HM-MOD-UART/coprocessor_update.eq3 und

Code Auswählen Erweitern

sudo cp coprocessor_update.eq3 /opt/fhem/FHEM/firmware/
Einmal Neustarten mit

Code Auswählen Erweitern

sudo reboot

In FHEM folgt dann:

Code Auswählen Erweitern

define myHmUART HMUARTLGW /dev/ttyAMA0
attr myHmUART hmId xxxxxx <- Die x mit Hexadezimal ersetzen, sprich eure gewünschte HMid

Code Auswählen Erweitern

set myHmUART updateCoPro /opt/fhem/FHEM/firmware/coprocessor_update.eq3 Flasht neue Firmware auf eure HMOD-PCB. Das hat bei mir beim ersten mal nicht funktioniert. Einfach 5 Minuten warten, nochmal den Befehl in FHEM senden. Bei Bedarf wiederholen.

Und dann hat es bei mir tadellos funktioniert, nachdem ich bei der VCCU die gleiche HMid eingegeben habe, wie bei der HMUARTLGW.
Otto hat noch weitere Tipps und Tricks in seinem Blogbeitrag verewigt, falls es nach diesen Befehlen nicht funktioniert, kann ich euch nur wärmstens empfehlen, sich dort mal alles durchzulesen. Auch für die Leute, die die Hintergründe für die Befehle wissen wollen, ist der Blogbeitrag sehr zu empfehlen.
Ich hoffe, ich konnte etwas helfen.

Grüße, Max