Autor Thema: SEPIA open-source Sprachassistent: Integration in FHEM?  (Gelesen 12881 mal)

Offline sepia

  • Jr. Member
  • **
  • Beiträge: 68
Antw:SEPIA open-source Sprachassistent: Integration in FHEM?
« Antwort #150 am: 14 Februar 2020, 20:30:57 »
ich nehme mal an ich tausche das isApp=true durch isHeadless=true. Ich probiere es einfach mal aus :-)

"isApp" besser behalten. Der Parameter erzwingt den Status "App" (wer hätte das gedacht) als Gegensatz zu "Website". Die Konsequenz ist, dass der Login nicht nach 1 Tag abläuft sonder das Token glaub 1 Jahr gültig bleibt (wie z.B. in Android etc.).

Also Anwendungsfall wäre ein HTPC mit Win10 der eh läuft, daher wäre dort ebenfalls ein Headless Client was Feines, aber eins nach dem anderen. Nur als gedanken was noch so alles geht :-)

Definitiv erwünscht ^^. In Windows ist alles im Grunde ja ziemlich unproblematisch. Man konfiguriert den Client einfach übers Display (oder Remote Desktop) und packt sich dann ne .bat Datei oder Ähnliches in den Autostart, die den Browser mit "headless" Parameter startet. CLEXI für das "remote Terminal" und sogar Nginx laufen auch in Windows. Das System macht halt nur generell jede Menge Krams im Hintergrund unangekündigt ::)

Jetzt schliesst sich der Kreis, warum ich meinte muss ich alles neu installieren. :-) bzw. ich nicht möchte. (Max2play = Image für Multiroom mittels squeezelite) Basiert auf dem Logitech Musik Server.
Den squeezelite Client gibts dann für Linux Windows etc. https://www.max2play.com/ und https://wiki.fhem.de/wiki/Squeezebox_Modul

Oh, spannend!  ;D

Dazu hatte ich eh noch ein Attentat auf dich vor.
Ähnlich wie die Anfrage von @Haecksler mit dem states und Talk2Fhem.
Dann schiebe ich das direkt mal ein. Die Module machen nämlich auch TTS Ausgaben, übergeben dazu den Text an
http://translate.google.com/translate_tts?ie=UTF-8&tl=<LANG>&q=<TEXT>&client=tw-ob.
Nun kannst du dir sicher vorstellen, worauf es hinausläuft. Text an die Sepia TTS Engine übergeben und dann zurück zu bekommen. Du kannst die URL auch direkt im Brower abschicken, aber du kennst das sicher. Teste mal: http://translate.google.com/translate_tts?ie=UTF-8&tl=de&q=Guten Abend SEPIA&client=tw-ob.

Ah ja der gute alte Google Translator, den hab ich vor ca. 4 Jahren schon zu diesem Zweck "vergewaltigt" ;D (das Projekt hieß ILA Voice Assistant). Es gibt auch Javascript Libraries die den mehr oder weniger "heimlich" als TTS Engine verkaufen. Ich bin persönlich kein großer Fan davon weil es im Grunde von Google nur "geduldet" wird und wenn man es ganz genau nimmt sogar gegen deren AGB verstößt (frag mich jetzt nicht wo das steht ^^). Ich bin sogar mal irgendwann geblockt worden von Google weil ich wohl zu viele Requests hatte =). Eigentlich ein Trauerspiel, dass in den vielen Jahren keine ernsthafte Konkurrenz aufgetaucht ist in Sachen Qualität und Einfachheit. SEPIA hat auch eine uralte Schnittstelle zu Acapela, zu denen hatte ich ganz guten Kontakt. Die könnte man bei Bedarf vielleicht mal etwas aufpolieren. Theoretisch müsste die sogar immer noch gehen, man muss sich nur nen Test-Account machen und dann irgendwas in den SEPIA Settings einstellen ^^.

Offline whistler

  • New Member
  • *
  • Beiträge: 43
Antw:SEPIA open-source Sprachassistent: Integration in FHEM?
« Antwort #151 am: 14 Februar 2020, 21:08:32 »
"isApp" besser behalten. Der Parameter erzwingt den Status "App" (wer hätte das gedacht) als Gegensatz zu "Website". Die Konsequenz ist, dass der Login nicht nach 1 Tag abläuft sonder das Token glaub 1 Jahr gültig bleibt (wie z.B. in Android etc.).
Zitat

So mit dem Bugfix von gestern abend bzw. heute morgen, hab ich scheinbar was anderes Kaputt gemacht.
Ich bekomme nun beim Remote terminal (bei beiden clients) nur noch folgendes im Logfenster unten drunter angezeigt.

CLEXI connecting ...
CLEXI reconnecting after unexpected close. Try: 19
CLEXI error: The operation is insecure.
CLEXI closed. Reason: 1015
CLEXI error
Hast du eine Idee, was ich da nun kaputt gemacht habe? Oder muss ich noch was aktualisieren? idispassword steht noch auf false, macht aber keine unterschied oder true oder false. hmm

[EDIT] wenn ich direkt "intern" über server:20726 auf das Remote Terminal gehe, dann gehts. Umweg über den apache, also extern will obige Meldung.
weil nicht wss? sondern nur ws? Oder einfach wie beim User Mgmt nur im "privaten" Netzerreichbar? Nur das die Fehlermeldung anders ist.

Definitiv erwünscht ^^. In Windows ist alles im Grunde ja ziemlich unproblematisch. Man konfiguriert den Client einfach übers Display (oder Remote Desktop) und packt sich dann ne .bat Datei oder Ähnliches in den Autostart, die den Browser mit "headless" Parameter startet. CLEXI für das "remote Terminal" und sogar Nginx laufen auch in Windows. Das System macht halt nur generell jede Menge Krams im Hintergrund unangekündigt ::)
Zitat

dem kann man ja endgegenwirken, weil das system erstmal läuft :-) sofern die states an fhem geschickt werden dann in Zukunft irgendwann. Kann man dort zur not tätig werden :-)
Oder man installiert neben dem headless client noch ein mesh node, dann kann man diesen ggf. unter windows noch was ausführen lassen.

Ah ja der gute alte Google Translator, den hab ich vor ca. 4 Jahren schon zu diesem Zweck "vergewaltigt" ;D (das Projekt hieß ILA Voice Assistant). Es gibt auch Javascript Libraries die den mehr oder weniger "heimlich" als TTS Engine verkaufen. Ich bin persönlich kein großer Fan davon weil es im Grunde von Google nur "geduldet" wird und wenn man es ganz genau nimmt sogar gegen deren AGB verstößt (frag mich jetzt nicht wo das steht ^^). Ich bin sogar mal irgendwann geblockt worden von Google weil ich wohl zu viele Requests hatte =). Eigentlich ein Trauerspiel, dass in den vielen Jahren keine ernsthafte Konkurrenz aufgetaucht ist in Sachen Qualität und Einfachheit. SEPIA hat auch eine uralte Schnittstelle zu Acapela, zu denen hatte ich ganz guten Kontakt. Die könnte man bei Bedarf vielleicht mal etwas aufpolieren. Theoretisch müsste die sogar immer noch gehen, man muss sich nur nen Test-Account machen und dann irgendwas in den SEPIA Settings einstellen ^^.
na du baust doch gerade das espeak ein, vielleicht geht auch das :-) Ich hab mir nicht angeschaut wie die api im sepia aussieht, was die gerade so bietet :-)

