FHEMWiki - Benutzerbeiträge [de]

FHEM Connector für Amazon Alexa

2020-06-22T16:58:38Z

MadMax-FHEM: Kleine Korrektur am "proactiveEvents-Dummy"

{{Baustelle}}
'''Alexa FHEMlazy''' war historisch ein Fork des Original [[Alexa-Fhem|alexa-fhem]], der im Januar 2019 mit dem Original zusammengeführt wurde und nun als '''FHEM Connector''' verfügbar ist.

Er ermöglicht innerhalb von Minuten die Verknüpfung von FHEM mit einem Amazon Echo Gerät. Auch Geräte anderer Hersteller mit verbauten Mikrofonen und Alexa-Sprachassistenten-Unterstützung sollten problemlos funktionieren. Für folgende Geräte ist dies bspw. der Fall (Falls Ihr andere/weitere Gerätemodelle bzw. Hersteller in Verwendung habt, bitte hier pflegen):

* SONOS Beam und SONOS One

Gegenüber dem klassischen Ansatz ergeben sich Einschränkungen, so läuft die Software normalerweise unter dem gleichen Benutzer wie FHEM auf dem gleichen Server, und es wird z.Zt. nur der Smarthome-Skill unterstützt (die Variante, bei der die Möglichkeiten der Interaktion von Amazon festgelegt wurden).
Dafür ist weder ein Developer-Account bei Amazon, eigene Lambda- und Skillfunktionen, noch das Öffnen eines eingehenden Ports aus dem Internet nötig.
* Die Software integriert einen Installer, der die Erstkonfiguration und Anmeldung übernimmt
* Die Kommunikation zur Software auf dem heimischen Rechner und dann zu FHEM verläuft über SSH und einen vom FHEM-Verein gehosteten Server
* Funktioniert mit IPv4, IPv6, echtem Dual Stack und DS-Lite
* Als Skill bei Amazon wird der Skill "FHEM Connector" verwendet.

Der Thread im Forum zur Software ist hier: {{Link2Forum|Topic=94817}}.

{{Infobox Modul
|ModPurpose=Einfache Anbindung von FHEM an Amazon Assistent Alexa
|ModType=h
|ModCmdRef=alexa
|ModTechName=39_alexa.pm / alexa-fhem
|ModForumArea=Frontends/Sprachsteuerung
|ModOwner=gvzdus, André/ justme1968 ({{Link2FU|430|Forum}} / [[Benutzer Diskussion:Justme|Wiki]])
}}

==Einführung==

===Arbeitsweise und Datenfluss===
Vorläufig ist alexa-fhem im "FHEM Connector-Modus" ein reiner [https://developer.amazon.com/de/docs/smarthome/understand-the-smart-home-skill-api.html SmartHome-Skill].
SmartHome-Skills erhalten weder die Sprachdaten selber noch das, was Amazon in Textform verstanden hat, sondern vielmehr extrahiert Amazon aus dem verstandenen Text Anweisungen und Abfragen für Geräte, die dann an den Skill übermittelt werden. Charmant ist dabei, dass unmittelbar gefragt werden kann "Alexa, wie ist die Temperatur im Wohnzimmer?", während andere Skills zunächst explizit angesprochen werden müssen ("Alexa, frage FHEM nach der Temperatur im Wohnzimmer"). Außerdem kann der Nutzer mehrere Smarthome-Skills installieren, und die Geräte werden zu einer Gesamtmenge zusammengefasst.

Gehen wir den Datenfluss bei der konkreten Frage "Wie ist die Temperatur im Wohnzimmer?" durch:
* Alexa hat bei der Skillinstallation gelernt, dass "FHEM Connector" bei Dir einen Thermostaten im Raum Wohnzimmer kennt. Dadurch wird bei der Sprachanalyse von "Alexa Voice Service" in der Cloud erkannt, dass eine Abfrage an "FHEM Connector" erfolgversprechend ist.
* Zunächst wird die zentrale "Lambda-Funktion" von "FHEM Connector" aufgerufen. Die Funktion leitet aber im Kern nur den Request unverändert an den vom Verein bereitgestellten Server weiter. Im Request enthalten ist ein Token, das sogenannte "Bearer-Token".
* Der "Vereinsserver" prüft anhand dieses Tokens, ob es überhaupt bekannt ist, und zu welchem Nutzer es gehört. Ist dieser Nutzer verbunden, wird der Request wiederum quasi unverändert an den Nutzer weitergeleitet.
* Diese Weiterleitung passiert über einen sogenannten SSH-Reverse-Tunnel, der von Deiner Seite und der Software auf dem FHEM-Tunnel automatisch aufgebaut wird.
* Auf Deiner Seite läuft die eigentliche Software, und zwar unter nodeJS. nodeJS ist ein Javascript ausführender Miniserver, der lokal auf einem Zufallsport auf Requests "lauscht". In der Original-Version [[Alexa-Fhem|Alexa FHEM]] kommen die Requests aus dem Internet (hoffentlich von der eigenen Lambda-Funktion), hier bei "FHEM Connector" kommen sie ausschließlich aus dem SSH-Tunnel von lokal.
* Die Software validiert nun diesen Request anhand des Bearer-Tokens. Konkret wird dabei das bei der Installation generierte Token, dass bei der Skill-Aktivierung an Amazon übertragen wurde, mit dem lokal gespeicherten Wert verglichen. Stimmt das Token, wird der Befehl verarbeitet, üblicherweise wird hierbei ein Aufruf an die Webschnittstelle von FHEM abgesetzt.
* FHEM führt den Befehl aus

Hört sich langsam und kompliziert an? Kompliziert: Okay. Langsam eher nicht, in etlichen Fällen liegt die Gesamtantwortszeit unter 200 ms.

Soweit ein erster Überblick über die Datenflüsse. Im Abschnitt Sicherheit ist das Konzept der Absicherung deutlich genauer und ausführlicher beschrieben.

==Installation==

Du wirst bei der Installation zuerst auf der Kommandozeile auf Deinem Raspberry (o.ä.) unterwegs sein, anschließend im Webfrontend von FHEM, und zum Schluss auf der Alexa-Konsole im Web.

===node.js installieren===

Ab Jessy liegt NodeJS bereits in einer ausreichend aktuellen Version vor (Stretch und Buster funktionieren ebenfalls). Mit

<syntaxhighlight lang="bash" style="width:50%;">
sudo apt-get install nodejs npm
</syntaxhighlight>

kannst Du es installieren. Mit
<syntaxhighlight lang="bash" style="width:50%;">
node --version
</syntaxhighlight>

erfährst Du die aktuelle Version - wenn hier etwas mit "8" oder höher vorneweg erscheint, ist alles gut.
Ansonsten suche Dir bitte eine Anleitung im Web, wie Du NodeJS auf Deinem System auf einen aktuellen Stand bringen kannst.

'''Anmerkung:''' diese Aussage bzgl. node-Version (und Jessie/Stretch) stimmt wohl für alexa-fhem Stand heute (12.06.2020) nicht mehr, siehe https://forum.fhem.de/index.php/topic,112025.msg1063218.html#msg1063218

=== Alexa-FHEM installieren ===

Nun installieren wir Alexa-fhem aus dem offiziellen Repository:

<syntaxhighlight lang="bash" style="width:50%;">
sudo npm install -g alexa-fhem
</syntaxhighlight>

Der Vorgang benötigt etwas Zeit.

=== Alexa-FHEM aktivieren ===

Wechsele jetzt in FHEM-Web!

Wichtig ist, dass das Alexa-Modul in der Version ab Januar 2019 vorliegt. Dafür bitte einmal FHEM aktualisieren:
Speichern der Config nicht vergessen, und

<syntaxhighlight lang="bash" style="width:50%;">
update
shutdown restart
</syntaxhighlight>

Alles, was jetzt noch nötig ist, ist das Anlegen eines Alexa-Devices. Gib dafür in der FHEM-Web-Kommandozeile

<syntaxhighlight lang="bash" style="width:50%;">
define alexa alexa
</syntaxhighlight>

an. Nun läuft, während Du bereits das neu angelegte Alexa-Devices siehst, ein komplexer Prozess im Hintergrund:

* Falls noch kein SSH-Key für den Benutzer, unter dem FHEM läuft, existiert, wird einer generiert
* Es wird ein Secret-Key im Prozess generiert, dass den Server nicht verlässt, und der Skillanmeldung dient.
* Du wirst auf dem Server "va-fhem.fhem.de" des FHEM-Vereins mit dem SSH-Key angemeldet, und der Hash-Wert Deines Secret-Key dort abgelegt.

Und wenn Du diese Sätze gelesen hast, sollte inzwischen sich das Alexa-Device in FHEM-Web aktualisiert haben, und
ungefähr so aussehen:

[[Datei:Alexa-Device-2.png|800px]]

Neben dem Status für alexa-fhem und der Proxyverbindung ist wichtig, dass diese beiden Zeilen beim Reload aufgetaucht sind:

<syntaxhighlight lang="bash" style="width:90%;">
alexaFHEM.bearerToken crypt:...
alexaFHEM.skillRegKey crypt:...
</syntaxhighlight>

Ja, und diesen Schlüssel benötigst Du wirklich! Also am besten schon einmal mit

<syntaxhighlight lang="bash" style="width:90%;">
get <alexa> proxyKey
</syntaxhighlight>

in Klartext anzeigen lassen und in ein Editor-Fenster dauerhaft wegsichern.

Jetzt solltest Du Dein Alexa-Device nicht mehr löschen, denn das im Reading angezeigte "bearerToken" zu löschen bedeutet, dass die Software die Zugriffe von nicht mehr überprüfen kann und keine Kommandos mehr funktionieren. In diesem Fall hilft nur die Neuinstallation des Skills.

==== Fehler bei der Aktivierung ====

Während kompliziertere Fehlerfälle im Abschnitt "Mögliche Probleme und Lösungen" behandelt werden, hier häufige Fälle, warum die kryptischen Zeilen nicht auftauchen:

* Zuerst bitte einfach einmal die Seite neu laden.

===== 401: Authorization Required =====

Wenn Du FHEM-Web mit einem User/Passwort-Schutz versehen hast, wirst du folgende Fehlermeldung sehen:

<syntaxhighlight lang="bash" style="width:90%;">
alexaFHEM stopped; failed to connect to fhem: 401: Authorization Required
</syntaxhighlight>

In der Regel musst du die Angaben User/Passwort noch einmal explizit setzen. Im Attribute-Abschnitt "alexaFHEM-auth" auswählen, User/Passwort mit ":" getrennt angeben und "attr" anklicken. alexa-fhem wird automatisch neu gestartet. Hier das Ganze in der Text-Variante:

<syntaxhighlight lang="bash" style="width:90%;">
attr alexa alexaFHEM-auth user:pass
</syntaxhighlight>

===== Permission denied =====

Wenn du folgende Fehlermeldungen im Alexa Logfile siehst, wurde das Verzeichnis "/opt/fhem/.ssh/" von dir bei der Arbeit mit "root" oder "sudo" mit den falschen Berechtigungen versehen:

<syntaxhighlight lang="bash" style="width:90%;">
[2019-7-25 11:59:12] sshautoconf: aborted with ssh-keygen returned error - key_save_private: Permission denied
[2019-7-25 11:59:12] *** SSH: proxy configuration failed: ssh-keygen returned error - key_save_private: Permission denied
</syntaxhighlight>

Prüfen kannst du die Berechtigungen mit folgendem Befehl auf der Shell-Konsole:

<syntaxhighlight lang="bash" style="width:90%;">
ls -l /opt/fhem/.ssh
</syntaxhighlight>

Du solltest dann folgende Ausgabe erhalten:

<syntaxhighlight lang="bash" style="width:90%;">
insgesamt 12
-rw------- 1 fhem dialout 1675 Jul 12 13:10 id_rsa
-rw-r--r-- 1 fhem dialout 391 Jul 12 13:10 id_rsa.pub
-rw-r--r-- 1 fhem dialout 884 Jul 12 13:10 known_hosts
</syntaxhighlight>

Steht in der Ausgabe nicht "fhem dialout" (dein fhem User), sondern bspw. "root root", dann bspw. mit folgendem Befehl an deinen fhem User anpassen:

<syntaxhighlight lang="bash" style="width:90%;">
chown fhem:dialout /opt/fhem/.ssh
</syntaxhighlight>

Mit dem ersten Befehl "ls -l ..." kannst du dann nochmal prüfen, ob die Berechtigungen korrekt übernommen wurden.

===== weitere Prüfungen =====

Hast Du noch die Shell-Konsole offen? Dann prüfe bitte noch einmal auf der Konsole, ob nun zwei Prozesse laufen:

<syntaxhighlight lang="bash" style="width:50%;">
ps -ef | egrep '(alexa|ssh)'
</syntaxhighlight>

sollte Dir idealerweise so etwas anzeigen:
<syntaxhighlight lang="bash" style="width:90%;">
fhem 31322 1 99 13:56 ? 00:00:03 alexa
fhem 31332 31322 8 13:56 ? 00:00:00 /usr/bin/ssh -R 1234:127.0.0.1:<zufälliger port> -oServerAliveInterval=90 -p 58824 fhem-va.fhem.de
</syntaxhighlight>

"alexa" ist dabei der Node-JS-Prozess, der ssh-Prozess ist die aufgebaute Verbindung zum Vereinsserver.

Wenn Du diese Prozesse '''nicht''' siehst oder das Alexa-Device keinen Registrierungskey anzeigt, dann ist leider der Start nicht glatt verlaufen.

Im Logfile (über den link <code>Logfile</code> in der Detail-Ansicht über <code>set</code>, oder über den Namen bei ''currentlogfile'' in den Internals) findest Du idealerweise selber Hinweise, wo es hakt, oder kannst im Forum nachfragen.

=== Geräte im FHEM-Webfrontend zuweisen ===
Um das Aha-Erlebnis zu vergrößern, ist jetzt ein guter Zeitpunkt, 1 oder besser mind. 2 Geräte für den Alexa-Dienst zuzuweisen. Von Haus aus wird keines Deiner FHEM-Geräte automatisch Alexa zugewiesen!

Wähle die Geräte aus, rufe sie auf und setze das Attribut "alexaName". Hierbei in Kürze nur der Hinweis:
* Keine Angst vor Leerzeichen und Umlauten, funktioniert.
* Große Angst vor Rechtschreibfehlern (Terrasse, Rollladen) oder komplizierten Wörtern "handgebastelte Martinslaterne im Kinderzimmer Iphigenie-Chantal".
* Mehrere Namen für dasselbe Gerät/Device in fhem werden unterstützt. Mehrere Namen werden durch Strichpunkt getrennt<ref>Feature nicht dokumentiert {{Link2Forum|Topic=74041|LinkText=Forumsthread}}</ref>.
* Das Attribut "alexaRoom" ist NUR FÜR DEN CUSTOM SKILL relevant. Ausnahme: structure und LightScene Devices, siehe: [[FHEM_Connector_f%C3%BCr_Amazon_Alexa#Was_geht_alles_.3F]].

Lade die Geräte neu in die Software, indem Du <code>set <alexa> restart</code> ausführst!
[[Datei:HowToSet alexaName.png|alternativtext=How to set alexaName|ohne|mini|Wie setzt man das Attribut alexaName]]

'''Anmerkungen (weil oft gestellte Fragen im Forum) bzgl. Erkennung von Geräten:'''

* Wichtig ist, dass die Filtereinstellung in der alexa-fhem.cfg (zu finden unter "Edit Files") passt.
Das, was dort eingetragen ist (Standard: alexaName=..* / also es ist ein alexaName vergeben) auch an den entsprechenden Devices in fhem vorhanden ist.
Stimmt das nicht überein, kann alexa-fhem keine Devices von fhem abfragen/finden.
Ob der Filter entsprechend funktioniert kann man wie folgt testen: ''list Filtereinstellung'' beispiel mit Standardfilter: ''list alexaName=..*''

* Hat alexa-fhem per Filter Devices aus fhem "gefunden", geht es weiter mit der "Erkennung". Also um welches Device (Typ und "Fähigkeiten") handelt es sich. Dazu gilt folgendes:
** sind entsprechende Readings beim Device vorhanden (z.B. temperature, state mit on/off, ...) erkennt das alexa-fhem automatisch. Die Liste der automatisch erkannten Readings wächst ständig. Daher erst mal schauen ob das Device bereits entsprechend erkannt (typisiert) wurde. Das kann durch prüfen des alexa-fhem-Logs geschehen (NICHT fhem-log!).
** sind entsprechende "set-Befehle" erkennbar (oft auch durch Readings). Also ist beispielsweise (wie beim Dummy nötig) ein ''setList'' mit entsprechenden Einträgen vorhanden oder entsprechende Readings, z.B. desired-temp zum Stellen der Temperatur etc.
** wird das Device nicht richtig oder "unvollständig" erkannt helfen folgende Attribute:
*** genericDeviceType: hiermit kann alexa-fhem in die gewünschte Richtung "geschubbst" werden. Anmerkung: man kann nicht alles erzwingen, Readings bzw. set-Befehle müssen passen (oder per homebridgeMapping passend gemacht werden). Wenn ein genericDeviceType nicht per "Drop-Down" erscheint, dann kann er auch (wenn bekannt) einfach per WEB-cmd eingegeben werden: ''attr Devicename genericDeviceType media''
*** homebridgeMapping: hierdurch kann alexa-fhem bei der Erkennung von Zuständen und möglichen Einstellungen (also WAS kann das Device) unterstützt werden. Mittels homebridgeMapping können vorhandene Readings (Zustände) auf für alexa-fhem bekannte Zustände gemappt werden. Ebenso können damit Standard-fhem-Kommandos von alexa-fhem auf Device-spezifische gemappt werden. Beispiel: on/off auf Ein/Aus (falls das Device statt on/off eben ein Ein/Aus erwartet). Zum Beispiel: <syntaxhighlight lang="bash" style="width:50%;">
attr <thermostat> homebridgeMapping TargetTemperature=target::target,minValue=18,maxValue=25,minStep=0.5 CurrentTemperature=myTemp:temperature
</syntaxhighlight> [https://github.com/justme-1968/homebridge-fhem/blob/master/README.md weitere Beispiele]

 '''Mehrere Namen für dasselbe Gerät/Device in fhem sind möglich.''' 
Die Namen werden durch Strichpunkt getrennt. 
Beispiel: 
<code>attr dmLampe alexaName Lichtkuppel;Lichtkugel</code>

'''Anmerkung bzgl. genericDeviceType und homebridgeMapping:''' 
* diese Attribute werden von verschiedenen "Sprachsteuerungsmodulen" in fhem verwendet (homebridge [dort wurde es "erfunden"], alexa-fhem, gassistant, ...). Daher ist nicht jedes Mapping für alle "Dienste" verwendbar. Ausprobieren schadet aber nicht.
* ebenso kann man mit diesen Attributen (homebridgeMapping wird gerne so "missbraucht") nichts erzwingen, was seitens Amazon/Alexa nicht unterstützt bzw. verstanden wird! D.h. zunächst ist zu prüfen, ob ein bestimmter (gewünschter) Sprachbefehl seitens Amazon/Alexa unterstützt wird! Aktuelles Beispiel (Stand Jan 2020): "Alexa, fahre den Rollo hoch/runter". Da ist Amazon/Alexa gerade dabei etwas zu tun. Bislang wird das nicht unterstützt, also ist das auch mit einem entsprechenden homebridgeMapping nicht zu erzwingen! Was unterstützt wird kann man bei Amazon nachlesen: [https://developer.amazon.com/es-ES/docs/alexa/device-apis/list-of-interfaces.html]

== Finale: Skill verknüpfen ==
Suche im WebFrontend oder der Alexa-App den Skill "FHEM Connector". Für nicht-Mac/iOS Anwerder empfiehlt das WebFrontend (https://alexa.amazon.de) statt die App, damit Du den Anmeldeschlüssel auch bequem kopieren kannst.

Wenn du noch nicht bei Amazon angemeldet bist, erwartet Amazon zunächst, dass Du Dich normal bei Amazon anmeldest.

Sobald Du "FHEM Connector" aktivierst, öffnet sich ein Browser-Tab mit folgender Maske: 
[[Datei:FHEMlazy_login.png|240px]]

Hier kopierst Du Deinen Anmeldeschlüssel (im Klartext!) hinein und klickst auf Check. Als glücklicher Mensch ist auf der folgenden Statusseite alles grün: 
[[Datei:FHEMlazy_check.png|240px]]

Im Einzelnen wird hier geprüft, ob Du per SSH verbunden bist (und auch Deine IP zur Sicherheit angezeigt), ob der Reverse-Tunnel steht, ob nodeJS erreichbar ist und wie viele Geräte Alexa gleich finden sollte (in meinem Fall 22).

Sollte etwas nicht grün sein und Du eine Idee zum Fixen haben, kannst Du mit "Retry" neue Versuche auslösen.

Ist alles okay, klicke rechts den Button "Activate Skill". Du springst damit wieder zurück zu Amazon, die Dir hoffentlich zur erfolgreichen Verknüpfung gratulieren.

Amazon möchte nun unmittelbar die Gerätesuche starten, und unter SmartHome-Geräte sollten diese nun auftauchen.

== Was geht alles ? ==

* Geräte, die sich ein- und ausschalten lassen:
** Automatisch: Müssen <code>set on</code> und <code>set off</code> Kommandos haben
** dummys müssen <code>setList</code> mit on und off haben
** Über <code>genericDeviceType</code> switch bzw. light kann bestimmt werden ob es in alexa als Schalter oder Licht behandelt wird.
** Wenn die Set-Kommandos im FHEM Device anders benannt sind: homebridgeMapping On:cmdOn=<ein>,cmdOff=<aus> setzen
** Kommandos:
***Alexa, schalte <name> ein/aus
***Alexa, Licht an/aus
***Alexa, schalte <gruppe> ein/aus
* Geräte, die eine Temperatur messen
** Automatisch: Es muss ein Reading <code>temperature</code> geben
** Über <code>genericDeviceType</code> thermometer
** Sonst: homebridgeMapping CurrentTemperature:reading=<reading>

* Geräte, deren Helligkeit sich ändern lässt
** Automatisch: wenn <code>dim</code> oder <code>pct</code> Kommandos erkannt werden
** Über <code>genericDeviceType</code> light
** Über homebridgeMapping: Wenn <code>helligkeit</code> das Reading für die aktuelle Helligkeit enthält und die Helligkeit mit <code>set <device> prozent xxx</code> gesetzt wird, sieht das homebridgeMapping wie folgt aus: homebridgeMapping Brightness=helligkeit::prozent,minValue=0,maxValue=<maximalwert>
** Kommandos:
*** Alexa, mache <name> heller/dunkler
*** Alexa, Licht heller/dunkler
* Geräte, deren Farbe sich ändern lässt
** ...

* Geräte, deren Farbtemperatur sich ändern lässt
** ...

* Geräte, bei denen sich eine Lautstärke einstellen lässt
** ...

* Geräte, bei denen sich ein prozentualer Wert einstellen lässt
** Automatisch: wenn <code>dim</code> oder <code>pct</code> Kommandos erkannt werden
** ...

* elektrische Türschlösser
** <code>genericDeviceType</code>: lock
** homebridgeMapping mit LockCurrentState und LockTargetState

* Thermostate
** Über <code>genericDeviceType</code> thermostate
** ...

* structure Devices aus FHEM (ab alexa-fhem version 0.5.7)
** können mit <code>genericDeviceType</code> scene als Szene eingebunden werden
** über <code>alexaRoom</code> kann der name um einen Ort ergänzt werden
** Szenen aus einer structure lassen sich ein- und ausschalten
** Wichtig:
*** Ein Skill darf nur 12 Szenen automatisch erkennen und einbinden.

* LightScene Devices aus FHEM (ab alexa-fhem version 0.5.8)
** können mit <code>genericDeviceType</code> scene als Szenen eingebunden werden
** über <code>alexaRoom</code> kann der name um einen Ort ergänzt werden
** Szenen aus einer LightScene lassen sich nur einschalten
** Wichtig:
*** Ein Skill darf nur 12 Szenen automatisch erkennen und einbinden.

* Geräte, deren Kanal sich umschalten lässt (ab alexa-fhem version 0.5.13)
** Über <code>genericDeviceType</code> media
** homebridgeMapping ChannelController:reading=<reading>,cmd=<cmd>
** Erlaubte Werte siehe hier: https://developer.amazon.com/de/docs/device-apis/alexa-channelcontroller.html#changechannel
** ...

* Geräte, deren Playback status sich schalten lässt (ab alexa-fhem version 0.5.13)
** Über <code>genericDeviceType</code> media
** homebridgeMapping PlaybackController:playback,values=Play;Pause;Stop;Previous;Next
** Erlaubte Werte siehe hier: https://developer.amazon.com/de/docs/device-apis/alexa-playbackcontroller.html#discovery
** ...

* Geräte, deren Eingang sich umschalten lässt (ab alexa-fhem version 0.5.13)
** Über <code>genericDeviceType</code> media
** homebridgeMapping InputController:reading=<reading>,cmd=<cmd>,values=HDMI+1;HDMI+2;XBOX
** Erlaubte Werte siehe hier: https://developer.amazon.com/de/docs/device-apis/alexa-property-schemas.html#input
** ...

* Kontaktsensoren (ab alexa-fhem version 0.5.15)
** Über <code>genericDeviceType</code> contact
** homebridgeMapping ContactSensorState:reading=<reading> oder CurrentDoorState:reading=<reading>
** Die Anzeige in der Alexa-App funktioniert sofort, die Abfrage per Sprache erst ab Version 0.5.27.

* Geräte, deren Lautstärke sich ändern lässt (ab alexa-fhem version 0.5.24)
** Über <code>genericDeviceType</code> speaker
** Automatisch: es muss ein Reading <code>volume</code> und/oder <code>mute</code> geben
** homebridgeMapping Volume:reading=<reading>,cmd=<cmd> Mute:reading=<reading>,cmd=<cmd>
** ...

* Geräte, die sich ein- (und optional) ausschalten lassen als Szene (ab alexa-fhem version 0.5.26)
** Über <code>genericDeviceType</code> scene
** Automatisch: Müssen <code>set on</code> und <code>set off</code> Kommandos haben
** homebridgeMapping On:reading=<reading>,cmdOn=<cmd>[,cmdOff=<cmd>]
** Hinweis: Fehlende Kommandos lassen sich mit cmdalias erzeugen
** Wichtig:
*** Ein Skill darf nur 12 Szenen automatisch erkennen und einbinden.
* Rollläden. Lange ein Problemthema, das nur mit "Schalte auf 0%, schalte auf 100% lief". Wichtig: "alexa-fhem" ab Version 0.5.39 einsetzen. GenericDevice-Type auf "blind" setzen. Nach Restart von alexa-fhem und neuer Gerätesuche sollte folgendes funktionieren:
** "..., öffne <Name> ganz"
** "..., schließe <Name> komplett"
** "hoch" und "runter" (ohne "ganz" oder "komplett") schalten jeweils nur einen bestimmten Prozentsatz hoch oder runter. Dieser kann mit <code>attr <name> homebridgeMapping TargetPosition:minStep=<wert></code>geändert werden. Aber Achtung: In diesem Intervall kann dann auch nur noch ein absoluter Prozentwert per Sprache oder Slider eingestellt werden! Bei z.B. 25% würden 13% zu 25% aufgerundet, 12% zu 0% abgerundet werden.
* Kontaktsensoren (ab alexa-fhem version 0.5.47)
** Automatisch wenn ein Reading <code>motion</code> vorhanden ist oder es sich um einen Zigbee bewgungsmelder an einer HUE oder deCONZ Bridge handelt
** Über <code>genericDeviceType</code> MotionSensor
** homebridgeMapping MotionDetected:reading=<reading>,values=<wert für bewgung>:1;<wert für keine bewegung>:0

* Alarmmelder (noch nicht in Deutschland):
** genericDeviceType Security
** homebridgeMapping Alarm=<reading>[,type=[fireAlarm|waterAlarm|burglaryAlarm|carbonMonoxideAlarm]]
** wenn der type nicht angegeben wird ist fireAlarm der default
** automatisch werden 0, ok und alles was mit no anfängt als OK erkannt. alles andere gilt als ALARM.

Es werden noch einige andere häufig verwendete Geräte (Homematic, hue,...) automatisch erkannt.

to be continued ...

In der [https://developer.amazon.com/docs/device-apis/list-of-interfaces.html List of Capability Interfaces] bei Amazon kann man sehen, welche Möglichkeiten das Smart Home Skill API aktuell in einzelnen Ländern bietet. Leider ohne die jeweiligen landessprachlichen Kommandos.

=== Aktiv Routinen starten ===
Routinen (eine Funktionalität, die rein - genauso wie "Räume" - bei Amazon liegt und nicht von FHEM Connector beeinflusst wird) waren lange die ewige Antwort auf die Frage: "Meine Frau möchte aber '''Öffne Rollläden''<nowiki/>' sagen": In der Alexa-App gibt es im Menü den Punkt "Routinen", und hier lässt sich eine gewisse Anzahl von Aktionen (unter optionalen Bedingungen) an ein Sprachkommando knüpfen.

Neu: Routinen können inzwischen auch von Skills getriggert werden, und seit Version 0.5.47 (Februar 2020) auch von FHEM Connector. Das braucht niemand, um die Rollläden hochzufahren, denn das kann FHEM ja selber, aber um z.B. eine Ansage auf einem Alexa-Gerät zu triggern. Dafür gibt es auch das FHEM-Modul "echodevice", aber es erfordert ein paar Klimmzüge. Mit dem aktiven Triggern von Routinen kann FHEM auslösen, dass Alexa ungefragt (!) Dinge wie

''"Die Temperatur in der Tiefkühltruhe hat -16 Grad überschritten"''

in den Raum sagt. Also eine Alternative bzw. Ergänzung zu Alarmen / Erinnerungen per Telegram o.ä.

'''Vorgeschichte''':

Die Smarthome-Skill-API von Amazon sah schon lange das "proactiveReporting" vor: Also z.B. die gemessene Temperatur nicht erst auf Anfrage hin zu übermitteln, sondern laufend aktiv zu pushen. Aber warum Daten an Amazon senden, wenn es dafür keinen Mehrwert gibt? Beim Öffnen z.B. des Thermostaten in der Alexa-App kommen ohnehin laufend Statusabfragen. Warum also einen Datenpool bei Amazon über die Haustemperatur aufbauen und Änderungen pushen, wenn es keinen Mehrwert dafür gibt?

Inzwischen lassen sich (reale oder vermeintliche) Änderungen von ''Bewegungssensoren'' und ''Fensterkontakten'' als Startbedingung an Alexa-Routinen koppeln. Man kann in der Alexa-App (ggf. fiktive) Öffnen eines Fensterkontaktes an das Aufsagen eines freien Textes durch die Hausbutlerin knüpfen.

'''Umsetzung''':
* Jedes Alexa-Device, dessen Status aktiv zu Amazon gepusht werden soll, im Attribut "alexaProactiveEvents" mit einer "1" versehen. Per Default wird ''kein'' Gerät laufend aktiv zu Amazon gepusht!
* das geänderte Device einmal zu Amazon pushen "set <alexa> add <device>" (oder 'Alexa, suche neue Geräte' murmeln)
* Das Gerät sollte jetzt beim Anlegen einer neuen Routine ("Neue Routine", "Wenn Folgendes passiert", "Smart Home") als möglicher Triggerpunkt erscheinen.

==== Dummygeräte: ====
Ein Dummydevice sollte einen Kontaktschalter oder Bewegungssensor simulieren, um dann in FHEM eine beliebige Bedingung als Trigger zu definieren, und eine freie Ansage in Alexa als Routine zu definieren. Hier ein Beispiel:

<syntaxhighlight lang="bash" style="width:90%;">
define voicetrigger1 dummy
attr voicetrigger1 alexaName alle Fenster
attr voicetrigger1 alexaProactiveEvents 1
attr voicetrigger1 genericDeviceType contact
attr voicetrigger1 homebridgeMapping ContactSensorState=state,values=closed:CONTACT_DETECTED;open:CONTACT_NOT_DETECTED
attr voicetrigger1 setList open closed

set alexa add voicetrigger1
set alexa restart
</syntaxhighlight>

'''Fehlersuche:'''

Der Push setzt ein intaktes Push-Token voraus. Sollte im Alexa-Logfile Folgendes erscheinen:

<code>failed to refresh token: invalid_grant: 'The request has an invalid grant parameter : refresh_token'</code>

so ist das Push-Token nicht aktuell. Weil die Auswirkung lange nur war, dass Geräteänderungen nicht aktiv an Amazon gemeldet wurden, gibt es noch keine umfassende Analyse des Problems. Es lässt sich lösen, indem eine oder beide folgenden Aktionen ausgeführt werden:
* Löschen des ".eventToken" im Alexa-Device über "deletereading"
* "FHEM-Connector"-Skill auf "alexa.amazon.de" einmal deaktivieren und dann neu verbinden

== Mögliche Probleme und Lösungen ==

Es kann vorkommen, dass Geräte zwar korrekt erkannt werden, aber das durch Alexa erkannte Kommando nicht richtig umgesetzt wird (Beispiel - mittlerweile behoben: {{Link2Forum|Topic=96766}}). Neben dem FHEM-Log gibt es noch das Logfile, welches von alexa-fhem angelegt wird.

=== Fehlersuche über die FHEM-Oberfläche ===

* alexa-fhem Logfile anschauen (Detail-Ansicht des <alexa>-Device aufrufen, klick auf '''Logfile''' oben)
* alexa-fhem im Debug-Modus aufrufen:
** -D zum alexaFHEM-params attribut hinzufügen
** Alexa-Befehl auslösen
** -D aus dem alexaFHEM-params attribut entfernen
* Die notwendigen Informationen finden sich in dem alexa-Logfile (siehe oben)

=== Fehlersuche über Kommandozeile (lies: Shell) + FHEM-Oberfläche ===

:* set <alexa> stop (FHEM-Oberfläche)
:* Auf der Kommandozeile <code>alexa-fhem -D -c /opt/fhem/alexa-fhem.cfg > debug.log</code> starten (dadurch wird die Datei debug.log erzeugt im aktuellen Verzeichnis)
:* Alexa-Befehl auslösen
:* alexa-fhem auf der Kommandozeile wieder stoppen (CTRL-C)
:* set <alexa> start (FHEM-Oberfläche)

Die Datei debug.log sollte Hinweise enthalten, wie das Problem zu lösen ist oder Dich zumindest in die richtige Richtung schieben.

Im Beispiel aus dem Forum fand sich in dem Logfile der Hinweis darauf, dass das Device mit falschen min/max-Werten unterwegs war.

=== Registrierungskey vergessen, Registrierung zurücksetzen ===

Auf der Kommandoshell:

<syntaxhighlight lang="bash" style="width:90%;">
pi@raspberrypi:~# sudo -u fhem ssh -p 58824 fhem-va.fhem.de status
Registered.
Registered on 2019-01-13T15:38:13Z.
</syntaxhighlight>

heisst, das der Vereinsserver eigentlich alles hat, was er will. Es wird kein neuer Schlüssel generiert.
Wenn Du die Situation zurücksetzen möchtest, wäre die hässliche Methode, Deinen SSH-Key zu löschen. Eleganter ist, die Registrierung auf Vereinsseite zu löschen:

<syntaxhighlight lang="bash" style="width:90%;">
pi@raspberrypi:~# sudo -u fhem ssh -p 58824 fhem-va.fhem.de unregister
Your registration has been removed
</syntaxhighlight>

löscht Deinen Schlüssel mitsamt allen dort gespeicherten Daten auf Vereinsseite. Bei Restart von alexa-fhem in FHEM-WEB wird jetzt ein neuer Registrierungskey angefordert.

== Sicherheitskonzept und Secrets ==

Um diesen Abschnitt zu verstehen, solltest Du den Abschnitt "Arbeitsweise" im Kopf haben. Einerseits ist Dir vermutlich einleuchtend, dass ein Server, der per SSH rückwärts nur ausgewählte Kommandos in den Tunnel, den Du aufgebaut hast, leitet, "irgendwie sicherer" ist. Andererseits möchte man nicht blind vertrauen.

=== SSH ===
==== SSH - macht das nichts Gefährliches? ====
SSH ist ein Veteran des Internet und entstand, um sich sicher (verschlüsselt) und schnell auf Servern einzuloggen. Schon früh wurde dabei der sogenannte "Reverse-Tunnel" implementiert: Also der vom Client (Deinem Rechner) geäußerte Wunsch: "Bitte leite mir Requests, die bei Dir, Server, auf Port xy eingehen, an meinen lokalen Port yz weiter.". Dieses Verfahren implementiert der Reverseproxy, wobei tatsächlich auf dem Server für Dich kein echter Port geöffnet wird.

Wie Dir ggf. sicher der Unix-Guru Deines Vertrauens bestätigen wird: Die Kombination
<syntaxhighlight lang="bash" style="width:50%;">
ssh -R 1234:localhost:<zufälliger port> zielserver
</syntaxhighlight>
erlaubt keine Ausführung von Shell-Kommandos auf Deinem Server, sondern einzig, dass vom SSH-Programm Verbindungen zu einem lokalen Port auf Deinem Server auf dem alexa-fhem lauscht aufgebaut werden. Du kannst also z.B. mit einem
<syntaxhighlight lang="bash" style="width:50%;">
sudo /usr/sbin/tcpdump -X -s 0 -i lo port <zufälliger port>
</syntaxhighlight>
vollständig überwachen (oder ggf. permanent aufzeichen), was auf Deinem Server von außen gesteuert passiert.

==== Wie wird bei SSH verschlüsselt? ====
Im Prinzip wie im Web auf SSL-Seiten, teils mit den gleichen Verschlüsselungsverfahren. Allerdings arbeitet SSH eher wie das im Web recht seltene Verfahren: Bei jeder Verbindung übermitteln sowohl Server wie auch Client den öffentlichen Teil ihres Schlüssels. Anders als im Web wird der Schlüssel aber nicht von einer öffentlichen Zertifizierungsstelle wie "LetsEncrypt" unterschrieben. Stattdessen entscheiden Server wie Client beim ersten Verbindungsaufbau typischerweise per manueller Frage: "Willst Du jetzt und künftig diesem Schlüssel vertrauen?" Bei der Installation wird diese Frage für Deine Seite bejaht, und fortan wird der öffentliche Schlüssel des FHEM-Servers auf Deinem Rechner gespeichert. Ab da bist Du z.B. davor sicher, dass jemand den DNS-Eintrag verbiegt oder sich in den Datenfluss Deines Providers einhängt: Ein geänderter Serverschlüssel würde bemerkt werden.
 
Soweit klar? Aus Deinem öffentlichen Schlüssel wiederum leitet der Server her: "Das ist definitiv wieder derjenige, der sich damals "registriert" hat". Und an dieser Stelle kann ich auch den ersten Teil des 3-teiligen Registrierungskeys erläutern: Die typischerweise 6-stellige Hex-Zahl am Anfang ist der Java-Hashcode Deines öffentlichen Schlüssel. Sie ist damit sozusagen Deine aus Deinem öffentlichen Schlüssel abgeleitete Benutzer-ID.

=== Die Rolle der Secrets ===
Wenn jetzt klar ist, dass die Verbindung zum Vereinsserver sicher und vertauschungsfrei funktioniert, bleiben noch 2 Probleme zu lösen:
1) Im Web bei der Skill-Aktivierung musst Du beweisen, dass Du der Mensch am Browser bist, dem der SSH-Tunnel von IP xy mit dem öffentlichen Schlüssel X gehört. Bei der automatischen Registrierung werden lokal auf Deinem Rechner zwei 64-Bit-Secrets generiert:
* Das Anmelde-Secret
* Das Bearer-Token
Beim Anmelden des SSH-Keys auf dem öffentlichen Server wird nun der Hashwert des ersten Secrets übertragen und dort in Verbindung mit Deinem öffentlichen Schlüssel gespeichert. Ein Hashwert bedeutet, dass (sofern das Verfahren, hier SHA256, funktioniert), niemand aus dem Hash das Secret zurückrechnen kann. Ein Datenbankklau auf dem Server gefährdet also nicht die Sicherheit Deines Passwortes.

Wenn Du nun beim Skill-Aktivieren den Registrierungskey eingibst, dann "sieht" der Server zum ersten Mal Dein ausgewürfeltes Secret, vergleicht es mit dem Hashwert und wird es anschließend wieder umgehend vergessen. Anhand des Hashwertes kann der Server aber entscheiden, dass Du der legitime Nutzer zum öffentlichen Schlüssel XY bist.

2) Das zweite Problem ist: Wie soll Amazon "beweisen", dass sie der legitime Aufrufer sind? Amazon erhält binnen wenigen Sekunden nach dem Klick auf "Activate Skill" den dritten Teil des Registrierungskeys als sogenanntes Bearer-Token. Zwar läuft er durch den Registrierungsserver, er wird dort, auf dem Registrierungs/Vereinsserver aber nicht gespeichert. Das Bearer-Token wird von Amazon bei allen Requests zu Deinem Server mitgesendet. Da es am Anfang zusätzlich Deine "User-ID" enthält, weiß der Vereinsserver, zu welchem SSH-Tunnel der Request zu senden ist. Aber lokal auf Deinem Rechner wird ausgewertet, ob das Token "stimmt".

== alexa-fhem Updaten bzw. "Upgraden" ==

'''Updaten einer "Connector" Installation:'''
* alexa-fhem über FHEM anhalten (Name des Alexa-Device: alexa):
:<syntaxhighlight lang="perl" style="width:50%;">set alexa stop</syntaxhighlight>

*Auf der Konsole wie anfangs bei der Installation:
:<syntaxhighlight lang="bash" style="width:50%;">sudo npm update -g alexa-fhem</syntaxhighlight>

:Manchmal hat npm Probleme mit einem Update. Dann einfach die aktuelle Version noch mal drüber Installieren:

:<syntaxhighlight lang="bash" style="width:50%;">sudo npm install -g alexa-fhem</syntaxhighlight>

*alexa-fhem über FHEM wieder starten:
:<syntaxhighlight lang="perl" style="width:50%;">set alexa start</syntaxhighlight>

'''"Upgraden von einer "Nicht-Connector" Installation (z.B. manuelle Installation per pm-Download):'''
* Daten der aktuellen Installation sichern (v.a. config.json / man weiß ja nie)
* Autostart der aktuellen alexa-fhem Installation deaktivieren:
** Bei initd: Service deaktivieren mittels: <code>sudo update-rc.d -f alexa remove</code> Vorher mittels stoppen: <code>sudo service alexa stop</code> Startscript unter /etc/init.d/ löschen.
** Bei systemd: Service deaktivieren mittels: <code>sudo systemctl disable alexa</code> Vorher mittels stoppen: <code>sudo systemctl alexa stop</code> Startscript unter /etc/systemd/system/ löschen.
* ALLE vorhandenen alexa-fhem Daten LÖSCHEN! Bleiben Dinge zurück und wird dann laut Connector installiert kann es zu Problemen kommen!
* (reboot)
* Installation von alexa-fhem laut Anleitung (Beginn dieses Wiki)
* Falls eigene Dinge von früher genutzt werden wollen/sollen (z.B. Custom Skill), dann die entsprechenden Einträge aus der gesicherten config.json in die neu angelegte alexa-fhem.cfg (zu finden unter "Edit files") übernehmen.
* Werden keine eigenen Dinge verwendet, dann kann der Port (Standard: 3000) geschlossen werden und auch die Daten unter Amazon-Developer können gelöscht werden.

== Bug- und Wunschliste ==
* Ist beim Start keine Internetverbindung vorhanden, erfolgt kein Retry -- alexa-fhem muss restartet werden (ssh_autoconfig wertet keine temporären Fehler aus)

==Weitergehende Informationen==
*[[Alexa und Mappings]]
*[[Alexa Tipps und Kniffe]]
*[[FHEM Connector for Amazon Alexa]]
[[Kategorie:HOWTOS]]
[[Kategorie:Sprachsteuerung]]

==Hinweise==
<references />

FHEM Connector für Amazon Alexa

2020-06-12T09:09:37Z

MadMax-FHEM:

{{Baustelle}}
'''Alexa FHEMlazy''' war historisch ein Fork des Original [[Alexa-Fhem|alexa-fhem]], der im Januar 2019 mit dem Original zusammengeführt wurde und nun als '''FHEM Connector''' verfügbar ist.

Er ermöglicht innerhalb von Minuten die Verknüpfung von FHEM mit einem Amazon Echo Gerät. Auch Geräte anderer Hersteller mit verbauten Mikrofonen und Alexa-Sprachassistenten-Unterstützung sollten problemlos funktionieren. Für folgende Geräte ist dies bspw. der Fall (Falls Ihr andere/weitere Gerätemodelle bzw. Hersteller in Verwendung habt, bitte hier pflegen):

* SONOS Beam und SONOS One

Gegenüber dem klassischen Ansatz ergeben sich Einschränkungen, so läuft die Software normalerweise unter dem gleichen Benutzer wie FHEM auf dem gleichen Server, und es wird z.Zt. nur der Smarthome-Skill unterstützt (die Variante, bei der die Möglichkeiten der Interaktion von Amazon festgelegt wurden).
Dafür ist weder ein Developer-Account bei Amazon, eigene Lambda- und Skillfunktionen, noch das Öffnen eines eingehenden Ports aus dem Internet nötig.
* Die Software integriert einen Installer, der die Erstkonfiguration und Anmeldung übernimmt
* Die Kommunikation zur Software auf dem heimischen Rechner und dann zu FHEM verläuft über SSH und einen vom FHEM-Verein gehosteten Server
* Funktioniert mit IPv4, IPv6, echtem Dual Stack und DS-Lite
* Als Skill bei Amazon wird der Skill "FHEM Connector" verwendet.

Der Thread im Forum zur Software ist hier: {{Link2Forum|Topic=94817}}.

{{Infobox Modul
|ModPurpose=Einfache Anbindung von FHEM an Amazon Assistent Alexa
|ModType=h
|ModCmdRef=alexa
|ModTechName=39_alexa.pm / alexa-fhem
|ModForumArea=Frontends/Sprachsteuerung
|ModOwner=gvzdus, André/ justme1968 ({{Link2FU|430|Forum}} / [[Benutzer Diskussion:Justme|Wiki]])
}}

==Einführung==

===Arbeitsweise und Datenfluss===
Vorläufig ist alexa-fhem im "FHEM Connector-Modus" ein reiner [https://developer.amazon.com/de/docs/smarthome/understand-the-smart-home-skill-api.html SmartHome-Skill].
SmartHome-Skills erhalten weder die Sprachdaten selber noch das, was Amazon in Textform verstanden hat, sondern vielmehr extrahiert Amazon aus dem verstandenen Text Anweisungen und Abfragen für Geräte, die dann an den Skill übermittelt werden. Charmant ist dabei, dass unmittelbar gefragt werden kann "Alexa, wie ist die Temperatur im Wohnzimmer?", während andere Skills zunächst explizit angesprochen werden müssen ("Alexa, frage FHEM nach der Temperatur im Wohnzimmer"). Außerdem kann der Nutzer mehrere Smarthome-Skills installieren, und die Geräte werden zu einer Gesamtmenge zusammengefasst.

Gehen wir den Datenfluss bei der konkreten Frage "Wie ist die Temperatur im Wohnzimmer?" durch:
* Alexa hat bei der Skillinstallation gelernt, dass "FHEM Connector" bei Dir einen Thermostaten im Raum Wohnzimmer kennt. Dadurch wird bei der Sprachanalyse von "Alexa Voice Service" in der Cloud erkannt, dass eine Abfrage an "FHEM Connector" erfolgversprechend ist.
* Zunächst wird die zentrale "Lambda-Funktion" von "FHEM Connector" aufgerufen. Die Funktion leitet aber im Kern nur den Request unverändert an den vom Verein bereitgestellten Server weiter. Im Request enthalten ist ein Token, das sogenannte "Bearer-Token".
* Der "Vereinsserver" prüft anhand dieses Tokens, ob es überhaupt bekannt ist, und zu welchem Nutzer es gehört. Ist dieser Nutzer verbunden, wird der Request wiederum quasi unverändert an den Nutzer weitergeleitet.
* Diese Weiterleitung passiert über einen sogenannten SSH-Reverse-Tunnel, der von Deiner Seite und der Software auf dem FHEM-Tunnel automatisch aufgebaut wird.
* Auf Deiner Seite läuft die eigentliche Software, und zwar unter nodeJS. nodeJS ist ein Javascript ausführender Miniserver, der lokal auf einem Zufallsport auf Requests "lauscht". In der Original-Version [[Alexa-Fhem|Alexa FHEM]] kommen die Requests aus dem Internet (hoffentlich von der eigenen Lambda-Funktion), hier bei "FHEM Connector" kommen sie ausschließlich aus dem SSH-Tunnel von lokal.
* Die Software validiert nun diesen Request anhand des Bearer-Tokens. Konkret wird dabei das bei der Installation generierte Token, dass bei der Skill-Aktivierung an Amazon übertragen wurde, mit dem lokal gespeicherten Wert verglichen. Stimmt das Token, wird der Befehl verarbeitet, üblicherweise wird hierbei ein Aufruf an die Webschnittstelle von FHEM abgesetzt.
* FHEM führt den Befehl aus

Hört sich langsam und kompliziert an? Kompliziert: Okay. Langsam eher nicht, in etlichen Fällen liegt die Gesamtantwortszeit unter 200 ms.

Soweit ein erster Überblick über die Datenflüsse. Im Abschnitt Sicherheit ist das Konzept der Absicherung deutlich genauer und ausführlicher beschrieben.

==Installation==

Du wirst bei der Installation zuerst auf der Kommandozeile auf Deinem Raspberry (o.ä.) unterwegs sein, anschließend im Webfrontend von FHEM, und zum Schluss auf der Alexa-Konsole im Web.

===node.js installieren===

Ab Jessy liegt NodeJS bereits in einer ausreichend aktuellen Version vor (Stretch und Buster funktionieren ebenfalls). Mit

<syntaxhighlight lang="bash" style="width:50%;">
sudo apt-get install nodejs npm
</syntaxhighlight>

kannst Du es installieren. Mit
<syntaxhighlight lang="bash" style="width:50%;">
node --version
</syntaxhighlight>

erfährst Du die aktuelle Version - wenn hier etwas mit "8" oder höher vorneweg erscheint, ist alles gut.
Ansonsten suche Dir bitte eine Anleitung im Web, wie Du NodeJS auf Deinem System auf einen aktuellen Stand bringen kannst.

'''Anmerkung:''' diese Aussage bzgl. node-Version (und Jessie/Stretch) stimmt wohl für alexa-fhem Stand heute (12.06.2020) nicht mehr, siehe https://forum.fhem.de/index.php/topic,112025.msg1063218.html#msg1063218

=== Alexa-FHEM installieren ===

Nun installieren wir Alexa-fhem aus dem offiziellen Repository:

<syntaxhighlight lang="bash" style="width:50%;">
sudo npm install -g alexa-fhem
</syntaxhighlight>

Der Vorgang benötigt etwas Zeit.

=== Alexa-FHEM aktivieren ===

Wechsele jetzt in FHEM-Web!

Wichtig ist, dass das Alexa-Modul in der Version ab Januar 2019 vorliegt. Dafür bitte einmal FHEM aktualisieren:
Speichern der Config nicht vergessen, und

<syntaxhighlight lang="bash" style="width:50%;">
update
shutdown restart
</syntaxhighlight>

Alles, was jetzt noch nötig ist, ist das Anlegen eines Alexa-Devices. Gib dafür in der FHEM-Web-Kommandozeile

<syntaxhighlight lang="bash" style="width:50%;">
define alexa alexa
</syntaxhighlight>

an. Nun läuft, während Du bereits das neu angelegte Alexa-Devices siehst, ein komplexer Prozess im Hintergrund:

* Falls noch kein SSH-Key für den Benutzer, unter dem FHEM läuft, existiert, wird einer generiert
* Es wird ein Secret-Key im Prozess generiert, dass den Server nicht verlässt, und der Skillanmeldung dient.
* Du wirst auf dem Server "va-fhem.fhem.de" des FHEM-Vereins mit dem SSH-Key angemeldet, und der Hash-Wert Deines Secret-Key dort abgelegt.

Und wenn Du diese Sätze gelesen hast, sollte inzwischen sich das Alexa-Device in FHEM-Web aktualisiert haben, und
ungefähr so aussehen:

[[Datei:Alexa-Device-2.png|800px]]

Neben dem Status für alexa-fhem und der Proxyverbindung ist wichtig, dass diese beiden Zeilen beim Reload aufgetaucht sind:

<syntaxhighlight lang="bash" style="width:90%;">
alexaFHEM.bearerToken crypt:...
alexaFHEM.skillRegKey crypt:...
</syntaxhighlight>

Ja, und diesen Schlüssel benötigst Du wirklich! Also am besten schon einmal mit

<syntaxhighlight lang="bash" style="width:90%;">
get <alexa> proxyKey
</syntaxhighlight>

in Klartext anzeigen lassen und in ein Editor-Fenster dauerhaft wegsichern.

Jetzt solltest Du Dein Alexa-Device nicht mehr löschen, denn das im Reading angezeigte "bearerToken" zu löschen bedeutet, dass die Software die Zugriffe von nicht mehr überprüfen kann und keine Kommandos mehr funktionieren. In diesem Fall hilft nur die Neuinstallation des Skills.

==== Fehler bei der Aktivierung ====

Während kompliziertere Fehlerfälle im Abschnitt "Mögliche Probleme und Lösungen" behandelt werden, hier häufige Fälle, warum die kryptischen Zeilen nicht auftauchen:

* Zuerst bitte einfach einmal die Seite neu laden.

===== 401: Authorization Required =====

Wenn Du FHEM-Web mit einem User/Passwort-Schutz versehen hast, wirst du folgende Fehlermeldung sehen:

<syntaxhighlight lang="bash" style="width:90%;">
alexaFHEM stopped; failed to connect to fhem: 401: Authorization Required
</syntaxhighlight>

In der Regel musst du die Angaben User/Passwort noch einmal explizit setzen. Im Attribute-Abschnitt "alexaFHEM-auth" auswählen, User/Passwort mit ":" getrennt angeben und "attr" anklicken. alexa-fhem wird automatisch neu gestartet. Hier das Ganze in der Text-Variante:

<syntaxhighlight lang="bash" style="width:90%;">
attr alexa alexaFHEM-auth user:pass
</syntaxhighlight>

===== Permission denied =====

Wenn du folgende Fehlermeldungen im Alexa Logfile siehst, wurde das Verzeichnis "/opt/fhem/.ssh/" von dir bei der Arbeit mit "root" oder "sudo" mit den falschen Berechtigungen versehen:

<syntaxhighlight lang="bash" style="width:90%;">
[2019-7-25 11:59:12] sshautoconf: aborted with ssh-keygen returned error - key_save_private: Permission denied
[2019-7-25 11:59:12] *** SSH: proxy configuration failed: ssh-keygen returned error - key_save_private: Permission denied
</syntaxhighlight>

Prüfen kannst du die Berechtigungen mit folgendem Befehl auf der Shell-Konsole:

<syntaxhighlight lang="bash" style="width:90%;">
ls -l /opt/fhem/.ssh
</syntaxhighlight>

Du solltest dann folgende Ausgabe erhalten:

<syntaxhighlight lang="bash" style="width:90%;">
insgesamt 12
-rw------- 1 fhem dialout 1675 Jul 12 13:10 id_rsa
-rw-r--r-- 1 fhem dialout 391 Jul 12 13:10 id_rsa.pub
-rw-r--r-- 1 fhem dialout 884 Jul 12 13:10 known_hosts
</syntaxhighlight>

Steht in der Ausgabe nicht "fhem dialout" (dein fhem User), sondern bspw. "root root", dann bspw. mit folgendem Befehl an deinen fhem User anpassen:

<syntaxhighlight lang="bash" style="width:90%;">
chown fhem:dialout /opt/fhem/.ssh
</syntaxhighlight>

Mit dem ersten Befehl "ls -l ..." kannst du dann nochmal prüfen, ob die Berechtigungen korrekt übernommen wurden.

===== weitere Prüfungen =====

Hast Du noch die Shell-Konsole offen? Dann prüfe bitte noch einmal auf der Konsole, ob nun zwei Prozesse laufen:

<syntaxhighlight lang="bash" style="width:50%;">
ps -ef | egrep '(alexa|ssh)'
</syntaxhighlight>

sollte Dir idealerweise so etwas anzeigen:
<syntaxhighlight lang="bash" style="width:90%;">
fhem 31322 1 99 13:56 ? 00:00:03 alexa
fhem 31332 31322 8 13:56 ? 00:00:00 /usr/bin/ssh -R 1234:127.0.0.1:<zufälliger port> -oServerAliveInterval=90 -p 58824 fhem-va.fhem.de
</syntaxhighlight>

"alexa" ist dabei der Node-JS-Prozess, der ssh-Prozess ist die aufgebaute Verbindung zum Vereinsserver.

Wenn Du diese Prozesse '''nicht''' siehst oder das Alexa-Device keinen Registrierungskey anzeigt, dann ist leider der Start nicht glatt verlaufen.

Im Logfile (über den link <code>Logfile</code> in der Detail-Ansicht über <code>set</code>, oder über den Namen bei ''currentlogfile'' in den Internals) findest Du idealerweise selber Hinweise, wo es hakt, oder kannst im Forum nachfragen.

=== Geräte im FHEM-Webfrontend zuweisen ===
Um das Aha-Erlebnis zu vergrößern, ist jetzt ein guter Zeitpunkt, 1 oder besser mind. 2 Geräte für den Alexa-Dienst zuzuweisen. Von Haus aus wird keines Deiner FHEM-Geräte automatisch Alexa zugewiesen!

Wähle die Geräte aus, rufe sie auf und setze das Attribut "alexaName". Hierbei in Kürze nur der Hinweis:
* Keine Angst vor Leerzeichen und Umlauten, funktioniert.
* Große Angst vor Rechtschreibfehlern (Terrasse, Rollladen) oder komplizierten Wörtern "handgebastelte Martinslaterne im Kinderzimmer Iphigenie-Chantal".
* Mehrere Namen für dasselbe Gerät/Device in fhem werden unterstützt. Mehrere Namen werden durch Strichpunkt getrennt<ref>Feature nicht dokumentiert {{Link2Forum|Topic=74041|LinkText=Forumsthread}}</ref>.
* Das Attribut "alexaRoom" ist NUR FÜR DEN CUSTOM SKILL relevant. Ausnahme: structure und LightScene Devices, siehe: [[FHEM_Connector_f%C3%BCr_Amazon_Alexa#Was_geht_alles_.3F]].

Lade die Geräte neu in die Software, indem Du <code>set <alexa> restart</code> ausführst!
[[Datei:HowToSet alexaName.png|alternativtext=How to set alexaName|ohne|mini|Wie setzt man das Attribut alexaName]]

'''Anmerkungen (weil oft gestellte Fragen im Forum) bzgl. Erkennung von Geräten:'''

* Wichtig ist, dass die Filtereinstellung in der alexa-fhem.cfg (zu finden unter "Edit Files") passt.
Das, was dort eingetragen ist (Standard: alexaName=..* / also es ist ein alexaName vergeben) auch an den entsprechenden Devices in fhem vorhanden ist.
Stimmt das nicht überein, kann alexa-fhem keine Devices von fhem abfragen/finden.
Ob der Filter entsprechend funktioniert kann man wie folgt testen: ''list Filtereinstellung'' beispiel mit Standardfilter: ''list alexaName=..*''

* Hat alexa-fhem per Filter Devices aus fhem "gefunden", geht es weiter mit der "Erkennung". Also um welches Device (Typ und "Fähigkeiten") handelt es sich. Dazu gilt folgendes:
** sind entsprechende Readings beim Device vorhanden (z.B. temperature, state mit on/off, ...) erkennt das alexa-fhem automatisch. Die Liste der automatisch erkannten Readings wächst ständig. Daher erst mal schauen ob das Device bereits entsprechend erkannt (typisiert) wurde. Das kann durch prüfen des alexa-fhem-Logs geschehen (NICHT fhem-log!).
** sind entsprechende "set-Befehle" erkennbar (oft auch durch Readings). Also ist beispielsweise (wie beim Dummy nötig) ein ''setList'' mit entsprechenden Einträgen vorhanden oder entsprechende Readings, z.B. desired-temp zum Stellen der Temperatur etc.
** wird das Device nicht richtig oder "unvollständig" erkannt helfen folgende Attribute:
*** genericDeviceType: hiermit kann alexa-fhem in die gewünschte Richtung "geschubbst" werden. Anmerkung: man kann nicht alles erzwingen, Readings bzw. set-Befehle müssen passen (oder per homebridgeMapping passend gemacht werden). Wenn ein genericDeviceType nicht per "Drop-Down" erscheint, dann kann er auch (wenn bekannt) einfach per WEB-cmd eingegeben werden: ''attr Devicename genericDeviceType media''
*** homebridgeMapping: hierdurch kann alexa-fhem bei der Erkennung von Zuständen und möglichen Einstellungen (also WAS kann das Device) unterstützt werden. Mittels homebridgeMapping können vorhandene Readings (Zustände) auf für alexa-fhem bekannte Zustände gemappt werden. Ebenso können damit Standard-fhem-Kommandos von alexa-fhem auf Device-spezifische gemappt werden. Beispiel: on/off auf Ein/Aus (falls das Device statt on/off eben ein Ein/Aus erwartet). Zum Beispiel: <syntaxhighlight lang="bash" style="width:50%;">
attr <thermostat> homebridgeMapping TargetTemperature=target::target,minValue=18,maxValue=25,minStep=0.5 CurrentTemperature=myTemp:temperature
</syntaxhighlight> [https://github.com/justme-1968/homebridge-fhem/blob/master/README.md weitere Beispiele]

 '''Mehrere Namen für dasselbe Gerät/Device in fhem sind möglich.''' 
Die Namen werden durch Strichpunkt getrennt. 
Beispiel: 
<code>attr dmLampe alexaName Lichtkuppel;Lichtkugel</code>

'''Anmerkung bzgl. genericDeviceType und homebridgeMapping:''' 
* diese Attribute werden von verschiedenen "Sprachsteuerungsmodulen" in fhem verwendet (homebridge [dort wurde es "erfunden"], alexa-fhem, gassistant, ...). Daher ist nicht jedes Mapping für alle "Dienste" verwendbar. Ausprobieren schadet aber nicht.
* ebenso kann man mit diesen Attributen (homebridgeMapping wird gerne so "missbraucht") nichts erzwingen, was seitens Amazon/Alexa nicht unterstützt bzw. verstanden wird! D.h. zunächst ist zu prüfen, ob ein bestimmter (gewünschter) Sprachbefehl seitens Amazon/Alexa unterstützt wird! Aktuelles Beispiel (Stand Jan 2020): "Alexa, fahre den Rollo hoch/runter". Da ist Amazon/Alexa gerade dabei etwas zu tun. Bislang wird das nicht unterstützt, also ist das auch mit einem entsprechenden homebridgeMapping nicht zu erzwingen! Was unterstützt wird kann man bei Amazon nachlesen: [https://developer.amazon.com/es-ES/docs/alexa/device-apis/list-of-interfaces.html]

== Finale: Skill verknüpfen ==
Suche im WebFrontend oder der Alexa-App den Skill "FHEM Connector". Für nicht-Mac/iOS Anwerder empfiehlt das WebFrontend (https://alexa.amazon.de) statt die App, damit Du den Anmeldeschlüssel auch bequem kopieren kannst.

Wenn du noch nicht bei Amazon angemeldet bist, erwartet Amazon zunächst, dass Du Dich normal bei Amazon anmeldest.

Sobald Du "FHEM Connector" aktivierst, öffnet sich ein Browser-Tab mit folgender Maske: 
[[Datei:FHEMlazy_login.png|240px]]

Hier kopierst Du Deinen Anmeldeschlüssel (im Klartext!) hinein und klickst auf Check. Als glücklicher Mensch ist auf der folgenden Statusseite alles grün: 
[[Datei:FHEMlazy_check.png|240px]]

Im Einzelnen wird hier geprüft, ob Du per SSH verbunden bist (und auch Deine IP zur Sicherheit angezeigt), ob der Reverse-Tunnel steht, ob nodeJS erreichbar ist und wie viele Geräte Alexa gleich finden sollte (in meinem Fall 22).

Sollte etwas nicht grün sein und Du eine Idee zum Fixen haben, kannst Du mit "Retry" neue Versuche auslösen.

Ist alles okay, klicke rechts den Button "Activate Skill". Du springst damit wieder zurück zu Amazon, die Dir hoffentlich zur erfolgreichen Verknüpfung gratulieren.

Amazon möchte nun unmittelbar die Gerätesuche starten, und unter SmartHome-Geräte sollten diese nun auftauchen.

== Was geht alles ? ==

* Geräte, die sich ein- und ausschalten lassen:
** Automatisch: Müssen <code>set on</code> und <code>set off</code> Kommandos haben
** dummys müssen <code>setList</code> mit on und off haben
** Über <code>genericDeviceType</code> switch bzw. light kann bestimmt werden ob es in alexa als Schalter oder Licht behandelt wird.
** Wenn die Set-Kommandos im FHEM Device anders benannt sind: homebridgeMapping On:cmdOn=<ein>,cmdOff=<aus> setzen
** Kommandos:
***Alexa, schalte <name> ein/aus
***Alexa, Licht an/aus
***Alexa, schalte <gruppe> ein/aus
* Geräte, die eine Temperatur messen
** Automatisch: Es muss ein Reading <code>temperature</code> geben
** Über <code>genericDeviceType</code> thermometer
** Sonst: homebridgeMapping CurrentTemperature:reading=<reading>

* Geräte, deren Helligkeit sich ändern lässt
** Automatisch: wenn <code>dim</code> oder <code>pct</code> Kommandos erkannt werden
** Über <code>genericDeviceType</code> light
** Über homebridgeMapping: Wenn <code>helligkeit</code> das Reading für die aktuelle Helligkeit enthält und die Helligkeit mit <code>set <device> prozent xxx</code> gesetzt wird, sieht das homebridgeMapping wie folgt aus: homebridgeMapping Brightness=helligkeit::prozent,minValue=0,maxValue=<maximalwert>
** Kommandos:
*** Alexa, mache <name> heller/dunkler
*** Alexa, Licht heller/dunkler
* Geräte, deren Farbe sich ändern lässt
** ...

* Geräte, deren Farbtemperatur sich ändern lässt
** ...

* Geräte, bei denen sich eine Lautstärke einstellen lässt
** ...

* Geräte, bei denen sich ein prozentualer Wert einstellen lässt
** Automatisch: wenn <code>dim</code> oder <code>pct</code> Kommandos erkannt werden
** ...

* elektrische Türschlösser
** <code>genericDeviceType</code>: lock
** homebridgeMapping mit LockCurrentState und LockTargetState

* Thermostate
** Über <code>genericDeviceType</code> thermostate
** ...

* structure Devices aus FHEM (ab alexa-fhem version 0.5.7)
** können mit <code>genericDeviceType</code> scene als Szene eingebunden werden
** über <code>alexaRoom</code> kann der name um einen Ort ergänzt werden
** Szenen aus einer structure lassen sich ein- und ausschalten
** Wichtig:
*** Ein Skill darf nur 12 Szenen automatisch erkennen und einbinden.

* LightScene Devices aus FHEM (ab alexa-fhem version 0.5.8)
** können mit <code>genericDeviceType</code> scene als Szenen eingebunden werden
** über <code>alexaRoom</code> kann der name um einen Ort ergänzt werden
** Szenen aus einer LightScene lassen sich nur einschalten
** Wichtig:
*** Ein Skill darf nur 12 Szenen automatisch erkennen und einbinden.

* Geräte, deren Kanal sich umschalten lässt (ab alexa-fhem version 0.5.13)
** Über <code>genericDeviceType</code> media
** homebridgeMapping ChannelController:reading=<reading>,cmd=<cmd>
** Erlaubte Werte siehe hier: https://developer.amazon.com/de/docs/device-apis/alexa-channelcontroller.html#changechannel
** ...

* Geräte, deren Playback status sich schalten lässt (ab alexa-fhem version 0.5.13)
** Über <code>genericDeviceType</code> media
** homebridgeMapping PlaybackController:playback,values=Play;Pause;Stop;Previous;Next
** Erlaubte Werte siehe hier: https://developer.amazon.com/de/docs/device-apis/alexa-playbackcontroller.html#discovery
** ...

* Geräte, deren Eingang sich umschalten lässt (ab alexa-fhem version 0.5.13)
** Über <code>genericDeviceType</code> media
** homebridgeMapping InputController:reading=<reading>,cmd=<cmd>,values=HDMI+1;HDMI+2;XBOX
** Erlaubte Werte siehe hier: https://developer.amazon.com/de/docs/device-apis/alexa-property-schemas.html#input
** ...

* Kontaktsensoren (ab alexa-fhem version 0.5.15)
** Über <code>genericDeviceType</code> contact
** homebridgeMapping ContactSensorState:reading=<reading> oder CurrentDoorState:reading=<reading>
** Die Anzeige in der Alexa-App funktioniert sofort, die Abfrage per Sprache erst ab Version 0.5.27.

* Geräte, deren Lautstärke sich ändern lässt (ab alexa-fhem version 0.5.24)
** Über <code>genericDeviceType</code> speaker
** Automatisch: es muss ein Reading <code>volume</code> und/oder <code>mute</code> geben
** homebridgeMapping Volume:reading=<reading>,cmd=<cmd> Mute:reading=<reading>,cmd=<cmd>
** ...

* Geräte, die sich ein- (und optional) ausschalten lassen als Szene (ab alexa-fhem version 0.5.26)
** Über <code>genericDeviceType</code> scene
** Automatisch: Müssen <code>set on</code> und <code>set off</code> Kommandos haben
** homebridgeMapping On:reading=<reading>,cmdOn=<cmd>[,cmdOff=<cmd>]
** Hinweis: Fehlende Kommandos lassen sich mit cmdalias erzeugen
** Wichtig:
*** Ein Skill darf nur 12 Szenen automatisch erkennen und einbinden.
* Rollläden. Lange ein Problemthema, das nur mit "Schalte auf 0%, schalte auf 100% lief". Wichtig: "alexa-fhem" ab Version 0.5.39 einsetzen. GenericDevice-Type auf "blind" setzen. Nach Restart von alexa-fhem und neuer Gerätesuche sollte folgendes funktionieren:
** "..., öffne <Name> ganz"
** "..., schließe <Name> komplett"
** "hoch" und "runter" (ohne "ganz" oder "komplett") schalten jeweils nur einen bestimmten Prozentsatz hoch oder runter. Dieser kann mit <code>attr <name> homebridgeMapping TargetPosition:minStep=<wert></code>geändert werden. Aber Achtung: In diesem Intervall kann dann auch nur noch ein absoluter Prozentwert per Sprache oder Slider eingestellt werden! Bei z.B. 25% würden 13% zu 25% aufgerundet, 12% zu 0% abgerundet werden.
* Kontaktsensoren (ab alexa-fhem version 0.5.47)
** Automatisch wenn ein Reading <code>motion</code> vorhanden ist oder es sich um einen Zigbee bewgungsmelder an einer HUE oder deCONZ Bridge handelt
** Über <code>genericDeviceType</code> MotionSensor
** homebridgeMapping MotionDetected:reading=<reading>,values=<wert für bewgung>:1;<wert für keine bewegung>:0

* Alarmmelder (noch nicht in Deutschland):
** genericDeviceType Security
** homebridgeMapping Alarm=<reading>[,type=[fireAlarm|waterAlarm|burglaryAlarm|carbonMonoxideAlarm]]
** wenn der type nicht angegeben wird ist fireAlarm der default
** automatisch werden 0, ok und alles was mit no anfängt als OK erkannt. alles andere gilt als ALARM.

Es werden noch einige andere häufig verwendete Geräte (Homematic, hue,...) automatisch erkannt.

to be continued ...

In der [https://developer.amazon.com/docs/device-apis/list-of-interfaces.html List of Capability Interfaces] bei Amazon kann man sehen, welche Möglichkeiten das Smart Home Skill API aktuell in einzelnen Ländern bietet. Leider ohne die jeweiligen landessprachlichen Kommandos.

=== Aktiv Routinen starten ===
Routinen (eine Funktionalität, die rein - genauso wie "Räume" - bei Amazon liegt und nicht von FHEM Connector beeinflusst wird) waren lange die ewige Antwort auf die Frage: "Meine Frau möchte aber '''Öffne Rollläden''<nowiki/>' sagen": In der Alexa-App gibt es im Menü den Punkt "Routinen", und hier lässt sich eine gewisse Anzahl von Aktionen (unter optionalen Bedingungen) an ein Sprachkommando knüpfen.

Neu: Routinen können inzwischen auch von Skills getriggert werden, und seit Version 0.5.47 (Februar 2020) auch von FHEM Connector. Das braucht niemand, um die Rollläden hochzufahren, denn das kann FHEM ja selber, aber um z.B. eine Ansage auf einem Alexa-Gerät zu triggern. Dafür gibt es auch das FHEM-Modul "echodevice", aber es erfordert ein paar Klimmzüge. Mit dem aktiven Triggern von Routinen kann FHEM auslösen, dass Alexa ungefragt (!) Dinge wie

''"Die Temperatur in der Tiefkühltruhe hat -16 Grad überschritten"''

in den Raum sagt. Also eine Alternative bzw. Ergänzung zu Alarmen / Erinnerungen per Telegram o.ä.

'''Vorgeschichte''':

Die Smarthome-Skill-API von Amazon sah schon lange das "proactiveReporting" vor: Also z.B. die gemessene Temperatur nicht erst auf Anfrage hin zu übermitteln, sondern laufend aktiv zu pushen. Aber warum Daten an Amazon senden, wenn es dafür keinen Mehrwert gibt? Beim Öffnen z.B. des Thermostaten in der Alexa-App kommen ohnehin laufend Statusabfragen. Warum also einen Datenpool bei Amazon über die Haustemperatur aufbauen und Änderungen pushen, wenn es keinen Mehrwert dafür gibt?

Inzwischen lassen sich (reale oder vermeintliche) Änderungen von ''Bewegungssensoren'' und ''Fensterkontakten'' als Startbedingung an Alexa-Routinen koppeln. Man kann in der Alexa-App (ggf. fiktive) Öffnen eines Fensterkontaktes an das Aufsagen eines freien Textes durch die Hausbutlerin knüpfen.

'''Umsetzung''':
* Jedes Alexa-Device, dessen Status aktiv zu Amazon gepusht werden soll, im Attribut "alexaProactiveEvents" mit einer "1" versehen. Per Default wird ''kein'' Gerät laufend aktiv zu Amazon gepusht!
* das geänderte Device einmal zu Amazon pushen "set <alexa> add <device>" (oder 'Alexa, suche neue Geräte' murmeln)
* Das Gerät sollte jetzt beim Anlegen einer neuen Routine ("Neue Routine", "Wenn Folgendes passiert", "Smart Home") als möglicher Triggerpunkt erscheinen.

==== Dummygeräte: ====
Ein Dummydevice sollte einen Kontaktschalter oder Bewegungssensor simulieren, um dann in FHEM eine beliebige Bedingung als Trigger zu definieren, und eine freie Ansage in Alexa als Routine zu definieren. Hier ein Beispiel:

<syntaxhighlight lang="bash" style="width:90%;">
define voicetrigger1 dummy
attr voicetrigger1 alexaName Trigger 1
attr voicetrigger1 alexaProactiveEvents 1
attr voicetrigger1 genericDeviceType contact
attr voicetrigger1 homebridgeMapping ContactSensorState=state,values=closed:CONTACT_DETECTED;;open:CONTACT_NOT_DETECTED
attr voicetrigger1 readingList 0:closed 1:open
attr voicetrigger1 setList closed open

set alexa add voicetrigger1
set alexa restart
</syntaxhighlight>

'''Fehlersuche:'''

Der Push setzt ein intaktes Push-Token voraus. Sollte im Alexa-Logfile Folgendes erscheinen:

<code>failed to refresh token: invalid_grant: 'The request has an invalid grant parameter : refresh_token'</code>

so ist das Push-Token nicht aktuell. Weil die Auswirkung lange nur war, dass Geräteänderungen nicht aktiv an Amazon gemeldet wurden, gibt es noch keine umfassende Analyse des Problems. Es lässt sich lösen, indem eine oder beide folgenden Aktionen ausgeführt werden:
* Löschen des ".eventToken" im Alexa-Device über "deletereading"
* "FHEM-Connector"-Skill auf "alexa.amazon.de" einmal deaktivieren und dann neu verbinden

== Mögliche Probleme und Lösungen ==

Es kann vorkommen, dass Geräte zwar korrekt erkannt werden, aber das durch Alexa erkannte Kommando nicht richtig umgesetzt wird (Beispiel - mittlerweile behoben: {{Link2Forum|Topic=96766}}). Neben dem FHEM-Log gibt es noch das Logfile, welches von alexa-fhem angelegt wird.

=== Fehlersuche über die FHEM-Oberfläche ===

* alexa-fhem Logfile anschauen (Detail-Ansicht des <alexa>-Device aufrufen, klick auf '''Logfile''' oben)
* alexa-fhem im Debug-Modus aufrufen:
** -D zum alexaFHEM-params attribut hinzufügen
** Alexa-Befehl auslösen
** -D aus dem alexaFHEM-params attribut entfernen
* Die notwendigen Informationen finden sich in dem alexa-Logfile (siehe oben)

=== Fehlersuche über Kommandozeile (lies: Shell) + FHEM-Oberfläche ===

:* set <alexa> stop (FHEM-Oberfläche)
:* Auf der Kommandozeile <code>alexa-fhem -D -c /opt/fhem/alexa-fhem.cfg > debug.log</code> starten (dadurch wird die Datei debug.log erzeugt im aktuellen Verzeichnis)
:* Alexa-Befehl auslösen
:* alexa-fhem auf der Kommandozeile wieder stoppen (CTRL-C)
:* set <alexa> start (FHEM-Oberfläche)

Die Datei debug.log sollte Hinweise enthalten, wie das Problem zu lösen ist oder Dich zumindest in die richtige Richtung schieben.

Im Beispiel aus dem Forum fand sich in dem Logfile der Hinweis darauf, dass das Device mit falschen min/max-Werten unterwegs war.

=== Registrierungskey vergessen, Registrierung zurücksetzen ===

Auf der Kommandoshell:

<syntaxhighlight lang="bash" style="width:90%;">
pi@raspberrypi:~# sudo -u fhem ssh -p 58824 fhem-va.fhem.de status
Registered.
Registered on 2019-01-13T15:38:13Z.
</syntaxhighlight>

heisst, das der Vereinsserver eigentlich alles hat, was er will. Es wird kein neuer Schlüssel generiert.
Wenn Du die Situation zurücksetzen möchtest, wäre die hässliche Methode, Deinen SSH-Key zu löschen. Eleganter ist, die Registrierung auf Vereinsseite zu löschen:

<syntaxhighlight lang="bash" style="width:90%;">
pi@raspberrypi:~# sudo -u fhem ssh -p 58824 fhem-va.fhem.de unregister
Your registration has been removed
</syntaxhighlight>

löscht Deinen Schlüssel mitsamt allen dort gespeicherten Daten auf Vereinsseite. Bei Restart von alexa-fhem in FHEM-WEB wird jetzt ein neuer Registrierungskey angefordert.

== Sicherheitskonzept und Secrets ==

Um diesen Abschnitt zu verstehen, solltest Du den Abschnitt "Arbeitsweise" im Kopf haben. Einerseits ist Dir vermutlich einleuchtend, dass ein Server, der per SSH rückwärts nur ausgewählte Kommandos in den Tunnel, den Du aufgebaut hast, leitet, "irgendwie sicherer" ist. Andererseits möchte man nicht blind vertrauen.

=== SSH ===
==== SSH - macht das nichts Gefährliches? ====
SSH ist ein Veteran des Internet und entstand, um sich sicher (verschlüsselt) und schnell auf Servern einzuloggen. Schon früh wurde dabei der sogenannte "Reverse-Tunnel" implementiert: Also der vom Client (Deinem Rechner) geäußerte Wunsch: "Bitte leite mir Requests, die bei Dir, Server, auf Port xy eingehen, an meinen lokalen Port yz weiter.". Dieses Verfahren implementiert der Reverseproxy, wobei tatsächlich auf dem Server für Dich kein echter Port geöffnet wird.

Wie Dir ggf. sicher der Unix-Guru Deines Vertrauens bestätigen wird: Die Kombination
<syntaxhighlight lang="bash" style="width:50%;">
ssh -R 1234:localhost:<zufälliger port> zielserver
</syntaxhighlight>
erlaubt keine Ausführung von Shell-Kommandos auf Deinem Server, sondern einzig, dass vom SSH-Programm Verbindungen zu einem lokalen Port auf Deinem Server auf dem alexa-fhem lauscht aufgebaut werden. Du kannst also z.B. mit einem
<syntaxhighlight lang="bash" style="width:50%;">
sudo /usr/sbin/tcpdump -X -s 0 -i lo port <zufälliger port>
</syntaxhighlight>
vollständig überwachen (oder ggf. permanent aufzeichen), was auf Deinem Server von außen gesteuert passiert.

==== Wie wird bei SSH verschlüsselt? ====
Im Prinzip wie im Web auf SSL-Seiten, teils mit den gleichen Verschlüsselungsverfahren. Allerdings arbeitet SSH eher wie das im Web recht seltene Verfahren: Bei jeder Verbindung übermitteln sowohl Server wie auch Client den öffentlichen Teil ihres Schlüssels. Anders als im Web wird der Schlüssel aber nicht von einer öffentlichen Zertifizierungsstelle wie "LetsEncrypt" unterschrieben. Stattdessen entscheiden Server wie Client beim ersten Verbindungsaufbau typischerweise per manueller Frage: "Willst Du jetzt und künftig diesem Schlüssel vertrauen?" Bei der Installation wird diese Frage für Deine Seite bejaht, und fortan wird der öffentliche Schlüssel des FHEM-Servers auf Deinem Rechner gespeichert. Ab da bist Du z.B. davor sicher, dass jemand den DNS-Eintrag verbiegt oder sich in den Datenfluss Deines Providers einhängt: Ein geänderter Serverschlüssel würde bemerkt werden.
 
Soweit klar? Aus Deinem öffentlichen Schlüssel wiederum leitet der Server her: "Das ist definitiv wieder derjenige, der sich damals "registriert" hat". Und an dieser Stelle kann ich auch den ersten Teil des 3-teiligen Registrierungskeys erläutern: Die typischerweise 6-stellige Hex-Zahl am Anfang ist der Java-Hashcode Deines öffentlichen Schlüssel. Sie ist damit sozusagen Deine aus Deinem öffentlichen Schlüssel abgeleitete Benutzer-ID.

=== Die Rolle der Secrets ===
Wenn jetzt klar ist, dass die Verbindung zum Vereinsserver sicher und vertauschungsfrei funktioniert, bleiben noch 2 Probleme zu lösen:
1) Im Web bei der Skill-Aktivierung musst Du beweisen, dass Du der Mensch am Browser bist, dem der SSH-Tunnel von IP xy mit dem öffentlichen Schlüssel X gehört. Bei der automatischen Registrierung werden lokal auf Deinem Rechner zwei 64-Bit-Secrets generiert:
* Das Anmelde-Secret
* Das Bearer-Token
Beim Anmelden des SSH-Keys auf dem öffentlichen Server wird nun der Hashwert des ersten Secrets übertragen und dort in Verbindung mit Deinem öffentlichen Schlüssel gespeichert. Ein Hashwert bedeutet, dass (sofern das Verfahren, hier SHA256, funktioniert), niemand aus dem Hash das Secret zurückrechnen kann. Ein Datenbankklau auf dem Server gefährdet also nicht die Sicherheit Deines Passwortes.

Wenn Du nun beim Skill-Aktivieren den Registrierungskey eingibst, dann "sieht" der Server zum ersten Mal Dein ausgewürfeltes Secret, vergleicht es mit dem Hashwert und wird es anschließend wieder umgehend vergessen. Anhand des Hashwertes kann der Server aber entscheiden, dass Du der legitime Nutzer zum öffentlichen Schlüssel XY bist.

2) Das zweite Problem ist: Wie soll Amazon "beweisen", dass sie der legitime Aufrufer sind? Amazon erhält binnen wenigen Sekunden nach dem Klick auf "Activate Skill" den dritten Teil des Registrierungskeys als sogenanntes Bearer-Token. Zwar läuft er durch den Registrierungsserver, er wird dort, auf dem Registrierungs/Vereinsserver aber nicht gespeichert. Das Bearer-Token wird von Amazon bei allen Requests zu Deinem Server mitgesendet. Da es am Anfang zusätzlich Deine "User-ID" enthält, weiß der Vereinsserver, zu welchem SSH-Tunnel der Request zu senden ist. Aber lokal auf Deinem Rechner wird ausgewertet, ob das Token "stimmt".

== alexa-fhem Updaten bzw. "Upgraden" ==

'''Updaten einer "Connector" Installation:'''
* alexa-fhem über FHEM anhalten (Name des Alexa-Device: alexa):
:<syntaxhighlight lang="perl" style="width:50%;">set alexa stop</syntaxhighlight>

*Auf der Konsole wie anfangs bei der Installation:
:<syntaxhighlight lang="bash" style="width:50%;">sudo npm update -g alexa-fhem</syntaxhighlight>

:Manchmal hat npm Probleme mit einem Update. Dann einfach die aktuelle Version noch mal drüber Installieren:

:<syntaxhighlight lang="bash" style="width:50%;">sudo npm install -g alexa-fhem</syntaxhighlight>

*alexa-fhem über FHEM wieder starten:
:<syntaxhighlight lang="perl" style="width:50%;">set alexa start</syntaxhighlight>

'''"Upgraden von einer "Nicht-Connector" Installation (z.B. manuelle Installation per pm-Download):'''
* Daten der aktuellen Installation sichern (v.a. config.json / man weiß ja nie)
* Autostart der aktuellen alexa-fhem Installation deaktivieren:
** Bei initd: Service deaktivieren mittels: <code>sudo update-rc.d -f alexa remove</code> Vorher mittels stoppen: <code>sudo service alexa stop</code> Startscript unter /etc/init.d/ löschen.
** Bei systemd: Service deaktivieren mittels: <code>sudo systemctl disable alexa</code> Vorher mittels stoppen: <code>sudo systemctl alexa stop</code> Startscript unter /etc/systemd/system/ löschen.
* ALLE vorhandenen alexa-fhem Daten LÖSCHEN! Bleiben Dinge zurück und wird dann laut Connector installiert kann es zu Problemen kommen!
* (reboot)
* Installation von alexa-fhem laut Anleitung (Beginn dieses Wiki)
* Falls eigene Dinge von früher genutzt werden wollen/sollen (z.B. Custom Skill), dann die entsprechenden Einträge aus der gesicherten config.json in die neu angelegte alexa-fhem.cfg (zu finden unter "Edit files") übernehmen.
* Werden keine eigenen Dinge verwendet, dann kann der Port (Standard: 3000) geschlossen werden und auch die Daten unter Amazon-Developer können gelöscht werden.

== Bug- und Wunschliste ==
* Ist beim Start keine Internetverbindung vorhanden, erfolgt kein Retry -- alexa-fhem muss restartet werden (ssh_autoconfig wertet keine temporären Fehler aus)

==Weitergehende Informationen==
*[[Alexa und Mappings]]
*[[Alexa Tipps und Kniffe]]
*[[FHEM Connector for Amazon Alexa]]
[[Kategorie:HOWTOS]]
[[Kategorie:Sprachsteuerung]]

==Hinweise==
<references />

FHEM Connector für Amazon Alexa

2020-06-12T09:08:18Z

MadMax-FHEM: Anmerkung bzgl. nodejs Version

{{Baustelle}}
'''Alexa FHEMlazy''' war historisch ein Fork des Original [[Alexa-Fhem|alexa-fhem]], der im Januar 2019 mit dem Original zusammengeführt wurde und nun als '''FHEM Connector''' verfügbar ist.

Er ermöglicht innerhalb von Minuten die Verknüpfung von FHEM mit einem Amazon Echo Gerät. Auch Geräte anderer Hersteller mit verbauten Mikrofonen und Alexa-Sprachassistenten-Unterstützung sollten problemlos funktionieren. Für folgende Geräte ist dies bspw. der Fall (Falls Ihr andere/weitere Gerätemodelle bzw. Hersteller in Verwendung habt, bitte hier pflegen):

* SONOS Beam und SONOS One

Gegenüber dem klassischen Ansatz ergeben sich Einschränkungen, so läuft die Software normalerweise unter dem gleichen Benutzer wie FHEM auf dem gleichen Server, und es wird z.Zt. nur der Smarthome-Skill unterstützt (die Variante, bei der die Möglichkeiten der Interaktion von Amazon festgelegt wurden).
Dafür ist weder ein Developer-Account bei Amazon, eigene Lambda- und Skillfunktionen, noch das Öffnen eines eingehenden Ports aus dem Internet nötig.
* Die Software integriert einen Installer, der die Erstkonfiguration und Anmeldung übernimmt
* Die Kommunikation zur Software auf dem heimischen Rechner und dann zu FHEM verläuft über SSH und einen vom FHEM-Verein gehosteten Server
* Funktioniert mit IPv4, IPv6, echtem Dual Stack und DS-Lite
* Als Skill bei Amazon wird der Skill "FHEM Connector" verwendet.

Der Thread im Forum zur Software ist hier: {{Link2Forum|Topic=94817}}.

{{Infobox Modul
|ModPurpose=Einfache Anbindung von FHEM an Amazon Assistent Alexa
|ModType=h
|ModCmdRef=alexa
|ModTechName=39_alexa.pm / alexa-fhem
|ModForumArea=Frontends/Sprachsteuerung
|ModOwner=gvzdus, André/ justme1968 ({{Link2FU|430|Forum}} / [[Benutzer Diskussion:Justme|Wiki]])
}}

==Einführung==

===Arbeitsweise und Datenfluss===
Vorläufig ist alexa-fhem im "FHEM Connector-Modus" ein reiner [https://developer.amazon.com/de/docs/smarthome/understand-the-smart-home-skill-api.html SmartHome-Skill].
SmartHome-Skills erhalten weder die Sprachdaten selber noch das, was Amazon in Textform verstanden hat, sondern vielmehr extrahiert Amazon aus dem verstandenen Text Anweisungen und Abfragen für Geräte, die dann an den Skill übermittelt werden. Charmant ist dabei, dass unmittelbar gefragt werden kann "Alexa, wie ist die Temperatur im Wohnzimmer?", während andere Skills zunächst explizit angesprochen werden müssen ("Alexa, frage FHEM nach der Temperatur im Wohnzimmer"). Außerdem kann der Nutzer mehrere Smarthome-Skills installieren, und die Geräte werden zu einer Gesamtmenge zusammengefasst.

Gehen wir den Datenfluss bei der konkreten Frage "Wie ist die Temperatur im Wohnzimmer?" durch:
* Alexa hat bei der Skillinstallation gelernt, dass "FHEM Connector" bei Dir einen Thermostaten im Raum Wohnzimmer kennt. Dadurch wird bei der Sprachanalyse von "Alexa Voice Service" in der Cloud erkannt, dass eine Abfrage an "FHEM Connector" erfolgversprechend ist.
* Zunächst wird die zentrale "Lambda-Funktion" von "FHEM Connector" aufgerufen. Die Funktion leitet aber im Kern nur den Request unverändert an den vom Verein bereitgestellten Server weiter. Im Request enthalten ist ein Token, das sogenannte "Bearer-Token".
* Der "Vereinsserver" prüft anhand dieses Tokens, ob es überhaupt bekannt ist, und zu welchem Nutzer es gehört. Ist dieser Nutzer verbunden, wird der Request wiederum quasi unverändert an den Nutzer weitergeleitet.
* Diese Weiterleitung passiert über einen sogenannten SSH-Reverse-Tunnel, der von Deiner Seite und der Software auf dem FHEM-Tunnel automatisch aufgebaut wird.
* Auf Deiner Seite läuft die eigentliche Software, und zwar unter nodeJS. nodeJS ist ein Javascript ausführender Miniserver, der lokal auf einem Zufallsport auf Requests "lauscht". In der Original-Version [[Alexa-Fhem|Alexa FHEM]] kommen die Requests aus dem Internet (hoffentlich von der eigenen Lambda-Funktion), hier bei "FHEM Connector" kommen sie ausschließlich aus dem SSH-Tunnel von lokal.
* Die Software validiert nun diesen Request anhand des Bearer-Tokens. Konkret wird dabei das bei der Installation generierte Token, dass bei der Skill-Aktivierung an Amazon übertragen wurde, mit dem lokal gespeicherten Wert verglichen. Stimmt das Token, wird der Befehl verarbeitet, üblicherweise wird hierbei ein Aufruf an die Webschnittstelle von FHEM abgesetzt.
* FHEM führt den Befehl aus

Hört sich langsam und kompliziert an? Kompliziert: Okay. Langsam eher nicht, in etlichen Fällen liegt die Gesamtantwortszeit unter 200 ms.

Soweit ein erster Überblick über die Datenflüsse. Im Abschnitt Sicherheit ist das Konzept der Absicherung deutlich genauer und ausführlicher beschrieben.

==Installation==

Du wirst bei der Installation zuerst auf der Kommandozeile auf Deinem Raspberry (o.ä.) unterwegs sein, anschließend im Webfrontend von FHEM, und zum Schluss auf der Alexa-Konsole im Web.

===node.js installieren===

Ab Jessy liegt NodeJS bereits in einer ausreichend aktuellen Version vor (Stretch und Buster funktionieren ebenfalls). Mit

<syntaxhighlight lang="bash" style="width:50%;">
sudo apt-get install nodejs npm
</syntaxhighlight>

kannst Du es installieren. Mit
<syntaxhighlight lang="bash" style="width:50%;">
node --version
</syntaxhighlight>

erfährst Du die aktuelle Version - wenn hier etwas mit "8" oder höher vorneweg erscheint, ist alles gut.
Ansonsten suche Dir bitte eine Anleitung im Web, wie Du NodeJS auf Deinem System auf einen aktuellen Stand bringen kannst.

'''Anmerkung:''' diese Aussage stimmt wohl für alexa-fhem Stand heute (12.06.2020) nicht mehr, siehe https://forum.fhem.de/index.php/topic,112025.msg1063218.html#msg1063218

=== Alexa-FHEM installieren ===

Nun installieren wir Alexa-fhem aus dem offiziellen Repository:

<syntaxhighlight lang="bash" style="width:50%;">
sudo npm install -g alexa-fhem
</syntaxhighlight>

Der Vorgang benötigt etwas Zeit.

=== Alexa-FHEM aktivieren ===

Wechsele jetzt in FHEM-Web!

Wichtig ist, dass das Alexa-Modul in der Version ab Januar 2019 vorliegt. Dafür bitte einmal FHEM aktualisieren:
Speichern der Config nicht vergessen, und

<syntaxhighlight lang="bash" style="width:50%;">
update
shutdown restart
</syntaxhighlight>

Alles, was jetzt noch nötig ist, ist das Anlegen eines Alexa-Devices. Gib dafür in der FHEM-Web-Kommandozeile

<syntaxhighlight lang="bash" style="width:50%;">
define alexa alexa
</syntaxhighlight>

an. Nun läuft, während Du bereits das neu angelegte Alexa-Devices siehst, ein komplexer Prozess im Hintergrund:

* Falls noch kein SSH-Key für den Benutzer, unter dem FHEM läuft, existiert, wird einer generiert
* Es wird ein Secret-Key im Prozess generiert, dass den Server nicht verlässt, und der Skillanmeldung dient.
* Du wirst auf dem Server "va-fhem.fhem.de" des FHEM-Vereins mit dem SSH-Key angemeldet, und der Hash-Wert Deines Secret-Key dort abgelegt.

Und wenn Du diese Sätze gelesen hast, sollte inzwischen sich das Alexa-Device in FHEM-Web aktualisiert haben, und
ungefähr so aussehen:

[[Datei:Alexa-Device-2.png|800px]]

Neben dem Status für alexa-fhem und der Proxyverbindung ist wichtig, dass diese beiden Zeilen beim Reload aufgetaucht sind:

<syntaxhighlight lang="bash" style="width:90%;">
alexaFHEM.bearerToken crypt:...
alexaFHEM.skillRegKey crypt:...
</syntaxhighlight>

Ja, und diesen Schlüssel benötigst Du wirklich! Also am besten schon einmal mit

<syntaxhighlight lang="bash" style="width:90%;">
get <alexa> proxyKey
</syntaxhighlight>

in Klartext anzeigen lassen und in ein Editor-Fenster dauerhaft wegsichern.

Jetzt solltest Du Dein Alexa-Device nicht mehr löschen, denn das im Reading angezeigte "bearerToken" zu löschen bedeutet, dass die Software die Zugriffe von nicht mehr überprüfen kann und keine Kommandos mehr funktionieren. In diesem Fall hilft nur die Neuinstallation des Skills.

==== Fehler bei der Aktivierung ====

Während kompliziertere Fehlerfälle im Abschnitt "Mögliche Probleme und Lösungen" behandelt werden, hier häufige Fälle, warum die kryptischen Zeilen nicht auftauchen:

* Zuerst bitte einfach einmal die Seite neu laden.

===== 401: Authorization Required =====

Wenn Du FHEM-Web mit einem User/Passwort-Schutz versehen hast, wirst du folgende Fehlermeldung sehen:

<syntaxhighlight lang="bash" style="width:90%;">
alexaFHEM stopped; failed to connect to fhem: 401: Authorization Required
</syntaxhighlight>

In der Regel musst du die Angaben User/Passwort noch einmal explizit setzen. Im Attribute-Abschnitt "alexaFHEM-auth" auswählen, User/Passwort mit ":" getrennt angeben und "attr" anklicken. alexa-fhem wird automatisch neu gestartet. Hier das Ganze in der Text-Variante:

<syntaxhighlight lang="bash" style="width:90%;">
attr alexa alexaFHEM-auth user:pass
</syntaxhighlight>

===== Permission denied =====

Wenn du folgende Fehlermeldungen im Alexa Logfile siehst, wurde das Verzeichnis "/opt/fhem/.ssh/" von dir bei der Arbeit mit "root" oder "sudo" mit den falschen Berechtigungen versehen:

<syntaxhighlight lang="bash" style="width:90%;">
[2019-7-25 11:59:12] sshautoconf: aborted with ssh-keygen returned error - key_save_private: Permission denied
[2019-7-25 11:59:12] *** SSH: proxy configuration failed: ssh-keygen returned error - key_save_private: Permission denied
</syntaxhighlight>

Prüfen kannst du die Berechtigungen mit folgendem Befehl auf der Shell-Konsole:

<syntaxhighlight lang="bash" style="width:90%;">
ls -l /opt/fhem/.ssh
</syntaxhighlight>

Du solltest dann folgende Ausgabe erhalten:

<syntaxhighlight lang="bash" style="width:90%;">
insgesamt 12
-rw------- 1 fhem dialout 1675 Jul 12 13:10 id_rsa
-rw-r--r-- 1 fhem dialout 391 Jul 12 13:10 id_rsa.pub
-rw-r--r-- 1 fhem dialout 884 Jul 12 13:10 known_hosts
</syntaxhighlight>

Steht in der Ausgabe nicht "fhem dialout" (dein fhem User), sondern bspw. "root root", dann bspw. mit folgendem Befehl an deinen fhem User anpassen:

<syntaxhighlight lang="bash" style="width:90%;">
chown fhem:dialout /opt/fhem/.ssh
</syntaxhighlight>

Mit dem ersten Befehl "ls -l ..." kannst du dann nochmal prüfen, ob die Berechtigungen korrekt übernommen wurden.

===== weitere Prüfungen =====

Hast Du noch die Shell-Konsole offen? Dann prüfe bitte noch einmal auf der Konsole, ob nun zwei Prozesse laufen:

<syntaxhighlight lang="bash" style="width:50%;">
ps -ef | egrep '(alexa|ssh)'
</syntaxhighlight>

sollte Dir idealerweise so etwas anzeigen:
<syntaxhighlight lang="bash" style="width:90%;">
fhem 31322 1 99 13:56 ? 00:00:03 alexa
fhem 31332 31322 8 13:56 ? 00:00:00 /usr/bin/ssh -R 1234:127.0.0.1:<zufälliger port> -oServerAliveInterval=90 -p 58824 fhem-va.fhem.de
</syntaxhighlight>

"alexa" ist dabei der Node-JS-Prozess, der ssh-Prozess ist die aufgebaute Verbindung zum Vereinsserver.

Wenn Du diese Prozesse '''nicht''' siehst oder das Alexa-Device keinen Registrierungskey anzeigt, dann ist leider der Start nicht glatt verlaufen.

Im Logfile (über den link <code>Logfile</code> in der Detail-Ansicht über <code>set</code>, oder über den Namen bei ''currentlogfile'' in den Internals) findest Du idealerweise selber Hinweise, wo es hakt, oder kannst im Forum nachfragen.

=== Geräte im FHEM-Webfrontend zuweisen ===
Um das Aha-Erlebnis zu vergrößern, ist jetzt ein guter Zeitpunkt, 1 oder besser mind. 2 Geräte für den Alexa-Dienst zuzuweisen. Von Haus aus wird keines Deiner FHEM-Geräte automatisch Alexa zugewiesen!

Wähle die Geräte aus, rufe sie auf und setze das Attribut "alexaName". Hierbei in Kürze nur der Hinweis:
* Keine Angst vor Leerzeichen und Umlauten, funktioniert.
* Große Angst vor Rechtschreibfehlern (Terrasse, Rollladen) oder komplizierten Wörtern "handgebastelte Martinslaterne im Kinderzimmer Iphigenie-Chantal".
* Mehrere Namen für dasselbe Gerät/Device in fhem werden unterstützt. Mehrere Namen werden durch Strichpunkt getrennt<ref>Feature nicht dokumentiert {{Link2Forum|Topic=74041|LinkText=Forumsthread}}</ref>.
* Das Attribut "alexaRoom" ist NUR FÜR DEN CUSTOM SKILL relevant. Ausnahme: structure und LightScene Devices, siehe: [[FHEM_Connector_f%C3%BCr_Amazon_Alexa#Was_geht_alles_.3F]].

Lade die Geräte neu in die Software, indem Du <code>set <alexa> restart</code> ausführst!
[[Datei:HowToSet alexaName.png|alternativtext=How to set alexaName|ohne|mini|Wie setzt man das Attribut alexaName]]

'''Anmerkungen (weil oft gestellte Fragen im Forum) bzgl. Erkennung von Geräten:'''

* Wichtig ist, dass die Filtereinstellung in der alexa-fhem.cfg (zu finden unter "Edit Files") passt.
Das, was dort eingetragen ist (Standard: alexaName=..* / also es ist ein alexaName vergeben) auch an den entsprechenden Devices in fhem vorhanden ist.
Stimmt das nicht überein, kann alexa-fhem keine Devices von fhem abfragen/finden.
Ob der Filter entsprechend funktioniert kann man wie folgt testen: ''list Filtereinstellung'' beispiel mit Standardfilter: ''list alexaName=..*''

* Hat alexa-fhem per Filter Devices aus fhem "gefunden", geht es weiter mit der "Erkennung". Also um welches Device (Typ und "Fähigkeiten") handelt es sich. Dazu gilt folgendes:
** sind entsprechende Readings beim Device vorhanden (z.B. temperature, state mit on/off, ...) erkennt das alexa-fhem automatisch. Die Liste der automatisch erkannten Readings wächst ständig. Daher erst mal schauen ob das Device bereits entsprechend erkannt (typisiert) wurde. Das kann durch prüfen des alexa-fhem-Logs geschehen (NICHT fhem-log!).
** sind entsprechende "set-Befehle" erkennbar (oft auch durch Readings). Also ist beispielsweise (wie beim Dummy nötig) ein ''setList'' mit entsprechenden Einträgen vorhanden oder entsprechende Readings, z.B. desired-temp zum Stellen der Temperatur etc.
** wird das Device nicht richtig oder "unvollständig" erkannt helfen folgende Attribute:
*** genericDeviceType: hiermit kann alexa-fhem in die gewünschte Richtung "geschubbst" werden. Anmerkung: man kann nicht alles erzwingen, Readings bzw. set-Befehle müssen passen (oder per homebridgeMapping passend gemacht werden). Wenn ein genericDeviceType nicht per "Drop-Down" erscheint, dann kann er auch (wenn bekannt) einfach per WEB-cmd eingegeben werden: ''attr Devicename genericDeviceType media''
*** homebridgeMapping: hierdurch kann alexa-fhem bei der Erkennung von Zuständen und möglichen Einstellungen (also WAS kann das Device) unterstützt werden. Mittels homebridgeMapping können vorhandene Readings (Zustände) auf für alexa-fhem bekannte Zustände gemappt werden. Ebenso können damit Standard-fhem-Kommandos von alexa-fhem auf Device-spezifische gemappt werden. Beispiel: on/off auf Ein/Aus (falls das Device statt on/off eben ein Ein/Aus erwartet). Zum Beispiel: <syntaxhighlight lang="bash" style="width:50%;">
attr <thermostat> homebridgeMapping TargetTemperature=target::target,minValue=18,maxValue=25,minStep=0.5 CurrentTemperature=myTemp:temperature
</syntaxhighlight> [https://github.com/justme-1968/homebridge-fhem/blob/master/README.md weitere Beispiele]

 '''Mehrere Namen für dasselbe Gerät/Device in fhem sind möglich.''' 
Die Namen werden durch Strichpunkt getrennt. 
Beispiel: 
<code>attr dmLampe alexaName Lichtkuppel;Lichtkugel</code>

'''Anmerkung bzgl. genericDeviceType und homebridgeMapping:''' 
* diese Attribute werden von verschiedenen "Sprachsteuerungsmodulen" in fhem verwendet (homebridge [dort wurde es "erfunden"], alexa-fhem, gassistant, ...). Daher ist nicht jedes Mapping für alle "Dienste" verwendbar. Ausprobieren schadet aber nicht.
* ebenso kann man mit diesen Attributen (homebridgeMapping wird gerne so "missbraucht") nichts erzwingen, was seitens Amazon/Alexa nicht unterstützt bzw. verstanden wird! D.h. zunächst ist zu prüfen, ob ein bestimmter (gewünschter) Sprachbefehl seitens Amazon/Alexa unterstützt wird! Aktuelles Beispiel (Stand Jan 2020): "Alexa, fahre den Rollo hoch/runter". Da ist Amazon/Alexa gerade dabei etwas zu tun. Bislang wird das nicht unterstützt, also ist das auch mit einem entsprechenden homebridgeMapping nicht zu erzwingen! Was unterstützt wird kann man bei Amazon nachlesen: [https://developer.amazon.com/es-ES/docs/alexa/device-apis/list-of-interfaces.html]

== Finale: Skill verknüpfen ==
Suche im WebFrontend oder der Alexa-App den Skill "FHEM Connector". Für nicht-Mac/iOS Anwerder empfiehlt das WebFrontend (https://alexa.amazon.de) statt die App, damit Du den Anmeldeschlüssel auch bequem kopieren kannst.

Wenn du noch nicht bei Amazon angemeldet bist, erwartet Amazon zunächst, dass Du Dich normal bei Amazon anmeldest.

Sobald Du "FHEM Connector" aktivierst, öffnet sich ein Browser-Tab mit folgender Maske: 
[[Datei:FHEMlazy_login.png|240px]]

Hier kopierst Du Deinen Anmeldeschlüssel (im Klartext!) hinein und klickst auf Check. Als glücklicher Mensch ist auf der folgenden Statusseite alles grün: 
[[Datei:FHEMlazy_check.png|240px]]

Im Einzelnen wird hier geprüft, ob Du per SSH verbunden bist (und auch Deine IP zur Sicherheit angezeigt), ob der Reverse-Tunnel steht, ob nodeJS erreichbar ist und wie viele Geräte Alexa gleich finden sollte (in meinem Fall 22).

Sollte etwas nicht grün sein und Du eine Idee zum Fixen haben, kannst Du mit "Retry" neue Versuche auslösen.

Ist alles okay, klicke rechts den Button "Activate Skill". Du springst damit wieder zurück zu Amazon, die Dir hoffentlich zur erfolgreichen Verknüpfung gratulieren.

Amazon möchte nun unmittelbar die Gerätesuche starten, und unter SmartHome-Geräte sollten diese nun auftauchen.

== Was geht alles ? ==

* Geräte, die sich ein- und ausschalten lassen:
** Automatisch: Müssen <code>set on</code> und <code>set off</code> Kommandos haben
** dummys müssen <code>setList</code> mit on und off haben
** Über <code>genericDeviceType</code> switch bzw. light kann bestimmt werden ob es in alexa als Schalter oder Licht behandelt wird.
** Wenn die Set-Kommandos im FHEM Device anders benannt sind: homebridgeMapping On:cmdOn=<ein>,cmdOff=<aus> setzen
** Kommandos:
***Alexa, schalte <name> ein/aus
***Alexa, Licht an/aus
***Alexa, schalte <gruppe> ein/aus
* Geräte, die eine Temperatur messen
** Automatisch: Es muss ein Reading <code>temperature</code> geben
** Über <code>genericDeviceType</code> thermometer
** Sonst: homebridgeMapping CurrentTemperature:reading=<reading>

* Geräte, deren Helligkeit sich ändern lässt
** Automatisch: wenn <code>dim</code> oder <code>pct</code> Kommandos erkannt werden
** Über <code>genericDeviceType</code> light
** Über homebridgeMapping: Wenn <code>helligkeit</code> das Reading für die aktuelle Helligkeit enthält und die Helligkeit mit <code>set <device> prozent xxx</code> gesetzt wird, sieht das homebridgeMapping wie folgt aus: homebridgeMapping Brightness=helligkeit::prozent,minValue=0,maxValue=<maximalwert>
** Kommandos:
*** Alexa, mache <name> heller/dunkler
*** Alexa, Licht heller/dunkler
* Geräte, deren Farbe sich ändern lässt
** ...

* Geräte, deren Farbtemperatur sich ändern lässt
** ...

* Geräte, bei denen sich eine Lautstärke einstellen lässt
** ...

* Geräte, bei denen sich ein prozentualer Wert einstellen lässt
** Automatisch: wenn <code>dim</code> oder <code>pct</code> Kommandos erkannt werden
** ...

* elektrische Türschlösser
** <code>genericDeviceType</code>: lock
** homebridgeMapping mit LockCurrentState und LockTargetState

* Thermostate
** Über <code>genericDeviceType</code> thermostate
** ...

* structure Devices aus FHEM (ab alexa-fhem version 0.5.7)
** können mit <code>genericDeviceType</code> scene als Szene eingebunden werden
** über <code>alexaRoom</code> kann der name um einen Ort ergänzt werden
** Szenen aus einer structure lassen sich ein- und ausschalten
** Wichtig:
*** Ein Skill darf nur 12 Szenen automatisch erkennen und einbinden.

* LightScene Devices aus FHEM (ab alexa-fhem version 0.5.8)
** können mit <code>genericDeviceType</code> scene als Szenen eingebunden werden
** über <code>alexaRoom</code> kann der name um einen Ort ergänzt werden
** Szenen aus einer LightScene lassen sich nur einschalten
** Wichtig:
*** Ein Skill darf nur 12 Szenen automatisch erkennen und einbinden.

* Geräte, deren Kanal sich umschalten lässt (ab alexa-fhem version 0.5.13)
** Über <code>genericDeviceType</code> media
** homebridgeMapping ChannelController:reading=<reading>,cmd=<cmd>
** Erlaubte Werte siehe hier: https://developer.amazon.com/de/docs/device-apis/alexa-channelcontroller.html#changechannel
** ...

* Geräte, deren Playback status sich schalten lässt (ab alexa-fhem version 0.5.13)
** Über <code>genericDeviceType</code> media
** homebridgeMapping PlaybackController:playback,values=Play;Pause;Stop;Previous;Next
** Erlaubte Werte siehe hier: https://developer.amazon.com/de/docs/device-apis/alexa-playbackcontroller.html#discovery
** ...

* Geräte, deren Eingang sich umschalten lässt (ab alexa-fhem version 0.5.13)
** Über <code>genericDeviceType</code> media
** homebridgeMapping InputController:reading=<reading>,cmd=<cmd>,values=HDMI+1;HDMI+2;XBOX
** Erlaubte Werte siehe hier: https://developer.amazon.com/de/docs/device-apis/alexa-property-schemas.html#input
** ...

* Kontaktsensoren (ab alexa-fhem version 0.5.15)
** Über <code>genericDeviceType</code> contact
** homebridgeMapping ContactSensorState:reading=<reading> oder CurrentDoorState:reading=<reading>
** Die Anzeige in der Alexa-App funktioniert sofort, die Abfrage per Sprache erst ab Version 0.5.27.

* Geräte, deren Lautstärke sich ändern lässt (ab alexa-fhem version 0.5.24)
** Über <code>genericDeviceType</code> speaker
** Automatisch: es muss ein Reading <code>volume</code> und/oder <code>mute</code> geben
** homebridgeMapping Volume:reading=<reading>,cmd=<cmd> Mute:reading=<reading>,cmd=<cmd>
** ...

* Geräte, die sich ein- (und optional) ausschalten lassen als Szene (ab alexa-fhem version 0.5.26)
** Über <code>genericDeviceType</code> scene
** Automatisch: Müssen <code>set on</code> und <code>set off</code> Kommandos haben
** homebridgeMapping On:reading=<reading>,cmdOn=<cmd>[,cmdOff=<cmd>]
** Hinweis: Fehlende Kommandos lassen sich mit cmdalias erzeugen
** Wichtig:
*** Ein Skill darf nur 12 Szenen automatisch erkennen und einbinden.
* Rollläden. Lange ein Problemthema, das nur mit "Schalte auf 0%, schalte auf 100% lief". Wichtig: "alexa-fhem" ab Version 0.5.39 einsetzen. GenericDevice-Type auf "blind" setzen. Nach Restart von alexa-fhem und neuer Gerätesuche sollte folgendes funktionieren:
** "..., öffne <Name> ganz"
** "..., schließe <Name> komplett"
** "hoch" und "runter" (ohne "ganz" oder "komplett") schalten jeweils nur einen bestimmten Prozentsatz hoch oder runter. Dieser kann mit <code>attr <name> homebridgeMapping TargetPosition:minStep=<wert></code>geändert werden. Aber Achtung: In diesem Intervall kann dann auch nur noch ein absoluter Prozentwert per Sprache oder Slider eingestellt werden! Bei z.B. 25% würden 13% zu 25% aufgerundet, 12% zu 0% abgerundet werden.
* Kontaktsensoren (ab alexa-fhem version 0.5.47)
** Automatisch wenn ein Reading <code>motion</code> vorhanden ist oder es sich um einen Zigbee bewgungsmelder an einer HUE oder deCONZ Bridge handelt
** Über <code>genericDeviceType</code> MotionSensor
** homebridgeMapping MotionDetected:reading=<reading>,values=<wert für bewgung>:1;<wert für keine bewegung>:0

* Alarmmelder (noch nicht in Deutschland):
** genericDeviceType Security
** homebridgeMapping Alarm=<reading>[,type=[fireAlarm|waterAlarm|burglaryAlarm|carbonMonoxideAlarm]]
** wenn der type nicht angegeben wird ist fireAlarm der default
** automatisch werden 0, ok und alles was mit no anfängt als OK erkannt. alles andere gilt als ALARM.

Es werden noch einige andere häufig verwendete Geräte (Homematic, hue,...) automatisch erkannt.

to be continued ...

In der [https://developer.amazon.com/docs/device-apis/list-of-interfaces.html List of Capability Interfaces] bei Amazon kann man sehen, welche Möglichkeiten das Smart Home Skill API aktuell in einzelnen Ländern bietet. Leider ohne die jeweiligen landessprachlichen Kommandos.

=== Aktiv Routinen starten ===
Routinen (eine Funktionalität, die rein - genauso wie "Räume" - bei Amazon liegt und nicht von FHEM Connector beeinflusst wird) waren lange die ewige Antwort auf die Frage: "Meine Frau möchte aber '''Öffne Rollläden''<nowiki/>' sagen": In der Alexa-App gibt es im Menü den Punkt "Routinen", und hier lässt sich eine gewisse Anzahl von Aktionen (unter optionalen Bedingungen) an ein Sprachkommando knüpfen.

Neu: Routinen können inzwischen auch von Skills getriggert werden, und seit Version 0.5.47 (Februar 2020) auch von FHEM Connector. Das braucht niemand, um die Rollläden hochzufahren, denn das kann FHEM ja selber, aber um z.B. eine Ansage auf einem Alexa-Gerät zu triggern. Dafür gibt es auch das FHEM-Modul "echodevice", aber es erfordert ein paar Klimmzüge. Mit dem aktiven Triggern von Routinen kann FHEM auslösen, dass Alexa ungefragt (!) Dinge wie

''"Die Temperatur in der Tiefkühltruhe hat -16 Grad überschritten"''

in den Raum sagt. Also eine Alternative bzw. Ergänzung zu Alarmen / Erinnerungen per Telegram o.ä.

'''Vorgeschichte''':

Die Smarthome-Skill-API von Amazon sah schon lange das "proactiveReporting" vor: Also z.B. die gemessene Temperatur nicht erst auf Anfrage hin zu übermitteln, sondern laufend aktiv zu pushen. Aber warum Daten an Amazon senden, wenn es dafür keinen Mehrwert gibt? Beim Öffnen z.B. des Thermostaten in der Alexa-App kommen ohnehin laufend Statusabfragen. Warum also einen Datenpool bei Amazon über die Haustemperatur aufbauen und Änderungen pushen, wenn es keinen Mehrwert dafür gibt?

Inzwischen lassen sich (reale oder vermeintliche) Änderungen von ''Bewegungssensoren'' und ''Fensterkontakten'' als Startbedingung an Alexa-Routinen koppeln. Man kann in der Alexa-App (ggf. fiktive) Öffnen eines Fensterkontaktes an das Aufsagen eines freien Textes durch die Hausbutlerin knüpfen.

'''Umsetzung''':
* Jedes Alexa-Device, dessen Status aktiv zu Amazon gepusht werden soll, im Attribut "alexaProactiveEvents" mit einer "1" versehen. Per Default wird ''kein'' Gerät laufend aktiv zu Amazon gepusht!
* das geänderte Device einmal zu Amazon pushen "set <alexa> add <device>" (oder 'Alexa, suche neue Geräte' murmeln)
* Das Gerät sollte jetzt beim Anlegen einer neuen Routine ("Neue Routine", "Wenn Folgendes passiert", "Smart Home") als möglicher Triggerpunkt erscheinen.

==== Dummygeräte: ====
Ein Dummydevice sollte einen Kontaktschalter oder Bewegungssensor simulieren, um dann in FHEM eine beliebige Bedingung als Trigger zu definieren, und eine freie Ansage in Alexa als Routine zu definieren. Hier ein Beispiel:

<syntaxhighlight lang="bash" style="width:90%;">
define voicetrigger1 dummy
attr voicetrigger1 alexaName Trigger 1
attr voicetrigger1 alexaProactiveEvents 1
attr voicetrigger1 genericDeviceType contact
attr voicetrigger1 homebridgeMapping ContactSensorState=state,values=closed:CONTACT_DETECTED;;open:CONTACT_NOT_DETECTED
attr voicetrigger1 readingList 0:closed 1:open
attr voicetrigger1 setList closed open

set alexa add voicetrigger1
set alexa restart
</syntaxhighlight>

'''Fehlersuche:'''

Der Push setzt ein intaktes Push-Token voraus. Sollte im Alexa-Logfile Folgendes erscheinen:

<code>failed to refresh token: invalid_grant: 'The request has an invalid grant parameter : refresh_token'</code>

so ist das Push-Token nicht aktuell. Weil die Auswirkung lange nur war, dass Geräteänderungen nicht aktiv an Amazon gemeldet wurden, gibt es noch keine umfassende Analyse des Problems. Es lässt sich lösen, indem eine oder beide folgenden Aktionen ausgeführt werden:
* Löschen des ".eventToken" im Alexa-Device über "deletereading"
* "FHEM-Connector"-Skill auf "alexa.amazon.de" einmal deaktivieren und dann neu verbinden

== Mögliche Probleme und Lösungen ==

Es kann vorkommen, dass Geräte zwar korrekt erkannt werden, aber das durch Alexa erkannte Kommando nicht richtig umgesetzt wird (Beispiel - mittlerweile behoben: {{Link2Forum|Topic=96766}}). Neben dem FHEM-Log gibt es noch das Logfile, welches von alexa-fhem angelegt wird.

=== Fehlersuche über die FHEM-Oberfläche ===

* alexa-fhem Logfile anschauen (Detail-Ansicht des <alexa>-Device aufrufen, klick auf '''Logfile''' oben)
* alexa-fhem im Debug-Modus aufrufen:
** -D zum alexaFHEM-params attribut hinzufügen
** Alexa-Befehl auslösen
** -D aus dem alexaFHEM-params attribut entfernen
* Die notwendigen Informationen finden sich in dem alexa-Logfile (siehe oben)

=== Fehlersuche über Kommandozeile (lies: Shell) + FHEM-Oberfläche ===

:* set <alexa> stop (FHEM-Oberfläche)
:* Auf der Kommandozeile <code>alexa-fhem -D -c /opt/fhem/alexa-fhem.cfg > debug.log</code> starten (dadurch wird die Datei debug.log erzeugt im aktuellen Verzeichnis)
:* Alexa-Befehl auslösen
:* alexa-fhem auf der Kommandozeile wieder stoppen (CTRL-C)
:* set <alexa> start (FHEM-Oberfläche)

Die Datei debug.log sollte Hinweise enthalten, wie das Problem zu lösen ist oder Dich zumindest in die richtige Richtung schieben.

Im Beispiel aus dem Forum fand sich in dem Logfile der Hinweis darauf, dass das Device mit falschen min/max-Werten unterwegs war.

=== Registrierungskey vergessen, Registrierung zurücksetzen ===

Auf der Kommandoshell:

<syntaxhighlight lang="bash" style="width:90%;">
pi@raspberrypi:~# sudo -u fhem ssh -p 58824 fhem-va.fhem.de status
Registered.
Registered on 2019-01-13T15:38:13Z.
</syntaxhighlight>

heisst, das der Vereinsserver eigentlich alles hat, was er will. Es wird kein neuer Schlüssel generiert.
Wenn Du die Situation zurücksetzen möchtest, wäre die hässliche Methode, Deinen SSH-Key zu löschen. Eleganter ist, die Registrierung auf Vereinsseite zu löschen:

<syntaxhighlight lang="bash" style="width:90%;">
pi@raspberrypi:~# sudo -u fhem ssh -p 58824 fhem-va.fhem.de unregister
Your registration has been removed
</syntaxhighlight>

löscht Deinen Schlüssel mitsamt allen dort gespeicherten Daten auf Vereinsseite. Bei Restart von alexa-fhem in FHEM-WEB wird jetzt ein neuer Registrierungskey angefordert.

== Sicherheitskonzept und Secrets ==

Um diesen Abschnitt zu verstehen, solltest Du den Abschnitt "Arbeitsweise" im Kopf haben. Einerseits ist Dir vermutlich einleuchtend, dass ein Server, der per SSH rückwärts nur ausgewählte Kommandos in den Tunnel, den Du aufgebaut hast, leitet, "irgendwie sicherer" ist. Andererseits möchte man nicht blind vertrauen.

=== SSH ===
==== SSH - macht das nichts Gefährliches? ====
SSH ist ein Veteran des Internet und entstand, um sich sicher (verschlüsselt) und schnell auf Servern einzuloggen. Schon früh wurde dabei der sogenannte "Reverse-Tunnel" implementiert: Also der vom Client (Deinem Rechner) geäußerte Wunsch: "Bitte leite mir Requests, die bei Dir, Server, auf Port xy eingehen, an meinen lokalen Port yz weiter.". Dieses Verfahren implementiert der Reverseproxy, wobei tatsächlich auf dem Server für Dich kein echter Port geöffnet wird.

Wie Dir ggf. sicher der Unix-Guru Deines Vertrauens bestätigen wird: Die Kombination
<syntaxhighlight lang="bash" style="width:50%;">
ssh -R 1234:localhost:<zufälliger port> zielserver
</syntaxhighlight>
erlaubt keine Ausführung von Shell-Kommandos auf Deinem Server, sondern einzig, dass vom SSH-Programm Verbindungen zu einem lokalen Port auf Deinem Server auf dem alexa-fhem lauscht aufgebaut werden. Du kannst also z.B. mit einem
<syntaxhighlight lang="bash" style="width:50%;">
sudo /usr/sbin/tcpdump -X -s 0 -i lo port <zufälliger port>
</syntaxhighlight>
vollständig überwachen (oder ggf. permanent aufzeichen), was auf Deinem Server von außen gesteuert passiert.

==== Wie wird bei SSH verschlüsselt? ====
Im Prinzip wie im Web auf SSL-Seiten, teils mit den gleichen Verschlüsselungsverfahren. Allerdings arbeitet SSH eher wie das im Web recht seltene Verfahren: Bei jeder Verbindung übermitteln sowohl Server wie auch Client den öffentlichen Teil ihres Schlüssels. Anders als im Web wird der Schlüssel aber nicht von einer öffentlichen Zertifizierungsstelle wie "LetsEncrypt" unterschrieben. Stattdessen entscheiden Server wie Client beim ersten Verbindungsaufbau typischerweise per manueller Frage: "Willst Du jetzt und künftig diesem Schlüssel vertrauen?" Bei der Installation wird diese Frage für Deine Seite bejaht, und fortan wird der öffentliche Schlüssel des FHEM-Servers auf Deinem Rechner gespeichert. Ab da bist Du z.B. davor sicher, dass jemand den DNS-Eintrag verbiegt oder sich in den Datenfluss Deines Providers einhängt: Ein geänderter Serverschlüssel würde bemerkt werden.
 
Soweit klar? Aus Deinem öffentlichen Schlüssel wiederum leitet der Server her: "Das ist definitiv wieder derjenige, der sich damals "registriert" hat". Und an dieser Stelle kann ich auch den ersten Teil des 3-teiligen Registrierungskeys erläutern: Die typischerweise 6-stellige Hex-Zahl am Anfang ist der Java-Hashcode Deines öffentlichen Schlüssel. Sie ist damit sozusagen Deine aus Deinem öffentlichen Schlüssel abgeleitete Benutzer-ID.

=== Die Rolle der Secrets ===
Wenn jetzt klar ist, dass die Verbindung zum Vereinsserver sicher und vertauschungsfrei funktioniert, bleiben noch 2 Probleme zu lösen:
1) Im Web bei der Skill-Aktivierung musst Du beweisen, dass Du der Mensch am Browser bist, dem der SSH-Tunnel von IP xy mit dem öffentlichen Schlüssel X gehört. Bei der automatischen Registrierung werden lokal auf Deinem Rechner zwei 64-Bit-Secrets generiert:
* Das Anmelde-Secret
* Das Bearer-Token
Beim Anmelden des SSH-Keys auf dem öffentlichen Server wird nun der Hashwert des ersten Secrets übertragen und dort in Verbindung mit Deinem öffentlichen Schlüssel gespeichert. Ein Hashwert bedeutet, dass (sofern das Verfahren, hier SHA256, funktioniert), niemand aus dem Hash das Secret zurückrechnen kann. Ein Datenbankklau auf dem Server gefährdet also nicht die Sicherheit Deines Passwortes.

Wenn Du nun beim Skill-Aktivieren den Registrierungskey eingibst, dann "sieht" der Server zum ersten Mal Dein ausgewürfeltes Secret, vergleicht es mit dem Hashwert und wird es anschließend wieder umgehend vergessen. Anhand des Hashwertes kann der Server aber entscheiden, dass Du der legitime Nutzer zum öffentlichen Schlüssel XY bist.

2) Das zweite Problem ist: Wie soll Amazon "beweisen", dass sie der legitime Aufrufer sind? Amazon erhält binnen wenigen Sekunden nach dem Klick auf "Activate Skill" den dritten Teil des Registrierungskeys als sogenanntes Bearer-Token. Zwar läuft er durch den Registrierungsserver, er wird dort, auf dem Registrierungs/Vereinsserver aber nicht gespeichert. Das Bearer-Token wird von Amazon bei allen Requests zu Deinem Server mitgesendet. Da es am Anfang zusätzlich Deine "User-ID" enthält, weiß der Vereinsserver, zu welchem SSH-Tunnel der Request zu senden ist. Aber lokal auf Deinem Rechner wird ausgewertet, ob das Token "stimmt".

== alexa-fhem Updaten bzw. "Upgraden" ==

'''Updaten einer "Connector" Installation:'''
* alexa-fhem über FHEM anhalten (Name des Alexa-Device: alexa):
:<syntaxhighlight lang="perl" style="width:50%;">set alexa stop</syntaxhighlight>

*Auf der Konsole wie anfangs bei der Installation:
:<syntaxhighlight lang="bash" style="width:50%;">sudo npm update -g alexa-fhem</syntaxhighlight>

:Manchmal hat npm Probleme mit einem Update. Dann einfach die aktuelle Version noch mal drüber Installieren:

:<syntaxhighlight lang="bash" style="width:50%;">sudo npm install -g alexa-fhem</syntaxhighlight>

*alexa-fhem über FHEM wieder starten:
:<syntaxhighlight lang="perl" style="width:50%;">set alexa start</syntaxhighlight>

'''"Upgraden von einer "Nicht-Connector" Installation (z.B. manuelle Installation per pm-Download):'''
* Daten der aktuellen Installation sichern (v.a. config.json / man weiß ja nie)
* Autostart der aktuellen alexa-fhem Installation deaktivieren:
** Bei initd: Service deaktivieren mittels: <code>sudo update-rc.d -f alexa remove</code> Vorher mittels stoppen: <code>sudo service alexa stop</code> Startscript unter /etc/init.d/ löschen.
** Bei systemd: Service deaktivieren mittels: <code>sudo systemctl disable alexa</code> Vorher mittels stoppen: <code>sudo systemctl alexa stop</code> Startscript unter /etc/systemd/system/ löschen.
* ALLE vorhandenen alexa-fhem Daten LÖSCHEN! Bleiben Dinge zurück und wird dann laut Connector installiert kann es zu Problemen kommen!
* (reboot)
* Installation von alexa-fhem laut Anleitung (Beginn dieses Wiki)
* Falls eigene Dinge von früher genutzt werden wollen/sollen (z.B. Custom Skill), dann die entsprechenden Einträge aus der gesicherten config.json in die neu angelegte alexa-fhem.cfg (zu finden unter "Edit files") übernehmen.
* Werden keine eigenen Dinge verwendet, dann kann der Port (Standard: 3000) geschlossen werden und auch die Daten unter Amazon-Developer können gelöscht werden.

== Bug- und Wunschliste ==
* Ist beim Start keine Internetverbindung vorhanden, erfolgt kein Retry -- alexa-fhem muss restartet werden (ssh_autoconfig wertet keine temporären Fehler aus)

==Weitergehende Informationen==
*[[Alexa und Mappings]]
*[[Alexa Tipps und Kniffe]]
*[[FHEM Connector for Amazon Alexa]]
[[Kategorie:HOWTOS]]
[[Kategorie:Sprachsteuerung]]

==Hinweise==
<references />

FHEM Connector für Amazon Alexa

2020-06-01T14:04:44Z

MadMax-FHEM:

{{Baustelle}}
'''Alexa FHEMlazy''' war historisch ein Fork des Original [[Alexa-Fhem|alexa-fhem]], der im Januar 2019 mit dem Original zusammengeführt wurde und nun als '''FHEM Connector''' verfügbar ist.

Er ermöglicht innerhalb von Minuten die Verknüpfung von FHEM mit einem Amazon Echo Gerät. Auch Geräte anderer Hersteller mit verbauten Mikrofonen und Alexa-Sprachassistenten-Unterstützung sollten problemlos funktionieren. Für folgende Geräte ist dies bspw. der Fall (Falls Ihr andere/weitere Gerätemodelle bzw. Hersteller in Verwendung habt, bitte hier pflegen):

* SONOS Beam und SONOS One

Gegenüber dem klassischen Ansatz ergeben sich Einschränkungen, so läuft die Software normalerweise unter dem gleichen Benutzer wie FHEM auf dem gleichen Server, und es wird z.Zt. nur der Smarthome-Skill unterstützt (die Variante, bei der die Möglichkeiten der Interaktion von Amazon festgelegt wurden).
Dafür ist weder ein Developer-Account bei Amazon, eigene Lambda- und Skillfunktionen, noch das Öffnen eines eingehenden Ports aus dem Internet nötig.
* Die Software integriert einen Installer, der die Erstkonfiguration und Anmeldung übernimmt
* Die Kommunikation zur Software auf dem heimischen Rechner und dann zu FHEM verläuft über SSH und einen vom FHEM-Verein gehosteten Server
* Funktioniert mit IPv4, IPv6, echtem Dual Stack und DS-Lite
* Als Skill bei Amazon wird der Skill "FHEM Connector" verwendet.

Der Thread im Forum zur Software ist hier: {{Link2Forum|Topic=94817}}.

{{Infobox Modul
|ModPurpose=Einfache Anbindung von FHEM an Amazon Assistent Alexa
|ModType=h
|ModCmdRef=alexa
|ModTechName=39_alexa.pm / alexa-fhem
|ModForumArea=Frontends/Sprachsteuerung
|ModOwner=gvzdus, André/ justme1968 ({{Link2FU|430|Forum}} / [[Benutzer Diskussion:Justme|Wiki]])
}}

==Einführung==

===Arbeitsweise und Datenfluss===
Vorläufig ist alexa-fhem im "FHEM Connector-Modus" ein reiner [https://developer.amazon.com/de/docs/smarthome/understand-the-smart-home-skill-api.html SmartHome-Skill].
SmartHome-Skills erhalten weder die Sprachdaten selber noch das, was Amazon in Textform verstanden hat, sondern vielmehr extrahiert Amazon aus dem verstandenen Text Anweisungen und Abfragen für Geräte, die dann an den Skill übermittelt werden. Charmant ist dabei, dass unmittelbar gefragt werden kann "Alexa, wie ist die Temperatur im Wohnzimmer?", während andere Skills zunächst explizit angesprochen werden müssen ("Alexa, frage FHEM nach der Temperatur im Wohnzimmer"). Außerdem kann der Nutzer mehrere Smarthome-Skills installieren, und die Geräte werden zu einer Gesamtmenge zusammengefasst.

Gehen wir den Datenfluss bei der konkreten Frage "Wie ist die Temperatur im Wohnzimmer?" durch:
* Alexa hat bei der Skillinstallation gelernt, dass "FHEM Connector" bei Dir einen Thermostaten im Raum Wohnzimmer kennt. Dadurch wird bei der Sprachanalyse von "Alexa Voice Service" in der Cloud erkannt, dass eine Abfrage an "FHEM Connector" erfolgversprechend ist.
* Zunächst wird die zentrale "Lambda-Funktion" von "FHEM Connector" aufgerufen. Die Funktion leitet aber im Kern nur den Request unverändert an den vom Verein bereitgestellten Server weiter. Im Request enthalten ist ein Token, das sogenannte "Bearer-Token".
* Der "Vereinsserver" prüft anhand dieses Tokens, ob es überhaupt bekannt ist, und zu welchem Nutzer es gehört. Ist dieser Nutzer verbunden, wird der Request wiederum quasi unverändert an den Nutzer weitergeleitet.
* Diese Weiterleitung passiert über einen sogenannten SSH-Reverse-Tunnel, der von Deiner Seite und der Software auf dem FHEM-Tunnel automatisch aufgebaut wird.
* Auf Deiner Seite läuft die eigentliche Software, und zwar unter nodeJS. nodeJS ist ein Javascript ausführender Miniserver, der lokal auf einem Zufallsport auf Requests "lauscht". In der Original-Version [[Alexa-Fhem|Alexa FHEM]] kommen die Requests aus dem Internet (hoffentlich von der eigenen Lambda-Funktion), hier bei "FHEM Connector" kommen sie ausschließlich aus dem SSH-Tunnel von lokal.
* Die Software validiert nun diesen Request anhand des Bearer-Tokens. Konkret wird dabei das bei der Installation generierte Token, dass bei der Skill-Aktivierung an Amazon übertragen wurde, mit dem lokal gespeicherten Wert verglichen. Stimmt das Token, wird der Befehl verarbeitet, üblicherweise wird hierbei ein Aufruf an die Webschnittstelle von FHEM abgesetzt.
* FHEM führt den Befehl aus

Hört sich langsam und kompliziert an? Kompliziert: Okay. Langsam eher nicht, in etlichen Fällen liegt die Gesamtantwortszeit unter 200 ms.

Soweit ein erster Überblick über die Datenflüsse. Im Abschnitt Sicherheit ist das Konzept der Absicherung deutlich genauer und ausführlicher beschrieben.

==Installation==

Du wirst bei der Installation zuerst auf der Kommandozeile auf Deinem Raspberry (o.ä.) unterwegs sein, anschließend im Webfrontend von FHEM, und zum Schluss auf der Alexa-Konsole im Web.

===node.js installieren===

Ab Jessy liegt NodeJS bereits in einer ausreichend aktuellen Version vor (Stretch und Buster funktionieren ebenfalls). Mit

<syntaxhighlight lang="bash" style="width:50%;">
sudo apt-get install nodejs npm
</syntaxhighlight>

kannst Du es installieren. Mit
<syntaxhighlight lang="bash" style="width:50%;">
node --version
</syntaxhighlight>

erfährst Du die aktuelle Version - wenn hier etwas mit "8" oder höher vorneweg erscheint, ist alles gut.
Ansonsten suche Dir bitte eine Anleitung im Web, wie Du NodeJS auf Deinem System auf einen aktuellen Stand bringen kannst.

=== Alexa-FHEM installieren ===

Nun installieren wir Alexa-fhem aus dem offiziellen Repository:

<syntaxhighlight lang="bash" style="width:50%;">
sudo npm install -g alexa-fhem
</syntaxhighlight>

Der Vorgang benötigt etwas Zeit.

=== Alexa-FHEM aktivieren ===

Wechsele jetzt in FHEM-Web!

Wichtig ist, dass das Alexa-Modul in der Version ab Januar 2019 vorliegt. Dafür bitte einmal FHEM aktualisieren:
Speichern der Config nicht vergessen, und

<syntaxhighlight lang="bash" style="width:50%;">
update
shutdown restart
</syntaxhighlight>

Alles, was jetzt noch nötig ist, ist das Anlegen eines Alexa-Devices. Gib dafür in der FHEM-Web-Kommandozeile

<syntaxhighlight lang="bash" style="width:50%;">
define alexa alexa
</syntaxhighlight>

an. Nun läuft, während Du bereits das neu angelegte Alexa-Devices siehst, ein komplexer Prozess im Hintergrund:

* Falls noch kein SSH-Key für den Benutzer, unter dem FHEM läuft, existiert, wird einer generiert
* Es wird ein Secret-Key im Prozess generiert, dass den Server nicht verlässt, und der Skillanmeldung dient.
* Du wirst auf dem Server "va-fhem.fhem.de" des FHEM-Vereins mit dem SSH-Key angemeldet, und der Hash-Wert Deines Secret-Key dort abgelegt.

Und wenn Du diese Sätze gelesen hast, sollte inzwischen sich das Alexa-Device in FHEM-Web aktualisiert haben, und
ungefähr so aussehen:

[[Datei:Alexa-Device-2.png|800px]]

Neben dem Status für alexa-fhem und der Proxyverbindung ist wichtig, dass diese beiden Zeilen beim Reload aufgetaucht sind:

<syntaxhighlight lang="bash" style="width:90%;">
alexaFHEM.bearerToken crypt:...
alexaFHEM.skillRegKey crypt:...
</syntaxhighlight>

Ja, und diesen Schlüssel benötigst Du wirklich! Also am besten schon einmal mit

<syntaxhighlight lang="bash" style="width:90%;">
get <alexa> proxyKey
</syntaxhighlight>

in Klartext anzeigen lassen und in ein Editor-Fenster dauerhaft wegsichern.

Jetzt solltest Du Dein Alexa-Device nicht mehr löschen, denn das im Reading angezeigte "bearerToken" zu löschen bedeutet, dass die Software die Zugriffe von nicht mehr überprüfen kann und keine Kommandos mehr funktionieren. In diesem Fall hilft nur die Neuinstallation des Skills.

==== Fehler bei der Aktivierung ====

Während kompliziertere Fehlerfälle im Abschnitt "Mögliche Probleme und Lösungen" behandelt werden, hier häufige Fälle, warum die kryptischen Zeilen nicht auftauchen:

* Zuerst bitte einfach einmal die Seite neu laden.

===== 401: Authorization Required =====

Wenn Du FHEM-Web mit einem User/Passwort-Schutz versehen hast, wirst du folgende Fehlermeldung sehen:

<syntaxhighlight lang="bash" style="width:90%;">
alexaFHEM stopped; failed to connect to fhem: 401: Authorization Required
</syntaxhighlight>

In der Regel musst du die Angaben User/Passwort noch einmal explizit setzen. Im Attribute-Abschnitt "alexaFHEM-auth" auswählen, User/Passwort mit ":" getrennt angeben und "attr" anklicken. alexa-fhem wird automatisch neu gestartet. Hier das Ganze in der Text-Variante:

<syntaxhighlight lang="bash" style="width:90%;">
attr alexa alexaFHEM-auth user:pass
</syntaxhighlight>

===== Permission denied =====

Wenn du folgende Fehlermeldungen im Alexa Logfile siehst, wurde das Verzeichnis "/opt/fhem/.ssh/" von dir bei der Arbeit mit "root" oder "sudo" mit den falschen Berechtigungen versehen:

<syntaxhighlight lang="bash" style="width:90%;">
[2019-7-25 11:59:12] sshautoconf: aborted with ssh-keygen returned error - key_save_private: Permission denied
[2019-7-25 11:59:12] *** SSH: proxy configuration failed: ssh-keygen returned error - key_save_private: Permission denied
</syntaxhighlight>

Prüfen kannst du die Berechtigungen mit folgendem Befehl auf der Shell-Konsole:

<syntaxhighlight lang="bash" style="width:90%;">
ls -l /opt/fhem/.ssh
</syntaxhighlight>

Du solltest dann folgende Ausgabe erhalten:

<syntaxhighlight lang="bash" style="width:90%;">
insgesamt 12
-rw------- 1 fhem dialout 1675 Jul 12 13:10 id_rsa
-rw-r--r-- 1 fhem dialout 391 Jul 12 13:10 id_rsa.pub
-rw-r--r-- 1 fhem dialout 884 Jul 12 13:10 known_hosts
</syntaxhighlight>

Steht in der Ausgabe nicht "fhem dialout" (dein fhem User), sondern bspw. "root root", dann bspw. mit folgendem Befehl an deinen fhem User anpassen:

<syntaxhighlight lang="bash" style="width:90%;">
chown fhem:dialout /opt/fhem/.ssh
</syntaxhighlight>

Mit dem ersten Befehl "ls -l ..." kannst du dann nochmal prüfen, ob die Berechtigungen korrekt übernommen wurden.

===== weitere Prüfungen =====

Hast Du noch die Shell-Konsole offen? Dann prüfe bitte noch einmal auf der Konsole, ob nun zwei Prozesse laufen:

<syntaxhighlight lang="bash" style="width:50%;">
ps -ef | egrep '(alexa|ssh)'
</syntaxhighlight>

sollte Dir idealerweise so etwas anzeigen:
<syntaxhighlight lang="bash" style="width:90%;">
fhem 31322 1 99 13:56 ? 00:00:03 alexa
fhem 31332 31322 8 13:56 ? 00:00:00 /usr/bin/ssh -R 1234:127.0.0.1:<zufälliger port> -oServerAliveInterval=90 -p 58824 fhem-va.fhem.de
</syntaxhighlight>

"alexa" ist dabei der Node-JS-Prozess, der ssh-Prozess ist die aufgebaute Verbindung zum Vereinsserver.

Wenn Du diese Prozesse '''nicht''' siehst oder das Alexa-Device keinen Registrierungskey anzeigt, dann ist leider der Start nicht glatt verlaufen.

Im Logfile (über den link <code>Logfile</code> in der Detail-Ansicht über <code>set</code>, oder über den Namen bei ''currentlogfile'' in den Internals) findest Du idealerweise selber Hinweise, wo es hakt, oder kannst im Forum nachfragen.

=== Geräte im FHEM-Webfrontend zuweisen ===
Um das Aha-Erlebnis zu vergrößern, ist jetzt ein guter Zeitpunkt, 1 oder besser mind. 2 Geräte für den Alexa-Dienst zuzuweisen. Von Haus aus wird keines Deiner FHEM-Geräte automatisch Alexa zugewiesen!

Wähle die Geräte aus, rufe sie auf und setze das Attribut "alexaName". Hierbei in Kürze nur der Hinweis:
* Keine Angst vor Leerzeichen und Umlauten, funktioniert.
* Große Angst vor Rechtschreibfehlern (Terrasse, Rollladen) oder komplizierten Wörtern "handgebastelte Martinslaterne im Kinderzimmer Iphigenie-Chantal".
* Mehrere Namen für dasselbe Gerät/Device in fhem werden unterstützt. Mehrere Namen werden durch Strichpunkt getrennt.
* Das Attribut "alexaRoom" ist NUR FÜR DEN CUSTOM SKILL relevant. Ausnahme: structure und LightScene Devices, siehe: [[FHEM_Connector_f%C3%BCr_Amazon_Alexa#Was_geht_alles_.3F]].

Lade die Geräte neu in die Software, indem Du <code>set <alexa> restart</code> ausführst!
[[Datei:HowToSet alexaName.png|alternativtext=How to set alexaName|ohne|mini|Wie setzt man das Attribut alexaName]]

'''Anmerkungen (weil oft gestellte Fragen im Forum) bzgl. Erkennung von Geräten:'''

* Wichtig ist, dass die Filtereinstellung in der alexa-fhem.cfg (zu finden unter "Edit Files") passt.
Das, was dort eingetragen ist (Standard: alexaName=..* / also es ist ein alexaName vergeben) auch an den entsprechenden Devices in fhem vorhanden ist.
Stimmt das nicht überein, kann alexa-fhem keine Devices von fhem abfragen/finden.
Ob der Filter entsprechend funktioniert kann man wie folgt testen: ''list Filtereinstellung'' beispiel mit Standardfilter: ''list alexaName=..*''

* Hat alexa-fhem per Filter Devices aus fhem "gefunden", geht es weiter mit der "Erkennung". Also um welches Device (Typ und "Fähigkeiten") handelt es sich. Dazu gilt folgendes:
** sind entsprechende Readings beim Device vorhanden (z.B. temperature, state mit on/off, ...) erkennt das alexa-fhem automatisch. Die Liste der automatisch erkannten Readings wächst ständig. Daher erst mal schauen ob das Device bereits entsprechend erkannt (typisiert) wurde. Das kann durch prüfen des alexa-fhem-Logs geschehen (NICHT fhem-log!).
** sind entsprechende "set-Befehle" erkennbar (oft auch durch Readings). Also ist beispielsweise (wie beim Dummy nötig) ein ''setList'' mit entsprechenden Einträgen vorhanden oder entsprechende Readings, z.B. desired-temp zum Stellen der Temperatur etc.
** wird das Device nicht richtig oder "unvollständig" erkannt helfen folgende Attribute:
*** genericDeviceType: hiermit kann alexa-fhem in die gewünschte Richtung "geschubbst" werden. Anmerkung: man kann nicht alles erzwingen, Readings bzw. set-Befehle müssen passen (oder per homebridgeMapping passend gemacht werden). Wenn ein genericDeviceType nicht per "Drop-Down" erscheint, dann kann er auch (wenn bekannt) einfach per WEB-cmd eingegeben werden: ''attr Devicename genericDeviceType media''
*** homebridgeMapping: hierdurch kann alexa-fhem bei der Erkennung von Zuständen und möglichen Einstellungen (also WAS kann das Device) unterstützt werden. Mittels homebridgeMapping können vorhandene Readings (Zustände) auf für alexa-fhem bekannte Zustände gemappt werden. Ebenso können damit Standard-fhem-Kommandos von alexa-fhem auf Device-spezifische gemappt werden. Beispiel: on/off auf Ein/Aus (falls das Device statt on/off eben ein Ein/Aus erwartet). Zum Beispiel: <syntaxhighlight lang="bash" style="width:50%;">
attr <thermostat> homebridgeMapping TargetTemperature=target::target,minValue=18,maxValue=25,minStep=0.5 CurrentTemperature=myTemp:temperature
</syntaxhighlight> [https://github.com/justme-1968/homebridge-fhem/blob/master/README.md weitere Beispiele]

'''Mehrere Namen für dasselbe Gerät/Device in fhem sind möglich.'''
Die Namen werden durch Strichpunkt getrennt.
Beispiel:
<code>attr dmLampe alexaName Lichtkuppel;Lichtkugel</code>

'''Anmerkung bzgl. genericDeviceType und homebridgeMapping:''' 
* diese Attribute werden von verschiedenen "Sprachsteuerungsmodulen" in fhem verwendet (homebridge [dort wurde es "erfunden"], alexa-fhem, gassistant, ...). Daher ist nicht jedes Mapping für alle "Dienste" verwendbar. Ausprobieren schadet aber nicht.
* ebenso kann man mit diesen Attributen (homebridgeMapping wird gerne so "missbraucht") nichts erzwingen, was seitens Amazon/Alexa nicht unterstützt bzw. verstanden wird! D.h. zunächst ist zu prüfen, ob ein bestimmter (gewünschter) Sprachbefehl seitens Amazon/Alexa unterstützt wird! Aktuelles Beispiel (Stand Jan 2020): "Alexa, fahre den Rollo hoch/runter". Da ist Amazon/Alexa gerade dabei etwas zu tun. Bislang wird das nicht unterstützt, also ist das auch mit einem entsprechenden homebridgeMapping nicht zu erzwingen! Was unterstützt wird kann man bei Amazon nachlesen: [https://developer.amazon.com/es-ES/docs/alexa/device-apis/list-of-interfaces.html]

== Finale: Skill verknüpfen ==
Suche im WebFrontend oder der Alexa-App den Skill "FHEM Connector". Für nicht-Mac/iOS Anwerder empfiehlt das WebFrontend (https://alexa.amazon.de) statt die App, damit Du den Anmeldeschlüssel auch bequem kopieren kannst.

Wenn du noch nicht bei Amazon angemeldet bist, erwartet Amazon zunächst, dass Du Dich normal bei Amazon anmeldest.

Sobald Du "FHEM Connector" aktivierst, öffnet sich ein Browser-Tab mit folgender Maske: 
[[Datei:FHEMlazy_login.png|240px]]

Hier kopierst Du Deinen Anmeldeschlüssel (im Klartext!) hinein und klickst auf Check. Als glücklicher Mensch ist auf der folgenden Statusseite alles grün: 
[[Datei:FHEMlazy_check.png|240px]]

Im Einzelnen wird hier geprüft, ob Du per SSH verbunden bist (und auch Deine IP zur Sicherheit angezeigt), ob der Reverse-Tunnel steht, ob nodeJS erreichbar ist und wie viele Geräte Alexa gleich finden sollte (in meinem Fall 22).

Sollte etwas nicht grün sein und Du eine Idee zum Fixen haben, kannst Du mit "Retry" neue Versuche auslösen.

Ist alles okay, klicke rechts den Button "Activate Skill". Du springst damit wieder zurück zu Amazon, die Dir hoffentlich zur erfolgreichen Verknüpfung gratulieren.

Amazon möchte nun unmittelbar die Gerätesuche starten, und unter SmartHome-Geräte sollten diese nun auftauchen.

== Was geht alles ? ==

* Geräte, die sich ein- und ausschalten lassen:
** Automatisch: Müssen <code>set on</code> und <code>set off</code> Kommandos haben
** dummys müssen <code>setList</code> mit on und off haben
** Über <code>genericDeviceType</code> switch bzw. light kann bestimmt werden ob es in alexa als Schalter oder Licht behandelt wird.
** Wenn die Set-Kommandos im FHEM Device anders benannt sind: homebridgeMapping On:cmdOn=<ein>,cmdOff=<aus> setzen
** Kommandos:
***Alexa, schalte <name> ein/aus
***Alexa, Licht an/aus
***Alexa, schalte <gruppe> ein/aus
* Geräte, die eine Temperatur messen
** Automatisch: Es muss ein Reading <code>temperature</code> geben
** Über <code>genericDeviceType</code> thermometer
** Sonst: homebridgeMapping CurrentTemperature:reading=<reading>

* Geräte, deren Helligkeit sich ändern lässt
** Automatisch: wenn <code>dim</code> oder <code>pct</code> Kommandos erkannt werden
** Über <code>genericDeviceType</code> light
** Über homebridgeMapping: Wenn <code>helligkeit</code> das Reading für die aktuelle Helligkeit enthält und die Helligkeit mit <code>set <device> prozent xxx</code> gesetzt wird, sieht das homebridgeMapping wie folgt aus: homebridgeMapping Brightness=helligkeit::prozent,minValue=0,maxValue=<maximalwert>
** Kommandos:
*** Alexa, mache <name> heller/dunkler
*** Alexa, Licht heller/dunkler
* Geräte, deren Farbe sich ändern lässt
** ...

* Geräte, deren Farbtemperatur sich ändern lässt
** ...

* Geräte, bei denen sich eine Lautstärke einstellen lässt
** ...

* Geräte, bei denen sich ein prozentualer Wert einstellen lässt
** Automatisch: wenn <code>dim</code> oder <code>pct</code> Kommandos erkannt werden
** ...

* elektrische Türschlösser
** <code>genericDeviceType</code>: lock
** homebridgeMapping mit LockCurrentState und LockTargetState

* Thermostate
** Über <code>genericDeviceType</code> thermostate
** ...

* structure Devices aus FHEM (ab alexa-fhem version 0.5.7)
** können mit <code>genericDeviceType</code> scene als Szene eingebunden werden
** über <code>alexaRoom</code> kann der name um einen Ort ergänzt werden
** Szenen aus einer structure lassen sich ein- und ausschalten
** Wichtig:
*** Ein Skill darf nur 12 Szenen automatisch erkennen und einbinden.

* LightScene Devices aus FHEM (ab alexa-fhem version 0.5.8)
** können mit <code>genericDeviceType</code> scene als Szenen eingebunden werden
** über <code>alexaRoom</code> kann der name um einen Ort ergänzt werden
** Szenen aus einer LightScene lassen sich nur einschalten
** Wichtig:
*** Ein Skill darf nur 12 Szenen automatisch erkennen und einbinden.

* Geräte, deren Kanal sich umschalten lässt (ab alexa-fhem version 0.5.13)
** Über <code>genericDeviceType</code> media
** homebridgeMapping ChannelController:reading=<reading>,cmd=<cmd>
** Erlaubte Werte siehe hier: https://developer.amazon.com/de/docs/device-apis/alexa-channelcontroller.html#changechannel
** ...

* Geräte, deren Playback status sich schalten lässt (ab alexa-fhem version 0.5.13)
** Über <code>genericDeviceType</code> media
** homebridgeMapping PlaybackController:playback,values=Play;Pause;Stop;Previous;Next
** Erlaubte Werte siehe hier: https://developer.amazon.com/de/docs/device-apis/alexa-playbackcontroller.html#discovery
** ...

* Geräte, deren Eingang sich umschalten lässt (ab alexa-fhem version 0.5.13)
** Über <code>genericDeviceType</code> media
** homebridgeMapping InputController:reading=<reading>,cmd=<cmd>,values=HDMI+1;HDMI+2;XBOX
** Erlaubte Werte siehe hier: https://developer.amazon.com/de/docs/device-apis/alexa-property-schemas.html#input
** ...

* Kontaktsensoren (ab alexa-fhem version 0.5.15)
** Über <code>genericDeviceType</code> contact
** homebridgeMapping ContactSensorState:reading=<reading> oder CurrentDoorState:reading=<reading>
** Die Anzeige in der Alexa-App funktioniert sofort, die Abfrage per Sprache erst ab Version 0.5.27.

* Geräte, deren Lautstärke sich ändern lässt (ab alexa-fhem version 0.5.24)
** Über <code>genericDeviceType</code> speaker
** Automatisch: es muss ein Reading <code>volume</code> und/oder <code>mute</code> geben
** homebridgeMapping Volume:reading=<reading>,cmd=<cmd> Mute:reading=<reading>,cmd=<cmd>
** ...

* Geräte, die sich ein- (und optional) ausschalten lassen als Szene (ab alexa-fhem version 0.5.26)
** Über <code>genericDeviceType</code> scene
** Automatisch: Müssen <code>set on</code> und <code>set off</code> Kommandos haben
** homebridgeMapping On:reading=<reading>,cmdOn=<cmd>[,cmdOff=<cmd>]
** Hinweis: Fehlende Kommandos lassen sich mit cmdalias erzeugen
** Wichtig:
*** Ein Skill darf nur 12 Szenen automatisch erkennen und einbinden.
* Rollläden. Lange ein Problemthema, das nur mit "Schalte auf 0%, schalte auf 100% lief". Wichtig: "alexa-fhem" ab Version 0.5.39 einsetzen. GenericDevice-Type auf "blind" setzen. Nach Restart von alexa-fhem und neuer Gerätesuche sollte folgendes funktionieren:
** "..., öffne <Name> ganz"
** "..., schließe <Name> komplett"
** "hoch" und "runter" (ohne "ganz" oder "komplett") schalten jeweils nur einen bestimmten Prozentsatz hoch oder runter. Dieser kann mit <code>attr <name> homebridgeMapping TargetPosition:minStep=<wert></code>geändert werden. Aber Achtung: In diesem Intervall kann dann auch nur noch ein absoluter Prozentwert per Sprache oder Slider eingestellt werden! Bei z.B. 25% würden 13% zu 25% aufgerundet, 12% zu 0% abgerundet werden.
* Kontaktsensoren (ab alexa-fhem version 0.5.47)
** Automatisch wenn ein Reading <code>motion</code> vorhanden ist oder es sich um einen Zigbee bewgungsmelder an einer HUE oder deCONZ Bridge handelt
** Über <code>genericDeviceType</code> MotionSensor
** homebridgeMapping MotionDetected:reading=<reading>,values=<wert für bewgung>:1;<wert für keine bewegung>:0

* Alarmmelder (noch nicht in Deutschland):
** genericDeviceType Security
** homebridgeMapping Alarm=<reading>[,type=[fireAlarm|waterAlarm|burglaryAlarm|carbonMonoxideAlarm]]
** wenn der type nicht angegeben wird ist fireAlarm der default
** automatisch werden 0, ok und alles was mit no anfängt als OK erkannt. alles andere gilt als ALARM.

Es werden noch einige andere häufig verwendete Geräte (Homematic, hue,...) automatisch erkannt.

to be continued ...

In der [https://developer.amazon.com/docs/device-apis/list-of-interfaces.html List of Capability Interfaces] bei Amazon kann man sehen, welche Möglichkeiten das Smart Home Skill API aktuell in einzelnen Ländern bietet. Leider ohne die jeweiligen landessprachlichen Kommandos.

=== Aktiv Routinen starten ===
Routinen (eine Funktionalität, die rein - genauso wie "Räume" - bei Amazon liegt und nicht von FHEM Connector beeinflusst wird) waren lange die ewige Antwort auf die Frage: "Meine Frau möchte aber '''Öffne Rollläden''<nowiki/>' sagen": In der Alexa-App gibt es im Menü den Punkt "Routinen", und hier lässt sich eine gewisse Anzahl von Aktionen (unter optionalen Bedingungen) an ein Sprachkommando knüpfen.

Neu: Routinen können inzwischen auch von Skills getriggert werden, und seit Version 0.5.47 (Februar 2020) auch von FHEM Connector. Das braucht niemand, um die Rollläden hochzufahren, denn das kann FHEM ja selber, aber um z.B. eine Ansage auf einem Alexa-Gerät zu triggern. Dafür gibt es auch das FHEM-Modul "echodevice", aber es erfordert ein paar Klimmzüge. Mit dem aktiven Triggern von Routinen kann FHEM auslösen, dass Alexa ungefragt (!) Dinge wie

''"Die Temperatur in der Tiefkühltruhe hat -16 Grad überschritten"''

in den Raum sagt. Also eine Alternative bzw. Ergänzung zu Alarmen / Erinnerungen per Telegram o.ä.

'''Vorgeschichte''':

Die Smarthome-Skill-API von Amazon sah schon lange das "proactiveReporting" vor: Also z.B. die gemessene Temperatur nicht erst auf Anfrage hin zu übermitteln, sondern laufend aktiv zu pushen. Aber warum Daten an Amazon senden, wenn es dafür keinen Mehrwert gibt? Beim Öffnen z.B. des Thermostaten in der Alexa-App kommen ohnehin laufend Statusabfragen. Warum also einen Datenpool bei Amazon über die Haustemperatur aufbauen und Änderungen pushen, wenn es keinen Mehrwert dafür gibt?

Inzwischen lassen sich (reale oder vermeintliche) Änderungen von ''Bewegungssensoren'' und ''Fensterkontakten'' als Startbedingung an Alexa-Routinen koppeln. Man kann in der Alexa-App (ggf. fiktive) Öffnen eines Fensterkontaktes an das Aufsagen eines freien Textes durch die Hausbutlerin knüpfen.

'''Umsetzung''':
* Jedes Alexa-Device, dessen Status aktiv zu Amazon gepusht werden soll, im Attribut "alexaProactiveEvents" mit einer "1" versehen. Per Default wird ''kein'' Gerät laufend aktiv zu Amazon gepusht!
* das geänderte Device einmal zu Amazon pushen "set <alexa> add <device>" (oder 'Alexa, suche neue Geräte' murmeln)
* Das Gerät sollte jetzt beim Anlegen einer neuen Routine ("Neue Routine", "Wenn Folgendes passiert", "Smart Home") als möglicher Triggerpunkt erscheinen.

==== Dummygeräte: ====
Ein Dummydevice sollte einen Kontaktschalter oder Bewegungssensor simulieren, um dann in FHEM eine beliebige Bedingung als Trigger zu definieren, und eine freie Ansage in Alexa als Routine zu definieren. Hier ein Beispiel:

<syntaxhighlight lang="bash" style="width:90%;">
define voicetrigger1 dummy
attr voicetrigger1 alexaName Trigger 1
attr voicetrigger1 alexaProactiveEvents 1
attr voicetrigger1 genericDeviceType contact
attr voicetrigger1 homebridgeMapping ContactSensorState=state,values=closed:CONTACT_DETECTED;;open:CONTACT_NOT_DETECTED
attr voicetrigger1 readingList 0:closed 1:open
attr voicetrigger1 setList closed open

set alexa add voicetrigger1
set alexa restart
</syntaxhighlight>

'''Fehlersuche:'''

Der Push setzt ein intaktes Push-Token voraus. Sollte im Alexa-Logfile Folgendes erscheinen:

<code>failed to refresh token: invalid_grant: 'The request has an invalid grant parameter : refresh_token'</code>

so ist das Push-Token nicht aktuell. Weil die Auswirkung lange nur war, dass Geräteänderungen nicht aktiv an Amazon gemeldet wurden, gibt es noch keine umfassende Analyse des Problems. Es lässt sich lösen, indem eine oder beide folgenden Aktionen ausgeführt werden:
* Löschen des ".eventToken" im Alexa-Device über "deletereading"
* "FHEM-Connector"-Skill auf "alexa.amazon.de" einmal deaktivieren und dann neu verbinden

== Mögliche Probleme und Lösungen ==

Es kann vorkommen, dass Geräte zwar korrekt erkannt werden, aber das durch Alexa erkannte Kommando nicht richtig umgesetzt wird (Beispiel - mittlerweile behoben: {{Link2Forum|Topic=96766}}). Neben dem FHEM-Log gibt es noch das Logfile, welches von alexa-fhem angelegt wird.

=== Fehlersuche über die FHEM-Oberfläche ===

* alexa-fhem Logfile anschauen (Detail-Ansicht des <alexa>-Device aufrufen, klick auf '''Logfile''' oben)
* alexa-fhem im Debug-Modus aufrufen:
** -D zum alexaFHEM-params attribut hinzufügen
** Alexa-Befehl auslösen
** -D aus dem alexaFHEM-params attribut entfernen
* Die notwendigen Informationen finden sich in dem alexa-Logfile (siehe oben)

=== Fehlersuche über Kommandozeile (lies: Shell) + FHEM-Oberfläche ===

:* set <alexa> stop (FHEM-Oberfläche)
:* Auf der Kommandozeile <code>alexa-fhem -D -c /opt/fhem/alexa-fhem.cfg > debug.log</code> starten (dadurch wird die Datei debug.log erzeugt im aktuellen Verzeichnis)
:* Alexa-Befehl auslösen
:* alexa-fhem auf der Kommandozeile wieder stoppen (CTRL-C)
:* set <alexa> start (FHEM-Oberfläche)

Die Datei debug.log sollte Hinweise enthalten, wie das Problem zu lösen ist oder Dich zumindest in die richtige Richtung schieben.

Im Beispiel aus dem Forum fand sich in dem Logfile der Hinweis darauf, dass das Device mit falschen min/max-Werten unterwegs war.

=== Registrierungskey vergessen, Registrierung zurücksetzen ===

Auf der Kommandoshell:

<syntaxhighlight lang="bash" style="width:90%;">
pi@raspberrypi:~# sudo -u fhem ssh -p 58824 fhem-va.fhem.de status
Registered.
Registered on 2019-01-13T15:38:13Z.
</syntaxhighlight>

heisst, das der Vereinsserver eigentlich alles hat, was er will. Es wird kein neuer Schlüssel generiert.
Wenn Du die Situation zurücksetzen möchtest, wäre die hässliche Methode, Deinen SSH-Key zu löschen. Eleganter ist, die Registrierung auf Vereinsseite zu löschen:

<syntaxhighlight lang="bash" style="width:90%;">
pi@raspberrypi:~# sudo -u fhem ssh -p 58824 fhem-va.fhem.de unregister
Your registration has been removed
</syntaxhighlight>

löscht Deinen Schlüssel mitsamt allen dort gespeicherten Daten auf Vereinsseite. Bei Restart von alexa-fhem in FHEM-WEB wird jetzt ein neuer Registrierungskey angefordert.

== Sicherheitskonzept und Secrets ==

Um diesen Abschnitt zu verstehen, solltest Du den Abschnitt "Arbeitsweise" im Kopf haben. Einerseits ist Dir vermutlich einleuchtend, dass ein Server, der per SSH rückwärts nur ausgewählte Kommandos in den Tunnel, den Du aufgebaut hast, leitet, "irgendwie sicherer" ist. Andererseits möchte man nicht blind vertrauen.

=== SSH ===
==== SSH - macht das nichts Gefährliches? ====
SSH ist ein Veteran des Internet und entstand, um sich sicher (verschlüsselt) und schnell auf Servern einzuloggen. Schon früh wurde dabei der sogenannte "Reverse-Tunnel" implementiert: Also der vom Client (Deinem Rechner) geäußerte Wunsch: "Bitte leite mir Requests, die bei Dir, Server, auf Port xy eingehen, an meinen lokalen Port yz weiter.". Dieses Verfahren implementiert der Reverseproxy, wobei tatsächlich auf dem Server für Dich kein echter Port geöffnet wird.

Wie Dir ggf. sicher der Unix-Guru Deines Vertrauens bestätigen wird: Die Kombination
<syntaxhighlight lang="bash" style="width:50%;">
ssh -R 1234:localhost:<zufälliger port> zielserver
</syntaxhighlight>
erlaubt keine Ausführung von Shell-Kommandos auf Deinem Server, sondern einzig, dass vom SSH-Programm Verbindungen zu einem lokalen Port auf Deinem Server auf dem alexa-fhem lauscht aufgebaut werden. Du kannst also z.B. mit einem
<syntaxhighlight lang="bash" style="width:50%;">
sudo /usr/sbin/tcpdump -X -s 0 -i lo port <zufälliger port>
</syntaxhighlight>
vollständig überwachen (oder ggf. permanent aufzeichen), was auf Deinem Server von außen gesteuert passiert.

==== Wie wird bei SSH verschlüsselt? ====
Im Prinzip wie im Web auf SSL-Seiten, teils mit den gleichen Verschlüsselungsverfahren. Allerdings arbeitet SSH eher wie das im Web recht seltene Verfahren: Bei jeder Verbindung übermitteln sowohl Server wie auch Client den öffentlichen Teil ihres Schlüssels. Anders als im Web wird der Schlüssel aber nicht von einer öffentlichen Zertifizierungsstelle wie "LetsEncrypt" unterschrieben. Stattdessen entscheiden Server wie Client beim ersten Verbindungsaufbau typischerweise per manueller Frage: "Willst Du jetzt und künftig diesem Schlüssel vertrauen?" Bei der Installation wird diese Frage für Deine Seite bejaht, und fortan wird der öffentliche Schlüssel des FHEM-Servers auf Deinem Rechner gespeichert. Ab da bist Du z.B. davor sicher, dass jemand den DNS-Eintrag verbiegt oder sich in den Datenfluss Deines Providers einhängt: Ein geänderter Serverschlüssel würde bemerkt werden.
 
Soweit klar? Aus Deinem öffentlichen Schlüssel wiederum leitet der Server her: "Das ist definitiv wieder derjenige, der sich damals "registriert" hat". Und an dieser Stelle kann ich auch den ersten Teil des 3-teiligen Registrierungskeys erläutern: Die typischerweise 6-stellige Hex-Zahl am Anfang ist der Java-Hashcode Deines öffentlichen Schlüssel. Sie ist damit sozusagen Deine aus Deinem öffentlichen Schlüssel abgeleitete Benutzer-ID.

=== Die Rolle der Secrets ===
Wenn jetzt klar ist, dass die Verbindung zum Vereinsserver sicher und vertauschungsfrei funktioniert, bleiben noch 2 Probleme zu lösen:
1) Im Web bei der Skill-Aktivierung musst Du beweisen, dass Du der Mensch am Browser bist, dem der SSH-Tunnel von IP xy mit dem öffentlichen Schlüssel X gehört. Bei der automatischen Registrierung werden lokal auf Deinem Rechner zwei 64-Bit-Secrets generiert:
* Das Anmelde-Secret
* Das Bearer-Token
Beim Anmelden des SSH-Keys auf dem öffentlichen Server wird nun der Hashwert des ersten Secrets übertragen und dort in Verbindung mit Deinem öffentlichen Schlüssel gespeichert. Ein Hashwert bedeutet, dass (sofern das Verfahren, hier SHA256, funktioniert), niemand aus dem Hash das Secret zurückrechnen kann. Ein Datenbankklau auf dem Server gefährdet also nicht die Sicherheit Deines Passwortes.

Wenn Du nun beim Skill-Aktivieren den Registrierungskey eingibst, dann "sieht" der Server zum ersten Mal Dein ausgewürfeltes Secret, vergleicht es mit dem Hashwert und wird es anschließend wieder umgehend vergessen. Anhand des Hashwertes kann der Server aber entscheiden, dass Du der legitime Nutzer zum öffentlichen Schlüssel XY bist.

2) Das zweite Problem ist: Wie soll Amazon "beweisen", dass sie der legitime Aufrufer sind? Amazon erhält binnen wenigen Sekunden nach dem Klick auf "Activate Skill" den dritten Teil des Registrierungskeys als sogenanntes Bearer-Token. Zwar läuft er durch den Registrierungsserver, er wird dort, auf dem Registrierungs/Vereinsserver aber nicht gespeichert. Das Bearer-Token wird von Amazon bei allen Requests zu Deinem Server mitgesendet. Da es am Anfang zusätzlich Deine "User-ID" enthält, weiß der Vereinsserver, zu welchem SSH-Tunnel der Request zu senden ist. Aber lokal auf Deinem Rechner wird ausgewertet, ob das Token "stimmt".

== alexa-fhem Updaten bzw. "Upgraden" ==

'''Updaten einer "Connector" Installation:'''
* alexa-fhem über FHEM anhalten (Name des Alexa-Device: alexa):
:<syntaxhighlight lang="perl" style="width:50%;">set alexa stop</syntaxhighlight>

*Auf der Konsole wie anfangs bei der Installation:
:<syntaxhighlight lang="bash" style="width:50%;">sudo npm update -g alexa-fhem</syntaxhighlight>

:Manchmal hat npm Probleme mit einem Update. Dann einfach die aktuelle Version noch mal drüber Installieren:

:<syntaxhighlight lang="bash" style="width:50%;">sudo npm install -g alexa-fhem</syntaxhighlight>

*alexa-fhem über FHEM wieder starten:
:<syntaxhighlight lang="perl" style="width:50%;">set alexa start</syntaxhighlight>

'''"Upgraden von einer "Nicht-Connector" Installation (z.B. manuelle Installation per pm-Download):'''
* Daten der aktuellen Installation sichern (v.a. config.json / man weiß ja nie)
* Autostart der aktuellen alexa-fhem Installation deaktivieren:
** Bei initd: Service deaktivieren mittels: <code>sudo update-rc.d -f alexa remove</code> Vorher mittels stoppen: <code>sudo service alexa stop</code> Startscript unter /etc/init.d/ löschen.
** Bei systemd: Service deaktivieren mittels: <code>sudo systemctl disable alexa</code> Vorher mittels stoppen: <code>sudo systemctl alexa stop</code> Startscript unter /etc/systemd/system/ löschen.
* ALLE vorhandenen alexa-fhem Daten LÖSCHEN! Bleiben Dinge zurück und wird dann laut Connector installiert kann es zu Problemen kommen!
* (reboot)
* Installation von alexa-fhem laut Anleitung (Beginn dieses Wiki)
* Falls eigene Dinge von früher genutzt werden wollen/sollen (z.B. Custom Skill), dann die entsprechenden Einträge aus der gesicherten config.json in die neu angelegte alexa-fhem.cfg (zu finden unter "Edit files") übernehmen.
* Werden keine eigenen Dinge verwendet, dann kann der Port (Standard: 3000) geschlossen werden und auch die Daten unter Amazon-Developer können gelöscht werden.

== Bug- und Wunschliste ==
* Ist beim Start keine Internetverbindung vorhanden, erfolgt kein Retry -- alexa-fhem muss restartet werden (ssh_autoconfig wertet keine temporären Fehler aus)

==Weitergehende Informationen==
*[[Alexa und Mappings]]
*[[Alexa Tipps und Kniffe]]
*[[FHEM Connector for Amazon Alexa]]
[[Kategorie:HOWTOS]]
[[Kategorie:Sprachsteuerung]]

FHEM Connector für Amazon Alexa

2020-06-01T14:04:00Z

MadMax-FHEM:

{{Baustelle}}
'''Alexa FHEMlazy''' war historisch ein Fork des Original [[Alexa-Fhem|alexa-fhem]], der im Januar 2019 mit dem Original zusammengeführt wurde und nun als '''FHEM Connector''' verfügbar ist.

Er ermöglicht innerhalb von Minuten die Verknüpfung von FHEM mit einem Amazon Echo Gerät. Auch Geräte anderer Hersteller mit verbauten Mikrofonen und Alexa-Sprachassistenten-Unterstützung sollten problemlos funktionieren. Für folgende Geräte ist dies bspw. der Fall (Falls Ihr andere/weitere Gerätemodelle bzw. Hersteller in Verwendung habt, bitte hier pflegen):

* SONOS Beam und SONOS One

Gegenüber dem klassischen Ansatz ergeben sich Einschränkungen, so läuft die Software normalerweise unter dem gleichen Benutzer wie FHEM auf dem gleichen Server, und es wird z.Zt. nur der Smarthome-Skill unterstützt (die Variante, bei der die Möglichkeiten der Interaktion von Amazon festgelegt wurden).
Dafür ist weder ein Developer-Account bei Amazon, eigene Lambda- und Skillfunktionen, noch das Öffnen eines eingehenden Ports aus dem Internet nötig.
* Die Software integriert einen Installer, der die Erstkonfiguration und Anmeldung übernimmt
* Die Kommunikation zur Software auf dem heimischen Rechner und dann zu FHEM verläuft über SSH und einen vom FHEM-Verein gehosteten Server
* Funktioniert mit IPv4, IPv6, echtem Dual Stack und DS-Lite
* Als Skill bei Amazon wird der Skill "FHEM Connector" verwendet.

Der Thread im Forum zur Software ist hier: {{Link2Forum|Topic=94817}}.

{{Infobox Modul
|ModPurpose=Einfache Anbindung von FHEM an Amazon Assistent Alexa
|ModType=h
|ModCmdRef=alexa
|ModTechName=39_alexa.pm / alexa-fhem
|ModForumArea=Frontends/Sprachsteuerung
|ModOwner=gvzdus, André/ justme1968 ({{Link2FU|430|Forum}} / [[Benutzer Diskussion:Justme|Wiki]])
}}

==Einführung==

===Arbeitsweise und Datenfluss===
Vorläufig ist alexa-fhem im "FHEM Connector-Modus" ein reiner [https://developer.amazon.com/de/docs/smarthome/understand-the-smart-home-skill-api.html SmartHome-Skill].
SmartHome-Skills erhalten weder die Sprachdaten selber noch das, was Amazon in Textform verstanden hat, sondern vielmehr extrahiert Amazon aus dem verstandenen Text Anweisungen und Abfragen für Geräte, die dann an den Skill übermittelt werden. Charmant ist dabei, dass unmittelbar gefragt werden kann "Alexa, wie ist die Temperatur im Wohnzimmer?", während andere Skills zunächst explizit angesprochen werden müssen ("Alexa, frage FHEM nach der Temperatur im Wohnzimmer"). Außerdem kann der Nutzer mehrere Smarthome-Skills installieren, und die Geräte werden zu einer Gesamtmenge zusammengefasst.

Gehen wir den Datenfluss bei der konkreten Frage "Wie ist die Temperatur im Wohnzimmer?" durch:
* Alexa hat bei der Skillinstallation gelernt, dass "FHEM Connector" bei Dir einen Thermostaten im Raum Wohnzimmer kennt. Dadurch wird bei der Sprachanalyse von "Alexa Voice Service" in der Cloud erkannt, dass eine Abfrage an "FHEM Connector" erfolgversprechend ist.
* Zunächst wird die zentrale "Lambda-Funktion" von "FHEM Connector" aufgerufen. Die Funktion leitet aber im Kern nur den Request unverändert an den vom Verein bereitgestellten Server weiter. Im Request enthalten ist ein Token, das sogenannte "Bearer-Token".
* Der "Vereinsserver" prüft anhand dieses Tokens, ob es überhaupt bekannt ist, und zu welchem Nutzer es gehört. Ist dieser Nutzer verbunden, wird der Request wiederum quasi unverändert an den Nutzer weitergeleitet.
* Diese Weiterleitung passiert über einen sogenannten SSH-Reverse-Tunnel, der von Deiner Seite und der Software auf dem FHEM-Tunnel automatisch aufgebaut wird.
* Auf Deiner Seite läuft die eigentliche Software, und zwar unter nodeJS. nodeJS ist ein Javascript ausführender Miniserver, der lokal auf einem Zufallsport auf Requests "lauscht". In der Original-Version [[Alexa-Fhem|Alexa FHEM]] kommen die Requests aus dem Internet (hoffentlich von der eigenen Lambda-Funktion), hier bei "FHEM Connector" kommen sie ausschließlich aus dem SSH-Tunnel von lokal.
* Die Software validiert nun diesen Request anhand des Bearer-Tokens. Konkret wird dabei das bei der Installation generierte Token, dass bei der Skill-Aktivierung an Amazon übertragen wurde, mit dem lokal gespeicherten Wert verglichen. Stimmt das Token, wird der Befehl verarbeitet, üblicherweise wird hierbei ein Aufruf an die Webschnittstelle von FHEM abgesetzt.
* FHEM führt den Befehl aus

Hört sich langsam und kompliziert an? Kompliziert: Okay. Langsam eher nicht, in etlichen Fällen liegt die Gesamtantwortszeit unter 200 ms.

Soweit ein erster Überblick über die Datenflüsse. Im Abschnitt Sicherheit ist das Konzept der Absicherung deutlich genauer und ausführlicher beschrieben.

==Installation==

Du wirst bei der Installation zuerst auf der Kommandozeile auf Deinem Raspberry (o.ä.) unterwegs sein, anschließend im Webfrontend von FHEM, und zum Schluss auf der Alexa-Konsole im Web.

===node.js installieren===

Ab Jessy liegt NodeJS bereits in einer ausreichend aktuellen Version vor (Stretch und Buster funktionieren ebenfalls). Mit

<syntaxhighlight lang="bash" style="width:50%;">
sudo apt-get install nodejs npm
</syntaxhighlight>

kannst Du es installieren. Mit
<syntaxhighlight lang="bash" style="width:50%;">
node --version
</syntaxhighlight>

erfährst Du die aktuelle Version - wenn hier etwas mit "8" oder höher vorneweg erscheint, ist alles gut.
Ansonsten suche Dir bitte eine Anleitung im Web, wie Du NodeJS auf Deinem System auf einen aktuellen Stand bringen kannst.

=== Alexa-FHEM installieren ===

Nun installieren wir Alexa-fhem aus dem offiziellen Repository:

<syntaxhighlight lang="bash" style="width:50%;">
sudo npm install -g alexa-fhem
</syntaxhighlight>

Der Vorgang benötigt etwas Zeit.

=== Alexa-FHEM aktivieren ===

Wechsele jetzt in FHEM-Web!

Wichtig ist, dass das Alexa-Modul in der Version ab Januar 2019 vorliegt. Dafür bitte einmal FHEM aktualisieren:
Speichern der Config nicht vergessen, und

<syntaxhighlight lang="bash" style="width:50%;">
update
shutdown restart
</syntaxhighlight>

Alles, was jetzt noch nötig ist, ist das Anlegen eines Alexa-Devices. Gib dafür in der FHEM-Web-Kommandozeile

<syntaxhighlight lang="bash" style="width:50%;">
define alexa alexa
</syntaxhighlight>

an. Nun läuft, während Du bereits das neu angelegte Alexa-Devices siehst, ein komplexer Prozess im Hintergrund:

* Falls noch kein SSH-Key für den Benutzer, unter dem FHEM läuft, existiert, wird einer generiert
* Es wird ein Secret-Key im Prozess generiert, dass den Server nicht verlässt, und der Skillanmeldung dient.
* Du wirst auf dem Server "va-fhem.fhem.de" des FHEM-Vereins mit dem SSH-Key angemeldet, und der Hash-Wert Deines Secret-Key dort abgelegt.

Und wenn Du diese Sätze gelesen hast, sollte inzwischen sich das Alexa-Device in FHEM-Web aktualisiert haben, und
ungefähr so aussehen:

[[Datei:Alexa-Device-2.png|800px]]

Neben dem Status für alexa-fhem und der Proxyverbindung ist wichtig, dass diese beiden Zeilen beim Reload aufgetaucht sind:

<syntaxhighlight lang="bash" style="width:90%;">
alexaFHEM.bearerToken crypt:...
alexaFHEM.skillRegKey crypt:...
</syntaxhighlight>

Ja, und diesen Schlüssel benötigst Du wirklich! Also am besten schon einmal mit

<syntaxhighlight lang="bash" style="width:90%;">
get <alexa> proxyKey
</syntaxhighlight>

in Klartext anzeigen lassen und in ein Editor-Fenster dauerhaft wegsichern.

Jetzt solltest Du Dein Alexa-Device nicht mehr löschen, denn das im Reading angezeigte "bearerToken" zu löschen bedeutet, dass die Software die Zugriffe von nicht mehr überprüfen kann und keine Kommandos mehr funktionieren. In diesem Fall hilft nur die Neuinstallation des Skills.

==== Fehler bei der Aktivierung ====

Während kompliziertere Fehlerfälle im Abschnitt "Mögliche Probleme und Lösungen" behandelt werden, hier häufige Fälle, warum die kryptischen Zeilen nicht auftauchen:

* Zuerst bitte einfach einmal die Seite neu laden.

===== 401: Authorization Required =====

Wenn Du FHEM-Web mit einem User/Passwort-Schutz versehen hast, wirst du folgende Fehlermeldung sehen:

<syntaxhighlight lang="bash" style="width:90%;">
alexaFHEM stopped; failed to connect to fhem: 401: Authorization Required
</syntaxhighlight>

In der Regel musst du die Angaben User/Passwort noch einmal explizit setzen. Im Attribute-Abschnitt "alexaFHEM-auth" auswählen, User/Passwort mit ":" getrennt angeben und "attr" anklicken. alexa-fhem wird automatisch neu gestartet. Hier das Ganze in der Text-Variante:

<syntaxhighlight lang="bash" style="width:90%;">
attr alexa alexaFHEM-auth user:pass
</syntaxhighlight>

===== Permission denied =====

Wenn du folgende Fehlermeldungen im Alexa Logfile siehst, wurde das Verzeichnis "/opt/fhem/.ssh/" von dir bei der Arbeit mit "root" oder "sudo" mit den falschen Berechtigungen versehen:

<syntaxhighlight lang="bash" style="width:90%;">
[2019-7-25 11:59:12] sshautoconf: aborted with ssh-keygen returned error - key_save_private: Permission denied
[2019-7-25 11:59:12] *** SSH: proxy configuration failed: ssh-keygen returned error - key_save_private: Permission denied
</syntaxhighlight>

Prüfen kannst du die Berechtigungen mit folgendem Befehl auf der Shell-Konsole:

<syntaxhighlight lang="bash" style="width:90%;">
ls -l /opt/fhem/.ssh
</syntaxhighlight>

Du solltest dann folgende Ausgabe erhalten:

<syntaxhighlight lang="bash" style="width:90%;">
insgesamt 12
-rw------- 1 fhem dialout 1675 Jul 12 13:10 id_rsa
-rw-r--r-- 1 fhem dialout 391 Jul 12 13:10 id_rsa.pub
-rw-r--r-- 1 fhem dialout 884 Jul 12 13:10 known_hosts
</syntaxhighlight>

Steht in der Ausgabe nicht "fhem dialout" (dein fhem User), sondern bspw. "root root", dann bspw. mit folgendem Befehl an deinen fhem User anpassen:

<syntaxhighlight lang="bash" style="width:90%;">
chown fhem:dialout /opt/fhem/.ssh
</syntaxhighlight>

Mit dem ersten Befehl "ls -l ..." kannst du dann nochmal prüfen, ob die Berechtigungen korrekt übernommen wurden.

===== weitere Prüfungen =====

Hast Du noch die Shell-Konsole offen? Dann prüfe bitte noch einmal auf der Konsole, ob nun zwei Prozesse laufen:

<syntaxhighlight lang="bash" style="width:50%;">
ps -ef | egrep '(alexa|ssh)'
</syntaxhighlight>

sollte Dir idealerweise so etwas anzeigen:
<syntaxhighlight lang="bash" style="width:90%;">
fhem 31322 1 99 13:56 ? 00:00:03 alexa
fhem 31332 31322 8 13:56 ? 00:00:00 /usr/bin/ssh -R 1234:127.0.0.1:<zufälliger port> -oServerAliveInterval=90 -p 58824 fhem-va.fhem.de
</syntaxhighlight>

"alexa" ist dabei der Node-JS-Prozess, der ssh-Prozess ist die aufgebaute Verbindung zum Vereinsserver.

Wenn Du diese Prozesse '''nicht''' siehst oder das Alexa-Device keinen Registrierungskey anzeigt, dann ist leider der Start nicht glatt verlaufen.

Im Logfile (über den link <code>Logfile</code> in der Detail-Ansicht über <code>set</code>, oder über den Namen bei ''currentlogfile'' in den Internals) findest Du idealerweise selber Hinweise, wo es hakt, oder kannst im Forum nachfragen.

=== Geräte im FHEM-Webfrontend zuweisen ===
Um das Aha-Erlebnis zu vergrößern, ist jetzt ein guter Zeitpunkt, 1 oder besser mind. 2 Geräte für den Alexa-Dienst zuzuweisen. Von Haus aus wird keines Deiner FHEM-Geräte automatisch Alexa zugewiesen!

Wähle die Geräte aus, rufe sie auf und setze das Attribut "alexaName". Hierbei in Kürze nur der Hinweis:
* Keine Angst vor Leerzeichen und Umlauten, funktioniert.
* Große Angst vor Rechtschreibfehlern (Terrasse, Rollladen) oder komplizierten Wörtern "handgebastelte Martinslaterne im Kinderzimmer Iphigenie-Chantal".
* Mehrere Namen für dasselbe Gerät/Device in fhem werden unterstützt. Mehrere Namen werden durch Strichpunkt getrennt.
* Das Attribut "alexaRoom" ist NUR FÜR DEN CUSTOM SKILL relevant. Ausnahme: structure und LightScene Devices, siehe: [[FHEM_Connector_f%C3%BCr_Amazon_Alexa#Was_geht_alles_.3F]].

Lade die Geräte neu in die Software, indem Du <code>set <alexa> restart</code> ausführst!
[[Datei:HowToSet alexaName.png|alternativtext=How to set alexaName|ohne|mini|Wie setzt man das Attribut alexaName]]

'''Anmerkungen (weil oft gestellte Fragen im Forum) bzgl. Erkennung von Geräten:'''

* Wichtig ist, dass die Filtereinstellung in der alexa-fhem.cfg (zu finden unter "Edit Files") passt.
Das, was dort eingetragen ist (Standard: alexaName=..* / also es ist ein alexaName vergeben) auch an den entsprechenden Devices in fhem vorhanden ist.
Stimmt das nicht überein, kann alexa-fhem keine Devices von fhem abfragen/finden.
Ob der Filter entsprechend funktioniert kann man wie folgt testen: ''list Filtereinstellung'' beispiel mit Standardfilter: ''list alexaName=..*''

* Hat alexa-fhem per Filter Devices aus fhem "gefunden", geht es weiter mit der "Erkennung". Also um welches Device (Typ und "Fähigkeiten") handelt es sich. Dazu gilt folgendes:
** sind entsprechende Readings beim Device vorhanden (z.B. temperature, state mit on/off, ...) erkennt das alexa-fhem automatisch. Die Liste der automatisch erkannten Readings wächst ständig. Daher erst mal schauen ob das Device bereits entsprechend erkannt (typisiert) wurde. Das kann durch prüfen des alexa-fhem-Logs geschehen (NICHT fhem-log!).
** sind entsprechende "set-Befehle" erkennbar (oft auch durch Readings). Also ist beispielsweise (wie beim Dummy nötig) ein ''setList'' mit entsprechenden Einträgen vorhanden oder entsprechende Readings, z.B. desired-temp zum Stellen der Temperatur etc.
** wird das Device nicht richtig oder "unvollständig" erkannt helfen folgende Attribute:
*** genericDeviceType: hiermit kann alexa-fhem in die gewünschte Richtung "geschubbst" werden. Anmerkung: man kann nicht alles erzwingen, Readings bzw. set-Befehle müssen passen (oder per homebridgeMapping passend gemacht werden). Wenn ein genericDeviceType nicht per "Drop-Down" erscheint, dann kann er auch (wenn bekannt) einfach per WEB-cmd eingegeben werden: ''attr Devicename genericDeviceType media''
*** homebridgeMapping: hierdurch kann alexa-fhem bei der Erkennung von Zuständen und möglichen Einstellungen (also WAS kann das Device) unterstützt werden. Mittels homebridgeMapping können vorhandene Readings (Zustände) auf für alexa-fhem bekannte Zustände gemappt werden. Ebenso können damit Standard-fhem-Kommandos von alexa-fhem auf Device-spezifische gemappt werden. Beispiel: on/off auf Ein/Aus (falls das Device statt on/off eben ein Ein/Aus erwartet). Zum Beispiel: <syntaxhighlight lang="bash" style="width:50%;">
attr <thermostat> homebridgeMapping TargetTemperature=target::target,minValue=18,maxValue=25,minStep=0.5 CurrentTemperature=myTemp:temperature
</syntaxhighlight> [https://github.com/justme-1968/homebridge-fhem/blob/master/README.md weitere Beispiele]

'''Mehrere Namen für dasselbe Gerät/Device in fhem ist möglich.'''
Die Namen werden durch Strichpunkt getrennt.
Beispiel:
<code>attr dmLampe alexaName Lichtkuppel;Lichtkugel</code>

'''Anmerkung bzgl. genericDeviceType und homebridgeMapping:''' 
* diese Attribute werden von verschiedenen "Sprachsteuerungsmodulen" in fhem verwendet (homebridge [dort wurde es "erfunden"], alexa-fhem, gassistant, ...). Daher ist nicht jedes Mapping für alle "Dienste" verwendbar. Ausprobieren schadet aber nicht.
* ebenso kann man mit diesen Attributen (homebridgeMapping wird gerne so "missbraucht") nichts erzwingen, was seitens Amazon/Alexa nicht unterstützt bzw. verstanden wird! D.h. zunächst ist zu prüfen, ob ein bestimmter (gewünschter) Sprachbefehl seitens Amazon/Alexa unterstützt wird! Aktuelles Beispiel (Stand Jan 2020): "Alexa, fahre den Rollo hoch/runter". Da ist Amazon/Alexa gerade dabei etwas zu tun. Bislang wird das nicht unterstützt, also ist das auch mit einem entsprechenden homebridgeMapping nicht zu erzwingen! Was unterstützt wird kann man bei Amazon nachlesen: [https://developer.amazon.com/es-ES/docs/alexa/device-apis/list-of-interfaces.html]

== Finale: Skill verknüpfen ==
Suche im WebFrontend oder der Alexa-App den Skill "FHEM Connector". Für nicht-Mac/iOS Anwerder empfiehlt das WebFrontend (https://alexa.amazon.de) statt die App, damit Du den Anmeldeschlüssel auch bequem kopieren kannst.

Wenn du noch nicht bei Amazon angemeldet bist, erwartet Amazon zunächst, dass Du Dich normal bei Amazon anmeldest.

Sobald Du "FHEM Connector" aktivierst, öffnet sich ein Browser-Tab mit folgender Maske: 
[[Datei:FHEMlazy_login.png|240px]]

Hier kopierst Du Deinen Anmeldeschlüssel (im Klartext!) hinein und klickst auf Check. Als glücklicher Mensch ist auf der folgenden Statusseite alles grün: 
[[Datei:FHEMlazy_check.png|240px]]

Im Einzelnen wird hier geprüft, ob Du per SSH verbunden bist (und auch Deine IP zur Sicherheit angezeigt), ob der Reverse-Tunnel steht, ob nodeJS erreichbar ist und wie viele Geräte Alexa gleich finden sollte (in meinem Fall 22).

Sollte etwas nicht grün sein und Du eine Idee zum Fixen haben, kannst Du mit "Retry" neue Versuche auslösen.

Ist alles okay, klicke rechts den Button "Activate Skill". Du springst damit wieder zurück zu Amazon, die Dir hoffentlich zur erfolgreichen Verknüpfung gratulieren.

Amazon möchte nun unmittelbar die Gerätesuche starten, und unter SmartHome-Geräte sollten diese nun auftauchen.

== Was geht alles ? ==

* Geräte, die sich ein- und ausschalten lassen:
** Automatisch: Müssen <code>set on</code> und <code>set off</code> Kommandos haben
** dummys müssen <code>setList</code> mit on und off haben
** Über <code>genericDeviceType</code> switch bzw. light kann bestimmt werden ob es in alexa als Schalter oder Licht behandelt wird.
** Wenn die Set-Kommandos im FHEM Device anders benannt sind: homebridgeMapping On:cmdOn=<ein>,cmdOff=<aus> setzen
** Kommandos:
***Alexa, schalte <name> ein/aus
***Alexa, Licht an/aus
***Alexa, schalte <gruppe> ein/aus
* Geräte, die eine Temperatur messen
** Automatisch: Es muss ein Reading <code>temperature</code> geben
** Über <code>genericDeviceType</code> thermometer
** Sonst: homebridgeMapping CurrentTemperature:reading=<reading>

* Geräte, deren Helligkeit sich ändern lässt
** Automatisch: wenn <code>dim</code> oder <code>pct</code> Kommandos erkannt werden
** Über <code>genericDeviceType</code> light
** Über homebridgeMapping: Wenn <code>helligkeit</code> das Reading für die aktuelle Helligkeit enthält und die Helligkeit mit <code>set <device> prozent xxx</code> gesetzt wird, sieht das homebridgeMapping wie folgt aus: homebridgeMapping Brightness=helligkeit::prozent,minValue=0,maxValue=<maximalwert>
** Kommandos:
*** Alexa, mache <name> heller/dunkler
*** Alexa, Licht heller/dunkler
* Geräte, deren Farbe sich ändern lässt
** ...

* Geräte, deren Farbtemperatur sich ändern lässt
** ...

* Geräte, bei denen sich eine Lautstärke einstellen lässt
** ...

* Geräte, bei denen sich ein prozentualer Wert einstellen lässt
** Automatisch: wenn <code>dim</code> oder <code>pct</code> Kommandos erkannt werden
** ...

* elektrische Türschlösser
** <code>genericDeviceType</code>: lock
** homebridgeMapping mit LockCurrentState und LockTargetState

* Thermostate
** Über <code>genericDeviceType</code> thermostate
** ...

* structure Devices aus FHEM (ab alexa-fhem version 0.5.7)
** können mit <code>genericDeviceType</code> scene als Szene eingebunden werden
** über <code>alexaRoom</code> kann der name um einen Ort ergänzt werden
** Szenen aus einer structure lassen sich ein- und ausschalten
** Wichtig:
*** Ein Skill darf nur 12 Szenen automatisch erkennen und einbinden.

* LightScene Devices aus FHEM (ab alexa-fhem version 0.5.8)
** können mit <code>genericDeviceType</code> scene als Szenen eingebunden werden
** über <code>alexaRoom</code> kann der name um einen Ort ergänzt werden
** Szenen aus einer LightScene lassen sich nur einschalten
** Wichtig:
*** Ein Skill darf nur 12 Szenen automatisch erkennen und einbinden.

* Geräte, deren Kanal sich umschalten lässt (ab alexa-fhem version 0.5.13)
** Über <code>genericDeviceType</code> media
** homebridgeMapping ChannelController:reading=<reading>,cmd=<cmd>
** Erlaubte Werte siehe hier: https://developer.amazon.com/de/docs/device-apis/alexa-channelcontroller.html#changechannel
** ...

* Geräte, deren Playback status sich schalten lässt (ab alexa-fhem version 0.5.13)
** Über <code>genericDeviceType</code> media
** homebridgeMapping PlaybackController:playback,values=Play;Pause;Stop;Previous;Next
** Erlaubte Werte siehe hier: https://developer.amazon.com/de/docs/device-apis/alexa-playbackcontroller.html#discovery
** ...

* Geräte, deren Eingang sich umschalten lässt (ab alexa-fhem version 0.5.13)
** Über <code>genericDeviceType</code> media
** homebridgeMapping InputController:reading=<reading>,cmd=<cmd>,values=HDMI+1;HDMI+2;XBOX
** Erlaubte Werte siehe hier: https://developer.amazon.com/de/docs/device-apis/alexa-property-schemas.html#input
** ...

* Kontaktsensoren (ab alexa-fhem version 0.5.15)
** Über <code>genericDeviceType</code> contact
** homebridgeMapping ContactSensorState:reading=<reading> oder CurrentDoorState:reading=<reading>
** Die Anzeige in der Alexa-App funktioniert sofort, die Abfrage per Sprache erst ab Version 0.5.27.

* Geräte, deren Lautstärke sich ändern lässt (ab alexa-fhem version 0.5.24)
** Über <code>genericDeviceType</code> speaker
** Automatisch: es muss ein Reading <code>volume</code> und/oder <code>mute</code> geben
** homebridgeMapping Volume:reading=<reading>,cmd=<cmd> Mute:reading=<reading>,cmd=<cmd>
** ...

* Geräte, die sich ein- (und optional) ausschalten lassen als Szene (ab alexa-fhem version 0.5.26)
** Über <code>genericDeviceType</code> scene
** Automatisch: Müssen <code>set on</code> und <code>set off</code> Kommandos haben
** homebridgeMapping On:reading=<reading>,cmdOn=<cmd>[,cmdOff=<cmd>]
** Hinweis: Fehlende Kommandos lassen sich mit cmdalias erzeugen
** Wichtig:
*** Ein Skill darf nur 12 Szenen automatisch erkennen und einbinden.
* Rollläden. Lange ein Problemthema, das nur mit "Schalte auf 0%, schalte auf 100% lief". Wichtig: "alexa-fhem" ab Version 0.5.39 einsetzen. GenericDevice-Type auf "blind" setzen. Nach Restart von alexa-fhem und neuer Gerätesuche sollte folgendes funktionieren:
** "..., öffne <Name> ganz"
** "..., schließe <Name> komplett"
** "hoch" und "runter" (ohne "ganz" oder "komplett") schalten jeweils nur einen bestimmten Prozentsatz hoch oder runter. Dieser kann mit <code>attr <name> homebridgeMapping TargetPosition:minStep=<wert></code>geändert werden. Aber Achtung: In diesem Intervall kann dann auch nur noch ein absoluter Prozentwert per Sprache oder Slider eingestellt werden! Bei z.B. 25% würden 13% zu 25% aufgerundet, 12% zu 0% abgerundet werden.
* Kontaktsensoren (ab alexa-fhem version 0.5.47)
** Automatisch wenn ein Reading <code>motion</code> vorhanden ist oder es sich um einen Zigbee bewgungsmelder an einer HUE oder deCONZ Bridge handelt
** Über <code>genericDeviceType</code> MotionSensor
** homebridgeMapping MotionDetected:reading=<reading>,values=<wert für bewgung>:1;<wert für keine bewegung>:0

* Alarmmelder (noch nicht in Deutschland):
** genericDeviceType Security
** homebridgeMapping Alarm=<reading>[,type=[fireAlarm|waterAlarm|burglaryAlarm|carbonMonoxideAlarm]]
** wenn der type nicht angegeben wird ist fireAlarm der default
** automatisch werden 0, ok und alles was mit no anfängt als OK erkannt. alles andere gilt als ALARM.

Es werden noch einige andere häufig verwendete Geräte (Homematic, hue,...) automatisch erkannt.

to be continued ...

In der [https://developer.amazon.com/docs/device-apis/list-of-interfaces.html List of Capability Interfaces] bei Amazon kann man sehen, welche Möglichkeiten das Smart Home Skill API aktuell in einzelnen Ländern bietet. Leider ohne die jeweiligen landessprachlichen Kommandos.

=== Aktiv Routinen starten ===
Routinen (eine Funktionalität, die rein - genauso wie "Räume" - bei Amazon liegt und nicht von FHEM Connector beeinflusst wird) waren lange die ewige Antwort auf die Frage: "Meine Frau möchte aber '''Öffne Rollläden''<nowiki/>' sagen": In der Alexa-App gibt es im Menü den Punkt "Routinen", und hier lässt sich eine gewisse Anzahl von Aktionen (unter optionalen Bedingungen) an ein Sprachkommando knüpfen.

Neu: Routinen können inzwischen auch von Skills getriggert werden, und seit Version 0.5.47 (Februar 2020) auch von FHEM Connector. Das braucht niemand, um die Rollläden hochzufahren, denn das kann FHEM ja selber, aber um z.B. eine Ansage auf einem Alexa-Gerät zu triggern. Dafür gibt es auch das FHEM-Modul "echodevice", aber es erfordert ein paar Klimmzüge. Mit dem aktiven Triggern von Routinen kann FHEM auslösen, dass Alexa ungefragt (!) Dinge wie

''"Die Temperatur in der Tiefkühltruhe hat -16 Grad überschritten"''

in den Raum sagt. Also eine Alternative bzw. Ergänzung zu Alarmen / Erinnerungen per Telegram o.ä.

'''Vorgeschichte''':

Die Smarthome-Skill-API von Amazon sah schon lange das "proactiveReporting" vor: Also z.B. die gemessene Temperatur nicht erst auf Anfrage hin zu übermitteln, sondern laufend aktiv zu pushen. Aber warum Daten an Amazon senden, wenn es dafür keinen Mehrwert gibt? Beim Öffnen z.B. des Thermostaten in der Alexa-App kommen ohnehin laufend Statusabfragen. Warum also einen Datenpool bei Amazon über die Haustemperatur aufbauen und Änderungen pushen, wenn es keinen Mehrwert dafür gibt?

Inzwischen lassen sich (reale oder vermeintliche) Änderungen von ''Bewegungssensoren'' und ''Fensterkontakten'' als Startbedingung an Alexa-Routinen koppeln. Man kann in der Alexa-App (ggf. fiktive) Öffnen eines Fensterkontaktes an das Aufsagen eines freien Textes durch die Hausbutlerin knüpfen.

'''Umsetzung''':
* Jedes Alexa-Device, dessen Status aktiv zu Amazon gepusht werden soll, im Attribut "alexaProactiveEvents" mit einer "1" versehen. Per Default wird ''kein'' Gerät laufend aktiv zu Amazon gepusht!
* das geänderte Device einmal zu Amazon pushen "set <alexa> add <device>" (oder 'Alexa, suche neue Geräte' murmeln)
* Das Gerät sollte jetzt beim Anlegen einer neuen Routine ("Neue Routine", "Wenn Folgendes passiert", "Smart Home") als möglicher Triggerpunkt erscheinen.

==== Dummygeräte: ====
Ein Dummydevice sollte einen Kontaktschalter oder Bewegungssensor simulieren, um dann in FHEM eine beliebige Bedingung als Trigger zu definieren, und eine freie Ansage in Alexa als Routine zu definieren. Hier ein Beispiel:

<syntaxhighlight lang="bash" style="width:90%;">
define voicetrigger1 dummy
attr voicetrigger1 alexaName Trigger 1
attr voicetrigger1 alexaProactiveEvents 1
attr voicetrigger1 genericDeviceType contact
attr voicetrigger1 homebridgeMapping ContactSensorState=state,values=closed:CONTACT_DETECTED;;open:CONTACT_NOT_DETECTED
attr voicetrigger1 readingList 0:closed 1:open
attr voicetrigger1 setList closed open

set alexa add voicetrigger1
set alexa restart
</syntaxhighlight>

'''Fehlersuche:'''

Der Push setzt ein intaktes Push-Token voraus. Sollte im Alexa-Logfile Folgendes erscheinen:

<code>failed to refresh token: invalid_grant: 'The request has an invalid grant parameter : refresh_token'</code>

so ist das Push-Token nicht aktuell. Weil die Auswirkung lange nur war, dass Geräteänderungen nicht aktiv an Amazon gemeldet wurden, gibt es noch keine umfassende Analyse des Problems. Es lässt sich lösen, indem eine oder beide folgenden Aktionen ausgeführt werden:
* Löschen des ".eventToken" im Alexa-Device über "deletereading"
* "FHEM-Connector"-Skill auf "alexa.amazon.de" einmal deaktivieren und dann neu verbinden

== Mögliche Probleme und Lösungen ==

Es kann vorkommen, dass Geräte zwar korrekt erkannt werden, aber das durch Alexa erkannte Kommando nicht richtig umgesetzt wird (Beispiel - mittlerweile behoben: {{Link2Forum|Topic=96766}}). Neben dem FHEM-Log gibt es noch das Logfile, welches von alexa-fhem angelegt wird.

=== Fehlersuche über die FHEM-Oberfläche ===

* alexa-fhem Logfile anschauen (Detail-Ansicht des <alexa>-Device aufrufen, klick auf '''Logfile''' oben)
* alexa-fhem im Debug-Modus aufrufen:
** -D zum alexaFHEM-params attribut hinzufügen
** Alexa-Befehl auslösen
** -D aus dem alexaFHEM-params attribut entfernen
* Die notwendigen Informationen finden sich in dem alexa-Logfile (siehe oben)

=== Fehlersuche über Kommandozeile (lies: Shell) + FHEM-Oberfläche ===

:* set <alexa> stop (FHEM-Oberfläche)
:* Auf der Kommandozeile <code>alexa-fhem -D -c /opt/fhem/alexa-fhem.cfg > debug.log</code> starten (dadurch wird die Datei debug.log erzeugt im aktuellen Verzeichnis)
:* Alexa-Befehl auslösen
:* alexa-fhem auf der Kommandozeile wieder stoppen (CTRL-C)
:* set <alexa> start (FHEM-Oberfläche)

Die Datei debug.log sollte Hinweise enthalten, wie das Problem zu lösen ist oder Dich zumindest in die richtige Richtung schieben.

Im Beispiel aus dem Forum fand sich in dem Logfile der Hinweis darauf, dass das Device mit falschen min/max-Werten unterwegs war.

=== Registrierungskey vergessen, Registrierung zurücksetzen ===

Auf der Kommandoshell:

<syntaxhighlight lang="bash" style="width:90%;">
pi@raspberrypi:~# sudo -u fhem ssh -p 58824 fhem-va.fhem.de status
Registered.
Registered on 2019-01-13T15:38:13Z.
</syntaxhighlight>

heisst, das der Vereinsserver eigentlich alles hat, was er will. Es wird kein neuer Schlüssel generiert.
Wenn Du die Situation zurücksetzen möchtest, wäre die hässliche Methode, Deinen SSH-Key zu löschen. Eleganter ist, die Registrierung auf Vereinsseite zu löschen:

<syntaxhighlight lang="bash" style="width:90%;">
pi@raspberrypi:~# sudo -u fhem ssh -p 58824 fhem-va.fhem.de unregister
Your registration has been removed
</syntaxhighlight>

löscht Deinen Schlüssel mitsamt allen dort gespeicherten Daten auf Vereinsseite. Bei Restart von alexa-fhem in FHEM-WEB wird jetzt ein neuer Registrierungskey angefordert.

== Sicherheitskonzept und Secrets ==

Um diesen Abschnitt zu verstehen, solltest Du den Abschnitt "Arbeitsweise" im Kopf haben. Einerseits ist Dir vermutlich einleuchtend, dass ein Server, der per SSH rückwärts nur ausgewählte Kommandos in den Tunnel, den Du aufgebaut hast, leitet, "irgendwie sicherer" ist. Andererseits möchte man nicht blind vertrauen.

=== SSH ===
==== SSH - macht das nichts Gefährliches? ====
SSH ist ein Veteran des Internet und entstand, um sich sicher (verschlüsselt) und schnell auf Servern einzuloggen. Schon früh wurde dabei der sogenannte "Reverse-Tunnel" implementiert: Also der vom Client (Deinem Rechner) geäußerte Wunsch: "Bitte leite mir Requests, die bei Dir, Server, auf Port xy eingehen, an meinen lokalen Port yz weiter.". Dieses Verfahren implementiert der Reverseproxy, wobei tatsächlich auf dem Server für Dich kein echter Port geöffnet wird.

Wie Dir ggf. sicher der Unix-Guru Deines Vertrauens bestätigen wird: Die Kombination
<syntaxhighlight lang="bash" style="width:50%;">
ssh -R 1234:localhost:<zufälliger port> zielserver
</syntaxhighlight>
erlaubt keine Ausführung von Shell-Kommandos auf Deinem Server, sondern einzig, dass vom SSH-Programm Verbindungen zu einem lokalen Port auf Deinem Server auf dem alexa-fhem lauscht aufgebaut werden. Du kannst also z.B. mit einem
<syntaxhighlight lang="bash" style="width:50%;">
sudo /usr/sbin/tcpdump -X -s 0 -i lo port <zufälliger port>
</syntaxhighlight>
vollständig überwachen (oder ggf. permanent aufzeichen), was auf Deinem Server von außen gesteuert passiert.

==== Wie wird bei SSH verschlüsselt? ====
Im Prinzip wie im Web auf SSL-Seiten, teils mit den gleichen Verschlüsselungsverfahren. Allerdings arbeitet SSH eher wie das im Web recht seltene Verfahren: Bei jeder Verbindung übermitteln sowohl Server wie auch Client den öffentlichen Teil ihres Schlüssels. Anders als im Web wird der Schlüssel aber nicht von einer öffentlichen Zertifizierungsstelle wie "LetsEncrypt" unterschrieben. Stattdessen entscheiden Server wie Client beim ersten Verbindungsaufbau typischerweise per manueller Frage: "Willst Du jetzt und künftig diesem Schlüssel vertrauen?" Bei der Installation wird diese Frage für Deine Seite bejaht, und fortan wird der öffentliche Schlüssel des FHEM-Servers auf Deinem Rechner gespeichert. Ab da bist Du z.B. davor sicher, dass jemand den DNS-Eintrag verbiegt oder sich in den Datenfluss Deines Providers einhängt: Ein geänderter Serverschlüssel würde bemerkt werden.
 
Soweit klar? Aus Deinem öffentlichen Schlüssel wiederum leitet der Server her: "Das ist definitiv wieder derjenige, der sich damals "registriert" hat". Und an dieser Stelle kann ich auch den ersten Teil des 3-teiligen Registrierungskeys erläutern: Die typischerweise 6-stellige Hex-Zahl am Anfang ist der Java-Hashcode Deines öffentlichen Schlüssel. Sie ist damit sozusagen Deine aus Deinem öffentlichen Schlüssel abgeleitete Benutzer-ID.

=== Die Rolle der Secrets ===
Wenn jetzt klar ist, dass die Verbindung zum Vereinsserver sicher und vertauschungsfrei funktioniert, bleiben noch 2 Probleme zu lösen:
1) Im Web bei der Skill-Aktivierung musst Du beweisen, dass Du der Mensch am Browser bist, dem der SSH-Tunnel von IP xy mit dem öffentlichen Schlüssel X gehört. Bei der automatischen Registrierung werden lokal auf Deinem Rechner zwei 64-Bit-Secrets generiert:
* Das Anmelde-Secret
* Das Bearer-Token
Beim Anmelden des SSH-Keys auf dem öffentlichen Server wird nun der Hashwert des ersten Secrets übertragen und dort in Verbindung mit Deinem öffentlichen Schlüssel gespeichert. Ein Hashwert bedeutet, dass (sofern das Verfahren, hier SHA256, funktioniert), niemand aus dem Hash das Secret zurückrechnen kann. Ein Datenbankklau auf dem Server gefährdet also nicht die Sicherheit Deines Passwortes.

Wenn Du nun beim Skill-Aktivieren den Registrierungskey eingibst, dann "sieht" der Server zum ersten Mal Dein ausgewürfeltes Secret, vergleicht es mit dem Hashwert und wird es anschließend wieder umgehend vergessen. Anhand des Hashwertes kann der Server aber entscheiden, dass Du der legitime Nutzer zum öffentlichen Schlüssel XY bist.

2) Das zweite Problem ist: Wie soll Amazon "beweisen", dass sie der legitime Aufrufer sind? Amazon erhält binnen wenigen Sekunden nach dem Klick auf "Activate Skill" den dritten Teil des Registrierungskeys als sogenanntes Bearer-Token. Zwar läuft er durch den Registrierungsserver, er wird dort, auf dem Registrierungs/Vereinsserver aber nicht gespeichert. Das Bearer-Token wird von Amazon bei allen Requests zu Deinem Server mitgesendet. Da es am Anfang zusätzlich Deine "User-ID" enthält, weiß der Vereinsserver, zu welchem SSH-Tunnel der Request zu senden ist. Aber lokal auf Deinem Rechner wird ausgewertet, ob das Token "stimmt".

== alexa-fhem Updaten bzw. "Upgraden" ==

'''Updaten einer "Connector" Installation:'''
* alexa-fhem über FHEM anhalten (Name des Alexa-Device: alexa):
:<syntaxhighlight lang="perl" style="width:50%;">set alexa stop</syntaxhighlight>

*Auf der Konsole wie anfangs bei der Installation:
:<syntaxhighlight lang="bash" style="width:50%;">sudo npm update -g alexa-fhem</syntaxhighlight>

:Manchmal hat npm Probleme mit einem Update. Dann einfach die aktuelle Version noch mal drüber Installieren:

:<syntaxhighlight lang="bash" style="width:50%;">sudo npm install -g alexa-fhem</syntaxhighlight>

*alexa-fhem über FHEM wieder starten:
:<syntaxhighlight lang="perl" style="width:50%;">set alexa start</syntaxhighlight>

'''"Upgraden von einer "Nicht-Connector" Installation (z.B. manuelle Installation per pm-Download):'''
* Daten der aktuellen Installation sichern (v.a. config.json / man weiß ja nie)
* Autostart der aktuellen alexa-fhem Installation deaktivieren:
** Bei initd: Service deaktivieren mittels: <code>sudo update-rc.d -f alexa remove</code> Vorher mittels stoppen: <code>sudo service alexa stop</code> Startscript unter /etc/init.d/ löschen.
** Bei systemd: Service deaktivieren mittels: <code>sudo systemctl disable alexa</code> Vorher mittels stoppen: <code>sudo systemctl alexa stop</code> Startscript unter /etc/systemd/system/ löschen.
* ALLE vorhandenen alexa-fhem Daten LÖSCHEN! Bleiben Dinge zurück und wird dann laut Connector installiert kann es zu Problemen kommen!
* (reboot)
* Installation von alexa-fhem laut Anleitung (Beginn dieses Wiki)
* Falls eigene Dinge von früher genutzt werden wollen/sollen (z.B. Custom Skill), dann die entsprechenden Einträge aus der gesicherten config.json in die neu angelegte alexa-fhem.cfg (zu finden unter "Edit files") übernehmen.
* Werden keine eigenen Dinge verwendet, dann kann der Port (Standard: 3000) geschlossen werden und auch die Daten unter Amazon-Developer können gelöscht werden.

== Bug- und Wunschliste ==
* Ist beim Start keine Internetverbindung vorhanden, erfolgt kein Retry -- alexa-fhem muss restartet werden (ssh_autoconfig wertet keine temporären Fehler aus)

==Weitergehende Informationen==
*[[Alexa und Mappings]]
*[[Alexa Tipps und Kniffe]]
*[[FHEM Connector for Amazon Alexa]]
[[Kategorie:HOWTOS]]
[[Kategorie:Sprachsteuerung]]

FHEM Connector für Amazon Alexa

2020-06-01T14:02:44Z

MadMax-FHEM:

{{Baustelle}}
'''Alexa FHEMlazy''' war historisch ein Fork des Original [[Alexa-Fhem|alexa-fhem]], der im Januar 2019 mit dem Original zusammengeführt wurde und nun als '''FHEM Connector''' verfügbar ist.

Er ermöglicht innerhalb von Minuten die Verknüpfung von FHEM mit einem Amazon Echo Gerät. Auch Geräte anderer Hersteller mit verbauten Mikrofonen und Alexa-Sprachassistenten-Unterstützung sollten problemlos funktionieren. Für folgende Geräte ist dies bspw. der Fall (Falls Ihr andere/weitere Gerätemodelle bzw. Hersteller in Verwendung habt, bitte hier pflegen):

* SONOS Beam und SONOS One

Gegenüber dem klassischen Ansatz ergeben sich Einschränkungen, so läuft die Software normalerweise unter dem gleichen Benutzer wie FHEM auf dem gleichen Server, und es wird z.Zt. nur der Smarthome-Skill unterstützt (die Variante, bei der die Möglichkeiten der Interaktion von Amazon festgelegt wurden).
Dafür ist weder ein Developer-Account bei Amazon, eigene Lambda- und Skillfunktionen, noch das Öffnen eines eingehenden Ports aus dem Internet nötig.
* Die Software integriert einen Installer, der die Erstkonfiguration und Anmeldung übernimmt
* Die Kommunikation zur Software auf dem heimischen Rechner und dann zu FHEM verläuft über SSH und einen vom FHEM-Verein gehosteten Server
* Funktioniert mit IPv4, IPv6, echtem Dual Stack und DS-Lite
* Als Skill bei Amazon wird der Skill "FHEM Connector" verwendet.

Der Thread im Forum zur Software ist hier: {{Link2Forum|Topic=94817}}.

{{Infobox Modul
|ModPurpose=Einfache Anbindung von FHEM an Amazon Assistent Alexa
|ModType=h
|ModCmdRef=alexa
|ModTechName=39_alexa.pm / alexa-fhem
|ModForumArea=Frontends/Sprachsteuerung
|ModOwner=gvzdus, André/ justme1968 ({{Link2FU|430|Forum}} / [[Benutzer Diskussion:Justme|Wiki]])
}}

==Einführung==

===Arbeitsweise und Datenfluss===
Vorläufig ist alexa-fhem im "FHEM Connector-Modus" ein reiner [https://developer.amazon.com/de/docs/smarthome/understand-the-smart-home-skill-api.html SmartHome-Skill].
SmartHome-Skills erhalten weder die Sprachdaten selber noch das, was Amazon in Textform verstanden hat, sondern vielmehr extrahiert Amazon aus dem verstandenen Text Anweisungen und Abfragen für Geräte, die dann an den Skill übermittelt werden. Charmant ist dabei, dass unmittelbar gefragt werden kann "Alexa, wie ist die Temperatur im Wohnzimmer?", während andere Skills zunächst explizit angesprochen werden müssen ("Alexa, frage FHEM nach der Temperatur im Wohnzimmer"). Außerdem kann der Nutzer mehrere Smarthome-Skills installieren, und die Geräte werden zu einer Gesamtmenge zusammengefasst.

Gehen wir den Datenfluss bei der konkreten Frage "Wie ist die Temperatur im Wohnzimmer?" durch:
* Alexa hat bei der Skillinstallation gelernt, dass "FHEM Connector" bei Dir einen Thermostaten im Raum Wohnzimmer kennt. Dadurch wird bei der Sprachanalyse von "Alexa Voice Service" in der Cloud erkannt, dass eine Abfrage an "FHEM Connector" erfolgversprechend ist.
* Zunächst wird die zentrale "Lambda-Funktion" von "FHEM Connector" aufgerufen. Die Funktion leitet aber im Kern nur den Request unverändert an den vom Verein bereitgestellten Server weiter. Im Request enthalten ist ein Token, das sogenannte "Bearer-Token".
* Der "Vereinsserver" prüft anhand dieses Tokens, ob es überhaupt bekannt ist, und zu welchem Nutzer es gehört. Ist dieser Nutzer verbunden, wird der Request wiederum quasi unverändert an den Nutzer weitergeleitet.
* Diese Weiterleitung passiert über einen sogenannten SSH-Reverse-Tunnel, der von Deiner Seite und der Software auf dem FHEM-Tunnel automatisch aufgebaut wird.
* Auf Deiner Seite läuft die eigentliche Software, und zwar unter nodeJS. nodeJS ist ein Javascript ausführender Miniserver, der lokal auf einem Zufallsport auf Requests "lauscht". In der Original-Version [[Alexa-Fhem|Alexa FHEM]] kommen die Requests aus dem Internet (hoffentlich von der eigenen Lambda-Funktion), hier bei "FHEM Connector" kommen sie ausschließlich aus dem SSH-Tunnel von lokal.
* Die Software validiert nun diesen Request anhand des Bearer-Tokens. Konkret wird dabei das bei der Installation generierte Token, dass bei der Skill-Aktivierung an Amazon übertragen wurde, mit dem lokal gespeicherten Wert verglichen. Stimmt das Token, wird der Befehl verarbeitet, üblicherweise wird hierbei ein Aufruf an die Webschnittstelle von FHEM abgesetzt.
* FHEM führt den Befehl aus

Hört sich langsam und kompliziert an? Kompliziert: Okay. Langsam eher nicht, in etlichen Fällen liegt die Gesamtantwortszeit unter 200 ms.

Soweit ein erster Überblick über die Datenflüsse. Im Abschnitt Sicherheit ist das Konzept der Absicherung deutlich genauer und ausführlicher beschrieben.

==Installation==

Du wirst bei der Installation zuerst auf der Kommandozeile auf Deinem Raspberry (o.ä.) unterwegs sein, anschließend im Webfrontend von FHEM, und zum Schluss auf der Alexa-Konsole im Web.

===node.js installieren===

Ab Jessy liegt NodeJS bereits in einer ausreichend aktuellen Version vor (Stretch und Buster funktionieren ebenfalls). Mit

<syntaxhighlight lang="bash" style="width:50%;">
sudo apt-get install nodejs npm
</syntaxhighlight>

kannst Du es installieren. Mit
<syntaxhighlight lang="bash" style="width:50%;">
node --version
</syntaxhighlight>

erfährst Du die aktuelle Version - wenn hier etwas mit "8" oder höher vorneweg erscheint, ist alles gut.
Ansonsten suche Dir bitte eine Anleitung im Web, wie Du NodeJS auf Deinem System auf einen aktuellen Stand bringen kannst.

=== Alexa-FHEM installieren ===

Nun installieren wir Alexa-fhem aus dem offiziellen Repository:

<syntaxhighlight lang="bash" style="width:50%;">
sudo npm install -g alexa-fhem
</syntaxhighlight>

Der Vorgang benötigt etwas Zeit.

=== Alexa-FHEM aktivieren ===

Wechsele jetzt in FHEM-Web!

Wichtig ist, dass das Alexa-Modul in der Version ab Januar 2019 vorliegt. Dafür bitte einmal FHEM aktualisieren:
Speichern der Config nicht vergessen, und

<syntaxhighlight lang="bash" style="width:50%;">
update
shutdown restart
</syntaxhighlight>

Alles, was jetzt noch nötig ist, ist das Anlegen eines Alexa-Devices. Gib dafür in der FHEM-Web-Kommandozeile

<syntaxhighlight lang="bash" style="width:50%;">
define alexa alexa
</syntaxhighlight>

an. Nun läuft, während Du bereits das neu angelegte Alexa-Devices siehst, ein komplexer Prozess im Hintergrund:

* Falls noch kein SSH-Key für den Benutzer, unter dem FHEM läuft, existiert, wird einer generiert
* Es wird ein Secret-Key im Prozess generiert, dass den Server nicht verlässt, und der Skillanmeldung dient.
* Du wirst auf dem Server "va-fhem.fhem.de" des FHEM-Vereins mit dem SSH-Key angemeldet, und der Hash-Wert Deines Secret-Key dort abgelegt.

Und wenn Du diese Sätze gelesen hast, sollte inzwischen sich das Alexa-Device in FHEM-Web aktualisiert haben, und
ungefähr so aussehen:

[[Datei:Alexa-Device-2.png|800px]]

Neben dem Status für alexa-fhem und der Proxyverbindung ist wichtig, dass diese beiden Zeilen beim Reload aufgetaucht sind:

<syntaxhighlight lang="bash" style="width:90%;">
alexaFHEM.bearerToken crypt:...
alexaFHEM.skillRegKey crypt:...
</syntaxhighlight>

Ja, und diesen Schlüssel benötigst Du wirklich! Also am besten schon einmal mit

<syntaxhighlight lang="bash" style="width:90%;">
get <alexa> proxyKey
</syntaxhighlight>

in Klartext anzeigen lassen und in ein Editor-Fenster dauerhaft wegsichern.

Jetzt solltest Du Dein Alexa-Device nicht mehr löschen, denn das im Reading angezeigte "bearerToken" zu löschen bedeutet, dass die Software die Zugriffe von nicht mehr überprüfen kann und keine Kommandos mehr funktionieren. In diesem Fall hilft nur die Neuinstallation des Skills.

==== Fehler bei der Aktivierung ====

Während kompliziertere Fehlerfälle im Abschnitt "Mögliche Probleme und Lösungen" behandelt werden, hier häufige Fälle, warum die kryptischen Zeilen nicht auftauchen:

* Zuerst bitte einfach einmal die Seite neu laden.

===== 401: Authorization Required =====

Wenn Du FHEM-Web mit einem User/Passwort-Schutz versehen hast, wirst du folgende Fehlermeldung sehen:

<syntaxhighlight lang="bash" style="width:90%;">
alexaFHEM stopped; failed to connect to fhem: 401: Authorization Required
</syntaxhighlight>

In der Regel musst du die Angaben User/Passwort noch einmal explizit setzen. Im Attribute-Abschnitt "alexaFHEM-auth" auswählen, User/Passwort mit ":" getrennt angeben und "attr" anklicken. alexa-fhem wird automatisch neu gestartet. Hier das Ganze in der Text-Variante:

<syntaxhighlight lang="bash" style="width:90%;">
attr alexa alexaFHEM-auth user:pass
</syntaxhighlight>

===== Permission denied =====

Wenn du folgende Fehlermeldungen im Alexa Logfile siehst, wurde das Verzeichnis "/opt/fhem/.ssh/" von dir bei der Arbeit mit "root" oder "sudo" mit den falschen Berechtigungen versehen:

<syntaxhighlight lang="bash" style="width:90%;">
[2019-7-25 11:59:12] sshautoconf: aborted with ssh-keygen returned error - key_save_private: Permission denied
[2019-7-25 11:59:12] *** SSH: proxy configuration failed: ssh-keygen returned error - key_save_private: Permission denied
</syntaxhighlight>

Prüfen kannst du die Berechtigungen mit folgendem Befehl auf der Shell-Konsole:

<syntaxhighlight lang="bash" style="width:90%;">
ls -l /opt/fhem/.ssh
</syntaxhighlight>

Du solltest dann folgende Ausgabe erhalten:

<syntaxhighlight lang="bash" style="width:90%;">
insgesamt 12
-rw------- 1 fhem dialout 1675 Jul 12 13:10 id_rsa
-rw-r--r-- 1 fhem dialout 391 Jul 12 13:10 id_rsa.pub
-rw-r--r-- 1 fhem dialout 884 Jul 12 13:10 known_hosts
</syntaxhighlight>

Steht in der Ausgabe nicht "fhem dialout" (dein fhem User), sondern bspw. "root root", dann bspw. mit folgendem Befehl an deinen fhem User anpassen:

<syntaxhighlight lang="bash" style="width:90%;">
chown fhem:dialout /opt/fhem/.ssh
</syntaxhighlight>

Mit dem ersten Befehl "ls -l ..." kannst du dann nochmal prüfen, ob die Berechtigungen korrekt übernommen wurden.

===== weitere Prüfungen =====

Hast Du noch die Shell-Konsole offen? Dann prüfe bitte noch einmal auf der Konsole, ob nun zwei Prozesse laufen:

<syntaxhighlight lang="bash" style="width:50%;">
ps -ef | egrep '(alexa|ssh)'
</syntaxhighlight>

sollte Dir idealerweise so etwas anzeigen:
<syntaxhighlight lang="bash" style="width:90%;">
fhem 31322 1 99 13:56 ? 00:00:03 alexa
fhem 31332 31322 8 13:56 ? 00:00:00 /usr/bin/ssh -R 1234:127.0.0.1:<zufälliger port> -oServerAliveInterval=90 -p 58824 fhem-va.fhem.de
</syntaxhighlight>

"alexa" ist dabei der Node-JS-Prozess, der ssh-Prozess ist die aufgebaute Verbindung zum Vereinsserver.

Wenn Du diese Prozesse '''nicht''' siehst oder das Alexa-Device keinen Registrierungskey anzeigt, dann ist leider der Start nicht glatt verlaufen.

Im Logfile (über den link <code>Logfile</code> in der Detail-Ansicht über <code>set</code>, oder über den Namen bei ''currentlogfile'' in den Internals) findest Du idealerweise selber Hinweise, wo es hakt, oder kannst im Forum nachfragen.

=== Geräte im FHEM-Webfrontend zuweisen ===
Um das Aha-Erlebnis zu vergrößern, ist jetzt ein guter Zeitpunkt, 1 oder besser mind. 2 Geräte für den Alexa-Dienst zuzuweisen. Von Haus aus wird keines Deiner FHEM-Geräte automatisch Alexa zugewiesen!

Wähle die Geräte aus, rufe sie auf und setze das Attribut "alexaName". Hierbei in Kürze nur der Hinweis:
* Keine Angst vor Leerzeichen und Umlauten, funktioniert.
* Große Angst vor Rechtschreibfehlern (Terrasse, Rollladen) oder komplizierten Wörtern "handgebastelte Martinslaterne im Kinderzimmer Iphigenie-Chantal".
* Mehrere Namen für dasselbe Gerät/Device in fhem werden unterstützt. Mehrere Namen werden durch Strichpunkt getrennt.
* Das Attribut "alexaRoom" ist NUR FÜR DEN CUSTOM SKILL relevant. Ausnahme: structure und LightScene Devices, siehe: [[FHEM_Connector_f%C3%BCr_Amazon_Alexa#Was_geht_alles_.3F]].

Lade die Geräte neu in die Software, indem Du <code>set <alexa> restart</code> ausführst!
[[Datei:HowToSet alexaName.png|alternativtext=How to set alexaName|ohne|mini|Wie setzt man das Attribut alexaName]]

'''Anmerkungen (weil oft gestellte Fragen im Forum) bzgl. Erkennung von Geräten:'''

* Wichtig ist, dass die Filtereinstellung in der alexa-fhem.cfg (zu finden unter "Edit Files") passt.
Das, was dort eingetragen ist (Standard: alexaName=..* / also es ist ein alexaName vergeben) auch an den entsprechenden Devices in fhem vorhanden ist.
Stimmt das nicht überein, kann alexa-fhem keine Devices von fhem abfragen/finden.
Ob der Filter entsprechend funktioniert kann man wie folgt testen: ''list Filtereinstellung'' beispiel mit Standardfilter: ''list alexaName=..*''

* Hat alexa-fhem per Filter Devices aus fhem "gefunden", geht es weiter mit der "Erkennung". Also um welches Device (Typ und "Fähigkeiten") handelt es sich. Dazu gilt folgendes:
** sind entsprechende Readings beim Device vorhanden (z.B. temperature, state mit on/off, ...) erkennt das alexa-fhem automatisch. Die Liste der automatisch erkannten Readings wächst ständig. Daher erst mal schauen ob das Device bereits entsprechend erkannt (typisiert) wurde. Das kann durch prüfen des alexa-fhem-Logs geschehen (NICHT fhem-log!).
** sind entsprechende "set-Befehle" erkennbar (oft auch durch Readings). Also ist beispielsweise (wie beim Dummy nötig) ein ''setList'' mit entsprechenden Einträgen vorhanden oder entsprechende Readings, z.B. desired-temp zum Stellen der Temperatur etc.
** wird das Device nicht richtig oder "unvollständig" erkannt helfen folgende Attribute:
*** genericDeviceType: hiermit kann alexa-fhem in die gewünschte Richtung "geschubbst" werden. Anmerkung: man kann nicht alles erzwingen, Readings bzw. set-Befehle müssen passen (oder per homebridgeMapping passend gemacht werden). Wenn ein genericDeviceType nicht per "Drop-Down" erscheint, dann kann er auch (wenn bekannt) einfach per WEB-cmd eingegeben werden: ''attr Devicename genericDeviceType media''
*** homebridgeMapping: hierdurch kann alexa-fhem bei der Erkennung von Zuständen und möglichen Einstellungen (also WAS kann das Device) unterstützt werden. Mittels homebridgeMapping können vorhandene Readings (Zustände) auf für alexa-fhem bekannte Zustände gemappt werden. Ebenso können damit Standard-fhem-Kommandos von alexa-fhem auf Device-spezifische gemappt werden. Beispiel: on/off auf Ein/Aus (falls das Device statt on/off eben ein Ein/Aus erwartet). Zum Beispiel: <syntaxhighlight lang="bash" style="width:50%;">
attr <thermostat> homebridgeMapping TargetTemperature=target::target,minValue=18,maxValue=25,minStep=0.5 CurrentTemperature=myTemp:temperature
</syntaxhighlight> [https://github.com/justme-1968/homebridge-fhem/blob/master/README.md weitere Beispiele]

'''Mehrere Namen für dasselbe Gerät/Device in fhem ist möglich. Die Namen werden durch Strichpunkt getrennt.'''
Beispiel:
<code>attr dmLampe alexaName Lichtkuppel;Lichtkugel</code>

'''Anmerkung bzgl. genericDeviceType und homebridgeMapping:''' 
* diese Attribute werden von verschiedenen "Sprachsteuerungsmodulen" in fhem verwendet (homebridge [dort wurde es "erfunden"], alexa-fhem, gassistant, ...). Daher ist nicht jedes Mapping für alle "Dienste" verwendbar. Ausprobieren schadet aber nicht.
* ebenso kann man mit diesen Attributen (homebridgeMapping wird gerne so "missbraucht") nichts erzwingen, was seitens Amazon/Alexa nicht unterstützt bzw. verstanden wird! D.h. zunächst ist zu prüfen, ob ein bestimmter (gewünschter) Sprachbefehl seitens Amazon/Alexa unterstützt wird! Aktuelles Beispiel (Stand Jan 2020): "Alexa, fahre den Rollo hoch/runter". Da ist Amazon/Alexa gerade dabei etwas zu tun. Bislang wird das nicht unterstützt, also ist das auch mit einem entsprechenden homebridgeMapping nicht zu erzwingen! Was unterstützt wird kann man bei Amazon nachlesen: [https://developer.amazon.com/es-ES/docs/alexa/device-apis/list-of-interfaces.html]

== Finale: Skill verknüpfen ==
Suche im WebFrontend oder der Alexa-App den Skill "FHEM Connector". Für nicht-Mac/iOS Anwerder empfiehlt das WebFrontend (https://alexa.amazon.de) statt die App, damit Du den Anmeldeschlüssel auch bequem kopieren kannst.

Wenn du noch nicht bei Amazon angemeldet bist, erwartet Amazon zunächst, dass Du Dich normal bei Amazon anmeldest.

Sobald Du "FHEM Connector" aktivierst, öffnet sich ein Browser-Tab mit folgender Maske: 
[[Datei:FHEMlazy_login.png|240px]]

Hier kopierst Du Deinen Anmeldeschlüssel (im Klartext!) hinein und klickst auf Check. Als glücklicher Mensch ist auf der folgenden Statusseite alles grün: 
[[Datei:FHEMlazy_check.png|240px]]

Im Einzelnen wird hier geprüft, ob Du per SSH verbunden bist (und auch Deine IP zur Sicherheit angezeigt), ob der Reverse-Tunnel steht, ob nodeJS erreichbar ist und wie viele Geräte Alexa gleich finden sollte (in meinem Fall 22).

Sollte etwas nicht grün sein und Du eine Idee zum Fixen haben, kannst Du mit "Retry" neue Versuche auslösen.

Ist alles okay, klicke rechts den Button "Activate Skill". Du springst damit wieder zurück zu Amazon, die Dir hoffentlich zur erfolgreichen Verknüpfung gratulieren.

Amazon möchte nun unmittelbar die Gerätesuche starten, und unter SmartHome-Geräte sollten diese nun auftauchen.

== Was geht alles ? ==

* Geräte, die sich ein- und ausschalten lassen:
** Automatisch: Müssen <code>set on</code> und <code>set off</code> Kommandos haben
** dummys müssen <code>setList</code> mit on und off haben
** Über <code>genericDeviceType</code> switch bzw. light kann bestimmt werden ob es in alexa als Schalter oder Licht behandelt wird.
** Wenn die Set-Kommandos im FHEM Device anders benannt sind: homebridgeMapping On:cmdOn=<ein>,cmdOff=<aus> setzen
** Kommandos:
***Alexa, schalte <name> ein/aus
***Alexa, Licht an/aus
***Alexa, schalte <gruppe> ein/aus
* Geräte, die eine Temperatur messen
** Automatisch: Es muss ein Reading <code>temperature</code> geben
** Über <code>genericDeviceType</code> thermometer
** Sonst: homebridgeMapping CurrentTemperature:reading=<reading>

* Geräte, deren Helligkeit sich ändern lässt
** Automatisch: wenn <code>dim</code> oder <code>pct</code> Kommandos erkannt werden
** Über <code>genericDeviceType</code> light
** Über homebridgeMapping: Wenn <code>helligkeit</code> das Reading für die aktuelle Helligkeit enthält und die Helligkeit mit <code>set <device> prozent xxx</code> gesetzt wird, sieht das homebridgeMapping wie folgt aus: homebridgeMapping Brightness=helligkeit::prozent,minValue=0,maxValue=<maximalwert>
** Kommandos:
*** Alexa, mache <name> heller/dunkler
*** Alexa, Licht heller/dunkler
* Geräte, deren Farbe sich ändern lässt
** ...

* Geräte, deren Farbtemperatur sich ändern lässt
** ...

* Geräte, bei denen sich eine Lautstärke einstellen lässt
** ...

* Geräte, bei denen sich ein prozentualer Wert einstellen lässt
** Automatisch: wenn <code>dim</code> oder <code>pct</code> Kommandos erkannt werden
** ...

* elektrische Türschlösser
** <code>genericDeviceType</code>: lock
** homebridgeMapping mit LockCurrentState und LockTargetState

* Thermostate
** Über <code>genericDeviceType</code> thermostate
** ...

* structure Devices aus FHEM (ab alexa-fhem version 0.5.7)
** können mit <code>genericDeviceType</code> scene als Szene eingebunden werden
** über <code>alexaRoom</code> kann der name um einen Ort ergänzt werden
** Szenen aus einer structure lassen sich ein- und ausschalten
** Wichtig:
*** Ein Skill darf nur 12 Szenen automatisch erkennen und einbinden.

* LightScene Devices aus FHEM (ab alexa-fhem version 0.5.8)
** können mit <code>genericDeviceType</code> scene als Szenen eingebunden werden
** über <code>alexaRoom</code> kann der name um einen Ort ergänzt werden
** Szenen aus einer LightScene lassen sich nur einschalten
** Wichtig:
*** Ein Skill darf nur 12 Szenen automatisch erkennen und einbinden.

* Geräte, deren Kanal sich umschalten lässt (ab alexa-fhem version 0.5.13)
** Über <code>genericDeviceType</code> media
** homebridgeMapping ChannelController:reading=<reading>,cmd=<cmd>
** Erlaubte Werte siehe hier: https://developer.amazon.com/de/docs/device-apis/alexa-channelcontroller.html#changechannel
** ...

* Geräte, deren Playback status sich schalten lässt (ab alexa-fhem version 0.5.13)
** Über <code>genericDeviceType</code> media
** homebridgeMapping PlaybackController:playback,values=Play;Pause;Stop;Previous;Next
** Erlaubte Werte siehe hier: https://developer.amazon.com/de/docs/device-apis/alexa-playbackcontroller.html#discovery
** ...

* Geräte, deren Eingang sich umschalten lässt (ab alexa-fhem version 0.5.13)
** Über <code>genericDeviceType</code> media
** homebridgeMapping InputController:reading=<reading>,cmd=<cmd>,values=HDMI+1;HDMI+2;XBOX
** Erlaubte Werte siehe hier: https://developer.amazon.com/de/docs/device-apis/alexa-property-schemas.html#input
** ...

* Kontaktsensoren (ab alexa-fhem version 0.5.15)
** Über <code>genericDeviceType</code> contact
** homebridgeMapping ContactSensorState:reading=<reading> oder CurrentDoorState:reading=<reading>
** Die Anzeige in der Alexa-App funktioniert sofort, die Abfrage per Sprache erst ab Version 0.5.27.

* Geräte, deren Lautstärke sich ändern lässt (ab alexa-fhem version 0.5.24)
** Über <code>genericDeviceType</code> speaker
** Automatisch: es muss ein Reading <code>volume</code> und/oder <code>mute</code> geben
** homebridgeMapping Volume:reading=<reading>,cmd=<cmd> Mute:reading=<reading>,cmd=<cmd>
** ...

* Geräte, die sich ein- (und optional) ausschalten lassen als Szene (ab alexa-fhem version 0.5.26)
** Über <code>genericDeviceType</code> scene
** Automatisch: Müssen <code>set on</code> und <code>set off</code> Kommandos haben
** homebridgeMapping On:reading=<reading>,cmdOn=<cmd>[,cmdOff=<cmd>]
** Hinweis: Fehlende Kommandos lassen sich mit cmdalias erzeugen
** Wichtig:
*** Ein Skill darf nur 12 Szenen automatisch erkennen und einbinden.
* Rollläden. Lange ein Problemthema, das nur mit "Schalte auf 0%, schalte auf 100% lief". Wichtig: "alexa-fhem" ab Version 0.5.39 einsetzen. GenericDevice-Type auf "blind" setzen. Nach Restart von alexa-fhem und neuer Gerätesuche sollte folgendes funktionieren:
** "..., öffne <Name> ganz"
** "..., schließe <Name> komplett"
** "hoch" und "runter" (ohne "ganz" oder "komplett") schalten jeweils nur einen bestimmten Prozentsatz hoch oder runter. Dieser kann mit <code>attr <name> homebridgeMapping TargetPosition:minStep=<wert></code>geändert werden. Aber Achtung: In diesem Intervall kann dann auch nur noch ein absoluter Prozentwert per Sprache oder Slider eingestellt werden! Bei z.B. 25% würden 13% zu 25% aufgerundet, 12% zu 0% abgerundet werden.
* Kontaktsensoren (ab alexa-fhem version 0.5.47)
** Automatisch wenn ein Reading <code>motion</code> vorhanden ist oder es sich um einen Zigbee bewgungsmelder an einer HUE oder deCONZ Bridge handelt
** Über <code>genericDeviceType</code> MotionSensor
** homebridgeMapping MotionDetected:reading=<reading>,values=<wert für bewgung>:1;<wert für keine bewegung>:0

* Alarmmelder (noch nicht in Deutschland):
** genericDeviceType Security
** homebridgeMapping Alarm=<reading>[,type=[fireAlarm|waterAlarm|burglaryAlarm|carbonMonoxideAlarm]]
** wenn der type nicht angegeben wird ist fireAlarm der default
** automatisch werden 0, ok und alles was mit no anfängt als OK erkannt. alles andere gilt als ALARM.

Es werden noch einige andere häufig verwendete Geräte (Homematic, hue,...) automatisch erkannt.

to be continued ...

In der [https://developer.amazon.com/docs/device-apis/list-of-interfaces.html List of Capability Interfaces] bei Amazon kann man sehen, welche Möglichkeiten das Smart Home Skill API aktuell in einzelnen Ländern bietet. Leider ohne die jeweiligen landessprachlichen Kommandos.

=== Aktiv Routinen starten ===
Routinen (eine Funktionalität, die rein - genauso wie "Räume" - bei Amazon liegt und nicht von FHEM Connector beeinflusst wird) waren lange die ewige Antwort auf die Frage: "Meine Frau möchte aber '''Öffne Rollläden''<nowiki/>' sagen": In der Alexa-App gibt es im Menü den Punkt "Routinen", und hier lässt sich eine gewisse Anzahl von Aktionen (unter optionalen Bedingungen) an ein Sprachkommando knüpfen.

Neu: Routinen können inzwischen auch von Skills getriggert werden, und seit Version 0.5.47 (Februar 2020) auch von FHEM Connector. Das braucht niemand, um die Rollläden hochzufahren, denn das kann FHEM ja selber, aber um z.B. eine Ansage auf einem Alexa-Gerät zu triggern. Dafür gibt es auch das FHEM-Modul "echodevice", aber es erfordert ein paar Klimmzüge. Mit dem aktiven Triggern von Routinen kann FHEM auslösen, dass Alexa ungefragt (!) Dinge wie

''"Die Temperatur in der Tiefkühltruhe hat -16 Grad überschritten"''

in den Raum sagt. Also eine Alternative bzw. Ergänzung zu Alarmen / Erinnerungen per Telegram o.ä.

'''Vorgeschichte''':

Die Smarthome-Skill-API von Amazon sah schon lange das "proactiveReporting" vor: Also z.B. die gemessene Temperatur nicht erst auf Anfrage hin zu übermitteln, sondern laufend aktiv zu pushen. Aber warum Daten an Amazon senden, wenn es dafür keinen Mehrwert gibt? Beim Öffnen z.B. des Thermostaten in der Alexa-App kommen ohnehin laufend Statusabfragen. Warum also einen Datenpool bei Amazon über die Haustemperatur aufbauen und Änderungen pushen, wenn es keinen Mehrwert dafür gibt?

Inzwischen lassen sich (reale oder vermeintliche) Änderungen von ''Bewegungssensoren'' und ''Fensterkontakten'' als Startbedingung an Alexa-Routinen koppeln. Man kann in der Alexa-App (ggf. fiktive) Öffnen eines Fensterkontaktes an das Aufsagen eines freien Textes durch die Hausbutlerin knüpfen.

'''Umsetzung''':
* Jedes Alexa-Device, dessen Status aktiv zu Amazon gepusht werden soll, im Attribut "alexaProactiveEvents" mit einer "1" versehen. Per Default wird ''kein'' Gerät laufend aktiv zu Amazon gepusht!
* das geänderte Device einmal zu Amazon pushen "set <alexa> add <device>" (oder 'Alexa, suche neue Geräte' murmeln)
* Das Gerät sollte jetzt beim Anlegen einer neuen Routine ("Neue Routine", "Wenn Folgendes passiert", "Smart Home") als möglicher Triggerpunkt erscheinen.

==== Dummygeräte: ====
Ein Dummydevice sollte einen Kontaktschalter oder Bewegungssensor simulieren, um dann in FHEM eine beliebige Bedingung als Trigger zu definieren, und eine freie Ansage in Alexa als Routine zu definieren. Hier ein Beispiel:

<syntaxhighlight lang="bash" style="width:90%;">
define voicetrigger1 dummy
attr voicetrigger1 alexaName Trigger 1
attr voicetrigger1 alexaProactiveEvents 1
attr voicetrigger1 genericDeviceType contact
attr voicetrigger1 homebridgeMapping ContactSensorState=state,values=closed:CONTACT_DETECTED;;open:CONTACT_NOT_DETECTED
attr voicetrigger1 readingList 0:closed 1:open
attr voicetrigger1 setList closed open

set alexa add voicetrigger1
set alexa restart
</syntaxhighlight>

'''Fehlersuche:'''

Der Push setzt ein intaktes Push-Token voraus. Sollte im Alexa-Logfile Folgendes erscheinen:

<code>failed to refresh token: invalid_grant: 'The request has an invalid grant parameter : refresh_token'</code>

so ist das Push-Token nicht aktuell. Weil die Auswirkung lange nur war, dass Geräteänderungen nicht aktiv an Amazon gemeldet wurden, gibt es noch keine umfassende Analyse des Problems. Es lässt sich lösen, indem eine oder beide folgenden Aktionen ausgeführt werden:
* Löschen des ".eventToken" im Alexa-Device über "deletereading"
* "FHEM-Connector"-Skill auf "alexa.amazon.de" einmal deaktivieren und dann neu verbinden

== Mögliche Probleme und Lösungen ==

Es kann vorkommen, dass Geräte zwar korrekt erkannt werden, aber das durch Alexa erkannte Kommando nicht richtig umgesetzt wird (Beispiel - mittlerweile behoben: {{Link2Forum|Topic=96766}}). Neben dem FHEM-Log gibt es noch das Logfile, welches von alexa-fhem angelegt wird.

=== Fehlersuche über die FHEM-Oberfläche ===

* alexa-fhem Logfile anschauen (Detail-Ansicht des <alexa>-Device aufrufen, klick auf '''Logfile''' oben)
* alexa-fhem im Debug-Modus aufrufen:
** -D zum alexaFHEM-params attribut hinzufügen
** Alexa-Befehl auslösen
** -D aus dem alexaFHEM-params attribut entfernen
* Die notwendigen Informationen finden sich in dem alexa-Logfile (siehe oben)

=== Fehlersuche über Kommandozeile (lies: Shell) + FHEM-Oberfläche ===

:* set <alexa> stop (FHEM-Oberfläche)
:* Auf der Kommandozeile <code>alexa-fhem -D -c /opt/fhem/alexa-fhem.cfg > debug.log</code> starten (dadurch wird die Datei debug.log erzeugt im aktuellen Verzeichnis)
:* Alexa-Befehl auslösen
:* alexa-fhem auf der Kommandozeile wieder stoppen (CTRL-C)
:* set <alexa> start (FHEM-Oberfläche)

Die Datei debug.log sollte Hinweise enthalten, wie das Problem zu lösen ist oder Dich zumindest in die richtige Richtung schieben.

Im Beispiel aus dem Forum fand sich in dem Logfile der Hinweis darauf, dass das Device mit falschen min/max-Werten unterwegs war.

=== Registrierungskey vergessen, Registrierung zurücksetzen ===

Auf der Kommandoshell:

<syntaxhighlight lang="bash" style="width:90%;">
pi@raspberrypi:~# sudo -u fhem ssh -p 58824 fhem-va.fhem.de status
Registered.
Registered on 2019-01-13T15:38:13Z.
</syntaxhighlight>

heisst, das der Vereinsserver eigentlich alles hat, was er will. Es wird kein neuer Schlüssel generiert.
Wenn Du die Situation zurücksetzen möchtest, wäre die hässliche Methode, Deinen SSH-Key zu löschen. Eleganter ist, die Registrierung auf Vereinsseite zu löschen:

<syntaxhighlight lang="bash" style="width:90%;">
pi@raspberrypi:~# sudo -u fhem ssh -p 58824 fhem-va.fhem.de unregister
Your registration has been removed
</syntaxhighlight>

löscht Deinen Schlüssel mitsamt allen dort gespeicherten Daten auf Vereinsseite. Bei Restart von alexa-fhem in FHEM-WEB wird jetzt ein neuer Registrierungskey angefordert.

== Sicherheitskonzept und Secrets ==

Um diesen Abschnitt zu verstehen, solltest Du den Abschnitt "Arbeitsweise" im Kopf haben. Einerseits ist Dir vermutlich einleuchtend, dass ein Server, der per SSH rückwärts nur ausgewählte Kommandos in den Tunnel, den Du aufgebaut hast, leitet, "irgendwie sicherer" ist. Andererseits möchte man nicht blind vertrauen.

=== SSH ===
==== SSH - macht das nichts Gefährliches? ====
SSH ist ein Veteran des Internet und entstand, um sich sicher (verschlüsselt) und schnell auf Servern einzuloggen. Schon früh wurde dabei der sogenannte "Reverse-Tunnel" implementiert: Also der vom Client (Deinem Rechner) geäußerte Wunsch: "Bitte leite mir Requests, die bei Dir, Server, auf Port xy eingehen, an meinen lokalen Port yz weiter.". Dieses Verfahren implementiert der Reverseproxy, wobei tatsächlich auf dem Server für Dich kein echter Port geöffnet wird.

Wie Dir ggf. sicher der Unix-Guru Deines Vertrauens bestätigen wird: Die Kombination
<syntaxhighlight lang="bash" style="width:50%;">
ssh -R 1234:localhost:<zufälliger port> zielserver
</syntaxhighlight>
erlaubt keine Ausführung von Shell-Kommandos auf Deinem Server, sondern einzig, dass vom SSH-Programm Verbindungen zu einem lokalen Port auf Deinem Server auf dem alexa-fhem lauscht aufgebaut werden. Du kannst also z.B. mit einem
<syntaxhighlight lang="bash" style="width:50%;">
sudo /usr/sbin/tcpdump -X -s 0 -i lo port <zufälliger port>
</syntaxhighlight>
vollständig überwachen (oder ggf. permanent aufzeichen), was auf Deinem Server von außen gesteuert passiert.

==== Wie wird bei SSH verschlüsselt? ====
Im Prinzip wie im Web auf SSL-Seiten, teils mit den gleichen Verschlüsselungsverfahren. Allerdings arbeitet SSH eher wie das im Web recht seltene Verfahren: Bei jeder Verbindung übermitteln sowohl Server wie auch Client den öffentlichen Teil ihres Schlüssels. Anders als im Web wird der Schlüssel aber nicht von einer öffentlichen Zertifizierungsstelle wie "LetsEncrypt" unterschrieben. Stattdessen entscheiden Server wie Client beim ersten Verbindungsaufbau typischerweise per manueller Frage: "Willst Du jetzt und künftig diesem Schlüssel vertrauen?" Bei der Installation wird diese Frage für Deine Seite bejaht, und fortan wird der öffentliche Schlüssel des FHEM-Servers auf Deinem Rechner gespeichert. Ab da bist Du z.B. davor sicher, dass jemand den DNS-Eintrag verbiegt oder sich in den Datenfluss Deines Providers einhängt: Ein geänderter Serverschlüssel würde bemerkt werden.
 
Soweit klar? Aus Deinem öffentlichen Schlüssel wiederum leitet der Server her: "Das ist definitiv wieder derjenige, der sich damals "registriert" hat". Und an dieser Stelle kann ich auch den ersten Teil des 3-teiligen Registrierungskeys erläutern: Die typischerweise 6-stellige Hex-Zahl am Anfang ist der Java-Hashcode Deines öffentlichen Schlüssel. Sie ist damit sozusagen Deine aus Deinem öffentlichen Schlüssel abgeleitete Benutzer-ID.

=== Die Rolle der Secrets ===
Wenn jetzt klar ist, dass die Verbindung zum Vereinsserver sicher und vertauschungsfrei funktioniert, bleiben noch 2 Probleme zu lösen:
1) Im Web bei der Skill-Aktivierung musst Du beweisen, dass Du der Mensch am Browser bist, dem der SSH-Tunnel von IP xy mit dem öffentlichen Schlüssel X gehört. Bei der automatischen Registrierung werden lokal auf Deinem Rechner zwei 64-Bit-Secrets generiert:
* Das Anmelde-Secret
* Das Bearer-Token
Beim Anmelden des SSH-Keys auf dem öffentlichen Server wird nun der Hashwert des ersten Secrets übertragen und dort in Verbindung mit Deinem öffentlichen Schlüssel gespeichert. Ein Hashwert bedeutet, dass (sofern das Verfahren, hier SHA256, funktioniert), niemand aus dem Hash das Secret zurückrechnen kann. Ein Datenbankklau auf dem Server gefährdet also nicht die Sicherheit Deines Passwortes.

Wenn Du nun beim Skill-Aktivieren den Registrierungskey eingibst, dann "sieht" der Server zum ersten Mal Dein ausgewürfeltes Secret, vergleicht es mit dem Hashwert und wird es anschließend wieder umgehend vergessen. Anhand des Hashwertes kann der Server aber entscheiden, dass Du der legitime Nutzer zum öffentlichen Schlüssel XY bist.

2) Das zweite Problem ist: Wie soll Amazon "beweisen", dass sie der legitime Aufrufer sind? Amazon erhält binnen wenigen Sekunden nach dem Klick auf "Activate Skill" den dritten Teil des Registrierungskeys als sogenanntes Bearer-Token. Zwar läuft er durch den Registrierungsserver, er wird dort, auf dem Registrierungs/Vereinsserver aber nicht gespeichert. Das Bearer-Token wird von Amazon bei allen Requests zu Deinem Server mitgesendet. Da es am Anfang zusätzlich Deine "User-ID" enthält, weiß der Vereinsserver, zu welchem SSH-Tunnel der Request zu senden ist. Aber lokal auf Deinem Rechner wird ausgewertet, ob das Token "stimmt".

== alexa-fhem Updaten bzw. "Upgraden" ==

'''Updaten einer "Connector" Installation:'''
* alexa-fhem über FHEM anhalten (Name des Alexa-Device: alexa):
:<syntaxhighlight lang="perl" style="width:50%;">set alexa stop</syntaxhighlight>

*Auf der Konsole wie anfangs bei der Installation:
:<syntaxhighlight lang="bash" style="width:50%;">sudo npm update -g alexa-fhem</syntaxhighlight>

:Manchmal hat npm Probleme mit einem Update. Dann einfach die aktuelle Version noch mal drüber Installieren:

:<syntaxhighlight lang="bash" style="width:50%;">sudo npm install -g alexa-fhem</syntaxhighlight>

*alexa-fhem über FHEM wieder starten:
:<syntaxhighlight lang="perl" style="width:50%;">set alexa start</syntaxhighlight>

'''"Upgraden von einer "Nicht-Connector" Installation (z.B. manuelle Installation per pm-Download):'''
* Daten der aktuellen Installation sichern (v.a. config.json / man weiß ja nie)
* Autostart der aktuellen alexa-fhem Installation deaktivieren:
** Bei initd: Service deaktivieren mittels: <code>sudo update-rc.d -f alexa remove</code> Vorher mittels stoppen: <code>sudo service alexa stop</code> Startscript unter /etc/init.d/ löschen.
** Bei systemd: Service deaktivieren mittels: <code>sudo systemctl disable alexa</code> Vorher mittels stoppen: <code>sudo systemctl alexa stop</code> Startscript unter /etc/systemd/system/ löschen.
* ALLE vorhandenen alexa-fhem Daten LÖSCHEN! Bleiben Dinge zurück und wird dann laut Connector installiert kann es zu Problemen kommen!
* (reboot)
* Installation von alexa-fhem laut Anleitung (Beginn dieses Wiki)
* Falls eigene Dinge von früher genutzt werden wollen/sollen (z.B. Custom Skill), dann die entsprechenden Einträge aus der gesicherten config.json in die neu angelegte alexa-fhem.cfg (zu finden unter "Edit files") übernehmen.
* Werden keine eigenen Dinge verwendet, dann kann der Port (Standard: 3000) geschlossen werden und auch die Daten unter Amazon-Developer können gelöscht werden.

== Bug- und Wunschliste ==
* Ist beim Start keine Internetverbindung vorhanden, erfolgt kein Retry -- alexa-fhem muss restartet werden (ssh_autoconfig wertet keine temporären Fehler aus)

==Weitergehende Informationen==
*[[Alexa und Mappings]]
*[[Alexa Tipps und Kniffe]]
*[[FHEM Connector for Amazon Alexa]]
[[Kategorie:HOWTOS]]
[[Kategorie:Sprachsteuerung]]

FHEM Connector für Amazon Alexa

2020-06-01T14:01:31Z

MadMax-FHEM:

{{Baustelle}}
'''Alexa FHEMlazy''' war historisch ein Fork des Original [[Alexa-Fhem|alexa-fhem]], der im Januar 2019 mit dem Original zusammengeführt wurde und nun als '''FHEM Connector''' verfügbar ist.

Er ermöglicht innerhalb von Minuten die Verknüpfung von FHEM mit einem Amazon Echo Gerät. Auch Geräte anderer Hersteller mit verbauten Mikrofonen und Alexa-Sprachassistenten-Unterstützung sollten problemlos funktionieren. Für folgende Geräte ist dies bspw. der Fall (Falls Ihr andere/weitere Gerätemodelle bzw. Hersteller in Verwendung habt, bitte hier pflegen):

* SONOS Beam und SONOS One

Gegenüber dem klassischen Ansatz ergeben sich Einschränkungen, so läuft die Software normalerweise unter dem gleichen Benutzer wie FHEM auf dem gleichen Server, und es wird z.Zt. nur der Smarthome-Skill unterstützt (die Variante, bei der die Möglichkeiten der Interaktion von Amazon festgelegt wurden).
Dafür ist weder ein Developer-Account bei Amazon, eigene Lambda- und Skillfunktionen, noch das Öffnen eines eingehenden Ports aus dem Internet nötig.
* Die Software integriert einen Installer, der die Erstkonfiguration und Anmeldung übernimmt
* Die Kommunikation zur Software auf dem heimischen Rechner und dann zu FHEM verläuft über SSH und einen vom FHEM-Verein gehosteten Server
* Funktioniert mit IPv4, IPv6, echtem Dual Stack und DS-Lite
* Als Skill bei Amazon wird der Skill "FHEM Connector" verwendet.

Der Thread im Forum zur Software ist hier: {{Link2Forum|Topic=94817}}.

{{Infobox Modul
|ModPurpose=Einfache Anbindung von FHEM an Amazon Assistent Alexa
|ModType=h
|ModCmdRef=alexa
|ModTechName=39_alexa.pm / alexa-fhem
|ModForumArea=Frontends/Sprachsteuerung
|ModOwner=gvzdus, André/ justme1968 ({{Link2FU|430|Forum}} / [[Benutzer Diskussion:Justme|Wiki]])
}}

==Einführung==

===Arbeitsweise und Datenfluss===
Vorläufig ist alexa-fhem im "FHEM Connector-Modus" ein reiner [https://developer.amazon.com/de/docs/smarthome/understand-the-smart-home-skill-api.html SmartHome-Skill].
SmartHome-Skills erhalten weder die Sprachdaten selber noch das, was Amazon in Textform verstanden hat, sondern vielmehr extrahiert Amazon aus dem verstandenen Text Anweisungen und Abfragen für Geräte, die dann an den Skill übermittelt werden. Charmant ist dabei, dass unmittelbar gefragt werden kann "Alexa, wie ist die Temperatur im Wohnzimmer?", während andere Skills zunächst explizit angesprochen werden müssen ("Alexa, frage FHEM nach der Temperatur im Wohnzimmer"). Außerdem kann der Nutzer mehrere Smarthome-Skills installieren, und die Geräte werden zu einer Gesamtmenge zusammengefasst.

Gehen wir den Datenfluss bei der konkreten Frage "Wie ist die Temperatur im Wohnzimmer?" durch:
* Alexa hat bei der Skillinstallation gelernt, dass "FHEM Connector" bei Dir einen Thermostaten im Raum Wohnzimmer kennt. Dadurch wird bei der Sprachanalyse von "Alexa Voice Service" in der Cloud erkannt, dass eine Abfrage an "FHEM Connector" erfolgversprechend ist.
* Zunächst wird die zentrale "Lambda-Funktion" von "FHEM Connector" aufgerufen. Die Funktion leitet aber im Kern nur den Request unverändert an den vom Verein bereitgestellten Server weiter. Im Request enthalten ist ein Token, das sogenannte "Bearer-Token".
* Der "Vereinsserver" prüft anhand dieses Tokens, ob es überhaupt bekannt ist, und zu welchem Nutzer es gehört. Ist dieser Nutzer verbunden, wird der Request wiederum quasi unverändert an den Nutzer weitergeleitet.
* Diese Weiterleitung passiert über einen sogenannten SSH-Reverse-Tunnel, der von Deiner Seite und der Software auf dem FHEM-Tunnel automatisch aufgebaut wird.
* Auf Deiner Seite läuft die eigentliche Software, und zwar unter nodeJS. nodeJS ist ein Javascript ausführender Miniserver, der lokal auf einem Zufallsport auf Requests "lauscht". In der Original-Version [[Alexa-Fhem|Alexa FHEM]] kommen die Requests aus dem Internet (hoffentlich von der eigenen Lambda-Funktion), hier bei "FHEM Connector" kommen sie ausschließlich aus dem SSH-Tunnel von lokal.
* Die Software validiert nun diesen Request anhand des Bearer-Tokens. Konkret wird dabei das bei der Installation generierte Token, dass bei der Skill-Aktivierung an Amazon übertragen wurde, mit dem lokal gespeicherten Wert verglichen. Stimmt das Token, wird der Befehl verarbeitet, üblicherweise wird hierbei ein Aufruf an die Webschnittstelle von FHEM abgesetzt.
* FHEM führt den Befehl aus

Hört sich langsam und kompliziert an? Kompliziert: Okay. Langsam eher nicht, in etlichen Fällen liegt die Gesamtantwortszeit unter 200 ms.

Soweit ein erster Überblick über die Datenflüsse. Im Abschnitt Sicherheit ist das Konzept der Absicherung deutlich genauer und ausführlicher beschrieben.

==Installation==

Du wirst bei der Installation zuerst auf der Kommandozeile auf Deinem Raspberry (o.ä.) unterwegs sein, anschließend im Webfrontend von FHEM, und zum Schluss auf der Alexa-Konsole im Web.

===node.js installieren===

Ab Jessy liegt NodeJS bereits in einer ausreichend aktuellen Version vor (Stretch und Buster funktionieren ebenfalls). Mit

<syntaxhighlight lang="bash" style="width:50%;">
sudo apt-get install nodejs npm
</syntaxhighlight>

kannst Du es installieren. Mit
<syntaxhighlight lang="bash" style="width:50%;">
node --version
</syntaxhighlight>

erfährst Du die aktuelle Version - wenn hier etwas mit "8" oder höher vorneweg erscheint, ist alles gut.
Ansonsten suche Dir bitte eine Anleitung im Web, wie Du NodeJS auf Deinem System auf einen aktuellen Stand bringen kannst.

=== Alexa-FHEM installieren ===

Nun installieren wir Alexa-fhem aus dem offiziellen Repository:

<syntaxhighlight lang="bash" style="width:50%;">
sudo npm install -g alexa-fhem
</syntaxhighlight>

Der Vorgang benötigt etwas Zeit.

=== Alexa-FHEM aktivieren ===

Wechsele jetzt in FHEM-Web!

Wichtig ist, dass das Alexa-Modul in der Version ab Januar 2019 vorliegt. Dafür bitte einmal FHEM aktualisieren:
Speichern der Config nicht vergessen, und

<syntaxhighlight lang="bash" style="width:50%;">
update
shutdown restart
</syntaxhighlight>

Alles, was jetzt noch nötig ist, ist das Anlegen eines Alexa-Devices. Gib dafür in der FHEM-Web-Kommandozeile

<syntaxhighlight lang="bash" style="width:50%;">
define alexa alexa
</syntaxhighlight>

an. Nun läuft, während Du bereits das neu angelegte Alexa-Devices siehst, ein komplexer Prozess im Hintergrund:

* Falls noch kein SSH-Key für den Benutzer, unter dem FHEM läuft, existiert, wird einer generiert
* Es wird ein Secret-Key im Prozess generiert, dass den Server nicht verlässt, und der Skillanmeldung dient.
* Du wirst auf dem Server "va-fhem.fhem.de" des FHEM-Vereins mit dem SSH-Key angemeldet, und der Hash-Wert Deines Secret-Key dort abgelegt.

Und wenn Du diese Sätze gelesen hast, sollte inzwischen sich das Alexa-Device in FHEM-Web aktualisiert haben, und
ungefähr so aussehen:

[[Datei:Alexa-Device-2.png|800px]]

Neben dem Status für alexa-fhem und der Proxyverbindung ist wichtig, dass diese beiden Zeilen beim Reload aufgetaucht sind:

<syntaxhighlight lang="bash" style="width:90%;">
alexaFHEM.bearerToken crypt:...
alexaFHEM.skillRegKey crypt:...
</syntaxhighlight>

Ja, und diesen Schlüssel benötigst Du wirklich! Also am besten schon einmal mit

<syntaxhighlight lang="bash" style="width:90%;">
get <alexa> proxyKey
</syntaxhighlight>

in Klartext anzeigen lassen und in ein Editor-Fenster dauerhaft wegsichern.

Jetzt solltest Du Dein Alexa-Device nicht mehr löschen, denn das im Reading angezeigte "bearerToken" zu löschen bedeutet, dass die Software die Zugriffe von nicht mehr überprüfen kann und keine Kommandos mehr funktionieren. In diesem Fall hilft nur die Neuinstallation des Skills.

==== Fehler bei der Aktivierung ====

Während kompliziertere Fehlerfälle im Abschnitt "Mögliche Probleme und Lösungen" behandelt werden, hier häufige Fälle, warum die kryptischen Zeilen nicht auftauchen:

* Zuerst bitte einfach einmal die Seite neu laden.

===== 401: Authorization Required =====

Wenn Du FHEM-Web mit einem User/Passwort-Schutz versehen hast, wirst du folgende Fehlermeldung sehen:

<syntaxhighlight lang="bash" style="width:90%;">
alexaFHEM stopped; failed to connect to fhem: 401: Authorization Required
</syntaxhighlight>

In der Regel musst du die Angaben User/Passwort noch einmal explizit setzen. Im Attribute-Abschnitt "alexaFHEM-auth" auswählen, User/Passwort mit ":" getrennt angeben und "attr" anklicken. alexa-fhem wird automatisch neu gestartet. Hier das Ganze in der Text-Variante:

<syntaxhighlight lang="bash" style="width:90%;">
attr alexa alexaFHEM-auth user:pass
</syntaxhighlight>

===== Permission denied =====

Wenn du folgende Fehlermeldungen im Alexa Logfile siehst, wurde das Verzeichnis "/opt/fhem/.ssh/" von dir bei der Arbeit mit "root" oder "sudo" mit den falschen Berechtigungen versehen:

<syntaxhighlight lang="bash" style="width:90%;">
[2019-7-25 11:59:12] sshautoconf: aborted with ssh-keygen returned error - key_save_private: Permission denied
[2019-7-25 11:59:12] *** SSH: proxy configuration failed: ssh-keygen returned error - key_save_private: Permission denied
</syntaxhighlight>

Prüfen kannst du die Berechtigungen mit folgendem Befehl auf der Shell-Konsole:

<syntaxhighlight lang="bash" style="width:90%;">
ls -l /opt/fhem/.ssh
</syntaxhighlight>

Du solltest dann folgende Ausgabe erhalten:

<syntaxhighlight lang="bash" style="width:90%;">
insgesamt 12
-rw------- 1 fhem dialout 1675 Jul 12 13:10 id_rsa
-rw-r--r-- 1 fhem dialout 391 Jul 12 13:10 id_rsa.pub
-rw-r--r-- 1 fhem dialout 884 Jul 12 13:10 known_hosts
</syntaxhighlight>

Steht in der Ausgabe nicht "fhem dialout" (dein fhem User), sondern bspw. "root root", dann bspw. mit folgendem Befehl an deinen fhem User anpassen:

<syntaxhighlight lang="bash" style="width:90%;">
chown fhem:dialout /opt/fhem/.ssh
</syntaxhighlight>

Mit dem ersten Befehl "ls -l ..." kannst du dann nochmal prüfen, ob die Berechtigungen korrekt übernommen wurden.

===== weitere Prüfungen =====

Hast Du noch die Shell-Konsole offen? Dann prüfe bitte noch einmal auf der Konsole, ob nun zwei Prozesse laufen:

<syntaxhighlight lang="bash" style="width:50%;">
ps -ef | egrep '(alexa|ssh)'
</syntaxhighlight>

sollte Dir idealerweise so etwas anzeigen:
<syntaxhighlight lang="bash" style="width:90%;">
fhem 31322 1 99 13:56 ? 00:00:03 alexa
fhem 31332 31322 8 13:56 ? 00:00:00 /usr/bin/ssh -R 1234:127.0.0.1:<zufälliger port> -oServerAliveInterval=90 -p 58824 fhem-va.fhem.de
</syntaxhighlight>

"alexa" ist dabei der Node-JS-Prozess, der ssh-Prozess ist die aufgebaute Verbindung zum Vereinsserver.

Wenn Du diese Prozesse '''nicht''' siehst oder das Alexa-Device keinen Registrierungskey anzeigt, dann ist leider der Start nicht glatt verlaufen.

Im Logfile (über den link <code>Logfile</code> in der Detail-Ansicht über <code>set</code>, oder über den Namen bei ''currentlogfile'' in den Internals) findest Du idealerweise selber Hinweise, wo es hakt, oder kannst im Forum nachfragen.

=== Geräte im FHEM-Webfrontend zuweisen ===
Um das Aha-Erlebnis zu vergrößern, ist jetzt ein guter Zeitpunkt, 1 oder besser mind. 2 Geräte für den Alexa-Dienst zuzuweisen. Von Haus aus wird keines Deiner FHEM-Geräte automatisch Alexa zugewiesen!

Wähle die Geräte aus, rufe sie auf und setze das Attribut "alexaName". Hierbei in Kürze nur der Hinweis:
* Keine Angst vor Leerzeichen und Umlauten, funktioniert.
* Große Angst vor Rechtschreibfehlern (Terrasse, Rollladen) oder komplizierten Wörtern "handgebastelte Martinslaterne im Kinderzimmer Iphigenie-Chantal".
* Mehrere Namen für dasselbe Gerät/Device in fhem werden unterstützt. Mehrere Namen werden durch Strichpunkt getrennt.
* Das Attribut "alexaRoom" ist NUR FÜR DEN CUSTOM SKILL relevant. Ausnahme: structure und LightScene Devices, siehe: [[FHEM_Connector_f%C3%BCr_Amazon_Alexa#Was_geht_alles_.3F]].

Lade die Geräte neu in die Software, indem Du <code>set <alexa> restart</code> ausführst!
[[Datei:HowToSet alexaName.png|alternativtext=How to set alexaName|ohne|mini|Wie setzt man das Attribut alexaName]]

'''Anmerkungen (weil oft gestellte Fragen im Forum) bzgl. Erkennung von Geräten:'''

* Wichtig ist, dass die Filtereinstellung in der alexa-fhem.cfg (zu finden unter "Edit Files") passt.
Das, was dort eingetragen ist (Standard: alexaName=..* / also es ist ein alexaName vergeben) auch an den entsprechenden Devices in fhem vorhanden ist.
Stimmt das nicht überein, kann alexa-fhem keine Devices von fhem abfragen/finden.
Ob der Filter entsprechend funktioniert kann man wie folgt testen: ''list Filtereinstellung'' beispiel mit Standardfilter: ''list alexaName=..*''

* Hat alexa-fhem per Filter Devices aus fhem "gefunden", geht es weiter mit der "Erkennung". Also um welches Device (Typ und "Fähigkeiten") handelt es sich. Dazu gilt folgendes:
** sind entsprechende Readings beim Device vorhanden (z.B. temperature, state mit on/off, ...) erkennt das alexa-fhem automatisch. Die Liste der automatisch erkannten Readings wächst ständig. Daher erst mal schauen ob das Device bereits entsprechend erkannt (typisiert) wurde. Das kann durch prüfen des alexa-fhem-Logs geschehen (NICHT fhem-log!).
** sind entsprechende "set-Befehle" erkennbar (oft auch durch Readings). Also ist beispielsweise (wie beim Dummy nötig) ein ''setList'' mit entsprechenden Einträgen vorhanden oder entsprechende Readings, z.B. desired-temp zum Stellen der Temperatur etc.
** wird das Device nicht richtig oder "unvollständig" erkannt helfen folgende Attribute:
*** genericDeviceType: hiermit kann alexa-fhem in die gewünschte Richtung "geschubbst" werden. Anmerkung: man kann nicht alles erzwingen, Readings bzw. set-Befehle müssen passen (oder per homebridgeMapping passend gemacht werden). Wenn ein genericDeviceType nicht per "Drop-Down" erscheint, dann kann er auch (wenn bekannt) einfach per WEB-cmd eingegeben werden: ''attr Devicename genericDeviceType media''
*** homebridgeMapping: hierdurch kann alexa-fhem bei der Erkennung von Zuständen und möglichen Einstellungen (also WAS kann das Device) unterstützt werden. Mittels homebridgeMapping können vorhandene Readings (Zustände) auf für alexa-fhem bekannte Zustände gemappt werden. Ebenso können damit Standard-fhem-Kommandos von alexa-fhem auf Device-spezifische gemappt werden. Beispiel: on/off auf Ein/Aus (falls das Device statt on/off eben ein Ein/Aus erwartet). Zum Beispiel: <syntaxhighlight lang="bash" style="width:50%;">
attr <thermostat> homebridgeMapping TargetTemperature=target::target,minValue=18,maxValue=25,minStep=0.5 CurrentTemperature=myTemp:temperature
</syntaxhighlight> [https://github.com/justme-1968/homebridge-fhem/blob/master/README.md weitere Beispiele]

''Mehrere Namen für dasselbe Gerät/Device in fhem ist möglich. Die Namen werden durch Strichpunkt getrennt.''
Beispiel:
<code>attr dmLampe alexaName Lichtkuppel;Lichtkugel</code>

'''Anmerkung bzgl. genericDeviceType und homebridgeMapping:''' 
* diese Attribute werden von verschiedenen "Sprachsteuerungsmodulen" in fhem verwendet (homebridge [dort wurde es "erfunden"], alexa-fhem, gassistant, ...). Daher ist nicht jedes Mapping für alle "Dienste" verwendbar. Ausprobieren schadet aber nicht.
* ebenso kann man mit diesen Attributen (homebridgeMapping wird gerne so "missbraucht") nichts erzwingen, was seitens Amazon/Alexa nicht unterstützt bzw. verstanden wird! D.h. zunächst ist zu prüfen, ob ein bestimmter (gewünschter) Sprachbefehl seitens Amazon/Alexa unterstützt wird! Aktuelles Beispiel (Stand Jan 2020): "Alexa, fahre den Rollo hoch/runter". Da ist Amazon/Alexa gerade dabei etwas zu tun. Bislang wird das nicht unterstützt, also ist das auch mit einem entsprechenden homebridgeMapping nicht zu erzwingen! Was unterstützt wird kann man bei Amazon nachlesen: [https://developer.amazon.com/es-ES/docs/alexa/device-apis/list-of-interfaces.html]

== Finale: Skill verknüpfen ==
Suche im WebFrontend oder der Alexa-App den Skill "FHEM Connector". Für nicht-Mac/iOS Anwerder empfiehlt das WebFrontend (https://alexa.amazon.de) statt die App, damit Du den Anmeldeschlüssel auch bequem kopieren kannst.

Wenn du noch nicht bei Amazon angemeldet bist, erwartet Amazon zunächst, dass Du Dich normal bei Amazon anmeldest.

Sobald Du "FHEM Connector" aktivierst, öffnet sich ein Browser-Tab mit folgender Maske: 
[[Datei:FHEMlazy_login.png|240px]]

Hier kopierst Du Deinen Anmeldeschlüssel (im Klartext!) hinein und klickst auf Check. Als glücklicher Mensch ist auf der folgenden Statusseite alles grün: 
[[Datei:FHEMlazy_check.png|240px]]

Im Einzelnen wird hier geprüft, ob Du per SSH verbunden bist (und auch Deine IP zur Sicherheit angezeigt), ob der Reverse-Tunnel steht, ob nodeJS erreichbar ist und wie viele Geräte Alexa gleich finden sollte (in meinem Fall 22).

Sollte etwas nicht grün sein und Du eine Idee zum Fixen haben, kannst Du mit "Retry" neue Versuche auslösen.

Ist alles okay, klicke rechts den Button "Activate Skill". Du springst damit wieder zurück zu Amazon, die Dir hoffentlich zur erfolgreichen Verknüpfung gratulieren.

Amazon möchte nun unmittelbar die Gerätesuche starten, und unter SmartHome-Geräte sollten diese nun auftauchen.

== Was geht alles ? ==

* Geräte, die sich ein- und ausschalten lassen:
** Automatisch: Müssen <code>set on</code> und <code>set off</code> Kommandos haben
** dummys müssen <code>setList</code> mit on und off haben
** Über <code>genericDeviceType</code> switch bzw. light kann bestimmt werden ob es in alexa als Schalter oder Licht behandelt wird.
** Wenn die Set-Kommandos im FHEM Device anders benannt sind: homebridgeMapping On:cmdOn=<ein>,cmdOff=<aus> setzen
** Kommandos:
***Alexa, schalte <name> ein/aus
***Alexa, Licht an/aus
***Alexa, schalte <gruppe> ein/aus
* Geräte, die eine Temperatur messen
** Automatisch: Es muss ein Reading <code>temperature</code> geben
** Über <code>genericDeviceType</code> thermometer
** Sonst: homebridgeMapping CurrentTemperature:reading=<reading>

* Geräte, deren Helligkeit sich ändern lässt
** Automatisch: wenn <code>dim</code> oder <code>pct</code> Kommandos erkannt werden
** Über <code>genericDeviceType</code> light
** Über homebridgeMapping: Wenn <code>helligkeit</code> das Reading für die aktuelle Helligkeit enthält und die Helligkeit mit <code>set <device> prozent xxx</code> gesetzt wird, sieht das homebridgeMapping wie folgt aus: homebridgeMapping Brightness=helligkeit::prozent,minValue=0,maxValue=<maximalwert>
** Kommandos:
*** Alexa, mache <name> heller/dunkler
*** Alexa, Licht heller/dunkler
* Geräte, deren Farbe sich ändern lässt
** ...

* Geräte, deren Farbtemperatur sich ändern lässt
** ...

* Geräte, bei denen sich eine Lautstärke einstellen lässt
** ...

* Geräte, bei denen sich ein prozentualer Wert einstellen lässt
** Automatisch: wenn <code>dim</code> oder <code>pct</code> Kommandos erkannt werden
** ...

* elektrische Türschlösser
** <code>genericDeviceType</code>: lock
** homebridgeMapping mit LockCurrentState und LockTargetState

* Thermostate
** Über <code>genericDeviceType</code> thermostate
** ...

* structure Devices aus FHEM (ab alexa-fhem version 0.5.7)
** können mit <code>genericDeviceType</code> scene als Szene eingebunden werden
** über <code>alexaRoom</code> kann der name um einen Ort ergänzt werden
** Szenen aus einer structure lassen sich ein- und ausschalten
** Wichtig:
*** Ein Skill darf nur 12 Szenen automatisch erkennen und einbinden.

* LightScene Devices aus FHEM (ab alexa-fhem version 0.5.8)
** können mit <code>genericDeviceType</code> scene als Szenen eingebunden werden
** über <code>alexaRoom</code> kann der name um einen Ort ergänzt werden
** Szenen aus einer LightScene lassen sich nur einschalten
** Wichtig:
*** Ein Skill darf nur 12 Szenen automatisch erkennen und einbinden.

* Geräte, deren Kanal sich umschalten lässt (ab alexa-fhem version 0.5.13)
** Über <code>genericDeviceType</code> media
** homebridgeMapping ChannelController:reading=<reading>,cmd=<cmd>
** Erlaubte Werte siehe hier: https://developer.amazon.com/de/docs/device-apis/alexa-channelcontroller.html#changechannel
** ...

* Geräte, deren Playback status sich schalten lässt (ab alexa-fhem version 0.5.13)
** Über <code>genericDeviceType</code> media
** homebridgeMapping PlaybackController:playback,values=Play;Pause;Stop;Previous;Next
** Erlaubte Werte siehe hier: https://developer.amazon.com/de/docs/device-apis/alexa-playbackcontroller.html#discovery
** ...

* Geräte, deren Eingang sich umschalten lässt (ab alexa-fhem version 0.5.13)
** Über <code>genericDeviceType</code> media
** homebridgeMapping InputController:reading=<reading>,cmd=<cmd>,values=HDMI+1;HDMI+2;XBOX
** Erlaubte Werte siehe hier: https://developer.amazon.com/de/docs/device-apis/alexa-property-schemas.html#input
** ...

* Kontaktsensoren (ab alexa-fhem version 0.5.15)
** Über <code>genericDeviceType</code> contact
** homebridgeMapping ContactSensorState:reading=<reading> oder CurrentDoorState:reading=<reading>
** Die Anzeige in der Alexa-App funktioniert sofort, die Abfrage per Sprache erst ab Version 0.5.27.

* Geräte, deren Lautstärke sich ändern lässt (ab alexa-fhem version 0.5.24)
** Über <code>genericDeviceType</code> speaker
** Automatisch: es muss ein Reading <code>volume</code> und/oder <code>mute</code> geben
** homebridgeMapping Volume:reading=<reading>,cmd=<cmd> Mute:reading=<reading>,cmd=<cmd>
** ...

* Geräte, die sich ein- (und optional) ausschalten lassen als Szene (ab alexa-fhem version 0.5.26)
** Über <code>genericDeviceType</code> scene
** Automatisch: Müssen <code>set on</code> und <code>set off</code> Kommandos haben
** homebridgeMapping On:reading=<reading>,cmdOn=<cmd>[,cmdOff=<cmd>]
** Hinweis: Fehlende Kommandos lassen sich mit cmdalias erzeugen
** Wichtig:
*** Ein Skill darf nur 12 Szenen automatisch erkennen und einbinden.
* Rollläden. Lange ein Problemthema, das nur mit "Schalte auf 0%, schalte auf 100% lief". Wichtig: "alexa-fhem" ab Version 0.5.39 einsetzen. GenericDevice-Type auf "blind" setzen. Nach Restart von alexa-fhem und neuer Gerätesuche sollte folgendes funktionieren:
** "..., öffne <Name> ganz"
** "..., schließe <Name> komplett"
** "hoch" und "runter" (ohne "ganz" oder "komplett") schalten jeweils nur einen bestimmten Prozentsatz hoch oder runter. Dieser kann mit <code>attr <name> homebridgeMapping TargetPosition:minStep=<wert></code>geändert werden. Aber Achtung: In diesem Intervall kann dann auch nur noch ein absoluter Prozentwert per Sprache oder Slider eingestellt werden! Bei z.B. 25% würden 13% zu 25% aufgerundet, 12% zu 0% abgerundet werden.
* Kontaktsensoren (ab alexa-fhem version 0.5.47)
** Automatisch wenn ein Reading <code>motion</code> vorhanden ist oder es sich um einen Zigbee bewgungsmelder an einer HUE oder deCONZ Bridge handelt
** Über <code>genericDeviceType</code> MotionSensor
** homebridgeMapping MotionDetected:reading=<reading>,values=<wert für bewgung>:1;<wert für keine bewegung>:0

* Alarmmelder (noch nicht in Deutschland):
** genericDeviceType Security
** homebridgeMapping Alarm=<reading>[,type=[fireAlarm|waterAlarm|burglaryAlarm|carbonMonoxideAlarm]]
** wenn der type nicht angegeben wird ist fireAlarm der default
** automatisch werden 0, ok und alles was mit no anfängt als OK erkannt. alles andere gilt als ALARM.

Es werden noch einige andere häufig verwendete Geräte (Homematic, hue,...) automatisch erkannt.

to be continued ...

In der [https://developer.amazon.com/docs/device-apis/list-of-interfaces.html List of Capability Interfaces] bei Amazon kann man sehen, welche Möglichkeiten das Smart Home Skill API aktuell in einzelnen Ländern bietet. Leider ohne die jeweiligen landessprachlichen Kommandos.

=== Aktiv Routinen starten ===
Routinen (eine Funktionalität, die rein - genauso wie "Räume" - bei Amazon liegt und nicht von FHEM Connector beeinflusst wird) waren lange die ewige Antwort auf die Frage: "Meine Frau möchte aber '''Öffne Rollläden''<nowiki/>' sagen": In der Alexa-App gibt es im Menü den Punkt "Routinen", und hier lässt sich eine gewisse Anzahl von Aktionen (unter optionalen Bedingungen) an ein Sprachkommando knüpfen.

Neu: Routinen können inzwischen auch von Skills getriggert werden, und seit Version 0.5.47 (Februar 2020) auch von FHEM Connector. Das braucht niemand, um die Rollläden hochzufahren, denn das kann FHEM ja selber, aber um z.B. eine Ansage auf einem Alexa-Gerät zu triggern. Dafür gibt es auch das FHEM-Modul "echodevice", aber es erfordert ein paar Klimmzüge. Mit dem aktiven Triggern von Routinen kann FHEM auslösen, dass Alexa ungefragt (!) Dinge wie

''"Die Temperatur in der Tiefkühltruhe hat -16 Grad überschritten"''

in den Raum sagt. Also eine Alternative bzw. Ergänzung zu Alarmen / Erinnerungen per Telegram o.ä.

'''Vorgeschichte''':

Die Smarthome-Skill-API von Amazon sah schon lange das "proactiveReporting" vor: Also z.B. die gemessene Temperatur nicht erst auf Anfrage hin zu übermitteln, sondern laufend aktiv zu pushen. Aber warum Daten an Amazon senden, wenn es dafür keinen Mehrwert gibt? Beim Öffnen z.B. des Thermostaten in der Alexa-App kommen ohnehin laufend Statusabfragen. Warum also einen Datenpool bei Amazon über die Haustemperatur aufbauen und Änderungen pushen, wenn es keinen Mehrwert dafür gibt?

Inzwischen lassen sich (reale oder vermeintliche) Änderungen von ''Bewegungssensoren'' und ''Fensterkontakten'' als Startbedingung an Alexa-Routinen koppeln. Man kann in der Alexa-App (ggf. fiktive) Öffnen eines Fensterkontaktes an das Aufsagen eines freien Textes durch die Hausbutlerin knüpfen.

'''Umsetzung''':
* Jedes Alexa-Device, dessen Status aktiv zu Amazon gepusht werden soll, im Attribut "alexaProactiveEvents" mit einer "1" versehen. Per Default wird ''kein'' Gerät laufend aktiv zu Amazon gepusht!
* das geänderte Device einmal zu Amazon pushen "set <alexa> add <device>" (oder 'Alexa, suche neue Geräte' murmeln)
* Das Gerät sollte jetzt beim Anlegen einer neuen Routine ("Neue Routine", "Wenn Folgendes passiert", "Smart Home") als möglicher Triggerpunkt erscheinen.

==== Dummygeräte: ====
Ein Dummydevice sollte einen Kontaktschalter oder Bewegungssensor simulieren, um dann in FHEM eine beliebige Bedingung als Trigger zu definieren, und eine freie Ansage in Alexa als Routine zu definieren. Hier ein Beispiel:

<syntaxhighlight lang="bash" style="width:90%;">
define voicetrigger1 dummy
attr voicetrigger1 alexaName Trigger 1
attr voicetrigger1 alexaProactiveEvents 1
attr voicetrigger1 genericDeviceType contact
attr voicetrigger1 homebridgeMapping ContactSensorState=state,values=closed:CONTACT_DETECTED;;open:CONTACT_NOT_DETECTED
attr voicetrigger1 readingList 0:closed 1:open
attr voicetrigger1 setList closed open

set alexa add voicetrigger1
set alexa restart
</syntaxhighlight>

'''Fehlersuche:'''

Der Push setzt ein intaktes Push-Token voraus. Sollte im Alexa-Logfile Folgendes erscheinen:

<code>failed to refresh token: invalid_grant: 'The request has an invalid grant parameter : refresh_token'</code>

so ist das Push-Token nicht aktuell. Weil die Auswirkung lange nur war, dass Geräteänderungen nicht aktiv an Amazon gemeldet wurden, gibt es noch keine umfassende Analyse des Problems. Es lässt sich lösen, indem eine oder beide folgenden Aktionen ausgeführt werden:
* Löschen des ".eventToken" im Alexa-Device über "deletereading"
* "FHEM-Connector"-Skill auf "alexa.amazon.de" einmal deaktivieren und dann neu verbinden

== Mögliche Probleme und Lösungen ==

Es kann vorkommen, dass Geräte zwar korrekt erkannt werden, aber das durch Alexa erkannte Kommando nicht richtig umgesetzt wird (Beispiel - mittlerweile behoben: {{Link2Forum|Topic=96766}}). Neben dem FHEM-Log gibt es noch das Logfile, welches von alexa-fhem angelegt wird.

=== Fehlersuche über die FHEM-Oberfläche ===

* alexa-fhem Logfile anschauen (Detail-Ansicht des <alexa>-Device aufrufen, klick auf '''Logfile''' oben)
* alexa-fhem im Debug-Modus aufrufen:
** -D zum alexaFHEM-params attribut hinzufügen
** Alexa-Befehl auslösen
** -D aus dem alexaFHEM-params attribut entfernen
* Die notwendigen Informationen finden sich in dem alexa-Logfile (siehe oben)

=== Fehlersuche über Kommandozeile (lies: Shell) + FHEM-Oberfläche ===

:* set <alexa> stop (FHEM-Oberfläche)
:* Auf der Kommandozeile <code>alexa-fhem -D -c /opt/fhem/alexa-fhem.cfg > debug.log</code> starten (dadurch wird die Datei debug.log erzeugt im aktuellen Verzeichnis)
:* Alexa-Befehl auslösen
:* alexa-fhem auf der Kommandozeile wieder stoppen (CTRL-C)
:* set <alexa> start (FHEM-Oberfläche)

Die Datei debug.log sollte Hinweise enthalten, wie das Problem zu lösen ist oder Dich zumindest in die richtige Richtung schieben.

Im Beispiel aus dem Forum fand sich in dem Logfile der Hinweis darauf, dass das Device mit falschen min/max-Werten unterwegs war.

=== Registrierungskey vergessen, Registrierung zurücksetzen ===

Auf der Kommandoshell:

<syntaxhighlight lang="bash" style="width:90%;">
pi@raspberrypi:~# sudo -u fhem ssh -p 58824 fhem-va.fhem.de status
Registered.
Registered on 2019-01-13T15:38:13Z.
</syntaxhighlight>

heisst, das der Vereinsserver eigentlich alles hat, was er will. Es wird kein neuer Schlüssel generiert.
Wenn Du die Situation zurücksetzen möchtest, wäre die hässliche Methode, Deinen SSH-Key zu löschen. Eleganter ist, die Registrierung auf Vereinsseite zu löschen:

<syntaxhighlight lang="bash" style="width:90%;">
pi@raspberrypi:~# sudo -u fhem ssh -p 58824 fhem-va.fhem.de unregister
Your registration has been removed
</syntaxhighlight>

löscht Deinen Schlüssel mitsamt allen dort gespeicherten Daten auf Vereinsseite. Bei Restart von alexa-fhem in FHEM-WEB wird jetzt ein neuer Registrierungskey angefordert.

== Sicherheitskonzept und Secrets ==

Um diesen Abschnitt zu verstehen, solltest Du den Abschnitt "Arbeitsweise" im Kopf haben. Einerseits ist Dir vermutlich einleuchtend, dass ein Server, der per SSH rückwärts nur ausgewählte Kommandos in den Tunnel, den Du aufgebaut hast, leitet, "irgendwie sicherer" ist. Andererseits möchte man nicht blind vertrauen.

=== SSH ===
==== SSH - macht das nichts Gefährliches? ====
SSH ist ein Veteran des Internet und entstand, um sich sicher (verschlüsselt) und schnell auf Servern einzuloggen. Schon früh wurde dabei der sogenannte "Reverse-Tunnel" implementiert: Also der vom Client (Deinem Rechner) geäußerte Wunsch: "Bitte leite mir Requests, die bei Dir, Server, auf Port xy eingehen, an meinen lokalen Port yz weiter.". Dieses Verfahren implementiert der Reverseproxy, wobei tatsächlich auf dem Server für Dich kein echter Port geöffnet wird.

Wie Dir ggf. sicher der Unix-Guru Deines Vertrauens bestätigen wird: Die Kombination
<syntaxhighlight lang="bash" style="width:50%;">
ssh -R 1234:localhost:<zufälliger port> zielserver
</syntaxhighlight>
erlaubt keine Ausführung von Shell-Kommandos auf Deinem Server, sondern einzig, dass vom SSH-Programm Verbindungen zu einem lokalen Port auf Deinem Server auf dem alexa-fhem lauscht aufgebaut werden. Du kannst also z.B. mit einem
<syntaxhighlight lang="bash" style="width:50%;">
sudo /usr/sbin/tcpdump -X -s 0 -i lo port <zufälliger port>
</syntaxhighlight>
vollständig überwachen (oder ggf. permanent aufzeichen), was auf Deinem Server von außen gesteuert passiert.

==== Wie wird bei SSH verschlüsselt? ====
Im Prinzip wie im Web auf SSL-Seiten, teils mit den gleichen Verschlüsselungsverfahren. Allerdings arbeitet SSH eher wie das im Web recht seltene Verfahren: Bei jeder Verbindung übermitteln sowohl Server wie auch Client den öffentlichen Teil ihres Schlüssels. Anders als im Web wird der Schlüssel aber nicht von einer öffentlichen Zertifizierungsstelle wie "LetsEncrypt" unterschrieben. Stattdessen entscheiden Server wie Client beim ersten Verbindungsaufbau typischerweise per manueller Frage: "Willst Du jetzt und künftig diesem Schlüssel vertrauen?" Bei der Installation wird diese Frage für Deine Seite bejaht, und fortan wird der öffentliche Schlüssel des FHEM-Servers auf Deinem Rechner gespeichert. Ab da bist Du z.B. davor sicher, dass jemand den DNS-Eintrag verbiegt oder sich in den Datenfluss Deines Providers einhängt: Ein geänderter Serverschlüssel würde bemerkt werden.
 
Soweit klar? Aus Deinem öffentlichen Schlüssel wiederum leitet der Server her: "Das ist definitiv wieder derjenige, der sich damals "registriert" hat". Und an dieser Stelle kann ich auch den ersten Teil des 3-teiligen Registrierungskeys erläutern: Die typischerweise 6-stellige Hex-Zahl am Anfang ist der Java-Hashcode Deines öffentlichen Schlüssel. Sie ist damit sozusagen Deine aus Deinem öffentlichen Schlüssel abgeleitete Benutzer-ID.

=== Die Rolle der Secrets ===
Wenn jetzt klar ist, dass die Verbindung zum Vereinsserver sicher und vertauschungsfrei funktioniert, bleiben noch 2 Probleme zu lösen:
1) Im Web bei der Skill-Aktivierung musst Du beweisen, dass Du der Mensch am Browser bist, dem der SSH-Tunnel von IP xy mit dem öffentlichen Schlüssel X gehört. Bei der automatischen Registrierung werden lokal auf Deinem Rechner zwei 64-Bit-Secrets generiert:
* Das Anmelde-Secret
* Das Bearer-Token
Beim Anmelden des SSH-Keys auf dem öffentlichen Server wird nun der Hashwert des ersten Secrets übertragen und dort in Verbindung mit Deinem öffentlichen Schlüssel gespeichert. Ein Hashwert bedeutet, dass (sofern das Verfahren, hier SHA256, funktioniert), niemand aus dem Hash das Secret zurückrechnen kann. Ein Datenbankklau auf dem Server gefährdet also nicht die Sicherheit Deines Passwortes.

Wenn Du nun beim Skill-Aktivieren den Registrierungskey eingibst, dann "sieht" der Server zum ersten Mal Dein ausgewürfeltes Secret, vergleicht es mit dem Hashwert und wird es anschließend wieder umgehend vergessen. Anhand des Hashwertes kann der Server aber entscheiden, dass Du der legitime Nutzer zum öffentlichen Schlüssel XY bist.

2) Das zweite Problem ist: Wie soll Amazon "beweisen", dass sie der legitime Aufrufer sind? Amazon erhält binnen wenigen Sekunden nach dem Klick auf "Activate Skill" den dritten Teil des Registrierungskeys als sogenanntes Bearer-Token. Zwar läuft er durch den Registrierungsserver, er wird dort, auf dem Registrierungs/Vereinsserver aber nicht gespeichert. Das Bearer-Token wird von Amazon bei allen Requests zu Deinem Server mitgesendet. Da es am Anfang zusätzlich Deine "User-ID" enthält, weiß der Vereinsserver, zu welchem SSH-Tunnel der Request zu senden ist. Aber lokal auf Deinem Rechner wird ausgewertet, ob das Token "stimmt".

== alexa-fhem Updaten bzw. "Upgraden" ==

'''Updaten einer "Connector" Installation:'''
* alexa-fhem über FHEM anhalten (Name des Alexa-Device: alexa):
:<syntaxhighlight lang="perl" style="width:50%;">set alexa stop</syntaxhighlight>

*Auf der Konsole wie anfangs bei der Installation:
:<syntaxhighlight lang="bash" style="width:50%;">sudo npm update -g alexa-fhem</syntaxhighlight>

:Manchmal hat npm Probleme mit einem Update. Dann einfach die aktuelle Version noch mal drüber Installieren:

:<syntaxhighlight lang="bash" style="width:50%;">sudo npm install -g alexa-fhem</syntaxhighlight>

*alexa-fhem über FHEM wieder starten:
:<syntaxhighlight lang="perl" style="width:50%;">set alexa start</syntaxhighlight>

'''"Upgraden von einer "Nicht-Connector" Installation (z.B. manuelle Installation per pm-Download):'''
* Daten der aktuellen Installation sichern (v.a. config.json / man weiß ja nie)
* Autostart der aktuellen alexa-fhem Installation deaktivieren:
** Bei initd: Service deaktivieren mittels: <code>sudo update-rc.d -f alexa remove</code> Vorher mittels stoppen: <code>sudo service alexa stop</code> Startscript unter /etc/init.d/ löschen.
** Bei systemd: Service deaktivieren mittels: <code>sudo systemctl disable alexa</code> Vorher mittels stoppen: <code>sudo systemctl alexa stop</code> Startscript unter /etc/systemd/system/ löschen.
* ALLE vorhandenen alexa-fhem Daten LÖSCHEN! Bleiben Dinge zurück und wird dann laut Connector installiert kann es zu Problemen kommen!
* (reboot)
* Installation von alexa-fhem laut Anleitung (Beginn dieses Wiki)
* Falls eigene Dinge von früher genutzt werden wollen/sollen (z.B. Custom Skill), dann die entsprechenden Einträge aus der gesicherten config.json in die neu angelegte alexa-fhem.cfg (zu finden unter "Edit files") übernehmen.
* Werden keine eigenen Dinge verwendet, dann kann der Port (Standard: 3000) geschlossen werden und auch die Daten unter Amazon-Developer können gelöscht werden.

== Bug- und Wunschliste ==
* Ist beim Start keine Internetverbindung vorhanden, erfolgt kein Retry -- alexa-fhem muss restartet werden (ssh_autoconfig wertet keine temporären Fehler aus)

==Weitergehende Informationen==
*[[Alexa und Mappings]]
*[[Alexa Tipps und Kniffe]]
*[[FHEM Connector for Amazon Alexa]]
[[Kategorie:HOWTOS]]
[[Kategorie:Sprachsteuerung]]

FHEM Connector für Amazon Alexa

2020-06-01T14:00:09Z

MadMax-FHEM: Ergänzt: mehrere Namen für dasselbe Gerät

{{Baustelle}}
'''Alexa FHEMlazy''' war historisch ein Fork des Original [[Alexa-Fhem|alexa-fhem]], der im Januar 2019 mit dem Original zusammengeführt wurde und nun als '''FHEM Connector''' verfügbar ist.

Er ermöglicht innerhalb von Minuten die Verknüpfung von FHEM mit einem Amazon Echo Gerät. Auch Geräte anderer Hersteller mit verbauten Mikrofonen und Alexa-Sprachassistenten-Unterstützung sollten problemlos funktionieren. Für folgende Geräte ist dies bspw. der Fall (Falls Ihr andere/weitere Gerätemodelle bzw. Hersteller in Verwendung habt, bitte hier pflegen):

* SONOS Beam und SONOS One

Gegenüber dem klassischen Ansatz ergeben sich Einschränkungen, so läuft die Software normalerweise unter dem gleichen Benutzer wie FHEM auf dem gleichen Server, und es wird z.Zt. nur der Smarthome-Skill unterstützt (die Variante, bei der die Möglichkeiten der Interaktion von Amazon festgelegt wurden).
Dafür ist weder ein Developer-Account bei Amazon, eigene Lambda- und Skillfunktionen, noch das Öffnen eines eingehenden Ports aus dem Internet nötig.
* Die Software integriert einen Installer, der die Erstkonfiguration und Anmeldung übernimmt
* Die Kommunikation zur Software auf dem heimischen Rechner und dann zu FHEM verläuft über SSH und einen vom FHEM-Verein gehosteten Server
* Funktioniert mit IPv4, IPv6, echtem Dual Stack und DS-Lite
* Als Skill bei Amazon wird der Skill "FHEM Connector" verwendet.

Der Thread im Forum zur Software ist hier: {{Link2Forum|Topic=94817}}.

{{Infobox Modul
|ModPurpose=Einfache Anbindung von FHEM an Amazon Assistent Alexa
|ModType=h
|ModCmdRef=alexa
|ModTechName=39_alexa.pm / alexa-fhem
|ModForumArea=Frontends/Sprachsteuerung
|ModOwner=gvzdus, André/ justme1968 ({{Link2FU|430|Forum}} / [[Benutzer Diskussion:Justme|Wiki]])
}}

==Einführung==

===Arbeitsweise und Datenfluss===
Vorläufig ist alexa-fhem im "FHEM Connector-Modus" ein reiner [https://developer.amazon.com/de/docs/smarthome/understand-the-smart-home-skill-api.html SmartHome-Skill].
SmartHome-Skills erhalten weder die Sprachdaten selber noch das, was Amazon in Textform verstanden hat, sondern vielmehr extrahiert Amazon aus dem verstandenen Text Anweisungen und Abfragen für Geräte, die dann an den Skill übermittelt werden. Charmant ist dabei, dass unmittelbar gefragt werden kann "Alexa, wie ist die Temperatur im Wohnzimmer?", während andere Skills zunächst explizit angesprochen werden müssen ("Alexa, frage FHEM nach der Temperatur im Wohnzimmer"). Außerdem kann der Nutzer mehrere Smarthome-Skills installieren, und die Geräte werden zu einer Gesamtmenge zusammengefasst.

Gehen wir den Datenfluss bei der konkreten Frage "Wie ist die Temperatur im Wohnzimmer?" durch:
* Alexa hat bei der Skillinstallation gelernt, dass "FHEM Connector" bei Dir einen Thermostaten im Raum Wohnzimmer kennt. Dadurch wird bei der Sprachanalyse von "Alexa Voice Service" in der Cloud erkannt, dass eine Abfrage an "FHEM Connector" erfolgversprechend ist.
* Zunächst wird die zentrale "Lambda-Funktion" von "FHEM Connector" aufgerufen. Die Funktion leitet aber im Kern nur den Request unverändert an den vom Verein bereitgestellten Server weiter. Im Request enthalten ist ein Token, das sogenannte "Bearer-Token".
* Der "Vereinsserver" prüft anhand dieses Tokens, ob es überhaupt bekannt ist, und zu welchem Nutzer es gehört. Ist dieser Nutzer verbunden, wird der Request wiederum quasi unverändert an den Nutzer weitergeleitet.
* Diese Weiterleitung passiert über einen sogenannten SSH-Reverse-Tunnel, der von Deiner Seite und der Software auf dem FHEM-Tunnel automatisch aufgebaut wird.
* Auf Deiner Seite läuft die eigentliche Software, und zwar unter nodeJS. nodeJS ist ein Javascript ausführender Miniserver, der lokal auf einem Zufallsport auf Requests "lauscht". In der Original-Version [[Alexa-Fhem|Alexa FHEM]] kommen die Requests aus dem Internet (hoffentlich von der eigenen Lambda-Funktion), hier bei "FHEM Connector" kommen sie ausschließlich aus dem SSH-Tunnel von lokal.
* Die Software validiert nun diesen Request anhand des Bearer-Tokens. Konkret wird dabei das bei der Installation generierte Token, dass bei der Skill-Aktivierung an Amazon übertragen wurde, mit dem lokal gespeicherten Wert verglichen. Stimmt das Token, wird der Befehl verarbeitet, üblicherweise wird hierbei ein Aufruf an die Webschnittstelle von FHEM abgesetzt.
* FHEM führt den Befehl aus

Hört sich langsam und kompliziert an? Kompliziert: Okay. Langsam eher nicht, in etlichen Fällen liegt die Gesamtantwortszeit unter 200 ms.

Soweit ein erster Überblick über die Datenflüsse. Im Abschnitt Sicherheit ist das Konzept der Absicherung deutlich genauer und ausführlicher beschrieben.

==Installation==

Du wirst bei der Installation zuerst auf der Kommandozeile auf Deinem Raspberry (o.ä.) unterwegs sein, anschließend im Webfrontend von FHEM, und zum Schluss auf der Alexa-Konsole im Web.

===node.js installieren===

Ab Jessy liegt NodeJS bereits in einer ausreichend aktuellen Version vor (Stretch und Buster funktionieren ebenfalls). Mit

<syntaxhighlight lang="bash" style="width:50%;">
sudo apt-get install nodejs npm
</syntaxhighlight>

kannst Du es installieren. Mit
<syntaxhighlight lang="bash" style="width:50%;">
node --version
</syntaxhighlight>

erfährst Du die aktuelle Version - wenn hier etwas mit "8" oder höher vorneweg erscheint, ist alles gut.
Ansonsten suche Dir bitte eine Anleitung im Web, wie Du NodeJS auf Deinem System auf einen aktuellen Stand bringen kannst.

=== Alexa-FHEM installieren ===

Nun installieren wir Alexa-fhem aus dem offiziellen Repository:

<syntaxhighlight lang="bash" style="width:50%;">
sudo npm install -g alexa-fhem
</syntaxhighlight>

Der Vorgang benötigt etwas Zeit.

=== Alexa-FHEM aktivieren ===

Wechsele jetzt in FHEM-Web!

Wichtig ist, dass das Alexa-Modul in der Version ab Januar 2019 vorliegt. Dafür bitte einmal FHEM aktualisieren:
Speichern der Config nicht vergessen, und

<syntaxhighlight lang="bash" style="width:50%;">
update
shutdown restart
</syntaxhighlight>

Alles, was jetzt noch nötig ist, ist das Anlegen eines Alexa-Devices. Gib dafür in der FHEM-Web-Kommandozeile

<syntaxhighlight lang="bash" style="width:50%;">
define alexa alexa
</syntaxhighlight>

an. Nun läuft, während Du bereits das neu angelegte Alexa-Devices siehst, ein komplexer Prozess im Hintergrund:

* Falls noch kein SSH-Key für den Benutzer, unter dem FHEM läuft, existiert, wird einer generiert
* Es wird ein Secret-Key im Prozess generiert, dass den Server nicht verlässt, und der Skillanmeldung dient.
* Du wirst auf dem Server "va-fhem.fhem.de" des FHEM-Vereins mit dem SSH-Key angemeldet, und der Hash-Wert Deines Secret-Key dort abgelegt.

Und wenn Du diese Sätze gelesen hast, sollte inzwischen sich das Alexa-Device in FHEM-Web aktualisiert haben, und
ungefähr so aussehen:

[[Datei:Alexa-Device-2.png|800px]]

Neben dem Status für alexa-fhem und der Proxyverbindung ist wichtig, dass diese beiden Zeilen beim Reload aufgetaucht sind:

<syntaxhighlight lang="bash" style="width:90%;">
alexaFHEM.bearerToken crypt:...
alexaFHEM.skillRegKey crypt:...
</syntaxhighlight>

Ja, und diesen Schlüssel benötigst Du wirklich! Also am besten schon einmal mit

<syntaxhighlight lang="bash" style="width:90%;">
get <alexa> proxyKey
</syntaxhighlight>

in Klartext anzeigen lassen und in ein Editor-Fenster dauerhaft wegsichern.

Jetzt solltest Du Dein Alexa-Device nicht mehr löschen, denn das im Reading angezeigte "bearerToken" zu löschen bedeutet, dass die Software die Zugriffe von nicht mehr überprüfen kann und keine Kommandos mehr funktionieren. In diesem Fall hilft nur die Neuinstallation des Skills.

==== Fehler bei der Aktivierung ====

Während kompliziertere Fehlerfälle im Abschnitt "Mögliche Probleme und Lösungen" behandelt werden, hier häufige Fälle, warum die kryptischen Zeilen nicht auftauchen:

* Zuerst bitte einfach einmal die Seite neu laden.

===== 401: Authorization Required =====

Wenn Du FHEM-Web mit einem User/Passwort-Schutz versehen hast, wirst du folgende Fehlermeldung sehen:

<syntaxhighlight lang="bash" style="width:90%;">
alexaFHEM stopped; failed to connect to fhem: 401: Authorization Required
</syntaxhighlight>

In der Regel musst du die Angaben User/Passwort noch einmal explizit setzen. Im Attribute-Abschnitt "alexaFHEM-auth" auswählen, User/Passwort mit ":" getrennt angeben und "attr" anklicken. alexa-fhem wird automatisch neu gestartet. Hier das Ganze in der Text-Variante:

<syntaxhighlight lang="bash" style="width:90%;">
attr alexa alexaFHEM-auth user:pass
</syntaxhighlight>

===== Permission denied =====

Wenn du folgende Fehlermeldungen im Alexa Logfile siehst, wurde das Verzeichnis "/opt/fhem/.ssh/" von dir bei der Arbeit mit "root" oder "sudo" mit den falschen Berechtigungen versehen:

<syntaxhighlight lang="bash" style="width:90%;">
[2019-7-25 11:59:12] sshautoconf: aborted with ssh-keygen returned error - key_save_private: Permission denied
[2019-7-25 11:59:12] *** SSH: proxy configuration failed: ssh-keygen returned error - key_save_private: Permission denied
</syntaxhighlight>

Prüfen kannst du die Berechtigungen mit folgendem Befehl auf der Shell-Konsole:

<syntaxhighlight lang="bash" style="width:90%;">
ls -l /opt/fhem/.ssh
</syntaxhighlight>

Du solltest dann folgende Ausgabe erhalten:

<syntaxhighlight lang="bash" style="width:90%;">
insgesamt 12
-rw------- 1 fhem dialout 1675 Jul 12 13:10 id_rsa
-rw-r--r-- 1 fhem dialout 391 Jul 12 13:10 id_rsa.pub
-rw-r--r-- 1 fhem dialout 884 Jul 12 13:10 known_hosts
</syntaxhighlight>

Steht in der Ausgabe nicht "fhem dialout" (dein fhem User), sondern bspw. "root root", dann bspw. mit folgendem Befehl an deinen fhem User anpassen:

<syntaxhighlight lang="bash" style="width:90%;">
chown fhem:dialout /opt/fhem/.ssh
</syntaxhighlight>

Mit dem ersten Befehl "ls -l ..." kannst du dann nochmal prüfen, ob die Berechtigungen korrekt übernommen wurden.

===== weitere Prüfungen =====

Hast Du noch die Shell-Konsole offen? Dann prüfe bitte noch einmal auf der Konsole, ob nun zwei Prozesse laufen:

<syntaxhighlight lang="bash" style="width:50%;">
ps -ef | egrep '(alexa|ssh)'
</syntaxhighlight>

sollte Dir idealerweise so etwas anzeigen:
<syntaxhighlight lang="bash" style="width:90%;">
fhem 31322 1 99 13:56 ? 00:00:03 alexa
fhem 31332 31322 8 13:56 ? 00:00:00 /usr/bin/ssh -R 1234:127.0.0.1:<zufälliger port> -oServerAliveInterval=90 -p 58824 fhem-va.fhem.de
</syntaxhighlight>

"alexa" ist dabei der Node-JS-Prozess, der ssh-Prozess ist die aufgebaute Verbindung zum Vereinsserver.

Wenn Du diese Prozesse '''nicht''' siehst oder das Alexa-Device keinen Registrierungskey anzeigt, dann ist leider der Start nicht glatt verlaufen.

Im Logfile (über den link <code>Logfile</code> in der Detail-Ansicht über <code>set</code>, oder über den Namen bei ''currentlogfile'' in den Internals) findest Du idealerweise selber Hinweise, wo es hakt, oder kannst im Forum nachfragen.

=== Geräte im FHEM-Webfrontend zuweisen ===
Um das Aha-Erlebnis zu vergrößern, ist jetzt ein guter Zeitpunkt, 1 oder besser mind. 2 Geräte für den Alexa-Dienst zuzuweisen. Von Haus aus wird keines Deiner FHEM-Geräte automatisch Alexa zugewiesen!

Wähle die Geräte aus, rufe sie auf und setze das Attribut "alexaName". Hierbei in Kürze nur der Hinweis:
* Keine Angst vor Leerzeichen und Umlauten, funktioniert.
* Große Angst vor Rechtschreibfehlern (Terrasse, Rollladen) oder komplizierten Wörtern "handgebastelte Martinslaterne im Kinderzimmer Iphigenie-Chantal".
* Mehrere Namen für dasselbe Gerät/Device in fhem werden unterstützt. Mehrere Namen werden durch Strichpunkt getrennt.
* Das Attribut "alexaRoom" ist NUR FÜR DEN CUSTOM SKILL relevant. Ausnahme: structure und LightScene Devices, siehe: [[FHEM_Connector_f%C3%BCr_Amazon_Alexa#Was_geht_alles_.3F]].

Lade die Geräte neu in die Software, indem Du <code>set <alexa> restart</code> ausführst!
[[Datei:HowToSet alexaName.png|alternativtext=How to set alexaName|ohne|mini|Wie setzt man das Attribut alexaName]]

'''Anmerkungen (weil oft gestellte Fragen im Forum) bzgl. Erkennung von Geräten:'''

* Wichtig ist, dass die Filtereinstellung in der alexa-fhem.cfg (zu finden unter "Edit Files") passt.
Das, was dort eingetragen ist (Standard: alexaName=..* / also es ist ein alexaName vergeben) auch an den entsprechenden Devices in fhem vorhanden ist.
Stimmt das nicht überein, kann alexa-fhem keine Devices von fhem abfragen/finden.
Ob der Filter entsprechend funktioniert kann man wie folgt testen: ''list Filtereinstellung'' beispiel mit Standardfilter: ''list alexaName=..*''

* Hat alexa-fhem per Filter Devices aus fhem "gefunden", geht es weiter mit der "Erkennung". Also um welches Device (Typ und "Fähigkeiten") handelt es sich. Dazu gilt folgendes:
** sind entsprechende Readings beim Device vorhanden (z.B. temperature, state mit on/off, ...) erkennt das alexa-fhem automatisch. Die Liste der automatisch erkannten Readings wächst ständig. Daher erst mal schauen ob das Device bereits entsprechend erkannt (typisiert) wurde. Das kann durch prüfen des alexa-fhem-Logs geschehen (NICHT fhem-log!).
** sind entsprechende "set-Befehle" erkennbar (oft auch durch Readings). Also ist beispielsweise (wie beim Dummy nötig) ein ''setList'' mit entsprechenden Einträgen vorhanden oder entsprechende Readings, z.B. desired-temp zum Stellen der Temperatur etc.
** wird das Device nicht richtig oder "unvollständig" erkannt helfen folgende Attribute:
*** genericDeviceType: hiermit kann alexa-fhem in die gewünschte Richtung "geschubbst" werden. Anmerkung: man kann nicht alles erzwingen, Readings bzw. set-Befehle müssen passen (oder per homebridgeMapping passend gemacht werden). Wenn ein genericDeviceType nicht per "Drop-Down" erscheint, dann kann er auch (wenn bekannt) einfach per WEB-cmd eingegeben werden: ''attr Devicename genericDeviceType media''
*** homebridgeMapping: hierdurch kann alexa-fhem bei der Erkennung von Zuständen und möglichen Einstellungen (also WAS kann das Device) unterstützt werden. Mittels homebridgeMapping können vorhandene Readings (Zustände) auf für alexa-fhem bekannte Zustände gemappt werden. Ebenso können damit Standard-fhem-Kommandos von alexa-fhem auf Device-spezifische gemappt werden. Beispiel: on/off auf Ein/Aus (falls das Device statt on/off eben ein Ein/Aus erwartet). Zum Beispiel: <syntaxhighlight lang="bash" style="width:50%;">
attr <thermostat> homebridgeMapping TargetTemperature=target::target,minValue=18,maxValue=25,minStep=0.5 CurrentTemperature=myTemp:temperature
</syntaxhighlight> [https://github.com/justme-1968/homebridge-fhem/blob/master/README.md weitere Beispiele]

Mehrere Namen für dasselbe Gerät/Device in fhem ist möglich. Die Namen werden durch Strichpunkt getrennt.
Beispiel:
<code>attr dmLampe alexaName Lichtkuppel;Lichtkugel</code>

'''Anmerkung bzgl. genericDeviceType und homebridgeMapping:''' 
* diese Attribute werden von verschiedenen "Sprachsteuerungsmodulen" in fhem verwendet (homebridge [dort wurde es "erfunden"], alexa-fhem, gassistant, ...). Daher ist nicht jedes Mapping für alle "Dienste" verwendbar. Ausprobieren schadet aber nicht.
* ebenso kann man mit diesen Attributen (homebridgeMapping wird gerne so "missbraucht") nichts erzwingen, was seitens Amazon/Alexa nicht unterstützt bzw. verstanden wird! D.h. zunächst ist zu prüfen, ob ein bestimmter (gewünschter) Sprachbefehl seitens Amazon/Alexa unterstützt wird! Aktuelles Beispiel (Stand Jan 2020): "Alexa, fahre den Rollo hoch/runter". Da ist Amazon/Alexa gerade dabei etwas zu tun. Bislang wird das nicht unterstützt, also ist das auch mit einem entsprechenden homebridgeMapping nicht zu erzwingen! Was unterstützt wird kann man bei Amazon nachlesen: [https://developer.amazon.com/es-ES/docs/alexa/device-apis/list-of-interfaces.html]

== Finale: Skill verknüpfen ==
Suche im WebFrontend oder der Alexa-App den Skill "FHEM Connector". Für nicht-Mac/iOS Anwerder empfiehlt das WebFrontend (https://alexa.amazon.de) statt die App, damit Du den Anmeldeschlüssel auch bequem kopieren kannst.

Wenn du noch nicht bei Amazon angemeldet bist, erwartet Amazon zunächst, dass Du Dich normal bei Amazon anmeldest.

Sobald Du "FHEM Connector" aktivierst, öffnet sich ein Browser-Tab mit folgender Maske: 
[[Datei:FHEMlazy_login.png|240px]]

Hier kopierst Du Deinen Anmeldeschlüssel (im Klartext!) hinein und klickst auf Check. Als glücklicher Mensch ist auf der folgenden Statusseite alles grün: 
[[Datei:FHEMlazy_check.png|240px]]

Im Einzelnen wird hier geprüft, ob Du per SSH verbunden bist (und auch Deine IP zur Sicherheit angezeigt), ob der Reverse-Tunnel steht, ob nodeJS erreichbar ist und wie viele Geräte Alexa gleich finden sollte (in meinem Fall 22).

Sollte etwas nicht grün sein und Du eine Idee zum Fixen haben, kannst Du mit "Retry" neue Versuche auslösen.

Ist alles okay, klicke rechts den Button "Activate Skill". Du springst damit wieder zurück zu Amazon, die Dir hoffentlich zur erfolgreichen Verknüpfung gratulieren.

Amazon möchte nun unmittelbar die Gerätesuche starten, und unter SmartHome-Geräte sollten diese nun auftauchen.

== Was geht alles ? ==

* Geräte, die sich ein- und ausschalten lassen:
** Automatisch: Müssen <code>set on</code> und <code>set off</code> Kommandos haben
** dummys müssen <code>setList</code> mit on und off haben
** Über <code>genericDeviceType</code> switch bzw. light kann bestimmt werden ob es in alexa als Schalter oder Licht behandelt wird.
** Wenn die Set-Kommandos im FHEM Device anders benannt sind: homebridgeMapping On:cmdOn=<ein>,cmdOff=<aus> setzen
** Kommandos:
***Alexa, schalte <name> ein/aus
***Alexa, Licht an/aus
***Alexa, schalte <gruppe> ein/aus
* Geräte, die eine Temperatur messen
** Automatisch: Es muss ein Reading <code>temperature</code> geben
** Über <code>genericDeviceType</code> thermometer
** Sonst: homebridgeMapping CurrentTemperature:reading=<reading>

* Geräte, deren Helligkeit sich ändern lässt
** Automatisch: wenn <code>dim</code> oder <code>pct</code> Kommandos erkannt werden
** Über <code>genericDeviceType</code> light
** Über homebridgeMapping: Wenn <code>helligkeit</code> das Reading für die aktuelle Helligkeit enthält und die Helligkeit mit <code>set <device> prozent xxx</code> gesetzt wird, sieht das homebridgeMapping wie folgt aus: homebridgeMapping Brightness=helligkeit::prozent,minValue=0,maxValue=<maximalwert>
** Kommandos:
*** Alexa, mache <name> heller/dunkler
*** Alexa, Licht heller/dunkler
* Geräte, deren Farbe sich ändern lässt
** ...

* Geräte, deren Farbtemperatur sich ändern lässt
** ...

* Geräte, bei denen sich eine Lautstärke einstellen lässt
** ...

* Geräte, bei denen sich ein prozentualer Wert einstellen lässt
** Automatisch: wenn <code>dim</code> oder <code>pct</code> Kommandos erkannt werden
** ...

* elektrische Türschlösser
** <code>genericDeviceType</code>: lock
** homebridgeMapping mit LockCurrentState und LockTargetState

* Thermostate
** Über <code>genericDeviceType</code> thermostate
** ...

* structure Devices aus FHEM (ab alexa-fhem version 0.5.7)
** können mit <code>genericDeviceType</code> scene als Szene eingebunden werden
** über <code>alexaRoom</code> kann der name um einen Ort ergänzt werden
** Szenen aus einer structure lassen sich ein- und ausschalten
** Wichtig:
*** Ein Skill darf nur 12 Szenen automatisch erkennen und einbinden.

* LightScene Devices aus FHEM (ab alexa-fhem version 0.5.8)
** können mit <code>genericDeviceType</code> scene als Szenen eingebunden werden
** über <code>alexaRoom</code> kann der name um einen Ort ergänzt werden
** Szenen aus einer LightScene lassen sich nur einschalten
** Wichtig:
*** Ein Skill darf nur 12 Szenen automatisch erkennen und einbinden.

* Geräte, deren Kanal sich umschalten lässt (ab alexa-fhem version 0.5.13)
** Über <code>genericDeviceType</code> media
** homebridgeMapping ChannelController:reading=<reading>,cmd=<cmd>
** Erlaubte Werte siehe hier: https://developer.amazon.com/de/docs/device-apis/alexa-channelcontroller.html#changechannel
** ...

* Geräte, deren Playback status sich schalten lässt (ab alexa-fhem version 0.5.13)
** Über <code>genericDeviceType</code> media
** homebridgeMapping PlaybackController:playback,values=Play;Pause;Stop;Previous;Next
** Erlaubte Werte siehe hier: https://developer.amazon.com/de/docs/device-apis/alexa-playbackcontroller.html#discovery
** ...

* Geräte, deren Eingang sich umschalten lässt (ab alexa-fhem version 0.5.13)
** Über <code>genericDeviceType</code> media
** homebridgeMapping InputController:reading=<reading>,cmd=<cmd>,values=HDMI+1;HDMI+2;XBOX
** Erlaubte Werte siehe hier: https://developer.amazon.com/de/docs/device-apis/alexa-property-schemas.html#input
** ...

* Kontaktsensoren (ab alexa-fhem version 0.5.15)
** Über <code>genericDeviceType</code> contact
** homebridgeMapping ContactSensorState:reading=<reading> oder CurrentDoorState:reading=<reading>
** Die Anzeige in der Alexa-App funktioniert sofort, die Abfrage per Sprache erst ab Version 0.5.27.

* Geräte, deren Lautstärke sich ändern lässt (ab alexa-fhem version 0.5.24)
** Über <code>genericDeviceType</code> speaker
** Automatisch: es muss ein Reading <code>volume</code> und/oder <code>mute</code> geben
** homebridgeMapping Volume:reading=<reading>,cmd=<cmd> Mute:reading=<reading>,cmd=<cmd>
** ...

* Geräte, die sich ein- (und optional) ausschalten lassen als Szene (ab alexa-fhem version 0.5.26)
** Über <code>genericDeviceType</code> scene
** Automatisch: Müssen <code>set on</code> und <code>set off</code> Kommandos haben
** homebridgeMapping On:reading=<reading>,cmdOn=<cmd>[,cmdOff=<cmd>]
** Hinweis: Fehlende Kommandos lassen sich mit cmdalias erzeugen
** Wichtig:
*** Ein Skill darf nur 12 Szenen automatisch erkennen und einbinden.
* Rollläden. Lange ein Problemthema, das nur mit "Schalte auf 0%, schalte auf 100% lief". Wichtig: "alexa-fhem" ab Version 0.5.39 einsetzen. GenericDevice-Type auf "blind" setzen. Nach Restart von alexa-fhem und neuer Gerätesuche sollte folgendes funktionieren:
** "..., öffne <Name> ganz"
** "..., schließe <Name> komplett"
** "hoch" und "runter" (ohne "ganz" oder "komplett") schalten jeweils nur einen bestimmten Prozentsatz hoch oder runter. Dieser kann mit <code>attr <name> homebridgeMapping TargetPosition:minStep=<wert></code>geändert werden. Aber Achtung: In diesem Intervall kann dann auch nur noch ein absoluter Prozentwert per Sprache oder Slider eingestellt werden! Bei z.B. 25% würden 13% zu 25% aufgerundet, 12% zu 0% abgerundet werden.
* Kontaktsensoren (ab alexa-fhem version 0.5.47)
** Automatisch wenn ein Reading <code>motion</code> vorhanden ist oder es sich um einen Zigbee bewgungsmelder an einer HUE oder deCONZ Bridge handelt
** Über <code>genericDeviceType</code> MotionSensor
** homebridgeMapping MotionDetected:reading=<reading>,values=<wert für bewgung>:1;<wert für keine bewegung>:0

* Alarmmelder (noch nicht in Deutschland):
** genericDeviceType Security
** homebridgeMapping Alarm=<reading>[,type=[fireAlarm|waterAlarm|burglaryAlarm|carbonMonoxideAlarm]]
** wenn der type nicht angegeben wird ist fireAlarm der default
** automatisch werden 0, ok und alles was mit no anfängt als OK erkannt. alles andere gilt als ALARM.

Es werden noch einige andere häufig verwendete Geräte (Homematic, hue,...) automatisch erkannt.

to be continued ...

In der [https://developer.amazon.com/docs/device-apis/list-of-interfaces.html List of Capability Interfaces] bei Amazon kann man sehen, welche Möglichkeiten das Smart Home Skill API aktuell in einzelnen Ländern bietet. Leider ohne die jeweiligen landessprachlichen Kommandos.

=== Aktiv Routinen starten ===
Routinen (eine Funktionalität, die rein - genauso wie "Räume" - bei Amazon liegt und nicht von FHEM Connector beeinflusst wird) waren lange die ewige Antwort auf die Frage: "Meine Frau möchte aber '''Öffne Rollläden''<nowiki/>' sagen": In der Alexa-App gibt es im Menü den Punkt "Routinen", und hier lässt sich eine gewisse Anzahl von Aktionen (unter optionalen Bedingungen) an ein Sprachkommando knüpfen.

Neu: Routinen können inzwischen auch von Skills getriggert werden, und seit Version 0.5.47 (Februar 2020) auch von FHEM Connector. Das braucht niemand, um die Rollläden hochzufahren, denn das kann FHEM ja selber, aber um z.B. eine Ansage auf einem Alexa-Gerät zu triggern. Dafür gibt es auch das FHEM-Modul "echodevice", aber es erfordert ein paar Klimmzüge. Mit dem aktiven Triggern von Routinen kann FHEM auslösen, dass Alexa ungefragt (!) Dinge wie

''"Die Temperatur in der Tiefkühltruhe hat -16 Grad überschritten"''

in den Raum sagt. Also eine Alternative bzw. Ergänzung zu Alarmen / Erinnerungen per Telegram o.ä.

'''Vorgeschichte''':

Die Smarthome-Skill-API von Amazon sah schon lange das "proactiveReporting" vor: Also z.B. die gemessene Temperatur nicht erst auf Anfrage hin zu übermitteln, sondern laufend aktiv zu pushen. Aber warum Daten an Amazon senden, wenn es dafür keinen Mehrwert gibt? Beim Öffnen z.B. des Thermostaten in der Alexa-App kommen ohnehin laufend Statusabfragen. Warum also einen Datenpool bei Amazon über die Haustemperatur aufbauen und Änderungen pushen, wenn es keinen Mehrwert dafür gibt?

Inzwischen lassen sich (reale oder vermeintliche) Änderungen von ''Bewegungssensoren'' und ''Fensterkontakten'' als Startbedingung an Alexa-Routinen koppeln. Man kann in der Alexa-App (ggf. fiktive) Öffnen eines Fensterkontaktes an das Aufsagen eines freien Textes durch die Hausbutlerin knüpfen.

'''Umsetzung''':
* Jedes Alexa-Device, dessen Status aktiv zu Amazon gepusht werden soll, im Attribut "alexaProactiveEvents" mit einer "1" versehen. Per Default wird ''kein'' Gerät laufend aktiv zu Amazon gepusht!
* das geänderte Device einmal zu Amazon pushen "set <alexa> add <device>" (oder 'Alexa, suche neue Geräte' murmeln)
* Das Gerät sollte jetzt beim Anlegen einer neuen Routine ("Neue Routine", "Wenn Folgendes passiert", "Smart Home") als möglicher Triggerpunkt erscheinen.

==== Dummygeräte: ====
Ein Dummydevice sollte einen Kontaktschalter oder Bewegungssensor simulieren, um dann in FHEM eine beliebige Bedingung als Trigger zu definieren, und eine freie Ansage in Alexa als Routine zu definieren. Hier ein Beispiel:

<syntaxhighlight lang="bash" style="width:90%;">
define voicetrigger1 dummy
attr voicetrigger1 alexaName Trigger 1
attr voicetrigger1 alexaProactiveEvents 1
attr voicetrigger1 genericDeviceType contact
attr voicetrigger1 homebridgeMapping ContactSensorState=state,values=closed:CONTACT_DETECTED;;open:CONTACT_NOT_DETECTED
attr voicetrigger1 readingList 0:closed 1:open
attr voicetrigger1 setList closed open

set alexa add voicetrigger1
set alexa restart
</syntaxhighlight>

'''Fehlersuche:'''

Der Push setzt ein intaktes Push-Token voraus. Sollte im Alexa-Logfile Folgendes erscheinen:

<code>failed to refresh token: invalid_grant: 'The request has an invalid grant parameter : refresh_token'</code>

so ist das Push-Token nicht aktuell. Weil die Auswirkung lange nur war, dass Geräteänderungen nicht aktiv an Amazon gemeldet wurden, gibt es noch keine umfassende Analyse des Problems. Es lässt sich lösen, indem eine oder beide folgenden Aktionen ausgeführt werden:
* Löschen des ".eventToken" im Alexa-Device über "deletereading"
* "FHEM-Connector"-Skill auf "alexa.amazon.de" einmal deaktivieren und dann neu verbinden

== Mögliche Probleme und Lösungen ==

Es kann vorkommen, dass Geräte zwar korrekt erkannt werden, aber das durch Alexa erkannte Kommando nicht richtig umgesetzt wird (Beispiel - mittlerweile behoben: {{Link2Forum|Topic=96766}}). Neben dem FHEM-Log gibt es noch das Logfile, welches von alexa-fhem angelegt wird.

=== Fehlersuche über die FHEM-Oberfläche ===

* alexa-fhem Logfile anschauen (Detail-Ansicht des <alexa>-Device aufrufen, klick auf '''Logfile''' oben)
* alexa-fhem im Debug-Modus aufrufen:
** -D zum alexaFHEM-params attribut hinzufügen
** Alexa-Befehl auslösen
** -D aus dem alexaFHEM-params attribut entfernen
* Die notwendigen Informationen finden sich in dem alexa-Logfile (siehe oben)

=== Fehlersuche über Kommandozeile (lies: Shell) + FHEM-Oberfläche ===

:* set <alexa> stop (FHEM-Oberfläche)
:* Auf der Kommandozeile <code>alexa-fhem -D -c /opt/fhem/alexa-fhem.cfg > debug.log</code> starten (dadurch wird die Datei debug.log erzeugt im aktuellen Verzeichnis)
:* Alexa-Befehl auslösen
:* alexa-fhem auf der Kommandozeile wieder stoppen (CTRL-C)
:* set <alexa> start (FHEM-Oberfläche)

Die Datei debug.log sollte Hinweise enthalten, wie das Problem zu lösen ist oder Dich zumindest in die richtige Richtung schieben.

Im Beispiel aus dem Forum fand sich in dem Logfile der Hinweis darauf, dass das Device mit falschen min/max-Werten unterwegs war.

=== Registrierungskey vergessen, Registrierung zurücksetzen ===

Auf der Kommandoshell:

<syntaxhighlight lang="bash" style="width:90%;">
pi@raspberrypi:~# sudo -u fhem ssh -p 58824 fhem-va.fhem.de status
Registered.
Registered on 2019-01-13T15:38:13Z.
</syntaxhighlight>

heisst, das der Vereinsserver eigentlich alles hat, was er will. Es wird kein neuer Schlüssel generiert.
Wenn Du die Situation zurücksetzen möchtest, wäre die hässliche Methode, Deinen SSH-Key zu löschen. Eleganter ist, die Registrierung auf Vereinsseite zu löschen:

<syntaxhighlight lang="bash" style="width:90%;">
pi@raspberrypi:~# sudo -u fhem ssh -p 58824 fhem-va.fhem.de unregister
Your registration has been removed
</syntaxhighlight>

löscht Deinen Schlüssel mitsamt allen dort gespeicherten Daten auf Vereinsseite. Bei Restart von alexa-fhem in FHEM-WEB wird jetzt ein neuer Registrierungskey angefordert.

== Sicherheitskonzept und Secrets ==

Um diesen Abschnitt zu verstehen, solltest Du den Abschnitt "Arbeitsweise" im Kopf haben. Einerseits ist Dir vermutlich einleuchtend, dass ein Server, der per SSH rückwärts nur ausgewählte Kommandos in den Tunnel, den Du aufgebaut hast, leitet, "irgendwie sicherer" ist. Andererseits möchte man nicht blind vertrauen.

=== SSH ===
==== SSH - macht das nichts Gefährliches? ====
SSH ist ein Veteran des Internet und entstand, um sich sicher (verschlüsselt) und schnell auf Servern einzuloggen. Schon früh wurde dabei der sogenannte "Reverse-Tunnel" implementiert: Also der vom Client (Deinem Rechner) geäußerte Wunsch: "Bitte leite mir Requests, die bei Dir, Server, auf Port xy eingehen, an meinen lokalen Port yz weiter.". Dieses Verfahren implementiert der Reverseproxy, wobei tatsächlich auf dem Server für Dich kein echter Port geöffnet wird.

Wie Dir ggf. sicher der Unix-Guru Deines Vertrauens bestätigen wird: Die Kombination
<syntaxhighlight lang="bash" style="width:50%;">
ssh -R 1234:localhost:<zufälliger port> zielserver
</syntaxhighlight>
erlaubt keine Ausführung von Shell-Kommandos auf Deinem Server, sondern einzig, dass vom SSH-Programm Verbindungen zu einem lokalen Port auf Deinem Server auf dem alexa-fhem lauscht aufgebaut werden. Du kannst also z.B. mit einem
<syntaxhighlight lang="bash" style="width:50%;">
sudo /usr/sbin/tcpdump -X -s 0 -i lo port <zufälliger port>
</syntaxhighlight>
vollständig überwachen (oder ggf. permanent aufzeichen), was auf Deinem Server von außen gesteuert passiert.

==== Wie wird bei SSH verschlüsselt? ====
Im Prinzip wie im Web auf SSL-Seiten, teils mit den gleichen Verschlüsselungsverfahren. Allerdings arbeitet SSH eher wie das im Web recht seltene Verfahren: Bei jeder Verbindung übermitteln sowohl Server wie auch Client den öffentlichen Teil ihres Schlüssels. Anders als im Web wird der Schlüssel aber nicht von einer öffentlichen Zertifizierungsstelle wie "LetsEncrypt" unterschrieben. Stattdessen entscheiden Server wie Client beim ersten Verbindungsaufbau typischerweise per manueller Frage: "Willst Du jetzt und künftig diesem Schlüssel vertrauen?" Bei der Installation wird diese Frage für Deine Seite bejaht, und fortan wird der öffentliche Schlüssel des FHEM-Servers auf Deinem Rechner gespeichert. Ab da bist Du z.B. davor sicher, dass jemand den DNS-Eintrag verbiegt oder sich in den Datenfluss Deines Providers einhängt: Ein geänderter Serverschlüssel würde bemerkt werden.
 
Soweit klar? Aus Deinem öffentlichen Schlüssel wiederum leitet der Server her: "Das ist definitiv wieder derjenige, der sich damals "registriert" hat". Und an dieser Stelle kann ich auch den ersten Teil des 3-teiligen Registrierungskeys erläutern: Die typischerweise 6-stellige Hex-Zahl am Anfang ist der Java-Hashcode Deines öffentlichen Schlüssel. Sie ist damit sozusagen Deine aus Deinem öffentlichen Schlüssel abgeleitete Benutzer-ID.

=== Die Rolle der Secrets ===
Wenn jetzt klar ist, dass die Verbindung zum Vereinsserver sicher und vertauschungsfrei funktioniert, bleiben noch 2 Probleme zu lösen:
1) Im Web bei der Skill-Aktivierung musst Du beweisen, dass Du der Mensch am Browser bist, dem der SSH-Tunnel von IP xy mit dem öffentlichen Schlüssel X gehört. Bei der automatischen Registrierung werden lokal auf Deinem Rechner zwei 64-Bit-Secrets generiert:
* Das Anmelde-Secret
* Das Bearer-Token
Beim Anmelden des SSH-Keys auf dem öffentlichen Server wird nun der Hashwert des ersten Secrets übertragen und dort in Verbindung mit Deinem öffentlichen Schlüssel gespeichert. Ein Hashwert bedeutet, dass (sofern das Verfahren, hier SHA256, funktioniert), niemand aus dem Hash das Secret zurückrechnen kann. Ein Datenbankklau auf dem Server gefährdet also nicht die Sicherheit Deines Passwortes.

Wenn Du nun beim Skill-Aktivieren den Registrierungskey eingibst, dann "sieht" der Server zum ersten Mal Dein ausgewürfeltes Secret, vergleicht es mit dem Hashwert und wird es anschließend wieder umgehend vergessen. Anhand des Hashwertes kann der Server aber entscheiden, dass Du der legitime Nutzer zum öffentlichen Schlüssel XY bist.

2) Das zweite Problem ist: Wie soll Amazon "beweisen", dass sie der legitime Aufrufer sind? Amazon erhält binnen wenigen Sekunden nach dem Klick auf "Activate Skill" den dritten Teil des Registrierungskeys als sogenanntes Bearer-Token. Zwar läuft er durch den Registrierungsserver, er wird dort, auf dem Registrierungs/Vereinsserver aber nicht gespeichert. Das Bearer-Token wird von Amazon bei allen Requests zu Deinem Server mitgesendet. Da es am Anfang zusätzlich Deine "User-ID" enthält, weiß der Vereinsserver, zu welchem SSH-Tunnel der Request zu senden ist. Aber lokal auf Deinem Rechner wird ausgewertet, ob das Token "stimmt".

== alexa-fhem Updaten bzw. "Upgraden" ==

'''Updaten einer "Connector" Installation:'''
* alexa-fhem über FHEM anhalten (Name des Alexa-Device: alexa):
:<syntaxhighlight lang="perl" style="width:50%;">set alexa stop</syntaxhighlight>

*Auf der Konsole wie anfangs bei der Installation:
:<syntaxhighlight lang="bash" style="width:50%;">sudo npm update -g alexa-fhem</syntaxhighlight>

:Manchmal hat npm Probleme mit einem Update. Dann einfach die aktuelle Version noch mal drüber Installieren:

:<syntaxhighlight lang="bash" style="width:50%;">sudo npm install -g alexa-fhem</syntaxhighlight>

*alexa-fhem über FHEM wieder starten:
:<syntaxhighlight lang="perl" style="width:50%;">set alexa start</syntaxhighlight>

'''"Upgraden von einer "Nicht-Connector" Installation (z.B. manuelle Installation per pm-Download):'''
* Daten der aktuellen Installation sichern (v.a. config.json / man weiß ja nie)
* Autostart der aktuellen alexa-fhem Installation deaktivieren:
** Bei initd: Service deaktivieren mittels: <code>sudo update-rc.d -f alexa remove</code> Vorher mittels stoppen: <code>sudo service alexa stop</code> Startscript unter /etc/init.d/ löschen.
** Bei systemd: Service deaktivieren mittels: <code>sudo systemctl disable alexa</code> Vorher mittels stoppen: <code>sudo systemctl alexa stop</code> Startscript unter /etc/systemd/system/ löschen.
* ALLE vorhandenen alexa-fhem Daten LÖSCHEN! Bleiben Dinge zurück und wird dann laut Connector installiert kann es zu Problemen kommen!
* (reboot)
* Installation von alexa-fhem laut Anleitung (Beginn dieses Wiki)
* Falls eigene Dinge von früher genutzt werden wollen/sollen (z.B. Custom Skill), dann die entsprechenden Einträge aus der gesicherten config.json in die neu angelegte alexa-fhem.cfg (zu finden unter "Edit files") übernehmen.
* Werden keine eigenen Dinge verwendet, dann kann der Port (Standard: 3000) geschlossen werden und auch die Daten unter Amazon-Developer können gelöscht werden.

== Bug- und Wunschliste ==
* Ist beim Start keine Internetverbindung vorhanden, erfolgt kein Retry -- alexa-fhem muss restartet werden (ssh_autoconfig wertet keine temporären Fehler aus)

==Weitergehende Informationen==
*[[Alexa und Mappings]]
*[[Alexa Tipps und Kniffe]]
*[[FHEM Connector for Amazon Alexa]]
[[Kategorie:HOWTOS]]
[[Kategorie:Sprachsteuerung]]

FHEM Connector für Amazon Alexa

2020-06-01T13:56:14Z

MadMax-FHEM:

{{Baustelle}}
'''Alexa FHEMlazy''' war historisch ein Fork des Original [[Alexa-Fhem|alexa-fhem]], der im Januar 2019 mit dem Original zusammengeführt wurde und nun als '''FHEM Connector''' verfügbar ist.

Er ermöglicht innerhalb von Minuten die Verknüpfung von FHEM mit einem Amazon Echo Gerät. Auch Geräte anderer Hersteller mit verbauten Mikrofonen und Alexa-Sprachassistenten-Unterstützung sollten problemlos funktionieren. Für folgende Geräte ist dies bspw. der Fall (Falls Ihr andere/weitere Gerätemodelle bzw. Hersteller in Verwendung habt, bitte hier pflegen):

* SONOS Beam und SONOS One

Gegenüber dem klassischen Ansatz ergeben sich Einschränkungen, so läuft die Software normalerweise unter dem gleichen Benutzer wie FHEM auf dem gleichen Server, und es wird z.Zt. nur der Smarthome-Skill unterstützt (die Variante, bei der die Möglichkeiten der Interaktion von Amazon festgelegt wurden).
Dafür ist weder ein Developer-Account bei Amazon, eigene Lambda- und Skillfunktionen, noch das Öffnen eines eingehenden Ports aus dem Internet nötig.
* Die Software integriert einen Installer, der die Erstkonfiguration und Anmeldung übernimmt
* Die Kommunikation zur Software auf dem heimischen Rechner und dann zu FHEM verläuft über SSH und einen vom FHEM-Verein gehosteten Server
* Funktioniert mit IPv4, IPv6, echtem Dual Stack und DS-Lite
* Als Skill bei Amazon wird der Skill "FHEM Connector" verwendet.

Der Thread im Forum zur Software ist hier: {{Link2Forum|Topic=94817}}.

{{Infobox Modul
|ModPurpose=Einfache Anbindung von FHEM an Amazon Assistent Alexa
|ModType=h
|ModCmdRef=alexa
|ModTechName=39_alexa.pm / alexa-fhem
|ModForumArea=Frontends/Sprachsteuerung
|ModOwner=gvzdus, André/ justme1968 ({{Link2FU|430|Forum}} / [[Benutzer Diskussion:Justme|Wiki]])
}}

==Einführung==

===Arbeitsweise und Datenfluss===
Vorläufig ist alexa-fhem im "FHEM Connector-Modus" ein reiner [https://developer.amazon.com/de/docs/smarthome/understand-the-smart-home-skill-api.html SmartHome-Skill].
SmartHome-Skills erhalten weder die Sprachdaten selber noch das, was Amazon in Textform verstanden hat, sondern vielmehr extrahiert Amazon aus dem verstandenen Text Anweisungen und Abfragen für Geräte, die dann an den Skill übermittelt werden. Charmant ist dabei, dass unmittelbar gefragt werden kann "Alexa, wie ist die Temperatur im Wohnzimmer?", während andere Skills zunächst explizit angesprochen werden müssen ("Alexa, frage FHEM nach der Temperatur im Wohnzimmer"). Außerdem kann der Nutzer mehrere Smarthome-Skills installieren, und die Geräte werden zu einer Gesamtmenge zusammengefasst.

Gehen wir den Datenfluss bei der konkreten Frage "Wie ist die Temperatur im Wohnzimmer?" durch:
* Alexa hat bei der Skillinstallation gelernt, dass "FHEM Connector" bei Dir einen Thermostaten im Raum Wohnzimmer kennt. Dadurch wird bei der Sprachanalyse von "Alexa Voice Service" in der Cloud erkannt, dass eine Abfrage an "FHEM Connector" erfolgversprechend ist.
* Zunächst wird die zentrale "Lambda-Funktion" von "FHEM Connector" aufgerufen. Die Funktion leitet aber im Kern nur den Request unverändert an den vom Verein bereitgestellten Server weiter. Im Request enthalten ist ein Token, das sogenannte "Bearer-Token".
* Der "Vereinsserver" prüft anhand dieses Tokens, ob es überhaupt bekannt ist, und zu welchem Nutzer es gehört. Ist dieser Nutzer verbunden, wird der Request wiederum quasi unverändert an den Nutzer weitergeleitet.
* Diese Weiterleitung passiert über einen sogenannten SSH-Reverse-Tunnel, der von Deiner Seite und der Software auf dem FHEM-Tunnel automatisch aufgebaut wird.
* Auf Deiner Seite läuft die eigentliche Software, und zwar unter nodeJS. nodeJS ist ein Javascript ausführender Miniserver, der lokal auf einem Zufallsport auf Requests "lauscht". In der Original-Version [[Alexa-Fhem|Alexa FHEM]] kommen die Requests aus dem Internet (hoffentlich von der eigenen Lambda-Funktion), hier bei "FHEM Connector" kommen sie ausschließlich aus dem SSH-Tunnel von lokal.
* Die Software validiert nun diesen Request anhand des Bearer-Tokens. Konkret wird dabei das bei der Installation generierte Token, dass bei der Skill-Aktivierung an Amazon übertragen wurde, mit dem lokal gespeicherten Wert verglichen. Stimmt das Token, wird der Befehl verarbeitet, üblicherweise wird hierbei ein Aufruf an die Webschnittstelle von FHEM abgesetzt.
* FHEM führt den Befehl aus

Hört sich langsam und kompliziert an? Kompliziert: Okay. Langsam eher nicht, in etlichen Fällen liegt die Gesamtantwortszeit unter 200 ms.

Soweit ein erster Überblick über die Datenflüsse. Im Abschnitt Sicherheit ist das Konzept der Absicherung deutlich genauer und ausführlicher beschrieben.

==Installation==

Du wirst bei der Installation zuerst auf der Kommandozeile auf Deinem Raspberry (o.ä.) unterwegs sein, anschließend im Webfrontend von FHEM, und zum Schluss auf der Alexa-Konsole im Web.

===node.js installieren===

Ab Jessy liegt NodeJS bereits in einer ausreichend aktuellen Version vor (Stretch und Buster funktionieren ebenfalls). Mit

<syntaxhighlight lang="bash" style="width:50%;">
sudo apt-get install nodejs npm
</syntaxhighlight>

kannst Du es installieren. Mit
<syntaxhighlight lang="bash" style="width:50%;">
node --version
</syntaxhighlight>

erfährst Du die aktuelle Version - wenn hier etwas mit "8" oder höher vorneweg erscheint, ist alles gut.
Ansonsten suche Dir bitte eine Anleitung im Web, wie Du NodeJS auf Deinem System auf einen aktuellen Stand bringen kannst.

=== Alexa-FHEM installieren ===

Nun installieren wir Alexa-fhem aus dem offiziellen Repository:

<syntaxhighlight lang="bash" style="width:50%;">
sudo npm install -g alexa-fhem
</syntaxhighlight>

Der Vorgang benötigt etwas Zeit.

=== Alexa-FHEM aktivieren ===

Wechsele jetzt in FHEM-Web!

Wichtig ist, dass das Alexa-Modul in der Version ab Januar 2019 vorliegt. Dafür bitte einmal FHEM aktualisieren:
Speichern der Config nicht vergessen, und

<syntaxhighlight lang="bash" style="width:50%;">
update
shutdown restart
</syntaxhighlight>

Alles, was jetzt noch nötig ist, ist das Anlegen eines Alexa-Devices. Gib dafür in der FHEM-Web-Kommandozeile

<syntaxhighlight lang="bash" style="width:50%;">
define alexa alexa
</syntaxhighlight>

an. Nun läuft, während Du bereits das neu angelegte Alexa-Devices siehst, ein komplexer Prozess im Hintergrund:

* Falls noch kein SSH-Key für den Benutzer, unter dem FHEM läuft, existiert, wird einer generiert
* Es wird ein Secret-Key im Prozess generiert, dass den Server nicht verlässt, und der Skillanmeldung dient.
* Du wirst auf dem Server "va-fhem.fhem.de" des FHEM-Vereins mit dem SSH-Key angemeldet, und der Hash-Wert Deines Secret-Key dort abgelegt.

Und wenn Du diese Sätze gelesen hast, sollte inzwischen sich das Alexa-Device in FHEM-Web aktualisiert haben, und
ungefähr so aussehen:

[[Datei:Alexa-Device-2.png|800px]]

Neben dem Status für alexa-fhem und der Proxyverbindung ist wichtig, dass diese beiden Zeilen beim Reload aufgetaucht sind:

<syntaxhighlight lang="bash" style="width:90%;">
alexaFHEM.bearerToken crypt:...
alexaFHEM.skillRegKey crypt:...
</syntaxhighlight>

Ja, und diesen Schlüssel benötigst Du wirklich! Also am besten schon einmal mit

<syntaxhighlight lang="bash" style="width:90%;">
get <alexa> proxyKey
</syntaxhighlight>

in Klartext anzeigen lassen und in ein Editor-Fenster dauerhaft wegsichern.

Jetzt solltest Du Dein Alexa-Device nicht mehr löschen, denn das im Reading angezeigte "bearerToken" zu löschen bedeutet, dass die Software die Zugriffe von nicht mehr überprüfen kann und keine Kommandos mehr funktionieren. In diesem Fall hilft nur die Neuinstallation des Skills.

==== Fehler bei der Aktivierung ====

Während kompliziertere Fehlerfälle im Abschnitt "Mögliche Probleme und Lösungen" behandelt werden, hier häufige Fälle, warum die kryptischen Zeilen nicht auftauchen:

* Zuerst bitte einfach einmal die Seite neu laden.

===== 401: Authorization Required =====

Wenn Du FHEM-Web mit einem User/Passwort-Schutz versehen hast, wirst du folgende Fehlermeldung sehen:

<syntaxhighlight lang="bash" style="width:90%;">
alexaFHEM stopped; failed to connect to fhem: 401: Authorization Required
</syntaxhighlight>

In der Regel musst du die Angaben User/Passwort noch einmal explizit setzen. Im Attribute-Abschnitt "alexaFHEM-auth" auswählen, User/Passwort mit ":" getrennt angeben und "attr" anklicken. alexa-fhem wird automatisch neu gestartet. Hier das Ganze in der Text-Variante:

<syntaxhighlight lang="bash" style="width:90%;">
attr alexa alexaFHEM-auth user:pass
</syntaxhighlight>

===== Permission denied =====

Wenn du folgende Fehlermeldungen im Alexa Logfile siehst, wurde das Verzeichnis "/opt/fhem/.ssh/" von dir bei der Arbeit mit "root" oder "sudo" mit den falschen Berechtigungen versehen:

<syntaxhighlight lang="bash" style="width:90%;">
[2019-7-25 11:59:12] sshautoconf: aborted with ssh-keygen returned error - key_save_private: Permission denied
[2019-7-25 11:59:12] *** SSH: proxy configuration failed: ssh-keygen returned error - key_save_private: Permission denied
</syntaxhighlight>

Prüfen kannst du die Berechtigungen mit folgendem Befehl auf der Shell-Konsole:

<syntaxhighlight lang="bash" style="width:90%;">
ls -l /opt/fhem/.ssh
</syntaxhighlight>

Du solltest dann folgende Ausgabe erhalten:

<syntaxhighlight lang="bash" style="width:90%;">
insgesamt 12
-rw------- 1 fhem dialout 1675 Jul 12 13:10 id_rsa
-rw-r--r-- 1 fhem dialout 391 Jul 12 13:10 id_rsa.pub
-rw-r--r-- 1 fhem dialout 884 Jul 12 13:10 known_hosts
</syntaxhighlight>

Steht in der Ausgabe nicht "fhem dialout" (dein fhem User), sondern bspw. "root root", dann bspw. mit folgendem Befehl an deinen fhem User anpassen:

<syntaxhighlight lang="bash" style="width:90%;">
chown fhem:dialout /opt/fhem/.ssh
</syntaxhighlight>

Mit dem ersten Befehl "ls -l ..." kannst du dann nochmal prüfen, ob die Berechtigungen korrekt übernommen wurden.

===== weitere Prüfungen =====

Hast Du noch die Shell-Konsole offen? Dann prüfe bitte noch einmal auf der Konsole, ob nun zwei Prozesse laufen:

<syntaxhighlight lang="bash" style="width:50%;">
ps -ef | egrep '(alexa|ssh)'
</syntaxhighlight>

sollte Dir idealerweise so etwas anzeigen:
<syntaxhighlight lang="bash" style="width:90%;">
fhem 31322 1 99 13:56 ? 00:00:03 alexa
fhem 31332 31322 8 13:56 ? 00:00:00 /usr/bin/ssh -R 1234:127.0.0.1:<zufälliger port> -oServerAliveInterval=90 -p 58824 fhem-va.fhem.de
</syntaxhighlight>

"alexa" ist dabei der Node-JS-Prozess, der ssh-Prozess ist die aufgebaute Verbindung zum Vereinsserver.

Wenn Du diese Prozesse '''nicht''' siehst oder das Alexa-Device keinen Registrierungskey anzeigt, dann ist leider der Start nicht glatt verlaufen.

Im Logfile (über den link <code>Logfile</code> in der Detail-Ansicht über <code>set</code>, oder über den Namen bei ''currentlogfile'' in den Internals) findest Du idealerweise selber Hinweise, wo es hakt, oder kannst im Forum nachfragen.

=== Geräte im FHEM-Webfrontend zuweisen ===
Um das Aha-Erlebnis zu vergrößern, ist jetzt ein guter Zeitpunkt, 1 oder besser mind. 2 Geräte für den Alexa-Dienst zuzuweisen. Von Haus aus wird keines Deiner FHEM-Geräte automatisch Alexa zugewiesen!

Wähle die Geräte aus, rufe sie auf und setze das Attribut "alexaName". Hierbei in Kürze nur der Hinweis:
* Keine Angst vor Leerzeichen und Umlauten, funktioniert.
* Große Angst vor Rechtschreibfehlern (Terrasse, Rollladen) oder komplizierten Wörtern "handgebastelte Martinslaterne im Kinderzimmer Iphigenie-Chantal".
* mehrere Namen für dasselbe Gerät/Device in fhem werden unterstützt. Mehrere Namen werden durch Strichpunkt getrennt.
* Das Attribut "alexaRoom" ist NUR FÜR DEN CUSTOM SKILL relevant. Ausnahme: structure und LightScene Devices, siehe: [[FHEM_Connector_f%C3%BCr_Amazon_Alexa#Was_geht_alles_.3F]].

Lade die Geräte neu in die Software, indem Du <code>set <alexa> restart</code> ausführst!
[[Datei:HowToSet alexaName.png|alternativtext=How to set alexaName|ohne|mini|Wie setzt man das Attribut alexaName]]

'''Anmerkungen (weil oft gestellte Fragen im Forum) bzgl. Erkennung von Geräten:'''

* Wichtig ist, dass die Filtereinstellung in der alexa-fhem.cfg (zu finden unter "Edit Files") passt.
Das, was dort eingetragen ist (Standard: alexaName=..* / also es ist ein alexaName vergeben) auch an den entsprechenden Devices in fhem vorhanden ist.
Stimmt das nicht überein, kann alexa-fhem keine Devices von fhem abfragen/finden.
Ob der Filter entsprechend funktioniert kann man wie folgt testen: ''list Filtereinstellung'' beispiel mit Standardfilter: ''list alexaName=..*''

* Hat alexa-fhem per Filter Devices aus fhem "gefunden", geht es weiter mit der "Erkennung". Also um welches Device (Typ und "Fähigkeiten") handelt es sich. Dazu gilt folgendes:
** sind entsprechende Readings beim Device vorhanden (z.B. temperature, state mit on/off, ...) erkennt das alexa-fhem automatisch. Die Liste der automatisch erkannten Readings wächst ständig. Daher erst mal schauen ob das Device bereits entsprechend erkannt (typisiert) wurde. Das kann durch prüfen des alexa-fhem-Logs geschehen (NICHT fhem-log!).
** sind entsprechende "set-Befehle" erkennbar (oft auch durch Readings). Also ist beispielsweise (wie beim Dummy nötig) ein ''setList'' mit entsprechenden Einträgen vorhanden oder entsprechende Readings, z.B. desired-temp zum Stellen der Temperatur etc.
** wird das Device nicht richtig oder "unvollständig" erkannt helfen folgende Attribute:
*** genericDeviceType: hiermit kann alexa-fhem in die gewünschte Richtung "geschubbst" werden. Anmerkung: man kann nicht alles erzwingen, Readings bzw. set-Befehle müssen passen (oder per homebridgeMapping passend gemacht werden). Wenn ein genericDeviceType nicht per "Drop-Down" erscheint, dann kann er auch (wenn bekannt) einfach per WEB-cmd eingegeben werden: ''attr Devicename genericDeviceType media''
*** homebridgeMapping: hierdurch kann alexa-fhem bei der Erkennung von Zuständen und möglichen Einstellungen (also WAS kann das Device) unterstützt werden. Mittels homebridgeMapping können vorhandene Readings (Zustände) auf für alexa-fhem bekannte Zustände gemappt werden. Ebenso können damit Standard-fhem-Kommandos von alexa-fhem auf Device-spezifische gemappt werden. Beispiel: on/off auf Ein/Aus (falls das Device statt on/off eben ein Ein/Aus erwartet). Zum Beispiel: <syntaxhighlight lang="bash" style="width:50%;">
attr <thermostat> homebridgeMapping TargetTemperature=target::target,minValue=18,maxValue=25,minStep=0.5 CurrentTemperature=myTemp:temperature
</syntaxhighlight> [https://github.com/justme-1968/homebridge-fhem/blob/master/README.md weitere Beispiele]

'''Anmerkung bzgl. genericDeviceType und homebridgeMapping:''' 
* diese Attribute werden von verschiedenen "Sprachsteuerungsmodulen" in fhem verwendet (homebridge [dort wurde es "erfunden"], alexa-fhem, gassistant, ...). Daher ist nicht jedes Mapping für alle "Dienste" verwendbar. Ausprobieren schadet aber nicht.
* ebenso kann man mit diesen Attributen (homebridgeMapping wird gerne so "missbraucht") nichts erzwingen, was seitens Amazon/Alexa nicht unterstützt bzw. verstanden wird! D.h. zunächst ist zu prüfen, ob ein bestimmter (gewünschter) Sprachbefehl seitens Amazon/Alexa unterstützt wird! Aktuelles Beispiel (Stand Jan 2020): "Alexa, fahre den Rollo hoch/runter". Da ist Amazon/Alexa gerade dabei etwas zu tun. Bislang wird das nicht unterstützt, also ist das auch mit einem entsprechenden homebridgeMapping nicht zu erzwingen! Was unterstützt wird kann man bei Amazon nachlesen: [https://developer.amazon.com/es-ES/docs/alexa/device-apis/list-of-interfaces.html]

== Finale: Skill verknüpfen ==
Suche im WebFrontend oder der Alexa-App den Skill "FHEM Connector". Für nicht-Mac/iOS Anwerder empfiehlt das WebFrontend (https://alexa.amazon.de) statt die App, damit Du den Anmeldeschlüssel auch bequem kopieren kannst.

Wenn du noch nicht bei Amazon angemeldet bist, erwartet Amazon zunächst, dass Du Dich normal bei Amazon anmeldest.

Sobald Du "FHEM Connector" aktivierst, öffnet sich ein Browser-Tab mit folgender Maske: 
[[Datei:FHEMlazy_login.png|240px]]

Hier kopierst Du Deinen Anmeldeschlüssel (im Klartext!) hinein und klickst auf Check. Als glücklicher Mensch ist auf der folgenden Statusseite alles grün: 
[[Datei:FHEMlazy_check.png|240px]]

Im Einzelnen wird hier geprüft, ob Du per SSH verbunden bist (und auch Deine IP zur Sicherheit angezeigt), ob der Reverse-Tunnel steht, ob nodeJS erreichbar ist und wie viele Geräte Alexa gleich finden sollte (in meinem Fall 22).

Sollte etwas nicht grün sein und Du eine Idee zum Fixen haben, kannst Du mit "Retry" neue Versuche auslösen.

Ist alles okay, klicke rechts den Button "Activate Skill". Du springst damit wieder zurück zu Amazon, die Dir hoffentlich zur erfolgreichen Verknüpfung gratulieren.

Amazon möchte nun unmittelbar die Gerätesuche starten, und unter SmartHome-Geräte sollten diese nun auftauchen.

== Was geht alles ? ==

* Geräte, die sich ein- und ausschalten lassen:
** Automatisch: Müssen <code>set on</code> und <code>set off</code> Kommandos haben
** dummys müssen <code>setList</code> mit on und off haben
** Über <code>genericDeviceType</code> switch bzw. light kann bestimmt werden ob es in alexa als Schalter oder Licht behandelt wird.
** Wenn die Set-Kommandos im FHEM Device anders benannt sind: homebridgeMapping On:cmdOn=<ein>,cmdOff=<aus> setzen
** Kommandos:
***Alexa, schalte <name> ein/aus
***Alexa, Licht an/aus
***Alexa, schalte <gruppe> ein/aus
* Geräte, die eine Temperatur messen
** Automatisch: Es muss ein Reading <code>temperature</code> geben
** Über <code>genericDeviceType</code> thermometer
** Sonst: homebridgeMapping CurrentTemperature:reading=<reading>

* Geräte, deren Helligkeit sich ändern lässt
** Automatisch: wenn <code>dim</code> oder <code>pct</code> Kommandos erkannt werden
** Über <code>genericDeviceType</code> light
** Über homebridgeMapping: Wenn <code>helligkeit</code> das Reading für die aktuelle Helligkeit enthält und die Helligkeit mit <code>set <device> prozent xxx</code> gesetzt wird, sieht das homebridgeMapping wie folgt aus: homebridgeMapping Brightness=helligkeit::prozent,minValue=0,maxValue=<maximalwert>
** Kommandos:
*** Alexa, mache <name> heller/dunkler
*** Alexa, Licht heller/dunkler
* Geräte, deren Farbe sich ändern lässt
** ...

* Geräte, deren Farbtemperatur sich ändern lässt
** ...

* Geräte, bei denen sich eine Lautstärke einstellen lässt
** ...

* Geräte, bei denen sich ein prozentualer Wert einstellen lässt
** Automatisch: wenn <code>dim</code> oder <code>pct</code> Kommandos erkannt werden
** ...

* elektrische Türschlösser
** <code>genericDeviceType</code>: lock
** homebridgeMapping mit LockCurrentState und LockTargetState

* Thermostate
** Über <code>genericDeviceType</code> thermostate
** ...

* structure Devices aus FHEM (ab alexa-fhem version 0.5.7)
** können mit <code>genericDeviceType</code> scene als Szene eingebunden werden
** über <code>alexaRoom</code> kann der name um einen Ort ergänzt werden
** Szenen aus einer structure lassen sich ein- und ausschalten
** Wichtig:
*** Ein Skill darf nur 12 Szenen automatisch erkennen und einbinden.

* LightScene Devices aus FHEM (ab alexa-fhem version 0.5.8)
** können mit <code>genericDeviceType</code> scene als Szenen eingebunden werden
** über <code>alexaRoom</code> kann der name um einen Ort ergänzt werden
** Szenen aus einer LightScene lassen sich nur einschalten
** Wichtig:
*** Ein Skill darf nur 12 Szenen automatisch erkennen und einbinden.

* Geräte, deren Kanal sich umschalten lässt (ab alexa-fhem version 0.5.13)
** Über <code>genericDeviceType</code> media
** homebridgeMapping ChannelController:reading=<reading>,cmd=<cmd>
** Erlaubte Werte siehe hier: https://developer.amazon.com/de/docs/device-apis/alexa-channelcontroller.html#changechannel
** ...

* Geräte, deren Playback status sich schalten lässt (ab alexa-fhem version 0.5.13)
** Über <code>genericDeviceType</code> media
** homebridgeMapping PlaybackController:playback,values=Play;Pause;Stop;Previous;Next
** Erlaubte Werte siehe hier: https://developer.amazon.com/de/docs/device-apis/alexa-playbackcontroller.html#discovery
** ...

* Geräte, deren Eingang sich umschalten lässt (ab alexa-fhem version 0.5.13)
** Über <code>genericDeviceType</code> media
** homebridgeMapping InputController:reading=<reading>,cmd=<cmd>,values=HDMI+1;HDMI+2;XBOX
** Erlaubte Werte siehe hier: https://developer.amazon.com/de/docs/device-apis/alexa-property-schemas.html#input
** ...

* Kontaktsensoren (ab alexa-fhem version 0.5.15)
** Über <code>genericDeviceType</code> contact
** homebridgeMapping ContactSensorState:reading=<reading> oder CurrentDoorState:reading=<reading>
** Die Anzeige in der Alexa-App funktioniert sofort, die Abfrage per Sprache erst ab Version 0.5.27.

* Geräte, deren Lautstärke sich ändern lässt (ab alexa-fhem version 0.5.24)
** Über <code>genericDeviceType</code> speaker
** Automatisch: es muss ein Reading <code>volume</code> und/oder <code>mute</code> geben
** homebridgeMapping Volume:reading=<reading>,cmd=<cmd> Mute:reading=<reading>,cmd=<cmd>
** ...

* Geräte, die sich ein- (und optional) ausschalten lassen als Szene (ab alexa-fhem version 0.5.26)
** Über <code>genericDeviceType</code> scene
** Automatisch: Müssen <code>set on</code> und <code>set off</code> Kommandos haben
** homebridgeMapping On:reading=<reading>,cmdOn=<cmd>[,cmdOff=<cmd>]
** Hinweis: Fehlende Kommandos lassen sich mit cmdalias erzeugen
** Wichtig:
*** Ein Skill darf nur 12 Szenen automatisch erkennen und einbinden.
* Rollläden. Lange ein Problemthema, das nur mit "Schalte auf 0%, schalte auf 100% lief". Wichtig: "alexa-fhem" ab Version 0.5.39 einsetzen. GenericDevice-Type auf "blind" setzen. Nach Restart von alexa-fhem und neuer Gerätesuche sollte folgendes funktionieren:
** "..., öffne <Name> ganz"
** "..., schließe <Name> komplett"
** "hoch" und "runter" (ohne "ganz" oder "komplett") schalten jeweils nur einen bestimmten Prozentsatz hoch oder runter. Dieser kann mit <code>attr <name> homebridgeMapping TargetPosition:minStep=<wert></code>geändert werden. Aber Achtung: In diesem Intervall kann dann auch nur noch ein absoluter Prozentwert per Sprache oder Slider eingestellt werden! Bei z.B. 25% würden 13% zu 25% aufgerundet, 12% zu 0% abgerundet werden.
* Kontaktsensoren (ab alexa-fhem version 0.5.47)
** Automatisch wenn ein Reading <code>motion</code> vorhanden ist oder es sich um einen Zigbee bewgungsmelder an einer HUE oder deCONZ Bridge handelt
** Über <code>genericDeviceType</code> MotionSensor
** homebridgeMapping MotionDetected:reading=<reading>,values=<wert für bewgung>:1;<wert für keine bewegung>:0

* Alarmmelder (noch nicht in Deutschland):
** genericDeviceType Security
** homebridgeMapping Alarm=<reading>[,type=[fireAlarm|waterAlarm|burglaryAlarm|carbonMonoxideAlarm]]
** wenn der type nicht angegeben wird ist fireAlarm der default
** automatisch werden 0, ok und alles was mit no anfängt als OK erkannt. alles andere gilt als ALARM.

Es werden noch einige andere häufig verwendete Geräte (Homematic, hue,...) automatisch erkannt.

to be continued ...

In der [https://developer.amazon.com/docs/device-apis/list-of-interfaces.html List of Capability Interfaces] bei Amazon kann man sehen, welche Möglichkeiten das Smart Home Skill API aktuell in einzelnen Ländern bietet. Leider ohne die jeweiligen landessprachlichen Kommandos.

=== Aktiv Routinen starten ===
Routinen (eine Funktionalität, die rein - genauso wie "Räume" - bei Amazon liegt und nicht von FHEM Connector beeinflusst wird) waren lange die ewige Antwort auf die Frage: "Meine Frau möchte aber '''Öffne Rollläden''<nowiki/>' sagen": In der Alexa-App gibt es im Menü den Punkt "Routinen", und hier lässt sich eine gewisse Anzahl von Aktionen (unter optionalen Bedingungen) an ein Sprachkommando knüpfen.

Neu: Routinen können inzwischen auch von Skills getriggert werden, und seit Version 0.5.47 (Februar 2020) auch von FHEM Connector. Das braucht niemand, um die Rollläden hochzufahren, denn das kann FHEM ja selber, aber um z.B. eine Ansage auf einem Alexa-Gerät zu triggern. Dafür gibt es auch das FHEM-Modul "echodevice", aber es erfordert ein paar Klimmzüge. Mit dem aktiven Triggern von Routinen kann FHEM auslösen, dass Alexa ungefragt (!) Dinge wie

''"Die Temperatur in der Tiefkühltruhe hat -16 Grad überschritten"''

in den Raum sagt. Also eine Alternative bzw. Ergänzung zu Alarmen / Erinnerungen per Telegram o.ä.

'''Vorgeschichte''':

Die Smarthome-Skill-API von Amazon sah schon lange das "proactiveReporting" vor: Also z.B. die gemessene Temperatur nicht erst auf Anfrage hin zu übermitteln, sondern laufend aktiv zu pushen. Aber warum Daten an Amazon senden, wenn es dafür keinen Mehrwert gibt? Beim Öffnen z.B. des Thermostaten in der Alexa-App kommen ohnehin laufend Statusabfragen. Warum also einen Datenpool bei Amazon über die Haustemperatur aufbauen und Änderungen pushen, wenn es keinen Mehrwert dafür gibt?

Inzwischen lassen sich (reale oder vermeintliche) Änderungen von ''Bewegungssensoren'' und ''Fensterkontakten'' als Startbedingung an Alexa-Routinen koppeln. Man kann in der Alexa-App (ggf. fiktive) Öffnen eines Fensterkontaktes an das Aufsagen eines freien Textes durch die Hausbutlerin knüpfen.

'''Umsetzung''':
* Jedes Alexa-Device, dessen Status aktiv zu Amazon gepusht werden soll, im Attribut "alexaProactiveEvents" mit einer "1" versehen. Per Default wird ''kein'' Gerät laufend aktiv zu Amazon gepusht!
* das geänderte Device einmal zu Amazon pushen "set <alexa> add <device>" (oder 'Alexa, suche neue Geräte' murmeln)
* Das Gerät sollte jetzt beim Anlegen einer neuen Routine ("Neue Routine", "Wenn Folgendes passiert", "Smart Home") als möglicher Triggerpunkt erscheinen.

==== Dummygeräte: ====
Ein Dummydevice sollte einen Kontaktschalter oder Bewegungssensor simulieren, um dann in FHEM eine beliebige Bedingung als Trigger zu definieren, und eine freie Ansage in Alexa als Routine zu definieren. Hier ein Beispiel:

<syntaxhighlight lang="bash" style="width:90%;">
define voicetrigger1 dummy
attr voicetrigger1 alexaName Trigger 1
attr voicetrigger1 alexaProactiveEvents 1
attr voicetrigger1 genericDeviceType contact
attr voicetrigger1 homebridgeMapping ContactSensorState=state,values=closed:CONTACT_DETECTED;;open:CONTACT_NOT_DETECTED
attr voicetrigger1 readingList 0:closed 1:open
attr voicetrigger1 setList closed open

set alexa add voicetrigger1
set alexa restart
</syntaxhighlight>

'''Fehlersuche:'''

Der Push setzt ein intaktes Push-Token voraus. Sollte im Alexa-Logfile Folgendes erscheinen:

<code>failed to refresh token: invalid_grant: 'The request has an invalid grant parameter : refresh_token'</code>

so ist das Push-Token nicht aktuell. Weil die Auswirkung lange nur war, dass Geräteänderungen nicht aktiv an Amazon gemeldet wurden, gibt es noch keine umfassende Analyse des Problems. Es lässt sich lösen, indem eine oder beide folgenden Aktionen ausgeführt werden:
* Löschen des ".eventToken" im Alexa-Device über "deletereading"
* "FHEM-Connector"-Skill auf "alexa.amazon.de" einmal deaktivieren und dann neu verbinden

== Mögliche Probleme und Lösungen ==

Es kann vorkommen, dass Geräte zwar korrekt erkannt werden, aber das durch Alexa erkannte Kommando nicht richtig umgesetzt wird (Beispiel - mittlerweile behoben: {{Link2Forum|Topic=96766}}). Neben dem FHEM-Log gibt es noch das Logfile, welches von alexa-fhem angelegt wird.

=== Fehlersuche über die FHEM-Oberfläche ===

* alexa-fhem Logfile anschauen (Detail-Ansicht des <alexa>-Device aufrufen, klick auf '''Logfile''' oben)
* alexa-fhem im Debug-Modus aufrufen:
** -D zum alexaFHEM-params attribut hinzufügen
** Alexa-Befehl auslösen
** -D aus dem alexaFHEM-params attribut entfernen
* Die notwendigen Informationen finden sich in dem alexa-Logfile (siehe oben)

=== Fehlersuche über Kommandozeile (lies: Shell) + FHEM-Oberfläche ===

:* set <alexa> stop (FHEM-Oberfläche)
:* Auf der Kommandozeile <code>alexa-fhem -D -c /opt/fhem/alexa-fhem.cfg > debug.log</code> starten (dadurch wird die Datei debug.log erzeugt im aktuellen Verzeichnis)
:* Alexa-Befehl auslösen
:* alexa-fhem auf der Kommandozeile wieder stoppen (CTRL-C)
:* set <alexa> start (FHEM-Oberfläche)

Die Datei debug.log sollte Hinweise enthalten, wie das Problem zu lösen ist oder Dich zumindest in die richtige Richtung schieben.

Im Beispiel aus dem Forum fand sich in dem Logfile der Hinweis darauf, dass das Device mit falschen min/max-Werten unterwegs war.

=== Registrierungskey vergessen, Registrierung zurücksetzen ===

Auf der Kommandoshell:

<syntaxhighlight lang="bash" style="width:90%;">
pi@raspberrypi:~# sudo -u fhem ssh -p 58824 fhem-va.fhem.de status
Registered.
Registered on 2019-01-13T15:38:13Z.
</syntaxhighlight>

heisst, das der Vereinsserver eigentlich alles hat, was er will. Es wird kein neuer Schlüssel generiert.
Wenn Du die Situation zurücksetzen möchtest, wäre die hässliche Methode, Deinen SSH-Key zu löschen. Eleganter ist, die Registrierung auf Vereinsseite zu löschen:

<syntaxhighlight lang="bash" style="width:90%;">
pi@raspberrypi:~# sudo -u fhem ssh -p 58824 fhem-va.fhem.de unregister
Your registration has been removed
</syntaxhighlight>

löscht Deinen Schlüssel mitsamt allen dort gespeicherten Daten auf Vereinsseite. Bei Restart von alexa-fhem in FHEM-WEB wird jetzt ein neuer Registrierungskey angefordert.

== Sicherheitskonzept und Secrets ==

Um diesen Abschnitt zu verstehen, solltest Du den Abschnitt "Arbeitsweise" im Kopf haben. Einerseits ist Dir vermutlich einleuchtend, dass ein Server, der per SSH rückwärts nur ausgewählte Kommandos in den Tunnel, den Du aufgebaut hast, leitet, "irgendwie sicherer" ist. Andererseits möchte man nicht blind vertrauen.

=== SSH ===
==== SSH - macht das nichts Gefährliches? ====
SSH ist ein Veteran des Internet und entstand, um sich sicher (verschlüsselt) und schnell auf Servern einzuloggen. Schon früh wurde dabei der sogenannte "Reverse-Tunnel" implementiert: Also der vom Client (Deinem Rechner) geäußerte Wunsch: "Bitte leite mir Requests, die bei Dir, Server, auf Port xy eingehen, an meinen lokalen Port yz weiter.". Dieses Verfahren implementiert der Reverseproxy, wobei tatsächlich auf dem Server für Dich kein echter Port geöffnet wird.

Wie Dir ggf. sicher der Unix-Guru Deines Vertrauens bestätigen wird: Die Kombination
<syntaxhighlight lang="bash" style="width:50%;">
ssh -R 1234:localhost:<zufälliger port> zielserver
</syntaxhighlight>
erlaubt keine Ausführung von Shell-Kommandos auf Deinem Server, sondern einzig, dass vom SSH-Programm Verbindungen zu einem lokalen Port auf Deinem Server auf dem alexa-fhem lauscht aufgebaut werden. Du kannst also z.B. mit einem
<syntaxhighlight lang="bash" style="width:50%;">
sudo /usr/sbin/tcpdump -X -s 0 -i lo port <zufälliger port>
</syntaxhighlight>
vollständig überwachen (oder ggf. permanent aufzeichen), was auf Deinem Server von außen gesteuert passiert.

==== Wie wird bei SSH verschlüsselt? ====
Im Prinzip wie im Web auf SSL-Seiten, teils mit den gleichen Verschlüsselungsverfahren. Allerdings arbeitet SSH eher wie das im Web recht seltene Verfahren: Bei jeder Verbindung übermitteln sowohl Server wie auch Client den öffentlichen Teil ihres Schlüssels. Anders als im Web wird der Schlüssel aber nicht von einer öffentlichen Zertifizierungsstelle wie "LetsEncrypt" unterschrieben. Stattdessen entscheiden Server wie Client beim ersten Verbindungsaufbau typischerweise per manueller Frage: "Willst Du jetzt und künftig diesem Schlüssel vertrauen?" Bei der Installation wird diese Frage für Deine Seite bejaht, und fortan wird der öffentliche Schlüssel des FHEM-Servers auf Deinem Rechner gespeichert. Ab da bist Du z.B. davor sicher, dass jemand den DNS-Eintrag verbiegt oder sich in den Datenfluss Deines Providers einhängt: Ein geänderter Serverschlüssel würde bemerkt werden.
 
Soweit klar? Aus Deinem öffentlichen Schlüssel wiederum leitet der Server her: "Das ist definitiv wieder derjenige, der sich damals "registriert" hat". Und an dieser Stelle kann ich auch den ersten Teil des 3-teiligen Registrierungskeys erläutern: Die typischerweise 6-stellige Hex-Zahl am Anfang ist der Java-Hashcode Deines öffentlichen Schlüssel. Sie ist damit sozusagen Deine aus Deinem öffentlichen Schlüssel abgeleitete Benutzer-ID.

=== Die Rolle der Secrets ===
Wenn jetzt klar ist, dass die Verbindung zum Vereinsserver sicher und vertauschungsfrei funktioniert, bleiben noch 2 Probleme zu lösen:
1) Im Web bei der Skill-Aktivierung musst Du beweisen, dass Du der Mensch am Browser bist, dem der SSH-Tunnel von IP xy mit dem öffentlichen Schlüssel X gehört. Bei der automatischen Registrierung werden lokal auf Deinem Rechner zwei 64-Bit-Secrets generiert:
* Das Anmelde-Secret
* Das Bearer-Token
Beim Anmelden des SSH-Keys auf dem öffentlichen Server wird nun der Hashwert des ersten Secrets übertragen und dort in Verbindung mit Deinem öffentlichen Schlüssel gespeichert. Ein Hashwert bedeutet, dass (sofern das Verfahren, hier SHA256, funktioniert), niemand aus dem Hash das Secret zurückrechnen kann. Ein Datenbankklau auf dem Server gefährdet also nicht die Sicherheit Deines Passwortes.

Wenn Du nun beim Skill-Aktivieren den Registrierungskey eingibst, dann "sieht" der Server zum ersten Mal Dein ausgewürfeltes Secret, vergleicht es mit dem Hashwert und wird es anschließend wieder umgehend vergessen. Anhand des Hashwertes kann der Server aber entscheiden, dass Du der legitime Nutzer zum öffentlichen Schlüssel XY bist.

2) Das zweite Problem ist: Wie soll Amazon "beweisen", dass sie der legitime Aufrufer sind? Amazon erhält binnen wenigen Sekunden nach dem Klick auf "Activate Skill" den dritten Teil des Registrierungskeys als sogenanntes Bearer-Token. Zwar läuft er durch den Registrierungsserver, er wird dort, auf dem Registrierungs/Vereinsserver aber nicht gespeichert. Das Bearer-Token wird von Amazon bei allen Requests zu Deinem Server mitgesendet. Da es am Anfang zusätzlich Deine "User-ID" enthält, weiß der Vereinsserver, zu welchem SSH-Tunnel der Request zu senden ist. Aber lokal auf Deinem Rechner wird ausgewertet, ob das Token "stimmt".

== alexa-fhem Updaten bzw. "Upgraden" ==

'''Updaten einer "Connector" Installation:'''
* alexa-fhem über FHEM anhalten (Name des Alexa-Device: alexa):
:<syntaxhighlight lang="perl" style="width:50%;">set alexa stop</syntaxhighlight>

*Auf der Konsole wie anfangs bei der Installation:
:<syntaxhighlight lang="bash" style="width:50%;">sudo npm update -g alexa-fhem</syntaxhighlight>

:Manchmal hat npm Probleme mit einem Update. Dann einfach die aktuelle Version noch mal drüber Installieren:

:<syntaxhighlight lang="bash" style="width:50%;">sudo npm install -g alexa-fhem</syntaxhighlight>

*alexa-fhem über FHEM wieder starten:
:<syntaxhighlight lang="perl" style="width:50%;">set alexa start</syntaxhighlight>

'''"Upgraden von einer "Nicht-Connector" Installation (z.B. manuelle Installation per pm-Download):'''
* Daten der aktuellen Installation sichern (v.a. config.json / man weiß ja nie)
* Autostart der aktuellen alexa-fhem Installation deaktivieren:
** Bei initd: Service deaktivieren mittels: <code>sudo update-rc.d -f alexa remove</code> Vorher mittels stoppen: <code>sudo service alexa stop</code> Startscript unter /etc/init.d/ löschen.
** Bei systemd: Service deaktivieren mittels: <code>sudo systemctl disable alexa</code> Vorher mittels stoppen: <code>sudo systemctl alexa stop</code> Startscript unter /etc/systemd/system/ löschen.
* ALLE vorhandenen alexa-fhem Daten LÖSCHEN! Bleiben Dinge zurück und wird dann laut Connector installiert kann es zu Problemen kommen!
* (reboot)
* Installation von alexa-fhem laut Anleitung (Beginn dieses Wiki)
* Falls eigene Dinge von früher genutzt werden wollen/sollen (z.B. Custom Skill), dann die entsprechenden Einträge aus der gesicherten config.json in die neu angelegte alexa-fhem.cfg (zu finden unter "Edit files") übernehmen.
* Werden keine eigenen Dinge verwendet, dann kann der Port (Standard: 3000) geschlossen werden und auch die Daten unter Amazon-Developer können gelöscht werden.

== Bug- und Wunschliste ==
* Ist beim Start keine Internetverbindung vorhanden, erfolgt kein Retry -- alexa-fhem muss restartet werden (ssh_autoconfig wertet keine temporären Fehler aus)

==Weitergehende Informationen==
*[[Alexa und Mappings]]
*[[Alexa Tipps und Kniffe]]
*[[FHEM Connector for Amazon Alexa]]
[[Kategorie:HOWTOS]]
[[Kategorie:Sprachsteuerung]]

IPCAM

2020-06-01T13:51:20Z

MadMax-FHEM: Umformuliert

{{Infobox Modul
|ModPurpose=Einbindung von Netzwerkkameras
|ModType=d
|ModForumArea=Sonstiges
|ModTechName=49_IPCAM.pm
|ModOwner=mfr69bs ({{Link2FU|6|Martin Fischer}})}}

[[IPCAM]] ermöglicht die ereignis- oder zeitgesteuerte Erzeugung von Mitschnitten bei Netzwerkkameras. Außerdem ist es möglich, die Kamera im PTZ-Modus oder über eigene Befehle zu steuern.

== Voraussetzungen ==
Die Kamera(bilder) müssen über eine URL erreichbar sein.

== Definition ==
Das IPCAM Objekt wird angelegt mit
:<code><nowiki>define <name> IPCAM <ip[:port]> </nowiki></code>

Zusätzlich zum obigen Define muss zwingend noch das ''path'' Attribut gesetzt werden.

== Attribute ==
Die wichtigsten Attribute von ''IPCAM'' werden im Folgenden aufgeführt, die komplette Liste findet sich in der {{Link2CmdRef|Anker=IPCAMattr}}.

=== Authentifizierung ===
;basicauth
:Hinterlegung von Benutzernamen und Passwort

=== Eigene Befehle ===
;cmd01, cmd02, ... cmd15
:Festlegung von Befehlen, die nicht zu den vordefinierten gehören, z.B. <code>attr ipcam cmd01 led_mode=0</code>

=== Vordefinierte Befehle ===
;cmdPanLeft, cmdPanRight, cmdTiltUp, cmdTiltDown, cmdStep
:Diesen Befehlen können die Kameraspezifischen Werte zugeordnet werden, z.B. <code>attr ipcam cmdTiltUp command=0</code>

=== Pfade ===
;path
:...

== Unterstützte Netzwerkkameras ==
{{Randnotiz|RNText=Die Aufzählungen der unterstützten und der problematischen Netzwerkkameras sollten ergänzt werden, sobald neue Erkenntnisse vorliegen; beide Listen sind nicht vollständig.}}
Bei den folgenden Netzwerkkameras ist gesichert, dass sie durch das ''IPCAM'' Modul unterstützt sind:
* {{Link2Forum|Topic=33347|Message=257115|LinkText=Foscam 9805W}}
* Foscam FI9831P
* {{Link2Forum|Topic=13826|LinkText=Instar 2905}}
* {{Link2Forum|Topic=100493|LinkText=IN-8015 Full HD}}
* {{Link2Forum|Topic=36201|LinkText=IN-6001HD}}
* {{Link2Forum|Topic=11664|LinkText=Instar 6011, 6012, 2905}}
* {{Link2Forum|Topic=58676|LinkText=Instar IN-5905HD, IN-5907HD, IN-6014HD, IN-6012HD-PoE}}
* {{Link2Forum|Topic=15217|LinkText=WansView (Modell nicht näher spezifiziert)}}
* {{Link2Forum|Topic=11664|Message=158052|LinkText=Wansview 620, 625, 6012}}
* Axis 205
* D-Link DCS-933
* Mobotix (jedenfalls S26 und Q25)
* Xiaomi Dafang (nur mit alternativer Firmware)

Nicht gesichert, ob die Kamera unterstützt wird bzw. ob alle Funktionen nutzbar sind:
* {{Link2Forum|Topic=33347|LinkText=Foscam FI9831W}}

=== Pfad-Parameter für Axis 205 ===
<pre>
attr Cam1 path /jpg/image.jpg
</pre>

=== Pfad-Parameter für D-Link DCS-933 ===
<pre>attr Cam1 path image.jpg</pre>

=== Parameter für Hikvision DS-2CD2032-I ===
Mit folgenden Parameter wurde (lt. diesem {{Link2Forum|Topic=39932|Message=322269|LinkText=Forenbeitrag}}) die Hikvision DS-2CD2032-I erfolgreich betrieben:
<pre>
define Cam1 IPCAM 192.168.xxx.xxx
attr Cam1 basicauth <username>:<passwort>
attr Cam1 delay 0
attr Cam1 group Kamera
attr Cam1 icon it_camera
attr Cam1 path Streaming/channels/1/picture?snapShotImageType=JPEG
attr Cam1 snapshots 1
attr Cam1 storage /opt/fhem/www/snapshots/cam1
</pre>

=== Pfad-Parameter für Foscam FI9831P ===
Die Version ist ohne basicauth und hat Nutzer und Passwort direkt in der URL. Kann natürlich geändert werden.
Sämtliche Befehle für die Foscam HD Kameras findet man [https://www.manualslib.com/manual/728928/Foscam-Ip-Camera.html hier]
<pre>
define IPKamera IPCAM <ip>:<port>
attr IPKamera cmd01 cmd=ptzStopRun&usr=xxx&pwd=xxx
attr IPKamera cmdPanLeft cmd=ptzMoveLeft&usr=xxx&pwd=xxx
attr IPKamera cmdPanRight cmd=ptzMoveRight&usr=xxx&pwd=xxx
attr IPKamera cmdPos01 cmd=ptzGotoPresetPoint&name=<Nameposition>&usr=xxx&pwd=xxx
attr IPKamera cmdTiltDown cmd=ptzMoveDown&usr=xxx&pwd=xxx
attr IPKamera cmdTiltUp cmd=ptzMoveUp&usr=xxx&pwd=xxx
attr IPKamera path cgi-bin/CGIProxy.fcgi?usr=xxx&pwd=xxx&cmd=snapPicture2
attr IPKamera pathCmd cgi-bin/CGIProxy.fcgi
attr IPKamera pathPanTilt cgi-bin/CGIProxy.fcgi?usr=xxx&pwd=xxx
attr IPKamera storage ./www/images/webcam
</pre>

=== Pfad-Parameter für Mobotix ===
<pre>
attr IPKamera path /record/current.jpg
</pre>

=== Pfad-Parameter für reolink (E1 Zoom) ===
<pre>
attr IPKamera path cgi-bin/api.cgi?cmd=Snap&channel=0&rs=<irgendwas>&user=Username&password=Passwort
</pre>

Beispiel:
<pre>
attr IPKamera path cgi-bin/api.cgi?cmd=Snap&channel=0&rs=12345&user=User&password=Pwd
</pre>

Weitere Befehle sind aktuell noch nicht bekannt.

Es gibt eine spärliche Doku bzgl. cgi hier: https://cdn.reolink.com/wp-content/uploads/2017/01/Reolink-CGI-command-v1.61.pdf

Allerdings wird wohl für die Steuerbefehle (PTZ) ein Post-Request benötigt.

=== Einstellungen für Foscam C2 und Foscam R2 ===
Eine ausführliche Beschreibung zur Benutzung der IP Kameras Foscam C2 und Foscam R2 findet sich in {{Link2Forum|Topic=84677|LinkText=diesem Forenthread}}.

=== Parameter für Xiaomi Dafang ===
Diese Parameter gelten bei installierter alternativer Firmware von [https://github.com/EliasKotlyar/Xiaomi-Dafang-Hacks hier]
<pre>

Attributes:
attr IPKamera cmdPanLeft cmd=motor_left
attr IPKamera cmdPanRight cmd=motor_right
attr IPKamera cmdTiltDown cmd=motor_down
attr IPKamera cmdTiltUp cmd=motor_up
attr IPKamera delay 10
attr IPKamera event-on-update-reading snapshots
attr IPKamera icon it_camera
attr IPKamera path cgi-bin/currentpic.cgi
attr IPKamera pathPanTilt cgi-bin/action.cgi?
attr IPKamera snapshots 5
attr IPKamera storage /opt/fhem/www/ipcamera/dafang_1/shot
</pre>

=== Parameter für INSTAR Full HD ===
Die vollständige Schnittstelle und weitere Beispiele können direkt im [https://wiki.instar.de/Erweitert/ INSTAR-Wiki] eingesehen werden. 
Zur Integration einer INSTAR Full HD CAM können zum Beispiel folgende Attribute verwendet werden:
<pre>
attr INSTAR_8015 basicauth {USERNAME}:{PASSWORD}
attr INSTAR_8015 cmd01 cmd=setinfrared&-infraredstat=auto
attr INSTAR_8015 cmd02 cmd=setinfrared&-infraredstat=close
attr INSTAR_8015 cmd03 cmd=setinfrared&-infraredstat=open
attr INSTAR_8015 cmd04 cmd=setmdalarm&-aname=ftprec&-switch=on
attr INSTAR_8015 cmd05 cmd=setmdalarm&-aname=ftprec&-switch=off
attr INSTAR_8015 cmd06 cmd=setplanrecattr&-planrec_enable=0
attr INSTAR_8015 cmd07 cmd=setplanrecattr&-planrec_enable=1
attr INSTAR_8015 cmd08 cmd=setplanrecattr&-planrec_chn=11
attr INSTAR_8015 cmd09 cmd=setplanrecattr&-planrec_chn=12
attr INSTAR_8015 cmd10 cmd=manualrec&-act=on
attr INSTAR_8015 cmd11 cmd=manualrec&-act=off
attr INSTAR_8015 cmd12 cmd=sdfrmt
attr INSTAR_8015 cmd13 cmd=preset&-act=goto&-number=0
attr INSTAR_8015 cmd14 cmd=preset&-act=goto&-number=1
attr INSTAR_8015 cmd15 cmd=preset&-act=goto&-number=2
attr INSTAR_8015 cmdPanLeft -act=left
attr INSTAR_8015 cmdPanRight -act=right
attr INSTAR_8015 cmdPos15 -act=stop
attr INSTAR_8015 cmdTiltDown -act=down
attr INSTAR_8015 cmdTiltUp -act=up
attr INSTAR_8015 credentials /<ipcam-conf-path>/ipcam.conf
attr INSTAR_8015 eventMap /pos 15:MOVE-STOP/pan left:MOVE-LEFT/pan right:MOVE-RIGHT/tilt up:MOVE-UP/tilt down:MOVE-DOWN/cmd 1:IR-LED-auto/cmd 2:IR-LED-off/cmd 3:IR-LED-on/cmd 4:FTP-rec-on/cmd 5:FTP-rec-off/cmd 6:REC-SD-DISABLE/cmd 7:REC-SD-ENABLE/cmd 8:REC-SD-QUAL-HIGH/cmd 9:REC-SD-QUAL-MID/cmd 10:MAN-REC-Start/cmd 11:MAN-REC-Stop/cmd 12:FORMAT-SD-CARD/cmd 13:POS-WZ/cmd 14:POS-Flur/cmd 15:POS-Park/
attr INSTAR_8015 icon it_camera
attr INSTAR_8015 path tmpfs/snap.jpg
attr INSTAR_8015 pathCmd param.cgi
attr INSTAR_8015 pathPanTilt ptzctrl.cgi?-step=
attr INSTAR_8015 scheme https
attr INSTAR_8015 storage /<ipcam-snapshot-path>/snapshots
attr INSTAR_8015 webCmd POS-WZ:POS-Flur:POS-Park
</pre>

== Nicht unterstützte Netzwerkkameras ==
{{Randnotiz|RNTyp=y|RNText=Die hier aufgeführten Netzwerkkameras sind definitiv nicht unterstützt oder es gibt gravierende, hier beschriebene Einschränkungen.}}
;TRENDnet TV-IP320PI
:Aufruf der Funktion <code>get ''myCam'' image</code> führt zur Fehlermeldung ''...invalid Format''; auf Kamerabild oder Stream kann jedoch über die URL camHostnameOrIP/Streaming/channels/1/Picture (Bild) bzw. camHostnameOrIP/Streaming/channels/1/httpPreview (Stream) zugegriffen werden.

== Generierte Ereignisse ==
Das Modul ''IPCAM'' generiert die Ereignisse
* <code><nowiki>last: <name_of_device>_snapshot.<image_extension></nowiki></code>
* <code><nowiki>snapshots: <total_number_of_taken_snapshots_at_end></nowiki></code>

== Bekannte Probleme ==
Derzeit (08/2015) ist das Logging aus dem Modul zumindest lückenhaft und verbesserungsfähig. So sollten z.B. einige weitere Meldungen zur Fehlereingrenzung bei der Einrichtung eines IPCAM Objekts eingefügt werden:
* Ausgabe des kompletten Pfads / der URL, die bei der Erzeugung eines Snapshots aus einzelnen Bestandteilen zusammengesetzt wird
* Die Zuordnung von Meldungen zu ''verbose''-Leveln sollte kontrolliert und ggf. umgestellt werden
* siehe auch diesen {{Link2Forum|Topic=39932|LinkText=Forenthread}}, der Beschreibung von Problemen, eine Hikvision IPCam in Betrieb zu nehmen

Außerdem müsste das Modul dringend auf die aktuelle Form des Logging, [[verbose|verbose/Log3]], umgestellt werden.

Eine mögliche Lösung für das Problem "Wrong or not supported image format: unknown" habe ich hier beschrieben: {{Link2Forum|Topic=10772|Message=425265|LinkText=Forenbeitrag}}

== Links ==
* Forenthread zur {{Link2Forum|Topic=10772|LinkText=Erweiterung des IPCAM Moduls}}
* Forenthread zum Thema {{Link2Forum|Topic=21005|LinkText=Bewegungserkennung}}
* Forenthread zum Thema {{Link2Forum|Topic=30723|LinkText=Bewegungsmelder der Kamera "anzapfen"}}
* Webseite des Modulautors zum Thema [http://www.fischer-net.de/hausautomation/videoueberwachung.html Videoüberwachung]

IPCAM

2020-06-01T13:49:59Z

MadMax-FHEM: Kleinere Ergänzungen bzgl. cgi

{{Infobox Modul
|ModPurpose=Einbindung von Netzwerkkameras
|ModType=d
|ModForumArea=Sonstiges
|ModTechName=49_IPCAM.pm
|ModOwner=mfr69bs ({{Link2FU|6|Martin Fischer}})}}

[[IPCAM]] ermöglicht die ereignis- oder zeitgesteuerte Erzeugung von Mitschnitten bei Netzwerkkameras. Außerdem ist es möglich, die Kamera im PTZ-Modus oder über eigene Befehle zu steuern.

== Voraussetzungen ==
Die Kamera(bilder) müssen über eine URL erreichbar sein.

== Definition ==
Das IPCAM Objekt wird angelegt mit
:<code><nowiki>define <name> IPCAM <ip[:port]> </nowiki></code>

Zusätzlich zum obigen Define muss zwingend noch das ''path'' Attribut gesetzt werden.

== Attribute ==
Die wichtigsten Attribute von ''IPCAM'' werden im Folgenden aufgeführt, die komplette Liste findet sich in der {{Link2CmdRef|Anker=IPCAMattr}}.

=== Authentifizierung ===
;basicauth
:Hinterlegung von Benutzernamen und Passwort

=== Eigene Befehle ===
;cmd01, cmd02, ... cmd15
:Festlegung von Befehlen, die nicht zu den vordefinierten gehören, z.B. <code>attr ipcam cmd01 led_mode=0</code>

=== Vordefinierte Befehle ===
;cmdPanLeft, cmdPanRight, cmdTiltUp, cmdTiltDown, cmdStep
:Diesen Befehlen können die Kameraspezifischen Werte zugeordnet werden, z.B. <code>attr ipcam cmdTiltUp command=0</code>

=== Pfade ===
;path
:...

== Unterstützte Netzwerkkameras ==
{{Randnotiz|RNText=Die Aufzählungen der unterstützten und der problematischen Netzwerkkameras sollten ergänzt werden, sobald neue Erkenntnisse vorliegen; beide Listen sind nicht vollständig.}}
Bei den folgenden Netzwerkkameras ist gesichert, dass sie durch das ''IPCAM'' Modul unterstützt sind:
* {{Link2Forum|Topic=33347|Message=257115|LinkText=Foscam 9805W}}
* Foscam FI9831P
* {{Link2Forum|Topic=13826|LinkText=Instar 2905}}
* {{Link2Forum|Topic=100493|LinkText=IN-8015 Full HD}}
* {{Link2Forum|Topic=36201|LinkText=IN-6001HD}}
* {{Link2Forum|Topic=11664|LinkText=Instar 6011, 6012, 2905}}
* {{Link2Forum|Topic=58676|LinkText=Instar IN-5905HD, IN-5907HD, IN-6014HD, IN-6012HD-PoE}}
* {{Link2Forum|Topic=15217|LinkText=WansView (Modell nicht näher spezifiziert)}}
* {{Link2Forum|Topic=11664|Message=158052|LinkText=Wansview 620, 625, 6012}}
* Axis 205
* D-Link DCS-933
* Mobotix (jedenfalls S26 und Q25)
* Xiaomi Dafang (nur mit alternativer Firmware)

Nicht gesichert, ob die Kamera unterstützt wird bzw. ob alle Funktionen nutzbar sind:
* {{Link2Forum|Topic=33347|LinkText=Foscam FI9831W}}

=== Pfad-Parameter für Axis 205 ===
<pre>
attr Cam1 path /jpg/image.jpg
</pre>

=== Pfad-Parameter für D-Link DCS-933 ===
<pre>attr Cam1 path image.jpg</pre>

=== Parameter für Hikvision DS-2CD2032-I ===
Mit folgenden Parameter wurde (lt. diesem {{Link2Forum|Topic=39932|Message=322269|LinkText=Forenbeitrag}}) die Hikvision DS-2CD2032-I erfolgreich betrieben:
<pre>
define Cam1 IPCAM 192.168.xxx.xxx
attr Cam1 basicauth <username>:<passwort>
attr Cam1 delay 0
attr Cam1 group Kamera
attr Cam1 icon it_camera
attr Cam1 path Streaming/channels/1/picture?snapShotImageType=JPEG
attr Cam1 snapshots 1
attr Cam1 storage /opt/fhem/www/snapshots/cam1
</pre>

=== Pfad-Parameter für Foscam FI9831P ===
Die Version ist ohne basicauth und hat Nutzer und Passwort direkt in der URL. Kann natürlich geändert werden.
Sämtliche Befehle für die Foscam HD Kameras findet man [https://www.manualslib.com/manual/728928/Foscam-Ip-Camera.html hier]
<pre>
define IPKamera IPCAM <ip>:<port>
attr IPKamera cmd01 cmd=ptzStopRun&usr=xxx&pwd=xxx
attr IPKamera cmdPanLeft cmd=ptzMoveLeft&usr=xxx&pwd=xxx
attr IPKamera cmdPanRight cmd=ptzMoveRight&usr=xxx&pwd=xxx
attr IPKamera cmdPos01 cmd=ptzGotoPresetPoint&name=<Nameposition>&usr=xxx&pwd=xxx
attr IPKamera cmdTiltDown cmd=ptzMoveDown&usr=xxx&pwd=xxx
attr IPKamera cmdTiltUp cmd=ptzMoveUp&usr=xxx&pwd=xxx
attr IPKamera path cgi-bin/CGIProxy.fcgi?usr=xxx&pwd=xxx&cmd=snapPicture2
attr IPKamera pathCmd cgi-bin/CGIProxy.fcgi
attr IPKamera pathPanTilt cgi-bin/CGIProxy.fcgi?usr=xxx&pwd=xxx
attr IPKamera storage ./www/images/webcam
</pre>

=== Pfad-Parameter für Mobotix ===
<pre>
attr IPKamera path /record/current.jpg
</pre>

=== Pfad-Parameter für reolink (E1 Zoom) ===
<pre>
attr IPKamera path cgi-bin/api.cgi?cmd=Snap&channel=0&rs=<irgendwas>&user=Username&password=Passwort
</pre>

Beispiel:
<pre>
attr IPKamera path cgi-bin/api.cgi?cmd=Snap&channel=0&rs=12345&user=User&password=Pwd
</pre>

Leider habe ich (noch) keine weiteren Befehle herausarbeiten können.

Es gibt eine spärliche Doku bzgl. cgi hier: https://cdn.reolink.com/wp-content/uploads/2017/01/Reolink-CGI-command-v1.61.pdf

Allerdings wird wohl für die Steuerbefehle (PTZ) ein Post-Request benötigt.

=== Einstellungen für Foscam C2 und Foscam R2 ===
Eine ausführliche Beschreibung zur Benutzung der IP Kameras Foscam C2 und Foscam R2 findet sich in {{Link2Forum|Topic=84677|LinkText=diesem Forenthread}}.

=== Parameter für Xiaomi Dafang ===
Diese Parameter gelten bei installierter alternativer Firmware von [https://github.com/EliasKotlyar/Xiaomi-Dafang-Hacks hier]
<pre>

Attributes:
attr IPKamera cmdPanLeft cmd=motor_left
attr IPKamera cmdPanRight cmd=motor_right
attr IPKamera cmdTiltDown cmd=motor_down
attr IPKamera cmdTiltUp cmd=motor_up
attr IPKamera delay 10
attr IPKamera event-on-update-reading snapshots
attr IPKamera icon it_camera
attr IPKamera path cgi-bin/currentpic.cgi
attr IPKamera pathPanTilt cgi-bin/action.cgi?
attr IPKamera snapshots 5
attr IPKamera storage /opt/fhem/www/ipcamera/dafang_1/shot
</pre>

=== Parameter für INSTAR Full HD ===
Die vollständige Schnittstelle und weitere Beispiele können direkt im [https://wiki.instar.de/Erweitert/ INSTAR-Wiki] eingesehen werden. 
Zur Integration einer INSTAR Full HD CAM können zum Beispiel folgende Attribute verwendet werden:
<pre>
attr INSTAR_8015 basicauth {USERNAME}:{PASSWORD}
attr INSTAR_8015 cmd01 cmd=setinfrared&-infraredstat=auto
attr INSTAR_8015 cmd02 cmd=setinfrared&-infraredstat=close
attr INSTAR_8015 cmd03 cmd=setinfrared&-infraredstat=open
attr INSTAR_8015 cmd04 cmd=setmdalarm&-aname=ftprec&-switch=on
attr INSTAR_8015 cmd05 cmd=setmdalarm&-aname=ftprec&-switch=off
attr INSTAR_8015 cmd06 cmd=setplanrecattr&-planrec_enable=0
attr INSTAR_8015 cmd07 cmd=setplanrecattr&-planrec_enable=1
attr INSTAR_8015 cmd08 cmd=setplanrecattr&-planrec_chn=11
attr INSTAR_8015 cmd09 cmd=setplanrecattr&-planrec_chn=12
attr INSTAR_8015 cmd10 cmd=manualrec&-act=on
attr INSTAR_8015 cmd11 cmd=manualrec&-act=off
attr INSTAR_8015 cmd12 cmd=sdfrmt
attr INSTAR_8015 cmd13 cmd=preset&-act=goto&-number=0
attr INSTAR_8015 cmd14 cmd=preset&-act=goto&-number=1
attr INSTAR_8015 cmd15 cmd=preset&-act=goto&-number=2
attr INSTAR_8015 cmdPanLeft -act=left
attr INSTAR_8015 cmdPanRight -act=right
attr INSTAR_8015 cmdPos15 -act=stop
attr INSTAR_8015 cmdTiltDown -act=down
attr INSTAR_8015 cmdTiltUp -act=up
attr INSTAR_8015 credentials /<ipcam-conf-path>/ipcam.conf
attr INSTAR_8015 eventMap /pos 15:MOVE-STOP/pan left:MOVE-LEFT/pan right:MOVE-RIGHT/tilt up:MOVE-UP/tilt down:MOVE-DOWN/cmd 1:IR-LED-auto/cmd 2:IR-LED-off/cmd 3:IR-LED-on/cmd 4:FTP-rec-on/cmd 5:FTP-rec-off/cmd 6:REC-SD-DISABLE/cmd 7:REC-SD-ENABLE/cmd 8:REC-SD-QUAL-HIGH/cmd 9:REC-SD-QUAL-MID/cmd 10:MAN-REC-Start/cmd 11:MAN-REC-Stop/cmd 12:FORMAT-SD-CARD/cmd 13:POS-WZ/cmd 14:POS-Flur/cmd 15:POS-Park/
attr INSTAR_8015 icon it_camera
attr INSTAR_8015 path tmpfs/snap.jpg
attr INSTAR_8015 pathCmd param.cgi
attr INSTAR_8015 pathPanTilt ptzctrl.cgi?-step=
attr INSTAR_8015 scheme https
attr INSTAR_8015 storage /<ipcam-snapshot-path>/snapshots
attr INSTAR_8015 webCmd POS-WZ:POS-Flur:POS-Park
</pre>

== Nicht unterstützte Netzwerkkameras ==
{{Randnotiz|RNTyp=y|RNText=Die hier aufgeführten Netzwerkkameras sind definitiv nicht unterstützt oder es gibt gravierende, hier beschriebene Einschränkungen.}}
;TRENDnet TV-IP320PI
:Aufruf der Funktion <code>get ''myCam'' image</code> führt zur Fehlermeldung ''...invalid Format''; auf Kamerabild oder Stream kann jedoch über die URL camHostnameOrIP/Streaming/channels/1/Picture (Bild) bzw. camHostnameOrIP/Streaming/channels/1/httpPreview (Stream) zugegriffen werden.

== Generierte Ereignisse ==
Das Modul ''IPCAM'' generiert die Ereignisse
* <code><nowiki>last: <name_of_device>_snapshot.<image_extension></nowiki></code>
* <code><nowiki>snapshots: <total_number_of_taken_snapshots_at_end></nowiki></code>

== Bekannte Probleme ==
Derzeit (08/2015) ist das Logging aus dem Modul zumindest lückenhaft und verbesserungsfähig. So sollten z.B. einige weitere Meldungen zur Fehlereingrenzung bei der Einrichtung eines IPCAM Objekts eingefügt werden:
* Ausgabe des kompletten Pfads / der URL, die bei der Erzeugung eines Snapshots aus einzelnen Bestandteilen zusammengesetzt wird
* Die Zuordnung von Meldungen zu ''verbose''-Leveln sollte kontrolliert und ggf. umgestellt werden
* siehe auch diesen {{Link2Forum|Topic=39932|LinkText=Forenthread}}, der Beschreibung von Problemen, eine Hikvision IPCam in Betrieb zu nehmen

Außerdem müsste das Modul dringend auf die aktuelle Form des Logging, [[verbose|verbose/Log3]], umgestellt werden.

Eine mögliche Lösung für das Problem "Wrong or not supported image format: unknown" habe ich hier beschrieben: {{Link2Forum|Topic=10772|Message=425265|LinkText=Forenbeitrag}}

== Links ==
* Forenthread zur {{Link2Forum|Topic=10772|LinkText=Erweiterung des IPCAM Moduls}}
* Forenthread zum Thema {{Link2Forum|Topic=21005|LinkText=Bewegungserkennung}}
* Forenthread zum Thema {{Link2Forum|Topic=30723|LinkText=Bewegungsmelder der Kamera "anzapfen"}}
* Webseite des Modulautors zum Thema [http://www.fischer-net.de/hausautomation/videoueberwachung.html Videoüberwachung]

IPCAM

2020-06-01T11:51:42Z

MadMax-FHEM: Pfad für reolink E1 Zoom ergänzt

{{Infobox Modul
|ModPurpose=Einbindung von Netzwerkkameras
|ModType=d
|ModForumArea=Sonstiges
|ModTechName=49_IPCAM.pm
|ModOwner=mfr69bs ({{Link2FU|6|Martin Fischer}})}}

[[IPCAM]] ermöglicht die ereignis- oder zeitgesteuerte Erzeugung von Mitschnitten bei Netzwerkkameras. Außerdem ist es möglich, die Kamera im PTZ-Modus oder über eigene Befehle zu steuern.

== Voraussetzungen ==
Die Kamera(bilder) müssen über eine URL erreichbar sein.

== Definition ==
Das IPCAM Objekt wird angelegt mit
:<code><nowiki>define <name> IPCAM <ip[:port]> </nowiki></code>

Zusätzlich zum obigen Define muss zwingend noch das ''path'' Attribut gesetzt werden.

== Attribute ==
Die wichtigsten Attribute von ''IPCAM'' werden im Folgenden aufgeführt, die komplette Liste findet sich in der {{Link2CmdRef|Anker=IPCAMattr}}.

=== Authentifizierung ===
;basicauth
:Hinterlegung von Benutzernamen und Passwort

=== Eigene Befehle ===
;cmd01, cmd02, ... cmd15
:Festlegung von Befehlen, die nicht zu den vordefinierten gehören, z.B. <code>attr ipcam cmd01 led_mode=0</code>

=== Vordefinierte Befehle ===
;cmdPanLeft, cmdPanRight, cmdTiltUp, cmdTiltDown, cmdStep
:Diesen Befehlen können die Kameraspezifischen Werte zugeordnet werden, z.B. <code>attr ipcam cmdTiltUp command=0</code>

=== Pfade ===
;path
:...

== Unterstützte Netzwerkkameras ==
{{Randnotiz|RNText=Die Aufzählungen der unterstützten und der problematischen Netzwerkkameras sollten ergänzt werden, sobald neue Erkenntnisse vorliegen; beide Listen sind nicht vollständig.}}
Bei den folgenden Netzwerkkameras ist gesichert, dass sie durch das ''IPCAM'' Modul unterstützt sind:
* {{Link2Forum|Topic=33347|Message=257115|LinkText=Foscam 9805W}}
* Foscam FI9831P
* {{Link2Forum|Topic=13826|LinkText=Instar 2905}}
* {{Link2Forum|Topic=100493|LinkText=IN-8015 Full HD}}
* {{Link2Forum|Topic=36201|LinkText=IN-6001HD}}
* {{Link2Forum|Topic=11664|LinkText=Instar 6011, 6012, 2905}}
* {{Link2Forum|Topic=58676|LinkText=Instar IN-5905HD, IN-5907HD, IN-6014HD, IN-6012HD-PoE}}
* {{Link2Forum|Topic=15217|LinkText=WansView (Modell nicht näher spezifiziert)}}
* {{Link2Forum|Topic=11664|Message=158052|LinkText=Wansview 620, 625, 6012}}
* Axis 205
* D-Link DCS-933
* Mobotix (jedenfalls S26 und Q25)
* Xiaomi Dafang (nur mit alternativer Firmware)

Nicht gesichert, ob die Kamera unterstützt wird bzw. ob alle Funktionen nutzbar sind:
* {{Link2Forum|Topic=33347|LinkText=Foscam FI9831W}}

=== Pfad-Parameter für Axis 205 ===
<pre>
attr Cam1 path /jpg/image.jpg
</pre>

=== Pfad-Parameter für D-Link DCS-933 ===
<pre>attr Cam1 path image.jpg</pre>

=== Parameter für Hikvision DS-2CD2032-I ===
Mit folgenden Parameter wurde (lt. diesem {{Link2Forum|Topic=39932|Message=322269|LinkText=Forenbeitrag}}) die Hikvision DS-2CD2032-I erfolgreich betrieben:
<pre>
define Cam1 IPCAM 192.168.xxx.xxx
attr Cam1 basicauth <username>:<passwort>
attr Cam1 delay 0
attr Cam1 group Kamera
attr Cam1 icon it_camera
attr Cam1 path Streaming/channels/1/picture?snapShotImageType=JPEG
attr Cam1 snapshots 1
attr Cam1 storage /opt/fhem/www/snapshots/cam1
</pre>

=== Pfad-Parameter für Foscam FI9831P ===
Die Version ist ohne basicauth und hat Nutzer und Passwort direkt in der URL. Kann natürlich geändert werden.
Sämtliche Befehle für die Foscam HD Kameras findet man [https://www.manualslib.com/manual/728928/Foscam-Ip-Camera.html hier]
<pre>
define IPKamera IPCAM <ip>:<port>
attr IPKamera cmd01 cmd=ptzStopRun&usr=xxx&pwd=xxx
attr IPKamera cmdPanLeft cmd=ptzMoveLeft&usr=xxx&pwd=xxx
attr IPKamera cmdPanRight cmd=ptzMoveRight&usr=xxx&pwd=xxx
attr IPKamera cmdPos01 cmd=ptzGotoPresetPoint&name=<Nameposition>&usr=xxx&pwd=xxx
attr IPKamera cmdTiltDown cmd=ptzMoveDown&usr=xxx&pwd=xxx
attr IPKamera cmdTiltUp cmd=ptzMoveUp&usr=xxx&pwd=xxx
attr IPKamera path cgi-bin/CGIProxy.fcgi?usr=xxx&pwd=xxx&cmd=snapPicture2
attr IPKamera pathCmd cgi-bin/CGIProxy.fcgi
attr IPKamera pathPanTilt cgi-bin/CGIProxy.fcgi?usr=xxx&pwd=xxx
attr IPKamera storage ./www/images/webcam
</pre>

=== Pfad-Parameter für Mobotix ===
<pre>
attr IPKamera path /record/current.jpg
</pre>

=== Pfad-Parameter für reolink (E1 Zoom) ===
<pre>
attr IPKamera path cgi-bin/api.cgi?cmd=Snap&channel=0&rs=<irgendwas>&user=Username&password=Passwort
</pre>

Beispiel:
<pre>
attr IPKamera path cgi-bin/api.cgi?cmd=Snap&channel=0&rs=12345&user=User&password=Pwd
</pre>

=== Einstellungen für Foscam C2 und Foscam R2 ===
Eine ausführliche Beschreibung zur Benutzung der IP Kameras Foscam C2 und Foscam R2 findet sich in {{Link2Forum|Topic=84677|LinkText=diesem Forenthread}}.

=== Parameter für Xiaomi Dafang ===
Diese Parameter gelten bei installierter alternativer Firmware von [https://github.com/EliasKotlyar/Xiaomi-Dafang-Hacks hier]
<pre>

Attributes:
attr IPKamera cmdPanLeft cmd=motor_left
attr IPKamera cmdPanRight cmd=motor_right
attr IPKamera cmdTiltDown cmd=motor_down
attr IPKamera cmdTiltUp cmd=motor_up
attr IPKamera delay 10
attr IPKamera event-on-update-reading snapshots
attr IPKamera icon it_camera
attr IPKamera path cgi-bin/currentpic.cgi
attr IPKamera pathPanTilt cgi-bin/action.cgi?
attr IPKamera snapshots 5
attr IPKamera storage /opt/fhem/www/ipcamera/dafang_1/shot
</pre>

=== Parameter für INSTAR Full HD ===
Die vollständige Schnittstelle und weitere Beispiele können direkt im [https://wiki.instar.de/Erweitert/ INSTAR-Wiki] eingesehen werden. 
Zur Integration einer INSTAR Full HD CAM können zum Beispiel folgende Attribute verwendet werden:
<pre>
attr INSTAR_8015 basicauth {USERNAME}:{PASSWORD}
attr INSTAR_8015 cmd01 cmd=setinfrared&-infraredstat=auto
attr INSTAR_8015 cmd02 cmd=setinfrared&-infraredstat=close
attr INSTAR_8015 cmd03 cmd=setinfrared&-infraredstat=open
attr INSTAR_8015 cmd04 cmd=setmdalarm&-aname=ftprec&-switch=on
attr INSTAR_8015 cmd05 cmd=setmdalarm&-aname=ftprec&-switch=off
attr INSTAR_8015 cmd06 cmd=setplanrecattr&-planrec_enable=0
attr INSTAR_8015 cmd07 cmd=setplanrecattr&-planrec_enable=1
attr INSTAR_8015 cmd08 cmd=setplanrecattr&-planrec_chn=11
attr INSTAR_8015 cmd09 cmd=setplanrecattr&-planrec_chn=12
attr INSTAR_8015 cmd10 cmd=manualrec&-act=on
attr INSTAR_8015 cmd11 cmd=manualrec&-act=off
attr INSTAR_8015 cmd12 cmd=sdfrmt
attr INSTAR_8015 cmd13 cmd=preset&-act=goto&-number=0
attr INSTAR_8015 cmd14 cmd=preset&-act=goto&-number=1
attr INSTAR_8015 cmd15 cmd=preset&-act=goto&-number=2
attr INSTAR_8015 cmdPanLeft -act=left
attr INSTAR_8015 cmdPanRight -act=right
attr INSTAR_8015 cmdPos15 -act=stop
attr INSTAR_8015 cmdTiltDown -act=down
attr INSTAR_8015 cmdTiltUp -act=up
attr INSTAR_8015 credentials /<ipcam-conf-path>/ipcam.conf
attr INSTAR_8015 eventMap /pos 15:MOVE-STOP/pan left:MOVE-LEFT/pan right:MOVE-RIGHT/tilt up:MOVE-UP/tilt down:MOVE-DOWN/cmd 1:IR-LED-auto/cmd 2:IR-LED-off/cmd 3:IR-LED-on/cmd 4:FTP-rec-on/cmd 5:FTP-rec-off/cmd 6:REC-SD-DISABLE/cmd 7:REC-SD-ENABLE/cmd 8:REC-SD-QUAL-HIGH/cmd 9:REC-SD-QUAL-MID/cmd 10:MAN-REC-Start/cmd 11:MAN-REC-Stop/cmd 12:FORMAT-SD-CARD/cmd 13:POS-WZ/cmd 14:POS-Flur/cmd 15:POS-Park/
attr INSTAR_8015 icon it_camera
attr INSTAR_8015 path tmpfs/snap.jpg
attr INSTAR_8015 pathCmd param.cgi
attr INSTAR_8015 pathPanTilt ptzctrl.cgi?-step=
attr INSTAR_8015 scheme https
attr INSTAR_8015 storage /<ipcam-snapshot-path>/snapshots
attr INSTAR_8015 webCmd POS-WZ:POS-Flur:POS-Park
</pre>

== Nicht unterstützte Netzwerkkameras ==
{{Randnotiz|RNTyp=y|RNText=Die hier aufgeführten Netzwerkkameras sind definitiv nicht unterstützt oder es gibt gravierende, hier beschriebene Einschränkungen.}}
;TRENDnet TV-IP320PI
:Aufruf der Funktion <code>get ''myCam'' image</code> führt zur Fehlermeldung ''...invalid Format''; auf Kamerabild oder Stream kann jedoch über die URL camHostnameOrIP/Streaming/channels/1/Picture (Bild) bzw. camHostnameOrIP/Streaming/channels/1/httpPreview (Stream) zugegriffen werden.

== Generierte Ereignisse ==
Das Modul ''IPCAM'' generiert die Ereignisse
* <code><nowiki>last: <name_of_device>_snapshot.<image_extension></nowiki></code>
* <code><nowiki>snapshots: <total_number_of_taken_snapshots_at_end></nowiki></code>

== Bekannte Probleme ==
Derzeit (08/2015) ist das Logging aus dem Modul zumindest lückenhaft und verbesserungsfähig. So sollten z.B. einige weitere Meldungen zur Fehlereingrenzung bei der Einrichtung eines IPCAM Objekts eingefügt werden:
* Ausgabe des kompletten Pfads / der URL, die bei der Erzeugung eines Snapshots aus einzelnen Bestandteilen zusammengesetzt wird
* Die Zuordnung von Meldungen zu ''verbose''-Leveln sollte kontrolliert und ggf. umgestellt werden
* siehe auch diesen {{Link2Forum|Topic=39932|LinkText=Forenthread}}, der Beschreibung von Problemen, eine Hikvision IPCam in Betrieb zu nehmen

Außerdem müsste das Modul dringend auf die aktuelle Form des Logging, [[verbose|verbose/Log3]], umgestellt werden.

Eine mögliche Lösung für das Problem "Wrong or not supported image format: unknown" habe ich hier beschrieben: {{Link2Forum|Topic=10772|Message=425265|LinkText=Forenbeitrag}}

== Links ==
* Forenthread zur {{Link2Forum|Topic=10772|LinkText=Erweiterung des IPCAM Moduls}}
* Forenthread zum Thema {{Link2Forum|Topic=21005|LinkText=Bewegungserkennung}}
* Forenthread zum Thema {{Link2Forum|Topic=30723|LinkText=Bewegungsmelder der Kamera "anzapfen"}}
* Webseite des Modulautors zum Thema [http://www.fischer-net.de/hausautomation/videoueberwachung.html Videoüberwachung]

FHEM Connector für Amazon Alexa

2020-03-28T08:36:42Z

MadMax-FHEM: Bild bzgl. alexaName eingefügt

{{Baustelle}}
'''Alexa FHEMlazy''' war historisch ein Fork des Original [[Alexa-Fhem|alexa-fhem]], der im Januar 2019 mit dem Original zusammengeführt wurde und nun als '''FHEM Connector''' verfügbar ist.

Er ermöglicht innerhalb von Minuten die Verknüpfung von FHEM mit einem Amazon Echo Gerät. Auch Geräte anderer Hersteller mit verbauten Mikrofonen und Alexa-Sprachassistenten-Unterstützung sollten problemlos funktionieren. Für folgende Geräte ist dies bspw. der Fall (Falls Ihr andere/weitere Gerätemodelle bzw. Hersteller in Verwendung habt, bitte hier pflegen):

* SONOS Beam und SONOS One

Gegenüber dem klassischen Ansatz ergeben sich Einschränkungen, so läuft die Software normalerweise unter dem gleichen Benutzer wie FHEM auf dem gleichen Server, und es wird z.Zt. nur der Smarthome-Skill unterstützt (die Variante, bei der die Möglichkeiten der Interaktion von Amazon festgelegt wurden).
Dafür ist weder ein Developer-Account bei Amazon, eigene Lambda- und Skillfunktionen, noch das Öffnen eines eingehenden Ports aus dem Internet nötig.
* Die Software integriert einen Installer, der die Erstkonfiguration und Anmeldung übernimmt
* Die Kommunikation zur Software auf dem heimischen Rechner und dann zu FHEM verläuft über SSH und einen vom FHEM-Verein gehosteten Server
* Funktioniert mit IPv4, IPv6, echtem Dual Stack und DS-Lite
* Als Skill bei Amazon wird der Skill "FHEM Connector" verwendet.

Der Thread im Forum zur Software ist hier: {{Link2Forum|Topic=94817}}.

{{Infobox Modul
|ModPurpose=Einfache Anbindung von FHEM an Amazon Assistent Alexa
|ModType=h
|ModCmdRef=alexa
|ModTechName=39_alexa.pm / alexa-fhem
|ModForumArea=Frontends/Sprachsteuerung
|ModOwner=gvzdus, André/ justme1968 ({{Link2FU|430|Forum}} / [[Benutzer Diskussion:Justme|Wiki]])
}}

==Einführung==

===Arbeitsweise und Datenfluss===
Vorläufig ist alexa-fhem im "FHEM Connector-Modus" ein reiner [https://developer.amazon.com/de/docs/smarthome/understand-the-smart-home-skill-api.html SmartHome-Skill].
SmartHome-Skills erhalten weder die Sprachdaten selber noch das, was Amazon in Textform verstanden hat, sondern vielmehr extrahiert Amazon aus dem verstandenen Text Anweisungen und Abfragen für Geräte, die dann an den Skill übermittelt werden. Charmant ist dabei, dass unmittelbar gefragt werden kann "Alexa, wie ist die Temperatur im Wohnzimmer?", während andere Skills zunächst explizit angesprochen werden müssen ("Alexa, frage FHEM nach der Temperatur im Wohnzimmer"). Außerdem kann der Nutzer mehrere Smarthome-Skills installieren, und die Geräte werden zu einer Gesamtmenge zusammengefasst.

Gehen wir den Datenfluss bei der konkreten Frage "Wie ist die Temperatur im Wohnzimmer?" durch:
* Alexa hat bei der Skillinstallation gelernt, dass "FHEM Connector" bei Dir einen Thermostaten im Raum Wohnzimmer kennt. Dadurch wird bei der Sprachanalyse von "Alexa Voice Service" in der Cloud erkannt, dass eine Abfrage an "FHEM Connector" erfolgversprechend ist.
* Zunächst wird die zentrale "Lambda-Funktion" von "FHEM Connector" aufgerufen. Die Funktion leitet aber im Kern nur den Request unverändert an den vom Verein bereitgestellten Server weiter. Im Request enthalten ist ein Token, das sogenannte "Bearer-Token".
* Der "Vereinsserver" prüft anhand dieses Tokens, ob es überhaupt bekannt ist, und zu welchem Nutzer es gehört. Ist dieser Nutzer verbunden, wird der Request wiederum quasi unverändert an den Nutzer weitergeleitet.
* Diese Weiterleitung passiert über einen sogenannten SSH-Reverse-Tunnel, der von Deiner Seite und der Software auf dem FHEM-Tunnel automatisch aufgebaut wird.
* Auf Deiner Seite läuft die eigentliche Software, und zwar unter nodeJS. nodeJS ist ein Javascript ausführender Miniserver, der lokal auf einem Zufallsport auf Requests "lauscht". In der Original-Version [[Alexa-Fhem|Alexa FHEM]] kommen die Requests aus dem Internet (hoffentlich von der eigenen Lambda-Funktion), hier bei "FHEM Connector" kommen sie ausschließlich aus dem SSH-Tunnel von lokal.
* Die Software validiert nun diesen Request anhand des Bearer-Tokens. Konkret wird dabei das bei der Installation generierte Token, dass bei der Skill-Aktivierung an Amazon übertragen wurde, mit dem lokal gespeicherten Wert verglichen. Stimmt das Token, wird der Befehl verarbeitet, üblicherweise wird hierbei ein Aufruf an die Webschnittstelle von FHEM abgesetzt.
* FHEM führt den Befehl aus

Hört sich langsam und kompliziert an? Kompliziert: Okay. Langsam eher nicht, in etlichen Fällen liegt die Gesamtantwortszeit unter 200 ms.

Soweit ein erster Überblick über die Datenflüsse. Im Abschnitt Sicherheit ist das Konzept der Absicherung deutlich genauer und ausführlicher beschrieben.

==Installation==

Du wirst bei der Installation zuerst auf der Kommandozeile auf Deinem Raspberry (o.ä.) unterwegs sein, anschließend im Webfrontend von FHEM, und zum Schluss auf der Alexa-Konsole im Web.

===node.js installieren===

Ab Jessy liegt NodeJS bereits in einer ausreichend aktuellen Version vor (Stretch und Buster funktionieren ebenfalls). Mit

<syntaxhighlight lang="bash" style="width:50%;">
sudo apt-get install nodejs npm
</syntaxhighlight>

kannst Du es installieren. Mit
<syntaxhighlight lang="bash" style="width:50%;">
node --version
</syntaxhighlight>

erfährst Du die aktuelle Version - wenn hier etwas mit "8" oder höher vorneweg erscheint, ist alles gut.
Ansonsten suche Dir bitte eine Anleitung im Web, wie Du NodeJS auf Deinem System auf einen aktuellen Stand bringen kannst.

=== Alexa-FHEM installieren ===

Nun installieren wir Alexa-fhem aus dem offiziellen Repository:

<syntaxhighlight lang="bash" style="width:50%;">
sudo npm install -g alexa-fhem
</syntaxhighlight>

Der Vorgang benötigt etwas Zeit.

=== Alexa-FHEM aktivieren ===

Wechsele jetzt in FHEM-Web!

Wichtig ist, dass das Alexa-Modul in der Version ab Januar 2019 vorliegt. Dafür bitte einmal FHEM aktualisieren:
Speichern der Config nicht vergessen, und

<syntaxhighlight lang="bash" style="width:50%;">
update
shutdown restart
</syntaxhighlight>

Alles, was jetzt noch nötig ist, ist das Anlegen eines Alexa-Devices. Gib dafür in der FHEM-Web-Kommandozeile

<syntaxhighlight lang="bash" style="width:50%;">
define alexa alexa
</syntaxhighlight>

an. Nun läuft, während Du bereits das neu angelegte Alexa-Devices siehst, ein komplexer Prozess im Hintergrund:

* Falls noch kein SSH-Key für den Benutzer, unter dem FHEM läuft, existiert, wird einer generiert
* Es wird ein Secret-Key im Prozess generiert, dass den Server nicht verlässt, und der Skillanmeldung dient.
* Du wirst auf dem Server "va-fhem.fhem.de" des FHEM-Vereins mit dem SSH-Key angemeldet, und der Hash-Wert Deines Secret-Key dort abgelegt.

Und wenn Du diese Sätze gelesen hast, sollte inzwischen sich das Alexa-Device in FHEM-Web aktualisiert haben, und
ungefähr so aussehen:

[[Datei:Alexa-Device-2.png|800px]]

Neben dem Status für alexa-fhem und der Proxyverbindung ist wichtig, dass diese beiden Zeilen beim Reload aufgetaucht sind:

<syntaxhighlight lang="bash" style="width:90%;">
alexaFHEM.bearerToken crypt:...
alexaFHEM.skillRegKey crypt:...
</syntaxhighlight>

Ja, und diesen Schlüssel benötigst Du wirklich! Also am besten schon einmal mit

<syntaxhighlight lang="bash" style="width:90%;">
get <alexa> proxyKey
</syntaxhighlight>

in Klartext anzeigen lassen und in ein Editor-Fenster dauerhaft wegsichern.

Jetzt solltest Du Dein Alexa-Device nicht mehr löschen, denn das im Reading angezeigte "bearerToken" zu löschen bedeutet, dass die Software die Zugriffe von nicht mehr überprüfen kann und keine Kommandos mehr funktionieren. In diesem Fall hilft nur die Neuinstallation des Skills.

==== Fehler bei der Aktivierung ====

Während kompliziertere Fehlerfälle im Abschnitt "Mögliche Probleme und Lösungen" behandelt werden, hier häufige Fälle, warum die kryptischen Zeilen nicht auftauchen:

* Zuerst bitte einfach einmal die Seite neu laden.

===== 401: Authorization Required =====

Wenn Du FHEM-Web mit einem User/Passwort-Schutz versehen hast, wirst du folgende Fehlermeldung sehen:

<syntaxhighlight lang="bash" style="width:90%;">
alexaFHEM stopped; failed to connect to fhem: 401: Authorization Required
</syntaxhighlight>

In der Regel musst du die Angaben User/Passwort noch einmal explizit setzen. Im Attribute-Abschnitt "alexaFHEM-auth" auswählen, User/Passwort mit ":" getrennt angeben und "attr" anklicken. alexa-fhem wird automatisch neu gestartet. Hier das Ganze in der Text-Variante:

<syntaxhighlight lang="bash" style="width:90%;">
attr alexa alexaFHEM-auth user:pass
</syntaxhighlight>

===== Permission denied =====

Wenn du folgende Fehlermeldungen im Alexa Logfile siehst, wurde das Verzeichnis "/opt/fhem/.ssh/" von dir bei der Arbeit mit "root" oder "sudo" mit den falschen Berechtigungen versehen:

<syntaxhighlight lang="bash" style="width:90%;">
[2019-7-25 11:59:12] sshautoconf: aborted with ssh-keygen returned error - key_save_private: Permission denied
[2019-7-25 11:59:12] *** SSH: proxy configuration failed: ssh-keygen returned error - key_save_private: Permission denied
</syntaxhighlight>

Prüfen kannst du die Berechtigungen mit folgendem Befehl auf der Shell-Konsole:

<syntaxhighlight lang="bash" style="width:90%;">
ls -l /opt/fhem/.ssh
</syntaxhighlight>

Du solltest dann folgende Ausgabe erhalten:

<syntaxhighlight lang="bash" style="width:90%;">
insgesamt 12
-rw------- 1 fhem dialout 1675 Jul 12 13:10 id_rsa
-rw-r--r-- 1 fhem dialout 391 Jul 12 13:10 id_rsa.pub
-rw-r--r-- 1 fhem dialout 884 Jul 12 13:10 known_hosts
</syntaxhighlight>

Steht in der Ausgabe nicht "fhem dialout" (dein fhem User), sondern bspw. "root root", dann bspw. mit folgendem Befehl an deinen fhem User anpassen:

<syntaxhighlight lang="bash" style="width:90%;">
chown fhem:dialout /opt/fhem/.ssh
</syntaxhighlight>

Mit dem ersten Befehl "ls -l ..." kannst du dann nochmal prüfen, ob die Berechtigungen korrekt übernommen wurden.

===== weitere Prüfungen =====

Hast Du noch die Shell-Konsole offen? Dann prüfe bitte noch einmal auf der Konsole, ob nun zwei Prozesse laufen:

<syntaxhighlight lang="bash" style="width:50%;">
ps -ef | egrep '(alexa|ssh)'
</syntaxhighlight>

sollte Dir idealerweise so etwas anzeigen:
<syntaxhighlight lang="bash" style="width:90%;">
fhem 31322 1 99 13:56 ? 00:00:03 alexa
fhem 31332 31322 8 13:56 ? 00:00:00 /usr/bin/ssh -R 1234:127.0.0.1:<zufälliger port> -oServerAliveInterval=90 -p 58824 fhem-va.fhem.de
</syntaxhighlight>

"alexa" ist dabei der Node-JS-Prozess, der ssh-Prozess ist die aufgebaute Verbindung zum Vereinsserver.

Wenn Du diese Prozesse '''nicht''' siehst oder das Alexa-Device keinen Registrierungskey anzeigt, dann ist leider der Start nicht glatt verlaufen.

Im Logfile (über den link <code>Logfile</code> in der Detail-Ansicht über <code>set</code>, oder über den Namen bei ''currentlogfile'' in den Internals) findest Du idealerweise selber Hinweise, wo es hakt, oder kannst im Forum nachfragen.

=== Geräte im FHEM-Webfrontend zuweisen ===
Um das Aha-Erlebnis zu vergrößern, ist jetzt ein guter Zeitpunkt, 1 oder besser mind. 2 Geräte für den Alexa-Dienst zuzuweisen. Von Haus aus wird keines Deiner FHEM-Geräte automatisch Alexa zugewiesen!

Wähle die Geräte aus, rufe sie auf und setze das Attribut "alexaName". Hierbei in Kürze nur der Hinweis:
* Keine Angst vor Leerzeichen und Umlauten, funktioniert.
* Große Angst vor Rechtschreibfehlern (Terrasse, Rollladen) oder komplizierten Wörtern "handgebastelte Martinslaterne im Kinderzimmer Iphigenie-Chantal".
* Das Attribut "alexaRoom" ist NUR FÜR DEN CUSTOM SKILL relevant. Ausnahme: structure und LightScene Devices, siehe: [[FHEM_Connector_f%C3%BCr_Amazon_Alexa#Was_geht_alles_.3F]].

Lade die Geräte neu in die Software, indem Du <code>set <alexa> restart</code> ausführst!
[[Datei:HowToSet alexaName.png|alternativtext=How to set alexaName|ohne|mini|Wie setzt man das Attribut alexaName]]

'''Anmerkungen (weil oft gestellte Fragen im Forum) bzgl. Erkennung von Geräten:'''

* Wichtig ist, dass die Filtereinstellung in der alexa-fhem.cfg (zu finden unter "Edit Files") passt.
Das, was dort eingetragen ist (Standard: alexaName=..* / also es ist ein alexaName vergeben) auch an den entsprechenden Devices in fhem vorhanden ist.
Stimmt das nicht überein, kann alexa-fhem keine Devices von fhem abfragen/finden.
Ob der Filter entsprechend funktioniert kann man wie folgt testen: ''list Filtereinstellung'' beispiel mit Standardfilter: ''list alexaName=..*''

* Hat alexa-fhem per Filter Devices aus fhem "gefunden", geht es weiter mit der "Erkennung". Also um welches Device (Typ und "Fähigkeiten") handelt es sich. Dazu gilt folgendes:
** sind entsprechende Readings beim Device vorhanden (z.B. temperature, state mit on/off, ...) erkennt das alexa-fhem automatisch. Die Liste der automatisch erkannten Readings wächst ständig. Daher erst mal schauen ob das Device bereits entsprechend erkannt (typisiert) wurde. Das kann durch prüfen des alexa-fhem-Logs geschehen (NICHT fhem-log!).
** sind entsprechende "set-Befehle" erkennbar (oft auch durch Readings). Also ist beispielsweise (wie beim Dummy nötig) ein ''setList'' mit entsprechenden Einträgen vorhanden oder entsprechende Readings, z.B. desired-temp zum Stellen der Temperatur etc.
** wird das Device nicht richtig oder "unvollständig" erkannt helfen folgende Attribute:
*** genericDeviceType: hiermit kann alexa-fhem in die gewünschte Richtung "geschubbst" werden. Anmerkung: man kann nicht alles erzwingen, Readings bzw. set-Befehle müssen passen (oder per homebridgeMapping passend gemacht werden). Wenn ein genericDeviceType nicht per "Drop-Down" erscheint, dann kann er auch (wenn bekannt) einfach per WEB-cmd eingegeben werden: ''attr Devicename genericDeviceType media''
*** homebridgeMapping: hierdurch kann alexa-fhem bei der Erkennung von Zuständen und möglichen Einstellungen (also WAS kann das Device) unterstützt werden. Mittels homebridgeMapping können vorhandene Readings (Zustände) auf für alexa-fhem bekannte Zustände gemappt werden. Ebenso können damit Standard-fhem-Kommandos von alexa-fhem auf Device-spezifische gemappt werden. Beispiel: on/off auf Ein/Aus (falls das Device statt on/off eben ein Ein/Aus erwartet). Zum Beispiel: <syntaxhighlight lang="bash" style="width:50%;">
attr <thermostat> homebridgeMapping TargetTemperature=target::target,minValue=18,maxValue=25,minStep=0.5 CurrentTemperature=myTemp:temperature
</syntaxhighlight> [https://github.com/justme-1968/homebridge-fhem/blob/master/README.md weitere Beispiele]

'''Anmerkung bzgl. genericDeviceType und homebridgeMapping:''' 
* diese Attribute werden von verschiedenen "Sprachsteuerungsmodulen" in fhem verwendet (homebridge [dort wurde es "erfunden"], alexa-fhem, gassistant, ...). Daher ist nicht jedes Mapping für alle "Dienste" verwendbar. Ausprobieren schadet aber nicht.
* ebenso kann man mit diesen Attributen (homebridgeMapping wird gerne so "missbraucht") nichts erzwingen, was seitens Amazon/Alexa nicht unterstützt bzw. verstanden wird! D.h. zunächst ist zu prüfen, ob ein bestimmter (gewünschter) Sprachbefehl seitens Amazon/Alexa unterstützt wird! Aktuelles Beispiel (Stand Jan 2020): "Alexa, fahre den Rollo hoch/runter". Da ist Amazon/Alexa gerade dabei etwas zu tun. Bislang wird das nicht unterstützt, also ist das auch mit einem entsprechenden homebridgeMapping nicht zu erzwingen! Was unterstützt wird kann man bei Amazon nachlesen: [https://developer.amazon.com/es-ES/docs/alexa/device-apis/list-of-interfaces.html]

== Finale: Skill verknüpfen ==
Suche im WebFrontend oder der Alexa-App den Skill "FHEM Connector". Für nicht-Mac/iOS Anwerder empfiehlt das WebFrontend (https://alexa.amazon.de) statt die App, damit Du den Anmeldeschlüssel auch bequem kopieren kannst.

Wenn du noch nicht bei Amazon angemeldet bist, erwartet Amazon zunächst, dass Du Dich normal bei Amazon anmeldest.

Sobald Du "FHEM Connector" aktivierst, öffnet sich ein Browser-Tab mit folgender Maske: 
[[Datei:FHEMlazy_login.png|240px]]

Hier kopierst Du Deinen Anmeldeschlüssel (im Klartext!) hinein und klickst auf Check. Als glücklicher Mensch ist auf der folgenden Statusseite alles grün: 
[[Datei:FHEMlazy_check.png|240px]]

Im Einzelnen wird hier geprüft, ob Du per SSH verbunden bist (und auch Deine IP zur Sicherheit angezeigt), ob der Reverse-Tunnel steht, ob nodeJS erreichbar ist und wie viele Geräte Alexa gleich finden sollte (in meinem Fall 22).

Sollte etwas nicht grün sein und Du eine Idee zum Fixen haben, kannst Du mit "Retry" neue Versuche auslösen.

Ist alles okay, klicke rechts den Button "Activate Skill". Du springst damit wieder zurück zu Amazon, die Dir hoffentlich zur erfolgreichen Verknüpfung gratulieren.

Amazon möchte nun unmittelbar die Gerätesuche starten, und unter SmartHome-Geräte sollten diese nun auftauchen.

== Was geht alles ? ==

* Geräte, die sich ein- und ausschalten lassen:
** Automatisch: Müssen <code>set on</code> und <code>set off</code> Kommandos haben
** dummys müssen <code>setList</code> mit on und off haben
** Über <code>genericDeviceType</code> switch bzw. light kann bestimmt werden ob es in alexa als Schalter oder Licht behandelt wird.
** Wenn die Set-Kommandos im FHEM Device anders benannt sind: hombridgeMapping On:cmdOn=<ein>,cmdOff=<aus> setzen
** Kommandos:
***Alexa, schalte <name> ein/aus
***Alexa, Licht an/aus
***Alexa, schalte <gruppe> ein/aus
* Geräte, die eine Temperatur messen
** Automatisch: Es muss ein Reading <code>temperature</code> geben
** Über <code>genericDeviceType</code> thermometer
** Sonst: hombridgeMapping CurrentTemperature:reading=<reading>

* Geräte, deren Helligkeit sich ändern lässt
** Automatisch: wenn <code>dim</code> oder <code>pct</code> Kommandos erkannt werden
** Über <code>genericDeviceType</code> light
** Über homebridgeMapping: Wenn <code>helligkeit</code> das Reading für die aktuelle Helligkeit enthält und die Helligkeit mit <code>set <device> prozent xxx</code> gesetzt wird, sieht das homebridgeMapping wie folgt aus: homebridgeMapping Brightness=helligkeit::prozent,minValue=0,maxValue=<maximalwert>
** Kommandos:
*** Alexa, mache <name> heller/dunkler
*** Alexa, Licht heller/dunkler
* Geräte, deren Farbe sich ändern lässt
** ...

* Geräte, deren Farbtemperatur sich ändern lässt
** ...

* Geräte, bei denen sich eine Lautstärke einstellen lässt
** ...

* Geräte, bei denen sich ein prozentualer Wert einstellen lässt
** Automatisch: wenn <code>dim</code> oder <code>pct</code> Kommandos erkannt werden
** ...

* elektrische Türschlösser
** <code>genericDeviceType</code>: lock
** hombridgeMapping mit LockCurrentState und LockTargetState

* Thermostate
** Über <code>genericDeviceType</code> thermostate
** ...

* structure Devices aus FHEM (ab alexa-fhem version 0.5.7)
** können mit <code>genericDeviceType</code> scene als Szene eingebunden werden
** über <code>alexaRoom</code> kann der name um einen Ort ergänzt werden
** Szenen aus einer structure lassen sich ein- und ausschalten
** Wichtig:
*** Ein Skill darf nur 12 Szenen automatisch erkennen und einbinden.

* LightScene Devices aus FHEM (ab alexa-fhem version 0.5.8)
** können mit <code>genericDeviceType</code> scene als Szenen eingebunden werden
** über <code>alexaRoom</code> kann der name um einen Ort ergänzt werden
** Szenen aus einer LightScene lassen sich nur einschalten
** Wichtig:
*** Ein Skill darf nur 12 Szenen automatisch erkennen und einbinden.

* Geräte, deren Kanal sich umschalten lässt (ab alexa-fhem version 0.5.13)
** Über <code>genericDeviceType</code> media
** hombridgeMapping ChannelController:reading=<reading>,cmd=<cmd>
** Erlaubte Werte siehe hier: https://developer.amazon.com/de/docs/device-apis/alexa-channelcontroller.html#changechannel
** ...

* Geräte, deren Playback status sich schalten lässt (ab alexa-fhem version 0.5.13)
** Über <code>genericDeviceType</code> media
** hombridgeMapping PlaybackController:playback,values=Play;Pause;Stop;Previous;Next
** Erlaubte Werte siehe hier: https://developer.amazon.com/de/docs/device-apis/alexa-playbackcontroller.html#discovery
** ...

* Geräte, deren Eingang sich umschalten lässt (ab alexa-fhem version 0.5.13)
** Über <code>genericDeviceType</code> media
** hombridgeMapping InputController:reading=<reading>,cmd=<cmd>,values=HDMI+1;HDMI+2;XBOX
** Erlaubte Werte siehe hier: https://developer.amazon.com/de/docs/device-apis/alexa-property-schemas.html#input
** ...

* Kontaktsensoren (ab alexa-fhem version 0.5.15)
** Über <code>genericDeviceType</code> contact
** hombridgeMapping ContactSensorState:reading=<reading> oder CurrentDoorState:reading=<reading>
** Die Anzeige in der Alexa-App funktioniert sofort, die Abfrage per Sprache erst ab Version 0.5.27.

* Geräte, deren Lautstärke sich ändern lässt (ab alexa-fhem version 0.5.24)
** Über <code>genericDeviceType</code> speaker
** Automatisch: es muss ein Reading <code>volume</code> und/oder <code>mute</code> geben
** hombridgeMapping Volume:reading=<reading>,cmd=<cmd> Mute:reading=<reading>,cmd=<cmd>
** ...

* Geräte, die sich ein- (und optional) ausschalten lassen als Szene (ab alexa-fhem version 0.5.26)
** Über <code>genericDeviceType</code> scene
** Automatisch: Müssen <code>set on</code> und <code>set off</code> Kommandos haben
** hombridgeMapping On:reading=<reading>,cmdOn=<cmd>[,cmdOff=<cmd>]
** Hinweis: Fehlende Kommandos lassen sich mit cmdalias erzeugen
** Wichtig:
*** Ein Skill darf nur 12 Szenen automatisch erkennen und einbinden.
* Rollläden. Lange ein Problemthema, das nur mit "Schalte auf 0%, schalte auf 100% lief". Wichtig: "alexa-fhem" ab Version 0.5.39 einsetzen. GenericDevice-Type auf "blind" setzen. Nach Restart von alexa-fhem und neuer Gerätesuche sollte folgendes funktionieren:
** "..., öffne <Name> ganz"
** "..., schließe <Name> komplett"
** "hoch" und "runter" (ohne "ganz" oder "komplett") schalten jeweils nur einen bestimmten Prozentsatz hoch oder runter. Dieser kann mit <code>attr <name> homebridgeMapping TargetPosition:minStep=<wert></code>geändert werden. Aber Achtung: In diesem Intervall kann dann auch nur noch ein absoluter Prozentwert per Sprache oder Slider eingestellt werden! Bei z.B. 25% würden 13% zu 25% aufgerundet, 12% zu 0% abgerundet werden.
* Kontaktsensoren (ab alexa-fhem version 0.5.47)
** Automatisch wenn ein Reading <code>motion</code> vorhanden ist oder es sich um einen Zigbee bewgungsmelder an einer HUE oder deCONZ Bridge handelt
** Über <code>genericDeviceType</code> MotionSensor
** hombridgeMapping MotionDetected:reading=<reading>,values=<wert für bewgung>:1;<wert für keine bewegung>:0

Es werden noch einige andere häufig verwendete Geräte (Homematic, hue,...) automatisch erkannt.

to be continued ...

In der [https://developer.amazon.com/docs/device-apis/list-of-interfaces.html List of Capability Interfaces] bei Amazon kann man sehen, welche Möglichkeiten das Smart Home Skill API aktuell in einzelnen Ländern bietet. Leider ohne die jeweiligen landessprachlichen Kommandos.

=== Aktiv Routinen starten ===
Routinen (eine Funktionalität, die rein - genauso wie "Räume" - bei Amazon liegt und nicht von FHEM Connector beeinflusst wird) waren lange die ewige Antwort auf die Frage: "Meine Frau möchte aber '''Öffne Rollläden''<nowiki/>' sagen": In der Alexa-App gibt es im Menü den Punkt "Routinen", und hier lässt sich eine gewisse Anzahl von Aktionen (unter optionalen Bedingungen) an ein Sprachkommando knüpfen.

Neu: Routinen können inzwischen auch von Skills getriggert werden, und seit Version 0.5.47 (Februar 2020) auch von FHEM Connector. Das braucht niemand, um die Rollläden hochzufahren, denn das kann FHEM ja selber, aber um z.B. eine Ansage auf einem Alexa-Gerät zu triggern. Dafür gibt es auch das FHEM-Modul "echodevice", aber es erfordert ein paar Klimmzüge. Mit dem aktiven Triggern von Routinen kann FHEM auslösen, dass Alexa ungefragt (!) Dinge wie

''"Die Temperatur in der Tiefkühltruhe hat -16 Grad überschritten"''

in den Raum sagt. Also eine Alternative bzw. Ergänzung zu Alarmen / Erinnerungen per Telegram o.ä.

'''Vorgeschichte''':

Die Smarthome-Skill-API von Amazon sah schon lange das "proactiveReporting" vor: Also z.B. die gemessene Temperatur nicht erst auf Anfrage hin zu übermitteln, sondern laufend aktiv zu pushen. Aber warum Daten an Amazon senden, wenn es dafür keinen Mehrwert gibt? Beim Öffnen z.B. des Thermostaten in der Alexa-App kommen ohnehin laufend Statusabfragen. Warum also einen Datenpool bei Amazon über die Haustemperatur aufbauen und Änderungen pushen, wenn es keinen Mehrwert dafür gibt?

Inzwischen lassen sich (reale oder vermeintliche) Änderungen von ''Bewegungssensoren'' und ''Fensterkontakten'' als Startbedingung an Alexa-Routinen koppeln. Man kann in der Alexa-App (ggf. fiktive) Öffnen eines Fensterkontaktes an das Aufsagen eines freien Textes durch die Hausbutlerin knüpfen.

'''Umsetzung''':
* Jedes Alexa-Device, dessen Status aktiv zu Amazon gepusht werden soll, im Attribut "alexaProactiveEvents" mit einer "1" versehen. Per Default wird ''kein'' Gerät laufend aktiv zu Amazon gepusht!
* das geänderte Device einmal zu Amazon pushen "set <alexa> add <device>" (oder 'Alexa, suche neue Geräte' murmeln)
* Das Gerät sollte jetzt beim Anlegen einer neuen Routine ("Neue Routine", "Wenn Folgendes passiert", "Smart Home") als möglicher Triggerpunkt erscheinen.

==== Dummygeräte: ====
Ein Dummydevice sollte einen Kontaktschalter oder Bewegungssensor simulieren, um dann in FHEM eine beliebige Bedingung als Trigger zu definieren, und eine freie Ansage in Alexa als Routine zu definieren. Hier ein Beispiel:

<syntaxhighlight lang="bash" style="width:90%;">
define voicetrigger1 dummy
attr voicetrigger1 alexaName Trigger 1
attr voicetrigger1 alexaProactiveEvents 1
attr voicetrigger1 genericDeviceType contact
attr voicetrigger1 homebridgeMapping ContactSensorState=state,values=closed:CONTACT_DETECTED;;open:CONTACT_NOT_DETECTED
attr voicetrigger1 readingList 0:closed 1:open
attr voicetrigger1 setList closed open

set alexa add voicetrigger1
set alexa restart
</syntaxhighlight>

'''Fehlersuche:'''

Der Push setzt ein intaktes Push-Token voraus. Sollte im Alexa-Logfile Folgendes erscheinen:

<code>failed to refresh token: invalid_grant: 'The request has an invalid grant parameter : refresh_token'</code>

so ist das Push-Token nicht aktuell. Weil die Auswirkung lange nur war, dass Geräteänderungen nicht aktiv an Amazon gemeldet wurden, gibt es noch keine umfassende Analyse des Problems. Es lässt sich lösen, indem eine oder beide folgenden Aktionen ausgeführt werden:
* Löschen des ".eventToken" im Alexa-Device über "deletereading"
* "FHEM-Connector"-Skill auf "alexa.amazon.de" einmal deaktivieren und dann neu verbinden

== Mögliche Probleme und Lösungen ==

Es kann vorkommen, dass Geräte zwar korrekt erkannt werden, aber das durch Alexa erkannte Kommando nicht richtig umgesetzt wird (Beispiel - mittlerweile behoben: {{Link2Forum|Topic=96766}}). Neben dem FHEM-Log gibt es noch das Logfile, welches von alexa-fhem angelegt wird.

=== Fehlersuche über die FHEM-Oberfläche ===

* alexa-fhem Logfile anschauen (Detail-Ansicht des <alexa>-Device aufrufen, klick auf '''Logfile''' oben)
* alexa-fhem im Debug-Modus aufrufen:
** -D zum alexaFHEM-params attribut hinzufügen
** Alexa-Befehl auslösen
** -D aus dem alexaFHEM-params attribut entfernen
* Die notwendigen Informationen finden sich in dem alexa-Logfile (siehe oben)

=== Fehlersuche über Kommandozeile (lies: Shell) + FHEM-Oberfläche ===

:* set <alexa> stop (FHEM-Oberfläche)
:* Auf der Kommandozeile <code>alexa-fhem -D -c /opt/fhem/alexa-fhem.cfg > debug.log</code> starten (dadurch wird die Datei debug.log erzeugt im aktuellen Verzeichnis)
:* Alexa-Befehl auslösen
:* alexa-fhem auf der Kommandozeile wieder stoppen (CTRL-C)
:* set <alexa> start (FHEM-Oberfläche)

Die Datei debug.log sollte Hinweise enthalten, wie das Problem zu lösen ist oder Dich zumindest in die richtige Richtung schieben.

Im Beispiel aus dem Forum fand sich in dem Logfile der Hinweis darauf, dass das Device mit falschen min/max-Werten unterwegs war.

=== Registrierungskey vergessen, Registrierung zurücksetzen ===

Auf der Kommandoshell:

<syntaxhighlight lang="bash" style="width:90%;">
pi@raspberrypi:~# sudo -u fhem ssh -p 58824 fhem-va.fhem.de status
Registered.
Registered on 2019-01-13T15:38:13Z.
</syntaxhighlight>

heisst, das der Vereinsserver eigentlich alles hat, was er will. Es wird kein neuer Schlüssel generiert.
Wenn Du die Situation zurücksetzen möchtest, wäre die hässliche Methode, Deinen SSH-Key zu löschen. Eleganter ist, die Registrierung auf Vereinsseite zu löschen:

<syntaxhighlight lang="bash" style="width:90%;">
pi@raspberrypi:~# sudo -u fhem ssh -p 58824 fhem-va.fhem.de unregister
Your registration has been removed
</syntaxhighlight>

löscht Deinen Schlüssel mitsamt allen dort gespeicherten Daten auf Vereinsseite. Bei Restart von alexa-fhem in FHEM-WEB wird jetzt ein neuer Registrierungskey angefordert.

== Sicherheitskonzept und Secrets ==

Um diesen Abschnitt zu verstehen, solltest Du den Abschnitt "Arbeitsweise" im Kopf haben. Einerseits ist Dir vermutlich einleuchtend, dass ein Server, der per SSH rückwärts nur ausgewählte Kommandos in den Tunnel, den Du aufgebaut hast, leitet, "irgendwie sicherer" ist. Andererseits möchte man nicht blind vertrauen.

=== SSH ===
==== SSH - macht das nichts Gefährliches? ====
SSH ist ein Veteran des Internet und entstand, um sich sicher (verschlüsselt) und schnell auf Servern einzuloggen. Schon früh wurde dabei der sogenannte "Reverse-Tunnel" implementiert: Also der vom Client (Deinem Rechner) geäußerte Wunsch: "Bitte leite mir Requests, die bei Dir, Server, auf Port xy eingehen, an meinen lokalen Port yz weiter.". Dieses Verfahren implementiert der Reverseproxy, wobei tatsächlich auf dem Server für Dich kein echter Port geöffnet wird.

Wie Dir ggf. sicher der Unix-Guru Deines Vertrauens bestätigen wird: Die Kombination
<syntaxhighlight lang="bash" style="width:50%;">
ssh -R 1234:localhost:<zufälliger port> zielserver
</syntaxhighlight>
erlaubt keine Ausführung von Shell-Kommandos auf Deinem Server, sondern einzig, dass vom SSH-Programm Verbindungen zu einem lokalen Port auf Deinem Server auf dem alexa-fhem lauscht aufgebaut werden. Du kannst also z.B. mit einem
<syntaxhighlight lang="bash" style="width:50%;">
sudo /usr/sbin/tcpdump -X -s 0 -i lo port <zufälliger port>
</syntaxhighlight>
vollständig überwachen (oder ggf. permanent aufzeichen), was auf Deinem Server von außen gesteuert passiert.

==== Wie wird bei SSH verschlüsselt? ====
Im Prinzip wie im Web auf SSL-Seiten, teils mit den gleichen Verschlüsselungsverfahren. Allerdings arbeitet SSH eher wie das im Web recht seltene Verfahren: Bei jeder Verbindung übermitteln sowohl Server wie auch Client den öffentlichen Teil ihres Schlüssels. Anders als im Web wird der Schlüssel aber nicht von einer öffentlichen Zertifizierungsstelle wie "LetsEncrypt" unterschrieben. Stattdessen entscheiden Server wie Client beim ersten Verbindungsaufbau typischerweise per manueller Frage: "Willst Du jetzt und künftig diesem Schlüssel vertrauen?" Bei der Installation wird diese Frage für Deine Seite bejaht, und fortan wird der öffentliche Schlüssel des FHEM-Servers auf Deinem Rechner gespeichert. Ab da bist Du z.B. davor sicher, dass jemand den DNS-Eintrag verbiegt oder sich in den Datenfluss Deines Providers einhängt: Ein geänderter Serverschlüssel würde bemerkt werden.
 
Soweit klar? Aus Deinem öffentlichen Schlüssel wiederum leitet der Server her: "Das ist definitiv wieder derjenige, der sich damals "registriert" hat". Und an dieser Stelle kann ich auch den ersten Teil des 3-teiligen Registrierungskeys erläutern: Die typischerweise 6-stellige Hex-Zahl am Anfang ist der Java-Hashcode Deines öffentlichen Schlüssel. Sie ist damit sozusagen Deine aus Deinem öffentlichen Schlüssel abgeleitete Benutzer-ID.

=== Die Rolle der Secrets ===
Wenn jetzt klar ist, dass die Verbindung zum Vereinsserver sicher und vertauschungsfrei funktioniert, bleiben noch 2 Probleme zu lösen:
1) Im Web bei der Skill-Aktivierung musst Du beweisen, dass Du der Mensch am Browser bist, dem der SSH-Tunnel von IP xy mit dem öffentlichen Schlüssel X gehört. Bei der automatischen Registrierung werden lokal auf Deinem Rechner zwei 64-Bit-Secrets generiert:
* Das Anmelde-Secret
* Das Bearer-Token
Beim Anmelden des SSH-Keys auf dem öffentlichen Server wird nun der Hashwert des ersten Secrets übertragen und dort in Verbindung mit Deinem öffentlichen Schlüssel gespeichert. Ein Hashwert bedeutet, dass (sofern das Verfahren, hier SHA256, funktioniert), niemand aus dem Hash das Secret zurückrechnen kann. Ein Datenbankklau auf dem Server gefährdet also nicht die Sicherheit Deines Passwortes.

Wenn Du nun beim Skill-Aktivieren den Registrierungskey eingibst, dann "sieht" der Server zum ersten Mal Dein ausgewürfeltes Secret, vergleicht es mit dem Hashwert und wird es anschließend wieder umgehend vergessen. Anhand des Hashwertes kann der Server aber entscheiden, dass Du der legitime Nutzer zum öffentlichen Schlüssel XY bist.

2) Das zweite Problem ist: Wie soll Amazon "beweisen", dass sie der legitime Aufrufer sind? Amazon erhält binnen wenigen Sekunden nach dem Klick auf "Activate Skill" den dritten Teil des Registrierungskeys als sogenanntes Bearer-Token. Zwar läuft er durch den Registrierungsserver, er wird dort, auf dem Registrierungs/Vereinsserver aber nicht gespeichert. Das Bearer-Token wird von Amazon bei allen Requests zu Deinem Server mitgesendet. Da es am Anfang zusätzlich Deine "User-ID" enthält, weiß der Vereinsserver, zu welchem SSH-Tunnel der Request zu senden ist. Aber lokal auf Deinem Rechner wird ausgewertet, ob das Token "stimmt".

== alexa-fhem Updaten bzw. "Upgraden" ==

'''Updaten einer "Connector" Installation:'''
* alexa-fhem über FHEM anhalten (Name des Alexa-Device: alexa):
:<syntaxhighlight lang="perl" style="width:50%;">set alexa stop</syntaxhighlight>

*Auf der Konsole wie anfangs bei der Installation:
:<syntaxhighlight lang="bash" style="width:50%;">sudo npm update -g alexa-fhem</syntaxhighlight>

:Manchmal hat npm Probleme mit einem Update. Dann einfach die aktuelle Version noch mal drüber Installieren:

:<syntaxhighlight lang="bash" style="width:50%;">sudo npm install -g alexa-fhem</syntaxhighlight>

*alexa-fhem über FHEM wieder starten:
:<syntaxhighlight lang="perl" style="width:50%;">set alexa start</syntaxhighlight>

'''"Upgraden von einer "Nicht-Connector" Installation (z.B. manuelle Installation per pm-Download):'''
* Daten der aktuellen Installation sichern (v.a. config.json / man weiß ja nie)
* Autostart der aktuellen alexa-fhem Installation deaktivieren:
** Bei initd: Service deaktivieren mittels: <code>sudo update-rc.d -f alexa remove</code> Vorher mittels stoppen: <code>sudo service alexa stop</code> Startscript unter /etc/init.d/ löschen.
** Bei systemd: Service deaktivieren mittels: <code>sudo systemctl disable alexa</code> Vorher mittels stoppen: <code>sudo systemctl alexa stop</code> Startscript unter /etc/systemd/system/ löschen.
* ALLE vorhandenen alexa-fhem Daten LÖSCHEN! Bleiben Dinge zurück und wird dann laut Connector installiert kann es zu Problemen kommen!
* (reboot)
* Installation von alexa-fhem laut Anleitung (Beginn dieses Wiki)
* Falls eigene Dinge von früher genutzt werden wollen/sollen (z.B. Custom Skill), dann die entsprechenden Einträge aus der gesicherten config.json in die neu angelegte alexa-fhem.cfg (zu finden unter "Edit files") übernehmen.
* Werden keine eigenen Dinge verwendet, dann kann der Port (Standard: 3000) geschlossen werden und auch die Daten unter Amazon-Developer können gelöscht werden.

== Bug- und Wunschliste ==
* Ist beim Start keine Internetverbindung vorhanden, erfolgt kein Retry -- alexa-fhem muss restartet werden (ssh_autoconfig wertet keine temporären Fehler aus)

==Weitergehende Informationen==
*[[Alexa und Mappings]]
*[[Alexa Tipps und Kniffe]]
*[[FHEM Connector for Amazon Alexa]]
[[Kategorie:HOWTOS]]
[[Kategorie:Sprachsteuerung]]

Datei:HowToSet alexaName.png

2020-03-28T08:28:36Z

MadMax-FHEM: MadMax-FHEM lud eine neue Version von Datei:HowToSet alexaName.png hoch

Datei:HowToSet alexaName.png

2020-03-28T08:26:27Z

MadMax-FHEM:

FHEM Connector für Amazon Alexa

2020-01-08T18:37:25Z

MadMax-FHEM: /* alexa-fhem Updaten */ Formatierung

{{Baustelle}}
'''Alexa FHEMlazy''' war historisch ein Fork des Original [[Alexa-Fhem|alexa-fhem]], der im Januar 2019 mit dem Original zusammengeführt wurde und nun als '''FHEM Connector''' verfügbar ist.

Er ermöglicht innerhalb von Minuten die Verknüpfung von FHEM mit einem Amazon Echo Gerät. Auch Geräte anderer Hersteller mit verbauten Mikrofonen und Alexa-Sprachassistenten-Unterstützung sollten problemlos funktionieren. Für folgende Geräte ist dies bspw. der Fall (Falls Ihr andere/weitere Gerätemodelle bzw. Hersteller in Verwendung habt, bitte hier pflegen):

* SONOS Beam und SONOS One

Gegenüber dem klassischen Ansatz ergeben sich Einschränkungen, so läuft die Software normalerweise unter dem gleichen Benutzer wie FHEM auf dem gleichen Server, und es wird z.Zt. nur der Smarthome-Skill unterstützt (die Variante, bei der die Möglichkeiten der Interaktion von Amazon festgelegt wurden).
Dafür ist weder ein Developer-Account bei Amazon, eigene Lambda- und Skillfunktionen, noch das Öffnen eines eingehenden Ports aus dem Internet nötig.
* Die Software integriert einen Installer, der die Erstkonfiguration und Anmeldung übernimmt
* Die Kommunikation zur Software auf dem heimischen Rechner und dann zu FHEM verläuft über SSH und einen vom FHEM-Verein gehosteten Server
* Funktioniert mit IPv4, IPv6, echtem Dual Stack und DS-Lite
* Als Skill bei Amazon wird der Skill "FHEM Connector" verwendet.

Der Thread im Forum zur Software ist hier: {{Link2Forum|Topic=94817}}.

{{Infobox Modul
|ModPurpose=Einfache Anbindung von FHEM an Amazon Assistent Alexa
|ModType=h
|ModCmdRef=alexa
|ModTechName=39_alexa.pm / alexa-fhem
|ModForumArea=Frontends/Sprachsteuerung
|ModOwner=gvzdus, André/ justme1968 ({{Link2FU|430|Forum}} / [[Benutzer Diskussion:Justme|Wiki]])
}}

==Einführung==

===Arbeitsweise und Datenfluss===
Vorläufig ist alexa-fhem im "FHEM Connector-Modus" ein reiner [https://developer.amazon.com/de/docs/smarthome/understand-the-smart-home-skill-api.html SmartHome-Skill].
SmartHome-Skills erhalten weder die Sprachdaten selber noch das, was Amazon in Textform verstanden hat, sondern vielmehr extrahiert Amazon aus dem verstandenen Text Anweisungen und Abfragen für Geräte, die dann an den Skill übermittelt werden. Charmant ist dabei, dass unmittelbar gefragt werden kann "Alexa, wie ist die Temperatur im Wohnzimmer?", während andere Skills zunächst explizit angesprochen werden müssen ("Alexa, frage FHEM nach der Temperatur im Wohnzimmer"). Außerdem kann der Nutzer mehrere Smarthome-Skills installieren, und die Geräte werden zu einer Gesamtmenge zusammengefasst.

Gehen wir den Datenfluss bei der konkreten Frage "Wie ist die Temperatur im Wohnzimmer?" durch:
* Alexa hat bei der Skillinstallation gelernt, dass "FHEM Connector" bei Dir einen Thermostaten im Raum Wohnzimmer kennt. Dadurch wird bei der Sprachanalyse von "Alexa Voice Service" in der Cloud erkannt, dass eine Abfrage an "FHEM Connector" erfolgversprechend ist.
* Zunächst wird die zentrale "Lambda-Funktion" von "FHEM Connector" aufgerufen. Die Funktion leitet aber im Kern nur den Request unverändert an den vom Verein bereitgestellten Server weiter. Im Request enthalten ist ein Token, das sogenannte "Bearer-Token".
* Der "Vereinsserver" prüft anhand dieses Tokens, ob es überhaupt bekannt ist, und zu welchem Nutzer es gehört. Ist dieser Nutzer verbunden, wird der Request wiederum quasi unverändert an den Nutzer weitergeleitet.
* Diese Weiterleitung passiert über einen sogenannten SSH-Reverse-Tunnel, der von Deiner Seite und der Software auf dem FHEM-Tunnel automatisch aufgebaut wird.
* Auf Deiner Seite läuft die eigentliche Software, und zwar unter nodeJS. nodeJS ist ein Javascript ausführender Miniserver, der lokal auf Port 3000 auf Requests "lauscht". In der Original-Version [[Alexa-Fhem|Alexa FHEM]] kommen die Requests aus dem Internet (hoffentlich von der eigenen Lambda-Funktion), hier bei "FHEM Connector" kommen sie ausschließlich aus dem SSH-Tunnel von lokal.
* Die Software validiert nun diesen Request anhand des Bearer-Tokens. Konkret wird dabei das bei der Installation generierte Token, dass bei der Skill-Aktivierung an Amazon übertragen wurde, mit dem lokal gespeicherten Wert verglichen. Stimmt das Token, wird der Befehl verarbeitet, üblicherweise wird hierbei ein Aufruf an die Webschnittstelle von FHEM abgesetzt.
* FHEM führt den Befehl aus

Hört sich langsam und kompliziert an? Kompliziert: Okay. Langsam eher nicht, in etlichen Fällen liegt die Gesamtantwortszeit unter 200 ms.

Soweit ein erster Überblick über die Datenflüsse. Im Abschnitt Sicherheit ist das Konzept der Absicherung deutlich genauer und ausführlicher beschrieben.

==Installation==

Du wirst bei der Installation zuerst auf der Kommandozeile auf Deinem Raspberry (o.ä.) unterwegs sein, anschließend im Webfrontend von FHEM, und zum Schluss auf der Alexa-Konsole im Web.

===node.js installieren===

Bei Jessy liegt NodeJS bereits in einer ausreichend aktuellen Version vor. Mit

<syntaxhighlight lang="bash" style="width:50%;">
sudo apt-get install nodejs npm
</syntaxhighlight>

kannst Du es installieren. Mit
<syntaxhighlight lang="bash" style="width:50%;">
node --version
</syntaxhighlight>

erfährst Du die aktuelle Version - wenn hier etwas mit "8" vorneweg erscheint, ist alles gut.
Ansonsten suche Dir bitte eine Anleitung im Web, wie Du NodeJS auf Deinem System auf einen aktuellen Stand bringen kannst.

=== Alexa-FHEM installieren ===

Nun installieren wir Alexa-fhem aus dem offiziellen Repository:

<syntaxhighlight lang="bash" style="width:50%;">
sudo npm install -g alexa-fhem
</syntaxhighlight>

Der Vorgang benötigt etwas Zeit.

=== Alexa-FHEM aktivieren ===

Wechsele jetzt in FHEM-Web!

Wichtig ist, dass das Alexa-Modul in der Version ab 14. Januar 2019 vorliegt. Dafür bitte einmal FHEM aktualisieren:
Speichern der Config nicht vergessen, und

<syntaxhighlight lang="bash" style="width:50%;">
update
shutdown restart
</syntaxhighlight>

Alles, was jetzt noch nötig ist, ist das Anlegen eines Alexa-Devices. Gib dafür in der FHEM-Web-Kommandozeile

<syntaxhighlight lang="bash" style="width:50%;">
define alexa alexa
</syntaxhighlight>

an. Nun läuft, während Du bereits das neu angelegte Alexa-Devices siehst, ein komplexer Prozess im Hintergrund:

* Falls noch kein SSH-Key für den Benutzer, unter dem FHEM läuft, existiert, wird einer generiert
* Es wird ein Secret-Key im Prozess generiert, dass den Server nicht verlässt, und der Skillanmeldung dient.
* Du wirst auf dem Server "va-fhem.fhem.de" des FHEM-Vereins mit dem SSH-Key angemeldet, und der Hash-Wert Deines Secret-Key dort abgelegt.

Und wenn Du diese Sätze gelesen hast, sollte inzwischen sich das Alexa-Device in FHEM-Web aktualisiert haben, und
ungefähr so aussehen:

[[Datei:Alexa-Device-2.png|800px]]

Neben dem Status für alexa-fhem und der Proxyverbindung ist wichtig, dass diese beiden Zeilen beim Reload aufgetaucht sind:

<syntaxhighlight lang="bash" style="width:90%;">
alexaFHEM.bearerToken crypt:...
alexaFHEM.skillRegKey crypt:...
</syntaxhighlight>

Ja, und diesen Schlüssel benötigst Du wirklich! Also am besten schon einmal mit

<syntaxhighlight lang="bash" style="width:90%;">
get <alexa> proxyKey
</syntaxhighlight>

in Klartext anzeigen lassen und in ein Editor-Fenster dauerhaft wegsichern.

Jetzt solltest Du Dein Alexa-Device nicht mehr löschen, denn das im Reading angezeigte "bearerToken" zu löschen bedeutet, dass die Software die Zugriffe von nicht mehr überprüfen kann und keine Kommandos mehr funktionieren. In diesem Fall hilft nur die Neuinstallation des Skills.

==== Fehler bei der Aktivierung ====

Während kompliziertere Fehlerfälle im Abschnitt "Mögliche Probleme und Lösungen" behandelt werden, hier häufige Fälle, warum die kryptischen Zeilen nicht auftauchen:

* Zuerst bitte einfach einmal die Seite neu laden.

===== 401: Authorization Required =====

Wenn Du FHEM-Web mit einem User/Passwort-Schutz versehen hast, wirst du folgende Fehlermeldung sehen:

<syntaxhighlight lang="bash" style="width:90%;">
alexaFHEM stopped; failed to connect to fhem: 401: Authorization Required
</syntaxhighlight>

In der Regel musst du die Angaben User/Passwort noch einmal explizit setzen. Im Attribute-Abschnitt "alexaFHEM-auth" auswählen, User/Passwort mit ":" getrennt angeben und "attr" anklicken. alexa-fhem wird automatisch neu gestartet. Hier das Ganze in der Text-Variante:

<syntaxhighlight lang="bash" style="width:90%;">
attr alexa alexaFHEM-auth user:pass
</syntaxhighlight>

===== Permission denied =====

Wenn du folgende Fehlermeldungen im Alexa Logfile siehst, wurde das Verzeichnis "/opt/fhem/.ssh/" von dir bei der Arbeit mit "root" oder "sudo" mit den falschen Berechtigungen versehen:

<syntaxhighlight lang="bash" style="width:90%;">
[2019-7-25 11:59:12] sshautoconf: aborted with ssh-keygen returned error - key_save_private: Permission denied
[2019-7-25 11:59:12] *** SSH: proxy configuration failed: ssh-keygen returned error - key_save_private: Permission denied
</syntaxhighlight>

Prüfen kannst du die Berechtigungen mit folgendem Befehl auf der Shell-Konsole:

<syntaxhighlight lang="bash" style="width:90%;">
ls -l /opt/fhem/.ssh
</syntaxhighlight>

Du solltest dann folgende Ausgabe erhalten:

<syntaxhighlight lang="bash" style="width:90%;">
insgesamt 12
-rw------- 1 fhem dialout 1675 Jul 12 13:10 id_rsa
-rw-r--r-- 1 fhem dialout 391 Jul 12 13:10 id_rsa.pub
-rw-r--r-- 1 fhem dialout 884 Jul 12 13:10 known_hosts
</syntaxhighlight>

Steht in der Ausgabe nicht "fhem dialout" (dein fhem User), sondern bspw. "root root", dann bspw. mit folgendem Befehl an deinen fhem User anpassen:

<syntaxhighlight lang="bash" style="width:90%;">
chown fhem:dialout /opt/fhem/.ssh
</syntaxhighlight>

Mit dem ersten Befehl "ls -l ..." kannst du dann nochmal prüfen, ob die Berechtigungen korrekt übernommen wurden.

===== weitere Prüfungen =====

Hast Du noch die Shell-Konsole offen? Dann prüfe bitte noch einmal auf der Konsole, ob nun zwei Prozesse laufen:

<syntaxhighlight lang="bash" style="width:50%;">
ps -ef | egrep '(alexa|ssh)'
</syntaxhighlight>

sollte Dir idealerweise so etwas anzeigen:
<syntaxhighlight lang="bash" style="width:90%;">
fhem 31322 1 99 13:56 ? 00:00:03 alexa
fhem 31332 31322 8 13:56 ? 00:00:00 /usr/bin/ssh -R 1234:127.0.0.1:<zufälliger port> -oServerAliveInterval=90 -p 58824 fhem-va.fhem.de
</syntaxhighlight>

"alexa" ist dabei der Node-JS-Prozess, der ssh-Prozess ist die aufgebaute Verbindung zum Vereinsserver.

Wenn Du diese Prozesse '''nicht''' siehst oder das Alexa-Device keinen Registrierungskey anzeigt, dann ist leider der Start nicht glatt verlaufen.

Im Logfile (über den link <code>Logfile</code> in der Detail-Ansicht über <code>set</Code>, oder über den Namen bei ''currentlogfile'' in den Internals) findest Du idealerweise selber Hinweise, wo es hakt, oder kannst im Forum nachfragen.

=== Geräte im FHEM-Webfrontend zuweisen ===
Um das Aha-Erlebnis zu vergrößern, ist jetzt ein guter Zeitpunkt, 1 oder besser mind. 2 Geräte für den Alexa-Dienst zuzuweisen. Von Haus aus wird keines Deiner FHEM-Geräte automatisch Alexa zugewiesen!

Wähle die Geräte aus, rufe sie auf und setze das Attribut "alexaName". Hierbei in Kürze nur der Hinweis:
* Keine Angst vor Leerzeichen und Umlauten, funktioniert.
* Große Angst vor Rechtschreibfehlern (Terrasse, Rollladen) oder komplizierten Wörtern "handgebastelte Martinslaterne im Kinderzimmer Iphigenie-Chantal".
* Das Attribut "alexaRoom" ist NUR FÜR DEN CUSTOM SKILL relevant. Ausnahme: structure und LightScene Devices, siehe: [[FHEM_Connector_f%C3%BCr_Amazon_Alexa#Was_geht_alles_.3F]].

Lade die Geräte neu in die Software, indem Du <code>set <alexa> restart</code> ausführst! 
 

'''Anmerkungen (weil oft gestellte Fragen im Forum) bzgl. Erkennung von Geräten:'''

* Wichtig ist, dass die Filtereinstellung in der alexa-fhem.cfg (zu finden unter "Edit Files") passt.
Also was dort eingetragen ist (Standard: alexaName=..* / also es ist ein alexaName vergeben) auch an den entsrpechenden Devices in fhem vorhanden ist.
Stimmt das schon nicht überein, kann alexa-fhem schon mal keine Devices von fhem abfragen/finden.
Ob der Filter entsprechend funktioniert kann man wie folgt testen: ''list Filtereinstellung'' beispiel mit Standardfilter: ''list alexaName=..*''

* Hat alexa-fhem per Filter Devices aus fhem "gefunden", geht es weiter mit der "Erkennung". Also um welches Device (Typ und "Fähigkeiten") handelt es sich. Dazu gilt folgendes:
** sind entsprechende Readings beim Device vorhanden (z.B. temperature, state mit on/off, ...) erkennt das alexa-fhem automatisch. Die Liste der automatisch erkannten Readings wächst ständig. Daher erst mal schauen ob das Device bereits entsprechend erkannt (typisiert) wurde. Das kann durch prüfen des alexa-fhem-Logs geschehen (NICHT fhem-log!).
** sind entsprechende "set-Befehle" erkennbar (oft auch durch Readings). Also ist beispielsweise (wie beim Dummy nötig) ein ''setList'' mit entsprechenden Einträgen vorhanden oder entsprechende Readings, z.B. desired-temp zum Stellen der Temperatur etc.
** wird das Device nicht richtig oder "unvollständig" erkannt helfen folgende Attribute:
*** genericDeviceType: hiermit kann alexa-fhem in die gewünschte Richtung "geschubbst" werden. Anmerkung: man kann nicht alles erzwingen, Readings bzw. set-Befehle müssen passen (oder per homebridgeMapping passend gemacht werden). Wenn ein genericDeviceType nicht per "Drop-Down" erscheint, dann kann er auch (wenn bekannt) einfach per WEB-cmd eingegeben werden: ''attr Devicename genericDeviceType media''
*** homebridgeMapping: hierdurch kann alexa-fhem bei der Erkennung von Zuständen und möglichen Einstellungen (also WAS kann das Device) unterstützt werden. Mittels homebridgeMapping können vorhandene Readings (Zustände) auf für alexa-fhem bekannte Zustände gemappt werden. Ebenso können damit Standard-fhem-Kommandos von alexa-fhem auf Device-spezifische gemappt werden. Beispiel: on/off auf Ein/Aus (falls das Device statt on/off eben ein Ein/Aus erwartet). Zum Beispiel: <syntaxhighlight lang="bash" style="width:50%;">
attr <thermostat> homebridgeMapping TargetTemperature=target::target,minValue=18,maxValue=25,minStep=0.5 CurrentTemperature=myTemp:temperature
</syntaxhighlight> [https://github.com/justme-1968/homebridge-fhem/blob/master/README.md weitere Beispiele]

'''Anmerkung bzgl. genericDeviceType und homebridgeMapping:''' 
* diese Attribute werden von verschiedenen "Sprachsteuerungsmodulen" in fhem verwendet (homebridge [dort wurde es "erfunden"], alexa-fhem, gassistant, ...). Daher ist nicht jedes Mapping für alle "Dienste" verwendbar. Ausprobieren schadet aber nicht.
* ebenso kann man mit diesen Attributen (homebridgeMapping wird gerne so "missbraucht") nichts erzwingen, was seitens Amazon/Alexa nicht unterstützt bzw. verstanden wird! D.h. zunächst ist zu prüfen, ob ein bestimmter (gewünschter) Sprachbefehl seitens Amazon/Alexa unterstützt wird! Aktuelles Beispiel (Stand Jan 2020): "Alexa, fahre den Rollo hoch/runter". Da ist Amazon/Alexa gerade dabei etwas zu tun. Bislang wird das nicht unterstützt, also ist das auch mit einem entsprechenden homebridgeMapping nicht zu erzwingen! Was unterstützt wird kann man bei Amazon nachlesen: [https://developer.amazon.com/es-ES/docs/alexa/device-apis/list-of-interfaces.html]

== Finale: Skill verknüpfen ==
Suche im WebFrontend oder der Alexa-App den Skill "FHEM Connector". Für nicht-Mac/iOS Anwerder empfiehlt das WebFrontend (https://alexa.amazon.de) statt die App, damit Du den Anmeldeschlüssel auch bequem kopieren kannst.

Wenn du noch nicht bei Amazon angemeldet bist, erwartet Amazon zunächst, dass Du Dich normal bei Amazon anmeldest.

Sobald Du "FHEM Connector" aktivierst, öffnet sich ein Browser-Tab mit folgender Maske: 
[[Datei:FHEMlazy_login.png|240px]]

Hier kopierst Du Deinen Anmeldeschlüssel (im Klartext!) hinein und klickst auf Check. Als glücklicher Mensch ist auf der folgenden Statusseite alles grün: 
[[Datei:FHEMlazy_check.png|240px]]

Im Einzelnen wird hier geprüft, ob Du per SSH verbunden bist (und auch Deine IP zur Sicherheit angezeigt), ob der Reverse-Tunnel steht, ob nodeJS erreichbar ist und wie viele Geräte Alexa gleich finden sollte (in meinem Fall 22).

Sollte etwas nicht grün sein und Du eine Idee zum Fixen haben, kannst Du mit "Retry" neue Versuche auslösen.

Ist alles okay, klicke rechts den Button "Activate Skill". Du springst damit wieder zurück zu Amazon, die Dir hoffentlich zur erfolgreichen Verknüpfung gratulieren.

Amazon möchte nun unmittelbar die Gerätesuche starten, und unter SmartHome-Geräte sollten diese nun auftauchen.

== Was geht alles ? ==

* Geräte, die sich ein- und ausschalten lassen:
** Automatisch: Müssen <code>set on</code> und <code>set off</code> Kommandos haben
** dummys müssen <code>setList</code> mit on und off haben
** Über <code>genericDeviceType</code> switch bzw. light kann bestimmt werden ob es in alexa als Schalter oder Licht behandelt wird.
** Wenn die Set-Kommandos im FHEM Device anders benannt sind: hombridgeMapping On:cmdOn=<ein>,cmdOff=<aus> setzen
** Kommandos:
***Alexa, schalte <name> ein/aus
***Alexa, Licht an/aus
***Alexa, schalte <gruppe> ein/aus

* Geräte, die eine Temperatur messen
** Automatisch: Es muss ein Reading temperature geben
** Über <code>genericDeviceType</code> thermometer
** Sonst: hombridgeMapping CurrentTemperature:reading=<reading>

* Geräte, deren Helligkeit sich ändern lässt
** Automatisch: wenn <code>dim</code> oder <code>pct</code> Kommandos erkannt werden
** Über <code>genericDeviceType</code> light
** Über homebridgeMapping: Wenn <code>helligkeit</code> das Reading für die aktuelle Helligkeit enthält und die Helligkeit mit <code>set <device> prozent xxx</code> gesetzt wird, sieht das homebridgeMapping wie folgt aus:
*** homebridgeMapping Brightness=helligkeit::prozent,minValue=0,maxValue=<maximalwert>

**Kommandos:
***Alexa, mache <name> heller/dunkler
***Alexa, Licht heller/dunkler

* Geräte, deren Farbe sich ändern lässt
** ...

* Geräte, deren Farbtemperatur sich ändern lässt
** ...

* Geräte, bei denen sich eine Lautstärke einstellen lässt
** ...

* Geräte, bei denen sich ein prozentualer Wert einstellen lässt
** Automatisch: wenn <code>dim</code> oder <code>pct</code> Kommandos erkannt werden
** ...

* elektrische Türschlösser
** <code>genericDeviceType</code>: lock
** hombridgeMapping mit LockCurrentState und LockTargetState

* Thermostate
** Über <code>genericDeviceType</code> thermostate
** ...

* structure Devices aus FHEM (ab alexa-fhem version 0.5.7)
** können mit <code>genericDeviceType</code> scene als Szene eingebunden werden
** über <code>alexaRoom</code> kann der name um einen Ort ergänzt werden
** Szenen aus einer structure lassen sich ein- und ausschalten
** Wichtig:
*** Ein Skill darf nur 12 Szenen automatisch erkennen und einbinden.

* LightScene Devices aus FHEM (ab alexa-fhem version 0.5.8)
** können mit <code>genericDeviceType</code> scene als Szenen eingebunden werden
** über <code>alexaRoom</code> kann der name um einen Ort ergänzt werden
** Szenen aus einer LightScene lassen sich nur einschalten
** Wichtig:
*** Ein Skill darf nur 12 Szenen automatisch erkennen und einbinden.

* Geräte, deren Kanal sich umschalten lässt (ab alexa-fhem version 0.5.13)
** Über <code>genericDeviceType</code> media
** hombridgeMapping ChannelController:reading=<reading>,cmd=<cmd>
** Erlaubte Werte siehe hier: https://developer.amazon.com/de/docs/device-apis/alexa-channelcontroller.html#changechannel
** ...

* Geräte, deren Playback status sich schalten lässt (ab alexa-fhem version 0.5.13)
** Über <code>genericDeviceType</code> media
** hombridgeMapping PlaybackController:playback,values=Play;Pause;Stop;Previous;Next
** Erlaubte Werte siehe hier: https://developer.amazon.com/de/docs/device-apis/alexa-playbackcontroller.html#discovery
** ...

* Geräte, deren Eingang sich umschalten lässt (ab alexa-fhem version 0.5.13)
** Über <code>genericDeviceType</code> media
** hombridgeMapping InputController:reading=<reading>,cmd=<cmd>,values=HDMI+1;HDMI+2;XBOX
** Erlaubte Werte siehe hier: https://developer.amazon.com/de/docs/device-apis/alexa-property-schemas.html#input
** ...

* Kontaktsensoren (ab alexa-fhem version 0.5.15)
** Über <code>genericDeviceType</code> contact
** hombridgeMapping ContactSensorState:reading=<reading> oder CurrentDoorState:reading=<reading>
** Die Anzeige in der Alexa-App funktioniert sofort, die Abfrage per Sprache erst ab Version 0.5.27.

* Geräte, deren Lautstärke sich ändern lässt (ab alexa-fhem version 0.5.24)
** Über <code>genericDeviceType</code> speaker
** Automatisch: es muss ein Reading <code>volume</code> und/oder <code>mute</code> geben
** hombridgeMapping Volume:reading=<reading>,cmd=<cmd> Mute:reading=<reading>,cmd=<cmd>
** ...

* Geräte, die sich ein- (und optional) ausschalten lassen als Szene (ab alexa-fhem version 0.5.26)
** Über <code>genericDeviceType</code> scene
** Automatisch: Müssen <code>set on</code> und <code>set off</code> Kommandos haben
** hombridgeMapping On:reading=<reading>,cmdOn=<cmd>[,cmdOff=<cmd>]
** Hinweis: Fehlende Kommandos lassen sich mit cmdalias erzeugen
** Wichtig:
*** Ein Skill darf nur 12 Szenen automatisch erkennen und einbinden.

Es werden noch einige andere häufig verwendete Geräte (Homematic, hue,...) automatisch erkannt.

to be continued ...

In der [https://developer.amazon.com/docs/device-apis/list-of-interfaces.html List of Capability Interfaces] bei Amazon kann man sehen, welche Möglichkeiten das Smart Home Skill API aktuell in einzelnen Ländern bietet. Leider ohne die jeweiligen landessprachlichen Kommandos.

== Mögliche Probleme und Lösungen ==

Es kann vorkommen, dass Geräte zwar korrekt erkannt werden, aber das durch Alexa erkannte Kommando nicht richtig umgesetzt wird (Beispiel - mittlerweile behoben: {{Link2Forum|Topic=96766}}). Neben dem FHEM-Log gibt es noch das Logfile, welches von alexa-fhem angelegt wird.

=== Fehlersuche über die FHEM-Oberfläche ===

* alexa-fhem Logfile anschauen (Detail-Ansicht des <alexa>-Device aufrufen, klick auf '''Logfile''' oben)
* alexa-fhem im Debug-Modus aufrufen:
** -D zum alexaFHEM-params attribut hinzufügen
** Alexa-Befehl auslösen
** -D aus dem alexaFHEM-params attribut entfernen
* Die notwendigen Informationen finden sich in dem alexa-Logfile (siehe oben)

=== Fehlersuche über Kommandozeile (lies: Shell) + FHEM-Oberfläche ===

:* set <alexa> stop (FHEM-Oberfläche)
:* Auf der Kommandozeile <code>alexa-fhem -D -c /opt/fhem/alexa-fhem.cfg > debug.log</code> starten (dadurch wird die Datei debug.log erzeugt im aktuellen Verzeichnis)
:* Alexa-Befehl auslösen
:* alexa-fhem auf der Kommandozeile wieder stoppen (CTRL-C)
:* set <alexa> start (FHEM-Oberfläche)

Die Datei debug.log sollte Hinweise enthalten, wie das Problem zu lösen ist oder Dich zumindest in die richtige Richtung schieben.

Im Beispiel aus dem Forum fand sich in dem Logfile der Hinweis darauf, dass das Device mit falschen min/max-Werten unterwegs war.

=== Registrierungskey vergessen, Registrierung zurücksetzen ===

Auf der Kommandoshell:

<syntaxhighlight lang="bash" style="width:90%;">
pi@raspberrypi:~# sudo -u fhem ssh -p 58824 fhem-va.fhem.de status
Registered.
Registered on 2019-01-13T15:38:13Z.
</syntaxhighlight>

heisst, das der Vereinsserver eigentlich alles hat, was er will. Es wird kein neuer Schlüssel generiert.
Wenn Du die Situation zurücksetzen möchtest, wäre die hässliche Methode, Deinen SSH-Key zu löschen. Eleganter ist, die Registrierung auf Vereinsseite zu löschen:

<syntaxhighlight lang="bash" style="width:90%;">
pi@raspberrypi:~# sudo -u fhem ssh -p 58824 fhem-va.fhem.de unregister
Your registration has been removed
</syntaxhighlight>

löscht Deinen Schlüssel mitsamt allen dort gespeicherten Daten auf Vereinsseite. Bei Restart von alexa-fhem in FHEM-WEB wird jetzt ein neuer Registrierungskey angefordert.

== Sicherheitskonzept und Secrets ==

Um diesen Abschnitt zu verstehen, solltest Du den Abschnitt "Arbeitsweise" im Kopf haben. Einerseits ist Dir vermutlich einleuchtend, dass ein Server, der per SSH rückwärts nur ausgewählte Kommandos in den Tunnel, den Du aufgebaut hast, leitet, "irgendwie sicherer" ist. Andererseits möchte man nicht blind vertrauen.

=== SSH ===
==== SSH - macht das nichts Gefährliches? ====
SSH ist ein Veteran des Internet und entstand, um sich sicher (verschlüsselt) und schnell auf Servern einzuloggen. Schon früh wurde dabei der sogenannte "Reverse-Tunnel" implementiert: Also der vom Client (Deinem Rechner) geäußerte Wunsch: "Bitte leite mir Requests, die bei Dir, Server, auf Port xy eingehen, an meinen lokalen Port yz weiter.". Dieses Verfahren implementiert der Reverseproxy, wobei tatsächlich auf dem Server für Dich kein echter Port geöffnet wird.

Wie Dir ggf. sicher der Unix-Guru Deines Vertrauens bestätigen wird: Die Kombination
<syntaxhighlight lang="bash" style="width:50%;">
ssh -R 1234:localhost:<zufälliger port> zielserver
</syntaxhighlight>
erlaubt keine Ausführung von Shell-Kommandos auf Deinem Server, sondern einzig, dass vom SSH-Programm Verbindungen zu einem lokalen Port auf Deinem Server auf dem alexa-fhem lauscht aufgebaut werden. Du kannst also z.B. mit einem
<syntaxhighlight lang="bash" style="width:50%;">
sudo /usr/sbin/tcpdump -X -s 0 -i lo port <zufälliger port>
</syntaxhighlight>
vollständig überwachen (oder ggf. permanent aufzeichen), was auf Deinem Server von außen gesteuert passiert.

==== Wie wird bei SSH verschlüsselt? ====
Im Prinzip wie im Web auf SSL-Seiten, teils mit den gleichen Verschlüsselungsverfahren. Allerdings arbeitet SSH eher wie das im Web recht seltene Verfahren: Bei jeder Verbindung übermitteln sowohl Server wie auch Client den öffentlichen Teil ihres Schlüssels. Anders als im Web wird der Schlüssel aber nicht von einer öffentlichen Zertifizierungsstelle wie "LetsEncrypt" unterschrieben. Stattdessen entscheiden Server wie Client beim ersten Verbindungsaufbau typischerweise per manueller Frage: "Willst Du jetzt und künftig diesem Schlüssel vertrauen?" Bei der Installation wird diese Frage für Deine Seite bejaht, und fortan wird der öffentliche Schlüssel des FHEM-Servers auf Deinem Rechner gespeichert. Ab da bist Du z.B. davor sicher, dass jemand den DNS-Eintrag verbiegt oder sich in den Datenfluss Deines Providers einhängt: Ein geänderter Serverschlüssel würde bemerkt werden.
 
Soweit klar? Aus Deinem öffentlichen Schlüssel wiederum leitet der Server her: "Das ist definitiv wieder derjenige, der sich damals "registriert" hat". Und an dieser Stelle kann ich auch den ersten Teil des 3-teiligen Registrierungskeys erläutern: Die typischerweise 6-stellige Hex-Zahl am Anfang ist der Java-Hashcode Deines öffentlichen Schlüssel. Sie ist damit sozusagen Deine aus Deinem öffentlichen Schlüssel abgeleitete Benutzer-ID.

=== Die Rolle der Secrets ===
Wenn jetzt klar ist, dass die Verbindung zum Vereinsserver sicher und vertauschungsfrei funktioniert, bleiben noch 2 Probleme zu lösen:
1) Im Web bei der Skill-Aktivierung musst Du beweisen, dass Du der Mensch am Browser bist, dem der SSH-Tunnel von IP xy mit dem öffentlichen Schlüssel X gehört. Bei der automatischen Registrierung werden lokal auf Deinem Rechner zwei 64-Bit-Secrets generiert:
* Das Anmelde-Secret
* Das Bearer-Token
Beim Anmelden des SSH-Keys auf dem öffentlichen Server wird nun der Hashwert des ersten Secrets übertragen und dort in Verbindung mit Deinem öffentlichen Schlüssel gespeichert. Ein Hashwert bedeutet, dass (sofern das Verfahren, hier SHA256, funktioniert), niemand aus dem Hash das Secret zurückrechnen kann. Ein Datenbankklau auf dem Server gefährdet also nicht die Sicherheit Deines Passwortes.

Wenn Du nun beim Skill-Aktivieren den Registrierungskey eingibst, dann "sieht" der Server zum ersten Mal Dein ausgewürfeltes Secret, vergleicht es mit dem Hashwert und wird es anschließend wieder umgehend vergessen. Anhand des Hashwertes kann der Server aber entscheiden, dass Du der legitime Nutzer zum öffentlichen Schlüssel XY bist.

2) Das zweite Problem ist: Wie soll Amazon "beweisen", dass sie der legitime Aufrufer sind? Amazon erhält binnen wenigen Sekunden nach dem Klick auf "Activate Skill" den dritten Teil des Registrierungskeys als sogenanntes Bearer-Token. Zwar läuft er durch den Registrierungsserver, er wird dort, auf dem Registrierungs/Vereinsserver aber nicht gespeichert. Das Bearer-Token wird von Amazon bei allen Requests zu Deinem Server mitgesendet. Da es am Anfang zusätzlich Deine "User-ID" enthält, weiß der Vereinsserver, zu welchem SSH-Tunnel der Request zu senden ist. Aber lokal auf Deinem Rechner wird ausgewertet, ob das Token "stimmt".

== alexa-fhem Updaten bzw. "Upgraden" ==

'''Updaten einer "Connector" Installation:'''
* alexa-fhem über FHEM anhalten (Name des Alexa-Device: alexa):
:<syntaxhighlight lang="perl" style="width:50%;">set alexa stop</syntaxhighlight>

*Auf der Konsole wie anfangs bei der Installation:
:<syntaxhighlight lang="bash" style="width:50%;">sudo npm update -g alexa-fhem</syntaxhighlight>

:Manchmal hat npm Probleme mit einem Update. Dann einfach die aktuelle Version noch mal drüber Installieren:

:<syntaxhighlight lang="bash" style="width:50%;">sudo npm install -g alexa-fhem</syntaxhighlight>

*alexa-fhem über FHEM wieder starten:
:<syntaxhighlight lang="perl" style="width:50%;">set alexa start</syntaxhighlight>

'''"Upgraden von einer "Nicht-Connector" Installation (z.B. manuelle Installation per pm-Download):'''
* Daten der aktuellen Installation sichern (v.a. config.json / man weiß ja nie)
* Autostart der aktuellen alexa-fhem Installation deaktivieren:
** Bei initd: Service deaktivieren mittels: <code>sudo update-rc.d -f alexa remove</code> Vorher mittels stoppen: <code>sudo service alexa stop</code> Startscript unter /etc/init.d/ löschen.
** Bei systemd: Service deaktivieren mittels: <code>sudo systemctl disable alexa</code> Vorher mittels stoppen: <code>sudo systemctl alexa stop</code> Startscript unter /etc/systemd/system/ löschen.
* ALLE vorhandenen alexa-fhem Daten LÖSCHEN! Bleiben Dinge zurück und wird dann laut Connector installiert kann es zu Problemen kommen!
* (reboot)
* Installation von alexa-fhem laut Anleitung (Beginn dieses Wiki)
* Falls eigene Dinge von früher genutzt werden wollen/sollen (z.B. Custom Skill), dann die entsprechenden Einträge aus der gesicherten config.json in die neu angelegte alexa-fhem.cfg (zu finden unter "Edit files") übernehmen.
* Werden keine eigenen Dinge verwendet, dann kann der Port (Standard: 3000) geschlossen werden und auch die Daten unter Amazon-Developer können gelöscht werden.

== Bug- und Wunschliste ==
* Ist beim Start keine Internetverbindung vorhanden, erfolgt kein Retry -- alexa-fhem muss restartet werden (ssh_autoconfig wertet keine temporären Fehler aus)

==Weitergehende Informationen==
*[[Alexa und Mappings]]
*[[Alexa Tipps und Kniffe]]
*[[FHEM Connector for Amazon Alexa]]
[[Kategorie:HOWTOS]]
[[Kategorie:Sprachsteuerung]]

FHEM Connector für Amazon Alexa

2020-01-08T18:29:16Z

MadMax-FHEM: /* alexa-fhem Updaten */ Ergänz um "Umstieg von alt auf neu"...

{{Baustelle}}
'''Alexa FHEMlazy''' war historisch ein Fork des Original [[Alexa-Fhem|alexa-fhem]], der im Januar 2019 mit dem Original zusammengeführt wurde und nun als '''FHEM Connector''' verfügbar ist.

Er ermöglicht innerhalb von Minuten die Verknüpfung von FHEM mit einem Amazon Echo Gerät. Auch Geräte anderer Hersteller mit verbauten Mikrofonen und Alexa-Sprachassistenten-Unterstützung sollten problemlos funktionieren. Für folgende Geräte ist dies bspw. der Fall (Falls Ihr andere/weitere Gerätemodelle bzw. Hersteller in Verwendung habt, bitte hier pflegen):

* SONOS Beam und SONOS One

Gegenüber dem klassischen Ansatz ergeben sich Einschränkungen, so läuft die Software normalerweise unter dem gleichen Benutzer wie FHEM auf dem gleichen Server, und es wird z.Zt. nur der Smarthome-Skill unterstützt (die Variante, bei der die Möglichkeiten der Interaktion von Amazon festgelegt wurden).
Dafür ist weder ein Developer-Account bei Amazon, eigene Lambda- und Skillfunktionen, noch das Öffnen eines eingehenden Ports aus dem Internet nötig.
* Die Software integriert einen Installer, der die Erstkonfiguration und Anmeldung übernimmt
* Die Kommunikation zur Software auf dem heimischen Rechner und dann zu FHEM verläuft über SSH und einen vom FHEM-Verein gehosteten Server
* Funktioniert mit IPv4, IPv6, echtem Dual Stack und DS-Lite
* Als Skill bei Amazon wird der Skill "FHEM Connector" verwendet.

Der Thread im Forum zur Software ist hier: {{Link2Forum|Topic=94817}}.

{{Infobox Modul
|ModPurpose=Einfache Anbindung von FHEM an Amazon Assistent Alexa
|ModType=h
|ModCmdRef=alexa
|ModTechName=39_alexa.pm / alexa-fhem
|ModForumArea=Frontends/Sprachsteuerung
|ModOwner=gvzdus, André/ justme1968 ({{Link2FU|430|Forum}} / [[Benutzer Diskussion:Justme|Wiki]])
}}

==Einführung==

===Arbeitsweise und Datenfluss===
Vorläufig ist alexa-fhem im "FHEM Connector-Modus" ein reiner [https://developer.amazon.com/de/docs/smarthome/understand-the-smart-home-skill-api.html SmartHome-Skill].
SmartHome-Skills erhalten weder die Sprachdaten selber noch das, was Amazon in Textform verstanden hat, sondern vielmehr extrahiert Amazon aus dem verstandenen Text Anweisungen und Abfragen für Geräte, die dann an den Skill übermittelt werden. Charmant ist dabei, dass unmittelbar gefragt werden kann "Alexa, wie ist die Temperatur im Wohnzimmer?", während andere Skills zunächst explizit angesprochen werden müssen ("Alexa, frage FHEM nach der Temperatur im Wohnzimmer"). Außerdem kann der Nutzer mehrere Smarthome-Skills installieren, und die Geräte werden zu einer Gesamtmenge zusammengefasst.

Gehen wir den Datenfluss bei der konkreten Frage "Wie ist die Temperatur im Wohnzimmer?" durch:
* Alexa hat bei der Skillinstallation gelernt, dass "FHEM Connector" bei Dir einen Thermostaten im Raum Wohnzimmer kennt. Dadurch wird bei der Sprachanalyse von "Alexa Voice Service" in der Cloud erkannt, dass eine Abfrage an "FHEM Connector" erfolgversprechend ist.
* Zunächst wird die zentrale "Lambda-Funktion" von "FHEM Connector" aufgerufen. Die Funktion leitet aber im Kern nur den Request unverändert an den vom Verein bereitgestellten Server weiter. Im Request enthalten ist ein Token, das sogenannte "Bearer-Token".
* Der "Vereinsserver" prüft anhand dieses Tokens, ob es überhaupt bekannt ist, und zu welchem Nutzer es gehört. Ist dieser Nutzer verbunden, wird der Request wiederum quasi unverändert an den Nutzer weitergeleitet.
* Diese Weiterleitung passiert über einen sogenannten SSH-Reverse-Tunnel, der von Deiner Seite und der Software auf dem FHEM-Tunnel automatisch aufgebaut wird.
* Auf Deiner Seite läuft die eigentliche Software, und zwar unter nodeJS. nodeJS ist ein Javascript ausführender Miniserver, der lokal auf Port 3000 auf Requests "lauscht". In der Original-Version [[Alexa-Fhem|Alexa FHEM]] kommen die Requests aus dem Internet (hoffentlich von der eigenen Lambda-Funktion), hier bei "FHEM Connector" kommen sie ausschließlich aus dem SSH-Tunnel von lokal.
* Die Software validiert nun diesen Request anhand des Bearer-Tokens. Konkret wird dabei das bei der Installation generierte Token, dass bei der Skill-Aktivierung an Amazon übertragen wurde, mit dem lokal gespeicherten Wert verglichen. Stimmt das Token, wird der Befehl verarbeitet, üblicherweise wird hierbei ein Aufruf an die Webschnittstelle von FHEM abgesetzt.
* FHEM führt den Befehl aus

Hört sich langsam und kompliziert an? Kompliziert: Okay. Langsam eher nicht, in etlichen Fällen liegt die Gesamtantwortszeit unter 200 ms.

Soweit ein erster Überblick über die Datenflüsse. Im Abschnitt Sicherheit ist das Konzept der Absicherung deutlich genauer und ausführlicher beschrieben.

==Installation==

Du wirst bei der Installation zuerst auf der Kommandozeile auf Deinem Raspberry (o.ä.) unterwegs sein, anschließend im Webfrontend von FHEM, und zum Schluss auf der Alexa-Konsole im Web.

===node.js installieren===

Bei Jessy liegt NodeJS bereits in einer ausreichend aktuellen Version vor. Mit

<syntaxhighlight lang="bash" style="width:50%;">
sudo apt-get install nodejs npm
</syntaxhighlight>

kannst Du es installieren. Mit
<syntaxhighlight lang="bash" style="width:50%;">
node --version
</syntaxhighlight>

erfährst Du die aktuelle Version - wenn hier etwas mit "8" vorneweg erscheint, ist alles gut.
Ansonsten suche Dir bitte eine Anleitung im Web, wie Du NodeJS auf Deinem System auf einen aktuellen Stand bringen kannst.

=== Alexa-FHEM installieren ===

Nun installieren wir Alexa-fhem aus dem offiziellen Repository:

<syntaxhighlight lang="bash" style="width:50%;">
sudo npm install -g alexa-fhem
</syntaxhighlight>

Der Vorgang benötigt etwas Zeit.

=== Alexa-FHEM aktivieren ===

Wechsele jetzt in FHEM-Web!

Wichtig ist, dass das Alexa-Modul in der Version ab 14. Januar 2019 vorliegt. Dafür bitte einmal FHEM aktualisieren:
Speichern der Config nicht vergessen, und

<syntaxhighlight lang="bash" style="width:50%;">
update
shutdown restart
</syntaxhighlight>

Alles, was jetzt noch nötig ist, ist das Anlegen eines Alexa-Devices. Gib dafür in der FHEM-Web-Kommandozeile

<syntaxhighlight lang="bash" style="width:50%;">
define alexa alexa
</syntaxhighlight>

an. Nun läuft, während Du bereits das neu angelegte Alexa-Devices siehst, ein komplexer Prozess im Hintergrund:

* Falls noch kein SSH-Key für den Benutzer, unter dem FHEM läuft, existiert, wird einer generiert
* Es wird ein Secret-Key im Prozess generiert, dass den Server nicht verlässt, und der Skillanmeldung dient.
* Du wirst auf dem Server "va-fhem.fhem.de" des FHEM-Vereins mit dem SSH-Key angemeldet, und der Hash-Wert Deines Secret-Key dort abgelegt.

Und wenn Du diese Sätze gelesen hast, sollte inzwischen sich das Alexa-Device in FHEM-Web aktualisiert haben, und
ungefähr so aussehen:

[[Datei:Alexa-Device-2.png|800px]]

Neben dem Status für alexa-fhem und der Proxyverbindung ist wichtig, dass diese beiden Zeilen beim Reload aufgetaucht sind:

<syntaxhighlight lang="bash" style="width:90%;">
alexaFHEM.bearerToken crypt:...
alexaFHEM.skillRegKey crypt:...
</syntaxhighlight>

Ja, und diesen Schlüssel benötigst Du wirklich! Also am besten schon einmal mit

<syntaxhighlight lang="bash" style="width:90%;">
get <alexa> proxyKey
</syntaxhighlight>

in Klartext anzeigen lassen und in ein Editor-Fenster dauerhaft wegsichern.

Jetzt solltest Du Dein Alexa-Device nicht mehr löschen, denn das im Reading angezeigte "bearerToken" zu löschen bedeutet, dass die Software die Zugriffe von nicht mehr überprüfen kann und keine Kommandos mehr funktionieren. In diesem Fall hilft nur die Neuinstallation des Skills.

==== Fehler bei der Aktivierung ====

Während kompliziertere Fehlerfälle im Abschnitt "Mögliche Probleme und Lösungen" behandelt werden, hier häufige Fälle, warum die kryptischen Zeilen nicht auftauchen:

* Zuerst bitte einfach einmal die Seite neu laden.

===== 401: Authorization Required =====

Wenn Du FHEM-Web mit einem User/Passwort-Schutz versehen hast, wirst du folgende Fehlermeldung sehen:

<syntaxhighlight lang="bash" style="width:90%;">
alexaFHEM stopped; failed to connect to fhem: 401: Authorization Required
</syntaxhighlight>

In der Regel musst du die Angaben User/Passwort noch einmal explizit setzen. Im Attribute-Abschnitt "alexaFHEM-auth" auswählen, User/Passwort mit ":" getrennt angeben und "attr" anklicken. alexa-fhem wird automatisch neu gestartet. Hier das Ganze in der Text-Variante:

<syntaxhighlight lang="bash" style="width:90%;">
attr alexa alexaFHEM-auth user:pass
</syntaxhighlight>

===== Permission denied =====

Wenn du folgende Fehlermeldungen im Alexa Logfile siehst, wurde das Verzeichnis "/opt/fhem/.ssh/" von dir bei der Arbeit mit "root" oder "sudo" mit den falschen Berechtigungen versehen:

<syntaxhighlight lang="bash" style="width:90%;">
[2019-7-25 11:59:12] sshautoconf: aborted with ssh-keygen returned error - key_save_private: Permission denied
[2019-7-25 11:59:12] *** SSH: proxy configuration failed: ssh-keygen returned error - key_save_private: Permission denied
</syntaxhighlight>

Prüfen kannst du die Berechtigungen mit folgendem Befehl auf der Shell-Konsole:

<syntaxhighlight lang="bash" style="width:90%;">
ls -l /opt/fhem/.ssh
</syntaxhighlight>

Du solltest dann folgende Ausgabe erhalten:

<syntaxhighlight lang="bash" style="width:90%;">
insgesamt 12
-rw------- 1 fhem dialout 1675 Jul 12 13:10 id_rsa
-rw-r--r-- 1 fhem dialout 391 Jul 12 13:10 id_rsa.pub
-rw-r--r-- 1 fhem dialout 884 Jul 12 13:10 known_hosts
</syntaxhighlight>

Steht in der Ausgabe nicht "fhem dialout" (dein fhem User), sondern bspw. "root root", dann bspw. mit folgendem Befehl an deinen fhem User anpassen:

<syntaxhighlight lang="bash" style="width:90%;">
chown fhem:dialout /opt/fhem/.ssh
</syntaxhighlight>

Mit dem ersten Befehl "ls -l ..." kannst du dann nochmal prüfen, ob die Berechtigungen korrekt übernommen wurden.

===== weitere Prüfungen =====

Hast Du noch die Shell-Konsole offen? Dann prüfe bitte noch einmal auf der Konsole, ob nun zwei Prozesse laufen:

<syntaxhighlight lang="bash" style="width:50%;">
ps -ef | egrep '(alexa|ssh)'
</syntaxhighlight>

sollte Dir idealerweise so etwas anzeigen:
<syntaxhighlight lang="bash" style="width:90%;">
fhem 31322 1 99 13:56 ? 00:00:03 alexa
fhem 31332 31322 8 13:56 ? 00:00:00 /usr/bin/ssh -R 1234:127.0.0.1:<zufälliger port> -oServerAliveInterval=90 -p 58824 fhem-va.fhem.de
</syntaxhighlight>

"alexa" ist dabei der Node-JS-Prozess, der ssh-Prozess ist die aufgebaute Verbindung zum Vereinsserver.

Wenn Du diese Prozesse '''nicht''' siehst oder das Alexa-Device keinen Registrierungskey anzeigt, dann ist leider der Start nicht glatt verlaufen.

Im Logfile (über den link <code>Logfile</code> in der Detail-Ansicht über <code>set</Code>, oder über den Namen bei ''currentlogfile'' in den Internals) findest Du idealerweise selber Hinweise, wo es hakt, oder kannst im Forum nachfragen.

=== Geräte im FHEM-Webfrontend zuweisen ===
Um das Aha-Erlebnis zu vergrößern, ist jetzt ein guter Zeitpunkt, 1 oder besser mind. 2 Geräte für den Alexa-Dienst zuzuweisen. Von Haus aus wird keines Deiner FHEM-Geräte automatisch Alexa zugewiesen!

Wähle die Geräte aus, rufe sie auf und setze das Attribut "alexaName". Hierbei in Kürze nur der Hinweis:
* Keine Angst vor Leerzeichen und Umlauten, funktioniert.
* Große Angst vor Rechtschreibfehlern (Terrasse, Rollladen) oder komplizierten Wörtern "handgebastelte Martinslaterne im Kinderzimmer Iphigenie-Chantal".
* Das Attribut "alexaRoom" ist NUR FÜR DEN CUSTOM SKILL relevant. Ausnahme: structure und LightScene Devices, siehe: [[FHEM_Connector_f%C3%BCr_Amazon_Alexa#Was_geht_alles_.3F]].

Lade die Geräte neu in die Software, indem Du <code>set <alexa> restart</code> ausführst! 
 

'''Anmerkungen (weil oft gestellte Fragen im Forum) bzgl. Erkennung von Geräten:'''

* Wichtig ist, dass die Filtereinstellung in der alexa-fhem.cfg (zu finden unter "Edit Files") passt.
Also was dort eingetragen ist (Standard: alexaName=..* / also es ist ein alexaName vergeben) auch an den entsrpechenden Devices in fhem vorhanden ist.
Stimmt das schon nicht überein, kann alexa-fhem schon mal keine Devices von fhem abfragen/finden.
Ob der Filter entsprechend funktioniert kann man wie folgt testen: ''list Filtereinstellung'' beispiel mit Standardfilter: ''list alexaName=..*''

* Hat alexa-fhem per Filter Devices aus fhem "gefunden", geht es weiter mit der "Erkennung". Also um welches Device (Typ und "Fähigkeiten") handelt es sich. Dazu gilt folgendes:
** sind entsprechende Readings beim Device vorhanden (z.B. temperature, state mit on/off, ...) erkennt das alexa-fhem automatisch. Die Liste der automatisch erkannten Readings wächst ständig. Daher erst mal schauen ob das Device bereits entsprechend erkannt (typisiert) wurde. Das kann durch prüfen des alexa-fhem-Logs geschehen (NICHT fhem-log!).
** sind entsprechende "set-Befehle" erkennbar (oft auch durch Readings). Also ist beispielsweise (wie beim Dummy nötig) ein ''setList'' mit entsprechenden Einträgen vorhanden oder entsprechende Readings, z.B. desired-temp zum Stellen der Temperatur etc.
** wird das Device nicht richtig oder "unvollständig" erkannt helfen folgende Attribute:
*** genericDeviceType: hiermit kann alexa-fhem in die gewünschte Richtung "geschubbst" werden. Anmerkung: man kann nicht alles erzwingen, Readings bzw. set-Befehle müssen passen (oder per homebridgeMapping passend gemacht werden). Wenn ein genericDeviceType nicht per "Drop-Down" erscheint, dann kann er auch (wenn bekannt) einfach per WEB-cmd eingegeben werden: ''attr Devicename genericDeviceType media''
*** homebridgeMapping: hierdurch kann alexa-fhem bei der Erkennung von Zuständen und möglichen Einstellungen (also WAS kann das Device) unterstützt werden. Mittels homebridgeMapping können vorhandene Readings (Zustände) auf für alexa-fhem bekannte Zustände gemappt werden. Ebenso können damit Standard-fhem-Kommandos von alexa-fhem auf Device-spezifische gemappt werden. Beispiel: on/off auf Ein/Aus (falls das Device statt on/off eben ein Ein/Aus erwartet). Zum Beispiel: <syntaxhighlight lang="bash" style="width:50%;">
attr <thermostat> homebridgeMapping TargetTemperature=target::target,minValue=18,maxValue=25,minStep=0.5 CurrentTemperature=myTemp:temperature
</syntaxhighlight> [https://github.com/justme-1968/homebridge-fhem/blob/master/README.md weitere Beispiele]

'''Anmerkung bzgl. genericDeviceType und homebridgeMapping:''' 
* diese Attribute werden von verschiedenen "Sprachsteuerungsmodulen" in fhem verwendet (homebridge [dort wurde es "erfunden"], alexa-fhem, gassistant, ...). Daher ist nicht jedes Mapping für alle "Dienste" verwendbar. Ausprobieren schadet aber nicht.
* ebenso kann man mit diesen Attributen (homebridgeMapping wird gerne so "missbraucht") nichts erzwingen, was seitens Amazon/Alexa nicht unterstützt bzw. verstanden wird! D.h. zunächst ist zu prüfen, ob ein bestimmter (gewünschter) Sprachbefehl seitens Amazon/Alexa unterstützt wird! Aktuelles Beispiel (Stand Jan 2020): "Alexa, fahre den Rollo hoch/runter". Da ist Amazon/Alexa gerade dabei etwas zu tun. Bislang wird das nicht unterstützt, also ist das auch mit einem entsprechenden homebridgeMapping nicht zu erzwingen! Was unterstützt wird kann man bei Amazon nachlesen: [https://developer.amazon.com/es-ES/docs/alexa/device-apis/list-of-interfaces.html]

== Finale: Skill verknüpfen ==
Suche im WebFrontend oder der Alexa-App den Skill "FHEM Connector". Für nicht-Mac/iOS Anwerder empfiehlt das WebFrontend (https://alexa.amazon.de) statt die App, damit Du den Anmeldeschlüssel auch bequem kopieren kannst.

Wenn du noch nicht bei Amazon angemeldet bist, erwartet Amazon zunächst, dass Du Dich normal bei Amazon anmeldest.

Sobald Du "FHEM Connector" aktivierst, öffnet sich ein Browser-Tab mit folgender Maske: 
[[Datei:FHEMlazy_login.png|240px]]

Hier kopierst Du Deinen Anmeldeschlüssel (im Klartext!) hinein und klickst auf Check. Als glücklicher Mensch ist auf der folgenden Statusseite alles grün: 
[[Datei:FHEMlazy_check.png|240px]]

Im Einzelnen wird hier geprüft, ob Du per SSH verbunden bist (und auch Deine IP zur Sicherheit angezeigt), ob der Reverse-Tunnel steht, ob nodeJS erreichbar ist und wie viele Geräte Alexa gleich finden sollte (in meinem Fall 22).

Sollte etwas nicht grün sein und Du eine Idee zum Fixen haben, kannst Du mit "Retry" neue Versuche auslösen.

Ist alles okay, klicke rechts den Button "Activate Skill". Du springst damit wieder zurück zu Amazon, die Dir hoffentlich zur erfolgreichen Verknüpfung gratulieren.

Amazon möchte nun unmittelbar die Gerätesuche starten, und unter SmartHome-Geräte sollten diese nun auftauchen.

== Was geht alles ? ==

* Geräte, die sich ein- und ausschalten lassen:
** Automatisch: Müssen <code>set on</code> und <code>set off</code> Kommandos haben
** dummys müssen <code>setList</code> mit on und off haben
** Über <code>genericDeviceType</code> switch bzw. light kann bestimmt werden ob es in alexa als Schalter oder Licht behandelt wird.
** Wenn die Set-Kommandos im FHEM Device anders benannt sind: hombridgeMapping On:cmdOn=<ein>,cmdOff=<aus> setzen
** Kommandos:
***Alexa, schalte <name> ein/aus
***Alexa, Licht an/aus
***Alexa, schalte <gruppe> ein/aus

* Geräte, die eine Temperatur messen
** Automatisch: Es muss ein Reading temperature geben
** Über <code>genericDeviceType</code> thermometer
** Sonst: hombridgeMapping CurrentTemperature:reading=<reading>

* Geräte, deren Helligkeit sich ändern lässt
** Automatisch: wenn <code>dim</code> oder <code>pct</code> Kommandos erkannt werden
** Über <code>genericDeviceType</code> light
** Über homebridgeMapping: Wenn <code>helligkeit</code> das Reading für die aktuelle Helligkeit enthält und die Helligkeit mit <code>set <device> prozent xxx</code> gesetzt wird, sieht das homebridgeMapping wie folgt aus:
*** homebridgeMapping Brightness=helligkeit::prozent,minValue=0,maxValue=<maximalwert>

**Kommandos:
***Alexa, mache <name> heller/dunkler
***Alexa, Licht heller/dunkler

* Geräte, deren Farbe sich ändern lässt
** ...

* Geräte, deren Farbtemperatur sich ändern lässt
** ...

* Geräte, bei denen sich eine Lautstärke einstellen lässt
** ...

* Geräte, bei denen sich ein prozentualer Wert einstellen lässt
** Automatisch: wenn <code>dim</code> oder <code>pct</code> Kommandos erkannt werden
** ...

* elektrische Türschlösser
** <code>genericDeviceType</code>: lock
** hombridgeMapping mit LockCurrentState und LockTargetState

* Thermostate
** Über <code>genericDeviceType</code> thermostate
** ...

* structure Devices aus FHEM (ab alexa-fhem version 0.5.7)
** können mit <code>genericDeviceType</code> scene als Szene eingebunden werden
** über <code>alexaRoom</code> kann der name um einen Ort ergänzt werden
** Szenen aus einer structure lassen sich ein- und ausschalten
** Wichtig:
*** Ein Skill darf nur 12 Szenen automatisch erkennen und einbinden.

* LightScene Devices aus FHEM (ab alexa-fhem version 0.5.8)
** können mit <code>genericDeviceType</code> scene als Szenen eingebunden werden
** über <code>alexaRoom</code> kann der name um einen Ort ergänzt werden
** Szenen aus einer LightScene lassen sich nur einschalten
** Wichtig:
*** Ein Skill darf nur 12 Szenen automatisch erkennen und einbinden.

* Geräte, deren Kanal sich umschalten lässt (ab alexa-fhem version 0.5.13)
** Über <code>genericDeviceType</code> media
** hombridgeMapping ChannelController:reading=<reading>,cmd=<cmd>
** Erlaubte Werte siehe hier: https://developer.amazon.com/de/docs/device-apis/alexa-channelcontroller.html#changechannel
** ...

* Geräte, deren Playback status sich schalten lässt (ab alexa-fhem version 0.5.13)
** Über <code>genericDeviceType</code> media
** hombridgeMapping PlaybackController:playback,values=Play;Pause;Stop;Previous;Next
** Erlaubte Werte siehe hier: https://developer.amazon.com/de/docs/device-apis/alexa-playbackcontroller.html#discovery
** ...

* Geräte, deren Eingang sich umschalten lässt (ab alexa-fhem version 0.5.13)
** Über <code>genericDeviceType</code> media
** hombridgeMapping InputController:reading=<reading>,cmd=<cmd>,values=HDMI+1;HDMI+2;XBOX
** Erlaubte Werte siehe hier: https://developer.amazon.com/de/docs/device-apis/alexa-property-schemas.html#input
** ...

* Kontaktsensoren (ab alexa-fhem version 0.5.15)
** Über <code>genericDeviceType</code> contact
** hombridgeMapping ContactSensorState:reading=<reading> oder CurrentDoorState:reading=<reading>
** Die Anzeige in der Alexa-App funktioniert sofort, die Abfrage per Sprache erst ab Version 0.5.27.

* Geräte, deren Lautstärke sich ändern lässt (ab alexa-fhem version 0.5.24)
** Über <code>genericDeviceType</code> speaker
** Automatisch: es muss ein Reading <code>volume</code> und/oder <code>mute</code> geben
** hombridgeMapping Volume:reading=<reading>,cmd=<cmd> Mute:reading=<reading>,cmd=<cmd>
** ...

* Geräte, die sich ein- (und optional) ausschalten lassen als Szene (ab alexa-fhem version 0.5.26)
** Über <code>genericDeviceType</code> scene
** Automatisch: Müssen <code>set on</code> und <code>set off</code> Kommandos haben
** hombridgeMapping On:reading=<reading>,cmdOn=<cmd>[,cmdOff=<cmd>]
** Hinweis: Fehlende Kommandos lassen sich mit cmdalias erzeugen
** Wichtig:
*** Ein Skill darf nur 12 Szenen automatisch erkennen und einbinden.

Es werden noch einige andere häufig verwendete Geräte (Homematic, hue,...) automatisch erkannt.

to be continued ...

In der [https://developer.amazon.com/docs/device-apis/list-of-interfaces.html List of Capability Interfaces] bei Amazon kann man sehen, welche Möglichkeiten das Smart Home Skill API aktuell in einzelnen Ländern bietet. Leider ohne die jeweiligen landessprachlichen Kommandos.

== Mögliche Probleme und Lösungen ==

Es kann vorkommen, dass Geräte zwar korrekt erkannt werden, aber das durch Alexa erkannte Kommando nicht richtig umgesetzt wird (Beispiel - mittlerweile behoben: {{Link2Forum|Topic=96766}}). Neben dem FHEM-Log gibt es noch das Logfile, welches von alexa-fhem angelegt wird.

=== Fehlersuche über die FHEM-Oberfläche ===

* alexa-fhem Logfile anschauen (Detail-Ansicht des <alexa>-Device aufrufen, klick auf '''Logfile''' oben)
* alexa-fhem im Debug-Modus aufrufen:
** -D zum alexaFHEM-params attribut hinzufügen
** Alexa-Befehl auslösen
** -D aus dem alexaFHEM-params attribut entfernen
* Die notwendigen Informationen finden sich in dem alexa-Logfile (siehe oben)

=== Fehlersuche über Kommandozeile (lies: Shell) + FHEM-Oberfläche ===

:* set <alexa> stop (FHEM-Oberfläche)
:* Auf der Kommandozeile <code>alexa-fhem -D -c /opt/fhem/alexa-fhem.cfg > debug.log</code> starten (dadurch wird die Datei debug.log erzeugt im aktuellen Verzeichnis)
:* Alexa-Befehl auslösen
:* alexa-fhem auf der Kommandozeile wieder stoppen (CTRL-C)
:* set <alexa> start (FHEM-Oberfläche)

Die Datei debug.log sollte Hinweise enthalten, wie das Problem zu lösen ist oder Dich zumindest in die richtige Richtung schieben.

Im Beispiel aus dem Forum fand sich in dem Logfile der Hinweis darauf, dass das Device mit falschen min/max-Werten unterwegs war.

=== Registrierungskey vergessen, Registrierung zurücksetzen ===

Auf der Kommandoshell:

<syntaxhighlight lang="bash" style="width:90%;">
pi@raspberrypi:~# sudo -u fhem ssh -p 58824 fhem-va.fhem.de status
Registered.
Registered on 2019-01-13T15:38:13Z.
</syntaxhighlight>

heisst, das der Vereinsserver eigentlich alles hat, was er will. Es wird kein neuer Schlüssel generiert.
Wenn Du die Situation zurücksetzen möchtest, wäre die hässliche Methode, Deinen SSH-Key zu löschen. Eleganter ist, die Registrierung auf Vereinsseite zu löschen:

<syntaxhighlight lang="bash" style="width:90%;">
pi@raspberrypi:~# sudo -u fhem ssh -p 58824 fhem-va.fhem.de unregister
Your registration has been removed
</syntaxhighlight>

löscht Deinen Schlüssel mitsamt allen dort gespeicherten Daten auf Vereinsseite. Bei Restart von alexa-fhem in FHEM-WEB wird jetzt ein neuer Registrierungskey angefordert.

== Sicherheitskonzept und Secrets ==

Um diesen Abschnitt zu verstehen, solltest Du den Abschnitt "Arbeitsweise" im Kopf haben. Einerseits ist Dir vermutlich einleuchtend, dass ein Server, der per SSH rückwärts nur ausgewählte Kommandos in den Tunnel, den Du aufgebaut hast, leitet, "irgendwie sicherer" ist. Andererseits möchte man nicht blind vertrauen.

=== SSH ===
==== SSH - macht das nichts Gefährliches? ====
SSH ist ein Veteran des Internet und entstand, um sich sicher (verschlüsselt) und schnell auf Servern einzuloggen. Schon früh wurde dabei der sogenannte "Reverse-Tunnel" implementiert: Also der vom Client (Deinem Rechner) geäußerte Wunsch: "Bitte leite mir Requests, die bei Dir, Server, auf Port xy eingehen, an meinen lokalen Port yz weiter.". Dieses Verfahren implementiert der Reverseproxy, wobei tatsächlich auf dem Server für Dich kein echter Port geöffnet wird.

Wie Dir ggf. sicher der Unix-Guru Deines Vertrauens bestätigen wird: Die Kombination
<syntaxhighlight lang="bash" style="width:50%;">
ssh -R 1234:localhost:<zufälliger port> zielserver
</syntaxhighlight>
erlaubt keine Ausführung von Shell-Kommandos auf Deinem Server, sondern einzig, dass vom SSH-Programm Verbindungen zu einem lokalen Port auf Deinem Server auf dem alexa-fhem lauscht aufgebaut werden. Du kannst also z.B. mit einem
<syntaxhighlight lang="bash" style="width:50%;">
sudo /usr/sbin/tcpdump -X -s 0 -i lo port <zufälliger port>
</syntaxhighlight>
vollständig überwachen (oder ggf. permanent aufzeichen), was auf Deinem Server von außen gesteuert passiert.

==== Wie wird bei SSH verschlüsselt? ====
Im Prinzip wie im Web auf SSL-Seiten, teils mit den gleichen Verschlüsselungsverfahren. Allerdings arbeitet SSH eher wie das im Web recht seltene Verfahren: Bei jeder Verbindung übermitteln sowohl Server wie auch Client den öffentlichen Teil ihres Schlüssels. Anders als im Web wird der Schlüssel aber nicht von einer öffentlichen Zertifizierungsstelle wie "LetsEncrypt" unterschrieben. Stattdessen entscheiden Server wie Client beim ersten Verbindungsaufbau typischerweise per manueller Frage: "Willst Du jetzt und künftig diesem Schlüssel vertrauen?" Bei der Installation wird diese Frage für Deine Seite bejaht, und fortan wird der öffentliche Schlüssel des FHEM-Servers auf Deinem Rechner gespeichert. Ab da bist Du z.B. davor sicher, dass jemand den DNS-Eintrag verbiegt oder sich in den Datenfluss Deines Providers einhängt: Ein geänderter Serverschlüssel würde bemerkt werden.
 
Soweit klar? Aus Deinem öffentlichen Schlüssel wiederum leitet der Server her: "Das ist definitiv wieder derjenige, der sich damals "registriert" hat". Und an dieser Stelle kann ich auch den ersten Teil des 3-teiligen Registrierungskeys erläutern: Die typischerweise 6-stellige Hex-Zahl am Anfang ist der Java-Hashcode Deines öffentlichen Schlüssel. Sie ist damit sozusagen Deine aus Deinem öffentlichen Schlüssel abgeleitete Benutzer-ID.

=== Die Rolle der Secrets ===
Wenn jetzt klar ist, dass die Verbindung zum Vereinsserver sicher und vertauschungsfrei funktioniert, bleiben noch 2 Probleme zu lösen:
1) Im Web bei der Skill-Aktivierung musst Du beweisen, dass Du der Mensch am Browser bist, dem der SSH-Tunnel von IP xy mit dem öffentlichen Schlüssel X gehört. Bei der automatischen Registrierung werden lokal auf Deinem Rechner zwei 64-Bit-Secrets generiert:
* Das Anmelde-Secret
* Das Bearer-Token
Beim Anmelden des SSH-Keys auf dem öffentlichen Server wird nun der Hashwert des ersten Secrets übertragen und dort in Verbindung mit Deinem öffentlichen Schlüssel gespeichert. Ein Hashwert bedeutet, dass (sofern das Verfahren, hier SHA256, funktioniert), niemand aus dem Hash das Secret zurückrechnen kann. Ein Datenbankklau auf dem Server gefährdet also nicht die Sicherheit Deines Passwortes.

Wenn Du nun beim Skill-Aktivieren den Registrierungskey eingibst, dann "sieht" der Server zum ersten Mal Dein ausgewürfeltes Secret, vergleicht es mit dem Hashwert und wird es anschließend wieder umgehend vergessen. Anhand des Hashwertes kann der Server aber entscheiden, dass Du der legitime Nutzer zum öffentlichen Schlüssel XY bist.

2) Das zweite Problem ist: Wie soll Amazon "beweisen", dass sie der legitime Aufrufer sind? Amazon erhält binnen wenigen Sekunden nach dem Klick auf "Activate Skill" den dritten Teil des Registrierungskeys als sogenanntes Bearer-Token. Zwar läuft er durch den Registrierungsserver, er wird dort, auf dem Registrierungs/Vereinsserver aber nicht gespeichert. Das Bearer-Token wird von Amazon bei allen Requests zu Deinem Server mitgesendet. Da es am Anfang zusätzlich Deine "User-ID" enthält, weiß der Vereinsserver, zu welchem SSH-Tunnel der Request zu senden ist. Aber lokal auf Deinem Rechner wird ausgewertet, ob das Token "stimmt".

== alexa-fhem Updaten ==

'''Updaten einer "Connector" Installation:'''
* alexa-fhem über FHEM anhalten (Name des Alexa-Device: alexa):
:<syntaxhighlight lang="perl" style="width:50%;">set alexa stop</syntaxhighlight>

*Auf der Konsole wie anfangs bei der Installation:
:<syntaxhighlight lang="bash" style="width:50%;">sudo npm update -g alexa-fhem</syntaxhighlight>

:Manchmal hat npm Probleme mit einem Update. Dann einfach die aktuelle Version noch mal drüber Installieren:

:<syntaxhighlight lang="bash" style="width:50%;">sudo npm install -g alexa-fhem</syntaxhighlight>

*alexa-fhem über FHEM wieder starten:
:<syntaxhighlight lang="perl" style="width:50%;">set alexa start</syntaxhighlight>

'''"Upgraden von einer "Nicht-Connector" Installation (z.B. manuelle Installation per pm-Download):'''
* Daten der aktuellen Installation sichern (v.a. config.json / man weiß ja nie)
* Autostart der aktuellen alexa-fhem Installation deaktivieren:
** Bei initd: Service deaktivieren mittels: . Startscript unter /etc/init.d/ löschen.
** Bei systemd: Service deaktivieren mittels: . Startscript unter /etc/systemd/system/ löschen.
* ALLE vorhandenen alexa-fhem Daten LÖSCHEN! Bleiben Dinge zurück und wird dann laut Connector installiert kann es zu Problemen kommen!
* (reboot)
* Installation von alexa-fhem laut Anleitung (Beginn dieses Wiki)
* Falls eigene Dinge von früher genutzt werden wollen/sollen (z.B. Custom Skill), dann die entsprechenden Einträge aus der gesicherten config.json in die neu angelegte alexa-fhem.cfg (zu finden unter "Edit files") übernehmen.
* Werden keine eigenen Dinge verwendet, dann kann der Port (Standard: 3000) geschlossen werden und auch die Daten unter Amazon-Developer können gelöscht werden.

== Bug- und Wunschliste ==
* Ist beim Start keine Internetverbindung vorhanden, erfolgt kein Retry -- alexa-fhem muss restartet werden (ssh_autoconfig wertet keine temporären Fehler aus)

==Weitergehende Informationen==
*[[Alexa und Mappings]]
*[[Alexa Tipps und Kniffe]]
*[[FHEM Connector for Amazon Alexa]]
[[Kategorie:HOWTOS]]
[[Kategorie:Sprachsteuerung]]

FHEM Connector für Amazon Alexa

2020-01-08T18:10:52Z

MadMax-FHEM: /* Geräte im FHEM-Webfrontend zuweisen */ Typo

{{Baustelle}}
'''Alexa FHEMlazy''' war historisch ein Fork des Original [[Alexa-Fhem|alexa-fhem]], der im Januar 2019 mit dem Original zusammengeführt wurde und nun als '''FHEM Connector''' verfügbar ist.

Er ermöglicht innerhalb von Minuten die Verknüpfung von FHEM mit einem Amazon Echo Gerät. Auch Geräte anderer Hersteller mit verbauten Mikrofonen und Alexa-Sprachassistenten-Unterstützung sollten problemlos funktionieren. Für folgende Geräte ist dies bspw. der Fall (Falls Ihr andere/weitere Gerätemodelle bzw. Hersteller in Verwendung habt, bitte hier pflegen):

* SONOS Beam und SONOS One

Gegenüber dem klassischen Ansatz ergeben sich Einschränkungen, so läuft die Software normalerweise unter dem gleichen Benutzer wie FHEM auf dem gleichen Server, und es wird z.Zt. nur der Smarthome-Skill unterstützt (die Variante, bei der die Möglichkeiten der Interaktion von Amazon festgelegt wurden).
Dafür ist weder ein Developer-Account bei Amazon, eigene Lambda- und Skillfunktionen, noch das Öffnen eines eingehenden Ports aus dem Internet nötig.
* Die Software integriert einen Installer, der die Erstkonfiguration und Anmeldung übernimmt
* Die Kommunikation zur Software auf dem heimischen Rechner und dann zu FHEM verläuft über SSH und einen vom FHEM-Verein gehosteten Server
* Funktioniert mit IPv4, IPv6, echtem Dual Stack und DS-Lite
* Als Skill bei Amazon wird der Skill "FHEM Connector" verwendet.

Der Thread im Forum zur Software ist hier: {{Link2Forum|Topic=94817}}.

{{Infobox Modul
|ModPurpose=Einfache Anbindung von FHEM an Amazon Assistent Alexa
|ModType=h
|ModCmdRef=alexa
|ModTechName=39_alexa.pm / alexa-fhem
|ModForumArea=Frontends/Sprachsteuerung
|ModOwner=gvzdus, André/ justme1968 ({{Link2FU|430|Forum}} / [[Benutzer Diskussion:Justme|Wiki]])
}}

==Einführung==

===Arbeitsweise und Datenfluss===
Vorläufig ist alexa-fhem im "FHEM Connector-Modus" ein reiner [https://developer.amazon.com/de/docs/smarthome/understand-the-smart-home-skill-api.html SmartHome-Skill].
SmartHome-Skills erhalten weder die Sprachdaten selber noch das, was Amazon in Textform verstanden hat, sondern vielmehr extrahiert Amazon aus dem verstandenen Text Anweisungen und Abfragen für Geräte, die dann an den Skill übermittelt werden. Charmant ist dabei, dass unmittelbar gefragt werden kann "Alexa, wie ist die Temperatur im Wohnzimmer?", während andere Skills zunächst explizit angesprochen werden müssen ("Alexa, frage FHEM nach der Temperatur im Wohnzimmer"). Außerdem kann der Nutzer mehrere Smarthome-Skills installieren, und die Geräte werden zu einer Gesamtmenge zusammengefasst.

Gehen wir den Datenfluss bei der konkreten Frage "Wie ist die Temperatur im Wohnzimmer?" durch:
* Alexa hat bei der Skillinstallation gelernt, dass "FHEM Connector" bei Dir einen Thermostaten im Raum Wohnzimmer kennt. Dadurch wird bei der Sprachanalyse von "Alexa Voice Service" in der Cloud erkannt, dass eine Abfrage an "FHEM Connector" erfolgversprechend ist.
* Zunächst wird die zentrale "Lambda-Funktion" von "FHEM Connector" aufgerufen. Die Funktion leitet aber im Kern nur den Request unverändert an den vom Verein bereitgestellten Server weiter. Im Request enthalten ist ein Token, das sogenannte "Bearer-Token".
* Der "Vereinsserver" prüft anhand dieses Tokens, ob es überhaupt bekannt ist, und zu welchem Nutzer es gehört. Ist dieser Nutzer verbunden, wird der Request wiederum quasi unverändert an den Nutzer weitergeleitet.
* Diese Weiterleitung passiert über einen sogenannten SSH-Reverse-Tunnel, der von Deiner Seite und der Software auf dem FHEM-Tunnel automatisch aufgebaut wird.
* Auf Deiner Seite läuft die eigentliche Software, und zwar unter nodeJS. nodeJS ist ein Javascript ausführender Miniserver, der lokal auf Port 3000 auf Requests "lauscht". In der Original-Version [[Alexa-Fhem|Alexa FHEM]] kommen die Requests aus dem Internet (hoffentlich von der eigenen Lambda-Funktion), hier bei "FHEM Connector" kommen sie ausschließlich aus dem SSH-Tunnel von lokal.
* Die Software validiert nun diesen Request anhand des Bearer-Tokens. Konkret wird dabei das bei der Installation generierte Token, dass bei der Skill-Aktivierung an Amazon übertragen wurde, mit dem lokal gespeicherten Wert verglichen. Stimmt das Token, wird der Befehl verarbeitet, üblicherweise wird hierbei ein Aufruf an die Webschnittstelle von FHEM abgesetzt.
* FHEM führt den Befehl aus

Hört sich langsam und kompliziert an? Kompliziert: Okay. Langsam eher nicht, in etlichen Fällen liegt die Gesamtantwortszeit unter 200 ms.

Soweit ein erster Überblick über die Datenflüsse. Im Abschnitt Sicherheit ist das Konzept der Absicherung deutlich genauer und ausführlicher beschrieben.

==Installation==

Du wirst bei der Installation zuerst auf der Kommandozeile auf Deinem Raspberry (o.ä.) unterwegs sein, anschließend im Webfrontend von FHEM, und zum Schluss auf der Alexa-Konsole im Web.

===node.js installieren===

Bei Jessy liegt NodeJS bereits in einer ausreichend aktuellen Version vor. Mit

<syntaxhighlight lang="bash" style="width:50%;">
sudo apt-get install nodejs npm
</syntaxhighlight>

kannst Du es installieren. Mit
<syntaxhighlight lang="bash" style="width:50%;">
node --version
</syntaxhighlight>

erfährst Du die aktuelle Version - wenn hier etwas mit "8" vorneweg erscheint, ist alles gut.
Ansonsten suche Dir bitte eine Anleitung im Web, wie Du NodeJS auf Deinem System auf einen aktuellen Stand bringen kannst.

=== Alexa-FHEM installieren ===

Nun installieren wir Alexa-fhem aus dem offiziellen Repository:

<syntaxhighlight lang="bash" style="width:50%;">
sudo npm install -g alexa-fhem
</syntaxhighlight>

Der Vorgang benötigt etwas Zeit.

=== Alexa-FHEM aktivieren ===

Wechsele jetzt in FHEM-Web!

Wichtig ist, dass das Alexa-Modul in der Version ab 14. Januar 2019 vorliegt. Dafür bitte einmal FHEM aktualisieren:
Speichern der Config nicht vergessen, und

<syntaxhighlight lang="bash" style="width:50%;">
update
shutdown restart
</syntaxhighlight>

Alles, was jetzt noch nötig ist, ist das Anlegen eines Alexa-Devices. Gib dafür in der FHEM-Web-Kommandozeile

<syntaxhighlight lang="bash" style="width:50%;">
define alexa alexa
</syntaxhighlight>

an. Nun läuft, während Du bereits das neu angelegte Alexa-Devices siehst, ein komplexer Prozess im Hintergrund:

* Falls noch kein SSH-Key für den Benutzer, unter dem FHEM läuft, existiert, wird einer generiert
* Es wird ein Secret-Key im Prozess generiert, dass den Server nicht verlässt, und der Skillanmeldung dient.
* Du wirst auf dem Server "va-fhem.fhem.de" des FHEM-Vereins mit dem SSH-Key angemeldet, und der Hash-Wert Deines Secret-Key dort abgelegt.

Und wenn Du diese Sätze gelesen hast, sollte inzwischen sich das Alexa-Device in FHEM-Web aktualisiert haben, und
ungefähr so aussehen:

[[Datei:Alexa-Device-2.png|800px]]

Neben dem Status für alexa-fhem und der Proxyverbindung ist wichtig, dass diese beiden Zeilen beim Reload aufgetaucht sind:

<syntaxhighlight lang="bash" style="width:90%;">
alexaFHEM.bearerToken crypt:...
alexaFHEM.skillRegKey crypt:...
</syntaxhighlight>

Ja, und diesen Schlüssel benötigst Du wirklich! Also am besten schon einmal mit

<syntaxhighlight lang="bash" style="width:90%;">
get <alexa> proxyKey
</syntaxhighlight>

in Klartext anzeigen lassen und in ein Editor-Fenster dauerhaft wegsichern.

Jetzt solltest Du Dein Alexa-Device nicht mehr löschen, denn das im Reading angezeigte "bearerToken" zu löschen bedeutet, dass die Software die Zugriffe von nicht mehr überprüfen kann und keine Kommandos mehr funktionieren. In diesem Fall hilft nur die Neuinstallation des Skills.

==== Fehler bei der Aktivierung ====

Während kompliziertere Fehlerfälle im Abschnitt "Mögliche Probleme und Lösungen" behandelt werden, hier häufige Fälle, warum die kryptischen Zeilen nicht auftauchen:

* Zuerst bitte einfach einmal die Seite neu laden.

===== 401: Authorization Required =====

Wenn Du FHEM-Web mit einem User/Passwort-Schutz versehen hast, wirst du folgende Fehlermeldung sehen:

<syntaxhighlight lang="bash" style="width:90%;">
alexaFHEM stopped; failed to connect to fhem: 401: Authorization Required
</syntaxhighlight>

In der Regel musst du die Angaben User/Passwort noch einmal explizit setzen. Im Attribute-Abschnitt "alexaFHEM-auth" auswählen, User/Passwort mit ":" getrennt angeben und "attr" anklicken. alexa-fhem wird automatisch neu gestartet. Hier das Ganze in der Text-Variante:

<syntaxhighlight lang="bash" style="width:90%;">
attr alexa alexaFHEM-auth user:pass
</syntaxhighlight>

===== Permission denied =====

Wenn du folgende Fehlermeldungen im Alexa Logfile siehst, wurde das Verzeichnis "/opt/fhem/.ssh/" von dir bei der Arbeit mit "root" oder "sudo" mit den falschen Berechtigungen versehen:

<syntaxhighlight lang="bash" style="width:90%;">
[2019-7-25 11:59:12] sshautoconf: aborted with ssh-keygen returned error - key_save_private: Permission denied
[2019-7-25 11:59:12] *** SSH: proxy configuration failed: ssh-keygen returned error - key_save_private: Permission denied
</syntaxhighlight>

Prüfen kannst du die Berechtigungen mit folgendem Befehl auf der Shell-Konsole:

<syntaxhighlight lang="bash" style="width:90%;">
ls -l /opt/fhem/.ssh
</syntaxhighlight>

Du solltest dann folgende Ausgabe erhalten:

<syntaxhighlight lang="bash" style="width:90%;">
insgesamt 12
-rw------- 1 fhem dialout 1675 Jul 12 13:10 id_rsa
-rw-r--r-- 1 fhem dialout 391 Jul 12 13:10 id_rsa.pub
-rw-r--r-- 1 fhem dialout 884 Jul 12 13:10 known_hosts
</syntaxhighlight>

Steht in der Ausgabe nicht "fhem dialout" (dein fhem User), sondern bspw. "root root", dann bspw. mit folgendem Befehl an deinen fhem User anpassen:

<syntaxhighlight lang="bash" style="width:90%;">
chown fhem:dialout /opt/fhem/.ssh
</syntaxhighlight>

Mit dem ersten Befehl "ls -l ..." kannst du dann nochmal prüfen, ob die Berechtigungen korrekt übernommen wurden.

===== weitere Prüfungen =====

Hast Du noch die Shell-Konsole offen? Dann prüfe bitte noch einmal auf der Konsole, ob nun zwei Prozesse laufen:

<syntaxhighlight lang="bash" style="width:50%;">
ps -ef | egrep '(alexa|ssh)'
</syntaxhighlight>

sollte Dir idealerweise so etwas anzeigen:
<syntaxhighlight lang="bash" style="width:90%;">
fhem 31322 1 99 13:56 ? 00:00:03 alexa
fhem 31332 31322 8 13:56 ? 00:00:00 /usr/bin/ssh -R 1234:127.0.0.1:<zufälliger port> -oServerAliveInterval=90 -p 58824 fhem-va.fhem.de
</syntaxhighlight>

"alexa" ist dabei der Node-JS-Prozess, der ssh-Prozess ist die aufgebaute Verbindung zum Vereinsserver.

Wenn Du diese Prozesse '''nicht''' siehst oder das Alexa-Device keinen Registrierungskey anzeigt, dann ist leider der Start nicht glatt verlaufen.

Im Logfile (über den link <code>Logfile</code> in der Detail-Ansicht über <code>set</Code>, oder über den Namen bei ''currentlogfile'' in den Internals) findest Du idealerweise selber Hinweise, wo es hakt, oder kannst im Forum nachfragen.

=== Geräte im FHEM-Webfrontend zuweisen ===
Um das Aha-Erlebnis zu vergrößern, ist jetzt ein guter Zeitpunkt, 1 oder besser mind. 2 Geräte für den Alexa-Dienst zuzuweisen. Von Haus aus wird keines Deiner FHEM-Geräte automatisch Alexa zugewiesen!

Wähle die Geräte aus, rufe sie auf und setze das Attribut "alexaName". Hierbei in Kürze nur der Hinweis:
* Keine Angst vor Leerzeichen und Umlauten, funktioniert.
* Große Angst vor Rechtschreibfehlern (Terrasse, Rollladen) oder komplizierten Wörtern "handgebastelte Martinslaterne im Kinderzimmer Iphigenie-Chantal".
* Das Attribut "alexaRoom" ist NUR FÜR DEN CUSTOM SKILL relevant. Ausnahme: structure und LightScene Devices, siehe: [[FHEM_Connector_f%C3%BCr_Amazon_Alexa#Was_geht_alles_.3F]].

Lade die Geräte neu in die Software, indem Du <code>set <alexa> restart</code> ausführst! 
 

'''Anmerkungen (weil oft gestellte Fragen im Forum) bzgl. Erkennung von Geräten:'''

* Wichtig ist, dass die Filtereinstellung in der alexa-fhem.cfg (zu finden unter "Edit Files") passt.
Also was dort eingetragen ist (Standard: alexaName=..* / also es ist ein alexaName vergeben) auch an den entsrpechenden Devices in fhem vorhanden ist.
Stimmt das schon nicht überein, kann alexa-fhem schon mal keine Devices von fhem abfragen/finden.
Ob der Filter entsprechend funktioniert kann man wie folgt testen: ''list Filtereinstellung'' beispiel mit Standardfilter: ''list alexaName=..*''

* Hat alexa-fhem per Filter Devices aus fhem "gefunden", geht es weiter mit der "Erkennung". Also um welches Device (Typ und "Fähigkeiten") handelt es sich. Dazu gilt folgendes:
** sind entsprechende Readings beim Device vorhanden (z.B. temperature, state mit on/off, ...) erkennt das alexa-fhem automatisch. Die Liste der automatisch erkannten Readings wächst ständig. Daher erst mal schauen ob das Device bereits entsprechend erkannt (typisiert) wurde. Das kann durch prüfen des alexa-fhem-Logs geschehen (NICHT fhem-log!).
** sind entsprechende "set-Befehle" erkennbar (oft auch durch Readings). Also ist beispielsweise (wie beim Dummy nötig) ein ''setList'' mit entsprechenden Einträgen vorhanden oder entsprechende Readings, z.B. desired-temp zum Stellen der Temperatur etc.
** wird das Device nicht richtig oder "unvollständig" erkannt helfen folgende Attribute:
*** genericDeviceType: hiermit kann alexa-fhem in die gewünschte Richtung "geschubbst" werden. Anmerkung: man kann nicht alles erzwingen, Readings bzw. set-Befehle müssen passen (oder per homebridgeMapping passend gemacht werden). Wenn ein genericDeviceType nicht per "Drop-Down" erscheint, dann kann er auch (wenn bekannt) einfach per WEB-cmd eingegeben werden: ''attr Devicename genericDeviceType media''
*** homebridgeMapping: hierdurch kann alexa-fhem bei der Erkennung von Zuständen und möglichen Einstellungen (also WAS kann das Device) unterstützt werden. Mittels homebridgeMapping können vorhandene Readings (Zustände) auf für alexa-fhem bekannte Zustände gemappt werden. Ebenso können damit Standard-fhem-Kommandos von alexa-fhem auf Device-spezifische gemappt werden. Beispiel: on/off auf Ein/Aus (falls das Device statt on/off eben ein Ein/Aus erwartet). Zum Beispiel: <syntaxhighlight lang="bash" style="width:50%;">
attr <thermostat> homebridgeMapping TargetTemperature=target::target,minValue=18,maxValue=25,minStep=0.5 CurrentTemperature=myTemp:temperature
</syntaxhighlight> [https://github.com/justme-1968/homebridge-fhem/blob/master/README.md weitere Beispiele]

'''Anmerkung bzgl. genericDeviceType und homebridgeMapping:''' 
* diese Attribute werden von verschiedenen "Sprachsteuerungsmodulen" in fhem verwendet (homebridge [dort wurde es "erfunden"], alexa-fhem, gassistant, ...). Daher ist nicht jedes Mapping für alle "Dienste" verwendbar. Ausprobieren schadet aber nicht.
* ebenso kann man mit diesen Attributen (homebridgeMapping wird gerne so "missbraucht") nichts erzwingen, was seitens Amazon/Alexa nicht unterstützt bzw. verstanden wird! D.h. zunächst ist zu prüfen, ob ein bestimmter (gewünschter) Sprachbefehl seitens Amazon/Alexa unterstützt wird! Aktuelles Beispiel (Stand Jan 2020): "Alexa, fahre den Rollo hoch/runter". Da ist Amazon/Alexa gerade dabei etwas zu tun. Bislang wird das nicht unterstützt, also ist das auch mit einem entsprechenden homebridgeMapping nicht zu erzwingen! Was unterstützt wird kann man bei Amazon nachlesen: [https://developer.amazon.com/es-ES/docs/alexa/device-apis/list-of-interfaces.html]

== Finale: Skill verknüpfen ==
Suche im WebFrontend oder der Alexa-App den Skill "FHEM Connector". Für nicht-Mac/iOS Anwerder empfiehlt das WebFrontend (https://alexa.amazon.de) statt die App, damit Du den Anmeldeschlüssel auch bequem kopieren kannst.

Wenn du noch nicht bei Amazon angemeldet bist, erwartet Amazon zunächst, dass Du Dich normal bei Amazon anmeldest.

Sobald Du "FHEM Connector" aktivierst, öffnet sich ein Browser-Tab mit folgender Maske: 
[[Datei:FHEMlazy_login.png|240px]]

Hier kopierst Du Deinen Anmeldeschlüssel (im Klartext!) hinein und klickst auf Check. Als glücklicher Mensch ist auf der folgenden Statusseite alles grün: 
[[Datei:FHEMlazy_check.png|240px]]

Im Einzelnen wird hier geprüft, ob Du per SSH verbunden bist (und auch Deine IP zur Sicherheit angezeigt), ob der Reverse-Tunnel steht, ob nodeJS erreichbar ist und wie viele Geräte Alexa gleich finden sollte (in meinem Fall 22).

Sollte etwas nicht grün sein und Du eine Idee zum Fixen haben, kannst Du mit "Retry" neue Versuche auslösen.

Ist alles okay, klicke rechts den Button "Activate Skill". Du springst damit wieder zurück zu Amazon, die Dir hoffentlich zur erfolgreichen Verknüpfung gratulieren.

Amazon möchte nun unmittelbar die Gerätesuche starten, und unter SmartHome-Geräte sollten diese nun auftauchen.

== Was geht alles ? ==

* Geräte, die sich ein- und ausschalten lassen:
** Automatisch: Müssen <code>set on</code> und <code>set off</code> Kommandos haben
** dummys müssen <code>setList</code> mit on und off haben
** Über <code>genericDeviceType</code> switch bzw. light kann bestimmt werden ob es in alexa als Schalter oder Licht behandelt wird.
** Wenn die Set-Kommandos im FHEM Device anders benannt sind: hombridgeMapping On:cmdOn=<ein>,cmdOff=<aus> setzen
** Kommandos:
***Alexa, schalte <name> ein/aus
***Alexa, Licht an/aus
***Alexa, schalte <gruppe> ein/aus

* Geräte, die eine Temperatur messen
** Automatisch: Es muss ein Reading temperature geben
** Über <code>genericDeviceType</code> thermometer
** Sonst: hombridgeMapping CurrentTemperature:reading=<reading>

* Geräte, deren Helligkeit sich ändern lässt
** Automatisch: wenn <code>dim</code> oder <code>pct</code> Kommandos erkannt werden
** Über <code>genericDeviceType</code> light
** Über homebridgeMapping: Wenn <code>helligkeit</code> das Reading für die aktuelle Helligkeit enthält und die Helligkeit mit <code>set <device> prozent xxx</code> gesetzt wird, sieht das homebridgeMapping wie folgt aus:
*** homebridgeMapping Brightness=helligkeit::prozent,minValue=0,maxValue=<maximalwert>

**Kommandos:
***Alexa, mache <name> heller/dunkler
***Alexa, Licht heller/dunkler

* Geräte, deren Farbe sich ändern lässt
** ...

* Geräte, deren Farbtemperatur sich ändern lässt
** ...

* Geräte, bei denen sich eine Lautstärke einstellen lässt
** ...

* Geräte, bei denen sich ein prozentualer Wert einstellen lässt
** Automatisch: wenn <code>dim</code> oder <code>pct</code> Kommandos erkannt werden
** ...

* elektrische Türschlösser
** <code>genericDeviceType</code>: lock
** hombridgeMapping mit LockCurrentState und LockTargetState

* Thermostate
** Über <code>genericDeviceType</code> thermostate
** ...

* structure Devices aus FHEM (ab alexa-fhem version 0.5.7)
** können mit <code>genericDeviceType</code> scene als Szene eingebunden werden
** über <code>alexaRoom</code> kann der name um einen Ort ergänzt werden
** Szenen aus einer structure lassen sich ein- und ausschalten
** Wichtig:
*** Ein Skill darf nur 12 Szenen automatisch erkennen und einbinden.

* LightScene Devices aus FHEM (ab alexa-fhem version 0.5.8)
** können mit <code>genericDeviceType</code> scene als Szenen eingebunden werden
** über <code>alexaRoom</code> kann der name um einen Ort ergänzt werden
** Szenen aus einer LightScene lassen sich nur einschalten
** Wichtig:
*** Ein Skill darf nur 12 Szenen automatisch erkennen und einbinden.

* Geräte, deren Kanal sich umschalten lässt (ab alexa-fhem version 0.5.13)
** Über <code>genericDeviceType</code> media
** hombridgeMapping ChannelController:reading=<reading>,cmd=<cmd>
** Erlaubte Werte siehe hier: https://developer.amazon.com/de/docs/device-apis/alexa-channelcontroller.html#changechannel
** ...

* Geräte, deren Playback status sich schalten lässt (ab alexa-fhem version 0.5.13)
** Über <code>genericDeviceType</code> media
** hombridgeMapping PlaybackController:playback,values=Play;Pause;Stop;Previous;Next
** Erlaubte Werte siehe hier: https://developer.amazon.com/de/docs/device-apis/alexa-playbackcontroller.html#discovery
** ...

* Geräte, deren Eingang sich umschalten lässt (ab alexa-fhem version 0.5.13)
** Über <code>genericDeviceType</code> media
** hombridgeMapping InputController:reading=<reading>,cmd=<cmd>,values=HDMI+1;HDMI+2;XBOX
** Erlaubte Werte siehe hier: https://developer.amazon.com/de/docs/device-apis/alexa-property-schemas.html#input
** ...

* Kontaktsensoren (ab alexa-fhem version 0.5.15)
** Über <code>genericDeviceType</code> contact
** hombridgeMapping ContactSensorState:reading=<reading> oder CurrentDoorState:reading=<reading>
** Die Anzeige in der Alexa-App funktioniert sofort, die Abfrage per Sprache erst ab Version 0.5.27.

* Geräte, deren Lautstärke sich ändern lässt (ab alexa-fhem version 0.5.24)
** Über <code>genericDeviceType</code> speaker
** Automatisch: es muss ein Reading <code>volume</code> und/oder <code>mute</code> geben
** hombridgeMapping Volume:reading=<reading>,cmd=<cmd> Mute:reading=<reading>,cmd=<cmd>
** ...

* Geräte, die sich ein- (und optional) ausschalten lassen als Szene (ab alexa-fhem version 0.5.26)
** Über <code>genericDeviceType</code> scene
** Automatisch: Müssen <code>set on</code> und <code>set off</code> Kommandos haben
** hombridgeMapping On:reading=<reading>,cmdOn=<cmd>[,cmdOff=<cmd>]
** Hinweis: Fehlende Kommandos lassen sich mit cmdalias erzeugen
** Wichtig:
*** Ein Skill darf nur 12 Szenen automatisch erkennen und einbinden.

Es werden noch einige andere häufig verwendete Geräte (Homematic, hue,...) automatisch erkannt.

to be continued ...

In der [https://developer.amazon.com/docs/device-apis/list-of-interfaces.html List of Capability Interfaces] bei Amazon kann man sehen, welche Möglichkeiten das Smart Home Skill API aktuell in einzelnen Ländern bietet. Leider ohne die jeweiligen landessprachlichen Kommandos.

== Mögliche Probleme und Lösungen ==

Es kann vorkommen, dass Geräte zwar korrekt erkannt werden, aber das durch Alexa erkannte Kommando nicht richtig umgesetzt wird (Beispiel - mittlerweile behoben: {{Link2Forum|Topic=96766}}). Neben dem FHEM-Log gibt es noch das Logfile, welches von alexa-fhem angelegt wird.

=== Fehlersuche über die FHEM-Oberfläche ===

* alexa-fhem Logfile anschauen (Detail-Ansicht des <alexa>-Device aufrufen, klick auf '''Logfile''' oben)
* alexa-fhem im Debug-Modus aufrufen:
** -D zum alexaFHEM-params attribut hinzufügen
** Alexa-Befehl auslösen
** -D aus dem alexaFHEM-params attribut entfernen
* Die notwendigen Informationen finden sich in dem alexa-Logfile (siehe oben)

=== Fehlersuche über Kommandozeile (lies: Shell) + FHEM-Oberfläche ===

:* set <alexa> stop (FHEM-Oberfläche)
:* Auf der Kommandozeile <code>alexa-fhem -D -c /opt/fhem/alexa-fhem.cfg > debug.log</code> starten (dadurch wird die Datei debug.log erzeugt im aktuellen Verzeichnis)
:* Alexa-Befehl auslösen
:* alexa-fhem auf der Kommandozeile wieder stoppen (CTRL-C)
:* set <alexa> start (FHEM-Oberfläche)

Die Datei debug.log sollte Hinweise enthalten, wie das Problem zu lösen ist oder Dich zumindest in die richtige Richtung schieben.

Im Beispiel aus dem Forum fand sich in dem Logfile der Hinweis darauf, dass das Device mit falschen min/max-Werten unterwegs war.

=== Registrierungskey vergessen, Registrierung zurücksetzen ===

Auf der Kommandoshell:

<syntaxhighlight lang="bash" style="width:90%;">
pi@raspberrypi:~# sudo -u fhem ssh -p 58824 fhem-va.fhem.de status
Registered.
Registered on 2019-01-13T15:38:13Z.
</syntaxhighlight>

heisst, das der Vereinsserver eigentlich alles hat, was er will. Es wird kein neuer Schlüssel generiert.
Wenn Du die Situation zurücksetzen möchtest, wäre die hässliche Methode, Deinen SSH-Key zu löschen. Eleganter ist, die Registrierung auf Vereinsseite zu löschen:

<syntaxhighlight lang="bash" style="width:90%;">
pi@raspberrypi:~# sudo -u fhem ssh -p 58824 fhem-va.fhem.de unregister
Your registration has been removed
</syntaxhighlight>

löscht Deinen Schlüssel mitsamt allen dort gespeicherten Daten auf Vereinsseite. Bei Restart von alexa-fhem in FHEM-WEB wird jetzt ein neuer Registrierungskey angefordert.

== Sicherheitskonzept und Secrets ==

Um diesen Abschnitt zu verstehen, solltest Du den Abschnitt "Arbeitsweise" im Kopf haben. Einerseits ist Dir vermutlich einleuchtend, dass ein Server, der per SSH rückwärts nur ausgewählte Kommandos in den Tunnel, den Du aufgebaut hast, leitet, "irgendwie sicherer" ist. Andererseits möchte man nicht blind vertrauen.

=== SSH ===
==== SSH - macht das nichts Gefährliches? ====
SSH ist ein Veteran des Internet und entstand, um sich sicher (verschlüsselt) und schnell auf Servern einzuloggen. Schon früh wurde dabei der sogenannte "Reverse-Tunnel" implementiert: Also der vom Client (Deinem Rechner) geäußerte Wunsch: "Bitte leite mir Requests, die bei Dir, Server, auf Port xy eingehen, an meinen lokalen Port yz weiter.". Dieses Verfahren implementiert der Reverseproxy, wobei tatsächlich auf dem Server für Dich kein echter Port geöffnet wird.

Wie Dir ggf. sicher der Unix-Guru Deines Vertrauens bestätigen wird: Die Kombination
<syntaxhighlight lang="bash" style="width:50%;">
ssh -R 1234:localhost:<zufälliger port> zielserver
</syntaxhighlight>
erlaubt keine Ausführung von Shell-Kommandos auf Deinem Server, sondern einzig, dass vom SSH-Programm Verbindungen zu einem lokalen Port auf Deinem Server auf dem alexa-fhem lauscht aufgebaut werden. Du kannst also z.B. mit einem
<syntaxhighlight lang="bash" style="width:50%;">
sudo /usr/sbin/tcpdump -X -s 0 -i lo port <zufälliger port>
</syntaxhighlight>
vollständig überwachen (oder ggf. permanent aufzeichen), was auf Deinem Server von außen gesteuert passiert.

==== Wie wird bei SSH verschlüsselt? ====
Im Prinzip wie im Web auf SSL-Seiten, teils mit den gleichen Verschlüsselungsverfahren. Allerdings arbeitet SSH eher wie das im Web recht seltene Verfahren: Bei jeder Verbindung übermitteln sowohl Server wie auch Client den öffentlichen Teil ihres Schlüssels. Anders als im Web wird der Schlüssel aber nicht von einer öffentlichen Zertifizierungsstelle wie "LetsEncrypt" unterschrieben. Stattdessen entscheiden Server wie Client beim ersten Verbindungsaufbau typischerweise per manueller Frage: "Willst Du jetzt und künftig diesem Schlüssel vertrauen?" Bei der Installation wird diese Frage für Deine Seite bejaht, und fortan wird der öffentliche Schlüssel des FHEM-Servers auf Deinem Rechner gespeichert. Ab da bist Du z.B. davor sicher, dass jemand den DNS-Eintrag verbiegt oder sich in den Datenfluss Deines Providers einhängt: Ein geänderter Serverschlüssel würde bemerkt werden.
 
Soweit klar? Aus Deinem öffentlichen Schlüssel wiederum leitet der Server her: "Das ist definitiv wieder derjenige, der sich damals "registriert" hat". Und an dieser Stelle kann ich auch den ersten Teil des 3-teiligen Registrierungskeys erläutern: Die typischerweise 6-stellige Hex-Zahl am Anfang ist der Java-Hashcode Deines öffentlichen Schlüssel. Sie ist damit sozusagen Deine aus Deinem öffentlichen Schlüssel abgeleitete Benutzer-ID.

=== Die Rolle der Secrets ===
Wenn jetzt klar ist, dass die Verbindung zum Vereinsserver sicher und vertauschungsfrei funktioniert, bleiben noch 2 Probleme zu lösen:
1) Im Web bei der Skill-Aktivierung musst Du beweisen, dass Du der Mensch am Browser bist, dem der SSH-Tunnel von IP xy mit dem öffentlichen Schlüssel X gehört. Bei der automatischen Registrierung werden lokal auf Deinem Rechner zwei 64-Bit-Secrets generiert:
* Das Anmelde-Secret
* Das Bearer-Token
Beim Anmelden des SSH-Keys auf dem öffentlichen Server wird nun der Hashwert des ersten Secrets übertragen und dort in Verbindung mit Deinem öffentlichen Schlüssel gespeichert. Ein Hashwert bedeutet, dass (sofern das Verfahren, hier SHA256, funktioniert), niemand aus dem Hash das Secret zurückrechnen kann. Ein Datenbankklau auf dem Server gefährdet also nicht die Sicherheit Deines Passwortes.

Wenn Du nun beim Skill-Aktivieren den Registrierungskey eingibst, dann "sieht" der Server zum ersten Mal Dein ausgewürfeltes Secret, vergleicht es mit dem Hashwert und wird es anschließend wieder umgehend vergessen. Anhand des Hashwertes kann der Server aber entscheiden, dass Du der legitime Nutzer zum öffentlichen Schlüssel XY bist.

2) Das zweite Problem ist: Wie soll Amazon "beweisen", dass sie der legitime Aufrufer sind? Amazon erhält binnen wenigen Sekunden nach dem Klick auf "Activate Skill" den dritten Teil des Registrierungskeys als sogenanntes Bearer-Token. Zwar läuft er durch den Registrierungsserver, er wird dort, auf dem Registrierungs/Vereinsserver aber nicht gespeichert. Das Bearer-Token wird von Amazon bei allen Requests zu Deinem Server mitgesendet. Da es am Anfang zusätzlich Deine "User-ID" enthält, weiß der Vereinsserver, zu welchem SSH-Tunnel der Request zu senden ist. Aber lokal auf Deinem Rechner wird ausgewertet, ob das Token "stimmt".

== alexa-fhem Updaten ==
* alexa-fhem über FHEM anhalten:
:<syntaxhighlight lang="perl" style="width:50%;">set alexa stop</syntaxhighlight>

*Auf der Konsole wie anfangs bei der Installation:
:<syntaxhighlight lang="bash" style="width:50%;">sudo npm update -g alexa-fhem</syntaxhighlight>

:Manchmal hat npm Probleme mit einem Update. Dann einfach die aktuelle Version noch mal drüber Installieren:

:<syntaxhighlight lang="bash" style="width:50%;">sudo npm install -g alexa-fhem</syntaxhighlight>

*alexa-fhem über FHEM wieder starten:
:<syntaxhighlight lang="perl" style="width:50%;">set alexa start</syntaxhighlight>

== Bug- und Wunschliste ==
* Ist beim Start keine Internetverbindung vorhanden, erfolgt kein Retry -- alexa-fhem muss restartet werden (ssh_autoconfig wertet keine temporären Fehler aus)

==Weitergehende Informationen==
*[[Alexa und Mappings]]
*[[Alexa Tipps und Kniffe]]
*[[FHEM Connector for Amazon Alexa]]
[[Kategorie:HOWTOS]]
[[Kategorie:Sprachsteuerung]]

FHEM Connector für Amazon Alexa

2020-01-06T10:08:29Z

MadMax-FHEM: /* Geräte im FHEM-Webfrontend zuweisen */

{{Baustelle}}
'''Alexa FHEMlazy''' war historisch ein Fork des Original [[Alexa-Fhem|alexa-fhem]], der im Januar 2019 mit dem Original zusammengeführt wurde und nun als '''FHEM Connector''' verfügbar ist.

Er ermöglicht innerhalb von Minuten die Verknüpfung von FHEM mit einem Amazon Echo Gerät. Auch Geräte anderer Hersteller mit verbauten Mikrofonen und Alexa-Sprachassistenten-Unterstützung sollten problemlos funktionieren. Für folgende Geräte ist dies bspw. der Fall (Falls Ihr andere/weitere Gerätemodelle bzw. Hersteller in Verwendung habt, bitte hier pflegen):

* SONOS Beam und SONOS One

Gegenüber dem klassischen Ansatz ergeben sich Einschränkungen, so läuft die Software normalerweise unter dem gleichen Benutzer wie FHEM auf dem gleichen Server, und es wird z.Zt. nur der Smarthome-Skill unterstützt (die Variante, bei der die Möglichkeiten der Interaktion von Amazon festgelegt wurden).
Dafür ist weder ein Developer-Account bei Amazon, eigene Lambda- und Skillfunktionen, noch das Öffnen eines eingehenden Ports aus dem Internet nötig.
* Die Software integriert einen Installer, der die Erstkonfiguration und Anmeldung übernimmt
* Die Kommunikation zur Software auf dem heimischen Rechner und dann zu FHEM verläuft über SSH und einen vom FHEM-Verein gehosteten Server
* Funktioniert mit IPv4, IPv6, echtem Dual Stack und DS-Lite
* Als Skill bei Amazon wird der Skill "FHEM Connector" verwendet.

Der Thread im Forum zur Software ist hier: {{Link2Forum|Topic=94817}}.

{{Infobox Modul
|ModPurpose=Einfache Anbindung von FHEM an Amazon Assistent Alexa
|ModType=h
|ModCmdRef=alexa
|ModTechName=39_alexa.pm / alexa-fhem
|ModForumArea=Frontends/Sprachsteuerung
|ModOwner=gvzdus, André/ justme1968 ({{Link2FU|430|Forum}} / [[Benutzer Diskussion:Justme|Wiki]])
}}

==Einführung==

===Arbeitsweise und Datenfluss===
Vorläufig ist alexa-fhem im "FHEM Connector-Modus" ein reiner [https://developer.amazon.com/de/docs/smarthome/understand-the-smart-home-skill-api.html SmartHome-Skill].
SmartHome-Skills erhalten weder die Sprachdaten selber noch das, was Amazon in Textform verstanden hat, sondern vielmehr extrahiert Amazon aus dem verstandenen Text Anweisungen und Abfragen für Geräte, die dann an den Skill übermittelt werden. Charmant ist dabei, dass unmittelbar gefragt werden kann "Alexa, wie ist die Temperatur im Wohnzimmer?", während andere Skills zunächst explizit angesprochen werden müssen ("Alexa, frage FHEM nach der Temperatur im Wohnzimmer"). Außerdem kann der Nutzer mehrere Smarthome-Skills installieren, und die Geräte werden zu einer Gesamtmenge zusammengefasst.

Gehen wir den Datenfluss bei der konkreten Frage "Wie ist die Temperatur im Wohnzimmer?" durch:
* Alexa hat bei der Skillinstallation gelernt, dass "FHEM Connector" bei Dir einen Thermostaten im Raum Wohnzimmer kennt. Dadurch wird bei der Sprachanalyse von "Alexa Voice Service" in der Cloud erkannt, dass eine Abfrage an "FHEM Connector" erfolgversprechend ist.
* Zunächst wird die zentrale "Lambda-Funktion" von "FHEM Connector" aufgerufen. Die Funktion leitet aber im Kern nur den Request unverändert an den vom Verein bereitgestellten Server weiter. Im Request enthalten ist ein Token, das sogenannte "Bearer-Token".
* Der "Vereinsserver" prüft anhand dieses Tokens, ob es überhaupt bekannt ist, und zu welchem Nutzer es gehört. Ist dieser Nutzer verbunden, wird der Request wiederum quasi unverändert an den Nutzer weitergeleitet.
* Diese Weiterleitung passiert über einen sogenannten SSH-Reverse-Tunnel, der von Deiner Seite und der Software auf dem FHEM-Tunnel automatisch aufgebaut wird.
* Auf Deiner Seite läuft die eigentliche Software, und zwar unter nodeJS. nodeJS ist ein Javascript ausführender Miniserver, der lokal auf Port 3000 auf Requests "lauscht". In der Original-Version [[Alexa-Fhem|Alexa FHEM]] kommen die Requests aus dem Internet (hoffentlich von der eigenen Lambda-Funktion), hier bei "FHEM Connector" kommen sie ausschließlich aus dem SSH-Tunnel von lokal.
* Die Software validiert nun diesen Request anhand des Bearer-Tokens. Konkret wird dabei das bei der Installation generierte Token, dass bei der Skill-Aktivierung an Amazon übertragen wurde, mit dem lokal gespeicherten Wert verglichen. Stimmt das Token, wird der Befehl verarbeitet, üblicherweise wird hierbei ein Aufruf an die Webschnittstelle von FHEM abgesetzt.
* FHEM führt den Befehl aus

Hört sich langsam und kompliziert an? Kompliziert: Okay. Langsam eher nicht, in etlichen Fällen liegt die Gesamtantwortszeit unter 200 ms.

Soweit ein erster Überblick über die Datenflüsse. Im Abschnitt Sicherheit ist das Konzept der Absicherung deutlich genauer und ausführlicher beschrieben.

==Installation==

Du wirst bei der Installation zuerst auf der Kommandozeile auf Deinem Raspberry (o.ä.) unterwegs sein, anschließend im Webfrontend von FHEM, und zum Schluss auf der Alexa-Konsole im Web.

===node.js installieren===

Bei Jessy liegt NodeJS bereits in einer ausreichend aktuellen Version vor. Mit

<syntaxhighlight lang="bash" style="width:50%;">
sudo apt-get install nodejs npm
</syntaxhighlight>

kannst Du es installieren. Mit
<syntaxhighlight lang="bash" style="width:50%;">
node --version
</syntaxhighlight>

erfährst Du die aktuelle Version - wenn hier etwas mit "8" vorneweg erscheint, ist alles gut.
Ansonsten suche Dir bitte eine Anleitung im Web, wie Du NodeJS auf Deinem System auf einen aktuellen Stand bringen kannst.

=== Alexa-FHEM installieren ===

Nun installieren wir Alexa-fhem aus dem offiziellen Repository:

<syntaxhighlight lang="bash" style="width:50%;">
sudo npm install -g alexa-fhem
</syntaxhighlight>

Der Vorgang benötigt etwas Zeit.

=== Alexa-FHEM aktivieren ===

Wechsele jetzt in FHEM-Web!

Wichtig ist, dass das Alexa-Modul in der Version ab 14. Januar 2019 vorliegt. Dafür bitte einmal FHEM aktualisieren:
Speichern der Config nicht vergessen, und

<syntaxhighlight lang="bash" style="width:50%;">
update
shutdown restart
</syntaxhighlight>

Alles, was jetzt noch nötig ist, ist das Anlegen eines Alexa-Devices. Gib dafür in der FHEM-Web-Kommandozeile

<syntaxhighlight lang="bash" style="width:50%;">
define alexa alexa
</syntaxhighlight>

an. Nun läuft, während Du bereits das neu angelegte Alexa-Devices siehst, ein komplexer Prozess im Hintergrund:

* Falls noch kein SSH-Key für den Benutzer, unter dem FHEM läuft, existiert, wird einer generiert
* Es wird ein Secret-Key im Prozess generiert, dass den Server nicht verlässt, und der Skillanmeldung dient.
* Du wirst auf dem Server "va-fhem.fhem.de" des FHEM-Vereins mit dem SSH-Key angemeldet, und der Hash-Wert Deines Secret-Key dort abgelegt.

Und wenn Du diese Sätze gelesen hast, sollte inzwischen sich das Alexa-Device in FHEM-Web aktualisiert haben, und
ungefähr so aussehen:

[[Datei:Alexa-Device-2.png|800px]]

Neben dem Status für alexa-fhem und der Proxyverbindung ist wichtig, dass diese beiden Zeilen beim Reload aufgetaucht sind:

<syntaxhighlight lang="bash" style="width:90%;">
alexaFHEM.bearerToken crypt:...
alexaFHEM.skillRegKey crypt:...
</syntaxhighlight>

Ja, und diesen Schlüssel benötigst Du wirklich! Also am besten schon einmal mit

<syntaxhighlight lang="bash" style="width:90%;">
get <alexa> proxyKey
</syntaxhighlight>

in Klartext anzeigen lassen und in ein Editor-Fenster dauerhaft wegsichern.

Jetzt solltest Du Dein Alexa-Device nicht mehr löschen, denn das im Reading angezeigte "bearerToken" zu löschen bedeutet, dass die Software die Zugriffe von nicht mehr überprüfen kann und keine Kommandos mehr funktionieren. In diesem Fall hilft nur die Neuinstallation des Skills.

==== Fehler bei der Aktivierung ====

Während kompliziertere Fehlerfälle im Abschnitt "Mögliche Probleme und Lösungen" behandelt werden, hier häufige Fälle, warum die kryptischen Zeilen nicht auftauchen:

* Zuerst bitte einfach einmal die Seite neu laden.

===== 401: Authorization Required =====

Wenn Du FHEM-Web mit einem User/Passwort-Schutz versehen hast, wirst du folgende Fehlermeldung sehen:

<syntaxhighlight lang="bash" style="width:90%;">
alexaFHEM stopped; failed to connect to fhem: 401: Authorization Required
</syntaxhighlight>

In der Regel musst du die Angaben User/Passwort noch einmal explizit setzen. Im Attribute-Abschnitt "alexaFHEM-auth" auswählen, User/Passwort mit ":" getrennt angeben und "attr" anklicken. alexa-fhem wird automatisch neu gestartet. Hier das Ganze in der Text-Variante:

<syntaxhighlight lang="bash" style="width:90%;">
attr alexa alexaFHEM-auth user:pass
</syntaxhighlight>

===== Permission denied =====

Wenn du folgende Fehlermeldungen im Alexa Logfile siehst, wurde das Verzeichnis "/opt/fhem/.ssh/" von dir bei der Arbeit mit "root" oder "sudo" mit den falschen Berechtigungen versehen:

<syntaxhighlight lang="bash" style="width:90%;">
[2019-7-25 11:59:12] sshautoconf: aborted with ssh-keygen returned error - key_save_private: Permission denied
[2019-7-25 11:59:12] *** SSH: proxy configuration failed: ssh-keygen returned error - key_save_private: Permission denied
</syntaxhighlight>

Prüfen kannst du die Berechtigungen mit folgendem Befehl auf der Shell-Konsole:

<syntaxhighlight lang="bash" style="width:90%;">
ls -l /opt/fhem/.ssh
</syntaxhighlight>

Du solltest dann folgende Ausgabe erhalten:

<syntaxhighlight lang="bash" style="width:90%;">
insgesamt 12
-rw------- 1 fhem dialout 1675 Jul 12 13:10 id_rsa
-rw-r--r-- 1 fhem dialout 391 Jul 12 13:10 id_rsa.pub
-rw-r--r-- 1 fhem dialout 884 Jul 12 13:10 known_hosts
</syntaxhighlight>

Steht in der Ausgabe nicht "fhem dialout" (dein fhem User), sondern bspw. "root root", dann bspw. mit folgendem Befehl an deinen fhem User anpassen:

<syntaxhighlight lang="bash" style="width:90%;">
chown fhem:dialout /opt/fhem/.ssh
</syntaxhighlight>

Mit dem ersten Befehl "ls -l ..." kannst du dann nochmal prüfen, ob die Berechtigungen korrekt übernommen wurden.

===== weitere Prüfungen =====

Hast Du noch die Shell-Konsole offen? Dann prüfe bitte noch einmal auf der Konsole, ob nun zwei Prozesse laufen:

<syntaxhighlight lang="bash" style="width:50%;">
ps -ef | egrep '(alexa|ssh)'
</syntaxhighlight>

sollte Dir idealerweise so etwas anzeigen:
<syntaxhighlight lang="bash" style="width:90%;">
fhem 31322 1 99 13:56 ? 00:00:03 alexa
fhem 31332 31322 8 13:56 ? 00:00:00 /usr/bin/ssh -R 1234:127.0.0.1:<zufälliger port> -oServerAliveInterval=90 -p 58824 fhem-va.fhem.de
</syntaxhighlight>

"alexa" ist dabei der Node-JS-Prozess, der ssh-Prozess ist die aufgebaute Verbindung zum Vereinsserver.

Wenn Du diese Prozesse '''nicht''' siehst oder das Alexa-Device keinen Registrierungskey anzeigt, dann ist leider der Start nicht glatt verlaufen.

Im Logfile (über den link <code>Logfile</code> in der Detail-Ansicht über <code>set</Code>, oder über den Namen bei ''currentlogfile'' in den Internals) findest Du idealerweise selber Hinweise, wo es hakt, oder kannst im Forum nachfragen.

=== Geräte im FHEM-Webfrontend zuweisen ===
Um das Aha-Erlebnis zu vergrößern, ist jetzt ein guter Zeitpunkt, 1 oder besser mind. 2 Geräte für den Alexa-Dienst zuzuweisen. Von Haus aus wird keines Deiner FHEM-Geräte automatisch Alexa zugewiesen!

Wähle die Geräte aus, rufe sie auf und setze das Attribut "alexaName". Hierbei in Kürze nur der Hinweis:
* Keine Angst vor Leerzeichen und Umlauten, funktioniert.
* Große Angst vor Rechtschreibfehlern (Terrasse, Rollladen) oder komplizierten Wörtern "handgebastelte Martinslaterne im Kinderzimmer Iphigenie-Chantal".
* Das Attribut "alexaRoom" ist NUR FÜR DEN CUSTOM SKILL relevant. Ausnahme: structure und LightScene Devices, siehe: [[FHEM_Connector_f%C3%BCr_Amazon_Alexa#Was_geht_alles_.3F]].

Lade die Geräte neu in die Software, indem Du <code>set <alexa> restart</code> ausführst! 
 

'''Anmerkungen (weil oft gestellte Fragen im Forum) bzgl. erkennung von Geräten:'''

* Wichtig ist, dass die Filtereinstellung in der alexa-fhem.cfg (zu finden unter "Edit Files") passt.
Also was dort eingetragen ist (Standard: alexaName=..* / also es ist ein alexaName vergeben) auch an den entsrpechenden Devices in fhem vorhanden ist.
Stimmt das schon nicht überein, kann alexa-fhem schon mal keine Devices von fhem abfragen/finden.
Ob der Filter entsprechend funktioniert kann man wie folgt testen: ''list Filtereinstellung'' beispiel mit Standardfilter: ''list alexaName=..*''

* Hat alexa-fhem per Filter Devices aus fhem "gefunden", geht es weiter mit der "Erkennung". Also um welches Device (Typ und "Fähigkeiten") handelt es sich. Dazu gilt folgendes:
** sind entsprechende Readings beim Device vorhanden (z.B. temperature, state mit on/off, ...) erkennt das alexa-fhem automatisch. Die Liste der automatisch erkannten Readings wächst ständig. Daher erst mal schauen ob das Device bereits entsprechend erkannt (typisiert) wurde. Das kann durch prüfen des alexa-fhem-Logs geschehen (NICHT fhem-log!).
** sind entsprechende "set-Befehle" erkennbar (oft auch durch Readings). Also ist beispielsweise (wie beim Dummy nötig) ein ''setList'' mit entsprechenden Einträgen vorhanden oder entsprechende Readings, z.B. desired-temp zum Stellen der Temperatur etc.
** wird das Device nicht richtig oder "unvollständig" erkannt helfen folgende Attribute:
*** genericDeviceType: hiermit kann alexa-fhem in die gewünschte Richtung "geschubbst" werden. Anmerkung: man kann nicht alles erzwingen, Readings bzw. set-Befehle müssen passen (oder per homebridgeMapping passend gemacht werden). Wenn ein genericDeviceType nicht per "Drop-Down" erscheint, dann kann er auch (wenn bekannt) einfach per WEB-cmd eingegeben werden: ''attr Devicename genericDeviceType media''
*** homebridgeMapping: hierdurch kann alexa-fhem bei der Erkennung von Zuständen und möglichen Einstellungen (also WAS kann das Device) unterstützt werden. Mittels homebridgeMapping können vorhandene Readings (Zustände) auf für alexa-fhem bekannte Zustände gemappt werden. Ebenso können damit Standard-fhem-Kommandos von alexa-fhem auf Device-spezifische gemappt werden. Beispiel: on/off auf Ein/Aus (falls das Device statt on/off eben ein Ein/Aus erwartet) [Konkretes homebridgemapping als Beispiel FEHLT!!].

'''Anmerkung bzgl. genericDeviceType und homebridgeMapping:''' 
* diese Attribute werden von verschiedenen "Sprachsteuerungsmodulen" in fhem verwendet (homebridge [dort wurde es "erfunden"], alexa-fhem, gassistant, ...). Daher ist nicht jedes Mapping für alle "Dienste" verwendbar. Ausprobieren schadet aber nicht.
* ebenso kann man mit diesen Attributen (homebridgeMapping wird gerne so "missbraucht") nichts erzwingen, was seitens Amazon/Alexa nicht unterstützt bzw. verstanden wird! D.h. zunächst ist zu prüfen, ob ein bestimmter (gewünschter) Sprachbefehl seitens Amazon/Alexa unterstützt wird! Aktuelles Beispiel (Stand Jan 2020): "Alexa, fahre den Rollo hoch/runter". Da ist Amazon/Alexa gerade dabei etwas zu tun. Bislang wird das nicht unterstützt, also ist das auch mit einem entsprechenden homebridgeMapping nicht zu erzwingen! Was unterstützt wird kann man bei Amazon nachlesen: (LINK einfügen!!!)

== Finale: Skill verknüpfen ==
Suche im WebFrontend oder der Alexa-App den Skill "FHEM Connector". Für nicht-Mac/iOS Anwerder empfiehlt das WebFrontend (https://alexa.amazon.de) statt die App, damit Du den Anmeldeschlüssel auch bequem kopieren kannst.

Wenn du noch nicht bei Amazon angemeldet bist, erwartet Amazon zunächst, dass Du Dich normal bei Amazon anmeldest.

Sobald Du "FHEM Connector" aktivierst, öffnet sich ein Browser-Tab mit folgender Maske: 
[[Datei:FHEMlazy_login.png|240px]]

Hier kopierst Du Deinen Anmeldeschlüssel (im Klartext!) hinein und klickst auf Check. Als glücklicher Mensch ist auf der folgenden Statusseite alles grün: 
[[Datei:FHEMlazy_check.png|240px]]

Im Einzelnen wird hier geprüft, ob Du per SSH verbunden bist (und auch Deine IP zur Sicherheit angezeigt), ob der Reverse-Tunnel steht, ob nodeJS erreichbar ist und wie viele Geräte Alexa gleich finden sollte (in meinem Fall 22).

Sollte etwas nicht grün sein und Du eine Idee zum Fixen haben, kannst Du mit "Retry" neue Versuche auslösen.

Ist alles okay, klicke rechts den Button "Activate Skill". Du springst damit wieder zurück zu Amazon, die Dir hoffentlich zur erfolgreichen Verknüpfung gratulieren.

Amazon möchte nun unmittelbar die Gerätesuche starten, und unter SmartHome-Geräte sollten diese nun auftauchen.

== Was geht alles ? ==

* Geräte, die sich ein- und ausschalten lassen:
** Automatisch: Müssen <code>set on</code> und <code>set off</code> Kommandos haben
** dummys müssen <code>setList</code> mit on und off haben
** Über <code>genericDeviceType</code> switch bzw. light kann bestimmt werden ob es in alexa als Schalter oder Licht behandelt wird.
** Wenn die Set-Kommandos im FHEM Device anders benannt sind: hombridgeMapping On:cmdOn=<ein>,cmdOff=<aus> setzen
** Kommandos:
***Alexa, schalte <name> ein/aus
***Alexa, Licht an/aus
***Alexa, schalte <gruppe> ein/aus

* Geräte, die eine Temperatur messen
** Automatisch: Es muss ein Reading temperature geben
** Über <code>genericDeviceType</code> thermometer
** Sonst: hombridgeMapping CurrentTemperature:reading=<reading>

* Geräte, deren Helligkeit sich ändern lässt
** Automatisch: wenn <code>dim</code> oder <code>pct</code> Kommandos erkannt werden
** Über <code>genericDeviceType</code> light
** Über homebridgeMapping: Wenn <code>helligkeit</code> das Reading für die aktuelle Helligkeit enthält und die Helligkeit mit <code>set <device> prozent xxx</code> gesetzt wird, sieht das homebridgeMapping wie folgt aus:
*** homebridgeMapping Brightness=helligkeit::prozent,minValue=0,maxValue=<maximalwert>

**Kommandos:
***Alexa, mache <name> heller/dunkler
***Alexa, Licht heller/dunkler

* Geräte, deren Farbe sich ändern lässt
** ...

* Geräte, deren Farbtemperatur sich ändern lässt
** ...

* Geräte, bei denen sich eine Lautstärke einstellen lässt
** ...

* Geräte, bei denen sich ein prozentualer Wert einstellen lässt
** Automatisch: wenn <code>dim</code> oder <code>pct</code> Kommandos erkannt werden
** ...

* elektrische Türschlösser
** <code>genericDeviceType</code>: lock
** hombridgeMapping mit LockCurrentState und LockTargetState

* Thermostate
** Über <code>genericDeviceType</code> thermostate
** ...

* structure Devices aus FHEM (ab alexa-fhem version 0.5.7)
** können mit <code>genericDeviceType</code> scene als Szene eingebunden werden
** über <code>alexaRoom</code> kann der name um einen Ort ergänzt werden
** Szenen aus einer structure lassen sich ein- und ausschalten
** Wichtig:
*** Ein Skill darf nur 12 Szenen automatisch erkennen und einbinden.

* LightScene Devices aus FHEM (ab alexa-fhem version 0.5.8)
** können mit <code>genericDeviceType</code> scene als Szenen eingebunden werden
** über <code>alexaRoom</code> kann der name um einen Ort ergänzt werden
** Szenen aus einer LightScene lassen sich nur einschalten
** Wichtig:
*** Ein Skill darf nur 12 Szenen automatisch erkennen und einbinden.

* Geräte, deren Kanal sich umschalten lässt (ab alexa-fhem version 0.5.13)
** Über <code>genericDeviceType</code> media
** hombridgeMapping ChannelController:reading=<reading>,cmd=<cmd>
** Erlaubte Werte siehe hier: https://developer.amazon.com/de/docs/device-apis/alexa-channelcontroller.html#changechannel
** ...

* Geräte, deren Playback status sich schalten lässt (ab alexa-fhem version 0.5.13)
** Über <code>genericDeviceType</code> media
** hombridgeMapping PlaybackController:playback,values=Play;Pause;Stop;Previous;Next
** Erlaubte Werte siehe hier: https://developer.amazon.com/de/docs/device-apis/alexa-playbackcontroller.html#discovery
** ...

* Geräte, deren Eingang sich umschalten lässt (ab alexa-fhem version 0.5.13)
** Über <code>genericDeviceType</code> media
** hombridgeMapping InputController:reading=<reading>,cmd=<cmd>,values=HDMI+1;HDMI+2;XBOX
** Erlaubte Werte siehe hier: https://developer.amazon.com/de/docs/device-apis/alexa-property-schemas.html#input
** ...

* Kontaktsensoren (ab alexa-fhem version 0.5.15)
** Über <code>genericDeviceType</code> contact
** hombridgeMapping ContactSensorState:reading=<reading> oder CurrentDoorState:reading=<reading>
** Die Anzeige in der Alexa-App funktioniert sofort, die Abfrage per Sprache erst ab Version 0.5.27.

* Geräte, deren Lautstärke sich ändern lässt (ab alexa-fhem version 0.5.24)
** Über <code>genericDeviceType</code> speaker
** Automatisch: es muss ein Reading <code>volume</code> und/oder <code>mute</code> geben
** hombridgeMapping Volume:reading=<reading>,cmd=<cmd> Mute:reading=<reading>,cmd=<cmd>
** ...

* Geräte, die sich ein- (und optional) ausschalten lassen als Szene (ab alexa-fhem version 0.5.26)
** Über <code>genericDeviceType</code> scene
** Automatisch: Müssen <code>set on</code> und <code>set off</code> Kommandos haben
** hombridgeMapping On:reading=<reading>,cmdOn=<cmd>[,cmdOff=<cmd>]
** Hinweis: Fehlende Kommandos lassen sich mit cmdalias erzeugen
** Wichtig:
*** Ein Skill darf nur 12 Szenen automatisch erkennen und einbinden.

Es werden noch einige andere häufig verwendete Geräte (Homematic, hue,...) automatisch erkannt.

to be continued ...

In der [https://developer.amazon.com/docs/device-apis/list-of-interfaces.html List of Capability Interfaces] bei Amazon kann man sehen, welche Möglichkeiten das Smart Home Skill API aktuell in einzelnen Ländern bietet. Leider ohne die jeweiligen landessprachlichen Kommandos.

== Mögliche Probleme und Lösungen ==

Es kann vorkommen, dass Geräte zwar korrekt erkannt werden, aber das durch Alexa erkannte Kommando nicht richtig umgesetzt wird (Beispiel - mittlerweile behoben: {{Link2Forum|Topic=96766}}). Neben dem FHEM-Log gibt es noch das Logfile, welches von alexa-fhem angelegt wird.

=== Fehlersuche über die FHEM-Oberfläche ===

* alexa-fhem Logfile anschauen (Detail-Ansicht des <alexa>-Device aufrufen, klick auf '''Logfile''' oben)
* alexa-fhem im Debug-Modus aufrufen:
** -D zum alexaFHEM-params attribut hinzufügen
** Alexa-Befehl auslösen
** -D aus dem alexaFHEM-params attribut entfernen
* Die notwendigen Informationen finden sich in dem alexa-Logfile (siehe oben)

=== Fehlersuche über Kommandozeile (lies: Shell) + FHEM-Oberfläche ===

:* set <alexa> stop (FHEM-Oberfläche)
:* Auf der Kommandozeile <code>alexa-fhem -D -c /opt/fhem/alexa-fhem.cfg > debug.log</code> starten (dadurch wird die Datei debug.log erzeugt im aktuellen Verzeichnis)
:* Alexa-Befehl auslösen
:* alexa-fhem auf der Kommandozeile wieder stoppen (CTRL-C)
:* set <alexa> start (FHEM-Oberfläche)

Die Datei debug.log sollte Hinweise enthalten, wie das Problem zu lösen ist oder Dich zumindest in die richtige Richtung schieben.

Im Beispiel aus dem Forum fand sich in dem Logfile der Hinweis darauf, dass das Device mit falschen min/max-Werten unterwegs war.

=== Registrierungskey vergessen, Registrierung zurücksetzen ===

Auf der Kommandoshell:

<syntaxhighlight lang="bash" style="width:90%;">
pi@raspberrypi:~# sudo -u fhem ssh -p 58824 fhem-va.fhem.de status
Registered.
Registered on 2019-01-13T15:38:13Z.
</syntaxhighlight>

heisst, das der Vereinsserver eigentlich alles hat, was er will. Es wird kein neuer Schlüssel generiert.
Wenn Du die Situation zurücksetzen möchtest, wäre die hässliche Methode, Deinen SSH-Key zu löschen. Eleganter ist, die Registrierung auf Vereinsseite zu löschen:

<syntaxhighlight lang="bash" style="width:90%;">
pi@raspberrypi:~# sudo -u fhem ssh -p 58824 fhem-va.fhem.de unregister
Your registration has been removed
</syntaxhighlight>

löscht Deinen Schlüssel mitsamt allen dort gespeicherten Daten auf Vereinsseite. Bei Restart von alexa-fhem in FHEM-WEB wird jetzt ein neuer Registrierungskey angefordert.

== Sicherheitskonzept und Secrets ==

Um diesen Abschnitt zu verstehen, solltest Du den Abschnitt "Arbeitsweise" im Kopf haben. Einerseits ist Dir vermutlich einleuchtend, dass ein Server, der per SSH rückwärts nur ausgewählte Kommandos in den Tunnel, den Du aufgebaut hast, leitet, "irgendwie sicherer" ist. Andererseits möchte man nicht blind vertrauen.

=== SSH ===
==== SSH - macht das nichts Gefährliches? ====
SSH ist ein Veteran des Internet und entstand, um sich sicher (verschlüsselt) und schnell auf Servern einzuloggen. Schon früh wurde dabei der sogenannte "Reverse-Tunnel" implementiert: Also der vom Client (Deinem Rechner) geäußerte Wunsch: "Bitte leite mir Requests, die bei Dir, Server, auf Port xy eingehen, an meinen lokalen Port yz weiter.". Dieses Verfahren implementiert der Reverseproxy, wobei tatsächlich auf dem Server für Dich kein echter Port geöffnet wird.

Wie Dir ggf. sicher der Unix-Guru Deines Vertrauens bestätigen wird: Die Kombination
<syntaxhighlight lang="bash" style="width:50%;">
ssh -R 1234:localhost:<zufälliger port> zielserver
</syntaxhighlight>
erlaubt keine Ausführung von Shell-Kommandos auf Deinem Server, sondern einzig, dass vom SSH-Programm Verbindungen zu einem lokalen Port auf Deinem Server auf dem alexa-fhem lauscht aufgebaut werden. Du kannst also z.B. mit einem
<syntaxhighlight lang="bash" style="width:50%;">
sudo /usr/sbin/tcpdump -X -s 0 -i lo port <zufälliger port>
</syntaxhighlight>
vollständig überwachen (oder ggf. permanent aufzeichen), was auf Deinem Server von außen gesteuert passiert.

==== Wie wird bei SSH verschlüsselt? ====
Im Prinzip wie im Web auf SSL-Seiten, teils mit den gleichen Verschlüsselungsverfahren. Allerdings arbeitet SSH eher wie das im Web recht seltene Verfahren: Bei jeder Verbindung übermitteln sowohl Server wie auch Client den öffentlichen Teil ihres Schlüssels. Anders als im Web wird der Schlüssel aber nicht von einer öffentlichen Zertifizierungsstelle wie "LetsEncrypt" unterschrieben. Stattdessen entscheiden Server wie Client beim ersten Verbindungsaufbau typischerweise per manueller Frage: "Willst Du jetzt und künftig diesem Schlüssel vertrauen?" Bei der Installation wird diese Frage für Deine Seite bejaht, und fortan wird der öffentliche Schlüssel des FHEM-Servers auf Deinem Rechner gespeichert. Ab da bist Du z.B. davor sicher, dass jemand den DNS-Eintrag verbiegt oder sich in den Datenfluss Deines Providers einhängt: Ein geänderter Serverschlüssel würde bemerkt werden.
 
Soweit klar? Aus Deinem öffentlichen Schlüssel wiederum leitet der Server her: "Das ist definitiv wieder derjenige, der sich damals "registriert" hat". Und an dieser Stelle kann ich auch den ersten Teil des 3-teiligen Registrierungskeys erläutern: Die typischerweise 6-stellige Hex-Zahl am Anfang ist der Java-Hashcode Deines öffentlichen Schlüssel. Sie ist damit sozusagen Deine aus Deinem öffentlichen Schlüssel abgeleitete Benutzer-ID.

=== Die Rolle der Secrets ===
Wenn jetzt klar ist, dass die Verbindung zum Vereinsserver sicher und vertauschungsfrei funktioniert, bleiben noch 2 Probleme zu lösen:
1) Im Web bei der Skill-Aktivierung musst Du beweisen, dass Du der Mensch am Browser bist, dem der SSH-Tunnel von IP xy mit dem öffentlichen Schlüssel X gehört. Bei der automatischen Registrierung werden lokal auf Deinem Rechner zwei 64-Bit-Secrets generiert:
* Das Anmelde-Secret
* Das Bearer-Token
Beim Anmelden des SSH-Keys auf dem öffentlichen Server wird nun der Hashwert des ersten Secrets übertragen und dort in Verbindung mit Deinem öffentlichen Schlüssel gespeichert. Ein Hashwert bedeutet, dass (sofern das Verfahren, hier SHA256, funktioniert), niemand aus dem Hash das Secret zurückrechnen kann. Ein Datenbankklau auf dem Server gefährdet also nicht die Sicherheit Deines Passwortes.

Wenn Du nun beim Skill-Aktivieren den Registrierungskey eingibst, dann "sieht" der Server zum ersten Mal Dein ausgewürfeltes Secret, vergleicht es mit dem Hashwert und wird es anschließend wieder umgehend vergessen. Anhand des Hashwertes kann der Server aber entscheiden, dass Du der legitime Nutzer zum öffentlichen Schlüssel XY bist.

2) Das zweite Problem ist: Wie soll Amazon "beweisen", dass sie der legitime Aufrufer sind? Amazon erhält binnen wenigen Sekunden nach dem Klick auf "Activate Skill" den dritten Teil des Registrierungskeys als sogenanntes Bearer-Token. Zwar läuft er durch den Registrierungsserver, er wird dort, auf dem Registrierungs/Vereinsserver aber nicht gespeichert. Das Bearer-Token wird von Amazon bei allen Requests zu Deinem Server mitgesendet. Da es am Anfang zusätzlich Deine "User-ID" enthält, weiß der Vereinsserver, zu welchem SSH-Tunnel der Request zu senden ist. Aber lokal auf Deinem Rechner wird ausgewertet, ob das Token "stimmt".

== alexa-fhem Updaten ==
* alexa-fhem über FHEM anhalten:
:<syntaxhighlight lang="perl" style="width:50%;">set alexa stop</syntaxhighlight>

*Auf der Konsole wie anfangs bei der Installation:
:<syntaxhighlight lang="bash" style="width:50%;">sudo npm update -g alexa-fhem</syntaxhighlight>

:Manchmal hat npm Probleme mit einem Update. Dann einfach die aktuelle Version noch mal drüber Installieren:

:<syntaxhighlight lang="bash" style="width:50%;">sudo npm install -g alexa-fhem</syntaxhighlight>

*alexa-fhem über FHEM wieder starten:
:<syntaxhighlight lang="perl" style="width:50%;">set alexa start</syntaxhighlight>

== Bug- und Wunschliste ==
* Ist beim Start keine Internetverbindung vorhanden, erfolgt kein Retry -- alexa-fhem muss restartet werden (ssh_autoconfig wertet keine temporären Fehler aus)

==Weitergehende Informationen==
*[[Alexa und Mappings]]
*[[Alexa Tipps und Kniffe]]
*[[FHEM Connector for Amazon Alexa]]
[[Kategorie:HOWTOS]]
[[Kategorie:Sprachsteuerung]]

FHEM Connector für Amazon Alexa

2020-01-06T10:08:01Z

MadMax-FHEM: /* Geräte im FHEM-Webfrontend zuweisen */

{{Baustelle}}
'''Alexa FHEMlazy''' war historisch ein Fork des Original [[Alexa-Fhem|alexa-fhem]], der im Januar 2019 mit dem Original zusammengeführt wurde und nun als '''FHEM Connector''' verfügbar ist.

Er ermöglicht innerhalb von Minuten die Verknüpfung von FHEM mit einem Amazon Echo Gerät. Auch Geräte anderer Hersteller mit verbauten Mikrofonen und Alexa-Sprachassistenten-Unterstützung sollten problemlos funktionieren. Für folgende Geräte ist dies bspw. der Fall (Falls Ihr andere/weitere Gerätemodelle bzw. Hersteller in Verwendung habt, bitte hier pflegen):

* SONOS Beam und SONOS One

Gegenüber dem klassischen Ansatz ergeben sich Einschränkungen, so läuft die Software normalerweise unter dem gleichen Benutzer wie FHEM auf dem gleichen Server, und es wird z.Zt. nur der Smarthome-Skill unterstützt (die Variante, bei der die Möglichkeiten der Interaktion von Amazon festgelegt wurden).
Dafür ist weder ein Developer-Account bei Amazon, eigene Lambda- und Skillfunktionen, noch das Öffnen eines eingehenden Ports aus dem Internet nötig.
* Die Software integriert einen Installer, der die Erstkonfiguration und Anmeldung übernimmt
* Die Kommunikation zur Software auf dem heimischen Rechner und dann zu FHEM verläuft über SSH und einen vom FHEM-Verein gehosteten Server
* Funktioniert mit IPv4, IPv6, echtem Dual Stack und DS-Lite
* Als Skill bei Amazon wird der Skill "FHEM Connector" verwendet.

Der Thread im Forum zur Software ist hier: {{Link2Forum|Topic=94817}}.

{{Infobox Modul
|ModPurpose=Einfache Anbindung von FHEM an Amazon Assistent Alexa
|ModType=h
|ModCmdRef=alexa
|ModTechName=39_alexa.pm / alexa-fhem
|ModForumArea=Frontends/Sprachsteuerung
|ModOwner=gvzdus, André/ justme1968 ({{Link2FU|430|Forum}} / [[Benutzer Diskussion:Justme|Wiki]])
}}

==Einführung==

===Arbeitsweise und Datenfluss===
Vorläufig ist alexa-fhem im "FHEM Connector-Modus" ein reiner [https://developer.amazon.com/de/docs/smarthome/understand-the-smart-home-skill-api.html SmartHome-Skill].
SmartHome-Skills erhalten weder die Sprachdaten selber noch das, was Amazon in Textform verstanden hat, sondern vielmehr extrahiert Amazon aus dem verstandenen Text Anweisungen und Abfragen für Geräte, die dann an den Skill übermittelt werden. Charmant ist dabei, dass unmittelbar gefragt werden kann "Alexa, wie ist die Temperatur im Wohnzimmer?", während andere Skills zunächst explizit angesprochen werden müssen ("Alexa, frage FHEM nach der Temperatur im Wohnzimmer"). Außerdem kann der Nutzer mehrere Smarthome-Skills installieren, und die Geräte werden zu einer Gesamtmenge zusammengefasst.

Gehen wir den Datenfluss bei der konkreten Frage "Wie ist die Temperatur im Wohnzimmer?" durch:
* Alexa hat bei der Skillinstallation gelernt, dass "FHEM Connector" bei Dir einen Thermostaten im Raum Wohnzimmer kennt. Dadurch wird bei der Sprachanalyse von "Alexa Voice Service" in der Cloud erkannt, dass eine Abfrage an "FHEM Connector" erfolgversprechend ist.
* Zunächst wird die zentrale "Lambda-Funktion" von "FHEM Connector" aufgerufen. Die Funktion leitet aber im Kern nur den Request unverändert an den vom Verein bereitgestellten Server weiter. Im Request enthalten ist ein Token, das sogenannte "Bearer-Token".
* Der "Vereinsserver" prüft anhand dieses Tokens, ob es überhaupt bekannt ist, und zu welchem Nutzer es gehört. Ist dieser Nutzer verbunden, wird der Request wiederum quasi unverändert an den Nutzer weitergeleitet.
* Diese Weiterleitung passiert über einen sogenannten SSH-Reverse-Tunnel, der von Deiner Seite und der Software auf dem FHEM-Tunnel automatisch aufgebaut wird.
* Auf Deiner Seite läuft die eigentliche Software, und zwar unter nodeJS. nodeJS ist ein Javascript ausführender Miniserver, der lokal auf Port 3000 auf Requests "lauscht". In der Original-Version [[Alexa-Fhem|Alexa FHEM]] kommen die Requests aus dem Internet (hoffentlich von der eigenen Lambda-Funktion), hier bei "FHEM Connector" kommen sie ausschließlich aus dem SSH-Tunnel von lokal.
* Die Software validiert nun diesen Request anhand des Bearer-Tokens. Konkret wird dabei das bei der Installation generierte Token, dass bei der Skill-Aktivierung an Amazon übertragen wurde, mit dem lokal gespeicherten Wert verglichen. Stimmt das Token, wird der Befehl verarbeitet, üblicherweise wird hierbei ein Aufruf an die Webschnittstelle von FHEM abgesetzt.
* FHEM führt den Befehl aus

Hört sich langsam und kompliziert an? Kompliziert: Okay. Langsam eher nicht, in etlichen Fällen liegt die Gesamtantwortszeit unter 200 ms.

Soweit ein erster Überblick über die Datenflüsse. Im Abschnitt Sicherheit ist das Konzept der Absicherung deutlich genauer und ausführlicher beschrieben.

==Installation==

Du wirst bei der Installation zuerst auf der Kommandozeile auf Deinem Raspberry (o.ä.) unterwegs sein, anschließend im Webfrontend von FHEM, und zum Schluss auf der Alexa-Konsole im Web.

===node.js installieren===

Bei Jessy liegt NodeJS bereits in einer ausreichend aktuellen Version vor. Mit

<syntaxhighlight lang="bash" style="width:50%;">
sudo apt-get install nodejs npm
</syntaxhighlight>

kannst Du es installieren. Mit
<syntaxhighlight lang="bash" style="width:50%;">
node --version
</syntaxhighlight>

erfährst Du die aktuelle Version - wenn hier etwas mit "8" vorneweg erscheint, ist alles gut.
Ansonsten suche Dir bitte eine Anleitung im Web, wie Du NodeJS auf Deinem System auf einen aktuellen Stand bringen kannst.

=== Alexa-FHEM installieren ===

Nun installieren wir Alexa-fhem aus dem offiziellen Repository:

<syntaxhighlight lang="bash" style="width:50%;">
sudo npm install -g alexa-fhem
</syntaxhighlight>

Der Vorgang benötigt etwas Zeit.

=== Alexa-FHEM aktivieren ===

Wechsele jetzt in FHEM-Web!

Wichtig ist, dass das Alexa-Modul in der Version ab 14. Januar 2019 vorliegt. Dafür bitte einmal FHEM aktualisieren:
Speichern der Config nicht vergessen, und

<syntaxhighlight lang="bash" style="width:50%;">
update
shutdown restart
</syntaxhighlight>

Alles, was jetzt noch nötig ist, ist das Anlegen eines Alexa-Devices. Gib dafür in der FHEM-Web-Kommandozeile

<syntaxhighlight lang="bash" style="width:50%;">
define alexa alexa
</syntaxhighlight>

an. Nun läuft, während Du bereits das neu angelegte Alexa-Devices siehst, ein komplexer Prozess im Hintergrund:

* Falls noch kein SSH-Key für den Benutzer, unter dem FHEM läuft, existiert, wird einer generiert
* Es wird ein Secret-Key im Prozess generiert, dass den Server nicht verlässt, und der Skillanmeldung dient.
* Du wirst auf dem Server "va-fhem.fhem.de" des FHEM-Vereins mit dem SSH-Key angemeldet, und der Hash-Wert Deines Secret-Key dort abgelegt.

Und wenn Du diese Sätze gelesen hast, sollte inzwischen sich das Alexa-Device in FHEM-Web aktualisiert haben, und
ungefähr so aussehen:

[[Datei:Alexa-Device-2.png|800px]]

Neben dem Status für alexa-fhem und der Proxyverbindung ist wichtig, dass diese beiden Zeilen beim Reload aufgetaucht sind:

<syntaxhighlight lang="bash" style="width:90%;">
alexaFHEM.bearerToken crypt:...
alexaFHEM.skillRegKey crypt:...
</syntaxhighlight>

Ja, und diesen Schlüssel benötigst Du wirklich! Also am besten schon einmal mit

<syntaxhighlight lang="bash" style="width:90%;">
get <alexa> proxyKey
</syntaxhighlight>

in Klartext anzeigen lassen und in ein Editor-Fenster dauerhaft wegsichern.

Jetzt solltest Du Dein Alexa-Device nicht mehr löschen, denn das im Reading angezeigte "bearerToken" zu löschen bedeutet, dass die Software die Zugriffe von nicht mehr überprüfen kann und keine Kommandos mehr funktionieren. In diesem Fall hilft nur die Neuinstallation des Skills.

==== Fehler bei der Aktivierung ====

Während kompliziertere Fehlerfälle im Abschnitt "Mögliche Probleme und Lösungen" behandelt werden, hier häufige Fälle, warum die kryptischen Zeilen nicht auftauchen:

* Zuerst bitte einfach einmal die Seite neu laden.

===== 401: Authorization Required =====

Wenn Du FHEM-Web mit einem User/Passwort-Schutz versehen hast, wirst du folgende Fehlermeldung sehen:

<syntaxhighlight lang="bash" style="width:90%;">
alexaFHEM stopped; failed to connect to fhem: 401: Authorization Required
</syntaxhighlight>

In der Regel musst du die Angaben User/Passwort noch einmal explizit setzen. Im Attribute-Abschnitt "alexaFHEM-auth" auswählen, User/Passwort mit ":" getrennt angeben und "attr" anklicken. alexa-fhem wird automatisch neu gestartet. Hier das Ganze in der Text-Variante:

<syntaxhighlight lang="bash" style="width:90%;">
attr alexa alexaFHEM-auth user:pass
</syntaxhighlight>

===== Permission denied =====

Wenn du folgende Fehlermeldungen im Alexa Logfile siehst, wurde das Verzeichnis "/opt/fhem/.ssh/" von dir bei der Arbeit mit "root" oder "sudo" mit den falschen Berechtigungen versehen:

<syntaxhighlight lang="bash" style="width:90%;">
[2019-7-25 11:59:12] sshautoconf: aborted with ssh-keygen returned error - key_save_private: Permission denied
[2019-7-25 11:59:12] *** SSH: proxy configuration failed: ssh-keygen returned error - key_save_private: Permission denied
</syntaxhighlight>

Prüfen kannst du die Berechtigungen mit folgendem Befehl auf der Shell-Konsole:

<syntaxhighlight lang="bash" style="width:90%;">
ls -l /opt/fhem/.ssh
</syntaxhighlight>

Du solltest dann folgende Ausgabe erhalten:

<syntaxhighlight lang="bash" style="width:90%;">
insgesamt 12
-rw------- 1 fhem dialout 1675 Jul 12 13:10 id_rsa
-rw-r--r-- 1 fhem dialout 391 Jul 12 13:10 id_rsa.pub
-rw-r--r-- 1 fhem dialout 884 Jul 12 13:10 known_hosts
</syntaxhighlight>

Steht in der Ausgabe nicht "fhem dialout" (dein fhem User), sondern bspw. "root root", dann bspw. mit folgendem Befehl an deinen fhem User anpassen:

<syntaxhighlight lang="bash" style="width:90%;">
chown fhem:dialout /opt/fhem/.ssh
</syntaxhighlight>

Mit dem ersten Befehl "ls -l ..." kannst du dann nochmal prüfen, ob die Berechtigungen korrekt übernommen wurden.

===== weitere Prüfungen =====

Hast Du noch die Shell-Konsole offen? Dann prüfe bitte noch einmal auf der Konsole, ob nun zwei Prozesse laufen:

<syntaxhighlight lang="bash" style="width:50%;">
ps -ef | egrep '(alexa|ssh)'
</syntaxhighlight>

sollte Dir idealerweise so etwas anzeigen:
<syntaxhighlight lang="bash" style="width:90%;">
fhem 31322 1 99 13:56 ? 00:00:03 alexa
fhem 31332 31322 8 13:56 ? 00:00:00 /usr/bin/ssh -R 1234:127.0.0.1:<zufälliger port> -oServerAliveInterval=90 -p 58824 fhem-va.fhem.de
</syntaxhighlight>

"alexa" ist dabei der Node-JS-Prozess, der ssh-Prozess ist die aufgebaute Verbindung zum Vereinsserver.

Wenn Du diese Prozesse '''nicht''' siehst oder das Alexa-Device keinen Registrierungskey anzeigt, dann ist leider der Start nicht glatt verlaufen.

Im Logfile (über den link <code>Logfile</code> in der Detail-Ansicht über <code>set</Code>, oder über den Namen bei ''currentlogfile'' in den Internals) findest Du idealerweise selber Hinweise, wo es hakt, oder kannst im Forum nachfragen.

=== Geräte im FHEM-Webfrontend zuweisen ===
Um das Aha-Erlebnis zu vergrößern, ist jetzt ein guter Zeitpunkt, 1 oder besser mind. 2 Geräte für den Alexa-Dienst zuzuweisen. Von Haus aus wird keines Deiner FHEM-Geräte automatisch Alexa zugewiesen!

Wähle die Geräte aus, rufe sie auf und setze das Attribut "alexaName". Hierbei in Kürze nur der Hinweis:
* Keine Angst vor Leerzeichen und Umlauten, funktioniert.
* Große Angst vor Rechtschreibfehlern (Terrasse, Rollladen) oder komplizierten Wörtern "handgebastelte Martinslaterne im Kinderzimmer Iphigenie-Chantal".
* Das Attribut "alexaRoom" ist NUR FÜR DEN CUSTOM SKILL relevant. Ausnahme: structure und LightScene Devices, siehe: [[FHEM_Connector_f%C3%BCr_Amazon_Alexa#Was_geht_alles_.3F]].

Lade die Geräte neu in die Software, indem Du <code>set <alexa> restart</code> ausführst! 
 

''''Anmerkungen (weil oft gestellte Fragen im Forum) bzgl. erkennung von Geräten:''''

* Wichtig ist, dass die Filtereinstellung in der alexa-fhem.cfg (zu finden unter "Edit Files") passt.
Also was dort eingetragen ist (Standard: alexaName=..* / also es ist ein alexaName vergeben) auch an den entsrpechenden Devices in fhem vorhanden ist.
Stimmt das schon nicht überein, kann alexa-fhem schon mal keine Devices von fhem abfragen/finden.
Ob der Filter entsprechend funktioniert kann man wie folgt testen: ''list Filtereinstellung'' beispiel mit Standardfilter: ''list alexaName=..*''

* Hat alexa-fhem per Filter Devices aus fhem "gefunden", geht es weiter mit der "Erkennung". Also um welches Device (Typ und "Fähigkeiten") handelt es sich. Dazu gilt folgendes:
** sind entsprechende Readings beim Device vorhanden (z.B. temperature, state mit on/off, ...) erkennt das alexa-fhem automatisch. Die Liste der automatisch erkannten Readings wächst ständig. Daher erst mal schauen ob das Device bereits entsprechend erkannt (typisiert) wurde. Das kann durch prüfen des alexa-fhem-Logs geschehen (NICHT fhem-log!).
** sind entsprechende "set-Befehle" erkennbar (oft auch durch Readings). Also ist beispielsweise (wie beim Dummy nötig) ein ''setList'' mit entsprechenden Einträgen vorhanden oder entsprechende Readings, z.B. desired-temp zum Stellen der Temperatur etc.
** wird das Device nicht richtig oder "unvollständig" erkannt helfen folgende Attribute:
*** genericDeviceType: hiermit kann alexa-fhem in die gewünschte Richtung "geschubbst" werden. Anmerkung: man kann nicht alles erzwingen, Readings bzw. set-Befehle müssen passen (oder per homebridgeMapping passend gemacht werden). Wenn ein genericDeviceType nicht per "Drop-Down" erscheint, dann kann er auch (wenn bekannt) einfach per WEB-cmd eingegeben werden: ''attr Devicename genericDeviceType media''
*** homebridgeMapping: hierdurch kann alexa-fhem bei der Erkennung von Zuständen und möglichen Einstellungen (also WAS kann das Device) unterstützt werden. Mittels homebridgeMapping können vorhandene Readings (Zustände) auf für alexa-fhem bekannte Zustände gemappt werden. Ebenso können damit Standard-fhem-Kommandos von alexa-fhem auf Device-spezifische gemappt werden. Beispiel: on/off auf Ein/Aus (falls das Device statt on/off eben ein Ein/Aus erwartet) [Konkretes homebridgemapping als Beispiel FEHLT!!].

'''Anmerkung bzgl. genericDeviceType und homebridgeMapping:''' 
* diese Attribute werden von verschiedenen "Sprachsteuerungsmodulen" in fhem verwendet (homebridge [dort wurde es "erfunden"], alexa-fhem, gassistant, ...). Daher ist nicht jedes Mapping für alle "Dienste" verwendbar. Ausprobieren schadet aber nicht.
* ebenso kann man mit diesen Attributen (homebridgeMapping wird gerne so "missbraucht") nichts erzwingen, was seitens Amazon/Alexa nicht unterstützt bzw. verstanden wird! D.h. zunächst ist zu prüfen, ob ein bestimmter (gewünschter) Sprachbefehl seitens Amazon/Alexa unterstützt wird! Aktuelles Beispiel (Stand Jan 2020): "Alexa, fahre den Rollo hoch/runter". Da ist Amazon/Alexa gerade dabei etwas zu tun. Bislang wird das nicht unterstützt, also ist das auch mit einem entsprechenden homebridgeMapping nicht zu erzwingen! Was unterstützt wird kann man bei Amazon nachlesen: (LINK einfügen!!!)

== Finale: Skill verknüpfen ==
Suche im WebFrontend oder der Alexa-App den Skill "FHEM Connector". Für nicht-Mac/iOS Anwerder empfiehlt das WebFrontend (https://alexa.amazon.de) statt die App, damit Du den Anmeldeschlüssel auch bequem kopieren kannst.

Wenn du noch nicht bei Amazon angemeldet bist, erwartet Amazon zunächst, dass Du Dich normal bei Amazon anmeldest.

Sobald Du "FHEM Connector" aktivierst, öffnet sich ein Browser-Tab mit folgender Maske: 
[[Datei:FHEMlazy_login.png|240px]]

Hier kopierst Du Deinen Anmeldeschlüssel (im Klartext!) hinein und klickst auf Check. Als glücklicher Mensch ist auf der folgenden Statusseite alles grün: 
[[Datei:FHEMlazy_check.png|240px]]

Im Einzelnen wird hier geprüft, ob Du per SSH verbunden bist (und auch Deine IP zur Sicherheit angezeigt), ob der Reverse-Tunnel steht, ob nodeJS erreichbar ist und wie viele Geräte Alexa gleich finden sollte (in meinem Fall 22).

Sollte etwas nicht grün sein und Du eine Idee zum Fixen haben, kannst Du mit "Retry" neue Versuche auslösen.

Ist alles okay, klicke rechts den Button "Activate Skill". Du springst damit wieder zurück zu Amazon, die Dir hoffentlich zur erfolgreichen Verknüpfung gratulieren.

Amazon möchte nun unmittelbar die Gerätesuche starten, und unter SmartHome-Geräte sollten diese nun auftauchen.

== Was geht alles ? ==

* Geräte, die sich ein- und ausschalten lassen:
** Automatisch: Müssen <code>set on</code> und <code>set off</code> Kommandos haben
** dummys müssen <code>setList</code> mit on und off haben
** Über <code>genericDeviceType</code> switch bzw. light kann bestimmt werden ob es in alexa als Schalter oder Licht behandelt wird.
** Wenn die Set-Kommandos im FHEM Device anders benannt sind: hombridgeMapping On:cmdOn=<ein>,cmdOff=<aus> setzen
** Kommandos:
***Alexa, schalte <name> ein/aus
***Alexa, Licht an/aus
***Alexa, schalte <gruppe> ein/aus

* Geräte, die eine Temperatur messen
** Automatisch: Es muss ein Reading temperature geben
** Über <code>genericDeviceType</code> thermometer
** Sonst: hombridgeMapping CurrentTemperature:reading=<reading>

* Geräte, deren Helligkeit sich ändern lässt
** Automatisch: wenn <code>dim</code> oder <code>pct</code> Kommandos erkannt werden
** Über <code>genericDeviceType</code> light
** Über homebridgeMapping: Wenn <code>helligkeit</code> das Reading für die aktuelle Helligkeit enthält und die Helligkeit mit <code>set <device> prozent xxx</code> gesetzt wird, sieht das homebridgeMapping wie folgt aus:
*** homebridgeMapping Brightness=helligkeit::prozent,minValue=0,maxValue=<maximalwert>

**Kommandos:
***Alexa, mache <name> heller/dunkler
***Alexa, Licht heller/dunkler

* Geräte, deren Farbe sich ändern lässt
** ...

* Geräte, deren Farbtemperatur sich ändern lässt
** ...

* Geräte, bei denen sich eine Lautstärke einstellen lässt
** ...

* Geräte, bei denen sich ein prozentualer Wert einstellen lässt
** Automatisch: wenn <code>dim</code> oder <code>pct</code> Kommandos erkannt werden
** ...

* elektrische Türschlösser
** <code>genericDeviceType</code>: lock
** hombridgeMapping mit LockCurrentState und LockTargetState

* Thermostate
** Über <code>genericDeviceType</code> thermostate
** ...

* structure Devices aus FHEM (ab alexa-fhem version 0.5.7)
** können mit <code>genericDeviceType</code> scene als Szene eingebunden werden
** über <code>alexaRoom</code> kann der name um einen Ort ergänzt werden
** Szenen aus einer structure lassen sich ein- und ausschalten
** Wichtig:
*** Ein Skill darf nur 12 Szenen automatisch erkennen und einbinden.

* LightScene Devices aus FHEM (ab alexa-fhem version 0.5.8)
** können mit <code>genericDeviceType</code> scene als Szenen eingebunden werden
** über <code>alexaRoom</code> kann der name um einen Ort ergänzt werden
** Szenen aus einer LightScene lassen sich nur einschalten
** Wichtig:
*** Ein Skill darf nur 12 Szenen automatisch erkennen und einbinden.

* Geräte, deren Kanal sich umschalten lässt (ab alexa-fhem version 0.5.13)
** Über <code>genericDeviceType</code> media
** hombridgeMapping ChannelController:reading=<reading>,cmd=<cmd>
** Erlaubte Werte siehe hier: https://developer.amazon.com/de/docs/device-apis/alexa-channelcontroller.html#changechannel
** ...

* Geräte, deren Playback status sich schalten lässt (ab alexa-fhem version 0.5.13)
** Über <code>genericDeviceType</code> media
** hombridgeMapping PlaybackController:playback,values=Play;Pause;Stop;Previous;Next
** Erlaubte Werte siehe hier: https://developer.amazon.com/de/docs/device-apis/alexa-playbackcontroller.html#discovery
** ...

* Geräte, deren Eingang sich umschalten lässt (ab alexa-fhem version 0.5.13)
** Über <code>genericDeviceType</code> media
** hombridgeMapping InputController:reading=<reading>,cmd=<cmd>,values=HDMI+1;HDMI+2;XBOX
** Erlaubte Werte siehe hier: https://developer.amazon.com/de/docs/device-apis/alexa-property-schemas.html#input
** ...

* Kontaktsensoren (ab alexa-fhem version 0.5.15)
** Über <code>genericDeviceType</code> contact
** hombridgeMapping ContactSensorState:reading=<reading> oder CurrentDoorState:reading=<reading>
** Die Anzeige in der Alexa-App funktioniert sofort, die Abfrage per Sprache erst ab Version 0.5.27.

* Geräte, deren Lautstärke sich ändern lässt (ab alexa-fhem version 0.5.24)
** Über <code>genericDeviceType</code> speaker
** Automatisch: es muss ein Reading <code>volume</code> und/oder <code>mute</code> geben
** hombridgeMapping Volume:reading=<reading>,cmd=<cmd> Mute:reading=<reading>,cmd=<cmd>
** ...

* Geräte, die sich ein- (und optional) ausschalten lassen als Szene (ab alexa-fhem version 0.5.26)
** Über <code>genericDeviceType</code> scene
** Automatisch: Müssen <code>set on</code> und <code>set off</code> Kommandos haben
** hombridgeMapping On:reading=<reading>,cmdOn=<cmd>[,cmdOff=<cmd>]
** Hinweis: Fehlende Kommandos lassen sich mit cmdalias erzeugen
** Wichtig:
*** Ein Skill darf nur 12 Szenen automatisch erkennen und einbinden.

Es werden noch einige andere häufig verwendete Geräte (Homematic, hue,...) automatisch erkannt.

to be continued ...

In der [https://developer.amazon.com/docs/device-apis/list-of-interfaces.html List of Capability Interfaces] bei Amazon kann man sehen, welche Möglichkeiten das Smart Home Skill API aktuell in einzelnen Ländern bietet. Leider ohne die jeweiligen landessprachlichen Kommandos.

== Mögliche Probleme und Lösungen ==

Es kann vorkommen, dass Geräte zwar korrekt erkannt werden, aber das durch Alexa erkannte Kommando nicht richtig umgesetzt wird (Beispiel - mittlerweile behoben: {{Link2Forum|Topic=96766}}). Neben dem FHEM-Log gibt es noch das Logfile, welches von alexa-fhem angelegt wird.

=== Fehlersuche über die FHEM-Oberfläche ===

* alexa-fhem Logfile anschauen (Detail-Ansicht des <alexa>-Device aufrufen, klick auf '''Logfile''' oben)
* alexa-fhem im Debug-Modus aufrufen:
** -D zum alexaFHEM-params attribut hinzufügen
** Alexa-Befehl auslösen
** -D aus dem alexaFHEM-params attribut entfernen
* Die notwendigen Informationen finden sich in dem alexa-Logfile (siehe oben)

=== Fehlersuche über Kommandozeile (lies: Shell) + FHEM-Oberfläche ===

:* set <alexa> stop (FHEM-Oberfläche)
:* Auf der Kommandozeile <code>alexa-fhem -D -c /opt/fhem/alexa-fhem.cfg > debug.log</code> starten (dadurch wird die Datei debug.log erzeugt im aktuellen Verzeichnis)
:* Alexa-Befehl auslösen
:* alexa-fhem auf der Kommandozeile wieder stoppen (CTRL-C)
:* set <alexa> start (FHEM-Oberfläche)

Die Datei debug.log sollte Hinweise enthalten, wie das Problem zu lösen ist oder Dich zumindest in die richtige Richtung schieben.

Im Beispiel aus dem Forum fand sich in dem Logfile der Hinweis darauf, dass das Device mit falschen min/max-Werten unterwegs war.

=== Registrierungskey vergessen, Registrierung zurücksetzen ===

Auf der Kommandoshell:

<syntaxhighlight lang="bash" style="width:90%;">
pi@raspberrypi:~# sudo -u fhem ssh -p 58824 fhem-va.fhem.de status
Registered.
Registered on 2019-01-13T15:38:13Z.
</syntaxhighlight>

heisst, das der Vereinsserver eigentlich alles hat, was er will. Es wird kein neuer Schlüssel generiert.
Wenn Du die Situation zurücksetzen möchtest, wäre die hässliche Methode, Deinen SSH-Key zu löschen. Eleganter ist, die Registrierung auf Vereinsseite zu löschen:

<syntaxhighlight lang="bash" style="width:90%;">
pi@raspberrypi:~# sudo -u fhem ssh -p 58824 fhem-va.fhem.de unregister
Your registration has been removed
</syntaxhighlight>

löscht Deinen Schlüssel mitsamt allen dort gespeicherten Daten auf Vereinsseite. Bei Restart von alexa-fhem in FHEM-WEB wird jetzt ein neuer Registrierungskey angefordert.

== Sicherheitskonzept und Secrets ==

Um diesen Abschnitt zu verstehen, solltest Du den Abschnitt "Arbeitsweise" im Kopf haben. Einerseits ist Dir vermutlich einleuchtend, dass ein Server, der per SSH rückwärts nur ausgewählte Kommandos in den Tunnel, den Du aufgebaut hast, leitet, "irgendwie sicherer" ist. Andererseits möchte man nicht blind vertrauen.

=== SSH ===
==== SSH - macht das nichts Gefährliches? ====
SSH ist ein Veteran des Internet und entstand, um sich sicher (verschlüsselt) und schnell auf Servern einzuloggen. Schon früh wurde dabei der sogenannte "Reverse-Tunnel" implementiert: Also der vom Client (Deinem Rechner) geäußerte Wunsch: "Bitte leite mir Requests, die bei Dir, Server, auf Port xy eingehen, an meinen lokalen Port yz weiter.". Dieses Verfahren implementiert der Reverseproxy, wobei tatsächlich auf dem Server für Dich kein echter Port geöffnet wird.

Wie Dir ggf. sicher der Unix-Guru Deines Vertrauens bestätigen wird: Die Kombination
<syntaxhighlight lang="bash" style="width:50%;">
ssh -R 1234:localhost:<zufälliger port> zielserver
</syntaxhighlight>
erlaubt keine Ausführung von Shell-Kommandos auf Deinem Server, sondern einzig, dass vom SSH-Programm Verbindungen zu einem lokalen Port auf Deinem Server auf dem alexa-fhem lauscht aufgebaut werden. Du kannst also z.B. mit einem
<syntaxhighlight lang="bash" style="width:50%;">
sudo /usr/sbin/tcpdump -X -s 0 -i lo port <zufälliger port>
</syntaxhighlight>
vollständig überwachen (oder ggf. permanent aufzeichen), was auf Deinem Server von außen gesteuert passiert.

==== Wie wird bei SSH verschlüsselt? ====
Im Prinzip wie im Web auf SSL-Seiten, teils mit den gleichen Verschlüsselungsverfahren. Allerdings arbeitet SSH eher wie das im Web recht seltene Verfahren: Bei jeder Verbindung übermitteln sowohl Server wie auch Client den öffentlichen Teil ihres Schlüssels. Anders als im Web wird der Schlüssel aber nicht von einer öffentlichen Zertifizierungsstelle wie "LetsEncrypt" unterschrieben. Stattdessen entscheiden Server wie Client beim ersten Verbindungsaufbau typischerweise per manueller Frage: "Willst Du jetzt und künftig diesem Schlüssel vertrauen?" Bei der Installation wird diese Frage für Deine Seite bejaht, und fortan wird der öffentliche Schlüssel des FHEM-Servers auf Deinem Rechner gespeichert. Ab da bist Du z.B. davor sicher, dass jemand den DNS-Eintrag verbiegt oder sich in den Datenfluss Deines Providers einhängt: Ein geänderter Serverschlüssel würde bemerkt werden.
 
Soweit klar? Aus Deinem öffentlichen Schlüssel wiederum leitet der Server her: "Das ist definitiv wieder derjenige, der sich damals "registriert" hat". Und an dieser Stelle kann ich auch den ersten Teil des 3-teiligen Registrierungskeys erläutern: Die typischerweise 6-stellige Hex-Zahl am Anfang ist der Java-Hashcode Deines öffentlichen Schlüssel. Sie ist damit sozusagen Deine aus Deinem öffentlichen Schlüssel abgeleitete Benutzer-ID.

=== Die Rolle der Secrets ===
Wenn jetzt klar ist, dass die Verbindung zum Vereinsserver sicher und vertauschungsfrei funktioniert, bleiben noch 2 Probleme zu lösen:
1) Im Web bei der Skill-Aktivierung musst Du beweisen, dass Du der Mensch am Browser bist, dem der SSH-Tunnel von IP xy mit dem öffentlichen Schlüssel X gehört. Bei der automatischen Registrierung werden lokal auf Deinem Rechner zwei 64-Bit-Secrets generiert:
* Das Anmelde-Secret
* Das Bearer-Token
Beim Anmelden des SSH-Keys auf dem öffentlichen Server wird nun der Hashwert des ersten Secrets übertragen und dort in Verbindung mit Deinem öffentlichen Schlüssel gespeichert. Ein Hashwert bedeutet, dass (sofern das Verfahren, hier SHA256, funktioniert), niemand aus dem Hash das Secret zurückrechnen kann. Ein Datenbankklau auf dem Server gefährdet also nicht die Sicherheit Deines Passwortes.

Wenn Du nun beim Skill-Aktivieren den Registrierungskey eingibst, dann "sieht" der Server zum ersten Mal Dein ausgewürfeltes Secret, vergleicht es mit dem Hashwert und wird es anschließend wieder umgehend vergessen. Anhand des Hashwertes kann der Server aber entscheiden, dass Du der legitime Nutzer zum öffentlichen Schlüssel XY bist.

2) Das zweite Problem ist: Wie soll Amazon "beweisen", dass sie der legitime Aufrufer sind? Amazon erhält binnen wenigen Sekunden nach dem Klick auf "Activate Skill" den dritten Teil des Registrierungskeys als sogenanntes Bearer-Token. Zwar läuft er durch den Registrierungsserver, er wird dort, auf dem Registrierungs/Vereinsserver aber nicht gespeichert. Das Bearer-Token wird von Amazon bei allen Requests zu Deinem Server mitgesendet. Da es am Anfang zusätzlich Deine "User-ID" enthält, weiß der Vereinsserver, zu welchem SSH-Tunnel der Request zu senden ist. Aber lokal auf Deinem Rechner wird ausgewertet, ob das Token "stimmt".

== alexa-fhem Updaten ==
* alexa-fhem über FHEM anhalten:
:<syntaxhighlight lang="perl" style="width:50%;">set alexa stop</syntaxhighlight>

*Auf der Konsole wie anfangs bei der Installation:
:<syntaxhighlight lang="bash" style="width:50%;">sudo npm update -g alexa-fhem</syntaxhighlight>

:Manchmal hat npm Probleme mit einem Update. Dann einfach die aktuelle Version noch mal drüber Installieren:

:<syntaxhighlight lang="bash" style="width:50%;">sudo npm install -g alexa-fhem</syntaxhighlight>

*alexa-fhem über FHEM wieder starten:
:<syntaxhighlight lang="perl" style="width:50%;">set alexa start</syntaxhighlight>

== Bug- und Wunschliste ==
* Ist beim Start keine Internetverbindung vorhanden, erfolgt kein Retry -- alexa-fhem muss restartet werden (ssh_autoconfig wertet keine temporären Fehler aus)

==Weitergehende Informationen==
*[[Alexa und Mappings]]
*[[Alexa Tipps und Kniffe]]
*[[FHEM Connector for Amazon Alexa]]
[[Kategorie:HOWTOS]]
[[Kategorie:Sprachsteuerung]]

FHEM Connector für Amazon Alexa

2020-01-06T10:06:39Z

MadMax-FHEM: /* Geräte im FHEM-Webfrontend zuweisen */ Genauere Beschreibung wie alexa-fhem Geräte/Devices erkennt und entsprechend "typisiert"...

{{Baustelle}}
'''Alexa FHEMlazy''' war historisch ein Fork des Original [[Alexa-Fhem|alexa-fhem]], der im Januar 2019 mit dem Original zusammengeführt wurde und nun als '''FHEM Connector''' verfügbar ist.

Er ermöglicht innerhalb von Minuten die Verknüpfung von FHEM mit einem Amazon Echo Gerät. Auch Geräte anderer Hersteller mit verbauten Mikrofonen und Alexa-Sprachassistenten-Unterstützung sollten problemlos funktionieren. Für folgende Geräte ist dies bspw. der Fall (Falls Ihr andere/weitere Gerätemodelle bzw. Hersteller in Verwendung habt, bitte hier pflegen):

* SONOS Beam und SONOS One

Gegenüber dem klassischen Ansatz ergeben sich Einschränkungen, so läuft die Software normalerweise unter dem gleichen Benutzer wie FHEM auf dem gleichen Server, und es wird z.Zt. nur der Smarthome-Skill unterstützt (die Variante, bei der die Möglichkeiten der Interaktion von Amazon festgelegt wurden).
Dafür ist weder ein Developer-Account bei Amazon, eigene Lambda- und Skillfunktionen, noch das Öffnen eines eingehenden Ports aus dem Internet nötig.
* Die Software integriert einen Installer, der die Erstkonfiguration und Anmeldung übernimmt
* Die Kommunikation zur Software auf dem heimischen Rechner und dann zu FHEM verläuft über SSH und einen vom FHEM-Verein gehosteten Server
* Funktioniert mit IPv4, IPv6, echtem Dual Stack und DS-Lite
* Als Skill bei Amazon wird der Skill "FHEM Connector" verwendet.

Der Thread im Forum zur Software ist hier: {{Link2Forum|Topic=94817}}.

{{Infobox Modul
|ModPurpose=Einfache Anbindung von FHEM an Amazon Assistent Alexa
|ModType=h
|ModCmdRef=alexa
|ModTechName=39_alexa.pm / alexa-fhem
|ModForumArea=Frontends/Sprachsteuerung
|ModOwner=gvzdus, André/ justme1968 ({{Link2FU|430|Forum}} / [[Benutzer Diskussion:Justme|Wiki]])
}}

==Einführung==

===Arbeitsweise und Datenfluss===
Vorläufig ist alexa-fhem im "FHEM Connector-Modus" ein reiner [https://developer.amazon.com/de/docs/smarthome/understand-the-smart-home-skill-api.html SmartHome-Skill].
SmartHome-Skills erhalten weder die Sprachdaten selber noch das, was Amazon in Textform verstanden hat, sondern vielmehr extrahiert Amazon aus dem verstandenen Text Anweisungen und Abfragen für Geräte, die dann an den Skill übermittelt werden. Charmant ist dabei, dass unmittelbar gefragt werden kann "Alexa, wie ist die Temperatur im Wohnzimmer?", während andere Skills zunächst explizit angesprochen werden müssen ("Alexa, frage FHEM nach der Temperatur im Wohnzimmer"). Außerdem kann der Nutzer mehrere Smarthome-Skills installieren, und die Geräte werden zu einer Gesamtmenge zusammengefasst.

Gehen wir den Datenfluss bei der konkreten Frage "Wie ist die Temperatur im Wohnzimmer?" durch:
* Alexa hat bei der Skillinstallation gelernt, dass "FHEM Connector" bei Dir einen Thermostaten im Raum Wohnzimmer kennt. Dadurch wird bei der Sprachanalyse von "Alexa Voice Service" in der Cloud erkannt, dass eine Abfrage an "FHEM Connector" erfolgversprechend ist.
* Zunächst wird die zentrale "Lambda-Funktion" von "FHEM Connector" aufgerufen. Die Funktion leitet aber im Kern nur den Request unverändert an den vom Verein bereitgestellten Server weiter. Im Request enthalten ist ein Token, das sogenannte "Bearer-Token".
* Der "Vereinsserver" prüft anhand dieses Tokens, ob es überhaupt bekannt ist, und zu welchem Nutzer es gehört. Ist dieser Nutzer verbunden, wird der Request wiederum quasi unverändert an den Nutzer weitergeleitet.
* Diese Weiterleitung passiert über einen sogenannten SSH-Reverse-Tunnel, der von Deiner Seite und der Software auf dem FHEM-Tunnel automatisch aufgebaut wird.
* Auf Deiner Seite läuft die eigentliche Software, und zwar unter nodeJS. nodeJS ist ein Javascript ausführender Miniserver, der lokal auf Port 3000 auf Requests "lauscht". In der Original-Version [[Alexa-Fhem|Alexa FHEM]] kommen die Requests aus dem Internet (hoffentlich von der eigenen Lambda-Funktion), hier bei "FHEM Connector" kommen sie ausschließlich aus dem SSH-Tunnel von lokal.
* Die Software validiert nun diesen Request anhand des Bearer-Tokens. Konkret wird dabei das bei der Installation generierte Token, dass bei der Skill-Aktivierung an Amazon übertragen wurde, mit dem lokal gespeicherten Wert verglichen. Stimmt das Token, wird der Befehl verarbeitet, üblicherweise wird hierbei ein Aufruf an die Webschnittstelle von FHEM abgesetzt.
* FHEM führt den Befehl aus

Hört sich langsam und kompliziert an? Kompliziert: Okay. Langsam eher nicht, in etlichen Fällen liegt die Gesamtantwortszeit unter 200 ms.

Soweit ein erster Überblick über die Datenflüsse. Im Abschnitt Sicherheit ist das Konzept der Absicherung deutlich genauer und ausführlicher beschrieben.

==Installation==

Du wirst bei der Installation zuerst auf der Kommandozeile auf Deinem Raspberry (o.ä.) unterwegs sein, anschließend im Webfrontend von FHEM, und zum Schluss auf der Alexa-Konsole im Web.

===node.js installieren===

Bei Jessy liegt NodeJS bereits in einer ausreichend aktuellen Version vor. Mit

<syntaxhighlight lang="bash" style="width:50%;">
sudo apt-get install nodejs npm
</syntaxhighlight>

kannst Du es installieren. Mit
<syntaxhighlight lang="bash" style="width:50%;">
node --version
</syntaxhighlight>

erfährst Du die aktuelle Version - wenn hier etwas mit "8" vorneweg erscheint, ist alles gut.
Ansonsten suche Dir bitte eine Anleitung im Web, wie Du NodeJS auf Deinem System auf einen aktuellen Stand bringen kannst.

=== Alexa-FHEM installieren ===

Nun installieren wir Alexa-fhem aus dem offiziellen Repository:

<syntaxhighlight lang="bash" style="width:50%;">
sudo npm install -g alexa-fhem
</syntaxhighlight>

Der Vorgang benötigt etwas Zeit.

=== Alexa-FHEM aktivieren ===

Wechsele jetzt in FHEM-Web!

Wichtig ist, dass das Alexa-Modul in der Version ab 14. Januar 2019 vorliegt. Dafür bitte einmal FHEM aktualisieren:
Speichern der Config nicht vergessen, und

<syntaxhighlight lang="bash" style="width:50%;">
update
shutdown restart
</syntaxhighlight>

Alles, was jetzt noch nötig ist, ist das Anlegen eines Alexa-Devices. Gib dafür in der FHEM-Web-Kommandozeile

<syntaxhighlight lang="bash" style="width:50%;">
define alexa alexa
</syntaxhighlight>

an. Nun läuft, während Du bereits das neu angelegte Alexa-Devices siehst, ein komplexer Prozess im Hintergrund:

* Falls noch kein SSH-Key für den Benutzer, unter dem FHEM läuft, existiert, wird einer generiert
* Es wird ein Secret-Key im Prozess generiert, dass den Server nicht verlässt, und der Skillanmeldung dient.
* Du wirst auf dem Server "va-fhem.fhem.de" des FHEM-Vereins mit dem SSH-Key angemeldet, und der Hash-Wert Deines Secret-Key dort abgelegt.

Und wenn Du diese Sätze gelesen hast, sollte inzwischen sich das Alexa-Device in FHEM-Web aktualisiert haben, und
ungefähr so aussehen:

[[Datei:Alexa-Device-2.png|800px]]

Neben dem Status für alexa-fhem und der Proxyverbindung ist wichtig, dass diese beiden Zeilen beim Reload aufgetaucht sind:

<syntaxhighlight lang="bash" style="width:90%;">
alexaFHEM.bearerToken crypt:...
alexaFHEM.skillRegKey crypt:...
</syntaxhighlight>

Ja, und diesen Schlüssel benötigst Du wirklich! Also am besten schon einmal mit

<syntaxhighlight lang="bash" style="width:90%;">
get <alexa> proxyKey
</syntaxhighlight>

in Klartext anzeigen lassen und in ein Editor-Fenster dauerhaft wegsichern.

Jetzt solltest Du Dein Alexa-Device nicht mehr löschen, denn das im Reading angezeigte "bearerToken" zu löschen bedeutet, dass die Software die Zugriffe von nicht mehr überprüfen kann und keine Kommandos mehr funktionieren. In diesem Fall hilft nur die Neuinstallation des Skills.

==== Fehler bei der Aktivierung ====

Während kompliziertere Fehlerfälle im Abschnitt "Mögliche Probleme und Lösungen" behandelt werden, hier häufige Fälle, warum die kryptischen Zeilen nicht auftauchen:

* Zuerst bitte einfach einmal die Seite neu laden.

===== 401: Authorization Required =====

Wenn Du FHEM-Web mit einem User/Passwort-Schutz versehen hast, wirst du folgende Fehlermeldung sehen:

<syntaxhighlight lang="bash" style="width:90%;">
alexaFHEM stopped; failed to connect to fhem: 401: Authorization Required
</syntaxhighlight>

In der Regel musst du die Angaben User/Passwort noch einmal explizit setzen. Im Attribute-Abschnitt "alexaFHEM-auth" auswählen, User/Passwort mit ":" getrennt angeben und "attr" anklicken. alexa-fhem wird automatisch neu gestartet. Hier das Ganze in der Text-Variante:

<syntaxhighlight lang="bash" style="width:90%;">
attr alexa alexaFHEM-auth user:pass
</syntaxhighlight>

===== Permission denied =====

Wenn du folgende Fehlermeldungen im Alexa Logfile siehst, wurde das Verzeichnis "/opt/fhem/.ssh/" von dir bei der Arbeit mit "root" oder "sudo" mit den falschen Berechtigungen versehen:

<syntaxhighlight lang="bash" style="width:90%;">
[2019-7-25 11:59:12] sshautoconf: aborted with ssh-keygen returned error - key_save_private: Permission denied
[2019-7-25 11:59:12] *** SSH: proxy configuration failed: ssh-keygen returned error - key_save_private: Permission denied
</syntaxhighlight>

Prüfen kannst du die Berechtigungen mit folgendem Befehl auf der Shell-Konsole:

<syntaxhighlight lang="bash" style="width:90%;">
ls -l /opt/fhem/.ssh
</syntaxhighlight>

Du solltest dann folgende Ausgabe erhalten:

<syntaxhighlight lang="bash" style="width:90%;">
insgesamt 12
-rw------- 1 fhem dialout 1675 Jul 12 13:10 id_rsa
-rw-r--r-- 1 fhem dialout 391 Jul 12 13:10 id_rsa.pub
-rw-r--r-- 1 fhem dialout 884 Jul 12 13:10 known_hosts
</syntaxhighlight>

Steht in der Ausgabe nicht "fhem dialout" (dein fhem User), sondern bspw. "root root", dann bspw. mit folgendem Befehl an deinen fhem User anpassen:

<syntaxhighlight lang="bash" style="width:90%;">
chown fhem:dialout /opt/fhem/.ssh
</syntaxhighlight>

Mit dem ersten Befehl "ls -l ..." kannst du dann nochmal prüfen, ob die Berechtigungen korrekt übernommen wurden.

===== weitere Prüfungen =====

Hast Du noch die Shell-Konsole offen? Dann prüfe bitte noch einmal auf der Konsole, ob nun zwei Prozesse laufen:

<syntaxhighlight lang="bash" style="width:50%;">
ps -ef | egrep '(alexa|ssh)'
</syntaxhighlight>

sollte Dir idealerweise so etwas anzeigen:
<syntaxhighlight lang="bash" style="width:90%;">
fhem 31322 1 99 13:56 ? 00:00:03 alexa
fhem 31332 31322 8 13:56 ? 00:00:00 /usr/bin/ssh -R 1234:127.0.0.1:<zufälliger port> -oServerAliveInterval=90 -p 58824 fhem-va.fhem.de
</syntaxhighlight>

"alexa" ist dabei der Node-JS-Prozess, der ssh-Prozess ist die aufgebaute Verbindung zum Vereinsserver.

Wenn Du diese Prozesse '''nicht''' siehst oder das Alexa-Device keinen Registrierungskey anzeigt, dann ist leider der Start nicht glatt verlaufen.

Im Logfile (über den link <code>Logfile</code> in der Detail-Ansicht über <code>set</Code>, oder über den Namen bei ''currentlogfile'' in den Internals) findest Du idealerweise selber Hinweise, wo es hakt, oder kannst im Forum nachfragen.

=== Geräte im FHEM-Webfrontend zuweisen ===
Um das Aha-Erlebnis zu vergrößern, ist jetzt ein guter Zeitpunkt, 1 oder besser mind. 2 Geräte für den Alexa-Dienst zuzuweisen. Von Haus aus wird keines Deiner FHEM-Geräte automatisch Alexa zugewiesen!

Wähle die Geräte aus, rufe sie auf und setze das Attribut "alexaName". Hierbei in Kürze nur der Hinweis:
* Keine Angst vor Leerzeichen und Umlauten, funktioniert.
* Große Angst vor Rechtschreibfehlern (Terrasse, Rollladen) oder komplizierten Wörtern "handgebastelte Martinslaterne im Kinderzimmer Iphigenie-Chantal".
* Das Attribut "alexaRoom" ist NUR FÜR DEN CUSTOM SKILL relevant. Ausnahme: structure und LightScene Devices, siehe: [[FHEM_Connector_f%C3%BCr_Amazon_Alexa#Was_geht_alles_.3F]].

Lade die Geräte neu in die Software, indem Du <code>set <alexa> restart</code> ausführst!

Anmerkungen (weil oft gestellte Fragen im Forum) bzgl. erkennung von Geräten:

* Wichtig ist, dass die Filtereinstellung in der alexa-fhem.cfg (zu finden unter "Edit Files") passt.
Also was dort eingetragen ist (Standard: alexaName=..* / also es ist ein alexaName vergeben) auch an den entsrpechenden Devices in fhem vorhanden ist.
Stimmt das schon nicht überein, kann alexa-fhem schon mal keine Devices von fhem abfragen/finden.
Ob der Filter entsprechend funktioniert kann man wie folgt testen: ''list Filtereinstellung'' beispiel mit Standardfilter: ''list alexaName=..*''

* Hat alexa-fhem per Filter Devices aus fhem "gefunden", geht es weiter mit der "Erkennung". Also um welches Device (Typ und "Fähigkeiten") handelt es sich. Dazu gilt folgendes:
** sind entsprechende Readings beim Device vorhanden (z.B. temperature, state mit on/off, ...) erkennt das alexa-fhem automatisch. Die Liste der automatisch erkannten Readings wächst ständig. Daher erst mal schauen ob das Device bereits entsprechend erkannt (typisiert) wurde. Das kann durch prüfen des alexa-fhem-Logs geschehen (NICHT fhem-log!).
** sind entsprechende "set-Befehle" erkennbar (oft auch durch Readings). Also ist beispielsweise (wie beim Dummy nötig) ein ''setList'' mit entsprechenden Einträgen vorhanden oder entsprechende Readings, z.B. desired-temp zum Stellen der Temperatur etc.
** wird das Device nicht richtig oder "unvollständig" erkannt helfen folgende Attribute:
*** genericDeviceType: hiermit kann alexa-fhem in die gewünschte Richtung "geschubbst" werden. Anmerkung: man kann nicht alles erzwingen, Readings bzw. set-Befehle müssen passen (oder per homebridgeMapping passend gemacht werden). Wenn ein genericDeviceType nicht per "Drop-Down" erscheint, dann kann er auch (wenn bekannt) einfach per WEB-cmd eingegeben werden: ''attr Devicename genericDeviceType media''
*** homebridgeMapping: hierdurch kann alexa-fhem bei der Erkennung von Zuständen und möglichen Einstellungen (also WAS kann das Device) unterstützt werden. Mittels homebridgeMapping können vorhandene Readings (Zustände) auf für alexa-fhem bekannte Zustände gemappt werden. Ebenso können damit Standard-fhem-Kommandos von alexa-fhem auf Device-spezifische gemappt werden. Beispiel: on/off auf Ein/Aus (falls das Device statt on/off eben ein Ein/Aus erwartet) [Konkretes homebridgemapping als Beispiel FEHLT!!].

'''Anmerkung bzgl. genericDeviceType und homebridgeMapping:''' 
* diese Attribute werden von verschiedenen "Sprachsteuerungsmodulen" in fhem verwendet (homebridge [dort wurde es "erfunden"], alexa-fhem, gassistant, ...). Daher ist nicht jedes Mapping für alle "Dienste" verwendbar. Ausprobieren schadet aber nicht.
* ebenso kann man mit diesen Attributen (homebridgeMapping wird gerne so "missbraucht") nichts erzwingen, was seitens Amazon/Alexa nicht unterstützt bzw. verstanden wird! D.h. zunächst ist zu prüfen, ob ein bestimmter (gewünschter) Sprachbefehl seitens Amazon/Alexa unterstützt wird! Aktuelles Beispiel (Stand Jan 2020): "Alexa, fahre den Rollo hoch/runter". Da ist Amazon/Alexa gerade dabei etwas zu tun. Bislang wird das nicht unterstützt, also ist das auch mit einem entsprechenden homebridgeMapping nicht zu erzwingen! Was unterstützt wird kann man bei Amazon nachlesen: (LINK einfügen!!!)

== Finale: Skill verknüpfen ==
Suche im WebFrontend oder der Alexa-App den Skill "FHEM Connector". Für nicht-Mac/iOS Anwerder empfiehlt das WebFrontend (https://alexa.amazon.de) statt die App, damit Du den Anmeldeschlüssel auch bequem kopieren kannst.

Wenn du noch nicht bei Amazon angemeldet bist, erwartet Amazon zunächst, dass Du Dich normal bei Amazon anmeldest.

Sobald Du "FHEM Connector" aktivierst, öffnet sich ein Browser-Tab mit folgender Maske: 
[[Datei:FHEMlazy_login.png|240px]]

Hier kopierst Du Deinen Anmeldeschlüssel (im Klartext!) hinein und klickst auf Check. Als glücklicher Mensch ist auf der folgenden Statusseite alles grün: 
[[Datei:FHEMlazy_check.png|240px]]

Im Einzelnen wird hier geprüft, ob Du per SSH verbunden bist (und auch Deine IP zur Sicherheit angezeigt), ob der Reverse-Tunnel steht, ob nodeJS erreichbar ist und wie viele Geräte Alexa gleich finden sollte (in meinem Fall 22).

Sollte etwas nicht grün sein und Du eine Idee zum Fixen haben, kannst Du mit "Retry" neue Versuche auslösen.

Ist alles okay, klicke rechts den Button "Activate Skill". Du springst damit wieder zurück zu Amazon, die Dir hoffentlich zur erfolgreichen Verknüpfung gratulieren.

Amazon möchte nun unmittelbar die Gerätesuche starten, und unter SmartHome-Geräte sollten diese nun auftauchen.

== Was geht alles ? ==

* Geräte, die sich ein- und ausschalten lassen:
** Automatisch: Müssen <code>set on</code> und <code>set off</code> Kommandos haben
** dummys müssen <code>setList</code> mit on und off haben
** Über <code>genericDeviceType</code> switch bzw. light kann bestimmt werden ob es in alexa als Schalter oder Licht behandelt wird.
** Wenn die Set-Kommandos im FHEM Device anders benannt sind: hombridgeMapping On:cmdOn=<ein>,cmdOff=<aus> setzen
** Kommandos:
***Alexa, schalte <name> ein/aus
***Alexa, Licht an/aus
***Alexa, schalte <gruppe> ein/aus

* Geräte, die eine Temperatur messen
** Automatisch: Es muss ein Reading temperature geben
** Über <code>genericDeviceType</code> thermometer
** Sonst: hombridgeMapping CurrentTemperature:reading=<reading>

* Geräte, deren Helligkeit sich ändern lässt
** Automatisch: wenn <code>dim</code> oder <code>pct</code> Kommandos erkannt werden
** Über <code>genericDeviceType</code> light
** Über homebridgeMapping: Wenn <code>helligkeit</code> das Reading für die aktuelle Helligkeit enthält und die Helligkeit mit <code>set <device> prozent xxx</code> gesetzt wird, sieht das homebridgeMapping wie folgt aus:
*** homebridgeMapping Brightness=helligkeit::prozent,minValue=0,maxValue=<maximalwert>

**Kommandos:
***Alexa, mache <name> heller/dunkler
***Alexa, Licht heller/dunkler

* Geräte, deren Farbe sich ändern lässt
** ...

* Geräte, deren Farbtemperatur sich ändern lässt
** ...

* Geräte, bei denen sich eine Lautstärke einstellen lässt
** ...

* Geräte, bei denen sich ein prozentualer Wert einstellen lässt
** Automatisch: wenn <code>dim</code> oder <code>pct</code> Kommandos erkannt werden
** ...

* elektrische Türschlösser
** <code>genericDeviceType</code>: lock
** hombridgeMapping mit LockCurrentState und LockTargetState

* Thermostate
** Über <code>genericDeviceType</code> thermostate
** ...

* structure Devices aus FHEM (ab alexa-fhem version 0.5.7)
** können mit <code>genericDeviceType</code> scene als Szene eingebunden werden
** über <code>alexaRoom</code> kann der name um einen Ort ergänzt werden
** Szenen aus einer structure lassen sich ein- und ausschalten
** Wichtig:
*** Ein Skill darf nur 12 Szenen automatisch erkennen und einbinden.

* LightScene Devices aus FHEM (ab alexa-fhem version 0.5.8)
** können mit <code>genericDeviceType</code> scene als Szenen eingebunden werden
** über <code>alexaRoom</code> kann der name um einen Ort ergänzt werden
** Szenen aus einer LightScene lassen sich nur einschalten
** Wichtig:
*** Ein Skill darf nur 12 Szenen automatisch erkennen und einbinden.

* Geräte, deren Kanal sich umschalten lässt (ab alexa-fhem version 0.5.13)
** Über <code>genericDeviceType</code> media
** hombridgeMapping ChannelController:reading=<reading>,cmd=<cmd>
** Erlaubte Werte siehe hier: https://developer.amazon.com/de/docs/device-apis/alexa-channelcontroller.html#changechannel
** ...

* Geräte, deren Playback status sich schalten lässt (ab alexa-fhem version 0.5.13)
** Über <code>genericDeviceType</code> media
** hombridgeMapping PlaybackController:playback,values=Play;Pause;Stop;Previous;Next
** Erlaubte Werte siehe hier: https://developer.amazon.com/de/docs/device-apis/alexa-playbackcontroller.html#discovery
** ...

* Geräte, deren Eingang sich umschalten lässt (ab alexa-fhem version 0.5.13)
** Über <code>genericDeviceType</code> media
** hombridgeMapping InputController:reading=<reading>,cmd=<cmd>,values=HDMI+1;HDMI+2;XBOX
** Erlaubte Werte siehe hier: https://developer.amazon.com/de/docs/device-apis/alexa-property-schemas.html#input
** ...

* Kontaktsensoren (ab alexa-fhem version 0.5.15)
** Über <code>genericDeviceType</code> contact
** hombridgeMapping ContactSensorState:reading=<reading> oder CurrentDoorState:reading=<reading>
** Die Anzeige in der Alexa-App funktioniert sofort, die Abfrage per Sprache erst ab Version 0.5.27.

* Geräte, deren Lautstärke sich ändern lässt (ab alexa-fhem version 0.5.24)
** Über <code>genericDeviceType</code> speaker
** Automatisch: es muss ein Reading <code>volume</code> und/oder <code>mute</code> geben
** hombridgeMapping Volume:reading=<reading>,cmd=<cmd> Mute:reading=<reading>,cmd=<cmd>
** ...

* Geräte, die sich ein- (und optional) ausschalten lassen als Szene (ab alexa-fhem version 0.5.26)
** Über <code>genericDeviceType</code> scene
** Automatisch: Müssen <code>set on</code> und <code>set off</code> Kommandos haben
** hombridgeMapping On:reading=<reading>,cmdOn=<cmd>[,cmdOff=<cmd>]
** Hinweis: Fehlende Kommandos lassen sich mit cmdalias erzeugen
** Wichtig:
*** Ein Skill darf nur 12 Szenen automatisch erkennen und einbinden.

Es werden noch einige andere häufig verwendete Geräte (Homematic, hue,...) automatisch erkannt.

to be continued ...

In der [https://developer.amazon.com/docs/device-apis/list-of-interfaces.html List of Capability Interfaces] bei Amazon kann man sehen, welche Möglichkeiten das Smart Home Skill API aktuell in einzelnen Ländern bietet. Leider ohne die jeweiligen landessprachlichen Kommandos.

== Mögliche Probleme und Lösungen ==

Es kann vorkommen, dass Geräte zwar korrekt erkannt werden, aber das durch Alexa erkannte Kommando nicht richtig umgesetzt wird (Beispiel - mittlerweile behoben: {{Link2Forum|Topic=96766}}). Neben dem FHEM-Log gibt es noch das Logfile, welches von alexa-fhem angelegt wird.

=== Fehlersuche über die FHEM-Oberfläche ===

* alexa-fhem Logfile anschauen (Detail-Ansicht des <alexa>-Device aufrufen, klick auf '''Logfile''' oben)
* alexa-fhem im Debug-Modus aufrufen:
** -D zum alexaFHEM-params attribut hinzufügen
** Alexa-Befehl auslösen
** -D aus dem alexaFHEM-params attribut entfernen
* Die notwendigen Informationen finden sich in dem alexa-Logfile (siehe oben)

=== Fehlersuche über Kommandozeile (lies: Shell) + FHEM-Oberfläche ===

:* set <alexa> stop (FHEM-Oberfläche)
:* Auf der Kommandozeile <code>alexa-fhem -D -c /opt/fhem/alexa-fhem.cfg > debug.log</code> starten (dadurch wird die Datei debug.log erzeugt im aktuellen Verzeichnis)
:* Alexa-Befehl auslösen
:* alexa-fhem auf der Kommandozeile wieder stoppen (CTRL-C)
:* set <alexa> start (FHEM-Oberfläche)

Die Datei debug.log sollte Hinweise enthalten, wie das Problem zu lösen ist oder Dich zumindest in die richtige Richtung schieben.

Im Beispiel aus dem Forum fand sich in dem Logfile der Hinweis darauf, dass das Device mit falschen min/max-Werten unterwegs war.

=== Registrierungskey vergessen, Registrierung zurücksetzen ===

Auf der Kommandoshell:

<syntaxhighlight lang="bash" style="width:90%;">
pi@raspberrypi:~# sudo -u fhem ssh -p 58824 fhem-va.fhem.de status
Registered.
Registered on 2019-01-13T15:38:13Z.
</syntaxhighlight>

heisst, das der Vereinsserver eigentlich alles hat, was er will. Es wird kein neuer Schlüssel generiert.
Wenn Du die Situation zurücksetzen möchtest, wäre die hässliche Methode, Deinen SSH-Key zu löschen. Eleganter ist, die Registrierung auf Vereinsseite zu löschen:

<syntaxhighlight lang="bash" style="width:90%;">
pi@raspberrypi:~# sudo -u fhem ssh -p 58824 fhem-va.fhem.de unregister
Your registration has been removed
</syntaxhighlight>

löscht Deinen Schlüssel mitsamt allen dort gespeicherten Daten auf Vereinsseite. Bei Restart von alexa-fhem in FHEM-WEB wird jetzt ein neuer Registrierungskey angefordert.

== Sicherheitskonzept und Secrets ==

Um diesen Abschnitt zu verstehen, solltest Du den Abschnitt "Arbeitsweise" im Kopf haben. Einerseits ist Dir vermutlich einleuchtend, dass ein Server, der per SSH rückwärts nur ausgewählte Kommandos in den Tunnel, den Du aufgebaut hast, leitet, "irgendwie sicherer" ist. Andererseits möchte man nicht blind vertrauen.

=== SSH ===
==== SSH - macht das nichts Gefährliches? ====
SSH ist ein Veteran des Internet und entstand, um sich sicher (verschlüsselt) und schnell auf Servern einzuloggen. Schon früh wurde dabei der sogenannte "Reverse-Tunnel" implementiert: Also der vom Client (Deinem Rechner) geäußerte Wunsch: "Bitte leite mir Requests, die bei Dir, Server, auf Port xy eingehen, an meinen lokalen Port yz weiter.". Dieses Verfahren implementiert der Reverseproxy, wobei tatsächlich auf dem Server für Dich kein echter Port geöffnet wird.

Wie Dir ggf. sicher der Unix-Guru Deines Vertrauens bestätigen wird: Die Kombination
<syntaxhighlight lang="bash" style="width:50%;">
ssh -R 1234:localhost:<zufälliger port> zielserver
</syntaxhighlight>
erlaubt keine Ausführung von Shell-Kommandos auf Deinem Server, sondern einzig, dass vom SSH-Programm Verbindungen zu einem lokalen Port auf Deinem Server auf dem alexa-fhem lauscht aufgebaut werden. Du kannst also z.B. mit einem
<syntaxhighlight lang="bash" style="width:50%;">
sudo /usr/sbin/tcpdump -X -s 0 -i lo port <zufälliger port>
</syntaxhighlight>
vollständig überwachen (oder ggf. permanent aufzeichen), was auf Deinem Server von außen gesteuert passiert.

==== Wie wird bei SSH verschlüsselt? ====
Im Prinzip wie im Web auf SSL-Seiten, teils mit den gleichen Verschlüsselungsverfahren. Allerdings arbeitet SSH eher wie das im Web recht seltene Verfahren: Bei jeder Verbindung übermitteln sowohl Server wie auch Client den öffentlichen Teil ihres Schlüssels. Anders als im Web wird der Schlüssel aber nicht von einer öffentlichen Zertifizierungsstelle wie "LetsEncrypt" unterschrieben. Stattdessen entscheiden Server wie Client beim ersten Verbindungsaufbau typischerweise per manueller Frage: "Willst Du jetzt und künftig diesem Schlüssel vertrauen?" Bei der Installation wird diese Frage für Deine Seite bejaht, und fortan wird der öffentliche Schlüssel des FHEM-Servers auf Deinem Rechner gespeichert. Ab da bist Du z.B. davor sicher, dass jemand den DNS-Eintrag verbiegt oder sich in den Datenfluss Deines Providers einhängt: Ein geänderter Serverschlüssel würde bemerkt werden.
 
Soweit klar? Aus Deinem öffentlichen Schlüssel wiederum leitet der Server her: "Das ist definitiv wieder derjenige, der sich damals "registriert" hat". Und an dieser Stelle kann ich auch den ersten Teil des 3-teiligen Registrierungskeys erläutern: Die typischerweise 6-stellige Hex-Zahl am Anfang ist der Java-Hashcode Deines öffentlichen Schlüssel. Sie ist damit sozusagen Deine aus Deinem öffentlichen Schlüssel abgeleitete Benutzer-ID.

=== Die Rolle der Secrets ===
Wenn jetzt klar ist, dass die Verbindung zum Vereinsserver sicher und vertauschungsfrei funktioniert, bleiben noch 2 Probleme zu lösen:
1) Im Web bei der Skill-Aktivierung musst Du beweisen, dass Du der Mensch am Browser bist, dem der SSH-Tunnel von IP xy mit dem öffentlichen Schlüssel X gehört. Bei der automatischen Registrierung werden lokal auf Deinem Rechner zwei 64-Bit-Secrets generiert:
* Das Anmelde-Secret
* Das Bearer-Token
Beim Anmelden des SSH-Keys auf dem öffentlichen Server wird nun der Hashwert des ersten Secrets übertragen und dort in Verbindung mit Deinem öffentlichen Schlüssel gespeichert. Ein Hashwert bedeutet, dass (sofern das Verfahren, hier SHA256, funktioniert), niemand aus dem Hash das Secret zurückrechnen kann. Ein Datenbankklau auf dem Server gefährdet also nicht die Sicherheit Deines Passwortes.

Wenn Du nun beim Skill-Aktivieren den Registrierungskey eingibst, dann "sieht" der Server zum ersten Mal Dein ausgewürfeltes Secret, vergleicht es mit dem Hashwert und wird es anschließend wieder umgehend vergessen. Anhand des Hashwertes kann der Server aber entscheiden, dass Du der legitime Nutzer zum öffentlichen Schlüssel XY bist.

2) Das zweite Problem ist: Wie soll Amazon "beweisen", dass sie der legitime Aufrufer sind? Amazon erhält binnen wenigen Sekunden nach dem Klick auf "Activate Skill" den dritten Teil des Registrierungskeys als sogenanntes Bearer-Token. Zwar läuft er durch den Registrierungsserver, er wird dort, auf dem Registrierungs/Vereinsserver aber nicht gespeichert. Das Bearer-Token wird von Amazon bei allen Requests zu Deinem Server mitgesendet. Da es am Anfang zusätzlich Deine "User-ID" enthält, weiß der Vereinsserver, zu welchem SSH-Tunnel der Request zu senden ist. Aber lokal auf Deinem Rechner wird ausgewertet, ob das Token "stimmt".

== alexa-fhem Updaten ==
* alexa-fhem über FHEM anhalten:
:<syntaxhighlight lang="perl" style="width:50%;">set alexa stop</syntaxhighlight>

*Auf der Konsole wie anfangs bei der Installation:
:<syntaxhighlight lang="bash" style="width:50%;">sudo npm update -g alexa-fhem</syntaxhighlight>

:Manchmal hat npm Probleme mit einem Update. Dann einfach die aktuelle Version noch mal drüber Installieren:

:<syntaxhighlight lang="bash" style="width:50%;">sudo npm install -g alexa-fhem</syntaxhighlight>

*alexa-fhem über FHEM wieder starten:
:<syntaxhighlight lang="perl" style="width:50%;">set alexa start</syntaxhighlight>

== Bug- und Wunschliste ==
* Ist beim Start keine Internetverbindung vorhanden, erfolgt kein Retry -- alexa-fhem muss restartet werden (ssh_autoconfig wertet keine temporären Fehler aus)

==Weitergehende Informationen==
*[[Alexa und Mappings]]
*[[Alexa Tipps und Kniffe]]
*[[FHEM Connector for Amazon Alexa]]
[[Kategorie:HOWTOS]]
[[Kategorie:Sprachsteuerung]]

Google Assistant FHEM Connect

2019-02-05T22:21:49Z

MadMax-FHEM: Typo: realRool -> realRoom

'''FHEM Connect''' ist eine Weiterentwicklung von [[Alexa-Fhem|Alexa FHEM]] speziell für den Google Assistant. Mit FHEM Connect ist die Verknüpfung von FHEM und dem Google Assistant in wenigen Schritten getan. Damit kannst du Geräte die in FHEM verwaltet werden auch über den Google Assistant von beliebigen Geräten mit Google Assistant Support steuern.

Es sind keine großen Einrichtungen dafür notwendig und die Verbindung zwischen Google und deinem Client ist ebenso gesichert.

ACHTUNG!!! FHEM muß zwingend aktuell sein. Update > 03.02.2019

{{Infobox Modul
|ModPurpose=Anbindung von FHEM an Google Assistant
|ModType=x
|ModTechName=
|ModForumArea=Frontends/Sprachsteuerung
|ModOwner=dominik
}}

==Hintergrundinfos==
FHEM Connect basiert auf Google Firebase, welches die Plattform für die Kommunikation mit Google bietet. Der lokal installierte fhemconnect Client kommuniziert mit Google Firebase und übermittelt von dort die Daten an Google. Das hat 3 große Vorteile:
* Keine Portfreigaben notwendig
* Kommunikation läuft gesichert über HTTPS und die Authentifizierung über Auth0 mittels OAuth2
* Neue Funktionalitäten, wie zum Beispiel die Unterstützung von neuen Devices, sind immer gleich verfügbar sobald diese im Firebase Projekt implementiert wurden. Man muss also nicht regelmäßig aktualisieren um in den Genuss von neuen Google Assistant Features zu kommen.

==Unterstütze Geräte==
Google unterscheidet zwischen Traits und Device Types. Traits sind Funktionen (on/off, dimmen, ...) die ein Geräte beliebigen Typs unterstützen kann. Device Types dienen nur zur Darstellung in der Home App und der Steuerung über den Gerätetyp per Sprache (z.B. "Schalte die Waschmaschine ein", der Name der Waschmaschine muss nicht genannt werden).

Die gesamte Liste der von Google bereitgestellten Traits findet man hier: https://developers.google.com/actions/smarthome/traits/

Folgende Traits werden durch Google Assistant FHEM Connect unterstützt:
* Brightness
* ColorSetting
* Dock
* FanSpeed (nur Englisch)
* Locator
* Modes (nur Englisch)
* OnOff
* Scene
* StartStop
* TemperatureSetting
* Toggles (nur Englisch)

Die gesamte Liste der von Google unterstützten Device Types findet man hier: https://developers.google.com/actions/smarthome/guides/
Der Device Type wird automatisch erkannt. Ist dieser nicht passend, kann man folgende Device Types über genericDeviceType setzen:
* switch
* outlet
* light
* thermostat
* aircondition
* airpurifier
* camera
* coffeemaker
* dishwasher
* dryer
* fan
* kettle
* oven
* refrigerator
* scene
* sprinkler
* vacuum
* washer

Um ein einfaches dummy Device in Google Assistant zu integrieren, benötigt es nur ein on,off Command (nicht webCmd, sondern setList!!).

==Attribute==
Folgende Attribute werden von Google Assistant FHEM Connection genutzt:
* genericDeviceType
* assistantName (Name des Devices bei Google, soll zukünftig auch von anderen Assistenten benutzt werden)
* gassistantName (Name des Devices bei Google)
* realRoom (Raum welcher beim ERSTEN Synchronisieren an Google übergeben wird)
* homebridgeMapping (Bitte nur verwenden, wenn es ohne homebridgeMapping nicht funktioniert)

==Installation (Kurzanleitung)==
Wichtig: Aktuell ist der Google Action noch im Beta Test und ihr müsst daher als Tester mit eurer GMail Adresse mit aufgenommen werden. Schickt mir dazu eine kurze private Nachricht im FHEM Forum ([https://forum.fhem.de/index.php?action=profile;u=15803 dominik]) mit eurer GMail Adresse. Sobald ich diese hinzugefügt habe, könnt ihr den Action in der Google Home App sehen.

'''Bevor ihr die Befehle unten ausführt, müsst ihr das Testaction aktivieren. Dazu bitte auf folgenden Link klicken:
'''

https://console.actions.google.com/project/fhem-connector-beta/simulatorcreate?isDeepLink

* Raspbian/Debian stretch ist Vorraussetzung, jessie wird nicht supported
* FHEM mit "update all" auf den letzten Stand bringen
<syntaxhighlight lang="bash" style="width:70%;">
sudo npm install -g gassistant-fhem --unsafe-perm
define gassistant gassistant
</syntaxhighlight>
* Ca. 30s warten bis ein Reading gassistantFHEM.loginURL erscheint
* Link öffnen und einloggen
* Den erhaltenen authcode in FHEM hinterlegen (set gassistant authcode ...)

* /opt/fhem/FHEM/gassistant-fhem.cfg bei Bedarf anpassen
* Geräte in den in der gassistant-fhem.cfg definierten Raum verschieben

==Architektur==
* fhemconnect Client
Lokale installierter Client der die Verbindung zu FHEM herstellt.

* Auth0
Auth0 wird sowohl von fhemconnect Client als auch von Google Assistant genutzt um den User zu authentifizieren. Damit erhält der User eine eindeutigen User ID.

* Firebase ("zentralerer Server", obwohl es Server-less betrieben wird)

* Firebase Firestore
Datenbank in welcher die Geräteinformationen gespeichert werden.

* Firebase Realtime DB
Datenbank in welcher der aktuelle Status der Geräte gespeichert wird.

* Firebase Cloud Functions
Die Cloud Function stellt einen Webaufruf im Internet zur Verfügung. Google ruft direkt eine solche Cloud Function auf. Des Weiteren wird diese auch für die Kommunikation vom fhemconnect Client zum Firebase Projekt ("Server") genutzt.

Die Dienste auth0 und Google Firebase wurden beide als EU Instanzen konfiguriert. Eure Daten liegen daher im EU Raum und unterliegen damit auch den EU Datenschutzvorgaben.

==Datenfluss==
Der Datenfluss und die Arbeitsweise von FHEM Connect wird anhand des folgenden Beispiels erklärt:
* Bei der Verknüpfung des Google Accounts mit FHEM Connect wird der Service von auth0 herangezogen. Dieser authentifiziert den User und generiert einen Access und Refresh Token mit welchem Google sich gegenüber FHEM Connect (“dem zentralen Service”) authentifiziert.
* Bei der Installation des fhemconnect Clients wird ebenso auth0 herangezogen. Der User wird auch dort über auth0 authentifiziert und damit kann sich auch fhemconnect am zentralen Service anmelden.
* Durch dieses Verfahren kann FHEM Connect die User ID aus dem fhemconnect Client und die User ID die über Google kommt matchen und damit Befehle dem richtigen User zuordnen. Ein Faken dieser User ID ist nicht möglich, da der übertragene Token (JSON Web Token) signiert ist und bei jeder Übertragung von auth0 verifiziert wird.
* Durch die Verknüpfung des Accounts weiß Google, dass es FHEM Connect gibt und es dorthin Smart Home Befehle schicken kann.
* Ein Befehl wie "Schalte das Nachtlicht ein" wird von Google interpretiert
* FHEM Connect (der zentrale Service der auf Firebase läuft) erhält den Befehl das Nachtlicht einzuschalten. Durch den von Google übertragenen Access Token, welcher die User ID beinhaltet, wird der User identifiziert.
* FHEM Connect weiß durch die User ID, welche es dem verifizierten Access Token entnommen hat, welchem User der Befehl zuzuordnen ist und schickt dieser über Firebase an den fhemconnect Client.
* Der fhemconnect Client schickt den Befehl direkt an FHEM weiter wo der Befehl ausgeführt wird.

==Update==
Es wird nur in seltenen Fällen ein Update benötigt, da der größte Teil der Anwendung in Firebase konfiguriert ist. Sollte der Client dennoch aktualisiert werden müssen, dann kann das mit folgenden Befehlen durchgeführt werden:
<syntaxhighlight lang="bash" style="width:70%;">
sudo npm install -g gassistant-fhem --unsafe-perm
</syntaxhighlight>
* gassistant über FHEM neu starten

==FAQs==
* FHEM ist durch Username und Password gesichert (401: Authorization Required)
gassistant-fhem.cfg im fhem Installationsordner mit user/pass und wenn nötig SSL erweitern
<syntaxhighlight lang="json" style="width:70%;">
"connections": [
{
"name": "FHEM",
"server": "127.0.0.1",
"auth": {"user": "fhemuser", "pass": "fhempassword"},
"ssl": true,
"port": "8083",
"filter": "room=GoogleAssistant"
}
]
</syntaxhighlight>
* "Method Not Allowed" Fehlermeldung bei der npm Installation?
<syntaxhighlight lang="bash" style="width:70%;">
sudo npm install -g npm
</syntaxhighlight>

* Geräte erneut an Google übertragen
"Hey Google, synchronisiere meine Geräte" sagen

* Wie kann meine Familie auf die Geräte zugreifen?
In der Home App kann man mit den + Symbol auch Familienmitglieder hinzufügen. Damit haben dann die Familienmitglieder in deren Home App ebenfalls Zugriff auf die Geräte.

* Beim Starten kommt ein Fehler in dem "async" hervorgehoben ist.
Stelle sicher, dass du die aktuelle nodejs Version hast. Es sollte zumindest >= 8 sein (node -v liefert dazu die Antwort).
<syntaxhighlight lang="bash" style="width:70%;">
sudo apt update && sudo apt install nodejs
</syntaxhighlight>

==Kostenlos==
Aktuell wird der Service kostenlos betrieben. Abhängig von der Auslastung, könnte es zukünftig der Fall sein, dass die freien Limits bei Firebase und Auth0 überstiegen werden und damit Kosten anfallen. Solange das nicht der Fall ist, wird der Service kostenlos zur Verfügung gestellt.

Alexa Tipps und Kniffe

2019-01-26T23:53:04Z

MadMax-FHEM: /* Alexa über eine URL aktivieren */

==Zugriff absichern==
Eine Kurzanleitung zur Absicherung des Zugriffs findet man
[[Alexa-Fhem#Absichern_des_Zugriffs | hier ]]

==Alexa mit Google verbinden==
Alexa nutzt für allgemeine Fragen die Suchmaschine Bing. Bessere Ergebnisse liefert Google. Hier wird gezeigt, wie man Alexa mit der Google-Suchmaschine nutzen kann.
*[http://alexamods.com/guide-install-ask-google-alexa-skill/ Schrittweise Anleitung]
*Youtube: [https://www.youtube.com/watch?v=MlNs23J4e8E Video-Anleitung]
*Source [https://github.com/tartanguru/alexa-google-search alexa-google-search]
(Tipp von Romoker)

==Alexa über eine URL aktivieren==
Offenbar ist es doch möglich, Alexa durch einen externen Aufruf zu aktivieren. Konsequenzen derzeit noch unklar.
https://www.gehrig.info/alexa/Alexa.html
(Tipp von marty29ak)

Eine andere Alternative stellt das echodevice-Modul von Michael Winkler dar: https://forum.fhem.de/index.php/topic,82631.msg747482.html#msg747482

[[Kategorie:Sprachsteuerung]]

CUL

2017-12-28T21:37:28Z

MadMax-FHEM: Wording mit anderem Wiki-Eintrag abgeglichen.

'''CUL''' ('''C'''C1101 '''U'''SB '''L'''ite) ist ein RF-Gerät im Formfaktor eines USB-Dongles mit externer [[CUL Ausstattung|Antenne]]. Die über das ISM/SRD Band empfangenen Daten werden durch einen Onboard 8 bit Atmel Prozessor vorverarbeitet. Mit verfügbarer quelloffener [[#FW|Firmware]] kann das CUL verschiedene 868MHz [[CUL HomeMatic und FS20|Protokolle]] empfangen und senden, insbesondere die FS20/FHT/S300/EM/HMS sowie durch kurzfristiges Umschaltung auf 433 MHz Intertechno (z. B. viele Baumarkt Funksteckdosen) Protokolle.

Im Umfeld von FS20/FHT/EM/S300/HMS ("[[Rfmode|rfmode]] - [[SlowRF]]") wird die Dekodierung der per AM in 1 kHz übertragenen Signale per [[#FW|culfw]] auf dem Atmel Prozessor direkt erledigt und dann per USB an den Hostrechner weitergegeben.

Das CUL kann mittels des CULModuls von FHEM angesprochen und somit wie eine FHZ1X00PC verwendet werden.

Das CUL kann auch im HM-Mode als HomeMatic Zentrale alternativ zur CCU oder dem [[HMLAN Konfigurator]] betrieben werden. Bei CULs älter als Version 3 ist jedoch der Speicher zu klein, um die Software für FS20/FHT/S300/EM/HMS und HomeMatic zugleich im Speicher zu halten, hier muss man sich beim [[CUL an einer Fritzbox 7390 flashen|Flashen]] der Firmware für eine Protokollfamilie entscheiden. Mit zwei CULs ist aber auch der Mischbetrieb an einem FHEM Hostrechner möglich.

Ebenso gibt es ein Modul zur Ansteuerung der [[MAX]]! Heizungsteuerung. Auch hier ist ein Mischbetrieb (MAX! und z. B. FS20 gleichzeitig über ein CUL) obwohl technisch nicht unmöglich {{Link2Forum|Topic=10510|LinkText=nicht angeraten}}.

Ferner ist der Einsatz eines CUL als [[RFR CUL]] für den ''SlowRF'' Mode (jedoch nicht für den ''HomeMatic'' Mode) möglich, um die Reichweite zu erhöhen. Die Verbindung erfolgt hierbei über Funk, sodass keine USB Verbindung zum FHEM Hostrechner erforderlich ist.

Alle diese Modi sind in der Original-[[#FW|culfw]] enthalten und werden z.B. durch die Wahl des ''rfmode'' eingestellt.

Obwohl die eigentliche Betriebsfrequenz der FHT und FS20-Komponenten 868,35 MHz ist, ist bei den aktuellen CUL Firmwareversionen zum Betrieb mit FHEM die Frequenz auf 868,30 MHz eingestellt. Dies hat sich als Kompromiss zum besseren Empfang von EM1000EM (Energiemonitor) Geräten bewährt, '''obwohl''' diese nominal mit 868,360 MHz arbeiten. Praktisch ist die Genauigkeit der Sendefrequenz der meisten ''SlowRF'' Geräte wegen der primitiven Sender sehr schlecht und kann deutlich von der nominalen Frequenz abweichen.

Frequenz und Bandbreite können daher im ''SlowRF'' Mode frei angepasst und somit für die örtlichen Empfangsgegebenheiten optimiert werden.

== Hinweise zum Betrieb mit FHEM ==
'''Anmerkung:''' Nachfolgende Beispiele sind so wie dargestellt in die FHEM-Eingabezeile oder per Telnet auf FHEM zu übertragen und per <Taste>Enter</Taste> abzuschicken (nicht "save" klicken); '''''myCUL''''' ist dabei nur ein Platzhalter und durch den Namen '''Ihres''' CUL zu ersetzen. Da diese Funktionen durch die culfw (Firmware) bereitgestellt werden, funktionieren sie auf allen Geräten, die die culfw verwenden ([[CUNO]], [[COC]], CSM:

* Ist Empfang eingeschaltet ?
*: <code> get myCUL raw C35</code> (13 = ja, z. b.: C35 = 0D / 13)
* Auslesen der culfw Version:
*: <code>get myCUL raw V</code>
* LED ausschalten (Achtung: Buchstabe l (L) vorweg für LED, keine Zahl 1)
*: <code>set myCUL raw l00</code>
* LED einschalten
*: <code>set myCUL raw l01</code> Blinkt bei Senden oder Empfangen von Paketen
* LED soll blinken (einmal in der Sekunde)
*: <code>set myCUL raw l02</code>
* Reboot / Reset des CUL:
*: <code>set myCUL raw B00</code> Andere Werte als 00 starten das CUL im Bootloader-Modus (=> neue Firmware)
* Freie CUL Sendezeit ([[1% Regel]]):
*: <code>get myCUL raw X</code> 2. Wert ist Sendezeit in 10ms Slots, ein FS20 Befehl braucht ca. 210ms (also 21 Slots), eine FHT Kommunikation wesentlich mehr. Alternativ auch <code>get myCUL credit10ms</code> ergibt Sendezeit in 10ms Slots
* Freie Kapazität des FHT Buffers
*: <code> get myCUL raw T03</code> Ergebniss bytes in HEX. Leer = 4a
* Inhalt des FHT Buffers
*: <code> get myCUL raw T02</code> (CUL V2 Buffer ist 74 Bytes gross, Platz für 14 bis 31 FHT Messages). Rückgabe n/a = Buffer ist leer
* Eingestellte [[Was_ist_der_Hauscode%3F|FHT-ID]]
*: <code> get myCUL raw T01</code>
* Eingestellte Frequenz, Bandbreite etc. Ausgeben
*: <code> get myCUL ccconf</code>. Rückgabe z. B.: <code><nowiki>myCUL ccconf => freq:868.300MHz bWidth:325kHz rAmpl:42dB sens:4dB</nowiki></code>
* eingestelle Bandbreite erhöhen (z.B. auf 464 kHz, mehr hat meist keinen Sinn):
*:<code>set myCUL bWidth 464</code>
* Einstellen der Sendestärke:
*: <code>set myCUL raw x09</code> Einstellen der Sendeleistung.

Gültige Werte für die Sendeleistung sind 00-09. Verwendet werden sollten nur die Werte 05-09, diese entsprechen
-10/-5/0/5/10 Sendeleistung in db. Default ist x08 = +5db. Bitte im Interesse von Nachbarn und der Abhörsicherheit den kleinsten problemlos funktionierenden Wert einstellen. Dies ist meistens x07 oder x08. Da speziell die Kommunikation mit den FHTs bidirektional ist, kann die Kommunikation durch höhere Werte oft nicht verbessert werden, da die FHTs selber dadurch nicht stärker senden. Besser versuchen, Lage und Antennenausrichtung des CUL zu verändern. Siehe auch Diskussion unter [https://groups.google.com/group/cul-fans/browse_thread/thread/683ca5c892eae1c3/c682a640f1ba863c?lnk=gst&q=bWidth+freq#c682a640f1ba863c GoogleGroups-CUL-Fans]

Werte x00-x04 sind '''mit''' Ramping und führen zum Verlust der Kommunikationsfähigkeit mit anderen CULs, z. B. [[RFR CUL]].

'''Hinweis:''' Beim CUL im HomeMatic-Modus kann man (ohne Firmware-Modifikation) die Empfangs-/Sendeparameter '''nicht''' verstellen. Die üblichen freq/x09 etc. haben hier keine Wirkung ({{Link2Forum|Topic=10203|Message=57191|LinkText=Quelle}}).

Weiterhin kann man zunehmend mehr Debuggingoutput auf dem CUL einschalten mit :
* <code> set CUL1 raw X61</code> Communication wird im Detail angezeigt
* <code>set CUL1 raw X25</code> auch checksum Fehler / unerkannte Protokolle werden gemeldet
* <code>set CUL1 raw X2F</code> alle empfangenen Flanken werden gemeldet
* <code>set CUL1 raw X80</code> RSSI / Signalstaerke jeder Flanke wird gemeldet
* <code>set CUL1 raw X21</code> normal Modus

Achtung: Auf Gross- und Kleinschreibung des "x,X" achten!

Die kompletten Kommandos mit Erklärung für CUL sind in der [http://culfw.de/commandref.html commandref] zu finden.

== Versionen ==
Das CUL gibt es in mehreren Versionen, die sich überwiegend in Prozessor und Speicherkonfiguration unterscheiden.

* CUL V1 - AT90USB162 Prozessor, 0,5Kb RAM, 16Kb Flashmemory, 0,5 kByte EEPROM. Einsatzfähigkeit unbekannt (aber vermutlich wie V2). Wird nicht mehr hergestellt.
* CUL V2 - AT90USB162 Prozessor, 0,5Kb RAM, 16Kb Flashmemory, 0,5 kByte EEPROM. Einsatzfähig. Der Flashspeicher ist jedoch zu klein für eine culfw (CUL Firmware), die Code für ''SlowRF'' Geräte und zugleich ''HomeMatic'' Geräte enthält. Es muss also vor dem Flashen der Firmware zwischen zwei jeweils reduzierten Versionen gewählt werden. Da ein CUL ohnehin nicht beide Sendemodi '''zeitgleich''' betreiben kann, ist dies keine wirkliche Einschränkung. Wird nicht mehr hergestellt.
* CUL V3 - ATMega32U4 Prozessor, 2,5 kB RAM, 32 kB Flashmemory, 1 kByte EEPROM). Voll einsatzfähig.
* CUL V4 - ATMega32U2 Prozessor, 1 kB RAM 32 kB Flashmemory, 1 kByte EEPROM. Voll einsatzfähig. Genau genommen ein "Sparmodell" des V3, um Lieferengpässe des atmega32u4 Prozessors zu umgehen. Der reduzierte RAM-Speicher verursacht (zumindest gegenwärtig) beim Betrieb mit culfw und FHEM keine Einschränkungen oder Nachteile. Achtung: Flashen des CULv4 setzt DFU-Programmer 0.5.4 oder höher voraus.

Die für die aktuellen Modelle lieferbare Abschirmung ist in der Regel nicht notwendig.

== Firmware {{Anker|FW}} ==
Die für den CUL und verwandte Hardware wie [[CUN]] und CUR im Zusammenhang mit FHEM überwiegend eingesetzte Firmware culfw findet sich auf der
* [http://culfw.de CUL Firmware Homepage]
Dort kann die jeweils aktuelle Version nachgesehen und herunter geladen werden.
Alten Stände, Version für Entwickler und ganz aktuelle Änderungen findet man auf der
* [https://sourceforge.net/projects/culfw/ Sourceforge Projektseite der culfw]
Hier kann man sich z.B. mit
<syntaxhighlight lang=bash>
svn co svn://svn.code.sf.net/p/culfw/code/trunk/culfw
</syntaxhighlight>
die aktuelle Version laden.

Zusätzlich gibt es ["leider"...!?] folgende Forks der originalen culfw mit dortigen speziellen Anpassungen/Abweichungen:
* [https://github.com/heliflieger/a-culfw Alternative culfw for cul devices] auf GitHub und im {{Link2Forum|Topic=35064|LinkText=Forum}} mit Anpassungen unter anderem für InterTechno. Hier könnte es aber zu Funktionseinschränkungen bei anderen Protokollen kommen. In dieser Version ist auch ein Portierung auf ARM-Prozessoren enthalten (siehe {{Link2Forum|Topic=38404|LinkText=Forum}}) mit der die CUL-Firmware auch auf dem HM-CFG-USB-2 und dem [[MAX]] Cube betrieben werden kann.
* {{Link2Forum|Topic=24436|LinkText=Timestamp Firmware}} mit speziellen Anpassungen für HomeMatic. Bei HomeMatic ist das Timing der Telegramme entscheidend sonst kann es zu "MISSING ACK" bzw. "RESPONSE TIMEOUT:RegisterRead" u.ä. Meldungen kommen.

Alternativ zu den [a]culfw-Firmwares gibt es [[SIGNALduino]] (zumindest auf manchen Hardware-Konstellationen umgeflashed direkt anwendbar und 1:1 lauffähig; inkl. normierter/kompatibler Weiterleitung/Dispatching auf die gleichen zentralen Geräte-Protokoll-Dekodier-Module, die auch von anderer Transceiver-Hardware/-Firmware - CUL etc. - ähnlich angebunden werden (sollen); somit Kommunikation mit vielen Funk-Komponenten auch dort idealerweise immer 1:1 funktionierend).

Generell ist das Angebot an Speicherplatz auf dem im CUL verwendeten ATMega32U2 sehr eingeschränkt, wodurch Erweiterungen ohne Abstriche an anderer Stelle kaum mehr möglich sind. Es wird also die optimale CUL-Firmware für alle Zwecke nie geben, so dass man die Auswahl am konkreten Bedarf klären muss. Wer die Firmware selbst compiliert kann gezielt Funktionen die nicht benötigt werden weg lassen und dafür ggf. Funktionen die sonst nicht eingefügt sind hinzufügen.

== Sendefrequenz ==
Das CUL gibt es in Ausführungen für 868 und 433 MHz.
Die Sende- und Empfangsfrequenz des CUL sind in weiten Bereichen einstellbar, im ''SlowRF'' Mode auch durch direkte Befehle aus FHEM (im ''HomeMatic'' Mode derzeit nicht unterstützt). Der wesentliche Unterschied der 868 und 433 MHz CULs ist ein auf die Frequenz richtig abgestimmter HF-Eingangskreis inklusive Antennenlänge.

Es ist es durchaus möglich, ein 868 MHz CUL auf 433 MHz einzustellen. Da dann aber die HF-Eingangskreis-Abstimmung und Antennenlänge nicht korrekt sind, ist Empfangs- und Sendeleistung suboptimal, die Reichweite sinkt. Dennoch wird diese Möglichkeit des freien Einstellens durch das FHEM Intertechnomodul genutzt, da Intertechnokomponenten mit 433 MHz arbeiten. Dazu wird beim Senden eines Intertechno-Befehls die Frequenz eines 868 MHz CULs kurz umgestellt.

== Antenne ==
Der CUL ist mit RP-SMA-Stecker für die Antenne aber auch mit angelöteter Drahtantenne lieferbar.
Funktional besteht kein Unterschied: auch die "richtige" Antenne ist (in diesem Fall) nur ein Draht, jedoch gummiummantelt und eventuell mit einem Knickgelenk und einem Schraubanschluss versehen, d.h. die Drahtantenne sieht nur unschön aus.

Wichtig ist nur die Länge. Diese muss vorteilhafterweise so groß sein wie ein Viertel der Wellenlänge der Frequenz ("Lambda/4"). Die sind bei 868 Mhz ca. 8,6 Zentimeter. Antennenlängen die länger oder kürzer sind verschlechtern in der Regel die Leistung. Daher ist eine z.B. 10 Zentimeter lange Antenne (obwohl länger) schlechter als 1/4 Lambda mit 8,6 Zentimeter.

Über besondere Antennenkonstruktionen (bitte nach Colinear, Jpole, Yagi suchen) oder Antennen die "Lambda/2" oder gar ("Lambda") lang sind (also ca. 17,2 bzw. 34,5 Zentimeter) kann ein höherer Gewinn erreicht werden. Einher geht aber gleichzeitig eine stärkere Richtwirkung der Antenne. Je kürzer die Antenne, desto kugelförmiger die Abstrahlung. Bei längeren Antennen wird die Abstrahlung mehr und mehr zylinderähnlich, also mit horizontaler Richtwirkung (und in die Richtung ist das Signal dann stärker, daher der Antennen"gewinn").
Das hat auch Nachteile, speziell wenn man auch "nach oben" funken will. Speziell wenn man Antennen länger als eine λ/4 Antenne (8,6 Zentimeter) in einem mehretagigen Haus verwenden will, muss man diese daher in der Regel waagerecht/horizontal ausrichten, da alles was in Richtung der Spitze (und dem Fuss) der Antenne liegt schlecht Empfangen wird.

Daher: Je mehr Gewinn die Antenne aufweist, desto besser ist die Sende und Empfangsleistung, aber desto mehr Gedanken muss man sich um die Ausrichtung der Antenne machen, um alle Geräte zu empfangen / zu erreichen. "Mehr db" und speziell "länger" ist also nicht automatisch besser.

Zu beachten ist auch, dass die Sendeleistung der Module gesetzlich geregelt ist und Spezialantennen mit höherem Gewinn ggf. nur an Empfängern erlaubt sind.

Falls man den CUL mit RP-SMA Stecker geordert hat, aber keine passend lange RP-SMA-Antenne verfügbar ist, kann (nur für erste Tests) auch eine abschraubbare Antenne für 802.11b/g WLAN-Geräte (2,4 GHz) benutzt werden, so diese anschlusstechnisch auf den RP-SMA-Stecker des CUL passt (dies funktioniert zumindest mit FS20- und EM-Geräten). Deren Länge ist wie oben diskutiert aber nicht optimal, besser ist auf jeden Fall eine speziell auf den Einsatzzweck (Frequenz) abgestimmte Antenne.

== Antennenlänge ==
Die genauen Antennenlängen sind praktisch schwer zu ermitteln, da auch Zuleitung auf dem CUL zugerechnet werden müssten und ggf Dämpfungen (also z.B. Durchführung der Antenne durch eine Gehäuse, oder gebogene Antennen) die Antennenlänge weiter beeinflussen. Gleichzeitig haben schon Abweichungen von wenigen Millimetern messbaren Einfluss. Die Antennenlänge ist daher immer nur eine Kompromiss.

Exact berechnet ohne Störeinflüsse wären folgende Antennenlängen nutzbar:
868,35 Mhz (z.B. HM, FS20, FHT …)
1/4 Lambda = 8,63 Zentimeter
1/2 Lambda = 17,26 Zentimeter
1 Lambda = 34,52 Zentimeter (Bereits sehr hohe Richtwirkung)

433,92 Mhz (z.B. Intertechno …)
1/4 Lambda = 17,27 Zentimeter
1/2 Lambda = 34,54 Zentimeter

Folgende Antennenlängen bieten sich praktisch an, diese sind immer etwas kürzer als die optimale Länge, dies wird z.T. durch Leiterlänge im CUL kompensiert.:

8,6 Zentimeter als 1/4 Lambda für 868,35 Mhz
17,2 Zentimeter als 1/2 Lambda für 868,35 Mhz und zugleich 1/4 Lambda für 433,92 Mhz
34,5 Zentimeter als Lambda für 868,35 Mhz und zugleich 1/2 Lambda für 433,92 Mhz

== Bekannte Probleme ==
Im Gegensatz zu den original FHZ-Zentralen ist das CUL recht schmalbandig, d.h. die Sende- und Empfangsfrequenz wird genauer eingehalten als z. B. bei einer FHZ1x00PC. Dies kann im Zusammenhang mit den eher ungenauen Sendern z. B. der FHT Raumregler zu Empfangsproblemen führen. Es kann daher mitunter sinnvoll sein, die Sende- und Empfangsbandbreite des CUL etwas zu erhöhen. Dies senkt jedoch gleichzeitig die Empfindlichkeit.

Bei Empfangsproblemen von z. B. HEM-Sensoren oder dem S300TH kann man folgendes testen:

* Man kann die Frequenz des CUL auf genau 868,35 MHz einstellen. Standardmäßig ist hier aus Kompatibilitätsgründen 868,30 MHz eingestellt. Diese Einstellung wird fest im NVRAM gespeichert und braucht nur einmal vorgenommen zu werden.
*: <code>set CUL freq 868.350</code>
* Es ist möglich die "decision boundary" zu vergrößern, frei beschrieben: die "Entscheidungsgrenze" ob die empfangene Signalflanke digital "0" oder "1" darstellte ({{Link2Forum|Topic=8572|Message=44388|LinkText=siehe Diskussion hier}}). Möglich sind die Werte "4", "8" und "16". Default-Einstellung ist hier "4". Zur Steigerung der Empfangsqualität soll es hilfreich sein, hier "8" einzustellen. Mitunter bringt jedoch erst die Einstellung auf "16" signifikante Verbesserungen beim Empfang von S300TH-Sensoren.
*: <code>set CUL sens 8</code>
* Oft hilft auch, die Bandbreite auf z. B. 464 kHz aufzuweiten.
*: <code>set CUL bWidth 464</code>

== Selbstbau-/Bastelprojekte ==
Innerhalb der FHEM-Community werden mittlerweile diverse Bastelprojekte zum Selbstbau eines CUL betrieben. Eine Auswahl dieser Projekte:
* [[Selbstbau CUL]]
* [[FHEMduino]]
* [[SIGNALduino]]
* [[MapleCUN]] mit STM32 Mikrocontroller

== Links ==
* Hersteller / Bezugsquelle für CUL: [http://www.busware.de/tiki-index.php?page=CUL busware.de]
* Google groups [https://groups.google.com/group/cul-fans/ CUL fans], mittlerweile durch das Board {{Link2Forum|Area=cul-fans}} im [http://forum.fhem.de/index.php FHEM Forum] ergänzt/ersetzt

[[Kategorie:Interfaces]]
[[Kategorie:CUL]]

HomeMatic

2017-12-28T21:34:46Z

MadMax-FHEM: Hinweis auf Timestamp-FW überarbeitet.

'''HomeMatic''' (HM) ist ein System des Herstellers eQ-3 zur Steuerung und Überwachung von zahlreichen Aufgaben und Situationen im Haus. Erhältlich sind sowohl Geräte mit Funkschnittstelle 868.3 MHz, als auch (seit 2008) drahtgebundene Geräte mit RS485-Schnittstelle. Im Programm sind Geräte zur Heizungs- und Lichtsteuerung, Temperatur-, Luftfeuchte- und Feuchtemessung, Zutrittskontrolle, als Wasser-, Brand- und Bewegungsmelder sowie als Wetterstation, ferner gibt es noch Fernbedienungen und Statusdisplays.

Das ähnliche klingende '''''[[HomeMatic IP]]''''' ist eine neue Generation von Geräten und Funkprotokoll (HM-IP: IP over BidCos). Die dort angebotenen Geräte lassen sich über den Einsatz einer (physischen) CCU2 oder anderen Lösungen wie YHAM, raspberrymatic usw. und den [[HMCCU|HomeMatic-Modulen]] integrieren.

=Grundlagen=
HomeMatic-Geräte können untereinander ''gepeert'' werden (engl. ''peers'' = "Gleiche"), im einfachsten Fall kann deshalb bereits ein Sensor (z.B. ein Temperatursensor) mit einem Aktor (z.B. einem Heizkörperregler) verbunden werden und diesen steuern. Hierbei können mehrere Sensoren und Aktoren untereinander verbunden werden, die Vorstellung der "Gleichen" ist also zutreffend.

HomeMatic-Geräte können auch mit einer Zentrale verbunden (''gepairt'') werden, die dann einen Teil der Steuerungslogik übernehmen kann. Bei dieser Verbindung spricht man vom ''Pairing'', weil jedes HomeMatic-Gerät nur mit einer Zentrale verbunden werden kann. Gepairte Geräte können auch nicht mehr direkt gepeert werden - dies geht dann nur noch unter Beteiligung der Zentrale.

==Voraussetzungen==
Für den Betrieb ohne Zentrale sind keine weiteren Voraussetzungen zu erfüllen.
===Zentrale von eQ-3===
Vom Hersteller eQ-3 selbst wird eine Zentrale (derzeit aktuell CCU-2) und Windows-Software zur Steuerung und Auswertung der HM-Komponenten angeboten. Diese Zentrale kann wie eingangs dargestellt über das Modul [[HMCCU]] in FHEM eingebunden werden und dann neben HM-IP- und HM-wired-Komponenten auch solche mit BidCoS verwalten.

===FHEM als Zentrale===
Zur Kommunikation mit HomeMatic benötigt FHEM eine Schnittstelle, die im 868,3-MHz-Band funken kann. Infrage kommen:
* [[HM-MOD-RPI-PCB HomeMatic Funkmodul f%C3%BCr Raspberry_Pi]] (RPI, WLAN, LAN, USB)
* [[HM-LGW-O-TW-W-EU Funk-LAN Gateway]] (LAN)
* [[HM-CFG-LAN]] (oft auch "HMLAN" genannt; LAN; nicht mehr lieferbar)
* [[HM-CFG-USB USB Konfigurations-Adapter|HM-CFG-USB]] (USB, nicht mehr lieferbar)
* [[CUL]] und andere Geräte mit CC110x-Transceiver, [[CUNO]], SelbstbauCUL, nanoCUL, umgeflashter MAX-Cube, MapleCUx, CUNX usw. (USB, GPIO, LAN , WLAN)

Erfahrungsgemäß ist der Einsatz originaler HomeMatic IOs empfehlenswert, da es bei allen CUL-Derivaten immer wieder zu Schwierigkeiten kommen kann, vor allem in größeren Installationen und bei der Kommunikation mit komplexeren Geräten. Wer dennoch einen CUL für HomeMatic verwenden will, sollte eine speziell für den Betrieb mit HomeMatic optimierte CUL-firmware ([https://forum.fhem.de/index.php/topic,24436.0.html TimeStamp Firmware]) verwenden. Bei HomeMatic ist das Timing der Telegramme entscheidend sonst kann es zu "MISSING_ACK" bzw. "RESPONSE TIMEOUT:RegisterRead" u.ä. Meldungen kommen! Zusätzlich sind '''unbedingt''' die Hinweise im Artikel [[AES_Encryption]] zu beachten!

Für ''HomeMatic Wired'' benötigt man eine RS485-Schnittstelle. Das "offizielle" Gateway [[HomeMatic Wired RS485 LAN Gateway|HMW-LGW-O-DR-GS-EU]] (LAN) funktioniert prinzipiell mit FHEM, der Einsatz wird aber nicht empfohlen. Hier gibt es Alternativen dazu: [[Serial/Netzwerk-RS485-Adapter]].

===Migration von CCU-2 zu FHEM===
Der Umzug einer bestehenden HomeMatic Installation von einer HomeMatic CCU-2 auf FHEM ist möglich. Um die an die Zentrale angebundenen Devices in FHEM ohne größere Umkonfiguration weiter verwenden zu können, muß die HM-Id und, falls verwendet, die AES-Schlüssel der CCU-2 in FHEM übernommen werden. Um diese Daten aus der CCU-2 auszulesen, wird eine SSH-Verbindung (zum Beispiel mit PuTTY unter Windows) aufgebaut. Die HM-Id befindet sich in der Datei <code>/usr/local/etc/config/rfd/BidCoS-RF.dev</code> in einer Zeile wie dieser:

<device serial="BidCoS-RF" type="HM-RCV-50" address="0xABCDEF" aes_key_index="0" firmware_version="2.11.9" bidcos_interface="KEQ1234567" roaming="true">

Die HM-Id ist der Wert des <code>address</code>-Attributs. Die dort angegebene hexadezimale Zahl (hier <code>0xABCDEF</code>) ist die HM-Id und wird in FHEM ohne das "0x"-Präfix verwendet.

Falls AES-Schlüssel eingerichtet sind, sind diese in der Datei <code>/etc/config_templates/crypttool.cfg</code> zu finden und können 1:1 als Schlüssel im [[HM-CFG-LAN]] in der gleichen Reihenfolge hinterlegt werden.
{{Todo|Wie werden AES-Schlüssel in HM-CFG-LAN "hinterlegt"?}}

==Prototokoll==
HM-Geräte kommunizieren untereinander mit dem Protokoll ''Bidirectional Communication Standard'', abgekürzt ''BidCoS''. Jedes HM-Gerät enthält also Sender und Empfänger, das ist einer der wesentlichen Unterschiede z.B. zum FS20-System.
*Jedes HM-Gerät meldet beim Empfang eines Steuerbefehls durch einen Peer an diesen eine Bestätigung „ACK“ zurück. Erkennt das HM-Gerät den Befehl nicht, sendet es ein ''NACK''. Kommt vom HM-Gerät keine Rückmeldung innerhalb einer festgelegten Zeit, meldet der steuernde Peer ein ''MISSING ACK''.
*Jedes HM-Gerät meldet ferner seinen Status nach dem Erhalt eines Steuerbefehls zurück - so kann auch ein lokal am Gerät erfolgender Tastendruck in beim steuernden Peer oder in der Zentrale registriert werden.

Das Protokoll ''BidCoS'' wurde zum großen Teil entschlüsselt, seine offen verfügbare Variante heißt ''AskSin''. Unter Verwendung der AskSin-Library entstehen derzeit erste Geräte, die in das HomeMatic-System eingebunden werden können. Zur Unterscheidung zwischen HM und den neuen Geräten werden diese als [[HomeBrew]] (HB) bezeichnet.

=Betrieb mit FHEM=
Die Kenntnis des Dokumentes [http://fhem.de/Heimautomatisierung-mit-fhem.pdf Einsteigerdokuments "Heimautomatisierung mit FHEM"] wird vorausgesetzt. Im Anhang dieses Dokuments findet sich ein Teil über den Aufbau und die Funktion von HM-Geräten.

=== Einrichten des IO-Devices (Funkschnittstelle)===
Zuerst muss ein IO-Device eingerichtet werden, um mit HM Geräten kommunizieren zu können. Hier ist eine Liste der [[HomeMatic#FHEM als Zentrale|Schnittstellen]].

=== Struktur von HM Geräten===
HM Geräte sind logisch in ein '''Device (Gerät)''' und ein oder mehrere '''Channels (Kanäle)''' gegliedert. Jedes Device und jeder Channel wird in einer Entity in FHEM repräsentiert. 
Ausnahme: Sollte ein Gerät nur einen Kanal haben werden diese zusammen in einer Entity angelegt.
====Device====
Das Device ist für die Kommunikation verantwortlich. Es sortiert und ordnet die zu sendenden und empfangenden Nachrichten.
Man kann prüfen, ob alle Nachrichten übertragen sind, oder ob es Probleme gegeben hat. Die Variablen "prot..." geben Auskunft darüber. Siehe auch [[Homematic_HMInfo#protoEvents]].
Zu beachten sind zudem die Übertragungsmodi. Nicht alle Devices sind ständig auf Empfang - FHEM muss berücksichtigen, wann gesendet werden kann. In '''protState''' kann man sehen, ob Kommandos auf Verarbeitung warten, also pending sind. Einige Devices unterstützen mehrere Modi parallel.

===== Config=====
Wird von allen Devices unterstützt, auch wenn es bei Always kaum genutzt werden kann.
Man setzt die Kommandos in FHEM ab und diese warten in der Kommando-queue.
Wenn die config-funktion am Device ausgelöst wird (Anlerntaste drücken) sendet FHEM die wartenden Nachrichten der Reihe nach. Config wird bei allen Devices zum pairen genutzt.

===== Always=====
Trifft man meist bei netzbetriebenen Geräten an, da diese kein Problem mit dem Energieverbrauch haben. Man kann immer mit dem Device kommunizieren.

===== Burst=====
Nur der Empfänger des Device ist aktiv. Über eine Aufweck-sequenz kann das Device geweckt werden. Man kann quasi immer mit dem Device kommunizieren. Nachteil des Aufwecken ist zum Einen, dass immer ALLE Devices im Funknetz geweckt werden, was deren Batterie belastet. Zum Andere ist die Aufweck-sequenz funktechnisch aufwändig und belastet die maximal erlaubte Sendekapazität des IO device je Stunde.

===== ConditionalBurst=====
Bei einigen Devices kann man den Burst mode zuschalten. Dies sind Devices, die zusätzlich über andere modi verfügen, so z.B. wakeup. Schaltet man burst-empfang ein kann man immer und sofort mit dem Device reden, es kostet aber etwas mehr Batterie. Siehe hierzu Attribut '''burstAccess''', Kommando '''burstXmit''' und Register '''burstRx'''
===== LazyConfig=====
Kommandos in der Queue werden bearbeitet, wenn eine Aktion vom Device ausgeht. So zum Beispiel ein Tastendruck bei einer Fernbedienung.
Dieser mode wird von CUL/CUNO nicht unterstützt. FHEM ignoriert diese Option automatisch und wartet i.a. auf ein Config.
===== Wakeup=====
Die Devices wachen regelmäßig auf und senden Daten, z.B. Temperatursensoren. Zu diesem Zeitpunkt kann FHEM die Nachrichten übertragen. Die Aufwachperiode ist unterschiedlich von 3 min bis zu 24h.

====Channel====
Ein Kanal ist die Funktionseinheit des Geräts. Hier ist die Funktion des Sensors oder Aktors realisiert.

Nutzt ein Gerät nur einen Kanal, wird dieser in FHEM der Übersichtlichkeit halber nicht einzeln angelegt. Für die Kommandos und das Peering wird trotzdem die HM-ID des 1. Kanals verwendet.

Nutzt ein Gerät hingegen mehrere Kanäle, werden diese per [[autocreate]] zusätzlich zum Device angelegt. Es ist aber möglich, bei Geräten mit virtuellen Kanälen, diese zu löschen und fehlende Attribute manuell dem Device hinzu zu fügen. Danach kann es wie ein 1-Kanal-Gerät genutzt werden. Allerdings werden die Kanäle beim erneuten Pairing von [[autocreate]] neu angelegt.

=====virtuelle Kanäle=====
Einige Dimmer unterstützen virtuelle Kanäle. Eigentlich haben sie keinen Hauptkanal sondern nur 3 virtuelle Kanäle, die je nach Verknüpfungslogik, den endgültigen Zustand des Aktors bestimmen. Dieses Verhalten wird in jedem Kanal per Register '''logicCombination''' gesetzt. 
Folgende Logik wird dabei angewendet: <tt>phyLevel = (((0% o Ch1) o Ch2) o Ch3)</tt> [o = Logik-Platzhalter]

D.h. es wird immer der Kanal mit dem gesetzten Register mit dem vorherigen Teilergebnis kombiniert, angefangen mit Kanal1. 
Es gibt folgende Logik-Optionen: [einzelne Betrachtung von <tt>(Vorergebnis o Kanal)</tt>]
{|
!style="text-align:left;"|Wert!!style="text-align:left;"|Bedeutung!!style="text-align:left;"|Beispiel (alle Werte in %)
|-
|inactive||keine Verknüpfung|| 30 inactive 80 = 30
|-
|or||oder (höchster Wert zählt)|| 30 or 80 = 80
|-
|and||und (kleinster Wert zählt)|| 30 and 80 = 30
|-
|xor||entweder-oder (nur 1 Kanal darf über 0% sein)|| 30 xor 80 = 0 ''aber'' 30 xor 0 = 30
|-
|nor||oder negiert (höchster Wert subtrahiert von 100%)|| 30 nor 80 ''= !80'' = 20
|-
|nand||und negiert (niedrigster Wert subtrahiert von 100%)|| 30 nand 80 ''= !30'' = 70
|-
|orinv||oder mit invertiertem Kanal|| 30 orinv 80 ''= 30 or 20'' = 30
|-
|andinv||und mit invertiertem Kanal|| 30 andinv 80 ''= 30 and 20'' = 20
|-
|plus||Vorergebnis addiert mit Kanal|| 30 plus 80 = 100
|-
|minus||Vorergebnis subtrahiert mit Kanal|| 30 minus 80 = 0
|-
|mul||Vorergebnis multipliziert mit Kanal|| 30 mul 80 = 24
|-
|plusinv||Vorergebnis addiert mit invertiertem Kanal|| 30 plusinv 80 ''= 30 plus 20'' = 50
|-
|minusinv||Vorergebnis subtrahiert mit invertiertem Kanal|| 30 minusinv 80 ''= 30 minus 20'' = 10
|-
|mulinv||Vorergebnis multipliziert mit invertiertem Kanal|| 30 mulinv 80 ''= 30 mul 20'' = 6
|-
|invPlus||invertiertes Vorergebnis addiert mit Kanal|| 30 invPlus 80 ''= 70 plus 80'' = 100
|-
|invMinus||invertiertes Vorergebnis subtrahiert mit Kanal|| 30 invMinus 80 ''= 70 minus 80'' = 0
|-
|invMul||invertiertes Vorergebnis multipliziert mit Kanal|| 30 invMul 80 ''= 70 mul 80'' = 56
|}
: ''→ Siehe auch: [[HM-LC-Dim1PWM-CV Dimmaktor PWM DC-LED#Beispiele|Verknüpfungsbeispiel]]''

=== Variablen===
Wie alle FHEM Entities werden 4 Gruppen von Daten unterstützt:
* Internals: Im Web-Interface sichtbare Variablen, die allgemeine Informationen über den Zustand enthalten.
* Readings: Im Web-Interface sichtbare Variablen. Sie werden aus von Entites empfangenen Nachrichten generiert. Man kann mit notify Trigger auf die setzen. Readings werden im Statefile bei save und gewissen neustarts gesichert und beim Booten eingelesen. Readings haben einen Zeitstempel.
* Attribute: Im Web-Interface sichtbare Variablen. Über sie kann man die Eigenschaften der Entity in FHEM steuern.
* Helper: Im Web-Interface nicht sichtbare Variablen. Man kann sie mit dem Kommando 'list' sehen. Es sind hilfsvariablen, die für den User keine Bedeutung haben sollen.
==== Internals====
Viele Variablen sind nicht HM spezifisch - deren Bedeutung muss in allgemeinen Teil nachgelesen werden. Spezifische Variablen sind:
*Device
** channel_xx: Liste der Kanäle, die dem Device zugeordnet sind.
** prot... : Gruppe von Daten zum Zustand des [[HomeMatic#Protokol|Protokolls]], also der Kommunikation mit dem Device.
** rssi...: Gruppe von Daten die den [[HomeMatic#Rssi|Empfangspegel]] des Device bei IOs, Peers und Repeatern darstellt.

*Kanäle
** device: Das übergeordnete Device
** chanNo: Die Kanalnummer
** peerList: Ist die Entity mit einem anderen gepeert ist steht hier der Name der Peers. Siehe auch attribut peerIDs und Reading peerList. Diese Variable ist mit dem peer verlinkt, man kann darauf 'clicken'.

==== Readings====
Readings für HM Entites unterliegenden allgemeinen FHEM Regeln.
Generell gilt, dass ein Wert, der von FHEM gesetzt wurde mit dem prefix '''"set_"''' versehen wird. Wenn der Zustand bestätigt ist wird das set_ entfernt. Sollte man also ein Reading mit diesem prefix haben, das sich nicht selbst entfernt sollt man unbedingt den Zustand kontrollieren. 
So ist nach einem "set Licht on" der Zustand des Licht erst einemal "set_on". Mit der Antwort des Device wird es dann auf "on" gesetzt. 
Register machen eine Ausnahme:

=====Register=====
Register sind Konfigurationsparameter, die '''im Device flash''' gespeichert werden. Daten, die Registern zureordnet sind beginnen mit "R-". Sollte das Register einem peer zugeordnet sein kommt dieser danach. Der Namen ist also '''R-<peer>-<registerName>'''.

Der Zugriff ist indirekt, geht also nur über Methoden und Kommandos. Man kann die Konfiguration (Register und peers) mit '''getConfig''' aus dem Device lesen und in FHEM dargestellen. FHEM bemüht sich, die angezeigten Register aktuell zu halten - der User muss aber ein gewisse Vorsicht im Umgang damit walten lassen. Register können mit '''regSet''' gesetzt werden. Ob die gelesenen Register komplett sind prüft [[Homematic_HMInfo#Integrit.C3.A4tspr.C3.BCfungen|configCheck]]. Da einige Entities viele Register haben kann man mit dem Attribut '''expert''' die Sichtbarkeit steuern (siehe auch [[Homematic_HMInfo#Infos|Register]]).

Von einigen Devices sind Register schwer zu lesen, z.B. config devices. Man kann die Register-Readings [[Homematic_HMInfo#archConfig|archivieren]] und beim reboot wieder [[Homematic_HMInfo#archConfig|laden]].

==== Attribute====
Attribute sind i.a. Parameter, die das Verhalten der Entity steuern. Sie werden mit '''save''' in fhem.cfg oder einem seiner subfiles gespeichert. Nach einer Änderung sollte der User ein "save" machen, sonst sind diese nach einem Reboot verloren. 
Hier werden nur '''HM spezifische Attribute''' besprochen. 
Attribute, die das System '''automatisch''' anlegt. Sollten diese nicht mehr stimmen kann der User anlernen am Device drücken und sie werden wieder hergestellt. Der User sollte sie '''nicht ändern'''.
* model
* subType
* peerIDs: HMIds der peers. Wird gelegentlich verschoben!
* serialNr: auslaufend - durch Reading D-serianNr ersetzt
* firmware: auslaufend - durch Reading D-firmware ersetzt

Attribute für HM Entities, die der User steuern kann
* webCmd: FHEM setzt ggf. einen Default, der User kann dies anpassen
* expert: schaltet mehr oder weniger Readings sichtbar - dient der Übersichtlichkeit des Web-Interface.
* autoReadReg: steuert das automatische Lesen der Konfiguration - ggf. zeitverzögert um Resourcen zu schonen. Es wird Level 5 empfohlen

Attribute für HM Entities am Device, die der User steuern kann
* msgRepeat: kann man im Device einstellen. Es legt fest wir oft eine Nachricht wiederholt werden soll, falls sie nicht empfangen wird. Beachte, dass unabhängig davon ein HMLAN/USB immer 3-mal probiert zu senden. Insbesondere bei Burst Devices sollte man einen niedrigen level einstellen.
* IODev: Sollte man auf das IO device setzen, über das zu diesem Device gesendet werden soll. Es wird i.a. beim Pairen gesetzt.

Empfohlene Attribute außerhalb von HM
* event-on-change-reading .*

===Kommandos===
====Allgemein====
* get <name> cmdList ''# zeigt alle Kommandos mit Parametern für diese Entity an''
* clear [readings|register|rssi|msgEvents] ''# löschen von Readings oder Zählern''
====Register kommandos====
* set <name> getConfig ''# liest alle Peers und Register. Auf ein Device angewendet werden ALLE channels auch gelesen''
* set <name> regSet [prep|exec] <regName> <value> ... [<peerChannel>]'' #schreiben eines Registerwerts. Das Kommando landet im Kommandstack''
* set <name> regbulk ...''# kommando zum setzen von rohdaten und ganzen Registerlisten. Ausser zum re-configurieren eines ganzen Device eher nicht für den User zu gebrauchen''

* set <name> sign [on|off ''# setzt das Register um AES einzuschalten. Man sollte sich über AES '''vorher''' einlesen!!''

* get <name> regList ''# zeigt alle Register, die diese Entity '''unterstützt''' - incl Beschreibung und Wertebereich. Als Anfänger sollte man einmal hinsehen!''
* get <name> reg all ''# zeigt alle Register, die diese Entity '''hat''' und den aktuellen Wert''

===Kommunikation===
Die Kommunikation zwischen Device und der Zentrale folgt einem Protokoll. Für die meisten Nachrichten erwartet der Sender eine Empfangsbestätigung. FHEM beachtet das Protokoll und implementiert es entsprechend der Fähigkeiten des IO device.

Grundsätzlich kann jedes Device an jedes andere Nachrichten senden. Damit dies auch einen erfolg hat, müssen die Kanäle gepeert werden.

Um FHEM zu erlauben, Nachrichten an das Device zu richten muss FHEM gepairt werden. 
Das Senden der Nachrichten macht IMMER das Device - ein Kanal selbst kann nicht wirklich senden.

====Protokoll====
Da für das Senden das Device verantwortlich ist sind hier die entsprechenden Informationen zu finden. Zu Beachten sind die [[HomeMatic#Device|Übertragungsmodi]], die ein Device unterstützt. Die Internals "prot..." enthalten alle notwendigen Daten.
* protState: Der Zustand der Protokollmaschine
** CMDs_done: alle Nachrichten übertragen, keine Fehler in diesem Durchgang aufgetreten
** CMDs_done_Error:xx : es hat xx Fehler bei der letzten Übertragung gegeben.
** CMDs_pending: Nachrichten warten auf das Senden
** CMDs_processing... : die Nachrichtenübertragung ist im Gange
** Info_Cleared: die Protokoll Statistik wurde rückgesetzt
* protCmdPend: Anzahl der Nachrichten, die auf das Senden warten
* protCmdDel: Anzahl gelöschter Nachrichten aufgrund von Fehlern
* protCmdNack: Anzahl der negativen Acknowledges
* protCmdResnd: Anzahl der Wiederholungen - die Nachrichten wurden nicht gelöscht.
* protCmdResndFail: Anzahl der fehlgeschlagenen Wiederholungen - die Nachrichten wurden gelöscht.
* protCmdIOerr: Anzahl der IO Fehler - Übertragung war nicht Möglich, weil das IO Device Probleme hatte. Der Grund sollte im IO Device nachgesehen werden.
* protCmdIOdly: Anzahl der Verzögerungen aufgrund von IO Problemen
* protCmdTimedOn: Anzahl der Nachrichten, wenn ein Timer im Device genutzt wird - z.B. durch on-for-timer
* protCmdRcv: Anzahl empfangene Nachrichten
* protCmdSnd: Anzahl gesendete Nachrichten
* protCmdErrIoId_...: Anzahl der Sendeversuche zum Device von einer anderen Zentrale
* protCmdErrIoAttack: Anzahl der Sendeversuche zum Device die nicht von FHEM kam- es könnte ein Versuch sein, das System zu hacken. Dies wird auch im Reading '''sabotageAttack''' ausgegeben und man kann ein notify darauf ansetzen.

* protCmdEvt_AESCom: Anzahl der AES Nachrichten von Device
* protCmdEvt_AESKey: Benutzter AES key

Die Zähler können mit '''set <device> clear msgEvents''' rückgesetzt werden. Dies kann vor Konfigurationsänderungen Sinn machen, um Probleme besser erkennen zu können. 
Eine Übersicht kann man mit HMInfo [[Homematic_HMInfo#protoEvents|protoEvents]] erhalten. Auch das Löschen aller Zähler ist von HMInfo aus möglich.

====Rssi====
Zeigt den Empfangspegel, den ein Device von einem Anderen misst. Die Variablen sind in Internals abgelegt. Angegeben werden minimale und maximale Wert. Außerdem wird der Durchschnitt und die Anzahl der Nachrichten ausgewertet. 
HM liefert Empfangspegel am IO Device (FHEM standard) aber auch den Empfangspegel am Device selbst. Ebenfalls ausgewertet werden Pegel, die beim Senden zwischen Peers erreicht werden. 
Die Zähler können mit '''set <device> clear rssi''' rückgesetzt werden. 
Eine Übersicht erhält man mit HMInfo [[Homematic_HMInfo#RSSI|Rssi]]. Das Löschen der Zähler aller HM devices ist von HMInfo aus möglich. 

Man kann RSSI kontinuierlich aufzeichnen, wenn das Attribut '''rssiLog''' im Device gesetzt ist. Es wird ein Reading rssi_<name> erzeugt. Das generelle setzen dieses Attributs wird aus Performance-gründen nicht empfohlen.

== Pairen und Peeren ==
: ''→ Siehe auch: [[Pairing und Peering]]''

HomeMatic-Geräte können mit einer Zentrale (FHEM) ''gepairt'' und mit anderen HM-Geräten ''gepeert'' werden.

=== Pairen ===
: ''→ Siehe auch: [[Pairing (HomeMatic)]]''
: ''→ Anleitung: [[HomeMatic Devices pairen]]''

HM-Geräte können mit und ohne Zentrale betrieben werden. FHEM geht davon aus, dass Geräte immer von einer Zentrale aus gesteuert werden können. Dazu muss das Gerät mit der Zentrale ''gepairt'' werden.

=== Peeren ===
: ''→ Siehe auch: [[Peering (HomeMatic)]]

Um es Geräten zu ermöglichen auch ohne Zentrale zu interagieren (zum Beispiel wenn die Zentrale einen Defekt hat), können HM-Geräte untereinander ''gepeert'' werden.
Dazu wird ein Sensor-Kanal mit einem Aktor-Kanal verknüpft.

== HMInfo ==
: ''→ Siehe auch: [[Homematic HMInfo]]''

Bei der Betreuung einer HomeMatic-Installation ist das Modul [[Homematic_HMInfo|HMInfo]] sehr hilfreich. Es stellt eine Übersicht der HomeMatic-Komponenten zur Verfügung, kann die Konfiguration prüfen und Alarmierungen gesammelt auswerten.

== Besondere Entites ==

=== Virtuelle Entities ===
Virtuelle Entities sind nicht reale HM Devices und Kanäle. Man kann sie als Sender und Empfänger nutzen, auch im Zusammenhang mit Rauchmeldern oder zur Steuerung von Heizungsventilen. Die spezifischen Anwendungen sind im entsprechenden Kapitel nachzulesen. 
Angelegt wird das Device, dann wird per Kommando eine Anzahl Kanäle angelegt.
define <virtDev> CUL_HM 112233
set <virtDev> virtual 10
jetzt hat man ein virtuelles Device mit 10 Kanälen angelegt.
Die die gültigen Kommandos kann man wie immer mit '''get <entity> cmdList''' erfahren. 
Auch einem Virtuellen Device sollte man das '''Attribut IODev setzen '''.
=== IO Entities ===
: ''→ Siehe auch: [[Virtueller Controller VCCU#Virtuelle Kanäle der VCCU]]

'''IO-Entities''' sind virtuelle Kanäle der Zentrale, mit denen andere HomeMatic-Geräte gepeert werden können. Diese Kanäle sind einem ''IO-Device'' zugeordnet – im Unterschied zu ''virtuellen Entities'' gibt es kein virtuelles Homematic-Gerät welches die Kanäle beherbergt.

Jedem IO-Device können bis zu 50 Kanäle zugewiesen werden. Wenn mehrere IO-Devices die gleiche HMId nutzen, zum Beispiel wenn ein [[Virtueller Controller VCCU|virtueller Controller]] verwendet wird, teilen sich diese IO-Devices die Kanäle.

'''Anlegen:'''

# IO-Device definieren
define <IO-Device> CUL_HM c0ffee
attr <IO-Device> model CCU-FHEM

# 4 IO-Entities definieren
set <IO-Device> virtual 4

=== Action Detector===
Einige Devices der HM-Geräteserie senden periodisch Nachrichten. Manche alle 3 Minuten, andere alle 3 Tage. Wenn so eine Zeit für einen Device spezifiziert ist wird diese automatisch vom ActionDetector überwacht. 
Meist sind dies batteriebetriebene Geräte. Sollte aus irgendwelchen Gründen der Batteriealarm übersehen werden und das Gerät keine Nachricht mehr senden wird es auf Dead gesetzt.
Die Kontrollinstanz ist ein Pseudo-Gerät "ActionDetector" mit der HMId "000000"

* attribut
** actCycle: gibt an, in welchen Abständen sich das Device melden muss
** actStatus: gibt den Zustand an
*** alive: Device hat sich in der erwarteten Zeit min einmal gemeldet
*** dead: Device hat sich in der erwarteten Zeit nicht gemeldet
*** unknown: Device hat sich nicht gemeldet, es ist aber seit dem letzten reboot die Zykluszeit noch nicht abgelaufen.

* readings
** Activity: entsprechend dem actStatus.

* get
** listDevice: Gibt alle Objekte zurück
** listDevice notActive: Gibt alle Objekte zurück die nicht "alive" sind
** listDevice alive: Gibt alle Objekte zurück die "alive" sind
** listDevice unknown: Gibt alle Objekte zurück die "unknown" sind
** listDevice dead: Gibt alle Objekte zurück die "dead" sind

Durch das Setzen des Attributs im HM device wird der ActionDetector automatisch definiert - nach einem save steht er auch in der fhem.cfg.
Alternativ ist auch eine manuelle Definition möglich und sollte in etwa so aussehen:

define ActionDetector CUL_HM 000000
attr ActionDetector actCycle 30
attr ActionDetector event-on-change-reading .*
attr ActionDetector model ActionDetector

Die HMId "000000" darf nicht geändert werden.

In der Entity actionDetector kann man die Infos gesammelt einsehen.
Der User kann durch das Setzen des Attributs actCycle jedes Device in diese Liste aufnehmen. Es wird dann geprüft, ob sich das Device in dieser Zeit auch meldet. Der User muss dies aber selbst sicherstellen.

== Tipps / HowTos / Beispiele ==

* [[HomeMatic Devices pairen|HM Devices pairen]] zum '''Pairen''' der Geräte untereinander.
* [[CUL]] (also gleichzeitig)?
* [[Slider für HM-Rolladensteuerung anzeigen]]
* Für den "Fall der Fälle": Erstellen Sie eine Liste aller HM-Geräte mit den Installationsorten, HM-Namen, FHEM-Namen '''und''' den Geräte-IDs. Falls Sie sich ihr FHEM einmal zerschießen, wird diese Liste sehr hilfreich sein. Zur Abwicklung von Gewährleistungsansprüchen sind Daten über Kaufdatum und Lieferant (bei größeren Installationen mit Zukauf in zeitlichen Abständen) ebenfalls angebracht.

== Probleme ==

=== Messages Sniffen ===
Um Probleme besser nachvollziehen zu können, kann man [[Homematic_Nachrichten_sniffen|Nachrichten mitsniffen]]

=== Daten können empfangen werden, Befehle werden nicht übertragen ===

Das kann mehrere Ursachen haben:
* Pairing nicht abgeschlossen (bei den ''Readings'' "PairedTo" bzw. "R-pairCentral" steht der Wert '''set_'''0x1A2B3C). Das Pairing ist erst dann erfolgreich abgeschlossen, wenn das '''set_''' fehlt, also nur noch (beispielhaft) "0x1A2B3C" steht. Siehe [[HomeMatic_Devices_pairen]]
* Sender (CUL/HM-LAN) und Empfänger (HM-Device) stehen zu nah (RSSI-Werte bei ~ "-17") beieinander
* Sender (CUL/HM-LAN) und Empfänger (HM-Device) stehen zu weit (RSSI-Werte bei unter ~ "-80") voneinander entfernt
* ...

=== Notifys und anderes funktionieren nach einem FHEM-Neustart nicht mehr oder nicht mehr zeitnah ===

Obwohl HomeMatic wegen der höhren Datenübertragungsrate wesentlich weniger von der [[1% Regel]] betroffen ist als z.b. FS20 oder FHT, so kann es dennoch zu Funkkontingentüberschreitungen kommen.

Insbesondere ist bei FHEM Versionen ab Oktober 2013 das Attribut ''autoReadReg'' auf "4_reqStatus" gesetzt. Damit wird für jedes HM-Device mit diesem so gesetzten Attribut beim FHEM-Start ein ''getConfig'' durchgeführt, was viel Funkverkehr erfordert.

Je nach Anzahl der Geräte kann dazu führen, dass insgesamt zu viel Funklast erzeugt wird, im Logfile erscheint dann eine Meldung wie:

2013.10.03 13:41:18 2: HMLAN_Parse: HMLAN1 new condition ERROR-Overload

Ab diesem Moment werden eben auch keine anderen Befehle mehr an weitere HM-Geräte geschickt, da das Funkkontigent aufgebraucht ist. Erst nach einer Stunde kann erneut gesendet werden. Als '''Notbehelf''' kann die Funkschnittstelle resetted oder ([[HMLAN Konfigurator]]) kurz stromlos gemacht werden. Dann wird der Zähler wieder auf Null gesetzt.

Alternativ können so viele HM-Geräte wie möglich auf ''autoReadReg 0_off'' gesetzt werden.

Siehe auch: [[1% Regel]]

=== Spannungsversorgung ===
Die Batterielebensdauer der HomaMatic Komponenten ist durchwachsen. Besonders die mitgelieferten Batterien sind mitunter schon nach wenigen Wochen leer, trotzdem werden öfters keine ''battery low'' Meldung erzeugt. Bei Störung des Funkverkehrs (z.b. blinkendes Antennensymbol im HM-CC-TC und kurzes piepen zur vollen Stunde von morgens bis abends, fehlende ACK Meldungen, nicht auslösende IR-Bewegungssensoren und ähnliches) sollte also immer auch eine schlechte Spannungsversorgung in Betracht gezogen werden.

Gute neue Batterien halten jedoch i.d.R. 12 Monate und mehr, auch Lebensdauern über 2 Jahre sind bei einigen Geräten (Tür/Fensterkontakte, Sender, Retroanzeige, IR-Bewegungsmelder) keine Seltenheit.

== Links ==
* [http://www.homematic.com/ HomeMatic] Homepage
* Hersteller [http://www.eq-3.de eQ-3]

[[Kategorie:HomeMatic Components]]
[[Kategorie:Glossary]]

CUL

2017-12-28T10:05:27Z

MadMax-FHEM:

'''CUL''' ('''C'''C1101 '''U'''SB '''L'''ite) ist ein RF-Gerät im Formfaktor eines USB-Dongles mit externer [[CUL Ausstattung|Antenne]]. Die über das ISM/SRD Band empfangenen Daten werden durch einen Onboard 8 bit Atmel Prozessor vorverarbeitet. Mit verfügbarer quelloffener [[#FW|Firmware]] kann das CUL verschiedene 868MHz [[CUL HomeMatic und FS20|Protokolle]] empfangen und senden, insbesondere die FS20/FHT/S300/EM/HMS sowie durch kurzfristiges Umschaltung auf 433 MHz Intertechno (z. B. viele Baumarkt Funksteckdosen) Protokolle.

Im Umfeld von FS20/FHT/EM/S300/HMS ("[[Rfmode|rfmode]] - [[SlowRF]]") wird die Dekodierung der per AM in 1 kHz übertragenen Signale per [[#FW|culfw]] auf dem Atmel Prozessor direkt erledigt und dann per USB an den Hostrechner weitergegeben.

Das CUL kann mittels des CULModuls von FHEM angesprochen und somit wie eine FHZ1X00PC verwendet werden.

Das CUL kann auch im HM-Mode als HomeMatic Zentrale alternativ zur CCU oder dem [[HMLAN Konfigurator]] betrieben werden. Bei CULs älter als Version 3 ist jedoch der Speicher zu klein, um die Software für FS20/FHT/S300/EM/HMS und HomeMatic zugleich im Speicher zu halten, hier muss man sich beim [[CUL an einer Fritzbox 7390 flashen|Flashen]] der Firmware für eine Protokollfamilie entscheiden. Mit zwei CULs ist aber auch der Mischbetrieb an einem FHEM Hostrechner möglich.

Ebenso gibt es ein Modul zur Ansteuerung der [[MAX]]! Heizungsteuerung. Auch hier ist ein Mischbetrieb (MAX! und z. B. FS20 gleichzeitig über ein CUL) obwohl technisch nicht unmöglich {{Link2Forum|Topic=10510|LinkText=nicht angeraten}}.

Ferner ist der Einsatz eines CUL als [[RFR CUL]] für den ''SlowRF'' Mode (jedoch nicht für den ''HomeMatic'' Mode) möglich, um die Reichweite zu erhöhen. Die Verbindung erfolgt hierbei über Funk, sodass keine USB Verbindung zum FHEM Hostrechner erforderlich ist.

Alle diese Modi sind in der Original-[[#FW|culfw]] enthalten und werden z.B. durch die Wahl des ''rfmode'' eingestellt.

Obwohl die eigentliche Betriebsfrequenz der FHT und FS20-Komponenten 868,35 MHz ist, ist bei den aktuellen CUL Firmwareversionen zum Betrieb mit FHEM die Frequenz auf 868,30 MHz eingestellt. Dies hat sich als Kompromiss zum besseren Empfang von EM1000EM (Energiemonitor) Geräten bewährt, '''obwohl''' diese nominal mit 868,360 MHz arbeiten. Praktisch ist die Genauigkeit der Sendefrequenz der meisten ''SlowRF'' Geräte wegen der primitiven Sender sehr schlecht und kann deutlich von der nominalen Frequenz abweichen.

Frequenz und Bandbreite können daher im ''SlowRF'' Mode frei angepasst und somit für die örtlichen Empfangsgegebenheiten optimiert werden.

== Hinweise zum Betrieb mit FHEM ==
'''Anmerkung:''' Nachfolgende Beispiele sind so wie dargestellt in die FHEM-Eingabezeile oder per Telnet auf FHEM zu übertragen und per <Taste>Enter</Taste> abzuschicken (nicht "save" klicken); '''''myCUL''''' ist dabei nur ein Platzhalter und durch den Namen '''Ihres''' CUL zu ersetzen. Da diese Funktionen durch die culfw (Firmware) bereitgestellt werden, funktionieren sie auf allen Geräten, die die culfw verwenden ([[CUNO]], [[COC]], CSM:

* Ist Empfang eingeschaltet ?
*: <code> get myCUL raw C35</code> (13 = ja, z. b.: C35 = 0D / 13)
* Auslesen der culfw Version:
*: <code>get myCUL raw V</code>
* LED ausschalten (Achtung: Buchstabe l (L) vorweg für LED, keine Zahl 1)
*: <code>set myCUL raw l00</code>
* LED einschalten
*: <code>set myCUL raw l01</code> Blinkt bei Senden oder Empfangen von Paketen
* LED soll blinken (einmal in der Sekunde)
*: <code>set myCUL raw l02</code>
* Reboot / Reset des CUL:
*: <code>set myCUL raw B00</code> Andere Werte als 00 starten das CUL im Bootloader-Modus (=> neue Firmware)
* Freie CUL Sendezeit ([[1% Regel]]):
*: <code>get myCUL raw X</code> 2. Wert ist Sendezeit in 10ms Slots, ein FS20 Befehl braucht ca. 210ms (also 21 Slots), eine FHT Kommunikation wesentlich mehr. Alternativ auch <code>get myCUL credit10ms</code> ergibt Sendezeit in 10ms Slots
* Freie Kapazität des FHT Buffers
*: <code> get myCUL raw T03</code> Ergebniss bytes in HEX. Leer = 4a
* Inhalt des FHT Buffers
*: <code> get myCUL raw T02</code> (CUL V2 Buffer ist 74 Bytes gross, Platz für 14 bis 31 FHT Messages). Rückgabe n/a = Buffer ist leer
* Eingestellte [[Was_ist_der_Hauscode%3F|FHT-ID]]
*: <code> get myCUL raw T01</code>
* Eingestellte Frequenz, Bandbreite etc. Ausgeben
*: <code> get myCUL ccconf</code>. Rückgabe z. B.: <code><nowiki>myCUL ccconf => freq:868.300MHz bWidth:325kHz rAmpl:42dB sens:4dB</nowiki></code>
* eingestelle Bandbreite erhöhen (z.b. auf 464 kHz, mehr hat meist keinen Sinn):
*:<code>set myCUL bWidth 464</code>
* Einstellen der Sendestärke:
*: <code>set myCUL raw x09</code> Einstellen der Sendeleistung.

Gültige Werte für die Sendeleistung sind 00-09. Verwendet werden sollten nur die Werte 05-09, diese entsprechen
-10/-5/0/5/10 Sendeleistung in db. Default ist x08 = +5db. Bitte im Interesse von Nachbarn und der Abhörsicherheit den kleinsten problemlos funktionierenden Wert einstellen. Dies ist meistens x07 oder x08. Da speziell die Kommunikation mit den FHTs bidirektional ist, kann die Kommunikation durch höhere Werte oft nicht verbessert werden, da die FHTs selber dadurch nicht stärker senden. Besser versuchen, Lage und Antennenausrichtung des CUL zu verändern. Siehe auch Diskussion unter [https://groups.google.com/group/cul-fans/browse_thread/thread/683ca5c892eae1c3/c682a640f1ba863c?lnk=gst&q=bWidth+freq#c682a640f1ba863c GoogleGroups-CUL-Fans]

Werte x00-x04 sind '''mit''' Ramping und führen zum Verlust der Kommunikationsfähigkeit mit anderen CULs, z. B. [[RFR CUL]].

'''Hinweis:''' Beim CUL im HomeMatic-Modus kann man (ohne Firmware-Modifikation) die Empfangs-/Sendeparameter '''nicht''' verstellen. Die üblichen freq/x09 etc. haben hier keine Wirkung ({{Link2Forum|Topic=10203|Message=57191|LinkText=Quelle}}).

Weiterhin kann man zunehmend mehr Debuggingoutput auf dem CUL einschalten mit :
* <code> set CUL1 raw X61</code> Communication wird im Detail angezeigt
* <code>set CUL1 raw X25</code> auch checksum Fehler / unerkannte Protokolle werden gemeldet
* <code>set CUL1 raw X2F</code> alle empfangenen Flanken werden gemeldet
* <code>set CUL1 raw X80</code> RSSI / Signalstaerke jeder Flanke wird gemeldet
* <code>set CUL1 raw X21</code> normal Modus

Achtung: Auf Gross- und Kleinschreibung des "x,X" achten!

Die kompletten Kommandos mit Erklärung für CUL sind in der [http://culfw.de/commandref.html commandref] zu finden.

== Versionen ==
Das CUL gibt es in mehreren Versionen, die sich überwiegend in Prozessor und Speicherkonfiguration unterscheiden.

* CUL V1 - AT90USB162 Prozessor, 0,5Kb RAM, 16Kb Flashmemory, 0,5 kByte EEPROM. Einsatzfähigkeit unbekannt (aber vermutlich wie V2). Wird nicht mehr hergestellt.
* CUL V2 - AT90USB162 Prozessor, 0,5Kb RAM, 16Kb Flashmemory, 0,5 kByte EEPROM. Einsatzfähig. Der Flashspeicher ist jedoch zu klein für eine culfw (CUL Firmware), die Code für ''SlowRF'' Geräte und zugleich ''HomeMatic'' Geräte enthält. Es muss also vor dem Flashen der Firmware zwischen zwei jeweils reduzierten Versionen gewählt werden. Da ein CUL ohnehin nicht beide Sendemodi '''zeitgleich''' betreiben kann, ist dies keine wirkliche Einschränkung. Wird nicht mehr hergestellt.
* CUL V3 - ATMega32U4 Prozessor, 2,5 kB RAM, 32 kB Flashmemory, 1 kByte EEPROM). Voll einsatzfähig.
* CUL V4 - ATMega32U2 Prozessor, 1 kB RAM 32 kB Flashmemory, 1 kByte EEPROM. Voll einsatzfähig. Genau genommen ein "Sparmodell" des V3, um Lieferengpässe des atmega32u4 Prozessors zu umgehen. Der reduzierte RAM-Speicher verursacht (zumindest gegenwärtig) beim Betrieb mit culfw und FHEM keine Einschränkungen oder Nachteile. Achtung: Flashen des CULv4 setzt DFU-Programmer 0.5.4 oder höher voraus.

Die für die aktuellen Modelle lieferbare Abschirmung ist in der Regel nicht notwendig.

== Firmware {{Anker|FW}} ==
Die für den CUL und verwandte Hardware wie [[CUN]] und CUR im Zusammenhang mit FHEM überwiegend eingesetzte Firmware culfw findet sich auf der
* [http://culfw.de CUL Firmware Homepage]
Dort kann die jeweils aktuelle Version nachgesehen und herunter geladen werden.
Alten Stände, Version für Entwickler und ganz aktuelle Änderungen findet man auf der
* [https://sourceforge.net/projects/culfw/ Sourceforge Projektseite der culfw]
Hier kann man sich z.B. mit
<syntaxhighlight lang=bash>
svn co svn://svn.code.sf.net/p/culfw/code/trunk/culfw
</syntaxhighlight>
die aktuelle Version laden.

Zusätzlich gibt es folgende Forks der originalen culfw mit speziellen Anpassungen:
* [https://github.com/heliflieger/a-culfw Alternative culfw for cul devices] auf GitHub und im {{Link2Forum|Topic=35064|LinkText=Forum}} mit Anpassungen unter anderem für InterTechno. Hier könnte es aber zu Funktionseinschränkungen bei anderen Protokollen kommen. In dieser Version ist auch ein Portierung auf ARM-Prozessoren enthalten (siehe {{Link2Forum|Topic=38404|LinkText=Forum}}) mit der die CUL-Firmware auch auf dem HM-CFG-USB-2 und dem [[MAX]] Cube betrieben werden kann.
* {{Link2Forum|Topic=24436|LinkText=Timestamp Firmware}} mit speziellen Anpassungen für HomeMatic. Bei HomeMatic ist das Timing der Telegramme entscheidend sonst kann es zu "MISSING ACK" bzw. "RESPONSE TIMEOUT REGISTER READ" u.ä. Meldungen kommen.

Generell ist das Angebot an Speicherplatz auf dem im CUL verwendeten ATMega32U2 sehr eingeschränkt, wodurch Erweiterungen ohne Abstriche an anderer Stelle kaum mehr möglich sind. Es wird also die optimale CUL-Firmware für alle Zwecke nie geben, so dass man die Auswahl am konkreten Bedarf klären muss. Wer die Firmware selbst compiliert kann gezielt Funktionen die nicht benötigt werden weg lassen und dafür ggf. Funktionen die sonst nicht eingefügt sind hinzufügen.

== Sendefrequenz ==
Das CUL gibt es in Ausführungen für 868 und 433 MHz.
Die Sende- und Empfangsfrequenz des CUL sind in weiten Bereichen einstellbar, im ''SlowRF'' Mode auch durch direkte Befehle aus FHEM (im ''HomeMatic'' Mode derzeit nicht unterstützt). Der wesentliche Unterschied der 868 und 433 MHz CULs ist ein auf die Frequenz richtig abgestimmter HF-Eingangskreis inklusive Antennenlänge.

Es ist es durchaus möglich, ein 868 MHz CUL auf 433 MHz einzustellen. Da dann aber die HF-Eingangskreis-Abstimmung und Antennenlänge nicht korrekt sind, ist Empfangs- und Sendeleistung suboptimal, die Reichweite sinkt. Dennoch wird diese Möglichkeit des freien Einstellens durch das FHEM Intertechnomodul genutzt, da Intertechnokomponenten mit 433 MHz arbeiten. Dazu wird beim Senden eines Intertechno-Befehls die Frequenz eines 868 MHz CULs kurz umgestellt.

== Antenne ==
Der CUL ist mit RP-SMA-Stecker für die Antenne aber auch mit angelöteter Drahtantenne lieferbar.
Funktional besteht kein Unterschied: auch die "richtige" Antenne ist (in diesem Fall) nur ein Draht, jedoch gummiummantelt und eventuell mit einem Knickgelenk und einem Schraubanschluss versehen, d.h. die Drahtantenne sieht nur unschön aus.

Wichtig ist nur die Länge. Diese muss vorteilhafterweise so groß sein wie ein Viertel der Wellenlänge der Frequenz ("Lambda/4"). Die sind bei 868 Mhz ca. 8,6 Zentimeter. Antennenlängen die länger oder kürzer sind verschlechtern in der Regel die Leistung. Daher ist eine z.B. 10 Zentimeter lange Antenne (obwohl länger) schlechter als 1/4 Lambda mit 8,6 Zentimeter.

Über besondere Antennenkonstruktionen (bitte nach Colinear, Jpole, Yagi suchen) oder Antennen die "Lambda/2" oder gar ("Lambda") lang sind (also ca. 17,2 bzw. 34,5 Zentimeter) kann ein höherer Gewinn erreicht werden. Einher geht aber gleichzeitig eine stärkere Richtwirkung der Antenne. Je kürzer die Antenne, desto kugelförmiger die Abstrahlung. Bei längeren Antennen wird die Abstrahlung mehr und mehr zylinderähnlich, also mit horizontaler Richtwirkung (und in die Richtung ist das Signal dann stärker, daher der Antennen"gewinn").
Das hat auch Nachteile, speziell wenn man auch "nach oben" funken will. Speziell wenn man Antennen länger als eine λ/4 Antenne (8,6 Zentimeter) in einem mehretagigen Haus verwenden will, muss man diese daher in der Regel waagerecht/horizontal ausrichten, da alles was in Richtung der Spitze (und dem Fuss) der Antenne liegt schlecht Empfangen wird.

Daher: Je mehr Gewinn die Antenne aufweist, desto besser ist die Sende und Empfangsleistung, aber desto mehr Gedanken muss man sich um die Ausrichtung der Antenne machen, um alle Geräte zu empfangen / zu erreichen. "Mehr db" und speziell "länger" ist also nicht automatisch besser.

Zu beachten, ist auch, dass die Sendeleistung der Module gesetzlich geregelt ist und Spezialantennen mit höherem Gewinn ggf. nur an Empfängern erlaubt sind.

Falls man den CUL mit RP-SMA Stecker geordert hat, aber keine passend lange RP-SMA-Antenne verfügbar ist, kann (nur für erste Tests) auch eine abschraubbare Antenne für 802.11b/g WLAN-Geräte (2,4 GHz) benutzt werden, so diese anschlusstechnisch auf den RP-SMA-Stecker des CUL passt (dies funktioniert zumindest mit FS20- und EM-Geräten). Deren Länge ist wie oben diskutiert aber nicht optimal, besser ist auf jeden Fall eine speziell auf den Einsatzzweck (Frequenz) abgestimmte Antenne.

== Antennenlänge ==
Die genauen Antennenlängen sind praktisch schwer zu ermitteln, da auch Zuleitung auf dem CUL zugerechnet werden müssten und ggf Dämpfungen (also z.b. Durchführung der Antenne durch eine Gehäuse, oder gebogene Antennen) die Antennenlänge weiter beeinflussen. Gleichzeitig haben schon Abweichungen von wenigen Millimetern messbaren Einfluss. Die Antennenlänge ist daher immer nur eine Kompromiss.

Exact berechnet ohne Störeinflüsse wären folgende Antennelängen nutzbar:
868,35 Mhz (z.B. HM, FS20, FHT …)
1/4 Lambda = 8,63 Zentimeter
1/2 Lambda = 17,26 Zentimeter
1 Lambda = 34,52 Zentimeter (Bereits sehr hohe Richtwirkung)

433,92 Mhz (z.B. Intertechno …)
1/4 Lambda = 17,27 Zentimeter
1/2 Lambda = 34,54 Zentimeter

Folgende Antennenlängen bieten sich praktisch an, diese sind immer etwas kürzer als die optimale Länge, dies wird z.T. durch Leiterlänge im CUL kompensiert.:

8,6 Zentimeter als 1/4 Lambda für 868,35 Mhz
17,2 Zentimeter als 1/2 Lambda für 868,35 Mhz und zugleich 1/4 Lambda für 433,92 Mhz
34,5 Zentimeter als Lambda für 868,35 Mhz und zugleich 1/2 Lambda für 433,92 Mhz

== Bekannte Probleme ==
Im Gegensatz zu den original FHZ Zentralen ist das CUL recht schmalbandig, d.h. die Sende- und Empfangsfrequenz wird genauer eingehalten als z. B. bei einer FHZ1x00PC. Dies kann im Zusammenhang mit den eher ungenauen Sendern z. B. der FHT Raumregler zu Empfangsproblemen führen. Es kann daher mitunter sinnvoll sein, die Sende- und Empfangsbandbreite des CUL etwas zu erhöhen. Dies senkt jedoch gleichzeitig die Empfindlichkeit.

Bei Empfangsproblemen von z. B. HEM-Sensoren oder dem S300TH kann man folgendes testen:

* Man kann die Frequenz des CUL auf genau 868,35 MHz einstellen. Standardmäßig ist hier aus Kompatibilitätsgründen 868,30 MHz eingestellt. Diese Einstellung wird fest im NVRAM gespeichert und braucht nur einmal vorgenommen zu werden.
*: <code>set CUL freq 868.350</code>
* Es ist möglich die "decision boundary" zu vergrößern, frei beschrieben: die "Entscheidungsgrenze" ob die empfangene Signalflanke digital "0" oder "1" darstellte ({{Link2Forum|Topic=8572|Message=44388|LinkText=siehe Diskussion hier}}). Möglich sind die Werte "4", "8" und "16". Default-Einstellung ist hier "4". Zur Steigerung der Empfangsqualität soll es hilfreich sein, hier "8" einzustellen. Mitunter bringt jedoch erst die Einstellung auf "16" signifikante Verbesserungen beim Empfang von S300TH-Sensoren.
*: <code>set CUL sens 8</code>
* Oft hilft auch, die Bandbreite auf z. B. 464 kHz aufzuweiten.
*: <code>set CUL bWidth 464</code>

== Selbstbau-/Bastelprojekte ==
Innerhalb der FHEM-Community werden mittlerweile diverse Bastelprojekte zum Selbstbau eines CUL betrieben. Eine Auswahl dieser Projekte:
* [[Selbstbau CUL]]
* [[FHEMduino]]
* [[SIGNALduino]]
* [[MapleCUN]] mit STM32 Mikrocontroller

== Links ==
* Hersteller / Bezugsquelle für CUL: [http://www.busware.de/tiki-index.php?page=CUL busware.de]
* Google groups [https://groups.google.com/group/cul-fans/ CUL fans], mittlerweile durch das Board {{Link2Forum|Area=cul-fans}} im [http://forum.fhem.de/index.php FHEM Forum] ergänzt/ersetzt

[[Kategorie:Interfaces]]
[[Kategorie:CUL]]