Modulentwicklung für Rhasspy Sprachassistent

[JensS]

Immer noch nicht getestet aber eine Idee zur Argumenteübergabe.
sentences.ini

Code Auswählen Erweitern

wähle (alle{$Intent,print=all}|playlist{$Intent,print=playlist}|genres{$Intent,print=genres}|artists{$Intent,print=artists})
getMpdSlots.pl

Code Auswählen Erweitern

$md = $ARGV[0] // "print=playlist";
if ($md eq "print=all"){$mode = 0}elsif($md eq "print=playlist"){$mode = 1}elsif($md eq "print=genres"){$mode = 2}elsif($md eq "print=artists"){$mode = 3};

[JensS]

Mein MPD-Device musste ich gerade löschen, weil irgendwas FHEM komplett blockiert hat. Das hängt aber nicht mit der Änderung zusammen. Hatte es schonmal und damals verdrängt. Irgendein Radiosender scheint nicht kompatibel zu sein...

Das Konstrukt zw. 73_MPD.pm, sentences.ini, getMpdSlots.pl und slot_programs/??? gibt mir noch Rätsel auf. Wo soll was hin?
In meinem Pythonscript hatte ich ein die gefundenen Slotwerte in eine Hilfsdatei slots/fhemtester geschrieben.
Wenn man die Slotwerte direkt im Slotprogramm ausgibt, funktioniert zwar die Erkennung aber man kann nicht separat auf die Slotwerte zugreifen.
Sie erscheinen nicht im Webinterface unter Slots und auch nicht beim Webaufruf /api/slots.
Für eine Argumenteverarbeitung wäre aber wichtig, die generierten Slotelemente auswerten zu können.

Gruß Jens

[Beta-User]

Mein MPD-Device musste ich gerade löschen, weil irgendwas FHEM komplett blockiert hat. Das hängt aber nicht mit der Änderung zusammen. Hatte es schonmal und damals verdrängt. Irgendein Radiosender scheint nicht kompatibel zu sein...

Es ist m.e. eher der Versuch, "alles" zu laden. Die load.*-Attribute auf "0" setzen sollte helfen. (Muss mal schauen, ob es sinnvoll ist, das default-Verhalten zu ändern).

Das Konstrukt zw. 73_MPD.pm, sentences.ini, getMpdSlots.pl und slot_programs/??? gibt mir noch Rätsel auf. Wo soll was hin?

Die 73_MPD kann halt zusätzlche Befehle, die wir hoffentlich irgendwann brauchen.

Das Perl-Script kann dazu genutzt werden, entweder "alles" anzuzeigen, oder eben unter je einem eigenen Namen und passendem Wert für $mode DIREKT als slot-Programm genutzt werden.

Ich mache damit im Moment einen Gesamt-output und scheibe den per > in eine Datei und kopiere dann die Teile jeweils zum Testen raus - das aber bisher nur in Teilen...

In meinem Pythonscript hatte ich ein die gefundenen Slotwerte in eine Hilfsdatei slots/fhemtester geschrieben.

Dieser Umweg ist m.E. ein komischer workaround. "Ganz oder gar nicht"...

Das ganze ist im Moment eine Baustelle mit vielen offenen Fragen. Die Einzelteile sehen aber schon ganz ok aus .

[JensS]

Beim MPD-Test muss ich passen. Das MPD-Modul blockieret hin und wieder beim Senderwechsel und dann muss FHEM gekillt werden.
Die Inhalte des MPD habe ich auf eine MP3-Datei und drei Radiosender gekürzt.
Hab den MPD mal mit einem eigenen Steuerungsscript getestet - da gab's bisher noch keine Abstürze. Bin noch auf der Suche...

[Beta-User]

Beim MPD-Test muss ich passen. Das MPD-Modul blockieret hin und wieder beim Senderwechsel und dann muss FHEM gekillt werden.
Die Inhalte des MPD habe ich auf eine MP3-Datei und drei Radiosender gekürzt.

