FHEM Forum

Mit dem jetzigen Template stimmt was nicht.

Zitat# perl_code returns a value for the parameter, or undef.
14   # If undef, the user has to specify them (the comment is shown to the user)
15   
16   #original name:speech_recognition_type_switch
17   name:speech_recognition_type_switch
18   filter:NAME=speechrecognTesting
19   order:100001
20   option:{my @devices=devspec2array("TYPE=(siri|alexa|gassistant)");;return 1 if $devices[0];;return 0}
21   attr DEVICE genericDeviceType switch

Wenn ich das Template auswähle steht da original name:speech_recognition_type_switch drüber
original name:speech_recognition_type_switch

option:{my @devices=devspec2array("TYPE=(siri|alexa|gassistant)");;return 1 if $devices[0];;return 0}
attr DEVICE genericDeviceType switch
option:TYPE=siri
option:TYPE=alexa
option:TYPE=gassistant

Wenn ich das blind template auswähle steht da attr DEVICE userReadings NEWUSERREADINGS drüber, was nur in speech_recognition_type_light_255 vorkommt.

attr DEVICE userReadings NEWUSERREADINGS

option:{my @devices=devspec2array("TYPE=(siri|alexa|gassistant)");;return 1 if $devices[0];;return 0}
attr DEVICE genericDeviceType blind
option:TYPE=siri
option:TYPE=alexa
option:TYPE=gassistant


Alle Templates kann man aber ausführen und die Befehle werden auch ausgeführt.
Nur das neue, letzte speech_recognition_gdt_and_mapping kann man nicht ausführen, da kommt folgender Fehler:

Error checking template regexp: Can't find string terminator '"' anywhere before EOF at (eval 25309) line 1.

Gruß

Thomas

Das mit den "komischen" Überschriften kommt daher, dass keine desc: da ist; die Zeilen lösche ich noch raus bzw. irgendwann gibt es auch eine ordentliche desc dafür (im Moment sind die ja nur sichtbar, wenn man weiß wie...).

Das andere ist kniffeliger, und einer der Gründe, warum ich das vorab getestet haben wollte...
Vielleicht hilft es schon, wenn man die anderen quotes und HTML-Code verwendet? (Ungetestet):

par:HOMEBRIDGEMAPPING;HOMEBRIDGEMAPPING, defaults to 'ContactSensorState=state,values=closed:CONTACT_DETECTED&#3B&#3Bopen:CONTACT_NOT_DETECTED';{ 'ContactSensorState=state,values=closed:CONTACT_DETECTED;;open:CONTACT_NOT_DETECTED' }
Ansonsten müßte ich mal mit escape-Optionen rumtesten, AttrTemplate macht da jedenfalls ein Perl-split und erzeugt damit drei Teile, deswegen sollte es "hinten" klappen, selbst wenn die Anzeige vorne jetzt "verbogen" sein sollte...
(Andere Frage: ist das mit den doppelten ;; überhaupt notwendig, oder würde nicht eines reichen? Habe das nur aus der erstbesten Fundstelle rauskopiert und gehofft, dass sich schon ggf. jemand meldet, der es besser weiß...)

komm schon nicht mit wenn ich es mir genauer anschaue.

Warum 2 x 'ContactSensorState=state,values=closed:CONTACT_DETECTEDBBopen:CONTACT_NOT_DETECTED';{ 'ContactSensorState=state,values=closed:CONTACT_DETECTED;;open:CONTACT_NOT_DETECTED' }

Sollte ich jede Varianten einzeln probieren, darum das eine in geschwungenen Klammern, das etwas irritierend (für mich) weil das ja auch schon zuvor so im Template stand.

Mit
name:speech_recognition_gdt_and_mapping
filter:NAME=speechrecognTesting
order:100007
desc:call e.g. with set xy attrTemplate speech_recognition_gdt_and_mapping GENERICDEVICETYPE=Security HOMEBRIDGEMAPPING= "ContactSensorState=state,values=closed:CONTACT_DETECTED;;open:CONTACT_NOT_DETECTED"
option:{my @devices=devspec2array("TYPE=(siri|alexa|gassistant)");;return 1 if $devices[0];;return 0}
par:GENERICDEVICETYPE;GENERICDEVICETYPE <genericDeviceType>, defaults to contact;{ "contact" }
par:HOMEBRIDGEMAPPING;HOMEBRIDGEMAPPING, defaults to 'ContactSensorState=state,values=closed:CONTACT_DETECTED;;open:CONTACT_NOT_DETECTED'
attr DEVICE genericDeviceType GENERICDEVICETYPE
attr DEVICE homebridgeMapping HOMEBRIDGEMAPPING
option:TYPE=siri
option:TYPE=alexa
option:TYPE=gassistant

Sieht das Ergebnis aus:

Zitatdefmod speechrecognTesting MQTT2_DEVICE FGL
attr speechrecognTesting IODev MQTT2_Server
attr speechrecognTesting genericDeviceType GENERICspeechrecognTestingTYPE  ???
attr speechrecognTesting homebridgeMapping ContactSensorState=state,values=closed:CONTACT_DETECTED;;;;open:CONTACT_NOT_DETECTED
attr speechrecognTesting room Test

Mit dem Html Beispiel:

par:HOMEBRIDGEMAPPING;HOMEBRIDGEMAPPING, defaults to 'ContactSensorState=state,values=closed:CONTACT_DETECTEDBBopen:CONTACT_NOT_DETECTED'

gibts einen Fehler beim ausführen.

Zitat(Andere Frage: ist das mit den doppelten ;; überhaupt notwendig, oder würde nicht eines reichen? Habe das nur aus der erstbesten Fundstelle rauskopiert und gehofft, dass sich schon ggf. jemand meldet, der es besser weiß...)

zu homebridgeMapping sollte ich der letzte sein den du dazu befrägst, sonst heb ich schon von alleine die Hand.

So, Danke, das hat mir schon weitergeholfen, jetzt hoffe ich nur, dass wir mit der jetzigen svn-Version wieder einen kleinen Schritt weiter sind...
Bitte weitertesten...

Da ich mich jetzt mit beschäftigt habe und zumindest in Teilen verstanden habe traue ich mich jetzt zu sagen das das ja nix anderes wie zuvor ist, auch falsch.

Wende mal das Template nochmal an (egal ob man die Attribute zuvor auch löscht), im Wechsel wird weiterhin aus genericDeviceType einmal contact und einmal GENERICspeechrecognTestingTYPE.

In der jetzigen SVN-Version ist ein Fehler, das letzte " muss raus.

Zitat...traue ich mich jetzt zu sagen das das ja nix anderes wie zuvor ist, auch falsch.

sry, war zu schnell GENERICDEVTYPE wurde jetzt draus, jetzt passts.

Aber es bleibt dabei das das letzte " zuviel ist.

Anderes Thema, was mir durch den Kopf schwirrt wenn ich an speech-Template denke:

Das Geräte von Alexa überhaupt gefunden werden ist ein alexaName Bedingung.

Besteht die Möglichkeit das Dialogfeld welches bspw. erscheint wenn was mit STATTOPIC,TELETOPIC.CMDTOPIC nicht passt, dazu zu nutzen einen alexaName zu übergeben, der dann in das Attribute alexaName geschrieben wird ?

So, den " habe ich eben entfernt, und auch die weiteren setter im tasmota-rgbw-template eingefügt...

Neu sind jetzt zwei alexaName-spezifische templates. Die sind "heiß", weil sie rekursive Aufrufe enthalten - will heißen: Das geht so (noch) nicht! Wenn du das testen willst, UNBEDINGT die letzte Zeile (set DEVICE attrTemplate speech_recognition_alaxaName_firstrun) auskommentieren und die templates neu laden!

Gedacht ist das so: Das erste wird - ggf. später dann über die anderen attrTemplates in dem alexa-option-Zweig - aufgerufen und fragt den Namen ab. Das zweite prüft, ob es diesen Namen schon gibt - wenn ja, muß der User nachbessern. Das ganze basiert auf der Annahme, dass der alexaName FHEMweit nur einmal vorhanden sein darf. Wenn das falsch ist, können wir die letzte Zeile einfach löschen (die Abfrage brauchen wir trotzdem, wegen mehrkanaligen Devices - da wird erst mal alles einfach kopiert, was definitiv zu ungewollten Ergebnissen führen müßte.

Genau so dacht ich mir das  :-*  ;D, du verstehst mich.
Aber es klappt noch nicht, der vergebene Name wird nicht ins Attribut geschrieben, es passiert einfach nichts.
Kann mich aber erst heute Abend weiter mit beschäftigen.

...wäre ja auch zu schön gewesen, wenn das auf Anhieb geklappt hätte...

Das Auskommentieren hatte ich bereits erledigt, für das Testen bzw. verbessern wäre ggf. wichtig zu wissen, wo es schief geht.

Anleitung:
- Das speech_recognition_alaxaName_firstrun bitte OHNE Parameter aufrufen, und zwar bei einem Device, das keinen Namen hat. Kommt das Dialogfeld zur Abfrage, ist das schon mal gut.

- Ob das Attribut zunächst richtig gesetzt war, kannst du dann nur feststellen, wenn du den Aufruf des 2. templates verhinderst, also Zeile 101 auskommentierst. Dann sollte es erst mal passen, und eigentlich glaube ich auch nicht, dass bis dahin irgendein Problem besteht.

Ab da dürfte dann der eigentlich spannende Teil beginnen... Wenn es nicht mit option klappt, müssen wir vermutlich den Perl-Code zur Abfrage, ob was doppelt vergeben ist nach par: (im secondrun) verlagern und ggf. dann dieses attrTemplate sich selbst am Ende aufrufen lassen. (das aber erst, wenn wir sicher sind, dass es keine Rekursion (oder wenigstens eine Abbruchmöglichkeit) gibt, wenn doppelte Namen vergeben wurden...).
(kopfkratz, ist nicht so einfach).

ZitatAnleitung:
- Das speech_recognition_alaxaName_firstrun bitte OHNE Parameter aufrufen, und zwar bei einem Device, das keinen Namen hat. Kommt das Dialogfeld zur Abfrage, ist das schon mal gut.

- Ob das Attribut zunächst richtig gesetzt war, kannst du dann nur feststellen, wenn du den Aufruf des 2. templates verhinderst, also Zeile 101 auskommentierst. Dann sollte es erst mal passen, und eigentlich glaube ich auch nicht, dass bis dahin irgendein Problem besteht.

Weiter bin ich noch nicht weil ich ewig gebraucht habe das es an option:TYPE=alexa liegt, das wohl keine 1 zurückgibt.

ZitatFalls nicht wahr ist, werden die darauffolgenden Zeilen des Template nicht ausgeführt.

Das Dialogfeld kommt aber trotzdem, nachdem man die Abfrage bestätigt hat wird das Attribut aber nicht gesetzt.

So klappts erstmal :):

name:speech_recognition_alexaName_firstrun
filter:NAME=speechrecognTesting
order:1000020a
desc:generic template to set speech recognition attribute alexaName, call e.g. with set xy attrTemplate speech_recognition_alexaName_firstrun
option:{my @devices=devspec2array("TYPE=(alexa)");;return 1 if $devices[0];;return 0}
par:ALEXANAME;Please enter alexaName;{ AttrVal("DEVICE","alexaname",undef) }
attr DEVICE alexaName ALEXANAME
#set DEVICE attrTemplate speech_recognition_alexaName_secondrun ALEXAISNAME=ALEXANAME

---

Im Template speech_recognition_type_thermostate muss thermostate in thermostate geändert werden.

---

In speech_recognition_gdt_and_mapping steht in der desc GENERICDEVTYPE=Security es ist doch aber ein contact ?

---

Wenn der spannende Teil vorbei ist, hab ich schon was neues im Kopf:

Stelle mir eine automatische Zuordnung in einen room vor, vorausgesetzt man hat in der config.json den Filter so eingestellt.
Hier an dem Beispiel wäre das AlexaRoom (Standard ist aber seit dem Connector alexaName=..*)

