FHEM und Rhasspy

Begonnen von drhirn, 28 Juli 2020, 14:28:50

Vorheriges Thema - Nächstes Thema

drhirn

Ich hab keine Probleme mehr mit Umlauten. Wurde in einer neueren Version von Rhasspy behoben. Weiß aber nicht mehr welche.

JensS

Danke, mit der Version 2.5.8 klappts. Es gab allerdings einige Probleme mit nicht verfügbaren Paketen bei der Installation auf meinem AMD64-System. Diese habe ich per Hand heruntergeladenwget http://ftp.br.debian.org/debian/pool/main/g/gcc-6/libgfortran3_6.3.0-18+deb9u1_amd64.deb
wget http://ftp.debian.org/debian/pool/main/g/gcc-6/gcc-6-base_6.3.0-18+deb9u1_amd64.deb

und installiert. Anschließend lief die Rhasspy-Installation fehlerfrei durch.

Gruß Jens
Debian auf APU2C4, HM-CFG-USB2, SIGNALduino, HM-ES-PMSw1-Pl, 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.

drhirn

Ich habe mal angefangen, das Modul zu dokumentieren. Bzw. die Doku von Thyraz übernommen. CommandRef gab's eh schon. Jetzt aber ein bisschen ausführlicher.
Ist auf englisch. Hat sich als dumme Idee heraus gestellt. Aber da war's schon zu spät.

Bin noch nicht fertig, wird aber ständig ergänzt.

Mitarbeit ist herzlich willkommen. Außerdem gibt's am Schluss der Doku noch eine To-Do Liste ;).

https://github.com/drhirn/fhem-rhasspy/blob/master/README.md


JensS

@drhirn
Ich hätt da noch ein kleines Python-Script zur Ansteuerung einer LED. Hast du einen Vorschlag, wos das am besten passt?
Gruß Jens
Debian auf APU2C4, HM-CFG-USB2, SIGNALduino, HM-ES-PMSw1-Pl, 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.

drhirn

Du kannst ja einfach auf GitHub im Readme einen neuen Abschnitt "Tipps" oder so machen. Oder lass es hier und ich mach das morgen.

JensS

#125
@drhirn

Anbei meine LED-Steuerung. Ist quick $ dirty...
Nach dem Wakeword wird die mittlere LED grün und anschließend bis zum Ende des Prozesses blau. Anschließend erlischt die LED wieder.
Man kann die Funktion durch einen kurzen Tastendruck auf den Button (de)aktivieren.
Drückt man 3 Sekunden, wird das Mikro aus- bzw. angeschaltet.
Hält man den Button 10 Sekunden gedrückt, leuchtet die LED für 2 Sekunden rot und der RPI wird heruntergefahren. Nach ca. 30 Sekunden kann man ihn dann vom Strom trennen.
Meine Programmierkenntnisse sind eher dürftig, so dass ich dich bitte, dir das Ganze mal anzuschauen und zu testen.

Gruß Jens

p.s. Die Abfrage bnutzt paho-mqtt, welches ich mitapt-get install python3-paho-mqttinstalliert habe.
p.p.s. LED.py ist neu.
p.p.p.s. Liegt jetzt hier: https://github.com/jens-schiffke/Rhasspy-LED
Debian auf APU2C4, HM-CFG-USB2, SIGNALduino, HM-ES-PMSw1-Pl, 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.

drhirn

Hast du das eh auf GitHub? Dann könnten wir ja einfach drauf verlinken?

Meine Programmierkenntnisse sind jetzt auch nicht gerade der Hit ;)

drhirn

Zitat von: JensS am 14 Januar 2021, 21:54:05
Nach dem Wakeword wird die mittlere LED grün und anschließend bis zum Ende des Prozesses blau. Anschließend erlischt die LED wieder.

Welche LED? Bei mir leuchtet leider nichts.

drhirn

Zitat von: JensS am 08 Januar 2021, 19:19:35
Da ich eine von Rhasspy jedesmal eine Bestätigung haben möchte, welches Gerät gerade geschalten wurde, habe ich eine sub in 99_myUtils.pm eingefügt:

https://github.com/drhirn/fhem-rhasspy/blob/master/README.md#rhasspy-speaks-actual-state-of-device-after-switching-it

jowe

