Spracherkennung und Sprachsynthese

Begonnen von Prof. Dr. Peter Henning, 09 Februar 2017, 08:19:06

Vorheriges Thema - Nächstes Thema

tiroso

Moin,
Natürlich geht so von alleine gar nichts. War vielleicht was salopp dahergesagt.
Aber ist das auflisten der Devices das Ziel?
Ich arbeite in meiner Texterkennung mit qgram Profilen um die Devices  zu identifizieren. Primär erfolgt eine semantische Auswertung...Zumindest versuche ich das. Dann erfolgt ein scoring aufgrund der qgram Profiles. Zum Abgleich der Aliase und rooms. Anschließend die Kontrolle ob das Device eine Freigabe zum bedienen hat.
Also ich habe bis jetzt nur einfache Dinge implementiert. Diese laufen aber erstaunlich gut ( aus/ ein/ umschalten., dimmen, wert setzen, hochfahren runterfahren, Status abfragen)
Da sich nicht jedes Device gleich bedient kann man benutzerdefinierte Befehle hinterlegen

Mit der Auswertung ist es möglich auch verschachtelte Sätze zu stellen und auszuwerten.

Das ganze habe ich in ein Modul geknallt und die Erweiterung auf AMAD und TelegramBot erweitert. Somit wird nicht nur der String von einem AMAD Device ausgewertet sondern auch das geschriebene von Telegram oder halt einen eigenen Satz dem man dem Modul übergeben kann. Die Antwort erfolgt, je nach Eingang, entweder auf dem Amad device(per Sprache oder Text oder umgeleitet auf Sonos Box) über den Telegram Bot an den freigegeben Peer oder in dem Modul selber.

Sprich ich habe kein Device in meinem Code.
Interagieren  ist nur mit Devices möglich die einen alias haben (und ggf room wenn eine Präposition erkannt wurde)
Von den Geräten kann man bei allen den Status abfragen
Schalten kann man nur die Geräte die freigegeben sind.
Ich muss noch ein paar Sachen fixen und dann kann ich es dir mal geben.
Ich hätte da gerne die Meinung eines Fachmanns. Und der ggf etwas mehr von der Thematik versteht.

Gruß
Tim

yrwyddfa

Zitat von: Prof. Dr. Peter Henning am 21 Mai 2017, 03:06:04
RiveScript finde ich ziemlichen Mist, nachdem ein Student von mir das sauber aufgearbeitet und dokumentiert hat.

Wie kommt's? Warum ist Rivescript Mist? Gibt es denn bessere Alternativen? In meinen Augen ist RS super geeignet, wenn man nicht nur eine stoische Befehl-Ausführen-Antworten-Kette möchte sondern dem Dialog etwas mehr "Pepp" verleihen möchte. "Nerdy" aber spannend finde ich vor allem die Idee, dem Haus einwenig "Persönlichkeit" zu geben, also z.B. je nach "Laune" des Bots entweder auf "Mach bitte die Kaffeemaschine aus" als Antwort entweder ein

"Sehr gern!" oder
"Kaffee soll ja eh nicht gesund sein." oder aber
"Aha, sind wir wieder zu faul es selbst zu machen?"

Da sich RS innerhalb weniger Stunden lernen lässt, finde ich es auch für Menschen wie mich geeignet, die als dritte Fremdsprache weder Perl noch ähnliches können :)
Gibt es denn bessere Alternativen, ohne eine Programmiersprache von Pike auf lernen zu müssen?
If every day has its number, Monday would be a zero division.

Prof. Dr. Peter Henning

Soso,
Zitat"Nerdy" aber spannend

Bei mir steht eher die Usability bzw. Gebrauchstauglichkeit im Vordergund: Ein Mensch-Maschine-Dialog muss planbar, inutuitiv verstehbar und erlernbar sein. Wechselnde mehr (oder weniger, in diesem Falle ...) witzige Sprüche erfüllen diese Kriterien nicht, sie haben in einer Steuerung auch als Antworten eigentlich gar nichts verloren.

