speechrecogn.template: bugs, Fragen, Anregungen

[TomLee]

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

Code Auswählen Erweitern

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.

[Beta-User]

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

[TomLee]

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

Code Auswählen Erweitern

name:speech_recognition_alaxaName_firstrun
filter:NAME=speechrecognTesting
order:1000020a
desc:generic template to set speech recognition attribute alexaName, call e.g. with set xy attrTemplate speech_recognition_alaxaName_firstrun ALEXANAME=myAlexaName
option:{my @devices=devspec2array("TYPE=(alexa)");; $devices[0] ? return 1 : return 0}
par:ALEXANAME;Please enter alexaName (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.

[Beta-User]

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.

[TomLee]

Habs ausprobiert klappt.

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

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

[Beta-User]

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?

[TomLee]

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?

Ich fänds super.

[Beta-User]

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

[TomLee]

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) 

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

[Beta-User]

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

[TomLee]

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.

[Beta-User]

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:

Code Auswählen Erweitern

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?

[TomLee]

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

Code Auswählen Erweitern


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

[TomLee]

Link korrigiert

[Beta-User]

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):

Code Auswählen Erweitern

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, das erste Array-Element aus @cfg_Import_Helper_Devices wäre in diesem Code das, was du hier suchst...).