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?
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
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
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
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.
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.
@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!
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
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.