speechrecogn.template: bugs, Fragen, Anregungen

[TomLee]

Hmm, seit 2-3 Tagen gibt es jetzt zu neuen Geräten (bei Alexa ist default der filter der alexaName) Notifications von der Alexa-App (ohne das alexa-fhem neu gestartet wurde, nur die Vergabe des Attributs reicht). Hab mich aber noch nicht damit beschäftigt (wie man sie wieder deaktiviert, das ist Premiere seit alexa-fhem) bisher hat auch keiner davon berichtet, also einfach mal alexaName vergeben find ich nicht gut. weiter schlafen  ...

oder ist das dann innovativ ?

[justme1968]

das man möglichst ohne alexa-fhem neustart auskommen soll ist schon immer so.

entweder per set <alexa> add ... oder set <alexa> reload.

auch das änderungen an attributen möglichst live übernommen werden sollen ist schon immer so. ich habe aber erst vor ein paar wochen einen big hierzu behoben der das leider meist verhindert hat.

das alles ist also gewollt.


ob man automatisch den alexaName setzt oder das dem anwender überlässt ist aber eine andere geschichte. das müsst ihr unter euch ausmachen.

[Beta-User]

Danke erst mal für die Rückmeldungen.

Hab's mir jetzt auch nochmal von der Struktur her angesehen, und eventuell jetzt  einen aktzeptablen Kompromis anzubieten...?

1. Klar ist: Würde man die genericDeviceType- (+teilw. mapping-) Vergabe rausnehmen wollen, würde alles sehr viel komplizierter. Vor allem wegen diesem Argument:

Ich plaediere fuer eine einfache Loesung, und alles "sinnvolle" zu setzen.
Attribute zu entfernen ist einfach [...]

Mit diesem Grundansatz muß der Anwender erst mal nicht allzuviel nachdenken, kann aber korrigierend eingreifen, was ungleich einfacher ist, als nachträglich irgendwas mit den richtigen Parametern aufzurufen.

2. Unklar ist, welche Rolle "alias" hier spielt. Verstehe ich das richtig, dass dieser aus sr-Sicht funktional gleichwertig ist mit dem alexaName? (Ist irritierend, da alias eben nicht eindeutig ist...!)
Selbst wenn es so wäre, wäre mir die Schlussfolgerung zu weitgehend, dass dieser Seiteneffekt  massive Auswirkungen auf die Gesamtstruktur der templates haben sollte.

Neige im Moment dazu, "alexa" wieder anzuschalten, allerdings dann mit folgendem "firstrun":

Code Auswählen Erweitern


name:speech_recognition_alaxaName_firstrun
filter:NAME=speechrecognTesting
order:1000020a
desc:generic template to set speech recognition attribute alexaName, call e.g. with set xy attrTemplate speech_recognition_alaxaName_firstrun ALEXANAME=myAlexaName
option:{my @devices=devspec2array("TYPE=(alexa)");; $devices[0] ? return 1 : return 0}
par:ALEXANAME;Please enter alexaName. Pls. enter something, even if you do not want any name to be set, use the offered radio option to skip naming instead!;{ AttrVal("DEVICE","alexaName",undef) }
par:RADIO_SETalexaNAME;Enable this to really set the name you entered above!;{ undef }
par:RADIO_DoNotSetalexaName;Enable this to SKIP setting alexaName attribute!;{ undef }
par:RADIO_Delete_gDT;Enable this to DELETE genericDeviceType attribute!;{ undef }
option:{ RADIO_Delete_gDT }
deleteAttr DEVICE genericDeviceType
option:{ RADIO_DoNotSetalexaName }
option:{ RADIO_SETalexaNAME }
attr DEVICE alexaName ALEXANAME
set DEVICE attrTemplate speech_recognition_alaxaName_secondrun ALEXAISNAME=ALEXANAME

@TomLee: Wäre nett, wenn du das testen könntest.
Es sollte dem User eine Auswahl bieten, die den meisten Anwendungsfällen halbwegs gerecht wird.

