HM-RC-Sec4-3 LED Statusrückmeldung

Begonnen von Eddy, 20 November 2017, 23:41:24

Vorheriges Thema - Nächstes Thema

Eddy

Hallo Leute,

ich habe mich mittlerweile in etlichen Beiträgen zu dem Thema eingelesen und vieles getestet. Leider auch teilweise veraltete Beiträge die mich nur in eine Ecke geführt haben.

Ich möchte lediglich bei erfolgreicher Übermittlung des Signals an mein LGW eine positive Rückmeldung an den Handsender geben (grüne LED). Ich habe eine VCCU eingerichtet.

Folgende Schritte habe ich durchgeführt:
https://wiki.fhem.de/wiki/Diskussion:HM-RC-12_Funkfernbedienung_12_Tasten

define HMvirtual CUL_HM A01001
set HMvirtual virtual 1
rename HMvirtual_Btn1 HMvirtual_ACK1
set HM_54ED08_light peerChan 0 HMvirtual_ACK1 single set


Das erste Drücken des buttons hat tatsächlich eine grüne Rückmeldung gegeben. Jedes weiter Drücken gibt jedoch eine rote Rückmeldung.
Event Monitor:

2017-11-20 23:38:10 CUL_HM Licht_Eingangsbereich_EG set_on-for-timer 150
2017-11-20 23:38:10 CUL_HM HM_54ED08_light Short 1_22 (to HMvirtual)
2017-11-20 23:38:10 CUL_HM HM_54ED08_light trigger: Short_22
2017-11-20 23:38:10 CUL_HM HM_54ED08_light triggerTo_HMvirtual: Short_22
2017-11-20 23:38:10 CUL_HM HM_54ED08_light trigger_cnt: 22
2017-11-20 23:38:10 readingsGroup HM_Components HM_Key_Dan.battery: ok
2017-11-20 23:38:10 CUL_HM HM_Key_Dan battery: ok
2017-11-20 23:38:10 CUL_HM HM_Key_Dan HM_54ED08_light Short
2017-11-20 23:38:10 CUL_HM HMvirtual CMDs_done
2017-11-20 23:38:10 CUL_HM HMvirtual CMDs_done
2017-11-20 23:38:10 CUL_HM HMvirtual_ACK1 OFF
2017-11-20 23:38:10 CUL_HM HMvirtual_ACK1 virtActState: OFF
2017-11-20 23:38:10 CUL_HM HMvirtual_ACK1 virtActTrigNo: 22
2017-11-20 23:38:10 CUL_HM HMvirtual_ACK1 virtActTrigRpt: 2
2017-11-20 23:38:10 CUL_HM HMvirtual_ACK1 virtActTrigType: short
2017-11-20 23:38:10 CUL_HM HMvirtual_ACK1 virtActTrigger: HM_54ED08_light


Log File:

2017.11.20 23:27:37 1: HMUARTLGW meinLGW:keepAlive: Device not initialized (state: 90, ) but asked to send data. Dropping: As0A248002A0100154ED0800
2017.11.20 23:27:37 1: HMUARTLGW meinLGW:keepAlive: Device not initialized (state: 90, ) but asked to send data. Dropping: As0A248002A0100154ED0800
2017.11.20 23:27:40 1: HMUARTLGW meinLGW:keepAlive did not respond for the 1. time, resending
2017.11.20 23:27:43 1: HMUARTLGW meinLGW:keepAlive did not respond for the 2. time, resending

Pfriemler

Das Problem liegt nicht an der RC-4, sondern für mich generell an der Stabilität des LGW. Da scheint was im Argen.
"Ä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 ..."

Eddy

Könntest du deine Vermutung etwas eingrenzen? Ich habe dieses Problem tatsächlich nur in Verbindung mit dem peer. Löse ich diesen, bekomme ich auch diese Fehlermeldung im Log nicht mehr.

Kann ich sonst etwas bereitstellen das die Analyse erleichtert?

Pfriemler

Dein "meinLGW" wird von FHEM regelmäßig am Leben gehalten (keepAlive), ein regelmäßiges Datenpaket sorgt dafür. Dein Logauszug zeigt, dass FHEM "meinLGW" ansprechen will, aber nicht kann, weil es "dead" ist. Daher schlagen die Wiederholungsversuche 3 und 6 Sekunden später fehl.
Oder Du hast nicht den passenden Logeintrag herausgesucht ...

Funktionieren denn andere Fernbedienungen mit dem gleichen Verfahren bei Dir?
Verwendest Du mehrere Homematic-Interfaces, so dass die zu sendende ACK-Quittung an die Fernbedienung über ein Device abgesetzt werden soll, was gerade dead ist (evtl. preferredIO-Einstellung?)

