Probleme mit neuem HM-LC-Sw1PBU-FM Schalter

[rainer042]

Hallo,

bei mir ist der oben genannte Schalter nach 9 Jahren kaputt gegangen. Also habe ich einen neuen gleichen Typs bestellt und wollte ihn an meinem RASPI mit COC anlernen:

set COC hmPairForSec 600
Dann den Schalter mit Spannung versorgt, noch  resettet und dann nachdem er damit fertig war den config-Button ca. 4 sec gedrückt bis er anfängt zu  blinken. Währenddessen habe ich im FHEM Event-Monitor geschaut ob sich was Neues meldet. Leider kein HM-Schalter, sondern nur kurz nachdem ich Spannung auf den HM-Schalter gegeben habe die Fehlermeldung:

2020-01-10 14:54:38.878 CUL COC UNKNOWNCODE A0D0084106C696300000006010000::-58:COC

Diese kommt immer ca. 3sec nachdem ich den Schalter mit Spannung versorgt habe. Leider aber kein neues Gerät. Aschließend habe ich das Gerät mittels set COC hmPairSerial <10digitcode> versucht zu pairen, was auch geklappt hat. Ich sehe den Schalter in fhem aber wenn ich einen StatusRequest mache oder On oder Off schalte tut der Schalter genau nichts, aber im Log sehe ich ein Missing Ack:

Code Auswählen Erweitern


2020-01-10_14:38:43 HM_6C6963 D-firmware: 2.8
2020-01-10_14:38:43 HM_6C6963 D-serialNr: QEQ0136917
2020-01-10_14:40:29 HM_6C6963 set_on
2020-01-10_14:40:32 HM_6C6963 set_off
2020-01-10_14:40:34 HM_6C6963 set_on
2020-01-10_14:40:37 HM_6C6963 ResndFail
2020-01-10_14:40:37 HM_6C6963 MISSING ACK
2020-01-10_14:40:56 HM_6C6963 deviceMsg: off (to broadcast)
2020-01-10_14:40:56 HM_6C6963 level: 0
2020-01-10_14:40:56 HM_6C6963 pct: 0
2020-01-10_14:40:56 HM_6C6963 powerOn: 2020-01-10 14:40:56
2020-01-10_14:40:56 HM_6C6963 off
2020-01-10_14:40:56 HM_6C6963 timedOn: off
2020-01-10_14:41:01 HM_6C6963 set_on
2020-01-10_14:41:14 HM_6C6963 ResndFail
2020-01-10_14:41:14 HM_6C6963 MISSING ACK
2020-01-10_14:41:36 HM_6C6963 ResndFail
2020-01-10_14:41:36 HM_6C6963 MISSING ACK
2020-01-10_14:41:48 HM_6C6963 R-pairCentral: set_0x000000
2020-01-10_14:42:05 HM_6C6963 ResndFail
2020-01-10_14:42:05 HM_6C6963 MISSING ACK
2020-01-10_15:05:39 HM_6C6963 D-firmware: 2.8
2020-01-10_15:05:39 HM_6C6963 D-serialNr: QEQ0136917
2020-01-10_15:06:51 HM_6C6963 ResndFail
2020-01-10_15:06:51 HM_6C6963 MISSING ACK
2020-01-10_15:07:47 HM_6C6963 deviceMsg: off (to broadcast)
2020-01-10_15:07:47 HM_6C6963 level: 0
2020-01-10_15:07:47 HM_6C6963 pct: 0
2020-01-10_15:07:47 HM_6C6963 powerOn: 2020-01-10 15:07:47
2020-01-10_15:07:47 HM_6C6963 off
2020-01-10_15:07:47 HM_6C6963 timedOn: off
2020-01-10_15:08:23 HM_6C6963 ResndFail
2020-01-10_15:08:23 HM_6C6963 MISSING ACK
2020-01-10_15:08:28 HM_6C6963 set_on
2020-01-10_15:08:46 HM_6C6963 ResndFail
2020-01-10_15:08:46 HM_6C6963 MISSING ACK
2020-01-10_15:09:32 HM_6C6963 set_toggle
2020-01-10_15:09:51 HM_6C6963 ResndFail
2020-01-10_15:09:51 HM_6C6963 MISSING ACK
2020-01-10_15:10:16 HM_6C6963 set_on
2020-01-10_15:10:33 HM_6C6963 ResndFail
2020-01-10_15:10:33 HM_6C6963 MISSING ACK
2020-01-10_15:10:34 HM_6C6963 deviceMsg: on (to broadcast)
2020-01-10_15:10:34 HM_6C6963 level: 100
2020-01-10_15:10:34 HM_6C6963 pct: 100
2020-01-10_15:10:34 HM_6C6963 on
2020-01-10_15:10:34 HM_6C6963 timedOn: off
2020-01-10_15:10:39 HM_6C6963 deviceMsg: off (to broadcast)
2020-01-10_15:10:39 HM_6C6963 level: 0
2020-01-10_15:10:39 HM_6C6963 pct: 0
2020-01-10_15:10:39 HM_6C6963 off
2020-01-10_15:10:39 HM_6C6963 timedOn: off
2020-01-10_15:10:43 HM_6C6963 deviceMsg: on (to broadcast)
2020-01-10_15:10:43 HM_6C6963 level: 100
2020-01-10_15:10:43 HM_6C6963 pct: 100
2020-01-10_15:10:43 HM_6C6963 on
2020-01-10_15:10:43 HM_6C6963 timedOn: off
2020-01-10_15:10:47 HM_6C6963 deviceMsg: off (to broadcast)
2020-01-10_15:10:47 HM_6C6963 level: 0
2020-01-10_15:10:47 HM_6C6963 pct: 0
2020-01-10_15:10:47 HM_6C6963 off
2020-01-10_15:10:47 HM_6C6963 timedOn: off
2020-01-10_15:10:52 HM_6C6963 set_on
2020-01-10_15:11:05 HM_6C6963 set_off
2020-01-10_15:11:12 HM_6C6963 ResndFail
2020-01-10_15:11:12 HM_6C6963 MISSING ACK


