Open xyzaxyz opened 4 years ago
Hi,
also ich fange mal beim Wake-Word an ;-)
Wie ich sehe hast du dich an dem Python Tool probiert. Leider habe ich das seit einer Weile nicht mehr auf Herz und Nieren getestet, vor allem nicht mit dem RPi4 :-( Einige Fehler beziehen sich auf SSL und tatsächlich habe ich dieses Tool glaub noch nie über HTTPS laufen lassen sondern immer nur mit lokalen IPs :grimacing: . Dazu kommt dann noch:
Die Einrichtung des wakeword scheiterte letztendlich mit der Erkenntnis, dass es keine Porcupine-Lib für den Pi4 in dem Package gibt.
Das hatte ich auch noch nicht auf dem Schirm :-( Werde ich mir aber noch mal angucken.
Aber ... der Client hat eigentlich eine integrierte Wake-Word Erkennung :nerd_face: weshalb ich das Python Programm nur noch als Notlösung betrachte, falls das andere nicht klappt oder falls man spezielle Setups basteln möchte (was nicht heißt dass der Python Client nicht irgendwann weiter ausgebaut wird ^^). Gab es einen bestimmten Grund dafür warum du die Python Tools nutzt? Falls die Antwort ist "ich wusste gar nicht dass es ein integriertes WW gibt" kann ich das durchaus nachvollziehen, denn es wird auch glaub nur am Rande irgendwo erwähnt und man findet es meist erst beim Rumspielen in der App :see_no_evil: . Generell ist die Dokumentation des DIY Clients noch ziemlich spärlich, einiges wird auch noch leichter gemacht in Zukunft ^^.
Die integrierte WW Erkennung findet sich in der App in den Settings bei "Hey SEPIA" und lässt sich im DIY Client (aka headless Client, ich werden den jetzt öfters DIY nennen ^^) via der settings.js
aktivieren:
"useWakeWord": false,
"autoloadWakeWord": false,
"allowWakeWordDuringStream": false
Zum Thema Android App + Smart Home:
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
, aber du brauchst erst eine Erlaubnis, um diesen Smart Home Service zu nutzen
Für den Smart Home Service benötigt der User die Rolle "smarthomeguest" zum Nutzen und "smarthomeadmin" zum Konfigurieren, siehe Smart Home Controls - Quick Setup.
Zum Thema Client Connection:
Also habe ich call ping ausgeführt, erhalte daraufhin leider einen 404, den ich via curl vom selben RPi4 nicht nachstellen kann. Logs habe ich leider bisher nicht gefunden, dass ich mehr Auskunft geben kann.
Ich vermute der Client darf mal wieder den HTTPS Call nicht machen. Läuft er noch auf "openhab.local:7070" oder auf "localhost:7070"? Bin mir allerdings nicht sicher ob das wirklich einen 404 erzeugen würde, kann ich mir aber gut vorstellen :-/
Ein paar nützliche Richtlinien um SSL Probleme zu vermeiden:
location /sepia/chat/messages/
Vorlage hinzufügenNachtrag zum Raspberry Pi Zero:
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'
Ich glaube da fehlte das folgenden Argument:
--keyword_file_paths=porcupine/keyword_files/hey_sepia_raspberrypi.ppn
Hey,
das Python Tool https://github.com/SEPIA-Framework/sepia-wakeword-tools/tree/master/Porcupine habe ich irgendwie zuerst gefunden und mich direkt leiten lassen, da es korrekt klang - ich habe es als das Projekt interpretiert, das dann auf den Clients/Satelliten läuft und lokal das Wakeword erkennt, um den danach folgenden Audiostream an den Master zu senden, der den Input verarbeitet.
Erst später bin ich auf das eigentliche Client-Projekt https://github.com/SEPIA-Framework/sepia-installation-and-setup/tree/dev/sepia-client-installation/rpi gestoßen und habe ähnliche Funktionen erwartet, also hab ich das versucht einzurichten.
Danke soweit! Danke für den Hinweis auf die Benutzergruppen, das habe ich zu dem Zeitpunkt wohl wieder vergessen - da dachte ich, der admin-User hätte doch sicher die nötigen Rechte ^^ Aber jetzt weiß ich es und habs hinterlegt. Durch die korrekten Gruppen konnte ich mit der Android-App schon erfolgreich mein Licht schalten.
Anbindung des RPi Clients: Dass der 404 wegen SSL kommt, kann ich mir nicht zu 100% vorstellen. Curl müsste ich üblicherweise mit -k
senden, um unsichere/untrusted SSL-Verbindungen zuzulassen, heißt also eigentlich, dass das Cert erfolgreich installiert wurde, oder?
Danke für den Hinweis auf das integrierte Wakeword vom Client!
Zwischen dem Lesen deiner Antworten bis zu dem Abschnitt unten ist ein bisschen Zeit vergangen, da ich das Setup auf dem Pi4 und Pi Zero erneut durchgeführt habe.
Ich habe folgende Schritte durchgeführt: Auf dem Pi4 sowie danach dem Zero funktioniert der Client - eingeschränkt. (Das Respeaker2 HAT, das grad am Zero ist, gefällt mir mehr, daher dachte ich, ich mach vllt alles mit dem - aber die Setup Schritte dauern vergleichsweise viel länger, evtl. wird es doch der Pi4 mit Respeaker2 statt Respeaker4 - der Audio Output vom AUX Port ist einfach zu noisy.)
Die Connection habe ich wie du vorgeschlagen hast nun gegen die HTTP-Route aufgeschalten, für den Anfang muss das reichen - lieber mit geringerer Komplexität starten.
Dadurch gingen die Befehle call test
, call ping
gut. Ebenfalls kann ich das Mikrofon über die Funktion "Shortcut: trigger mic (device ID)" aktivieren und damit mein Licht steuern.
Das Wakeword geht trotz der Settings in der ~/clexi/settings.json
bisher nicht.
Nachtrag zum Raspberry Pi Zero:
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'
Ich glaube da fehlte das folgenden Argument:
--keyword_file_paths=porcupine/keyword_files/hey_sepia_raspberrypi.ppn
Du hast Recht, mit dem Parameter geht es. Da hätte ich auch drauf kommen können, leider hab ich nicht in die später in der README erwähnten bash-Skripte geschaut, da stehen die ja auch ^^ Mit dem Python-Wakeword-Tool habe ich dann aber nicht weiter gemacht, sondern geschaut, dass ich den Client ordnungsgemäß zum Laufen kriege.
Ich hab den sepia-client heute noch mal sauber auf dem Pi4 mit dem Respeaker2 aufgezogen und komme nur bis zum Punkt, an dem ich vorher war - das Wakeword funktioniert in meinem Fall leider nicht. Die Werte für die ~/clexi/settings.json
habe ich mit true
begonnen und später auch false
probiert, dazwischen immer rebootet.
Nur wenn ich das Mic manuell aktiviere, kann ich Kommandos geben, die auch korrekt ausgeführt werden. 👍
Step by step ^^
Moin :-)
Die Wake-Word Settings sind glaub in der falschen Datei gelandet ^^. Ich meinte tatsächlich die settings.js
aus dem Client Ordner ~/clexi/www/sepia/settings.js
:sweat_smile:
... arbeite auch gerade dran, dass man das in Zukunft über den SEPIA Control HUB aktivieren kann ;-)
Anbindung des RPi Clients: Dass der 404 wegen SSL kommt, kann ich mir nicht zu 100% vorstellen. Curl müsste ich üblicherweise mit -k senden, um unsichere/untrusted SSL-Verbindungen zuzulassen, heißt also eigentlich, dass das Cert erfolgreich installiert wurde, oder?
Hm ja komisch. Besteht das Problem jetzt weiterhin oder ist es durch das geänderte Setup verschwunden?
Moin :)
Die Wake-Word Settings sind glaub in der falschen Datei gelandet ^^. Ich meinte tatsächlich die
settings.js
aus dem Client Ordner~/clexi/www/sepia/settings.js
😅
Ahh, da hab ich mich noch nicht umgeschaut, clexi ist auch noch neu für mich :D Damit funktioniert es! 👍
... arbeite auch gerade dran, dass man das in Zukunft über den SEPIA Control HUB aktivieren kann ;-)
Top was du alles einbaust! 🚀
Hm ja komisch. Besteht das Problem jetzt weiterhin oder ist es durch das geänderte Setup verschwunden?
Hab es jetzt normal über HTTP angebunden und die Verbindung persistiert ja, daher ist das nicht so schlimm. Ich habs nicht noch mal probiert, denke aber dass es mit HTTPS nicht klappen würde - ich lass das jetzt so und baue lieber erst mal aus :) Für Tests soll dann ein separates Setup dienen, da ich aber nur einen Respeaker2 habe, ist mir das Umstecken für kleine Versuche zu fummlig, wenn das Main-Setup schon läuft ^^
Gerade sind meine Baustellen auf der Lernkurve / eventuelle sub-issues:
speech-websocket-uri
statt auf ws://localhost:20741/stt/socket
auf die Docker-Instanz des sepia/stt-server:beta2.1
zeigen? Denke ich hier richtig, dass der Client eine mitgelieferte STT-Engine hat, und nicht die von der SEPIA-Basis nutzt? Dort hatte ich die eigentlich unter /sepia/assist/tools/index.html#!speech-recognition
hinterlegt./sepia/assist/tools/index.html#!speech-recognition
, /sepia/assist/tools/index.html#!client-connections
und /sepia/assist/tools/index.html#!smart-home
vergessen leider die zuletzt dort eingegebenen Werte, da wäre es eigentlich praktisch, wenn die erhalten bleiben.Endlich mal in kurzer Form ein paar Punkte aufgelistet 😄 Das meiste hat keine Eile. Bin froh, wenn manche Dinge schon gehen und ich Sepia parallel zu Snips aufziehen kann, und irgendwann bald ersetzen kann :)
Grüße euch,
vielleicht könnt ihr mir ja weiterhelfen was ich eventuell falsch mache. Ich versuche auch gerade den Smartspeaker zu bauen und nutze dafür den respeaker core v2. Der hat eigentlich alles schon an Bord was man braucht. Grundlegend funktioniert Sepia bei mir eigentlich schon recht gut, aber ich scheitere an CLEXI. Ich habe es installiert (ohne SSL, mit SSL kann ich ihn nicht erreichen), kann auf der Testpaige auch alles machen und mich mit der Testpaige zum Server connecten.
Ich kann mich aber mit keinem Client zum CLEXI Server verbinden, weder über Android noch über den Browser. Ich habe es mit dem Admin und mit meinem User versucht aber alles ohne Erfolg.
Das "Pünktchen" im Client bleibt immer rot. Wenn ich clexi-123 als ID rausnehme wird er immerhin schon mal gelb.
Hat irgendeiner eine Idee was da los sein kann? Ich komme sonst mit dem Smartspeaker nicht weiter.
Zudem habe ich mal noch eine Frage zum "allways on" Modus. Das Mikrofon bleibt dabei aber nicht aktiv oder? Ich kann mein Tablet anschreien wie ich will aber Sepia bleibt davon unbeeindruckt. Ich muss aktiv auf den Butten drücken oder? Das wäre recht hinderlich wenn man Satelliten bauen will.
Ich hoffe ihr könnt mir vielleicht weiterhelfen.
Danke und Gruß
Android App Mic-Button freezt mit blauem Rand, wenn man während der Antwort erneut drauf drückt
Könntest du dafür ein neues Issue erstellen bitte. Hier direkt noch ein paar Fragen, die du mitnehmen kannst ;-) : Ist das nur die Animation oder betrifft es auch die Funktionalität des Buttons, sprich kannst du danach direkt erneut drücken zum aktivieren? Welchen Skin nutzt du und (falls nicht default) tritt es auch beim default Skin auf? Welche TTS Engine/Stimme ist aktiv?
RPi4 sepia-client Wakeword Erkennung klappt nicht oft genug, akustisches Success-Feedback dauert gefühlt etwas lang
Ja ich fürchte bis man hier die Qualität eines Amazon Echos erreicht mit frei zugänglicher Technik wird es leider noch etwas dauern, zumal es auch stark von der Wahl des Mikrofons abhängt. Gute Erfahrungen habe ich mit dem "AmazonBasics Tragbares USB-Kondensatormikrofon" gemacht, ein Abklatsch des "Samson Go Mic Clip-On USB Mikrofon", das ich als nächstes probieren werde. Mein Jabra Konferenz Mic klappt auch ganz gut.
In den "Hey SEPIA" Settings gibt es noch eine Einstellung für die Empfindlichkeit, die ich noch nicht in die settings.js
aufgenommen habe, aber du kannst mal folgendes reinkopieren oben bei "device":
...,
"de-voice": "",
"wakeWordSensitivity": ["0.9"]
1.0 ist theoretisch am empfindlichsten, ... glaube ich ^^.
Tausch der TTS-Engine, evtl. weniger Roboterstimme, wenns da was gibt
Ja, da hab ich noch ein paar Sachen in der Schublade (MaryTTS und PicoTTS). Im Fokus steht auch die Mozilla Geschichte, aber die ist nicht so einfach zum Laufen zu kriegen und mmn auch noch im experimentellen Stadium. In Android hast du noch die Auswahl der integrierten Stimmen und auf Windows Geräten kann man übrigens auch die Microsoft Stimmen nutzen.
Anbindung ReSpeaker2 LEDs / Default ausschalten, grüne und blaue LED sind dauernd an
Bisher mache ich gar nichts mit den LEDs, ist aber geplant. Läuft vielleicht irgendwo noch das Python Wake-Word Tool im Hintergrund or lädt irgendwas beim Booten? Das hat die nämlich benutzt.
Gerätesteuerung & LocalSite: Android und sepia-client sind dem livingroom zugewiesen ...
Kannst du die Fragen bitte in zwei neue Issues kopieren, eins zur Smart Home Steuerung und eins zur STT Engine :-)
Ich kann mich aber mit keinem Client zum CLEXI Server verbinden, weder über Android noch über den Browser. Ich habe es mit dem Admin und mit meinem User versucht aber alles ohne Erfolg. [...] Das "Pünktchen" im Client bleibt immer rot. Wenn ich clexi-123 als ID rausnehme wird er immerhin schon mal gelb.
Ich bräuchte noch ein paar Infos zum Setup. Wo läuft der CLEXI Server? Kommst du vom Handy Browser auch auf die Test-Seite? Gibt es noch irgendwo eine Fehlermeldung?
Zudem habe ich mal noch eine Frage zum "always on" Modus. Das Mikrofon bleibt dabei aber nicht aktiv oder? Ich kann mein Tablet anschreien wie ich will aber Sepia bleibt davon unbeeindruckt. Ich muss aktiv auf den Butten drücken oder?
"Always-On" bezieht sich ursprünglich auf die App, da in diesem Modus der Bildschirm vereinfacht dargestellt wird, stromsparender läuft (auf OLED Screens) und das Display sich nicht selber ausschaltet. Das Mikrofon ist davon nicht beeinflusst. Für die "Wake-Word" Erkennung gibt es in den Einstellungen den Bereich "Hey SEPIA" (siehe auch die Diskussion weiter oben in diesem Issue ^^).
@fquirin, danke für deine schnelle Antwort. Clexi läuft auf dem selben Raspi 3b+ auf dem auch Sepia läuft. Ja ich komme vom Handy Browser aus auf die Clexi Testseite. Kann es sein das ws:// für websocket und wss:// für websocket secure oder sowas steht? Auf dem Android Client habe ich es mit ws://xxx.xxx.x.xx:9090 und clexi-123 zum laufen gekriegt aber wenn ich im "Admin Center" bei Client Connections ws://... eingebe sagt er dierkt "CLEXI error: The operation is insecure." Wenn ich aber wss://... schreibe versucht er sich zu connecten und spuckt folgende Meldung aus "CLEXI closed. Reason: 1015". Wie gesagt, Clexi läuft aber ohne SSL Zertifikat.
Und nochmal zum Allways On Modus... ich habe es gerade nochmal versucht aber ich kann brüllen wie ich will, Sepia lässt die Augen zu. Wenn ich das in den Wake Word Einstellungen einstellen will, fängt es da schon an das ich schreien muss und mir das Gerät etwa 10cm vor mein Gesicht halten muss bis er mich überhaupt hört. Egal wie sensibel ich es einstelle. Hier habe ich auch festgestellt das sich die Sensibilität immer von selbst wieder verstellt. Ich gebe 1.0 ein und wenn ich das nächste mal in die Einstellung gehe steht mal 1.000875767 oder 0.1000076634 oder sowas drin. Getestet habe ich das mit meinem SHIELD Tablet und mit meinem Sony XZ1 Compact... bei meinem alten SHIELD könnte ich es noch verstehen wenn er mich schlecht hört aber nicht beim Handy.
Hast du da noch einen Tipp oder bin ich einfach zu blöd?
Danke und Gruß
Kann es sein das ws:// für websocket und wss:// für websocket secure oder sowas steht?
Ja genau, analog zu HTTP und HTTPS. Ich glaube das Problem hier ist, dass du den Control HUB ("Admin Center") über HTTPS lädst und WS dann geblockt wird wegen "Mixed Content", sprich er will im sicheren HTTPS Context keine unsichere WS Verbinung haben.
Wo kommt denn die HTTPS Adresse für den HUB her? Ich würde empfehlen die HUB Seite einfach ohne HTTPS zu öffnen, z.B. indem du direkt auf den Server gehst ohne Umwege, z.B. http://[IP-von-SEPIA]:20721/tools/index.html
oder z.B. http://raspberrypi.local:20721/tools/index.html
falls dein RPi so heißt. Im lokalen Netzwerk sollte die erreichbar sein und da ist ein SSL Zertifikat auch nicht so kritisch.
Und nochmal zum Allways On Modus... ich habe es gerade nochmal versucht aber ich kann brüllen wie ich will, Sepia lässt die Augen zu. Wenn ich das in den Wake Word Einstellungen einstellen will, fängt es da schon an das ich schreien muss und mir das Gerät etwa 10cm vor mein Gesicht halten muss bis er mich überhaupt hört.
Hm komisch, das hört sich fast so an als wäre das Mikrofon auf den Nahbereich eingestellt und nicht auf Freisprechen ... falls es sowas überhaupt gibt (auswählen kann man das nicht). Hast du vielleicht ein Bluetooth Gerät angeschlossen am Handy? Kannst du es alternativ mal mit einem Headset probieren bzw. Kopfhörern + Mic (manche Handys liefern sowas ja mit). Welche Android Version(en) ist/sind da drauf? Klappt die Spracherkennung denn gut wenn du selber den Button drückst? Oder ist die Qualität da auch eher schlecht?
@fquirin, als erstes muss ich dir einfach nochmal Honig um den Bart schmieren. Du bist wahrscheinlich der beste Programierer den ich je kennengelernt habe. Und ich kenne viele. ;-) Habe noch keinen erlebt der so hinter seinem Produkt steht. Und ich dachte damals schon "snips" wird das ganz große Ding.
Und jetzt zum "Problem". Das mit dem "Mixedmode" kam mit gestern dann auch noch in den Sinn und ich werde es testen. Generell verwende ich die https Geschichte mit deinem nginx Proxy um im Browser das Mic zu nutzen. Aber du hasst recht für den HUB sollte auch http reichen. Werde ich gleich testen.
Das mit dem Wake Word ist so eine Sache. Versteh mich da nicht falsch, sprechen generell funktioniert sehr gut. Ich kann mein Handy ganz normal neben mir liegen haben, drücke den Button und kann ganz normal sprechen und werde auch super gehört. Nur eben das mit dem Wake Word klappt überhaupt nicht. Das mit dem Headset werde ich mal noch probieren und geb dir dann Input.
EDIT:
Ergebnisse zu den Tests. Ja ohne https läuft es nun und ich kann die Clients remote ansprechen.
Habe mich jetzt nochmal mit dem Wake Word beschäfftigt und ich denke ich habe es nun hinbekommen. Mein Gerät liegt neben mir und ist im always on mode und es funktioniert. ABER, hier muss ich mich meinem Vorredner anschließen, die Wake Word Erkennung funktioniert zu selten. Das erklärt warum ich brüllen konnte wie ich wollte. :D Und ich habe festgestellt das ich in einer bestimmten Tonlage mit ihr sprechen muss damit sie auf mich reagiert. Ein bischen zickig die gute. ;-)
Ich bastel jetzt am Headless Client weiter mal schauen wie es da läuft.
@Smarthome-Creator , danke für die motivierenden Worte! 😃 SEPIA ist ein Projekt aus Leidenschaft und ich hoffe die Leute werden Spaß damit haben 😊.
Das mit dem Wake Word ist so eine Sache. Versteh mich da nicht falsch, sprechen generell funktioniert sehr gut. [...] Nur eben das mit dem Wake Word klappt überhaupt nicht. Das mit dem Headset werde ich mal noch probieren und geb dir dann Input.
Die Erfahrungen mit dem Wake Word sind leider sehr durchwachsen, das stimmt schon. Ich habe diverse Systeme getestet und alles erlebt von "sehr solide" bis "unbrauchbar". Mein Samsung A3 Handy z.B. oder mein iPhone 6 funktionieren fast gar nicht, mein Samsung S10e funktioniert prima in 1-2m. Der ReSpeaker funktioniert okay bei Entfernungen bis ca 1m und meine 2 USB Mikrofone laufen im ganzen Wohnzimmer hinreichend gut. Zufriedenstellend ist das alles nicht 100%, weshalb ich auch immer wieder zusätzliche Optionen bastle wie den Bluetooth Trigger (Samsung Watch/Microbit) oder den HTTP Trigger (bastle noch an einer mini App dafür). Parallel beobachte ich immer alle Entwicklungen der Open-Source Community um bessere Lösungen zu finden :-)
Grüße, Florian
Ich denke bei Smartphones oder Tablets wirst du tatsächlich nicht um ein Bluetooth Mic drumrumkommen das irgendwie auch noch gut funktioniert. Ich hatte hier schon diverse JBL Lautsprecher im Auge, bin letztlich aber immer dran gescheitert das die Mic´s eben keine Fernfeldmikrofone sind.
Wie schon angesprochen ist der Respeaker Core V2 wahrscheinlich eine gute Basis. Der hat 8 Mic´s und wurde mit Distanzen bis zu 16m getestet. Ich selbst konnte ihn schon erfolgreich mit bis zu 5 Metern testen.
Derzeit scheitere ich allerdings daran den Headless Client an meinen Clexi Server anzubinden. Ich weiß nicht genau was ich die settings.js eintragen muss um zu meinem Server zu connecten. Ich musste mir das selber zusammenbasteln da du ja derzeit nur den Raspi unterstützt. Läuft auch soweit, nur eben die Anbindung zum Server scheitert noch.
Ich denke bei Smartphones oder Tablets wirst du tatsächlich nicht um ein Bluetooth Mic drumrumkommen das irgendwie auch noch gut funktioniert [...]
Ich werde bei Gelegenheit mal eine Liste anfangen mit getesteter Hardware ^^. Spannend finde ich auch das ReSpeaker USB Mic Array für den DIY Client, hab aber noch keins in die Finger bekommen ;-)
Derzeit scheitere ich allerdings daran den Headless Client an meinen Clexi Server anzubinden. Ich weiß nicht genau was ich die settings.js eintragen muss um zu meinem Server zu connecten.
Den SEPIA Server kannst du über das Setup Skript eintragen ~/sepia-client/setup.sh
(bash) oder direkt in die ~/clexi/www/sepia/settings.js
bei "host-name": "[SEPIA-Server-IP]"
. Der Wert kann z.B. die IP deines SEPIA Servers sein (falls er auf den Standard Ports 20721, ... läuft) oder das, was du beim Login in deine Android App eingegeben hast. Wenn du eine HTTPS Adresse benutzt (z.B. 'example.com/sepia' oder 'https://my-domain.local:20726/sepia' etc.) musst du wieder darauf achten, dass du keine mixed-content Probleme bekommst. In der Standard Konfiguration läuft der Client vom CLEXI Server aus via 'localhost', da solltest du keine Probleme kriegen eigentlich.
Was hattest du schon versucht?
Hallo Florian,
also ich bekomme die Anbindung einfach nicht zum laufen. Habe nochmal verschiedene IP Varianten durchprobiert, ganz simpel ohne https und so wie ich es in der Android App eingestellt habe. Kannst du mir in kurzen Stichpunkten erklären mit welchen Komponenten der headless mode läuft?
Ich habe auf dem respeaker zum Beispiel das Problem das der Chromium nicht startet und ich bei Linux noch nicht rausgefunden habe wie ich den Chromium z.B. ohne Hardwarebeschleunigung starten kann (da fehlt es mir an Programmierkenntnissen), um dann zu hoffen das er startet. Ich kann halt leider auch nicht nachvollziehen ob irgendwo Fehlerlogs ausgespuckt werden, da dein run.sh Skript sauber und ohne Fehlermeldungen startet.
Also nur kurz erklärt wie der headless mode denn läuft damit ich eventuell nach Fehlerursachen suchen kann.
Soll ich vielleicht auch mal einen neuen Issue dazu aufmachen?
Danke und Gruß
Dieses Issue behandelt eh schon sehr viele Themen und ist komplett in Deutsch da können wir auch hier bleiben ... zumal es ja auch "diverse Einrichtungsprobleme" heißt und deine Frage ein spezielles Setup betrifft ;-)
Also hier eine kurze Skizze zum Setup:
~/clexi/www/sepia
) und bildet gleichzeitig die Schnittstelle zum 'Remote Terminal' (aka 'Client Connections' im SEPIA HUB) via WebSocket Verbindung. Er ist außerdem die Schnittstelle zum OS und dessen Bluetooth Funktionen. CLEXI muss als 'hostname' localhost
benutzen, damit der Client von http://localhost:8080/sepia/index.html
geladen werden kann (secure context).ws://[hostname-oder-IP]:9090/clexi
im lokalen Netzwerk bereitzustellen. Die SEPIA Nginx Config leitet dazu den Pfad '/clexi' auf Port 9090 um auf 'localhost:8080'. Das ist im Grunde nur wichtig wenn man im SEPIA Control HUB die 'Client Connections' benutzt.http://localhost:8080/sepia/index.html
geladen wird (s.o.). Die run.sh
in ~/sepia-client/
führt diesen Befehl auf verschiedene Weisen mit diversen Chromium Flags und URL Parametern aus, je nachdem, wie der 'headless' Modus eingestellt ist. Standardmäßig sollte isHeadless=1
gesetzt sein.isHeadless=1
läuft der SEPIA Client ohne Display. Dazu wird das Package Xvfb
benötigt (siehe ebenfalls run.sh
für den Startbefehl)isHeadless=0
und isHeadless=2
wird das Display benutzt. Dazu verwendet das System Openbox
als XServer.isHeadless=1
oder isHeadless=2
gestartet geht er automatisch in den "Setup" Modus, falls kein aktiver Login besteht und nutzt dann die Daten aus ~/clexi/www/sepia/settings.js
zur Herstellung der Verbindung mit CLEXI (Einstellung "clexiSocketURI"
) und ggf. dem SEPIA Server (Einstellung "host-name"
)Danke dir, dann werde ich mal noch ein wenig basteln. Gruß
@xyzaxyz Ich habe gerade mal ein paar Tests zu diesem Punkt gemacht:
"Licht an" - führt korrekt zur Abfrage, welches Licht geschalten werden soll - "Wohnzimmerlicht an", "Licht im Wohnzimmer an" oder "Wohnzimmerlicht im Wohnzimmer an" führen bei den livingroom-clients aber immer zur Abfrage, welches ich meine.
Kannst du mir noch mal sagen wie genau dein Gerät heißt im SEPIA Control HUB? "Wohnzimmerlicht" als Name erkennt er in v2.4.1 (aktueller Release) noch nicht richtig, in meiner Dev Version (v2.5.0) geht es aber scheinbar.
@fquirin ,
hallo, ich habe dein Installationsskript nun soweit angepasst das es auf meinem System alles installiert und am Ende keine Fehler auswirft. Am Ende der Installation steht ja dann das man einen reboot machen soll und nach dem Neustart dann zwei Stimmen zu hören sein sollen. Hier scheitert es bei mir aber noch, daher die einfache Frage: Kannst du mir sagen was nach dem Neustart dann passiert? Muss ich noch irgendwo etwas ind den Autostart basteln oder muss irgendein Skript automatisch starten? Du würdest mir da sehr weiterhelfen, da ich zu etwa 85% bei der Lösung bin und hoffe das ich den Smart Speaker nun zum laufen kriege. Danke und Gruß
hallo, ich habe dein Installationsskript nun soweit angepasst das es auf meinem System alles installiert und am Ende keine Fehler auswirft.
nice :-)
Kannst du mir sagen was nach dem Neustart dann passiert? Muss ich noch irgendwo etwas ind den Autostart basteln oder muss irgendein Skript automatisch starten?
In der Standardkonfiguration wird beim Login des Linux Users entweder das Skript "$HOME/sepia-client/run.sh"
ausgeführt ('headless' mode 1) oder der XServer gestartet startx
('headless modes 0 und 2). startx
triggert nach Start des XServers das Openbox Skript, was am Ende wiederum "$HOME/sepia-client/run.sh"
ausführt.
Ich habe vor ein paar Tage ein neues "on-login" Skript gemacht, ist noch nicht im Dev Branch, wird aber so aussehen:
#!/bin/bash
# SEPIA-Client auto-start on (non SSH) login
if [[ ! $DISPLAY && $XDG_VTNR -eq 1 ]]; then
client_run_script="$HOME/sepia-client/run.sh"
if [ -z $(cat "$client_run_script" | grep is_headless=1) ]; then
exec startx
else
bash $client_run_script login
fi
fi
@fquirin ,
und ich nochmal. Ich habe jetzt noch ein wenig gebastelt und gefummelt und ich vermute dass das run Skript bei mir noch nicht ganz greift, da ich im ps ax weder xvfb noch chromium angezigt bekomme. Wenn ich das Skript händisch starte sieht die Ausgabe bei mir wie folgt aus:
Starting CLEXI server RPi model: RK3229 ReSpeaker Board V1.0 - Is Pi4: 0 Running SEPIA-Client in 'headless' mode. Use SEPIA Control-HUB to connect and control via remote terminal, default URL is: ws://[IP]:9090/clexi
In dem Skript konnte ich irgendwie herauslesen das "Is Pi4: 0" bedeutet das er im Displaymodus startet, kann das sein? aber er soll ja im headless Modus starten. Kann ich das irgenwie erzwingen? Ich habe es mit der setup.sh bereits auf headless gestellt aber das greift anscheinend nicht. Zudem erscheint mir die Ausgabe nach ausführen des Skripts auch etwas kurz oder muss das so?
Danke und Gruß
In dem Skript konnte ich irgendwie herauslesen das "Is Pi4: 0" bedeutet das er im Displaymodus startet
Ne, das wird eigentlich nur gesetzt, wenn er den Pi4 erkennt (=1) um dann im headless mode einen zusätzlichen Flag für den Chromium zu nutzen.
Für den Modus ist die Variable is_headless
zuständig (1=kein Display, 0=Display ohne Setup, 2=Display mit Setup (pseudo-headless)), die auch über das setup.sh Skript eingestellt werden kann.
Zudem erscheint mir die Ausgabe nach ausführen des Skripts auch etwas kurz oder muss das so?
Ja, das ist normal weil die Log Datei eigentlich die ~/clexi/log.out
ist. Guck mal da rein ob er vielleicht abbricht.
Vielleicht mal testen ob Xvfb und Chromium überhaupt starten können: xvfb-run -n 2072 chromium-browser
.
RK3229 ReSpeaker Board V1.0
Cool, ist das der ReSpeaker mit SBC dran und dem v2.0 Array? :-)
Also clexi startet sauber und im log stehen keine Fehler. Die clexi Testseite funktioniert auch. Dann habe ich xvfb.... händisch gestartet was zu folgender Ausgabe führt:
[2879:2879:0403/205505.628213:ERROR:edid_parser.cc(102)] Too short EDID data: manufacturer id [2917:2917:0403/205509.112644:ERROR:sandbox_linux.cc(374)] InitializeSandbox() called with multiple threads in process gpu-process. [2931:7:0403/205509.265654:ERROR:command_buffer_proxy_impl.cc(125)] ContextResult::kTransientFailure: Failed to send GpuChannelMsg_CreateCommandBuffer. [2931:1:0403/205510.250595:ERROR:child_process_sandbox_support_impl_linux.cc(79)] FontService unique font name matching request did not receive a response. [2931:1:0403/205510.252672:ERROR:child_process_sandbox_support_impl_linux.cc(79)] FontService unique font name matching request did not receive a response.
Hier fehlt es mir aber an Hintergrundwissen um zu verstehen was nicht funktioniert. Mit ps ax bekomme ich aber Prozesse angezeigt die ich aber ebenfalls nicht ganz interprettieren kann: 2863 pts/0 S+ 0:00 /bin/sh /usr/bin/xvfb-run -n 2072 chromium 2872 pts/0 Sl+ 0:00 Xvfb :2072 -screen 0 1280x1024x24 -nolisten tcp -auth /tmp/xvfb-run.j3ApS4/Xauthority 2879 pts/0 SLl+ 0:08 /usr/lib/chromium/chromium --show-component-extension-options --enable-gpu-rasterization --no 2894 pts/0 SL+ 0:00 /usr/lib/chromium/chromium --type=zygote 2896 pts/0 S+ 0:00 /usr/lib/chromium/chromium --type=zygote 2917 pts/0 SLl+ 0:05 /usr/lib/chromium/chromium --type=gpu-process --field-trial-handle=5535072851694958726,584517 2921 pts/0 SLl+ 0:01 /usr/lib/chromium/chromium --type=utility --field-trial-handle=5535072851694958726,5845173166 2931 pts/0 Sl+ 0:03 /usr/lib/chromium/chromium --type=renderer --file-url-path-alias=/gen=/usr/lib/chromium/gen - 3029 ? Vielleicht kannst du mir da mehr dazu sagen? Und ich glaube ich muss dein Start Skript händisch zu meinem Login hinzufügen, denn er startet nach dem Reboot nichts.
Wunder dich nicht das da nicht "chromium-browser" steht. Das Packet gibt es nicht mehr, das heißt nur noch "chromium". Das musste ich z.B. auch in deinem Installationsskript anpassen.
Ja das ist der v2.0. Wie gesagt eigentlich eine super Basis aber extrem sensibel, gerade was das Upgrade auf Buster angeht. hier habe ich einige Tests machen müssen bevor ich z.B. Chromium zum laufen bekommen habe und ein vollständiges dist upgrade konnte ich auch noch nicht machen da er sonst z.B. den Displaymanager ändert und man dann nicht mehr zum Desktop booten kann.
Das Ding läuft mit lxqt könnte das vielleicht ein Teil meines Problems sein? Es fehlt mir wirklich nur noch daran das Loginskript für den run.sh Start hinzufriemeln und die xvfb + chromium Geschichte zum starten zu kriegen. Wenn das läuft habe ich es glaube ich geschafft.
EDIT: Und wenn ich das xvfb... mit STRG + C stoppe bekomme ich noch folgende Ausgabe:
[2879:2879:0403/212050.490429:ERROR:chrome_browser_main_extra_parts_x11.cc(62)] X IO error received (X server probably went away) [2917:2917:0403/212050.495331:ERROR:x11_util.cc(109)] X IO error received (X server probably went away)
Die ganzen ERRORS lassen mich noch schwitzen.
Mit ps ax bekomme ich aber Prozesse angezeigt die ich aber ebenfalls nicht ganz interprettieren kann: 2863 pts/0 S+ 0:00 /bin/sh /usr/bin/xvfb-run -n 2072 chromium 2872 pts/0 Sl+ 0:00 Xvfb :2072 -screen 0 1280x1024x24 -nolisten tcp -auth /tmp/xvfb-run.j3ApS4/Xauthority
Das sieht eigentlich ok aus. Chromium spuckt in der Konsole immer 1000 Fehler aus, das ist irgendwie "normal" so lange der Browser trotzdem startet :rofl: ... jedenfalls hab ich noch nie eine Installation ohne gesehen ^^. Meistens sind das irgendwelche Module die dann einfach deaktiviert werden. Du könntest noch mal --disable-features=VizDisplayCompositor
als Flag testen und gucken ob dann zumindest GPU Fehler verschwinden (das nutze ich auf dem RPi4).
Vielleicht kannst du mir da mehr dazu sagen?
Chromium hat diverse Sachen, die parallel laufen, das meiste verstehe ich auch nicht ganz, aber wichtig ist, dass Xvfb dir einen screen anzeigt und dass Chromium aktiv zu sein scheint, sonst wären alle Prozesse automatisch wieder weg.
Und ich glaube ich muss dein Start Skript händisch zu meinem Login hinzufügen, denn er startet nach dem Reboot nichts.
Bei der Standardinstallation hängt sich das Skript in die ~/.bashrc und versucht das "on-login" Skript von weiter oben auszuführen.
Wunder dich nicht das da nicht "chromium-browser" steht. Das Packet gibt es nicht mehr, das heißt nur noch "chromium". Das musste ich z.B. auch in deinem Installationsskript anpassen.
Ja, das scheint eine Eigenart vom Raspbian zu sein (und ein paar anderen Linux Systemen) :thinking:
Ja das ist der v2.0. Wie gesagt eigentlich eine super Basis aber [...]
Solche Probleme scheinen mir symptomatisch zu sein für alle SBCs abseits vom RPi. Mein Odroid ist auch so zickig :-/
Das Ding läuft mit lxqt könnte das vielleicht ein Teil meines Problems sein?
Das könnte in Konflikt mit Openbox stehen, was aber im "headless" Modus (is_headless=1) gar nicht benutzt wird.
Ich habe das Gefühl Xvfb + Chromium scheint schon zu starten irgendwie. Versuch doch mal aus dem run.sh
Skript in ~/sepia-client
das >/dev/null 2>&1
am Ende der 'xvfb-run' Zeilen rauszunehmen und es dann zu starten. Dann müsste er eigentlich ein paar mehr Sachen zeigen, eventuell auch LOG outs von der SEPIA web-app.
Und wenn ich das xvfb... mit STRG + C stoppe bekomme ich noch folgende Ausgabe: [...]
Das scheint mir logisch, vermutlich terminiert Xvfb vor Chromium oder wartet nicht darauf, dass Chromium ordentlich beendet wird und Chromium fehlt dann der (virtuelle) X-server.
@fquirin, Es ist langsam echt zum Haare raufen. Punkt 1: Bei ~/.bashrc steht dein run Skript mit drin, wird aber nicht gestartet. Soll aber mal nicht dein Problem sein. ;-) Punkt 2: Mir ist aufgefallen das wenn ich das run Skript starte clexi gestartet wird aber chromium nicht. In dem Skript konnte ich lesen das er sich irgendwelche Daten aus dem Ordner /sepia-client/chromium zieht. Der ist bei mir aber leer. Ich vermute ich muss hier meinen eigenen Chromiumpfad angeben?
Danke und Gruß
In dem Skript konnte ich lesen das er sich irgendwelche Daten aus dem Ordner /sepia-client/chromium zieht. Der ist bei mir aber leer. Ich vermute ich muss hier meinen eigenen Chromiumpfad angeben?
Das ~/sepia-client/run.sh
Skript startet Chromium mit dem Verweise auf den Ordner via --user-data-dir=$chromedatadir
(die Variable wird vorher definiert). Der Ordner wird beim ersten Start von Chromium mit dem Flag angelegt und beim zweiten Start dann modifiziert. Falls der also nicht existiert bei dir müsste er eigentlich beim erfolgreichen Chromium Start auftauchen :thinking:
Es ist wichtig, dass dieser Ordner benutzt wird (bzw der Ordner der der Variable entspricht), da die Daten darin angepasst werden um einige Chromium Einstellungen zu setzen.
Wurde der Ordner bisher nie erzeugt, bei keinem Start via Skript?
@fquirin , danke für deine Geduld und dein fungiertes Wissen über dein Projekt. Manchmal ist man aber auch echt vernagelt. :D Ich habe den Fehler schon vor Tagen gefunden aber nicht in deinem run.sh Skript geändert. Wie schon weiter oben angesprochen heißt das Paket bei mir nicht chromium-browser sondern nur chromium. Geändert, ausgeführt und er startet alles wie es soll. Ich habe zwar "ready 4 setup" noch nicht gehört aber ich werde mich jetzt an der Konfiguration über Clexi versuchen. Wenn am Ende alles läuft kannst du den respeaker als getestet und funktionsfähig listen.
Gruß
Ich habe zwar "ready 4 setup" noch nicht gehört aber ich werde mich jetzt an der Konfiguration über Clexi versuchen
Ich hoffe das ist kein Problem mit dem Audio System :crossed_fingers:
Wenn am Ende alles läuft kannst du den respeaker als getestet und funktionsfähig listen.
Das wäre super :slightly_smiling_face: . Das ist dieser hier oder: https://www.seeedstudio.com/ReSpeaker-Core-v2-0.html
Das ist dieser hier oder: https://www.seeedstudio.com/ReSpeaker-Core-v2-0.html Ja das ist er.
Also ich komme mit der Clexieinrichtung keinen Meter vorwärts. Clexi Server auf dem Client läuft und ich kann mich verbinden. Ab da ist dann aber auch Ende. Ich bekomme beim ausführen des run Skripts nur die erste Stimme zu hören und dann bleibt er stumm. Was vielleicht noch nicht ganz so tragisch ist wenn ich wenigsten wüsste wie die Verbindung zwischen dem Client und dem Server zustande kommen soll.
Ich bin deine Anleitung 1000x durchgegangen aber mir erschließt sich nicht wie mein Headlessclient Verbindung mit dem Server herstellen soll. Ich habe als Hostnamen alles an Schreibweisen eingetragen die ich bei den Clients nutze, z.B: 192.168.0.... oder http://192.168.0.... oder https://...
Nichts davon funktioniert das ich irgendwie darauf schließen könnte das der Client zu irgendeinem Teil meines Sepia Servers kommt. Weißt du was ich meine? In den Apps trage ich ja den Clexi Websocket erst ein wenn ich in der App eingeloggt bin und dann kann ich vom Server aus alles anpingen und bekomme meine Antworten. Deswegen kann ich absolut nicht verstehen wie ich den Headlessclient einrichten soll wenn er doch gar nicht weiß wo er hin soll. Was mache ich falsch?
Also das ganze ist so gedacht:
~\clexi\www\sepia\settings.js
steht der CLEXI Server mit dem sich der "headless" Client verbinden soll (normalerweise: ws://localhost:8080
). (Dort steht auch der SEPIA Server Host, aber der ist erstmal nicht wichtig).isHeadless=true
starten, siehe ~/sepia-client/run.sh
(falls du was an den Chromium Zeilen geändert hast).Falls dein Chromium aktiv ist, die richtige SEPIA Client URL mit "isHeadless" Parameter aufgerufen wird und dann nichts passiert heißt es entweder der Client startet nicht richtig oder er ist bereits eingeloggt und kommt deshalb nicht ins Setup (was vermutlich eher nicht der Fall ist). Theoretisch möglich wäre auch, dass der Sound Output nicht geht, der Client sich aber versucht mit CLEXI zu verbinden und das scheitert dann irgendwie. Unglücklicherweise kommt man nicht so leicht an die Chromium Logs sobald der im Xvfb läuft (habe noch keinen Weg gefunden :-/).
Ich bin deine Anleitung 1000x durchgegangen aber mir erschließt sich nicht wie mein Headlessclient Verbindung mit dem Server herstellen soll. Ich habe als Hostnamen alles an Schreibweisen eingetragen die ich bei den Clients nutze, z.B: 192.168.0.... oder http://192.168.0.... oder https://...
Alle Schreibweisen müssten funktionieren wenn sie in anderen Clients funktionieren ;-) Ich benutze ganz gerne einfach die IP des Servers. Der SEPIA Server wird aber erst relevant wenn du dich via CLEXI mit dem Client verbinden kannst.
Wie weit weg von der Standard-Konfiguration bist du denn gerade? Bzw. was musstest du eigentlich ändern an den Installationsskripten?
Grüß dich, ich bin bis jetzt kein bisschen von deiner Standardkonfig abgewichen um so wenig wie möglich an Problemen zu bekommen. Einzig chromium-browser zu chromium musste ich ändern im install und run Skript. Aber vielleicht sehen vier Augen auch einfach mehr als zwei.
Sepia Clexi settings.js: device: { "host-name": "https://192.168.0.55:20726/sepia", URL meines Sepia Servers wie ich ihn bei den Clients eintrage? Https ist nur als Bsp.
"deviceId": "S1", Die deviceID meines "SmartSpeakers"?
user: { "clexiSocketURI": "ws://192.168.0.55:9090", Die IP meines Clexi Servers so wie ich sie auch in den Cients eintrage?
"clexiServerId": "clexi-123" Hier bin ich mir nicht sicher was da rein soll. Die clexiServerId ist doch nicht gleichzeitig die clexiId? Wie kann ich die serverID herausfinden?
Im run Skript nur als Beispiel:
sed -i 's/"notifications":{}/"notifications":{"http:\/\/localhost:8080, muss ich hier gegebenfalls meine eigenen URL´s eintragen?
Ebenso in:
--kiosk 'http://localhost:8080/sepia/index.html?isApp=true&isHeadless=true' ?
Ich glaube soweit ist alles i.O. Ich habe aber die Vermutung dass das run Skript nicht alles an den Stellen ändert an denen es etwas ändern sollte. Das liegt denke ich nicht an deinem Skript sondern einfach an meinem etwas anderem System. Ich bin sicher das es wohl nur noch an den IP Adressen und oder URL´s liegt.
Gruß
"host-name": "https://192.168.0.55:20726/sepia", URL meines Sepia Servers wie ich ihn bei den Clients eintrage?
Ja das sollte passen, falls die Ports offen sind (20721) wäre "host-name": "192.168.0.55"
die sichere Variante, das würde eventuelle Probleme mit HTTPS und dem Proxy ausschließen.
"deviceId": "S1", Die deviceID meines "SmartSpeakers"?
Die Device-ID ist eine frei wählbare ID, hauptsächlich gedacht um Client Logins auf verschiedenen Geräten mit dem selben Account zu managen. Man sollte die ID allerdings so kurz und einfach wie möglich halten, ich gehe normal nicht über 3 Zeichen, keine Leerstellen, keine Sonderzeichen.
"clexiSocketURI": "ws://192.168.0.55:9090", Die IP meines Clexi Servers so wie ich sie auch in den Cients eintrage?
Ich glaube hier ist der Casus knacksus. Der CLEXI Server läuft normal auf localhost:8080
und der Proxy zeigt via [hostname]:9090/clexi
auf den localhost. Das ist so gemacht damit das Remote Terminal von anderen Rechnern via ws://[ip-or-host]:9090/clexi
auf den CLEXI Server kommt während der SEPIA Client lokal ws://localhost:8080
nutzen kann. Wenn in den CLEXI Settings (~/clexi/settings.json) etwas anderes steht als "hostname": "localhost"
und "port": 8080
geht eine ganze Kaskade von Problemen los, siehe z.B. https://github.com/SEPIA-Framework/sepia-docs/issues/25 .
Im run Skript nur als Beispiel: sed -i 's/"notifications":{}/"notifications":{"http://localhost:8080, muss ich hier gegebenfalls meine eigenen URL´s eintragen? [...] Ebenso in: [...] --kiosk 'http://localhost:8080/sepia/index.html?isApp=true&isHeadless=true' ?
So lange der CLEXI Server auf localhost:8080
läuft ist das genau richtig. Wenn daran was geändert wurde gehen die oben angesprochenen Probleme los ^^.
Ich hoffe das hilft weiter :-)
Es kommt ein wenig Freude auf!☺ Ich bekomme nun ready 4 setup zu hören. 👍 Das bedeutet doch im Umkehrschluss das mein Client jetzt Verbindung zu meinem Server aufnimmt... oder? Da er sich ja automatisch mit dem Setup User einloggt... richtig?
yeah :grin:
Das bedeutet doch im Umkehrschluss das mein Client jetzt Verbindung zu meinem Server aufnimmt
Wenn du mit "meinem Server" den SEPIA Server meinst (nicht den CLEXI Server), dann nein ;-) Zunächst mal wird die Verbindung zum Remote Terminal hergestellt (via CLEXI). Die Verbindung zum SEPIA Server wird dann im nächsten Schritt über den Login Befehl des Remote Terminals hergestellt.
Der Setup "User" ist im Grunde das gleiche wie der Demo "User" (wenn man beim Login auf 'weiter ohne Login' drückt), quasi ein "fake" Login damit der Client funktional wird und die Settings.js einliest (und sich dann mit CLEXI verbindet).
Grüß dich nochmal. Ich glaube wir reden mittlerweile etwas aneinander vorbei. Ich versuche es mal genauer auszudrücken. Ich will wissen wann sich der Clexi Headless Client mit meinem Clexi Server verbindet mit dem ich ja die Clients anspreche. In deiner Einrichtungsanleitung für den Client schreibst du: Use the remote terminal to ping all connected clients by typing ping all or use the shortcut button right above the terminal input field Your SEPIA Client should answer with client info, device ID and a short message. Und im Step davor soll man sich mit dem Clexi Websocket des Headless Clients verbinden. Ich kann doch aber nichts anpingen was nirgends miteinander verbunden ist. Ich stecke jetzt quasi im login Modus fest weil ich nicht weiß mit welchem Websocket ich mich verbinden soll und wie dann der Login funktionieren soll.
Deswegen nochmal, damit wir uns nicht falsch verstehen. Clexi Client aka "Headless" und Clexi Remoteserver. Daher nochmal die Frage, was soll ich hier in der settings.js eintragen:
user: { "clexiSocketURI": "ws://Welchen Websocket soll man hier eintragen? Vom Client oder vom Remotserver?" "clexiServerId": "Was soll hier rein? Die ServerID vom Clexi Client oder vom Remoteserver?"
Denn laut deiner Anleitung soll ich mich vom Remoteterminal aus mit der deviceID des Headless Clients auf dem Cleint einloggen. Aber... das kann ja gar nicht funktionieren wenn der Clexi Client nicht mit Clexi Remoteserver verbunden ist. Ich blicke leider nicht mehr durch was ich wo eintragen und wie ich die beiden miteinander Verbinden soll. :-( I need your help again.
Ich meine deine Einstellungen waren eigentlich schon korrekt :sweat_smile:
im Step davor soll man sich mit dem Clexi Websocket des Headless Clients verbinden. Ich kann doch aber nichts anpingen was nirgends miteinander verbunden ist.
Das Remote Terminal verbindet sich ebenso wie der SEPIA Client mit dem CLEXI Server, damit man den Client steuern kann. Das läuft quasi komplett parallel zum SEPIA Server.
ich nicht weiß mit welchem Websocket ich mich verbinden soll und wie dann der Login funktionieren soll
Über den Control HUB verbindet man sich mit dem CLEXI WebSocket Server via ws://[CLEXI-IP-ODER-HOST]:9090/clexi
(immer vorausgesetzt am Proxy wurde nichts geändert).
Der SEPIA Client verbindet sich ebenfalls mit CLEXI. Theoretisch könnte er dazu die URI von oben nutzen aber weil beide auf dem selben Rechner laufen steht in der Settings normalerweise "clexiSocketURI": "ws://localhost:8080"
.
Also Control HUB auf CLEXI und Client auf CLEXI. Dann muss der Client nach "Ready for setup" auf den Ping request antworten und man kann den Login befehl für den SEPIA Server eingeben. Alle Adressen des SEPIA Servers sind in der settings.js über "host-name": "192.168.0.55"
definiert. Der Client weiß dann selber, dass z.B. 192.168.0.55:20721 der Assist-Server und 192.168.0.55:20723 der Chat-Server (aka WebSocket Server 2) von SEPIA ist.
Es ist manchmal etwas beänstigend aber kaum das du mir geschrieben hast das eigentlich alles richtig eingestellt ist, funktioniert es auf einmal. :D Du bist top. 👍
Danke für deine Geduld.
Freut mich, dass es endlich läuft :-)
Im Endeffekt wurde also nur das Chromium package und die entsprechenden chromium-browser
Einträge geändert? Welches OS läuft eigentlich auf dem ReSpeaker?
Ja ich musste nur im install und im run Skript von chromium-browser zu chromium umschreiben und dann funktioniert das reibungslos. Wir haben nur so lange für die Lösung gebraucht weil wir tatsächlich etwas aneinander vorbei geredet haben. Letztlich war der Knackpunkt wirklich der Websocketeintrag vom Clexi.
Der Respeaker wird mit einem angepassten Android oder Debian 9 ausgeliefert. Ich hatte es mit deiner App auf dem Android versucht aber das ist zu oft abgestürzt, weil das Android schon sehr stark von seeed angepasst ist. Bei dem Debian 9 startet z.B. der Chrome nicht und deswegen habe ich ein Teilupgrade auf Buster gemacht. Auf dem 9er habe ich allerdings dein install und run Skript noch nicht versucht aber das werde ich mal noch nachholen.
Ich habe nun schon einiges an Tests gemacht und habe da leider noch hauptsächlich mit der Sprache Probleme festgestellt. Soll ich mal einen neuen Issue dazu aufmachen mit Dingen die verbessert und eventuell noch hinzugefügt werden sollten? So als kleine ToDo Liste?
Ich habe mal die Vermutung das die ASR (Zamia, Kaldi usw.) Geschichte für eine bessere Spracherkennung und Sprachausgabe zuständig ist oder? Und ich habe auch gesehen das du bei goofy/zamia ins Forum geschrieben hast und du an der Sache dranbleibst. Dann würde ich damit mal noch etwas rumexperimentieren und vielleicht geht dann das ein oder andere Problem auch von selbst.
Das größte Problem das ich bis jetzt ausmachen konnte ist nach wie vor die Wake Word Erkennung. Wenn ich das Mic über Clexi triggere werde ich gut verstanden aber er versteht eben nicht genau was ich sage, was ich jetzt mal auf die STT Engine schiebe? Das ist mir aufgefallen da ich bestimmt 50x "Hey Sepia" zu sprechen versucht habe und er nicht ein einziges mal "Hey Sepia" verstanden hat. Da kam sowas wie Silvia, gedika, bella und solche Spässchen bei raus.
Von daher denke ich eine ToDo Liste für dich wo du abhaken kannst was du schon machst und was du vielleicht noch machen willst.
Gruß
Ich habe nun schon einiges an Tests gemacht und habe da leider noch hauptsächlich mit der Sprache Probleme festgestellt. Soll ich mal einen neuen Issue dazu aufmachen mit Dingen die verbessert und eventuell noch hinzugefügt werden sollten?
Ja mach das mal. Schreib bitte am Anfang dazu welche STT engine du nutzt (native oder custom) und vielleicht auch noch mal die Hardware :+1:
Ich habe mal die Vermutung das die ASR (Zamia, Kaldi usw.) Geschichte für eine bessere Spracherkennung und Sprachausgabe zuständig ist oder?
Wenn der Client auf "custom" ASR engine steht wird der SEPIA STT Server genutzt, der auf Zamia (Kaldi) basiert. Leider ist das Sprachmodell noch ziemlich wenig optimiert. Man kann gute Ergebnisse erzielen, wenn man die Domain stark verkleinert, dazu gibt es eine (noch etwas umständliche und wenig dokumentierte) LM Adapt Funktion, zu finden im SEPIA Control Hub. Wenn die Client ASR Engine auf "native" steht wird in Chrome Google benutzt, da sollten die Ergebnisse fast perfekt sein, zumindest ist das das Beste was der Markt hergibt. Dummerweise kann man das Sprachmodell nicht anpassen, weshalb er ausgerechnet den Namen "SEPIA" selten richtig erkennt. Der Kontext am Anfang oder Ende eines Satzes stimmt für Google einfach (noch) nicht ^^.
Das Thema ist lang und komplex. Zuletzt hatte ich auch mal Deepspeech getestet über Firefox Nightly, das hat bei mir aber nicht wirklich gut funktioniert. Auch da lässt sich aber noch viel durch das Sprachmodell (LM) erreichen.
Die Tatsache, dass "Hey SEPIA" allerdings so schlecht funktioniert deutet aber irgendwie darauf hin, dass vielleicht das Mikrofon noch nicht optimal eingestellt ist. Spätestens beim 3. versuch klappt es bei mir so gut wie immer. Wenn man länger nichts gesagt hat verschluckt es bei mir oft den ersten Versuch, der zweite klappt dann aber. Ich vermute das liegt an der automatischen Anpassung an Hintergrundgeräusche.
So ich habe nun nochmal den Ein oder anderen Test gemacht und einiges dabei feststellen können.
Wenn man die Zamia ASR einbindet und Custom Stream auswählt dann dauert es tatsächlich recht "lange" bis die Eingabe interprettiert und die Ausgabe generiert wird. So bis zu 5 Sekunden sind hier keine Seltenheit.
Wenn man das deutsche Sprachpaket in die ASR Engine einbindet versteht er leider kein "denglisch". Das ist mir aufgefallen als ich Sepia mit "Starte den Allways on Modus" in den Standby schicken wollte.
Außerdem habe ich noch viele Test´s mit der Wake Word Erkennung gemacht und bin da zu folgenden Ergebnissen gekommen. Ich habe es mit verschiedenen Mikrofonen getestet und das Ergebnis war immer dasselbe. Wenn man Sepia dreisilbig ausspricht und die Betonung auf PI legt also im Sinne von Se - PI - a dann triggert das Mic immer gleich beim ersten mal. Ich vermute das es einfach nur daran liegt das zu viele unterschiedliche Dialekte und Aussprachen das ganze etwas schwierig machen.
Den besten den ich bis jetzt hatte war Edeka als ich ihn mit Hey Sepia ansprechen wollte.
Und am Headless Client weis nicht zufällig jemand wie man die Stimme auf weiblich umstellen kann?
Wenn man die Zamia ASR einbindet und Custom Stream auswählt dann dauert es tatsächlich recht "lange" bis die Eingabe interprettiert und die Ausgabe generiert wird. So bis zu 5 Sekunden sind hier keine Seltenheit.
5s nach Ende der Spracheingabe? Wie lang (s) war die Eingabe ca.? Auf welchem System läuft der Server bei dir? 5s scheint mir etwas zu Lang, 3s ist allerdings nicht unüblich. Da ist auch noch Optimierungspotential. Bisher ist es so, dass die Audiodaten beim Sprechen zum Server gestreamt werden und dann transkribiert. Man kann aber theoretisch schon früher anfangen, das Buffer Handling ist nur kompliziert.
Wenn man das deutsche Sprachpaket in die ASR Engine einbindet versteht er leider kein "denglisch".
Das Sprachmodell ist leider wirklich noch nicht gut optimiert auf den SEPIA Use-Case. Man müsste eigentlich mal anfangen und ca. 100 Sätze speziell für SEPIA aufschreiben, dann prüfen welche Vokabeln fehlen, diese im Wörterbuch von Kaldi ergänzen und dann mal die Domain trainieren. Wenn du Interesse hast da weiter zu experimentieren könnte ich eine Anleitung schreiben dazu (sollte ich eh mal machen :see_no_evil: ).
Ich habe es mit verschiedenen Mikrofonen getestet und das Ergebnis war immer dasselbe. Wenn man Sepia dreisilbig ausspricht und die Betonung auf PI legt also im Sinne von Se - PI - a dann triggert das Mic immer gleich beim ersten mal
Ja das stimmt natürlich. Ich habe bei dem Wort immer diese Aussprache im Kopf, aber das muss natürlich nicht bei Jedem so sein :sweat_smile: . Im Grunde ist es ähnlich wie bei A-Lex-a ;-) Ich würde gerne für die nächste Version wenigstens eine Hand voll Wake-Words anbieten, die Picovoice im GitHub Repo frei verfügbar hat aber die Jungs antworten leider zur Zeit nicht auf meine Anfrage und leider sind sie die Einzigen, die das Format von meiner alten Version konvertieren können :-/ . Im schlimmsten Fall kann ich aber noch ein Skript basteln, was die Dateien austauscht beim DIY Client. Dann wäre zumindest auch "Raspberry" mal zum Testen verfügbar (und theoretisch auch "Alexa" =) ).
Und am Headless Client weis nicht zufällig jemand wie man die Stimme auf weiblich umstellen kann?
Die eSpeak Engine vom SEPIA Server hat leider keine weibliche Stimme zur Zeit und die Plattform selber hat auch nix im Angebot (nicht so wie Windows z.B.). Aber ich habe die Hoffnung MaryTTS noch für die nächste SEPIA Version fertig zu bekommen :-)
Ich habe das Zamia mal testweiße auf meinem alten Netbook installiert. Das kann natürlich schon daran liegen das es auf dem alten Ding einfach etwas länger dauert mit der Berechnung der Ein -/ Ausgabe.
Ich weiß aber nicht ob es sich lohnt das Zamia Projekt weiter zu verfolgen da ist seit mittlerweile 2 Jahren nichts mehr passiert. Es ist auch nach wie vor nicht möglich Zamia aus deren Repo zu installieren das sie einfach den "Apt Key" nicht aktualliesieren. Ich habe so das gefühl das Ding ist "tot".
Ich weiß hier leider nicht was das für ein Programmieraufwand ist aber wäre es eine Möglichkeit wenn du in einer kommenden Version die Möglichkeit anbieten würdest das Wake Word einfach selbst aufzunhemen. Also nicht im Sinne von mein eigenes Wake Word zu verwenden sondern eine Audiodatei aufzunehmen einfach damit Sepia meine Stimme, Aussprache und Dialekt kennenlernt?
Geht sowas überhaupt?
Ich weiß aber nicht ob es sich lohnt das Zamia Projekt weiter zu verfolgen da ist seit mittlerweile 2 Jahren nichts mehr passiert.
Zamia ist im Grunde ein gut angewendetes Kaldi und das Resultat ist im open-source Bereich immer noch das beste was ich kenne. Die Modelle sind zuletzt am 2019-06-09 upgedated worden. Wenn es gute neu Daten gibt macht Günther ab und an was dran. Das Trainieren dauert aber teilweise über 1 Woche, ist also ganz schön aufwendig. Die packages könnte er aber echt mal updaten ^^. Deepspeech von Mozilla ist seit mindestens 2 Jahren die Hoffnung aber kommt nicht aus dem Quark irgendwie. Die angeblich guten Resultate habe ich bisher nie in der Praxis testen können. Es entwickelt sich aber zumindest zu einem user-freundlichen Projekt ^^.
[...]das Wake Word einfach selbst aufzunhemen[...]. Geht sowas überhaupt?
Nur in der Theorie :sweat: . Es gibt kommerzielle Software die sowas kann, z.B. von Sensory. Snow-boy war mal eine Hoffnung, die sind aber weder komplett offen, noch haben mich die Ergebnisse überzeugt. Precise von Mycroft ist auf dem Papier die Lösung, in der Praxis aber braucht man viel zu viele Trainingsdaten und das Ergebnis kann man nicht wirklich gut irgendwo integrieren. Die Qualität des Ergebnisses konnte ich selber auch noch nie testen.
Ja das mit den geupdateten Modellen habe ich gesehen und mir da auch das deutsche runtergeladen und getestet. Ich meinte auch eher die Installation aus den "Repos". Ich würde mir halt schon lieber eine kleine Raspifarm basteln anstatt einen großen Rechner dafür laufen zu lassen. Aber ich sehe schon das du dich ja mit allen "Problemen" auseinander setzt und an den ganzen Sachen dran bist. Von daher, mach weiter so und wir warten sehnsüchtig auf das nächste Update. 👍
Dieser Thread hat mir so viel weitergeholfen und ich habe nun fast alles hinbekommen. Unter Client Connections kann ich die Verbindung zu ws://sepia-home:9090/clexi problemlos aufbauen. Mein sepia-client sagt nach dem start "ready to setup". Nur beim "ping all" bekomme ich keine Antwort.... Was kann ich noch tun?
Broadcaster response: "sent" Broadcaster event: {"broadcast":{"name":"sepia-client","data":{"ping":"all"}}} Broadcaster event: {"broadcast":{"name":"sepia-client","data":{"ping":"all"}}} CLEXI server says welcome. Info: {"version":"CLEXI Node.js server v0.8.2","xtensions":{"clexi-broadcaster":{"active":true},"clexi-http-events":{"active":true},"runtime-commands":{"active":true}}} CLEXI connected CLEXI connecting ...
Hi,
Nur beim "ping all" bekomme ich keine Antwort
Das deutet darauf hin, dass der CLEXI Server funktioniert, aber der Client keine Verbindung damit aufbaut.
Hast du die ~/clexi/www/sepia/settings.js
modifiziert? Oder sonst irgendwas geändert an den Standardeinstellungen?
Die Datei sollte folgende Einträge haben (eventuell mit angepasstem Feld 'clexiServerId'):
"clexiSocketURI": "ws://localhost:8080",
"clexiServerId": "clexi-123",
"clexiConnect": true,
"useRemoteCmdl": true,
Grüße, Florian
Hi Florian,
danke für die schnelle Antwort in einem eigentlich bereits geschlossenen Ticket. Dachte das Thema passt hier jedoch ganz gut dazu, falls in Zukunft außer mir noch jemand den ganzen Thread hier studiert.
Prinzipiell habe ich alles auf Standard gelassen, da es aber nicht funktioniert hatte auch des öfteren mit einzelnen Parametern rumgespielt. Ohne erfolg bis jetzt.
So sieht meine settings.js aus: SepiaFW.settings = { headless: { device: { "host-name": "localhost", "deviceId": "m1", "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/socke$ "useGamepads": true, "useBluetoothBeacons": true, "useBluetoothBeaconsInAoModeOnly": false, "useWakeWord": false, "autoloadWakeWord": false, "allowWakeWordDuringStream": false, "activeSkin": "2", "proactiveNotes": false, "autoGPS": false }, location: { "latitude": "", "longitude": "" }, broadcast: { "state": true, "login": true, "speech": true, "wakeWord": true } } "useWakeWord": false, "autoloadWakeWord": false, "allowWakeWordDuringStream": false };
Viele Grüße Matthias
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!