MISSING ACK bei HM-LC-Bl1PBU-FM & Viele Fehlermeldungen seit Update auf 5.5/COC

Begonnen von Shadow, 04 September 2014, 18:55:44

Vorheriges Thema - Nächstes Thema

Shadow

Nach set wz_Rollo_Rechts getConfig hat sich leider nichts geändert in R-pairCentral   set_0x0

Internals:
   DEF        241B07
   IODev      COC
   NAME       wz_Rollo_Rechts
   NR         51
   STATE      RESPONSE TIMEOUT:RegisterRead
   TYPE       CUL_HM
   protCmdDel 6
   protCmdPend 2 CMDs pending
   protResnd  9 last_at:2014-09-05 10:59:45
   protResndFail 2 last_at:2014-09-05 10:59:30
   protSnd    3 last_at:2014-09-05 10:59:32
   protState  CMDs_processing...
   Readings:
     2014-05-21 16:55:48   CommandAccepted yes
     2014-09-04 15:06:34   D-firmware      2.2
     2014-09-04 15:06:34   D-serialNr      KEQ0879230
     2014-09-04 18:38:13   R-pairCentral   set_0x0
     2014-05-21 16:55:48   deviceMsg       7.5 % (to COC)
     2014-09-04 18:38:13   level           set_20
     2014-05-21 16:55:48   motor           stop:7.5 %
     2014-09-05 10:59:30   state           RESPONSE TIMEOUT:RegisterRead
     Regl_00::
       VAL
   cmdStack:
     ++A001F11234241B0701040000000001
     ++A001F11234241B070103
   Helper:
     cSnd       01F11234241B0700040000000000
     getCfgList all
     getCfgListNo ,3
     mId        006A
     rxType     1
     Io:
       newChn     +241B07,00,01,00
       prefIO
       rxt        0
       vccu
       p:
         241B07
         00
         01
         00
     Mrssi:
       mNo
     Prt:
       bErr       0
       sProc      1
       Rspwait:
         Pending    RegisterRead
         cmd        As100EA001F11234241B0700040000000000
         forChn     00
         forList    00
         forPeer
         mNo        14
         nAddr      0
         reSent     4
     Q:
       qReqConf
       qReqStat   00
     Role:
       chn        1
       dev        1
       prs        1
Attributes:
   IODev      COC
   autoReadReg 4_reqStatus
   expert     2_full
   firmware   2.2
   model      HM-LC-Bl1PBU-FM
   room       Wohnzimmer
   serialNr   KEQ0879230
   subType    blindActuator
   webCmd     statusRequest:toggle:on:off:up:down:stop


Dann muss ich ihn wohl neu Pairen.  :-\

Aber danke an alle Beteiligten!
System:
RPi 1 (FHEM) + COC Modul (auf GPios) + Antenne, 6 x HM-LC-Dim1T-FM (Dim Licht), 6 x HM-LC-Bl1PBU-FM (Rolladen), 7 x HM-CC-VD (Heizkörer), 5 x HM-CC-TC (Temperatur), 6 x HM-SEC-SC-2 (Fenster), 2 x HM-PB-6-WM55 (Taster)

frank

ZitatNach set wz_Rollo_Rechts getConfig hat sich leider nichts geändert in R-pairCentral
der befehl ist zwar noch nicht abgearbeitet:

protState  CMDs_processing...

aber neu pairen, wirst du wohl doch müssen.
du kannst das pairen mit seriennummer versuchen, dann kannst du dir ein eventuelles ausbauen des device vielleicht ersparen. manchmal funktioniert es.  ;)
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

Shadow

Ich hab das device mit set wz_Rollo_Rechts unpair und delete wz_Rollo_Rechts geunpaired und versucht neu einzurichten.

Hab das COC auf set coc hmPairForSec 120  gesetzt. Bekomme dann diese Meldung die ich mit der Version 5.3 nicht hatte. COC ccconf => freq:868.300MHz bWidth:101KHz rAmpl:33dB sens:8dB

Nachdem ich im direkten Anschluss die den Anlernknopf drücke, passiert da leider nichts. Er blinkt durchgehend Grün 20 sek Grün und geht dann aus.

Habe dann dieses Gerät unter Unsortiert:
"CUL_HM_HM_LC_Bl1PBU_FM_241B07"

Leider reagiert auch dieser nicht auf irgendeinen Befehl. Weder auf "Up" "Down" "On" oder "Off".

Hab dann dieses hier unter GetConf. stehen.

CFGFN

COC_MSGCNT

1
COC_RAWMSG

A1A0F8400241B0700000022006A4B45513038373932333030010100::-71.5:COC
COC_RSSI

-71.5
COC_TIME

2014-09-07 15:14:08
DEF
241B07
IODev

COC
LASTInputDev

COC
MSGCNT

1
NAME

CUL_HM_HM_LC_Bl1PBU_FM_241B07
NR

170
STATE

MISSING ACK
TYPE

