Modulentwicklung für Rhasspy Sprachassistent

Begonnen von drhirn, 11 März 2021, 15:59:50

Vorheriges Thema - Nächstes Thema

drhirn

Ich habe gerade die Möglichkeit eingebaut, die Ausgabe-Lautstärke einer siteId zu ändern.

Dabei gefällt mir aber das zusätzliche If in Zeile 440 nicht sonderlich. Hast du eine Idee, wie man das besser lösen könnte?

Und mir ist aufgefallen, dass wir in Zeile 452 auf EIN vorhandenes Argument prüfen. Das stimmt nicht. Bei "speak", "playWav" und "setVolume" müssens zwei sein. Wie machen wir das am Besten? Die Länge des Arrays prüfen?

Und, weißt du zufällig, ob man die Sets in FHEMWEB sortieren kann?

Beta-User

Zitat von: drhirn am 18 März 2021, 10:30:06
Ich habe gerade die Möglichkeit eingebaut, die Ausgabe-Lautstärke einer siteId zu ändern.
:)
ZitatDabei gefällt mir aber das zusätzliche If in Zeile 440 nicht sonderlich. Hast du eine Idee, wie man das besser lösen könnte?
Ob das viel "besser" ist:
if ( $command eq 'play' || $command eq 'volume' ) {
        $values[0] = $h->{siteId} if defined $h->{siteId};
        $values[1] = $h->{path}   if defined $h->{path};
        $values[1] = $h->{volume} if defined $h->{volume};
    }

ZitatUnd mir ist aufgefallen, dass wir in Zeile 452 auf EIN vorhandenes Argument prüfen. Das stimmt nicht. Bei "speak", "playWav" und "setVolume" müssens zwei sein. Wie machen wir das am Besten? Die Länge des Arrays prüfen?
Vermutlich läßt sich das später einfacher prüfen. Kannst du mal testen:
# Set volume on specific siteId
sub RHASSPY_setVolume {
    my $hash = shift // return;
    my $cmd = shift;

    return 'setVolume needs siteId and volume as parameters!' if !defined $cmd->{siteId} || !defined $cmd->{volume};

    my $sendData =  {
        id => '0',
        sessionId => '0'
    };


    Log3($hash->{NAME}, 5, 'setVolume called');

    #if (defined $cmd->{siteId} && defined $cmd->{volume}) {
        $sendData->{siteId} = $cmd->{siteId};
        $sendData->{volume} = 0 + $cmd->{volume};

        my $json = toJSON($sendData);
        return IOWrite($hash, 'publish', qq{rhasspy/audioServer/setVolume $json});   
    #}
    return;
}


ZitatUnd, weißt du zufällig, ob man die Sets in FHEMWEB sortieren kann?
Habe ich bisher noch nie versucht, vermute aber: geht nicht... (da wird einiger Perl- und Java-Code zwischen Modulcode und Anzeige sein).
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 18 März 2021, 12:02:12Ob das viel "besser" ist:

Finde schon :)

ZitatVermutlich läßt sich das später einfacher prüfen. Kannst du mal testen:

Könnte man natürlich so machen. Ich war irgendwie der Überzeugung, dass muss schon in SET passieren. Aber nach erneutem Studium der FHEM-Doku ist das wohl nicht so.

ZitatHabe ich bisher noch nie versucht, vermute aber: geht nicht... (da wird einiger Perl- und Java-Code zwischen Modulcode und Anzeige sein).

Hmm, schade.



Habe mir gerade andere Module angesehen, werde aber nicht schlau draus.
Ich fänd's schön, wenn ich dem User Tipperei abnehmen könnte, in dem beim SET je nach Befehl unterschiedliche Eingabefelder kommen. Ein weiteres Auswahlfeld (wie bei reinit) ist mir klar, wie das funktioniert. Aber sowas:

SET Rhasspy playWAV siteId:Auswahlfeld path:Eingabefeld

bekomme ich nicht hin.
Fällt dir auf die Schnelle ein einfaches Modul-Beispiel (oder Doku) ein, wo ich mir das abschauen könnte?