Was evtl. noch fehlt, wäre
- ein 4. RADIO, mit dem man das generell ausschalten kann (das wäre dann ein userattr am alexa-Device)
- ein "Zwischentemplate", das dieses userattr abfragt und dann den nachfolgenden Schritt gar nicht mehr aufruft.

Woran man noch feilen könnte, wäre die Reihung dieser Dinge, also v.a. die Namensabfrage in einen weiteren Schritt auszulagern (es ist nicht so ganz easy zu verstehen, dass man was eingeben muß, selbst wenn man am Ende ja gar nichts setzen will...). Da wären Meinungen zu erbeten, aber vorher wäre es gut, wir hätten Einvernehmen über die grundsätzliche Herangehensweise.

[justme1968]

1. ja. genericDeviceType kann und sollte automatisch gesetzt werden

2. alias ist der fallback wenn alexaName nicht gesetzt ist. beides muss nicht eindeutig sein. die sprachassistenten verstehen inzwischen meist die unterscheidung anhand des raumes oder fragen sogar nach. es ist auf dauer auch garnicht möglich sich für jedes gerät einen wirklich eindeutigen namen auszudenken.

ich glaube wir haben eine art henne und ei problem. an irgendeiner stell musst der benutzer sagen welche geräte er per sprachsteuerung zur verfügung haben möchte. das kann sein alle, bestimmte geräte die bedingung x erfüllen oder als spezialfall nur die, die er von einzeln spezifiziert.

wenn ein neues gerät hinzukommt ist 1. kein problem, bei 2 vielleicht auch nicht, bei 3 stellt sich aber die frage ob das gerät hinzugefügt werden soll, mit der konsequenz das z.b. der filter erweitert wird, oder ob der filter schon richtig ist und verwendet werden kann um zu bestimmen ob ein gerät hinzugefügt wird.

man könnte jetzt nur den einfachen fall betrachten: filter steht auf alexaName. das würde bedeuten das man im template fragt ob das aktuelle gerät zur sprachsteuerung hinzugefügt werden soll. wenn ja -> alexaName setzen, wenn nein: alles andere setzen.

[Beta-User]

Das mit dem filter verstehe ich nicht ganz.

Zumindest bei den MQTT2-Geräten ist es ja so, dass diese erst durch die templates zu dem werden, was sie sind, MQTT2_DEVICE weiß im Prinzip ja (fast) nichts über das betreffende Gerät. Mindestens da macht es mMn. nicht so viel Sinn, für die templates den alexaName vorauszusetzen, sondern die Frage ist ja, ob der durch das "eine" template, das man aufruft, um z.B. ein tasmota-Doppelrelais zum Rollladenaktor zu kofigurieren, dann auch gleich die sr mit erledigen sollte oder nicht bzw. in welcher Form.

Mein aktueller Vorschlag besagt: Miterledigen, aber dem User die Wahl bieten, ob er auch den alexaName mit vergeben will, das lassen oder den genericDeviceType (gleich wieder) löschen. Da das ganze immer voraussetzt, dass überhaupt eine sr definiert ist, ist das m.E. die Wahl, die dieser user-Kreis am ehesten erwartet, oder liege ich da falsch?



Wenn der alexaName nicht eindeutig sein muß, machen "secondrun" und "thirdrun" in der jetzigen Form keinen Sinn und die Aufrufe müssen für die mehrkanaligen Geräte anders sein (ist kein Drama, es erfordert eben diverse Anpassungen betr. "defaults", die seither über copy gesetzt waren; (denke ich zumindest im Moment)). Muss ich mir mal näher ansehen, wird aber etwas dauern...

[Beta-User]

So, zu guter Letzt noch eine Variante mit  nachträglicher Abfrage des Namens und etwas anderen Hinweistexten und template-Namen:

Code Auswählen Erweitern