Und eine "Persönlichkeit" lässt sich so schon gar nicht simulieren - das ist höchstens eine Woche lang witzig.

LG

pah


yrwyddfa

Bei so vielen Fragen über "wie kann man Goggle Nows Hotword in "Hey Jarvis" ändern", die im Internet in den Foren kursieren, glaube ich aber schon, dass viele einen solchen Coolness-Faktor begrüßen - was man nun als witzig empfindet bleibt da ja jedem selbst überlassen.

Was ich nicht verstehe, ist, warum alternierende Antworten eine Sprachbedienung weniger intuitiv machen sollen. Die Nachvollziehbarkeit leidet ja eigentlich erst, wenn der Sprachbefehl mal ausgeführt wird und mal nicht. Wenn ich also sage: "Mach bitte das Licht an" und Fhem antwortet "nein", dann wäre das in der Tat wenig intuitiv. Aber allein schon, um eine Sprachbestätigung nicht immer nur mit einem "ok" oder "Ich habe das Licht angemacht" ablaufen zu lassen, sondern mehrere Optionen bieten zu können bietet hier ja schon eine willkommene Abwechslung - gerade wenn du ja auf "spätestens nach einer Woche" anspielst.

Ich glaube einfach, dass RS, was die Interaktion angeht, einfach mehr Optionen eröffnet wie "hartkodierte" Dialoge - wie man sie nutzt, ist ja jedem selbst überlassen - aber wenn es hier andere bzw. einfachere Wege gibt, lass ich mich sehr gern eines Besseren belehren :)
If every day has its number, Monday would be a zero division.

Prof. Dr. Peter Henning

Was soll eigentlich das "hart kodiert" aussagen ?

Wenn man sich dumme Sprüche ansagen lässt, kommen diese natürlich aus einer Tabelle. Das ist aber nicht mehr oder weniger "hart" als ein kurzes Programm, das sich mit Hilfe einer Markov-Kette Antworten zusammenbastelt: In beiden Fällen gibt es nur eine endliche Anzahl von unterschiedlichen Antworten, die nach einem zufälligen Verfahren ausgewählt werden. Ich halte es für absurd, so etwas mit einer "Persönlichkeit" zu assoziieren.

Den "Coolness-Faktor" bevorzuge ich auch (in den SmartHome Hacks habe ich meine Vorliebe für eine Jeannie-Marilyn-HAL TTS ausführlich beschrieben), mein dienstbarer Geist heißt Jeannie. Aber deswegen lasse ich nicht die grundlegenden Regeln der Usability außer Acht.

Etwas Anderes wäre, wenn sich die Sprachansagen personalisieren ließen. Jeannie antwortet mir deshalb auch mit "Ja, Meister" - aber an der Unterscheidung der Stimmen verschiedener Hausbewohner bin ich bisher gescheitert.

LG

pah

tiroso

#65
Moin Leute,

Ich würde gerne auch meine Art mit FHEM zu kommunizieren ins Rennen werfen. Ich habe mich auch mal in RS probiert allerdings ist es mir zu starr und es ist immer mehr Arbeit etwas daran zu ändern.

Mein Modul nennt sich TEERKO und soll Textbefehle (von Telegram, AMAD oder lokal im Device) umsetzen.

Ich habe das Modul in einem eigenen Thread aufgemacht:
https://forum.fhem.de/index.php/topic,72657.0.html

Das Modul wird ganz simpel mit folgendem Befehl definiert:
define <name> TEERKO

Schon jetzt ist das Modul in der Lage auf Befehle direkt am Device zu reagieren. (set <TEERKODevice> TextCommand Schalte die Deckenlampe in der Küche an)