Ich habe mittlerweile auch mein FHEM von Snips auf Rhasspy umgestellt. Danke drhirn für deine Arbeit! Danke auch JensS für dein Codeschnippsel, ich habe das auch bei mir umgesetzt. Allerdings habe ich das Problem, dass meine Hue-Lampen noch am runter-/raufdimmen sind, wenn die Antwort schon kommt. Wenn ich also eine Lampe einschalte, kommt die Antwort dass die Lampe jetzt aus ist, da sie gerade erst mit dem hochdimmen beginnt. Und beim Ausschalten anders rum. Hat jemand eine Idee, wie ich das Antwort Script mit 1-2 Sekunden Verzögerung starten kann, ohne dabei FHEM zu blockieren?

drhirn

Ich habe dazu leider keine schlaue Idee. Wäre gut zu lösen, wenn FHEM die aktuelle Helligkeit der Lampe kennen würde. Aber das ist leider nicht der Fall.
Du könntest natürlich auch einfach einen at Befehl setzen, der die Sprachausgabe einfach später auslöst.

Aber wärst du so nett und würdest schreiben, was du für Hardware verwendest? Und welches Wakeword?

jowe

FHEM kennt die aktuelle Helligkeit. Nur haben Lampen halt eine transition time, während der die Helligkeit runter geregelt wird. Ich bekomme also die aktuelle Helligkeit während dem runter dimmen ausgegeben. Das lässt sich nur lösen, wenn die Sprachausgabe erst nach Ende des Dimmens erfolgt. Mittels sleep würde ich mir aber mein FHEM währenddessen blockieren soweit ich weiß. Vielleicht hat einer der Mitlesenden ja eine Idee dazu.
Ich nutze Rhasspy aktuell auf einem PI4 mit RespeakerArray V2 im Docker Container. Als Wakeword nutze ich ein mittels Raven selbst aufgezeichnetes. Ich bin mit der Wakeword Erkennung wie auch mit der Spracherkennung allerdings noch nicht wirklich zufrieden. Ich überlege, ob ich mir wieder einen Satelliten mit Snips-Hotword Erkennung einrichte und die Spracherkennung auf dem Pi mache. Hauptsächlich nutze ich aktuell die Befehle per TextCommand über Telegram bzw. über die Rhasspy-App. Das funktioniert super.
Ich hoffe auf weiter Verbesserungen bei Rhasspy in der Zukunft..

JensS

#132
@jowe
Wenn du nur eine Rückmeldung des zu erwartenden Status haben möchtest, kannst du das mir einem zusätzlichen Reading lösen.
rhasspyMapping:SetOnOff:cmdOn={fhem("set $DEVICE on;setreading $DEVICE rhasspySTATE an")},cmdOff={fhem("set $DEVICE off;setreading $DEVICE rhasspySTATE aus")},response={my $Name = (split(/,/,AttrVal($DEVICE,"rhasspyName","error")))[0];my $Status = ReadingsVal($DEVICE,"rhasspySTATE","im unbekannten Status");return "Ok - $Name ist $Status"}Ist zwar ganz schön lang aber dafür flexibel.
Raven finde ich auch gut, weil man selbst das Wakeword einsprechen kann. Ist aber leider viiiiel zu langsam.

@drhirn
mic_hat ist nicht von mir, beinhaltet aber wichtige Dateien.
Was passiert, wenn du "python3 /opt/mic_hat/LED.py" ausführst.
Debian auf APU2C4, HM-CFG-USB2, SIGNALduino, HM-ES-PMSw1-Pl, 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.

drhirn

Zitat von: JensS am 15 Januar 2021, 17:39:49
Raven finde ich auch gut, weil man selbst das Wakeword einsprechen kann. Ist aber leider viiiiel zu langsam.

Ganz frisch, ein Wakeword-Generator für Snowboy: https://github.com/rhasspy/snowboy-seasalt
Funktioniert super.


Zitat von: JensS am 15 Januar 2021, 17:39:49
@drhirn
mic_hat ist nicht von mir, beinhaltet aber wichtige Dateien.
Was passiert, wenn du "python3 /opt/mic_hat/LED.py" ausführst.

Ha, lustig. Jetzt leuchtet doch die blaue LED. Aber nur, wenn mir Rhasspy antwortet. Und jetzt leuchtet's grün, dann blau. Und jetzt leuchtet's gar nicht mehr. Hä?
Komisches Verhalten. Werde ich dann weiter testen.

JensS

@drhirn
Und - wie leuchtet es jetzt? Was ist überhaupt aus der Wakeword-Erkennung geworden. Geht's jetzt auch über weitere Entfernung?
Debian auf APU2C4, HM-CFG-USB2, SIGNALduino, HM-ES-PMSw1-Pl, 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.