« Letzte Änderung: 14 Februar 2020, 21:47:45 von whistler »

Offline sepia

  • Jr. Member
  • **
  • Beiträge: 68
Antw:SEPIA open-source Sprachassistent: Integration in FHEM?
« Antwort #152 am: 14 Februar 2020, 23:48:14 »
Zitat
Hast du eine Idee, was ich da nun kaputt gemacht habe? Oder muss ich noch was aktualisieren? idispassword steht noch auf false, macht aber keine unterschied oder true oder false. hmm

Hmm. Der Control HUB ist über den Apache auf HTTPS? Und die CLEXI Verbindung dann WS? Dann meckert er vermutlich wegen insecure origin. Wenn ich diese Situation nachstelle komme ich aber gar nicht erst bis "CLEXI connecting ...", er bricht schon vorher ab mit der Meldung, dass es nicht geht wegen HTTPS + WS.

Zitat
Oder einfach wie beim User Mgmt nur im "privaten" Netzerreichbar?

Das sollte hier keine Rolle spielen. Für die Client Connections musst du im Grunde nicht mal angemeldet sein, weil das direkt vom Browser zum CLEXI Server geht.

Zitat
Oder man installiert neben dem headless client noch ein mesh node, dann kann man diesen ggf. unter windows noch was ausführen lassen.

 ;D ;D
Ich hatte das mal im RPi Client laufen um das System per Sprache herunterzufahren. Aber ich eins nach dem anderen ^^.

Zitat
na du baust doch gerade das espeak ein, vielleicht geht auch das :-) Ich hab mir nicht angeschaut wie die api im sepia aussieht, was die gerade so bietet :-)

Der TTS Endpoint vom SEPIA Assist-Server integriert sich nahtlos in den SEPIA Client. In den Settings kannst du die "Voice Engine" jetzt genau so switchen wie die "ASR Engine". Im Control HUB gibt es übrigens auch die Seite "Speech Synthesis" zum testen ;-)
« Letzte Änderung: 14 Februar 2020, 23:50:47 von sepia »

Offline whistler

  • New Member
  • *
  • Beiträge: 43
Antw:SEPIA open-source Sprachassistent: Integration in FHEM?
« Antwort #153 am: 15 Februar 2020, 18:27:53 »
Hmm. Der Control HUB ist über den Apache auf HTTPS? Und die CLEXI Verbindung dann WS? Dann meckert er vermutlich wegen insecure origin. Wenn ich diese Situation nachstelle komme ich aber gar nicht erst bis "CLEXI connecting ...", er bricht schon vorher ab mit der Meldung, dass es nicht geht wegen HTTPS + WS.

Das sollte hier keine Rolle spielen. Für die Client Connections musst du im Grunde nicht mal angemeldet sein, weil das direkt vom Browser zum CLEXI Server geht.
Ja insecure origin schreibt er ja. Ich komme aber auch an den Clexi nicht per wss vermutlich müsste ich dann den Parameter ssl in den settings auf true setzen oder?

ich würde ihn aber glaubig vom client auch eher intern verbinden, das er raus geht über den Proxy dann wieder rein kommt macht ja für die headless clients nicht so viel sinn denke ich.

;D ;D
Ich hatte das mal im RPi Client laufen um das System per Sprache herunterzufahren. Aber ich eins nach dem anderen ^^.
Da fallen mir dann noch anderen sachen ein ja :-) (Gabs da nicht mal ein Beispiel irgendwo das der mesh ein Powershell Skript ausführt. Egal später :-)


Der TTS Endpoint vom SEPIA Assist-Server integriert sich nahtlos in den SEPIA Client. In den Settings kannst du die "Voice Engine" jetzt genau so switchen wie die "ASR Engine". Im Control HUB gibt es übrigens auch die Seite "Speech Synthesis" zum testen ;-)

Ja verstehe und hab ich gesehen, daher musste ich ja auch mein Docker verlassen, wenn ich das jetzt richtig kombiniere weil doch da was nachinstalliert werden musste. Und ich es zumindest nicht hinbekommen habe.

Aber der Gedanke war. Ich schicke den Text nicht mehr an die Google Api (egal ob geduldet oder nicht :-) ), und bekomme dann das ergebnis von der api direkt zurück.
Das sie im client ist hab ich gesehen ja :-)

Offline whistler

  • New Member
  • *
  • Beiträge: 43
Antw:SEPIA open-source Sprachassistent: Integration in FHEM?
« Antwort #154 am: 15 Februar 2020, 18:34:08 »
Hallo Florian,

ich muss nochmal was wegen der headless Clients fragen :-) Ja der Echte Client :-)

Ich hab gerade per bash setup.sh die clexi und client id umgebogen. dazu hat er vom dhcp eine feste ip bekommen. (also ip wechsel).
nach dem neustart meldet er sich im setup mode an (get user)

wenn ich dann per call login user uid1007 pwd xxx versuche den user einzuloggen meckert er.
hat er gestern bei meinem "not supported" client auch gehabt. das aber erstmal darauf geschoben.

Broadcaster event: {"broadcast":{"client":"o87_chrome_app_v0.21.0","deviceId":"o87","sepia-login":{"note":"loginFail"}}}
Broadcaster event: {"broadcast":{"client":"o87_chrome_app_v0.21.0","deviceId":"o87","msg":"Logging in with new user: uid1007. Plz wait."}}
Broadcaster response: "sent"
Broadcaster event: {"broadcast":{"name":"sepia-client","data":{"deviceId":"o87","call":"login","user":"uid1007","pwd":"testtest"}}}

Ich könnte mir jetzt vorstellen das die clexi id und device id eindeutig ist und somit neu für den Server.
Wo kann ich dann "verwaiste" einträge sehen und ggf. löschen?
Was mach ich bei obigem Fehler? :-)

Macht es dann generell Sinn, das ich pro Client einen eigenen User anmelde, zumindest für die Räume.
[EDIT] Zusatzfrage: Was sind dann die sinnvollen Rollen die die Headless User kriegen?

Mein Gedanke wäre ich lege die User an konfiguriere sie im Browser, Treffe Raumzuordnung etc. und melde sie dann per Remote Terminal am headless client an.

Schöne Grüße
Basti
« Letzte Änderung: 15 Februar 2020, 18:35:48 von whistler »

Offline sepia

  • Jr. Member
  • **
  • Beiträge: 68
Antw:SEPIA open-source Sprachassistent: Integration in FHEM?
« Antwort #155 am: 16 Februar 2020, 01:32:48 »
Ja insecure origin schreibt er ja. Ich komme aber auch an den Clexi nicht per wss vermutlich müsste ich dann den Parameter ssl in den settings auf true setzen oder?

Der "ssl" Parameter müsste auf "false" bleiben denn eigentlich macht der reverse proxy die SSL Terminierung und der CLEXI Server weiß davon nichts.