{   "alexa": {
       "name": "Alexa TEST",
       "keyFile": "./key.pem",
       "certFile": "./cert.pem",
       "applicationId": "amzn1.ask.skill.xxxxxxxxxxxxxxxxxxxxxxxxxxxx",
       "oauthClientID": "amzn1.application-oa2-client.xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
   },
   "connections": [
       {
           "name": "FHEM",
           "server": "192.168.0.xxx.xxx",
           "auth": {"user": "fhemuser", "pass": "fhempassword"},
           "ssl": true,
           "port": "8083",
           "filter": "room=AlexaRoom"
       }
   ]
}

Denke hab mir dazu mittlerweile fast alles angeeignet/ das Verständnis dazu entwickelt, das selbst umzusetzen.

Moin,

Zitat von: TomLee am 07 März 2020, 03:40:46Weiter bin ich noch nicht weil ich ewig gebraucht habe das es an

Code Auswählen Erweitern

option:TYPE=alexa liegt, das wohl keine 1 zurückgibt.

Aua. Ich hatte mich da an Rudi's Beschreibung orientiert, danach hätte option wie prereq funktionieren sollen und das erfordert genau ein Gerät, das einer devspec entspricht. Hast du zufällig zwei alexa-Instanzen?
(Ist aber egal, wir machen das auf dem vorgeschlagenen Weg bzw. in der etwas verkürzten Variante unten...).

ZitatDas Dialogfeld kommt aber trotzdem, nachdem man die Abfrage bestätigt hat wird das Attribut aber nicht gesetzt.

Das hatte ich fast vermutet, es werden wohl alle par-Anweisungen zuerst abgearbeitet. Ist der Grund gewesen, warum das auf mehrere Stufen verteilt ist...
(Nur leider nicht mehr im Fokus, als ich die Anleitung geschrieben habe, sorry for inconvenience!)

ZitatSo klappts erstmal :) :

Sehr schön!

Aktualisiertes "Doppel" s.u..
Jetzt könnte es sogar klappen, wenn das zweite template wieder das erste aufruft: Da sollte dann das Attribut ja gesetzt sein und mit par ermittelt werden (über den nicht parametrierten Aufruf ohne  ALEXANAME=xy). Das Attribut wird erneut gesetzt, der aktuelle Wert an 2. übergeben, das prüft dann wieder, ob es (noch) doppelt ist...
Bitte auch nochmal kritisch durchdenken und dann testweise die letzte Zeile aktivieren?

Zitat

---

Im Template speech_recognition_type_thermostate muss thermostate in thermostate geändert werden.

---

In speech_recognition_gdt_and_mapping steht in der desc GENERICDEVTYPE=Security es ist doch aber ein contact ?

---

Teil 1 habe ich nicht kapiert, Teil 2 kommt mit dem nächsten update (die anderen checke ich ggf. auch mit ein, aber erst, wenn ich "sowieso" was habe; sonst würde ich gerne das komplette Paket "scharf schalten", wenn wir soweit sind...)

Zitat
Wenn der spannende Teil vorbei ist, hab ich schon was neues im Kopf:

Stelle mir eine automatische Zuordnung in einen room vor, vorausgesetzt man hat in der config.json den Filter so eingestellt.

Sicher, dass man das braucht? Wenn für alexa der alexaName zwischenzeitlich DAS Kriterium ist, sollte man jetzt nicht hergehen, und irgendwelche alten/überholten Voraussetzungen auch noch supporten.
Anders gesagt: Wer die alte Implementierung nutzt, weiß was er tut bzw. noch einstellen muß, für die Neuen ist es nicht erforderlich. Wer als "alter" die neuen features nutzen will, muß halt ggf. "in den sauren Apfel beißen" und ein update machen...

Also bitte KISS halten, mMn. ist das schon eine sehr komfortable Lösung, die wir hier anbieten (können, thx @Rudi!).

So, noch der letzte Stand zu den beiden alexa-spezifischen templates (die option-Umstellung mache ich bei den anderen selbstredend auch, zumindest, soweit es dann irgendwann auch zweckmäßig ist...)
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;{ AttrVal("DEVICE","alexaName",undef) }
attr DEVICE alexaName ALEXANAME
set DEVICE attrTemplate speech_recognition_alaxaName_secondrun ALEXAISNAME=ALEXANAME

name:speech_recognition_alaxaName_secondrun
filter:NAME=speechrecognTesting
order:1000020b
desc:generic template to doublecheck alexaName attribute setting to avoid doubletes , call e.g. with set xy attrTemplate speech_recognition_alaxaName_secondrun ALEXAISNAME=myAlexaName
option:{my @devices=devspec2array("TYPE=(alexa)");; $devices[0] ? return 1 : return 0}
par:ALEXAISNAME;Please enter alexaName;{ AttrVal("DEVICE","alexaName",undef) }
option:{my @devices=devspec2array("alexaName=ALEXAISNAME");; $devices[1] ? return 1 : return 0}
par:ALEXANAME;Please enter alexaName (you may be asked multiple times to avoid already existing names);{undef) }
attr DEVICE alexaName ALEXANAME
option:{my @devices=devspec2array("TYPE=(alexa)");; $devices[0] ? return 1 : return 0}
#set DEVICE attrTemplate speech_recognition_alaxaName_firstrun

komme nicht weiter.

in name:speech_recognition_alaxaName_firstrun das {my @devices=devspec2array("TYPE=(alexa)");; $devices[0] ? return 1 : return 0} gibt doch entweder nichts oder alexa zurück, wenn nichts dann gib 0 sonst 1 zurück, ist doch richtig oder ?


in name:speech_recognition_alaxaName_secondrun mit option:{my @devices=devspec2array("alexaName=ALEXAISNAME");; $devices[1] ? return 1 : return 0} steht immer (auch wenn kein zweiter alexaName vergeben wurde) in jedem Skalar irgendwas und wird nie "unwahr"

Ist das eine praktisch erprobte Frage oder eine theoretische?

Nr. prüft nach meinem Verständnis, ob es (mind.) ein zweites Element in dem Array gibt, oder nur das eine bzw. keins (keins dürfte aber nicht sein, da wir das ja vorher festlegen, aber wenn nicht vorhanden wäre es auch egal).

Wenn das Probleme macht: "defined $devices[1]" statt nur $devices[1]?

Oder übersehe ich was?

Praxiserprobt ist das dieser Zweig immer wieder aufgerufen wird, egal was für einen Namen man wählt.

option:{my @devices=devspec2array("alexaName=ALEXAISNAME");; $devices[1] ? return 1 : return 0}
par:ALEXANAME;Please enter alexaName (you may be asked multiple times to avoid already existing names);{ (undef) }

Vergeben wird er aber immer, das sieht man wenn man das darauf folgende Dialogfeld abbricht, dann aber erst nach Aktualisierung der Seite.

muß ich mal drüber nachdenken, für heute ist mir das vermutlich zu hoch, bin grad an was anderem...

Im Template speech_recognition_type_thermostate muss thermostate in thermostat geändert werden.

---

Mir mag es nicht gelingen wie du dir das vorgestellt hast.

Darum bin ich davon ab und hätte einen anderen Vorschlag :P

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 (you may be asked multiple times to avoid already existing names);{ AttrVal("DEVICE","alexaName",undef) }
attr DEVICE alexaName ALEXANAME
set DEVICE attrTemplate speech_recognition_alaxaName_secondrun ALEXAISNAME=ALEXANAME

name:speech_recognition_alaxaName_secondrun
filter:NAME=speechrecognTesting
order:1000020b
desc:generic template to doublecheck alexaName attribute setting to avoid doubletes , call e.g. with set xy attrTemplate speech_recognition_alaxaName_secondrun ALEXAISNAME=myAlexaName
option:{my @devices=devspec2array("TYPE=(alexa)");; $devices[0] ? return 1 : return 0}
par:ALEXAISNAME;Please enter alexaName;{ AttrVal("DEVICE","alexaName",undef) }
option:{my @devices=devspec2array("alexaName=ALEXAISNAME");; $devices[1] ? return 1 : return 0}
deleteattr DEVICE alexaName
set DEVICE attrTemplate speech_recognition_alaxaName_firstrun

Wie man das jetzt aber in ein Template bekommt ist mir weiterhin unklar, weil immer wenn zweimal par angegeben wird diese zwei dann auch im Dialogfeld abgefragt werden, dort wollen wir (ich) ja aber nur eine.

Der Vorschlag klingt plausibel, manchmal sieht man den Wald vor lauter Bäumen nicht...

Es wird aus dem genannten Grund nicht gehen, die par: werden eben vorab abgearbeitet, aber das macht m.E. nichts, wenn man es verteilen muß. Sooo komplex ist es ja nun auch wieder nicht.
In meiner ersten Konzeptfassung hatte ich sogar einen "thirdrun" -
und genau in diese Richtung habe ich es eben noch umgebaut, damit man unterschiedliche Dialogfelder sieht.

"thermostat" ist jetzt hoffentlich auch korrekt.

Habs ausprobiert klappt.

Zitatdamit man unterschiedliche Dialogfelder sieht

Verstehe ich und find ich auch gut, aber ob man das wirklich braucht hier einen Unterschied zu machen ?
Der Endanwender weiß doch nix davon das es eigentlich zwei Dialogfelder gibt, es reicht doch eines wie in meinem Vorschlag, es steht halt  immer da das man mehrfach gefragt werden kann, ist doch nicht schlimm.

Zitatpar:ALEXANAME;Please enter alexaName (the one provided last time seem to exist already);{undef) }

Probierst du dass denn nicht, hier ist schon wieder die Klammer nach undef zuviel.

Nein, schlimm ist es nicht, wenn man ein "Einheitsdialogfeld" hat...

Meine Erfahrung mit diesen Themen ist allerdings tendenziell die, dass die User nicht sooo gut mit Mehrdeutigkeiten umgehen können und häufig schon keine Idee haben, was gemeint sein könnte, wenn mal eine Rückfrage kommt. Wir haben das ja mit den Topic-Tree-Abfragen in vielen Fällen bereits erlebt, von daher bin ich der Ansicht, dass es hier besser ist, unterschiedliche Dialogfelder zu haben, schon alleine aus dem Grund, dass wir bei eventuellen Fragen dazu rückfragen können, welche "Ebene" eigentlich das Problem bereitet.

Was den Typo angeht: Ist zugegebenermaßen ein "doofer" Fehler, aber ich kann für das ganze entweder aufwändig Testszenarien bauen, oder darauf vertrauen dass mir schon jemand rückmeldet, wo ggf. noch Fehler sind; die attrTemplate haben ja zum Glück keinen direkten Einfluß auf das laufende System. Sonst würde ich etwas anders vorgehen (bzw. mache das bei den Modulen auch, indem ich Testversionen bereitstelle).

Hier sind (waren?) wir ja erst mal noch "unter uns".

Btw.: Wenn das jetzt paßt, kann ich die alexaName-templates dann auch in die anderen einbinden zum Aufruf im alexa-Zweig, oder spricht was dagegen?

ZitatBtw.: Wenn das jetzt paßt, kann ich die alexaName-templates dann auch in die anderen einbinden zum Aufruf im alexa-Zweig, oder spricht was dagegen?

Ich fänds super.

Done!  :)

An der Stelle mal (auch im Namen der namenlosen User, die davon profitieren!):
Vielen Dank für deine Geduld und tatkräftige Unterstützung!!!

Hab auf auf zwei Systemen ein update gemacht, ich denke es ist alles wie vorgesehen

Finde das (für den Anfang) genial.

Was dann aktuell fehlt ist, dass das auch an prominenter Stelle steht -> Wiki (ich bin der falsche dazu) 

ZitatmMn. ist das schon eine sehr komfortable Lösung, die wir hier anbieten

Meine Gedanken dazu:

