SEPIA open-source Sprachassistent: Integration in FHEM?

[TRallala]

einen Pi Neustart mache, dann sehe ich wieder die alten Daten: Das Symbol ist nicht auf grün, sondern grau, der Client ist nicht auf "localhost" sondern auf "raspberryhost", etc. Läuft da etwas schief?

Das ist bei mir genauso. Allerdings würde ich es höchstens als Schönheitsfehler einstufen. Im Normalfall muss man da ja nicht jedesmal/oft dran.

Nach dem Neustart verbindest du dich über "/tools/#!client-connections" wieder mit dem CLEXI server, wie ist denn dann der Status deines (lokalen) Clients?
Bei mir lag es vermutlich an Ungeduld: Es ist wichtig, dass die Neustarts exakt eingehalten werden, sonst hat der client (wie in der Anleitung beschrieben) kein Zugriff auf das Mic.

Damit bin ich nun aber an an einem ähnlichen Punkt:

PI Pseudo-Headless funktionierte ganz gut.
Heute wieder angeschmissen, mit folgendem Status/Ergebnis:

1. active user: setup  - unschön, aber okay:
2. call login -> success -> reboot
3. active user: uid1007 - soweit so gut; jetzt kommter aber nicht mehr ans mic:

Code Auswählen Erweitern

Broadcaster event: {"broadcast":{"client":"o1_chrome_app_v0.22.0","deviceId":"o1","sepia-speech":{"type":"asr_error","msg":"Mikrofon nicht richtig erkannt oder Zugriff  verweigert."}}}

4. also noch ein reboot:  active user: setup 
5. call login -> success -> call test -> success -> set wakeword active -> success -> reboot
6. active user: setup   

rekursion, siehe rekursion..

gute Idee(n)?

[sepia]

Hi,
da ich jemand bin, der eine Schritt für Schritt Anleitung benötigt, habe ich für mich etwas zusammengeschrieben. Ich habe es mal angehängt.

Sehr gut! Ich würde das noch mal in ruhe durchgehen und dann irgendwo in den SEPIA Docs als PDF ablegen, wenn das ok ist?
Es gab jetzt schon 2-3 solcher User-Tutorials auf Deutsch. Werde mal überlegen wo ich die zentral sammeln könnte.

Ich höre beim Start ein paar Sachen, z.B. "ready for setup", aber wenn ich sage, "hey Sepia, schalte Wohnzimmerlicht an" funktioniert es leider nicht.
Das Mikrofon an sich funktioniert --> "arecord -l" --> "arecord -D plughw:1,0 -d 3 test.wav && aplay test.wav" funktioniert. Ich kann meine Stimme aufnehmen und mit dem Befehl höre ich meine aufgenommene Stimme.
Zum Microfon: Ich habe ein Amazon-Microfon.

Kannst du im CLEXI Remote Terminal (Control HUB -> Client Connections) irgendwelche Fehlermeldungen sehen? Der Client ist zu diesem Zeitpunkt schon eingeloggt ja?
P.S.: Ich habe ein Amazon Basics USB Kondensatormikrofon, das funktioniert sehr gut.

Was mich bisher stutzig macht: Wenn ich beim Control Hub die Client Daten eingebe und einen Pi Neustart mache, dann sehe ich wieder die alten Daten: Das Symbol ist nicht auf grün, sondern grau, der Client ist nicht auf "localhost" sondern auf "raspberryhost", etc. Läuft da etwas schief?

s.U.

Bei mir lag es vermutlich an Ungeduld: Es ist wichtig, dass die Neustarts exakt eingehalten werden, sonst hat der client (wie in der Anleitung beschrieben) kein Zugriff auf das Mic.

Ja, da muss man genau aufpassen, denn beim ersten Start wird das User Verzeichnis im Chromium angelegt und erst beim bzw. vor dem zweiten Start können diese dann überschrieben werden.

Damit bin ich nun aber an an einem ähnlichen Punkt:

PI Pseudo-Headless funktionierte ganz gut.
Heute wieder angeschmissen, mit folgendem Status/Ergebnis:

1. active user: setup  - unschön, aber okay:
2. call login -> success -> reboot
3. active user: uid1007 - soweit so gut; jetzt kommter aber nicht mehr ans mic:
[...]
gute Idee(n)?

Ich fasse noch mal kurz zusammen: Ihr habt beide das Problem, dass der Client nach einem Neustart den Login verliert?
Ich werde mal überlegen woran das liegen könnte. Im Grunde würde das bedeuten der Chromium Userfolder wird zurückgesetzt

[whistler]

Ich fasse noch mal kurz zusammen: Ihr habt beide das Problem, dass der Client nach einem Neustart den Login verliert?
Ich werde mal überlegen woran das liegen könnte. Im Grunde würde das bedeuten der Chromium Userfolder wird zurückgesetzt

Ich melde mich auch mal kurz, ja zudem das die Wakeword Erkennung "verschwindet", kann ich heute bestätigen das Aufgrund eines Stromausfalls der Server nicht erreichbar war, aber auch die Clients die den Server noch erreichen konnten sind geflogen.

Sie standen alle im Demomodus und haben auf einen Login gewartet. Ich hatte das beim rumprobieren schon öfter, aber erstmal auf mein Setup geschoben,
aber muss sagen es ist nicht schön.

PS: Mit github hab ich noch nicht geschafft, aber da andere ebenfalls ja hier einen nutzen haben, sollten wir den rest vielleicht auch wie alles andere hier besprechen, ich überlege mal.

Btw, aktuell flippen wieder die Clients mit Wakeword ohne wakeword aus

Schönen Abend Gruß
Basti

[sepia]

Ich melde mich auch mal kurz, ja zudem das die Wakeword Erkennung "verschwindet", kann ich heute bestätigen das Aufgrund eines Stromausfalls der Server nicht erreichbar war, aber auch die Clients die den Server noch erreichen konnten sind geflogen.

Hm das könnte vielleicht der entscheidenden Hinweis sein. Wenn der Client neustartet und der Server noch nicht läuft hängt der Client im Login Modus und springt dann vermutlich nach 8s in den Auto-Setup Modus wobei der alte Login verloren geht
Ich habe schon eine Idee wie man das verbessern könnte. Bei der Handy App hat mich das auch ein paar mal gestört, wenn der Server down war. Da ist es nicht ganz so schlimm weil man die App einfach neustarten kann und die nicht in den Auto-Setup Modus springt, aber bessere wäre wohl wenn der Client einfach auf den Server oder einen Manuellen Logout Request wartet.
Übrigens wenn Server bei laufendem Client abschmiert versucht der Client sich mit immer größer werdenden Abständen automatisch wieder zu verbinden, das kann im Maximalfall aber hoch gehen bis auf 5min.

PS: Mit github hab ich noch nicht geschafft, aber da andere ebenfalls ja hier einen nutzen haben, sollten wir den rest vielleicht auch wie alles andere hier besprechen, ich überlege mal.

