Modulentwicklung für Rhasspy Sprachassistent

[Beta-User]

Anbei zumindest mal das etwas überarbeitete Schaubild als jpeg und im Ausgangsformat.

[JensS]

Wie gesagt - hübsch bunt. 
Die Abbildung zeigt nur geringe Teile des tatsächlichen Prozessablaufs und ist notdürftig skizziert.
Z.B ist das Dialogmanagement ist ein extra Layer. Dieser erhält Daten vom STT und spricht seine Module (ASR, NLU, etc.) über MQTT an, sowie übergibt den erkannten Intent per MQTT an RHASSPY, welches sich dann um die Fortsetzung der Session kümmert.

Gruß Jens

[Beta-User]

Na ja, alle Verästelungen zu zeigen wäre vermutlich der absolute "Overkill"... Geht ja "nur" darum, erst mal sowas wie eine Idee zu vermitteln, was alles möglich ist.

Vermutlich bastle ich dann noch eine abgespeckte Version, in der dann "RHASSPY pur" dargestellt ist (also ohne Babble, AMAD.* und msgConfig+). Dann sieht man als Einsteiger eher, was man eigentlich (nur) braucht.

[Beta-User]

Gestern habe ich die SVN eingespielt und die multicommand-Anweisungen funktionieren gut.
Gibt es die Möglichkeit, vorhandene confirm-Abfragen in den rhasspySpecials der einzelnen Devices zwingend aufzurufen?

Habe eben ein update ins svn eingespielt, das neben dem geänderten output-Format (es gab keine Klagen...) auch eine Reparatur für die confirm-Prüfung bei den multi-Commands enthält. Bitte um Rückmeldung, wenn ich doch noch was übersehen haben sollte ...

[Prof. Dr. Peter Henning]

Die Abbildung zeigt nur geringe Teile des tatsächlichen Prozessablaufs und ist notdürftig skizziert.

Das ist nicht richtig. Der innere Ablauf von Rhasspy ist für die Ankopplung an FHEM derzeit irrelevant.

Die Kunst der wissenschaftlichen Abbildung besteht darin, solche irrelevanten Dinge herauszulassen.

LG

pah

[JensS]

Das ist nicht richtig. Der innere Ablauf von Rhasspy ist für die Ankopplung an FHEM derzeit irrelevant.

Die Kunst der wissenschaftlichen Abbildung besteht darin, solche irrelevanten Dinge herauszulassen.

LG

pah

Mag sein, dann sollte die Darstellung aber keine "alternativen" Wahrheiten beinhalten.
Entweder, man lässt alle Rhasspymodule weg oder man stellt das Dialogmanagement als Zwischenlayer dar. Eine gleichwertige Einordnung zu den Untermodulen ist faktisch falsch.

Gruß Jens

[Prof. Dr. Peter Henning]

Da bin ich anderer Ansicht und würde das in einer Publikation (egal ob Buch oder wissenschaftliches Paper) genau so darstellen, wie es hier der Fall ist. Es geht eben _nicht_ um die genaue Darstellung der inneren Abläufe von Rhasspy.

LG

pah

[JensS]

Genau das macht es für Suchende besonders schwierig, weil die Darstellung irreführend ist und mit dem Prozessablauf überhaupt nichts zu tun hat.
Wenn es nun so sein soll, dann gehören zumindestens die inneren Pfeile weg...

[Beta-User]

Na ja, der (gedankliche) Fokus dieser (und wohl auch der originalen) Darstellung lag und liegt auch weniger auf den Feinheiten der inneren Abläufe auf der Rhasspy-Seite, sondern eher auf dem, was man in FHEM braucht bzw. aus FHEM heraus machen kann.
Dabei muss ich zugeben, dass ich die Pfeilchen in/bei Rhasspy zum Teil auch nicht unbedingt notwendig oder intuitiv fand. Mal sehen...

Bisher war das mit der Grafik auch eher als Abgleich zu dem gemeint, was pah gemacht hatte. Von daher würde mich in Schritt 1 daher eigentlich mehr interessieren, ob alles soweit auch im Kontext der "großen Landschaft" funktioniert, die pah aufgezeicht hatte. Ich habe zwar manches getestet, aber eben z.B. nicht, wie das mit der Soundausgabe auf unterschiedlichen Geräten klappt (z.B. dem TV auf der Grafik). (Btw.: Weiß jemand zufällig, wie man (für automagic) einen shortcut für "activateVoiceInput" @ Android mit einem Icon versieht? Bei mir ist das einfach "durchsichtig"...).