alexaName als filter find ich sch...(auch wenn ich es jetzt so nutze), Raumbezogen find ich übersichtlicher, vorallem für Einsteiger.
Bei homebridge-fhem ist der Raum (seit Anfang an?) default, keine Ahnung warum das mit dem Connector geändert wurde, vielleicht kann man sich ja da auf einen Standard einigen, wie das mit ON/OFF und on/off eigentlich auch angedacht ist.
Hilfreich (für die Templates) wäre dann, nach meinem Verständnis, das es einen "empfohlenem" Standard-Pfad (ich weiß nicht obs schon so ist) der jeweiligen config.json und dem "empfohlenem" Syntax darin gibt, das man mit den Templates, im Falle das, Zugriff hat.

Das wäre in meinen Augen die Grundlage für die vielen kommenden homebridgemappings die in Zukunft folgen werden.

Hmm, mal meine noch unausgegorenen Gedanken dazu:

- Wir sind auf einem Stand, der gut vorzeigbar ist. Ob für andere Zweige wie alexa (habe neulich was mit siriRoom-Attribut gesehen) weitere Attribute in ähnlicher Weise zu setzen wären: k.A.... (Genauso wie zur Frage, ob jetzt nur alexaName sinnvoll ist oder auch (?) alexaRoom).
Meine Erwartung ist die, dass da einige User feedback/Anregungen geben werden, die gerne sowas auch mittesten/gleich integrieren.

Nach meinem Eindruck ist (v.a.) justme1968 (und ggf. weitere Maintainer rund um die sr-Anbindungen) im Hintergrund dabei, das möglichst so zu gestalten, dass man mit sehr wenigen Attributen auskommt. Meine Meinung ist die, dass man per attrTemplate die Attribute setzen sollte, die entweder notwendig sind oder zumindest empfehlenswert, wer was spezielles haben will, sollte das "von Hand" machen.

Dem Gefühl nach liegt "alexaRoom" da irgendwo dazwischen. Vielleicht wäre es eine Option, in den attrTemplates einen "Schalter" abzufragen, anhand dem dann entschieden wird, ob auch alexaRoom abgefragt werden soll. Das könnte man z.B. anhand eines Attributs am Alexa-Device entscheiden, müßte dann aber damit leben, dass die Dialogfelder nacheinander abgefragt werden, sonst wird es eventuell (?) zu kompliziert und/oder wir benötigen weitere Funktionalität in AttrTemplate.pm.

M.E. wäre die Frage im Development-Bereich besser aufgehoben. Vielleicht magst du einen "Tester"-Status beantragen? Dann solltest du auch dort posten können und wir könnten diese Fragen am "richtigen" Ort diskutieren?

(Btw.: der Thread hier gehört eigentlich auch entweder nach Development oder nach Spracherkennung, diese templates sind generisch - und z.B. auch bereits bei MAX mit verfügbar/eingebunden :) ).

- MMn. wäre der nächste Schritt, diesen generischen Mechanismus in noch mehr Modulen bereitzustellen, also zunächst im Development-Bereich "Werbung" zu machen. Ich bin da noch etwas zurückhaltend, weil insbesondere zap grade eher in der HMCCU.*-4.4 Entwicklung stark engagiert ist und sich eventuell auch an den Client-Geräten aus diesem Grund das eine oder andere ändern wird, was dann auch wieder Auswirkungen auf die dortigen attrTemplates haben wird.
Will sagen: die Querbezüge sind vielfältig, und es wäre evtl. wünschenswert, wenn sich (jeweils!) jemand anbieten würde, sich um attrTemplate-"Maintainance"  für andere "große" Module (insbesondere: HMCCU.*, ZWave, evtl. CUL_HM) (mit) zu kümmern (ich mache das nicht, supporte aber wie immer gerne, damit das "ans fliegen kommt"...)

- Das Wiki wird vor diesem Hintergrund vermutlich mehrstufig zu aktualisieren sein:
Erst mal ein paar Hinweise, dass ggf. je nach individueller Installation mir Rückfragen zu rechnen ist (zu AttrTemplate allgemein bzw. auch kurz in den "Praxisbeispielen"). Das pflege ich demnächst ein.
Die attrTemplate "solo" anzuwenden ist zwar möglich, aber da es (derzeit) nur um max. drei Attribute geht, stellt sich die Frage, ob das besonders "beworben" werden sollte - als "addon" von anderen Templates ist das natürlich was anderes, da gehört es zu einer vollständigen "Erst-Einrichtung".
Aber in dem Zusammenhang: Evtl. könnten wir die "filter:" so anpassen, dass diese attrTemplate (auch) dann in der ?-Liste/im dropdown sichtbar werden, wenn jemand z.B. "alexaName" oder alexaRoom" "genericDeviceType" gesetzt hat (sofern das betr. Modul AttrTemplate unterstützt)?

Sobald wir diese Fragen vollends geklärt haben, könnte man das dann auch näher erläutern, allerdings stellt sich die Frage, ob das dann noch Sinn macht, eben weil es intuitiv geht und ja auch immer mehr user wissen, wie es - zumindest der Spur nach - geht...?

Es gibt keinen siriRoom und auch alexaRoom hat nichts mit meinem Vorschlag gemein.
Das json-Beispiel von oben ist für jemanden der sich mit Spracherkennung noch nicht beschäftigt hat verwirrend, habs einfach aus dem Wiki kopiert.

Das Attribute alexaRoom ist hier irrelevant (wird nur für den Custom-Skill und für scenen benötigt), zufällig hies früher aber der default-Raumname AlexaRoom (im filter), alle Geräte die diesem Raum zugeordnet waren, wurden von Alexa gefunden. Heute ist der filter bei alexa aber alexaName=..*, alle Geräte denen ein alexaName vergeben wurde werden gefunden.

Beim siri-Modul ist der filter nach wie vor room=Homekit, alle Geräte die dem Raum zugeordnet sind werden erkannt.
Somit prädistiniert für ein Template weil man den vergebenen Raumnamen im filter aus der config auslesen und ins  Attribute room schreiben kann. Ohne Template macht man das so oder so dann von Hand.

Sorry, wenn ich da nicht immer folgen kann, wie gesagt: Hab's nicht im Einsatz und daher keinen wirklichen Schimmer, wie die Bausteinchen zusammengehören, welche Attribute gültig sind usw.; kann durchaus sein, dass da jemand irgendwo ein userattr gesetzt hatte oä...

Was "room=Homekit" angeht:
name:speech_recognition_type_switch
filter:NAME=speechrecognTesting
order:100001
desc:template to set speech recognition attributes for genericDeviceType switch
option:{my @devices=devspec2array("TYPE=(siri|alexa|gassistant)");;return 1 if $devices[0];;return 0}
attr DEVICE genericDeviceType switch
option:{my @devices=devspec2array("TYPE=siri");; $devices[0] ? return 1 : return 0}
par:NEWROOM;NEWROOM as set if Homekit is included, otherwise it will be added;{ my $old =  AttrVal("DEVICE","room",undef);; !defined $old ? 'Homekit' : $old =~ m,Homekit, ? $old : $old.',Homekit' }
attr DEVICE NEWROOM
option:{my @devices=devspec2array("TYPE=alexa");; $devices[0] ? return 1 : return 0}
set DEVICE attrTemplate speech_recognition_alaxaName_firstrun
option:TYPE=gassistantMagst du das testen?
Wenn das klappt, schalten wir die "option:TYPE=siri"-Zweige auch gleich zusätzlich in den weiteren templates mit scharf?

Nicht wirklich, du hast mich noch nicht verstanden, man kann ja auch einen anderen Namen wie Homekit in der config.json vergeben.

