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

[ahlermi]

Ich benutze das "init" nicht

[bennebartsch]

Habe noch ein paar Probleme mit den Shortcuts. Diese werden leider weiterhin nur per Spracheingabe erkannt, nicht per textCommand.

Mein shortcuts Attribut sieht aktuell so aus:

Code Auswählen Erweitern


Wieviel Uhr ist es={return "es ist " . qx(date +%R);}
Wieviel Uhr haben wir={return "es ist " . qx(date +%R);}
Roomba Dock={fhem("set roomba980 dock"); return "ok";}
Schicke den Staubsauger nach Hause={fhem("set roomba980 dock"); return "ok";}
Audio Fernseher={return "es ist " . qx(date +%R);}
Quelle TV={fhem("set audio_source TV"); return "ok";}
Audio TV={fhem("set audio_source TV"); return "ok";}
Quelle Fernseher={fhem("set audio_source TV"); return "ok";}

Die ersten 4 Shortcuts funktionieren, die anderen habe ich bis jetzt nicht einmal zum triggern bekommen. Snips gibt immer nur den Fehlerton aus... updateModel und Snips neustarten habe ich schon probiert.

[bennebartsch]

Sorry wenn ich euch schon nerve, aber habe noch ein kleines Problem:
Meine LEDs steuere ich über das Device Farbe in FHEM. Dazu nutze ich snipsColors und kann auch wunderbar alle definierten Farben setzten. Leider funktioniert dann das snipsMapping mit SetOnOff:cmdOn=on,cmdOff=off nicht mehr, Snips denkt immer ich möchte eine Farbe setzten:

Code Auswählen Erweitern

{"input":"farbe einschalten","intent":"SetColor","probability":"0.8885536","requestType":"voice","sessionId":"b3b3eca6-1be2-4d55-98c5-e4b39576c90d","siteId":"default"}


Ist das so gewollt?

[Eisix]

Habe mittlerweile die Datei /etc/snips.toml gefunden, in der die snips service Konfiguration zumindest teilweise liegt.

Das FHEM Modul MQTT2 scheint nicht die richtigen Protokolle zu unterstützen.

Code Auswählen Erweitern


Sep 18 14:11:50 home systemd[1]: Started Snips NLU.
Sep 18 14:11:50 home snips-nlu[13908]: ERROR:snips_nlu: Could not start MQTT client
Sep 18 14:11:50 home snips-nlu[13908]:  -> caused by: mqtt negogiation failed with return code: RefusedProtocolVersion
Sep 18 14:11:50 home systemd[1]: snips-nlu.service: Main process exited, code=exited, status=1/FAILURE
Sep 18 14:11:50 home systemd[1]: snips-nlu.service: Unit entered failed state.
Sep 18 14:11:50 home systemd[1]: snips-nlu.service: Failed with result 'exit-code'.
Sep 18 14:11:55 home systemd[1]: snips-nlu.service: Service hold-off time over, scheduling restart.
Sep 18 14:11:55 home systemd[1]: Stopped Snips NLU.


Somit startet auch keiner der Snips services. OS ist stretch Debian/amd64. Jemand die Kombination am laufen und einen Tip?

Gruß
Eisix

[bennebartsch]

Habe mittlerweile die Datei /etc/snips.toml gefunden, in der die snips service Konfiguration zumindest teilweise liegt.

Das FHEM Modul MQTT2 scheint nicht die richtigen Protokolle zu unterstützen.

Code Auswählen Erweitern


Sep 18 14:11:50 home systemd[1]: Started Snips NLU.
Sep 18 14:11:50 home snips-nlu[13908]: ERROR:snips_nlu: Could not start MQTT client
Sep 18 14:11:50 home snips-nlu[13908]:  -> caused by: mqtt negogiation failed with return code: RefusedProtocolVersion
Sep 18 14:11:50 home systemd[1]: snips-nlu.service: Main process exited, code=exited, status=1/FAILURE
Sep 18 14:11:50 home systemd[1]: snips-nlu.service: Unit entered failed state.
Sep 18 14:11:50 home systemd[1]: snips-nlu.service: Failed with result 'exit-code'.
Sep 18 14:11:55 home systemd[1]: snips-nlu.service: Service hold-off time over, scheduling restart.
Sep 18 14:11:55 home systemd[1]: Stopped Snips NLU.


