Perl - Modul 10_RHASSPY.pm "professionalisieren"

Begonnen von drhirn, 18 Februar 2021, 17:02:31

Vorheriges Thema - Nächstes Thema

drhirn

Updating Rhasspy Slots with data (de): {"de.fhem.Color":1,"de.fhem.Device":1,"de.fhem.MediaChannels":1,"de.fhem.NumericType":1,"de.fhem.Room":1}

Jetzt haben wir dann bald alle Möglichkeiten durch :D

Beta-User

#166
puh, jetzt sollte es gehen...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

drhirn

Jeeeeee :)

Was war jetzt der Schlüssel zum Erfolg?

Beta-User

Dereferenzierung des übergebenen Parameters... (shift bei get_unique() vergleichen).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

drhirn

Gut, da wäre ich nie drauf gekommen.

Hui, und der Timer redet auch wieder richtig! Ich bin grenzenlos begeistert.

Für mehr Tests habe ich jetzt leider keine Zeit. Da wollen Mäuler gestopft werden. Ich hoff, ich komm morgen dazu.

Danke dir!

Beta-User

#170
So, hoffe, es hat vielfach gemundet und schaffe mal Platz für noch mehr Tests:

- Der Parser für die eigenen Intents ist umgebaut, und der Weg macht nach meinem jetzigen Verständnis auch Sinn, wenn man Parameter aus der Rhasspy-Analyse mitgeben will (wie bei der Wikipedia-Anfrage). Anm.: Für parameterlose Perl-aufrufe ist m.E. der Shortcuts-Weg der elegantere.

Allerdings ist mir völlig unklar, warum da scheinbar immer der $hash (->RHASSPY-Instanz) mit übergeben wird? Müßte eigentlich bei der hier üblichen Notation der Perl-Funktionen in myUtils mit Prototypen Mismatches werfen. Aber vielleicht übersehe ich auch mal wieder was...
Stand: Ungetestet.

- die deutsche Sprachkonfiguration ist jetzt außerhalb des Moduls untergebracht,  ist es auch configDB-kompatibel 8) (einen Test betr.  Migration nach configDB habe ich aber nicht gemacht).
Kann die nicht geladen werden, wird eben englisch gesprochen...
(Der englische default-Teil sollte vermutlich auch noch JSON-encoded abgelegt werden, dann müßte es auch mit o'clock funktionieren.)

Soweit erkennbar, klappt es auch, die Sprach-Daten über
set <rhasspy> reinit language neu einzulesen, wenn man was angepasst hat.
Die als Muster angehängte cfg enthält - soweit ich das überblicken kann - alle "de-Strings" und damit mehr, als im Moment aufgelöst werden können, und mit der (im Modul bereits vorher vorhandenen) eval { }-Variante können auch Variablen relativ einfach aufgelöst werden :) . (siehe time und weekday-requests, wobei ich mir nicht sicher bin, ob es Sinn macht, für jede mögliche Frage eine Routine zu basteln).

Bestimmte Dinge, die regional unterschiedlich sein können, sind jetzt optional (Punkt=>Komma, mutated_vovels).

Was vermutlich (in weiten Teilen) nicht optimal ist, ist die Verwendung von regexen als keys für die Hashes. Das aufzudröseln, wäre vermutlich sinnvoll, allerdings sollten wir einen Weg finden, wie man das machen kann, ohne alle Texte mehrfach eingeben zu müssen... Könnte man auch über loops lösen, ist aber m.E. unelegant. Ging jetzt aber erst mal darum den Weg zu zeigen, wie man Sprache und Code einigermaßen entkoppeln kann und das Regexen ggf. durch Hash-Lookups schneller zu erledigen. Von daher würde mich erst mal interessieren, ob das ein guter/gangbarer Weg ist...

Überhaupt Doppelarbeit: eigentlich müßte es in Teilen doch für sowas Standardlibs geben, die man anzapfen könnte...? Also, falls da jemand was kennt?

Na ja, wie dem auch sei: erst mal viel Spaß beim Testen und Überlegen, ob das in dieser Form prinzipiell Sinn macht oder nicht. 8)

Nachtrag - "Bedienungsanleitung":
Sprachfile irgendwohin speichern, wo fhem Zugriff hat, also z.B. nach /opt/fhem/rhasspy-de.cfg (fhem:dialout).
In das configFile-Attribut den Pfad geben:
attr <rhasspy> configFile./rhasspy-de.cfg
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Beta-User

#171
...und nun wird es experimentell...

