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.

[dkreutz]

Update: Presence

Es kann jetzt der Presence-Status von ROOMMATE-Devices abgefragt werden. Z.B.

• Hey Mycroft, wo ist <Name>?
• Hey Mycroft, ist <Name> anwesend?

Der Presence-Intent sucht dann in allen ROOMMATE-Devices ob der "rr_realname" (das ist ein Verweis auf group oder alias) mit <Name> übereinstimmt (da Mycroft den Namen meiner Frau nicht immer richtig versteht, verwende ich hier ein Fuzzy-Matching) und bei einem Treffer wird mit dem Wert des presence-Attributs geantwort, z.B. "Zur Zeit ist <Name> nicht da." oder "<Name> ist anwesend".

[the ratman]

hiho,

nur ne kurze - vielleicht dumme frage - aber ich bin neu im mycroft-universum

ich hab vor, mein nicht genutztes matrix-voice und einen alten pi3 für mycroft zu mißbrauchen.
anleitung dazu: https://community.matrix.one/t/matrix-voice-running-mycroft-ai/2033
im endeffekt ist das also picraft --> https://github.com/MycroftAI/enclosure-picroft/tree/stretch

geht das mit deinem skill einher? siehst du irgendwelche stolpersteine?

[dkreutz]

geht das mit deinem skill einher? siehst du irgendwelche stolpersteine?

Der FHEM-Skill ist unabhängig von der Hardware bzw. Betriebssystem auf dem Mycroft läuft. (Einige, wenige Skills erfordern bestimmte Hardware, meist dienen die dann aber dazu die Features genau dieser Hardware zu nutzen - z.B. das Display des Mycroft Mark-I oder PiCroft mit Google-AIY-Kit).

[blofield]

NLUI und Presence laufen super (auch in EN).
Ich nutze Talk2Fhem als NLUI und bin begeistert, welche Flexibilität das mit sich bringt.

Was mir dabei aufgefallen ist:
Je nach dem welche Worte man verwendet Mycroft verschiedene Skills triggert. Wenn ich z.B. (auf Englisch) die Temperatur an einem Thermostat setzen will, kommt es häufig vor, das Mycroft auf den Wetter-Skill "abbiegt".
Formuliere ich anders, lande ich in Deinem Skill, dann bekomme ich ggf. Entity not found wenn ich etwa eine Structure für die Kinderzimmer Thermostate schalten will, welche ich aber über NLUI konfiguriert habe :-/

@dkreuz hast Du da ggf. ein paar generelle Hinweise oder Erfahrungen?

Danke
blofield

Gesendet von meinem ONEPLUS A5000 mit Tapatalk

[dkreutz]

Grundsätzlich gibt es Probleme bei Skills mit sich "überschneidenden" Phrasen/Schlagwörtern in den Intents. Hier ist es "Temperatur" - da fühlt sich mal der Wetter-Skill und mal der Fhem-Skill angesprochen. Für diesen Fall würde ich statt "ändere Temperatur im Kinderzimmer auf 20 Grad" dann "ändere Thermostat Kinderzimmer auf 20 Grad" sagen - dann sollte der Wetter-Skill nicht getriggert werden.
Hilft im Deinem Spezial-Fall aber auch nicht, wo eines der Thermostate nur über den NLUI-Fallback angesteuert werden kann. Es müssen alle Thermostate für den Fhem-Skill "erkennbar" sein, ggfs. musst Du in der Structure genericDeviceType=thermostat und dann ein homebridgeMapping selber bauen.
Den NLUI-Fallback habe ich als Hilfsmittel für noch nicht im Skill implementierte Intents gesehen.

Ganz massiv ist das Problem mit "doppelten Intents" bei Skills die etwas abspielen - Spotify, Pandora, Kodi, Nachrichten, etc. - "play rock music" wird dann ggfs. von mehreren Skills verstanden. Dazu gab es gerade mit CommonPlay eine Neuerung bei Mycroft. Hier geben alle Skills die z.B. "play help by the beatles" verstehen eine Wertung ab, wie gut sie die Anfrage "bedienen" können (z.B. Skill A erkennt gewünschten Titel und Künstler, Skill B kennt nur den Titel - dann "gewinnt" Skill A). Vielleich sollte ich etwas ähnliches für Temperaturen/Wetter vorschlagen...?

Der Thermostat-Intent nutzt ürbigens Padatious zum parsen des Intents, der über Neuronale Netze die Beispielphrasen lernt. Die Alternative wäre Adapt, der über vorgebene Regeln (inkl. Regex) arbeitet. Die Erkennung der Erkennung der gewünschten Temperatur hat über Adapt/Regex nicht brauchbar funktioniert.

[blofield]

Moin,