Ich möchte diesen vergebenen Namen auslesen  (https://regex101.com/r/GPQM6f/1) und dann ins Attribut schreiben.

Das Template hätt ich auch schon fertig, nur komm ich nicht drauf wie ich das mit der Schleife mache, bin ja kein Programmierer :

{ my @content = FileRead({ FileName => "/opt/fhem/.homebridge/config.json", ForceType => "file" });;my $sk=@content;; $sk =~ m,(filter....(....).([^"]*))/g $0}

Link korrigiert

Ah, und ich hatte mich schon gewundert, aus welchem Grund du so komplexen code suchst.

Vielleicht hilft das weiter (@cfg_Import_Helper_Devices wurde vorher initialisiert):
my ($err, @cfgDataAll) = FileRead({ FileName => $filename, ForceType => "file" });
  $hash->{CFG_FILE_LENGTH} = scalar(@cfgDataAll);
  if ($err){
    readingsSingleUpdate($hash, 'state', $err, 1);
    return $err;
  }
  @cfg_Import_Helper_Devices = grep {
      $_ =~ s/^(define|defmod)[ ]+([a-zA-Z0-9._]+)[ ]+.+/$2/g #no commented definitions
    } @cfgDataAll;

(Ist "geklaut" aus https://forum.fhem.de/index.php/topic,108593.msg1026841.html#msg1026841 (https://forum.fhem.de/index.php/topic,108593.msg1026841.html#msg1026841), das erste Array-Element aus @cfg_Import_Helper_Devices wäre in diesem Code das, was du hier suchst...).

Ergänzend:

- Man könnte in dem Fall auch JSON-Decoding machen (eher als allg. Hinweis, ist hier vermutlich viel zu komplex, siehe z.B. https://svn.fhem.de/trac/browser/trunk/fhem/FHEM/98_WeekdayTimer.pm#L542 ff.)
- Kann man kein Internal auslesen? (Ich habe aber zumindest auf die Schnelle in siri.pm nichts in die Richtung gefunden, aber vielleicht wäre ein List aufschlussreich).

Is mir erstmal wieder zu hoch, aber auch erst später wieder Zeit.

Auf die Schnelle hab ich mir sowas zusammengereimt:
{ my @content = FileRead({ FileName => "/opt/fhem/.homebridge/config.json", ForceType => "file" });;my @content1 = grep {$_ =~ m/(filter....(....).([^"]*))$0/g}@content}

Mit dem Siri-Device bist du denk ich irgendwie auf dem falschen Dampfer, zeig ich dir aber:

Internals:
   FUUID      5cb3c819-f33f-78f5-271c-bc9309fe47b8dfb4
   NAME       Siri
   NR         113
   STATE      active
   TYPE       siri
   homebridge-fhem version 0.5.13
Attributes:
   group      Apple
   room       Sprachsteuerung

...harte Nuss, das list sieht aus wie der siri-code das auch vermuten lies...

Ungetestet:
name:speech_recognition_type_switch
filter:NAME=speechrecognTesting
order:100001
desc:template to set speech recognition attributes for genericDeviceType switch
option:{my @devices=devspec2array("TYPE=(siri|alexa|gassistant)");;return 1 if $devices[0];;return 0}
attr DEVICE genericDeviceType switch
option:{my @devices=devspec2array("TYPE=siri");; $devices[0] ? return 1 : return 0}
par:NEWROOM;NEWROOM as set if value in homebridge-config is included, otherwise it will be added;{ my ($err,@hbconfig) = FileRead({ FileName => ".homebridge/config.json", ForceType => "file" });;my @rooms = grep { $_ =~ s/.*filter.+room=([a-zA-Z0-9_.\->]+).*/$1/g } @hbconfig;; $err = $rooms[0] unless $err;; my $old =  AttrVal("DEVICE","room",undef);; !defined $old ? $err : $old =~ m,$err, ? $old : $old.",$err" }
attr DEVICE NEWROOM
option:{my @devices=devspec2array("TYPE=alexa");; $devices[0] ? return 1 : return 0}
set DEVICE attrTemplate speech_recognition_alaxaName_firstrun
option:TYPE=gassistant

Unklar ist mir, was passiert, wenn es diese File nicht gibt; müßte eigentlich abgefangen sein, aber da besteht ein nicht unerhebliches Risiko, dass FHEM direkt abstirbt.

Geändert sind:
- die Regex, kann aber sein, dass das jetzt zu viel ausschließt;- versucht, eine Fehlerfallerkennung einzubauen, falls die file nicht da/nicht lesbar ist;
- das Array-Element wird (hoffentlich) direkt verwendet.

---

Was etwas anderes, betreffend nur mehrkanalige Devices:
Bisher hatten wir eine Art "Einheitslösung", also im ersten Kanal alles festgelegt, auf die weiteren Kanäle per copy übertragen. Das ist für den alexaName natürlich nicht zielführend, der soll ja grade individuell werden.
Solange das wirklich nur alexa betrifft, ist es egal, aber wenn das noch weitere Zweige betreffen kann, wäre es vermutlich einfacher, die Struktur etwas umzubauen: den funktionalen Teil von der Namensvergabe trennen und über zwei attrTemplate auch getrennt aufrufen. Dann würde man den funktionalen Teil (also das, was es im file bis vorgestern gab) direkt aufrufen&per copy mit übertragen, und dann für jeden Kanal getrennt die Namens- und Raumvergabe anschubsen (bzw. bei siri macht das offenkundig Sinn, den Raum mit in den funktionalen Teil mit aufzunehmen, es gibt ja nur den einen).

Anstoß für die Überlegung war dieser template-Vorschlag: https://forum.fhem.de/index.php/topic,94495.msg1031089.html#msg1031089 (https://forum.fhem.de/index.php/topic,94495.msg1031089.html#msg1031089).

(Hoffe, du kannst das verstehen, ist einigermaßen absrakt...

Bin noch unterwegs, testen musst ich aber  :P.

Error checking template regexp: Missing right curly or square bracket at (eval 2290) line 1, at end of line
syntax error at (eval 2290) line 1, at EOF

Ich sehe sie nicht.

Kann auch auf den Code starren und finde keine fehlende Klammer;

hängt evtl. irgedwie mit den Abfragen zusammen, vermutlich wäre stacktrace da aufschlußreich?

Ich habe die erwaehnte Fehlermeldung mit Parametername und Perl-Code erweitert, weiterhin ein attrTemplate Befehl checkPar hinzugefuegt, was die perl-Expressions in allen par Zeilen ausfuehrt, und bei Syntax-Fehler sich meldet.

checkPar gibt mit perl 5.30 Folgendes aus:
tasmota_prefix_clearing_and_reboot:READINGLISTCLEARED:Can't modify non-lvalue subroutine call of &main::AttrVal in substitution (s///) at (eval 288) line 1, near "s/, '[^_]+[_]'/, ''/g,"
syntax error at (eval 288) line 1, near ", ?"


 :o :o :o
Schock schwere Not, was will mir denn das sagen...?!?

(Nun, was dieses template  tasmota_prefix_clearing_and_reboot angeht wohl: "Maintainer, wirf es raus" - ich habe keine Ahnung mehr, für was das mal gut war, stammt noch aus den Tasmota-Anfängen, und ich bezweifle, dass das heute noch jemand braucht bzw. irgendwann mal jemand genutzt hatte...)
Aber einen Zusammenhang mit dem anderen Vorschlag bekomme ich auf die Schnelle nicht hin... Mal schauen, ob ich irgendwo Erleuchtung finde?

ZitatSchock schwere Not, was will mir denn das sagen...?!?

Ich habe eine Moeglichkeit eingebaut, Fehler, die in letzten Tagen scheinbar aufgetaucht sind, einfacher zu pruefen.
Bin aber langsam nicht mehr sicher, ob das gebraucht wird :)

Hmm, mag ich nicht abschließend beurteilen, aber grundsätzlich finde ich das Abfangen von Fehlern eine gute Sache!

Diese Art der Auswertung hier ist aber sowieso eine sehr spezielle Ecke (um nicht zu sagen: ziemlich abgefahren...!). Vermutlich wäre es besser, einfach justme1968 zu fragen, ob er nicht in siri.pm eine passende Funktion einbauen kann, die schlicht und ergreifend den neuen Attributinhalt "mundgerecht" und vollständig zurückliefert? (Ersatzweise: ein entsprechendes Internal bereitstellt).

((Noch ersatzweiser: den Autor von AttrTemplate bitten, was passendes einzubauen... Aber das wäre echt eher eine Notlösung!))

Tut mir Leid, das war das Resultat davon wenn man am Tablet Code kopiert, par war auf drei Zeilen aufgeteilt.

---

Trotzdem bekomme ich jetzt diese Meldung:

speechrecognTesting: unknown attribute Homekit. Type 'attr speechrecognTesting ?' for a detailed list.
<html><input type='hidden' value='set speechrecognTesting attrTemplate speech_recognition_alaxaName_firstrun'><p>Specify the unknown parameters for speech_recognition_alaxaName_firstrun:</p><table class='block wide'><tr><td>Please enter alexaName</td><td><input type='text' name='ALEXANAME' size='20'></td></tr></table><script>
          setTimeout(function(){
            $("#FW_okDialog input[type=radio]").first().prop("checked",true);
            $("#FW_okDialog").parent().find("button").css("display","block");
            $("#FW_okDialog").parent().find(".ui-dialog-buttonpane button")
            .unbind("click").click(function(){
              var cmd;
              $("#FW_okDialog input").each(function(){
                var t=$(this).attr("type");
                if(t=="hidden") cmd = $(this).val();
                if(t=="text")  cmd +=" "+$(this).attr("name")+"="+$(this).val();
                if(t=="radio") cmd +=" "+$(this).val()+"="+
                                          ($(this).prop("checked") ? 1:0);
              });
              FW_cmd(FW_root+"?cmd="+encodeURIComponent(cmd)+"&XHR=1",
              function(resp){
                if(resp) {
                  if(!resp.match(/^<html>[\s\S]*<\/html>/))
                    resp = "<pre>"+resp+"</pre>";
                  return FW_okDialog(resp);
                }
                location.reload()
              });
              $("#FW_okDialog").remove();
            })}, 100);
         </script>
       </html>

---

Ich hatte mir noch überlegt, zuvor erstmal zu schauen ob der filter überhaupt auf room steht:
option:{my @content = { my @content = FileRead({ FileName => "/opt/fhem/.homebridge/config.json", ForceType => "file" });; grep (/^room$=/,@content) ? 1 : 0 }

Also mehr oder weniger auch übertragbar auf Alexa, falls der Filter dort auf room eingestellt ist.

---

Der Vergabe des room Attributs sollte optional sein, nicht jedes Gerät mag man siri(/alexa) bekannt machen, es gibt doch auch Radio Buttons  :P?

---

Zitat
Was etwas anderes, betreffend nur mehrkanalige Devices:...

Alles richtig erkannt, genauso sollte umgebaut werden

Betreffend des siri-Raums: hab's mal im Dev-Bereich in den allg. Thread dazu eingekippt; denke justme1968 wird dann vermutlich auch zu alexa was sagen können.

Vorneweg mal: seit eben ist ein größeres update im svn.
- Damit sollten die paar "wichtigen" in allen Devices sichtbar/auswählbar werden, die genericDeviceType gesetzt haben => einfacherer Zugang zu den zusätzlichen Optionen, wenn man alexaName usw. nachträglich noch setzen will;
(Hoffnung dabei: Wenn mehr Leute wissen/nebenbei sehen, dass man den ganzen (Teil-) Prozess einfach via attrTemplate anschubsen kann (vorausgesetzt, das Modul unterstützt das), dann wird es ggf. auch zu "Nachrüstaktionen" genutzt...).
- Die Umorganisation in Richtung der Trennung der reinen "Namensattribute" von den funktionalen, typ-abhängigen Attributen ist "präventiv" umgesetzt.

Wie immer: Bitte melden, falls ich mal wieder was übersehen haben sollte...

---

Was den Rest angeht:
Muß ich erst mal drüber nachdenken...
Grundsätzlich ist mir das "optionale Zeug" suspekt, und ich fände es besser, wenn wir es auf irgendwie auf ein Dialogfeld (am besten für alle sr-Lösungen gemeinsam, notfalls aber) pro sr-Lösung "eingedampft" bekämen. Alles andre empfinde ich im Moment als nervtötend (gut, vielleicht nicht so nervtötend, wie alle optionalen, aber gewünschten Attribute manuell zu vergeben?). Kann aber sein, dass sich der Nebel doch irgendwie lichtet und es einfacher ist wie gedacht - hätte ja schließlich vor einigen Monaten auch noch nicht geglaubt, dass wir heute den sr-Teil halbwegs akzeptabel "im Griff" haben würden... ;D
(Und wie immer: gemacht wird, was gewünscht ist, solange es irgendwie plausibel ist und wartbar bleibt...)

(@TomLee: irgendwo gab's vor einigen Tagen mal Ansätze für diverse options-Vorauswahlen; war in dem "IKEA"-Lampen-thread(?); vielleicht kannst du daraus was recyceln...?)

Zitatattr DEVICE room NEWROOM

Stand doch in der Fehlermeldung, ich wollte es nicht sehen

Ich wette das bei einer Umfrage 95% der User den filter niemals angerührt haben und werden.

Und die die das tun werden nur in den seltensten Fällen ein Template für ihre Konfiguration wählen, sondern von Hand anpassen.

Na ja, wenn 5% ihren Unmut kundtun, ist das nicht lustig, und eigentlich reicht es, wenn ein kleiner Teil der 5% sich berechtigterweise beklagen...

Und 100 Devices (Obergrenze?) sind auch schnell erreicht=> mit der Verbreitung wird das Problem ggf. erst entstehen...

Schnelle (müde) Tendenz: Wenn, sollten wir es so anbieten, dass man es aktiv einschalten muß, und es muß auch dann funktionieren, wenn es zwar eine config-file gibt, aber einen anderen Filter (vermute: FHEM schmiert ab, wenn wir das nicht auch noch abfangen).

Ansonsten scheint mein Code an der wichtigen Stelle - bis auf das unbekannte Detail, dass es andere Filter geben kann - gepaßt zu haben. Sehr schön!
Der Pfad für das Lesen der Datei sollte m.E. übrigens nicht absolut gesetzt werden, auch wenn 99% auf Linux sind und von diesen 99% 98% FHEM in /opt laufen haben...

(Aber auch hier sieht man wieder, dass es wichtig ist, doofe Fehler abzufangen, sorry für das fehlende "room"...)

Zur derzeitigen Implemetierung der sr-Templates:

Nur weil es eine alexa-Definition gibt, muss man zwangsläufig neu definierten Geräten die sr-typischen Attribute vergeben. Im Falle Alexa macht man ja mit der Vergabe des alexaName-Attribute (filter steht per default ja auf alexaName) das Gerät dem Sprachassistenten bekannt, das ist aber nicht bei jedem Gerät gewollt.

Aktuell wird aber jedem Gerät auf dass ein MQTT2_Template angewendet wird das Attribut genericDevicetype, alexaName (siriname) oder auch homebridgeMapping vergeben.

Der Aufruf eines speech_recognition_type_xxx Templates sollte optional sein oder bei Bedarf dann eben manuell aufgerufen werden.
(mit Optionsfeldern hab ich schon ein wenig gespielt aber nicht weitergekommen, Auswahlfelder wären hilfreich kann ich mir vorstellen)

---

Generell klappt es aber mMn. wie du dir das vorgestellt hattest, ausser bei den split-Templates ist noch der Wurm drin, komme aber nicht drauf.

Danke für die Rückmeldung, dann müssen wir da wohl nochmal ran:

Hatte aber vorher noch verstanden:
- genericDeviceType ist in jedem Fall gewollt, mapping macht auch Sinn (das "kennen" wir beim Aufruf besser wie der user, oder nicht?);
- (nur) nicht optimal ist, dass die Namensvergabe grade zwangsweise erfolgt, aber optional sein müßte
Ist das jetzt anders oder genau so wie geschildert?

Wenn nur der Name das Problem darstellt, bleibt die Frage, ob der User zwei Aufrufe machen soll, oder ob wir  dem User über einen Aufrufparameter  ermöglichen wollen, das gleich mitzuerledigen. Tendiere zu zwei Aufrufe= zwei Templates?
Das würde vermutlich auch die ganze Struktur deutlich vereinfachen?

Wg. der Funktionalität: Es sollte so sein, dass man das template "speech_recognition_general_naming_master_template" ja sieht, sobald der genericDeviceType gesetzt ist. Das paßt, oder?

(Dann hat sich das mit den mehrkanaligen vermutlich auch relativ schnell erledigt, wenn wir das mit den Namen weg haben).

ZitatHatte aber vorher noch verstanden:
- genericDeviceType ist in jedem Fall gewollt, mapping macht auch Sinn (das "kennen" wir beim Aufruf besser wie der user, oder nicht?);
- (nur) nicht optimal ist, dass die Namensvergabe grade zwangsweise erfolgt, aber optional sein müßte
Ist das jetzt anders oder genau so wie geschildert?

Alle bisher besprochenen sr-Attribute sind gewünscht, aber doch nur wenn ich ein Gerät über den Sprachassistenten steuern möchte, sonst sind es doch einfach nur unnötig gesetzte Attribute.
Dann ist es so das man das setzten der genericDeviceType und homebridgemapping-Attribute abhängig vom
alexaName  machen sollte und nicht wie aktuell andersrum.
Der alexaName ist ein muss, unabhängig wie der filter gesetzt ist. Und dieser sollte dann Indikator für das setzen der anderen Attribute sein, genericDeviceType ist nicht immer ein muss (das Gerät wird bei passenden Readings auch so erkannt), setzen wir in den Templates aber generell und homebridgeMapping wird benötigt um sich Readings passend zu biegen, also eigentlich auch kein muss nur bei Bedarf.
Mir war nicht klar das du es so einbaust das nun jedem Gerät auf das ein Template angewendet wird, automatisch immer auch die sr-Attribute zugewiesen werden, das ist sicher nicht gewünscht.

ZitatWenn nur der Name das Problem darstellt, bleibt die Frage, ob der User zwei Aufrufe machen soll, oder ob wir  dem User über einen Aufrufparameter  ermöglichen wollen, das gleich mitzuerledigen. Tendiere zu zwei Aufrufe= zwei Templates?
Das würde vermutlich auch die ganze Struktur deutlich vereinfachen?

Meiner Meinung nach über einen Aufrufparameter der den alexaName abfrägt, ist der gewünscht werden die anderen Attribute automatisch gesetzt.

ZitatWg. der Funktionalität: Es sollte so sein, dass man das template "speech_recognition_general_naming_master_template" ja sieht, sobald der genericDeviceType gesetzt ist. Das paßt, oder?

Schon, aktuell wird doch aber jedem Gerät ein genericDeviceType und alexaName vergeben sobald ich ein MQTT2-Template darauf anwende, also brauch ich auch kein speech_recognition_general_naming_master_template  :o

Rede ja hier mit jemandem der auf diesem Gebiet blind und taub ist, muss mich korrigieren:

alexaName ist kein muss, wird dieser nicht vergeben wird der alias genommen  ::)

Für die Templates kann man es aber so machen wie oben beschrieben.

Hmmm, muß mal drüber nachdenken...

Das Problem ist folgendes: In dem template, das der user zur Grundkonfiguration auswählt, können "wir" noch wissen, was die speziellen Anforderungen des Geräts sind (255-bri oder 100-pct, z.B.). Trennt man das weg, ist es für den user sehr viel schwieriger, weil er dann die eigentliche Parametrierung kennen muß => fehleranfällig...

Daher finde ich es tendenziell an der Stelle naheliegender, diese Attribute mit zu setzen, selbst wenn sie erst mal "unnötig" sind.

Für mein Verständnis: Man kann also alles vorbereiten, aber "scharf" wird das ganze (auch für siri?) erst, wenn es den alexaName gibt? (Die Attribute setzen kann man eh' nur, wenn es eine sr gibt).

Die Idee, das ganze (per option?) so zu machen, dass man den angeben kann, finde ich eigentlich ganz chick, ich habe nur (noch?) keine Idee, wie man das ablauftechnisch sinnvoll gestalten kann; diese Abfrage müßte ja in dem ersten template drinstecken, was bedeutet, dass wir die ganze Struktur umbauen müßten(?). Unschön...

Wie gesagt, muß das mal überdenken...

Tendenziell werde ich aber wohl erst mal besser die Abfrage des Namens deaktivieren, oder?

---

Nachtrag, da wir parallel geschrieben haben: Wenn der alias oder alexaName das ganze scharf schaltet, muß wohl über ein späteres "option" abgefragt werden, ob die anderen Attribute gesetzt werden sollen?
Oder wir legen irgendeinen generellen "Kenner" fest, der bestimmt, ob die Attribute gesetzt werden sollen...?
(Da wäre es vermutlich sinnvoll, es gäbe eine zentrale Funktion, damit man das einfacher von überall her prüfen kann?).

Sehr blind und taub :(

ZitatTendenziell werde ich aber wohl erst mal besser die Abfrage des Namens deaktivieren, oder?

ja

ZitatNachtrag, da wir parallel geschrieben ...

scharf schalten tut es am Ende nur die devspec im filter (alexa und siri).
Wie gesagt wäre vorerst (wenn wir hier weiter spielen wollen) bei Alexa als "Kenner" der alexaName durchaus verwendbar, den vergeben 99,9 % aller User.

So, hoffe, die richtigen Schalter gefunden zu haben (=> svn)...

Zum Glück läuft jetzt vieles einfach zentral zusammen...

Jetzt werden weiter die zentralen Attribute (type+(teilw.) mapping) weiter (wie bisher/seit einiger Zeit schon) via attrTemplate vergeben. Wenn man das auch noch ausschalten wollte, müßten halt weiter oben auch noch ein paar Zeilen deaktiviert werden.

Zitat von: Beta-User am 15 März 2020, 17:14:15
- genericDeviceType ist in jedem Fall gewollt, mapping macht auch Sinn (das "kennen" wir beim Aufruf besser wie der user, oder nicht?);

Ich habe mal mit genericDeviceType bei meinen Mehrfach Steckdosenleisten experimentiert. Als Spracherkennung habe ich nur Alexa zur Verfügung.

Als genericDeviceType wären die Typen Outlet, Switch und Light im Angebot.

Outlet sprach mich am besten an. In der Alexa App werden die Steckdosen dann auch passend mit einem Stecker Symbol dargestellt. (freu...)

Bei weiterem rumklicken in der Alexa App kam ich auf die Detail Darstellung der gefundenen Geräte.
Zu meiner Überraschung bietet die Alexa App an den Typ von Outlet nach Light zu wechseln. (upps...)
Begründung laut Alexa App, wenn die Steckdose eine Lampe schaltet ist Light eine gute Wahl.
Spielt vielleicht eine Rolle bei der Bildung von Gruppen in der Alexa App.

Ob es eine Auswahl Möglichkeit in den Templates geben sollte lass ich mal offen, ich bin mir da selber nicht einig.

Mit freundlichem Gruß

joelinux

Zitat von: Beta-User am 15 März 2020, 17:14:15
- (nur) nicht optimal ist, dass die Namensvergabe grade zwangsweise erfolgt, aber optional sein müßte

Vielleicht sollte ich mich als Fan der Tasmota Funktion 'Hue Emulation' zu erkennen geben.
Ich nutze die Tasmota Hue Emulation extensiv weil es vor einiger Zeit nur den custom Alexa Skill gab. Der neue fhem-connector Skill ist deutlich weniger komplex einzurichten, kommt mir aber bei Tasmota noch etwas in die Quere.

Bei zigbee2mqtt ist mir fhem-connector sehr willkommen.

Aus meiner Sicht ist eine Vergabe von AlexaName optional, kann aber damit leben manuell einzugreifen und ungewollte AlexaNamen entfernen.

Mit freundlichem Gruß

joelinux

Hmm, alles noch etwas undurchsichtig. Im Moment habe ich den Eindruck, dass wir dem User die Möglichkeit eröffnen sollten, das Verhalten der templates an zentraler Stelle zu beeinflussen.

Kurz hatte ich darüber nachgedacht, ob es Sinn macht, zentralen Perl-Code bereitzustellen, der das dann abfragt, aber auch dabei bleibt die Frage: Woher sollte der die eigentlichen Informationen nehmen...?

Jetzt bin ich auf folgendes gekommen, weiß aber mal wieder noch nicht so recht, ob das eine gute Idee ist:
Der user könnte über ein Attribut an der jeweiligen Spracherkennung einen Satz von Parametern zur Übernahme durch attrTemplate vorhalten...?

Also beispielsweise:

attr <alexa-device> attrTemplate_params SETGENERICDEVICETYPE=1 ASKALEXANAME=1 DOWHATEVER1=0 DOWHATEVER2=1
attrTemplate_parms könnte man im Moment als userattr hinterlegen, aber es wäre sicher keine große Sache, das über die Module selbst anzubieten.

Dann sollte es mit der options:-Abfrage recht einfach möglich sein, (nur) die Teile einzufügen, die der user auch wirklich haben will und wir könnten im "Eingangsbereich" des jeweiligen Templates eine "allgemeine Vorauswahl" treffen (hier: SETGENERICDEVICETYPE=1 ASKALEXANAME=0).

Nachteil: das Attribut müßte der User bei jeder sr-Variante hinterlegen. Das könnte man ggf. dahingehend erweitern, dass man das (user-) Attribut an "global" hängt oder eine Art attrTemplate_parms_all zuläßt (?).

Meinungen dazu?

Müßten wir ggf. - bevor wir das umsetzen - auch mal an justme1968 adressieren, vielleicht hat er noch eine zündende Idee oder Hinweise, falls wir dazu bisher was übersehen haben.

ZitatKurz hatte ich darüber nachgedacht, ob es Sinn macht, zentralen Perl-Code bereitzustellen, der das dann abfragt, aber auch dabei bleibt die Frage: Woher sollte der die eigentlichen Informationen nehmen...?

Wenn ich das richtig verstehen sollte, dann hab ich dazu gestern ähnlich sinniert und an einen subType gedacht, der jedem Device beim anwenden eines "allgemeinen" Template zugewiesen wird.
Anhand von zentralem Perl-Code werden über den subType bei der Vergabe eines alexaName/siriName die entsprechenden Attribute zu genericDeviceType/homebridgeMapping abgefragt.

Hmm, das war eher "anders herum" gemeint:
- subType wie von dir vorgeschlagen müßte jeweils das Modul bereits als Attribut "kennen" oder man müßte es als userattr zulassen. Das dürfte verwirrend sein, weil der user am einzelnen Device schon (auf mehreren Stufen?) irgendwas festlegen müßte, was dann ggf. auch noch in Abstimmung zu bringen sein müßte mit "bekannten" subTypes (gibt es bei CUL_HM, z.b.).

- Tendenziell sollte der Ablauf möglichst automatisiert sein, also: User wählt _ein_ template aus, das richtet dann das Gerät vollständig ein, und zwar optimalerweise einschl. Sprachsteuerung, jedenfalls bis zu dem Punkt, den der User (optimalerweise: pro Sprachsteuerungsvariante) zentral irgendwo einstellt.
Beispiel:
1. "tasmota_basic" wird "solo" aufgerufen.
2. Das merkt, dass es nicht intern aufgerufen wurde => zentrales Sprachsteuerungs-attrTemplate wird aufgerufen (wenn  intern aufgerufen: kein Aufruf dieses Teils!).
3. Das zentrale sr-template checkt, ob es "irgendwo" (global, eine der drei TYPES) ein Attribut "attrTemplate_params" gibt? Wenn nein: Ende Gelände, wenn ja:
Ausführen der Teile, die der user für die jeweilige sr-Variante (nicht ab-) gewählt hat. Logik dabei: Erst sehen, ob es das Attribut für die jeweilige sr-Variante gibt, sonst global, wenn nein: diese Teile unkonfiguriert lassen bzw. z.B. nur den genericDeviceType festlegen?

So in der Reichtung halt...

Daneben gäbe es weiter die Option, den sr-Teil nachträglich aufzurufen (wie jetzt auch).

Ist das jetzt klarer? Oder übersehe ich was?

ZitatUser wählt _ein_ template aus, das richtet dann das Gerät vollständig ein, und zwar optimalerweise einschl. Sprachsteuerung, jedenfalls bis zu dem Punkt, den der User (optimalerweise: pro Sprachsteuerungsvariante) zentral irgendwo einstellt.

Das ist einfach nicht richtig. Nochmal, die sr-Attribute sollten mMn. nur gesetzt werden wenn ich das Gerät auch über eine der Sprachsteuerungsvarianten steuern möchte. Nur weil ich Alexa nutze vergeb ich doch nicht jedem Tempsensor mal vorab die sr-Attribute oder auch den Rollläden nicht.

Unabhängig vom gesetzten filter, ist es aber i.d.R. so wenn ich einen siriName oder alexaName vergebe dann auch die anderen Attribute gewünscht sind.

Warum nicht (wenn möglich) beim "solo" Template Aufruf nacheinander bis zu 3 Dialogfelder die den jeweiligen Namen abfragen, aufrufen? Jedes Dialogfeld kann mit Auswahl eines Optionsfeld auch keinen Namen (undef) übergeben. Wird nur ein Name vergeben, werden auch die genericDeviceType Attribute gesetzt.

Zitat von: TomLee am 18 März 2020, 14:50:20
die sr-Attribute sollten mMn. nur gesetzt werden wenn ich das Gerät auch über eine der Sprachsteuerungsvarianten steuern möchte.

Das generelle Setzen des Attribut genericDeviceType könnte zu einer ungewollten Veröffentlichung an den Alexa Skill führen.
Ich meine verstanden zu haben das der Alexa Skill ein vorhandenes alias Attribut nimmt falls kein alexaName vorhanden ist. 

Hmm, vielleicht sollten wir nochmal den allg. Ablauf ansehen?

Meine Meinung ist die, dass der User irgendwo zentral festlegen können sollte, was passieren soll. Vermutlich gibt es einige "Kategorien", wie User der Spur nach an so was rangehen. Die einen wollen...
- ...alles (ggf. per eigenem attrTemplate-Aufruf) selbst machen, oder (anderes Extrem)...
- alles gefragt werden, aber direkt aus dem einen attrTemplate raus?
- Der nächste vielleicht z.B. alles "schaltbare" direkt in die sr integrieren, aber z.B. Sensoren nicht...?

Sowas könnte man mMn. recht gut durch einen (oder mehrere) zentrale/n Schalter steuern, das wäre wohl auch nicht übermäßig kompliziert in der Umsetzung oder Handhabung für den User, er müßte nur irgendwie erfahren, wo er welche/n Schalter setzen kann, um den Gesamtablauf für alle attrTemplates zentral zu ändern.

Mein "Problem" mit einer Splittung in zwei Teile ist schlicht das, dass das 2. vom ersten nichts weiß, also insbesondere nicht, welcher genericDeviceType es ist - wenn ich es mit einem einkanaligen Tasmota zu tun habe, weiß ich dagegen schon, dass es ein switch wäre, wenn der User das Attribut denn "geschrieben" haben wollte...
Aber wenn dafür jemand eine Idee hat (?), ist es für mich auch ok, den Ablauf zu splitten.

---

Zitat von: joelinux am 18 März 2020, 15:24:39
Das generelle Setzen des Attribut genericDeviceType könnte zu einer ungewollten Veröffentlichung an den Alexa Skill führen.
Ich meine verstanden zu haben das der Alexa Skill ein vorhandenes alias Attribut nimmt falls kein alexaName vorhanden ist. 

Das spräche z.B. dafür, tatsächlich den genericDeviceType nur dann zu setzen, wenn der User bei seinem alexa-Device einen entsprechenden Marker gesetzt hat. Aber wenn er diesen Marker gesetzt hat, spricht mMn. auch wenig dagegen, das generell und gleich zu tun (und ihn per default für schaltbares Zeug auch gleich nach dem alexaName zu fragen, wenn er dieses feature nicht am gleichen Ort ausgeschaltet hat...?).

Ist denn jetzt klarer, wie ich mir das grundsätzlich vom Ablauf her vorstelle, oder soll ich den Aufwand treiben, bei Gelegenheit mal ein Beispiel/etwas Code zu liefern?

Ich plaediere fuer eine einfache Loesung, und alles "sinnvolle" zu setzen.
Attribute zu entfernen ist einfach, und sie werden vor dem Anwenden auch gezeigt.
Wen das Entfernen nervt, der soll seine eigene Variante von AttrTemplate anlegen.

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 ?

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.

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:

Zitat von: rudolfkoenig am 18 März 2020, 16:16:12
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":
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.

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.

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...

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

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

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 ;D
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:
Set a (new) alexaName, current value is: ALEXAISNAME
Leave alexaName attribute unchanged (or unset)
DELETE genericDeviceType attribute (or do not set it by attrTemplate)

Set a new alexaName
Leave alexaName attribute empty
Discard genericDeviceType attribute

 :) 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  ;D ...

(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...)

Zitat von: Beta-User am 19 März 2020, 17:21:37
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       

ZitatDie 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=..*"

Zitat von: TomLee am 20 März 2020, 16:35:15
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...). 

ZitatVielleicht 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"

Zitat von: TomLee am 20 März 2020, 16:35:15
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. 

@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

Zitaterschwerend 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.

Mit ...alaxa... war einfach nur der Schreibfehler in
speech_recognition_alaxa_specials
speech_recognition_request_alaxaName
gemeint.

OK, jetzt habe ich den Typo auch entdeckt ;D ::) .

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...

ZitatDas 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.

Ja, denke alles richtig erkannt. Keine Ahnung wie du das umsetzt aber wenn der genericDeviceType bereits durch die Vergabe eines alexaNamen (oder umgekehrt siriNamen) gesetzt wurde, braucht man genericDeviceType auch nicht für die nächste Namen-Abfrage vorhalten, ändert sich ja nix von sr-Variante zu sr-Variante, genericDeviceType ist bei beiden immer  gleich.

Na ja, der user hat es ja ggf. in jeder Stufe in der Hand, das genericDeviceAttribute zu löschen. Hat er alexa und siri und löscht bei alexa (1. Abfrage), dann macht siri keinen Sinn mehr, oder?
(usw.)

So sollte das passen:
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=alexa");; $devices[0] ? return 1 : return 0}
set DEVICE attrTemplate speech_recognition_alexa_specials
option:{my @devices=devspec2array("TYPE=siri");; $devices[0] ? AttrVal("DEVICE","genericDeviceType","none") eq "none" ? 0 : 1 : 0 }
set DEVICE attrTemplate speech_recognition_siri_specials
option:{my @devices=devspec2array("TYPE=gassistant");; $devices[0] ? return 1 : return 0}

#######
# alexa specials

name:speech_recognition_alexa_specials
filter:NAME=speechrecognTesting
order:1000020a
desc:generic template to set speech recognition attribute alexaName, call e.g. with set xy attrTemplate speech_recognition_alexa_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;{ undef }
par:RADIO_DoNotSetalexaName;Leave alexaName attribute empty;{ undef }
par:RADIO_Delete_gDT;Discard genericDeviceType attribute;{ undef }
option:{ RADIO_Delete_gDT }
deleteAttr DEVICE genericDeviceType
option:{ RADIO_DoNotSetalexaName }
option:{ RADIO_SETalexaNAME }
set DEVICE attrTemplate speech_recognition_request_alexaName

name:speech_recognition_request_alexaName
filter:NAME=speechrecognTesting
order:1000020b
desc:generic template to ask for alexaName attribute setting. Only intented for internal use by speech_recognition_request_alexaName
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

####
#siri specials

name:speech_recognition_siri_specials
filter:NAME=speechrecognTesting
order:1000021a
desc:generic template to set speech recognition attribute alexaName, call e.g. with set xy attrTemplate speech_recognition_siri_specials ALEXANAME=myAlexaName
option:{my @devices=devspec2array("TYPE=(siri)");; $devices[0] ? return 1 : return 0}
par:RADIO_SETsiriNAME;Set a new siriName;{ undef }
par:RADIO_DoNotSetsiriName;Leave siriName attribute empty;{ undef }
par:RADIO_Delete_gDT;Discard genericDeviceType attribute;{ undef }
option:{ RADIO_Delete_gDT }
deleteAttr DEVICE genericDeviceType
option:{ RADIO_DoNotSetsiriName }
option:{ RADIO_SETsiriNAME }
set DEVICE attrTemplate speech_recognition_request_siriName

name:speech_recognition_request_siriName
filter:NAME=speechrecognTesting
order:1000021b
desc:generic template to ask for siriName attribute setting. Only intented for internal use by speech_recognition_request_siriName
par:SIRIISNAME;Current attribute value alexaName;{ AttrVal("DEVICE","siriName","(not set)") }
par:SIRINAME;Please enter siriName. Current value: SIRIISNAME;{ undef }
option:{my @devices=devspec2array("TYPE=(siri)");; $devices[0] ? return 1 : return 0}
attr DEVICE siriName SIRINAME

Zitatname: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=alexa");; $devices[0] ? return 1 : return 0}
set DEVICE attrTemplate speech_recognition_alexa_specials
option:{my @devices=devspec2array("TYPE=siri");; $devices[0] ? AttrVal("DEVICE","genericDeviceType","none") eq "none" ? 0 : 1 : 0 }
set DEVICE attrTemplate speech_recognition_siri_specials
option:{my @devices=devspec2array("TYPE=gassistant");; $devices[0] ? return 1 : return 0}

Komme erst später zum ausprobieren, aber genau dieser Ablauf will mir nicht in den Kopf/interessiert mich.
Was denn wenn beide Devices existieren, erst wird  attrTemplate speech_recognition_alexa_specials ausgeführt, es kommt das Dialogfenster für Alexa das wird bestätigt und dann ist doch Ende oder wird danach dann attrTemplate speech_recognition_siri_specials ausgeführt.

Nach dem, was ich von Rudi's damaliger Erläuterung im Kopf habe, wird jeweils alles nach "option:x" nur ausgeführt, wenn die wahr ist, und zwar bis zur nächsten Zeile, die ein wahr ergibt.
Was ich (noch) nicht weiß, ist, wann die Bedingungen ausgewertet werden, gehe aber davon aus, dass das jeweils dann ist, wann die Zeile "dran" ist - daher der Versuch, gleich das Ergebnis aus der alexa-option mit zu berücksichtigen.

Mal schauen, ob das funktioniert, ansonsten müßte man das in "Untertemplates" auslagern.

(partly OT:)
Bin grade dabei, die Tasmota-Geschichte (erst mal nur soweit erforderlich) umzubauen/anzupassen, und würde das ggf. dann versuchen, das (Zwischen-) Ergebnis morgen nach dem regulären Updatezeitpunkt ins svn zu schubsen. Wäre dann super, wenn ihr dann auch mal mit wachsamen Augen drübersehen könntet...

So, updates sind im svn, es wäre also heute Gelegenheit, Rückmeldung für eventuelle Korrekturen zu geben, bevor sich ab morgen "alle" beschweren ;D .

Da sind auch ein paar kleinere Versuche für die mehrkanaligen Tasmota-Geräte mit mit drin., Diesen Teil der Diskussion sollten wir aber in dem anderen Thread vertiefen, hier sollte es vorrangig darum gehen, dass alles funktioniert, wenn die betr. sr-templates _zurecht_ aufgerufen werden.

War doch klar das das nicht klappt, es werden beide option-Zweige im ersten Dialogfenster abgefragt, es sind ja aber Optionsfelder nur eins der sechs ist auswählbar, wähle ich eines bestätige mit OK werden keine weiteren Templates ausgeführt. Nur genericDeviceType wird gesetzt, Ende. siehe auch Bild im Anhang

Hab etwas gespielt, so mein ich passt alles wie vorgestellt :):

Zitatname: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=alexa");; $devices[0] ? return 1 : return 0}
set DEVICE attrTemplate speech_recognition_alexa_specials
option:{my @devices=devspec2array("TYPE=gassistant");; $devices[0] ? return 1 : return 0}

#######
# alexa specials

name:speech_recognition_alexa_specials
filter:NAME=speechrecognTesting
order:1000020a
desc:generic template to set speech recognition attribute alexaName, call e.g. with set xy attrTemplate speech_recognition_alexa_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;{ undef }
par:RADIO_DoNotSetalexaName;Leave alexaName attribute empty;{ undef }
par:RADIO_Delete_gDT;Discard genericDeviceType attribute;{ undef }
option:{ RADIO_Delete_gDT }
deleteAttr DEVICE genericDeviceType
option:{ RADIO_DoNotSetalexaName }
set DEVICE attrTemplate speech_recognition_siri_specials
option:{ RADIO_SETalexaNAME }
set DEVICE attrTemplate speech_recognition_request_alexaName

name:speech_recognition_request_alexaName
filter:NAME=speechrecognTesting
order:1000020b
desc:generic template to ask for alexaName attribute setting. Only intented for internal use by speech_recognition_request_alexaName
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
option:{my @devices=devspec2array("TYPE=siri");; $devices[0] ? AttrVal("DEVICE","genericDeviceType","none") eq "none" ? 0 : 1 : 0 }
set DEVICE attrTemplate speech_recognition_siri_specials

####
#siri specials

name:speech_recognition_siri_specials
filter:NAME=speechrecognTesting
order:1000021a
desc:generic template to set speech recognition attribute alexaName, call e.g. with set xy attrTemplate speech_recognition_siri_specials ALEXANAME=myAlexaName
option:{my @devices=devspec2array("TYPE=(siri)");; $devices[0] ? return 1 : return 0}
par:RADIO_SETsiriNAME;Set a new siriName;{ undef }
par:RADIO_DoNotSetsiriName;Leave siriName attribute empty;{ undef }
par:RADIO_Delete_gDT;Discard genericDeviceType attribute;{ undef }
option:{ RADIO_Delete_gDT }
deleteAttr DEVICE genericDeviceType
option:{ RADIO_DoNotSetsiriName }
option:{ RADIO_SETsiriNAME }
set DEVICE attrTemplate speech_recognition_request_siriName

name:speech_recognition_request_siriName
filter:NAME=speechrecognTesting
order:1000021b
desc:generic template to ask for siriName attribute setting. Only intented for internal use by speech_recognition_request_siriName
par:SIRIISNAME;Current attribute value alexaName;{ AttrVal("DEVICE","siriName","(not set)") }
par:SIRINAME;Please enter siriName. Current value: SIRIISNAME;{ undef }
option:{my @devices=devspec2array("TYPE=(siri)");; $devices[0] ? return 1 : return 0}
attr DEVICE siriName SIRINAME

Hmmm, grins, war mir neu, dass auch die templates (nur?) der nächsten Ebene direkt aufgelöst zu werden scheinen...

Jetzt habe ich aber ein paar gedankliche Hänger bei dem neuen Vorschlag:
- Was passiert denn, wenn kein alexa-TYPE-Device da ist?
- Und warum nur dann siriName abfragen, wenn alexaName nicht gesetzt werden soll?

Klingt eher danach, als müßte man im "general"-template bereits mit diversen "RADIO"-Elementen spielen, und die eben ggf. dann in weiteren Untertemplates aufrufen, oder mehr Fälle abfangen...

Jedenfalls für die ersten beiden sr-Varianten könnte das hier funktionieren:

Zitatname: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=alexa");; $devices[0] ? return 1 : return 0}
set DEVICE attrTemplate speech_recognition_alexa_specials
option:{my @devices=devspec2array("TYPE=siri");; my @alexas=devspec2array("TYPE=alexa");; ($devices[0] && !$alexas[0]) ? AttrVal("DEVICE","genericDeviceType","none") eq "none" ? 0 : 1 : 0 }
set DEVICE attrTemplate speech_recognition_siri_specials
option:{my @devices=devspec2array("TYPE=gassistant");; $devices[0] ? return 1 : return 0}

#######
# alexa specials

name:speech_recognition_alexa_specials
filter:NAME=speechrecognTesting
order:1000020a
desc:generic template to set speech recognition attribute alexaName, call e.g. with set xy attrTemplate speech_recognition_alexa_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;{ undef }
par:RADIO_DoNotSetalexaName;Leave alexaName attribute empty;{ undef }
par:RADIO_Delete_gDT;Discard genericDeviceType attribute;{ undef }
option:{ RADIO_Delete_gDT }
deleteAttr DEVICE genericDeviceType
option:{ RADIO_DoNotSetalexaName }
option:{ RADIO_SETalexaNAME }
set DEVICE attrTemplate speech_recognition_request_alexaName
option:{my @siris=devspec2array("TYPE=siri");; my @alexas=devspec2array("TYPE=alexa");; ($siris[0] && $alexas[0]) ? AttrVal("DEVICE","genericDeviceType","none") eq "none" ? 0 : 1 : 0 }
set DEVICE attrTemplate speech_recognition_siri_specials

Zitat- Was passiert denn, wenn kein alexa-TYPE-Device da ist?

Mir war klar das ich etwas übersehe, mit deinem Vorschlag klappts nur leicht angepasst wie u.a.

Zitat- Und warum nur dann siriName abfragen, wenn alexaName nicht gesetzt werden soll?

Vielleicht mag man das Gerät Homebridge bekannt machen, Alexa aber nicht ?

Zitatname: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=alexa");; $devices[0] ? return 1 : return 0}
set DEVICE attrTemplate speech_recognition_alexa_specials
option:{my @devices=devspec2array("TYPE=siri");; my @alexas=devspec2array("TYPE=alexa");; ($devices[0] && !$alexas[0]) ? AttrVal("DEVICE","genericDeviceType","none") eq "none" ? 0 : 1 : 0 }
set DEVICE attrTemplate speech_recognition_siri_specials
option:{my @devices=devspec2array("TYPE=gassistant");; $devices[0] ? return 1 : return 0}

#######
# alexa specials

name:speech_recognition_alexa_specials
filter:NAME=speechrecognTesting
order:1000020a
desc:generic template to set speech recognition attribute alexaName, call e.g. with set xy attrTemplate speech_recognition_alexa_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;{ undef }
par:RADIO_DoNotSetalexaName;Leave alexaName attribute empty;{ undef }
par:RADIO_Delete_gDT;Discard genericDeviceType attribute;{ undef }
option:{ RADIO_Delete_gDT }
deleteAttr DEVICE genericDeviceType
option:{ RADIO_DoNotSetalexaName }
deleteAttr DEVICE alexaName #optional falls Name zuvor vorhanden
set DEVICE attrTemplate speech_recognition_siri_specials
option:{ RADIO_SETalexaNAME }
set DEVICE attrTemplate speech_recognition_request_alexaName

name:speech_recognition_request_alexaName
filter:NAME=speechrecognTesting
order:1000020b
desc:generic template to ask for alexaName attribute setting. Only intented for internal use by speech_recognition_request_alexaName
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
option:{my @siris=devspec2array("TYPE=siri");; my @alexas=devspec2array("TYPE=alexa");; ($siris[0] && $alexas[0]) ? AttrVal("DEVICE","genericDeviceType","none") eq "none" ? 0 : 1 : 0 }
set DEVICE attrTemplate speech_recognition_siri_specials


####
#siri specials

name:speech_recognition_siri_specials
filter:NAME=speechrecognTesting
order:1000021a
desc:generic template to set speech recognition attribute alexaName, call e.g. with set xy attrTemplate speech_recognition_siri_specials ALEXANAME=myAlexaName
option:{my @devices=devspec2array("TYPE=(siri)");; $devices[0] ? return 1 : return 0}
par:RADIO_SETsiriNAME;Set a new siriName;{ undef }
par:RADIO_DoNotSetsiriName;Leave siriName attribute empty;{ undef }
par:RADIO_Delete_gDT;Discard genericDeviceType attribute;{ undef }
option:{ RADIO_Delete_gDT }
deleteAttr DEVICE genericDeviceType
option:{ RADIO_DoNotSetsiriName }
deleteAttr DEVICE siriName #optional falls Name zuvor vorhanden
option:{ RADIO_SETsiriNAME }
set DEVICE attrTemplate speech_recognition_request_siriName

name:speech_recognition_request_siriName
filter:NAME=speechrecognTesting
order:1000021b
desc:generic template to ask for siriName attribute setting. Only intented for internal use by speech_recognition_request_siriName
par:SIRIISNAME;Current attribute value alexaName;{ AttrVal("DEVICE","siriName","(not set)") }
par:SIRINAME;Please enter siriName. Current value: SIRIISNAME;{ undef }
option:{my @devices=devspec2array("TYPE=(siri)");; $devices[0] ? return 1 : return 0}
attr DEVICE siriName SIRINAME

Zitat von: TomLee am 21 März 2020, 17:10:45
Vielleicht mag man das Gerät Homebridge bekannt machen, Alexa aber nicht ?

Dass es diese Option geben sollte, ist schon klar.

Mir ist nur nicht klar, warum das in speech_recognition_alexa_specials _innerhalb des Zweigs "RADIO_DoNotSetalexaName"_ stehen soll. Denn selbst wenn ein user erst den alexaName vergeben will, kann er doch _auch_ den siriName vergeben wollen, oder?
Daher der Versuch in meinem Code, das in einem _eigenen_ option-Zweig abzubilden (vermutlich wäre es dazu noch sinnvoll, dann RADIO_Delete_gDT gleich als "0" mitzugeben, damit man diese Option beim 2. Dialogfeld gar nicht mehr zu sehen bekommt (?) ?.

Aber so langsam dämmert mir: vermutlich kommt mit diesem option-Zweig wieder die "Doppel-"Abfrage mit den zu vielen "Radios", oder?
Dann brauchen wir in _beiden_ "gdt-nicht-löschen"-Zweigen diesen Aufruf...

Also im Ergebnis so (?):

Zitatname:speech_recognition_alexa_specials
filter:NAME=speechrecognTesting
order:1000020a
desc:generic template to set speech recognition attribute alexaName, call e.g. with set xy attrTemplate speech_recognition_alexa_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;{ undef }
par:RADIO_DoNotSetalexaName;Leave alexaName attribute empty;{ undef }
par:RADIO_Delete_gDT;Discard genericDeviceType attribute;{ undef }
option:{ RADIO_Delete_gDT }
deleteAttr DEVICE genericDeviceType
option:{ RADIO_DoNotSetalexaName }
deleteAttr DEVICE alexaName #optional falls Name zuvor vorhanden
set DEVICE attrTemplate speech_recognition_siri_specials RADIO_Delete_gDT=0
option:{ RADIO_SETalexaNAME }
set DEVICE attrTemplate speech_recognition_request_alexaName
set DEVICE attrTemplate speech_recognition_siri_specials RADIO_Delete_gDT=0

ZitatMir ist nur nicht klar, warum das in speech_recognition_alexa_specials _innerhalb des Zweigs "RADIO_DoNotSetalexaName"_ stehen soll.

Innerhalb speech_recognition_alexa_specials hab ich drei Optionen zur Auswahl
Set a new alexaName
Leave alexaName attribute empty
Discard genericDeviceType attribute

wenn ich keinen alexaNamen vergeben möchte, aber einen siriNamen, brauch ich weiterhin genericDeviceType, dann ist doch klar wenn ich mit Option Leave alexaName attribute empty alexaName leer lasse dann speech_recognition_siri_specials aufzurufen ?
Komme erstmal nicht mit warum Optionsfelder jetzt ausgeblendet werden müssen, der Vorschlag passt auf Anhieb nicht und keine Zeit mehr jetzt, erst wieder später/morgen.


define alexa alexa
define siri siri

Auf nem Testssystem und du könntest nachvollziehen warum, das nicht immer einfach zu erklären wieso und weshalb.

Hmm, dachte immer, dass man im Hintergrund mehr braucht zum testen. Ist in der Tat schräg, was da passiert und schade, dass das nicht klappen will, den alten Namen anzuzeigen, sofern vorhanden.

Na jedenfalls sind wir jetzt vermutlich einen weiteren Schritt weiter, auch wenn das noch nicht abschließend fertig getestet ist, aber so wie jetzt im svn (nochmal anders...) sieht es erst mal einigermaßen ok aus. Bin mal gespannt, was so an Rückmeldungen kommt...

ZitatDas Modul AttrTemplate ist indirekt Bestandteil der SetExtensions, das Modul kann von Modulautoren aber auch ohne diese mit in beliebige (Geräte-) Module mit eingebaut werden.

Kenne mich nicht aus, sind das große Anpassungen oder nur wenige Zeilen die man ergänzen müsste für die Variante ohne SetExtensions ?

Würde gerne ein neues sr-Template welches einfach nur die Attribute genericDeviceType und homebridgeMapping setzt, in einem Modul das bisher kein attrTemplate eingebaut hat, testen.

---

Zu der jetzigen SVN-Variante:

Bin der Meinung Leave alexaName attribute empty versteht der User so das nach Bestätigung der alexaName nicht mehr vorhanden ist (das kann vorkommen wenn man auf ein älteres Gerät das einem der Sprachassistenten zuvor bekannt war und nun ein Template angewendet wird), darum hatte ich in diesem Zweig deleteAttr DEVICE alexaName #optional falls Name vorgeschlagen.
Sonst wär doch besser etwas in der Art wie Keep alexaName/siriName

Eigentlich ist es nicht viel, was man ergänzen muß, damit AttrTemplate sauber eingebunden wird, siehe https://svn.fhem.de/trac/changeset/17769/#file2 => da ist die Erweiterung der SetExtensions drin, kann man analog in jedes andere Modul übernehmen...

---

Wegen set/keep werde ich nochmal schauen: Eigentlich sollte es kein Hexenwerk sein, das dahingehend zu berücksichtigen, dass man Punkte wie "keep current", "set new", "delete current" je nach Bedarf angezeigt bekommt, so was müßte mit denselben Mechanismen gehen wie das Ausblenden auf der 2. Stufe siri, wenn vorher alexa durch ist... 
(Das wäre dann nahe dem, was ich mit ALEXAISNAME immer erreichen wollte...).
Danke für den Schubs, jetzt wird langsam ein richtig ordentlicher Schuh draus :) .

Zur Info: seit eben ist nochmal eine aktualisierte Fassung im svn, allerdings - nach einem freundlichen Hinweis auf die verbesserungsfähige Namensgebung - unter neuem Namen: speechcontrol.template.

Die Namen der einzelnen templates habe ich auch angepasst, die betreffenden Aufrufe in den meisten anderen template-files auch. Neu hinzugekommen ist jetzt beim alexa-template noch ein "skip"-Button, zumindest bei meinen Tests hier scheint das alles soweit zu funktionieren.

Dann wäre jetzt eigentlich gassistant an der Reihe...

(Und: gibt es eventuell noch weitere Sprachsteuerungsvarianten, die wir bisher nicht im Fokus hatten?)

In speechcontrol.template fehlen in den Templatenamen zwischen speech und control die Unterstriche oder andersrum in  mqtt2.template sind welche vorhanden die weg müssten.

Argh, zu viele Änderungen gleichzeitig/nacheinander...

Danke für den Hinweis, jetzt sollte es passen.

Hallo zusammen,

ich hoffe es ist okay wenn ich mich mal hier anhänge. Ich habe einen Thread https://forum.fhem.de/index.php/topic,116317.0.html (https://forum.fhem.de/index.php/topic,116317.0.html) in dem mir schon toll geholfen wurde. Nun stehe ich aber vor dem Alexa Problem. Ich hab das attrTemplate für eurotronic ausgewählt und nach set kam ein Abfragefenster mit dem ich einen Alexa Namen vergeben konnte und dies auch getan habe. Nun habe ich Alexa-fhem neu gestartet und mit Alexa nach neuen Geräten gesucht. Es wird gefunden aber ich bekomme immer wenn ich die Temperatur setzen möchte die Antwort "Heiz... unterstützt das nicht"
Was fehlt mir noch?

Hi,

mir ist das schon öfter aufgefallen, die Hoffnung war aber das irgendwann, irgendwer anders das mal anspricht, jetzt mach ichs halt doch.

Wenn ich bei mir (immer noch Siri-Definition(nutz ich aber gar nicht mehr) und Alexa-Definition vorhanden) ein Template anwende werden in dem Dialogfeld die Optionen immer zwei mal angezeigt, siehe Anhang.
Und egal was ich auswähle es wird immer gdT und homebridgemapping gesetzt, wenn man auswählt einen alexaName vergeben zu wollen, kommt die "Abfrage" dazu nicht, das Template wird einfach angewendet nach bestätigen von OK.

Kannst du dir das mal bitte bei Gelegenheit genauer anschauen warum es dazu kommt ?

(Ich hab kurz in die Templates reingeschaut, ehrlich gesagt mag ich mich zur Zeit nicht damit befassen, für mich ist das Arbeit da wieder reinzukommen, mit sowas beschäftige ich mich gerne wieder wenns draussen kalt ist.)

Zitat von: TomLee am 01 September 2021, 18:08:00
... mir ist das schon öfter aufgefallen, ...

Mit RHASSPY die letzten Monate, muss dir das auf deinen Test-Installationen doch auch aufgefallen sein oder verhält es sich dort (mit nur einer RHASSPY-Definition, hab das Thema RHASSPY nur mit zuenen ::)  Augen verfolgt, weiß nicht mal die Definition davon sonst hätt ichs ausprobiert) anders ?

Hmm, kann es sein, dass das nur auftritt, wenn man es mit einem mehrkanaligen versucht?

Hab's eben mit einem "tasmota_POW_USB_split" versucht und konnte das das doppelte Dialogfeld auch erzeugen. Ist soweit nachvollziehbar, weil über das "redirect" "set DEVICE attrTemplate tasmota_POW" doppelt das "set DEVICE.* attrTemplate speechcontrol_type_switch" aufgerufen wird. Entsprechendes findet statt, wenn irgendwo sowas steht:
set DEVICE,DEVICE_CH2 attrTemplate speechcontrol_type_switch

Insofern ist es in der Tat verwunderlich, dass das bisher keiner gemeldet hat...

(Bzgl. RHASSPY hatte ich jetzt dann zwar die prinzipielle Option, das besser und selbst zu testen, aber da ich keinen Anlass hatte, an der vorher schon vorhandenen Schreibweise was zu ändern, ist es mir nicht aufgefallen...).

Na ja, wie dem auch sei, jetzt muss ich mir irgendwie überlegen, wie ich diese Schleife anderweitig hingebogen bekomme... Wird aber vermutlich etwas dauern.

ZitatHmm, kann es sein, dass das nur auftritt, wenn man es mit einem mehrkanaligen versucht?

Nee, eigentlich nicht, hab mich jetzt nicht viel mit beschäftigt, so aus der Erinnerung heraus würd ich behaupten bei allen Devices die ich die letzten Monate neu angelegt hatte (ob zum Test oder weils einfach ein neues Device war) und ein Template angewendet, war das der Fall.

Sry ich wollt gestern eigentlich noch eine Minimal- Definition mit angeben mit der ich vor dem schreiben all die genannten Punkte durch bin, angewendet aber ja nicht relevant hatte ich immer zigbee2mqtt_light_cct.

defmod MQTT2_zigbee_bulb_Test MQTT2_DEVICE zigbee_0x00158d0002fdc5d7
attr MQTT2_zigbee_bulb_Test IODev MQTT2_Server
attr MQTT2_zigbee_bulb_Test devicetopic zigbee2mqtt/0x00158d0002fdc5d7
attr MQTT2_zigbee_bulb_Test readingList $DEVICETOPIC:.* { json2nameValue($EVENT) }
attr MQTT2_zigbee_bulb_Test room MQTT2_DEVICE

Öhm, jetzt bin ich noch ratloser als zuvor...

Dein RAW-Device in die Testinstallation, genanntes Template angewandt => doppelte Abfrage...
Das Tasmota-Ding von vorhin mit "basic" => einfache Abfrage, dasselbe mit einem "split" => doppelt (wie vorhin, allerdings habe ich auch in mqtt2.template etwas rumgespielt).

Habe im Moment den Verdacht, dass es vielleicht mit der Änderung bzgl. RHASSPY was zu tun haben könnte, aber im Moment erschließt sich mir der Zusammenhang noch nicht so recht, und ein schneller Test mit der Version von Jan. 21 brachte auch weiter das "doppelte Lottchen" für den cct-Versuch.

Ok, vielleicht, weil da RHASSPY und ein alexa-Device definiert sind in der Testinstallation? RHASSPY gelöscht. Erwartungsgemäß weiter doppelte Abfrage...

Hmm, strange, aber im Moment auf die Schnelle nicht so einfach zu durchschauen, warum das passiert.

OK, wie fast immer, wenn es verwirrend ist: es sind zwei unterschiedliche Probleme...

Es gibt zum einen bug im 255-light, update dafür kommt.

Und zum anderen klappt eben das mit dem Komma nicht so einfach, man muss das irgendwie entzerren. Meine bisherigen Tests waren nur sehr bedingt erfolgreich, mal sehen... Tendenziell müssen es separate Aufrufe werden, was aber andere Nachteile nach sich zieht. Kannst ja mal schauen, ob dir was einfällt wenn die updates im svn sind.

Cool, hab mir zum testen beispielhaft die Definition aus dem ersten Post in dem anderen Thread angelegt das Template angewendet (Siri und Alexa Definition vorhanden) und jetzt erfolgt erst das Dialogfeld für die Alexa Konfiguration und anschliessend das für Siri.

Jetzt gefällt mir das, so hatte ich mir das damals vorgestellt, was mir nicht gefällt  ::) lass ich mal noch aus, kommt irgendwann noch.

Macht man zwar normal nicht, wenn ich aber nochmal das Template auf die erste Definition anwende kommt das "Popup" im Anhang, das mit "already defined, delete it first" ist ja korrekt, das mit dem HTML auch ?

ZitatMacht man zwar normal nicht, wenn ich aber nochmal das Template auf die erste Definition anwende kommt das "Popup" im Anhang, das mit "already defined, delete it first" ist ja korrekt, das mit dem HTML auch ?

Wie mann es nimmt.
Es ist die Folge des Hacks, wie die Dialog-Abfrage der fehlenden Parameter implementiert ist.
Habe im Moment noch keine Idee, wie ich das sinnvoll und mit minimalen Aufwand verschoenern soll.
Ich denke aber noch nach :)

Weiß nicht, wie groß der Aufwand ist, aber vielleicht wäre es möglich, "define" und "copy"-Anweisungen vorab zu prüfen, ob die Zieldevices schon existieren? Wenn ja => Hinweis an User mit "Bitte erst aufräumen"?
(Kann sein, dass ich mir damit ein Eigentor schieße. defmod sollte aber bitte zulässig bleiben).

Ansonsten sind seit eben einige loop: und "mehrfach"-attrTemplate-Anweisungen (wieder) im svn.

@TomLee: Danke für den schnellen Test und die Rückmeldung!

Ich habe AttrTemplate.pm angepasst, jetzt sollte die Fehlermeldung zivilisierter sein.
Siehe Anhang mit meinem Test-Template