Diese Version kann dann erst mal in wesentlichen Teilen nur deutsch, müßte aber dafür alle Vergleiche usw. aus der Sprachfile ziehen. Will sagen: Spanisch ist im Bereich des Möglichen 8) .

Wenn das klappt, müßte man erst überlegen, ob die JSON-Struktur so "gut" (auch im Sinne von ggf. ausbaufähig) ist, und wenn das soweit geklärt ist dann asap ins Englische übersetzen, damit keiner auf die Nase fällt, der es ohne Sprachdatei versucht...

EDIT: jetzt sollte auch der englische Teil vollständig sein...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

drhirn

Ich habe - wie gesagt - zur Zeit ein bisschen viel um die Ohren. Drum war ich da so still. Heute sieht's aber ganz gut aus. Werde daher gleich mal anfangen zu testen. Hab da ja einiges aufzuholen.

Zuerst mal: Der aktuelle Stand von dir ist im Github in Version 0.4.0beta verewigt. Die rhasspy-de.cfg habe ich auch ins Repo aufgenommen.

Dann: Das funktioniert :). Zumindest hat ein Kurz-Test nichts Gegenteiliges ergeben.

Und zuletzt: Danke!

Eine Bitte hätte ich noch: Könntest du bitte bei Gelegenheit die CRef mal überfliegen? Ich bin mir nicht ganz sicher, ob ich da alles dokumentiert habe. Und richtig. Ich mach mich in der Zwischenzeit ans Testen.

Beta-User

#173
Zitat von: drhirn am 05 März 2021, 11:04:19
Ich habe - wie gesagt - zur Zeit ein bisschen viel um die Ohren. Drum war ich da so still. Heute sieht's aber ganz gut aus. Werde daher gleich mal anfangen zu testen. Hab da ja einiges aufzuholen.
Kein Problem, so hatte ich auch Ruhe, um den einen oder anderen Gedanken auszutesten (nachdem ich mir überlegt hatte, wie man das ohne Rhasspy testen kann)...

Zitat
Zuerst mal: Der aktuelle Stand von dir ist im Github in Version 0.4.0beta verewigt. Die rhasspy-de.cfg habe ich auch ins Repo aufgenommen.

Dann: Das funktioniert :) . Zumindest hat ein Kurz-Test nichts Gegenteiliges ergeben.
8)
Danke für die Rückmeldung!

Ist denn (in groben Zügen) klar, wie es funktioniert?

Zitat
Eine Bitte hätte ich noch: Könntest du bitte bei Gelegenheit die CRef mal überfliegen? Ich bin mir nicht ganz sicher, ob ich da alles dokumentiert habe. Und richtig. Ich mach mich in der Zwischenzeit ans Testen.
Mache ich bei Gelegenheit.

