HM-ES-PMSw1-DR - Nach Schalten per fhem wird direkt wieder geschaltet

[Luke2000]

Hallo zusammen,

der Schaltaktor HM-ES-PMSw1-DR bereitet mir Probleme: Schalte ich über den Schaltkanal per fhem, wird direkt wieder geschaltet. Schalte ich ihn z.B. im Zustand "an" per fhem aus, schaltet er innerhalb von Sekundenbruchteilen wieder an. Des Weiteren zeigt das Leuchtensymbol beim "DeviceOverview" ein Ausrufezeichen. Anscheinend bekommt fhem keine Rückmeldung des Zustandes...

Liegt ein Defekt des Funkmoduls des Schaltaktors vor? Das Schalten per Knopf am Aktor funktioniert... Auch das Anlernen hat problemlos funktioniert. Dann sollte doch auch das Funkmodul i.O. sein, oder?

Ich bin etwas ratlos...

VG, Luke

P.S. Hier noch ein List des HM-ES-PMSw1-DR:

Code Auswählen Erweitern


Internals:
   DEF        5CD945
   IODev      myHmUART
   LASTInputDev myHmUART
   MSGCNT     10
   NAME       HM_5CD945
   NOTIFYDEV  global
   NR         179
   NTFY_ORDER 50-HM_5CD945
   STATE      CMDs_done
   TYPE       CUL_HM
   channel_01 HM_5CD945_Sw
   channel_02 HM_5CD945_Pwr
   channel_03 HM_5CD945_SenPwr
   channel_04 HM_5CD945_SenI
   channel_05 HM_5CD945_SenU
   channel_06 HM_5CD945_SenF
   lastMsg    No:32 - t:5E s:5CD945 d:000000 8000FE0004C4005C08EB03
   myHmUART_MSGCNT 10
   myHmUART_RAWMSG 0500004732845E5CD9450000008000FE0004C4005C08EB03
   myHmUART_RSSI -71
   myHmUART_TIME 2018-12-29 21:54:49
   protLastRcv 2018-12-29 21:54:49
   protRcv    10 last_at:2018-12-29 21:54:49
   protSnd    6 last_at:2018-12-29 21:50:26
   protState  CMDs_done
   rssi_at_myHmUART cnt:10 min:-77 max:-68 avg:-70.3 lst:-71
   rssi_myHmUART cnt:4 min:-78 max:-76 avg:-76.5 lst:-78
   READINGS:
     2018-12-29 21:43:11   Activity        alive
     2018-12-29 19:57:57   CommandAccepted yes
     2018-12-29 19:57:56   D-firmware      2.5
     2018-12-29 19:57:56   D-serialNr      OEQ0947200
     2018-12-29 19:58:00   PairedTo        0xF43210
     2018-12-29 19:58:00   R-pairCentral   0xF43210
     2018-12-29 19:58:00   RegL_00.        00:00 02:01 0A:F4 0B:32 0C:10 15:FF 18:00
     2018-12-29 19:57:00   powerOn         2018-12-29 19:57:00
     2018-12-29 21:50:26   state           CMDs_done
   helper:
     HM_CMDNR   50
     cSnd       11F432105CD9450201C80000,11F432105CD9450201C80000
     mId        00EA
     regLst     ,0
     rxType     1
     supp_Pair_Rep 0
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     io:
       newChn     +5CD945,00,00,00
       nextSend   1546116890.06462
       prefIO     
       rxt        0
       vccu       VCCU
       p:
         5CD945
         00
         00
         00
     mRssi:
       mNo        32
       io:
         myHmUART:
           -69
           -69
     prt:
       bErr       0
       sProc      0
       rspWait:
     q:
       qReqConf   
       qReqStat   
     role:
       dev        1
       prs        1
     rssi:
       at_myHmUART:
         avg        -70.3
         cnt        10
         lst        -71
         max        -68
         min        -77
       myHmUART:
         avg        -76.5
         cnt        4
         lst        -78
         max        -76
         min        -78
Attributes:
   IODev      myHmUART
   IOgrp      VCCU
   actCycle   000:10
   actStatus  alive
   autoReadReg 4_reqStatus
   expert     2_raw
   firmware   2.5
   model      HM-ES-PMSw1-DR
   room       CUL_HM
   serialNr   OEQ0947200
   subType    powerMeter
   webCmd     getConfig:clear msgEvents

[Pfriemler]

