Modulentwicklung für Rhasspy Sprachassistent

[drhirn]

bzgl. dieser beiden Punkte:

Umsetzen? (0.4.10, s.u.)

Total unwichtig die zwei Punkte.
Und da hast natürlich recht. Das mit der 1.4.10 war ein Tippfehler

Ich _glaube_, dass es nur für die gefählich sein kann, die das aktiv austesten, für alle anderen sollte es keine Probleme bringen, und wenn ich dann die Tage mal an's Testen komme, ist auch besser abschätzbar, wie groß das Gefahrenpotential effektiv ist (ich hoffe: 0  ).
Von daher wäre es mir am liebsten, wir könnten die experiementellen Teile einfach in den "rolling" Code integriert lassen (und/oder notfalls den erweiterten Code auf möglichst einfache Weise deaktivieren). Dann ist es für mich einfacher, ggf. erforderliche Bugfixes in den regulären Code-Teilen einzupflegen.

Ich habe sowieso entschieden, dass es in Zukunft nur noch zwei Versionen geben wird. Eine "master" und eine "dev". Ist viel einfacher.

Meine Kunstwerke wären die MySensors-Module, Weekday- und RandomTimer sowie Twilight...

Ist notiert.

Nachtrag: das via github sichtbare diff ist im Detail leider nicht so aussagekräftig wie im Code-Bereich.

Kann nicht folgen. Welcher Code-Bereich? Bzw., kann ich was tun, um das sichtbarer für dich zu machen?

[Beta-User]

Kann nicht folgen. Welcher Code-Bereich? Bzw., kann ich was tun, um das sichtbarer für dich zu machen?

Hab's jetzt mal in notepad++ verglichen, da sieht man die Details der Veränderungen teils besser, paßt schon...

Ein paar kleine Kritikpunkte hätte ich noch:
- "Tweaks" ist jetzt etwas "kurz", und der "Vorläufigkeitsvermerk" ist weg. Das ist bzgl. der Timer-Geschichten ok, aber z.B. das eingangs erwähnte siteId2room gibt es noch nicht...
- beim CLIENT steht keine IP-Adresse
- parseParams braucht bei Leerzeichen im Text quotes, vermutlich müsste das so lauten:

DefaultError= DefaultConfirmation="Klaro, mach ich"

(Generell hatte ich beim Überarbeiten der .md noch ein paar Kleinigkeiten angemerkt, von denen ich grade nicht mehr weiß, ob sie in der cref noch fehlen oder ergänzt werden sollten).

Total unwichtig die zwei Punkte.

Das mit dem rhasspyShortcuts ist anbei erledigt und V. auf 0.4.10 gesetzt.
Da wir beim Aufräumen sind:
- configFile könnte man auch in languageFile umbenennen, andere config-Elemente sind da ja nicht drin.
- Ob man fetchSideIds in "update" integrieren sollte?
(- Bitte schau auch nochmal in diesem Sinne kritisch drüber).

Ich habe sowieso entschieden, dass es in Zukunft nur noch zwei Versionen geben wird. Eine "master" und eine "dev". Ist viel einfacher.

Hatte mich schon gewundert, dass es so viele Zweige gibt, aber ich bin ja bekennender github-DAU...

Es ist schon ok, im Rahmen des dev-Zweigs dann von Zeit zu Zeit auch die Version hochzudrehen, das ist aber eigentlich eher ein "Marker", damit man ggf. in der Diskussion über ein Problem besser eingrenzen kann, über welche Fassung man jeweils redet. Den Punkt finde ich bei svn einleuchtender (was nicht bedeuten soll, dass man sowas nicht auch via git hinbekäme).

Im Moment sehe ich allerdings wie gesagt keinen echten Grund, irgendeine Fassung als "master" oder "dev" anzusehen, weil die experimentellen Teile relativ gut abzugrenzen sind, und wir auch Verbesserungen ggf. direkt im übrigen Code einpflegen. Es ist im Moment eher eine "rolling beta" (und das zu ändern vermutlich den Aufwand (noch) nicht wert).

[Beta-User]

So, zum Ende des Tages noch ein paar Ergebnisse meiner Kurztests:

1. Die Zuordnung der Geräte scheint deutlich besser zu sein, wenn man passende "Sub-Slots" aus den gDT verwendet.
sentences.ini:

Code Auswählen Erweitern

[de.fhem:SetNumeric]
\[ ( schalt | mach ) ] $de.fhem.Device-media{Device} [um] [(0..10){Value!int}] [dezibel{Unit}] ( lauter:volUp | leiser:volDown){Change}
[de.fhem:SetNumeric]
( mach | stelle ) $de.fhem.Device-thermostat{Device} [um] [(0..10){Value!int}] [grad{Unit}] ( wärmer:tempUp | kälter:tempDown ){Change}
( mach |schalt|schalte|stelle) $de.fhem.Device-light{Device} [um] [(0..100){Value}] [prozent{Unit:percent}] ( heller:lightUp | dunkler:lightDown){Change}
(schalt | schalte | stelle ) $de.fhem.Device-light{Device} auf (0..100){Value!float}
( mehr{Change:lightUp} | weniger{Change:lightDown} ) $de.fhem.Device-light{Device} [$de.fhem.Room{Room}]
( mach |schalt|schalte|stelle) $de.fhem.Device{Device} [um] [(0..100){Value}] [prozent{Unit:percent}] (heller){Change:lightUp}
( mach |schalt|schalte|stelle) $de.fhem.Device{Device} [um] [(0..100){Value}] [prozent{Unit:percent}] (dunkler){Change:lightDown}
(schalt | schalte | stelle ) $de.fhem.Device{Device} auf (0..100){Value!float}
( mehr{Change:lightUp} | weniger{Change:lightDown} ) $de.fhem.Device{Device} [$de.fhem.Room{Room}]


2. Warmweiss/Kaltweiss klappt mit den gDT-Analysen, rgb-Kommandos nicht. Details dazu muss ich mir noch ansehen, aber: Im Prinzip funktioniert es, und FHEM läuft auch dann noch, wenn die Zuordnung nicht klappt .
sentences.ini:

Code Auswählen Erweitern

[de.fhem:SetColor]
\[setze|färbe] $de.fhem.Device-light{Device} [$de.fhem.Room{Room}] [auf die Farbe] (grün{Color:green}  | hellgrün{Color:lightgreen} | rot{Rgb:FF0000} | (warm weiss){Colortemp:100} | (kalt weiss){Colortemp:0} | (mittleres weiss){Colortemp:50} )

M. E. ein ziemlicher Schritt nach vorne, insgesamt gesehen.

Nachtrag: Neben Colortemp gehen auch Hue und Saturation; die Ergebnisse sind zwar bei Saturation optisch nicht toll, aber das hängt an den Leuchtmitteln...
sentences dazu:

Code Auswählen Erweitern

\[setze|färbe] $de.fhem.Device-light{Device} [$de.fhem.Room{Room}] [auf die Farbe] (grün{Saturation:90}  | hellgrün{Saturation:30} | rot{Hue:1} | (warm weiss){Colortemp:100} | (kalt weiss){Colortemp:0} | (mittleres weiss){Colortemp:50} )

[drhirn]

- "Tweaks" ist jetzt etwas "kurz", und der "Vorläufigkeitsvermerk" ist weg. Das ist bzgl. der Timer-Geschichten ok, aber z.B. das eingangs erwähnte siteId2room gibt es noch nicht...
- beim CLIENT steht keine IP-Adresse

So viel kürzer ist Tweaks nicht? Aber der Vorläufigkeitsvermerk ist wieder dabei.

- parseParams braucht bei Leerzeichen im Text quotes, vermutlich müsste das so lauten:

Code Auswählen Erweitern

DefaultConfirmation="Klaro, mach ich"

Dann habe ich Anführungszeichen in der Antwort. Wird da überhaupt parseParams verwendet?

(Generell hatte ich beim Überarbeiten der .md noch ein paar Kleinigkeiten angemerkt, von denen ich grade nicht mehr weiß, ob sie in der cref noch fehlen oder ergänzt werden sollten).

Abgleich MD<->CRef hab ich noch nicht gemacht.