ich verwende ja als Sprache English (ich möchte gerne, dass die Kinder sich daran gewöhnen english zu sprechen, was sie mit Mycroft nun auch mit großer Freude tun und das Wort "Thermostat" geht da meist nicht ganz so flüssig über die Lippen   Dank fuzzy reicht es aber zu sagen: "set the office to ..." -> the wird offenbar als Thermostat interpretiert, was gut funktioniert. Sagt man aber nun "set the office temperature to ..." wird eben häufig der aktuelle Wetterbericht getriggert. Den Skill will man ja aber auch behalten, insofern scheint die von Dir angesprochene Änderung mit CommonPlay sicherlich sinnvoll auch bei Temperaturen/Wetter einsetzbar.

Wie kann ich mit Padatious experimentieren? Reicht es die Vocab-Files anzupassen?
Ich habe etwa ~500 Entities zu steuern. Damit man nicht Vokabeln lernen muss, um in jedem Raum die passenden Entity Namen zu kennen (deswegen verwende ich auch Aliase) habe ich den Weg über Talk2fhem verwendet, weil man dort relativ leicht "schalte licht im wohnzimmer|esszimmer|schlafzimmer ein" verwenden kann. Das fühlt sich wesentlich natürlicher an und man muss nicht alle Entity-Namen auswendig kennen - leider stößt man auch mit Aliasen relativ schnell an eine Grenze :-/

Idee:
Vielleicht kann man in deinem Skill auch den "Quell-"Ort verwenden?
Ich habe 3 Mark I über das Haus verteilt. In home.mycroft.ai kann man jedem Gerät auch den Ort zuweisen, an dem es aufgestellt ist. Wenn man das abgreifen kann und jetzt dem Mycrott im Wohnzimmer sagt: "Mach das Licht an", wäre es naheliegend das Licht auch im Wohnzimmer zu schalten, wo der Befehl ohne anderweitige Ortsangabe her kam.

Macht auf jeden Fall richtig Spaß das mit fhem zusammen zu testen
blofield

[dkreutz]

Wie kann ich mit Padatious experimentieren? Reicht es die Vocab-Files anzupassen?

Im vocab-Ordner sind die .intent-Dateien für Padatious-Intents, die .voc-Dateien sind für Adapt-Intents, für letztere ggfs. noch zusätzlich die .rx-Dateien im regex-Ordner. (Anmerkung: um einen Intentparser von Adapt zu Padatious zu ändern reicht es nicht die Dateiendung im Vocab-Ordner zu ändern, es sind auch Änderungen im Programmcode der __init.py__ erforderlich)

Ich habe etwa ~500 Entities zu steuern. Damit man nicht Vokabeln lernen muss, um in jedem Raum die passenden Entity Namen zu kennen (deswegen verwende ich auch Aliase) habe ich den Weg über Talk2fhem verwendet, weil man dort relativ leicht "schalte licht im wohnzimmer|esszimmer|schlafzimmer ein" verwenden kann. Das fühlt sich wesentlich natürlicher an und man muss nicht alle Entity-Namen auswendig kennen - leider stößt man auch mit Aliasen relativ schnell an eine Grenze :-/

Der Licht/Schalter-Intent arbeitet mit Adapt und reagiert auf bestimmte Schlüsselwörter. Das Fuzzy-Matching zur Erkennung des Device funktioniert natürlich besonders gut mit dem von mir verwendeten Namensschema (DevicetypOrt, z.B. LichtKinderzimmer oder ThermostatSpielzimmer). Ich werde demnächst mal mit einer Padatious-Variante experimentieren, vielleicht klappt da die Erkennung des Ortes besser als das Fuzzy-Matching.

Idee:
Vielleicht kann man in deinem Skill auch den "Quell-"Ort verwenden?
Ich habe 3 Mark I über das Haus verteilt. In home.mycroft.ai kann man jedem Gerät auch den Ort zuweisen, an dem es aufgestellt ist. Wenn man das abgreifen kann und jetzt dem Mycrott im Wohnzimmer sagt: "Mach das Licht an", wäre es naheliegend das Licht auch im Wohnzimmer zu schalten, wo der Befehl ohne anderweitige Ortsangabe her kam.

Ich hatte mir auch schon überlegt die Location-Angabe aus der Mycroft-Konfiguration dafür zu verwenden. Auch hierzu soll es im Mycroft-core eine Unterstützung (für mehrere Mycroft-Geräte in einem Haushalt) geben, kommt aber wohl erst im Frühjahr 2019. Sollte nicht zu kompliziert sein, sehe ich mir mal an...

Macht auf jeden Fall richtig Spaß das mit fhem zusammen zu testen

Ja, nochmals Danke für das viele Feedback.

[dkreutz]

Es gibt ein Update des fhem-skill mit folgenden Änderungen:

• Verwendung des PyPi-package "fhem" statt meines selbst geschriebenen Client-Codes
  Vereinfacht die Programmierung und hat ein paar interessante Features für zukünftige Erweiterung (Auslesen des Eventlogs)
  

• Aktualisierung Intents mit besserer Erkennung des Raums
  Die Intents für Schalter, Thermostat und Präsenz wurden auf den Padatious-Parser umgestellt und unterstützen Raumangaben jetzt wesentlich besser.
  Wenn in home.mycroft.ai bei den Skill-Einstellung die Option "use mycroft device description as location" aktiviert ist wird aus den Mycroft Device-Settings der Inhalt des Feldes "Desription" als Standort von Mycroft interpretiert, z.B. "Wohnzimmer". Bei Kommandos ohne Raumangabe, z.B. "schalte das Licht an", wird dann automatisch dieser Standort angenommen und das Kommando als "schalte das Licht im Wohnzimmer an" ausgeführt.
  

Wer den Skill schon installiert hat kann einfach mit

Code Auswählen Erweitern

mycroft-msm update fhem-skill aktualisieren. Sonst Installation wie oben beschrieben.
In den Skill-Settings gab es einige Änderungen und Erweiterung, deshalb nach dem Update die Skill-Settings prüfen und ggfs. aktualisieren.

[blofield]

Hm,

seit dem letzten update will er bei mir nicht mehr.
Ich nutze für Mycroft ja beim Device einen englischen Alias z.B. "office" für mein Thermostat im FHEM-Raum "Büro". Bei Mycroft habe ich als Location auch "Büro" eingetragen, allerdings erhalte ich dann:

Code Auswählen Erweitern


15:52:18.294 - fhem-skill_domcross:_setup:50 - DEBUG - mycroft device location: Büro
15:52:18.297 - fhem-skill_domcross:handle_set_thermostat_intent:526 - DEBUG - Starting Thermostat Intent
15:52:18.300 - fhem-skill_domcross:handle_set_thermostat_intent:537 - DEBUG - Device: office
15:52:18.302 - fhem-skill_domcross:handle_set_thermostat_intent:538 - DEBUG - This is the message data: {'utterance': 'set office to 20.5 degrees', 'device': 'office', 'temp': '20.5'}
15:52:18.305 - fhem-skill_domcross:handle_set_thermostat_intent:540 - DEBUG - desired temperature from message: 20.5
15:52:18.308 - fhem-skill_domcross:_find_device:732 - DEBUG - device: office allowed_types: thermostat room: Büro
15:52:18.316 - mycroft.skills.core:wrapper:996 - ERROR - An error occurred while processing a request in Fhem Skill
Traceback (most recent call last):
  File "/opt/venvs/mycroft-core/lib/python3.4/site-packages/mycroft/skills/core.py", line 987, in wrapper
    handler(message)
  File "/opt/mycroft/skills/fhem-skill.domcross/__init__.py", line 544, in handle_set_thermostat_intent
    fhem_device = self._find_device(device, allowed_types, room)
  File "/opt/mycroft/skills/fhem-skill.domcross/__init__.py", line 740, in _find_device
    device_candidates = self.fhem.get(room=self.allowed_devices_room,
AttributeError: 'FhemSkill' object has no attribute 'allowed_devices_room'
15:52:18.322 - SKILLS - DEBUG - {"data": {"utterance": "An error occurred while processing a request in Fhem Skill", "expect_response": false}, "context": {}, "type": "speak"}
~~~~a": {"name": "FhemSkill.handle_set_thermostat_intent", "exception": "AttributeError(\"'FhemSkill' object has no attribute 'allowed_devices_room'\",)"}, "context": {}, "type": "mycroft.skill.handler.complete"}

Device ist korrekt erkannt, Room auch und desired-temp auch?!
Ich kommre nicht darauf, wo der Fehler liegt.

Hat jemand eine Idee?

b.

[dkreutz]

Die Fehlermeldung sagt aus, dass die Variable "allowed_devices_room" nicht bekannt ist. Hinter der Variable steht die Skill-Einstellung "Name of FHEM-room with controllable devices". Die Fehlermeldung verwundert mich, denn wenn keine Einstellungen gefunden wurde, sollte eigentlich der Default "Homebridge" verwendet werden.

Mit dem letzten Update gab es auch Änderungen in den Skill-Settings. Bitte kontrolliere Deine Einstellungen für "FHEM home automation" unter home.mycroft.ai. Ggfs. hilft auch ein durchstarten des mycroft-skills Service oder ein reboot des Servers...

[blofield]

Ich habe es nicht hinbekommen. Über Ostern habe ich meine Mark I nochmal komplett aufgesetzt und da läuft jetzt 19.2.6B drauf.
Allerdings funktioniert es immer noch nicht. Der Fehler ist jetzt aber auch ein anderer, aber genau so hartnäckig:

Code Auswählen Erweitern


15:26:32.201 - Fhem - INFO - Request: http://192.168.0.129:8084/fhem?XHR=1&cmd=set%20talk%20set%20office%20to%2020.5%20degrees
15:26:32.537 - Fhem - INFO - Request: http://192.168.0.129:8084/fhem?XHR=1&cmd=jsonlist2%20NAME%7Etalk
15:26:32.586 - Fhem - INFO - JSON answer received.
~~~~6 - Fhem - INFO - Request: http://192.168.0.129:8084/fhem?XHR=1&cmd=jsonlist2%20room%7Emycroft%3AFILTER%3DgenericDeviceType%7Ethermostat
15:26:33.418 - Fhem - INFO - JSON answer received.
15:26:33.484 - mycroft.skills.core:wrapper:1054 - ERROR - An error occurred while processing a request in Fhem Skill
Traceback (most recent call last):
  File "/opt/venvs/mycroft-core/lib/python3.4/site-packages/mycroft/skills/core.py", line 1045, in wrapper
    handler(message)
  File "/opt/mycroft/skills/fhem-skill.domcross/__init__.py", line 544, in handle_set_thermostat_intent
    fhem_device = self._find_device(device, allowed_types, room)
  File "/opt/mycroft/skills/fhem-skill.domcross/__init__.py", line 756, in _find_device
    del filter_dict['room']
KeyError: 'room'


wenn ich den Link in Zeile 4 im Browser aufrufe, dann bin ich im richtigen Raum und ich habe die korrekten Devices und DeviceTypes ?!
Ich verstehe allerdings nicht, warum in Zeile 1 mein Talk2Fhem NLUI mit angesprochen wird?!


Dankbar für jede Hilfe,
blofield

[dkreutz]

Code Auswählen Erweitern


  File "/opt/mycroft/skills/fhem-skill.domcross/__init__.py", line 544, in handle_set_thermostat_intent
    fhem_device = self._find_device(device, allowed_types, room)
  File "/opt/mycroft/skills/fhem-skill.domcross/__init__.py", line 756, in _find_device
    del filter_dict['room']
KeyError: 'room'


Möglicherweise treffe ich Annahmen über die Raum-Namen, die bei dir nicht zutreffen. Ich werde mir das in den nächsten Tagen ansehen...

[dkreutz]

@blofield: Ich konnte die Fehlermeldung reproduzieren wenn in den Skill-Settings die Option "Use Mycroft device description as location" nicht gesetzt ist.

Dazu gibt es jetzt einen Fix im Github-Repository

[blofield]

So,

ich habe jetzt mal ein wenig Zeit gefunden.
Meine Probleme lagen darin, dass ich unter home.mycroft.ai die Settings zum Skill nicht setzen konnte! Wenn ich diese geändert hatte, wurde dort quittiert "saved successfully", das war aber nicht so!
Ich habe das nur durch Zufall gefunden, als ich mir die settingsmeta.json angeschaut habe, ändere ich diese lokal auf einem Mark I dann geht wieder alles.
Warum das aber nicht geht, habe ich noch nicht herausgefunden.

Bei mir lautet der Raum nicht Homebridge sondern "mycroft" und zudem gehe ich auch nicht über 8083 sondern port 8084 auf FHEM, so konnte das nicht klappen.
Nun geht es wieder

Danke für die Unterstützung.
blofield

[dkreutz]

Nach längerer Pause gibt es wieder ein Update:

Rolladensteuerung:
- Hey Mycroft, öffne den Rolladen im Schlafzimmer
- Hey Mycroft, stelle Jalousie auf 25%

Momentan werden Devices vom TYPE "ROLLO" mit genericDeviceType="blind" unterstützt. Bei Bedarf kann ich mir auch noch andere Rolladen-Devices (z.B. automatic shutter control) ansehen, dann benötige ich aber Unterstützung beim Test da ich selber noch keine durch FHEM steuerbaren Rolladen habe...

[Grumpy]

Hallo

zunächst einmal großes Lob und Danke an den Entwickler des FHEM-Skills.

Vor 3 Wochen bin ich auf Mycroft gestoßen und plane nun auch mein FHEM über Sprache zu steuern.
Am Wochenende habe ich dann erfolgreich einen Funkschalter über Mycroft geschaltet.
Mycroft läuft bei mir auf einem RPi3 (BS:Stretch), FHEM auf einem RPi4 (BS:Buster).
Die Verbindung erfolgt über Telnet.

Schön wäre es, wenn man mehrere Räume (Name of FHEM-room with controll) angeben könnte.
Darüber hinaus habe ich mehrere Funkrolladen von der Fa. Selve eingebunden.
Bei Interesse kann ich gerne beim Testen helfen und weitere Infos geben.

Grumpy

[Grumpy]

Hallo

Die Sache mit mehreren Räumen (Name of FHEM-room control) hat sich erledigt.
Habe das wie folgt gelöst: Einen neuen Raum "Mycroft" erstellt, und diesen über Fhem-Web als "hiddenroom" definiert.
Im Anschluss den Devices die man per Sprache steuern möchte den Raum "Mycroft" als zusätzliches room-Attribut hinzugefügt.
Im FHEM-Skill unter "Name of FHEM-room control" Mycroft eingetragen.

Grumpy

[dkreutz]

Hallo

Die Sache mit mehreren Räumen (Name of FHEM-room control) hat sich erledigt.
Habe das wie folgt gelöst: Einen neuen Raum "Mycroft" erstellt, und diesen über Fhem-Web als "hiddenroom" definiert.
Im Anschluss den Devices die man per Sprache steuern möchte den Raum "Mycroft" als zusätzliches room-Attribut hinzugefügt.
Im FHEM-Skill unter "Name of FHEM-room control" Mycroft eingetragen.

Grumpy

Prima, so war das auch gedacht. Ich werde aber noch einmal die Dokumentation überprüfen, ob ich das noch deutlicher beschreiben kann.

[Grumpy]

So, meine Thermostate MAX von eq3 funktionieren auch.
Bleiben nur noch die Rollos. Diese sind von der Fa. Selve und auch als Type  SELVE angelegt. Für diese Funkrollos gibt es ein Gateway vom Type SELVEGateway
Kann man das in einer der Dateien eintragen, oder lieber über den Fallback (Talk2Fehm) gehen?

Grumpy

[dkreutz]

Ich habe bereits einen Intent für den generischen Device-Type ROLLO programmiert. Die ist aber aktuell deaktiviert, da es Probleme im Zusammenspiel mit anderen Intents gab und ich bisher noch nicht die Zeit gefunden habe, dafür eine Lösung zu entwickeln. Von daher würde ich empfehlen den Fallback über Talk2Fhem zu nutzen.

[Prof. Dr. Peter Henning]

Natürlich kann man das alles mit Talk2Fhem machen - aber warum nicht mit Babble? Durch die darin vorgenommene semantische Analyse werden Mehrdeutigkeiten wie die oben beschriebenen aufgelöst. Und der angehängte Chatbot erlaubt einen echten Dialog.

Ich habe gerade jetzt wieder in einer meiner Konferenzsessions einen interessanten Vortrag gehört, nachdem eine Konversation erst als natürlich empfunden wird, wenn sie 60% Smalltalk enthält - und das kann ein Chatbot sehr viel besser abwickeln, als Talk2Fhem.

LG

pah

[dkreutz]

Mein FHEM-Skill unterstützt Babble, Talk2Fhem und Teerko - also im Prinzip alles was FHEM in Richtung NLU hergibt.

Den Chatbot-Bezug verstehe ich aber hier nicht: Mycroft ist ein Sprachassistent und mein Skill ermöglicht es FHEM-Devices einfach und unkompliziert darüber zu "schalten". Ich möchte nicht erst eine Minute Smalltalk machen um das Licht auszuschalten.

[Prof. Dr. Peter Henning]

Das geht aber auch nur gut, wenn sich alle Mitglieder des Haushalts zu jeder Zeit daran erinnern, wie die korrekten Befehle lauten. Mit dem Chatbot kann man den Nutzer in einem Dialog zu den richtigen Befehlen führen. Siehe z.B. den Notfall-Dialog, den ich beschrieben habe.

LG

pah

[caruso]

Guten Abend,
ich habe seit ein paar Tagen endlich mal die Mikrofon-Geschichte mit einem Seeed-VoiceDingsda gelöst und Mycroft arbeitet auf dem Pi endlich soweit, dass ich es an mich anpassen kann und dann auch mal mit FHEM verbinden möchte.

Dabei bin ich auf die Beschreibung hier gestoßen
- FHEM läuft als http ohne Benutzernamen und Passwort, weil es nicht von extern aufrufbar ist
- Port 8083 ist drin
- Fallback Talk2Fhem ist in den Skill geschrieben
- Der Raum heißt "Haus" und ist auch so im Skill hinterlegt

Dummerweise sagt mir Mycroft immer, dass er nicht weiß, was er mit den Anweisungen tun soll, aber er lernt täglich neue Dinge

Probleme:
Ich finde keine Möglichkeit genericDeviceType in FHEM zu setzen. Egal ob ich es bei als attr global versuche zu definieren, er sagt mir immer, dass er sowas nicht kennt. Was mache ich falsch? Einfach erfassen geht nicht, in die FHEM.cfg eintragen führt zu einem Fehler. Was habe ich übersehen?

Noch ist das Ganze auf Englisch eingestellt, ich werde mal versuchen, mycroft generell auf Deutsch umzustellen. Hoffentlich klappts. Muss ich anschließend noch was in FHEM anpassen, wenn Mycroft umgestellt ist?

Danke und Gruß
Caruso

[dkreutz]

Für dem global-Device folgendes im userattr hinzu "genericDeviceType:security,ignore,switch,outlet,light,blind,thermometer,thermostat,contact,garage,window,lock"

Alle FHEM-Devices, die von Mycroft gesteuert werden sollen, müssen den genericDeviceType gesetzt haben und sich indem FHEM-Room befinden - in deinem Beispiel "Haus". Die Devices können sich zusätzlich noch in anderen Räumen befinden. Beispiel: genericDeviceType=light, room=Haus,Wohnzimmer - dann funktioniert "schalte das Licht im Wohnzimmer ein".

[caruso]

Hallo,

DAnke für die Info. Ich habe das jetzt eingetragen und tatsächlich geht der Befehl nun an FHEM.
Allerdings quakt mir Mycroft jetzt ins Ohr:
"Bei der Verarbeitung der Anfrage ist ein Fehler im Skill Fhem-Skill aufgetreten"
oder so ähnlich.

Könnt Ihr mir sagen, wo ich nähere Details dazu finde, wo genau der Fehler liegt?

Wie genau muss ich sprachlich in Deutsch an Mycroft herantreten, damit er was schaltet?
Habe das Wort "schalte " benutzt, um einen über CUL auf 433MHz gesetzten Aktor einzuschalten, auch einer über Z_Wave geht nicht.

Gruß
Caruso

PS: Gerade habe ich festgestellt, dass in der settingsmeta.json alle Einstellungen in dem Skill-Frontend nicht in die Datei übernommen wurden.
Ich habe es manuell eingetragen. Allerdings kommt immer noch derselbe Fehler.
PS2: Ich habe gerade noch gesehen, dass es in Mycroft-core/skills/...Fhem... die Datei gibt und unter /opt/mycroft/skills nochmal. In letzterer ist alles eingetragen worden. Jetzt bin ich wirklich ratlos, weil er immer noch auf dem nicht vorhandenen allowed_device_room rumhackt.

[caruso]

...so, habe das Skills-Log jetzt tatsächlich gefunden unter /var/log/mycroft, ich hatte es lediglich in den Mycroft-Ordnern gesucht, sorry.

Fehler:
2020-11-03 09:28:54.322 | INFO     |   790 | FhemSkill | action: ein
2020-11-03 09:28:54.358 | ERROR    |   790 | mycroft.skills.mycroft_skill.mycroft_skill:on_error:835 | Bei der Verarbeitung der Anfrage ist ein Fehler im Skill Fhem Sk$
Traceback (most recent call last):
  File "/home/pi/mycroft-core/mycroft/skills/mycroft_skill/event_container.py", line 66, in wrapper
    handler(message)
  File "/opt/mycroft/skills/fhem-skill.domcross/__init__.py", line 232, in handle_switch_intent
    fhem_device = self._find_device(device, allowed_types, room)
  File "/opt/mycroft/skills/fhem-skill.domcross/__init__.py", line 817, in _find_device
    device_candidates = self.fhem.get(room=self.allowed_devices_room,
AttributeError: 'FhemSkill' object has no attribute 'allowed_devices_room'
2

Die Aktion wird wohl tatsähclih vom Skill mit "ein" oder "an" korrekt erkannt, aber es bleibt beim Fehler. Ich habe, da Beleuchtung, jetzt light als deviceType angegeben. Das wird aber wohl nicht der Fehler sein oder?

Wieso wird der Raum nach wie vor nicht als gültig erkannt?

[EDIT: PUH, unter ~/.config/mycroft/skills/fhem-skill.domcross gibt es noch eine Datei namens settings.json, wer soll da noch durchfinden. Aber da steht auch alles korrekt drin]

Gruß
Caruso

[dkreutz]

Das ist ein Mycroft-spezifischer Fehler, den beantworte ich dir im Mycroft-Forum, wo Du ja auchein neues Thema aufgemacht hast...

[Iceman0073]

Hallo und erstmal vielen Dank für die tolle Arbeit, der Skill und die Integration von Talk2FHEM macht echt richtig Spaß.
Ich habe eine Frage und zwar hatte ich mal mit Snips und FHEM zu tun und kenne von dort noch die Möglichkeit, dass man von FHEM aus eine Nachricht über Snips ausgeben lassen kann.

Ist dies mit Mycroft auch möglich, dass ich z.Bsp. zu einer bestimmten Uhrzeit oder nach Ablauf von einem Timer dann die Rückmeldung über Mycroft ausgeben lassen kann?

Vielen Dank im Voraus.

Viele Grüße
Michael

[dkreutz]

Ich habe eine Frage und zwar hatte ich mal mit Snips und FHEM zu tun und kenne von dort noch die Möglichkeit, dass man von FHEM aus eine Nachricht über Snips ausgeben lassen kann.

Ist dies mit Mycroft auch möglich, dass ich z.Bsp. zu einer bestimmten Uhrzeit oder nach Ablauf von einem Timer dann die Rückmeldung über Mycroft ausgeben lassen kann?

Mycroft hat einen Message-Bus, an den z.B. speak-Befehle gesendet werden können. Der läuft aber über Web-Sockets, sodass man nicht z.B. HTTPMOD dafür verwenden kann. Web-Sockets gehen auch in Perl, aber damit (Perl) konnte ich mich nie so recht anfreunden.
Inzwischen gibt es fhempy, damit kann man in Python recht einfach ein Mycroft-Modul für FHEM bauen. Das kann dann auch speak-Befehle. Steht auf meiner ToDo-Liste, habe aber noch keinen konkrete Zeitplan dafür.

[Iceman0073]

Super, vielen Dank das hört sich ja auf alle Fälle gut an.
Hab noch eine kleine Verständnisfrage. Habe die Geräte, die ich Steuern möchte im zusätzlichen Raum Homebridge aufgenommen und das entsprechende genericDeviceType hinterlegt. Bisher heißen meine Geräte aber sehr kryptisch wie z.Bsp. WZ_Licht_Decke usw.
Wie hast du das bei dir mit den Namen gelöst, verwendest du ein Alias oder hast du alle dann entsprechend umbenannt?
Wenn du mehrere Lampen im Wohnzimmer hast nennst beinhaltet der Name dann z.Bsp. Wohnzimmer_Licht_Decke oder wie funktioniert die Zuordnung am Besten?

Danke für deine Hilfe.

Viele Grüße
Michael

[dkreutz]

Ich habe bei mir die Namenskonvention "GeräteartRaumname", z.B.

• LichtWohnzimmer
• ThermostatSchlafzimmer
• SensorKinderzimmer

Das ist aber nicht immer konsequent durchgehalten, so gibt es auch "LichtStehlampe" im Raum "Wohnzimmer". Die Geräte sind deshalb immer in einem entsprechenden FHEM-Raum (Room). Der Suchalgorithmus arbeitet mit Fuzzy-Matching, um Fehler bei der Sprache-zu-Text Übersetzung auszugleichen und funktioniert mit meiner eigenen Namenskonvention natürlich ganz gut.

Der FHEM-Skill sucht sowohl in Aliasnamen als auch in Gerätenamen und berücksichtigt auch den Raumnamen mit. In Abhängigkeit des "Intent" werden auch nur bestimmte GenericDeviceTypes berücksichtigt. Der Switch-Intent ("schalte ... an") z.B. Devices vom Type "light", "switch" und "outlet", der Temperatur-Intent ("stelle Temperatur ... auf X Grad") nur Thermostat-Devices, etc. Geräte die im selben Raum wie die Mycroft-Instanz stehen (Parameter "placement" für das Mycroft-Device unter home.mycroft.ai) haben Priorität bzw. es wird dann dieser Raum implizit angenommen, wenn im Sprach-Befehl kein Raum angegeben wurde.

[Prof. Dr. Peter Henning]

Beim Spracherkennungsmodul Babble bin ich einen anderen Weg gegangen. Und zwar erhält jedes Gerät, das damit steuerbar ist, ein zusätzliches Attribut "babbleDevice" - unter diesem Namen wird es bei der Sprachsteuerung erkann. Bei der Sprachsteuerung mit Alexa wurde ebenfalls dieser Weg beschritten, das Attribut heißt dann "alexaName". Insofern schlage ich vor, dass das mit dem Zusatzattribut auch hier umgesetzt wird.

LG

pah

[dkreutz]

https://mycroft.ai/blog/update-from-the-ceo-part-1/

Mycroft als Unternehmen ist am Ende. Die Unterstützer der Kickstarter-Kampagne werden nicht mehr mit Mycroft Mark-II Geräten "belohnt", lediglich direkte Bestellungen über den Webshop der Mycroft-Webseite werden ausgeliefert. Ab März 2023 hat Mycroft-AI keine Mitarbeiter mehr und stellt den Geschäftsbetrieb ein.

Die Pflege und Weiterentwicklung der Mycroft Software wird durch NeonAI fortgesetzt.
Eine weitere Möglichkeit ist OpenVoiceOS (OVOS).
NeonAI OS und OVOS kooperieren und sind untereinander kompatibel (Skills, Pliugins).

Ich werde den FHEM-Skill für Mycroft für NeonAI bzw. OVOS anpassen, kann dazu aber aktuell noch keinen Zeithorizont geben...

[Dr.McKay]

Hallo Dominik,

bin nach einiger Recherche über deinen Skill gestolpert. Erstmal ein Dankeschön, dass du dir die Mühe gemacht hast so etwas zu basteln Allerdings hätte ich noch ein paar Fragen die ausschlaggebend darüber sind, ob der Skill für uns Sinn macht. Über eine Antwort würde ich mich freuen:
1) gibt es eine Möglichkeit den Skill anzupassen, bzw. um Lampen auf eine Farbe zu setzen (set <Beispiellampe> rgb FF0000)?
2) Wir würden gerne die Kommandos so kurz wie möglich halten, also nach dem Schema "Computer, Hauptbeleuchtung ein" anstelle "Computer, schalte die Hauptbeleuchtung ein". Ist das möglich? (Das Wake Word ist bei mir "Computer")
3) Es soll bei Ausführung eines Befehls kein Text wiedergegeben werden, sondern eine simple Audiodatei abgespielt werden. Wie ist das zu bewerkstelligen?
4) Kannst du noch erläutern wie Talk2Fhem zu definieren ist und wie das funktioniert?