Ich hab gerade per bash setup.sh die clexi und client id umgebogen. dazu hat er vom dhcp eine feste ip bekommen. (also ip wechsel).
[...]
wenn ich dann per call login user uid1007 pwd xxx versuche den user einzuloggen meckert er.
hat er gestern bei meinem "not supported" client auch gehabt. das aber erstmal darauf geschoben.
[...]
Ich könnte mir jetzt vorstellen das die clexi id und device id eindeutig ist und somit neu für den Server.
Wo kann ich dann "verwaiste" einträge sehen und ggf. löschen?
Was mach ich bei obigem Fehler? :-)

Wenn du bis zum Login Versuch kommst ist mit der CLEXI Verbindung und ID alles in Ordnung und es kann mmn eigentlich nur noch der "hostname" falsch sein oder aus irgendeinem Grund nicht erreichbar. Was hast du da eingetragen?
Wenn sich die "device ID" des Clients ändert wird der Login beim nächsten reload ungültig und alle gespeicherten Tokens automatisch entfernt. Der Client müsste dann nach ein paar Sekunden wieder im Setup Modus landen. "Verwaiste" Einträge gibt es in diesem Sinne nicht oder ich hab nicht ganz verstanden was du meinst.

[EDIT] Mir ist gerade eingefallen, dass es noch den Befehl "call ping" gibt, der prüft ob der Client einen der SEPIA Server erreichen kann.

Macht es dann generell Sinn, das ich pro Client einen eigenen User anmelde, zumindest für die Räume.

Ich bin mir noch nicht sicher was mehr Sinn macht, tendiere aber dazu auf allen Geräten den selben User anzumelden, weil sich dann z.B. auch die Teach-UI Befehle und Timer/Reminder etc. synchronisieren. So lange jeder Client eine eigene Device ID hat geht das. Bei zwei Geräten mit gleichem User UND gleicher Device ID geht es theoretisch sogar auch noch, nur für den Server bleibt immer der Client "aktiv" der als letztes benutzt wurde.
Wenn man jeweils einen eigenen User hat kann man vielleicht andere Sachen dafür besser managen. Vielleicht will man das ja genau WEIL dann die Teach-UI Befehle unterschiedlich sind :). Eigene Befehle und SDK Services die man dem Assistant-User (default: uid1005) beibringt gelten übrigens für alle User.

[EDIT] Zusatzfrage: Was sind dann die sinnvollen Rollen die die Headless User kriegen?

Gute Frage ::) Spontan würde ich sagen "smarthomeguest" reicht eigentlich. Ggf. noch "developer" falls man irgendwann SDK Services hochladen will für den User.

Mein Gedanke wäre ich lege die User an konfiguriere sie im Browser, Treffe Raumzuordnung etc. und melde sie dann per Remote Terminal am headless client an.

Im Grunde habe ich mir das auch so vorgestellt :) . Man muss nur ein wenig aufpassen, denn z.B. die Raumzuordnung ('Einstellungen - Gerätestandort' meine ich) ist eine Device Eigenschaft keine User Eigenschaft ;-)
« Letzte Änderung: 16 Februar 2020, 11:35:58 von sepia »

Offline JensS

  • Sr. Member
  • ****
  • Beiträge: 618
Antw:SEPIA open-source Sprachassistent: Integration in FHEM?
« Antwort #156 am: 16 Februar 2020, 19:35:17 »
Zitat
Sorry MCP, aber du brauchst erst eine Erlaubnis, um diesen Smart Home Service zu nutzen.
Wo kann ich die Berechtigung eintragen?
Debian auf APU2C4, HM-CFG-USB2, SIGNALduino, HM-ES-PMSw1-Pl, AB440S, AB440R, TFA 30.3121, TFA 30.3125, ITS-150, PIR-5000, configurable Firmata USB & LAN, 1-wire: DS-18B20, DS-18S20, DS-2408, DS-2413, diverse I2C-Komponenten, zigbee2mqtt, ESPEasy etc.

Offline whistler

  • New Member
  • *
  • Beiträge: 43
Antw:SEPIA open-source Sprachassistent: Integration in FHEM?
« Antwort #157 am: 16 Februar 2020, 19:45:45 »
Der "ssl" Parameter müsste auf "false" bleiben denn eigentlich macht der reverse proxy die SSL Terminierung und der CLEXI Server weiß davon nichts.

Ja klingt logisch, vielleicht hab ich auch eine Überdosis Sepia. :-) müsste das dann nicht der nginx erledigen der am headless client mit installiert ist, oder ist das dort deaktiviert?


Wenn du bis zum Login Versuch kommst ist mit der CLEXI Verbindung und ID alles in Ordnung und es kann mmn eigentlich nur noch der "hostname" falsch sein oder aus irgendeinem Grund nicht erreichbar. Was hast du da eingetragen?
Wenn sich die "device ID" des Clients ändert wird der Login beim nächsten reload ungültig und alle gespeicherten Tokens automatisch entfernt. Der Client müsste dann nach ein paar Sekunden wieder im Setup Modus landen. "Verwaiste" Einträge gibt es in diesem Sinne nicht oder ich hab nicht ganz verstanden was du meinst.

[EDIT] Mir ist gerade eingefallen, dass es noch den Befehl "call ping" gibt, der prüft ob der Client einen der SEPIA Server erreichen kann.
das hatte ich per Zufall auf den Hilfebutton gestern abend auch gesehen, dann einen Fehler 404 und dann erstmal keine Lust mehr.

eingetragen habe ich
- zuerst 192.168.1.25:20721/sepia
- dann 192.168.1.25:20726/sepia
er versucht dann setzt er ein https davor und erreicht da nix :-) Fehler 404
Nun hab ich ein http://192.168.1.25:20726/sepia/ eingetragen und der Ping antwortet.
([PS:] Habe gesehen du hast bereits das Skript angepasst für die Hostname Fehler :-))

Und ich kann mich wieder auf deinem favoriten einloggen aber auch auf meinem favoriten läuft der login. (hab schon gesehen, dank github rss :-) du bastelst einen pseudo headless) :-)
Hat dir wohl keine ruhe gelassen. Gedanklich vermutlich das ähnliche was ich auch versucht habe :-)

Ich bin mir noch nicht sicher was mehr Sinn macht, tendiere aber dazu auf allen Geräten den selben User anzumelden, weil sich dann z.B. auch die Teach-UI Befehle und Timer/Reminder etc. synchronisieren. So lange jeder Client eine eigene Device ID hat geht das. Bei zwei Geräten mit gleichem User UND gleicher Device ID geht es theoretisch sogar auch noch, nur für den Server bleibt immer der Client "aktiv" der als letztes benutzt wurde.
Wenn man jeweils einen eigenen User hat kann man vielleicht andere Sachen dafür besser managen. Vielleicht will man das ja genau WEIL dann die Teach-UI Befehle unterschiedlich sind :). Eigene Befehle und SDK Services die man dem Assistant-User (default: uid1005) beibringt gelten übrigens für alle User.

