Modulentwicklung für Rhasspy Sprachassistent

[Beta-User]

Also früher wurde bei der Frage nach "wie ist die temperatur in der küche" in diesem Raum nach einem Gerät mit dem GetNumeric-Mapping-Typ "Temperatur" gesucht. Gab's keines, wurde der Fehlerton ausgegeben.

Bist du da sicher? Die Logik, Devices zu finden, hat sich mAn. zwischen 0.2.0 und der aktuellen Version nicht grundsätzlich vom Ablauf her verändert, wenn man davon absieht, dass jetzt "temperature" statt "Temperatur" abgefragt wird.

Und das hier ist auch unverändert - das Problem, dass Werte von außerhalb des Raums zurückgeliefert werden, besteht also "schon immer":

Code Auswählen Erweitern

# Erstes Device im passenden Raum zurückliefern falls vorhanden, sonst erstes Device außerhalb
$device = (@{$matchesInRoom} > 0) ? shift @{$matchesInRoom} : shift @{$matchesOutsideRoom};
"Mein anderes Problem" mit den mehreren Sensoren rührt zum einen daher, dass es durch die gDT-Auswertung a) in der Tat plötzlich viele Temperatur-Geräte gibt und b) auch "desired-temp" nach "temperature" gemappt wird, was auch noch die Zahl der abfragbaren Werte (uneindeutig) an ein und demselbend Device erhöht.

Ich tendiere eher dazu, in FHEM eine richtige Logik abzubilden anstatt das Modul nach irgendwelchen Geräten suchen zu lassen. Aber mit der Meinung bin ich wohl schon etwas zu spät dran

Wenn man es in dem Sinne "richtig" macht, dass man alles händisch definiert und in jedem Raum genau einen Sensor hat, sollte es auch weiter problemlos laufen. Und wenn die "neue Methode" zu unlösbaren Problemen führt, ist es nie zu spät, bessere Alternativen zu diskutieren.

Es macht z.B. in der Praxis eigentlich keinen Sinn, mehrere Temperatur-Sensoren in einem Raum zu haben. Also, kann man schon haben, hab ich auch. Aber interessieren tut mich eigentlich nur einer (bzw. ein Mittelwert aus allen, was wieder nur ein Device wäre).

Na ja, einer ist vermutlich eine Art "default", den man "eigentlich" haben will, wenn man nichts spezielles anfordert, aber in der Küche könnten schon Raumtemperatur, Kühlschrank und Backofen samt Garthermometer im Braten interessant sein, und auch im Heizraum (oder Garten) wäre es ähnlich (ja, auch im Garten habe ich auch einige Thermometer für diverse Zwecke...).

Gibt's in einem Raum keinen Sensor, wird das wohl seinen Grund haben.

Nun ja, in dem Raum gab es durchaus einen Sensor (einen Raumthermostat), der war nur noch nicht konfiguriert...
Es bleibt aber dabei, dass die Ansage auch in dem Fall, dass es wirklich keinen Sensor gibt, nicht kommentarlos "irgendwas" beinhalten sollte, oder?

Langer Rede kurzer Sinn: Alles nicht so einfach...

Ich habe gerade Rhasspy in mein produktives FHEM übernommen. Und bin wieder über die selben zwei Punkte gestolpert, über die ich immer stolpere. rhasspyMaster und configFile vergessen .

Gibt's irgendwie eine Möglichkeit, dass wir das so einrichten, dass das ein User nicht vergessen kann? Eventuell als verpflichtende Option ins define?

configFile ist eine echte Option, wenn's die nicht gibt, geht nichts kaputt, "man spricht" halt nicht "deutsch" => gehört m.E. nicht ins define.
rhasspyMaster wäre vermutlich sinnvoll in der DEF. Würde aber vorschlagen, das dann "Rhasspy" zu nennen (für den Dienst). Wobei man auch dort überlegen könnte, ob es optional sein soll mit default auf "localhost:12101".
(Generell: state ist bei mir noch leer).

[drhirn]

Bist du da sicher? Die Logik, Devices zu finden, hat sich mAn. zwischen 0.2.0 und der aktuellen Version nicht grundsätzlich vom Ablauf her verändert, wenn man davon absieht, dass jetzt "temperature" statt "Temperatur" abgefragt wird.