interessant ist aber, das wenn ich am Schalter selbst ein/aus schalte, ich auch in FHEM diese Statusänderung sehen kann.

Da ich solcherlei Probleme bisher nicht hatte, würde ich auf einen Defekt tippen, zumal andere Homematic Geräte problemlos von fhem aus steuerbar sind. Hat jemand noch eine Idee was ich vor der Rücksendung des Schalters testen sollte?

Danke
Rainer

[MadMax-FHEM]

interessant ist aber, das wenn ich am Schalter selbst ein/aus schalte, ich auch in FHEM diese Statusänderung sehen kann.

Das ist nicht interessant sondern ganz normal:

es ist Funk. Also der Schalter/Aktor funkt seinen Status etc. "in der Gegend rum"... fhem empfängt und ordnet das halt dem passenden Gerät zu... fertig...

ABER: der Aktor nimmt nur Telegramme/Befehle von einer GEPAIRTEN Zentrale an...

Ich schätze es ist nicht (vollständig) gepaired...

Ein list des Aktor würde helfen...

UND: COC/CUL/etc. sind NICHT ideal für HomeMatic (ja geht aber naja...)

Gruß, Joachim

[Pfriemler]

Moment, ich verstehe nicht ganz: "kein neues Gerät" gibt es, wenn autocreate fehlschlägt. Allerdings musst Du den neuen Schalter doch schon angelegt haben, denn sonst könntest Du die Statusänderung nicht sehen.
Als Tip: Ich habe festgestellt, dass sich jungfräuliche Aktoren nach dem Anstromen viel pairungswilliger zeigen, wenn sie davor wenigstens einmal lokal geschaltet wurden, gerade wenn hmPairSerial benutzt wird.
Also einstromen, kurz warten, dann erst einmal kurz schalten und erst dann ein Pairing versuchen.

Ich warte derweil auch auf das angemahnte List.

Und für den kaputten Schalter interessiere ich mich extremst! Ist er noch verfügbar?

[Otto123]

Und merke: set COC hmPairSerial  xxxxxxxx  muss man nach meiner Erfahrung immer zweimal machen, mit einer kurzen Pause dazwischen. Warum auch immer.

Und config Taste bei dem Aktor 4 sec drücken ist m.M.n  falsch, nur kurz drücken
Handbuch Seite 25

Betätigen Sie die Config-Taste des Aktors
kurz mit einem spitzen Gegenstand (z.B.
Kugelschreiber) um den 20 sekündigen
Anlernmodus zu starten.

4 sec drücken wird was anderes 

