Modulentwicklung für Rhasspy Sprachassistent

[Beta-User]

Das use feature ändert zwar nichts.

Doch, schon, anderswo. Aber leider in die völlig falsche Richtung ...

Wir müssen nur irgendwie den Raum "kleinkriegen", sonst passt das nicht zur sonstigen Logik.
Hier mal der Versuch, das (und das Colortemp-Mapping unter dem Namen "colorTempMap") zu fixen. Bin mal gespannt, ob beides so klappt...

Code Auswählen Erweitern

attr lampe1 rhasspy3Specials colorTempMap:0="command set_white" 50="command set_white" 100="command set_white"

[drhirn]

Keine guten Nachrichten bezüglich Umlauten. Hat sich nichts geändert

[Beta-User]

...bedeutet: wir lassen das mit lc erst mal weg?

Code Auswählen Erweitern

$room = ReadingsVal($hash->{NAME}, $rreading, $siteId);

Ausgesprochen unschön. Habe Sorge, dass dann das mit dem Auffinden des richtigen Devices häufig schiefgehen wird, weil wir überall sonst von Kleinschreibung ausgehen, und die Hash-lookups nur klappen, wenn es 1:1 paßt... Sehe aber grade keine andere Option.
Vielleicht ist auch das use utf8-Pragma nicht glücklich?

[drhirn]

Wir lassen's so, wie's war. Das Verhalten ist nicht konsistent.

Gestern hatte ich z.B. sowas im Log:

Code Auswählen Erweitern

Msg: hermes/dialogueManager/sessionStarted => {"sessionId": "küche-porcupine_raspberry-pi-68a2c8a4-986d-4e38-bb6d-9f4516afe32f", "siteId": "küche", "customData": "porcupine_raspberry-pi", "lang": null}

Heute sieht das so aus:

Code Auswählen Erweitern

hermes/dialogueManager/sessionStarted => {"sessionId": "küche-porcupine_raspberry-pi-a5fdee9a-5bff-4405-90a0-31edae13c13e", "siteId": "küche", "customData": "porcupine_raspberry-pi", "lang": null}

Und darauf hat nichts, was wir gemacht haben, einen Einfluss.

So lange kein anderer testet, können wir eigentlich nichts dazu sagen. Vielleicht liegt's ja wirklich an mir.

[Beta-User]

Glaube nicht, dass das an dir liegt!

Jedenfalls scheint ein utf8::downgrade() vorab dann die "kleine Küche" via lc zu erzeugen, wenn die Message sauber reinkommt.
Evtl. müssen wir da noch tweaken, und ich hoffe auch sehr, dass das nicht den downgrade kaputt macht....

[drhirn]

Bevor ich's jetzt gleich wieder überschreibe nur zu Dokumentationszwecken eine Lösung, die bei mir gerade funktioniert:

Code Auswählen Erweitern


    my $siteId = decode('UTF-8', $data->{siteId});
    $siteId = lc $siteId;
    $siteId = encode('UTF-8', $siteId);


Und ich suche gerade eine Website, die mir den Unterschied zw. utf8 und UTF-8 so erklärt, dass ich ihn auch verstehe [/code]

[drhirn]

Glaube nicht, dass das an dir liegt!

Jedenfalls scheint ein utf8::downgrade() vorab dann die "kleine Küche" via lc zu erzeugen, wenn die Message sauber reinkommt.
Evtl. müssen wir da noch tweaken, und ich hoffe auch sehr, dass das nicht den downgrade kaputt macht....

Funktioniert auch.

Wir haben aber noch ein Mischmasch us utf8 (hash encoding,getRoomName) und UTF-8 (initialize_Language,parseJSONPayload)

[Beta-User]

Ja, ist irgendwie unschön.

Ich würde (begründet im Moment leider nur durch Bauchgefühl!) aber die Stellen auf dem "einstellbaren" Encoding lassen, wo es nicht nachweislich zu Problemen kommt. Da das bei getRoom die einzige Stelle ist, wo das problematisch zu sein scheint, würde ich das ausschließlich da belassen, und irgendwie sagt mir auch der downgrade im Moment mehr zu. Letztlich ist das für mich aber black box und geraten...

Hartcodiert würde ich den UTF-8-Parameter jedenfalls nicht stehen lassen, bestenfalls den Verweis auf das allgemein genutzte encoding. Up to you...

[drhirn]

Gut, gut. Ich hab da alles auf $cp (oder UTF-8) umgestellt. Konnte bisher keine Probleme feststellen. Außer im Logfile. Warum auch immer.

Wo bist du denn über Unstimmigkeiten gestolpert? Nur damit ich weiß, was ich testen muss.

