HM-CC-RT-DN gepaired und Missing Ack [solved]

Begonnen von linuxpaul, 09 November 2017, 21:07:13

Vorheriges Thema - Nächstes Thema

linuxpaul

Hi Forum,

Hab nach einigen Versuchen (airen, löschen, wieder von vorne) meinen HM-CC-RT-DN gepaired bekommen, gibt ja schon massig Posts dazu.
Habe nun aber laufend Missing Acks.

List:
nternals:
   CFGFN
   CUL_Cube_Lan_MSGCNT 51
   CUL_Cube_Lan_RAWMSG A0F26861042C2340000000AA8ED0B0000::-51.5:CUL_Cube_Lan
   CUL_Cube_Lan_RSSI -51.5
   CUL_Cube_Lan_TIME 2017-11-09 20:46:36
   DEF        42C234
   IODev      CUL_Cube_Lan
   LASTInputDev CUL_Cube_Lan
   MSGCNT     51
   NAME       Bad_Heizung
   NOTIFYDEV  global
   NR         175
   STATE      CMDs_pending
   TYPE       CUL_HM
   channel_01 Bad_Heizung_Weather
   channel_02 Bad_Heizung_Climate
   channel_03 Bad_Heizung_WindowRec
   channel_04 Bad_Heizung_Clima
   channel_05 Bad_Heizung_ClimaTeam
   channel_06 Bad_Heizung_remote
   lastMsg    No:26 - t:10 s:42C234 d:000000 0AA8ED0B0000
   protCmdDel 42
   protCmdPend 14 CMDs pending
   protLastRcv 2017-11-09 20:46:36
   protResnd  14 last_at:2017-11-09 20:46:41
   protResndFail 3 last_at:2017-11-09 20:13:07
   protSnd    37 last_at:2017-11-09 20:46:36
   protState  CMDs_pending
   rssi_at_CUL_Cube_Lan avg:-52.65 cnt:51 lst:-51.5 max:-51.5 min:-56.5
   READINGS:
     2017-11-09 20:05:03   Activity        alive
     2017-11-09 19:46:01   CommandAccepted yes
     2017-11-09 19:37:51   D-firmware      1.4
     2017-11-09 19:37:51   D-serialNr      MEQ1557476
     2017-11-09 19:46:02   PairedTo        0x230369
     2017-11-09 19:46:02   R-backOnTime    10 s
     2017-11-09 19:46:02   R-burstRx       on
     2017-11-09 19:46:02   R-cyclicInfoMsg on
     2017-11-09 19:46:02   R-cyclicInfoMsgDis 0
     2017-11-09 19:46:02   R-pairCentral   0x230369
     2017-11-09 20:46:36   actuator        0
     2017-11-09 20:46:36   battery         ok
     2017-11-09 20:46:36   batteryLevel    2.6
     2017-11-09 20:46:36   desired-temp    21.0
     2017-11-09 20:46:36   measured-temp   23.7
     2017-11-09 20:46:36   motorErr        ok
     2017-11-09 20:46:41   state           CMDs_pending
     2017-11-09 19:38:23   time-request    -
   cmdStack:
     ++A00123036942C23400040000000000
     ++A00123036942C2340103
     ++A00123036942C23401040000000001
     ++A00123036942C2340203
     ++A00123036942C23402040000000001
     ++A00123036942C2340303
     ++A00123036942C23403040000000001
     ++A00123036942C2340403
     ++A00123036942C23404040000000001
     ++A00123036942C23400040000000007
     ++A00123036942C2340503
     ++A00123036942C23405040000000001
     ++A00123036942C2340603
     ++A00123036942C23406040000000001
   helper:
     HM_CMDNR   39
     PONtest    1
     cSnd       0123036942C23404040000000001,0123036942C23400040000000007
     mId        0095
     rxType     140
     supp_Pair_Rep 0
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     io:
       newChn     +42C234,02,00,00
       nextSend   1510256796.15606
       prefIO
       rxt        2
       vccu
       p:
         42C234
         00
         00
         00
     mRssi:
       mNo        26
       io:
         CUL_Cube_Lan -49.5
     prt:
       bErr       0
       sProc      2
       wuReSent   4
     q:
       qReqConf
       qReqStat
     role:
       dev        1
       prs        1
     rssi:
       at_CUL_Cube_Lan:
         avg        -52.656862745098
         cnt        51
         lst        -51.5
         max        -51.5
         min        -56.5
     shRegW:
       07         04
     shadowReg:
     tmpl:
Attributes:
   IODev      CUL_Cube_Lan
   IOgrp      VCCU:CUL_Cube_Lan
   actCycle   000:30
   actStatus  alive
   autoReadReg 4_reqStatus
   expert     2_raw
   firmware   1.4
   icon       hm-cc-rt-dn
   model      HM-CC-RT-DN
   room       Bad,Hardware
   serialNr   MEQ1557476
   subType    thermostat
   webCmd     getConfig:clear msgEvents:burstXmit


Hab den sniffer aktiviert und sehe das:
2017.11.09 20:39:15.814 4: CUL_Parse: CUL_Cube_Lan A 0F 23 8610 42C234 000000 0AA8EF0B00002C -52
2017.11.09 20:39:46.039 4: CUL_Parse: CUL_Cube_Lan V 1.20.06 a-culfw Build: 199 (2016-02-21_13-36-20) CUBe (F-Band: 868MHz)
2017.11.09 20:40:16.263 4: CUL_Parse: CUL_Cube_Lan V 1.20.06 a-culfw Build: 199 (2016-02-21_13-36-20) CUBe (F-Band: 868MHz)
2017.11.09 20:40:46.488 4: CUL_Parse: CUL_Cube_Lan V 1.20.06 a-culfw Build: 199 (2016-02-21_13-36-20) CUBe (F-Band: 868MHz)
2017.11.09 20:41:16.713 4: CUL_Parse: CUL_Cube_Lan V 1.20.06 a-culfw Build: 199 (2016-02-21_13-36-20) CUBe (F-Band: 868MHz)
2017.11.09 20:41:46.938 4: CUL_Parse: CUL_Cube_Lan V 1.20.06 a-culfw Build: 199 (2016-02-21_13-36-20) CUBe (F-Band: 868MHz)
2017.11.09 20:41:57.095 4: CUL_Parse: CUL_Cube_Lan A 0F 24 8610 42C234 000000 0AA8EF0B000026 -55
2017.11.09 20:42:24.347 4: CUL_Parse: CUL_Cube_Lan A 0D E9 A610 409137 230369 0601000000 -74
2017.11.09 20:42:24.595 4: CUL_Parse: CUL_Cube_Lan A 0D EA A610 409137 230369 0601000001 -73.5
2017.11.09 20:42:25.338 4: CUL_Parse: CUL_Cube_Lan A 0D EB A610 409137 230369 06010000FF -74.5
2017.11.09 20:42:26.081 4: CUL_Parse: CUL_Cube_Lan A 0D EC A610 409137 230369 0601000000 -74
2017.11.09 20:42:27.320 4: CUL_Parse: CUL_Cube_Lan A 0D ED A610 409137 230369 06010000FF -74.5
2017.11.09 20:42:28.559 4: CUL_Parse: CUL_Cube_Lan A 0D EE A610 409137 230369 0601000001 -73.5
2017.11.09 20:42:58.783 4: CUL_Parse: CUL_Cube_Lan V 1.20.06 a-culfw Build: 199 (2016-02-21_13-36-20) CUBe (F-Band: 868MHz)
2017.11.09 20:43:29.008 4: CUL_Parse: CUL_Cube_Lan V 1.20.06 a-culfw Build: 199 (2016-02-21_13-36-20) CUBe (F-Band: 868MHz)
2017.11.09 20:43:59.233 4: CUL_Parse: CUL_Cube_Lan V 1.20.06 a-culfw Build: 199 (2016-02-21_13-36-20) CUBe (F-Band: 868MHz)
2017.11.09 20:44:23.760 4: CUL_Parse: CUL_Cube_Lan A 0F 25 8610 42C234 000000 0AA8ED0B000029 -53.5
2017.11.09 20:44:29.458 4: CUL_Parse: CUL_Cube_Lan A 0D 2C A610 4341C0 230369 06010000F6 -79
2017.11.09 20:44:29.671 4: CUL_Parse: CUL_Cube_Lan A 0D 2D A610 4341C0 230369 06010000F6 -79
2017.11.09 20:44:30.201 4: CUL_Parse: CUL_Cube_Lan A 0D 2E A610 4341C0 230369 06010000F7 -78.5