Also mein noch aktives Snips-Gerät meint auf die Frage "Wie warm ist es im Vorraum" - "Da ist etwas schief gegangen". Und die Logik zwischen Snips und 0.2.0 hat sich da eigentlich nicht verändert.

"Mein anderes Problem" mit den mehreren Sensoren rührt zum einen daher, dass es durch die gDT-Auswertung a) in der Tat plötzlich viele Temperatur-Geräte gibt und b) auch "desired-temp" nach "temperature" gemappt wird, was auch noch die Zahl der abfragbaren Werte (uneindeutig) an ein und demselbend Device erhöht.
Wenn man es in dem Sinne "richtig" macht, dass man alles händisch definiert und in jedem Raum genau einen Sensor hat, sollte es auch weiter problemlos laufen. Und wenn die "neue Methode" zu unlösbaren Problemen führt, ist es nie zu spät, bessere Alternativen zu diskutieren.

Nun ja, das ist ein Problem. Vielleicht sollten wir da wirklich nur auf das Mapping setzen?

Na ja, einer ist vermutlich eine Art "default", den man "eigentlich" haben will, wenn man nichts spezielles anfordert, aber in der Küche könnten schon Raumtemperatur, Kühlschrank und Backofen samt Garthermometer im Braten interessant sein, und auch im Heizraum (oder Garten) wäre es ähnlich (ja, auch im Garten habe ich auch einige Thermometer für diverse Zwecke...).

Ist richtig. Aber du wirst dir auf die Frage "Wie warm ist es in der Küche" nicht die Temperatur des Kühlschranks erwarten, oder? Da fragst du dann ja eher nach dem speziellen Gerät in dem speziellen Raum.

Es bleibt aber dabei, dass die Ansage auch in dem Fall, dass es wirklich keinen Sensor gibt, nicht kommentarlos "irgendwas" beinhalten sollte, oder?

Ja. Eindeutig.

configFile ist eine echte Option, wenn's die nicht gibt, geht nichts kaputt, "man spricht" halt nicht "deutsch" => gehört m.E. nicht ins define.

Jup, macht Sinn. Muss ich dann einfach in der Doku deutlicher herausstreichen, dass das Attribut gesetzt gehört.

rhasspyMaster wäre vermutlich sinnvoll in der DEF. Würde aber vorschlagen, das dann "Rhasspy" zu nennen (für den Dienst).

Nochmal "Rhasspy"? Das schafft Verwirrung befürchte ich. rhasspyMaster ist aber blöd, geb ich zu. "rhasspyURL", "baseURL", "rhasspyBase" oder was anderes?

Wobei man auch dort überlegen könnte, ob es optional sein soll mit default auf "localhost:12101".

Hmm, weiß nicht. Dann wäre eventuell eine Fehlermeldung/ein Hinweis bei Nicht-Erreichbarkeit gut.

(Generell: state ist bei mir noch leer).

Vorschläge?

Ich habe in meinem produktiven FHEM ein paar Geräte mit gDT. Nach einem update sieht mein Rhasspy-Slot de.fhem.Room jetzt so aus:

Code Auswählen Erweitern


Küche
Schlafzimmer
system->devices
multimedia
klo
shelly
küche->licht
wohnzimmer
Vorraum
beleuchtung
enocean
rhasspy
snips
mqtt2_device
Wohnzimmer

Da werden FHEM-Räume hergenommen. Nicht gut. Sollte nur befüllt werden, wenn es zum Device einen rhasspyRoom gibt.

[Beta-User]

Also mein noch aktives Snips-Gerät meint auf die Frage "Wie warm ist es im Vorraum" - "Da ist etwas schief gegangen". Und die Logik zwischen Snips und 0.2.0 hat sich da eigentlich nicht verändert.

Wie geschrieben: aus der Code-Logik hätte ich andere Schlüsse gezogen, aber vermutlich übersehe ich was...

Nun ja, das ist ein Problem. Vielleicht sollten wir da wirklich nur auf das Mapping setzen?

Hmm, klar, man könnte es einschränken. Aber vermutlich kommt das Thema wieder auf den Tisch, wenn jemand meint, nicht eindeutige Mappings verwenden zu wollen. Muss vermutlich bei Gelegenheit nochmal etwas spielen, um ein Gefühl für die Gesamtzusammenhänge zu bekommen. Im Ergebnis sollte es für den User einfach zu durchschauen sein, warum was passiert bzw. eine Eingriffstelle bekannt sein, mit der man das ggf. "fixt" bzw. eindeutig bekommt.

