UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[tobetobe]

@joergeli
Hallo Jörg,
ja ich habe das Thema auch verfolgt. Auch darin, dass Synthesiam auf deinen Post noch nicht geantwortet hat, sehe ich eine Bestätigung, dass hier tatsächlich noch ein Fehlverhalten vorliegt.

Noch befinde ich mich ja im theoretischen Bereich zur 2.5. Ich habe mir diese Anleitung

https://rhasspy.github.io/rhasspy-voltron/tutorials.html#getting-started-guide

bereits mehrfach angeschaut. Ohne parallel zu testen, ist zwar vieles verständlich, aber nicht nachvollziehbar. Und so frage ich mich, ob die Hinweise zu einem externen MQTT-Broker nicht eine Bedeutung auch für das von dir geschilderte Problem haben könnten. Morgen muss ich mich um einige berufliche Angelegenheiten kümmern (und meine Frau wurde ebenfalls verdonnert, im Home Office zu arbeiten). Von daher wird es wahrscheinlich nicht so schnell gehen, bis ich zum Testen der 2.5 komme. Steht für mich aber jetzt auf Prio 1.

Gruß und Gute Nacht
Thomas

[joergeli]

@tobetobe
Hallo Thomas,
nur kein Stress :blush:
Ich habe nur langsam an mir selbst gezweifelt, da im Forum immer nur unisono zu lesen war, daß es bei anderen (mit dem externen MQTT-broker funktioniert (allerdings immer mit dem Standard-Port 1883).

Mach Deine Tests aber bitte nicht nur wegen mir, nicht daß Deine bisherige Installation über den Jordan geht!

Kaldi:
Das ist auch wieder so eine Sache:
Im Forum heißt es, Kaldi funktioniert unter V2.5-pre mit deutschem Profil.

Kann ich aber nur eingeschränkt bestätigen:
Ich habe gerade eben die V 2.5 nochmals kpl. mit englischem Profil installiert --> Kaldi auswählbar.
Anschließend habe ich den "englischen Container" gestoppt und das deutsche Profil installiert.
Jetzt ist Kaldi auch im deutschen Profil aktivierbar und die entspr. Kaldi-Dateien werden heruntergeladen.

Zu diesem Umstand, also erst englisches Profil installieren, anschl. deutsches Profil, meine ich im Forum auch schon bei V2.4.18/V2.4.19 gelesen zu haben.

Ich bin nur froh, daß ich einen zweiten Raspi zum Testen habe.
Den ersten mit der V2.4.19 fasse ich nach Möglichkeit gar nicht mehr an, bzw. nur mit Samthandschuhen, damit ich ihn mir nicht zerschieße.

Gruß und bis demnächst
Jörg

[System 9]

@tobetobe
Vielen Dank für die Antwort.
Um den master mache ich mir keine sorgen, läuft auf virtuell auf einem Server (24core 100gb Ram).
was würdest du als Hardware für die Satelliten empfehlen. Ich habe hier schon an Richtmikrofone gedacht, da die dinger in der Decke verschwinden sollen, mein Problem bis jetzt war, das ich auch deckenlautsprecher benötige und diese dann einen kleinen Verstärker.
Und als Herausforderung, solllen die lautsprecher natürlich dann über iobroker noch spotify abspielen können :dizzy_face:

[tobetobe]

@System-9
Guten Morgen

@System-9 said in Rhasspy Offline Sprachsteuerung:

Um den master mache ich mir keine sorgen, läuft auf virtuell auf einem Server (24core 100gb Ram).

Das ist zwar etwas knapp, dürfte aber notfalls gehen:grin:

Nun aber im Ernst. Ich greife mal einige Stichworte von dir auf.

1. Richtmikrofone. Da muss ich dich natürlich erst einmal fragen, was du darunter verstehst. Echte Richtmikrofone weisen üblicherweise einen sehr schmalen Empfangswinkel auf. Außerhalb dieses Winkels sinkt die Empfindlichkeit rapide ab. Das ist im Zusammenhang mit Spracherkennung eigentlich genau das, was man nicht will.

Im Allgemeinen - und da sind die Profis wie Alexa etc sicher die besten Beispiele, haben sich nicht Richtmikrofone, sondern Mikrofon-Arrays durchgesetzt, die dank spezieller Eigenschaften "rundum" empfangen, aber dennoch für größere Distanzen (mehrere Meter) geeignet sind.

Die am meisten verwendeten Arrays stammen von ReSpeaker oder von Matrix.

2. Unterbringung in der Decke: Dies spricht für eine geringe Baugröße, steht aber zugleich im Widerspruch zu deinem Wunsch, Musik über Lautsprecher abspielen zu wollen. Beides gleichzeitig geht nicht ohne entsprechenden Raum zu spendieren, und zwar für Mikrofon, Prozessor, HiFi-Verstärker, Lautsprecher (ggf mehrere?, dann mit Frequenzweiche), Stromversorgung

Ich hoffe, du bist dir darüber im Klaren. Bzw. hier musst du dich entscheiden.

a) wenn es wirklich ganz klein ausfallen soll, dann ohne großen Audio-Teil. Hierfür gibt es zwei Möglichkeiten: Entweder die "einfachen" Mikrofon Arrays mit einem externen Prozessor. Hier reicht wohl schon ein Pi Zero (habe ich selbst noch nicht getestet) oder ein Pi3/4 mit 1 bis 2 GByte RAM. Oder man nimmt die Core Varianten der Mikrofone, die bereits einen Linux-Kern beinhalten und ohne weiteren Prozessor auskommen. Beide Mikrofon Varianten (mit und ohne Core) gibt es von beiden Herstellern.
b) wenn es der maximale Funktionsumfang sein soll: Dann das volle Programm wie unter 2 beschrieben, als Prozessor Pi4 mit 2 bis 4GByte RAM

