SNIPS: Sprachsteuerung (mittlerweile auch per Textcommands) über snips.ai

[bennebartsch]

Technisch ja, Snips unterstützt aber glaub nur ein Micro pro Device/Satellite.
Klar, man könnte auf dem NUC in VMs mehrere Satellites parallel laufen lassen und jeweils ein USB-Device an eine VM weiterleiten...

Schade, klingt nach einer unschönen Lösung... Meinst du man könnte per pulseaudio etc die beiden Mikros vereinen und dann an SNIPS weitergeben?
Für die, die auch gefühlt jeden Tag das Modul updaten:

Code Auswählen Erweitern


#!/bin/bash
git pull
sudo cp FHEM/10_SNIPS.pm /opt/fhem/FHEM/
sudo chown fhem:dialout /opt/fhem/FHEM/10_SNIPS.pm
sudo service fhem restart


[bennebartsch]

Wäre es evtl. möglich für On-Off Devices noch einen Toggle zu integrieren?
Quasi so:
Licht Badezimmer ein -> on
Licht Badezimmer aus -> off
Licht Badezimmer -> toggle

Wäre super!

[kud]

Ich hoffe, dass wir dem Initiator von Snips-FHEM nicht zu oft nerven bzw. anmotzen.
In so kurzer Zeit so viel auf die Beine zu stellen ist schon bemerkenswert.
Vielleicht sollten die Leute , welche Snips nach der Uhrzeit fragen mal Alexa nach dem Status vom Rasenmäher fragen.... "Tut mir leid ich kann kein Gerät Gerät Rasenmäher finden" etc.... Die nette Dame weiß gar nichts was FHEM betrifft. Da ist Snips-FHEM , mit richtiger Einrichtung, meilenweit voraus.
Ich hoffe der Entwickler "T" hat noch genug Geduld und Power. Ich freue mich jedenfalls über jede Neuerung. Und ganz objektiv vergleicht mal die Möglichkeiten mit Alexa und Google...

 

[Thyraz]

Und nochmal ein kleines Update, bevor es in die Kiste geht.

Ihr könnt mit attr <snipsDevice> errorResponse Oh oh was ist da passiert den Fehlertext der als Antwort ausgegeben wird anpassen.
Wenn ihr das Attribut auf "disabled" setzt, wird im Fehlerfall kein Text ausgegeben.

Damit erspart ihr euch das Editieren der Strings bei jeder neuen Version. 

edit: Keine Angst kud, so schnell lass ich mich nicht nerven.

[Thyraz]

Schade, klingt nach einer unschönen Lösung... Meinst du man könnte per pulseaudio etc die beiden Mikros vereinen und dann an SNIPS weitergeben?

Muss ich leider passen, hab pulseaudio selbst noch nie eingesetzt.

Evtl. mal in der Snips-Community fragen ob sich jemand schon einmal an sowas (mehrere Micros in einem Device) versucht hat,
oder ob es evtl. doch schon von Haus aus irgendwie mit Snips möglich ist.

Wäre es evtl. möglich für On-Off Devices noch einen Toggle zu integrieren?
Quasi so:
Licht Badezimmer ein -> on
Licht Badezimmer aus -> off
Licht Badezimmer -> toggle

Wäre super!

Nur den Gerätenamen zu sagen ruft schon den Status Intent auf.
Es müsste also über Wörter wie "toggle" oder Ähnliches im Satz getriggert werden.

Ist aber sicher mit irgendwelchen Beispielsätzen + etwas Programmieraufwand im Modul möglich sowas umzusetzen.
Da ich mir das selbst nicht so recht vorstellen kann: Nutzt man das wirklich? Also ein "Hey Snips, toggle Deckenlampe".

Normal will man ja was Bestimmtes erreichen und sagt dann eher ein/aus anstatt zu überlegen ob ich jetzt einfach den anderen Zustand will.
Bei der Automatisierung von irgendwelchen Aufgaben mag ein Toggle ja recht sinnvoll sein,
bei einem Sprachbefehl kommt mir das eher schwer von den Lippen.

Sprich: Wenn ihr mich vom Sinn überzeugt setze ich das gern auf die Todo Liste. 

[bennebartsch]

Muss ich leider passen, hab pulseaudio selbst noch nie eingesetzt.

Evtl. mal in der Snips-Community fragen ob sich jemand schon einmal an sowas (mehrere Micros in einem Device) versucht hat,
oder ob es evtl. doch schon von Haus aus irgendwie mit Snips möglich ist.

Nur den Gerätenamen zu sagen ruft schon den Status Intent auf.
Es müsste also über Wörter wie "toggle" oder Ähnliches im Satz getriggert werden.

