[gelöst] State von Lichtschaltern wird „falsch“ angezeigt

Begonnen von onkel-tobi, 18 Oktober 2021, 10:33:29

Vorheriges Thema - Nächstes Thema

onkel-tobi

Hi zusammen,

ich habe einige HM Lichtschalter im Einsatz. Nun ist es so, dass 2 Lichtschalter als an angezeigt werden obwohl sie aus sind. Die haben aber jahrelang funktioniert.
Vor ein paar Tagen habe ich meine config überprüft und als iogroup bei diesen devices die vccu statt einem dedizierten hmlan eingetragen. Meint ihr daran kann es liegen?
Wie bekomme ich das jetzt am saubersten wieder korrekt hin?
Hab schon probiert die devices auf ignore zu setzen und dann zu schalten, aber leider ohne Erfolg.
Oder habt ihr noch einen anderen Tipp für mich?

List eines betroffenen devices:
Internals:
   DEF        554BB6
   FUUID      5c5dae99-f33f-d748-4dfb-a4b6e9a5fe5ae759
   HMLAN_AZ_MSGCNT 10
   HMLAN_AZ_RAWMSG E554BB6,0000,025D9EF9,FF,FFB1,23A410554BB6200DB80601C800
   HMLAN_AZ_RSSI -79
   HMLAN_AZ_TIME 2021-10-18 10:06:14
   IODev      hmusb
   LASTInputDev hmusb
   MSGCNT     24
   NAME       eg_ku_li
   NR         158
   NTFY_ORDER 48-eg_ku_li
   STATE      on
   TYPE       CUL_HM
   chanNo     01
   disableNotifyFn 1
   hmusb_MSGCNT 14
   hmusb_RAWMSG E554BB6,0000,1479DBE3,FF,FFCC,23A410554BB6200DB80601C800
   hmusb_RSSI -52
   hmusb_TIME 2021-10-18 10:06:14
   lastMsg    No:23 - t:10 s:554BB6 d:200DB8 0601C800
   protLastRcv 2021-10-18 10:06:14
   protRcv    10 last_at:2021-10-18 10:06:14
   protSnd    13 last_at:2021-10-18 10:06:14
   protState  CMDs_done
   rssi_at_HMLAN_AZ cnt:10 min:-83 max:-73 avg:-77.3 lst:-79
   rssi_at_hmusb cnt:14 min:-57 max:-52 avg:-56.57 lst:-52
   rssi_hmusb cnt:1 min:-60 max:-60 avg:-60 lst:-60
   CL:
     Authenticated 0
     BUF       
     FD         138
     FW_ID      690
     LASTACCESS 1634544453
     NAME       WEB_192.168.175.140_54516
     NR         691
     PEER       192.168.175.140
     PORT       54516
     SNAME      WEB
     SSL       
     STATE      Connected
     TEMPORARY  1
     TYPE       FHEMWEB
     canAsyncOutput 1
     READINGS:
       2021-10-18 10:07:15   state           Connected
   READINGS:
     2021-10-18 10:05:45   D-firmware      2.8
     2021-10-18 10:05:45   D-serialNr      OEQ0030507
     2021-10-18 10:06:14   IODev           hmusb
     2021-10-18 10:05:20   PairedTo        0x200DB8
     2021-10-18 10:05:20   R-pairCentral   0x200DB8
     2021-10-18 10:05:21   R-powerUpAction off
     2021-10-18 10:05:21   R-sign          off
     2021-10-18 10:05:20   RegL_00.         00:00 02:01 0A:20 0B:0D 0C:B8 15:FF 18:00
     2021-10-18 10:05:21   RegL_01.         00:00 08:00 30:06 56:00 57:24
     2021-10-18 10:06:22   cfgState        ok
     2021-10-18 10:06:14   commState       CMDs_done
     2021-10-18 10:06:14   deviceMsg       on (to vccu)
     2021-10-18 10:06:14   level           100
     2021-10-18 10:06:14   pct             100
     2021-10-18 10:06:14   recentStateType info
     2021-10-18 10:06:14   state           on
     2021-10-18 10:06:14   timedOn         off
   helper:
     HM_CMDNR   35
     cSnd       01200DB8554BB601040000000001,01200DB8554BB60103
     cfgStateUpdt 0
     lastMsgTm  1634544374.38763
     mId        0069
     peerFriend peerSens,peerVirt
     peerIDsRaw ,00000000
     peerIDsState complete
     peerOpt    3:switch
     regLst     0,1,3p
     rxType     1
     supp_Pair_Rep 0
     cmds:
       TmplKey    :no:1634544157.37379
       TmplTs     1634544157.37379
       cmdKey     1:1:0::eg_ku_li:0069:01:
       cmdLst:
         assignHmKey noArg
         clear      [(readings|trigger|register|oldRegs|rssi|msgEvents|{msgErrors}|attack|all)]
         deviceRename -newName-
         fwUpdate   -filename- [-bootTime-]
         getConfig  noArg
         getDevInfo noArg
         getRegRaw  (List0|List1|List2|List3|List4|List5|List6|List7) [-peerChn-]
         getVersion noArg
         inhibit    [(on|{off})]
         off        noArg
         on         noArg
         on-for-timer -ontime-
         on-till    -time-
         pair       noArg
         peerBulk   -peer1,peer2,...- [({set}|unset)]
         peerIODev  [IO] -btn- [({set}|unset)] 'not for future use'
         peerSmart  -peerOpt-
         press      [(long|{short})] [(-peer-|{self01})] [(-repCount-|{0})] [(-repDelay-|{0.25})]
         raw        -data- [...]
         regBulk    -list-.-peerChn- -addr1:data1- [-addr2:data2-]...
         regSet     [(prep|{exec})] -regName- -value- [-peerChn-]
         reset      noArg
         sign       [(on|{off})]
         statusRequest noArg
         toggle     noArg
         tplDel     -tplDel-
         tplSet_0   -tplChan-
         unpair     noArg
       lst:
         condition  slider,0,1,255
         peer       
         peerOpt    Rauchmelder_Team,dg_fk_li,dg_gl_mo1,eg_fl_db,eg_fl_mo,eg_fl_moBtn_01,eg_fl_moBtn_02,eg_fl_tk1,eg_ga_rain,eg_gb_fk,eg_ku_fk
         tplChan   
         tplDel     
         tplPeer   
       rtrvLst:
         cmdList    [({short}|long)]
         deviceInfo [({short}|long)]
         list       [({normal}|full)]
         param      -param-
         reg        -addr- -list- [-peerChn-]
         regList    noArg
         regTable   noArg
         regVal     -addr- -list- [-peerChn-]
         saveConfig [-filename-]
         tplInfo    noArg
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     io:
       flgs       0
       newChn     +554BB6,00,01,00
       nextSend   1634544374.5292
       rxt        0
       vccu       vccu
       p:
         554BB6
         00
         01
         00
       prefIO:
     mRssi:
       mNo        23
       io:
         HMLAN_AZ:
           -79
           -79
         hmusb:
           -46
           -46
     peerIDsH:
       00000000   broadcast
     prt:
       bErr       0
       sProc      0
       rspWait:
       tryMsg:
     q:
       qReqConf   
       qReqStat   
     regCollect:
     role:
       chn        1
       dev        1
       prs        1
     rpt:
       IO         HMLAN_AZ
       flg        A
       ts         1634544374.38763
       ack:
         HASH(0x3a6f2b0)
         238002200DB8554BB600
     rssi:
       at_HMLAN_AZ:
         avg        -77.3
         cnt        10
         lst        -79
         max        -73
         min        -83
       at_hmusb:
         avg        -56.5714285714286
         cnt        14
         lst        -52
         max        -52
         min        -57
       hmusb:
         avg        -60
         cnt        1
         lst        -60
         max        -60
         min        -60
     shadowReg:
     tmpl:
Attributes:
   IOgrp      vccu
   alias      Küche
   autoReadReg 4_reqStatus
   event-on-change-reading .*
   expert     defReg,rawReg
   firmware   2.8
   model      HM-LC-SW1PBU-FM
   peerIDs    00000000
   room       Homekit,CUL_HM,alexa,Küche
   serialNr   OEQ0030507
   subType    switch
   webCmd     statusRequest:toggle:on:off


Danke und Gruß,
Tobi

Beta-User

Auch wenn man Softwareprobleme nicht völlig ausschließen kann (=> https://forum.fhem.de/index.php/topic,123436.0.html) klingt das für mich nach einem C26-Problem (ausgetrockneter Kondensator, auch wenn zwei gleichzeitig eher ungewöhnlich sind).

Nehmen die Geräte denn Befehle zuverlässig entgegen?

Bzgl. Software wäre es gut, du würdest verraten, welche Versionen du fährst.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

frank

Zitatdass 2 Lichtschalter als an angezeigt werden obwohl sie aus sind
hm..., das list zeigt eindeutig, dass er "on" ist und das wird dir dort auch angezeigt.

   STATE      on
...
     2021-10-18 10:06:14   deviceMsg       on (to vccu)
     2021-10-18 10:06:14   level           100
     2021-10-18 10:06:14   pct             100
     2021-10-18 10:06:14   state           on
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

onkel-tobi

ZitatNehmen die Geräte denn Befehle zuverlässig entgegen?
Das mit den c26 hatte ich auch bei 2-3 aktoren, aber dann reagierten sie wirklich nicht mehr. Die hier resgieren, nur ist state halt immer falsch.
Zitat
Bzgl. Software wäre es gut, du würdest verraten, welche Versionen du fährst.
Habe vor meinem post noch ein Update gefahren, insofern aktuelles fhem mit der neuen cul_hm:
10_CUL_HM.pm           25078 2021-10-16 10:31:26Z martinp876


frank

wenn die aktoren in einer klassischen wechselschaltung installiert sind, ist ein korrekter status abhängig vom 2. schalter.
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

onkel-tobi

Zitat von: frank am 18 Oktober 2021, 15:05:57
wenn die aktoren in einer klassischen wechselschaltung installiert sind, ist ein korrekter status abhängig vom 2. schalter.
Das kann ich ausschließen. Der eine ist ein einzelner Schalter und der andere funktioniert ja jahrelang ohne hardwaremäßige Änderungen.

Pfriemler

Zitat von: onkel-tobi am 18 Oktober 2021, 11:34:29
Die hier reagieren, nur ist state halt immer falsch.
Heißt was? Sie lassen sich schalten, zeigen aber immer den entgegengesetzten Status?
Und ändert sich der Status, wenn man manuell lokal schaltet?
"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."

onkel-tobi

Zitat von: Pfriemler am 18 Oktober 2021, 18:53:51
Heißt was? Sie lassen sich schalten, zeigen aber immer den entgegengesetzten Status?
korrekt
ZitatUnd ändert sich der Status, wenn man manuell lokal schaltet?
Ja, und das zuverlässig.

onkel-tobi

Habe mal die alte CUL_HM.pm wieder eingespielt aber auch ohne Erfolg.
Hat noch wer eine Idee? Die Aktoren schalten weiterhin sehr zuverlässig, lokal wie über fhem....

Pfriemler

Also der Sw1PBU hat kein bistabiles Relais. Es wird bei on bestromt und fällt bei off ab. Der gemeldete Status kann eigentlich nicht anders als korrekt sein, außer mit dem u.g. Attribut. Manche Schalter kann man in ihrer Wertetabelle umprogrammieren, beim Sw1PBU geht das aber m.W. nicht.
Ich greife trotzdem mal franks Anregung auf:

Zitat von: onkel-tobi am 18 Oktober 2021, 16:46:32
Das kann ich ausschließen. Der eine ist ein einzelner Schalter und der andere funktioniert ja jahrelang ohne hardwaremäßige Änderungen.

Es muss ja nicht ein zweiter Schalter im Spiel sein. Der Aktor hat einen Umschaltkontakt und es haben schon etliche den NC-Kontakt verdrahtet und sich über ein inverses Schaltverhalten gewundert. Wenn Du wirklich ganz sicher ausschließen kannst, dass niemand etwas geändert hat, wundert es schon, aber selbst einem Elektriker würde ich nicht über den Weg trauen dass er das nach einem Abklemmen wieder hinbekommt, vor allem wenn der Aktor danach kopfstehend eingebaut wird. Dann stimmt nämlich die lokale Bedienhaptik wieder, aber der Status ist immer falsch.

Nur so eine Diagnoseidee: Wenn Du den Stromkreis einmal ausschaltest (Sicherung) und nach ein paar Sekunden wieder einschaltest, muss der Aktor aus sein und das Licht darf nicht leuchten. Anderenfalls ist der Schalter falsch verdrahtet. Auch ein on-for-timer sollte das Licht begrenzt einschalten und wieder ausschalten. off-for-timer wird nicht unterstützt.

Einen bei richtiger Beschaltung inversen Meldecharakter erreicht man auch mit dem Attribut "param" und dem Wert "levelInverse". In diesem Fall geht der Aktor bei einem on-for-timer 10 etwa physisch an (Licht leuchtet während fhem off meldet) und schaltet danach physikalisch off (und fhem on). Das ist bei Dir aber auch nicht gelistet.

Soweit meine Testideen, ich bitte um feedback.
"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."

onkel-tobi

hi,

Danke für wure Antworten und Tipps.

Zitat von: Pfriemler am 19 Oktober 2021, 21:53:15
Nur so eine Diagnoseidee: Wenn Du den Stromkreis einmal ausschaltest (Sicherung) und nach ein paar Sekunden wieder einschaltest, muss der Aktor aus sein und das Licht darf nicht leuchten. Anderenfalls ist der Schalter falsch verdrahtet.
Das muss ich mir die Tage ml anschauen. Evtl ist er ja wirklich falsch verdrahtet und ich hatte aber levelinverse in der Vergangenheit konfiguriert. Aktuell kann ich das gar nicht setzen.
Zitat
Auch ein on-for-timer sollte das Licht begrenzt einschalten und wieder ausschalten. off-for-timer wird nicht unterstützt.
Das habe ich eben getestet. Bei beiden Schaltern geht das Licht erst nach angegeben Sekunden an und bleibt dann an. Das würde ja dann echt für falsche Verkabelung sprechen? Ich versteh es nur nicht, weil das jahrelang lief und nichts geändert wurde (außer der config Änderung bezüglich vccu und dem Update von cul_hm).

Gruß,
Tobi

Beta-User

Es kann sein, dass Attribute durch Zwischenversionen verloren gegangen waren...

Fröhliches "Würfeln mit Hashes".... :o :( 8)
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

onkel-tobi

Zitat von: Beta-User am 19 Oktober 2021, 23:06:37
Es kann sein, dass Attribute durch Zwischenversionen verloren gegangen waren...
So, dann ist denke ich die Erklärung gefunden und ich muss neu verdrahten.
Habe nach Änderungen via configdb gesucht und ein diff gefunden:

attr eg_ku_li param levelInverse

Beta-User

qed...

Also im Ergebnis eine Verkettung unglücklicher Zufälligkeiten, und doch (auch) ein Softwareproblem.

(Immer wieder lustig, dass man mit configDB dann schnell mal schauen kann, wie das den früher mal war, ohne lange alte Daten zu durchgreppen 8) ).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

onkel-tobi

Zitat von: Beta-User am 19 Oktober 2021, 23:14:41
Also im Ergebnis eine Verkettung unglücklicher Zufälligkeiten, und doch (auch) ein Softwareproblem.
Jep. Ich bin ja nur glücklich, dass jetzt die Ursache geklärt ist. Ich hab mich ja selbst schon für völlig irre gehalten  😂.
Levelinverse scheint insofern komplett zu ,,fehlen" in der aktuellsten Version.
Zitat
(Immer wieder lustig, dass man mit configDB dann schnell mal schauen kann, wie das den früher mal war, ohne lange alte Daten zu durchgreppen 8) ).
Jep, auf die config Dateien hätte ich heute auch keine Lust mehr gehabt...