Modul für Spracherkennung? (menschlichen Text in einen Befehl umsetzen)

[siggi85]

Ich bräuchte weitere ideen
Der ursprüngliche zweck eine menschliche sprache beliebig und unabhängig von der grammatik auszuwerten erfüllt diese funktion und sie ist an beliebiger stelle aus fhem aufrufbar.
Wenn du einer Idee hast immer her damit

Anbei mal etwas Brainstorming meinerseits:

Code Auswählen Erweitern


define sprachsteuerung VOICECOMMAND
attr sprachsteuerung voiceCommands set,"Schalte":setstate,"Setze"
attr sprachsteuerung voiceLang de
attr sprachsteuerung voiceError set xbmc msg "Nichts verstanden"

define wz_htpc WOL aa:bb:cc:dd:ee:11 192.168.10.10
attr wz_htpc voiceName htpc
attr wz_htpc voiceCmd set,on,"an":set,off,"aus"
attr wz_htpc voiceOwn set,on,"Starte $voiceName",1:set,off,"Stoppe $voiceName",1


VOICECOMMAND Modul
voiceCommands: Attribut welches den Standardbefehlen in FHEM (set,setstate,setreading) global Werte zuweist damit sie nicht auf jedem Gerät definiert werden müssen.
Syntax: "Fhembefehl","RegEx":"Fh... usw.
voiceLang: Sprache in welcher die Spracherkennung arbeiten soll
voiceError: Was soll ausgeführt werden wenn nichts erkannt wurde.

Zu steuerndes Modul
voiceName: Regex nach welchem gesucht wird um das zu schaltende Gerät fest zu legen.
voiceCmd: Mitgeben zu schaltender Zustände und des jeweiligen RegEx
Syntax: "Fhembefehl","zuschaltender Zustand","SprachRegex":"Fh... usw.
voiceOwn: Komplette eigene Regex um ganze Befehle zu definieren. Die Variable $voiceName kommt aus dem gleichnamigen Attribut.
Sytax: "Fhembefehl","zuschaltender Zustand","Sprachregex","Priorität"
Die Priorität gibt an in welcher alle Regex abgesucht werden sollen. z.B.
Die Standardpriorität für die voiceCommands Befehle könnte dabei 10 Betragen. Als von 1-9 wäre dann vor den globalen Kommandos, alles ab 11 würde erst abgearbeitet werden wenn keine eigenen Kommands von 1-9 und kein globales Kommando gegriffen hat.

Es fehlen hierbei natürlich noch Dinge wie:
- reagieren auf gesprochene Werte zB: "Setze die Temperatur auf 20 Grad" (hierbei würde ein Platzhalter im RegEx gebraucht werden, welcher in eine Variable schreibt. Der Platzhalter müsste nach dem Wert vor dem Wort "Grad" greppen.)
- Zeitgesteuerte ansagen zB: "Schalte htpc in 10 Minuten aus" (hier muss natürlich das reagieren auf einen bestimmten Wert (in diesem Fall die Minutenzahl) reagiert werden. Hinzu kommt hierbei aber, dass ein at definiert werden muss mit der gesprochenen Aktion)


Dies soll nur ein Denkanstoß für eine mögliche Realisierung sein. Ich hoffe ihr habt vielleicht auch noch Ideen hierzu oder sogar bessere!

[siggi85]

Zusatz:

Vielleicht könnte man auch

Code Auswählen Erweitern

attr sprachsteuerung voiceCommands set,"Schalte":setstate,"Setze"
umbauen zu

Code Auswählen Erweitern

attr sprachsteuerung voiceCommands set,"Starte|Stoppe|Schalte",WOL:set,"Schalte",0:setstate,"Setze",0
Syntax: "Fhembefehl","RegEx","Modulart":"Fh... usw.
Dann könnte man für bestimmte Modultypen (in diesem Beispiel WOL) eigene Parameter definieren um sagen zu können "Starte htpc". Im WOL Modul muss natürlich auch noch definiert werden--> IF (voiceCommand eq starte) "zuschaltender Zustand"=on.
Zum Beipspiel vielleicht so:

Code Auswählen Erweitern

attr wz_htpc voiceCmd set,on,"an":set,off,"aus":set,on,$voiceCommand="Starte"
Syntax: "Fhembefehl","zuschaltender Zustand","SprachRegex"ODER"Prüfung (zum Beispiel hier auf neue Variable $voiceCommand):"Fh... usw.