Maßgeblich müsste deine Vorstellung zu den Lautsprechern und zur "Power" den Platzbedarf bestimmen. Mikrofon und Prozessor sind im Verhältnis nur Kleinkram. Persönlich könnte ich mir auch zu b) durchaus vorstellen, das alles in einem Deckenraum unterzubringen. Eines solltest du dann aber noch wissen: Selbstverständlich gibt es für dein Vorhaben kein Standardgehäuse. Da müsstest du dir auch selbst etwas bauen...

Und eines solltest du dir auch noch überlegen: Wenn du volle Möhre Musik hörst, die aus Lautsprechern kommt, die sich unmittelbar neben dem Mikrofon befinden, wie willst du dann noch einen neuen Sprachbefehl fehlerfrei erkennen lassen?

Was ich damit sagen will: Erst drüber nachdenken, was du wirklich willst, und dann die Ärmel hochkrempeln, ist besser, als einfach loslegen, Geld ausgeben und dann frustriert aufgeben, weil die eigene Vorstellung die Möglichkeiten überschreitet.

Soweit in Kürze.

Gruß
Thomas

[System 9]

@tobetobe
Zum Thema Platz, da gibt es jetzt auch noch keine Probleme, da dies gerade im bau ist, und die ganze Decke abgehangen ist (10cm) und noch offen ist, hier ist nur die Frage welche kabel da rein kommen, aber so wie ich das sehe werde ich auf die Variante mit dem Mikrofon-Array gehen. ->

Richtmikrofon hab ich mir erst bestellt, konnte ich selber noch nicht testen (bin selber am tüfftelt was am besten ist), aber wenn das so ist, mit dem empfangswinkel, hat sich das schon erledigt.

Aus den Deckenlautsprechern (gerne in einer anderen Ecke des Raumes) soll nur "normal" musik laufen, für alles andere gibt es die HiFi Anlage.

Das mit Musik und Sprachbefehl -> hier werd ich wohl in den Saurenapfel beißen müssen, wenn Musik gespielt wird, die Sprachbefehle nicht funktionieren -> Möglichkeit über ein Taster/Panel die Musik zu deaktivieren.