Ähhh bei 42C234 steht eine 000000? doch nicht gepaired?

Was soll man hier tun?

(CUL_Cube_Lan ist ein geflashter Max Cube als CUN)

:)
linuxpaul

popperchris

Guten Morgen
das gleich Problem habe ich auch.
Habe ein neues Thermostat über EBay ersteigert und dann an FHEM angelernt.
set CUL_0 hmPairForSec 600 und dann an dem Thermostat die entsprechende Taste gedrückt. Der fängt dann an von 30 runterzuzählen. Nach ca 2 Sekunden zeigt der Thermostat "ACK". Das Device wird auch in FHEM angelegt.

Ich sehe auch in FHEM die Soll eingestellte Temperatur, die Soll Temperatur und auch wie weit das Thermostat offen ist. Dies wird auch regelmäßig aktualisiert.

Schicke ich aber dem Thermostat irgendwelche Befehle kommt entweder "MISS_ACK" bzw jetzt steht der Status auf "CMD_PENDING".

Habe das Teil schon zweimal aus FHEM gelöscht, das Thermostat auf Werkseinstellungen zurückgesetzt und wieder im FHEM angelernt. Alles ohne Erfolg.

Auch bei den anderen beiden Thermostaten geht es nicht mehr

Gruß
Christoph

popperchris

Habe nochmal rumprobiert.

Habe im restoredir noch Dateien liegen. Spiele ich die vom 03.11.2017 wieder ein geht das ganze wieder.

linuxpaul

Leider habe ich keine alte config, wo der rt funktioniert.

Nu heute wieder das Gerät zurückgesetzt, das Gerät in FHEM gelöscht, wieder gepaired und mit gesniffed
2017.11.10 17:07:45.327 4: CUL_Parse: CUL_Cube_Lan A 0C 99 A641 4341C0 230369 010FC8FB -76.5
2017.11.10 17:07:45.329 5: CUL_Cube_Lan: dispatch A0C99A6414341C0230369010FC8::-76.5:CUL_Cube_Lan
2017.11.10 17:07:45.335 5: CUL_Cube_Lan sending As0A9980022303694341C000
2017.11.10 17:07:45.336 5: CUL 4341C0 dly:92ms
2017.11.10 17:07:45.429 5: SW: As0A9980022303694341C000
2017.11.10 17:07:45.432 5: CUL_Cube_Lan sending As0D9980022303694341C00101C800
2017.11.10 17:07:45.433 5: SW: As0D9980022303694341C00101C800
2017.11.10 17:07:58.151 3: CUL_HM set VCCU hmPairForSec 60
2017.11.10 17:08:05.883 5: CUL/RAW: /A1A01840042C2340000001400954D4551313535373437365900FFFF1E

2017.11.10 17:08:05.884 4: CUL_Parse: CUL_Cube_Lan A 1A 01 8400 42C234 000000 1400954D4551313535373437365900FFFF1E -59
2017.11.10 17:08:05.886 5: CUL_Cube_Lan: dispatch A1A01840042C2340000001400954D4551313535373437365900FFFF::-59:CUL_Cube_Lan
2017.11.10 17:08:06.047 5: CUL_Cube_Lan sending As1029A00123036942C23400050000000000
2017.11.10 17:08:06.048 5: SW: As1029A00123036942C23400050000000000
2017.11.10 17:08:06.378 5: CUL/RAW: /A0A29800242C2342303690022

2017.11.10 17:08:06.379 4: CUL_Parse: CUL_Cube_Lan A 0A 29 8002 42C234 230369 0022 -57
2017.11.10 17:08:06.380 5: CUL_Cube_Lan: dispatch A0A29800242C23423036900::-57:CUL_Cube_Lan
2017.11.10 17:08:06.540 5: CUL_Cube_Lan sending As132AA00123036942C234000802010A230B030C69
2017.11.10 17:08:06.541 5: SW: As132AA00123036942C234000802010A230B030C69
2017.11.10 17:08:06.874 5: CUL/RAW: /A0A2A800242C234230369002A

2017.11.10 17:08:06.875 4: CUL_Parse: CUL_Cube_Lan A 0A 2A 8002 42C234 230369 002A -53
2017.11.10 17:08:06.877 5: CUL_Cube_Lan: dispatch A0A2A800242C23423036900::-53:CUL_Cube_Lan
2017.11.10 17:08:06.881 5: CUL_Cube_Lan sending As0B2BA00123036942C2340006
2017.11.10 17:08:06.882 5: CUL 42C234 dly:93ms
2017.11.10 17:08:06.976 5: SW: As0B2BA00123036942C2340006
2017.11.10 17:08:07.370 5: CUL/RAW: /A0A2B800242C2342303690029

2017.11.10 17:08:07.370 4: CUL_Parse: CUL_Cube_Lan A 0A 2B 8002 42C234 230369 0029 -53.5
2017.11.10 17:08:07.372 5: CUL_Cube_Lan: dispatch A0A2B800242C23423036900::-53.5:CUL_Cube_Lan
2017.11.10 17:08:37.347 5: CUL/RAW: /A0901A03F42C23423036929

2017.11.10 17:08:37.348 4: CUL_Parse: CUL_Cube_Lan A 09 01 A03F 42C234 230369 29 -53.5
2017.11.10 17:08:37.350 5: CUL_Cube_Lan: dispatch A0901A03F42C234230369::-53.5:CUL_Cube_Lan
2017.11.10 17:08:37.355 5: CUL_Cube_Lan sending As0F01803F23036942C234020421987D75
2017.11.10 17:08:37.356 5: CUL 42C234 dly:92ms
2017.11.10 17:08:37.449 5: SW: As0F01803F23036942C234020421987D75
2017.11.10 17:08:39.824 5: CUL/RAW: /A0F04861042C2342303690AA8EF0A000029

2017.11.10 17:08:39.825 4: CUL_Parse: CUL_Cube_Lan A 0F 04 8610 42C234 230369 0AA8EF0A000029 -53.5
2017.11.10 17:08:39.827 5: CUL_Cube_Lan: dispatch A0F04861042C2342303690AA8EF0A0000::-53.5:CUL_Cube_Lan
2017.11.10 17:08:40.032 5: CUL_Cube_Lan sending As0905A11223036942C234
2017.11.10 17:08:40.033 5: SW: As0905A11223036942C234
2017.11.10 17:09:10.049 5: CUL/RAW: /V 1.20.06 a-culfw Build: 199 (2016-02-21_13-36-20) CUBe (F-Band: 868MHz)

2017.11.10 17:09:10.049 4: CUL_Parse: CUL_Cube_Lan V 1.20.06 a-culfw Build: 199 (2016-02-21_13-36-20) CUBe (F-Band: 868MHz)
2017.11.10 17:09:40.274 5: CUL/RAW: /V 1.20.06 a-culfw Build: 199 (2016-02-21_13-36-20) CUBe (F-Band: 868MHz)

2017.11.10 17:09:40.274 4: CUL_Parse: CUL_Cube_Lan V 1.20.06 a-culfw Build: 199 (2016-02-21_13-36-20) CUBe (F-Band: 868MHz)
2017.11.10 17:09:56.377 5: CUL/RAW: /A0D9AA6104341C02303690601C800FD