Somit startet auch keiner der Snips services. OS ist stretch Debian/amd64. Jemand die Kombination am laufen und einen Tip?

Gruß
Eisix

Was spricht denn gegen einen externen MQTT Broker? Ich habe zum Beispiel viele Lampen und Lichtschalter per MQTT eingebunden und diese funktionieren auch noch wenn FHEM mal abschmieren sollte. Das ist ja gerade das schöne an MQTT.

[Eisix]

Was dagegen spricht ist:
- zusätzlicher Service der Konfiguriert, abgesichert und administriert werden muß
- doppelter Konfigurationsaufwand Fhem und Mosquitto
- bei Neuinstallation müssen alle Abhängigkeiten wieder hergestellt werden. Beim Modul ist alles drin und geht.

Nutze MQTT noch nicht aber hatte es vor. Und bevor ich damit anfange versuche ich halt schon die effizienteste Variante zu evaluieren.
Wenn Mosquitto der einzige Weg ist, dann ist die Entscheidung aber klar.

Gruß
Eisix

[bennebartsch]

Klar, sind auch alles Argumente. Wenn du aber eh in Zukunft mal mit MQTT basteln willst installier einfach eben den Broker, bei mir hats keine Minute gedauert!

[ahlermi]

Hallo Thyraz,

kannst du wohl noch einen Satz für das Intent SetOnOff aufnehmen?

Code Auswählen Erweitern


Schalte Standardgerät aus


Da tut sich SNIPS echt schwer.

Gruß Michael

[ahlermi]

Sorry wenn ich euch schon nerve, aber habe noch ein kleines Problem:
Meine LEDs steuere ich über das Device Farbe in FHEM. Dazu nutze ich snipsColors und kann auch wunderbar alle definierten Farben setzten. Leider funktioniert dann das snipsMapping mit SetOnOff:cmdOn=on,cmdOff=off nicht mehr, Snips denkt immer ich möchte eine Farbe setzten:

Code Auswählen Erweitern

{"input":"farbe einschalten","intent":"SetColor","probability":"0.8885536","requestType":"voice","sessionId":"b3b3eca6-1be2-4d55-98c5-e4b39576c90d","siteId":"default"}


Ist das so gewollt?

Ist Farbe als Gerät nicht etwas unglücklich gewählt? Was passiert wenn du es LED nennst?

[bennebartsch]

Ist Farbe als Gerät nicht etwas unglücklich gewählt? Was passiert wenn du es LED nennst?

Das Gerät hat auch LED im SnipsName, allerdings reagiert Snips darauf nicht...

[Thyraz]

Habe noch ein paar Probleme mit den Shortcuts. Diese werden leider weiterhin nur per Spracheingabe erkannt, nicht per textCommand.

Kannst du mal die Logausgaben dazu posten mit verbose 5 (nur beim Snips Device) wenn du einen Shortcut zu triggern versuchst?
Dazu ein komplettes list vom Snips-Device?

Die ersten 4 Shortcuts funktionieren, die anderen habe ich bis jetzt nicht einmal zum triggern bekommen. Snips gibt immer nur den Fehlerton aus... updateModel und Snips neustarten habe ich schon probiert.

Ja, wie beschrieben ist es gerade bei kürzeren Sätzen teilweise problematisch, da NLU das ganze als "Kann ich nichts mit anfangen" abschmettert.
Solange es kein offizielles NLU Inject gibt, werden wir da wenig tun können.

Sobald das da ist, sollte es mit dem jetzigen Code dann einfach plötzlich funktionieren.