Danke
Erhard

[dkreutz]

Hallo Erhard /Dr.McKay

1) gibt es eine Möglichkeit den Skill anzupassen, bzw. um Lampen auf eine Farbe zu setzen (set <Beispiellampe> rgb FF0000)?

Ja, das ist grundsätzlich möglich. Schon jetzt kann man die Helligkeit einstellen - das ist ja ähnlich. Allerdings stelle ich es mir schwierig vor den RGG-Wert zu buchstabieren, da würde man eher eine Reihe von Farbnamen vordefinieren und ein Sprachbefehl "stelle Lampenfarbe auf rot" würde dann in "set Lampe rgb FF0000" übersetzt.

2) Wir würden gerne die Kommandos so kurz wie möglich halten, also nach dem Schema "Computer, Hauptbeleuchtung ein" anstelle "Computer, schalte die Hauptbeleuchtung ein". Ist das möglich? (Das Wake Word ist bei mir "Computer")

Das ist schon etwas schwieriger, da der Skill normalerweise über Schlüsselwörter wie "schalte" getriggert wird.
Was funktioniert ist "Computer, mach Licht an" - wenn alles richtig konfiguriert ist, dann schaltet das das Licht im Raum ein, in dem Mycroft steht.

3) Es soll bei Ausführung eines Befehls kein Text wiedergegeben werden, sondern eine simple Audiodatei abgespielt werden. Wie ist das zu bewerkstelligen?