[tobetobe]

@System-9
Das ist ja prima, dass du noch so viele Freiheitsgrade hast. Dann würde ich dir zur Verkabelung in der abgehängten Decke folgendes empfehlen:

1. Am Ort des Mikrofons: 1 - 2 Steckdosen für 230V und ich würde LAN vorsehen, damit du vom WLAN unabhängig bist
2. Zwischen Lautprecher und Mikrofon: Lautsprecherkabel

Ob, oder besser wie gut, Sprachbefehle erkannt werden, kann man jetzt noch nicht so sagen. Du solltest wissen, das dies maßgeblich vom sogenannten Signal/Stör-Abstand abhängt, der wiederum von den räumlichen Distanzen und Lautstärkepegeln bestimmt wird. Also: Wie laut kommt die Musik am Mikrofon an und wie laut die Sprache. Befindet sich der Mensch nahe beim Mikro und die Lautsprecher weiter weg, wird es günstiger, umgekehrt ungünstiger. Das gleiche gilt für die Lautstärke: Je Lauter die Musik am Ort des Mikros im Verhältnis der Lautstärke der Sprache am Ort des Mikros, um so ungünstiger, je leiser die Musik, umso günstiger.

Von daher: Mikro vielleicht am besten über dem Tisch / über der Sitzgruppe und die Lautsprecher entsprechend abgesetzt. Meistens geht man da ja Richtung Wand.

Noch eins: Du sprachst in Summe von ca. 10 Mikros, die du verteilen möchtest. Wenn du nicht sicherstellen kannst, dass du überall gutes WLAN hast, leg LAN-Kabel hin.

Ich hatte bei mir leider nicht die Möglichkeit, da schon alles fertig war, und bedaure fast täglich die fehlenden Anschlüsse.

Gruß
Thomas

[joergeli]

@tobetobe
Hallo Thomas,

Zu Deiner Information:
@synesthesiam hat das MQTT-Problem jetzt als BUG deklariert:
https://github.com/rhasspy/rhasspy-voltron/issues/10

Ich habe gerade eben noch mal eine frische Rhasspy V 2.5-pre-Installation durchgeführt:
1.) Alles bisherige, was Rhasspy betrifft, gelöscht (docker container en/de, docker image, en-profile, de-profile).
2.) Rhasspy mit engl. Profil installiert

docker run -d -p 12101:12101  --restart unless-stopped -v "$HOME/.config/rhasspy/profiles:/profiles" --device /dev/snd:/dev/snd rhasspy/rhasspy:2.5.0-pre --user-profiles /profiles --profile en

GUI gestartet und als STT "Kaldi" gewählt --> fehlende Kaldi-Dateien werden heruntergeladen.
--> Rhasspy reagiert auf WakeWord "snowboy" und intent wird erkannt --> soweit alles gut.

3.) Docker-container mit engl. Profil gestoppt.
4.) Rhasspy mit deutschem Profil installiert:

docker run -d -p 12101:12101 --restart unless-stopped -v "$HOME/.config/rhasspy/profiles:/profiles" --device /dev/snd:/dev/snd rhasspy/rhasspy:2.5.0-pre --user-profiles /profiles --profile de

GUI nochmals gestartet und im deutschen Profil als STT ebenfalls "Kaldi" gewählt --> fehlende Kaldi-Dateien werden heruntergeladen.
--> Rhasspy reagiert auf WakeWord "snowboy" und intent wird erkannt --> soweit alles gut.

Soweit ist momentan - bis auf das Problem mit dem externen MQTT-Broker - alles OK.

Gruß
Jörg

[tobetobe]

@joergeli

Hallo Jörg,

vielen Dank für das Update. Die Einstufung deines Problems als Bug, hört sich nach größerem Zeitbedarf an. Schade.