Beta-User

#78
Zitat von: drhirn am 18 März 2021, 12:30:36
Finde schon :)
...na dann 8) .

ZitatKönnte man natürlich so machen. Ich war irgendwie der Überzeugung, dass muss schon in SET passieren. Aber nach erneutem Studium der FHEM-Doku ist das wohl nicht so.
Mir war so, dass "SetFn" halt nicht was anderes als undef zurückgeben darf, woher auch immer das am Ende kommt (ist bei AttrFn auch so). Von daher ist es m.E. völlig ok, das einfach auf die Art mittels der dispatch-Funktion durchzureichen...

Zitat
Hmm, schade.



Habe mir gerade andere Module angesehen, werde aber nicht schlau draus.
Ich fänd's schön, wenn ich dem User Tipperei abnehmen könnte, in dem beim SET je nach Befehl unterschiedliche Eingabefelder kommen. Ein weiteres Auswahlfeld (wie bei reinit) ist mir klar, wie das funktioniert. Aber sowas:

SET Rhasspy playWAV siteId:Auswahlfeld path:Eingabefeld

bekomme ich nicht hin.
Fällt dir auf die Schnelle ein einfaches Modul-Beispiel (oder Doku) ein, wo ich mir das abschauen könnte?
Na ja, dazu fällt mir ein, dass es diese Art Anfrage seitens diverser "Neulinge" immer mal wieder gibt, aber afaik ist FHEMWEB nicht auf diese Art der Interaktion ausgelegt (will sagen: du müßtest ein widget (js-Code) beisteuern, dann ginge das ggf., wobei dem Bauchgefühl nach der Code dann genau auf das RHASSPY_Modul zugeschnitten sein müßte, aber das ist (mal wieder) gar nicht meine Ecke...)

Anbei mal wieder etwas aktualisierter Code, die Hash-Verwendung kann jetzt über "useHash=1" in der DEF erzwungen werden, und updateSlots erneuert dann auch gleich den Hash, der jetzt auch mal wieder leicht anders aussieht.



Fyi:
FHEM sagt mir jetzt auch auf Anfrage via Handy-App die Zeit durch, "hello world" ist also gegeben - ganz ohne separates Mikro oder Lautsprecher.
Bei Gelegenheit folgen die dafür erforderlichen Einstellungen (separater Thread), jetzt muss ich nur mal wieder suchen, wie ich "mach das Radio lauter" auf neue Weise als intent/Satz in Rhasspy definieren muss (deine Doku auf Github ist noch alter Stand ;) ).
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 hab im Moment die Sätze. Sind nicht final, das geht besser. Deckt aber ab, was ich bisher getestet habe.


[de.fhem:SetNumeric]
(schalt|schalte) $de.fhem.Device{Device} [um] [(0..10){Value!float}] [dezibel{Unit}] (lauter|höher){Change:volUp}
(schalt|schalte) $de.fhem.Device{Device} [um] [(0..10){Value!float}] [dezibel{Unit}] (leiser|niedriger){Change:volDown}
(schalt|schalte) $de.fhem.Device{Device} [um] [(0..10){Value!float}] [grad{Unit}] (höher|wärmer){Change:tempUp}
(schalt|schalte) $de.fhem.Device{Device} [um] [(0..10){Value!float}] [grad{Unit}] (niedriger|kälter){Change:tempDown}
(schalt|schalte) $de.fhem.Device{Device} [um] [(0..100){Value}] [prozent{Unit:percent}] (heller){Change:lightUp}
(schalt|schalte) $de.fhem.Device{Device} [um] [(0..100){Value}] [prozent{Unit:percent}] (dunkler){Change:lightDown}
(schalt|schalte) $de.fhem.Device{Device} auf (0..100){Value!float}
(mehr{Change:lightUp}|weniger{Change:lightDown}) $de.fhem.Device{Device} [$de.fhem.Room{Room}]


(float funktioniert nicht, ist ein Rhasspy-Problem)

drhirn


Beta-User

#81
Sehr cool 8) !