Das mit dem rhasspyShortcuts ist anbei erledigt und V. auf 0.4.10 gesetzt.

Perfekt! Danke!

- configFile könnte man auch in languageFile umbenennen, andere config-Elemente sind da ja nicht drin.

Ja, sehr gerne!

- Ob man fetchSideIds in "update" integrieren sollte?

Naja, wir müssen's auf jeden Fall weiterhin gleich nach dem Start des Moduls ausführen. Aber es würde schon irgendwie Sinn ergeben, das zu verschieben.

Es ist schon ok, im Rahmen des dev-Zweigs dann von Zeit zu Zeit auch die Version hochzudrehen, das ist aber eigentlich eher ein "Marker", damit man ggf. in der Diskussion über ein Problem besser eingrenzen kann, über welche Fassung man jeweils redet. Den Punkt finde ich bei svn einleuchtender (was nicht bedeuten soll, dass man sowas nicht auch via git hinbekäme).

In GitHub gibt's auch Commits.

Im Moment sehe ich allerdings wie gesagt keinen echten Grund, irgendeine Fassung als "master" oder "dev" anzusehen, weil die experimentellen Teile relativ gut abzugrenzen sind, und wir auch Verbesserungen ggf. direkt im übrigen Code einpflegen. Es ist im Moment eher eine "rolling beta" (und das zu ändern vermutlich den Aufwand (noch) nicht wert).

"master" wäre einfach eine gut getestet und nachweislich funktionierende Version.

[drhirn]

2. Warmweiss/Kaltweiss klappt mit den gDT-Analysen, rgb-Kommandos nicht. Details dazu muss ich mir noch ansehen, aber: Im Prinzip funktioniert es, und FHEM läuft auch dann noch, wenn die Zuordnung nicht klappt .
sentences.ini:

Code Auswählen Erweitern

[de.fhem:SetColor]
\[setze|färbe] $de.fhem.Device-light{Device} [$de.fhem.Room{Room}] [auf die Farbe] (grün{Color:green}  | hellgrün{Color:lightgreen} | rot{Rgb:FF0000} | (warm weiss){Colortemp:100} | (kalt weiss){Colortemp:0} | (mittleres weiss){Colortemp:50} )

M. E. ein ziemlicher Schritt nach vorne, insgesamt gesehen.

Nachtrag: Neben Colortemp gehen auch Hue und Saturation; die Ergebnisse sind zwar bei Saturation optisch nicht toll, aber das hängt an den Leuchtmitteln...
sentences dazu:

Code Auswählen Erweitern

\[setze|färbe] $de.fhem.Device-light{Device} [$de.fhem.Room{Room}] [auf die Farbe] (grün{Saturation:90}  | hellgrün{Saturation:30} | rot{Hue:1} | (warm weiss){Colortemp:100} | (kalt weiss){Colortemp:0} | (mittleres weiss){Colortemp:50} )

Kannst du mir bitte mal ein DEV von so einer Lampe posten?

[Beta-User]

...damit das mit den Farben "halbwegs" rund wird, ist anbei dann auch das mit "Rgb" bzw. RGB-Werten für "Color" gefixt. Da es grade so schön war, gibt es das ganze dann auch gleich als Gruppen-Intent (der Teil ist noch ungetestet).
Damit fehlt bei den Farben "eigentlich nur noch" die Konvertierung zwischen verschiedenen Farbräumen bzw. die Berücksichtigung eines bereits gesetzten oder im JSON enthaltenen Helligkeitswerts. (Also falls jemand Lust hat, Farbe war eigentlich gar nicht mein Thema, hat sich halt ergeben ...)


Ein "uninitialized"-Warning ist mir noch vor die Flinte gelaufen, die ist (hoffentlich) auch gefixt.


Und zu guter Letzt war es unschön, wenn sich Rhasspy über fehlende Detail-Slots beschwert hat und deswegen das Training abgebrochen hat. Da davon auszugehen ist, dass ggf. Einsteiger erst mal alles kopieren und dann auch über das Problem stolpern (auch bei den "alten" slots), werden alle slots jetzt zwangsweise erstellt. Kann man abschalten mit

Code Auswählen Erweitern