Was ist nun möglich?
Das Modul analysiert den ihm übermittelten String auf Prädikat, örtliche Präposition etc usw.
Natürlich alles nur im kleinen Rahmen und nicht alles was der deutsche Wortschatz so hergibt.
Aufgrund eine qgram Profiles werden ebenfalls alias und room gefiltert.

Je nach Konstellation werden Devices:
Ein, Aus und umgeschaltet
Ein, Aus gestellt
Hoch und runter gefahren
Auf einen Wert gedimmt oder gestellt oder gefahren
Der Status abgefragt
Befehle wiederholt (Bsp. Mach das nochmal)
Alte Devices angesprochen(Keyword Gerät ohne das erkennen weiterer Devices)
Bsp. Schalte die Deckenlampe aus-> schaltet Küchen Deckenlampe aus
Bsp. Schalte das Gerät ein-> schaltet Küchen Deckenlampe ein

Vorraussetzung für die Kommunikation ist das korrekte benennen der Devices.
TEERKO soll nicht nur mit Wortfragmenten bedient werden sondern relativ menschlich.
Dementsprechend ist es notwendig auch die Geräte korrekt zu bennenen.
Beispiel:
Device: KU.SA.Deckenlampe (Raum: Küche; Gerät: Deckenlampe)
Also:
attr KU.SA.Deckenlampe alias Deckenlampe
attr KU.SA.Deckenlampe room Küche

Somit ist das Gerät eingerichtet und kann auch von TEERKO über den alias oder über den Room angesprochen werden.
Also:
TEERKO findet keine Geräte die keinen alias besitzen.
Es können keine Geräte einem Raum zugeordnet werden wenn dieser nicht in room angegeben ist.

TEERKO spricht immer nur ein Gerät an. Wie kann man mehrere Geräte in einem Satz schalten?
Beispiel:
Schalte alle Lampen im Erdgeschoss aus

Lege ein "structure" Device mit allen Lampen für das Erdgeschoss an. Das "structure" Device bekommt den alias "alle Lampen" und den Room "Erdgeschoss". Fertig und es kann bedient werden. Wenn der Status eines Structure Devices abgefragt wird, bekommt man den Status eines jeden einzelnen beinhaltenden Devices, selbst wenn ein Structure device ein anderes Structure Device enthält.

Zur Sicherheit:
Den Status kann TEERKO von jedem Device auslesen.
Zum schalten benötigt es das Reading TEERKOControl = 1, erst dann darf TEERKO das Gerät auch schalten, dimmen etc.
Schalten:
attr KU.SA.Deckenlampe TEERKOControl 1

Wenn das TEERKO Modul korrekt mit einem Telegram Device oder AMAD Device verbunden sind erfolgen die Antworten automatisch auch auf dem jeweiligen Device. Wenn ein String direkt an dem TEERKO Modul eingegeben wurde erscheint auch die Antwort in dem Reading Answer. Wichtig für den Betrieb mit AMAD. Der Flow für VoiceControl splittet den String bei "und" und sendet die Teile seperat. Das ist für den Betrieb meines Moduls üüüberhaupt nicht gut. Der String muss als ganzes übertragen werden. Das müsste noch angepasst werden. Es kann zu unerwünschten Nebeneffekten kommen solltet ihr das nicht ändern  ;)

Possible Sets:

TextCommand: <textfield> : Eingabe des auszuwertenden Satzes.
AMADAnswer: text|voice|sonos : Eingaben die über das AMAD Device erkannt werden, werden auf diesen Devices auch beantwortet. Text auf dem Display des AMAD Devices. Voice per TTS auf dem AMAD Device. Sonos auf dem SonosGerät welches unter AMADSonos gesetzt werden kann ( Sonos Speak muss funktionieren)
AMADSonos: <textfield> : Angabe des Sonos Devices wenn AMADAnswer auf sonos gestellt ist
UserDefinedCommand: <textarea> : Definieren eines User definierten Input, Kommandos und Output. Detaillierte Beschreibung später
ActivateUserDefinedCommand: <Number> 1|0 : Aktivieren oder deaktivieren eines User definierten Kommandos
DeleteUserDefindesCommand: <Number> : Der User definierte Kommando wird gelöscht.


