Modulentwicklung für Rhasspy Sprachassistent

[drhirn]

Augenreib, aber na ja... Vermutlich wäre es daher sinnvoll, mal "utf8" zum default zu erklären (bzw. über die DEF vorzugeben; das ist jetzt in der Fassung anbei so, ich weiß aber noch nicht, ob das nicht an anderer Stelle unangenehme Nebenwirkungen hat!).

Macht leider auch keinen Unterschied.

da wäre bei der speziellen Leuchte dann interessant, was "getAllSets()" auswirft?

Was was auswirft? Wie komme ich zu einem Ergebnis?
Kann nicht sagen, ob justme1968 da was dran rumgebastelt hat, und ob das nicht auch ein Überbleibsel von einer Gruppensteuerung sein könnte...

Ich _glaube_ daher, dass wir die Hue- und Rgb-Optionen halbwegs funktional haben sollten (will sagen: den Rgb-slot in der language-file drin) und das mit dem Mapping (ohne separates Attribug) klappen sollte. Dann ist es so universell, dass man 80/20 behaupten kann, dass es funktioniert.

Ich wär dafür, dass du dann einfach RAW und sentences postest und ich das ausprobiere. Ich kann nämlich nicht mehr folgen, was jetzt geht und was nicht

[Beta-User]

Macht leider auch keinen Unterschied.

Hmmm, dann bin ich im Moment wirklich komplett ratlos...

Was was auswirft? Wie komme ich zu einem Ergebnis?

FHEM-Kommandofeld:

Code Auswählen Erweitern

{getAllSets('HUEDevice6')}Dann sehen wir wenigstens mal, was erkannt werden könnte.

Ich wär dafür, dass du dann einfach RAW und sentences postest und ich das ausprobiere. Ich kann nämlich nicht mehr folgen, was jetzt geht und was nicht

Für die Colortemp-Geschichte:

Code Auswählen Erweitern


[de.fhem:SetColor]
\[setze|färbe|stelle] [der|die|das] $de.fhem.Device-light{Device} [im|in der|auf der|auf dem] [$de.fhem.Room{Room}] [auf] [die Farbe] ( $hueColor{Hue} | (warm weiss){Colortemp:100} | (kalt weiss){Colortemp:0} | (mittleres weiss){Colortemp:50} )
Falls das HUEDevice ct als setter kennt, müßte dann bei den weiss-Anweidungen auch was passieren (bzw. ggf. auch, wenn das nicht der Fall ist, aber rgb geht).

Was RAW angeht, ist das nicht so einfach, denn ob jetzt bei einer Hardware am Ende wirklich was sinnvolles ankommt, sieht man eigentlich nur, wenn man wirklich in der Realität versucht, das Leuchtmittel zu steuern.
Klappen müßte das jetzt mit allem, was hue, ct, color_temp, rgb, RGB oder hex versteht, und zwar alles mit obigem Satz...

Next step bzgl. wäre daher ein sentence für die Sättigung. Ist im Prinzip beliebig, solange irgendwas zwischen 0 und 100 als "Saturation" übergeben wird, also z.B.

Code Auswählen Erweitern

\die sättigung von $de.fhem.Device-light{Device} [im|in der|auf der|auf dem] [$de.fhem.Room{Room}] soll [auf] (0..100){Value!float} [prozent]
...
Hier noch der zusätzliche rgb-Color-slot:

Code Auswählen Erweitern

"slots":
{
  "Colors": "braun:20,grüngelb:90,blaurot:330,leichtes grüngelb:75,grünblau:210,rot:0,grün:120,magenta:300,indigo:255,dunkelgrün:120,leichtes blaurot:345,zinnober:15,cyan:180,leichtes grünblau:225,leichtes blaugrün:135,limett:105,orange:30,blaugrün:150,gelb:60,blau:240,blaumagenta:315,grüncyan:165,violett:270,blaucyan:195,rotmagenta:315,safran:45",
  "ColorsRgb": "grüngelb:80FF00,blaurot:8000FF,leichtes grüngelb:BFFF00,grünblau:0080FF,rot:FF0000,grün:00FF000,magenta:FF00FF,indigo:4000FF,dunkelgrün:00FF00,leichtes blaurot:carmine,zinnober:FF4000,cyan:00FFFF,leichtes grünblau:0040FF,leichtes blaugrün:00FF40,limett:40FF00,orange:FF8000,blaugrün:00FF80,gelb:FFFF00,blau:0000FF,blaumagenta:FF00BF,grüncyan:00FFBF,violett:8000FF,blaucyan:00BFFF,rotmagenta:FF00BF,safran:FFBF00"
}
Der ist ggf. für die gedacht, die sich lieber an den RGB-Werten orientieren wollen und setzt vermutlich voraus, dass das FHEM-Device mit rgb umgehen kann, da Hue bereits "durch" ist, wenn Rgb geprüft wird. Diese Werte können entweder über den Rgb-Key kommen oder in Color.