Ist möglich, in der __init__.py müssten die Stellen "self.speak_dialog(...)" auskommentiert und der Befehl zum abspielen der Audiodatei eingefügt werden.

4) Kannst du noch erläutern wie Talk2Fhem zu definieren ist und wie das funktioniert?

In FHEM musst ein Talk2Fhem Device erstellt werden und dessen Name in der Skill-Konfiguration unter "Name of NLU Fallback Device" eingetragen werden. Alles weitere erfolgt dann in dem Talk2Fhem Device (siehe die entsprechende Dokumentation im Fhem-Wiki).

Viele Grüße
Dominik

[Dr.McKay]

Hallo Dominik,

danke für die schnelle Antwort. Das mit den Farben habe ich mir so vorgestellt, dass man die Farbwörter wie "rot" "grün", hinterlegt und dazu Hex-Werte hinterlegt, die dann Fhem ausführen soll. Ich habe mir Talk2Fhem zunächst kurz angesehen, und wenn ich das richtig sehe, dann lösen die Sprachkommandos dort Events aus, die man noch nutzen könnte um RGB Werte zu setzen mit einer kleinen Schaltlogik im Notify und Regex, oder was denkst du? Ein Problem habe ich jedoch, ich kann in den Skill-Einstellungen in mYcroft den Haken bei "Enable NLUI as fallback" nicht setzen. Weist du womit das zu tun haben könnte?