Was sagt die Logdatei zu diesem Vorgang?
Boah, das ist außergewöhnlich.
- ein "gutes" Interface"
- pairing erfolgreich
- rssi ok
1. Die Rückmeldung vom Gerät kommt nicht an. Das Ausrufezeichen erscheint auch bei normalen Schaltvorgängen (Status nach Absenden set_on bzw. set_off) bis zur Rückmeldung des Aktors über den tatsächlichen Zustand. Diese Rückmeldung scheint nicht anzukommen.
Interessant wäre noch ein Listing des Schaltkanals _Sw nach einem fehlerhaften Schaltvorgang - wie genau ist "state"? Bei fehlender Rückmeldung kommt dort meist ein MISSING_ACK.
2. Es wäre noch ein spontanes Schalten des Aktors aufgrund einer Messbedingung denkbar (internes Peering und Reaktion auf Über/Unterlast). Kann hier nicht zutreffen, weil das Schalten lokal prinzipiell funktioniert.
3. Eine Reaktion von FHEM auf einen geänderten Schaltzustand (verstecktes Notify) etc. würde ich auch aussschließen - es sei denn, dieses Notify reagiert auf MISSING_ACK...
4. Es könnte noch ein Problem mit der internen Stromversorgung sein - der berühmte "C26" - wäre bei den DR aber ein neues Problem. Hier wäre eine Reaktion nur auf "Einschalten" zu erwarten (schaltet sofort wieder aus), verbunden mit einem Neustart, zu sehen am PowerOn-Reading. Wenn Du die Stromversorgung des DR heute abend um 19.57 Uhr nicht verändert hast (also z.B. eine Sicherung ausgeschaltet), dann wäre das eine denkbare Fehlerursache.

Jeder weitere Input ist willkommen.

[Luke2000]

Hallo Pfriemler,

in der Logdatei steht beim Schalten per fhem m.E. nichts außergewöhnliches...

Code Auswählen Erweitern


2018-12-30 11:55:58 CUL_HM HM_5CD945 CMDs_pending
2018-12-30 11:55:58 CUL_HM HM_5CD945_Sw set_on
2018-12-30 11:55:58 CUL_HM HM_5CD945_Sw trigLast: fhem:02
2018-12-30 11:55:58 CUL_HM HM_5CD945 CMDs_done
2018-12-30 11:55:58 CUL_HM HM_5CD945_Sw deviceMsg: on (to VCCU)
2018-12-30 11:55:58 CUL_HM HM_5CD945_Sw level: 100
2018-12-30 11:55:58 CUL_HM HM_5CD945_Sw pct: 100
2018-12-30 11:55:58 CUL_HM HM_5CD945_Sw on
2018-12-30 11:55:58 CUL_HM HM_5CD945_Sw timedOn: off


zu 1.
Ich muss mich hier korrigieren. Die Rückmeldung kommt doch an! Habe das gestern irgendwie falsch beobachtet...Sorry! State ist nach dem Anschalten tatsächlich "on". Auch wenn die angeschlossene Lampe nur kurz aufleuchtet und dann direkt wieder ausgeschaltet wird.

zu 3. MISSING_ACK trifft nicht zu

zu 4. Doch, ich habe tatsächlich die Stromversorgung gestern um 19:57 unterbrochen. Ich habe den Aktor nochmal stromlos gesetzt und neu angelernt... Daher wird es C26 vermutlich nicht sein, oder?

Bin leider immer noch ratlos. Trotzdem erstmal Danke für Deinen Input, Pfriemler! Hast Du noch eine Idee? Ansonsten werde ich wohl morgen mal bei ELV anrufen und dort fragen, was ich tun kann...

VG, Luke

[Pfriemler]

Ein schwacher Pufferelko (welcher das ist,  müsste ich nachsehen) ist dennoch denkbar. In bekannter Weise führt es sekundär zum Ausfall der Prozessorversorgung und einem Neustart nebst frischem powerOn-reading.
Ich muss mir den Schaltplan ansehen.
Lokales Schalten: Der Aktor meldet den neuen Zustand verzögert, das ist normal.
Fernschalten: Aktor meldet neuen Zustand sofort und schaltet Relais. Das ist theoretisch keine höhere Belastung.

Gegenfrage: wie verhält sich die Geräte-Led beim Fernschalten: geht sie wie die geschaltete Lampe wieder sofort aus oder bleibt sie an?

[Luke2000]

Die Geräte-LED geht ebenfalls sofort wieder aus...

[LuckyDay]

   @Luke2000

so ganz blöd gefragt.
du schreibst , mit dem Taster kannst du ihn schalten also du redest von dem 230V Taster wie im Bild?

du hast aber nicht beleuchtete Taster?

[Luke2000]

Ja, genau. Um dieses Gerät handelt es sich.

Ich rede von dem kleinen Knopf am Gerät. Mit diesem kann ich schalten ohne das direkt wieder umgeschaltet wird, wie es beim Fernschalten der Fall ist. Direkt über dem Knopf befindet sich eine kleine LED, die ebenfalls direkt wieder geschaltet wird...