Ist aber sicher mit irgendwelchen Beispielsätzen + etwas Programmieraufwand im Modul möglich sowas umzusetzen.
Da ich mir das selbst nicht so recht vorstellen kann: Nutzt man das wirklich? Also ein "Hey Snips, toggle Deckenlampe".

Normal will man ja was Bestimmtes erreichen und sagt dann eher ein/aus anstatt zu überlegen ob ich jetzt einfach den anderen Zustand will.
Bei der Automatisierung von irgendwelchen Aufgaben mag ein Toggle ja recht sinnvoll sein,
bei einem Sprachbefehl kommt mir das eher schwer von den Lippen.

Sprich: Wenn ihr mich vom Sinn überzeugt setze ich das gern auf die Todo Liste. 

Ich werde die Snips Community mal dazu befragen, trotzdem Danke!
Also bis vorgestern hatte ich noch 2 Google Home Minis (dank dir endlich nicht mehr!) und ich habe immer gerne einfach nur "Licht Badezimmer" oder "Licht Küche" gesagt um es zu "togglen". Ist natürlich Geschmackssache... Deine Entscheidung, du baust ja dieses wunderbare Modul!

[Thyraz]

Ok, damit kann ich das Anliegen nachvollziehen.

Es geht also weniger darum einen Befehl zum togglen zu haben,
sondern eher darum ein noch kürzeren Sprachbefehl zu haben (und bei Sprachbefehlen ist auf Dauer kürzer immer besser. )

Wie gesagt, belegt die Ansage nur vom Devicenamen (oder Raum + Device) eigentlich der Status Intent.
Klar könnte man nun sagen, wenn das Gerät kein Status Mapping hat, dann versuche es erstmal mit SetOnOff.

Das Problem liegt hier aber in der Funktionsweise von Snips:
Es hat kein Wissen über dein Smarthome, sondern entscheidet allein über den gesprochenen Satz (mithilfe des NLU Moduls) welcher Intent gemeint ist.

Ich müsste also bevor ich bei einem einkommenden Befehl zu dem Code für den entsprechenden Intent springe, erstmal eine komplizierte Sonderbehandlung einführen.
Diese müsste prüfen ob im Falle eines Status-Intents wirklich nur das Device (und nicht etwa "Status Gerät") genannt wurde, kein Status Mapping existiert und dafür SetOnOff konfiguriert ist.
Dann den Intent von Status auf SetOnOff umbiegen.

Das ist ne Menge Extrawurst nur um ein kurzes Wort wie "an/aus" einzusparen.

Zusätzlich wird es für den User schwieriger zu verstehen wie sein Sprachassistent denn nun tickt.
Mal antwortet er mit dem aktuellen Status, beim nächsten Gerät schaltet er plötzlich ein/aus.
Kann eigentlich nur der verstehen, der die Diskussion hier mitgelesen hat.

Ich würde aktuell eher dazu neigen den Status Intent so auszubauen, dass er versucht auch antworten zu können wenn kein Status Mapping erstellt wurde.
Man könnte das Mapping dann erstmal nach GetOnOff durchsuchen und wenn es das auch nicht gibt nach GetNumeric.
Als letzter Fallback evtl. sogar den State vom Gerät nutzen.

Dann eine entsprechende Rückmeldung wie "Deckenlampe ist eingeschaltet".

Es hat noch einen weiteren Grund warum mir ein lesender Befehl bei der Ansage nur vom Gerät lieber ist als ein setzender:
Wenn Snips nicht den ganzen Satz versteht ist es mir schon passiert, dass eben der Status Intent aufgerufen wurde.
In solch einem Fehlerfall ist es mir lieber, wenn ich nur die Ansage über den Status bekomme, als dass das Gerät ungewollt geschaltet wird.

[Wal]

Schön wäre ein:

"Licht ein"
"Wo?"
"Wohnzimmer"
o.
"Temperatur"
"Wo?"
"Draussen"

Auf Rückmeldungen könnte ich verzichten es genügt ein OK, es sei denn ich wünsche ein Status, wie im zweiten Beispiel.

[Thyraz]

Hi Wal

das dürfte auch wieder eine Geschmacksfrage sein.

Ich habe das Konzept bisher so umgesetzt, dass Snips beim Nicht-Nennung eines Raumes immer davon ausgeht,
dass der aktuelle Raum gemeint ist.
Mir hat an Snips eben gerade gefallen, dass es Multiroom-tauglich ist.

Mir erschien es wichtiger im aktuellen Raum kurz und knackig das Licht mit "Licht an" anschalten zu können.

"Licht ein"
"Wo?"
"Wohnzimmer"

