Modulentwicklung für Rhasspy Sprachassistent

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

Vorheriges Thema - Nächstes Thema

Beta-User

Hmm, damit habe ich ein Problem..., und zwar das folgende: Bisher sind _alle_ RHASSPY-Attribute nach dem Muster "eine Zeile, ein Thema, nächste Zeile, nächstes Thema", und "Thema=..." aufgebaut.
Vermutlich ist
a) eine Abkehr von obigem Prinzip nur "ganz oder gar nicht" machbar (oder extrem verwirrend für die User)
b) das parsen zumindest auf den ersten Blick ziemlich schwierig; vor allem auch, was Rückmeldungen etc. angeht. Beim bisherigen Verfahren kann man relativ einfach halbwegs qualifizierte Rückmeldungen generieren, wenn was nicht paßt. Bei der vorgeschlagenen Methode wird es spätestens dann schwierig, wenn irgendwo eine Klammer fehlt oder zu viel ist...

Generelle Anmerkung: Bin mir nicht sicher, ob man für parseParams nicht sogar einen Teil der heutigen "" weglassen könnte, das sind für meinen (ungetesteten) Geschmack sowieso etwas viele.

Sowas sollte eigentlich auch gehen:
set Rhasspy play siteId=wohnzimmer path=./raspberry01.wav repeats=3 wait=5 id=timer_wohnzimmer_Taimer
bzw.:
attr RHASSPY rhasspyTweaks timerSounds= default=./flasche.wav Eier=3:20:./flasche1.wav Kartoffeln=5:./flasche2.wav
Aber klar, es ist - so oder so - relativ viel Info in einer "Zeile", und ich finde es ziemlich schwierig, mir eine (verständlichere) Alternative auszudenken, die sich dann auch noch halbwegs ordentlich in zusammengehörende Einzelteile zerlegen läßt...
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

Es war nur ein Vorschlag. Du wolltest meine Meinung wissen ;D

Wie wär's mit einem Label pro Zeile?

timerEier = 3:20:./flasche.wav
timer<label>= repeat:wait:path


Aber, mir ist's eigentlich egal. Ist jetzt kein Feature, das ich unbedingt brauche. Mir reicht ein (längerer) Sound für alle Timer, der sich ein paar Mal wiederholt, außer er wird abgebrochen.

Beta-User

#377
Die Variante ohne Anführungszeichen läuft scheinbar durch...
attr RHASSPY rhasspyTweaks timerSounds= default=./flasche.wav Eier=3:20:./flasche1.wav Kartoffeln=5:./flasche2.wav

Problem war der Versuch, ein grade laufendes at innerhalb dessen Ausführung neu zu definieren. Hätte ich mir eigentlich denken können...

Zitat von: drhirn am 15 April 2021, 15:09:28
Es war nur ein Vorschlag. Du wolltest meine Meinung wissen ;D
:) Reaktion war auch nicht böse gemeint. Eigentlich hasse ich diese Bandwurmargumente nämlich auch, und wenn man beim Doppelpunkte-Zählen drauskommt, ist das auch nur bedingt lustig.

Zitat
Wie wär's mit einem Label pro Zeile?

timerEier = 3:20:./flasche.wav
timer<label>= repeat:wait:path

Wäre vermutlich ein gangbarer Mittelweg, aber: es gibt schon "timerLimits". Könnte man vorneweg rausfischen, aber der Code wird dadurch insgesamt deutlich länger, weil man dann auch noch den Hash erweitern muss und nicht einfach reinkopiert usw.. Von daher:
Zitat
Aber, mir ist's eigentlich egal. Ist jetzt kein Feature, das ich unbedingt brauche. Mir reicht ein (längerer) Sound für alle Timer, der sich ein paar Mal wiederholt, außer er wird abgebrochen.
Mir geht es ähnlich: "eigentlich" will ich einen default setzen können, und wenn es dann nicht für alle Fälle gut ist, kann man ja nachregeln und muss dann halt mit der Einschränkung leben, dass es eine Bandwurmzeile wird....

Ansonsten wollte ich schon schreiben, dass mir im Moment keine weiteren timer-Tweaks mehr einfallen, aber just in dem Moment: Super wäre, wenn FHEM so intelligent wäre zu wissen, ob der Verstärker im passenden Raum grade an ist und dann den Sound darüber zu spielen...? Und die File von meinem minidlna-System holen zu können, wäre auch cool. (Aber wie rendert man die dann auf die Bandbreite, die Rhasspy kann...?!?) *duck und weg*
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 15 April 2021, 15:22:41
Von daher:Mir geht es ähnlich: "eigentlich" will ich einen default setzen können, und wenn es dann nicht für alle Fälle gut ist, kann man ja nachregeln und muss dann halt mit der Einschränkung leben, dass es eine Bandwurmzeile wird....