[LuckyDay]

Frage ich halt nochmal !

ist der 230V Taster bei dir angeschlossen?
und b. hat der eine beleuchtung?

[Luke2000]

Oh... Entschuldige, habe die Frage falsch verstanden.

Nein, ich habe keinen Taster angeschlossen. Um etwas genauer zu werden: Ich möchte den Schaltaktor nutzen, um eine Treppenstufenbeleuchtung zu schalten. Es ist daher lediglich diese angeschlossen...

[Pfriemler]

ich bin ratlos. Bei ausgeschalteter LED hat sich mein Verdacht erledigt.
Nächste Stufe wäre der HM-Message-Log ("sniffen"), siehe Wiki, auch um eine mglw. noch versteckte Mitarbeit von Fhem am Ausschalten zu entdecken.
Siehe Wiki.
Kurz, da mobil ...

[Luke2000]

Hallo Pfriemler,

ich konnte Deiner Empfehlung erst jetzt nachgehen. Folgendes steht beim Fernschalten im Log-File:

Code Auswählen Erweitern


2019.01.05 12:02:58.805 0: HMUARTLGW myHmUART send: 00 08
2019.01.05 12:02:58.811 0: HMUARTLGW myHmUART recv: 00 040201, state 98
2019.01.05 12:02:58.813 0: HMUARTLGW myHmUART GetSet Ack: 02, state 98
2019.01.05 12:02:58.813 0: HMUARTLGW myHmUART roundtrip delay: 0.0040
2019.01.05 12:03:00.422 0: HMUARTLGW myHmUART recv: 01 05 00 00 47 msg: 04 84 5E 5CD945 000000 800000000000000008CEFA


Kannst Du damit etwas anfangen?

VG, Luke

[Pfriemler]

Bissl mehr vorn und hintendran bitte. Auch beim EventMonitor. Die Meldung über eine wie auch immer erfolgte spontane Zurückschaltung kann schon mal 10 Sekunden später kommen.

[Luke2000]

Ok, hier etwas längere Ausschnitte aus Log-File und Event-Monitor.
Meines Erachtens habe ich um 19:20:48 ausgeschaltet und es ging direkt wieder an...

Code Auswählen Erweitern

2019.01.05 19:20:42.891 0: HMUARTLGW myHmUART send: 00 08
2019.01.05 19:20:42.896 0: HMUARTLGW myHmUART recv: 00 040202, state 98
2019.01.05 19:20:42.898 0: HMUARTLGW myHmUART GetSet Ack: 02, state 98
2019.01.05 19:20:42.899 0: HMUARTLGW myHmUART roundtrip delay: 0.0034
2019.01.05 19:20:47.999 0: HMUARTLGW myHmUART send: 01 02 00 00 00 msg: B2 A0 11 F43210 5CD945 0201000000
2019.01.05 19:20:48.160 0: HMUARTLGW myHmUART recv: 01 04 03 00 44 msg: B2 80 02 5CD945 F43210 010100004B
2019.01.05 19:20:57.898 0: HMUARTLGW myHmUART send: 00 08
2019.01.05 19:20:57.904 0: HMUARTLGW myHmUART recv: 00 040202, state 98
2019.01.05 19:20:57.906 0: HMUARTLGW myHmUART GetSet Ack: 02, state 98
2019.01.05 19:20:57.907 0: HMUARTLGW myHmUART roundtrip delay: 0.0040
2019.01.05 19:21:10.284 0: HMUARTLGW myHmUART recv: 01 05 00 00 17 msg: A2 84 5E 33828B 000000 800D95000000000008CAFF
2019.01.05 19:21:12.906 0: HMUARTLGW myHmUART send: 00 08
2019.01.05 19:21:12.912 0: HMUARTLGW myHmUART recv: 00 040202, state 98
2019.01.05 19:21:12.914 0: HMUARTLGW myHmUART GetSet Ack: 02, state 98
2019.01.05 19:21:12.914 0: HMUARTLGW myHmUART roundtrip delay: 0.0038
2019.01.05 19:21:14.423 0: HMUARTLGW myHmUART recv: 01 05 00 00 3F msg: D1 86 53 521980 000000 00C100000013
2019.01.05 19:21:27.914 0: HMUARTLGW myHmUART send: 00 08
2019.01.05 19:21:27.920 0: HMUARTLGW myHmUART recv: 00 040200, state 98
2019.01.05 19:21:27.922 0: HMUARTLGW myHmUART GetSet Ack: 02, state 98
2019.01.05 19:21:27.922 0: HMUARTLGW myHmUART roundtrip delay: 0.0040
2019.01.05 19:21:42.921 0: HMUARTLGW myHmUART send: 00 08
2019.01.05 19:21:42.928 0: HMUARTLGW myHmUART recv: 00 040200, state 98
2019.01.05 19:21:42.929 0: HMUARTLGW myHmUART GetSet Ack: 02, state 98
2019.01.05 19:21:42.930 0: HMUARTLGW myHmUART roundtrip delay: 0.0038
2019.01.05 19:21:48.935 0: HMUARTLGW myHmUART recv: 01 05 00 00 44 msg: B1 84 5E 5CD945 000000 8000B70004BC005B08D2FF


