[Gelöst] Rolladenaktor ohne Rückmeldung nach Aktion

[phil82]

Hallo zusammen,

ich habe mehrere Rollandeaktorn (HM-LC-Bl1PBU-FM) im Einsatz. Seit ca. vier Wochen meldet einer der Aktoren seinen Status nicht mehr zurück, nachdem die Aktion ausgeführt wurde. Soll heißen: Per Fhem fahre ich alle Rolladen runter ... die Aktion kommt überall an und die Rolladen fahren brav runter ... alle Aktoren quittieren den Befehl und mehren den aktuellen Stand zurück (also oben oder 98%, da die Rolladen bereits runter fahren) ... wenn alle Rolladen unten sind, melden 3 von 4 Aktoren zurück, dass die Rolladen jetzt unten sind. Nur einer nicht. Und ich weiß nicht warum.
Wenn ich jetzt per FHEM die Rolle nochmal runterfahre, dann meldet der Aktor die Bestätigung der Aktion und auch die aktuell Position (also unten).

An der Funkverbindung liegt es nicht, die ist mit einen RSSI von -60 eigentlich ganz gut und ich hab kaum Resend-Nachrichten. Auch Statusabfragen, und Befehle funktionieren tadellos.

Die Konfigurationen der Aktoren sind identisch.
Nur das Reading "recentStateType" steht auf "ack" und bei den funktionierenden Aktoren auf "info". Aßerdem gibt es bei dem nicht funktionierem Aktor ein Internal "CHANGED". Ich weiß aber nicht, was das für Reading und Internals sind und wie diese geändert werden können.

Hat jemand eine Idee?


Anbei die Infos von dem Deivce:

Code Auswählen Erweitern

Internals:
   CHANGED   
   DEF        338B00
   IODev      hwCulHM
   LASTInputDev hwCulHM
   MSGCNT     9
   NAME       hwWzRolloTuer
   NOTIFYDEV  global
   NR         251
   NTFY_ORDER 50-hwWzRolloTuer
   STATE      hoch
   TYPE       CUL_HM
   hwCulHM_MSGCNT 9
   hwCulHM_RAWMSG A1A6C8000338B0054F82C23006A4C45513134343031353830010100::-59.5:hwCulHM
   hwCulHM_RSSI -59.5
   hwCulHM_TIME 2018-02-24 12:40:47
   lastMsg    No:6C - t:00 s:338B00 d:54F82C 23006A4C45513134343031353830010100
   protLastRcv 2018-02-24 12:40:47
   protSnd    11 last_at:2018-02-24 12:40:47
   protState  CMDs_done
   rssi_at_hwCulHM cnt:9 min:-59.5 avg:-59.22 lst:-59.5 max:-57.5
   rssi_hwCulHM lst:-57 max:-57 avg:-57 min:-57 cnt:1
   READINGS:
     2018-02-24 11:15:29   CommandAccepted yes
     2018-02-24 12:40:47   D-firmware      2.3
     2018-02-24 12:40:47   D-serialNr      LEQ1440158
     2018-02-24 12:37:01   PairedTo        0x54F82C
     2018-02-04 18:44:24   R-driveDown     61.3 s
     2018-02-04 18:44:24   R-driveTurn     1.5 s
     2018-02-04 18:44:24   R-driveUp       61.5 s
     2018-02-04 18:44:17   R-pairCentral   0x54F82C
     2018-02-04 18:44:24   R-sign          off
     2018-02-24 12:37:01   RegL_00.          02:01 0A:54 0B:F8 0C:2C 15:FF 18:00 00:00
     2018-02-24 12:37:02   RegL_01.         08:00 09:00 0A:00 0B:02 0C:65 0D:02 0E:67 0F:0F 10:00  30:06 57:24 00:00
     2018-02-24 11:15:29   deviceMsg       on (to viVCCU)
     2018-02-24 11:15:29   level           100
     2018-02-21 20:34:48   levelMissed     desired:0
     2018-02-24 11:15:29   motor           stop:on
     2018-02-24 11:15:29   pct             100
     2017-03-31 09:27:09   powerOn         2017-03-31 09:27:09
     2018-02-24 11:15:29   recentStateType ack
     2018-02-24 11:15:29   state           on
     2018-02-24 11:15:29   timedOn         off
   helper:
     HM_CMDNR   147
     cSnd       0154F82C338B0001040000000001,0154F82C338B000103
     dlvlCmd    ++A01154F82C338B000201C80000
     mId        006A
     peerIDsRaw ,00000000
     regLst     ,0,1,3p
     rxType     1
     supp_Pair_Rep 1
     dir:
       cur        stop
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     io:
       newChn     +338B00,00,01,00
       nextSend   1519472447.5311
       prefIO     
       rxt        0
       vccu       viVCCU
       p:
         338B00
         00
         01
         00
     mRssi:
       mNo        6C
       io:
         hwCulHM:
           -53.5
           -53.5
     prt:
       bErr       0
       sProc      0
       rspWait:
     q:
       qReqConf   
       qReqStat   
     role:
       chn        1
       dev        1
       prs        1
     rssi:
       at_hwCulHM:
         avg        -59.2222222222222
         cnt        9
         lst        -59.5
         max        -57.5
         min        -59.5
       hwCulHM:
         avg        -57
         cnt        1
         lst        -57
         max        -57
         min        -57
     shadowReg:
     tmpl:
Attributes:
   IODev      hwCulHM
   IOgrp      viVCCU
   alias      Rollo Balkontür
   autoReadReg 0_off
   devStateIcon runter:fts_shutter_100 down:fts_shutter_100 hoch:fts_window_2w up:fts_window_2w 100:fts_window_2w [0-9]:fts_shutter_100 1[0-9].*:fts_shutter_90 2[0-9].*:fts_shutter_80 3[0-9].*:fts_shutter_70 4[0-9].*:fts_shutter_60 5[0-9].*:fts_shutter_50 6[0-9].*:fts_shutter_40 7[0-9].*:fts_shutter_30 8[0-9].*:fts_shutter_20 9[0-9].*:fts_shutter_10 .*:fts_shutter
   event-on-change-reading .*
   eventMap   statusRequest:status on:hoch off:runter stop:stop
   expert     2_full
   firmware   2.3
   group      Rolladen - Details Hinten
   icon       fts_shutter
   model      HM-LC-Bl1PBU-FM
   peerIDs    00000000,
   room       Wohnzimmer
   serialNr   LEQ1440158
   sortby     21
   subType    blindActuator
   webCmd     pct:hoch:runter:stop

[Otto123]

Hi,

meine Vermutung wäre, die 4 senden relativ gleichzeitig und der Empfänger bekommt ein Signal nicht mit. Wobei ja die Statusmeldungen extra mit gewisser zufälliger Verzögerung gesendet werden, soweit ich weiß.

Du hast einen CUL? Der ist exklusiv für HM? Hat der die TS Firmware?

Gruß Otto

[phil82]

Hi,

das Problem tritt auch auf, wenn nur die eine Rollade hoch/runter alleine gefahren wird. Eine gegenseitige Stöhrung ist daher unwarscheinlich.

Und ja, ich werden CUL exklusiv für HM. Dort nutzte ich die Standard Firmeware.

Gruß
Philipp

[phil82]

hmm ok, das Problem hat sich gerade erledigt.

Ich hab einfach mal den Aktor "reseted". Sprich einmal die Sicherung raus und wieder rein.
Hätte ich auch vorher mal drauf kommen können.

[Otto123]

Hallo Philipp,

das hatte ich dann anders verstanden:

Wenn ich jetzt per FHEM die Rolle nochmal runterfahre, dann meldet der Aktor die Bestätigung der Aktion und auch die aktuell Position (also unten).

Ich habe keine Lösung, ich weiß nur der CUL reagiert sehr empfindlich auf kleine Änderung der Frequenz (schmalbandig - hab ich mal irgendwo gelesen). Es könnte also sein, dein Aktor ist etwas weggedriftet und damit aus dem Toleranzbereich des CUL herausgewandert. Aber das ist Spekulation und nur der Versuch einer Erklärung ...

Die TS Firmware verbessert das Verhalten für HM kolossal, die würde ich auf jeden Fall empfehlen.
https://wiki.fhem.de/wiki/HomeMatic#FHEM_als_Zentrale

Gruß Otto

[Otto123]

hmm ok, das Problem hat sich gerade erledigt.

Ich hab einfach mal den Aktor "reseted". Sprich einmal die Sicherung raus und wieder rein.
Hätte ich auch vorher mal drauf kommen können.

Ja diesen Effekt gibt es auch immer mal wieder. Der war bei mir bisher aber immer hartnäckiger. Er ging dann gar nicht mehr - einmal im Jahr