name:speech_recognition_general_naming_master_template
filter:genericDeviceType=.+
order:10000200
desc:generic template to set attributes for identifying this device by speech recognition software. This template will call several sub-templates - dependent on the speech recognition solutions which are in use in your installation. Pls. do not use one of the subtemplates directly. Call e.g. with set xy attrTemplate speech_recognition_general_naming_master_template
option:{my @devices=devspec2array("TYPE=siri");; $devices[0] ? return 1 : return 0}
option:{my @devices=devspec2array("TYPE=alexa");; $devices[0] ? return 1 : return 0}
set DEVICE attrTemplate speech_recognition_alaxa_specials
option:{my @devices=devspec2array("TYPE=gassistant");; $devices[0] ? return 1 : return 0}


name:speech_recognition_alaxa_specials
filter:NAME=speechrecognTesting
order:1000020a
desc:generic template to set speech recognition attribute alexaName, call e.g. with set xy attrTemplate speech_recognition_alaxa_specials ALEXANAME=myAlexaName
option:{my @devices=devspec2array("TYPE=(alexa)");; $devices[0] ? return 1 : return 0}
#par:ALEXANAME;Please enter alexaName. Pls. enter something, even if you do not want any name to be set, use the offered radio option to skip naming instead!;{ AttrVal("DEVICE","alexaName",undef) }
par:ALEXAISNAME;Current attribute value alexaName;{ AttrVal("DEVICE","alexaName","(not set)") }
par:RADIO_SETalexaNAME;Set a (new) alexaName, current value is: ALEXAISNAME;{ undef }
par:RADIO_DoNotSetalexaName;Leave alexaName attribute unchanged (or unset);{ undef }
par:RADIO_Delete_gDT;DELETE genericDeviceType attribute (or do not set it by attrTemplate);{ undef }
option:{ RADIO_Delete_gDT }
deleteAttr DEVICE genericDeviceType
option:{ RADIO_DoNotSetalexaName }
option:{ RADIO_SETalexaNAME }
#attr DEVICE alexaName ALEXANAME
set DEVICE attrTemplate speech_recognition_request_alaxaName

name:speech_recognition_request_alaxaName
filter:NAME=speechrecognTesting
order:1000020b
desc:generic template to ask for alexaName attribute setting. Only intented for internal use by speech_recognition_alaxaName
par:ALEXAISNAME;Current attribute value alexaName;{ AttrVal("DEVICE","alexaName","(not set)") }
par:ALEXANAME;Please enter alexaName. Current value: ALEXAISNAME;{ undef }
option:{my @devices=devspec2array("TYPE=(alexa)");; $devices[0] ? return 1 : return 0}
attr DEVICE alexaName ALEXANAME
Jedenfalls vom theoretischen Ansatz her gefällt mir das am besten. Falls es keine Rückmeldungen gibt, dass es _nicht_ funktioniert, checke ich das in dieser Form bei Gelegenheit ein...

Grüße, Beta-User

[TomLee]

Es funktioniert.
Hut ab was du da mit "Behinderung" für theoretische Ansätze zauberst.
Es sind ja nur noch die Optionsfelder von all meinen Vorschlägen übrig
Wusste nicht das Alexa jetzt schon so "intelligent" ist bei doppelten Namen nachzufragen welcher gemeint ist.
genericDeviceType erstmal zu setzen und mit dem Dialogfenster die Möglichkeit zu haben wieder zu löschen, mir fehlen die Gehirnwindungen auf sowas zu kommen, das alles mit noch kürzerem Code wie zuvor.

Mir gefällt der letzte Vorschlag.

Ich frag mich wie du jetzt den siriNamen (und den von GoogleAssistant, kenn ich aber nicht) abfragen willst.
Warum übernimmst du immer wieder ...alaxa.. in die neuen Vorschläge.

Verständlicher fänd ich es ohne Doku-Englisch, wer ausser die die sich mit dem Template selbst beschäftigt haben, können was mit ALEXAISNAME oder unset was anfangen, irritiert mMn. nur:

Code Auswählen Erweitern

Set a (new) alexaName, current value is: ALEXAISNAME
Leave alexaName attribute unchanged (or unset)
DELETE genericDeviceType attribute (or do not set it by attrTemplate)