Zurücksetzen in den Auslieferungszustand
Der HomeMatic Unterputz-Schaltaktor kann jederzeit in den Auslieferungszustand zurückgesetzt werden.
Das Zurücksetzen erfolgt dabei in fünf Schritten:
Schritt 1: Entfernen Sie die Wippe aus dem Wippadapter.
Schritt 2: Halten Sie mit einem schmalen, spitzen Gegenstand (z. B. Kugelschreiber) die Config-Taste (B) für mindestens 4 Sekunden gedrückt, bis die LED im Taster langsam blinkt. Lassen Sie die Taste jetzt wieder los.
Schritt 3: Drücken Sie die Taste erneut für mindestens 4 Sekunden, bis die LED schnell blinkt und lassen Sie die Taste anschließend wieder los.

Gruß Otto

[rainer042]

Hallo,

danke für die Antworten. Das gewünschte List des Aktors steht unten.

@Otto123: Ja stimmt kurz drücken hat den Anlernmodus aktiviert, lange Drücken war wohl wirklich was anderes. Dann wird er auch automatisch erkannt. Allerdings bleibt das MISSING_ACK-Problem bestehen. Ich kann also nicht von fhem den Status abfragen oder An-/Abschalten wohl aber vom Schalter aus Schalten mit Statusänderung des Eintrags in fhem.

@Pfriemler: Zuerst hatte ich ja den config-Button 4sec gedrückt. Damit klappte das automatische Anlernen nicht, wohl aber das manuelle set ...pair. Und dann hatte ich aber die gleichen Probleme wie jetzt (MISSING_ACK).

Das list:

Code Auswählen Erweitern


Internals:
   CFGFN     
   COC_MSGCNT 4
   COC_RAWMSG A0D0D84106C69630000000601C800::-43:COC
   COC_RSSI   -43
   COC_TIME   2020-01-10 17:07:46
   DEF        6C6963
   FUUID      5e189ff3-f33f-78a6-5e01-ce66aa8426a25e27
   IODev      COC
   LASTInputDev COC
   MSGCNT     4
   NAME       HM_6C6963
   NOTIFYDEV  global
   NR         707
   STATE      on
   TYPE       CUL_HM
   chanNo     01
   lastMsg    No:0D - t:10 s:6C6963 d:000000 0601C800
   protCmdDel 8
   protLastRcv 2020-01-10 17:07:46
   protRcv    5 last_at:2020-01-10 17:07:46
   protResnd  6 last_at:2020-01-10 17:03:26
   protResndFail 2 last_at:2020-01-10 17:03:32
   protSnd    2 last_at:2020-01-10 17:03:09
   protState  CMDs_done_Errors:1
   rssi_at_COC cnt:5 min:-43 max:-38 avg:-40.7 lst:-43
   READINGS:
     2020-01-10 17:01:55   D-firmware      2.8
     2020-01-10 17:01:55   D-serialNr      QEQ0136917
     2020-01-10 17:01:55   R-pairCentral   set_0xF11234
     2020-01-10 17:07:46   deviceMsg       on (to broadcast)
     2020-01-10 17:07:46   level           100
     2020-01-10 17:07:46   pct             100
     2020-01-10 17:07:46   recentStateType info
     2020-01-10 17:07:46   state           on
     2020-01-10 17:07:46   timedOn         off
   helper:
     HM_CMDNR   13
     cSnd       01F112346C696300050000000000,11F112346C69630201000000
     dlvlCmd    ++A011F112346C69630201000000
     mId        0069
     peerFriend peerSens,peerVirt
     peerOpt    3:switch
     regLst     0,1,3p
     rxType     1
     supp_Pair_Rep 0
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     io:
       newChn     +6C6963,00,00,00
       nextSend   1578672466.61445
       prefIO     
       rxt        0
       vccu       
       p:
         6C6963
         00
         00
         00
     mRssi:
       mNo        0D
       io:
         COC:
           -35
           -35
     prt:
       bErr       0
       sProc      0
     q:
       qReqConf   00
       qReqStat   
     role:
       chn        1
       dev        1
       prs        1
     rssi:
       at_COC:
         avg        -40.7
         cnt        5
         lst        -43
         max        -38
         min        -43
     shadowReg:
       RegL_00.    02:01 0A:F1 0B:12 0C:34
Attributes:
   IODev      COC
   autoReadReg 4_reqStatus
   expert     2_raw
   firmware   2.8
   model      HM-LC-SW1PBU-FM
   room       CUL_HM
   serialNr   QEQ0136917
   subType    switch
   webCmd     statusRequest:toggle:on:off