attr rhasspy updateSlots=noEmptySlots=1
Zusätzlich habe ich mal testweise die Option drin, overwrite auszuschalten:

Code Auswählen Erweitern

attr rhasspy updateSlots=overwrite_all=false
Bin noch nicht sicher, ob das eine gute Idee ist...
Jedenfalls ist "tweaks" jetzt um diese Einträge länger

Dann habe ich Anführungszeichen in der Antwort. Wird da überhaupt parseParams verwendet?

Öhm, vermutlich dann nicht...


configFile heißt jetzt auch languageFile, allerdings muss das für configDB weiter als Internal CONFIGFILE heißen.

Naja, wir müssen's auf jeden Fall weiterhin gleich nach dem Start des Moduls ausführen. Aber es würde schon irgendwie Sinn ergeben, das zu verschieben.

Ausführung und Verortung in den settern sind zwei Paar Stiefel. Mache ich bei Gelegenheit, Wunsch für den Namen? Würde das "fetch" weglassen, also "update siteIds"?

In GitHub gibt's auch Commits.

Schon klar, aber wenn ich als User irgendwas installiert habe: Wie komme ich zur fraglichen Commit-Id um genaue Rückmeldung an den Entwickler zu geben?

"master" wäre einfach eine gut getestet und nachweislich funktionierende Version.

In der Theorie klingt das gut. In der Praxis haben wir 7 Installationen, die bisher in "statistics" auftauchen. Da ist m.E. eine einzige "rolling" (noch) die bessere Variante, selbst wenn man eine hohe Dunkelziffer bei eventuellen Testinstallationen unterstellt.

Mein Test-dummy - die setList entspricht dem, was bei einer HUEDevice-Gruppe farbiger Lampen mit getAllSets() kommt:

Code Auswählen Erweitern

defmod devstrich0 dummy
attr devstrich0 userattr genericDeviceType
attr devstrich0 alias Mülleimer
attr devstrich0 genericDeviceType light
attr devstrich0 group global_test,
attr devstrich0 readingList a b c desired-temp temperature
attr devstrich0 room H Harmony
attr devstrich0 setList off:noArg on:noArg toggle:noArg statusRequest:noArg pct:colorpicker,BRI,0,1,100 bri:colorpicker,BRI,0,1,254 rgb:colorpicker,RGB color:colorpicker,CT,2000,1,6500 ct:colorpicker,CT,154,1,500 hue:colorpicker,HUE,0,1,65535 sat:slider,0,1,254 xy dimUp:noArg dimDown:noArg ctUp:noArg ctDown:noArg hueUp:noArg hueDown:noArg satUp:noArg satDown:noArg alert:none,select,lselect,breathe,okay,channelchange,finish,stop effect:none,colorloop lights rename savescene deletescene scene: off-for-timer on-till-overnight off-till-overnight intervals off-till on-for-timer blink on-till

Hatte auch mit einer MQTT2_DEVICE-RGBW-Milight experimentiert, die u.A. auch HUE (0-359) kennt; die hatte auch (auf Hue) nachvollziehbar reagiert. Allerdings war mir die korrekte Farbbenennung bisher nicht wichtig gewesen, das waren irgendweche Werte; das sollte man also ggf. checken und was "sinnvolles" in die Doku aufnehmen (FF0000 => Hue 0 in der 0-100-Skala?)

[drhirn]

...damit das mit den Farben "halbwegs" rund wird, ist anbei dann auch das mit "Rgb" bzw. RGB-Werten für "Color" gefixt. Da es grade so schön war, gibt es das ganze dann auch gleich als Gruppen-Intent (der Teil ist noch ungetestet).
Damit fehlt bei den Farben "eigentlich nur noch" die Konvertierung zwischen verschiedenen Farbräumen bzw. die Berücksichtigung eines bereits gesetzten oder im JSON enthaltenen Helligkeitswerts. (Also falls jemand Lust hat, Farbe war eigentlich gar nicht mein Thema, hat sich halt ergeben ...)

Mit Lichtfarben hab ich auch nicht viel am Hut. Ich verwende nur RGB. Und das ganz selten. Aber ich schau dann mal, wie dein leuchtender Mülleimer funktioniert