Ich habe aber gemerkt, dass noch ein Teil der Rückmeldungen/Abfragen noch gar nicht fertig ist (da wird dann noch auf die harten de-Codes zurückgegriffen.

Das ist in den beiden angehängten Dateien zum Teil korrigiert, vermutlich kannst du daran gut sehen, wie die Baustelle in etwa bearbeitet werden soll - wir brauchen dann hoffentlich nur am Ende noch eine Abfrage, ob wir einen Hash vor uns haben (dann $response->{$isNumber}) oder nicht...
Da scheint mir aber auch noch ein "Loch" in der cfg zu sein.
Habe aber im Moment noch keinen Plan, wie ich das Testen kann, von daher wäre es gut, wir wären soweit sicher, dass diese Baustelle bis dahin erst mal funktioniert. Da habe ich nur noch keinen Plan, wie ich das selbst testen könnte...

ZitatUnd zuletzt: Danke!
Gerne!

EDIT: Nachtrag noch zur Statistik
Total lines:2439
Code lines:1549
Comment lines:317
Data lines:1
Blank lines:410
POD lines:162
Total violations:70
Severity 5:
0
Severity 4:
0
Severity 3:
70
Total subroutines:
64
Average McCabe:
6,95
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

drhirn

Zitat von: Beta-User am 05 März 2021, 11:17:09
(nachdem ich mir überlegt hatte, wie man das ohne Rhasspy testen kann)

Ich bin jederzeit gerne bereit, dich bei einer Rhasspy-Test-Installation zu begleiten. Mit Docker ist das fix erledigt. Und kann rückstandslos wieder gekübelt werden. Brauchst nur ein Mikro/Webcam für den Betrieb. Wenn's dich interessiert.

ZitatIst denn (in groben Zügen) klar, wie es funktioniert?

In groben Zügen. Im Detail hab ich's mir noch nicht angesehen.

drhirn

Hast du in der letzten 10_RHASSPY.pm Änderungen von gestern wieder rückgängig gemacht? Bin gerade ein bisschen verwirrt.

Beta-User

Zitat von: drhirn am 05 März 2021, 11:57:08
Hast du in der letzten 10_RHASSPY.pm Änderungen von gestern wieder rückgängig gemacht? Bin gerade ein bisschen verwirrt.
Au; wenn, dann unbeabsichtigt... :o >:(

(Basis war aber (hoffentlich) meine gestrige Version, nicht deine von github, von daher sind gewisse Differenzen normal).

Grummel, vermutlich muss ich mir das selbst anschauen, was ich da angerichtet habe; nicht alles dürfte falsch sein... (geht aber nicht sofort). Vielleicht kannst du ja auch versuchen nachzuvollziehen, was ich mir mit den heutigen Änderungen so gedacht habe (da ist aber auch einiges noch (auskommentiert) drin, das nicht funktioniert hat).

Zitat von: drhirn am 05 März 2021, 11:42:50
Ich bin jederzeit gerne bereit, dich bei einer Rhasspy-Test-Installation zu begleiten. Mit Docker ist das fix erledigt. Und kann rückstandslos wieder gekübelt werden. Brauchst nur ein Mikro/Webcam für den Betrieb. Wenn's dich interessiert.
Danke für's Angebot, aber so einfach ist es vermutlich dann doch nicht:
- Die docker-Basis ist derzeit bei keinem meiner Server installiert (ok, kann man auch rückstandsfrei, und evtl. findet sich ja noch ein alter Pi im Keller...)
- Mikro ist zwar vorhanden, aber wenn, dann nur eins mit Kabel oder ich muss mir was mit BT überlegen.
=> relativ viel Aufwand, denn selbst wenn ich das soweit dann zusammengeschustert habe, fehlen zu guter Letzt- die entsprechenden settings in meinen FHEM-Devices, damit man die abfragen kann...

Kurzum: mit den entsprechenden dummy- (oder mqtt2-) Devices und passenden Topic-payload-Infos kann ich das "gezielter" simulieren ;) . Habe mir nur noch nichts überlegt für die Abfragen usw., das ist einfach zu neu.

Wenn, dann würde ich überlegen wollen, ob ich ein "Bedienungs-FHEM" bastle und das dann via MQTT_GENERIC_BRIDGE mit den "eigentlichen Devices" fülle und darauf dann Rhasspy loslasse - setzt aber voraus, dass es möglich wäre, eine Art "einfacher Funk-Mikrophone" zu nutzen, um einen zentralen Rhasspy anzusteuern. (Super wäre eine handy-app, die man kurz aktivieren kann, damit die den "Sound" an die Zentrale schickt, aber sowas scheint es nicht zu geben).

Zitat
Im Detail hab ich's mir noch nicht angesehen.
Grundzüge sind erst mal ok, in die Details kommt man am einfachsten rein, wenn man sich die Struktur der Sprachdaten im list anzeigen läßt.

Tipp für's Editieren der JSON-Struktur: https://jsoneditoronline.org/ (aber ruhig auch mal austesten, was passiert, wenn du es mit einem "malformed" versuchst...).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

drhirn

Zitat von: Beta-User am 05 März 2021, 12:14:43
Danke für's Angebot, aber so einfach ist es vermutlich dann doch nicht:

Ich teste auf meinem Windows-Rechner. Der hat sowieso Boxen und Webcam. Docker startet eine FHEM- und zwei Rhasspy-Instanzen. Und als FHEM-Devices habe ich ein paar Dummies.

drhirn

Zitat von: Beta-User am 05 März 2021, 12:14:43
(Super wäre eine handy-app, die man kurz aktivieren kann, damit die den "Sound" an die Zentrale schickt, aber sowas scheint es nicht zu geben).

https://github.com/razzo04/rhasspy-mobile-app

Hab ich aber noch nicht ausprobiert.

Beta-User

#179
Hm, also: Hab's mal soweit überflogen, auf Basis deiner 0.4.0 beta von ca. 11:00 Uhr (ec5457bcd3a24848ddb41b0433f98e3da4cce6da).

Da sind nicht die riesigen Änderungen drin gewesen gegenüber dem, was ich gestern gemacht hatte, oder ich übersehe was.

Habe dann beim Überfliegen noch den einen oder anderen kleineren Punkt geändert, aber (hoffentlich) nichts substantielles, playWav sollte auch weiter gehen.

Das mit der App ist interessant, vielleicht werde ich doch noch zum aktiven Nutzer...? Mal sehen... (Wenn, komme ich auf dein Angebot zurück, falls Fragen auftauchen :) ).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files