2017.11.10 17:09:56.378 4: CUL_Parse: CUL_Cube_Lan A 0D 9A A610 4341C0 230369 0601C800FD -75.5
2017.11.10 17:09:56.380 5: CUL_Cube_Lan: dispatch A0D9AA6104341C02303690601C800::-75.5:CUL_Cube_Lan
2017.11.10 17:09:56.578 5: CUL_Cube_Lan sending As0A9A80022303694341C000
2017.11.10 17:09:56.579 5: SW: As0A9A80022303694341C000
2017.11.10 17:09:56.606 5: CUL/RAW: /A0D9BA6104341C02303690601C800FD

2017.11.10 17:09:56.607 4: CUL_Parse: CUL_Cube_Lan A 0D 9B A610 4341C0 230369 0601C800FD -75.5
2017.11.10 17:09:56.608 5: CUL_Cube_Lan: dispatch A0D9BA6104341C02303690601C800::-75.5:CUL_Cube_Lan
2017.11.10 17:09:56.612 5: CUL_Cube_Lan sending As0A9B80022303694341C000
2017.11.10 17:09:56.612 5: CUL 4341C0 dly:94ms
2017.11.10 17:09:56.708 5: SW: As0A9B80022303694341C000
2017.11.10 17:09:57.120 5: CUL/RAW: /A0D9CA6104341C02303690601C800FF

2017.11.10 17:09:57.121 4: CUL_Parse: CUL_Cube_Lan A 0D 9C A610 4341C0 230369 0601C800FF -74.5
2017.11.10 17:09:57.122 5: CUL_Cube_Lan: dispatch A0D9CA6104341C02303690601C800::-74.5:CUL_Cube_Lan
2017.11.10 17:09:57.126 5: CUL_Cube_Lan sending As0A9C80022303694341C000
2017.11.10 17:09:57.126 5: CUL 4341C0 dly:94ms
2017.11.10 17:09:57.222 5: SW: As0A9C80022303694341C000
2017.11.10 17:09:57.863 5: CUL/RAW: /A0D9DA6104341C02303690601C800FF

2017.11.10 17:09:57.864 4: CUL_Parse: CUL_Cube_Lan A 0D 9D A610 4341C0 230369 0601C800FF -74.5
2017.11.10 17:09:57.866 5: CUL_Cube_Lan: dispatch A0D9DA6104341C02303690601C800::-74.5:CUL_Cube_Lan
2017.11.10 17:09:57.871 5: CUL_Cube_Lan sending As0A9D80022303694341C000
2017.11.10 17:09:57.872 5: CUL 4341C0 dly:92ms
2017.11.10 17:09:57.965 5: SW: As0A9D80022303694341C000
2017.11.10 17:09:59.102 5: CUL/RAW: /A0D9EA6104341C02303690601C800FE

2017.11.10 17:09:59.103 4: CUL_Parse: CUL_Cube_Lan A 0D 9E A610 4341C0 230369 0601C800FE -75
2017.11.10 17:09:59.104 5: CUL_Cube_Lan: dispatch A0D9EA6104341C02303690601C800::-75:CUL_Cube_Lan
2017.11.10 17:09:59.109 5: CUL_Cube_Lan sending As0A9E80022303694341C000
2017.11.10 17:09:59.110 5: CUL 4341C0 dly:93ms
2017.11.10 17:09:59.204 5: SW: As0A9E80022303694341C000
2017.11.10 17:10:00.588 5: CUL/RAW: /A0D9FA6104341C02303690601C800FE

2017.11.10 17:10:00.589 4: CUL_Parse: CUL_Cube_Lan A 0D 9F A610 4341C0 230369 0601C800FE -75
2017.11.10 17:10:00.591 5: CUL_Cube_Lan: dispatch A0D9FA6104341C02303690601C800::-75:CUL_Cube_Lan
2017.11.10 17:10:00.596 5: CUL_Cube_Lan sending As0A9F80022303694341C000
2017.11.10 17:10:00.597 5: CUL 4341C0 dly:92ms
2017.11.10 17:10:00.691 5: SW: As0A9F80022303694341C000
2017.11.10 17:10:30.813 5: CUL/RAW: /V 1.20.06 a-culfw Build: 199 (2016-02-21_13-36-20) CUBe (F-Band: 868MHz)

2017.11.10 17:10:30.820 4: CUL_Parse: CUL_Cube_Lan V 1.20.06 a-culfw Build: 199 (2016-02-21_13-36-20) CUBe (F-Band: 868MHz)
2017.11.10 17:11:01.056 5: CUL/RAW: /V 1.20.06 a-culfw Build: 199 (2016-02-21_13-36-20) CUBe (F-Band: 868MHz)

2017.11.10 17:11:01.056 4: CUL_Parse: CUL_Cube_Lan V 1.20.06 a-culfw Build: 199 (2016-02-21_13-36-20) CUBe (F-Band: 868MHz)
2017.11.10 17:11:20.206 5: CUL/RAW: /A0F05861042C2340000000AA8F50B000029

2017.11.10 17:11:20.207 4: CUL_Parse: CUL_Cube_Lan A 0F 05 8610 42C234 000000 0AA8F50B000029 -53.5
2017.11.10 17:11:20.208 5: CUL_Cube_Lan: dispatch A0F05861042C2340000000AA8F50B0000::-53.5:CUL_Cube_Lan
2017.11.10 17:11:20.212 5: CUL_Cube_Lan sending As0906A11223036942C234
2017.11.10 17:11:20.213 5: CUL 42C234 dly:94ms
2017.11.10 17:11:20.308 5: SW: As0906A11223036942C234
2017.11.10 17:11:50.339 5: CUL/RAW: /V 1.20.06 a-culfw Build: 199 (2016-02-21_13-36-20) CUBe (F-Band: 868MHz)

2017.11.10 17:11:50.340 4: CUL_Parse: CUL_Cube_Lan V 1.20.06 a-culfw Build: 199 (2016-02-21_13-36-20) CUBe (F-Band: 868MHz)
2017.11.10 17:12:20.564 5: CUL/RAW: /V 1.20.06 a-culfw Build: 199 (2016-02-21_13-36-20) CUBe (F-Band: 868MHz)


42C234 ist der RT und der 4341C0 ein Fensterkontakt.

Für mich sieht das hier so aus als ob die Telegramme vom RT passen, bis der Fensterkontakt funkt.
Danach haben alle Telegramme des rt statt 230369 (HMID) ein 000000 im Telegram.
Später werde ich die Kontakte mal außer Betrieb nehmen und dann nochmal pairen.

Weiß sonst noch jemand was?

linuxpaul

OK, das Ergebnis

Wenn man vorher genau hinschaut, gibt es auh später noch Telegramme des rt mit 230369,
allerdings ist sowas immer dazwischen 0F 0B 8610 42C234 000000 0AF0E50B570025 -55.5

Wie kriegt man raus was da nicht passt?

linuxpaul

Cool, keiner eine Idee?

Hat FHEM das pairing verpasst?
Mittlerweile werden alle protCmdPend verwofen und mit Missing ACK quitier.
Guckt man nach einem clear MsgEvents und getConfig etwas tiefer das findest man:

protSnd 1 last_at:2017-11-11 12:15:47

und im LOG dazu:
2017.11.11 12:15:47.506 5: CUL/RAW: /A0F09861042C2340000000AA8E90A00002D
2017.11.11 12:15:47.508 4: CUL_Parse: CUL_Cube_Lan A 0F 09 8610 42C234 000000 0AA8E90A00002D -51.5
2017.11.11 12:15:47.510 5: CUL_Cube_Lan: dispatch A0F09861042C2340000000AA8E90A0000::-51.5:CUL_Cube_Lan
2017.11.11 12:15:47.719 5: CUL_Cube_Lan sending As090AA11223036942C234
2017.11.11 12:15:47.720 5: SW: As090AA11223036942C234

