speechrecogn.template: bugs, Fragen, Anregungen

[TomLee]

Mit dem jetzigen Template stimmt was nicht.

# 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

Code Auswählen Erweitern

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.

Code Auswählen Erweitern

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:

Code Auswählen Erweitern


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

Gruß

Thomas

[Beta-User]

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

Code Auswählen Erweitern


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

[TomLee]

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

Code Auswählen Erweitern

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:

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

Code Auswählen Erweitern

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

gibts einen Fehler beim ausführen.

[TomLee]

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

[Beta-User]

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

[TomLee]

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.

[TomLee]

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

[TomLee]

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 ?

[Beta-User]

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.

[TomLee]

Genau so dacht ich mir das    , 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.

[Beta-User]

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

[TomLee]

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.

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

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

Code Auswählen Erweitern

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

Code Auswählen Erweitern

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

[Beta-User]

Moin,

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

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

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

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

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

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;{ 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

[TomLee]

komme nicht weiter.

in name:speech_recognition_alaxaName_firstrun das

Code Auswählen Erweitern

{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

Code Auswählen Erweitern

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"

[Beta-User]

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?