Gute Frage ::) Spontan würde ich sagen "smarthomeguest" reicht eigentlich. Ggf. noch "developer" falls man irgendwann SDK Services hochladen will für den User.

Im Grunde habe ich mir das auch so vorgestellt :) . Man muss nur ein wenig aufpassen, denn z.B. die Raumzuordnung ('Einstellungen - Gerätestandort' meine ich) ist eine Device Eigenschaft keine User Eigenschaft ;-)

Okay aktuell bin ich am Android Browser und headless clients mit dem 1007 unterwegs.
Dann wurde ich vermutlich einen 1009 anlegen, wenn das ungerade Zahlen ein Muster hat :-) und würde device id und o id pro headless unterschiedlich machen.

Dann hätte ich einen persönlichen am Handy / Browser und einen an den headless für den Haushalt :-)


Weils so schön ist beim testen noch eine Zusatzfrage. das mit den Wakeworks will noch nicht so recht. Zum einen am Headless. Teste ich aber nach der Änderung jetzt nochmal.
in der clexi settings der 27041 geht auf localhost wird das intern redirected oder muss auch noch passend auf die ip gebogen werden?


Aber am Android Client hab ich den Native ASR aktiv, wenn ich auf den Button klicke hört er mir brav zu, dann klappt es auch,
aber wenn ich Einstellungen "Hey Sepia" aufrufe, kann ich ja den Start Button drücken und den Logo Wechsel anschauen.
Das funktioniert auch, aber das Wake up klappt nicht so recht. ja die schieber darunter sind an :-)
Er reagiert weder in der App noch im Always on Display, das zwischen die Augen tippen klappt aber.
Er vermeldet auch das die App im Hintergrund auf das Mikro zugreift, Berechtigung ist erteilt.
Wenn ich die Lösung kenne bestimmt ganz dumm :-)

Danke schön.
Gruß
Basti


Offline Haecksler

  • Full Member
  • ***
  • Beiträge: 192
Antw:SEPIA open-source Sprachassistent: Integration in FHEM?
« Antwort #158 am: 16 Februar 2020, 20:47:58 »
Wo kann ich die Berechtigung eintragen?
Du musst einen User anlegen und diesem die Rolle smarthomeguest geben...mit dem Admin User geht das nicht, soweit ich weiß.
Zustimmung Zustimmung x 1 Hilfreich Hilfreich x 1 Liste anzeigen

Offline sepia

  • Jr. Member
  • **
  • Beiträge: 68
Antw:SEPIA open-source Sprachassistent: Integration in FHEM?
« Antwort #159 am: 16 Februar 2020, 23:00:47 »
Ja klingt logisch, vielleicht hab ich auch eine Überdosis Sepia. :-) müsste das dann nicht der nginx erledigen der am headless client mit installiert ist, oder ist das dort deaktiviert?

Ja stimmt, der CLEXI server selber ist eh nur auf localhost konfiguriert, die "ssl" Option müsste demnach immer aus bleiben und man könnte dem Nginx ein self-signed Zertifikat geben ... wenn man nicht eh alles über einen zentralen Proxy steuert. Klappte der Zugriff irgendwie noch oder hattest du das jetzt erstmal auf die Warteliste gesetzt?

das hatte ich per Zufall auf den Hilfebutton gestern abend auch gesehen, dann einen Fehler 404 und dann erstmal keine Lust mehr.

eingetragen habe ich
- zuerst 192.168.1.25:20721/sepia
- dann 192.168.1.25:20726/sepia
er versucht dann setzt er ein https davor und erreicht da nix :-) Fehler 404
Nun hab ich ein http://192.168.1.25:20726/sepia/ eingetragen und der Ping antwortet.
([PS:] Habe gesehen du hast bereits das Skript angepasst für die Hostname Fehler :-))

Wenn man es ganz genau nimmt ist der "hostname" immer der Basispfad zu allen Servern, also z.B. "http://192.168.178.10" für "...:20721, ...:20722, ..." oder mit Proxy "http://my-domain/sepia" für ".../sepia/assist, .../sepia/teach, ...". Das hatte ich mal so gemacht damit der User nicht immer jeden einzelnen Server eintragen muss (auch wenn er das mittlerweile könnte). Damit das klappt muss ich aber einige Annahmen machen, wie z.B. dass der User die Ports nicht ändert und dass er einen Proxy nutzt mit den standard Pfaden falls seine URL ".../sepia" heißt ... und auch dass er beim Proxy HTTPS nutzt wenn er nicht explizit den "hostname" als "http://..." definiert.
Diese Annahmen gehen leider nicht immer 100% auf ::) :P Zusätzlich versucht das Skript dann noch Eingabefehler zu korrigieren, wie z.B. "192.168.178.10:20721" (der Port gehört da nicht hin) oder "http://192.168.1.25:20726/sepia/" (der Slash am Ende ist genau genommen falsch). Mancher Marketing Mensch würde sagen "die Eingabe wird mit Künstlicher Intelligenz korrigiert"  ;D :o =) ... naja was ich damit sagen will ist es gibt einen wohl definierten Weg aber keiner hält sich dran  :-[ :-X

Und ich kann mich wieder auf deinem favoriten einloggen aber auch auf meinem favoriten läuft der login. (hab schon gesehen, dank github rss :-) du bastelst einen pseudo headless) :-)
Hat dir wohl keine ruhe gelassen. Gedanklich vermutlich das ähnliche was ich auch versucht habe :-)

Hehe ;D , der "pseudo-headless" bedeutet, dass das Display an bleibt, der Client sich aber ansonsten wie die "headless" Variante verhält (auto setup, remote terminal etc.). War das das was du auch im Sinne hattest? ^^
Vielleicht hast du auch schon gesehen, dass ich den Aufbau des Clients etwas verändert habe. Das wird vermutlich ein Update deiner Clients etwas tricky machen (der Ordner ~/sepia heißt jetzt ~/sepia-client und beinhaltet auch den meisten code aus ~/.config/openbox/autostart, die .bashrc hat sich auch geändert), allerdings hielt ich es für nötig das noch vor dem Release zu machen, denn dadurch wird die Struktur etwas übersichtlicher und man kann den Client auch besser über die Konsole starten und stoppen. Außerdem wird openbox für die headless Version gar nicht mehr gestartet (nur noch im 'display' mode).

Okay aktuell bin ich am Android Browser und headless clients mit dem 1007 unterwegs.
Dann wurde ich vermutlich einen 1009 anlegen, wenn das ungerade Zahlen ein Muster hat :-) und würde device id und o id pro headless unterschiedlich machen.

Dann hätte ich einen persönlichen am Handy / Browser und einen an den headless für den Haushalt :-)