Ist richtig. Aber du wirst dir auf die Frage "Wie warm ist es in der Küche" nicht die Temperatur des Kühlschranks erwarten, oder? Da fragst du dann ja eher nach dem speziellen Gerät in dem speziellen Raum.

Schon, aber woher soll dann der Code wissen, welchen der Sensoren er jetzt heranziehen soll... Im Moment ist es einfach der erste gefundene Treffer, und das ganze aus einer Hash-Auswertung (=vermutlich zufällig...)

Ja. Eindeutig.

Wie gesagt: muss mal nachdenken/spielen...

Nochmal "Rhasspy"? Das schafft Verwirrung befürchte ich.

Bin da leidenschaftslos, zumal ich im Moment keinen Schimmer habe, wie man rausfinden kann, ob die URL/Port-Kombi erreichbar ist (auch wg. Log)...

Vorschläge?

_Wenn_ wir irgendwie wüßten, dass der Dienst läuft und erreichbar ist wäre connected/disconnected m.E. ganz passabel.

Ich habe in meinem produktiven FHEM ein paar Geräte mit gDT. Nach einem update sieht mein Rhasspy-Slot de.fhem.Room jetzt so aus:
[...]
Da werden FHEM-Räume hergenommen. Nicht gut. Sollte nur befüllt werden, wenn es zum Device einen rhasspyRoom gibt.

Finde ich auch nicht glücklich, würde aber den Schluss daraus ziehen, dass rhasspyRoom den room verdrängen sollte, wenn dieser gesetzt ist (sonst nicht).

Mit etwas Glück könnte das die Version im Anhang besser machen, für "Rhasspy" habe ich jetzt mal "IP_Port" verwendet, ist aber nur ein Vorschlag...

[Cordula]

Bin auch auf die Version 0.46a umgestiegen und hab folgendes festgestellt:

Wenn ich das Licht im Arbeitszimmer schalten will, schaltet er das Licht in der Toilette. Den rhasspyNamen gibt es in mehreren Räumen, kann man aber über den Raum unterscheiden. Hier die Details:

Code Auswählen Erweitern

attr Az.Licht rhasspyMapping SetOnOff:cmdOn=Schalten on,cmdOff=Schalten off,response={ResponseOnOff($DEVICE)}
attr Az.Licht rhasspyName Licht,Lampe
attr Az.Licht rhasspyRoom Arbeitszimmer

Code Auswählen Erweitern

attr Flur.Toilette_Licht rhasspyMapping SetOnOff:cmdOn=Schalten on,cmdOff=Schalten off,response={ResponseOnOff($DEVICE)}
attr Flur.Toilette_Licht rhasspyName Licht,Lampe,Toilettenlicht
attr Flur.Toilette_Licht rhasspyRoom Toilette

Code Auswählen Erweitern

2021.04.07 10:58:25 5: Parsed value: SetOnOff for key: intent
2021.04.07 10:58:25 5: Parsed value: mach das licht im arbeitszimmer an for key: rawInput
2021.04.07 10:58:25 5: Parsed value: arbeitszimmer-Okay Kalle-4d46865b-3283-4a55-89c8-cc9ff16b4136 for key: sessionId
2021.04.07 10:58:25 5: Parsed value: Licht for key: Device
2021.04.07 10:58:25 5: Parsed value: arbeitszimmer for key: Room
2021.04.07 10:58:25 5: Parsed value: mach das Licht im arbeitszimmer an for key: input
2021.04.07 10:58:25 5: Parsed value: arbeitszimmer for key: siteId
2021.04.07 10:58:25 5: Parsed value: 1 for key: probability
2021.04.07 10:58:25 5: handleIntentSetOnOff called
2021.04.07 10:58:25 5: Device selected (by hash, using only name): Flur.Toilette_Licht
2021.04.07 10:58:25 5: runCmd called with command: Schalten on
2021.04.07 10:58:25 5: Flur.Toilette_Licht Schalten on is a normal command
2021.04.07 10:58:25 5: Running command [Schalten on] on device [Flur.Toilette_Licht]
2021.04.07 10:58:25 5: runCmd called with command: {ResponseOnOff($DEVICE)}
2021.04.07 10:58:25 5: {ResponseOnOff($DEVICE)} is a perl command
2021.04.07 10:58:25 5: Response is Ok - Licht in Toilette ist angeschaltet