Gruß Erhard

[Dr.McKay]

PS: Auch bei mir tritt exakt der hier https://community.mycroft.ai/t/fhem-skill-doesnt-accept-room-name-giving-error/9697 beschriebene Fehler auf. In der Skillkonfiguration auf mycroft.ai ist exakt das gesetzt, wie du gesagt hast. Ich habe keine Erklärung, warum er mir diesen Fehler wirft. Gibt es noch andere Sachen zu beachten? Wie kann ich z.B. das Logging aktivieren um überhaupt sehen zu können was der Skill verarbeitet und ob überhaupt eine Verbindung zu meinem FHEM-Server aufgebaut wird? Ich hätte noch eine weitere Frage: Woran erkennt Mycroft, dass er andere Befehle an das Talk2Fhem fallback Device schicken soll und nicht den Befehl in irgendeinem anderen Skill sucht?

Danke und Grüße

[Dr.McKay]

PS: Der Fehler "AttributeError: 'FhemSkill' object has no attribute 'allowed_devices_room" lag daran, dass "csrf= True" in der init.py gsetzt war. ICh nutze keinen Token, da Fhem auch Web-Befehle von anderen Geräten bekommen soll. Die Absicherung geschieht über IP Begrenzung. Also scheint der Verbindungsaufbau von vornherein nicht funktioniert zu haben, allerdings hat das Log nichst über einen gescheiterten verbindungsaufbau gesagt, daher wäre es umso wichtiger für meine weiteren Tests ein hochverboses Logging zu aktivieren. Weist du wie ich das machen kann?