Klingt gut  8) ;D . Die UIDs steigen generell um 2 (uid1003/5/7/9), zwischendurch kann aber immer mal wieder ein Sprung passieren, also nicht wundern ;-) (das liegt am globalen unique ID Generator). Ursprünglich war es eigentlich gedacht, dass man die Email Adressen nutzt, mache ich aber selber auch nie =) ... aber nur so als Hinweis, dass das auch möglich ist falls man mal seine UID vergisst ;-)
Wo ich schon dabei bin aus dem Nähkästchen zu plaudern ::) ... im Grunde kann der Server den kompletten, automatischen Registrierungsprozess bereitstellen (Anfrage eines neuen Accounts mit Angabe einer gültigen Email-Adresse, Nachricht an Email mit Freischaltungslink, Erstellung des Accounts mit Definition des Passworts ... alles optional abgesichert durch whitelisting von Email-Adressen). Die Endpoints existieren alle und der Email Account kann sogar in den Server Settings konfiguriert werden, der Client hat nur die entsprechenden Views dafür nicht. Das ganze wäre zur Zeit ja eh nur interessant, wenn Jemand SEPIA in einer Firma oder öffentlich hosten würde ... ^^.

Weils so schön ist beim testen noch eine Zusatzfrage. das mit den Wakeworks will noch nicht so recht. Zum einen am Headless. Teste ich aber nach der Änderung jetzt nochmal.
in der clexi settings der 27041 geht auf localhost wird das intern redirected oder muss auch noch passend auf die ip gebogen werden?

Wake-word braucht nur die Mikrofon Erlaubnis und die ist in den RPi Clients automatisch gegeben weil die Web-App über localhost vom CLEXI Server geladen wird. Meintest du diesen Eintrag "clexiSocketURI" mit ... localhost:8080 ? Der sollte unbedingt so bleiben.

Aber am Android Client hab ich den Native ASR aktiv, wenn ich auf den Button klicke hört er mir brav zu, dann klappt es auch,
aber wenn ich Einstellungen "Hey Sepia" aufrufe, kann ich ja den Start Button drücken und den Logo Wechsel anschauen.
Das funktioniert auch, aber das Wake up klappt nicht so recht. ja die schieber darunter sind an :-)
Er reagiert weder in der App noch im Always on Display, das zwischen die Augen tippen klappt aber.
Er vermeldet auch das die App im Hintergrund auf das Mikro zugreift, Berechtigung ist erteilt.
Wenn ich die Lösung kenne bestimmt ganz dumm :-)

Also wenn es auf der Wake-Word Seite klappt mit dem Logo Wechsel (Schwarz/Weiß) und unten die beiden Regler "Allow local/remote wake-word" und "Load engine on start" an sind müsste alles korrekt eingestellt sein (vielleicht einmal die App komplett neu starten). Ich habe es so laufen bei mir. Wenn du ganz genau hinguckst erkennst du oben beim SEPIA Label an dem "online" Tag ob der WW-Listener aktiv ist, dann sieht das so aus "Ξ online Ξ". Die Performance kann etwas vom Handy abhängen, ich habe ein Samsung A3, da ist die Qualität durchwachsen und ein Samsung S10e, da klappt es ziemlich gut. Ich vermute es liegt am verbauten Mikrofon und/oder an der Performance. Das müsste man dann aber schon auf der WW Settings Seite beim Testen bemerken.

Offline whistler

  • New Member
  • *
  • Beiträge: 43
Antw:SEPIA open-source Sprachassistent: Integration in FHEM?
« Antwort #160 am: 17 Februar 2020, 00:09:46 »
Ja stimmt, der CLEXI server selber ist eh nur auf localhost konfiguriert, die "ssl" Option müsste demnach immer aus bleiben und man könnte dem Nginx ein self-signed Zertifikat geben ... wenn man nicht eh alles über einen zentralen Proxy steuert. Klappte der Zugriff irgendwie noch oder hattest du das jetzt erstmal auf die Warteliste gesetzt?

Ich hab das wss geparkt :-) Weil ich es nicht verstehe :-)
Aber ich hab jetzt 1 +3 Clients laufen. http://192.168.1.25:20726/sepia/ also ohne SSL intern für den HUB. und von da aus kann ich alle clients anmelden.
Ich muss jetzt nur noch etwas am pulseaudio / alsa rumspielen damit sich die musik und sepia brav die geräte Teilen.
Wake Word will noch nicht so wie ich will, schauen wir mal.

Wenn man es ganz genau nimmt ist der "hostname" immer der Basispfad zu allen Servern, also z.B. "http://192.168.178.10" für "...:20721, ...:20722, ..." oder mit Proxy "http://my-domain/sepia" für ".../sepia/assist, .../sepia/teach, ...". Das hatte ich mal so gemacht damit der User nicht immer jeden einzelnen Server eintragen muss (auch wenn er das mittlerweile könnte). Damit das klappt muss ich aber einige Annahmen machen, wie z.B. dass der User die Ports nicht ändert und dass er einen Proxy nutzt mit den standard Pfaden falls seine URL ".../sepia" heißt ... und auch dass er beim Proxy HTTPS nutzt wenn er nicht explizit den "hostname" als "http://..." definiert.
Diese Annahmen gehen leider nicht immer 100% auf ::) :P Zusätzlich versucht das Skript dann noch Eingabefehler zu korrigieren, wie z.B. "192.168.178.10:20721" (der Port gehört da nicht hin) oder "http://192.168.1.25:20726/sepia/" (der Slash am Ende ist genau genommen falsch). Mancher Marketing Mensch würde sagen "die Eingabe wird mit Künstlicher Intelligenz korrigiert"  ;D :o =) ... naja was ich damit sagen will ist es gibt einen wohl definierten Weg aber keiner hält sich dran  :-[ :-X
Ich habs ja ohne Skript gemacht, weil der Bugfix noch nicht da war, ist ja auch nicht schlimm. Ich hab sogar überlegt ob das Skript nicht direkt den Check per curl machen? ob die URL passt.


Hehe ;D , der "pseudo-headless" bedeutet, dass das Display an bleibt, der Client sich aber ansonsten wie die "headless" Variante verhält (auto setup, remote terminal etc.). War das das was du auch im Sinne hattest? ^^
Ja das war das was ich testweise gebaut habe auf meinem unsupported device genau :-)
Das schöne beim testen war ich per vnc drauf, und konnte quasi neben dem terminal dann live sehen wie am pi der browser sich bewegt hat :-)

Vielleicht hast du auch schon gesehen, dass ich den Aufbau des Clients etwas verändert habe. Das wird vermutlich ein Update deiner Clients etwas tricky machen (der Ordner ~/sepia heißt jetzt ~/sepia-client und beinhaltet auch den meisten code aus ~/.config/openbox/autostart, die .bashrc hat sich auch geändert), allerdings hielt ich es für nötig das noch vor dem Release zu machen, denn dadurch wird die Struktur etwas übersichtlicher und man kann den Client auch besser über die Konsole starten und stoppen. Außerdem wird openbox für die headless Version gar nicht mehr gestartet (nur noch im 'display' mode).

Ich war da sehr einfach gestrikt oder Bequem :-) ich hab einfach
sudo cp openbox /opt/openbox_autostart.sh
isHeadless=0 # fix
&isHeadless=true an URL angehängt
sudo nano ~/.config/lxsession/LXDE/autostart  hier per @/opt/openbox_autostart.sh
Ich wollte erst ans Ziel, also ein Ergebnis, hab ich noch nicht ganz, aber zumindest meine Buttons etc. werden geladen also mein Profil noch gibt es nur 1007 und nicht 1009 :-)
Es war zum testen, ich hab quasi nur nen bisschen vorgegriffen denke ich. Deine Lösung ist natürlich dann schöner.
Hab gesehen das du ein paar sachen eingecheckt hast, und hab gedacht, wenn ich wieder vorab clone habe ich wieder einen Zwischenstand :-) Das wollte ich nicht.
Finde ich aber gut und werde ich dann nochmal bei mir runterschmeissen und sobald du durch bist updaten. Man will ja schon im Standard bleiben.