[Kuzl]

OK dann scheint es so, als muss da doch irgendwann mal ein direktes Modul daraus werden
Nur im Moment hab ich leider absolut keine Zeit sowas umzusetzen, evtl wenn ich mal Urlaub habe

Deine Idee ist ganz interessant und zeigt v.a. wie man das ganze etwas Benutzerfreundlicher gestallten könnte, denn bist auf die "at" ist bereits alles damit umsetzbar

Mit den Attributen für die einzelnen Module glaub ich, ist das nicht umsetzbar, da es das voicecmd etc. in keinem Modul gibt.
Ich wüde eher nur 5 Attribute für das Voicecmd-Modul nehmen und Zwar:
-Devices: Definiert alle Devices, die über Sprache gesteuert werden sollen
-cmds:     Definiert die Befehle, evtl. optional zugeortnet zu einem bestimmten Device
-params: zusätzliche Parameter für bestimmte Befehle, keine Ahnung wie man das umsetzen könnte
-special: sachen wie at, setstate
-ErrorAction: Aktion die ausgeführt werden soll, wenn kein Befehl erkannt wurde.

Natürlich soll alles mit oder verküpft werden können um mehrere Schlüsselworte für einen Befehl zu haben.

wie das ganze dann genau aussehen und umgesetzt werden soll weis ich noch nicht aber schön langsam geht es in eine Richtung, unter der man sich was vorstellen kann Vll sieht das ja der ein oder andere erfahrene Entwickler und macht daraus was, bevor ich mich daran vergeblich versucht habe

[der-Lolo]

Attribute sind ja für die devices, nicht für die Module... Ich finde auch die Version der Attribute für devices besser - entweder man setzt sie, oder das device nimmt nicht an der sprachsteuerung Teil.

[Kuzl]

Ich hab damit gemeint, dass das Modul die Attribute gar nicht kennt.
Devices werden ja immer mithilfe eines Moduls definiert, das Ihnen ihre attribute (zuzüglich der standard von fhem) mitbringt.
Da kann man nicht einfach mal so ein Attribut für ein STV dazuerfinden.

entweder man setzt sie, oder das device nimmt nicht an der sprachsteuerung Teil.

So hab ich das ja auch gedacht; entweder man schreibt das Device dazu oder es wird nicht beachtet

[siggi85]

Ich denke genau aus diesen Gründen wird man die Attribute erst mal nur auf dem Voicecmd Modul haben können. Wenn das Modul viel genutzt wird, ist eine spätere Integration in andere Module vielleicht möglich. Aber das wird die Zukunft zeigen. Version 1 wird erst mal komplett im Voice Modul erfolgen müssen.

[Kuzl]

So sehe ich das auch

[Zephyr]

Für genau solche generischen Analysen von Sprache und Dialogen gibt es eigentlich schon eine Lösung: http://de.wikipedia.org/wiki/AIML.
Und ein Perl-Modul gibt es dafür auch: http://search.cpan.org/~perigrin/Net-AIML-0.0.5/lib/Net/AIML.pm

Das Problem: Alles sehr generisch. Man muss die möglichen Dialoge in einer Baumstruktur vorhersehen.
Eigentlich möchte man doch eine Metaebene, die erahnt was der Nutzer will. Im Prinzip habt ihr das schon getan: Das Pattern mit Gerät, Befehl etc. pp. Aber es braucht noch die Intelligenz, die erahnt, dass der Nutzer die Temperatur hochstellen will, aber so lange fragt bis alle dafür notwendigen Infos vorhanden sind.

[Rince]

Bitte nicht die Threads mit Alternativen zukleistern.
Ein neuer Thread kostet nix

Und du hast doch hier schon einen:
http://forum.fhem.de/index.php/topic,22838.0.html

[franky08]

Da es hier im Thread lange nichts neues zu berichten gab, wollte ich mal fragen wie der Stand der Dinge ist?
VG
Frank

[SpenZerX]

Spracherkennung würde mich auch interessieren.

Aber bitte über Google Now so wie es hier demonstriert wird:

https://github.com/MohammadAG/Google-Search-API
http://forum.xda-developers.com/xposed/modules/mod-google-search-api-t2554173

[siggi85]

Über Tasker mit Autovoice sollte eine Umsetzung auch bei einer FHEM internen Lösung möglich sein.