fhem-skill für mycroft.ai

[dkreutz]

Es gibt ja neben Alexa und Co. noch mehr Sprachassisten, darunter mycroft.ai, der mich aufgrund des Opensource/Cloudfree-Gedanken angesprochen hat. Mycroft gibt es als Hardware in Form des Mark-I und ab Dezember auch einen Mark-II (z.B. bei Kickstarter oder Indiegogo), weiter ist es lauffähig auf dem Raspberry Pi3 (fertiges PiCroft-Image) und auf  verschiedenen Linux-Distributionen. (Des weiteren gibt es eine Version für Android und mit einem noch nicht offiziell unterstützten Docker-Image läuft es angeblich auch auf MacOS)

Inzwischen werkelt bei mir ein Mycroft Mark-I und eine weitere Mycroft-Instanz auf Grundlage des Google AIY VoiceKit als "Entwicklungssystem".

Nachdem ich meine Python-Programmierkenntnisse durch anpassen und "übersetzen" vorhandener Skills aufgefrischt habe, sitze ich nun an einem Skill für FHEM (auf Grundlage eines bereits vorhanden Skills für Homeassistant / hass.io, den ich "geklont" habe, um schon einmal die grundsätzliche "Intent"-Verarbeitung zu haben).

Ich habe erst einmal einen na(t)iven Ansatz gewählt und spreche FHEM direkt über das Webinterface an, das heißt es ist kein Modul in FHEM erforderlich. Außerdem habe ich die Konventionen von der Homebridge/Alexa Anbindung übernommen: die von Mycroft ansprechbaren Devices müssen sich im Raum "Homebridge" befinden und das Attribut "genericDeviceType" muss gesetzt sein. Aktuell werden die Typen "light", "switch" (für Schalter/Lampen die EIN und AUS verstehen), "thermostat" und "sensor" (Sensoren, Thermometer, etc.) unterstützt.

Hier geht es zum Repository für den FHEM-Skill: https://github.com/domcross/fhem-skill.git

Für die Installation folgt man am besten der Dokumentation des Mycroft Skill Manager (Vorbereitung des Environments) und installiert dann per

Code Auswählen Erweitern

msm install https://github.com/domcross/fhem-skill.git
Nach kurzer Wartezeit müsste dann im persönlichen Mycroft-Home unter "Skills" die Konfiguration für FHEM auftauchen. Dort unter "Host" die IP/den DNS-Namen und unter "Port" die Portnummer des eigenen FHEM-Servers eintragen. (SSL und Verify wird noch ignoriert).

Weitere Fragen gerne hier oder im Mycroft-Forum oder Mycroft-Chat (Channels "dev", "skills", "home-automation")

Im angehängten Video bekommt man eine Vorstellung davon, was bisher mit dem Fhem-Skill möglich ist...

_{EDIT: Aktualisierung der unterstützten genericDeviceTypes}

[dkreutz]

Der fhem-skill kann jetzt auch als "Fallback" (wenn Mycroft keinen passenden Skill für die Anfrage findet) mit einem NLUI-Device sprechen.

Ist in der Skill-Konfiguration für den FHEM-Skill die "Fallback" Option aktiviert, so wird bei der Initialisierung nach einem Device mit TYPE Talk2Fhem, TEERKO oder Babble gesucht und wenn (genau) eins gefunden wurde, wird die Anfrage im Fallback-Szenario daran weiter geleitet. Gibt das NLUI-Device eine Antwort, so wird diese von Mycroft "vorgelesen".

Siehe angehängtes Video für eine Demonstration: Lampe schalten passiert im fhem-skill, Temperaturabfrage und Kaffee kochen in Talk2Fhem.

Jegliches Feedback ist herzlich willkommen...

EDIT: Update - neben Talk2Fhem auch TEERKO und Babble möglich

[dantist]

Klasse, dass sich etwas in Richtung Mycroft tut! Sobald mein Mark II eintrudelt, werde ich den Skill auf jeden Fall testen.

Eine (vielleicht blöde) Frage: Kann ich im Skill oder in FHEM natürlich klingende Sätze/Satzfetzen hinterlegen, z.B. "Heimkino starten" und passend dazu, welche FHEM-Befehle daraufhin ausgeführt werden sollen? Also ganz losgelöst von der direkten Ansprache einzelner Devices.

[dkreutz]

Kann ich im Skill oder in FHEM natürlich klingende Sätze/Satzfetzen hinterlegen, z.B. "Heimkino starten" und passend dazu, welche FHEM-Befehle daraufhin ausgeführt werden sollen? Also ganz losgelöst von der direkten Ansprache einzelner Devices.