Hilft das erst mal weiter?

[drhirn]

FHEM-Kommandofeld:

Code Auswählen Erweitern

{getAllSets('HUEDevice6')}Dann sehen wir wenigstens mal, was erkannt werden könnte.

Anführungszeichen vergessen. Und beim Device den falschen subType eingestellt gehabt 

Code Auswählen Erweitern

off:noArg on:noArg toggle:noArg statusRequest:noArg pct:colorpicker,BRI,0,1,100 bri:colorpicker,BRI,0,1,254 color:colorpicker,CT,2000,1,6500 ct:colorpicker,CT,154,1,500 dimUp:noArg dimDown:noArg ctUp:noArg ctDown:noArg alert:none,select,lselect rename scene:[...] intervals off-till blink off-till-overnight on-till off-for-timer on-till-overnight on-for-timer attrTemplate:?

Falls das HUEDevice ct als setter kennt, müßte dann bei den weiss-Anweidungen auch was passieren (bzw. ggf. auch, wenn das nicht der Fall ist, aber rgb geht).

Ja, geht. Aber mit vollkommen falschen Werten.
Aus 2000 von Rhasspy wird 90000 in FHEM
Aus 6500 von Rhasspy wird 292500 in FHEM

Hilft das erst mal weiter?

Ja, hab's jetzt verstanden. Danke!

[Beta-User]

Ja, geht. Aber mit vollkommen falschen Werten.
Aus 2000 von Rhasspy wird 90000 in FHEM
Aus 6500 von Rhasspy wird 292500 in FHEM

Sorry, das hätte ich vermutlich besser erklären sollen...

Also: Es ist mal wieder nicht standardisiert, was Mindest- und Höchstwert ist. Der Code ermittelt das selbstständig aus den Werten und erwartet, dass du ihm als Colortemp einen Prozentwert übergibst, also irgendwas zwischen 0 und 100 mit dem Verständnis: 0=so warm wie möglich, 100=so kalt wie es geht...
Vermutlich liegt da der "Fehler". Trotzdem fehlt da wohl eine Begrenzungslogik, ich schau mal, dass das noch reinkommt...

EDIT: habe mal min/max für die diversen Varianten eingebaut und dann noch ein paar "ungetestete Kleinigkeiten" (weitestgehend auch in der cref) ergänzt..

[drhirn]

Sorry, das hätte ich vermutlich besser erklären sollen...

Also: Es ist mal wieder nicht standardisiert, was Mindest- und Höchstwert ist. Der Code ermittelt das selbstständig aus den Werten und erwartet, dass du ihm als Colortemp einen Prozentwert übergibst, also irgendwas zwischen 0 und 100 mit dem Verständnis: 0=so warm wie möglich, 100=so kalt wie es geht...
Vermutlich liegt da der "Fehler". Trotzdem fehlt da wohl eine Begrenzungslogik, ich schau mal, dass das noch reinkommt...

EDIT: habe mal min/max für die diversen Varianten eingebaut und dann noch ein paar "ungetestete Kleinigkeiten" (weitestgehend auch in der cref) ergänzt..

Sollen wir das dann nicht lieber über SetNumeric abfackeln?

[Beta-User]

Spontanreaktion: Nein, nein, bloß nicht...

Mal meine ungeordneten Gedanken dazu:
Theoretisch ginge das wohl, aber sprachlich ist alles, was direkt oder indirekt mir Farbe zu tun hat viel näher an "rot" oder "grün" dran. Von daher ist das mit dem "Einheitssatz" für Farbtemperatur an der Stelle m.E. schon alleine deswegen hilfreich, weil man Vermischungen mit allem möglichen anderen vermeidet (v.a., wenn man gDT setzt und dann auf -light eingrenzt).

Innerhalb der Lichtsteuerung ist es auch sehr viel einfacher, ggf. den "falschen" setter in etwas umzuwandeln, das dann funktioniert. Der "Wechsel" von "SetNumeric" nach "rgb" ginge sonst praktisch gar nicht oder nur mit großen Verrenkungen... Für "Saturation" habe ich da zwar noch keine zündende Idee, vermute aber, dass es ähnlich ist wie mit dem bisherigen Rest.