Klingt gut  8) ;D . Die UIDs steigen generell um 2 (uid1003/5/7/9), zwischendurch kann aber immer mal wieder ein Sprung passieren, also nicht wundern ;-) (das liegt am globalen unique ID Generator). Ursprünglich war es eigentlich gedacht, dass man die Email Adressen nutzt, mache ich aber selber auch nie =) ... aber nur so als Hinweis, dass das auch möglich ist falls man mal seine UID vergisst ;-)
Wo ich schon dabei bin aus dem Nähkästchen zu plaudern ::) ... im Grunde kann der Server den kompletten, automatischen Registrierungsprozess bereitstellen (Anfrage eines neuen Accounts mit Angabe einer gültigen Email-Adresse, Nachricht an Email mit Freischaltungslink, Erstellung des Accounts mit Definition des Passworts ... alles optional abgesichert durch whitelisting von Email-Adressen). Die Endpoints existieren alle und der Email Account kann sogar in den Server Settings konfiguriert werden, der Client hat nur die entsprechenden Views dafür nicht. Das ganze wäre zur Zeit ja eh nur interessant, wenn Jemand SEPIA in einer Firma oder öffentlich hosten würde ... ^^.

Ja hab ich gesehen, da hab ich sogar bereits am Anfang direkt den Mailserver eingetragen, weil in der UServerwaltung ja Whitelisting drin ist. Es stehen aber nur die ersten zwei (1003/1005) Accounts in der properties Datei der Rest dann in der Datenbank oder?

Nice wäre noch ein clonen eines Users, oder Teach Teile Clonen :-)

Apropo Teachserver ich hab mir vorhin entlich mal dein Sample angucken wollen, bzgl. neuer Einträge per API. Naja ich hab die URL zum API Server nicht zusammen gebracht.
Dabei ist mir bei dein Infobuttons aufgefallen, in der Serverübersicht, das in den ganzen URLs die Ports etc. weggelassen werden, also nicht mal fix Copy & Paste :-)

Wake-word braucht nur die Mikrofon Erlaubnis und die ist in den RPi Clients automatisch gegeben weil die Web-App über localhost vom CLEXI Server geladen wird. Meintest du diesen Eintrag "clexiSocketURI" mit ... localhost:8080 ? Der sollte unbedingt so bleiben.
Nein es gab noch den Eintrag mit :20741 aber als ich die Räume der Clients konfiguriert habe, hab ich gesehen, das du einfach ein default eingetragen hast als Bespiel glaubig.
Könnte man dann anpassen für den Server, wenn er nicht auch mit dem auf dem PI läuft.

Also wenn es auf der Wake-Word Seite klappt mit dem Logo Wechsel (Schwarz/Weiß) und unten die beiden Regler "Allow local/remote wake-word" und "Load engine on start" an sind müsste alles korrekt eingestellt sein (vielleicht einmal die App komplett neu starten). Ich habe es so laufen bei mir. Wenn du ganz genau hinguckst erkennst du oben beim SEPIA Label an dem "online" Tag ob der WW-Listener aktiv ist, dann sieht das so aus "Ξ online Ξ". Die Performance kann etwas vom Handy abhängen, ich habe ein Samsung A3, da ist die Qualität durchwachsen und ein Samsung S10e, da klappt es ziemlich gut. Ich vermute es liegt am verbauten Mikrofon und/oder an der Performance. Das müsste man dann aber schon auf der WW Settings Seite beim Testen bemerken.

Scheinbar hab ich das indirekt schon getan, weil ich gestern abend oder heute morgen kurz vorm schlafen gehen das Handy neugestartet habe (Mi9T Pro) und dann vorhin am Handy deinen Text gelesen haben und dann nochmal in die App rein bin. Also ich hatte den Text unterm Logo so verstanden das der nur zum Testen gedacht ist und man auf Stop drückt bevor man die Maske verlässt. Aber man muss scheinbar auf Start bleiben. Hmmm komisch (Android 10 vielleicht). Danach klappt das Mikro wenn ich in der App bin ohne den Knopf zu drücken und Wenn ich den Always On Screen an habe.

Wenn das Handy im Lockscreen ist geht es nicht. Eine Kombi von Always On und Lockscreen wäre cool, aber dann kommen sicher die Google Spielregeln dazwischen. Ich glaub die Hoheitsrechte mit Wakeword von fast überall hat nur der Google Assistent.

Da fällt mir noch was ein für die Wunschliste :-)
Stichwort eigenes Wakeword. Ich schieb hier mal so hin und wieder die Features von Snips rein :-) Die ich ganz nett fand, wobei ich das gar nicht soweit hinbekommen hatte. (pulseaudio / alsa) sei dank.
Aber neues Projekt neues Glück.

Sag bescheid, wenn du was zum testen hast, dann bügel ich es über. Hab gesehen Docker hast du auch was neues gebaut. Hab ich aber noch nicht angeschaut.

Guten Start in die neue Woche.

Gruß
Basti

Offline sepia

  • Jr. Member
  • **
  • Beiträge: 68
Antw:SEPIA open-source Sprachassistent: Integration in FHEM?
« Antwort #161 am: 17 Februar 2020, 01:10:56 »
Ich muss jetzt nur noch etwas am pulseaudio / alsa rumspielen damit sich die musik und sepia brav die geräte Teilen.

Oh ha, ich prophezeie viele sorgenvolle Stunden :o :-[ . Der Client ist super sensibel was das angeht. Im Endeffekt war der Konflikt zwischen Alsa und Pulseaudio sogar der Grund warum ich den TTS Endpoint des Servers wiederbelebt habe. Immer wenn ich am Audiosystem von Linux rumgespielt habe ging später irgendwas nicht (Mikrofon, Audio in Chromium, Audio im Allgemeinen, TTS voices, etc. etc.). Vielleicht hast du ja Glück aber das ist einer der Hauptgründe warum ich den Client eigentlich auf einem isolierten System haben will (unberührtes Raspbian Buster).

Ich hab sogar überlegt ob das Skript nicht direkt den Check per curl machen? ob die URL passt.

Ja wäre cool, das würde einem zumindest ein "call reload" + "call test" ersparen :-)

Das schöne beim testen war ich per vnc drauf, und konnte quasi neben dem terminal dann live sehen wie am pi der browser sich bewegt hat :-)

Hehe ja das ist ganz cool :-). Ich hatte ein paar mal versucht aus dem virtuellen Display (Xvfb) Screenshots zu erstellen zu Debug-Zwecken, bin aber bisher gescheitert daran :-(

Hab gesehen das du ein paar sachen eingecheckt hast, und hab gedacht, wenn ich wieder vorab clone habe ich wieder einen Zwischenstand :-) Das wollte ich nicht.
Finde ich aber gut und werde ich dann nochmal bei mir runterschmeissen und sobald du durch bist updaten. Man will ja schon im Standard bleiben.