dauert durch das hin und her IMO weit länger als einfach "Licht im Wohnzimmer einschalten" zu sagen.
Da bin ich schneller zum Lichtschalter gelaufen, auch wenn das nicht als smarte Lösung gelten mag.

[bennebartsch]

Danke für deine ausführliche Antwort. Jetzt verstehe ich wo das Problem liegt, ist also mit SNIPS nicht ganz so leicht umzusetzen. Ist ja auch kein Problem, damit kann ich leben!

Ich weiß ich nerve dich vermutlich schon, aber was hälst du davon Farben zu integrieren (RGB, RGBW)? So in etwa:
Schalte LED auf Blau -> set LED rgb 0000FF
Schalte LED auf Rot   -> set LED rgb FF0000

[Wal]

Hi Wal

das dürfte auch wieder eine Geschmacksfrage sein.

Ich habe das Konzept bisher so umgesetzt, dass Snips beim Nicht-Nennung eines Raumes immer davon ausgeht,
dass der aktuelle Raum gemeint ist.
Mir hat an Snips eben gerade gefallen, dass es Multiroom-tauglich ist.

Mir erschien es wichtiger im aktuellen Raum kurz und knackig das Licht mit "Licht an" anschalten zu können.dauert durch das hin und her IMO weit länger als einfach "Licht im Wohnzimmer einschalten" zu sagen.
Da bin ich schneller zum Lichtschalter gelaufen, auch wenn das nicht als smarte Lösung gelten mag.

Da hast du ja Recht. Bin ja froh, das es einer in die Hand genommen hat. Bei den Cloud-Lösungen stellen sich mir die Nackenhaare hoch.

[Thyraz]

... damit kann ich leben!

...aber was hälst du davon Farben zu integrieren (RGB, RGBW)?

Freut mich wenn es nachvollziehbar und zu ertragen ist.
Nur weil ich das Modul schreibe, soll das hier ja keine Friss oder Stirb Diskussion werden.

Im Gegenteil, gute Ideen sind immer willkommen.


Daher gleich zum Thema Farben:
(Landet auf der Todo-Liste aber etwas weiter hinten, da jetzt erstmal die Mediengeschichten kommen.)

Wie läuft das denn bei anderen Assistenten wie Siri/Alexa?
Gibt es ein paar definierte Farbtöne die man eben nutzen kann?

Bin gerade am überlegen wie man das am Besten umsetzt.
Man könnte auch versuchen das Ganze etwas flexibler zu gestalten als bei der Konkurrenz.
Nehmen wir an es gäbe ein extra Attribut snipsColors das man einer Lampe mit Farbsteuerung zuweisen kann:

Code Auswählen Erweitern


weiß=ct 3000
warmweiß=ct 2700
rot=rgb ff0000
blau=rgb 0000ff
lilablassblau=rgb b7b4ff


Vorteil der Lösung:
Ihr könnt beliebige Farbnamen selbst definieren, deren Bezeichnungen dann wieder per ASR Inject in Snips bekannt gemacht werden.
Dadurch, dass man hinter dem Gleichzeichen den gesamten set Befehl angeben würde, könnte man auch über verschiedene Kommandos Farben setzen.
Gerade bei Hue Lampen sind schöne Weißwerte über RGB ja nur schwer zu erreichen. CT bietet sich hier mehr an.

Oder ist das Overkill zum Einrichten und eine einfache Zeile im Attribut snipsMapping mit ein paar Grundfarben gefällt euch besser:

Code Auswählen Erweitern


Color:cmd=rgb,valWhite=ffffff,valRed=ff0000,valGreen=00ff00,...

Hier könnte es dafür im Modul schon vorbelegte Farbwerte für diverse Standardfarben geben, so dass man nur die Farben im Mapping überschreiben muss, welche man anpassen will.

Verschiedene Ansteuerung wie CT oder RGB gäbe es halt nicht (Weißtöne kann man ja aber auch z.B. über den SetNumeric Intent steuern, muss halt dann als Zahl in Kelvin erfolgen), eigene Farbnamen erfinden auch nicht.

Meinungen dazu?

[bennebartsch]

Freut mich wenn es nachvollziehbar und zu ertragen ist.
Nur weil ich das Modul schreibe, soll das hier ja keine Friss oder Stirb Diskussion werden.

Im Gegenteil, gute Ideen sind immer willkommen.


Daher gleich zum Thema Farben:
(Landet auf der Todo-Liste aber etwas weiter hinten, da jetzt erstmal die Mediengeschichten kommen.)

Wie läuft das denn bei anderen Assistenten wie Siri/Alexa?
Gibt es ein paar definierte Farbtöne die man eben nutzen kann?