Ich habe gestern ebenfalls mal zwei Installationen aufgesetzt, eine in einer Virtuellen Maschine (mein Master) und einen Satellliten auf einem alten Pi3. Beides lief absolut problemlos durch und auch Kaldi war sofort, bzw. nach dem erforderlichen Download, verfügbar. Ich installiere übrigens immer sofort das deutsche Profil und gehe nicht über den Umweg, erst das englische Profil zu installieren. Damit habe ich bislang noch nie Schwierigkeiten gehabt.

Momentan hänge ich eher daran, die neue Version noch zu konfigurieren. Ich finde es etwas verwirrend, dass nicht alle Einstellungen über das Menü links erreicht werden, sondern man dann für die Details oben über die grafischen Element, die den Installationszustand anzeigen, gehen muss.

Und dann hängst bei mir noch an einem Mikrofon. Ich habe zwar noch eine USB-Kamera mit Mikrofon, habe diese aber am Pi nocht nicht zum Laufen bekommen.

Und wenn mir die neue Release dann wieder zu nervig ist, befasse ich mich noch hiermit (nicht fertiger Bearbeitungsstand):

Dank deinen Tipps, bin ich dann doch recht flott voran gekommen. Auch habe ich festgestellt, dass man Verbindungen wieder löschen kann, ohne dass die Grundelemente verloren gehen. Und dass es beim Ausschneiden auf die Reihenfolge bei der Auswahl der Elemente ankommt. Also: Geht voran. Vielen Dank nochmals.

Gruß
Thomas

[joergeli]

@tobetobe
Hallo Thomas,
obwohl das nichts mit ioBroker/Rhasspy zu tun hat, noch ein paar Tipps bzgl. FreeCad, bzw. 3D-Druck von mir:

Ich habe anfangs auch versucht, viele zusätzliche optische Gimmicks und Schnörkel an meine Konstruktionen zu basteln.
Das hat aber Nachteile:
Zum einen verlängert es die Druckdauer immens und zum anderen, werden u.U. sog. Stützstrukturen erforderlich, die nur während des Druckens notwendig sind und später manuell weggebrochen werden müssen.

Ich versuche das mit den Stützstrukturen mal anhand Deiner Konstruktion zu erklären ( die gewölbten Lamellen an der linken Wandung):
Der 3D-Drucker druckt ja Schicht für Schicht von unten nach oben, somit kann er bei sog. Überhängen, d.h. Strukturen, die keinen direkten Druckbettkontakt haben, nicht einfach in die Luft drucken.
(Die würden dann z.B. "runterfließen", wie bei Salvador Dalis Uhrengemälde)
Deshalb müssen bei solchen Überhängen zusätzliche Stützstrukturen generiert werden, s. Bild

Ich habe im Bild mal versucht, die Überhänge zu identifizieren, bzw. die Stellen, an denen Stützstrukturen notwendig werden.
Die Stützstrukturen können vom Druckprogramm, dem sog. Slicer (ich verwende Cura) zwar automatisch generiert werden, es wird aber nach dem Druck u.U. schwierig, die nun überflüssigen Stützstrukturen zu entfernen (mit Seitenschneider rausprökeln).
Man könnte an Deinen Lamellen die Stützstrukturen vermeiden, in dem man beim Druck das Gehäuse um 90° im Uhrzeigersinn dreht, daß also die rechte Seitenwand unten zu liegen kommt, dann werden die Lamellen senkrecht gedruckt, es entstehen dort also keine Überhänge mehr.
Besser ist es aber, schon bei der Konstruktion so wenig wie möglich Überhänge zu erzeugen.
Natürlich kann man Stützstrukturen nicht immer vermeiden, aber weniger ist hier mehr.

Hier noch ein Screenshot von Cura, dem 3D-Druckprogramm, wo bei einem meiner Entwürfe eine 45°-Schräge abgestützt werden musste:

Das soll jetzt keinesfalls eine Belehrung meinerseits sein, ich möchte nur meine Erfahrungen teilen.
Was habe ich schon geflucht, wenn nach 8 Std. Druckdauer ein missglückter "Pimpel" in den obersten Schichten den ganzen Ausdruck unbrauchbar gemacht hat.