Possible Attr:

AMADDevice: <textfiled> : Angabe des AMAD Devices welches Überwacht werden soll
TelegramDevice <textfiled> : Angabe des TelegramDevices welches Überwacht werden soll
TelegramPeer <textfiled> : Angabe der PeerID von welcher Daten angenommen werden dürfen
informlowBatterie: 1|0 : Wenn leere Batterien auftreten werden diese automatisch an alle Ausgänge geschickt
sarReading: <textfield> : Angabe von Readings und wie diese Ersetzt werden:Beispiel:  on=an;off=aus;open=offen;closed=geschlossen;home=zuhause;present=anwesend


Possible Attr in anderen Devices:

TEERKOControl: 1|0 : Darf dieses Device kontrolliert werden
TEERKOUserDef*<textfiled> : Falls die Befehle zum ausführen anderes sind als es TEERKO ausführt kann man es hier hinterlegen. Darüber ist es möglich Befehle "schöner" ausführen zu lassen.
Beispiel:
Schalte die Stehlampe aus (Bewirkt: set <Device> off)
Wenn allerdings TEERKOUserDefOff pct 0 hinterlegt ist bewirkt es  set <Device> pct 0 und die Lampe dimmt sich aus anstatt einfach auszuschalten.



Hier ein paar Beispiele aus meiner Konfiguration:
Schalte die Deckenlampe in der Küche aus
-> Schaltet das Gerät mit dem alias Deckenlampe und room Küche aus
Mach bitte alle Lampen im Wohnzimmer aus und dimme die Stehlampe im Büro auf 30%
-> Schaltet das structure device mit dem alias alle lampen und room Wohnzimmer aus und stellt das device mit dem alias Stehlampe und room Wohnzimmer auf 30

(Tip: Immer ganze Sätze stellen. Status Deckenlampe ist eher abgehackt und wird nicht erkannt. Wogegen wie ist der Status der Deckenlampe den erwünschten Effekt erzielt.

Wie ihr seht kann man auch verschachtelte Sätze stellen.
Dabei ist aber zu beachten das die Angabe eines Raumes und des Prädikates in den Satzteilen nach hinten vererbt wird.
Schalte in der Küche die Deckenlampe aus und die Tischlampe an
->Angesprochen werden in jedem Satzteil ein Device (alias Deckenlampe und alias Tischlampe) beide Devices müssen aber ebenfalls das attr room Küche beinhalten. Schalte wird ebenfalls auf den zweiten Satzteil bezogen allerdings dort mit dem Zusatz an. Somit wird die Deckenlampe in der Küche ausgeschaltet und die Tischlampe in der Küche eingeschaltet

UserDefinedCommand:
In dem Feld kann man ein Benutzerdefinierten Befehl anlegen
Beispiel in der Textarea:
IN:Mache einen Befehl anders
OUT:Ok dann werde ich das anders machen
DO:set testdevice off


Es werden also 3 Zeilen angelegt. IN, OUT und DO. Diese kann man dann mit benutzerdefinierten Befehlen füllen. Der Teil ist noch seeeeeehr schlecht aufgebaut. Aber man kann es testen.

Wenn ein Benutzerdefinierter Befehl in einem Teilstring erkannt wird, wird dieser nicht mehr ausgewertet um Devices zu schalten.


Lasst mich wissen wenn es ok, gut oder schlecht ist. Ich will mir da was schönes basteln und vielleicht kann es der eine oder andere auch gebrauchen

chunter1

#66
Zitat von: Prof. Dr. Peter Henning am 21 Mai 2017, 16:04:35
Jeannie antwortet mir deshalb auch mit "Ja, Meister" - aber an der Unterscheidung der Stimmen verschiedener Hausbewohner bin ich bisher gescheitert.

... das muss ganz schön hart sein, wenn Jeannie nicht nur zum Dr.Dr. "Ja, Meister" sagt.  ;)