Bin gerade am überlegen wie man das am Besten umsetzt.
Man könnte auch versuchen das Ganze etwas flexibler zu gestalten als bei der Konkurrenz.
Nehmen wir an es gäbe ein extra Attribut snipsColors das man einer Lampe mit Farbsteuerung zuweisen kann:

Code Auswählen Erweitern


weiß=ct 3000
warmweiß=ct 2700
rot=rgb ff0000
blau=rgb 0000ff
lilablassblau=rgb b7b4ff


Vorteil der Lösung:
Ihr könnt beliebige Farbnamen selbst definieren, deren Bezeichnungen dann wieder per ASR Inject in Snips bekannt gemacht werden.
Dadurch, dass man hinter dem Gleichzeichen den gesamten set Befehl angeben würde, könnte man auch über verschiedene Kommandos Farben setzen.
Gerade bei Hue Lampen sind schöne Weißwerte über RGB ja nur schwer zu erreichen. CT bietet sich hier mehr an.

Oder ist das Overkill zum Einrichten und eine einfache Zeile im Attribut snipsMapping mit ein paar Grundfarben gefällt euch besser:

Code Auswählen Erweitern


Color:cmd=rgb,valWhite=ffffff,valRed=ff0000,valGreen=00ff00,...

Hier könnte es dafür im Modul schon vorbelegte Farbwerte für diverse Standardfarben geben, so dass man nur die Farben im Mapping überschreiben muss, welche man anpassen will.

Verschiedene Ansteuerung wie CT oder RGB gäbe es halt nicht (Weißtöne kann man ja aber auch z.B. über den SetNumeric Intent steuern, muss halt dann als Zahl in Kelvin erfolgen), eigene Farbnamen erfinden auch nicht.

Meinungen dazu?

Also ich finde das ist kein Overkill. Die 2. Lösung ist etwas zu unflexibel bei Lampen die nicht nur RGB in der Setlist haben. Ich bin für die 1. Lösung, diese sollte allerdings "Standartwerte" haben (z.B. valBlau = 0000FF), sodass man nur bei einigen Lampen die Farbtöne/Kommandos anpassen muss.

[shilbert]

Danke für das coole Modul. Wird immer besser.

Nur falls jemand von euch Problem mit "clipping" bei der Sprachausgabe hat ... Bei mir war die Sprachausgabe zu laut und hat den Lautsprecher am Google AIY Voice Kit scheppern lassen.

Es gibt die Möglichkeit, die Lautstärke für TTS getrennt anzupassen.

[snips-tts]
## Choose one tts provider (defaults to picotts)
# provider = "picotts"
# provider = "makerstts"
provider = "customtts"
## customtts specific configuration (here configured to use picotts)
#customtts = { command = ["pico2wave", "-w", "%%OUTPUT_FILE%%", "-l", "%%LANG%%", "%%TEXT%%"] }
customtts = { command = ["picospeaker", "-o", "%%OUTPUT_FILE%%", "-l", "%%LANG%%", "-v", "0.5", "%%TEXT%%"] }

https://github.com/the-kyle/picospeaker/blob/master/picospeaker herunterladen und installieren. Details stehen in der Datei selbst.

Damit %%LANG%% funktioniert, braucht ihr noch einen Patch

--- picospeaker.bak     2018-08-27 22:03:05.000000000 +0200
+++ picospeaker 2018-08-27 23:49:35.289440981 +0200
@@ -59,8 +59,16 @@
       exit(0)
     elif ( argv[opt] == '-l' ) or ( argv[opt] == '--language' ):
       languages = ('en-US', 'en-GB', 'de-DE', 'es-ES', 'fr-FR', 'it-IT')
+      lang_map = {
+       'en': 'en-US',
+       'de': 'de-DE',
+       'es': 'es-ES',
+       'fr': 'fr-FR',
+       'it': 'it-IT'}
       if ( argv[opt+1] in languages ):
         settings['language'] = argv[opt+1]
+      elif ( argv[opt+1] in lang_map.keys() ):
+       settings['language'] = lang_map[argv[opt+1]]
       else:
         stderr.write('Language ' + argv[opt+1] + ' is currently not available.\n')
         stderr.write('Available languages are ' + ', '.join(languages[:-1]) + ' and ' + languages[-1] + '.\n')

[shilbert]

Hi,

Du hast set <snipsDevice> say Dies ist ein Test implementiert. Kann man da ggf. noch den Namen eines Satelliten mitgeben ? Sonst kommt das vermutlich auf dem zentralen Snips-Device raus und dort ist kein Lautsprecher angeschlossen.