Gruß
Jörg

[tobetobe]

@joergeli
Hallo Jörg,
ich fluche auch gerade. Na ja, wieder was gelernt. Eine Hoffnung habe ich noch: Ich habe mich entschieden, zunächst mal keinen eigenen Drucker zu kaufen, sondern den Druck in Auftrag zu geben. Nun weiß ich dank deiner Hilfe wenigstens, welche Frage ich stellen muss.

Zu Übungszwecken mache ich mein Gehäuse jetzt einfach mal fertig. Vielleicht trenne ich die Seitenteile auch einfach ab und lasse sie senkrecht drucken. Dann klebe ich sie halt ein. An den anderen Stellen kann ich mit den Stützen glaube ich leben.

Ja, herzlichen Dank mal wieder und noch einen schönen Abend
Thomas

[joergeli]

@tobetobe
Hallo Thomas,
ich würde mir das mit in Auftrag geben noch mal überlegen.
Lt. einem Bekannten werden da recht ordentliche Preise verlangt.
Er hat mal ein Raspi-Gehäuse mit integrierter Pi-Cam Noir (mit Infrarotausleuchtung) drucken lassen, da waren dann 65,-€ fällig.

Wenn Du Dir einen Mittelklasse-3D-Drucker im Bereich von ca. 300,-€ zulegst, hast Du die Anschaffungskosten bald raus.
Verbrauchsmaterial (Filament) kostet ca. 20,-€ pro 1kg-Rolle und das reicht für div. Gehäuse und sonstiges.

Meine Frau meinte auch erst, was ich mit so einem Spielzeug will, aber als ich ihr dann ein paar Teile (Zubehör-Halter für Dyson-Staubsauger, Zahnpastatuben-Ausdreher, etc.) gedruckt habe, war der Drucker sofort akzeptiert ;-)

Ich selbst habe mir schon div. Gehäuse fur Raspi, ESP8266, NanoCUL-Stick, oder auch Staubsauger-Adapter für Bosch-Bandschleifer gedruckt.
Die Einsatzmöglichkeiten sind also sehr vielfältig.

Gruß
Jörg

[System 9]

@tobetobe
Hallo Thomas,
ich versuche mich gerade mit Rhasspy im Client/Server Modus
nach dieser Anleitung https://rhasspy.readthedocs.io/en/latest/tutorials/#client-steps

Leider ist mir noch nicht ganz klar wer jetzt das Intent Handling macht (beim Server steht da das es der Client macht, und beim Client fehlt der Punkt)
Bzw wie wird das intent handling "vollzogen" muss hierfür home assistent installiert werden ?

Grundsätzlich stellt sich mir noch die Frage was bringt Client/Server für vorteile, oder sollte ich doch in jedem raum ein extra Rhasspy server machen(technik wäre ja eh vorhanden dazu)

[tobetobe]

@System-9

Hallo,
ich habe mich bei meiner Installation (2.419, nicht 2.5-pre) immer an diese Anleitung gehalten und hatte nie Probleme:

https://community.home-assistant.io/t/rhasspy-offline-voice-control-step-by-step-server-client-docker/154015

Anders als bei deiner Anleitung, wird hier gesagt, dass der Master für das Intent-Handling verantwortlich ist, was mir auch logischer erscheint.

Bei mir, und wahrscheinlich bei dir auch, ist der Intent-Handler der ioBroker. Das Rhasspy-Team arbeitet selbst wohl mit Home Assistant (HA). Wenn du HA nicht betreibst, brauchst du es auch nicht zu installieren, weil die Aufgabe ja von ioBroker erledigt wird.

Vorteile von Client/Server:

Nun, wenn du nur einen Rhasspy im gesamten Haushalt betreiben möchtest, brauchst du diese Konfiguration nicht. In diesem Fall würde ein Raspi alle Aufgaben erledigen.