Die Schwierigkeit in der Darstellung ist ansonsten eigentlich immer, dass Rhasspy halt eine Sammlung von Tools ist, die man ganz nach Belieben zusammensetzen und aktivieren kann - oder eben auch nicht. Ähnlich ist es bei Teilfunktionalitäten von RHASSPY: man kann einiges machen, wenn man das will, aber man muss nicht....

[drhirn]

sondern eher auf dem, was man in FHEM braucht bzw. aus FHEM heraus machen kann.

Zwischen "brauchen" und "kann" ist im Falle RHASSPY aber ein riesen Unterschied
Wenn ich mir als Anfänger die Grafik ansehen würde, würde ich gleich zum nächsten Produkt weiter ziehen. Ist eher eine Grafik für die, die Rhasspy/RHASSPY schon am Laufen haben und es erweitern möchten.
Der Anfänger braucht Base und Modul. Mehr nicht. MQTT ist per Default eh in der Base integriert, Audio - Ein- und Ausgabe kann eine Base grundsätzlich auch.
Was in Rhasspy genau abgeht, muss ihn auch nicht interessieren.

Also eigentlich bräuchte man da drei Grafiken. Anfänger, Fortgeschrittene, Experte

Und irgendwo müsste noch eine Audio-Ausgabe über Rhasspy hin (also Standardverhalten). Die fehlt da.

[Beta-User]

Zwischen "brauchen" und "kann" ist im Falle RHASSPY aber ein riesen Unterschied

Wenn ich mir als Anfänger die Grafik ansehen würde, würde ich gleich zum nächsten Produkt weiter ziehen. Ist eher eine Grafik für die, die Rhasspy/RHASSPY schon am Laufen haben und es erweitern möchten.
Der Anfänger braucht Base und Modul. Mehr nicht. MQTT ist per Default eh in der Base integriert, Audio - Ein- und Ausgabe kann eine Base grundsätzlich auch.
Was in Rhasspy genau abgeht, muss ihn auch nicht interessieren.

Also eigentlich bräuchte man da drei Grafiken. Anfänger, Fortgeschrittene, Experte

Und irgendwo müsste noch eine Audio-Ausgabe über Rhasspy hin (also Standardverhalten). Die fehlt da.

Na ja, "nur drei"...?!? Eigentlich bräuchte man ggf. für jeden in RHASSPY enthaltenen Teilbereich "erweiterter Funktionalität" nämlich eine separate Grafik...?

Für die Basis sollte ein Anfänger eigentlich diese hier kennen, muss mal schauen, ob es dazu auch irgendwo den Quelltext gibt:
https://rhasspy.readthedocs.io/en/latest/#services

Und man braucht für die "base" eigentlich auch keine Audio-Hardware, wer FHEM und einen Androiden hat, kann das eigentlich am näherungsweise komfortabelsten via AMAD lösen (*duck und weg*).

[drhirn]

Und man braucht für die "base" eigentlich auch keine Audio-Hardware, wer FHEM und einen Androiden hat, kann das eigentlich am näherungsweise komfortabelsten via AMAD lösen (*duck und weg*).

Mal überlegen...
Die Mehrheit experimentiert mit Rhasspy am Anfang mit einem Raspberry Pi als Base. Auch wenn du den nicht magst. Lautsprecher und Mikro anhängen und in der Konfiguration der Base zwei Hackerl setzen.
oder...
Zusätzlich zu dem Pi als Base noch AMAD auf FHEM und Android konfigurieren müssen, was jetzt auch nicht so einsteigerfreundlich ist.

Meine Entscheidung wäre klar

Für die Basis sollte ein Anfänger eigentlich diese hier kennen

Ja, seh ich auch so.

[Beta-User]

Die Mehrheit

Aha... (Überstimmt ).

Vielleicht für diese Mehrheit wie in der Anlage...?

[drhirn]

Nein. Die Mehrheit wie im Rhasspy-Forum ersichtlich.
Ich formulier's um: Wenn man das Rhasspy-Forum durchliest, verwenden die meisten User eine Pi.

Ja. Anhang macht Sinn. Für blutige Anfänger.

[Prof. Dr. Peter Henning]

Wenn ich mir als Anfänger die Grafik ansehen würde, würde ich gleich zum nächsten Produkt weiter ziehen

Ui, welch eine Drohung 

Meine FHEM-Bücher haben sich eigentlich ganz gut verkauft, insofern sehe ich das ganz selbstgefällig locker. Mein neuestes Buch dümpelt noch so vor sich hin, hat aber auch nichts mit Informatik zu tun.

Und die Korrelation "Anfänger" und "Blut" hatte ich auch schon manchmal im Sinn.

LG

pah