Hilfreich wären die Ausgaben von "list HM_54ED08_light" und "list HMvirtual".
Eigentlich ist die Einrichtung von VCCU und virtueller Buttons allda inzwischen die Empfehlung für ACK-Partner in FHEM. Man sollte das Wiki ggf. überarbeiten (Notiz an mich)...
"Ä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 ..."

Eddy

Die Einträge im Log-File erfolgen wirklich unmittelbar und nur im Zusammenhang mit dem per peer Verbundenen Button auf der Fernbedienung. Alle anderen Buttons sowie Buttons anderer Fernbedienungen lösen diese Log- Einträge nicht aus.

Mich wundert auch, dass HMvirtual auf meinLGW geht, statt auf VCCU. Oder habe ich da etwas falsch verstanden?

Zitat
Eigentlich ist die Einrichtung von VCCU und virtueller Buttons allda inzwischen die Empfehlung für ACK-Partner in FHEM.
Sorry, das habe ich jetzt nicht verstanden  :o

Hier der Auszug aus list HM_54ED08_light:

Internals:
   DEF        54ED0803
   NAME       HM_54ED08_light
   NOTIFYDEV  global
   NR         150
   NTFY_ORDER 50-HM_54ED08_light
   STATE      Short 1_25 (to HMvirtual)
   TYPE       CUL_HM
   chanNo     03
   device     HM_Key_Dan
   READINGS:
     2017-11-20 23:05:57   R-HMvirtual_ACK1-expectAES set_off
     2017-11-20 23:05:57   R-HMvirtual_ACK1-peerNeedsBurst set_off
     2017-11-21 07:50:57   state           Short 1_25 (to HMvirtual)
     2017-11-21 07:50:57   trigger         Short_25
     2017-11-20 23:16:40   triggerTo_100101 Short_15
     2017-11-21 07:50:57   triggerTo_HMvirtual Short_25
     2017-11-21 07:50:57   trigger_cnt     25
   helper:
     BNO        25
     BNOCNT     1
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     role:
       chn        1
     shadowReg:
       RegL_04.HMvirtual_ACK1  01:00
Attributes:
   model      HM-RC-Sec4-3


list HMvirtual:

Internals:
   CFGFN
   DEF        A01001
   IODev      meinLGW:keepAlive
   NAME       HMvirtual
   NOTIFYDEV  global
   NR         354
   STATE      CMDs_done
   TYPE       CUL_HM
   channel_01 HMvirtual_ACK1
   protSnd    9 last_at:2017-11-21 07:50:57
   protState  CMDs_done
   CHANGED:
     CMDs_done
   CHANGEDWITHSTATE:
   READINGS:
     2017-11-21 07:50:57   state           CMDs_done
   helper:
     HM_CMDNR   94
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     io:
       newChn     +A01001,00,00,00
       prefIO
       rxt        0
       vccu
       p:
         A01001
         00
         00
         00
     mRssi:
       mNo
     prt:
       bErr       0
       sProc      0
       rspWait:
     q:
       qReqConf
       qReqStat
     role:
       dev        1
Attributes:
   IODev      meinLGW:keepAlive
   autoReadReg 4_reqStatus
   expert     2_raw
   model      virtual_1
   subType    virtual


frank

IODev      meinLGW:keepAlive
ändere mal das attribut zu "meinLGW", oder wie immer der auch heissen mag.
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

Pfriemler

@frank: (daumenhoch) - ich hätt's hoffentlich auch gefunden, aber jetzt machen die Einträge im Log noch mehr Sinn.


Und:
     2017-11-20 23:05:57   R-HMvirtual_ACK1-expectAES set_off
     2017-11-20 23:05:57   R-HMvirtual_ACK1-peerNeedsBurst set_off

Die Fernbedienung möchte nochmal per Knopfdruck angeschubst werden, damit die "set_..." verschwinden.

ZitatMich wundert auch, dass HMvirtual auf meinLGW geht, statt auf VCCU. Oder habe ich da etwas falsch verstanden?

Ganz und gar nicht, im Gegenteil. Wenn Du eine VCCU hast, ja. Dann gehört sogar noch ein ein:
IOgrp      vccu
in die Def vom HMVirtual.

ZitatZitat

    Eigentlich ist die Einrichtung von VCCU und virtueller Buttons allda inzwischen die Empfehlung für ACK-Partner in FHEM.

Sorry, das habe ich jetzt nicht verstanden  :o

Gerade wenn Du schon eine VCCU hast: dort kannst Du mit "set <VCCU> virtual X" eine Anzahl virtueller Buttons erzeugen (max. 50 - Achtung nie weniger als bereits schon exisiterende, sonst werden die "überzähligen" kommentarlos gelöscht) und diese zum Peeren mit HM-Fernbedienungen nutzen, statt extra HMVirtual anzulegen. Das ist der derzeit einfachste Weg dafür. Ganz ohne Probleme mit IO ...