Nochmals Danke

[dkreutz]

Ein Problem habe ich jedoch, ich kann in den Skill-Einstellungen in mYcroft den Haken bei "Enable NLUI as fallback" nicht setzen. Weist du womit das zu tun haben könnte?

Ich kann den Haken auch nicht setzen - da scheint das Webinterface von home.mycroft.ai einen Fehler zu haben.
Wie Du evtl. aus meinem Post #48 entnommen hast, hat das Unternehmen Mycroft die Geschäftstätigkeit eingestellt.
Ich habe im Mycroft-Forum auf das Problem hier aufmerksam gemacht - vielleicht wird es ja von NeonAI noch behoben...

Wie kann ich z.B. das Logging aktivieren um überhaupt sehen zu können was der Skill verarbeitet und ob überhaupt eine Verbindung zu meinem FHEM-Server aufgebaut wird? Ich hätte noch eine weitere Frage: Woran erkennt Mycroft, dass er andere Befehle an das Talk2Fhem fallback Device schicken soll und nicht den Befehl in irgendeinem anderen Skill sucht?

... allerdings hat das Log nichst über einen gescheiterten verbindungsaufbau gesagt, daher wäre es umso wichtiger für meine weiteren Tests ein hochverboses Logging zu aktivieren. Weist du wie ich das machen kann?