Ja, kein Problem. Nutzt du eigentlich Node-RED? ^^

Grüße,
Florian

[Jasdhewer]

Sehr gut! Ich würde das noch mal in ruhe durchgehen und dann irgendwo in den SEPIA Docs als PDF ablegen, wenn das ok ist?
Es gab jetzt schon 2-3 solcher User-Tutorials auf Deutsch. Werde mal überlegen wo ich die zentral sammeln könnte.

Kannst du im CLEXI Remote Terminal (Control HUB -> Client Connections) irgendwelche Fehlermeldungen sehen? Der Client ist zu diesem Zeitpunkt schon eingeloggt ja?
P.S.: Ich habe ein Amazon Basics USB Kondensatormikrofon, das funktioniert sehr gut.

s.U.

Ja, da muss man genau aufpassen, denn beim ersten Start wird das User Verzeichnis im Chromium angelegt und erst beim bzw. vor dem zweiten Start können diese dann überschrieben werden.

Ich fasse noch mal kurz zusammen: Ihr habt beide das Problem, dass der Client nach einem Neustart den Login verliert?
Ich werde mal überlegen woran das liegen könnte. Im Grunde würde das bedeuten der Chromium Userfolder wird zurückgesetzt

Hi,
du darfst gerne die word Datein benutzen und zur Verfügung stellen. GGf. findest du ja noch Fehler, die mein Problem verursachen. Fehler mein Clienten werden erst einmal nicht angezeigt.
Ich werde am Wochenende mich noch mal hinsetzen und den Clienten noch mal versuchen einzurichten. Sonst gibt es ja bisher keine Lösung für mein Problem?!

[whistler]

Hallo Florian,

ich versuch mal gesammelt einmal deine offenen und Antworten zu durchlaufen (Vollständig nicht unbedingt gegeben ).
Ich hänge an zwei drei stellen, daher brauchte Sepia eine Pause (oder ich ).

Hm das könnte vielleicht der entscheidenden Hinweis sein. Wenn der Client neustartet und der Server noch nicht läuft hängt der Client im Login Modus und springt dann vermutlich nach 8s in den Auto-Setup Modus wobei der alte Login verloren geht
Ich habe schon eine Idee wie man das verbessern könnte. Bei der Handy App hat mich das auch ein paar mal gestört, wenn der Server down war. Da ist es nicht ganz so schlimm weil man die App einfach neustarten kann und die nicht in den Auto-Setup Modus springt, aber bessere wäre wohl wenn der Client einfach auf den Server oder einen Manuellen Logout Request wartet.
Übrigens wenn Server bei laufendem Client abschmiert versucht der Client sich mit immer größer werdenden Abständen automatisch wieder zu verbinden, das kann im Maximalfall aber hoch gehen bis auf 5min.

Grüße,
Florian