Code Auswählen Erweitern


2019-01-05 19:20:47.961 CUL_HM HM_5CD945 CMDs_pending
2019-01-05 19:20:47.968 CUL_HM HM_5CD945_Sw set_off
2019-01-05 19:20:48.011 CUL_HM HM_5CD945_Sw trigLast: fhem:02
2019-01-05 19:20:48.174 CUL_HM HM_5CD945 CMDs_done
2019-01-05 19:20:48.178 CUL_HM HM_5CD945_Sw deviceMsg: off (to VCCU)
2019-01-05 19:20:48.178 CUL_HM HM_5CD945_Sw level: 0
2019-01-05 19:20:48.178 CUL_HM HM_5CD945_Sw pct: 0
2019-01-05 19:20:48.178 CUL_HM HM_5CD945_Sw off
2019-01-05 19:20:48.178 CUL_HM HM_5CD945_Sw timedOn: off
2019-01-05 19:21:10.316 CUL_HM HM_33828B_Pwr boot: off
2019-01-05 19:21:10.316 CUL_HM HM_33828B_Pwr current: 0
2019-01-05 19:21:10.316 CUL_HM HM_33828B_Pwr eState: E: 347.7 P: 0 I: 0 U: 225 f: 49.99
2019-01-05 19:21:10.316 CUL_HM HM_33828B_Pwr energy: 347.7
2019-01-05 19:21:10.316 CUL_HM HM_33828B_Pwr energyCalc: 12672.6
2019-01-05 19:21:10.316 CUL_HM HM_33828B_Pwr frequency: 49.99
2019-01-05 19:21:10.316 CUL_HM HM_33828B_Pwr power: 0
2019-01-05 19:21:10.316 CUL_HM HM_33828B_Pwr 347.7
2019-01-05 19:21:10.316 CUL_HM HM_33828B_Pwr voltage: 225
2019-01-05 19:21:10.323 CUL_HM HM_33828B_SenF 49.99
2019-01-05 19:21:10.328 CUL_HM HM_33828B_SenI 0
2019-01-05 19:21:10.334 CUL_HM HM_33828B_SenPwr 0
2019-01-05 19:21:10.339 CUL_HM HM_33828B_SenU 225
2019-01-05 19:21:48.963 CUL_HM HM_5CD945_Pwr boot: off
2019-01-05 19:21:48.963 CUL_HM HM_5CD945_Pwr current: 91
2019-01-05 19:21:48.963 CUL_HM HM_5CD945_Pwr eState: E: 18.3 P: 12.12 I: 91 U: 225.8 f: 49.99
2019-01-05 19:21:48.963 CUL_HM HM_5CD945_Pwr energy: 18.3
2019-01-05 19:21:48.963 CUL_HM HM_5CD945_Pwr energyCalc: 166.7
2019-01-05 19:21:48.963 CUL_HM HM_5CD945_Pwr frequency: 49.99
2019-01-05 19:21:48.963 CUL_HM HM_5CD945_Pwr power: 12.12
2019-01-05 19:21:48.963 CUL_HM HM_5CD945_Pwr 18.3
2019-01-05 19:21:48.963 CUL_HM HM_5CD945_Pwr voltage: 225.8
2019-01-05 19:21:48.969 CUL_HM HM_5CD945_SenF 49.99
2019-01-05 19:21:48.973 CUL_HM HM_5CD945_SenI 91
2019-01-05 19:21:48.978 CUL_HM HM_5CD945_SenPwr 12.12
2019-01-05 19:21:48.983 CUL_HM HM_5CD945_SenU 225.8


[frank]

unmittelbar nach dem set off meldet der aktor korrekt off und strom=0.
60s später meldet der aktor allerdings strom ungleich null in seiner zyklischen message. es wird aber kein "on" angezeigt, als ob das relais durch einen fehlstrom aktiviert wird. 

seltsam. defekt?
was sagt "get hminfo peerXref"? werden peers vom aktor angezeigt?

[Luke2000]

Nein, es werden keine Peers vom Aktor angezeigt.
So langsam fürchte ich, dass das Gerät defekt ist...