alexa-fhem test version mit ModeController support

Begonnen von justme1968, 20 Januar 2022, 19:42:00

Vorheriges Thema - Nächstes Thema

slor

Ich habe mir gerade mit dem aktuellen fhem-alexa connector das Beispiel von justme in mein fhem kopiert.

In der App sehe ich das device und kann auch via drop down die verschiedenen Modi auswählen.

Mit der Sprach Steuerung funktioniert das allerdings nur sehr bedingt. Alexa ruft bei "Alexa Kion Start" immer das aktuelle Kino Program auf :-)

Ein Umbenennen in der AlexaApp auf Alarm hat schon mal dazu geführt, dass Start, Pause und Play funktionieren.

Sage ich "Alexa, Alarm stop" meldet sie zurück "Alarm unterstützt das nicht." (In der App kann ich stop einstellen)

Auch scheinen keine anderen Stati zu gehen als start, play, pause, stop.

Ein eingefügtes Manuell oder Automatik zeigt keine Wirkung. Das Gerät springt in der App dann auf Status Festlegen.

Mir ist noch aufgefallen, dass ich in Fhem im Dropdown für genericDeviceType "mode" nicht auswählen kann. In der Alexa App wird das Gerät als "Typ Sonstiges" angezeigt.

MadMax-FHEM

Das mit dem Sprechen ist "Übung", da muss man etwas probieren.

Habe auch festgestellt (typ media), dass sich das auch immer wieder mal ändert (also was ich sprechen muss)...

Auch ist Alexa ab und an (vermeintlich) "superschlau" und macht nicht wirklich was sie soll, obwohl exakt verstanden.

Also exakt das Gerät verstanden, trotzdem wird auf einem anderen Echo z.B. eine andere Musik gestartet, gestoppt (weil dort gerade was läuft) oder eben auch geantwortet: unterstützt das nicht...
Wenn ich dann exakt dasselbe noch mal sage klappt es (manchmal "trotzdem" ;) )...

Kurz: man kann nicht sagen was man selber will, sondern muss so sprechen, wie es Alexa will/versteht...


Das mit dem Attribut: entweder die Liste unter "global" (userattr) anpassen oder einfach per FhemWeb-cmd eingeben:

attr DeviceName genericDeviceType mode


Wichtig: das Attribut wird, wie auch homebridgeMapping, von verschiedenen Sprachsteuerungen genutzt. Nicht alles geht...

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)

hapege

Hallo,

ich verzweifle gerade am modeController...
Ich habe das Beispiel von vorne 1:1 definiert:
defmod kino dummy
attr kino devStateIcon on:control_on_off: off:control_home:
attr kino genericDeviceType mode
attr kino homebridgeMapping ModeController:mode,cmd=mode,mode=status,values=start;;play;;pause;;stop On=state,cmdOn=on,cmdOff=off
attr kino readingList mode
attr kino setList on off mode:start,play,pause,stop
attr kino webCmd on:off:mode

Irgendwie fehlt aber doch der "alexaName"?
Wenn ich den noch hinzufüge
attr kino alexaName kino

und dann alexa-fhem neu starte
set alexa restart

... dann wird die SSH Verbindung immer wieder kurz aufgebaut und fällt dann wieder runter (

Readings:
alexaFHEM stopped
alexaFHEM.ProxyConnection stopped

Im log finde ich nichts dazu, keine Fehlermeldung.
Wenn ich das attr homebridgeMapping lösche, dann läuft alexa-fhem sofort wieder stabil...

Was mache ich falsch?

(System und fhem sind aktuell)
Developer: 70_ESCVP21net.pm, 70_SVDRP.pm
Mitglied FHEM e.V.

fz55

Hallo,

ich hatte bei der Migration von Raspberry Pi3 auf Pi5 auch dieses Problem mit alexa-fhem und ModeController-Devices. Nachdem ich den Ordner /usr/local/lib/node_modules/alexa-fhem/lib vom Alt- auf das Neusystem kopiert hatte, lief wieder alles.

Der Inhalt des Ordners ist im Anhang. Du kannst ja Mal probieren, ob es bei dir auch das Problem löst.

hapege

#19
Hi,

Danke - aber das ist eine "wilde" Lösung.
Ich habe alexa-fhem sauber neu installiert, da jetzt eine ältere Version drüber-"patchen" klingt abenteurlich.
Mein libs liegen (ubuntu) unter /usr/lib, in /usr/local/lib waren vorher Überbleibsel alter Installationen. Habe ich alles bereinigt.
Welche Version von alexa-fhem läuft bei Dir? Mit 0.5.61 habe ich keine Abstürze, wenn ich auf 0.5.65 umschalte schon. Die 0.5.65 hat aber halt den modeController Support an Bord.

Danke aber für den Tipp, ich probiere das mal.

Update: Deine libs sind nicht aus der aktuellen Version 0.5.65, sondern vermutlich aus der 0.5.61. Die kann keinen ModeController. Mit Deinen libs crashed alexa-fhem zwar nicht, aber mode geht halt auch nicht :(
Developer: 70_ESCVP21net.pm, 70_SVDRP.pm
Mitglied FHEM e.V.

passibe

Zitat von: hapege am 02 Oktober 2025, 15:44:02Im log finde ich nichts dazu, keine Fehlermeldung.
Poste bitte mal trotzdem das Log, auch wenn dir erstmal nichts auffällt; irgendwas muss da ja geloggt werden, wenn die SSH-Verbindung gestoppt wird.

Ansonsten füge bitte mal das homebridgeMapping so hinzu und mach dann mal einset alexa reloadund dann poste aus dem Log mal die Stellen, in denen kino auftaucht. Während dem reload werden nämlich die einzelnen Devices bei Amazon "angemeldet" und da wird relativ detailliert aufgeschlüsselt a) was genau zu Amazon übermittelt wird und b) was Amazon zurückgibt, also wie Amazon die Geräte bei sich registriert.

Im Zweifel mal mehr aus dem Log posten als du denkst, dass es notwendig ist, vielleicht liegt der Teufel da irgendwo im Detail.

Wenn ich demnächst Zeit habe kann ich selbst mal probieren das bei mir zu definieren, habe (noch) keine Erfahrung mit ModeController, aber vielleicht schaffe ich es den Fehler zu reproduzieren.

fz55

Hallo,

installiert ist bei mir die Version 0.5.65 in /usr/local/bin/alexa-fhem. Ich hatte damals ein Fhem-Backup  auf einem neu aufgesetztem Debian Bookworm eingespielt und alexa-fhem nach FHEMWiki "FHEM Connector für Amazon Alexa" installiert. Leider funktionierte es wegen ModeController-Devices nicht, aber mit dem Überschreiben von /usr/local/lib/node_modules/alexa-fhem/lib ging wieder alles.

Soweit ich mich erinnern kann, habe ich das Kino-Beispiel in 2022 nicht zum Laufen bekommen, andere ModeController-Devices schon.