Dokumentation zur Konfiguration von FHEM-Devices mit Alexa

[Prof. Dr. Peter Henning]

André (justme1968) ist heftig mit der Weiterentwicklung von Fhem-Alexa-beschäftigt, das ist auch gut so. Klar, dass in einem solchen Stadium die Dokumentation auf der Strecke bleibt.

Ich habe mir deshalb ein paar Stunden Zeit genommen, und nicht nur die Wiki-Seite zur Installation überarbeitet.

Es gibt jetzt darüber hinaus im FHEM-Wiki eine Kategorie Sprachsteuerung, https://wiki.fhem.de/wiki/Kategorie:Sprachsteuerung mit derzeit 3 Seiten darin: Installation, Tipps und - noch in Arbeit - eine Dokumentation des ganzen Mapping-Zeugs, https://wiki.fhem.de/wiki/Alexa_und_Mappings

Die habe ich begonnen, weil ich mehrfach über zumindest mir nicht ganz klare Begriffe. gestolpert bin. Außerdem sieht man an einer solchen Dokumentation auch, wo noch Nachbesserungsbedarf herrscht: Warum beispielsweise heißt die eine Charakteristik "LockCurrentState/LockTargetState", die andere aber "CurrentDoorState/TargetDoorState" ?

Ich hoffe, dass ich nicht alleine dabei bleibe, das Wiki an dieser Stelle auszubauen.

LG

pah

[doman75]

Da ist eine super-idee, habe das mit dem fensterkontakten auch mal ausprobiert, nur bringen tut es irgendwie nix, der abfragestatus ist immer noch nur der batteriestand.

Das mit dem Humidity hab ich auch probiert bei einem "Status von Thermometer" sagt Alexa aber weiterhin "Thermometer misst 20,7 Grad"

VG
Swen

[Prof. Dr. Peter Henning]

Eben. Und damit wir nicht alle immer nur im Nebel stochern, die Wiki-Seite. Ich würde mich über Ergänzungen aller Art freuen.

LG

pah

[justme1968]

hier noch mal etwas zum hintergund...
                                   
das alexa smart home api kennt leider auser lampen und thermostaten keine weiteren geräte typen. und auch sonst keine abstraktion die über ein/aus/temperatur schalten hinaus geht.
                                   
um geräte differenzierter anzusprechen ist (zumindest aktuell) ein custom skill nötig. in diesem kann man dann mit konzepten wie geräte typen, räumen und eigenschaften arbeiten.
                                   
                                   
im gegensatz dazu bietet apples homekit von haus aus eine recht fein differenzierte unterscheidung nach geräte typen und eigenschaften.
                                   
da ich schon vor einiger zeit die anbindung von homekit/homebridge an fhem gemacht habe hat es sich angeboten das rad nicht neu zu erfinden sondern code und konzepte so weit wie möglich zu übernehmen. das erlaubt auch die identische konfiguration für alexa und siri.
                                   
                                   
kurz: sowohl homebridge-fhem als auch alexa-fhem gehen davon aus das geräte bestimmte eigenschaften haben. diese eigenschaften können read only (z.b. aktuell gemessene temperatur) sein oder durch den benutzer veränderbar (z.b. gwünschte raum temperatur).
                                   
d.h. über die genericDeviceType und homebridgeMapping attribute  wird die sehr variable FHEM welt (device abhängige readings und set kommandos mit unterschiedlichen namen) in eine eher abstrakte und semantisch eindeutigere zwischenschicht überführt (fest definierte characteristics mit festen eigenschaften).
                                   
homebridge-fhem und alexa-fhem versuchen die häufisgten devices so automatisch wie möglich zu erkennen. wo dies nicht ausrecht ist eine komplett freie konfiguration möglich. das konzept des homebridgeMapping ist hier: https://forum.fhem.de/index.php/topic,48558.msg402024.html#msg402024 und hier: https://github.com/justme-1968/homebridge-fhem/blob/master/README.md beschrieben.
                                   
                                   
da die homekit anbindung zuerst da war und das konzept gut funktioniert kommen die namen für die eigenschaften (characteristics) die ein gerät hat direkt aus dem apple homekit api. ebenso ungereimtheiten wie LockTargetState vs. TargetDoorState. welche services mit welchen characteristics es dort gibt ist hier zu finden: https://github.com/KhaosT/HAP-NodeJS/blob/master/lib/gen/HomeKitTypes.js
                                   
                                   
im gegensatz zu homekit, das von haus aus die information aus den characteristics bei der sprachanalyse verwendet, muss dies für alexa im custom skill selber implementiert werden. hier kommt das alexaMapping ins spiel. hierüber wird konfiguriert welches gesprochene kommando auswirkung auf welche characteristic hat.
                                   
d.h. das alexaMapping gibt an welches gesprochene kommando welche eigenschaft eines gerätes betrifft und das homebridgeMapping gibt an welches welches eigenschaft durch welches reading und kommando beeinflusst wird.

im alexaMapping lassen sich auch zusätzliche characteristics 'erfinden' wenn die bereits definierten nicht ausreichen. hier sollte man das konzept der 'eigenschaft' verstanden haben. eine characteristic zum umschalten sollte man z.b. Sender oder Kanal nennen. nicht TV.
                                   
                                   
dieser zwischenschritt der abstrakten eigenschaften erlaubt es geräte zu gruppen zusammen zu fassen (alle rolläden im erdgeschoss, alle lampen im wohnzimmer,...) und auch geräte unterschiedlicher hersteller auf die gleiche art auzulesen und anzusprechen (HM,MAX,PID20: desired-temp vs. desiredTemperature vs. desired, HM,DUOFERN,SOMFY: pct vs. position, 0 vs. 100, ...) und das auch in kombination. d.h. ein kommando wie 'mach das licht im wohnzimmer an' kann hue, fs20, hm,... lampen gemeinsam schalten.
                                   
                                   
zum aktuellen alexa entwicklungsstand:
- mit homebridgeMapping und alexaMapping ist es möglich jedes fhem gerät zu steuern
- es gibt eine reihe der häufigsten eigenschaften die sich als status abfragen lassen
- mit den fhemIntents ist es möglich über alexa beliebigen fhem oder perl code anzustossen und sprachrückmeldung zu geben
- die nächste version wird alle konfigurierten und erkannten characteristics als status abfragen können
- damit das auch sprachlich vernünftig wird gibt es dann eine möglichkeit diese abfragen zu konfigurieren
                                 
gruss
  andre

[Master_Nick]

Kann man das ggf. für eine gewisse Zeit pinnen?

[Prof. Dr. Peter Henning]

Unnötig. Ist bereits in die Wiki-Seite eingearbeitet.

André, zwei konkrete Fragen.

1. Ist der genericDeviceType überflüssig, wenn ein homebridgeMapping mit mindestens einer Characteristic definiert wurde ?
2. Hast Du irgendwo eine Liste der tatsächlich  verwendeten Characteristics (LockCurrentState kommt z.B. in Deinem github-Text nicht vor).

LG

pah

[justme1968]

der genericDeviceType ist nur dann unnötig wenn er automatisch aus dem fhem device erkannt werden kann.

mein code schaut zur laufzeit per 'introspektion' im homekit/homebridge code nach. d.h. alle im oben verlinkten HomeKitTypes.js vorhandenen characteristics können verwendet werden.

gruss
  andre

[justme1968]

ich weiß nicht ob du im wiki die diskussions seite dazu im auge hast. ich habe da etwas ergänzt.

gruss
  andre

[Prof. Dr. Peter Henning]

Sehe ich mir an, danke.

LG

pah