Du kannst in der mycroft.conf den Loglevel auf DEBUG setzen: "log_level": "DEBUG",
Darüber kann man dann auch nachvollziehen welcher Fallback-Skill "gewonnen" hat.

[Dr.McKay]

Super, danke. Was mr noch aufgefallen ist, dass offenichtlich die Werte aus mycroft.ai nicht greifen, obwohl in /home/user/.config/mycroft/skill/fhem-skill.domcros/settings.json genau das eingetragen ist, was ich auch über mycroft.ai gsetzt habe, inkl. "fallback_device_name: Talk2Fhem" und "enable_fallback: true." Dennoch hat mir das Log gemeldet fallback sei false und das default fallback device sei TEERKO. Hab das dann kurzerhand durch Definition der Variablen in der init.py gelöst, hoffe du hast nix dagegen. Zusätzlich ist mir noch aufgefallen, dass der selbst gesetzte Name des Fhem Devices "Talk2Fhem" noch übergeben werden muss, da ansonsten die Fhem Meldung: "please define <Devicename> first".

[Dr.McKay]

Was mich noch interessieren würde: gesetzt der Fall ich sage "...schalte Licht" geht es, bzw. ist es überhaupt möglich, dass Mycroft nochmal rückfragt "Welches Licht soll geschaltet werden?", erneut in den Aufnahmemodus geht, um einen weiteren Parameter in Empfang zu nehmen und dann das Komplette Kommando ausführt bzw. an Fhem übergibt? So wie das bei dem Default Timer-Skill mit der Rückfrage "Wie lang soll der Timer sein?" funktioniert?

