HM-LC-Sw1-Pl-CT-R1 und 'press' per Alexa möglich?

Begonnen von HansDampfHH, 05 Juni 2021, 13:15:56

Vorheriges Thema - Nächstes Thema

HansDampfHH

Hallo, ich habe eine HM-LC-Sw1-Pl-CT-R1 Funk-Steckdose in der Garage verbaut.
Über das Relais kann ich unser Garagentor öffnen/schließen. Das funktioniert wunderbar aus der Wohnung mit einem Dashbutton, der folgendes triggert:
set HM_4EEF64 press

Nun würde ich gerne per Sprachsteuerung diese Kommando absetzen, bin bisher aber gescheitert.

Hier mal das Log, wie das Device von Alexa erkannt wurde:

[4.6.2021, 21:28:00] [FHEM] HM_4EEF64 is switch
[4.6.2021, 21:28:00] [FHEM] HM_4EEF64 has
[4.6.2021, 21:28:00] [FHEM]   StatusLowBattery [battery]
[4.6.2021, 21:28:00] [FHEM]   On [state;on,off]
[4.6.2021, 21:28:00] [FHEM] HM_4EEF64 will not send proactive events
[4.6.2021, 21:28:00] [FHEM] HM_4EEF64 uses ID: NEQ1263648
[4.6.2021, 21:28:00] [FHEM] value2homekit_re: [ { re: '.*', to: 'BATTERY_LEVEL_LOW' } ]
[4.6.2021, 21:28:00] [FHEM] value2homekit: { ok: 'BATTERY_LEVEL_NORMAL' }
  2021-06-04 21:28:00 caching: HM_4EEF64-battery: ok
  2021-06-04 21:28:00 caching: HM_4EEF64-state: off


Gibt also scheinbar erst mal nur on, off.
Aber auch das Kommando "Alexa, Garage an" zeigt keine Wirkung.

Hat jemand einen Hinweis wie ich dem Problem beikommen kann?
FHEM Docker, CUL868, Zigbee, CCU2, Jeelink

MadMax-FHEM

Post doch ein list des HM_4EEF64.

Du brauchst ein homebridgeMapping...
...wenn du nicht on/off willst.

Aber on/off sollte gehen, wenn es richtig konfiguriert ist/wäre.

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

HansDampfHH

Okay, ich hoffe das listing gibt Auschluß:

Internals:
   DEF        NEQ1263648 defaults
   FUUID      5cc937bf-f33f-9484-4f2f-112bc8a184f3394e
   IODev      CCU2
   NAME       HM_4EEF64
   NR         372
   STATE      off
   TYPE       HMCCUDEV
   ccuaddr    NEQ1263648
   ccudevstate active
   ccuif      BidCos-RF
   ccuname    Garage
   ccutype    HM-LC-Sw1-Pl-CT-R1
   channels   2
   firmware   2.5
   statevals  devstate|on|off
   READINGS:
     2021-05-24 16:02:59   0.AES_KEY       0
     2021-05-24 16:02:59   0.CONFIG_PENDING false
     2021-05-24 16:02:59   0.DEVICE_IN_BOOTLOADER false
     2021-05-24 16:02:59   0.DUTYCYCLE     false
     2021-05-24 16:02:59   0.RSSI_DEVICE   1
     2021-05-24 16:02:59   0.RSSI_PEER     1
     2021-05-24 16:03:00   0.STICKY_UNREACH 1
     2021-05-24 16:02:59   0.UPDATE_PENDING false
     2021-05-24 16:02:59   1.INHIBIT       false
     2021-06-05 16:46:11   1.STATE         off
     2021-06-05 16:46:11   1.WORKING       no
     2021-05-24 16:02:40   IODev           CCU2
     2021-05-24 16:02:59   activity        alive
     2021-05-24 16:02:59   battery         ok
     2021-06-05 16:46:11   control         off
     2021-06-05 16:46:11   hmstate         off
     2021-06-05 16:46:11   state           off
   hmccu:
     devspec    NEQ1263648
     dp:
       0.AES_KEY:
         OSVAL      0
         OVAL       0
         SVAL       0
         VAL        0
       0.CONFIG_PENDING:
         OSVAL      false
         OVAL       false
         SVAL       false
         VAL        false
       0.DEVICE_IN_BOOTLOADER:
         OSVAL      false
         OVAL       false
         SVAL       false
         VAL        false
       0.DUTYCYCLE:
         OSVAL      false
         OVAL       false
         SVAL       false
         VAL        false
       0.LOWBAT:
         OSVAL      ok
         OVAL       false
         SVAL       ok
         VAL        false
       0.RSSI_DEVICE:
         OSVAL      1
         OVAL       1
         SVAL       1
         VAL        1
       0.RSSI_PEER:
         OSVAL      1
         OVAL       1
         SVAL       1
         VAL        1
       0.STICKY_UNREACH:
         OSVAL      true
         OVAL       true
         SVAL       1
         VAL        1
       0.UNREACH:
         OSVAL      alive
         OVAL       false
         SVAL       alive
         VAL        false
       0.UPDATE_PENDING:
         OSVAL      false
         OVAL       false
         SVAL       false
         VAL        false
       1.INHIBIT:
         OSVAL      false
         OVAL       false
         SVAL       false
         VAL        false
       1.STATE:
         OSVAL      off
         OVAL       0
         SVAL       off
         VAL        0
       1.WORKING:
         OSVAL      no
         OVAL       0
         SVAL       no
         VAL        0