Sorry wenn ich euch schon nerve, aber habe noch ein kleines Problem:
Meine LEDs steuere ich über das Device Farbe in FHEM.

Ich denke auch, dass Snips da komplett durcheinander kommt.
Würde mal versuchen einen anderen Namen zu vergeben, dann den Assistenten neu installieren,
damit der alte NLU Inject mit Farbe im Deviceslot verschwindet und erneut updateModel ausführen.

Was dagegen spricht ist:

Was dafür spricht:
Snips schickt konstant den gesamten Audiotraffic als Message-Payloads über den MQTT Server.
Die einzelnen Snips-Module kommunizieren halt auch nur über MQTT miteinander.
Da kommt so einiges zusammen.
Würde das nicht einem in Perl geschriebenen MQTT Server zumuten, als auch FHEM nicht damit belasten wollen.

Hallo Thyraz,

kannst du wohl noch einen Satz für das Intent SetOnOff aufnehmen?

Code Auswählen Erweitern


Schalte Standardgerät aus

Da tut sich SNIPS echt schwer.

erledigt.

[ahlermi]

erledigt

Hast du eine Idee wie das kann?
Text sauber erkannt, und dann macht SNIPS mist und übergibt mir auch garnichts

EDIT
Habe gerade nochmal die APP geforkt und sehe das Kommando auch noch nicht, vlt war ich ja zu schnell.

[Thyraz]

Hatte vergessen auf publish zu drücken.
Versuchs jetzt nochmal...

[martin-s]

Hi,

ich hätte im Anhang ein paar Verbesserungsvorschläge für das Snips-Modul:

• Wenn man bei say die siteId verwendet, funktionierte das bisher nur bis zum 1. Leerzeichen, jetzt werden Leerzeichen sinnvoll behandelt. Doppelpunkte führen aber immer noch zu Problemen
• Man kann im GetNumeric-Mapping jetzt analog dem Status-Mapping response angeben und damit die vorgegebenen Texte überschreiben. Nachtrag: Oops, habe gelesen dass das schon drin ist
• Man kann bei Custom Intents jetzt als Parameter "data" oder "hash" angeben und bekommt dann die komplette Snips-Antwort bzw. den SNIPS-Device-Hash geliefert
• Zu "Da ist etwas schief gelaufen." kommt noch "Ich habe blabla verstanden" (Praktisch fürs Debugging, sollte man vielleicht über ein Attribut konfigurierbar machen)
• Multi-Turn-Dialog. Das braucht eine etwas ausführlichere Erklärung

Mit dem Multi-Turn-Dialog kann man (bei Custom Intents) jetzt Rückfragen stellen.
Nicht sehr sinnvolles Beispiel:

Code Auswählen Erweitern


sub
my_snips_good_morning()
{
        my $text="Ebenfalls einen guten Morgen. Soll ich den Rollo öffnen?";
        return { 'text' => $text, 'topic' => 'continueSession', 'intentFilter' => [ 'my-intent:yes','my-intent:no', 'my-intent:abort' ], 'sessionData' => { 'intent' => 'good_morning'} };
}


Damit wird auf den Custom Intent "Guten Morgen" eine Antwort gegeben und eine Frage gestellt.
Aufgrund 'continueSession' geht Snips sofort wieder in den ASR-Modus und erwartet einen Intent aus der angegebenen Liste.
sessionData wird dabei dem neuen Intent in "data" übergeben (so wie das momentan ist werden die Daten allerdings nie frei gegeben falls der Dialog durch einen Fehler abbricht).

Code Auswählen Erweitern


sub
my_snips_yes($)
{
        my ($data)=@_;
        if ($data->{sessionData}{intent} eq 'good_morning') {
                fhem("set rollo up");
                return "Alles klar";
        }
        return "Ich verstehe den Zusammenhang nicht";
}


Ciao,

Martin

[ahlermi]

   Besser

nur irgendwie kommt SNIPS manchmal nicht klar und übergibt raus anstelle von aus...