Hmm, unschön...

Komme auch nicht recht weiter mit dem Testen, hatte aber bisher keine Blockaden beobachtet.
Meine playlists sind aber auch eher kurz (was Name und Inhalt angeht). Die verweisen nur auf Sendernamen wie "SWR 1", abgespielt werden sollte dann eigentlich ein Stream, der vom TvHeadend-Server bereit gestellt wird. Da hat sich aber auch irgendwas geändert, so dass ich zwar sehe, dass (im MPD) die ind er playlist stehende Streamnummer geändert wird, aber effektiv kommt dann kein Ton...

Gibt es irgendwelche Sender, bei denen das mit dem Hängenbleiben besonders gerne passiert? Weisen die irgendwelche Besonderheiten auf (Umlaute, Apostrophen, sowas in der Art...)?

Hab den MPD mal mit einem eigenen Steuerungsscript getestet - da gab's bisher noch keine Abstürze. Bin noch auf der Suche...

Bisher hat mein MPD auf den abgespeckten Code aus dem Modul immer zackig reagiert, von daher würde ich ungerne zu viel Code "außerhalb" des FHEM-(MPD)-Moduls durch RHASSPY aufrufen lassen.
Allerdings: nachdem ich ein wenig mit dem MPD-Modul und dem Protokoll an sich (https://mpd.readthedocs.io/en/latest/protocol.html) rumgespielt habe, ist es vermutlich am Ende das einfachste, doch eine Art "Roh-Kommando" auf der RHASSPY-Seite zusammenzubasteln und das dann komplett über "mpdCMD" an MPD zu übergeben. Das gibt dann so oder so ein paar "Sonderlocken", um das hinzubiegen...

Wenn dieser "Master" dann mal steht, können wir ja versuchen, das auf "DNLA-Geräte" zu übertragen. Viel mehr Typen scheinen ja im Moment nicht im Umlauf zu sein, und wer einen "sowieso-online-Dienst" wie spotify im Einsatz hat, hat vermutlich schon das Problem, dass es nicht nur "viele" unbekannte Worte sind, sondern "zu viele" für eine Rhasspy-"Verslottung"....

[Beta-User]

- Für MPD sind jetzt ein paar features drin, von denen ich bisher auch nicht in vollem Umfang weiß, ob sie funktionieren.
[...]
Jetzt muss ich erst mal meinen MPD (oder genauer gesagt: das OS von dem Rechner, auf dem der läuft) updaten, dann sehen wir weiter...

Ein paar kleinere Anpassungen waren noch nötig, aber im Prinzip sollte man jetzt beliebige FILTER-Anweisungen an einen halbwegs aktuellen mpd-Dienst (immer über das MPD-Modul) schicken können und/oder das ganze begrenzen auf eine gewisse Anzahl von hinzuzufügenden Elementen. Wenn man das letztere macht, gibt es ein zufälliges Ergebnis aus den gesamten zur Verfügung stehenden passenden Titeln (oder eben der vorhandenen Gesamtzahl, wenn die geringer ist als die übergebene max.-Anzahl).

Konkret getestet:
"spiele ein paar songs von Marillion"

Es sollte aber auch sowas gehen:
"spiele 20 Lieder aus Dark Side of the Moon"
"spiele auch 100 jazz titel"

[Prof. Dr. Peter Henning]

Ich halte das MPD-Modul (und MPD...) für nicht ganz ausgereift. Wenn ich Musik auf einer Linux-Kiste abspiele, geht das über den mpg123 und ein paar Perl-Routinen zur Ansteuerung.

Insofern sollte man sich vielleich über eine Abstraktionsschicht einigen:  Welches sind die generischen Kommandos, die eine Sprachsteuerung für das Abspielen von Musik beherrschen sollte?

LG

pah

[JensS]

Ich halte das MPD-Modul (und MPD...) für nicht ganz ausgereift.

Dem kann ich mich anschließen.
Die Ursache für den Halt von FHEM durch das MPD-Modul liegt darin begründet, dass der MPD-Server irgendwann keine Antwort mehr sendet und eine while-Schleife im Modul blockiert. Ein Fork inkl. wait und/oder $SIG{ALRM} könnte zumindestens FHEM am laufen halten. In der jetzigen Fassung ist eine Nutzung von 73_MPD.pm zu riskant. Ich schau mal, was ich da machen kann.

Gruß Jens

[Beta-User]

Insofern sollte man sich vielleich über eine Abstraktionsschicht einigen:  Welches sind die generischen Kommandos, die eine Sprachsteuerung für das Abspielen von Musik beherrschen sollte?

Hmmm, ich würde da vor dem Hintergrund meiner bisherigen Erfahrungen mit dem Thema in mehrerlei Hinsicht zwischen "Pflicht" und "Kür" trennen...

Ausgangspunkt ist zum einen, dass eine Sprachsteuerung in der Lage sein sollte, eine Anzahl Basiskommandos umzusetzen, die grob in
https://wiki.fhem.de/wiki/DevelopmentGuidelinesAV (Kommandos) umrissen sind, wobei ich on/off nicht direkt dazuzählen würde, sondern es auf die "Klassiker" play/pause/stop beschränken würde. Im "engeren Kreis" würde ich dann noch "playlist" sehen, wobei das als Teil einer "Content-Steuerung" schon zur "Kür" gehört.

Alles, was an "content-Steuerung" darüber hinausgeht, gehört in den Bereich "nice to have". Die jetzige "Lösung" mit MPD und der automatisierten Generierung von slots für RHASSPY ist auch imo irgendeine Form von Kompromis, von dem ich noch nicht weiß, ob er ein guter ist... Ziel war erst mal, _eine mögliche_ Lösung für die Aufgabe "spiele Musik von den Pogues" zu präsentieren .

RHASSPY erkennt die obigen Basiskommandos, wenn vorhanden, sowie auch "playlist" und kann dann das betreffende Gerät direkt steuern, wenn man die entsprechenden Werte nach {Command} übergibt bzw. ggf. dann zusätzlich {Playlist}.

Aber bereits da beginnen gewisse "Problemchen" - playlist-Kommandos setzen nämlich nicht nur voraus, dass das Gerät das auch kann (device-media ist daher nur eine Art Vor-Filter), sondern das Gerät dann auch noch genau diese Playlist kennt. Wenn man also nicht nur ein entsprechendes Gerät hat, wird es schnell "spaßig". Das gilt dann noch viel mehr für "generelle Content-Ermittlung" (anhand Genre, Interpret, ...).

Will man sowas umsetzen, erweitert sich der Kreis der generischen Kommandos dann noch um "füge zur aktuellen Abspielliste noch etwas hinzu" und "ersetze die aktuelle Abspielliste mit einer neuen (dynamisch erstellten)". Habe dafür mal die "Etiketten" 'cmdAddSelected' und 'cmdPlaySelected' vergeben.

Will man eine "generalisierte Content-Ermittlung" haben, ist es (zumindest für "cloud-free"-Lösungen) m.E. zweckmäßig, einen einzigen zentralen Dienst vorzusehen, der dann als "Infoquelle" einerseits für die Sprachsteuerung dient (@Rhasspy: slot-Erstellung), und andererseits eben von möglichst allen "Abspielgeräten" als Medienquelle genutzt werden kann.

Ich halte das MPD-Modul (und MPD...) für nicht ganz ausgereift. Wenn ich Musik auf einer Linux-Kiste abspiele, geht das über den mpg123 und ein paar Perl-Routinen zur Ansteuerung.

MPD (der Dienst) ist für mich bisher der beste (aktuelle) Kompromis für die Musikwiedergabe gewesen.

Vielleicht hole ich an der Stelle etwas aus:
Früher hatte ich für sehr lange Zeit Amarok (1.4) im Einsatz, dafür gab es (irgendwann später) auch eine App (oder ein WEB-UI?), mit der man den kontrollieren konnte. Das war für mich und meine damaligen Anforderungen super: Datenbankbasierte Musikauswahl, replay gain, crossfade, wenn keine Albumwiedergabe, tolerant gegen alle möglichen und unmöglichen Audio-Formate, clevere "auto-playlisten" Funktionen (? oder gab's die erst in 2.0)...
Irgendwann gab es dann jedenfalls 2.0 und einen Stall von bis dato nicht gekannten Problemen. MPD hat die meisten gelöst, im Moment vermisse ich eigentlich nur das "clevere cossfade" und diese "auto-playlisten"-Funktion (das war irgendein script von der Uni Zürich, wenn ich das richtig im Kopf habe). Und auch die Auswahl via App (es gibt einige schlechte, für mich hat sich MALP am besten bewährt) ist damit halbwegs erträglich, damit ist nur das Verschieben von Titeln innerhalb der Playlist ein wunder Punkt (aber für sowas kann man dann Cantata+Bildschirm hernehmen).
Worauf ich nicht verzichten wollte, ist replay gain (also die automatisierte Lautstärkeanpassung abhängig von einem als Tag (!) gespeicherten relativen Lautstärkewert eines Titels (bzw. Albums)).
Letzteres ist mAn. der Schwachpunkt bei DLNA-basierten Lösungen, wobei ich da nur "die App" meines Yamaha-Receivers vor Augen habe, die auch von der Bedienung her eher "schwach" ist (Musikauswahl macht damit sowas von keinen Spaß, aber vielleicht habe ich auch nur den richtigen Haken noch nicht gefunden...).

Von daher mag MPD als Dienst verbesserungsfähig sein, aber bevor mir nicht jemand bessere Alternativen aufzeigt (die Frage stand im Raum!), ist der für mich erst mal "gesetzt".


Back to RHASSPY:
Prinzipiell ist das Modul derzeit/jetzt so aufgebohrt, dass es erkennt, ob ein Gerät bestimmte Befehle kann, TYPE=MPD bekommt eine Sonder-/Vorzugsbehandlung, nachdem die Optionen 'cmdAddSelected' und 'cmdPlaySelected' intern umgesetzt sind. An der Stelle der Hinweis: um die max.-Anzahl zu ermitteln, wird eine direkte Rückmeldung vom MPD-Dienst ausgewertet; ein fork wäre dafür vermutlich ein Problem.
Es sollte aber möglich sein, z.B. via rhasspySpecials auch beliebige andere Geräte entsprechend zu erweitern (aber dann wohl via Perl-Code). Oder jemand bastelt aus den vorhandenen Bausteinchen was für mpg123... (EDIT: gemeint war: ein Modul).
(Wobei erfahrungsgemäß das Thema sound-Ausgabe aus Linux-Kisten für spaßfreie Abende gut ist...).


Zum MPD-FHEM-Modul:
Es mag sein, dass manches nicht optimal gelöst ist, und den default für den Verbindungsabbruch (2 Sekunden; EDIT: das kann man verkürzen auf 1 Sek., was ggf. immer noch (zu) viel ist) halte ich auch für eher hoch. Tendenziell sehe ich das forken des FHEM-Prozesses eher kritisch (neben dem Problem, dass RHASSPY auf die "count"-Anfrage eine unmittelbare Rückmeldung braucht ist auch der dauerhafte Speicherverbrauch ein Thema!) und würde als Lösung eher eine konfigurierbare Zeit und eine Art "non-blocking ping" sehen, um den Verbindungsstatus regelmäßig zu checken, bevor die eigentliche "while"-Aktion jeweils losläuft.
Kenne mich mit sowas aber vermutlich auch zuwenig aus (beide Server laufen hier 24/7).
EDIT: zur Klarstellung - das RHASSPY-Modul aus dem svn braucht bisher keine Anpassungen im MPD-Modul, allerdings sollte man uU. verbose auf 2 setzen, weil die "mpdCMD"-Anweisungen alle auf verbose-3-Level im Log landen...

[Prof. Dr. Peter Henning]

Ausgangspunkt ist zum einen, dass eine Sprachsteuerung in der Lage sein sollte, eine Anzahl Basiskommandos umzusetzen

Missversteh mich nicht, da bin ich ja voll auf Deiner Seite. Ich störe mich eher am ungenauen Sprachgebrauch, z.B. "etwas" oder "ein paar songs" etc.

LG

pah

[Beta-User]

Ich störe mich eher am ungenauen Sprachgebrauch, z.B. "etwas" oder "ein paar songs" etc.

OK, das ist jetzt was ganz anderes...

Prinzipiell bin ich bei dir, dass man im Umgang mit Ungenauigkeiten eine gewisse Vorsicht walten lassen sollte und ggf. dann eigentlich lieber rückfragen sollte, wenn da ein "zu großer" Interpretationsspielraum bleibt.

Was "etwas" oder "ein paar" sein soll, kann der "Administrator" (oder vielleicht besser: Konfigurator) bestimmen, und es geht selbstredend auch direkt numerisch mit "spiele 5/10/20 Songs". Mir liegen diese eher umgangs- oder allgemeinsprachlichen Quantifizierungen näher als entweder Zahlenarrays auswerten zu lassen, (damit (1..100) funktioniert, was aber zunehmend schmerzhafterweise Trainingszeit kostet) oder mir beim späteren Sprechen zu überlegen, welche einzelnen konkreten Zahlenwerte ich denn jetzt jeweils vorgesehen hatte.

Die Alternative wäre, in Richtung von strukturierten Dialogen zu gehen, was aber bei "ein paar Songs" mAn. künstlich & aufgesetzt wirkt, und v.a. weitere Fragen aufwerfen würde, die vielleicht beherrschbar wären, wenn wir "on the fly" slots ändern bzw. "Sätze" aktivieren/deaktivieren könnten. In der momentanen Situation würde ich aber nicht Richtung voice2json votieren wollen...

[JensS]

MPD sendet jeweils zwei Antworten. Wenn die erste kommt, geht's in der Schleife. Fehlt die 2. Antwort, wirkt der Socket-Timeout nicht. Die ganze Prozedur müsste überwacht und ggf. abgebrochen werden. Der blockierende Aufruf ist eh ungünstig für FHEM.

[Beta-User]

MPD sendet jeweils zwei Antworten. Wenn die erste kommt, geht's in der Schleife. Fehlt die 2. Antwort, wirkt der Socket-Timeout nicht. Die ganze Prozedur müsste überwacht und ggf. abgebrochen werden. Der blockierende Aufruf ist eh ungünstig für FHEM.

Für manche Aktionen muss* es m.E. blockierend sein - hier z.B. die "count"-Anfrage. Bei sowas dürfte es auch kaum zu Problemen kommen. (*: Muss ist vielleicht sehr hart, aber die Alternative, das nonblocking auszulegen, erscheint mir extrem aufwändig).

Letztlich ist diese Diskussion aber hier fehl am Platze - ich nehme an, Wzut ist gerne bereit, konkrete Vorschläge ins Modul zu übernehmen und hat ggf. auch mehr Erfahrungen damit wann/wie es zu Problemen kommt. Den Teil sollten wir dann auch dort thematisieren.

Hier könenn wir aber gerne darüber diskutieren, was ggf. Alternativen wären und wie man die dann einbindet .

[JensS]

So, ein Lösungsvorschlag ist raus. https://forum.fhem.de/index.php/topic,18517.msg1225316.html#msg1225316

Gruß Jens

[JensS]

Wie bekomme ich aktuell die playlists und music in die slots?