"Ä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 ..."

Eddy

Ok, bin grade am testen. Scheint zu funktionieren. Jetzt versuche ich das mal für alle Buttons zu machen. Kann ich an einen virtuellen Button mehrere physische peeren? Ich meine ich nutze den ja nur für den ACK.

Pfriemler

Zitat von: Eddy am 21 November 2017, 21:02:06
Kann ich an einen virtuellen Button mehrere physische peeren? Ich meine ich nutze den ja nur für den ACK.
Definitiv. Ich habe teilweise mehr als ein Dutzend drauf.
"Ä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 ..."

Eddy

Super, jetzt funktioniert es. Ich habe alles Buttons mit einem virtuellen der VCCU gekoppelt.

Vielen Dank ersteinmal.

Ein Problem habe ich jedoch noch. Es scheint noch ein peer aktiv zu sein, der jetzt Probleme macht. Das Event wird also doppelt ausgeführt und führt nun dazu, dass das Licht ein und wieder aus geschaltet wird.

hier der Event-Log:

2017-11-21 22:36:44 CUL_HM Licht_Eingangsbereich_EG set_on-for-timer 150
2017-11-21 22:36:44 CUL_HM HM_54ED08_light Short 1_55 (to A01001)
2017-11-21 22:36:44 CUL_HM HM_54ED08_light trigger: Short_55
2017-11-21 22:36:44 CUL_HM HM_54ED08_light triggerTo_A01001: Short_55
2017-11-21 22:36:44 CUL_HM HM_54ED08_light trigger_cnt: 55
2017-11-21 22:36:45 readingsGroup HM_Components HM_Key_Dan.battery: ok
2017-11-21 22:36:45 CUL_HM HM_Key_Dan battery: ok
2017-11-21 22:36:45 CUL_HM HM_Key_Dan HM_54ED08_light Short
2017-11-21 22:36:45 CUL_HM Licht_Eingangsbereich_EG deviceMsg: on (to VCCU)
2017-11-21 22:36:45 CUL_HM Licht_Eingangsbereich_EG level: 100
2017-11-21 22:36:45 CUL_HM Licht_Eingangsbereich_EG pct: 100
2017-11-21 22:36:45 CUL_HM Licht_Eingangsbereich_EG on
2017-11-21 22:36:45 CUL_HM Licht_Eingangsbereich_EG timedOn: running
2017-11-21 22:36:45 CUL_HM Licht_Eingangsbereich_EG set_off
2017-11-21 22:36:45 CUL_HM HM_54ED08_light Short 2_55 (to VCCU)
2017-11-21 22:36:45 CUL_HM HM_54ED08_light trigger: Short_55
2017-11-21 22:36:45 CUL_HM HM_54ED08_light trigger_cnt: 55
2017-11-21 22:36:45 readingsGroup HM_Components HM_Key_Dan.battery: ok
2017-11-21 22:36:45 CUL_HM HM_Key_Dan battery: ok
2017-11-21 22:36:45 CUL_HM HM_Key_Dan CMDs_done
2017-11-21 22:36:45 CUL_HM HM_Key_Dan HM_54ED08_light Short
2017-11-21 22:36:46 CUL_HM Licht_Eingangsbereich_EG deviceMsg: off (to VCCU)
2017-11-21 22:36:46 CUL_HM Licht_Eingangsbereich_EG level: 0
2017-11-21 22:36:46 CUL_HM Licht_Eingangsbereich_EG pct: 0
2017-11-21 22:36:46 CUL_HM Licht_Eingangsbereich_EG off
2017-11-21 22:36:46 CUL_HM Licht_Eingangsbereich_EG timedOn: off


Wie kann ich diesen peer lösen? Ich finde nirgends diese Einträge.

Pfriemler

Hmmm ... komisch. Ich muss da nochmal nachrecherchieren. ...

Schaue - ggf. nach einem getConfig (inkl. Config-Knopfdruck) an der RC4 auf der Taste nach der peerList in den Internals. Dort müssten noch zwei peers stehen, nämlich der alte HMVirtual und der virtuelle Button der VCCU. Wenn Du HMVirtual noch nicht gelöscht hast, entpeere ihn dann in der RC4.
Wenn schon weg: peerBulk ginge zur Not auch, "set HM_54ED08_light peerBulk A0100101 unset"? ins blaue geraten.
Im Log sieht man jedenfalls, dass der erste Trigger an A01001 geht (das ist HMVirtual) und der zweite an VCCU.
Vielleicht löst das schon das Problem.
"Ä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 ..."

Eddy

super, der Befehl
set HM_54ED08_light peerBulk A0100101 unset
hat die Lösung gebracht. Vielen Dank für die Hilfe!!!