D.h. der rt weiß nach dem pairing die HMID, aber FHEM weiß nicht das rt es weiß?








linuxpaul

#6
Antwort: sieht so aus,
sicher das da kein Bug reingerutscht ist?

Hab zunächst den CUN wieder zum CUL gemacht und nochmal gelöscht und wieder gepaired.
Ergebnis leider wie vorher.

Dann habe ich die fehm.save entdeckt, fhem gestopt (/etc/init.d/fhem stop) und
fehm.save mit vi editiert so das sie diese beiden Zeilen enthält:

setstate HM_42C234 2017-11-11 22:02:07 PairedTo 0x230369
setstate HM_42C234 2017-11-11 22:02:07 R-pairCentral 0x230369

Dann fhem wieder gestartet und jetzt geht der rt wie 'ne 1.

2017.11.11 23:43:36.429 0: Server started with 55 defined entities (fhem.pl:15377/2017-11-01 perl:5.020002 os:linux user:fhem pid:11082)
2017.11.11 23:46:02.799 0: Server shutdown
2017.11.11 23:51:41.569 1: Including fhem.cfg
2017.11.11 23:51:45.269 1: Including ./log/fhem.save
2017.11.11 23:51:45.621 0: Featurelevel: 5.8
2017.11.11 23:51:45.622 0: Server started with 55 defined entities (fhem.pl:15377/2017-11-01 perl:5.020002 os:linux user:fhem pid:11126)
2017.11.11 23:54:45.382 4: CUL_Parse: CUL_Cube_Usb A 0F C0 8610 42C234 000000 0A88E90B00001F -58.5
2017.11.11 23:54:45.640 4: CUL_Parse: CUL_Cube_Usb A 0A C1 8002 42C234 230369 001F -58.5
2017.11.11 23:54:45.911 4: CUL_Parse: CUL_Cube_Usb A 1A C2 A010 42C234 230369 020101020109010A230B030C690E0A0F001F -58.5
2017.11.11 23:54:46.167 4: CUL_Parse: CUL_Cube_Usb A 18 C3 8010 42C234 230369 02110012151600180019001A0000001F -58.5
2017.11.11 23:54:46.428 4: CUL_Parse: CUL_Cube_Usb A 0E C4 8010 42C234 230369 01000000001F -58.5
2017.11.11 23:54:46.689 4: CUL_Parse: CUL_Cube_Usb A 0E C5 8010 42C234 230369 02080000001F -58.5
2017.11.11 23:54:46.950 4: CUL_Parse: CUL_Cube_Usb A 0E C6 8010 42C234 230369 01000000001F -58.5
2017.11.11 23:54:47.212 4: CUL_Parse: CUL_Cube_Usb A 0E C7 8010 42C234 230369 02080000001F -58.5
2017.11.11 23:54:47.473 4: CUL_Parse: CUL_Cube_Usb A 0E C8 8010 42C234 230369 01000000001F -58.5
2017.11.11 23:54:47.734 4: CUL_Parse: CUL_Cube_Usb A 0E C9 8010 42C234 230369 02080000001F -58.5
2017.11.11 23:54:47.996 4: CUL_Parse: CUL_Cube_Usb A 0E CA 8010 42C234 230369 01000000001F -58.5
2017.11.11 23:54:48.257 4: CUL_Parse: CUL_Cube_Usb A 0E CB 8010 42C234 230369 02080000001F -58.5
2017.11.11 23:54:48.530 4: CUL_Parse: CUL_Cube_Usb A 1A CC A010 42C234 230369 03012A22093D18030016073000640F05001F -58.5
2017.11.11 23:54:48.787 4: CUL_Parse: CUL_Cube_Usb A 1A CD A010 42C234 230369 03100000098E44485508452045204520451F -58.5
2017.11.11 23:54:49.045 4: CUL_Parse: CUL_Cube_Usb A 1A CE A010 42C234 230369 031F2045204520452045204520452045201E -59
2017.11.11 23:54:49.303 4: CUL_Parse: CUL_Cube_Usb A 1A CF A010 42C234 230369 032E4448550845204520452045204520451F -58.5
2017.11.11 23:54:49.560 4: CUL_Parse: CUL_Cube_Usb A 1A D0 A010 42C234 230369 033D20452045204520452045204448546C1F -58.5
2017.11.11 23:54:49.817 4: CUL_Parse: CUL_Cube_Usb A 1A D1 A010 42C234 230369 034C44CC550845204520452045204520451F -58.5
2017.11.11 23:54:50.074 4: CUL_Parse: CUL_Cube_Usb A 1A D2 A010 42C234 230369 035B204520452045204448546C44CC55081F -58.5
2017.11.11 23:54:50.332 4: CUL_Parse: CUL_Cube_Usb A 1A D3 A010 42C234 230369 036A4520452045204520452045204520451F -58.5
2017.11.11 23:54:50.590 4: CUL_Parse: CUL_Cube_Usb A 1A D4 A010 42C234 230369 03792045204448546C44CC5508452045201F -58.5
2017.11.11 23:54:51.105 4: CUL_Parse: CUL_Cube_Usb A 1A D4 A010 42C234 230369 03792045204448546C44CC5508452045201F -58.5
2017.11.11 23:54:51.362 4: CUL_Parse: CUL_Cube_Usb A 1A D5 A010 42C234 230369 03884520452045204520452045204520441F -58.5
2017.11.11 23:54:51.619 4: CUL_Parse: CUL_Cube_Usb A 1A D6 A010 42C234 230369 039748546C44CC550845204520452045201F -58.5
2017.11.11 23:54:51.876 4: CUL_Parse: CUL_Cube_Usb A 1A D7 A010 42C234 230369 03A6452045204520452045204448546C441F -58.5
2017.11.11 23:54:52.134 4: CUL_Parse: CUL_Cube_Usb A 1A D8 A010 42C234 230369 03B5CC55084520452045204520452045201E -59
2017.11.11 23:54:52.389 4: CUL_Parse: CUL_Cube_Usb A 17 D9 A010 42C234 230369 03C44520452045200F1E1E0F1E1E1F -58.5
2017.11.11 23:54:52.636 4: CUL_Parse: CUL_Cube_Usb A 0B DA 8010 42C234 230369 03001F -58.5
2017.11.11 23:54:52.898 4: CUL_Parse: CUL_Cube_Usb A 0E DB 8010 42C234 230369 01000000001F -58.5
2017.11.11 23:54:53.159 4: CUL_Parse: CUL_Cube_Usb A 0E DC 8010 42C234 230369 02080000001F -58.5
2017.11.11 23:54:53.421 4: CUL_Parse: CUL_Cube_Usb A 0E DD 8010 42C234 230369 01000000001F -58.5
2017.11.11 23:54:53.683 4: CUL_Parse: CUL_Cube_Usb A 0E DE 8010 42C234 230369 02080000001F -58.5
2017.11.11 23:57:02.133 4: CUL_Parse: CUL_Cube_Usb A 0F C1 8610 42C234 000000 0A88E90B00001F -58.5
2017.11.11 23:59:04.385 4: CUL_Parse: CUL_Cube_Usb A 0F C2 8610 42C234 000000 0A88E90B00001F -58.5
2017.11.11 23:59:04.642 4: CUL_Parse: CUL_Cube_Usb A 0A C3 8002 42C234 230369 001F -58.5
2017.11.11 23:59:04.914 4: CUL_Parse: CUL_Cube_Usb A 1A C4 A010 42C234 230369 020101020109010A230B030C690E0A0F001F -58.5
2017.11.11 23:59:05.170 4: CUL_Parse: CUL_Cube_Usb A 18 C5 8010 42C234 230369 02110012151600180019001A0000001F -58.5
2017.11.11 23:59:05.432 4: CUL_Parse: CUL_Cube_Usb A 0E C6 8010 42C234 230369 01000000001F -58.5
2017.11.11 23:59:05.694 4: CUL_Parse: CUL_Cube_Usb A 0E C7 8010 42C234 230369 02080000001F -58.5
2017.11.11 23:59:05.956 4: CUL_Parse: CUL_Cube_Usb A 0E C8 8010 42C234 230369 01000000001F -58.5
2017.11.11 23:59:06.217 4: CUL_Parse: CUL_Cube_Usb A 0E C9 8010 42C234 230369 02080000001F -58.5
2017.11.11 23:59:06.478 4: CUL_Parse: CUL_Cube_Usb A 0E CA 8010 42C234 230369 01000000001F -58.5
2017.11.11 23:59:06.740 4: CUL_Parse: CUL_Cube_Usb A 0E CB 8010 42C234 230369 02080000001F -58.5
2017.11.11 23:59:07.001 4: CUL_Parse: CUL_Cube_Usb A 0E CC 8010 42C234 230369 01000000001F -58.5
2017.11.11 23:59:07.263 4: CUL_Parse: CUL_Cube_Usb A 0E CD 8010 42C234 230369 02080000001F -58.5
2017.11.11 23:59:07.535 4: CUL_Parse: CUL_Cube_Usb A 1A CE A010 42C234 230369 03012A22093D18030016073000640F05001E -59
2017.11.11 23:59:07.793 4: CUL_Parse: CUL_Cube_Usb A 1A CF A010 42C234 230369 03100000098E44485508452045204520451F -58.5
2017.11.11 23:59:08.050 4: CUL_Parse: CUL_Cube_Usb A 1A D0 A010 42C234 230369 031F2045204520452045204520452045201F -58.5
2017.11.11 23:59:08.307 4: CUL_Parse: CUL_Cube_Usb A 1A D1 A010 42C234 230369 032E4448550845204520452045204520451F -58.5
2017.11.11 23:59:08.564 4: CUL_Parse: CUL_Cube_Usb A 1A D2 A010 42C234 230369 033D20452045204520452045204448546C1F -58.5
2017.11.11 23:59:08.822 4: CUL_Parse: CUL_Cube_Usb A 1A D3 A010 42C234 230369 034C44CC550845204520452045204520451F -58.5
2017.11.11 23:59:09.080 4: CUL_Parse: CUL_Cube_Usb A 1A D4 A010 42C234 230369 035B204520452045204448546C44CC55081F -58.5
2017.11.11 23:59:09.337 4: CUL_Parse: CUL_Cube_Usb A 1A D5 A010 42C234 230369 036A4520452045204520452045204520451F -58.5
2017.11.11 23:59:09.595 4: CUL_Parse: CUL_Cube_Usb A 1A D6 A010 42C234 230369 03792045204448546C44CC5508452045201F -58.5
2017.11.11 23:59:09.851 4: CUL_Parse: CUL_Cube_Usb A 1A D7 A010 42C234 230369 03884520452045204520452045204520441F -58.5
2017.11.11 23:59:10.109 4: CUL_Parse: CUL_Cube_Usb A 1A D8 A010 42C234 230369 039748546C44CC550845204520452045201E -59
2017.11.11 23:59:10.366 4: CUL_Parse: CUL_Cube_Usb A 1A D9 A010 42C234 230369 03A6452045204520452045204448546C441F -58.5
2017.11.11 23:59:10.624 4: CUL_Parse: CUL_Cube_Usb A 1A DA A010 42C234 230369 03B5CC55084520452045204520452045201F -58.5
2017.11.11 23:59:10.879 4: CUL_Parse: CUL_Cube_Usb A 17 DB A010 42C234 230369 03C44520452045200F1E1E0F1E1E1F -58.5
2017.11.11 23:59:11.126 4: CUL_Parse: CUL_Cube_Usb A 0B DC 8010 42C234 230369 03001F -58.5
2017.11.11 23:59:11.388 4: CUL_Parse: CUL_Cube_Usb A 0E DD 8010 42C234 230369 01000000001F -58.5
2017.11.11 23:59:11.651 4: CUL_Parse: CUL_Cube_Usb A 0E DE 8010 42C234 230369 02080000001F -58.5
2017.11.11 23:59:11.913 4: CUL_Parse: CUL_Cube_Usb A 0E DF 8010 42C234 230369 01000000001F -58.5
2017.11.11 23:59:12.176 4: CUL_Parse: CUL_Cube_Usb A 0E E0 8010 42C234 230369 02080000001F -58.5