Danke

[Dr.McKay]

Spricht eigentlich etwas dagegen, wenn ich mir noch weitere Intent Handler definiere um noch besondere, individuelle Funktionen auszufühen? Oder wird dann das Programm instabil?

[dkreutz]

Was mich noch interessieren würde: gesetzt der Fall ich sage "...schalte Licht" geht es, bzw. ist es überhaupt möglich, dass Mycroft nochmal rückfragt "Welches Licht soll geschaltet werden?", erneut in den Aufnahmemodus geht, um einen weiteren Parameter in Empfang zu nehmen und dann das Komplette Kommando ausführt bzw. an Fhem übergibt? So wie das bei dem Default Timer-Skill mit der Rückfrage "Wie lang soll der Timer sein?" funktioniert?

Das geht zumindest für Ja/Nein Fragen. Mit Conversational Context müsste das aber prinzipiell auch für richtige Dialoge funktionieren.

Spricht eigentlich etwas dagegen, wenn ich mir noch weitere Intent Handler definiere um noch besondere, individuelle Funktionen auszufühen? Oder wird dann das Programm instabil?

Spricht nichts dagegen, mir sind zumindest keine Limits bekannt

p.s. sorry für die späte Antwort, die automatische Emailbenachrichtigung über neue Antworten hat nicht funktioniert....

[Dr.McKay]

Hi @dkreutz,

es scheint nun so, dass mycroft.ai endgültig nicht mehr online ist. Seit lezter Woche kann sich Mycroft nicht mehr mit api.mycroft.ai verbinden und damit geht auch nix mehr außer die Wakewordekrennung, die ich selbst erstelt habe. Sämtli. Skills (auch der Fhem-Skill) gehen nicht mehr, da sich Mycroft vorher erst mit api.mycroft.ai verbinden will. Das interessante allerdings ist, dass erst nach einem Neustart des Raspberry das Problem auftrat. Kurz vorher haben die Anfragen noch funktioniert, daher vermute ich, dass api.mycroft.ai schon vorher down war, aber die Skills noch irgendwo im Cache waren. Kennst du einen Weg um zumindest den Fhem-Skill auch ohne api.mycroft.ai verfügbar zu machen?

Danke, auch nochmal für die vorherigen Antworten

[dkreutz]

Hallo Dr.McKay,

Am sinnvollsten ist es auf Neon.ai oder OVOS umzusteigen (URLs siehe weiter oben). Wenn Du auf der alten Mycroft-Codebasis bleiben möchtest bzw. wegen dem FHEM-Skill musst: es gibt "LocalCroft" (https://github.com/el-tocino/localcroft), der den Mycroft-Server lokal simuliert, ist aber veraltet. Das habe ich selbst mal ausprobiert und funktionierte soweit gut.

Alternativ, aber deutlich überdimensioniert für ein einzelnes Mycroft-Device, gibt es das Selene-Backend (https://github.com/MycroftAI/selene-backend) - das ist die Software, die auf den Mycroft.ai API-Servern läuft/lief. Benötigt aber deutlich mehr Resourcen, u.a. eine Datenbank (Maria-DB oder PostgreSQL - ich erinnere mich nicht mehr..)

[Dr.McKay]

Danke 

das werde ich mal ausprobieren.

[Dr.McKay]

Weist du noch wie der localcroft zu installieren war. Wie üblich ins home-Verzeichnis mit 'git clone'?
Das war's dann?

Besten Dank

[dkreutz]

Weist du noch wie der localcroft zu installieren war. Wie üblich ins home-Verzeichnis mit 'git clone'?
Das war's dann?

Sorry, ist schon länger her und habe da keine detaillierte Erinnerung mehr - ich habe gerade im localcroft-Repository gesehen, dass der Code zur Integration des TTS-Services ursprünglich von mir stammt - selbst das habe ich total vergessen...  Und noch einen Schritt weiter fällt mir jetzt gerade auf, dass ich localcroft mit dem Personal-Backend  verwechselt habe: https://github.com/MycroftAI/personal-backend - das wäre die Empfehlung, hier gibt es auch eine (hoffentlich verstänndliche) Installationsanleitung

[Dr.McKay]

Ich glaube das personal-backend ist nicht vollständig Aber dennoch Danke für deine Tipps
Ich habe derweil dies hier gefunden, wo ich denke, dass es mich weiterbringt
https://openvoiceos.github.io/ovos-technical-manual/personal_backend/#classic-mycroft-devices