Beim Client/Server-Betrieb übernehmen die Satelliten (Clients) die Aufgaben der WakeWord-Erkennung und der Befehls-Erkennung. Der Master interpretiert die Befehle und schickt entsprechende Quittungen (Töne, Ansagen) sowie die Rohdaten des erkannten Befehls (also das zu steuernde Device, der State, etc) an den Client. Der Client gibt dann Töne und Quittungen lokal aus, steuert ggf die LEDs entsprechend und schickt die Rohdaten des Befehls über MQTT an den Intent-Handler (ioBroker). Der macht dann den Rest.

Soweit die prinzipielle Funktionsweise. Die Vorteile dieses Ansatzes sind:

• Der Master ist das Arbeitstier und kann entsprechend leistungsfähiger ausgelegt werden. Die Interpretation der Befehle verläuft dadurch schneller.

• Die Satelliten können folglich sehr klein ausgelegt werden, zB mit Pi Zero oder sogar ganz ohne Pi, wenn man die Core-Varianten der Mikrofon-Arrays einsetzt.

• Die Pflege des Systems ist sehr viel einfacher, da die komplexen Daten (Wörterbuch, Sentences, Slots, etc) zentral auf dem Master gehalten werden, und nicht auf zB 10 eigenständige Rhasspys verteilt werden müssen

• Das Aufsetzen eines neuen Satelliten geht schneller und ist deutlich einfacher

Noch ein Hinweis, was du noch auf der ioBroker Seite zu tun hast: Du benötigst einen MQTT-Server, der die Befehle von den Satelliten entgegennimmt und an ioBroker übergibt. Diesen MQTT-Server kannst du außerhalb von ioBroker installieren, oder du verwendest einfach den fertigen ioBroker -Adapter, was ich persönlich für den einfacheren Weg angesehen habe.

Damit aber noch nicht genug: ioBroker kann mit den MQTT-States so nichts anfangen. Du brauchst noch Skripte (in Javascript, Blockly oder Node-Red), die die MQTT-States dann in Befehle umsetzen, die deine Devices verstehen.

Aber alles kein Hexenwerk. Wir haben hier auf dieser Seite schon (fast) alles dazu zusammengetragen.

Viel Erfolg
Thomas

[tobetobe]

@joergeli

Hallo Jörg,

war ne toughe Woche. Jetzt habe ich nämlich endlich mein Backup für Rhasspy. Der Anlass: Weil ich vorher noch keins hatte. Sprich, ohne Zutun ist auf einmal die Mikro-SD verglüht. So durfte ich meinen Rhasspy-Satelliten nochmal komplett neu aufsetzen. Bin immer noch nicht ganz fertig...

Danke auch für dein Statement zum Drucker. Ich bin noch am Überlegen. Gegen einen eigenen Drucker sprechen momentan auch einige Gründe: Keine Zeit, kein Platz, kein Netzwerk dort, wo ich Platz habe, noch ne Baustelle usw.

Ich werde meinen Bekanntenkreis hier vor Ort abklappern.

Noch eine Frage: Hast du diese Diskussion mitverfolgt:

https://forum.iobroker.net/topic/31174/global-smart-home-community-alliance/

Könntest du dir vorstellen, dabei mitzumachen?

So, ich muss nun zurück zur "Arbeit".

Gruß und noch einen schönen Sonntag,
Thomas

[System 9]

Hallo,
erstmal ein Danke wegen dem Tipp mit dem Array Mikrophone, die sind echt genial und besser als richtmik´s.
Ich glaub mein Hauptproblem ist, das auf der iobroker seite, keine intents angelegt werden, der rhasspy ist zwar angelegt aber nicht die intents die schon im standard vorhanden sind.
Woran könnte das noch liegen ?!

[tobetobe]

@System-9
Hallo,
bei mir sieht das ein wenig anders aus:

image url)
Wie du siehst, müsstest du einen Ordner "intent" unterhalb von "Rhasspy" haben. Leg ihn und die States mal manuell an, damit die Daten reinlaufen können. Das war bei mir auch so. Die States müssen hierzu exakt den Namen deiner Sentences tragen.