Weiß der Geier warum das fhem nicht selbst kann.
Idee?

Die ganzen Posts betr. pairing des rt beschreiben ja auch meist seltsame workflows.
Warte hier, drücke da, paire nochmal drüber.

:)
linuxpaul

LuckyDay

#7
CUL_Cube_Lan V 1.20.06 a-culfw Build: 199 (2016-02-21_13-36-20) CUBe (F-Band: 868MHz)

mit der SW vom deinem Cube wirst du nie glücklich werden, die kann kein Timing. der empfangenen Nachrichten.

einzige Möglichkeit wäre vielleicht die SW vom noansi falls es die für den Cube gibt.

Ansonsten musst du damit leben, oder ordentliche hmIO's nehmen die Timing beherschen.


linuxpaul

Vielen Dank für die Antwort,

sowas hab ich  mir schon bald gedacht.
Für den Cube Betrieb als CUN gibt es einen entrsprechenden Honweis.
HM-MOD-RPI-PCB scheint derzeit der HM Adapter der Wahl zu sein, oder?
Zumindest wird der Busware Dongle für Homematic hier nicht als zwingend stabil beschrieben.

:)
linuxpaul

popperchris

Guten Morgen,
ich hole das Thema nochmal hoch.

Ich habe seit guten 2 Jahren einen CC1101 als CUL_0 mit Homematic auf meinem Raspberry laufen. Das Teil läuft, zumindest bei mir, stabil.

Ich habe heute Morgen einen erneuten Update gemacht und danach kann ich über FHEM keine Solltemperatur an meine ( 3 Stück ) HM_CC-RT-DN mehr schicken.

Spiele ich den Update vom 03. November wieder ein geht es wieder. Ich habe noch einen Update vom 08. November. Auch damit geht es nicht mehr.

Ich gehe also davon aus das irgendwas zwischen dem Update vom 03. bis zum 08. November geändert wurde welches diesen Fehler verursacht !!!


Gruß
Christoph

upsalmo

#10
Habe mich gerade ins Forum eingeloggt, um ein ähnliches Problem zu beschreiben. Jetzt poste ich mal hier, weil ich die Vermutung habe, dass dies vielleicht auch genau mein Problem sein könnte.

Ich habe ebenfalls einen CC1101 (die Platine für GPIO, nicht das USB-Modul) als CUL_0 auf einem Raspi 3. Insgesamt verwende ich sechs Homematic-Thermostate (HM-CC-RT-DN) und drei Funksteckdosen von Homematic (HM-LC-Sw1-Pl-DN-R1).

Seit einigen Tagen übernehmen die Thermostate nicht mehr zuverlässig die Soll-Temperatur. Das heißt, ich setze einen Befehl in FHEM ab, der auch (laut Logfile) abgesendet wird, dann aber auf den Thermostaten nicht ankommt. Das Verrückte ist, dass manchmal funktioniert und manchmal nicht. Ich hatte schon den Fall, dass ich es viermal hintereinander mit dem selben Befehl versucht habe. Dreimal hat das Thermostat die neue Temperatur ignoriert, beim vierten Mal dann übernommen.

Die Funksteckdosen dagegen haben kein Problem. Batterien der Thermostate sind okay. Zwei habe ich auch schon mal vom Strom getrennt und so zur Neuinitialisierung gezwungen. Leider ohne Erfolg. Deshalb ist mein Verdacht inzwischen auch ein Problem durch irgendein Update.