Ja, sehe ich auch so. Wobei, ich tät's fast anders formulieren. Ich will, dass es einen Default gibt. Wenn ich was anderes will, muss ich's halt setzen.

Zitat
Ansonsten wollte ich schon schreiben, dass mir im Moment keine weiteren timer-Tweaks mehr einfallen, aber just in dem Moment: Super wäre, wenn FHEM so intelligent wäre zu wissen, ob der Verstärker im passenden Raum grade an ist und dann den Sound darüber zu spielen...? Und die File von meinem minidlna-System holen zu können, wäre auch cool. (Aber wie rendert man die dann auf die Bandbreite, die Rhasspy kann...?!?) *duck und weg*

Viel Spaß damit ;D

drhirn

Ich sehe den Timer ja übrigens immer noch nicht als FHEM-Feature. Das war ja nur eine Notlösung, weil der Wunsch danach kam. Aber eigentlich sollte das Rhasspy selber können. Also als Skill.

Beta-User

Hmm, damit hast du eigentlich recht!

Ist halt bis auf weiteres nicht Realität...

(Ansonsten hätte ich noch "timerTrigger" als Tweak für die Liste... Macht zwar keinen großen Sinn, komplette Kommandos (wie in shortcuts) in die Attribute aufzunehmen, aber ein trigger-Kommando über das RHASSPY-Device abzusetzen mit allen Bausteinchen, die wir sowieso haben ("trigger <rhasspy> timerEnd siteId Room Label"), das wäre eigentlich keine große Sache. Analog zu Sound könnte man default für alle setzen, oder eben nur eine Auswahl.
Dann müßte man nur diesen Trigger abfangen und könnte beliebige Makros anflanschen (normale FHEM-Logik). Geht jetzt zwar auch, wenn man den deletereading-Befehl abfängt, aber in dieser neuen Soundschleife passiert das mit dem Löschen erst zum Schluß...)
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

Wichtiger wäre eigentlich, darüber nachzudenken, wie wir mit Kommazahlen umgehen. Rhasspy kann's nämlich nicht. Zumindest weiß ich nicht, wie.

Ich kann nur so einen Satz bauen:
stelle die Heizung{Device} auf (0..100){Value_0}(komma)(0..10){Value_1} grad{Unit}

Das hilft uns aber nicht weiter. Wie könnten wir da tun?

drhirn

Ha! Und ein Über-Feature ist mir gerade eingefallen. Sollte nämlich die Gastronomie irgendwann wieder aufsperren dürfen, brauche ich dann wieder regelmäßig folgenden Satz: "Wann bin ich [gestern|heute] nach Hause gekommen?" verknüpft mit "Residents" ;D

Beta-User

#383
Zitat von: drhirn am 15 April 2021, 16:14:41
Wichtiger wäre eigentlich, [...].
...eigentlich, ja ::) ...

Ist aber schon fertig... :P

Zitat
Ich kann nur so einen Satz bauen:
stelle die Heizung{Device} auf (0..100){Value_0}(komma)(0..10){Value_1} grad{Unit}

Das hilft uns aber nicht weiter. Wie könnten wir da tun?
Ungetestet vielleicht sowas:
stelle die Heizung{Device} auf ((0..100)[(komma:.)(0..10)]){Value} grad{Unit}
Zitat von: drhirn am 15 April 2021, 16:29:05
Ha! Und ein Über-Feature ist mir gerade eingefallen. Sollte nämlich die Gastronomie irgendwann wieder aufsperren dürfen, brauche ich dann wieder regelmäßig folgenden Satz: "Wann bin ich [gestern|heute] nach Hause gekommen?" verknüpft mit "Residents" ;D
Nur zu...
(Es gibt auch noch CustomEvents, und jemand sollte mal checken, ob $data sauber ankommt...)
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 15 April 2021, 16:31:42
stelle die Heizung{Device} auf ((0..100)[(komma:.)(0..10)]){Value} grad{Unit}

Geht leider nicht, schon ausprobiert. Das bringt Rhasspy statt "22.5" dann "22 . 5". Warum auch immer.