Rhasspy spricht mit mir, es passiert zwar nicht immer unbedingt das, was ich gehofft hatte, aber immerhin...
Die Reihenfolge der Sätze scheint auch eine Rolle zu spielen, ziemlich "lustig", das ganze :o ::) .

Bin mir noch nicht sicher, ob es gut ist, alles pauschal über dieselben Sätze abzuhandeln, aber das werde ich dann ja sehen.

Für den Moment bin ich etwas weitergekommen mit genericDeviceType, auch wenn es noch nicht perfekt 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

Naja, Rhasspy nimmt den ersten Satz, der passt. Deshalb muss man ziemlich aufpassen, dass man nicht Sätze baut, die zu verschiedenen Intents passen. Ist knifflig manchmal.

Und man muss natürlich schon sagen, dass es weder Alexa, noch Echo ist. Wird auch nie so gut funktionieren. Steht ja weder ein Milliarden-Unternehmen, noch eine riesige Serverlandschaft, noch eine mit hundertausenden privaten Daten trainierte KI dahinter. Wenn man das in Betracht zieht, ist es erstaunlich, was synesthesiam (und andere) in der kurzen Zeit hochgezogen hat.

drhirn

Zitat von: Beta-User am 18 März 2021, 21:23:25
Für den Moment bin ich etwas weitergekommen mit genericDeviceType, auch wenn es noch nicht perfekt ist...

Version 0.4.5beta im GitHub

drhirn

Und ich finde, das ist ein guter Zeitpunkt, von den drei Warnings zu erzählen, die ich jedes Mal bei einem Neustart von FHEM bekomme ;)

Zitat
PERL WARNING: Useless use of hash element in void context at ./FHEM/10_RHASSPY.pm line 2435, <$fh> line 159.
PERL WARNING: Use of uninitialized value in string ne at ./FHEM/10_RHASSPY.pm line 308, <$fh> line 159.
PERL WARNING: Use of uninitialized value $currentMapping{"type"} in hash element at ./FHEM/10_RHASSPY.pm line 703.

Beta-User

#85
Zitat von: drhirn am 19 März 2021, 09:11:41
Und ich finde, das ist ein guter Zeitpunkt, von den drei Warnings zu erzählen, die ich jedes Mal bei einem Neustart von FHEM bekomme ;)
... es gab noch ein paar mehr... ::)
Fixes anbei (hoffe ich zumindest).




Zu meinen ersten Erfahrungen mit der App hatte ich hier was geschrieben, also falls jemand Ideen hat, wie man das eine oder andere verbessern kann (zerhackte Rückmeldungen, z.B., oder eine .service für meinen FHEM-Server ::) )...?



Vorläufig hätten wir dann folgende offene Punkte, wenn ich das richtig sehe:
Zitat

       
  • Status: "[Device:Reading]" isn't recognized
  • MediaChannels RHASSPY_getCmd($hash, $device, 'rhasspyChannels', $channel, undef); stays undef
  • Add Shortcuts to README (https://forum.fhem.de/index.php/topic,118926.msg1136115.html#msg1136115) (drhirn)
  • Shortcuts: "Longpoll" only works when "n" is given. Perl-Code does never "longpoll"
  • GetNumeric: Answer "already at max/min" if minVal or maxVal is reached
Von hinten nach vorne:
- "GetNumeric" ist ein feature-request, oder? Da weiß ich noch nicht so richtig, wie es gemeint ist, vermutlich geht es darum, (nur) bei Änderungen, bei denen die Begrenzung durch min/maxVal zuschlägt eine spezifischere Rückmeldung zu geben? (Muss ich mir ansehen, ist eventuell nicht so einfach oder ein auch Klacks...)

- Shortcuts und das Verhalten bei Perl-Code ist beschrieben, ich bin noch nicht sicher, ob es Sinn macht, trigger über den "Ausbruch" aus der eigentlichen Eventverarbeitung (InternalTimer für den Perl-Code, wenn "n" nicht angegeben ist (?)) zu erzeugen. Jedenfalls reicht das eigentliche Thema m.E. weiter wie nur "longpoll", verhindert werden eventuell auch - allgemeiner gesprochen - explizite Events an den geschalteten Geräten.

- Über RHASSPY_getCmd im Allgemeinen müssen wir noch nachdenken - jedenfalls ab dem Moment "Zwangshash" ist es "eigentlich" überflüssig. Wobei mir bisher völlig entgangen war, dass es ein allgemeines Attribut "response" geben könnte, das wir auswerten - genau das macht aber der Code in RHASSPY_getResponse(). (Hm, eigentlich hat der Gedanke was, auch noch individuellere Antworten pro Device per Attribut festlegen zu können, aber irgendwo sollte auch mal Ende sein...).

- Status: Bitte prüfen, ob das nicht "gelöst" ist. Zumindest hat es eben mit dem in der Testfile enthaltenen dummy mit und ohne Quotes funktioniert.
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 19 März 2021, 10:50:29
Zu meinen ersten Erfahrungen mit der App hatte ich hier was geschrieben, also falls jemand Ideen hat, wie man das eine oder andere verbessern kann (zerhackte Rückmeldungen, z.B., oder eine .service für meinen FHEM-Server ::) )...?