Zeitlich kann ich das Problem noch weiter eingrenzen, als Christoph. Ich habe den Fehler nämlich zum ersten Mal am Sonntag, den 5. November bemerkt. Es müsste also, wenn man Christophs und meine Zeitrechnung zusammennimmt, zwischen dem 03. und dem 05. November ein Problem entstanden sein.

Grüße, upsalmo

linuxpaul

Mein rt geht jetzt seit zwei Tagen nach dem fix.
Mag das jetzt auch nicht zwingen anfassen wollen.

Nix dest trotz würde uch trotzdem gerne wissen warum hier
0F 0B 8610 42C234 000000 0AF0E50B570025 -55.5
Nuller drinstehen, wo jedes andere device die HMID im Telegram hat.

Googelt man nach 10_CUL_HM findet man einige Bewegung
seit anfang November.

und dann noch dies:
https://github.com/mhop/fhem-mirror/commits/master/fhem/FHEM/10_CUL_HM.pm
10_CUL_HM: improve ack for Threestate sensor with CUL
Sicher ein anderes Thema, oder?

Oder evtl. nochmal mit der neuesten Version testen?

:)
linuxpaul

popperchris

Wenn du den Update von FHEM meinst dann muss ich leider sagen das der Fehler noch drin ist.

Ich habe heute Morgen einen update gemacht und es ging nicht.

Gruß
Christoph

linuxpaul


LuckyDay

ZitatMein rt geht jetzt seit zwei Tagen nach dem fix.
Mag das jetzt auch nicht zwingen anfassen wollen.

Nix dest trotz würde uch trotzdem gerne wissen warum hier
Code: [Auswählen]

0F 0B 8610 42C234 000000 0AF0E50B570025 -55.5

das sit die zyklische Temp valve usw Meldung von deinem RT , die gehen immer an Broadcast (000000)

in der Meldung stand übrigens das drin, siehe Bild ;) ;)

linuxpaul

Danke erstmal für die Hilfe,
hab mir ein HM-MOD-RPI-MOD zugelegt, eingebaut aber noch nicht weiter getestet

Ist das ein ähliches Problem?
https://forum.fhem.de/index.php/topic,79145.0.html

:)
linuxpaul

Lars_

#16
Moin zusammen,

