speechrecogn.template: bugs, Fragen, Anregungen

Begonnen von TomLee, 05 März 2020, 15:58:24

Vorheriges Thema - Nächstes Thema

Beta-User

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).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

TomLee

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

Beta-User

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

(Hoffe, du kannst das verstehen, ist einigermaßen absrakt...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

TomLee

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.

Beta-User

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?
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

rudolfkoenig

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 ", ?"

Beta-User

 :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?
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

rudolfkoenig

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

Beta-User

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!))
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

TomLee

#39
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



Beta-User

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...?)
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

TomLee

Zitatattr DEVICE room NEWROOM

Stand doch in der Fehlermeldung, ich wollte es nicht sehen

TomLee

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.

Beta-User

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"...)
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

TomLee

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.