Attributes:
   IODev      CCU2
   alexaName  Garage
   alias      Garagentor
   batteryChange 02.10.2019
   cmdIcon    press:general_ok
   devStateIcon on:general_an@green off:general_aus@red
   eventMap   /on-for-timer 1:press/
   group      CCU - Devices
   icon       ge_wht_steckdose
   room       Garage
   statedatapoint 1.STATE
   statevals  on:true,off:false
   substitute STATE!(0|false):off,(1|true):on;WORKING!(0|false):no,(1|true):yes
   webCmd     press
FHEM Docker, CUL868, Zigbee, CCU2, Jeelink

MadMax-FHEM

#3
Oh, HMCCU...
Wenn mit CUL_HM eingebunden hätte es verm. "out-of-the-box" funktioniert...

Bei HMCCU weiß ich nicht was fehlt.
Und auch die ganzen "Umbiegungen", also ob die stören oder ob das bzgl. HMCCU so "muss" (oder "nur" du so willst)...

Evtl. fehlt genericDeviceType (wobei es ja als switch erkannt wurde)...
Und evtl. setList (braucht es aber eigentl. nur bei dummy oder wenn alexa-fhem die "setter" nicht erkennt)...

Ich habe ein homebridgeMapping für einen CUL_HM Aktor, dabei hab ich "on" auf "on-for-timer" "umgebogen".
Kann ich mal posten, vielleicht hilft es.

EDIT: hier ist es

On=state,valueOn=on,valueOff=off,cmdOn=on-for-timer+3600,cmdOff=off


Ansonsten bin ich leider bei HMCCU raus... :-\

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

HansDampfHH

Hm, HMCCU muss ja nicht. Ist eher historisch. Läuft eben seit Jahren alles Top.
CUL_HM ist die neue Variante? Kann ich ja für dieses Device mal umstellen.
FHEM Docker, CUL868, Zigbee, CCU2, Jeelink

micky0867

Meine allgemeine Vorgehensweise bei speziellen Alexa Dingen:
Ein Dummy-Device mit genericdevicetype=light anlegen und in Alexa einbinden.
Dann in Alexa eine Routine mit Spracheingabe erstellen und mit dieser das Dummy auf einen bestimmten Prozentwert setzen.
Ein notify, das bei Änderung des Prozentwerts eine Perl Funktion aufruft.
Diese fragt den Prozentwert ab und führt je nach Wert unterschiedliche Funktionen aus.
Damit hat man eine universelle Routine-zu-Dummy Funktion und kann mit wenig Aufwand alles mögliche realisieren.

HansDampfHH

@micky0867
Funzt, nette Idee mit der man im Grunde alles abbilden kann.
Danke für den Hinweis. Auch wenn es vielleicht eine "richtige" Lösung gibt, so komme ich zumindest schnell zu einem Ergebnis.

Dank euch!
FHEM Docker, CUL868, Zigbee, CCU2, Jeelink

MadMax-FHEM

Zitat von: HansDampfHH am 05 Juni 2021, 19:42:48
Hm, HMCCU muss ja nicht. Ist eher historisch. Läuft eben seit Jahren alles Top.
CUL_HM ist die neue Variante? Kann ich ja für dieses Device mal umstellen.

Historisch denke ich war CUL_HM früher.
Deine Art der Einbindung hat den Vorteil, dass du so auch mal HM-IP kannst...
Mit CUL_HM geht das nicht...

Gut dummy-Umweg geht immer aber: der Status stimmt (u.U.) nicht, wenn mal direkt oder über einen anderen Weg (fhem direkt am Aktor) geschalten wird.

Besserer "Umweg" wäre readingsProxy...

Sauber wäre halt das Device selbst direkt einzubinden, dann gibt es kein "Durcheinander"/"Unstimmigkeiten"...

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

HansDampfHH

ZitatSauber wäre halt das Device selbst direkt einzubinden, dann gibt es kein "Durcheinander"/"Unstimmigkeiten"

Da gebe ich Dir auf jeden Fall recht.
Für den aktuellen Case ist es okay, man kann eh nur togglen...gibt also keinen State.
FHEM Docker, CUL868, Zigbee, CCU2, Jeelink