Sobald Daten erkannt werden, findest du diese dann ganz rechts. NodeRed kann dann mit diesen States koppeln und weiter verarbeiten.

Gruß
Thomas

[System 9]

@tobetobe
Hallo,
nach einiger zeit tauchen die unter hermes/intent auf und könne mit Node Red abgegriffen werden.

Habe es jetzt auch mal über den Websocket probiert
ws://host:12101/api/events/intent, hier kommen sogar die wörter mit, die man gesprochen hat und man kann mit einem trigger, gleich alle Intents abfangen.

[joergeli]

Hallo Thomas,

@tobetobe sagte in Rhasspy Offline Sprachsteuerung:

Sprich, ohne Zutun ist auf einmal die Mikro-SD verglüht.

also wahrscheinlich ähnlich wie meine ioBroker Mikro-SD, die zwar noch per Putty erreichbar war, aber eine AVG-Load von 9.5 hatte, sprich: ioBroker war nicht mehr erreichbar, bzw. bedienbar.
Auch per SSH musste ich dann ca. 20 Sek. warten, bis ein Kommando angenommen wurde.

Ich hatte dann ioBroker mit einem älteren Backup-SD- Image vom Januar 2020 auf eine neuen Mikro-SD gezogen und
die fehlenden/geänderten Scripte ergänzt, sowie die zwischenzeitlichen Adapter-Aktualisierungen nachgezogen.
Jetzt tritt plötzlich ein merkwürdiges Phänomen auf:
Zeitweise schwankt die AVG-Load extrem, meist dümpelt sie zwar so um ca. 0.3-0.5/1min. vor sich hin, dann steigt sie - ohne ersichtlichen Grund - zeitweilig auf Werte bis zu 2.9.
Wenn die AVG sehr hoch ist, reagiert Rhasspy - logischerweise - nur noch sehr verzögert.

Ich habe schon verschiedene Tests durchgeführt, um den Grund der zeitweiligen hohen Last herauszufinden:
JavaScript-Adapter in ioBroker deaktiviert, nochmals ein aktuelles Image auf andere SD-Karte installiert, etc., trotzdem zeitweilig hohe Last. Kommt zwar recht selten vor, ist mir aber vorher nie aufgefallen.
Ich kann es auch nicht zeitlich eingrenzen, denn es laufen keine anderen Scripte o.ä., als vor dem Crash.

2 Möglichkeiten bleiben mir noch:
1.) Ich hatte hier im Forum gelesen, daß evtl. die Umstellung von File auf Redis die Last reduzieren könnte.
2.) Da ich jetzt ein aktuelles Backup habe, könnte ich den ioBroker-Raspi kpl. neu aufsetzen und dann das Backup restoren, was natürlich recht lange dauern wird, bis alle Adapter wieder installiert sind.
Unter Umständen restore ich damit aber auch die Ursache für die zeitweiligen hohen Systemlasten.
Schaun mer ma', ich beobachte das noch ein paar Tage.

@tobetobe sagte in Rhasspy Offline Sprachsteuerung:

Noch eine Frage: Hast du diese Diskussion mitverfolgt:
https://forum.iobroker.net/topic/31174/global-smart-home-community-alliance/
Könntest du dir vorstellen, dabei mitzumachen?

Ich habe das zwar gelesen, bin aber eher der Bastler, der im stillen Kämmerlein vor sich hinwerkelt.
In meinem Berufsleben habe ich genug mit AKüFis (Abkürzungsfimmlern), wie CEOs, Account- und was weiß ich für Managern, in Besprechungen, ähhh... Meetings zu tun gehabt und bin froh, daß das vorbei ist :face_with_rolling_eyes:
... also lieber ohne mich.

Rhaspy V2.5-pre:
Ich zähle schon nicht mehr, wie viele neue Releases ich in letzter Zeit davon schon installiert habe, aber ich kann immer noch nicht testen, da die externe MQTT-Verbindung mit ioBroker nicht funktioniert.
Es sind wohl andere Prioritäten vom Rhasspy-Team gesetzt.