Aktuell werden Befehle zum Schalten von Lampen und Steckdosen (ein/aus) und die Abfrage von Sensoren (es wird der Status/STATE ausgegeben) unterstützt. Weiter gibt es die Fallback-Funktion, die ich bisher erfolgreich mit Talk2Fhem getestet habe. Damit kannst Du dann in FHEM individuelle Phrasen mit Aktionen hinterlegen. Wenn Du dann mit der Phrase "Heimkino starten" mit z.B. einer Lichtszene oder Structure hinterlegst, kannst Du selber bestimmen was und wie mit der Phrase ausgelöst wird. Das ist nicht zu unterschätzen, da Du so Deine ganze individuelle "Sprache" verwenden kannst und flexibel auf Änderungen reagieren kannst und auch exotische Fhem-Devices ansteuern kannst.

Weiter plane ich neben Talk2Fhem auch TEERKO und Babble als Fallback-Device anzubinden (sofern ich heraus finde, wie ich dort die erfolgreiche bzw. nicht erfolgreich Erkennung einer Phrase abfragen kann). Damit sind dann die drei am weitesten verbreiteten "natural language user interfaces" unterstützt (wenn nach man der FHEM-Statistik geht).

Außerdem schaue ich mir an, ob noch weitere generische Devicetypen, z.B. Dimmer/Farbsteuerung, Lightscene, etc. sinnvoll in dem fhem-skill unterstützt werden können.

[dantist]

Sehr cool. Wenn man etwas initialen Aufwand in die Fallback-Regeln steckt, könnte das ziemlich beeindruckend werden, was die Verwendung natürlicher Sprache angeht. Funktioniert das eigentlich schon auf Deutsch? Die Mycroft-Macher drücken sich immer um konkrete Antworten, was multi language-Support angeht.

[dkreutz]

Funktioniert das eigentlich schon auf Deutsch? Die Mycroft-Macher drücken sich immer um konkrete Antworten, was multi language-Support angeht.

Mein Mycroft-Entwicklungssystem läuft mit Spracheinstellung "de", den fhem-skill habe ich bis jetzt noch gar nicht auf Englisch getestet.

Inzwischen haben die Skills, die im Standard mit ausgeliefert werden, alle auch eine deutsche Übersetzung. Allerdings sind diese teilweise sprachlich noch etwas hölzern. Der Datum/Uhr-Skill reagiert bei mir z.B. nicht auf "Wieviel Uhr ist es?" sondern nur auf "nenne die Uhrzeit".

Die internationale Sprachunterstützung ist aber ein Punkt auf der Mycroft-Roadmap

[shilbert]

FYI:

Ich habe auch immer nach mycroft geschaut. Leider kam ich da nicht weiter und bin inzwischen bei snips.ai gelandet. Da wird gerade intensiv an einem fhem-Modul entwickelt.

Funktioniert sehr gut u.a. mit dem Google AIY-Kit

https://forum.fhem.de/index.php/topic,89548.165.html

[dkreutz]

Kleines Update zum FHEM-Skill für Mycroft:

Username, Passwort und SSL werden im Programmcode unterstützt, das habe ich aber noch nicht getestet.

Damit der Skill ein FHEM-Device "erkennen" kann, muss ein FHEM-Device folgende Bedingungen erfüllen:
1) das Device befindet sich in Raum "Homebridge" (Defaultwert, kann in der Skill-Konfiguration geändert werden)
2) das Device hat ein Attribut "genericDeviceType", aktuell kann der Skill folgende Werte "erkennen": 'light', 'switch', 'outlet', 'sensor', 'thermometer'

Außerdem kann der FHEM-Skill als "Fallback" arbeiten: wenn Mycroft keinen Skill findet der die erkannte Phrase direkt verarbeiten kann, werden die Fallbacks durchprobiert. Damit der FHEM-Skill als Fallback arbeiten kann, muss ein Device vom Typ Talk2Fhem oder TEERKO (das ist neu) für den FHEM-Skill konfiguriert werden. Talk2Fhem funktioniert aus Skill-Sicht besser, da hier ein Feedback erfolgt wenn Talk2Fhem die Phrase nicht verarbeiten konnte. Mycroft kann dann ggfs. weitere Fallbacks durchprobieren.

[blofield]

Moin,

erstmal großartig, dass Du einen Skill für FHEM gebaut hast!
Ich habe seit langer Zeit einen Mark I und als ich im Forum über diesen Beitrag gestolpert bin, habe ich es auch gleich versucht!