da bin ich ja "fast" froh, das ihr auch das Problem habt  :(

Ich habe vor einiger Zeit meinen Raspi neu aufgesetzt, weil die Platte einen Schlag hatte und habe seit dem das o.g. Problem.

Seit dem Neuaufbau und Update auf die aktuellsten fhem-Module kann ich den desired-state der RT's nicht mehr setzen.
Das device steht im State "set_desired-temp nn.n" und bekommt nach einiger Zeit den State "Missing Ack". Wenn ich für den Kanal 04 (_CLIMA) ein set device burstXmit absetze, wird der desired-state aber gesetzt  ???

Meine Cul-Definition:

# CUL868
define CUL0 CUL /dev/ttyACM0@9600 1205
attr CUL0 rfmode HomeMatic
attr CUL0 room CUL_HM,Zentrale
attr CUL0 verbose 4

Einige CUL-Stati:
get CUL0 raw t02   : CUL0 raw => 00D671FF
get CUL0 raw C35   : CUL0 raw => C35 = 0D / 13
get CUL0 raw X   : CUL0 raw => 21  900

Ich habe eine neue config erstellt und alle RT's und Fenstersensoren angelernt, um Probleme mit Strukturen oder oder anderen Funktionen auszuschließen, aus meiner Sicht ohne Erfolg.
Eben habe ich noch den Fenstersensor von meinem Beispiel RT entfernt, das scheint auch nichts zu bringen ...

Log-Auszug (mit verbose 4 für den CUL) :
Betroffenes Device: 240359
2017.11.17 09:28:14 3: CUL_HM set bad_dg_RT_Clima desired-temp 19.0
2017.11.17 09:28:33 4: CUL_Parse: CUL0 A 0F E8 8610 240473 000000 0A24C40E004007 -70.5
2017.11.17 09:28:45 4: CUL_Parse: CUL0 A 0C 53 865A 314278 000000 ACD62907 -70.5
2017.11.17 09:28:55 4: CUL_Parse: CUL0 A 0E DF 8410 314278 000000 0BACD60C4007 -70.5
2017.11.17 09:29:01 4: CUL_Parse: CUL0 A 0F 79 8610 21F6E3 000000 0A8CC10E0040E5 -87.5
2017.11.17 09:29:05 4: CUL_Parse: CUL0 A 0C 53 8470 314278 000000 00D62906 -71
2017.11.17 09:29:09 4: CUL_Parse: CUL0 A 0F 5F 8610 319EEA 000000 0AACD60B504010 -66
2017.11.17 09:29:11 4: CUL_Parse: CUL0 A 0D 35 A610 176E49 4A4E27 06018A00CB -100.5
2017.11.17 09:29:11 4: CUL_Parse: CUL0 A 11 35 A002 4A4E27 176E49 040F1824A42FE902C3 -104.5
2017.11.17 09:29:11 4: CUL_Parse: CUL0 A 19 35 A003 176E49 4A4E27 02A157B180A2BA37977C393440D6020CCB -100.5
2017.11.17 09:29:12 4: CUL_Parse: CUL0 A 0E 35 8002 4A4E27 176E49 0046FB6E8EC5 -103.5
2017.11.17 09:29:24 4: CUL_Parse: CUL0 A 0F 89 8610 220098 000000 0A24A90C004040 -42
2017.11.17 09:29:52 4: CUL_Parse: CUL0 A 0F 48 8610 21F6C3 000000 0AACD60A50401F -58.5
2017.11.17 09:30:10 4: CUL_Parse: CUL0 A 0F 75 8610 24034C 000000 0A24B50F004011 -65.5
2017.11.17 09:30:30 4: CUL_Parse: CUL0 A 0F F8 8610 240359 000000 0AB0F48E154025 -55.5
2017.11.17 09:30:55 4: CUL_Parse: CUL0 A 0C 54 865A 314278 000000 ACD62908 -70
2017.11.17 09:31:02 4: CUL_Parse: CUL0 A 0F 7A 8610 21F6E3 000000 0A8CC10E0040E8 -86
2017.11.17 09:31:15 4: CUL_Parse: CUL0 A 0C 54 8470 314278 000000 00D62908 -70
2017.11.17 09:31:15 4: CUL_Parse: CUL0 A 0F E9 8610 240473 000000 0A24C40E004009 -69.5
2017.11.17 09:31:44 4: CUL_Parse: CUL0 A 0F 60 8610 319EEA 000000 0AACD60B434010 -66
2017.11.17 09:32:08 4: CUL_Parse: CUL0 A 0F 8A 8610 220098 000000 0A24A90C00403F -42.5
2017.11.17 09:32:09 4: CUL_Parse: CUL0 A 0F 49 8610 21F6C3 000000 0AACD60A4A401E -59
2017.11.17 09:32:22 4: CUL_Parse: CUL0 A 0F 76 8610 24034C 000000 0A24B40F004011 -65.5
2017.11.17 09:33:12 4: CUL_Parse: CUL0 A 0F F9 8610 240359 000000 0AB0F58E154024 -56
2017.11.17 09:33:42 4: CUL_Parse: CUL0 A 0F EA 8610 240473 000000 0A24C40E00400B -68.5
2017.11.17 09:33:44 4: CUL_Parse: CUL0 A 0D 36 A610 176E49 4A4E27 06019500CB -100.5
2017.11.17 09:33:44 4: CUL_Parse: CUL0 A 19 36 A003 176E49 4A4E27 113309494BF68E9544526F4084242C02CC -100
2017.11.17 09:33:52 4: CUL_Parse: CUL0 A 0F 7B 8610 21F6E3 000000 0A8CC20E004005 -71.5
2017.11.17 09:33:55 4: CUL_Parse: CUL0 A 0C 55 865A 314278 000000 ACD72907 -70.5
2017.11.17 09:34:05 4: CUL_Parse: CUL0 A 0E E1 8410 314278 000000 0BACD70C4007 -70.5
2017.11.17 09:34:05 4: CUL_Parse: CUL0 A 0F 61 8610 319EEA 000000 0AACD70B334011 -65.5
2017.11.17 09:34:10 4: CUL_Parse: CUL0 A 0F 4A 8610 21F6C3 000000 0AACD70A39401E -59
2017.11.17 09:34:15 4: CUL_Parse: CUL0 A 0C 55 8470 314278 000000 00D72906 -71
2017.11.17 09:34:38 4: CUL_Parse: CUL0 A 0F 8B 8610 220098 000000 0A24A90C00403E -43
2017.11.17 09:35:06 4: CUL_Parse: CUL0 A 0F 6A 943F 4A4E27 000000 020221A15BBABF -106.5
2017.11.17 09:35:24 4: CUL_Parse: CUL0 A 0F 77 8610 24034C 000000 0A24B40F004010 -66
2017.11.17 09:35:39 4: CUL_Parse: CUL0 A 0F FA 8610 240359 000000 0AB0F68E154024 -56
2017.11.17 09:35:54 4: CUL_Parse: CUL0 A 0F EB 8610 240473 000000 0A24C40E00400B -68.5
2017.11.17 09:36:11 4: CUL_Parse: CUL0 A 0F 62 8610 319EEA 000000 0AACD70B264011 -65.5
2017.11.17 09:36:28 4: CUL_Parse: CUL0 A 0F 7C 8610 21F6E3 000000 0A8CC20E004006 -71
2017.11.17 09:36:40 4: CUL_Parse: CUL0 A 0C 56 865A 314278 000000 ACD82907 -70.5
2017.11.17 09:36:50 4: CUL_Parse: CUL0 A 0E E2 8410 314278 000000 0BACD80C4007 -70.5
2017.11.17 09:36:53 4: CUL_Parse: CUL0 A 0F 8C 8610 220098 000000 0A24A90C00403F -42.5
2017.11.17 09:37:00 4: CUL_Parse: CUL0 A 0C 56 8470 314278 000000 00D82906 -71
2017.11.17 09:37:02 4: CUL_Parse: CUL0 A 0F 4B 8610 21F6C3 000000 0AACD80A2A401F -58.5
2017.11.17 09:37:48 4: CUL_Parse: CUL0 A 0D 37 A610 176E49 4A4E27 06019500CC -100
2017.11.17 09:37:48 4: CUL_Parse: CUL0 A 19 37 A003 176E49 4A4E27 C2CB3A3E3CDBADCFC7EB151D5C81B165CB -100.5
2017.11.17 09:37:52 4: CUL_Parse: CUL0 A 0F FB 8610 240359 000000 0AB0F78E154024 -56
2017.11.17 09:38:11 4: CUL_Parse: CUL0 A 0F 78 8610 24034C 000000 0A24B40F004010 -66
2017.11.17 09:38:50 4: CUL_Parse: CUL0 A 0F 7D 8610 21F6E3 000000 0A8CC20E004006 -71
2017.11.17 09:38:54 4: CUL_Parse: CUL0 A 0F 8D 8610 220098 000000 0A24A90C00403F -42.5
2017.11.17 09:38:57 4: CUL_Parse: CUL0 A 0F EC 8610 240473 000000 0A24C40E00400A -69
2017.11.17 09:39:07 4: CUL_Parse: CUL0 A 0F 63 8610 319EEA 000000 0AACD80B264010 -66
2017.11.17 09:39:11 4: CUL_Parse: CUL0 A 0C 57 865A 314278 000000 ACD92A06 -71
2017.11.17 09:39:21 4: CUL_Parse: CUL0 A 0E E3 8410 314278 000000 0BACD90C4007 -70.5
2017.11.17 09:39:31 4: CUL_Parse: CUL0 A 0C 57 8470 314278 000000 00D92A07 -70.5
2017.11.17 09:39:39 4: CUL_Parse: CUL0 A 0F 4C 8610 21F6C3 000000 0AACD90A19401F -58.5
2017.11.17 09:40:44 4: CUL_Parse: CUL0 A 0F 79 8610 24034C 000000 0A24B40F004011 -65.5
2017.11.17 09:40:54 4: CUL_Parse: CUL0 A 0F FC 8610 240359 000000 0AB0F88E154025 -55.5
2017.11.17 09:40:57 4: CUL_Parse: CUL0 A 0F 7E 8610 21F6E3 000000 0A8CC20E004005 -71.5
2017.11.17 09:41:27 4: CUL_Parse: CUL0 A 0C 58 865A 314278 000000 ACD92A08 -70
2017.11.17 09:41:44.894 4: CUL_Parse: CUL0 A 0F 8E 8610 220098 000000 0A24A90C004041 -41.5
2017.11.17 09:41:45.091 4: CUL_Parse: CUL0 A 0F ED 8610 240473 000000 0A24C30E004007 -70.5
2017.11.17 09:41:47.348 4: CUL_Parse: CUL0 A 0C 58 8470 314278 000000 00D92A08 -70
2017.11.17 09:41:48.660 4: CUL_Parse: CUL0 A 0F 64 8610 319EEA 000000 0AACD90B004011 -65.5
2017.11.17 09:42:01.596 4: CUL_Parse: CUL0 A 0F 4D 8610 21F6C3 000000 0AACD90A08401F -58.5


Da das bei mir schon 3 Jahre lief, denke ich, dass das ein Problem mit einem geänderten Modul (CUL?) sein könnte. Ohne die Unterstützung der Wissenden werden wir hier vermutlich nicht weiterkommen. Vlt. kann Rudolf, Martin oder einer der anderen Erfahrenen ja mal drüberschauen?

Sollten noch weitere Infos benötigt werden, kann ich die gerne bereitstellen.

Danke schon mal und ein schönes Wochenende
Lars

hier noch die Version-Infos:
Latest Revision: 15432

File              Rev   Last Change

fhem.pl           15377 2017-11-01 16:59:23Z rudolfkoenig
96_allowed.pm     14888 2017-08-13 12:07:12Z rudolfkoenig
98_autocreate.pm  15377 2017-11-01 16:59:23Z rudolfkoenig
57_Calendar.pm    14832 2017-08-01 18:36:03Z neubert
00_CUL.pm         15027 2017-09-08 09:11:43Z rudolfkoenig
10_CUL_HM.pm      15422 2017-11-11 16:43:17Z martinp876
93_DbLog.pm       15297 2017-10-20 20:59:52Z DS_Starter
98_DOIF.pm        14790 2017-07-26 10:27:41Z Damian
98_dummy.pm       12700 2016-12-02 16:49:42Z rudolfkoenig
91_eventTypes.pm  14888 2017-08-13 12:07:12Z rudolfkoenig
01_FHEMWEB.pm     15328 2017-10-27 10:51:17Z rudolfkoenig
92_FileLog.pm     14888 2017-08-13 12:07:12Z rudolfkoenig
36_JeeLink.pm     14707 2017-07-13 18:08:33Z justme1968
36_LaCrosse.pm    15365 2017-10-31 16:59:42Z HCS
91_notify.pm      14888 2017-08-13 12:07:12Z rudolfkoenig
99_SUNRISE_EL.pm  14888 2017-08-13 12:07:12Z rudolfkoenig
98_telnet.pm      15006 2017-09-05 09:37:33Z rudolfkoenig
99_Utils.pm       13259 2017-01-28 17:39:39Z rudolfkoenig
98_version.pm     15140 2017-09-26 09:20:09Z markusbloch

Blocking.pm       15412 2017-11-09 14:34:29Z rudolfkoenig
Color.pm          11159 2016-03-30 16:08:06Z justme1968
DevIo.pm          14933 2017-08-20 14:21:58Z rudolfkoenig
HMConfig.pm       15337 2017-10-29 06:43:02Z martinp876
HttpUtils.pm      15284 2017-10-18 19:46:13Z rudolfkoenig
RTypes.pm         10476 2016-01-12 21:03:33Z borisneubert
SetExtensions.pm  12935 2017-01-02 19:51:46Z rudolfkoenig
TcpServerUtils.pm 14862 2017-08-07 15:16:03Z rudolfkoenig
TimeSeries.pm     10907 2016-02-21 17:38:02Z borisneubert
Fhem auf rpi 3   fhem auf rpi b+
1 x CULHM/jeelink v3c   1 x CULHM
7 x HM-CC-RT-DN   3 x HM-CC-RT-DN
5 x HM-Sec-RHS

Lars_

#17
Nachtrag ....
Auf einem Test-Raspi mit dem gleichen (umgehängten) Device funktioniert das setzen des desired-state prima!

Auffälligster Unterschied bei den Modulen ist m. E. das CUL_HM

10_CUL_HM.pm   15340   29.10.17   08:32:38 OK
10_CUL_HM.pm   15422   11.11.17   16:43:17 Fehler

Ich denke es liegt an einem der geänderten Module, vermutlich dem 10_CUL_HM.pm mit einem der höheren ReleaseNr (>15340).

Martin, kannst du dir das bitte mal anschauen?
(ich werde das Modul auch mal auf das andere System kopieren, dann schauen wir, ob sich das wieder etwas kooperativer verhält ;-)

Gruß
Lars
Fhem auf rpi 3   fhem auf rpi b+
1 x CULHM/jeelink v3c   1 x CULHM
7 x HM-CC-RT-DN   3 x HM-CC-RT-DN
5 x HM-Sec-RHS

Yokurt

Hallo,

auch bei meinem seit Jahren funktionierenden System mit CUL  am Raspi kamen die letzten Tage keine Kommandos mehr durch.

Mit einem Rückfall auf die "alte" 10_CUL_HM.pm Version 15170 vom 2.10. scheint wieder alles wie gewohnt zu funktionieren.

Gruß
Yokurt

Lars_

#19
Test auf dem produktiven System mit dem 10_CUL_HM.pm (15340   29.10.17   08:32:38) vom Test-System erfolgreich  :)