Das Spontangefühl mag täuschen, aber für mich ist auch ein sehr starkter Indikator, dass das bisher komplett separat abgehandelt wurde. Jetzt müßte es z.B. gehen, das Color-Mapping auch über das rhasspyMapping abzubilden (hab's noch nicht getestet), aber eben unter einer anderen Untergruppe (SetColorParms).
Generell: Evtl. wäre eine Export-Funktion ganz praktisch, falls jemand das automatisch erstelle Mapping als Gerüst nehmen will. (Ist aber nicht dringlich).

Was in der Version aus dem letzten Post noch eingebaut war: Ändern des prefix führt jetzt dazu, dass die Attribut-Inhalte auf die neuen Namen "umgezogen" werden (und die alten gelöscht, wenn diese keine RHASSPY-Instanz mehr verwendet).

[drhirn]

Spontanreaktion: Nein, nein, bloß nicht...

Hahaha

(v.a., wenn man gDT setzt und dann auf -light eingrenzt)

Mach ich nicht (kann ich dzt. nicht machen), drum hab ich nicht daran gedacht.

Innerhalb der Lichtsteuerung ist es auch sehr viel einfacher, ggf. den "falschen" setter in etwas umzuwandeln, das dann funktioniert. Der "Wechsel" von "SetNumeric" nach "rgb" ginge sonst praktisch gar nicht oder nur mit großen Verrenkungen... Für "Saturation" habe ich da zwar noch keine zündende Idee, vermute aber, dass es ähnlich ist wie mit dem bisherigen Rest.

...und hab nicht daran gedacht, dass ct ja auch für richtige Farben verwendet wird.

Was in der Version aus dem letzten Post noch eingebaut war: Ändern des prefix führt jetzt dazu, dass die Attribut-Inhalte auf die neuen Namen "umgezogen" werden (und die alten gelöscht, wenn diese keine RHASSPY-Instanz mehr verwendet).

Jup, gesehen. Danke!

Bzgl. venetian-blind: Sollen wir wirklich "venetian blind" im Code lassen? "blind" ist "blind". Jalousien funktionieren doch alle gleich. Egal ob sie aus Venedig sind oder nicht. Oder?

[Beta-User]

Bzgl. venetian-blind: Sollen wir wirklich "venetian blind" im Code lassen? "blind" ist "blind". Jalousien funktionieren doch alle gleich. Egal ob sie aus Venedig sind oder nicht. Oder?

Na ja, ich kenne die Begrifflichkeit v.a. von ZWave her. Da kann man einen normalen "blind"-Aktor eben im "venetian mode" betreiben. Du gehst gedanklich vermutlich davon aus, dass ein "blind" immer eine Jalousie ist und ein "shutter" immer ein Rollladen (bzw. das, was wir hier im Südwestdeutschen eben als solche bezeichnen).

MWn. ist die Unterscheidung aber nicht wirklich trennscharf, mal abgesehen davon, dass sich das "venetian" _vielleicht_ am ehesten für die "echte" Jalousie durchgesetzt hat:
https://en.wikipedia.org/wiki/Window_blind#Venetian
(leo.org ist da ziemlich bunt, was shutter und blind angeht...)

Falls du bessere Vorschläge hast: her damit, ich bin mal wieder eher an der Funktionaliät interessiert wie am wording .

(Ach so: das zugrundeliegende Problem kommt aus der Funktionalität meiner ZWave-Aktoren. Steuert man die über den Controller (in meinem Fall also FHEM), werden die Lamellen wieder in die letzte Lage gedreht, was z.B. beim Öffnen bedeutet, dass wieder ein kleines Stück geschlossen wird bzw. beim Schließen, dass die Lamellen wieder "Innenseite nach außen" gedreht werden. Dazu musste schon "Spezialcode" in ASC her, und hier ist es m.E. auch ausgesprochen zweckmäßig, einfach auch den Ziellevel als Drehwinkel zu nehmen).

[drhirn]

Ich dachte mir nur, es ist einfach kürzer und weniger Tippfehler-anfällig. Ich kenn in dem Fall nur "venetian blinds" und nenn die auch Jalousien. Rollladen heißt bei mir übrigens auch Rollladen

(Und im Rest Österreichs ist es genau so. Gerade nachgefragt )

[Beta-User]

Ja, "Rollladen" dürfte (!) weitgehend im deutschsprachigen Raum einheitlich verstanden werden, aber was ist mit "Rollo"...(Heillose Verwirrung, zumal "ROLLO" (also das FHEM-Modul) (bisher?) nur "Rollladenmodus" kann (afaik)).

Von daher fand ich es angemessen, irgendwie kenntlich zu machen, dass es eben irgendwas "spezielles" ist. Aber wie gesagt: Darfst du gerne so machen, wie es dir beliebt, solange ich meine Jalousien am Ende voll geöffnet resp. geschlossen bekomme .

[drhirn]

Rollo ist für mich die Abkürzung von Rollladen

[Beta-User]

Unabhängig von der Benennung mal die Rückmeldung, dass meine Jalousien jetzt den venetianBlind-Eintrag haben und zumindest auf den ersten Blick so funktionieren wie erhofft .
Dafür sind die dusseligen MiLights widerspenstig, was mal wieder nicht am Code liegt sondern an den Leuchtmitteln: Die verstehen jetzt zwar hex, aber wenn es in die Nähe von FFFFFF (bzw. ffffff) geht, sind die Ergebnisse seltsam. Wenn man bei denen weiss will, muss man explizit diesen Modus einschalten. Unschön...

[drhirn]

Cool!

Das mit den MiLights ist ein bisschen lästig. Andererseits hätten wir für solche Spezialfälle ja immer noch die "traditionellen" Mappings. Oder Shortcuts


Musste gesten beim Einschlafen an dich denken. Klingt jetzt aber romantischer, als es war
Mir lässt deine Pi-Sache keine Ruhe. Die Docker-Container haben ja nichts mit pyaudio zu tun. Audio wird ja einfach vom Host zum Container durchgereicht.
Wie startest du den Container? Eh mit docker-compose up -d im entsprechenden Verzeichnis? Und kannst du mir mal die docker-compose.yml posten bitte. Die liegt entweder in ~/rhasspy oder in /data/rhasspy. Vielleicht hab ich da was vergessen. Andererseits, bei meinen Tests hat's ja funktioniert.

[Beta-User]

Das mit den MiLights ist ein bisschen lästig. Andererseits hätten wir für solche Spezialfälle ja immer noch die "traditionellen" Mappings. Oder Shortcuts

Ja! Und ja, schon, vielleicht, nein...

Ja: Die MiLights sind zwar "schon immer" ein Quell der Freude (und nicht nur "ein bisschen lästig"), in unserem Zusammenhang aber vermutlich nur eine Sonderlocke von vielen möglichen (wie gesagt, die sind eingebunden über MQTT2_DEVICE, was nicht viel mehr heißt wie: Was eigentlich dahinter steht und dann an die jeweilige echte Hardware weitergegeben wird, wissen wir in vielen anderen Fällen genausowenig...

nein: "traditionelle" Mappings und shortcuts sind zwar möglich, aber aus dem Alter für's Vokabellernen bin ich raus, und m.E. kann man es auch niemandem vermitteln, dass er für die Steuerung bestimmter Leuchtmittel ganz andere Wörter verwenden soll wie für andere.

MAn. muss man das also durch passende Einstellungen auf der FHEM-Seite lösen und den input aus einem "Einheitssatz" aus Rhasspy generieren.
Läuft vermutlich auf weitere "Color-Mapping"-Einträge in "specials" raus. Vorschlag wäre: "colorTempMapping" (bei Bedarf dann noch "colorHueMapping"?).


Was den Pi angeht: den werde ich voraussichtlich vor Do. bzw. dem WE nicht mehr in Betrieb nehmen, bitte daher keine weiteren schlaflosen Nächte deswegen . Vielleicht finden sich ja jemand, der uns die strukturellen Probleme hinter dem UTF-8-Problem verklickern kann... Momentan habe ich die "lc"-Transformation im Verdacht.
Schnelles Suchmaschinenbefragen liefert https://perldoc.perl.org/functions/lc. Bin nur etwas ratlos, as ich damit anfangen soll:

Code Auswählen Erweitern

use feature 'unicode_strings'
Würde das also mal in unseren header einbauen (mit ";" am Ende der Zeile), ist aber auch wieder nur irgendwie geraten...

EDIT: Kann schon sein, dass ich versehentlich den Startaufruf für das docker-image geändert habe; nach dem update startete der Container nicht mehr automatisch, soweit ich mich entsinne. (Aber wie gesagt: eilt nicht)

[drhirn]

Boa, du bist ein Held! Das use feature ändert zwar nichts. Aber mit lc hattest du vollkommen recht!

In getRoomName

Code Auswählen Erweitern


#my $siteId = lc $data->{siteId};
my $siteId = $data->{siteId};

und es funktioniert wieder.

Das ist mal ein guter Ansatz. Bin die nächsten zwei Stunden verhindert, aber danach schau ich mal, was man da tun könnte.