Prof. Dr. Peter Henning

@chunter: Erstmal habe ich keine 2 Doktortitel - nur zwei Professuren  ;)
Na, und da gibt es natürlich noch einen Trick, mit dem ich verhindere, dass meine Göttergattin als "Meister" angeredet wird.

LG

pah

the ratman

#68
wie könnte man den unterscheiden? denke, frequenzen angucken wäre zu einfach, oder?

btw - warum heißt dein automat nicht igor? würde doch viel besser zum  professor passen *bg*
*duck und weg*
→do↑p!dnʇs↓shit←

Prof. Dr. Peter Henning

"Igor" - das ist etwas für Mediziner an der Universität Ingolstadt (die gab es wirklich mal).

LG

pah

eurolift

hallo tiroso
Habe dein Modul schon ausprobiert.Ich habe das Problem das im String mein Hotword mit übertragen wird (brauch ich für was anderes).
Würde es gehen  Wörter (Hotword) auszuklammern? Ansonsten funktioniert es schon prima ,besonders die Antworten  :).


Ma_Bo

Zitat von: tiroso am 22 Mai 2017, 08:57:42
Moin Leute,

Ich würde gerne auch meine Art mit FHEM zu kommunizieren ins Rennen werfen. Ich habe mich auch mal in RS probiert allerdings ist es mir zu starr und es ist immer mehr Arbeit etwas daran zu ändern.

Mein Modul nennt sich HOMETALK und soll Textbefehle (von Telegram, AMAD oder lokal im Device) umsetzen.

Das Modul wird ganz simpel mit folgendem Befehl definiert:
define <name> HOMETALK

Schon jetzt ist das Modul in der Lage auf Befehle direkt am Device zu reagieren. (set <HomeTalkDevice> TextCommand Schalte die Deckenlampe in der Küche an)

Was ist nun möglich?
Das Modul analysiert den ihm übermittelten String auf Prädikat, örtliche Präposition etc usw.
Natürlich alles nur im kleinen Rahmen und nicht alles was der deutsche Wortschatz so hergibt.
Aufgrund eine qgram Profiles werden ebenfalls alias und room gefiltert.

Je nach Konstellation werden Devices:

  • Ein, Aus und umgeschaltet
  • Ein, Aus gestellt
  • Hoch und runter gefahren
  • Auf einen Wert gedimmt oder gestellt oder gefahren
  • Der Status abgefragt
  • Befehle wiederholt (Bsp. Mach das nochmal)
  • Alte Devices angesprochen(Keyword Gerät ohne das erkennen weiterer Devices)
    Bsp. Schalte die Deckenlampe aus-> schaltet Küchen Deckenlampe aus
    Bsp. Schalte das Gerät ein-> schaltet Küchen Deckenlampe ein

Vorraussetzung für die Kommunikation ist das korrekte benennen der Devices.
HomeTalk soll nicht nur mit Wortfragmenten bedient werden sondern relativ menschlich.
Dementsprechend ist es notwendig auch die Geräte korrekt zu bennenen.
Beispiel:
Device: KU.SA.Deckenlampe (Raum: Küche; Gerät: Deckenlampe)
Also:
attr KU.SA.Deckenlampe alias Deckenlampe
attr KU.SA.Deckenlampe room Küche

Somit ist das Gerät eingerichtet und kann auch von HomeTalk über den alias oder über den Room angesprochen werden.
Also:
HomeTalk findet keine Geräte die keinen alias besitzen.
Es können keine Geräte einem Raum zugeordnet werden wenn dieser nicht in room angegeben ist.

HomeTalk spricht immer nur ein Gerät an. Wie kann man mehrere Geräte in einem Satz schalten?
Beispiel:
Schalte alle Lampen im Erdgeschoss aus