Und zu guter Letzt war es unschön, wenn sich Rhasspy über fehlende Detail-Slots beschwert hat und deswegen das Training abgebrochen hat. Da davon auszugehen ist, dass ggf. Einsteiger erst mal alles kopieren und dann auch über das Problem stolpern (auch bei den "alten" slots), werden alle slots jetzt zwangsweise erstellt. Kann man abschalten mit

Code Auswählen Erweitern

attr rhasspy updateSlots=noEmptySlots=1
Zusätzlich habe ich mal testweise die Option drin, overwrite auszuschalten:

Code Auswählen Erweitern

attr rhasspy updateSlots=overwrite_all=false
Bin noch nicht sicher, ob das eine gute Idee ist...
Jedenfalls ist "tweaks" jetzt um diese Einträge länger

Hmm. Bin nicht sicher, ob man Usern das Denken abnehmen sollte. Und innerhalb von Rhasspy wird das immer noch passieren, wenn man die Sentences davor anlegt.
Aber schaden tut das nicht.
Die zweite Option ist allerdings riskant. Könnte dazu führen, dass Rhasspy Devices erkennt, die es schon lange nicht mehr gibt, weil einer vergessen hat, dass er die Option gesetzt hat. Aber könnte auch manchmal praktisch sein.

Du meinst aber

Code Auswählen Erweitern

attr Rhasspy rhasspyTweaks updateSlots=overwrite_all=false
oder?

configFile heißt jetzt auch languageFile, allerdings muss das für configDB weiter als Internal CONFIGFILE heißen.

Ausführung und Verortung in den settern sind zwei Paar Stiefel. Mache ich bei Gelegenheit, Wunsch für den Namen? Würde das "fetch" weglassen, also "update siteIds"?

Es ist eigentlich kein "update". Je nachdem, von welcher Seite man das sieht.
Aber ist ok für mich.

Schon klar, aber wenn ich als User irgendwas installiert habe: Wie komme ich zur fraglichen Commit-Id um genaue Rückmeldung an den Entwickler zu geben?

So z.B.: https://github.com/drhirn/fhem-rhasspy/commits/dev

[Beta-User]

Mit Lichtfarben hab ich auch nicht viel am Hut. Ich verwende nur RGB. Und das ganz selten. Aber ich schau dann mal, wie dein leuchtender Mülleimer funktioniert

Viel Spaß beim Testen. Wenn du die Gruppenfunktion testen willst, brauchst du halt mehrere Mülleimer .

Hmm. Bin nicht sicher, ob man Usern das Denken abnehmen sollte. Und innerhalb von Rhasspy wird das immer noch passieren, wenn man die Sentences davor anlegt.

Na ja, das ist so eine Frage, über die man trefflich streiten kann. Grundsätzlich sollte man m.E. unnötige Fehlerquellen eliminieren, es sind auch so schon genug Baustellen, über die man stolpern kann.

Die zweite Option ist allerdings riskant. Könnte dazu führen, dass Rhasspy Devices erkennt, die es schon lange nicht mehr gibt, weil einer vergessen hat, dass er die Option gesetzt hat. Aber könnte auch manchmal praktisch sein.

Sehe ich ähnlich, und bin dabei sogar unsicher, ob man das für Gruppen- und "normale" slots getrennt machen müßte.
Gedanklicher Hintergrund ist der: Wenn man "nur" gDT-Mapping macht, hat man (hoffentlich) kein Problem. Fügt man aber einzelne Devices zu einem Slot auf der Rhasspy dazu, ist das ggf. hilfreich, um bestimmte Funktionalitäten anzuflanschen, die via gDT nicht gehen, oder ggf. eben dann irgendeinen "Hybriden" oä. zu erzeugen. Hat fast nichts gekostet, also dachte ich, es könnte evtl. manchmal praktisch sein...

Du meinst aber

Code Auswählen Erweitern

attr Rhasspy rhasspyTweaks updateSlots=overwrite_all=false
oder?

...versenkt...

Es ist eigentlich kein "update". Je nachdem, von welcher Seite man das sieht.
Aber ist ok für mich.

