Funk Rolladenaktor "Missing Ack" nach Stromausfall - erneutes Pairing erfolglos

[Andy]

Hallo zusammen,

ich betreibe seit knapp zwei Jahren (FHEM auf Raspberry, CUL, ein Rolladenaktor, ein Dimmer und eine schaltbare Steckdose) ohne größere Probleme.

Seit einem Stromausfall letzte Woche wurde der Rolladenaktor manchmal nicht angesprochen, nun reagiert er gar nicht mehr - Missing Ack.

Auch ein Löschen in FHEM, Reset des Aktors und neues Pairing führt sofort zu "Missing Ack", wenn ich den ersten Befehl absetzen will. Der Schalter selbst funktioniert bei manueller Betätigung.

List zeigt folgendes :

Code Auswählen Erweitern

Internals:
   CFGFN
   CUL_0_MSGCNT 4
   CUL_0_RAWMSG A0A2B800256F66211066900::-66:CUL_0
   CUL_0_RSSI -66
   CUL_0_TIME 2019-07-21 15:07:53
   DEF        56F662
   IODev      CUL_0
   LASTInputDev CUL_0
   MSGCNT     4
   NAME       HM_56F662
   NOTIFYDEV  global
   NR         116
   STATE      ???
   TYPE       CUL_HM
   lastMsg    No:2B - t:02 s:56F662 d:110669 00
   protLastRcv 2019-07-21 15:07:53
   protSnd    3 last_at:2019-07-21 15:07:53
   protState  CMDs_done
   rssi_at_CUL_0 cnt:4 min:-66 max:-55.5 lst:-66 avg:-62.5
   READINGS:
     2019-07-21 15:07:53   CommandAccepted yes
     2019-07-21 15:07:52   D-firmware      2.11
     2019-07-21 15:07:52   D-serialNr      OEQ0265662
     2019-07-21 15:07:52   R-pairCentral   set_0x110669
   helper:
     HM_CMDNR   43
     PONtest    1
     cSnd       0111066956F662000802010A110B060C69,0111066956F6620006
     mId        006A
     rxType     1
     supp_Pair_Rep 0
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     io:
       newChn     +56F662,00,00,00
       nextSend   1563714473.67256
       prefIO
       rxt        0
       vccu
       p:
         56F662
         00
         00
         00
     mRssi:
       mNo        2B
       io:
         CUL_0      -64
     prt:
       bErr       0
       sProc      0
       rspWait:
     q:
       qReqConf   00
       qReqStat   00
     role:
       chn        1
       dev        1
       prs        1
     rssi:
       at_CUL_0:
         avg        -62.5
         cnt        4
         lst        -66
         max        -55.5
         min        -66
     shadowReg:
       RegL_00.    02:01 0A:11 0B:06 0C:69
Attributes:
   IODev      CUL_0
   autoReadReg 4_reqStatus
   expert     2_raw
   firmware   2.11
   model      HM-LC-Bl1PBU-FM
   room       CUL_HM
   serialNr   OEQ0265662
   subType    blindActuator
   webCmd     statusRequest:toggleDir:on:off:up:down:stop
Habt Ihr Ideen?

Danke für Eure Hilfe
Andy

[kaihs]

Nach meiner Erfahrung verlieren die Homematic Devices bei Stromausfall/leeren Batterien gerne mal ihre Konfiguration. Als wenn der Brown Out Detector nicht richtig konfiguriert sei und beim Verlust der Betriebsspannung das EEPROM Inhalt kaputt geht.

Dann hilft nur neu anlernen.

[Andy]

Neu angelernt habe ich ja.
Muss ich dabei eventuell eine besondere Reihenfolge berücksichtigen?

- in FHEM löschen, Reset des Aktors und neues Anlernen
- nur neues Anlernen

habe ich bereits versucht. Missing Ack bleibt bestehen

[kaihs]

In fhem löschen ist m. E. nicht notwendig.

IODev in den Anlernmodus versetzen und dann den Config Knopf am Schalter drücken sollte reichen. Allerdings ist ein CUL auch nicht ideal für Homematic.

Laut den Readings ist der Schalter noch nicht richtig gepaired (R-pairCentral   set_0x110669) und verweigert daher wohl alle Kommandos.

[LuckyDay]