Lege ein "structure" Device mit allen Lampen für das Erdgeschoss an. Das "structure" Device bekommt den alias "alle Lampen" und den Room "Erdgeschoss". Fertig und es kann bedient werden. Wenn der Status eines Structure Devices abgefragt wird, bekommt man den Status eines jeden einzelnen beinhaltenden Devices, selbst wenn ein Structure device ein anderes Structure Device enthält.

Zur Sicherheit:
Den Status kann HomeTalk von jedem Device auslesen.
Zum schalten benötigt es das Reading HomeTalkControl = 1, erst dann darf HomeTalk das Gerät auch schalten, dimmen etc.
Schalten:
attr KU.SA.Deckenlampe HomeTalkControl 1

Wenn das HomeTalk Modul korrekt mit einem Telegram Device oder AMAD Device verbunden sind erfolgen die Antworten automatisch auch auf dem jeweiligen Device. Wenn ein String direkt an dem HomeTalk Modul eingegeben wurde erscheint auch die Antwort in dem Reading Answer. Wichtig für den Betrieb mit AMAD. Der Flow für VoiceControl splittet den String bei "und" und sendet die Teile seperat. Das ist für den Betrieb meines Moduls üüüberhaupt nicht gut. Der String muss als ganzes übertragen werden. Das müsste noch angepasst werden. Es kann zu unerwünschten Nebeneffekten kommen solltet ihr das nicht ändern  ;)

Possible Sets:

  • TextCommand: <textfield> : Eingabe des auszuwertenden Satzes.
  • AMADAnswer: text|voice|sonos : Eingaben die über das AMAD Device erkannt werden, werden auf diesen Devices auch beantwortet. Text auf dem Display des AMAD Devices. Voice per TTS auf dem AMAD Device. Sonos auf dem SonosGerät welches unter AMADSonos gesetzt werden kann ( Sonos Speak muss funktionieren)
  • AMADSonos: <textfield> : Angabe des Sonos Devices wenn AMADAnswer auf sonos gestellt ist
  • UserDefinedCommand: <textarea> : Definieren eines User definierten Input, Kommandos und Output. Detaillierte Beschreibung später
  • ActivateUserDefinedCommand: <Number> 1|0 : Aktivieren oder deaktivieren eines User definierten Kommandos
  • DeleteUserDefindesCommand: <Number> : Der User definierte Kommando wird gelöscht.

Possible Attr:

  • AMADDevice: <textfiled> : Angabe des AMAD Devices welches Überwacht werden soll
  • TelegramDevice <textfiled> : Angabe des TelegramDevices welches Überwacht werden soll
  • TelegramPeer <textfiled> : Angabe der PeerID von welcher Daten angenommen werden dürfen
  • informlowBatterie: 1|0 : Wenn leere Batterien auftreten werden diese automatisch an alle Ausgänge geschickt
  • sarReading: <textfield> : Angabe von Readings und wie diese Ersetzt werden:Beispiel:  on=an;off=aus;open=offen;closed=geschlossen;home=zuhause;present=anwesend

Possible Attr in anderen Devices:

  • HomeTalkControl: 1|0 : Darf dieses Device kontrolliert werden
  • HomeTalkUserDef*<textfiled> : Falls die Befehle zum ausführen anderes sind als es HomeTalk ausführt kann man es hier hinterlegen. Darüber ist es möglich Befehle "schöner" ausführen zu lassen.
    Beispiel:
    Schalte die Stehlampe aus (Bewirkt: set <Device> off)
    Wenn allerdings HomeTalkUserDefOff pct 0 hinterlegt ist bewirkt es  set <Device> pct 0 und die Lampe dimmt sich aus anstatt einfach auszuschalten.