Ist schon richtig, der Rest geht (eher) in Richtung Rhasspy, hier holen wir was ab...
Dann lassen wir es wie es ist...

So z.B.: https://github.com/drhirn/fhem-rhasspy/commits/dev

Ja. Alles bekannt.
Aber wenn ich als User irgendwann mal was installiert habe, habe ich nirgends einen automatisch erzeugten Kenner, es sei denn, der Developer hat einen (manuell!) eingefügt. Ergo kann ich dann nur wieder raten, welche Version es denn ist, wenn es ein dev ist, der eben nur bei wesentlicheren Änderungen eine neue Nummer vergibt....

[drhirn]

Na ja, das ist so eine Frage, über die man trefflich streiten kann. Grundsätzlich sollte man m.E. unnötige Fehlerquellen eliminieren, es sind auch so schon genug Baustellen, über die man stolpern kann.

Es ist halt kein Modul-Problem. Und Support für Rhasspy können andere besser als ich.
Aber ich wehre mich nicht gegen die Funktion. Ist mir selber schon oft genug passiert. Deswegen ja damals auch der Hinweis, dass man updaten können muss, ohne ein Training zu starten.

Aber wenn ich als User irgendwann mal was installiert habe, habe ich nirgends einen automatisch erzeugten Kenner, es sei denn, der Developer hat einen (manuell!) eingefügt. Ergo kann ich dann nur wieder raten, welche Version es denn ist, wenn es ein dev ist, der eben nur bei wesentlicheren Änderungen eine neue Nummer vergibt....

Ah, verstehe was du meinst. Bei "dev" könnte ich sagen, "mach ein Update und frag dann nochmal". Und in der "master" brauchen wir dann sowieso eine Versionsnummer im Code. Haben wir ja auch.

Aber, ich hab ja inzwischen eh einen SVN-Zugang genehmigt bekommen*. Dort wird dann die jeweilige "master" abgelegt. Weiterentwickeln möchte ich aber weiterhin auf GitHub.

*Ich brauch dann noch einen SVN Crash-Kurs

[Beta-User]

Es ist halt kein Modul-Problem.

Sehe ich auch so. Das "Problem" ist, dass die die Erfahrung haben eher eingrenzen können, ob es ein Modul-Problem ist, aber für den typischen User ist es meist nur "ein Problem", das dann halt "irgendwo" eingekippt ist, wo es ggf. halbwegs (oder nicht mal das) paßt. Und damit ist es auf deinem Tisch, ganz gleich, wie oft du den User darauf hinweist, dass es ein ZigBee-Problem ist, er aber der Überzeugung, es mit einem MQTT2_DEVICE zu tun zu haben...

Ah, verstehe was du meinst. Bei "dev" könnte ich sagen, "mach ein Update und frag dann nochmal". Und in der "master" brauchen wir dann sowieso eine Versionsnummer im Code. Haben wir ja auch.

Klar, "master" wird/sollte immer etwas "besser gepflegt" sein als irgendein Zwischenstand, mit dem man ggf. einfach nur mal was ausprobiert hat.

Das Problem besteht mAn. vor allem bei diesen Zwischenständen. Kommt z.b. eine "uninitialized"-Rückmeldung, und die Zeilennummer ist zwischendurch verrutscht, ist es oft ziemlich schwer, wieder die richtige Stelle zu finden, um "das bißchen" zu fixen. Dem kommt man nur bei, wenn man das (genau) an der Version checken kann, die der User auch hat (oder man muss nachfragen, was denn in der Zeile steht usw. usf).

Aber, ich hab ja inzwischen eh einen SVN-Zugang genehmigt bekommen*. Dort wird dann die jeweilige "master" abgelegt. Weiterentwickeln möchte ich aber weiterhin auf GitHub.

*Ich brauch dann noch einen SVN Crash-Kurs

Falls du git-Kommandos auf der Komandozeile kennst: alles entspannt. Sonst auch nicht dramatisch.
Es gibt eine kleine Anleitung (von Boris?) in der Developer-Ecke zu den vorbereitenden Checks, die man machen sollte (v.a. das "property setting", damit die Versionierung klappt), ansonsten einfach fragen, oder auch mal CoolTux wegen eines Web-Meetings anpingen, dann können wir das auch kurz zu dritt durchgehen.