Die ganzen Tests bis zu dieser Version waren auf jeden Fall super nützlich, danke noch mal! :D

Ja hab ich gesehen, da hab ich sogar bereits am Anfang direkt den Mailserver eingetragen, weil in der UServerwaltung ja Whitelisting drin ist. Es stehen aber nur die ersten zwei (1003/1005) Accounts in der properties Datei der Rest dann in der Datenbank oder?

Die 2 "core" Accounts sind in der Properties Datei, weil der Server die beim Start benötigt. Alles andere ist in der Elasticsearch, genau.

Nice wäre noch ein clonen eines Users, oder Teach Teile Clonen :-)

In der Tat, generell auch ein Export/Import, aber das wird wohl noch etwas dauern ;)

Apropo Teachserver ich hab mir vorhin entlich mal dein Sample angucken wollen, bzgl. neuer Einträge per API. Naja ich hab die URL zum API Server nicht zusammen gebracht.
Dabei ist mir bei dein Infobuttons aufgefallen, in der Serverübersicht, das in den ganzen URLs die Ports etc. weggelassen werden, also nicht mal fix Copy & Paste :-)

Die Teach-Server API ist standardmäßig "http://[IP-von-SEPIA]:20722" oder via Proxy "http://[proxy-IP]:20726/sepia/teach" bzw. "https://[my-domain]/sepia/teach".
Sind die Ports in deiner Übersicht in dem speziellen Fall vielleicht nur weg, weil du da die public Domain mit SSL nutzt, die auf deinen Router mit Port 443 zeigt? (so ist es bei mir).

Nein es gab noch den Eintrag mit :20741 aber als ich die Räume der Clients konfiguriert habe, hab ich gesehen, das du einfach ein default eingetragen hast als Bespiel glaubig.
Könnte man dann anpassen für den Server, wenn er nicht auch mit dem auf dem PI läuft.

Ach jo, das ist der Demo Pfad zum STT Server, der wird aber für das Wake-Word gar nicht gebraucht. Der RPi4 mit 4GB könnte vielleicht auch noch den STT Server stemmen, das habe ich als Test auf der To-Do Liste stehen ^^.

Scheinbar hab ich das indirekt schon getan, weil ich gestern abend oder heute morgen kurz vorm schlafen gehen das Handy neugestartet habe (Mi9T Pro) und dann vorhin am Handy deinen Text gelesen haben und dann nochmal in die App rein bin. Also ich hatte den Text unterm Logo so verstanden das der nur zum Testen gedacht ist und man auf Stop drückt bevor man die Maske verlässt. Aber man muss scheinbar auf Start bleiben. Hmmm komisch (Android 10 vielleicht). Danach klappt das Mikro wenn ich in der App bin ohne den Knopf zu drücken und Wenn ich den Always On Screen an habe.

Wenn das Handy im Lockscreen ist geht es nicht. Eine Kombi von Always On und Lockscreen wäre cool, aber dann kommen sicher die Google Spielregeln dazwischen. Ich glaub die Hoheitsrechte mit Wakeword von fast überall hat nur der Google Assistent.

Wenn man STOP drückt vor dem Verlassen, müsste es eigentlich automatisch wieder anspringen nachdem man einmal manuell was gefragt/gesagt hat (falls es denn generell erlaubt ist). Die Abfrage kommt beim Switch in den "idle" Modus also im Grunde nach jeder Interaktion mit SEPIA.
In den Lockscreen kommt man tatsächlich nicht, oder nur mit irgendwelchen Sonderregeln :-( Auf Android hat man zusätzlich das Problem, dass je nach Hersteller immer mal wieder die App aus dem Hintergrund gelöscht wird. SEPIA macht eigentlich nix im Hintergrund, aber das führt dazu, dass man irgendwann plötzlich keine Erinnerungen/Timer/Alarme per Notification bekommt :-/ Dann muss man einmal das Handy neustarten >:( (das passiert ca. 1mal im Monat bei mir).

Da fällt mir noch was ein für die Wunschliste :-)
Stichwort eigenes Wakeword. Ich schieb hier mal so hin und wieder die Features von Snips rein :-) Die ich ganz nett fand, wobei ich das gar nicht soweit hinbekommen hatte. (pulseaudio / alsa) sei dank.
Aber neues Projekt neues Glück.

Sag bescheid, wenn du was zum testen hast, dann bügel ich es über. Hab gesehen Docker hast du auch was neues gebaut. Hab ich aber noch nicht angeschaut.

Guten Start in die neue Woche.

Eigenes Wake-Word wäre schon cool ja. Die Jungs von Picovoice waren so nett und haben mir "Hey SEPIA" kostenlos für das Projekt erstellt. Theoretisch kann man noch alles benutzen, was die so im GitHub veröffentlicht haben. Leider kann man sich bei denen nur eigene Wake-Words für Windows 64bit und Linux 64bit erstellen (Browser (wasm) und Raspberry muss man in Auftrag geben).

Docker ist work-in-progress, aber ich sage gerne Bescheid wenn es soweit ist ^^.

Ebenfalls einen guten Start!  :)
« Letzte Änderung: 17 Februar 2020, 01:14:10 von sepia »

Offline whistler

  • New Member
  • *
  • Beiträge: 43
Antw:SEPIA open-source Sprachassistent: Integration in FHEM?
« Antwort #162 am: 17 Februar 2020, 22:35:31 »
Oh ha, ich prophezeie viele sorgenvolle Stunden :o :-[ . Der Client ist super sensibel was das angeht. Im Endeffekt war der Konflikt zwischen Alsa und Pulseaudio sogar der Grund warum ich den TTS Endpoint des Servers wiederbelebt habe. Immer wenn ich am Audiosystem von Linux rumgespielt habe ging später irgendwas nicht (Mikrofon, Audio in Chromium, Audio im Allgemeinen, TTS voices, etc. etc.). Vielleicht hast du ja Glück aber das ist einer der Hauptgründe warum ich den Client eigentlich auf einem isolierten System haben will (unberührtes Raspbian Buster).

Das war sogar bei mir der Grund snips erstmal in die Ecke zu liegen und noch ein zwei andere Gründe. Jetzt ja noch ein zusätzlicher. :-)
Aber er soll ja sinnvolle Dienste vollbringen der Pi :-) also nicht nur einen. Ich verstehe natürlich deine bedenken.

Die Teach-Server API ist standardmäßig "http://[IP-von-SEPIA]:20722" oder via Proxy "http://[proxy-IP]:20726/sepia/teach" bzw. "https://[my-domain]/sepia/teach".
Sind die Ports in deiner Übersicht in dem speziellen Fall vielleicht nur weg, weil du da die public Domain mit SSL nutzt, die auf deinen Router mit Port 443 zeigt? (so ist es bei mir).
Nunja Reverse Proxy ist ja das eine, aber intern per http müsste ich ja so dran, so wie der clexi auch dran kommt, ja ein anderer port aber ist ja in der vm alles freigegeben. Ich prüfe das nochmal in ruhe.

