speechrecogn.template: bugs, Fragen, Anregungen

[Beta-User]

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

[TomLee]

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?

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.

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?

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

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?

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 

[TomLee]

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.

[Beta-User]

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

[TomLee]

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

ja

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

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

[joelinux]

- 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

[joelinux]

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

[Beta-User]

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:

Code Auswählen Erweitern

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.

[TomLee]

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

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.

[Beta-User]

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?

[TomLee]

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.

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.

[joelinux]

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. 

[Beta-User]

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.

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?

[rudolfkoenig]

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.