Hattest du Rudi angepingt wegen des Verzeichnisthemas?
Sehe da im Moment drei+ Dateien:
- RHASSPY selbst (würde noch nicht in ./FHEM gehen);
- die de-cfg (und falls Spanisch auch aktuell ist: gerne auch die!)
- die "Demo"-Utils
(- (sehr vielleicht) eine sentences.ini).


Bzgl. dem "master"-Thema noch:
Falls noch Kleinigkeiten sind, wird es uU. aufwändig, "backports" und "dev" parallel zu pflegen.
Es macht sicher Sinn, nicht jeden Zwischenstand ins svn zu schubsen, aber z.B. mal angenommen, wir finden in der aktuellen Version 0.4.11 kein akutes Problem, würde ich das auch so ins svn (aktuell ja sowieso nur contrib) schubsen. Wer mittesten will und das Vertrauen hat, dass das "schon passen wird", kann sich das unproblematisch von da holen, wer einsteigt, wird zum "Zwangstester", und wer eine für ihn akzeptable laufende Version hat, kann die ja solange nutzen, bis er "über die Klippe" springen will.

Btw.: wenn das mit meinen Lamellen (venetian blind) mal läuft und sich die Trefferquote zu meiner Zufriedenheit entwickelt hat, sehe ich auch nicht den großen Bedarf an weiteren features oder Revolutionen.
Bleiben die wenigen bekannten Baustellen (allen voran: selection bei matches outside oder mehreren Geräten), aber sonst?
Das kann man dann auch gemächlicher angehen lassen...

[drhirn]

Hattest du Rudi angepingt wegen des Verzeichnisthemas?
Sehe da im Moment drei+ Dateien:
- RHASSPY selbst (würde noch nicht in ./FHEM gehen);
- die de-cfg (und falls Spanisch auch aktuell ist: gerne auch die!)
- die "Demo"-Utils
(- (sehr vielleicht) eine sentences.ini).

Jup. Er war einverstanden. Ich habe aber eh immer nur von contrib gesprochen.
Und ja, bis auf die sentences.ini sehe ich das gleich wie du. Alle drei in einen Ordner contrib/RHASSPY

[Beta-User]

Im Moment ist es klar, dass es erst mal _nur_ contrib sein sollte.
Mittelfristig dann: 10_RHASSPY.pm nach ./FHEM, der Rest bleibt in contrib, dazu kommen dann ggf. weitere myUtils-Intents, Sprachfiles, whatever, und ggf. dann wieder ein dev-Zweig, wenn es (wieder) einen gibt.

Sollen wir am WE mal einen Zeitslot einplanen, auch wegen der Präsentation?

[Beta-User]

Mal wieder ein update:

- gDT "thermometer" (mit temperature und humidity) wird jetzt auch erkannt;
- SetColorGroup ist getestet, scheint zumindest auf den ersten Blick stressfrei zu funktionieren;
Mein (rudimentärer) Test-sentence:

Code Auswählen Erweitern


[de.fhem:SetColorGroup]
\[setze|färbe] (alle | sämtliche ) $de.fhem.Group{Group} [im] [( überall:global | $de.fhem.Room){Room}]  [auf die Farbe] ( rot{Hue:1} | (warm weiss){Colortemp:100} | (kalt weiss){Colortemp:0} | (mittleres weiss){Colortemp:50} )

Dann hätte ich noch ein Beispiel für eine CustomIntent-file: siteId2room. Einstellungen in RHASSPY siehe cref, sentence:

Code Auswählen Erweitern


[de.fhem:siteId2room]
( Ortswechsel  | begib dich ) ( ins | in den ) $de.fhem.Room{Room}

(Jemand sollte dann mal wieder die cref ergänzen...)

[drhirn]

Ich bekomm bei SetColorGroup immer den Hinweis, dass kein passendes Gerät gefunden wurde.

Was ist fehlt an dem Device?

Code Auswählen Erweitern


