Open xyzaxyz opened 4 years ago
"speech-websocket-uri": "ws://localhost:20741/stt/socke$
ist das durchs Kopieren entstanden oder sieht das wirklich so aus? ^^ Abgesehen davon sieht alles soweit OK aus.
Eine Möglichkeit wäre noch in der ~/clexi/settings.json
mal den Parameter "idIsPassword": false
zu setzen, etwa so:
"hostname": "localhost",
"id": "clexi-123",
"idIsPassword": false,
"speech-websocket-uri": "ws://localhost:20741/stt/socke$
ist das durchs Kopieren entstanden oder sieht das wirklich so aus? ^^
Durch kopieren x)
Abgesehen davon sieht alles soweit OK aus.
Eine Möglichkeit wäre noch in der
~/clexi/settings.json
mal den Parameter"idIsPassword": false
zu setzen, etwa so:"hostname": "localhost", "id": "clexi-123", "idIsPassword": false,
Habe ich soeben geändert. Bekomme trotzdem keine Antwort, wenn ich pinge...
Hm komisch. Ich fasse kurz zusammen:
Hast du die Möglichkeit ein Display anzuschließen and den Client (Raspberry Pi?) ?
Zusammenfassung stimmt =)
Ich bin zumindest der Meinung, dass ich grundsätzlich nach einem Test jede Individualisierung wieder rückgängig gemacht habe oO
Ich hatte den Client auch extra gelöscht und nochmal neu gebasht.
Ja, ich habe die Möglichkeit. Habe schon zeitweiße einen dran. Was mich zu den Punkten bringt, dass Readyforsetup nur ertönt, wenn ich headless Client auswähle. Bei den zwei anderen Optionen will er einfach nicht^^
Ja, ich habe die Möglichkeit. Habe schon zeitweiße einen dran. Was mich zu den Punkten bringt, dass Readyforsetup nur ertönt, wenn ich headless Client auswähle. Bei den zwei anderen Optionen will er einfach nicht^^
Beim "normalen" Modus ist das zu erwarten, da dort die settings.js ignoriert wird, aber beim "pseudo-headless" sollte es klappen, der Modus verhält sich quasi wie headless (wer hätte das gedacht =)). Kannst du im Client mal F12 drücken und dann in der Dev-Tools Konsole gucken ob Fehlermeldungen kommen?
Ja, ich habe die Möglichkeit. Habe schon zeitweiße einen dran. Was mich zu den Punkten bringt, dass Readyforsetup nur ertönt, wenn ich headless Client auswähle. Bei den zwei anderen Optionen will er einfach nicht^^
Beim "normalen" Modus ist das zu erwarten, da dort die settings.js ignoriert wird, aber beim "pseudo-headless" sollte es klappen, der Modus verhält sich quasi wie headless (wer hätte das gedacht =)). Kannst du im Client mal F12 drücken und dann in der Dev-Tools Konsole gucken ob Fehlermeldungen kommen?
Ja pseudo-headless, das geht auch nicht^^ Wenn ich es richtig gesehen hab, funkt mir da der x-server (startx) dazwischen, da kommt dann immer "permission denied"...
Keinerlei Fehler in der Konsole =/ (getesetet auf dem Raspi direkt via Chromium -> http://localhost:20721/tools/index.html)
Interessanter wird es, wenn ich es an meinem Rechner über Chrome mache. Dort via http://sepia-home:20721/tools/index.html
Der gelbe Teil taucht nur an einem externen Rechner auf. Wenn ich am Raspi direkt eingeloggt bin, nicht. Allerdings funktioniert der Ping am Raspi genau so wenig...
Ach, das ist der Control HUB, sorry, ich meinte den Client, der das "ready for setup" von sich gibt. Die gelbe Warnung kann man getrost ignorieren, dass kommt durch die Dev-Tools selber ^^ (diese .map files mappen die minified JS Datei zurück in lesbaren Code zum Debuggen, brauchen wir aber nicht).
Ja pseudo-headless, das geht auch nicht^^ Wenn ich es richtig gesehen hab, funkt mir da der x-server (startx) dazwischen, da kommt dann immer "permission denied"...
Ok das ist auch komisch, aber das schieben wir erstmal nach hinten ;-) (klingt nach remote Zugriff oder Konflikt mit Desktop?).
Kannst du noch mal kurz erläutern wie dein Client von der Standardkonfiguration abweicht? Der Standard wäre:
Ach, das ist der Control HUB, sorry, ich meinte den Client, der das "ready for setup" von sich gibt. Die gelbe Warnung kann man getrost ignorieren, dass kommt durch die Dev-Tools selber ^^ (diese .map files mappen die minified JS Datei zurück in lesbaren Code zum Debuggen, brauchen wir aber nicht).
Ja pseudo-headless, das geht auch nicht^^ Wenn ich es richtig gesehen hab, funkt mir da der x-server (startx) dazwischen, da kommt dann immer "permission denied"...
Ok das ist auch komisch, aber das schieben wir erstmal nach hinten ;-) (klingt nach remote Zugriff oder Konflikt mit Desktop?).
Kannst du noch mal kurz erläutern wie dein Client von der Standardkonfiguration abweicht? Der Standard wäre:
- Raspberry Pi 3 oder 4 mit Raspbian Lite (aka Raspberry Pi OS) ohne Desktop
- Sauberes System, bei dem lediglich der SEPIA DIY Client installiert wurde
- Boot direkt in den Client im 'headless' Modus
Raspberry Pi 4, normales Raspian (kein Lite) Mit Desktop, versuche sowohl ind Headless, als auch pseudo-headless, autologin aktiv. Installiert sind Client und Server (ist das schlimm?) Ansonsten sauber. Extra für Sepia angeschafft. Bootet direkt in den headless. Ready for setup kommt automatisch.
Installiert sind Client und Server (ist das schlimm?) Ansonsten sauber
Nein, das macht keine Probleme mehr in der aktuellen Version.
Mit Desktop, versuche sowohl ind Headless, als auch pseudo-headless, autologin aktiv.
Das kann ein Problem sein, auf jeden Fall wird das vermutlich den XServer "permission denied" Fehler erzeugen, da der Desktop selber ja schon ein XServer ist und der Client versucht seinen eigenen Window Manager zu starten (Openbox).
Wenn du aber eh auf dem Desktop bist kannst du mal versuchen den Client einfach so im Browser zu öffnen via:
http://localhost:8080/sepia/index.html?isApp=true&isHeadless=true
.
Vermutlich werden dann einige Fehler aufpoppen bzw. Fragen nach Berechtigungen etc. aber die kannst du zum Testen einfach wegdrücken.
Du solltest dann "ready for setup" hören und in der Konsole (F12) beobachten können ob Fehler auftauchen.
Installiert sind Client und Server (ist das schlimm?) Ansonsten sauber
Nein, das macht keine Probleme mehr in der aktuellen Version.
Mit Desktop, versuche sowohl ind Headless, als auch pseudo-headless, autologin aktiv.
Das kann ein Problem sein, auf jeden Fall wird das vermutlich den XServer "permission denied" Fehler erzeugen, da der Desktop selber ja schon ein XServer ist und der Client versucht seinen eigenen Window Manager zu starten (Openbox).
Wobei das für mich ja auch erstmal nachrangig ist^^
Wenn du aber eh auf dem Desktop bist kannst du mal versuchen den Client einfach so im Browser zu öffnen via:
http://localhost:8080/sepia/index.html?isApp=true&isHeadless=true
. Vermutlich werden dann einige Fehler aufpoppen bzw. Fragen nach Berechtigungen etc. aber die kannst du zum Testen einfach wegdrücken. Du solltest dann "ready for setup" hören und in der Konsole (F12) beobachten können ob Fehler auftauchen.
Ich komme ohne Fehlermeldungen auf die Seite. Der Client meldet sich dann nach kurzer Zeit automatisch als Demo User an, bevor ich die User-Daten eingegeben habe. Dann kommt auch schon "ready for setup" In der Konsole taucht tatsächlich ein Sytax Error der settings.js:46 auf.
Ohweeeeeeeeee.... Der Syntax-Error war der Schuldige....
Das hatte ich einfach am Ende hinzugefügt, da ich nicht genau wusste, wohin damit... "useWakeWord": false, "autoloadWakeWord": false, "allowWakeWordDuringStream": false
Hab die Parameter nun raus gelöscht und jetzt auch eine Antwort vom Ping bekommen: Broadcaster event: {"broadcast":{"client":"m1_chrome_app_v0.22.0","deviceId":"m1","msg":"Hello World"}} Broadcaster response: "sent" Dafür schon mal herzlichen Dank!!!!!!!! <3
Laut Anleitung habe ich dann weiter diesen Befehl "call login user [user-ID] password [user-pwd]" ausgeführt. Mit uid1007 (smarthome user) und dem entsprechenden Kennwort. Das hat er angenommen mit "success", auch der Test hat funktioniert. Broadcaster event: {"broadcast":{"client":"m1_chrome_app_v0.22.0","deviceId":"m1","sepia-state":{"state":"idle"}}} Broadcaster event: {"broadcast":{"client":"m1_chrome_app_v0.22.0","deviceId":"m1","sepia-state":{"state":"speaking"}}} Broadcaster event: {"broadcast":{"client":"m1_chrome_app_v0.22.0","deviceId":"m1","sepia-speech":{"type":"tts_speak","msg":"Ja, klappt immer noch!"}}} Broadcaster event: {"broadcast":{"client":"m1_chrome_app_v0.22.0","deviceId":"m1","sepia-state":{"state":"loading"}}} Broadcaster event: {"broadcast":{"client":"m1_chrome_app_v0.22.0","deviceId":"m1","test-result":{"isActive":true,"user":"uid1007","next":"sending test message now ..."}}}
Dann kommt der Reboot und die Settings sind scheinbar wieder weg o.O Die Client Connections Console meldet dann wieder: Broadcaster event: {"broadcast":{"client":"m1_chrome_app_v0.22.0","deviceId":"m1","event":{"state":"active","user":"setup"}}}
Mit folgenden Login: http://localhost:8080/sepia/index.html?isApp=true&isHeadless=true Meldet sich dann auch wieder der Demo-User automatisch an.
Kontextfrage: run.sh und shutdown.sh in den Autostart einzutragen war schon richtig, oder? Also run.sh wird beim Start ausgeführt und shutdown.sh beim runterfahren. (via /etc/init.d Start/Stop Script)
Gibt es denn mittlerweile ne Möglichkeit, die Sprachengine zu ändern? Bzw auf online-Sprach-Engines zurückzugreifen? Das wäre edel.
Zum Thema pseudo-headless, was muss ich denn beim Raspi tun, damit das funzt? Weil sobald ich den Bildschirm anschließe, startet er automatisch im Desktop Mode...
Und am Rande: Wird es irgendwann möglich sein, das Wakeword "Hey Sepia" zu ändern? Das wäre cool, erstens schön individuell und zweitens kann man da Wörter nehmen, die sich kraftvoller brüllen lassen für eine bessere Erkennung x)
Btw. musste ich im run.sh in der Zeile für "pkill -f "clexi-server.js" ein "sudo" davor setzen.
Ohweeeeeeeeee.... Der Syntax-Error war der Schuldige....
uups :sweat_smile: , ich hatte mich schon gefragt ob beim Laden der Datei eventuell ein Fehler auftritt. Leider habe ich bisher noch keine Möglichkeit gefunden solche Fehler transparent weiterzuleiten :-/
Dann kommt der Reboot und die Settings sind scheinbar wieder weg o.O
Das liegt vermutlich daran, dass du mit dem "Test" Client im Browser weitergemacht hast während des Login oder? Beim Autostart wird der Client mit einem speziellen User-Ordner geladen (~/sepia-client/chromium/
), sprich alle deine Einstellungen die vorher gemacht wurden beim Test sind in dem Kontext dann nicht vorhanden.
Am Besten einfach noch mal den Login machen mit dem regulär geladenen Client, dann sollten sie permanent sein.
run.sh und shutdown.sh in den Autostart einzutragen war schon richtig, oder? Also run.sh wird beim Start ausgeführt und shutdown.sh beim runterfahren. (via /etc/init.d Start/Stop Script)
Bei der Installation des Client müsste sich eigentlich das 'run' Skript in die ~/.bashrc
eintragen (am Ende), welche dann beim Login des Users ausgeführt wird. Das 'shutdown' Skript ist eigentlich nur zum manuellen Beenden, Linux sollte den Rest automatisch erledigen wenn das System runterfährt.
Zum Thema pseudo-headless, was muss ich denn beim Raspi tun, damit das funzt? Weil sobald ich den Bildschirm anschließe, startet er automatisch im Desktop Mode...
In der RPi Konfiguration (sudo raspi-config
) kannst du einstellen, dass das System beim Start in die Konsole bootet (3 Boot Options -> B1 -> Console Autologin). Ich weiß jetzt nur nicht genau ob dann in deiner Konfiguration mit Desktop der richtige User geladen wird (pkill -f "clexi-server.js"
klappt vermutlich z.B. nicht weil der Desktop User keine Rechte dafür hat).
Gibt es denn mittlerweile ne Möglichkeit, die Sprachengine zu ändern? Bzw auf online-Sprach-Engines zurückzugreifen? Das wäre edel.
Du meinst für die Sprachausgabe oder? Auf dem Linux Client gehen da leider momentan nur die open-source offline Engines (eSpeak, pico + Mary TTS). Andere Engines z.B. von Google, Microsoft oder Amazon sind legal nur möglich wenn man die kostenpflichtigen APIs integrieren würde. Auf dem Windows Desktop und in Android sind Google und Microsoft so freundlich diese Services kostenlos als Plattform-Feature anzubieten. Ich habe in letzter Zeit etwas experimentiert mit neuen Mozilla Engines, die ziemlich gut sind. Leider noch zu langsam für den RPi und bisher auch nur in Englisch verfügbar (hier eine kleine Übersicht, die Engines in der Rubrik "Old School" sind schon in SEPIA, die oberen noch in der Test-Phase). Mary-TTS ist in SEPIA das "realistischste" was momentan möglich ist.
Wird es irgendwann möglich sein, das Wakeword "Hey Sepia" zu ändern? Das wäre cool, erstens schön individuell und zweitens kann man da Wörter nehmen, die sich kraftvoller brüllen lassen für eine bessere Erkennung x)
Es gibt eine begrenzte Anzahl von Optionen zur Zeit siehe hier. Eventuell tut sich auf dem Feld auch noch ein bisschen was in nicht allzu ferner Zukunft ^^. Leider war es bisher immer so, dass die Firmen, die etwas zuverlässiges geschafft hatten mittelfristig immer kommerziell wurden :-/
Habe nun alles komplett neu durchgestartet, die Logindaten nochmal neu gesetzt. Dann wieder getestet, hat wunderbar funktioniert. Nach dem erforderlichen reboot isses nun aber auch wieder weg :( Der Testclient war definitiv nirgendwo mehr offen.
Werde mich morgen weiter darum kümmern :)
Wird beim Pseudo-Headless dann keine grafische Oberfläche geladen? Prinzipiell hätte ich gerne nen Client mit Bildschirm, welcher wie der headless, sich automatisch startet und anmeldet, nur eben auch mit der grafischen Oberfläche, dass mir z.B. Wetterdaten etc. angezeigt werden können.
Habe es jetzt nochmal versucht. Client in Pseudo-Headless gesetzt und Autologin Console. Damit ohne grafisches Interface und somit Standardkonfiguration. Er merkt sich aber einfach die Login Daten nicht -.-
Hi, sorry für die späte Antwort. Leider habe ich gerade auch keine zündende Idee woran es liegen könnte :-/ vielleicht wird aus irgendeinem Grund beim Start der User Ordner (~/sepia-client/chromium) überschrieben 🤔
Dein Client ist Version 0.22.0 also aus dem Master Branch nicht dem Dev Branch oder?
Bin mir ziemlich sicher, dass es der master branch ist. Bin allerdings diese und nächste Woche im Urlaub. Werde anschließend der Server auf einem anderen Gerät aufsetzen und den raspi mit rasbpi lite neu installieren und den Client neu einrichten. Dann gebe ich nochmal Rückmeldung
Ok klingt gut. Vielleicht habe ich bis dahin auch die neue Version fertig :-).
Alternativ könnte man auch über den Desktop noch mal den Client mit korrektem (non-test) Startskript probieren. Vielleicht ist der Chromium aus irgendeinem Grund so eingestellt dass er beim Schließen alle Daten löscht.
Habe jetzt den Server auf meine Synology NAS gelegt und den Raspi komplett neu mit Raspi light installiert. Er scheint sich jetzt auch tatsächlich die Login-Daten zu merken. Dann taucht jedoch das nächste Problem auf: Broadcaster event: {"broadcast":{"client":"l1_chrome_app_v0.22.0","deviceId":"l1","sepia-wake-word":{"state":"error","msg":"Could not start audio source"}}} Broadcaster event: {"broadcast":{"client":"l1_chrome_app_v0.22.0","deviceId":"l1","sepia-wake-word":{"state":"inactive"}}} Broadcaster event: {"broadcast":{"client":"l1_chrome_app_v0.22.0","deviceId":"l1","sepia-wake-word":{"state":"active"}}} Broadcaster event: {"broadcast":{"client":"l1_chrome_app_v0.22.0","deviceId":"l1","event":{"state":"active","user":"uid1007"}}} Broadcaster event: {"broadcast":{"client":"l1_chrome_app_v0.22.0","deviceId":"l1","sepia-login":{"note":"loginSuccess"}}} Broadcaster event: {"broadcast":{"client":"l1_chrome_app_v0.22.0","deviceId":"l1","msg":"Logging in with new user: uid1007. Plz wait."}} Broadcaster response: "sent"
Wenn ich jedoch am Client die "test_voice_output.sh" teste, das funktioniert....
Muss auf dem Server die TTS Enigen dafür installiert sein? Dachte es genügt, wenn der Client reden kann^^
Hi,
"Could not start audio source" deutet normalerweise auf ein Problem mit dem Mikrofon hin. Weiter unten im Log schien es aber schon erfolgreich aktiviert worden zu sein. Folgt der Fehler unmittelbar auf das "active" oder liegt da noch eine User Interaktion dazwischen?
Der Server müsste in deiner Konfiguration schon das minimale TTS Paket installiert haben. Im Server Setup Menü (~/SEPIA/setup...) gibt es dafür im Zweifelsfall aber noch einen extra Eintrag. Der Fehler oben kommt allerdings von der Wake-Word Engine, wenn ich nichts übersehen habe.
Grüße
Ich logge den User ein. Und dann gibt es ja den Befehl zum testen, bei dem dann normalerweise "Funktioniert" geantwortet wird. Bei diesem Befehl taucht dann der Fehler auf.
Ein Fehler mit dem Mikro kann ich mir nicht vorstellen. Ich kann Audio Dateien aufnehmen und wieder abspielen, beides ohne Probleme...
Wenn es an der Wake-Word Engine liegt, was kann ich da tun? Liegt das dann evtl wieder an settings.json oder settings.js?
settings.js
//Settings primarily for headless mode and setup (URL parameter: 'isHeadless=true') SepiaFW.settings = { headless: { device: { "host-name": "192.168.188.67:20721", "deviceId": "l1", "deviceLocalSiteData": { "location": "home", "type": "room", "name": "unassigned", "index": "" }, "en-voice": "", "de-voice": "", "wakeWordSensitivity": [0.8] }, user: { "clexiSocketURI": "ws://localhost:8080", "clexiServerId": "clexi-123", "clexiConnect": true, "useRemoteCmdl": true, "speech-voice-engine": "sepia", "speech-asr-engine": "native", "speech-websocket-uri": "ws://localhost:20741/stt/socket", "useGamepads": true, "useBluetoothBeacons": true, "useBluetoothBeaconsInAoModeOnly": false, "useWakeWord": true, "autoloadWakeWord": true, "allowWakeWordDuringStream": false, "activeSkin": "2", "proactiveNotes": false, "autoGPS": true }, location: { "latitude": "", "longitude": "" }, broadcast: { "state": true, "login": true, "speech": true, "wakeWord": true } } };
Settings.json
{ "hostname": "localhost", "id": "clexi-123", "idIsPassword": true, "port": 8080, "ssl": false, "logger": { "level": "error" }, "xtensions": [ "clexi-broadcaster", "clexi-http-events", "runtime-commands" ] }
Hi,
soweit sehen alle Settings gut aus.
Nur noch mal zur Sicherheit: du benutzt das normale "~/sepia-client/run" Skript zum Starten richtig? Bzw. dort wurde nichts verändert oder?
Ich könnte mir vorstellen, dass der Client vielleicht auf dem falschen Kanal nach dem Mikrofon sucht. Was für ein Mikrofon nutzt du noch mal und wie wurde das installiert? (USB mit dem install Skript?).
Ja ich benutze das normale run-skript.
Mikro ist das 4 Mic Array https://wiki.seeedstudio.com/ReSpeaker_4_Mic_Array_for_Raspberry_Pi/ Hatte auf dem ersten Client einwandfrei funktiuoniert^^
Hatte auf dem ersten Client einwandfrei funktiuoniert^^
Das war der mit Desktop richtig? Eventuell hat der Desktop das korrekte Audiogerät automatisch eingestellt.
Kannst du einmal prüfen ob folgende Dateien bei dir existieren und ggf. den Inhalt posten:
~/.asoundrc
/etc/asound.conf
asoundrc
pcm.!default {
type asym
playback.pcm {
type plug
slave.pcm "output"
}
capture.pcm {
type plug
slave.pcm "input"
}
}
pcm.output {
type hw
card 0
}
ctl.!default {
type hw
card 0
}
/etc/asound.conf
# The IPC key of dmix or dsnoop plugin must be unique
# If 555555 or 666666 is used by other processes, use another one
# use samplerate to resample as speexdsp resample is bad
defaults.pcm.rate_converter "samplerate"
pcm.!default {
type asym
playback.pcm "playback"
capture.pcm "ac108"
}
pcm.playback {
type plug
slave.pcm "hw:ALSA"
}
# pcm.dmixed {
# type dmix
# slave.pcm "hw:0,0"
# ipc_key 555555
# }
pcm.ac108 {
type plug
slave.pcm "hw:seeed4micvoicec"
}
# pcm.multiapps {
# type dsnoop
# ac108-slavepcm "hw:1,0"
# ipc_key 666666
# }
Danke für den Edit, war zu doof dafür....
Hmmmm, ich hasse diese Dateien :stuck_out_tongue_closed_eyes: weil ich da nie richtig schlau draus werde aber ich habe das Gefühl in der ~/.asoundrc
fehlt irgendwie die richtige Info zum "input" device.
In der Konsole geht es ja? Wie testest du da? Mit arecord
?
Kommt das alles von der Installation des 4mic HAT?
Ja das teste ich mit dem arecord.
Kann ich nicht sagen, was das Installationsscript da alles gemacht hat. Vermutlich schon.
Kannst du testweise einfach mal die ~/.asoundrc
umbenennen (oder verschieben so dass sie nicht mehr geladen wird) und dann das System neustarten. Ich habe das Gefühl die steht in Konflikt mit der /etc/asound.conf
.
Eine andere Alternative:
nano ~/sepia-client/run.sh
--alsa-output-device=default
steht folgendes ergänzen: --alsa-input-device='ac108'
Also Datei umbenennen hat nichts gebracht^^ Ich teste die zweite Variante.
Hat leider nichts gebracht. Er bringt nachm Reboot kein Setup mehr, da er sich ja jetzt die Daten merkt. Aber Tests funktionieren nicht: Broadcaster event: {"broadcast":{"client":"l1_chrome_app_v0.22.0","deviceId":"l1","sepia-speech":{"type":"tts_error","msg":"unknown"}}} Broadcaster event: {"broadcast":{"client":"l1_chrome_app_v0.22.0","deviceId":"l1","sepia-state":{"state":"idle"}}} Broadcaster event: {"broadcast":{"client":"l1_chrome_app_v0.22.0","deviceId":"l1","sepia-speech":{"type":"tts_speak","msg":"Ja, es funktioniert!"}}} Broadcaster event: {"broadcast":{"client":"l1_chrome_app_v0.22.0","deviceId":"l1","sepia-state":{"state":"loading"}}} Broadcaster event: {"broadcast":{"client":"l1_chrome_app_v0.22.0","deviceId":"l1","test-result":{"isActive":true,"user":"uid1007","next":"sending test message now ..."}}} Broadcaster response: "sent" Broadcaster event: {"broadcast":{"name":"sepia-client","data":{"deviceId":"l1","call":"test"}}} Broadcaster event: {"broadcast":{"client":"l1_chrome_app_v0.22.0","deviceId":"l1","sepia-wake-word":{"state":"active"}}} Broadcaster event: {"broadcast":{"client":"l1_chrome_app_v0.22.0","deviceId":"l1","event":{"state":"active","user":"uid1007"}}} Broadcaster event: {"broadcast":{"client":"l1_chrome_app_v0.22.0","deviceId":"l1","sepia-login":{"note":"loginSuccess"}}} Broadcaster event: {"broadcast":{"client":"l1_chrome_app_v0.22.0","deviceId":"l1","sepia-login":{"note":"logoutSuccess"}}} Broadcaster event: {"broadcast":{"client":"l1_chrome_app_v0.22.0","deviceId":"l1","msg":"Logging in with new user: uid1007. Plz wait."}} Broadcaster response: "sent"
Moin.
Broadcaster event: {"broadcast":{"client":"l1_chrome_app_v0.22.0","deviceId":"l1","sepia-speech":{"type":"tts_error","msg":"unknown"}}} Broadcaster event: {"broadcast":{"client":"l1_chrome_app_v0.22.0","deviceId":"l1","sepia-state":{"state":"idle"}}} Broadcaster event: {"broadcast":{"client":"l1_chrome_app_v0.22.0","deviceId":"l1","sepia-speech":{"type":"tts_speak","msg":"Ja, es funktioniert!"}}}
Diesen Teil hier verstehe ich nicht, erst scheint er erfolgreich die Sprachausgabe zu triggern, geht zurück in den "idle" Modus und dann kommt ein Fehler :-/ Das ist jetzt aber neu oder? Vorher war es die Spracheingabe und jetzt die Sprachausgabe?
Ich gebe dir mal eine Vorabversion der 0.23.0 DIY Client scripts, vielleicht geht es damit einfacher einzustellen: sepia-diy-client_0.23.0_beta_scripts.zip
Den Inhalt einfach nach ~/sepia-client/
kopieren und die existierende run.sh und setup.sh überschreiben. Dann noch mal bash setup.sh
ausführen und Punkt 8 wählen und dort ac108
als Input Gerät angeben :crossed_fingers: :crossed_fingers:
Bei der Einrichtung des wakeword und des sepia-client auf dem RPi4 mit einem Respeaker4 Mic habe ich leider folgende Schwierigkeiten:
Prolog
Prolog zu unserem Austausch gestern - was ich bisher durchgeführt und eingerichtet habe: Ich nutze mittlerweile die SEPIA Basis/Web-UI nicht mehr auf dem RPi4, sondern auf einem Docker-Host. Das Webpanel wird durch einen nginx-Proxy von `http://dock.vx:20726/sepia/assist/tools/index.html` auf `https://sepia.dock.vx/sepia/assist/tools/index.html` umgeleitet. Dadurch habe ich valides HTTPs, was zur Einrichtung vom wakeword scheinbar wichtig war. Das Wakeword habe ich nicht zum Laufen bekommen, den Host werde ich in Docker behalten. `sepia/stt-server:beta2.1` läuft ebenfalls in einem Container und die Anbindung hat gestern abend eigentlich funktioniert - derzeit sind die Inputs unter /sepia/assist/tools/index.html#!speech-recognition allerdings leer, evtl. muss ich das erneut anbinden - sollte aber funktionieren.Details
Als SEPIA selbst noch auf dem RPi4 lag, war alles per HTTP - ich bekam beim Anbinden des wakeword auf dem selben Host folgende Meldung: ``` requests.exceptions.SSLError: HTTPSConnectionPool(host='homenode01.fritz.box', port=20726): Max retries exceeded with url: /sepia/as sist/authentication (Caused by SSLError(SSLError(1, u'[SSL: WRONG_VERSION_NUMBER] wrong version number (_ssl.c:727)'),)) ``` Später bei der Einrichtung des wakeword kam ich trotz trusted CA nicht um den Fehler herum: ``` requests.exceptions.SSLError: HTTPSConnectionPool(host='sepia.dock.vx', port=443): Max retries exceeded with url: /sepia/assist/authentication (Caused by SSLError(SSLError(1, u'[SSL: CERTIFICATE_VERIFY_FAILED ``` Daraufhin habe ich `File "/home/pi/SEPIA/sepia-wakeword-tools/Porcupine/sepia/account.py", line 60` bearbeitet, **dirty hack**: `response = requests.request("POST", url, json=payload, headers=headers)` --> `response = requests.request("POST", url, verify=False, json=payload, headers=headers)` Die Einrichtung des wakeword scheiterte letztendlich mit der Erkenntnis, dass es keine Porcupine-Lib für den Pi4 in dem Package gibt. `Exception: Cannot autodetect library. Please use e.g.: --library_path="porcupine/lib/raspberry-pi/arm11/libpv_porcupine.so" (Pi Zero with ARM11 CPU).` Danach habe ich das wakeword auf einem pi zero w installiert, da dort ja die arm11-lib greifen sollte. Leider scheiterte ich letztendlich an: ``` [ERROR] keyword file has incorrect format or belongs to a different platform [ERROR] loading keyword file failed with 'INVALID_ARGUMENT' ``` ![image](https://user-images.githubusercontent.com/27498403/77226232-0d801700-6b77-11ea-8663-9d19f5485473.png)Nachdem ich also mit dem Wakeword keinen Erfolg hatte, habe ich die Android-App ausprobiert. In der App komme ich leider weder mit dem admin-User, noch mit einem User mit den Gruppen
"user", "tester", "translator", "developer", "seniordev", "chiefdev"
dazu, einen Befehl abzusenden:Sorry <user_name>, aber du brauchst erst eine Erlaubnis, um diesen Smart Home Service zu nutzen
Also habe ich weiter gelesen und fand die SEPIA Client Installation - Raspberry Pi und versuchte mich an der Anbindung.
Ausgehend von meiner HTTPS-Route auf SEPIA konnte ich den CLEXI-Server vom RPi-Client nicht anbinden, da unsichere WebSocket-Verbindungen nicht von einer HTTPS-Seite ausgehen dürfen, während ich über die zusätzlich verfügbare HTTP-Route zu meinem Container erfolgreich eine Verbindung zum WebSocket herstellen konnte. Das wss-Protokoll ist scheinbar nicht unterstützt, sodass ich mit HTTPS keine Verbindung aufbauen kann.
Screenshots
![image](https://user-images.githubusercontent.com/27498403/77226436-b8450500-6b78-11ea-87ef-5f385bf26899.png) ![image](https://user-images.githubusercontent.com/27498403/77226437-ba0ec880-6b78-11ea-8e19-0f4ac7926147.png)Die Anbindung des Client endet in diesem Moment leider mit folgender Situation: Egal, welche Art der Authentifizierung ich probiere (wobei ich denke, uid1234 ist das richtige user-pattern), erhalte ich die Antwort
loginFail
.Laut doc
Meldung von SEPIA auf
call ping
Manueller
curl
call auf den EndpunktSEPIA client and server versions
sepia-assist-v2.4.2
&sepia-core-tools-v2.2.6
(Gestern von dir bereitgestellt, nun in Docker)Um es noch mal kurz zu fassen, brauche ich gerade ein paar Richtungsweisungen, wie ich am Besten das Wakeword und die Spracheingabe angebunden bekomme - bestenfalls auf dem RPi4. Wenn ich die Android-App ebenfalls zum Laufen bekomme, wäre das super.
Ich danke Dir vielmals!