Falls das auch in der finalen 2.5 nicht funktionieren sollte, bleibe ich bei der V 2.4.19.
Die funktioniert, bis auf die False-/Positive-Erkennungen von Snowboy, bzw. "Lieselotte", ganz gut.

Bis demnächst
Jörg

P.S.
Heute nachmittag ist es mir zum ersten Mal bei der Installation der 2.5-pre gelungen, Kaldi sofort erfolgreich mit dem DE-Profil zu installieren ( also nicht erst EN-Profil und anschl. DE-Profil)

P.P.S.
Hast du gelesen, daß KITT.AI, bzw. Snowboy, Ende 2020 eingestellt wird?

[tobetobe]

@joergeli

Hallo Jörg,

Systemlast: Ein stabiler Betrieb von ioBroker ist natürlich essentiell. Ich hoffe, du bekommst dein Problem rasch in den Griff. Ich sehe noch eine dritte Möglichkeit, um nicht evtl den Grund für die Zähflüssigkeit mit einem Backup wieder mit zu installieren. Und zwar: Aufsetzen eines frischen Linux und ioBroker und dann ein Backup von /opt/iobroker wieder einspielen. Nachteil: Wenn du sonstige Pakete installiert hattest, müssen diese ebenfalls neu installiert werden. Aber, wem sage ich das...

Noch ein Hinweis: Ich habe bei meiner Migration von Raspberry auf Odroid H2 auch ein Backup restored, und alle Adapter waren mit dem Backup sofort wieder verfügbar. Es dauert also nicht so lange, wie befürchtet.

Rhasspy V.2.5-pre: Begeisterung kommt bei mir noch nicht auf. Ich habe sie noch nicht zum Laufen bekommen. Ich habe mir jeweils auf Master und Satellit einen Batch gelegt, mit dem ich jeweils die Profile für 2.4.19 und 2.5 sichere, bzw zurückspiele und die jeweils gewünschte Version starte. So bringe ich meine lauffähige 2.4.19 nicht durcheinander und kann immer wieder mal testen. Bei mir hängt sich mit 2.5 der Satellit immer auf. Da hilft dann nur noch der Weg übers Steckernetzteil. Das war wohl auch der Grund für die zerschossene SD.

Snowboy: Ich denke mal, dass uns das kurzfristig nicht berühren wird. Zitat von GitHub:

Our github repositories will remain open, but only community support will be available from this point beyond.

Die Communities werden sich also voraussichtlich schon um die weitere Pflege kümmern. Und wenn nicht: Rhasspy basiert ja zum Glück auf einer sehr offenen Architektur. Dann nimmt man halt in 2021 oder später eine aktuelle Alternative. Bin dabei ganz entspannt.

Viele Grüße
Thomas

[joergeli]

@tobetobe
Hallo Thomas,

wie bekommst Du denn mit der 2.5 Deine Intents in ioBroker, nicht wie ich via ioBroker-MQTT-Adapter ???

Ich habe das Problem, daß ich in der GUI von Rhasspy zwar einen externen MQTT-Broker (<IP>, Port 1891) eintragen kann und im ioBroker-Log sehe ich dann, daß sich Rhasspy auf div. Topics subscribed.
Allerdings erfolgen zwischen den Subscriptions mehrere disconnections/connections, keine Ahnung, ob das OK ist.

Weiter komme ich nicht, weil Rhasspy nach Aktivierung des externem MQTT-Brokers weder auf WakeWord, noch auf WakeUp-Button reagiert.

Stelle ich wieder auf den internen Rhasspy-MQTT-Broker zurück, reagieren sowohl WakeWord, als auch WakeUp-Button einwandfrei.

Wegen meinem ioBroker-Auslastungsproblem:
Wieviel RAM gönnt sich bei Dir der Admin-Adapter? Bei mir sind es knapp 190 MB:

Gruß
Jörg