Wenn ich einen eindeutigen rhasspy-Namen verwende, funktioniert es.

In einem anderen Raum mit der gleichen Konstellation funktioniert das Schalten:

Code Auswählen Erweitern

attr Kueche.Licht rhasspyMapping SetOnOff:cmdOn=Schalten on,cmdOff=Schalten off,response={ResponseOnOff($DEVICE)}
attr Kueche.Licht rhasspyName Licht,Lampe,Küchenlicht
attr Kueche.Licht rhasspyRoom Küche

Code Auswählen Erweitern

2021.04.07 11:30:40 5: Parsed value: mach das Licht in der Küche an for key: input
2021.04.07 11:30:40 5: Parsed value: Küche for key: Room
2021.04.07 11:30:40 5: Parsed value: arbeitszimmer for key: siteId
2021.04.07 11:30:40 5: Parsed value: 1 for key: probability
2021.04.07 11:30:40 5: Parsed value: SetOnOff for key: intent
2021.04.07 11:30:40 5: Parsed value: an for key: Value
2021.04.07 11:30:40 5: Parsed value: mach das licht in der küche an for key: rawInput
2021.04.07 11:30:40 5: Parsed value: arbeitszimmer-Okay Kalle-f0ab281c-1232-445b-84a0-bd4c72efc9e1 for key: sessionId
2021.04.07 11:30:40 5: handleIntentSetOnOff called
2021.04.07 11:30:40 5: Device selected (by hash, with room and name): Kueche.Licht

Einmal sucht er nur über den Namen und einmal über den Namen und den Raum.
Hab ich da was falsch definiert oder wo liegt das Problem.

Zum anderen habe ich einen rhasspyIntent ohne Parameter definiert. Hat bisher funktioniert, jetzt bringt er folgende Fehlermeldung:

Code Auswählen Erweitern

rhasspyIntent wie folgt definiert
MyOpen=MyOpen()