[Beta-User]

RHASSPY selbst sah dann in der Detailansicht an der einen oder anderen Stelle "komisch" aus, wenn ein Umlaut da war (da waren die UTF-8-Oktetts (?) zu sehen).
Wenn du das nicht auf die Schnelle nachvollziehen kannst, aber Umlaute drin hast: einfach ignorieren...

(Falls du dann wieder einen konsolidierten gemeinsamen Zwischenstand hast: Bitte wieder nach github (oder ins svn...), nur für den Fall, dass ich noch über was stolpere. Ansonsten werde ich irgendwann noch das mit der Colortemp-"Brücke" testen, denn wenn, kann das Modul jetzt für den Moment das, was es _ aus meiner Warte gesprochen - können sollte - wenn man von "matches in room" absieht. Das ist aber vermutlich ein dickeres Brett bzw. ggf. muss ich auch erst mal testen, ob es überhaupt erforderlich ist, da irgendwas einzuschränken statt schlicht mit dem "Gesamtslot" in einem intent "MakeChoice" zu arbeiten. (Link für später mal: https://community.rhasspy.org/t/add-context-setting-to-intents-easy-building-dialogues-problem-and-solution/2434))

[drhirn]

Gerade in der Sekunde erledigt . Aktuell ist die "dev".

[Beta-User]

So, aktuell läuft :

Code Auswählen Erweitern


File                            Rev   Last Change 10_RHASSPY.pm                   24343 2021-04-27 13:11:33Z drhirn
Und mit passendem colorTempMap bekomme ich das dusselige MiLight-MQTT2_DEVICE-Ding dann auch endlich wieder aus weiss:

Code Auswählen Erweitern

attr Licht_Stehlampe_links rhasspySpecials colorTempMap:0="command Weiss" 85="command Weiss" 100="command Weiss"


Bei der Gelegenheit: Evtl. sollte man in der de-cfg unter "slots" noch was für Colortemp hinterlegen, wobei ich noch nicht sicher bin, ob die drei Varianten in der jetzigen Form gut sind. Bei Leuchtmitteln, die wirklich den gesamten Bereich abdecken, ist es eher so, dass die bei Warmweiss beginnen (2700 Kelvin), dann "normales Tageslichtweiss" auf ca. 3000 Kelvin haben und dann aber "Arbeitsweiss" bis 6500 Kelvin definieren. Dusseligerweise "denkt" der Slider von meinen Hue grade anders herum... Wie dem auch sei, mit "85" für das "mittlere weiss" kann sich das Ergebnis "sehen lassen".

[drhirn]

Hab noch die beiden gefunden. Weiß aber nicht, wo sie her kommen. Passiert mir immer beim Neustart.

Code Auswählen Erweitern


2021.04.28 09:05:44.343 1: PERL WARNING: Useless use of private variable in void context at ./FHEM/10_RHASSPY.pm line 1691, <$fh> line 308.
2021.04.28 09:05:44.351 1: PERL WARNING: Use of uninitialized value $old_prefix in string eq at ./FHEM/10_RHASSPY.pm line 412, <$fh> line 308.


[Beta-User]

Hab noch die beiden gefunden. Weiß aber nicht, wo sie her kommen. Passiert mir immer beim Neustart.

Code Auswählen Erweitern


2021.04.28 09:05:44.343 1: PERL WARNING: Useless use of private variable in void context at ./FHEM/10_RHASSPY.pm line 1691, <$fh> line 308.
2021.04.28 09:05:44.351 1: PERL WARNING: Use of uninitialized value $old_prefix in string eq at ./FHEM/10_RHASSPY.pm line 412, <$fh> line 308.


Zeile 1691 war ein echter bug, da ist mir vermutlich beim Umbenennen der Funktionen was danebengegangen .
Zeile 412 ist neu durch die Umbenennungs-Orgien für prefix dazugekommen, sollte jetzt auch weg sein.

Ansonsten hat Perlcritics noch ein paar Kleinigkeiten aufgedeckt, die einfach zu beseitigen waren ...

[davedeluxe]

Guten Morgen,

mal ne generelle Frage da ich dazu nichts gefunden habe (was nicht bedeutet das es nicht doch irgendwo steht).
Ich habe meine Satelliten wie folgt benannt: satellite-raum
Soweit ich verstehe kann ich z.B. in der Küche sagen: "Licht an" und das Licht in der Küche geht an.
Was muss ich tun, dass das funktioniert da mein satellite ja "satellite-kueche" heißt.

Ich bin bereits auf siteId2room gestoßen, was für mich nach einer Möglichkeit klingt, finde aber keine Dokumentation darüber.

Grüße!