Zitat
(Es gibt auch noch CustomEvents, und jemand sollte mal checken, ob $data sauber ankommt...)

Was sind CustomEvents?

Beta-User

Öhm, CustomIntents...

OK, also Rhasspy grenzt jedes "Element" gegen das nächste mit einem Leerzeichen ab. Könnte man doch relativ einfach auf der FHEM-Seite abfangen, wenn man weiß, dass ein Wert numerisch sein muss? (oder "müßte", weil er nur Ziffern, Punkte und Leerzeichen enthält?)
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


Beta-User

Zitat von: drhirn am 15 April 2021, 16:43:52
Timer-WAV wird jetzt brav wiederholt :)
...dann sind wir vermutlich bei Version 0.4.8a1 angekommen... 8)

Bzgl. Prioritäten (mehr als Merker für mich selbst):
- gDT: bessere mappings (also in Schritt 1 v.a. bei "media" nur, was es auch gibt).
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 15 April 2021, 16:50:18
...dann sind wir vermutlich bei Version 0.4.8a1 angekommen... 8)

Ach so, nö, 0.4.9 weil neues Feature ;)

drhirn

#389
--edit--
Es liegt an mir




Zitat von: Beta-User am 15 April 2021, 16:31:42
(Es gibt auch noch CustomEvents, und jemand sollte mal checken, ob $data sauber ankommt...)

Hmm, keine Ahnung, ob das an mir liegt.

Ich hab den rhasspyIntent
Calculation=rhasspyCalc(DATA)

Die Sub dazu in der 99_myUtils.pm ist:

sub rhasspyCalc{
    my $data = shift // return;
    return "Calc data is: $data";
}


Die Anfrage war:
RHASSPY: [Rhasspy] Parse (IO: rhasspyMQTT2): Msg: hermes/intent/de.fhem_Calculation => {"input": "Was macht 5 div 3", "intent": {"intentName": "de.fhem:Calculation", "confidenceScore": 1.0}, "siteId": "default", "id": "e93be8ec-e93d-4d3a-abb9-2f78853f7f84", "slots": [{"entity": "rhasspy/number", "value": {"kind": "Number", "value": 5}, "slotName": "Number1", "rawValue": "fünf", "confidence": 1.0, "range": {"start": 10, "end": 11, "rawStart": 10, "rawEnd": 14}}, {"entity": "Operator", "value": {"kind": "Unknown", "value": "div"}, "slotName": "Operator", "rawValue": "dividiert durch", "confidence": 1.0, "range": {"start": 12, "end": 15, "rawStart": 15, "rawEnd": 30}}, {"entity": "rhasspy/number", "value": {"kind": "Number", "value": 3}, "slotName": "Number2", "rawValue": "drei", "confidence": 1.0, "range": {"start": 16, "end": 17, "rawStart": 31, "rawEnd": 35}}], "sessionId": "e93be8ec-e93d-4d3a-abb9-2f78853f7f84", "customData": null, "asrTokens": [[{"value": "Was", "confidence": 1.0, "rangeStart": 0, "rangeEnd": 3, "time": null}, {"value": "macht", "confidence": 1.0, "rangeStart": 4, "rangeEnd": 9, "time": null}, {"value": "5", "confidence": 1.0, "rangeStart": 10, "rangeEnd": 11, "time": null}, {"value": "div", "confidence": 1.0, "rangeStart": 12, "rangeEnd": 15, "time": null}, {"value": "3", "confidence": 1.0, "rangeStart": 16, "rangeEnd": 17, "time": null}]], "asrConfidence": null, "rawInput": "was macht 5 dividiert durch drei", "wakewordId": null, "lang": null}

Das Ergebnis:

2021.04.15 17:47:40.749 5: handleCustomIntent called with Calculation key
2021.04.15 17:47:40.749 5: Calling sub:  rhasspyCalc( HASH(0x55e6d56d5808) )
2021.04.15 17:47:40.749 1: PERL WARNING: Hexadecimal number > 0xffffffff non-portable at (eval 407) line 1.
2021.04.15 17:47:40.750 3: eval:  rhasspyCalc( HASH(0x55e6d56d5808) )
2021.04.15 17:47:40.750 1: ERROR evaluating  rhasspyCalc( HASH(0x55e6d56d5808) ) : Undefined subroutine &main::HASH called at (eval 407) line 1.

2021.04.15 17:47:40.750 5: Response is: Undefined subroutine &main::HASH called at (eval 407) line 1.