Perl - Modul 10_RHASSPY.pm "professionalisieren"

Begonnen von drhirn, 18 Februar 2021, 17:02:31

Vorheriges Thema - Nächstes Thema

drhirn

Jetzt wird mir das Mapping vorgelesen :D


PERL WARNING: Use of uninitialized value within %specials in substitution iterator at ./FHEM/10_RHASSPY.pm line 279.
2021.02.22 11:31:22.387 1: ERROR evaluating {ResponseOnOff()}: Not enough arguments for main::ResponseOnOff at (eval 615) line 1, near "()"


Da fehlt das "$DEVICE" zwischen den Klammern.

Beta-User

...auch nicht unbedingt mein Spezialgbiet...

Hier noch ein Versuch mit EvalSpecials (=>Import):
sub RHASSPY_execute {
    my $hash   = shift // return;
    my $device = shift // carp q[No target device provided!] && return;
    my $cmd    = shift // carp q[No command provided!]       && return;
    my $value  = shift // carp q[No value provided!]         && return;
    my $siteId = shift // $hash->{helper}{defaultRoom};
    $siteId = $hash->{helper}{defaultRoom} if $siteId eq "default";


    # Nutervariablen setzen
    my %specials = (
         '%DEVICE' => $device,
         '%VALUE'  => $value,
         '%ROOM'   => $siteId
    );
   
    $cmd  = EvalSpecials($cmd, %specials);
 
    # CMD ausführen
    #my $returnVal = eval $cmd;
    return AnalyzePerlCommand( $hash, $cmd );
}
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

Beta-User

#62
Mal ein paar erste Versuche noch zum Thema $language...

Leider kann ich mal wieder nicht viel mehr sagen wie: es läßt sich laden ::) .

Edit: jetzt mit Anhang...
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

drhirn

Zitat von: Beta-User am 22 Februar 2021, 11:51:56
Hier noch ein Versuch mit EvalSpecials (=>Import):

Der funktioniert! Danke!

Sprache sehe ich mir gleich an. Wo würdest du da die unterschiedlichen Ausdrücke platzieren? In %languagevars nehm ich an?

Beta-User

Zitat von: drhirn am 22 Februar 2021, 13:29:15
Der funktioniert! Danke!
Ufff...

Zitat
Sprache sehe ich mir gleich an. Wo würdest du da die unterschiedlichen Ausdrücke platzieren? In %languagevars nehm ich an?
Jein...

Damit wollte ich erst mal eine Art Machbarkeitsanalyse vorbereiten mit wenigen Elementen, wobei ich mir auch mit der Struktur noch unsicher bin:
Es gibt ja da nicht nur Sätze, die zurückgegeben werden, sondern auch ein paar regexe, die passen müssen (z.B. "lauter|leiser" für "Lautstärke"). Diese müssen auch irgendwo abgelegt sein und dynamisch verwendet werden. (Der Code sieht um das Suchwort "Lautstärke" herum aber auch - unabhängig von der Sprache - irgendwie provisorisch aus).

Mittelfristig sollte dann dieser Hash woanders herkommen:
Zitat von: Beta-User am 21 Februar 2021, 08:41:56
Meine Ideen (ohne Anspruch auf Vollständigkeit oder optimierte Gestaltung):
- die Textbausteine in einen Hash  packen und den zentral ablegen (irgendwo unter $hash->{helper})
- ein language-Attribut bzw. Internal vorzusehen (per default aus global zu füllen)
- den Internal-Wert dann bei der regex (${language}.fhem) mit berücksichtigen und beim Aufbau des Hashs
- Die Texte sollten dann außerhalb des Moduls abgelegt werden (separate config-file), das ganze dann so, dass configDB es auch versteht (FileRead nutzen und Internal .configfile setzen (?)). Am einfachsten vermutlich im JSON-Format (?). Dann können die User das separat bearbeiten und ggf. viel einfacher wechselseitig austauschen.
Der Code sollte bis hierher erst mal nur den 2. Spiegelstrich erfüllen, ohne dass die Funktionalität leidet, da, wo jetzt statt des harten "de" $language bzw. ${language} steht...
Nächster Schritt wäre dann, alle "de"-Vorkommen durch die Variable zu ersetzen.
Erst danach würde man den Hash füllen und beginnen, die lookups einzubauen, und dann ist es auch schon nicht mehr weit, dass man dann auch andere Sprachen unterstützen würde... 8)
(Es sei denn, jemand hat eine bessere/cleverere Idee und/oder man könnte das (in Teilen?) schon woanders finden?)
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

drhirn

Verstehe. Also, ich kann berichten: Es funktioniert mal nichts nicht. Die Slots/Sentences werden wie erwartet jetzt mit "en.fhem.xxx" benannt. Ansonsten tu ich mir mit dem Testen gerade ein bisschen schwer. Da muss ich mir in einer Pause etwas überlegen.

Darf ich dich bitten, mal die aktuelle testing-Branch runter zu laden und dort weiter zu machen. Da sind auch sonst noch ein paar kleine Änderungen von mir dabei. Würde mir das Zusammenführen einfacher machen.

drhirn

"updateSlots" funktioniert so nicht.