CUL_HM
lastMsg

No:0F - t:00 s:241B07 d:000000 22006A4B45513038373932333030010100
protCmdDel

3
protCmdPend

2 CMDs pending
protLastRcv

2014-09-07 15:14:08
protResnd

3 last_at:2014-09-07 15:16:57
protResndFail

1 last_at:2014-09-07 15:17:01
protSnd

2 last_at:2014-09-07 15:18:03
protState

CMDs_processing...
rssi_at_COC

avg:-71.5 min:-71.5 max:-71.5 lst:-71.5 cnt:1
System:
RPi 1 (FHEM) + COC Modul (auf GPios) + Antenne, 6 x HM-LC-Dim1T-FM (Dim Licht), 6 x HM-LC-Bl1PBU-FM (Rolladen), 7 x HM-CC-VD (Heizkörer), 5 x HM-CC-TC (Temperatur), 6 x HM-SEC-SC-2 (Fenster), 2 x HM-PB-6-WM55 (Taster)

Shadow

Ist vieleicht der Aktor kaputt oder habe ich etwas beim Anlernen bzw. Ablernen falsch gemacht?
System:
RPi 1 (FHEM) + COC Modul (auf GPios) + Antenne, 6 x HM-LC-Dim1T-FM (Dim Licht), 6 x HM-LC-Bl1PBU-FM (Rolladen), 7 x HM-CC-VD (Heizkörer), 5 x HM-CC-TC (Temperatur), 6 x HM-SEC-SC-2 (Fenster), 2 x HM-PB-6-WM55 (Taster)

Mr. P

Hej Shadow,

lösche nochmals alle Daten für den Schalter aus FHEM heraus und starte es dann einmal neu. Um ganz sicher zu gehen, schau nach dem Neustart nochmal in die Config, ob auch wirklich nichts mehr von dem Schalter zu sehen ist.
Sicher stellen, dass du 'autocreate' aktiviert hast und danach erst versuch nochmal ein: set COC hmPairForSec 120 und drücke anschließend den Config-Button am Aktor.
Sollte das auch noch nichts bringen, dann würde ich noch den Schalter komplett zurücksetzen. Also Config-Button 4 Sekunden drücken, bis das LED langsam blinkt und dann nochmal 4 Sekunden drücken, bis es schnell blinkt. Anschließend den oben beschriebenen Vorgang nochmal von Anfang an durchspielen.
Greetz,
   Mr. P

martinp876

ggf rohmessages loggen - incl timig.
ist die COC am Ethernet? Das könnte timing-probleme erzeugen

Shadow

@martinp876:
Also der Raspberry Pi ist am Lan angeschlossen und der COC ist ja mit ihm verbunden. Aber sonst könnte man FHEM ja auch nicht steuern? Wäre ja blöd wenn das timing probleme erzeugt.
Oder wie meinst du das mit dem Ethernet?
Unter 5.3 welches bei mir bis vor einem Jahr lief hatte ich große Timing Probleme. Umso länger FHEM lief umso länger dauerte es, bis die Befehle umgesetzt wurden.

@Mr. P:
Danke. Das werd ich gleich heute Nachmittag probieren. Bin gespannt. :)
System:
RPi 1 (FHEM) + COC Modul (auf GPios) + Antenne, 6 x HM-LC-Dim1T-FM (Dim Licht), 6 x HM-LC-Bl1PBU-FM (Rolladen), 7 x HM-CC-VD (Heizkörer), 5 x HM-CC-TC (Temperatur), 6 x HM-SEC-SC-2 (Fenster), 2 x HM-PB-6-WM55 (Taster)

martinp876

die COC beachtet kein timing  - also "in welchen Zeitfenster mus sich antworten". Das Timing macht die Zentrale, also der PI. Der kann das sicher auch hinreichend.
Ein Problem haben wir bei IOs, die mit der Zentrale über LAN verbunden sind. Die schaffen das Timing nicht.
Abhilfe gibt es bei HMLAN - das macht einiges alleine und sendet einen timestamp, der für eine korrektur genutzt werden kann.

Bei einer CUL/CUNO, evtl auch COC könnte man diesen timestamp auch einbauen - defactor habe ich eine CUL-FW die das macht.
Wenn diese FW (endlich) freigegeben wird kann die Zentrale deutlich besser/genauer reagieren.

Ohne die Änderung kann ich LAN nur für HMLAN empfehlen - alles andere ist instabil.
USB ist deutlich präziser

franky08

@Martin
Ein COC sitzt direkt auf der GPIO Leiste vom Raspi, der ist nicht über Ethernet verbunden.

VG
Frank
Debian Bookworm auf HUNSN / Debian Bullseye auf 2.ter HUNSN F2F an 2x RaspiB
mit FHEM aktuell
22Zoll ViewSonic als Infodislay (WVC)
3xHMLAN mit vccu, raspmatic_rpi3, HMIP-HCU1

martinp876