Gerne immer, wenns beim Fehlersuchen/finden hilft.
Wenn ich das hier richtig sehe, dann broadcastet er natürlich auch nicht mehr dann
Sowas wie ein heartbeat wäre nice (z.b. alle 60 Sekunden, ob der Client noch da ist.

Ja, kein Problem. Nutzt du eigentlich Node-RED? ^^

Nein bisher kein Note-Red, aber sieht immer interessant aus.

Ich könnte ja bei dem Event ein Feld "previousState" o.Ä. einfügen ... dann muss ich den nur selber erstmal tracken ... sollte aber nicht so schwer sein

Ich hab dir zum tracken mal ein "Log" anlegt, ich hab das tracken quasi fhem überlassen (MQTT Device dahinter ein log, json wird ja per 98_jsonExpansion extrahiert)
Dann siehst du vielleicht besser was ich mit Status meine und hast ein gefühl dafür wie es am besten zu integrieren ist.

Für die Node-RED Fans ein kleiner Teaser im Anhang ^^

Nur fürs Verständnis, kann das parallel zu fhem laufen dann? oder als entweder oder? Ich nehme an du sprichst dort MQTT in Richtung Node-Red
Du kennst meine Vorstellung ja, per Interface (z.B. fhem) alles machen lassen und parallel per MQTT broadcasten


So jetzt zu den aktuellen Problemen / Infos nochmal in Kurzform und ich hoffe wir sind dann wieder auf dem gleichen Stand der vom Standard abweichenden Standards:
* Im Log erkennst du ja das ich noch nicht vor einer Stunde getestet habe, und nun ist das Wakeword schon wieder ausgegangen (knapp 45 Minuten nach Letzter Interaktion).
  Im Log siehst du auch gesprochenendes, das dann zu unvollständigen sätzen wird, meistens kann man erkennen, was ich eigentlich hätte sagen wollten (z.b. link anstatt links)
* Ich hab mir jetzt mal noch nen TTS Ausgabe gemacht die mit mir spricht, wenn das Wakeword ausschaltet (als Telegram Message geht das schonmal unter )
  Dieser hat nach 45 Minuten nach letzter Interaktion ausgelöst
  Wenn ich nun ein Reload mache, ist es wieder an. Zu sehen ist aber am Client nichts.

* Kann ich das "Reload" am Clexi auch remote machen? Gedanke: Ich löse vom fhem aus den reload aus (per api aufruf), hast du hier ein Beispiel. Ich bin auf die schnelle nicht fündig geworden.

* Ich hab ja die besondere Konstellation das ich einen Squeezeplayer laufen lassen und auch den Sepia Client, hab sogar den Client um eine weitere USB Karte erweitert, zu Verbesserung
  Ich hab nach wie vor noch nicht 100% verstanden, wo Sepia sich das "Ausgabe Device" zieht und wie ich das anpassen kann (Vielleicht hast du da noch einen Tipp)
  PS: Das Wakeword spinnt sowohl wenn der Squeezeplayer aus, und er spinnt auch, wenn ich "Hey Sepia" einstelle etwas weniger aber trotzdem.
* es gibt noch was, was vielleicht etwas verwirrt, wenn auch Gedanklich vielleicht nicht falsch, das wakeword geht auch inactive, wenn das mic angeht. das geht auch auf inactive, wenn es inactive wird. (es gibt auch keine Unterscheid zwischen "bewusst" oder "unbewusst" aus.
  Aktuell hab ich nen Timer von 2 Minuten laufen, sofern das active nicht kommt, was den Timer löscht. (Nicht schön, aber naja )

* Zum Thema Heartbeat (Kann man vielleicht diesen Status aus der Übersicht am Client abgreifen, hier werden ja die aktiven Clients angezeigt.

* Dann zum Schluss, noch einmal kurz zur Handy App, weil du es kürzlich als Randthema angesprochen hast. Kurz nochmal zusammengefasst das "Problem".
* Sepia Client ist gestartet und auch als Default (Anstatt Google definiert)
Da ich mein Handy nicht gerootet habe, kann Tasker die App nicht beenden. Vielleicht kannst du ihr noch ein intent spendieren, wo Tasker (oder auch weitere) das dann doch dürfen.
Bin nicht 100% sicher, ob das Gedanklich so richtig gedacht ist.

Also Sepia ist auf, Ich steige ins Auto ein, Tasker startet Spotify beim Bluetooth connect.
Wenn Sepia wird gestartet ist passiert folgendes: Er stellt sepia als Anruf da, macht er eigentlich die ganze Zeit und es gibt keinen Ton am Radio sondern direkt am Handy,
wenn ich die App beende, hab ich direkt den Ton im Radio. (Alternativ stellt er den Stream als Anruf da, was erstens leider ist, und kein Steuern (Skip etc. zulässt)
Beides nicht schön. zudem Übersteuert er scheinbar (zumindest bei Xiaomi) die Volumetasten, und er macht das Mic lauter leiser und nicht mehr Lautstärke.
Es gibt scheinbar verschiedene Möglichkeiten einen Audio zu starten, als stream als call. (Hatte ich beim Tasker mal gesehen, was man einstellen kann wie er "Vorlesen" soll.)

Das Ergänzung zum Wunsch des Custom Pling Tons, da hab ich überlegt. vielleicht kannst du im Code einbauen, wenn an einer bestimmten stelle im Handyspeicher eine custom_coin.mp3 liegt lädt er die beim starten.
Ob die gleiche Logik auch beim Wakeword geht vermutlich nicht so einfach.

Die PS3 Eye hab ich bisher zwar zum sprechen ans Laufen bekommen, aber das wakeword macht es nicht so. Heisst wenn ich das knöpfchen drücke, dann kann ich dann ohne Probleme sprechen.

Kann man irgendwie den wakeword erkennungsstream "mitschneiden" damit man mal hören kann, was er da so "hört".

[EDIT]
Das Performance Schaltproblem ist immer noch da, kannst du evtl. auch im Log sehen, im Server keine auffälligkeiten (dauert bis zu 7 Sekunden ()


Hallo zusammen,

wie es denn eure Erfahrung bzgl. Wakeword Erkennung läuft die Eindwandfrei, wahlweise mit Hey Sepia oder den Custom words?

Vielen Dank und einen schönen Sonntag.
Gruß
Basti

[sepia]

Hi,
du darfst gerne die word Datein benutzen und zur Verfügung stellen. GGf. findest du ja noch Fehler, die mein Problem verursachen. Fehler mein Clienten werden erst einmal nicht angezeigt.
Ich werde am Wochenende mich noch mal hinsetzen und den Clienten noch mal versuchen einzurichten. Sonst gibt es ja bisher keine Lösung für mein Problem?!

Hi,
hattest du noch was erreicht oder besteht das Problem mit dem Mikrofon weiterhin?
Ich hatte mal etwas Zeit um deine Anleitung Schritt für Schritt durchzugehen, dabei sind mir ein paar Sachen aufgefallen:

   
• Root Rechte sollten eigentlich nicht explizit vergeben werden müssen für den "Pi" User. Befehle, die nur als root klappen stehen immer mit "sudo ..." in den Skripten. "Zu viel" root führt eher zu Probleme später.
• In Teil 1 wird Let's Encrypt konfiguriert UND Ngrok benutzt. Mit erfolgreicher Einrichtung von Let's Encrypt sollte Ngrok eigentlich nicht mehr nötig sein. Generell würde ich empfehlen erstmal alles komplett ohne SSL/HTTPS zu machen, so lange man noch beim Einrichten ist. Die Android App und der DIY Client haben keine Probleme ohne HTTPS (da sie im eigenen "secure context" laufen). Erst wenn du über einen beliebigen Browser auf einem anderen System auf den SEPIA Server zugreifen willst gibt es Probleme.
• Beim Zuweisen der Rolle "smarthomeguest" sollte die Rolle "user" erhalten bleiben. Das ist aber nicht schlimm, glaube ich
• Bei Teil 3 zur Client Installation ist auffällig, dass es wohl Probleme mit "ws://[rpi-IP]:9090/clexi" gibt. Selbst wenn du auf dem selben Rechner bist müsste diese Adresse gehen falls der Nginx im Schritt davor richtig installiert wurde

Noch mal kurz zum Verständnis, bei dir laufen SEPIA Server und Raspberry Pi Client auf dem selben RPi4 richtig?

Ich hänge an zwei drei stellen, daher brauchte Sepia eine Pause (oder ich ).

Hi Basti, verstehe ich. Ich komme auch gerade nicht immer sofort dazu, detailliert auf Fragen einzugehen. Dafür bin ich aber dran die einzelnen Problemchen Schritt für Schritt abzuarbeiten und neue Features einzubauen

Sowas wie ein heartbeat wäre nice (z.b. alle 60 Sekunden, ob der Client noch da ist.

Ja, das steht auch schon auf der Liste (sowohl für die Client -> CLEXI Verbindung als auch Client -> SEPIA Chat Server). Mit Node-RED kann man sowas auch gut machen, sobald ich die Client Node fertig habe ^^.

Ich hab dir zum tracken mal ein "Log" anlegt, ich hab das tracken quasi fhem überlassen (MQTT Device dahinter ein log, json wird ja per 98_jsonExpansion extrahiert)
Dann siehst du vielleicht besser was ich mit Status meine und hast ein gefühl dafür wie es am besten zu integrieren ist.

Cool, danke.

Nur fürs Verständnis, kann das parallel zu fhem laufen dann? oder als entweder oder? Ich nehme an du sprichst dort MQTT in Richtung Node-Red
Du kennst meine Vorstellung ja, per Interface (z.B. fhem) alles machen lassen und parallel per MQTT broadcasten

Das läuft komplett unabhängig. Die Nodes für SEPIA haben verschiedene Funktionen, eine davon ist z.B. die Verbindung zum Client über den CLEXI Server. Sprich es wird dann möglich sein die ganzen Events des CLEXI Servers in Node-RED auszulesen und weiter zu verarbeiten. Andere Nodes greifen z.B. direkt auf die SEPIA Server Endpoints zu, können Befehle ausführen ("Stelle den Wecker für 7 Uhr"), Nachrichten in SEPIA Chat Kanäle schicken oder Remote-Actions ausführen. Ich glaube das wird ziemlich cool weil man weniger im SEPIA Code rumfummeln muss um selber Ideen umzusetzen

So jetzt zu den aktuellen Problemen / Infos nochmal in Kurzform und ich hoffe wir sind dann wieder auf dem gleichen Stand der vom Standard abweichenden Standards:
* [...] Dieser hat nach 45 Minuten nach letzter Interaktion ausgelöst
  Wenn ich nun ein Reload mache, ist es wieder an. Zu sehen ist aber am Client nichts.

Da gab es scheinbar wieder dieses Problem, dass kein Text erkannt wurde und deshalb irgendwie der Restart des Wake-Word Listeners nicht klappt. Ich versuche gleich noch mal das zu reproduzieren, scheint aber nicht trivial zu sein irgendwie :-/

* Kann ich das "Reload" am Clexi auch remote machen? Gedanke: Ich löse vom fhem aus den reload aus (per api aufruf), hast du hier ein Beispiel. Ich bin auf die schnelle nicht fündig geworden.

Theoretisch ja, praktisch braucht man aber irgendeine Form des CLEXI Clients um die WebSocket Verbindug herzustellen und dann den Trigger Befehl über den Broadcast-Kanal zu schicken. Das ist auch ein schönes Beispiel für die zukünftigen Node-RED Möglichkeiten (weil man da die Endpoints schön per Drag-n-Drop verbinden und bedienen kann via CLEXI Node).

* Ich hab ja die besondere Konstellation das ich einen Squeezeplayer laufen lassen und auch den Sepia Client, hab sogar den Client um eine weitere USB Karte erweitert, zu Verbesserung
  Ich hab nach wie vor noch nicht 100% verstanden, wo Sepia sich das "Ausgabe Device" zieht und wie ich das anpassen kann (Vielleicht hast du da noch einen Tipp)
  PS: Das Wakeword spinnt sowohl wenn der Squeezeplayer aus, und er spinnt auch, wenn ich "Hey Sepia" einstelle etwas weniger aber trotzdem.

Mit "Ausgabe Device" meinst du quasi den Lautsprecher des Clients? Was genau ist hier noch mal die Aufgabe des Squeezeplayer, die Ausgabe auf ein anderes Gerät zu streamen? Oder generell Musik abzuspielen, die dann auf das Gerät gestreamt wird?
Das Ausgabegerät von SEPIA ist über die ALSA Einstellungen "konfiguriert". Im Besten Fall ist es einfach die Standardeinstellung des Systems oder was in der '~/.asoundrc' steht.

* Zum Thema Heartbeat (Kann man vielleicht diesen Status aus der Übersicht am Client abgreifen, hier werden ja die aktiven Clients angezeigt.

Im Grunde wäre der zentrale Anlaufpunkt der SEPIA Chat Server. Der weiß welche User und DeviceIds online sind. Abfragen kann man die aber noch nicht, da wäre ein Endpoint durchaus sinnvoll
Ansonsten müsste man sich mit jedem CLEXI Server des jeweiligen Clients verbinden und den "ping" request senden (wieder ein möglicher Anwendungsfall für Node-RED ^^).

* Dann zum Schluss, noch einmal kurz zur Handy App, weil du es kürzlich als Randthema angesprochen hast. Kurz nochmal zusammengefasst das "Problem".
* Sepia Client ist gestartet und auch als Default (Anstatt Google definiert)
Da ich mein Handy nicht gerootet habe, kann Tasker die App nicht beenden. Vielleicht kannst du ihr noch ein intent spendieren, wo Tasker (oder auch weitere) das dann doch dürfen.
Bin nicht 100% sicher, ob das Gedanklich so richtig gedacht ist.

Ich guck mal dass ich dem Client eine "App exit" Aktion spendiere Background reicht nicht? Das müsste doch gehen oder? Die App macht eh nichts im Hintergrund und bei einem hard-exit dauert der Neustart länger.

Also Sepia ist auf, Ich steige ins Auto ein, Tasker startet Spotify beim Bluetooth connect.
Wenn Sepia wird gestartet ist passiert folgendes: Er stellt sepia als Anruf da, macht er eigentlich die ganze Zeit und es gibt keinen Ton am Radio sondern direkt am Handy,
wenn ich die App beende, hab ich direkt den Ton im Radio. (Alternativ stellt er den Stream als Anruf da, was erstens leider ist, und kein Steuern (Skip etc. zulässt)
Beides nicht schön. zudem Übersteuert er scheinbar (zumindest bei Xiaomi) die Volumetasten, und er macht das Mic lauter leiser und nicht mehr Lautstärke.
Es gibt scheinbar verschiedene Möglichkeiten einen Audio zu starten, als stream als call. (Hatte ich beim Tasker mal gesehen, was man einstellen kann wie er "Vorlesen" soll.)

Uh das klingt echt nervig Irgendwo kam dieses Problem schon mal (hatten wir das diskutiert?). Kommt der "Anruf" Status durch das Wake-word oder auch ohne? Ich hatte schon mal versucht ob es möglich ist die Audio-Kanäle in Android konkret auszuwählen aber das ist ziemlich schwierig bis unmöglich (zur Zeit). Die Kombination Wake-Word + Audio Output ist auch deshalb standardmäßig deaktiviert. Wenn Audio aus einer anderen App kommt kann SEPIA das aber nicht verhindern vermute ich.

Das Ergänzung zum Wunsch des Custom Pling Tons, da hab ich überlegt. vielleicht kannst du im Code einbauen, wenn an einer bestimmten stelle im Handyspeicher eine custom_coin.mp3 liegt lädt er die beim starten.
Ob die gleiche Logik auch beim Wakeword geht vermutlich nicht so einfach.

Hmm ja theoretisch müsste das gehen. Jede App hat ja einen Ort in Android wo sie Dateien ablegen und auch lesen darf. Das wird etwas tricky aber klingt nach einer guten Idee
Bezüglich Wake-Word ... es gibt ein undokumentiertes Feature im Client ^^ guck mal hier: https://github.com/SEPIA-Framework/sepia-docs/issues/52

Die PS3 Eye hab ich bisher zwar zum sprechen ans Laufen bekommen, aber das wakeword macht es nicht so. Heisst wenn ich das knöpfchen drücke, dann kann ich dann ohne Probleme sprechen.
Kann man irgendwie den wakeword erkennungsstream "mitschneiden" damit man mal hören kann, was er da so "hört".

Mit der PS3 Eye wurde ich auch nicht glücklich damals, der Sound war immer viel zu leise wenn ich mich recht erinnere. Mitschneiden wäre wirklich praktisch, ist aber (Stand jetzt) ziemlich umständlich einzubauen :-/ dazu muss man irgendwie den Audio-Buffer abgreifen, duplizieren und dann wieder abspielbar machen

Das Performance Schaltproblem ist immer noch da, kannst du evtl. auch im Log sehen, im Server keine auffälligkeiten (dauert bis zu 7 Sekunden ()

Uff 7s ist hart. Kommt das eigentlich auch wenn du den trigger button im Control HUB benutzt? Wenn ich mich recht erinnere wurde das auch weniger wenn man mehrere Befehle in kurzem Abstand benutzt hat oder? Geht da vielleicht irgendein Empfänger in den sleep-mode?

Grüße,
Florian

[whistler]

Hi Basti, verstehe ich. Ich komme auch gerade nicht immer sofort dazu, detailliert auf Fragen einzugehen. Dafür bin ich aber dran die einzelnen Problemchen Schritt für Schritt abzuarbeiten und neue Features einzubauen

ich antworte zumindest mal kurz.

Ja, das steht auch schon auf der Liste (sowohl für die Client -> CLEXI Verbindung als auch Client -> SEPIA Chat Server). Mit Node-RED kann man sowas auch gut machen, sobald ich die Client Node fertig habe ^^.

Das läuft komplett unabhängig. Die Nodes für SEPIA haben verschiedene Funktionen, eine davon ist z.B. die Verbindung zum Client über den CLEXI Server. Sprich es wird dann möglich sein die ganzen Events des CLEXI Servers in Node-RED auszulesen und weiter zu verarbeiten. Andere Nodes greifen z.B. direkt auf die SEPIA Server Endpoints zu, können Befehle ausführen ("Stelle den Wecker für 7 Uhr"), Nachrichten in SEPIA Chat Kanäle schicken oder Remote-Actions ausführen. Ich glaube das wird ziemlich cool weil man weniger im SEPIA Code rumfummeln muss um selber Ideen umzusetzen

Okay das hört sich aber nicht nach MQTT in Richtung Node-Red an oder? sondern ein Node?
Mein gedanke war, ich schicke ein Kommanda "Reload" zum Client oder Server und lasse, wenn er ein event inactive schickt ihn einrach einen Reload machen.
Nicht schön, aber dann steht man zumindest nicht doof davor und fragt sich, will er mich gerade nicht verstehen, oder kann er mich nicht verstehen.

Da gab es scheinbar wieder dieses Problem, dass kein Text erkannt wurde und deshalb irgendwie der Restart des Wake-Word Listeners nicht klappt. Ich versuche gleich noch mal das zu reproduzieren, scheint aber nicht trivial zu sein irgendwie :-/

Also entweder du hast selber einen Geheimtrick, hast das Mikro so gut versteckt, das es den "Fernseher" etc. nicht findet. Aber du stimmst mir zu Musik hören oder Fernsehen sollte wohl drin sein.
Und ja es ist scheinbar so, das er das Wakeword erkannt hat (warum auch immer) und dann gehts los. Witzig (naja eigentlich nicht), wenn er "fehlauslöst" und der Fernseher läuft, dann "zeichnet" er erstmal Fleissig auf, Hatte mal ne ganze Tagesthemen Reportage dann als Text, (Ich glaub ich wiederhole mich gerade)

Und er löst wieder öfter aus, das hört erst auf, wie sollte es sein, wenn er sich verschluckt hat. und dann das wakeword aus ist. So auf den abendverteilt wenn alle clients frisch aktiviert sind, so 5-6 oder öfter male, für falsch Auslösung. und ja noch nichtmal unbedingt in dem Raum wo dann der Fernseher läuft.

Theoretisch ja, praktisch braucht man aber irgendeine Form des CLEXI Clients um die WebSocket Verbindug herzustellen und dann den Trigger Befehl über den Broadcast-Kanal zu schicken. Das ist auch ein schönes Beispiel für die zukünftigen Node-RED Möglichkeiten (weil man da die Endpoints schön per Drag-n-Drop verbinden und bedienen kann via CLEXI Node).

Das ist vermutlich genau das, was ich ja teilweise, wenn auch nicht so schön, per client und mqtt versucht habe, aber aufgehört habe, weil das ja mit updates nicht mehr wirklich pflegbar wäre.
Aber meine Lösung gefällt mir bisher ganz gut.

Mit "Ausgabe Device" meinst du quasi den Lautsprecher des Clients? Was genau ist hier noch mal die Aufgabe des Squeezeplayer, die Ausgabe auf ein anderes Gerät zu streamen? Oder generell Musik abzuspielen, die dann auf das Gerät gestreamt wird?
Das Ausgabegerät von SEPIA ist über die ALSA Einstellungen "konfiguriert". Im Besten Fall ist es einfach die Standardeinstellung des Systems oder was in der '~/.asoundrc' steht.

Der Logitech Media Server, ist quasi der Zentrale Dienst, der Squeezeplayer (Linux/Windows/Android/...) läuft dann jeweils als Player der den Multiroom Stream empfängt und dann an die lokale Soundkarte ausgibt. Ich nehme aber nicht direkt die Karte sondern das playback, bzw. ist dimex, also quasi das seeed voice sample. da hat er ja noch zwei Zwischenschritte.
Ich benötigte aber natürlich nur das play device, das record device nehme ich dort gar nicht. (Deswegen trage ich auch nicht das default ein). Damit sollten sie sich nicht in die quere kommen.
ich habs global unter /etc/asound.conf liegen, was aber im Endeffekt keinen Unterschied macht.

Im Grunde wäre der zentrale Anlaufpunkt der SEPIA Chat Server. Der weiß welche User und DeviceIds online sind. Abfragen kann man die aber noch nicht, da wäre ein Endpoint durchaus sinnvoll
Ansonsten müsste man sich mit jedem CLEXI Server des jeweiligen Clients verbinden und den "ping" request senden (wieder ein möglicher Anwendungsfall für Node-RED ^^).

Okay vielleicht im Node-Red einfacher. Vorteil wäre, so der Gedanke, das du du im Standard einbaust, muss sich nicht jeder am Ende einzelnd ausdenken. Und je weniger kann "daneben" gehen, wenn du mal was anpasst bei einem Update.

Ich guck mal dass ich dem Client eine "App exit" Aktion spendiere Background reicht nicht? Das müsste doch gehen oder? Die App macht eh nichts im Hintergrund und bei einem hard-exit dauert der Neustart länger.

Naja der Neustart ist vielleicht gar nicht schlecht. Denn, wenn ich aus dem Auto austeige, in der Tiefgarage bin keinen Empfang habe, gibts das nächste Problem
Und ja ein Hintergrund reicht wohl nicht, weil die App ist normal im Hintergrund offen, und nicht als Always on. mit Wakeword aus, müsse ich mal testen, aber das wäre ja vom Prinzip unpraktisch.
Vorschlag, damit jeder sich was passendes, bzw. Situationsabhängiges hat und wenn die Stelle im Code hast, vermutlich "wenig" Mehraufwand.
"App Exit" "App Background" dann bist du für alle eventualitäten gewappnet. Sobald die app offen ist macht sie "zicken".

Uh das klingt echt nervig Irgendwo kam dieses Problem schon mal (hatten wir das diskutiert?). Kommt der "Anruf" Status durch das Wake-word oder auch ohne? Ich hatte schon mal versucht ob es möglich ist die Audio-Kanäle in Android konkret auszuwählen aber das ist ziemlich schwierig bis unmöglich (zur Zeit). Die Kombination Wake-Word + Audio Output ist auch deshalb standardmäßig deaktiviert. Wenn Audio aus einer anderen App kommt kann SEPIA das aber nicht verhindern vermute ich.

ja am Anfang hatten wir das Diskutiert, ich hatte das aber zugunsten des DIY 2.5.0 Releases auf der Problemliste bei mir nach hinten geschoben, aber da der Fall in der letzten Zeit öfter vorkam, hab ich es wieder ausgegraben. Nach dem Release ist vor dem Release. Das mit und ohne müsste ich probieren. Mit den Kanälen hatte ich mal im Tasker gesehen, das man ihm das mitgeben kann.

Hmm ja theoretisch müsste das gehen. Jede App hat ja einen Ort in Android wo sie Dateien ablegen und auch lesen darf. Das wird etwas tricky aber klingt nach einer guten Idee
Bezüglich Wake-Word ... es gibt ein undokumentiertes Feature im Client ^^ guck mal hier: https://github.com/SEPIA-Framework/sepia-docs/issues/52

Mit der PS3 Eye wurde ich auch nicht glücklich damals, der Sound war immer viel zu leise wenn ich mich recht erinnere. Mitschneiden wäre wirklich praktisch, ist aber (Stand jetzt) ziemlich umständlich einzubauen :-/ dazu muss man irgendwie den Audio-Buffer abgreifen, duplizieren und dann wieder abspielbar machen

Der Gedanke mit der PS3 Eye war ganz charmant, da der PI hinterm 3D Drucker hängt. WebCam für den Drucker und Mikro für die Spracherkennung. Spannend ist ja. Wakeword mag er nicht, sobal das Mik läuft versteht er mich wie eine eins.

Uff 7s ist hart. Kommt das eigentlich auch wenn du den trigger button im Control HUB benutzt? Wenn ich mich recht erinnere wurde das auch weniger wenn man mehrere Befehle in kurzem Abstand benutzt hat oder? Geht da vielleicht irgendein Empfänger in den sleep-mode?

Grüße,
Florian

Ich hab es ja mit verschiedene Gerätetypen probiert. Also gerade nochmal über den Control HUB getestet und geklickt. Also er benötigt einen Moment nachdem ich auf das Symbol geklickt habe, umintern den state von off/on zu wechseln. Aber der Klick auf den Powerbutton, lässt quasi mit Mauszeiger loslassen das Licht an bzw. ausgehen. Ich muss dann nur Zwischen den Schaltvorgängen zwei Sekunden warten. (Also Lampen an und direkt wieder aus geht nicht), aber das war ja auch erstmal nicht das Problem. also da betellt das Problem wohl eher nicht. Dann muss es ein anderes Problem sein.

Und das mit dem kürzeren Abständen hatten wir schonmal, aber das funktioniert so auch nicht. Bzw. lässt sich nicht bestätigen.
Wenn ich mal eine Vermutung äussern kann/darf wie auch immer. Ich spreche den Text, dann wertet er den Text aus, baut den Befehl zusammen und schickt dann die Antwort zurück und dabei schaltet er.
Kann es sein, das die "Auswertung" vom Text so lange dauert? Wie gesagt, ich würde gerne suchen ich weiss nur nicht wo

Das Log hatte ich dir ja mitgeschickt, dann siehst du ja eigentlich ganz gut, was er so abschickt und in welchem Abstand zurück bekommt.

Vielleicht hast du ja noch eine Idee, und ja so ist es nicht nutzbar ernsthaft, denn da hab ich ja schon 3 Schalter geklickt in der Zeit. Wenn nicht eh der Bewegungsmelder oder Radarsensor der schnellste von allen ist.
[/quote]

Gruß
Basti

PS: Naja mal kurz antworten geht nicht, wenn mal einmal antwortet.

[EDIT] Noch ein kleiner Wunsch für deine Liste (sofern ich das noch nicht gefragt habe) du hast doch das Testskript wo du die Ports und zugriffe testest (test-cluster.sh), kannst du da noch einen Proxy Check einbauen?. Manchmal nach dem Neustart startet er ihn nicht mit, hab noch nicht gefunden warum. Dann hab ich ja das portmapping im Windows für localhost.
Nach einem grösseren Windows Update ist das auch schonmal weg, dann geht die suche los wer schuld ist. da wäre das test skript wenn das den proxy direkt mit checkt schon gold wert.

Danke.

[sepia]

Okay das hört sich aber nicht nach MQTT in Richtung Node-Red an oder? sondern ein Node?

Ja, im Grunde läuft es so: Die neue Node.js Library für SEPIA baut die Verbindung zum CLEXI Server auf und Node-RED ist nur eine Möglichkeit diese Verbindung via Drag & Drop Funktionen zu verarbeiten. Z.B. kann man alle CLEXI Events auslesen und via Node-RED MQTT Node irgendwo anders hinschicken

Mein gedanke war, ich schicke ein Kommando "Reload" zum Client oder Server und lasse, wenn er ein event inactive schickt ihn einrach einen Reload machen.
Nicht schön, aber dann steht man zumindest nicht doof davor und fragt sich, will er mich gerade nicht verstehen, oder kann er mich nicht verstehen.

Theoretisch geht das, praktisch ist es aber mmn momentan noch zu kompliziert, weil man die authentifizierte Verbindung zu entweder CLEXI oder SEPIA Server benötigt und dann auf einem der Kanäle auf eine Antwort warten muss.
Für die nächste Version füge ich dem SEPIA Chat-Server einen Endpoint hinzu, der alle aktiven Clients ausgibt.

... wenn er "fehlauslöst" und der Fernseher läuft, dann "zeichnet" er erstmal Fleissig auf, Hatte mal ne ganze Tagesthemen Reportage dann als Text, (Ich glaub ich wiederhole mich gerade)

Alexa scheint da ziemlich robust zu sein, aber bei meinem Google Home hatte ich genau das gleiche Problem. Der hatte so viele Fehlzündungen beim TV gucken und auch generell, dass ich ihn irgendwann komplett rausgeschmissen habe :-/. Alexa erkennt dafür manchmal meine Zurufe nicht wenn der Fernseher läuft. Bei Musik haben die allerdings den unschlagbaren Vorteil, dass das was aus dem eigenen Lautsprecher kommt automatisch aus dem Mikrofonkanal rausgefiltert wird (ist zumindest meine Beobachtung).

Für SEPIA nutze ich zur Zeit ein Mikrofon, das Geräusche hauptsächlich aus einer bestimmten Richtung aufnimmt (Samson GoMic, lässt sich umschalten) um dieses Problem zu reduzieren. P.S.: Je mehr Wake-Words du gleichzeitig einstellst desto mehr Fehlalarme wirst du natürlich auch bekommen
Eventuell macht es auch Sinn ein System zu etablieren, das alle Wake-Words ausschaltet wenn man den Raum verlässt. Sowas wurde hier irgendwann ja auch schon mal kurz angesprochen über Bluetooth Beacons oder Wifi. Die Schnittstellen dafür vervollständige ich gerade.

Das ist vermutlich genau das, was ich ja teilweise, wenn auch nicht so schön, per client und mqtt versucht habe, aber aufgehört habe, weil das ja mit updates nicht mehr wirklich pflegbar wäre.
Aber meine Lösung gefällt mir bisher ganz gut.

Ja, im Grunde wird dadurch das Feature vom Client entkoppelt, so dass jeder einbauen kann was er braucht ohne am Source-Code zu spielen. Wer kein Node-RED nutzen will kann auch die Node.js Funktionen so laufen lassen. Node.js ist ja eh schon installiert für CLEXI.

Ich benötigte aber natürlich nur das play device, das record device nehme ich dort gar nicht. (Deswegen trage ich auch nicht das default ein). Damit sollten sie sich nicht in die quere kommen.
ich habs global unter /etc/asound.conf liegen, was aber im Endeffekt keinen Unterschied macht.

SEPIA nimmt als Sound-Output einfach das was Linux als "default" definiert, es könnte allerdings sein, dass deine globale 'asound.conf' durch die im User Ordner überschrieben wird (die müsste höhere Priorität haben).

Wakeword aus, müsse ich mal testen, aber das wäre ja vom Prinzip unpraktisch.

Ich mache es im Auto manchmal so: Handy in Halterung, SEPIA in Always-On Mode und dann für die Eingabe kurzer Tap auf das SEPIA Gesicht Wake-word bleibt aus, das klappt bei mir eh nicht wegen zu hoher Geräuschkulisse :-/

Vorschlag, damit jeder sich was passendes, bzw. Situationsabhängiges hat und wenn die Stelle im Code hast, vermutlich "wenig" Mehraufwand.
"App Exit" "App Background" dann bist du für alle eventualitäten gewappnet. Sobald die app offen ist macht sie "zicken".

Ich habe da noch mal drüber nachgedacht und mir ist dabei eingefallen, dass "App Exit" gar nicht existiert ... sowohl iOS als auch Android kennen Design bedingt nur "App Background". Es gibt Workarounds die mit entsprechenden System Rechten den Prozess killen können oder man bringt die App vorsätzlich zum Crash ... leider beides nicht wirklich Optionen für die App, sorry

Wenn ich mal eine Vermutung äussern kann/darf wie auch immer. Ich spreche den Text, dann wertet er den Text aus, baut den Befehl zusammen und schickt dann die Antwort zurück und dabei schaltet er.
Kann es sein, das die "Auswertung" vom Text so lange dauert? Wie gesagt, ich würde gerne suchen ich weiss nur nicht wo

In den Server Stats und in der API Antwort kannst du die NLU Zeit sehen. Die ist bei mir im Schnitt 200-400ms auf einem RPi3. Es gibt eine Stelle, an der es etwas länger dauern könnte, da liest er alle Gerätenamen vom Smart Home HUB (FHEM) in den Cache. Wenn der Cache aus irgendeinem Grund leer ist und du viele Geräte hast könnte das etwas länger dauern. Was eventuell mal einen Versuch wert wäre ist beim Smart Home Service auf "Internal HUB" umzustellen und das besagte Gerät dort einrichten um zu gucken ob sich die Reaktionszeit ändert.
Im Assist-Server Log standen keine Warnungen bezüglich fehlender Verbindungen (MQTT Server die nicht mehr benutzt werden etc.) oder Funktion die zu lange gebraucht haben?

[EDIT] Noch ein kleiner Wunsch für deine Liste (sofern ich das noch nicht gefragt habe) du hast doch das Testskript wo du die Ports und zugriffe testest (test-cluster.sh), kannst du da noch einen Proxy Check einbauen?

Kann ich machen, ja Ein möglicher System Befehl ist übrigens "sudo service nginx status".

Grüße

[TRallala]

Hey Florian,

kurze zwischenfrage aml ohne smarthome/mqtt service bezug:  hast du eine doku für den TTS endpoint, die ich nicht gefunden habe?
Würde den gerne weiter benutzen, wenn möglich.

Gruß
Markus

[sepia]

Hey Florian,

kurze zwischenfrage aml ohne smarthome/mqtt service bezug:  hast du eine doku für den TTS endpoint, die ich nicht gefunden habe?
Würde den gerne weiter benutzen, wenn möglich.

Gruß
Markus

Hi Markus,

es gibt eine knappe aber nützliche Übersichtsseite für die Endpoints. Dort ist auch ein TTS Beispiel. Der "/tts" Endpoint liefert einen Link zur Audiodatei. Eine Node.js Library ist auch in Arbeit, falls dir das weiterhelfen würde.

Grüße

[TRallala]

Mahlzeit,

danke. Funktioniert. Und doch auch wieder nicht. Ist der API nur eine "voice" zugeordnet, oder erlaubt?
Über "Tools" kann ich die picotts voice  "voice": "de-DE pico f" auswählen und nutzen.
Mach ich das manuell, per

Code Auswählen Erweitern

curl -X POST -d "text='Hello World'&lang=de&voice='de-DE pico f'&gender=default&mood=5&GUUID=uid1007&PWD=password" 1.2.3.4:20721/tts
bekomm ich im Log:

Code Auswählen Erweitern

ERROR - TTS FAILED: voice NOT found!

Gruß
Markus

[sepia]

danke. Funktioniert. Und doch auch wieder nicht. Ist der API nur eine "voice" zugeordnet, oder erlaubt?
[...]

Code Auswählen Erweitern

curl -X POST -d "text='Hello World'&lang=de&voice='de-DE pico f'&gender=default&mood=5&GUUID=uid1007&PWD=password" 1.2.3.4:20721/tts

Hi Markus,

die Anfrage sieht auf den ersten Blick korrekt aus und der Endpoint bedient auch alle Clients sprich das Ergebnis sollte identisch sein zu z.B. der Testseite aus dem Control HUB und der App (falls der Server identisch ist).
Versuch mal den "/tts-info" Endpoint um zu testen welche Stimmen angeblich verfügbar sind.

[TRallala]

Moin,

jetzt funzt's.
Problem:  bei "text" scheint der parser kulant zu sein und den übermittelten Wert 'Hello World' selbst zu (url) de/en-coden.
bei voice tut er das nicht und  man muss sich selbst drum kümmern.

also:
funktioniert NICHT:

Code Auswählen Erweitern

curl -X POST -d "text='Hello World'&lang=de&voice='de-DE pico f'&gender=default&mood=5&GUUID=uid1007&PWD=password" 1.2.3.4:20721/tts

funktioniert:

Code Auswählen Erweitern

curl -X POST -d "text='Hello World'&lang=de&voice='de-DE+pico+f'&gender=default&mood=5&GUUID=uid1007&PWD=password" 1.2.3.4:20721/tts
besser:

Code Auswählen Erweitern

curl -X POST -d "text='Hello World'&lang=de&voice=de-DE%20pico%20f&gender=default&mood=5&GUUID=uid1007&PWD=password" 1.2.3.4:20721/tts
imho best:
curl -X POST -d "text=Hello%20World%20&lang=de&voice=de-DE%20pico%20f&gender=default&mood=5&GUUID=uid1007&PWD=password" 1.2.3.4:20721/tts

GrußMarkus

edit:
Bei Text darf nicht  encodiert werden.
Funktioniert auch nicht:

Code Auswählen Erweitern

curl -X POST -d "text=Hello%20World%20&lang=de&voice=de-DE%20pico%20f&gender=default&mood=5&GUUID=uid1007&PWD=password" 1.2.3.4:20721/tts

[whistler]

Ja, im Grunde läuft es so: Die neue Node.js Library für SEPIA baut die Verbindung zum CLEXI Server auf und Node-RED ist nur eine Möglichkeit diese Verbindung via Drag & Drop Funktionen zu verarbeiten. Z.B. kann man alle CLEXI Events auslesen und via Node-RED MQTT Node irgendwo anders hinschicken

Theoretisch geht das, praktisch ist es aber mmn momentan noch zu kompliziert, weil man die authentifizierte Verbindung zu entweder CLEXI oder SEPIA Server benötigt und dann auf einem der Kanäle auf eine Antwort warten muss.
Für die nächste Version füge ich dem SEPIA Chat-Server einen Endpoint hinzu, der alle aktiven Clients ausgibt.

Das klingt vielversprechend, nach weniger Selbstumbau, und mehr wieder im Standard. Customizing macht ja immer da sind, wo nix überschrieben wird, wie du ja schon die Cust Teach eingebaut hast. Wo ich auch mal weiter probieren könnte

Alexa scheint da ziemlich robust zu sein, aber bei meinem Google Home hatte ich genau das gleiche Problem. Der hatte so viele Fehlzündungen beim TV gucken und auch generell, dass ich ihn irgendwann komplett rausgeschmissen habe :-/. Alexa erkennt dafür manchmal meine Zurufe nicht wenn der Fernseher läuft. Bei Musik haben die allerdings den unschlagbaren Vorteil, dass das was aus dem eigenen Lautsprecher kommt automatisch aus dem Mikrofonkanal rausgefiltert wird (ist zumindest meine Beobachtung).

Ich bastel gerade eine Loopback, aber eher um passend zur Musik die Ausgabe abzufangen fürs Ambilight Wieder eine andere Baustelle. Aber das mit dem Rausfiltern klingt spannend.
Ähnlich wie in der Höherpreisigen Autos, die Filtern auch die Geräusche vom aussenbereich damit es innen schönen Leise ist

Für SEPIA nutze ich zur Zeit ein Mikrofon, das Geräusche hauptsächlich aus einer bestimmten Richtung aufnimmt (Samson GoMic, lässt sich umschalten) um dieses Problem zu reduzieren. P.S.: Je mehr Wake-Words du gleichzeitig einstellst desto mehr Fehlalarme wirst du natürlich auch bekommen
Eventuell macht es auch Sinn ein System zu etablieren, das alle Wake-Words ausschaltet wenn man den Raum verlässt. Sowas wurde hier irgendwann ja auch schon mal kurz angesprochen über Bluetooth Beacons oder Wifi. Die Schnittstellen dafür vervollständige ich gerade.

Ja ich hatte tatsächlich überlegt die Wakewors mal wieder zu reduzieren, deswegen fand ich ja ursprünglich den gedanken nett, das er die Wakewords als Audio ablegen könnte. Dann könnte man sich das anhören, wenns läuft interessiert das natürlich nicht mehr. Also ich merke immer indirekt wenn es keine Fehlzündungen mehr gibt. Heisst das für mich das "Wakeword" ist abgestürzt.
Gutes Beispiel dafür, ich lasse ihn Restarten, geht ja auch gut per VNC, Reiter 3 Interface neu laden, das geht auch gut in der Mittagspause Remote. Das ich danach Telegram Meldungen fürs Hotword kriege so 1-2 Stunden aus allen unterschiedlichen Räumen. Wohlgemerkt es ist keiner daheim und alles Still und aus.

Ja, im Grunde wird dadurch das Feature vom Client entkoppelt, so dass jeder einbauen kann was er braucht ohne am Source-Code zu spielen. Wer kein Node-RED nutzen will kann auch die Node.js Funktionen so laufen lassen. Node.js ist ja eh schon installiert für CLEXI.

Also das Problem ist vielleicht auch, das es mehr möglichkeiten gibt die du vielleicht ja kennst, weil du sie eingebaut hast, aber der rest nicht
Aber ja so würde ich mir das wünschen, ich bin sicher nicht der einzige. (Hast du schon was DEV Test mässiges? )

SEPIA nimmt als Sound-Output einfach das was Linux als "default" definiert, es könnte allerdings sein, dass deine globale 'asound.conf' durch die im User Ordner überschrieben wird (die müsste höhere Priorität haben).

ich habe nur die globale, die scheint zu tun. es scheint auch damit nicht zusammen zu hängen. einmal sieht es so aus als gäbe es einen Zusammenhang dafür die nächsten 9 male nicht mehr (1/10) ist ja nur nicht direkt reproduzierbar

Ich mache es im Auto manchmal so: Handy in Halterung, SEPIA in Always-On Mode und dann für die Eingabe kurzer Tap auf das SEPIA Gesicht Wake-word bleibt aus, das klappt bei mir eh nicht wegen zu hoher Geräuschkulisse :-/

Ich habe da noch mal drüber nachgedacht und mir ist dabei eingefallen, dass "App Exit" gar nicht existiert ... sowohl iOS als auch Android kennen Design bedingt nur "App Background". Es gibt Workarounds die mit entsprechenden System Rechten den Prozess killen können oder man bringt die App vorsätzlich zum Crash ... leider beides nicht wirklich Optionen für die App, sorry

Also ich hab das Wakeword mal ausgemacht, ich hatte den Verdacht auch schon. Aber du kennst das zwischen ja wird vermutlich so sein und eigentlich will ich das aber nicht so haben.
Also damit ist zumindest das Lautstärke "Problem" weg.

Hast du denn ein Intent was Sepia direkt in den Always On Mode schicken kann, bzw. könntest du das einbauen?
Dann könnte ich das Triggern per Tasker. Das wäre dann vielleicht auch ein Kompromiss, ich weiss das der Absturz etc. keine Option ist, keine Frage.

In den Server Stats und in der API Antwort kannst du die NLU Zeit sehen. Die ist bei mir im Schnitt 200-400ms auf einem RPi3. Es gibt eine Stelle, an der es etwas länger dauern könnte, da liest er alle Gerätenamen vom Smart Home HUB (FHEM) in den Cache. Wenn der Cache aus irgendeinem Grund leer ist und du viele Geräte hast könnte das etwas länger dauern. Was eventuell mal einen Versuch wert wäre ist beim Smart Home Service auf "Internal HUB" umzustellen und das besagte Gerät dort einrichten um zu gucken ob sich die Reaktionszeit ändert.
Im Assist-Server Log standen keine Warnungen bezüglich fehlender Verbindungen (MQTT Server die nicht mehr benutzt werden etc.) oder Funktion die zu lange gebraucht haben?

Kann ich machen, ja Ein möglicher System Befehl ist übrigens "sudo service nginx status".

Ja ich weiss, aber ich dachte mir, so hat man den "kompletten" System report in einem Rutsch. Und ja auch hier könnte ich selber was bauen. Da sind wir wieder bei Punkt 1 oben. Da ist mir sich ein gemeinsamen weg einigen und du schiebst es dafür in den Standard

Gruß
Basti