Ich habe nur das Modul "10_CUL_HM.pm   15340 vom 29.10.17 08:32:38" auf das produktive System kopiert (restoreDirs war auf 5 directories eingestellt und für dieses Modul leider nicht mehr möglich).
Nach einem shutdown restart klappt das setzen des desired-state wieder!

Da muss wohl mal jemand drauf schauen.
(ich kann das problematische Modul für Analysedaten bei Bedarf wieder aktivieren, falls jemand was benötigt)

Gruß und ein schönes Wochenende
Fhem auf rpi 3   fhem auf rpi b+
1 x CULHM/jeelink v3c   1 x CULHM
7 x HM-CC-RT-DN   3 x HM-CC-RT-DN
5 x HM-Sec-RHS

linuxpaul

#20
Uiui,

in meinem Fall scheint fhem-hm-knecht richtig zu liegen.
Hab den Cube durch HM-MOD-RPI-MOD ersetzt, den rt zurückgesetzt, das Device gelöscht, fhem neu gestartet,
den rt neu gepaired und ... geht  :)

Nix desto trotz hab ich mal die Versionen des 10_CUL_HM 15340 und 15366 verglichen und da wurden einige Regexp
die u.a. auch auf HM-CC-RT-DN filtern etwas verschärft. Bewerten will/kann ich das aber nicht. Hat sicherlich einen Grund.

Danke nochmal an alle für den Einsatz

:)
linuxpaul


1907

Ich habe das gleiche Problem.
Heute meinen ersten RT versucht in Betrieb zu nehmen (zusammen mit einem SelbstbauCUL) und damit kläglich gescheitert.
Das Pairing klappte zwar, aber ich bekomme wie ihr diese MissingACK Meldungen.

Gott sei dank habe ich diesen Thread gefunden.
Nach dem ich eine ältere 10_CUL_HM.pm installiert habe funktioniert alles wie erwartet.

Viele Grüße

Dr. Boris Neubert

Zitat von: Lars_ am 17 November 2017, 10:03:32
Moin zusammen,

Wenn Du etwas erreichen willst, musst Du den Beitrag dem Programmautor melden, nicht den Moderatoren.

Grüße
Boris
Globaler Moderator, Developer, aktives Mitglied des FHEM e.V. (Marketing, Verwaltung)
Bitte keine unaufgeforderten privaten Nachrichten!

mgernoth

#23
Hallo,

versucht bitte mal in der aktuellen Version die Zeil 1180 auszukommentieren:


  #CUL_HM_assignIO($mh{devH}); #this way the init and remove work even on startup for TSCUL


Evtl. verursacht irgendetwas in assignIO eine zu große Verzögerung und das Timing wird nicht mehr eingehalten.

Viele Grüße
  Michael

noansi

Hallo,

könnt Ihr bitte auch mal per shell mit
perl -v
Eure perl Version checken und mitteilen.

Nicht auszuschließen, dass das den Unterschied macht.

Gruß, Ansgar.

twenta

#25
Gehöre auch zur Gruppe der ,,MISSING ACKs". Habe diese gestern neu gepaired (Geräte waren zuvor einwandfrei gepaired), seitdem kann ich (mit stackable SCC VERSION
V 1.65 CSM868) keine Befehle mehr an die RTs senden.
Meine Perl Version ist perl 5, version 20, subversion 2 (v5.20.2) built for arm-linux-gnueabihf-thread-multi-64int

Auch das auskommentieren von
  #CUL_HM_assignIO($mh{devH});

Hat leider nichts gebracht

mgernoth

Hallo,

Zitat von: twenta am 19 November 2017, 21:11:56
Auch das auskommentieren von
  #CUL_HM_assignIO($mh{devH});

Hat leider nichts gebracht

Ja, anscheinend führt die aktuelle assignIO-Logik (wird noch an anderen Stellen aufgerufen) dazu, dass der Fhem-Kern die Verzögerung auslöst.
Hier ist die aktuelle CUL_HM.pm mit der alten assignIO-Logik, damit sollten die Probleme erstmal behoben sein:
https://rmdir.de/~michael/10_CUL_HM.pm

Viele Grüße
  Michael

Yokurt

Hello,

das ist auch meine Perlversion (mit der es nicht funktioniert hat):
perl -v

This is perl 5, version 20, subversion 2 (v5.20.2) built for arm-linux-gnueabihf-thread-multi-64int


Gruß
Yokurt

linuxpaul

Diese Version habe ich auch -> die Perl Version scheint es nicht zu sein.

:)
linuxpaul

Yokurt

Zitat von: mgernoth am 19 November 2017, 21:52:29
...Hier ist die aktuelle CUL_HM.pm mit der alten assignIO-Logik, damit sollten die Probleme erstmal behoben sein:
https://rmdir.de/~michael/10_CUL_HM.pm...

Hallo,

funktioniert bei mir :)

Gruß
Yokurt

frust

Hast du neu gepaired oder nur die *.pm-Datei ersetzt ?? Bei mir hat es bislang nämlich nicht geholfen nur die 10_CUL_HM.pm zu ersetzen :-(

Yokurt

Nur die 10_CUL_HM.pm ersetzt und fhem neu gestartet. Alternativ sollte auch ein reload der pm-Datei gehen.

Andreas_

#32
.....
BananaPi mit Cul-Stick V3
13 x HM-CC-RT-DN firmware 1.4
1 x HM-HM-LC-SW4
9x HM-LC-Bl1-FM
HM-RC-19