Code Auswählen Erweitern

Set a new alexaName
Leave alexaName attribute empty
Discard genericDeviceType attribute

[Beta-User]

  Das ist doch schon mal was.

Was (kürzere) wording ist m.E. ein sinnvoller Vorschlag, ich hatte angenommen, dass das ggf. durch Echtwerte ersetzt wird und man ggf. nicht unbeabsichtigt was vorhandenes überschreibt, sondern das Vorhandene als Referenz hat...

Betr. siriName (gibt's sowas...?): Für die weiteren sr-Varianten können wir im Prinzip dann die alexa-Struktur (mit jeweils anderen Namen übernehmen, oder spricht was dagegen?
Bzw. braucht es irgendeine Auswertung vorab, um abzufragen, ob schon was vorhanden ist. K.A., aber evtl. ist die interne Logik @siri ja: Nimm' den alexaName (oder alias...?), falls es keinen siriName gibt. Das wäre dann nämlich einigermaßen schwierig abzufangen, da müßte ich dann erst mal Info haben und dann wieder "ein bißchen" nachdenken, ob und wie man das ggf. auch noch mit den diversen Behinderungen hinbekommt  ...

(Oder sollte: "Warum übernimmst du immer wieder ...alaxa.. in die neuen Vorschläge." bedeuten: Wenn beides da ist, übernimm den vergebenen alexaName auch direkt als siriName? Das sollte bei Arraygröße = 2 und entsprechener option-regex gehen...)

[joelinux]

So, zu guter Letzt noch eine Variante mit  nachträglicher Abfrage des Namens und etwas anderen Hinweistexten und template-Namen:

Die Idee kommt mir sehr entgegen.

Mit der Konfiguration von alexa-fhem habe ich den Willen bekundet grundsätzlich Spracherkennung einzusetzen.
Nachfragen ob ich einen alexaNamen setzen möchte oder auch nicht ist prima und unkompliziert.

Die dritte Option sogar genericDeviceType wegzulassen gefällt mir auch. Damit wird das Gerät vor der automagischen Erkennung der Spracherkennung "versteckt".
Vielleicht ist der Hinweistext für diese Auswahl dahingehend zu verändern. Es ist zunächst richtig das genericDeviceType nicht gesetzt wird.
Die Wirkung daraus, das das Gerät nicht mit in die Spracherkennung eingebunden wird ist möglicherweise interessanter nachzulesen.

Mit freundlichem Gruß

joelinux       

[TomLee]

Die dritte Option sogar genericDeviceType wegzulassen gefällt mir auch. Damit wird das Gerät vor der automagischen Erkennung der Spracherkennung "versteckt".

Du hast da was missverstanden, das speech_recognition_general_naming_master_template wird, wenn per update verteilt, aus einem allgemeinen Template aufgerufen wo der genericDeviceType immer vergeben wird, mit der dritten Option hast du die Möglichkeit dieses wieder zu löschen, so hab ich es zumindest verstanden

Automatisch erkannt werden Geräte abhängig vom gesetzten filter in der config.json. Per default ist das "filter": "alexaName=..*" -> alle Geräte mit alexaName werden von Alexa erkannt.
Hast du bei dir den filter auf das Attribut genericDeviceType gesetzt ? -> "filter": "genericDeviceType=..*"

[Beta-User]

Du hast da was missverstanden, das speech_recognition_general_naming_master_template wird, wenn per update verteilt, aus einem allgemeinen Template aufgerufen wo der genericDeviceType immer vergeben wird, mit der dritten Option hast du die Möglichkeit dieses wieder zu löschen, so hab ich es zumindest verstanden

Genau so wäre es (mit beiden Vorschlägen von gestern): genericDeviceType wird erst mal gesetzt, wenn irgendeine sr aktiviert ist. Mit dem Dialogfeld kann man das wieder löschen (wobei der user vermutlich erst mal nichts vom setzen+Löschen mitbekommt, es ist halt bei entsprechender Auswahl am Ende nicht (mehr) da...). 

Vielleicht ist der Hinweistext für diese Auswahl dahingehend zu verändern

Bin für zielführende  Vorschläge offen, im Moment war der letzte Vorschlag: "
Discard genericDeviceType attribute"

[joelinux]

Hast du bei dir den filter auf das Attribut genericDeviceType gesetzt ? -> "filter": "genericDeviceType=..*"

Diesen Filter habe ich nicht angefasst und steht auf alexaName=..*

Ich habe wohl das mit dem Fallback auf Alias Name wenn alexaName nicht gesetzt ist wahrscheinlich mißverstanden. 

[TomLee]

@Beta-User

da das mit dem filter dir scheinbar auch noch unklar ist, genauso verhält es sich bei homebridge-fhem.
Bei meinem weiter o. a. config.json -Beispiel wo die devspec auf room verweist, werden alle Geräte die sich im room Homekit befinden von hombridge gefunden. Das hatte ich damals aus dem Wiki übernommen und find ich auch übersichtlicher wie das die devspec auf den siriNamen verweist, wie das heute beim Connector ist ( einen Überblick auf die Alexa bekannten Geräte bekommt nur per devspec über die Kommandozeile, so sind alle schön in einem Raum)

Darum auch meine Frage hier mal ob man sich da auf einen Standard (zumindest per default, der Templates wegen) einigen könnte.
Auch wenn mir der filter auf siriName/alexaName weniger gefällt, dem Template im jetzigen Zustand käme das entgegen.

Allerdings

erschwerend kommt hinzu das für siri
die default config noch nicht automatisch erzeugt wird und dir wiki beispiele von anfang anders als das config.sample file das ich mit ausliefere waren.

Aber vielleicht kann man ja da eine Empfehlung im Wiki aussprechen, das es sonst nur eingeschränkte sr-Template Funktionalität gibt.

[TomLee]

Mit ...alaxa... war einfach nur der Schreibfehler in

Code Auswählen Erweitern

speech_recognition_alaxa_specials
speech_recognition_request_alaxaName
gemeint.

[Beta-User]

OK, jetzt habe ich den Typo auch entdeckt .

Was die filter-Frage in Homekit angeht (sorry wg. der "Böhmischen Dörfer": Wenn man das nicht selbst nutzt, sind diese ganzen Details irgendwie sehr schwer im Kopf zu behalten...), fände ich es weiter gut, sich an justme1968's Empfehlungen zu orientieren.

Das hieße wohl: siriName abfragen, analog alexaName.
Wieder mit allen Optionen, wäre die Frage, und ich wäre auch geneigt, das dahingehend zu "verfeinern", dass bei den weiteren sr-Varianten jeweils auch vorausgesetzt wird, dass der genericDeviceType noch gesetzt ist.

Im Moment wäre der Plan, das ggf. zeitnah (zumindest für alexa) scharf zu schalten, bei der Gelegenheit vielleicht dann mit einer leicht einzuschaltenden Erweiterung für den siri-Teil?
Müßte mir dazu aber nochmal den MQTT2-Teil ansehen betr. der mehrkanaligen bzw. internen Aufrufe. Da müssen an die richtige Stellen wohl noch einige option-Schalter hin. Mal schauen, ob das "unfallfrei" klappt.

Was das Wiki angeht: Wäre schön, wenn das jemand dahingehend überarbeiten würde, dass das, was da steht mit justme1968's Empfehlungen zusammenpaßt (Stand heute, auf "Altlasten" würde ich erst mal keine allzu große Rücksicht nehmen; dem Gefühl nach dürfte es dann auch nicht das große Problem sein, ggf. nachzusteuern oder was zu ergänzen). Wer auch immer sich dazu berufen fühlt, kann gerne auch "meine" Hinweise zu dynamischen Räumen (extraRooms) in dem MQTT-Thread entsprechend anpassen/übernehmen; wenn hier jemand Quelltext liefert, kann ich das auch ins Wiki transferieren...