Parsed value: 1 for key: probability
2021.04.07 11:00:59 5: Parsed value: arbeitszimmer for key: siteId
2021.04.07 11:00:59 5: Parsed value: Sind türen oder Fenster offen for key: input
2021.04.07 11:00:59 5: Parsed value: arbeitszimmer-Okay Kalle-a84627b5-951d-44db-89b8-f7b939c8f90c for key: sessionId
2021.04.07 11:00:59 5: Parsed value: sind türen oder fenster offen for key: rawInput
2021.04.07 11:00:59 5: Parsed value: MyOpen for key: intent
2021.04.07 11:00:59 5: handleCustomIntent called with MyOpen key
2021.04.07 11:00:59 5: Calling sub:  MyOpen( "" )
2021.04.07 11:00:59 1: ERROR evaluating  MyOpen( "" ) : Too many arguments for main::MyOpen at (eval 192598) line 1, near """ )

Desweiteren ist mir aufgefallen, dass bei rhasspyIntents Parameter, die eigentlich leer sind, jetzt der Name des Parameters enthalten. Eigentlich das Gleiche wie oben. Je nach Befehl werden unterschiedliche Variablen gefüllt.
In dem Beispiel sind Room und Change eigentlich leer.

Code Auswählen Erweitern

Parsed value: mach die lamellen der türjalousie auf fünfzig prozent for key: rawInput

MyBlinds=MyBlinds(Device,Room,Value,Change,Lamellen)

Calling sub:  MyBlinds( "Az.Jalousie_Tuer","Room","50","Change","lamellen" )


Zunächst einmal Danke für eure Arbeit. Wenn mir noch was auffällt, melde ich mich.

PS:
Das getNumeric-Problem habe ich auch. Für mich wäre folgende Reihenfolge der Devicebestimmung ok.

• Zuordnung über den Type (z.B. Temperatur)
• Zuordnung über einen eindeutigen Devicenamen und den Raum. Wenn der Raum fehlt, wird die siteid als Raum genommen.
• Zuordnung über einen eindeutigen Devicenamen, den es nur einmal im System gibt (z.B. hab ich nur ein Gerät, das den CO2-Gehalt misst.

[Beta-User]

Hmm, was die "Arbeitszimmer"-Thematik angeht würde ich auf ein Problem mit Groß/Kleinschreibung tippen. Sollte in der angehängten Version gelöst sein, da müßten dann sowohl Räume wie Namen alle in Kleinschreibung an Rhasspy übermittelt werden. (Habe bisher nur mit Kleinschreibung experimentiert).

Das mit parameterlosen Perl-Aufrufen und (echtem) "undef" statt des Parameternamens könnte mit dem Anhang auch funktionieren, ist aber ungetestet.

Code Auswählen Erweitern


PS:
Das getNumeric-Problem habe ich auch. Für mich wäre folgende Reihenfolge der Devicebestimmung ok.
Zuordnung über den Type (z.B. Temperatur)Zuordnung über einen eindeutigen Devicenamen und den Raum. Wenn der Raum fehlt, wird die siteid als Raum genommen. Zuordnung über einen eindeutigen Devicenamen, den es nur einmal im System gibt (z.B. hab ich nur ein Gerät, das den CO2-Gehalt misst.
Meinem Bauchgefühl nach ist "Type" eigentlich "gesetzt", ich hatte aber auch ein paar seltsame Ergebnisse, wenn der Devicename nicht sauber erkannt wurde.
Die Suche sollte dann immer über Devicename und Raum gehen (ggf. abgeleitet von siteId bzw. der Reading-Auswertung), spannend wird es erst, wenn da nichts zu finden ist. Dann sollte nämlich der Raum mit angesagt werden, aus dem das dann geholt worden ist, ganz unabhängig davon, ob es nun genau einen Treffer gab oder mehrere.

[Cordula]

Also der parameterlose Perlaufruf funktioniert.

Bei den undefinierten Parametern habe ich folgendes Ergebnis:

Code Auswählen Erweitern

Calling sub:  MyBlinds( ,,"50",,"lamellen" )
2021.04.07 13:35:42 1: ERROR evaluating  MyBlinds( ,,"50",,"lamellen" ) : syntax error at (eval 221535) line 1, near "( ,"

Beim Problem mit dem Licht schalten im Arbeitszimmer, wird nun das Schlafzimmerlicht geschaltet, es wird aber immer nur noch nach dem Namen gesucht.

Code Auswählen Erweitern

Parsed value: mach das licht im arbeitszimmer an for key: rawInput
2021.04.07 13:49:19 5: Parsed value: SetOnOff for key: intent
2021.04.07 13:49:19 5: Parsed value: an for key: Value
2021.04.07 13:49:19 5: Parsed value: 1 for key: probability
2021.04.07 13:49:19 5: Parsed value: arbeitszimmer for key: siteId
2021.04.07 13:49:19 5: Parsed value: mach das Licht im arbeitszimmer an for key: input
2021.04.07 13:49:19 5: Parsed value: arbeitszimmer for key: Room
2021.04.07 13:49:19 5: Parsed value: Licht for key: Device
2021.04.07 13:49:19 5: handleIntentSetOnOff called
2021.04.07 13:49:19 5: Device selected (by hash, using only name): Sz.Lichter
2021.04.07 13:49:19 5: runCmd called with command: Schalten on
2021.04.07 13:49:19 5: Sz.Lichter Schalten on is a normal command

[Beta-User]

Hmm, da muss wohl ein "echtes undef" hin, sollte so klappen:

Code Auswählen Erweitern

for (@rets) {
            if ($_ eq 'NAME') {
                $_ = qq{"$hash->{NAME}"};
            } elsif ($_ eq 'DATA') {
                $_ = $data;
            } elsif (defined $data->{$_}) {
                $_ = qq{"$data->{$_}"};
            } else {
                $_ = "undef";
            }
        }
(Das sieht grausam aus, finde ich auch...!).

Was den Raumnamen angeht: Hattest du die devicemap aktualisiert bzw. FHEM neu gestartet? (M.E. sollte das mit der devicemap zwingend sein, damit auch Rhasspy wieder konsistente Daten hat).

Stehen denn dann ausschließlich "kleine" Räume und Namen im Hash? (Im Ergebnis sollten eigentlich letztendlich ausschließlich die echten Devicenamen korrekte Groß/Kleinschreibung aufweisen).

Ansonsten ist es wie schon geschrieben ein "Hash"-Zugriff und daher das Ergebnis bei mehreren potentiellen Matches innerhalb einer loop zufällig. (Fyi: Das kann früher etwas anders gewesen sein, weil das damals genutzte devspec2array vermutlich eine sortierte Liste zurückgibt.)

[drhirn]

Schon, aber woher soll dann der Code wissen, welchen der Sensoren er jetzt heranziehen soll...

Hmm, ist ein Argument. Hab nicht dran gedacht, dass die anderen Sensoren ja auch ein temperature-mapping haben könnten.

Bin da leidenschaftslos, zumal ich im Moment keinen Schimmer habe, wie man rausfinden kann, ob die URL/Port-Kombi erreichbar ist (auch wg. Log)..._Wenn_ wir irgendwie wüßten, dass der Dienst läuft und erreichbar ist wäre connected/disconnected m.E. ganz passabel.

Da sollte einfach über ein curl/wget/HttpUtils gehen. Kommt was zurück, ist gut. Wenn nicht, nicht. . Wir könnten ja da einfach /api/profile abfragen.

Finde ich auch nicht glücklich, würde aber den Schluss daraus ziehen, dass rhasspyRoom den room verdrängen sollte, wenn dieser gesetzt ist (sonst nicht).

Bin noch nicht ganz überzeugt. Im Prinzip ist's egal, ob ich im Slot merkwürdige Raum-Namen habe. Schön ist's nicht.

Sollten wir alexaRoom, snipsRoom, etc. auch abfragen, wenn wir schon gDT verwenden?

Mit etwas Glück könnte das die Version im Anhang besser machen, für "Rhasspy" habe ich jetzt mal "IP_Port" verwendet, ist aber nur ein Vorschlag...

Funktioniert. IP_Port ist aber nicht sooo glücklich. Da bin ich als IT-Profi gleich reingefallen und hab http:// nicht angegeben

[drhirn]

Blöde Frage: Wo bekomme ich eigentlich das genericDeviceType Attribut her? Hab das in meiner Test-Umgebung nicht.

[drhirn]

Mit etwas Glück könnte das die Version im Anhang besser machen, für "Rhasspy" habe ich jetzt mal "IP_Port" verwendet, ist aber nur ein Vorschlag...

Kommando zurück. Ist IP_Port nicht im DEF angegeben, wird auch der Hash nicht befüllt.

[Beta-User]

Blöde Frage: Wo bekomme ich eigentlich das genericDeviceType Attribut her? Hab das in meiner Test-Umgebung nicht.

Wenn du das in der DEF auf "use/1" setzt, sollte das Modul das selbst in die Liste der globalen Attribute einfügen .

Hmm, ist ein Argument. Hab nicht dran gedacht, dass die anderen Sensoren ja auch ein temperature-mapping haben könnten.

Na ja, vermutlich finden wir dazu eine Lösung, muss ja nicht gleich sein... Evtl. sollten wir uns als erstes darum kümmern, dass eine nachvollziehbare Rückmeldung kommt, also Device (1. rhasspyName) und Room (selbe Logik) mit ausgegeben werden.

Da sollte einfach über ein curl/wget/HttpUtils gehen. Kommt was zurück, ist gut. Wenn nicht, nicht. . Wir könnten ja da einfach /api/profile abfragen.

Das ist nun gar nicht mein Kenntnishorizont...

Bin noch nicht ganz überzeugt. Im Prinzip ist's egal, ob ich im Slot merkwürdige Raum-Namen habe. Schön ist's nicht.

Na ja, das war was, das ich bei meinen bisherigen Tests auch nicht gut fand, und an sich finde ich durchgängige Verwendung der "allgemeinen Logik" besser: Gibt der User in einem speziellen Attribut was an, verdrängt das die vom Modul zusammengesuchten.
Solange das "per Attribut-Gruppe" abgegrenzt ist, finde ich das eher hilfreich, schon alleine, weil Rhasspy die gegliederten Räume nicht sinnvoll aussprechen kann...

Sollten wir alexaRoom, snipsRoom, etc. auch abfragen, wenn wir schon gDT verwenden?

Na ja, ich wollte erst mal zeigen, wie es prinzipiell gehen könnte, von daher spricht wenig gegen "alexaRoom" (ist da auch das Trennzeichen ein ";"?). snipsRoom ist halt eigentlich ein Relikt, da würde es mehr Sinn machen, das dadurch zu überehmen, dass man als prefix "snips" angibt . (Es fehlt "nur" eine Umbenennungsfunktion...)

Funktioniert. IP_Port ist aber nicht sooo glücklich. Da bin ich als IT-Profi gleich reingefallen und hab http:// nicht angegeben

Wie gesagt, bin leidenschaftslos, aber dann sollte man vermutlich dem localhost:1201 auch den http://-header spendieren...?
Hier wird der Hash befüllt, kann nur nicht testen, ob das funktional ist. Grundsätzlich wird sich immer die Frage stellen, wieviel Nutzerführung man an der Stelle braucht/einprogrammieren will.

[drhirn]

Wenn du das in der DEF auf "use/1" setzt, sollte das Modul das selbst in die Liste der globalen Attribute einfügen .

Hab ich schon mal erwähnt, dass hier im Forum das Hand->Kopf Emoticon fehlt?

Evtl. sollten wir uns als erstes darum kümmern, dass eine nachvollziehbare Rückmeldung kommt, also Device (1. rhasspyName) und Room (selbe Logik) mit ausgegeben werden.

Mhm, wär sinnvoll. Auch wenn ich irgendwie kurze, knackige Antworten bevorzuge. Also auf die Frage "Wie warm ist es im Wohnzimmer?", ist mir eigentlich die Antwort "21 Grad" lieber als "Die Temperatur im Wohnzimmer beträgt 21 Grad"

Das ist nun gar nicht mein Kenntnishorizont...

Ist eigentlich alles schon da (fetchSiteIds). Ich schau bei Gelegenheit mal, wie ich das missbrauchen könnte.

Na ja, ich wollte erst mal zeigen, wie es prinzipiell gehen könnte, von daher spricht wenig gegen "alexaRoom" (ist da auch das Trennzeichen ein ";"?).

Keine Ahnung. Müsste jemand anderes beantworten.

snipsRoom ist halt eigentlich ein Relikt, da würde es mehr Sinn machen, das dadurch zu überehmen, dass man als prefix "snips" angibt .

War nur ein Beispiel, weil mir sonst nichts eingefallen ist. Um irgendwelche Snips-Attribute brauchen wir uns nicht zu kümmern finde ich.

Wie gesagt, bin leidenschaftslos, aber dann sollte man vermutlich dem localhost:1201 auch den http://-header spendieren...?

Ja, unbedingt!

Hier wird der Hash befüllt, kann nur nicht testen, ob das funktional ist. Grundsätzlich wird sich immer die Frage stellen, wieviel Nutzerführung man an der Stelle braucht/einprogrammieren will.

Ich träume davon, dass einer defmod Rhasspy RHASSPY eingibt und dann mittels Pop-Ups durch die übrigen Angaben geleitet wird. Wie bei attrTemplate.

[Beta-User]

Hab ich schon mal erwähnt, dass hier im Forum das Hand->Kopf Emoticon fehlt?

Hatte ich nicht schon angemerkt, dass es gar nicht so einfach ist, immer den Überblick zu behalten...?

Ich träume davon, dass einer defmod Rhasspy RHASSPY eingibt und dann mittels Pop-Ups durch die übrigen Angaben geleitet wird. Wie bei attrTemplate.

Sowas könnte man schon machen, ABER: Entweder man arbeitet mit defaults, dann braucht der User praktisch NICHTS anzugeben (btw. @JensS: encoding steht per default auf UTF-8, das braucht man nur zu setzen, wenn man es anders haben will), oder man zwingt ihn dazu, was anzugeben; das wäre über Prüfungen in der DEF machbar, vorausgesetzt, wir benötigen keine asynchronen Rückmeldungen.

MAn. sollte man es dem User bei so einer komplexen Geschichte wie Rhasspy zumuten, mal in die cref-Optionen reinzuschauen, weil er nur dann erkennen kann, ob es da Dinge gibt, die ihn sehr viel weiterbringen könnten - wie z.B. die Sache mit verschiedenen Sprachen oder präfixen und fhemId's...

Daher finde ich eine sinnvolle Vorbelegung die zielführendste Variante, denn in der Detailansicht/im list kann dann der User sehen, was alles "Sache" ist. Gefällt es ihm dann nicht (oder stellt er sich die Frage, warum es da steht), kann er in die cref schauen, und wir Helfer haben via list eine Übersicht.

Mhm, wär sinnvoll. Auch wenn ich irgendwie kurze, knackige Antworten bevorzuge. Also auf die Frage "Wie warm ist es im Wohnzimmer?", ist mir eigentlich die Antwort "21 Grad" lieber als "Die Temperatur im Wohnzimmer beträgt 21 Grad"

Prinzipielle Zustimmung. Setzt voraus, dass wir uns im Code merken, ob das "Ergebnis" eindeutig war (Device, Raum, Mapping). Wenn nicht => andere Rückmeldung. (Vermutlich) kein Hexenwerk, aber (zu treibender) Aufwand.

Ist eigentlich alles schon da (fetchSiteIds). Ich schau bei Gelegenheit mal, wie ich das missbrauchen könnte.

Gerne .

Keine Ahnung. Müsste jemand anderes beantworten.

Hatte auf die Schnelle die Doku durchforstet und zum ganzen nur Bruchstücke gefunden, uA. eben den Hinweis, dass alexaName per Semicolon trennt (super... ganz im Stile aller sonstigen FHEM-Konventionen...)

War nur ein Beispiel, weil mir sonst nichts eingefallen ist. Um irgendwelche Snips-Attribute brauchen wir uns nicht zu kümmern finde ich.

Na ja, wenn man das mit einem simplen "prefix"-Trick hinbekommt, soll's mir recht sein. Aber zusätzlichen Aufwand würde ich nicht reinstecken wollen.

Ja, unbedingt!

(Hoffentlich) done, siehe Anhang...
Im Sinne von: "User kann stressfrei direkt mit den defaults loslegen" die Frage, ob das auch paßt, wenn Rhasspy in docker auf demselben Server läuft?

[drhirn]

Sowas könnte man schon machen, ABER: Entweder man arbeitet mit defaults, dann braucht der User praktisch NICHTS anzugeben, oder man zwingt ihn dazu, was anzugeben; das wäre über Prüfungen in der DEF machbar, vorausgesetzt, wir benötigen keine asynchronen Rückmeldungen.

MAn. sollte man es dem User bei so einer komplexen Geschichte wie Rhasspy zumuten, mal in die cref-Optionen reinzuschauen, weil er nur dann erkennen kann, ob es da Dinge gibt, die ihn sehr viel weiterbringen könnten - wie z.B. die Sache mit verschiedenen Sprachen oder präfixen und fhemId's...

Daher finde ich eine sinnvolle Vorbelegung die zielführendste Variante, denn in der Detailansicht/im list kann dann der User sehen, was alles "Sache" ist. Gefällt es ihm dann nicht (oder stellt er sich die Frage, warum es da steht), kann er in die cref schauen, und wir Helfer haben via list eine Übersicht.

Nun ja, mein Traum beinhaltet mit den Default-Werten vorbelegte Pop-Ups und einer Erklärung zur jeweiligen Einstellung dazu. Entweder man gibt was ein, oder übernimmt mit "Weiter" den Default-Wert.
Die Sache mit Asynchron ist halt ein Problem. Da müsste dann sichergestellt werden, dass mindestens das Modul danach neu geladen wird.

(super... ganz im Stile aller sonstigen FHEM-Konventionen...)

Ist das jetzt ironisch gemeint? Oder sollten wir auch auf Strickpunkt umstellen?

Im Sinne von: "User kann stressfrei direkt mit den defaults loslegen" die Frage, ob das auch paßt, wenn Rhasspy in docker auf demselben Server läuft?

Solange FHEM nicht in einem Container läuft, sollte das funktionieren. Das muss aber eh der User selber wissen.

[Beta-User]

Nun ja, mein Traum beinhaltet mit den Default-Werten vorbelegte Pop-Ups und einer Erklärung zur jeweiligen Einstellung dazu. Entweder man gibt was ein, oder übernimmt mit "Weiter" den Default-Wert.
Die Sache mit Asynchron ist halt ein Problem. Da müsste dann sichergestellt werden, dass mindestens das Modul danach neu geladen wird.

Ja, Träume...
Wird eher nichts werden, und wir werden die Nutzerführung halt auf herkömmliche Weise via commandref machen .


Ist das jetzt ironisch gemeint? Oder sollten wir auch auf Strickpunkt umstellen?

Ja, aber eher in die andere Richtung: Es gibt allgemeine Attribute für room und group, da wird Komma-getrennt; warum das jetzt alexa an der ähnlichen Stelle anders macht, erschließt sich mir nicht.

Solange FHEM nicht in einem Container läuft, sollte das funktionieren. Das muss aber eh der User selber wissen.

Dann ist es gut so...