defmod Stimmungsleuchte dummy
attr Stimmungsleuchte genericDeviceType light
attr Stimmungsleuchte group Lampen
attr Stimmungsleuchte icon light_party
attr Stimmungsleuchte readingList pct rgb
attr Stimmungsleuchte rhasspyGroup Lampen
attr Stimmungsleuchte rhasspyMapping SetOnOff:cmdOn=on,cmdOff=off\
GetOnOff:currentVal=state,valueOff=off\
GetNumeric:currentVal=pct,type=brightness\
SetNumeric:currentVal=pct,cmd=pct,minVal=0,maxVal=255,step=1,type=brightness
attr Stimmungsleuchte rhasspyName Stimmungsleuchte,Stimmungslampe
attr Stimmungsleuchte rhasspyRoom Wohnzimmer
attr Stimmungsleuchte room Rhasspy,Wohnzimmer
attr Stimmungsleuchte setList on off pct rgb
attr Stimmungsleuchte webCmd rgb:pct:on:off
attr Stimmungsleuchte widgetOverride pct:slider,0,1,255 on:noArg off:noArg rgb:colorpicker,RGB


Ich hab's auch mit einem rhasspyColors Mapping versucht.

Code Auswählen Erweitern


2021.04.23 09:37:44.072 5: RHASSPY: [Rhasspy] Parse (IO: rhasspyMQTT2): Msg: hermes/intent/de.fhem_SetColorGroup => {"input": "setze alle lampen auf #FF0000", "intent": {"intentName": "de.fhem:SetColorGroup", "confidenceScore": 1.0}, "siteId": "default", "id": "0cb4a7a4-8e14-44f2-9251-6b9517753bf9", "slots": [{"entity": "de.fhem.Group", "value": {"kind": "Unknown", "value": "lampen"}, "slotName": "Group", "rawValue": "lampen", "confidence": 1.0, "range": {"start": 11, "end": 17, "rawStart": 11, "rawEnd": 17}}, {"entity": "Rgb", "value": {"kind": "Unknown", "value": "#FF0000"}, "slotName": "Rgb", "rawValue": "rot", "confidence": 1.0, "range": {"start": 22, "end": 29, "rawStart": 22, "rawEnd": 25}}], "sessionId": "0cb4a7a4-8e14-44f2-9251-6b9517753bf9", "customData": null, "asrTokens": [[{"value": "setze", "confidence": 1.0, "rangeStart": 0, "rangeEnd": 5, "time": null}, {"value": "alle", "confidence": 1.0, "rangeStart": 6, "rangeEnd": 10, "time": null}, {"value": "lampen", "confidence": 1.0, "rangeStart": 11, "rangeEnd": 17, "time": null}, {"value": "auf", "confidence": 1.0, "rangeStart": 18, "rangeEnd": 21, "time": null}, {"value": "#FF0000", "confidence": 1.0, "rangeStart": 22, "rangeEnd": 29, "time": null}]], "asrConfidence": null, "rawInput": "setze alle lampen auf rot", "wakewordId": null, "lang": null}
2021.04.23 09:37:44.072 5: Parsed value: #FF0000 for key: Rgb
2021.04.23 09:37:44.072 5: Parsed value: 1 for key: probability
2021.04.23 09:37:44.073 5: Parsed value: setze alle lampen auf #FF0000 for key: input
2021.04.23 09:37:44.073 5: Parsed value: lampen for key: Group
2021.04.23 09:37:44.073 5: Parsed value: default for key: siteId
2021.04.23 09:37:44.073 5: Parsed value: 0cb4a7a4-8e14-44f2-9251-6b9517753bf9 for key: sessionId
2021.04.23 09:37:44.073 5: Parsed value: setze alle lampen auf rot for key: rawInput
2021.04.23 09:37:44.073 5: Parsed value: SetColorGroup for key: intent
2021.04.23 09:37:44.074 5: handleIntentSetColorGroup called
2021.04.23 09:37:44.074 5: sorted devices list is:
2021.04.23 09:37:44.074 5: Response is: Tut mir leid, ich konnte kein passendes Gerät finden


[drhirn]

Und warum bekam ich gerade: AssertionError: Missing slot $de.fhem.Color?