Hier ein paar Beispiele aus meiner Konfiguration:
Schalte die Deckenlampe in der Küche aus
-> Schaltet das Gerät mit dem alias Deckenlampe und room Küche aus
Mach bitte alle Lampen im Wohnzimmer aus und dimme die Stehlampe im Büro auf 30%
-> Schaltet das structure device mit dem alias alle lampen und room Wohnzimmer aus und stellt das device mit dem alias Stehlampe und room Wohnzimmer auf 30

(Tip: Immer ganze Sätze stellen. Status Deckenlampe ist eher abgehackt und wird nicht erkannt. Wogegen wie ist der Status der Deckenlampe den erwünschten Effekt erzielt.

Wie ihr seht kann man auch verschachtelte Sätze stellen.
Dabei ist aber zu beachten das die Angabe eines Raumes und des Prädikates in den Satzteilen nach hinten vererbt wird.
Schalte in der Küche die Deckenlampe aus und die Tischlampe an
->Angesprochen werden in jedem Satzteil ein Device (alias Deckenlampe und alias Tischlampe) beide Devices müssen aber ebenfalls das attr room Küche beinhalten. Schalte wird ebenfalls auf den zweiten Satzteil bezogen allerdings dort mit dem Zusatz an. Somit wird die Deckenlampe in der Küche ausgeschaltet und die Tischlampe in der Küche eingeschaltet

UserDefinedCommand:
In dem Feld kann man ein Benutzerdefinierten Befehl anlegen
Beispiel in der Textarea:
IN:Mache einen Befehl anders
OUT:Ok dann werde ich das anders machen
DO:set testdevice off


Es werden also 3 Zeilen angelegt. IN, OUT und DO. Diese kann man dann mit benutzerdefinierten Befehlen füllen. Der Teil ist noch seeeeeehr schlecht aufgebaut. Aber man kann es testen.

Wenn ein Benutzerdefinierter Befehl in einem Teilstring erkannt wird, wird dieser nicht mehr ausgewertet um Devices zu schalten.


Lasst mich wissen wenn es ok, gut oder schlecht ist. Ich will mir da was schönes basteln und vielleicht kann es der eine oder andere auch gebrauchen

Gibts dafür nen eigenen Thread, hätte ein paar Fragen und ggfs. Erweiterungen/Änderungen als Vorschlag...

Grüße Marcel
NUC mit FHEM, HM Heizungsthermostate, HM Wandthermostate, Intertechno Funksteckdosen, 10" Tablet als Wanddisplay, KeyMatic, Fensterkontakte, Fensterkontakte umgebaut als Wassermelder und Briefkastenmelder, Aussenthermostat, Anwesenheitssteuerung über Fritz Box, Google Home usw. usw.

Prof. Dr. Peter Henning

#72
Ich bitte darum, dem Modul "HOMETALK" einen anderen Namen zu geben. Derzeit ensteht schon die HOMESTATE-Familie von Modulen - das ist viel zu generisch als Name.

Siehe hier:  https://forum.fhem.de/index.php/topic,72259.0.html

LG

pah

tiroso

#73
Zitat von: Prof. Dr. Peter Henning am 22 Mai 2017, 18:55:32
Ich bitte darum, dem Modul "HOMETALK" einen anderen Namen zu geben. Derzeit ensteht schon die HOMESTATE-Familie von Modulen - das ist viel zu generisch als Name.

Siehe hier:  https://forum.fhem.de/index.php/topic,72259.0.html

LG

pah

Das verstehe ich. Ich werde den Namen umgehend ändern  :)
Ich will das aber nicht als offizielles Modul einstellen. Einerseits weil ich nicht weiß wie es geht. Und anderseits weil ich nicht weiß ob ich auf dem Konstrukt eine Sprachbasierende Kontrolle weiter aufbauen kann.

Da bräuxhte ich die Meinung eines Fachmanns ob ich in die Richtung weiter machen kann.
Also klar kann ich das. Aber ob es auch Sinn macht. Das ist halt leider nur in meinem Laienhaften Leichtsinn entstanden.