Viele Grüße
Rainer

[Pfriemler]

Code Auswählen Erweitern

     2020-01-10 17:01:55   R-pairCentral   set_0xF11234
     2020-01-10 17:07:46   deviceMsg       on (to broadcast)

FHEM hat den Befehl abgesetzt, aber das Gerät sendet immer noch broadcast. Pairing wiederholen.
Vorher unbedingt "set HM_6C6963 clear msgEvents" schicken. Sollte zwar automatisch passieren laut martin, aber ...

Dies löscht alle Nachrichten, die FHEM für das Gerät noch "auf Lager" hat, insbesondere ein getConfig. Das wiederum wird der Aktor aber immer ignorieren, solange er nicht wirklich die pairing-Aufforderung akzeptiert hat.

P.S.: wie geht es dem defekten Aktor?
P.P.S: die 4 s Tastendruck haben neben dem Reset auch etwas mit dem direkten Verknüpfen von Geräten ohne Zentrale zu tun. Das ist hier aber nicht erwünscht.

[rainer042]

Hallo

ich habs wie von Dir vorgeschlagen versucht und danach auch noch mit einem unpair auf den Aktor und einem komplett-Reset dieses Aktors. Danach wieder anlernen. Hat wieder zu dem gleichen Ergebnis geführt.

Dann bin ich ich auf eine andere Idee gekommen. Der alte Schalter, wird immer beim start von fhem auf "on" gesetzt. Da ich den Aktor abgeklemmt hatte, hat er nie geantwortet. Dies scheint warum auch immer zu den Problemen geführt zu haben, die ich beobachtet hatte.

Ich habe also den alten Schalter wieder angeklemmt, fhem restarted, gewartet bis der alte Schalter auf "on" ging und ihn dann abgeklemmt und stattdessen den neuen angeklemmt (der noch gepairt war, aber eben ein  MISSING_ACK hatte). Danach klappte der neue Schalter wie gewünscht. Jetzt scheint alles in Ordnung zu sein. Erklären kann ich das nicht aber Hauptsache es geht.

Der alte Schalter hat wohl ein kaputtes Relais, auf jeden Fall geht das Licht nicht mehr an, wenn er auf "on" schaltet. Im Log erscheint dann folgendes:
CUL_HM Schalter_FLOG repeat, level 00 instead of C8

Viele Grüße
Rainer

[Otto123]

 

[Pfriemler]

Hätt ich nicht schöner sagen können.
Ich versuch's mal zu ordnen:
1. Beide HM-Geräte sind eigentlich völlig eigenständige Teile. Es ist egal, welches unter Strom steht und welches nicht, FHEM wird das nicht weiter interessieren. Insbesondere behindern Geräte, die "offline" sind, m.a.S.g.W. keine Kommunikation mit anderen HM-Geräten.
2. Aus welchen Gründen auch immer schaltet sein "alter" Schalter bei einem Start von FHEM "on". Es muss also eine Routine geben, die ihn einschaltet. Aber wie unter 1. benannt: Wenn ein Schaltbefehl Befehl nicht erfolgreich abgesetzt werden kann, wird er in der Regel zeitnah verworfen, also auch nicht nachgeholt, wenn das Gerät irgendwann später online geht.

3. "Schalter_FLOG" sendet auf Einschaltbefehl eine unerwartete Rückmeldung. Dafür kann es viele Ursachen haben. Ungeklärt ist bspw. bei mir ein Fall, in dem ein Aktor nach einem Einschaltbefehl von FHEM selbsttätig ausschaltete. Der vom Aktor zurückgemeldete Status unterscheidet sich dann von dem, den FHEM erwartet hat. (&H00 = 0 = aus anstelle &HC8 = 200 = ein). Dies passiert aber ganz regulär auch, wenn Schutzmechanismen des Aktors eine Einschaltung des Verbrauchers aktiv verhindert haben, so z.B. eine Überlasterkennung bei Dimmern oder eine sonstige (bspw. Übertemperatur-)Problematik. Der Sw1 besitzt bspw. eine Einrichtung zur Messung des Stromes, der durch den Aktor fließt.
Wenn kein Strom durch den Verbraucher fließt, obwohl er eingeschaltet wurde, führt das jedoch nicht zu einer Fehlermeldung.

Möglicherweise liegt ein Defekt in der Schutzschaltung vor, z.B. ein durchgebrannter Messwiderstand. Ich hätte Lust, das mal zu examinieren.