Allerdings funktioniert es bei mir leider nicht auf Anhieb ;(
Ich muss allerdings sagen, dass ich meinen Mark I noch auf english laufen habe, weil es bei Inbetriebnahme noch keine deutsche Version gab (Habe zudem im MyCroft Forum keine wirklich gute Anleitung gefunden, wie die Spracheinstellungen zu ändern wären). In Deinem Github Repo habe ich gesehen, dass aber für english auch alles vorbereitet ist.

Was ich gemacht habe:

• global attr genericDeviceType:light,switch,sensor,thermometer angelegt
• Raum "Homebridge" angelegt
• Einen vorhandenen HM-LC-Sw1-Pl-DN-R1 zu Ansteuerung einer Stehlampe als "lamp" benannt, bei diesem das genericDeviceType auf "switch" gestellt und dem Raum "Homebridge" hinzugefügt
• Dann ein neues FHEMWEB mit User und PW für Mycroft eingerichtet und getestet
• Diese Werte unter home.mycroft.ai im Skillmanager eingetragen

und gehofft ein "Hey Mycroft, turn on lamp" würde die Lampe schalten.
Allerdings bekomme ich ein : >> Sorry, I can't find the fhem entity "lamp".

Was ja schonmal bedeutet, das Mycroft im richtigen Skill gelandet ist. Aber, ....


Was habe ich übersehen?
Danke
blofield

[blofield]

So,

ich habe jetzt mal geschaut woran es lag:

• Leider hat msm bei mir kein einziges der Requirements geladen, weswegen ein Verbindungsaufbau zu fhem leider nicht geklappt hat, dies ließ sich aber durch manuelles nachinstallieren schnell fixen.
• Zudem funktioniert das User:PW via SSL leider nicht, da bekomme ich immer einen HTTP 401, erst wenn ich basicAuth im allowed_Web entferne geht es.

P.S.: Funktioniert in english auch

Grüße blofield

[dkreutz]

Hallo Blofield,

Danke fürs testen. Ich habe gerade eine Änderung in den Master-Branch commitet.
Damit funktioniert jetzt User/Passwort über BasicAuth. (SSL Support ist immer noch ungetestet)

Außerdem wird der GenericType "thermostat" jetzt unterstützt (funktioniert mit Devices die "set desired-temp ..." verstehen, z.B. die Homematic Thermostate):
"Hey Mycroft, ändere Thermostat Kinderzimmer auf 22 Grad"

[blofield]

Hallo dkreutz,

User:PW funktioniert bei mir

Thermostat funktioniert leider nicht (getestet mit FHT80b & HM): Mycroft meldet korrekt die Umsetzung, in fhem wird aber nichts gesetzt, weil an den Entity-Name automatisch ein '_Clima' angehängt wird.

Ich spiele da jetzt aber mal intensiver mit rum...

Grüße
blofield

[dkreutz]

Update: Verbesserte Unterstützung für Thermostate

Es werden "nativ" Thermostate unterstützt, die über Reading/Command

• "desired-temp" (CUL/HM, FHT, Comet-Dect)
• "desiredTemperature" (MAX)
• "desired" (PID20)

gesteuert werden, des weiteren auch Thermostate mit einem

• homebridgeMapping für die Charakteristik "TargetTemperature".

Bei HM-Thermostaten wird automatisch das _Clima-Device (channel_04) ermittelt.
Außerdem gibt es einen Bugfix für die Verwendung von Aliasnamen (Danke an Blofield / Github-User "apunkt").

[blofield]

Nachdem ich nun 1 Woche auf Mycroft umgestellt habe, nutze ich mein andFHEM auf dem Handy fast gar nicht mehr.
Die ganze Familie hat auf einmal Spaß am Smart Home! - so soll das sein

Ich bräuchte allerdings noch mal einen Config-Tip, wie man Mycroft mit Talk2Fhem zum laufen bekommt.

Im Mycroft Skill Config habe ich NLUI richtig angegeben, er sagt allerdings im DebugLog, das Fallback nicht aktiviert wäre und versucht dann die anderen Fallback-Skills wie Wolfram Alpha ...

Danke!
blofield

Gesendet von meinem ONEPLUS A5000 mit Tapatalk

[dkreutz]

Update: Unterstützung von Babble als NLUI-Fallback-Device.

In der Skill-Konfiguration unter home.mycroft.ai kann als "NLUI Fallback Device" auch der Name eines Babble-Device angegeben werden.
Wenn Mycroft die Anfrage nicht selbst beantworten kann, wird diese dann an das Babble-Device durchgereicht. Die Rückmeldung von Babble wird entsprechend verarbeitet, d.h. wenn Babble mit der Anfrage nichts anfangen kann, wird dies Mycroft-intern erkannt und die Anfrage an weitere ggfs. vorhandene Fallback-fähige Skills weitergeleitet.

Damit werden jetzt als NLUI-Fallback unterstützt: Talk2Fhem, TEERKO, Babble.

Nachdem ich nun 1 Woche auf Mycroft umgestellt habe, nutze ich mein andFHEM auf dem Handy fast gar nicht mehr.
Die ganze Familie hat auf einmal Spaß am Smart Home! - so soll das sein

Das freut mich und da bist Du mir sogar einen Schritt voraus - hier läuft Mycroft noch im "Testbetrieb"...

Ich bräuchte allerdings noch mal einen Config-Tip, wie man Mycroft mit Talk2Fhem zum laufen bekommt.

Im Mycroft Skill Config habe ich NLUI richtig angegeben, er sagt allerdings im DebugLog, das Fallback nicht aktiviert wäre und versucht dann die anderen Fallback-Skills wie Wolfram Alpha ...

Es gab einen Bug bei der Initialisierung des Fallback-Device, zu dem ich gestern Abend (zufällig etwas zur gleichen Zeit wie Du hier kommentiert hast) zusammen mit dem Babble-Support (siehe oben) einen Fix in Github commitet habe.