Zerhackte Rückmeldungen sind mir neu. Ich hab mir allerdings auch noch nie einen langen Satz ausgeben lassen. Könnte aber natürlich auch an der App liegen.
Zum Service: https://community.rhasspy.org/t/rhasspy-as-service-with-debian-installation/1278/22


Zitat
- "GetNumeric" ist ein feature-request, oder? Da weiß ich noch nicht so richtig, wie es gemeint ist, vermutlich geht es darum, (nur) bei Änderungen, bei denen die Begrenzung durch min/maxVal zuschlägt eine spezifischere Rückmeldung zu geben? (Muss ich mir ansehen, ist eventuell nicht so einfach oder ein auch Klacks...)

Jup Feature-Request. Ich hab mir das gar nicht so kompliziert vorgestellt. Aktuellen Wert (GetValue) mit gewünschter Erhöhung addieren und mit maxVal vergleichen. Wenn größer/gleich, einfach die Rückmeldung.

Zitat- Shortcuts und das Verhalten bei Perl-Code ist beschrieben, ich bin noch nicht sicher, ob es Sinn macht, trigger über den "Ausbruch" aus der eigentlichen Eventverarbeitung (InternalTimer für den Perl-Code, wenn "n" nicht angegeben ist (?)) zu erzeugen. Jedenfalls reicht das eigentliche Thema m.E. weiter wie nur "longpoll", verhindert werden eventuell auch - allgemeiner gesprochen - explizite Events an den geschalteten Geräten.

Viiiiel zu komplex für mich ;). Aber auch nicht wahnsinnig wichtig.


ZitatWobei mir bisher völlig entgangen war, dass es ein allgemeines Attribut "response" geben könnte, das wir auswerten - genau das macht aber der Code in RHASSPY_getResponse(). (Hm, eigentlich hat der Gedanke was, auch noch individuellere Antworten pro Device per Attribut festlegen zu können, aber irgendwo sollte auch mal Ende sein...).

Thyraz hat das bei einigen Intents eingebaut. Kann gut sein, dass das bei allen geht. Dokumentiert wurde es nie. Gerade heute damit herumgespielt. Funktioniert soweit. Zumindest bei Set/GetOnOff, mehr hab ich nicht getestet.

Zitat- Status: Bitte prüfen, ob das nicht "gelöst" ist. Zumindest hat es eben mit dem in der Testfile enthaltenen dummy mit und ohne Quotes funktioniert.

Mach ich gleich.

drhirn

Zitat von: Beta-User am 19 März 2021, 10:50:29
... es gab noch ein paar mehr... ::)
Fixes anbei (hoffe ich zumindest).

Zeile 731 und 761 sind doppelt gemoppelt. Welche soll ich ändern?

Zeile 2516 immer noch
Useless use of hash element in void context at