@eurolift:
Was meinst du mit ausklammern? Nicht mit in die Bewertung und Analyse aufnehmen. Oder Sätze in denen kein Hotword vorkommt gar nicht erst auswerten?

@Marcel:
Wenn es generell gut ankommt kann ich das mal in Erwägung ziehen. Aber das passte gut ins Thema.

yrwyddfa

Zitat von: Prof. Dr. Peter Henning am 21 Mai 2017, 16:04:35
Was soll eigentlich das "hart kodiert" aussagen ?

Wenn man sich dumme Sprüche ansagen lässt, kommen diese natürlich aus einer Tabelle. Das ist aber nicht mehr oder weniger "hart" als ein kurzes Programm, das sich mit Hilfe einer Markov-Kette Antworten zusammenbastelt: In beiden Fällen gibt es nur eine endliche Anzahl von unterschiedlichen Antworten, die nach einem zufälligen Verfahren ausgewählt werden. Ich halte es für absurd, so etwas mit einer "Persönlichkeit" zu assoziieren.

Den "Coolness-Faktor" bevorzuge ich auch (in den SmartHome Hacks habe ich meine Vorliebe für eine Jeannie-Marilyn-HAL TTS ausführlich beschrieben), mein dienstbarer Geist heißt Jeannie. Aber deswegen lasse ich nicht die grundlegenden Regeln der Usability außer Acht.

Etwas Anderes wäre, wenn sich die Sprachansagen personalisieren ließen. Jeannie antwortet mir deshalb auch mit "Ja, Meister" - aber an der Unterscheidung der Stimmen verschiedener Hausbewohner bin ich bisher gescheitert.

LG

pah

Wie gesagt, ich kenne mich mit Programmierung nicht aus - und daher sind meiner Termini sicherlich auch nicht so akkurat wie sie sein könnten  ::)
Ich mag einfache Lösungen (und vor allem welche, die ich leicht verstehe  :P ). Und RS ist zwar sicher weder mächtig noch perfekt, aber es ist defacto leicht zu lernen und bringt sehr schnell recht effektive Ergebnisse (was heißt: ich kann mich auch etwas einbringen ^^).
Eine Persönlichkeit als solche zu programmieren ist natürlich nicht möglich, das sollten die Gänsefüßchen auch zum Ausdruck bringen. Aber beispielsweise immer nur 3-4 Standardantworten zu bringen, um dann beim z.B. 7. mal randomisiert irgendeinen blöden Spruch vom Stapel zu lassen hat schon was für sich und hält je nach Nutzungsintensität auch deutlich länger als eine Woche - und das muss der Usability nicht mal einen Abbruch tun (so lange man es nicht so aufsetzt, dass zuerst ein Sermon vom Stapel gelassen werden muss, ehe der eigentliche Befehl ausgeführt wird). Und wenn man dann noch die Möglichkeit hat, einen kurzen Plausch einzubauen, um bei Besuch einen Lacher auf seiner Seite zu haben - warum nicht?
Es ließe sich sogar darüber nachdenken, eine Art "Quickmode" einzubinden, in der man eben nur kurz und knackig die Befehle ohne Brimborium abgibt und eben nur kurz geantwortet wird. Unbekannte Fragen könnten dann mit einem "Du bist im Quickmode, möchtest Du ihn verlassen?" beantwortet werden.


Generell stimmt natürlich, dass man so oder so ohne weiteres keine selbstlernende bzw. sich selbst erweiternde Lösung hat (höchstens, wenn der Bot nach einer unbekannten Anfrage nachfragt, was er in Zukunft darauf antworten soll).
Alles in allem ist es ein super spannendes Thema, und wenn wir schon eine Sprachdatenbank anlegen sollten, warum sollte sie dann nicht auch mit einfacher Syntax zu bearbeiten sein (und vom "Arbeitscode" nicht getrennt)?

Liebe Grüße

yw
If every day has its number, Monday would be a zero division.