$deviceData =qq({"intents/$language.fhem.Shortcuts.ini":"[$language.fhem:Shortcuts]\n); geht nicht

$deviceData='{"intents/'.$language.'.fhem.Shortcuts.ini":"['.$language.'.fhem:Shortcuts]\n'; das geht

Beta-User

#67
Das explizite concat gefällt mir noch nicht so recht... Kannst du mal noch das hier testen:
$deviceData =qq({"intents/${language}.fhem.Shortcuts.ini":"[${language}.fhem:Shortcuts]\n);

2. Nachtrag: Und dann gleich noch das:
      $deviceData->{qq(${language}.fhem.Device)} = \@devices if @devices;
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

Beta-User

#68
Sorry, den hatte ich erst übersehen...
Zitat von: drhirn am 22 Februar 2021, 14:19:08Verstehe. Also, ich kann berichten: Es funktioniert mal nichts nicht. Die Slots/Sentences werden wie erwartet jetzt mit "en.fhem.xxx" benannt. Ansonsten tu ich mir mit dem Testen gerade ein bisschen schwer. Da muss ich mir in einer Pause etwas überlegen.
Ziel sollte wie gesagt erst mal sein, dass "de" weiter funktioniert wie gehabt. Dann bauen wir ggf. den Hash (für de) auf, und erst danach könnten/sollten wir uns mit "en" beschäftigen, da gibt es im Moment ja nichts, was wir testen könnten.


ZitatDarf ich dich bitten, mal die aktuelle testing-Branch runter zu laden und dort weiter zu machen. Da sind auch sonst noch ein paar kleine Änderungen von mir dabei. Würde mir das Zusammenführen einfacher machen.
...hab's mal versucht, gleich 00_MQTT.pm ausgebaut und verwurstelt, was mit spontan vor die Flinte gelaufen ist...
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

drhirn

$deviceData =qq({"intents/${language}.fhem.Shortcuts.ini":"[${language}.fhem:Shortcuts]\\n);

So geht's. Der letzte Backslash musste noch escaped werden. Der muss im "Klartext" übermittelt werden.

Ansonsten funktioniert alles.

$language sollten wir aber wo anders definieren. Kann ja sein, dass man das im laufenden Betrieb ändern will. Im Moment wird sie aber nur bei der ersten Initialisierung des Moduls gesetzt. Da bin ich gerade drauf rein gefallen ;).
Ich hätte das gleich am Anfang gemacht. Dort wo jetzt my $language = 'en'; steht. Wie verpönt wäre das?

drhirn

Und ich frage mich gerade, ob es nicht schlauer wäre, die Sprache in der DEF des Moduls zu bestimmen. Sonst vergessen alle, eines der Attribute zu setzen. Was meinst du?

Beta-User

Zitat von: drhirn am 22 Februar 2021, 17:26:04
Ansonsten funktioniert alles.
8)
Sehr cool, Danke für die Rückmeldung!

Was $language angeht:
- Die Variable wird (hoffentlich) beim Starten aktualisiert, entsprechend der gesetzten Attribute (erst Device, dann global, wenn da nichts steht auf "en", entsprechend der von dir zitierten Setzung);
- wenn man das Attribut setzt, wird aktualisiert;
- wenn man das Attribut löscht, wird ebenfalls aktualisiert. (?)

Die "Lücke" entsteht, wenn man es später in global ändert. Halte ich für verschmerzbar, ggf. muss man halt die DEF anfassen (Leerzeichen), dann wird auch wieder alles aktualisiert, oder?

M.E. wäre es zielführend, wenn (auch) RHASSPY den user etwas dahingehend (=>cref) leitet, dass man die Grundeinstellungen in global passend setzt; wer es mehrsprachig braucht/will, kann dann am Device was verändern (und ggf. auch aktiv danach suchen). Hat z.B. auch Auswirkungen auf WDT und cref-Sprache.

Ansonsten bin ich kein Freund von "Doppeloptionen", sonst muss man nur erklären, wie die Prio ist (es gibt sowas bei Twilight, aber da teilweise aus historischen Gründen).

Wir brauchen auf alle Fälle eine Logik, die erlaubt, den Hash im laufenden Betrieb neu einzulesen, ggf. braucht es einen setter/Perl-Command dafür (damit man ggf. auch testen kann...)

Haben wir schon alle "de"-Stellen erwischt?
(Wenn nein, bitte den konsolidierten aktuellen Code nach github laden).

Wenn ja, sollten wir mal versuchen, eine Response dynamisch aufzubauen. Würde für die Zeitabfrage votieren...?

Zitat von: JensS am 22 Februar 2021, 17:36:03
Nachdem ich gestern Abend die 0.2.0 getestet habe, wurde mein Logfile (./log/Rhasspy_Intent.log Rhasspy:lastIntentPayload.*) nicht weiter gefüllt.
Es scheint, als wurde kein Event ausgelöst.
Gruß Jens
Habe ich gesehen, kann aber im Moment nicht zuordnen, was die Rückmeldung bedeutet und ob das noch aktuell ist...?
(@JensS: Tester? @drhirn hat sich auch schon mit dem "developer" "angefreundet"... :P )
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

drhirn

Ich hatte global auf DE. RHASSPY hab ich von EN auf DE gesetzt. Es hat mir trotzdem EN genommen. Erst nach einem FHEM-Neustart hat's gepasst. Muss das aber noch genauer testen.

Muss für heute nur leider aufgeben. Aktueller Stand ist auf GitHub (testing).

Danke dir nochmal!

Beta-User

Das language-Problem hing mit der Parameterübergabe zusammen, beim Löschen wird als Attributwert nichts übergeben, so wäre es richtig:
# Attribute setzen / löschen
sub RHASSPY_Attr {
    my $command = shift;
    my $name = shift;
    my $attribute = shift // return;
    my $value = shift;

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

drhirn

Ok, danke!
Dann  muss ich jetzt eine Frage stellen, die mir eine Internet-Recherche nicht beantworten konnte: Was bedeutet "//"? Und "// return" im Speziellen?