Ach jo, das ist der Demo Pfad zum STT Server, der wird aber für das Wake-Word gar nicht gebraucht. Der RPi4 mit 4GB könnte vielleicht auch noch den STT Server stemmen, das habe ich als Test auf der To-Do Liste stehen ^^.
Ein STT sollte reichen, spricht was dagegen den SEPIA Server + STT zusammen auf einer Maschine zu installieren (nein kein PI) :-)

Wenn man STOP drückt vor dem Verlassen, müsste es eigentlich automatisch wieder anspringen nachdem man einmal manuell was gefragt/gesagt hat (falls es denn generell erlaubt ist). Die Abfrage kommt beim Switch in den "idle" Modus also im Grunde nach jeder Interaktion mit SEPIA.
In den Lockscreen kommt man tatsächlich nicht, oder nur mit irgendwelchen Sonderregeln :-( Auf Android hat man zusätzlich das Problem, dass je nach Hersteller immer mal wieder die App aus dem Hintergrund gelöscht wird. SEPIA macht eigentlich nix im Hintergrund, aber das führt dazu, dass man irgendwann plötzlich keine Erinnerungen/Timer/Alarme per Notification bekommt :-/ Dann muss man einmal das Handy neustarten >:( (das passiert ca. 1mal im Monat bei mir).
Dann bin ich damit ja nicht alleine. unschöner Nebeneffekt, evtl. ein Xiaomi Ding, wenn das Mikro an ist, tauscht er den Default Lautstärke für Lautsprecher und man reguliert die Lautstärke vom Mikro. Bissel nervig. und per Bluetooth Verbindung sorgt es bei der Freisprecheinrichtung dafür das diese denkt es wäre ein Anruf, und generiert einen Pseudo Anruf :-(


Eigenes Wake-Word wäre schon cool ja. Die Jungs von Picovoice waren so nett und haben mir "Hey SEPIA" kostenlos für das Projekt erstellt. Theoretisch kann man noch alles benutzen, was die so im GitHub veröffentlicht haben. Leider kann man sich bei denen nur eigene Wake-Words für Windows 64bit und Linux 64bit erstellen (Browser (wasm) und Raspberry muss man in Auftrag geben).
Bevor ich jetzt anfange zu suchen. Wo ist das Wakeword File versteckt? :-) Klingt interessant.
Hast du mal mit Snowboy rumprobiert. Wobei die auch auf die Picovoice Console verweisen, was dann noch nichts hilft am Ende.

Offline whistler

  • New Member
  • *
  • Beiträge: 43
Antw:SEPIA open-source Sprachassistent: Integration in FHEM?
« Antwort #163 am: 17 Februar 2020, 22:43:52 »
Hehe ;D , der "pseudo-headless" bedeutet, dass das Display an bleibt, der Client sich aber ansonsten wie die "headless" Variante verhält (auto setup, remote terminal etc.). War das das was du auch im Sinne hattest? ^^
Vielleicht hast du auch schon gesehen, dass ich den Aufbau des Clients etwas verändert habe. Das wird vermutlich ein Update deiner Clients etwas tricky machen (der Ordner ~/sepia heißt jetzt ~/sepia-client und beinhaltet auch den meisten code aus ~/.config/openbox/autostart, die .bashrc hat sich auch geändert), allerdings hielt ich es für nötig das noch vor dem Release zu machen, denn dadurch wird die Struktur etwas übersichtlicher und man kann den Client auch besser über die Konsole starten und stoppen. Außerdem wird openbox für die headless Version gar nicht mehr gestartet (nur noch im 'display' mode).

Wenn du eh gerade den Client umbaust, kannst du dir vielleicht nochmal den Clexi Server bzw. nginx anschauen. Du benötigst ja den Port 9090.
Vielleicht könntest du den Port 80 "ausbauen", den er vermutlich aktiv nicht nutzt oder hab ich was übersehen?

Ich weiss, nur headless alleine :-) Aber es müssen ja nicht Ports belegt werden, die am Ende nicht genutzt werden.

Dann wären nur 8080 und 9090 offen und aktuell in Nutzung richtig? :-)

Ich installiere den Client am Ende dann zum Testen auch gerne nochmal frisch :-)

im setup.sh wäre eine Raum Eingabe noch cool, oder per remote control. (Ups hab ich da was übersehen evtl. :-) )





Offline sepia

  • Jr. Member
  • **
  • Beiträge: 68
Antw:SEPIA open-source Sprachassistent: Integration in FHEM?
« Antwort #164 am: 19 Februar 2020, 01:29:13 »
Ein STT sollte reichen, spricht was dagegen den SEPIA Server + STT zusammen auf einer Maschine zu installieren (nein kein PI) :-)

Eigentlich nicht, solange die genug Saft hat ;)

Dann bin ich damit ja nicht alleine. unschöner Nebeneffekt, evtl. ein Xiaomi Ding, wenn das Mikro an ist, tauscht er den Default Lautstärke für Lautsprecher und man reguliert die Lautstärke vom Mikro. Bissel nervig. und per Bluetooth Verbindung sorgt es bei der Freisprecheinrichtung dafür das diese denkt es wäre ein Anruf, und generiert einen Pseudo Anruf :-(

Uff, das mit dem Anruf ist ja echt nervig >:(

Bevor ich jetzt anfange zu suchen. Wo ist das Wakeword File versteckt? :-) Klingt interessant.
Hast du mal mit Snowboy rumprobiert. Wobei die auch auf die Picovoice Console verweisen, was dann noch nichts hilft am Ende.

Das WW ist momentan im HTML Code könnte man aber so umbauen, dass es zumindest im Ordner des SEPIA Clients liegt ;-)
Snowboy hatte ich mal probiert bevor es Picovoice gab. Die waren ganz ok aber alles etwas umständlich zu konfigurieren und nicht auf so vielen Plattformen verfügbar. Vermutlich hat sich da auch einiges getan, wusste z.B. nicht, dass die jetzt irgendwas mit Picovoice zu tun haben.

Wenn du eh gerade den Client umbaust, kannst du dir vielleicht nochmal den Clexi Server bzw. nginx anschauen. Du benötigst ja den Port 9090.
Vielleicht könntest du den Port 80 "ausbauen", den er vermutlich aktiv nicht nutzt oder hab ich was übersehen?

Ich weiss, nur headless alleine :-) Aber es müssen ja nicht Ports belegt werden, die am Ende nicht genutzt werden.

Dann wären nur 8080 und 9090 offen und aktuell in Nutzung richtig? :-)

Ach, ich glaube der ist überhaupt nur drin wegen der Nginx default config, den hab ich gar nicht explizit definiert :( 8080 für CLEXI und 9090 für Nginx sind ansonsten alles.

im setup.sh wäre eine Raum Eingabe noch cool, oder per remote control. (Ups hab ich da was übersehen evtl. :-) )

Ich glaub da gibt es tatsächlich momentan noch keine Möglichkeit das einzustellen ohne Monitor ???
Ich prüfe das noch mal ^^.

 

decade-submarginal