interresant, dein Aktor ist bereits gepairt mit 110669 !

ich würde ihn mal stromlos machen , der hängt bestimmt

[amenomade]

interresant, dein Aktor ist bereits gepairt mit 110669 !

Eben nicht

Laut den Readings ist der Schalter noch nicht richtig gepaired (R-pairCentral   set_0x110669) und verweigert daher wohl alle Kommandos.

[LuckyDay]

Eben nicht

eben Doch

No:2B - t:02 s:56F662 d:110669 00

[amenomade]

Ja, aber Fhem kriegt es nicht mit. Der Register wird nicht berücksichtigt.

Aber Du hast Recht, stromlos machen könnte helfen.

[Andy]

Ja, aber Fhem kriegt es nicht mit. Der Register wird nicht berücksichtigt.

Aber Du hast Recht, stromlos machen könnte helfen.

Ich habe mal die Sicherung für ein paar Minuten rausgenommen

Ich nehme an, so wäre es richtig:

Code Auswählen Erweitern

PairedTo        0x110669
R-pairCentral   0x110669

Das ist meine schaltbare Steckdose, funktioniert prächtig.

Das hier ist der Dimmer:

Code Auswählen Erweitern

R-pairCentral   set_0x110669

Obwohl hier das PairedTo Attribut fehlt und R-pairCentral ein set-Prefix hat, funktioniert auch der Dimmer fehlerfrei

Der Rolladenaktor hat denselben Eintrag wie der Dimmer (R-PairCentral mit set_, kein PairedTo) und funktioniert nicht

[MadMax-FHEM]

Kommt vermutlich drauf an WO bzw. warum das set_ noch da ist:

Pairing beim Aktor im Register eingetragen aber noch kein Rücklesen in fhem -> set_ ABER: Aktor wird wohl funktionieren, da er ja von "seiner" Zentrale die Kommandos erhält

Pairing beim Aktor noch nicht eingetragen (und auch noch keine Rückmeldung) -> set_ ABER: Aktor verweigert Befehle von einer noch nicht bekannten Zentrale...

Zumindest meine Theorie hierzu...

Gruß, Joachim

[frank]

so viele "_set" in den readings und das bei gutem rssi/funk deutet für mich auf timing probleme hin.

1. tsculfw von noansi auf den cul flashen
2. freezes in fhem kontrollieren

[MadMax-FHEM]

so viele "_set" in den readings und das bei gutem rssi/funk deutet für mich auf timing probleme hin.

1. tsculfw von noansi auf den cul flashen
2. freezes in fhem kontrollieren

Da schließe ich mich an!

Wobei (selbst erfahren und "durchgemacht") letztendlich ein richtiges HM-IO immer noch die beste (und letztendlich) einfachste Lösung ist...

Gruß, Joachim

[Andy]

so viele "_set" in den readings und das bei gutem rssi/funk deutet für mich auf timing probleme hin.

1. tsculfw von noansi auf den cul flashen
2. freezes in fhem kontrollieren

Danke, werde ich bei Gelegenheit mal versuchen. Muss ich dabei etwas beachten, oder sollte hinterher zumindest theoretisch alles noch so gehen wie vorher?

Ich hab jetzt den Raspi / CUL mal woanders aufgestellt (Stockwerk über dem Aktor, Entfernung etwa 2m im Ggensatz zu vorher nur 1 m) und siehe da, der Aktor spricht wieder an.

Allerdings habe ich einige weitere "set_" provoziert (driveUp, down, ...) und die Readings sind ansonsten auch unverändert (R-PairCentral mit set_, kein PairedTo)

[amenomade]

Wenn das Gerät mit fhem "spricht" könnte ein getConfig helfen

[MadMax-FHEM]

Danke, werde ich bei Gelegenheit mal versuchen. Muss ich dabei etwas beachten, oder sollte hinterher zumindest theoretisch alles noch so gehen wie vorher?

Theoretisch: ja.

Einfach wie im entsprechenden Thread beschrieben...

Allerdings (das war auch der Grund das nicht mehr weiter zu machen, obwohl es danach [sehr] gut lief): es werden einige fhem-Module "ersetzt" und sind dann vom update (besser) auszuschließen... Ist immer etwas fraglich wann die "nachgezogen" werden...

Gruß, Joachim