Zeilennummern entsprechen deinem obigen Code.

Beta-User

#88
Zitat von: drhirn am 19 März 2021, 11:14:50
Zerhackte Rückmeldungen sind mir neu. Ich hab mir allerdings auch noch nie einen langen Satz ausgeben lassen. Könnte aber natürlich auch an der App liegen.
Vermute eher espeak, werde mal den Vorschlag aus dem anderen Thread testen, kann aber dauern, denn

Zitat
Zum Service: https://community.rhasspy.org/t/rhasspy-as-service-with-debian-installation/1278/22
Danke für den Link, auch wenn mir völlig schleierhaft ist, warum die Jungs das als root laufen lassen...?
Werde mal versuchen, das - wie fhem - unter einem "kleinen System-user" laufen zu lassen. Für später:
[Unit]
Description=Rhasspy Service
After=syslog.target network.target

[Service]
Type=simple
ExecStart=/bin/bash -o pipefail -c '{ /usr/bin/rhasspy -p de 2>&1 | cat >&2 3>&-; } 3>&1'
WorkingDirectory=/opt/rhasspy
User=rhasspy
Group=audio
RestartSec=1
Restart=on-failure
StandardOutput=syslog
StandardError=syslog
SyslogIdentifier=rhasspy

[Install]
WantedBy=multi-user.target

Zitat
Jup Feature-Request. Ich hab mir das gar nicht so kompliziert vorgestellt. Aktuellen Wert (GetValue) mit gewünschter Erhöhung addieren und mit maxVal vergleichen. Wenn größer/gleich, einfach die Rückmeldung.
Na ja, diese Art Vergleich findet an ein paar Stellen statt und jetzt auch noch "verkürzt" durch min/max. Man müßte also irgendwie dann auch noch den Vergleichswert mitziehen (oder die Antwort) und das später wieder zusammenfieseln. IMO nicht ganz so einfach, wie es auf den ersten Blick ausschaut (SetNummeric ist nach perlcritic-Auffassung schon jetzt "zu kompliziert").
ZitatViiiiel zu komplex für mich ;) . Aber auch nicht wahnsinnig wichtig.
Wäre ein gutes Lernfeld ;) .

Zitat
Thyraz hat das bei einigen Intents eingebaut. Kann gut sein, dass das bei allen geht. Dokumentiert wurde es nie. Gerade heute damit herumgespielt. Funktioniert soweit. Zumindest bei Set/GetOnOff, mehr hab ich nicht getestet.
Das sind m.E. zwei Paar Stiefel, über die wir da sprechen: Die response aus rhasspyMappings wird immer durchgeschleust. Aber die besagte Funktion versucht es noch an einer weiteren Stelle ;) . Und das ist m.E. eine Ecke zu weit bzw. - wenn man dahin gehen will - dann nicht fertig entwickelt...

ZitatMach ich gleich.
Viel Erfolg.

Zitat von: drhirn am 19 März 2021, 11:36:29
Zeile 731 und 761 sind doppelt gemoppelt. Welche soll ich ändern?
#761 war m.E. ein überflüssiger Rest. Die jetzige Logik ist m.E. stringet: Wenn kein gDT angegeben ist, wird das Device in dieser Auswertung ignoriert, und das wird direkt vorneweg geprüft.

ZitatZeile 2516 immer noch
Useless use of hash element in void context at
Kann sein, dass das durch den Kommentar kommt, das scheint das ? : durcheinanderzubringen. (to be verified).
Habe den mal verschoben.
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 19 März 2021, 11:42:01SetNummeric ist nach perlcritic-Auffassung schon jetzt "zu kompliziert"

Ist auch mir zu kompliziert. Ich kann's nicht mal mehr dokumentieren.
Es sind auch mittlerweile unnötige Sachen dabei. Das "map=percent" im Mapping ist z.B. eigentlich überflüssig. Da reicht auch ein "{Unit:percent}" im Rhasspy-Satz.
Vielleicht sollten wir das einfach bei Gelegenheit komplett neu schreiben? Oder auch in mehrere Intents teilen?