FHEM Forum

FHEM => Frontends => Sprachsteuerung => Thema gestartet von: drhirn am 11 März 2021, 15:59:50

Titel: Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 11 März 2021, 15:59:50
Dieser Thread ist die Fortsetzung von https://forum.fhem.de/index.php/topic,118926.msg1133694.html#msg1133694

Hier geht es nur über die Entwicklung des Moduls. Ist somit für Endnutzer eher nicht so relevant.

Wer in das Thema RHASSPY einsteigen möchte, findet im Wiki die wichtigsten Informationen.

- https://wiki.fhem.de/wiki/RHASSPY/Schnellstart (https://wiki.fhem.de/wiki/RHASSPY/Schnellstart): Eine Schnellstart-Anleitung, die gleich zu den ersten Erfolgen führt
- https://wiki.fhem.de/wiki/RHASSPY/Vertiefung (https://wiki.fhem.de/wiki/RHASSPY/Vertiefung): Vertiefende Informationen nach dem Schnellstart
- https://wiki.fhem.de/wiki/RHASSPY (https://wiki.fhem.de/wiki/RHASSPY): Die RHASSPY-Hauptseite mit den meisten Konfigurations-Optionen und allen Intents

Fragen zu RHASSPY werden gerne hier im Forum unter "Frontends/Sprachsteuerung" beanwortet. Bitte dem jeweiligen Themen-Titel ein "[RHASSPY]" voranstellen, damit man den Zusammenhang besser erkennt.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 11 März 2021, 16:23:47
Zitat von: Beta-User am 11 März 2021, 15:42:13
Glaube, die Ursache gefunden zu haben:
Da wurden teils Hashes mit leerem Inhalt erzeugt, '' ist halt nicht undef...

Jetzt hat das Hand und Fuß :)

Aber, damit's nicht langweilig wird:
"radio um 10 prozent lauter"

Msg: hermes/intent/de.fhem_SetNumeric => {"input": "radio 10 percent volUp", "intent": {"intentName": "de.fhem:SetNumeric", "confidenceScore": 1.0}, "siteId": "wohnzimmer", "id": null, "slots": [{"entity": "de.fhem.Device", "value": {"kind": "Unknown", "value": "radio"}, "slotName": "Device", "rawValue": "radio", "confidence": 1.0, "range": {"start": 0, "end": 5, "rawStart": 0, "rawEnd": 5}}, {"entity": "rhasspy/number", "value": {"kind": "Number", "value": 10}, "slotName": "Value", "rawValue": "zehn", "confidence": 1.0, "range": {"start": 6, "end": 8, "rawStart": 6, "rawEnd": 10}}, {"entity": "Unit", "value": {"kind": "Unknown", "value": "percent"}, "slotName": "Unit", "rawValue": "prozent", "confidence": 1.0, "range": {"start": 9, "end": 16, "rawStart": 11, "rawEnd": 18}}, {"entity": "Change", "value": {"kind": "Unknown", "value": "volUp"}, "slotName": "Change", "rawValue": "lauter", "confidence": 1.0, "range": {"start": 17, "end": 22, "rawStart": 19, "rawEnd": 25}}], "sessionId": "wohnzimmer-snowboy-8080609b-e57b-44f5-935b-5a29bfcb8e67", "customData": null, "asrTokens": [[{"value": "radio", "confidence": 1.0, "rangeStart": 0, "rangeEnd": 5, "time": null}, {"value": "10", "confidence": 1.0, "rangeStart": 6, "rangeEnd": 8, "time": null}, {"value": "percent", "confidence": 1.0, "rangeStart": 9, "rangeEnd": 16, "time": null}, {"value": "volUp", "confidence": 1.0, "rangeStart": 17, "rangeEnd": 22, "time": null}]], "asrConfidence": null, "rawInput": "radio zehn prozent lauter", "wakewordId": "snowboy", "lang": null}

Mapping macht hier den Unterschied:
SetNumeric:currentVal=volume,minVal=-60,maxVal=40,cmd=volume,step=0.5,type=volume

Man würde davon ausgehen, dass bei einem Ausgangswert von 0 als Ergebnis 10 kommt. Wird aber -50. Liegt das am negativen minVal?


Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 11 März 2021, 17:02:28
Irgendwo stand, dass Rhasspy nicht mit negativen Zahlen könnte, und so gibt es an diversen Stellen Vorkehrungen, um insbesondere percent unbedingt zwischen 0 und 100 zu halten.

Insbesondere:
                    $newVal =   0 if ($newVal <   0);
                    $newVal = 100 if ($newVal > 100);

und - zwar so beabsichtigt, aber vermutlich unwirksam - auch hier:
                #my $minVal  = (defined($mapping->{minVal})) ? $mapping->{minVal} : 0; # Rhasspy kann keine negativen Nummern bisher, daher erzwungener minVal
                my $minVal  = $mapping->{minVal} // 0; # Rhasspy kann keine negativen Nummern bisher, daher erzwungener minVal


Würde behaupten, dass es reichen würde, die oberen beiden Zeilen auszukommentieren, habe aber die Furcht, dass das Nebenwirkungen hat...

Ähm, nicht umsonst meint perlcritic:
Subroutine "RHASSPY_handleIntentSetNumeric" with high complexity score (59) at line 1918, column 1. Consider refactoring.
(Ist aber nicht so einfach, das ist schon klar...)
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 11 März 2021, 17:11:26
Rhasspy muss es eh nicht können. Das kann nicht mal 0 hab ich gerade gemerkt. Kann uns aber egal sein, ich sage Rhasspy ja nicht, es soll um -10% höher stellen.

Das Modul sollt's können. AV-Receiver arbeiten z.B. oft mit negativen dB Werten.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 11 März 2021, 18:12:00
Da hast du wohl recht...

M.E. war da auch ein Logikfehlerchen verborgen, bin mal gespannt, ob du das zwischen diesen ganzen Änderungen findest...

(Und es wäre ggf. hilfreich, die de-cfg um die neuen Fehlerkategorien zu ergänzen...)
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 11 März 2021, 19:38:29
Habt ihr mal bitte ne aktuelle Sprachdatei.?
Gruß Jens
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 11 März 2021, 21:07:43
versuch's mal mit dem hier (ist auf die Schnelle zusammengestupft, nur , damit das erst mal vollständig ist):

#$Id: rhasspy-de.cfg 2021-03-11-alpha- Beta-User $
# Diese Datei an einem Ort ablegen, den der user fhem lesen kann
# und dann diesen Ort im Attribut configFile hinterlegen. Beispiel:
# attr <rhasspy> configFile ./log/rhasspy-de.cfg
#
# "commaconversion", "units" und "mutated_vowels" sind optional, wenn nicht
# angegeben, werden die englischen Werte/Gepflogenheiten verwendet bzw. keine
# Ersetzungen vorgenommen.

{
  "commaconversion": "1",
  "mutated_vowels": {
    "Ä": "Ae",
    "Ö": "Oe",
    "Ü": "Ue",
    "ß": "ss",
    "ä": "ae",
    "ö": "oe",
    "ü": "ue"
  },
  "units": {
    "unitHours": "(stunde|stunden)",
    "unitMinutes": "(minute|minuten)"
  },
  "on": "an",
  "percent": "Prozent",
  "responses": {
    "DefaultConfirmation": "OK",
    "DefaultError": "Da ist leider etwas schief gegangen",
    "NoValidData": "Sorry but the received data is not sufficient to derive any action",
    "NoDeviceFound": "Sorry but I could not find a matching device",
    "NoMappingFound": "Sorry but I could not find a suitable mapping",
    "NoNewValDerived": "Sorry but I could not calculate a new value to set",
    "NoActiveMediaDevice": "Tut mir leid  es ist kein Wiedergabegerät aktiv",
    "duration_not_understood": "Tut mir leid ich habe die Dauer nicht verstanden",
    "timerEnd": "taimer im raum $room abgelaufen",
    "timerSet": "taimer im raum $room gesetzt auf $value $unit",
    "DefaultConfirmationTimeout": "Sorry too late to confirm",
    "DefaultCancelConfir": "Thanks aborted",
    "DefaultConfirReceived": "ok will do it",
    "timeRequest": "Es ist $hour Uhr $min",
    "weekdayRequest": "Heute ist $weekDay"
  },
  "Change": {
    "Types": {
      "volume": "Lautstärke",
      "brightness": "Helligkeit",
      "temperature": "Temperatur",
      "battery": "Batterie",
      "waterLevel": "Wasserstand",
      "airHumidity": "Luftfeuchtigkeit",
      "soilHumidity": "Bodenfeuchte",
      "targetValue": "Sollwert"
    },
    "regex": {
      "kälter": "temperature",
      "wärmer": "temperature",
      "dunkler": "brightness",
      "heller": "brightness",
      "lauter": "volume",
      "leiser": "volume",
      "upward": "(höher|heller|lauter|wärmer)",
      "setTarget": "(Helligkeit|Lautstärke|Sollwert)",
      "volume": "Lautstärke"
    },
    "regexToEn": {
      "Temperatur": "temperature",
      "Luftfeuchtigkeit": "airHumidity",
      "Batterie": "battery",
      "Wasserstand": "waterLevel",
      "Bodenfeuchte": "soilMoisture",
      "Helligkeit": "brightness",
      "Sollwert": "setTarget",
      "Lautstärke": "volume"
    },
    "responses": {
      "volume": "$device ist auf $value gestellt",
      "brightness": "$device ist auf $value gestellt",
      "temperature": {
        "0": "Die Temperatur von $location ist $value",
        "1": "Die Temperatur von $location beträgt $value Grad"
      },
      "battery": {
        "0": "Der Batteriestand von $location ist $value",
        "1": "Der Batteriestand von $location beträgt $value Prozent"
      },
      "waterLevel": "Der Wasserstand von $location beträgt $value Prozent",
      "airHumidity": "Die Luftfeuchtigkeit von $location beträgt $value Prozent",
      "soilMoisture": "Die Bodenfeuchte von $location beträgt $value Prozent",
      "knownType": "$mappingType von $location beträgt $value Prozent",
      "unknownType": "Der Wert von $location beträgt $value Prozent"
    }
  },
  "stateResponseType": {
    "aus": "onOff",
    "an": "onOff",
    "auf": "openClose",
    "zu": "openClose",
    "eingefahren": "inOut",
    "ausgefahren": "inOut",
    "läuft": "inOperation",
    "fertig": "inOperation"
  },
  "stateResponses": {
    "onOff": {
      "0": "$deviceName ist ausgeschaltet",
      "1": "$deviceName ist eingeschaltet"
    },
    "openClose": {
      "0": "$deviceName ist geöffnet",
      "1": "$deviceName ist geschlossen"
    },
    "inOut": {
      "0": "$deviceName ist ausgefahren",
      "1": "$deviceName ist eingefahren"
    },
    "inOperation": {
      "0": "$deviceName ist fertig",
      "1": "$deviceName läuft noch"
    }
  }
}
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 12 März 2021, 11:52:23
Zitat von: Beta-User am 11 März 2021, 18:12:00
M.E. war da auch ein Logikfehlerchen verborgen, bin mal gespannt, ob du das zwischen diesen ganzen Änderungen findest...

Hab ich nicht. Aber um ehrlich zu sein, ich hab auch nicht danach gesucht.

Zitat(Und es wäre ggf. hilfreich, die de-cfg um die neuen Fehlerkategorien zu ergänzen...)

Ist erledigt.

Überhaupt ist auf GitHub gerade ein aktueller Stand (ich hab da gestern am Timer gebastelt). Allerdings immer noch unter 0.4.3beta.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 12 März 2021, 14:03:37
So, in meinem vorwochenendlichen Überschwang und weil gerade in der Arbeit und beim Modul alles so funktioniert, wie's soll, hab ich in GitHub eine Version 0.4.3 erstellt. Das ist die aktuelle "stable".

Weiter geht's mit 0.4.4beta ;)
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 12 März 2021, 14:05:55
Na ja, ich hätte da noch ein paar Kleinigkeiten und auch einige Vorarbeiten aus der beta...

Sollte (hoffentlich!) nichts brechen, aber damit wir in etwa auf demselben Stand sind...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 12 März 2021, 14:07:40
An was bastelst du eigentlich gerade? Eine Dialog-Option?

Ich übernehm' das gleich.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 12 März 2021, 14:16:30
An zwei Dingen:
a) Ausführen nur nach Bestätigung, das ist vermutlich das, was du mit "Dialog-Option" meinst?
b) Einsammeln der ganzen Mappings => Bilden von einem Hash, der die ganze Struktur der steuerbaren Devices so abbildet, dass man darüber die Auswertung @runtime machen kann... Da interessiert mich v.a. erst mal, wie der sinnigerweise strukturiert sein sollte.
Ist der für die "eigenen" Attribute mal erstellt und funktionsfähig, könnte man dann "fremde Attribute" ausschlachten.

ad a) fehlt eigentlich fast nur
aa) das Verzögern, wenn "c" gesetzt ist (im Shortcut-handling)
bb) ein "Bestätigungs"-Intent (da wäre Zuarbeit angesagt...)
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 12 März 2021, 14:19:07
Für bb brauche ich mehr Infos. Was genau stellst du dir das vor? Sowas:

Ich: Lösche wikipedia.org
Rhasspy: Bist du sicher?
Ich: Nein
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 12 März 2021, 14:57:04
Ja, genau so..

Oder etwas ausführlicher:

Anweisung via Rhasspy => Rückfrage =>
a) "Ja, mach" (oä) => Ausführung
b) "Neee, bloß nicht!" (oä.) => Abbrechen

oder eben
c) keine rechtzeitige Rückmeldung => Abbruch
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 13 März 2021, 10:40:06
Deutsche Sprache - schwere Sprache.
Mein Rhasspy kann derzeit keine Umlaute:{"Room":"Wohnzimmer","Type":"light","input":"lösche alle light im Wohnzimmer","intent":"SetAllOff","probability":1,"rawInput":"lösche alle lichter im wohnzimmer","requestType":"voice","sessionId":"Wohnzimmer-alexa-f1c191c6-5621-4e09-88ad-10083d405b19","siteId":"Wohnzimmer"}
Darauf hin sagt Rhasspy, dass alle Lampen auf dem Dachboden ausgeschaltet sind.
Vom Rhasspy-Master wird der richtige Raum erkannt und übertragen.
Gruß Jens

p.s. Bei mir funktioniert:
    # JSON Decode und Fehlerüberprüfung
    my $decoded = eval { decode_json(encode('cp-1252',$json)) };

Wobei mir aber immer noch der Dachboden statt Wohnzimmer übergeben wird. Wieso verwendest Du eigentlich "eval"?

p.p.s. dito# Parse the response of the request to the HTTP-API
sub RHASSPY_ParseHttpResponse {
...
        my $siteIds = encode('cp-1252',$ref->{dialogue}{satellite_site_ids});
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 13 März 2021, 11:19:26
Wie und wo ist denn dein FHEM installiert? Windows? Weil mir passiert das nicht. Ich bekomm mit deiner Codierung Probleme.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 13 März 2021, 11:29:03
ZitatDebian auf APU2C4, HM-CFG-USB2, SIGNALduino, HM-ES-PMSw1-Pl, AB440S, AB440R, TFA 30.3121, TFA 30.3125, ITS-150, PIR-5000, configurable Firmata USB & LAN, 1-wire: DS-18B20, DS-18S20, DS-2408, DS-2413, diverse I2C-Komponenten, zigbee2mqtt, ESPEasy etc.
Als Browser nutze ich einen aktuellen Edge auf Windows10 - alles in deutsch. Auf dier Rhasspy-Weboberfläche werden alle Umlaute richtig dargestellt.
Gruß Jens

p.s. Ich hab's mal doppelt gemoppelt:    # JSON Decode und Fehlerüberprüfung
my $decoded = eval { decode_json(encode('utf-8',encode('cp-1252',$json))) };


        my $siteIds = encode('utf-8',encode('cp-1252',$ref->{dialogue}{satellite_site_ids}));

p.p.s.{ qx(locale)}
LANG=de_DE.UTF-8
LANGUAGE=
LC_CTYPE="de_DE.UTF-8"
LC_NUMERIC="de_DE.UTF-8"
LC_TIME="de_DE.UTF-8"
LC_COLLATE="de_DE.UTF-8"
LC_MONETARY="de_DE.UTF-8"
LC_MESSAGES="de_DE.UTF-8"
LC_PAPER="de_DE.UTF-8"
LC_NAME="de_DE.UTF-8"
LC_ADDRESS="de_DE.UTF-8"
LC_TELEPHONE="de_DE.UTF-8"
LC_MEASUREMENT="de_DE.UTF-8"
LC_IDENTIFICATION="de_DE.UTF-8"
LC_ALL=
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 13 März 2021, 11:58:16
Ist dein Debian deutsch?

Ja, zu spät gesehen.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 13 März 2021, 12:04:23
Die Ursache in der Übergabe des falschen Raumnamens ist die Nutzung von "Room" in sentences.ini bzw. rhasspyIntents.
Nach der Umbenennung in "jRoom" funktioniert es wieder.
sentences.ini:[de.fhem:SetAllOff]
(schließe|lösche) alle ((Lichter|Lampen){Type:light}|(Rollos){Type:blind}) [im (Haus | $de.fhem.Room){jRoom}]

rhasspyIntents:SetAllOff=SetAllOff(jRoom,Type)
myUtils.pm:sub SetAllOff{
my $Raum = shift // 'Haus';
my $Typ = shift // 'light';
$Raum = 'Haus' if $Raum eq "Room";

Gruß Jens

p.s. Grrrrr, jetzt wird die SiteId übergeben, statt des gesprochenen Raumnamens.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 13 März 2021, 12:28:25
jRoom kennt das Modul nicht, das kennt nur Room. Und wenn der nicht vorhanden ist, wird Room durch die siteId ersetzt.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 13 März 2021, 12:32:11
Wieso das denn? Im customIntent sollten die Werte 1:1 übergeben - und nicht verändert werden.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 13 März 2021, 12:37:02
Zitat von: JensS am 13 März 2021, 12:04:23
p.s. Grrrrr, jetzt wird die SiteId übergeben, statt des gesprochenen Raumnamens.
Vermutung: der Raumname matcht nicht mit was bekanntem, dann wird aus Raum siteId (immer).
(doppelt, eben durch drhirn bestätigt)
Und ja, es sollte die Info zu jRoom zurückgegeben werden, ich vermute an der Stelle ein Problem mit dem Encoding und/oder mit der Art, wie der JSON-Parser die Daten analysiert. Da werden (schon immer) uU. nicht alle Infos aus dem JSON geholt, (zumindest, wenn ich den Code richtig interpretiere, was aber an der Stelle eher flüchtig überflogen wurde, da er funktioniert hat und perlcritic nicht gemeckert hatte)...



Zu dem Codepage-Thema:
Das mit dem mehrfachen "encode" behagt mir nicht.

Da es keinen wirklichen Standard zu geben scheint: Wie wäre es, das in der DEF konfigurierbar zu machen (encoding= ...) und im default mit UTF-8 zu arbeiten?

@drhirn: Magst du das angehen? (Ich würde ein encoding-Internal vorschlagen, aber das nur füllen, wenn der User es via DEF macht? Alles andere führt nur zu Rückfragen, und wer -wie JensS- ein Problem hat, wird es (hoffentlich) in der cref zu define finden.)



Ansonsten anbei mein noch ziemlich unfertiger Zwischenstand. Neben den (hier deaktivierten) ersten weiteren Vorarbeiten zum Thema Flexibilisierung der Mapping-Generierung sind da auch noch kleinere Änderungen am Basiscode drin. Wäre ggf. gut, das wieder zu konsolidieren, damit es möglichst halbwegs synchron bleibt, was wir tun.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 13 März 2021, 12:47:45
Im customIntent sollten alles frei wählbar sein und auch so übertragen werden. Wenn ich sage: "lösche alle Lichter im Schlafzimmer", sollen dort die Lampen ausgehen.
Früher war nicht alles besser aber zumindest waren die customIntents frei definierbar und haben auch funktioniert.
Ist schon echt anstrengend, jedesmal beim Wechsel zum funktionierenden Modul, die vielen Anpassungen zurückzusetzen.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 13 März 2021, 13:54:33
Ich kann zwar deine Kritik im emotionalen Teil nachvollziehen, allerdings ist es auch für mich nicht so einfach, alles vollständig durchzutesten.
Und für die Rückgabe von siteId statt jRoom habe ich grade auch noch keine Idee...

Generell: M.E. fährt man mit shortcuts besser (was aber nicht bedeuten soll, dass wir die CustomIntents nicht wieder sauber ans Laufen bekommen sollten...!)

@drhirn: Habe die Datei von vorhin nochmal getauscht, jetzt kann man ggf. in den Grundzügen erkennen, wie das mal aufgebaut sein könnte...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 13 März 2021, 14:05:17
Nun gut, wenn die Funktionalität zweitrangig wird, ist es -für mich und meiner Familie- besser, bei der funktionierenden Variante zu bleiben.
Übrigens sind alle Systeme in meinem Netzwerk de_DE.UTF-8-codiert. Also nichts exotisches.
So long.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 13 März 2021, 14:15:55
Das Modul kann jRoom nicht erkennen. Wir verwenden hier fixe Vorgaben, wie die Rhasspy-Sentences auszusehen haben. Inklusive Groß-/Kleinschreibung. Das ist auch nicht anders zu lösen.

z.B.:

Room, Device, Change, Color, ...

Irgendwie muss das Modul ja wissen, was es aus dem JSON ziehen muss.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 13 März 2021, 14:26:27
Ich versuche grade, das zu reparieren, Funktionalität ist nicht "zweitrangig", genau deswegen habe ich ja den Hinweis gegeben, wie es möglicherweise alternativ mit der derzeitigen Basis ans Laufen zu bekommen sein könnte...

Was mir grade fehlt, sind passende topic/payload für CustomIntent. Bei der Payload von 10:40 Uhr kann ich mir mein Testsystem abschießen, das meint dann:
Can't use string ("SetAllOff") as a HASH ref while "strict refs" in use at ./FHEM/10_RHASSPY.pm line 1373.

#1373 ist
    ($data->{intent} = $decoded->{intent}{intentName}) =~ s{\A.*.:}{}x if exists $decoded->{intent}{intentName};

PS: Ja, "eval" nach Möglichkeit zu vermeiden (oder wenigstens "korrekt" zu verwenden), ist schon auch ein Ziel, darum steht ja da heute auch AnalyzePerlCommand statt des "eigenen eval". Ich kann aber nicht sagen, warum es da steht, glaube aber, dass es (anders gelöst!) erforderlich ist, um kaputte JSON-Messages abzufangen.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 13 März 2021, 14:27:09
Zitat von: JensS am 13 März 2021, 14:05:17
Übrigens sind alle Systeme in meinem Netzwerk de_DE.UTF-8-codiert. Also nichts exotisches.

Eh nicht. UTF-8 sollte UTF-8 sein. Egal in welcher Sprache. Finde das etwas merkwürdig. Ich bin mir v.a. nicht ganz sicher, ob das wirklich an FHEM liegt.
Du hast doch sicher irgendeinen MQTT Explorer installiert (MQTT FX, etc.)? Wie sieht das dort aus?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 13 März 2021, 14:47:02
FHEM auf de_DE.UTF-8 umgestellt:

Msg: hermes/intent/de.fhem_SetOnOff => {"input": "licht küche an", "intent": {"intentName": "de.fhem:SetOnOff", "confidenceScore": 0.33333333333333337}, "siteId": "default", "id": "0ae587bc-ff2a-412d-9696-976791828c8a", "slots": [{"entity": "de.fhem.Device", "value": {"kind": "Unknown", "value": "licht"}, "slotName": "Device", "rawValue": "licht", "confidence": 1.0, "range": {"start": 0, "end": 5, "rawStart": 0, "rawEnd": 5}}, {"entity": "de.fhem.Room", "value": {"kind": "Unknown", "value": "küche"}, "slotName": "Room", "rawValue": "küche", "confidence": 1.0, "range": {"start": 6, "end": 11, "rawStart": 6, "rawEnd": 11}}, {"entity": "OnOffValue", "value": {"kind": "Unknown", "value": "an"}, "slotName": "Value", "rawValue": "ein", "confidence": 1.0, "range": {"start": 12, "end": 14, "rawStart": 12, "rawEnd": 15}}], "sessionId": "0ae587bc-ff2a-412d-9696-976791828c8a", "customData": null, "asrTokens": [[{"value": "licht", "confidence": 1.0, "rangeStart": 0, "rangeEnd": 5, "time": null}, {"value": "küche", "confidence": 1.0, "rangeStart": 6, "rangeEnd": 11, "time": null}, {"value": "an", "confidence": 1.0, "rangeStart": 12, "rangeEnd": 14, "time": null}]], "asrConfidence": null, "rawInput": "licht in der küche ein", "wakewordId": null, "lang": null}

Rhasspy + FHEM auf de_DE.UTF8:

Msg: hermes/intent/de.fhem_SetOnOff => {"input": "licht küche aus", "intent": {"intentName": "de.fhem:SetOnOff", "confidenceScore": 0.33333333333333337}, "siteId": "default", "id": "990db75d-f37f-4ed1-b044-ab05cee2f1f5", "slots": [{"entity": "de.fhem.Device", "value": {"kind": "Unknown", "value": "licht"}, "slotName": "Device", "rawValue": "licht", "confidence": 1.0, "range": {"start": 0, "end": 5, "rawStart": 0, "rawEnd": 5}}, {"entity": "de.fhem.Room", "value": {"kind": "Unknown", "value": "küche"}, "slotName": "Room", "rawValue": "küche", "confidence": 1.0, "range": {"start": 6, "end": 11, "rawStart": 6, "rawEnd": 11}}, {"entity": "OnOffValue", "value": {"kind": "Unknown", "value": "aus"}, "slotName": "Value", "rawValue": "aus", "confidence": 1.0, "range": {"start": 12, "end": 15, "rawStart": 12, "rawEnd": 15}}], "sessionId": "990db75d-f37f-4ed1-b044-ab05cee2f1f5", "customData": null, "asrTokens": [[{"value": "licht", "confidence": 1.0, "rangeStart": 0, "rangeEnd": 5, "time": null}, {"value": "küche", "confidence": 1.0, "rangeStart": 6, "rangeEnd": 11, "time": null}, {"value": "aus", "confidence": 1.0, "rangeStart": 12, "rangeEnd": 15, "time": null}]], "asrConfidence": null, "rawInput": "licht in der küche aus", "wakewordId": null, "lang": null}

Macht bei mir also keinen Unterschied. Ich kann jetzt nur noch ausprobieren, FHEM + Rhasspy auf einem deutschen Debian zu installieren. Weil das aber nicht wenig Aufwand ist, wär's mir vorher aber fast lieber, es würden noch andere das Problem bestätigen.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 13 März 2021, 14:52:46
Betr. das SetAllOff-Ding...:

Wenn ich folgendes publishe:hermes/intent/de.fhem_SetAllOff => {"input": "schalte alle light im aussen", "intent": {"intentName": "de.fhem:SetAllOff", "confidenceScore": 1.0}, "siteId": "Wohnzimmer", "id": null, "slots": [{"entity": "Type", "value": {"kind": "Unknown", "value": "light"}, "slotName": "Type", "rawValue": "lampen", "confidence": 1.0, "range": {"start": 13, "end": 18, "rawStart": 13, "rawEnd": 19}}, {"entity": "de.fhem.Room", "value": {"kind": "Unknown", "value": "aussen"}, "slotName": "Room", "rawValue": "aussen", "confidence": 1.0, "range": {"start": 22, "end": 28, "rawStart": 23, "rawEnd": 29}}], "sessionId": "Wohnzimmer-alexa-80289a9b-7f96-4f19-9574-d026d2b7a9be", "customData": null, "asrTokens": [[{"value": "schalte", "confidence": 1.0, "rangeStart": 0, "rangeEnd": 7, "time": null}, {"value": "alle", "confidence": 1.0, "rangeStart": 8, "rangeEnd": 12, "time": null}, {"value": "light", "confidence": 1.0, "rangeStart": 13, "rangeEnd": 18, "time": null}, {"value": "im", "confidence": 1.0, "rangeStart": 19, "rangeEnd": 21, "time": null}, {"value": "aussen", "confidence": 1.0, "rangeStart": 22, "rangeEnd": 28, "time": null}]], "asrConfidence": null, "rawInput": "schalte alle lampen im aussen", "wakewordId": "alexa", "lang": null}Dieses RHASSPY-Device habe:
defmod rhasspy RHASSPY language=de test
attr rhasspy IODev m2client
attr rhasspy rhasspyIntents SetAllOff=SetAllOff(Room,Type)

und diesen Code:
sub SetAllOff{
my $Raum = shift;# // 'Haus';
my $Typ = shift;# // 'light';
#$Raum = 'Haus' if $Raum eq "Room";
Log3(undef, 3, "Raum: $Raum - Typ: $Typ");
return;
}

bekomme ich diesen Log-Eintrag:
ZitatRaum: aussen - Typ: light
Das sieht für mich erst mal ok aus, was m.E. bedeutet, dass entweder topic/payload jetzt anders strukturiert sind, oder eben das decoding nicht paßt - das ist aber eine andere Baustelle...

Bzgl. UTF-8:
Es scheint so zu sein, dass bei JensS da irgendwo was schief hängt, sonst wäre ja gezeigte die Payload nicht "verbogen" gewesen. Wäre natürlich schön, wir könnten das allgemein mit UTF-8 lösen (und JensS die passende Stelle finden, die das verbiegt), aber falls das auf ein generelles Thema hindeutet, über das noch mehrere stolpern, sollten wir eine Möglichkeit bieten, das notfalls eben über das Modul zu fixen.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 13 März 2021, 14:58:59
Ist bei mir auch so:


2021.03.13 14:58:41.329 5: RHASSPY: [Rhasspy] Parse (IO: rhasspyMQTT2): Msg: hermes/intent/de.fhem_SetAllOff => {"input": "lösche alle light küche", "intent": {"intentName": "de.fhem:SetAllOff", "confidenceScore": 0.5}, "siteId": "default", "id": "efb67fe9-3469-409f-9c93-5050e8c37e2b", "slots": [{"entity": "Type", "value": {"kind": "Unknown", "value": "light"}, "slotName": "Type", "rawValue": "lichter", "confidence": 1.0, "range": {"start": 12, "end": 17, "rawStart": 12, "rawEnd": 19}}, {"entity": "de.fhem.Room", "value": {"kind": "Unknown", "value": "küche"}, "slotName": "Room", "rawValue": "küche", "confidence": 1.0, "range": {"start": 18, "end": 23, "rawStart": 20, "rawEnd": 25}}], "sessionId": "efb67fe9-3469-409f-9c93-5050e8c37e2b", "customData": null, "asrTokens": [[{"value": "lösche", "confidence": 1.0, "rangeStart": 0, "rangeEnd": 6, "time": null}, {"value": "alle", "confidence": 1.0, "rangeStart": 7, "rangeEnd": 11, "time": null}, {"value": "light", "confidence": 1.0, "rangeStart": 12, "rangeEnd": 17, "time": null}, {"value": "küche", "confidence": 1.0, "rangeStart": 18, "rangeEnd": 23, "time": null}]], "asrConfidence": null, "rawInput": "lösche alle lichter in der küche", "wakewordId": null, "lang": null}
2021.03.13 14:58:41.330 5: Parsed value: light for key: Type
2021.03.13 14:58:41.330 5: Parsed value: lösche alle light küche for key: input
2021.03.13 14:58:41.330 5: Parsed value: efb67fe9-3469-409f-9c93-5050e8c37e2b for key: sessionId
2021.03.13 14:58:41.330 5: Parsed value: default for key: siteId
2021.03.13 14:58:41.331 5: Parsed value: 0.5 for key: probability
2021.03.13 14:58:41.331 5: Parsed value: küche for key: Room
2021.03.13 14:58:41.331 5: Parsed value: lösche alle lichter in der küche for key: rawInput
2021.03.13 14:58:41.331 5: Parsed value: SetAllOff for key: intent
2021.03.13 14:58:41.332 5: handleCustomIntent called with SetAllOff key
2021.03.13 14:58:41.332 5: Calling sub:  SetAllOff( "wohnzimmer","light" )
2021.03.13 14:58:41.332 3: Raum: wohnzimmer - Typ: light
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 13 März 2021, 17:13:00
Glaube das Problem gefunden zu haben: Die Parameternamen wurden nämlich im Hash ausgetauscht.

Die Version anbei scheint das Problem nicht mehr zu haben, man muss das Array kopieren, und dann erst die Parameter erstetzen, sonst stehen da einfach die letzten Werte drin...

Das mit dem internen Hash für die ganzen Mappings etc. geht auch voran, der nächste Schritt wäre jetzt, die Kommandos so umzubauen, dass sie auf diesen internen Hash zugreifen; ich bin auch noch nicht sicher, ob er vollständig ist.

Btw.: Es sollte über diesen Mechanismus dann auch leichter sein, sowas wie "mach alle Lichter im Wohnzimmer aus" direkt im Modul umzusetzen (fände ich sinnvoll).
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 14 März 2021, 10:04:59
Zitat von: Beta-User am 13 März 2021, 17:13:00Glaube das Problem gefunden zu haben: Die Parameternamen wurden nämlich im Hash ausgetauscht.

Eine Lösung für welches Problem?

ZitatBtw.: Es sollte über diesen Mechanismus dann auch leichter sein, sowas wie "mach alle Lichter im Wohnzimmer aus" direkt im Modul umzusetzen (fände ich sinnvoll).

Bin immer noch der Meinung, es wäre einfach, dass via FHEM zu lösen (devspec, structure, etc.) und einfach SetOnOff zu nehmen.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 14 März 2021, 10:17:45
Zitat von: drhirn am 14 März 2021, 10:04:59
Eine Lösung für welches Problem?
Das von JensS mit dem "falschen" Raum: Das Problem war, dass die Argumente im RHASSPY-Hash gespeichert waren (als "Namen") und dann bei der ersten Ausführung durch die ermittelten Werte getauscht wurden. Daher hat das beim 2. Mal (mit anderen Werten) nicht mehr funktioniert...
Jetzt wird mit einer Kopie aus dem Hash gearbeitet, damit scheint das Problem gelöst zu sein.

ZitatBin immer noch der Meinung, es wäre einfach, dass via FHEM zu lösen (devspec, structure, etc.) und einfach SetOnOff zu nehmen.
Jein. Bezogen auf den einzelnen Anwendungfall mag das richtig sein, v.a., wenn man die Routinen schon hat bzw. die Strukturen eingerichtet sind.
Ggf. braucht es eben gar keine zusätzlichen Strukturen oder myUtils-Routinen. Wir könnten den "Pseudonamen" "all" (oder "everything" oä.)  zulassen, um dann einfach die Gruppe zu "schalten" (auch: auf 80% stellen, usw. usf.). Ich glaube, das wäre nicht sooo schwierig direkt im Modul umzusetzen, und weil der Code recht generisch sein dürfte, geht das im Ergebnis dann mit einiger Sicherheit auch mit praktisch allen passenden Kommandos. (Aber Rom und so).
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 14 März 2021, 10:23:32
Also wenn ich dich richtig verstehe, müssten wir dann mal alle Geräte finden, die angesprochen werden sollen. Danach rausfinden, ob sich die mit dem gewünschten Befehl schalten lassen. Und dann schalten. Anschließend das ganze wieder von vorne um festzustellen, ob auch alle richtig geschaltet wurden.

Ich glaub immer noch, dass z.B. eine structure sinnvoller wäre. Die kann ich dann - wie mal erwähnt - auch außerhalb von Rhasspy schalten.

Aber, wenn das Modul dann noch cooler wird, unterstütze ich das Vorhaben natürlich sofort :)
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 14 März 2021, 10:35:35
Genau.
Kannst ja mal testweise versuchen, ob der neue Befehl "reinit devicemap" bei dir eine schöne Struktur unter helper/devicemap in das list vom RHASSPY-Device erstellt, die dann Grundlage sein könnte.
(Ist alles noch nicht fertig, aber ggf. kannst du dann erahnen, in welche Richtung meine Überlegungen gehen).

Und klar, das mit den Rückmeldungen ist bei Gruppenanweisungen noch ein separates Thema, aber da fällt uns dann bei @Array>1 dann schon irgendwas ein...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 14 März 2021, 10:42:32

$VAR1 = {
          'lampe2' => {
                        'intents' => {
                                       'SetNumeric' => {
                                                         'maxVal' => '40',
                                                         'cmd' => 'volume',
                                                         'step' => '0.5',
                                                         'type' => 'volume',
                                                         'minVal' => '-60',
                                                         'currentVal' => 'volume'
                                                       },
                                       'GetOnOff' => {
                                                       'valueOff' => 'off',
                                                       'currentVal' => 'state',
                                                       'type' => undef
                                                     },
                                       'MediaControls' => {
                                                            'cmdStop' => 'stop',
                                                            'cmdPlay' => 'play',
                                                            'cmdBack' => 'previous',
                                                            'cmdFwd' => 'next',
                                                            'cmdPause' => 'pause',
                                                            'type' => undef
                                                          },
                                       'GetNumeric' => {
                                                         'currentVal' => 'temperature',
                                                         'type' => 'temperature'
                                                       },
                                       'SetOnOff' => {
                                                       'cmdOff' => 'off',
                                                       'cmdOn' => 'on',
                                                       'type' => undef
                                                     }
                                     }
                      },
          'Channels' => {
                          'bad' => {
                                     'orf zwei' => 'lampe1',
                                     'orf eins' => 'lampe1',
                                     'orf drei' => 'lampe1'
                                   },
                          'küche' => {
                                        'orf drei' => 'lampe1',
                                        'orf eins' => 'lampe1',
                                        'orf zwei' => 'lampe1'
                                      }
                        },
          'rhasspyRooms' => {
                              'schlafzimmer' => {
                                                  'radio' => 'lampe2',
                                                  'lampe' => 'lampe2',
                                                  'licht' => 'lampe2'
                                                },
                              'bad' => {
                                         'radio' => 'lampe1',
                                         'Musik' => 'RXV777',
                                         'deckenlampe' => 'lampe1',
                                         'licht' => 'lampe1'
                                       },
                              'wohnzimmer' => {
                                                'radio' => 'lampe2',
                                                'licht' => 'lampe2',
                                                'lampe' => 'lampe2'
                                              },
                              'küche' => {
                                            'licht' => 'lampe1',
                                            'radio' => 'lampe1',
                                            'deckenlampe' => 'lampe1'
                                          }
                            },
          'Colors' => {
                        'küche' => {
                                      'grün' => 'lampe1',
                                      'blau' => 'lampe1',
                                      'gelb' => 'lampe1',
                                      'rot' => 'lampe1'
                                    },
                        'bad' => {
                                   'grün' => 'lampe1',
                                   'blau' => 'lampe1',
                                   'gelb' => 'lampe1',
                                   'rot' => 'lampe1'
                                 }
                      },
          'RXV777' => {
                        'intents' => {
                                       'SetOnOff' => {
                                                       'cmdOn' => 'on',
                                                       'type' => undef,
                                                       'cmdOff' => 'off'
                                                     },
                                       'MediaControls' => {
                                                            'cmdPause' => 'pause',
                                                            'type' => undef,
                                                            'cmdStop' => 'stop',
                                                            'cmdBack' => 'previous',
                                                            'cmdPlay' => 'play',
                                                            'cmdFwd' => 'next'
                                                          },
                                       'GetOnOff' => {
                                                       'valueOff' => 'off',
                                                       'currentVal' => 'state',
                                                       'type' => undef
                                                     },
                                       'SetNumeric' => {
                                                         'currentVal' => 'volume',
                                                         'minVal' => '0',
                                                         'cmd' => 'volume',
                                                         'maxVal' => '100',
                                                         'type' => 'volume',
                                                         'step' => '10'
                                                       }
                                     }
                      },
          'lampe1' => {
                        'Colors' => {
                                      'rot' => 'rgb FF0000',
                                      'gelb' => 'rgb 00F000',
                                      'blau' => 'rgb 0000FF',
                                      'grün' => 'rgb 00FF00'
                                    },
                        'Channels' => {
                                        'orf zwei' => 'set lampe1 off',
                                        'orf eins' => 'set lampe1 on',
                                        'orf drei' => 'set lampe1 on'
                                      },
                        'intents' => {
                                       'GetNumeric' => {
                                                         'type' => 'brightness',
                                                         'currentVal' => 'brightness'
                                                       },
                                       'SetOnOff' => {
                                                       'cmdOff' => 'off',
                                                       'cmdOn' => 'on',
                                                       'type' => undef,
                                                       'response' => 'Okidoki'
                                                     },
                                       'SetNumeric' => {
                                                         'cmd' => 'brightness',
                                                         'maxVal' => '255',
                                                         'minVal' => '0',
                                                         'currentVal' => 'brightness',
                                                         'map' => 'percent',
                                                         'step' => '1',
                                                         'type' => 'brightness'
                                                       },
                                       'Status' => {
                                                     'response' => 'Die Temperatur in der Küche beträgt',
                                                     'type' => undef
                                                   },
                                       'GetOnOff' => {
                                                       'type' => undef,
                                                       'valueOff' => 'off',
                                                       'currentVal' => 'state'
                                                     },
                                       'MediaControls' => {
                                                            'cmdFwd' => 'next',
                                                            'cmdStop' => 'stop',
                                                            'cmdBack' => 'previous',
                                                            'cmdPlay' => 'play',
                                                            'type' => undef,
                                                            'cmdPause' => 'pause'
                                                          }
                                     }
                      }
        };


Gute Überlegung!

Allerdings müssten wir das immer ausführen, wenn ein Device geändert wird. Wie auch updateSlots. Also dort gleich zusätzlich einbauen?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 14 März 2021, 10:55:37
Jein.

Würde mal folgendes vorschlagen:
- Das ist erst mal optional!
- Wir könnten eine DEF-Option einbauen, damit es beim Start ausgeführt wird?
- Ist die Struktur vorhanden, wird sie dann (wenn es soweit fertig ist) dafür genutzt, die bisherigen Routinen zu "umgehen"
=> testen ist möglich

- dann erst mal sehen, ob man genericDeviceType "ausschlachten" kann, um die Struktur zu füllen.

Dazwischen oder danach dann das "Struktur-Thema"...?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 14 März 2021, 10:59:45
Warum "Jein"? Wenn wir uns darauf verlassen, müssen Änderungen an einem Device ja gleich im helper abgebildet werden. Oder nicht?

Ich komm übrigens langsam auch zu der Ansicht, dass deine Idee mit dem genericDeviceType sehr gut ist.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 14 März 2021, 11:02:32
Na ja, letztlich ist das meistens statisch, und ggf. muss halt der User einen "scan" einleiten, wenn er was ändert oder ergänzt. Wird woanders auch so gemacht (ASC, z.B.)...

Eine NotifyFn wollte ich eigentlich nicht einbauen.
Zitat von: drhirn am 14 März 2021, 10:59:45
Ich komm übrigens langsam auch zu der Ansicht, dass deine Idee mit dem genericDeviceType sehr gut ist.
:)
Dauert halt noch, bis wir dahin kommen...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 14 März 2021, 11:24:53
Zitat von: Beta-User am 14 März 2021, 11:02:32
Na ja, letztlich ist das meistens statisch, und ggf. muss halt der User einen "scan" einleiten, wenn er was ändert oder ergänzt. Wird woanders auch so gemacht (ASC, z.B.)...

Eh. Aber in unserem Fall müsste er bei einer Änderung zwei Sachen ausführen (updateSlots und reinit). Finde ich nicht so schön.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 14 März 2021, 12:09:28
Mittelfristig sollte es ggf. dann "update" mit "slots" "devicemap" und "language" bzw. "all" geben?
Die Teile (anders) zu verketten, wäre kein Problem...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 14 März 2021, 12:11:49
Wäre fast sinnvoll. Oder überhaupt nur "all" ;). Wir müssen nur sicher gehen, dass sowohl der hash, als auch Rhasspy was davon mitbekommen.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 14 März 2021, 12:24:18
Was hattest du bei "setUp"/"setDown" für ein Gerät im Kopf?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 14 März 2021, 13:23:50
...dann vermutlich eher weiter "updateSlots" (mit integriertem reinit devicemap) und reinit language; letzteres ist schon irgendwie was anderes...

setUp war nicht für irgendein konkretes Gerät; im Code tauchte halt bisher irgendwas auf, das dann nach setTarget gewandert ist ("Sollwert"?), von daher ist es halt in der Form drin geblieben. Darf aber gerne auch anders heißen, war halt das, was mit eingefallen ist...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 15 März 2021, 17:34:05
So, anbei mal die nächste Iteration:
Zitat von: Beta-User am 13 März 2021, 17:13:00
Das mit dem internen Hash für die ganzen Mappings etc. geht auch voran, der nächste Schritt wäre jetzt, die Kommandos so umzubauen, dass sie auf diesen internen Hash zugreifen; ich bin auch noch nicht sicher, ob er vollständig ist.

Soweit ich das bisher beurteilen kann, scheint das - nach einigen kleineren Erweiterungen an der Struktur - zu klappen. Die eine oder andere Kleinigkeit ist mir dann auch noch aufgefallen, Basis war deine 0.4.4beta von gestern.
Die interne Struktur wird jetzt verwendet, wenn sie vorhanden ist, was derzeit bedeutet, dass man das aktiv Anschubsen muss. Finde ich für Testzwecke erst mal ganz gut.
Wenn das soweit ok ist und geprüft, könnte man dann die Hash-Generierung in firstInit() mit aufrufen (da sind alle Attribute auch von nachfolgenden defines vorhanden) und dann noch in "set ... updateSlots" (dort dann ziemlich vorne!) mit reinknödeln, das scheint ja eigentlich nur miteinander Sinn zu machen.

Hat dann aber zur Folge, dass Rhasspy dann die englischen "type" (also "brightness" statt "Helligkeit" zu sehen bekommt, selbst, wenn da heute im Mapping der deutsche Begriff steht. Weiß nicht, ob das Schwierigkeiten verursacht.

Next steps (nach "Zwangshash") wären dann:
- Ausbau der nicht mehr benötigten Code-Teile
- Auswertung von genericDeviceType & Co...



Betr. des Codepage-Problems:
Habe mal die Option reigeknödelt, "encoding" in der DEF anzugeben, also z.B. "encoding=cp-1252". Das gab aber Schwierigkeiten mit der de-cfg, daher habe ich das dort hart in UTF-8 belassen...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 15 März 2021, 17:47:21
Super, werde ich gleich einbauen.

Ich hab derzeit die meisten Probleme mit Set- und GetNumeric.

Bei GetNumeric springen wir z.B. nie in das else von hier:

    if ($mappingType eq 'setTarget'
            || $mappingType=~ m{\A$internal_mappings->{regex}->{setTarget}\z}xim
            || $mappingType=~ m{\A$de_mappings->{regex}->{setTarget}\z}xim) {
        $response = $hash->{helper}{lng}->{Change}->{responses}->{setTarget};
    }
    else {
        $response =
            $hash->{helper}{lng}->{responses}->{Change}->{$mappingType}
        //  $hash->{helper}{lng}->{responses}->{Change}->{$de_mappings->{ToEn}->{$mappingType}}
        //  $hash->{helper}{lng}->{res ponses}->{Change}->{$type}
        //  $hash->{helper}{lng}->{responses}->{Change}->{$de_mappings->{ToEn}->{$type}};
        ;
        #my $isNumber = looks_like_number($value);
        $response = $response->{looks_like_number($value)} if ref $response eq 'HASH';
   }


Aber ich schreib das alles noch genau zusammen und liefer die DEF und Payloads.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 15 März 2021, 18:04:40
Hmm, auf die Schnelle scheint mir da die Logik falsch herum zu sein:

Erst checken, ob wir was spezifisches wissen (heutiges else), dann das etwas unspezifischere (heutiger if-Fall) und zu letzt eben die Auffanglösungen.

Ergäbe zum Testen:
    $response =
        $hash->{helper}{lng}->{Change}->{responses}->{$mappingType}
        //  $hash->{helper}{lng}->{Change}->{responses}->{$de_mappings->{ToEn}->{$mappingType}}
        //  $hash->{helper}{lng}->{Change}->{responses}->{$type}
        //  $hash->{helper}{lng}->{Change}->{responses}->{$de_mappings->{ToEn}->{$type}};
        ;
        $response = $response->{looks_like_number($value)} if ref $response eq 'HASH';

    if (!defined $response && (
            $mappingType=~ m{\A$internal_mappings->{regex}->{setTarget}\z}xim
            || $mappingType=~ m{\A$de_mappings->{regex}->{setTarget}\z}xim)) {
        $response = $hash->{helper}{lng}->{Change}->{responses}->{setTarget};
    }
    $response = $response            #we already are done? ...

Bin aber auf die Schnelle nicht sicher, ob das nicht eine neue Lücke in der Logik ergibt...

EDIT: da war auch der Hash noch nicht umgestellt gewesen, jetzt müsste es eher passen...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 16 März 2021, 10:41:08
Scheint der richtige Weg gewesen zu sein, auch, wenn es im Detail dann wieder "seltsam" war...

In der de-cfg fehlte  noch das response-mapping für "setTarget".

Wie dem auch sei, jetzt sollte alles wieder zusammenpassen (?)...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 16 März 2021, 12:22:04
Ok, GitHub ist akutell. Danke!

Ich hab gerade ein Verständnisproblem:
Wenn wir von der Annahme ausgehen, dass man bei einem Gerät Soll- und Ist-Temperatur ablesen kann. Wie könnten wir dann folgenden Satz auflösen?

"Wie ist die Temperatur der Heizung"

Die Mappings wären dann ja z.B.:


GetNumeric:currentVal=desired-temp,type=temperature
GetNumeric:currentVal=measured-temp,type=temperature


... In dem man SetTarget nimmt z.B. Ist dann nur ein Rhasspy-Problem.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 16 März 2021, 12:45:27
Ach, und weil ich gerade darüber gestolpert bin:

Gab's ein Device mit dem Reading temperature und einem entsprechenden GetNumeric Mapping, konnte man - glaube ich - fragen "wie warm ist es im schlafzimmer". Wäre sehr praktisch.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 16 März 2021, 13:00:11
Verständnisfrage meinerseits: Hat das bisher (bis V. 0.2.x) geklappt :o ?

Auf so eine unspezifische Frage sollte man dann den Messwert zurückgeben ;) . Wer den Sollwert haben will, sollte gezielt fragen ;D .

Im Ernst: Auf die Schnelle neige ich dazu, für Heizungsgeräte einen weiteren type (desired-temp) zuzulassen, wobei ich mir nicht sicher bin, ob das nicht schon geht. Jedenfalls sieht der Hash ganz ok aus, wenn ich das hier angebe:SetNumeric:currentVal=desired-temp,minVal=0,maxVal=255,cmd=desired-temp,step=1,type=desired-temp

Die Frage wäre dann eher, ob es Sinn macht, diesen verbreiteten Type in den Standard aufzunehmen (und v.a. auch eindeutige Rückmeldesätze vorzuhalten), und wie dann ggf. mit heutigen SetNummeric-Mappings umzugehen sein soll. Ich neige dazu, da ggf. keine Rücksicht auf bestehendes zu nehmen, v.a., wenn es bisher keine klare Antwort auf die Frage gab...

Habe auch noch etwas an der Komplexitäts-Schraube gedreht, weiß aber mal wieder nicht, ob das alles tut wie es soll (sieht aber so aus).

Zitat von: drhirn am 16 März 2021, 12:45:27
Ach, und weil ich gerade darüber gestolpert bin:

Gab's ein Device mit dem Reading temperature und einem entsprechenden GetNumeric Mapping, konnte man - glaube ich - fragen "wie warm ist es im schlafzimmer". Wäre sehr praktisch.
Das sollte - bei entsprechender Rhasspy-Zuarbeit - klappen, oder täuscht mich das?
Zumindest bekomme ich auf diese - etwas verbogene - Frage eine Antwort mit Komma:
hermes/intent/de.fhem_GetNumeric {"input": "Helligkeit deckenlampe im bad", "intent": {"intentName": "de.fhem:GetNumeric", "confidenceScore": 1.0}, "siteId": "wohnzimmer", "id": null, "slots": [{"entity": "Type", "value": {"kind": "Unknown", "value": "temperature"}, "slotName": "Type", "rawValue": "helligkeit", "confidence": 1.0, "range": {"start": 0, "end": 10, "rawStart": 0, "rawEnd": 10}}, {"entity": "de.fhem.Device", "value": {"kind": "Unknown", "value": "lampe"}, "slotName": "Device", "rawValue": "deckenlampe", "confidence": 1.0, "range": {"start": 11, "end": 22, "rawStart": 11, "rawEnd": 22}}, {"entity": "de.fhem.Room", "value": {"kind": "Unknown", "value": "wohnzimmer"}, "slotName": "Room", "rawValue": "bad", "confidence": 1.0, "range": {"start": 26, "end": 29, "rawStart": 26, "rawEnd": 29}}], "sessionId": "wohnzimmer-snowboy-b6d9df29-fb48-48b5-b0bb-1658e229e8dd", "customData": null, "asrTokens": [[{"value": "temperature", "confidence": 1.0, "rangeStart": 0, "rangeEnd": 10, "time": null}, {"value": "deckenlampe", "confidence": 1.0, "rangeStart": 11, "rangeEnd": 22, "time": null}, {"value": "im", "confidence": 1.0, "rangeStart": 23, "rangeEnd": 25, "time": null}, {"value": "bad", "confidence": 1.0, "rangeStart": 26, "rangeEnd": 29, "time": null}]], "asrConfidence": null, "rawInput": "helligkeit deckenlampe im bad", "wakewordId": "snowboy", "lang": null}
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 16 März 2021, 13:08:29
Zitat von: Beta-User am 16 März 2021, 13:00:11
Verständnisfrage meinerseits: Hat das bisher (bis V. 0.2.x) geklappt :o ?

Nein. Ist ein Feature-Request ;)

ZitatAuf so eine unspezifische Frage sollte man dann den Messwert zurückgeben ;) . Wer den Sollwert haben will, sollte gezielt fragen ;D .

Hehe, ja, eh. Ich sehe aber keine Möglichkeit, das in Rhasspy abzubilden. Außer wir nehmen einen extra type, wie du schreibst.

ZitatDie Frage wäre dann eher, ob es Sinn macht, diesen verbreiteten Type in den Standard aufzunehmen (und v.a. auch eindeutige Rückmeldesätze vorzuhalten), und wie dann ggf. mit heutigen SetNummeric-Mappings umzugehen sein soll.

Ja, können wir gerne machen.

ZitatZumindest bekomme ich auf diese - etwas verbogene - Frage eine Antwort mit Komma:

Ja, ist klar. Hast ja auch ein Device angegeben. Das fehlt in meinem Satz absichtlich.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 16 März 2021, 13:27:20
Zitat
Hehe, ja, eh. Ich sehe aber keine Möglichkeit, das in Rhasspy abzubilden. Außer wir nehmen einen extra type, wie du schreibst.
Na ja, was man versuchen könnte, wäre zu schauen, ob es zwei "temperature"-Type Readings gibt, und dann mit "temperature"/"measured-temp"=>"temperature" und dem anderen als "desired-temp" zu antworten (neue "combined_temps"-Antwort).
In "setze"-Richtung sollte es sowieso nur eine Möglichkeit geben, mit Soll-Temperaturen umzugehen (von gewissen Doppelungen wie in ZWave abgesehen).
(aber vermutlich nicht mehr heute, ist evtl. kompliziert...)

ZitatJa, können wir gerne machen.
Sollte kein Hexenwerk sein und schadet m.E. auch nicht. Magst du das versuchen?

ZitatJa, ist klar. Hast ja auch ein Device angegeben. Das fehlt in meinem Satz absichtlich.
OK, soweit so klar, war ein feature-request ;D ....
=> schreib's mal auf die Liste
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 16 März 2021, 14:12:51
Zitat von: drhirn am 16 März 2021, 13:08:29
Ja, ist klar. Hast ja auch ein Device angegeben. Das fehlt in meinem Satz absichtlich.
Hmm, das müßte früher mal funktioniert haben, oder ich hatte es (fast) nebenbei repariert. Jedenfalls war bei der Hash-Variante noch ein Fehler drin, der jetzt raus ist.
Will sagen: Jetzt sollte die Temperaturabfrage in einem Raum klappen, wenn es irgendwo ein "temperature"-Mapping dafür gibt...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 16 März 2021, 14:39:57
Pfoahhh, funktioniert.


2021.03.16 14:38:20.538 5: RHASSPY: [Rhasspy] Parse (IO: rhasspyMQTT2): Msg: hermes/intent/de.fhem_GetNumeric => {"input": "temperature im wohnzimmer", "intent": {"intentName": "de.fhem:GetNumeric", "confidenceScore": 1.0}, "siteId": "default", "id": "8a9af3fa-10c9-4815-90f7-f698fadfb7c2", "slots": [{"entity": "Type", "value": {"kind": "Unknown", "value": "temperature"}, "slotName": "Type", "rawValue": "wie warm ist es", "confidence": 1.0, "range": {"start": 0, "end": 11, "rawStart": 0, "rawEnd": 15}}, {"entity": "de.fhem.Room", "value": {"kind": "Unknown", "value": "wohnzimmer"}, "slotName": "Room", "rawValue": "wohnzimmer", "confidence": 1.0, "range": {"start": 15, "end": 25, "rawStart": 19, "rawEnd": 29}}], "sessionId": "8a9af3fa-10c9-4815-90f7-f698fadfb7c2", "customData": null, "asrTokens": [[{"value": "temperature", "confidence": 1.0, "rangeStart": 0, "rangeEnd": 11, "time": null}, {"value": "im", "confidence": 1.0, "rangeStart": 12, "rangeEnd": 14, "time": null}, {"value": "wohnzimmer", "confidence": 1.0, "rangeStart": 15, "rangeEnd": 25, "time": null}]], "asrConfidence": null, "rawInput": "wie warm ist es im wohnzimmer", "wakewordId": null, "lang": null}
2021.03.16 14:38:20.539 5: Parsed value: temperature for key: Type
2021.03.16 14:38:20.539 5: Parsed value: wohnzimmer for key: Room
2021.03.16 14:38:20.539 5: Parsed value: 1 for key: probability
2021.03.16 14:38:20.540 5: Parsed value: default for key: siteId
2021.03.16 14:38:20.540 5: Parsed value: 8a9af3fa-10c9-4815-90f7-f698fadfb7c2 for key: sessionId
2021.03.16 14:38:20.541 5: Parsed value: GetNumeric for key: intent
2021.03.16 14:38:20.541 5: Parsed value: temperature im wohnzimmer for key: input
2021.03.16 14:38:20.541 5: Parsed value: wie warm ist es im wohnzimmer for key: rawInput
2021.03.16 14:38:20.542 5: handleIntentGetNumeric called
2021.03.16 14:38:20.543 4: Devices in Room wohnzimmer: Heizung
2021.03.16 14:38:20.543 4: Devices outside Room wohnzimmer:
2021.03.16 14:38:20.543 5: Heizung
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 16 März 2021, 15:08:49
 ;D
Warum so überrascht?!?

Das ganze hat einen Haken: Der Zugriff erfolgt "zufällig", da über den Hash:
for my $devs (keys %{$hash->{helper}{devicemap}{devices}}) {
Man kann daher nie sicher vorhersagen, welches von mehreren passenden Devices geliefert wird (bzw. eigentlich: in welcher Reihenfolge sie in den Zielarray landen).

Könnte man an dieser Stelle per sort-Anweisung(en) verhindern, dieses Thema des zufälligen Zugriffs taucht aber (uU) auch an anderer Stelle auf:
if ($fromHash) {
        $matchedMapping = $hash->{helper}{devicemap}{devices}{$device}{intents}{$intent}{type};

(Kann aber sein, dass auch der Hash nur einfach gefüllt werden kann, damit wäre es dann so, dass effektiv z.B. das letzte GetNummeric-temperature-Mapping im Hash landet.)
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 16 März 2021, 15:13:08
Gar nicht überrascht. Das hätte Begeisterung ausdrücken sollen. Mir fehlt da einfach das "Party"-Emoticon ;)

Naja, wenn wir jetzt beim Beispiel Heizung bleiben, ist eher nicht wahrscheinlich, dass es mehrere Geräte mit dem selben Mapping im selben Raum gibt. Man müsste also nur das nehmen, das im jeweiligen Raum vorkommt.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 16 März 2021, 15:28:31
OK, das laß' ich gelten ;D 8) ;D ...

Es kann schon vorkommen, dass man mehrere Geräte im selben Raum hat, die dieselben Mappings haben können. Ist nur die Frage, ob das sinnvoll ist, das alles unter RHASSPY-Kontrolle zu bekommen. Beispiel:
Ein Raum, zwei Heizkörper (mit regelbarem Thermostat), ein Raumtemperatursensor oder Wand-Thermostat => 3 Ist-Temperaturen (optimalerweise: Identisch), 2-3 Soll-Temperaturen.
In meinen Settings wäre es egal, weil der Raumsensor den gemessenen Wert wiedergibt und es egal ist, an welchen ich die Zieltemp übermittle (gepeerte CUL_HM). Für ein ZWave-Setup sieht das aber uU. "etwas" anders aus, v.a., wenn man die neuen Optionen noch nicht nutzt, dem/n Thermostat/en die gemessene Temp des Raumsensors unterzuschieben...

Schon mit den "althergebrachten" expliziten rhasspyMappings muss man aufpassen, was man macht, aber lustig wird das dann, wenn wir in Richtung automatische Erkennung (aus genDevType) gehen...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 16 März 2021, 15:33:01
Dein Beispiel ist genau mein Beispiel. Sehe ich nicht als Problem.

Aber ja, das mit genericDeviceType wird dann spannend. Aber da können wir das Modul ja rückfragen lassen ;)
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 16 März 2021, 16:34:10
Mir machen gerade folgende beiden Sätze sorgen:

"Stell die Heizung wärmer"
"Stell die Heizung höher"

V.a., wenn man auch noch z.B. eine Rollo hat:

"Stell den Rollo höher"

Ich kann die Rhasspy-Sentences nicht so bauen, dass Rhasspy unterscheiden kann, was gemeint ist.

stell $Device{Device} höher{Change:tempUp}
ist der gleiche gesprochene Satz wie
stell $Device{Device} höher{Change:setUp}

Weißt du, was ich meine?

Das Modul müsste entscheiden, was beim übermittelten Device zu tun ist. Führt uns wieder zu genericDeviceType. Oder wieder zurück zu {Type}.

Oder hast du das eh schon berücksichtigt?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 16 März 2021, 16:55:16
Hast du das Beispiel mal praktisch durchgespielt?

Wenn ich auf den Code starre, meine ich, dass $device immer durchschlägt, und dann eben "notfalls" ein nicht zum $type passendes Mapping genommen wird... (Möglicherweise geht es aber dann später schief, wenn "Change" relevant wird, aber eigentlich ist das dann wieder losgelöst von $type und es wird nur die Richtung ermittelt...?)

Ansonsten müßten wir überlegen, ob diese These richtig ist:
ZitatIch kann die Rhasspy-Sentences nicht so bauen, dass Rhasspy unterscheiden kann, was gemeint ist.

Und nein, ich habe nicht unbedingt absichtlich alles mögliche berücksichtigt, so weit habe ich das Rhasspy-Universum noch nicht durchflogen :P .

EDIT:
These erhärtet, Device schlägt wohl durch, danach interessiert nur noch die Richtung:
hermes/intent/de.fhem_SetNumeric {"input": "mach radio lauter", "intent": {"intentName": "de.fhem:SetNumeric", "confidenceScore": 0.6666666666666667}, "siteId": "default", "id": "cf521ed9-8de4-4bc2-82ae-77ed9a854e0c", "slots": [{"entity": "de.fhem.Device", "value": {"kind": "Unknown", "value": "radio"}, "slotName": "Device", "rawValue": "radio", "confidence": 1.0, "range": {"start": 5, "end": 10, "rawStart": 5, "rawEnd": 10}}, {"entity": "Change", "value": {"kind": "Unknown", "value": "tempUp"}, "slotName": "Change", "rawValue": "tempUp", "confidence": 1.0, "range": {"start": 11, "end": 17, "rawStart": 11, "rawEnd": 17}}], "sessionId": "cf521ed9-8de4-4bc2-82ae-77ed9a854e0c", "customData": null, "asrTokens": [[{"value": "mach", "confidence": 1.0, "rangeStart": 0, "rangeEnd": 4, "time": null}, {"value": "radio", "confidence": 1.0, "rangeStart": 5, "rangeEnd": 10, "time": null}, {"value": "tempUp", "confidence": 1.0, "rangeStart": 11, "rangeEnd": 17, "time": null}]], "asrConfidence": null, "rawInput": "mach das radio lauter", "wakewordId": null, "lang": null}
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 17 März 2021, 13:23:39
Kann's gerade nicht testen weil siehe weiter unten. Aber sieht so aus, als ob's wirklich funktioniert.

Größeres Problem: Das Sammeln von Devices, Rooms, etc. funktioniert nicht richtig. Und zwar dann nicht mehr, wenn ich davor ein reinit devicemap aufgerufen habe.

Ein updateSlots liefert mir dann
Updating Rhasspy Slots with data (de): {"de.fhem.Color":["grün","gelb","blau","rot"],"de.fhem.Device":["lampe1","Heizung","lampe2","RXV777"],"de.fhem.MediaChannels":["orf eins","orf zwei","orf drei"],"de.fhem.NumericType":[null],"de.fhem.Room":["küche","bad","wohnzimmer","schlafzimmer"]}

Device und NumericType hat da also Probleme.

Bei Device liegt das daran, dass die rhasspyNames nicht im $hash vorkommen. Weil sie in _analyze_rhassypAttr auch gar nicht rein geschrieben werden so wie ich das sehe. Hat das einen speziellen Grund?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 17 März 2021, 14:25:39
Zitat von: drhirn am 17 März 2021, 13:23:39
Bei Device liegt das daran, dass die rhasspyNames nicht im $hash vorkommen. Weil sie in _analyze_rhassypAttr auch gar nicht rein geschrieben werden so wie ich das sehe. Hat das einen speziellen Grund?
Na ja, die Frage ist, wie der Hash sinnvollerweise ausgewertet werden kann. Und da die "Names" nicht unbedingt eindeutig sind, macht es m.E. nicht den großen Sinn, dazu eine separate Struktur anzulegen. Ziel sollte eigentlich sein, über die Struktur immer auf schnelle Weise zu einem eindeutigen Ergebnis zu kommen. Daher kann es auch sein, dass das ganze im Bereich der Colors etc. noch zu einfach gestrickt ist... (kann sein bedeutet wohl eher: vermutlich ist...).

Die Art und Weise, wie die vorhandene Struktur ausgewertet wurde, war aber in jedem Fall fehlerhaft (auch noch zu Set/GetNumeric). Das sollte jetzt beides behoben sein.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 17 März 2021, 14:31:37
Hmm, dann müssten wir für updateSlots ein neues Argument einführen, dass RHASSPY_allRhasspy[...] auf jeden Fall anweist, selbst zu suchen, anstatt den Hash zu nehmen.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 17 März 2021, 14:41:46
...auf gar keinen Fall ;D ...

Dann wären die "fremden" Infos ja weg (oder wir gehen von unterschiedlichen Infos aus, je nach Auswertung => auch nicht gut!)...

Ablauf muss sein: updateSlots initiiert Neueinlesen des Hashes, danach wird der als Grundlage genommen.
Daher muss er alles enthalten, was erforderlich ist (vermutete Lücken: siehe vorhin), und dann auch die Auswertung (für den Versand an Rhasspy) so sein, dass alles drin ist.
Wie gesagt: zwei Bugs habe ich gefunden, für den Moment sollte es wieder vollständig sein, was jetzt aus dem Hash gelesen wird...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 17 März 2021, 14:49:35
Okeoke  ;D

Mir ist aufgefallen, dass man reinit devicemap nach einem Neustart explizit aufrufen muss. Sonst ist der Hash leer. Ist das Absicht?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 17 März 2021, 15:18:07
Zitat von: drhirn am 17 März 2021, 14:49:35
Mir ist aufgefallen, dass man reinit devicemap nach einem Neustart explizit aufrufen muss. Sonst ist der Hash leer. Ist das Absicht?
Zitat von: Beta-User am 15 März 2021, 17:34:05
[....] Die interne Struktur wird jetzt verwendet, wenn sie vorhanden ist, was derzeit bedeutet, dass man das aktiv Anschubsen muss. Finde ich für Testzwecke erst mal ganz gut.
Wenn das soweit ok ist und geprüft, könnte man dann die Hash-Generierung in firstInit() mit aufrufen (da sind alle Attribute auch von nachfolgenden defines vorhanden) und dann noch in "set ... updateSlots" (dort dann ziemlich vorne!) mit reinknödeln, das scheint ja eigentlich nur miteinander Sinn zu machen.

Hat dann aber zur Folge, dass Rhasspy dann die englischen "type" (also "brightness" statt "Helligkeit" zu sehen bekommt, selbst, wenn da heute im Mapping der deutsche Begriff steht. Weiß nicht, ob das Schwierigkeiten verursacht.

Next steps (nach "Zwangshash") wären dann:
- Ausbau der nicht mehr benötigten Code-Teile
- Auswertung von genericDeviceType & Co...
Die Bedingung ist aus meiner Sicht noch nicht hinreichend verifiziert ;) . Was man (recht einfach) tun könnte, wäre die Hash-Generierung (etc.) automatisch zu machen, wenn z.B. "usehash=1" in der DEF angegeben ist (parseParams ist was sehr hilfreiches, oder...?).
Wenn wir einfachere Testmöglichkeiten haben wollen, müßten wir auch eine Option anbieten, nach dem Testen im Echtsystem dann auch wieder den Hash zu löschen...

Ich habe aber derzeit keine Ahnung, ob das z.B. für JensS derzeit relevant ist. @JensS: Ich vermute, du nutzt die Variante, die mit deinen myUtils wieder gut umgehen kann?
Hast du Optionen zum Testen, oder ist das jedesmal im Hauptsystem und daher aufwändig zu wechseln?



@drhirn:
Was anderes noch. Es gibt im Hash jetzt teilweise eine Ebene zu viel (unter intents), nämlich - soweit ich das bisher überblicken kann - immer dann, wenn Set/GetNumeric im Spiel ist. Das hat mit dem leeren type zu tun und sieht irgendwie unschön aus, selbst wenn es funktioniert...
Daher die Frage: Ist es richtig, dass man diese Art der Unterstruktur nur bei diesen beiden intents benötigt? Oder kann es sowas auch bei [SG]etOnOff geben?

Anders gesagt: Ich fürchte, wir sind noch nicht ganz soweit...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 17 März 2021, 16:57:15
Ja, ich habe nur das Produktivsystem und bin daher nur begrenzt leidenfähig. Ich nutze die Version aus meinem Fork. https://github.com/jens-schiffke/fhem-rhasspy/blob/master/10_RHASSPY.pm (https://github.com/jens-schiffke/fhem-rhasspy/blob/master/10_RHASSPY.pm)
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 17 März 2021, 16:59:03
Ach, entschuldige! Mein Hirn...

Jens verwendet - soweit ich das verstanden habe - immer sein Produktiv-System. Deswegen hätte ich mal um die Custom Intents gebeten. Damit ich die testen kann.

Wenn ich dich richtig verstanden habe, meinst du das hier?

'RXV777' => {
                                       'intents' => {
                                                      'SetNumeric' => {
                                                                        'volume' => {
                                                                                      'type' => 'volume',
                                                                                      'currentVal' => 'volume',
                                                                                      'step' => '10',
                                                                                      'maxVal' => '100',
                                                                                      'cmd' => 'volume',
                                                                                      'minVal' => '0'
                                                                                    }
                                                                      },
                                                      'MediaControls' => {
                                                                           '' => {
                                                                                   'cmdBack' => 'previous',
                                                                                   'cmdPause' => 'pause',
                                                                                   'cmdStop' => 'stop',
                                                                                   'cmdFwd' => 'next',
                                                                                   'cmdPlay' => 'play',
                                                                                   'type' => undef
                                                                                 }
                                                                         },
                                                      'GetOnOff' => {
                                                                      '' => {
                                                                              'currentVal' => 'state',
                                                                              'type' => undef,
                                                                              'valueOff' => 'off'
                                                                            }
                                                                    },
                                                      'SetOnOff' => {
                                                                      '' => {
                                                                              'cmdOn' => 'on',
                                                                              'cmdOff' => 'off',
                                                                              'type' => undef
                                                                            }
                                                                    }
                                                    },
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 17 März 2021, 17:19:49
Einige CustomIntents sind im Rhasspy-Thread veröffentlicht. Zum Testen der Übergabe in und von der sub, erstellt besser einen speziellen Intent, der alle Möglichkeiten abbildet und Logs ausgibt.
Wobei mir nicht klar ist, weshalb man alles testen muss.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 17 März 2021, 17:28:43
Nevermind, mir geht auch hin und wieder was raus...

Zeigt aber, dass es wichtig wäre, erst mal - soweit als möglich - Kompabilität und eine Art Testmodus anzubieten.

Jens ist halt noch ganz in der "alten Welt" verhaftet. Ich _glaube_, dass es relativ gefahrlos und unaufwändig wäre, erst mal den Schritt auf die "no-Hash"-Variante mit dem aktuellen Modul zu gehen. Alternativ könntest du (ungetestet...) das Modul auch umbenennen und nach einer sehr kleinen Änderung des Namens der Initialize-Funktion sogar beides parallel betreiben, wobei dann sinnvollerweise eine andere fhemId und einen anderen Präfix gesetzt werden sollte. Dann könntest du das eine oder andere auch so testen (allerdings zu dem Preis, dass ggf. zusätzliche Attribute erforderlich werden).
Bei Interesse schreibe ich gerne, wie das geht, zumindest bei meinen Tests zu Twilight habe ich das auch so gemacht...

@Jens (bzw. ggf. weitere Tester): Für eine Rückmeldung, ob der Aufwand aus deiner/eurer Sicht Sinn macht, wäre ich dir/euch sehr verbunden, eine Anleitung/eine entsprechend angepaßte Datei kann ich gerne liefern...

Alternative:
Testsystem aufbauen und ggf. (z.B. mit FHEM2FHEM) einen Teil "clonen" und dann in dem Testsystem (ebenfalls mit anderer fhemId) eben die "neue Welt" austesten.

Leider kann ich im Moment nicht wirklich sicher sagen, wie stabil das alles ist. Meine Tests sehen zwar ok aus, sind aber bisher nicht wirklich umfangreich (ich will eigentlich erst zumindest einen Teil der genericDeviceType-Geschichten "ausschlachten" können).
Da fällt mir ein: Es sollte eine Option geben, dass RHASSPY die "tpischen Attribute" ggf. selbst in die globalen (? oder user-) Attribute einfügt, falls sie nicht da sind...
(Wenn das fertig wäre, könnte man RHASSPY ggf. auch in die Sprachsteuerungs-attrTemplate mit aufnehmen, was ggf. die Ersteinrichtung neuer Devices vereinfachen kann).

Zitat von: JensS am 17 März 2021, 17:19:49
Einige CustomIntents sind im Rhasspy-Thread veröffentlicht. Zum Testen der Übergabe in und von der sub, erstellt besser einen speziellen Intent, der alle Möglichkeiten abbildet und Logs ausgibt.
Wobei mir nicht klar ist, weshalb man alles testen muss.
Was die Custom-Geschichte angeht, meine ich, dass man ggf. nur noch checken müßte, ob der angeorderte HASH verwertbar ist; da bin ich bisher schlicht nicht dazu gekommen, und bisher gab es auch relativ wenig Bedarf, überhaupt was anzufordern. Aber das mit den "Klatrextelementen" sollte ja jetzt gehen, und an der Stelle sollten auch keine Änderungen mehr kommen.

Auch am Sprach-"hash" dürfte das meiste erledigt sein, ggf. würde ich nur noch überlegen, ob man eine Variante baut, die dann erlaubt, die eigenen von den default-Sätzen zu trennen (und dann den konsolidierten Hash als Grundlage nimmt).

Von daher ginge es jetzt erst mal darum, die Struktur des "devicemap"-Hashes zu finalisieren und dann zu testen, ob das alles klappt, wie es soll. Dafür wären Tester sehr willkommen (zumindest, sobald das mit dem folgenden geklärt ist und in der Basis läuft...)



Ja, gemeint war diese Zwischenstufe
Zitat{
  '' => {
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 17 März 2021, 17:54:00
Jens ist in der Welt verankert, die funktioniert.  ;)
Danke für das Angebot aber von weiteren Teststellungen sehe ich ab.
Generell ist die Nutzung von Hash eine gute Sache, wenn man einen großen Dachboden bzw. Speicher hat.
Die Geräte sind alle in %defs und können zur Laufzeit abgerufen werden. Im "alten Modul" wurde die JSON-Message bereits in einen Hash geladen - also für mich ist das kein Quantensprung.
Die Entkopplung der Begriffe in eine Sprachdatei finde ich gut, sollte aber eindeutig und gut verständlich sein.
Insgesamt begrüße ich die Modernisierung. Sie sollte halt funktionieren und den User nicht einschränken.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 17 März 2021, 18:09:21
Zitat von: Beta-User am 17 März 2021, 17:28:43
Ja, gemeint war diese Zwischenstufe

Ahh, hat ein bisschen gedauert. Mein Hirn... ;)

Ja, nein, mir fällt jetzt spontan kein Intent ein, der mehrfach Sinn machen würde. Außer eben Get/SetNumeric.

Aber wir können bei den anderen Intents ja einfach einen Platzhalter nehmen wenn das einfacher ist.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 17 März 2021, 18:17:57
Zitat von: drhirn am 17 März 2021, 18:09:21
Ja, nein, mir fällt jetzt spontan kein Intent ein, der mehrfach Sinn machen würde. Außer eben Get/SetNumeric.

Aber wir können bei den anderen Intents ja einfach einen Platzhalter nehmen wenn das einfacher ist.
Muss mal schauen, was da wie Sinn macht; vermutlich ist es dann einfacher, diese beiden halt separat abzuarbeiten bzw. einen eigenen Zweig dafür vorzuhalten.

@JensS:
Verständliche Position. Ich empfinde das bisher (und vermutlich auch in Zukunft) auch nicht als funktionalen Quantensprung, wenn man ein funktionierendes System hat und weiß, wo/wie man die Sätze anpassen kann, wenn man Bedarf sieht. Das ganze "beglückt" eher neue User...
Sehe zwar nicht, wo (evtl. abgesehen von dem Trigger-Thema, das aber auch weitgehend gelöst sein sollte) jetzt Einschränkungen wären, aber vermutlich übersehe ich mal wieder was.
Bzgl. der Eindeutigkeit/Verständlichkeit der Sprachdatei: Falls es Vorschläge gibt: her damit...
MAn. ist es jetzt "erträglich" - es gibt einen halbwegs aussagekräftigen "Label" und eine recht flache Struktur samt Beispielen, so dass man das m.E. jetzt recht gut selbst anpassen (oder übersetzen) könnte, und die Rückmeldungen sind jetzt auch etwas spezifischer, an welcher Stelle ggf. der "finde mein Device"-Prozess nicht geklappt hat (was aber ja sowieso die Ausnahme sein sollte).
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag 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.

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?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 18 März 2021, 12:02:12
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).
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 18 März 2021, 12:30:36
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?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 18 März 2021, 12:55:53
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 ;) ).
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 18 März 2021, 13:32:57
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)
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 18 März 2021, 18:19:55
Da sind alle meine sentence-files: https://github.com/drhirn/fhem-rhasspy/tree/0.4.4beta/sentences
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 18 März 2021, 21:23:25
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...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 19 März 2021, 08:54:27
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.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 19 März 2021, 09:07:50
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
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag 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 ;)

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.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 19 März 2021, 10:50:29
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 (https://forum.fhem.de/index.php/topic,119679.0.html) 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 (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.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 19 März 2021, 11:14:50
Zitat von: Beta-User am 19 März 2021, 10:50:29
Zu meinen ersten Erfahrungen mit der App hatte ich hier (https://forum.fhem.de/index.php/topic,119679.0.html) 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.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 19 März 2021, 11:36:29
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.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 19 März 2021, 11:42:01
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 (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.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 19 März 2021, 11:50:35
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?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 19 März 2021, 11:57:20
Zitat von: Beta-User am 19 März 2021, 11:42:01
Kann sein, dass das durch den Kommentar kommt, das scheint das ? : durcheinanderzubringen. (to be verified).
Habe den mal verschoben.

Das war's nicht ;)

Aber die Sache mit dem Status funktioniert. Danke!
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 19 März 2021, 12:13:48
Zitat von: drhirn am 19 März 2021, 11:50:35
Ist auch mir zu kompliziert. Ich kann's nicht mal mehr dokumentieren.
"mehr" kommt mir deplaziert vor: Das war mal bei Komplexität 55 oder so, jetzt sind wir "nur noch" bei 41 8) .

ZitatEs 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.
Muss ich mir mal ansehen, aber m.E. müßte das beides sowieso schon jetzt über die (vorgeschaltete) Mapping-Analyse sowieso auf denselben Pfad genagelt worden sein. Grundsächtlich würde ich aber sagen:
Alte Zöpfe könnten wir abschneiden, wer jetzt einsteigen will, sollte lieber darauf "getrimmt" werden, "neuen" Input zu liefern. Um dazu aber eine halbwegs valide Richtung für mein Bauchgefühl zu haben, muss ich damit noch ein wenig rumspielen. Von daher steht z.B. der "Taimer" auf der Agenda: Da gibt es ein {min} {sec} - Beispiel in dem "in depth"-Video, in dem auch "halb" vorkommt; das hat es mir angetan...

Zitat
Vielleicht sollten wir das einfach bei Gelegenheit komplett neu schreiben? Oder auch in mehrere Intents teilen?
Bin da unschlüssig und glaube, dass der Code jetzt soweit reduziert ist, dass man das lassen kann (bzw. sollte). Wenn das Device mal identifiziert ist, laufen - soweit ich das beurteilen kann - alle Zweige ordentlich durch, und man kann dasselbe Anliegen auf angenehm flexible Weise formulieren. Wenn es damit keine Probleme gibt, sehe ich keinen Änderungsbedarf.

Doku: $OnOffValue hätte mich noch interessiert, und ggf. sollte man {volUp} etc. auch in eine Rhasspy-Variable legen? (kann aber auch falsch sein...)

Zitat von: drhirn am 19 März 2021, 11:57:20
Das war's nicht ;)
Wenn man sich das kritisch ansieht, wird auch klar, warum... Da sollte eigentlich einer Variablen ein Wert zugewiesen werden, aber die Variable fehlte...

Zitat
Aber die Sache mit dem Status funktioniert. Danke!
Wenigstens etwas :P .
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 19 März 2021, 14:41:30
Zitat von: Beta-User am 19 März 2021, 12:13:48"mehr" kommt mir deplaziert vor: Das war mal bei Komplexität 55 oder so, jetzt sind wir "nur noch" bei 41 8) .
Ich rede ja nur von mir, nicht von PerlCritic ;D

ZitatGrundsächtlich würde ich aber sagen: Alte Zöpfe könnten wir abschneiden, wer jetzt einsteigen will, sollte lieber darauf "getrimmt" werden, "neuen" Input zu liefern.
Meine Rede! Auch wenn das Jens wahrscheinlich gar nicht gerne hört ;D

ZitatVon daher steht z.B. der "Taimer" auf der Agenda: Da gibt es ein {min} {sec} - Beispiel in dem "in depth"-Video, in dem auch "halb" vorkommt; das hat es mir angetan...
Welches Video?

ZitatDoku: $OnOffValue hätte mich noch interessiert, und ggf. sollte man {volUp} etc. auch in eine Rhasspy-Variable legen? (kann aber auch falsch sein...)
Verstehe leider nicht, was du meinst.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 19 März 2021, 14:44:01
Zitat von: Beta-User am 19 März 2021, 12:13:48
Wenn man sich das kritisch ansieht, wird auch klar, warum... Da sollte eigentlich einer Variablen ein Wert zugewiesen werden, aber die Variable fehlte...

Jeeeetzt verstehe ich, was der Code macht. Ich wollte dich schon bitten, mir den Teil zu erklären. ;D
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 19 März 2021, 15:07:31
Zitat von: drhirn am 19 März 2021, 14:44:01
Jeeeetzt verstehe ich, was der Code macht. Ich wollte dich schon bitten, mir den Teil zu erklären. ;D
::) "use warnings;" hat schon was für sich...

Zitat von: drhirn am 19 März 2021, 14:41:30
Ich rede ja nur von mir, nicht von PerlCritic ;D
Na ja, vielleicht vergleichst du die 0.2.0-Variante mal mit der jetzigen... Imo war die alte "totaler Kauderwelsch", bei der jetzigen habe zumindest ich die Illussion, dass es stringent von oben nach unten geht und halbwegs erkennbar ist, was welcher Schritt macht. Wenn man es weiter eindampfen wollte, müßte man halt immer relativ viele Variablen übergeben, ich _glaube nicht_, dass das übersichtlicher wäre.


Meine Rede! Auch wenn das Jens wahrscheinlich gar nicht gerne hört ;D

Muss er sich selbst äußern. Für den Moment sollte alles noch 100% kompatibel sein (abgesehen evtl. von dem CustomIntent-Thema, das ggf. kleine Anpassungen erfordert). Aber auch das mit dem map=percent macht m.E. Sinn, es ist nur eine etwas andere Schreibweise für das, was homebridgeMapping in >90% der vergleichbaren Fälle mit "factor" macht. Das darf von mir aus gerne bleiben, vermutlich ist das sogar hilfreich, wenn man "255"-er brightness-Werte hat. (Soweit bin ich noch nicht).

ZitatWelches Video?
Es gibt 3 sehr gute Videos zum Ganzen:
Gemeint gewesen war das hier: https://www.youtube.com/watch?v=sWVl0ZoXZEo (das mit dem Timer-Code werde ich mir mal ansehen, da muss ich vermutlich selbst das eine oder andere austesten)
Eine super Einführung zu Rhasspy an sich finde ich ist: https://www.youtube.com/watch?v=IsAlz76PXJQ

Und dann gab es da noch was auf Französisch zu Satelliten:
https://www.youtube.com/watch?v=oTYpTYo2re8

Verstehe leider nicht, was du meinst.

a) Du musst da irgendwo eine Variable/einen slot definiert haben. In meinen Tests konnte Rhasspy das nicht aus der getOnOff.ini auflösen:[de.fhem:GetOnOff]
ist [der|die|das] $de.fhem.Device{Device} [$de.fhem.Room{Room}] $OnOffValue{Status}
b) beim 2. Teil war ich mir auch noch nicht sicher...


Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 19 März 2021, 15:14:14
Ah, das ist ein Slot, den ich schon ewig mit mir rum schleppe:


(an|einschalten|ein|anschalten|aktiviere|aktivieren|anmachen|schließe|schließen|runter|zu|raus|ausfahren|rausfahren|läuft|rennt):an
(aus|ausschalten|ab|abschalten|deaktiviere|deaktivieren|ausmachen|öffne|öffnen|rauf|auf|rauf|rein|einfahren|reinfahren):aus


Den sollte ich vielleicht aus den Sätzen im GitHub rausnehmen
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 19 März 2021, 15:18:20
Danke für die Videos. Kannte ich nicht.

Das mit Timer sollte einfach zu lösen sein. Gehe ich dann mal an.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 19 März 2021, 15:25:54
Ähm, entfernen finde nicht die beste Lösung, früher oder später wird das ganze eh' etwas komplex, von daher schadet es nicht, sowas mal von Hand anzulegen...

Betr. Slots: "updateSlots" ruft jetzt (bei Hash-Nutzung) ja intern als erstes den Hash-update auf; eigentlich wäre es m.E. sinnvoll, da auch gleich den Trainingsaufruf mit reinzuknödeln.

Wenn das zutrifft, würde ich vorschlagen, "reinit" nach "update" umzubenennen und dann dort nur noch zwei Optionen anzubieten: language und slots.
Damit wäre die Userführung klarer: Hat man die Language-file angefasst, macht man dort ein update, damit das Modul das weiß, hat man an den FHEM-Geräten was geändert, muss man die slots updaten. That's all, den ganzen Rest drumrum braucht man nicht...
(Oder übersehe ich mal wieder was?)

Wenn meine Tests mit dem gDT über's WE (?) erfolgreich sind, und niemand sonst was Gegenteiliges berichtet, könnten wir Hash zur Pflicht machen, dann sollte der Code auch an der einen oder anderen Stelle wieder einfacher werden?

Timer ist fertig, aber noch nicht getestet, Code anbei, sentences.ini:
[SetTimer]
two_to_nine = (zwei:2 | drei:3 | vier:4 | fünf:5 | sechs:6 | sieben:7 | acht:8 | neun:9)
one_to_nine = (ein:1 | <two_to_nine>)
teens = (zehn:10 | elf:11 | zwölf:12 | dreizehn:13 | vierzehn:14 | fünfzehn:15 | sechzehn:16 | siebzehn:17 | achtzehn:18 | neunzehn:19)
tens = (zwanzig:20 | dreissig:30 | vierzig:40 | fünfzig:50)

one_to_fifty_nine = (<one_to_nine> | <teens> | <tens> [<one_to_nine>])
two_to_fifty_nine = (<two_to_nine> | <teens> | <tens> [<one_to_nine>])

hour_half_expr = (<one_to_nine>{hour} und (ein halb){min:30})
hour_expr = (((eine:1){hour}) | ((<one_to_nine>){hour}) | <hour_half_expr>) (stunde | stunden)

minute_half_expr = (<one_to_fifty_nine>{min} [und] ((eine | eine) halb){sec:30})
minute_expr = (((eine:1){min}) | ((<two_to_fifty_nine>){min}) | <minute_half_expr>) (minute | minuten)

second_expr = (((eine:1){sec}) | ((<two_to_fifty_nine>){sec})) (sekunde | sekunden)

time_expr = ((<hour_expr> [[und] <minute_expr>] [[und] <second_expr>]) | (<minute_expr> [[und] <second_expr>]) | <second_expr>)

setze [einen] timer für <time_expr>

EDIT: Kurzformen in der ini statt der langen Variante
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 19 März 2021, 15:37:55
Zitat von: Beta-User am 19 März 2021, 15:25:54
Ähm, entfernen finde nicht die beste Lösung, früher oder später wird das ganze eh' etwas komplex, von daher schadet es nicht, sowas mal von Hand anzulegen...

Ich möchte die Sentences nur als Beispiel-Sammlung haben, die jeder ergänzen kann. Von daher sollten da keine Querverweise kommen.
Und ich möchte mit der Doku auch eigentlich keine Rhasspy-Doku machen. Die gibt's schon. Fokus soll auf dem Modul sein.

ZitatBetr. Slots: "updateSlots" ruft jetzt (bei Hash-Nutzung) ja intern als erstes den Hash-update auf; eigentlich wäre es m.E. sinnvoll, da auch gleich den Trainingsaufruf mit reinzuknödeln.

Oft überlegt, immer dagegen entschieden. Wenn du dann viel mit Rhasspy ausprobierst, wird dir auffallen, dass ein Training gleich nach einer Änderung nicht immer sinnvoll ist. Weil du vielleicht davor noch einen Slot ändern musst z.B. Oder du nicht immer warten willst, bis das Training abgeschlossen ist. Das kann unter Umständen nämlich ganz schön lange dauern.


ZitatWenn das zutrifft, würde ich vorschlagen, "reinit" nach "update" umzubenennen und dann dort nur noch zwei Optionen anzubieten: language und slots.

Derzeit muss ich nach jeder Änderung an einem FHEM-Device ein reinit machen. Auch wenn ich nur rhasspyXXX Attribute ändere. Gibt keinen Grund, da dann jedes Mal ein updateSlots zu machen.

Für ein Produktiv-System wäre das dann durchaus von Vorteil, da ändert man nicht viel. Jetzt könnte ich das noch nicht brauchen. Da wär mir lieber, ich müsste nicht ständig ein reinit machen ;)

Wenn meine Tests mit dem gDT über's WE (?) erfolgreich sind, und niemand sonst was Gegenteiliges berichtet, könnten wir Hash zur Pflicht machen, dann sollte der Code auch an der einen oder anderen Stelle wieder einfacher werden?

Ich bräuchte da bitte noch Hinweise, was sich genau dadurch ändert. Damit ich's nachstellen und dokumentieren kann.

Zitat
two_to_nine = (zwei:2 | drei:3 | vier:4 | fünf:5 | sechs:6 | sieben:7 | acht:8 | neun:9)
one_to_nine = (ein:1 | <two_to_nine>)
[...]

Reicht nicht das?
(1..60)
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 19 März 2021, 15:54:33
Zitat von: Beta-User am 19 März 2021, 15:25:54
EDIT: Kurzformen in der ini statt der langen Variante

ini?

Wär's nicht einfacher, wenn wir einen Rhasspy-Satz z.B. so bauen:
\[stell|stelle] (taimer|countdown) [im|auf dem|auf der|in der] [$de.fhem.Room{Room}] (in|auf) (0..60){Value} [(ein viertel|einhalb|dreiviertel){Value2}] [(sekunden|minuten|stunden){Unit}]
Und das Value2 dann im Modul auseinandernehmen?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 19 März 2021, 16:28:02
Zitat von: drhirn am 19 März 2021, 15:37:55
Ich möchte die Sentences nur als Beispiel-Sammlung haben, die jeder ergänzen kann. Von daher sollten da keine Querverweise kommen.
Und ich möchte mit der Doku auch eigentlich keine Rhasspy-Doku machen. Die gibt's schon. Fokus soll auf dem Modul sein.
Im Prinzip richtig. Gebe aber zu Bedenken, dass erst durch den (einmaligen) Blick auf "Slots" klarer wird, was der Befehl von FHEM aus eigentlich macht...
Ansonsten sollten die Sätze in der Tat eher erläutern, welchen Input FHEM denn in etwa erwartet.

ZitatOft überlegt, immer dagegen entschieden. Wenn du dann viel mit Rhasspy ausprobierst, wird dir auffallen, dass ein Training gleich nach einer Änderung nicht immer sinnvoll ist. Weil du vielleicht davor noch einen Slot ändern musst z.B. Oder du nicht immer warten willst, bis das Training abgeschlossen ist. Das kann unter Umständen nämlich ganz schön lange dauern.
Ok, das mag sein. Evtl.: zwei update-slot-Varianten mit und ohne Training? Da der FHEM-Hash-Teil sehr fix geht, könnte man m.E. auf den trainings-setter verzichten?
(Für meine Tests hatte ich das Training praktisch immer über das Web-Interface von Rhasspy gemacht, und das Modul macht es so oder so nicht ständig, sondern nur auf Nutzeranweisung).

Zitat
Derzeit muss ich nach jeder Änderung an einem FHEM-Device ein reinit machen. Auch wenn ich nur rhasspyXXX Attribute ändere. Gibt keinen Grund, da dann jedes Mal ein updateSlots zu machen.
Die Frage wäre, ob es schadet, wenn FHEM ggf. "zu oft" die slots updated.
Bei den Attributen ist es halt so, dass man als User dann wissen muss, ob es - aus Rhasspy-Sicht - "new news" gibt. Wenn nein, macht es keinen Sinn, wenn ja, macht es sehr viel Sinn.
Ich _glaube_, die Nutzerführung ist einfacher, wenn wir das ganze unter einer update-Gruppe zusammenfassen und ggf. dann eben nur mehr Varianten anbieten, also z.B. (neben language) devicemap, devicemap+slot devicemap+slot+train, nur slot, nur train).

ZitatIch bräuchte da bitte noch Hinweise, was sich genau dadurch ändert. Damit ich's nachstellen und dokumentieren kann.
Also: Es gibt einen neuen optionalen Parameter: addDGTAttrs (Bennenung können wir gerne diskutieren). Setzt man den auf z.B. 1, werden
a) zwei weitere globale Attribute verfügbar
b) die der devspec entspechenden Devices automatisch mit ausgewertet, an denen genericDeviceType gesetzt ist. Muss allerdings erst noch testen, inwieweit das klappt. Mit etwas Glück sollten (mind.) CUL_HM, ZWave und MAX - switch/light/thermostat direkt funktionieren... (abgesehen von Farbe).
Kannst ja mal schauen, ob und was da bei dir wie im Hash landet ;) .

(@JensS: So sollte dann auch halbwegs transparent sein, was das Modul im Hintergrund macht).

ZitatReicht nicht das?
(1..60)
Vielleicht.
Deine Ankündigung, das direkt selbst anzugehen, hat mich bewogen "vor der Zeit" was ungetestetes zu posten, das für mich erst mal halbwegs plausibel klang, auch um das eine oder andere zu lernen. Von daher: Schauen wir mal, was am Ende daraus entsteht...
(Ich hatte irgendwie gestern abend etwas rumgespielt, aber da wollte das mit dem Timer nicht. Vermutlich hätte ich in die sentences.ini schauen sollen, aber ich wollte erst mal vor allem auch wissen, wie "intuitiv" manches automatisch geht  ;D ::) .

Zitat von: drhirn am 19 März 2021, 15:54:33
ini?
sentences.ini (dafür war doch dieser verschachtelte code, oder? Da standen erst {minutes}, im Modulcode aber {min}...)
ZitatWär's nicht einfacher, wenn wir einen Rhasspy-Satz z.B. so bauen:
\[stell|stelle] (taimer|countdown) [im|auf dem|auf der|in der] [$de.fhem.Room{Room}] (in|auf) (0..60){Value} [(ein viertel|einhalb|dreiviertel){Value2}] [(sekunden|minuten|stunden){Unit}]
Und das Value2 dann im Modul auseinandernehmen?
Wie geschrieben: Ich wollte auch erst noch selbst ein Gefühl dafür bekommen, wie das mit den Variablen etc. funktioniert und wollte keinesfalls behaupten, dass das das Gelbe vom Ei ist, was ich da irgendwo aufgegabelt habe ::) .

(Und interessant wird noch die Frage, wie wir "stelle einen Wecker auf dreiviertel zwölf" vercoden - ihr kennt im schönen Österreich ja auch diese vorwärtsgewandte Sichtweise... (andere sagen "viertel vor", und das ist fast genauso lustig ;D ).
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 19 März 2021, 16:35:24
Zitat von: Beta-User am 19 März 2021, 16:28:02
(Und interessant wird noch die Frage, wie wir "stelle einen Wecker auf dreiviertel zwölf" vercoden - ihr kennt im schönen Österreich ja auch diese vorwärtsgewandte Sichtweise... (andere sagen "viertel vor", und das ist fast genauso lustig ;D ).

Also, bevor ich mir deinen Post nochmal genau durchlese und antworte, muss ich darauf reagieren.

Nein! Nie, nimmer, niemals werde ich etwas für "viertel" und "dreiviertel" zwölf programmieren. Diese "Zeitverwendung" ist so absurd! So oft war ich schon zu früh/spät irgendwo, weil ich's als Westösterreicher auch nach 20 Jahren im Osten nicht kapiert habe, was die damit meinen. Und die machen's nicht mal alle gleich. Alle (mir bekannten) Sprachen verwenden "viertel vor" und "viertel nach". Die Ostösterreicher sollen das auch endlich lernen zefix! ;D
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 19 März 2021, 16:42:38
Nix Ostösterreicher, ich bin weiter westlich: https://www.youtube.com/watch?v=Q4_0W5ZJYcU (https://www.youtube.com/watch?v=Q4_0W5ZJYcU)

(und zum einen ist es logischer, immer nach vorne zu denken (mal abgesehen von "tsee nach tswelve"), zum anderen ist es ein netter Denksport, das (kompatibel mit Westösterreichischen Gepflogenheiten) zu coden)
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 19 März 2021, 16:45:33
Zitat von: Beta-User am 19 März 2021, 16:28:02
Im Prinzip richtig. Gebe aber zu Bedenken, dass erst durch den (einmaligen) Blick auf "Slots" klarer wird, was der Befehl von FHEM aus eigentlich macht...
Deswegen hab ich die Verwendung des Slots in meinen Sentences jetzt einfach durch (an|ein) ersetzt.

Zitat(Für meine Tests hatte ich das Training praktisch immer über das Web-Interface von Rhasspy gemacht, und das Modul macht es so oder so nicht ständig, sondern nur auf Nutzeranweisung).
Ich mach's immer über FHEM ;)

ZitatBei den Attributen ist es halt so, dass man als User dann wissen muss, ob es - aus Rhasspy-Sicht - "new news" gibt.
Attribute sollten Rhasspy eigentlich gar nicht interessieren.


ZitatIch _glaube_, die Nutzerführung ist einfacher, wenn wir das ganze unter einer update-Gruppe zusammenfassen und ggf. dann eben nur mehr Varianten anbieten, also z.B. (neben language) devicemap, devicemap+slot devicemap+slot+train, nur slot, nur train).

Ja, da bin ich deiner Meinung.

ZitatAlso: Es gibt einen neuen optionalen Parameter: addDGTAttrs (Bennenung können wir gerne diskutieren).

Da müssen wir auf jeden Fall drüber diskutieren ;D
"useGenericDeviceTypes" z.B.? Oder eine leicht abgekürzte Variante?

ZitatKannst ja mal schauen, ob und was da bei dir wie im Hash landet ;) .
Mach ich

ZitatVon daher: Schauen wir mal, was am Ende daraus entsteht...
So wie meine Tests derzeit aussehen, wird's eine Kombination aus unseren Varianten
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 19 März 2021, 16:48:50
Zitat von: Beta-User am 19 März 2021, 16:42:38
Nix Ostösterreicher, ich bin weiter westlich: https://www.youtube.com/watch?v=Q4_0W5ZJYcU (https://www.youtube.com/watch?v=Q4_0W5ZJYcU)

(und zum einen ist es logischer, immer nach vorne zu denken (mal abgesehen von "tsee nach tswelve"), zum anderen ist es ein netter Denksport, das (kompatibel mit Westösterreichischen Gepflogenheiten) zu coden)

Moment. Was? Schwaben verwenden auch "dreiviertel Zwölf"?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 19 März 2021, 17:13:08
Zitat von: drhirn am 19 März 2021, 16:48:50
Moment. Was? Schwaben verwenden auch "dreiviertel Zwölf"?
Jo. Und auch unsere westlichen Nachbarn, die Badener (nett formuliert ;D ). Und wie das in Hessen oder der Pfalz gehandhabt wird, habe ich bisher nicht untersucht...

Zitat von: drhirn am 19 März 2021, 16:45:33
Deswegen [...]
Schaue ich mir an, aber eigentlich sehe ich diesen Teil auch nicht wirklich als meine aktuelle Baustelle an...

ZitatIch mach's immer über FHEM ;)
Jeder, wie er es gewohnt ist. Ich habe die sentences halt über das web-if bearbeitet, und da muss man dann sowieso aktiv werden, was die Frage nach dem Training angeht.

Zitat
Attribute sollten Rhasspy eigentlich gar nicht interessieren.
? Neuer rhasspyRoom => updateSlots. dto. für channel, device-Namen etc. Oder übersehe ich mal wieder was?


Ja, da bin ich deiner Meinung.

Vorschläge sind willkommen, aber da die funktionalen Bauteile ja soweiso getrennt sind, ist es eigentlich nur "skinning", und ich bin daher für jeden zielführenden Vorschlag offen. Wollte nur zurückmelden, was ich so als "unbedarfter User" an Eindrücken hatte :P .

Zitat
Da müssen wir auf jeden Fall drüber diskutieren ;D
"useGenericDeviceTypes" z.B.? Oder eine leicht abgekürzte Variante?
"useGenericAttrs"?"ausgeschlachtet" werden (hoffentlich) auch alexaName & siriName, ggf. ergänzt und (betr. hb-Mapping noch nicht) ausgewertet eben die beiden "generischen" schon erwähnten. Wobei ich mir bezgl. des homebridgeMappings noch nicht sicher bin. Das sieht recht kompliziert aus, und da es auch die Möglichkeit gibt, eben ein rhasspyMapping anzugeben, kann man das in diesen Fällen eventuell auch sein lassen (es sei denn, es liefert jemand Code).
Jedenfalls im Moment sollte es so sein, dass (bei Doppelungen) "rhasspy sticht generic" gilt...

Wird evtl. auch die Praxis zeigen
Zitat
So wie meine Tests derzeit aussehen, wird's eine Kombination aus unseren Varianten
Bin mal auf das Ergebnis gespannt :) .
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 19 März 2021, 17:21:21
Zitat von: Beta-User am 19 März 2021, 17:13:08
Jo. Und auch unsere westlichen Nachbarn, die Badener (nett formuliert ;D ). Und wie das in Hessen oder der Pfalz gehandhabt wird, habe ich bisher nicht untersucht...

Pfff, und ich hab immer geglaubt, wir Alemannen sind die besseren Deutschsprechenden ;D

ZitatSchaue ich mir an, aber eigentlich sehe ich diesen Teil auch nicht wirklich als meine aktuelle Baustelle an...
Sehe ich auch so

Zitat? Neuer rhasspyRoom => updateSlots. dto. für channel, device-Namen etc. Oder übersehe ich mal wieder was?

Nein, aber ich. *kopf->tisch*


Zitat"useGenericAttrs"?
d'accord

ZitatWobei ich mir bezgl. des homebridgeMappings noch nicht sicher bin. Das sieht recht kompliziert aus, und da es auch die Möglichkeit gibt, eben ein rhasspyMapping anzugeben, kann man das in diesen Fällen eventuell auch sein lassen (es sei denn, es liefert jemand Code).
Beim Homebridge-Mapping kann ich gar nicht helfen. Da hab ich null Erfahrung.

ZitatJedenfalls im Moment sollte es so sein, dass (bei Doppelungen) "rhasspy sticht generic" gilt...
Das halte ich für einen guten Ansatz!
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 19 März 2021, 17:36:32
Ich hätt's nicht geglaubt, aber das scheint Rhasspy-seitig zu funktionieren. Muss nur das Modul entsprechend umbauen.


[de.fhem:SetTimer]
timer auf [((1..60){hour} (stunde|stunden))] [und] [((1..60){min} (minute|minuten))] [und] [((1..60){sec} (sekunde|sekunden))]
timer auf (1..60){hour} (einviertel{min:15}|einhalb{min:30}|dreiviertel{min:45}) (stunde|stunden)
timer auf (1..60){min} (einviertel{sec:15}|einhalb{sec:30}|dreiviertel{sec:45}) (minute|minuten)


Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 19 März 2021, 17:44:00
Zitat von: drhirn am 19 März 2021, 17:21:21
Nein, aber ich.
Ok, das spricht aber doch auch eher dafür, bei einem devicemap-update auch ein slot-update hinterherzuschubsen, oder?
Es ist ja die Info (an FHEM), dass sich irgendwelche relevanten Attribute geändert haben, und das dann eben auch potentiell auf der Rhasspy-Seite direkt auch ankommen sollte.

Zitatd'accord
War auch ein Schnellschuss, aber dann machen wir das (bis auf weiteres) so...

ZitatBeim Homebridge-Mapping kann ich gar nicht helfen. Da hab ich null Erfahrung.
Ich auch nur dahingehend, dass "weniger ist mehr" gilt. Wenn man wirklich was braucht, wird das scheinbar recht schnell kompliziert, aber das ist eigentlich eher die Ausnahme - abgesehen von der "255"-er brightness. Aber die kann man mit map=percent abfackeln :) .
Hab's mal eingebaut, mal sehen, ob das schon alles war...

Zur "brightness"-Logik:
- für Rhasspy ist das das "Schlüsselwort für "Leuchtmittel" => bitte Zahlenwert liefern!
- für FHEM ist es eher ein Indikator, dass nicht von 0-100 (bzw. 99) gestellt werden kann, sondern 0-255.
Das Modul verhält sich jetzt - ohne explizite Angabe - (hoffentlch) genau nach der FHEM-Logik, wenn es "brightness" geliefert bekommt und entscheidet das mapping anhand des setter-Namens.

Sollte in > 80% das "richtige" Ergebnis liefern, aber eben bei weitem nicht immer...

ZitatDas halte ich für einen guten Ansatz!
Das war auch meine Schlussfolgerung nach den ersten Tests gestern. Man kann zwar manches direkt verwerten, aber z.B. die rhasspyNames machen schon Sinn, selbst, wenn der Rest automatisch läuft und z.B. ein Switch als solcher erkannt und eingebunden wird...
Ist halt alles noch etwas im Fluß, aber wenn wir mit dieser "kleinen Lösung" und ein paar Ergänzungen (speaker, player, oder wie das ggf. heißt) dann das meiste ohne weitere Nutzereingriffe "abgefackelt" bekommen, wäre das schon richtig g*l...

Zitat von: drhirn am 19 März 2021, 17:36:32
Ich hätt's nicht geglaubt, aber das scheint Rhasspy-seitig zu funktionieren. Muss nur das Modul entsprechend umbauen.
8)
Hattest du Zweifel?!?
:P :-* ::)
Btw.: Das Modul sollte schon jetzt mit hour, min und sec "können", "Value"+"Unit" ist nur noch eine Art Kompabilitätslayer...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 19 März 2021, 17:48:29
Zitat von: Beta-User am 19 März 2021, 17:44:00
Hattest du Zweifel?!?
An dir nicht. Aber ich war mir nicht sicher, was Rhasspy mit so vielen Klammern macht.

ZitatBtw.: Das Modul sollte schon jetzt mit hour, min und sec "können", "Value"+"Unit" ist nur noch eine Art Kompabilitätslayer...
Ja, kann es. Abgesehen davon, dass wir $time statt $value brauchen. Und ich mir jetzt überlegen muss, wie ich die "Setzen-Erfolgt"-Rückmeldung mache.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 19 März 2021, 17:53:40
Zitat von: Beta-User am 19 März 2021, 11:42:01
Danke für den Link, auch wenn mir völlig schleierhaft ist, warum die Jungs das als root laufen lassen...?
Nichts hält länger als ein Provisorium...  ;D
Willkommen in der Welt der Beta-Tester!  ;)
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 19 März 2021, 18:04:41
Zitat von: JensS am 19 März 2021, 17:53:40
Nichts hält länger als ein Provisorium...  ;D
Willkommen in der Welt der Beta-Tester!  ;)
;D
...sowas hatte ich schon vermutet...

Dann mal auch ein herzliches Willkommen im Kreis der Beta-User. (Ich habe das Modul im Echtsystem am Start, no risk, no fun...)
Klingt so, als wären Hashes nunmehr doch nicht nur was für große Dachböden...?




;D ... die Rückmeldung in Sekunden ist vielleicht wirklich etwas gewöhnungsbedürftig ;D ...

Würde vorschlagen, den für das at verwendeten String zu teilen und dann die Uhrzeit zurückzugeben.
Die Luxusvariante wäre, in Unit nicht seconds zu schreiben, wenn wir von der neuen Variante kommen, sondern (irgend) was anderes, und/oder danach zu unterscheiden, ob es bis zur Zielzeit mehr oder weniger wie z.B. 100 Sek. sind...? (Oder drei Varianten zu bauen, falls wir noch im Bereich bis z.B. 15 Minuten sind?)
Wie das mit den Hashes funktioniert, ist ja jetzt soweit klar, wobei ich hier ein "sprechendes" Etikett draufkleben würde, z.B. ...->{hour}.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 19 März 2021, 18:16:35
Unit habe ich ganz vernichtet. Brauchen wir nicht mehr.
Die Textausgabe ist aber etwas komplexer. Weil's halt leider auch einen Unterschied macht, ob 1 Stunde oder 2 StundeN.
Aber ich bin gerade auf einem guten Weg. Glaub ich
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 19 März 2021, 18:28:32
Zitat von: Beta-User am 19 März 2021, 18:04:41
Dann mal auch ein herzliches Willkommen im Kreis der Beta-User. (Ich habe das Modul im Echtsystem am Start, no risk, no fun...)
Klingt so, als wären Hashes nunmehr doch nicht nur was für große Dachböden...?
Danke für's Willkommen.  :)
Solange man nicht verschwenderisch mit dem Platz auf dem Dachboden umgeht, sind Hashes super. Ich habe mir den Code noch nicht wirklich angeschaut, hatte aber auf Grund der Posts die Vermutung, dass bereits vorhandene Werte doppelt vorgehalten werden.
Zum Thema Timer hatte Roman einen Beitrag. https://forum.fhem.de/index.php/topic,113180.msg1130139.html#msg1130139 (https://forum.fhem.de/index.php/topic,113180.msg1130139.html#msg1130139)
Könnt ihr Werners Bierflasche optional mit einbauen?
Ich freue mich jedenfalls, dass das Modul von einem Code-Jongleur so fachkräftige Hilfe erfährt und warte geduldig auf eine endgültige Version.
Gruß Jens
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 19 März 2021, 18:53:27
So, ich hab mal denen neuen Timer zu GitHub (0.4.5beta) gestellt. Work in progress. Nur damit ihr seht, wie ich mir das vorstelle. Musste halt auch die rhasspy-de.cfg ändern.

Funktioniert mit dem oben geposteten Rhasspy-Sätzen:

[de.fhem:SetTimer]
timer auf [((1..60){hour} (stunde|stunden))] [und] [((1..60){min} (minute|minuten))] [und] [((1..60){sec} (sekunde|sekunden))]
timer auf (1..60){hour} (einviertel{min:15}|einhalb{min:30}|dreiviertel{min:45}) (stunde|stunden)
timer auf (1..60){min} (einviertel{sec:15}|einhalb{sec:30}|dreiviertel{sec:45}) (minute|minuten)
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 20 März 2021, 13:55:11
So, Zwischenstand zum Thema genericDeviceType:

Der Hash wird mit der (leider noch auf meiner gestrigen Version basierenden) Version jetzt aufgebaut, die einzelnen Elemente werden - soweit ich das vorläufig überblicken kann - auch sauber gemischt.
Testgeräte für "nur-gDT" bzw. gDT+rhasspy-Names/Room waren: CUL_HM-Thermostat, ZWave-on/off, blind-Geräte beider Gattungen und ein MQTT2-Tasmota-Licht (pct-dimmbar).

Was Timer angeht, hätte ich da auch gerne deine neue Fassung eingebaut, aber das sah' gestern noch wirklich nach WIP aus. Tipp: Für's Testen reicht es erst mal, die Sätze in die de-cfg zu schreiben und dann ein language-update zu machen. Wenn dann klar ist, wie es geht, kann man es dann in die en-Fassung nachtragen. (Auf github lag/liegt noch eine alte de-cfg, wenn ich das richtig sehe).

Soweit erst mal von meiner Seite...
EDIT: das mit dem Timer wollte ich jetzt doch wissen, ist eingearbeitet, language-file anbei.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 20 März 2021, 18:55:49
Zitat von: Beta-User am 20 März 2021, 13:55:11
(Auf github lag/liegt noch eine alte de-cfg, wenn ich das richtig sehe).

Öhm, nein. Die ist schon aktuell. Letzter Stand gestern abend.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 20 März 2021, 20:01:01
Bin mal drübergeflogen hab gleich ein paar Fragen:

"define Rhasspy RHASSPY" scheint zu reichen - das gefällt mir. Im Code bzw. ref stehen verschiedene Ersatz-Standardräume (RHASSPY,Rhasspy,default). Wozu brauche ich das Ding überhaupt? Er soll ja notwendig sein aber ich habe nirgends einen Bezug dazu gefunden. Als SiteId bei "set Rhasspy speak ..." wird ja "default" gesetzt.

Passiert ein Response oder SessionEnd, wenn SetMute aktiv ist, und z.B. nach der Zeit gefragt wird?

Zeile 2009: "    my $contenttype = q{application/json};" scheint überflüssig zu sein.

Ist eine Erweiterung des Timers mit Begriffen machbar? Bei mehreren Timern gleichzeitig, könnte man so erfahren, welcher gerade abgelaufen ist. Eine Liste mit Begriffen könnte in die Sprachdatei und per updateSlots verteilt werden. Für mich auch noch interessant - die Möglichkeit, eine .wav abzusetzen.

Nochmals Danke für Eure viele Arbeit!!!

Gruß Jens

Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 21 März 2021, 09:52:35
Zitat von: drhirn am 20 März 2021, 18:55:49
Öhm, nein. Die ist schon aktuell. Letzter Stand gestern abend.
Ähm, sorry, dann habe ich da wohl was durcheinandergewürfelt...

Es war noch eine Kleinigkeit bei den Räumen verquer, das sollte jetzt auch in der Fassung anbei geklärt sein.

Es sind mir beim Rumtesten noch ein paar andere "Kleinigkeiten" aufgefallen, aber dazu ein andermal mehr.

Zitat von: JensS am 20 März 2021, 20:01:01
Ist eine Erweiterung des Timers mit Begriffen machbar? Bei mehreren Timern gleichzeitig, könnte man so erfahren, welcher gerade abgelaufen ist. Eine Liste mit Begriffen könnte in die Sprachdatei und per updateSlots verteilt werden.
Das mit den Begriffen fände ich auch gut, das mit dem "Programm" in der Einkaufsliste war in dem Zusammenhang ggf. interessant?
(sollte man vorsehen, würde "label" vorschlagen?)

Hätte dann auch noch zwei Wünsche:
- Es sollte die Möglichkeit geben, einen (ebenfalls optional benannten) "Wecker" zu stellen. Dazu müßte man aber unterscheiden, ob eine Dauer (hour) oder eine Uhrzeit (hourAbs?) übergeben wird. sollte weder bei den sentences noch im Code ein großes Problem darstellen.
- Die heutige Rückgabe finde ich nicht so gelungen, würde nochmal auf das hier zurückkommen:
Zitat von: Beta-User am 19 März 2021, 18:04:41
Die Luxusvariante wäre, [in der Antwort] danach zu unterscheiden, ob es bis zur Zielzeit mehr oder weniger wie z.B. 100 Sek. sind...? (Oder drei Varianten zu bauen, falls wir noch im Bereich bis z.B. 15 Minuten sind?)
Will sagen: Wenn der Timer erst in einer Stunde abläuft, würde ich eher die Uhrzeit zurückgeben als die Zeitdifferenz in Stunden. Das sollte auch für "Wecker" intuitiver sein?

Zitat"define Rhasspy RHASSPY" scheint zu reichen - das gefällt mir.
Im Prinzip ja, wobei es vermutlich empfehlenswert ist, language=de zu setzen, sonst muss man immer die Labels bei den sentences anpassen, oder?
Ansonsten finde ich das mit parseParams auch sehr elegant, das macht es wirklich einfach, beliebig Parameter zu setzen, oder es eben sein zu lassen :) .

Zitat
Im Code bzw. ref stehen verschiedene Ersatz-Standardräume (RHASSPY,Rhasspy,default). Wozu brauche ich das Ding überhaupt? Er soll ja notwendig sein aber ich habe nirgends einen Bezug dazu gefunden. Als SiteId bei "set Rhasspy speak ..." wird ja "default" gesetzt.
Dazu kann ich noch wenig sagen, im Moment ist es (fast) so, wie es immer war... (nur bei Hash-Nutzung wird alles auf Kleinschreibung "getrimmt").

Zitat
Passiert ein Response oder SessionEnd, wenn SetMute aktiv ist, und z.B. nach der Zeit gefragt wird?
Wenn muted,  erfolgt nie eine Reaktion. An sich finde ich das logisch, aber wenn Bedarf besteht, müßte man sich das mal ansehen.

Zitat
Zeile 2009: "    my $contenttype = q{application/json};" scheint überflüssig zu sein.
Muss ich mir mal ansehen, wird etwas dauern.

Zitat
Für mich auch noch interessant - die Möglichkeit, eine .wav abzusetzen.
Mit dem Teil "Audiowiedergabe" habe ich mich noch nicht befasst, aber playWav als Funktion ist ja da, sollte also eigentlich keine größere Sache sein.
(Ich habe aber noch keine Vorstellung, was da von woher gespielt werden soll).

Danke auf alle Fälle auch für's drübersehen!
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 21 März 2021, 10:47:21
Danke für deine ausführliche Antworten!
ZitatWenn muted,  erfolgt nie eine Reaktion. An sich finde ich das logisch, aber wenn Bedarf besteht, müßte man sich das mal ansehen.
Wenn eine Session eröffnet wurde, muss es ein SessionEnd in irgendeiner Art geben. Ansonsten wartet die Basis bis zum Timeoutfehler.
ZitatMit dem Teil "Audiowiedergabe" habe ich mich noch nicht befasst, aber playWav als Funktion ist ja da, sollte also eigentlich keine größere Sache sein.
Wär ne tolle Sache!
Zitatnur bei Hash-Nutzung wird alles auf Kleinschreibung "getrimmt"
...sehe ich kritisch, da in den Rhasspy-Attributen bzw. sentences.ini beides erlaubt ist.
ZitatDazu kann ich noch wenig sagen, im Moment ist es (fast) so, wie es immer war...
Der Standardraum sollte der SiteId entsprechen, welche im Standardfall genutzt wird und kein siteId="Küche" mitgegeben wird.
Bei "set Rhasspy speak hallo" ertönt in diesem Raum ein "hallo". Bei mir ist es aktuell das Wohnzimmer. Dazu habe ich die hardgecodete Variable von "default" auf "Wohnzimmer" gesetzt.
Da bei der Installation von Rhasspy, die siteId immer zuerst "default" lautet, würde ich vorschlagen, den Standardraum mit "default" bei undef vorzubelegen. Das würde Einsteigern das Testen mit "set Rhasspy (speak|textCommand|play|etc.)" erleichtern und schnell zum gewünschten Erfolg führen.
ZitatDazu müßte man aber unterscheiden, ob eine Dauer (hour) oder eine Uhrzeit (hourAbs?) übergeben wird.
Ist auf jeden Fall eine nützliche Erweiterung.
Zeile 2009:"    my $contenttype = q{application/json};"
Da ist mir aufgefallen, dass die Variable definiert wird aber keine Übergabe bzw. Auswertung stattfindet.

Gruß Jens

p.s.
ZitatIch habe aber noch keine Vorstellung, was da von woher gespielt werden soll
Schau mal hier: https://forum.fhem.de/index.php/topic,113180.msg1130450.html#msg1130450 (https://forum.fhem.de/index.php/topic,113180.msg1130450.html#msg1130450)
Die Get-Variante von Roman (vv.) ist auch interessant. "Wann sind die Kartoffeln fertig?" könnte man mit "Der Kartoffel-Timer ist in 10 Minuten abgelaufen." beantworten.

Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 22 März 2021, 18:04:22
Zitat von: JensS am 21 März 2021, 10:47:21
Wenn eine Session eröffnet wurde, muss es ein SessionEnd in irgendeiner Art geben. Ansonsten wartet die Basis bis zum Timeoutfehler.
Soweit ich das überblicken kann, wird die Sitzung auch in dem Fall beendet, da "respond" aufgerufen wird.

Zitat
Wär ne tolle Sache!
Hab's mal auf die Wunschliste gepackt (@drhirn: zu finden jetzt am Anfang der Doku, vor der cref; ist m.E. übersichtlicher).

Zitat
...sehe ich kritisch, da in den Rhasspy-Attributen bzw. sentences.ini beides erlaubt ist.
Mein Gedanke dazu:
Wie will man das in der Spracherkennung auseinanderhalten? Klar wird das gehen, wenn es in unterschiedlichen Variablen vorkommt, aber wenn nicht...?
M.E. ist es eindeutiger, wenn wir in der Kommunikation zwischen Rhasspy und dem Modul zumindest im Bereich Device-Namen, Gruppen (s.u.) und Rooms alles auf "klein" trimmen. Da brauchen wir eindeutige Kenner, sonst ist m.E. Chaos im wahrsten Sinne des Wortes "vorprogrammiert"...
(Das betrifft nur bestimmte Elemente, die sowieso unter der "Verwaltung" des Moduls standen; das sollte eigentlich in vorhandenen Installationen keine Aufwände erzeugen, da wir ja nicht mehr immer auf die Attribute zugreifen, sondern vorverarbeitete Daten verwenden, s.u.).
[OT]
Wegen des Speichereinwands:
Ja, das mit dem Hash kostet etwas Arbeitsspeicher, spart dafür aber vermutlich etwas Rechenleistung. Vorteil ist (m.E.) eine größere Transparenz bei der jetzt möglichen "Vermischung" der Quellen für Infos.
Hatte mal eine Diskussion mit Rudi betr. die attrTemplate, da meinte er nur sinngemäß, dass wir uns dieses Themas dann annehmen, wenn es wirklich viel Speicher kostet ;D . Glaube kaum, dass wir mit den paar Daten da was grundlegend falsch machen, zumal, wenn die Daten (bei gDT-Mappings) vorher gar nicht in der Form existiert hatten ::) ...
[/OT]

Zitat
Der Standardraum sollte der SiteId entsprechen, welche im Standardfall genutzt wird und kein siteId="Küche" mitgegeben wird.Bei "set Rhasspy speak hallo" ertönt in diesem Raum ein "hallo". Bei mir ist es aktuell das Wohnzimmer. Dazu habe ich die hardgecodete Variable von "default" auf "Wohnzimmer" gesetzt.
RHASSPY habe ich rausgeworfen (s.o.), Rhasspy als Room-Name bleibt (für devspec im room-Attribut) erst mal (und m.E. auch langfristig) möglich, sollte aber für Rhasspy dann auf Übermittlung in Kleinschreibung umgebogen werden, wie das mit allen Raumnamen der Fall ist (s.o.).
Eine Änderung im Modulcode sollte in jedem Fall nicht erforderlich sein, jedenfalls, soweit ich das überblicken kann; dafür gibt es ja weiter die Option, in der DEF was anzugeben.

Zitat
Da bei der Installation von Rhasspy, die siteId immer zuerst "default" lautet, würde ich vorschlagen, den Standardraum mit "default" bei undef vorzubelegen. Das würde Einsteigern das Testen mit "set Rhasspy (speak|textCommand|play|etc.)" erleichtern und schnell zum gewünschten Erfolg führen.Ist auf jeden Fall eine nützliche Erweiterung.
Das mit "default" als Standardraum habe ich mal (hoffentlich) reingebastelt, erscheint mir sinnvoll, ist aber noch nicht weiter auf Praxistauglichkeit getestet und eben jederzeit auch änderbar (s.o.).

ZitatZeile 2009:"    my $contenttype = q{application/json};"
Da ist mir aufgefallen, dass die Variable definiert wird aber keine Übergabe bzw. Auswertung stattfindet.
...berechtigter Einwand, ist weg...

Zitatp.s.Schau mal hier: https://forum.fhem.de/index.php/topic,113180.msg1130450.html#msg1130450 (https://forum.fhem.de/index.php/topic,113180.msg1130450.html#msg1130450)Die Get-Variante von Roman (vv.) ist auch interessant. "Wann sind die Kartoffeln fertig?" könnte man mit "Der Kartoffel-Timer ist in 10 Minuten abgelaufen." beantworten.
Finde ich auch interessant!

Zum Anhang hier:
- "Hash-only"
Im laufenden Betrieb greift das Modul jetzt auf die interne Struktur zu, deren Erneuerung löst dann auch gleich ein updateSlots und Training aus (andere Optionen sind wählbar). Damit sollte nach einer Änderung an einem Device dann immer Rhasspy auch die aktuellen Daten haben (und z.B. dann klein geschriebene Räume zurückliefern, die dann zu den Angaben im Hash passen).
Ich hatte erst vor, den Hash zu verstecken, aber bis auf weiteres ist die Fehlersuche ggf. einfacher, wenn er ohne weiteres via list sichtbar ist. Auch später glaube ich, dass er offen sichtbar bleiben sollte, damit der Anwender sehen kann, was aus seinen Angaben da "zusammengebraut" wird...

- Die Sprach-Hashes werden jetzt "gemixt", die Struktur ist über die englische Variante strikt vorgegeben. Im Detail:
-- Wenn wir neue Hashes brauchen, müssen die im Modulcode vorgesehen sein, sonst geht es jetzt nicht mehr; (ich hatte ein paar Abstürze, weil die Sprachfile nicht zu dem paßte, was das Modul erwartete; das sollte im Echtbetrieb nicht vorkommen können...!)
-- Da, wo dann passende Elemente (SCALAR) in der cfg gefunden werden, werden die übernommen, wo nicht, bleiben die Vorgaben aus dem Modul;
-- Das ganze ist jetzt dreistufig, neu ist die Option, einfach bestimmte einzelne eigene Sätze an passender Stelle im JSON-Bereich "user" zu ergänzen. (Ist evtl. zu kompliziert zu erklären, (unisnniges) Beispiel ist anbei (auch ein engl. "Rest", der nicht überschrieben ist). Die alten Fassungen sollten aber auch weiter funktionieren, und wenn das als zu schwierig empfunden ist, sollten wir es bei zwei Stufen belassen).)

- Es gibt eine neue Kategorie "groups", wie bei den rasspyRooms wird entweder das "allgemeine" group-Attribut ausgewertet, oder das ganze überschrieben durch rasspyGroups, falls gesetzt. Ziel ist es, je einen SetOnOffGroup-intent und SetNummericGroup-intent möglich zu machen. Man könnte das ganze eventuell auch über structure abbilden, aber das ist uU. sehr viel mehr Aufwand, als es über ein schnell mal vergebenes Schlagwort zu machen. Ggf. muss dann aber auch eine Verzögerungsmöglichkeit (send_delay) rein, damit es nichz zu "Funkhackel" kommt...

- Die genericDevType enthalten jetzt auch "media" (ungetestet, aber sollte mit den Vorgaben von https://wiki.fhem.de/wiki/DevelopmentGuidelinesAV passen);

- Es ist mal eine Art ToDo/Wunschliste eingepflegt, dann kann man die Dinge ggf. auch leichter priorisieren und findet die Quelle schneller;
Im Moment stehen da u.A. drauf:
-- Timer/Wecker mit "label"-Option, geänderter Rückmeldung und Funktionalität.
-- Gruppen Schaltung (s.o.)
-- siteId2Room: Das ist in der heutigen Form zu starr, wenn man mobile Geräte verwendet. Ziel wäre, entweder den Standort (z.B. des Androiden) per Perl-Funktion bestimmen zu können oder einfach sagen zu können: "ich bin jetzt im Wohnzimmer". Über Details wäre zu reden...
-- "rhasspySpecials":
Habe keinen besseren Begriff gefunden, aber im Kern geht es darum, einen Ort anzubieten/vorzuhalten, um z.B. für das siteId2Room-Feature eine (Erst-) Eingabemöglichkeit zu haben. Weiterer Anwendungfall könnte ein "Lamellen-ad-on" sein (hier gibt es einige Jalousien mit separat verstellbaren/drehbaren Lamellen. Die Anweisung: "Fahre die Jalousie xy auf 50%" ist unvollständig, weil der "Drehungsanteil" fehlt - der zudem teilweise noch an ein ganz anderes Gerät gehen muss...
(Ein weites Feld; falls jemand funktionierende Lösungen hat?...).
Dann: bei manchen Geräten war bisher die Erkennung noch nicht optimal, und bei vielen von diesen Geräten wäre es super, erst noch eine Bestätigung vorzuschalten. In den Shortcuts ist das vorbereitet, aber "jemand" müßte es fertig machen und dann eben auch z.B. für SetOnOff an einzelnen Geräten (oder Gruppenschaltungen :) ) möglich machen.

Bzgl. weiterem Vorgehen:
Ich würde mich bei Gelegenheit um die Themen Gruppen (Prio 1) und Bestätigung (Prio 2) kümmern, wäre nett, wenn jemand anderes das Timer-Thema gut fände ;) . Codeschnippsel sollten m.E. in Twilight zu finden sein, da gibt es z.B. die Prüfung, ob ein neu errechneter Sonnenuntergang (wg. Wetter) früher ist als "jetzt" - sowas bräuchte man vermutlich für den "Wecker" auch: Wird der um 17:00 Uhr auf 09:00 Uhr gestellt, ist vermutlich der morgige Tag gemeint...

Happy Testing 8) .
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 22 März 2021, 20:53:30
Hey, cool - das Schweizer Taschenmesser!  8)
Danke für die schlüssigen Ausführungen. Da folgen wohl einige neue Hauptversionen.
   if ($mute)...habe ich wohl überlesen - sorry.

Gruß Jens

p.s.
ZitatDie Anweisung: "Fahre die Jalousie xy auf 50%" ist unvollständig, weil der "Drehungsanteil" fehlt
Nur mal aus Interesse; wie würde die ganze Anweisung aussehen?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 24 März 2021, 08:09:46
Anbei wieder was neues...

Das kann jetzt (prinzipiell) Gruppen an- und ausschalten, und bei shortcuts eine Bestätigung abfragen 8) .

Details (auch zu den weiteren Attributen) liefere ich nach, bitte melden, falls direkt Informationsbedarf besteht.

- Gruppen werden aus den normalen group-Attributen abgeleitet, man kann das übersteuern über das neue (globale) rhasspyGroup-Attribut. Wie üblich muss man Rhasspy über update devicemap mitteilen, dass es was neues gibt...
sentences.ini dazu:
[de.fhem:SetOnOffGroup]
\[(schalt|mach|fahr)] (alle | sämtliche ) $de.fhem.Group{Group} [im] [( überall:global | $de.fhem.Room){Room}] $OnOffValue{Value}


Das ganze auch für SetNumeric umzusetzen, wird vermutlich etwas schwieriger, es wäre ggf. nett, wenn ihr Rückmeldung geben könntet, ob das in dieser Form für euch Sinn macht.

- Das mit der Confirmation braucht:a) eine entsprechende Anforderung, das ist im Moment nur für Shortcuts testweise implementiert:
attr rhasspy shortcuts i="ton aus" f="set Yamaha_Main mute on" c="Soll ich wirklich den Verstärker still schalten" ct=10\
ton an={fhem ("set Yamaha_Main mute off")}

Relevant sind hier "c" (und optional "ct"), Erläuterungen zu den Parametern (Shortcuts insges.) sind als Kommentar im Code zu finden.
b) sentences.ini:
[de.fhem:ConfirmAction]
(ja mach | tu es | ist ok ){Mode:OK}
(lass es | nein | abbrechen | abbruch ){Mode}

Das ganze ist recht generisch aufgebaut, es sollte sich praktisch ohne größere Aufwände bei allen "Einzelanweisungen" ergänzen lassen (vorausgesetzt, man hat einen Ort, um die Info unterzubringen, dass man nur nach Bestätigung ausgeführt haben will). Was scheinbar nicht klappt, ist die Session ordentlich zu beenden, ich weiß aber noch nicht warum.

PS:
Bin wirklich positiv überrascht über den Rhasspy-Dienst an sich. Es scheint auch so zu sein, dass die Erkennung mit zunehmender Zahl an zu verarbeitenden Worten/Schnipseln eher besser wird...?

Zitat von: JensS am 22 März 2021, 20:53:30
p.s.  Nur mal aus Interesse; wie würde die ganze Anweisung aussehen?
Das kommt zu allem Überfluss auch noch auf das konkrete Gerät an... Erfahrung habe ich jetzt mit zwei Fibaro-Modellen:
Der FGRM222 ist ein "Einheitsdevice", das dann die Befehle dim oder positionBlinds für die Öffnung kennt und positionSlat für die Drehung.
Der FGRM-223 ist ein "Mehrkanaler", von dem ich Kanal 1 für die Öffnung (hier nur: dim) verwende (das ginge auch über den Hauptkanal), und Kanal 2 für die Drehung, dort auch wieder über den dim-Befehl....
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 24 März 2021, 09:20:41
Wie ihr merkt, habe ich zur momentan leider nicht wirklich Gelegenheit, mit euch am Modul zu arbeiten. Wird wieder anders hoffe ich.

Auf jeden Fall habe ich mal die neuesten Änderungen von Beta-User in eine Version 0.4.6a gepackt.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 24 März 2021, 17:49:43
Paßt schon.

Du musst halt rechtzeitig "stop" rufen, falls das aus deiner Sicht in die falsche Richtung geht...

Werde mir dann mal den Wecker vornehmen ;) , und dann eventuell irgendwann mal SetNumericGroup.

@all: Testet denn grade jemand an der aktuellen Version rum?
Habe gesehen, dass mind. einer (@Hardlife) grade dabei ist, sich in das Thema Rhasspy reinzufieseln, und fände es schade, wenn er sich noch allzulange mit der "klassischen" Konfiguration rumplagen würde... Statt alle in den room Rhasspy zu packen, einfach die devspec entsprechend wählen (das kann auch eine kommaseparierte Einzelauflistung von Devices sein!), jeweils genericDeviceType festlegen, und es wird in geschätzt 60%+ schon das meiste gewesen sein. Bißchen Raum- und Gruppenzuordnung, that's all ;) .
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 24 März 2021, 18:46:51
Ich hab keine Einwände. Ich täte nur Timer/Wecker trennen. Weil, ein Wecker kann durchaus komplex werden ("wecker jeden mittwoch um 08:30").

Bzgl. Groß-/Kleinschreibung unterstütze ich die Kleinschreib-Fraktion. Modulintern sollten wir alles klein behandeln, was wir verarbeiten müssen.

Soll ich eine neue "stable" machen und die als Hauptversion in GitHub markieren? Dann kommt keiner mehr auf die Idee, eine alte Version zu nehmen.

Durch meine ungewollte Abwesenheit bekomme ich leider viel nicht mit. Es wäre daher superpraktisch, wenn jemand von euch in der README/CRef mitdokumentieren würde damit wir nichts vergessen.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 25 März 2021, 08:40:28
Zitat von: drhirn am 24 März 2021, 18:46:51
Ich hab keine Einwände.
Danke für die Rückmeldung!

Zitat
Ich täte nur Timer/Wecker trennen. Weil, ein Wecker kann durchaus komplex werden ("wecker jeden mittwoch um 08:30").
An sich ein korrekter Hinweis. Zwei Gedanken dazu:
a) er kam "zu spät", da war der Code im wesentlichen schon umgestellt... (könnte man auch wieder ändern, falls gewünscht), aber
b) glaube ich, dass das mit dem komplexen Wecker-Wunsch zwar kommen wird ist, aber recht schwierig umzusetzen sein wird. Will mal wieder niemanden abhalten, zu beweisen, dass es doch geht, aber m.E. ist da recht viel Interaktion erforderlich, von daher macht man sowas m.E. lieber auf die "analoge" Weise per Frontend?
Timer/Wecker würde ich auf den Bereich bis 24h beschränken, und dafür lieber die Option vorsehen, über (das bereits in Teilen implementierte) Feature "$label" iVm. "specials" auch andere Aktionen auszulösen (also den speak-Befehl durch was anderes zu tauschen (oder zu ergänzen) - dann wäre evtl. auch das "Spiele eine WAV zum Zeitpunkt x ab" recht einfach umzusetzen...

ZitatBzgl. Groß-/Kleinschreibung unterstütze ich die Kleinschreib-Fraktion. Modulintern sollten wir alles klein behandeln, was wir verarbeiten müssen.
Thx.

Zitat
Soll ich eine neue "stable" machen und die als Hauptversion in GitHub markieren? Dann kommt keiner mehr auf die Idee, eine alte Version zu nehmen.
Wenn, dann m.E. die hier angehängte...
Ist aber eben noch recht wenig getestet.

ZitatDurch meine ungewollte Abwesenheit bekomme ich leider viel nicht mit. Es wäre daher superpraktisch, wenn jemand von euch in der README/CRef mitdokumentieren würde damit wir nichts vergessen.
Das wäre jetzt dann der nächste Schritt, werde das mal bei Gelegenheit angehen.
Bis dato sollte das meiste mit der "alten" Anleitung funktionieren, nicht dokumentiert sind eher die neuen Sachen...

PS: die sentences für den Wecker:
[de.fhem:SetTimer]
( timer | wecker ) [$TimerNames{label}] auf [((1..60){hour} (stunde|stunden) | (1..24){hourabs} (uhr) )] [und] [((1..60){min})]
( timer | wecker ) [$TimerNames{label}] auf [((1..60){hour} (stunde|stunden) | (1..24){hourabs} (uhr) )] [und] [((1..60){min} (minute|minuten))] [und] [((1..60){sec} (sekunde|sekunden))]
( timer | wecker ) [$TimerNames{label}] auf (1..60){hour} (einviertel{min:15}|einhalb{min:30}|dreiviertel{min:45}) (stunde|stunden)
( timer | wecker ) [$TimerNames{label}] auf (1..60){min} (einviertel{sec:15}|einhalb{sec:30}|dreiviertel{sec:45}) (minute|minuten)

Der slot $TimerNames muss separat angelegt werden und kann beliebige Schlagworte enthalten.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 25 März 2021, 10:32:12
Vorgezogene Doku
Zitat von: Treibhaus am 25 März 2021, 09:46:52
wie generiert man Text -> Sprachausgabe nach den neuen Updates. D.h.erzeugt eine Sprachausgabe ?
[...] Version 4.6a.
Kommt darauf an:
Shortcuts ("alte" Syntax ) und CustomIntent:
ton aus={fhem ("set lampe1 off")}In beiden Fällen wird Perlcode ausgeführt. Was da zurückkommt, sollte als response verwendet werden (=>wenn es nicht klappt, ist es ein bug), ausgenommen der Fall, dass "nichts" (echtes undef) zurückkommt; dann sollte die "DefaultConfirmation" ertönen.

Shortcuts neu enthält dann noch die Option, bei erfolgreicher Ausführung "r:" anzugeben, und da die Response reinzuschreiben.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 25 März 2021, 10:36:51
Zitat von: Beta-User am 25 März 2021, 08:40:28
dann wäre evtl. auch das "Spiele eine WAV zum Zeitpunkt x ab" recht einfach umzusetzen...

Mein ursprünglicher Plan war sowieso, eine WAV abspielen zu lassen. Und zwar so lange, bis man sie mit "stopp(e den Timer)" stoppt. Deswegen auch die playWAV-Geschichte. Die Sprachausgabe war nur eine Übergangslösung.
Ich kam nur nicht dazu, das umzusetzen. Und mir fehlt eine brauchbare WAV-Datei. Falls jemand eine hat, nur her damit. Und ich weiß nicht, wie man die solange wiederholen könnte, bis eine Stopp-Anweisung kommt.

Zitat
Wenn, dann m.E. die hier angehängte...

Erledigt
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 25 März 2021, 10:59:44
Übergangsweise: Die "Flasche (https://forum.fhem.de/index.php/topic,113180.msg1130450.html#msg1130450)" von JensS? (Für die "finale Fassung" müßte man was copyright-unverdächtiges suchen, evtl. irgendeinen (konvertierten) Linux-Systemsound?)

Das mit dem "Stop" bringt mich auf einen weiteren Ast:
- Das Default-Abspielen könnte man in eine at-Schleife packen, wobei ich die Zahl der Wiederholungen nicht bei Unendlich sehe.
- "Stop" sollte eine Anweisung unterhalb des SetTimer-intents sein, dann kann man das at gezielt "abschießen"; das wäre sowieso ein Thema, denn- "Cancel" könnte noch ein weiterer Zweig in SetTimer darstellen, mit dem man den Timer löscht.

Die ganze Logik würde sich dann erweitern, indem erst geschaut wird, ob eines der beiden "Keywords" in $data drin ist (siehe den Shortcuts-Code zu "confirm"). Das sollte dann auch direkt mit "$label" "spielen" können...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 25 März 2021, 13:53:05
Ziemlich genau so war mein Plan.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 25 März 2021, 16:18:38
Zitat von: laberlaib am 25 März 2021, 14:19:45
Ist 0.4.6a die aktuell "stabilste"?
also immer die, die man erhält, wenn man hier
https://github.com/drhirn/fhem-rhasspy (https://github.com/drhirn/fhem-rhasspy)
hin geht?
Na ja, wie "stabil" die ist, wird man sehen, da steht jedenfalls die version die ich heute morgen hier angehängt hatte...

Hier wäre jetzt eine im Angebot, die eine aktuelle cref enthält, die bisher verfügbaren Attribute und Optionen etwas ordnet und die Syntax an sich erklärt, vom Code her ist das ausnahmsweise mal unverändert. (die html-Konsistenz ist noch nicht geprüft)

Es wäre daher nett, wenn du die nehmen könntest (bis drhirn das auch nochmal durchgegangen ist und/oder wieder was neues via der von dir genannten github-Stelle kommt), dann kannst du nämlich auch gleich Rückmeldung geben, ob alles halbwegs stringent erklärt ist, auch zur Vorgehensweise bei der Einrichtung und so...

Zitat von: drhirn am 25 März 2021, 13:53:05
Ziemlich genau so war mein Plan.
Dann mal nur zu ;D !
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 25 März 2021, 18:25:18
Was haltet Ihr davon, die Sprachdatei per Knopfdruck in fhem/FHEM zu generieren?
Die Hashes dazu wären bereits da, die Sprache wäre auch bekannt und als User müsste man nicht auf die Konsole.
Zum editieren würde man über "Edit files -> Own modules and helper file" rankommen.

@Beta-User
Mit den Rechten an der Flasche hast Du natürlich recht. Da war ich wohl zu voreilig.

Gruß Jens
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 25 März 2021, 21:41:28
Zitat von: JensS am 25 März 2021, 18:25:18
Was haltet Ihr davon, die Sprachdatei per Knopfdruck in fhem/FHEM zu generieren?
Die Hashes dazu wären bereits da, die Sprache wäre auch bekannt und als User müsste man nicht auf die Konsole.
Zum editieren würde man über "Edit files -> Own modules and helper file" rankommen.
Wäre nicht das große Problem, aber:
- Der Befehl, um schnell mal einen Export zu machen ist jetzt schon in der cref drin ;) .
- Mittelfristig wäre es gut, eine kleine Sammlung via svn/contrib verfügbar zu machen. Von da kann man sie mit einem speziellen Befehl auch direkt (mit passenden Rechten) aus FHEM runterladen. Aber auch dafür sollte cref eigentlich ausreichend sein.

Zitat
Mit [...] der Flasche
Kein Problem; ist ja nur ein Schnipsel... Mir geht es halt darum, da für die "offizielle Fassung" gar nicht erst in irgendeinen Graubereich zu kommen.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 25 März 2021, 22:21:06
Zitat von: laberlaib am 25 März 2021, 21:54:35Also, welche FHEM-Rhasspy-Version soll ich den nun nehmen?
Schon alleine wegen der cref: Mit ziemlicher Sicherheit => die letzte hier angehängte!
(EDIT: Ist nun auch im git unter https://github.com/drhirn/fhem-rhasspy/blob/0.4.6a/10_RHASSPY.pm verfügbar.)

ZitatJetzt will ich natürlich nicht je zwei Satelliten nebeneinander haben, einmal Deutsch, einmal Spanisch. Also ist mein Ziel derzeit (neben dem langfristigen, das mir mal im Code anzuschauen, siehe Thread in der rhasspy Community) das Ganze via MQTT-Bridging hinzubekommen (meine bisherigen Anstrengungen siehe auch dort drüben).
Ich _glaube_, dass es möglich sein sollte, zwei (oder mehr) rhasspy-Dienste parallel laufen zu lassen (auf derselben Plattform), einen mit de-profile und einen mit "es", das ganze über einen Broker.

In der aktuellen cref sind ein paar Hinweise drin, wie ich _glaube/mir nach jetzigem Stand vorstelle_, dass man mehrere RHASSPY-Instanzen auf einem FHEM laufen haben kann.

ZitatUnd falls drhirn/Beta-User soweit lesen: der Group-seperator wird in die site-id eingetragen und so trennt sich Gruppen- und Raumnamen. Entweder kann man das in den FHEM-rhasspyRoom-Attributen irgendwie mitgeben, oder aber man muss eben die site_id (Gruppe-Trenner-Name) und den echten Namen eintragen; einmal zu lernen und einmal falls man keinen Raum sagt und man den Raum, wo sich der Satellit befindet meint. Wenn ich sowas mal ernsthaft braucht, formuliere ich das besser.
Das habe ich nicht verstanden, ich würde optimalerweise MQTT-Rohdaten benötigen (siehe die Beispiele im Repo von drhirn), dann wird es evtl. klarer.

(Ich will nicht in dem anderen Thread zu viele Anwenderdetails diskutieren, die ich sowieso vermutlich noch nicht im Detail nachvollziehen kann; wenn es spezielle Themen gibt, die mit Mehrsprachigkeit zu tun haben, bitte melden und ggf. einfach einen neuen Thread dazu aufmachen?)
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: laberlaib am 26 März 2021, 13:40:42
Zitat von: Beta-User am 25 März 2021, 22:21:06
Schon alleine wegen der cref: Mit ziemlicher Sicherheit => die letzte hier angehängte!
(EDIT: Ist nun auch im git unter https://github.com/drhirn/fhem-rhasspy/blob/0.4.6a/10_RHASSPY.pm verfügbar.)
Ich _glaube_, dass es möglich sein sollte, zwei (oder mehr) rhasspy-Dienste parallel laufen zu lassen (auf derselben Plattform), einen mit de-profile und einen mit "es", das ganze über einen Broker.

In der aktuellen cref sind ein paar Hinweise drin, wie ich _glaube/mir nach jetzigem Stand vorstelle_, dass man mehrere RHASSPY-Instanzen auf einem FHEM laufen haben kann.
Das habe ich nicht verstanden, ich würde optimalerweise MQTT-Rohdaten benötigen (siehe die Beispiele im Repo von drhirn), dann wird es evtl. klarer.

(Ich will nicht in dem anderen Thread zu viele Anwenderdetails diskutieren, die ich sowieso vermutlich noch nicht im Detail nachvollziehen kann; wenn es spezielle Themen gibt, die mit Mehrsprachigkeit zu tun haben, bitte melden und ggf. einfach einen neuen Thread dazu aufmachen?)

Danke wieder Mal für den ganzen Aufriss.
Das SNIPS-Modul hab ich sogar halbwegs verstanden, das was hier gerade entsteht...

Mehrere RHASSPY-FHEM-Instanzen sind nicht das Problem bei mir, da ich ja einfach alles doppelt anlegen kann - wie dann die Slots geupdatet werden ist eher ein Luxusproblem, zur Not mach ich das manuell bzw. bau mir irgendwas.
Das Problem ist eher, dass sich in Rhasspy die Services gegenseitig in die Quere kommen und dann mehrfach gestartet werden, wenn da zwei Master auf dem selben Broker laufen. Weil nur der Dialogservice kann nach Wakeword unterscheiden, die anderen nehmen die siteID. D.h. sobald die Soundübertragung von einem Satellite "Wohnzimmer" losgeht, dann hören beide Master zu und das setzt sich dann fort. Ich hatte dann nach einem Wakeword 2^3 = 8 Resultate: 1 Wakeword aktiviert 2 Soundstreams welche an 2 Spracherkenner weitergegeben werden und diese wieder rum an 2 Intenterkenner (oder so ähnlich).

Du hast mich gerade aber auf die Idee gebracht, zwei Instanzen auf einem Satelliten laufen zu lassen, unterschiedliche Wakewords dran zu hängen und unterschiedliche SiteId (Wohnzimmer, salon) zu geben und dann den SiteID-Trennermechanismus zu nutzen. Das wird vermutlich an der gleichzeitigen Nutzung der Soundhardware scheitern. Außer wiederum das wäre mit Pulseaudio irgendwie geregelt zu bekommen...
Dann bin ich aber wieder beim reinfrickeln in Software und da schlägt für mich derzeit MQTT-Gefrickel Pulseaudiogefrickel um längen. Ersteres ist irgendwie transparent, verständlich und im MQTT-Explorer nachvollziehbar; letzteres eine Blackbox.

Den Groupseperator erläutere ich bei Gelegenheit.

Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 26 März 2021, 14:08:39
Auf die Schnelle ein paar Gedanken dazu:

Zitat von: laberlaib am 26 März 2021, 13:40:42Danke wieder Mal für den ganzen Aufriss.
Gerne :) !

Zitat
Das SNIPS-Modul hab ich sogar halbwegs verstanden, das was hier gerade entsteht...
Das SNIPS-Modul kannte ich nicht, aber m.E. ist durch die ganzen Änderungen vieles für die Einrichtung _vereinfacht_ worden. Insbesondere ist es durch die "language" und "prefix"-Optionen möglich, zwei sehr unterschiedliche Instanzen von RHASSPY in einem FHEM laufen zu lassen - beide jeweils mit einem anderen "Master" (an der Stelle fremdlich ich noch etwas mit den Begrifflichkeiten), also der eine z.B. auf localhost:12101 und der andere auf localhost:12102.

Aber falls das die Rückmeldung war, dass die cref in der jetzigen Form (noch) nicht verständlich ist: Bin für Verbesserungsvorschläge offen (und drhirn vermutlich dankbar!)...

Zitat
Mehrere RHASSPY-FHEM-Instanzen sind nicht das Problem bei mir, da ich ja einfach alles doppelt anlegen kann - wie dann die Slots geupdatet werden ist eher ein Luxusproblem, zur Not mach ich das manuell bzw. bau mir irgendwas.
Wenn jede RHASSPY-Instanz ihren Master kennt, sollten auch die (von FHEM aus geschriebenen) slots sauber up-to-date zu halten sein.

Zitat
Das Problem ist eher, dass sich in Rhasspy die Services gegenseitig in die Quere kommen und dann mehrfach gestartet werden, wenn da zwei Master auf dem selben Broker laufen. [...]
Ich kann zwar das Problem erahnen, aber eigentlich müßte das ganze doch so intelligent sein, dass "erst mal" nur der (jeweilige) Master aufgeweckt wird (setzt unterschiedliche Wakewords voraus) und halt "seinen" Dialog mit dem einen Satelliten führt. Aber evtl. fehlt mir da noch die praktische Erfahrung mit dem Ganzen.

Zitat[...] Pulseaudiogefrickel [...]
Falls dir das Stichwort MPD was sagt: Auf der Hardware, auf der mein derzeitiger Master untergegracht ist, läuft auch ein MPD. Da ich von daher wußte, dass Audioausgaben durch unter anderen Usern laufende Services ein ziemlicher Showstopper sind, habe ich es vorsichtshalber für rhasspy genauso gemacht: beides wird in der user-Sphäre nach (automatischem) login automatisch gestartet, so dass auch (gleichzeitiger) Zugriff auf die Soundschnittstellen gar kein Problem sind (bzw. wären...).
Der Artikel hier wäre ggf. ein geeigneter Startpunkt: https://wiki.ubuntuusers.de/MPD/MPD_auf_der_Benutzerebene/

Und dem Bauchgefühl nach müßte es auch möglich sein, rhasspy doppelt unter demselben User mit unterschiedlichen Profilen zu starten.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 26 März 2021, 14:55:20
Zitat von: Beta-User am 26 März 2021, 14:08:39
Und dem Bauchgefühl nach müßte es auch möglich sein, rhasspy doppelt unter demselben User mit unterschiedlichen Profilen zu starten.

Das ist ganz sicher so.

Wichtig für laberlaib: Du brauchst natürlich zwei unterschiedliche Broker! In Folge dessen auch 2 MQTT2_DEVICEs.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: laberlaib am 26 März 2021, 15:02:37
Sicher ist alles einfacher geworden und alle festen Texte sind raus, aber sowas
if ( defined $hash->{helper}{shortcuts}{$data->{input}}{conf_timeout} && !$data->{Confirmation} ) {
braucht erst einmal Zeit, sich ins Hirn zu fressen (mindestens wenn man kein Dr. ist).

Zitat von: Beta-User am 26 März 2021, 14:08:39
Falls dir das Stichwort MPD was sagt: Auf der Hardware, auf der mein derzeitiger Master untergegracht ist, läuft auch ein MPD. Da ich von daher wußte, dass Audioausgaben durch unter anderen Usern laufende Services ein ziemlicher Showstopper sind, habe ich es vorsichtshalber für rhasspy genauso gemacht: beides wird in der user-Sphäre nach (automatischem) login automatisch gestartet, so dass auch (gleichzeitiger) Zugriff auf die Soundschnittstellen gar kein Problem sind (bzw. wären...).
Der Artikel hier wäre ggf. ein geeigneter Startpunkt: https://wiki.ubuntuusers.de/MPD/MPD_auf_der_Benutzerebene/
Danke, ich klick mich da mal durch. Ich dachte immer, dass wäre eher so was wie Squeezeserver/box.

Wichtig ist, dass das auch für das Mikrofon gilt. Und im Schreiben fällt mir dann auf, dass ja der Befehl für den einen Satellitenservice gleichzeitig im anderen auf das Wakeword untersucht wird: Wenn also Alexa Porcupinen kaufen soll, dann habe ich ein Problem. Bei einem Satellite wird afaik die Hotworderkennung ausgeschalten, wenn er gerade etwas an die Spracherkennung streamt.

Im Grunde ist das MQTT-Zeug eigentlich auch sehr einfach zu testen:
- Broker mit -v starten, Kommunikation aufzeichnen und die topics merken welche jeweils beschrieben werden.
- Beide Instanzen auf eigenen Broker setzen, wobei einer extern aber auf der gleichen Maschine läuft, dann ist es einfacher mit der mosquittoconfig.
- Die Bridgekonfiguration kann soweit ich da bisher verstehe In und Out, d.h. es reicht, wenn bspw. jeweils auf dem Satellite die Bridge konfiguriert ist. Diese gibt dann die entsprechenden Topics weiter bzw. holt sich die notwendigen. An den Zentralinstanzen muss man dann nur die Satellitennamen reinkonfigurieren (das muss man eh immer) und die Inbetriebnahme eines Satelliten erfordert immer etwas mehr Arbeit (Automatischer Start per cron, Soundkarte installieren etc) da fällt dann die Bridgekonfiguration auch nicht mehr ins Gewicht.

Hätte ich mich nicht nachts um 22:00 Uhr letztes Wochenende komplett verrannt und verkonfiguriert, hätte ich das schon am Start.

Ich berichte weiter.

Zitat von: drhirn am 26 März 2021, 14:55:20
Das ist ganz sicher so.

Wichtig für laberlaib: Du brauchst natürlich zwei unterschiedliche Broker! In Folge dessen auch 2 MQTT2_DEVICEs.

Zwei Broker für die Zentralinstanzen hab ich auch und auch alles was dazu gehört. Das hat mit auch 0.2 funktioniert.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 26 März 2021, 15:38:01
Zitat von: laberlaib am 26 März 2021, 15:02:37
Sicher ist alles einfacher geworden und alle festen Texte sind raus, aber sowas
if ( defined $hash->{helper}{shortcuts}{$data->{input}}{conf_timeout} && !$data->{Confirmation} ) {
braucht erst einmal Zeit, sich ins Hirn zu fressen (mindestens wenn man kein Dr. ist).
Da hast du dir aber eine schöne Stelle ausgesucht ;D ;D ;D ...

Bin auch kein Dr., und als "normaler Anwender" braucht man ja eigentlich auch nicht ganz so weit unter das Auto liegen...

Zitat
Danke, ich klick mich da mal durch. Ich dachte immer, dass wäre eher so was wie Squeezeserver/box.
Ist nicht ganz falsch, aber ich nutze das als netzwerkfähigen Audioplayer mit direkter Soundausgabe an den Verstärker (den muss(te) ja jemand befüllen (als der noch keinen LAN-Port hatte).

Wichtig in dem Zusammenhang war eben die Frage, wie man den gemeinsamen Zugriff auf pulseaudio ermöglichen kann, habe aber k.A., ob das auch das Mikro umfasst.

Zitat
Zwei Broker für die Zentralinstanzen hab ich auch [...]
Mein Bauchgefühl meint, dass es mit nur einem Broker einfacher sein sollte, kann aber auch falsch liegen.
Aber bei zwei Sprachen müssen es zwei Dienste sein, die jeweils Wakeword und speechrecogn. machen, und ich neige zu der Auffassung, dass (auch) die Audioübertragung optimalerweise nur über MQTT laufen sollte (da sonst unterschiedliche UDP-Ports gewählt werden müßten).

In meiner Welt wären das also ein mosquitto und auf der FHEM-Seite 1xMQTT2_CLIENT, 2xRHASSPY.

Aber vermutlich bin ich nicht tief genug in der Materie drin...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 26 März 2021, 16:02:44
Zitat von: Beta-User am 26 März 2021, 15:38:01

In meiner Welt wären das also ein mosquitto und auf der FHEM-Seite 1xMQTT2_CLIENT, 2xRHASSPY.

Aber vermutlich bin ich nicht tief genug in der Materie drin...

Stimmt, könnte jetzt funktionieren. Wenn's zwei unterschiedliche Sprachen sind und die Rhasspy-Sentences richtig benannt werden (z.B. [es.fhem.SetOnOff] und [de.fhem.SetOnOff]).
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 26 März 2021, 16:17:35
Zitat von: drhirn am 26 März 2021, 16:02:44
Stimmt, könnte jetzt funktionieren. Wenn's zwei unterschiedliche Sprachen sind und die Rhasspy-Sentences richtig benannt werden (z.B. [es.fhem.SetOnOff] und [de.fhem.SetOnOff]).
Oder die andere Option gewählt wird, das bisher vermutlich noch unverständliche "fhemId" zu setzen :P . Aber das ist eher für den Fall gedacht, dass man mehrere FHEM-Instanzen hat (oder unterschiedliche User mit unterschiedlichen Rechten auf derselben Instanz)...

Aber klar, die sentences müssen dann (jeweils) auch zum gewünschten "Ziel" (RHASSPY-Instanz auf irgendeiner fhemId) führen ;) . Hoffe, das auch halbwegs klar in der cref dargestellt zu haben, welches Schräubchen für welchen Fall getweakt werden sollte...?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 26 März 2021, 17:30:09
Zu dem hier nochmal:
Zitat von: Treibhaus am 25 März 2021, 09:46:52
Guten Morgen,

wie generiert man Text -> Sprachausgabe nach den neuen Updates.

Zitat von: Beta-User am 25 März 2021, 10:32:12
Vorgezogene Doku[...]
Kommt darauf an:Shortcuts ("alte" Syntax ) und CustomIntent:
ton aus={fhem ("set lampe1 off")}In beiden Fällen wird Perlcode ausgeführt. Was da zurückkommt, sollte als response verwendet werden (=>wenn es nicht klappt, ist es ein bug), ausgenommen der Fall, dass "nichts" (echtes undef) zurückkommt; dann sollte die "DefaultConfirmation" ertönen.

Shortcuts neu enthält dann noch die Option, bei erfolgreicher Ausführung "r:" anzugeben, und da die Response reinzuschreiben.
Die Langfassung nochmal:

Ich habe keine Ahnung, wie es früher funktioniert hat. Da stand zwar was zu einem nicht mehr existenten Attribut in die Richtung in der bisherigen commandref, aber Code dazu gab es nicht, (auch schon nicht in 0.2.0).

Mein Vorschlag dazu ist, über shortcuts Perl-Code aufzurufen, der dann den anzusagenden Text zurückgibt. Will sagen: Das, was in dem Ausgangsbeitrag (https://forum.fhem.de/index.php/topic,113180.msg1135365.html#msg1135365) mal steand, geht (fast) noch 1:1, du musst nur (zusätzlich) klarmachen, dass Perl ausgeführt werden soll => passende Klammern drumrum, und schon findest du im list auch den freundlichen Hinweis, dass es als Perl-Code erkannt worden  ist:
attr RHASSPY shortcuts ton aus={fhem ("set lampe1 off")}\
i="du bist cool" f="set $NAME speak siteId='wohnzimmer' text='Danke du auch'"\
i="ton an" p={fhem ("set $NAME on")} n=lampe1 c="Bitte bestätigen!"\
Witze={Witze()}


Bei der Gelegenheit noch: FHEM hat interne Routinen für das Handling von files => es geht auch eleganter:
sub Witze {
  my ($err, @Witze_array) = FileRead("./Witze_erzaehlen.txt");
  return $err if $err; #Wir bekommen direkt eine Fehlermeldung angesagt, wenn etwas schief geht (englisch halt...)
  my $Zufall = int(rand(@Witze_array+1)); #sicher mit der +1? Muss m.E. weg...
  chop $Witze_array[$Zufall]; #hat das letzte Zeichen weg
  #Log3('rhasspy',3 , "RHASSPY: $Witze_array[$Zufall]");
  return $Witze_array[$Zufall];
}


Nachtrag:
Da auch "Witze=Witze()" als Perl-Command im list angezeigt wird, habe ich in der angehängten Fassung das Handling umgestellt.

Da sind auch einige noch nicht wirklich getestete Änderungen bzgl. der Verwaltung der "Gruppen-Queue" drin, damit man keine anonymen subs braucht und das ganze ggf. auch "mischen" kann, falls weitere (Gruppen) Anweisungen dazukommen...
Außerdem könnte "Cancel" für timer gehen ;) .
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 26 März 2021, 19:14:42
Danke für deine Kommentare, so kann ich dazu lernen.

Witze():
Die letzte Fassung war speicherschonender, da die Variable immer nur eine Zeile enthält. Und man weiß ja nicht, wie groß die Datei mal wird.
https://forum.fhem.de/index.php/topic,113180.msg1133690.html#msg1133690 (https://forum.fhem.de/index.php/topic,113180.msg1133690.html#msg1133690)
Zitatmy $Zufall = int(rand(@Witze_array+1)); #sicher mit der +1? Muss m.E. weg...
Wenn das Witzearray 124 Zeilen erfasst, wird bei int(rand(124)) niemals die Zeile 124 vorgelesen. Daher dachte ich, +1 könnte nicht schaden.

Mehrsprachigkeit:
Man müsste tatsächlich zwei separate Systeme (Rhasspy & FHEM-Bridge) mit unterschiedlichen Ports aufbauen und das Mikro zweimal abgreifen. Eventuell geht das ja mit PyAudio.?

Gruß Jens
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: laberlaib am 26 März 2021, 22:58:16
Eine einfach Konfiguration ohne die Nutzung eines gemeinsamen Brokers für eine Sprache:
Zentralinstanz: Internen Broker auf 12183
Satellite: Externen Broker auf localhost 1883, gestartet mit "mosquitto -c mosquitto.conf", was man auch als Service hinterlegen kann.
In der mosquitto.conf das hier ergänzt:

#connection bridge2Spain
connection bridge2Spain
address 192.168.2.122:12183
try_private true
topic hermes/audioServer/+/audioFrame out
topic hermes/audioServer/+/playFinished out
topic hermes/hotword/+/detected out

topic hermes/asr/# in
topic hermes/audioServer/+/playBytes/# in
topic hermes/dialogueManager/# in
topic hermes/hotword/toggleOff in
topic hermes/hotword/toggleOn in
topic hermes/intent/# in
topic hermes/nlu/# in
topic hermes/tts/# in


Das "tüt mir leid, es kein widdrgabegerrt aktf" hat hier für Lacher gesorgt.

Jetzt werd ich morgen die bridge2Germany integrieren und schauen, ob sich das System verschluckt.

Das Problem liegt niemals bei FHEM sondern immer in Rhasspy, wo jede Instanz Intentrecogniction macht. Und man kann eben nie sagen, ob ein deutscher Satz nicht auch irgendwie einen spanischen (oder englischen oder plattdeutschen o.ä.) auslöst. Das muss verhindert werden. Weil denkbar ist ja nicht nur, dass man unterschiedliche Sprachen hat sonden einfach die Genauigkeit erhöhen will. "Fettes Brot" soll nicht auf die Einkaufsliste (Wakeword "Tante Emma") sondern in aus den Boxen (Wakeword "Hey DJ") kommen.
Dann lehre ich den jewieligen Zentralinstanzen nur die notwendigen Intents in den sentences.ini und fertig.

Zitat von: Beta-User am 26 März 2021, 15:38:01
Bin auch kein Dr., und als "normaler Anwender" braucht man ja eigentlich auch nicht ganz so weit unter das Auto liegen...
Das war eher als Seitenhieb auf DrHirn gedacht.

Edit: Rhasspy hat die Top 3 im Unterforum Sprachsteuerung erobert!


Edit2: Was du heute kannst besorgen:
mosquitto.conf erweitert:
connection bridge2Germany
address 192.168.2.121:12183
try_private true
topic hermes/audioServer/+/audioFrame out
topic hermes/audioServer/+/playFinished out
topic hermes/hotword/+/detected out

topic hermes/asr/# in
topic hermes/audioServer/+/playBytes/# in
topic hermes/dialogueManager/# in
topic hermes/hotword/toggleOff in
topic hermes/hotword/toggleOn in
topic hermes/intent/# in
topic hermes/nlu/# in
topic hermes/tts/# in


/usr/lib/rhasspy/rhasspy-dialogue-hermes/rhasspydialogue_hermes/___init___.py
auf den beiden Zentralinstanzen in Zeile ~150 erweitert:
        #self.wakeword_ids: typing.Set[str] = set(wakeword_ids or [])
        #ZENTRALINSTANZ DE
        #self.wakeword_ids = ["alexa"]
        self.wakeword_ids = ["snowboy"]

bzw.
        #self.wakeword_ids: typing.Set[str] = set(wakeword_ids or [])
        #ZENTRALINSTANZ ES
        #self.wakeword_ids = ["snowboy"]
        self.wakeword_ids = ["alexa"]


Die Spanische Instanz versteht immer nur lauter/leiser und findet um diese Uhrzeit bei schlafenden Kindern und Frauen weiterhin kein Wiedergabegerät.
Die Deutsche Instanz macht irgendwas aber von der bekomme ich derzeit noch 2 Oks - besser als 8 und da lässt sich sicherlich noch was filtern.
Edit3: Also zur Verdeutlichung: Wenn sie jeweils angesprochen werden. Wenn nicht, dann bleiben sie komplett still. Es antwort also immer nur eine.

Ich habe jeweils zum Testen immer das Wakeword auf "Alexa" gestellt, "Snowboy" versteht mich nur einmal von 10 Versuchen.
Das Ignorieren durch den Dialogmanager funktioniert aber:
Angereichert mit ein wenig Debugging/Warning von mir:
[WARNING:2021-03-26 22:10:02,419] rhasspydialogue_hermes: Ignoring wake word id=alexa
[WARNING:2021-03-26 22:10:02,419] rhasspydialogue_hermes: len(self.wakeword_ids)
[WARNING:2021-03-26 22:10:02,419] rhasspydialogue_hermes: 1
[WARNING:2021-03-26 22:10:02,420] rhasspydialogue_hermes: self.wakeword_ids
[WARNING:2021-03-26 22:10:02,420] rhasspydialogue_hermes: ['snowboy']


Edith4:
Wenn das Testrhasspydevice auf FHEM meint, es müsste auch ein OK schicken, dann ist klar warum das doppelt kommt.
Für mich siehts nach einer funktionierenden, einfachen Lösung aus.
Jetzt wirklich ins Bett und morgen skalieren.


Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 26 März 2021, 23:24:04
@laberlaib
Dann kannst du alles mit einer Rhasspy-Instance abfrühstücken? Das wird wahrscheinlich nicht funktionieren. Selbst für die Rückgabe brauchst du einen separaten es-TTS.
Ganz zu schweigen vom STT. Kaldi kann angeblich kein spanisch. Da müsstest du wohl auf pocketsphinx ausweichen.
Wie bereits geschrieben, wirst du wohl nicht um zwei Komplett-Installationen und extra M2D + RHASSPY in FHEM nicht herumkommen.
Das würde einem Zero leider das Leben kosten...

Gruß Jens
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: laberlaib am 26 März 2021, 23:28:29
Man man man, wenn die Clubs noch länger zu sind, dann programmiert hier noch jemand Skynet.

Zitat von: JensS am 26 März 2021, 23:24:04
@laberlaib
Dann kannst du alles mit einer Rhasspy-Instance abfrühstücken? Das wird wahrscheinlich nicht funktionieren. Selbst für die Rückgabe brauchst du einen separaten es-TTS.
Ganz zu schweigen vom STT. Kaldi kann angeblich kein spanisch. Da müsstest du wohl auf pocketsphinx ausweichen.
Wie bereits geschrieben, wirst du wohl nicht um zwei Komplett-Installationen und extra M2D + RHASSPY in FHEM nicht herumkommen.
Das würde einem Zero leider das Leben kosten...

Gruß Jens

Zentralinstanzen sind ja nicht das Problem: Proxmox liefert ausreichend von allem.
Aber Satelliten sind rar, da diese auch gleich kabel mitbringen, Audiohardware wollen etc. Aber die machen ja nichts außer sich aktivieren, Audio wo hin schicken und audio empfangen - die TTSGenerierung geschieht ja auf dem Master und den gibts dann in vielen Sprachen.

Siehe mein Edit oben - es scheint zu klappen.
Edit: und das neuste Edit oben ist, dass ich den Grund für da doppelte OK gefunden habe...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: laberlaib am 27 März 2021, 21:44:35
Da meine Konfiguration läuft wollte ich mal auf 0.46a umsteigen und hab hier gleich mal ein:
€: Sie unten, ist wohl ein Tippfehler, das Protokollzeug kann man geflisslich überlesen, ich lass es mal aus historieschen Gründen drin.
2021.03.27 20:41:34 5: handleIntentSetOnOff called
Not a SCALAR reference at ./FHEM/10_RHASSPY.pm line 1229.

Bei Verbose 5
2021.03.27 20:41:34 5: RHASSPY: [RHASSPY_DE] Parse (IO: RhasspyMasterDeMQTT2): Msg: hermes/intent/de.fhem_SetOnOff => {"input": "schalte die Stehlampe an", "intent": {"intentName": "de.fhem:SetOnOff", "confidenceScore": 1.0}, "siteId": "MasterDe", "id": "d6798865-76ff-4a8e-92b6-c0e81c7013fd", "slots": [{"entity": "de.fhem.Device", "value": {"kind": "Unknown", "value": "Stehlampe"}, "slotName": "Device", "rawValue": "stehlampe", "confidence": 1.0, "range": {"start": 12, "end": 21, "rawStart": 12, "rawEnd": 21}}, {"entity": "Value", "value": {"kind": "Unknown", "value": "an"}, "slotName": "Value", "rawValue": "ein", "confidence": 1.0, "range": {"start": 22, "end": 24, "rawStart": 22, "rawEnd": 25}}], "sessionId": "d6798865-76ff-4a8e-92b6-c0e81c7013fd", "customData": null, "asrTokens": [[{"value": "schalte", "confidence": 1.0, "rangeStart": 0, "rangeEnd": 7, "time": null}, {"value": "die", "confidence": 1.0, "rangeStart": 8, "rangeEnd": 11, "time": null}, {"value": "Stehlampe", "confidence": 1.0, "rangeStart": 12, "rangeEnd": 21, "time": null}, {"value": "an", "confidence": 1.0, "rangeStart": 22, "rangeEnd": 24, "time": null}]], "asrConfidence": null, "rawInput": "schalte die stehlampe ein", "wakewordId": null, "lang": null}
2021.03.27 20:41:34 5: Parsed value: SetOnOff for key: intent
2021.03.27 20:41:34 5: Parsed value: schalte die Stehlampe an for key: input
2021.03.27 20:41:34 5: Parsed value: MasterDe for key: siteId
2021.03.27 20:41:34 5: Parsed value: Stehlampe for key: Device
2021.03.27 20:41:34 5: Parsed value: schalte die stehlampe ein for key: rawInput
2021.03.27 20:41:34 5: Parsed value: d6798865-76ff-4a8e-92b6-c0e81c7013fd for key: sessionId
2021.03.27 20:41:34 5: Parsed value: 1 for key: probability
2021.03.27 20:41:34 5: Parsed value: an for key: Value
2021.03.27 20:41:34 5: handleIntentSetOnOff called
Not a SCALAR reference at ./FHEM/10_RHASSPY.pm line 1229.


Und dann Neustart.
Geschalten werden soll dieser Dummy:
defmod du_Dummyschalter dummy
attr du_Dummyschalter rhasspyMapping SetOnOff:cmdOn=on,cmdOff=off\
GetOnOff:currentValue=state,valueOff=off
attr du_Dummyschalter rhasspyName Stehlampe
attr du_Dummyschalter rhasspyRoom Wohnzimmer
attr du_Dummyschalter room Rhasspy


Das ist mein RHASSPY:
defmod RHASSPY_DE RHASSPY room=Rhasspy defaultRoom=Wohnzimmer language=de
attr RHASSPY_DE IODev RhasspyMasterDeMQTT2
attr RHASSPY_DE rhasspyMaster http://192.168.2.121:12101
attr RHASSPY_DE room Rhasspy
attr RHASSPY_DE verbose 5


Ist eine eben aufgesetzte neue Installation von FHEM.

Edit: würde mal sagen Tippfehler:
https://github.com/drhirn/fhem-rhasspy/blob/0.4.6a/10_RHASSPY.pm
ab Zeile 1227
 
    my $room;
    $room = $
    $data->{siteId};


mal "_;" angefügt, jetzt läufts.

Und wie gut ist das bitte mit der Sprachkonfig? Hat auf Anhieb geklappt.

Die prefix-Geschichte für unterschiedliche Attribute, die geht noch nicht wenn ich das richtig verstehe.
Aber die Slots werden schon in Abhängigkeit der Sprache gefüttert, das konnte ich sehen.
D.h. ich schreib alles zur Benennung in die rhasspy*-Attribute rein und lösche dann auf meinem Master die wieder raus, die er nicht lernen muss - damit kann ich erstmal leben.

Aber für die Hilfe (Device specific help) bekomme ich das hier:
No help found for module: rhasspy
Sollte da nicht das kommen, was ganz unten steht, also cref?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 28 März 2021, 09:25:30
Zitat von: laberlaib am 27 März 2021, 21:44:35
Edit: würde mal sagen Tippfehler:
https://github.com/drhirn/fhem-rhasspy/blob/0.4.6a/10_RHASSPY.pm
ab Zeile 1227
 
    my $room;
    $room = $
    $data->{siteId};


mal "_;" angefügt, jetzt läufts.

Das soll wohl
$room = $data->{siteId};
heißen. Hab eine korrigierte Version auf GitHub hochgeladen.

Zitat
Aber für die Hilfe (Device specific help) bekomme ich das hier:
No help found for module: rhasspy
Sollte da nicht das kommen, was ganz unten steht, also cref?
Geht bei mir. Kann es sein, dass das erst nach deiner Änderung passiert ist? Schau mal nach, ob das bei dir noch UTF-8 codiert ist und die Zeilenenden (EOL) auf LF (Unix) stehen. FHEM mag das gar nicht, wenn da was falsch codiert ist.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: laberlaib am 28 März 2021, 09:53:55
Zitat von: drhirn am 28 März 2021, 09:25:30
Geht bei mir. Kann es sein, dass das erst nach deiner Änderung passiert ist? Schau mal nach, ob das bei dir noch UTF-8 codiert ist und die Zeilenenden (EOL) auf LF (Unix) stehen. FHEM mag das gar nicht, wenn da was falsch codiert ist.

Exakt das wars, danke.

Ich übersetze nun mal die Sprachkonfigration ins Spanische und folgende Frage:
Ist das fehlende "M" bei den letzten beiden Absicht?
    'DefaultConfirmation' => "OK",
    'DefaultConfirmationTimeout' => "Sorry too late to confirm",
    'DefaultCancelConfir' => "Thanks aborted",
    'DefaultConfirReceived' => "ok will do it",


Und dann ist Sprache super kompliziert (dies ist nun ausdürcklich kein Featurerequest sondern eine Feststellung und es wird dafür passende Formulierungen für die Sprachkonfiguration geben): aus "ausgeschaltet" wird im spanischen (französischen, italienischen) je nach Geschlecht "apagdo" oder "apagada". Des Weiteren "ist" es dort ein Uhr, "sind" es aber zwei Uhr.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 28 März 2021, 10:05:31
Das mit dem M muss dir Beta-User beantworten.

Und bzgl. Sprache ist Mitarbeit herzlich willkommen. Ich kann zwar "einen Aschenbecher bitte" in ziemlichen vielen Sprachen. Aber ansonsten ist bei mir nach Englisch und Deutsch leider Schluss.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 28 März 2021, 10:12:41
Vorab mal sorry für die übersehene "Unvollendete"...

Der Plan war eigentlich, an der Stelle zwei "Andockstellen" einzubauen, nämlich für Code ("rhasspyTweaks") und für das Auslesen eines zusätzlichen Readings (siteId2room_mobile1 etc.). Das klappt aber grade noch nicht so, wie ich mir das vorstelle, daher ein andermal mehr dazu.

Falls jemand Lust hat, das auszutesten bzw. weiter zu entwickeln, das ist mein aktueller Stand:
sub RHASSPY_roomName {
    my $hash = shift // return;
    my $data = shift // return;

    # Slot "Room" im JSON vorhanden? Sonst Raum des angesprochenen Satelites verwenden
    return $data->{Room} if exists($data->{Room});
   
    my $room;
   
    #Beta-User: This might be the right place to check, if there's additional logic implemented...
   
    my $rreading = makeReadingName("siteId2room_$data->{siteId}");
    $room = ReadingsVal($hash->{NAME}, $rreading, $data->{siteId});
    $room = $hash->{helper}{defaultRoom} if ($room eq 'default' || !(length $room));

    return $room;
}




Zitat von: laberlaib am 27 März 2021, 21:44:35
Und wie gut ist das bitte mit der Sprachkonfig? Hat auf Anhieb geklappt.
8)

Wäre natürlich nett, wenn du eine spanische Variante einstellen könntest...

Zitat
Die prefix-Geschichte für unterschiedliche Attribute, die geht noch nicht wenn ich das richtig verstehe.
ist das eine Rückmeldung oder eine Frage?!?

"Eigentlich" müßte das mAn. funktionieren, aber getestet habe ich es bisher nicht. Was (derzeit) NICHT geht, wäre das prefix im laufenden Betrieb zu ändern, aber eine zweite Instanz mit anderem (auch nachträglich geändertem) prefix sollte eigentlich ohne weiteres laufen.




Schon jemand mit den Timern rumgespielt? Leider paßt da scheinbar noch nicht alles, aber ich bekomme immerhin gelabelte Timer, und kann die auch - entgegen der Rückmeldung - abschießen...

Die sind jetzt als "temporary"-at angelegt und daher nur noch via list-Kommando zu sehen; weiß noch nicht, ob das eine gute Idee ist.

Hier noch der sentences-Teil zum labeln und testen:
[de.fhem:SetTimer]
labels=( Wecker | Eier | Kartoffeln | Tee )
( Lösche | entferne ){Cancel} [den] ( timer | wecker ) [<labels>{label}]




Das mit den fehlenden "m" sind tendenziell Typos, sollte man wohl noch verbessern.

Und das mit der gegenderten Form ist auch im deutschen ein Thema (z.B. bei Räumen), bisher habe ich dazu noch keine Idee. Wäre aber natürlich schon eleganter, wenn man das irgendwie gelöst bekäme - geht aber nicht, ohne dass der User irgendwas dazu irgendwo einstellt...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: laberlaib am 28 März 2021, 11:17:45
#Fehlends M:
Das zieht sich aber durch den Code durch, z.B. Zeile 1011:
$response = $hash->{helper}{lng}->{responses}->{DefaultCancelConfir};

Zitat von: Beta-User am 28 März 2021, 10:12:41
"Eigentlich" müßte das mAn. funktionieren, aber getestet habe ich es bisher nicht. Was (derzeit) NICHT geht, wäre das prefix im laufenden Betrieb zu ändern, aber eine zweite Instanz mit anderem (auch nachträglich geändertem) prefix sollte eigentlich ohne weiteres laufen.
Da muss ich mal "Folgefehler" rufen. in der README wird das define anders beschrieben, drum habe ich das nicht mit angegeben.
Ich wollte dann ja die cref aufrufen, was bei mir nicht funktionierte. Da ich das nun fixen konnte las ich das hier:
Zitatdefine <name> RHASSPY <devspec> <defaultRoom> <language> <fhemId> <prefix> <useGenericAttrs> <encoding>
Und kann neue Tests starten.

Zitat von: Beta-User am 28 März 2021, 10:12:41
Wäre natürlich nett, wenn du eine spanische Variante einstellen könntest...

https://github.com/laberlaib/fhem-rasspy-some-data

Da mach ich eine config-es.cfg und ein paar sentences.inis
Extra dafür mal einen github-Account gemacht und mich damit beschäftigt. Wie man das dann vererben, verlinken, commiten, pullen o.ä. kann, das finde ich auch noch irgendwie raus.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 28 März 2021, 11:53:22
Na ja, das mit dem "m" ist kein reiner Typo; hatte da mal "confirmation" stehen, aber das ist eben lang...

Habe nichts dagegen, wenn wir uns da auf einen "guten" Standard verständigen würden; hatte ja schon früher mal geschrieben, dass die Struktur der Sprachkonfig halt mal irgendwie auf die Schnelle entstanden ist ::) .

Scheint so, dass die cref jedenfalls was die Optionen in der DEF angeht, einigermaßen verständlich und vollständig zu sein scheint. Meine Empfehlung wäre auch, immer die param=xy-Schreibweise zu verwenden, einfach, weil andere das dann ggf. so nachmachen ;) . (Es ist m.E. weniger fehleranfällig)
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 28 März 2021, 12:00:23
Super, da hat sich ja eine ganze Menge getan.
sub RHASSPY_roomName {
    my $hash = shift // return;
    my $data = shift // return;

    # Slot "Room" im JSON vorhanden? Sonst Raum des angesprochenen Satelites verwenden
    return $data->{Room} if exists($data->{Room});
   
    my $room;
   
    #Beta-User: This might be the right place to check, if there's additional logic implemented...
   
    my $rreading = makeReadingName("siteId2room_$data->{siteId}");
#Ein ReadingsName wird erzeugt aber kein Reading angelegt, welches dann aber abgefragt wird?
    $room = ReadingsVal($hash->{NAME}, $rreading, $data->{siteId});
    $room = $hash->{helper}{defaultRoom} if ($room eq 'default' || !(length $room)); #Greift das noch, da $room im vorigen Schritt mindestensauf  $data->{siteId} gesetzt wird?

#Sollte man hier die Möglichkeit abbilden, wenn ein Satellit in einem Raum (z.B. Veranda) ohne zugeordnete Geräte steht und man in der Küche sagt: "Starte den Brötchen Timer in der Veranda in 10 Minuten!"?
#Dazu kann fetchSiteIds genutzt werden.

    return $room;
}

Zitatdefine <name> RHASSPY <devspec> <defaultRoom> <language> <fhemId> <prefix> <useGenericAttrs> <encoding>
Cool, da hat man viele Anpassungsmöglichkeiten bereits in der Definition.  8)

Zitatlabels=( Wecker | Eier | Kartoffeln | Tee )
Bei uns gab es heute zum Frühstück frisch aufgebackene Brötchen.  ;)

Ich finde es super, dass Rhasspy dank vieler Unterstützung an Bandbreite gewinnt. Wenn es einen stabilen Zwischenstand inkl. CustomIntents gibt, würde ich wieder mit von der Partie sein.

Gruß Jens
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 31 März 2021, 12:19:05
Zitat von: JensS am 28 März 2021, 12:00:23
Super, da hat sich ja eine ganze Menge getan.
8)

Zitat

#Ein ReadingsName wird erzeugt aber kein Reading angelegt, welches dann aber abgefragt wird?
Na ja, die Funktion zur Erzeugung eines Namens ist das eine, an der Stelle ging es aber in der Tat erst mal darum, ein (anderweitig erzeugtes und z.B. mit setreading gesetztes) Reading abzufragen. Bauchgefühl sagt, dass das sogar funktioniert, aber intensiver Testen konnte ich noch nicht.

ZitatCool, da hat man viele Anpassungsmöglichkeiten bereits in der Definition.  8)
Ja. Man muss halt ein gewisses Gefühl dafür haben, was im jeweiligen Anwendungsfall sinnvoll ist bzw. an welcher "Schraube" man denn am besten dreht. In den meisten Fällen sollte es "für Umsteiger" ganz ohne Parameter gehen, empfehlen würde ich im Moment useGenericAttrs, auch wenn das noch nicht vollständig mit allem möglichem "durchgetestet" ist V.a. bei "mehrsprachigen" Systemen ist es m.E. einfacher, auf diesen "gemeinsamen Nenner" Bezug zu nehmen, sonst muss man auch die mappings 2x konfigurieren (wg. unterschiedlicher prefixe).

ZitatBei uns gab es heute zum Frühstück frisch aufgebackene Brötchen.  ;)
;D Hast du das Keyword dafür ergänzt, oder eben Kartoffeln gebacken...?

Was Timer angeht, habe ich noch etwas am Rückmelde-Code beim Setzen gefeilt, das sollte jetzt in allen Fällen was sinnvolles liefern. Man muss dazu aber auch die Sprachdatei mal wieder mit anfassen. Daher habe ich in dem Zug auch gleich den "Typo" rausgebügelt (hoffe ich jedenfalls).

ZitatWenn es einen stabilen Zwischenstand inkl. CustomIntents gibt, würde ich wieder mit von der Partie sein.
CustomIntents sollten eigentlich seit einiger Zeit schon wieder laufen, (bzw. wenn nicht auch schnell zu reparieren sein), und auch bei shortcuts sollte jetzt Perl wieder in beiden Varianten ausgeführt werden.

Ein paar Anmerkungen noch zu dem Witze-Code:
- Eigentlich wäre es besser, eine generische "ReadRandomLine"-Funktion zu verwenden und dann zum einen den (relativen) Pfad mit zu übergeben und die Anweisung, ob das letzte Zeichen einer Zeile weggeschnitten werden soll. Dann kann man das nämlich für verschiedene Zwecke benutzen (z.B. über "rhasspyTweaks" zum Verlesen verschiedener "wird gemacht!"-Varianten ;) und auch mit unterschiedlichen "Quellen".
- Das mit dem Speicher und der zu verwendenden Lesefunktion mag korrekt sein, aber "wegen der paar Bytes" würde ich mir noch nicht den Kopf zerbrechen, zumal das ja nach Beenden der Funktion auch schon wieder Geschichte ist.
- @JensS: Was steht denn in Witzearray[124] bzw. Witzearray[0]... ;) ?



Neben den oben angesprochenen Themen gibt es in der angehängten Version jetzt auch noch "SetNumericGroup".
Auf die Schnelle habe ich folgende sentences dazu zusammengeklöppelt:
[de.fhem:SetNumericGroup]
\[(schalt|mach|fahr)] (alle | sämtliche ) $de.fhem.Group{Group} [im] [( überall:global | $de.fhem.Room){Room}] [um] [(0..10){Value!int}] [dezibel{Unit}] (lauter|höher){Change:volUp}
\[(schalt|mach)] (alle | sämtliche ) $de.fhem.Group{Group} [im] [( überall:global | $de.fhem.Room){Room}] [um] [(0..10){Value!int}] [dezibel{Unit}] (leiser|niedriger){Change:volDown}
( mach | stelle ) (alle | sämtliche ) $de.fhem.Group{Group} [im] [( überall:global | $de.fhem.Room){Room}] [um] [(0..10){Value!int}] [grad{Unit}] (höher|wärmer){Change:tempUp}
( mach | stelle ) (alle | sämtliche ) $de.fhem.Group{Group} [im] [( überall:global | $de.fhem.Room){Room}] [um] [(0..10){Value!int}] [grad{Unit}] (niedriger|kälter){Change:tempDown}
( mach |schalt|schalte|stelle) (alle | sämtliche ) $de.fhem.Group{Group} [im] [( überall:global | $de.fhem.Room){Room}] [um] [(0..100){Value}] [prozent{Unit:percent}] (heller){Change:lightUp}
( mach |schalt|schalte|stelle) (alle | sämtliche ) $de.fhem.Group{Group} [im] [( überall:global | $de.fhem.Room){Room}] [um] [(0..100){Value}] [prozent{Unit:percent}] (dunkler){Change:lightDown}
(schalt | schalte | stelle ) (alle | sämtliche ) $de.fhem.Group{Group} [im] [( überall:global | $de.fhem.Room){Room}] auf (0..100){Value!float}
( mehr{Change:lightUp} | weniger{Change:lightDown} ) (alle | sämtliche ) $de.fhem.Group{Group} [im] [( überall:global | $de.fhem.Room){Room}]
[de.fhem:SetNumericGroup]
Scheint grundsätzlich zu funktionieren, allerdings bin ich noch nicht ganz zufrieden mit dem, was am Ende rauskommt - allerdings eher von der Seite her, was erkannt wird und welche Geräte daher angesprochen werden. Muss mich da erst mal noch etwas intensiver mit den Wechselwirkungen zwischen unterschiedlichen Sätzen und den "keywords" "probability" und "confidence" etc. auseinandersetzten.
Und evtl. dann noch Bestätigungsanforderung (optional?) mit einbauen...?

Ansonsten sind noch ein paar Kleinigkeiten geändert (z.B. List::Util any und uniq), aber nachdem es sonst keine Klagen gab, würde ich mal annehmen, dass man das ganze als "stabilen Zwischenstand" bezeichnen könnte.


In Bezug auf  'generische "ReadRandomLine"-Funktion' vielleicht noch eine Anmerkung:
Eventuell ließe sich über eine ähnliche Funktion auch noch komplexerer "gender-spezifischer" Antwortcode realisieren. Setzte aber (vermutlich) voraus, dass wir die Struktur eher wieder flacher gestalten (also "timerSet0" statt "timerSet->{0}" und alle Antworten über RHASSPY_getResponse() anfragen (dann könnte man da den Zusatzcode optional aufrufen lassen). Ist aber alles noch nicht abschließend durchdacht und vermutlich auch nicht so einfach umzusetzen...



Was im Moment noch nicht getestet ist, ist die Reaktion auf eine Bestätigung - ohne dass noch was offen ist (bzw. insgesamt das Thema Bestätigung), und mein Logfile sollte ich ggf. auch nochmal intensiver ansehen (da scheint aber nichts gravierendes schief zu laufen).

Sonst würde ich mal behaupten, dass jetzt eigentlich ein "guter" Zeitpunkt für den Umstieg sein sollte; würde die kommenden Wochen eher dann für Fehlerkorrekturen (sofern erforderlich) nutzen und ggf. dann zu gegebener Zeit wieder auf "rhasspyTweaks" etc. zurückkommen?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 31 März 2021, 16:32:33
Frage an die Rhasspy-Experten: Wo kann man näheres erfahren über das dialog-Management?

Hintergrund: RHASSPY_respond antwortet immer auf dem Topic "endSession" - damit wird also die aktuelle Sitzung beendet. "Eigentlich" wäre es nach meinem Verständnis logischer, wenn man sowas wie die Bestätigungsanfrage nicht unter "endSession"-Flagge versenden würde, sondern innerhalb derselben Session abhandelt.
Mein Wunschgedanke: Die weiteren Dialoge ließen sich einschränken, z.B. ginge eine Bestätigung nur innerhalb einer laufenden/noch offenen Sitzung, oder man könnte sowas wie einen Auswahldialog starten ("Du willst eine Temperatur wissen. Welcher Seensor soll ausgelesen werden, im Wohnzimmer sind folgende drei verfügbar?").

Falls also jemand irgendeinen zielführenden Link hat, mit dem man schnell auf des Pudels Kern kommt: her damit...
(Und falls jemand genau weiß, dass das (derzeit?) nicht klappen kann, wäre das auch interessant.)

EDIT: ich antworte mir mal selbst... Unter https://rhasspy.readthedocs.io/en/latest/reference/#dialoguemanager_continuesession gibt es ein paar Hinweise in diese Richtung.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 31 März 2021, 16:40:34
Es gibt das Dialogue-Management: https://rhasspy.readthedocs.io/en/latest/reference/#dialogue-manager

Ich weiß aber nicht, wie man da tun muss. Und kann mich auch nicht erinnern, dass ich funktionierende Beispiele gelesen hätte. Vielleicht findet sich im Forum was? https://community.rhasspy.org/
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 31 März 2021, 16:57:02
Hmm, also:
Man müßte wohl die response auf einen anderen Topic (continueSession) schreiben, im Moment ist das hart auf endSession vercodet, aber es sollte nicht allzu schwierig sein, da ein flag reinzubasteln, um die response bei Bedarf auf einen anderen Pfad umzuleiten :) .

Dann kann man auch einen intentFilter mitgeben. Klingt danach, als könnte man damit (nur) die Confirmation freischalten?

Und weiter unten liest man zu "hermes/dialogueManager/configure:" "Name of intent - enable: bool - true if intent should be eligible for recognition"
Das liest sich so, als könnte man über diesen Mechanismus bestimmte Dinge standardmäßig ausschalten... Das könnte also der Weg sein, Confirmation ansonsten abzuschalten?

Muss ich bei Gelegenheit mal durchspielen und testen... (Wird aber dauern)
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 31 März 2021, 17:42:40
@Beta-User
Danke für deine ausführlichen Antworten. Dann schaue ich mal, wie ich demnächst die Migration durchführe. Im Moment drängen andere Dinge und Zeit ist aktuell knapp.

Rhasspy ist aus Snips entstanden und es gibt viele Ähnlichkeiten. Schau dir mal die Beschreibung von Snips an. Die ist auf jeden Fall ausführlicher.
https://docs.snips.ai/reference/dialogue#continue-session (https://docs.snips.ai/reference/dialogue#continue-session)
https://docs.snips.ai/articles/platform/dialog/multi-turn-dialog (https://docs.snips.ai/articles/platform/dialog/multi-turn-dialog)

Gruß Jens
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 01 April 2021, 11:32:33
Danke für die Links!

Das Beispiel mit dem Flughafen ist schon mal sehr anschaulich, das geht genau in die Richtung "welches Schweinderl hätten's denn gern?".

Na ja, vor einem solchen Auswahldialog sollte erst mal der "einfache" soll ich wirklich?"-Dialog in Shortcuts sauber laufen, dann sehen wir weiter...

Ansonsten @JensS: Kein Stress mit der Umstellung, läuft ja erst mal alles so, wie du das haben willst!

@all:
Da es ansonsten still ist, und doch einige wenige den letzten Code (auch von vor ein paar Tagen) im Einsatz zu haben scheinen, werte ich das als Rückmeldung, dass das soweit stressfrei läuft?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 01 April 2021, 11:52:15
Zitat von: Beta-User am 01 April 2021, 11:32:33
@all:
Da es ansonsten still ist, und doch einige wenige den letzten Code (auch von vor ein paar Tagen) im Einsatz zu haben scheinen, werte ich das als Rückmeldung, dass das soweit stressfrei läuft?

Naja. Also ich hab schon lange nichts mehr getestet. Ich weiß nicht mal, was alles neu ist. Muss ich mir zuerst zusammen suchen. Hab eventuell in den nächsten Tage wieder etwas Zeit.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 01 April 2021, 12:04:25
Ähm

Zitat
response
Optionally define alternative default answers. Available keywords are DefaultError, NoActiveMediaDevice and DefaultConfirmation.
Example:

DefaultError=
DefaultConfirmation=Klaro, mach ich

Beta-User: Was never part of the code? Use configFile instead!

Ist im Code und funktioniert ;)
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 01 April 2021, 12:21:42
Na ja, richtig neu sind "nur" die "Group"-Intents, das mit der (optionalen) Bestätigung bei Shortcuts und bei Timern die modifizierten Rückmeldungen und die Optionen, ein Label draufzukleben und abzubrechen.
Alles andere sind entweder Optionen und/oder Änderungen "unter der Haube", die man als Anwender eigentlich optimalerweise gar nicht bemerken sollte - bzw. die einfach laufen sollten, wie das mit der spanischen Sprachfile und zwei RHASSPY-Instanzen parallel.

Was z.B. @JensS (vermutlich) interessiert, ist die Frage, ob man einfach so 1:1 von 0.2.0 auf 0.4.6a wechseln kann, also Modul & Interface tauscht und die Sprachfile einspielt, und das war es schon...?

Zitat von: drhirn am 01 April 2021, 12:04:25
Ist im Code und funktioniert ;)
Das ist dann in der Tat eine "regression", denn in den aktuellen Versionen funktioniert das nicht mehr, genauer gesagt, sollte es auch in der 0.2.0 schon nicht mehr funktioniert haben, weil die zwei Zeilen auskommentiert sind, die das bereitgestellt hatten:
https://github.com/drhirn/fhem-rhasspy/blob/0.2.0/10_RHASSPY.pm#L1033 (https://github.com/drhirn/fhem-rhasspy/blob/0.2.0/10_RHASSPY.pm#L1033) und #L1034

Das in der Form wiederaufleben zu lassen, macht aber aus naheliegenden Gründen mAn. keinen Sinn. Es wäre aber auch kein großes Problem, dieses Attribut (verdeckt?) weiterleben zu lassen und den Attribut-Inhalt dann einfach in den Sprachhash zu übernehmen...

Bin da aber im Ergebnis leidenschaftslos, das kann dann ggf. auch die "Andockstelle" für zufällige Rückmeldungen (einen aus einer File oder einem Array...) sein :P .EDIT: Kommando zurück, das mit der response-Auswertung steht immer noch da, nur eben woanders, *Augenreib*
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: laberlaib am 01 April 2021, 12:30:08
Zitat von: Beta-User am 01 April 2021, 11:32:33
@all:
Da es ansonsten still ist, und doch einige wenige den letzten Code (auch von vor ein paar Tagen) im Einsatz zu haben scheinen, werte ich das als Rückmeldung, dass das soweit stressfrei läuft?
Ich frag mal kurz meinen Arbeitgeber, meine Homeschoolingtochter sowie den vermeintlichen Pfuscher von Lieferant der Parksysteme unserer Wohnanlage, ob diese Schlussfolgerung korrekt ist  ;)

Mit Bezug: Ich musste den Stecker ziehen, nachdem sich neben der MQTT-Bridge und dem sonstiges Testen die Wakewordeinstellung als sehr empfindlich rausgestellt hat und Jarvis quasi im Technebeat gehupt hat.
Seit heute habe ich eine Woche frei und es sind Schulferien; es könnte also wieder zu spontanen, ausschweifenden Rückmeldung meinerseits kommen.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 01 April 2021, 12:40:21
Zitat von: laberlaib am 01 April 2021, 12:30:08
Ich frag mal kurz meinen Arbeitgeber, meine Homeschoolingtochter sowie den vermeintlichen Pfuscher von Lieferant der Parksysteme unserer Wohnanlage, ob diese Schlussfolgerung korrekt ist  ;)
:P ... das war durchaus provokativ gemeint ;D ;D ;D .

Zitat
Mit Bezug: Ich musste den Stecker ziehen, nachdem sich neben der MQTT-Bridge und dem sonstiges Testen die Wakewordeinstellung als sehr empfindlich rausgestellt hat und Jarvis quasi im Technebeat gehupt hat.
Seit heute habe ich eine Woche frei und es sind Schulferien; es könnte also wieder zu spontanen, ausschweifenden Rückmeldung meinerseits kommen.
Das mit der MQTT-Bridge würde ich gerne näher verstehen wollen, weil ich auch gewisse Schwierigkeiten bei nachträglichen Änderungen (also nach FHEM-Start) mit MQTT2_CLIENT hatte, die (kleine) Stolpersteine waren; das meiste hatte aber mit dem Umzug von Rhasspy auf meinen FHEM-Server zu tun und dürfte daher nicht eben representativ sein...

Das mit dem Wakeword ist ein anderes Thema, und hat (hoffentlich) nichts mit dem eigentlichen Code zu tun?

Ansonsten: Kein Stress, mir ging es erst mal nur drum rauszufinden, wie die Lage so ist...!
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 01 April 2021, 13:44:45
Zitat von: Beta-User am 01 April 2021, 12:21:42
EDIT: Kommando zurück, das mit der response-Auswertung steht immer noch da, nur eben woanders, *Augenreib*

Hihi :D

Aber du hast natürlich vollkommen recht, es ist ein überholtes Feature.

Aber angenommen, jemand ändert jetzt die .cfg. Die wird beim nächsten Update überschrieben. Oder er hat keine aktuelle Datei. Wie sollen wir das lösen?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 01 April 2021, 13:48:05
Zitat von: Beta-User am 28 März 2021, 10:12:41
Die sind jetzt als "temporary"-at angelegt und daher nur noch via list-Kommando zu sehen; weiß noch nicht, ob das eine gute Idee ist.

Hmm, zum Testen find ich das nicht so angenehm. Sollte alles funktionieren, könnte das ein guter Plan sein.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 01 April 2021, 13:59:41
Zitat von: drhirn am 01 April 2021, 13:44:45
Aber du hast natürlich vollkommen recht, es ist ein überholtes Feature.
Na ja, das ganze ist nur insoweit überholt, als man da starre Texte hinterlegen kann ;) . Die Idee, einen "RandomSentence" abspielen zu können, gefällt mir aber sehr (auch, wenn es völlig unwichtig ist ::) ...). Und dafür müsste es auch "irgendwo" einen Ort geben, an dem der User das "einkippen" kann...

ZitatAber angenommen, jemand ändert jetzt die .cfg. Die wird beim nächsten Update überschrieben.
Das Updaten der cfg ist mAn. immer in der Verantwortung des betreffenden Users. Daher ist es jetzt so gestaltet, dass die Struktur fest aus dem Modul kommt und dann (zweistufig) geprüft wird, was an "default" in der cfg steht, und zuletzt (jeweils überschreibend) der "user"-Teil darübergelegt wird.
Ergo kann ein User einfach den "default"-Teil in der cfg tauschen und seine eigenen Sätze bleiben unberührt (er muss/sollte nur anpassen, wenn in der "default" neue Variablen erlaubt sind u.ä.. Das ist aber mAn. irgendwann in näherer Zukunft "passée"...)

ZitatOder er hat keine aktuelle Datei. Wie sollen wir das lösen?
Keine aktuelle Datei (oder eine unvollständige) bedeutet: (teilweise) Englische defaults, s.o.; der User kann jederzeit die (aktuelle) Struktur exportieren und daraus was eigenes stricken; Anleitung ist in der cref...

Die Frage wäre daher ggf. eher, ob wir das Attribut nicht vorneweg auswerten und dann in die Struktur integrieren, damit der User das komplett exportieren und verwenden kann...?

Zitat von: drhirn am 01 April 2021, 13:48:05
Hmm, zum Testen find ich das nicht so angenehm. Sollte alles funktionieren, könnte das ein guter Plan sein.
Wie gesagt: bin noch unentschlossen und man sollte auch noch checken, ob das Neustart-fest ist. Man kann die mit "list TYPE=at " sehen, das an sich sollte daher beim Testen nicht das Problem sein.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 01 April 2021, 14:55:36
Zitat von: Beta-User am 01 April 2021, 13:59:41
Daher ist es jetzt so gestaltet, dass die Struktur fest aus dem Modul kommt und dann (zweistufig) geprüft wird, was an "default" in der cfg steht, und zuletzt (jeweils überschreibend) der "user"-Teil darübergelegt wird.

Ja, ähm, genau. So ist das. Manoman, mein Hirn...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 01 April 2021, 15:04:47
Nevermind...

Das ist letztlich ja nur dann wichtig, wenn man "mismatches" hat und gehört daher in die Kategorie "unter der Haube", in die man eigentlich erst dann schaut, wenn es irgendwo knirscht (was scheinbar nicht ernsthaft der Fall war ;D ).
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 01 April 2021, 18:27:25
Hier mal meine letzten Erkenntnisse zum Thema Dialog:
- geht!  8)
- hält man die Sitzung offen, scheint es keinen oder einen längeren Timeout zu geben von der Rhasspy-Seite
- implementiert derzeit für Shortcut
- der Bestätigungs-Intent scheint jetzt auch per default aus zu sein, man kann also eine Negativauswahl machen und Rhasspy so initialisieren...

- Neu dazugekommen ist jetzt mal ein neuer setter-Vorschlag, mit dem man beliebige slots füllen kann, mit und ohne overwrite.
Damit sollte es möglich sein, z.B. einen Auswahldialog aufzumachen, wenn es mehrere passende Devices in einem Raum gibt oder mehrere Devices, aber in verschiedenen Räumen. (Ab hier wird es vermutlich dann komplex... Aber die Grundlagen sollten vorhanden sein :) .)

Falls ihr also zum Testen kommt, dann am besten gleich mit dem Anhang von hier...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: laberlaib am 01 April 2021, 18:45:03
Noch nicht der Anhang von direkt über mir:
Ich glaube bei zwei RHASSPY-Devices kommt er mit der config ducheinander:
RAW teilweise kopiert:
attr RHASSPY_DE configFile ./.config/rhasspy-de.cfg
setstate RHASSPY_DE 2021-04-01 16:39:48 lastIntentPayload {"Device":"Stehlampe","input":"schalte Stehlampe","intent":"SetNumeric","probability":0,"rawInput":"schalte die stehlampe sdkfj","requestType":"voice","sessionId":"caa2c909-e822-48e7-8399-50e8f233f9db","siteId":"MasterDe"}
setstate RHASSPY_DE 2021-04-01 16:39:48 voiceResponse Lo siento, pero faltan parámetros
oder auch mal
setstate RHASSPY_DE 2021-04-01 16:44:31 voiceResponse Lo siento, pero no hay ningún reproductor activo

Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 01 April 2021, 18:45:47
Zitat von: Beta-User am 01 April 2021, 18:27:25
Hier mal meine letzten Erkenntnisse zum Thema Dialog:
- geht!  8)
- hält man die Sitzung offen, scheint es keinen oder einen längeren Timeout zu geben von der Rhasspy-Seite
- implementiert derzeit für Shortcut
- der Bestätigungs-Intent scheint jetzt auch per default aus zu sein, man kann also eine Negativauswahl machen und Rhasspy so initialisieren...

Hast du da ein Beispiel, mit dem ich das testen könnte?

ZitatDamit sollte es möglich sein, z.B. einen Auswahldialog aufzumachen, wenn es mehrere passende Devices in einem Raum gibt oder mehrere Devices, aber in verschiedenen Räumen.

Wie meinst du das? Wie "mehrere passende Devices"?
Und wenn wir schon dabei sind. Mir ist "Recommended to be unique" in der CRef bei rhasspyRoom aufgefallen. Was meinst du damit? Weil, es kann schon mehrere Devices in einem Raum gegen. Somit ist der Raum nicht unique.

Zitat
Falls ihr also zum Testen kommt, dann am besten gleich mit dem Anhang von hier...

Ist im GitHub
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 01 April 2021, 19:01:08
Zitat von: laberlaib am 01 April 2021, 18:45:03
Noch nicht der Anhang von direkt über mir:
Ich glaube bei zwei RHASSPY-Devices kommt er mit der config ducheinander:
Dazu solltest du die lists ansehen, ob da deutsche Texte drin stehen?

Allerdings ist mir grade aufgefallen, dass SetNumeric "solo" nicht mehr will und über angeblich fehlende Daten mosert, grade funktioniert wohl nur noch die Gruppenvariante. Hat vermutlich mit der Umstellung auf "gruppe" zu tun, aber im Moment werde ich vermutlich nicht dazukommen, das zu fixen.

Zitat von: drhirn am 01 April 2021, 18:45:47
Hast du da ein Beispiel, mit dem ich das testen könnte?
mit dem "confirm"-Beispiel aus der cref (hoffe, das eingepflegt zu haben) sollte es gehen.

ZitatWie meinst du das? Wie "mehrere passende Devices"?
Im Moment schaltet RHASSPY das erste Device, das sich "im Raum" befindet, selbst wenn es mehrere gibt, und wenn es das nicht gibt, das erste beliebige Device, das zwar paßt, aber in matchesOutsideRoom ist.

ZitatUnd wenn wir schon dabei sind. Mir ist "Recommended to be unique" in der CRef bei rhasspyRoom aufgefallen. Was meinst du damit? Weil, es kann schon mehrere Devices in einem Raum gegen. Somit ist der Raum nicht unique.
Darüber muss ich vermutlich nochmal nachdenken, könnte sein, dass das ein Übertragungsfehler war...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: laberlaib am 01 April 2021, 19:13:44
Zitat von: Beta-User am 01 April 2021, 19:01:08
Dazu solltest du die lists ansehen, ob da deutsche Texte drin stehen?
Nope.
Internals:
   CONFIGFILE ./.config/rhasspy-de.cfg
   DEF        devspec=room=Rhasspy defaultRoom=Wohnzimmer language=de prefix=de
   FUUID      605f973f-f33f-3460-1827-1bd6124fb6c68a44
   IODev      RhasspyMasterDeMQTT2
   LANGUAGE   de
   LASTInputDev RhasspyMasterDeMQTT2
   MODULE_VERSION 0.4.6a
   MSGCNT     33
   NAME       RHASSPY_DE
   NR         16
   RhasspyMasterDeMQTT2_MSGCNT 33
   RhasspyMasterDeMQTT2_TIME 2021-04-01 17:12:44
   STATE      ???
   TYPE       RHASSPY
   devspec    room=Rhasspy
   encoding   
   fhemId     fhem
   prefix     de
   useGenericAttrs
   READINGS:
     2021-04-01 17:12:41   lastIntentPayload {"Change":"leiser","input":"leiser","intent":"SetNumeric","probability":1,"rawInput":"leiser","requestType":"voice","sessionId":"lebenXWohnzimmer-jarvis-4d8550ad-7a98-4bdf-b5eb-9a77240f785e","siteId":"lebenXWohnzimmer"}
     2021-04-01 17:12:41   lastIntentTopic hermes/intent/de.fhem_SetNumeric
     2021-03-28 19:11:46   listening_lebenXKochen 0
     2021-04-01 17:12:44   listening_lebenXWohnzimmer 0
     2021-04-01 17:12:41   responseType    voice
     2021-03-27 20:37:49   siteIds         lebenXWohnzimmer,handylaib,lebenXKochen,tester,MasterDe
     2021-04-01 16:30:09   training        Training completed in 2.99 second(s)
     2021-04-01 16:30:06   updateSlots     OK
     2021-04-01 17:12:41   voiceResponse   Lo siento, pero faltan parámetros
   helper:
     defaultRoom Wohnzimmer
     devicemap:
       devices:
         du_Dummyschalter:
           intents:
             GetOnOff:
               GetOnOff:
                 currentValue state
                 type       GetOnOff
                 valueOff   off
             MediaControls:
             SetOnOff:
               SetOnOff:
                 cmdOff     off
                 cmdOn      on
                 type       SetOnOff
           rooms:
             Wohnzimmer
       rhasspyRooms:
         Wohnzimmer:
           Stehlampe  du_Dummyschalter
         lebenXWohnzimmer:
     lng:
       responses:
         DefaultCancelConfirmation Orden cancelada
         DefaultConfirmation Vale
         DefaultConfirmationNoOutstanding No había nada para confirmar
         DefaultConfirmationReceived Valo, lo hago
         DefaultConfirmationTimeout Lo siento, está durando demasiado
         DefaultError Algo fallado
         NoActiveMediaDevice Lo siento, pero no hay ningún reproductor activo
         NoDeviceFound Lo siento, pero no se encontró el aparato
         NoMappingFound Lo siento, pero no se encontró un mapping apropiado
         NoNewValDerived Lo siento, pero no se puede definir el valor deseado
         NoValidData Lo siento, pero faltan parámetros
         duration_not_understood Lo siento, pero no se entendió la duratión
         reSpeak_failed Lo siento, pero no lo recuerdo
         timeRequest Son las $hour y $min
         timerCancellation timer $label for $room deleted
         weekdayRequest Hoy es $weekDay
         Change:
           airHumidity la humedad del aire de $location está $value por ciento
           brightness $deviceName está definido a $value
           knownType  $mappingType de $location está definido para $value por ciento
           setTarget  $device está definido para $value
           soilMoisture La humedad del suelo de $location está $value por ciento
           unknownType El valor de $location está definido para $value por ciento
           volume     $deviceName está definido a $value
           waterLevel el nivel del aqua de $location está $value por ciento
           battery:
             0          El estado de la batería de $location está $value
             1          El estado de la batería de $location está $value por ciento
           temperature:
             0          La temperatura de $location está $value
             1          La temperatura de $location está $value grados
         timerEnd:
           0          temporizador $label terminado
           1          temporizador $label en la habitación $room terminado
         timerSet:
           0          temporizador $label en la habitación $room está definido para $seconds segundos
           1          temporizador $label en la habitación $room está definido para $minutes minutos y $seconds segundos
           2          temporizador $label en la habitación $room está definido para $minutes minutos
           3          despertador $label en la habitación $room está definido para $hours horas y $minutes minutos
           4          despertador $label en la habitación $room está definido para $hours horas y $minutes minutos
           5          despertador $label en la habitación $room está definido para mañana, $hours horas y $minutes minutos
       stateResponses:
         inOperation:
           0          $deviceName ha terminado
           1          $deviceName sigue en marcha
         inOut:
           0          $deviceName está abierta
           1          $deviceName está cerrada
         onOff:
           0          $deviceName está apagada
           1          $deviceName está encendida
         openClose:
           0          $deviceName está abierta
           1          $deviceName está cerrada
       units:
         unitHours:
           0          horas
           1          una hora
         unitMinutes:
           0          Testeinheiten
           1          eine weniger
         unitSeconds:
           0          segundos
           1          un segundo
Attributes:
   IODev      RhasspyMasterDeMQTT2
   configFile ./.config/rhasspy-de.cfg
   rhasspyMaster http://192.168.2.121:12101
   room       Rhasspy
   verbose    5

Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 01 April 2021, 19:18:27
Und in der configFile stehen deutsche Texte?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: laberlaib am 01 April 2021, 19:31:08
jo:
laberlaib@ubuntu:/opt/fhem/.config$ cat rhasspy-de.cfg
#$Id: rhasspy-de.cfg 2021-03-30 incl. new timer 2 Beta-User $
# Diese Datei an einem Ort ablegen, den der user fhem lesen kann
# und dann diesen Ort im Attribut configFile hinterlegen. Beispiel:
# attr <rhasspy> configFile ./log/rhasspy-de.cfg
#
# "commaconversion", "units" und "mutated_vowels" sind optional, wenn nicht
# angegeben, werden die englischen Werte/Gepflogenheiten verwendet bzw. keine
# Ersetzungen vorgenommen.

{"default":
{
  "commaconversion": "1",
  "mutated_vowels": {
    "Ä": "Ae",
    "Ö": "Oe",
    "Ü": "Ue",
    "ß": "ss",
    "ä": "ae",
    "ö": "oe",
    "ü": "ue"
  },
  "units": {
      "unitHours" : {
          "0": "stunden",
          "1": "eine stunde"
      },
      "unitMinutes": {
          "0": "minuten",
          "1": "eine minute"
      },
      "unitSeconds": {
          "0": "sekunden",
          "1": "eine sekunde"
      }
   },
  "responses": {
    "DefaultConfirmation": "OK",
    "DefaultConfirmationTimeout": "Tut mir leid, da hat etwas zu lange gedauert"                 ,
    "DefaultCancelConfirmation": "Habe abgebrochen",
    "DefaultConfirmationReceived": "Ok, werde ich machen",
    "DefaultConfirmationNoOutstanding": "Es war nichts mehr zu bestätigen",
    "DefaultError": "Da ist leider etwas schief gegangen",
    "NoValidData": "Tut mir leid, aber ich habe zu wenig Daten um den Vorgang au                 szuführen",
    "NoDeviceFound": "Tut mir leid, ich konnte kein passendes Gerät finden",
    "NoMappingFound": "Tut mir leid, aber ich konnte kein passendes Mäpping find                 en",
    "NoNewValDerived": "Tut mir leid, aber ich konnte den Zielwert nicht ausrech                 nen",
    "NoActiveMediaDevice": "Tut mir leid, es ist kein Wiedergabegerät aktiv",
    "duration_not_understood": "Tut mir leid, ich habe die Dauer nicht verstande                 n",
    "timerEnd": {
        "0": "taimer $label abgelaufen",
        "1": "taimer $label im raum $room abgelaufen"
    },
    "timerSet": {
        "0": "taimer $label im Raum $room ist gestellt auf $seconds sekunden",
        "1": "taimer $label im Raum $room ist gestellt auf $minutetext $seconds"                 ,
        "2": "taimer $label im Raum $room ist gestellt auf $minutetext",
        "3": "Wecker $label im Raum $room ist gestellt auf $hours stunden $minut                 etext",
        "4": "Wecker $label im Raum $room ist gestellt auf $hours uhr $minutes",
        "5": "Wecker $label im Raum $room ist gestellt auf morgen, $hours uhr $m                 inutes"
    },"timeRequest": "Es ist $hour Uhr $min",
    "weekdayRequest": "Heute ist $weekDay",
    "reSpeak_failed": "Tut mir leid, ich kann mich nicht erinnern",
    "Change": {
      "volume": "$deviceName ist auf $value gestellt",
      "brightness": "$deviceName ist auf $value gestellt",
      "temperature": {
        "0": "Die Temperatur von $location ist $value",
        "1": "Die Temperatur von $location beträgt $value Grad"
      },
      "battery": {
        "0": "Der Batteriestand von $location ist $value",
        "1": "Der Batteriestand von $location beträgt $value Prozent"
      },
      "waterLevel": "Der Wasserstand von $location beträgt $value Prozent",
      "airHumidity": "Die Luftfeuchtigkeit von $location beträgt $value Prozent"                 ,
      "soilMoisture": "Die Bodenfeuchte von $location beträgt $value Prozent",
      "setTarget": "$device ist auf $value gesetzt",
      "knownType": "$mappingType von $location beträgt $value Prozent",
      "unknownType": "Der Wert von $location beträgt $value Prozent"
    }
  },
  "stateResponses": {
    "onOff": {
      "0": "$deviceName ist ausgeschaltet",
      "1": "$deviceName ist eingeschaltet"
    },
    "openClose": {
      "0": "$deviceName ist geöffnet",
      "1": "$deviceName ist geschlossen"
    },
    "inOut": {
      "0": "$deviceName ist ausgefahren",
      "1": "$deviceName ist eingefahren"
    },
    "inOperation": {
      "0": "$deviceName ist fertig",
      "1": "$deviceName läuft noch"
    }
  }
},
"user":
{
  "units": {
      "unitSeconds": {
          "0": "Test einige Sekunden",
          "1": "Test genau eine Sekunde"
      }
  }

}
laberlaib@ubuntu:/opt/fhem/.config$

Und der andere Rhasspy ist exakt gleich, außer halt dass aus "de" überall "es" wird.
Und die config-es.cfg enthält die Spanischen Texte.

Edit:
Ich dreh mal die Reihenfolge in der fhem.cfg um und mach n Neustart

Edit2: Reihenfolge gedreht, nun erst den Spanier, dann den Deutschen mit ihren jeweiligen configs
=> Beide sprechen Deutsch; in beiden lists sind die deutschen Texte.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 01 April 2021, 19:43:21
Hmm, kannst du mal den Spanier anweisen, seine es-config neu einzulesen?

Edit: vermutlich muss da beim Kopieren in lng dereferenziert werden: =%{$...}
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: laberlaib am 01 April 2021, 19:47:55
Zitat von: Beta-User am 01 April 2021, 19:43:21
Hmm, kannst du mal den Spanier anweisen, seine es-config neu einzulesen?
...was genau was ist?
Update language?
Done.
Und list ergibt spanisch... leider bei beiden
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 01 April 2021, 19:49:42
Siehe edit, falls das weiter hilft.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: laberlaib am 01 April 2021, 22:06:32
Zitat von: Beta-User am 01 April 2021, 19:43:21
Edit: vermutlich muss da beim Kopieren in lng dereferenziert werden: =%{$...}
Ich glaube sogar zu verstehen, was Du sagst.
ich probier da mal was Morgen oder später noch...

Edit: ich glaub, ich gebs auf. Ich hab die Zuweisung versucht zu kopieren und dann zu referenzieren. Aber es hat nicht geklappt:
Also aus Zeile 398
    $hash->{helper}{lng} = _combineHashes( $lngvars, $decoded);
hab ich all das hier mal erfolglos probiert:

$hash->{helper}{lng} = %{_combineHashes( $lngvars, $decoded)};
Resultat im List bei lng: 3.
Ok, helperlng soll ja nur die Referenz bekommen:
$hash->{helper}{lng} = \%{_combineHashes( $lngvars, $decoded)};
falsche Sprache
Ok, mal einzeln versuchen:
my $test = _combineHashes( $lngvars, $decoded);
my %hash_copy =  %{$test};
    $hash->{helper}{lng} = \%hash_copy;

falsche Sprache.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 02 April 2021, 09:56:08
Ad Dialogue:
Zitat von: Beta-User am 01 April 2021, 19:01:08
mit dem "confirm"-Beispiel aus der cref (hoffe, das eingepflegt zu haben) sollte es gehen.
ich werde nach einer Bestätigung gefragt. Aber wie muss dann meine Sprachantwort sein, damit das auch gemacht wird?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 02 April 2021, 15:05:12
Puh, das mit der dereferenzierung war ein dickeres Brett, das Problem war _combineHashes()...

Sollte jetzt klappen, vermutlich kann man manches noch schöner machen....

Zitat von: drhirn am 02 April 2021, 09:56:08
Ad Dialogue:ich werde nach einer Bestätigung gefragt. Aber wie muss dann meine Sprachantwort sein, damit das auch gemacht wird?
Sorry, falls ich das bisher nicht gepostet hatte:
[de.fhem:ConfirmAction]
(ja mach | tu es | ist ok ){Mode:OK}
(lass es | nein | abbrechen | abbruch ){Mode}
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: laberlaib am 02 April 2021, 15:23:16
Zitat von: Beta-User am 02 April 2021, 15:05:12
Puh, das mit der dereferenzierung war ein dickeres Brett, das Problem war _combineHashes()...
...und ich mit meinem Korkenzieher als improvisierte Bohrmaschine...

Klappt, super, Danke!

Ich versuch das mal durch vergleichen nachzuvollziehen, ich find das nämlich richtig spannend, da es über mein VBA-basiertes Programmieren deutlich hinausgeht.

Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 02 April 2021, 15:37:46
Zitat von: laberlaib am 02 April 2021, 15:23:16
Klappt, super, Danke!
Danke für die Rückmeldung!

Zitat
Ich versuch das mal durch vergleichen nachzuvollziehen, ich find das nämlich richtig spannend, da es über mein VBA-basiertes Programmieren deutlich hinausgeht.
Das mit diesen verdammten Hashes und Referenzen ist wirklich spannend, und die eigentlichen Änderungen (aaO) sind nicht wirklich revolutionär - es wird einfach nicht die übergebene Referenz "bearbeitet", sondern ein neuer Hash aufgebaut - "eigentlich" nichts besonderes...
(Der Rest oben ist zwar auch überarbeitet, aber vermutlich hätte der auch unverändert bleiben können.)
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 03 April 2021, 06:45:01
...kleine Ursache, große Wirkung...

Habe den Logikfehler gefunden, der SetNumeric befallen hatte und bei der Gelegenheit noch ein paar Eintagsfliegen-Variablen bei der Sprachinitialisierung wieder entsorgt.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 04 April 2021, 07:00:37
Hier noch zwei gefundene Ostereier und etwas Verpackungsmaterial:
Gelöste Probleme:
- Sprachnachricht nach Timer-Ende umfasste auch das Ändern des Readingwerts;
- Automatisch angelegte "media"-Mappings (aus gDT) waren eine Ebene zu hoch => crash...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 04 April 2021, 10:35:10
Frohe Ostern und vielen Dank für die Revisionen. Nach Ostern geht's ans testen.
Gruß Jens
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 06 April 2021, 09:55:13
So, habe eben die rhasspy-de.cfg eingespielt, den rhasspyMQTT2 erzeugt 10_RHASSPY.pm modifiziert und nach FHEM-Neustart die Definition "devspec=room=Rhasspy defaultRoom=Wohnzimmer language=de encoding=utf-8'" angepasst. Schalten geht schon mal und der Rest kommt nach der Gartenarbeit ran. Lustig sind die englischen Fehlermeldungen. Pfad der Sprachdatei angepasst... 8)
Gruß Jens

p.s. Bevor ich viel lese, frage ich lieber jemanden, der sich mit auskennt.[de.fhem:GetNumeric]
(warm|kalt|heiß|Temperatur){Type:Temperatur} [ist es|von|vom|ist] ([(im|auf dem)]($de.fhem.Room){Room}|[das]($de.fhem.Device){Device})

Frage: "Wie warm ist es im Wohnzimmer?" - Antwort: "Tut mir leid, ich konnte kein passendes Gerät finden."attr Sensor2 rhasspyMapping GetNumeric:currentVal=temperature,type=Temperatur
attr Sensor2 rhasspyName Thermometer
attr Sensor2 rhasspyRoom Wohnzimmer
attr Sensor2 room Rhasspy,Sensoren,Wohnzimmer


rhasspyIntents funktionieren weitgehend!  :)
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 06 April 2021, 15:47:03
GetNumeric hatte ich bisher nicht auf dem Schirm, habe eben mal (mit deinem Sentence) getestet: "im Wohnzimmer" => kein passendes Gerät; Anfrage auf spezielles Gerät (HK-Thermostat) =>  Antwort, aber "falsches" Reading (desired-temp statt measured-temp; beides ist aber in GetNumeric als "temperature" drin).
Habe dann in sentences "Temperatur" gegen "temperature" getauscht, jetzt kam was sinnvolles bei der Raumanfrage (allerdings mit "Punkt" statt "Komma", und ob man das auf zwei Stellen genau haben muss, ist ... na ja, so wird es eben geliefert...).

Auf die Anfrage bei den Heizkörpern kommt "zuverlässig" die desired-temp; das muss ich mir wohl mal ansehen...

Was bedeutet:
rhasspyIntents funktionieren weitgehend!

Vermutung: Das mit dem HASH als letztes Argument mußt du umbauen/in der Anfrage anpassen?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 06 April 2021, 16:17:19
...die Ursache für den Punkt habe ich gefunden:
Durch das strikte "nur was im Ausgangs-lng-Hash steht, darf ersetzt werden" gab es ein Problem mit dem Komma und den Umlauten.

Wenn man die speziell als Ergänzung zulässt, funktioniert auch das wieder:

sub _combineHashes {
    my ($hash1, $hash2, $parent) = @_;
    my $hash3 = {};
   
    for my $key (keys %{$hash1}) {
        $hash3->{$key} = $hash1->{$key};
        if (!exists $hash2->{$key}) {
            next;
        }
        if ( ref $hash3->{$key} eq 'HASH' and ref $hash2->{$key} eq 'HASH' ) {
            $hash3->{$key} = _combineHashes($hash3->{$key}, $hash2->{$key}, $key);
        } elsif ( !ref $hash3->{$key} && !ref $hash2->{$key} ) {
            $hash3->{$key} = $hash2->{$key};
        }
    }
    for (qw(commaconversion mutated_vowels)) {
        $hash3->{$_} = $hash2->{$_} if defined $hash2->{$_};
    }
    return $hash3;
}
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 06 April 2021, 21:59:06
Das mit den matches_in_room, matches_outside_room sollten wir uns nochmal ansehen:

Wenn ich die Temperaturabfrage im Esszimmer mache, bekomme ich - mangels passendem Gerät im Esszimmer - die Temperatur des Sensors im Wohnzimmer (als Temperatur im Esszimmer) angesagt.

Meine aktuelle Vorstellung dazu:
- gibt es keinen passenden Match im Raum, sollte geschaut werden, ob es mehrere Sensoren gibt. Wenn ja, müßten die Räume als Auswahl angeboten werden (bzw. die Sensoren aus dem einen Raum, falls die alle im selben Raum sind).
- gibt es mehrere Sensoren => Auswahl fragen
- die letztendliche Ausgabe sollte dann sowohl den Namen des Sensors wie auch den Raum beinhalten. Das bringt aber zwei neue Probleme mit sich: jeweils "welchen" Namen bzw. Raum, wenn es mehrere gibt? Neige dazu, das zugunsten des jeweils ersten angegebenen zu entscheiden, habe aber noch keine Ahnung, ob sich das so in Code gießen läßt.
Und: vorab muss  das "Dialogische" funktionieren und mehr oder weniger frei konfigurierbar sein (klingt nicht lustig)...

Ansonsten bin ich noch etwas am Rumspielen, wie sich Dinge vereindeutigen lassen, manche "Treffer" wirken weiter etwas zufällig. Auch dazu meine Gedanken:
- Tendenziell wissen wir, welche Kombinationen Sinn machen ("volume" ist eher "media" und passt nicht richtig auf "blind").
- Da für klarere Verhältnisse zu sorgen, würde aber bedingen, dass
-- mindestens Rhasspy zum einen genauere Kenntnisse über "Typen" hat, also mehr slots definiert werden (also Rhasspy z.B. einen slot mit allen "blind"-Gerätenamen hat), und
-- eventuell dazu noch die Rückmeldungen dann auch wieder von RHASSPY nicht nur pauschal mit "up" oder eben nicht "up"( = down) ausgewertet werden, sondern auch wieder etwas differenzierter.
Muss mal testen, was da ggf. wie Sinn machen würde, oder hat jemand eine spontane Eingebung oder ein ausgefeiltes Konzept?

Aber evtl. hat auch jemand noch andere Tipps, wie man eindeutige Ergebnisse bekommen kann; habe jedenfalls das Gefühl, dass da noch "Luft" ist, und eigentlich wollte ich es vermeiden, die ganzen "alten" Threads zum Thema zu durchforsten, was sich da noch alles an (verworfenen) Ansätzen findet...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 07 April 2021, 08:37:47
Also früher wurde bei der Frage nach "wie ist die temperatur in der küche" in diesem Raum nach einem Gerät mit dem GetNumeric-Mapping-Typ "Temperatur" gesucht. Gab's keines, wurde der Fehlerton ausgegeben. Das hat mir persönlich eigentlich gereicht. Bzw. könnten wir auch einfach "kein passendes gerät gefunden" ausgeben lassen.

Ich tendiere eher dazu, in FHEM eine richtige Logik abzubilden anstatt das Modul nach irgendwelchen Geräten suchen zu lassen. Aber mit der Meinung bin ich wohl schon etwas zu spät dran ;D
Es macht z.B. in der Praxis eigentlich keinen Sinn, mehrere Temperatur-Sensoren in einem Raum zu haben. Also, kann man schon haben, hab ich auch. Aber interessieren tut mich eigentlich nur einer (bzw. ein Mittelwert aus allen, was wieder nur ein Device wäre).
Gibt's in einem Raum keinen Sensor, wird das wohl seinen Grund haben.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 07 April 2021, 09:23:49
Ich habe gerade Rhasspy in mein produktives FHEM übernommen. Und bin wieder über die selben zwei Punkte gestolpert, über die ich immer stolpere. rhasspyMaster und configFile vergessen ;D.

Gibt's irgendwie eine Möglichkeit, dass wir das so einrichten, dass das ein User nicht vergessen kann? Eventuell als verpflichtende Option ins define?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 07 April 2021, 10:03:40
Zitat von: drhirn am 07 April 2021, 08:37:47
Also früher wurde bei der Frage nach "wie ist die temperatur in der küche" in diesem Raum nach einem Gerät mit dem GetNumeric-Mapping-Typ "Temperatur" gesucht. Gab's keines, wurde der Fehlerton ausgegeben.
Bist du da sicher? Die Logik, Devices zu finden, hat sich mAn. zwischen 0.2.0 und der aktuellen Version nicht grundsätzlich vom Ablauf her verändert, wenn man davon absieht, dass jetzt "temperature" statt "Temperatur" abgefragt wird.

Und das hier ist auch unverändert - das Problem, dass Werte von außerhalb des Raums zurückgeliefert werden, besteht also "schon immer":# Erstes Device im passenden Raum zurückliefern falls vorhanden, sonst erstes Device außerhalb
$device = (@{$matchesInRoom} > 0) ? shift @{$matchesInRoom} : shift @{$matchesOutsideRoom};

"Mein anderes Problem" mit den mehreren Sensoren rührt zum einen daher, dass es durch die gDT-Auswertung a) in der Tat plötzlich viele Temperatur-Geräte gibt und b) auch "desired-temp" nach "temperature" gemappt wird, was auch noch die Zahl der abfragbaren Werte (uneindeutig) an ein und demselbend Device erhöht.

ZitatIch tendiere eher dazu, in FHEM eine richtige Logik abzubilden anstatt das Modul nach irgendwelchen Geräten suchen zu lassen. Aber mit der Meinung bin ich wohl schon etwas zu spät dran ;D
Wenn man es in dem Sinne "richtig" macht, dass man alles händisch definiert und in jedem Raum genau einen Sensor hat, sollte es auch weiter problemlos laufen. Und wenn die "neue Methode" zu unlösbaren Problemen führt, ist es nie zu spät, bessere Alternativen zu diskutieren.

ZitatEs macht z.B. in der Praxis eigentlich keinen Sinn, mehrere Temperatur-Sensoren in einem Raum zu haben. Also, kann man schon haben, hab ich auch. Aber interessieren tut mich eigentlich nur einer (bzw. ein Mittelwert aus allen, was wieder nur ein Device wäre).
Na ja, einer ist vermutlich eine Art "default", den man "eigentlich" haben will, wenn man nichts spezielles anfordert, aber in der Küche könnten schon Raumtemperatur, Kühlschrank und Backofen samt Garthermometer im Braten interessant sein, und auch im Heizraum (oder Garten) wäre es ähnlich (ja, auch im Garten habe ich auch einige Thermometer für diverse Zwecke...).

ZitatGibt's in einem Raum keinen Sensor, wird das wohl seinen Grund haben.
Nun ja, in dem Raum gab es durchaus einen Sensor (einen Raumthermostat), der war nur noch nicht konfiguriert...
Es bleibt aber dabei, dass die Ansage auch in dem Fall, dass es wirklich keinen Sensor gibt, nicht kommentarlos "irgendwas" beinhalten sollte, oder?

Langer Rede kurzer Sinn: Alles nicht so einfach...

Zitat von: drhirn am 07 April 2021, 09:23:49
Ich habe gerade Rhasspy in mein produktives FHEM übernommen. Und bin wieder über die selben zwei Punkte gestolpert, über die ich immer stolpere. rhasspyMaster und configFile vergessen ;D .

Gibt's irgendwie eine Möglichkeit, dass wir das so einrichten, dass das ein User nicht vergessen kann? Eventuell als verpflichtende Option ins define?
configFile ist eine echte Option, wenn's die nicht gibt, geht nichts kaputt, "man spricht" halt nicht "deutsch" => gehört m.E. nicht ins define.
rhasspyMaster wäre vermutlich sinnvoll in der DEF. Würde aber vorschlagen, das dann "Rhasspy" zu nennen (für den Dienst). Wobei man auch dort überlegen könnte, ob es optional sein soll mit default auf "localhost:12101".
(Generell: state ist bei mir noch leer).
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 07 April 2021, 10:31:48
Zitat von: Beta-User am 07 April 2021, 10:03:40
Bist du da sicher? Die Logik, Devices zu finden, hat sich mAn. zwischen 0.2.0 und der aktuellen Version nicht grundsätzlich vom Ablauf her verändert, wenn man davon absieht, dass jetzt "temperature" statt "Temperatur" abgefragt wird.

Also mein noch aktives Snips-Gerät meint auf die Frage "Wie warm ist es im Vorraum" - "Da ist etwas schief gegangen". Und die Logik zwischen Snips und 0.2.0 hat sich da eigentlich nicht verändert.

Zitat"Mein anderes Problem" mit den mehreren Sensoren rührt zum einen daher, dass es durch die gDT-Auswertung a) in der Tat plötzlich viele Temperatur-Geräte gibt und b) auch "desired-temp" nach "temperature" gemappt wird, was auch noch die Zahl der abfragbaren Werte (uneindeutig) an ein und demselbend Device erhöht.
Wenn man es in dem Sinne "richtig" macht, dass man alles händisch definiert und in jedem Raum genau einen Sensor hat, sollte es auch weiter problemlos laufen. Und wenn die "neue Methode" zu unlösbaren Problemen führt, ist es nie zu spät, bessere Alternativen zu diskutieren.

Nun ja, das ist ein Problem. Vielleicht sollten wir da wirklich nur auf das Mapping setzen?

ZitatNa ja, einer ist vermutlich eine Art "default", den man "eigentlich" haben will, wenn man nichts spezielles anfordert, aber in der Küche könnten schon Raumtemperatur, Kühlschrank und Backofen samt Garthermometer im Braten interessant sein, und auch im Heizraum (oder Garten) wäre es ähnlich (ja, auch im Garten habe ich auch einige Thermometer für diverse Zwecke...).

Ist richtig. Aber du wirst dir auf die Frage "Wie warm ist es in der Küche" nicht die Temperatur des Kühlschranks erwarten, oder? Da fragst du dann ja eher nach dem speziellen Gerät in dem speziellen Raum.

ZitatEs bleibt aber dabei, dass die Ansage auch in dem Fall, dass es wirklich keinen Sensor gibt, nicht kommentarlos "irgendwas" beinhalten sollte, oder?

Ja. Eindeutig. :D

ZitatconfigFile ist eine echte Option, wenn's die nicht gibt, geht nichts kaputt, "man spricht" halt nicht "deutsch" => gehört m.E. nicht ins define.

Jup, macht Sinn. Muss ich dann einfach in der Doku deutlicher herausstreichen, dass das Attribut gesetzt gehört.

ZitatrhasspyMaster wäre vermutlich sinnvoll in der DEF. Würde aber vorschlagen, das dann "Rhasspy" zu nennen (für den Dienst).

Nochmal "Rhasspy"? Das schafft Verwirrung befürchte ich. rhasspyMaster ist aber blöd, geb ich zu. "rhasspyURL", "baseURL", "rhasspyBase" oder was anderes?

ZitatWobei man auch dort überlegen könnte, ob es optional sein soll mit default auf "localhost:12101".

Hmm, weiß nicht. Dann wäre eventuell eine Fehlermeldung/ein Hinweis bei Nicht-Erreichbarkeit gut.

Zitat
(Generell: state ist bei mir noch leer).

Vorschläge?

Ich habe in meinem produktiven FHEM ein paar Geräte mit gDT. Nach einem update sieht mein Rhasspy-Slot de.fhem.Room jetzt so aus:

Küche
Schlafzimmer
system->devices
multimedia
klo
shelly
küche->licht
wohnzimmer
Vorraum
beleuchtung
enocean
rhasspy
snips
mqtt2_device
Wohnzimmer

Da werden FHEM-Räume hergenommen. Nicht gut. Sollte nur befüllt werden, wenn es zum Device einen rhasspyRoom gibt.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 07 April 2021, 11:33:34
Zitat von: drhirn am 07 April 2021, 10:31:48
Also mein noch aktives Snips-Gerät meint auf die Frage "Wie warm ist es im Vorraum" - "Da ist etwas schief gegangen". Und die Logik zwischen Snips und 0.2.0 hat sich da eigentlich nicht verändert.
Wie geschrieben: aus der Code-Logik hätte ich andere Schlüsse gezogen, aber vermutlich übersehe ich was...

ZitatNun ja, das ist ein Problem. Vielleicht sollten wir da wirklich nur auf das Mapping setzen?
Hmm, klar, man könnte es einschränken. Aber vermutlich kommt das Thema wieder auf den Tisch, wenn jemand meint, nicht eindeutige Mappings verwenden zu wollen. Muss vermutlich bei Gelegenheit nochmal etwas spielen, um ein Gefühl für die Gesamtzusammenhänge zu bekommen. Im Ergebnis sollte es für den User einfach zu durchschauen sein, warum was passiert bzw. eine Eingriffstelle bekannt sein, mit der man das ggf. "fixt" bzw. eindeutig bekommt.

ZitatIst richtig. Aber du wirst dir auf die Frage "Wie warm ist es in der Küche" nicht die Temperatur des Kühlschranks erwarten, oder? Da fragst du dann ja eher nach dem speziellen Gerät in dem speziellen Raum.
Schon, aber woher soll dann der Code wissen, welchen der Sensoren er jetzt heranziehen soll... Im Moment ist es einfach der erste gefundene Treffer, und das ganze aus einer Hash-Auswertung (=vermutlich zufällig...)

ZitatJa. Eindeutig. :D
Wie gesagt: muss mal nachdenken/spielen...

ZitatNochmal "Rhasspy"? Das schafft Verwirrung befürchte ich.
Bin da leidenschaftslos, zumal ich im Moment keinen Schimmer habe, wie man rausfinden kann, ob die URL/Port-Kombi erreichbar ist (auch wg. Log)...
Zitat
Vorschläge?
_Wenn_ wir irgendwie wüßten, dass der Dienst läuft und erreichbar ist wäre connected/disconnected m.E. ganz passabel.

ZitatIch habe in meinem produktiven FHEM ein paar Geräte mit gDT. Nach einem update sieht mein Rhasspy-Slot de.fhem.Room jetzt so aus:
[...]
Da werden FHEM-Räume hergenommen. Nicht gut. Sollte nur befüllt werden, wenn es zum Device einen rhasspyRoom gibt.
Finde ich auch nicht glücklich, würde aber den Schluss daraus ziehen, dass rhasspyRoom den room verdrängen sollte, wenn dieser gesetzt ist (sonst nicht).

Mit etwas Glück könnte das die Version im Anhang besser machen, für "Rhasspy" habe ich jetzt mal "IP_Port" verwendet, ist aber nur ein Vorschlag...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Cordula am 07 April 2021, 11:56:16
Bin auch auf die Version 0.46a umgestiegen und hab folgendes festgestellt:

Wenn ich das Licht im Arbeitszimmer schalten will, schaltet er das Licht in der Toilette. Den rhasspyNamen gibt es in mehreren Räumen, kann man aber über den Raum unterscheiden. Hier die Details:
attr Az.Licht rhasspyMapping SetOnOff:cmdOn=Schalten on,cmdOff=Schalten off,response={ResponseOnOff($DEVICE)}
attr Az.Licht rhasspyName Licht,Lampe
attr Az.Licht rhasspyRoom Arbeitszimmer


attr Flur.Toilette_Licht rhasspyMapping SetOnOff:cmdOn=Schalten on,cmdOff=Schalten off,response={ResponseOnOff($DEVICE)}
attr Flur.Toilette_Licht rhasspyName Licht,Lampe,Toilettenlicht
attr Flur.Toilette_Licht rhasspyRoom Toilette


2021.04.07 10:58:25 5: Parsed value: SetOnOff for key: intent
2021.04.07 10:58:25 5: Parsed value: mach das licht im arbeitszimmer an for key: rawInput
2021.04.07 10:58:25 5: Parsed value: arbeitszimmer-Okay Kalle-4d46865b-3283-4a55-89c8-cc9ff16b4136 for key: sessionId
2021.04.07 10:58:25 5: Parsed value: Licht for key: Device
2021.04.07 10:58:25 5: Parsed value: arbeitszimmer for key: Room
2021.04.07 10:58:25 5: Parsed value: mach das Licht im arbeitszimmer an for key: input
2021.04.07 10:58:25 5: Parsed value: arbeitszimmer for key: siteId
2021.04.07 10:58:25 5: Parsed value: 1 for key: probability
2021.04.07 10:58:25 5: handleIntentSetOnOff called
2021.04.07 10:58:25 5: Device selected (by hash, using only name): Flur.Toilette_Licht
2021.04.07 10:58:25 5: runCmd called with command: Schalten on
2021.04.07 10:58:25 5: Flur.Toilette_Licht Schalten on is a normal command
2021.04.07 10:58:25 5: Running command [Schalten on] on device [Flur.Toilette_Licht]
2021.04.07 10:58:25 5: runCmd called with command: {ResponseOnOff($DEVICE)}
2021.04.07 10:58:25 5: {ResponseOnOff($DEVICE)} is a perl command
2021.04.07 10:58:25 5: Response is Ok - Licht in Toilette ist angeschaltet


Wenn ich einen eindeutigen rhasspy-Namen verwende, funktioniert es.

In einem anderen Raum mit der gleichen Konstellation funktioniert das Schalten:

attr Kueche.Licht rhasspyMapping SetOnOff:cmdOn=Schalten on,cmdOff=Schalten off,response={ResponseOnOff($DEVICE)}
attr Kueche.Licht rhasspyName Licht,Lampe,Küchenlicht
attr Kueche.Licht rhasspyRoom Küche


2021.04.07 11:30:40 5: Parsed value: mach das Licht in der Küche an for key: input
2021.04.07 11:30:40 5: Parsed value: Küche for key: Room
2021.04.07 11:30:40 5: Parsed value: arbeitszimmer for key: siteId
2021.04.07 11:30:40 5: Parsed value: 1 for key: probability
2021.04.07 11:30:40 5: Parsed value: SetOnOff for key: intent
2021.04.07 11:30:40 5: Parsed value: an for key: Value
2021.04.07 11:30:40 5: Parsed value: mach das licht in der küche an for key: rawInput
2021.04.07 11:30:40 5: Parsed value: arbeitszimmer-Okay Kalle-f0ab281c-1232-445b-84a0-bd4c72efc9e1 for key: sessionId
2021.04.07 11:30:40 5: handleIntentSetOnOff called
2021.04.07 11:30:40 5: Device selected (by hash, with room and name): Kueche.Licht


Einmal sucht er nur über den Namen und einmal über den Namen und den Raum.
Hab ich da was falsch definiert oder wo liegt das Problem.

Zum anderen habe ich einen rhasspyIntent ohne Parameter definiert. Hat bisher funktioniert, jetzt bringt er folgende Fehlermeldung:

rhasspyIntent wie folgt definiert
MyOpen=MyOpen()

Parsed value: 1 for key: probability
2021.04.07 11:00:59 5: Parsed value: arbeitszimmer for key: siteId
2021.04.07 11:00:59 5: Parsed value: Sind türen oder Fenster offen for key: input
2021.04.07 11:00:59 5: Parsed value: arbeitszimmer-Okay Kalle-a84627b5-951d-44db-89b8-f7b939c8f90c for key: sessionId
2021.04.07 11:00:59 5: Parsed value: sind türen oder fenster offen for key: rawInput
2021.04.07 11:00:59 5: Parsed value: MyOpen for key: intent
2021.04.07 11:00:59 5: handleCustomIntent called with MyOpen key
2021.04.07 11:00:59 5: Calling sub:  MyOpen( "" )
2021.04.07 11:00:59 1: ERROR evaluating  MyOpen( "" ) : Too many arguments for main::MyOpen at (eval 192598) line 1, near """ )


Desweiteren ist mir aufgefallen, dass bei rhasspyIntents Parameter, die eigentlich leer sind, jetzt der Name des Parameters enthalten. Eigentlich das Gleiche wie oben. Je nach Befehl werden unterschiedliche Variablen gefüllt.
In dem Beispiel sind Room und Change eigentlich leer.

Parsed value: mach die lamellen der türjalousie auf fünfzig prozent for key: rawInput

MyBlinds=MyBlinds(Device,Room,Value,Change,Lamellen)

Calling sub:  MyBlinds( "Az.Jalousie_Tuer","Room","50","Change","lamellen" )


Zunächst einmal Danke für eure Arbeit. Wenn mir noch was auffällt, melde ich mich.

PS:
Das getNumeric-Problem habe ich auch. Für mich wäre folgende Reihenfolge der Devicebestimmung ok.


Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 07 April 2021, 12:44:16
Hmm, was die "Arbeitszimmer"-Thematik angeht würde ich auf ein Problem mit Groß/Kleinschreibung tippen. Sollte in der angehängten Version gelöst sein, da müßten dann sowohl Räume wie Namen alle in Kleinschreibung an Rhasspy übermittelt werden. (Habe bisher nur mit Kleinschreibung experimentiert).

Das mit parameterlosen Perl-Aufrufen und (echtem) "undef" statt des Parameternamens könnte mit dem Anhang auch funktionieren, ist aber ungetestet.

PS:
Das getNumeric-Problem habe ich auch. Für mich wäre folgende Reihenfolge der Devicebestimmung ok.
Zuordnung über den Type (z.B. Temperatur)Zuordnung über einen eindeutigen Devicenamen und den Raum. Wenn der Raum fehlt, wird die siteid als Raum genommen. Zuordnung über einen eindeutigen Devicenamen, den es nur einmal im System gibt (z.B. hab ich nur ein Gerät, das den CO2-Gehalt misst.

Meinem Bauchgefühl nach ist "Type" eigentlich "gesetzt", ich hatte aber auch ein paar seltsame Ergebnisse, wenn der Devicename nicht sauber erkannt wurde.
Die Suche sollte dann immer über Devicename und Raum gehen (ggf. abgeleitet von siteId bzw. der Reading-Auswertung), spannend wird es erst, wenn da nichts zu finden ist. Dann sollte nämlich der Raum mit angesagt werden, aus dem das dann geholt worden ist, ganz unabhängig davon, ob es nun genau einen Treffer gab oder mehrere.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Cordula am 07 April 2021, 14:03:10
Also der parameterlose Perlaufruf funktioniert.

Bei den undefinierten Parametern habe ich folgendes Ergebnis:

Calling sub:  MyBlinds( ,,"50",,"lamellen" )
2021.04.07 13:35:42 1: ERROR evaluating  MyBlinds( ,,"50",,"lamellen" ) : syntax error at (eval 221535) line 1, near "( ,"


Beim Problem mit dem Licht schalten im Arbeitszimmer, wird nun das Schlafzimmerlicht geschaltet, es wird aber immer nur noch nach dem Namen gesucht.

Parsed value: mach das licht im arbeitszimmer an for key: rawInput
2021.04.07 13:49:19 5: Parsed value: SetOnOff for key: intent
2021.04.07 13:49:19 5: Parsed value: an for key: Value
2021.04.07 13:49:19 5: Parsed value: 1 for key: probability
2021.04.07 13:49:19 5: Parsed value: arbeitszimmer for key: siteId
2021.04.07 13:49:19 5: Parsed value: mach das Licht im arbeitszimmer an for key: input
2021.04.07 13:49:19 5: Parsed value: arbeitszimmer for key: Room
2021.04.07 13:49:19 5: Parsed value: Licht for key: Device
2021.04.07 13:49:19 5: handleIntentSetOnOff called
2021.04.07 13:49:19 5: Device selected (by hash, using only name): Sz.Lichter
2021.04.07 13:49:19 5: runCmd called with command: Schalten on
2021.04.07 13:49:19 5: Sz.Lichter Schalten on is a normal command
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 07 April 2021, 14:13:28
Hmm, da muss wohl ein "echtes undef" hin, sollte so klappen:

for (@rets) {
            if ($_ eq 'NAME') {
                $_ = qq{"$hash->{NAME}"};
            } elsif ($_ eq 'DATA') {
                $_ = $data;
            } elsif (defined $data->{$_}) {
                $_ = qq{"$data->{$_}"};
            } else {
                $_ = "undef";
            }
        }

(Das sieht grausam aus, finde ich auch...!).

Was den Raumnamen angeht: Hattest du die devicemap aktualisiert bzw. FHEM neu gestartet? (M.E. sollte das mit der devicemap zwingend sein, damit auch Rhasspy wieder konsistente Daten hat).

Stehen denn dann ausschließlich "kleine" Räume und Namen im Hash? (Im Ergebnis sollten eigentlich letztendlich ausschließlich die echten Devicenamen korrekte Groß/Kleinschreibung aufweisen).

Ansonsten ist es wie schon geschrieben ein "Hash"-Zugriff und daher das Ergebnis bei mehreren potentiellen Matches innerhalb einer loop zufällig. (Fyi: Das kann früher etwas anders gewesen sein, weil das damals genutzte devspec2array vermutlich eine sortierte Liste zurückgibt.)
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 07 April 2021, 16:33:06
Zitat von: Beta-User am 07 April 2021, 11:33:34
Schon, aber woher soll dann der Code wissen, welchen der Sensoren er jetzt heranziehen soll...

Hmm, ist ein Argument. Hab nicht dran gedacht, dass die anderen Sensoren ja auch ein temperature-mapping haben könnten.

ZitatBin da leidenschaftslos, zumal ich im Moment keinen Schimmer habe, wie man rausfinden kann, ob die URL/Port-Kombi erreichbar ist (auch wg. Log)..._Wenn_ wir irgendwie wüßten, dass der Dienst läuft und erreichbar ist wäre connected/disconnected m.E. ganz passabel.

Da sollte einfach über ein curl/wget/HttpUtils gehen. Kommt was zurück, ist gut. Wenn nicht, nicht. ;). Wir könnten ja da einfach /api/profile abfragen.

ZitatFinde ich auch nicht glücklich, würde aber den Schluss daraus ziehen, dass rhasspyRoom den room verdrängen sollte, wenn dieser gesetzt ist (sonst nicht).

Bin noch nicht ganz überzeugt. Im Prinzip ist's egal, ob ich im Slot merkwürdige Raum-Namen habe. Schön ist's nicht.

Sollten wir alexaRoom, snipsRoom, etc. auch abfragen, wenn wir schon gDT verwenden?

Zitat
Mit etwas Glück könnte das die Version im Anhang besser machen, für "Rhasspy" habe ich jetzt mal "IP_Port" verwendet, ist aber nur ein Vorschlag...

Funktioniert. IP_Port ist aber nicht sooo glücklich. Da bin ich als IT-Profi gleich reingefallen und hab http:// nicht angegeben ;D
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 07 April 2021, 16:35:41
Blöde Frage: Wo bekomme ich eigentlich das genericDeviceType Attribut her? Hab das in meiner Test-Umgebung nicht.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 07 April 2021, 16:46:54
Zitat von: Beta-User am 07 April 2021, 11:33:34
Mit etwas Glück könnte das die Version im Anhang besser machen, für "Rhasspy" habe ich jetzt mal "IP_Port" verwendet, ist aber nur ein Vorschlag...

Kommando zurück. Ist IP_Port nicht im DEF angegeben, wird auch der Hash nicht befüllt.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 07 April 2021, 16:54:57
Zitat von: drhirn am 07 April 2021, 16:35:41
Blöde Frage: Wo bekomme ich eigentlich das genericDeviceType Attribut her? Hab das in meiner Test-Umgebung nicht.
Wenn du das in der DEF auf "use/1" setzt, sollte das Modul das selbst in die Liste der globalen Attribute einfügen ;) .

Zitat von: drhirn am 07 April 2021, 16:33:06
Hmm, ist ein Argument. Hab nicht dran gedacht, dass die anderen Sensoren ja auch ein temperature-mapping haben könnten.
Na ja, vermutlich finden wir dazu eine Lösung, muss ja nicht gleich sein... Evtl. sollten wir uns als erstes darum kümmern, dass eine nachvollziehbare Rückmeldung kommt, also Device (1. rhasspyName) und Room (selbe Logik) mit ausgegeben werden.

Zitat
Da sollte einfach über ein curl/wget/HttpUtils gehen. Kommt was zurück, ist gut. Wenn nicht, nicht. ;) . Wir könnten ja da einfach /api/profile abfragen.
Das ist nun gar nicht mein Kenntnishorizont...

ZitatBin noch nicht ganz überzeugt. Im Prinzip ist's egal, ob ich im Slot merkwürdige Raum-Namen habe. Schön ist's nicht.
Na ja, das war was, das ich bei meinen bisherigen Tests auch nicht gut fand, und an sich finde ich durchgängige Verwendung der "allgemeinen Logik" besser: Gibt der User in einem speziellen Attribut was an, verdrängt das die vom Modul zusammengesuchten.
Solange das "per Attribut-Gruppe" abgegrenzt ist, finde ich das eher hilfreich, schon alleine, weil Rhasspy die gegliederten Räume nicht sinnvoll aussprechen kann...

Zitat
Sollten wir alexaRoom, snipsRoom, etc. auch abfragen, wenn wir schon gDT verwenden?
Na ja, ich wollte erst mal zeigen, wie es prinzipiell gehen könnte, von daher spricht wenig gegen "alexaRoom" (ist da auch das Trennzeichen ein ";"?). snipsRoom ist halt eigentlich ein Relikt, da würde es mehr Sinn machen, das dadurch zu überehmen, dass man als prefix "snips" angibt ;) . (Es fehlt "nur" eine Umbenennungsfunktion...)

ZitatFunktioniert. IP_Port ist aber nicht sooo glücklich. Da bin ich als IT-Profi gleich reingefallen und hab http:// nicht angegeben ;D
Wie gesagt, bin leidenschaftslos, aber dann sollte man vermutlich dem localhost:1201 auch den http://-header spendieren...?
Hier wird der Hash befüllt, kann nur nicht testen, ob das funktional ist. Grundsätzlich wird sich immer die Frage stellen, wieviel Nutzerführung man an der Stelle braucht/einprogrammieren will.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 07 April 2021, 17:16:59
Zitat von: Beta-User am 07 April 2021, 16:54:57
Wenn du das in der DEF auf "use/1" setzt, sollte das Modul das selbst in die Liste der globalen Attribute einfügen ;) .

Hab ich schon mal erwähnt, dass hier im Forum das Hand->Kopf Emoticon fehlt? ;D

ZitatEvtl. sollten wir uns als erstes darum kümmern, dass eine nachvollziehbare Rückmeldung kommt, also Device (1. rhasspyName) und Room (selbe Logik) mit ausgegeben werden.

Mhm, wär sinnvoll. Auch wenn ich irgendwie kurze, knackige Antworten bevorzuge. Also auf die Frage "Wie warm ist es im Wohnzimmer?", ist mir eigentlich die Antwort "21 Grad" lieber als "Die Temperatur im Wohnzimmer beträgt 21 Grad"

ZitatDas ist nun gar nicht mein Kenntnishorizont...

Ist eigentlich alles schon da (fetchSiteIds). Ich schau bei Gelegenheit mal, wie ich das missbrauchen könnte.

ZitatNa ja, ich wollte erst mal zeigen, wie es prinzipiell gehen könnte, von daher spricht wenig gegen "alexaRoom" (ist da auch das Trennzeichen ein ";"?).

Keine Ahnung. Müsste jemand anderes beantworten.

ZitatsnipsRoom ist halt eigentlich ein Relikt, da würde es mehr Sinn machen, das dadurch zu überehmen, dass man als prefix "snips" angibt ;) .

War nur ein Beispiel, weil mir sonst nichts eingefallen ist. Um irgendwelche Snips-Attribute brauchen wir uns nicht zu kümmern finde ich.

ZitatWie gesagt, bin leidenschaftslos, aber dann sollte man vermutlich dem localhost:1201 auch den http://-header spendieren...?

Ja, unbedingt!

ZitatHier wird der Hash befüllt, kann nur nicht testen, ob das funktional ist. Grundsätzlich wird sich immer die Frage stellen, wieviel Nutzerführung man an der Stelle braucht/einprogrammieren will.

Ich träume davon, dass einer defmod Rhasspy RHASSPY eingibt und dann mittels Pop-Ups durch die übrigen Angaben geleitet wird. Wie bei attrTemplate. ;)
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 07 April 2021, 17:37:00
Zitat von: drhirn am 07 April 2021, 17:16:59
Hab ich schon mal erwähnt, dass hier im Forum das Hand->Kopf Emoticon fehlt? ;D
Hatte ich nicht schon angemerkt, dass es gar nicht so einfach ist, immer den Überblick zu behalten...?
Zitat
Ich träume davon, dass einer defmod Rhasspy RHASSPY eingibt und dann mittels Pop-Ups durch die übrigen Angaben geleitet wird. Wie bei attrTemplate. ;)
Sowas könnte man schon machen, ABER: Entweder man arbeitet mit defaults, dann braucht der User praktisch NICHTS anzugeben (btw. @JensS: encoding steht per default auf UTF-8, das braucht man nur zu setzen, wenn man es anders haben will), oder man zwingt ihn dazu, was anzugeben; das wäre über Prüfungen in der DEF machbar, vorausgesetzt, wir benötigen keine asynchronen Rückmeldungen.

MAn. sollte man es dem User bei so einer komplexen Geschichte wie Rhasspy zumuten, mal in die cref-Optionen reinzuschauen, weil er nur dann erkennen kann, ob es da Dinge gibt, die ihn sehr viel weiterbringen könnten - wie z.B. die Sache mit verschiedenen Sprachen oder präfixen und fhemId's...

Daher finde ich eine sinnvolle Vorbelegung die zielführendste Variante, denn in der Detailansicht/im list kann dann der User sehen, was alles "Sache" ist. Gefällt es ihm dann nicht (oder stellt er sich die Frage, warum es da steht), kann er in die cref schauen, und wir Helfer haben via list eine Übersicht.

ZitatMhm, wär sinnvoll. Auch wenn ich irgendwie kurze, knackige Antworten bevorzuge. Also auf die Frage "Wie warm ist es im Wohnzimmer?", ist mir eigentlich die Antwort "21 Grad" lieber als "Die Temperatur im Wohnzimmer beträgt 21 Grad"
Prinzipielle Zustimmung. Setzt voraus, dass wir uns im Code merken, ob das "Ergebnis" eindeutig war (Device, Raum, Mapping). Wenn nicht => andere Rückmeldung. (Vermutlich) kein Hexenwerk, aber (zu treibender) Aufwand.

ZitatIst eigentlich alles schon da (fetchSiteIds). Ich schau bei Gelegenheit mal, wie ich das missbrauchen könnte.
Gerne :) .

ZitatKeine Ahnung. Müsste jemand anderes beantworten.
Hatte auf die Schnelle die Doku durchforstet und zum ganzen nur Bruchstücke gefunden, uA. eben den Hinweis, dass alexaName per Semicolon trennt (super... ganz im Stile aller sonstigen FHEM-Konventionen...)

ZitatWar nur ein Beispiel, weil mir sonst nichts eingefallen ist. Um irgendwelche Snips-Attribute brauchen wir uns nicht zu kümmern finde ich.
Na ja, wenn man das mit einem simplen "prefix"-Trick hinbekommt, soll's mir recht sein. Aber zusätzlichen Aufwand würde ich nicht reinstecken wollen.

ZitatJa, unbedingt!
(Hoffentlich) done, siehe Anhang...
Im Sinne von: "User kann stressfrei direkt mit den defaults loslegen" die Frage, ob das auch paßt, wenn Rhasspy in docker auf demselben Server läuft?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 07 April 2021, 17:54:25
Zitat von: Beta-User am 07 April 2021, 17:37:00
Sowas könnte man schon machen, ABER: Entweder man arbeitet mit defaults, dann braucht der User praktisch NICHTS anzugeben, oder man zwingt ihn dazu, was anzugeben; das wäre über Prüfungen in der DEF machbar, vorausgesetzt, wir benötigen keine asynchronen Rückmeldungen.

MAn. sollte man es dem User bei so einer komplexen Geschichte wie Rhasspy zumuten, mal in die cref-Optionen reinzuschauen, weil er nur dann erkennen kann, ob es da Dinge gibt, die ihn sehr viel weiterbringen könnten - wie z.B. die Sache mit verschiedenen Sprachen oder präfixen und fhemId's...

Daher finde ich eine sinnvolle Vorbelegung die zielführendste Variante, denn in der Detailansicht/im list kann dann der User sehen, was alles "Sache" ist. Gefällt es ihm dann nicht (oder stellt er sich die Frage, warum es da steht), kann er in die cref schauen, und wir Helfer haben via list eine Übersicht.

Nun ja, mein Traum beinhaltet mit den Default-Werten vorbelegte Pop-Ups und einer Erklärung zur jeweiligen Einstellung dazu. Entweder man gibt was ein, oder übernimmt mit "Weiter" den Default-Wert.
Die Sache mit Asynchron ist halt ein Problem. Da müsste dann sichergestellt werden, dass mindestens das Modul danach neu geladen wird.


Zitat(super... ganz im Stile aller sonstigen FHEM-Konventionen...)

Ist das jetzt ironisch gemeint? Oder sollten wir auch auf Strickpunkt umstellen?

ZitatIm Sinne von: "User kann stressfrei direkt mit den defaults loslegen" die Frage, ob das auch paßt, wenn Rhasspy in docker auf demselben Server läuft?

Solange FHEM nicht in einem Container läuft, sollte das funktionieren. Das muss aber eh der User selber wissen.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 07 April 2021, 18:54:17
Zitat von: drhirn am 07 April 2021, 17:54:25
Nun ja, mein Traum beinhaltet mit den Default-Werten vorbelegte Pop-Ups und einer Erklärung zur jeweiligen Einstellung dazu. Entweder man gibt was ein, oder übernimmt mit "Weiter" den Default-Wert.
Die Sache mit Asynchron ist halt ein Problem. Da müsste dann sichergestellt werden, dass mindestens das Modul danach neu geladen wird.
Ja, Träume...
Wird eher nichts werden, und wir werden die Nutzerführung halt auf herkömmliche Weise via commandref machen :P .


Ist das jetzt ironisch gemeint? Oder sollten wir auch auf Strickpunkt umstellen?

Ja, aber eher in die andere Richtung: Es gibt allgemeine Attribute für room und group, da wird Komma-getrennt; warum das jetzt alexa an der ähnlichen Stelle anders macht, erschließt sich mir nicht.
ZitatSolange FHEM nicht in einem Container läuft, sollte das funktionieren. Das muss aber eh der User selber wissen.
Dann ist es gut so...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 07 April 2021, 20:49:15
Auf der Suche nach der Außentemperatur bin ich über leere @matchesInRoom gestolpert und habe RHASSPY_getDevicesByIntentAndType etwas angepasst.# Sammelt Geräte über Raum, Intent und optional Type
sub RHASSPY_getDevicesByIntentAndType {
    my $hash   = shift // return;
    my $room   = shift;
    my $intent = shift;
    my $type   = shift; #Beta-User: any necessary parameters...?

my @matchesInRoom; my @matchesOutsideRoom;
    my $prefix = $hash->{prefix};
   
    return if !defined $hash->{helper}{devicemap};
    for my $devs (keys %{$hash->{helper}{devicemap}{devices}}) {
        my $mapping = RHASSPY_getMapping($hash, $devs, $intent, $type, 1, 1) // next;
        my $mappingType = $mapping->{type};
        my @rooms = $hash->{helper}{devicemap}{devices}{$devs}{rooms};

        # Geräte sammeln
        if ( !defined $type ) {
            #any { m{\A$room\z}ix } @rooms
            any { $_ eq $room } @rooms
                ? push @matchesInRoom, $devs
                : push @matchesOutsideRoom, $devs;
        }
if ( defined $type && $mappingType && $type =~ m{\A$mappingType\z}ix ) {
my @Hilfsarray = @{ $rooms[0] };
            for (my $i=0;$i < @Hilfsarray;$i++){
if ( $room eq  $rooms[0][$i]){
            push @matchesInRoom, $devs}else{
            push @matchesOutsideRoom, $devs};
    }
        }
    }
    return (\@matchesInRoom, \@matchesOutsideRoom);
}

$rooms[0][$i] passt bei mir. Habe aber jeweils nur einen Raum pro Gerät. Hab's nochmal überarbeitet...
In sentence.ini musste zusätzlich, wie in den vorigen Beiträgen beschrieben, Type:Temperatur in Type:temperature geändert werden.

Gruß Jens

p.s. any { $_ eq $room } @roomsWas macht "any"? G??gle findet bei "any" many...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 08 April 2021, 11:53:06
Danke vorab mal für den Schubs betr. "inRoom".

"any" gehört zu List::Util, und sollte dasselbe machen wie zuvor das "grep", siehe https://perldoc.perl.org/List::Util.pm#any (https://perldoc.perl.org/List::Util.pm#any). Leider hat aber auch schon das grep nicht das geliefert, was es sollte :o .

Hab's daher jetzt umgebaut und dabei auch gleich die Rückmeldung im Fall des "matchoutside" etwas angepaßt, so dass jetzt wenigstens der richtige Raum angesagt werden sollte, falls sich das device nicht im Raum befindet.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Cordula am 08 April 2021, 11:58:43
@Beta-User
Wollte dir noch Rückmeldung geben. Ich habe jetzt die 0.4.7a im Einsatz. Damit funktioniert der rhasspyIntent ohne Parameter und der rhasspyIntent mit undef-Parametern. Das Problem mit dem Intent SetOnOff ist auch gelöst, allerdings erst nachdem ich die Räume und die Device händisch auf Kleinschreibung umgestellt habe und die Slots händisch angepasst habe. Dabei ist mir aufgefallen, dass der Update der Slots nicht mehr funktioniert, da hier jetzt nicht mehr das Attribut rhasspyMaster verwendet wird, sondern http://localhost:12101.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 08 April 2021, 12:09:06
Das ist leider noch nicht dokumentiert. Wir haben die URL zur Base in die DEF übernommen, damit man das Attribut nicht vergessen kann. Du müsstest also die DEF um IP_Port=<url zur base:port> ergänzen.

Und danach das Modul neu laden reload 10_RHASSPY.pm
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 08 April 2021, 12:13:29
Danke für any!

Wieso schiebst Du die Räume überhaupt als Array in rooms? Als einzelne Listenelemente des Hashes würden sie eine Ebene höher liegen und man könnte auch direkt darauf zugreifen.

Gruß Jens
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 08 April 2021, 12:26:54
Hier nochmal ein update, ich habe das jetzt nach WebIF umbenannt und die cref entsprechend erweitert.
Weiter statt "localhost" die nummerische Entsprechung eingearbeitet (Namensauflösungen können blockieren, daher sollte das hier m.E. beispielhaft auch gleich nummerisch sein...).

Ob rooms (und ggf. auch andere Infos wie rhasspyNames etc.) als Array Sinn machen, muss ich mal schauen, aber das wäre eh' nur ein internes Ding. Klingt mir aber immer mehr so...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Cordula am 08 April 2021, 12:40:31
@drhirn
Alles klar, habs angepasst. Funktioniert. Danke.

Hab jetzt erst gesehen, dass du eine neue Version gemacht hast. Bei der neuen Version wird WebIf übernommen. Aber für den Rhasspy-Update scheinbar immer noch IP_port genommen, der auf localhost steht. Also kein Update.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 08 April 2021, 13:07:20
Das Internal IP_Port verschwindet erst nach einem Neustart, und für das neue Internal braucht es auch entweder einen Neustart oder das Anfassen der DEF (würde letzteres empfehlen, um gleich die korrekte Info unter dem aktuellen Namen einzugeben).
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Cordula am 08 April 2021, 14:00:27
Passt.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 08 April 2021, 14:14:15
Zitat von: Beta-User am 08 April 2021, 12:26:54
Ob rooms (und ggf. auch andere Infos wie rhasspyNames etc.) als Array Sinn machen, muss ich mal schauen, aber das wäre eh' nur ein internes Ding. Klingt mir aber immer mehr so...
"Eigentlich" ist es im list als Komma-separierte Liste schöner, da diese Angaben dann auch gleich vorne zusammen erscheinen...

Allerdings ist der Umbau "gefahrgeneigt", weil unpassende Datentypen FHEM in den Abgrund reißen. Ich hoffe, alle relevanten Stellen erwischt zu haben, aber ausdrücklich: Experimentelle Version! (also noch experimenteller als üblich... ::) ;D :P )

Nachtrag: Da sich der erwartete devicemap-Hash ändert, muss dieser erneuert werden! (Neustart oder reload devicemap)
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 08 April 2021, 14:30:10
Die experimentelle Version teste ich heute Abend. Hab ich etwas spät gelesen, da ich beim experimentieren war.   ;D
$hash->{helper}{devicemap}{devices}{Sensor3}{raueme}{aussen} = 'aussen';
$hash->{helper}{devicemap}{devices}{Sensor3}{raueme}{Garten} = 'Garten';
if ( exists $hash->{helper}{devicemap}{devices}{$devs}{raueme}{$room}){push @matchesInRoom, $devs}else{push @matchesOutsideRoom, $devs;}
        }

Gruß Jens
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 08 April 2021, 14:34:26
Für's Analysieren noch: Es gibt jetzt @verbose 5 ein paar neue Log-Einträge, damit man besser nachvollziehen kann, was jeweils als @matches rausgekommen ist...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 08 April 2021, 16:17:30
Dann gleich noch ein update der experimentellen Version...

- der in der cref enthaltene Filter für die language und fhemId-Geschichte ist jetzt nicht nur Teil der cref, sondern hoffentlich auch im Code aktiv...
- überflüssige Attribute (defaultRoom und rhasspyMaster) sind aus der Attributliste raus; kann also sein, dass da entsprechende (einmalige) Logeinträge beim nächsten Start kommen...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 08 April 2021, 19:03:45
Prima, GetNumeric läuft mit {Type:temperature} für Room und Device.  :)
Info: {Type:Temperatur} funktioniert ausschließlich mit Device.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 09 April 2021, 10:03:20
Prima, keine Klagen bisher ::) ...

Zitat von: JensS am 08 April 2021, 19:03:45
Prima, GetNumeric läuft mit {Type:temperature} für Room und Device.  :)
Es scheint auch mit nur Raum zu klappen, allerdings eben nach wie vor mit der Einschränkung, dass potentiell jedes Gerät vom Type:temperature ausgelesen wird... Da das mit der Solltemperatur ein Spezialthema für "thermostat" ist, neige ich im Moment dazu, ggf. eine Sonderbehandlung für diesen Type vorzusehen; mal sehen...

ZitatInfo: {Type:Temperatur} funktioniert ausschließlich mit Device.
Das ist interessant, und evtl. auch hilfreich, um Sonderfälle abzufangen. Vom Bauchgefühl her würde ich aber behaupten, dass du damit auch die Helligkeit von einem Dimmer  und/oder den Öffnungsgrad eines Rollladens abfragen kannst, weil bei "bekanntem" Device eben abgerufen wird, was via GetNummeric verfügbar ist, wenn es nichts spezifisches gibt (und "Temperatur" wird ggf. - im Unterschied zu den meisten anderen Keywords - auch weiter übersetzt).



Nachtrag:
Schaut auch bitte mal in eure Logs. Hin und wieder habe ich auch Warnings über "uninitialized value" bei diversen split-Aktionen etc.. Einen Teil davon sollte ich über die letzten Änderungen erwischt haben, aber über manches stolpert man erst, wenn man bestimmte Dinge einstellt oder Optionen nutzt. Die Fixe dazu sind meistens nichts großes, aber die Warnings eben unschön...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 09 April 2021, 10:18:30
ZitatPrima, GetNumeric läuft mit {Type:temperature} für Room und Device.  :)
Sorry, sollte heißen, das es in allen Konstellationen funktioniert.

Leider kann SetOnOff jetzt keinen Raum zum Device finden. "Licht an" im Wohnzimmer gesprochen, schaltet das Licht im Flur an.
Ist bestimmt so, weil in der experientellen Version die Raumsuche erst mal nur auf GetNumeric umgebogen wurde.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 09 April 2021, 10:46:11
Das mit SetOnOff sollte eigentlich mit GetNumeric nicht direkt was zu tun haben, die Raumsuche ist ein gemeinsamer Baustein. Den habe ich aber nicht wegen "GetNumeric" angefasst, sondern wegen der ergänzenden Berücksichtigung von mobilen Geräten, was aber ohne passendes Reading ohne Auswirkung sein sollte.
Ich würde daher eher darauf tippen, dass es ein Groß-/Kleinschriebungs-Thema ist, das sich da auswirkt. Verbose 5 könnte Aufschluss geben, und evtl. schaust du dir auch das list und die slots mal an, ob die Schreibweisen da zusammenpaßen.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 09 April 2021, 11:22:21
Ok, hier die Verbose-Ausgabe:2021.04.09 11:20:39 5: RHASSPY: [Rhasspy] Parse (IO: rhasspyMQTT2): Msg: hermes/intent/de.fhem_SetOnOff => {"input": "licht an", "intent": {"intentName": "de.fhem:SetOnOff", "confidenceScore": 1.0}, "siteId": "Wohnzimmer", "id": null, "slots": [{"entity": "de.fhem.Device", "value": {"kind": "Unknown", "value": "licht"}, "slotName": "Device", "rawValue": "licht", "confidence": 1.0, "range": {"start": 0, "end": 5, "rawStart": 0, "rawEnd": 5}}, {"entity": "Value", "value": {"kind": "Unknown", "value": "an"}, "slotName": "Value", "rawValue": "an", "confidence": 1.0, "range": {"start": 6, "end": 8, "rawStart": 6, "rawEnd": 8}}], "sessionId": "Wohnzimmer-alexa-6af6e108-5634-4084-b10a-5efe1c48b2cb", "customData": null, "asrTokens": [[{"value": "licht", "confidence": 1.0, "rangeStart": 0, "rangeEnd": 5, "time": null}, {"value": "an", "confidence": 1.0, "rangeStart": 6, "rangeEnd": 8, "time": null}]], "asrConfidence": null, "rawInput": "licht an", "wakewordId": "alexa", "lang": null}
2021.04.09 11:20:39 5: Parsed value: licht for key: Device
2021.04.09 11:20:39 5: Parsed value: licht an for key: rawInput
2021.04.09 11:20:39 5: Parsed value: an for key: Value
2021.04.09 11:20:39 5: Parsed value: Wohnzimmer-alexa-6af6e108-5634-4084-b10a-5efe1c48b2cb for key: sessionId
2021.04.09 11:20:39 5: Parsed value: SetOnOff for key: intent
2021.04.09 11:20:39 5: Parsed value: licht an for key: input
2021.04.09 11:20:39 5: Parsed value: 1 for key: probability
2021.04.09 11:20:39 5: Parsed value: Wohnzimmer for key: siteId
2021.04.09 11:20:39 5: handleIntentSetOnOff called
2021.04.09 11:20:39 5: Device selected (by hash, using only name): Flurlicht
2021.04.09 11:20:39 5: runCmd called with command: on
2021.04.09 11:20:39 5: Flurlicht on is a normal command
2021.04.09 11:20:39 5: Running command [on] on device [Flurlicht]
2021.04.09 11:20:39 5: runCmd called with command: {ResponseOnOff($DEVICE)}
2021.04.09 11:20:39 5: {ResponseOnOff($DEVICE)} is a perl command
2021.04.09 11:20:39 5: Response is Ok - Licht im Flur ist eingeschaltet


Meine Slots sind plötzlich klein geschrieben und es gibt neuerdings englische Slots mit z.B. Wohnzimmer. Die englischen und deutschen Slots sind zudem mit der falschen Sprache befüllt.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 09 April 2021, 11:27:07
Ich hab in der 0.4.7b mal eine Überprüfung eingebaut, die die Verbindung zum WebIF prüft. Die setzt das "state"-Reading auf "online" oder den Fehler.

Wird jedes Mal ausgeführt, wenn eine Verbindung zum HTTP-API aufgebaut wird (train, updateSlots, fetchSiteIDs, etc.). Das ist nicht ganz glücklich, eine bessere Idee hatte ich aber nicht. Vorteil ist, fetchSiteIDs wird gleich nach dem define aufgerufen wenn ich das richtig sehe. Nachteil ist, es dauert halt im schlimmsten Fall 120s (Timeout), bis das Ergebnis da ist.


sub RHASSPY_ParseHttpResponse {
...
    if ($err) {
        readingsBulkUpdate($hash, 'state', $err);
        readingsEndUpdate($hash, 1);
        Log3($hash->{NAME}, 1, "Connection to Rhasspy base failed: $err");
        return;
    }
...
    readingsBulkUpdate($hash, 'state', "online");
    readingsEndUpdate($hash, 1);
    return;
}


Jemand eine bessere Idee?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 09 April 2021, 11:29:44
@JensS:
OK, scheint wirklich ein "lc"-Thema zu sein, allerdings aus einer unvermuteten Richtung: die siteId beginnt "Kapital".

Kannst du mal "lc" (ca. in Zeile 1281) ergänzen und dann nochmal testen:
$room = ReadingsVal($hash->{NAME}, $rreading, lc $data->{siteId});

@drhirn:
Das wäre ggf. wirklich ein Thema, das in die developer-Ecke gut aufgehoben wäre...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 09 April 2021, 11:43:50
ACHTUNG!

In der aktuellen 0.4.7b wurde WebIF durch baseUrl ersetzt, nachdem ich mit WebIF zu viele Gross-/Kleinschreibfehler gemacht habe ;D

Eine 0.4.7b Definition sieht also derzeit z.B. wie folgt aus:
define Rhasspy RHASSPY baseUrl=http://127.0.0.1:12101 devspec=room=Rhasspy defaultRoom=default language=en fhemId=fhem prefix=rhasspy useGenericAttrs=1
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 09 April 2021, 12:00:39
 ;D
Kein Problem...
Nur zur Klarstellung: Fast alle der Parameter in der "Muster-define" kann man weglassen, mind. für baseUrl, fhemId und prefix stimmt das aus dem Kopf heraus auch so. (Daher ist mir der Name für baseUrl auch egal, ich muss nur nach dem reload die DEF (ohne Änderung) anfassen, dann passt das wieder ;) .)
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 09 April 2021, 12:08:30
Stimmt für alle. Definition kann auch so aussehen:
define Rhasspy RHASSPY

Was passiert, wenn ich useGenericAttrs=0 eingebe?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 09 April 2021, 12:11:35
Es kommt mit "0" in die Internals, Reaktion vom Modul dann:
_analyze_genDevType($hash, $_) if $hash->{useGenericAttrs};
0 ist bool-falsch => wird ignoriert. Interessanter wäre, was "false" bewirkt ;) .
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 09 April 2021, 12:12:24
Beim Attribut genericDeviceType haben wir kein Auswahlfeld. Nur ein Textfeld für den Input. War das geplant?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 09 April 2021, 12:16:02
Jein. Dieses Attribut "gehört" eigentlich nicht RHASSPY, sondern ist ein gemeinsames für alle Arten der Sprachsteuerung. Von daher _glaube_ ich, dass es besser ist, da keine Einschränkungen von RHASSPY aus "reinzuknödeln".
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 09 April 2021, 12:17:51
Naja. Aber woher weiß ich, was ich reinschreiben könnte, wenn ich nur Rhasspy habe?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 09 April 2021, 12:23:49
Es steht (nicht sehr prominent) in der commandref, was bisher seitens RHASSPY unterstützt wird. Ansonsten sind der Möglichkeiten viele, RHASSPY unterstützt bei weitem nicht alles, und ich bin mir auch nicht sicher, wo man da eine Grenze ziehen sollte...

Dieses feature ist für zwei Anwendergruppen gedacht:
a) (potentielle) Umsteiger, die schon was anderes nutzen und erst mal "schnell testen" wollen, wie das mit Rhasspy so funktioniert;
Wird da "zu viel vereinnahmt", wird die Struktur in Rhasspy schnell unübersichtlich und vielleicht (?) die Ergebnisse verwirrend (Sensoren etc.)
b) Neueinsteiger, die es sich mit der Konfiguration einfach machen wollen. Für die gehen dann "einfache" Geräte schnell zu konfigurieren...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 09 April 2021, 12:30:30
Ach du meine Güte, jetzt hab ich aber lange gesucht. Hast du gut versteckt ;D

Es gibt:
* switch
* light
* thermostat
* blind
* media
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 09 April 2021, 12:41:18
 ;D na ja, die cref-Ergänzungen habe ich halt erst mal auf die Schnelle zusammengenagelt mit Prio auf (vollständige) Ergänzung meines "Gewurstels" in der Hoffnung, dass sich dann schon jemand findet, der das aufhübscht und ggf. verständlicher macht... ;D
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 09 April 2021, 12:45:45
Ah, verstehe. Haha ;D
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 09 April 2021, 12:48:39
Ich spiele gerade mit den gDTs. In der FHEM-Demo gibt's ein Device "ct light". Was zu einem spannenden Ergebnis führt:


2021.04.09 12:45:10.018 5: RHASSPY: [Rhasspy] Parse (IO: rhasspyMQTT2): Msg: hermes/intent/de.fhem_SetOnOff => {"input": "ct light aus", "intent": {"intentName": "de.fhem:SetOnOff", "confidenceScore": 1.0}, "siteId": "wohnzimmer", "id": null, "slots": [{"entity": "de.fhem.Device", "value": {"kind": "Unknown", "value": "ct light"}, "slotName": "Device", "rawValue": "ct light", "confidence": 1.0, "range": {"start": 0, "end": 8, "rawStart": 0, "rawEnd": 8}}, {"entity": "OnOffValue", "value": {"kind": "Unknown", "value": "aus"}, "slotName": "Value", "rawValue": "aus", "confidence": 1.0, "range": {"start": 9, "end": 12, "rawStart": 9, "rawEnd": 12}}], "sessionId": "wohnzimmer-snowboy-cf7a096b-ba3b-4fa2-ba5d-124f78b13b22", "customData": "snowboy", "asrTokens": [[{"value": "ct", "confidence": 1.0, "rangeStart": 0, "rangeEnd": 2, "time": null}, {"value": "light", "confidence": 1.0, "rangeStart": 3, "rangeEnd": 8, "time": null}, {"value": "aus", "confidence": 1.0, "rangeStart": 9, "rangeEnd": 12, "time": null}]], "asrConfidence": null, "rawInput": "ct light aus", "wakewordId": "snowboy", "lang": null}
2021.04.09 12:45:10.019 5: Parsed value: ct light aus for key: rawInput
2021.04.09 12:45:10.019 5: Parsed value: wohnzimmer for key: siteId
2021.04.09 12:45:10.020 5: Parsed value: SetOnOff for key: intent
2021.04.09 12:45:10.020 5: Parsed value: 1 for key: probability
2021.04.09 12:45:10.020 5: Parsed value: wohnzimmer-snowboy-cf7a096b-ba3b-4fa2-ba5d-124f78b13b22 for key: sessionId
2021.04.09 12:45:10.020 5: Parsed value: aus for key: Value
2021.04.09 12:45:10.020 5: Parsed value: ct light aus for key: input
2021.04.09 12:45:10.020 5: Parsed value: ct light for key: Device
2021.04.09 12:45:10.021 5: handleIntentSetOnOff called
2021.04.09 12:45:10.021 5: Device selected (by hash, using only name): CT
2021.04.09 12:45:10.021 5: runCmd called with command: off
2021.04.09 12:45:10.022 5: CT off is a normal command
2021.04.09 12:45:10.022 5: Running command [off] on device [CT]


"ct light" wird noch als Device angenommen, der Befehl wird dann aber am Device "CT" ausgeführt.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 09 April 2021, 12:55:05
Mir kommt das logisch vor: Der alias von "CT" ist "CT Light". Das wird zu lowercase "ct light" und scheinbar korrekt dann beim Schalten wieder "CT" zugeordnet. Sieht für mich ok aus, oder übersehe ich was?

Zitat von: drhirn am 09 April 2021, 12:45:45
Ah, verstehe. Haha ;D
Na ja, war nur bedingt ernst gemeint... Thema war eher, dass ich mir noch nicht sicher bin, wie weit man mit dem feature gehen sollte und wie schnell das wächst bzw. was auch wieder raus kommt.
Aber das obige Beispiel zeigt, dass man praktisch "nichts" machen muss, um zu (m.E.) passablen Ergebnissen zu kommen :P .
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 09 April 2021, 13:00:44
Ich war verwirrt. Das Device heißt ja wirklich "CT".
Und mir war nicht klar, dass der Alias für ein "updateSlots" genommen wird.

Führt aber dazu, dass der Status des Devices mal wieder nicht automatisch aktualisiert wird.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 09 April 2021, 13:12:03
Bei gDT-Nutzung gibt es eine gewisse Logik für die Ermittlung der "rhasspyNames": siri- und alexaNames werden vorrangig berücksichtigt, dann der alias, und wenn es all das nicht gibt, eben der NAME.
Wenn gesetzt, wird all das verdrängt durch rhasspyName.

Das mit dem ausbleibenden Trigger wäre schlecht, ich kann das aber grade am Code nicht nachvollziehen. Vermute eher, dass wir es hier mit einem "Problem" aus readingsProxy zu tun haben, dieses Modul ist "speziell", was triggern angeht.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 09 April 2021, 13:22:23
readingsProxy?

Bei einem Gerät ohne Alias (Livingroom) funktioniert das Update.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 09 April 2021, 13:38:44
Mit dem neuen "update devicemap" scheint mir, dass das Rhasspy-Training zu früh gestartet wird. Kann das sein? Ich muss nach dem "update devicemap" immer noch ein Training durchführen, damit neue Geräte von Rhasspy erkannt werden.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Cordula am 09 April 2021, 13:40:45
Hier noch ein Input zu getNumeric:

sentence.ini= \[(wie ist der|wie ist die)] (co2-gehalt|kohlendioxid-gehalt|luft){Device} [im] [$de.fhem.Room{Room}]

rhasspyMapping = GetNumeric:currentVal=co2,response="Der CO2-Gehalt im Wohnzimmer beträgt [Innenstation:co2] ppm"

Parsed value: wie ist die luft im wohnzimmer for key: input
2021.04.09 13:20:36 5: Parsed value: wohnzimmer for key: Room
2021.04.09 13:20:36 5: Parsed value: wie ist die luft im wohnzimmer for key: rawInput
2021.04.09 13:20:36 5: Parsed value: 1 for key: probability
2021.04.09 13:20:36 5: Parsed value: GetNumeric for key: intent
2021.04.09 13:20:36 5: Parsed value: arbeitszimmer-Okay Kalle-ba28009c-d448-403a-a923-dec0e5339388 for key: sessionId
2021.04.09 13:20:36 5: Parsed value: arbeitszimmer for key: siteId
2021.04.09 13:20:36 5: Parsed value: luft for key: Device
2021.04.09 13:20:36 5: handleIntentGetNumeric called
2021.04.09 13:20:36 5: Device selected (by hash, with room and name): Innenstation
2021.04.09 13:20:36 5: runCmd called with command: "Der CO2-Gehalt im Wohnzimmer beträgt [Innenstation:co2] ppm"
2021.04.09 13:20:36 5: "Der CO2-Gehalt im Wohnzimmer beträgt [Innenstation:co2] ppm" has quotes...
2021.04.09 13:20:36 5: ...and is now: Der CO2-Gehalt im Wohnzimmer beträgt [Innenstation:co2] ppm (Der CO2-Gehalt im Wohnzimmer beträgt 688 ppm)

Funktioniert laut Log. Es kommt aber keine Sprachausgabe.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 09 April 2021, 13:46:18
Zitat von: Cordula am 09 April 2021, 13:40:45
sentence.ini= \[(wie ist der|wie ist die)] (co2-gehalt|kohlendioxid-gehalt|luft){Device} [im] [$de.fhem.Room{Room}]

Entschuldigt, aber ich muss kurz vom Thema abweichen.

Was hast du da für ein Gerät?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Cordula am 09 April 2021, 13:54:03
Netatmo Innenstation / "Smarte Wetterstation"
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 09 April 2021, 14:09:09
@Cordula: Der Code erscheint mir an der Stelle nicht logisch bzw. vollständig...
Ändere mal (ca. #2744) von
if ( defined $mapping->{response} ) {
        return RHASSPY_getValue($hash, $device, $mapping->{response}, $value, $location);
    }
auf:
if ( defined $mapping->{response} ) {
        return RHASSPY_respond ($hash, $data->{requestType}, $data->{sessionId}, $data->{siteId}, RHASSPY_getValue($hash, $device, $mapping->{response}, $value, $location));
    }

Zitat von: drhirn am 09 April 2021, 13:38:44
Mit dem neuen "update devicemap" scheint mir, dass das Rhasspy-Training zu früh gestartet wird. Kann das sein? Ich muss nach dem "update devicemap" immer noch ein Training durchführen, damit neue Geräte von Rhasspy erkannt werden.
Das will ich nicht ausschließen; im Moment wird das halt nacheinander rausgehauen, ohne auf Rückmeldung zu warten oder eine kurze Pause. Könnte Sinn machen, da was einzubauen...

Zitat von: drhirn am 09 April 2021, 13:22:23
Bei einem Gerät ohne Alias (Livingroom) funktioniert das Update.
Weiß nicht, aber eigentlich wird ab Zeitpunkt x mit dem Device-NAME gearbeitet, dürfte also eigentlich keinen Unterschied machen, und dem Code ist es auch egal, ob das mal ein rhasspyName war oder ein siriName, ... oder eben alias.

Kann's nur grade auch nicht so einfach nachstellen bzw. irgendwie ist die demo-cfg komisch...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 09 April 2021, 14:19:32
Zitat von: Beta-User am 09 April 2021, 14:09:09
Das will ich nicht ausschließen; im Moment wird das halt nacheinander rausgehauen, ohne auf Rückmeldung zu warten oder eine kurze Pause. Könnte Sinn machen, da was einzubauen...

Müssen wir. Ich weiß nur nicht, wie wir da warten können.

ZitatKann's nur grade auch nicht so einfach nachstellen bzw. irgendwie ist die demo-cfg komisch...

Jup :D
Die Zugehörigkeiten zu den Gruppen sind z.B. durch Leerzeichen, statt durch Beistrich getrennt
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 09 April 2021, 14:31:34
InternalTimer. Ist z.B. auch für die init-Geschichte drin. Die Frage ist nur, wie lange das schlummern soll...

Zitat von: drhirn am 09 April 2021, 14:19:32
Die Zugehörigkeiten zu den Gruppen sind z.B. durch Leerzeichen, statt durch Beistrich getrennt
Hmm, FHEMWEB macht das irgendwie zwangsweise mit dem Komma... Sollte ggf. Rudi (?) mal in der demo anpassen?

Ansonsten müßten wir den Code dann wieder konsolidieren, wenn OK seitens Cordula+JensS kommt. Ich habe jetzt erst mal auch wegen deiner Änderungen darauf verzichtet, wieder eine vollst. Version zu posten.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 09 April 2021, 14:35:23
Zitat von: Beta-User am 09 April 2021, 14:31:34
Ansonsten müßten wir den Code dann wieder konsolidieren, wenn OK seitens Cordula+JensS kommt. Ich habe jetzt erst mal auch wegen deiner Änderungen darauf verzichtet, wieder eine vollst. Version zu posten.

Meine und deine Änderung sind online (https://github.com/drhirn/fhem-rhasspy/blob/0.4.7b/10_RHASSPY.pm).
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 09 April 2021, 14:44:28
Zitat von: Beta-User am 09 April 2021, 11:29:44
@JensS:
OK, scheint wirklich ein "lc"-Thema zu sein, allerdings aus einer unvermuteten Richtung: die siteId beginnt "Kapital".

Kannst du mal "lc" (ca. in Zeile 1281) ergänzen und dann nochmal testen:
$room = ReadingsVal($hash->{NAME}, $rreading, lc $data->{siteId});
Wie schaut's damit aus? (Und approved ist weder das noch die respond-Erägnzung).
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Cordula am 09 April 2021, 14:47:01
Mit der Codeänderung funktioniert die Sprachausgabe. Danke.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 09 April 2021, 14:54:25
Zitat von: Beta-User am 09 April 2021, 14:44:28
Wie schaut's damit aus?

Jetzt auch.



Ich versuche gerade, alle Lichter im Wohnzimmer auszuschalten. Bekomme aber immer nur die Antwort, dass kein Gerät gefunden wurde. Das Log meint, die sorted devices list sei leer. Liegt wahrscheinlich daran, dass sich in RHASSPY_getDevicesByGroup ab next if $allgroups =~ m{\b$group\b}x; nichts mehr tut. Da bleiben alle folgenden Variablen leer.


2021.04.09 14:46:19.652 5: RHASSPY: [Rhasspy] Parse (IO: rhasspyMQTT2): Msg: hermes/intent/de.fhem_SetOnOffGroup => {"input": "schalte alle lichter wohnzimmer aus", "intent": {"intentName": "de.fhem:SetOnOffGroup", "confidenceScore": 1.0}, "siteId": "default", "id": "c089e860-cfd7-4b41-8cd7-309653c11e3d", "slots": [{"entity": "de.fhem.Group", "value": {"kind": "Unknown", "value": "lichter"}, "slotName": "Group", "rawValue": "lichter", "confidence": 1.0, "range": {"start": 13, "end": 20, "rawStart": 13, "rawEnd": 20}}, {"entity": "de.fhem.Room", "value": {"kind": "Unknown", "value": "wohnzimmer"}, "slotName": "Room", "rawValue": "wohnzimmer", "confidence": 1.0, "range": {"start": 21, "end": 31, "rawStart": 21, "rawEnd": 31}}, {"entity": "OnOffValue", "value": {"kind": "Unknown", "value": "aus"}, "slotName": "Value", "rawValue": "aus", "confidence": 1.0, "range": {"start": 32, "end": 35, "rawStart": 32, "rawEnd": 35}}], "sessionId": "c089e860-cfd7-4b41-8cd7-309653c11e3d", "customData": null, "asrTokens": [[{"value": "schalte", "confidence": 1.0, "rangeStart": 0, "rangeEnd": 7, "time": null}, {"value": "alle", "confidence": 1.0, "rangeStart": 8, "rangeEnd": 12, "time": null}, {"value": "lichter", "confidence": 1.0, "rangeStart": 13, "rangeEnd": 20, "time": null}, {"value": "wohnzimmer", "confidence": 1.0, "rangeStart": 21, "rangeEnd": 31, "time": null}, {"value": "aus", "confidence": 1.0, "rangeStart": 32, "rangeEnd": 35, "time": null}]], "asrConfidence": null, "rawInput": "schalte alle lichter wohnzimmer aus", "wakewordId": null, "lang": null}
2021.04.09 14:46:19.652 5: Parsed value: schalte alle lichter wohnzimmer aus for key: input
2021.04.09 14:46:19.653 5: Parsed value: wohnzimmer for key: Room
2021.04.09 14:46:19.653 5: Parsed value: c089e860-cfd7-4b41-8cd7-309653c11e3d for key: sessionId
2021.04.09 14:46:19.653 5: Parsed value: aus for key: Value
2021.04.09 14:46:19.653 5: Parsed value: SetOnOffGroup for key: intent
2021.04.09 14:46:19.653 5: Parsed value: 1 for key: probability
2021.04.09 14:46:19.653 5: Parsed value: lichter for key: Group
2021.04.09 14:46:19.654 5: Parsed value: schalte alle lichter wohnzimmer aus for key: rawInput
2021.04.09 14:46:19.654 5: Parsed value: default for key: siteId
2021.04.09 14:46:19.654 5: handleIntentSetOnOffGroup called
2021.04.09 14:46:19.654 5: sorted devices list is:


Mache ich da etwas falsch?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 09 April 2021, 15:02:41
Zitat von: drhirn am 09 April 2021, 14:54:25
Mache ich da etwas falsch?
Nö, mein Fehler (im Zusammenhang mit dem Umbau von Array auf Komma-Liste). Bin froh, wenn es nur das ist ::) ...

Logik sollte m.E. invertiert sein:
next if $allgroups !~ m{\b$group\b}x;

Die InternalTimer-Geschichte mit 10 Sekunden sähe so aus (#523):
    if ($command eq 'update') {
        if ($values[0] eq 'language') {
            return initialize_Language($hash, $hash->{LANGUAGE});
        }
        if ($values[0] eq 'devicemap') {
            initialize_devicemap($hash);
            RHASSPY_updateSlots($hash);
            return InternalTimer(time + 10,\&RHASSPY_trainRhasspy,$hash,0);
        }
        if ($values[0] eq 'devicemap_only') {
            return initialize_devicemap($hash);
        }
        if ($values[0] eq 'slots') {
            RHASSPY_updateSlots($hash);
            return InternalTimer(time + 10,\&RHASSPY_trainRhasspy,$hash,0);
        }
        if ($values[0] eq 'slots_no_training') {
            initialize_devicemap($hash);
            return RHASSPY_updateSlots($hash);
        }
        if ($values[0] eq 'all') {
            initialize_Language($hash, $hash->{LANGUAGE});
            initialize_devicemap($hash);
            RHASSPY_updateSlots($hash);
            return InternalTimer(time + 10,\&RHASSPY_trainRhasspy,$hash,0);
        }
    }
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 09 April 2021, 15:22:15
Zitat von: Beta-User am 09 April 2021, 15:02:41
Logik sollte m.E. invertiert sein:

Perfekt, danke!


Bzgl. Timer: Das war, wie's scheint, ein Problem mit der demo.cfg. Rhasspy kann aus irgendeinem Grund mit dem Wort "AV" nichts anfangen. Zumindest meines nicht. Hat immer ein Fehler beim Training gegeben.
Ich hab das Delay daher wieder raus genommen und überlege mir gerade, ob es nicht trotzdem sinnvoll wäre. Notiere das als einen Punkt für später. Die fixen 10s sind nämlich auch irgendwie unschön.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 09 April 2021, 15:30:33
Muss ich bei SetOnOffGroup wirklich einen Raum angeben? Laut Code ja, aber warum? Was ist, wenn ich einfach alle Lampen im Haus ausschalten möchte?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 09 April 2021, 15:41:28
Zitat von: drhirn am 09 April 2021, 15:30:33
Muss ich bei SetOnOffGroup wirklich einen Raum angeben? Laut Code ja, aber warum? Was ist, wenn ich einfach alle Lampen im Haus ausschalten möchte?
Warum? Na ja, weil ich das so wollte... Unspezifisch "Immer alles" war mir ehrlich gesagt nach den ersten live-Tests mit Rhasspy noch zu "heiß" - Meine Musik war beim Testen zu oft weg ;D .

Daher habe ich diesen Raum "global" erfunden, der für "überall" versendet wird:
Zitat von: Beta-User am 31 März 2021, 12:19:05
Auf die Schnelle habe ich folgende sentences dazu zusammengeklöppelt:
[de.fhem:SetNumericGroup]
\[(schalt|mach|fahr)] (alle | sämtliche ) $de.fhem.Group{Group} [im] [( überall:global | $de.fhem.Room){Room}] [um] [(0..10){Value!int}] [dezibel{Unit}] (lauter|höher){Change:volUp}
\[(schalt|mach)] (alle | sämtliche ) $de.fhem.Group{Group} [im] [( überall:global | $de.fhem.Room){Room}] [um] [(0..10){Value!int}] [dezibel{Unit}] (leiser|niedriger){Change:volDown}
( mach | stelle ) (alle | sämtliche ) $de.fhem.Group{Group} [im] [( überall:global | $de.fhem.Room){Room}] [um] [(0..10){Value!int}] [grad{Unit}] (höher|wärmer){Change:tempUp}
( mach | stelle ) (alle | sämtliche ) $de.fhem.Group{Group} [im] [( überall:global | $de.fhem.Room){Room}] [um] [(0..10){Value!int}] [grad{Unit}] (niedriger|kälter){Change:tempDown}
( mach |schalt|schalte|stelle) (alle | sämtliche ) $de.fhem.Group{Group} [im] [( überall:global | $de.fhem.Room){Room}] [um] [(0..100){Value}] [prozent{Unit:percent}] (heller){Change:lightUp}
( mach |schalt|schalte|stelle) (alle | sämtliche ) $de.fhem.Group{Group} [im] [( überall:global | $de.fhem.Room){Room}] [um] [(0..100){Value}] [prozent{Unit:percent}] (dunkler){Change:lightDown}
(schalt | schalte | stelle ) (alle | sämtliche ) $de.fhem.Group{Group} [im] [( überall:global | $de.fhem.Room){Room}] auf (0..100){Value!float}
( mehr{Change:lightUp} | weniger{Change:lightDown} ) (alle | sämtliche ) $de.fhem.Group{Group} [im] [( überall:global | $de.fhem.Room){Room}]


Wir können aber gerne diskutieren, ob das sinnvoll ist.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 09 April 2021, 15:44:44
Achso, haha, das ist natürlich blöd ;D

Es stimmt schon, das ist riskant. Aber "schalte alle lichter überall aus" wird halt auch keiner sagen. Zumindest nicht freiwillig ;)
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 09 April 2021, 15:52:47
Na ja, man kann entweder die sentences ergänzen um
Zitatschalte überall das licht aus
- dann ist es natürlicher sprechbar - oder sich eben sonst was überlegen, wie man das haben will.

Im Moment fehlt mir einfach noch die praktische Erfahrung, wie man "praktikable" und gute Sätze baut, die dann eben auch im praktischen Leben nicht für unliebsame Ergebnisse sorgen. Daher eben auch das mit der "confirmation" usw.. Steckt alles noch etwas in den Kinderschuhen, aber sowas wie ein erster Pfad ist erkennbar.
Was sentences an sich angeht: Nach meinem bisherigen Eindruck ist länger = besser/trennschärfer, und das ganze wird wohl auch besser, wenn man mehr "keywords" im Einsatz hat. Deckt sich das mit euren Erfahrungen?

Da du grade mit beidem rumspielst: Wie sind die Eindrücke zu gDT und "Set...Group"?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 09 April 2021, 16:36:36
Zitat von: Beta-User am 09 April 2021, 15:52:47
Na ja, man kann entweder die sentences ergänzen um - dann ist es natürlicher sprechbar - oder sich eben sonst was überlegen, wie man das haben will.

Ich überlege...

ZitatWas sentences an sich angeht: Nach meinem bisherigen Eindruck ist länger = besser/trennschärfer, und das ganze wird wohl auch besser, wenn man mehr "keywords" im Einsatz hat. Deckt sich das mit euren Erfahrungen?

Ist eindeutig so. Rhasspy nimmt halt einen Intent, der ungefähr zum Satz passt. Je genauer die Sentences mit dem Gesprochenen übereinstimmen, desto korrektere Ergebnisse werden geliefert.
Deswegen muss man auch höllisch aufpassen, dass man nicht zu viel im Sentence optional macht. Sonst spricht man plötzlich einen Satz, der auf mehrere Intents passen könnte. Schon oft genug passiert.
Oder Rhasspy entscheidet sich für einen Intent, obwohl überhaupt nichts gesprochen wurde.

ZitatDa du grade mit beidem rumspielst: Wie sind die Eindrücke zu gDT und "Set...Group"?

Ich hab bisher bzgl. gDT nur mit "switch" und "light" gespielt. Und da nur ein/aus. Ist schon eine große Erleichterung, wenn man bei einem Device nur gDT und FHEM-Room braucht. Ich habe aber ein bisschen Angst vor Inkonsistenzen. Nicht so sehr, was das Modul betrifft, sondern eher den Saustall, den ich eh schon habe ;).

Meine Erkenntnisse zu Set..Group stehen schon hier. Hab bisher nur SetOnOffGroup getestet. Und das funktioniert ja jetzt soweit. Ich persönlich habe aber nicht viel Verwendung dafür.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 09 April 2021, 16:58:20
Wo passiert denn die ganze gDT-Magie im Code? Ich mein, wo wird entschieden, welche Fähigkeiten welcher gDT hat?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 09 April 2021, 16:59:20
@Beta-User
Licht aus - funktioniert mit lc.

"Licht im ganzen Haus aus" habe ich so gelöst:[de.fhem:SetAllOff]
(schließe|lösche) alle ((Lichter|Lampen){rType:light}|(Rollos){rType:blind}) ([im (Haus | $de.fhem.Room){rRoom}] | :Haus{rRoom})

"Lösche alle Lichter im Wohnzimmer" schaltet alle Lampen im WZ aus.
"Lösche alle Lichter" ohne Angabe vom Raumnamen, wird durch " :Haus{rRoom}" ergänzt. Hatte ich so erweitert, weil in der neuen Version keine undef-Parameter übergeben wurden.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 09 April 2021, 17:19:07
So geht's auch:
schalte alle $de.fhem.Group{Group} (:){Room:global}([$de.fhem.Room{Room}]) $OnOffValue{Value}
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 09 April 2021, 17:20:38
Zitat von: JensS am 09 April 2021, 16:59:20
@Beta-User
Licht aus - funktioniert mit lc.
Danke für die Rückmeldung! Dann haken wir diesen Teil also ab :) .

Zitat"Licht im ganzen Haus aus" habe ich so gelöst:[de.fhem:SetAllOff]
Das war eine wertvolle Anregung, auch für die Entwicklung dieses Gruppen-Dingens. Mir war es an zwei Stellen zu eng: Zum einen, weil ich (eventuell fälschlicherweise) davon ausgegangen war, dass Room eine eher größere Gruppe darstellen sollte und daher eine Zwischenstufe analog dem allgemeinen group für sinnvoll empfand und zum anderen, weil ich - wenn schon denn schon - dann auch gleich SetNumeric entsprechend umgesetzt haben wollte (triggernd und mit der Möglichkeit, ein async_delay einzubauen).

Und den Hinweis, dass man "leer" mit "global" übersetzen könnte, behalte (nicht nur) ich hoffentlich im Hinterkopf :) . (EDIT: das hat "jemand" aber schnell aufgegriffen...!)

Zitat von: drhirn am 09 April 2021, 16:36:36
Ist eindeutig so. Rhasspy nimmt halt einen Intent, der ungefähr zum Satz passt. Je genauer die Sentences mit dem Gesprochenen übereinstimmen, desto korrektere Ergebnisse werden geliefert.Deswegen muss man auch höllisch aufpassen, dass man nicht zu viel im Sentence optional macht. Sonst spricht man plötzlich einen Satz, der auf mehrere Intents passen könnte. Schon oft genug passiert.
Nachvollziehbar; bin auch am Überlegen, wie man da was verbessern kann.
Neben einer eventuell verbesserten Erkennung der Kombinationen in FHEM (da ist das aber uU. schon in den Brunnen gefallen...) kommt auf der Rhasspy-Seite in Frage:
- Reihenfolge der sentences bzw. intents (?)
- Verzicht auf Optionen
- Verwendung von speziellen Keywords (Bsp. "überall")
- Verwendung von mehr slots (eben nur alle Lichter für heller/dunkler, nicht pauschal alle FHEM-Devices)
- Einen möglichen Ansatzpunkt könnte auch "kind" liefern:{"entity": "de.fhem.Device", "value": {"kind": "Unknown", "value": "ct light"}, ...
Hat zufällig jemand einen Link, wo man sich dazu schlau machen kann?
Meine Hoffnung ist die, dass Rhasspy sehr viel mehr zu bieten hat als wir derzeit nutzen ;) ..
ZitatOder Rhasspy entscheidet sich für einen Intent, obwohl überhaupt nichts gesprochen wurde.
Bei mir meistens "nein", was dann nur zur Folge hat, dass keiner sich für eine Bestätigung zuständig fühlt...

ZitatIch hab bisher bzgl. gDT nur mit "switch" und "light" gespielt. Und da nur ein/aus. Ist schon eine große Erleichterung, wenn man bei einem Device nur gDT und FHEM-Room braucht. Ich habe aber ein bisschen Angst vor Inkonsistenzen. Nicht so sehr, was das Modul betrifft, sondern eher den Saustall, den ich eh schon habe ;) .
Nachvollziehbar.
M.E. beherrschbar, wenn man devspec nutzt, um erst mal mit wenigen Devices anzufangen. Bei mir derzeit: Zwei FHEM-Räume und einige wenige Einzeldevices.

ZitatMeine Erkenntnisse zu Set..Group stehen schon hier. Hab bisher nur SetOnOffGroup getestet. Und das funktioniert ja jetzt soweit. Ich persönlich habe aber nicht viel Verwendung dafür.
Auch nachvollziehbar, aber vermutlich eine Geschmacksfrage bzw. eine Frage dessen, was vorher schon da war. Ich habe z.B. praktisch alle structures irgendwann nicht mehr benötigt/genutzt und daher ausgebaut. Meine Beleuchtung in den zwei Räumen besteht aber aus diversen logischen Gruppen, und die lassen sich wunderbar zusammenfassen und mit Rhasspy steuern - das ist bisher die eleganteste Variante, die ich im Einsatz hatte :) .
Eventuell läßt sich das toppen, wenn man lightscene noch als gDT dazunimmt. Das ist aber was für V 0.6.0...

Zitat von: drhirn am 09 April 2021, 16:58:20
Wo passiert denn die ganze gDT-Magie im Code? Ich mein, wo wird entschieden, welche Fähigkeiten welcher gDT hat?
initialize_devicemap() =>     
for (@devices) {
        _analyze_genDevType($hash, $_) if $hash->{useGenericAttrs};
        _analyze_rhassypAttr($hash, $_);
    }

medias res ist also _analyze_rhassypAttr(), und dort ab "my $currentMapping"
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 09 April 2021, 17:50:41
Zitat von: Beta-User am 09 April 2021, 17:20:38
Zum einen, weil ich (eventuell fälschlicherweise) davon ausgegangen war, dass Room eine eher größere Gruppe darstellen sollte

Ist auch meine FHEM-Logik


ZitatNeben einer eventuell verbesserten Erkennung der Kombinationen in FHEM (da ist das aber uU. schon in den Brunnen gefallen...)

Naja, Rhasspy sollte schon mal den richtigen Intent liefern. Sonst können wir im Modul auch nicht viel machen.

Zitat
- Verwendung von mehr slots (eben nur alle Lichter für heller/dunkler, nicht pauschal alle FHEM-Devices)
- Einen möglichen Ansatzpunkt könnte auch "kind" liefern:{"entity": "de.fhem.Device", "value": {"kind": "Unknown", "value": "ct light"}, ...

Mehr Slots wäre eine Option.
Ich weiß jetzt auch nicht, wofür "kind" ist. Aber ich habe mal nachgefragt und werden dann berichten. Die Frage ist allerdings, ob man's überhaupt setzen kann.

ZitatBei mir meistens "nein", was dann nur zur Folge hat, dass keiner sich für eine Bestätigung zuständig fühlt...

Ja, bei mir auch. Das ist der de.fhem:ConfirmAction Intent. Ich weiß aber nicht, warum.

ZitatEventuell läßt sich das toppen, wenn man lightscene noch als gDT dazunimmt. Das ist aber was für V 0.6.0...

Fände ich ganz gut. Ich bilde meinen Lichtszene derzeit ja mit rhasspyChannels ab.
Interessanter wäre - und deswegen habe ich wegen gDT im Code gefragt - ein Typ "colorlight" oder so. Um die Farbe des Lichts setzen zu können.

Zitatmedias res ist also _analyze_rhassypAttr(), und dort ab "my $currentMapping"

Danke!
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 09 April 2021, 17:55:05
Zitat von: Beta-User am 09 April 2021, 17:20:38
Bei mir meistens "nein", was dann nur zur Folge hat, dass keiner sich für eine Bestätigung zuständig fühlt...

btw. da gibt's schon einen Thread dazu: https://community.rhasspy.org/t/unrecognized-commands-silence-incorrectly-return-intent/2270
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 09 April 2021, 17:59:40
@Beta-User
ZitatDann haken wir diesen Teil also ab :) .
Gern - Codebereinigung halte ich generell für vorrangiger.

SetAllOff hatte ich mal auf Wunsch eines Freundes geschrieben und als zweckmäßig empfunden. Da bin ich ganz bei Dir - es ist ein erster Ansatz um Gruppen zu definieren und anzusprechen.

Kind - kommt so von Rhasspy und ist wohl so gewollt. Wichtig sind ja die folgenden Werte. Eine Manpage habe ich nicht gefunden.
Hier ein paar Links:
https://github.com/rhasspy/rhasspy/issues/25 (https://github.com/rhasspy/rhasspy/issues/25)
https://forum.iobroker.net/topic/28411/rhasspy-offline-sprachsteuerung/192 (https://forum.iobroker.net/topic/28411/rhasspy-offline-sprachsteuerung/192)
EMPF-CODE:
{
"input": "schalte die wandspots ein",
"intent": { "intentName": "Lampen",
"confidenceScore": 1.0
},
"siteId": "volti",
"id": null,
"slots": [
{ //<--- slots[0]
"entity": "name",
"value": { //<---slots[0].value
"kind": "Unknown",
"value": "wandspots" //<------- = slots[0].value.value
},
"slotName": "name",
"rawValue": "wandspots",
"confidence": 1.0,
"range": {
"start": 12,
"end": 21,
"rawStart": 12,
"rawEnd": 21
}
},
{ //<--- slots[1]
"entity": "state",
"value": {  //<---slots[1].value
"kind": "Unknown",
"value": "ein" //<------- = slots[1].value.value
},
"slotName": "state",
"rawValue": "ein",
"confidence": 1.0,
"range": {
"start": 22,
"end": 25,
"rawStart": 22,
"rawEnd": 25
}
}
],
"sessionId": "volti-snowboy-36f74062-40c8-47eb-a05c-96d87fd476fb",
"customData": null,
"asrTokens": [
[
{
"value": "schalte",
"confidence": 1.0,
"rangeStart": 0,
"rangeEnd": 7,
"time": null
},
{
"value": "die",
"confidence": 1.0,
"rangeStart": 8,
"rangeEnd": 11,
"time": null
},
{
"value": "wandspots",
"confidence": 1.0,
"rangeStart": 12,
"rangeEnd": 21,
"time": null
},
{
"value": "ein",
"confidence": 1.0,
"rangeStart": 22,
"rangeEnd": 25,
"time": null
}
]
],
"asrConfidence": null,
"rawInput": "schalte die wandspots ein",
"wakewordId": "snowboy"
}
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Cordula am 09 April 2021, 18:05:24
Hab beim getNumeric noch ein Problem.

RHASSPY: [Rhasspy] Parse (IO: RhasspyMQTT2): Msg: hermes/intent/de.fhem_GetNumeric => {"input": "temperature im arbeitszimmer", "intent": {"intentName": "de.fhem:GetNumeric", "confidenceScore": 1.0}, "siteId": "arbeitszimmer", "id": null, "slots": [{"entity": "Type", "value": {"kind": "Unknown", "value": "temperature"}, "slotName": "Type", "rawValue": "wie ist die temperatur", "confidence": 1.0, "range": {"start": 0, "end": 11, "rawStart": 0, "rawEnd": 22}}, {"entity": "de.fhem.Room", "value": {"kind": "Unknown", "value": "arbeitszimmer"}, "slotName": "Room", "rawValue": "arbeitszimmer", "confidence": 1.0, "range": {"start": 15, "end": 28, "rawStart": 26, "rawEnd": 39}}], "sessionId": "arbeitszimmer-Okay Kalle-3117dfb0-43e9-4751-89b2-c2158e39da76", "customData": null, "asrTokens": [[{"value": "temperature", "confidence": 1.0, "rangeStart": 0, "rangeEnd": 11, "time": null}, {"value": "im", "confidence": 1.0, "rangeStart": 12, "rangeEnd": 14, "time": null}, {"value": "arbeitszimmer", "confidence": 1.0, "rangeStart": 15, "rangeEnd": 28, "time": null}]], "asrConfidence": null, "rawInput": "wie ist die temperatur im arbeitszimmer", "wakewordId": "Okay Kalle", "lang": null}
2021.04.09 17:22:59 5: Parsed value: temperature im arbeitszimmer for key: input
2021.04.09 17:22:59 5: Parsed value: temperature for key: Type
2021.04.09 17:22:59 5: Parsed value: GetNumeric for key: intent
2021.04.09 17:22:59 5: Parsed value: arbeitszimmer-Okay Kalle-3117dfb0-43e9-4751-89b2-c2158e39da76 for key: sessionId
2021.04.09 17:22:59 5: Parsed value: arbeitszimmer for key: Room
2021.04.09 17:22:59 5: Parsed value: wie ist die temperatur im arbeitszimmer for key: rawInput
2021.04.09 17:22:59 5: Parsed value: 1 for key: probability
2021.04.09 17:22:59 5: Parsed value: arbeitszimmer for key: siteId
2021.04.09 17:22:59 5: handleIntentGetNumeric called
2021.04.09 17:22:59 5: matches in room: Az.Heizung, matches outside: Bad.Heizung Sz.Heizung Gaestezimmer.Heizung Wetter.Temperatur Wz.Heizung Fritzbox_repeater Aussenstation Ebus
2021.04.09 17:22:59 5: Az.Heizung


Bei der Antwort holt er sich scheinbar aus der Config einen falschen Wert.

voiceResponse = temperature von arbeitszimmer beträgt 21,70 Grad Prozent

Die Gradangabe in der Antwort kommt von der Variablen. Die Prozent scheinbar aus der Config-Datei eventuell aus dem Eintrag:

"knownType": "$mappingType von $location beträgt $value Prozent",

Ein Eintrag für temperature ist vorhanden:

"temperature": {
        "0": "Die Temperatur von $location ist $value",
        "1": "Die Temperatur von $location beträgt $value Grad"
      },

Hab schon verschiedene Änderungen an der config gemacht, ohne Reaktion. Update Language habe ich gemacht.

Bei der Luftfeuchtigkeit habe ich keine Probleme.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 09 April 2021, 18:08:49
Wie sieht denn dein Mapping aus?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 09 April 2021, 18:13:59
Bei GetNumeric bin ich auch noch nicht glücklich über {Type:temperature} in sentences.ini.
Mal ist was in deutsch und groß geschrieben, mal klein und in englisch. Irgendwo müsste das eindeutig beschrieben sein. Da wären wir wieder beim Wiki-Artikel...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Cordula am 09 April 2021, 18:15:19
So:
attr Az.Heizung rhasspyMapping GetNumeric:currentVal=Temperatur,type=temperature
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 09 April 2021, 18:23:39
@Cordula: (ergänzend) Ist da eventuell eine CustomResponse im Spiel?
Sieht für mich so aus, als wäre es entweder das, oder das Reading ist ein anderes, müßte erforderlichenfalls in die Details gehen.

Bzgl. "kind"
Dass das gewollt ist, ist soweit klar; irgendwie müßte es aber möglich sein, Rhasspy mitzuteilen, welches "Ding" welcher "kind" ist, diffuse Vermutung: der JSON zur Bildung des slots müßte entsprechende zusätzliche Infos enthalten...
(Muß mal schauen, wie das intern abgespeichert wird).

Mit der "silence" muss ich auch mal sehen, interessant war aber auf die Schnelle das Stichwort "rebranded-the-matrix-voice-to-esp32-rhasspy-satellite"; einen ESP32 hätte ich ggf. für's Wohnzimmer übrig ;D ...

Zitat von: JensS am 09 April 2021, 18:13:59
Bei GetNumeric bin ich auch noch nicht glücklich über {Type:temperature} in sentences.ini.
Mal ist was in deutsch und groß geschrieben, mal klein und in englisch. Irgendwo müsste das eindeutig beschrieben sein. Da wären wir wieder beim Wiki-Artikel...
Die Regel ist eigentlich klar: die MQTT-Messages sollten im Ergebnis ALLE allgemeingültige (englische) Begriffe beinhalten, die eigentliche Sprache kommt dann erst wieder bei der Sprachausgabe zum Tragen. Alles dazwischen sollte (einheitlich) englisch sein.

Von daher ist es uU. das Mapping, das hier Probleme macht und (irgendwie) umgestellt werden müßte. Es kann aber sein, dass der Readingname da aus irgendeinem Grund nicht sauber übernommen wird. Bin an der Stelle auch noch unschlüssig, wie man das lösen kann.
Wie wird das denn in den Hash übernommen, und heißt das abzugreifende Reading wirklich Temperatur?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Cordula am 09 April 2021, 18:33:56
Problem gelöst. Ich habe die Gradangabe in der Variablen entfernt (also statt : 21,6 Grad nur noch 21,6). Jetzt funktionierts. Scheinbar gibts da ein Problem, wenn Textzusätze in der Variablen stehen.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 09 April 2021, 19:24:16
Zitat von: Cordula am 09 April 2021, 18:33:56
Problem gelöst. Ich habe die Gradangabe in der Variablen entfernt (also statt : 21,6 Grad nur noch 21,6). Jetzt funktionierts. Scheinbar gibts da ein Problem, wenn Textzusätze in der Variablen stehen.

Da gab's mal part für's Mapping: https://github.com/Thyraz/Snips-Fhem#getnumeric
Ist noch im Code, aber ich weiß gerade nicht, ob's funktioniert. Probier's einfach.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 09 April 2021, 22:36:07
@drhirn
Wie lauten die offiziellen Übersetzungen für Helligkeit, Temperatur, Sollwert, Lautstärke, Luftfeuchtigkeit, Batterie, Wasserstand? Gilt die englische Kleinscheibung auch für {device}, {room}, {value}, {etc.}?
Mit https://github.com/drhirn/fhem-rhasspy/blob/0.4.7b/README.md (https://github.com/drhirn/fhem-rhasspy/blob/0.4.7b/README.md) kann ich leider meine sentences.ini und mappings nicht umstellen.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Cordula am 09 April 2021, 22:58:34
Ich denke, da stimmt die Antwort noch nicht ganz.

RHASSPY: [Rhasspy] Parse (IO: RhasspyMQTT2): Msg: hermes/intent/de.fhem_GetNumeric => {"input": "wie ist die airHumidity im küche", "intent": {"intentName": "de.fhem:GetNumeric", "confidenceScore": 1.0}, "siteId": "arbeitszimmer", "id": null, "slots": [{"entity": "Type", "value": {"kind": "Unknown", "value": "airHumidity"}, "slotName": "Type", "rawValue": "luftfeuchtigkeit", "confidence": 1.0, "range": {"start": 12, "end": 23, "rawStart": 12, "rawEnd": 28}}, {"entity": "de.fhem.Room", "value": {"kind": "Unknown", "value": "küche"}, "slotName": "Room", "rawValue": "küche", "confidence": 1.0, "range": {"start": 27, "end": 32, "rawStart": 32, "rawEnd": 37}}], "sessionId": "arbeitszimmer-Okay Kalle-0eb668f5-8860-402b-8872-bda42c3651ae", "customData": null, "asrTokens": [[{"value": "wie", "confidence": 1.0, "rangeStart": 0, "rangeEnd": 3, "time": null}, {"value": "ist", "confidence": 1.0, "rangeStart": 4, "rangeEnd": 7, "time": null}, {"value": "die", "confidence": 1.0, "rangeStart": 8, "rangeEnd": 11, "time": null}, {"value": "airHumidity", "confidence": 1.0, "rangeStart": 12, "rangeEnd": 23, "time": null}, {"value": "im", "confidence": 1.0, "rangeStart": 24, "rangeEnd": 26, "time": null}, {"value": "küche", "confidence": 1.0, "rangeStart": 27, "rangeEnd": 32, "time": null}]], "asrConfidence": null, "rawInput": "wie ist die luftfeuchtigkeit im küche", "wakewordId": "Okay Kalle", "lang": null}
2021.04.09 22:46:56 5: Parsed value: arbeitszimmer for key: siteId
2021.04.09 22:46:56 5: Parsed value: 1 for key: probability
2021.04.09 22:46:56 5: Parsed value: wie ist die luftfeuchtigkeit im küche for key: rawInput
2021.04.09 22:46:56 5: Parsed value: küche for key: Room
2021.04.09 22:46:56 5: Parsed value: arbeitszimmer-Okay Kalle-0eb668f5-8860-402b-8872-bda42c3651ae for key: sessionId
2021.04.09 22:46:56 5: Parsed value: GetNumeric for key: intent
2021.04.09 22:46:56 5: Parsed value: airHumidity for key: Type
2021.04.09 22:46:56 5: Parsed value: wie ist die airHumidity im küche for key: input
2021.04.09 22:46:56 5: handleIntentGetNumeric called
2021.04.09 22:46:56 5: matches in room: , matches outside: Gaestezimmer.Feuchtigkeit Flur.Feuchtigkeit Bad.Feuchtigkeit Sz.Feuchtigkeit Az.Feuchtigkeit Wz.Feuchtigkeit
2021.04.09 22:46:56 5: Gaestezimmer.Feuchtigkeit


Antwort: Die Luftfeuchtigkeit von gaestezimmer beträgt 39,62 Prozent

In der Küche gibt es aber keinen Luftfeuchtigkeitssensor. Matches outside sind keine wirklichen Treffer.

Meiner Meinung nach sollte die Antwort etwa so lauten:

Ich kann keine Luftfeuchtigkeit in der Küche feststellen oder eine allgemeinere Fehlermeldung.

Was meint ihr dazu?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Cordula am 09 April 2021, 23:19:42
@drhirn
part=1 funktioniert nicht, Es wird nicht die Zahl geholt, sondern der Zusatz. Damit findet er dann wieder nicht die richtige Antwort. Ist aber kein Problem. Über ein entsprechendes Attribut userreadings hab ich mir ein passendes reading erzeugt. Damit geht's.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 10 April 2021, 06:45:37
Puh, jetzt sind ja viele Fragen im Raum...

Vorab mal zu "part" und allgemeinen mapping-Fragen:
- die Grundstruktur der Mappings folgt (zumindest einstweilen) weiter der alten Logik und bildet die von der (alten) Funktion zurückgegebene Hash-Struktur eben in dem Gesamthash direkt ab, die gDT-Geschichte versucht "nur", passende Einstellungen für "unbekannte Geräte" zu erraten, indem z.B. das Vorhandensein bestimmter setter geprüft wird.
- Daher sollte v.a. auch part weiter funktionieren, allerdings wäre der erste Teil vermutlich "0", nicht "1";

Zum gDT-Thema:
- In das Attribut sollten nur Werte geschrieben werden, die "allgemeingültig" sind, ein farbiges Licht ist in dieser Logik m.E. auch weiter "light", eine LightScene sollte "scene" sein;
Allgemeingültig meint: das Schlüsselwort kennen auch die anderen Sprachsteuerungslösungen.
- Für Farbe und Farbtemperatur ist mir noch nichts gescheites eingefallen, stand bisher nicht auf meiner persönlichen Prio-Liste. Der bisherigen Logik folgend müßte man das auch "RHASSPY"-konform in einen auswertbaren (Teil-) Hash packen. Neben vielem anderen ist da aber das Problem, dass es für CT z.B. keine normierten Werte gibt, ebenso ist HUE mWn. auch nicht wirklich standardisiert, rgb müsste nach rhasspyColor...
Das sind ziemlich viele Details, die man da kennen und beachten muß, daher wäre es uU. gut, wenn wir jemanden im Boot hätten, der mehr Erfahrung damit hat (z.B. justme1968 wäre super), damit man ggf. bereits bekannte Eckdaten aus homeBridgeMapping berücksichtigen könnte. Würde den Teil daher perspektivisch erst nach dem 29.04. angehen
- "scene" und speziell LightScene sind sicher interessant. Da wäre es super, wenn sich jemand das mal ansehen würde, der mit der bisherigen "Szenenfunktionalität" von RHASSPY etwas besser vertraut ist. Es gibt in den heutigen Beispielen zu "light" schon Varianten, die TYPE berücksichtigen, das ganze könnte man also so lösen, dass gDT "scene" vergeben wird, und dann ein ganzer Unterzweig sich vorab mit LightScene befasst und nur "der unbekannte Rest" mit irgendwelchen defaults (welchen...?) vorbelegt wird (oder eben gar nicht).

"Englisch" und Kleinschreibung
Vorab mal sorry, dass ich scheinbar die Frage hinter der Frage nicht verstanden hatte...
- Bekannt sind die "Type", die im Hashbereich "Change" hinterlegt sind, also:
temperature, brightness, airHumidity, soilMoisture, volume, waterLevel, battery, setTarget, knownType, unknownType
(sorry, dass es da auch nicht einheitlich klein oder groß ist).
Die sollten eigentlich auch aus der "alten Welt" direkt übersetzt werden, wenn sie im mapping stehen. Das Problem sind hier (vermutlich) nur die Anfragen aus sentences.ini.
- Die "Label" für die Kategorien sind unverändert. Da finde (und fand) ich die "technische Kennzeichnung" mit einem Großbuchstaben zum Start eine gute Sache. So sieht man gleich, dass es sich um was spezielles handelt.
Insbesondere {Device} und {Type} sind also in sentences.ini weiter korrekt;

- "unknownType" ist dabei eigentlich keine wirkliche Übersetzung, sondern (hoffentlich) halt eine Auffangkategorie für alles, was nicht in die vorherige Liste paßt. An der Stelle eine Warnung: mir ist im Moment unklar was passiert, wenn man eine "ungültige" Anfrage stellt, also z.B. nach einem Widerstand. Wer im Moment sowas macht, begibt sich evtl. auf gefahrgeneigtes Terrain, kann sein, dass man da was besser absichern muss;

Zu "matches outside"
Zitat von: Cordula am 09 April 2021, 22:58:34
Ich denke, da stimmt die Antwort noch nicht ganz.

[...] Meiner Meinung nach sollte die Antwort etwa so lauten:

Ich kann keine Luftfeuchtigkeit in der Küche feststellen oder eine allgemeinere Fehlermeldung.

Was meint ihr dazu?
...vorab bin ich ja froh, dass nicht nur ich das Problem habe...
Die jetzige Lösung legt immerhin schon mal offen, dass da ein Problem besteht, indem wenigstens der korrekte Raum angesagt wird.
Meine persönliche Vorstellung wäre:
1. Schritt: Andere Ansage - "Für die Küche kenne ich den Wert nicht, im Arbeitszimmer ..." (das sollte relativ einfach umzusetzen sein)
2. Schritt:
-- Gibt es nur einen passenden Wert "outside" => Ansage wie Schritt 1;
-- Gibt es mehrere: Abfrage, welchen (mit Abbruchmöglichkeit oder Timeout
Das würde ich auch auf "für später" auf die todo-Liste nehmen, denn es gibt dazu einen "kleinen Bruder", wie bereits angemerkt: mehrere Sensoren im Raum. Diese Variante finde ich persönlich dringlicher zu lösen, denn da kommen im Moment noch "falsche" Ergebnisse, wenn man z.B. "thermostat"-gDT-Geräte hat.

Hoffe, damit erst mal die gröbsten Unklarheiten erläutert zu haben, bitte melden, wenn ich was übersehen haben sollte.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 10 April 2021, 07:32:55
Jössas Maria, ihr brauch aber wenig Schlaf ;D

Ich gebe zu, dass keine Doku derzeit brauchbar ist. Ich komme einfach nicht hinterher. Und meine Auszeit vor kurzem in der ihr fleissig weiter entwickelt habt, hat das nicht besser gemacht. Da ich nur dokumentiere, was ich vorher getestet habe, ist das alles sehr, sehr viel Aufwand. Unter anderem, weil's halt derzeit so ist, dass eine Doku nicht lange Bestand hat ;).

Deswegen bin ich auch gegen eine Wiki-Seite. Ich kann ich nicht noch um eine dritte Doku kümmern. Und ich fände es auch nicht gut, wenn plötzlich Wiki - CRef - README total auseinanderlaufen.

Es ist jetzt aber auch nicht so, dass das alles an mir hängen bleiben muss. Das Modul und die Doku sind bewusst auf GitHub. Es kann somit jeder mitarbeiten, der das möchte. Würde mich sogar freuen!
Ihr könnt mir auch gerne einfach Sachen hier ins Forum stellen, die ich dann einbaue.

Das Modul ist unglaublich mächtig geworden. Und teilweise extrem komplex (SetNumeric z.B.). Ich muss da selber erst mal alle Möglichkeiten entdecken. Das braucht Zeit. Ich verspreche aber, dass die Doku bis spätestens 29.04. zumindest alles Wichtige richtig beinhaltet.

Und wie gesagt, Hilfe ist herzlich willkommen! Ihr könntet mir z.B. mal erzählen, was der Timer jetzt so alles kann (incl. Sentences). Das Thema hab ich nämlich leider vollkommen verpasst.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 10 April 2021, 08:02:56
Na ja, "das meiste" sollte eigentlich funktionieren wie gehabt, und bis auf den berechtigten Hinweis von JensS auf die Kategorien ist auch das meiste mAn. in der cref aktuell.
Was da fehlt, ist eine Beschreibung der am Ende gelisteten intents samt passender sentences-Beispiele.

Ich habe aber v.a. bzgl. der sentences.ini und intents ähnliche Probleme hinsichtlich Doku, nicht alles ist getestet oder optimiert, sondern ich habe zu einem großen Teil auch einfach erst mal kopiert, was da war, und die Frage steht weiter im Raum, ob man nicht manches dann noch auf der Rhasspy-Seite besser verstehen könnte.

Unter Vorbehalt daher hier mal mein kompletter aktueller Stand der sentences.ini:
[de.fhem:SetNumeric]
\[(schalt|mach)] $de.fhem.Device{Device} [um] [(0..10){Value!int}] [dezibel{Unit}] (lauter|höher){Change:volUp}
\[(schalt|mach)] $de.fhem.Device{Device} [um] [(0..10){Value!int}] [dezibel{Unit}] (leiser|niedriger){Change:volDown}
( mach | stelle ) $de.fhem.Device{Device} [um] [(0..10){Value!int}] [grad{Unit}] (höher|wärmer){Change:tempUp}
( mach | stelle ) $de.fhem.Device{Device} [um] [(0..10){Value!int}] [grad{Unit}] (niedriger|kälter){Change:tempDown}
( mach |schalt|schalte|stelle) $de.fhem.Device{Device} [um] [(0..100){Value}] [prozent{Unit:percent}] (heller){Change:lightUp}
( mach |schalt|schalte|stelle) $de.fhem.Device{Device} [um] [(0..100){Value}] [prozent{Unit:percent}] (dunkler){Change:lightDown}
(schalt | schalte | stelle ) $de.fhem.Device{Device} auf (0..100){Value!float}
( mehr{Change:lightUp} | weniger{Change:lightDown} ) $de.fhem.Device{Device} [$de.fhem.Room{Room}]

[de.fhem:SetNumericGroup]
\[(schalt|mach|fahr)] (alle | sämtliche ) $de.fhem.Group{Group} [im] [( überall:global | $de.fhem.Room){Room}] [um]  [(0..10){Value!int}] [dezibel{Unit}] (lauter|höher){Change:volUp}
\[(schalt|mach)] (alle | sämtliche ) $de.fhem.Group{Group} [im] [( überall:global | $de.fhem.Room){Room}] [um] [(0..10){Value!int}] [dezibel{Unit}] (leiser|niedriger){Change:volDown}
( mach | stelle ) (alle | sämtliche ) $de.fhem.Group{Group} [im] [( überall:global | $de.fhem.Room){Room}] [um] [(0..10){Value!int}] [grad{Unit}] (höher|wärmer){Change:tempUp}
( mach | stelle ) (alle | sämtliche ) $de.fhem.Group{Group} [im] [( überall:global | $de.fhem.Room){Room}] [um] [(0..10){Value!int}] [grad{Unit}] (niedriger|kälter){Change:tempDown}
( mach |schalt|schalte|stelle) (alle | sämtliche ) $de.fhem.Group{Group} [im] [( überall:global | $de.fhem.Room){Room}] [um] [(0..100){Value}] [prozent{Unit:percent}] (heller){Change:lightUp}
( mach |schalt|schalte|stelle) (alle | sämtliche ) $de.fhem.Group{Group} [im] [( überall:global | $de.fhem.Room){Room}] [um] [(0..100){Value}] [prozent{Unit:percent}] (dunkler){Change:lightDown}
(schalt | schalte | stelle ) (alle | sämtliche ) $de.fhem.Group{Group} [im] [( überall:global | $de.fhem.Room){Room}] auf (0..100){Value!float}
( mehr{Change:lightUp} | weniger{Change:lightDown} ) (alle | sämtliche ) $de.fhem.Group{Group} [im] [( überall:global | $de.fhem.Room){Room}]


[de.fhem:MediaControls]
(starte|start){Command:cmdPlay} [die wiedergabe] [$de.fhem.Device{Device}][im] [$de.fhem.Room{Room}]
(stoppe|stop){Command:cmdStop} [die wiedergabe] [$de.fhem.Device{Device}] [im][$de.fhem.Room{Room}]
(pausiere){Command:cmdPause} [die wiedergabe] [$de.fhem.Device{Device}][im] [$de.fhem.Room{Room}]
(nächstes|nächster){Command:cmdFwd} (lied|titel) [$de.fhem.Device{Device}] [im][$de.fhem.Room{Room}]
(vorheriges|voriges|vorheriger|voriger){Command:cmdBack} (lied|titel) [$de.fhem.Device{Device}][im] [$de.fhem.Room{Room}]

[de.fhem:GetWeekday]
\[bitte] weißt du [bitte] welcher Tag heute ist [bitte]
\[bitte] kannst du mir [bitte] sagen welcher Tag heute ist [bitte]
\[bitte] könntest du mir [bitte] sagen welcher Tag heute ist [bitte]
\[bitte] kannst du mir [bitte] den [heutigen] Tag sagen [bitte]
welcher [wochentag|tag] ist heute [bitte]
welchen [wochentag|tag] haben wir heute [bitte]

[de.fhem:GetTime]
wie spät [ist es]
sag mir die uhrzeit
wie schpät [isch es]

[de.fhem:GetNumeric]
( warm | kalt | heiß | Temperatur ){Type:temperature} [ist es | von | vom | ist ] ([(im|auf dem)]($de.fhem.Room){Room}|[das]($de.fhem.Device){Device})
(wie laut | Lautstärke){Type:volume} [ist es | von | vom | ist ] ([(im|auf dem)]($de.fhem.Room){Room}|[das]($de.fhem.Device){Device})

[de.fhem:SetTimer]
labels=( Wecker | Eier | Kartoffeln | Tee )
( Lösche | entferne ){Cancel} [den] ( timer | wecker ) [<labels>{label}]
( timer | wecker ) [<labels>{label}] auf [((1..60){hour} (stunde|stunden) | (1..24){hourabs} (uhr) )] [und] [((1..60){min})]
( timer | wecker ) [<labels>{label}] auf [((1..60){hour} (stunde|stunden) | (1..24){hourabs} (uhr) )] [und] [((1..60){min} (minute|minuten))] [und] [((1..60){sec} (sekunde|sekunden))]
( timer | wecker ) [<labels>{label}] auf (1..60){hour} (einviertel{min:15}|einhalb{min:30}|dreiviertel{min:45}) (stunde|stunden)
( timer | wecker ) [<labels>{label}] auf (1..60){min} (einviertel{sec:15}|einhalb{sec:30}|dreiviertel{sec:45}) (minute|minuten)

[de.fhem:ReSpeak]
was hast du gesagt

[de.fhem:SetMute]
(gute nacht){Value:on}
(guten morgen){Value:off}

[de.fhem:Shortcuts]
motor aus
auto an
motor an
ton aus
auto aus
ton an
du bisch cool

[de.fhem:ConfirmAction]
(ja mach | tu es | ist ok ){Mode:OK}
(lass es | nein | abbrechen | abbruch ){Mode}

[de.fhem:GetOnOff]
ist [der|die|das] $de.fhem.Device{Device} [$de.fhem.Room{Room}] (an|ein){Status}
(läuft){Status} $de.fhem.Device{Device} [$de.fhem.Room{Room}]

[de.fhem:Status]
wie ist der status{Status} $de.fhem.Device{Device} [(im|in der|auf der|draußen|auf dem)] [$de.fhem.Room{Room}]

[de.fhem:GetOnOff]
ist [der|die|das] $de.fhem.Device{Device} [$de.fhem.Room{Room}] $OnOffValue{Status}
(läuft){Status} $de.fhem.Device{Device} [$de.fhem.Room{Room}]

[de.fhem:SetOnOff]
\[(schalt|mach|fahr)] [den|die|das] $de.fhem.Device{Device} [$de.fhem.Room{Room}] $OnOffValue{Value}

[de.fhem:SetOnOffGroup]
\[(schalt|mach|fahr)] (alle | sämtliche ) $de.fhem.Group{Group} [im] [( überall:global | $de.fhem.Room){Room}] $OnOffValue{Value}

und der Slot "OnOffValue"
off
aus:off
zu:off
on
auf:on
an:on


Vorschlag zur Vorgehensweise wäre, das (gekürzt?) in die cref zu übernehmen und dann kenntlich zu machen, was getestet ist und was nicht (ggf. der ungetestete Teil einfach hinten dranpappen? Und bei den intents dann die getestete Variante?).
Feedback bzw. Rückmeldung von Usern zu einzelnen Teilen ist willkommen, und falls jemand weiß, wie bzw. ob man die sentences.ini irgendwie optimieren kann bzgl. der Reihenfolge der Einzelteile oder innerhalb eines intents: her damit...!

Anders gesagt: Man muss es nicht mögen, aber (englische) cref hat (entsprechend der in FHEM geltenden Konventionen) Prio vor allem anderen. Heißt aber mAn. nicht, dass die sentences englisch sein müßten, die sind ja "fast selbsterklärend" bzw. auch woanders gut dokumentiert; hier geht es nur darum zu zeigen, was FHEM eigentlich derzeit versteht.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 10 April 2021, 08:09:41
Die Doku wird seeeeehr lang. Deswegen möchte ich das alles eigentlich nicht in der CRef haben. Die ist unübersichtlich und schlecht zu handhaben. Finde ich. Und schnell mal etwas ausbessern geht auch nur schwer, sollte das Modul mal ins SVN wandern.

Und alles Rhasspy-spezifische (Sentences, etc.) gehört eigentlich nicht in die CRef.

Mein Plan von Anfang an war:

CRef: Kurze Beschreibung, DEF+SET+ATTR+wichtige Hinweise+kurzes Beispiel
GitHub: Wie CRef + genaue Erklärung + Beispiele
(Wiki: mehr Beispiele + Tipps&Tricks)
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 10 April 2021, 08:19:01
Wie wär's, wenn wir gemeinsam mal die Intents der Reihe nach durchgehen und hier unsere Erkenntnisse sammeln? Angefangen von der Definition des/der Devices, über Sentences und Testergebnisse?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 10 April 2021, 09:21:41
Ich fange mal an. Mit SetOnOff. Das war leicht  ;)
Sentences bitte ergänzen, falls da noch jemand weitere Ideen hat.

https://forum.fhem.de/index.php/topic,113180.msg1147622.html#msg1147622
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 10 April 2021, 09:42:37
Na dass ist doch schon mal ein praktikabler Anfang.  :)
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Cordula am 10 April 2021, 09:45:48
@Beta-User
Mit part=0 funktionierts.

Zum Thema Klein/Großschreibung habe ich inzwischen alles also rhasspyName und rhasspyRoom einheitlich auf Kleinschreibung umgestellt. Ebenso meine Einträge in den Slots und in der sentences.ini. Umlaute habe ich drin gelassen. Damit funktionierts, nachdem ich vorher diverse Probleme damit hatte. Oder wird hier inzwischen alles abgefangen?

Zum Thema SetOnOff:

Verwendest du keine rhasspyName,RhasspyMapping und rhasspyRoom ?
Beispiel für verändertes rhassspyMapping mit Antwort:
SetOnOff:cmdOn=Schalten on,cmdOff=Schalten off,response={ResponseOnOff($DEVICE)}
Anmerkung dazu: bei manchen Geräten ist die Antwort über den Status falsch, da sie zu langsam den Status ändern (z.B. mein 3D-Drucker)

Beispiel für Slots in der sentences.ini
\[($Aktion)] [(den|die|das)] ($de.fhem.Device){Device} [(im |in der)] [($de.fhem.Room){Room}] ($onoffvalue){Value}   

$Aktion

machs
mache
stells
schalt
stell
schalte
mach
fahre
stelle
fahr


$onoffvalue

(an|ein|aktiv|hoch|offen|auf):an
(aus|ab|deaktiv|runter|rein|zu):aus


Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 10 April 2021, 09:49:28
Zitat von: Cordula am 10 April 2021, 09:45:48
Verwendest du keine rhasspyName,RhasspyMapping und rhasspyRoom ?

Doch, normal schon. Das ist halt ein Beispiel mit genericDeviceType. Muss auch auch wer testen ;).

Die Slots hab ich in meiner produktiven Umgebung auch. Aber ich denke mir, um die Funktionsweise zu veranschaulichen, ist es ohne zusätzliche Slots einfacher. Das ist v.a. ein Rhasspy-Thema, das mit dem Modul eigentlich nichts zu tun hat.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 10 April 2021, 09:59:22
SetOnOffGroup:

https://forum.fhem.de/index.php/topic,113180.msg1147624.html#msg1147624
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Cordula am 10 April 2021, 10:05:29
Beim Thema genericDeviceType sollte noch ergänzt werden, welche hier unterstützt werden. Ich gehe davon aus, dass nicht alle in der Auswahl unterstützt werden.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 10 April 2021, 10:07:30
ZitatVerwendest du keine rhasspyName,RhasspyMapping und rhasspyRoom ?
Vorab: bin erst am Einarbeiten in das Thema, ist noch unvollständig...

Name: zum großen Teil: ja
Mapping: fast alles derzeit über gDT
Room: ja, aber das meiste über rhasspyGroups

Groß/Kleinschreibung und $mutated_vovels sollten über gewisse Automatiken zwischenzeitlich weitgehend abgefangen werden und daher einige Probleme aus der Vergangenheit "Vergangenheit" sein. Kann aber nicht garantieren, bereits alles "erwischt" zu haben.
An sich sollte aber Groß/Kleinschreibung bei "aliasen", Gruppen und Räumen zwischenzeitlich keine Probleme mehr machen.


Generell fände ich es für künftige Leser einfacher, wenn die sentences-Geschichte und Tips&Tricks dazu in einem separaten Thread gebündelt würden. Hier geht ggf. sonst auch was anderes dazwischen unter?


Was Doku angeht:
Die Dreiteilung finde ich schwierig zu pflegen, und die (ungeschriebenen) Mindeststandards an cref sind eigentlich, dass man das Modul damit sinnvoll in Betrieb nehmen kann. Ergo gehört da eine kurze Beschreibung der vorhandenen intents ebenso rein wie mind. ein Beispielsatz.

Weniger Skrupel habe ich übrigens, was ggf. deswegen erforderliche häufigere commits ins svn angeht: Ist halt so, gewöhnt man sich dran und ist auch schnell gemacht (ich find's einfacher als github-commandline).
Kann dich gerne da etwas coachen und mime auch übergangsweise ggf. den 2. Maintainer; generell fände ich es langsam an der Zeit, das nach contrib einzuchecken (nächstes WE?). Dann wird es nämlich einfacher, die Dateien (und ggf. updates) in die eigene Installation zu holen.
(feedback auch zum Thema svn v.a. von unseren Testern und stillen Mitlesern hier wäre willkommen)
ZitatSobald rhasspyName definiert ist muss auch rhasspyRoom angegeben werden, weil dann der FHEM-room ignoriert wird. Ist das richtig?
Bitte prüfen. Gedacht ist es anders: Wenn rhasspyName angegeben ist, verdrängt das alle anderen Namen, wenn rhasspyRoom angegeben ist, dann wird das statt der allgemeinen rooms verwendet.

Zitat von: Cordula am 10 April 2021, 10:05:29
Beim Thema genericDeviceType sollte noch ergänzt werden, welche hier unterstützt werden. Ich gehe davon aus, dass nicht alle in der Auswahl unterstützt werden.
Welche Auswahl?
Falls es die Liste aus der cref ist: eigentlich schon, es kann aber sein, dass erforderliche Setter nicht identifiziert werden können und daher dann kein mapping erstellt werden kann.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 10 April 2021, 10:16:36
Zitat von: Cordula am 10 April 2021, 10:05:29
Beim Thema genericDeviceType sollte noch ergänzt werden, welche hier unterstützt werden. Ich gehe davon aus, dass nicht alle in der Auswahl unterstützt werden.

Habe ich auch schon mal gefragt ;D
https://forum.fhem.de/index.php/topic,119447.msg1147238.html#msg1147238

Es sind:
* switch
* light
* thermostat
* blind
* media

@Beta-User: Hat man z.B. schon ein alexa-fhem, ist das gDT schon da. Da gibt's dann eine Auswahlliste. Siehe Screenshot.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 10 April 2021, 10:21:34
*window wäre auch ganz nett für "Sind alle Fenster geschlossen?".

Zitat von: Cordula am 10 April 2021, 09:45:48
SetOnOff:cmdOn=Schalten on,cmdOff=Schalten off,response={ResponseOnOff($DEVICE)}
Anmerkung dazu: bei manchen Geräten ist die Antwort über den Status falsch, da sie zu langsam den Status ändern (z.B. mein 3D-Drucker)
ResponseOnOff fragt den aktuellen Status ab. Eventuell wäre es besser, den gewollten Status zu verwenden. Dazu hatte ich mal was auf die Schnelle geschrieben:SetOnOff:cmdOn={fhem("set $DEVICE on;setreading $DEVICE rhasspySTATE an")},cmdOff={fhem("set $DEVICE off;setreading $DEVICE rhasspySTATE aus")},response={my $Name = (split(/,/,AttrVal($DEVICE,"rhasspyName","error")))[0];my $Status = ReadingsVal($DEVICE,"rhasspySTATE","im unbekannten Status");return "Ok - $Name ist $Status"}

Keine Ahnung, ob das jetzt noch richtig ist.

Zitat von: Cordula am 10 April 2021, 09:45:48
(an|ein|aktiv|hoch|offen|auf):an
(aus|ab|deaktiv|runter|rein|zu):aus
Hatte ich so verstanden, dass nach der neuen Definition :on bzw. :off verwendet werden soll.

Gruß Jens
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 10 April 2021, 10:25:34
Zitat von: Beta-User am 10 April 2021, 10:07:30
Generell fände ich es für künftige Leser einfacher, wenn die sentences-Geschichte und Tips&Tricks dazu in einem separaten Thread gebündelt würden. Hier geht ggf. sonst auch was anderes dazwischen unter?

Ja, wahrscheinlich. Ich hab allerdings aber auch Angst, dass dann wichtige Informationen auf zwei Threads verteilt sind.

Zitat von: Beta-User am 10 April 2021, 10:07:30
Die Dreiteilung finde ich schwierig zu pflegen, und die (ungeschriebenen) Mindeststandards an cref sind eigentlich, dass man das Modul damit sinnvoll in Betrieb nehmen kann. Ergo gehört da eine kurze Beschreibung der vorhandenen intents ebenso rein wie mind. ein Beispielsatz.

Ok. Aber wirklich nur kurz.

Zitat von: Beta-User am 10 April 2021, 10:07:30
Weniger Skrupel habe ich übrigens, was ggf. deswegen erforderliche häufigere commits ins svn angeht: Ist halt so, gewöhnt man sich dran und ist auch schnell gemacht (ich find's einfacher als github-commandline).
Kann dich gerne da etwas coachen und mime auch übergangsweise ggf. den 2. Maintainer; generell fände ich es langsam an der Zeit, das nach contrib einzuchecken (nächstes WE?). Dann wird es nämlich einfacher, die Dateien (und ggf. updates) in die eigene Installation zu holen.
(feedback auch zum Thema svn v.a. von unseren Testern und stillen Mitlesern hier wäre willkommen)

Nun, ich bin ja eher zur GitHub-Fraktion zugehörig. Finde ich nämlich einfacher als SVN ;).
Ich hab mir das Repo nach /opt/fhem/FHEM geklont und hab mit einem git pull (und ev. git switch <branch> bzw. git checkout <branch>) sehr einfach die aktuellste Version.
Nach contrib möchte ich erst, nachdem die Doku vollständig und alles getestet ist. Sonst ist mir das zu peinlich ;D
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 10 April 2021, 10:44:17
Zitat von: drhirn am 10 April 2021, 09:21:41
Bei SetNumeric hamma bei FS20 aber ein Problem. Die werden mit dim06%, dim12%, etc. gedimmt. Eher blöd :(
Wieder ein paar Anmerkungen:
- Nachträgliche Edits gehen gerne unter; hoffe, du führst anderweitig eine Liste
- gDT ist eine Art "best guess". Exoten oder Oldtimer kann es im Moment nicht, und ich bin auch unsicher, ob man das integrieren sollte. Wer "sowas" hat, "muss" es halt zu Fuß machen...
- gDT ist eine Art "best guess". Daher sind ggf. im Moment (z.B. bei "media") Dinge drin, die das Gerät ggf. nicht kann. Ggf. können wir das ausbauen, um z.B. nur wirklich vorhandene setter auch zu mappen.
Das Ganze ist im Moment eher eine (überraschend gut funktionierende) Machbarkeitsstudie :) .
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 10 April 2021, 10:49:14
Das war ja gar nicht nachträglich!? ;D

ZitatgDT ist eine Art "best guess". Exoten oder Oldtimer kann es im Moment nicht, und ich bin auch unsicher, ob man das integrieren sollte. Wer "sowas" hat, "muss" es halt zu Fuß machen...

Da bin ich bei dir. Die FHEM-Demo ist halt in dem Fall für Test nur leider eher wenig brauchbar.

ZitatgDT ist eine Art "best guess". Daher sind ggf. im Moment (z.B. bei "media") Dinge drin, die das Gerät ggf. nicht kann. Ggf. können wir das ausbauen, um z.B. nur wirklich vorhandene setter auch zu mappen.

Müssen wir nicht. Kann's halt zu viel. Besser als zu wenig.

ZitatDas Ganze ist im Moment eher eine (überraschend gut funktionierende) Machbarkeitsstudie :) .

Funktioniert wirklich gut!
Aber ich bereu's eh schon, dass ich drauf herum geritten bin. Das verwirrt nur. In Zukunft wird wieder mit den rhasspy-Attributen gearbeitet.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 10 April 2021, 11:19:38
Die Intent-Tests gehen im anderen Thread weiter: https://forum.fhem.de/index.php/topic,113180.msg1074909.html#msg1074909
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 10 April 2021, 12:05:03
Die neue "Default-Branch" ist jetzt 0.4.7b.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 10 April 2021, 14:17:32
Zitat von: drhirn am 10 April 2021, 12:05:03
Die neue "Default-Branch" ist jetzt 0.4.7b.
:)

Zitat von: drhirn am 10 April 2021, 10:49:14
Funktioniert wirklich gut!
Aber ich bereu's eh schon, dass ich drauf herum geritten bin. Das verwirrt nur. In Zukunft wird wieder mit den rhasspy-Attributen gearbeitet.
Ähm, so war das nicht gemeint, jetzt bin ich es, der bereut, das als "so unvollkommen" dargestellt zu haben...
Fakt ist doch:
a) mich freut es  sehr, dass du es getestet und für grundsätzlich gut befunden hast!  8)
b) wird die Interessenten am 29. am ehesten interessieren, wie sie schnell mal testen können bzw. "progress" machen können ::) => Gerade das FS20-Dimmer-Ding ist super geeignet, um Möglichkeiten und Grenzen zu erläutern. In realen "modernen" Installationen wird es tendenziell eher besser funktionieren, weil CUL_HM, ZWave, HUEDevice und MQTT2_DEVICE in der Mehrzahl der Fälle (bis auf die Color-Themen) ootb laufen (behaupte ich mal in meinem jugendlichen Leichtsinn)!  8)
Und wer die gDT schon gesetzt hatte, wird evtl. direkt 1:1 loslegen können (von speziellen Mappings abgesehen, für die man auch sonst eben dann homeBridgeMapping setzen müßte...)
c) Die allgemeine Vorgehensweise ist damit einfach zu erläutern: vieles passiert ggf. automatisch, und wer damit nicht glücklich ist, kann das list ansehen,  rausfinden, wo es hakt und ggf. dann die "zusätzlichen" Attribute so setzen, dass es im Ergebnis paßt.
d) Ein bißchen Werbung zur Mitwirkung kann an der Stelle auch nicht schaden. Der "2Mapping"-Code ist eigentlich nicht besonders schwierig; wer etwas Übung hat, kann da gut was anflanschen, das dann allen das Leben erleichtert. Vielleicht findet sich sogar einer der "alten Hasen", der sich mit homeBridgeMapping auskennt und da einen 2RHASSPY-Parser beisteuern kann und will...?

Von daher sehe ich in dieser generellen "gDT-als -Startpunkt"-Vorgehensweise eher die Zukunft, und mAn. ist es auch soweit "ok", dass man es als "default" durchgehen lassen kann...
Vielleicht bekommen wir noch das "thermostat"-Thema mit der Temperaturabfrage bis zum 29. hin, dann ist doch eigentlich alles supi 8) , und wenn's noch LightScene reicht, ist es kaum zu toppen :P .

PS: zum Thema Timer und Wecker ist es so still ;D ... ::) :-* :P
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 11 April 2021, 08:44:12
Zitat von: Beta-User am 10 April 2021, 14:17:32
Ähm, so war das nicht gemeint, jetzt bin ich es, der bereut, das als "so unvollkommen" dargestellt zu haben...

Es ging mir eher darum, dass es eventuell ein paar bereits aktive Nutzer verwirren könnten. V.a., weil's nicht wirklich dokumentiert ist.

ZitatVielleicht bekommen wir noch das "thermostat"-Thema mit der Temperaturabfrage bis zum 29. hin, dann ist doch eigentlich alles supi

Das wär sehr gut!

Zitat
PS: zum Thema Timer und Wecker ist es so still ;D ... ::) :-* :P

Ja, leider. Aber zu den anderen Intents eh auch bis jetzt ;).
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 11 April 2021, 08:44:26
Gibt eine neue Rhasspy-Version: https://community.rhasspy.org/t/rhasspy-2-5-10-released/2619
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 11 April 2021, 08:50:32
^ weil ich in den Release-Notes gerade gesehen habe

ZitatOnly one satellite within a group should start recording if more than one detect the wake word at the same time

Die Gruppen liegen mir schon länger im Magen, ich wollt's nur bisher nicht erwähnen, sondern mir für eine später Version aufsparen. Aber schadet eigentlich nicht, es zu wissen.

Es gibt die Möglichkeit, Gruppen von Satelliten zu definieren. Wenn man z.B. in einem Raum mehrere hat (was bei mir dann der Fall sein wird). Die werden dann, wenn ich das richtig in Erinnerung habe, wie folgt benannt:

gruppenname.satellitenname

also z.B.

wohnzimmer.schreibtisch
wohnzimmer.esstisch


Wir sollten dann sicherstellen, dass so eine siteId richtig als "wohnzimmer" erkannt wird. In einer späteren Version dann.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 11 April 2021, 10:41:53
Wenn ich nach einem FHEM Neustart gleich ein update devicemap ausführe, bekomme ich eine Perl-Warnung:

PERL WARNING: Use of uninitialized value $devgroups in split at ./FHEM/10_RHASSPY.pm line 1302

Zeile 1302 ist bei mir:

sub RHASSPY_allRhasspyGroups {
...
        for (split m{,}xi, $devgroups ) {
...
}
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 11 April 2021, 11:19:18
Spiele gerade mit Shortcuts.

i="geh kochen" p={fhem ("set $NAME on")} n="Stehlampe" c="möchtest du schweinsbraten?"

Meine (offensichtliche) Antwort auf diese Frage ist immer "Ja". Was zu diesen Sentences passen würde:


[de.fhem:ConfirmAction]
(ja | tu es | ist ok ){Mode:OK}
(lass es | nein | abbrechen | abbruch ){Mode:Cancel}


Leider bekomme ich keinen Schweinsbraten, sondern offenbar immer einen Timeout.


2021.04.11 11:18:08.729 5: RHASSPY: [Rhasspy] Parse (IO: rhasspyMQTT2): Msg: hermes/intent/de.fhem_Shortcuts => {"input": "geh kochen", "intent": {"intentName": "de.fhem:Shortcuts", "confidenceScore": 1.0}, "siteId": "wohnzimmer", "id": null, "slots": [], "sessionId": "wohnzimmer-snowboy-6171a983-2d53-4c4f-aadc-681505f5f3c6", "customData": "snowboy", "asrTokens": [[{"value": "geh", "confidence": 1.0, "rangeStart": 0, "rangeEnd": 3, "time": null}, {"value": "kochen", "confidence": 1.0, "rangeStart": 4, "rangeEnd": 10, "time": null}]], "asrConfidence": null, "rawInput": "geh kochen", "wakewordId": "snowboy", "lang": null}
2021.04.11 11:18:08.730 5: Parsed value: geh kochen for key: rawInput
2021.04.11 11:18:08.730 5: Parsed value: Shortcuts for key: intent
2021.04.11 11:18:08.730 5: Parsed value: wohnzimmer-snowboy-6171a983-2d53-4c4f-aadc-681505f5f3c6 for key: sessionId
2021.04.11 11:18:08.730 5: Parsed value: geh kochen for key: input
2021.04.11 11:18:08.730 5: Parsed value: wohnzimmer for key: siteId
2021.04.11 11:18:08.730 5: Parsed value: 1 for key: probability
2021.04.11 11:18:08.731 5: handleIntentShortcuts called with geh kochen key
2021.04.11 11:18:08.731 5: Response is: HASH(0x55e246a34518)
2021.04.11 11:18:23.009 5: Response is: Tut mir leid, da hat etwas zu lange gedauert


Muss ich da etwas anders machen? Bzw., funktioniert das bei euch?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 11 April 2021, 12:28:02
Das mit der Confirmation funktioniert bei mir (@Rhasspy 2.5.10  :) ), und ich kann an deinen Sätzen im Moment auch nicht erkennen, wo das Problem liegen könnte.
Ich habe  in dem Confirmation-Zusammenhang aber ein anderes "Problem": Das "nein" (für Stille...) wird als Confirmation intent erkannt, aber keiner ist in der Lage, das zu händeln.
OK, nach dem alten Code ist das logisch, weil in dem Fall $data nicht mit übergeben wurde. Nur: das zu ergänzen hilft dem nicht ab... Hä?!?

Die unititialized-Meldung sollte "erlegt" sein, danke für's Melden (das war so ein "typischer" Fall, den ich mal hier zum Abschuss freigegeben hatte...).

Zitat von: drhirn am 11 April 2021, 08:50:32
Wir sollten dann sicherstellen, dass so eine siteId richtig als "wohnzimmer" erkannt wird. In einer späteren Version dann.
Besser jetzt und gleich :P ...
Ist nicht besonders getestet, müßte aber eigentlich funktionieren, und auch in der b-Version hätte man "einfach" nur passende siteId2room-Readings setzen müssen ;) .
(Ok, ich weiß, Doku. Meine eigentliche Idee dazu ist aber noch nicht fertig und besonders gut getestet...)

Zitat von: drhirn am 11 April 2021, 08:44:12
Es ging mir eher darum, dass es eventuell ein paar bereits aktive Nutzer verwirren könnten. V.a., weil's nicht wirklich dokumentiert ist.
Na ja, wer die "alten" Attribute hat, braucht das ja für den Teil nicht ändern, sollte ja (weitestgehend, wenn man von Namenskonventionen absieht) funktionieren. Und wie viel Doku braucht es dazu?
Wenn es "fertiger" ist, sollte man es mAn.  ::) in der cref prominenter präsentieren im Sinne von: bitte "use" setzen, aber das war es dann auch schon fast (abgesehen von einer "schöneren" Liste...)

ZitatJa, leider. Aber zu den anderen Intents eh auch bis jetzt ;) .
Na ja, eigentlich wollte ich nur zu diesem speziellen Punkt, der ja bei Einführung durchaus nicht direkt Begeisterung hervorgerufen hatte, ein "das ist ja jetzt aber tatsächlich klasse, wie das jetzt gelöst ist" hören ::) ...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 11 April 2021, 12:57:33
Zitat von: Beta-User am 11 April 2021, 12:28:02
Das mit der Confirmation funktioniert bei mir (@Rhasspy 2.5.10  :) ), und ich kann an deinen Sätzen im Moment auch nicht erkennen, wo das Problem liegen könnte.

Ich bekomm immer ein intentNotRecognized:

hermes/nlu/query
{
  "input" : "ja",
  "siteId" : "wohnzimmer",
  "id" : null,
  "intentFilter" : [ "ConfirmAction" ],
  "sessionId" : "wohnzimmer-snowboy-9eddd51b-a285-4027-8e5a-472af90c426f",
  "wakewordId" : "snowboy",
  "lang" : null,
  "customData" : "snowboy"
}

hermes/nlu/intentNotRecognized
{
  "input" : "ja",
  "siteId" : "wohnzimmer",
  "id" : null,
  "customData" : "snowboy",
  "sessionId" : "wohnzimmer-snowboy-9eddd51b-a285-4027-8e5a-472af90c426f"
}


Es hat also wohl irgendwie mit meinen Sentences zu tun. Denk ich. Ich hab aber deine genommen, also keine Ahnung, was bei mir anders ist.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 11 April 2021, 13:28:47
Zitat von: Beta-User am 11 April 2021, 12:28:02
Die unititialized-Meldung sollte "erlegt" sein, danke für's Melden (das war so ein "typischer" Fall, den ich mal hier zum Abschuss freigegeben hatte...).

Sieht gut aus, danke!

Zitat
Besser jetzt und gleich :P ...
Ist nicht besonders getestet, müßte aber eigentlich funktionieren, und auch in der b-Version hätte man "einfach" nur passende siteId2room-Readings setzen müssen ;) .

Ich kann's halt derzeit nicht testen. Weil ich zu wenig Satelliten habe. Andererseits ... ich könnte mal schauen, was passiert, wenn ich zwei Docker-Satelliten auf das selbe Mikro los lasse.

ZitatWenn es "fertiger" ist, sollte man es mAn.  ::) in der cref prominenter präsentieren im Sinne von: bitte "use" setzen, aber das war es dann auch schon fast (abgesehen von einer "schöneren" Liste...)

Wenn "use" gesetzt ist aber kein gDT-Attribut gesetzt, hat das ja eigentlich keine Auswirkungen, oder? Überraschend wird's nur, wenn man schon gesetzte gDT-Attribute von anderen Sprachsteuerungen hat und nicht damit rechnet, dass diese Geräte dann in Rhasspy auftauchen.
Ich überleg nämlich gerade, was passiert, wenn wir "use" automatisch setzen bzw. der "default" 1 ist.

Zitat
Na ja, eigentlich wollte ich nur zu diesem speziellen Punkt, der ja bei Einführung durchaus nicht direkt Begeisterung hervorgerufen hatte, ein "das ist ja jetzt aber tatsächlich klasse, wie das jetzt gelöst ist" hören ::) ...
Undankbares Pack! Genießen alle das Wochenende, anstatt uns zu loben. ;D
Kannst du mir einen Gefallen tun, und ein paar gesprochene deutsche Beispielsätze für Timer schreiben?

Im GitHub gibt's jetzt die 0.4.7c
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Cordula am 11 April 2021, 16:33:44
Zunächst einmal:

Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,
Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,
Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,Lob,
Aber wirklich ich finde es toll, wie ihr das Modul weiterbringt. Ich will ja immer nur was.

Aber nach dem Lob noch eine Rückmeldung. Ich habe einen Shortcut mit  Confirmation (4.7c) getestet. Mit dem gleichen Ergebnis, wie bei dir:
hermes/nlu/intentNotRecognized
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 11 April 2021, 16:35:05
;D

Hast du den gleichen Shortcut/Sentence genommen, wie ich?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Cordula am 11 April 2021, 16:45:41
Nein
Hier mein Shortcut:
i="rapunzel an" f="set Az.Anycubic on" c="Soll ich wirklich den 3d-Drucker einschalten" ct=10\

Und hier der Sentence-Eintrag:
[de.fhem:ConfirmAction]
(ja | tu es | ist ok ){Mode:OK}
(lass es | nein | abbrechen | abbruch ){Mode:Cancel}



hermes/nlu/intentNotRecognized
{"input": "ja", "siteId": "arbeitszimmer", "id": null, "customData": null, "sessionId": "arbeitszimmer-Okay Kalle-601bf1c5-81d6-4ba8-8586-0038a7ae401d"}
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 11 April 2021, 18:54:47
Zitat von: drhirn am 11 April 2021, 08:44:12
Ja, leider. Aber zu den anderen Intents eh auch bis jetzt ;).
Habe heute alle sentences und mappings auf englisch umgestellt und bin erfreut, dass es funktioniert.  :)
Wenn ich irgendwo helfen kann, lasst es mich wissen.

Durch den Hinweis von drhirn habe ich die Version 2.5.10 installiert - danke für die Info. Da soll ja einiges möglich sein.
Z.B. Kaldi Mixed Language Model Weight soll nun tatsächlich funktionieren. Das wäre ein großer Sprung, da ein riesen Wortschatz dran hängt.
Leider läuft das bisher nur mit Docker und die eigenständige Debian-Installation erweist sich als langwierig...

Für den 29. sehe ich gute Chancen zur weiteren Verbreitung und Unterstützung. Die Intents im Forum sind ein guter Anfang. Diese Infos gebündelt als ein README für die deutsche Version im Github bzw. zukünftig im Wiki würde ich als Schlüssel zur Verbreitung ansehen.

Gruß Jens
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 11 April 2021, 20:03:38
Zitat von: JensS am 11 April 2021, 18:54:47
Wenn ich irgendwo helfen kann, lasst es mich wissen.

Ganz, ganz wichtig wäre mir derzeit, mich mit Tests zu unterstützen und die Erkenntnisse im anderen Thread zu vermerken. Was wie getestet wurde und ob das Ergebnis so war, wie erwartet.
Schön wäre auch, wenn an der Doku mitgewirkt würde. Gerne auch auf deutsch übersetzen. Aber wirklich nur übersetzen, nicht ergänzen. Sonst laufen sie auseinander. Haupt-Doku hätte ich gerne immer in englisch.

Zitat
Z.B. Kaldi Mixed Language Model Weight soll nun tatsächlich funktionieren. Das wäre ein großer Sprung, da ein riesen Wortschatz dran hängt.
Leider läuft das bisher nur mit Docker und die eigenständige Debian-Installation erweist sich als langwierig...

Möchtest du erklären, was das genau macht und was sich dadurch für Möglichkeiten ergeben? Ich hatte noch keine Zeit, mich damit zu beschäftigen.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 11 April 2021, 20:25:59
Ok, wie schon erwähnt, ist mein englisch nicht sonderlich gut aber ich werde in meinem Fork eine Datei eröffnen.

Mixed Language Model Weight soll (so habe ich es verstanden) alle deutschen Wörter mit in die Erkennung einfließen lassen. Sobald mein separates Kaldi läuft, werde ich hoffentlich mehr dazu schreiben können.
Du hast ja Docker am Start und bist bestimmt schneller.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 12 April 2021, 08:25:49
Zitat von: JensS am 11 April 2021, 18:54:47
Habe heute alle sentences und mappings auf englisch umgestellt und bin erfreut, dass es funktioniert.  :)
Freut mich sehr, dass das geklappt hat. Würdest du den Aufwand für die Umstellung als groß ansehen, oder eher als klein, wenn man mal weiß, was zu ändern ist?

Zitat
Z.B. Kaldi Mixed Language Model Weight soll nun tatsächlich funktionieren. Das wäre ein großer Sprung, da ein riesen Wortschatz dran hängt.
Leider läuft das bisher nur mit Docker und die eigenständige Debian-Installation erweist sich als langwierig...
Das Thema würde mich auch (später mal) interessieren. Ich weiß, die Gefahr der Unübersichtlichkeit besteht, wenn man Teilthemen auf mehrere Thread verteilt, aber trotzdem die Bitte, das in einen separaten Thread zu packen. MAn. wäre das auch für die aktuellen sentences-Tests besser gewesen, denn bei dem alten Thread ist es so: Neue User (mich eingeschlossen) interessiert die ganze Historie nicht im Detail, jeder "Einsteiger" in ein neues Thema will eigentlich nur eine aktuelle summary haben (selbst wenn die vorläufig ist und offene Fragen als solche benennt), und sich nicht seitenlang alles mögliche (potentiell schon wieder veraltete) durchlesen und sich dadurch verwirren lassen.

Zitat von: Cordula am 11 April 2021, 16:45:41
Nein
[...]
Und hier der Sentence-Eintrag:
[de.fhem:ConfirmAction]
(ja | tu es | ist ok ){Mode:OK}
(lass es | nein | abbrechen | abbruch ){Mode:Cancel}

Das simle "ja" scheint für Rhasspy zu kurz zu sein, wenn "intent not recognized" zurückkommt. Diese Erfahrung hatte drhirn ja auch gemacht. Mit meinem "ja mach" scheint es zu funktionieren, wenn ich die etwas kryptische Rückmeldung von drhirn richtig deute.


Apropos "intent" und Timeout - betr. der "nein"-Confirmation habe ich folgende Theorie: RHASSPY deaktiviert den. Das bedeutet aber nicht, dass es ihn (vorübergehend) nicht mehr gibt (das war meine Vermutung), und auch noch nicht mal, dass er nicht mehr versendet wird. Entweder es ist ein Fehler im Deaktivierungs-Code oder  ich würde als Bug bei Rhasspy ansehen, aber wir könnten dann vermutlich als würgaround dann einfach die "SilentConfirmation" durchführen.
Mal sehen...


Da zwar ausgiebiges Lob zurückkam, aber keine ausdrückliche Rückmeldung zu dem Timer-Thema vom Ober-Skeptiker betr. des "Wecker"-Dingens, hier noch eine Anleitung:

a) es sollte (wie üblich  ::) ...) alles funktionieren, was mit dem "alten timer"-Code auch ging:
"timer auf 5 Sekunden", "timer auf 2 Minuten 7 sekunden", ...
Wenn man dann in die Bereiche von einigen Minuten oder mehreren Stunden kommt, kommt eben dann eine andere Rückmeldung ;) .
b) Man kann "belabeln":
"timer Eier auf 5 Minuten"
Das ist optional, führt aber uU. dazu, dass man in einem Raum mehrere Timer laufen haben kann (und entsprechend viele Readings hat (weiß nicht, ob man das überdenken sollte oder eben einfach von Zeit zu Zeit nicht mehr genutzte Readings löschen sollte).
c) Absolute Zeitangaben sind möglich:
"timer auf 18 Uhr", "Timer auf 18 Uhr 15", "Wecker Kartoffeln auf 18 Uhr 15", "Wecker Eier auf 6 Uhr 22".
Auch hier wieder: Bitte verschiedene Endezeiten (ab jeweils "jetzt") testen, und das ganze dann auch mal über Mitternacht raus versuchen.

Zitat von: drhirn am 11 April 2021, 13:28:47
Wenn "use" gesetzt ist aber kein gDT-Attribut gesetzt, hat das ja eigentlich keine Auswirkungen, oder? Überraschend wird's nur, wenn man schon gesetzte gDT-Attribute von anderen Sprachsteuerungen hat und nicht damit rechnet, dass diese Geräte dann in Rhasspy auftauchen.
Ich überleg nämlich gerade, was passiert, wenn wir "use" automatisch setzen bzw. der "default" 1 ist.
"use" wirkt sich in der Tat nur aus, wenn a) überhaupt irgendwo ein gDT gesetzt ist und b) (zusätzlich!) das Device von der devspec erfasst ist. Von daher sollte sich die Überraschung in Grenzen halten.
Das mit dem default halte ich für eine gute Idee. Wer es von den jetzigen Usern nicht will, liest hier vermutlich sowieso mit und kann es abschalten, und Einsteigern (=>29.) erleichtert es die Sache, wenn "sowieso" schon gDT gesetzt sind.
Soll ich oder machst du?

Zitat
Für den 29. sehe ich gute Chancen zur weiteren Verbreitung und Unterstützung. Die Intents im Forum sind ein guter Anfang. Diese Infos gebündelt als ein README für die deutsche Version im Github bzw. zukünftig im Wiki würde ich als Schlüssel zur Verbreitung ansehen.
Die sentences sind definitiv wichtig. Genauso wichtig ist eine offene Kommunikation zu Möglichkeiten und Grenzen, von daher bin ich auch mal gespannt, was ihr dazu so zu berichten habt, ich selbst bin nämlich noch in der Experimentierphase: Einerseits begeistert, dass das alles verblüffend gut klappt, andererseits schaue ich immer mal wieder auf top (derzeit unauffällig) und die "Treffer". Letztere sind in meiner Wahrnehmung  hin und wieder weiter manchmal irgendwie zufällig. Weiß noch nicht so recht, ob es daran liegt, dass ich zum Testen das ganze relativ schnell etwas breiter ausgerollt habe und daher die Namensvergabe teilweise noch nicht so durchdacht (oder verinnerlicht) ist, dass es "super" ist, sei es, dass es (auch bei anderen Lösungen!) eben Grenzen des Verfahrens im allgemeinen gibt. Aber da fehlt mir z.B. auch der Vergleich mit anderen Sprachsteuerungssystemen. Ich vermute, alle kämpfen an der Stelle mit ähnlichen Problemen. (Ich habe aber mal wieder nicht die Neigung, sämtliche 1000 Seiten zu alexa und homebridge zu lesen...).
Auch dazu bin ich mal auf den 29. gespannt :) .
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 12 April 2021, 08:58:03
Zitat von: Beta-User am 12 April 2021, 08:25:49
MAn. wäre das auch für die aktuellen sentences-Tests besser gewesen, denn bei dem alten Thread ist es so: Neue User (mich eingeschlossen) interessiert die ganze Historie nicht im Detail, jeder "Einsteiger" in ein neues Thema will eigentlich nur eine aktuelle summary haben (selbst wenn die vorläufig ist und offene Fragen als solche benennt), und sich nicht seitenlang alles mögliche (potentiell schon wieder veraltete) durchlesen und sich dadurch verwirren lassen.

Mein Plan war, die Sentences/Devices dann in eine Doku zu packen, sobald die Tests abgeschlossen sind.
Aber du hast recht, ich mag auch keine ewig langen Threads. Andererseits ist bei einem neuen die Gefahr, dass das ein paar Mitleser nicht mitbekommen.
Und ich verlinke alle Intent-Test-Beiträge ja im ersten Beitrag. (Außer die von gestern, die hab ich vergessen ;))

ZitatDas simle "ja" scheint für Rhasspy zu kurz zu sein, wenn "intent not recognized" zurückkommt. Diese Erfahrung hatte drhirn ja auch gemacht. Mit meinem "ja mach" scheint es zu funktionieren, wenn ich die etwas kryptische Rückmeldung von drhirn richtig deute.

Ich habe das zwar nicht behauptet, weil ich das nicht wusste. Aber ich werde das gleich ausprobieren.

ZitatDa zwar ausgiebiges Lob zurückkam, aber keine ausdrückliche Rückmeldung zu dem Timer-Thema vom Ober-Skeptiker betr. des "Wecker"-Dingens, hier noch eine Anleitung:

Suuuper, danke!

ZitatAuch hier wieder: Bitte verschiedene Endezeiten (ab jeweils "jetzt") testen, und das ganze dann auch mal über Mitternacht raus versuchen.

Ahm. Letzte Woche hat sich bei mir mal Rhasspy während dem Fernsehen bei mir gemeldet (wie so oft). Ich hab nur leider nicht verstanden, was sie mir gesagt hat. Dafür hat sich mich dann mitten in der Nacht mit "Timer abgelaufen" angebrüllt. Das mit "über Mitternacht" scheint also zu funktionieren ;D

ZitatDas mit dem default halte ich für eine gute Idee. Wer es von den jetzigen Usern nicht will, liest hier vermutlich sowieso mit und kann es abschalten, und Einsteigern (=>29.) erleichtert es die Sache, wenn "sowieso" schon gDT gesetzt sind.
Soll ich oder machst du?

Darf ich dich bitten?


ZitatDie sentences sind definitiv wichtig. Genauso wichtig ist eine offene Kommunikation zu Möglichkeiten und Grenzen, von daher bin ich auch mal gespannt, was ihr dazu so zu berichten habt, ich selbst bin nämlich noch in der Experimentierphase: Einerseits begeistert, dass das alles verblüffend gut klappt, andererseits schaue ich immer mal wieder auf top (derzeit unauffällig) und die "Treffer". Letztere sind in meiner Wahrnehmung  hin und wieder weiter manchmal irgendwie zufällig. Weiß noch nicht so recht, ob es daran liegt, dass ich zum Testen das ganze relativ schnell etwas breiter ausgerollt habe und daher die Namensvergabe teilweise noch nicht so durchdacht (oder verinnerlicht) ist, dass es "super" ist, sei es, dass es (auch bei anderen Lösungen!) eben Grenzen des Verfahrens im allgemeinen gibt. Aber da fehlt mir z.B. auch der Vergleich mit anderen Sprachsteuerungssystemen. Ich vermute, alle kämpfen an der Stelle mit ähnlichen Problemen. (Ich habe aber mal wieder nicht die Neigung, sämtliche 1000 Seiten zu alexa und homebridge zu lesen...).
Auch dazu bin ich mal auf den 29. gespannt :) .

Ganz ehrlich? Überhaupt kein Vergleich zu Alexa, Google, Siri. Wäre auch vermessen, das überhaupt zu erwarten. Oder zu erwarten, dass das irgendwann so wird. Hinter Rhasspy stecken weder Milliarden an Dollar, noch riesige Serverfarmen, noch eine schier unendliche Zahl an Trainingsdaten. Das darf man nie vergessen. Trotzdem funktioniert Rhasspy erfreulich gut finde ich. Man ist halt in den Möglicheiten beschränkt und hat viel Handarbeit. Aber das Projekt ist eigentlich noch sehr jung. Mal sehen, was da noch kommt.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Cordula am 12 April 2021, 09:24:11
Zum Thema shortcuts:

Bei mir funktioniert das mit "Ja mach" oder auch mit "Ja mach das bitte" auch nicht. Gleiche Fehlermeldung: hermes/nlu/intentNotRecognized. Version 2.5.10
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 12 April 2021, 09:30:39
Zitat von: JensS am 11 April 2021, 20:25:59
Mixed Language Model Weight soll (so habe ich es verstanden) alle deutschen Wörter mit in die Erkennung einfließen lassen. Sobald mein separates Kaldi läuft, werde ich hoffentlich mehr dazu schreiben können.
Du hast ja Docker am Start und bist bestimmt schneller.

Also, ich weiß bis jetzt nur, dass ein Mixed Language Model Weight Wert von 0.05 die Trainingszeit auf einer Proxmox VM mit 4CPUs um 180s verlängert  :o
So viel, wie ich derzeit durch die Tests trainieren lasse, kann ich das nicht brauchen ;)
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 12 April 2021, 09:42:37
Zitat von: Cordula am 12 April 2021, 09:24:11
Zum Thema shortcuts:

Bei mir funktioniert das mit "Ja mach" oder auch mit "Ja mach das bitte" auch nicht. Gleiche Fehlermeldung: hermes/nlu/intentNotRecognized. Version 2.5.10

Kann ich bestätigen.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 12 April 2021, 09:54:35
Zitat von: Cordula am 12 April 2021, 09:24:11
Zum Thema shortcuts:

Bei mir funktioniert das mit "Ja mach" oder auch mit "Ja mach das bitte" auch nicht. Gleiche Fehlermeldung: hermes/nlu/intentNotRecognized. Version 2.5.10
Hmm, bin da im Moment ratlos. RHASSPY braucht halt eine eingehende Bestätigung (oder eben einen Abbruch). Wenn es auf der Rhasspy-Seite hakt - warum auch immer - kann das nicht klappen....
Tiefergreifende Analysen dazu habe ich nicht gemacht, aber wenn es da schon Schwierigkeiten mit so (vermeintlich) einfachen Sachen gibt, ist das unschön.

"ja mach" gibt mir jedenfalls "Warte grade nicht auf eine Bestätigung" zur Antwort.
(habe aber nach dem update bisher nur den Dienst neu gestartet, nicht den ganzen Server; auch nach einem  Training@2.5.10 passt das noch).
Zitat von: drhirn am 12 April 2021, 09:30:39
Also, ich weiß bis jetzt nur, dass ein Mixed Language Model Weight Wert  [...]
...klingt spannend...

Zitat von: drhirn am 12 April 2021, 08:58:03
Suuuper, danke!
8)

ZitatAhm. Letzte Woche hat sich bei mir mal Rhasspy während dem Fernsehen bei mir gemeldet (wie so oft). Ich hab nur leider nicht verstanden, was sie mir gesagt hat. Dafür hat sich mich dann mitten in der Nacht mit "Timer abgelaufen" angebrüllt. Das mit "über Mitternacht" scheint also zu funktionieren ;D
Na ja, es ging eher a) um die Rückmeldung, die man direkt nach dem Setzen eines Timers bekommt bzw. b) darum, dass er zum richtigen Zeitpunkt abläuft ;D .

Zitat
Darf ich dich bitten?
Kommt bei Gelegenheit.

Zitat
Ganz ehrlich? Überhaupt kein Vergleich zu Alexa, Google, Siri. Wäre auch vermessen, das überhaupt zu erwarten. Oder zu erwarten, dass das irgendwann so wird. Hinter Rhasspy stecken weder Milliarden an Dollar, noch riesige Serverfarmen, noch eine schier unendliche Zahl an Trainingsdaten. Das darf man nie vergessen. Trotzdem funktioniert Rhasspy erfreulich gut finde ich. Man ist halt in den Möglicheiten beschränkt und hat viel Handarbeit. Aber das Projekt ist eigentlich noch sehr jung. Mal sehen, was da noch kommt.
Dieses "die haben viel Geld"-Argument ist m.E. nur bedingt tragfähig. Natürlich braucht man bei mehr Variationsmöglichkeiten genauere Unterscheidungsmethoden, und in dem Zusammenhang dann auch entsprechend Rechenpower. Das schließt aber nicht aus, dass man mit relativ bescheidenen Mitteln schon mehr als akzeptable Ergebnisse erzielen kann - dass das eine entsprechend "intelligente" Konfiguration voraussetzt, ist schon klar, aber auch da sollten sich die Aufwände in einem überschaubaren Rahmen halten lassen.
Im Ergebnis kochen eben alle nur mit Wasser, und ein gutes Rezeptebuch hilft manchmal über das Fehlen von Kaviar ganz gut hinweg :P ... Also: wardmrsab.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 12 April 2021, 10:00:48
Zitat von: Beta-User am 12 April 2021, 09:54:35
Hmm, bin da im Moment ratlos. RHASSPY braucht halt eine eingehende Bestätigung (oder eben einen Abbruch). Wenn es auf der Rhasspy-Seite hakt - warum auch immer - kann das nicht klappen....
Tiefergreifende Analysen dazu habe ich nicht gemacht, aber wenn es da schon Schwierigkeiten mit so (vermeintlich) einfachen Sachen gibt, ist das unschön.

Ich würde dem Thema momentan keine zu hohe Priorität gönnen. Es ist auch im Rhasspy-Forum noch ziemlich ruhig diesbezüglich. Bringen wir unsere Standard-Intents mal vollständig zum Laufen.

ZitatNa ja, es ging eher a) um die Rückmeldung, die man direkt nach dem Setzen eines Timers bekommt bzw. b) darum, dass er zum richtigen Zeitpunkt abläuft ;D .

Ist der Plan für heute. Warte schon darauf, dass mich Rhasspy erinnert, dass ich bald zum Zahnarzt muss  :'(
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 12 April 2021, 11:45:18
Also: "use" müßte anliegend default sein, und die gemessene Temperatur kommt jetzt auch beim Thermostaten.
Bin noch nicht sicher, ob das nicht Nebenwirkungen auf die Solltemperatur hat, aber wenn, war das sowieso bisher ein Zufallstreffer, da war jedenfalls ein kleiner aber wirkungsvoller Typo im Code...
Na jedenfalls wäre jetzt die Herausforderung, die Solltemperatur ansagen zu lassen :P .

Generell ist da noch etwas Vorbereitung drin, um ggf. auch "subType" auswerten zu können (insbesondere für "desired-temp"). Allerdings bin ich mir noch nicht sicher, ob das auf diese Art sinnvoll gelöst ist, wird sich zeigen.

Dann mal viel Spaß beim Dentisten und später wieder beim Testen...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 12 April 2021, 20:29:44
Zitat von: Beta-User am 12 April 2021, 08:25:49
Freut mich sehr, dass das geklappt hat. Würdest du den Aufwand für die Umstellung als groß ansehen, oder eher als klein, wenn man mal weiß, was zu ändern ist?
Der Aufwand pro Device ist gering. Da sich alle Devices im Raum Rhasspy befinden, hat man auch eine gute Übersicht, was man anfassen muss.

Gruß Jens
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 13 April 2021, 07:56:14
Danke für die Rückmeldung.

Anbei wieder eine Iteration weiter:
- desired-temp ist als neue abfragbare Kategorie drin. Noch nicht optimaler sentence (GetNummeric):
((Solltemperatur | Wunschtemperatur | Zieltemperatur){Type:desired-temp} | ( warm | kalt | heiß | Temperatur ){Type:temperature}) [ist es | von | vom | ist ] ([(im|auf dem)]($de.fhem.Room){Room}|[das]($de.fhem.Device){Device})
- In dem confirmation-Code waren noch einige Ungereimtheiten drin. Bei mir funktioniert das weiter, vielleicht hilft es auch bei euch...? Was jedenfalls besser ist: Es fühlt sich jemand für das "lautlose nein" zuständig, es gibt keinen Timeout mehr.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 13 April 2021, 07:59:09
Ich arbeite gerade am Timer. Da laufen die letzten Tests. Schau mir deine Änderungen gleich danach an.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 13 April 2021, 08:45:17
Unser Gesundheitsminister tritt wohl zurück, ich allerdings noch nicht. Habe am Timer gebastelt. Ihr werdet mich prügeln dafür, aber ihr müsst eure Rhasspy-Sentences anpassen. Es gab da Inkonsistenzen was die Groß-/Kleinschreibung der Labels betrifft (hourabs, hour, min, sec). Außerdem hab ich als Vorsichtsmaßname Cancel in CancelTimer umbenannt. Nur Cancel könnte unter Umständen zweideutig werden.
Das Wort "timer" hab ich aus den Sentences gestrichen und ein "Label" draus gemacht. Gemeinsam mit Änderungen an den Sprachdateien gibt das schönere Sprachausgaben.
Außerdem werden die Readings nicht mehr auf 0 od. 1 gesetzt, sondern auf die Uhrzeit, wann der Timer abläuft. Nach Ablauf od. Abbruch werden die Readings wieder gelöscht.

Meine Sentences:

[de.fhem:SetTimer]
labels=( Wecker | Eieruhr | Kartoffeltaimer | Teetaimer | Taimer)

# Timer auf eine Stunde, 20 Minuten und 3 Sekunden
# Timer auf eine Stunde
# Timer auf drei Minuten
\[<labels>{Label}] [in|im|in der|auf der] [$de.fhem.Room{Room}] (in|auf) [((1..60){Hour!int} (stunde|stunden))] [und] [((1..60){Min!int} (minute|minuten))] [und] [((1..60){Sec!int} (sekunde|sekunden))]

# Timer auf ein einviertel Stunden
\[<labels>{Label}] [in|im|in der|auf der] [$de.fhem.Room{Room}] (in|auf) (1..60){Hour!int} (einviertel{Min:15}|einhalb{Min:30}|dreiviertel{Min:45}) (stunde|stunden)

# Timer auf ein einhalb Minuten
\[<labels>{Label}] [in|im|in der|auf der] [$de.fhem.Room{Room}] (in|auf) (1..60){Min!int} (einviertel{Sec:15}|einhalb{Sec:30}|dreiviertel{Sec:45}) (minute|minuten)

# Timer auf 12 Uhr 15
\[<labels>{Label}] [in|im|in der|auf der] [$de.fhem.Room{Room}] (in|auf|um) (1..24){Hourabs!int} uhr [(1..60){Min!int}]

# Timer löschen
(lösche|entferne|stoppe){CancelTimer} [den|die] [<labels>{Label}]  [in|im|in der|auf der] [$de.fhem.Room{Room}]
\[<labels>{Label}] [in|im|in der|auf der] [$de.fhem.Room{Room}] (abbrechen|stoppen|löschen){CancelTimer}
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 13 April 2021, 09:24:24
Zitat von: Beta-User am 13 April 2021, 07:56:14
- In dem confirmation-Code waren noch einige Ungereimtheiten drin. Bei mir funktioniert das weiter, vielleicht hilft es auch bei euch...? Was jedenfalls besser ist: Es fühlt sich jemand für das "lautlose nein" zuständig, es gibt keinen Timeout mehr.

Funktioniert!

Aber:
- Bei einer positiven Bestätigung bleibt im Reading "voiceResponse" ein HASH stehen, solange man die Seite nicht manuell aktualisiert. Bei negativ wechselt das Reading auf "habe abgebrochen"
- Sagt man nichts, gibt's trotzdem eine Aktion. Und zwar positiv, wenn man "ja" in den sentences hat, ansonsten negativ weil "nein" verstanden wird. Das dürfte aber eine Rhasspy-Geschichte sein. Kann man lösen, in dem man in den betreffenden Sentences alles auf optional stellt:


[de.fhem:ConfirmAction]
\[(ja mach|ja|ja bitte|tu es|ist ok|bitte darum){Mode:OK}]
\[(lass es|nein|abbrechen|abbruch){Mode}]
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 13 April 2021, 09:42:59
Zitat von: drhirn am 13 April 2021, 09:24:24
Funktioniert!
:)

Danke für die Rückmeldung und auch für's Verbessern der sentences.
Wegen dem HASH muss ich mal schauen, aber wenn man einen refresh braucht, heißt das eigentlich immer, dass keine ausreichende Info über das getriggerte Gerät (via ParseFn an fhem.pl) zurückgegeben wurde.

Zitat von: drhirn am 13 April 2021, 08:45:17
Habe am Timer gebastelt. [...]
MAn. kein Grund, irgendwen zu verprügeln!
Klingt alles sinnvoll, und ich bin auch ausgesprochen dankbar, wenn jemand meine "feasibility studies" dann aufgreift und vollends "zur Marktreife" fertig baut ::) .
Auch das mit den erläuternden Kommentaren direkt in sentences.ini ist eine gute Idee, btw.!
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 13 April 2021, 10:21:32
...auf Verdacht (=ungetestet!) noch ein paar kleinere Änderungen. Hoffentlich (!) sind folgende Punkte damit erledigt:
- ConfirmAction sollte jetzt auf alle Fälle was zurückliefern, und über die kleine Ergänzung in onmessage() sollte jetzt eigentlich immer abgesichert sein, dass zumindest die aufgerufene RHASSPY-Instanz zurückegliefert wird;
- auch die desired-temp-Rückmeldung verwendet jetzt $location; der technische Name war unschön;
Da der Teil bisher in der de-cfg noch nicht drin war, auch dazu ein update.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Cordula am 13 April 2021, 11:17:27
Shortcuts mit Confirmation funktionieren bei mir jetzt auch. Nach dem shortcut/erste Frage wird bei voiceResponse ein Hash angezeigt. Nach der Confirmation die richtige Antwort.

Der Timer-Intent funktioniert bei mir einwandfrei. Hier noch eine Ergänzung für die Sentence.ini.


# Timer auf eine viertel/halbe/dreiviertel Stunde
\[<labels>{Label}] [in|im|in der|auf der] [$de.fhem.Room{Room}] (in|auf) ((eine viertel){Min:15}|(eine halbe){Min:30}|(eine dreiviertel){Min:45}) (stunde|stunden)

# Timer auf eine viertel/halbe/dreiviertel Minute
\[<labels>{Label}] [in|im|in der|auf der] [$de.fhem.Room{Room}] (in|auf) ((eine viertel){Sec:15}|(eine halbe){Sec:30}|(eine dreiviertel){Sec:45}) (minute|minuten)

Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 13 April 2021, 11:32:31
Vermutlich habe ich die Ursache für den übergangsweisen Hash identifiziert, der sollte mit dem Anhang der Vergangenheit angehören.

Zur Erläuterung: Es wird neuerdings versucht, alle anderen intents zu deaktivieren, solange diese Anfrage läuft. Dazu muss aber in den Parameter etwas mehr als nur der reine Text => was zusätzlich ist, wird mit in einen Hash verpackt, und den habt ihr dann gesehen...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 13 April 2021, 11:39:12
Ich muss meinen Shortcut ändern. Ich hab seit Samstag dauernd ein unbändiges Verlangen nach Schweinsbraten ;D

Shortcut:

i="geh kochen" f="set Stehlampe on" n="Stehlampe" c="Magst du Schweinsbraten"


Sentences:

[de.fhem:ConfirmAction]
\[(ja mach|ja|ja bitte|tu es|ist ok|bitte darum){Mode:OK}]
\[(lass es|nein|abbrechen|abbruch){Mode}]


Tut jetzt alles wie erwartet. Super!  8)
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 13 April 2021, 12:12:09
Also, bei GetNumeric und desired-temp kann ich auch nur Positives berichten. In der rhasspy-de.cfg war in Zeile 72 nur ein kleiner Tippfehler bei Solltemperatur
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 13 April 2021, 13:24:28
 :)

Dann scheinen wir ja erst mal auf Stand zu sein? Dann wäre es an der Zeit, mal zu sammeln, wo denn grade noch mehr oder weniger bekannte "Baustellen" zu finden sind.

Erst mal die Shortlist:
- kein "match in room" bei GetNumeric
- "kind" und wie man es füllen könnte (mehr Dialoge)
- Bestätigungsdialoge - weitere Anwendungsfelder
- gDT: mehr und bessere mappings?
- Farbe und Farbtemperatur

Im Detail:
kein "match in room" bei GetNumeric
Zitat von: Beta-User am 10 April 2021, 06:45:37
Meine persönliche Vorstellung wäre:
1. Schritt: Andere Ansage - "Für die Küche kenne ich den Wert nicht, im Arbeitszimmer ..." (das sollte relativ einfach umzusetzen sein)
Die Vermutung war leider nicht richtig, jedenfalls habe ich bisher keinen wirklich guten "Dreh" gefunden, um die zusätzliche Info zielsicher irgendwie reinzupacken. Klingt für mich danach, als müßte man ggf. einen etwas allgemeingültigeren Ansatz wählen, um Zusatz-Sätze oder ähnliches anzuflanschen.
Persönliche Prio: niedrig

"kind" und wie man es füllen könnte (mehr Dialoge)
Zitat von: drhirn am 09 April 2021, 17:50:41
Ich weiß jetzt auch nicht, wofür "kind" ist. Aber ich habe mal nachgefragt und werden dann berichten. Die Frage ist allerdings, ob man's überhaupt setzen kann.
Hast du mir da einen Link?
Im aktuellen Code ist teilweise eine "subType"-Logik angerissen, evtl. wäre es möglich, das irgendwie zusammenzubringen.

Ansonsten werde ich ggf. auch selbst mal da posten, nachdem das mit der Bestätigung ja jetzt bei allen funktioniert. Meine momentane Idee wäre, einen "all.fhem-labels"-slot vorab mit allen denkbaren Auswahlmöglichkeiten zu füllen (für Trainingszweche), und den dann dynamisch nur mit den Werten zu arbeiten, die im jeweiligen Auswahldialog eine Rolle spielen. Das könnte dann auch das "kein match in room"-Problem auf andere Weise lösen.
Bin aber noch nicht überzeugt, dass das die einzige Variante ist, die funktionieren kann und will nicht massive Code-Eingriffe vorschlagen, bevor das geklärt ist. Insbesondere geht mir das hier nicht aus dem Kopf:
Zitat von: Beta-User am 09 April 2021, 18:23:39irgendwie müßte es aber möglich sein, Rhasspy mitzuteilen, welches "Ding" welcher "kind" ist, diffuse Vermutung: der JSON zur Bildung des slots müßte entsprechende zusätzliche Infos enthalten...
Persönliche Prio: schwierig, aber m.E. das vordringlichste der Dialog-Themen

Bestätigungsdialoge - weitere Anwendungsfelder
Wie bereits erwähnt: shortcuts war eigentlich nur die Spielwiese. Die nächste Frage wäre dann, wo es (optional!) dann noch möglich sein sollte.
MAn. vorrangig wären da die Themen SetOnOff(Group), (mit Abstand) gefolgt von den SetNumeric-Varianten.
Könnte mir vorstellen, dass es pro FHEM-Device eine Zeile in "specials" gibt mit dem Schlüsselwort "confirm:":
attr <device> rhasspySpecials confirm:SetOnOff
attr <device> rhasspySpecials confirm:SetOnOff=cmdOff
(Alle, oder eben nur eine Teilmenge)
Persönliche Prio: mittel

gDT: mehr und bessere mappings?
Hat zwei Teilaspekte:
- Zum einen sind die vorhandenen Mappings halt erst mal auf die Schnelle "zusammengestupft" und schon alleine deswegen ausbaufähig. Wer passenden Code hat, kann da laufend was beisteuern.
- Zum anderen sind (neben den mich nicht so "drückenden" Farbthemen) insbesondere "scene" und "media" interessant. Da habe ich mir mal angesehen, was denn da so an settern an diesen beiden "Großtypen" vorhanden ist, und - na ja - wie sage ich es: meine Fresse...
Da geht kaum was über einen Kamm zu schehren, und es gibt Überschneidungen. Mein Receiver kann z.B. auch Szenen, dafür eben kein "play" und "pause", und die Mainzone kann andere Dinge wie die sehr viel eingeschränktere Zone 2.

Die große Frage ist, wie damit umgehen. Meine aktuelle Idee wäre, "einfach" eine Art "generischer setter-Analyse" drüberlaufen zu lassen, also z.B. bei "media" dann zu schauen, ob "play" vorhanden ist (dann kommt das rhasspy-Mapping auch in den Hash), oder eben nicht (=> kein Eintrag im Hash), und das ganze dann eben für eine "typische" Auswahl an wichtigen Steuerungselementen.
Hat den Vorteil, dass man z.B. auch Szenennamen darüber erfahren könnte und gleich an Rhasspy übermitteln, aber den Nachteil, dass das ganze dann erst mal jemand machen muss...
Persönliche Prio: relativ hoch, aber auch da ist es so, dass ich mir nicht sicher bin, ob es nicht bessere Lösungen gibt. Weiter ist mir unklar, ob das in die derzeitigen RHASSPY-Kategorien alles auch reinpaßt (Szenen sind mit einiger Sicherheit ein neuer intent). Andererseits:
Zitat von: drhirn am 09 April 2021, 17:50:41
Fände ich ganz gut. Ich bilde meinen Lichtszene derzeit ja mit rhasspyChannels ab.
Ist evtl. für diesen Teilbereich auch eine Lösung, da Channels ja "alles"erlaubt. Aber man muss dann eben auch händisch ran...

Farbe und Farbtemperatur
Zitat von: drhirn am 09 April 2021, 17:50:41
Interessanter wäre - und deswegen habe ich wegen gDT im Code gefragt - ein Typ "colorlight" oder so. Um die Farbe des Lichts setzen zu können.
Zur Idee zusätzlicher dDT-Type hatte ich ja schon was geschrieben, aber bei Licht kommt m.E. noch das Zusatzproblem dazu, dass das ganze afaik kaum normiert ist, sobald man die halbwegs gesicherten Gefilde von on/off und pct/brightness hinter sich gelassen hat...
Persönliche Prio: Ist für mich persönlich eher unwichtig.

Fragen meinerseits:
- fehlt was auf der shortlist?
- wie seht ihr das? Angefangen bei der jeweiligen persönlichen Prio-Liste.
(- ist das obige überhaupt verständlich dargestellt...?)
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 13 April 2021, 14:14:32
Pfuh, langer Beitrag. Versuche mal, zu antworten und hab schon auch noch ein paar kleine Punkte.

Zuerst muss ich aber sagen, dass ich bis 29. gerne eine Feature-Freeze hätte. Prio muss jetzt Testen, Testen, Bugfixing, Doku und Testen haben. Sonst muss ich immer von vorne anfangen mit meinen Tests.

Ad "kein "match in room" bei GetNumeric": Andere Alternative wäre: "Kein passendes Gerät gefunden". Fände ich schöner, als die derzeitige Lösung und wäre wahrscheinlich leicht zu lösen. Später können wir dann einen Dialog einbauen.

Bzgl. der "kind"-Sache kannst du gerne den Link haben. Es hat mir bis dato aber niemand geantwortet. https://community.rhasspy.org/t/what-is-slots-value-kind-for/2610
Ansonsten weiß ich gerade nicht, was du mit subtype vor hast und wofür wir das brauchen könnten.

Zu den Bestätigungsdialogen: Überhaupt keine Priorität für mich derzeit.

gDTs sind cool, da weiter zu bauen fände ich schon interessant. Da würde ich aber sagen, wir halten uns an die minimalen FHEM-Vorgaben was Setter betrifft. Für z.B. AV-Geräte gibt's ja das hier: https://wiki.fhem.de/wiki/DevelopmentGuidelinesAV. Unterstützt ein Gerät einen definierten Befehl nicht, Pech gehabt.
Lightscenes werden wir nicht abbilden können, weil wir ja nicht wissen, wie die heißen.

Bei Farbe und -Temperatur war ich eigentlich der Meinung, dass das auch in FHEM normiert ist. Kann mich da aber täuschen. Wir setzen einfach rgb (oder was halt Standard ist) und ct. Wenn's ein Gerät nicht kann, wieder Pech.

Ich hab am Anfang der 10_RHASSPY.pm noch ein paar Punkte:

Aber wie gesagt, alles keine Priorität für mich derzeit. Ich brauche nur dringend Unterstützung beim Testen.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 13 April 2021, 15:24:03
Zitat von: drhirn am 13 April 2021, 14:14:32
Zuerst muss ich aber sagen, dass ich bis 29. gerne eine Feature-Freeze hätte. Prio muss jetzt Testen, Testen, Bugfixing, Doku und Testen haben.
Sehe ich auch so. Wenn, dann geht es vorrangig erst mal um Verbesserung der vorhandenen features.

Zitat
Ad "kein "match in room" bei GetNumeric": Andere Alternative wäre: "Kein passendes Gerät gefunden". Fände ich schöner, als die derzeitige Lösung und wäre wahrscheinlich leicht zu lösen. Später können wir dann einen Dialog einbauen.
Habe die Stelle mal gemarkert, an der das einzubauen wäre. Wir bräuchten dann noch eine spezielle Rückmeldung dazu (ist easy) und den Willen, das auf die Art umzusetzen. Bin selbst unentschlossen, aber die Mehrheit scheint eher für "keine numerische Rückmeldung" zu sein. Was mir an der "keine Info"-Lösung nicht gefällt: sie gibt keine Alternative zur Auswahl. Das erscheint mir nicht als motivierend.

Zitat
Bzgl. der "kind"-Sache kannst du gerne den Link haben. Es hat mir bis dato aber niemand geantwortet. https://community.rhasspy.org/t/what-is-slots-value-kind-for/2610 (https://community.rhasspy.org/t/what-is-slots-value-kind-for/2610)
Thx; evtl. hänge ich mich da mit dran und versuche mal das dahinterliegende Problem zu erläutern.
Zitat
Ansonsten weiß ich gerade nicht, was du mit subtype vor hast und wofür wir das brauchen könnten.
Ist im Moment auch nur ein diffuses Bauchgefühl, dass man "sowas" brauchen könnte. Schwierig zu erklären, wo das Bauchgefühl herkommt, ist nur nicht ganz selten eine gute Idee, es zu beachten...

Zitat
Zu den Bestätigungsdialogen: Überhaupt keine Priorität für mich derzeit.
Nachvollziehbar.

Zitat
gDTs sind cool, da weiter zu bauen fände ich schon interessant. Da würde ich aber sagen, wir halten uns an die minimalen FHEM-Vorgaben was Setter betrifft. Für z.B. AV-Geräte gibt's ja das hier: https://wiki.fhem.de/wiki/DevelopmentGuidelinesAV (https://wiki.fhem.de/wiki/DevelopmentGuidelinesAV). Unterstützt ein Gerät einen definierten Befehl nicht, Pech gehabt.
Das "Problem" bei den "minimalen" FHEM-Vorgaben ist folgendes: Es sind keine "minimalen" setter, die immer da sind, sondern nur der zusammengefasste Konsens, wie diese setter heißen sollten WENN sie (funktional gesehen) vorhanden sind.
Die eigentliche Aufgabe ist also, nur das zu mappen, was auch da ist. Das rauszufinden, ist gar nicht so schwierig, getAllSets() liefert einem das frei Haus (oder jsonlist2 etc.).
Das wäre also eine Verbesserung innerhalb des bestehenden Codes ;) .

Zitat
Lightscenes werden wir nicht abbilden können, weil wir ja nicht wissen, wie die heißen.
Doch, wissen wir (bzw. können wir abfragen): mittels getAllSets(). Das Unschöne daran ist nur, dass das eher "technische" Namen sind, von denen wir nicht wissen, ob sie gut auszusprechen sind.

Zitat
Bei Farbe und -Temperatur war ich eigentlich der Meinung, dass das auch in FHEM normiert ist. Kann mich da aber täuschen. Wir setzen einfach rgb (oder was halt Standard ist) und ct. Wenn's ein Gerät nicht kann, wieder Pech.
Wieder wie oben: es ist m.E. nicht zielführend, Kommandos zuzulassen, die effektiv doch nicht da sind. Und wenn sie da sind: rgb ist noch relativ eindeutig, aber auch da ist es afaik nicht immer in Großschreibung... Ganz davon abgesehen, dass wir dafür grade noch kein RHASSPY-Kommando/intent haben. Color ist "irgendwie anders".
Und der Wertebereich für CT ist afaik wirklich näherungsweise willkürlich, aber eine wissentschaftliche Analyse habe ich dazu nicht vorzuweisen. Auch hier: wir haben noch keine Kommandos/intents...

ZitatIch hab am Anfang der 10_RHASSPY.pm noch ein paar Punkte:
Sorry, war mir entgangen, meine stehen kurz nach __END__...
- Training verzögern: Muss ich mir in Ruhe ansehen. Aber eigentlich haben wir ja die Rückmeldung, wenn updateSlots durch ist, oder? Es wir ja ein Reading gesetzt. Ergo müßte man an der Stelle dann auch ein (in dem vorherigen Aufruf gesetztes, ggf. verstecktes) Internal abfragen können.

(ungetestet, auf der RHASSPY-Seite) erledigt sollten sein:
- textField für rhasspyGroup;
- State statt Status und "GetState";
- (englische) fehlende Kanal-Meldung;
- Shortcuts:
-- d statt n;
-- initialized-Warning;

"Longpoll" muss ich mir ansehen.

"Timer auf 10:15": Kommt darauf an, wie lange es noch dahin ist. Die Rückmeldung in Sekunden/Minuten erfolgt nur, wenn die Zeit bis dahin eher kurz ist, und da finde ich persönlich das sehr viel intuitiver, wenn ich "klingelt in 10 Minuten" zurückbeckomme wie "... um 10:15 Uhr".
Klar, Geschmacksfrage, und über die Grenzsetzungen bei der jeweiligen Abgrenzung können wir uns gerne unterhalten, evtl. könnte man das sogar konfigurierbar machen. Das war ein erster Schuss, und genau deswegen hatte ich ja auch speziell zum Thema Timer immer wieder gefragt, ob das jetzt allgemein als "gut" angesehen wird...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 13 April 2021, 17:03:54
Zitat von: Beta-User am 13 April 2021, 15:24:03
ZitatZitat von: drhirn am Heute um 14:14:32

    Zuerst muss ich aber sagen, dass ich bis 29. gerne eine Feature-Freeze hätte. Prio muss jetzt Testen, Testen, Bugfixing, Doku und Testen haben.

Sehe ich auch so. Wenn, dann geht es vorrangig erst mal um Verbesserung der vorhandenen features.

Nicht mal das. Dann muss ich nur wieder von vorne testen.

Zitat
ZitatAd "kein "match in room" bei GetNumeric": Andere Alternative wäre: "Kein passendes Gerät gefunden". Fände ich schöner, als die derzeitige Lösung und wäre wahrscheinlich leicht zu lösen. Später können wir dann einen Dialog einbauen.
Habe die Stelle mal gemarkert, an der das einzubauen wäre. Wir bräuchten dann noch eine spezielle Rückmeldung dazu (ist easy) und den Willen, das auf die Art umzusetzen. Bin selbst unentschlossen, aber die Mehrheit scheint eher für "keine numerische Rückmeldung" zu sein. Was mir an der "keine Info"-Lösung nicht gefällt: sie gibt keine Alternative zur Auswahl. Das erscheint mir nicht als motivierend.

Ist es auch nicht. Aber für den Moment, denke ich, können wir damit leben.

Zitat
ZitatgDTs sind cool, da weiter zu bauen fände ich schon interessant. Da würde ich aber sagen, wir halten uns an die minimalen FHEM-Vorgaben was Setter betrifft. Für z.B. AV-Geräte gibt's ja das hier: https://wiki.fhem.de/wiki/DevelopmentGuidelinesAV. Unterstützt ein Gerät einen definierten Befehl nicht, Pech gehabt.
Das "Problem" bei den "minimalen" FHEM-Vorgaben ist folgendes: Es sind keine "minimalen" setter, die immer da sind, sondern nur der zusammengefasste Konsens, wie diese setter heißen sollten WENN sie (funktional gesehen) vorhanden sind.
Die eigentliche Aufgabe ist also, nur das zu mappen, was auch da ist. Das rauszufinden, ist gar nicht so schwierig, getAllSets() liefert einem das frei Haus (oder jsonlist2 etc.).
Das wäre also eine Verbesserung innerhalb des bestehenden Codes ;) .
Ah, das wusste ich nicht. Dann ab auf die ToDo-Liste ;)

Zitat
ZitatLightscenes werden wir nicht abbilden können, weil wir ja nicht wissen, wie die heißen.
Doch, wissen wir (bzw. können wir abfragen): mittels getAllSets(). Das Unschöne daran ist nur, dass das eher "technische" Namen sind, von denen wir nicht wissen, ob sie gut auszusprechen sind.
Ja, das auch. Könnte man aber auch dem User überlassen, die hübsch zu benennen.

ZitatSorry, war mir entgangen, meine stehen kurz nach __END__...
Oh, die hab ich übersehen :D

Zitat- Training verzögern: Muss ich mir in Ruhe ansehen. Aber eigentlich haben wir ja die Rückmeldung, wenn updateSlots durch ist, oder? Es wir ja ein Reading gesetzt. Ergo müßte man an der Stelle dann auch ein (in dem vorherigen Aufruf gesetztes, ggf. verstecktes) Internal abfragen können.
Stimmt, das Reading wäre da. Egal, keine Priorität. Die jetzige Lösung funktioniert ja.

Zitat- textField für rhasspyGroup;
Leider nicht

Zitat- State statt Status und "GetState";
8)

Zitat- (englische) fehlende Kanal-Meldung;
Kann ich nicht mehr testen. Rhasspy liefert immer einen existierenden Kanal, egal was ich sage. Weiß nicht, warum plötzlich.

Zitat
- Shortcuts:
-- d statt n;
-- initialized-Warning;
8)

Zitat"Timer auf 10:15": Kommt darauf an, wie lange es noch dahin ist. Die Rückmeldung in Sekunden/Minuten erfolgt nur, wenn die Zeit bis dahin eher kurz ist, und da finde ich persönlich das sehr viel intuitiver, wenn ich "klingelt in 10 Minuten" zurückbeckomme wie "... um 10:15 Uhr".
Ahhhh, dachte mir doch, das ist nicht ganz konsistent. Jetzt weiß ich auch, warum. :D

ZitatKlar, Geschmacksfrage, und über die Grenzsetzungen bei der jeweiligen Abgrenzung können wir uns gerne unterhalten, evtl. könnte man das sogar konfigurierbar machen. Das war ein erster Schuss, und genau deswegen hatte ich ja auch speziell zum Thema Timer immer wieder gefragt, ob das jetzt allgemein als "gut" angesehen wird...
ToDo-Liste
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 13 April 2021, 17:24:06
Zitat von: drhirn am 13 April 2021, 17:03:54
Ah, das wusste ich nicht. Dann ab auf die ToDo-Liste ;)
Nur nicht hetzen...!

Zitat
Ja, das auch. Könnte man aber auch dem User überlassen, die hübsch zu benennen.
Na ja, bei meinem Receiver geht das schon mal nicht, jedenfalls, wenn ich das Handbuch richtig gelesen habe.
Und "sprechbare" Szenennamen hätten vermutlich häufig auch Leerzeichen drin. Das geht dann vermutlich auch nicht so einfach...

Zitat
Leider nicht
Ähm, vermutlich, weil das Attribut in der global-Liste drin steht; einmal drin, immer drin. Für "neue" sollte es jetzt aber passen.

ZitatKann ich nicht mehr testen. Rhasspy liefert immer einen existierenden Kanal, egal was ich sage. Weiß nicht, warum plötzlich.
Na ja, vermutlich war das Training erfolgreich, und du musst den slot manuell "kaputt" machen...

Zitat
Ahhhh, dachte mir doch, das ist nicht ganz konsistent. Jetzt weiß ich auch, warum. :D
ToDo-Liste
Was genau? Bzw. wie soll es genau sein?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 13 April 2021, 17:28:08
Zitat von: Beta-User am 13 April 2021, 17:24:06
ZitatAhhhh, dachte mir doch, das ist nicht ganz konsistent. Jetzt weiß ich auch, warum. :D
ToDo-Liste
Was genau? Bzw. wie soll es genau sein?

Naja, manchmal hat mir Rhasspy Sekunden ausgegen, manchmal die Uhrzeit. Also wie von dir geplant. Wusste das nur nicht.

Verbesserungen daran auf die ToDo-Liste. Mir persönlich würde es besser gefallen, wenn ich bei einem Timer mit Uhrzeit auch die Uhrzeit zurück bekomme. Aber ich richte mich nach der Mehrheit. Bzw. bei einem 1:1 nach dir ;)
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 13 April 2021, 17:36:58
Na ja, das "Problem" ist, dass man sich bei "absoluten" Angaben dann merken müßte, dass es eine solche war und das entsprechend gesondert behandeln. Im Moment wird "stumpf" die Differenz betrachtet.

Aber eigentlich finde ich die kleine Irritation wegen der "anderen" Rückmeldung ganz ok, weil man damit auch mitbekommt, wenn es "gleich" ist (was man ggf. gar nicht gedacht hatte).
Aber wenn es Wünsche gibt, das konfigurierbar zu machen, schaue ich mir das bei Gelegneheit mal im Detail an; an sich sollte sich das ggf. sogar getrennt konfigurieren lassen. ("tweaks"...)
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 13 April 2021, 17:54:25
Zitat von: Beta-User am 13 April 2021, 17:36:58
Na ja, das "Problem" ist, dass man sich bei "absoluten" Angaben dann merken müßte, dass es eine solche war und das entsprechend gesondert behandeln. Im Moment wird "stumpf" die Differenz betrachtet.

Wir hätten ja "Hourabs"

ZitatAber eigentlich finde ich die kleine Irritation wegen der "anderen" Rückmeldung ganz ok, weil man damit auch mitbekommt, wenn es "gleich" ist (was man ggf. gar nicht gedacht hatte).
Aber wenn es Wünsche gibt, das konfigurierbar zu machen, schaue ich mir das bei Gelegneheit mal im Detail an; an sich sollte sich das ggf. sogar getrennt konfigurieren lassen. ("tweaks"...)

Es ist sowas von gar nicht wichtig. Wenn dir mal langweilig ist.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 13 April 2021, 22:16:00
Sodale...

Jetzt sollte das Training erst anlaufen, wenn der slot-update als erfolgreich zurückgemeldet wird.

Timer habe ich mir auch angesehen und ein bißchen was vorbereitet:
Die Zeiten stecken jetzt in einem Array (#3172), das man ggf. dann mit einem aus der User-Späre vergleichen könnte. 4 Elemente wären als Zeitgrenzen gedacht: 0-3 entsprechen den Grenzen für die Stufen 0-3 aus "timerSet" (Sprach-Hash), Element 4 wäre die Grenze (in Sekunden), ab wann die Uhrzeit statt der "Zeit bis" angesagt werden würde.
Derzeitige Grenzen:
my @timerlimits = $hash->{helper}->{timerLimits} // (101, 9*MINUTESECONDS, HOURSECONDS, 3*HOURSECONDS,3*HOURSECONDS );
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 14 April 2021, 08:08:54
Weil im Demo-FHEM auch ein sunRise Device vorkommt, dachte ich mir, das wäre eigentlich ein guter Anschauungspunkt für Shortcuts.

Bekommen wir das hin, dass so ein Shortcut funktioniert?

i="wann geht die sonne auf" f="" r="um [Astro:sunRise] uhr"

Derzeit wird mir die Response einfach vorgelesen (voiceResponse: um [Astro:sunRise] uhr).
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 14 April 2021, 08:29:40
Bzgl. rhasspyGroup und textfield-long

Zitat von: Beta-User am 13 April 2021, 17:24:06
Ähm, vermutlich, weil das Attribut in der global-Liste drin steht; einmal drin, immer drin. Für "neue" sollte es jetzt aber passen.

Was meinst du mit "neue"? Neue FHEM-Installationen?
Ich hab nämlich gerade ein neues Device angelegt und hab noch immer das textfield-long.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 14 April 2021, 08:35:23
Ja, "frisches" global (oder gesäubertes ;) ).

Zitat von: drhirn am 14 April 2021, 08:08:54
Weil im Demo-FHEM auch ein sunRise Device vorkommt, dachte ich mir, das wäre eigentlich ein guter Anschauungspunkt für Shortcuts.

Bekommen wir das hin, dass so ein Shortcut funktioniert?

i="wann geht die sonne auf" f="" r="um [Astro:sunRise] uhr"

Derzeit wird mir die Response einfach vorgelesen (voiceResponse: um [Astro:sunRise] uhr).
Guter Gedanke, eventuell müssen wir das aber im Detail anders lösen. Mal schauen.

Ich glaube, der timerLimits-Code sollte auch passen, kurze cref (rhasspyTweaks) dazu ist auch drin, siehe Anhang. Was mir noch nicht 100% gefällt sind "Null"-Ansagen, z.B. wenn man den Wecker auf ganze Stunden stellt... Das ist aber nicht neu dazu gekommen.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 14 April 2021, 08:51:46
Warum antworten wir nicht wirklich einfach mit 12 Uhr 15, wenn Hourabs vorhanden ist? Dem, der den Timer so setzt, ist ja im Normalfall wurscht, wie viel Minuten und Sekunden es bis dahin sind. Also, mir zumindest.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 14 April 2021, 08:56:19
Aber, die rhasspyTweaks bzgl. Timer funktionieren. Und wenn ich die letzte Zahl auf 0 stelle (oder die erste), hab ich genau das, was ich will ;)
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 14 April 2021, 10:17:12
Zitat von: drhirn am 14 April 2021, 08:56:19
Aber, die rhasspyTweaks bzgl. Timer funktionieren. Und wenn ich die letzte Zahl auf 0 stelle (oder die erste), hab ich genau das, was ich will ;)
:) .

Wie schon mehrfach geschrieben: wir können gerne über die im Modul vercodeten defaults diskutieren, die "Nullwerte" würde ich aber gerne an beiden Stellen vermeiden wollen, sonst hagelt es vermutlich nur Beschwerden über den vermeintlich "dummen" Code...

Zitat von: Beta-User am 14 April 2021, 08:35:23
Guter Gedanke, eventuell müssen wir das aber im Detail anders lösen. Mal schauen.
Lösungsvorschlag für das Detail: Alle response-Werte gehen nochmal durch "RHASSPY_ReplaceReadingsVal()", es muss nur einer der Parameter p, f oder r angegeben werden.
Gültig ist daher auch:
i="wann geht die sonne auf" r="um [Astro:sunRise] uhr"

Kurz angetestet, scheint zu funktionieren, cref ist dahingehend aktualisiert.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 14 April 2021, 10:30:57
Zitat von: Beta-User am 14 April 2021, 10:17:12Wie schon mehrfach geschrieben: wir können gerne über die im Modul vercodeten defaults diskutieren

Das ist schon ok so. Kann sich ja jeder einstellen, wie er will.

Zitat
Lösungsvorschlag für das Detail: Alle response-Werte gehen nochmal durch "RHASSPY_ReplaceReadingsVal()", es muss nur einer der Parameter p, f oder r angegeben werden.
Gültig ist daher auch:
i="wann geht die sonne auf" r="um [Astro:sunRise] uhr"

Kurz angetestet, scheint zu funktionieren, cref ist dahingehend aktualisiert.

Hmm, kann ich leider nicht bestätigen. Hab das Modul neu geladen, FHEM neu gestartet, update devicemap gemacht. Aber trotzdem wird mir noch die eckige Klammer vorgelesen. Hab ich was vergessen?

Mah, fies! Das Reading heißt gar nicht sunRise. Sondern SunRise. Damit geht's.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 14 April 2021, 10:50:41
Zitat von: drhirn am 14 April 2021, 10:30:57
Das ist schon ok so. Kann sich ja jeder einstellen, wie er will.
Na ja, meine Vorstellung wäre, dass man was voreinstellt, das erst mal als "mehrheitsfähig" durchgehen könnte. Die 3 Stunden für absolute Zeitangaben sind relativ lang, sehe ich auch so, kommt halt aus dem Ursprungscode. Vorschlag wäre, das (5. Parameter) auf eine Stunde (HOURSECONDS) voreinzustellen.
Unklar ist mir noch, was passiert, wenn man "nichts" bzw. nichtnummerische Werte angibt, wäre gut, wenn du das testen könntest.

ZitatMah, fies! Das Reading heißt gar nicht sunRise. Sondern SunRise. Damit geht's.
Bitte auch in der cref anpassen.

Btw.: Das war ein erfüllter feature-request, und die sollte es doch eigentlich vor dem 29. gar nicht geben ;D ...

Ansonsten habe ich auch "drumrum" die offenen Punkte noch ergänzt etc.. Würde vorschlagen, "meine" Stelle zu nutzen, da kann man den Text freier schreiben.
Einen hatte ich auf der Shortlist vergessen, nämlich das Abspielen von einer WAV bei Wecker-Ende.
Muss mal schauen, wie ich Rhasspy dazu bewegen kann, die "bin bereit"-etc-Sounds abzuspielen, dann geht's ggf. an der Stelle weiter...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 14 April 2021, 10:58:03
Zitat von: Beta-User am 14 April 2021, 10:50:41
Bitte auch in der cref anpassen.

Erledigt.

ZitatBtw.: Das war ein erfüllter feature-request, und die sollte es doch eigentlich vor dem 29. gar nicht geben ;D ...

Ja, haha, verdammt, erwischt ;D
Aber immerhin einer mit direktem Bezug auf den 29. ;)

ZitatWürde vorschlagen, "meine" Stelle zu nutzen, da kann man den Text freier schreiben.

Stimmt. Am Anfang sieht man's allerdings besser. V.a. weil die CRef bei mir hellgrau auf weißem Hintergrund ist. Aber ich kann damit leben. Meine Punkte sind eh abgearbeitet.

Zitat
Einen hatte ich auf der Shortlist vergessen, nämlich das Abspielen von einer WAV bei Wecker-Ende.
Muss mal schauen, wie ich Rhasspy dazu bewegen kann, die "bin bereit"-etc-Sounds abzuspielen, dann geht's ggf. an der Stelle weiter...

Die WAV byte für byte an "hermes/audioServer/<siteId>/playBytes/<beliebige SessionID>" schicken. Hätte mir gedacht, wir nehmen playWAV dafür.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 14 April 2021, 11:01:49
Zitat von: Beta-User am 14 April 2021, 10:50:41
Na ja, meine Vorstellung wäre, dass man was voreinstellt, das erst mal als "mehrheitsfähig" durchgehen könnte. Die 3 Stunden für absolute Zeitangaben sind relativ lang, sehe ich auch so, kommt halt aus dem Ursprungscode. Vorschlag wäre, das (5. Parameter) auf eine Stunde (HOURSECONDS) voreinzustellen.
Unklar ist mir noch, was passiert, wenn man "nichts" bzw. nichtnummerische Werte angibt, wäre gut, wenn du das testen könntest.

timerLimits=90,300,3000,2*HOURSECONDS,x
Zitat
PERL WARNING: Use of uninitialized value in numeric lt (<) at ./FHEM/10_RHASSPY.pm line 3160.
PERL WARNING: Use of uninitialized value in numeric lt (<) at ./FHEM/10_RHASSPY.pm line 3162.
PERL WARNING: Use of uninitialized value in numeric lt (<) at ./FHEM/10_RHASSPY.pm line 3169.

Fehlt eine Zahl, bekomme ich ein FHEM-Popup mit
Zitatin timerLimits=300,3000,2*HOURSECONDS,0, 5 comma separated values have to be provided
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 14 April 2021, 11:12:06
Ok, die Warnings sind unschön, geben aber dem "kundigen Leser" einen Hinweis auf die Ursache. Paßt m.E. soweit. Dass der Code wenigstens vorab die Zahl der Argumente checkt, ist "klar" ;) . Die Frage war eher, ob man das noch verbessern muss, um Abstürze zu vermeiden.

Der "nichts"-Test, um das abschließend zu klären, sähe dann noch z.B. so aus:
timerLimits=90,,,,xEs sollten dann eigentlich auch nur wieder "nur" Warnings kommen.

Zitat von: drhirn am 14 April 2021, 10:58:03
Stimmt. Am Anfang sieht man's allerdings besser. V.a. weil die CRef bei mir hellgrau auf weißem Hintergrund ist. Aber ich kann damit leben. Meine Punkte sind eh abgearbeitet.
Ja, hängt vom Editor ab (bzw. dessen "Spracheinstellung"). "Abgearbeitet" ist auch das mit dem fehlenden Trigger? Wenn nein, wäre das m.E. noch wichtig.

Zitat
Die WAV byte für byte an "hermes/audioServer/<siteId>/playBytes/<beliebige SessionID>" schicken. Hätte mir gedacht, wir nehmen playWAV dafür.
playWAV wäre schon das Mittel der Wahl, ich habe es nur bisher nicht geschafft, mein Handy per Ton bimmeln zu lassen, Sprache klappt 1a...
(Und einen superhypermodernen Pi (im Vergleich zu meinem Altbestand) wollte ich erst mal noch ins Netz hängen ;D ).
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 14 April 2021, 13:29:56
Zitat von: Beta-User am 14 April 2021, 11:12:06
Der "nichts"-Test, um das abschließend zu klären, sähe dann noch z.B. so aus:
timerLimits=90,,,,xEs sollten dann eigentlich auch nur wieder "nur" Warnings kommen.

Jup, wäre wohl sinnvoller gewesen.
Da bekomme ich keine Warning/Errors, etc. Funktioniert einfach.

Zitat"Abgearbeitet" ist auch das mit dem fehlenden Trigger? Wenn nein, wäre das m.E. noch wichtig.
Du meinst den bei Shortcuts + Perl-Code? Das geht nämlich.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 14 April 2021, 13:36:39
OK, dann gilt also numerisch "undef==0". Mal sehen, wann da wer drüberstolpert...

Anbei eine "cleanup" Version, bei der dann "deine" offenen Punkte raus sind. "Eigentlich" ist am Code nichts geändert, aber wie immer: Fehler sind nicht komplett ausgeschlossen...

Die Limits habe ich mal auf "(91, 9*MINUTESECONDS, HOURSECONDS, 1.5*HOURSECONDS, HOURSECONDS )" gesetzt. Falls das Gefallen findet, würde ich vorschlagen, das als default-Werte dann auch in der cref zu nennen, dann findet man es auch wieder und es ist besser klar, dass die FHEM-Zeitkonstanten verfügbar sind.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 14 April 2021, 13:50:52
Gut, gut, gut!
Die Version ist jetzt die Version 0.4.8 und auch die Default-Branch. Ich ernenne die Version hiermit zu stable.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 14 April 2021, 16:03:57
Mein Plan ist wie folgt:

Wir testen noch SetNumeric durch. Das ist der letzte Intent, der noch offen ist. Klappt da alles (wovon ich derzeit ausgehe), geb ich eine Runde Bier aus und mach eine Version 1.0.0. Mit der wird dann die Präsentation gemacht. Was uns aber nicht daran hindern soll, an einer 1.0.1 weiter zu arbeiten.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 14 April 2021, 16:52:49
...das mit dem Bier klingt gut!

1.0.0 ist aber ein "gewaltiger Schritt", lirc ist ja auch erst bei 0.10.0rc1 ;) , und ASC ist auch noch bei 0.10.0....

Wie auch immer: diese Version ist m.E. jedenfalls die, mit der wir für den 29. ganz gut "unterwegs" sein sollten.

Ob ihr's glaubt oder nicht, ich habe (erst) jetzt dann auch mal die Zeit gefunden, den "RHASSPY & FHEM"-Thread nochmal zu durchstöbern. Hier mal meine (um eigene Schlagworte ergänzte) Stichwortliste - ist eine wilde Mischung aus Ideen bzw. potentiellen ToDo's, offenen Enden und Fragen, teils vermutlich auch für den 29. nicht uninteressant:

- SetOnOff: Bestätigung welches Gerät wie geschaltet wurde (derzeit: User-Code bei rhasspyMapping)
- Talk2FHEM, Jabber, Telegram: Schnittstellen, Zusammenspiel (+msg-Kommando?)
- Wikipedia, google und andere "offene" Anfragen an die Weiten des Inet (Vorfrage: wie "trainierte" Stichworte generieren?)
- Bring! und andere Einkaufslisten
- Ansagen für ausstehende Timer
- zufällige Ansagen oder Rückmeldungen (oder: mal was anderes statt "OK")
- CustomIntents: Code in eigene .pm verlagern?

Gerade der letzte Punkt wäre auch im Rahmen der Idee interessant, das ganze "Beiwerk" auch längerfristig via contrib anzubieten. Würde aber vorschlagen, entsprechenden Code dann auch zu packagen. (@Mitleser: keine Sorge, das ist nicht allzu schwierig! Ordentlich formatierter Code, der mal perlcritic.com gesehen hat, wäre aber als Voraussetzung wünschenswert...)
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 14 April 2021, 17:18:15
Zitat von: Beta-User am 14 April 2021, 16:52:49
...das mit dem Bier klingt gut!

Haben wir uns auch verdient

Zitat1.0.0 ist aber ein "gewaltiger Schritt", lirc ist ja auch erst bei 0.10.0rc1 ;) , und ASC ist auch noch bei 0.10.0....
Das sind ja auch alles Feiglinge ;D

Meine Logik ist eigentlich die:
x.0.0 - Große Stable-Versionen (Änderung der Stelle bringt sehr wahrscheinlich Inkompatibilitäten mir vorigen Versionen)
x.x.0 - Kleine Stable-Versionen (Kleine bis keine Inkompatibilitäten)
x.x.x - Bug-Fix-Versionen (Keine Inkompatibilitäten)
x.x.x.x - Entwicklungs-Versionen

Hab ich zwar noch nie so durchgezogen, würde aber Sinn machen ;)

Zitat- SetOnOff: Bestätigung welches Gerät wie geschaltet wurde (derzeit: User-Code bei rhasspyMapping)

Würde ich fast so lassen. Dann hat der User die Wahl. Oder ein zusätzliches Attribut/Mapping beim Device.

Zitat- Talk2FHEM, Jabber, Telegram: Schnittstellen, Zusammenspiel (+msg-Kommando?)

Hatte ich bei Snips in Kombination mit Talk2FHEM. Aber leider die Devices gelöscht. Hab aber einfach alles, was an hermes/asr/textCaptured ankam, zu T2F geschickt.
Sehe ich aber nicht als Rhasspy-Thema.

Zitat- Wikipedia, google und andere "offene" Anfragen an die Weiten des Inet (Vorfrage: wie "trainierte" Stichworte generieren?)
- Bring! und andere Einkaufslisten

Nein! Hat níchts mit FHEM zu tun. Wie schon mal erwähnt, ist da ein Rhasspy-"Modul" der bessere Weg. Weil dann auch Nicht-FHEM-User davon profitieren könnten.

Zitat- Ansagen für ausstehende Timer

Hohe Prio! "Wie lange noch" geht mir mächtig ab.

Zitat- zufällige Ansagen oder Rückmeldungen (oder: mal was anderes statt "OK")

Täte mir auch gefallen. Geht aber theoretisch eh schon mittels "response" und "rand()"

Zitat
- CustomIntents: Code in eigene .pm verlagern?

Gerade der letzte Punkt wäre auch im Rahmen der Idee interessant, das ganze "Beiwerk" auch längerfristig via contrib anzubieten.

Dafür
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 14 April 2021, 17:30:01
SetNumeric:

Hab ich kein passendes Mapping, bekomme ich 2x einen Hinweis darauf als Antwort. Warum dies?


2021.04.14 17:27:56.823 5: RHASSPY: [Rhasspy] Parse (IO: rhasspyMQTT2): Msg: hermes/intent/de.fhem_SetNumeric => {"input": "stelle die lautstärke vom fernseher im schlafzimmer auf 50", "intent": {"intentName": "de.fhem:SetNumeric", "confidenceScore": 1.0}, "siteId": "wohnzimmer", "id": null, "slots": [{"entity": "de.fhem.Device", "value": {"kind": "Unknown", "value": "fernseher"}, "slotName": "Device", "rawValue": "fernseher", "confidence": 1.0, "range": {"start": 26, "end": 35, "rawStart": 26, "rawEnd": 35}}, {"entity": "de.fhem.Room", "value": {"kind": "Unknown", "value": "schlafzimmer"}, "slotName": "Room", "rawValue": "schlafzimmer", "confidence": 1.0, "range": {"start": 39, "end": 51, "rawStart": 39, "rawEnd": 51}}, {"entity": "rhasspy/number", "value": {"kind": "Number", "value": 50}, "slotName": "Value", "rawValue": "fünfzig", "confidence": 1.0, "range": {"start": 56, "end": 58, "rawStart": 56, "rawEnd": 63}}], "sessionId": "wohnzimmer-snowboy-5301253b-8999-4458-9ab3-79316eaaacc1", "customData": "snowboy", "asrTokens": [[{"value": "stelle", "confidence": 1.0, "rangeStart": 0, "rangeEnd": 6, "time": null}, {"value": "die", "confidence": 1.0, "rangeStart": 7, "rangeEnd": 10, "time": null}, {"value": "lautstärke", "confidence": 1.0, "rangeStart": 11, "rangeEnd": 21, "time": null}, {"value": "vom", "confidence": 1.0, "rangeStart": 22, "rangeEnd": 25, "time": null}, {"value": "fernseher", "confidence": 1.0, "rangeStart": 26, "rangeEnd": 35, "time": null}, {"value": "im", "confidence": 1.0, "rangeStart": 36, "rangeEnd": 38, "time": null}, {"value": "schlafzimmer", "confidence": 1.0, "rangeStart": 39, "rangeEnd": 51, "time": null}, {"value": "auf", "confidence": 1.0, "rangeStart": 52, "rangeEnd": 55, "time": null}, {"value": "50", "confidence": 1.0, "rangeStart": 56, "rangeEnd": 58, "time": null}]], "asrConfidence": null, "rawInput": "stelle die lautstärke vom fernseher im schlafzimmer auf fünfzig", "wakewordId": "snowboy", "lang": null}
2021.04.14 17:27:56.823 5: Parsed value: wohnzimmer-snowboy-5301253b-8999-4458-9ab3-79316eaaacc1 for key: sessionId
2021.04.14 17:27:56.823 5: Parsed value: SetNumeric for key: intent
2021.04.14 17:27:56.823 5: Parsed value: stelle die lautstärke vom fernseher im schlafzimmer auf fünfzig for key: rawInput
2021.04.14 17:27:56.824 5: Parsed value: stelle die lautstärke vom fernseher im schlafzimmer auf 50 for key: input
2021.04.14 17:27:56.824 5: Parsed value: 1 for key: probability
2021.04.14 17:27:56.824 5: Parsed value: schlafzimmer for key: Room
2021.04.14 17:27:56.824 5: Parsed value: wohnzimmer for key: siteId
2021.04.14 17:27:56.824 5: Parsed value: 50 for key: Value
2021.04.14 17:27:56.824 5: Parsed value: fernseher for key: Device
2021.04.14 17:27:56.825 5: handleIntentSetNumeric called
2021.04.14 17:27:56.825 5: Device selected (by hash, with room and name): FernseherSZ
2021.04.14 17:27:56.825 5: Response is: Tut mir leid, aber ich konnte kein passendes Mäpping finden
2021.04.14 17:27:56.826 5: Response is: Tut mir leid, aber ich konnte kein passendes Mäpping finden


(und weiß einer, warum mir das FHEM-Log keine Umlaute mehr anzeigt?)
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 14 April 2021, 17:55:57
Zitat von: drhirn am 14 April 2021, 17:18:15
Haben wir uns auch verdient
:) Unbedingt!

Zitat
Das sind ja auch alles Feiglinge ;D
Du bist der Boss!

ZitatMeine Logik ist eigentlich die:
x.0.0 - Große Stable-Versionen (Änderung der Stelle bringt sehr wahrscheinlich Inkompatibilitäten mir vorigen Versionen)
Hoffen wir mal, dass es nicht erforderlich wird, irgendwas zu brechen. Die höchste Wahrscheinlichkeit für sowas sehe ich im Moment bei Color/Media. Daher mag ich auch die "1" vorne noch nicht...

Zitat
Würde ich fast so lassen. Dann hat der User die Wahl. Oder ein zusätzliches Attribut/Mapping beim Device.
Gehört m.E. nach "Specials". Hatte erst gedacht, dass das da ein Format "Confirmation:..." geben sollte, aber im Moment denke ich eher, das wird in Richtung
"SetOnOff:v=on,off c="Soll ich $NAME $newVal schalten" r="habe $NAME auf $newVal gestellt"
(Wir werden wohl dazu noch einige Übersetzungshilfswerte brauchen).

Zitat
Hatte ich bei Snips in Kombination mit Talk2FHEM. Aber leider die Devices gelöscht. Hab aber einfach alles, was an hermes/asr/textCaptured ankam, zu T2F geschickt.
Sehe ich aber nicht als Rhasspy-Thema.
Habe noch kein genaues Bild vom ganzen; irgendwas pauschal durchzureichen, finde ich auf den ersten Blick nicht so spannend, das wäre dann ggf. ein Thema für "forceNEXT" und ein separates M2D?

Zitat
Nein! Hat níchts mit FHEM zu tun. Wie schon mal erwähnt, ist da ein Rhasspy-"Modul" der bessere Weg. Weil dann auch Nicht-FHEM-User davon profitieren könnten.
Den Einwand habe ich gelesen, aber bis dato nicht verstanden (und das auch noch nicht versucht).

Zitat
Hohe Prio! "Wie lange noch" geht mir mächtig ab.
Guter Kandidat für einen (übergangsweisen) CustomIntent. Vielleicht kann das jemand anderes an die neuen Timer-Namen anpassen?

Zitat
Täte mir auch gefallen. Geht aber theoretisch eh schon mittels "response" und "rand()"
Das wäre (auf Basis meiner Anmerkungen zu "Witze") m.E. ein guter Kandidat für das 1. "add-on" in contrib...

Meine persönliche Prio (und das Interesse ;) ) liegt eher auf dem dialogischen und "matches outside".

@all: Wenn ich das richtig deute, haben einige wenige die aktuellste Fassung runtergeladen. Falls ihr die auch einsetzt: Feedback "aus dem Feld" wäre willkommen, damit wir ggf. eventuelle Probleme noch identifiziert bekommen.
Falls jemand was in den "Listen" besonders gerne umgesetzt hätte: Wünsche äußern ist erlaubt...




Ad SetNumeric:
#2569ff muss vermutlich so lauten; der "response"-Teil ist danach nochmal drin bzw. reingekommen wegen der "Group"-Geschichte:
if ( !defined $mapping ) {
        if ( defined $data->{'.inBulk'} ) {
            #Beta-User: long forms to later add options to check upper/lower limits for pure on/off devices
            return;
        } #else {
        #    return RHASSPY_respond ($hash, $data->{requestType}, $data->{sessionId}, $data->{siteId}, RHASSPY_getResponse($hash, 'NoMappingFound'));
        #}
    }

(Das "return" hatte gefehlt; die Frage ist, ob man den Code dann doch (mit return) aktiv läßt...)
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 14 April 2021, 18:29:56
Zitat von: Beta-User am 14 April 2021, 17:55:57
Hoffen wir mal, dass es nicht erforderlich wird, irgendwas zu brechen. Die höchste Wahrscheinlichkeit für sowas sehe ich im Moment bei Color/Media. Daher mag ich auch die "1" vorne noch nicht...
Na guuuut, dann wird's halt 0.5.0. Ist eh eine coole Zahl. :D

ZitatGehört m.E. nach "Specials". Hatte erst gedacht, dass das da ein Format "Confirmation:..." geben sollte, aber im Moment denke ich eher, das wird in Richtung
"SetOnOff:v=on,off c="Soll ich $NAME $newVal schalten" r="habe $NAME auf $newVal gestellt"
Ja, gute Idee mit "rhasspySpecials"

ZitatDen Einwand habe ich gelesen, aber bis dato nicht verstanden (und das auch noch nicht versucht).
Nun, ich kann ja MQTT-Messages in welcher Sprache auch immer abgreifen. Python würde sich im Falle Rhasspy anbieten. Und da läuft dann halt ein kleines Python-Script irgendwo, dass auf den Intent "Wikipedia" wartet. Kommt der daher, wird er abgehandelt. Das selbe, was wir jetzt ja auch machen.
Bei Snips gab's eine "Web-Shop", in dem diverse AddOns gelistet waren. Die konnte man sich einfach zu seinem "Assistenten" hinzufügen. Sowas gibt's bei Rhasspy noch nicht wirklich, es wird aber daran gebaut (https://community.rhasspy.org/t/hermes-skill-server-for-intent-handling/1054).

Das ist auch der Grund, warum wir so komische Intent-Namen verwenden (de.fhem.XXXX). Damit sich FHEM und ein externes Script nicht in die Quere kommen, weil sie versehentlich die selben Intents abgreifen.

Hier ist z.b. ein Wetter-Skill: https://community.rhasspy.org/t/rhasspy-can-tell-you-the-weather/671. Habe ich aber nicht ausprobiert.

Zitat@all: Wenn ich das richtig deute, haben einige wenige die aktuellste Fassung runtergeladen.
Befürchte, das war 4x ich. Hatte kleinere Probleme.


ZitatAd SetNumeric:
#2569ff muss vermutlich so lauten; der "response"-Teil ist danach nochmal drin bzw. reingekommen wegen der "Group"-Geschichte:
if ( !defined $mapping ) {
        if ( defined $data->{'.inBulk'} ) {
            #Beta-User: long forms to later add options to check upper/lower limits for pure on/off devices
            return;
        } #else {
        #    return RHASSPY_respond ($hash, $data->{requestType}, $data->{sessionId}, $data->{siteId}, RHASSPY_getResponse($hash, 'NoMappingFound'));
        #}
    }

(Das "return" hatte gefehlt; die Frage ist, ob man den Code dann doch (mit return) aktiv läßt...)

Merci, klappt jetzt.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 15 April 2021, 11:36:37
Nachträge zu gestern:
- war an mind. einer Stelle mit "return $name" über das Ziel rausgeschossen (set ... play). Kann bestätigen, dass auch mein Handy auf Anweisung von Rhasspy Sounds wiedergeben kann, aber nach der set-Anweisung will man eigentlich auf die Detail-Seite vom RHASSPY-Device zurück...
- das mit dem "zusätzlichen richtigen return" gefällt mir besser, ist einfach für die Zukunft gesehen übersichtlicher wie das komplette Auskommentieren.
- noch etwas clean-up

UND: ...doch noch ein (bislang ungetesteter!) feature-Versuch - wiederholtes Abspielen einer WAV.
Das ganze ist eigentlich generisch gestaltet, aber erst mal zu dem Anwendungfall "Timer":
attr RHASSPY rhasspyTweaks timerSounds=default="./flasche.wav" Eier="3:20:./flasche1.wav" Kartoffeln="5:./flasche2.wav"
Die Keys sind Beispiele und müssen "Label" entsprechen. "default" ist optional, und leitet dann ALLE (belabelten?) timer auf die betreffende File um, wenn kein expliziter Label-Match paßt.

Die Zahlen sind optional und stehen für "repeats" und "wait", "wait" ist die Wartezeit bis zum nächsten Durchlauf. (Erst mal gesetzte) defaults dafür sind 5 repeats und 15 für "wait", ist nur eine Zahl angegeben, wird das als "repeats" verwendet.

Da das ganze so funktioniert, dass playWav mit ein paar mehr Parametern aufgerufen wird, kann man das natürlich auch außerhalb von Timer nutzen, die erneute Widergabe abbrechen geht dann mit der normalen Cancel-Anweisung für Timer.

Jetzt müsste man
a) testen, ob der Code überhaupt funktioniert (belabelte und unbelabelte timer,Anzahl Wiederholungen und Dauer, Abbruch, ...)
b) Rückmeldung geben, ob die Syntax und generelle Logik "ok" ist, und
c) (wenn a) und b) geklärt sind) Doku dazu machen...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 15 April 2021, 12:16:31
timerSounds=default="/opt/fhem/raspberry01.wav"

Funktioniert, wird aber nicht wiederholt weil:

timer_wohnzimmer_Taimer: datespec is not allowed with +
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 15 April 2021, 12:30:29
...na dann...

...müssen wir wohl $attime etwas anders berechnen und formatieren; war gedanklich wohl bei InternalTimer...

%T war doch irgendwie auf Wind.*-Maschinen problematisch, oder? Daher jetzt auch an anderer Stelle die "umständliche" Variante.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 15 April 2021, 12:42:33
%T hab ich nur verwendet, um das Timer-Reading anzuzeigen.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 15 April 2021, 12:51:10
Es ist egal, wo %T effektiv zur Anwendung kommt - auf diesem seltsamen OS führt es dann (soweit ich mich entsinne) zu einem Fehler...
Daher hatte ich das irgendwann mal in einer früheren Version gegen die "lange Form" '%H:%M:%S' getauscht. Zwischenzeitlich war das dann mal nicht mehr erforderlich, weil eh' die Einzelteile benötigt gewesen waren, jetzt muss man (bzw. sollte man freundlicherweise) m.E. eben wieder die "lange Form" an beiden Stellen verwenden. Ist aber nebensächlich, interessanter wäre, ob es jetzt geht ;D .
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 15 April 2021, 12:53:23
Nö ;D

Usage: POSIX::strftime(fmt, sec, min, hour, mday, mon, year, wday = -1, yday = -1, isdst = -1) at ./FHEM/10_RHASSPY.pm line 3009.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 15 April 2021, 13:11:38
OK, dann versuchen wir es eben mit der (hoffentlich) korrekten Klammersetzung...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 15 April 2021, 13:22:30
Da wird jetzt nicht richtig getrennt:

set Rhasspy play siteId="wohnzimmer" path=":/opt/fhem/raspberry01.wav" repeats=3 wait=5 id=timer_wohnzimmer_Taimer

Der Doppelpunkt vor dem Pfad sollte da nicht sein.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 15 April 2021, 13:29:13
Argh, da ist ein Doppelpunkt in Zeile 3018 verloren gegangen:
            $soundoption =~ m{((?<repeats>[0-9]*):){0,1}((?<duration>[0-9.]*):){0,1}(?<file>(.+))}x;

Warum notiert ihr eigentlich scheinbar bevorzugt absolut? Sollte auch so funktionieren:
path="./raspberry01.wav"
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 15 April 2021, 13:41:57
Jetzt geht's wieder. Aber wiederholt wird noch immer nichts.

Keine Ahnung, warum ich den Pfad immer so angegebe. Die Finger tippen das inzwischen von selbst. Aber ja, geht natürlich auch anders.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 15 April 2021, 13:51:56
Hmm, werde wohl selbst testen müssen, vermute irgendeine Kleinigkeit beim Anlegen des nächsten at...
Aber wenn erst mal das Ausgangskommando abgesetzt ist, sollte der Rest dann auch kein Hexenwerk mehr sein.

Wie findest du die Syntax?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 15 April 2021, 13:56:23
Zitat von: Beta-User am 15 April 2021, 13:51:56
Wie findest du die Syntax?

Extrem fehleranfällig leider.

timerSounds {
    "default" : "./flasche.wav"
    "Eier" : "3,20,flasche1.wav"
}

Oder so in der Art wäre fast schöner. Sonst sind das extrem viele =, : und "
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 15 April 2021, 14:13:01
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...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 15 April 2021, 15:09:28
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.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 15 April 2021, 15:22:41
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*
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 15 April 2021, 15:28:05
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
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 15 April 2021, 15:29:39
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.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 15 April 2021, 15:49:26
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ß...)
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 15 April 2021, 16:14:41
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?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag 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
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 15 April 2021, 16:31:42
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...)
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 15 April 2021, 16:35:25
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?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 15 April 2021, 16:41:58
Ö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?)
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 15 April 2021, 16:43:52
Timer-WAV wird jetzt brav wiederholt :)
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 15 April 2021, 16:50:18
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).
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 15 April 2021, 17:00:39
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 ;)
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 15 April 2021, 17:53:02
--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.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 15 April 2021, 18:02:53
"Eigentlich" sieht das ganz gut aus...

Es wird ein Hash übergeben, ganz so, wie es sein sollte. Vermutlich solltest du Dumper dazwischenklemmen, oder eben eine for-loop über die keys laufen lassen, um was sinnvolles angezeigt zu bekommen. Aber das eigentliche Ziel war ja, $data genauso verwenden zu können wie innerhalb des Moduls und dann auf beliebige Keys zugreifen zu können (die wir ja kennen), ohne die einzeln als Parameter vorab abzurufen.
In myUtils muss man dann nur den Umweg von NAME auf $defs{NAME} nehmen, also eher so:
Calculation=rhasspyCalc(NAME,DATA)
sub rhasspyCalc{
    my $name = shift // return;
    my $data = shift // return;
    my $hash = $defs{$name} // return;

    return "Calc data keys ares: ". join q{, }, keys %{$data};
}

Das wäre noch zu checken.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 15 April 2021, 18:13:41
Also deine Version bringt ähnliches:


2021.04.15 18:13:14.255 5: handleCustomIntent called with Calculation key
2021.04.15 18:13:14.255 5: Calling sub:  rhasspyCalc( "Rhasspy",HASH(0x55e6d5487298) )
2021.04.15 18:13:14.255 1: PERL WARNING: Hexadecimal number > 0xffffffff non-portable at (eval 580) line 1.
2021.04.15 18:13:14.255 3: eval:  rhasspyCalc( "Rhasspy",HASH(0x55e6d5487298) )
2021.04.15 18:13:14.255 1: ERROR evaluating  rhasspyCalc( "Rhasspy",HASH(0x55e6d5487298) ) : Undefined subroutine &main::HASH called at (eval 580) line 1.

2021.04.15 18:13:14.256 5: Response is: Undefined subroutine &main::HASH called at (eval 580) line 1.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 15 April 2021, 18:18:55
Was aber z.B. funktioniert ist:


[de.fhem:Calculation]
Was (macht|ergibt) (0..10){Number1} ([plus|und]{Operator:plus}|[minus|weniger]{Operator:minus}|[mal|multipliziert mit]{Operator:mul}|[durch|geteilt durch|dividiert durch]{Operator:div}) (0..10){Number2}


Calculation=rhasspyCalc(Number1,Number2,Operator)


sub rhasspyCalc{
  my $val1 = shift // return;
  my $val2 = shift // return;
  my $op = shift // return;

  my $response = "Dafür muss ich nochmal in die Nachhilfe";

  if ($op eq "plus") {
    $response = "Das Ergebnis ist " . ($val1 + $val2);
  }

  return $response;
}
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 16 April 2021, 07:54:05
Was ein Sch...

Also: Das Problem ist, dass wir mit der absichernden Variante der Code-Ausführung eigentlich nur Text übergeben können. Alles andere führt zu diesen seltsamen Effekten, und im Moment habe ich auch keine Idee, wie man aus dem HASH-String wieder an die Daten kommen könnte.
Von daher schlage ich vor, DATA einfach JSON-encoded zu übergeben, dann muss man halt wieder auspacken... (Eventuell sollte man dazu noch ein Code-Schnipsel in die cref packen, reicht aber später irgendwann noch).

Zumindest auf den ersten Blick sieht das ganz ok aus, was die Fassung in der Anlage macht. Da ist mir auch noch ein "undefined"-Warning vor die Flinte gelaufen.

Nachdem ich jetzt auch das erste Mal mit CustomIntents rumgespielt habe: Eigentlich sollte man zwei Werte zurückliefern können: Device und $response. Oder täuscht mich das?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 16 April 2021, 08:48:23
Hmm, laß gut sein. Ich find das eigentlich nicht schlecht, wenn man einfach nur die Tags aus dem Sentence weiterreichen kann. Das ist perfekt für schnelle Workarounds und Anfänger. Leute, die einen ausgiebigeren Intent brauchen, sollen ein "Modul für's Modul" schreiben. Da haben dann alle was davon.

Bisher war's so, dass einfach nur eine Response zurückgeliefert wurde. Das Device brauchen wir ja nicht, oder? Höchstens eventuell für einen Trigger, hab ich aber nicht ausprobiert.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 16 April 2021, 09:53:25
Zitat von: drhirn am 16 April 2021, 08:48:23
Hmm, laß gut sein.
Bald...

Zitat
Ich find das eigentlich nicht schlecht, wenn man einfach nur die Tags aus dem Sentence weiterreichen kann. Das ist perfekt für schnelle Workarounds und Anfänger.
Ja, und diese Option MUSS m.E. auch bleiben, genauso wie die "einfache" Interpretation eines zurückgelieferten SCALARS als $response (und trigger auf die RHASSPY-Instanz).

Zitat
Leute, die einen ausgiebigeren Intent brauchen, sollen ein "Modul für's Modul" schreiben. Da haben dann alle was davon.

Bisher war's so, dass einfach nur eine Response zurückgeliefert wurde. Das Device brauchen wir ja nicht, oder? Höchstens eventuell für einen Trigger, hab ich aber nicht ausprobiert.
Bei DATA geht es genau um das Thema "Modul für's Modul": Wir brauchen eine Art "API", die vollen Zugriff gibt auf alle Funktionen, die alle anderen internen Funktionen auch haben. Neben $hash (Umweg: NAME) und $data (der Umweg über toJSON ist implementiert und funktioniert!) (und evtl. Room?) sind das eben auch in der Rückgabe:
- $response mit Möglichkeit, den Dialog offenzuhalten (!)
- Liste der Devices, die zu triggern sind.
Das richtet sich in der Tat eher an erfahrenere Leute, aber wenn man spannende weitere features anflanschen will, braucht man m.E. genau das.

Das über einen separaten anderen Intent anzuflanschen, finde ich nicht notwendig, wir müssen jetzt eigentlich nur noch den Rückgabewert darauf prüfen, ob er ein ARRAY-REF ist (wenn ja, ist (z.B.) ${$response}[0] die kommaseparierte Liste der Geräte und ${$response}[1] die $response, die ihrerseits dann weitergereicht wird, was ggf. (wenn das ein HASH-REF ist) dazu führt, dass der Dialog offen bleibt. In dem Fall sollte dann noch die Option bestehen, den timeout vorzugeben, bis wann das so sein soll (=> ${$response}[2]).

Wenn wir das haben, ist m.E. "der Fisch geputzt" (an der Stelle), und du darfst wieder eine "Unternummer" weiterzählen ;D .
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 16 April 2021, 14:17:21
Zitat von: drhirn am 15 April 2021, 16:14:41
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?

synesthesiam hat im Rhasspy-Forum eine Lösung geliefert: Custom-Converter

https://community.rhasspy.org/t/using-real-numbers-in-sentences-0-5-22-point-5-etc/2501/7
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 16 April 2021, 15:03:58
 :) das geht ja mit großen Schritten auf's WE zu!

Dann (hoffentlich) zum Abschluss noch die beiden "fehlenden" Themen, von denen ich hoffe, sie ohne schädliche Nebenwirkungen erschlagen zu haben:
- Rückgabe eines ARRAYs für CustomIntent-Spezialisten (komplett ungetestet, dafür dokumentiert  ::) ) und
- für den gDT-Type "media" wird jetzt nur noch gemappt, was auch an settern vorhanden ist. Ist grob angetestet, und sollte zum einen die gröbsten Unsauberkeiten beseitigen, die durch das vormalige generöse mapping entstanden waren, und zum anderen eine Demo dafür sein, wie man das prinzipiell lösen kann, nur zu mappen, was auch vorhanden ist. Sollte hilfreich sein für weitere gDT-Mapping-Typen, und theoretisch ist die Methode (wohl aber der aktuelle Code) nicht auf setter beschränkt. Allerdings würde ich bzgl. Abfragen (typische Readings) ggf. auch einfach mal warten, ob es da überhaupt Bedarf gibt bzw. welchen. Habe Sorge, dass zu viele Mappings zulasten der Trennschärfe gehen.

Wenn wir keine gröberen Schnitzer mehr finden, wäre das dann m.E. tauglich für 0.5.0 und den Gang Richtung svn, und es spräche dann auch gar nichts mehr dagegen, die dDT-Vorgehensweise auch in der Darstellung zum Default zu machen.

Apropos Darstellung:
Will eigentlich nicht zu viel Energie in das .md legen, aber auf die Schnelle ist mir neben der "Kleinigkeit", dass gDT irgendwo im Nachklapp erwähnt wird und diversen anderen Kleinigkeiten aufgefallen, dass "E.g. if currentVal is 23 C, part=1 results" sachlich nicht stimmt und eventuell manche noch offene Punkte abgehakt werden könnten  ;) .
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 16 April 2021, 15:43:56
Nachdem ich ja kein Custom-Intent Spezialist bin, magst du ein kurzes Beispiel mit $data und der Rückgabe eines Arrays posten? V.a., was man dann mit dem Array machen könnte?

gDT "media" habe ich jetzt gerade keine Ahnung, wie ich das testen könnte. Da muss ich wohl ein sehr ausführliches Dummy-Device anlegen. Oder einfach mal ein paar Set-Befehle aus meinem vorhandenen löschen? Hmm...

Da ich gDT für den 29. jetzt nicht ausführlich getestet habe, habe ich sie absichtlich noch nicht in der Doku erwähnt. Das war für mich von Anfang an ein Feature, auf dem ich eigentlich die Version 2 aufbauen wollte. Da's aber schon sehr gut funktioniert, wird's wohl eine kleiner Versionsnummer. Nichts desto trotz bin ich dafür, dass wir die Kaum-Erwähnung jetzt vorläufig mal so lassen.

Danke für den Hinweis mit dem Fehler in der Doku! Die ist halt auch noch nicht fertig. Irgend jemand hat mich ja mit Custom Intents abgelenkt ;D
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 16 April 2021, 16:08:55
Zitat von: drhirn am 16 April 2021, 15:43:56
Nachdem ich ja kein Custom-Intent Spezialist bin, magst du ein kurzes Beispiel mit $data und der Rückgabe eines Arrays posten? V.a., was man dann mit dem Array machen könnte?
Mache ich bei Gelegenheit - das Problem ist, dass ich das selbst kaum verstehe ::) , und vor weiteren Tests erst mal die Schnittstelle vom Konzept her "stehen" musste - irgendwo muss man ja anfangen (ähnlich wie mit dem gDT-Ding).
Für's erste sollte es reichen, wenn es mit den alten Intents fehlerfrei weiter läuft, der Rest kommt dann schon.

Zitat
gDT "media" habe ich jetzt gerade keine Ahnung, wie ich das testen könnte. Da muss ich wohl ein sehr ausführliches Dummy-Device anlegen. Oder einfach mal ein paar Set-Befehle aus meinem vorhandenen löschen? Hmm...
Ich werde das über's WE mit meinen Echt-Geräten testen, mit dummy ist es bereits vor-getestet. Weiß nur noch nicht, wann ich dazu komme, daher ist das vorläufig eher zur Abrundung gedacht und für die, die ggf. grade mittesten. Man sieht ja direkt im Hash, ob alles ok ist.
Vermutlich werde ich dann noch "light" mit rgb,ct und hue (+set?) ergänzen. Wenn ich die Zusammenhänge richtig deute, braucht man für ein "Color"-mapping zusätzlich diese setter, und dann noch die Angabe in rhasspyColor. Eventuell könnte man überlegen, ob man eine Art "colorDefault" in "tweaks" hinterlegen kann, das dann (in welcher Reihenfolge, wenn es z.B. hue und rgb gibt?) greift, wenn ein "light" z.B. eines/beides kann?
EDIT: Zumindest meine dummy-Devices deuten darauf hin, dass es ohne geht; die Frage wäre dann also eher, ob man diesen Teil ggf. irgendwie generischer lösen kann/will. Dazu fehlt mir aber noch eine Idee...

Zitat
Da ich gDT für den 29. jetzt nicht ausführlich getestet habe, habe ich sie absichtlich noch nicht in der Doku erwähnt. Das war für mich von Anfang an ein Feature, auf dem ich eigentlich die Version 2 aufbauen wollte. Da's aber schon sehr gut funktioniert, wird's wohl eine kleiner Versionsnummer. Nichts desto trotz bin ich dafür, dass wir die Kaum-Erwähnung jetzt vorläufig mal so lassen.
Da es funktioniert (vorbehaltich der Tests zu "media"), würde ich empfehlen, das vorzuziehen. Wer schon irgendwas in die Richtung bei sich in der config hat, wird sich sonst über eine umständliche Einzelkonfiguration vermutlich spätestens im Nachhinein wundern. Mir ist schon klar, dass du dich damit noch nicht so wohlfühlst, weil es (scheinbar) was neues ist und du mit der "zu Fuß"-Methode halt gut vertraut bist, aber im Ergebnis kommt 1:1 dasselbe raus (ggf. halt mit demselben Fehler, wie wenn man ein falsches manuelles Mapping macht, wie im Fall von dem FS20-Dimmer). Ist aber m.E. eine reine Gewohnheitsfrage, und der Stand ist soweit gediehen, dass m.E. eigentlich nichts schiefgehen kann.
(Die Grenzen des Verfahrens kann und darf man aber zeigen! Damit hat auch die "alte" Methode weiter ihre volle Berechtigung!)

Zitat
Danke für den Hinweis mit dem Fehler in der Doku! Die ist halt auch noch nicht fertig. Irgend jemand hat mich ja mit Custom Intents abgelenkt ;D
...alles zu seiner Zeit. Ist mir halt aufgefallen.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 16 April 2021, 16:33:16
Was ich bzgl. gDT noch nicht ausgiebig getestet habe ist, was passiert, wenn man ein gDT gesetzt hat, aber auch ein z.B. rhasspyColors haben möchte. Oder die gDT Setter mit rhasspyMapping überschreiben möchte. Also, wenn ich ein Device habe, dass zwar keinen "rhasspyName" und "rhasspyRoom" hat, dafür aber ein "rhasspyMapping".

Was ist dir denn an der MD noch aufgefallen?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 16 April 2021, 17:01:45
gDT und "blind": Da erscheinen mir "pct" und "dim" als nicht passend. Ich weiß leider nicht, wie ein Rollladen-Device in der Praxis aussieht. Hast du sowas? Wird da "state" gesetzt? Und wenn ja, müssen wir das wohl anders abhandeln.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 16 April 2021, 17:14:38
Zitat von: drhirn am 16 April 2021, 16:33:16
Was ich bzgl. gDT noch nicht ausgiebig getestet habe ist, was passiert, wenn man ein gDT gesetzt hat, aber auch ein z.B. rhasspyColors haben möchte. Oder die gDT Setter mit rhasspyMapping überschreiben möchte. Also, wenn ich ein Device habe, dass zwar keinen "rhasspyName" und "rhasspyRoom" hat, dafür aber ein "rhasspyMapping".
Der Vergleich zwischen den Ergebnissen aus gDT und rhasspy-Attribut erfolgt "pro Attribut". Ist also gDT gesetzt, aber kein rhasspyName, wird ggf. der alexaname etc. verwendet, selbst wenn ein rhasspyMapping (z.B. für SetNumeric) da ist (letzteres verdrängt dann nur die mappings, die aber dann komplett).
Andersrum kannst du bei einem funktionierenden "light" (dimmer-) Device z.B. dann nur "rhasspyColors" setzen und darüber die Farben steuern (so jedenfalls die Vermutung aus dem Code).

Kurz: du siehst IMMER das Gesamtmapping im Hash, und wie einleitend in der cref geschrieben: die speziellere Angabe verdrängt immer die Allgemeine (da wo sie gilt).

Zitat
Was ist dir denn an der MD noch aufgefallen?
Wenn ich dazu komme, schaue ich drüber und mache das dann per pull-request (sowas will ja auch geübt sein ::) .)

Zitat von: drhirn am 16 April 2021, 17:01:45
gDT und "blind": Da erscheinen mir "pct" und "dim" als nicht passend. Ich weiß leider nicht, wie ein Rollladen-Device in der Praxis aussieht. Hast du sowas? Wird da "state" gesetzt? Und wenn ja, müssen wir das wohl anders abhandeln.
Habe ich und das ist bei mir auch produktiv so ok (jedenfalls, soweit ich das bisher getestet habe (v.a. mit SetNumericGroup)). Eingesetzte TYPE sind CUL_HM (Bl-PBU, nur Rollläden) und ZWave (Fibaro 222 und 223 an Jalousien, also drehbare Lamellen; der "Dreh"-Teil fehlt noch...). Bei den ZWave ist es - so oder so - etwas speziell, weil man da etwas nachhelfen muss, damit man "dim" auch als Reading bekommt. Ist aber häufig vorhanden, v.a. bei denen, die auch AutoShuttersControl nutzen.
Wenn nicht, geht halt die GetNumeric-Anfrage schief, aber der Rest paßt...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 17 April 2021, 07:01:52
So, nachdem jetzt erste Tests durch sind, und mir dann auch beim Gegenlesen der .md noch Verbesserungsmöglichkeiten aufgefallen sind, noch ein paar kleinere Änderungen und Ergänzungen. Feine Sache, das...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 17 April 2021, 08:41:42
Danke für die Änderungen an der .md!

Was ist eine feine Sache?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 17 April 2021, 08:45:40
Wie das mit dem Mappen jetzt alles hübsch automatisch geht, aber eben nur für das, was auch geht - dafür bekomme ich halt Rückmeldung "das geht nicht", wenn ein Kommando ins Leere geht. Ein MPD-Device ist halt was anderes als ein Verstärker, und auch da sind Main und Nebenzone unterschiedlich (was aber Rhasspy (noch?) nicht wissen kann)...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 17 April 2021, 08:51:27
Ja, das ist wahr!

Bin gerade plan - und antriebslos, weil schlecht geschlafen. Was könnten wir heute noch so machen?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 17 April 2021, 08:58:32
Ich: hoffentlich FHEM-mässig: nichts, ggf. Notreparaturen, falls erforderlich, ansonsten: warten auf feedback.
Du: Präsentation vorbereiten?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 17 April 2021, 09:07:12
Klingt nach einem guten Plan!
Und was soll ich am Wochenende kochen? ;)
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 17 April 2021, 11:09:04
Heute: https://de.wikipedia.org/wiki/Schakschuka, morgen: Schweinsbraten, ist doch klar...
Ansonsten kannst du meine Tippfehler in der .MD suchen und die teilweise kaputtgemachte Formatierung retten...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 17 April 2021, 11:15:47
Schweinsbraten ist tatsächlich der Plan für heute :D
Schakuschka klingt super, kommt vielleicht morgen dran.

Ja, ein paar Fehler hab ich schon korrigiert. Jetzt ist aber zuerst mal die Präsentation dran.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 18 April 2021, 13:09:59
WICHTIG

In Version 0.4.9 habe ich das GitHub-Repository umgebaut.
Es beinhaltet jetzt meine vollständige Konfiguration (docker-compose.yml, Demo-FHEM, Rhasspy-Konfig, Rhasspy-Sentences, ...) für eine komplette Testinstallation unter Windows (Docker + WSL).

Theoretisch sollte es also möglich sein, das Repo herunterzuladen und die Docker-Container zu starten.

In der Praxis spielt leider der FHEM-Container nicht mit. Da muss ich noch eine Lösung finden.


Für euch am wichtigsten ist aber, dass sich die 10_RHASSPY.pm nicht mehr im Repo-root, sondern in opt/fhem/FHEM befindet.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 18 April 2021, 17:30:29
Kann zwar nicht einschätzen, was das jetzt konkret bedeutet, aber es klingt nach einem Meilenstein...

Da das WE sich dem Ende nähert, ohne dass jemand "Katastrophe" gerufen hat: Wie schaut's mit svn aus?

Fragst du mal bei Rudi an, ob es sinnvoll ist, für RHASSPY ein Verzeichnis in contrib einzurichten?

Ansonsten habe ich das Problem, dass meine Kommandos zu häufig an die falsche Adresse gehen, und dann ein "gerät kann das nicht" zurückkommt. Bin am Grübeln, ob es nicht besser wäre, mit Hilfe der gDT-Info Gruppen zu bilden, so dass z.B. "auf" und "zu" nur an Rollläden gehen, "leiser/lauter" nur an "media" usw.. Würde halt bedeuten, dass man die sentences auch entsprechend modifiziert.
Jemand Erfahrung in diese Richtung?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 18 April 2021, 18:27:45
Das bedeutet eigentlich gar nichts. Zum einen hab ich meine aktuelle Konfiguration irgendwo gesichert. Zum anderen findet vielleicht jemand Inspiration dadurch. Und theoretisch könnte man wirklich mein Testsystem nachbilden. Ist nur nicht so einfach, wie gehofft.

Ja, werde Rudi morgen oder übermorgen mal anschreiben.

Wie meinst du "falsche Adresse"? An das falsche Gerät?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 18 April 2021, 18:35:14
Ja, es wird zumindest gefühlt zu häufig nicht das richtige device angesprochen.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: rakete123 am 18 April 2021, 19:23:07
Hallo zusammen,
ich habe mal den de.fhem:SetOnOff intent aktiviert. "Schalte die Deckenlampe im Wohnzimmer an" wird auch von rhasspy erkannt und ich sehe auch die Meldungen in FHEM. Aber als VoiceResponse bekomme ich immer wieder "Sorry but something seems not to work as expected".
Dem Gerät "wz.licht.1" in FHEM hab ich nur ein einziges Attribute verpasst:
rhasspyName Deckenlicht,Deckenlampe

Ein update devicemap und train in RHASSPY habe ich gemacht.

Woran liegt es jetzt noch?

Edit: verbose auf 5 zeigt das hier:
2021.04.18 19:24:00 5: Parsed value: on for key: Value
2021.04.18 19:24:00 5: Parsed value: SetOnOff for key: intent
2021.04.18 19:24:00 5: Parsed value: wohnzimmer-jarvis_raspberry-pi-139799d5-42f6-4a00-b630-490f7572c72b for key: sessionId
2021.04.18 19:24:00 5: Parsed value: wohnzimmer for key: siteId
2021.04.18 19:24:00 5: Parsed value: deckenlampe for key: Device
2021.04.18 19:24:00 5: Parsed value: schalte die deckenlampe on for key: input
2021.04.18 19:24:00 5: Parsed value: schalte die deckenlampe an for key: rawInput
2021.04.18 19:24:00 5: handleIntentSetOnOff called
2021.04.18 19:24:00 5: Device selected (by hash, with room and name): wz.licht.1
2021.04.18 19:24:00 5: Response is: Sorry but something seems not to work as expected


Sieht doch eigentlich ganz gut aus.

Edit2: Ahhh gdt muss man auch setzen, ok eigentlich klar. gdt oder rhasspymapping nehme ich an?

mfg
Marcel
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 18 April 2021, 19:52:07
Kannst du dir aussuchen. Kannst auch beides setzen, wenn gDT nicht so richtig zu deinem Gerät passt. Aber in dem Fall reicht das auf jeden Fall.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Treibhaus am 19 April 2021, 02:28:48
Hallo,

ich habe die Version (will die neue Version::0.4.7b ) testen.

Ich bekomme die Meldung : 127.0.0.1: Verbindungsaufbau abgelehnt (111)    (in FHEM)
Meine Main-RHASSPY läuft auf einem weiterem Linux-Gerät = andere IP.

Wo ändere ich das ? Wo kann ich es einstellen ?

Gruß Jörg



Kurze Antwort (auch an mich selbst):
INTERNALS von "RHASSPY" (Name of Device)
DEF:  baseUrl=http://XXX.XXX.XXX.xxx:12101 devspec=room=Rhasspy,room=Music,Light1 defaultRoom=Wohnzimmer,Kueche,Flur,Keller language=de


Funktioniert trotzdem nicht !!  - -  obwohl die Meldung in FHEM unter DEVICEOVERVIEW : RHASSPY = Online   ist

.... ich teste/versuche weiter....
Gerne Anregungen !!

Gruß Jörg
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 19 April 2021, 08:16:53
Was funktioniert nicht? Das erste Problem hast du ja selbst gelöst. Sobald das Modul eine Verbindung zur Rhasspy-Base herstellen kann, ist der Status online wie du richtig erkannt hast.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 19 April 2021, 08:38:06
Zitat von: Treibhaus am 19 April 2021, 02:28:48
defaultRoom=Wohnzimmer,Kueche,Flur,Keller

Moment mal, die Angabe macht keinen Sinn. defaultRoom ist nur einer. Und zwar der, der genommen werden soll, wenn ein Device keinem Raum zugeordnet werden kann (über room od. rhasspyRoom).
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 19 April 2021, 11:59:31
Zitat von: Beta-User am 18 April 2021, 17:30:29
Ansonsten habe ich das Problem, dass meine Kommandos zu häufig an die falsche Adresse gehen, und dann ein "gerät kann das nicht" zurückkommt. Bin am Grübeln, ob es nicht besser wäre, mit Hilfe der gDT-Info Gruppen zu bilden, so dass z.B. "auf" und "zu" nur an Rollläden gehen, "leiser/lauter" nur an "media" usw.. Würde halt bedeuten, dass man die sentences auch entsprechend modifiziert.
Jemand Erfahrung in diese Richtung?

Mir passiert das eigentlich nie. Begeistert mich immer wieder, dass das so gut klappt.
Kann es sein, dass deine Geräte Namen haben, die Rhasspy nicht versteht? Schaust du hin und wieder im GUI von Rhasspy nach, ob da eventuell noch ein paar "Custom Words" angelegt werden müssen? Rhasspy meldet das im GUI nach dem Training, dass es Wörter nicht kennt.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 19 April 2021, 12:15:27
 ;D liegt vielleicht eher daran, dass ich gerne die Extreme austeste, also z.B. Sprachkommandos bei laufender Musik...

Wenn es ruhig ist und ich sehr darauf achte, deutlich zu sprechen und _genau_ den Satz zu sagen bzw. den Namen zu wählen, der die besten Ergebnisse geben sollte (muss das dann nachschlagen...), dann ist alles supi.
Dass man "unbekannte" und unaussprechliche Namen ggf. manuell anfassen muss, ist soweit klar - das war letztlich auch der Grund, warum z.B. alias den "techname" verdrängt bzw. rhasspyName alles andere: Zu viele ähnliche Namen führen nicht unbedingt zu besseren Ergebnissen...

Mal sehen, ob ich dazu komme, mal diese gDT-Gruppen als slots anzulegen und damit zu testen.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: rakete123 am 19 April 2021, 12:51:27
Könnte man nicht irgendwie ein event in FHEM haben, wenn das hotword erkannt wurde? Dann könnte man schnell medien muten oder pausieren.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 19 April 2021, 12:53:42
Gibt es. Die "<siteId>_listening" Readings gehen auf 1, sobald Rhasspy zuhört.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 19 April 2021, 12:54:56
Korrigiere. Gab es mal. Keine Ahnung wo die hin sind. Ich schau mir das an.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 19 April 2021, 13:33:42
@Beta-User: Durch Zeile 1788
        next if $topic !~ m{$topicpart}x;
rutschen wir nie nach RHASSPY_onmessage. Was hattest du mir der Zeile im Hinterkopf?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 19 April 2021, 13:44:00
"nie" ist ein großes Wort...

onmessage wird nur noch aufgerufen, wenn der topic auch zu Sprache und fhemId paßt. "An sich" ist das gut und richtig. Vermute, es geht um das "listening"-Thema?
Wie sieht da der MQTT-Verkehr aus? (Kann grade nicht testen).
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 19 April 2021, 13:48:59
Nie... nagut, war falsch formuliert ;D

Ja, genau. Es geht um das "listening"-Thema. Die Readings werden natürlich nicht geschrieben, weil if ($topic =~ m{\Ahermes/dialogueManager}x) nie zutrifft. Und jetzt passt das "nie" ;)
Wir sollte also auf jeden Fall nach onmessage springen. Oder die Sache mit den Readings wo anders unterbringen.

Msg: hermes/dialogueManager/sessionStarted => {"sessionId": "wohnzimmer-snowboy-bda47a55-35eb-4dfe-ad02-de0a670cae2d", "siteId": "wohnzimmer", "customData": "snowboy", "lang": null}
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 19 April 2021, 13:58:21
Man sollte immer so früh wie möglich aussortieren...

Würde also den Filter eher versuchen so einzustellen, dass er das durchläßt, was Sinn macht. So könnte das klappen:
my $topicpart = qq{/$hash->{LANGUAGE}\.$hash->{fhemId}\[._]|\Ahermes/dialogueManager};
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 19 April 2021, 14:07:54
Das "A" ist unabsichtlich rein gerutscht?

Funktioniert. Danke!
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 19 April 2021, 14:09:02
Hm, eigentlich nicht. "\A" ist "damit muss es anfangen".
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 19 April 2021, 14:14:54
Hätte ich auch gedacht.

PERL WARNING: Unrecognized escape \A passed through at ./FHEM/10_RHASSPY.pm line 1788
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 19 April 2021, 14:17:28
Zitat von: rakete123 am 19 April 2021, 12:51:27
Könnte man nicht irgendwie ein event in FHEM haben, wenn das hotword erkannt wurde? Dann könnte man schnell medien muten oder pausieren.

Ist im aktuellen Commit von 0.4.9 wieder möglich.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 19 April 2021, 14:20:33
...ursprünglich hatte ich das anders herum verschlagen wollen:
my $topicpart = qq{\Ahermes/dialogueManager|/$hash->{LANGUAGE}\.$hash->{fhemId}\[._]}und dann aber "kalte Füße", ob sich das \A auch auf den hinteren Teil auswirkt. Müßte man testen, aber notfalls sollte es an der Stelle auch ohne gehen, da wir "$topic" ja schon mal irgendwie abgegrenzt hatten.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Treibhaus am 19 April 2021, 17:09:47
Zitat von: drhirn am 19 April 2021, 08:16:53
Was funktioniert nicht? Das erste Problem hast du ja selbst gelöst. Sobald das Modul eine Verbindung zur Rhasspy-Base herstellen kann, ist der Status online wie du richtig erkannt hast.


Hallo,

es hilft natürlich wenn man
1. alle Dateien austauscht
2. Update / ALL im DEVICE:RHASSPY ausführt.

room= sind korrigiert (laut Spezf).

DANKE. Läuft wieder mit der Version: 0.4.8 

Gruß
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 19 April 2021, 17:24:54
Vorhin ist mir in den screenshots aufgefallen, dass "alias" nicht in lowercase gewandelt wird. Anbei entprechende Korrektur, auch für die Paralellthemen...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 20 April 2021, 10:09:06
Der defaultRoom scheint nicht in einem list des Devices auf. Ist das Absicht? Nur im helper.

Und, weil du gerne spanisch in deinen Beispielen verwendest: Da heißt das Wohnzimmer z.B. "cuarto de estar". Die Leerzeichen sind da natürlich blöd. Können/sollen wir das im DEF irgendwie beachten?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 20 April 2021, 11:13:44
Zitat von: drhirn am 20 April 2021, 10:09:06
Der defaultRoom scheint nicht in einem list des Devices auf. Ist das Absicht? Nur im helper.
Kann noch nicht nachvollziehen, was du meinst. Falls sich das wirklich auf das list des Devices bezieht: RHASSPY ändert an dem Device (abgesehen von den zusätzlichen Attributen via global) nichts, es wird alles im RHASSPY-Hash (unter helper) verwaltet.

Zitat
Und, weil du gerne spanisch in deinen Beispielen verwendest: Da heißt das Wohnzimmer z.B. "cuarto de estar". Die Leerzeichen sind da natürlich blöd. Können/sollen wir das im DEF irgendwie beachten?
Hm, ich habe in meinen (deutschen) Gruppen und Namen teils auch Leerzeichen drin, und sehe in Leerzeichen im rhasspyRoom eigentlich auch keine besonderen Probleme. Übersehe ich was?

Anbei nochmal eine Aktualisierung, die jetzt auch die effektive "Namensliste" Komma-separiert im Geräte-Teilhash anzeigt und dann noch zusätzliche Slots für die Geräte jeder gDT-Gruppe anlegt (dafür war die Namensliste hilfreich). Der Teil funktioniert soweit, ich weiß aber noch nicht, ob das Verbesserungen an der Erkennungsrate bringt, dazu muss ich erst noch die sentences entsprechend anpassen. Wenn es was bringt, bin ich am überlegen, ob sowas auch für groups zielführend wäre. Aber eines nach dem anderen.

Happy testing.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 20 April 2021, 11:21:15
Ein List des Devices:

Internals:
   CONFIGFILE FHEM/rhasspy-de.cfg
   DEF        baseUrl=http://rhasspy:12101 defaultRoom=cuarto de estar language=de useGenericAttrs=1
   FUUID      604dd2ff-f33f-1a4f-056c-ce4673ffea964c2d
   FVERSION   10_RHASSPY.pm:?/2021-04-19
   IODev      rhasspyMQTT2
   LANGUAGE   de
   MODULE_VERSION 0.4.9
   NAME       Rhasspy
   NR         20
   STATE      online
   TYPE       RHASSPY
   baseUrl    http://rhasspy:12101
   devspec    room=Rhasspy
   encoding   
   fhemId     fhem
   prefix     rhasspy
   useGenericAttrs 1

Da wird alles angezeigt, nur der defaultRoom nicht.

Und hier der helper:

   helper:
     defaultRoom cuarto
     custom:

Da ist der Raum nach dem ersten Leerzeichen abgeschnitten.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 20 April 2021, 11:31:36
Ah, jetzt ist der Bezugspunkt klar. habe das auch mal nach oben gezogen.

Was den spanischen defaultRoom angeht, müssen mal wieder Quotes her, damit parseParams das als Einheit zusammenhält:
defmod RHASSPY RHASSPY devspec=room=Rhasspy,devstrich0\
baseUrl=http://192.168.33.99:12101 defaultRoom="cuarto de estar" language=de useGenericAttrs=0

(räusper, IP/blocking (!) und use-default...)

NACHTRAG 1: Bitte FHEM neu starten oder auf sonstige Weise sicherstellen, dass Modulhash und Code zusammenpassen (z.B. RHASSPY löschen und neu anlegen), wenn ihr im laufenden Betrieb auf diese Mudulfassung wechselt!
NACHTRAG 2: Neuen Slot hinzugefügt mit einem Gesamtslot, der alle Namen, Räume und Gruppennamen beinhaltet (zum "Vorauslernen" für spätere Auswahl?)
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 20 April 2021, 11:35:04
Zitat von: Beta-User am 20 April 2021, 11:31:36
(räusper, IP/blocking (!) und use-default...)

Wie bitte?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 20 April 2021, 11:39:18
Zitat von: drhirn am 20 April 2021, 11:35:04
Wie bitte?
Deine angefragte DEF war die:
DEF        baseUrl=http://rhasspy:12101 defaultRoom=cuarto de estar language=de useGenericAttrs=1

Da sind m.E. zwei nicht mustergültige Dinge drind:
a) useGenericAttrs=1 ist sowieso der default => unnötig, kann weg.
b) baseUrl=http://rhasspy:12101
Das zeigt nicht auf eine IP-Adresse sondern einen hostname. Der muss aufgelöst werden, und wenn es damit Probleme gibt, blockiert im schlechtesten Fall FHEM komplett, mindestens aber solange, bis ggf. httputils melden, dass da was nicht klappt (unterstellt, die werden intern verwendet was zu empfehlen wäre).
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 20 April 2021, 15:20:17
Nochmal eine Iteration.

Neben dem Umzug von "defaultRoom" direkt in Internals (Bitte FHEM neu starten oder auf sonstige Weise sicherstellen, dass Modulhash und Code zusammenpassen (z.B. RHASSPY löschen und neu anlegen), wenn ihr im laufenden Betrieb auf diese Mudulfassung wechselt!), sind da noch ein paar Kleinigkeiten rund um CustomIntents und triggernde Rückgaben eingearbeitet.
Und es gibt eine kleine Demo-myUtils samt zugehöriger cref, die man als Basis für weitere eigene Entwicklungen nehmen könnte. Den Dialog-Teil habe ich noch nicht weiter getestet, aber die Logik ist jetzt:

Der erste zurückgegebene Wert kann eine einfache Text-response sein, ein Hash (=> Dialog) oder ein Array (1. Element: response, kann wieder SCALAR oder HASH sein), 2. Element: zu triggernde Devices (Komma-Liste), 3. Element: ggf. anderer Timeout).
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 20 April 2021, 17:49:48
Zitat von: Beta-User am 20 April 2021, 11:39:18
a) useGenericAttrs=1 ist sowieso der default => unnötig, kann weg.

Altlast. Tut aber auch nicht weh

Zitat
b) baseUrl=http://rhasspy:12101
Das zeigt nicht auf eine IP-Adresse sondern einen hostname. Der muss aufgelöst werden, und wenn es damit Probleme gibt, blockiert im schlechtesten Fall FHEM komplett, mindestens aber solange, bis ggf. httputils melden, dass da was nicht klappt (unterstellt, die werden intern verwendet was zu empfehlen wäre).

Wenn die Namensauflösung bei mir im Netzwerk nicht klappt, hab ich ganz andere Probleme als das ;)
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 20 April 2021, 18:20:50
...ich spreche auch nicht nur für deinen Anwendungsfall, sondern für die Leute, die eine FritzBox die Namensauflösung machen lassen...
(Das Thema kommt so alle Monat mal hier im Forum hoch)
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 21 April 2021, 08:28:29
Und noch eine Iteration :) .

Neben den zusätzlichen gDT-slots (auf sentence-Seite bisher noch nicht getestet, aber es kommt mir zielführend vor!) und den Anpassungen bzgl. der Demo-myUtils "kann" die jetzt auch die setter soweit auseinandernehmen, dass man sowas wie ein auf eine 100-er-Skala normiertes HUE- und CT-Mapping generieren kann (die Wertebereiche sind bei meinen Geräten wirklich teilweise signifikant unterschiedlich!).
(lustig ist auch, dass die HUEDevice einen "stop"-Befehl kennen, was mir bisher entgangen war und jetzt im RHASSPY-list lustig ausschaut...)

Die Idee wäre, den Color-Intent aufzubohren, dass der auch generische Anweisungen versteht und das jetzt mal vorläufig "SetColorParms" getaufte Baby irgendwie verarbeiten kann. Wie das genau gehen soll, steht noch in den Sternen, aber wie meistens: irgendwo muss man halt mal anfangen...
(Man sollte das dann später mal auch als rhasspyMapping anlegen können, der Parser dürfte damit klarkommen).

(Btw.: das wäre dann ein neues feature, die bisherigen Vorbereitungen sind aber keine Revolution, von daher kann man diese Version m.E. am 29. durchaus als Grundlage verwenden.)
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 21 April 2021, 09:35:59
Hmmmmm, was müsste ich an der Doku ändern?

Und die 99_RHASSPY_Demo_Utils.pm soll ein Beispiel für einen "Skill" sein? Also für einen Custom Intent, der nicht in der 99_myUtils.pm steht?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 21 April 2021, 10:00:42
Zitat von: drhirn am 21 April 2021, 09:35:59
Hmmmmm, was müsste ich an der Doku ändern?
Auf was bezieht sich das?
- myUtils: siehe unten
- zusätzliche Slots: man kann damit ggf. einfach die in Frage kommenden Geräte in der sentences.ini eingrenzen, z.B. für Helligkeit:
#brightness
(stelle|schalte|erhöhe|mache) $de.fhem.Device-light{Device} [$de.fhem.Room{Room}] [um] [(0..255){Value}] [prozent{Unit:percent}] (heller){Change:lightUp}
(stelle|schalte|senke|mache) $de.fhem.Device-light{Device} [$de.fhem.Room{Room}] [um] [(0..255){Value}] [prozent{Unit:percent}] (dunkler){Change:lightDown}

Das funktioniert dann aber nur noch, wenn auch die slots gefüllt sind, also an den in Frage kommenden Geräten der gDT gesetzt ist.
- color: Ist noch nicht fertig und evtl. nochmal isgesamt zu überarbeiten, würde ich im Moment nicht aktiv darstellen. Die Idee wäre, (einmal mehr) englische Keywords übergeben zu können (lightgreen, darkgrey,blue), und das Modul würde dann daraus einen Farbwert errechnen, den die Hardware versteht. Müßte man halt z.B. auch noch wissen, welchen Helligkeitswert man annimmt, wenn das Ding auf "Helligkeit 0" steht. Ist

Zitat
Und die 99_RHASSPY_Demo_Utils.pm soll ein Beispiel für einen "Skill" sein? Also für einen Custom Intent, der nicht in der 99_myUtils.pm steht?
Es sind in der Demo-Utils drei "Skills" drin, und das ganze dann halt gleich als Package.

Meine Testinstallation sieht bei den rhasspyIntents grade so aus:
attr RHASSPY rhasspyIntents Respeak=Respeak(NAME)\
SetAllOn=SetAllOn(Room,Type)\
SetCustomIntentsBasicTest=RHASSPY::Demo::BasicTest(siteId,Type)\
SetCustomIntentsDataTest=RHASSPY::Demo::DataTest(NAME, DATA)\
SetCustomIntentsDialogueTest=RHASSPY::Demo::DialogueTest(NAME,DATA)

Bzgl. Doku würde ich da erst mal gar nichts weiter machen. Die "alten" CusotmIntents sollten weiter funktionieren, und jetzt gibt es eben diese weiteren Demos, v.a. dazu, wie man ggf. DATA "auspackt". Vielleicht den Hinweis aufnehmen, dass man mit "help RHASSPY_Demo_Utils" eine (englische) Hilfe dazu bekommen kann.
DialogueTest müßte ich auch erst mal testen. "Eigentlich" müßte er gehen, das ist einfach ein Klon von der "shortcut"-Logik.


Bin grade noch am überlegen, ob es relativ einfach möglich ist, diese "Mehrfachnennungen" im list irgendwie zu vermeiden. Wenn der setter "pct" ist, ist ja doch sehr häufig auch der Rest (Reading usw.) "pct"...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 21 April 2021, 10:07:32
Woher weiß das Modul, wo die 99_RHASSPY_Demo_Utils.pm liegt? Bzw. wie sie heißt? Oder anders gefragt, muss die so heißen?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 21 April 2021, 10:27:27
Da das eine "myUtils"-Datei ist, sollte die wie üblich ins FHEM- (Modul-) Verzeichnis.
Zur Namensgebung:
99 => automatisch laden
"Utils" => damit sie unter "edit files" erscheint

Rest: Frei wählbar, aber der Link auf die "Initialize"-Funktion muss bei anderem Namen angepaßt werden.

Anders gefragt: Was stört dich am Namen?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 21 April 2021, 10:31:05
Zitat von: Beta-User am 21 April 2021, 10:27:27
aber der Link auf die "Initialize"-Funktion muss bei anderem Namen angepaßt werden.

Ich find das nicht. Wo genau?

Zitat
Anders gefragt: Was stört dich am Namen?

Hehe, überhaupt nichts. Ich wollte es nur wissen.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 21 April 2021, 10:36:45
Zitat von: drhirn am 21 April 2021, 10:31:05
Ich find das nicht. Wo genau?
sub ::RHASSPY_Demo_Utils_Initialize { goto &Initialize }
Um das myUtils-"Modul" zu registrieren, muss fhem.pl eine Initialize-Funktion haben, die eben genau dem Dateinamens-Schema entspricht (ohne den Zahlenpräfix); das ist genau gleich wie bei allen anderen Modulen und auch so im Wiki zu 99_myUtils.pm zu finden. Hier ist nur die Besonderheit, dass wir wegen des packages erst noch nach $main verweisen müssen => daher die beiden Doppelpunkte ;) .
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 21 April 2021, 10:48:38
Ahhh, verstehe. Danke für die Aufklärung!

Und was müssten wir tun, wenn wir das in einen Unterordner legen möchten? Nach opt/fhem/FHEM/rhasspy-intents z.B.?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 21 April 2021, 10:52:52
Und kannst du mir bitte noch timerTrigger erklären? V.a., wie ich den Trigger dann nutzen könnte?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 21 April 2021, 11:15:12
Zitat von: drhirn am 21 April 2021, 10:48:38
Und was müssten wir tun, wenn wir das in einen Unterordner legen möchten? Nach opt/fhem/FHEM/rhasspy-intents z.B.?
Hmm, also:
- afaik kann man nicht so einfach eine Sonderbehandlung für irgendwas in einem Unterverzeichnis haben, fhem.pl ist dafür nicht ausgelegt.
- man könnte sowas vielleicht via RHASSPY nachladen, aber:

Warum sollte man?

Im praktischen Leben ist es so:
- User will "normale" Funktionen haben. Dann macht er "normale" myUtils (wie gehabt).
- User will mehr. Dann lädt er sich die "Muster-package-myUtils" (für RHASSPY) aus "contrib" runter (dort aus dem angedachten RHASSPY-Verzeichnis?) und platziert die mittels svn_Get... an der richtigen Stelle (gleich mit "laden"-Kommando). Danach kann er eine Kopie ziehen (save as), muss dann eben den Initialize-Verweis anpassen und rauswerfen oder umbenennen, was er nicht braucht (oder die Demo wieder löschen).

Für eine Unterstruktur unterhalb ./FHEM sehe ich jedenfalls im Moment keinen Bedarf.
Oder übersehe ich mal wieder was?

Zitat von: drhirn am 21 April 2021, 10:52:52
Und kannst du mir bitte noch timerTrigger erklären? V.a., wie ich den Trigger dann nutzen könnte?
Die Kurzfassung ist in der commandref drin. Hintergrund ist folgender:
- bisher war es beim "einfachen speak" nach Ablauf des Timer so, dass man ein oder zwei Events (am RHASSPY-Device) hatte, nämlich den vom "speak" und das "Reading löschen" (?).
- jetzt ist es uU. ein eher allgemeines "playWav", und das Reading wird erst am Ende gelöscht.
- mit timerTrigger kann man jetzt bei Ablauf des (bei Wiederholung: ersten) Timers ein genau umrissenes Event auslösen. Einzige Einschränkung: es muss ein "label" für den Timer geben.

Darauf kann dann ein beliebiger Eventhandler (z.B. notify) hören, und dann wieder beliebige FHEM- oder Perl-Befehle auslösen. Beispiel: Weckautomation mit Aufdimmen des Lichts, Einschalten der Stereoanlage, Einstellen eines bestimmten Senders, ...

(Es wäre ggf. gut, wenn du in solchen Fällen einfach mal "nachbaust", was jeweils in der cref kurz angerissen ist. Dann sehen wir auch gleich, ob es a) sachlich korrekt ist (und nicht nur auf dem System paßt, auf dem ich es getestet hatte), und b) halbwegs verständlich...)
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 21 April 2021, 11:30:03
Zitat von: Beta-User am 21 April 2021, 11:15:12
Für eine Unterstruktur unterhalb ./FHEM sehe ich jedenfalls im Moment keinen Bedarf.
Oder übersehe ich mal wieder was?

Nun, es wäre schon irgendwie cool, wenn User A ein File mit einem Intent zur Verfügung stellt. Und User B die Datei dann einfach nur in den Ordner kopieren muss und schon den Intent zur Verfügung hat.

Zitat(Es wäre ggf. gut, wenn du in solchen Fällen einfach mal "nachbaust", was jeweils in der cref kurz angerissen ist. Dann sehen wir auch gleich, ob es a) sachlich korrekt ist (und nicht nur auf dem System paßt, auf dem ich es getestet hatte), und b) halbwegs verständlich...)

Keine Sorge, das mach ich eh immer. Aber manchmal weiß ich halt nicht, wie ich was nachbauen muss ;).
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 21 April 2021, 11:45:17
Zitat von: drhirn am 21 April 2021, 11:30:03
Nun, es wäre schon irgendwie cool, wenn User A ein File mit einem Intent zur Verfügung stellt. Und User B die Datei dann einfach nur in den Ordner kopieren muss und schon den Intent zur Verfügung hat.
Genauso könnte das doch laufen; nur dass eben direkt in ./FHEM mehrere 99_RHASSPY_.*Utils.pm vorhanden sein können, eine jede ganz hübsch und ordentlich mit einer Beschreibung des Intents, des korrekten Funktionsaufrufs, eines passenden sentence-Schnippsels und der Funktion in der zugehörigen cref...
(Das machen wir @attrTemplate in "speziellen Fällen" ähnlich: Wenn der User was passendes hat/haben will, wird (nur) der zugehörige Code runtergeladen).

Zitat
Keine Sorge, das mach ich eh immer. Aber manchmal weiß ich halt nicht, wie ich was nachbauen muss ;) .
Schon klar, dass das nicht immer einfach zu verstehen ist, was ich da so hinpinsle... Bei timerTrigger sollte es aber einfach sein: Den key in "tweaks" packen mit dem Wert "default", und dann einfach einen (kurzen) belabelten Timer anlegen. Fertig, bzw. bereit, das Ergebnis im Event-Monitor zu sehen ;) .
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 21 April 2021, 11:50:04
Zitat von: Beta-User am 21 April 2021, 11:45:17
Genauso könnte das doch laufen; nur dass eben direkt in ./FHEM mehrere 99_RHASSPY_.*Utils.pm vorhanden sein können

Ich bin ein Fan von Unterordnern zwecks Aufgeräumtheit ;)

ZitatSchon klar, dass das nicht immer einfach zu verstehen ist, was ich da so hinpinsle...

:D

timerTrigger jetzt trotzdem kapiert. Und frage mich dabei, ob wir nicht einfach standardmäßig ein Event triggern sollen. Spricht was dagegen?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 21 April 2021, 12:02:29
Zitat von: drhirn am 21 April 2021, 11:50:04
Ich bin ein Fan von Unterordnern zwecks Aufgeräumtheit ;)
Kann ich nachvollziehen, aber das framework gibt halt nur die "Ordnung via Benennung" her. Von daher könnte man auch "Utils" und "Demo" umdrehen?
Ansonsten sollte v.a. der Code ordentlich sein, also (mAn.) z.B. auch gepackaged; da wird es vermutlich noch etwas "guidance" für den einen oder anderen brauchen; v.a., was den Import von ggf. genutzten Funktionen angeht (auch sowas häufiges wie ReadingsVal, z.B.).

ZitatUnd frage mich dabei, ob wir nicht einfach standardmäßig ein Event triggern sollen. Spricht was dagegen?
M.E. nicht, wenn man von der "Gefahr" absieht, dass bei "unbelabelten" Timern vermutlich die Events teils (seitens einiger User) nicht sauber abgegriffen werden (mit .* am Ende).
Ehrlich gesagt war es so, dass mich im Nachhinein etwas wundert, dass vorher scheinbar keiner auf die Idee gekommen ist, Events zu generieren oder abzugreifen, um z.B. Sound-loops anzuschubsen...
Na ja, Rom und so.

Gibts du ein Signal, oder haben wir das jetzt schon beschlossen mit dem immer triggern?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 21 April 2021, 12:20:16
Zitat von: Beta-User am 21 April 2021, 12:02:29
Kann ich nachvollziehen, aber das framework gibt halt nur die "Ordnung via Benennung" her. Von daher könnte man auch "Utils" und "Demo" umdrehen?

Verstehe. Die Umbenennung wäre praktisch. Dann sind sie wenigstens sortiert.

Zitat
Gibts du ein Signal, oder haben wir das jetzt schon beschlossen mit dem immer triggern?

Naja, wenn nichts dagegen spricht, können wir das gerne so machen. Ist aber nicht dringend.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 21 April 2021, 12:48:24
Deaktivieren ist einfacher wie einbauen...

here you are :) .
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 21 April 2021, 14:32:39
Sodala, die CRef ist jetzt tippitoppi. Hab sie auch extra noch durch einen HTML-Syntaxchecker laufen lassen. Manoman, waren da Fehler drin ;D

https://github.com/drhirn/fhem-rhasspy/blob/0.4.9/opt/fhem/FHEM/10_RHASSPY.pm
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 21 April 2021, 15:03:23
Zitat von: drhirn am 21 April 2021, 14:32:39
Sodala, die CRef ist jetzt tippitoppi. Hab sie auch extra noch durch einen HTML-Syntaxchecker laufen lassen. Manoman, waren da Fehler drin ;D
...einen Logikfehler habe ich in der cref mAn. noch gefunden, yellow sollte wohl F0F000 sein, oder täuschen mich meine Trockenübungsaugen?

(Ansonsten ist es schade, dass die Unterschiede in github hier nicht im Detail angezeigt werden. Ist nicht eben mein Spezialgebiet, und vermutlich könnte ich da noch das eine oder andere lernen für meine anderen "Kunstwerke"... Also falls du mal Muße hast ::) ).

Anbei nochmal ein Zwischenstand, der ggf. auch das Setzen von CT, Saturation, HUE und RGB erlaubt, wenn a) das gDT-mapping sowas hergibt und b) ein passender Wert unter dem entsprechenden Keyword übergeben wird, also "Colortemp" für einen CT-Wert, "Rgb" (oder Color) für einen RGB-Wert im HEX-Format (F0F000) oder Saturation.

Wird ein RGB-Wert übergeben, wird im Moment nicht gerechnet, sondern das (auch) als Helligkeitsangabe verstanden, alles andere ist nummerisch 0-100 zu übermitteln und wird als Prozentangabe zwischen dem verfügbaren Minimal- und Maximalwert verstanden.
Muss erst mal testen, inwieweit das klappt, dann kann es ggf. irgendwann auch mit der Übergabe von "keywords" weitergehen, und im Moment habe ich mir auch keinen Kopf zur Kompabilität mit einer späteren Gruppenfunktion gemacht...

(Diese Version ist in diesem Punkt (Color Intent) vermutlich wieder ziemlich gefährlich, da intensiv "rumgehasht" wird und nichts getestet ist!).
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 21 April 2021, 15:18:53
Zitat von: Beta-User am 21 April 2021, 15:03:23
...einen Logikfehler habe ich in der cref mAn. noch gefunden, yellow sollte wohl F0F000 sein, oder täuschen mich meine Trockenübungsaugen?

Eigentlich ist's #FFFF00. Ich hab da irgend eine Zahl genommen. Aber hast recht, ist natürlich nicht korrekt. Grün war's auch nicht.

Zitat(Ansonsten ist es schade, dass die Unterschiede in github hier nicht im Detail angezeigt werden. Ist nicht eben mein Spezialgebiet, und vermutlich könnte ich da noch das eine oder andere lernen für meine anderen "Kunstwerke"... Also falls du mal Muße hast ::) ).

Du meinst so: https://github.com/drhirn/fhem-rhasspy/commit/8746b9ab9bd7fa6bf86386c81d912d8953cd0b24

Über deine Kunstwerke können wir dann gerne mal Reden. Welche wären das? Erinnere mich dann einfach mal daran.

Zitat
(Diese Version ist in diesem Punkt (Color Intent) vermutlich wieder ziemlich gefährlich, da intensiv "rumgehasht" wird und nichts getestet ist!).

Ich könnte da eine 1.4.10 draus machen. Oder eine 0.5.1? In der 0.4.9 möchte ich jetzt keine großen Veränderungen mehr.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 21 April 2021, 15:58:52
bzgl. dieser beiden Punkte:

Zitat# Attribute:
- "shortcuts" in "rhasspyShortcuts" umbenennen
Sollte kein Hexenwerk sein, ist aber ein "breaking change" (ich will für die Kleinikgeit nicht unbedingt noch Transfercode schreiben...).

Umsetzen? (0.4.10, s.u.)

Zitat# Custom Intents
- Bei Verwendung des Dialouges wenn man keine Antwort spricht, bricht Rhasspy ab. Die voice response "Tut mir leid, da hat etwas zu lange gedauert" wird
   also gar nicht ausgegeben.
Muss ich mir ansehen, bin aber unsicher, ob das nicht ggf. damit zusammenhängt, dass Stille gerne als "nein" interpretiert wird und dafür ein "stiller Abbruch" vorgesehen ist, wenn RHASSPY nicht mehr wartet. (Aber eigentlich nur dann, evtl. ist mir da ein Fehler unterlaufen).
Wenn es eine "silent cancellation" war, sollte das response-Reading leer ('') sein.
=> etwas mehr Info dazu wäre evtl. hilfreich.

ZitatIch könnte da eine 1.4.10 draus machen. Oder eine 0.5.1? In der 0.4.9 möchte ich jetzt keine großen Veränderungen mehr.
1.4.10 ist "steil", 0.4.10 fände ich ok.

Ich _glaube_, dass es nur für die gefählich sein kann, die das aktiv austesten, für alle anderen sollte es keine Probleme bringen, und wenn ich dann die Tage mal an's Testen komme, ist auch besser abschätzbar, wie groß das Gefahrenpotential effektiv ist (ich hoffe: 0  ::) ).
Von daher wäre es mir am liebsten, wir könnten die experiementellen Teile einfach in den "rolling" Code integriert lassen (und/oder notfalls den erweiterten Code auf möglichst einfache Weise deaktivieren). Dann ist es für mich einfacher, ggf. erforderliche Bugfixes in den regulären Code-Teilen einzupflegen.
Ich wollte es halt nicht ohne den üblichen Warnhinweis hier posten.

Meine Kunstwerke wären die MySensors-Module, Weekday- und RandomTimer sowie Twilight...

Nachtrag: das via github sichtbare diff ist im Detail leider nicht so aussagekräftig wie im Code-Bereich.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 21 April 2021, 16:24:54
Zitat von: Beta-User am 21 April 2021, 15:58:52
bzgl. dieser beiden Punkte:

Umsetzen? (0.4.10, s.u.)

Total unwichtig die zwei Punkte.
Und da hast natürlich recht. Das mit der 1.4.10 war ein Tippfehler :D

Zitat
Ich _glaube_, dass es nur für die gefählich sein kann, die das aktiv austesten, für alle anderen sollte es keine Probleme bringen, und wenn ich dann die Tage mal an's Testen komme, ist auch besser abschätzbar, wie groß das Gefahrenpotential effektiv ist (ich hoffe: 0  ::) ).
Von daher wäre es mir am liebsten, wir könnten die experiementellen Teile einfach in den "rolling" Code integriert lassen (und/oder notfalls den erweiterten Code auf möglichst einfache Weise deaktivieren). Dann ist es für mich einfacher, ggf. erforderliche Bugfixes in den regulären Code-Teilen einzupflegen.

Ich habe sowieso entschieden, dass es in Zukunft nur noch zwei Versionen geben wird. Eine "master" und eine "dev". Ist viel einfacher.

ZitatMeine Kunstwerke wären die MySensors-Module, Weekday- und RandomTimer sowie Twilight...

Ist notiert.

ZitatNachtrag: das via github sichtbare diff ist im Detail leider nicht so aussagekräftig wie im Code-Bereich.

Kann nicht folgen. Welcher Code-Bereich? Bzw., kann ich was tun, um das sichtbarer für dich zu machen?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 21 April 2021, 17:05:56
Zitat von: drhirn am 21 April 2021, 16:24:54
Kann nicht folgen. Welcher Code-Bereich? Bzw., kann ich was tun, um das sichtbarer für dich zu machen?
Hab's jetzt mal in notepad++ verglichen, da sieht man die Details der Veränderungen teils besser, paßt schon...

Ein paar kleine Kritikpunkte hätte ich noch:
- "Tweaks" ist jetzt etwas "kurz", und der "Vorläufigkeitsvermerk" ist weg. Das ist bzgl. der Timer-Geschichten ok, aber z.B. das eingangs erwähnte siteId2room gibt es noch nicht...
- beim CLIENT steht keine IP-Adresse
- parseParams braucht bei Leerzeichen im Text quotes, vermutlich müsste das so lauten:
ZitatDefaultError= DefaultConfirmation="Klaro, mach ich"

(Generell hatte ich beim Überarbeiten der .md noch ein paar Kleinigkeiten angemerkt, von denen ich grade nicht mehr weiß, ob sie in der cref noch fehlen oder ergänzt werden sollten).
Zitat
Total unwichtig die zwei Punkte.
Das mit dem rhasspyShortcuts ist anbei erledigt und V. auf 0.4.10 gesetzt.
Da wir beim Aufräumen sind:
- configFile könnte man auch in languageFile umbenennen, andere config-Elemente sind da ja nicht drin.
- Ob man fetchSideIds in "update" integrieren sollte?
(- Bitte schau auch nochmal in diesem Sinne kritisch drüber).

Zitat
Ich habe sowieso entschieden, dass es in Zukunft nur noch zwei Versionen geben wird. Eine "master" und eine "dev". Ist viel einfacher.
Hatte mich schon gewundert, dass es so viele Zweige gibt, aber ich bin ja bekennender github-DAU...

Es ist schon ok, im Rahmen des dev-Zweigs dann von Zeit zu Zeit auch die Version hochzudrehen, das ist aber eigentlich eher ein "Marker", damit man ggf. in der Diskussion über ein Problem besser eingrenzen kann, über welche Fassung man jeweils redet. Den Punkt finde ich bei svn einleuchtender (was nicht bedeuten soll, dass man sowas nicht auch via git hinbekäme).

Im Moment sehe ich allerdings wie gesagt keinen echten Grund, irgendeine Fassung als "master" oder "dev" anzusehen, weil die experimentellen Teile relativ gut abzugrenzen sind, und wir auch Verbesserungen ggf. direkt im übrigen Code einpflegen. Es ist im Moment eher eine "rolling beta" (und das zu ändern vermutlich den Aufwand (noch) nicht wert).
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 21 April 2021, 22:11:00
So, zum Ende des Tages noch ein paar Ergebnisse meiner Kurztests:

1. Die Zuordnung der Geräte scheint deutlich besser zu sein, wenn man passende "Sub-Slots" aus den gDT verwendet.
sentences.ini:
[de.fhem:SetNumeric]
\[ ( schalt | mach ) ] $de.fhem.Device-media{Device} [um] [(0..10){Value!int}] [dezibel{Unit}] ( lauter:volUp | leiser:volDown){Change}
[de.fhem:SetNumeric]
( mach | stelle ) $de.fhem.Device-thermostat{Device} [um] [(0..10){Value!int}] [grad{Unit}] ( wärmer:tempUp | kälter:tempDown ){Change}
( mach |schalt|schalte|stelle) $de.fhem.Device-light{Device} [um] [(0..100){Value}] [prozent{Unit:percent}] ( heller:lightUp | dunkler:lightDown){Change}
(schalt | schalte | stelle ) $de.fhem.Device-light{Device} auf (0..100){Value!float}
( mehr{Change:lightUp} | weniger{Change:lightDown} ) $de.fhem.Device-light{Device} [$de.fhem.Room{Room}]
( mach |schalt|schalte|stelle) $de.fhem.Device{Device} [um] [(0..100){Value}] [prozent{Unit:percent}] (heller){Change:lightUp}
( mach |schalt|schalte|stelle) $de.fhem.Device{Device} [um] [(0..100){Value}] [prozent{Unit:percent}] (dunkler){Change:lightDown}
(schalt | schalte | stelle ) $de.fhem.Device{Device} auf (0..100){Value!float}
( mehr{Change:lightUp} | weniger{Change:lightDown} ) $de.fhem.Device{Device} [$de.fhem.Room{Room}]


2. Warmweiss/Kaltweiss klappt mit den gDT-Analysen, rgb-Kommandos nicht. Details dazu muss ich mir noch ansehen, aber: Im Prinzip funktioniert es, und FHEM läuft auch dann noch, wenn die Zuordnung nicht klappt :) 8) .
sentences.ini:
[de.fhem:SetColor]
\[setze|färbe] $de.fhem.Device-light{Device} [$de.fhem.Room{Room}] [auf die Farbe] (grün{Color:green}  | hellgrün{Color:lightgreen} | rot{Rgb:FF0000} | (warm weiss){Colortemp:100} | (kalt weiss){Colortemp:0} | (mittleres weiss){Colortemp:50} )


M. E. ein ziemlicher Schritt nach vorne, insgesamt gesehen.

Nachtrag: Neben Colortemp gehen auch Hue und Saturation; die Ergebnisse sind zwar bei Saturation optisch nicht toll, aber das hängt an den Leuchtmitteln...
sentences dazu:
\[setze|färbe] $de.fhem.Device-light{Device} [$de.fhem.Room{Room}] [auf die Farbe] (grün{Saturation:90}  | hellgrün{Saturation:30} | rot{Hue:1} | (warm weiss){Colortemp:100} | (kalt weiss){Colortemp:0} | (mittleres weiss){Colortemp:50} )
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 22 April 2021, 11:31:45
Zitat von: Beta-User am 21 April 2021, 17:05:56
- "Tweaks" ist jetzt etwas "kurz", und der "Vorläufigkeitsvermerk" ist weg. Das ist bzgl. der Timer-Geschichten ok, aber z.B. das eingangs erwähnte siteId2room gibt es noch nicht...
- beim CLIENT steht keine IP-Adresse

So viel kürzer ist Tweaks nicht? Aber der Vorläufigkeitsvermerk ist wieder dabei.

Zitat
- parseParams braucht bei Leerzeichen im Text quotes, vermutlich müsste das so lauten:
DefaultConfirmation="Klaro, mach ich"

Dann habe ich Anführungszeichen in der Antwort. Wird da überhaupt parseParams verwendet?

Zitat(Generell hatte ich beim Überarbeiten der .md noch ein paar Kleinigkeiten angemerkt, von denen ich grade nicht mehr weiß, ob sie in der cref noch fehlen oder ergänzt werden sollten).

Abgleich MD<->CRef hab ich noch nicht gemacht.

ZitatDas mit dem rhasspyShortcuts ist anbei erledigt und V. auf 0.4.10 gesetzt.

Perfekt! Danke!

Zitat- configFile könnte man auch in languageFile umbenennen, andere config-Elemente sind da ja nicht drin.

Ja, sehr gerne!

Zitat- Ob man fetchSideIds in "update" integrieren sollte?

Naja, wir müssen's auf jeden Fall weiterhin gleich nach dem Start des Moduls ausführen. Aber es würde schon irgendwie Sinn ergeben, das zu verschieben.

ZitatEs ist schon ok, im Rahmen des dev-Zweigs dann von Zeit zu Zeit auch die Version hochzudrehen, das ist aber eigentlich eher ein "Marker", damit man ggf. in der Diskussion über ein Problem besser eingrenzen kann, über welche Fassung man jeweils redet. Den Punkt finde ich bei svn einleuchtender (was nicht bedeuten soll, dass man sowas nicht auch via git hinbekäme).

In GitHub gibt's auch Commits.

ZitatIm Moment sehe ich allerdings wie gesagt keinen echten Grund, irgendeine Fassung als "master" oder "dev" anzusehen, weil die experimentellen Teile relativ gut abzugrenzen sind, und wir auch Verbesserungen ggf. direkt im übrigen Code einpflegen. Es ist im Moment eher eine "rolling beta" (und das zu ändern vermutlich den Aufwand (noch) nicht wert).

"master" wäre einfach eine gut getestet und nachweislich funktionierende Version.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 22 April 2021, 12:43:00
Zitat von: Beta-User am 21 April 2021, 22:11:00
2. Warmweiss/Kaltweiss klappt mit den gDT-Analysen, rgb-Kommandos nicht. Details dazu muss ich mir noch ansehen, aber: Im Prinzip funktioniert es, und FHEM läuft auch dann noch, wenn die Zuordnung nicht klappt :) 8) .
sentences.ini:
[de.fhem:SetColor]
\[setze|färbe] $de.fhem.Device-light{Device} [$de.fhem.Room{Room}] [auf die Farbe] (grün{Color:green}  | hellgrün{Color:lightgreen} | rot{Rgb:FF0000} | (warm weiss){Colortemp:100} | (kalt weiss){Colortemp:0} | (mittleres weiss){Colortemp:50} )


M. E. ein ziemlicher Schritt nach vorne, insgesamt gesehen.

Nachtrag: Neben Colortemp gehen auch Hue und Saturation; die Ergebnisse sind zwar bei Saturation optisch nicht toll, aber das hängt an den Leuchtmitteln...
sentences dazu:
\[setze|färbe] $de.fhem.Device-light{Device} [$de.fhem.Room{Room}] [auf die Farbe] (grün{Saturation:90}  | hellgrün{Saturation:30} | rot{Hue:1} | (warm weiss){Colortemp:100} | (kalt weiss){Colortemp:0} | (mittleres weiss){Colortemp:50} )

Kannst du mir bitte mal ein DEV von so einer Lampe posten?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 22 April 2021, 13:17:41
...damit das mit den Farben "halbwegs" rund wird, ist anbei dann auch das mit "Rgb" bzw. RGB-Werten für "Color" gefixt. Da es grade so schön war, gibt es das ganze dann auch gleich als Gruppen-Intent (der Teil ist noch ungetestet).
Damit fehlt bei den Farben "eigentlich nur noch" die Konvertierung zwischen verschiedenen Farbräumen bzw. die Berücksichtigung eines bereits gesetzten oder im JSON enthaltenen Helligkeitswerts. (Also falls jemand Lust hat, Farbe war eigentlich gar nicht mein Thema, hat sich halt ergeben ::) ...)



Ein "uninitialized"-Warning ist mir noch vor die Flinte gelaufen, die ist (hoffentlich) auch gefixt.



Und zu guter Letzt war es unschön, wenn sich Rhasspy über fehlende Detail-Slots beschwert hat und deswegen das Training abgebrochen hat. Da davon auszugehen ist, dass ggf. Einsteiger erst mal alles kopieren und dann auch über das Problem stolpern (auch bei den "alten" slots), werden alle slots jetzt zwangsweise erstellt. Kann man abschalten mit
attr rhasspy updateSlots=noEmptySlots=1
Zusätzlich habe ich mal testweise die Option drin, overwrite auszuschalten:
attr rhasspy updateSlots=overwrite_all=false
Bin noch nicht sicher, ob das eine gute Idee ist...
Jedenfalls ist "tweaks" jetzt um diese Einträge länger

Zitat von: drhirn am 22 April 2021, 11:31:45
Dann habe ich Anführungszeichen in der Antwort. Wird da überhaupt parseParams verwendet?
Öhm, vermutlich dann nicht...



configFile heißt jetzt auch languageFile, allerdings muss das für configDB weiter als Internal CONFIGFILE heißen.

Zitat
Naja, wir müssen's auf jeden Fall weiterhin gleich nach dem Start des Moduls ausführen. Aber es würde schon irgendwie Sinn ergeben, das zu verschieben.
Ausführung und Verortung in den settern sind zwei Paar Stiefel. Mache ich bei Gelegenheit, Wunsch für den Namen? Würde das "fetch" weglassen, also "update siteIds"?

ZitatIn GitHub gibt's auch Commits.
Schon klar, aber wenn ich als User irgendwas installiert habe: Wie komme ich zur fraglichen Commit-Id um genaue Rückmeldung an den Entwickler zu geben?

Zitat
"master" wäre einfach eine gut getestet und nachweislich funktionierende Version.
In der Theorie klingt das gut. In der Praxis haben wir 7 Installationen, die bisher in "statistics" auftauchen. Da ist m.E. eine einzige "rolling" (noch) die bessere Variante, selbst wenn man eine hohe Dunkelziffer bei eventuellen Testinstallationen unterstellt.

Mein Test-dummy - die setList entspricht dem, was bei einer HUEDevice-Gruppe farbiger Lampen mit getAllSets() kommt:
defmod devstrich0 dummy
attr devstrich0 userattr genericDeviceType
attr devstrich0 alias Mülleimer
attr devstrich0 genericDeviceType light
attr devstrich0 group global_test,
attr devstrich0 readingList a b c desired-temp temperature
attr devstrich0 room H Harmony
attr devstrich0 setList off:noArg on:noArg toggle:noArg statusRequest:noArg pct:colorpicker,BRI,0,1,100 bri:colorpicker,BRI,0,1,254 rgb:colorpicker,RGB color:colorpicker,CT,2000,1,6500 ct:colorpicker,CT,154,1,500 hue:colorpicker,HUE,0,1,65535 sat:slider,0,1,254 xy dimUp:noArg dimDown:noArg ctUp:noArg ctDown:noArg hueUp:noArg hueDown:noArg satUp:noArg satDown:noArg alert:none,select,lselect,breathe,okay,channelchange,finish,stop effect:none,colorloop lights rename savescene deletescene scene: off-for-timer on-till-overnight off-till-overnight intervals off-till on-for-timer blink on-till

Hatte auch mit einer MQTT2_DEVICE-RGBW-Milight experimentiert, die u.A. auch HUE (0-359) kennt; die hatte auch (auf Hue) nachvollziehbar reagiert. Allerdings war mir die korrekte Farbbenennung bisher nicht wichtig gewesen, das waren irgendweche Werte; das sollte man also ggf. checken und was "sinnvolles" in die Doku aufnehmen (FF0000 => Hue 0 in der 0-100-Skala?)
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 22 April 2021, 14:13:37
Zitat von: Beta-User am 22 April 2021, 13:17:41
...damit das mit den Farben "halbwegs" rund wird, ist anbei dann auch das mit "Rgb" bzw. RGB-Werten für "Color" gefixt. Da es grade so schön war, gibt es das ganze dann auch gleich als Gruppen-Intent (der Teil ist noch ungetestet).
Damit fehlt bei den Farben "eigentlich nur noch" die Konvertierung zwischen verschiedenen Farbräumen bzw. die Berücksichtigung eines bereits gesetzten oder im JSON enthaltenen Helligkeitswerts. (Also falls jemand Lust hat, Farbe war eigentlich gar nicht mein Thema, hat sich halt ergeben ::) ...)
Mit Lichtfarben hab ich auch nicht viel am Hut. Ich verwende nur RGB. Und das ganz selten. Aber ich schau dann mal, wie dein leuchtender Mülleimer funktioniert ;D


ZitatUnd zu guter Letzt war es unschön, wenn sich Rhasspy über fehlende Detail-Slots beschwert hat und deswegen das Training abgebrochen hat. Da davon auszugehen ist, dass ggf. Einsteiger erst mal alles kopieren und dann auch über das Problem stolpern (auch bei den "alten" slots), werden alle slots jetzt zwangsweise erstellt. Kann man abschalten mit
attr rhasspy updateSlots=noEmptySlots=1
Zusätzlich habe ich mal testweise die Option drin, overwrite auszuschalten:
attr rhasspy updateSlots=overwrite_all=false
Bin noch nicht sicher, ob das eine gute Idee ist...
Jedenfalls ist "tweaks" jetzt um diese Einträge länger
Hmm. Bin nicht sicher, ob man Usern das Denken abnehmen sollte. Und innerhalb von Rhasspy wird das immer noch passieren, wenn man die Sentences davor anlegt.
Aber schaden tut das nicht.
Die zweite Option ist allerdings riskant. Könnte dazu führen, dass Rhasspy Devices erkennt, die es schon lange nicht mehr gibt, weil einer vergessen hat, dass er die Option gesetzt hat. Aber könnte auch manchmal praktisch sein.

Du meinst aber
attr Rhasspy rhasspyTweaks updateSlots=overwrite_all=false
oder?

ZitatconfigFile heißt jetzt auch languageFile, allerdings muss das für configDB weiter als Internal CONFIGFILE heißen.
8)

ZitatAusführung und Verortung in den settern sind zwei Paar Stiefel. Mache ich bei Gelegenheit, Wunsch für den Namen? Würde das "fetch" weglassen, also "update siteIds"?
Es ist eigentlich kein "update". Je nachdem, von welcher Seite man das sieht. ;)
Aber ist ok für mich.

ZitatSchon klar, aber wenn ich als User irgendwas installiert habe: Wie komme ich zur fraglichen Commit-Id um genaue Rückmeldung an den Entwickler zu geben?
So z.B.: https://github.com/drhirn/fhem-rhasspy/commits/dev
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 22 April 2021, 14:26:52
Zitat von: drhirn am 22 April 2021, 14:13:37
Mit Lichtfarben hab ich auch nicht viel am Hut. Ich verwende nur RGB. Und das ganz selten. Aber ich schau dann mal, wie dein leuchtender Mülleimer funktioniert ;D
Viel Spaß beim Testen. Wenn du die Gruppenfunktion testen willst, brauchst du halt mehrere Mülleimer ;D .

Zitat
Hmm. Bin nicht sicher, ob man Usern das Denken abnehmen sollte. Und innerhalb von Rhasspy wird das immer noch passieren, wenn man die Sentences davor anlegt.
Na ja, das ist so eine Frage, über die man trefflich streiten kann. Grundsätzlich sollte man m.E. unnötige Fehlerquellen eliminieren, es sind auch so schon genug Baustellen, über die man stolpern kann.

Zitat
Die zweite Option ist allerdings riskant. Könnte dazu führen, dass Rhasspy Devices erkennt, die es schon lange nicht mehr gibt, weil einer vergessen hat, dass er die Option gesetzt hat. Aber könnte auch manchmal praktisch sein.
Sehe ich ähnlich, und bin dabei sogar unsicher, ob man das für Gruppen- und "normale" slots getrennt machen müßte.
Gedanklicher Hintergrund ist der: Wenn man "nur" gDT-Mapping macht, hat man (hoffentlich) kein Problem. Fügt man aber einzelne Devices zu einem Slot auf der Rhasspy dazu, ist das ggf. hilfreich, um bestimmte Funktionalitäten anzuflanschen, die via gDT nicht gehen, oder ggf. eben dann irgendeinen "Hybriden" oä. zu erzeugen. Hat fast nichts gekostet, also dachte ich, es könnte evtl. manchmal praktisch sein...
Zitat
Du meinst aber
attr Rhasspy rhasspyTweaks updateSlots=overwrite_all=false
oder?
8)
...versenkt...

Zitat
Es ist eigentlich kein "update". Je nachdem, von welcher Seite man das sieht. ;)
Aber ist ok für mich.
Ist schon richtig, der Rest geht (eher) in Richtung Rhasspy, hier holen wir was ab...
Dann lassen wir es wie es ist...

Zitat
So z.B.: https://github.com/drhirn/fhem-rhasspy/commits/dev (https://github.com/drhirn/fhem-rhasspy/commits/dev)
Ja. Alles bekannt.
Aber wenn ich als User irgendwann mal was installiert habe, habe ich nirgends einen automatisch erzeugten Kenner, es sei denn, der Developer hat einen (manuell!) eingefügt. Ergo kann ich dann nur wieder raten, welche Version es denn ist, wenn es ein dev ist, der eben nur bei wesentlicheren Änderungen eine neue Nummer vergibt....
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 22 April 2021, 14:49:12
Zitat von: Beta-User am 22 April 2021, 14:26:52
Na ja, das ist so eine Frage, über die man trefflich streiten kann. Grundsätzlich sollte man m.E. unnötige Fehlerquellen eliminieren, es sind auch so schon genug Baustellen, über die man stolpern kann.
Es ist halt kein Modul-Problem. Und Support für Rhasspy können andere besser als ich.
Aber ich wehre mich nicht gegen die Funktion. Ist mir selber schon oft genug passiert. Deswegen ja damals auch der Hinweis, dass man updaten können muss, ohne ein Training zu starten.

Zitat
Aber wenn ich als User irgendwann mal was installiert habe, habe ich nirgends einen automatisch erzeugten Kenner, es sei denn, der Developer hat einen (manuell!) eingefügt. Ergo kann ich dann nur wieder raten, welche Version es denn ist, wenn es ein dev ist, der eben nur bei wesentlicheren Änderungen eine neue Nummer vergibt....

Ah, verstehe was du meinst. Bei "dev" könnte ich sagen, "mach ein Update und frag dann nochmal". Und in der "master" brauchen wir dann sowieso eine Versionsnummer im Code. Haben wir ja auch.

Aber, ich hab ja inzwischen eh einen SVN-Zugang genehmigt bekommen*. Dort wird dann die jeweilige "master" abgelegt. Weiterentwickeln möchte ich aber weiterhin auf GitHub.

*Ich brauch dann noch einen SVN Crash-Kurs ;)
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 22 April 2021, 15:13:50
Zitat von: drhirn am 22 April 2021, 14:49:12
Es ist halt kein Modul-Problem.
Sehe ich auch so. Das "Problem" ist, dass die die Erfahrung haben eher eingrenzen können, ob es ein Modul-Problem ist, aber für den typischen User ist es meist nur "ein Problem", das dann halt "irgendwo" eingekippt ist, wo es ggf. halbwegs (oder nicht mal das) paßt. Und damit ist es auf deinem Tisch, ganz gleich, wie oft du den User darauf hinweist, dass es ein ZigBee-Problem ist, er aber der Überzeugung, es mit einem MQTT2_DEVICE zu tun zu haben...

Zitat
Ah, verstehe was du meinst. Bei "dev" könnte ich sagen, "mach ein Update und frag dann nochmal". Und in der "master" brauchen wir dann sowieso eine Versionsnummer im Code. Haben wir ja auch.
Klar, "master" wird/sollte immer etwas "besser gepflegt" sein als irgendein Zwischenstand, mit dem man ggf. einfach nur mal was ausprobiert hat.

Das Problem besteht mAn. vor allem bei diesen Zwischenständen. Kommt z.b. eine "uninitialized"-Rückmeldung, und die Zeilennummer ist zwischendurch verrutscht, ist es oft ziemlich schwer, wieder die richtige Stelle zu finden, um "das bißchen" zu fixen. Dem kommt man nur bei, wenn man das (genau) an der Version checken kann, die der User auch hat (oder man muss nachfragen, was denn in der Zeile steht usw. usf).

Zitat
Aber, ich hab ja inzwischen eh einen SVN-Zugang genehmigt bekommen*. Dort wird dann die jeweilige "master" abgelegt. Weiterentwickeln möchte ich aber weiterhin auf GitHub.

*Ich brauch dann noch einen SVN Crash-Kurs ;)
Falls du git-Kommandos auf der Komandozeile kennst: alles entspannt. Sonst auch nicht dramatisch.
Es gibt eine kleine Anleitung (von Boris?) in der Developer-Ecke zu den vorbereitenden Checks, die man machen sollte (v.a. das "property setting", damit die Versionierung klappt), ansonsten einfach fragen, oder auch mal CoolTux wegen eines Web-Meetings anpingen, dann können wir das auch kurz zu dritt durchgehen.

Hattest du Rudi angepingt wegen des Verzeichnisthemas?
Sehe da im Moment drei+ Dateien:
- RHASSPY selbst (würde noch nicht in ./FHEM gehen);
- die de-cfg (und falls Spanisch auch aktuell ist: gerne auch die!)
- die "Demo"-Utils
(- (sehr vielleicht) eine sentences.ini).



Bzgl. dem "master"-Thema noch:
Falls noch Kleinigkeiten sind, wird es uU. aufwändig, "backports" und "dev" parallel zu pflegen.
Es macht sicher Sinn, nicht jeden Zwischenstand ins svn zu schubsen, aber z.B. mal angenommen, wir finden in der aktuellen Version 0.4.11 kein akutes Problem, würde ich das auch so ins svn (aktuell ja sowieso nur contrib) schubsen. Wer mittesten will und das Vertrauen hat, dass das "schon passen wird", kann sich das unproblematisch von da holen, wer einsteigt, wird zum "Zwangstester", und wer eine für ihn akzeptable laufende Version hat, kann die ja solange nutzen, bis er "über die Klippe" springen will.

Btw.: wenn das mit meinen Lamellen (venetian blind) mal läuft und sich die Trefferquote zu meiner Zufriedenheit entwickelt hat, sehe ich auch nicht den großen Bedarf an weiteren features oder Revolutionen.
Bleiben die wenigen bekannten Baustellen (allen voran: selection bei matches outside oder mehreren Geräten), aber sonst?
Das kann man dann auch gemächlicher angehen lassen...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 22 April 2021, 15:19:54
Zitat von: Beta-User am 22 April 2021, 15:13:50
Hattest du Rudi angepingt wegen des Verzeichnisthemas?
Sehe da im Moment drei+ Dateien:
- RHASSPY selbst (würde noch nicht in ./FHEM gehen);
- die de-cfg (und falls Spanisch auch aktuell ist: gerne auch die!)
- die "Demo"-Utils
(- (sehr vielleicht) eine sentences.ini).

Jup. Er war einverstanden. Ich habe aber eh immer nur von contrib gesprochen.
Und ja, bis auf die sentences.ini sehe ich das gleich wie du. Alle drei in einen Ordner contrib/RHASSPY
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 22 April 2021, 15:43:25
Im Moment ist es klar, dass es erst mal _nur_ contrib sein sollte.
Mittelfristig dann: 10_RHASSPY.pm nach ./FHEM, der Rest bleibt in contrib, dazu kommen dann ggf. weitere myUtils-Intents, Sprachfiles, whatever, und ggf. dann wieder ein dev-Zweig, wenn es (wieder) einen gibt.

Sollen wir am WE mal einen Zeitslot einplanen, auch wegen der Präsentation?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 23 April 2021, 08:06:04
Mal wieder ein update:

- gDT "thermometer" (mit temperature und humidity) wird jetzt auch erkannt;
- SetColorGroup ist getestet, scheint zumindest auf den ersten Blick stressfrei zu funktionieren;
Mein (rudimentärer) Test-sentence:

[de.fhem:SetColorGroup]
\[setze|färbe] (alle | sämtliche ) $de.fhem.Group{Group} [im] [( überall:global | $de.fhem.Room){Room}]  [auf die Farbe] ( rot{Hue:1} | (warm weiss){Colortemp:100} | (kalt weiss){Colortemp:0} | (mittleres weiss){Colortemp:50} )


Dann hätte ich noch ein Beispiel für eine CustomIntent-file: siteId2room. Einstellungen in RHASSPY siehe cref, sentence:

[de.fhem:siteId2room]
( Ortswechsel  | begib dich ) ( ins | in den ) $de.fhem.Room{Room}


(Jemand sollte dann mal wieder die cref ergänzen...)
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 23 April 2021, 09:39:23
Ich bekomm bei SetColorGroup immer den Hinweis, dass kein passendes Gerät gefunden wurde.

Was ist fehlt an dem Device?


defmod Stimmungsleuchte dummy
attr Stimmungsleuchte genericDeviceType light
attr Stimmungsleuchte group Lampen
attr Stimmungsleuchte icon light_party
attr Stimmungsleuchte readingList pct rgb
attr Stimmungsleuchte rhasspyGroup Lampen
attr Stimmungsleuchte rhasspyMapping SetOnOff:cmdOn=on,cmdOff=off\
GetOnOff:currentVal=state,valueOff=off\
GetNumeric:currentVal=pct,type=brightness\
SetNumeric:currentVal=pct,cmd=pct,minVal=0,maxVal=255,step=1,type=brightness
attr Stimmungsleuchte rhasspyName Stimmungsleuchte,Stimmungslampe
attr Stimmungsleuchte rhasspyRoom Wohnzimmer
attr Stimmungsleuchte room Rhasspy,Wohnzimmer
attr Stimmungsleuchte setList on off pct rgb
attr Stimmungsleuchte webCmd rgb:pct:on:off
attr Stimmungsleuchte widgetOverride pct:slider,0,1,255 on:noArg off:noArg rgb:colorpicker,RGB


Ich hab's auch mit einem rhasspyColors Mapping versucht.


2021.04.23 09:37:44.072 5: RHASSPY: [Rhasspy] Parse (IO: rhasspyMQTT2): Msg: hermes/intent/de.fhem_SetColorGroup => {"input": "setze alle lampen auf #FF0000", "intent": {"intentName": "de.fhem:SetColorGroup", "confidenceScore": 1.0}, "siteId": "default", "id": "0cb4a7a4-8e14-44f2-9251-6b9517753bf9", "slots": [{"entity": "de.fhem.Group", "value": {"kind": "Unknown", "value": "lampen"}, "slotName": "Group", "rawValue": "lampen", "confidence": 1.0, "range": {"start": 11, "end": 17, "rawStart": 11, "rawEnd": 17}}, {"entity": "Rgb", "value": {"kind": "Unknown", "value": "#FF0000"}, "slotName": "Rgb", "rawValue": "rot", "confidence": 1.0, "range": {"start": 22, "end": 29, "rawStart": 22, "rawEnd": 25}}], "sessionId": "0cb4a7a4-8e14-44f2-9251-6b9517753bf9", "customData": null, "asrTokens": [[{"value": "setze", "confidence": 1.0, "rangeStart": 0, "rangeEnd": 5, "time": null}, {"value": "alle", "confidence": 1.0, "rangeStart": 6, "rangeEnd": 10, "time": null}, {"value": "lampen", "confidence": 1.0, "rangeStart": 11, "rangeEnd": 17, "time": null}, {"value": "auf", "confidence": 1.0, "rangeStart": 18, "rangeEnd": 21, "time": null}, {"value": "#FF0000", "confidence": 1.0, "rangeStart": 22, "rangeEnd": 29, "time": null}]], "asrConfidence": null, "rawInput": "setze alle lampen auf rot", "wakewordId": null, "lang": null}
2021.04.23 09:37:44.072 5: Parsed value: #FF0000 for key: Rgb
2021.04.23 09:37:44.072 5: Parsed value: 1 for key: probability
2021.04.23 09:37:44.073 5: Parsed value: setze alle lampen auf #FF0000 for key: input
2021.04.23 09:37:44.073 5: Parsed value: lampen for key: Group
2021.04.23 09:37:44.073 5: Parsed value: default for key: siteId
2021.04.23 09:37:44.073 5: Parsed value: 0cb4a7a4-8e14-44f2-9251-6b9517753bf9 for key: sessionId
2021.04.23 09:37:44.073 5: Parsed value: setze alle lampen auf rot for key: rawInput
2021.04.23 09:37:44.073 5: Parsed value: SetColorGroup for key: intent
2021.04.23 09:37:44.074 5: handleIntentSetColorGroup called
2021.04.23 09:37:44.074 5: sorted devices list is:
2021.04.23 09:37:44.074 5: Response is: Tut mir leid, ich konnte kein passendes Gerät finden
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 23 April 2021, 09:46:04
Und warum bekam ich gerade: AssertionError: Missing slot $de.fhem.Color?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 23 April 2021, 09:57:47
Mit dem missing slot muss ich mal schauen (geht aber nicht vor heute abend), ich nutze den gar nicht mehr, sondern die Hue-Variante. Das hat m.E. den Vorteil, dass das nur den Farbwert wiederspiegelt und man sich am Ende darauf beschränken könnte, den erforderlichenfalls in RGB umzuwandeln (was aber dann die Ermittlung eines "guten" Helligkeitswerts voraussetzt, wenn das Zielgerät nur rgb kann.

Betr. RGB ist es so, dass RHASSPY das (zumindest im Moment noch) gerne ohne den "#"-Vorsatz hätte. Ggf. kannst du den Filter auch aufbohren, kommt aber darauf an, was das jeweilige Gerät versteht (also ggf: das # löschen).

Ansonsten sehe ich jetzt auf die Schnelle nichts, was gegen die Steuerbarkeit des Testdevices spräche (ggf. mal das RHASSPY-list kontrollieren).
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 23 April 2021, 10:11:18
Bei siteId2room hat's was mit dem Encoding:

setstate Rhasspy 2021-04-23 09:50:05 siteId2room_wohnzimmer b�ro
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 23 April 2021, 10:25:21
Hm, evtl. muss man der decode-Anweisung in der myUtils ausdrücklich UTF-8 (oder was auch immer unter "encoding" angegeben war) unterschieben (und dem encoding in RHASSPY genauso)?

Kannst du das mal ergänzen?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 23 April 2021, 10:26:34
Ich versuch's.

Zitat von: Beta-User am 23 April 2021, 09:57:47
Ansonsten sehe ich jetzt auf die Schnelle nichts, was gegen die Steuerbarkeit des Testdevices spräche (ggf. mal das RHASSPY-list kontrollieren).

Der Schmäh ist: Es braucht den Setter hue damit das Device überhaupt im List auftaucht. Ändert aber nichts daran, dass es bei SetColorGroup nicht gefunden wird.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 23 April 2021, 11:18:24
siteId2room war schuld. Also eigentlich ich ;)



Ich hab zwei Geräte mit einem temperature-Mapping. Eines im Raum "draußen", eines im Raum "Wohnzimmer".

"Wie warm ist es" im Wohnzimmer gesprochen, bringt mir jetzt die Temperatur von draußen. Weil im Wohnzimmer kein Gerät gefunden wurde (matches in room). Warum? Das ging doch mal.



defmod thermWohnzimmer dummy
attr thermWohnzimmer group Temperatur
attr thermWohnzimmer icon temp_inside
attr thermWohnzimmer readingList measured-temp desired-temp
attr thermWohnzimmer rhasspyMapping SetOnOff:cmdOn=desired-temp 22.5,cmdOff=desired-temp 0\
GetOnOff:currentVal=desired-temp,valueOff=0\
GetNumeric:currentVal=measured-temp,type=temperature\
GetNumeric:currentVal=desired-temp,part=0,type=desired-temp\
SetNumeric:currentVal=desired-temp,cmd=desired-temp,part=0,minVal=0,maxVal=23,step=0.5,type=temperature
attr thermWohnzimmer rhasspyName Heizung
attr thermWohnzimmer rhasspyRoom Wohnzimmer
attr thermWohnzimmer room Rhasspy,Wetter
attr thermWohnzimmer setList desired-temp
attr thermWohnzimmer stateFormat measured-temp °C / desired-temp °C




2021.04.23 11:13:32.703 5: RHASSPY: [Rhasspy] Parse (IO: rhasspyMQTT2): Msg: hermes/intent/de.fhem_GetNumeric => {"input": "temperature", "intent": {"intentName": "de.fhem:GetNumeric", "confidenceScore": 1.0}, "siteId": "wohnzimmer", "id": null, "slots": [{"entity": "Type", "value": {"kind": "Unknown", "value": "temperature"}, "slotName": "Type", "rawValue": "wie warm ist es", "confidence": 1.0, "range": {"start": 0, "end": 11, "rawStart": 0, "rawEnd": 15}}], "sessionId": "wohnzimmer-snowboy-3d5890d1-292d-48d5-9cb8-e0331c96ba35", "customData": null, "asrTokens": [[{"value": "temperature", "confidence": 1.0, "rangeStart": 0, "rangeEnd": 11, "time": null}]], "asrConfidence": null, "rawInput": "wie warm ist es", "wakewordId": "snowboy", "lang": null}
2021.04.23 11:13:32.703 5: Parsed value: wohnzimmer-snowboy-3d5890d1-292d-48d5-9cb8-e0331c96ba35 for key: sessionId
2021.04.23 11:13:32.703 5: Parsed value: temperature for key: Type
2021.04.23 11:13:32.704 5: Parsed value: wie warm ist es for key: rawInput
2021.04.23 11:13:32.704 5: Parsed value: 1 for key: probability
2021.04.23 11:13:32.704 5: Parsed value: wohnzimmer for key: siteId
2021.04.23 11:13:32.704 5: Parsed value: GetNumeric for key: intent
2021.04.23 11:13:32.704 5: Parsed value: temperature for key: input
2021.04.23 11:13:32.705 5: handleIntentGetNumeric called
2021.04.23 11:13:32.705 5: matches in room: , matches outside: tempOutside thermWohnzimmer
2021.04.23 11:13:32.705 5: tempOutside
2021.04.23 11:13:32.706 5: Response is: Die Temperatur von draußen beträgt 19,5 Grad



         thermWohnzimmer:
           alias      heizung
           groups     temperatur
           names      heizung
           rooms      wohnzimmer
           intents:
             GetNumeric:
               desired-temp:
                 currentVal desired-temp
                 part       0
                 type       desired-temp
               temperature:
                 currentVal measured-temp
                 type       temperature
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 23 April 2021, 11:26:45
Lustiges feature, schiebt man rgb nach vorne, taucht es auch im Mapping auf...

Habe jetzt die Regex (auch an noch ein paar anderen Stellen) aufgebohrt, damit die das auch akzeptiert, wenn "end of string" erreicht ist.

Ansonsten hatte ich bisher nur "hue" und "Colortemp" als Gruppenbefehle in der Praxis (also mit realen Geräten) ausgetestet, und das war insoweit ok, als alle bei hue die Farbe gewechselt haben, und nur die Truppe, die dann auch ct kann auf den Colortemp reagiert hat.

RGB (via Color und Rgb) hatte ich gestern in der Troppenübung durch, da aber nur single und mit dem gezeigten dummy; Wert der beiden Felder war sechsstelliges HEX (FF0000).
Da die Gruppen-Logik nur eine übergreifende Schleife ist, die eben die Devices überspringt, die den jeweiligen Befehl nicht kennen, "müsste" das eigentlich auch passen. Beim Testen mit Gruppe daher erst starten, wenn der "single"-Payload-JSON paßt.



Zum "outisde room":
Ist das 2room-reading noch gesetzt? Dann ist der Satellit im B?ro ;) .
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 23 April 2021, 11:31:57
Zitat von: Beta-User am 23 April 2021, 11:26:45
Zum "outisde room":
Ist das 2room-reading noch gesetzt? Dann ist der Satellit im B?ro ;) .

Ja, hehe. Hatte das eh oben geschrieben. Aber zu spät. Peinlich ;D
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 23 April 2021, 11:45:52
Ich kann jetzt rhasspyColors und gDT nicht mehr mischen, oder? Ich mein, alle bunten Lichter müssen jetzt entweder ein rhasspyColors oder ein gDT haben. Ein Licht mit rhasspyColors, ein anderes mit gDT geht nicht mehr. Zumindest weiß ich nicht, wie ich die Rhasspy-sentences bauen sollte.
Ich müsste das so machen:


[de.fhem:SetColor]
\[setze|färbe|stelle] $de.fhem.Device{Device} [$de.fhem.Room{Room}] [auf] [die Farbe] $de.fhem.Color{Color}
\[setze|färbe|stelle] $de.fhem.Device{Device} [$de.fhem.Room{Room}] [auf] [die Farbe] (grün{Rgb:008000}|rot{Hue:1})


Da wird aber bei "grün" natürlich immer der erste Satz genommen.

Oder so

[de.fhem:SetColor]
\[setze|färbe|stelle] $de.fhem.Device{Device} [$de.fhem.Room{Room}] [auf] [die Farbe] ($de.fhem.Color{Color}|grün{Rgb:008000}|rot{Hue:1})

Dann wird immer 008000 genommen.

Oder übersehe ich da etwas?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 23 April 2021, 11:57:11
Mischen sollte schon (bedingt) gehen, allerdings macht es m.E. in der "neuen Welt" nicht mehr den großen Sinn, Farben erst auf der FHEM-Seite zu benennen.
Das hier sollte gehen (vorausgesetzt, das mapping auf der FHEM-Seite wird auf HEX umgestellt):
\[setze|färbe|stelle] $de.fhem.Device{Device} [$de.fhem.Room{Room}] [auf] [die Farbe] (grün{Color:008000}|rot{Hue:1})


Insgesamt fand ich den "separaten Kanal" für das Farb-Thema schon immer komisch und _glaube_, dass man das mittelfristig als "deprecated" kennzeichnen sollte, nämlich dann, wenn wir "Hue2hex" können...
(Nachtrag: Das mapping auf der FHEM-Seite via Attribut macht uU. allerdings dann Sinn, wenn man Farbkorrekturen vornehmen will/muss, mal schauen)
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 23 April 2021, 12:03:03
Somit brechen wir aber jetzt schon mit der Rückwertskompatibiliät. Das rhasspyColors ist somit sinnlos. Bzw. dessen Inhalt. Und der Slot de.fhem.Colors.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 23 April 2021, 12:14:23
Nicht unbedingt.

Der slot an sich funktioniert und wird das auch weiterhin. Wer es wie gehabt nutzen will: Gerne, kein Problem.

Ursprünglich hatte ich überlegt, ob man ein "word2rgb"-Mapping machen sollte, dann wäre "Color" mit (englischen) Wortwerten gegangen. So ist das im Moment auch auskommentiert begonnen.

Mit meinen jetzigen Erfahrungen mit dem Thema würde ich sagen, dass man dann mehrfach mappt, was vermutlich Quatsch ist, weil man in jedem Fall ein mapping auf der Rhasspy-Seite braucht, und das dann auch gleich "richtig" machen kann und (nach derzeitigem Verständnis) "Hue" nummerisch übergeben.

Zwischenfazit also:
Wer in die "neue Welt" will sollte das nach der Devise tun: Ganz oder gar nicht.
Zum Testen kann man ja ein Schlüsselwort voranstellen, und dann entweder Hue (zu empfehlen) oder Rgb zusätzlich nutzen. Ähnliches gilt für  Gruppenfunktionen; die gehen dann eben nur "entweder" oder...
Schwierig, das letztlich auf Basis einiger weniger Erfahrungen jetzt schon zu entscheiden, auch von daher bin ich mal auf nachher bzw. den Do. gespannt.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 23 April 2021, 12:21:32
Versteh ich nicht. Wie soll das gehen? Der Slot nützt mir ja nichts mehr sobald ich irgendein Gerät habe, dessen Farben mit gDT gesteuert werden. Weil ich eben keine auf beide passenden sentences mehr zusammen bringe.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 23 April 2021, 12:29:10
Als Beispiel dieses Device


defmod Stimmungsleuchte dummy
attr Stimmungsleuchte readingList pct rgb
attr Stimmungsleuchte rhasspyColors grün=rgb 008000\
blau=rgb 0000FF\
gelb=rgb FFFF00
attr Stimmungsleuchte rhasspyMapping SetOnOff:cmdOn=on,cmdOff=off
...
attr Stimmungsleuchte setList on off pct rgb


Und der sentence:

[de.fhem:SetColor]
\[setze|färbe|stelle] $de.fhem.Device{Device} [$de.fhem.Room{Room}] [auf] [die Farbe] ($de.fhem.Color{Color}|grün{Color:008000})


Das ergibt bei "Stelle die Stimmungslampe auf grün":

2021.04.23 12:28:22.749 5: RHASSPY: [Rhasspy] Parse (IO: rhasspyMQTT2): Msg: hermes/intent/de.fhem_SetColor => {"input": "stelle stimmungslampe auf 008000", "intent": {"intentName": "de.fhem:SetColor", "confidenceScore": 1.0}, "siteId": "wohnzimmer", "id": null, "slots": [{"entity": "de.fhem.Device", "value": {"kind": "Unknown", "value": "stimmungslampe"}, "slotName": "Device", "rawValue": "stimmungslampe", "confidence": 1.0, "range": {"start": 7, "end": 21, "rawStart": 7, "rawEnd": 21}}, {"entity": "Color", "value": {"kind": "Unknown", "value": "008000"}, "slotName": "Color", "rawValue": "grün", "confidence": 1.0, "range": {"start": 26, "end": 32, "rawStart": 26, "rawEnd": 30}}], "sessionId": "wohnzimmer-snowboy-d0a043dc-738d-4fd1-852a-437de2504e3a", "customData": null, "asrTokens": [[{"value": "stelle", "confidence": 1.0, "rangeStart": 0, "rangeEnd": 6, "time": null}, {"value": "stimmungslampe", "confidence": 1.0, "rangeStart": 7, "rangeEnd": 21, "time": null}, {"value": "auf", "confidence": 1.0, "rangeStart": 22, "rangeEnd": 25, "time": null}, {"value": "008000", "confidence": 1.0, "rangeStart": 26, "rangeEnd": 32, "time": null}]], "asrConfidence": null, "rawInput": "stelle stimmungslampe auf grün", "wakewordId": "snowboy", "lang": null}
2021.04.23 12:28:22.750 5: Parsed value: 1 for key: probability
2021.04.23 12:28:22.750 5: Parsed value: SetColor for key: intent
2021.04.23 12:28:22.750 5: Parsed value: stelle stimmungslampe auf 008000 for key: input
2021.04.23 12:28:22.750 5: Parsed value: wohnzimmer for key: siteId
2021.04.23 12:28:22.750 5: Parsed value: stimmungslampe for key: Device
2021.04.23 12:28:22.751 5: Parsed value: stelle stimmungslampe auf grün for key: rawInput
2021.04.23 12:28:22.751 5: Parsed value: 008000 for key: Color
2021.04.23 12:28:22.751 5: Parsed value: wohnzimmer-snowboy-d0a043dc-738d-4fd1-852a-437de2504e3a for key: sessionId
2021.04.23 12:28:22.751 5: handleIntentSetColor called
2021.04.23 12:28:22.752 5: Device selected (by hash, with room and name): Stimmungsleuchte
2021.04.23 12:28:22.752 5: Response is: Tut mir leid, aber ich konnte kein passendes Mäpping finden
2021.04.23 12:28:22.752 5: Response is: Da ist leider etwas schief gegangen
2021.04.23 12:28:25.400 5: RHASSPY: [Rhasspy] Parse (IO: rhasspyMQTT2): Msg: hermes/dialogueManager/sessionEnded => {"termination": {"reason": "nominal"}, "sessionId": "wohnzimmer-snowboy-d0a043dc-738d-4fd1-852a-437de2504e3a", "siteId": "wohnzimmer", "customData": "snowboy"}
2021.04.23 12:28:25.400 5: Parsed value: wohnzimmer-snowboy-d0a043dc-738d-4fd1-852a-437de2504e3a for key: sessionId
2021.04.23 12:28:25.400 5: Parsed value: wohnzimmer for key: siteId


Gleich zwei Fehlermeldungen nämlich
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 23 April 2021, 12:40:47
Na ja, ein sentence, beide Gruppen bedienen wird vermutlich nicht gehen bzw. nur dann, wenn jemand das mapping für "nicht-HEX-Color" fertig stellen würde (das wir übrigens auch als Option in "tweaks" unterbringen könnten, dann kann es der user auf Deutsch einstellen; die jetzige Form ist vermutlich nicht gut, de-Text nach HEX wäre vermutlich besser, und wer dann was anderes braucht, muss dann halt rhasspyColors am Gerät anders einstellen, das hat bei einem match (in Color) immer Vorrang).

Daher ist im Moment dem Einsteiger zu empfehlen, direkt gDT zu nehmen, und es sollte auch möglich sein, SetColor als mapping in rhasspyMapping unterzubringen, falls z.B. jemand RGB als setter hat.

Falls der Eindruck entstanden sein sollte, dass das alles schon irgendwie fertig ausgekocht oder vercodet ist: bewahre... Ich habe bisher nur festgestellt, dass es überraschend easy mit den zwei (farbigen) Typen klappt, die ich habe, und _glaube_, dass die verbliebenen Lücken relativ leicht zu füllen sein müßten, ohne jemandem Funktionalität abzuklemmen, der die neuen features nicht nutzen will (bzw. mit in der Entwickelung supporten).

(Das mit den zwei Rückmeldungen muss ich mir in Ruhe ansehen; werden denn auch beide gesprochen oder nur die letzte?)
EDIT: Bitte mal testen, ob jetzt die eigentlich richtige Antwort kommt. Wenn, waren da ein paar mehr Stellen; die Änderung sollte unschädlich sein...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 23 April 2021, 12:45:05
Es werden beide gesprochen.

Also nicht rückwärtskompatibel ;)

Ich hätte mir gedacht, wir bringen die Farben irgendwie im language-file unter. Aber dazu müssten wir wirklich umrechnen können (HEX <-> HUE). Da hat doch sicher schon mal jemand gemacht, nicht?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 23 April 2021, 13:09:18
Dann hilft die Änderung (siehe Anhang im letzten Post) wohl auch nicht...
Hmm, als RGB-Wert hätte das eigentlich gehen sollen...

Das mit der language-file wäre eine Möglichkeit, aber: Im Prinzip ist es sehr willkürlich, welche Keys es geben kann, und es ist dort etwas "unprominent" platziert. Einen Tweak mit rhasspyColors-Key und dann danach allen word2command-Paaren wäre m.E. besser (?): (grün="rgb 00FF00"). Dann könnte man diese Keys auch einfach noch in den slot packen, und die Commands gehen an die Devices, die den ersten Teil (hier: rgb) kennen...

Mit Umrechnungen beschäftigt sich Color.pm. Da gibt es aus einem guten Grund kein Hue2HEX (bzw. rgb): HUE hat afaik keinen Helligkeitsinhalt, RGB sehr wohl (deswegen gefällt mir auch Color mit HEX-Inhalt nicht so). Aber vermutlich hat sich schon jemand mit der Frage beschäftigt und es gibt fertige Formeln...
Bin mir übrigens auch nicht sicher, ob ein lineares Verständnis immer paßt. (Für meine RGBW-MiLights wohl schon, die "denken" anscheinend in einem Farbkreis).

(Generell: Da via gDT auch der Device-slot eingeehngt werden kann, ist diese ganze Kompabilitäts-Geschichte (bzw. der Aufwand, das ggf. anders als "entweder oder" zuzulassen) eh' eine Frage, die man aufwerfen sollte.)
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 23 April 2021, 14:02:37
Noch etwas schnell aufgefundene Theorie:

Evtl. sollte man HUE als 360° notieren?
Nö, man macht das jetzt so...

Na jedenfalls habe ich mal auf die Schnelle versucht, die Tabelle aus https://en.wikipedia.org/wiki/Hue#24_hues_of_HSL/HSV (https://en.wikipedia.org/wiki/Hue#24_hues_of_HSL/HSV) zu integrieren, und jetzt kommt auch "irgendwas" raus, wenn man Hue-Befehle auf "pure rgb"-Devices (wie die Stimmungsleuchte) losläßt...

Edit:
Und rhasspyColors habe ich dann auch gleich aus der Liste der globalen Attribute rausgenommen, cref ist entsprechend ergänzt, dass man das bei Bedarf von Hand machen soll.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 23 April 2021, 14:20:26
Zitat von: Beta-User am 23 April 2021, 14:02:37
Nö, man macht das jetzt so...

Na jedenfalls habe ich mal auf die Schnelle versucht, die Tabelle aus https://en.wikipedia.org/wiki/Hue#24_hues_of_HSL/HSV (https://en.wikipedia.org/wiki/Hue#24_hues_of_HSL/HSV) zu integrieren, und jetzt kommt auch "irgendwas" raus, wenn man Hue-Befehle auf "pure rgb"-Devices (wie die Stimmungsleuchte) losläßt...

Und wie soll jetzt ein Device und ein sentence aussehen?

Zitat
Edit:
Und rhasspyColors habe ich dann auch gleich aus der Liste der globalen Attribute rausgenommen, cref ist entsprechend ergänzt, dass man das bei Bedarf von Hand machen soll.

Gefällt mir gar nicht die Idee! Momentan.

War nicht der Plan, dass ich wieder anfange zu testen. Ich wollte mich eigentlich auf die Doku konzentrieren. Und jetzt finde ich knapp vor der Präsentation eine Unstimmigkeit nach der anderen. Deswegen wollte ich einen Feature-Freeze. Und die gDTs am Donnerstag nur am Rande als "in Arbeit" erwähnen. Geht jetzt natürlich nicht mehr.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 23 April 2021, 14:39:02
Hab heute wiedermal meinen physischen Satelliten in Betrieb genommen. siteId ist "Küche".
Der ist schon mal gelaufen, ich habe mit ihm getestet. Heute wird mir ein Reading "listening_k__che" erstellt, statt "listening_küche". Da hat sich aber nichts geändert, oder?

Weiters habe ich ein Device "thermKueche" mit gDT thermostat im Raum "Küche". Frage ich jetzt meinen Satelliten "wie warm ist es", antwortet der: Die Temperatur von Rhasspy beträgt 5°. Warum "Rhasspy"?


         thermKueche:
           alias      heizung
           groups     temperatur
           names      heizung
           rooms      rhasspy,wetter,küche
           intents:
             GetNumeric:
               desired-temp:
                 currentVal desired-temp
                 type       desired-temp
               temperature:
                 currentVal temperature
                 type       temperature
             SetNumeric:
               desired-temp:
                 cmd        desired-temp
                 currentVal desired-temp
                 maxVal     28
                 minVal     10
                 step       0.5
                 type       temperature



2021.04.23 14:36:30.542 5: RHASSPY: [Rhasspy] Parse (IO: rhasspyMQTT2): Msg: hermes/intent/de.fhem_GetNumeric => {"input": "temperature", "intent": {"intentName": "de.fhem:GetNumeric", "confidenceScore": 1.0}, "siteId": "küche", "id": null, "slots": [{"entity": "Type", "value": {"kind": "Unknown", "value": "temperature"}, "slotName": "Type", "rawValue": "wie warm ist es", "confidence": 1.0, "range": {"start": 0, "end": 11, "rawStart": 0, "rawEnd": 15}}], "sessionId": "küche-porcupine_raspberry-pi-8b193597-5ba7-43ef-b51e-158cab426e76", "customData": null, "asrTokens": [[{"value": "temperature", "confidence": 1.0, "rangeStart": 0, "rangeEnd": 11, "time": null}]], "asrConfidence": null, "rawInput": "wie warm ist es", "wakewordId": "porcupine_raspberry-pi", "lang": null}
2021.04.23 14:36:30.542 5: Parsed value: temperature for key: input
2021.04.23 14:36:30.543 5: Parsed value: wie warm ist es for key: rawInput
2021.04.23 14:36:30.543 5: Parsed value: 1 for key: probability
2021.04.23 14:36:30.543 5: Parsed value: GetNumeric for key: intent
2021.04.23 14:36:30.543 5: Parsed value: küche for key: siteId
2021.04.23 14:36:30.543 5: Parsed value: küche-porcupine_raspberry-pi-8b193597-5ba7-43ef-b51e-158cab426e76 for key: sessionId
2021.04.23 14:36:30.544 5: Parsed value: temperature for key: Type
2021.04.23 14:36:30.544 5: handleIntentGetNumeric called
2021.04.23 14:36:30.545 5: matches in room: thermKueche, matches outside: tempOutside thermWohnzimmer
2021.04.23 14:36:30.545 5: thermKueche
2021.04.23 14:36:30.545 5: Response is: Die Temperatur von rhasspy beträgt 5 Grad
2021.04.23 14:36:34.115 5: RHASSPY: [Rhasspy] Parse (IO: rhasspyMQTT2): Msg: hermes/dialogueManager/sessionEnded => {"termination": {"reason": "nominal"}, "sessionId": "küche-porcupine_raspberry-pi-8b193597-5ba7-43ef-b51e-158cab426e76", "siteId": "küche", "customData": "porcupine_raspberry-pi"}
2021.04.23 14:36:34.115 5: Parsed value: küche for key: siteId
2021.04.23 14:36:34.115 5: Parsed value: küche-porcupine_raspberry-pi-8b193597-5ba7-43ef-b51e-158cab426e76 for key: sessionId
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 23 April 2021, 15:21:04
Zwei Unterstriche deuten darauf hin, dass es irgendein Konvertierungsproblem ist. Gefühlt wurde an dem Teil des Codes nichts geändert.

Rhasspy ist der defaultRoom, da hat also was mit der Zuordung nicht gepaßt. Dachte erst, das hinge mit einer fehlenden lc-Anweisung zusammen, aber die stand am erwarteten Ort. eventuell war aber auch der Versuch des splits in RHASSPY_roomName() keine gute Idee (für die Satelitten-Gruppenfunktion), habe das jetzt geändert in substitution.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 23 April 2021, 16:01:18
Zitat von: Beta-User am 23 April 2021, 15:21:04
Zwei Unterstriche deuten darauf hin, dass es irgendein Konvertierungsproblem ist. Gefühlt wurde an dem Teil des Codes nichts geändert.

Ich glaub eh auch, dass das an mir liegt. Aber ich verstehe nicht, wo das Problem sein könnte.

Wenn ich mir in onmessage $siteId und $room vor und nach der Umwandlung der Umlaute ausgeben lasse, sieht das so aus:


2021.04.23 15:54:04.915 5: Parsed value: büro for key: siteId
$VAR1 = "b\x{c3}\x{bc}ro";
$VAR1 = "b\x{e3}\x{bc}ro";
$VAR1 = "b\x{e3}\x{bc}ro";


Und $hash liefert auch so komische Umlaute:

'timerCancellation' => "\$label im \$room gel\x{c3}\x{b6}scht"


Bei einem list Rhasspy passt das aber. Und fetchSiteIds schreibt mir die siteIds auch mit Umlauten hin.

Das ist alles nicht ganz logisch. Kannst du das irgendwann bei dir mal testen bitte?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 23 April 2021, 16:07:36
Zitat von: Beta-User am 23 April 2021, 15:21:04
Rhasspy ist der defaultRoom, da hat also was mit der Zuordung nicht gepaßt. Dachte erst, das hinge mit einer fehlenden lc-Anweisung zusammen, aber die stand am erwarteten Ort. eventuell war aber auch der Versuch des splits in RHASSPY_roomName() keine gute Idee (für die Satelitten-Gruppenfunktion), habe das jetzt geändert in substitution.

Ich denke, das hängt auch mit meinem Umlaut-Problem zusammen. Hat ja mal funktioniert. Und deine Änderung ändert nichts am Fehlverhalten.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 23 April 2021, 16:14:31
Zum Konvertierungs-Thema kann ich im Moment nichts beitragen, es erinnert mich allerdings an die von JensS geschilderten Probleme. Mal sehen...

Zu dem Farb-Ding:
Es wäre vermutlich sinnvoll, eine "Variable" in den sentences zu definieren, die dann ausgewählte "Sprechfarben" in Hue-Werte übersetzt. Ansonsten kann man den bisherigen Satz auch entsprechend ändern:
\[setze|färbe|stelle] $de.fhem.Device-light{Device} [$de.fhem.Room{Room}] [auf] [die Farbe] (grün{Hue:120}|rot{Hue:0}|blau{Hue:240}|(warm weiss){Colortemp:100}|(kalt weiss){Colortemp:0}|(mittleres weiss){Colortemp:50})
Damit sollte sich jedes Device farblich direkt steuern lassen, das hue oder rgb als Kommando kennt und gDT "light" ist (das sollte eigentlich die ganz überwiegende Mehrzahl sein). Ob die Eingrenzung auf diesen Device-Teilslot es ermöglicht, daneben noch die anderen Devices über denselben sentence (aber Color-Content) abzufackeln, wäre die Frage.

Ein "Loch" war noch bei Colortemp2HEX (bzw. allgemein weiß oder grau). Dazu habe ich in Color.pm was gefunden, bin aber am Import gescheitert und hab's daher einfach als eine Art Klon eigebaut. Da ist mir aber auch erst mal unklar, wie der Wertebereich denn sinnvollerweise sein soll, eine 100-Skala wohl definitiv nicht. Hab jetzt mal die 0-100 auf den Bereich von 2000 bis 7000 gemappt (Anlehnung an FHEM-Wiki zu Color), mal schauen, ob das praxistauglich ist.

Das mit den globalen Attributen ist lediglich auskommentiert, also keine große Sache. Ich würde es trotz mancher (mAn. kleinerer!) Wackeligkeiten deaktiviert lassen, das war es übrigens bis 0.2.0 btw. auch.

Und wenn du Einsteiger interessieren willst, solltest du das gDT-Thema nicht außen vor lassen. Es ist mAn. soweit fertig, dass man sich eher in Ausnahmefällen noch mit eigenen Mappings beschäftigen wird...
(Bzgl. Testen: Das betrifft nur den Color-Teil; für den Rest ist es gleichgültig, wo das mapping herkommt).
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 23 April 2021, 16:32:29
Zitat von: Beta-User am 23 April 2021, 16:14:31Zum Konvertierungs-Thema kann ich im Moment nichts beitragen, es erinnert mich allerdings an die von JensS geschilderten Probleme. Mal sehen...

Ja. Nur bei mir ändert auch das Setzen des "encoding" auf cp-irgendwas nichts. Wird nur noch schlimmer.

ZitatEs wäre vermutlich sinnvoll, eine "Variable" in den sentences zu definieren, die dann ausgewählte "Sprechfarben" in Hue-Werte übersetzt.

Ich hätte mir gedacht, wir schreiben für den Anfang in das language-file die z.B. HUE-Farben mit "hue angle".
Keinen genauen Plan, wie. Aber so z.B.:

'colors' => {
  'red' => 0,
  'green' => 120,
...
}

Und im Code rechnen wir dann halt um. Je nach Setter.
Ist das realistisch?

ZitatOb die Eingrenzung auf diesen Device-Teilslot es ermöglicht, daneben noch die anderen Devices über denselben sentence (aber Color-Content) abzufackeln, wäre die Frage.
Eben nicht. Device-light ist ja nur eine Untermenge von Device.

ZitatDas mit den globalen Attributen ist lediglich auskommentiert, also keine große Sache. Ich würde es trotz mancher (mAn. kleinerer!) Wackeligkeiten deaktiviert lassen, das war es übrigens bis 0.2.0 btw. auch.
Ja, war so. Und ich fand's lästig ;).

ZitatUnd wenn du Einsteiger interessieren willst, solltest du das gDT-Thema nicht außen vor lassen. Es ist mAn. soweit fertig, dass man sich eher in Ausnahmefällen noch mit eigenen Mappings beschäftigen wird...
Keine Sorge. Ich werde gDT auf jeden Fall prominent erwähnen. Ich find's immer noch cool. Mich stört nur das Entweder-Oder bei den Lichtfarben. Aber andererseits, die drei bisherigen User werden's überleben wenn wir den Zopf abschneiden. Jens wird schimpfen, aber damit müssen wir leben ;D
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 23 April 2021, 16:36:08
Zitat von: drhirn am 23 April 2021, 16:32:29
Ich hätte mir gedacht, wir schreiben für den Anfang in das language-file die z.B. HUE-Farben mit "hue angle".
Keinen genauen Plan, wie. Aber so z.B.:

'colors' => {
  'red' => 0,
  'green' => 120,
...
}

Und im Code rechnen wir dann halt um. Je nach Setter.

Achso, ich vergaß. Und aus den Farben im Language-File machen wir einen Slot "colors". Der kann dann in die Sentences eingebaut werden.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 23 April 2021, 16:52:44
Zitat von: drhirn am 23 April 2021, 16:32:29
Ja. Nur bei mir ändert auch das Setzen des "encoding" auf cp-irgendwas nichts. Wird nur noch schlimmer.
Schade, aber wenig überraschend. Evtl. auch nur ein Darstellungsproblem, oder wir müssen irgendwie die Verwendung von UTF8 erzwingen (da gibt es ein "use", wenn ich das richtig im Kopf habe).


Ich hätte mir gedacht, wir schreiben für den Anfang in das language-file die z.B. HUE-Farben mit "hue angle".
Keinen genauen Plan, wie. Aber so z.B.:

'colors' => {
  'red' => 0,
  'green' => 120,
...
}

Und im Code rechnen wir dann halt um. Je nach Setter.
Ist das realistisch?

Realistisch ja, aber "gefühlt" im Kreis rum. Eher anders herum für "backwards"-Kompabilität, also "mach aus einer Ziffer ein (deutsches) Wort - und vergleiche das dann mit dem, was in rhasspyColors drin steht.
Dann ist es m.E. einfacher und deutlich weniger fehleranfällig, der User mappt das in seinem Attribut. (wobei er dann HEX-Werte nach Color packen müßte; auch nicht lustig).

Zitat von: drhirn am 23 April 2021, 16:36:08
Achso, ich vergaß. Und aus den Farben im Language-File machen wir einen Slot "colors". Der kann dann in die Sentences eingebaut werden.
Hmm, (irgendwie) denkbar. Sehe aber im Moment nicht den großen Vorteil zu einer für die sentences.ini vorbereiteten Variable. Das ist ja (im Prinzip) in jeder deutschen Konfiguration gleich.

Andere Option noch für "backwards compability" (aber auch ohne slots): Kann man ein "Doppel-tag" vergeben? also:

\[setze|färbe|stelle] $de.fhem.Device-light{Device} [$de.fhem.Room{Room}] [auf] [die Farbe] (grün{Hue:120}{Color}|rot{Hue:0}{Color}|blau{Hue:240}{Color}|(warm weiss){Colortemp:100}|(kalt weiss){Colortemp:0}|(mittleres weiss){Colortemp:50})
Zitat
Eben nicht. Device-light ist ja nur eine Untermenge von Device.
OK, klar, Überschneidungen sind immer schwierig...

Zitat
Ja, war so. Und ich fand's lästig ;) .
Meine Idee war jetzt, das wieder lästig zu machen, damit es nur noch die nutzen, die das haben oder unbedingt wollen ;) ...

Zitat
Keine Sorge. Ich werde gDT auf jeden Fall prominent erwähnen. Ich find's immer noch cool. Mich stört nur das Entweder-Oder bei den Lichtfarben. Aber andererseits, die drei bisherigen User werden's überleben wenn wir den Zopf abschneiden. Jens wird schimpfen, aber damit müssen wir leben ;D
Ebend. Und es funktioniert ja auf die alte Weise immer noch. Ist nur eben "entweder-oder" (es sei denn, das mit den Doppeltags geht!).
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 23 April 2021, 17:06:00
Zitat von: Beta-User am 23 April 2021, 16:52:44Schade, aber wenig überraschend. Evtl. auch nur ein Darstellungsproblem, oder wir müssen irgendwie die Verwendung von UTF8 erzwingen (da gibt es ein "use", wenn ich das richtig im Kopf habe).

Keine Ahnung. Ich weiß nur, dass ich keine Ahnung habe, was ich geändert haben könnte. Bin der Meinung nichts. Und ich gerade keine siteIds mit Umlauten verwenden kann. Ich hab schon mal meine ganze Test-Umgebung neu gemacht. Das hat nichts geändert.

ZitatRealistisch ja, aber "gefühlt" im Kreis rum. Eher anders herum für "backwards"-Kompabilität, also "mach aus einer Ziffer ein (deutsches) Wort - und vergleiche das dann mit dem, was in rhasspyColors drin steht.
Ich dachte, wir haben uns darauf geeinigt, den Zopf abzuschneiden :D


ZitatSehe aber im Moment nicht den großen Vorteil zu einer für die sentences.ini vorbereiteten Variable. Das ist ja (im Prinzip) in jeder deutschen Konfiguration gleich.
Ist richtig, ist immer gleich. Aber der User kann's ändern, wenn er das möchte. Oder neue Farben hinzufügen.

ZitatAndere Option noch für "backwards compability" (aber auch ohne slots): Kann man ein "Doppel-tag" vergeben?
Leider nein. Wird dann nur der jeweils letzte genommen.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 23 April 2021, 17:12:26
Jetzt bin ich verwirrt! Mein Farblicht wird immer auf HUE 0 geschalten, RGB bleibt gleich.


defmod Farblicht dummy
attr Farblicht genericDeviceType light
attr Farblicht group Lampen
attr Farblicht icon light_fairy_lights
attr Farblicht readingList rgb hue
attr Farblicht room Rhasspy,Wohnzimmer
attr Farblicht setList on off rgb hue



2021.04.23 17:11:07.002 5: RHASSPY: [Rhasspy] Parse (IO: rhasspyMQTT2): Msg: hermes/intent/de.fhem_SetColor => {"input": "setze farblicht auf 240", "intent": {"intentName": "de.fhem:SetColor", "confidenceScore": 1.0}, "siteId": "default", "id": "5a4eeff9-d231-4b9b-ab38-beb56eb938d9", "slots": [{"entity": "de.fhem.Device-light", "value": {"kind": "Unknown", "value": "farblicht"}, "slotName": "Device", "rawValue": "farblicht", "confidence": 1.0, "range": {"start": 6, "end": 15, "rawStart": 6, "rawEnd": 15}}, {"entity": "Hue", "value": {"kind": "Unknown", "value": "240"}, "slotName": "Hue", "rawValue": "blau", "confidence": 1.0, "range": {"start": 20, "end": 23, "rawStart": 20, "rawEnd": 24}}], "sessionId": "5a4eeff9-d231-4b9b-ab38-beb56eb938d9", "customData": null, "asrTokens": [[{"value": "setze", "confidence": 1.0, "rangeStart": 0, "rangeEnd": 5, "time": null}, {"value": "farblicht", "confidence": 1.0, "rangeStart": 6, "rangeEnd": 15, "time": null}, {"value": "auf", "confidence": 1.0, "rangeStart": 16, "rangeEnd": 19, "time": null}, {"value": "240", "confidence": 1.0, "rangeStart": 20, "rangeEnd": 23, "time": null}]], "asrConfidence": null, "rawInput": "setze farblicht auf blau", "wakewordId": null, "lang": null}
2021.04.23 17:11:07.002 5: Parsed value: 240 for key: Hue
2021.04.23 17:11:07.003 5: Parsed value: setze farblicht auf blau for key: rawInput
2021.04.23 17:11:07.003 5: Parsed value: farblicht for key: Device
2021.04.23 17:11:07.003 5: Parsed value: 1 for key: probability
2021.04.23 17:11:07.003 5: Parsed value: setze farblicht auf 240 for key: input
2021.04.23 17:11:07.003 5: Parsed value: 5a4eeff9-d231-4b9b-ab38-beb56eb938d9 for key: sessionId
2021.04.23 17:11:07.004 5: Parsed value: default for key: siteId
2021.04.23 17:11:07.004 5: Parsed value: SetColor for key: intent
2021.04.23 17:11:07.004 5: handleIntentSetColor called
2021.04.23 17:11:07.004 5: Device selected (by hash, with room and name): Farblicht
2021.04.23 17:11:07.005 5: Response is: OK
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 23 April 2021, 17:18:43
Zitat von: drhirn am 23 April 2021, 17:06:00
Keine Ahnung. Ich weiß nur, dass ich keine Ahnung habe, was ich geändert haben könnte. Bin der Meinung nichts. Und ich gerade keine siteIds mit Umlauten verwenden kann. Ich hab schon mal meine ganze Test-Umgebung neu gemacht. Das hat nichts geändert.
Schreib mal bei den "use"-Anweisungen vorne noch "use utf8;" dazu. Schadet vermutlich nicht.

Zitat
Ich dachte, wir haben uns darauf geeinigt, den Zopf abzuschneiden :D
Ebend.
Wie vorhin mal geschrieben: der einzige Grund, künftig das Colors-Attribut zu nutzen könnte höchstens darin bestehen, dass eine individuelle Korrektur der Farbe her muss, weil z.B. eines von zwei Leuchtmitteln in einer Gruppe "rot" anders interpretiert. Das wäre dann aber eh' ein Problem, wenn man "nur" Hue sendet, weil bisher das Mapping via Attribut "Color" voraussetzt.
(Dürfte aber nicht schwierig sein, da bei Bedarf was zu basteln.)

Zitat
Ist richtig, ist immer gleich. Aber der User kann's ändern, wenn er das möchte. Oder neue Farben hinzufügen.
Na ja, im Prinzip kann er 360 Farben haben; für den Anfang würde ich dazu neigen, die 24 Segmente aus der en-Wikipedia zu übernehmen und dafür (de-) Namen zu zeigen?

Zitat
Leider nein. Wird dann nur der jeweils letzte genommen.
(schade, dann also s.o.)

Zitat von: drhirn am 23 April 2021, 17:12:26
Jetzt bin ich verwirrt! Mein Farblicht wird immer auf HUE 0 geschalten, RGB bleibt gleich.


attr Farblicht setList on off rgb hue

hue braucht ZWINGEND einen Wertebereich (aus getAllSets(), kann also vermutlich auch aus widgetOverride kommen). Wenn es das Kommando in der Wirklichkeit gibt, dann ist der vorhanden. Sonst ist es 0 bis 0...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 24 April 2021, 08:25:42
Habe im Nachgang zu gestern dann noch die Funktionen umbenannt, hoffe, das passt so.

Hier dann noch der Versuch, den "Hue-Farbkreis" zu übersetzen:

[de.fhem:SetColor]
colors=( rot{Hue:0} | orangerot{Hue:15} | orange{Hue:30} | goldgelb{Hue:45} | ([(zitrus|zitronen)] gelb){Hue:60} | (gelb grün){Hue:75} | (grün gelb){Hue:90} | ((grass|hell) grün){Hue:105} | grün{Hue:120} | (dunkel grün){Hue:135} | (smaragd grün | wasser blau){Hue:150} | (türkis [grün] | grün blau ){Hue:165} | (türkis [blau] | blau grün ){Hue:180} | (azur [blau]){Hue:210}  | ([blau] violet){Hue:225} | ([marine] blau){Hue:240} | ([blau] violet){Hue:255} | (rosa){Hue:270} | (purpur [blau]){Hue:285} | (magenta [blau]){Hue:300} | (alt rosa){Hue:315} | (rubin rot){Hue:330} | (karmin rot){Hue:345} )
\[setze|färbe] $de.fhem.Device-light{Device} [$de.fhem.Room{Room}] [auf die Farbe] (<colors> | (warm weiss){Colortemp:100} | (kalt weiss){Colortemp:0} | (mittleres weiss){Colortemp:50} )

[de.fhem:SetColorGroup]
\[setze|färbe] (alle | sämtliche ) $de.fhem.Group{Group} [im] [( überall:global | $de.fhem.Room){Room}]  [auf die Farbe] (<de.fhem:SetColor.colors> | (warm weiss){Colortemp:100} | (kalt weiss){Colortemp:0} | (mittleres weiss){Colortemp:50} )


Leider ist es mir bisher auch nicht gelungen, "doppelte keys" für eine Farbe zu erzeugen, wenn es wirklich (noch) wichtig ist, könnten wir auch mal im Rhasspy-Forum nachfragen, ob bzw. wie das ggf. geht.
Eigentlich wollte ich jetzt schreiben, dass das für meine Bedürfnisse jetzt ist ziemlich cool ist... ABER: es hängt sehr bei den HUEDevices stark (zu stark?) davon ab, wo man startet, vermutlich, was die Sättigung angeht. (Doch lieber Rgb-Werte übergeben) Hmmm, unschön...

Aber jetzt ist erst mal anderes dran.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 24 April 2021, 09:13:50
Zitat von: Beta-User am 24 April 2021, 08:25:42Doch lieber Rgb-Werte übergeben

Ich hab kaum Erfahrung mit Farben was Lampen betrifft. Ich weiß nur, dass ich immer RGB schalte. Weil ich's logischer finde. Und einfacher.
Und wenn's auch einfacher in der Umsetzung wäre, wäre ich fast dafür, dass wir das so machen. Bis ein Feature-Request kommt.
Und verzichten eben wirklich auch rhasspyColors

Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 24 April 2021, 11:24:11
Zitat von: drhirn am 24 April 2021, 09:13:50
Ich hab kaum Erfahrung mit Farben was Lampen betrifft. Ich weiß nur, dass ich immer RGB schalte. Weil ich's logischer finde. Und einfacher.
Vorab: Die sentences für den "Rgb"-Key umzuschreiben wäre vermutlich kein Problem.

Bin aber tendenziell dagegen, weil RGB eben immer auch einen Helligkeitswert forciert. Meine aktuelle Idee dazu wäre, zu diesem Zweck etwas in "specials" einzubauen, so dass man bei Leuchten, die eigentlich einen "hue"-Setter haben dann RGB erzwingt. Sollte relativ einfach im Code einzubauen sein.

Damit hätte man wieder ein Bausteinchen mehr in Richtung: default-Verhalten an einem Gerät gefällt dir nicht => setze einen tweak bzw. ein special. ("colors=forceHue2RGB=1")

Ein weiteres wäre dann, auch für die Konvertierung von Colortemp fixe RGB-Werte zu erzwingen (das klappt nämlich bei meinen RGBW-MiLights nicht, und das hängt nicht nur an den Bugs, die ich in _ct2rgb reingemogelt hatte (das schaue ich mir nochmal in Ruhe an)). Weiß aber noch nicht, was da dann der beste Weg wäre.

Zitat
Und verzichten eben wirklich auch rhasspyColors
...wenn wir grade beim Verzichten sind: Ich würde auch rhasspyChannels mittelfristig eher anderswo verorten und daher von vornherein das Attribut nicht "global" hinterlegen.

Hintergrund:
- Eigentlich ist das auch eine "Sonderregelung" für lediglich einzelne Devices, und mit globalen Attributen sollte man m.E. sparsam sein.
- Man könnte es vermutlich mehr oder weniger 1:1 in "specials" einbauen, indem man einfach ein "channel=" davorsetzt und dann diese Zeilen einer Sonderbehandlung zuführt. Sollte auch ohne größere Klimmzüge umzusetzen sein.

Meinungen dazu?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 24 April 2021, 11:32:32
Was Lampenfarben betrifft bin ich vorbehaltlos. Ich will sagen "schalte die lampe auf rot" und FHEM soll das tun. Wie, ist mir egal ;D

Zitat von: Beta-User am 24 April 2021, 11:24:11
...wenn wir grade beim Verzichten sind: Ich würde auch rhasspyChannels mittelfristig eher anderswo verorten und daher von vornherein das Attribut nicht "global" hinterlegen.

Hintergrund:
- Eigentlich ist das auch eine "Sonderregelung" für lediglich einzelne Devices, und mit globalen Attributen sollte man m.E. sparsam sein.
- Man könnte es vermutlich mehr oder weniger 1:1 in "specials" einbauen, indem man einfach ein "channel=" davorsetzt und dann diese Zeilen einer Sonderbehandlung zuführt. Sollte auch ohne größere Klimmzüge umzusetzen sein.

Meinungen dazu?

Keine gute ;).
rhasspyChannels ist für mich extrem wichtig. Darüber läuft bei mir sehr viel. TV-Kanäle, TV-Apps, Lichtszenen, etc. Dementsprechend umfangreich ist das Attribut auch teilweise befüllt. Und somit sollte es leicht zu konfigurieren sein. Ob jetzt extra ein userattr anlegen einfacher ist, als "specials" zu befüllen ist natürlich fraglich.
Wir können's wieder optional machen. War ja nicht meine Idee, dass automatisch global zu setzen ;D
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 24 April 2021, 11:47:31
Ging nicht darum, die Funktionalität von "channels" entfallen zu lassen oder zwanghaft eine andere Syntax zu verordnen. Wer es hat: alles gut...

Werde bei Gelegenheit mal versuchen, das entsprechend aufzugleisen, dass es _auch_ über "specials" abgebildet ist.
Aber vor dem Gang ins svn sollte man m.E. auch das Attribut (wieder) deaktivieren, hoffe, zur Deaktivierung noch spätestens morgen ein update liefern zu können.

"scene" ist sowieso noch ein spezielles Thema. Vermutlich dann auch in "specials" zu verorten, aber darum kümmere ich mich erst, wenn "colors" läuft... Grob skizziert: 'scene=<techname>="schalte den Fernesmodus ein"' könnte dann den Satz an Rhasspy übermitteln und daraus einen Eintrag im  "SetScene"-Intent generieren, mit '(schalte den Fernesmodus ein){Scene:techname} {Device:<alias>)'
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 24 April 2021, 12:07:56
Zitat von: Beta-User am 24 April 2021, 11:47:31Ging nicht darum, die Funktionalität von "channels" entfallen zu lassen oder zwanghaft eine andere Syntax zu verordnen. Wer es hat: alles gut...
Hab ich auch nicht so verstanden.

Zitat
Werde bei Gelegenheit mal versuchen, das entsprechend aufzugleisen, dass es _auch_ über "specials" abgebildet ist.
Aber vor dem Gang ins svn sollte man m.E. auch das Attribut (wieder) deaktivieren, hoffe, zur Deaktivierung noch spätestens morgen ein update liefern zu können.

"scene" ist sowieso noch ein spezielles Thema. Vermutlich dann auch in "specials" zu verorten, aber darum kümmere ich mich erst, wenn "colors" läuft... Grob skizziert: 'scene=<techname>="schalte den Fernesmodus ein"' könnte dann den Satz an Rhasspy übermitteln und daraus einen Eintrag im  "SetScene"-Intent generieren, mit '(schalte den Fernesmodus ein){Scene:techname} {Device:<alias>)'
Was ich noch nicht verstanden habe ist, warum wir nicht einfach das Attribut als userattr belassen
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 24 April 2021, 12:36:29
Gute Frage...

Evtl. irgenr wann mal c, ct und r-Optionen...?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 24 April 2021, 15:03:33
Könnte ich doch auf mit dem eigenen Attribut machen. Oder nicht?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 24 April 2021, 15:47:57
Ich hab mir mein Codierungsproblem jetzt den ganzen Tag angesehen. Und irgendwann mal eine ganz alte Version (0.4.3) hergenommen. Damit passt alles. Ich weiß nur nicht, warum.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 24 April 2021, 16:45:56
Zitat von: drhirn am 24 April 2021, 15:47:57
Ich hab mir mein Codierungsproblem jetzt den ganzen Tag angesehen. Und irgendwann mal eine ganz alte Version (0.4.3) hergenommen. Damit passt alles. Ich weiß nur nicht, warum.
Werde mir mal ein diff zwischen den beiden Versionen ansehen, mal schauen.

Habe grade mal versucht, dem ESP32 die siteId "Küche" zuzuweisen, aber da bekommt er scheinbar keinen Kontakt zur base; mit "wohnzimmer" und "buero" geht es hingegen. Ist daher etwas schwierig zum schnellen Testen, muss wohl doch bei Gelegenheit mal den Pi ins WLAN lassen...

Zitat von: drhirn am 24 April 2021, 15:03:33
Könnte ich doch auf mit dem eigenen Attribut machen. Oder nicht?
Ja, nein, vielleicht; bin wie gesagt unsicher...

Meine Sorge: Zu viele mögliche Attribute sind m.E. wirklich übersichtlicher, und gerade Einsteiger tun sich mit dem Konzept "userattr" gerne schwer. Daher tendiere ich eher zu der Überzeugung, dass man - neben den "Haupt-RHASSPY-Attributen" eigentlich nur noch eines braucht. Das kann dann zwar viele unterschiedliche Inhalte haben, aber typischerweise für eine "Geräte-Art" eben immer nur eine kleine Auswahl.
Im Moment bin ich aber an der Hinsicht in etwa noch genaus "blind" wie ich es vor kurzem noch zu "Color" war. Bei "Color" handelt es sich mAn. eigentlich nur um eine Unterart von Set..., von daher ist das da "eindeutiger" in dem generischen rasspyMapping anzusiedeln.

Kann aber auch verstehen, dass da ggf. Sorgen bestehen, dass die Syntax "schwierig" ist. Andererseits: Wenn es mehr oder weniger dasselbe ist wie z.B. in "shortcut", wird es (hoffentlich) schnell ein paar Leute geben, die Beispiele parat haben und/oder Einsteigern helfen können. Wir werden sehen, ist vorläufig nicht so wichtig, da eine Entscheidung in die eine oder andere Richtung zu treffen (wichtiger wäre z.B. das Kodierungsproblem).



Vielleicht im Nachgang zu der Funktionsnamensthematik noch: Es gibt einen Punkt, der uns uU. dabei rausgegangen ist: Wenn die Funktion via InternalTimer verwaltet wird (oder werden kann), dann sollte sie in "fhemdebug timerList" möglichst zuordenbar sein. Kann also sein, dass man das an einigen wenigen Stellen nochmal checken sollte... 
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 24 April 2021, 16:55:43
Zitat von: Beta-User am 24 April 2021, 16:45:56
Werde mir mal ein diff zwischen den beiden Versionen ansehen, mal schauen.
Das Problem liegt hier:
$decoded  = decode_json(encode($cp,$json))
Also konkret im decode_json. Danach kommt nur Müll raus. Aber ich versteh zum einen nicht, warum plötzlich. Und zum anderen nicht, wie ich's lösen könnte.

Zitatgerade Einsteiger tun sich mit dem Konzept "userattr" gerne schwer.

Stimmt. Kenn ich aus eigener Erfahrung.

Zitat
Vielleicht im Nachgang zu der Funktionsnamensthematik noch: Es gibt einen Punkt, der uns uU. dabei rausgegangen ist: Wenn die Funktion via InternalTimer verwaltet wird (oder werden kann), dann sollte sie in "fhemdebug timerList" möglichst zuordenbar sein. Kann also sein, dass man das an einigen wenigen Stellen nochmal checken sollte... 
Ja, genau. Was? Kein Wort verstanden ;D
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 24 April 2021, 17:09:54
Zitat von: drhirn am 24 April 2021, 16:55:43
Das Problem liegt hier:
$decoded  = decode_json(encode($cp,$json))
Also konkret im decode_json. Danach kommt nur Müll raus. Aber ich versteh zum einen nicht, warum plötzlich. Und zum anderen nicht, wie ich's lösen könnte.
Vielleicht ist an der Stelle die Info bzgl. utf8 verloren gegangen. Muss mal schauen. "ganz früher" stand da mal ausdrücklich utf8, dann wollte jemand was anderes haben, usw.. Fand das gestern seltsam, dass es nicht im list auftaucht und vermute ein Problem bei der Initialisierung oder beim Abholen von dem Ort, an dem es stehen sollte.

Jetzt erst mal eine Version, die
a) auch Channels als userattr vorsieht (cref ist angepaßt) und
b) eine reparierte _ct2rgb enthält. Sieht von der HEX-Darstellung her ok aus.

Zitat
Stimmt. Kenn ich aus eigener Erfahrung.
(Fand das früher auch "häh...?!?"...)
...und so gibt es eben für alles mögliche Pro- und Contra-Argumente....

Zitat
Ja, genau. Was? Kein Wort verstanden ;D
Da geht es darum, dass man manchmal zu debugging-Zwecken als Entwickler auch mal anschaut, welche Timer grade warum laufen. Und wenn das "unleserlich" ist, was man angezeigt bekommt, ist das nicht schön...
(ggf. einfach mal "help fhemdebug" ansehen, ist durchaus interessant).
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 24 April 2021, 17:25:07
Zitat von: Beta-User am 24 April 2021, 17:09:54
Vielleicht ist an der Stelle die Info bzgl. utf8 verloren gegangen. Muss mal schauen. "ganz früher" stand da mal ausdrücklich utf8, dann wollte jemand was anderes haben, usw.. Fand das gestern seltsam, dass es nicht im list auftaucht

Ja. Aber zum einen wurde das schon lange umgebaut. Zum anderen ist's das selbe Problem, wenn ich die Zeile wieder so wie früher einbaue. Und Dumper ist halt leider auch keine Hilfe, weil der wieder anders codiert.
Probier einfach mal aus, was bei dir bei einem Umlaut in der siteId passiert. Ich glaub echt, es liegt an mir. Aber ich hab jetzt schon diverse Neu- und Testinstallationen auf diversen Systemen hinter mir und komm nicht drauf, wo der Unterschied zu vor ein paar Tage ist.

ZitatDa geht es darum, dass man manchmal zu debugging-Zwecken als Entwickler auch mal anschaut, welche Timer grade warum laufen. Und wenn das "unleserlich" ist, was man angezeigt bekommt, ist das nicht schön...
(ggf. einfach mal "help fhemdebug" ansehen, ist durchaus interessant).
Ahhhhhh. Man dankt!
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 24 April 2021, 17:39:30
Zitat von: drhirn am 24 April 2021, 17:25:07
Ja. Aber zum einen wurde das schon lange umgebaut. Zum anderen ist's das selbe Problem, wenn ich die Zeile wieder so wie früher einbaue. Und Dumper ist halt leider auch keine Hilfe, weil der wieder anders codiert.
Probier einfach mal aus, was bei dir bei einem Umlaut in der siteId passiert. Ich glaub echt, es liegt an mir. Aber ich hab jetzt schon diverse Neu- und Testinstallationen auf diversen Systemen hinter mir und komm nicht drauf, wo der Unterschied zu vor ein paar Tage ist.
Teste mal (ca.) in Zeile 336
    $hash->{encoding} = $h->{encoding} // q{UTF-8};

Große Hoffnung habe ich nicht, aber eventuell ist das Problem, dass der Hash an der Stelle überhaupt da ist.

Wie gesagt: zum Testen bräuchte ich noch einen Satelliten, denn das mit dem ESP32 wollte grade auf die Schnelle nicht...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 24 April 2021, 17:43:17
Kein Unterschied.

Naja, du hättest noch einen Satelliten ;)
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 24 April 2021, 17:48:46
Schon klar, und mit dem werde ich das dann auch testen.

(Auch wenn der betreffende sehr gut aussieht: Ich mag Pi's einfach nicht. Ist ähnlich wie mit ESP8266...)
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 24 April 2021, 17:56:38
Zitat von: Beta-User am 24 April 2021, 17:48:46
Ich mag Pi's einfach nicht.

Huch. Warum das?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 24 April 2021, 18:18:13
Zitat von: Beta-User am 24 April 2021, 08:25:42
Hier dann noch der Versuch, den "Hue-Farbkreis" zu übersetzen:

[de.fhem:SetColor]
colors=( rot{Hue:0} | orangerot{Hue:15} | orange{Hue:30} | goldgelb{Hue:45} | ([(zitrus|zitronen)] gelb){Hue:60} | (gelb grün){Hue:75} | (grün gelb){Hue:90} | ((grass|hell) grün){Hue:105} | grün{Hue:120} | (dunkel grün){Hue:135} | (smaragd grün | wasser blau){Hue:150} | (türkis [grün] | grün blau ){Hue:165} | (türkis [blau] | blau grün ){Hue:180} | (azur [blau]){Hue:210}  | ([blau] violet){Hue:225} | ([marine] blau){Hue:240} | ([blau] violet){Hue:255} | (rosa){Hue:270} | (purpur [blau]){Hue:285} | (magenta [blau]){Hue:300} | (alt rosa){Hue:315} | (rubin rot){Hue:330} | (karmin rot){Hue:345} )
\[setze|färbe] $de.fhem.Device-light{Device} [$de.fhem.Room{Room}] [auf die Farbe] (<colors> | (warm weiss){Colortemp:100} | (kalt weiss){Colortemp:0} | (mittleres weiss){Colortemp:50} )

[de.fhem:SetColorGroup]
\[setze|färbe] (alle | sämtliche ) $de.fhem.Group{Group} [im] [( überall:global | $de.fhem.Room){Room}]  [auf die Farbe] (<de.fhem:SetColor.colors> | (warm weiss){Colortemp:100} | (kalt weiss){Colortemp:0} | (mittleres weiss){Colortemp:50} )


Damit ich auch wieder mal etwas sinnvolles beitrage:

Ich habe mir gerade einen Slot mit allen "HUE Farben" erzeugt, die ich so gefunden habe. Der heißt einfach hueColor:

braun:20
grüngelb:90
blaurot:330
leichtes grüngelb:75
grünblau:210
rot:0
grün:120
magenta:300
indigo:255
dunkelgrün:120
leichtes blaurot:345
zinnober:15
cyan:180
leichtes grünblau:225
leichtes blaugrün:135
limett:105
orange:30
blaugrün:150
gelb:60
blau:240
blaumagenta:315
grüncyan:165
violett:270
blaucyan:195
rotmagenta:315
safran:45


Und den dann in die sentences eingebaut, um den HUE-Wert einer Lampe zu ändern:

\[setze|färbe|stelle] [der|die|das] $de.fhem.Device-light{Device} [im|in der|auf der|auf dem] [$de.fhem.Room{Room}] [auf] [die Farbe] $hueColor{Hue}


Ist im Prinzip das gleiche, wie du auch gemacht hast. Nur übersichtlicher.
Deswegen meinte ich, dass wir das einfach in das Language-File einbauen. Und daraus einen Slot erstellen. Dann hat's jeder gleich zur Verfügung ohne sich zuerst einen Slot bauen zu müssen.
Geht aber natürlich so auch.



Ich bekomme da übrigens Komma-Werte für Hue (z.B. 57343.125). Ist das ein Problem oder soll das so sein?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 25 April 2021, 10:29:11
Zitat
Ich bekomme da übrigens Komma-Werte für Hue (z.B. 57343.125). Ist das ein Problem oder soll das so sein?
Na ja, meine HUEDevices akzeptieren das so, es wird halt gerechnet. Nach Ausführung steht dann da wieder ein ganzzahliger Wert. Können auch zwecks besserer  Optik runden?

Zitat von: drhirn am 24 April 2021, 18:18:13
Damit ich auch wieder mal etwas sinnvolles beitrage:
Auch diese ganze Testerei usw. ist extrem wichtig!

Die Idee mit dem "slot aus config" finde ich umso besser, je länger ich darüber nachdenke!
Mit meinem sentence wollte ich v.a. erst mal eine Grundlage zum Testen bereitgestellt haben, slot ist eigentlich das Mittel der Wahl, ist aber m.E. dieselbe Kategorie wie userattr: Man denkt erst mal "watndat"?
Denke aber, es würde Sinn machen, das feature generisch auszulegen, also z.B. dann für jeden Eintrag im Abschnitt  "slots" dann auch einen solchen zu generieren. Dann könnten wir z.B. auch einen für Rgb und OnOff bereitstellen. Wenn der User die nicht mag, kann er entweder andere Inhalte in die configfile reinschreiben, oder eben den slot kopieren, abändern und dann einen eigenen Namen dafür vergeben.



Der Pi hängt jetzt zwar im Netz, aber sonst ist erst mal nicht viel. Vermute einen Anfängerfehler, hier die settings:

{
    "microphone": {
        "pyaudio": {
            "device": "0"
        },
        "system": "pyaudio"
    },
    "mqtt": {
        "enabled": "true",
        "host": "ip vom fhem-server",
        "port": "1884",
        "site_id": "Küche"
    },
    "sounds": {
        "aplay": {
            "device": "default:CARD=seeed2micvoicec"
        },
        "system": "aplay"
    },
    "text_to_speech": {
        "system": "nanotts"
    },
    "wake": {
        "system": "hermes"
    }
}


Zitat von: drhirn am 24 April 2021, 17:56:38
Huch. Warum das?
Die Dinger haben ein paar grundlegende Mängel, angefangen bei der SD-Karten-Thematik und der Nutzung der GPIO's, die v.a. Anfänger dazu verleiten, Server und Hardware in der Hausautomatisierung zu vermischen. (Aktuelles Beispiel: https://forum.fhem.de/index.php/topic,120658.0.html Wenn man schon einen ATMEga dazwischenklemmt, dann übermittelt man per USB und gut ist...)


Daher mag ich für alle zwecke, die man mit ebensolchen erledigen kann Microcontroller lieber. Daher auch noch ein Screenshot von dem ESP32-Ding, das als Mikro überraschend gut funktioniert, wenn man direkt reinspricht, aber halt bauartbedingt einen miesen Soundoutput hat...
(Es gibt den ESP32 auch als "backiges" Board mit spezieller Soundausstattung, an die man dann auch einen 3W-Speaker klemmen kann. Wäre eventuell auch einen Test wert...)
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 25 April 2021, 10:44:53
Zitat von: Beta-User am 25 April 2021, 10:29:11Na ja, meine HUEDevices akzeptieren das so, es wird halt gerechnet. Nach Ausführung steht dann da wieder ein ganzzahliger Wert. Können auch zwecks besserer  Optik runden?
Wäre irgendwie schöner. Dachte nur, da gibt's vielleicht irgendwelche Vorgaben.

ZitatDenke aber, es würde Sinn machen, das feature generisch auszulegen, also z.B. dann für jeden Eintrag im Abschnitt  "slots" dann auch einen solchen zu generieren. Dann könnten wir z.B. auch einen für Rgb und OnOff bereitstellen. Wenn der User die nicht mag, kann er entweder andere Inhalte in die configfile reinschreiben, oder eben den slot kopieren, abändern und dann einen eigenen Namen dafür vergeben.
Meine Rede :D

ZitatDer Pi hängt jetzt zwar im Netz, aber sonst ist erst mal nicht viel. Vermute einen Anfängerfehler, hier die settings:
Wakeword fehlt. Das wird nur für die App an der Base konfiguriert. Ein regulärer Satellit macht das Wakeword selbst und überträgt dann an die Base nur, was gesprochen wurde.

ZitatDie Dinger haben ein paar grundlegende Mängel, angefangen bei der SD-Karten-Thematik und der Nutzung der GPIO's, die v.a. Anfänger dazu verleiten, Server und Hardware in der Hausautomatisierung zu vermischen.
Es ist wie bei allem: Man sollte schon wissen, was man tut. Das mit der SD ist ein Problem. Aber, das Ding war ja als billige Lernplattform gedacht. Konnte ja keiner ahnen, dass die so "missbraucht" werden. RPi und ESP sind für mich zwei paar Schuhe.

Zitat
(Es gibt den ESP32 auch als "backiges" Board mit spezieller Soundausstattung, an die man dann auch einen 3W-Speaker klemmen kann. Wäre eventuell auch einen Test wert...)
Hast du da einen Link bitte?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 25 April 2021, 10:47:07
Hier die Config meines RPi-Satelliten:

{
    "intent": {
        "system": "hermes"
    },
    "microphone": {
        "pyaudio": {
            "udp_audio_port": "12202"
        },
        "system": "pyaudio"
    },
    "mqtt": {
        "enabled": "true",
        "host": "ip-der-base",
        "port": "12183",
        "site_id": "vorraum"
    },
    "sounds": {
        "system": "aplay"
    },
    "speech_to_text": {
        "system": "hermes"
    },
    "text_to_speech": {
        "system": "hermes"
    },
    "wake": {
        "porcupine": {
            "keyword_path": "porcupine_raspberry-pi.ppn",
            "udp_audio": "12202"
        },
        "system": "porcupine"
    }
}


Ahhh, blödes Timeout in den Screenshot mitgerutscht. Soll dich nicht nervös machen. Liegt dran, dass die Base nicht läuft.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 25 April 2021, 12:14:47
Zitat von: drhirn am 25 April 2021, 10:44:53
Wäre irgendwie schöner. Dachte nur, da gibt's vielleicht irgendwelche Vorgaben.
Keine Vorgaben, round wird eingebaut...

Zitat
Meine Rede :D
;D ... ist ja schon gut, kommt bei Gelegenheit...

Zitat
Wakeword fehlt. Das wird nur für die App an der Base konfiguriert. Ein regulärer Satellit macht das Wakeword selbst und überträgt dann an die Base nur, was gesprochen wurde.
:-[ bin wohl zu doof für diese Sache... Jetzt habe ich (bis auf den abweichenden Port) fast alle Einstellungen auf identisch, wobei dann nur noch die porcupine_linux statt .*_pi angezeigt wird.
Will irgendwie noch nicht, das ganze.

Zitat
Es ist wie bei allem: Man sollte schon wissen, was man tut. Das mit der SD ist ein Problem. Aber, das Ding war ja als billige Lernplattform gedacht. Konnte ja keiner ahnen, dass die so "missbraucht" werden. RPi und ESP sind für mich zwei paar Schuhe.
Na ja, am Anfang konnte keiner ahnen, dass die Dinger so eine große Verbreitung finden.
Aber "irgendwann" hätte man ein SSD-Interface (M.2? auf die Rückseite) und eine (von mir aus über einen Kondensator gespeiste) RTC einbauen können...

Und ja, es sind zwei Paar Stiefel. Daher: Was man mit einer MCU erledigen kann, sollte man mAn. damit erledigen.

Zitat
Hast du da einen Link bitte?
Hoffe, mit den Suchworten aus dem ESP32-github-Dingens das richtige bestellt zu haben: https://smile.amazon.de/dp/B085ZLFBDB?psc=1&smid=AMW1WIDE8JCF7&ref_=chk_typ_imgToDp
Oder:
https://de.aliexpress.com/item/1005001889297112.html?albpd=de1005001889297112&acnt=494-037-6276&aff_platform=aaf&albpg=539263010115&netw=u&albcp=12554800262&pvid=0ac021fa-a99a-43ae-89c7-d86ef2759f01&sk=UneMJZVf&scm=1007.23534.124000.0&trgt=539263010115&terminal_id=dddd910e988e467bb38bfe40c3488535&needSmbHouyi=false&albbt=Google_7_shopping&src=google&crea=de1005001889297112&aff_fcid=87af2e3631fc4783bebac73b2d67a9ed-1619340281444-03840-UneMJZVf&gclid=EAIaIQobChMIxbfdyYCZ8AIVCrh3Ch2L8wV3EAQYAyABEgLdXPD_BwE&albag=127990761348&aff_fsk=UneMJZVf&albch=shopping&albagn=888888&isSmbAutoCall=false&aff_trace_key=87af2e3631fc4783bebac73b2d67a9ed-1619340281444-03840-UneMJZVf&rmsg=do_not_replacement&device=c&gclsrc=aw.ds

Jetzt lege ich das erst mal auf die Seite und genieße die Sonne...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 25 April 2021, 12:20:51
Zitat von: Beta-User am 25 April 2021, 12:14:47
:-[ bin wohl zu doof für diese Sache... Jetzt habe ich (bis auf den abweichenden Port) fast alle Einstellungen auf identisch, wobei dann nur noch die porcupine_linux statt .*_pi angezeigt wird.
Will irgendwie noch nicht, das ganze.
Da gibt's ja einen Refresh-Button neben "Available Keywords". Drück den mal und wähl dann "porcupine" aus.
Und oben gibt's den grauen Log-Button. Lass das mal mitlaufen, wenn du das nächste Mal ein Wakeword sprichst. Bzw. auch einen MQTT-Explorer.

ZitatAber "irgendwann" hätte man ein SSD-Interface (M.2? auf die Rückseite) und eine (von mir aus über einen Kondensator gespeiste) RTC einbauen können...
Macht's halt wieder teurer.

ZitatHoffe, mit den Suchworten aus dem ESP32-github-Dingens das richtige bestellt zu haben: https://smile.amazon.de/dp/B085ZLFBDB?psc=1&smid=AMW1WIDE8JCF7&ref_=chk_typ_imgToDp
Danke!

ZitatJetzt lege ich das erst mal auf die Seite und genieße die Sonne...
Tu das! Irgendwann, irgendwann hab ich dann auch mal Balkon, Terrasse oder Garten und kann das auch ;).
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 25 April 2021, 19:06:04
So ein M....

Also: stelle ich auf arecord, bekommt mosquitto_sub ordentlich was zu sehen.
TTS funktioniert auch, wenn ich über das WEB-Interface was ausgeben lasse.

Ergo: Hardware ist funktional, es ist irgendein 60cm-Problem...

Eigentlich sollte es doch auch möglich sein, mit dem Button einen Dialog zu eröffnen? Aber da sehe ich auch schlicht und ergreifend nichts via MQTT, weder irgendwelche Dialog-Management Messages, noch irgendwas, das nach Audio für die Intent-Recognition aussieht.
(Vermutlich zu viel Sonne, und jetzt ist auch der Weißburgunder lecker, also ein andermal wieder RTFM...)
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 26 April 2021, 07:21:03
Nimm einfach meine Konfiguration. Die hat auf deinem auch funktioniert.
UDP für Wakeword und Audio Recording auf einen beliebigen Port stellen (ich nehm immer 12202), dann fließt nicht dauernd Audio über's Netzwerk sondern nur, wenn das Wakeword erkannt wurde.

Der Button tut standardmäßig nichts. Da müsstest du ein Script schreiben, dass den GPIO abgreift. Hab ich noch nie gemacht. Aber andere können da sicher mit Links oder Scripts helfen.

---edit---
Hier z.B.: https://community.rhasspy.org/t/using-respeaker-button-for-wake/370
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 26 April 2021, 08:18:41
Nun ja, vermutlich war es keine gute Idee, den docker-Container direkt auf 2.5.10 zu heben, da scheint was schiefgegangen zu sein; sieht irgendwie so aus, als wäre pyaudio kaputt.

Leider klemmt sich der ESP32 mit einer Umlaut-siteId zuverlässig vom MQTT-Verkehr ab, dto. für die App. Mit etwas tricksen kann ich allerdings "Unterstrich"-listening-Readings erzeugen, immerhin...

Na ja, bei anderen Dingen war ich erfolgreicher:
- "slots" via languagefile sollten jetzt funktionieren, Beispiel anbei;
- es gibt jetzt auch noch "Gruppen-gDT"-slots;
- Farbe bei Hue kann man erzwingen, wenn man ein "special" setzt:
attr Licht_Essen rhasspySpecials colorForceHue2rgb:1
(kurz angetestet, scheint zu funktionieren)
- hue usw. wird auf Ganzzahl gerundet;
- es gibt ein weiteres color-special (noch ungetestet), "colorCommandMap":
Da schreibe ich mal die Syntax noch nicht auf, im Moment sieht es mir danach aus, als bräuchte ich eventuell eine Option, die nach Color, Hue, ... und Colortemp unterscheidet. Im Moment sollte man beliebige Werte (nur) aus Color nach irgendwas mappen können (wie die "alten" Colours "0='rgb FF0000'" ).
- die Funktionen, die als Timeraufrufe verwendet werden können, haben jetzt wieder den RHASSPY_-Prefix. Finde es besser, wenn man in fhemdebug sehen kann, wo die hingehören.

(Danke für das scrpit für den PGIO, schaue ich mir bei Gelegenheit mal an).
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 26 April 2021, 08:28:00
Bei mir läuft auch alles auf 2.5.10

Ist hue wirklich so verbreitet? Ich hab das noch nie verwendet. Immer nur RGB und PCT für die Helligkeit.

Was war das Problem beim Einbinden von Color.pm?

Und, derzeit kann ich keine Lampen regeln, die nur die Lichtfarben (ct) unterstützen, weil immer das rgb-mapping verlangt wird. Muss das so sein?

Ich hab gestern noch bei Delete $prefix definiert. Das hat gefehlt.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 26 April 2021, 10:03:36
Zitat von: Beta-User am 26 April 2021, 08:18:41
Im Moment sollte man beliebige Werte (nur) aus Color nach irgendwas mappen können (wie die "alten" Colours "0='rgb FF0000'" ).

Wie meinst du das?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 26 April 2021, 10:39:50
Zitat von: drhirn am 26 April 2021, 08:28:00
Bei mir läuft auch alles auf 2.5.10
Der Pi hing gestern eine Zeitlang, ich dachte, er wäre abgeschmiert; evtl. ist dadurch was in pyaudio nicht richtig aktualisiert worden. K.A., ich werde den Container bei Gelegenheit nochmal pullen, vielleicht hilft das.

Zitat
Ist hue wirklich so verbreitet? Ich hab das noch nie verwendet. Immer nur RGB und PCT für die Helligkeit.
Kann ich nicht sagen, ob das "so verbreitet" ist. Meine beiden Farb-Typen konnten das eben, und ich finde das Konzept des 360°-Farbkreises eigentlich ganz einleuchtend.
Dagegen haben die RGBW-MiLights derzeit nicht mal ein rgb-Kommando (was ich auch erst festgestellt habe, nachdem die mit dem umgebogenen korrigierten ct-Code immer noch nicht wollten ::) ). Die wollen einen JSON mit den Einzelkanälen, was bisher wurst war, weil wenn Farbe, dann hue...

Vermutlich muss der mapping-Analyse-Code nochmal verändert werden, denn nachdem ich jetzt mal z.B. gesehen habe, wie das z.B. für zigbee2mqtt-Farb-Leuchten gemacht ist, fehlen da noch wichtige Details, v.a. zu HEX (das scheint aber nur "kleingeschriebenes" rgb zu sein)...

Zitat
Was war das Problem beim Einbinden von Color.pm?
Die Funktion wird nicht exportiert und fehlt daher in @INC. Hatte keine Neigung, dem grade intensiver nachzugehen...

Zitat
Und, derzeit kann ich keine Lampen regeln, die nur die Lichtfarben (ct) unterstützen, weil immer das rgb-mapping verlangt wird. Muss das so sein?
Wie machst du das genau?
Über den Color-slot kann es nicht funktionieren, bei mir waren da ein paar Weiß-Elemente mit dabei, die explizit in "Colortemp" übergeben wurden/werden. Vermutlich muss man dafür einen separaten slot anlegen und dann diesen slot als alternativen Farbwert in sentences.ini hinterlegen.
Ggf. hilft mir ein RAW-listing vom Zieldevice?

ZitatIch hab gestern noch bei Delete $prefix definiert. Das hat gefehlt.
stimmt.
Löschen bzw. umbenennen der Attribute ist aber eh' noch ein Thema...

Zitat von: drhirn am 26 April 2021, 10:03:36
Wie meinst du das?
Im Moment sollte sowas hier funktionieren:
attr Licht_Essen rhasspySpecials colorCommandMap:0='rgb FF0000' 120='rgb 00FF00' 240='rgb 0000FF'Damit würde aus einer im JSON-Element "Color" übergebenen Zahl der betreffende Befehl zugeordnet (ist "hinten" nicht auf rgb beschränkt, und wenn "vorne" ein RGB steht und RGB übergeben wurde, müßte es auch klappen). Oder wenn "grün" übergeben wurde, kann man eine heu-Befehl daraus basteln usw. usf.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 26 April 2021, 11:07:07
Zitat von: Beta-User am 26 April 2021, 10:39:50und ich finde das Konzept des 360°-Farbkreises eigentlich ganz einleuchtend.

Ja, ist nicht blöd.

ZitatWie machst du das genau?
Über den Color-slot kann es nicht funktionieren, bei mir waren da ein paar Weiß-Elemente mit dabei, die explizit in "Colortemp" übergeben wurden/werden. Vermutlich muss man dafür einen separaten slot anlegen und dann diesen slot als alternativen Farbwert in sentences.ini hinterlegen.
Ggf. hilft mir ein RAW-listing vom Zieldevice?

Gar nicht merke ich gerade, weil mir das HUE Modul das nicht (mehr) zur Verfügung stellt!? War der Meinung, ich hätte das mal gemacht. Das Reading ist nämlich da.

define HUEDevice6 HUEDevice 6  IODev=hueBridge2
attr HUEDevice6 userattr light lightSceneParamsToSave lightSceneRestoreOnlyIfChanged:1,0 light_map structexclude
attr HUEDevice6 IODev hueBridge2
attr HUEDevice6 alias hueFloorLamp01Wz
attr HUEDevice6 color-icons 2
attr HUEDevice6 devStateIcon {(HUEDevice_devStateIcon($name),"toggle")}
attr HUEDevice6 group Wohnzimmer
attr HUEDevice6 icon hue_filled_lightstrip
attr HUEDevice6 model FLS-H3
attr HUEDevice6 room Wohnzimmer->Licht,Beleuchtung,HUEDevice
attr HUEDevice6 subType dimmer
attr HUEDevice6 webCmd pct:dimDown:dimUp:toggle:on:off

setstate HUEDevice6 on
setstate HUEDevice6 2021-04-24 15:19:20 alert select
setstate HUEDevice6 2021-04-24 15:19:20 bri 254
setstate HUEDevice6 2021-04-24 15:19:20 colormode ct
setstate HUEDevice6 2021-04-24 15:19:20 ct 500 (2000K)
setstate HUEDevice6 2021-04-26 10:56:36 onoff 1
setstate HUEDevice6 2021-04-26 10:56:36 pct 100
setstate HUEDevice6 2021-04-25 22:42:26 reachable 1
setstate HUEDevice6 2021-04-24 15:19:20 rgb ffb16e
setstate HUEDevice6 2021-04-26 10:56:36 state on



ZitatIm Moment sollte sowas hier funktionieren:
attr Licht_Essen rhasspySpecials colorCommandMap:0='rgb FF0000' 120='rgb 00FF00' 240='rgb 0000FF'Damit würde aus einer im JSON-Element "Color" übergebenen Zahl der betreffende Befehl zugeordnet (ist "hinten" nicht auf rgb beschränkt, und wenn "vorne" ein RGB steht und RGB übergeben wurde, müßte es auch klappen). Oder wenn "grün" übergeben wurde, kann man eine heu-Befehl daraus basteln usw. usf.

Aha. Nett!

Das Licht-Thema nervt. Sollen wir's vorläufig lassen und uns auf etwas anderes konzentrieren? Und bezüglich Licht im Forum mal nach schlauen Ideen fragen?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 26 April 2021, 11:43:31
Zitat von: drhirn am 26 April 2021, 11:07:07
Das Licht-Thema nervt. Sollen wir's vorläufig lassen und uns auf etwas anderes konzentrieren? Und bezüglich Licht im Forum mal nach schlauen Ideen fragen?
Ja, finde es auch nervig, _glaube_ aber, ein paar mehr setter bereits eingefangen zu haben; müßte nur zum Testen mal ein paar passende Devices bauen, die hex, color_temp usw-Setter haben...

Vorab aber die eher wichtige Sache:
Zitat von: drhirn am 24 April 2021, 16:55:43
Das Problem liegt hier:
$decoded  = decode_json(encode($cp,$json))
Der default für $cp ist jetzt "UTF-8".

Davor war es:
$decoded  = decode_json(encode_utf8($json))
Nun sollte man annehmen, das sei dasselbe. Ist es aber nicht: https://perldoc.perl.org/Encode#encode_utf8 (https://perldoc.perl.org/Encode#encode_utf8)
Zitat
Equivalent to $octets = encode("utf8", $string). [...]
WARNING: do not use this function for data exchange as it can produce $string with not strict utf8 representation! For strictly valid UTF-8 $string representation use $string = decode("UTF-8", $octets [, CHECK]).
Aha... utf8 und UTF-8 sind nicht dasselbe, und das steht auch so in der Doku, siehe https://perldoc.perl.org/Encode#UTF-8-vs.-utf8-vs.-UTF8 (https://perldoc.perl.org/Encode#UTF-8-vs.-utf8-vs.-UTF8)

Augenreib, aber na ja... Vermutlich wäre es daher sinnvoll, mal "utf8" zum default zu erklären (bzw. über die DEF vorzugeben; das ist jetzt in der Fassung anbei so, ich weiß aber noch nicht, ob das nicht an anderer Stelle unangenehme Nebenwirkungen hat!).

Sorry für den "lapsus"!

Zitat von: drhirn am 26 April 2021, 11:07:07
Gar nicht merke ich gerade, weil mir das HUE Modul das nicht (mehr) zur Verfügung stellt!? War der Meinung, ich hätte das mal gemacht. Das Reading ist nämlich da.
Das Verhalten von Leuchten ist manchmal "komisch". Die HUEDevice "sollten" es eigentlich können, wenn es das Leuchtmittel hergibt; da wäre bei der speziellen Leuchte dann interessant, was "getAllSets()" auswirft?
Kann nicht sagen, ob justme1968 da was dran rumgebastelt hat, und ob das nicht auch ein Überbleibsel von einer Gruppensteuerung sein könnte...
Habe btw. auch eine MiLight-Fernbedienung, die irgendwie manchmal (vermittelt durch den Eigenbau-MiLight-Hub) "komische" Rückmeldungen aus dem Farbrad bringt; das scheint teilweise auch davon abzuhängen, in welchem Modus die grade ist. In diese Richtung scheint auch "colormode" zu gehen? (Endlose Weiten...).

ZitatUnd bezüglich Licht im Forum mal nach schlauen Ideen fragen?
Ja, vielleicht, nein...

Da ich schon bei geschlagenen zwei (!) Gerätetypen nicht auf einen eigenen Nenner komme, befürchte ich, dass das zu nichts führt, weil die Vorstellungen davon, wie das sein müßte dann wieder sehr weit auseinandergehen.
Ich _glaube_ daher, dass wir die Hue- und Rgb-Optionen halbwegs funktional haben sollten (will sagen: den Rgb-slot in der language-file drin) und das mit dem Mapping (ohne separates Attribug) klappen sollte. Dann ist es so universell, dass man 80/20 behaupten kann, dass es funktioniert.
Bin guten Mutes, dass wir genau diesen Stand erreicht haben. Mein verbliebenes "Colortemp"-Problem sollte dann dadurch gelöst werden, dass ich einfach einen passenden setter für die MiLight-MQTT2-Devices generiere. (Das ist kein Hexenwerk...).
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 26 April 2021, 12:04:57
Zitat von: Beta-User am 26 April 2021, 11:43:31
Augenreib, aber na ja... Vermutlich wäre es daher sinnvoll, mal "utf8" zum default zu erklären (bzw. über die DEF vorzugeben; das ist jetzt in der Fassung anbei so, ich weiß aber noch nicht, ob das nicht an anderer Stelle unangenehme Nebenwirkungen hat!).

Macht leider auch keinen Unterschied.

Zitatda wäre bei der speziellen Leuchte dann interessant, was "getAllSets()" auswirft?
Was was auswirft? Wie komme ich zu einem Ergebnis?
Kann nicht sagen, ob justme1968 da was dran rumgebastelt hat, und ob das nicht auch ein Überbleibsel von einer Gruppensteuerung sein könnte...

ZitatIch _glaube_ daher, dass wir die Hue- und Rgb-Optionen halbwegs funktional haben sollten (will sagen: den Rgb-slot in der language-file drin) und das mit dem Mapping (ohne separates Attribug) klappen sollte. Dann ist es so universell, dass man 80/20 behaupten kann, dass es funktioniert.
Ich wär dafür, dass du dann einfach RAW und sentences postest und ich das ausprobiere. Ich kann nämlich nicht mehr folgen, was jetzt geht und was nicht ;D
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 26 April 2021, 12:46:01
Zitat von: drhirn am 26 April 2021, 12:04:57
Macht leider auch keinen Unterschied.
Hmmm, dann bin ich im Moment wirklich komplett ratlos...

Zitat
Was was auswirft? Wie komme ich zu einem Ergebnis?
FHEM-Kommandofeld:
{getAllSets('HUEDevice6')}Dann sehen wir wenigstens mal, was erkannt werden könnte.

Zitat
Ich wär dafür, dass du dann einfach RAW und sentences postest und ich das ausprobiere. Ich kann nämlich nicht mehr folgen, was jetzt geht und was nicht ;D
Für die Colortemp-Geschichte:
[de.fhem:SetColor]
\[setze|färbe|stelle] [der|die|das] $de.fhem.Device-light{Device} [im|in der|auf der|auf dem] [$de.fhem.Room{Room}] [auf] [die Farbe] ( $hueColor{Hue} | (warm weiss){Colortemp:100} | (kalt weiss){Colortemp:0} | (mittleres weiss){Colortemp:50} )

Falls das HUEDevice ct als setter kennt, müßte dann bei den weiss-Anweidungen auch was passieren (bzw. ggf. auch, wenn das nicht der Fall ist, aber rgb geht).

Was RAW angeht, ist das nicht so einfach, denn ob jetzt bei einer Hardware am Ende wirklich was sinnvolles ankommt, sieht man eigentlich nur, wenn man wirklich in der Realität versucht, das Leuchtmittel zu steuern.
Klappen müßte das jetzt mit allem, was hue, ct, color_temp, rgb, RGB oder hex versteht, und zwar alles mit obigem Satz...

Next step bzgl. wäre daher ein sentence für die Sättigung. Ist im Prinzip beliebig, solange irgendwas zwischen 0 und 100 als "Saturation" übergeben wird, also z.B.
\die sättigung von $de.fhem.Device-light{Device} [im|in der|auf der|auf dem] [$de.fhem.Room{Room}] soll [auf] (0..100){Value!float} [prozent]
...
Hier noch der zusätzliche rgb-Color-slot:
"slots":
{
  "Colors": "braun:20,grüngelb:90,blaurot:330,leichtes grüngelb:75,grünblau:210,rot:0,grün:120,magenta:300,indigo:255,dunkelgrün:120,leichtes blaurot:345,zinnober:15,cyan:180,leichtes grünblau:225,leichtes blaugrün:135,limett:105,orange:30,blaugrün:150,gelb:60,blau:240,blaumagenta:315,grüncyan:165,violett:270,blaucyan:195,rotmagenta:315,safran:45",
  "ColorsRgb": "grüngelb:80FF00,blaurot:8000FF,leichtes grüngelb:BFFF00,grünblau:0080FF,rot:FF0000,grün:00FF000,magenta:FF00FF,indigo:4000FF,dunkelgrün:00FF00,leichtes blaurot:carmine,zinnober:FF4000,cyan:00FFFF,leichtes grünblau:0040FF,leichtes blaugrün:00FF40,limett:40FF00,orange:FF8000,blaugrün:00FF80,gelb:FFFF00,blau:0000FF,blaumagenta:FF00BF,grüncyan:00FFBF,violett:8000FF,blaucyan:00BFFF,rotmagenta:FF00BF,safran:FFBF00"
}

Der ist ggf. für die gedacht, die sich lieber an den RGB-Werten orientieren wollen und setzt vermutlich voraus, dass das FHEM-Device mit rgb umgehen kann, da Hue bereits "durch" ist, wenn Rgb geprüft wird. Diese Werte können entweder über den Rgb-Key kommen oder in Color.

Hilft das erst mal weiter?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 26 April 2021, 13:50:23
Zitat von: Beta-User am 26 April 2021, 12:46:01
FHEM-Kommandofeld:
{getAllSets('HUEDevice6')}Dann sehen wir wenigstens mal, was erkannt werden könnte.
Anführungszeichen vergessen. Und beim Device den falschen subType eingestellt gehabt  :-[
off:noArg on:noArg toggle:noArg statusRequest:noArg pct:colorpicker,BRI,0,1,100 bri:colorpicker,BRI,0,1,254 color:colorpicker,CT,2000,1,6500 ct:colorpicker,CT,154,1,500 dimUp:noArg dimDown:noArg ctUp:noArg ctDown:noArg alert:none,select,lselect rename scene:[...] intervals off-till blink off-till-overnight on-till off-for-timer on-till-overnight on-for-timer attrTemplate:?


ZitatFalls das HUEDevice ct als setter kennt, müßte dann bei den weiss-Anweidungen auch was passieren (bzw. ggf. auch, wenn das nicht der Fall ist, aber rgb geht).
Ja, geht. Aber mit vollkommen falschen Werten.
Aus 2000 von Rhasspy wird 90000 in FHEM
Aus 6500 von Rhasspy wird 292500 in FHEM

ZitatHilft das erst mal weiter?
Ja, hab's jetzt verstanden. Danke!
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 26 April 2021, 14:07:05
Zitat von: drhirn am 26 April 2021, 13:50:23
Ja, geht. Aber mit vollkommen falschen Werten.
Aus 2000 von Rhasspy wird 90000 in FHEM
Aus 6500 von Rhasspy wird 292500 in FHEM
Sorry, das hätte ich vermutlich besser erklären sollen...

Also: Es ist mal wieder nicht standardisiert, was Mindest- und Höchstwert ist. Der Code ermittelt das selbstständig aus den Werten und erwartet, dass du ihm als Colortemp einen Prozentwert übergibst, also irgendwas zwischen 0 und 100 mit dem Verständnis: 0=so warm wie möglich, 100=so kalt wie es geht...
Vermutlich liegt da der "Fehler". Trotzdem fehlt da wohl eine Begrenzungslogik, ich schau mal, dass das noch reinkommt...

EDIT: habe mal min/max für die diversen Varianten eingebaut und dann noch ein paar "ungetestete Kleinigkeiten" (weitestgehend auch in der cref) ergänzt..
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 26 April 2021, 15:52:35
Zitat von: Beta-User am 26 April 2021, 14:07:05
Sorry, das hätte ich vermutlich besser erklären sollen...

Also: Es ist mal wieder nicht standardisiert, was Mindest- und Höchstwert ist. Der Code ermittelt das selbstständig aus den Werten und erwartet, dass du ihm als Colortemp einen Prozentwert übergibst, also irgendwas zwischen 0 und 100 mit dem Verständnis: 0=so warm wie möglich, 100=so kalt wie es geht...
Vermutlich liegt da der "Fehler". Trotzdem fehlt da wohl eine Begrenzungslogik, ich schau mal, dass das noch reinkommt...

EDIT: habe mal min/max für die diversen Varianten eingebaut und dann noch ein paar "ungetestete Kleinigkeiten" (weitestgehend auch in der cref) ergänzt..

Sollen wir das dann nicht lieber über SetNumeric abfackeln?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 26 April 2021, 16:12:27
Spontanreaktion: Nein, nein, bloß nicht...

Mal meine ungeordneten Gedanken dazu:
Theoretisch ginge das wohl, aber sprachlich ist alles, was direkt oder indirekt mir Farbe zu tun hat viel näher an "rot" oder "grün" dran. Von daher ist das mit dem "Einheitssatz" für Farbtemperatur an der Stelle m.E. schon alleine deswegen hilfreich, weil man Vermischungen mit allem möglichen anderen vermeidet (v.a., wenn man gDT setzt und dann auf -light eingrenzt).

Innerhalb der Lichtsteuerung ist es auch sehr viel einfacher, ggf. den "falschen" setter in etwas umzuwandeln, das dann funktioniert. Der "Wechsel" von "SetNumeric" nach "rgb" ginge sonst praktisch gar nicht oder nur mit großen Verrenkungen... Für "Saturation" habe ich da zwar noch keine zündende Idee, vermute aber, dass es ähnlich ist wie mit dem bisherigen Rest.

Das Spontangefühl mag täuschen, aber für mich ist auch ein sehr starkter Indikator, dass das bisher komplett separat abgehandelt wurde. Jetzt müßte es z.B. gehen, das Color-Mapping auch über das rhasspyMapping abzubilden (hab's noch nicht getestet), aber eben unter einer anderen Untergruppe (SetColorParms).
Generell: Evtl. wäre eine Export-Funktion ganz praktisch, falls jemand das automatisch erstelle Mapping als Gerüst nehmen will. (Ist aber nicht dringlich).

Was in der Version aus dem letzten Post noch eingebaut war: Ändern des prefix führt jetzt dazu, dass die Attribut-Inhalte auf die neuen Namen "umgezogen" werden (und die alten gelöscht, wenn diese keine RHASSPY-Instanz mehr verwendet).
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 26 April 2021, 16:18:01
Zitat von: Beta-User am 26 April 2021, 16:12:27
Spontanreaktion: Nein, nein, bloß nicht...
Hahaha

Zitat(v.a., wenn man gDT setzt und dann auf -light eingrenzt)
Mach ich nicht (kann ich dzt. nicht machen), drum hab ich nicht daran gedacht.

ZitatInnerhalb der Lichtsteuerung ist es auch sehr viel einfacher, ggf. den "falschen" setter in etwas umzuwandeln, das dann funktioniert. Der "Wechsel" von "SetNumeric" nach "rgb" ginge sonst praktisch gar nicht oder nur mit großen Verrenkungen... Für "Saturation" habe ich da zwar noch keine zündende Idee, vermute aber, dass es ähnlich ist wie mit dem bisherigen Rest.
...und hab nicht daran gedacht, dass ct ja auch für richtige Farben verwendet wird.

ZitatWas in der Version aus dem letzten Post noch eingebaut war: Ändern des prefix führt jetzt dazu, dass die Attribut-Inhalte auf die neuen Namen "umgezogen" werden (und die alten gelöscht, wenn diese keine RHASSPY-Instanz mehr verwendet).
Jup, gesehen. Danke!

Bzgl. venetian-blind: Sollen wir wirklich "venetian blind" im Code lassen? "blind" ist "blind". Jalousien funktionieren doch alle gleich. Egal ob sie aus Venedig sind oder nicht. Oder?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 26 April 2021, 16:31:57
Zitat von: drhirn am 26 April 2021, 16:18:01
Bzgl. venetian-blind: Sollen wir wirklich "venetian blind" im Code lassen? "blind" ist "blind". Jalousien funktionieren doch alle gleich. Egal ob sie aus Venedig sind oder nicht. Oder?
Na ja, ich kenne die Begrifflichkeit v.a. von ZWave her. Da kann man einen normalen "blind"-Aktor eben im "venetian mode" betreiben. Du gehst gedanklich vermutlich davon aus, dass ein "blind" immer eine Jalousie ist und ein "shutter" immer ein Rollladen (bzw. das, was wir hier im Südwestdeutschen eben als solche bezeichnen).

MWn. ist die Unterscheidung aber nicht wirklich trennscharf, mal abgesehen davon, dass sich das "venetian" _vielleicht_ am ehesten für die "echte" Jalousie durchgesetzt hat:
https://en.wikipedia.org/wiki/Window_blind#Venetian
(leo.org ist da ziemlich bunt, was shutter und blind angeht...)

Falls du bessere Vorschläge hast: her damit, ich bin mal wieder eher an der Funktionaliät interessiert wie am wording ;D .

(Ach so: das zugrundeliegende Problem kommt aus der Funktionalität meiner ZWave-Aktoren. Steuert man die über den Controller (in meinem Fall also FHEM), werden die Lamellen wieder in die letzte Lage gedreht, was z.B. beim Öffnen bedeutet, dass wieder ein kleines Stück geschlossen wird bzw. beim Schließen, dass die Lamellen wieder "Innenseite nach außen" gedreht werden. Dazu musste schon "Spezialcode" in ASC her, und hier ist es m.E. auch ausgesprochen zweckmäßig, einfach auch den Ziellevel als Drehwinkel zu nehmen).
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 26 April 2021, 16:59:40
Ich dachte mir nur, es ist einfach kürzer und weniger Tippfehler-anfällig. Ich kenn in dem Fall nur "venetian blinds" und nenn die auch Jalousien. Rollladen heißt bei mir übrigens auch Rollladen ;D

(Und im Rest Österreichs ist es genau so. Gerade nachgefragt ;) )
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 26 April 2021, 17:06:41
Ja, "Rollladen" dürfte (!) weitgehend im deutschsprachigen Raum einheitlich verstanden werden, aber was ist mit "Rollo"...(Heillose Verwirrung, zumal "ROLLO" (also das FHEM-Modul) (bisher?) nur "Rollladenmodus" kann (afaik)).

Von daher fand ich es angemessen, irgendwie kenntlich zu machen, dass es eben irgendwas "spezielles" ist. Aber wie gesagt: Darfst du gerne so machen, wie es dir beliebt, solange ich meine Jalousien am Ende voll geöffnet resp. geschlossen bekomme ;D .
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 26 April 2021, 17:08:24
Rollo ist für mich die Abkürzung von Rollladen ;D
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 27 April 2021, 08:27:41
Unabhängig von der Benennung mal die Rückmeldung, dass meine Jalousien jetzt den venetianBlind-Eintrag haben und zumindest auf den ersten Blick so funktionieren wie erhofft :) .
Dafür sind die dusseligen MiLights widerspenstig, was mal wieder nicht am Code liegt sondern an den Leuchtmitteln: Die verstehen jetzt zwar hex, aber wenn es in die Nähe von FFFFFF (bzw. ffffff) geht, sind die Ergebnisse seltsam. Wenn man bei denen weiss will, muss man explizit diesen Modus einschalten. Unschön...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 27 April 2021, 08:44:27
Cool!

Das mit den MiLights ist ein bisschen lästig. Andererseits hätten wir für solche Spezialfälle ja immer noch die "traditionellen" Mappings. Oder Shortcuts ;)



Musste gesten beim Einschlafen an dich denken. Klingt jetzt aber romantischer, als es war ;D
Mir lässt deine Pi-Sache keine Ruhe. Die Docker-Container haben ja nichts mit pyaudio zu tun. Audio wird ja einfach vom Host zum Container durchgereicht.
Wie startest du den Container? Eh mit docker-compose up -d im entsprechenden Verzeichnis? Und kannst du mir mal die docker-compose.yml posten bitte. Die liegt entweder in ~/rhasspy oder in /data/rhasspy. Vielleicht hab ich da was vergessen. Andererseits, bei meinen Tests hat's ja funktioniert.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 27 April 2021, 09:58:33
Zitat von: drhirn am 27 April 2021, 08:44:27
Das mit den MiLights ist ein bisschen lästig. Andererseits hätten wir für solche Spezialfälle ja immer noch die "traditionellen" Mappings. Oder Shortcuts ;)
Ja! Und ja, schon, vielleicht, nein...

Ja: Die MiLights sind zwar "schon immer" ein Quell der Freude (und nicht nur "ein bisschen lästig"), in unserem Zusammenhang aber vermutlich nur eine Sonderlocke von vielen möglichen (wie gesagt, die sind eingebunden über MQTT2_DEVICE, was nicht viel mehr heißt wie: Was eigentlich dahinter steht und dann an die jeweilige echte Hardware weitergegeben wird, wissen wir in vielen anderen Fällen genausowenig...

nein: "traditionelle" Mappings und shortcuts sind zwar möglich, aber aus dem Alter für's Vokabellernen bin ich raus, und m.E. kann man es auch niemandem vermitteln, dass er für die Steuerung bestimmter Leuchtmittel ganz andere Wörter verwenden soll wie für andere.

MAn. muss man das also durch passende Einstellungen auf der FHEM-Seite lösen und den input aus einem "Einheitssatz" aus Rhasspy generieren.
Läuft vermutlich auf weitere "Color-Mapping"-Einträge in "specials" raus. Vorschlag wäre: "colorTempMapping" (bei Bedarf dann noch "colorHueMapping"?).



Was den Pi angeht: den werde ich voraussichtlich vor Do. bzw. dem WE nicht mehr in Betrieb nehmen, bitte daher keine weiteren schlaflosen Nächte deswegen :) . Vielleicht finden sich ja jemand, der uns die strukturellen Probleme hinter dem UTF-8-Problem verklickern kann... Momentan habe ich die "lc"-Transformation im Verdacht.
Schnelles Suchmaschinenbefragen liefert https://perldoc.perl.org/functions/lc (https://perldoc.perl.org/functions/lc). Bin nur etwas ratlos, as ich damit anfangen soll:
use feature 'unicode_strings'
Würde das also mal in unseren header einbauen (mit ";" am Ende der Zeile), ist aber auch wieder nur irgendwie geraten...

EDIT: Kann schon sein, dass ich versehentlich den Startaufruf für das docker-image geändert habe; nach dem update startete der Container nicht mehr automatisch, soweit ich mich entsinne. (Aber wie gesagt: eilt nicht)
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 27 April 2021, 10:21:33
Boa, du bist ein Held! Das use feature ändert zwar nichts. Aber mit lc hattest du vollkommen recht!

In getRoomName

#my $siteId = lc $data->{siteId};
my $siteId = $data->{siteId};

und es funktioniert wieder.

Das ist mal ein guter Ansatz. Bin die nächsten zwei Stunden verhindert, aber danach schau ich mal, was man da tun könnte.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 27 April 2021, 10:52:32
Zitat von: drhirn am 27 April 2021, 10:21:33
Das use feature ändert zwar nichts.
Doch, schon, anderswo. Aber leider in die völlig falsche Richtung ;D ...

Wir müssen nur irgendwie den Raum "kleinkriegen", sonst passt das nicht zur sonstigen Logik.
Hier mal der Versuch, das (und das Colortemp-Mapping unter dem Namen "colorTempMap") zu fixen. Bin mal gespannt, ob beides so klappt...

attr lampe1 rhasspy3Specials colorTempMap:0="command set_white" 50="command set_white" 100="command set_white"
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 27 April 2021, 11:04:57
Keine guten Nachrichten bezüglich Umlauten. Hat sich nichts geändert
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 27 April 2021, 11:21:53
...bedeutet: wir lassen das mit lc erst mal weg?
$room = ReadingsVal($hash->{NAME}, $rreading, $siteId);

Ausgesprochen unschön. Habe Sorge, dass dann das mit dem Auffinden des richtigen Devices häufig schiefgehen wird, weil wir überall sonst von Kleinschreibung ausgehen, und die Hash-lookups nur klappen, wenn es 1:1 paßt... Sehe aber grade keine andere Option.
Vielleicht ist auch das use utf8-Pragma nicht glücklich?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 27 April 2021, 11:31:38
Wir lassen's so, wie's war. Das Verhalten ist nicht konsistent.

Gestern hatte ich z.B. sowas im Log:
Msg: hermes/dialogueManager/sessionStarted => {"sessionId": "küche-porcupine_raspberry-pi-68a2c8a4-986d-4e38-bb6d-9f4516afe32f", "siteId": "küche", "customData": "porcupine_raspberry-pi", "lang": null}

Heute sieht das so aus:
hermes/dialogueManager/sessionStarted => {"sessionId": "küche-porcupine_raspberry-pi-a5fdee9a-5bff-4405-90a0-31edae13c13e", "siteId": "küche", "customData": "porcupine_raspberry-pi", "lang": null}

Und darauf hat nichts, was wir gemacht haben, einen Einfluss.

So lange kein anderer testet, können wir eigentlich nichts dazu sagen. Vielleicht liegt's ja wirklich an mir.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 27 April 2021, 11:58:08
Glaube nicht, dass das an dir liegt!

Jedenfalls scheint ein utf8::downgrade() vorab dann die "kleine Küche" via lc zu erzeugen, wenn die Message sauber reinkommt.
Evtl. müssen wir da noch tweaken, und ich hoffe auch sehr, dass das nicht den downgrade kaputt macht....
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 27 April 2021, 12:15:00
Bevor ich's jetzt gleich wieder überschreibe nur zu Dokumentationszwecken eine Lösung, die bei mir gerade funktioniert:

    my $siteId = decode('UTF-8', $data->{siteId});
    $siteId = lc $siteId;
    $siteId = encode('UTF-8', $siteId);


Und ich suche gerade eine Website, die mir den Unterschied zw. utf8 und UTF-8 so erklärt, dass ich ihn auch verstehe ;)[/code]
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 27 April 2021, 12:22:28
Zitat von: Beta-User am 27 April 2021, 11:58:08
Glaube nicht, dass das an dir liegt!

Jedenfalls scheint ein utf8::downgrade() vorab dann die "kleine Küche" via lc zu erzeugen, wenn die Message sauber reinkommt.
Evtl. müssen wir da noch tweaken, und ich hoffe auch sehr, dass das nicht den downgrade kaputt macht....

Funktioniert auch.

Wir haben aber noch ein Mischmasch us utf8 (hash encoding,getRoomName) und UTF-8 (initialize_Language,parseJSONPayload)
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 27 April 2021, 12:34:51
Ja, ist irgendwie unschön.

Ich würde (begründet im Moment leider nur durch Bauchgefühl!) aber die Stellen auf dem "einstellbaren" Encoding lassen, wo es nicht nachweislich zu Problemen kommt. Da das bei getRoom die einzige Stelle ist, wo das problematisch zu sein scheint, würde ich das ausschließlich da belassen, und irgendwie sagt mir auch der downgrade im Moment mehr zu. Letztlich ist das für mich aber black box und geraten...

Hartcodiert würde ich den UTF-8-Parameter jedenfalls nicht stehen lassen, bestenfalls den Verweis auf das allgemein genutzte encoding. Up to you...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 27 April 2021, 14:11:31
Gut, gut. Ich hab da alles auf $cp (oder UTF-8) umgestellt. Konnte bisher keine Probleme feststellen. Außer im Logfile. Warum auch immer.

Wo bist du denn über Unstimmigkeiten gestolpert? Nur damit ich weiß, was ich testen muss.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 27 April 2021, 14:25:36
RHASSPY selbst sah dann in der Detailansicht an der einen oder anderen Stelle "komisch" aus, wenn ein Umlaut da war (da waren die UTF-8-Oktetts (?) zu sehen).
Wenn du das nicht auf die Schnelle nachvollziehen kannst, aber Umlaute drin hast: einfach ignorieren...

(Falls du dann wieder einen konsolidierten gemeinsamen Zwischenstand hast: Bitte wieder nach github (oder ins svn...), nur für den Fall, dass ich noch über was stolpere. Ansonsten werde ich irgendwann noch das mit der Colortemp-"Brücke" testen, denn wenn, kann das Modul jetzt für den Moment das, was es _ aus meiner Warte gesprochen - können sollte - wenn man von "matches in room" absieht. Das ist aber vermutlich ein dickeres Brett bzw. ggf. muss ich auch erst mal testen, ob es überhaupt erforderlich ist, da irgendwas einzuschränken statt schlicht mit dem "Gesamtslot" in einem intent "MakeChoice" zu arbeiten. (Link für später mal: https://community.rhasspy.org/t/add-context-setting-to-intents-easy-building-dialogues-problem-and-solution/2434))
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 27 April 2021, 14:27:24
Gerade in der Sekunde erledigt :). Aktuell ist die "dev".
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 28 April 2021, 07:50:15
So, aktuell läuft :) :

File                            Rev   Last Change 10_RHASSPY.pm                   24343 2021-04-27 13:11:33Z drhirn

Und mit passendem colorTempMap bekomme ich das dusselige MiLight-MQTT2_DEVICE-Ding dann auch endlich wieder aus weiss:
attr Licht_Stehlampe_links rhasspySpecials colorTempMap:0="command Weiss" 85="command Weiss" 100="command Weiss"


Bei der Gelegenheit: Evtl. sollte man in der de-cfg unter "slots" noch was für Colortemp hinterlegen, wobei ich noch nicht sicher bin, ob die drei Varianten in der jetzigen Form gut sind. Bei Leuchtmitteln, die wirklich den gesamten Bereich abdecken, ist es eher so, dass die bei Warmweiss beginnen (2700 Kelvin), dann "normales Tageslichtweiss" auf ca. 3000 Kelvin haben und dann aber "Arbeitsweiss" bis 6500 Kelvin definieren. Dusseligerweise "denkt" der Slider von meinen Hue grade anders herum... Wie dem auch sei, mit "85" für das "mittlere weiss" kann sich das Ergebnis "sehen lassen".
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 28 April 2021, 10:14:45
Hab noch die beiden gefunden. Weiß aber nicht, wo sie her kommen. Passiert mir immer beim Neustart.


2021.04.28 09:05:44.343 1: PERL WARNING: Useless use of private variable in void context at ./FHEM/10_RHASSPY.pm line 1691, <$fh> line 308.
2021.04.28 09:05:44.351 1: PERL WARNING: Use of uninitialized value $old_prefix in string eq at ./FHEM/10_RHASSPY.pm line 412, <$fh> line 308.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 28 April 2021, 10:55:15
Zitat von: drhirn am 28 April 2021, 10:14:45
Hab noch die beiden gefunden. Weiß aber nicht, wo sie her kommen. Passiert mir immer beim Neustart.


2021.04.28 09:05:44.343 1: PERL WARNING: Useless use of private variable in void context at ./FHEM/10_RHASSPY.pm line 1691, <$fh> line 308.
2021.04.28 09:05:44.351 1: PERL WARNING: Use of uninitialized value $old_prefix in string eq at ./FHEM/10_RHASSPY.pm line 412, <$fh> line 308.

Zeile 1691 war ein echter bug, da ist mir vermutlich beim Umbenennen der Funktionen was danebengegangen :o :-[ .
Zeile 412 ist neu durch die Umbenennungs-Orgien für prefix dazugekommen, sollte jetzt auch weg sein.

Ansonsten hat Perlcritics noch ein paar Kleinigkeiten aufgedeckt, die einfach zu beseitigen waren ::) ...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: davedeluxe am 30 April 2021, 08:43:54
Guten Morgen,

mal ne generelle Frage da ich dazu nichts gefunden habe (was nicht bedeutet das es nicht doch irgendwo steht).
Ich habe meine Satelliten wie folgt benannt: satellite-raum
Soweit ich verstehe kann ich z.B. in der Küche sagen: "Licht an" und das Licht in der Küche geht an.
Was muss ich tun, dass das funktioniert da mein satellite ja "satellite-kueche" heißt.

Ich bin bereits auf siteId2room gestoßen, was für mich nach einer Möglichkeit klingt, finde aber keine Dokumentation darüber.

Grüße!
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 30 April 2021, 08:52:40
Also, am einfachsten wäre, du benennst den Satellit in küche um.

siteId2room ist auch eine Möglichkeit. Empfehle ich in dem Fall aber eher nicht.
Ist auf jeden Fall ein eigener "Custom Intent". Dazu müsstest du 99_RHASSPY_Utils_siteId2room.pm aus SVN oder GitHub holen und sie in deinem FHEM-Installationsordner ablegen (Berechtigungen nicht vergessen). Und dann einen rhasspyIntent anlegen: siteId2room=RHASSPY::siteId2room::siteId2room(NAME,DATA)
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 30 April 2021, 09:44:03
Zitat von: drhirn am 30 April 2021, 08:52:40
siteId2room ist auch eine Möglichkeit. Empfehle ich in dem Fall aber eher nicht.
Schließe mich der Empfehlung grundsätzlich an.

Das mit dem Code ist dazu gedacht, das im laufenden Betrieb (einfach und per Sprache) ändern zu können, was klasse ist, wenn man einen "mobilen Satelliten" hat.
Der CustomIntent-Code macht aber nichts anderes, wie ein bestimmtes Reading auf einen neuen Wert zu setzen. Das Modul selbst schaut auch ohne die myUtils-Geschichte nach dem Wert des Readings, man kann das also einfach auf via "setreading" auf den passenden Wert setzen.

Der Code zur Auswertung (und Bildung) des Reading-Namens in RHASSPY sieht wie folgt aus:
1342        my $rreading = makeReadingName("siteId2room_$siteId");
1343        $siteId =~ s{\A([^.]+).*}{$1}xms;
1344        utf8::downgrade($siteId, 1);
1345        $room = ReadingsVal($hash->{NAME}, $rreading, lc $siteId);


Bei "satellite-kueche" müsste also "siteId2room_satellite-kueche" als Readingname passen...

Die Doku zum (myUtils-) Code an sich ist in der dortigen commandref enthalten. Vorschläge zur Verbesserung nehmen wir aber natürlich gerne entgegen, das habe ich erst mal zur Lösung des spezifischen Problems entwickelt...

EDIT: Das mit der Reading-Abfrage wäre btw. auch ein Anknüpfungspunkt, um ganz ohne RHASSPY-Hilfe im laufenden Betrieb den Standort eines Satelliten zu ändern, z.B. anhand der RSSI-Werte einer Bluetooth-Verbindung zu einem oder mehreren BT-Dongles oä..
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 30 April 2021, 11:37:27
 ::) Bitte nicht erschrecken, wenn du das diff machst...

Anbei eine neue, experimentelle (!) Version (also vorerst bitte nicht nach contrib damit...).

Kann sein, dass damit das mit dem Bestätigungsdialog nicht mehr funktioniert und/oder andere schwerwiegende Probleme auftreten, wenn man was "dialogisches" versucht (Rest müsste weiter passen).
Es gibt jetzt drei weitere Intents, von denen einer aktiv geschaltet sein sollte, nämlich "CancelAction". Ich empfehle für diese Version, dazu einen eigenenen Zweig in den sentences aufzumachen, der Inhalt kann derselbe Abbruchsatz sein wie bisher der in "ConfirmAction".

Dieses Aufsplitten hat folgenden Hintergrund:
Künftig brauchen wir das mit dem Abbrechen (und Bestätigen) ggf. von unterschiedlichen Satelliten aus und für unterschiedliche Intents parallel, zumindest war das die "logische Hürde", die sich mir beim Nachdenken über das "welches Räumchen hätten Sie denn gerne" gestolpert bin. Die bisherige "Verwaltung" bestand darin, einfach genau eine Dialog-Option zu "parken", was m.E. das Risiko birgt, dass irgendwann alles durcheinandergeht, wenn mal tatsächlich mehreres gleichzeitig ausgeführt werden soll und dann ggf. ganz komische Dinge passieren, wenn der falsche Code aufgerufen wird...

Daher bin ich jetzt auf die Idee verfallen, einfach den ganzen $data-Inhalt in "custom_intent" wieder auf die Reise zu schicken wie in https://rhasspy-hermes-app.readthedocs.io/en/latest/usage.html#continuing-a-session (https://rhasspy-hermes-app.readthedocs.io/en/latest/usage.html#continuing-a-session) beschrieben und das anzureichern mit den Infos, was in dem Zusammenhang an intents aktiviert bzw. deaktiviert wurde. (Soweit alles klar, oder... ::) ??? ::) )
Vermutlich habe ich dabei auch den Grund gefunden, warum "ConfirmAction" (mit dem kurzen "nein") immer funktioniert hat, obwohl es vermeintlich deaktiviert war: Der Deaktivierungsbefehl ging wohl schlicht an die falsche Adresse :o . Nach ersten Tests ist das jetzt "besser" (wobei ich nicht sicher bin, ob das "Ableiten" der Stille nach "SilentCancellation" nicht allgemein eine gute Idee ist, aber das wäre dann eine andere Diskussion), aber alles in allem ist es schlicht und ergreifend so, dass die ganzen Änderungen so massiv sind, dass ich für's erste schon mal froh wäre, das mit der "simplen" Bestätigung würde wieder funktionieren (ich kann's voraussichtlich frühestens morgen irgendwann testen, bin aber optimistisch, nach meinen erfolglosen Tests noch ein paar Lücken geschlossen zu haben. Testen aber bitte auf einer Test-Installation!).

Für die "welcher Raum"-Abfrage könnte man dann da auch die im ersten Durchgang erkannten Raum- (oder Device-) Optionen mit reinpacken und so feststellen, ob die Wahl zur Frage paßt usw.....

Und weil man ja bei einer entsprechenden Abfrage auch was zur Auswahl anbieten muss, gibt es jetzt nicht nur einen "Hauptnamen" ("alias" im Hash) für jedes Device, sondern auch einen "Haupt-Raum" - nämlich der erste, der in "rooms" zu finden ist (wer mit rhasspyRooms arbeitet, kann das also beeinflussen). Beides ergibt dann wieder je einen slot, damit wir den für die noch deaktivierten weiteren Intents dann schon mal haben.

Vermutlich ist dann der "DialogManager" immer noch zu simpel, weil man "eigentlich" überwachen müsste, für welche Intent-Satellit-Kombi denn grade welcher andere Intent aktiviert ist bzw. deaktiviert werden soll, aber a) ist auch das wieder "nun ja", b) sind die potentiellen Problemfälle tendenziell deutlich weniger und c) bin ich nicht sicher, ob da überhaupt noch eine logische Lücke ist.



ZitatIrgendwie müssen wir die neue siteId in den Slot Rooms bringen
Das mit satellite2room für "Missmatches" habe ich gesehen, bin aber noch nicht sicher, ob es wirklich sinnvoll ist, die Satellitennamen (bzw. Teile davon bei Gruppen?) automatisch den Räumen hinzuzufügen. Ich _vermute_, dahinter steckt in aller Regel ein Konfigurationsproblem, das ggf. durch das "siteId2room"-Reading gelöst werden kann, falls man die Benennung des Satelliten nicht anfassen will. Bin aber grade nicht sicher, ob das für die Timer-Anlage auch gilt.

EDIT: Bisher keine Abstürze, dafür m.E. halbwegs konsistente Datenübergaben an Rhasspy... (Aber kein Dialog.)

EDIT 2: Dialoge laufen jetzt wieder. Fyi: customData hat sich als Problem erwiesen. Wenn man das nutzt, bekommt man mind. an der Handy-App keine Tonausgabe. Die Daten werden daher jetzt wieder intern gepuffert, aber nicht mehr unter einem "Einheitsnamen", sondern unter der Session-ID. Damit sollte nun der Weg frei sein für sowas wie eine "welches Schweinderl..."-Abfrage :) .
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 02 Mai 2021, 09:23:19
Soooo....

Jetzt geht auch das mit der Device-Wahl, wenn es mehrere gibt. Der Haken: Man muss den Intent "treffen".

Erst mal die weiteren sentences:

[de.fhem:ChoiceRoom]
nimm das Gerät aus ( dem | der ) $de.fhem.MainRooms{Room}

[de.fhem:ChoiceDevice]
ich hätte gerne das Gerät $de.fhem.Aliases{Device}

Muss jetzt erst mal noch checken, ob die Choice-Intents wirklich sauber deaktiviert werden, dann könnte man es ggf. auf das Schlagwort reduzieren, aber der Rhasspy-Teil ist immer noch etwas "black box".

Das ganze ist auch etwas "langatmig", von daher wird der eine oder andere das vermutlich (teilweise?) deaktivieren wollen (z.B. begrenzen auf die Raumauswahl). Aber wie war das mit "Rom" und so...?

(und zur Sicherheit CancelAction etc.):
[de.fhem:ConfirmAction]
(ja mach | tu es | ist ok | aber gerne doch){Mode:OK}
(lieber doch nicht ){Mode}

[de.fhem:CancelAction]
(lass es | nein | abbrechen | abbruch ){Mode:Cancel}
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 03 Mai 2021, 08:19:27
Morgen Jörg,

noch nichts getestet bisher. Kam nicht dazu.
Aber eine Frage in Bezug auf deinen Beitrag im Developer-Bereich: Reicht dir die SessionId von Rhasspy nicht als Identifier? Die wird ja durch den ganzen Dialog mitgeschleppt. Sollte zumindest. Und wofür brauchen wir eigentlich die Timer?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 03 Mai 2021, 08:52:05
Zitat von: drhirn am 03 Mai 2021, 08:19:27
noch nichts getestet bisher. Kam nicht dazu.
Kein Ding, hat ja keine Eile.

Bin zwar sehr zufrieden, dass das jetzt "an und für sich" läuft, aber nicht unbedingt mit den "praktischen Ergebnissen" ::) . Beispiel: Im WZ sind  zwei Thermostate und ein Raumfühler vorhanden. Wenn alles sauber läuft, sind die Ist-Temparaturen an den Thermostaten identisch mit dem Raumfühler (es kann kurzzeitige Abweichungen geben). Jetzt wird man aber immer gefragt, welcher es denn sein soll, was in der Konstellation einfach unnötig ist. Denke, es braucht eine Möglichkeit, "prios" zu vergeben, und das vermutlich noch getrennt für "inside" und "outside room"...
(Aber Rom und so)

Zitat
Aber eine Frage in Bezug auf deinen Beitrag im Developer-Bereich: Reicht dir die SessionId von Rhasspy nicht als Identifier? Die wird ja durch den ganzen Dialog mitgeschleppt. Sollte zumindest. Und wofür brauchen wir eigentlich die Timer?
Ja, die SessionId ist ausreichend, und die wird jetzt auch verwendet. Die Timer sind dazu da, dass RHASSPY die Dialoge dann abschließt, wenn zu lange nicht passiert (auch da braucht es vermutlich noch eine Schnittstelle für die Dauer der timeouts, getrennt nach "ja/nein" und "welches Schweinderl...".
Das Problem ist, dass verschiedene Satelliten _gleichzeitig_ Dialoge offen haben können, also muss der Timeout-Funktion bei Ablauf mitgegeben werden, welcher Dialog/welche SessionId eigentlich gerade zu schließen ist.

(Das Problem ist nicht, dass das nicht funktionieren würde, die Frage ist eher die, ob das "clever" gelöst ist, wie es jetzt gelöst ist und ob man die Funktionen ggf. auslagern sollte, damit andere, die _genau_ diese Art Problemstellung auch haben, einfach die betr. Funktionen einbinden können...).
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 03 Mai 2021, 09:05:26
Dann hab ich das eh richtig verstanden mit den Timern. Aber, beendet nicht Rhasspy selbst den Dialog (bzw. die Session), wenn nichts kommt?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 03 Mai 2021, 10:07:30
Zitat von: drhirn am 03 Mai 2021, 09:05:26
Aber, beendet nicht Rhasspy selbst den Dialog (bzw. die Session), wenn nichts kommt?
Hmm, vermutlich...
Allerdings wenn, dann erst nach ziemlich langer Dauer, was mir danach klingt, also wäre es besser bzw. von vornherein eigentlich so gedacht, das auf Seite des Dialog-Partners (also RHASSPY) zu lösen. Kann aber sein, dass das falsch ist (habe aber auch keine Option gesehen, den Timeout für Rhasspy ggf. zu beeinflussen), und es gibt dann auf alle Fälle eine Art Lücke:
Es werden bestimmte Intents ja erst freigeschaltet (bzw. das ist jedenfalls so beabsichtigt), wenn überhaupt passende Fragen bestehen. Wird der Dialog geschlossen (von wem auch immer), sollte das auch wieder auf die Default-Werte. (Im Moment passiert das über den timeout, so dass ggf. dann trotzdem noch irgendwas ausgegeben wird, aber das ist m.E. zumindest im Moment kein echtes Problem).
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 03 Mai 2021, 14:56:11
...vor lauter Analyse des Timer-Codes sind mir dann noch ein paar "kleinere" Unsauberkeiten aufgefallen, die hoffentlich nebenwirkungsfrei beseitigt sind...
(Der Code an sich verschickt jetzt zwar die Daten vermutlich richtig (ich konnte keine "working examples" dazu finden), aber soweit ich das verstanden habe, ist Rhasspy gar nicht in der Lage, z.B. Intents@runtime zu (de-) aktivieren... Kann also sein, dass die jetzige Fassung aus diesem kühnen Grunde nicht optimal ist, v.a., wenn Rhasspy zwischendurch mal trainiert wird ??? .)
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 03 Mai 2021, 16:01:30
Ich hab gerade einen kleinen Punkt für die ToDo-Liste gefunden: Ist ein "genericDevice" z.B. im FHEM-Web-Raum "schlafzimmer->temperatur" ist es das natürlich auch für Rhasspy. Das wird relativ kompliziert mit der Aussprache :D
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 03 Mai 2021, 16:09:06
 :) Das ist aber nur solange ein Problem, wie kein rhasspyRoom gesetzt ist, oder?

Oder ist das ToDo das, den "->" per default durch ein Leerzeichen zu ersetzen? (Wäre auch keine große Sache).
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 03 Mai 2021, 16:13:50
Genau. Lösung ist, einen rhasspyRoom zu setzen.

Ich weiß leider nicht, wie andere die Möglichkeit mit dem -> nützen. Drum kann ich auch nicht sagen, was man am Besten damit tun sollte. Spontan hätte ich eiskalt alles ab -> abgeschnitten. Aber wie gesagt, das täte nur mit meiner Logik funktionieren.
Beim dritten Nachdenken drüber: Lassen wir's, wie's ist.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 03 Mai 2021, 16:50:24
Ich hab jetzt schon das zweite "thermometer", bei dem ich nicht auf Luftfeuchtigkeit abfragen kann. Im "list" sieht das gut aus, aber Matches werden keine gefunden.

         enoTemperaturAussen01:
           alias      temperatur
           groups     aussentemperatur
           names      temperatur
           rooms      draußen
           intents:
             GetNumeric:
               humidity:
                 currentVal humidity
                 type       humidity
               temperature:
                 currentVal temperature
                 type       temperature



2021.05.03 16:46:49 5: RHASSPY: [Rhasspy] Parse (IO: rhasspyMQTT2): Msg: hermes/intent/de.fhem_GetNumeric => {"input": "airHumidity draußen", "intent": {"intentName": "de.fhem:GetNumeric", "confidenceScore": 1.0}, "siteId": "wohnzimmer", "id": null, "slots": [{"entity": "Type", "value": {"kind": "Unknown", "value": "airHumidity"}, "slotName": "Type", "rawValue": "wie hoch ist die luftfeuchtigkeit", "confidence": 1.0, "range": {"start": 0, "end": 11, "rawStart": 0, "rawEnd": 33}}, {"entity": "de.fhem.Room", "value": {"kind": "Unknown", "value": "draußen"}, "slotName": "Room", "rawValue": "draußen", "confidence": 1.0, "range": {"start": 12, "end": 19, "rawStart": 34, "rawEnd": 41}}], "sessionId": "wohnzimmer-porcupine_raspberry-pi-611d2436-64b9-4ea3-9f96-172a7c4aa08c", "customData": "porcupine_raspberry-pi", "asrTokens": [[{"value": "airHumidity", "confidence": 1.0, "rangeStart": 0, "rangeEnd": 11, "time": null}, {"value": "draußen", "confidence": 1.0, "rangeStart": 12, "rangeEnd": 19, "time": null}]], "asrConfidence": 0.99112795, "rawInput": "wie hoch ist die luftfeuchtigkeit draußen", "wakewordId": "porcupine_raspberry-pi", "lang": null}
2021.05.03 16:46:49 5: Parsed value: airHumidity draußen for key: input
2021.05.03 16:46:49 5: Parsed value: airHumidity for key: Type
2021.05.03 16:46:49 5: Parsed value: wohnzimmer for key: siteId
2021.05.03 16:46:49 5: Parsed value: draußen for key: Room
2021.05.03 16:46:49 5: Parsed value: wie hoch ist die luftfeuchtigkeit draußen for key: rawInput
2021.05.03 16:46:49 5: Parsed value: wohnzimmer-porcupine_raspberry-pi-611d2436-64b9-4ea3-9f96-172a7c4aa08c for key: sessionId
2021.05.03 16:46:49 5: Parsed value: GetNumeric for key: intent
2021.05.03 16:46:49 5: Parsed value: 1 for key: probability
2021.05.03 16:46:49 5: handleIntentGetNumeric called
2021.05.03 16:46:49 5: matches in room: , matches outside:
2021.05.03 16:46:49 1: PERL WARNING: Use of uninitialized value $text in concatenation (.) or string at fhem.pl line 1006.
2021.05.03 16:46:49 5:
2021.05.03 16:46:49 5: Response is: Tut mir leid, ich konnte kein passendes Gerät finden


Das hat keinen Zusammenhang mit "humidity" statt "airHumidity", oder?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 03 Mai 2021, 16:57:03
doch, das ist das Problem.

Allerdings bin ich mir im Moment unsicher, wie man die verschiedenen Feuchtigkeiten unterscheiden soll und tendiere dazu, "humidity" mit "airHumidity" gleichzusetzen. Muss aber mal bei Gelegenheit checken, ob das irgendwie durchgängig ist...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 03 Mai 2021, 16:59:59
Ja, würde ich so machen. "airHumidity" klingt eh irgendwie blöd ;D
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 04 Mai 2021, 11:22:38
INFO

Ich habe das GitHub-Repository nach https://github.com/fhem/fhem-rhasspy verschoben.

Das ursprüngliche gibt's zwar noch. Ist aber Read-Only und nur aus sentimentalen Gründen (vorläufig) noch vorhanden. Bitte nicht mehr verwenden.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 06 Mai 2021, 08:23:09
Das mit den Auswahldialogen scheint soweit zu laufen, ein paar "uninitialized" sind mir noch über den Weg gelaufen, und zu den "odd elements" ist mir auch was eingefallen, das zu helfen scheint... Vermutlich gibt's trotzdem noch das eine oder andere, wo man nacharbeiten muss.

Für die Vermeidung von Auswahldialogen gibt's dann auch noch ein "special" ( ::) ) "priority".

"humidity" sollte jetzt überall passen.

Dann müssten wir mal wieder sammeln, ob bzw. was ggf. noch fehlt bzw. Priorität hat. Auf die Schnelle wäre das aus meiner Sicht gDT "scene".

EDIT: Wg. der utf8/UTF-8-Geschichte: Das ist eher Rumprobieren als konsolidierte Erkenntnis; hatte gesehen, dass in einer deiner früheren Versionen mal utf8 als default gesetzt war und selbst mit UTF-8 ein paar Probleme gesehen...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 07 Mai 2021, 11:39:25
Zitat von: Beta-User am 06 Mai 2021, 08:23:09
Dann müssten wir mal wieder sammeln, ob bzw. was ggf. noch fehlt bzw. Priorität hat. Auf die Schnelle wäre das aus meiner Sicht gDT "scene".
...so ruhig hier...?

Habe mal in der Zwischenzeit noch etwas am Thema "scenes" rumgekaut; mir ist klar, dass du das bisher über shortcuts gelöst hast, aber mir schwebte eine eher generische Lösung vor ::) .

Hier also eine Fassung, die "SetScene" als intent kennt :) .
Man kann entweder ein SetScene-mapping in rhasspyMapping erstellen, oder bei gesetztem genericDeviceType (das kann "media" sein oder irgendwas anderes, das bisher bekannt ist), das automatisch erkennen lassen und dann die dazu passenden "Worte" über "specials" einfügen:
defmod Sonos dummy
attr Sonos devStateIcon play:audio_play pause:audio_pause stop:audio_stop next:audio_ff previous:audio_rew
attr Sonos genericDeviceType media
attr Sonos readingList power volume scene
attr Sonos rhasspyGroup Multimedia
attr Sonos rhasspyName Sonos
attr Sonos rhasspyRoom Wohnzimmer
attr Sonos rhasspySpecials scenes:scene2="Kino zu zweit" scene3=none scene1=none scene4=none
attr Sonos room Rhasspy,Wohnzimmer
attr Sonos setList on:noArg off:noArg volumeStraight:slider,-80,1,16 volume:slider,0,1,100 volumeUp volumeDown input:audio1,audio2,audio3,audio4,audio5,av1,av2,airplay,bluetooth,deezer,hdmi1,hdmi2,hdmi3,hdmi4,hdmi5,juke,musiccastlink,netradio,napster,phono,qobuz,server,spotify,tidal,tuner,usb,v-aux mute:on,off,toggle remoteControl:setup,up,down,left,right,return,option,display,tunerPresetUp,tunerPresetDown,enter scene:scene1,scene2,scene3,scene4 straight:on,off 3dCinemaDsp:off,auto adaptiveDrc:off,auto direct:on,off surroundDecoder:dolbypl,dolbypliimovie,dolbypliimusic,dolbypliigame,dolbypliixmovie,dolbypliixmusic,dolbypliixgame,dtsneo:6cinema,dtsneo:6music dsp:hallinmunich,hallinvienna,chamber,cellarclub,theroxytheatre,thebottomline,sports,actiongame,roleplayinggame,musicvideo,standard,spectacle,sci-fi,adventure,drama,monomovie,surrounddecoder,2chstereo,7chstereo enhancer:on,off sleep:off,30min,60min,90min,120min,last bass:slider,-6,0.5,6 treble:slider,-6,0.5,6 partyMode:on,off extraBass:off,auto ypaoVolume:off,auto tunerFrequency displayBrightness:slider,-4,1,0 statusRequest:noArg


Das ganze generiert zwei neue slots, sentences habe ich bisher noch nicht dazu getestet, aber sowas sollte klappen:
[de.fhem:SetScene]
stelle ( der| die | das ) $de.fhem.Device-scene{Device} [( im [Raum] | in der ) $de.fhem.Room){Room}] auf [( [die] Szene | den Modus )] $de.fhem.Scenes [Modus]

Bin mal gespannt auf dein/euer feedback, und allgemein würde mich interessieren, ob und wie das mit den "slots-by-intent" ankommt. Theoretisch sollte es auf dem bei dem SetScene gewählten Weg auch möglich sein, (weitgehend?) unabhängig von gDT zusätzliche slots zu generieren, die jeweils dann nur die Devices beinhalten, die den jeweiligen Intent auch tatsächlich "können".

Praktisch ist es auch nicht wirklich schwierig, siehe Anhang...

EDIT2: Nanu, kein Download bisher?
Da war noch ein kleiner Typo drin, aber jetzt sieht es ganz ok aus. Hier noch mein aktueller  sentence:
[de.fhem:SetScene]
stelle ( den | die | das ) $de.fhem.Device-scene{Device} [ ( im | in der ) $de.fhem.Room{Room} ] auf [ ( die Szene | den Modus ) ] $de.fhem.Scenes [Modus]
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 10 Mai 2021, 11:03:44
Ich war leider unfreiwillig offline die letzten Tage und habe mich daher auf's schöne Wetter konzentriert. Deswegen so ruhig ;)

ZitatMan kann entweder ein SetScene-mapping in rhasspyMapping erstellen
Wie würde das aussehen?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 10 Mai 2021, 11:53:13
...dann mal willkommen zurück in der online-Welt!

(Das schöne Wetter hat meine RHASSPY-Aktivitäten auch etwas gebremst, aber wir sind auch m.E. zwischenzeitlich auf einem Stand, den ich mal als "ziemlich komplett" ansehen würde, s.u.).

attr lampe1 rhasspyMapping SetScene:scene1=Das wäre TV ansehen,scene2=Das wäre was anderes,scene5=und nochmal was anderes

Wie sich das auswirkt, siehst du am besten in einem list vom RHASSPY-Device und dem, was dann an slots dazu erstellt wird. Du bekommst den Text (z.B. "Das wäre TV ansehen") als komplette Elemente in den "Erkennungstext" im slot von Rhasspy (z.B. in "de.fhem.SetScene"), und dann "{Scene:scene1}" zurück, wenn der betreffende Text erkannt wird, und das ganze läßt sich beschränken auf Devices, die "SetScene" überhaupt verarbeiten können.

Was ggf. zur Abrundung noch fehlt, ist "nextScene" bzw. "previousScene", aber da bin ich zum einen noch unsicher, ob das sinnvoll ist und wie es ggf. umzusetzen wäre (bin bei lightScene eher noch Anfänger, und z.B. mein Verstärker kann das nicht orginär).



Insgesamt habe ich den Eindruck, dass das mit den jeweils für bestimmte Kommandos "passenden" Device-slots eine gute Idee war, das paßt jetzt bei meinen Tests sehr viel besser wie früher.




Was auch gut klappt, ist das mit "priority". Konkret läuft das bei mir jetzt so, dass für (Ist-) Temperaturen "outsideRoom" der Außenfühler herangezogen wird, und in den Innenräumen jeweils der "Raumfühler" - was entweder ein (CUL_HM-) Wandthermostat ist oder ein HUEDEvice bzw. MQTT2_DEVICE (das als "virtueller Wandthermostat" auch die Thermostate steuert). Für die Soll-Temperatur wird dann entweder der "echte Raumfühler" herangezogen, oder eben einer der beiden ("geteamten") Thermostate.

"volume" ist dann jeweils der Verstärker, nicht der MPD.

Damit hat sich das mit den Rückfragen auch weitestgehend erledigt...



Bin aber wegend des schönen Wetters auch noch nicht komplett durch mit Testen und Umbauen meiner sentences ;) .
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 10 Mai 2021, 11:59:15
Das mit der Priorität, wie sieht das in der Praxis aus? Könntest du mir das ein Beispiel-Special schreiben bitte?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 10 Mai 2021, 12:37:24
Hier mal die fraglichen 3 (den RT-DN mit prio für desired-temp kann man sich dazudenken)

"fake" Raumfühler, TYPE=MQTT2_DEVICE:
attr Raumfuehler_Wohnzimmer rhasspySpecials priority:inRoom=temperature,humidity
Wand-Thermostat TYPE=CUL_HM:attr Thermostat_EssZi_Climate rhasspySpecials priority:inRoom=desired-temp,temperature,humidity
Außentemperatur etc:
attr MYSENSOR_97 rhasspyMapping GetNumeric:currentVal=temperature2,type=temperature\GetNumeric:currentVal=humidity3,type=humidity
attr MYSENSOR_97 rhasspyName aussenthermometer,thermometer
attr MYSENSOR_97 rhasspyRoom garten,draussen
attr MYSENSOR_97 rhasspySpecials priority:outsideRoom=temperature inRoom=temperature


Ob man inRoom _und_ outsideRoom setzt, ist eine Zweckmäßigkeitsfrage; tendenziell wäre ich zurückhaltend mit "outside".

Generell wäre es ggf. hilfreich, mal einen Wiki-Artikel zu RHASSPY anzufangen, dann kann man das gleich verlinken, wenn es irgenwohin passende Querbezüge gibt?
Z.B. das mit den "MainRooms" und dem "alias" steht bisher auch nirgends, wo es herkommt und was es soll (ist zwar "fast selbsterklärend", aber verkehrt wäre es nicht, auch das mal darzustellen, falls es "bleiben darf"?)...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 19 Mai 2021, 08:33:06
Update nach  der Jagd nach ein paar weiteren "uninitialized"-Meldungen...

Ist sonst grade noch was offen?

Ich bin übrigens im großen und ganzen zufrieden damit, wie das jetzt läuft.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: DrBasch am 19 Mai 2021, 12:20:14
Guten Morgen.

Entschuldigt bitte, dass ich mich hier einklinke... 

;D
Zitat von: Beta-User am 19 Mai 2021, 08:33:06
Update nach  der Jagd nach ein paar weiteren "uninitialized"-Meldungen...

Ist sonst grade noch was offen?

Da Du gerade nach uninitialized-Meldungen fragst... bin eben über eine gestolpert.  ;D

Ich habe jetzt 14 Tage versucht, das Rhasspy-Modul bei mir an den Start zu bringen. Es wollte und wollte einfach nicht funktionieren (d.h. ich konnte kein Dummy o.a. on/off-schalten). Heute bin ich der Sache endlich auf die Spur gekommen.

Nach einer Einrichtung gemäß github/readme bzw. cref konnte ich mit verbose 5 quasi nur Logeintäge vom MQTT2_CLIENT-Device finden. Das RHASSPY-Modul machte sich nur durch ein
"perl warning: use of uninitialized string in ne ... 10_RHASSPY.pm"
bemerkbar.

Das Warning konnte ich auf die Parse-Funktion zurückführen.
sub Parse {
    my $iodev = shift // carp q[No IODev provided!] && return;
    my $msg   = shift // carp q[No message to analyze!] && return;

  ...

    return q{[NEXT]} if !grep( { m{\A$shorttopic}x } @topics);

    my @instances = devspec2array('TYPE=RHASSPY');

    for my $dev (@instances) {
        my $hash = $defs{$dev};
        # Name mit IODev vergleichen
->        next if $ioname ne AttrVal($hash->{NAME}, 'IODev', undef);
        next if IsDisabled( $hash->{NAME} );
        my $topicpart = qq{/$hash->{LANGUAGE}\.$hash->{fhemId}\[._]|hermes/dialogueManager};
        next if $topic !~ m{$topicpart}x;


Das Attribut "IODev" wird offensichtlich im Gegensatz zu Internal bzw. Reading "IODev" nicht automatisch gesetzt. Erst nach händischem setzen des Attributs
"attr Rhasspy IODev mqtt_Rhasspy" konnte ich mit dem RHASSPY-Modul mein switch-dummy schalten.

Ich war so glücklich wie ein junger Vater, dessen Sohn (namens Jarvis) seinen ersten Satz gesprochen hat:
"Sorry but something went not as expected"
... so etwas bleibt einem ein Leben lang in Erinnerung... hab immer noch Tränen in den Augen ;D

Der cref bzw. der github-Doku hab ich nicht entnehmen können, dass ich das Attribut setzen muss.
Sollte man das nicht als wichtigen Hinweis in die Doku aufnehmen (oder es mehr hervorheben, falls ich es schlichtweg überlesen habe) ?
Oder kann man die IODev über ein Internal referenzieren, das ggf. FHEM-neustartübergreifend abhängig vom IODev-Attribut gesetzt wird?

In jedem Fall möchte Euch für die Entwicklung des Moduls danken, das eröffnet uns neue Welten in unserem smart home-Universum.

Mögen die Spiele beginnen!
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 19 Mai 2021, 13:00:24
Zitat von: Beta-User am 19 Mai 2021, 08:33:06
Update nach  der Jagd nach ein paar weiteren "uninitialized"-Meldungen...
Danke!

Zitat
Ist sonst grade noch was offen?
Bei mir nicht. Ich muss aber gestehen, ich mache derzeit gar nichts mit Rhasspy. Zu viele andere Sachen um die Ohren. Ich hör dem Ding nur zu, wie es sich mit meinem TV unterhält. Ansprachen von mir werden ja in der Regel leider ignoriert. ;)
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 19 Mai 2021, 13:06:43
Zitat von: DrBasch am 19 Mai 2021, 12:20:14
Guten Morgen.

Entschuldigt bitte, dass ich mich hier einklinke... 
Kein Problem, gerne!

Zitat

        # Name mit IODev vergleichen
->        next if $ioname ne AttrVal($hash->{NAME}, 'IODev', undef);


Das Attribut "IODev" wird offensichtlich im Gegensatz zu Internal bzw. Reading "IODev" nicht automatisch gesetzt. Erst nach händischem setzen des Attributs [...]
...irgendwie hatte ich schon darauf gewartet, dass mir die jüngsten Änderungen rund um AssignIOPort vor die Füße fallen:
Zitat von: rudolfkoenig am 02 Mai 2021, 20:16:20
Wenn man im Modul auf das Vorhandensein des IODev Attributes prueft, dann kann das zu Problemen fuehren.
Ich bin der Meinung, dass das nicht notwendig ist, das Modul soll (wenn ueberhaupt!) nur das IODev Internal anfassen.
Eigentlich sollte die Kommunikation zwischen den beiden Modulen ueber IOWrite() bzw Dispatch laufen.
Das "Problem" hier (und bei MQTT_GENERIC_BRIDGE) ist aber etwas anders gelagert wie bei den Funk-IO's, bei denen es zu _anders gelagerten_ Doppelungen usw. kommen kann; muss ich mir ansehen, wie man das am besten löst.

Bisher war es (jedenfalls in meiner Erinnerung) so, dass IODev als Attribut automatisch immer gesetzt wurde (und meinem Bauchgefühl nach _hier_ (!) auch weiter gesetzt werden sollte). Muss mal ein paar Tests machen...

Zitat
Oder kann man die IODev über ein Internal referenzieren, das ggf. FHEM-neustartübergreifend abhängig vom IODev-Attribut gesetzt wird?
Ist das Attribut gesetzt, wird das Internal auch entsprechend angelegt; das "Problem" ist, dass das Internal einen Neustart nicht überlebt, und AssignIOPort (soweit ich mich entsinne) immer das _letzte_ passende IO in der cfg heranzieht, und daraus dann eben neuerdings kein Attribut mehr macht, sondern (auch) ein _Reading_ (das dann auch (saubere) Neustarts überlebt)...

Diese Kaskade könnte auf die Schnelle so aussehen:
next if $ioname ne AttrVal($hash->{NAME}, 'IODev', ReadingsVal($hash->{NAME}, 'IODev', InternalVal($hash->{NAME}, 'IODev', 'none')));
Bin aber nicht sicher, ob das schon alles war, weil auch das bezogene IOWrite() muss ja auch auf das "richtige" IODev verweisen...

ZitatSollte man das nicht als wichtigen Hinweis in die Doku aufnehmen (oder es mehr hervorheben, falls ich es schlichtweg überlesen habe) ?
Sollte man wohl, es war nur bis eben gar nicht als Problem bekannt ;) .

ZitatIn jedem Fall möchte Euch für die Entwicklung des Moduls danken, das eröffnet uns neue Welten in unserem smart home-Universum.
(Von meiner Seite:) Gerne!

War für mich auch eine sehr hilfreiche Erweiterung :) .
Zitat
Mögen die Spiele beginnen!
Dann mal viel Spaß - und ruhig weiter Fragen stellen, wenn was unklar ist bzw. (v.a.) die cref verbessert werden kann!

Zitat von: drhirn am 19 Mai 2021, 13:00:24
Bei mir nicht. Ich muss aber gestehen, ich mache derzeit gar nichts mit Rhasspy. Zu viele andere Sachen um die Ohren. Ich hör dem Ding nur zu, wie es sich mit meinem TV unterhält. Ansprachen von mir werden ja in der Regel leider ignoriert. ;)
;D
Wenn man das Handy zückt, um mit dem "Knopf" die App zu aktivieren, klappen Anweisungen in der Regel sogar bei lauter Musik im Hintergrund... :P
(Man muss die App aber gelegentlich neu starten, irgendwie verliert sie gelegentlich die Verbindung).
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 19 Mai 2021, 13:07:52
Zitat von: DrBasch am 19 Mai 2021, 12:20:14
Das Attribut "IODev" wird offensichtlich im Gegensatz zu Internal bzw. Reading "IODev" nicht automatisch gesetzt. Erst nach händischem setzen des Attributs
"attr Rhasspy IODev mqtt_Rhasspy" konnte ich mit dem RHASSPY-Modul mein switch-dummy schalten.

Das hat mich jetzt doch schwer gewundert, weil das bei mir immer automatisch gesetzt wurde. Und wird. Hab ich gerade ausprobiert.

Es wird aber nicht automatisch gesetzt, wenn clientOrder im MQTT2_CLIENT nicht richtig gesetzt ist habe ich gerade herausgefunden.

Wie dem auch sei, in der aktuellen dev-Version gibt's sowohl in CRef, als auch README einen Hinweis auf Kontrolle des Attributs.

Danke für den Hinweis!
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: DrBasch am 20 Mai 2021, 01:26:16
Zitat von: Beta-User am 19 Mai 2021, 13:06:43

Ist das Attribut gesetzt, wird das Internal auch entsprechend angelegt; das "Problem" ist, dass das Internal einen Neustart nicht überlebt, und AssignIOPort (soweit ich mich entsinne) immer das _letzte_ passende IO in der cfg heranzieht, und daraus dann eben neuerdings kein Attribut mehr macht, sondern (auch) ein _Reading_ (das dann auch (saubere) Neustarts überlebt)...

Diese Kaskade könnte auf die Schnelle so aussehen:
next if $ioname ne AttrVal($hash->{NAME}, 'IODev', ReadingsVal($hash->{NAME}, 'IODev', InternalVal($hash->{NAME}, 'IODev', 'none')));
Bin aber nicht sicher, ob das schon alles war, weil auch das bezogene IOWrite() muss ja auch auf das "richtige" IODev verweisen...

Wow  :D... Danke für die Erklärung... AssignIOPort u. IOWrite Begriffe, mit denen ich mich noch nicht auseinandersetzen musste... ich glaube aber prinzipiell verstanden zu haben worum es geht.
Vor allem aber hast Du mir bewußt gemacht, dass _Readings_ Neustarts überstehen können... Die Sache mit der fhem.save hab ich zwar irgendwann schonmal gelesen, aber mangels praktischem Bezug nicht verinnerlicht...


Zitat von: drhirn am 19 Mai 2021, 13:07:52
Das hat mich jetzt doch schwer gewundert, weil das bei mir immer automatisch gesetzt wurde. Und wird. Hab ich gerade ausprobiert.

Es wird aber nicht automatisch gesetzt, wenn clientOrder im MQTT2_CLIENT nicht richtig gesetzt ist habe ich gerade herausgefunden.

clientOrder war bei mir auf "RHASSPY" gesetzt; ohne MQTT_GENERIC_BRIDGE bzw. MQTT2_DEVICE. MQTT läuft hier z.Zt. ja ausschließlich für Rhasspy.


Da das Testsystem noch lief, konnte ich zwei Versuchsreihen durchlaufen lassen. Einmal mit Modulversion 0.4.12 und einmal 0.4.14:

- Bestehende Devices MQTT2_CLIENT und RHASSPY gelöscht und fhem.cfg gespeichert.

- Module /opt/fhem/FHEM kopiert und FHEM neu gestartet. Zuerst 0.4.12 im zweiten Durchlauf 0.4.14.

- MQTT2_CLIENT-Device und RHASSPY-Device anlegen.
define mqtt2_Rhasspy MQTT2_CLIENT 127.0.0.1:12183
attr mqtt2_Rhasspy clientOrder RHASSPY MQTT_GENERIC_BRIDGE MQTT2_DEVICE
attr mqtt2_Rhasspy subscriptions hermes/intent/+ hermes/dialogueManager/sessionStarted hermes/dialogueManager/sessionEnded
define Rhasspy RHASSPY
save



Ergebnis mit Modul 0.4.12:
Internals:
   CFGFN     
   FUUID      60a50bf9-f33f-a4a6-7a4a-342599eafb9e3309
   IODev      mqtt2_Rhasspy
   LANGUAGE   de
   MODULE_VERSION 0.4.12
   NAME       Rhasspy
   NR         42
   STATE      ???
   TYPE       RHASSPY
   baseUrl    http://127.0.0.1:12101
   defaultRoom default
   devspec    room=Rhasspy
   encoding   UTF-8
   fhemId     fhem
   prefix     rhasspy
   useGenericAttrs 1
   READINGS:
     2021-05-19 15:00:41   IODev           mqtt2_Rhasspy
   helper:
     lng:
       responses:
         DefaultCancelConfirmation Thanks aborted
...
         unitSeconds:
           0          seconds
           1          one second
Attributes:


Ergebnis mit Modul 0.4.14:
Internals:
   CFGFN     
   FUUID      60a510a6-f33f-a4a6-7983-6c267ef3f15a44b3
   IODev      mqtt2_Rhasspy
   LANGUAGE   de
   MODULE_VERSION 0.4.14
   NAME       Rhasspy
   NR         24
   STATE      ???
   TYPE       RHASSPY
   baseUrl    http://127.0.0.1:12101
   defaultRoom default
   devspec    room=Rhasspy
   encoding   utf8
   fhemId     fhem
   prefix     rhasspy
   useGenericAttrs 1
   READINGS:
     2021-05-19 15:20:38   IODev           mqtt2_Rhasspy
   helper:
     lng:
       responses:
         DefaultCancelConfirmation Thanks aborted
         ...
         unitSeconds:
           0          seconds
           1          one second
Attributes:


Keine der beiden Modulversionen legt bei mir automatisch Attribute an. Irgendetwas scheint unsere Systeme zu unterscheiden. Ich würde gerne verstehen, was den Unterschied ausmacht, und ob mir das - bei anderen Modulen, in vergleichbare Situationen - erneut um die Ohren fliegt  :-\. Ich muss noch für die Sommerferien ein DIY-Bewässerungssystem für unsere Kübelpflanzen bauen... das wollte ich eigentlich per MQTT steuern.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: DrBasch am 20 Mai 2021, 02:11:10
Zitat von: Beta-User am 19 Mai 2021, 13:06:43
Dann mal viel Spaß - und ruhig weiter Fragen stellen, wenn was unklar ist bzw. (v.a.) die cref verbessert werden kann!


Das Angebot nutze ich gleich nochmal schamlos aus... ;D

1. Beim Anlegen des RHASSPY-Devices hab ich mich das ein oder andere mal vertippt. Ich schrieb z.B.
"define Rhasspy RHASSPY ... devspe=genericDeviceType=.+" 
anstatt
"define Rhasspy RHASSPY ...devspec=...".

Dann hat das Modul -nachvollziehbar- den devspec-default "room=Rhasspy" übernommen. Das fiel mir dann aber erst sehr viel später auf.
Ein anders Mal schrieb ich "baseURL" anstatt "baseUrl". Der Fehler hat sich wiederum sehr schnell bemerkbar gemacht.

Syntaxfehler werden somit zwar irgendwie abgefangen, aber dem Anwender nicht aktiv rückgemeldet, z.B. durch einen Log-Eintrag "define <Devicename> with an unknown argument 'devspe=genericDeviceType=.+', please check Internals manually").
Ich habe keine Ahnung, wie aufwänding es wäre eine Syntaxprüfung zu implementieren - mit parseParameters hab ich mich noch nicht auseinandergesetzt. Eine solche Erweiterung der Rhasspy_DefFn wäre in meinen Augen nett, ist aber definitiv nichts was als zwingend oder dringlich priorisiert werden müsste... eher etwas für langweilige, verregnete Tage mit miesem TV-Programm wenn die Frau/Freundin/Familie die Schwiegereltern besucht  ;)

2. Ich habe bis jetzt nur ein Dummy-Device angelegt, dass sprachgesteuert on/off geschaltet werden sollte. 
Nach einem "set Rhasspy update devicemap/slots/all" finde ich im Rhasspy-Webinterface slots wie z.B. "de.fhem.Device", "de.fhem.Room", "de.fhem.AllKeywords" mit den jeweils korrekten values ("lampe", "wohnzimmer").
Jedesmal wurde auch ein Sentence-File "intents/de.fhem.Shortcuts.ini" mit dem (leeren) intent "[de.fhem:Shortcuts]" angelegt.

Was ich vermisst habe, war ein automatisches Anlegen von z.B. "[de.fhem:SetOnOff]", insbes. dann, wenn ich mit attr rhasspyMapping SetOnOff:cmdOn=on,cmdOff=off" die beabsichtigten intentions vorgegeben habe.
Bei meinem allerersten Einrichtungsversuch war mir nämlich nicht klar, wie und wo ich die sentences eingeben muß ("sentence.ini"? "intents/de.fhem.Shortcuts.ini"? Ganz wo anders?). Nachdem ich dann auf Youtube den FHEM-Monatsrückblick geschaut habe und einen kurzen Blick auf Eure Rhasspy Konfiguration erhaschen konnte bin ich nachfolgend dazu übergegangen für jede intention eine eigene .ini anzulegen. Ist dieses Vorgehen okay, oder kann/sollte man besser alle intentions einfach in die sentence.ini kloppen?

3. Das gettingstarted von cb2sela https://github.com/cb2sela/fhem-rhasspy-gettingstarted (https://github.com/cb2sela/fhem-rhasspy-gettingstarted) ist mE in Bezug auf den derzeitigen Enwicklungsstand eures Moduls outdated.

ZitatIn FHEM folgendes angelegt:

define RhasspyMQTT MQTT [ip_des_rhasspy]:12183
define Rhasspy RHASSPY RhasspyMQTT Wohnzimmer
attr RhasspyMQTT room Rhasspy
attr RhasspyMQTT rhasspyRoom Wohnzimmer
attr Rhasspy room Rhasspy
attr Rhasspy rhasspyRoom Wohnzimmer
Funktioniert das Rhasspy-Modul denn noch mit MQTT? Ich hatte es so verstanden, dass man MQTT2_CLIENT oder MQTT2_SERVER benötigt.

last but not least... okay, jetzt wird es kleinkariert...:
4. Im Github readme wird unter "Attributes (ATTR)" noch (das alte) "configFile" anstelle von "languageFile" erklärt.


Bitte kriegt nicht den Eindruck ich würde nur meckern wollen...
Ich bin wirklich, wirklich dankbar für das Modul, euer Engagement und eure Bereitschaft auf die Anwender einzugehen.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 20 Mai 2021, 08:29:28
Anbei dann erst mal eine Version, die die uninitialized-Warnung bei nicht gesetztem IODev-Attribut vermeidet und dann auf Reading/Internal zurückgreift - samt entsprechender Anpassung der cref. Bin auch noch nicht ganz durch, aber mAn. wird das Attribut künftig nicht mehr automatisch gesetzt.

OT-Anmerkung dazu: Das ist vermutlich in allen den Fällen kein Problem, in denen es sowieso nur eine lose Verbindung zwischen IO und Information gibt (wie bei den meisten Funklösungen, bei denen dann fhem.pl Duplikate vorrab aussortiert).
In allen Fällen, in denen es sein kann, dass - vermeintlich - identische Information über unterschiedliche IO's reinkommen kann (vornehmlich MQTT, aber auch MySensors!), muss die Koppelung zwischen IO und Client-Modul im zweistufigen Modulkonzept aber "gehärtet" werden, was bei MySensors z.B. schon länger dadurch erfolgt, dass da das Attribut durch das Modul gesetzt wird, statt auf AssignIOPort zu vertrauen...

Anders gesagt: Wenn (und solange) man z.B. auch bei MQTT_GENERIC_BRIDGE das Attribut gesetzt hat, ist alles fein...

Für die Zukunft wird es vermutlich auch dort (und bei MQTT2_DEVICE?) eine Ergänzung brauchen, die das klarstellt.
[/OT]

Zitat von: DrBasch am 20 Mai 2021, 02:11:10
Das Angebot nutze ich gleich nochmal schamlos aus... ;D
Gerne!

Ad 1.: Guter Vorschlag, hab's auf die ToDo genommen. Vermutlich wird sich das aber "nur" darauf beschränken müssen, das auf korrekte Schreibweise der "Schlüsselworte" (und evtl. die Zahl der unbenannten Parameter) zu checken.
(OT: das ist nicht wirklich ein originäres parseParams-Problem, das hilft nur, die Optionen selektiv setzen zu können [/OT]).

Ad. 2.
a) Weiß nicht, ob wir den "automatisiert erstellten" OnOff-Slot (via rhasspy-de.cfg) bereits implementiert haben bzw. das schon im svn ist. Machbar wäre es jedenfalls dafür zu sorgen, dass erst mal jeder ein relativ schnelles "hello world" zustande bringen kann, ohne sich (bis dahin)  intensiver mit der Rhasspy-Seite auseinandersetzen zu müssen.
b) das mit den leeren Shortcuts ist auf der ToDo-Liste, sollte sich ohne größere Aufwände vermeiden lassen.
c) Für jeden Intent eine eigene ini anzulegen erscheint mir sinnvoll. Ist zwar im ersten Moment unübersichtlicher, aber bei Überarbeitungen deutlich weniger fehleranfällig.

ad 3 und 4.:
Die aktuellste Doku ist die cref, da steht eindeutig: MQTT2-IO, empfohlen: M2C, alle andere Doku in den Untiefen des INet ist veraltet ::) .

Das git-HowTo war - soweit ich das beurteilen kann - eine (gute!) Art Notlösung, weil es keinen anderen praxistauglichen Ort gab. Es hat sich nur "leider" sehr viel geändert, auch, was die Frage der Herangehensweise bei der Einrichtung angeht usw.. Von daher wäre es m.E. an der Zeit,
a) die cref auf "Tauglichkeit" (im Sinne einer knappen manpage) zu checken, ob da alles wesentliche drin steht, was man braucht, und
b) einen (deutschen) Guide zu erstellen, der das wesentliche enthält. Die md im (fhem-) git deckt vieles ab, aber noch nicht alles aus der aktuellen dev-Version (und ist auch englisch).

Meine persönliche Vorstellung wäre:
- Ziel für den Guide wäre das FHEM-Wiki;
(- parallel cref im Auge behalten/überarbeiten, wo erforderlich)
- Basis die aktuelle dev-version
- Startpunkt für die Einrichtung von Geräten wäre - soweit das möglich ist - jeweils genericDeviceType zu setzen.

Unsere Probleme dabei:
- drhirn und andere, die die Vorversionen schon im Einsatz hatten, haben ihre Systeme "nach guter alter Väter Sitte" konfiguriert und "fremdeln" (noch) etwas mit dem gDT-Ansatz (was auch völlig ok ist, denn wir hatten ja auf (weitgehende) Kompabilität geachtet). Da besteht jetzt aber keine Veranlassung, am laufenden System was zu ändern, daher ist die Testintensität nicht wirklich hoch (genauer gesagt: mir liegt außer den eigenen Erfahrungen praktisch keine Rückmeldung dazu vor);
- "wir" sind etwas betriebsblind, was es immer schwierig macht, einen "einsteigerfreundlichen" Wiki-Artikel zu verfassen

Zitat
Bitte kriegt nicht den Eindruck ich würde nur meckern wollen...
Bei mir ist das als konstruktive Kritik angekommen. Du brauchst dich für Fragen nicht zu rechtfertigen, _noch_ ist die Doku nicht so, dass man dir ein rtfm um die Ohren hauen dürfte ;D .

Meine Bitte bzw. mein Vorschlag:
Wir brauchen (wieder) jemanden wie cb2sela, der hilft, eine passende (de-) Doku zu verfassen und die verbleibenden Lücken in der Doku, in der cref, in der rhasspy-de.cfg aufzuspüren, (uninitialized-warnings zu jagen) und ggf. mal ausführlichere Rückmeldung zum "gDT-Way" gibt.

Evtl. wäre es auch "Zeit", den "alten" Thread zu schließen (ähnlich, wie das mit den verschiedenen Versionen bei AutoShuttersControl der Fall war), um zu zeigen, dass der korrekte Startpunkt nicht mehr der 1. Threadbeitrag ist?

Wenn die Doku (halbwegs) fertig ist und die aktuelle dev-Version keine größeren Schwächen mehr zeitigt, wäre ggf. dann der Zeitpunkt gekommen, das ganze dann auch "scharf" zu schalten, also das Modul in den regulären update-Zyklus aufzunehmen (wir sollten aber ggf. wissen, wer von den 10 (in statistics) "gemeldeten" Installationen schon auf dem MQTT2_CLIENT-IO ist, damit wir nicht versehentlich/unangekündigt jemanden "abschießen").

@drhirn: Deine Meinung dazu?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 20 Mai 2021, 10:14:06
Ich sag's euch ganz ehrlich: In Österreich hat gestern nach einem halben Jahr endlich die Gastronomie wieder aufgesperrt. Ich kann daher erst sinnvoll antworten, wenn mein Hirn wieder richtig funktioniert. ;D

Zitat von: DrBasch am 20 Mai 2021, 02:11:10
Bitte kriegt nicht den Eindruck ich würde nur meckern wollen...
Hab das nicht als meckern empfunden. Sehr hilfreiche Anmerkungen bisher.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 20 Mai 2021, 10:33:16
Glückwunsch zur "neuen" alten Freiheit!
"Genieße es" :P ...



Anbei dann gleich der Versuch, Fehleingaben in der DEF sinnvoll zurückzumelden (angetestet) und das automatische Erstellen des Shortcut-Slots zu verhindern (ungetestet, aber optimistisch).
(Für sowas braucht man kaum länger als eine Frühstückspause ::) ).
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: DrBasch am 20 Mai 2021, 14:15:35
Zitat von: Beta-User am 20 Mai 2021, 08:29:28
Anbei dann erst mal eine Version, die die uninitialized-Warnung bei nicht gesetztem IODev-Attribut vermeidet und dann auf Reading/Internal zurückgreift - samt entsprechender Anpassung der cref. Bin auch noch nicht ganz durch, aber mAn. wird das Attribut künftig nicht mehr automatisch gesetzt.
Mann, bist Du schnell... :o

Zitat von: Beta-User am 20 Mai 2021, 08:29:28
Vermutlich wird sich das aber "nur" darauf beschränken müssen, das auf korrekte Schreibweise der "Schlüsselworte" (und evtl. die Zahl der unbenannten Parameter) zu checken.
Mehr als eine Testung der Schlüsselwortsyntax hatte ich mir auch nicht vorgestellt. Die Werte, die zugewiesen werden, hat mE jeder Anwender selbst zu verantworten. Eine Prüfung, ob der mit baseUrl übergebene String eine valide URL ist wäre natürlich ein Träumchen.
Was die Zahl der unbenannten Parameter helfen soll verstehe ich ehrlich gesagt gerade nicht... Wenn man es aber auf die Spitze treiben will, könnte man noch noch auf Duplikate testen.

Zitat von: Beta-User am 20 Mai 2021, 08:29:28
a) Weiß nicht, ob wir den "automatisiert erstellten" OnOff-Slot (via rhasspy-de.cfg) bereits implementiert haben bzw. das schon im svn ist. Machbar wäre es jedenfalls dafür zu sorgen, dass erst mal jeder ein relativ schnelles "hello world" zustande bringen kann, ohne sich (bis dahin)  intensiver mit der Rhasspy-Seite auseinandersetzen zu müssen.
b) das mit den leeren Shortcuts ist auf der ToDo-Liste, sollte sich ohne größere Aufwände vermeiden lassen.
c) Für jeden Intent eine eigene ini anzulegen erscheint mir sinnvoll. Ist zwar im ersten Moment unübersichtlicher, aber bei Überarbeitungen deutlich weniger fehleranfällig.
Asche auf mein Haupt! die rhasspy-de.cfg hab ich mir ehrlich gesagt noch garnicht angeschaut.
Für mich war es einerseits gut, die leeren Shortcuts zu sehen ("It works!"). Andererseits hat es mich irritiert, weil wie gesagt keine sentences eingetragen wurden  ("It works... maybe?... partialliy?").
Spontan könnte ich mir auch vorstellen, dass man die Shortcuts.ini mit einer (sehr kurzen) "burn after reading" Einweisung füllt.

Zitat von: Beta-User am 20 Mai 2021, 08:29:28
Meine Bitte bzw. mein Vorschlag:
Wir brauchen (wieder) jemanden wie cb2sela, der hilft, eine passende (de-) Doku zu verfassen und die verbleibenden Lücken in der Doku, in der cref, in der rhasspy-de.cfg aufzuspüren, (uninitialized-warnings zu jagen) und ggf. mal ausführlichere Rückmeldung zum "gDT-Way" gibt.
Ich werde heute Nacht mal anfangen meine Erfahrungen im Hinblick auf die Rhasspy Einrichtung - im Sinne einer Step-By-Step-Anleitung - zusammenschreiben. Ich muss ja sowieso noch vom Test- aufs Produktivsystem portieren und nochmal alles durchgehen. Wenn es dann dort läuft, fängt die eigentliche Konfiguration dann ja erst richtig an und ich werde mich intensiver mit der Doku und dem "FHEM und Rhasspy"-Thread auseinandersetzen müssen... will sagen: Ihr hört von mir :P
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 20 Mai 2021, 14:48:07
Zitat von: DrBasch am 20 Mai 2021, 14:15:35
Mehr als eine Testung der Schlüsselwortsyntax hatte ich mir auch nicht vorgestellt. Die Werte, die zugewiesen werden, hat mE jeder Anwender selbst zu verantworten. Eine Prüfung, ob der mit baseUrl übergebene String eine valide URL ist wäre natürlich ein Träumchen.
Die "Quittung" für falsche Parameter bekommt man eben durch "geht nicht" bzw. "offline", wenn es die URL ist. Ein bißchen Mitdenken darf dann der User auch :P .

Zitat
Was die Zahl der unbenannten Parameter helfen soll verstehe ich ehrlich gesagt gerade nicht... Wenn man es aber auf die Spitze treiben will, könnte man noch noch auf Duplikate testen.
Wenn mehr als TYPE und NAME angegeben sind, liegt der Verdacht nahe, dass es zu viele sind, und ab 4 liegt sicher ein Fehler vor, aber
ZitatEin bißchen Mitdenken darf dann der User auch
Solche Fehler führen aber in der Regel nicht zu schwerwiegenden Problemen, daher würde ich für meinen Teil sagen: lassen wir es an der Stelle gut sein...

Zitat
Asche auf mein Haupt! die rhasspy-de.cfg hab ich mir ehrlich gesagt noch garnicht angeschaut.
Nevermind; es ist halt doch ein "größeres Puzzle", bei dem man typischerweise nicht alle Teile gleich beim ersten Anlauf findet und korrekt hinlegt. Ist in der Regel kein dauerhaftes Thema, weil (noch) die wenigsten mit englisch zufrieden sind ;D ...

Zitat
Für mich war es einerseits gut, die leeren Shortcuts zu sehen ("It works!"). Andererseits hat es mich irritiert, weil wie gesagt keine sentences eingetragen wurden  ("It works... maybe?... partialliy?").
Das "it works"-Gefühl sollte sich schon dadurch einstellen, dass einige slots erstellt werden (mit den letzten Versionen dann nochmal deutlich mehr, als bei den vorherigen Fassungen). Aber ein leeres und unfunktionales Shortcut.ini ist nicht gut und eine unbeabsichtige Nebenwirkung meiner in Code gegossener These, dass filigranere slots "gut" wären und lieber auch leere erstellt werden sollten (damit Rhasspy nicht von vornherein meckert, weil bestimmte Variablen aus den (noch nicht vorhandenen Muster-) sentences.ini nicht vorhanden sind).

Zitat
Spontan könnte ich mir auch vorstellen, dass man die Shortcuts.ini mit einer (sehr kurzen) "burn after reading" Einweisung füllt.
Da Rhasspy das dann irgendwie zu verarbeiten versuchen würde und dann ggf. wieder versuchen, daraus MQTT-Payload zu generieren, ist das meinem Bauchgefühl nach keine gute Idee. Da Shortcuts ansonsten "autonom" ist, ist es hier egal, ob das nun erstellt wird oder nicht => raus damit...

Zitat
Ich werde heute Nacht mal anfangen meine Erfahrungen im Hinblick auf die Rhasspy Einrichtung - im Sinne einer Step-By-Step-Anleitung - zusammenschreiben. Ich muss ja sowieso noch vom Test- aufs Produktivsystem portieren und nochmal alles durchgehen. Wenn es dann dort läuft, fängt die eigentliche Konfiguration dann ja erst richtig an und ich werde mich intensiver mit der Doku und dem "FHEM und Rhasspy"-Thread auseinandersetzen müssen... will sagen: Ihr hört von mir :P
Das mit dem Zusammenschreiben finde ich klasse, das mit dem Thread eher weniger.
"Mein" gedankliches Poblem: Da stehen ein paar Lösungen drin, die mAn. schon wieder "outdated" sind (aber ggf. weiter funktionieren!). Wenn wir eine "zeitgemäße" Anleitung haben wollen, wäre der Versuch (im Sinne aller Nachkommenden gedacht) hilfreicher, das _nur mit commandref_ und ggf. einem neuen Fragethread zu lösen. Wo es noch paßt, kann man dann ja direkt zu den betreffenden einzelnen Beiträgen/Abschnitten innerhalb des "Monsterthreads" verweisen.
Mehr Aufwand (v.a. für dich), aber ggf. hilfreich bzgl. der "alten Zöpfe". Dafür mit "Individualbetreuung"...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: DrBasch am 21 Mai 2021, 02:19:07
Zitat von: Beta-User am 20 Mai 2021, 14:48:07
Wenn mehr als TYPE und NAME angegeben sind, liegt der Verdacht nahe, dass es zu viele sind, und ab 4 liegt sicher ein Fehler vor, ...
Das möchte ich gerade verstehen, tu mich aber noch etwas schwer damit...Meinst du mit TYPE/NAME z.B. "define ... baseUrl[TYPE]=127.0.0.1:12101[NAME]?

Zitat
Das mit dem Zusammenschreiben finde ich klasse, das mit dem Thread eher weniger.
"Mein" gedankliches Poblem: Da stehen ein paar Lösungen drin, die mAn. schon wieder "outdated" sind (aber ggf. weiter funktionieren!).
Wenn wir eine "zeitgemäße" Anleitung haben wollen, wäre der Versuch (im Sinne aller Nachkommenden gedacht) hilfreicher, das _nur mit commandref_ und ggf. einem neuen Fragethread zu lösen. Wo es noch paßt, kann man dann ja direkt zu den betreffenden einzelnen Beiträgen/Abschnitten innerhalb des "Monsterthreads" verweisen.
Je mehr ich darüber nachdenke, umso mehr muss ich Dir Recht geben. Qualität vor Quantität!

Ich habe im Übrigen angefangen, meinen Installationsweg zu dokumentieren, musste aber von der Idee abrücken, das im Rahmen des Umzugs auf mein Haupt-FHEM zu machen... Ich habe also den Test-RasPi neu aufgesetzt und protokolliere nochmal stoisch alle Schritte mit. Bin jetzt mit der Rhasspy Einrichtung durch und würde dann morgen Abend mit der RHASSPY-Einrichtung weitermachen. Am WE kann ich dann hoffentlich das Protokoll gliedern und in eine lesbare Form formatieren.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 21 Mai 2021, 05:41:40
Zitat von: DrBasch am 21 Mai 2021, 02:19:07
Je mehr ich darüber nachdenke, [...]
:) Dann mal willkommen an Bord!

Du solltest dann möglichst die letzte hier verfügbare Fassung im Einsatz haben (und die zugehörige rhasspy-de.cfg).
@drhirn: spricht was dagegen, die im svn einzuchecken?

Zitat
Bin jetzt mit der Rhasspy Einrichtung durch
Habe mir das Einrichtungs-git auch nochmal angesehen:
- Zu docker kann ich nichts beitragen, das dürfte aber aktuell sein (ich habe den debian-Weg genommen, siehe meinen gesonderten Thread dazu; heißt aber ausdrücklich nicht, dass das "besser" wäre, sondern nur, dass mir dieser Weg näher lag/sympatischer war!).
- an der sentences.ini sollte man m.E. nicht direkt rumschrauben. "Zu meiner Zeit" hat direkt der vorhandene "Wie spät ist es"-Satz genügt, um von FHEM eine Antwort zu erhalten, jetzt muss man m.E. den intent anfassen und ein "de.fhem:" davorsetzen (bei ensprechender language/fhemId).
MAn. wäre das das "geschicktere" "hello world 1"-Erlebnis...

Hat nämlich zwei Vorteile:
- man braucht keine Hardware und keine dummy (s.u.)
- man bekommt (hoffentlich) direkt nach der RHASSPY-Einrichtung eine Antwort - allerdings in schönstem "denglish" und ist damit gleich beim nächsten Thema, nämlich der language-file...

Dein "Erstling" mit dummy hatte m.E. zwei Nachteile:
- Es ist ein dummy!
- Du hattest es "klassisch" gemacht (mit rhasspyMapping)

dummy werden leider inflationär genutzt (OT: es ist besser geworden), von daher würde ich - so es irgend möglich ist - empfehlen, echte Hardware anzusteuern. Optimal wäre da ein farbiges HUEDevice (die bridge kann man ja mehrfach "anzapfen", also insbesondere auch von einem Testsystem aus), alternativ (aber schwieriger) eine dimmbare (und ggf. farbige) MQTT2_DEVICE-Leuchte (ob ursprünglich zigbee2mqtt, Tasmota oder Shelly oder sonst was ist egal); das ist nur etwas schwieriger, aber wer Testhardware hat, kann ja auch einen MQTT2_SERVER kurz dafür auf dem Testsystem aufziehen.   
dummy braucht darüber hinaus auch sinnvolle setList-Angaben, damit das mit genericDeviceType klappt, und da kommt vermutlich der eine oder andere ins Schleudern bzw. es wird auch der "Vorteil" der automatisierten Erkennung verwässert.
MAn. ist der "aha"-Effekt viel größer, wenn man reale Hardware nimmt, weil dann mehr oder weniger unmittelbar sichtbar wird, was RHASSPY erkennen/auswerten kann (und was ggf. nicht). (Wenn da noch was fehlt, können wir in dem Zuge dann auch noch nachlegen).

Bzgl. der unmittelbaren sentences.ini-Anpassung: In den letzten Versionen  sind  mehr slots verfügbar, so dass ein {Device} für einen OnOff-Intent m.E. nicht mehr optimal ist - man sollte das daher mAn. dann direkt wieder ändern, und fragt sich dann vermutlich, welchen Sinn die erste Änderung denn eigentlich hatte...

Daher sollte man dann nach der Vergabe des gDT-Attributs an ein (von der devspec erfasstes) reales Device mal "update devicemap" machen und sich anschließend erst das RHASSPY-list und dann die ganzen slots ansehen ;) . (bin nur unschlüssig, ob man erst mal "nur vorhandene slots generieren" aktivieren sollte?).

Zitat von: DrBasch am 21 Mai 2021, 02:19:07
Das möchte ich gerade verstehen, [...]
An DefFn() wird die Definition

define myPorcupine RHASSPY Element3 Element4 Element5

(parseParams ist aktiviert) als Liste (Array) mit den unbenannten Elementen beginnend ab "myPorcupine" (=> NAME als Internal) übergeben. Das Beispiel hat also 5 unbenannte Argumente, das Modul verarbeitet offiziell aber nur zwei (NAME und TYPE (=RHASSPY)).

Bei

define myPorcupine RHASSPY Element6 Element5=bla Element3="das ist ein Test" Element4="blub"

hätte man 3 unbenannte Argumente und 3 benannte, das "richtig fehlerhafte" Beispiel

define myPorcupine RHASSPY Element6 Element5=bla Element3=das ist ein weiterer Test Element4="blub"

liefert 7 unbenannte und 3 benannte.
Klarer jetzt?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: DrBasch am 21 Mai 2021, 10:21:32
Zitat von: Beta-User am 21 Mai 2021, 05:41:40
:) Dann mal willkommen an Bord!
Danke und Ahoi, Käpt'n

Zitat
Du solltest dann möglichst die letzte hier verfügbare Fassung im Einsatz haben (und die zugehörige rhasspy-de.cfg).
Klar, ich hatte schon die gestern von Dir hier eingestellte Version (0.4.15, glaube ich) gezogen und werde - wenn es soweit ist - nochmal nachschauen ob Ihr schon wieder nachgelegt habt.

Zitat
- Zu docker kann ich nichts beitragen, das dürfte aber aktuell sein (ich habe den debian-Weg genommen, siehe meinen gesonderten Thread dazu; heißt aber ausdrücklich nicht, dass das "besser" wäre, sondern nur, dass mir dieser Weg näher lag/sympatischer war!).
Docker + Rhasspy-Container laufen schon. Die docker-Installation ist imho der einfachste/userfreundlichste (aber nicht unbedingt "bessere" Installationsweg). Am der .venv-Variante war ich zuvor gescheitetert: u.a. gibt es mit der aktuellen Rhasspy bzw. RasPi OS-Version Probleme bei der Compilierung, so man das Makefile händisch editieren muss.
Ich suche mir aber nochmal deine Ausführungen bezgl. debian dazu raus. Es schadet mE nicht die Installationsvarianten zu dokumentieren und "docker-free" wäre mir persönlich auch lieber. Meine euphorische Docker-Phase hab ich hinter mir...

Etwas Kopfzerbrechen bereitet mir noch ob - und wenn ja in welcher Form - man in einem Wiki auf die Installation der Treiber eingehen kann/sollte/muss. Für die ReSpeaker z.B. muss man ja seeed-voicecard-Treiber installieren, die Originaltreiber (https://github.com/respeaker/seeed-voicecard (https://github.com/respeaker/seeed-voicecard) sind derzeit ohne Kernel-Downgrade nicht verwendbar und der fork von HinTak ist ... naja ... halt ein fork. Wie lange gibt es den noch?
Wenn man auf die Installation von ReSpeaker-Treibern eingeht, was "bietet" man Usern an, die z.B. eine PS Eye Camera an den Start bringen wollen? ("Nix" ist diesbzgl. sicher _eine_ Lösung).
Was mich gleich zur nächsten Unschlüssigkeit bringt: Wo holt man den User ab? / Wo steigt man - i.S.e Wiki-HowTo - ein? / Welche "Voraussetzungen" (hard- bzw. softwareseitig) sollten definiert werden?

Zitat
- an der sentences.ini sollte man m.E. nicht direkt rumschrauben. "Zu meiner Zeit" hat direkt der vorhandene "Wie spät ist es"-Satz genügt, um von FHEM eine Antwort zu erhalten, jetzt muss man m.E. den intent anfassen und ein "de.fhem:" davorsetzen (bei ensprechender language/fhemId).
Na, dass werde ich heute abend dann gleich ausprobieren...
Das denglische Text to Speech hab ich schon kennengelernt: "Sorry but something seems not to work as expected" -> ROTFL.

Zitat- Du hattest es "klassisch" gemacht (mit rhasspyMapping)
Stimmt, obgleich ich quasi jeden Anlauf mit devspec=genericDeviceType=.+ begonnen habe. Als es dann nicht funktioniert hat, hab ich verbogen was ich konnte, in der Hoffnung es zum Laufen zu kriegen... Und dabei - wie du ja auch angemerkt hast - das ein oder andere Mal "attr Dummy setList on off" vergessen. :-[

Zitat...von daher würde ich - so es irgend möglich ist - empfehlen, echte Hardware anzusteuern...
HUEDevices hab ich leider nicht. Kurzfristig werde ich versuchen Schaltsteckdosen, Heizkörperthermostaten, Fenstersensoren anzusteuern. Mittelfristig kommen dann sicherlich noch eine (derzeit noch orginalverpackte) zigbee Leuchte, eine HarmonyOne und Sonos-Devices dazu.

Ferner sehe ich dann noch CALENDAR-Devices ("Welche Termine habe ich/haben wir/hat XYZ heute?"), ABFALL- und Wetter-Module ("Wann kommt die Müllabfuhr?", "Wie wird das Wetter?/Wird es regnen?" o.s.ä) u. PostMe-Listen für Einkaufszettel/ToDo-Listen ein (Keine Ahnung, ob das überhaupt realiserbar ist, dürfte von seiten Rhasspys offline-"Wortschatz" schwierig werden). Das sehe ich aber eher als "Privat-Projekte" die ich nicht in ein Wiki/cref sondern bestenfalls in einen Thread dokumentieren würde.

ZitatDaher sollte man dann nach der Vergabe des gDT-Attributs an ein (von der devspec erfasstes) reales Device mal "update devicemap" machen und sich anschließend erst das RHASSPY-list und dann die ganzen slots ansehen ;)
...Ist notiert! Mach ich.

ZitatKlarer jetzt?
Definitiv! Jetzt verstehe ich, was du mit
Zitat von: Beta-User am 20 Mai 2021, 14:48:07
Wenn mehr als TYPE und NAME angegeben sind, liegt der Verdacht nahe, dass es zu viele sind, und ab 4 liegt sicher ein Fehler vor
meintest.

Sorry, wenn ich so viel nachhake... Ich bin bzgl. MQTT, Softwareentwicklung (iHa die modulare FHEM-Architektur) und Perl echt unerfahren und gedanklich auf die Wege fixiert, die mir bei kleinen Projekten und Problemstellungen geholfen haben.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 21 Mai 2021, 11:18:01
Zitat von: DrBasch am 21 Mai 2021, 10:21:32
Klar, ich hatte schon die gestern von Dir hier eingestellte Version (0.4.15, glaube ich) gezogen und werde - wenn es soweit ist - nochmal nachschauen ob Ihr schon wieder nachgelegt habt.
Dachte ich mir, und - jedenfalls von meiner Seite - wird es immer erst mal hier die Info geben, was es neues gibt (und zumindest rudimentär, was sich geändert hat).
Im Moment sollte da erst mal wenig neues kommen, allenfalls Reaktionen auf gefundene "uninitialized" bzw. aufgegriffene Anregungen von mutigen "Matrosen" ;) .

Zitat
Docker + Rhasspy-Container [...] debian [...] ob - und wenn ja in welcher Form - man in einem Wiki auf die Installation der Treiber eingehen kann/sollte/muss.
Klares statement von meiner Seite: Die Rhasspy-Installation muss der User "alleine" hinbekommen.
Man _kann_ ggf. einen Weg (docker) als "geprüftes Muster" mit aufnehmen, aber eben unter dem für externe Projekte "üblichen Vorbehalt", dass das nur eine Momentaufnahme ist und man bitte im externen Projekt nachfragen soll, wenn was unklar ist. Man kann auch gerne auf die "hardwarelose" Variante verweisen, die ich unter Debian mit der App betreibe, aber auch da sollte (mAn.) nicht mehr als der Link zum Thread zu finden sein. Sonst wird das uferlos und veraltet auch zu schnell...

ZitatWas mich gleich zur nächsten Unschlüssigkeit bringt: Wo holt man den User ab? / Wo steigt man - i.S.e Wiki-HowTo - ein? / Welche "Voraussetzungen" (hard- bzw. softwareseitig) sollten definiert werden?
Wieder meine 2ct: Als Vorbemerkung (im Prinzip) nur rein, wo man Hinweise findet, um (mind.) ein lauffähiges Rhasspy am Start zu haben, aber der eigentliche Einstieg ist: der Dienst läuft, "wie spät ist es" schickt einen MQTT-JSON auf den Weg, die Aufgabe ist ab jetzt, diesen in FHEM auszuwerten und was sinnvolles daraus zu machen...

Zitat
Das denglische Text to Speech hab ich schon kennengelernt: "Sorry but something seems not to work as expected" -> ROTFL.
;D ;D ;D Solche - mal mehr, mal weniger erheiternden - Momente braucht es (bei mir war es die Uhrzeit, und die "allSets" von einem MQTT2_DEVICE vorgelesen zu bekommen, hat auch seinen Reiz ;D (da sind die ganzen attrTemplate-Namen mit drin, ist gefühlt endlos :o )...), und es ist m.E. auch hilfreich klarzustellen, dass es schon ein ziemlich gutes Zwischenergebnis ist, wenn man zum ersten Mal überhaupt eine Rückmeldung bekommt!

(Wer an dieser Stelle ist, sollte in etwa knapp die Hälfte des Weges haben, btw.! (Aber erst mal eher in der Ausbaustufe "Pfad"  :P ))

Zitat
Stimmt, obgleich ich quasi [...]
qed.
(fyi: ich hatte bisher nur den unbestimmten Verdacht, dass das früher oder später jemandem passieren wird und eigentlich nicht damit gerechnet, dass das direkt im Schwarzen ladet...)

Zitat
HUEDevices hab ich leider nicht.
Was es konkret ist, ist nicht ganz so wichtig. Meine Empfehlung ist ein "onoff"-Device, wenn möglich dimmbar, optimalerweise farbig (da sind nämlich (v.a. bei HUEDevice bzw. allem, was "echtes HUE" kann...) die ersten Stolpersteinchen zu erwarten).
Alternativ ein Rollladenaktor, der aber Krach macht und vergleichsweise träge ist, wenn man korrekte Ergebnisse checken will. Da sollten die meisten Typen ootb laufen, von daher ist das "zweitbeste Wahl".
HK-Thermostate sollten "zur Not" auch gehen, bisher getestet habe ich aber nur CUL_HM, da könnte es also schwierig werden, wenn der setter anders ist als bekannt usw.. (Bei ZWave fehlt z.B. vermutlich "desired-temp" als Reading)
Fenstersensoren hatten wir bisher nicht, aber "contact" als gDT-Typ zu ergänzen sollte ggf. kein Hexenwerk sein, wenn "state" paßt (insbesondere "gekippt" gibt es aber noch nicht als Satz...).

Sonos könnte als "media" auch klappen, ist aber ein Experimentierfeld.

Beim Rest werden wir sehen, was Privatprojekt ist, und wo ggf. Optionen bestehen, eins nach dem anderen, ist doch schon mal was, wenn das Sonos auf play/pause, lauter/leiser und ein/aus reagiert, oder?

Zitat
Sorry, wenn ich so viel nachhake... Ich bin bzgl. MQTT, Softwareentwicklung (iHa die modulare FHEM-Architektur) und Perl echt unerfahren und gedanklich auf die Wege fixiert, die mir bei kleinen Projekten und Problemstellungen geholfen haben.
Das ist a) völlig ok und b) sehr hilfreich, weil du damit die Chance hast, genau die Fragen zu stellen, die die Mehrzahl der FHEM-User auch hat.

Meine Bitte wäre:
Vermutlich wird die Diskussion über das eine oder andere Detail bei der Einrichtung von konkreten Geräten schon eine Art hilfreicher Doku für alle die, die auf dem jetzigen Stand einsteigen wollen. Wenn du dafür einen eigenen Thread aufmachst, kann man auf den "Prototypen" verweisen, und das ist in der Regel unterhaltsam für die, die das dann irgendwann nachlesen oder nachbauen...
(Es gibt zu diversen mqtt2-attrTemplate-Varianten ein paar solcher Threads, und meistens ist es mir wohl gelungen, solche "Projektchen" zur beiderseitigen Zufriedenheit zu "coachen" (hoffe ich zumindest...). Bei dir habe ich jedenfalls das Gefühl, dass das sehr gut gelingen könnte, die Frage (und die Tonlage ;) ) sind auf einem m.E. "passenden" Niveau.

Immer dann, wenn wir wirklich am Modul was schrauben müssen (neue TYPE für Heizkörperthermostate, z.B.), kommen wir hierher zurück, fixen das Problem und machen im "Prototype"-Thread weiter, wenn klar ist, wie es geht?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 21 Mai 2021, 11:37:09
Soooo, wo fang ich an. Hab da ja doch was verpasst.

Vielleicht zum Einstieg mal zur Doku:

Zitat von: Beta-User am 20 Mai 2021, 08:29:28
Unsere Probleme dabei:
- drhirn und andere, die die Vorversionen schon im Einsatz hatten, haben ihre Systeme "nach guter alter Väter Sitte" konfiguriert und "fremdeln" (noch) etwas mit dem gDT-Ansatz
Üüüüüberhaupt nicht wahr! In meinem produktiven FHEM ist alles, was ging, via gDT konfiguriert ;)

Den "FHEM und Rhasspy"-Thread hab ich zu gemacht. Den Hinweis auf die Anleitung von cb2sela als veraltet markiert.

Zitat von: Beta-User am 20 Mai 2021, 08:29:28
Wenn die Doku (halbwegs) fertig ist und die aktuelle dev-Version keine größeren Schwächen mehr zeitigt, wäre ggf. dann der Zeitpunkt gekommen, das ganze dann auch "scharf" zu schalten, also das Modul in den regulären update-Zyklus aufzunehmen (wir sollten aber ggf. wissen, wer von den 10 (in statistics) "gemeldeten" Installationen schon auf dem MQTT2_CLIENT-IO ist, damit wir nicht versehentlich/unangekündigt jemanden "abschießen").
Hmm. Ich hätte gerne noch eine breitere Userbasis bevor wir aus contrib raus gehen. Von den 10 gemeldeten Installationen sind wahrscheinlich schon mal drei von mir.

Zitat von: DrBasch am 20 Mai 2021, 02:11:10
und einen kurzen Blick auf Eure Rhasspy Konfiguration erhaschen konnte bin ich nachfolgend dazu übergegangen für jede intention eine eigene .ini anzulegen. Ist dieses Vorgehen okay, oder kann/sollte man besser alle intentions einfach in die sentence.ini kloppen?
Das kannst du machen, wie du möchtest. Ich bevorzuge den Weg über viele verschiedene .ini Dateien. Einfach, weil ich's übersichtlicher finde. Für Rhasspy macht das aber keinen Unterschied.

Zitat von: DrBasch am 20 Mai 2021, 02:11:10
Im Github readme wird unter "Attributes (ATTR)" noch (das alte) "configFile" anstelle von "languageFile" erklärt
Danke, ist in der dev-Branch korrigiert

Zitat von: Beta-User am 21 Mai 2021, 05:41:40
@drhirn: spricht was dagegen, die im svn einzuchecken?
Nein, gar nicht. Mache ich, sobald ich zuhause bin. Also vom Büro. Nicht, dass noch einer glaubt, ich würde seit Mittwoch meine neue alte Freiheit genießen ;D

Zitat von: DrBasch am 21 Mai 2021, 10:21:32
Ferner sehe ich dann noch CALENDAR-Devices ("Welche Termine habe ich/haben wir/hat XYZ heute?"), ABFALL- und Wetter-Module ("Wann kommt die Müllabfuhr?", "Wie wird das Wetter?/Wird es regnen?" o.s.ä) u. PostMe-Listen für Einkaufszettel/ToDo-Listen ein (Keine Ahnung, ob das überhaupt realiserbar ist, dürfte von seiten Rhasspys offline-"Wortschatz" schwierig werden). Das sehe ich aber eher als "Privat-Projekte" die ich nicht in ein Wiki/cref sondern bestenfalls in einen Thread dokumentieren würde.
Das sehe ich wiederum ganz anders. Das wären genau die Sachen, die ich mir im Wiki vorstellen würde. Und auch sehr gerne selbst als Modul vom Modul zur Verfügung hätte. Einkaufszettel ist aber in der Tat nicht ganz einfach. Irgendwo im Forum glaube ich aber eine Liste mit möglichen Produkten gesehen zu haben, die man dann einfach nur in die Custom Words integrieren müsste.

Zu vorkonfigurierten sentence.ini-Files ein klares Nein von mir. Das kann zu einem Saustall führen, wenn man im Nachhinein Präfix oder Sprache ändert weil man mit der Konfiguration noch nicht ganz fertig war.

Hab ich was übersehen, auf das ich noch antworten sollte?

Ich werde jetzt mal die neuen Files auf GitHub übernehmen und die main-Branch daraus machen.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 21 Mai 2021, 12:09:27
Zitat von: drhirn am 21 Mai 2021, 11:37:09
Vielleicht zum Einstieg mal zur Doku:
Aye, Mr. Admiral!

(Ich spekuliere darauf, dass sich >80% der "echten" aktuellen Einsteigerporbleme in dem Muster-Thread direkt und einigermaßen dauerhaft klären lassen; ob und wie man das dann ggf. zusammenfasst, werden wir erst später entscheiden können).

ZitatÜüüüüberhaupt nicht wahr! In meinem produktiven FHEM ist alles, was ging, via gDT konfiguriert ;)
8) Eine Rückmeldung dazu, yippie!  ;D
Hast du eine grobe Schätzung, welchen Anteil "alles, was ging" in etwa hat?
Müßte mal schauen, aber ich meine, bei meinen 3 "Musterräumen" im Produktivsystem gibt es genau ein klassisches rhasspyMapping (weil ich irgendwann in der Anfangsphase von FHEM leider nicht realisiert habe, dass man bei MySensors den "Endpunkten" eigene Readingnamen verpassen kann und ich jetzt nur deswegen nicht unbedingt die historischen Daten über den Jordan schicken wollte, um "passende" Reading-Namen zu generieren  ::) ...)

ZitatDas sehe ich wiederum ganz anders. Das wären genau die Sachen, die ich mir im Wiki vorstellen würde. Und auch sehr gerne selbst als Modul vom Modul zur Verfügung hätte. Einkaufszettel ist aber in der Tat nicht ganz einfach. Irgendwo im Forum glaube ich aber eine Liste mit möglichen Produkten gesehen zu haben, die man dann einfach nur in die Custom Words integrieren müsste.
Zur Klarstellung: Das ist durchaus interessant, aber eben in "Ausbaustufe 2+".

Modell in etwa:
Grundstufe 1 => Rhasspy+RHASSPY laufen, was via gDT direkt zu erschlagen ist, ist erschlagen.
Grundstufe 2 => Räume, Gruppen und Devices sind so benannt, dass alles soweit rund läuft, spezielle Devices haben eigene rMappings, "specials" sind implementiert wo erforderlich
Ausbaustufe 1 => Shortcuts und ggf. erste kleine CustomIntents
Ausbaustufe 2 => this is where fun starts...

bzgl. Custom Words und Einkaufsliste: Man kann von FHEM aus eigene slots generieren :P ... (und dabei entscheiden, ob der bestehende überschrieben werden soll; ist aber von meiner Seite bisher ungetestet...)

Zu vorkonfigurierten sentence.ini-Files [...]
Nachvollziehbare Position. In der Praxis brauchen wir m.E. sowas wie einen brauchbaren Startpunkt (=> Muster-Thread, damit man ggf. auch mal etwas ausführlicher diskutieren kann, welchen slot man denn ggf. für was verwendet und warum... (ich bin da auch noch nicht durch, und hab' erst mal versucht, überhaupt eine Diskussionsgrundlage zu schaffen, sonst ist das sehr abstrakt).

Zitat
Hab ich was übersehen, auf das ich noch antworten sollte?
Bestimmt, aber das geht mir ziemlich sicher auch nicht anders ::) .
Wichtige Punkte kommen aber erfahrungsgemäß sowieso wieder in der einen oder anderen Form auf den Tisch...

ZitatIch werde jetzt mal die neuen Files auf GitHub übernehmen und die main-Branch daraus machen.
Thx!
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 21 Mai 2021, 12:32:27
Zitat von: Beta-User am 21 Mai 2021, 12:09:27
8) Eine Rückmeldung dazu, yippie!  ;D
Hast du eine grobe Schätzung, welchen Anteil "alles, was ging" in etwa hat?

Naja, ich verwende Rhasspy derzeit nur, um den TV ein- und auszuschalten, Lichtszene im Wohnzimmer zu ändern, Timer zu setzen und die Temperatur abzufragen. Und eigentlich war auch der Plan, die Heizung zu kontrollieren. Das hat sich aber endlich erledigt. Zumindest für die nächsten paar Monate. Also bis auf Lichtszene und Timer ist überall gDT gesetzt.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 21 Mai 2021, 14:09:07
@Beta-User: Warum hast du das Erstellen von Scene-Slots auskommentiert?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 21 Mai 2021, 14:23:43
Ähm, habe ich...?
Oder nur in Teilen? Dunkle Erinnerung: es war "too much" und ist an anderer Stelle untergebracht?

(Das Ergebnis müsste bei einem device_map-update via MQTT relativ einfach zu begutachten sein).
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 21 Mai 2021, 15:21:25
Hab mich vertan. Auf meiner Testumgebung im Büro wurden die Slots nicht erstellt. Zuhause schon.

Aktuelle Versionen sind im SVN
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 21 Mai 2021, 15:27:44
...ist schon eine Weile her, aber dunkel schimmert da was, dass auch das so ein Thema war, wo ich dann hinterher dachte, dass es in diesem Fall besser ist, die leeren Intents nicht zu erstellen (analog zu der Diskussion um Shortcuts):
Zitat von: Beta-User am 20 Mai 2021, 14:48:07
Da Rhasspy das dann irgendwie zu verarbeiten versuchen würde und dann ggf. wieder versuchen, daraus MQTT-Payload zu generieren, ist das meinem Bauchgefühl nach keine gute Idee. Da Shortcuts ansonsten "autonom" ist, ist es hier egal, ob das nun erstellt wird oder nicht => raus damit...
Vermute also, dass es in der Testumgebung keine SetScene-Optionen gibt...?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 21 Mai 2021, 15:31:03
Ich hab's nur kurz vor'm Heimgehen schnell zusammen geschustert. Kann gut sein, dass ich etwas übersehen habe.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 21 Mai 2021, 15:41:32
Besser nachgefragt - ich mache auch ausreichend viele Fehler ::) ...
(Eher in Richtung Dr. Basch, falls mal ein Blick in den Code erforderlich werden sollte): Relativ ich oft lasse ich Codeteile, die wir vermutlich nicht mehr (oder noch nicht) benötigen deaktiviert im Code stehen, bis ich dann sicher bin, dass man das definitiv nicht mehr (funktional oder als Vergleich) braucht (fremde Teile fasse ich normalerweise nicht an). Erst dann fliegt es ggf. letztendlich raus.

@drhirn: Wenn das mit dem WDT (und der lib) fertig ist, könnten wir das dann auch hierher übernehmen und anschließend mal noch etwas aufräumen. Ist zwar "gefühlt" nicht mehr viel, aber schaden tut aufräumen eigentlich nie...

War bei den gDT-Geschichten irgendwas dabei, was interessant wäre oder nicht funktioniert hat? Hast du irgendwo "specials" gesetzt?
(Es klang nach nicht besonders vielen Devices, aber grade "am Anfang" ist jeder erledigte Punkt einer, über den der nächste nicht mehr stolpert, und dein Zoo ist wohl etwas anders als meiner...)
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 21 Mai 2021, 15:48:22
Zitat von: Beta-User am 21 Mai 2021, 15:41:32
@drhirn: Wenn das mit dem WDT (und der lib) fertig ist, könnten wir das dann auch hierher übernehmen und anschließend mal noch etwas aufräumen. Ist zwar "gefühlt" nicht mehr viel, aber schaden tut aufräumen eigentlich nie...
Wenn wir womit fertig sind?

ZitatWar bei den gDT-Geschichten irgendwas dabei, was interessant wäre oder nicht funktioniert hat? Hast du irgendwo "specials" gesetzt?
Wie du sagst, es sind nicht viele Devices. Und nein, außer bei der LightScene und Timer keine Specials bisher.

A propos LightScene: Ich spreche bisher (rhasspyChannels) nur "Computerlicht", "Esslicht", etc. Täte ich gerne so beibehalten. Weil "Licht auf Esslicht" macht zwar Sinn, ist für mich faulen Menschen aber zu viel geredet ;D. Geht jetzt leider nicht, weil wir das Device brauchen. Bekommen wir das hin, dass automatisch das passende Device zur Szene gesucht wird?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 21 Mai 2021, 16:06:27
Zitat von: drhirn am 21 Mai 2021, 15:48:22
Wenn wir womit fertig sind?
In dem Fall mache ich das ganz alleine "fertig": das Einbauen und Einchecken der "Register.pm"-lib in den WeekdayTimer (und ein paar Nebenarbeiten, und dann noch dasselbe in Twilight).

Zitat
Wie du sagst, es sind nicht viele Devices. Und nein, außer bei der LightScene und Timer keine Specials bisher.
:) Hatte schon vermutet, dass das Ausbleiben von Rückmeldung dann "funktioniert einfach" bedeuten sollte.

Zitat
A propos LightScene: Ich spreche bisher (rhasspyChannels) nur "Computerlicht", "Esslicht", etc. Täte ich gerne so beibehalten. Weil "Licht auf Esslicht" macht zwar Sinn, ist für mich faulen Menschen aber zu viel geredet ;D . Geht jetzt leider nicht, weil wir das Device brauchen. Bekommen wir das hin, dass automatisch das passende Device zur Szene gesucht wird?
Hmm, ja, nun, vielleicht, Kopfkratz (da habe ich ja mal wieder eine doofe Frage gestellt...)....

Auf die Schnelle: "Im Prinzip" sollte es möglich sein, den rawInput mit dem gemappten "Ausgangssatz" (also in deinem Fall: dem einen Wort) zu vergleichen und darüber dann wieder das Ausgangsdevice zu rekonstruieren (ggf. nur, wenn es nicht vorher klare Ergebnisse gibt).
Ich hatte das Problem bisher nicht, habe aber auch noch nicht so intensiv getestet, sondern war erst mal froh, (halbwegs) sinnvollen Input zur Weiterverarbeitung an Rhassy abliefern zu können. Und: Meine Szenennamen sind auch recht eindeutig; es gibt die "tech-scenes" 1-4 aus dem Yamaha und ein paar lightScene-Szenen, die man ja aber eindeutig benennen kann.

Sollten wir im Auge behalten und können ggf. dann Nachsteuern.
Das einzige Problem, das ich im Moment sehe: Wenn jemand identische oder ähnliche Szenen-Sätze hat, muss irgendwie priorisiert werden, also z.B. festgelegt, ob der "Sprachraum" wichtiger ist wie rawInput oder umgekehrt... Vermutlich sollten wir da etwas Erfahrungen und "Spielmaterial" für Code-Schnipsel sammeln.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 21 Mai 2021, 19:07:11
Ist keine große Tragödie. Ich kann's ja weiterhin über rhasspyChannels machen.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 22 Mai 2021, 09:06:28
Nachdem ich mir mal die aktuellen Slots und die SetScene.ini (kurz) angesehen habe, kam dann auch wieder eine Erinnerung an den "aktuellen Stand" hoch... Das ist irgendwie unfertig, der Hinweis ist schon berechtigt.
Irgendwie hatte ich noch keine "Vision" entwickelt, ob das mit oder ohne direkte ini gehen soll bzw. wie dann die automatisch erstellten sentences aussehen sollen, wie es mit (unbeabsichtigten?) "Doppelungen" sein soll, usw., usf..

Vermutlich sollten wir da mal sowas wie eine gemeinsame Vorstellung entwickeln, wie man das wirklich sinnvoll nutzen kann, also was will "man" wo sagen können, damit was passiert, wo soll welche Info herkommen, welche pattern, Variablen sollten wo verfügbar sein, welche "Schätzungen" sollen bei der Auswertung erfolgen, ...

(Vermutlich schwierig zu verstehen).

Stand an der Stelle ist also eher Machbarkeitsstudie, als "fertig" kann man den Teil wohl nicht bezeichnen.
Wer also Ideen hat (und die neuen slots etc. jetzt schon gesehen hat) möge sich dazu äußern ::) .
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 25 Mai 2021, 12:48:24
Ich wurde hier (https://github.com/fhem/fhem-rhasspy/issues/1#issue-899050098) darauf hin gewiesen, dass bei analyzeAndRunCmd Befehle in Anführungszeichen nicht ausgeführt werden. Ich kann das leider nachvollziehen.

Wenn ich mir folgendes Beispiel bastle:

attr Fernseher rhasspyChannels Netflix=launchApp Netflix\
SkyOnline=set Fernseher launchApp SkyOnline\
YouTube="set Fernseher launchApp YouTube"

funktionieren die ersten beiden. Das letzte nicht.

Hab jetzt ziemlich viel herum probiert, komme aber nicht drauf, warum. Hast du eine Idee?

Das ist der Output im Log bei allen drei Varianten:

2021.05.25 12:46:53.275 5: RHASSPY: [Rhasspy] Parse (IO: rhasspyMQTT2): Msg: hermes/intent/de.fhem_MediaChannels => {"input": "schalte um auf Netflix", "intent": {"intentName": "de.fhem:MediaChannels", "confidenceScore": 1.0}, "siteId": "default", "id": "d0176c00-7d84-44e5-93b6-a6e0e51105c4", "slots": [{"entity": "de.fhem.MediaChannels", "value": {"kind": "Unknown", "value": "Netflix"}, "slotName": "Channel", "rawValue": "netflix", "confidence": 1.0, "range": {"start": 15, "end": 22, "rawStart": 15, "rawEnd": 22}}], "sessionId": "d0176c00-7d84-44e5-93b6-a6e0e51105c4", "customData": null, "asrTokens": [[{"value": "schalte", "confidence": 1.0, "rangeStart": 0, "rangeEnd": 7, "time": null}, {"value": "um", "confidence": 1.0, "rangeStart": 8, "rangeEnd": 10, "time": null}, {"value": "auf", "confidence": 1.0, "rangeStart": 11, "rangeEnd": 14, "time": null}, {"value": "Netflix", "confidence": 1.0, "rangeStart": 15, "rangeEnd": 22, "time": null}]], "asrConfidence": null, "rawInput": "schalte um auf netflix", "wakewordId": null, "lang": null}
2021.05.25 12:46:53.276 5: Parsed value: MediaChannels for key: intent
2021.05.25 12:46:53.276 5: Parsed value: Netflix for key: Channel
2021.05.25 12:46:53.278 5: Parsed value: schalte um auf Netflix for key: input
2021.05.25 12:46:53.279 5: Parsed value: d0176c00-7d84-44e5-93b6-a6e0e51105c4 for key: sessionId
2021.05.25 12:46:53.280 5: Parsed value: default for key: siteId
2021.05.25 12:46:53.280 5: Parsed value: schalte um auf netflix for key: rawInput
2021.05.25 12:46:53.281 5: Parsed value: 1 for key: probability
2021.05.25 12:46:53.283 5: handleIntentMediaChannels called
2021.05.25 12:46:53.284 5: room is identified using siteId as wohnzimmer
2021.05.25 12:46:53.284 5: Device selected (by hash, with room and channel): Fernseher
2021.05.25 12:46:53.285 5: analyzeAndRunCmd called with command: launchApp Netflix
2021.05.25 12:46:53.285 5: Fernseher launchApp Netflix is a normal command
2021.05.25 12:46:53.286 5: Response is: OK
2021.05.25 12:47:01.582 5: RHASSPY: [Rhasspy] Parse (IO: rhasspyMQTT2): Msg: hermes/intent/de.fhem_MediaChannels => {"input": "schalte um auf SkyOnline", "intent": {"intentName": "de.fhem:MediaChannels", "confidenceScore": 1.0}, "siteId": "default", "id": "5fbd571d-e8fe-4f20-b7d5-112f254341de", "slots": [{"entity": "de.fhem.MediaChannels", "value": {"kind": "Unknown", "value": "SkyOnline"}, "slotName": "Channel", "rawValue": "skyonline", "confidence": 1.0, "range": {"start": 15, "end": 24, "rawStart": 15, "rawEnd": 24}}], "sessionId": "5fbd571d-e8fe-4f20-b7d5-112f254341de", "customData": null, "asrTokens": [[{"value": "schalte", "confidence": 1.0, "rangeStart": 0, "rangeEnd": 7, "time": null}, {"value": "um", "confidence": 1.0, "rangeStart": 8, "rangeEnd": 10, "time": null}, {"value": "auf", "confidence": 1.0, "rangeStart": 11, "rangeEnd": 14, "time": null}, {"value": "SkyOnline", "confidence": 1.0, "rangeStart": 15, "rangeEnd": 24, "time": null}]], "asrConfidence": null, "rawInput": "schalte um auf skyonline", "wakewordId": null, "lang": null}
2021.05.25 12:47:01.583 5: Parsed value: 1 for key: probability
2021.05.25 12:47:01.583 5: Parsed value: SkyOnline for key: Channel
2021.05.25 12:47:01.584 5: Parsed value: MediaChannels for key: intent
2021.05.25 12:47:01.584 5: Parsed value: schalte um auf skyonline for key: rawInput
2021.05.25 12:47:01.585 5: Parsed value: default for key: siteId
2021.05.25 12:47:01.586 5: Parsed value: 5fbd571d-e8fe-4f20-b7d5-112f254341de for key: sessionId
2021.05.25 12:47:01.586 5: Parsed value: schalte um auf SkyOnline for key: input
2021.05.25 12:47:01.586 5: handleIntentMediaChannels called
2021.05.25 12:47:01.587 5: room is identified using siteId as wohnzimmer
2021.05.25 12:47:01.588 5: Device selected (by hash, with room and channel): Fernseher
2021.05.25 12:47:01.588 5: analyzeAndRunCmd called with command: set Fernseher launchApp SkyOnline
2021.05.25 12:47:01.588 5: set Fernseher launchApp SkyOnline is a FHEM command
2021.05.25 12:47:01.589 5: Response is: OK
2021.05.25 12:47:07.111 5: RHASSPY: [Rhasspy] Parse (IO: rhasspyMQTT2): Msg: hermes/intent/de.fhem_MediaChannels => {"input": "schalte um auf YouTube", "intent": {"intentName": "de.fhem:MediaChannels", "confidenceScore": 1.0}, "siteId": "default", "id": "59d60dcc-af23-4a4b-8202-e48a00383d4d", "slots": [{"entity": "de.fhem.MediaChannels", "value": {"kind": "Unknown", "value": "YouTube"}, "slotName": "Channel", "rawValue": "youtube", "confidence": 1.0, "range": {"start": 15, "end": 22, "rawStart": 15, "rawEnd": 22}}], "sessionId": "59d60dcc-af23-4a4b-8202-e48a00383d4d", "customData": null, "asrTokens": [[{"value": "schalte", "confidence": 1.0, "rangeStart": 0, "rangeEnd": 7, "time": null}, {"value": "um", "confidence": 1.0, "rangeStart": 8, "rangeEnd": 10, "time": null}, {"value": "auf", "confidence": 1.0, "rangeStart": 11, "rangeEnd": 14, "time": null}, {"value": "YouTube", "confidence": 1.0, "rangeStart": 15, "rangeEnd": 22, "time": null}]], "asrConfidence": null, "rawInput": "schalte um auf youtube", "wakewordId": null, "lang": null}
2021.05.25 12:47:07.112 5: Parsed value: YouTube for key: Channel
2021.05.25 12:47:07.112 5: Parsed value: MediaChannels for key: intent
2021.05.25 12:47:07.113 5: Parsed value: schalte um auf youtube for key: rawInput
2021.05.25 12:47:07.113 5: Parsed value: default for key: siteId
2021.05.25 12:47:07.114 5: Parsed value: schalte um auf YouTube for key: input
2021.05.25 12:47:07.114 5: Parsed value: 59d60dcc-af23-4a4b-8202-e48a00383d4d for key: sessionId
2021.05.25 12:47:07.115 5: Parsed value: 1 for key: probability
2021.05.25 12:47:07.116 5: handleIntentMediaChannels called
2021.05.25 12:47:07.119 5: room is identified using siteId as wohnzimmer
2021.05.25 12:47:07.119 5: Device selected (by hash, with room and channel): Fernseher
2021.05.25 12:47:07.120 5: analyzeAndRunCmd called with command: "set Fernseher launchApp YouTube"
2021.05.25 12:47:07.120 5: "set Fernseher launchApp YouTube" has quotes...
2021.05.25 12:47:07.122 5: ...and is now: set Fernseher launchApp YouTube (set Fernseher launchApp YouTube)
2021.05.25 12:47:07.123 5: Response is: OK
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 25 Mai 2021, 13:03:39
Na ja, die Anführungszeichen sind "leider" der Anzeiger dafür, dass (nur) replaceSetMagic stattfinden soll, was z.B. dann auch für die GetState-Geschichten genutzt wird. "Eigentlich" ist das ganze nur dahingehend inkonsitstent, dass nicht das Ergebnis in dem Fall gesprochen wird...

Das "Problem" ist eher (zusätzlich), dass hier bei "rChannels" (ausnahmsweise) nicht parseParams zum Einsatz kommt, was dann (aus heutiger Sicht gesprochen) irritierend ist. Für's erste sollten wir mal die Doku zu rChannels checken und ggf. klarstellen, dass hier bitte die Quotes nichts verloren haben. (rChannels war bisher nicht so in meinen persönlichen Fokus ::) ).
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 25 Mai 2021, 13:06:48
Ok.
daZiton hat ja eigentlich kein Problem mit Anführungszeichen, sondern mit Doppelpunkten im Befehl. Dabei ist er auf den Versuch mit den Anführungszeichen gekommen. Und die Doppelpunkte gehen halt leider auch nicht.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 25 Mai 2021, 13:15:51
Hmm, nach etwas Grübeln über dem Code: eigentlich wird ja erst geprüft, ob der erste Begriff ein cmd ist. Die ":"-Prüfung kommt erst danach (in elsif). Von daher sollte das doch mit der "set"-Erweiterung auch ohne Quotes gehen, oder täuscht mich das?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 25 Mai 2021, 13:45:39
Leider, da wird davon ausgegangen, dass da ein anderes Device gemeint ist

2021.05.25 13:43:55.479 5: RHASSPY: [Rhasspy] Parse (IO: rhasspyMQTT2): Msg: hermes/intent/de.fhem_MediaChannels => {"input": "schalte um auf YouTube", "intent": {"intentName": "de.fhem:MediaChannels", "confidenceScore": 1.0}, "siteId": "default", "id": "2e6c60a7-2a81-43f2-a3bc-cad755c10359", "slots": [{"entity": "de.fhem.MediaChannels", "value": {"kind": "Unknown", "value": "YouTube"}, "slotName": "Channel", "rawValue": "youtube", "confidence": 1.0, "range": {"start": 15, "end": 22, "rawStart": 15, "rawEnd": 22}}], "sessionId": "2e6c60a7-2a81-43f2-a3bc-cad755c10359", "customData": null, "asrTokens": [[{"value": "schalte", "confidence": 1.0, "rangeStart": 0, "rangeEnd": 7, "time": null}, {"value": "um", "confidence": 1.0, "rangeStart": 8, "rangeEnd": 10, "time": null}, {"value": "auf", "confidence": 1.0, "rangeStart": 11, "rangeEnd": 14, "time": null}, {"value": "YouTube", "confidence": 1.0, "rangeStart": 15, "rangeEnd": 22, "time": null}]], "asrConfidence": null, "rawInput": "schalte um auf youtube", "wakewordId": null, "lang": null}
2021.05.25 13:43:55.481 5: Parsed value: 1 for key: probability
2021.05.25 13:43:55.482 5: Parsed value: schalte um auf youtube for key: rawInput
2021.05.25 13:43:55.482 5: Parsed value: default for key: siteId
2021.05.25 13:43:55.483 5: Parsed value: schalte um auf YouTube for key: input
2021.05.25 13:43:55.483 5: Parsed value: 2e6c60a7-2a81-43f2-a3bc-cad755c10359 for key: sessionId
2021.05.25 13:43:55.483 5: Parsed value: YouTube for key: Channel
2021.05.25 13:43:55.484 5: Parsed value: MediaChannels for key: intent
2021.05.25 13:43:55.485 5: handleIntentMediaChannels called
2021.05.25 13:43:55.486 5: room is identified using siteId as wohnzimmer
2021.05.25 13:43:55.487 5: Device selected (by hash, with room and channel): Fernseher
2021.05.25 13:43:55.488 5: analyzeAndRunCmd called with command: launchApp You:Tube
2021.05.25 13:43:55.491 5: launchApp You Tube redirects to another device
2021.05.25 13:43:55.492 1: fhemicon.png
2021.05.25 13:43:55.493 5: Response is: OK
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 25 Mai 2021, 13:55:56
Aber theoretisch funktioniert's ohne Anführungszeichen. Wenn ich den elsif ($cmd =~ m{:}x) { Block auskommentiere.
Es muss da also eine genauere Prüfung her.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 25 Mai 2021, 14:12:05
Na ja, also eben hatte ich einen erfolgreichen Versuch (ohne Auskommentieren) mit:
attr Sonos rhasspyChannels Netflix=launchApp Netflix\
SkyOnline=set Fernseher launchApp SkyOnline\
YouTube=setreading Sonos open plugin://plugin.video.twitch/?channel_id=CHANNEL_ID&mode=play


$DEVICE wird nur bei Perl ersetzt...

Das Auskommentierte kommt erst danach und beginnt mit elsif. Sollte also gehen (wie geschrieben). Nur eben nicht mit $DEVICE.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Ziton am 25 Mai 2021, 14:25:45
Hallo drhirn und Beta-User,

hierüber geht die Kommunikation natürlich einfacher. Ich bin der Schuldige für diesen kleinen Stolperstein.

Ich würde die Device Angabe theoretisch nicht brauchen wenn das übergebene Device genutzt werden könnte.
Dazu müsste ich aber an der Überprüfung auf ":" vorbeikommen.

Kann man evtl. noch ein elseif einbauen das man durchläuft wenn man den Doppelpunkt doppelt "::" und in diesem Fall
ein Doppelpunkt entfernt wird? Das erste elseif dürfte dann natürlich nur bei einfachem Doppelpunkt anspringen.

Wenn zu aufwendig muss ich hart programmieren falls ich diese Funktion an der Stelle wie beschrieben nutzen möchte. Wäre eben leider nicht so smart.

Gruß Ziton
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 25 Mai 2021, 14:36:44
Dann mal willkommen im FHEM-Forum!

Bin etwas verwirrt, wie geschrieben hatte ich den "setreading"-Test erfolgreich durchgeführt (also eigentlich nur eine kleine Abwandlung des set-Befehls wegen des "Zieldummy", der das als set nicht kennt (zur Sicherheit...) ). Aber auch so kommt das bei mir im state an:YouTube=set Sonos open plugin://plugin.video.twitch/?channel_id=CHANNEL_ID&mode=play
Den Doppelpunkt zu escapen wäre etwas umständlicher, weil man das dann ggf. vorher irgendwo erledigen müßte und dann hinterher wieder an der richtigen Stelle zusammenbasteln.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 25 Mai 2021, 16:34:20
Tatsächlich. Geht bei mir (zuhause) auch. Aber nur wenn ich set xxx mit angebe. Bin verwirrt. Dachte, ich hätte das im Büro auch getestet.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 25 Mai 2021, 16:57:02
Das ist etwas "speziell", weil dieser Zweig prüft, ob es einen passenden (FHEM-) command dafür gibt. Baut man da einen Tippfehler rein oder verwendet "Kurzformen", klappt es leider nicht.

(Bin noch nicht entschieden, ob ich diesen Parser insgesamt geglückt finde...)

Wie dem auch sei: Danke für die Bestätigung, DASS es geht. Ergänzt du die Doku (cref) "irgendwie"? Das ist jedenfalls nicht selbsterklärend :P ...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 25 Mai 2021, 17:02:35
Ja, mach ich dann. Sobald ich weiß, wie das "irgendwie" aussehen soll. ;)
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Ziton am 25 Mai 2021, 17:28:29
Danke fürs Willkommen heißen :-)

Ich wollte auf das nicht übersetzte $Device hinaus.

Wie du schon beschrieben hast wird $Device in dem Moment in dem der Befehl mit "set xxxx ...." angeben wird, nicht übersetzt. An der Stelle nachvollziehbar.
Im ursprünglichen Sinn würde der Befehl aus meiner Sicht nur mit "open plugin://plugin.video.twitch/?channel_id=CHANNEL_ID&mode=play" hinterlegt.
Das Device wird über den Sprachbefehl erkannt. (Ansonsten Fehler)

"2021.05.25 13:43:55.487 5: Device selected (by hash, with room and channel)"

"open" sollte auch die Prüfung auf einen (FHEM-) command überstehen imho. [EDIT: Ist ja quatsch ... die Prüfung wird es NICHT überstehen und läuft deswegen derzeit in den Elseif zweig mit dem Doppelpunkt.]

Zusammenbauen würde er das Ganze aber nur wenn die cmd Prüfung den elseif zweig auf den Doppelpunkt übersteht.

Gruß Ziton
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 25 Mai 2021, 18:03:58
Ähm, hast du das jetzt mit dem konkret angegebenen Device-Namen und dem "set" getestet oder nicht (also mein "Sonos" durch den Namen deines Geräte ersetzt)? Ich bin immer noch verwirrt und meine, mit diesem Umweg ginge es...

(Ist eher so, dass ich mir überlege, ob es Sinn macht, hier ein "special"-Äquivalent zu "rhasspyChannels" zu bauen, das etwas flexibler ist, auch in der Rückmeldung usw.. Mir fehlt aber etwas der Überblick, wer sowas wie aus welchen Gründen verwendet...)
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Ziton am 25 Mai 2021, 20:22:26
Entschuldige, ja es funktioniert wenn man den kompletten Befehl in das Attribut übernimmt.

Bei dieser Vorgehensweise habe ich nun bei jedem Channel den Device Namen hart im Attribut verdrahtet. Das ist der Punkt auf den ich hinaus wollte.

Ich kann mir schon vorstellen dass das ein Sonderfall ist und könnte durchaus auch verstehen wenn ihr da keine Arbeit rein stecken wollt.

Bei meinem ersten Ansatz mit dem Befehl in Anführungszeichen dachte ich ich könnte das Problem umschiffen. Konnte aber aus dem Code nicht genau herauslesen
wofür dieser Fall gedacht war da er keinen Ausführungsteil enthielt.

Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 25 Mai 2021, 20:51:02
Zitat von: Ziton am 25 Mai 2021, 20:22:26
Entschuldige, ja es funktioniert wenn man den kompletten Befehl in das Attribut übernimmt.
Sorry für die Nachfrage; ich habe manchmal das Problem, dass ich keine passende Hardware etc. habe und daher nicht sicher sein kann, ob die Trockenübung der Realität standhält ::) ...

Zitat
Bei dieser Vorgehensweise habe ich nun bei jedem Channel den Device Namen hart im Attribut verdrahtet. Das ist der Punkt auf den ich hinaus wollte.
Ich sehe ein, dass das "unschön" ist, aber im Moment sehe ich das als kleineren Schönheitsfehler an, da "rhasspyChannels" (und "rhasspyColors") "Sonderlocken" (als Attribute) sind und durch was generischeres ersetzt werden sollten. Also wenn an der Stelle überhaupt Aufwand reingesteckt werden sollte, dann mE. eher in den "Nachfolger" in "specials"...

Zitat
Konnte aber aus dem Code nicht genau herauslesen wofür dieser Fall gedacht war da er keinen Ausführungsteil enthielt.
Sich in dem Code als Neuling zu orientieren ist m.E. nicht wirklich einfach. Diese Codestelle wird von einigen Funktionen intern aufgerufen und hat daher an der einen oder anderen Stelle Funktionalitäten, die man nicht verstehen kann, wenn man sie nur aus der einen Warte betrachtet, von der man grade "losgelaufen" ist (hier: von rChannels kommend).
Andererseits ist es grade aus dem Grund relativ schwierig, was umzubauen; es besteht dann immer die große Gefahr, dass man eine Stelle übersehen hat und der Umbau dann entweder gar nicht geht, oder nur mit großen Mühen.... Ich habe mich auch relativ lange nicht getraut, diese zentralen Stellen überhaupt anzufassen.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 25 Mai 2021, 22:39:27
Sooo, für mutige (und FHEM-mäßig akuelle!) Tester und User....

(Intern wird jetzt die Register.pm zur Timerverwaltung genutzt. Das kommt mit dem update erst seit ein paar Tagen, ich hab's aber (mit RHASSPY) noch nicht intensiv getestet...)

Dafür kann das Ding jetzt vielleicht on-for-timer...

Beim gDT-Mapping ist mir auch was kaputt gegangen gewesen, das ist auch repariert.

sentence.ini zum Testen:
[de.fhem:SetTimedOnOff]
(schalt|mach) (den|die|das) $de.fhem.Device-SetOnOff{Device} [in|im|in der|auf der] [$de.fhem.Room{Room}] für [((1..60){Hour!int} (stunde|stunden))] [und] [((1..60){Min!int} (minute|minuten))] [und] [((1..60){Sec!int} (sekunde|sekunden))] $OnOffValue{Value}
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: DrBasch am 26 Mai 2021, 12:04:27
Guten Morgen.

Über Pfingsten bin ich jetzt doch aufs Produktivsystem gewechselt... mit einigen (mal wieder selbstverschuldeten  ::) ) Schwierigkeiten. Insgesamt scheint neue Konfiguration mit Master und Satelliten (ehemaliges Testsystem +  Rhasspy Mobile App) jetzt aber zu laufen.

Aber der Reihe nach - first things first:
Zitat von: Beta-User am 21 Mai 2021, 11:18:01
Bei dir habe ich jedenfalls das Gefühl, dass das sehr gut gelingen könnte, die Frage (und die Tonlage ;) ) sind auf einem m.E. "passenden" Niveau.
Vielen Dank, ich fasse das als Kompliment auf, dass ich gerne und aufrichtig zurückgeben möchte.

Zitat von: Beta-User am 21 Mai 2021, 05:41:40
- an der sentences.ini sollte man m.E. nicht direkt rumschrauben. "Zu meiner Zeit" hat direkt der vorhandene "Wie spät ist es"-Satz genügt, um von FHEM eine Antwort zu erhalten, jetzt muss man m.E. den intent anfassen und ein "de.fhem:" davorsetzen (bei ensprechender language/fhemId).
MAn. wäre das das "geschicktere" "hello world 1"-Erlebnis...
Der Vollständigkeit halber bestätige ich, dass bereits unter 0.4.15  nach define Rhasspy RHASSPY... kein leerer Intent mehr angelegt wurde/wird.
Nach Anlage von intents/de.fhem.GetTime.ini

[de.fhem:GetTime]
(wie spät | wieviel uhr) ist es
was sagt die Uhr

funktioniert die Zeitansage inkl. "hello wold-Experience".

Zitat von: Beta-User am 21 Mai 2021, 05:41:40
Daher sollte man dann nach der Vergabe des gDT-Attributs an ein (von der devspec erfasstes) reales Device mal "update devicemap" machen und sich anschließend erst das RHASSPY-list und dann die ganzen slots ansehen ;)
Zitat von: Beta-User am 25 Mai 2021, 22:39:27
Sooo, für mutige (und FHEM-mäßig akuelle!) Tester und User....
Beim gDT-Mapping ist mir auch was kaputt gegangen gewesen, das ist auch repariert.

Nach dem GetTime habe ich mich an die Konfiguration der Schaltsteckdosen für unsere Beleuchtung gemacht. Unter 0.4.15 wurde
nach attr <device> genericDeviceType switch
set Rhasspy update devicemap
list Rhasspy

partout kein (SetOnOff-/GetOnOff-)Intents gemappt.

Mit 0.4.16 werden jetzt beide Intents korrekt gemappt.
Jippie :D


Bzgl. Doku:
Bevor ich jetzt irgendeinen Unsinn mache möchte ich doch noch einmal nachfragen ob das so in Eurem Interesse wäre/ ich Eure Vorstellungen richtig verstanden habe:

Ich würde einen neuen Thread (z.B. "Mein Einstieg in Rhasspy" ) aufmachen und dort meine Erkenntnisse/Erfolge/Mißerfolge bei der Konfiguration teilen; mit Links als Hinweis auf die Grundeinrichtung bzgl. Rhasspy(https://rhasspy.readthedocs.io/en/latest/ (https://rhasspy.readthedocs.io/en/latest/)) und RHASSPY (https://github.com/fhem/fhem-rhasspy (https://github.com/fhem/fhem-rhasspy), cref). Von der Form her in Anlehnung an https://forum.fhem.de/index.php/topic,77724.msg696453.html#msg696453. Wäre das so okay für Euch?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 26 Mai 2021, 12:42:15
Zitat von: DrBasch am 26 Mai 2021, 12:04:27
ich fasse das als Kompliment auf, [...]
:) So war es gemeint gewesen!

Zitat
Nach Anlage von [...] funktioniert die Zeitansage inkl. "hello wold-Experience".
8)

Zitat
partout kein (SetOnOff-/GetOnOff-)Intents gemappt.
Sorry, das war das, was mit "gDT-Mapping ist mir auch was kaputt gegangen gewesen" gemeint gewesen war ::) .

Zur Tonlage noch - falls dir sowas nochmal über den Weg läuft: Bitte nicht zu lange den Fehler bei dir selbst suchen; die offensichtlichen "Wegmarken" prüfen, aber wenn es dann "seltsam wirkt", was das list hergibt => kurze Frage hier, und es sollte sich klären lassen.
(Das Probem war: Ich hatte den gDT-Attribut-Parser erweitert/generalisiert, aber eine Stelle übersehen und dort nicht die (neue) Syntax für den Funktionsaufruf eingebaut, was mir aber selbst nicht direkt aufgefallen war, weil mein "Testgerät" jetzt auch eine "GetState"-Abfrage "kann" und daher ein rhasspyMapping hat (was ich aber zum Zeitpunkt des Testens vergessen hatte...). Sowas kann (leider) vorkommen ::) .

Zitat
Bzgl. Doku:
[...]
Wäre das so okay für Euch?
Aus meiner Warte klingt das sinnvoll (auch wenn ich Grafana nicht im Einsatz und das verlinkte Beispiel auch nur grob überflogen habe).

Aus der Erfahrung mit Doku-Themen allgemein heraus wäre meine Bitte nur, jeweils klarzustellen, auf welche Fassung sich das bezieht, und dass es z.B. für die Rhasspy-(Dienst)-Themen sinnvoll ist, ggf. mal nachzusehen, ob es nicht an der "eigentlichen Quelle" Neuigkeiten gibt. (Es gibt User, die trotz solcher Hinweise meinen, sie hätten einen Anspruch auf fortlaufende Aktualisierungen, statt selbst aktiv zu werden).
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: DrBasch am 26 Mai 2021, 14:28:01
Zitat von: Beta-User am 26 Mai 2021, 12:42:15
[...]Bitte nicht zu lange den Fehler bei dir selbst suchen; die offensichtlichen "Wegmarken" prüfen, aber wenn es dann "seltsam wirkt", was das list hergibt => kurze Frage hier, und es sollte sich klären lassen.
OT: Danke für das "Angebot" ich bleibe aber im Moment lieber noch dabei unerwartetes Verhalten von FHEM/Modulen (ganz allgemein) erstmal selbst zu "untersuchen". Auf die Art und Weise lerne ich von Tag zu Tag ein bisschen mehr über FHEM, Perl und die zugrundeliegenden Datenmodelle/Funktionen.

Zitat
Aus der Erfahrung mit Doku-Themen allgemein heraus wäre meine Bitte nur, jeweils klarzustellen, auf welche Fassung sich das bezieht...
Die Angaben von Versionsnummern hatte ich vor, mit einzupflegen.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 26 Mai 2021, 14:38:35
Zitat von: DrBasch am 26 Mai 2021, 14:28:01
Auf die Art und Weise lerne ich von Tag zu Tag ein bisschen mehr über FHEM, Perl und die zugrundeliegenden Datenmodelle/Funktionen.
Sehr gerne - nach meiner eigenen Erfahrung schadet das nicht (und es ist ggf. auch erlaubt, Fragen dazu zu stellen).

Wie in dem anderen Thread erwähnt, habe ich noch zwei Punkte in dem TimedOnOff-Intenthandler gefunden.

Eventuell diesen Teil tauschen (ungetestet, da war noch ein $value drin und wenn man die aktuelle Zeit nicht am Ende von der Zielzeit abzieht, ergibt das "ziemlich lange" Dauern...):
            my $hour = 0;
            my $now1 = time;
            my $now = $now1;
            my @time = localtime($now);
            if ( defined $data->{Hourabs} ) {
                $hour  = $data->{Hourabs};
                $now1 = $now1 - ($time[2] * HOURSECONDS) - ($time[1] * MINUTESECONDS) - $time[0]; #last midnight
            }
            elsif ($data->{Hour}) {
                $hour = $data->{Hour};
            }
            $now1 += HOURSECONDS * $hour;
            $now1 += MINUTESECONDS * $data->{Min} if $data->{Min};
            $now1 += $data->{Sec} if $data->{Sec};

            $now1 += +DAYSECONDS if $now1 < $now;
            $now1 = $now1 - $now;

            $cmd .= " $now1";
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 27 Mai 2021, 13:22:17
Da ich die Tage vermutlich nicht ans Testen kommen werde, anbei zwei kleinere ungetestete Updates:
- die de-cfg enthält neben zwei fehlenden/neuen Übersetzungen einige kleinere Änderungen, die ich für "gut" hielt (eigentlich wäre es nett, wenn sich jemand mal die Mühe machen würde ggf. bessere Vorschläge zu machen, das ist alles nebenbei und auf die Schnelle entstanden).
Weiter ist eine Art "commandref" enthalten mit einletenden kurzen Erklärungen, für was der jeweilige Bereich gedacht ist.

- Dann ist in SetTimedOnOff der "Schnipsel" von gestern eingearbeitet, allerdings ohne große Tests. Wer nachsehen will, ob die Timer richtig gesetzt wurden, findet (bei den Geräten, die es über SetExtensions machen) die Infos zu dem Timer im list des jeweiligen (Ziel-) Geräts.

- Der Intent SetTimedOnOffGroup ist auch eingearbeitet, allerdings habe ich beim Testen festgestellt, dass hier - wie bei allen Gruppen-Anweisungen bisher - die Angabe des Raums verpflichtend gewesen zu sein scheint. Fand ich nicht so intuitiv und habe daher versucht, das auch auf die "Sprecher-Raum"-Logik umzubiegen, wenn der Room nicht da ist. (Ist komplett ungetestet, sentence.ini folgt ggf. nach eigenen Tests nach dem WE).

Kann also sein, dass das eine oder andere nicht erwartungsgemäß läuft, größere Schwierigkeiten erwarte ich aber nicht (vorausgesetzt, Register.pm ist vorhanden (=>FHEM also up to date), sonst wird das Modul nicht geladen...)
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 27 Mai 2021, 20:14:05
...jetzt hat es doch noch einen Kurztest gereicht...

(Ich habe aber auch ein Talent, mir die ungünstigsten Testbedingungen auszusuchen...)

Kurzfassung: das mit TimedOnOffGroup klappt, sentence.ini wie angekündigt:
[de.fhem:SetTimedOnOff]
(schalt|mach) (den|die|das) $de.fhem.Device-SetOnOff{Device} [in|im|in der|auf der] [$de.fhem.Room{Room}] für [((1..60){Hour!int} (stunde|stunden))] [und] [((1..60){Min!int} (minute|minuten))] [und] [((1..60){Sec!int} (sekunde|sekunden))] $OnOffValue{Value}
(schalt|mach) (den|die|das) $de.fhem.Device-SetOnOff{Device} [in|im|in der|auf der] [$de.fhem.Room{Room}] bis um (0..24){Hourabs!int} uhr [(1..60){Min!int}] $OnOffValue{Value}

[de.fhem:SetTimedOnOffGroup]
(schalt|mach) (den|die|das) $de.fhem.Group-SetOnOff{Group} [in|im|in der|auf der] [$de.fhem.Room{Room}] für [((1..60){Hour!int} (stunde|stunden))] [und] [((1..60){Min!int} (minute|minuten))] [und] [((1..60){Sec!int} (sekunde|sekunden))] $OnOffValue{Value}
(schalt|mach) (den|die|das) $de.fhem.Group-SetOnOff{Group} [in|im|in der|auf der] [$de.fhem.Room{Room}] bis um (0..24){Hourabs!int} uhr [(1..60){Min!int}] $OnOffValue{Value}


Langfassung: Es klappt (mit allen Gruppen-Kommandos) nicht, wenn man Gruppennamen mit Leerzeichen verwendet - jedenfalls dann nicht, wenn die hinten stehen.
Auch sonst bekomme ich die Gruppen nicht unbedingt "ortsübergreifend" angesprochen, aber es wird mir heute/dieses WE wohl nicht reichen rauszufinden, woran das ggf. liegt...

Aber auch so: Ist cool, die Funktion 8) ...
Viel Spaß beim Testen.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 28 Mai 2021, 07:36:07
(erst mal nur als Idee: Eigentlich sollte es möglich sein, identische Sätze zu verwenden und dann intern von der Einzel- auf die Gruppenfunktion umzuleiten, wenn {Device} nicht vorhanden ist und dafür {Group}. Kann aber auch sein, dass das in der Praxis (früher oder später) ein Kuddelmuddel gäbe).
(Vielleicht abschaltbar per tweak?)

Meinungen dazu?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 28 Mai 2021, 08:43:04
Hmm. Ist jetzt nur so ein Bauchgefühl, aber ich tät's getrennt lassen. Wobei das mit dem Tweak schon was hätte. Aber ich tendiere eher dazu, eine Rückmeldung zu bekommen, wenn es ein Gerät nicht gibt. Bevor RHASSPY einfach irgendwas schaltet.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 28 Mai 2021, 09:00:06
Zum "User"-Bereich in der Sprachdatei: Ist der wirklich brauchbar? Ich mein, bei einem Update muss ich sowieso editieren. Da kann ich doch gleich auch meine "alten" Sätze wieder rein bauen. Einfacher ist's zwar. Aber angreifen muss ich's sowieso. Wär's da nicht praktischer, wir liefern eine Standard-Datei, binden aber auch zusätzlich Dateien ein, die ähnlich heißen (rhasspy-de-user.cfg z.B.)?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 28 Mai 2021, 10:08:20
Moment mal. Bei SetTimedOnOff wird bei mir das Licht IN fünf Sekunden eingeschaltet. Und nicht FÜR fünf Sekunden. Soll das so sein?

Liegt an meinem Test-Device
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Ziton am 28 Mai 2021, 10:50:57
Hallo zusammen,

ich würde gerne mit Tests unterstützen bin aber noch zu sehr mit mir selbst beschäftigt. Musste mein rhasspy nochmal neu aufsetzen weil ich irgendwas kaputt konfiguriert habe
beim Versuch die Leds meines respeaker ans laufen zu bekommen.

In meinem Kopf schweben noch folgende Fragen, vielleicht kann mir die jemand von euch beantworten.
Ist es möglich für ausgewählte Intents eine Bestätigung einzufordern? Gelegentlich aktiviert sich Rhasspy selbst und erkennt einen Sprachbefehl obwohl nahezu stille im Raum herrscht.
Oft nicht weiter schlimm aber bei dem ein oder anderen Schaltbefehl wäre es mir lieber wenn rhasspy vorher nochmal nachfragt.

Gibt es eine Empfehlung welchen Weg man beschreiten sollte wenn ich Rhasspy in mehreren Räumen einsetzen möchte?
Ich tendiere zur Zeit eher dazu Satellites aufzusetzen. Dann hat man die Sprachkonfiguration an einer Stelle. Derzeit gibt es aber, soweit ich es durchblicke, keine Möglichkeit einen "room <-> siteID" Mapping vorzunehmen oder? Ist so etwas ggf. noch in Planung?

Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 28 Mai 2021, 10:59:31
Zitat von: Ziton am 28 Mai 2021, 10:50:57
Gibt es eine Empfehlung welchen Weg man beschreiten sollte wenn ich Rhasspy in mehreren Räumen einsetzen möchte?
Ich tendiere zur Zeit eher dazu Satellites aufzusetzen. Dann hat man die Sprachkonfiguration an einer Stelle. Derzeit gibt es aber, soweit ich es durchblicke, keine Möglichkeit einen "room <-> siteID" Mapping vorzunehmen oder? Ist so etwas ggf. noch in Planung?

Doch, gibt's. Du musst die Satelliten in deren Web-GUI nur so benennen, wie der Raum heißt, in dem deine Geräte sind. Also so, wie das FHEM-room oder FHEM-rhasspyRoom Attribut heißt. Meine Satelliten heißen z.B. "wohnzimmer", "küche" und "vorraum".

Willst du mehrere Satelliten im selben Raum haben kannst du die z.B. so benennen: "wohnzimmer.sofa", "wohnzimmer.esstisch", etc. Das ist eine Option von Rhasspy, das Modul sollte damit umgehen können. Ich hab das aber noch nicht getestet.

Bei deiner ersten Frage bin ich mir fast ganz sicher, dass das geht. Ich hoffe aber, da kann sich Beta-User dazu äußern.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 28 Mai 2021, 12:00:17
Szenen:

Mein Slot "de.fhem.Scenes" (automatisch erstellt) sieht richtig so aus:

( Esslicht ){Scene:Esslicht}
( AllesAn ){Scene:AllesAn}
( Schlummerlicht ){Scene:Schlummerlicht}
( AllesAus ){Scene:AllesAus}
( DunklesFernsehlicht ){Scene:DunklesFernsehlicht}
( Fernsehlicht ){Scene:Fernsehlicht}
( Computerlicht ){Scene:Computerlicht}


Sobald ich aber ein HUE-Device von RHASSPY steuern lasse (also in den Raum Rhasspy stelle), werden alle HUE Lichtszenen (die von der Bridge automatisch erstellt werden) zu Rhasspy übertragen. Und das leider nicht richtig. Der Slot sieht dann so aus:

( Konzentrieren#[id=kcz2eYl2goK91Hz] ){Scene:Konzentrieren#[id=kcz2eYl2goK91Hz]}
( Esslicht ){Scene:Esslicht}
( Gedimmt#[id=nEY-TZ2qVEx6WpP] ){Scene:Gedimmt#[id=nEY-TZ2qVEx6WpP]}
( Tropendämmerung#[id=Li5XQV2Ckvcl9ac] ){Scene:Tropendämmerung#[id=Li5XQV2Ckvcl9ac]}
( Konzentrieren#[id=ig9Hb2jZ6iP9X0E] ){Scene:Konzentrieren#[id=ig9Hb2jZ6iP9X0E]}
( Energie#tanken#[id=ykGAH5vm9qguUhm] ){Scene:Energie#tanken#[id=ykGAH5vm9qguUhm]}
( Frühlingsblüten#[id=amg18-TICTPiayR] ){Scene:Frühlingsblüten#[id=amg18-TICTPiayR]}
( Lesen#[id=qk7qNpKVeugEugh] ){Scene:Lesen#[id=qk7qNpKVeugEugh]}
( Sonnenuntergang#Savanne#[id=J88yqZyARhlQh4q] ){Scene:Sonnenuntergang#Savanne#[id=J88yqZyARhlQh4q]}
( Hell#[id=QszaD6316SsOGNX] ){Scene:Hell#[id=QszaD6316SsOGNX]}
( Tropendämmerung#[id=1a6rDrpjg-i33u8] ){Scene:Tropendämmerung#[id=1a6rDrpjg-i33u8]}
( Hell#[id=Kd35TY8qIb6pTax] ){Scene:Hell#[id=Kd35TY8qIb6pTax]}
( Sonnenuntergang#Savanne#[id=968VgE7b29JysiY] ){Scene:Sonnenuntergang#Savanne#[id=968VgE7b29JysiY]}
( AllesAus ){Scene:AllesAus}
( Frühlingsblüten#[id=fmsyN3Ve4fYGqhG] ){Scene:Frühlingsblüten#[id=fmsyN3Ve4fYGqhG]}
( DunklesFernsehlicht ){Scene:DunklesFernsehlicht}
( Nachtlicht#[id=0F5VwJFcHpymkm2] ){Scene:Nachtlicht#[id=0F5VwJFcHpymkm2]}
( Fernsehlicht ){Scene:Fernsehlicht}
( Nachtlicht#[id=yJ0tWdBhE-emL3q] ){Scene:Nachtlicht#[id=yJ0tWdBhE-emL3q]}
( Nordlichter#[id=lk39fWLRdxjTqVl] ){Scene:Nordlichter#[id=lk39fWLRdxjTqVl]}
( Sonnenuntergang#Savanne#[id=SOcyx8ZWLqI73MR] ){Scene:Sonnenuntergang#Savanne#[id=SOcyx8ZWLqI73MR]}
( Tropendämmerung#[id=yzMdTFOtJPAIVel] ){Scene:Tropendämmerung#[id=yzMdTFOtJPAIVel]}
( Konzentrieren#[id=WGjGSBvWPfW0JH0] ){Scene:Konzentrieren#[id=WGjGSBvWPfW0JH0]}
( Entspannen#[id=gbca4wF9Vni8oSb] ){Scene:Entspannen#[id=gbca4wF9Vni8oSb]}
( Gedimmt#[id=oZRhLrscoEgC7Xu] ){Scene:Gedimmt#[id=oZRhLrscoEgC7Xu]}
( Nachtlicht#[id=Ke4VCTMCsSNaIli] ){Scene:Nachtlicht#[id=Ke4VCTMCsSNaIli]}
( Entspannen#[id=MkBqmt1iphIRayB] ){Scene:Entspannen#[id=MkBqmt1iphIRayB]}
( Energie#tanken#[id=1N0Ow9IjFvwJWOb] ){Scene:Energie#tanken#[id=1N0Ow9IjFvwJWOb]}
( AllesAn ){Scene:AllesAn}
( Entspannen#[id=g9hPzEGZkAR2g5j] ){Scene:Entspannen#[id=g9hPzEGZkAR2g5j]}
( Schlummerlicht ){Scene:Schlummerlicht}
( Frühlingsblüten#[id=wZdk5cpy35oldlw] ){Scene:Frühlingsblüten#[id=wZdk5cpy35oldlw]}
( Gedimmt#[id=7r1VzbwX5H5VVqW] ){Scene:Gedimmt#[id=7r1VzbwX5H5VVqW]}
( Energie#tanken#[id=iJiMFXkE57qvCJ7] ){Scene:Energie#tanken#[id=iJiMFXkE57qvCJ7]}
( Lesen#[id=s-co9adxMQsAsEz] ){Scene:Lesen#[id=s-co9adxMQsAsEz]}
( Nordlichter#[id=UloxktBtdsVJEUg] ){Scene:Nordlichter#[id=UloxktBtdsVJEUg]}
( Hell#[id=jJAU3n8QlDZI4Zh] ){Scene:Hell#[id=jJAU3n8QlDZI4Zh]}
( Lesen#[id=IYY-Qkhs6577mil] ){Scene:Lesen#[id=IYY-Qkhs6577mil]}
( Nordlichter#[id=l9gNnheN-NwDIgY] ){Scene:Nordlichter#[id=l9gNnheN-NwDIgY]}
( Computerlicht ){Scene:Computerlicht}


Training wirft somit sofort einen Fehler.

Wie kommt RHASSPY drauf, dass das gültige Szenen sind?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Ziton am 29 Mai 2021, 13:12:49
Hallo,

ich habe jetzt auch ein komisches Phänomen und komme nicht auf das Problem.

Mein SetOnOff Intent quittiert jetzt alles mit "Das ist leider etwas schief gegangen". Feststellen kann ich das Problem erst seit ich einen Satallite mit der siteID "kueche" erstellt habe und die siteId des "servers" auf "wohnzimmer" umbenannt habe. Soweit ich das überblicken kann funktioniert die Kommunikation auch problemlos. SetNumeric oder MediaControls Intents funktionieren in beiden Räumen.

Auszug aus dem Logfile beim Versuch das Gerät "receiver" aus dem Raum Wohnzimmer einzuschalten:

2021.05.29 12:59:14 3: CUL_HM set Th.Rm.00 statusRequest noArg
2021.05.29 12:59:24 5: RHASSPY: [RhasspyTK] Parse (IO: Mqtt.Rhasspy): Msg: hermes/dialogueManager/sessionStarted => {"sessionId": "wohnzimmer-bumblebee_raspberry-pi-6fe55acf-db37-467d-8c9c-8dfd75bb66c5", "siteId": "wohnzimmer", "customData": "bumblebee_raspberry-pi", "lang": null}
2021.05.29 12:59:24 5: Parsed value: wohnzimmer-bumblebee_raspberry-pi-6fe55acf-db37-467d-8c9c-8dfd75bb66c5 for key: sessionId
2021.05.29 12:59:24 5: Parsed value: wohnzimmer for key: siteId
2021.05.29 12:59:24 5: Parsed value: bumblebee_raspberry-pi for key: customData
2021.05.29 12:59:24 5: room is identified using siteId as wohnzimmer
2021.05.29 12:59:27 5: RHASSPY: [RhasspyTK] Parse (IO: Mqtt.Rhasspy): Msg: hermes/intent/de.fhem_SetOnOff => {"input": "receiver on", "intent": {"intentName": "de.fhem:SetOnOff", "confidenceScore": 1.0}, "siteId": "wohnzimmer", "id": null, "slots": [{"entity": "de.fhem.Device", "value": {"kind": "Unknown", "value": "receiver"}, "slotName": "Device", "rawValue": "receiver", "confidence": 1.0, "range": {"start": 0, "end": 8, "rawStart": 0, "rawEnd": 8}}, {"entity": "value", "value": {"kind": "Unknown", "value": "on"}, "slotName": "value", "rawValue": "einschalten", "confidence": 1.0, "range": {"start": 9, "end": 11, "rawStart": 9, "rawEnd": 20}}], "sessionId": "wohnzimmer-bumblebee_raspberry-pi-6fe55acf-db37-467d-8c9c-8dfd75bb66c5", "customData": "bumblebee_raspberry-pi", "asrTokens": [[{"value": "receiver", "confidence": 1.0, "rangeStart": 0, "rangeEnd": 8, "time": null}, {"value": "on", "confidence": 1.0, "rangeStart": 9, "rangeEnd": 11, "time": null}]], "asrConfidence": 0.999297532, "rawInput": "receiver einschalten", "wakewordId": "bumblebee_raspberry-pi", "lang": null}
2021.05.29 12:59:27 5: Parsed value: SetOnOff for key: intent
2021.05.29 12:59:27 5: Parsed value: receiver on for key: input
2021.05.29 12:59:27 5: Parsed value: receiver for key: Device
2021.05.29 12:59:27 5: Parsed value: bumblebee_raspberry-pi for key: customData
2021.05.29 12:59:27 5: Parsed value: wohnzimmer for key: siteId
2021.05.29 12:59:27 5: Parsed value: 1 for key: probability
2021.05.29 12:59:27 5: Parsed value: on for key: value
2021.05.29 12:59:27 5: Parsed value: receiver einschalten for key: rawInput
2021.05.29 12:59:27 5: Parsed value: wohnzimmer-bumblebee_raspberry-pi-6fe55acf-db37-467d-8c9c-8dfd75bb66c5 for key: sessionId
2021.05.29 12:59:27 5: handleIntentSetOnOff called
2021.05.29 12:59:27 5: Device = receiver
2021.05.29 12:59:27 5: Value =
2021.05.29 12:59:27 5: Response is: Da ist leider etwas schief gegangen


Die beiden Logzeilen Device = ... und Value = ... habe ich eingefügt um mich dem Problem zu nähern. Anscheinend ist kein Wert enthalten. Da steigt mein Verständnis jetzt aber leider aus. Weiter oben steht "Parsed value: on for key: value"
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 29 Mai 2021, 15:19:15
Kannst du bitte ein RAW Listing vom Device schicken?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Ziton am 29 Mai 2021, 15:33:52
Raw list im Anhang
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 29 Mai 2021, 15:41:31
Hmm, seh auf die Schnelle nichts ungewöhnliches. Kannst du mir bitte auch noch ein List vom Wz.VSX_S510 schicken?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Ziton am 29 Mai 2021, 15:45:02
Ebenfalls im Anhang

Das Device spielt aber kein Rolle. SetOnOff funktioniert derzeit mit keinem Device.

Ein bisschen seltsam...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 29 Mai 2021, 15:52:34
Schräg! Welche Version vom Modul?

Und kannst du bitte nur zum Testen ein SetOnOff-Mapping setzten? (SetOnOff:cmdOn=on,cmdOff=off)
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Ziton am 30 Mai 2021, 11:38:51
Modul Version ist jetzt die letzte 0.4.16
Hatte das Problem aber auch mit der 0.4.12 ... Wollte ausschließen das es an der Version liegt  :)
Aber mit der 0.4.12 hat es schon funktioniert. Wie gesagt bevor ich den Satallite hinzugefügt habe. Kann mir aber nicht erklären warum das bisher nur zu einem Problem beim SetOnOff Intent führt und
nicht bei den anderen. Habe grade nochmal ein de.fhem:GetOnOff getestet. Das scheint auch zu funktionieren.

Achso das Mapping einzufügen hat keinen Unterschied gemacht. Hatte das testweise zuvor auch schon mal probiert.

Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 30 Mai 2021, 12:02:45
Gibt auf GitHub in der dev-Branch eine Version 0.4.17 (https://github.com/fhem/fhem-rhasspy/blob/dev/FHEM/10_RHASSPY.pm). Bzw. auch hier: https://forum.fhem.de/index.php/topic,119447.msg1159345.html#msg1159345.
Kannst du die bitte mal versuchen?

Aber so grundsätzlich versteh ich das eh nicht. Es hat mal funktioniert. Mit 0.4.12 ohne Satellit. Richtig?
Dann hast du die siteIDs von Rhasspy (Base + Satellit) geändert. Und seit dem geht's nicht mehr. Richtig?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Ziton am 30 Mai 2021, 12:32:15
Ja genau
Zumindest ist mir ansonsten keine weitere Änderung eingefallen.
Habe auch den Sentence für SetOnOff nochmal auf ein sehr einfaches Schema gesetzt um das auszuschließen. Aber auf Rhasspy Seite werten die Tags alle korrekt erkannt.

0.4.17 funktioniert leider auch nicht

Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 30 Mai 2021, 13:28:56
In deinem RHASSPY-Device gibt's nur die siteId "kueche". Mach mal ein set xxxx fetchSiteIds. Und gerade auch noch ein set xxx update all zur Sicherheit.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Ziton am 30 Mai 2021, 13:59:29
Hat keine Veränderung gebracht
Ich vermute das über den Befehl nur siteid's von Satellites übertragen werden?!
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 30 Mai 2021, 14:05:41
Das stimmt natürlich. Und das ist irgendwie nicht schlau. Bei mir ist die Base ohne Audiogeräte und rechnet nur. Deswegen hab ich nie daran gedacht, dass die Base vielleicht auch Befehle entgegen nimmt.

Funktionieren Geräte in der "kueche"?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Ziton am 30 Mai 2021, 14:19:07
Geräte in der Küche funktionieren gleichermaßen alle bisher eingerichteten Befehle mit Ausnahme von SetOnOff

Das heißt in beiden Räumen funktionieren derzeit Befehle für:
GetOnOff
SetNumeric
MediaChannels
GetTime
GetWeekDay
SetTimer
SetMute
ReSpeak

Der Problem ist irgendwie schwer auszumachen. Wie gesagt es scheint als würde er beim Unterprogramm "sub handleIntentSetOnOff" aussteigen weil kein Value vorhanden ist. Aber ich verstehe nicht warum bzw. wo er den Wert verliert.

Nun ja jetzt geht es erstmal ein bisschen in die Sonne. Ich danke dir sehr für deine Unterstützung.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 31 Mai 2021, 09:53:53
Zitat von: Ziton am 29 Mai 2021, 13:12:49
Die beiden Logzeilen Device = ... und Value = ... habe ich eingefügt um mich dem Problem zu nähern. Anscheinend ist kein Wert enthalten. Da steigt mein Verständnis jetzt aber leider aus. Weiter oben steht "Parsed value: on for key: value"

Hab's! Du hast "{value}" in deinen Sentences klein geschrieben, kann das sein? Da muss ein großes "V" hin ({Value})
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 31 Mai 2021, 10:41:09
Zitat von: drhirn am 31 Mai 2021, 09:53:53
Hab's! Du hast "{value}" in deinen Sentences klein geschrieben, kann das sein? Da muss ein großes "V" hin ({Value})
Jedenfalls war auch in dem JSON-Blob nur ein kleines "value" enthalten, und damit funktioniert es nicht. (Das hat höchstens mal mit einer sehr alten Fassung funktioniert.

(ad Doku: Weiß nicht, ob wir irgendwo stehen haben, wie die Formate im einzelnen "üblicherweise" sind => JSON-Keywords beginnen alle mit Großbuchstaben?)

Zitat von: drhirn am 28 Mai 2021, 12:00:17
Wie kommt RHASSPY drauf, dass das gültige Szenen sind?
Nun ja, es gibt in dem Device einen entsprechenden scene-Setter...

Im Anhang eine Fassung, die daraus "sprechbare" Scenen-Namen macht und das dann auch ohne händische Eingriffe (wäre via "specials" zu korrigieren gewesen) so an Rhasspy übergibt, dass es zumindest keine Fehler werfen sollte.

Habe jetzt mal zum einen cref zu diesem "special" erweitert und die Option eingebaut, einfach alle Szenen an einem "szenen-fähigen" Device zu deaktivieren, indem man da "all=none" setzt.



In der angehängten Fassung könnte dann auch mein Problem mit der "Leerzeichengruppe" gelöst sein (ich vermute, es war weniger das Leerzeichen, und eher der Umstand, dass das die letzte Gruppe in den verfügbaren Gruppen war => erweiterte Regex sollte das lösen, ist ungetestet)

Zitat von: drhirn am 28 Mai 2021, 08:43:04
Hmm. Ist jetzt nur so ein Bauchgefühl, aber ich tät's getrennt lassen. Wobei das mit dem Tweak schon was hätte. Aber ich tendiere eher dazu, eine Rückmeldung zu bekommen, wenn es ein Gerät nicht gibt. Bevor RHASSPY einfach irgendwas schaltet.
Na ja, beide sentences unterscheiden sich nur in Nuancen, und die Frage ist eher, ob man "versehentliches Heranziehen" des falschen Intents durch Rhasspy damit überspielen möchte. Es passiert ja trotzdem nicht "irgendwas", sondern (hoffentlich) das, was der Sprecher eigentlich erreichen möchte (in der Regel weiß er ja gar nicht (mehr), ob er jetzt ein Einzeldevice schaltet oder eine Gruppe - oder anders formuliert: idealerweise muss er sich das nicht merken ;) ).

Zitat von: drhirn am 28 Mai 2021, 09:00:06
Zum "User"-Bereich in der Sprachdatei: Ist der wirklich brauchbar? Ich mein, bei einem Update muss ich sowieso editieren. Da kann ich doch gleich auch meine "alten" Sätze wieder rein bauen. Einfacher ist's zwar. Aber angreifen muss ich's sowieso. Wär's da nicht praktischer, wir liefern eine Standard-Datei, binden aber auch zusätzlich Dateien ein, die ähnlich heißen (rhasspy-de-user.cfg z.B.)?
Was bedeutet "brauchbar"?
Falls "funktional": ja
Falls "die beste Lösung": Weiß nicht, aber wenn man es aus framework-Gesichtspunkten heraus beurteilt vermutlich schon. configDB kann beim Konvertieren afaik nur genau eine configfile übernehmen...
Anders gewendet: Ich fürchte mehr User-Fehler, wenn wir das auf mehr Konfigurationsmöglichkeiten verteilen, und halte das mit den verschiedenen Bereichen daher auch aus diesem Grund für (im Ergebnis) einfacher.

Zitat von: Ziton am 28 Mai 2021, 10:50:57
Ist es möglich für ausgewählte Intents eine Bestätigung einzufordern? Gelegentlich aktiviert sich Rhasspy selbst und erkennt einen Sprachbefehl obwohl nahezu stille im Raum herrscht.
Oft nicht weiter schlimm aber bei dem ein oder anderen Schaltbefehl wäre es mir lieber wenn rhasspy vorher nochmal nachfragt.
Generelle Bestätigungsmöglichkeiten sind derzeit noch nicht implementiert, das Interesse war bisher nicht übermäßig groß. (bei shortcuts geht das aber!)
Sowas (vollends) zu implementieren dürfte nicht allzu schwierig sein, ist aber Aufwand, auch beim Testen. Falls größeres Interesse besteht, würde ich das mal auf die Agenda nehmen... (Mein persönliches Problem, das mit in diese Richtung geschubst hatte, ist jetzt eher dadurch gelöst, dass mehr Slots zur Verfügung stehen, so dass Rhasspy "treffsicherer" ist).

Zitat
Gibt es eine Empfehlung welchen Weg man beschreiten sollte wenn ich Rhasspy in mehreren Räumen einsetzen möchte?
Ich tendiere zur Zeit eher dazu Satellites aufzusetzen. Dann hat man die Sprachkonfiguration an einer Stelle. Derzeit gibt es aber, soweit ich es durchblicke, keine Möglichkeit einen "room <-> siteID" Mapping vorzunehmen oder? Ist so etwas ggf. noch in Planung?

Bevorzugte Lösung wäre der Vorschlag von drhirn hier, und es wäre klasse, wenn jemand, der das mit der Gruppenoption nutzt Rückmeldung geben könnte, dass es funktioniert wie gedacht:
Zitat von: drhirn am 28 Mai 2021, 10:59:31
Doch, gibt's. Du musst die Satelliten in deren Web-GUI nur so benennen, wie der Raum heißt, in dem deine Geräte sind. Also so, wie das FHEM-room oder FHEM-rhasspyRoom Attribut heißt. Meine Satelliten heißen z.B. "wohnzimmer", "küche" und "vorraum".

Willst du mehrere Satelliten im selben Raum haben kannst du die z.B. so benennen: "wohnzimmer.sofa", "wohnzimmer.esstisch", etc. Das ist eine Option von Rhasspy, das Modul sollte damit umgehen können. Ich hab das aber noch nicht getestet.
Es gibt aber noch eine weitere Variante: Über ein spezielles Reading, Details finden sich (hoffentlich) in der cref der myUtils-Funktion für "fliegende Satelliten", das feature kann man aber auch ohne den myUtils-Code nutzen.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Ziton am 31 Mai 2021, 11:15:06
Zitat von: drhirn am 31 Mai 2021, 09:53:53
Hab's! Du hast "{value}" in deinen Sentences klein geschrieben, kann das sein? Da muss ein großes "V" hin ({Value})
Kleiner Fehler großer Wirkung!
Ich bedanke mich fürs finden und entschuldige mich für die Umstände. Ich kann zumindest versichern, dass der Fehler bei mir nicht mehr vorkommen wird  :D

Zitat von: Beta-User am 31 Mai 2021, 10:41:09
Generelle Bestätigungsmöglichkeiten sind derzeit noch nicht implementiert, das Interesse war bisher nicht übermäßig groß. (bei shortcuts geht das aber!)
Sowas (vollends) zu implementieren dürfte nicht allzu schwierig sein, ist aber Aufwand, auch beim Testen. Falls größeres Interesse besteht, würde ich das mal auf die Agenda nehmen... (Mein persönliches Problem, das mit in diese Richtung geschubst hatte, ist jetzt eher dadurch gelöst, dass mehr Slots zur Verfügung stehen, so dass Rhasspy "treffsicherer" ist).

Habe gesehen das mit der letzten Version mehr Slots erzeugt werden. Ich werde daraufhin meine Sentences auch nochmal untersuchen und ggf. anpassen. (natürlich immer mit {Value} ;D )

Zitat von: Beta-User am 31 Mai 2021, 10:41:09
Bevorzugte Lösung wäre der Vorschlag von drhirn hier, und es wäre klasse, wenn jemand, der das mit der Gruppenoption nutzt Rückmeldung geben könnte, dass es funktioniert wie gedacht
Habe es so umgesetzt wie von drhirn vorgeschlagen. Gruppen Funktionen habe ich noch nicht in Gebrauch. Vielleicht schaffe ich es sie diese Woche mal auszuprobieren.

Zum Abschluss noch eine Frage zur Sprachdatei. Wo muss ich die Übersetzung für $weekDay hinpacken? Die werden nämlich derzeit noch auf Englisch mit deutscher Aussprache ausgegeben :)
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 31 Mai 2021, 11:26:26
Zitat von: Ziton am 31 Mai 2021, 11:15:06
Kleiner Fehler großer Wirkung!
Ich bedanke mich fürs finden und entschuldige mich für die Umstände. Ich kann zumindest versichern, dass der Fehler bei mir nicht mehr vorkommen wird  :D
:) Nevermind; wir alle stolpern hin und wieder über solche "Kleinigkeiten"... (ich zumindest)

Zitat
Habe gesehen das mit der letzten Version mehr Slots erzeugt werden. Ich werde daraufhin meine Sentences auch nochmal untersuchen und ggf. anpassen. (natürlich immer mit {Value} ;D )
Bin mal gespannt, wie sich das bei dir auswirkt. (Ich verwende bisher kein wakeup-word, aber deine Probleme scheinen _auch_ typisch zu sein, wenn das zu viele false positives bringt => sensitivity anpassen)

Zitat
Zum Abschluss noch eine Frage zur Sprachdatei. Wo muss ich die Übersetzung für $weekDay hinpacken? Die werden nämlich derzeit noch auf Englisch mit deutscher Aussprache ausgegeben :)
Ausgegeben wird, was das hier liefert:
strftime( '%A', localtime );
Bin nicht sicher, nach welchen Kriterien das arbeitet, aber an irgendeiner Stelle ist dein FHEM nicht "deutsch".

@drhirn:
Das ist trotzdem ein Problem, weil eben grade nicht international... (=> Problem auf mehrsprachigen Systemen). Habe allerdings auch grade keine Idee, wie man das besser machen könnte... Müßte man ggf. auch bei Gelegenheit mal auf $wday anpassen....
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 31 Mai 2021, 11:26:43
Zitat von: Ziton am 31 Mai 2021, 11:15:06
Zum Abschluss noch eine Frage zur Sprachdatei. Wo muss ich die Übersetzung für $weekDay hinpacken? Die werden nämlich derzeit noch auf Englisch mit deutscher Aussprache ausgegeben :)

weekDay hat nichts mit der Sprachdatei zu tun. Der nimmt die Spracheinstellung des Systems (OS, Perl). Ist nicht ganz optimal gelöst. War damals von mir aber auch nur ein Test-Intent, der irgendwie geblieben ist ;D.
Ich wollte gerade testen, was genau du umstellen musst. Ich kann's dir leider nicht sagen, bei mir ist und bleibt die Ausgabe deutsch (beim FHEM-Docker-Image).
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 31 Mai 2021, 11:28:58
Zitat von: Beta-User am 31 Mai 2021, 11:26:26
:) Nevermind; wir alle stolpern hin und wieder über solche "Kleinigkeiten"... (ich zumindest)
Ich auch ;D

Zitat@drhirn:
Das ist trotzdem ein Problem, weil eben grade nicht international... (=> Problem auf mehrsprachigen Systemen). Habe allerdings auch grade keine Idee, wie man das besser machen könnte... Müßte man ggf. auch bei Gelegenheit mal auf $wday anpassen....
Wie eben geschrieben, ist nicht optimal. Aber es war eh der Wunsch, da ein ganzes Datum als Ausgabe zu bekommen. Wäre auch sinnvoller. Sollte ich dazu kommen, baue ich das dann gleich richtig ein und um.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Raemsna am 31 Mai 2021, 11:34:43
Weil ich grad bei den Rhasspy Threads interessiert mitlese und Wochentag o.Ä. gelesen habe.

Bin auch so bisschen am Überlegen, wie ich mir Termine in meine Kalender per Spracheingabe legen kann.
Bin da gestern über folgendes gestolpert (kennt ihr wahrscheinlich schon):

https://snips-nlu.readthedocs.io/en/latest/builtin_entities.html (https://snips-nlu.readthedocs.io/en/latest/builtin_entities.html)

https://rhasspy.readthedocs.io/en/latest/intent-recognition/#snips-nlu (https://rhasspy.readthedocs.io/en/latest/intent-recognition/#snips-nlu)

Das sollte auch in Rhasspy genutzt werden können und vereinfacht vielleicht viele Themen (auch wenn es aktuell nicht alles auch auf Deutsch gibt):

AmountOfMoney snips/amountOfMoney Grammar Entity de, en, es, fr, it, ja, ko, pt_br, pt_pt
Duration snips/duration Grammar Entity de, en, es, fr, it, ja, ko, pt_br, pt_pt
Number snips/number Grammar Entity de, en, es, fr, it, ja, ko, pt_br, pt_pt
Ordinal snips/ordinal Grammar Entity de, en, es, fr, it, ja, ko, pt_br, pt_pt
Temperature snips/temperature Grammar Entity de, en, es, fr, it, ja, ko, pt_br, pt_pt
Datetime snips/datetime Grammar Entity de, en, es, fr, it, ja, ko, pt_br, pt_pt
Date snips/date Grammar Entity en
Time snips/time Grammar Entity en
DatePeriod snips/datePeriod Grammar Entity en
TimePeriod snips/timePeriod Grammar Entity en
Percentage snips/percentage Grammar Entity de, en, es, fr, it, ja, pt_br, pt_pt
MusicAlbum snips/musicAlbum Gazetteer Entity de, en, es, fr, it, ja, pt_br, pt_pt
MusicArtist snips/musicArtist Gazetteer Entity de, en, es, fr, it, ja, pt_br, pt_pt
MusicTrack snips/musicTrack Gazetteer Entity de, en, es, fr, it, ja, pt_br, pt_pt
City snips/city Gazetteer Entity de, en, es, fr, it, ja, pt_br, pt_pt
Country snips/country Gazetteer Entity de, en, es, fr, it, ja, pt_br, pt_pt
Region snips/region Gazetteer Entity de, en, es, fr, it, ja, pt_br, pt_pt
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 31 Mai 2021, 11:50:17
Habe mir das mit den Wochentagen mal angesehen, und jetzt erst mal eine etwas andere Lösung eingebaut:

"localtime" wird weiter genutzt, aber wer es braucht, kann einen speziellen Bereich "words" in "user" nutzen, um das Ergebnis umzumappen, das das liefert:

"user":
{
  "responses": {
    "DefaultConfirmation": "Gerne!",
    "DefaultError": "Da paßt irgend was nicht"
  },
  "words": {
    "Monday": "Montag",
    "Tuesday": "Dienstag",
    "Wednesday": "Mittwoch",
    "Thursday": "Montag",
    "Friday": "Freitag",
    "Saturday": "Samstag",
    "Sunday": "Sonntag"
  }
},

An sich sollte das sowohl hinreichend sein für User, die mehrere Sprachen parallel brauchen, wie auch für die, die - aus welchen Gründen auch immer - das System auf en lassen wollen, aber de-Ausgaben haben möchten.

(Wiederfinden wird Freude machen...)

(Ob man Rhasspy auch bei der Ausgabe bewegen kann, bestimmte Dinge zu übersetzen, wäre auch so eine Frage, mit der ich mich bisher nicht beschäftigt hatte...).
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 31 Mai 2021, 12:39:30
Dann gleich so, da ist dann das ganze Datum dabei ;)


# Handle incoming "GetWeekday" intents
sub handleIntentGetWeekday {
    my $hash = shift // return;
    my $data = shift // return;

    Log3($hash->{NAME}, 5, "handleIntentGetWeekday called");

    my $weekDay  = strftime( '%A', localtime );
    $weekDay  = $hash->{helper}{lng}{words}->{$weekDay} if defined $hash->{helper}{lng}{words}->{$weekDay};
    my $month = strftime( '%B', localtime );
    $month  = $hash->{helper}{lng}{words}->{$month} if defined $hash->{helper}{lng}{words}->{$month};
    my $year = strftime( '%G', localtime );
    my $day = strftime( '%e', localtime );
    my $response = $hash->{helper}{lng}->{responses}->{weekdayRequest};
    $response =~ s{(\$\w+)}{$1}eegx;

    Log3($hash->{NAME}, 5, "Response: $response");

    # Send voice reponse
    return respond ($hash, $data->{requestType}, $data->{sessionId}, $data->{siteId}, $response);
}


Neue Version von 10_RHASSPY.pm und rhasspy-de.cfg ist im dev-Branch (https://github.com/fhem/fhem-rhasspy/tree/dev) auf GitHub.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 31 Mai 2021, 12:56:16
Zitat von: Beta-User am 31 Mai 2021, 10:41:09
Nun ja, es gibt in dem Device einen entsprechenden scene-Setter...

Im Anhang eine Fassung, die daraus "sprechbare" Scenen-Namen macht und das dann auch ohne händische Eingriffe (wäre via "specials" zu korrigieren gewesen) so an Rhasspy übergibt, dass es zumindest keine Fehler werfen sollte.

Habe jetzt mal zum einen cref zu diesem "special" erweitert und die Option eingebaut, einfach alle Szenen an einem "szenen-fähigen" Device zu deaktivieren, indem man da "all=none" setzt.

Also, "all=none" tut. Die Szenen-Namen kommen leider noch immer falsch an.

( Frühlingsblüten ){Scene:Frühlingsblüten#[id=wZdk5cpy35oldlw]}


Woher kommt der Scene-Setter bei dem Device?


Internals:
   DEF        6  IODev=hueBridge2
   FUUID      60250efd-f33f-dc90-065c-6bf31c51dc378fac
   FVERSION   31_HUEDevice.pm:0.239120/2021-03-08
   ID         6
   INTERVAL   
   IODev      hueBridge2
   NAME       HUEDevice6
   NR         325
   STATE      off
   TYPE       HUEDevice
   desired    0
   manufacturername dresden elektronik
   modelid    FLS-H3
   name       Color temperature light 1
   swversion  020C.20000053
   type       Color temperature light
   uniqueid   00:21:2e:ff:ff:00:5a:3e-0a
   READINGS:
     2021-05-28 11:16:00   IODev           hueBridge2
     2021-05-28 11:16:06   alert           select
     2021-05-28 11:16:06   bri             254
     2021-05-28 11:16:06   colormode       ct
     2021-05-28 11:16:06   ct              500 (2000K)
     2021-05-30 23:18:23   onoff           0
     2021-05-30 23:18:23   pct             0
     2021-05-28 11:16:06   reachable       1
     2021-05-28 11:16:06   rgb             ffb16e
     2021-05-30 23:18:23   state           off
   helper:
     alert      select
     battery    -1
     bri        254
     colormode  ct
     ct         500
     devtype   
     effect     
     hue        -1
     lastseen   
     mode       
     on         0
     pct        0
     reachable  1
     rgb        ffb16e
     sat        -1
     update_timeout 1
     xy         
     json:
       manufacturername dresden elektronik
       modelid    FLS-H3
       name       Color temperature light 1
       productname Color temperature light
       swversion  020C.20000053
       type       Color temperature light
       uniqueid   00:21:2e:ff:ff:00:5a:3e-0a
       capabilities:
         control:
           ct:
             max        500
             min        153
         streaming:
       config:
         archetype  classicbulb
         direction  omnidirectional
         function   functional
       state:
         alert      select
         bri        254
         colormode  ct
         ct         500
         mode       homeautomation
       swupdate:
         lastinstall 2021-02-11T11:02:22
         state      notupdatable
Attributes:
   IODev      hueBridge2
   alias      Stehlampe
   color-icons 2
   devStateIcon {(HUEDevice_devStateIcon($name),"toggle")}
   genericDeviceType light
   group      Wohnzimmer
   icon       hue_filled_lightstrip
   model      FLS-H3
   rhasspyRoom wohnzimmer
   room       Beleuchtung,HUEDevice,Rhasspy,Wohnzimmer->Licht
   subType    ctdimmer
   userattr   light lightSceneParamsToSave lightSceneRestoreOnlyIfChanged:1,0 light_map structexclude
   webCmd     pct:dimDown:dimUp:toggle:on:off
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 31 Mai 2021, 13:12:34
Zitat von: drhirn am 31 Mai 2021, 12:56:16
Also, "all=none" tut. Die Szenen-Namen kommen leider noch immer falsch an.

( Frühlingsblüten ){Scene:Frühlingsblüten#[id=wZdk5cpy35oldlw]}

Hmm, hatte versucht, einen setter aus deinen Angaben zu basteln, damit hatte es funktioniert, "all" war eigentlich nur als Notlösung gedacht...

ZitatWoher kommt der Scene-Setter bei dem Device?[...]
Der Ablauf ist der:
Bei der Erstellung/dem Update der devicemap wird (z.B.) "getAllSets('HUEDevice6')" aufgerufen und dann analysiert, was da zurückkommt. Jetzt sollte es bei einem update eigentlich so sein, dass "vorne" der "Techname" stehen bleibt, und hinten dann nur noch der "Klarname" übrig bleibt (ggf. sogar mit Leerzeichen), und (nur) der/die dann auch weiter an Rhasspy geschickt wird/werden.
Ergo wird irgendwas anders bei getAllSets() geliefert, als ich angenommen hatte (input wäre hilfreich), oder der Slot ist jetzt komplett leer (gar keine scenes?) und wird deswegen nicht wieder überschrieben, oder ich übersehe mal wieder was.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 31 Mai 2021, 13:17:13
Ahh, Käse. Es gibt bei HUEDevices ein set scene. Das wusste ich nicht.

off:noArg on:noArg toggle:noArg statusRequest:noArg pct:colorpicker,BRI,0,1,100 bri:colorpicker,BRI,0,1,254 color:colorpicker,CT,2000,1,6500 ct:colorpicker,CT,154,1,500 dimUp:noArg dimDown:noArg ctUp:noArg ctDown:noArg alert:none,select,lselect rename scene:Energie#tanken#[id=1N0Ow9IjFvwJWOb],Energie#tanken#[id=iJiMFXkE57qvCJ7],Energie#tanken#[id=ykGAH5vm9qguUhm],Entspannen#[id=MkBqmt1iphIRayB],Entspannen#[id=g9hPzEGZkAR2g5j],Entspannen#[id=gbca4wF9Vni8oSb],Frühlingsblüten#[id=amg18-TICTPiayR],Frühlingsblüten#[id=fmsyN3Ve4fYGqhG],Frühlingsblüten#[id=wZdk5cpy35oldlw],Gedimmt#[id=7r1VzbwX5H5VVqW],Gedimmt#[id=nEY-TZ2qVEx6WpP],Gedimmt#[id=oZRhLrscoEgC7Xu],Hell#[id=Kd35TY8qIb6pTax],Hell#[id=QszaD6316SsOGNX],Hell#[id=jJAU3n8QlDZI4Zh],Konzentrieren#[id=WGjGSBvWPfW0JH0],Konzentrieren#[id=ig9Hb2jZ6iP9X0E],Konzentrieren#[id=kcz2eYl2goK91Hz],Lesen#[id=IYY-Qkhs6577mil],Lesen#[id=qk7qNpKVeugEugh],Lesen#[id=s-co9adxMQsAsEz],Nachtlicht#[id=0F5VwJFcHpymkm2],Nachtlicht#[id=Ke4VCTMCsSNaIli],Nachtlicht#[id=yJ0tWdBhE-emL3q],Nordlichter#[id=UloxktBtdsVJEUg],Nordlichter#[id=l9gNnheN-NwDIgY],Nordlichter#[id=lk39fWLRdxjTqVl],Sonnenuntergang#Savanne#[id=968VgE7b29JysiY],Sonnenuntergang#Savanne#[id=J88yqZyARhlQh4q],Sonnenuntergang#Savanne#[id=SOcyx8ZWLqI73MR],Tropendämmerung#[id=1a6rDrpjg-i33u8],Tropendämmerung#[id=Li5XQV2Ckvcl9ac],Tropendämmerung#[id=yzMdTFOtJPAIVel] off-for-timer on-till-overnight on-till blink off-till off-till-overnight on-for-timer intervals attrTemplate:?,----subordinated-devices-section--------,C_01_Eurotronic_SPZB0001_Spirit_ZigBee,D_01_Xiaomi_Aqara_MCCGQ11LM_Window_Door_Sensor,E_01a_Xiaomi_Aqara_WSDCGQ11LM_Temperature_Sensor,E_01b_Xiaomi_Aqara_WSDCGQ11LM_Pressure_Sensor,E_01c_Xiaomi_Aqara_WSDCGQ11LM_Humidity_Sensor,F_01a_Xiaomi_Aqara_RTCGQ11LM_Lightlevel_Sensor,F_01a_Xiaomi_Aqara_RTCGQ11LM_Motion_Sensor,G_01_Xiaomi_Aqara_WXKG02LM_Double_Switch

Der Slot ist jetzt mit den Szenen aus "getAllSets" gefüllt. Das Training schlägt natürlich fehl.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 31 Mai 2021, 13:54:57
Zitat von: drhirn am 31 Mai 2021, 13:17:13
Ahh, Käse. Es gibt bei HUEDevices ein set scene. Das wusste ich nicht.
In der Theorie war mir das klar, nur nicht, wie es in der Praxis aussieht, wenn man Szenen konkret definiert hat ::) .

Wie dem auch sei, es ist tricky bzw. irgendwie auch "eigen", was da aus dem HUEDevice kommt...

Mach mal diese Änderung in #1148 rein:
$clscene = (split m{[#]\[id}xms, $clscene)[0] if $clscene =~ m{[#]\[id}xms;
Damit bekomme ich immerhin mal ein "sauberes" listing von RHASSPY hin, allerdings ist es ggf. rückwärts dann "spannend", was passiert, wenn man eines von den "dreifachen Lottchen" haben will? RHASSPY müßte sich eigentlich eines aussuchen, welches wir vermutlich über einen unsortierten Hash-Zugriff ermittelt und damit zufällig...

(Irgendwie irritiert es mich, dass da soviel Tech-Content an FHEM abgeliefert wird; ich würde tippen, dass die entweder alle gleich sind, oder nur einer funktioniert und die anderen irgendwie "outdated" sind...)
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 31 Mai 2021, 14:31:17
Kein Änderung, leider.

Ich hab da keine Szene definiert. Die sind "ab Werk" auf der HueBridge definiert. Warum das jeweils drei sind, weiß ich nicht. Kann aber mit dem Wechsel der Bridge zusammen hängen.

Können wir nicht all=none als Standard definieren?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 31 Mai 2021, 15:17:22
Zwischenzeitlich habe ich mir das auch nochmal angesehen, irgendwie hatte ich bisher nicht realisiert, dass ja _auch_ die "Technames" scheinbar ein Problem darstellen und das mapping direkt auf der Rhasspy-Seite erfolgt...

Eine "Sonderlocke" für "echte" HueBridges (mein Test-HUEDevice unter deconz kennt diese Art von scene nicht) finde ich unglücklich, aber im Moment sehe ich auch keine wirkliche Alternative. Hab's jetzt aber (hoffentlich) anders gelöst, indem eben in diesem Fall die id "durchgeschleust" und beim setter wieder rekonstruiert wird.

Unsicher war ich schon immer, ob es nicht gut wäre, die Device-Info da noch mit reinzubasteln, um gleiche Szenen auseinanderzuhalten. Diese Aktion hier deutet sehr darauf hin, dass es evtl. wirklich eine gute Idee wäre. Das würde aber bedeuten, dass man den ganzen Mapping-Mechanismus an der Stelle nochmal aufbrechen muss und wieder von Rhasspy auf RHASSPY verlagern. Kein Hexenwerk, aber potentiell fehleranfällig und evtl. mit anderen Problemen verbunden...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 31 Mai 2021, 15:28:54
Cool! Jetzt werden die Szenen brauchbar hochgeladen  8)
Danke!

Mal schauen, ob ich das dann auch testen kann. Hab die noch nie verwendet.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 31 Mai 2021, 15:38:40
Danke erst mal für Rückmeldung Teil 1 - es war mir erst mal sehr wichtig, dass wir Rhasspy nicht mit diesem feature "aus dem Tritt" bringen.

Bin mal gespannt, ob das mit dem Anwenden auch klappt (=Teil2) - ich habe das nämlich mit HUEDevice auch noch nie genutzt, nur mit "normalen" Technames (= ohne Sonderzeichen, v.a. ohne das "kommentarverdächtige" #)...

(Falls keine offenkundigen Probleme vorhanden sind, wäre ein svn-Update vermutlich nicht schlecht, weil sonst evtl. der nächste "echte" HueBridge-User über das Thema stolpert).
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 31 Mai 2021, 17:37:23
Zitat von: Beta-User am 31 Mai 2021, 15:38:40
Bin mal gespannt, ob das mit dem Anwenden auch klappt (=Teil2) - ich habe das nämlich mit HUEDevice auch noch nie genutzt, nur mit "normalen" Technames (= ohne Sonderzeichen, v.a. ohne das "kommentarverdächtige" #)...

Ich wollte gerade mal wissen, was überhaupt passiert, wenn ich eine Szene auf einem HUEDevice schalte. Das hier ;D
Unknown argument scene, choose one of off on toggle statusRequest pct bri dimUp dimDown alert rename scene off-for-timer on-till-overnight on-till blink off-till-overnight off-till on-for-timer intervals attrTemplate

Also, keine Ahnung, was das mit den Szenen da soll.

--edit--
Dafür weiß ich jetzt, warum's drei sind: Für jeden HUE-Raum eine
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 31 Mai 2021, 17:53:28
Ähm, häh...?!?

Kann man die ("gleichnamigen" 3) scene(s) denn über das FHEMWEB-Interface schalten? Eigentlich müßte es dort ein dropdown geben... Oder kommt da auch diese Meldung zurück? Oder steht in dem dropdown was ganz anders als vermutet? - Ja, scheint so... Aber bedeutet das, dass man den Befehl dann ohne die "#" zusammenbauen muss? Oder gar, dass "id=xyz" reicht?!?

Wäre klasse, wenn du das mal etwas intensiver testen könntest, ich vermute fast, dass HUEDevice auch parseParams nutzt und dann das "unnütze Bewerk" einfach verwirft....

RHASSPY sollte jedenfalls bei verbose 5 loggen, welcher Befehl versuchsweise abgesetzt wurde.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 31 Mai 2021, 18:07:22
HUEDevice.pm kann's nicht wie's aussieht. Hab nur das hier gefunden: https://forum.fhem.de/index.php/topic,100827.0.html
Aber ja, wenn ich's über FHEMWEB schalte, kommt genau die Meldung.

Können wir die Szenen nicht einfach nur sammeln, wenn das Device gDT "Scene" od. "Media" hat?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 01 Juni 2021, 10:32:43
Hmm, also:
Habe mal via phoscon Szenen angelegt, allerdings erst mal nur an einem Device (einer Gruppe, genauer gesagt) => die werden ohne die id an FHEM übergeben, und ein "set" in FHEMWEB läuft auch ohne direkt erkennbare Fehlermeldung durch.
Von daher bin ich nicht unbedingt für die Lösung, "scene" auf die beiden genannten gDT zu begrenzen.

Aus dem verlinkten Thread werde ich nicht so recht schlau, weil da unklar bleibt, ob es (ohne Modul-Anpassung?) klappt, wenn man die id korrekt übergibt, oder ob das (ggf. auch ohne id) nur dann geht, wenn man die modifizierte Version verwendet? ("Lustig" dort: lc und utf8...)

Allerdings hatte ich den Eindruck, dass das mit dem Anwenden der (id-losen) Szenen dann effektiv keine Auswirkungen in der Realität hat...?!? Ein Blick in den Code (der Teil findet sich in HUEBridge) verrät dann (jedenfalls war das mein vorläufiges Verständnis): Sowohl die "originalen" Szenen der HueBridge wie auch deCONZ-Szenen brauchen die id, und die wird identifiziert anhand der "Verpackung" in eckigen Klammern, der Rest der Argumente scheint als unnötiges Beiwerk betrachtet zu werden... 
EDIT: "Brauchen" wohl nicht, aber _wenn_ sie vorhanden ist, erfolgt die Identifizierung wohl (nur) per id.

Na ja, wie dem auch sei, mal meine vorläufige Meinung zu diversen Aspekten:
- bin dagegen, die Funktionalität an dieser Stelle "künstlich" zu begrenzen;
- Workaround ist vorhanden, Rhasspy wird auch ohne workaround nicht gestört => kein unmittelbarer Handlungsdruck;
- "kaputte" (im Sinne von nicht von FHEM aus setzbare) Szenen sind eigentlich ein HUEDevice-Problem und sollten an der richtigen Stelle gefixt werden => eher den verlinkten Thread nochmal aufgreifen
- "ganz kaputte Szenen" (=auch nicht auf der HueBridge selbst setzbare) sind ggf. vom User aus der Bridge zu löschen (grundsätzliches Aufräumen ist nicht RHASSPY-Aufgabe...)

Brauche vermutlich noch ein paar Tests, auch mit "Leerzeichen-Szenen" und mehr Szenen auf mehr HUEDevice-Geräten, anbei jedenfalls mal eine Version, die
- zum einen keine # an Rhasspy liefern sollte, wenn keine id gesetzt ist, aber "Leerzeichen" enthalten sind (HUEDevice füllt die auf), und
- zum anderen dann _nur_ die "richtig verpackte" (?) id an die "set"-Anweisung übergibt.
Vielleicht kommen wir ja so weiter, ansonsten wäre wie gesagt m.E. justme1968 isns Boot zu holen.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Raemsna am 01 Juni 2021, 20:34:57
Zitat von: Beta-User am 25 Mai 2021, 22:39:27
Sooo, für mutige (und FHEM-mäßig akuelle!) Tester und User....

(Intern wird jetzt die Register.pm zur Timerverwaltung genutzt. Das kommt mit dem update erst seit ein paar Tagen, ich hab's aber (mit RHASSPY) noch nicht intensiv getestet...)

Dafür kann das Ding jetzt vielleicht on-for-timer...

Beim gDT-Mapping ist mir auch was kaputt gegangen gewesen, das ist auch repariert.

sentence.ini zum Testen:
[de.fhem:SetTimedOnOff]
(schalt|mach) (den|die|das) $de.fhem.Device-SetOnOff{Device} [in|im|in der|auf der] [$de.fhem.Room{Room}] für [((1..60){Hour!int} (stunde|stunden))] [und] [((1..60){Min!int} (minute|minuten))] [und] [((1..60){Sec!int} (sekunde|sekunden))] $OnOffValue{Value}


Hi,

nachdem ich jetzt FHEM aktuell habe, wollte ich eben on-for-timer in Rhasspy testen.

- Ich hab die neueste Version aus Post https://forum.fhem.de/index.php/topic,119447.msg1160270.html#msg1160270 (https://forum.fhem.de/index.php/topic,119447.msg1160270.html#msg1160270) eingespielt.
- Modul lädt, scheint alles i.O. zu sein
- updates von FHEM aus gemacht (update devicemap, slots, all)
- Train in Rhasspy aufgerufen

Dann wollte ich die oben angehängte Sentence einfügen.

Ergebnis in Rhasspy:
AssertionError: Missing slot $OnOffValue

Ich bin mir aktuell nicht sicher, ob ich etwas händisch einfügen muss, oder ob das das FHEM Modul könnten sollte?

Danke und Grüße
Raemsna
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 01 Juni 2021, 21:10:22
Das ist ein Slot, den Beta-User und ich händisch angelegt haben. Sieht so aus:


(an|einschalten|ein|anschalten|aktiviere|aktivieren|anmachen|schließe|schließen|runter|zu|raus|ausfahren|rausfahren|läuft|rennt):an
(aus|ausschalten|ab|abschalten|deaktiviere|deaktivieren|ausmachen|öffne|öffnen|rauf|auf|rauf|rein|einfahren|reinfahren):aus


Du kannst das aber in dem "sentence" durch

... (an|ein|aus){Value}

ersetzen. Dann brauchst du den Slot nicht.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 01 Juni 2021, 21:36:35
Ist bei mir etwas anders:

aus:off
on
zu:off
auf:on
off
an:on
Value ist dann gleich "international".
Könnte man ggf. (überarbeitet) auch in de-cfg über nehmen, müsste dann aber de.fhem.... vor den slot-Namen packen.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 02 Juni 2021, 08:00:47
Naja, schwierig. Dann müssten wir alle englischen Möglichkeiten abdecken. Weil, ist ja nicht nur ein/aus, sondern z.B. auch auf/zu, runter/rauf, etc. Glaube, es ist einfacher, wenn das jeder selber macht. Und ein bisschen Rhasspy-Wissen schadet ja nicht.

Aber hast recht, mein Beispiel war nicht ganz korrekt. Hätte so heißen sollen:


(an|ein){Value:on}
(aus){Value:off}
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 02 Juni 2021, 08:19:02
Ja, ist ein Thema, das eigentlich auch etwas mehr "Hirnschmalz" vertragen könnte...
Bin z.B. auch noch nicht dazu gekommen, das "auf/zu"-Ding abzuspalten (und z.B. mit "öffne/schließe" zu ergänzen); das sollte m.E. eigentlich in einen eigenen Slot, damit es zu gDT blind paßt (aber bisher waren meine Erkennungsergebnisse seit der Umstellung der sentences auf -group auch so ok => eilt nicht).

Was allerdings immer noch nicht wollte (bzw. mit den letzten Versionen effektiv noch "schlechter" war), ist das Schalten bestimmter Gruppen. Leider habe ich da den Dreh' noch nicht gefunden, warum (in der angehängten Fassung wenigstens) die erste von zwei Gruppen funktioniert, die andere aber nicht, wenn die als letzte steht und ein Leerzeichen enthält...
Muss ich mir nochmal intensiver ansehen, das scheint irgendwie an der regex zu hängen. Nach regex101.com wäre die aber an sich ok, bin grade ratlos.

(Ansonsten sind nur noch zwei weitere "uninitialized"-Stellen gefixt).
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 02 Juni 2021, 09:15:34
...ach so, was ich eigentlich auch noch loswerden wollte:
Mit den letzten beiden Versionen funktionierte das Schalten von HUEDevice-Szenen :) .

Anmerkungen/eventuelle Einschränkungen:
- getestet mit deconz als HUEBridge
- bisher ohne "id"-Kenner, also "nur" Klartext-Namen, aber
- Szenennamen mit und ohne Leerzeichen werden geschaltet.

Jetzt werde ich die kommenden Tage erst mal versuchen, das Gruppen-Thema zu fixen, (=> wer zweckdienliche Hinweise einschließlich ähnlicher Probleme (!) hat: bitte melden (rhasspy-list (auszugsweise) wäre hilfreich) !), und mir dann überlegen, wo/auf welcher Ebene ich eigentlich welche Art der Gruppenschaltung sinnvollerweise realisiere (einschl. der Szenen-Optionen aus deconz und lightScene...).
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 02 Juni 2021, 09:17:14
Zitat von: Beta-User am 02 Juni 2021, 09:15:34
...ach so, was ich eigentlich auch noch loswerden wollte:
Mit den letzten beiden Versionen funktionierte das Schalten von HUEDevice-Szenen :) .

Ähm, wie? Du meinst, RHASSPY kann's. Aber HUEDevice.pm nicht?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 02 Juni 2021, 09:22:17
Zitat von: drhirn am 02 Juni 2021, 09:17:14
Ähm, wie? Du meinst, RHASSPY kann's. Aber HUEDevice.pm nicht?
Nö, ich meine: Rhasspy erkennt die Szene, RHASSPY setzt das als Einzelbefehl um, HUEDevice akzeptiert den Befehl und haut das über das passende IO raus, und am Ende wird meine Lampe(ngruppe) auch entsprechend in der Realität umgeschaltet (konkret: Lichtfarbe und Dimmung geändert).

Kurz: works as intented 8) ...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 02 Juni 2021, 09:42:01
Versteh ich nicht. Wie soll das gehen, wenn's das HUEDevice nicht kann?


2021.06.02 09:40:22 5: RHASSPY: [Rhasspy] Parse (IO: rhasspyMQTT2): Msg: hermes/intent/de.fhem_SetScene => {"input": "stelle die stehlampe auf die Szene id=gbca4wF9Vni8oSb", "intent": {"intentName": "de.fhem:SetScene", "confidenceScore": 1.0}, "siteId": "default", "id": "8871b861-236c-4bc2-82f9-cc67ea6be059", "slots": [{"entity": "de.fhem.Device-scene", "value": {"kind": "Unknown", "value": "stehlampe"}, "slotName": "Device", "rawValue": "stehlampe", "confidence": 1.0, "range": {"start": 11, "end": 20, "rawStart": 11, "rawEnd": 20}}, {"entity": "Scene", "value": {"kind": "Unknown", "value": "id=gbca4wF9Vni8oSb"}, "slotName": "Scene", "rawValue": "entspannen", "confidence": 1.0, "range": {"start": 35, "end": 53, "rawStart": 35, "rawEnd": 45}}], "sessionId": "8871b861-236c-4bc2-82f9-cc67ea6be059", "customData": null, "asrTokens": [[{"value": "stelle", "confidence": 1.0, "rangeStart": 0, "rangeEnd": 6, "time": null}, {"value": "die", "confidence": 1.0, "rangeStart": 7, "rangeEnd": 10, "time": null}, {"value": "stehlampe", "confidence": 1.0, "rangeStart": 11, "rangeEnd": 20, "time": null}, {"value": "auf", "confidence": 1.0, "rangeStart": 21, "rangeEnd": 24, "time": null}, {"value": "die", "confidence": 1.0, "rangeStart": 25, "rangeEnd": 28, "time": null}, {"value": "Szene", "confidence": 1.0, "rangeStart": 29, "rangeEnd": 34, "time": null}, {"value": "id=gbca4wF9Vni8oSb", "confidence": 1.0, "rangeStart": 35, "rangeEnd": 53, "time": null}]], "asrConfidence": null, "rawInput": "stelle die stehlampe auf die szene entspannen", "wakewordId": null, "lang": null}
2021.06.02 09:40:22 5: Parsed value: stelle die stehlampe auf die szene entspannen for key: rawInput
2021.06.02 09:40:22 5: Parsed value: SetScene for key: intent
2021.06.02 09:40:22 5: Parsed value: id=gbca4wF9Vni8oSb for key: Scene
2021.06.02 09:40:22 5: Parsed value: stelle die stehlampe auf die Szene id=gbca4wF9Vni8oSb for key: input
2021.06.02 09:40:22 5: Parsed value: default for key: siteId
2021.06.02 09:40:22 5: Parsed value: 8871b861-236c-4bc2-82f9-cc67ea6be059 for key: sessionId
2021.06.02 09:40:22 5: Parsed value: stehlampe for key: Device
2021.06.02 09:40:22 5: Parsed value: 1 for key: probability
2021.06.02 09:40:22 5: handleIntentSetScene called
2021.06.02 09:40:22 5: default room used
2021.06.02 09:40:22 5: Device selected (by hash, with room and name): HUEDevice6
2021.06.02 09:40:22 5: analyzeAndRunCmd called with command: scene [id=gbca4wF9Vni8oSb]
2021.06.02 09:40:22 5: HUEDevice6 scene [id=gbca4wF9Vni8oSb] is a normal command
2021.06.02 09:40:22 1: default/icoEverything.png
2021.06.02 09:40:22 5: Running command [scene [id=gbca4wF9Vni8oSb]] on device [HUEDevice6]
2021.06.02 09:40:22 5: Response is: Gerne!


Und was macht das "default/icoEverything.png" da? Das ist für mich immer ein Zeichen, dass etwas nicht funktioniert ;)
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 02 Juni 2021, 10:09:07
Zitat von: drhirn am 02 Juni 2021, 09:42:01
Versteh ich nicht. Wie soll das gehen, wenn's das HUEDevice nicht kann?
Na ja, _mein_ HUEDevice kann das (wie bereits angemerkt: getestet aber bisher ohne, dass irgendwo das "magische" (eckige) id=... aufgetaucht wäre, muss mal schauen, ob/wie man das @deconz überhaupt "generieren" kann). Nach dem Code von HUEBridge zu urteilen, sollten eigentlich sowohl deconz wie auch die holländische Bridge "id=..." verarbeiten können. Wenn das nicht der Fall ist => Problem bitte bei HUEDevice/justme1968 einkippen, und dann eben "notfalls" den workaround mit "all=none" nutzen, wenn's nur Probleme macht...

(Wie gestern geschrieben: wenn "id=..." (in eckig) angegeben wird, scheint _nur noch das_ durchzuschlagen, der Rest ist imo irrelevant. Kann natürlich sein, dass ich was übersehe, aber der "volle" Kommand hat ja bei dir auch nicht funktioniert; da aber gefühlt >30% der HUEBridge-User auch deconz einsetzen, macht es m.E. keinen Sinn, über eine generelle Deaktivierung zu sprechen, das Thema ist anderswo zu lösen).

Und was macht das "default/icoEverything.png" da? Das ist für mich immer ein Zeichen, dass etwas nicht funktioniertDas kann ich nicht zuordnen, aber das klingt nach einer "eigentlich" anderen Geschichte...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 02 Juni 2021, 10:12:08
Zitat von: Beta-User am 02 Juni 2021, 10:09:07
Na ja, _mein_ HUEDevice kann das

Ahsooo ;D
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 02 Juni 2021, 10:18:06
Zitat von: drhirn am 02 Juni 2021, 10:12:08
Ahsooo ;D
Zur Klarstelung: Die Moduldatei ist aber nichts spezielles, sondern einfach nur die aktuelle svn-Fassung (dto. für HUEBridge):
31_HUEDevice.pm 23912 2021-03-08 10:21:02Z justme1968
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 02 Juni 2021, 10:22:59
Mein FHEM ist aktuellst, daran liegt's nicht. Mir ist das Thema aber auch nicht wichtig. Wozu soll ich die Szene einer Lampe schalten? Und die HUE-Szenen verwende ich sowieso nicht.

Was anderes: Ich hab das README letzte Woche aktualisiert. Könntest du bei Gelegenheit bitte mal kurz drüber sehen, ob ich etwas vergessen habe? Jetzt mal abgesehen von den paar Intents, die noch leer sind?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 02 Juni 2021, 10:57:09
Zitat von: drhirn am 02 Juni 2021, 10:22:59
Mein FHEM ist aktuellst, daran liegt's nicht. Mir ist das Thema aber auch nicht wichtig. Wozu soll ich die Szene einer Lampe schalten? Und die HUE-Szenen verwende ich sowieso nicht.
Dann scheint es wirklich an der (originalen) HueBridge zu liegen, komisch eigentlich; ich gehe davon aus, dass justme1968 genau die (auch) nutzt...

Bisher hatte ich auch nicht das große Bedürfnis, mich mit den HUE-Szenen zu beschäftigen ::) , aber für RHASSPY war's jetzt halt "notwendig" - und jetzt fand ich das sogar eine ziemlich coole Option, auch Gruppenschaltungen zu realisieren. Zum Hintergrund: Ich habe einen "ZigBee-Raum" (also einen physischen Bereich, in dem für Beleuchtung fast überall ZigBee-Zeug installiert ist), und eigentlich ist für bestimmte Gelegenheiten das Hue-feature für bestimmte Modi ideal, weil es "hardwarenah" ausgeführt wird...

Zitat
Was anderes: Ich hab das README letzte Woche aktualisiert. Könntest du bei Gelegenheit bitte mal kurz drüber sehen, ob ich etwas vergessen habe? Jetzt mal abgesehen von den paar Intents, die noch leer sind?
Mache ich; auf die Schnelle sind mir schon ein paar Kleinigkeiten aufgefallen.

Btw.: Soll "GetWeekday" eigentlich weiter so heißen?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 02 Juni 2021, 11:00:10
Zitat von: Beta-User am 02 Juni 2021, 10:57:09
Btw.: Soll "GetWeekday" eigentlich weiter so heißen?

Stimmt. Ist jetzt eigentlich blöd. Können wir gerne in GetDate umbenennen.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 02 Juni 2021, 13:48:25
Zitat von: drhirn am 02 Juni 2021, 11:00:10
Stimmt. Ist jetzt eigentlich blöd. Können wir gerne in GetDate umbenennen.
here you are...

Habe vermutlich auch den Schalter gefunden, der das Leerzeichen in meiner Gruppenbenennung nicht mochte. Ist geändert, und ich hoffe auch, dass das nicht noch mehr Stellen betrifft (potentiell: Raumnamen mit Leerzeichen).
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 02 Juni 2021, 20:29:55
Hi, ich hab mal die aktuelle contrib probiert und gleich eine Frage. Was denkt ihr über confirm in den vorhandenen Set-mappings (z.B. SetOnOff und SetNumeric) - ist das machbar?
Gruß Jens
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 02 Juni 2021, 20:44:09
Zitat von: JensS am 02 Juni 2021, 20:29:55
Hi, ich hab mal die aktuelle contrib probiert und gleich eine Frage. Was denkt ihr über confirm in den vorhandenen Set-mappings (z.B. SetOnOff und SetNumeric) - ist das machbar?
Gruß Jens
Zitat von: Beta-User am 31 Mai 2021, 10:41:09
Generelle Bestätigungsmöglichkeiten sind derzeit noch nicht implementiert, das Interesse war bisher nicht übermäßig groß. (bei shortcuts geht das aber!)
Sowas (vollends) zu implementieren dürfte nicht allzu schwierig sein, ist aber Aufwand, auch beim Testen. Falls größeres Interesse besteht, würde ich das mal auf die Agenda nehmen... (Mein persönliches Problem, das mit in diese Richtung geschubst hatte, ist jetzt eher dadurch gelöst, dass mehr Slots zur Verfügung stehen, so dass Rhasspy "treffsicherer" ist).
Nehme dich mal auf die Liste der potentiellen Befürworter, bitte aber trotzdem darum, erst mal zu checken, ob ggf. auch die engeren Slots den größten Teil des Weges nicht abdecken könnten.

Was die Modulversion angeht: am besten die aktuelle aus meinem letzten Post nehmen, da klappen (@drhirn: getestet) jetzt auch "Leerzeichen-Gruppen" (und vermutlich auch L-Räume) wieder. FHEM vorher updaten (wg. Register.pm).



@drhirn betr. Doku: den pull-request hast du vermutlich gesehen.
Bin aber zunehmend unsicher, ob wir nicht doppelt Arbeit haben und das nicht (weitgehend) besser in die cref gehören würde. (Da wäre ggf. nochmal zu checken, ob nicht Teile der Überarbeitung dahin übernommen werden können).


Jetzt muss ich aber erst selbst mal wieder ein paar gDT-Attribute verteilen 8) . Gefällt mir ausgesprochen gut, das Tool!
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 03 Juni 2021, 10:47:10
Hinweis: Der Intent GetWeekday wurde umbenannt in GetDate

Zitat von: Beta-User am 02 Juni 2021, 20:44:09
Was die Modulversion angeht: am besten die aktuelle aus meinem letzten Post nehmen, da klappen (@drhirn: getestet) jetzt auch "Leerzeichen-Gruppen" (und vermutlich auch L-Räume) wieder. FHEM vorher updaten (wg. Register.pm).
Die Version ist jetzt im SVN. Und ich habe einen Merge von dev auf main gemacht. Es ist somit alles aktuell.

Zitat@drhirn betr. Doku: den pull-request hast du vermutlich gesehen.
Ja. Großen Dank an dich und christoph-morrison!

ZitatBin aber zunehmend unsicher, ob wir nicht doppelt Arbeit haben und das nicht (weitgehend) besser in die cref gehören würde.
Wie du weißt, war mein ursprünglicher Plan, die CRef kurz und knapp zu halten. Und Details im Readme unterzubringen. Jetzt ist halt das Modul schon so mächtig, dass "kurz und knapp" doch relativ lang ist. Ja, ist doppelte Arbeit. Ich weiß aber momentan nicht, wie wir das sonst lösen könnten. Hab aber im FHEM-GitHub mal eine Möglichkeit gesehen, wie man die CRef automatisch erstellen lassen kann ;).

ZitatJetzt muss ich aber erst selbst mal wieder ein paar gDT-Attribute verteilen 8) . Gefällt mir ausgesprochen gut, das Tool!
Ja! Hast du gut gemacht! Und ich finde das super, dass ich dich so angefixt habe ;D
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 04 Juni 2021, 08:35:36
Zitat von: drhirn am 03 Juni 2021, 10:47:10
Die Version ist jetzt im SVN. Und ich habe einen Merge von dev auf main gemacht.
Thx (auch an Christoph für den review!). Imo sind wir mit V. 0.4.x jetzt ziemlich "durch" (s.u.).
Was "excerpt" angeht: das war wirklich im Sinne von "auszugsweise" gemeint, es gibt ja noch ein paar mehr als die auf der Liste, oder?

Was 0.4 angeht, geht es imo jetzt noch um das Fixen von eventuellen Problemen/uninitialized-Warnings usw., und dann wäre da noch die Frage der Vervollständigung der Doku im Hinblick auf "optimales Vorgehen" bzw. Abrundung der automatisiert (via de-cfg) erstellten slots. Da wäre z.B. noch der OnOff-Slot bzw. hoch/runter-Verfeinerungen usw.. Habe da auch noch keine abschließende Meinung zu, _glaube aber_, dass wir gut daran täten,  von vornherein "filigranere" Slots (Device-xy und OnOff-xy) zumindest vorzustellen und (via Modul und de-cfg) vorzubereiten.

(Ja, die FHEM-Doku kann keine Rhasspy-Doku ersetzen, aber es ist eng verzahnt, so dass sich da gewisse Doppelungen kaum vermeiden lassen, oder?).

Kann im Moment nicht sagen, was von der ToDo-Liste sonst noch aktuell ist.

Zitat
war mein ursprünglicher Plan, die CRef kurz und knapp zu halten.
Finde ich nach wie vor richtig, andererseits finde ich aber die Doppelung definitiv nicht gut, da Doppelarbeit und immer dem Risiko ausgesetzt, dass es widersprüchlich ist. Sehe nur zwei Auswege (cref ist und bleibt Pflicht und steht daher nicht zur Diskussion): Entweder "alles" aus der md kommt in die cref (von mir aus gerne automatisiert), einschl. Tipps und Tricks, oder es gibt eine eindeutige Struktur in der md, die "zwingend" voraussetzt, dass man die Bezugspunkte in der cref daneben legt und die md diese nur ergänzt.
Da ich im Moment nicht glaube, dass noch besonders viele Anwendungshinweise dazu kommen, wäre ich  eher für eine "cref only"-Variante.


Was die Roadmap für 0.5/0.6 angeht, hätte ich folgende Punkte auf der Liste:
- automatisches Umschalten von Einzel- auf Gruppenkommando (wenn eine Gruppe in dem JSON ist, aber kein Device);
- (mehr) Bestätigungsoptionen
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 04 Juni 2021, 10:02:07
Zitat von: Beta-User am 04 Juni 2021, 08:35:36
Was "excerpt" angeht: das war wirklich im Sinne von "auszugsweise" gemeint, es gibt ja noch ein paar mehr als die auf der Liste, oder?
Ja, ich hab da deswegen eine dritte Version des Textes ins Spiel gebracht. Die ist allerdings auch nicht ganz richtig sehe ich gerade.

Zitatund dann wäre da noch die Frage der Vervollständigung der Doku im Hinblick auf "optimales Vorgehen" bzw. Abrundung der automatisiert (via de-cfg) erstellten slots. Da wäre z.B. noch der OnOff-Slot bzw. hoch/runter-Verfeinerungen usw.. Habe da auch noch keine abschließende Meinung zu, _glaube aber_, dass wir gut daran täten,  von vornherein "filigranere" Slots (Device-xy und OnOff-xy) zumindest vorzustellen und (via Modul und de-cfg) vorzubereiten.

Was meinst du mit "optimales Vorgehen"?
Aber ja, wir können gerne die automatisch erstellten Slots in der Doku genauer erklären.

ZitatDa ich im Moment nicht glaube, dass noch besonders viele Anwendungshinweise dazu kommen, wäre ich  eher für eine "cref only"-Variante.
Wie wird denn das in der FHEM-Community gesehen? Ich persönlich verwende extrem oft die ganze CRef im Web. Da ist es wahnsinnig lästig, wenn da zwischendurch eine riesiger Abschnitt für ein Device kommt.
Und die CRefs werden in FHEM jedes Mal mitgeladen. Ob man sie gerade braucht, oder nicht. Da geht eine ausführliche CRef natürlich auf die Performance.


ZitatWas die Roadmap für 0.5/0.6 angeht, hätte ich folgende Punkte auf der Liste:
- automatisches Umschalten von Einzel- auf Gruppenkommando (wenn eine Gruppe in dem JSON ist, aber kein Device);
- (mehr) Bestätigungsoptionen
Ich hab eigentlich nur "wie lange noch" beim Timer auf meiner Liste
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 04 Juni 2021, 10:16:39
Zitat von: drhirn am 04 Juni 2021, 10:02:07
Was meinst du mit "optimales Vorgehen"?
Na ja, an der Stelle war eigentlich "nur" gemeint: bilde Sätze, die z.B. nur für Rollläden passen und verwende dann einen On/Off-slot, der auch nur öffne/schließe bzw. auf/zu in on bzw. off umwandelt. Sowas ist m.E. jedenfalls zweckmäßig, bevor man anfängt, (dann ggf. überflüssige?) Bestätigungsdialoge einzurichten.
(Will aber nicht behaupten, dass das bei mir schon "fertig" wäre).

Etwas generischer aber vorneweg: setze gDT, damit überhaupt die "engeren" slots verfügbar sind bzw. mit sinnvollem Content an Rhasspy übermittelt werden.

ZitatIch hab eigentlich nur "wie lange noch" beim Timer auf meiner Liste
Können wir ja auch gerne für die nächste Version mit aufnehmen. Da die Timer als at angelegt werden, sollte sowas eigentlich recht einfach zu machen sein (internal NTM abfragen, "etwas rechnen" und eine Ausgabe machen analog zum Timer setzen...). Und in den Readings steht es ja eigentlich auch...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 06 Juni 2021, 14:12:07
Nach einer ConfirmAction ordnet die Rhasspy-Basis keine Intents mehr zu, obwohl die Worte eindeutig erkannt wurden.
Ein "ja bitte" wird weiterhin erkannt - natürlich mit der Meldung, dass gerade nicht danach gefragt wurde.
Kann sein, dass meine exotische Installation daran schuld ist.

In 10_RHASSPY.pm fand ich folgende Zeile, welche ich auskommentiert habe:IOWrite($hash, 'publish', qq{hermes/dialogueManager/configure $json});
Hintergrund ist, dass offensichtlich der IntentFilter nach der ConfirmAction nicht zurückgesetzt wird.

Gruß Jens
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 07 Juni 2021, 09:54:48
Zitat von: JensS am 06 Juni 2021, 14:12:07
Nach einer ConfirmAction ordnet die Rhasspy-Basis keine Intents mehr zu, obwohl die Worte eindeutig erkannt wurden.
Interessante Feststellung - bisher war ich davon ausgegangen, dass Rhasspy nicht in der Lage wäre, die Intent-Filter überhaupt im laufenden Betrieb zu ändern... Das scheint eine Fehlannahme zu sein bzw. zwischenzeitlich überholt (entsprach aber meinen damaligen Tests, die aber (nach heutigem Kenntnisstand) auch aus anderen Gründen schiefgehen mussten).

ZitatIn 10_RHASSPY.pm fand ich folgende Zeile, welche ich auskommentiert habe:IOWrite($hash, 'publish', qq{hermes/dialogueManager/configure $json});
Hintergrund ist, dass offensichtlich der IntentFilter nach der ConfirmAction nicht zurückgesetzt wird.
Dieser Fix deaktiviert im Endeffekt die ganze Filterung. Bin den Code jetzt nochmal durchgegangen und habe ein paar Stellen umgestellt, die diesen Codeteil nutzen, da waren definitiv noch Unsauberkeiten drin. Die Umstellungen sind bisher aber (funktional) noch nicht getestet. Damit könnte es jetzt wieder - einschließlich der Filterung - wieder so klappen, wie es ursprünglich gedacht war.

Zitat von: JensS am 06 Juni 2021, 14:12:07
Kann sein, dass meine exotische Installation daran schuld ist.
Glaube ich zwar nicht, dass deine Installation die eigentliche Ursache ist, aber falls doch, wäre es klasse, wenn du testen könntest, ob es mit der angehängten Fassung dann klappt wie es soll. Dann wären wir nämlich an der Stelle wieder einen großen Schritt weiter :) .
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 07 Juni 2021, 17:55:14
Funktioniert leider nicht. Wieso machst du überhaupt ein configure?
In continueSession hast du doch schon alles abgefrühstückt, was muss.
https://docs.snips.ai/reference/dialogue#payload-4 (https://docs.snips.ai/reference/dialogue#payload-4)

Gruß Jens
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 07 Juni 2021, 18:15:25
...gute Frage. Muss ich mir nochmal im Gesamtzusammenhang ansehen, ist schon wieder eine Weile her...

Was Doku angeht, bin ich mir nicht so sicher, ob das noch 100% aktuell ist, was bei snips zu finden ist; https://rhasspy.readthedocs.io/en/latest/reference/#dialogue-manager sollte den aktuellen Stand wiedergeben. Mein gedanklicher Ansatz war - soweit ich das aus dem Kopf zusammenbringe - grundsätzlich die Bestätigungs- und Auswahl-Intents zu deaktivieren, und nur zu aktivieren, wenn sie gebraucht werden. Das Deaktivieren müßte nach meinem Verständnis über "configure" laufen, ob der intentFilter das dann für die Session überspielen kann, wäre die spannende Frage.
So richtig viele funktionsfähige Dialog-Beispiele habe ich aber auch nicht gefunden, kann schon sein, dass das doch anders läuft. Ganz außen vor kann man den DialogManager (und das configure) aber mAn. nicht lassen - aber man muss ihn aber ggf. anders bzw. seltener überhaupt aufrufen, wenn das vorübergehende Aktivieren über "continue" gemacht werden kann.

(Needs testing, wird dauern...)
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 07 Juni 2021, 21:31:32
Ok, den Filter kannst du vielleicht mit "intentFilter":nullzurücksetzen.
Interessant wäre, wenn man den ConfirmAction-Filter negieren könnte.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 08 Juni 2021, 09:13:38
@Beta-User
Bin die ganze Sache mit dem intentFilter nochmal durchgegangen und habe ein paar Ansätze.

Dein intentFilter funktioniert und braucht (entgegen meiner ersten Annahme) nicht zurückgesetzt werden, da er nur für die Session gilt.

"configure ... intents ... intentId ... enable" ist die Ursache für die Dienstquittierung von Rhasspy nach ConfirmAction, da das (vermutlich) global wirkt.

Wenn eine ausreichend lange Sequenz (ja bitte|nein danke) erkannt werden muss, wäre ein configure nicht unbedingt erforderlich.

Das Hermes-Protokoll ist mittlerweile ein Standard, den nicht nur Rhasspy/Snips nutzt. Unter "hermes intentFilter" findet man eventuell was im Web.

Gruß Jens

p.s. Wenn https://docs.snips.ai/reference/hermes#sending-text-to-the-nlu-component-for-slot-detection (https://docs.snips.ai/reference/hermes#sending-text-to-the-nlu-component-for-slot-detection) nur für die Session gilt, könnten die ConfirmActions in der Sprachdatei einem eigenen Slot hinterlegt und der Slotname der Session übergeben werden. Nur eine Vermutung - haltbare Infos sind nicht leicht zu finden...

p.p.s. So ein freier Tag setzt viele Ideen frei.  :)
Das p.s. sollte auch im contuineSession als zusätzliche Option zu intentFilter funktionieren. Dazu wird ein Slot de.fhem.confirmAction angelegt und mit (ja bitte){Mode:OK} befüllt.
In sentences.ini wird nur der Intent [de.fhem:confirmAction] ohne Inhalt definiert.
Das hat (vermutlich) zur Folge, dass die Worte trainiert aber nicht zur ASR genutzt werden.
Bei continueSession wird dann der intentFilter de.fhem:confirmAction mit der Option "slot":"de.fhem.confirmAction" aufgerufen. Ob das geht?


Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 08 Juni 2021, 10:40:28
Anbei mal eine Fassung, die den dialogManager nur noch @startup aufruft.

Zitat von: JensS am 08 Juni 2021, 09:13:38
@Beta-User
Bin die ganze Sache mit dem intentFilter nochmal durchgegangen und habe ein paar Ansätze.

Dein intentFilter funktioniert und braucht (entgegen meiner ersten Annahme) nicht zurückgesetzt werden, da er nur für die Session gilt.
Danke für den Schubs, ich hatte das mit dem intentFilter nicht mehr im Fokus und den Code (und die auffindbare Doku) nochmal unter diesem Blickwinkel durchgesehen. Bisher war das so gelöst gewesen, dass sowohl der intentFilter gesetzt (nur für die Dauer der Session gültig) wie auch der global wirkende dialogManager aufgerufen wurde. Der setzt aber "nur" die jeweils ausgewählten Intents auf aktiv oder deaktiv, von daher wäre es auch programmtechnisch logisch, dass man das innerhalb einer Session auch ändern kann, ohne gleich alles umzukonfigurieren...
Falls es ohne die "globale Erlaubnis" auch geht, müsste das mit der angehängten Fassung funktionieren, getestet habe ich es noch nicht.

Zitat
Wenn eine ausreichend lange Sequenz (ja bitte|nein danke) erkannt werden muss, wäre ein configure nicht unbedingt erforderlich.
Wichtig wäre, dass die Erstinitialisierung klappt, dann scheint auch das mit den ggf. sehr kurzen Sequenzen kein Problem mehr zu sein, weil die dann nur zum Tragen kommen, wenn sie (für die Session) aktiviert werden.

Zitat
Das Hermes-Protokoll ist mittlerweile ein Standard, den nicht nur Rhasspy/Snips nutzt. Unter "hermes intentFilter" findet man eventuell was im Web.

Gruß Jens

p.s. Wenn https://docs.snips.ai/reference/hermes#sending-text-to-the-nlu-component-for-slot-detection (https://docs.snips.ai/reference/hermes#sending-text-to-the-nlu-component-for-slot-detection) nur für die Session gilt, könnten die ConfirmActions in der Sprachdatei einem eigenen Slot hinterlegt und der Slotname der Session übergeben werden. Nur eine Vermutung - haltbare Infos sind nicht leicht zu finden...
Na ja, im Detail scheint es Unterschiede zwischen snips und Rhasspy zu geben. Beim Überfliegen der diversen Fundstellen ist mir z.B. aufgefallen,  dass die intentFilter als JSON-Array zu übergeben sind (selbst, wenn es nur ein Wert ist (?), siehe https://community.rhasspy.org/t/one-wake-word-phrase-followed-by-multiple-commands/438 (https://community.rhasspy.org/t/one-wake-word-phrase-followed-by-multiple-commands/438)) und Rhasspy nlu scheinbar kein "partialQuery" zu kennen scheint, siehe https://rhasspy.readthedocs.io/en/latest/reference/#natural-language-understanding (https://rhasspy.readthedocs.io/en/latest/reference/#natural-language-understanding). Müßte man ggf. nachfragen, ist aber mAn. ein anderes Thema, das ggf. zu den "Choice"-Geschichten passen würde.

Na ja, eines nach dem anderen, mir kommt es so vor, als würde sich der Nebel so langsam vollends lichten und wir kämen insgesamt auch an dem Thema voran :) .
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 08 Juni 2021, 10:55:47
Zitathttps://rhasspy.readthedocs.io/en/latest/reference/#natural-language-understanding
Danke für den Hinweis. Die Originalquellen zu Rhasspy hatte ich schon aus dem Blick verloren...
Leider taucht da die Option slot in continueSession nicht auf.  :(
Deine neue Version teste ich gleich.
ZitatAnbei mal eine Fassung, die den dialogManager nur noch @startup aufruft.
Sorry, ob meiner Bequemlichkeit - wo, in den tausenden Zeilen ist was geändert?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 08 Juni 2021, 11:02:50
Zitat von: JensS am 08 Juni 2021, 10:55:47
Danke für den Hinweis. Die Originalquellen zu Rhasspy hatte ich schon aus dem Blick verloren...
Leider taucht da die Option slot in continueSession nicht auf.  :(
Deine neue Version teste ich gleich.Sorry, ob meiner Bequemlichkeit - wo, in den tausenden Zeilen ist was geändert?
Eigentlich sind nur die dialogManager-Aufrufe deaktiviert (und das Erweitern der gespeicherten Daten), diese Änderungen hatte ich aus Bequemlichkeit mit dem "#dialog"-Hinweis kenntlich gemacht, damit ich die selbst auch wiederfinde ::) . (Und die Nummer hochgedreht).
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 08 Juni 2021, 11:15:56
Ah, danke - die Beta-User'sche Syntax macht Sinn...
Um das confirmAction-Thema in meiner Installation als gelöst zu betrachten, habe ich noch ein paar Fragen/Anmerkungen.
Wie sehen die Intents in der sentences.ini richtig aus? Aktuell bei mir:[de.fhem:ConfirmAction]
(ja bitte){Mode:OK}

[de.fhem:CancelAction]
(nein danke){Mode}

CancelAction endet bei mir mit einem Timeout, egal ob "nein danke" oder nichts erkannt wird.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 08 Juni 2021, 11:39:42
Zitat von: JensS am 08 Juni 2021, 11:15:56
Ah, danke - die Beta-User'sche Syntax macht Sinn...
Sowas hört man doch gerne 8) ...

Zitat
CancelAction endet bei mir mit einem Timeout, egal ob "nein danke" oder nichts erkannt wird.
Ups, da war noch die "alte" Logik mit customData drin. Habe den betreffenden intent-handler (ab #3882) entsprechend "Confirm" angepaßt, jetzt müsste es ohne Timeout durchlaufen.

Zitat
Wie sehen die Intents in der sentences.ini richtig aus?
Das paßt so.
Weiterführende Anmerkungen:
- ConfirmAction ruft CancelAction auf, wenn nicht "{Mode:OK}" in den JSON übergeben wird; die "alte" Einheitssyntax funktioniert weiter
- CancelAction braucht an sich gar keinen "Mode", es kennt nur "weg damit..." Schaden tut es aber auch nicht...

Jetzt wäre interessant, ob die Auswahl-Geschichten auch weiter klappen, aber eigentlich sehe ich keine Gründe, warum nicht.

Was mir noch nicht ganz klar ist: Wie ist das mit dem Deaktivieren der slots bei einem Neustart von Rhasspy? FHEM macht das ja nur einmalig. Meine Erwartungshaltung wäre: Rhasspy merkt sich das "configure" (und bisher habe ich noch keine gegenteiligen Hinweise gefunden).
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 08 Juni 2021, 12:03:21
Danke - passt!
"ja bitte" und "nein danke" sowie Stille werden richtig verarbeitet und geben entsprechene Antworten.
Ein intentNotRecognized (wie spät ist es) wird erwartungsgemäß von der Basis mit sessionEnded quittiert.
Für 10_Rhasspy.pm scheint die Session allerdings noch nicht vorbei zu sein, da einhermes/dialogueManager/endSession {"sessionId":"wohnzimmer-alexa-0b6762e9-eb47-4eef-b439-54ec1a54e529","siteId":"wohnzimmer","text":"Tut mir leid, da hat etwas zu lange gedauert"}
nachgeschoben wird. Die Ausgabe hört man natürlich nicht mehr, da die Basis die Session zuvor als beendet erklärt hat.

Insgesamt ist eine funktionierende und nützliche Erweiterung!

Zur Haltbarbeit von configure muss ich dich leider enttäuschen. Die ist abgelaufen, wenn die Basis neu gestartet wird.

p.s. Für einige SetOnOff-Devices würde ich gern die ConfirmAction nutzen. Rasensprenger, Teichbefüller, Weidezaungerät uem habe ich aus Sichereitsgründen noch nicht in Rhasspy intergriert. Für jedes Device zwei rhasspyShortcuts anzulegen, bläht die Config auf.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 08 Juni 2021, 12:17:39
Zitat von: JensS am 08 Juni 2021, 12:03:21
Danke - passt!
"ja bitte" und "nein danke" sowie Stille werden richtig verarbeitet und geben entsprechene Antworten.
OK, also sind wir an der Stelle wirklich deutlich weitergekommen, danke für den support!

Zitat
Ein intentNotRecognized (wie spät ist es) wird erwartungsgemäß von der Basis mit sessionEnded quittiert.
Für 10_Rhasspy.pm scheint die Session allerdings noch nicht vorbei zu sein, da einhermes/dialogueManager/endSession {"sessionId":"wohnzimmer-alexa-0b6762e9-eb47-4eef-b439-54ec1a54e529","siteId":"wohnzimmer","text":"Tut mir leid, da hat etwas zu lange gedauert"}
nachgeschoben wird. Die Ausgabe hört man natürlich nicht mehr, da die Basis die Session zuvor als beendet erklärt hat.
Das muss ich mir nochmal im Detail ansehen. Es ist nachvollziehbar, warum das passiert - der Timer läuft ja noch. Zum Unterbinden müßte man jetzt aber entweder "externe endSession"-Topics abonnieren und auf die sessionId auswerten, um den "richtigen" Timer zu killen, oder "irgendwie" die intentNotRecognized-Message rausfiltern. Falls du grade Topic/Payload zum ganzen Ablauf hast: das wäre hilfreich...

ZitatZur Haltbarbeit von configure muss ich dich leider enttäuschen. Die ist abgelaufen, wenn die Basis neu gestartet wird.
Nicht schön... Bedeutet, wir müssten irgendwie mitbekommen, wann Rhasspy neu gestartet wird. (Klar ist: nach jedem Training; das könnte man abgreifen. Aber sonst...?!?) Oder eben "auf Verdacht" doch immer mal wieder die defaults wiederherstellen (was ich aber lieber vermeiden würde).
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 08 Juni 2021, 12:22:52
mosquitto_sub -h 192.168.x.x -p 1883 -v -t hermes/dialogueManager/# -t hermes/hotword/# -t hermes/intent/#
hermes/hotword/alexa/detected {"modelId": "alexa", "modelVersion": "", "modelType": "personal", "currentSensitivity": 0.5, "siteId": "wohnzimmer", "sessionId": null, "sendAudioCaptured": null, "lang": null, "customEntities": null}
hermes/dialogueManager/sessionStarted {"sessionId": "wohnzimmer-alexa-3e2edb19-61c0-4f2a-a5b9-975745fb1db6", "siteId": "wohnzimmer", "customData": "alexa", "lang": null}
hermes/hotword/toggleOff {"siteId": "wohnzimmer", "reason": "dialogueSession"}
hermes/hotword/toggleOn {"siteId": "wohnzimmer", "reason": "dialogueSession"}
hermes/intent/de.fhem:Shortcuts {"input": "Beleuchtung einschalten", "intent": {"intentName": "de.fhem:Shortcuts", "confidenceScore": 1.0}, "siteId": "wohnzimmer", "id": null, "slots": [], "sessionId": "wohnzimmer-alexa-3e2edb19-61c0-4f2a-a5b9-975745fb1db6", "customData": "alexa", "asrTokens": [[{"value": "Beleuchtung", "confidence": 1.0, "rangeStart": 0, "rangeEnd": 11, "time": null}, {"value": "einschalten", "confidence": 1.0, "rangeStart": 12, "rangeEnd": 23, "time": null}]], "asrConfidence": 1.0, "rawInput": "beleuchtung einschalten", "wakewordId": "alexa", "lang": null}
hermes/dialogueManager/continueSession {"intentFilter":["de.fhem:ConfirmAction","de.fhem:CancelAction"],"sessionId":"wohnzimmer-alexa-3e2edb19-61c0-4f2a-a5b9-975745fb1db6","siteId":"wohnzimmer","text":"Soll ich die Stehlampe wirklich einschalten?"}
hermes/hotword/toggleOff {"siteId": "wohnzimmer", "reason": "dialogueSession"}
hermes/hotword/toggleOff {"siteId": "wohnzimmer", "reason": "ttsSay"}
hermes/hotword/toggleOn {"siteId": "wohnzimmer", "reason": "ttsSay"}
hermes/hotword/toggleOn {"siteId": "wohnzimmer", "reason": "dialogueSession"}
hermes/dialogueManager/sessionEnded {"termination": {"reason": "intentNotRecognized"}, "sessionId": "wohnzimmer-alexa-3e2edb19-61c0-4f2a-a5b9-975745fb1db6", "siteId": "wohnzimmer", "customData": "alexa"}
hermes/hotword/toggleOn {"siteId": "wohnzimmer", "reason": "dialogueSession"}
hermes/dialogueManager/endSession {"sessionId":"wohnzimmer-alexa-3e2edb19-61c0-4f2a-a5b9-975745fb1db6","siteId":"wohnzimmer","text":"Tut mir leid, da hat etwas zu lange gedauert"}

Neustart - es wäre gut ohne configure auszukommen.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 08 Juni 2021, 12:55:34
Hm, also:
"sessionEnded" wird sowieso abonniert, da habe ich jetzt das Löschen des Timers reingebastelt (#2140ff).
Damit sollte das "erledigt" sein (auch wenn es schöner wäre, "falsche intents" direkt auszuschalten, so dass da nichts dazwischenfunkt, aber selbst wenn das dann irgendwann klappen sollte, schadet es nicht, ggf. noch bestehende Timer abzuräumen und überflüssige Daten zu löschen).

Zitat von: JensS am 08 Juni 2021, 12:22:52
Neustart - es wäre gut ohne configure auszukommen.
Wieso?

Zum Hintergrund der Frage:
Meine Überlegung beim Erstellen des dialogManager war, dass es sinnvoll wäre, nicht benötigte Intents ausschalten zu können. Dabei war mir die "Stille" (=> CancelAction in Folge des false positives auf "nein") besonders deutlich vor Augen, aber auch die Auswahlmöglichkeiten sind in der Erkennung kurze Sequenzen, und ich fürchte Nebenwirkungen, wenn man die betreffenden Intents _nicht_ deaktiviert.
Von daher wäre meine Überlegung eher, ggf. bestehende Probleme in diesem Zusammenhang in die Rhasspy-Community einzukippen bzw. mal nachzufragen, ob das so beabsichtigt ist (bzw. warum). Evtl. bekommt man "wenigstens" eine Neustart-Info via MQTT?
Aber evtl. übersehe ich ja mal wieder was wichtiges?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 08 Juni 2021, 13:18:04
Prima - klappt alles.
Noch ein Vorschlag - bei intentNotRecognized "Habe abgebrochen" als Antwort. Dazu genügt ja ein speak.

configure - da kann ich deine berechtigten Bedenken nachvollziehen. Es wäre schön, wenn Rhasspy in hermes/dialogueManager/continueSession die Erweiterung "slot" aufnehmen würde. Das passiert ja vielleicht in Zukunft oder ist nur nicht dokumentiert.

CancelAction - da hatte ich den Sprung zur sub von ConfirmAction in 10_RHASSPY.pm gesehen. Letztlich ist alles, was nicht "OK" ist automatisch cancel. Ist CancelAction als separater Intent überhaupt noch notwendig?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 08 Juni 2021, 14:28:20
Zitat von: JensS am 08 Juni 2021, 09:13:38
p.p.s. [...]
Sorry, das hatte ich erst eben gesehen, hatte sich wohl überschnitten, scheint aber (weitesgehend) erledigt zu sein?

Zitat von: JensS am 08 Juni 2021, 13:18:04
Noch ein Vorschlag - bei intentNotRecognized "Habe abgebrochen" als Antwort. Dazu genügt ja ein speak.
Hab's mal reingeknödelt.

Bin aber nach wie vor irgendwie "unruhig", was das ganze angeht. Eigentlich sollte sich irgendwie verhindern lassen, dass überhaupt der falsche Intent herangezogen wird. Habe jetzt eine Weile drauf rumgekaut und überlegt, ob man doch dialogManager irgendwie dazu nutzen sollte, nur noch bestimmte Intents aktiviert zu halten. Das dürfte aber andererseits auch nicht des Rätsels Lösung sein, denn - jedenfalls lt. Doku in https://rhasspy.readthedocs.io/en/latest/reference/#dialoguemanager_sessionqueued (https://rhasspy.readthedocs.io/en/latest/reference/#dialoguemanager_sessionqueued) - theoretisch wäre es denkbar, dass mehrere Sessions von einer siteId her offen zu halten wären. Da würde dann das Deaktivieren zu echten Problemen führen, weil dann immer die letzte Anweisung durchschlagen würde.

Jetzt bin ich aber in der kurzen Doku noch über "sendIntentNotRecognized" gestolpert :o :) , und würde dazu noch zu einem kurzen Test bitten. Imo sollte das dazu führen, dass die Sitzung erst dann geschlossen wird, wenn entweder ein (zu intentFilter) "passender" Intent gewählt wird, oder der Timeout zuschlägt. Kann aber natürlich sein, dass uns das an anderer Stelle wieder einholt und man das ggf. ein- und ausschaltbar ausgestalten müßte...

Zitat
configure - da kann ich deine berechtigten Bedenken nachvollziehen. Es wäre schön, wenn Rhasspy in hermes/dialogueManager/continueSession die Erweiterung "slot" aufnehmen würde. Das passiert ja vielleicht in Zukunft oder ist nur nicht dokumentiert.
[...]
CancelAction - da hatte ich den Sprung zur sub von ConfirmAction in 10_RHASSPY.pm gesehen. Letztlich ist alles, was nicht "OK" ist automatisch cancel. Ist CancelAction als separater Intent überhaupt noch notwendig?
Notwendig: nein. Vermutlich für die meisten User logischer?

Tatsächlich ist das in der jetzigen Form schlicht und ergreifend "halt so no worra", weil mir zu Beginn noch nicht so richtig klar war, ob man jetzt geschickter einen Intent mit mehreren Modi anlegen sollte und dann anhand der Payload den Rest ansteuert, oder ob man es besser getrennt hält. Das ganze schon vor dem gedanklichen Hintergrund, dass man z.B. Räume oder Devices wählen können sollte.
Für den Moment _glaube ich_, dass separate Intents die geschicktere Lösung sind. Das beruht aber vor allem auf dem Umstand, dass ich irgendwann über das "sister project" voice2json gestolpert bin, das als "Verbesserungen" v.a. das Ändern von slots@runtime mitbringen soll. Vermutlich fehlte dir diese letzte Info als Puzzlesteinchen, um zu verstehen, warum bestimmte Dinge jetzt eben erst mal so gelöst sind, wie sie gelöst sind...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 08 Juni 2021, 15:26:30
Ok, bin gerade auf dem Sprung.
Stille und "wie spät ist es" führen zu "tut mir leid, da hat etwas zu lange gedauert"mosquitto_sub -h 192.168.100.1 -p 1883 -v -t hermes/dialogueManager/# -t hermes/hotword/# -t hermes/intent/#
hermes/hotword/alexa/detected {"modelId": "alexa", "modelVersion": "", "modelType": "personal", "currentSensitivity": 0.5, "siteId": "wohnzimmer", "sessionId": null, "sendAudioCaptured": null, "lang": null, "customEntities": null}
hermes/dialogueManager/sessionStarted {"sessionId": "wohnzimmer-alexa-a32c083b-4d02-4f6e-87f2-fb8d4d2dc652", "siteId": "wohnzimmer", "customData": "alexa", "lang": null}
hermes/hotword/toggleOff {"siteId": "wohnzimmer", "reason": "dialogueSession"}
hermes/hotword/toggleOn {"siteId": "wohnzimmer", "reason": "dialogueSession"}
hermes/intent/de.fhem:Shortcuts {"input": "Beleuchtung einschalten", "intent": {"intentName": "de.fhem:Shortcuts", "confidenceScore": 1.0}, "siteId": "wohnzimmer", "id": null, "slots": [], "sessionId": "wohnzimmer-alexa-a32c083b-4d02-4f6e-87f2-fb8d4d2dc652", "customData": "alexa", "asrTokens": [[{"value": "Beleuchtung", "confidence": 1.0, "rangeStart": 0, "rangeEnd": 11, "time": null}, {"value": "einschalten", "confidence": 1.0, "rangeStart": 12, "rangeEnd": 23, "time": null}]], "asrConfidence": 1.0, "rawInput": "beleuchtung einschalten", "wakewordId": "alexa", "lang": null}
hermes/dialogueManager/continueSession {"intentFilter":["de.fhem:ConfirmAction","de.fhem:CancelAction"],"sendIntentNotRecognized":"false","sessionId":"wohnzimmer-alexa-a32c083b-4d02-4f6e-87f2-fb8d4d2dc652","siteId":"wohnzimmer","text":"Soll ich die Stehlampe wirklich einschalten?"}
hermes/hotword/toggleOff {"siteId": "wohnzimmer", "reason": "dialogueSession"}
hermes/hotword/toggleOff {"siteId": "wohnzimmer", "reason": "ttsSay"}
hermes/hotword/toggleOn {"siteId": "wohnzimmer", "reason": "ttsSay"}
hermes/hotword/toggleOn {"siteId": "wohnzimmer", "reason": "dialogueSession"}
hermes/dialogueManager/intentNotRecognized {"sessionId": "wohnzimmer-alexa-a32c083b-4d02-4f6e-87f2-fb8d4d2dc652", "siteId": "wohnzimmer", "input": "wie spät ist es", "customData": "alexa"}
hermes/dialogueManager/endSession {"sessionId":"wohnzimmer-alexa-a32c083b-4d02-4f6e-87f2-fb8d4d2dc652","siteId":"wohnzimmer","text":"Tut mir leid, da hat etwas zu lange gedauert"}
hermes/hotword/toggleOff {"siteId": "wohnzimmer", "reason": "ttsSay"}
hermes/hotword/toggleOn {"siteId": "wohnzimmer", "reason": "ttsSay"}
hermes/dialogueManager/sessionEnded {"termination": {"reason": "nominal"}, "sessionId": "wohnzimmer-alexa-a32c083b-4d02-4f6e-87f2-fb8d4d2dc652", "siteId": "wohnzimmer", "customData": "alexa"}
hermes/hotword/toggleOn {"siteId": "wohnzimmer", "reason": "dialogueSession"}

Es funktioniert soweit alles.

Dass der CancelAction-Intent noch drin ist, um irgendwelche Sonderfälle zu bedienen, habe ich mir schon gedacht.

Vielen Dank für die rasche Umsetzung!

Gruß Jens
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 08 Juni 2021, 15:38:13
Zitat von: JensS am 08 Juni 2021, 15:26:30
Ok, bin gerade auf dem Sprung.
Stille und "wie spät ist es" führen zu "tut mir leid, da hat etwas zu lange gedauert"
[...]
Es funktioniert soweit alles.
OK, dann lassen wir das jetzt erst mal so, nochmal Danke auch für die Tests und die Inputs, auf das mit "intentNotRecognized" bei "continueSession" wäre ich wohl sonst nicht so schnell gestoßen.

Auswahl aus mehreren möglichen Geräten hattest du aber noch nicht getestet, wenn ich das richtig verstehe?
(Da muss ich bei mir mal ein paar priorities wieder löschen, um das zu testen ;D , und kann vermutlich auch die sentences noch einkürzen)...

ZitatDass der CancelAction-Intent noch drin ist, um irgendwelche Sonderfälle zu bedienen, habe ich mir schon gedacht.
Na ja, nach meiner Lesart ist es eher andersrum: Der indirekte Aufruf aus ConfirmAction ist noch drin, um einen Sonderfall abzudecken ;) ...
Kommt aber wirklich nicht drauf an.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 09 Juni 2021, 07:21:45
Zitat von: JensS am 08 Juni 2021, 12:03:21
Zur Haltbarbeit von configure muss ich dich leider enttäuschen. Die ist abgelaufen, wenn die Basis neu gestartet wird.
Dazu ist mir noch was eingefallen: Es müßte ausreichen, wenn man das configure mit "retain"-flag versendet, also an den Topic einfach ein ":r" anhängt (#767)
Zitat von: Beta-User am 08 Juni 2021, 15:38:13
Auswahl aus mehreren möglichen Geräten hattest du aber noch nicht getestet, wenn ich das richtig verstehe?
(Da muss ich bei mir mal ein paar priorities wieder löschen, um das zu testen ;D , und kann vermutlich auch die sentences noch einkürzen)...
Getestet, und leider funktioniert der Teil jetzt grade nicht mehr, muss mal schauen, wie das im Lichte der neueren Erkenntnisse zu reparieren ist...

(v.a. @drhirn:) Generelle Anmerkung noch zum Thema Doku: Die ganzen Bestätigungs-Mechanismen sind sehr davon abhängig, dass man Rhasspy für das Dialog-Management verwendet (oder was, das 1:1 denselben "Dialekt" spricht). Kann sein, dass das mittelfristig Probleme schafft, falls jemand unbedingt was anderes einsetzen will.

Zitat
p.s. Für einige SetOnOff-Devices würde ich gern die ConfirmAction nutzen. Rasensprenger, Teichbefüller, Weidezaungerät uem habe ich aus Sichereitsgründen noch nicht in Rhasspy intergriert. Für jedes Device zwei rhasspyShortcuts anzulegen, bläht die Config auf.
Der edit wäre mir mal wieder fast durch die Lappen gegangen...

Ich nehme es auf die Liste, aber ganz ohne zusätzliche Konfiguration wird es wohl nicht gehen.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 09 Juni 2021, 09:01:47
Zitat von: Beta-User am 09 Juni 2021, 07:21:45
(v.a. @drhirn:) Generelle Anmerkung noch zum Thema Doku: Die ganzen Bestätigungs-Mechanismen sind sehr davon abhängig, dass man Rhasspy für das Dialog-Management verwendet (oder was, das 1:1 denselben "Dialekt" spricht). Kann sein, dass das mittelfristig Probleme schafft, falls jemand unbedingt was anderes einsetzen will.

Ok, nehme ich in die Doku auf

Danke für's Weiterwerken euch beiden!
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 09 Juni 2021, 10:29:20
Zitat von: drhirn am 09 Juni 2021, 09:01:47
Ok, nehme ich in die Doku auf
Bevor wir Doppelarbeit machen:
ist (neben anderem) in der cref der beiliegenden Version ergänzt.

Da ist weiter drin:
- "retain" für die dialogue-configuration
- die Antworttexte werden intern jetzt alle über getResponse() ermittelt, gibt einen weiteren Parameter, damit das auch für die Responses klappt, die eine Unterstruktur haben (ungetestet).

ZitatGetestet, und leider funktioniert der Teil jetzt grade nicht mehr, muss mal schauen, wie das im Lichte der neueren Erkenntnisse zu reparieren ist...
Das wird dauern, im Moment werde ich aus dem Code nicht schlau, wieso das nicht mehr klappt. "Eigentlich"... Vielleicht habe ich mal wieder für den Schnelltest die "besten" Testbedingungen getroffen ;D .
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 09 Juni 2021, 19:54:42
Zitat von: Beta-User am 09 Juni 2021, 10:29:20
ZitatGetestet, und leider funktioniert der Teil jetzt grade nicht mehr, muss mal schauen, wie das im Lichte der neueren Erkenntnisse zu reparieren ist...
Das wird dauern, im Moment werde ich aus dem Code nicht schlau, wieso das nicht mehr klappt. "Eigentlich"... Vielleicht habe ich mal wieder für den Schnelltest die "besten" Testbedingungen getroffen ;D .
Hab ein zweites Device eingerichtet - hier läuft es. Bei intentNotRecognized kommt: "tut mir leid, da hat etwas zu lange gedauert" - aber das ist ok.

Gruß Jens

p.s.i="Beleuchtung einschalten" f="set Stehlampe on" n="Stehlampe" c="Soll ich die Stehlampe wirklich einschalten?" ct=10
i="Lampe einschalten" f="set Schreibtischlampe on" n="Schreibtischlampe" c="Soll ich die Schreibtischlampe wirklich einschalten?" ct=10
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 10 Juni 2021, 07:37:31
Zitat von: Beta-User am 08 Juni 2021, 12:55:34
Evtl. bekommt man "wenigstens" eine Neustart-Info via MQTT?
Wenn man in der Rhasspy-Web-GUI auf "Restart" klickt, passiert rein gar nichts im MQTT. Die Zeit wäre auch zu kurz, um einen Notar für einen letzten Willen zu finden. Daher wird's wohl auch kein retain geben.

Gruß Jens
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 10 Juni 2021, 08:08:58
Hmm, bin grade ratlos:
Beim Testen war ich davon ausgegangen, dass ConfirmAction/CancelAction funktionieren und habe mir daher ChoiceDevice/CancelAction angesehen. Das hat "scheinbar" nicht funktioniert. Scheinbar, weil ich keine Sprachausgabe (mehr) hatte mit der Anfrage, welches Device ich denn gerne hätte.
Dann habe ich mir die MQTT-Seite dazu angesehen - die sah so aus, wie nach dem Code zu vermuten: Eigentlich passt alles!?!
Dann habe ich es mit ConfirmAction/CancelAction probiert, und siehe da, ich erhalte auch keine (gesprochende) Bestätigungsanfrage auf dem Handy-Satelliten?!? Das Problem ist also wohl nicht auf der Modulebene zu suchen, sondern wohl eher irgendwo anders. Normale Ausgaben ("gerne" etc.) werden aber gesprochen, das scheint auf continueSession beschränkt zu sein.
Meinen ESP-Satelliten habe ich grade nicht gefunden, und der Pi ist auch nicht getestet einsatzfähig...

@JensS (bzw. auch andere, die neben normalen Satelliten auch die Handy-App im Einsatz  haben): Könntet ihr bitte mal checken, ob das bei euch auch ein Problem ist bzw. ggf. mit welcher Art Satellit es auftritt? Dann könnte man das mal in Richtung der Rhasspy-Community adressieren...

Zitat von: JensS am 10 Juni 2021, 07:37:31
Wenn man in der Rhasspy-Web-GUI auf "Restart" klickt, passiert rein gar nichts im MQTT. Die Zeit wäre auch zu kurz, um einen Notar für einen letzten Willen zu finden. Daher wird's wohl auch kein retain geben.
Imo gibt es da kein allgemein sichtbares "MQTT-Gelaber", sondern der Server haut die "retain"-Messages nur an die Clients raus, die sich neu verbinden. Soweit so klar. ABER: Einen ähnlichen Effekt kann man erzielen, wenn man sich mit mosquitto_sub neu subscribed. Aber da ist nichts...?!?
Also FHEM neu gestartet => immer noch nichts...? Scheinbar wir jetzt das configure_DialogManager gar nicht mehr aufgerufen und daher auch nichts gepublisht...? Und da die Messages per siteId versendet werden, wäre es sowieso immer nur die letzte, das bringt also auch nicht wirklich den gewünschten Effekt, selbst wenn es bis dahin funktionieren würde. Hmmm, muss wohl nochmal über dieser Sache brüten ??? :( ??? .
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 10 Juni 2021, 10:32:46
Das hat mir jetzt keine Ruhe gelassen...

Ursache dafür, dass da schlicht nichts kam war, dass die bei der Gesamtinitialisierung vor dem DialogManager-Aufruf stehende Erneuerung der Subscriptions erst mal den M2C disconnected hat, und der daher just zu dem Zeitpunkt einfach nicht bereit war, irgendwas zu verschicken!
Von daher: erst mal alles wieder jeweils 2 Schritte vor, zur Seite, zurück und zur anderen Seite...

Zwischenergebnis anbei (jetzt wieder ohne retain). Glaube zwar nicht, dass das meine App-Dialoge wieder zurückbringt, aber damit sollte sich zumindest checken lassen, ob
- die configure-Anweisungen nicht doch dauerhaft in Rhasspy registriert bleiben (Obacht: da das bisher @startup wirkungslos war, könnte das dazu führen, dass jetzt gar nichts mehr geht, falls ich beim Zusammenbasteln der payload was falsch gemacht haben sollte...!);
- es erforderlich/hilfreich ist, das jeweils innerhalb einer Session via configure zu ändern. Dazu gibt es jetzt in der DEF eine weitere Option "switchDM"; setzt man die auf 1 (oder einen anderen Wert, der als wahr interpretiert wird), sollten dann auch wieder die configure-Anweisungen rausgehen. Kann allerdings sein, dass man das ggf. vor der response machen muss.

Die Antworten auf
Zitat von: Beta-User am 10 Juni 2021, 08:08:58
Könntet ihr bitte mal checken, ob das bei euch auch ein Problem ist bzw. ggf. mit welcher Art Satellit es auftritt?
würde mich aber weiter interessieren, und zwar optimalerweise sowohl mit der alten wie mit der angehängten Version.
Weiter wäre in dem Zusammenhang ggf. noch interessant, ob es auch bei echten Rhasspy's (Base+Satelliten) einen Unterschied macht, ob die Base sprechen soll oder ein Satellit.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 10 Juni 2021, 16:18:07
@Beta-User
configure lässt dir wohl keine Ruhe.  ;)
Hier mal wieder ein paar Gedanken/Ideen:
Der intentFilter gilt nur für die aktuelle Session und ist anschließend zwangsläufig nicht mehr aktiv. Das gilt auch bei einem Timeout.
Configure deaktiviert alle Intents für eine siteId und wenn eine Session nicht durchläuft, bleibt alles deaktiviert.
Da es aber den slot-Aufruf bei continueSession nicht gibt, bleibt wohl nur die zweite Variante.

Aus meiner Sicht sollte der Ablauf so aussehen:
Die Session wird von der Basis gestartet und der Intent wird von der Basis übergeben.
FHEM erkennt den Intent und setzt configure auf intents: [intentId: ConfirmAction, enable: true], siteId: wohnzimmerAlle Intents, außer ConfirmAction sind deaktiviert.

Nach der Antwort sollte  configure intents: [], siteId: wohnzimmerfolgen, um alle Intents zu aktivieren.
Abschließend dann intents: [intentId: ConfirmAction, enable: false], siteId: wohnzimmerum ConfirmAction zu deaktivieren.

Ist nur so eine Idee - ungestestet. Zum testen deiner 10_RHASSPY.pm komme ich frühestens heute Abend.

Gruß Jens

Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 10 Juni 2021, 16:53:40
Zitat von: JensS am 10 Juni 2021, 16:18:07
configure lässt dir wohl keine Ruhe.
Nein... ::)

ZitatHier mal wieder ein paar Gedanken/Ideen:
Der intentFilter gilt nur für die aktuelle Session und ist anschließend zwangsläufig nicht mehr aktiv. Das gilt auch bei einem Timeout.
Configure deaktiviert alle Intents für eine siteId und wenn eine Session nicht durchläuft, bleibt alles deaktiviert.
Da es aber den slot-Aufruf bei continueSession nicht gibt, bleibt wohl nur die zweite Variante.
Na ja, da die Sessions entweder durch RHASSPY (ok oder timeout) oder Rhasspy (no one managed bei meinem "ungesprächigen" App-Satelliten...) beendet werden, sollte dann "irgendwann" auch nach einem intentFilter wieder alles temporär deaktivierte wieder aktiv sein. (Nur) so macht das ganze für mich Sinn, aber evtl. übersehe ich auch was. (Ja, in Teilen: Wenn Rhasspy die Sitzung zumacht, müßte ggf. die DialogManager-config auch aufgerufen werden, wenn man die Intents zwischendurch via config umstellt; das deutet für mich darauf hin, dass es nicht so gedacht sein kann).

Grundsätzlich war ich auch davon ausgegangen, dass immer alles aktiv ist, es sei denn, man deaktiviert es (temporär via intentFilter oder dauerhaft via "configure"-Topic). Wieder anschalten sollte dann auch selektiv gehen, entweder über entsprechende intentFilter-Erneuerung oder via configure-true.
Es geht jetzt v.a. darum rauszufinden, ob diese Grundannahme korrekt ist.

Zitat
Aus meiner Sicht sollte der Ablauf so aussehen:
Die Session wird von der Basis gestartet und der Intent wird von der Basis übergeben.
FHEM erkennt den Intent und setzt configure auf intents: [intentId: ConfirmAction, enable: true], siteId: wohnzimmerAlle Intents, außer ConfirmAction sind deaktiviert.
In diese Richtung ging mein ursprünglicher Ansatz, nur dass da eben neben ConfirmAction noch CancelAction und (alternativ statt ConfirmAction) einer der beiden Choice-Intents aktiviert wurde.
Fyi: Soweit hatte es auch schon mal bei mir funktioniert


ZitatNach der Antwort sollte  configure intents: [], siteId: wohnzimmerfolgen, um alle Intents zu aktivieren.

Abschließend dann intents: [intentId: ConfirmAction, enable: false], siteId: wohnzimmerum alle Intents außer ConfirmAction zu aktivieren.
In diese Richtung ging auch der bisherige Code, nur eben mit mehr Intents und dem "direkten" Versuch, jeweils (nur) die betroffenen Intents wieder umzuschalten. Da "global" zu agieren, (also erst beim "Aufräumen" alles zu aktivieren, um dann selektiv wieder zu deaktivieren) finde ich schwierig, weil es theoretisch ja sein kann, dass grade irgendeine weitere Sitzung läuft (muss nicht mal FHEM sein), in der auch nur bestimmte Intents zulässig sind. Das käme mir sauberer vor: Immer der, der die Sitzungskontrolle übernimmt (continueSession), ist auch für das "Aufräumen" zuständig, muss aber nur wegräumen, was er selbst an Hinterlassenschaften zu verantworten hat.

Kannst ja heute abend dann beim Testen auch "mithören", was die neue Version mit und ohne den neuen Schalter jeweils über "configure" raushaut. Und falls du die Rhasspy-logs (oder wo auch immer man sehen kann, was grade auf der Rhasspy-Seite "Sache" ist, also welche Intents jeweils grade (de-) aktiviert sind) auswerten kannst, wäre das natürlich auch super!

Insgesamt _glaube ich_, dass die jetzige Version _ohne die Aktivierung in der DEF_ die korrekte Implementierung auf der FHEM-Seite darstellt und wir nur irgendein Problem auf der Rhasspy-Seite haben, wenn die App (oder bestimmte Satelliten-Typen?) im Einsatz ist.

Gegenüber der bei dir ja funktionierenden Variante bringt die neue ja eigentlich nur die (jetzt hoffentlich funktionsfähige) Erstinitialisierung der Intents mit, die Dialoge an sich hatten ja funktioniert (zumindest Confirm).
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 10 Juni 2021, 19:23:00
Der erste Dialog geht durch. Der Folgende "Stehlampe" aus, wird nicht dem Intent SetOnOff zugeordnet. "ja bitte" geht weiterhin. Nach einem Restart der Basis ist alles wieder gut.mosquitto_sub -h 192.168.100.1 -p 1883 -v -t hermes/dialogueManager/# -t hermes/hotword/# -t hermes/intent/#
hermes/hotword/alexa/detected {"modelId": "alexa", "modelVersion": "", "modelType": "personal", "currentSensitivity": 0.5, "siteId": "wohnzimmer", "sessionId": null, "sendAudioCaptured": null, "lang": null, "customEntities": null}
hermes/dialogueManager/sessionStarted {"sessionId": "wohnzimmer-alexa-00abb350-fbc8-48ab-af1e-6ce6c31da5bb", "siteId": "wohnzimmer", "customData": "alexa", "lang": null}
hermes/hotword/toggleOff {"siteId": "wohnzimmer", "reason": "dialogueSession"}
hermes/hotword/toggleOn {"siteId": "wohnzimmer", "reason": "dialogueSession"}
hermes/intent/de.fhem:Shortcuts {"input": "Beleuchtung einschalten", "intent": {"intentName": "de.fhem:Shortcuts", "confidenceScore": 1.0}, "siteId": "wohnzimmer", "id": null, "slots": [], "sessionId": "wohnzimmer-alexa-00abb350-fbc8-48ab-af1e-6ce6c31da5bb", "customData": "alexa", "asrTokens": [[{"value": "Beleuchtung", "confidence": 1.0, "rangeStart": 0, "rangeEnd": 11, "time": null}, {"value": "einschalten", "confidence": 1.0, "rangeStart": 12, "rangeEnd": 23, "time": null}]], "asrConfidence": 1.0, "rawInput": "beleuchtung einschalten", "wakewordId": "alexa", "lang": null}
hermes/dialogueManager/configure {"intents":[{"enable":"true","intentId":"de.fhem:ConfirmAction"},{"enable":"true","intentId":"de.fhem:CancelAction"}],"siteId":"wohnzimmer"}
hermes/dialogueManager/continueSession {"intentFilter":["de.fhem:ConfirmAction","de.fhem:CancelAction"],"sendIntentNotRecognized":"false","sessionId":"wohnzimmer-alexa-00abb350-fbc8-48ab-af1e-6ce6c31da5bb","siteId":"wohnzimmer","text":"Soll ich die Stehlampe wirklich einschalten?"}
hermes/hotword/toggleOff {"siteId": "wohnzimmer", "reason": "dialogueSession"}
hermes/hotword/toggleOff {"siteId": "wohnzimmer", "reason": "ttsSay"}
hermes/hotword/toggleOn {"siteId": "wohnzimmer", "reason": "ttsSay"}
hermes/hotword/toggleOn {"siteId": "wohnzimmer", "reason": "dialogueSession"}
hermes/intent/de.fhem:ConfirmAction {"input": "OK", "intent": {"intentName": "de.fhem:ConfirmAction", "confidenceScore": 1.0}, "siteId": "wohnzimmer", "id": null, "slots": [{"entity": "Mode", "value": {"kind": "Unknown", "value": "OK"}, "slotName": "Mode", "rawValue": "ja bitte", "confidence": 1.0, "range": {"start": 0, "end": 2, "rawStart": 0, "rawEnd": 8}}], "sessionId": "wohnzimmer-alexa-00abb350-fbc8-48ab-af1e-6ce6c31da5bb", "customData": "alexa", "asrTokens": [[{"value": "OK", "confidence": 1.0, "rangeStart": 0, "rangeEnd": 2, "time": null}]], "asrConfidence": 1.0, "rawInput": "ja bitte", "wakewordId": "alexa", "lang": null}
hermes/dialogueManager/configure {"intents":[{"enable":"false","intentId":"de.fhem:ConfirmAction"},{"enable":"false","intentId":"de.fhem:CancelAction"}],"siteId":"wohnzimmer"}
hermes/dialogueManager/endSession {"sessionId":"wohnzimmer-alexa-00abb350-fbc8-48ab-af1e-6ce6c31da5bb","siteId":"wohnzimmer","text":"Ok, mach ich"}
hermes/hotword/toggleOff {"siteId": "wohnzimmer", "reason": "ttsSay"}
hermes/hotword/toggleOn {"siteId": "wohnzimmer", "reason": "ttsSay"}
hermes/dialogueManager/sessionEnded {"termination": {"reason": "nominal"}, "sessionId": "wohnzimmer-alexa-00abb350-fbc8-48ab-af1e-6ce6c31da5bb", "siteId": "wohnzimmer", "customData": "alexa"}
hermes/hotword/toggleOn {"siteId": "wohnzimmer", "reason": "dialogueSession"}


hermes/hotword/alexa/detected {"modelId": "alexa", "modelVersion": "", "modelType": "personal", "currentSensitivity": 0.5, "siteId": "wohnzimmer", "sessionId": null, "sendAudioCaptured": null, "lang": null, "customEntities": null}
hermes/dialogueManager/sessionStarted {"sessionId": "wohnzimmer-alexa-0b6c8fdb-1c79-43d5-bd2f-a012eb8be478", "siteId": "wohnzimmer", "customData": "alexa", "lang": null}
hermes/hotword/toggleOff {"siteId": "wohnzimmer", "reason": "dialogueSession"}
hermes/hotword/toggleOn {"siteId": "wohnzimmer", "reason": "dialogueSession"}
hermes/dialogueManager/sessionEnded {"termination": {"reason": "intentNotRecognized"}, "sessionId": "wohnzimmer-alexa-0b6c8fdb-1c79-43d5-bd2f-a012eb8be478", "siteId": "wohnzimmer", "customData": "alexa"}
hermes/hotword/toggleOn {"siteId": "wohnzimmer", "reason": "dialogueSession"}


hermes/hotword/alexa/detected {"modelId": "alexa", "modelVersion": "", "modelType": "personal", "currentSensitivity": 0.5, "siteId": "wohnzimmer", "sessionId": null, "sendAudioCaptured": null, "lang": null, "customEntities": null}
hermes/dialogueManager/sessionStarted {"sessionId": "wohnzimmer-alexa-bc209f9e-7dc9-48b1-9adf-769176630668", "siteId": "wohnzimmer", "customData": "alexa", "lang": null}
hermes/hotword/toggleOff {"siteId": "wohnzimmer", "reason": "dialogueSession"}
hermes/hotword/toggleOn {"siteId": "wohnzimmer", "reason": "dialogueSession"}
hermes/intent/de.fhem:ConfirmAction {"input": "OK", "intent": {"intentName": "de.fhem:ConfirmAction", "confidenceScore": 1.0}, "siteId": "wohnzimmer", "id": null, "slots": [{"entity": "Mode", "value": {"kind": "Unknown", "value": "OK"}, "slotName": "Mode", "rawValue": "ja bitte", "confidence": 1.0, "range": {"start": 0, "end": 2, "rawStart": 0, "rawEnd": 8}}], "sessionId": "wohnzimmer-alexa-bc209f9e-7dc9-48b1-9adf-769176630668", "customData": "alexa", "asrTokens": [[{"value": "OK", "confidence": 1.0, "rangeStart": 0, "rangeEnd": 2, "time": null}]], "asrConfidence": 1.0, "rawInput": "ja bitte", "wakewordId": "alexa", "lang": null}
hermes/dialogueManager/endSession {"sessionId":"wohnzimmer-alexa-bc209f9e-7dc9-48b1-9adf-769176630668","siteId":"wohnzimmer","text":"warte grade nicht auf eine bestätigung"}
hermes/hotword/toggleOff {"siteId": "wohnzimmer", "reason": "ttsSay"}
hermes/hotword/toggleOn {"siteId": "wohnzimmer", "reason": "ttsSay"}
hermes/dialogueManager/sessionEnded {"termination": {"reason": "nominal"}, "sessionId": "wohnzimmer-alexa-bc209f9e-7dc9-48b1-9adf-769176630668", "siteId": "wohnzimmer", "customData": "alexa"}
hermes/hotword/toggleOn {"siteId": "wohnzimmer", "reason": "dialogueSession"}
Wenn configure genutzt wird, könnte doch intentFilter raus?.

Gruß Jens

p.s.
ZitatDa "global" zu agieren, (also erst beim "Aufräumen" alles zu aktivieren, um dann selektiv wieder zu deaktivieren) finde ich schwierig, weil es theoretisch ja sein kann, dass grade irgendeine weitere Sitzung läuft (muss nicht mal FHEM sein), in der auch nur bestimmte Intents zulässig sind.
Bisher habe ich es nicht geschafft, mit einer siteId gleichzeitig eine zweite Sitzung zu starten. War immer mit "anstehen".
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 11 Juni 2021, 07:48:23
Zitat von: JensS am 10 Juni 2021, 16:18:07
Nach der Antwort sollte  configure intents: [], siteId: wohnzimmerfolgen, um alle Intents zu aktivieren.
Abschließend dann {"intents": [{"intentId": "de.fhem:ConfirmAction", "enable": false}], "siteId": "wohnzimmer"}um ConfirmAction zu deaktivieren.

Ist nur so eine Idee - ungestestet. Zum testen deiner 10_RHASSPY.pm komme ich frühestens heute Abend.

Gestern Abend hatte ich das Ganze mal durchgespielt.

Das Zurücksetzen der Intents mit [] funktionierte problemlos.

Die Deaktivierung von ConfirmAction (u.a.) funktionierte nicht.
Egal, was ich machte - es wurden alle Intents (inkl. ConfirmAction) oder ausschließlich ConfirmAction aktiviert.
Quelle war: https://rhasspy-hermes.readthedocs.io/en/latest/api.html#rhasspyhermes.dialogue.DialogueConfigure (https://rhasspy-hermes.readthedocs.io/en/latest/api.html#rhasspyhermes.dialogue.DialogueConfigure)
Das Deaktivieren durch false funtionierte nicht mit und ohne " oder '.

Nun bleiben (aus meiner derzeitigen Sicht) genau zwei Möglichkeiten:

1. Ich bin zu blöd, die Matroschka aus JSON-Strings, Array und Strings zusammenzubauen.
2. Es handelt sich um ein BUG im Rhasspy.

Die zweite Möglichkeit wäre mir dabei persönlich lieber...

Gruß Jens
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 11 Juni 2021, 08:37:06
Zitat
2. Es handelt sich um ein BUG im Rhasspy.

Die zweite Möglichkeit wäre mir dabei persönlich lieber...
Ich halte das auch für wahrscheinlich.

Hinzu kommt folgendes: Ob es zu Sprachausgaben bei continueSession kommt oder nicht, scheint nach meinen Tests von zwei Faktoren abzuhängen:
- dem Inhalt der Payload und
- der verwendeten TTS-Engine...

nanoTTS scheint schon mit "filter"-Elementen überfordert zu sein, picoTTS kapituliert dann vor customData (jedenfalls, wenn da Sonderzeichen drin sind, was anderes ist nicht getestet).

Verwirrenderweise kommt dann relativ schnell ein "no one managed" in der App, obwohl ja eine Rückmeldung auf der MQTT-Ebene erfolgt.

Muss das mal irgendwie zusammenfassen und in die Rhasspy-Community geben, alleine kommen wir vermutlich an der Stelle nicht weiter.

Danke auch für's Testen mit dem ungequoteten false etc., das wäre noch eine offene Frage gewesen.

ZitatEgal, was ich machte - es wurden alle Intents (inkl. ConfirmAction) oder ausschließlich ConfirmAction aktiviert.
Hier hatte ich eher den Eindruck, dass immer alles aktiv war, von daher stellt sich mir eher die Frage, ob überhaupt irgendwas "Zurückzusetzen" war...
Aber wenn es bei dir ging, das auf ConfirmAction zu beschränken, dann stimmt vermutlich was mit unserer payload bei den Arrays nicht.

...dickes Brett...
(Und leider wohl auch noch konfigurationsabhängig; sehr unschön!)
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 11 Juni 2021, 17:57:59
Ich denke, dass die Objekttypen nicht passen.
Der folgende Versuch geht zwar auch ins Leere, ist aber ausbaufähig.
\0==false, \1==true

Somit ist "false" (String) größer als null und ergibt true (bool).

    my %jsonHash = (intents => [{'intentId'=>'de.fhem:ConfirmAction','enable'=>\0}],'siteId'=>'wohnzimmer');
my $jsonString = encode_json \%jsonHash;
IOWrite($hash, 'publish', qq{hermes/dialogueManager/configure $jsonString}) if $enable eq "false";

Gruß Jens

p.s. Interessante Quelle zu intentFiler und slot - wird vielleicht noch: https://rhasspy-hermes.readthedocs.io/en/latest/api.html#rhasspyhermes.dialogue.DialogueContinueSession (https://rhasspy-hermes.readthedocs.io/en/latest/api.html#rhasspyhermes.dialogue.DialogueContinueSession)

p.p.s.
Sollten wir für den Filter einen eigenen Thread aufmachen?
Bei der Basis habe ich mal als root "rhasspy -p de" per Konsole gestartet und auch dort interessante Infos gefunden:root@rhasspy-base:~# mosquitto_pub -h 192.168.x.x -p 1883 -t hermes/dialogueManager/configure -m '{"intents": [{"intentId": "de.fhem:ConfirmAction", "enable": false}], "siteId": "wohnzimmer"}'
root@rhasspy-base:~# mosquitto_pub -h 192.168.x.x -p 1883 -t hermes/dialogueManager/configure -m '{"intents": [{"intentId": "de.fhem:ConfirmAction", "enable": true}], "siteId": "wohnzimmer"}'
root@rhasspy-base:~# mosquitto_pub -h 192.168.x.x -p 1883 -t hermes/dialogueManager/configure -m '{"intents": [], "siteId": "wohnzimmer"}'

root@rhasspy-base:~# mosquitto_sub -h 192.168.x.x -p 1883 -v -t hermes/dialogueManager/# -t hermes/hotword/# -t hermes/intent/#
hermes/dialogueManager/configure {"intents": [{"intentId": "de.fhem:ConfirmAction", "enable": false}], "siteId": "wohnzimmer"}
hermes/dialogueManager/configure {"intents": [{"intentId": "de.fhem:ConfirmAction", "enable": true}], "siteId": "wohnzimmer"}
hermes/dialogueManager/configure {"intents": [], "siteId": "wohnzimmer"}

Hier die Debug-Ausgaben von der Rhasspy-Base:[DEBUG:2021-06-12 09:42:11,847] rhasspydialogue_hermes: <- DialogueConfigure(intents=[DialogueConfigureIntent(intent_id='de.fhem:ConfirmAction', enable=False)], site_id='wohnzimmer')
[DEBUG:2021-06-12 09:42:11,848] rhasspydialogue_hermes: Removed default intent filter
[DEBUG:2021-06-12 09:43:07,664] rhasspydialogue_hermes: <- DialogueConfigure(intents=[DialogueConfigureIntent(intent_id='de.fhem:ConfirmAction', enable=True)], site_id='wohnzimmer')
[DEBUG:2021-06-12 09:43:07,665] rhasspydialogue_hermes: Default intent filter set: ['de.fhem:ConfirmAction']
[DEBUG:2021-06-12 09:43:39,805] rhasspydialogue_hermes: <- DialogueConfigure(intents=[], site_id='wohnzimmer')
[DEBUG:2021-06-12 09:43:39,805] rhasspydialogue_hermes: Removed default intent filter

Das Verhalten sieht anders aus als erwartet/verstanden.
Einem "default intent filter" können Intents hinzugefügt (enable=true) oder daraus entfernt (enable=false) werden. Eine Negation ist nicht vorgesehen.  :(
Ich schlage vor, aktuell den intentFilter in continueSession zu verwenden um die Antwortmöglichkeiten einzuschränken.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 13 Juni 2021, 07:00:04
Zitat von: JensS am 11 Juni 2021, 17:57:59
Ich denke, dass die Objekttypen nicht passen.
Vermutlich hast du recht, und nach meinen Tests ist Rhasspy auch etwas "sensibel", was die Syntax angeht.

"encode_json" hatte ich auch (ohne die escapten Wahrheitswerte) getestet, aber da taucht dann wieder das utf8-Problem auf. Daher bin ich jetzt den anderen Weg gegangen, "Nachbearbeitungscode" für toJSON zu verwenden, damit neben true/false auch die Reihenfolge der Schlüssel für Rhasspy gedreht werden kann usw..

Damit habe ich zumindest nicht mehr den Effekt, dass die TTS-Enginge (getestet aber nur mit nanoTTS) ins Straucheln kommt; ist ja schon mal was...

Zitat
p.s. Interessante Quelle zu intentFiler und slot - wird vielleicht noch: https://rhasspy-hermes.readthedocs.io/en/latest/api.html#rhasspyhermes.dialogue.DialogueContinueSession (https://rhasspy-hermes.readthedocs.io/en/latest/api.html#rhasspyhermes.dialogue.DialogueContinueSession)
Thx. Leider bleiben da (für mich) weiter Fragen offen, "an sich" würde ich behaupten wollen, dass die Payload jetzt so aussieht, wie das vorgesehen ist - abgesehen davon, dass Rhasspy ggf. nur einen einfachen Text für den intentFilter erwartet, wir aber eine Mehrzahl von Objekten schicken (was aber mAn. auch sinnvoll ist).

Zitat
p.p.s.
Sollten wir für den Filter einen eigenen Thread aufmachen?
Für die Rhasspy-Seite habe ich zu den ganzen Themen mal hier was angefangen: https://community.rhasspy.org/t/lost-in-dialogues-customdata-intentfilter-and-dialoguemanager-configure/2890 (https://community.rhasspy.org/t/lost-in-dialogues-customdata-intentfilter-and-dialoguemanager-configure/2890)

Hier im Forum würde ich sagen: muss nicht, das Thema ist einfach der nächste Punkt auf der ToDo...

Zitat
Bei der Basis habe ich mal als root "rhasspy -p de" per Konsole gestartet und auch dort interessante Infos gefunden: [...]
Das Verhalten sieht anders aus als erwartet/verstanden.
Einem "default intent filter" können Intents hinzugefügt (enable=true) oder daraus entfernt (enable=false) werden. Eine Negation ist nicht vorgesehen.  :(
Ich schlage vor, aktuell den intentFilter in continueSession zu verwenden um die Antwortmöglichkeiten einzuschränken.
Das ist in der Tat interessant, auch wenn ich die Logik mit dem "default intent filter" eigentlich genau so verstanden zu haben glaube (und aus diesem Grund die "globale Aktivierung" für keine gute Idee halte).

Im Moment ist es jedenfalls so, dass in meinem System weder intentFilter noch die enable:true/false-Variante über den dialogManager irgendwelche Auswirkungen haben. Ich werde das demnächst auch noch im Rhasspy-Thread mit etwas Topic/payload darstellen und hoffe, dass sich da dann jemand meldet, der erläutern kann, wo der Hase im Pfeffer liegt...

Vielleicht könntest du bei Gelegenheit die debug-Ausgaben für "switchDM=1" mal checken, ob da abzulesen ist, was da ankommt und wie es verarbeitet wird?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 13 Juni 2021, 10:36:19
Hab mir mal deine angehangene Vesion angesehen:    my $enable    = shift // q{false};q{false} ist ein String und wird von Rhasspy als true (bool) erkannt. Somit sollten keine Intents, außer ConfirmAction, etc. erkannt werden.
In meinen Versuchen verwende ich nur den Intent ConfirmAction, weil ich nicht so viel tippen möchte. Natürlich sind die Beispiele/Ergebnisse auf mehrere Intents erweiterbar.
In continueSession intentFilter können auch mehrere Intents gesandt werden - so verstehe ich zumindestens intentFilter: [string]? = null - valid intent names (null means all).

Gruß Jens
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Raemsna am 13 Juni 2021, 11:16:01
Hi zusammen,

ich hab mal wieder eine Frage an die Profis:
Ist es möglich (in Rhasspy selbst oder in FHEM) eine beliebige siteid für Sprachausgaben / Antworten von Befehlen auszuwählen?

Hintergrund: An meiner Base ist ein Mikrofon für WakeWord und Ausführung der eingesprochenen Befehle.
Allerdings habe ich daran keine Lautsprecher, wo die Ergebnisse ausgegeben werden können.

Stattdessen nutze ich auf zwei meiner Handys die Rhasspy App, wo Sprachausgabe (und auch Befehle einsprechen) ohne Probleme funktioniert.

Also:
Kann ich die Antwort eines eingesprochenen Befehls auf der Base ("default") z.B. auf der siteid mobile-app1 ausgeben?

danke schon wieder.

P.S.: Vielen Dank für die tolle Implementierung on-for-timer. Läuft erste Klasse!!!

Grüße
Raemsna
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 13 Juni 2021, 13:25:38
@Raemsna
Bin zwar kein Profi habe aber einen Tipp.
Installiere mosquitto_pub mit "apt-get install mosquitto-clients".
Erstelle eine Datei /opt/ausgabe.sh mit folgendem Inhalt:#!/bin/bash
cat $1 > /tmp/handy.wav && /usr/bin/mosquitto_pub -p 1883 -t hermes/audioServer/mobile-app1/playBytes/usjro -f /tmp/handy.wav
Eventuell muss der Port angepasst werden oder/und der Host mit -h 192.168... hinzugefügt werden.
Passe die Rechte mit "chmod 755 /opt/ausgabe.sh" an.
Trage folgendes in der Base ein - settings -> "Audio Playing" -> "Local Command" -> "Program": /opt/ausgabe.sh
Das war's schon.

Gruß Jens
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Raemsna am 13 Juni 2021, 18:06:07
Zitat von: JensS am 13 Juni 2021, 13:25:38
@Raemsna
Bin zwar kein Profi habe aber einen Tipp.
Installiere mosquitto_pub mit "apt-get install mosquitto-clients".
Erstelle eine Datei /opt/ausgabe.sh mit folgendem Inhalt:#!/bin/bash
cat $1 > /tmp/handy.wav && /usr/bin/mosquitto_pub -p 1883 -t hermes/audioServer/mobile-app1/playBytes/usjro -f /tmp/handy.wav
Eventuell muss der Port angepasst werden oder/und der Host mit -h 192.168... hinzugefügt werden.
Passe die Rechte mit "chmod 755 /opt/ausgabe.sh" an.
Trage folgendes in der Base ein - settings -> "Audio Playing" -> "Local Command" -> "Program": /opt/ausgabe.sh
Das war's schon.

Gruß Jens

Dankeschön! Werde ich ausprobieren! :)
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 14 Juni 2021, 07:31:32
Zitat von: Raemsna am 13 Juni 2021, 11:16:01
P.S.: Vielen Dank für die tolle Implementierung on-for-timer. Läuft erste Klasse!!!
Danke vorab mal für die Rückmeldung!  :)

Zitat
Ist es möglich (in Rhasspy selbst oder in FHEM) eine beliebige siteid für Sprachausgaben / Antworten von Befehlen auszuwählen?
Derzeit ist es im Modul nicht vorgesehen.
An sich sollte es aber kein größeres Problem sein, das zu ergänzen, für alle Antworten wird zentraler Code verwendet, den man z.B. (ähnlich zu siteId2room()) um eine Reading-Auswertung ergänzen könnte, um dann die Audioausgabe zu doppeln (via speak-Befehl).
Vorteil: man könnte es @runtime ohne weiteres ändern.
Einziges Problem, das mir einfällt: Sonstige Audioausgaben, v.a. soundfiles bei abgelaufenem Timer sollte man wohl auch umleiten, und das bräuchte vermutlich auch (wenig) Extracode.

Falls noch Bedarf besteht, schaue ich mir das mal an.

Zitat von: JensS am 13 Juni 2021, 10:36:19
Hab mir mal deine angehangene Vesion angesehen:    my $enable    = shift // q{false};q{false} ist ein String und wird von Rhasspy als true (bool) erkannt. Somit sollten keine Intents, außer ConfirmAction, etc. erkannt werden.
Bezieht sich das auf die Version von gestern morgen?

Schon klar, dass dieser Code-Teil weiter so drin steht, aber die Payload wird hinterher "gereinigt", und es würde mich interessieren, ob es jetzt immer noch so ist, oder ob es geholfen hat, die Quotes vor dem Versenden zu entfernen?

Ansonsten könnte man beim Bereinigen auch mal versuchen, da die bool'schen Werte nummerisch (und ohne Quotes) zu übertragen?
(Der toCleanJSON-Code ist ganz am Ende zu finden).
Zitat
In meinen Versuchen verwende ich nur den Intent ConfirmAction, weil ich nicht so viel tippen möchte. Natürlich sind die Beispiele/Ergebnisse auf mehrere Intents erweiterbar.
In continueSession intentFilter können auch mehrere Intents gesandt werden - so verstehe ich zumindestens intentFilter: [string]? = null - valid intent names (null means all).

Gruß Jens
Sehe ich auch so. Nur, dass das dann ein Array ist, das man zusammensetzen muss, was ggf. weitere "Möglichkeiten bietet", Syntaxfehler reinzubasteln...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 14 Juni 2021, 15:45:33
Zitat von: Beta-User am 14 Juni 2021, 07:31:32
(Der toCleanJSON-Code ist ganz am Ende zu finden)

Ok - und sorry. Habe zu flüchtig drübergeschaut...
Jetzt wird's richtig übertragen.

p.s. intentNotRecognized wird abgefangen aber kein reconfigure ausgeführt.hermes/hotword/alexa/detected {"modelId": "alexa", "modelVersion": "", "modelType": "personal", "currentSensitivity": 0.5, "siteId": "wohnzimmer", "sessionId": null, "sendAudioCaptured": null, "lang": null, "customEntities": null}
hermes/dialogueManager/sessionStarted {"sessionId": "wohnzimmer-alexa-8331bc08-5821-4133-a89c-d5cbe92c56f1", "siteId": "wohnzimmer", "customData": "alexa", "lang": null}
hermes/hotword/toggleOff {"siteId": "wohnzimmer", "reason": "dialogueSession"}
hermes/hotword/toggleOn {"siteId": "wohnzimmer", "reason": "dialogueSession"}
hermes/intent/de.fhem:Shortcuts {"input": "Beleuchtung einschalten", "intent": {"intentName": "de.fhem:Shortcuts", "confidenceScore": 1.0}, "siteId": "wohnzimmer", "id": null, "slots": [], "sessionId": "wohnzimmer-alexa-8331bc08-5821-4133-a89c-d5cbe92c56f1", "customData": "alexa", "asrTokens": [[{"value": "Beleuchtung", "confidence": 1.0, "rangeStart": 0, "rangeEnd": 11, "time": null}, {"value": "einschalten", "confidence": 1.0, "rangeStart": 12, "rangeEnd": 23, "time": null}]], "asrConfidence": 1.0, "rawInput": "beleuchtung einschalten", "wakewordId": "alexa", "lang": null}
hermes/dialogueManager/configure {"intents":[{"intentId": "de.fhem:ConfirmAction","enable": true},{"intentId": "de.fhem:CancelAction","enable": true}],"siteId": "wohnzimmer"}
hermes/dialogueManager/continueSession {"customData": "alexa","intentFilter":["de.fhem:ConfirmAction","de.fhem:CancelAction"],"sendIntentNotRecognized": false,"sessionId": "wohnzimmer-alexa-8331bc08-5821-4133-a89c-d5cbe92c56f1","siteId": "wohnzimmer","text": "Soll ich die Stehlampe wirklich einschalten?"}
hermes/hotword/toggleOff {"siteId": "wohnzimmer", "reason": "dialogueSession"}
hermes/hotword/toggleOff {"siteId": "wohnzimmer", "reason": "ttsSay"}
hermes/hotword/toggleOn {"siteId": "wohnzimmer", "reason": "ttsSay"}
hermes/hotword/toggleOn {"siteId": "wohnzimmer", "reason": "dialogueSession"}
hermes/dialogueManager/sessionEnded {"termination": {"reason": "intentNotRecognized"}, "sessionId": "wohnzimmer-alexa-8331bc08-5821-4133-a89c-d5cbe92c56f1", "siteId": "wohnzimmer", "customData": "alexa"}
hermes/hotword/toggleOn {"siteId": "wohnzimmer", "reason": "dialogueSession"}
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Raemsna am 14 Juni 2021, 20:04:46
Zitat von: Beta-User am 14 Juni 2021, 07:31:32
Falls noch Bedarf besteht, schaue ich mir das mal an.
Hi zusammen,

falls das "relativ unaufwendig" umzusetzen ist und du Lust drauf hast, fände ich das natürlich Klasse.
Vorteil wäre aus meiner Sicht, dass man flexibel (ohne große Änderungen in einer bash datei o.Ä.) aus FHEM heraus die Ausgabe siteid anpassen könnte.

Und mit der Rhasspy App ist man - zumindest in Android - ja wunderbar flexibel verschiedene Geräte für Sprachein-/ausgaben einzubinden...

Super coole Sache das ganze :)
Raemsna
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 15 Juni 2021, 07:58:18
Zitat von: JensS am 14 Juni 2021, 15:45:33
Jetzt wird's richtig übertragen.
Muss mal schauen, dass ich mir das auch mal im Debug-Modus ansehe. Die eigentliche Frage ist ja, ob es wirksam ist. Leider hatte ich bei meinen Tests bisher eher nicht den Eindruck.

Zitat
p.s. intentNotRecognized wird abgefangen aber kein reconfigure ausgeführt.
Der DialogManager wird nur dann für das reconfigure (ständig) aufgerufen, wenn die Option in der DEF gesetzt ist, wie hier erwähnt:
Zitat von: Beta-User am 13 Juni 2021, 07:00:04
Vielleicht könntest du bei Gelegenheit die debug-Ausgaben für "switchDM=1" mal checken, ob da abzulesen ist, was da ankommt und wie es verarbeitet wird?

Zitat von: Raemsna am 14 Juni 2021, 20:04:46
falls das "relativ unaufwendig" umzusetzen ist [...]
Ich schau's mir auf alle Fälle an. Bauchgefühl sagt: sollte ohne allzu große Aufwände gehen, aber das kann auch falsch sein...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 15 Juni 2021, 10:46:52
Zitat von: Beta-User am 15 Juni 2021, 07:58:18
Ich schau's mir auf alle Fälle an. Bauchgefühl sagt: sollte ohne allzu große Aufwände gehen, aber das kann auch falsch sein...
:) Bitte testen...
siteId2doubleSpeak_<siteId>

Anwendungshinweise (auch zu siteId2room) sind am Ende der cref ergänzt.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 15 Juni 2021, 20:47:35
switchDM=1 war/ist gesetzt2021.06.15 20:40:40 5: RHASSPY: [Rhasspy] Parse (IO: rhasspyMQTT2): Msg: hermes/dialogueManager/sessionStarted => {"sessionId": "wohnzimmer-alexa-ec0d2905-0df4-4454-a6fb-3516cf8671c0", "siteId": "wohnzimmer", "customData": "alexa", "lang": null}
2021.06.15 20:40:40 5: Parsed value: wohnzimmer-alexa-ec0d2905-0df4-4454-a6fb-3516cf8671c0 for key: sessionId
2021.06.15 20:40:40 5: Parsed value: alexa for key: customData
2021.06.15 20:40:40 5: Parsed value: wohnzimmer for key: siteId
2021.06.15 20:40:40 5: room is identified using siteId as wohnzimmer
2021.06.15 20:40:43 5: RHASSPY: [Rhasspy] Parse (IO: rhasspyMQTT2): Msg: hermes/intent/de.fhem_Shortcuts => {"input": "Beleuchtung einschalten", "intent": {"intentName": "de.fhem:Shortcuts", "confidenceScore": 1.0}, "siteId": "wohnzimmer", "id": null, "slots": [], "sessionId": "wohnzimmer-alexa-ec0d2905-0df4-4454-a6fb-3516cf8671c0", "customData": "alexa", "asrTokens": [[{"value": "Beleuchtung", "confidence": 1.0, "rangeStart": 0, "rangeEnd": 11, "time": null}, {"value": "einschalten", "confidence": 1.0, "rangeStart": 12, "rangeEnd": 23, "time": null}]], "asrConfidence": 1.0, "rawInput": "beleuchtung einschalten", "wakewordId": "alexa", "lang": null}
2021.06.15 20:40:43 5: Parsed value: wohnzimmer-alexa-ec0d2905-0df4-4454-a6fb-3516cf8671c0 for key: sessionId
2021.06.15 20:40:43 5: Parsed value: beleuchtung einschalten for key: rawInput
2021.06.15 20:40:43 5: Parsed value: 1 for key: probability
2021.06.15 20:40:43 5: Parsed value: Shortcuts for key: intent
2021.06.15 20:40:43 5: Parsed value: alexa for key: customData
2021.06.15 20:40:43 5: Parsed value: Beleuchtung einschalten for key: input
2021.06.15 20:40:43 5: Parsed value: wohnzimmer for key: siteId
2021.06.15 20:40:43 5: handleIntentShortcuts called with Beleuchtung einschalten key
2021.06.15 20:40:43 5: [Rhasspy] setting  Timer: Rhasspy_wohnzimmer-alexa-ec0d2905-0df4-4454-a6fb-3516cf8671c0 2021-06-15 20:40:53
2021.06.15 20:40:43 3: R-DM for Rhasspy called
2021.06.15 20:40:43 5: Response is: HASH(0x55c4c6e4b1a0)
2021.06.15 20:40:48 5: RHASSPY: [Rhasspy] Parse (IO: rhasspyMQTT2): Msg: hermes/intent/de.fhem_ConfirmAction => {"input": "OK", "intent": {"intentName": "de.fhem:ConfirmAction", "confidenceScore": 1.0}, "siteId": "wohnzimmer", "id": null, "slots": [{"entity": "Mode", "value": {"kind": "Unknown", "value": "OK"}, "slotName": "Mode", "rawValue": "ja bitte", "confidence": 1.0, "range": {"start": 0, "end": 2, "rawStart": 0, "rawEnd": 8}}], "sessionId": "wohnzimmer-alexa-ec0d2905-0df4-4454-a6fb-3516cf8671c0", "customData": "alexa", "asrTokens": [[{"value": "OK", "confidence": 1.0, "rangeStart": 0, "rangeEnd": 2, "time": null}]], "asrConfidence": 1.0, "rawInput": "ja bitte", "wakewordId": "alexa", "lang": null}
2021.06.15 20:40:48 5: Parsed value: OK for key: Mode
2021.06.15 20:40:48 5: Parsed value: ConfirmAction for key: intent
2021.06.15 20:40:48 5: Parsed value: alexa for key: customData
2021.06.15 20:40:48 5: Parsed value: wohnzimmer-alexa-ec0d2905-0df4-4454-a6fb-3516cf8671c0 for key: sessionId
2021.06.15 20:40:48 5: Parsed value: 1 for key: probability
2021.06.15 20:40:48 5: Parsed value: ja bitte for key: rawInput
2021.06.15 20:40:48 5: Parsed value: wohnzimmer for key: siteId
2021.06.15 20:40:48 5: Parsed value: OK for key: input
2021.06.15 20:40:48 5: handleIntentConfirmAction called
2021.06.15 20:40:48 5: [Rhasspy] removing Timer: Rhasspy_wohnzimmer-alexa-ec0d2905-0df4-4454-a6fb-3516cf8671c0
2021.06.15 20:40:48 3: R-DM for Rhasspy called
2021.06.15 20:40:48 5: handleIntentShortcuts called with Beleuchtung einschalten key
2021.06.15 20:40:48 5: cmd selected: Ok, mach ich
2021.06.15 20:40:48 5: FHEM shortcut identified: set Stehlampe on, device name is Rhasspy
2021.06.15 20:40:48 5: _replace from RHASSPY::handleIntentShortcuts starting with: set Stehlampe on
2021.06.15 20:40:48 5: _replace from RHASSPY::handleIntentShortcuts returns: set Stehlampe on
2021.06.15 20:40:48 5: _replace from RHASSPY::handleIntentShortcuts starting with: Ok, mach ich
2021.06.15 20:40:48 5: _replace from RHASSPY::handleIntentShortcuts returns: Ok, mach ich
2021.06.15 20:40:48 5: Response is: Ok, mach ich
2021.06.15 20:40:50 5: RHASSPY: [Rhasspy] Parse (IO: rhasspyMQTT2): Msg: hermes/dialogueManager/sessionEnded => {"termination": {"reason": "nominal"}, "sessionId": "wohnzimmer-alexa-ec0d2905-0df4-4454-a6fb-3516cf8671c0", "siteId": "wohnzimmer", "customData": "alexa"}
2021.06.15 20:40:50 5: Parsed value: wohnzimmer for key: siteId
2021.06.15 20:40:50 5: Parsed value: alexa for key: customData
2021.06.15 20:40:50 5: Parsed value: wohnzimmer-alexa-ec0d2905-0df4-4454-a6fb-3516cf8671c0 for key: sessionId
2021.06.15 20:40:50 5: room is identified using siteId as wohnzimmer
2021.06.15 20:40:54 5: RHASSPY: [Rhasspy] Parse (IO: rhasspyMQTT2): Msg: hermes/dialogueManager/sessionStarted => {"sessionId": "wohnzimmer-alexa-86430f81-b87e-4746-8b48-9d8d5a74ef0b", "siteId": "wohnzimmer", "customData": "alexa", "lang": null}
2021.06.15 20:40:54 5: Parsed value: wohnzimmer-alexa-86430f81-b87e-4746-8b48-9d8d5a74ef0b for key: sessionId
2021.06.15 20:40:54 5: Parsed value: wohnzimmer for key: siteId
2021.06.15 20:40:54 5: Parsed value: alexa for key: customData
2021.06.15 20:40:54 5: room is identified using siteId as wohnzimmer
2021.06.15 20:40:56 5: RHASSPY: [Rhasspy] Parse (IO: rhasspyMQTT2): Msg: hermes/intent/de.fhem_SetOnOff => {"input": "stehlampe off", "intent": {"intentName": "de.fhem:SetOnOff", "confidenceScore": 1.0}, "siteId": "wohnzimmer", "id": null, "slots": [{"entity": "de.fhem.Device", "value": {"kind": "Unknown", "value": "stehlampe"}, "slotName": "Device", "rawValue": "stehlampe", "confidence": 1.0, "range": {"start": 0, "end": 9, "rawStart": 0, "rawEnd": 9}}, {"entity": "Value", "value": {"kind": "Unknown", "value": "off"}, "slotName": "Value", "rawValue": "aus", "confidence": 1.0, "range": {"start": 10, "end": 13, "rawStart": 10, "rawEnd": 13}}], "sessionId": "wohnzimmer-alexa-86430f81-b87e-4746-8b48-9d8d5a74ef0b", "customData": "alexa", "asrTokens": [[{"value": "stehlampe", "confidence": 1.0, "rangeStart": 0, "rangeEnd": 9, "time": null}, {"value": "off", "confidence": 1.0, "rangeStart": 10, "rangeEnd": 13, "time": null}]], "asrConfidence": 0.99669105, "rawInput": "stehlampe aus", "wakewordId": "alexa", "lang": null}
2021.06.15 20:40:56 5: Parsed value: SetOnOff for key: intent
2021.06.15 20:40:56 5: Parsed value: alexa for key: customData
2021.06.15 20:40:56 5: Parsed value: stehlampe for key: Device
2021.06.15 20:40:56 5: Parsed value: wohnzimmer-alexa-86430f81-b87e-4746-8b48-9d8d5a74ef0b for key: sessionId
2021.06.15 20:40:56 5: Parsed value: stehlampe aus for key: rawInput
2021.06.15 20:40:56 5: Parsed value: 1 for key: probability
2021.06.15 20:40:56 5: Parsed value: off for key: Value
2021.06.15 20:40:56 5: Parsed value: stehlampe off for key: input
2021.06.15 20:40:56 5: Parsed value: wohnzimmer for key: siteId
2021.06.15 20:40:56 5: handleIntentSetOnOff called
2021.06.15 20:40:56 5: room is identified using siteId as wohnzimmer
2021.06.15 20:40:56 5: Device selected (by hash, with room and name): Stehlampe
2021.06.15 20:40:56 5: analyzeAndRunCmd called with command: off
2021.06.15 20:40:56 5: Stehlampe off is a normal command
2021.06.15 20:40:56 5: Running command [off] on device [Stehlampe]
2021.06.15 20:40:56 5: analyzeAndRunCmd called with command: {ResponseOnOff($DEVICE)}
2021.06.15 20:40:56 5: {ResponseOnOff($DEVICE)} is a perl command
2021.06.15 20:40:56 5: Response is Ok - Stehlampe im wohnzimmer ist ausgeschaltet
2021.06.15 20:40:56 5: Response is: Ok - Stehlampe im wohnzimmer ist ausgeschaltet
2021.06.15 20:41:00 5: RHASSPY: [Rhasspy] Parse (IO: rhasspyMQTT2): Msg: hermes/dialogueManager/sessionEnded => {"termination": {"reason": "nominal"}, "sessionId": "wohnzimmer-alexa-86430f81-b87e-4746-8b48-9d8d5a74ef0b", "siteId": "wohnzimmer", "customData": "alexa"}
2021.06.15 20:41:00 5: Parsed value: alexa for key: customData
2021.06.15 20:41:00 5: Parsed value: wohnzimmer for key: siteId
2021.06.15 20:41:00 5: Parsed value: wohnzimmer-alexa-86430f81-b87e-4746-8b48-9d8d5a74ef0b for key: sessionId
2021.06.15 20:41:00 5: room is identified using siteId as wohnzimmer
2021.06.15 20:41:02 5: RHASSPY: [Rhasspy] Parse (IO: rhasspyMQTT2): Msg: hermes/dialogueManager/sessionStarted => {"sessionId": "wohnzimmer-alexa-371e5021-c17c-46fd-ae8b-a0199d2863ef", "siteId": "wohnzimmer", "customData": "alexa", "lang": null}
2021.06.15 20:41:02 5: Parsed value: alexa for key: customData
2021.06.15 20:41:02 5: Parsed value: wohnzimmer for key: siteId
2021.06.15 20:41:02 5: Parsed value: wohnzimmer-alexa-371e5021-c17c-46fd-ae8b-a0199d2863ef for key: sessionId
2021.06.15 20:41:02 5: room is identified using siteId as wohnzimmer
2021.06.15 20:41:05 5: RHASSPY: [Rhasspy] Parse (IO: rhasspyMQTT2): Msg: hermes/intent/de.fhem_Shortcuts => {"input": "Beleuchtung einschalten", "intent": {"intentName": "de.fhem:Shortcuts", "confidenceScore": 1.0}, "siteId": "wohnzimmer", "id": null, "slots": [], "sessionId": "wohnzimmer-alexa-371e5021-c17c-46fd-ae8b-a0199d2863ef", "customData": "alexa", "asrTokens": [[{"value": "Beleuchtung", "confidence": 1.0, "rangeStart": 0, "rangeEnd": 11, "time": null}, {"value": "einschalten", "confidence": 1.0, "rangeStart": 12, "rangeEnd": 23, "time": null}]], "asrConfidence": 1.0, "rawInput": "beleuchtung einschalten", "wakewordId": "alexa", "lang": null}
2021.06.15 20:41:05 5: Parsed value: alexa for key: customData
2021.06.15 20:41:05 5: Parsed value: Shortcuts for key: intent
2021.06.15 20:41:05 5: Parsed value: wohnzimmer-alexa-371e5021-c17c-46fd-ae8b-a0199d2863ef for key: sessionId
2021.06.15 20:41:05 5: Parsed value: 1 for key: probability
2021.06.15 20:41:05 5: Parsed value: beleuchtung einschalten for key: rawInput
2021.06.15 20:41:05 5: Parsed value: Beleuchtung einschalten for key: input
2021.06.15 20:41:05 5: Parsed value: wohnzimmer for key: siteId
2021.06.15 20:41:05 5: handleIntentShortcuts called with Beleuchtung einschalten key
2021.06.15 20:41:05 5: [Rhasspy] setting  Timer: Rhasspy_wohnzimmer-alexa-371e5021-c17c-46fd-ae8b-a0199d2863ef 2021-06-15 20:41:15
2021.06.15 20:41:05 3: R-DM for Rhasspy called
2021.06.15 20:41:05 5: Response is: HASH(0x55c4c7742080)
2021.06.15 20:41:11 5: RHASSPY: [Rhasspy] Parse (IO: rhasspyMQTT2): Msg: hermes/intent/de.fhem_ConfirmAction => {"input": "Abbruch", "intent": {"intentName": "de.fhem:ConfirmAction", "confidenceScore": 1.0}, "siteId": "wohnzimmer", "id": null, "slots": [{"entity": "Mode", "value": {"kind": "Unknown", "value": "Abbruch"}, "slotName": "Mode", "rawValue": "nein danke", "confidence": 1.0, "range": {"start": 0, "end": 7, "rawStart": 0, "rawEnd": 10}}], "sessionId": "wohnzimmer-alexa-371e5021-c17c-46fd-ae8b-a0199d2863ef", "customData": "alexa", "asrTokens": [[{"value": "Abbruch", "confidence": 1.0, "rangeStart": 0, "rangeEnd": 7, "time": null}]], "asrConfidence": 1.0, "rawInput": "nein danke", "wakewordId": "alexa", "lang": null}
2021.06.15 20:41:11 5: Parsed value: Abbruch for key: input
2021.06.15 20:41:11 5: Parsed value: wohnzimmer for key: siteId
2021.06.15 20:41:11 5: Parsed value: alexa for key: customData
2021.06.15 20:41:11 5: Parsed value: Abbruch for key: Mode
2021.06.15 20:41:11 5: Parsed value: ConfirmAction for key: intent
2021.06.15 20:41:11 5: Parsed value: wohnzimmer-alexa-371e5021-c17c-46fd-ae8b-a0199d2863ef for key: sessionId
2021.06.15 20:41:11 5: Parsed value: 1 for key: probability
2021.06.15 20:41:11 5: Parsed value: nein danke for key: rawInput
2021.06.15 20:41:11 5: handleIntentConfirmAction called
2021.06.15 20:41:11 5: handleIntentCancelAction called
2021.06.15 20:41:11 5: [Rhasspy] removing Timer: Rhasspy_wohnzimmer-alexa-371e5021-c17c-46fd-ae8b-a0199d2863ef
2021.06.15 20:41:11 5: Response is: Habe abgebrochen
2021.06.15 20:41:11 3: R-DM for Rhasspy called
2021.06.15 20:41:13 5: RHASSPY: [Rhasspy] Parse (IO: rhasspyMQTT2): Msg: hermes/dialogueManager/sessionEnded => {"termination": {"reason": "nominal"}, "sessionId": "wohnzimmer-alexa-371e5021-c17c-46fd-ae8b-a0199d2863ef", "siteId": "wohnzimmer", "customData": "alexa"}
2021.06.15 20:41:13 5: Parsed value: wohnzimmer-alexa-371e5021-c17c-46fd-ae8b-a0199d2863ef for key: sessionId
2021.06.15 20:41:13 5: Parsed value: alexa for key: customData
2021.06.15 20:41:13 5: Parsed value: wohnzimmer for key: siteId
2021.06.15 20:41:13 5: room is identified using siteId as wohnzimmer
2021.06.15 20:41:16 5: RHASSPY: [Rhasspy] Parse (IO: rhasspyMQTT2): Msg: hermes/dialogueManager/sessionStarted => {"sessionId": "wohnzimmer-alexa-91813434-a7cf-464e-b272-e3d9cd6ef03a", "siteId": "wohnzimmer", "customData": "alexa", "lang": null}
2021.06.15 20:41:16 5: Parsed value: wohnzimmer for key: siteId
2021.06.15 20:41:16 5: Parsed value: alexa for key: customData
2021.06.15 20:41:16 5: Parsed value: wohnzimmer-alexa-91813434-a7cf-464e-b272-e3d9cd6ef03a for key: sessionId
2021.06.15 20:41:16 5: room is identified using siteId as wohnzimmer
2021.06.15 20:41:19 5: RHASSPY: [Rhasspy] Parse (IO: rhasspyMQTT2): Msg: hermes/intent/de.fhem_SetNumeric => {"input": "stehlampe 31", "intent": {"intentName": "de.fhem:SetNumeric", "confidenceScore": 1.0}, "siteId": "wohnzimmer", "id": null, "slots": [{"entity": "de.fhem.Device", "value": {"kind": "Unknown", "value": "stehlampe"}, "slotName": "Device", "rawValue": "stehlampe", "confidence": 1.0, "range": {"start": 0, "end": 9, "rawStart": 0, "rawEnd": 9}}, {"entity": "rhasspy/number", "value": {"kind": "Number", "value": 31}, "slotName": "Value", "rawValue": "einunddreißig", "confidence": 1.0, "range": {"start": 10, "end": 12, "rawStart": 10, "rawEnd": 23}}], "sessionId": "wohnzimmer-alexa-91813434-a7cf-464e-b272-e3d9cd6ef03a", "customData": "alexa", "asrTokens": [[{"value": "stehlampe", "confidence": 1.0, "rangeStart": 0, "rangeEnd": 9, "time": null}, {"value": "31", "confidence": 1.0, "rangeStart": 10, "rangeEnd": 12, "time": null}]], "asrConfidence": 0.21532300000000004, "rawInput": "stehlampe einunddreißig", "wakewordId": "alexa", "lang": null}
2021.06.15 20:41:19 5: Parsed value: SetNumeric for key: intent
2021.06.15 20:41:19 5: Parsed value: stehlampe for key: Device
2021.06.15 20:41:19 5: Parsed value: alexa for key: customData
2021.06.15 20:41:19 5: Parsed value: stehlampe einunddreißig for key: rawInput
2021.06.15 20:41:19 5: Parsed value: 1 for key: probability
2021.06.15 20:41:19 5: Parsed value: wohnzimmer-alexa-91813434-a7cf-464e-b272-e3d9cd6ef03a for key: sessionId
2021.06.15 20:41:19 5: Parsed value: 31 for key: Value
2021.06.15 20:41:19 5: Parsed value: stehlampe 31 for key: input
2021.06.15 20:41:19 5: Parsed value: wohnzimmer for key: siteId
2021.06.15 20:41:19 5: handleIntentSetNumeric called
2021.06.15 20:41:19 5: room is identified using siteId as wohnzimmer
2021.06.15 20:41:19 5: Device selected (by hash, with room and name): Stehlampe
2021.06.15 20:41:19 5: Response is: Tut mir leid, ich konnte kein passendes Mäpping finden
2021.06.15 20:41:23 5: RHASSPY: [Rhasspy] Parse (IO: rhasspyMQTT2): Msg: hermes/dialogueManager/sessionEnded => {"termination": {"reason": "nominal"}, "sessionId": "wohnzimmer-alexa-91813434-a7cf-464e-b272-e3d9cd6ef03a", "siteId": "wohnzimmer", "customData": "alexa"}
2021.06.15 20:41:23 5: Parsed value: wohnzimmer-alexa-91813434-a7cf-464e-b272-e3d9cd6ef03a for key: sessionId
2021.06.15 20:41:23 5: Parsed value: alexa for key: customData
2021.06.15 20:41:23 5: Parsed value: wohnzimmer for key: siteId
2021.06.15 20:41:23 5: room is identified using siteId as wohnzimmer
2021.06.15 20:41:25 5: RHASSPY: [Rhasspy] Parse (IO: rhasspyMQTT2): Msg: hermes/dialogueManager/sessionStarted => {"sessionId": "wohnzimmer-alexa-93d9ac40-b52a-40dd-bc75-ca446b9bfb22", "siteId": "wohnzimmer", "customData": "alexa", "lang": null}
2021.06.15 20:41:25 5: Parsed value: wohnzimmer-alexa-93d9ac40-b52a-40dd-bc75-ca446b9bfb22 for key: sessionId
2021.06.15 20:41:25 5: Parsed value: wohnzimmer for key: siteId
2021.06.15 20:41:25 5: Parsed value: alexa for key: customData
2021.06.15 20:41:25 5: room is identified using siteId as wohnzimmer
2021.06.15 20:41:27 5: RHASSPY: [Rhasspy] Parse (IO: rhasspyMQTT2): Msg: hermes/intent/de.fhem_Shortcuts => {"input": "Beleuchtung einschalten", "intent": {"intentName": "de.fhem:Shortcuts", "confidenceScore": 1.0}, "siteId": "wohnzimmer", "id": null, "slots": [], "sessionId": "wohnzimmer-alexa-93d9ac40-b52a-40dd-bc75-ca446b9bfb22", "customData": "alexa", "asrTokens": [[{"value": "Beleuchtung", "confidence": 1.0, "rangeStart": 0, "rangeEnd": 11, "time": null}, {"value": "einschalten", "confidence": 1.0, "rangeStart": 12, "rangeEnd": 23, "time": null}]], "asrConfidence": 1.0, "rawInput": "beleuchtung einschalten", "wakewordId": "alexa", "lang": null}
2021.06.15 20:41:27 5: Parsed value: Beleuchtung einschalten for key: input
2021.06.15 20:41:27 5: Parsed value: wohnzimmer for key: siteId
2021.06.15 20:41:27 5: Parsed value: wohnzimmer-alexa-93d9ac40-b52a-40dd-bc75-ca446b9bfb22 for key: sessionId
2021.06.15 20:41:27 5: Parsed value: beleuchtung einschalten for key: rawInput
2021.06.15 20:41:27 5: Parsed value: 1 for key: probability
2021.06.15 20:41:27 5: Parsed value: alexa for key: customData
2021.06.15 20:41:27 5: Parsed value: Shortcuts for key: intent
2021.06.15 20:41:27 5: handleIntentShortcuts called with Beleuchtung einschalten key
2021.06.15 20:41:27 5: [Rhasspy] setting  Timer: Rhasspy_wohnzimmer-alexa-93d9ac40-b52a-40dd-bc75-ca446b9bfb22 2021-06-15 20:41:37
2021.06.15 20:41:27 3: R-DM for Rhasspy called
2021.06.15 20:41:27 5: Response is: HASH(0x55c4c786a520)
2021.06.15 20:41:34 5: RHASSPY: [Rhasspy] Parse (IO: rhasspyMQTT2): Msg: hermes/dialogueManager/sessionEnded => {"termination": {"reason": "intentNotRecognized"}, "sessionId": "wohnzimmer-alexa-93d9ac40-b52a-40dd-bc75-ca446b9bfb22", "siteId": "wohnzimmer", "customData": "alexa"}
2021.06.15 20:41:34 5: Parsed value: wohnzimmer-alexa-93d9ac40-b52a-40dd-bc75-ca446b9bfb22 for key: sessionId
2021.06.15 20:41:34 5: Parsed value: wohnzimmer for key: siteId
2021.06.15 20:41:34 5: Parsed value: alexa for key: customData
2021.06.15 20:41:34 5: room is identified using siteId as wohnzimmer
2021.06.15 20:41:34 5: [Rhasspy] removing Timer: Rhasspy_wohnzimmer-alexa-93d9ac40-b52a-40dd-bc75-ca446b9bfb22
2021.06.15 20:41:39 5: RHASSPY: [Rhasspy] Parse (IO: rhasspyMQTT2): Msg: hermes/dialogueManager/sessionStarted => {"sessionId": "wohnzimmer-alexa-3e2ff5cd-5cf6-4b5d-b503-6c059095c2db", "siteId": "wohnzimmer", "customData": "alexa", "lang": null}
2021.06.15 20:41:39 5: Parsed value: wohnzimmer-alexa-3e2ff5cd-5cf6-4b5d-b503-6c059095c2db for key: sessionId
2021.06.15 20:41:39 5: Parsed value: wohnzimmer for key: siteId
2021.06.15 20:41:39 5: Parsed value: alexa for key: customData
2021.06.15 20:41:39 5: room is identified using siteId as wohnzimmer
2021.06.15 20:41:43 5: RHASSPY: [Rhasspy] Parse (IO: rhasspyMQTT2): Msg: hermes/dialogueManager/sessionEnded => {"termination": {"reason": "intentNotRecognized"}, "sessionId": "wohnzimmer-alexa-3e2ff5cd-5cf6-4b5d-b503-6c059095c2db", "siteId": "wohnzimmer", "customData": "alexa"}
2021.06.15 20:41:43 5: Parsed value: wohnzimmer-alexa-3e2ff5cd-5cf6-4b5d-b503-6c059095c2db for key: sessionId
2021.06.15 20:41:43 5: Parsed value: wohnzimmer for key: siteId
2021.06.15 20:41:43 5: Parsed value: alexa for key: customData
2021.06.15 20:41:43 5: room is identified using siteId as wohnzimmer
2021.06.15 20:41:56 5: RHASSPY: [Rhasspy] Parse (IO: rhasspyMQTT2): Msg: hermes/dialogueManager/sessionStarted => {"sessionId": "wohnzimmer-alexa-227f37e4-8735-4027-9f9b-8d20548c6023", "siteId": "wohnzimmer", "customData": "alexa", "lang": null}
2021.06.15 20:41:56 5: Parsed value: wohnzimmer-alexa-227f37e4-8735-4027-9f9b-8d20548c6023 for key: sessionId
2021.06.15 20:41:56 5: Parsed value: wohnzimmer for key: siteId
2021.06.15 20:41:56 5: Parsed value: alexa for key: customData
2021.06.15 20:41:56 5: room is identified using siteId as wohnzimmer
2021.06.15 20:42:26 5: RHASSPY: [Rhasspy] Parse (IO: rhasspyMQTT2): Msg: hermes/dialogueManager/sessionEnded => {"termination": {"reason": "timeout"}, "sessionId": "wohnzimmer-alexa-227f37e4-8735-4027-9f9b-8d20548c6023", "siteId": "wohnzimmer", "customData": "alexa"}
2021.06.15 20:42:26 5: Parsed value: alexa for key: customData
2021.06.15 20:42:26 5: Parsed value: wohnzimmer for key: siteId
2021.06.15 20:42:26 5: Parsed value: wohnzimmer-alexa-227f37e4-8735-4027-9f9b-8d20548c6023 for key: sessionId
2021.06.15 20:42:26 5: room is identified using siteId as wohnzimmer

Abschließende Betrachtung zum Filter aus meiner Sicht:
Einen globalen Filter zu setzen, welcher alle Intents AUSSER ConfirmAction, etc. erlaubt, ist derzeit nicht in Sicht.
Intentfilterung via continueSession oder/und configure ist generell möglich.
Letztlich sollte nur eine Variante zum filtern genutzt werden.
Es sollten passende Antworten zu confirm, cancel, intentNotRecognized und silence ausgegeben sowie der/die Filter zurückgesetzt werden.
Wenn das alles passt, könnte die Dialogroutine abgehakt werden.

Gruß Jens
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 16 Juni 2021, 11:11:02
Zitat von: JensS am 15 Juni 2021, 20:47:35
switchDM=1 war/ist gesetzt
Ah, ok, sorry für die Rückfrage, das war mir nicht klar.

Was du schreibst, klingt danach, als hätten die Filter irgendwelche Auswirkungen, was sich leider nicht mit meinen eigenen Beobachtungen deckt. Zum Teil könnte das daran liegen, dass ich bisher die App ohne Hotword zum Testen verwendet hatte, also die Sitzungsverwaltung nicht von der Base her initiiert wurde. Muss da noch weiter testen, aber das wäre eine Erklärung.

Falls die Filter bei dir/euch wirken:
Es würde mich interessieren, ob das immer gilt, nur dann, wenn die Sitzung über die Hotword-Erkennung der base lief, oder auch, wenn die Hotword-Erkennung auf dem Satelliten ablief.

Zitat
Abschließende Betrachtung zum Filter aus meiner Sicht:
Einen globalen Filter zu setzen, welcher alle Intents AUSSER ConfirmAction, etc. erlaubt, ist derzeit nicht in Sicht.
Oder bedeutet das, dass das "DialogueConfigureIntent" (Ausgabe an der Linux-Konsole) doch keine Auswirkungen hat?

Zitat
Intentfilterung via continueSession oder/und configure ist generell möglich.
Letztlich sollte nur eine Variante zum filtern genutzt werden.
Klar scheint mir, dass derzeit "zu viel" gefiltert wird (bzw. versucht wird zu filtern). Ziel sollte daher mAn. sein, jeweils nur "das Erforderliche" auf der richtigen Ebene zu filtern.

ZitatEs sollten passende Antworten zu confirm, cancel, intentNotRecognized und silence ausgegeben sowie der/die Filter zurückgesetzt werden.
Mir ist noch unklar, was mit "intentNotRecognized und silence" gemeint ist. Da bräuchte ich ggf. Material, um das nachzuvollziehen.
Unter "silence" würde ich grade verstehen, dass "nichts sagen" grade als "nein" erkannt und via ConfirmAction-intent weiterverarbeitet wird (weil das globale Filtern nicht funktioniert).

Ansonsten habe ich neben confirm und cancel noch die beiden "choice"-Intents, die auch (standardmäßig) deaktiviert werden sollten (aber eine "passende" Antwort liefern, wenn sie verfrüht angesprochen werden).
ZitatWenn das alles passt, könnte die Dialogroutine abgehakt werden.
Irgendwie sind m.E. dazu aber im Moment noch zu viele Fragezeichen offen....
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 16 Juni 2021, 20:17:40
Zitat von: Beta-User am 16 Juni 2021, 11:11:02
Zum Teil könnte das daran liegen, dass ich bisher die App ohne Hotword zum Testen verwendet hatte, also die Sitzungsverwaltung nicht von der Base her initiiert wurde. Muss da noch weiter testen, aber das wäre eine Erklärung.
Wie schräg ist das denn...?!? Es macht einen Riesen-Unterschied, ob eine Sitzung mit oder ohne Hotword (=per app-shortcut) gestartet wird.
Per Hotword sind die intentFilter auch nach Ende der session weiter aktiv!?! Ergo müßte man den nach Ende der Auswahl auch wieder zurücksetzen.
Auf den app-button hat das keinen Einfluss, startet man eine Session darüber, kann man unabhängig von den gesetzten intentFiltern und configures alle intents ansprechen...
Nicht lustig, im Moment habe ich k.A., wie man das in den Griff bekommen sollte. Die intentFilter wieder zurückzusetzen, sollte ja gehen, aber was bringt das, wenn "configure" als Oberfilter nicht durchschlägt?
Mal sehen, ob jemand von den Rhasspy-Leuten eine Idee hat.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 16 Juni 2021, 20:28:49
Zitat von: Beta-User am 16 Juni 2021, 11:11:02
Irgendwie sind m.E. dazu aber im Moment noch zu viele Fragezeichen offen....
Einige Fragen lassen sich eventuell mit verbose 5 am rhasspyMQTT2 klären. Das ist fast so gut, wie ein mosquitto_sub.
Bei (ja bitte|nein danke) funktioniert alles wie gewünscht - inkl. passenderAntwort.
Wenn man gar nichts sagt, läuft die Session durch und wird ordentlich beendet . Auch dann erhält man eine Antwort.
Der configure-Filter bleibt dauerhaft aktiviert, wenn nicht mit (ja bitte|nein danke) geantworten wird, sonder bspw. mit "wie spät ist es". Dort gibt es wohl noch ein "altes" Sprungziel.
In dem Fall muss man Rhasspy neu starten, um das configure zurückzusetzen.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 16 Juni 2021, 20:33:11
Zitat von: Beta-User am 16 Juni 2021, 20:17:40
Die intentFilter wieder zurückzusetzen, sollte ja gehen, aber was bringt das, wenn "configure" als Oberfilter nicht durchschlägt?
Der intentFilter sollte nicht das Problem sein. Der wird nach der Session von der Base zurückgesetzt. Wenn configure mit "default intent filter" nicht von fhem zurückgesetzt wird, klemmt's halt.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 16 Juni 2021, 21:06:58
Zitat von: JensS am 16 Juni 2021, 20:33:11
Der intentFilter sollte nicht das Problem sein. Der wird nach der Session von der Base zurückgesetzt. Wenn configure mit "default intent filter" nicht von fhem zurückgesetzt wird, klemmt's halt.
Sorry, verstehe ich nicht bzw. anders, oder das Verhalten ist auf einer Debian-Installation anders als auf docker:

Im Moment teste ich vorrangig ohne die zusätzlichen "configure"-Anweisungen, die globalen Deaktivierungs-Versuche gehen daher nur bei FHEM-Restart (oder Änderung der DEF) raus, das Verhalten war aber auch mit switchDM=1 schon "komisch" gewesen - daher der (mglicherweise falsche) Schluss, dass das "configure" im Endeffekt schlicht und ergreifend gar keine Auswirkungen zu haben scheint.
intentFilter ist auch bei ordnungsgemäßer Beendigung weiter aktiv, das habe ich grade mit und ohne switchDM nochmal durchgespielt.
Es scheint zwar partiell zu helfen, wenn man das configure "feuert", aber eine richtige Struktur kann ich im Moment nicht erkennen; das scheint bestenfalls eine Art globaler reset zu sein, was ja auch eine Option wäre, würde es immer funktionieren. Das tut es aber scheinbar auch nicht...
Und Rhasspy immer wieder neu zu starten ist ja auch keine Lösung, zumal dann ja auch die beabsichtigten partiellen Deaktivierungen (derzeit: via configure) wieder nicht Bestand hätten...

Bin irgendwie noch nicht auf den Trichter gekommen, wie das ganze gedacht ist, irgendwas übersehe ich bestimmt...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 16 Juni 2021, 21:15:01
https://forum.fhem.de/index.php/topic,119447.msg1161151.html#msg1161151 (https://forum.fhem.de/index.php/topic,119447.msg1161151.html#msg1161151) hilft. Dann ist nur noch der intentFilter in Benutzung und (fast) alles ist gut.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 17 Juni 2021, 07:46:26
Zitat von: JensS am 16 Juni 2021, 21:15:01
https://forum.fhem.de/index.php/topic,119447.msg1161151.html#msg1161151 (https://forum.fhem.de/index.php/topic,119447.msg1161151.html#msg1161151) hilft. Dann ist nur noch der intentFilter in Benutzung und (fast) alles ist gut.
Das Weglassen von switchDM in der DEF und ein einmaliger Neustart von Rhasspy haben mAn. genau dieselben Effekte: Es gehen keine Messages mehr an "configure". Soweit ich das bisher getestet habe, ist dann aber leider nichts wirklich besser.
intentFilter ist jedenfalls nicht auf die aktuelle Sitzung beschränkt und damit in der jetzigen Form unkalkulierbar. Ich bin auch unschlüssig, ob bzw. wie es sinnvoll ist, da noch weitere Anpassungen vorzunehmen, insbesondere, um auch den intentFilter wieder zurückzusetzen. Es wäre zwar möglich, das (De-) Aktivieren von intents in intentFilter "umzuziehen", aber nach meinem Eindruck ist  da eigentlich vorrangig zuerst auf der Rhasspy-Seite Nacharbeit erforderlich; das ganze wirkt auch mich schlicht unausgegoren oder einfach buggy. (Übergangsweise mag es aber sinnvoll sein, einen workaround zu bauen oder auch intentFilter komplett zu deaktivieren).

Mal sehen, vielleicht meldet sich ja jemand in der Rhasspy-community, der erklären kann, wie es "richtig" geht...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 18 Juni 2021, 11:29:52
Zu unserem "Lieblingsthema"
Zitat von: JensS am 16 Juni 2021, 21:15:01
https://forum.fhem.de/index.php/topic,119447.msg1161151.html#msg1161151 (https://forum.fhem.de/index.php/topic,119447.msg1161151.html#msg1161151) hilft. Dann ist nur noch der intentFilter in Benutzung und (fast) alles ist gut.
habe ich noch was von synesthesiam gefunden:
https://community.rhasspy.org/t/only-allow-some-intents-to-start-a-dialogue/973/5 (https://community.rhasspy.org/t/only-allow-some-intents-to-start-a-dialogue/973/5), zu intentFilter dann das hier: https://community.rhasspy.org/t/how-to-enable-continuous-mode/2277/4 (https://community.rhasspy.org/t/how-to-enable-continuous-mode/2277/4)

Nach meinem Verständnis sollte es daher jedenfalls nicht falsch sein, hin und wieder "configure" aufzurufen, und das Beibehalten von intentFilter nach Session-Ende halte ich für einen Bug.

Habe gestern noch ein paar Tests gemacht. Nach denen scheint jedenfalls der Filter auch wieder zurückgesetzt zu werden, wenn "configure" (mit den für den Dauerbetrieb richtigen Werten) aufgerufen wird. Daraus habe ich den Schluss gezogen, dass es zum einen sinnvoll ist, "configure" relativ (mAn. eigentlich: zu) häufig aufzurufen, und zum anderen vermutlich kein Fehler, _vorher_ intentFilter wieder auf "null" (ohne Quotes) zu stellen.

Anbei eine (gg. dem gestrigen noch unvollständigen Stand ergänzte) Fassung, die jetzt immer bei _jedem_ Dialogende (ausgenommen also nur Rückmeldungen bei continueSession) beides machen sollte (vorläufig noch nur, wenn switchDM=1 gesetzt ist, das sollte dann aber wieder nicht mehr konfigurierbar sein).

Tests wären willkommen, da da ein (zusätzlicher) InternalTimer-Mechanismus zur Anwendung kommt, um das "configure" erst nach Dialogbeendigung anzuschubsen, ist es allerdings "leicht gefahrgeneigt".



Zur Abwechslung dann aber auch noch was ganz anderes: Gibt es eigentlich einen Grund, warum es a) zwei "TTS-Optionen" im Code gibt (EDIT: da hatte ich wohl was missverstanden) und b) (EDIT: für den einen TTS-Fall) nicht "einfach" der (mAn) default-Weg verwendet wird, den Sitzungsmanager anzuweisen, eine neue "notification"-Sitzung zu starten?
(Details siehe pod ab Zeile 2300).
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 19 Juni 2021, 12:10:41
@Beta-User
Soeben habe ich eine Idee erfolgreich testen können. Es ist zwar keine elegante Lösung aber machbar.
Intent-Namen einsammeln und extrahieren:
http://rhasspy:12101/api/intents
Für alle sideId's (null) den "default intent filter" global setzen:
mosquitto_pub -t hermes/dialogueManager/configure -m '{"intents": [{"intentId": "alle Intents AUSSER de.fhem.ConfirmAction", "enable": true}], "siteId": null}'
In der Session den intentFilter setzen:
mosquitto_pub -t hermes/dialogueManager/continueSession-m '{"intentFilter":["de.fhem:ConfirmAction"],"sendIntentNotRecognized":true,"sessionId":"wohnzimmer-alexa-a32c083b-4d02-4f6e-87f2-fb8d4d2dc652","siteId":"wohnzimmer","text":"Soll ich die Stehlampe wirklich einschalten?"}'

Hintergrund:
Der "default intent filter" von configure wirkt global für alle siteId's und erlaubt alle Intents außer de.fhem.ConfirmAction. Ein "ja bitte" wird im laufenden Betrieb nicht erkannt.
Der intentFilter von continueSession wirkt lediglich in der gestarteten Session und wird abschließend gelöscht.
Der intentFilter hat eine höhere Prio als der "default intent filter" und überlagert diesen, allerdings nur in der Session. Anschließend gilt wieder der "default intent filter".

Wenn man also den "default intent filter" nach dem (re)start von Rhasspy aktiviert, ist alles wie gewollt. Nun fehlt nur noch ein Trigger dazu.

Gruß Jens

p.s. Bei der Überarbeitung meines Beitrags ist mir aufgefallen, dass "sendIntentNotRecognized":"false" den gewünschten boolschen Wert true ergibt und true statt "false" eingetragen.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 20 Juni 2021, 10:20:02
Anbei eine aktualisierte und bisher als ungefährlich eingestufte Aktualisierung.

Die bringt zum einen eine umgebaute speak-Routine, die den mAn. "korrekten" generischen Weg über den (Rhasspy-) Dialog-Manager geht.

Zum anderen konsolidiert das jedenfalls mal meine bisherigen Erkenntnisse, und v.a. auch ein paar der findings von @JensS:

Diese Tests und Feststellungen sind interessant, und das deckt sich eigentlich auch weitgehend mit meinen Erwartungen und dem Versuch, den Code dazu passend zu machen.
Für die RHASSPY-Entwicklung finde ich zwar das "alles aktivieren und dann ausgewählte deaktivieren" nicht "schick", weil das sehr "RHASSPY-zentriert" ist, aber nach meinen bisherigen früheren Tests müßte es eigentlich reichen, einfach (via configure) das zu deaktivieren, was man nicht braucht.

Besonders interessant fand ich, dass man mit "null" alle siteId's ansprechen kann, von daher geht jetzt an diese "Id" nur noch eine MQTT-Message raus, um (vermeintlich) alle unnötigen Intents zu "deaktivieren".

Leider funktioniert das dann grade in der Praxis alles  grade nicht, obwohl das "false" mAn. jeweils "korrekt" (ohne Quotes) übertragen werden sollte (in allen payloads/Fällen).
sentIntentNotRecognized verhält sich auch "komisch" bzw. anders als bisher?!?
Die "configure"-Messages gehen jetzt jedenfalls  (mit switchDM=1) zum "richtigen Zeitpunkt raus, also eigentlich müßte alles "fein" sein?
Leider bekomme ich meinen Rhasspy grade nicht motiviert, vernünftige Debug-Ausgaben zu machen, damit ich selber sehen kann, wann "false" als "true" interpretiert wird. Müsste erst mal Doku lesen, habe dazu jetzt aber grade keine Lust mehr; ein andermal...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 20 Juni 2021, 10:46:54
Zitat von: Beta-User am 20 Juni 2021, 10:20:02
nach meinen bisherigen früheren Tests müßte es eigentlich reichen, einfach (via configure) das zu deaktivieren, was man nicht braucht.

Die Negation eines Filters nach der Art !de.fhem.ConfirmAction ist in Rhasspy nicht vorgesehen. Zur Sicherheit habe ich mir die Quelltexte zu Dialogue und NLU angesehen und dort nur die einfachen intent_filter und intentFilter gefunden. Das deckt sich mit meinem Test vom 11.06.21 https://forum.fhem.de/index.php/topic,119447.msg1162076.html#msg1162076 (https://forum.fhem.de/index.php/topic,119447.msg1162076.html#msg1162076) .
Du wirst dich wohl oder übel vom Gedanken verabschieden müssen, dass es einen negierten globalen Filter "erlaube alles außer ..." gibt bzw. geben wird.

p.s. In den letzten Test-Versionen von 10_Rhasspy.pm scheint es eine Loop zu geben, so dass FHEM mit sich beschäftigt ist und keine Interaktion mehr möglich ist.
Der Prozess muss dann gekillt und neu gestartet werden. Bitte schau dir die letzten Änderungen einmal im Detail an. Eventuell ist es die Behandlung von sendIntentNotRecognized. Mir ist es zu aufwändig, die vielen Sprungziele zu prüfen und vom Debug halte ich wenig...

Richtig sollte es heißen: "sendIntentNotRecognized":true
https://rhasspy-hermes.readthedocs.io/en/latest/api.html#rhasspyhermes.dialogue.DialogueContinueSession (https://rhasspy-hermes.readthedocs.io/en/latest/api.html#rhasspyhermes.dialogue.DialogueContinueSession)
Wenn Quotes verwendet werden, wird "false" als String erkannt und ist somit größer als NULL. Die Base erkennt in den Fall ein boolsches true - was auch richtig wäre.
Wenn man die korrekte Syntax ohne Quotes verwendet, wird false als bool übertragen und die Base erkennt false (Defaultwert). Korrekt ist in dem Fall aber true.
https://rhasspy.readthedocs.io/en/latest/reference/#dialoguemanager_intentnotrecognized (https://rhasspy.readthedocs.io/en/latest/reference/#dialoguemanager_intentnotrecognized)
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 20 Juni 2021, 13:03:45
Hmmm, doof, das...

Es ist mAn. dann nicht gut auf der Rhasspy-Seite gelöst, wenn man z.B. von FHEM aus dann eine Positivliste senden müßte, was man alles haben will. Das bringt die Gefahr mit sich, dass man unbeabsichtigt andere "Clients" beeinflusst, und sei es nur, weil man deren deaktivierte Intents auf diesem Weg anschaltet.

Da das ganze aber sowieso nur die Filterei zu beeinflussen scheint, aber nicht Intents komplett deaktiviert, ist das eh' nur bedingt tauglich.
Muss wohl nochmal das ganze durchdenken und ggf. dann auch nochmal auf der Rhasspy-Seite Rückmeldung geben.


Mit der Fassung von heute morgen und auch mit der Testversion habe ich keine wirklichen Probleme, FHEM läuft ohne Probleme. Allerdings hatte ich manchmal (mit picoTTS?) das Problem, dass sich Rhasspy beim sprechen selbst ausgewertet hat, und dann irgendwas im Kreis ging...
Hast du ggf. etwas MQTT-Verkehr dazu?

intentNotRecognized auf "false" zu setzen, ist eigentlich beabsichtigt, damit die session offen bleibt, wenn was anderes erkannt wird. Aber das muss man dann eh' überdenken, wenn es "nur" als Filter wirkt...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 20 Juni 2021, 13:35:42
Danke für die schnelle Antwort.
Bei "sendIntentNotRecognized":false (default) übernimmt die Base die Verarbeitung und schließt die Session.
Bei "sendIntentNotRecognized":true wird die Verarbeitung an FHEM übergeben und die Session bleibt offen.
Das hattest du damals mit "sendIntentNotRecognized":"false" gelöst.
Nachdem das JSON neuerdings bereinigt wird, passiert genau das Gegenteil von dem, was anfangs geplant war.

Die Positivliste muss nur einmal global mit configure aktiviert werden. Die dabei deaktivierten Intents können ja temporär in der Session aktiviert werden. Da nur eine Session pro siteId möglich ist, und die Positivliste weiterhin für alle siteId's gültig ist, sollte das Ganze funktionieren.

Leider gehen die Quellen zu Rhasspy nicht ins Detail und so muss man sich mühevoll die Infos u.a. durch Analyse vieler Tests erarbeiten.
Vielen Dank, dass du dir die Arbeit machst, konsequent das Modul nach vorn zu bringen und zu optimieren.
Ich verstehe meinen Beitrag dabei als Unterstützung - keinesfalls als Kritik.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 21 Juni 2021, 17:29:22
Zitat von: JensS am 20 Juni 2021, 13:35:42
Nachdem das JSON neuerdings bereinigt wird, passiert genau das Gegenteil von dem, was anfangs geplant war.
Na supi, eigentlich einleuchtend (allerdings mAn. nicht das wording durch Rhasspy), aber diese ganze "um's-Eck-Denkerei" (in Verbindung mit der etwas dünnen Doku) macht mich fix und alle...

Wie dem auch sei:
http://rhasspy:12101/api/intentsist zwar "nett", aber auch nicht aufschlussreich, was die Frage von evtl. von anderer Seite (de-)aktivierten Intents angeht, jedenfalls, wenn ich beim Testen nicht wieder was grob falsch gemacht habe ::) .
Wenn ich das richtig verstanden hatte, kann man auch mit einem leeren Array alle Intents in die Positiv-Liste aufnehmen? Dann scheint mir das die einfachere Variante zu sein (iVm. mit nachgelagertem Ausschalten von allem, was wir per default nicht haben wollen). Ist zwar weiter mAn. "nicht gut", aber eben dann wohl die beste der heute möglichen Lösungen.

Zitat
Leider gehen die Quellen zu Rhasspy nicht ins Detail und so muss man sich mühevoll die Infos u.a. durch Analyse vieler Tests erarbeiten.
Na ja, und dann sind die Sourcen auch noch in python - und da habe ich "gewisse Orientierungsschwierigkeiten", und die Tests sind immer auch eher eine Momentaufnahme von dem, was grade auf FHEM-Seite raus- und reingeht, weniger, was auch in Rhasspy verstanden wird. "Blöd" ist insbesondere, dass die Reihenfolge passen (und evtl. die Sitzung auch noch offen sein) muss, sonst scheint es Probleme oder unbeabsichtigte Seiteneffekte zu geben.

ZitatVielen Dank, dass du dir die Arbeit machst, konsequent das Modul nach vorn zu bringen und zu optimieren.
Ich verstehe meinen Beitrag dabei als Unterstützung - keinesfalls als Kritik.
Paßt schon! Ich brauche halt manchmal etwas länger, um die Rückmeldungen einzuordnen und in den Code passend einzuarbeiten  ::) ...
Von daher geht der Dank auch zurück, denn diese Tests sind ja auch nicht eben unaufwendig, und da immer wieder (zum richtigen Zeitpunkt wieder) Rückverweise reinzubauen, wenn ich mal wieder länger auf dem Holzweg war, fällt ja auch nicht vom Himmel ::) .

Muss dann erst mal wieder testen, glaube aber, mit folgenden Zwischenschritten dann wieder weitergekommen zu sein (falls das alles auch klappt...):
-  "sendIntentNotRecognized" künftig auf (bereinigtes) "true"
- "configure" künftig dann zweistufig: Erst Array für "alles" aktivieren, dann ausgewählte deaktivieren; (wäre klasse, wenn man das in eine Message packen könnte, aber das ist mir im Moment "too much", ggf. sollte da auch auf Rhasspy-Seite noch was nachgearbeitet werden);
(Ergänzend, aber schon in der Vorversion eingebaut:)
- "intentFilter" wird bei allen abschließenden Meldungen wieder auf "null" gestellt.

Wenn das soweit klappt, wird sich die Frage stellen, ob wir "configure" dann sicherheitshalber häufiger aufrufen sollten oder eher nicht.


Damit's auch mal wieder um was anderes geht:

An "confirm" habe ich auch schon etwas rumgehirnt, ggf. kommt dann als nächstes, dass man für Gruppen-OnOff (optional) Bestätigungen einbauen kann (über "tweaks"). Von der Syntax her wäre es dann so, dass man Intent-"Kürzel" und Gruppenname(n) (künftig dann ggf. noch: FHEM-Device-Name) angeben könnte, und das dann via regex gecheckt wird.
Für Devices dann in "specials" ähnlich, aber da dann nur als Regex für die Intent-Kürzel?

Das dann noch weiter zu verfeinern (z.B. nur "on", aber nicht "off"), ist evtl. etwas schwieriger, aber bis auf den geschliderten Level runter sollte es "eigentlich" mit vertretbarem Aufwand machbar sein (wenn das mit den Filtern mal endlich soweit passt)...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 21 Juni 2021, 18:29:09
Zitat von: Beta-User am 21 Juni 2021, 17:29:22
kann man auch mit einem leeren Array alle Intents in die Positiv-Liste aufnehmen?
Ein leeres Array löscht den Filter. Das sieht genau so aus, als wären alle Intents in einer Positivliste. Aber man kann nichts, in einer nicht existierenden Liste durch false ausschließen. Klingt komisch  - is aber so.
Hier mal ein Programmbeispiel zur Abfrage der vorhandenen Intents:sub intentList(){
my $intentString;
my $ua = LWP::UserAgent->new();
my $response = $ua->get("http://192.168.x.x:12101/api/intents");
my $content = $response->content;
my $ref = JSON->new->decode($content);
my @intents = keys %$ref;
while (@intents) {
    $intentString = $intentString."\"".pop(@intents)."\"\n";
};
$ref = encode('utf-8',$intentString);
return $ref;
}

Dort die nicht allzeit gewünschten Intents rauswerfen und den configure-Filter dauerhaft setzen.
Den intentFilter würde ich jeweils nur einmal bei continueSession definieren und dann durchlaufen lassen.

Gruß Jens

p.s. Ich hatte das mit einer händisch erstellten Positivliste gestestet und es hat alles zuverlässig funktioniert, wie gewollt.
Die Handy-App scheint (unabhängig von der Filterei) etwas sensibel auf nicht rechtzeitige Antworten im Netzwerk zu sein und hat auch schon mal einen Fehler ausgeworfen.
Ich habe zur Sicherheit bei allen Geräten/Servern IPv6 rausgenommen.
Zum testen empfehle ich einen Raspi oder die Base.

ZitatWenn das soweit klappt, wird sich die Frage stellen, ob wir "configure" dann sicherheitshalber häufiger aufrufen sollten oder eher nicht.
hermes/nlu/query gibt den aktiven Filter aus. Allerdings nur im laufenden Dialog. Der configure-Filter könnte neu gesetzt werden, wenn ein Diff zum api/intents-Ergebnis minus ConfirmAction etc. existiert.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 21 Juni 2021, 19:25:49
Zitat von: Beta-User am 21 Juni 2021, 17:29:22
Damit's auch mal wieder um was anderes geht:

An "confirm" habe ich auch schon etwas rumgehirnt, ggf. kommt dann als nächstes, dass man für Gruppen-OnOff (optional) Bestätigungen einbauen kann (über "tweaks"). Von der Syntax her wäre es dann so, dass man Intent-"Kürzel" und Gruppenname(n) (künftig dann ggf. noch: FHEM-Device-Name) angeben könnte, und das dann via regex gecheckt wird.
Für Devices dann in "specials" ähnlich, aber da dann nur als Regex für die Intent-Kürzel?

Das dann noch weiter zu verfeinern (z.B. nur "on", aber nicht "off"), ist evtl. etwas schwieriger, aber bis auf den geschliderten Level runter sollte es "eigentlich" mit vertretbarem Aufwand machbar sein (wenn das mit den Filtern mal endlich soweit passt)...
Sieht interessant aus - bin schon auf die Ref gespannt!
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 22 Juni 2021, 11:10:44
Zitat von: JensS am 21 Juni 2021, 18:29:09
Ein leeres Array löscht den Filter. Das sieht genau so aus, als wären alle Intents in einer Positivliste. Aber man kann nichts, in einer nicht existierenden Liste durch false ausschließen. Klingt komisch  - is aber so.
...da war doch was ::) ...
Das scheint in der Tat so gelöst zu sein, dass beide Filter eigentlich (immer) als Positivliste zu verstehen sind, und mit dem letzten Element dann die ganze Liste gelöscht wird. Was den "configure"-Filter angeht, gefällt mir das nicht wirklich, aber zumindest im Moment müssen wir wohl damit leben.

ZitatHier mal ein Programmbeispiel zur Abfrage der vorhandenen Intents:
[...]
Danke für den Schnipsel, ich habe das jetzt erst mal in der Form umgesetzt, dass
- beim FHEM-Start bzw. nach Änderung der DEF ein API-Request abgesetzt wird, der dann asynchron abgearbeitet wird;
- die intents in einem Reading landen (Komma-separiert (?));
- der callback dann auch ein "configure" initiiert, durch das alle Intents (bis auf unsere Standard-Negativliste) aktiviert bleiben sollten (das ganze geht auf einmal raus).

Zumindest auf den ersten Blick sieht das auf der MQTT-Seite ok aus, und "nein" wurde mit "intent not recognized" bzw. "nichts" quittiert, viel mehr habe ich bisher nicht getestet.
Das ist jetzt irgendwie "gefühlt unfertig". Meine "Bauchschmerzen":
- Zunächst müssten wir checken, dass der globale Filter auf diese Weise korrekt gesetzt wird und aktiv ist (s.u.).
- Dann muss geklärt werden,
-- wann jeweils das "globale configure" aufgerufen werden sollte (ich vermute: das muss nicht ständig sein, aber eben nach jedem Rhasspy-Restart, von dem wir aber nichts mitbekommen (? - evtl. gibt's die Möglichkeit, irgendwie an die uptime von Rhasspy (-hermes) zu kommen?), und
-- wie das Verhältnis von intentFilter und globalem Filter wirklich ist, wenn die Sitzung "zu" ist (und ob ggf. ein "nachgeschobenes" "null" für intentFilter@siteId ausreicht, um den globalen Filter wieder aktiv zu bekommen).

Zitat
hermes/nlu/query gibt den aktiven Filter aus. Allerdings nur im laufenden Dialog. Der configure-Filter könnte neu gesetzt werden, wenn ein Diff zum api/intents-Ergebnis minus ConfirmAction etc. existiert.
Danke für den Hinweis, muss ich mir dann mal im laufenden Betrieb ansehen, was darüber dann kommt - und wie man das ggf. verwerten kann. Meine Befürchtung wäre, dass man dann relativ viel Daten intern vorhalten muss und bedingte (asynchrone) Auswertungen vornehmen - puh...

Zitat
Zum testen empfehle ich einen Raspi oder die Base.
Mein eigentliches Zielgerät ist und bleibt halt der Android, und auch zum Testen ist der schneller bei der Hand ::) ...

Zitat von: JensS am 21 Juni 2021, 19:25:49
Sieht interessant aus - bin schon auf die Ref gespannt!
...erst mal ohne cref und ungetestet, aber für SetOnOffGroup eventuell schon funktional...
Das ganze ist relativ generisch angelegt und sollte daher auch relativ einfach auf andere Gruppen- und auch Einzelintents erweitert werden können. (Falls das mit den Dialogen dann mal voll funktioniert...)
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 22 Juni 2021, 16:16:44
Zeile 771 musste noch ein ; ran.
Ich teste gleich mal...

Prima, sieht gut aus! Alle Möglichkeiten werden richtig abgefangen und zu Ende gebracht.
Machst du das configure nach endSession oder kommt das von der Base? Hab mich gerade im Code verirrt.  ???
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 22 Juni 2021, 16:53:27
Zitat von: JensS am 22 Juni 2021, 16:16:44
Zeile 771 musste noch ein ; ran.
Ups, sorry, hatte ich nur auf dem Hauptsystem ergänzt...

Zitat
Ich teste gleich mal...

Prima, sieht gut aus! Alle Möglichkeiten werden richtig abgefangen und zu Ende gebracht.
Machst du das configure nach endSession oder kommt das von der Base? Hab mich gerade im Code verirrt.  ???
Wann das "configure" aufgerufen wird, hängt von der DEF ab. Mit "switchDM=1" wird das bei jedem von FHEM aus initiierten Dialogende rausgepustet, ohne nur zum Start...

Klingt danach, als wäre
Zitat von: Beta-User am 22 Juni 2021, 11:10:44
- Zunächst müssten wir checken, dass der globale Filter auf diese Weise korrekt gesetzt wird und aktiv ist (s.u.).
soweit geklärt; der "zusammengefasste Filter auf siteId=>null" scheint ok zu sein 8) .

Damit wären wir bei
Zitat
- Dann muss geklärt werden,
-- wann jeweils das "globale configure" aufgerufen werden sollte (ich vermute: das muss nicht ständig sein, aber eben nach jedem Rhasspy-Restart, von dem wir aber nichts mitbekommen (? - evtl. gibt's die Möglichkeit, irgendwie an die uptime von Rhasspy (-hermes) zu kommen?), und
-- wie das Verhältnis von intentFilter und globalem Filter wirklich ist, wenn die Sitzung "zu" ist (und ob ggf. ein "nachgeschobenes" "null" für intentFilter@siteId ausreicht, um den globalen Filter wieder aktiv zu bekommen).
Mehr Infos zu letzterem Punkt sollte man dadurch bekommen können, dass man den Schalter in der DEF rausnimmt (und Rhasspy während des Tests nicht neu startet!). Passen dann die Filter (bzw. werden dann nur die jeweils gerade relevanten Intents erkannt), funktioniert auch das "Überlagern" des globalen Filters durch den "continue"-Mechanismus und das Zurücksetzen nach Dialogende (mit "null").
(Falls Rhasspy zwischendurch doch neu gestartet werden muss: danach die DEF anfassen, z.B. ein Leerzeichen reinmachen oder so, dann geht der request auch raus).

(Erst) dann können wir überlegen, wann es Sinn macht, das globale "configure" aufzurufen - bzw. vermutlich besser: den api-Request abzusetzen? Dessen Antwort triggert dann das configure zum richtigen Zeitpunkt, nämlich nach Erhalt der ggf. aktualisierten Intent-Liste.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 22 Juni 2021, 17:08:33
Ich hab mal die Zeilen 2285 und 2286 auskommentiert. Läuft weiterhin 1a!
So kann ConfirmAction etc. in den produktiven Betrieb gehen.
Wie und wann die Positivliste gesetzt werden muss, ist schwer ermittelbar. Die Routine bei der Definition ist jedefalls schnell und zuverlässig durchgelaufen.
Schau die mal die hermes/nlu/#-Messages an, ob das mit einem Filtervergleich praktikabel wäre.
Was besseres fällt mir (noch) nicht ein. Notfalls erst mal ein set...

Gruß Jens
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 22 Juni 2021, 17:23:32
Hmm, #2286 leuchtet mir ein, das läuft auf dasselbe raus, wie den Wert aus der DEF zu nehmen (was mittelfristig das Ziel sein sollte; das ist ja nur zum Testen und einfachen Umschalten drin).

#2285 ist ein "Hosenträger". Wenn es ohne geht, auch gut, aber als Merkposten sollte die Zeile erst mal drin bleiben, falls es doch komische Effekte gibt (kann aber auch sein, dass ich wegen der "false=>true-Geschichte jetzt in dem Punkt übervorsichtig bin...).

Den Verkehr aaO schaue ich mir bei Gelegenheit dann mal in Ruhe an, eventuell können wir auch in der Rhasspy-Communitiy mal nachhaken, ob es möglich ist, irgendwie eine Signalisierung von einem Rhasspy-Start zu bekommen. Oder wir feuern halt von Zeit zu Zeit während eines laufenden Dialogs eine Abfrage raus, ob noch ein Filter gesetzt ist und reagieren dann, wenn da nicht rechtzeitig eine (aus FHEM-sicht korrekte) Antwort kommt?
Insgesamt gefällt es mir aber nicht, dass der globale Filter nicht per default aktiv (und persistent) ist. Das würde ich eigentlich vorrangig zu allem anderen in die Rhasspy-Community als Änderungswunsch rückmelden (wenn der Rest soweit läuft)...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 22 Juni 2021, 17:33:57
Zitat von: Beta-User am 22 Juni 2021, 17:23:32
#2285 ist ein "Hosenträger". Wenn es ohne geht, auch gut, aber als Merkposten sollte die Zeile erst mal drin bleiben, falls es doch komische Effekte gibt (kann aber auch sein, dass ich wegen der "false=>true-Geschichte jetzt in dem Punkt übervorsichtig bin...).
Sicher ist sicher - Gürtel und Hosenträger.  ;D
Finde ich auch gut so, lasse es aber trotzdem (bei mir) auskommentiert und stelle es auf Wiedervorlage.
Zitat
Den Verkehr aaO schaue ich mir bei Gelegenheit dann mal in Ruhe an, eventuell können wir auch in der Rhasspy-Communitiy mal nachhaken, ob es möglich ist, irgendwie eine Signalisierung von einem Rhasspy-Start zu bekommen. Oder wir feuern halt von Zeit zu Zeit während eines laufenden Dialogs eine Abfrage raus, ob noch ein Filter gesetzt ist und reagieren dann, wenn da nicht rechtzeitig eine (aus FHEM-sicht korrekte) Antwort kommt?
Insgesamt gefällt es mir aber nicht, dass der globale Filter nicht per default aktiv (und persistent) ist. Das würde ich eigentlich vorrangig zu allem anderen in die Rhasspy-Community als Änderungswunsch rückmelden (wenn der Rest soweit läuft)...
Das wäre gut, genau wie die Möglichkeit einer Negativliste. Die Jungs sind leider nicht so gesprächig...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 23 Juni 2021, 18:13:02
@Beta-User
Könntest/würdest du ein Mäpping für die Bestätigungsanfrage bei SetOnOff schreiben?

Gruß Jens

p.s.
Hab mal eben die Rhasspy-Quellen nach einer gangbaren Lösung für eine Startmessage durchsucht und eine Zeile in /var/lib/rhasspy/rhasspy-server-hermes/rhasspyserver_hermes/_init_.py zugefügt:    # -------------------------------------------------------------------------
    # MQTT Event Handlers
    # -------------------------------------------------------------------------

    def on_connect(self, client, userdata, flags, rc):
        """Connected to MQTT broker."""
        try:
            self.is_connected = True
            _LOGGER.debug("Connected to MQTT broker")

            # Default subscriptions
            self.subscribe(
                HotwordDetected,
                AsrTextCaptured,
                NluIntent,
                NluIntentNotRecognized,
                AsrAudioCaptured,
                AudioSummary,
            )
            self.client.publish("hermes/start", '{"event":"start"}')
            # Re-subscribe to everything
            for topic in self.all_mqtt_topics:
                self.client.subscribe(topic)
                _LOGGER.debug("Subscribed to %s", topic)

            self.connected_event.set()
        except Exception:
            _LOGGER.exception("on_connect")

Beim (re)start wird dann eine Message hermes/start {"event":"start"} ausgegeben. Vielleicht implementieren die Rhasspy-Leute das, wenn du das dort postest. Mein Englisch ist super schlecht...

p.p.s. Hab die Nachricht auf ein JSON geändert. Auswerten kann man das, wenn die subscriptions der rhasspy-MQTT-Bridge um hermes/start erweitert wird.
Dann ein MQTT2_DEVICE anlegen:
defmod MQTT2_rhasspyMQTT2 MQTT2_DEVICE rhasspyMQTT2
attr MQTT2_rhasspyMQTT2 event-on-update-reading event
attr MQTT2_rhasspyMQTT2 readingList rhasspyMQTT2:hermes/start:.* { json2nameValue($EVENT) }

und ein Notify drauf ansetzen: defmod updateIntentFilter notify MQTT2_rhasspyMQTT2 set  Rhasspy update intent_filter
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 23 Juni 2021, 20:27:14
...da waren noch ein paar Wackler in der vorigen Version drin, das mit dem SetOnOffGroup klappt (erst) mit der beigefügten Version. Die braucht einen restart, damit der neue language-key eingefügt wird.

attr rhasspy rhasspyTweaks confirmIntents=SetOnOffGroup=rollläden,deckenlichter

Zum Rest ein ander Mal.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 24 Juni 2021, 12:00:12
Erst mal ein paar ergänzende Infos, was die letzte Version eigentlich so alles mitbringt.... Hier erst mal eine shortlist:

1.
- der "lang"-key wird mit durchgeschleust;
- sendSpeakCommand() adressiert jetzt "startSession" statt direkt die "tts/say"

2.
- fetchIntents() als neue interne Funktion eingefügt, die setzt dann in der Folge auch den globalen Filter zurück;
- es gibt einen setter dafür (unterhalb update), das ganze wird derzeit ansonsten nur beim FHEM-Start bzw. bei Änderung der DEF ausgeführt;
- switchDM gibt's nicht mehr (war nur ein Hilfsmittel zum testen)

3.
- es gibt den neuen Tweak "confirmIntents" (mehr dazu unten);
- und das "Special" "confirm" (s.u.)
- getNeedsConfirmation() als neue zentrale Funktion eingefügt.

4.
- sendIntentNotRecognized ist "repariert" und steht im Moment auf "true". Das scheint (vorläufig gesprochen) die "richtige" Einstellung zu sein, wenn man einen Dialog mit dem App-shortcut startet, für per hotword eröffnete sessions scheint es egal zu sein, ob man das überhaupt mitsendet;

5.
- die respond()-Funktion ist umgebaut und extrahiert jetzt die relevanten Daten direkt aus $data (ist eher intern und aus User-Sicht uninteressant)
- Ausgabemöglichkeit für "speakerless"-Satelliten (Reading-Auswertung "siteId2doubleSpeak_<siteId>")

Etwas mehr Details zu einigen der Stichworte:
1. "lang"-key durchschleusen
Aus https://community.rhasspy.org/t/passing-language-setting-to-intent/2903/2 (https://community.rhasspy.org/t/passing-language-setting-to-intent/2903/2) (und dem dort weiter verlinkten Material) habe ich den Schluss gezogen, dass es sinnvoll ist, diesen Key weiterzugeben, wenn er vorhanden ist. Inwieweit das ggf. dann dazu genutzt werden _könnte_, auch eine automatische Übersetzung unserer "englischen" default-Antworten in die gewünschte Zielsprache zu ermöglichen, weiß ich im Moment auch nicht, ebensowenig wie geklärt ist, ob es ggf. sinnvoll wäre, den "notification"-Messages (aus speakCommand) gleich die lang-Info (aus dem Internal LANGUAGE) mitzugeben...
Also falls da einer unserer Mehrsprachler tiefer einsteigen will...

2. (und evtl. 4.)
In dem Filter-Thema ist jedenfalls jetzt Bewegung drin :) .
Zitat von: JensS am 23 Juni 2021, 18:13:02
Beim (re)start wird dann eine Message "hermes/start on" ausgegeben. Vielleicht implementieren die Rhasspy-Leute das, wenn du das dort postest.
Hab's mal da eingekippt :) , in diese Richtung ging auch die Überlegung von @synesthesiam.
Mal sehen, was wir in dem Zusammenhang wann wie umbauen können/müssen.

3.
Das mit der Bestätigungsanforderung ist jetzt im eigentlichen Intent-spezifischen Code relativ unaufwändig gelöst. Im aktuellen Beispiel "handleIntentSetOnOffGroup" ist es nur die eine Zeile:
return $hash->{NAME} if !$data->{Confirmation} && getNeedsConfirmation( $hash, $data, 'SetOnOffGroup' );Bevor wir das aber auf diese Art weiter ausrollen, noch ein paar Gedanken dazu:
- Zum Aktivieren (für Gruppen) kann man den beschriebenen Tweak setzen, Syntax ist "intent=<Gruppennamen>". Für diesen Fall halte ich auch die Syntax für ok und verständlich, Gruppen mit Leerzeichen kann man (wie parseParams-üblich) mit dem Setzen passender Quotes ebenfalls verwenden.
Unsicher bin ich allerdings, ob das Komma als Trennzeichen glücklich gewählt ist, denn das Ganze könnte man auch als Regex formulieren und umdrehen, was ggf. die flexiblere Variante wäre. => Meinungen dazu?!? (Meine eigene Tendenz wäre, das in diese Richtung umzubauen)
- Theoretisch geht das genauso (per Tweak) mit den FHEM-Device-Namen und Einzelintents (man muss die Zeile dann nur mit "nicht im Bulk-Modus" ergänzen), ABER:
- Eigentlich finde ich die Logik eingängiger, alles, was mit einzelnen Devices zu tun hat, auch (nur) über "Specials" zu regeln und würde das tendenziell daher als Tweak deaktivieren. Andererseits: eine Regex-Lösung funktioniert mAn. nur zentral, von daher ist meine aktuelle Tendenz, das an der Stelle beizubehalten (eigentlich nur wegen der regex-Option);
- Was "Specials" angeht, ist das derzeit (ungetestet) eine einfache "per-intent"-Lösung. Vermutlich ließe sich das auch noch filigraner lösen (also nur z.B. für das "off"), aber das würde "gefühlt" wieder deutlich mehr Coding erfordern. Insgesamt bin ich gedanklich noch nicht so richtig bei Einzelgeräten angekommen gewesen, und im Moment habe ich erst mal nur die richtige Stelle für die Abfrage bei dem (relativ einfachen (!)) SetOnOff-Intent lokalisiert: Es muss der FHEM-Device-Name bekannt sein, also kurz vor analyzeAndRunCmd() (#2869). Dachte erst, bei anderen Intents gäbe es deutlich mehr Stellen, aber die Zahl der Aufrufe ist zum Glück relativ begrenzt... (Erfahrungsgemäß steckt der Teufel dann aber im Detail, sobald man was umsetzen will ;) ).

Wie ist denn die allgemeine Temperatur dazu? Braucht es filigranere Unterscheidungen (bzw. würde es ggf. reichen, on und off gesondert zu betrachten)?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 25 Juni 2021, 18:31:07
https://community.rhasspy.org/t/lost-in-dialogues-customdata-intentfilter-and-dialoguemanager-configure/2890/9?u=jens-schiffke (https://community.rhasspy.org/t/lost-in-dialogues-customdata-intentfilter-and-dialoguemanager-configure/2890/9?u=jens-schiffke)
Aus meiner Sicht wäre es besser, wenn @synesthesiam continueSession um die Option "slot" erweitern würde.
Die configure-Lösung springt quasi in die Bresche, um bestimmte Worte, wie "ja" per Filter im laufenden Betrieb auszuklammern.
Wenn "ja" erst gar nicht erkannt würde, weil der entsprechende Slot keinem Intent zugeordnet ist, würde der intentFilter genügen.
Das macht Dialoge einfacher, sicherer und flexibler.
Natürlich kann ich mit meiner Auslegung der Hermes-Referenz daneben liegen...
Wie du schon bemerkt hast, sollte es nicht um Reiseziele, sondern um Devices gehen. Ich fand die Reise anschaulicher.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 26 Juni 2021, 15:53:45
Zitat von: JensS am 25 Juni 2021, 18:31:07
Die configure-Lösung springt quasi in die Bresche, um bestimmte Worte, wie "ja" per Filter im laufenden Betrieb auszuklammern.
So ist das derzeit gelöst, und wenn dann ein Filter angewendet wird, geht's nach "intentNotRecognized", was - je nach Anweisung an den DialogueManager - eben dann Ende des Dialogs (false) bzw. "lass das externe Programm entscheiden" bedeutet (s.u.).

Das "Grundproblem" scheint zu sein: Rhasspy muss vorher wissen, welche "Datenmodelle" es auswerten darf. Die werden beim "training" erstellt - auf Basis der zu diesem Zeitpunkt vorhandenen "Effektivsätze", die daraus gebildet werden, dass alle Varianten der "sentences.ini" (bzw. alle relevanten "Rohsätze") aus den vorhandenen Bausteinen (feste und optionale Elemente aus den Sätzen unter Berücksichtigung aller Varianten, die sich durch die Auflösung der Variablen (also auch: slots)) ergeben.

Ändert man nachträglich was (aktiviert slots?), muss man neu trainieren, was (derzeit) aus Zeitgründen effektiv nicht geht.

Ein "slot" entsprechend deinem Vorschlag könnte daher (diesem Verständnis folgend) allenfalls ein kompletter "Satz" sein, der eben (nach dem Training) entweder aktiviert wird oder nicht, aber mAn. ist es etwas anderes wie andere "slots", die im Prinzip als variable _Bestandteile_ von Sätzen fungieren und daher vor dem Training "eingeordnet" (oder vielleicht ist "ausgepackt" plakativer?) werden müssen.

Vielleicht wäre es besser, von einem "optionalSentence" zu sprechen, der dann flexibel beliebigen Intents zugeordnet werden kann?

Das könnte in der Tat eine gewisse weitere Flexibilität ermöglichen, interne Basis wäre aber weiter die Option, einzelne Sätze (egal ob per (globalem) Filter oder per "optionalSentence") für die Erkennung komplett ein- und auszuschalten (ohne Training).

Zitat
Ich fand die Reise anschaulicher.
Das mit der Reise ist anschaulicher. Um im Bild zu bleiben: Wenn man in Rom startet, braucht man in der zweiten Anfrage "Rom" nicht mehr verstehen; dieses Schlüsselwort sollte also aus dem slot raus bzw. die damit gebildeten Sätze sollten dann auch nicht mehr erkannt werden...
Alles nicht so einfach.

Zitat
Wenn "ja" erst gar nicht erkannt würde, weil der entsprechende Slot keinem Intent zugeordnet ist, würde der intentFilter genügen.
Das macht Dialoge einfacher, sicherer und flexibler.
Zwischenzeitlich bin ich nicht mehr unbedingt sicher, ob diese These zutrifft.
Unsere Ausgangsmotivation ist doch in etwa so (oder ?): Es ist keine gute User-Erfahrung, wenn Rhasspy in einem Dialog zwischendurch plötzlich "irgendwas" erkennt und von sich aus scheinbar das Thema wechselt. Das kann man mit den heutigen (Filter-) Mechanismen (teilweise) abfangen (vorausgesetzt, das Dialogue-Management wird durch Rhasspy-hermes gesteuert), oder auch nicht, was dann eben das vorzeitige Dialog-Ende bedeutet (was derzeit fast noch die "beste" Lösung erscheint).
Das Thema zu wechseln kann aber auch gewollt sein, und dann ist es (auch für die User-Experience) kontraproduktiv, wenn man nicht flexibel reagiert...

Letzteres würde bedeuten, den intentNotRecognized-Topic auszuwerten, und dann Daten zu konsolidieren, die History berücksichtigen, entweder einfach erst mal still sein (wie mit "true" heute) oder nochmal nachhaken, ...
Muss mal sehen, ob sich da was machen läßt, aber das sieht mir tricky aus.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 26 Juni 2021, 17:33:13
Ok, dann wollen wir mal sehen, was die Rhasspy-Leute daraus machen.
Wenn "slot" nach dem Ansatz umgesetzt wird, wie ich ihn verstanden habe, wäre es ein weiterer Schritt nach vorn.
Man könnte dynamisch Rückfragen erstellen und sich dabei aller denkbaren Slots (Device, Room, Zahl, Uhrzeit, Dauer, etc...) bedienen.
Dazu genügt ein Intent "Dialogue" eine sub "rhasspyDialogue" als Dialog-Bridge. Man bräuchte nicht für jede Situation einen extra Intent.

p.s.
ZitatDas Thema zu wechseln kann aber auch gewollt sein, und dann ist es (auch für die User-Experience) kontraproduktiv, wenn man nicht flexibel reagiert...
Letzteres würde bedeuten, den intentNotRecognized-Topic auszuwerten, und dann Daten zu konsolidieren
Das sollte unbedingt mit rein. Das hat Potenzial. Beim intentFilter werden alle gelernten Worte zur STT mit einbezogen aber nur die gefilterten Worte als Treffer ausgegeben. Die verworfenen Worte werden trotzdem über MQTT ausgegeben. Das hat schon was...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 28 Juni 2021, 10:22:09
Zitat von: JensS am 26 Juni 2021, 17:33:13
Man könnte dynamisch Rückfragen erstellen und sich dabei aller denkbaren Slots (Device, Room, Zahl, Uhrzeit, Dauer, etc...) bedienen.
Dazu genügt ein Intent "Dialogue" eine sub "rhasspyDialogue" als Dialog-Bridge. Man bräuchte nicht für jede Situation einen extra Intent.
Na ja, weiß nicht recht...

Das Problem ist mAn. weniger, dass man ggf. viele Intents braucht, sondern eher, dass man zu jedem Zeitpunkt weiß, was (mit der notwendigen Sicherheit) jeweils gewollt ist. Es kann daher zwar hilfreich sein, wenn man z.B. einen (sehr kurzen) Bestätigungs-Satz (bzw. Abbruch/zurück,...) "überall" einbauen kann, aber ansonsten fand ich die "Vorstrukturierung" über die Erkennung der diversen Intent-Sektionen in der sentences.ini eigentlich ganz ok.

Zitat
p.s.Das sollte unbedingt mit rein. Das hat Potenzial. Beim intentFilter werden alle gelernten Worte zur STT mit einbezogen aber nur die gefilterten Worte als Treffer ausgegeben. Die verworfenen Worte werden trotzdem über MQTT ausgegeben. Das hat schon was...
Auch da: schon, aber soweit meine Tests bisher reichen, bekommt man eben dann nur den "raw"-Text ohne die erkannten Bestandteile. Im Ergebnis wird man dann vermutlich nochmal eine Schleife brauchen, in der dann entweder der User nochmal "seinen" (bereits erkannten) Satz sagt, oder wir müssen den rawInput dann wieder über die Intent-Erkennung laufen lassen, nachdem der Filter geändert/den neuen Gegebenheiten angepaßt wurde => gefühlt müssen sehr viele Dialogstufen zwischengespeichert werden und zu jedem Zeitpunkt dann wieder der passende Aspekt hervorgeholt werden (und passend beantwortet!).
Bin ehrlich gesagt grade nicht sicher, ob
a) sich das lohnt und
b) ich überhaupt in der Lage wäre, sowas als programmtechnischen Ablauf sauber zu designen :( .

Werde mal versuchen, zumindest die erste Stufe, also Erkennen und Auswerten von intentNotRecognized, mal abzubilden. Erst danach läßt sich vermutlich erkennen, wie es dann weitergehen kann...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 28 Juni 2021, 10:33:34
Es geht ja nur um die Rückfrage-Dialoge.
Die normale sentences.ini und der bisherige Programmcode bliebe unangetastet und würde wie gewohnt abgearbeitet.

Wenn der intentFilter gesetzt ist und keine Antwort, wie "ja bitte" sondern "wie spät ist es" gegeben wurde, erhält man vor der intentNotRecognized-Nachricht eine NLU-Message (sofern aboniert).
hermes/nlu/query {"input": "wie spät ist es"
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 28 Juni 2021, 11:47:59
Zitat von: JensS am 28 Juni 2021, 10:33:34
Es geht ja nur um die Rückfrage-Dialoge.
Die normale sentences.ini und der bisherige Programmcode bliebe unangetastet und würde wie gewohnt abgearbeitet.
Das Problem ist aber, dass man dann eben aus der Rückfrage wieder in den "normalen" Modus wechselt (s.u.), aber - dem Gefühl nach - irgendwie festhalten muss, wo man herkommt...

Zitat
Wenn der intentFilter gesetzt ist und keine Antwort, wie "ja bitte" sondern "wie spät ist es" gegeben wurde, erhält man vor der intentNotRecognized-Nachricht eine NLU-Message (sofern aboniert).
hermes/nlu/query {"input": "wie spät ist es"
Das "wie spät ist es" ist dann auch in der intentNotRegognized-Message drin. Es ist dort (wie auch bei "query") aber überhaupt nicht klar, "wo" das hingehört (also z.B. zu welchem (deaktivierten) Intent). Das bedeutet, man muss diesen Input wieder an Rhasspy zurückgeben (noch zu klären: wo und wie?), aber eben erst, nachdem man (welchen?) Filter wieder umgestellt hat, damit die Analyse auf den Intent (und ggf. enthaltene keywords) stattfindet. Vorab noch eine Rückfrage an den User, ob das Thema gewechselt werden soll...?
Da das dann aber innerhalb eines Dialoges stattfindet, stellt sich die Frage, welche "alten" Daten eigentlich gelöscht werden sollten, damit man nicht versehentlich in der falschen Schublade landet (z.B.: bleibt man im selben Raum wie dem, der ggf. bei der ersten Ansage genannt wurde oder nimmt man den aus der siteId abgeleiteten?!?).

Vielleicht denke ich grade auch zu sehr um's Eck, aber es kommt mir alles andere als trivial vor, von dem zentralen "intentNotRecognized" wieder zielführend wegzukommen...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 28 Juni 2021, 12:20:10
Zitat von: Beta-User am 28 Juni 2021, 11:47:59
Vielleicht denke ich grade auch zu sehr um's Eck, aber es kommt mir alles andere als trivial vor, von dem zentralen "intentNotRecognized" wieder zielführend wegzukommen...
Ich denke, dass das zentrale intentNotRecognized die Pflicht ist und die NLU als Kür vielleicht irgenwann mit reinkommen könnte. Vieles ist sowieso hypothetisch, solange wir keine Info/Erweiterung von Rhasspy haben.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 28 Juni 2021, 14:02:43
@drhirn
Da Rhasspy in einem recht gutem Zustand ist und prinzipiell die Anforderungen einer Sprachsteuerung erfüllt, wären die Voraussetzungen zu einem WIKI-Artikel in der Kategoie Sprachsteuerung gegeben.
Zumal das Modul bereits in contrib ist.
Man könnte ja https://github.com/fhem/fhem-rhasspy/blob/main/README.md (https://github.com/fhem/fhem-rhasspy/blob/main/README.md) dazu nehmen.

Gruß Jens
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 28 Juni 2021, 14:24:36
Ich habe meine Überlegungen dazu hier schon kund getan: https://forum.fhem.de/index.php/topic,119447.msg1157988.html#msg1157988

Kurz gesagt: Kann jeder jederzeit machen, ich unterstütze gerne. Kümmern möchte ich mich aber nicht darum.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 29 Juni 2021, 12:41:11
@Beta-User
Als Zwischenlösung habe ich meinen Beitrag https://forum.fhem.de/index.php/topic,119447.msg1163740.html#msg1163740 (https://forum.fhem.de/index.php/topic,119447.msg1163740.html#msg1163740) nochmals editiert.
Hast du ein Attribut, in dem ich meine per default zu deaktivierenden Intents reinpacken kann?

Gruß Jens

Edit: Funktioniert nicht, da Dialogue nach dem allg. Rhasspy-Server gestartet wird. Entweder setzt man ein qos, dass Dialogue die Nachricht erhält, wenn er sich beim MQTT anmeldet oder das notify bekommt ein at mit rein.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 29 Juni 2021, 13:02:25
Ein Attribut gibt es bisher nicht, muss mal überlegen, ob das Sinn macht (aber vermutlich erst, wenn wir mit dem ganzen gedanklich "fertig" sind). Dann wäre noch zu klären, wie das wirken soll und in welcher Form die Intents dann präsentiert werden müßten (Komma-separiert?)

An sich ist der Code aber generisch angelegt. Es sollte daher möglich sein, das über "normales Perl" im notify zu machen. Ausgangspunkt:
configure_DialogManager {
    my $hash      = shift // return;
    my $siteId    = shift // 'null'; #ReadingsVal( $hash->{NAME}, 'siteIds', 'default' ) // return;
    my $toDisable = shift // [qw(ConfirmAction CancelAction ChoiceRoom ChoiceDevice)];
    my $enable    = shift // q{false};

Das ergäbe dann ungefär sowas:
defmod updateIntentFilter notify MQTT2_rhasspyMQTT2 { my $toDisable = [qw(MeinIntent)];; RHASSPY::configure_DialogManager( $defs{Rhasspy}, undef, $toDisable ) }

Das ganze wird aber bei einer "SilentCancellation" derzeit wieder auf die defaults gesetzt!
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 29 Juni 2021, 13:30:35
Danke, das übernehme gern. Gibt es eine Möglichkeit, nur diese Nachricht mit qos=1 o.ä. anzusetzen?
Zitat von: Beta-User am 29 Juni 2021, 13:02:25
Das ganze wird aber bei einer "SilentCancellation" derzeit wieder auf die defaults gesetzt!
Der "default intent filter" kann doch immer so bleiben.? Nach der Dialog-Session mit intentFilter gilt er doch sowieso wieder, egal ob ordentlich beendet wurde oder mit einem Timeout.

p.s. So geht's:defmod updateIntentFilter notify MQTT2_rhasspyMQTT2 {fhem('define 5_s at +00:00:05 { my $toDisable = [qw(ConfirmAction)];;;; RHASSPY::configure_DialogManager( $defs{Rhasspy}, undef, $toDisable ) }')}
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 29 Juni 2021, 13:40:53
Zitat von: JensS am 29 Juni 2021, 13:30:35
Danke, das übernehme gern. Gibt es eine Möglichkeit, nur diese Nachricht mit qos=1 o.ä. anzusetzen?
Mit QoS habe ich mich bisher nicht beschäftigt, und ich bin auch nicht sicher, ob das von MQTT2_CLIENT unterstützt wird bzw. dann auch wirklich die Auswirkung hätte, die du dir wünschen würde - das ganze setzt nämlich afaik voraus, dass das eigentliche Zielgerät sich ordentlich subscribed hatte, und das scheint beim Start ja grade nicht der Fall zu sein, wenn ich den Nachtrag von vorhin richtig interpretiere?

Zitat
Der "default intent filter" kann doch immer so bleiben.? Nach der Dialog-Session mit intentFilter gilt er doch sowieso wieder, egal ob ordentlich beendet wurde oder mit einem Timeout.
Na ja, wenn ein (bestimmter) "unzulässiger" Intent kommt, unterstelle RHASSPY derzeit, dass Rhasspy neu gestartet wurde und stellt dann die default-Filter wieder her. Wenn (künftig) per Attribut gelöst, würde man wohl die default-Liste entsprechend erweitern...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 29 Juni 2021, 13:50:20
Zitat von: Beta-User am 29 Juni 2021, 13:40:53
setzt nämlich afaik voraus, dass das eigentliche Zielgerät sich ordentlich subscribed hatte, und das scheint beim Start ja grade nicht der Fall zu sein
Rhasspy besteht, wie du weißt, aus veschiedenen Modulen. Das Hauptmodul (mit der Start-Message) subscribed kein configure. Das wird vom Dialog-Modul aboniert, welches später startet.
Beim Neustart ist die configure-Anweisung also längst durch, bevor das betreffende Modul gestartet wurde.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 29 Juni 2021, 14:01:21
Na ja, dem könnte man mit einer Timer-Lösung begegnen, also das configure verzögert rauszuschicken.
(Ich wollte nicht unterstellen, dass Rhasspy da was "falsch" macht, sondern nur klarstellen, dass es passieren kann, dass der MQTT-Server gar nicht weiß, dass "jemand" später einen bestimmten Topic subscriben will und daher ggf. das QoS ins Leere läuft.

Könnte man vielleicht mit einem retain-Flag lösen, aber da stellen sich dann wieder andere Probleme - kurz: Ich halte das mit dem "SilentCancellation"-reset für die noch am ehesten zielführende Lösung.

Es dämmert mir aber, dass es vermutlich hilfreich wäre, die Liste der default zu deaktivierenden Intents ggf. auf einfache Weise ergänzbar zu machen... Kein Hexenwerk, aber ein kleinerer Umbau...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 29 Juni 2021, 17:21:54
Wenn die Message mit QOS 1 gepublisht wurde, hält sie Mosquitto so lange vor, bis sie von einem Client subscribed/abgerufen wurde. Die Message ist so lange in der Mosquitto-Datenbank hinterlegt und überlebt sogar einen Mosquitto-Neustart.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 29 Juni 2021, 17:33:01
OK, dann habe ich das mit QoS jetzt auch verstanden... Nur: wie publisht man via M2C mit entsprechendem Flag? Doku ist an der Stelle etwas "dünn"...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 29 Juni 2021, 17:40:29
Ich hab's mal in MQTT angefragt. Rudi als Maintainer weiß das bestimmt.
Insgesamt wäre es sowieso besser, wenn das auf der Rhasspy-Seite gelöst werden würde. Eventuell mit einem flag in der Intentdefinition von sentences. Im Forum hatte ich ja gefragt, ob man die Intents per default (de)aktivieren kann. Das würde die ganze Nummer mit der Start-Message überflüssig machen. Irgendwie sind dort meine Vorschläge bislang auf kein großes Interesse gestoßen...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 29 Juni 2021, 17:46:56
Hab's dann auch gesehen...

Na ja, die Vorschläge laufen halt meinem Bauchgefühl nach auf ziemlich tiefe Eingriffe in die Gesamtfunktionalität ein und erfordern einiges an Coding. Da würde hier auch erst mal gefragt werden, wo denn die effektiven Restriktionen liegen, und ob man nicht erst mal versuchen kann, mit den vorhandenen Mitteln zurande zu kommen.
Genau an der Stelle sind jetzt mAn. erst mal wir in der Pflicht. Ich habe zwar das Gefühl, dass es noch andere "Apps" gibt, die an diesen Stellen straucheln, aber einen Bedarf zu erkennen heißt dann ja noch lange nicht, dass man eine gemeinsame Vision hat, wie sich die Probleme lösen lassen. Ergo: eines nach dem anderen...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 29 Juni 2021, 18:17:18
Ok, dann halte ich mal die Füße still.
Die Antwort von Rudi hast du bestimmt gelesen. Also könnte man von FHEM-Seite her (versuchen), ein extra MQTT2_CLIENT (zu) definieren, welcher die Start-Message abfängt und die Configure-Message mit QOS 1 absetzt. Ob's klappt, wird sich zeigen. Das hängt davon ab, ob das Dialogmodul nach dem subscribe einmal durchgelaufen und bereit für Messages ist.
Die Übertragung im Netzwerk dauert ja ein paar ms und das sollte eventuell als Verzögerung reichen.
Willst du dir das mal anschauen, ob man das in 10_RHASSPY reinnehmen könnte?

p.s. Andererseits ist es dem User nicht zuzumuten, den Rhasspy-Code zu editieren...  :-\
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 30 Juni 2021, 11:19:17
Zitat von: Beta-User am 29 Juni 2021, 14:01:21
Es dämmert mir aber, dass es vermutlich hilfreich wäre, die Liste der default zu deaktivierenden Intents ggf. auf einfache Weise ergänzbar zu machen... Kein Hexenwerk, aber ein kleinerer Umbau...
Anbei der (weitgehend ungetestete) Versuch, das einzubauen...

Es gibt dazu einen weiteren "Tweak" (intentFilter), mit dem man die Liste der "default" (de-) aktivierten Intents manipulieren können sollte; weiß noch nicht, wann ich dazu komme, das in Ruhe auch von der MQTT-Seite her zu begutachten. Bitte einfach etwas "spielen", das key/value-Ergebnis der Auswertung des Attributs ist im list unter "tweaks" zu finden, die intents müssen mit dem vollen Namen im key landen.

ZitatNa ja, dem könnte man mit einer Timer-Lösung begegnen, also das configure verzögert rauszuschicken.
Wie ich vorhin erst gesehen habe, klappt das grundsätzlich. Da es jetzt auch den "intent_filter" unter den "update"-settern gibt, sollte das auch als "einfaches FHEM-Kommando mit FHEM-sleep" umsetzbar sein, ohne dass der einzelne User besonders tief in's RHASSPY-coding einsteigen müßte.

Andere IO's finde ich eher schwierig, da (auch in der Gesamtkonfiguration incl. dem weiteren IO) unübersichtlich und ggf. bzgl. der Hintergründe unverstanden. MAn. sollte es reichen, wenn FHEM auf den "SilentCancelation"-Fall dadurch reagiert, dass der default-Filter wiederhergestellt wird und der User die Option hat, ggf. auf die dann auf Rhasspy-Seite eingebaute "bin wieder da"-Message angemessen (verzögert) zu reagieren (bzw. dann bauen wir das auch in RHASSPY direkt ein!).


Die Version anbei kann übrigens auch Messages auf intentNotRecognized "verarbeiten", wobei sich das im Moment mehr oder weniger darauf beschränkt, den zwischengespeicherten Kontent etwas anzureichern (so das überhaupt funktioniert); die Idee, wie es dann ggf. danach weitergehen soll fehlt mir im Moment noch...

Bitte mal schauen, ob ihr ggf. mit den cref-Hinweisen soweit erst mal hinkommt.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 30 Juni 2021, 18:34:51
Sorry, ich suche gerade einen Wald - hast du mal ein Syntax-Beispiel bitte?  :o

p.s. Jetzt hab ich es gefunden:intentFilter= de.fhem:SetOnOff='false'

Danke @Beta-User - funktioniert zuverlässig!

Nun kann ich ja mal versuchen, ein (für Rhasspy) unbekanntes Wort zu buchstabieren [de.fhem:ABC] und in der Wikipedia zu suchen.
Das gestaltet sich noch schwierig, da z.B. b und w (für Rhasspy) ziemlich ähnlich klingen.

p.p.s. Hab mich dazu entschlossen, das Buchstabieren nach DIN 5009 umzusetzen - also Öko = Ökonom, Kaufmann, Otto.
Wie gut, dass in Deutschland alles geregelt ist.  ;D
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 01 Juli 2021, 08:07:59
Ja, das Wegschalten von Intents klappt, aber leider nicht (bei allen) die Gegenrichtung...

Bin unschlüssig, was ich reparieren soll: Die cref oder den Code ::) .

Lt. cref sollte auch sowas funktionieren:
attr rhasspy rhasspyTweaks intentFilter=de.fhem:SetMute de.fhem:ConfirmAction=true
Und das klappt bzgl. ConfirmAction nicht. Hatte erst dazu tendiert, das im Code so anzupassen, dass auch das so geht wie in der cref beschrieben.
ABER: ist zwar nicht wirklich eine größere Aktion, aber zum einen ist unklar, ob sowas wirklich jemand braucht, und zum anderen (und das ist hier m.E. wichtiger): Das "leise" Wiederherstellen des vom Modul erwarteten Intent-Filter-Verhaltens setzt eben voraus, dass bestimmte Filter im normalen Betrieb wirklich gesetzt sind. Wenn jemand meint, die ausschalten zu müssen, wird der Filter nach jeder entsprechenden Aktion wieder aktiviert, ohne dass das positive Auswirkungen hätte - höchstens unbeabsichtigte Nebenwirkungen auf andere "Apps".
Es wird daher eine Klarstellung geben, dass das für "die 4" nicht geht...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 01 Juli 2021, 09:00:02
Zitat von: Beta-User am 01 Juli 2021, 08:07:59
Es wird daher eine Klarstellung geben, dass das für "die 4" nicht geht...
... sehe ich auch so. Die gehören ja auch zwingen zum Modul und sollten vom User im laufenden Betrieb nicht enabled werden.

Den Code schaue ich mir auch nochmal genau an aber vielleicht ist es #789, da configure_DialogManager bei "set Rhasspy update intent_filter" kein Shift bekommt.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 01 Juli 2021, 09:28:07
Zitat von: JensS am 01 Juli 2021, 09:00:02
... sehe ich auch so. Die gehören ja auch zwingen zum Modul und sollten vom User im laufenden Betrieb nicht enabled werden.
Thx für die Einschätzung. Zwischenzeitlich ist mir auch der Gedanke durch den Kopf gegangen, dass Experten, die es anders haben wollen, dann ja die Wahl haben, einen eigenen Intent dafür zu verwenden und dann eben das ganze Drumrum selbst zu organisieren.

Zitat
Den Code schaue ich mir auch nochmal genau an aber vielleicht ist es #789, da configure_DialogManager bei "set Rhasspy update intent_filter" kein Shift bekommt.
"set Rhasspy update intent_filter" schubst eigentlich nur das Abholen der (vollständigen und aktuellen) Intents von Rhasspy an. Das eigentliche Filter-Setzen ist dann asynchron organisiert, nämlich aus der Verarbeitung der Antwort darauf heraus.

#789 bewirkt, dass die "default"-Routine mehr oder weniger übersprungen wird, wenn jemand configure_DialogManager() aufruft, um aktiv nur bestimmte Intents zu aktivieren. Diese Funktionalität ist mAn. eigentlich an sich überholt, kurzfristige Änderungen sollte man mit continueSession-intentFilter verwirklichen; sie schadet aber auch nicht....

Für das "Überspringen" der "4 speziellen" Intents ist die Folgezeile ("next if $_ =~ m{$matches}ms;") zuständig.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 01 Juli 2021, 09:38:20
Zitat von: Beta-User am 01 Juli 2021, 09:28:07
"next if $_ =~ m{$matches}ms;"
Ja klar - dann ist doch alles gut.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 02 Juli 2021, 15:59:17
Da hast du ja ein ziemliches "Schmankerl" in einem sehr nachträglichen Edit versteckt ;) :
Zitat von: JensS am 30 Juni 2021, 18:34:51
p.p.s. Hab mich dazu entschlossen, das Buchstabieren nach DIN 5009 umzusetzen - also Öko = Ökonom, Kaufmann, Otto.
Klingt nach einem coolen Projekt, mit dem man die myUtils-Funktionalität iVm. "contunueSession" usw. ziemlich gut austesten können sollte :) .

Vielleicht in dem Zusammenhang noch ein Hinweis bzw. auch eine etwas abstrakte Überlegung: Vermutlich wird es aus "intentNotRecognized" heraus sinnvoll sein, "customData" mit einem "Merker" zu füllen, damit man z.B. relativ einfach (ohne erst den irgendwo zwischengespeicherten Intent zu suchen) in der Verarbeitung "normaler" Intents feststellen kann, _ob_ es eine "Vorgeschichte" gibt, die man sich ggf. näher ansehen muss.

Die angehängte Version unterscheidet sich in dem Punkt und einer weiteren Kleinigkeit von der Vorversion, sonst ist nur die cref angepaßt (und alles kaum getestet), aber evtl. hilft dir das schon etwas weiter....
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 02 Juli 2021, 16:55:43
 :) Ideen muss man haben - Hellwig.
customData dachte ich als Speicherort für die jeweilige Session zu nutzen, um den Einstiegsintent und die Dialog(zwischen)ergebnisse abzulegen.
Nun muss ich erst mal Urlaub machen. Ich schau zwischendurch mal rein, ob's was Neues gibt - auch im Rhasspy-Forum.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 02 Juli 2021, 17:03:04
Zitat von: JensS am 02 Juli 2021, 16:55:43
customData dachte ich als Speicherort für die jeweilige Session zu nutzen, um den Einstiegsintent und die Dialog(zwischen)ergebnisse abzulegen.
Nun muss ich erst mal Urlaub machen. Ich schau zwischendurch mak rein, ob's was Neues gibt - auch im Rhasspy-Forum.
Dann mal schönen Urlaub, erhol dich gut :) !

Was cutomData angeht, bin ich unschlüssig, wie man das sinnvoll verwenden kann. Das Problem ist halt, dass man da keine strukturierten Daten durchreichen kann (sonst zuerhaut's die Session), sondern nur "flachen Text". Daher neige ich eher dazu, alle Zwischeninfos im RHASSPY-Hash abzulegen und in customData nur irgendwelche (kurzen?) Statusinfos mitzugeben, damit man schnell(er) vorsortieren kann. Ist aber alles noch nicht komplett durchdacht, werd's vermutlich dann die Tage mal auch als Zwischenstand im Rhasspy-Forum posten und mir da nochmal Meinungen versuchen einzuholen...
Muß dazu aber auch nochmal (v.a.) den MQTT-Verkehr etwas "im laufenden Betrieb" beobachten, vielleicht kommt mir dann noch eine Eingebung?!?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 02 Juli 2021, 17:13:43
Danke.  8)
Wegen des Formats würde ich mir erst mal keine Sorgen machen. Selbst JSON ist letztlich nur Text. Wichtig ist die richtige Codierung. Ich hatte mir mal mit der Sprachausgabe das ganze FHEM abgeschossen, bevor ich dann auf utf-8 umgestellt hatte. Lehrgeld eben... Man kann ja auch einen Konverter zum Maskieren drüber laufen lassen.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 02 Juli 2021, 17:23:10
Zitat von: JensS am 02 Juli 2021, 17:13:43
Selbst JSON ist letztlich nur Text.
Jo. Dachte ich auch mal...
Kann schon sein, dass da was ginge, wenn man das mit dem "Säubern" intensiver ansehen würde, aber die Reaktion von den Rhasspy-Leuten auf komplexeren Content an der Stelle war eher: "Watndat...?!?!?"
Von daher _glaube_ ich, dass es einfacher ist, das Feld nur für "Schalterwörter" zu nutzen und den eigentlichen Content dann einfach im "Dialoghash" zwischenzuspeichern. Den brauchen wir nach meinen bisherigen Erfahrungen sowieso und sind dann völlig flexibel...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 02 Juli 2021, 17:49:27
Wenn die Grundlagen gelegt sind, gibt's der Wege viele. Klar, das alles in FHEM zwischenzuspeichern macht Sinn, wenn der Spieltrieb nicht wäre...  ;D
Kann sein, dass ich den intentFilter-Thread im Rhasspy-Forum getötet habe. Mir ging es doch nur um default-disabled-Intent und slot in intentFilter...
Wäre schön, wenn es in die nächste Rhasspy-Version mit einfließen würde.
Konntest du dich inzwischen mit einer optionalen Rückfrage in SetOnOff anfreunden?

Insgesamt finde ich das Modul 10_RHASSPY.pm mittlerweile echt sehenswert, nachdem ich dem Umbau skeptisch entgegensah. Auch von den anderen Nutzern gibt es derzeit keine Fehleranzeigen. :Daumenhoch
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 02 Juli 2021, 18:05:48
Zitat von: JensS am 02 Juli 2021, 17:49:27
Kann sein, dass ich den intentFilter-Thread im Rhasspy-Forum getötet habe. Mir ging es doch nur um default-disabled-Intent und slot in intentFilter...
Das glaube ich kaum, dass du den "abgeschossen" hast, die warten da eher auf (halbwegs) qualifizierten Input von meiner Seite ::) .

Die zugrundeliegenden Probleme sind nach meiner Wahrnehmung auch in der einen oder anderen Form auch schon von anderen aufgegriffen worden, aber bis zum Ende durchgespielt (nicht nur mit der Demo-App) scheint das bisher keiner zu haben. Von daher bin ich optimistisch, dass es da in der einen oder anderen Form Bewegung geben wird.

Zitat
Konntest du dich inzwischen mit einer optionalen Rückfrage in SetOnOff anfreunden?
Strukturell sollte das kein größerer Act sein, ich meine, da wären auch noch ein paar Fragen an die Nutzer offen, wie man es denn gerne hätte...?

Mein "Problem" ist derzeit eher, dass ich für den "Prototypen" (SetOnOffGroup) eigentlich lieber erst mal den Pfad durch den Gesamtcode gelegt haben wollte, bevor es weitergeht. Und das wird noch etwas dauern, ansonsten steht es auf dem Plan, klar...

Zitat
Insgesamt finde ich das Modul 10_RHASSPY.pm mittlerweile echt sehenswert, nachdem ich dem Umbau skeptisch entgegensah. Auch von den anderen Nutzern gibt es derzeit keine Fehleranzeigen. :Daumenhoch
Danke!
Wenn ich nicht "gewisse Erfahrungen" aus dem MQTT_GENERIC_BRIDGE-Umbau heraus gehabt hätte, wäre ich auch skeptischer gewesen bzw. hätte mir den Umbau auch nicht zugetraut ;D . So bin ich auch hocherfreut, dass keiner (berechtigten) Anlass hat, sich zu beklagen und das ganze doch sehr reibungslos zu laufen scheint... (?).

Aber bei so massiven Eingriffen darf man skeptisch sein! Und manches hat ja leider auch nicht auf Anhieb geklappt.
Jetzt finde ich das ganze - trotz der vielen Optionen auf vielen Ebenen - noch vergleichsweise easy in der Einrichtung (aus User-Sicht), das ist eigentlich das coolste daran 8) ...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 10 Juli 2021, 16:11:33
Hat schon jemand die Preview auf 2.5.11 (docker) am laufen? Ich nutze ausschließlich Debian-Pakete.
Mich interessiert, ob es was Neues im Dialogmodul gibt und z.B. eine Startmessage implementiert wurde.
Geschrieben wurde dazu leider nichts.

Gruß Jens
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 14 Juli 2021, 10:58:20
@Beta-User
Kannst du mir bitte auf die Sprünge helfen, wie ich die sessionId und die siteId von handleCustomIntent abgreifen kann?
Versuche mich gerade am Wikipedia-Dialog...

Gruß Jens
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 14 Juli 2021, 11:31:55
Zitat von: JensS am 14 Juli 2021, 10:58:20
@Beta-User
Kannst du mir bitte auf die Sprünge helfen, wie ich die sessionId und die siteId von handleCustomIntent abgreifen kann?
Versuche mich gerade am Wikipedia-Dialog...

Gruß Jens
Aus dem Kopf: DATA abfragen?
("Auspacken" müßte über die "Muster-myUtils" dargestellt sein).
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 14 Juli 2021, 12:23:20
Danke, da war doch noch was - hatte vergessen, DATA im Attribut rhasspyIntents zu abonnieren.  ???
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 14 Juli 2021, 18:12:05
@Beta-User
Hast du eine Idee, warum Rhasspy meine Session nach continueSession beendet?hermes/intent/de.fhem:WIKI {"input": "bitte schlage in der Wikipdia nach", "intent": {"intentName": "de.fhem:WIKI", "confidenceScore": 1.0}, "siteId": "wohnzimmer", "id": null, "slots": [], "sessionId": "wohnzimmer-alexa-3165aa4a-114b-4f6c-9628-e9ded3e34200", "customData": "alexa", "asrTokens": [[{"value": "bitte", "confidence": 1.0, "rangeStart": 0, "rangeEnd": 5, "time": null}, {"value": "schlage", "confidence": 1.0, "rangeStart": 6, "rangeEnd": 13, "time": null}, {"value": "in", "confidence": 1.0, "rangeStart": 14, "rangeEnd": 16, "time": null}, {"value": "der", "confidence": 1.0, "rangeStart": 17, "rangeEnd": 20, "time": null}, {"value": "Wikipdia", "confidence": 1.0, "rangeStart": 21, "rangeEnd": 29, "time": null}, {"value": "nach", "confidence": 1.0, "rangeStart": 30, "rangeEnd": 34, "time": null}]], "asrConfidence": 0.99609652, "rawInput": "bitte schlage in der wikipdia nach", "wakewordId": "alexa", "lang": null}
hermes/dialogueManager/continueSession {"intentFilter":["de.fhem:ABC"],"sendIntentNotRecognized":true,"sessionId":"wohnzimmer-alexa-3165aa4a-114b-4f6c-9628-e9ded3e34200","siteId":"wohnzimmer","text":"Bitte buchstabiere."}
hermes/dialogueManager/endSession {"customData": "alexa","intentFilter": null,"sessionId": "wohnzimmer-alexa-3165aa4a-114b-4f6c-9628-e9ded3e34200","siteId": "wohnzimmer","text":-1}
hermes/dialogueManager/sessionEnded {"termination": {"reason": "nominal"}, "sessionId": "wohnzimmer-alexa-3165aa4a-114b-4f6c-9628-e9ded3e34200", "siteId": "wohnzimmer", "customData": "alexa"}

Mit [WIKI] rufe ich [ABC] in continueSession auf und möchte den Rückgabewert (vorerst) als Reading ablegen.
Die Sprachausgabe "Bitte buchstabiere" wird ausgegeben, trotzdem wird die Session unmittelbar nach absetzen von continueSession geschlossen. Daher erhalte ich auch keine Rückgabe von [ABC].

sub ABC{
my $data = shift // return;
my $Buchstabe = shift // return;
fhem("setreading Rhasspy Buchstabe $Buchstabe");
my $SessionJSON = decode_json($data);
my $SessionID = $SessionJSON->{'sessionId'};
my $SiteID = $SessionJSON->{'siteId'};
my $CustomData = $SessionJSON->{'customData'}.$Buchstabe;
if ($Buchstabe ne "suche"){
my $Readingsstring = "\'\{\"customData\"\:\"$CustomData\"\,\"intentFilter\"\:\[\"de\.fhem\:ABC\"\]\,\"sendIntentNotRecognized\"\:false\,\"sessionId\"\:\"$SessionID\"\,\"siteId\"\:\"$SiteID\"\,\"text\"\:\"$Buchstabe\"\}\'";
system("/usr/bin/mosquitto_pub -h 192.168.x.x -p 1883 -t hermes/dialogueManager/continueSession -m $Readingsstring")}
else{
fhem("set Rhasspy speak siteId\=\"$SiteID\" text\=\"$CustomData\"")
}
}

sub WIKI{
my $data = shift // return;
my $SessionJSON = decode_json($data);
my $SessionID = $SessionJSON->{'sessionId'};
my $SiteID = $SessionJSON->{'siteId'};
#my $CustomData = $SessionJSON->{'customData'};
my $CustomData = "WIKI ";
my $Readingsstring = "\'\{\"customData\"\:\"$CustomData\"\,\"intentFilter\"\:\[\"de\.fhem\:ABC\"\]\,\"sendIntentNotRecognized\"\:true\,\"sessionId\"\:\"$SessionID\"\,\"siteId\"\:\"$SiteID\"\,\"text\"\:\"Bitte buchstabiere\.\"\}\'";
system("/usr/bin/mosquitto_pub -h 192.168.x.x -p 1883 -t hermes/dialogueManager/continueSession -m $Readingsstring");
}


rhasspyIntents:ABC=ABC(DATA,Ch)
WIKI=WIKI(DATA)


sentences:[de.fhem:ABC]
($de.fhem.ABC){Ch}
(suche){Ch}


$de.fhem.ABC:([zett wie] Zacharias):z
([fau wie] Viktor):v
(es zett):ß
([ce wie] Cesar):c
([ess wie] Siegfried):s
([kuh wie] Quelle):q
([u wie] Ulrich):u
([eff wie] Friedrich):f
([ell wie] Ludwig):l
([ka wie] Kaufmann):k
([ge wie] Gustav):g
([pee wie] Paula):p
([o wie] Otto):o
([de wie] Dora):d
([be wie] Berta):b
([ä wie] Ärger):ä
([sch wie] Schule):sch
([emm wie] Martha):m
([ce ha wie] Charlotte):ch
([e wie] Emil):e
([ü wie] Übermut):ü
([zett wie] Zeppelin):z
([tee wie] Theodor):t
([enn wie] Nordpol):n
([ess wie] Samuel):s
([ö wie] Ökonom):ö
([Üppsilonn wie] Üppsilonn):y
([ha wie] Heinrich):h
([i wie] Ida):i
([icks wie] ksantippe):x
([jott wie] Julius):j
([err wie] Richard):r
([a wie] Anton):a
([we wie] Wilhelm):w


EDIT: Der erste mehrstufige Dialog läuft...
In sub handleCustomIntent musste ich das finale "return respond" auskommentieren, da nach dem Respond die Session vom Modul geschlossen wird.

hermes/dialogueManager/continueSession {"customData":"WIKI bad","intentFilter":["de.fhem:ABC"],"sendIntentNotRecognized":false,"sessionId":"wohnzimmer-alexa-7508d27c-8dad-49c9-aab0-edc69f2b5779","siteId":"wohnzimmer","text":"d"}
hermes/nlu/query {"input": "suche", "siteId": "wohnzimmer", "id": null, "intentFilter": ["de.fhem:ABC"], "sessionId": "wohnzimmer-alexa-7508d27c-8dad-49c9-aab0-edc69f2b5779", "wakewordId": "alexa", "lang": null, "customData": "WIKI bad", "asrConfidence": 1.0, "customEntities": null}
hermes/nlu/intentParsed {"input": "suche", "intent": {"intentName": "de.fhem:ABC", "confidenceScore": 1.0}, "siteId": "wohnzimmer", "id": null, "slots": [{"entity": "Ch", "value": {"kind": "Unknown", "value": "suche"}, "slotName": "Ch", "rawValue": "suche", "confidence": 1.0, "range": {"start": 0, "end": 5, "rawStart": 0, "rawEnd": 5}}], "sessionId": "wohnzimmer-alexa-7508d27c-8dad-49c9-aab0-edc69f2b5779"}
hermes/intent/de.fhem:ABC {"input": "suche", "intent": {"intentName": "de.fhem:ABC", "confidenceScore": 1.0}, "siteId": "wohnzimmer", "id": null, "slots": [{"entity": "Ch", "value": {"kind": "Unknown", "value": "suche"}, "slotName": "Ch", "rawValue": "suche", "confidence": 1.0, "range": {"start": 0, "end": 5, "rawStart": 0, "rawEnd": 5}}], "sessionId": "wohnzimmer-alexa-7508d27c-8dad-49c9-aab0-edc69f2b5779", "customData": "WIKI bad", "asrTokens": [[{"value": "suche", "confidence": 1.0, "rangeStart": 0, "rangeEnd": 5, "time": null}]], "asrConfidence": 1.0, "rawInput": "suche", "wakewordId": "alexa", "lang": null}
hermes/dialogueManager/startSession {"init":{"canBeEnqueued": true,"customData": "de.fhem","text": "WIKI badsuche","type": "notification"},"siteId": "wohnzimmer"}
hermes/dialogueManager/sessionEnded {"termination": {"reason": "nominal"}, "sessionId": "wohnzimmer-alexa-7508d27c-8dad-49c9-aab0-edc69f2b5779", "siteId": "wohnzimmer", "customData": "WIKI bad"}


p.s. Nun läuft auch die Übergabe an die Wikiabfrage. Dazu habe ich die sub Wikipedia etwas umgeschrieben und statt return ein speak aufgerufen.  8)
Ist natürlich nur eine temporäre Teststellung zur Forschung und Entwicklung...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 14 Juli 2021, 18:30:11
Mobil-kurz:
Die Rückgabe aus der sub muss! anders sein array ? => cref der Muater-myUtils
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 15 Juli 2021, 07:49:34
Längere Antwort unter Berücksichtigung deines Edits:

Zu Forschungszwecken ist das Vorgehen ok, externe Tools zu verwenden und Teile des Codes auszukommentieren. Aber an sich ist handleCustomIntent() vorbereitet, um auch Dialoganforderungen "mit Bordmitteln" zu erledigen ;) .

Es muss nur durch die Perl-Funktion eine passende Datenstruktur zurückgegeben werden, dann sollte das Modul alles "von alleine" machen. Die myUtils wird ausgeführt, der Rückgabewert landet in "$error", der wird dann geprüft:
if ( ref $error eq 'ARRAY' ) {
        $response = ${$error}[0] // getResponse($hash, 'DefaultConfirmation');
        if ( ref ${$error}[0] eq 'HASH') {
            $timeout = ${$error}[1] if looks_like_number( ${$error}[1] );
            return setDialogTimeout($hash, $data, $timeout, ${$error}[0]);
        }
        respond( $hash, $data, $response );
        return ${$error}[1]; #comma separated list of devices to trigger
    } elsif ( ref $error eq 'HASH' ) {
        return setDialogTimeout($hash, $data, $timeout, $error);
    } else {
        $response = $error; # if $error && $error !~ m{Please.define.*first}x;
    }


Was macht das nun:
Kommt "nichts" zurück => defaultConfirmation wird angesagt
Kommt "scalar" zurück => Das wird als Text behandelt und angesagt, Dialog ist fertig
Kommt Datentyp "HASH" zurück => Es handelt sich um einen Dialog! Der Hash wird 1:1 durchgereicht an "setDialogTimeout()" (=> der "customData"-key kann gesetzt werden!), timeout wird mit dem Standartwerten abgehandelt
Datentyp ist ARRAY: $timeout kann verändert werden, $response wird an setDialogTimeout() durchgereicht => Dialog bleibt offen, $response (innerhalb des ARRAY, kann auch Datentyp HASH sein => s.o.) wird durchgereicht.

Erforderlichenfalls können wir das ARRAY mit einer Option erweitern, den intentFilter auch noch zu setzen (geht aber auch innerhalb der HASH-$response-Struktur).

Klingt vermutlich kompliziert, aber es sollte - ohne Eingriff in den RHASSPY-Code (!) - schon jetzt möglich sein, die volle Dialogsteuerung via myUtils zu übernehmen ;) . Da sollte dann auch "clean" JSON erzeugt werden.

PS: "qq" würde ich dir noch ans Herz legen.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 15 Juli 2021, 09:01:18
Vielen Dank für deine ausführliche Antwort.
qq{} - da muss ich mich noch disziplinieren...

Berichtige mich bitte, wenn ich daneben liege:


Das geht solange, bis das Schüsselwort qq{suche} erkannt wird. Dann wird von der sub ABC die sub Wikipedia mit dem Übergabewert $CustomData aufgerufen (hier nicht im Code).
Der Wechsel der Intents WIKI->ABC innerhalb einer Session führt doch zwangsweise zum Neuaufruf der sub ABC.?
Hast du einen Beispiel-Hash, welchen ich nach 3. an das Modul zurückgeben muss?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 15 Juli 2021, 11:13:25
@all: Anbei mal wieder eine aktualisierte Fassung. Im Code selbst ist nicht viel passiert, aber die cref ist aktualisiert, zum einen s.u., zum anderen https://forum.fhem.de/index.php/topic,120779.msg1166266.html#msg1166266 (https://forum.fhem.de/index.php/topic,120779.msg1166266.html#msg1166266) (feedback zu letzterem wäre klasse...!)

Zitat von: JensS am 15 Juli 2021, 09:01:18
qq{} - da muss ich mich noch disziplinieren...
Wenn man's mal "hat", ist es sehr viel einfacher...

ZitatBerichtige mich bitte, wenn ich daneben liege:

       
  • Session wird erzeugt und mit dem Intent [WIKI] an das Modul übergeben.
  • Das Modul erkennt einen customIntent und ruft die sub WIKI auf.
    [/l][/l][/l][/l][/l][/l][/l][/l][/l]
Bis dahin richtig, aber 3. gibt nicht, es geht _immer_ 4. weiter (bzw. so sollte der myUtils-Code strukturiert sein)
Zitat
   

          
  • Die sub WIKI ruft bei der Basis ein continueSession für den Intent ABC auf.
  • Die sub WIKI ist durchgelaufen und das Modul ist wieder dran.

    [/l]
    [/l][/l][/l][/l][/l][/l]
Das Modul prüft dann anhand der Datenstruktur der Rückgabe (explizites "return $whatYouWant"!), was genau der User nach dem MyUtils-Aufruf haben will - genau das ist ja der "Trick" an der Sache: Es funktioniert an/ bzw. nach der Stelle ganz genauso wie innerhalb des Moduls, nur dass eben anhand des Datentyps entschieden wird, ob der Dialog offen bleiben soll (=>continueSession, indirekt über den
setDialogTimeout()-Call ) oder eben nicht...

Die cref habe ich mir unter diesem Gesichtspunkt auch nochmal angesehen, da war bzgl. dieser Dinge noch ein alter Stand verarbeitet.
Zitat
5. Die Basis fragt nach einem Buchstaben und übergibt die Daten mit dem neuen Intent ABC an das Modul.
6. Das Modul erkennt einen customIntent und ruft die sub ABC auf.
5. ist Abhängig von dem, was du zurückgibst, das kann die Frage nach dem Buchstaben sein, und der HASH kann dann auch einen intentFilter setzen, der nur noch "de.fhem.ABC" (und mAn. auch zweckmäßigerweise immer "de.fhem.CancelAction") aktiv hält.

Danach geht es "ganz normal" weiter, es kann also jeder beliebige aktive Intent weiterverarbeitet  werden, egal, ob Modulintern oder Custom.

Zitat
Das geht solange, bis [...]
Das geht theoretisch bis in alle Ewigkeit, bei jedem Durchlauf muss halt jeweils eine "passende" Rückgabe erfolgen. Solange jeweils wieder ein HASH an das Modul zurückgeht, solange bleibt auch der Dialog offen (timeout ausgenommen...).

Zitat
Hast du einen Beispiel-Hash, welchen ich nach 3. an das Modul zurückgeben muss?
Im Modul selbst wird eigentlich nur innerhalb des setDialogTimeout()-Codes ein $response-HASH gebaut, dort heißt er $reaction (am besten ab #1270 anfangen zu lesen wg. des Zusammenbauens des intentFilters).

(Aus Listen zu zitieren ist echt schwierig in der Nachformatierung...)
   
   
[/list][/list]
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 15 Juli 2021, 11:59:29
Der Hash ist mir doch noch unklar. Soll ich in der sub WIKI und ABC die Keys und Values von siteId, sessionId, intentFilter, sendIntentNotRecognized, text und customData in ein HASH legen und dann mit return übergeben? Reicht das?

Die cref muss ich mir erstmal Wort für Wort anschauen und in meinem 8-Bit-Rechner(Kopf) übersetzen.
Das letzte Wort aus Zeile 4634 habe ich schon mal verstanden.  ;D

Ein Beispiel zum Tweak intentFilter fände ich hilfreich.
Insgesamt ist das schon eine sehr weitreichende Anleitung.  :Daumenhoch
Für eine Neuinstallation durch einen Rhasspy-Beginner könnte noch ein Hinweis zu einer sentences.ini-Anleitung rein.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 15 Juli 2021, 12:56:53
Zitat von: JensS am 15 Juli 2021, 11:59:29
Der Hash ist mir doch noch unklar. Soll ich in der sub WIKI und ABC die Keys und Values von siteId, sessionId, intentFilter, sendIntentNotRecognized, text und customData in ein HASH legen und dann mit return übergeben? Reicht das?
M.E. ist das sogar zu viel: die "Kommunikationsdaten" siteId und sessionId sind bekannt (in $data enthalten) und brauchen mAn. nicht gesondert übergeben zu werden

Zitat
Die cref muss ich mir erstmal Wort für Wort anschauen und in meinem 8-Bit-Rechner(Kopf) übersetzen.
So war's gar nicht gemeint: Es geht v.a. darum, dass die Hilfetexte jetzt auch erscheinen sollten, wenn man ein (mit beliebigem RHASSPY-prefix versehenes) Attribut an einem "fremden" Device auswählt, sieht man die Beschreibung (aktuelles FHEMWEB vorausgesetzt) direkt beim Auswählen des Attributs ;) . Screenshot anbei (das ist ein MQTT2_DEVICE).

ZitatEin Beispiel zum Tweak intentFilter fände ich hilfreich.
"just adding their names" meint: einfach die Namen (ohne "de.fhem.") hinschreiben...
attr RHASSPY rhasspyTweaks intentfilter=ABC 2.filter Phantasie:true
(Das letzte macht eigentlich keinen Sinn...)

Zitat
Insgesamt ist das schon eine sehr weitreichende Anleitung.  :Daumenhoch
Für eine Neuinstallation durch einen Rhasspy-Beginner könnte noch ein Hinweis zu einer sentences.ini-Anleitung rein.
Danke auch für die allgemeine Rückmeldung.
Das mit sentences.ini ist ein guter Punkt; nach meinem Geschmack wäre es gut, wenn man da jeweils ein (kurzes!) Beispiel in der "intent"-Liste am Ende hätte, aber evtl. wäre auch ein globaler (de-) Link ok. Letztlich finde ich die Haltung von drhirn berechtigt, dass "irgendwann" auch gut ist mit der Doku. Die muss/soll soweit gehen, dass man weiß, wie man es in etwa einrichtet, aber dann ist auch "gut"...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 15 Juli 2021, 19:49:21
Ok, das mit den Hilfetexten bei der Auswahl von z.B. rhasspyMapping funktioniert (getestet mit Edge).

sentences.ini - Wir paar User sind mittlerweile mit Rhasspy und dem Modul vertraut. Anfangs war es nicht ganz trivial reinzufinden und jetzt gibt es wesentlich mehr Optionen, bei denen man noch nicht mal weiß, ob man sie braucht.

continueSession - habe ich folgende sub:sub WIKI{
my $data = shift // return;
my $SessionJSON = decode_json($data);
my $SessionID = $SessionJSON->{'sessionId'};
my $SiteID = $SessionJSON->{'siteId'};

my %ReturnHash = (
siteId => qq{$SiteID},
sessionId => qq{$SessionID},
intentFilter => qq{de.fhem:ABC},
customData => qq{WIKI},
text => qq{Bitte buchstabiere}
);

return %ReturnHash
}

Nun erwarte ich die Aufforderung "Bitte buchstabiere" aber nichts passiert.
Die Session wird vom Modul beendet.
hermes/intent/de.fhem:WIKI {"input": "bitte schlage in der Wikipdia nach", "intent": {"intentName": "de.fhem:WIKI", "confidenceScore": 1.0}, "siteId": "wohnzimmer", "id": null, "slots": [], "sessionId": "wohnzimmer-alexa-c03a7f9b-b8e9-43f9-a3ff-9ea0ebb392ef", "customData": "alexa", "asrTokens": [[{"value": "bitte", "confidence": 1.0, "rangeStart": 0, "rangeEnd": 5, "time": null}, {"value": "schlage", "confidence": 1.0, "rangeStart": 6, "rangeEnd": 13, "time": null}, {"value": "in", "confidence": 1.0, "rangeStart": 14, "rangeEnd": 16, "time": null}, {"value": "der", "confidence": 1.0, "rangeStart": 17, "rangeEnd": 20, "time": null}, {"value": "Wikipdia", "confidence": 1.0, "rangeStart": 21, "rangeEnd": 29, "time": null}, {"value": "nach", "confidence": 1.0, "rangeStart": 30, "rangeEnd": 34, "time": null}]], "asrConfidence": 0.999430304, "rawInput": "bitte schlage in der wikipdia nach", "wakewordId": "alexa", "lang": null}
hermes/dialogueManager/endSession {"customData": "alexa","intentFilter": null,"sessionId": "wohnzimmer-alexa-c03a7f9b-b8e9-43f9-a3ff-9ea0ebb392ef","siteId": "wohnzimmer","text":5}
hermes/dialogueManager/sessionEnded {"termination": {"reason": "nominal"}, "sessionId": "wohnzimmer-alexa-c03a7f9b-b8e9-43f9-a3ff-9ea0ebb392ef", "siteId": "wohnzimmer", "customData": "alexa"}

Hab' ich immer noch falsch verstanden... :-\
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 15 Juli 2021, 19:56:19
Ungetestet: Versuch's mal mit geschweiften Klammern statt rundenmy %ReturnHash = {
Edit: evtl. auch die Referenz auf den Hash zurückgeben...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 15 Juli 2021, 21:26:35
"my $ReturnHash ={" passt.
Also ein Schritt weiter.hermes/nlu/intentParsed {"input": "bitte schlage in der Wikipdia nach", "intent": {"intentName": "de.fhem:WIKI", "confidenceScore": 1.0}, "siteId": "wohnzimmer", "id": null, "slots": [], "sessionId": "wohnzimmer-alexa-1811f6f9-2e60-4263-8a54-494715a146c5"}
hermes/intent/de.fhem:WIKI {"input": "bitte schlage in der Wikipdia nach", "intent": {"intentName": "de.fhem:WIKI", "confidenceScore": 1.0}, "siteId": "wohnzimmer", "id": null, "slots": [], "sessionId": "wohnzimmer-alexa-1811f6f9-2e60-4263-8a54-494715a146c5", "customData": "alexa", "asrTokens": [[{"value": "bitte", "confidence": 1.0, "rangeStart": 0, "rangeEnd": 5, "time": null}, {"value": "schlage", "confidence": 1.0, "rangeStart": 6, "rangeEnd": 13, "time": null}, {"value": "in", "confidence": 1.0, "rangeStart": 14, "rangeEnd": 16, "time": null}, {"value": "der", "confidence": 1.0, "rangeStart": 17, "rangeEnd": 20, "time": null}, {"value": "Wikipdia", "confidence": 1.0, "rangeStart": 21, "rangeEnd": 29, "time": null}, {"value": "nach", "confidence": 1.0, "rangeStart": 30, "rangeEnd": 34, "time": null}]], "asrConfidence": 1.0, "rawInput": "bitte schlage in der wikipdia nach", "wakewordId": "alexa", "lang": null}
hermes/dialogueManager/continueSession {"customData": "WIKI","intentFilter": "de.fhem:ABC","sessionId": "wohnzimmer-alexa-1811f6f9-2e60-4263-8a54-494715a146c5","siteId": "wohnzimmer","text": "Bitte buchstabiere"}
hermes/dialogueManager/endSession {"customData": "alexa","intentFilter": null,"sessionId": "wohnzimmer-alexa-1811f6f9-2e60-4263-8a54-494715a146c5","siteId": "wohnzimmer","text": "Tut mir leid, da hat etwas zu lange gedauert"}
hermes/dialogueManager/sessionEnded {"termination": {"reason": "nominal"}, "sessionId": "wohnzimmer-alexa-1811f6f9-2e60-4263-8a54-494715a146c5", "siteId": "wohnzimmer", "customData": "alexa"}

Rhasspy reagiert auf keine Ansprache.
hermes/dialogueManager/continueSession {"customData": "WIKI","intentFilter": "de.fhem:ABC"
Bei intentFilter müssen noch die eckigen Klammern rein. ["de.fhem:ABC"]
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 15 Juli 2021, 21:33:48
 
Zitat(am besten ab #1270 anfangen zu lesen wg. des Zusammenbauens des intentFilters
).
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 15 Juli 2021, 21:39:29
Ok, intentFilter => [qq{de.fhem:ABC}] passt.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 16 Juli 2021, 07:44:21
Zitat von: JensS am 15 Juli 2021, 21:39:29
Ok, intentFilter => [qq{de.fhem:ABC}] passt.
...jein...: Für eine Musterlösung würde ich empfehlen, immer auch "CancelAction" aktiv zu lassen, damit der User auch immer die Option hat, aktiv aus dem Dialog auszusteigen. Und "qq" brauchst du hier nicht, es gibt keine Variablen aufzulösen => "qw"

Und meine Vermutung ist weiter, dass es unnötig (mind., evtl. sogar irreführend) ist, in den Hash sieteId und sessionId mit aufzunehmen. Wirf es zumindest testweise bitte mal raus. Diese Daten werden mAn. von "respond()" sowieso "passend" ergänzt (bzw. vermutlich in diesem Fall überschrieben). Würde evtl. Sinn machen, die cref zu den HASH-Inhalten zu ergänzen, ich müßte nur mal schauen, wie es mit zusätzlichen Inhalten ausschaut (v.a. "lang").
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 16 Juli 2021, 09:41:53
Ok, das vereinfacht die Sache. Noch einfacher wäre ein kurzes Beispiel gewesen.
Hier (als Info) mein aktueller Einstieg in den Dialog:sub WIKI{
my $ReturnHash = {
sendIntentNotRecognized => true,
intentFilter => [qq{de.fhem:ABC}],
customData => qq{WIKI },
text => qq{bitte buchstabiere}
};
return $ReturnHash;
}
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 16 Juli 2021, 10:01:58
Zitat von: JensS am 16 Juli 2021, 09:41:53
Ok, das vereinfacht die Sache.
:) ...ebend. Der Code sollte von der Struktur her schon so aufgebaut sein, dass es insgesamt relativ einfach ist, zu einem akzeptablen Ergebnis zu gelangen... Scheint halbwegs funktioniert zu haben 8) .

ZitatNoch einfacher wäre ein kurzes Beispiel gewesen.
Klar... Ich war nur erst mal froh, das innerhalb des Moduls soweit auf die Reihe gebracht zu haben ;D . Und "jemand" hat den Ball ja jetzt aufgenommen ;) .

Ich würde das Beispiel allerdings (ungetestet) so schreiben:
sub WIKI {
    my $ReturnHash = {
        sendIntentNotRecognized => q{true},
        intentFilter => [qw(de.fhem:ABC de.fhem:CancelAction)],
        customData => q{WIKI },
        text => q{bitte buchstabiere}
    };
    return $ReturnHash;
}

Für die Feinheiten - unsicher bin ich, ob
- man besser "return \$ReturnHash;" schreiben sollte, und
- "true" auch ohne Quotes ok ist oder ob das ohne Quotes erst (Perl-intern) irgendeine Sonderbehandlung braucht...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 16 Juli 2021, 10:48:10
Zitat von: Beta-User am 16 Juli 2021, 10:01:58Und "jemand" hat den Ball ja jetzt aufgenommen ;) .
Gern  :) .
"return \$ReturnHash;" bringt Fehler - "return $ReturnHash;" läuft.
true mit einfachen Quotes funktioniert genauso wie ohne Quotes.

p.s.
Der Dialog ist ziemlich empfindlich und bricht häufig mit sendIntentNotRecognized ab.
Ich nehme an, dass durch die etwas verzögerte Ausgabe des Textes (bitte buchstabiere, a, etc.), ein lokales Echo als Antwort erkannt wird. Mit text => q{} funktioniert es besser.
Leider hat das "ReSpeaker 2-Mics Pi HAT" kein internes Echo-Canceling und das macht es etwas aufwändiger.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 19 Juli 2021, 19:48:32
Habe ein seltsames Verhalten bei einem rhasspyShortCut.
i="Gartensprenger einschalten" f="set Gartensprenger on" n="Gartensprenger" c="Soll ich wirklich den Garten sprengen?" ct=10
Die Anweisung und die Rückfrage werden richtig erkannt und der dummy Gartensprenger wird auch geschalten.
Am dummy hängt ein Notify, welches $EVENT an ein FRM_Out-Device weitergibt. Das funktioniert nur in diesem Zusammenhang nicht. Bei der Eingabe von "set Gartensprenger on" läuft's.
Sieht so aus, als würde kein Event ausgelöst.
Jetzt kommt das Merkwürdige - bei:i="Beleuchtung einschalten" f="set Stehlampe on" n="Stehlampe" c="Soll ich die Stehlampe wirklich einschalten?" ct=10funktioniert es. Hier wird allerdings das Device (Zigbee2MQTT) direkt geschalten.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 20 Juli 2021, 08:02:00
Vermutung:
Wir sind innerhalb einer Event-Verarbeitungsschleife. Die wird (u.a.) "per name" abgearbeitet (v.a., um unbeabsichtigte Schleifen zu verhindern). Damit ich nicht den kompletten Code in fhem.pl checken muss, wäre es gut, du könntest mal testen, ob es was ändert, wenn du
-  "Gartensprenger" umbenennst, so dass er z.B. mit "Z" beginnt (bzw. das notify?);
- den FRM_out als readingsProxy (statt dummy+notify) konfigurierst
- die Event-Priorität vom RHASSPY-Gerät änderst (Details siehe https://wiki.fhem.de/wiki/DevelopmentModuleIntro#X_Notify):
$hash->{NotifyOrderPrefix} = "45-";
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 20 Juli 2021, 17:50:28
Zitat von: Beta-User am 20 Juli 2021, 08:02:00
-  "Gartensprenger" umbenennst, so dass er z.B. mit "Z" beginnt (bzw. das notify?);
...funktioniert nicht.

Zitat- den FRM_out als readingsProxy (statt dummy+notify) konfigurierst
Den dummy brauche ich für weitere Abfragen (Zeitsteuerung inkl. Bodenfeuchte $ Regen). FRM_out kann direkt geschalten werden.

Zitat- die Event-Priorität vom RHASSPY-Gerät änderst (Details siehe https://wiki.fhem.de/wiki/DevelopmentModuleIntro#X_Notify):
Das geht doch nur im Modul selbst - also dummy.?

Mit einem DOIF ging es auch nicht, obwohl in verbose 5dummy set Gartensprenger onsteht.

Als Zwischenlösung lasse ich zwei Devices mit Perl schalten.i="Gartensprenger einschalten" p={fhem("set Gartensprenger on");; fhem("set FRM_13 on")} c="Soll ich wirklich den Garten sprengen?" ct=10
i="Gartensprenger ausschalten" p={fhem("set FRM_13 off");; fhem("set Gartensprenger off")} c="Soll ich den Gartensprenger wirklich ausschalten?" ct=10
n=... habe ich rausgenommen, da ich keinen Verweis im Modul gesehen habe.

Gruß Jens
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 21 Juli 2021, 08:03:14
Danke für's testen, auch wenn ich manche Punkte noch nicht so recht nachvollziehen kann...:

Zitat von: JensS am 20 Juli 2021, 17:50:28
...funktioniert nicht.
Bezieht sich das auf beide Varianten? Auch das Umbenennen des notify?

Zitat
Den dummy brauche ich für weitere Abfragen (Zeitsteuerung inkl. Bodenfeuchte $ Regen). FRM_out kann direkt geschalten werden.
Nachvollziehbar.

Zitat
Das geht doch nur im Modul selbst - also dummy.?
Gemeint war wie geschrieben: im RHASSPY-Code. Da aber RHASSPY selbst gar nicht "notified" wird, war das wohl so oder so zu kurz gedacht.

ZitatMit einem DOIF ging es auch nicht, obwohl in verbose 5dummy set Gartensprenger onsteht.
DOIF kenne/verstehe ich nicht, aber mAn. ist das auch nicht anders wie bei notify. Vielleicht kommt es auf den trigger bzw. darauf an, dass NOTIFYDEV gesetzt/erkannt wird, wobei das ja der Fall zu sein scheint...?

Zitatn=... habe ich rausgenommen, da ich keinen Verweis im Modul gesehen habe.
Das ist mit einiger Sicherheit kontraproduktiv!

Zur Erläuterung: Das RHASSPY-Modul/parseFn gibt an fhem.pl eine Liste der Geräte zurück, die "getriggert" wurden. Welche, gibt man u.A. über diesen Parameter an. Fehlt er, wird nur der Name der RHASSPY-Instanz zurückgegeben (bzw. bei "fhem"-Befehlen kann es sein, dass die analysiert werden(? müßte ich nachsehen)).
Diese Liste wird dann von fhem.pl analysiert und es werden dann nur die  Event-Handler "informiert", die - bei  vorhandenem NOTIFYDEV - ein Gerät aus dieser Liste damit abdecken, oder die das Internal nicht gesetzt haben (aber damit tendenziell ineffizienter sind, weil sie alles selbst analysieren müssen).
Wenn das also klappt, liegt es entweder daran, dass die automatische Erkennung (bei mehreren Befehlen sicher nur teilweise!) funktioniert, oder der betreffende Eventhandler "unsauber" ist.

(Die Reihenfolge der Benachrichtigtung richtet sich dann nach dem Prio-Internal von oben, was z.B. hilft, wenn man ggf. durch einen Event-Handler erst noch einen Reading-Wert ändern will, bevor andere Event-Hanlder das Eregebnis analysieren...)

MAn. sollten wir das in jedem Fall sauber lösen... Ich habe nur weiter keine Idee, wo das Problem ggf. entstehen könnte, wenn "n=" gesetzt ist und NOTIFYDEV auf dieses Device zeigt. (=> show me...)
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 21 Juli 2021, 16:44:50
Zitat von: Beta-User am 21 Juli 2021, 08:03:14
Bezieht sich das auf beide Varianten? Auch das Umbenennen des notify?
Ja, beide Varianten (leider erfolglos) getestet.

ZitatVielleicht kommt es auf den trigger bzw. darauf an, dass NOTIFYDEV gesetzt/erkannt wird, wobei das ja der Fall zu sein scheint...?
Beim f=... ist das nachvollziehbar, bei p=... wird ja der set-Befehl auf Perl-Ebene abgesetzt und sollte auf jeden Fall greifen.

ZitatMAn. sollten wir das in jedem Fall sauber lösen... Ich habe nur weiter keine Idee, wo das Problem ggf. entstehen könnte, wenn "n=" gesetzt ist und NOTIFYDEV auf dieses Device zeigt. (=> show me...)
Bei der Perl-Variante werden Gartensprenger und FRM_13 durch die Perl-Anweisung geschaltet. Daher handelt es sich genau genommen um zwei NOTIFYDEV.

Kannst du testweise ein readingsSingleUpdate auf state setzen? Das ist zwar nicht die feine Art aber hilft eventuell bei der Lösungsfindung.

Gruß Jens

Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 21 Juli 2021, 17:09:16
...immer noch Missverständnisse...:
Zitat von: JensS am 21 Juli 2021, 16:44:50
Beim f=... ist das nachvollziehbar, bei p=... wird ja der set-Befehl auf Perl-Ebene abgesetzt und sollte auf jeden Fall greifen.
Es wird mAn. IMMER geschaltet, unabhängig davon, ob es als Perl- oder FHEM-Anweisung gekennzeichnet ist. Es kann nur sein, dass bei der Perl-Variante die Events (teilweise!) "sauberer" generiert werden bzw. die Liste der getriggerten Geräte nicht ganz so _unvollständig_ ist (wenn mehrere Geräte beteiligt sind);

Zitat
Daher handelt es sich genau genommen um zwei NOTIFYDEV.
NOTIFYDEV ist/war hier technisch zu verstehen, im Sinne eines ganz bestimmten Internals bei Eventhandlern. Vielleicht hilft https://forum.fhem.de/index.php/topic,117075.msg1115704.html#msg1115704 etwas weiter, um zu verstehen, was ich mit dem obigen konkret meine, im RHASSPY-Kontext (etwas versteckt) ggf. dann noch https://forum.fhem.de/index.php/topic,118979.msg1134879.html#msg1134879.

Zitat
Kannst du testweise ein readingsSingleUpdate auf state setzen? Das ist zwar nicht die feine Art aber hilft eventuell bei der Lösungsfindung.
a) weiß ich nicht genau, wie das gemeint ist, und
b) klingt es nach einem üblen Würgaround, der das eigentliche Problem vermutlich dann auch nicht beseitigt: Es MUSS von ParseFn() eine Liste der betroffenen Geräte zurückgeliefert werden, wenn man "seitlich vorbei" versucht, Events zu generieren, klappt das nicht wirklich ;) . (Oder man muß bewußt unsauber (= ineffizient in der Eventverarbeitung) arbeiten).
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 21 Juli 2021, 17:36:34
NOTIFYDEV - eben das "Starting notify loop for dummy ..." fehlt. Egal ob mit einem dummy und f= (und n=) oder einem dummy mit p=.

Folgendes habe ich gerade (erfolglos) probiert:i="Gartensprenger einschalten" p={ my $TueHash = $defs{'Gartensprenger'};; readingsSingleUpdate($TueHash, "state", "on", 1)} c="Soll ich wirklich den Garten sprengen?" ct=10
Setze ich den Perl-Einzeiler in der Befehlszeile ab, wird ordentlich geschaltet.
Wenn ich auf die Frage "Soll ich den Garten wirklich sprengen?" mit "ja bitte" antworte, wird der Block ebenfalls ausfgeführt und ich erhalte statt "ok, mach ich" ein einfaches "on" als Sprachausgabe. Der Status vom dummy ändert sich aber ein Event wird nicht ausgelöst.

p.s.
Kann es sein, dass das shortCut zwischen einem readingsBeginUpdate und einem (noch nicht erfolgtem) readingsEndUpdate hängt?

p.p.s.
Hab's mal auf die Spitze getrieben und einen kompletten ReadingsUpdate-Durchlauf gemacht. Das funktioniert!i="Gartensprenger einschalten" p={ my $TueHash = $defs{'Gartensprenger'};; readingsBeginUpdate($TueHash);; readingsBulkUpdateIfChanged($TueHash, "state", "on", 1);; readingsEndUpdate($TueHash, 1)} c="Soll ich wirklich den Garten sprengen?" ct=10
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 21 Juli 2021, 18:39:43
Sieht nach einem bug bzw. einem Fehler in der Doku aus, versuch's mal mit "d=..." (#680 und #2823)
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 21 Juli 2021, 18:59:01
Zitat von: Beta-User am 21 Juli 2021, 18:39:43
versuch's mal mit "d=..." (#680 und #2823)
...macht Sinn - funktioniert leider auch nicht.

Kurze Zwischenfrage zu u.a. #2824 und #2834:
Wäre     my $cmd    = $shortcut->{perl} if exists $shortcut->{perl}; richtigerer?  :o

Gruß Jens

p.s.
Da das Verhalten nur bei dummys auftritt und bei anderen Typen (z.B. FRM_out) nicht, könnte es auch eine Besonderheit im Eventhandling von 98_dummy.pm sein.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 22 Juli 2021, 11:37:42
Ich wollte nur mal kurz vermelden: Bin eh noch da und lese brav mit. Kann nur nichts beitragen.
Aber habe gerade, wie immer knapp vor einem Urlaub, aus Langeweile wieder ein bisschen mit Rhasspy geredet. Und bin immer noch begeistert ob unser aller Arbeit :)
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 22 Juli 2021, 12:45:11
Zitat von: drhirn am 22 Juli 2021, 11:37:42
Ich wollte nur mal kurz vermelden: Bin eh noch da und lese brav mit. Kann nur nichts beitragen.
Aber habe gerade, wie immer knapp vor einem Urlaub, aus Langeweile wieder ein bisschen mit Rhasspy geredet. Und bin immer noch begeistert ob unser aller Arbeit :)
Dann mal schönen Urlaub!

Im Anhang dann noch eine kleine Aktualisierung (s.u.), die aber weiter das "d=..." aus dem Shortcuts-Attribut (zur Doku passend) in "NAME" übernimmt. (Wir hatten irgendwann eine Diskussion darüber, ob das Kürzel "d" oder "n" sein sollte, weiß aber nicht mehr, wie wir das letztendlich entschieden hatten. Ich finde weiter n=>NAME verständlicher, aber da das auch in der Doku so stand, bleibt das erst mal so...).
Vielleicht schubst du das ins svn? MAn. ist v.a. das mit der verbesserten Doku "cool", ansonsten bin ich auch sehr froh, dass es im großen und ganzen keine größeren offenen Punkt gibt...

(OK, das mit dem komplexeren Dialog, aber da hat JensS jetzt ja auch mit dem myUtils-Buchstabieren ein sehr tolles Beispiel gebaut, mit dem man weiterarbeiten kann!)

Was das mit dem ausbleibenden DoTrigger-Anweisungen nach Dispatch angeht, habe ich mal noch eine Log-4-Meldung eingebaut, in der steht, welche Devices zurückgegeben werden.

Zitat von: JensS am 21 Juli 2021, 18:59:01
...macht Sinn - funktioniert leider auch nicht.
Wird denn im RHASSPY-Hash zu dem Shortcut "NAME" gefüllt?

Habe den Code kurz überflogen, und mAn. müßte das eigentlich im Rückgabe-Array landen, was da steht, es sei denn
- (bisher) es wird Perl ausgeführt, und dieser Code gibt etwas zurück. Das stand etwas anders in der Doku, ich hoffe, den Code jetzt auch an der Stelle entsprechend angepasst zu haben;
- die Devices existieren nicht.

ZitatKurze Zwischenfrage zu u.a. #2824 und #2834:
Wäre     my $cmd    = $shortcut->{perl} if exists $shortcut->{perl}; richtigerer?  :o
Doppelt nein:
- my $foo = "baa" if $baz; ist grundsätzlich eine "unzulässige" Anweisung. (Wenn, dann müßte man $foo vorher einführen);
- wenn der Hash nicht defined ist, bleibt $cmd undefined, und genau das wird später gecheckt.
Falls du strukturelle Zweifel hast (dahingehend, dass immer der erste (oder 2.) Zweig angefahren wird): Verbose 5 sollte Aufschluss geben ;) .

Zitat
Da das Verhalten nur bei dummys auftritt und bei anderen Typen (z.B. FRM_out) nicht, könnte es auch eine Besonderheit im Eventhandling von 98_dummy.pm sein.
Vermute eher, dass FRM_out ein (eigentlich) 2. Event wirft, wenn der Befehl von der Hardware ausgeführt wurde. So sollte es für eigentlich alle bidirektionalen Systeme sein.

Wir sollten als erstes checken, was an fhem.pl-Dispatch() zurückgegeben wird, beginnend mit der sauberen Übernahme in den RHASSPY-Hash als "NAME". Dann sehen wir weiter.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 22 Juli 2021, 13:04:55
Zitat von: Beta-User am 22 Juli 2021, 12:45:11Vielleicht schubst du das ins svn?

Ist erledigt. GitHub auch aktuell.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 22 Juli 2021, 16:50:43
Ok, mit der aktuellen Version und f= und d= wird das Event ausgelöst. Das hatte in der Vorversion mit den selben Bedingungen nicht geklappt.
Die Perl-Anweisung geht nur mit d=. Wenn ich das d= weglasse, weil die Perlanweisung über ein einzelnes Dummy hinausgehen könnte, wird kein Event erzeugt.
2021.07.22 16:25:09 4: dummy set Gartensprenger on
2021.07.22 16:25:09 4: [Rhasspy] dispatch result is Rhasspy


ZitatDoppelt nein:
- my $foo = "baa" if $baz; ist grundsätzlich eine "unzulässige" Anweisung. (Wenn, dann müßte man $foo vorher einführen);
- wenn der Hash nicht defined ist, bleibt $cmd undefined, und genau das wird später gecheckt.
... natürlich. Klar müsste zuvor deklariert werden. Mir ist bei der Initialisierung von shortCuts aufgefallen, dass {perl} nur erzeugt wird, wenn ein p= existiert.
Ein paar Zeilen zuvor wird {perl} zwangsweise deklariert - daher ist ein exists eh falsch.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 22 Juli 2021, 17:24:53
Danke für die Rückmeldung.

Habe ich das jetzt richtig verstanden, dass ich das von der Liste streichen kann, oder ist doch noch was offen?

Ein paar Anmerkungen:
- Eigentlich ist der "f="-Teil gar nicht geändert, nur beim Perl-Zweig wird jetzt (entsprechend der Doku) "d" berücksichtigt.
- Perl wird btw. auch "gesetzt", wenn die Zeile in der "alten Notation" gefunden wird, also nicht mit "i=..." beginnt.
- Es kann jetzt eine "Lücke" geben, wenn der Code Gerätenamen zurückgibt. Die werden jetzt nicht mehr als "getriggert" erkannt. Glaube allerdings nicht, dass das eine größere Anzahl von Usern bisher genutzt hatte...
=> das könnte man auch noch abfangen bzw. erweitern, wenn man das Ergebnis (wie in CustomIntent) auf den Datentyp prüft.  Dann könnte man bei einem Array (usw....).

(Frage mich grade, ob man an der Stelle devspec zulassen sollte (und devspec2array+join dranhängen, was relativ einfach ginge). Konkrete Device-Namen in der Config sind irgendwie gefühlt sehr statisch (aber hier vermutlich verschmerzbar, zumindest solange die Anweisung selbst nicht devspec nutzt...)).
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 22 Juli 2021, 20:30:45
Igendwie muss es eine Änderung gegeben haben, welche auch den f-Zweig in irgendeiner Weise auf die Beine geholfen hat.
Von der Liste streichen - hab ich noch ein flaues Gefühl. Wenn man eine Perlanweisung mit dem gleichen Erfolg, wie in der Befehlszeile absetzen kann - dann gern. Man kann ja einen Hinweis in der cref machen und sich bei Bedarf drum kümmern.
Vorerst ist es für mich eine Möglichket, SetOnOff-Geräte gesichert zu schalten. Muss halt nur eine zusätzliche Anweisung ($de.fhem.Device einschalten) nutzen.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 23 Juli 2021, 07:43:31
Zitat von: JensS am 22 Juli 2021, 20:30:45
Vorerst ist es für mich eine Möglichket, SetOnOff-Geräte gesichert zu schalten. Muss halt nur eine zusätzliche Anweisung ($de.fhem.Device einschalten) nutzen.
...da war doch was...

Bisher gab es praktisch keine Rückmeldung zur "Temperaturanfrage":
Zitat von: Beta-User am 24 Juni 2021, 12:00:12
[...]
3.
- es gibt den neuen Tweak "confirmIntents" (mehr dazu unten);
- und das "Special" "confirm" (s.u.)
- getNeedsConfirmation() als neue zentrale Funktion eingefügt.

[...]
3.
Das mit der Bestätigungsanforderung ist jetzt im eigentlichen Intent-spezifischen Code relativ unaufwändig gelöst. Im aktuellen Beispiel "handleIntentSetOnOffGroup" ist es nur die eine Zeile:
return $hash->{NAME} if !$data->{Confirmation} && getNeedsConfirmation( $hash, $data, 'SetOnOffGroup' );Bevor wir das aber auf diese Art weiter ausrollen, noch ein paar Gedanken dazu:
- Zum Aktivieren (für Gruppen) kann man den beschriebenen Tweak setzen, Syntax ist "intent=<Gruppennamen>". Für diesen Fall halte ich auch die Syntax für ok und verständlich, Gruppen mit Leerzeichen kann man (wie parseParams-üblich) mit dem Setzen passender Quotes ebenfalls verwenden.
Unsicher bin ich allerdings, ob das Komma als Trennzeichen glücklich gewählt ist, denn das Ganze könnte man auch als Regex formulieren und umdrehen, was ggf. die flexiblere Variante wäre. => Meinungen dazu?!? (Meine eigene Tendenz wäre, das in diese Richtung umzubauen)
- Theoretisch geht das genauso (per Tweak) mit den FHEM-Device-Namen und Einzelintents (man muss die Zeile dann nur mit "nicht im Bulk-Modus" ergänzen), ABER:
- Eigentlich finde ich die Logik eingängiger, alles, was mit einzelnen Devices zu tun hat, auch (nur) über "Specials" zu regeln und würde das tendenziell daher als Tweak deaktivieren. Andererseits: eine Regex-Lösung funktioniert mAn. nur zentral, von daher ist meine aktuelle Tendenz, das an der Stelle beizubehalten (eigentlich nur wegen der regex-Option);
- Was "Specials" angeht, ist das derzeit (ungetestet) eine einfache "per-intent"-Lösung. Vermutlich ließe sich das auch noch filigraner lösen (also nur z.B. für das "off"), aber das würde "gefühlt" wieder deutlich mehr Coding erfordern. Insgesamt bin ich gedanklich noch nicht so richtig bei Einzelgeräten angekommen gewesen, und im Moment habe ich erst mal nur die richtige Stelle für die Abfrage bei dem (relativ einfachen (!)) SetOnOff-Intent lokalisiert: Es muss der FHEM-Device-Name bekannt sein, also kurz vor analyzeAndRunCmd() (#2869). Dachte erst, bei anderen Intents gäbe es deutlich mehr Stellen, aber die Zahl der Aufrufe ist zum Glück relativ begrenzt... (Erfahrungsgemäß steckt der Teufel dann aber im Detail, sobald man was umsetzen will ;) ).

Wie ist denn die allgemeine Temperatur dazu? Braucht es filigranere Unterscheidungen (bzw. würde es ggf. reichen, on und off gesondert zu betrachten)?

Mir ist schon klar, dass das Geschreibsel nicht so einfach zu verstehen ist; im Zweifel bitte einfach nachfragen, wie es gemeint ist...

Ansonsten löse ich das ggf. irgendwann dann eben auf die Art und Weise, die mir zu diesem Zeitpunkt grade im Kopf rumspukt... :P
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 23 Juli 2021, 08:03:12
Zitat von: Beta-User am 23 Juli 2021, 07:43:31
Mir ist schon klar, dass das Geschreibsel nicht so einfach zu verstehen ist; im Zweifel bitte einfach nachfragen, wie es gemeint ist...
Das kann ich unterstreichen.  ;)
Anstatt mit vielen Tweaks zu arbeiten, würde ich manche Funktionen in bestehende Intents integrieren. Manchmal ist weniger mehr.

Allgemein fände ich  es gut, wenn es u.a. im SetOnOff-Mapping möglich wäre, eine optionale Rückfrage zu stellen. Bei dem einen Device muss ich aktuell "schalte die Stehlampe an" sagen und beim anderen "Gartensprenger einschalten". Eine Option confirm="Soll ich $DEVICE wirklich einschalten?" (im Zusammenhang mit Confirm- CancelAction) würde das lösen.

Gruß Jens
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 23 Juli 2021, 08:27:22
Stimme Jens zu. Das mit den Tweaks ist nicht so intuitiv. Wie wär's mit einem eigenen Attribut?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 23 Juli 2021, 08:54:36
Zitat von: JensS am 23 Juli 2021, 08:03:12
Das kann ich unterstreichen.  ;)
Anstatt mit vielen Tweaks zu arbeiten, würde ich manche Funktionen in bestehende Intents integrieren. Manchmal ist weniger mehr.
Na ja, ich finde "Tweaks" und "Specials" eigentlich ein gutes Konzept, aber das muss ich wohl auch ;D ...
Zitat von: drhirn am 23 Juli 2021, 08:27:22
Stimme Jens zu. Das mit den Tweaks ist nicht so intuitiv. Wie wär's mit einem eigenen Attribut?
:) du bist der Maintainer...

Meine Meinung/Begründung für "Tweaks"/"Specials":
Irgendwo muss der Content hin, damit das Modul ihn findet. Dazu kann man viele Attribute nutzen, oder eben ein Attribut mit vielen "Schlüsselwörtern".

Attribute zu verwalten, ist von der Modul-Code-Seite her deutlich aufwändiger, und der User muss mehr aufräumen, wenn er das betreffende Modul nicht mehr nutzen will. Außerdem braucht er in der Regel nur ein oder zwei Einträge aus dem ganzen "Strauß".
Mit "Specials" ist jetzt halt ein Attribut vorhanden, in dem er alles gebündelt findet, dazu auch eine cref-Anzeige, in der sämtliche Optionen dann (beim Gerät!) auch direkt gelistet werden.
Ohne Not würde ich das nicht mehr in Richtung Einzelattribut umdrehen, jm2ct...

Oder bezog sich das wirklich nur auf "Tweaks" als (für Einzelanweisungen ungewohntes) Attribut, das sich auf Einzeldevices auswirken kann?

Zitat
Allgemein fände ich  es gut, wenn es u.a. im SetOnOff-Mapping möglich wäre, eine optionale Rückfrage zu stellen. Bei dem einen Device muss ich aktuell "schalte die Stehlampe an" sagen und beim anderen "Gartensprenger einschalten". Eine Option confirm="Soll ich $DEVICE wirklich einschalten?" (im Zusammenhang mit Confirm- CancelAction) würde das lösen.
Das mit dem Rhasspy-Mapping zu machen, ist halt relativ aufwändig in der Analyse der Attributzeile (aber vermutlich lösbar). Das Problem dabei ist nur, dass man dann das komplette Mapping aufschreiben muss und nicht einfach gDT machen lassen kann.
Das mit dem "individuellen Bestätigungssatz" gefällt mir an sich, allerdings braucht man eigentlich zwei (ein/aus), und es ist dann sehr auf diese Funktion zugeschnitten, was es  schwierig macht, das auf andere Aktionen auszuweiten (was aber eh' in den Sternen steht).
Die Idee, einfach den verstandenen raw-Text zurückzugeben, scheint  demnach nicht zu gefallen...? (OK, das könnte man bei einer generischen Umsetzung immer noch als fallback machen, wenn man nichts besseres findet.) Bleibt aber das Problem, dass man bei der Rückfrage dann wissen muss, welche Rückfrage ggf. die spezifische wäre. Ohne in den Code geschaut zu haben: vermutlich nicht ganz unaufwändig, aber lösbar.

Muss mal nachdenken... (aber nicht gleich), und evtl. hat ja noch jemand anderes Gedanken dazu.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 23 Juli 2021, 09:02:47
Zitat von: Beta-User am 23 Juli 2021, 08:54:36
Oder bezog sich das wirklich nur auf "Tweaks" als (für Einzelanweisungen ungewohntes) Attribut, das sich auf Einzeldevices auswirken kann?

Wenn ich dich richtig verstanden habe: Ja
Brauche ich bei einem bestimmten Device eine Bestätigung, aktiviere ich ein Attribut (confirmation=1 oder confirmation="bist du sicher").
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 23 Juli 2021, 09:41:30
Zitat von: drhirn am 23 Juli 2021, 09:02:47
Wenn ich dich richtig verstanden habe: Ja
Ah, Danke für die Klarstellung.

Zitat
Brauche ich bei einem bestimmten Device eine Bestätigung, aktiviere ich ein Attribut (confirmation=1 oder confirmation="bist du sicher").
Wir sind uns einig, dass man die Aktivierung einer Bestätigung für ein einzelnes Device in jedem Fall _bei diesem Device einstellen_ können sollte. MAn. wäre das in "Specials" zu verorten. (Gegen "rasspyMapping" spricht noch, dass das der alte Parser zerlegt, und ich den eigentlich lieber nicht anfassen möchte... Specials kann man immer ergänzen, egal, wo das Mapping herkam ;) ).

Bei "Tweaks" besteht nun das "Problem", dass generischer Code die Angaben dort wohl gegenchecken "muss" (wg. der Gruppen), so dass man als "Nebenwirkung" dann ggf. darüber ein generelles Aktivieren per regex verwirklichen könnte, ohne dass das aufwändig wäre. Im Ergebnis gäbe es dann eben zwei Stellen, von denen man eine tendenziell zwar ausbauen könnte, was aber mit (u.a. Rechen-) Aufwand verbunden wäre...

Zur Syntax:
In Tweaks für Gruppen ist das grade wohl so gelöst:
confirmIntents=SetOnOffGroup=rollläden,deckenlichter
(Nicht so einfach, da einen Satz dazu zu basteln*.)

Für "Specials"  wäre das eher:
confirmIntents=SetOnOff="bist du sicher"
oder (Pipe kann nicht gesprochen werden und wäre daher ggf. ein geeigneter Trenner für ein/aus):
confirmIntents=SetOnOff="$NAME wirklich ausschalten|$NAME wirklich einschalten"

*Was den Satz bei Tweaks angeht:
Könnte man über eine weitere Zeile lösen (confirmIntentsResponses= SetOnOffGroup="$NAME wirklich ausschalten|$NAME wirklich einschalten") oder dann eben (als Rückfallposition) über einen default in languagefile.

(Das wird ggf. "lustig", das zu vercoden...)
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 23 Juli 2021, 10:29:13
Ich hab mir keine Gedanken darüber gemacht, wie das am besten zu programmieren wäre. Aus User-Sicht wär's natürlich optimal, wenn ich einfach ein "Kästchen beim Device anhacken" würde und ich werde nach einer Bestätigung gefragt. Aber schon das mit dem Kästchen ist mit FHEM nicht lösbar ;).

Aber es sollte auf jeden Fall beim zu schaltenden Device zu aktivieren sein. Finde ich.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 23 Juli 2021, 11:09:34
Zitat von: drhirn am 23 Juli 2021, 10:29:13
[...] Aber schon das mit dem Kästchen ist mit FHEM nicht lösbar ;) .
Nanana!!! Klar ginge das auch mit FHEM, warum denn nicht...? 8) ;D 8) ::)

Es müßte  jemand etwas .js-Code beisteuern... :P
Der müßte das dann "nur" in passende Konfigurationsanweisungen übersetzen 8) . Falls jemand die "Attributsprache" zu kompliziert ist: Ich hätte kein Problem damit, den RHASSPY-helper-Hash am Ende der normalen Konfiguration dann z.B. einfach noch mit dem zu ergänzen bzw. zu ersetzen, was aus einem weiteren (JSON-encoded?) Attributinhalt kommt...

(Aber auch so ist es doch eigentlich kein Hexenwerk 8) ).
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 23 Juli 2021, 15:43:45
Zitat von: drhirn am 23 Juli 2021, 10:29:13Aber es sollte auf jeden Fall beim zu schaltenden Device zu aktivieren sein. Finde ich.
... ich auch.  ;D

Die Tweaks und Spezials sind eine gute Sache, für Situationen, welche sich nicht im Device abbilden lassen. Generell sollte eine große Flexibiltät in Bezug auf die Fragen/Antworten erhalten bleiben.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 29 Juli 2021, 10:41:44
...also...:

Zuerst die gute Nachricht:
Ein erster Pfad für "Bestätigung auf Device-Ebene" (auch via "Specials") ist gelegt :) .

Die schlechten:
- das ganze ist von meiner Seite sehr wenig getestet und ausdrücklich experimentell!
- die Syntax in den Attributen (bzw. der betr. Zeilen) gefällt mir noch nicht so ganz => "may" be subject to changes (Ziel: regex, s.u., daher auch noch keine commandref);
- "erster Pfad" meint: vermutlich muss sich im Code noch einiges ändern, und bisher funktioniert es nur für "SetOnOff";
- andere Intents habe ich noch nicht intensiver angesehen, aber insbesondere "SetNumeric" bereitet mir schon jetzt Kopfschmerzen. Will sagen: Ob das jemals (von meiner Seite) kommt, steht in den Sternen...
- das Rückwärtsmapping von "on/off" klappt bisher nur zu "an/aus", und auch nur dann, wenn die "words" in der language-file stehen. Will sagen: das ist ungewohnt unflexibel, und wer am Device dann "auf/zu" haben will, hat derzeit noch keine Chance;
- es wird ein paar Wochen dauern, bis ich mich wieder etwas intensiver damit befassen kann...

Zur Klarstellung zu dem hier:
Zitat von: JensS am 23 Juli 2021, 15:43:45
Die Tweaks und Spezials sind eine gute Sache, für Situationen, welche sich nicht im Device abbilden lassen. Generell sollte eine große Flexibiltät in Bezug auf die Fragen/Antworten erhalten bleiben.
"Specials" ist eigentlich dafür gedacht, Konfigurationen "im Device" (abweichend vom Default, also eben "speziell") abzubilden...

Aktuelle Syntax - global:
attr RHASSPY rhasspyTweaks confirmIntents=SetOnOffGroup=licht,rollläden\
confirmIntentResponses=SetOnOffGroup="$target $Value schalten" SetOnOff="Gerät $target $Value schalten"


bzw. "lokal":
attr Sonos rhasspySpecials confirm: SetOnOffoderattr Sonos rhasspySpecials confirm: SetOnOff="wirklich $target $Value schalten?" SetScene
Gruppen-Intent-Vorgaben gehen nur via Tweaks, falls (!) globale Vorgaben für alle Devices gewünscht sind, geht das (hoffentlich) über Tweaks (dort müßte aber für die Device- bzw. Gruppen-Liste eigentlich eine regex statt Komma-separierter Vorgaben hin), was in "Specials" vorgegeben wird, sollte "Tweaks" vorgehen (dafür das wenig sinnvolle "SetScene"-Beispiel => der Intent "kann" das (noch) nicht, s.o.).

(als Merkposten für mich:
Das mit der "on/off" => "auf/zu" - Geschichte könnte man eventuell über ein confirmValueMapping in "specials" lösen).

Viel Spaß beim Testen!

PS: Es gab hinsichtlich der einen oder andere "großen" Sprachsteuerung jüngst einige Fragen, bei denen ich so ganz klammheimlich bei mir dachte: "Mit RHASSPY hätte man diese Probleme vermutlich nicht und wäre dazu noch deutlich flexibler...!"  8)
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 31 Juli 2021, 09:44:29
Hey - cool!  8)
Funktioniert mit SetOnOff. Habe es alsrhasspySpecials confirm: SetOnOff="$target wirklich $Value schalten?" SetScenedefiniert.
Es kommt die Rückfrage "Stehlampe wirklich ON schalten?" und man kann bestätigen oder abbrechen.
Damit komme ich schon ein ganzes Stück weiter und kann z.B. Gartenakteure sicher in RHASSPY einbinden.

Hin und wieder gerät der Dialog nach der Antwort in eine Endlosschleife "please confirm: ludwig".
Es werden diverse Slots zufällig abgeklappert. ludwig, licht, hell, ...

Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 31 Juli 2021, 09:57:07
ON kann man in words übersetzen.
Für die Schleife habe ich keine Idee, wird dauern...
Ludwig klingt nach buchstabieren...?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 31 Juli 2021, 10:46:21
Der mqtt-Verkehr bei so einer Schleife wäre ggf. interessant.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 31 Juli 2021, 14:44:01
hermes/intent/de.fhem:SetOnOff {"input": "stehlampe on", "intent": {"intentName": "de.fhem:SetOnOff", "confidenceScore": 1.0}, "siteId": "wohnzimmer", "id": null, "slots": [{"entity": "de.fhem.Device", "value": {"kind": "Unknown", "value": "stehlampe"}, "slotName": "Device", "rawValue": "stehlampe", "confidence": 1.0, "range": {"start": 0, "end": 9, "rawStart": 0, "rawEnd": 9}}, {"entity": "Value", "value": {"kind": "Unknown", "value": "on"}, "slotName": "Value", "rawValue": "an", "confidence": 1.0, "range": {"start": 10, "end": 12, "rawStart": 10, "rawEnd": 12}}], "sessionId": "wohnzimmer-alexa-7f762edd-5380-40fb-b1f0-43f8eb16df28", "customData": "alexa", "asrTokens": [[{"value": "stehlampe", "confidence": 1.0, "rangeStart": 0, "rangeEnd": 9, "time": null}, {"value": "on", "confidence": 1.0, "rangeStart": 10, "rangeEnd": 12, "time": null}]], "asrConfidence": 0.9718234, "rawInput": "stehlampe an", "wakewordId": "alexa", "lang": null}
hermes/dialogueManager/continueSession {"customData": "alexa","intentFilter":["de.fhem:ConfirmAction","de.fhem:CancelAction"],"sendIntentNotRecognized": true,"sessionId": "wohnzimmer-alexa-7f762edd-5380-40fb-b1f0-43f8eb16df28","siteId": "wohnzimmer","text": "stehlampe wirklich on schalten?"}
hermes/nlu/intentNotRecognized {"input": "", "siteId": "wohnzimmer", "id": null, "customData": null, "sessionId": "wohnzimmer-alexa-7f762edd-5380-40fb-b1f0-43f8eb16df28"}
hermes/dialogueManager/intentNotRecognized {"sessionId": "wohnzimmer-alexa-7f762edd-5380-40fb-b1f0-43f8eb16df28", "siteId": "wohnzimmer", "input": "", "customData": "alexa"}
hermes/dialogueManager/continueSession {"customData": "intentNotRecognized","intentFilter":["de.fhem:ConfirmAction","de.fhem:CancelAction"],"sendIntentNotRecognized": true,"sessionId": "wohnzimmer-alexa-7f762edd-5380-40fb-b1f0-43f8eb16df28","siteId": "wohnzimmer","text": "please confirm: "}
hermes/nlu/intentNotRecognized {"input": "", "siteId": "wohnzimmer", "id": null, "customData": null, "sessionId": "wohnzimmer-alexa-7f762edd-5380-40fb-b1f0-43f8eb16df28"}
hermes/dialogueManager/intentNotRecognized {"sessionId": "wohnzimmer-alexa-7f762edd-5380-40fb-b1f0-43f8eb16df28", "siteId": "wohnzimmer", "input": "", "customData": "intentNotRecognized"}
hermes/dialogueManager/continueSession {"customData": "intentNotRecognized","intentFilter":["de.fhem:ConfirmAction","de.fhem:CancelAction"],"sendIntentNotRecognized": true,"sessionId": "wohnzimmer-alexa-7f762edd-5380-40fb-b1f0-43f8eb16df28","siteId": "wohnzimmer","text": "please confirm: "}
hermes/nlu/intentNotRecognized {"input": "ida", "siteId": "wohnzimmer", "id": null, "customData": null, "sessionId": "wohnzimmer-alexa-7f762edd-5380-40fb-b1f0-43f8eb16df28"}
hermes/dialogueManager/intentNotRecognized {"sessionId": "wohnzimmer-alexa-7f762edd-5380-40fb-b1f0-43f8eb16df28", "siteId": "wohnzimmer", "input": "ida", "customData": "intentNotRecognized"}
hermes/dialogueManager/continueSession {"customData": "intentNotRecognized","intentFilter":["de.fhem:ConfirmAction","de.fhem:CancelAction"],"sendIntentNotRecognized": true,"sessionId": "wohnzimmer-alexa-7f762edd-5380-40fb-b1f0-43f8eb16df28","siteId": "wohnzimmer","text": "please confirm: ida"}
hermes/nlu/intentNotRecognized {"input": "", "siteId": "wohnzimmer", "id": null, "customData": null, "sessionId": "wohnzimmer-alexa-7f762edd-5380-40fb-b1f0-43f8eb16df28"}
hermes/dialogueManager/intentNotRecognized {"sessionId": "wohnzimmer-alexa-7f762edd-5380-40fb-b1f0-43f8eb16df28", "siteId": "wohnzimmer", "input": "", "customData": "intentNotRecognized"}
hermes/dialogueManager/continueSession {"customData": "intentNotRecognized","intentFilter":["de.fhem:ConfirmAction","de.fhem:CancelAction"],"sendIntentNotRecognized": true,"sessionId": "wohnzimmer-alexa-7f762edd-5380-40fb-b1f0-43f8eb16df28","siteId": "wohnzimmer","text": "please confirm: "}
hermes/nlu/intentNotRecognized {"input": "", "siteId": "wohnzimmer", "id": null, "customData": null, "sessionId": "wohnzimmer-alexa-7f762edd-5380-40fb-b1f0-43f8eb16df28"}
hermes/dialogueManager/intentNotRecognized {"sessionId": "wohnzimmer-alexa-7f762edd-5380-40fb-b1f0-43f8eb16df28", "siteId": "wohnzimmer", "input": "", "customData": "intentNotRecognized"}
hermes/dialogueManager/continueSession {"customData": "intentNotRecognized","intentFilter":["de.fhem:ConfirmAction","de.fhem:CancelAction"],"sendIntentNotRecognized": true,"sessionId": "wohnzimmer-alexa-7f762edd-5380-40fb-b1f0-43f8eb16df28","siteId": "wohnzimmer","text": "please confirm: "}
hermes/nlu/query {"input": "nein danke", "siteId": "wohnzimmer", "id": null, "intentFilter": ["de.fhem:ConfirmAction", "de.fhem:CancelAction"], "sessionId": "wohnzimmer-alexa-7f762edd-5380-40fb-b1f0-43f8eb16df28", "wakewordId": "alexa", "lang": null, "customData": "intentNotRecognized", "asrConfidence": 1.0, "customEntities": null}
hermes/nlu/intentParsed {"input": "Abbruch", "intent": {"intentName": "de.fhem:CancelAction", "confidenceScore": 1.0}, "siteId": "wohnzimmer", "id": null, "slots": [{"entity": "Mode", "value": {"kind": "Unknown", "value": "Abbruch"}, "slotName": "Mode", "rawValue": "nein danke", "confidence": 1.0, "range": {"start": 0, "end": 7, "rawStart": 0, "rawEnd": 10}}], "sessionId": "wohnzimmer-alexa-7f762edd-5380-40fb-b1f0-43f8eb16df28"}
hermes/intent/de.fhem:CancelAction {"input": "Abbruch", "intent": {"intentName": "de.fhem:CancelAction", "confidenceScore": 1.0}, "siteId": "wohnzimmer", "id": null, "slots": [{"entity": "Mode", "value": {"kind": "Unknown", "value": "Abbruch"}, "slotName": "Mode", "rawValue": "nein danke", "confidence": 1.0, "range": {"start": 0, "end": 7, "rawStart": 0, "rawEnd": 10}}], "sessionId": "wohnzimmer-alexa-7f762edd-5380-40fb-b1f0-43f8eb16df28", "customData": "intentNotRecognized", "asrTokens": [[{"value": "Abbruch", "confidence": 1.0, "rangeStart": 0, "rangeEnd": 7, "time": null}]], "asrConfidence": 1.0, "rawInput": "nein danke", "wakewordId": "alexa", "lang": null}
hermes/dialogueManager/endSession {"customData": "intentNotRecognized","intentFilter": null,"sessionId": "wohnzimmer-alexa-7f762edd-5380-40fb-b1f0-43f8eb16df28","siteId": "wohnzimmer","text": "Habe abgebrochen"}
hermes/dialogueManager/sessionEnded {"termination": {"reason": "nominal"}, "sessionId": "wohnzimmer-alexa-7f762edd-5380-40fb-b1f0-43f8eb16df28", "siteId": "wohnzimmer", "customData": "intentNotRecognized"}


Ich denke, beim intentNotRecognized handelt es sich um ein lokales Echo Bestätigungsanfrage. Dazu habe ich noch keine Lösung.

p.s. Ludwig kommt tatsächlich vom ABC-Intent/Slot.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 02 August 2021, 11:50:47
Jetzt mal noch eine etwas längere Antwort zum ganzen...:

Zitat von: JensS am 31 Juli 2021, 09:44:29
Hey - cool!  8)
8)
Zitat
Funktioniert mit SetOnOff. Habe es alsrhasspySpecials confirm: SetOnOff="$target wirklich $Value schalten?" SetScenedefiniert.
Es kommt die Rückfrage "Stehlampe wirklich ON schalten?" und man kann bestätigen oder abbrechen.

Zitat von: Beta-User am 31 Juli 2021, 09:57:07
ON kann man in words übersetzen.
Das bezieht sich auf einen Abschnitt in der language-file, siehe https://svn.fhem.de/trac/browser/trunk/fhem/contrib/RHASSPY/rhasspy-de.cfg#L22 ff

Es gäbe noch einen zweiten "key", den man in der language-file (unter "responses") einsortieren kann, z.B.:
"DefaultConfirmationRequestRawInput": "bitte bestätige $rawInput", (s.u.)

Zitat von: JensS am 31 Juli 2021, 14:44:01
Ich denke, beim intentNotRecognized handelt es sich um ein lokales Echo Bestätigungsanfrage. Dazu habe ich noch keine Lösung.

p.s. Ludwig kommt tatsächlich vom ABC-Intent/Slot.
Aus dem MQTT-Auszug läßt sich die Ursache auch noch nicht abschließend ermitteln, aber "ida" geht auch in diese Richtung. Ich vermute (!), es handelt sich (auch) um ein spezielles Problem, das durch die App (iVm. mit "silence detection") entsteht, wenn man nicht die hotword-Erkennung nutzt, sondern das Mikro manuell einschalten. Dann wird anscheinend das Mikro nicht sauber aus- und anschaltet (wenn Rhasspy das macht, gibt es trigger unter "hermes/hotword/"). Klingt danach, als würde einfach irgendeiner der "kürzesten möglichen" erkannten "Sätze" ausgewählt...
Da wurde in .11 auch was verbessert, wenn ich das richtig verstanden habe. Falls du docker nutzt, wäre ggf. mal ein Wechsel auf die pre-release sinnvoll.

Kann aber auch sein, dass einfach die Länge der Ausgabe falsch berechnet wird? (kommt ggf. auf die TTS-Engine an?).



Vielleicht auch noch ein paar Takte zur Bestätigungs-Anfrage:

Obiger key "DefaultConfirmationRequestRawInput" wird verwendet, wenn nirgendwo was passendes zu finden ist. Da wird einfach der erkannte Text zurückgegeben ($rawInput). Das hat den Vorteil, dass zumindest immer irgendwas (halbwegs) "verständliches" zurückgegeben wird.

Das kann man (in der üblichen Vorgehensweise, dass die speziellere Vorgabe die allgemeine verdrängt) überlagern, indem man entweder in "Specials" was angibt (wie oben zitiert), oder in "Tweaks". Das obige Beispiel aus "confirmIntentResponses" würde dann für alle SetOnOff-Bestätigungsanfragen gelten, bei denen es kein entsprechendes "Special" gibt... Verfügbar sind immer die Variablen $rawInput, $Value (modifiziert durch "words") und $target (Device- bzw- Gruppenname).
(Ob das wirklich in allen Fällen sauber funktioniert, habe ich bisher nicht getestet).

Das Grundproblem bei allen Rückfragen ist, dass man den gefundenen Wert irgendwie "rückübersetzen" muss, was bei on/off noch relativ leicht ist, dann aber schnell ausfasert. An sich wird das "Ausgangswort" sogar mit im JSON übermittelt. Allerdings kann sich der betreffende Inhalt - soweit ich die JSON dazu mal etwas intensiver angesehen hatte - aber leider unter ziemlich vielen "Flaggen" verstecken, so dass mir jedenfalls bisher keine wirklich elegante Option eingefallen ist, das irgendwie soweit rauszuarbeiten, dass man damit weiterarbeiten könnte.
Vermutlich wäre es einfacher, den "words"-Hash (auf Geräte-Ebene => Specials) erweitern/ersetzen zu können, dann könnte man z.B. "on" auch in "ausfahren" übersetzen. Aber damit wäre man so ziemlich am Ende dessen angelangt, was ich glaube (selbst) umsetzen zu können...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 03 August 2021, 16:52:21
Derzeit kämpfe ich mit meinem Viomi S9, der (bisher) nur über die Cloud zu steuern ist. Aber das ist ein anderes Thema...

Der Rhasspy-Dialog läuft nun aktuell zuverlässig.  :)
Die Sprachdatei habe ich angepasst und auch gleich "please confirm" in "bitte bestätige" übersetzt.
Auch das lokal Echo konnte ich durch eine Verlängerung von "silence after" unterdrücken. Bisher fehlerfrei.
Übrigens nutze ich in meinen Systemen (noch) kein Docker.

Vielen Dank @Beta-User!
Sollten wir für Rhasspy ein Feature anregen, das mittels Flag (z.B. [Intent]#deactive) bestimmte Intents per default in der sentences.ini deaktiv setzen kann?
Gruß Jens
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 03 August 2021, 19:34:02
Zitat von: JensS am 03 August 2021, 16:52:21
Vielen Dank @Beta-User!
Gerne!

Zitat
Der Rhasspy-Dialog läuft nun aktuell zuverlässig.  :)
Die Sprachdatei habe ich angepasst und auch gleich "please confirm" in "bitte bestätige" übersetzt.
...da das mit dem "please confirm" dann scheinbar doch "halbwegs" ok ist und das ganze dann halbwegs direkt durch die zentrale Routine "abzufrühstücken" ist, hätte ich anbei die nächste Iteration:
Praktisch alle Device- und Gruppen-set-Kommandos sollten sich jetzt eine Bestätigung holen können, Groups und Devicenamen kann man per regex in "Tweaks" angeben (hoffe ich zumindest).

Zitat
Auch das lokal Echo konnte ich durch eine Verlängerung von "silence after" unterdrücken. Bisher fehlerfrei.

Zitat
Sollten wir für Rhasspy ein Feature anregen, das mittels Flag (z.B. [Intent]#deactive) bestimmte Intents per default in der sentences.ini deaktiv setzen kann?
a) ist mir das noch zu früh, über den Punkt "wie soll es nach einem 'falschen Intent' weitergehen" müssen wir m.E. auch erst nochmal nachdenken, und
b) würde ich davon Abstand nehmen, einen konkreten Vorschlag zur Umsetzung zu unterbreiten.
An sich fände ich es aber nach wie vor richtig, bestimmte Intents komplett wegschalten zu können.

Jetzt wünsche ich erst mal viel Spaß beim weiteren Testen. Kleine (englische) Syntax-Beispiele sind in der cref enthalten.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 03 August 2021, 20:23:41
Zitat von: Beta-User am 03 August 2021, 19:34:02
...da das mit dem "please confirm" dann scheinbar doch "halbwegs" ok ist und das ganze dann halbwegs direkt durch die zentrale Routine "abzufrühstücken" ist, hätte ich anbei die nächste Iteration:
Praktisch alle Device- und Gruppen-set-Kommandos sollten sich jetzt eine Bestätigung holen können, Groups und Devicenamen kann man per regex in "Tweaks" angeben (hoffe ich zumindest).
confirmValueMap ist cool.  8)

Zitata) ist mir das noch zu früh, über den Punkt "wie soll es nach einem 'falschen Intent' weitergehen" müssen wir m.E. auch erst nochmal nachdenken
Was meinst du genau? Gibt's unbehandelte Zustände?

Zitatb) würde ich davon Abstand nehmen, einen konkreten Vorschlag zur Umsetzung zu unterbreiten.
An sich fände ich es aber nach wie vor richtig, bestimmte Intents komplett wegschalten zu können.
Ich kann ja mal was vorbereiten und dir vorstellen.?

ZitatJetzt wünsche ich erst mal viel Spaß beim weiteren Testen. Kleine (englische) Syntax-Beispiele sind in der cref enthalten.
Danke, den hab ich - ist gut erklärt und läuft echt gut.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 04 August 2021, 10:02:49
Zitat von: JensS am 03 August 2021, 20:23:41
confirmValueMap ist cool.  8)
Fand ich nach dem ersten Testen auch, der nächste Impuls war dann: Wie bekommt man sowas für Gruppen-Intents hin... ::)
Im Endeffekt würde dann aber vermutlich die Syntax sehr kompliziert ausfallen müssen, mit der man sowas "ver-attributiert" und dann auch wieder auswertet => kommt erst mal auf die Seite (und dann vermutlich nie).

Zitat
Was meinst du genau? Gibt's unbehandelte Zustände?
Jein. Der Dialog bleibt - auch wenn man irgendwas anderes an Rhasspy "reinlabert" - ja solange offen, bis entweder bestätigt oder abgebrochen wird, oder eben dann der timeout zuschlägt, alles andere geht (im Sinne eines (fast*) folgenlosen Funktionsaufrufs) über "intent not recognized". Theoretisch wäre es aber auch möglich, als Reaktion auf "not recognized" rückzufragen, was denn nun passieren soll. "Unbehandelt" ist dann die (neben Confirm/Cancel) die "dritte Option", nämlich den "weiteren Intent" tatsächlich zu erkennen und dann damit weiterzumachen.

Dann müßte man aber
- rückfragen, ob ein Wechsel gewollt ist;
- eine Logik haben, die eine entsprechende "Bestätigung**" erkennt;
- den erkannten raw-Text (*: der wird intern über die Funktion heute schon zwischengespeichert) dann (insbesondere) _nach Änderung des intentFilters_ wieder an die Intent-Erkennung zurückgeben.

** Die Bestätigung für den Wechsel könnte auch ein spezieller Text in der "Cancel"-Behadlung sein, sonst müßte man nochmal einen Intent generieren. So oder so dürfte das ganze im Endergebnis irgendwie "gekünstelt" wirken...

Zitat
Ich kann ja mal was vorbereiten und dir vorstellen.?
Du musst mir nichts vorstellen ;) . Mein Eindruck war/ist lediglich, dass
- das "Grundproblem" mit den nicht komplett ausgeschalteten Intents heute schon "bekannt" und adressiert ist, und es eher an Anschauungsmaterial fehlt, wie sich das konkret auswirkt (so wie dein "Ludwig-Ida-Gestottere"***);
- bisher (außer dem Demo-Script) keine "App" da war, die überhaupt in etwas größerem Umfang dialogische Optionen genutzt hat****. Von daher wäre mein Angang eben eher darzustellen, welche Optionen unsere "App" heute schon bietet, und welche Probleme sich auftun:

-- "Themenwechsel" (bewußt/unbewußt) wie oben beschrieben (für eine Antwort wäre es da ggf. hilfreich zu wissen, als welcher intent es den erkannt worden wäre). Da stellt sich die Frage, ob (und in welchen Fällen) das "Ausschalten" ggf. helfen könnte? (***wäre ein sehr gutes Beispiel).
-- Zu weite/ nicht beschränkbare slots/slot-Werte: Wenn man eine Wahl (z.B zwischen mehreren Devices) anbietet, sollte (vorrangig?) erkannt werden, was zur Wahl steht, und nicht weiter "alles mögliche", was in dem Ausgangsslot stand, oder?

Betr. **** wäre es noch die "Krönung", wenn man sowas wie msgDialog (https://wiki.fhem.de/wiki/MsgDialog) abbilden könnte, aber da habe ich auch noch deutlich zu wenig Erfahrung: Außer einem kleinen "Gespräch" zum Thema Spritpreise ist mir da auch noch nicht viel eingefallen (und das könnte man über einen CustomIntent oder eine Status-Abfrage vermutlich direkter abbilden).

ZitatDanke, den hab ich - ist gut erklärt und läuft echt gut.
Thx. für die Rückmeldung.
Bzgl. "Erklärungen": Wäre nett, wenn sich jemand mal der commandref annehmen würde. Zum einen sehen 4 (oder mehr) Augen immer mehr als 2, und zum anderen habe ich manches (denke grade v.a. auch an die Fein-Strukturierung, wie die Reihenfolge der Attribute/Keys in den Attributen) auch einfach aus der Hüfte geschossen, eventuell fehlen Querverweise, weitere (kleine!) Beispiele, usw., usf... (Das ist mAn. auch keine reine Frage nach Englisch-Kenntnissen).
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 04 August 2021, 21:20:35
Das sind gute Ideen und diese sollten auch relativ gut umsetzbar sein.
Bei zwei intentNotRecognized-Durchläufen könnte man die möglichen Antwortmöglichkeiten vorlesen lassen sowie fragen, ob abgebrochen oder einen Schritt zurückgegangen werden soll.
Eine Auswertung vom raw-Text wäre hier nicht nötig.

Einen msgDialog könnte man relativ einfach aufbauen. Natürlich wird es komplexer, je mehr Möglichkeiten man anbietet. Eine Idee/Spielerei:

Ich: "Alexa, beginne einen Dialog"
Rhasspy: "Ok, was kann ich für dich tun? Schalten oder informieren?
Ich: "informieren"
Rhasspy: Was möchtest du wissen? Status - Temperatur - Leerungstermin ...
Ich: "Temperatur"
Rhasspy: "Ok, die Temperatur von welchem Gerät oder Raum?
Ich: "Garten"
Rhasspy startet de.fhem:GetNumeric mit {Type:temperature} und $de.fhem.Room{Room} und dem vorhandenen hash.
Rhasspy: "Die Temperatur vom Garten beträgt 26 Grad Celsius"

Denkbar?

Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 05 August 2021, 08:04:22
Zitat von: JensS am 04 August 2021, 21:20:35
diese sollten auch relativ gut umsetzbar sein.
Da bin ich eher skeptisch, der Teufel steckt - wie so oft - im Detail...

Zitat
Bei zwei intentNotRecognized-Durchläufen könnte man die möglichen Antwortmöglichkeiten vorlesen lassen sowie fragen, ob abgebrochen oder einen Schritt zurückgegangen werden soll.
Eine Auswertung vom raw-Text wäre hier nicht nötig.
Gedanklicher Ausgangspunkt ist: Wer weiß, wie er mit Rhasspy sprechen muss, kann den direkten Weg nehmen, eigentlich geht es bei den Dialogen immer darum, entweder eine Sicherung einzubauen (Confirm), oder eben eine Benutzerführung zu haben - tendenziell auch für die, die sich nicht mit den Details rumschlagen wollen (Mitbewohner). Für letztere muss das ganze "organisch" sein, sonst wird es (vermutlich) nicht angenommen.

Ergo stellt sich gleich die Frage, wieso erst beim 2. Mal?
Falls es wegen "schwacher" Erkennung des eigentlich gewollten ist, müßte man vorrangig da nacharbeiten, für andere Fälle sehe ich die Notwenigkeit einer Wiederholung nicht, das führt sonst zu einer Wahrnehmung im Sinne von "das Sch..-System reagiert mal wieder nicht!".

Und wenn "zurück", muss man wissen, wohin. Wenn/solange der "Anschlussintent" beliebig ist, kann dann bei einem (bestätigt) absichtlichen Wechsel auch direkt die Auswertung des gespeicherten letzten rawInput erfolgen, sonst müsste man ja nochmal sagen, was bereits (zutreffend!) erkannt wurde => unorganisch.

ZitatDenkbar?
Denkbar ist immer vieles, aber im Detail stelle ich es mir ziemlich schwierig vor, das mit den jetzigen Methoden umzusetzen: Es würde erfordern, dass man die intents wirksam (!) beschränken _und_ die slots @runtime ändern kann. Ginge vielleicht (!) mit voice2json, aber selbst wenn das das kann, ist noch keine Zeile Code geschrieben mit der FHEM die jeweils passenden nächsten Schritte ermitteln könnte.
Kurz: Bevor nicht "ChoiceDevice" 100% funktioniert (mit Beschränkung auf zum vorherigen Schritt passenden Filterungen (!)), braucht man über sowas erst gar nicht nachdenken.
Davon abgesehen dürfte der Programmier- und (!) Konfigurationsaufwand viel zu hoch werden und den großen Mehrwert gegenüber den bereits bestehenden Auswahl-Intents sehe ich auch noch nicht.

Aber vielleicht übersehe ich mal wieder was wesentliches... ::) ?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 05 August 2021, 13:16:27
Was anderes - hier (https://community.rhasspy.org/t/best-esp32-based-hardware-for-satellite/3012/6) ist mir ein interessanter Ansatz über den Weg gelaufen:
ZitatAlternatively, I might put Zigbee based buttons around the house and trigger the hotword through pressing the button
...ist erst mal eher ein Merkposten, aber ggf. hat ja jemand damit Erfahrung, wie man sowas im FHEM-Kontext umsetzt bzw. ob es sinnvoll wäre, eine "start session"-Logik in/zu RHASSPY zu basteln...?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 05 August 2021, 18:06:58
In Bezug auf msgDialog muss ich etwas falsch verstanden haben. Zumindestens sollte es möglich sein, eine Session in msgDialog offen zu halten. Einen msgDialog würde dann auch im msgDialog-Device abgebildet. Wenn man einen frei manipulierbaren [Dialog]-Intent in continueSession hätte, wäre manches einfacher umzusetzen.
Jetzt werden meine Anfragen im Rhasspy-Forum anschaulicher.
Snips hatte einige Erweiterungen mehr. So verstehe ich die Hermes-Referenz bei Snips. Bisher wird es noch kein Erfordernis für variable Slots in continueSession/intentFilter gegeben zu haben. Auch die Möglichkeit, Intents per Standard zu deaktivieren wurde wohl noch nicht gebraucht. Wenn man die Beiträge sieht, ist 10_RHASSPY.pm in dieser Hinsicht wesentlich weiter, als die Entwickler (bisher) geplant haben.
Ich habe mir mal die Rhasspy-Quellen angesehen und es ist in der Tat eine große Aufgabe, die Standard-Deaktivierung zu implementieren. Derzeit wird die Intent-Zeile nur bis ] ausgewertet. Dahinter ist aber noch viel Platz :) .

Bei der intentNotRecognized weiß ich nicht, was du genau vorhast. Klar reicht ein Durchlauf...

Die Zigbee-Geschichte müsste ja nur einen Dialog anschubsen. Letztlich kommuniziert Rhasspy intern auch bloß über MQTT. Also einen Satelliten in der Nähe als siteId angeben und was sonst noch in der ref steht, sollte reichen.

Mit dem ESP habe ich auch schon geliebäugelt. Da meine Zero's aber ihren Dienst tun, bin ich dem nicht nachgegangen.

Ich würde bei Bedarf/Gelegenheit mal einen kleinen msgDialog zusammenbasteln.?

Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 20 August 2021, 12:41:01
Können wir das Attribute languageFile so umbauen, dass man auch mehrere Files angeben kann? Ich hab nämlich das - in einem früheren Post befürchtete - Problem, dass mir ein Update des Files natürlich immer meine "User"-Einträge überschreibt. Um nicht jedes Mal ein diff machen zu müssen, wär's daher praktisch, wenn wir da zwei Files angeben könnten. Ein File, in dem unsere Default-Einträge drinnen stehen. Und eines mit dem "User"-Abschnitt.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 21 August 2021, 08:14:36
Zitat von: drhirn am 20 August 2021, 12:41:01
Können wir das Attribute languageFile so umbauen, dass man auch mehrere Files angeben kann?
Können schon, aber nach etwas Nachdenken bin ich weiter nicht überzeugt, dass das eine gute Lösung wäre.
Argumente dagegen:
- sowas ist nicht configDB-kompatibel
- (Aufwand)
- ist auch nicht unbedingt selbsterklärend, wie dann was ineinandergreifen würde.

Dagegen sind eigentlich nur noch bei größeren Umbauten Änderungen an den keys in der File zu erwarten. Die Nächste, wenn/falls ich die Probleme mit "notRecognized" (und ggf. sowas wie einem "continuous mode") in den Griff bekomme.... Wird aber noch dauern ;) .
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 22 August 2021, 11:37:03
Zitat von: Beta-User am 21 August 2021, 08:14:36
... wenn/falls ich die Probleme mit "notRecognized" (und ggf. sowas wie einem "continuous mode") in den Griff bekomme...
Was meinst du speziell?
Mir ist aufgefallen (#4114 ff) , dass das Modul bei notRecognized den intentFilter auf zurücksetzt und cusomData auf intentNotRecognized gesetzt wird.
Man erhält dann eine "please confirm"-Aufforderung, welche im Hintergrund lediglich die Intents confirmAction und cancelAction zur Verfügung stellt.
Da wäre mir persönlich lieber, den vorigen intentFilter sowie die customData für einen zweiten Versuch zu behalten.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 22 August 2021, 13:06:46
Du hast des Pudels Kern gut getroffen.

"Speziell" teste ich grade an einer Variante rum, die die Frage, ob der nächste Schritt eingeleitet werden soll daran festmacht, wie lang der rawInput des nicht erkannten Intents ist und dann für "Confirm" noch ein paar weitere Varianten kennt. Leider laufe ich damit auch in "Stottereien" rein, die ich mir erst ansehen muss, bevor ich hier einen weiteren Zwischenstand poste...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 27 August 2021, 15:26:05
So, nachdem ich lange genug erfolglos auf den Code gestarrt habe, poste ich halt mal meinen aktuellen Stand - vielleicht findet ja jemand anderes den Dreh, wann und warum es ggf. Stottereien gibt...? (das mit der Erhöhung der Silence-Zeit könnte helfen?). Bin zwischenzeitlich auch auf 2.5.11-preview@deb-Paket.

Anders gesagt: Für "normale User" ist nichts neues drin, und "dialogorientierte" Mitüberleger müssen aufpassen, was sie sagen, wenn RHASSPY auf weiteren Input wartet bzw. den anfragt. (Aber ansonsten sollte eigentlich alles andere weiter funktionieren).

Vorbereitungen:
- Es gibt neue Keys ("default" auswechseln reicht ;) )
- Habe mal "OK" für ConfirmAction noch mit "Back" und "Next" ergänzt, dementsprechend "braucht" man auch was in der sentences.ini:
[de.fhem:ConfirmAction]
( ja mach | tu es | ist ok | aber gerne doch ){Mode:OK}
( lieber doch nicht ){Mode}
( Geh zurück | bleib da ) zurück{Mode:Back}
( Mach | geh ) weiter{Mode:Next}

("Braucht" meint: es ist eigentlich noch gar nicht vollst. relevant, OK reicht im Moment noch).

Die grundsätzliche Idee: Wenn der rawInput zu intentNotRecognized eine gewisse Länge hat, kann man vermuten, dass es die Absicht des Sprechers ist, RHASSPY was anderes mitzuteilen als eine positive oder negative Antwort bzw. eine Auswahlentscheidung. Habe jetzt mal die Grenze etwas willkührlich bei 12 Zeichen gezogen.

Daher erfolgt dann (hoffentlich) eine Rückfrage (bis dahin scheint es nicht nur theoretisch zu funktionieren), ob RHASSPY den neuen Content korrekt erfaßt hat. "Ja" sollte dann dazu führen, dass der neue Content ausgewertet wird (im Prinzip nach denselben Regeln wie eine komplett neue Ansage).
"Prinzipiell" klappt das auch, nur scheint (manchmal) während des Sprechens der Rückfrage durch Rhasspy bereits wieder was erkannt zu werden, was dann im Ergebnis irgendwie ein ungeordnet wirkt, und (noch) keine Regel zu erkennen ist, in welchen Fällen das passiert.

_Falls_ wir das in den Griff bekommen, sollte es dann möglich sein, auch sowas wie "Schalte ein paar Geräte ein" - "welche?" - "[den] Verstärker" - "was sonst?" - "Licht" - "OK, weiter?" ... umzusetzen, und/oder dann von "licht an" auf "dimmen" weiterzugehen usw. (entsprechende Konfiguration vorausgesetzt...). Ist zwar vermutlich im Detail auch "tricky".

Oder hat jemand andere/bessere Ideen, als das über den zentralen "Verteiler" ConfirmAction/Mode laufen zu lassen?
(Ich komme mir vor, als würde ich grade Holzräder schnitzen und würde übersehen, wo die nächstbeste Luftreifenfabrik ist...)
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 27 August 2021, 17:34:11
Prima, das teste ich in der nächsten Woche.

Als ich das von der Stotterei las, kam mir folgende Idee, welche auch funktioniert.
Rhasspy -> Audio Playing -> Local Command -> Program: /opt/ausgabe.sh:#!/bin/bash
amixer -q -c 'seeed2micvoicec' sset Capture 0
cat $1 > /tmp/handy.wav && aplay /tmp/handy.wav
amixer -q -c 'seeed2micvoicec' sset Capture 95

Das wäre eventuell ein Ansatz für die Rhasspy-Entwickler, um das lokale Echo zu verhindern. In der Form allerdings extrem langsam.

Gruß Jens
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 22 September 2021, 14:22:28
Irgendwie scheinen wir alle noch nicht so richtig zum Testen (&Grübeln) gekommen zu sein...

Aber manchmal ist ja ein bißchen Abstand ganz hilfreich, vorliegend jedenfalls, was die Doku (https://forum.fhem.de/index.php/topic,123035.msg1175941.html#msg1175941) anbelangt  ::) .

Leider ist die Doku jetzt auf dem Stand der Testversion mit den "Stottereien", wenn man beim Warten auf eine Bestätigungsanfrage was unpassendes sagt, aber zum einen nutzen das Bestätigungsfeature vermutlich die wenigstens, oder sie sind dann besser motiviert, Abhilfemöglichkeiten zu erruieren... "stable" ist das also nicht, ich hatte aber auch keine Lust, die Doku rückwärts zu portieren).

(Das mit dem script habe ich bisher nicht getestet, ich vermute (begründet mal wieder nur durch Bauchgefühl) weiter irgendeinen Logikfehler in dem, was wir von RHASSPY aus generieren und auswerten).
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 22 September 2021, 14:31:29
Zitat von: Beta-User am 22 September 2021, 14:22:28
Irgendwie scheinen wir alle noch nicht so richtig zum Testen (&Grübeln) gekommen zu sein...

Naja. Es läuft und läuft und läuft. Die drei Befehle, die ich so durchschnittlich am Tag gebe, werden immer korrekt ausgeführt. Mehr Verwendungszweck habe ich offenbar derzeit nicht.

Aufgefallen ist mir nur, dass mir bei einer Frage nach der Temperatur immer zwei Geräte vorgeschlagen werden. Ok soweit. Aber egal, was ich danach sage, es gibt zuerst einen IntentNotRecognized und dann irgendwann "tut mir leid, da hat etwas zu lange gedauert". Es war mir aber bisher nicht wichtig genug, um dem nachzugehen.

Ich stell die neue Version dann am Abend ins SVN. Auf GitHub ist sie schon.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 22 September 2021, 14:38:49
Zitat von: drhirn am 22 September 2021, 14:31:29
Naja. Es läuft und läuft und läuft. Die drei Befehle, die ich so durchschnittlich am Tag gebe, werden immer korrekt ausgeführt. Mehr Verwendungszweck habe ich offenbar derzeit nicht.
So ähnlich ist es bei mir auch...

Zitat
Aufgefallen ist mir nur, dass mir bei einer Frage nach der Temperatur immer zwei Geräte vorgeschlagen werden. Ok soweit. Aber egal, was ich danach sage, es gibt zuerst einen IntentNotRecognized und dann irgendwann "tut mir leid, da hat etwas zu lange gedauert". Es war mir aber bisher nicht wichtig genug, um dem nachzugehen.
Das könntest du mit einer "priority" abstellen, aber solche "Nickeligkeiten" meine ich; interessant ist dann, was in "IntentNotRecognized" denn so alles als rawInput erkannt wurde. Das Verhalten scheint aber auch teils damit zusammenzuhängen, wie der Dialog initialisiert wurde (bei mir macht es gefühlt einen Unterschied, ob die App auf "wakeword" steht (also "base" den Dialog steuert), oder ob man das mit dem "Mikro-Knopf" initiiert.)

ZitatIch stell die neue Version dann am Abend ins SVN. Auf GitHub ist sie schon.
...drum... hatte mich schon gewundert, wo die .39 herkam...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 22 September 2021, 14:48:31
Zitat von: Beta-User am 22 September 2021, 14:38:49
interessant ist dann, was in "IntentNotRecognized" denn so alles als rawInput erkannt wurde.

Kann ich bei Gelegenheit mal liefern.

ZitatDas Verhalten scheint aber auch teils damit zusammenzuhängen, wie der Dialog initialisiert wurde (bei mir macht es gefühlt einen Unterschied, ob die App auf "wakeword" steht (also "base" den Dialog steuert), oder ob man das mit dem "Mikro-Knopf" initiiert.)

Ausschließlich via Wakeword.

Wenn wir schon plaudern: Ich muss gestehen, ich hab mir im Sommer einen Nest Audio organisiert. Weil mich meine Rhasspy-Hardware in der Küche um's Verrecken nicht verstehen will (stark befahrene Straße vor'm Fenster) und die Angebetete beim Abwaschen gerne Musik hat. Und ich muss sagen, es ist schon großartig, was mit dem Rhasspy-Modul alles auf die Beine gestellt wurde! In Verbindung mit FHEM um Ecken besser und einfacher als Google Home. Letzteres hat halt andere Vorteile. Aber das könnten wir alles auch, wenn hinter Rhasspy und RHASSPY Milliarden an Dollar stecken würden ;).
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 22 September 2021, 15:01:28
Zitat von: drhirn am 22 September 2021, 14:48:31
Kann ich bei Gelegenheit mal liefern.
Vermutlich ist das eher was, was sich der jeweilige User (=du) näher ansehen muss, weil das einfach nur "Rohdaten" sind und man "raten" muss, wie und warum es in dieser Form dann zustande gekommen ist...

Zitat
Ausschließlich via Wakeword.
Na ja, es geht bei der Initialisierung mehr um die Frage, _wie_ herum das Karussel fährt, weniger, ob überhaupt ::) ...

Zitat
Wenn wir schon plaudern: Ich muss gestehen, ich hab mir im Sommer einen Nest Audio organisiert. Weil mich meine Rhasspy-Hardware in der Küche um's Verrecken nicht verstehen will (stark befahrene Straße vor'm Fenster) und die Angebetete beim Abwaschen gerne Musik hat. Und ich muss sagen, es ist schon großartig, was mit dem Rhasspy-Modul alles auf die Beine gestellt wurde! In Verbindung mit FHEM um Ecken besser und einfacher als Google Home. Letzteres hat halt andere Vorteile. Aber das könnten wir alles auch, wenn hinter Rhasspy und RHASSPY Milliarden an Dollar stecken würden ;) .
Na ja, für mich ist Rhasspy sehr gut tauglich, wie es ist, und ich teste auch gerne mit (mehr oder weniger melodischem) "Hintergrundgeräusch" ;D . Bin mal gespannt, ob irgendwann mal auch sowas wie ein "App-Store (https://community.rhasspy.org/t/collaboration-with-jaco-assistant-project/1972/44)" (für externe Applikationen) kommt, aber eher aus allgemeinem Interesse, "brauchen" wäre anders...

Wie "umständlich" man manche Dinge mit anderen Lösungen basteln muss, "freut" mich auch immer mal wieder :P . Es ist aber auch klar ein Unterschied, ob man "alles mögliche" erkennen will/muss, oder ob es nur darum geht, einen relativ begrenzten Wortschatz (ordentlich!) zu beherrschen. Ich bin jedenfalls sehr zufrieden mit dieser Offline-Variante, die wir hier gebastelt haben 8) .
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Ziton am 22 September 2021, 17:16:28
Ich bin zumeist auch Happy mit dieser wirklich schönen Offline Variante.

Das größte Ärgernis für mich im Alltag ist immer noch das Wakeword.
Wenn es zuhören soll, tut es das nicht. Wenn es nicht zuhören soll, wird es vom Fernseher aktiviert oder der grade laufenden Unterhaltung.
Ich muss deutlich BumbleBEE sagen damit es klappt und im Fernsehen kann es ein Ton sein der nicht im geringsten etwas damit zu tun hat. Gefolgt von der Spannung welchen
Befehl er aus der laufenden Aufnahme glaubt zu erkennen. Meistens versucht er einen Timer zu stellen was wenig schmerzlich ist. Aber er hat auch schon meinen kompletten TV-Schrank ausgeschaltet
im laufenden Betrieb, was ziemlich ärgerlich war.

Welches Wakeword Modul benutzt ihr bzw. womit habt ihr die besten Erfahrungen gemacht?

Jetzt aktuell ist bei mir aber ein Problem aufgetreten. Ich hab seit längerer Zeit mal wieder versucht ein Licht mit dem SetNumeric Intent zu schalten. Dieser wird von Rhasspy korrekt erkannt und verarbeitet
aber auf FHEM Seite leider nicht. Es kommt zu folgender Ausgabe im Log:
2021.09.22 13:09:24 5: RHASSPY: [RhasspyTK] Parse (IO: Mqtt.Rhasspy): Msg: hermes/dialogueManager/sessionStarted => {"sessionId": "wohnzimmer-bumblebee_raspberry-pi-6ed673af-e988-4056-9525-75132ac2449f", "siteId": "wohnzimmer", "customData": "bumblebee_raspberry-pi", "lang": null}
2021.09.22 13:09:24 5: Parsed value: wohnzimmer for key: siteId
2021.09.22 13:09:24 5: Parsed value: wohnzimmer-bumblebee_raspberry-pi-6ed673af-e988-4056-9525-75132ac2449f for key: sessionId
2021.09.22 13:09:24 5: Parsed value: bumblebee_raspberry-pi for key: customData
2021.09.22 13:09:24 5: room is identified using siteId as wohnzimmer
2021.09.22 13:09:28 5: RHASSPY: [RhasspyTK] Parse (IO: Mqtt.Rhasspy): Msg: hermes/intent/de.fhem_SetNumeric => {"input": "die Licht schreibtisch auf 50 percent", "intent": {"intentName": "de.fhem:SetNumeric", "confidenceScore": 1.0}, "siteId": "wohnzimmer", "id": null, "slots": [{"entity": "de.fhem.Device", "value": {"kind": "Unknown", "value": "schreibtisch"}, "slotName": "Device", "rawValue": "schreibtisch", "confidence": 1.0, "range": {"start": 10, "end": 22, "rawStart": 10, "rawEnd": 22}}, {"entity": "rhasspy/number", "value": {"kind": "Number", "value": 50}, "slotName": "Value", "rawValue": "fünfzig", "confidence": 1.0, "range": {"start": 27, "end": 29, "rawStart": 27, "rawEnd": 34}}, {"entity": "Unit", "value": {"kind": "Unknown", "value": "percent"}, "slotName": "Unit", "rawValue": "prozent", "confidence": 1.0, "range": {"start": 30, "end": 37, "rawStart": 35, "rawEnd": 42}}], "sessionId": "wohnzimmer-bumblebee_raspberry-pi-6ed673af-e988-4056-9525-75132ac2449f", "customData": "bumblebee_raspberry-pi", "asrTokens": [[{"value": "die", "confidence": 1.0, "rangeStart": 0, "rangeEnd": 3, "time": null}, {"value": "Licht", "confidence": 1.0, "rangeStart": 4, "rangeEnd": 9, "time": null}, {"value": "schreibtisch", "confidence": 1.0, "rangeStart": 10, "rangeEnd": 22, "time": null}, {"value": "auf", "confidence": 1.0, "rangeStart": 23, "rangeEnd": 26, "time": null}, {"value": "50", "confidence": 1.0, "rangeStart": 27, "rangeEnd": 29, "time": null}, {"value": "percent", "confidence": 1.0, "rangeStart": 30, "rangeEnd": 37, "time": null}]], "asrConfidence": 0.35006499999999996, "rawInput": "die licht schreibtisch auf fünfzig prozent", "wakewordId": "bumblebee_raspberry-pi", "lang": null}
2021.09.22 13:09:28 5: Parsed value: 50 for key: Value
2021.09.22 13:09:28 5: Parsed value: die licht schreibtisch auf fünfzig prozent for key: rawInput
2021.09.22 13:09:28 5: Parsed value: percent for key: Unit
2021.09.22 13:09:28 5: Parsed value: bumblebee_raspberry-pi for key: customData
2021.09.22 13:09:28 5: Parsed value: wohnzimmer for key: siteId
2021.09.22 13:09:28 5: Parsed value: SetNumeric for key: intent
2021.09.22 13:09:28 5: Parsed value: wohnzimmer-bumblebee_raspberry-pi-6ed673af-e988-4056-9525-75132ac2449f for key: sessionId
2021.09.22 13:09:28 5: Parsed value: schreibtisch for key: Device
2021.09.22 13:09:28 5: Parsed value: die Licht schreibtisch auf 50 percent for key: input
2021.09.22 13:09:28 5: Parsed value: 1 for key: probability
2021.09.22 13:09:28 5: handleIntentSetNumeric called
2021.09.22 13:09:28 5: room is identified using siteId as wohnzimmer
2021.09.22 13:09:28 5: Device selected (by hash, with room and name): Wz.Di.00_Dim
2021.09.22 13:09:28 1: PERL WARNING: Use of uninitialized value $change in hash element at ./FHEM/10_RHASSPY.pm line 3337.
2021.09.22 13:09:28 1: PERL WARNING: Use of uninitialized value in hash element at ./FHEM/10_RHASSPY.pm line 3337.
Undefined subroutine &RHASSPY::round called at ./FHEM/10_RHASSPY.pm line 3369


FHEM schmiert ab und startet neu...

Habe ich bei den letzten Änderungen etwas wichtiges verpasst? Ich weiß leider nicht mehr welches die letzte für mich
funktionierende Modul Version war.

Gruß Ziton
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 22 September 2021, 17:32:18
Ich hab Porcupine im Einsatz. Mit Porcupine als Wakeword. Auf diversen Raspberrys mit ReSpeaker 2MIC. Die Lösung für dein Problem war bei mir - so blöd das jetzt klingt - mit alsamixer den "Gain" zurück zu drehen. Das hat die Erkennung meiner Befehle wesentlich verbessert. Auf TV hört das Ding aber natürlich immer noch.

Bei mir wurde auch immer irgendwas ausgeführt. Meistens wurde ein Timer-Befehl verstanden. Ich hab dann meine Sentences so stark konkretisiert, dass es nicht mehr passiert. Speziell am Anfang des Satzes sollte etwas wirklich eindeutiges stehen. Hab ich zumindest das Gefühl.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 22 September 2021, 18:20:45
Hmm, alsamixer und Mobile App (bei mir), das klingt lustig...

Bzgl. "round": Das ist ein Bug, den ich wohl irgendwann unbemerkt eingebaut habe, als ich die ganzen "uses" einer Revision unterzogen habe, Danke für den Hinweis.

Die Funktion kommt eigentlich aus 99_Utils, und ist ... na ja...

Habe in der angehängten Version versucht, das zu fixen, kann eigentlich kaum schlechter laufen als die Versin von heute mittag (also wenn svn, dann bitte diese hier).

Sorry for inconvenience!

Nachtrag: Bei Prozent-Anweisungen crasht FHEM nicht mehr, ungetestet ist noch eine Stelle bei Abfragen. Dafür habe ich jetzt beim Rumtesten noch ein paar "uninitialized"-Warnings gesehen ::) ; als Merkposten für später:
2021.09.22 20:06:35 1: PERL WARNING: Use of uninitialized value $change in hash element at ./FHEM/10_RHASSPY.pm line 3342.
2021.09.22 20:06:35 1: PERL WARNING: Use of uninitialized value in hash element at ./FHEM/10_RHASSPY.pm line 3342.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 23 September 2021, 09:41:59
Ist im SVN und auf GitHub
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 25 September 2021, 10:14:11
Die Dialog-Geschichte inkl. Confirm und Cancel ist eine gute Sache. Derzeit sehe ich aber Grenzen bei Rhasspy selbst.
Das führt u.a. zur erwähnten "Stotterei", welche durch die IntentNotRecognized-Behandlung noch verstärkt wird.
Die negativen Aspekte können zwar teilweise kompensiert werden aber das sind dann nur (aufwendige) Notlösungen.
Ich hoffe, dass die Rhasspy-Entwicklung der Rhasspy-Community wieder mehr nach vorn, anstatt in die Breite geht.

Insgesamt ist die Implemetierung der aktuellen Rhasspy-Version in FHEM gut gelungen und funktioniert auch gut.
Gruß Jens
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 19 Oktober 2021, 15:49:58
Aus gegebenem Anlass ein kleines Zwischenupdate:
- verhindert den Absturz aus https://forum.fhem.de/index.php/topic,123439.0.html (https://forum.fhem.de/index.php/topic,123439.0.html), wenn man vorher keinen CLIENT fertig konfiguriert hat;
- etwas aufgeräumt, v.a. bei den "unsicher" und "für später"-Kommentaren
- kleine commandref-Änderungen.

Für bisherige Nutzer eher kein Anlass zum updaten, aber testen wäre natürlich trotzdem nett...

EDIT: Modulupdate ist im svn (contrib)
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 28 Oktober 2021, 16:48:35
...da sich bisher keiner beschwert hat...:
@drhirn: würdest du die letzte Fassung wieder einchecken?
(Dann würde die dann voraussichtlich im 6.1-Package landen).
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Raemsna am 21 November 2021, 16:41:51
Zitat von: Beta-User am 29 Juli 2021, 10:41:44

bzw. "lokal":
attr Sonos rhasspySpecials confirm: SetOnOff="wirklich $target $Value schalten?" SetScene

Hallo zusammen,

Verständnisfrage zur Bestätigung der Befehlsausführung...
Ich habe folgendes Setup:
- aktuellste 10_Rhasspy.pm aus Github
- aktuellstes language File rhasspy-de.cfg aus Github

bei meiner Wasserpumpe im Garten habe ich folgende Rhasspy spezifischen Attribute eingestellt. :


attr Garten_Wasserpumpe rhasspyMapping SetOnOff:cmdOn=on,cmdOff=off
attr Garten_Wasserpumpe rhasspyName Wasser
attr Garten_Wasserpumpe rhasspyRoom Garten
attr Garten_Wasserpumpe rhasspySpecials confirm: SetOnOff="wirklich $target $Value schalten?" SetScene


wenn ich über Rhasspy die Wasserpumpe anschalte, kommt auch die Abfrage, "wirklich Wasser anschalten"? Das ist gemäß Einstellung.

Allerdings weiß ich nicht, was die korrekte Antwort auf die Frage im Falle eines gewünschten Anschaltens ist.
Ich habe schon "on", "an", "ja" usw. versucht, es wird aber immer etwas "komplett anderes" erkannt, z.B. zuletzt "lösche im" wo ich beispielsweise Nein gesagt hat.

Ich stehe leider auf dem Schlauch und freue mich (mal wieder) sehr über eure Hilfe!

Vielen Dank für das tolle Modul!!
Liebe Grüße
Raemsna
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 21 November 2021, 16:53:12
Das, was in sentences.ini für ConfirmAction => OK hinterlegt ist.

Die "stotterei" etc.  ist noch ein "todo"....
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Raemsna am 21 November 2021, 17:01:21
Zitat von: Beta-User am 21 November 2021, 16:53:12
Das, was in sentences.ini für ConfirmAction => OK hinterlegt ist.

Die "stotterei" etc.  ist noch ein "todo"....

Vielen Dank (mal wieder) für die schnelle Hilfe. Ich wär nicht draufgekommen, wobei es total logisch ist... :/

Grüße
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 22 November 2021, 13:08:58
Zitat von: Raemsna am 21 November 2021, 17:01:21
Vielen Dank (mal wieder) für die schnelle Hilfe. Ich wär nicht draufgekommen, wobei es total logisch ist... :/
:) Logisch vielleicht, aber leider bisher nicht dokumentiert...

Zitat von: Raemsna am 21 November 2021, 16:41:51
Vielen Dank für das tolle Modul!!
Zitat von: JensS am 25 September 2021, 10:14:11Insgesamt ist die Implemetierung der aktuellen Rhasspy-Version in FHEM gut gelungen und funktioniert auch gut.
:) Ein fesses DANKE an euch für das nette feedback!

Nachdem bei RHASSPY grade wieder ein bißchen was los war, anbei mal wieder ein (eher kleines und noch ungetestetes) update, das einige der jüngst genannten Punkte aufgreift. Habe mal die Versionsnummer auf 0.5.0 gehoben, damit wir nicht wirklich irgendwann bei 0.4.99 ankommen, aber das soll nicht bedeuten, dass es was substantiell neues gäbe :P .

"Neuerungen":
- gassistant scheint mit "blinds" statt "blind" zu arbeiten (https://forum.fhem.de/index.php/topic,124240.msg1188444.html#msg1188444 (https://forum.fhem.de/index.php/topic,124240.msg1188444.html#msg1188444)). Daher gibt es jetzt eine Art "aliasing" für gDT "blinds" und "shutter". Das Vorgehen an sich ist generisch, man könnte das stressfrei auf ähnliche Fälle erweitern;
- da Gisbert unbedingt mit einem Rollladen starten wollte, ist mir aufgefallen, dass ein "stop"-Kommando doch auch ganz nett wäre. Könnte sein, dass es klappt, wenn der Rollladen so einen setter hat und man in "Change" für "stop" "cmdStop" übergibt ([de.fhem:SetNumeric] => ( halte | stoppe ) ( den | die ) $de.fhem.Device-blind{Device} [an] {Change:cmdStop}). Da ziemlich sicher meine Lamellen dann "falsch" stehen bleiben werden, gibt es auch noch einen weiteren Eintrag in den "specials" für venetian blinds... (Achtung: Status insgesamt ist komplett ungetestet ::) ).
- die default-devspec hängt jetzt davon ab, ob man "gDT" nutzt. Wenn ja, werden alle Devices erfasst, bei denen einer gesetzt ist...
- die commandref war vielleicht etwas missverständlich, was das mit der devspec angeht, ist aus gegebenem Anlass auch renoviert.

ZitatDie Dialog-Geschichte inkl. Confirm und Cancel ist eine gute Sache. Derzeit sehe ich aber Grenzen bei Rhasspy selbst.
[...]
Das führt u.a. zur erwähnten "Stotterei", welche durch die IntentNotRecognized-Behandlung noch verstärkt wird.
Da das nervig ist, habe ich mal versucht, diesen Teil wegzuschalten. Ebenfalls ungetestet, Wiedereinschalten müßte mit "experimental=1" in der DEF gehen.

Im Hinterkopf habe ich auch noch den pah'schen Ansatz, ggf. auf bestimmte WakeWords direkt Aktionen auszuführen. An sich dürfte sowas als reines "Input-Device" einfacher mit MQTT2_DEVICE abzufackel sein, aber andererseits könnte es hilfreich sein, z.B. für bestimmte siteId's dann beim Erkennen eines bestimmten WakeWords auch bestimmte Vorbereitungs-Aktivitäten zu entfalten (Lautstärke der Musik runter, damit der eigentliche Sprechtext besser erkannt werden kann oä.). Von daher schadet eine zusätzliche Option innerhalb des Moduls vermutlich nicht. (FHEM- oder Perl-Kommandos, RHASSPY-Name, wakeword und siteId als Parameter auflösbar?).
Meinungen: Gerne...

Viel Spaß beim Testen, CU

EDIT: Anhang entfernt, da waren ein paar Kleinigkeiten beim Testen, die erst ausgebügelt werden müssen. Update folgt...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 23 November 2021, 13:20:48
Gestern hatten sich leider (mind.) zwei kleinere Problemchen eingeschlichen bzgl. der default-devspec (wenn man was gesetzt hatte), und bei der Erstellung der "blind"-slots ::) . Sollte mit der angehängten Version wieder funktionieren.

Da mir das mit der hotword-Reaktion als Idee gefallen hat, gibt's jetzt ein neues Attribut "rhasspyHotwords" (siehe commandref, da ist auch die einfachere Form via DEF zu finden). Wer die subscriptions manuell gesetzt hat, muss diese um "hermes/hotword/+/detected" ergänzen, damit was beim Modul ankommt.

Viel Spaß!

EDIT: Modul nochmal getauscht. Funktional keine Unterschiede, aber die commandref im Bereich der "Musterdefinitionen" von M2C und RHASSPY erweitert.

EDIT2: Scheint zumindest zum großen Teil zu funktionieren.
Hier ein "stopCommand"-Beispiel für meine ZWave-FGR-222
attr Jalousie_Mitte rhasspySpecials venetianBlind:setter=positionSlat stopCommand="set Jalousie_Mitte positionSlat [Jalousie_Mitte:positionSlat]"
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: laberlaib am 24 November 2021, 09:08:24
Hallo,

ich glaube, es gibt einen Bug beim einlesen der SiteIds.
Es wird dabei über die API gegangen:
http://192.168.2.81:12101/api/profile?layers=profile

{
    "dialogue": {
        "satellite_site_ids": "sat1,handylaib",
        "system": "rhasspy"
    },
    "intent": {
        "satellite_site_ids": "sat1,handylaib",
        "system": "fsticuffs"
    },
    "mqtt": {
        "site_id": "masterde"
    },
    "speech_to_text": {
        "satellite_site_ids": "sat1,handylaib",
        "system": "kaldi"
    },
    "text_to_speech": {
        "satellite_site_ids": "sat1,handylaib",
        "system": "nanotts"
    }
}


Aber lt. Rhasspydoku braucht man bei Master-Satellite-Aufbau keinen Dialoguemanager beim Master:
https://rhasspy.readthedocs.io/en/latest/tutorials/#server-with-satellites
(siehe Bild in der Anlage).

Mein per app angebundenes Handy (handylaib) war daher nicht auffindbar, trotz update slots. Erst nach dem ich einmal Dialogue Managerment an und konfiguriert hatte, war das der Fall.

Obs Auswirkungen hat(te)? Keine Ahnung. Bei mir hängt gerade unabhängig von der Eingabe (per Text direkt auf dem master oder auf der Handyapp) die Info am MQTT2-Device und kommt nicht weiter. Da muss ich noch mal reingucken.
Edit: Die IP des Masters hatte sich geändert und ich hatte diese sowohl im MQTT2-Device als auch im RHASSPY-Device geändert und letzteres auch durch einen reload 10_RHASSPY neu gestartet. Jetzt einen kompletten FHEM restart mal gemacht und es klappt. Im log hatte ich beim MQTT2-Dvice mit verbose 5 die Meldungen, dass was ankommt, drum habe ich das nicht regeloaded. Egal, klappt.
Merke: an irgendeiner Konfig mit vielen Abhängigkeiten rumspielen => Restart FHEM :p

laberlaib

Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 24 November 2021, 09:33:29
Hmm, bin im Moment auch überfragt, ob/welche Auswirkungen das hat und wie man es ggf. "besser" machen kann.
Theoretisch könnte man alle Ober-Keys durchgehen, um dann die Werte in den "satellite_site_ids" nacheinander durchzugehen und ggf. zu ergänzen, was fehlt.

Allerdings habe ich jetzt beim schnellen Überfliegen des Codes keine Stelle gefunden von der ich annehmen würde, dass das irgendwelche Auswirkungen hat. Vermutlich übersehe ich was.

@drhirn: Deine Meinung?

Zitatdie Info am MQTT2-Device
verstehe ich nicht bzw. meine Glaskugel meint, clientOrder am MQTT2_CLIENT wäre eventuell nicht/falsch gesetzt?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: laberlaib am 24 November 2021, 10:39:33
Zitat von: Beta-User am 24 November 2021, 09:33:29
verstehe ich nicht bzw. meine Glaskugel meint, clientOrder am MQTT2_CLIENT wäre eventuell nicht/falsch gesetzt?
Nope, war eingestellt. Hatte auch "früher" funktioniert - erst nach dem ich die IP geändert hatte, da ich meinen Master ins mein offizielles IP-Schema gepresst hatte, wars aus mit der Herrlichkeit.
Aber ist egal, Ihr schreibt das ja auch in der Anleitung, dass das Effekte haben kann und mein Bugreport diesbezüglich ist ja auch... unbrauchbar, sagen wirs direkt. :)
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 24 November 2021, 10:55:45
Zitat von: laberlaib am 24 November 2021, 10:39:33
Nope, war eingestellt. Hatte auch "früher" funktioniert - erst nach dem ich die IP geändert hatte, da ich meinen Master ins mein offizielles IP-Schema gepresst hatte, wars aus mit der Herrlichkeit.
Hatte neulich auch so einen ähnlichen Effekt, scheinbar liest M2C das Attribut nicht, wenn man die DEF ändert. Ein Neustart hatte das dann behoben, vielleicht hilft das bei dir auch (bzw. einfach das Attribut nochmal setzen, und eine "fake-Änderung" einbauen (zusätzliches Leerzeichen)).

ZitatAber ist egal, Ihr schreibt das ja auch in der Anleitung, dass das Effekte haben kann und mein Bugreport diesbezüglich ist ja auch... unbrauchbar, sagen wirs direkt. :)
Na ja, hier jedenfalls zum Testen ein Vorschlag für das "siteIds-Problem" (Abschnitt ab Zeile 2739):
    elsif ( $url =~ m{api/profile}ix ) {
        my $ref;
        if ( !eval { $ref = decode_json($data) ; 1 } ) {
            readingsEndUpdate($hash, 1);
            return Log3($hash->{NAME}, 1, "JSON decoding error: $@");
        }
        my $siteIds;
        for (keys %{$ref}) {
            next if !defined $ref->{$_}{satellite_site_ids};
            if ($siteIds) {
                $siteIds .= ',' . encode($cp,$ref->{$_}{satellite_site_ids});
            } else {
                $siteIds = encode($cp,$ref->{$_}{satellite_site_ids});
            }
        }
        my @ids = uniq(split q{,},$siteIds);
        readingsBulkUpdate($hash, 'siteIds', join q{,}, @ids);
    }
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: laberlaib am 24 November 2021, 11:20:32
Danke.
wenn ich das Handy meiner Frau "anschließe" werde ichs mal auf diese Weise probieren.
Stichwort Handy der Frau:

Ich habe jetzt ein rhasspy-es.cfg quasi fertig. 4-5 neu hinzugekommene Sätze muss ich noch mal nachfragen/verifizieren.
https://github.com/laberlaib/fhem-rasspy-some-data
Ein paar Fragen dazu:

1) Hätte ich jetzt meine alte spanische Sprachdatei nicht überarbeitet, dann hätten da Sätze gefehlt. Hätte das was ausgemacht oder ist auch für die eine Englische Fallbackdatei sowieso immer implementiert? Dies ist so nur für "commaconversion", "units" und "mutated_vowels" angegeben.
2) "User" ist klar; heißt das aber auch, dass bei einem FHEM-Update-Befehl (hinterlegte controls für 10_RHASSPY vorausgesetzt) die rhasspy-de.cfg auch nicht aktualisiert wird und man das händisch machen muss?
3) slots: Hier werden derzeit Farbbezeichnungen in HEX-Werte "übersetzt". D.h. ich müsste für ein komplettes File auch die Bezeichnungen ins spanische übersetzen (von einer Farbtabelle abschreiben)?
Ist das auch der Ort, wo ich eigenen Slots einbringen kann oder gibt es dafür eine andere Funktion?

ich würde dann einfach ein weiteres RHASSPY-DEVICE mit language=es fhemId=fhemEs prefix=rhasspyEs anlegen, attr <rhasspy> configFile ./FHEM/rhasspy-es.cfg setzen und ab die Post.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 24 November 2021, 11:43:27
Zitat von: laberlaib am 24 November 2021, 11:20:32
1) Hätte ich jetzt meine alte spanische Sprachdatei nicht überarbeitet, dann hätten da Sätze gefehlt. Hätte das was ausgemacht oder ist auch für die eine Englische Fallbackdatei sowieso immer implementiert? Dies ist so nur für "commaconversion", "units" und "mutated_vowels" angegeben.
Englisch-Default ist direkt im Modul enthalten. Prinzipiell kann man nur Sätze modifizieren, die das Modul aus dieser "Grundstruktur" "kennt". Als Erweiterungen zugelassen sind nur einige weitere Elemente, darunter eben diese "Farbe-zu-Nummer"-Geschichte, die dann direkt dazu genutzt werden kann, Rhasspy-Slots zu generieren.

Die in contrib enthaltene de-Fassung sollte ein paar Erläuterungen dazu enthalten.

Der prinzipielle Mechanismus für die eigentlichen Sätze ist der: Was zugelassen ist, steht in englisch im Modul. Da sind auch die zugelassenen Variablen zu finden. Dann wird "drübergeklatscht", was in der Sprachdatei in "default" zu finden ist, und zuletzt der "user"-Bereich nochmal drübergegelegt. Ergo bleiben die englischen Werte sichtbar, wenn man irgendwo eine Lücke hat und kann dann das gezielt nacharbeiten. Super wäre es, für "es" auch eine vollständige "neutrale" Fassung in "default" zu haben und eine (teilweise) "individualisierte" Ergänzung in "user".

Zitat
2) "User" ist klar; heißt das aber auch, dass bei einem FHEM-Update-Befehl (hinterlegte controls für 10_RHASSPY vorausgesetzt) die rhasspy-de.cfg auch nicht aktualisiert wird und man das händisch machen muss?
Da im Moment alles in contrib liegt, wird so oder so nichts per update aktualisiert. Für die Sprachdatei fände ich einen automatischen update auch extrem schwierig, weil da in der Regel eben auch User-Daten drin stehen. Stellt man fest, dass irgendwo was fehlt (weil die engl. Sätze drin bleiben), kann man (für "de") den "default"-Teil einfach aus dem svn rauskopieren.
(Das ist der tiefere Sinn hinter der Aufteilung an sich).

Zitat
3) slots: Hier werden derzeit Farbbezeichnungen in HEX-Werte "übersetzt". D.h. ich müsste für ein komplettes File auch die Bezeichnungen ins spanische übersetzen (von einer Farbtabelle abschreiben)?
Ist das auch der Ort, wo ich eigenen Slots einbringen kann oder gibt es dafür eine andere Funktion?
Ja, das ist einer der Orte dafür (shortcuts gibt es z.B. auch noch, und uU. bei "specials"/scene (?), und einen setter), und ja, wenn du spanische Farben sagen können willst, wäre das m.E. der richtige Ort dafür.

Zitatich würde dann einfach ein weiteres RHASSPY-DEVICE mit language=es fhemId=fhemEs prefix=rhasspyEs anlegen, attr <rhasspy> configFile ./FHEM/rhasspy-es.cfg setzen und ab die Post.
So wäre die Theorie :) .

Bin mal gespannt, ob das alles so klappt oder wir nicht irgendwo das eine oder andere weitere Problem finden. Prinzipiell fände ich es übrigens nicht schlecht, für "RHASSPY spricht spanisch" einen separaten Thread zu haben.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 24 November 2021, 11:43:37
Zitat von: laberlaib am 24 November 2021, 09:08:24
Aber lt. Rhasspydoku braucht man bei Master-Satellite-Aufbau keinen Dialoguemanager beim Master:
https://rhasspy.readthedocs.io/en/latest/tutorials/#server-with-satellites
(siehe Bild in der Anlage).

Witzig. Ich hab's aus irgendeinem Grund genau umgekehrt konfiguriert. DialogueManager an der Base aktiv, am Satellit nicht. Was erklärt, warum Dialoge bei mir nicht funktioniert haben ;D

Unabhängig davon - laberlaib hat's inzwischen selbst beantwortet - seh ich darin auch kein Grund für das Verhalten.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 25 November 2021, 12:47:55
Hallo zusammen,

mal wieder ein paar "Kleinigkeiten"...:

Zitat von: Beta-User am 25 November 2021, 07:24:48
Alles, was an diese RHASSPY-Instanz gehen soll, braucht "de.fhem:" vorneweg. In der sentences.ini muss der Intent also so benannt werden:
[de.fhem:GetTime]

=> Doku/commandref zu den intents ergänzt

ZitatIn den "keywords" [...] manches von vornherein keinen Sinn macht (room: googleassistant),
=> neuer "tweak" "ignoreKeywords"
(Status: scheint zu funktionieren)

EDIT: der Code aus https://forum.fhem.de/index.php/topic,119447.msg1188968.html#msg1188968 (https://forum.fhem.de/index.php/topic,119447.msg1188968.html#msg1188968) betr. die siteId-Ermittlung ist auch übernommen. Scheint soweit zu klappen...

Zitat von: Beta-User am 25 November 2021, 09:03:21
RHASSPY vielleicht um eine Funktion für text2intent zu erweitern? Mal sehen...
Erste Ansätze dazu sind drin. Weiß im Moment weder, ob das überhaupt in der Praxis funktioniert (lt. Doku sollte es), noch, ob es sinnvoll ist, die siteId mitgeben zu können (das erste Wort wird als siteId interpretiert, der Rest gibt den Text).

Na ja, jedenfalls könnte man jetzt z.B. was via Telegram oä. an FHEM senden, einen Eventhandler hernehmen, der die Message auswertet und an RHASSPY weitergibt und dann hoffen, dass das Ergebnis paßt... (Status an der Stelle ausdrücklich experimentell, für den Normalbetrieb aber hoffentlich erst mal irrelevant)

Außerdem gibt es noch ein paar mehr gDT's, die grundsätzlich berücksichtigt werden könnten, aber ob das im Detail dann klappt, wird sich auch zeigen => ebenfalls eher experimentell, aber vermutlich auch für den Normalbetrieb unkritisch...

Generell scheint mir, dass bei der gDT-Auswertung noch etwas Nacharbeitsbedarf bestehen könnte in Richtung auf onCmd=ON usw.. Ziehe ich ggf. nach, wenn Gisbert seine getAllSets() gezeigt hat.

Wie üblich: Viel Spaß beim Testen, bin mal auf eure Rückmeldungen zu den bisherigen Neuerungen in 0.5 gespannt :) . Bisher war es verdächtig ruhig (=> braucht keiner, hat keiner getestet, ...?)

CU
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: laberlaib am 25 November 2021, 18:12:49
Zitat von: Beta-User am 24 November 2021, 11:43:27
Bin mal gespannt, ob das alles so klappt oder wir nicht irgendwo das eine oder andere weitere Problem finden. Prinzipiell fände ich es übrigens nicht schlecht, für "RHASSPY spricht spanisch" einen separaten Thread zu haben.

Ich bin dran - die handyapp enciendet die lampara schon und danach wird die Stehlampe wieder ausgeschalten.
Probleme hatte ich mit dem Attribut clientOrder vom MQTT-Device: Da wurde mir mal gesagt, dass das nur ein MQTT Device braucht und das dasnn für alle gilt. Aber ohne das hatte ich im mqtt2_rhasspy_es unter Interals/Clients nur Clients ":MQTT_GENERIC_BRIDGE:MQTT2_DEVICE:" stehen.
Aber sonst siehts gut aus, und dank Proxmox-VM-Master ist das ja auch echt schnell aufgesetzt.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 26 November 2021, 16:25:59
...und noch ein (funktional gesehen) Mini-update.

Interessanter dürften die Erweiterungen in der commandref sein, zusammen mit
Zitat von: Beta-User am 26 November 2021, 13:42:55
Unter https://wiki.fhem.de/wiki/Rhasspy (https://wiki.fhem.de/wiki/Rhasspy) habe ich jetzt mal einen "Quick-Start" ins Wiki gestellt.
sollte es jetzt einfacher sein, RHASSPY einzurichten, ohne erst gefühlte 1000 Seiten Entwicklungsthread zu lesen....

(bzgl. der Github-Seite hatte Gisbert einen Typo gemeldet, und zwischenzeitlich bin ich nicht sicher, wie man bzgl. des Doku-Themas sinnvollerweise weiter macht...)
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 27 November 2021, 08:12:33
Zitat von: Beta-User am 26 November 2021, 16:25:59
(bzgl. der Github-Seite hatte Gisbert einen Typo gemeldet, und zwischenzeitlich bin ich nicht sicher, wie man bzgl. des Doku-Themas sinnvollerweise weiter macht...)

Tja. Wir sind jetzt auf jeden Fall da, wo ich eigentlich nicht hinwollte: Ich muss drei Dokumentationen im Auge behalten.

Das mit dem Typo auf GitHub hab ich übersehen. Was war das?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 27 November 2021, 08:27:15
Zitat von: Gisbert am 26 November 2021, 07:30:32
Hinweis: Github hat einen kleinen Fehler, ")" statt "}", hinter on.

Generell stimme ich dir zu, dass 3 Dokus nicht optimal sind. Daher habe ich bisher den Wiki-Teil auch auf das "Starten mit genericDeviceType" beschränkt. MAn. brauchte es sowas, mir ist aber im Prinzip auch egal, wo es steht. Man könnte die Kurzformel auch in die commandref aufnehmen. Das Problem sind m.E. allerdings Beispielsätze, die sind immer sprachspezifisch, was eben nach einer (kurzen) de-Doku ruft...
Vielleicht sollten wir mal telefonieren (oder wie man das neuerdings halt so macht), wie wir insgesamt weiter vorgehen wollen?

Anbei auch noch ein kleines svg. Noch nicht 100% hübsch, aber vielleicht mag es ja jemand mit einem hübscheren Rahmen versehen...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 27 November 2021, 08:49:22
Zitat von: Beta-User am 27 November 2021, 08:27:15Das Problem sind m.E. allerdings Beispielsätze, die sind immer sprachspezifisch, was eben nach einer (kurzen) de-Doku ruft...

Ja. Hab eh immer gesagt, Technische-Doku bleibt, wo sie ist (CRef, GitHub). Und Beispiele sollen ins Wiki ;D
Muss aber auch gestehen, GitHub hängt schwer hinten nach. Was einfach daran liegt, dass ich das meiste, was in letzter Zeit von euch dazu gebaut wurde, mangels Anwendungszweck nicht so richtig testen kann.


Zitat von: Beta-User am 27 November 2021, 08:27:15Vielleicht sollten wir mal telefonieren (oder wie man das neuerdings halt so macht), wie wir insgesamt weiter vorgehen wollen?
Im Sinne der Transparenz wäre ich fast dafür, dass wir das im Forum irgendwo abhandeln. Damit Interessierte auch daran teilhaben können.

Zitat von: Beta-User am 27 November 2021, 08:27:15Anbei auch noch ein kleines svg. Noch nicht 100% hübsch, aber vielleicht mag es ja jemand mit einem hübscheren Rahmen versehen...
Für's Wiki?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 27 November 2021, 09:23:18
Zitat von: drhirn am 27 November 2021, 08:49:22
Für's Wiki?
Na ja, ich nutze das in FHEMWEB, wäre also mittelfristig eher was für den "icons"-Thread bzw. "contrib"-Material?

Zitat von: drhirn am 27 November 2021, 08:49:22
Ja. Hab eh immer gesagt, Technische-Doku bleibt, wo sie ist (CRef, GitHub). Und Beispiele sollen ins Wiki ;D
Muss aber auch gestehen, GitHub hängt schwer hinten nach. Was einfach daran liegt, dass ich das meiste, was in letzter Zeit von euch dazu gebaut wurde, mangels Anwendungszweck nicht so richtig testen kann.
...mein erster Blick ging auch nach github, und da war dann auch mein Reflex: Ups, da wäre "action required", und das ist in der Tat eher "Beispiel"...

Die meisten neuen Sachen sind im Prinzip zumindest von mir angetestet, manches ist noch nicht ausgereift (text2rhasspy)

Zitat
Im Sinne der Transparenz wäre ich fast dafür, dass wir das im Forum irgendwo abhandeln. Damit Interessierte auch daran teilhaben können.
Kein Problem. Ich wollte nur anfragen, ob zum einen Interesse besteht, dass ich die Co-Maintainerschaft offiziell übernehme, und zum anderen, was du mit Rudi besprochen hattest betr. der Frage, contrib vs. FHEM?

Zum ersten Punkt: War ja lange nicht sicher, ob ich bei Rhasspy bleibe, aber im Moment stellt sich die Frage nicht mehr 8) . Jetzt hat sich gezeigt, dass Bedarf im Feinschliff für die besteht, die die Entwicklungsdiskussion nicht aktiv begleitet hatten. Dir daher die Verantwortung auf's Auge zu drücken für features, die du nicht (aktiv) nutzt bzw. nicht brauchst, ist daher diskussionswürdig ;) ...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 27 November 2021, 09:31:03
Wer eine vernünftige Offline-Spracherkennung/-steuerung implementieren möchte, kommt um Rhasspy nicht herum.
Bisher gab es keinen Einstieg für Suchende; Rhasspy wurde eher durch Zufall gefunden. Dass ist jetzt mit der Verlinkung im WIKI korrigieret. Danke dafür!
Selbst nutze ich die automatische Generierung per gDT nicht, da meine paar Devices per Hand definiert wurden.
Zum Einstieg in Rhasspy wäre ein Beispiel mit einem M2C-Device, einem Rhasspy-Device und einem Dummy-setOnOff ausreichend.
Alles weitere würde zu Beginn mehr Fragen aufwerfen, als Verständnis zum Konstrukt von Rhasspy zu vermitteln.

Gruß Jens
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 27 November 2021, 10:00:48
Zitat von: Beta-User am 27 November 2021, 09:23:18
Ich wollte nur anfragen, ob zum einen Interesse besteht, dass ich die Co-Maintainerschaft offiziell übernehme, und zum anderen, was du mit Rudi besprochen hattest betr. der Frage, contrib vs. FHEM?

Auf jeden Fall! Wenn wir uns ehrlich sind, bist du der Maintainer, nicht ich. Meine letzte Zeile Code ist schon ziemlich lange her ;)
Mit Rudi habe ich eigentlich nur bzgl. contrib gesprochen. Ich würd's dabei belassen, bis die Userschaft wächst. Aber ich bin da meinungselastisch.

Zitat von: Beta-User am 27 November 2021, 09:23:18Dir daher die Verantwortung auf's Auge zu drücken für features, die du nicht (aktiv) nutzt bzw. nicht brauchst, ist daher diskussionswürdig ;)

Fair :D
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 27 November 2021, 10:07:24
Zitat von: JensS am 27 November 2021, 09:31:03Zum Einstieg in Rhasspy wäre ein Beispiel mit einem M2C-Device, einem Rhasspy-Device und einem Dummy-setOnOff ausreichend.
Alles weitere würde zu Beginn mehr Fragen aufwerfen, als Verständnis zum Konstrukt von Rhasspy zu vermitteln.

Wiederum: Ich sehe das wertfrei. Das ist nicht "mein" Modul, es ist nicht "meine" Doku. Alles, was Rhasspy und das Modul weiterbringt, freut mich. Insofern bin ich begeistert über jeden Input. Ich ermutige euch auch, selbst Hand anzulegen. Sei das Modul oder Doku. Sei das mit einem Patch für SVN oder einen Pull Request für GitHub. Ich hab das ganze nur gestartet, aber ich bin nicht beleidigt, wenn das jemand besser macht. Bin auch nicht der Meinung, ich hab die Weisheit mit Löffeln gefressen. In Wahrheit habt ihr mich alle wissenstechnisch schon lange überholt ;).
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 27 November 2021, 10:27:12
Zitat von: drhirn am 27 November 2021, 10:07:24
Ich hab das ganze nur gestartet...
Dafür ein dickes Lob und einen großen Dank!!!
Ich glaube es an einer anderen Stelle schon mal geschrieben zu haben - ohne diesen Start wäre das Snpis-Modul von Thyraz gestorben und keine vernünftige Alternative vorhanden.

Gruß Jens
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: laberlaib am 27 November 2021, 10:36:25
Sagt mal, woher weiß ich den, welche Befehle so ein genericDeviceTyp unterstützt?
Ich hab hier eine Zigbee-Birne die ich mir mla mit einem Template folgendermaßen eingerichtet habe:
defmod light_Stehlampe MQTT2_DEVICE zigbee_0xec1bbdfffe181343
attr light_Stehlampe IODev MQTT2_FHEM_Server
attr light_Stehlampe comment Licht nicht schlecht: F0F6FE\
FFC248
attr light_Stehlampe devStateIcon {zigbee2mqtt_devStateIcon255($name)}
attr light_Stehlampe genericDeviceType light
attr light_Stehlampe group dev_light
attr light_Stehlampe icon hue_filled_white_and_color_e27_b22
attr light_Stehlampe imageLink /fhem/deviceimages/mqtt2/LED1624G9.jpg
attr light_Stehlampe model zigbee2mqtt_light_rgb_hex
attr light_Stehlampe readingList zigbee2mqtt/0xec1bbdfffe181343:.* { json2nameValue($EVENT) }
attr light_Stehlampe rhasspy1Name Stehlampe
attr light_Stehlampe rhasspy1Room wohnzimmer
attr light_Stehlampe rhasspyEsName lampara
attr light_Stehlampe rhasspyEsRoom salon
attr light_Stehlampe room LIGHTER,Rhasspy
attr light_Stehlampe setList on:noArg zigbee2mqtt/0xec1bbdfffe181343/set {"state":"ON"}\
  off:noArg zigbee2mqtt/0xec1bbdfffe181343/set {"state":"OFF"}\
  brightness:colorpicker,BRI,0,5,255 zigbee2mqtt/0xec1bbdfffe181343/set {"state":"on","$EVTPART0":"$EVTPART1"}\
  hex:colorpicker,HEX,0,15,255 zigbee2mqtt/0xec1bbdfffe181343/set {"color":{"$EVTPART0":"#$EVTPART1"}}
attr light_Stehlampe stateFormat {lc ReadingsVal($name,"state",0)}
attr light_Stehlampe userReadings hex:color_y.* {Color::xyY2hex(ReadingsVal($name,"color_x",0),ReadingsVal($name,"color_y",0),ReadingsVal($name,"brightness",254))}
attr light_Stehlampe webCmd toggle:on:off:brightness:hex


Reicht dazu das gDT "light" aus?
Und dann würde ja weiter gehen mit blinds etc..

Zur Doku:
Ich finde, dass Github und Wiki im Grunde das gleiche sein könnten. Und das Wiki können halt alle editieren, bei Github tu zumindest ich mich schwerer.
Das Modul ist so speziell, dass es ja von niemandem isoliert ohne FHEM betrieben werden kann und daher auch keine für sich stehende Doku auf Github braucht.
Und die Commandref ist nochmal weniger von Helfern zu pflegen, daher würde ich hier nur kurz und einsprachig (Englisch, wegen der FHEM-Richtlinien) erläutern, um was es geht.


Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 27 November 2021, 10:56:50
Zitat von: drhirn am 27 November 2021, 10:00:48
Auf jeden Fall!
OK, dann schaue ich mal, dass ich 0.5.03 ins svn/contrib schubse...

Und ohne speziell die Initiative von drhirn und euren support isgesamt (und manche kritische Rückfrage) wären wir ganz sicher nicht dahin gekommen, dass ca. 80% des Codes überarbeitet wurden und der ganz überwiegende Teil automatisch geht.

Was die gDT angeht, dürfte das "hex"-light zu 2/3 funktionieren, nämlich on/off und brightness. hex geht vermutlich nicht, wobei ich mich frage, ob man das nicht (im M2D) nach "rgb" ändern könnte, dann wären es 100%. Was geht, sieht man im RHASSPY-list ;) . Bräuchte aber Info, was im Reading hex für Werte stehen (ob mit oder ohne #), sonst muss ich Code schauen...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 27 November 2021, 11:31:33
Zitat von: Beta-User am 27 November 2021, 10:56:50
OK, dann schaue ich mal, dass ich 0.5.03 ins svn/contrib schubse...

Hab ich am Morgen schon gemacht
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Prof. Dr. Peter Henning am 28 November 2021, 17:05:08
Bin hier ab sofort mit dabei.

LG

pah
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 29 November 2021, 07:17:11
Zitat von: Prof. Dr. Peter Henning am 28 November 2021, 17:05:08
Bin hier ab sofort mit dabei.
:) Dann mal willkommen in unserer trauten Runde hier!
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 29 November 2021, 09:20:29
Zitat von: laberlaib am 27 November 2021, 10:36:25
Sagt mal, woher weiß ich den, welche Befehle so ein genericDeviceTyp unterstützt?

Das ist derzeit leider nur aus dem Code ersichtlich (sub _analyze_genDevType).
Für "light" ist das SetOnOff, GetOnOff und SetNumeric. Wobei bei letzterem brightness gesetzt wird. Und das ist - je nach Gerät - dim, pct oder brightness.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 29 November 2021, 10:03:01
Zitat von: Beta-User am 27 November 2021, 08:27:15
Anbei auch noch ein kleines svg. Noch nicht 100% hübsch, aber vielleicht mag es ja jemand mit einem hübscheren Rahmen versehen...

Mir gefällt's überhaupt ohne Rahmen am besten: https://github.com/fhem/fhem-rhasspy/blob/main/extras/rhasspy.svg
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 29 November 2021, 10:26:39
Zitat von: drhirn am 29 November 2021, 09:20:29
Das ist derzeit leider nur aus dem Code ersichtlich (sub _analyze_genDevType).
Für "light" ist das SetOnOff, GetOnOff und SetNumeric. Wobei bei letzterem brightness gesetzt wird. Und das ist - je nach Gerät - dim, pct oder brightness.
Es fehlt: SetColor. Und ein Blick in den Code zeigt: hex wird automatisch als rgb behandelt. Das müßte mAn. daher also bei diesem Gerät direkt mit dem gDT light klappen.

Grundsätzlich zu dem Thema: einfach den (vermutlich) passenden gDT setzen und dann schauen, was der analyzer daraus macht => RHASSPY-list. Wenn es nicht gefällt oder zu 100% paßt, hat man schon mal eine Grundlage, die man dann "nur noch" anpassen muss...

Zitat von: laberlaib am 27 November 2021, 10:36:25
Und die Commandref ist nochmal weniger von Helfern zu pflegen, daher würde ich hier nur kurz und einsprachig (Englisch, wegen der FHEM-Richtlinien) erläutern, um was es geht.
Prinzipiell fände ich es gut, wenn die (engl.) commandref alles enthalten würde, was man braucht. Dazu fehlen mind. noch ein paar Beispielsätze, und evtl. auch sowas wie eine Kurzfassung des Quick-Starts. Es ist aber völlig ok, wenn jemand dazu (und nicht nur zu den genannten Punkten) content-Vorschläge liefert oder bessere Formulierungen etc. vorschlägt usw.. Ich habe das bisher eher als schnellen "write-up" genutzt, in dem dann eben auch neue features etc. direkt dokumentiert wurden. Da besteht sicher noch Verbesserungspotential ;) .

Zitat von: drhirn am 29 November 2021, 10:03:01
Mir gefällt's überhaupt ohne Rahmen am besten: https://github.com/fhem/fhem-rhasspy/blob/main/extras/rhasspy.svg (https://github.com/fhem/fhem-rhasspy/blob/main/extras/rhasspy.svg)
Finde ich gut. Wie wäre es mit einem Eincheck-Vorschlag an wuppi68?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 29 November 2021, 10:41:16
Zitat von: Beta-User am 29 November 2021, 10:26:39
Grundsätzlich zu dem Thema: einfach den (vermutlich) passenden gDT setzen und dann schauen, was der analyzer daraus macht => RHASSPY-list.

Ich glaub, wir sollten's trotzdem irgendwann irgendwo dokumentieren ;).

Zitat von: Beta-User am 29 November 2021, 10:26:39
Finde ich gut. Wie wäre es mit einem Eincheck-Vorschlag an wuppi68?

Antrag ist gestellt
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 29 November 2021, 10:56:25
Zitat von: Beta-User am 23 November 2021, 13:20:48
Da mir das mit der hotword-Reaktion als Idee gefallen hat, gibt's jetzt ein neues Attribut "rhasspyHotwords" (siehe commandref, da ist auch die einfachere Form via DEF zu finden). Wer die subscriptions manuell gesetzt hat, muss diese um "hermes/hotword/+/detected" ergänzen, damit was beim Modul ankommt.

Ich hab gerade folgende DEF:
baseUrl=http://rhasspy:12101 defaultRoom=wohnzimmer language=de devspec=room=Rhasspy handleHotword

Stimmt das mit dem handleHotword so? Weil, ich bekomm da kein Reading. Erst, wenn ich das Attribut entsprechend setze.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 29 November 2021, 11:55:16
Zitat von: drhirn am 29 November 2021, 10:41:16
Ich glaub, wir sollten's trotzdem irgendwann irgendwo dokumentieren ;) .
Ja, Doku ist alles...

Bin allerdings eher skeptisch, ob man derartige "Selbstverständlichkeiten" wie das, was der gDT-Analyzer ermittelt, wirklich explizit dokumentieren sollte. Die User sollten mAn. lernen, sowas auszutesten und dann in die devicemap zu schauen, was RHASSPY daraus macht. Dann kann man bei Bedarf nachregeln, aber im Grundsatz sollten diese Dinge so sein, dass es einfach "funktioniert" und die User gar nicht groß nachdenken müssen. Das ganze ist ja auch so angelegt, dass ggf. an zentraler Stelle einfach eine Korrektur eingefügt werden kann, die dann für alle Betroffenen auch direkt wirksam wird.

Bei der Gelegenheit: Mir ist vorhin aufgefallen, dass z.B. gar nicht dokumentiert gewesen war, dass es einen "Specials"-Key namens "colorTempMap" gibt. (Ich hoffe nur, dass der auch funktioniert... ::) )

Da wir derartige "Specials" schon an der einen oder anderen Stelle haben, habe ich die Anregung von Gisbert jetzt mal so umgesetzt, dass es ein generisches "Special" gibt, mit dem man beliebige Werte (in Value) an den SetNumeric(Group)-Intenthandler übergeben kann, und den dann nur für das Zieldevice ummappt. So kann z.B. auch eine Mischung zwischen "Gisbert-TYPE" und "CUL_HM/ZWave-TYPE"-Rollläden sauber und einheitlich angesteuert werden, und auch Somfy-Typen müßten sich zwanglos überreden lassen, in "myPosition" zu fahren:
attr RollladenSchlafzimmer1 rhasspyMapping SetOnOff:cmdOn=DriveUp,cmdOff=DriveDown\
SetNumeric:cmdStop=Stop,type=setTarget,cmd=pct
attr RollladenSchlafzimmer1 rhasspySpecials numericValueMap:10='DriveSlit'


Status: Grob angetestet (einchecken dann, wenn Gisbert oder jemand anderes "paßt" ruft).

EDIT: man sollte die diffs immer erst nochmal durchsehen. Bitte den einen downloader, das nochmal auszutauschen, da war ein Kopier/Änder-Fehler drin!
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 29 November 2021, 13:12:14
Sorry, beim Testen sind mir jetzt noch ein paar "uninitialized"-Warnungen über den Weg gelaufen... Fix anbei.

EDIT: Modul ist im svn/contrib eingecheckt
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 29 November 2021, 18:24:27
So, diskutieren wir mal drüber, wie wir jetzt dokumentieren sollen? Ich bin bereit, die Doku auf GitHub und Englisch als Sprache aufzugeben. Hätte dafür aber gerne einen guten Plan, wie wir die Doku im Wiki strukturieren ;).
Sollen wir alles auf eine Wiki-Seite packen, oder machen wir mehrere? Sollen wir die CRef wirklich so ausführlich lassen, oder verschieben wir Teile davon ins Wiki? Oder sollen wir die CRef nochmal auf deutsch ins Wiki übernehmen? Sollen wir das hier diskutieren, oder in einem eigenen Beitrag?

Extrem cool wär ja, wenn man einfach EIN Markdown-File erstellen könnte, das dann automatisch in HTML für die Cref und Wiki-Markdown umgewandelt wird ;). Für die CRef hab ich sowas mal gesehen glaub ich. Für's Wiki halt leider nicht.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 30 November 2021, 11:27:58
Sorry, das hier hatte ich gestern nicht beantwortet:
Zitat von: drhirn am 29 November 2021, 10:56:25
Ich hab gerade folgende DEF:
baseUrl=http://rhasspy:12101 defaultRoom=wohnzimmer language=de devspec=room=Rhasspy handleHotword

Stimmt das mit dem handleHotword so? Weil, ich bekomm da kein Reading. Erst, wenn ich das Attribut entsprechend setze.
So sollte das auch ohne Attribut klappen.
baseUrl=http://rhasspy:12101 defaultRoom=wohnzimmer language=de devspec=room=Rhasspy handleHotword=1
Der Teil ist eigentlich auch schon in der commandref (define und Attribut) enthalten ;) .

Soweit ich das im Moment überblicken kann, fehlt in der commandref eigentlich nur das mit der neuen setter-Idee - da bin ich aber noch nicht dazu gekommen, irgendwas substantielles auszutesten => might be subject to changes...

Alles andere sollte zumindest als Stichwort (und jeweils - wo erforderlich - mit einem Mini-Beispiel-Schnipsel) in der commandref enthalten sein.

Zitat von: drhirn am 29 November 2021, 18:24:27
So, diskutieren wir mal drüber, wie wir jetzt dokumentieren sollen? [...] Sollen wir die CRef wirklich so ausführlich lassen, oder verschieben wir Teile davon ins Wiki?
Eine commandref sollte
1. es (global gedacht) ermöglichen, ein Modul in Betrieb nehmen zu können, ohne weitere Doku dazu zu brauchen;
2. alle Optionen enthalten/dokumentieren, die man im Modul (bzw. in den durch das Modul verteilten Attribute) einstellen kann;

Ad 1.: gefühlter Erfüllungsgrad: na ja, vielleicht grade so ::) . Ist in dem Fall aber so oder so schwierig, weil auch Konfiguration auf der Rhasspy-Seite erforderlich ist, und sich das wechselseitig bedingt. Daher ggf. die Überlegung, einen engl. Quickstart in die commandref zu packen. Wird dadurch halt noch länger... Die Frage ist dann höchstens, ob man dann auf eine ergänzende en-Doku irgendwo anders verzichten könnte

Ad 2.: gefühlter Erfüllungsgrad: m.E. eigentlich mehr als passabel. V.a. finde ich es gut und richtig, mehr oder weniger kurze Erläuterungen zu den rhasspy-Attributen direkt bei den Geräten zu sehen, selbst wenn die "Kurzfassung" bei "Specials" schon etwas lang ist...
Dies Teile sind aber eigentlich die, die die Gesamtlänge der commandref im Wesentlichen bedingen. Da würde ich ungern Abstriche machen wollen, manches braucht ggf. noch etwas Feinschliff, mir sind auch grade wieder ein paar Kleinigkeiten beim Drübersehen aufgefallen.

Zitat
Ich bin bereit, die Doku auf GitHub und Englisch als Sprache aufzugeben. Hätte dafür aber gerne einen guten Plan, wie wir die Doku im Wiki strukturieren ;) .
An Github hing ich ja noch nie ::) , und für den allgemeinen Fahrplan bzgl. english sollte man vermutlich vorab klären, wie viel/was und wie in die commandref soll. Zumindest wesentliche Teile zu def/set/attr sind im Moment gedoppelt, der derzeitige Mehrwert der dortigen Doku sind die hinteren Teile ab #intents.
Nach meinem jetzigen Bauchgefühl würde es Sinn machen, den (noch zu übersetzenden) Quickstart und diesen hinteren Teil als Rhasspy/en ins Wiki zu übernehmen? (Und aus der commandref dann dahin zu verlinken).


Zitat
Sollen wir alles auf eine Wiki-Seite packen, oder machen wir mehrere? [...] Oder sollen wir die CRef nochmal auf deutsch ins Wiki übernehmen? Sollen wir das hier diskutieren, oder in einem eigenen Beitrag?
Die erste Frage würde ich dann beantworten, wenn wir den Gesamtumfang sehen.
1:1 zu übersetzen finde ich nicht den großen Mehrwert, v.a. ist das Aufwand/Nutzen-Verhältnis m.E. nicht akzeptabel (schon klar, dass es einige User gibt, die sich mit englisch schwer tun, aber denen ist m.E. anders besser geholfen*).
Mittelfristig ist die Diskussion vermutlich im Wiki-Bereich besser aufgehoben, andererseits sind hier die derzeitigen User beieinander und können direkt ihre Meinung äußern. Das Problem dabei ist nur, dass die meisten vermutlich im Wesentlichen die Einrichtung noch "old-school" gemacht hatten, und daher diese komplett andere Herangehensweise über genericDeviceType, die ich grade propagiere (teilweise (!) & noch) nicht nachvollziehen können?

ad * - im Moment fehlt nach meinem Geschmack ungefähr folgendes:
- eine Art "einfach"-sentences.ini mit allen slots, die man direkt verwenden kann, ohne dass sich die Dinge gegenseitig ins Gehege kommen (=>Verwendung der eingeschränkten slots und weniger Varianten, also nicht "(schalte|mach)", sondern nur "schalte", aber dafür bei an/aus -media/-switch/-light und bei auf/zu -blind)
- die Darstellung der kompletten Konfiguration von diversen "Muster-Geräten", also z.B.
-- blind: eines CUL_HM-Rollladens, einer ZWave-Jalousie und eines "Custom"-Rollladens ohne numerischen Setter;
-- light: auch hier mehrere Varianten, ggf. mit Szenen (HUEDevice), ...
Meine Erwartung: So kann man sich das Zusammenspiel der Attribute besser erarbeiten?

@pah: Speziell deine Meinung als "Novize" und Experte in der Vermittlung derartigen Wissens zu diesem ganzen Themenkreis würde mich sehr interessieren!
(@all others: Das bedeutet ausdrücklich nicht, dass ihr ruhig bleiben solltet!).

ZitatExtrem cool wär ja, wenn man einfach EIN Markdown-File erstellen könnte, das dann automatisch in HTML für die Cref und Wiki-Markdown umgewandelt wird ;) . Für die CRef hab ich sowas mal gesehen glaub ich. Für's Wiki halt leider nicht.
Entsprechender Converter-Tools gibt es, allerdings vergesse ich immer, wie das geht, und m.E. müßte man so oder so klären, ob eine "Einheitsdokumentation" sinnvoll ist (ich meine: nein).

Anbei auch die (funktional nicht geänderte) Fassung mit den kleineren Änderungen an der commandref.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 30 November 2021, 11:38:23
Zitat von: Beta-User am 30 November 2021, 11:27:58
Sorry, das hier hatte ich gestern nicht beantwortet:So sollte das auch ohne Attribut klappen.
baseUrl=http://rhasspy:12101 defaultRoom=wohnzimmer language=de devspec=room=Rhasspy handleHotword=1
Der Teil ist eigentlich auch schon in der commandref (define und Attribut) enthalten ;) .

Das =1 war mir nicht klar. Ist auch in der CRef so nicht beschrieben. Und im Define-Code fehlt's auch. ;D

Über alles andere muss ich zuerst nachdenken.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: ph1959de am 30 November 2021, 11:44:56
Zum Thema "dokumentieren" - insbesondere im Wiki - habe ich folgende Vorschläge (und teilweise schon umgesetzt):


Ich habe die meisten Code-/Konfigurationsbeispiele auf <syntaxhighlight> Tags (lang="Text", sollte jemand einen passenden Lexer kennen, kann das natürlich gern angepasst werden) umgestellt, damit werden unter Anderem auch Formatierungsprobleme mit URLs vermieden.

Eine Anregung noch: an manchen Stellen würde {{RandNotiz...}} dem {{Hinweis}} vorziehen, weil dadurch der Lesefluss nicht so stark unterbrochen wird.

Zum großen Thema "EIN Markdown" habe ich leider keine Lösung parat.

Peter
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 30 November 2021, 12:46:14
Zitat von: ph1959de am 30 November 2021, 11:44:56
[...] und teilweise schon umgesetzt):
:) Danke! (auch für die weiteren Anmerkungen)

Irgendwie war es mir entgangen, dass im Wiki seit meinem ersten Wurf schon wieder von mehreren Seiten einiges erfolgt ist, sorry!

Zitat von: drhirn am 30 November 2021, 11:38:23
im Define-Code fehlt's auch. ;D
Na ja, es findet sich was in den "extended examples"...
Zitat
Über alles andere muss ich zuerst nachdenken.
Ging/geht mir auch so!

Vielleicht noch einige Anmerkungen von meiner Seite zum Ganzen:
- RHASSPY war für mich erst notwendiges Übel (ich konnte nicht von drhirn fordern, dass bestimmte "Soll-Anforderungen" eingehalten werden, ohne selbst zu zeigen, wie es geht ::) ), dann eine nette Fingerübung, um in Perl mal "richtig was" zu machen :o . Mit 0.4.xx hatten wir dann einen Stand erreicht, der ungemein flexibel ist 8) , und bei dem (nach ein paar Handgriffen) sehr vieles automatisch geht, der aber noch in "rhasspyMapping" verhaftet war;
- das lief jetzt völlig stressfrei für einige Monate, und das anscheinend nicht nur bei mir, sondern auch bei anderen.
Soweit so gut. Die (Doku-) Struktur paßte zum Nutzerkreis (lauter "Eingeschworene") und war eigentlich zweitrangig (aber gemessen an diesen Maßstäben exzellent!), weil bei denen ja soweiso jeder im großen und ganzen weiß, wie es prinzipiell funktioniert.
- zwischenzeitlich ist nicht nur eine kleine Schar weiterer Interessenden/Nutzer dabei, sich mit dem Thema zu befassen, sondern mir ist vor ein paar Tagen mal eine Spiegel-Beilage in die Hände gefallen, in der die Botschaft sinngemäß an mehreren Stellen hieß: Man braucht Internet (im Sinne einer "cloud"), um "richtige" Hausautomatisierung zu machen...

Das war dann für mich der Anlass, das Gegenteil zu beweisen :P und die jüngsten Umbauten in Angriff zu nehmen, mit den Zielen:
- der User soll für "Standard-Geräte" nicht viel mehr machen müssen wie diese RHASSPY zu unterstellen (=idR. gDT setzen) und ein paar "Namenslabel" dranzupappen (Prio 1);
- ein Interface zu generieren, dass man ggf. die Spracherkennung (speech to text) auch "außerhalb" machen lassen kann (Mitbewohner diktiert was mit "seinem Lieblings-System" an Telegram, z.B.), das dann intern mit Rhasspy als backend ausgewertet und für RHASSPY vorbereitet wird (Prio 2).

Denn: FHEM ist cloud-free, (was nicht bedeutet, dass man es nicht anders machen darf (!),) und es sollte eine gute (und m.E. daher auch offizielle) Lösung _wie_ RHASSPY/Rhasspy geben, mit der man den "Inputweg" Sprache bedienen kann. Soweit ich das bisher beurteilen kann, gibt es keine ernsthafte Konkurrenz, so dass ich aus diesem Grund dazu tendieren würde, sogar den Schritt in Richtung eines offiziellen Moduls zu erwägen, falls nicht einer der Experten (insbes. @pah) sich gegenteilig dazu äußert.

PS: ich schreibe das nicht unbedingt gerne, weil ein nicht unerheblicher support-Aufwand zu befürchten ist. Da das Modul an sich aber steht, und der "Stresstest" mit diesem außergewöhnlichen "blind" gezeigt hat, wie flexibel die Lösung im Ergebnis ist, kann man m.E. diesen Schritt jetzt prinzipiell gehen. Doku ist dazu dann eben "notwendiges Übel", und wir sollten die beiden "Neulinge" bitten, den Weg für "users to come" (mit) vorzubereiten. "whatever it takes"...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 30 November 2021, 13:10:43
Zitat von: ph1959de am 30 November 2021, 11:44:56
Zum Thema "dokumentieren" - insbesondere im Wiki - habe ich folgende Vorschläge (und teilweise schon umgesetzt):

So, jetzt bin ich verwirrt :D. V.a., weil ich ja gerade gestern Änderungen vorgenommen habe.

RHASSPY soll die Haupt-Seite werden?
Rhasspy und fhem-rhasspy Weiterleitungen auf RHASSPY?

Ich könnte gut damit leben. In meinem Kopf hieß das Modul nur einfach immer fhem-rhasspy um Verwechslungen vorzubeugen (Rhasspy/RHASSPY).

Zitat von: ph1959de am 30 November 2021, 11:44:56Eine Anregung noch: an manchen Stellen würde {{RandNotiz...}} dem {{Hinweis}} vorziehen, weil dadurch der Lesefluss nicht so stark unterbrochen wird.

Jup, war noch geplant.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 30 November 2021, 13:21:55
Zitat von: drhirn am 30 November 2021, 13:10:43
RHASSPY soll die Haupt-Seite werden?
Rhasspy und fhem-rhasspy Weiterleitungen auf RHASSPY?
Vorab: "Rhasspy" war vermutlich in der Tat keine gute Idee, da im Internet case-sensitive immer Mist ist. RHASSPY als Modul-Seite finde ich daher gut, und ich finde es auch gut, dass es eine weitere Seite gibt (Benennung weiß ich noch nicht so recht...).

Die "Modulseite" kann m.E. durchaus Basics zur Einrichtung enthalten, wobei ich dazu neigen würde, nur die "simple" Variante (incl. MQTT2_CLIENT) darzustellen, vielleicht noch was zu "devspec" und "baseId" zu sagen und für die ganzen anderen Optionen auf den "Quickstart" und/oder die commandref zu verweisen.

Ansonsten hatte ich "ganz früher" mal gespickelt, wie das anderswo so gemacht wird und hatte mir den Link auf diese Seite als "Basistemplate" notiert: https://wiki.fhem.de/wiki/FHEM_Connector_f%C3%BCr_Amazon_Alexa.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 30 November 2021, 13:53:45
Mit Weiterleitungen bekommen wir das schon hin.

Ich hätte den Quickstart auf eine eigene Seite ausgelagert (RHASSPY/Schnellstart) und unter Umständen etwas gekürzt. Den aber gleich am Anfang der Seite RHASSPY prominent verlinkt. Auf der Seite RHASSPY dann detailliertere Informationen zur Funktionsweise.
Ich bin mir nur noch nicht sicher, wie wir mit den Intents tun sollen. Eigene Seite für alle, eigene Seite für jeden einzelnen (bissi übertrieben) oder die gleich auf RHASSPY einbauen.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 30 November 2021, 14:25:48
Zitat von: drhirn am 30 November 2021, 13:53:45
Ich bin mir nur noch nicht sicher, wie wir mit den Intents tun sollen. Eigene Seite für alle, eigene Seite für jeden einzelnen (bissi übertrieben) oder die gleich auf RHASSPY einbauen.
Intents und sentences.ini sind m.E. "Vorder- und Rückseite" der Medaille. Das muss zusammenpassen, und einen "Grundstock" zu haben, schadet m.E. nicht. Meine momentane Tendenz zu diesem Punkt wäre, eine "vereinfachte" sentences.ini (aber unter Verwendung der spezifischen slots) bereitzustellen. Das als "Abschluss" zum QuickStart? Da müssen uU. nicht alle Intents rein, was genau, wäre noch zu klären (die timer-Geschichten sind halt direkt ziemlich komplex).
Da sich die slots von FHEM aus automatisch füllen, wäre so der erste Erfolg sehr schnell zu erzielen und die slots sind dann eigentlich auch direkt verständlich, weil erkennbar ist, was man sagen muss... Das verbleibende Problem dabei sind ggf. die "unaussprechlichen Namen", die man erst beseitigen muss, aber was das angeht, sollte auch nach den ersten Abschnitten im Quickstart klar sein, wie das läuft?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 30 November 2021, 14:34:31
Hmmmmm
Den Quickstart hätte ich nach "Erstes Gerät steuern" beendet. Sonst ist's ja kein Quickstart mehr ;D
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 30 November 2021, 14:49:22
Zitat von: drhirn am 30 November 2021, 14:34:31
Hmmmmm
Den Quickstart hätte ich nach "Erstes Gerät steuern" beendet. Sonst ist's ja kein Quickstart mehr ;D
...die Argumentation hat was für sich...

So war auch mein erster Gedanke, als ich mit dem Artikelchen gestartet war. Dann ist mir aufgefallen, dass da irgendwie ein paar auf der Hand liegende Fragen nach einer Antwort schreien (Gruppen, nummerische Werte, Farben), und der aktuelle Status quo ruft eigentlich auch noch nach "und wie geht es jetzt weiter" mit ein paar Links und Hinweisen.

Der Vorschlag zum Ort resultiert aus der Überlegung, dass wir versuchen sollten sicherzustellen, dass sich der User ein paar essentielle Gedanken gemacht hat, bevor er mit dem "großen Ganzen" konfrontiert wird. Überspringen wir diesen Schritt, ist meine Sorge, dass der Supportaufwand pro User um ein vielfaches höher wird. So könnten wir darauf verweisen, dass er nochmal diese eine Seite von vorne bis hinten durchgehen soll...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 30 November 2021, 15:05:16
Zitat von: Beta-User am 30 November 2021, 14:49:22
Der Vorschlag zum Ort resultiert aus der Überlegung, dass wir versuchen sollten sicherzustellen, dass sich der User ein paar essentielle Gedanken gemacht hat, bevor er mit dem "großen Ganzen" konfrontiert wird. Überspringen wir diesen Schritt, ist meine Sorge, dass der Supportaufwand pro User um ein vielfaches höher wird. So könnten wir darauf verweisen, dass er nochmal diese eine Seite von vorne bis hinten durchgehen soll...

Ja, seh ich auch so. Deswegen war auch mein Gedanke, das gleich am Anfang prominent zu platzieren. Von mir aus auch gerne als eigene Überschrift. Und der Inhalt verweist dann auf die Unterseite Schnellstart.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 30 November 2021, 15:45:47
 :) Anders gesagt: Die Bausteinchen später umzusortieren, ist nicht die große Übung, wenn die Bausteinchen exisitieren...

Vielleicht sollten wir dann lieber erst mal Bausteinchen backen ;) ...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 30 November 2021, 15:58:52
Hihi, ja. Ich hab schon den umgebauten Schnellstart im Ofen. Dauert aber noch ein bisschen, bis der durch ist. ;)
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Prof. Dr. Peter Henning am 30 November 2021, 16:59:39
Zitatist nicht die große Übung, wenn die Bausteinchen exisitieren...

Dann schau Dir mal "Die Türme von Hanoi" an.

LG

pah
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 30 November 2021, 17:09:12
So hätte ich mir das vorgestellt: https://wiki.fhem.de/wiki/RHASSPY/Schnellstart

Die restlichen Informationen aus deinem Schnellstart werden dann in der Hauptseite untergebracht.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 30 November 2021, 17:33:26
Zitat von: drhirn am 30 November 2021, 17:09:12
So hätte ich mir das vorgestellt: https://wiki.fhem.de/wiki/RHASSPY/Schnellstart (https://wiki.fhem.de/wiki/RHASSPY/Schnellstart)
Sieht gut aus!

(kleine!) Kritikpunkte:
- reload ist m.E. unnötig. DEF initialisiert alles, und attr languageFile liest die de-Fassung auch komplett ein. Probleme gab es nur, wenn die Basiskeys erweitert wurden, was während der Entwicklung hin und wieder der Fall war. (So einen Fall sollte man eher unter "Spezialfälle" sehen und bei updates der Moduldatei grundsätzlich einen restart empfehlen)
- "set rhasspy update all" befindet sich m.E. in der Erklärung an der falschen Stelle. Für "[de.fhem:GetTime]" muss man erst mal nur der Aufforderung folgen, das Training wegen der Änderung der sentences zu starten.
Alle anderen Infos/Tags braucht man erst später.
- "unklar" ist mir noch, ob man direkt noch weiter wie $de.fhem.Device-SetOnOff gehen sollte (also: ($de.fhem.Device-switch | $de.fhem.Device-light | $de.fhem.Device-media){Device})), aber das ist dann eher ein Vertiefungs-Thema.

Sonst finde ich das (sehr!) gelungen, und es ist im Prinzip auch völlig ok, dass der Artikel an der Stelle endet.

Zitat von: Prof. Dr. Peter Henning am 30 November 2021, 16:59:39
Dann schau Dir mal "Die Türme von Hanoi" an.
a) das ist simple Mechanik, wenn man mal weiß, wie man zählen muss :P ;
b) hinkt der Vergleich, weil andere Spielregeln gelten 8) .

Aber danke für den konstruktiven Einwand ::) ...

EDIT: Nachtrag noch @drhirn: Da steht was von RHASSPY versteht "an" nicht. Ich bin ja geneigt, das aus Aufforderung anzusehen, diesen Sprach-Kompabilitätsrest direkt auszubauen, wollte aber sicherheitshalber nachfragen, ob Einwände bestehen...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 30 November 2021, 17:50:48
Zitat von: Beta-User am 30 November 2021, 17:33:26
- reload ist m.E. unnötig. DEF initialisiert alles, und attr languageFile liest die de-Fassung auch komplett ein. Probleme gab es nur, wenn die Basiskeys erweitert wurden, was während der Entwicklung hin und wieder der Fall war. (So einen Fall sollte man eher unter "Spezialfälle" sehen und bei updates der Moduldatei grundsätzlich einen restart empfehlen)
- "set rhasspy update all" befindet sich m.E. in der Erklärung an der falschen Stelle. Für "[de.fhem:GetTime]" muss man erst mal nur der Aufforderung folgen, das Training wegen der Änderung der sentences zu starten.
Alle anderen Infos/Tags braucht man erst später.

Ich hab mir für die Doku extra eine neue Testumgebung angelegt. Und das zuerst so getestet, wie du das geschrieben hast. Und das hat eben dann erst funktioniert, nachdem ich reload/update all gemacht habe. Das reload war nicht immer nötig. Weiß nicht, warum ich das gebraucht habe. Aber bevor Fragen aufkommen, dachte ich mir, ich schreib's einfach rein. Schadet ja nicht. Das "update all" war definitiv notwendig, weil das Modul noch nichts von dem neuen Intent wusste. Erst nach dem update all war der im Reading "intents" vorhanden.

Zitataber das ist dann eher ein Vertiefungs-Thema.

Finde ich auch ;)

Zitat
EDIT: Nachtrag noch @drhirn: Da steht was von RHASSPY versteht "an" nicht. Ich bin ja geneigt, das aus Aufforderung anzusehen, diesen Sprach-Kompabilitätsrest direkt auszubauen, wollte aber sicherheitshalber nachfragen, ob Einwände bestehen...

Einwände hab ich keine. Notwendig finde ich es aber nicht. Weil, kann ja sein, dass es nicht bei "an" und "aus" bleibt. Gibt ja noch andere Wörter dafür ("ein" z.B.).
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 30 November 2021, 17:59:25
Zitat von: drhirn am 30 November 2021, 17:50:48
Ich hab mir für die Doku extra eine neue Testumgebung angelegt. Und das zuerst so getestet, wie du das geschrieben hast. Und das hat eben dann erst funktioniert, nachdem ich reload/update all gemacht habe. Das reload war nicht immer nötig. Weiß nicht, warum ich das gebraucht habe.
Ich habe den Verdacht, dass das eine andere Urache hat, die eher im Zusammenspiel mit MQTT2_CLIENT zu suchen ist. Jedenfalls erschließt sich mir der reload an der Stelle nicht - abgesehen ggf. davon, dass man das dann braucht, wenn man language in global anfasst. Dann muss man auch die DEF von RHASSPY anfassen - (aber ein reload hilft in diesem Fall auch nicht)

Zitat
Aber bevor Fragen aufkommen, dachte ich mir, ich schreib's einfach rein. Schadet ja nicht. Das "update all" war definitiv notwendig, weil das Modul noch nichts von dem neuen Intent wusste. Erst nach dem update all war der im Reading "intents" vorhanden.
Das Reading ist aber nur Kosmetik, die Auswertung der Messages sollte so oder so stattfinden, wenn das zu den Internals paßt, was reinkommt.

ZitatEinwände hab ich keine. Notwendig finde ich es aber nicht. Weil, kann ja sein, dass es nicht bei "an" und "aus" bleibt. Gibt ja noch andere Wörter dafür ("ein" z.B.).
Na ja, die Botschaft wäre eher: alles, was sinngemäß "on" ist, ist eben genau als on zu übergeben, und die "hoch"- und "runter"-Anweisungen sind nur noch mit dem korrespondierenden englischen Key zu übergeben. (Der code ist an der Stelle eigentlich unnötig kompliziert, und wenn wir ihn vereinfachen können, fallen halt ein paar Zeilen wieder weg, weil auch ein, zwei zentrale Hashes nicht mehr benötigt werden...).
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 01 Dezember 2021, 09:29:00
Ich hab das jetzt nochmal getestet. In einer ganz frischen Umgebung.

Stimmt, wenn ich die Sprache im DEF umstelle, brauche ich kein Reload. Wenn ich aber - nach einrichten des RHASSPY-Devices - die Sprache in global ändere, muss ich entweder einmal die DEF von RHASSPY öffnen und (ohne Änderung) wieder speichern. Oder eben einen Reload machen. Da ich aber im Satz im Wiki ein ein "kann nötig sein" habe und ein reload ja eigentlich nicht weh tut, könnte man das - umformuliert - schon drinnen lassen.

Bezüglich "update all" der selbe Effekt, wie gestern schon. Solange ich das nicht gemacht habe, erkennt Rhasspy zwar den Satz "wie spät ist es", findet aber keinen Intent dazu. Was echt schräg ist. Und es ist egal, wie oft ich trainiere. Geht erst nach einem udpate all. "update devicemap" reicht nicht. Kann ich mir nicht erklären. Und teste das jetzt gleich nochmal.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 01 Dezember 2021, 09:50:25
Zitat von: drhirn am 01 Dezember 2021, 09:29:00
Bezüglich "update all" der selbe Effekt, wie gestern schon. Solange ich das nicht gemacht habe, erkennt Rhasspy zwar den Satz "wie spät ist es", findet aber keinen Intent dazu. Was echt schräg ist. Und es ist egal, wie oft ich trainiere. Geht erst nach einem udpate all. "update devicemap" reicht nicht. Kann ich mir nicht erklären. Und teste das jetzt gleich nochmal.

Und jetzt passiert's natürlich nicht mehr. Obwohl ich alles genau gleich gemacht habe. Aber, es muss irgendwie an Rhasspy gelegen sein.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 01 Dezember 2021, 09:55:46
Zitat von: drhirn am 01 Dezember 2021, 09:29:00
Bezüglich "update all" der selbe Effekt, wie gestern schon. Solange ich das nicht gemacht habe, erkennt Rhasspy zwar den Satz "wie spät ist es", findet aber keinen Intent dazu. Was echt schräg ist. Und es ist egal, wie oft ich trainiere. Geht erst nach einem udpate all. "update devicemap" reicht nicht. Kann ich mir nicht erklären. Und teste das jetzt gleich nochmal.
Das "mehr" liegt an fetchIntents(), vielleicht kannst du mal "fetchIntents($defs{<rhasspy-Name>})" testen? Dann bastle ich das noch in "update" mit rein...

Zitat von: drhirn am 01 Dezember 2021, 09:29:00
Da ich aber im Satz im Wiki ein ein "kann nötig sein" habe und ein reload ja eigentlich nicht weh tut, könnte man das - umformuliert - schon drinnen lassen.
So ein Satz "riecht" nach fehlerhafter Programmierung, von daher hätte ich ihn gerne draußen. DEF anfassen als Anleitung wäre für mich ok.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 01 Dezember 2021, 09:59:06
Zitat von: Beta-User am 01 Dezember 2021, 09:55:46Das "mehr" liegt an fetchIntents(), vielleicht kannst du mal "fetchIntents($defs{<rhasspy-Name>})" testen? Dann bastle ich das noch in "update" mit rein...
Nicht nötig, siehe oben.

ZitatSo ein Satz "riecht" nach fehlerhafter Programmierung, von daher hätte ich ihn gerne draußen. DEF anfassen als Anleitung wäre für mich ok.
Haha, alles klar. Hab's geändert. Weiß nur nicht, ob jeder versteht, was damit gemeint ist. https://wiki.fhem.de/wiki/RHASSPY/Schnellstart#Basissprache
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 01 Dezember 2021, 10:33:10
Zitat von: drhirn am 01 Dezember 2021, 09:59:06
Nicht nötig, siehe oben.
Danke.

Zitat
Haha, alles klar. Hab's geändert. Weiß nur nicht, ob jeder versteht, was damit gemeint ist. https://wiki.fhem.de/wiki/RHASSPY/Schnellstart#Basissprache (https://wiki.fhem.de/wiki/RHASSPY/Schnellstart#Basissprache)
Habe da ein kleines Beispiel ergänzt, weiß allerdings nicht, ob das jedem weiterhilft...

Anbei dann wieder ein (weitgehend ungetestetes!) update. Das
- kann nicht mehr die de-mappings verstehen und
- sollte einige mehr "SetOnOff"-Typen erkennen (darunter auch den 0/1-Fall (?) vom Nebenthread)

Also falls du grade eh' am Testen bist...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 01 Dezember 2021, 10:34:20
Zitat von: Beta-User am 01 Dezember 2021, 10:33:10
- kann nicht mehr die de-mappings verstehen und

Was bedeutet das konkret?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 01 Dezember 2021, 10:35:51
Zitat von: Beta-User am 01 Dezember 2021, 10:33:10
Habe da ein kleines Beispiel ergänzt, weiß allerdings nicht, ob das jedem weiterhilft...

Es muss nicht mal ein Leerzeichen angefügt werden. Auf "DEF" klicken und dann auf "modify xxx" reicht.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 01 Dezember 2021, 10:39:10
Zitat von: drhirn am 01 Dezember 2021, 10:34:20
Was bedeutet das konkret?

Das bedeutet, dass alle die ihre sentences.ini (und ggf. rhasspyMappings) überarbeiten müssen, die diese Version nutzen möchten _und_ bisher noch die deutschen Begrifflichkeiten drin hatten (und/oder ungünstige Werte in state der Devices haben für on/off).
Also Type=Helligkeit geht nicht mehr, da muss brightness hin/kommen.

Zitat von: drhirn am 01 Dezember 2021, 10:35:51
Es muss nicht mal ein Leerzeichen angefügt werden. Auf "DEF" klicken und dann auf "modify xxx" reicht.
:) Dann ist es noch einfacher. Ich mache halt meistens das mit dem Leerzeichen, das funktioniert z.B. auch in den Attributen. Ist vermutlich dann ein unnötiger Hosenträger... ;D
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 01 Dezember 2021, 18:52:32
So, ich hab euch allen, die ihr eine deutsche Wiki-Doku wolltet, mal ein bisschen was zum Abarbeiten vorgegeben (https://wiki.fhem.de/wiki/RHASSPY). Viel Spaß beim Übersetzen und Ergänzen. Ich mach mal Schluss für heute ;)
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 02 Dezember 2021, 16:44:40
Text-Zeilen, die grau sind, konnte ich - mangels Wissen - nicht übersetzen. Das müsste bitte jemand anderer machen. Am Besten so, dass auch ich verstehe, was gemeint ist ;)
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 02 Dezember 2021, 17:37:40
...irgendwie hatte sich da wohl was überschnitten, und jetzt finde mal die Unterschiede...

Hier mal die übersetzte Fassung:

[...]
(War leider weg...)
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Prof. Dr. Peter Henning am 02 Dezember 2021, 18:07:53
Öh...

Ich habe gerade die Sprache des Wiki-Eintrags etwas geglättet. Zumindest damit angefangen.

LG

pah
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 02 Dezember 2021, 18:22:02
Zitat von: Beta-User am 02 Dezember 2021, 17:37:40
...irgendwie hatte sich da wohl was überschnitten, und jetzt finde mal die Unterschiede...

Wie hat sich wann wo was überschnitten?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 02 Dezember 2021, 19:25:45
...hatte vorhin versucht, die in den code-tags zu findende Fassung ins Wiki zu packen. Da kam dann eine Meldung, dass sich das mit anderen zwischenzeitlichen Änderungen "beißen" würde - also habe ich das erst mal gelassen...

Scheint @pah gewesen zu sein. Sollte kein Problem sein, das zu integrieren, aber heute mache ich das nicht mehr... (bin nicht traurig, falls jemand anderes sich ein diff anschaut und das dann zusammenpuzzelt...)
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 03 Dezember 2021, 10:16:18
OK, leider scheinen meine gestrigen Vorschläge doch versehentlich in den Orkus gewandert zu sein...

Jetzt ist es aktualisiert. Bei der Gelegenheit ist mir aufgefallen, dass bei den jetzigen sentences.ini-Beispielen meine "Schubser" im "neue Ufer"-Thread zur Nutzung der eingeschränkten slots noch nicht berücksichtigt sind und hoffe sehr, dass geplant ist...

Bei der Gelegenheit: Für ein "howto part 2" würde ich vorschlagen, dann auch sowas wie Gruppen-Schaltungen zu erläutern, und eine Doku zu "mainrooms" fehlt vermutlich auch noch (für die cref hole ich das nach)... (ich befürchte, diesen Hinweis versteht keiner...)

PS: Wegen des dialogischen "Interfacings" zwischen Messenger-Diensten und RHASSPY/Rhasspy bin ich jetzt über msgConfig/msgDialog gestolpert. Meine aktuelle Idee wäre, die betreffenden funktionalen Code-Bausteine aus msgDialog (umgebaut) in RHASSPY einzubauen. Damit hätte man die Option, nicht nur einfache Textkommandos entgegenzunehmen (was schon immer ging, aber irgendwie an mir vorbeigegangen war), sondern
- die Antwort (in Text) wieder an den Absender zu senden (statt zu sprechen);
- eventuell fehlende Informationen abzufragen;
- offene Dialoge zu gestalten ("Hi user, was willst du tun: Geräte schalten oder Informationen abrufen?" -> Geräte schalten -> "wo bzw. welche Geräte oder Gruppe?" ...)

Der Vorteil von RHASSPY ist ja, dass wir bereits eine relativ eindeutige Brücke von Sprache zu FHEM-Devices haben, und "wissen, was geht", und andererseits Optionen, pro Gerät auch spezifische Abfragen vorkonfigurieren zu können, ohne komplexe JSON-Strukturen vorzukonfigurieren. msgConfig seinerseits erlaubt es, im Prinzip beliebige Messenger-Dienste einzubinden :) .

Wird aber noch dauern, bis (vielleicht) das Gerüst steht...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 03 Dezember 2021, 10:23:27
Ich übernehme derzeit nur aus CRef/GitHub und formatiere entsprechend. Übersetzen tu ich nur nach Lust und Laune. Und ändern nur, wenn's unbedingt erforderlich ist.
Das wird's für mich dann aber im Großen und Ganzen gewesen sein.

Wer ändern/ergänzen will, möge das tun. Gröbere Änderungen können wir ja vorher hier oder auf der Diskussion-Seite der Wiki-Seite besprechen.

Was meinst du mit "mainrooms"?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 03 Dezember 2021, 10:46:14
Zitat von: drhirn am 03 Dezember 2021, 10:23:27
Was meinst du mit "mainrooms"?
Es gibt einen speziellen slot, in dem alle "Erstwerte" landen, die im "rooms"-Key bei jedem Device stehen. Der wird für Auswahldialoge genutzt. Ist ähnlich wie die etwas offensichtlichere "alias"-Funktionalität, und ich gehe mal davon aus, dass der Gesamtzusammenhang vom Tweak "ignoreKeywords" (rooms) über die Attributauswertung (room, rhasspyRoom) bis hin dazu, welche Auswahlmöglichkeit dann in $mainrooms bestehen, einigermaßen unklar ist ;D ...

Genauso dürften ein paar Praxisbeispiele dazu fehlen, welche Angaben man sinnvollerweise über "room"-Begrifflichkeiten abwickelt (eher "geografisch" orientiert), und was über Gruppenzugehörigkeiten (eher funktional orientiert). Also: "schließe alle rollläden im erdgeschoss", "mache sämtliche lichter im essbereich an". Setzt halt voraus, dass man entsprechend Werte in den Gruppen- und room-Attributen gesetzt hat, aber dann funktioniert das (mit den eingeschränkten slots!) m.E. ziemlich gut...

Zitat von: drhirn am 03 Dezember 2021, 10:23:27
Ich übernehme derzeit nur aus CRef/GitHub und formatiere entsprechend. Übersetzen tu ich nur nach Lust und Laune. Und ändern nur, wenn's unbedingt erforderlich ist.
Das wird's für mich dann aber im Großen und Ganzen gewesen sein.

Wer ändern/ergänzen will, möge das tun. Gröbere Änderungen können wir ja vorher hier oder auf der Diskussion-Seite der Wiki-Seite besprechen.
Verständlich, und irgendwo muss man auch anfangen, da ist der erste Schritt mit der Übersetzung schon ein Riesenschritt vorwärts.

Nur bekommen wir es an die User nicht ran, dass es sehr viel akkuratere Möglichkeiten gibt, einzelne (Gruppen von) Geräte/n zu adressieren, wenn wir im Wiki wieder alles in einen Topf werfen und überall nur $de.fhem:Device hinpappen. Für mich ist das wie Porsche nur im 1. Gang fahren ::) ...

Wenn es nicht anders geht, räume ich bei Gelegenheit hinterher, aber eigentlich dürfte der Aufwand minimal sein, das gleich mit einzupflegen.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 03 Dezember 2021, 14:11:52
Zitat von: Beta-User am 03 Dezember 2021, 10:46:14
Es gibt einen speziellen slot, in dem alle "Erstwerte" landen, die im "rooms"-Key bei jedem Device stehen. Der wird für Auswahldialoge genutzt. Ist ähnlich wie die etwas offensichtlichere "alias"-Funktionalität, und ich gehe mal davon aus, dass der Gesamtzusammenhang vom Tweak "ignoreKeywords" (rooms) über die Attributauswertung (room, rhasspyRoom) bis hin dazu, welche Auswahlmöglichkeit dann in $mainrooms bestehen, einigermaßen unklar ist ;D ...

Ähm, ja :D

ZitatNur bekommen wir es an die User nicht ran, dass es sehr viel akkuratere Möglichkeiten gibt, einzelne (Gruppen von) Geräte/n zu adressieren, wenn wir im Wiki wieder alles in einen Topf werfen und überall nur $de.fhem:Device hinpappen. Für mich ist das wie Porsche nur im 1. Gang fahren ::) ...

Wenn es nicht anders geht, räume ich bei Gelegenheit hinterher, aber eigentlich dürfte der Aufwand minimal sein, das gleich mit einzupflegen.

Wo ich eh schon korrigiert, hab ich das hinzugefügt.

Ansonsten bin ich so weit fertig. Sollte alles da sein, was in CRef und GitHub steht. Jetzt seid ihr dran. Viel Spaß!
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 03 Dezember 2021, 14:26:28
Zitat von: drhirn am 03 Dezember 2021, 14:11:52
Ähm, ja :D
...am besten mal ausprobieren und mit den Parametern rumspielen... Sonst schreibe ich mir die Finger wund und bekomme es eh' nicht erklärt... ::)

ZitatWo ich eh schon korrigiert, hab ich das hinzugefügt.

Ansonsten bin ich so weit fertig. Sollte alles da sein, was in CRef und GitHub steht. Jetzt seid ihr dran. Viel Spaß!
Danke! Ich versuche dann bei Gelegenheit nochmal drüberzugehen, wäre aber überhaupt nicht undankbar, wenn sich jemand anderes der Sache annehmen würde.
(Eigentlich hatte ich mal angenommen, dass die slot-Namen selbsterklärend wären und irgendwann jemand rufen würde: "Das ist ja g...(anz toll)!" und dann ab da dann "der Fisch geputzt" wäre. Scheint eine grobe Fehleinschätzung gewesen zu sein, oder ich hab's bisher noch nicht geschafft, das so zu erklären, dass es jemand versteht ::) ...).

Am WE will ich aber wenn möglich erst mal testen, ob RHASSPY mit Telegram spricht, dann könnt ihr euch dann wieder mit neuen unverstandenen features rumschlagen :P und Vorschläge liefern, wie man das verbessern kann...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Gisbert am 03 Dezember 2021, 20:40:24
ZitatBei der Gelegenheit ist mir aufgefallen, dass bei den jetzigen sentences.ini-Beispielen meine "Schubser" im "neue Ufer"-Thread zur Nutzung der eingeschränkten slots noch nicht berücksichtigt sind und hoffe sehr, dass geplant ist...

Hallo Jörg,

Das kommt ganz sicher noch, WE steht ja vor der Tür :). Mitgelesen habe ich die ganze Zeit, auch in diesem Thread hier. Der Hinweis im "neuen Ufer"-Thread auf ein Youtube-Video war auch sehr hilfreich.

Viele​ Grüße​ Gisbert​
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 04 Dezember 2021, 17:44:50
Hallo zusammen,

kleiner update zu zwei Aspekten:

Zum einen gibt es jetzt mit gdt2groups noch einen weiteren Tweak, der das Einrichten erleichtern soll (siehe commandref);

Zum anderen bin ich mit dem msgDialog-Thema immerhin mal soweit, dass es ein Attribut dafür gibt und die Eventverarbeitung startet, wenn man mit Telegram was reinschickt. Wer da mitwerkeln will, muss vermutlich etwas tiefer in das Coding einsteigen und mal einen msgDialog eingerichtet haben, sonst ist das sicher komplett unverständlich.
Für heute mache ich an der Stelle mal Schluss...

Grüße, Beta-User
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Prof. Dr. Peter Henning am 04 Dezember 2021, 19:28:06
Diverse Inkonsistenzen in der Schnellstart-Anleitung behoben.

LG

pah
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 04 Dezember 2021, 20:13:12
Zitat von: Prof. Dr. Peter Henning am 04 Dezember 2021, 19:28:06
Diverse Inkonsistenzen in der Schnellstart-Anleitung behoben.

Danke!

Die konsequente Kleinschreibung für die RHASSPY-Instanz ist eine gute Sache.

Klingt danach, als wäre die Einrichtung nach der Anleitung erst mal soweit nachvollziehbar  :) .

Als nächsten Schritt würde ich dann empfehlen, die relativ neuen "Schlüsselwörter" in rhasspyTweaks zu setzen (also ignoreKeywords und gdt2groups). Damit hat man dann z.B. gleich alle "blind"-Geräte in einer ansprechbaren Gruppe "Rollläden" oder alle "light" in "Lichter"...
Danach käme dann das "rhasspy-Attribut am Device geht genereller Einstellung/Erkennung vor"-Prinzip an die Reihe ;) .
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 04 Dezember 2021, 20:21:18
Der MQTT von Rhasspy läuft per default auf Port 12183. Das hat schon gepasst.

Und mit deiner Einführung von "rhasspy" hast du eine dritte Schreibweise eingeführt. Passt zwar zum in den Screenshots definierten Device, weiß aber nicht, ob das dann nicht noch verwirrender wird. Ich hatte mit "RHASSPY" einfach das Modul im Kopf - unabhängig davon, wie's der User benennt. Im "Normalfall" hat man ja eh nur eine Definition des Moduls.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Gisbert am 05 Dezember 2021, 10:03:30
Hallo zusammen,

ich nutze die Android-App zur Spracheingabe. Bei Benutzung der App muss man diese öffnen und auf das Mikrofon tippen, bevor man den Sprachbefehl absetzen kann, immerhin sind 2 Klicks notwendig.

Gibt es die Möglichkeit wie bei Google Assistant ein Aufwachwort zu sprechen und dann den eigentlichen Sprachbefehl?

In meinem Fall benutzt Rhasspy den gleichen MQTT-Broker Mosquitto wie meine Fhem-Installation. Gibt es dabei etwas zu bedenken?

Viele​ Grüße​ Gisbert​
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 05 Dezember 2021, 10:08:01
Zitat von: Gisbert am 05 Dezember 2021, 10:03:30
In meinem Fall benutzt Rhasspy den gleichen MQTT-Broker Mosquitto wie meine Fhem-Installation. Gibt es dabei etwas zu bedenken?

Ja! Rhasspy schickt enorm viele Daten durch die Gegend. Sobald ein Hotword erkannt wurde z.B. alles, was das Mikrofon aufnimmt. Also wirklich Audio (WAV Chunks). Das willst du alles nicht wirklich auf einem MQTT-Broker haben, der auch andere Sachen machen soll. Deshalb lieber zwei getrennte Mosquittos. Einen für FHEM und den Rhasspy-eigenen für Rhasspy, den du dann mit MQTT2_CLIENT abfrägst.

Zur App kann ich nicht viel sagen. Hab aber im Hinterkopf, dass man schon irgendwie aktivieren konnte, dass die dauernd zuhört. Muss Beta-User etwas dazu sagen.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Prof. Dr. Peter Henning am 05 Dezember 2021, 11:50:47
@drhirn:
ZitatUnd mit deiner Einführung von "rhasspy" hast du eine dritte Schreibweise eingeführt.
Nix da. Das war schon vorher im Wiki - aber eben nicht überall. Außerdem muss man sorgfältig zwischen dem Modul RHASSPY und der Instanz rhasspy unterscheiden.

ZitatDer MQTT von Rhasspy läuft per default auf Port 12183. Das hat schon gepasst.
Auch nicht zielführend - denn bei Verwendung der Installations- und Startanweisung für das Docker Image auf den offiziellen Rhasspy-Seiten ist der Port 12183 nicht exposed. Damit klappt die Verbindung zwischen FHEM und Rhasspy nur über einen (Rhasspy-externen) Mosquitto. Und der läuft auf 1883.

LG

pah
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 05 Dezember 2021, 16:26:36
Zitat von: Gisbert am 05 Dezember 2021, 10:03:30
Bei Benutzung der App muss man diese öffnen und auf das Mikrofon tippen, bevor man den Sprachbefehl absetzen kann, immerhin sind 2 Klicks notwendig.
Es gibt auch ein (unschönes) "Widget", mit dem man mit einem Klick ein "offenes Mikro" bekommt.

Zitat
Gibt es die Möglichkeit wie bei Google Assistant ein Aufwachwort zu sprechen und dann den eigentlichen Sprachbefehl?
Ja. Muss extra eingeschaltet werden (an der App), und die "Base" muss wissen, dass es für diesen Satelliten die wakeword-Funktion übernehmen soll. Sollte im "Läuft soweit"-Thread zu finden sein, wie die Ports zu konfigurieren sind. (Für wakeword wird per UDP der Ton übertragen => nicht sooo toll für die Akku-Laufzeit.... => ich nehme lieber den shortcut per widget.)

Zitat
In meinem Fall benutzt Rhasspy den gleichen MQTT-Broker Mosquitto wie meine Fhem-Installation. Gibt es dabei etwas zu bedenken?
Ja. "not recommended", wie drhirn und meinereiner schon mehrfach geschrieben haben. Ich hatte erst einen extra externen Mosquitto dafür aufgesetzt, aber das macht keinen Sinn und der interne "frißt auch (fast) kein extra Brot"... (Man ist mit dem "internen" setup einfach "standardkonform").
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Gisbert am 05 Dezember 2021, 20:26:56
Hallo Jörg,

danke für die Info. Das Widget für ein offenes Mikrofon finde ich ganz ok. Damit lasse ich es bewenden.

Viele​ Grüße​ Gisbert​
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 06 Dezember 2021, 18:05:36
Hier findet ihr einen ersten Wurf für die "Einführung Teil 2": https://wiki.fhem.de/wiki/RHASSPY/Vertiefung
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Prof. Dr. Peter Henning am 07 Dezember 2021, 15:57:24
1. Frage:
- Warum verhalten sich das Docker-Image und die per dpkg installierte Paketversion unterschiedlich in Bezug auf das Mikrofon?
  Bei Docker-Image wird zur Auswahl beim Audio Recording als Device angeboten "Hardware device with all software conversions (plughw:CARD=AK5370,DEV=0)", bei der Paketversion fehlt dies (obwohl natürlich das plughw-Plugin für Alsa installiert ist). Das wäre aber wichtig, um beliebige Mikros verwenden zu können.

2. Beobachtung:
- Derzeit habe ich es noch nicht geschafft, in Docker ein EXTERN trainiertes Modell für die Wakeup-Engine precise zum Laufen zu bekommen. Zwar kann man das Modell (in beiden Installationsversionen) in das richtige Verzeichnis schreiben, es wird dann in Rhasspy auch zur Auswahl angeboten - aber laufen tut es (noch) nicht.

3. Feature Requests für das Modul:
- Es sollte möglich sein, zusätzliche Räume (als Werte für den Room-slot) in einem Attribut zu hinterlegen. Derzeit ist mein Weg, ein Dummy zu definieren, das einfach in diversen rhasspyRooms vertreten ist, und diesem den genericDeviceType switch zu geben.
- Es sollte ein "set ... activateVoiceInput" geben, mit dem Rhasspy aufgeweckt wird (also ohne Wakeword). Die Benennung "activateVoiceInput" orientiert sich dabei an dem, was man bei Android Tablets eingeben kann.

4. Rhasspy und Babble:
- Ich habe das jetzt genau evaluiert. Es ist problemlos möglich, im Attribut rhasspyIntents des rhasspy-Devices einen Intent-Handler anzulegen, der den gesamten input an Babble weiterleitet, indem die subroutine Babble_DoIt("<name>","<sentence>"[,<parm0>,<parm1>,...]) aufgerufen wird. Die Auswertung, sowie gegebenenfalls die Steuerung von FHEM-Devices, wird dann komfortabel über die Oberfläche von Babble konfiguriert. An Babble ist im Hintergrund noch der RiveScript-Chatbot angekoppelt, der einen echten Dialog mit dem Nutzer führen kann.

Beispiel (U=User, B=Babble, R=Rhasspy):

U: "Hey Mycroft"
R: Beep
U: "Spiele Musik"
(R: Erkennt dies als Dateneingabe in einem Intent "Musik". Leitet dies an B weiter. B intern: Nicht direkt erkannt, reiche weiter an RiveScript. Dort erkannt,  B wechselt in den Kontext "Musik". Antwortet mit Text, B reicht Text an R weiter oder lässt auf einem anderen Device sprechen)
R: "Das mache ich gerne, bitte sage mir wo Du gerade bist"
R mit Verzögerung: aktiviert Spracheingabe ohne Wakeword
U: "Im Schlafzimmer"
(R: Erkennt dies als Dateneingabe in einem Intent "GetRoom". Leitet dies an B weiter. B intern: Nicht direkt erkannt, reiche weiter an RiveScript. Dort erkannt, im Kontext "Musik" muss dies ein Raumname sein. Wenn nicht, Fehlermeldung zurück via B an R, dort ausgesprochen. Wenn ja, antworte mit Text. B reicht Text an R weiter oder lässt auf einem anderen Device sprechen)
R: "Von wem soll ich im Schlafzimmer Musik spielen?"
R mit Verzögerung: aktiviert Spracheingabe ohne Wakeword
U: "Von den Beatles"

===> Ab jetzt wird es visionär

(R: Erkennt dies als Dateneingabe in einem Intent "getSource", aber mit der Aussprache "Bietels". Leitet dies an B weiter. B intern: Nicht direkt erkannt, reiche weiter an RiveScript. Dort erkannt. Rivescript ruft B auf mit dem vollständigen Satz "Spiele Musik im Schlafzimmer von Quelle Bietels".

Hinweis: Bei mir läuft dann eine Suche in meiner Musikbibliothek nach Songs, bei dieser Suche kann z.B. "Bietels" auf "Beatles" gemappt werden.
Endergebnis: Es wird eine Playlist mit Beatles-Songs abgespielt.

Problematisch ist in diesem Beispiel, dass die STT-Engines von Rhasspy ohne Cloud-Zugriff keinen Text für untrainierte Sätze ausgeben können. In meinen Android-Devices kommt von Google tatsächlich auch in einer deutschen Satzkontruktion  "Beatles" zurück, weil die offenbar eine semantische Analyse durchführen und erkennen, dass die Band gemeint ist. Klappt auch bei anderen Bands, wie "Deep Purple" - scheitert dann aber an deutschen Künstlern, etwa wird statt "Degenhardt" nur "Degenhart" zurückgegeben. In meiner Suchroutine macht das nichts aus, weil ich zur Erkennung von Künstlern die Namen bis zu einem Levenshtein-Abstand von 3 auswerte.

Ob mit einer anderen STT-Engine (etwa Mozilla Deep Speech) auch die Rückgabe von Text für untrainierte Sätze möglich ist, muss ich mir noch ansehen.

Fazit: JA, Rhasspy (und auch das Modul) können prima mit Babble zusammenarbeiten. Das hat den Vorteil, dass die Intents komplett von den Devices getrennt werden können, und die auszuführenden Befehle zentral abgelegt werden können (eben in der Datenstruktur von Babble). Zusammen mit dem an Babble angehängten ChatBot ergeben sich tolle Möglichkeiten  - begrenzt nur durch die Tatsache, dass (bisher) untrainierte Sätze von Rhasspy nicht in Text umgewandelt werden können. In dem obigen Dialogbeispiel ist das bei den Räumen gut ausgeführt: Die relativ wenigen Räume meines Hauses kann ich Rhasspy antrainieren - aber nicht hundertundein Künstlernamen aus meiner Musikbibliothek.

Zur Verbessserung der Zusammenarbeit habe ich oben zwei Feature Requests für das Rhasspy-Modul gepostet. Auf der Seite von Babble wäre ein wichtige Verbesserung, es an MQTT anzubinden - es müsste sowohl textuelle Daten von dort bekommen, als auch textuelle Daten ODER Audiodaten zurückliefern. Ersteres geht ohne Cloud.

LG

pah
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 07 Dezember 2021, 16:47:03
Erst mal zu dem hier:
Zitat von: Prof. Dr. Peter Henning am 07 Dezember 2021, 15:57:24
3. Feature Requests für das Modul:
- Es sollte möglich sein, zusätzliche Räume (als Werte für den Room-slot) in einem Attribut zu hinterlegen. Derzeit ist mein Weg, ein Dummy zu definieren, das einfach in diversen rhasspyRooms vertreten ist, und diesem den genericDeviceType switch zu geben.
- Es sollte ein "set ... activateVoiceInput" geben, mit dem Rhasspy aufgeweckt wird (also ohne Wakeword). Die Benennung "activateVoiceInput" orientiert sich dabei an dem, was man bei Android Tablets eingeben kann.
Teil 1 mit den zusätzlichen Räumen verstehe ich noch nicht so ganz. Prinzipiell versucht RHASSPY halt, über die Räume rauszufinden, welches Device gemeint sein soll. Ein "device-loser Raum" macht für mich keinen großen Sinn (falls es so gemeint ist), und ein "normales Device" kann im Prinzip in beliebig vielen rhasspyRooms vertreten sein. Prinzipiell sehe ich aber kein Problem, einen Tweak zu basteln, der device-lose Räume ergänzt.
Vielleicht klärst du mich auf, was du damit erreichen willst :) .

"activateVoiceInput" dürfte auch kein allzugroßes Problem sein, allerdings wird in Rhasspy nach meinem Verständnis eine Sitzung immer einer "siteId" zugeordnet, die den Dialog vermutlich auch wieder schließen sollte.
Siehe https://rhasspy.readthedocs.io/en/latest/wake-word/#mqtthermes, und nach meinem Verständnis ergänzend: https://docs.snips.ai/reference/hermes#detecting-a-wake-word

Wenn es so gedacht ist, dass von FHEM aus ein beliebiger Satellit "geöffnet" werden soll, muss der als Argument übergeben werden (und bekannt sein).

Falls FHEM/RHASSPY die Sitzungsverwaltung machen soll: In etwa an dem Problem hänge ich grade bei der msgDialog-Geschichte fest. Da muss man m.E. streng genommen zwei Sitzungen verwalten, nämlich einmal in Richtung des Messengers (bzw.: Babble), und zum anderen (ggf. bedarfsorientiert auch mehrfach unterbrochen) in Richtung Rhasspy.

Bitte um Klärung, was du genau benötigst.

Zitat
4. Rhasspy und Babble:
- Ich habe das jetzt genau evaluiert. Es ist problemlos möglich, im Attribut rhasspyIntents des rhasspy-Devices einen Intent-Handler anzulegen, der den gesamten input an Babble weiterleitet, indem die subroutine Babble_DoIt("<name>","<sentence>"[,<parm0>,<parm1>,...]) aufgerufen wird. Die Auswertung, sowie gegebenenfalls die Steuerung von FHEM-Devices, wird dann komfortabel über die Oberfläche von Babble konfiguriert. An Babble ist im Hintergrund noch der RiveScript-Chatbot angekoppelt, der einen echten Dialog mit dem Nutzer führen kann.
...das ist mir im Moment noch zu hoch, und prinzipiell stellt sich die Frage, über welchen Mechanismus eigentlich "komfortabel konfiguriert" am einfachsten zu bewerkstelligen ist, was die Steuerung von FHEM-Gerät angeht... (Vermutlich brauche ich einen Schnellkurs in Babble?).

ZitatFazit: JA, Rhasspy (und auch das Modul) können prima mit Babble zusammenarbeiten. Das hat den Vorteil, dass die Intents komplett von den Devices getrennt werden können, und die auszuführenden Befehle zentral abgelegt werden können (eben in der Datenstruktur von Babble). Zusammen mit dem an Babble angehängten ChatBot ergeben sich tolle Möglichkeiten  - begrenzt nur durch die Tatsache, dass (bisher) untrainierte Sätze von Rhasspy nicht in Text umgewandelt werden können. In dem obigen Dialogbeispiel ist das bei den Räumen gut ausgeführt: Die relativ wenigen Räume meines Hauses kann ich Rhasspy antrainieren - aber nicht hundertundein Künstlernamen aus meiner Musikbibliothek.

Zur Verbessserung der Zusammenarbeit habe ich oben zwei Feature Requests für das Rhasspy-Modul gepostet. Auf der Seite von Babble wäre ein wichtige Verbesserung, es an MQTT anzubinden - es müsste sowohl textuelle Daten von dort bekommen, als auch textuelle Daten ODER Audiodaten zurückliefern. Ersteres geht ohne Cloud.
Ob Babble MQTT beherschen muss? Es wäre kein Hexenwerk, auf RHASSPY-Seite z.B. über ein rhasspy2Babble-Attribut einstellbar zu machen, dass Babble genutzt werden soll, um dann z.B. jeweils den Roh-Text weiterzugeben oder die Daten irgendwie anders vorverarbeitet/standardisiert zu liefern. Da könnte auch z.B. ein Schlüssel additionalBabbleRooms zu finden sein...

Audiodaten kann RHASSPY heute schon weitergeben, neu wäre nur, das (für ein anderes Modul) im Rahmen einer laufenden Sitzung zu machen, aber dem Bauchgefühl nach müßte das halbwegs stressfrei integrierbar sein.

Nicht erkannte Sentences sind übrigens ein Spezialthema, und sowas wie "GetRoom" gibt es schon als "ChoiceRoom"-Intent. Die Kunst wäre dann nur, für Babble (oder einen Messenger-Dienst) einen abweichenden Ablauf vorzuschalten, falls grade eine Sitzung läuft.

PS: https://wiki.fhem.de/wiki/RHASSPY/Vertiefung ist jetzt halbwegs "fertig", und es sind mir dabei auch noch ein paar Wackler in der commandref aufgefallen. Ich hoffe, irgendwann das mit dem Messenger-Dialog in den Griff zu bekommen, dann kommt wieder ein update.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: dkreutz am 07 Dezember 2021, 17:02:54
Zitat von: Prof. Dr. Peter Henning am 07 Dezember 2021, 15:57:24
Ob mit einer anderen STT-Engine (etwa Mozilla Deep Speech) auch die Rückgabe von Text für untrainierte Sätze möglich ist, muss ich mir noch ansehen.

Mozilla DeepSpeech wird nicht mehr weiter entwickelt. Ein großer Teil des Entwicklerteams hat coqui.ai gegründet und DeepSpeech als Coqui-STT "geforkt". Leider ist das deutschsprachige STT-Modell aber (immer noch) relativ "schlecht" (hohe WER).

Hier habe ich alle verfügbaren STT Modelle evaluiert: https://domcross.github.io/german-stt-evaluation/
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 07 Dezember 2021, 17:29:35
zu 1. Frage:
   Seltsam, bei meinen Rhasspy-Installationen (Debian-Paket) wurde immer eine plughw erkannt. Vielleicht doch nur ein ALSA-Ploblem?
   
zu 2. Beobachtung:
   https://github.com/MycroftAI/mycroft-precise/wiki/Training-your-own-wake-word#demoing-the-model
   
zu 3. Feature Requests für das Modul:
   a) Man konnte schon immer einem Device mehrere Räume zuordnen.
   b) Die Erkennung des Hotwords kann auch vorgetäuscht werden. https://rhasspy.readthedocs.io/en/latest/reference/#hotword-detectionmosquitto_pub -h 192.168.100.1 -p 1883 -t hermes/hotword/alexa/detected -m '{"modelId": "alexa", "modelVersion": "", "modelType": "personal", "currentSensitivity": 0.5, "siteId": "wohnzimmer", "sessionId": null, "sendAudioCaptured": null, "lang": null, "customEntities": null}'

zu 4. Rhasspy und Babble:
   Finde ich super. Hatte mal ein Beispiel zu Talk2Fhem gepostet https://forum.fhem.de/index.php/topic,113180.msg1124227.html#msg1124227 . Deep Speech hatte ich leider nicht recht zum laufen bekommen aber in Rhasspy gibt es den "Open transcription mode" zur freien Texterkennung und  das "Mixed Language Model" zur gewichteten freien Erkennung unter Beachtung der sentences.ini. Für einen echten Dialog ist die Quelle von Rhasspy aber noch nicht bereit. https://forum.fhem.de/index.php/topic,119447.msg1176363.html#msg1176363 , https://community.rhasspy.org/t/lost-in-dialogues-customdata-intentfilter-and-dialoguemanager-configure/2890/14?u=jens-schiffke
   
   Gruß Jens
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 07 Dezember 2021, 17:37:38
Anbei erst mal eine ungetestete Version, mit der man als Tweak auch "extrarooms" zur Verfügung hat, damit pah erst mal weiterarbeiten kann. Mal sehen, wo das letztendlich hinwandert. Ergänzt werden dann (hoffentlich) sowohl rooms wie mainrooms.

Die messenger-Schnittstelle sollte man vorsichtshalber nicht nutzen, aber der Rest dürfte ok sein, und v.a. ist jetzt auch wieder die commandref aktuell...

Was die STT-Engine angeht, bin ich zwar relativ blind, aber im Prinzip ist auch innerhalb des Rhasspy-frameworks ja nicht nur der default drin, sondern man könnte verschiedene nutzen. Stellt sich die Frage, ob das auch "on the fly" ginge.
Weiter ist "voice2json" als Schwesterprojekt ja auf Geschwindigkeit getrimmt, v.a., was das Training im laufenden Betrieb angeht. Evtl. wäre es eine Idee, sich (parallel zu allem anderen) auch mal anzusehen, ob bzw. was damit machbar ist? (Sehe ich aber eher als mittel- bis langfristiges Thema an).

Was das Wakeword-Thema angeht: Prinzipiell stellt sich die Frage, ob man RHASSPY nicht eine siteId zuweisen sollte? In der messenger-Geschichte ist es so vorgesehen, wobei im Moment mein Favorit "<language><fhemId>" ist, die dann aber auf der "Gegenseite" (also in der Regel der Base) freigeschaltet werden muss.

(Generell: alles reichlich kompliziert, auch in der Einrichtung).
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Prof. Dr. Peter Henning am 07 Dezember 2021, 20:00:29
ZitatVielleicht klärst du mich auf, was du damit erreichen willst
Ich will, dass Raumnamen (auch) abstrahiert von Devices angegeben werden können. Mit einem Dummy, der diverse Raumnamen enthält, ist das ja schon getan.

ZitatWenn es so gedacht ist, dass von FHEM aus ein beliebiger Satellit "geöffnet" werden soll, muss der als Argument übergeben werden (und bekannt sein).
Kein Problem, das geht

ZitatMozilla DeepSpeech wird nicht mehr weiter entwickelt. 
Bäh.

ZitatHier habe ich alle verfügbaren STT Modelle evaluiert: https://domcross.github.io/german-stt-evaluation/
Sehr gut.

Zitatzu 1. Frage:
   Seltsam, bei meinen Rhasspy-Installationen (Debian-Paket) wurde immer eine plughw erkannt. Vielleicht doch nur ein ALSA-Ploblem?
Identische Maschine, rhasspy einmal als Docker und einmal als Debian. Ohne Wechsel von SD-Karte oder Audio-Hardware.

Zitat
zu 2. Beobachtung:
   https://github.com/MycroftAI/mycroft-precise/wiki/Training-your-own-wake-word#demoing-the-model
Längst geschehen, als standalone mit precise-listen läuft das sehr gut.
   
Zitatzu 3. Feature Requests für das Modul:
   a) Man konnte schon immer einem Device mehrere Räume zuordnen.
Das war aber nicht gemeint. Sondern eine abstrakte Liste von Räumen

Zitat
   b) Die Erkennung des Hotwords kann auch vorgetäuscht werden
Prima, eines der Probleme gelöst. Muss nur noch herausfinden, ob es eine MQTT-Nachricht gibt, die das Ende von "speak" verkündet. Wenn ich meine Sprachausgabe mit Amazon Polly mache, kann ich immer die Laufzeit der erzeugten MP3-Dateien benutzen.

LG

pah
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 07 Dezember 2021, 20:42:52
Zitat von: Prof. Dr. Peter Henning am 07 Dezember 2021, 20:00:29
Muss nur noch herausfinden, ob es eine MQTT-Nachricht gibt, die das Ende von "speak" verkündet.
hermes/hotword/toggleOn {"siteId": "wohnzimmer", "reason": "ttsSay"}

Gruß Jens
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: dkreutz am 08 Dezember 2021, 08:32:21
Der "Chefentwickler" von Rhasspy (Michael Hansen) ist jetzt hauptberuflich bei Mycroft AI Inc. (der Firma hinter dem Mycroft Voice Assistant) angestellt: https://community.mycroft.ai/t/mycroft-dev-sync-2021-11-29/11562/13
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 08 Dezember 2021, 11:45:41
Weitgehend ungetestetes update:
1. neuer Tweak "extrarooms", damit kein dummy benötigt wird, um "devicelose" Räume zu erzeugen (werden auch in mainrooms gelistet);
2. neuer Setter "activateVoiceInput". Was auf der MQTT-Seite rauskommt, sieht erst mal in etwa so aus wie das Beispiel von JensS, diverse Argumente können entweder benannt oder in der richtigen Reihenfolge übergeben werden, wenn nicht, schustert das Modul was zusammen;
3. noch mehr Room-slots für "treffgenauere" sentences;
4. es müßte neue Readings geben, wenn eine Info über die hermes/hotword/toggle.*-Topics reinkommt (entsprechende subscriptions vorausgesetzt, ungetestet).

Ad 2: Umgesetzt ist der bloße Request, einen passenden publish zu veranlassen; es erfolgt im Moment noch keine Sitzungsverwaltung oder Zwischenspeicherung irgendwelcher Daten, ich kann daher nicht sagen, wer so eine Sitzung ggf. wieder wann zu macht, und insbesondere noch nicht, ob Rhasspy das von sich aus tut.
Die rausgesendete Info landet dann auch wieder im "wakeword"-Event, RHASSPY vergißt also direkt wieder, was RHASSPY wußte. Weiß noch nicht, ob das ein Problem ist, es ist aber m.E. ein Verstoß gegen den Grundsatz, dass MQTT-Geräte nicht auf die von ihnen selbst gesendeten Infos irgendwie reagieren sollten (Schleifengefahr!), deswegen erwähne ich das hier.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 08 Dezember 2021, 19:07:48
Zitat von: Prof. Dr. Peter Henning am 07 Dezember 2021, 15:57:24
2. Beobachtung:
- Derzeit habe ich es noch nicht geschafft, in Docker ein EXTERN trainiertes Modell für die Wakeup-Engine precise zum Laufen zu bekommen. Zwar kann man das Modell (in beiden Installationsversionen) in das richtige Verzeichnis schreiben, es wird dann in Rhasspy auch zur Auswahl angeboten - aber laufen tut es (noch) nicht.

Wird die Wakeword-Engine richtig aufgerufen?ps ax | grep wake
Gruß Jens
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Prof. Dr. Peter Henning am 09 Dezember 2021, 18:31:27
ZitatWird die Wakeword-Engine richtig aufgerufen?
Aber natürlich - genau wie mit anderen Modellen. Habe ich jetzt erstmal zurückgestellt.

Derzeit habe ich erst einmal die andere Richtung ausgebaut, nämlich meine TTS-Ausgaben an Rhasspy angepasst und damit die eher grenzwertigen mitgelieferten TTS-Systeme umgangen. Das geht ganz einfach durch einen externen MQTT2_CLIENT, der den Topic hermes/tts/say abonniert hat.

Die Rückgabe hängt noch, denn Rhasspy erwartet natürlich eine Bestätigung.

Nach der Seite hier: http://192.168.0.115:12101/docs/reference/#tts_sayfinished sollte das mit einem
set SpeakMQTT_CLIENT publish hermes/tts/sayFinished {"id": "f1c1e037-55ee-4af6-bc1b-633c0ba03304", "siteId": "default"}
gehen (die id kommt natürlich aus der Nachricht an den den Client).

Leider akzeptiert Rhasspy das (noch) nicht und geht nach 30 Sekunden in einen Timeout.

LG

pah

Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 09 Dezember 2021, 19:00:04
Da fehlt noch die Session-ID. Scheint auch in der Referenz zu fehlen...
https://docs.snips.ai/reference/hermes#text-to-speech-tts

Gruß Jens

p.s. Ein Beispiel:hermes/hotword/alexa/detected {"modelId": "alexa", "modelVersion": "", "modelType": "personal", "currentSensitivity": 0.5, "siteId": "wohnzimmer", "sessionId": null, "sendAudioCaptured": null, "lang": null, "customEntities": null}
hermes/dialogueManager/sessionStarted {"sessionId": "wohnzimmer-alexa-dcce0c53-2b45-4240-ba93-3748d4e3920e", "siteId": "wohnzimmer", "customData": "alexa", "lang": null}
hermes/hotword/toggleOff {"siteId": "wohnzimmer", "reason": "dialogueSession"}
hermes/hotword/toggleOn {"siteId": "wohnzimmer", "reason": "dialogueSession"}
hermes/nlu/query {"input": "wie spät ist es", "siteId": "wohnzimmer", "id": null, "intentFilter": [], "sessionId": "wohnzimmer-alexa-dcce0c53-2b45-4240-ba93-3748d4e3920e", "wakewordId": "alexa", "lang": null, "customData": "alexa", "asrConfidence": 0.99236121, "customEntities": null}
hermes/nlu/intentParsed {"input": "wie spät ist es", "intent": {"intentName": "de.fhem:GetTime", "confidenceScore": 1.0}, "siteId": "wohnzimmer", "id": null, "slots": [{"entity": "Value", "value": {"kind": "Unknown", "value": "spät"}, "slotName": "Value", "rawValue": "spät", "confidence": 1.0, "range": {"start": 4, "end": 8, "rawStart": 4, "rawEnd": 8}}], "sessionId": "wohnzimmer-alexa-dcce0c53-2b45-4240-ba93-3748d4e3920e"}
hermes/intent/de.fhem:GetTime {"input": "wie spät ist es", "intent": {"intentName": "de.fhem:GetTime", "confidenceScore": 1.0}, "siteId": "wohnzimmer", "id": null, "slots": [{"entity": "Value", "value": {"kind": "Unknown", "value": "spät"}, "slotName": "Value", "rawValue": "spät", "confidence": 1.0, "range": {"start": 4, "end": 8, "rawStart": 4, "rawEnd": 8}}], "sessionId": "wohnzimmer-alexa-dcce0c53-2b45-4240-ba93-3748d4e3920e", "customData": "alexa", "asrTokens": [[{"value": "wie", "confidence": 1.0, "rangeStart": 0, "rangeEnd": 3, "time": null}, {"value": "spät", "confidence": 1.0, "rangeStart": 4, "rangeEnd": 8, "time": null}, {"value": "ist", "confidence": 1.0, "rangeStart": 9, "rangeEnd": 12, "time": null}, {"value": "es", "confidence": 1.0, "rangeStart": 13, "rangeEnd": 15, "time": null}]], "asrConfidence": 0.99236121, "rawInput": "wie spät ist es", "wakewordId": "alexa", "lang": null}
hermes/dialogueManager/endSession {"customData": "alexa","intentFilter": null,"sessionId": "wohnzimmer-alexa-dcce0c53-2b45-4240-ba93-3748d4e3920e","siteId": "wohnzimmer","text": "Es ist 19 Uhr 9"}
hermes/hotword/toggleOff {"siteId": "wohnzimmer", "reason": "ttsSay"}
hermes/tts/say {"text": "Es ist 19 Uhr 9", "siteId": "wohnzimmer", "lang": null, "id": "ebfdc14c-755e-4f5a-a343-e091eec81501", "sessionId": "wohnzimmer-alexa-dcce0c53-2b45-4240-ba93-3748d4e3920e", "volume": null}
hermes/tts/sayFinished {"siteId": "wohnzimmer", "id": "ebfdc14c-755e-4f5a-a343-e091eec81501", "sessionId": "wohnzimmer-alexa-dcce0c53-2b45-4240-ba93-3748d4e3920e"}
hermes/hotword/toggleOn {"siteId": "wohnzimmer", "reason": "ttsSay"}
hermes/dialogueManager/sessionEnded {"termination": {"reason": "nominal"}, "sessionId": "wohnzimmer-alexa-dcce0c53-2b45-4240-ba93-3748d4e3920e", "siteId": "wohnzimmer", "customData": "alexa"}
hermes/hotword/toggleOn {"siteId": "wohnzimmer", "reason": "dialogueSession"}
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Prof. Dr. Peter Henning am 09 Dezember 2021, 19:45:38
Nö, kanns nicht sein. Weder bekomme ich bei hermes/tts/say eine sessionId, noch akzeptiert Rhasspy ein
set ... publish hermes/tts/sayFinished {"id": "8b4937bc-1338-4e3c-b2da-cd977006af7a", "siteId": "default", "sessionId": null}

LG

pah
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 09 Dezember 2021, 19:47:07
Wegen der generischen msgDialog-Schnittstelle habe ich auch etwas mit dem tts-Topic rumgespielt. Weitgehend ungetestetes Zwischenergebnis anbei, für Kommentare fehlt mir grade die Zeit.

RHASSPY braucht wohl eine siteId...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Prof. Dr. Peter Henning am 09 Dezember 2021, 20:22:15
Aber das ist doch drin, mit dem Wert "default" ???

LG

pah
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 10 Dezember 2021, 06:40:28
@pah

Suchst du sowas? https://github.com/hcooper/snips-tts-polly/blob/master/snips-tts-polly.py (https://github.com/hcooper/snips-tts-polly/blob/master/snips-tts-polly.py)

Vielleicht lässt sich im Kontext zu TTS  das Problem des lokalen Echos in hermes/dialogueManager/continueSession (erweiterter Dialog) behandeln. Ein Beispiel...

Ich: Rhasspy, buche ein Zugticket.
Rhasspy: Wohin? Berlin oder Düsseldorf?
Ich: Berlin.
Rhasspy: Wann möchtest du starten?
...

In der Zeit, wenn Rhasspy nachfragt, bleibt das Mikro offen. Sobald die Frage gestellt wurde, springt die SST wieder an. Die Sprachdaten werden vom TTS als RIFF an den Satelliten gesandt.
Dieser muss das dann erstmal verarbeiten und ausgeben, Dabei kommt es zwangsläufig zu Latenzen, welche die SST falsch als Eingabe versteht. Dadurch sind Dialoge extrem fehleranfällig.
Meine Notlösung war ein "Local Command" beim "Local Playing" des Satelliten.#!/bin/bash
amixer -q -c 'seeed2micvoicec' sset Capture 0
cat $1 > /tmp/handy.wav && aplay /tmp/handy.wav
amixer -q -c 'seeed2micvoicec' sset Capture 95



Gruß Jens
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Prof. Dr. Peter Henning am 10 Dezember 2021, 08:14:35
ZitatSuchst du sowas? https://github.com/hcooper/snips-tts-polly/blob/master/snips-tts-polly.py
Nö, danke. Polly funktioniert bei mir seit Jahren auf allen Devices, die Anleitung dazu findet man auch in dem Buch "SmartHome mit FHEM". Ich habe sogar noch die alten Android-Apps mit der Stimme "Marlene", bevor der Hersteller von Amazon geschluckt wurde.

Meine Bose-SoundTouch-Devices oder sonstige Ausgabegeräte (auch Linux-Kisten) bekommen dann ein maßgefertigtes MP3 geliefert, gerne poste ich den Code hier noch einmal.

ZitatVielleicht lässt sich im Kontext zu TTS  das Problem des lokalen Echos in sessionContinue (erweiterter Dialog) behandeln. Ein Beispiel...

Ich: Rhasspy, buche ein Zugticket.
Rhasspy: Wohin? Berlin oder Düsseldorf?
Ich: Berlin.
Rhasspy: Wann möchtest du starten?
Habe ich doch schon gelöst, mit dem ChatBot. Das läuft wirklich.

Das Problem ist, dass die Spracheingabe STT nicht verarbeitet wird, bevor sie abgeschlossen wurde. Also muss man nach der Antwort mit TTS die Spracherkennung neu starten, und aktives Dialogmanagement in FHEM betreiben.

LG

pah
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 10 Dezember 2021, 10:32:35
Anbei ein update zu dem gestrigen Experiment und ein paar Anmerkungen und Vorschläge.

Zitat von: Prof. Dr. Peter Henning am 10 Dezember 2021, 08:14:35
und aktives Dialogmanagement in FHEM betreiben.
Darauf zielte diese Bemerkung:
Zitat von: Beta-User am 09 Dezember 2021, 19:47:07
RHASSPY braucht wohl eine siteId...

Etwas Theorie:
Im Rhasspy-Ökosystem wird vorausgesetzt, dass jeder Teilnehmer (prinzipiell) bekannt ist und "seine" spezifische Rolle spielt. Bisher hatte RHASSPY (fast) keine aktive Rolle in diesem Ökosystem, sondern war nur "passive listener" mit gelegentlichen "Zwischenrufen" (nämlich dann, wenn eine Aktion erfolgreich ausgeführt worden ist oder "speak" bzw. "textCommand" als "one shot"-Aktionen ausgelöst wurden).
Will man Dialoge haben, muss man aktiv ins Geschehen eingreifen, was eben bedeutet, dass jede RHASSPY-Instanz auch eine "Kennung" innerhalb des Rhasspy-Ökosystems braucht, also eine siteId.
Wenn Babble diese Rolle (teilweise) auch spielen soll, gilt hier dasselbe, auch Babble (bzw. jede Instanz) braucht eine eigene siteId.

Deswegen hat RHASSPY ab sofort eine (optional konfigurierbare) siteId (default: "<language><fhemId>").

Für Babble, würde ich "<language><fhemId>.<Babble-Name>" vorschlagen (und hoffe, das wird später klarer, warum).

Bin mit dem Testen noch nicht an diese Stelle gekommen, gehe aber davon aus, dass man diese (und ggf. die von Babble) dann wie andere "normale Satelliten" auch jeweils für die Dienste in der Rhasspy-Weboberfläche registieren muss, die man nutzen will. Damit könnte man z.B. den "Babble-Satelliten" zum TTS-System für beliebige andere Satelliten machen.

Babble muss dazu nur in der Lage sein, das Dialogmanagement zu bedienen.
Meine aktuelle Idee zum Gesamtkonzept wäre nun, dass man
- RHASSPY optional in der DEF mitteilen kann, dass Babble integriert werden soll
- RHASSPY kann dann z.B. seine setter um Babble-spezifische Optionen ergänzen (vorausgesetzt, es gibt z.B. eine Babble-Definition). Das könnte z.B. genutzt werden, um RHASSPY die Anweisung zu geben, für einen bestimmten Satelliten die Info rauszuhauen, dass STT fertig ist.
- RHASSPY greift dann bestimmte (tbd) Messages ab und generiert entweder Events oder reicht das an eine oder mehrere noch zu spezifizierende(n) Schnittstelle(n) bei Babble weiter.
Damit würde quasi RHASSPY als "erweitertes" IO-Modul für Babble genutzt, daher auch der Vorschlag, durch die siteId kenntlich zu machen, dass  RHASSPY und Babble eine Art "Gruppe" sind.

Ein showcase für das dynamische Ergänzen des setters ist mal eingebaut.

Den Vorteil dieser Konstruktion gg. einer separaten MQTT-Anbindung sehe ich darin, dass RHASSPY sowieso in Teilen ein Sitzungsmanagement betreibt, den Traffic mitschneidet bzw. auch auswertet und die notwendigen internen Funktionen schon eingebaut hat, um die MQTT-Schnittstelle von Rhasspy zu beliefern.




Die allgemeine msgDialog-Schnittstelle "zuckt" auch schon, es hakt noch an der Weitergabe an die nlu-Query, aber immerhin kann man (in meinem Fall per Telegram) was an RHASSPY senden und erhält ein "blink" sowie eine "timeout"-Message.

Wer diesen Teil mittesten will, braucht:
- eine msgConfig-Instanz
- einen ROOMMATE oder GUEST, der für msgConfig eingerichtet ist (bei mir war vorher schon ein msgDialog eingerichtet gewesen, im Zweifel muss man erst mal dieser Anleitung bis dahin folgen, dann man darüber ein "hello world" bekommt)
- im RHASSPY-Device:attr rhasspy rhasspyMsgDialog allowed=<Name(n) der ROOMMATE-Instanz>
keepOpenDelay=90

Schickt man dann als zugelassener Teilnehmer ein "hi rhasspy" an FHEM, sollte eine Antwort kommen...

Wie gesagt: die weitere Verarbeitung von danach gesendeten Inhalten klappt noch nicht. Vermutlich ist es keine große Sache, das soweit zu fixen, dass man einfache Anweisungen raushauen kann. Man kann alle Parameter optional ändern, also z.B. das "hi rhasspy" durch "rapunzel lass dein haar herab" ersetzen.

Status: Dieser Teil scheint ungefährlich zu sein.




Prinzipiell stelle ich mir jetzt die Frage, warum es sein muss, dass RHASSPY die Sitzungen standardmäßig schließt, wenn was erkannt wurde. Daher gibt es jetzt den sehr experimentellen Schlüssel "keepOpenDelay" in der DEF. Wer das testen will sei gewarnt: im Code von gestern war eine loop versteckt, die hoffentlich jetzt ausgebaut ist, selbst Testen kann ich aber erst über das WE. (Symptom: rasanter Speicherverbrauch!).Status: Diesen Schlüssel zu aktivieren könnte gefährlich sein!

Bin mal auf eure Rückmeldungen gespannt!
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 10 Dezember 2021, 17:32:19
Zitat von: Prof. Dr. Peter Henning am 10 Dezember 2021, 08:14:35
Nö, danke. Polly funktioniert bei mir seit Jahren auf allen Devices,
Oha, seit Jahren mit Hermes-MQTT? Im Link sind einige Infos zur Reihenfolge der Topics für eine separate TTS versteckt...

Aus Interesse - kannst du bitte einen MQTT-Mitschnitt posten?

Gruß Jens
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Prof. Dr. Peter Henning am 10 Dezember 2021, 18:32:41
ZitatOha, seit Jahren mit Hermes-MQTT?
Nein, das habe ich nicht gesagt.

Sondern per direktem Aufruf und FHEM2FHEM-Kopplung.  Dafür mit anderen Features, z.B. kann ich die vordefinierte Nachricht Nr. 123 einfach in einen Text zum Sprechen einbinden per :123:, und das Caching funktioniert auch gut.

Die MQTT-Anbindung habe ich jetzt erst mit einem MQTT2_CLIENT, einem MQTT2_DEVICE und etwa 10 Zeilen Code realisiert.


LG

pah
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 11 Dezember 2021, 07:19:02
Hallo zusammen,

die msgConfig-Schnittstelle scheint jetzt zumindest prinzipiell mal zu laufen, man kann also mit RHASSPY direkt chatten. Um dann z.B. zu wissen, dass jetzt z.B. "Babble_DoIt()" aufzurufen wäre, wäre es noch ein kleiner Schritt.

activateVoiceInput ist auch getestet und läuft.

Damit auch wieder mehr Leute Anlass haben mitzutesten, gibt es jetzt eine Möglichkeit, mehrere Antworten anzugeben. Das klappt erst mal nur bei den "flachen" Antworten, also da, wo es keine weitere Verzweigung mehr gibt. Alternativen werden mit pipe getrennt, es wird gewürfelt.
Beispiel:
  "responses": {
    "DefaultConfirmation": "Gerne!|schon erledigt|ok|jawohl|stets zu diensten",
    "DefaultError": "Da paßt irgend was nicht|das klappt so nicht"

Im Zweig "inOperation" würde es z.B. (noch) nicht gehen.

Zitat von: Prof. Dr. Peter Henning am 10 Dezember 2021, 18:32:41
Die MQTT-Anbindung habe ich jetzt erst mit einem MQTT2_CLIENT, einem MQTT2_DEVICE und etwa 10 Zeilen Code realisiert.
OK. Sag einfach Bescheid, wenn klarer ist, wie der nächste Schritt aussehen könnte/müßte.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 13 Dezember 2021, 10:48:33
 :) Scheinbar fehlt zu der msgConfig-Geschichte entweder Info oder ein "teaser", oder ist alles klar?

Anbei daher mal ein paar "real-life"-Beispiele als screenshots 8) .

Grundsätzlicher Ablauf ist:
- Es wird eine Sitzung per "open"-Text geöffnet;
- dann kann man alles schreiben, was man auch sagen könnte;
- die (sonst gesprochene) Antwort kommt als Text an den Schreiber zurück;
- dann kann man weitere Anweisungen geben, ...
... bis entweder der timeout nach der letzten eingehenden Message abgelaufen ist, oder der "close"-Text gesendet wird.

Benötigt wird:
- ein msgConfig-Device. Das sorgt dafür, dass eingehende Textnachrichten (hier: von Telegram, das sollte aber mit jedem anderen einbindbaren Messenger-Dienst genauso funktionieren) einem ROOMMATE oder GUEST-Device zugeordnet wird und darüber dann auch wieder der Empfänger für die Antwort ermittelt werden kann;
- die siteId (möglichst: das, was im Internal "siteId" zu finden ist!) der RHASSPY-Instanz muss für die NLU-Funktion bei Rhasspy eingetragen sein;
- alle (zugelassenen) ROOMMATE bzw. GUEST-Devices müssen im "allowed"-key im Attribut "rhasspyMsgDialog" aufgeführt sein. Das ist der einzige zwingende Parameter;
- zu empfehlen ist auch, "keepOpenDelay" im Attribut "rhasspyMsgDialog" zu setzen, sonst schließt RHASSPY die Schnittstelle uU. schneller als man tippen kann...

Eigentlich also total easy (wenn man einen funktionierenden RHASSPY hat), und im Moment bin ich am überlegen, ob es nicht sinnvoll wäre, einen dDT "info" zu erfinden und den "GetState"-Intent etwas aufzubohren, damit man darüber vielleicht
- beliebige Readings abfragen und/oder auch
- update-Anfragen raushauen
kann.
Mein einziger msgDialog befasst(e) sich mit Spritpreisen, und die HTTPMOD-Devices dafür brauchen eigentlich immer erst eine "reread"-Anweisung, weil ich das ganze so selten nutze...

Da das ganze an sich stabil ist und m.E. auch eine sinnvolle Erweiterung darstellt, werde ich die commandref noch etwas überarbeiten und das ganze dann bei Gelegenheit ins svn einchecken...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 13 Dezember 2021, 11:12:30
Zitat von: Beta-User am 13 Dezember 2021, 10:48:33:) Scheinbar fehlt zu der msgConfig-Geschichte entweder Info oder ein "teaser", oder ist alles klar?

Ich versteh nicht ganz, warum ich einem Sprachassistenten Textnachrichten schicken sollte?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 13 Dezember 2021, 11:39:28
Zitat von: drhirn am 13 Dezember 2021, 11:12:30
Ich versteh nicht ganz, warum ich einem Sprachassistenten Textnachrichten schicken sollte?
Gute Frage! Ohne die Babble-Runde wäre ich auch nicht auf den Gedanken gekommen... ;D

Also:
1. Manche Leute diktieren ihre Text-Messages, finden es aber ansonsten total unnötig, mit Computern zu reden ;) . Wenn ich denen jetzt anbiete, mit dem ihnen vertrauten Messenger auch das Licht in ihrem Zimmer ausmachen zu können, werden die vermutlich nicht auf den Gedanken kommen, dass sie grade mit einem Computer geredet haben :P , das feature aber ggf. trotzdem gerne nutzen 8) .

2. RHASSPY etabliert ja so oder so schon einen (optional: mehrsprachigen!) Zwischenlayer, der es erlaubt, von Text auf "Device" zu schließen, im Prinzip beliebige Aktionen auszuführen und passende (flexibel anpassbare) Rückmeldungen zu geben. Die STT- und TTS-Anteile sind dabei nur ein Aspekt, der "Mitteilteil" besteht eigentlich aus Textbausteinen, die auch als solche ausgetauscht werden.
Daher stellte sich plötzlich die Frage, warum man das eigentlich nicht auch ohne die "äußeren" Input/Output-Anteile nutzen sollte? Antwort: Es geht ohne weiteres, also warum eigentlich nicht...

3. Vor längerem habe ich mal mit msgDialog rumexperimentiert. An sich ist das nett, aber relativ aufwändig zu konfigurieren: man muss das händisch für jedes Device/jede Anfrage im msgDialog selbst (JSON-encoded) hinterlegen. Da ist die RHASSPY-Methode (z.B. über GetState), alle "Antwortsätze" direkt im abzufragenden Device zu hinterlegen (oder für bestimmte Typen vorgefertigte Antworten vorzuhalten) sehr viel angenehmer 8) . (Vermutlich habe ich auch noch nicht alle Optionen in msgDialog rausgefunden, kann schon sein, dass da "mehr geht", als das nach meinem halbherzigen Versuch den Eindruck machte, und die Option, Inline-keyboards zu generieren, finde ich eigentlich auch klasse; mal sehen...).

Anders gesagt: Wer seinem FHEM Textnachrichten schicken will, um damit Steuerungsbefehle abzusetzen oder Informationen abzufragen, hat damit eben eine weitere, sehr flexible Option ;) .
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 13 Dezember 2021, 11:57:12
Ist schon ok. Kein Problem damit. Versteh's nur persönlich nicht ;D

Hab das mal mit Talk2FHEM realisiert. Ist auch ein guter Weg. Da ist's dann v.a. egal, ob die Anfrage via Messenger, Sprachassistent oder sonst was kommt.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 13 Dezember 2021, 12:41:15
Talk2FHEM hatte ich auch (im Wiki, nicht im realen FHEM) immer mal wieder angesehen, aber ehrlich gesagt hat mich dann der Wiki-Artikel immer wieder nicht überzeugt. Das sah so ähnlich aus wie meine msgDialog-Versuche: Sehr "statisch"... Man ändert irgendwo den Device-Namen, und schon klemmt es. Nicht gut.
M.E. ist das in etwa so, wie wenn man RHASSPY ohne gDT vergleicht mit RHASSPY mit gDT: Ist einfach eine ganz andere Liga...

Und da das "RHASSPY-de-Layer" eh' da ist, finde ich die Doppelung völlig unnötig :) , zumal es vermutlich verwirrend ist, wenn man für die eine "Bedienweise" bestimmte Begrifflichkeiten hat und für die nächste dann wieder andere (?).

msgConfig ist im Übrigen auch nicht beschränkt auf einen bestimmten "Output-Layer", sondern man kann das dynamisch konfigurieren, und z.B. Sprachausgaben bei Anweisenheit realisieren und Text-Messages bei Abwesenheit ;) . Geantwortet wird nämlich an einen RESIDENT, nicht an ein bestimmtes Gerät 8) .

Schwieriger wird es uU., wenn man die zulässigen Kommandos usw. für verschiedene RESIDENTS beschränken will. Dafür braucht man dann vermutlich unterschiedliche Rhasspy-Services+RHASSPY-Instanzen, aber man kann zumindest den "Sprachschatz" gemeinsam nutzen, wenn man denselben prefix für die Attribut-Namen beibehält... (Das wird alles vermutlich noch "lustig").
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Prof. Dr. Peter Henning am 17 Dezember 2021, 18:26:16
ZitatIch versteh nicht ganz, warum ich einem Sprachassistenten Textnachrichten schicken sollte?
In der nächsten Generation von Messengern wird die STT-Funktion angeboten.

LG

pah

P.S.: Welches ist denn nun die aktuellste Version des RHASSPY-Moduls?

Könnte man die jeweils im ersten Post des Threads hinsetzen, ode rim Github?

Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 18 Dezember 2021, 08:12:09
Habe eben ein update ins svn (contib) geschoben.

Da kann man jetzt u.a. auch
- experimentell einen "sessionTimeout" setzen (umbenannt). Dann macht RHASSPY die Sitzung nicht immer gleich zu. Klappt manchmal, aber wenn irgendwas quer hängt (not recognized), gibt es das bekannte Gestottere, das ganze scheint aber sehr viel besser zu laufen als bisher gewohnt;
- die msgDialog-Schnittstelle ist leicht verbessert, (der sessionTimeout-Parameter ist auch dort umbenannt);
- ich habe einen gDT "info" erfunden, der (wenn alles mal funktioniert) dann dazu dienen soll, beliebige Geräte abfragbar zu machen (man kann sich z.B. vorlesen/zusenden  lassen, was man via stateFormat in einen HTTPMOD geschrieben hat, und einen update anschubsen). Muss aber noch verbessert werden, ist erst mal eine Art preview...

Vor allem:
Es sollten alle Antworten "würfelbar" sein. Dazu einfach alternative Sätze/Antworten per Pipe (|) trennen, ein passendes update für languageFile mit kleinen Beispielen ist auch im svn zu finden (die Struktur ist leicht erweitert wegen der STATE-Abfragen => Neustart erforderlich)

Wie immer würde ich mich über Rückmeldungen freuen (das war die letzte Zeit eher etwas mau), und ggf. Vorschläge zur Code-Verbesserung...

Soweit erst mal die Kurzfassung.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 18 Dezember 2021, 08:36:46
Sei bitte so nett, und häng's auch hier immer an. Damit ich's auf GitHub laden kann.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 18 Dezember 2021, 08:52:50
Zitat von: drhirn am 18 Dezember 2021, 08:36:46
Sei bitte so nett, und häng's auch hier immer an. Damit ich's auf GitHub laden kann.
Bitte schön :) .
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Prof. Dr. Peter Henning am 18 Dezember 2021, 12:24:57
Zitatdas war die letzte Zeit eher etwas mau
Klar. Wenn Du schneller entwickelst, als wir testen können...

LG

pah

P.S.:

Zitat1.PERL WARNING: Use of uninitialized value $siteIds in split at /opt/fhem/FHEM/10_RHASSPY.pm line 3165.
2. Ein Attribut "configFile" gibt es im Modul nicht
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 18 Dezember 2021, 14:07:29
Zitat von: Prof. Dr. Peter Henning am 18 Dezember 2021, 12:24:57
Klar. Wenn Du schneller entwickelst, als wir testen können...
...und teilweise auch schneller, also ich selbst (komplett) testen kann...
Ich fasse das mal als Kompliment auf.

Es waren halt teilweise auch sehr wenige Downloads gewesen für die Testversionen, und das war irritierend, da anders als "früher". Klar, es läuft für die meisten soweit, no need to change. Aber etwas mehr Neugier hätte ich erwartet, auch zu den Doku-Themen.
Zur Klarstellung: Bei @pah und @drhirn habe ich gesehen, wo z.B. was im Wiki passiert ist, an dem ich ablesen kann, wo die Einarbeitung ggf. grade ist bzw. wo unklar ist, für was man bestimmte Optionen überhaupt braucht (weil z.B. durch alte Methoden gelöst).

Das ging also eher in Richtung des Rests...

@pah: speziell interessiert hätte mich vor allem, ob meine Überlegungen zur Messenger-Integration grundsätzlich in die richtige Richtung gehen, oder eher nicht. (Aber auch da: die letzte Rückmeldung wegen der Frage von drhirn hatte ich in diese Richtung als "positiv" bewertet...)

Zitat
1.PERL WARNING: Use of uninitialized value $siteIds in split at /opt/fhem/FHEM/10_RHASSPY.pm line 3165.
2. Ein Attribut "configFile" gibt es im Modul nicht
Ad 1.: Danke für den Hinweis. "Sollte" eigentlich nicht passieren, aber vermutlich muss man in diesem "undefined"-Fall dafür sorgen, dass RHASSPY die siteIds anfordert. Das scheinst du noch nicht gemacht zu haben.

Ad 2.: Es war mal die Überlegung, welchen Namen man für das vergeben sollte, was dann im Internal configFile (für configDB muss das so heißen) zu finden sein soll. "Früher" waren das wirklich nur sprachspezifische Sachen, aber nachdem man darüber auch slots an Rhasspy übergeben kann, wäre fast die Frage, ob man languageFile umbenennt...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Prof. Dr. Peter Henning am 18 Dezember 2021, 18:04:11
Ich bin mit der aktuellen Version des Moduls nicht zufrieden. Wenn ich es installiere, macht das zugehörige MQTT2_DEVICE eine Verbindung zu Rhasspy auf, die alle Audiodaten empfängt. Ich kann zwar autocreate abschalten - aber wer um Himmels Willen braucht denn die ganzen Audioframes? Diese Netzlast will ich eigentlich vermeiden.

LG

pah
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 18 Dezember 2021, 18:15:12
Zitat von: Prof. Dr. Peter Henning am 18 Dezember 2021, 18:04:11
Ich bin mit der aktuellen Version des Moduls nicht zufrieden. Wenn ich es installiere, macht das zugehörige MQTT2_DEVICE eine Verbindung zu Rhasspy auf, die alle Audiodaten empfängt. Ich kann zwar autocreate abschalten - aber wer um Himmels Willen braucht denn die ganzen Audioframes? Diese Netzlast will ich eigentlich vermeiden.

Ähm. Es ist nicht RHASSPY dafür verantwortlich, dass du die Entscheidung getroffen hast, nicht die eingeschränkten subscriptions zu nutzen und den ganzen "Schmodder" mit MQTT2_DEVICE abzugreifen...
(Oder verstehe ich da was falsch?)

Betr. #3156ff würde ich mal folgendes vorschlagen:
        my $siteIds;
        for (keys %{$ref}) {
            next if !defined $ref->{$_}{satellite_site_ids};
            if ($siteIds) {
                $siteIds .= ',' . encode($cp,$ref->{$_}{satellite_site_ids});
            } else {
                $siteIds = encode($cp,$ref->{$_}{satellite_site_ids});
            }
        }
        if ( $siteIds ) {
            my @ids = uniq(split m{,},$siteIds);
            readingsBulkUpdate($hash, 'siteIds', join q{,}, @ids);
        }

(Neu ist eigentlich nur die if-Abfrage am Ende - ich weiß ehrlich gesagt nicht, warum Rhasspy anscheinend komplett leeren Content zurückgibt, oder ich verstehe den Mechanismus noch nicht ganz, kann auch sein.)

@drhirn: Habe versucht, den "Komma"-Konverter in Gang zu bringen (wie jetzt von mir im Wiki für die Theorie hinterlegt). Das klappt aber leider aus irgendeinem Grund nicht, für einen Schubs wäre ich dankbar ::) .
In Python wollte ich mich eigentlich nicht auch noch reinarbeiten ::) und weiß nicht mal, was auf der Murmel an Version verfügbar ist; vielleicht wäre Perl einfacher ;) ...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Prof. Dr. Peter Henning am 18 Dezember 2021, 18:52:10
Zitat
Ähm. Es ist nicht RHASSPY dafür verantwortlich, dass du die Entscheidung getroffen hast, nicht die eingeschränkten subscriptions zu nutzen und den ganzen "Schmodder" mit MQTT2_DEVICE abzugreifen...
(Oder verstehe ich da was falsch?)
Da verstehst Du etwas falsch. ICH habe gar keine Subscriptions ausgeführt - das muss alles aus dem Modul stammen.

LG

pah
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 18 Dezember 2021, 19:13:49
Die Empfehlung ist, subscriptions im M2C auf setByTheProgram zu setzen. Ist das der Fall?

RHASSPY interessiert sich jedenfalls nur für einen Teil der messages, (wenn ich richtig informiert bin...)

M2C steht per default auf "#"...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 19 Dezember 2021, 07:38:18
Anders gesagt:
Die subscriptions, die RHASSPY bei "setByTheProgram" beim M2C anmeldet, sind in @topics (#271ff) zu finden.

Mit
mosquitto_sub -h <server-ip> -p 12183 -v -t +/hotword/+ -t +/intent/# -t +/dialogueManager/# -t +/nlu/# -t +/tts/#
kann man mitlauschen, was RHASSPY so in etwa zu sehen bekommt - und im übrigen dann rausfiltert und nicht (ohne entsprechende Anweisung) an M2D weitergibt...

Jedenfalls bei meinen bisherigen Tests kamen da keine Audio-Frames, sondern nur Text/JSON. Was übersehe ich?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 19 Dezember 2021, 10:16:28
Zitat von: Beta-User am 18 Dezember 2021, 18:15:12
@drhirn: Habe versucht, den "Komma"-Konverter in Gang zu bringen (wie jetzt von mir im Wiki für die Theorie hinterlegt). Das klappt aber leider aus irgendeinem Grund nicht, für einen Schubs wäre ich dankbar ::) .
In Python wollte ich mich eigentlich nicht auch noch reinarbeiten ::) und weiß nicht mal, was auf der Murmel an Version verfügbar ist; vielleicht wäre Perl einfacher ;) ...

Geht er nicht? Bzw. was konkret geht nicht? Schon lange nicht mehr ausprobiert. Und ich komm die nächsten Tage auch nicht dazu. Aber ich behalt's im Hinterkopf.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 19 Dezember 2021, 10:35:38
Also, Langfassung:ls -l /opt/rhasspy/profile/de/converters/customFloat 
-rwxr-xr-- 1 rhasspy rhasspy 154 Dez 18 20:00 /opt/rhasspy/profile/de/converters/customFloat


cat /opt/rhasspy/profile/de/converters/customFloat       
#!/usr/bin/env python3
import sys
import json

# [22, ".", 5]
args = json.load(sys.stdin)

# 22.5
num = "".join(str(s).strip() for s in args)

print(num)


Aktiviere ich diese Zeile in sentences.ini:
<de.fhem:SetOnOff.cmdmulti> [<den>] $de.fhem.Device-thermostat{Device}  [<de.fhem:SetOnOff.rooms>] auf (5..25 [Komma:. (0|5)]){Value!customFloat}] Grad{Unit.degree}

bekomme ich die Meldung eingeblendet:TrainingFailedException: Command '['fstcompile', '--isymbols=/opt/rhasspy/profiles/de/kaldi/model/data/lang/words.txt', '--osymbols=/opt/rhasspy/profiles/de/kaldi/model/data/lang/words.txt', '--keep_isymbols=false', '--keep_osymbols=false', '/opt/rhasspy/profiles/de/kaldi/language_model.txt', '/opt/rhasspy/profiles/de/kaldi/model/data/lang/G.fst.unsorted']' returned non-zero exit status 1.
Ins log habe ich bisher nicht geschaut, deaktiviert man die Zeile läuft alles sauber durch...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 19 Dezember 2021, 10:52:28
Bei dem Satz
(stelle|schalte|mache) $de.fhem.Device-SetNumeric{Device} [$de.fhem.Room{Room}] [um] [(0..30 [komma:. 1..9]){Value!customFloat}] [grad{Unit}] (höher|wärmer){Change:tempUp}
läuft das Training durch. Aber ich bekomm dann einen NLU-Fehler.

Tippe auf Rhasspy. Vielleicht hat sich der Fehler (https://community.rhasspy.org/t/question-about-custom-converters/2167) wieder eingeschlichen. Müssen wir im Rhasspy-Forum klären.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 20 Dezember 2021, 19:35:57
@Beta-User
Habe gerade die letzte Version installiert und bisher keine Klagen. ActiveVoiceInput läuft gut.

Wozu gibt's den extra Konverter customFloat? Geht's nicht mit dem vorhandenen float?

allg. Info: In Bullseye hatte ich bei der Installation von Rhasspy Probleme mit dem abhängigen Paket libgfortran4. https://community.rhasspy.org/t/bullseye-refuses-to-install/3355

Gruß Jens
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 21 Dezember 2021, 06:54:52
Zitat von: JensS am 20 Dezember 2021, 19:35:57
@Beta-User
Habe gerade die letzte Version installiert und bisher keine Klagen. ActiveVoiceInput läuft gut.
8)

Zitat
Wozu gibt's den extra Konverter customFloat? Geht's nicht mit dem vorhandenen float?
Da es im Wiki stand, wollte ich das schlicht ausprobieren und kann nicht sagen, ob "float" das genauso gut kann...
Hatte dann auch die "1...9"-Version ausprobiert, allerdings mit demselben Ergebnis. Wenn wir "customFloat" nicht brauchen, sollte man es aus dem Wiki werfen. @drhirn: Schaust du dir das bei Gelegenheit an?

Zitatallg. Info: In Bullseye hatte ich bei der Installation von Rhasspy Probleme mit dem abhängigen Paket libgfortran4. https://community.rhasspy.org/t/bullseye-refuses-to-install/3355 (https://community.rhasspy.org/t/bullseye-refuses-to-install/3355)
Danke auch für's posten bei Rhasspy, Gisbert hatte ja auch darauf hingewiesen, dass das klappt, wenn man die 4-er Version aus buster holt. Was ich mich allerdings frage: "libgfortran" (?) ist als Meta-Paket doch in beiden drin. Es sollte eigentlich genügen, das zu referenzieren und nicht irgendeine bestimmte Version? (Mindest-Versionsangaben sollten ja möglich sein). Dann wäre dieser wiederkehrende Hackel auch erledigt...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Prof. Dr. Peter Henning am 21 Dezember 2021, 18:31:11
Hat eigentlich jemand eine deutsche Datei für Stopwords erstellt?

LG

pah
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 21 Dezember 2021, 19:25:54
Afaik nicht. stop words (falls https://en.wikipedia.org/wiki/Stop_word gemeint ist) findet sich erst im "Whitepaper": https://rhasspy.readthedocs.io/en/latest/whitepaper/.

Was aber heute schon geht, ist "ignore_unknown_words" generell in fsticuffs zu aktivieren, siehe https://rhasspy.readthedocs.io/en/latest/intent-recognition/#fsticuffs. Kann aber sein, dass das "Nebenwirkungen" hat.

Oder war  gemeint, dass man ein "slot program" für diese Datei erstellt und die passende Variable einfach in sentences.ini verteilt?

Falls es "irgendwo da draußen" eine Datei gibt, könnte man die vermutlich ohne weiteres verwenden, allerdings wäre das vermutlich umständlicher als es sein müßte und eher "lahm" in der Umsetzung/im Training...?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Prof. Dr. Peter Henning am 21 Dezember 2021, 21:24:04
Stand der Forschung (nicht nur bei mir) ist, dass die beste Spracherkennung nicht einfach ein neuronales Netz ist, sondern semantische Aspekte beinhalten muss. Teilweise wird das ja schon dadurch realisiert, dass Begriffe als "Room" etc. interpretiert werden - das kann man aber noch wesentlich weiter treiben.

Google macht das übrigens ebenso.

LG

pah
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 21 Dezember 2021, 22:02:34
Zitat von: rejoe2
What's the best choice for such a "continuous scanario"?
EDIT: Seems the "no one managed" may be just related to the usage of the rhasspy mobile app
...verstehe ich nicht. Der Dialog läuft doch.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 22 Dezember 2021, 10:13:17
Zitat von: Prof. Dr. Peter Henning am 21 Dezember 2021, 21:24:04
Stand der Forschung (nicht nur bei mir) ist, dass die beste Spracherkennung nicht einfach ein neuronales Netz ist, sondern semantische Aspekte beinhalten muss. Teilweise wird das ja schon dadurch realisiert, dass Begriffe als "Room" etc. interpretiert werden - das kann man aber noch wesentlich weiter treiben.

Google macht das übrigens ebenso.
Bin am Rätseln, was das in Bezug auf das Modul bedeuten soll.

Falls das eher in Richtung Rhasspy geht: Auf der Rhasspy-Seite scheint es "an sich" kein Problem zu sein, einfach den STT service zu wechseln und/oder einfach was externes zu nutzen. So verstand ich z.B. diesen Thread: https://community.rhasspy.org/t/vosk-coqui-stt-asrs-integration/2848 (https://community.rhasspy.org/t/vosk-coqui-stt-asrs-integration/2848)

Zitat von: JensS am 21 Dezember 2021, 22:02:34
...verstehe ich nicht. Der Dialog läuft doch.
...jein...
Vorab bin ich nicht sicher, ob wir über dassselbe reden: Mir geht es nicht um den "welches Schweinderl hättens dennn gerne"-Dialog, wenn RHASSPY mehrere Optionen erkennt (das funktioniert in der Tat recht gut), sondern darum, wie RHASSPY/Rhasspy interagiert, wenn man in der DEF sessionTimeout setzt (z.B. auf 15). Dann macht RHASSPY den Dialog nicht direkt zu, sondern wartet, ob nicht der User eine weitere Anweisung erteilt. Auch das klappt prinzipiell, aber eben nicht immer.
Dann kommt es (Testumgebung immer: rhasspy mobile app) zu den bekannten "Stottereien", die sich schlimmstenfalls nur noch dadurch beenden lassen, dass man die App komplett schließt. Dazwischen poppen diese "no one managed..."-Meldungen auf, von denen ich zwischenzeitlich annehme, dass die durch die App generiert werden. Zunächst war ich davon ausgegangen, dass die von Rhasspy (Dialog Manager?) verursacht würden.

Hast du diese Option bereits getestet? Und: Läuft das bei dir gut (wenn ja: welche Umgebungsbedingungen?)

PS: Man kann das "Dialogverhalten" "on the fly" auch ändern, indem man passende sessionTimeout-Readings (pro siteId) setzt.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 22 Dezember 2021, 16:14:12
Sorry, hab immer noch nicht kapiert worum es genau geht - ein MQTT-Mitschnitt einer solchen Stotterei wäre interessant.
Die Timeout-Option habe ich noch nicht genutzt und in der Referenz auch nicht gesehen.
Hier ein WIKI-Dialog - ganz ohne Stotterei:mosquitto_sub -h 192.168.100.1 -p 1883 -v -t hermes/dialogueManager/# -t hermes/hotword/# -t hermes/intent/# -t hermes/nlu/# -t hermes/tts/#
hermes/hotword/alexa/detected {"modelId": "alexa", "modelVersion": "", "modelType": "personal", "currentSensitivity": 0.5, "siteId": "wohnzimmer", "sessionId": null, "sendAudioCaptured": null, "lang": null, "customEntities": null}
hermes/dialogueManager/sessionStarted {"sessionId": "wohnzimmer-alexa-27a31494-5fd0-40d9-9321-bac52cb18d44", "siteId": "wohnzimmer", "customData": "alexa", "lang": null}
hermes/hotword/toggleOff {"siteId": "wohnzimmer", "reason": "dialogueSession"}
hermes/hotword/toggleOn {"siteId": "wohnzimmer", "reason": "dialogueSession"}
hermes/nlu/query {"input": "bitte schlage in der wikipdia nach", "siteId": "wohnzimmer", "id": null, "intentFilter": ["de.fhem:SetMute", "de.fhem:Witze", "de.fhem:GetOnOff", "de.fhem:Fernsehprogramm", "de.fhem:ViomiRhasspy", "de.fhem:WIKI", "de.fhem:Wikipedia", "de.fhem:SetOnOff", "de.fhem:Respeak", "de.fhem:Wetter", "de.fhem:GetWeekday", "de.fhem:SetColor", "de.fhem:GetNumeric", "de.fhem:RhasspySetTimer", "de.fhem:GetAllOff", "de.fhem:SetAllOff", "de.fhem:Shortcuts", "de.fhem:MediaControls", "de.fhem:SetNumeric", "de.fhem:SetAllOn", "de.fhem:GetTime", "de.fhem:RhasspyGetTimer", "de.fhem:Status"], "sessionId": "wohnzimmer-alexa-27a31494-5fd0-40d9-9321-bac52cb18d44", "wakewordId": "alexa", "lang": null, "customData": "alexa", "asrConfidence": 0.99866271, "customEntities": null}
hermes/nlu/intentParsed {"input": "bitte schlage in der Wikipdia nach", "intent": {"intentName": "de.fhem:WIKI", "confidenceScore": 1.0}, "siteId": "wohnzimmer", "id": null, "slots": [], "sessionId": "wohnzimmer-alexa-27a31494-5fd0-40d9-9321-bac52cb18d44"}
hermes/intent/de.fhem:WIKI {"input": "bitte schlage in der Wikipdia nach", "intent": {"intentName": "de.fhem:WIKI", "confidenceScore": 1.0}, "siteId": "wohnzimmer", "id": null, "slots": [], "sessionId": "wohnzimmer-alexa-27a31494-5fd0-40d9-9321-bac52cb18d44", "customData": "alexa", "asrTokens": [[{"value": "bitte", "confidence": 1.0, "rangeStart": 0, "rangeEnd": 5, "time": null}, {"value": "schlage", "confidence": 1.0, "rangeStart": 6, "rangeEnd": 13, "time": null}, {"value": "in", "confidence": 1.0, "rangeStart": 14, "rangeEnd": 16, "time": null}, {"value": "der", "confidence": 1.0, "rangeStart": 17, "rangeEnd": 20, "time": null}, {"value": "Wikipdia", "confidence": 1.0, "rangeStart": 21, "rangeEnd": 29, "time": null}, {"value": "nach", "confidence": 1.0, "rangeStart": 30, "rangeEnd": 34, "time": null}]], "asrConfidence": 0.99866271, "rawInput": "bitte schlage in der wikipdia nach", "wakewordId": "alexa", "lang": null}
hermes/dialogueManager/continueSession {"customData": "WIKI de.fhem:ABC ","intentFilter":["de.fhem:ABC"],"sendIntentNotRecognized": true,"sessionId": "wohnzimmer-alexa-27a31494-5fd0-40d9-9321-bac52cb18d44","siteId": "wohnzimmer","text": "bitte buchstabiere"}
hermes/hotword/toggleOff {"siteId": "wohnzimmer", "reason": "dialogueSession"}
hermes/hotword/toggleOff {"siteId": "wohnzimmer", "reason": "ttsSay"}
hermes/tts/say {"text": "bitte buchstabiere", "siteId": "wohnzimmer", "lang": null, "id": "186c6510-a97d-4f57-9323-a4ce83190a0b", "sessionId": "wohnzimmer-alexa-27a31494-5fd0-40d9-9321-bac52cb18d44", "volume": null}
hermes/tts/sayFinished {"siteId": "wohnzimmer", "id": "186c6510-a97d-4f57-9323-a4ce83190a0b", "sessionId": "wohnzimmer-alexa-27a31494-5fd0-40d9-9321-bac52cb18d44"}
hermes/hotword/toggleOn {"siteId": "wohnzimmer", "reason": "ttsSay"}
hermes/hotword/toggleOn {"siteId": "wohnzimmer", "reason": "dialogueSession"}
hermes/nlu/query {"input": "emil", "siteId": "wohnzimmer", "id": null, "intentFilter": ["de.fhem:ABC"], "sessionId": "wohnzimmer-alexa-27a31494-5fd0-40d9-9321-bac52cb18d44", "wakewordId": "alexa", "lang": null, "customData": "WIKI de.fhem:ABC ", "asrConfidence": 0.9836987, "customEntities": null}
hermes/nlu/intentParsed {"input": "e", "intent": {"intentName": "de.fhem:ABC", "confidenceScore": 1.0}, "siteId": "wohnzimmer", "id": null, "slots": [{"entity": "de.fhem.ABC", "value": {"kind": "Unknown", "value": "e"}, "slotName": "Ch", "rawValue": "emil", "confidence": 1.0, "range": {"start": 0, "end": 1, "rawStart": 0, "rawEnd": 4}}], "sessionId": "wohnzimmer-alexa-27a31494-5fd0-40d9-9321-bac52cb18d44"}
hermes/intent/de.fhem:ABC {"input": "e", "intent": {"intentName": "de.fhem:ABC", "confidenceScore": 1.0}, "siteId": "wohnzimmer", "id": null, "slots": [{"entity": "de.fhem.ABC", "value": {"kind": "Unknown", "value": "e"}, "slotName": "Ch", "rawValue": "emil", "confidence": 1.0, "range": {"start": 0, "end": 1, "rawStart": 0, "rawEnd": 4}}], "sessionId": "wohnzimmer-alexa-27a31494-5fd0-40d9-9321-bac52cb18d44", "customData": "WIKI de.fhem:ABC ", "asrTokens": [[{"value": "e", "confidence": 1.0, "rangeStart": 0, "rangeEnd": 1, "time": null}]], "asrConfidence": 0.9836987, "rawInput": "emil", "wakewordId": "alexa", "lang": null}
hermes/dialogueManager/continueSession {"customData": "WIKI de.fhem:ABC e","intentFilter":["de.fhem:ABC"],"sendIntentNotRecognized": true,"sessionId": "wohnzimmer-alexa-27a31494-5fd0-40d9-9321-bac52cb18d44","siteId": "wohnzimmer","text": "e"}
hermes/hotword/toggleOff {"siteId": "wohnzimmer", "reason": "dialogueSession"}
hermes/hotword/toggleOff {"siteId": "wohnzimmer", "reason": "ttsSay"}
hermes/tts/say {"text": "e", "siteId": "wohnzimmer", "lang": null, "id": "9dfb0b11-a867-42ec-bad4-e8ae7f52c13f", "sessionId": "wohnzimmer-alexa-27a31494-5fd0-40d9-9321-bac52cb18d44", "volume": null}
hermes/tts/sayFinished {"siteId": "wohnzimmer", "id": "9dfb0b11-a867-42ec-bad4-e8ae7f52c13f", "sessionId": "wohnzimmer-alexa-27a31494-5fd0-40d9-9321-bac52cb18d44"}
hermes/hotword/toggleOn {"siteId": "wohnzimmer", "reason": "ttsSay"}
hermes/hotword/toggleOn {"siteId": "wohnzimmer", "reason": "dialogueSession"}
hermes/nlu/query {"input": "ida", "siteId": "wohnzimmer", "id": null, "intentFilter": ["de.fhem:ABC"], "sessionId": "wohnzimmer-alexa-27a31494-5fd0-40d9-9321-bac52cb18d44", "wakewordId": "alexa", "lang": null, "customData": "WIKI de.fhem:ABC e", "asrConfidence": 0.9393692, "customEntities": null}
hermes/nlu/intentParsed {"input": "i", "intent": {"intentName": "de.fhem:ABC", "confidenceScore": 1.0}, "siteId": "wohnzimmer", "id": null, "slots": [{"entity": "de.fhem.ABC", "value": {"kind": "Unknown", "value": "i"}, "slotName": "Ch", "rawValue": "ida", "confidence": 1.0, "range": {"start": 0, "end": 1, "rawStart": 0, "rawEnd": 3}}], "sessionId": "wohnzimmer-alexa-27a31494-5fd0-40d9-9321-bac52cb18d44"}
hermes/intent/de.fhem:ABC {"input": "i", "intent": {"intentName": "de.fhem:ABC", "confidenceScore": 1.0}, "siteId": "wohnzimmer", "id": null, "slots": [{"entity": "de.fhem.ABC", "value": {"kind": "Unknown", "value": "i"}, "slotName": "Ch", "rawValue": "ida", "confidence": 1.0, "range": {"start": 0, "end": 1, "rawStart": 0, "rawEnd": 3}}], "sessionId": "wohnzimmer-alexa-27a31494-5fd0-40d9-9321-bac52cb18d44", "customData": "WIKI de.fhem:ABC e", "asrTokens": [[{"value": "i", "confidence": 1.0, "rangeStart": 0, "rangeEnd": 1, "time": null}]], "asrConfidence": 0.9393692, "rawInput": "ida", "wakewordId": "alexa", "lang": null}
hermes/dialogueManager/continueSession {"customData": "WIKI de.fhem:ABC ei","intentFilter":["de.fhem:ABC"],"sendIntentNotRecognized": true,"sessionId": "wohnzimmer-alexa-27a31494-5fd0-40d9-9321-bac52cb18d44","siteId": "wohnzimmer","text": "i"}
hermes/hotword/toggleOff {"siteId": "wohnzimmer", "reason": "dialogueSession"}
hermes/hotword/toggleOff {"siteId": "wohnzimmer", "reason": "ttsSay"}
hermes/tts/say {"text": "i", "siteId": "wohnzimmer", "lang": null, "id": "92472fd1-0c49-4eb6-8373-9e576c0542bd", "sessionId": "wohnzimmer-alexa-27a31494-5fd0-40d9-9321-bac52cb18d44", "volume": null}
hermes/tts/sayFinished {"siteId": "wohnzimmer", "id": "92472fd1-0c49-4eb6-8373-9e576c0542bd", "sessionId": "wohnzimmer-alexa-27a31494-5fd0-40d9-9321-bac52cb18d44"}
hermes/hotword/toggleOn {"siteId": "wohnzimmer", "reason": "ttsSay"}
hermes/hotword/toggleOn {"siteId": "wohnzimmer", "reason": "dialogueSession"}
hermes/nlu/query {"input": "nordpol", "siteId": "wohnzimmer", "id": null, "intentFilter": ["de.fhem:ABC"], "sessionId": "wohnzimmer-alexa-27a31494-5fd0-40d9-9321-bac52cb18d44", "wakewordId": "alexa", "lang": null, "customData": "WIKI de.fhem:ABC ei", "asrConfidence": 1.0, "customEntities": null}
hermes/nlu/intentParsed {"input": "n", "intent": {"intentName": "de.fhem:ABC", "confidenceScore": 1.0}, "siteId": "wohnzimmer", "id": null, "slots": [{"entity": "de.fhem.ABC", "value": {"kind": "Unknown", "value": "n"}, "slotName": "Ch", "rawValue": "nordpol", "confidence": 1.0, "range": {"start": 0, "end": 1, "rawStart": 0, "rawEnd": 7}}], "sessionId": "wohnzimmer-alexa-27a31494-5fd0-40d9-9321-bac52cb18d44"}
hermes/intent/de.fhem:ABC {"input": "n", "intent": {"intentName": "de.fhem:ABC", "confidenceScore": 1.0}, "siteId": "wohnzimmer", "id": null, "slots": [{"entity": "de.fhem.ABC", "value": {"kind": "Unknown", "value": "n"}, "slotName": "Ch", "rawValue": "nordpol", "confidence": 1.0, "range": {"start": 0, "end": 1, "rawStart": 0, "rawEnd": 7}}], "sessionId": "wohnzimmer-alexa-27a31494-5fd0-40d9-9321-bac52cb18d44", "customData": "WIKI de.fhem:ABC ei", "asrTokens": [[{"value": "n", "confidence": 1.0, "rangeStart": 0, "rangeEnd": 1, "time": null}]], "asrConfidence": 1.0, "rawInput": "nordpol", "wakewordId": "alexa", "lang": null}
hermes/dialogueManager/continueSession {"customData": "WIKI de.fhem:ABC ein","intentFilter":["de.fhem:ABC"],"sendIntentNotRecognized": true,"sessionId": "wohnzimmer-alexa-27a31494-5fd0-40d9-9321-bac52cb18d44","siteId": "wohnzimmer","text": "n"}
hermes/hotword/toggleOff {"siteId": "wohnzimmer", "reason": "dialogueSession"}
hermes/hotword/toggleOff {"siteId": "wohnzimmer", "reason": "ttsSay"}
hermes/tts/say {"text": "n", "siteId": "wohnzimmer", "lang": null, "id": "c6d09f7d-c7fd-4094-9d35-218f893be873", "sessionId": "wohnzimmer-alexa-27a31494-5fd0-40d9-9321-bac52cb18d44", "volume": null}
hermes/tts/sayFinished {"siteId": "wohnzimmer", "id": "c6d09f7d-c7fd-4094-9d35-218f893be873", "sessionId": "wohnzimmer-alexa-27a31494-5fd0-40d9-9321-bac52cb18d44"}
hermes/hotword/toggleOn {"siteId": "wohnzimmer", "reason": "ttsSay"}
hermes/hotword/toggleOn {"siteId": "wohnzimmer", "reason": "dialogueSession"}
hermes/nlu/query {"input": "berta", "siteId": "wohnzimmer", "id": null, "intentFilter": ["de.fhem:ABC"], "sessionId": "wohnzimmer-alexa-27a31494-5fd0-40d9-9321-bac52cb18d44", "wakewordId": "alexa", "lang": null, "customData": "WIKI de.fhem:ABC ein", "asrConfidence": 1.0, "customEntities": null}
hermes/nlu/intentParsed {"input": "b", "intent": {"intentName": "de.fhem:ABC", "confidenceScore": 1.0}, "siteId": "wohnzimmer", "id": null, "slots": [{"entity": "de.fhem.ABC", "value": {"kind": "Unknown", "value": "b"}, "slotName": "Ch", "rawValue": "berta", "confidence": 1.0, "range": {"start": 0, "end": 1, "rawStart": 0, "rawEnd": 5}}], "sessionId": "wohnzimmer-alexa-27a31494-5fd0-40d9-9321-bac52cb18d44"}
hermes/intent/de.fhem:ABC {"input": "b", "intent": {"intentName": "de.fhem:ABC", "confidenceScore": 1.0}, "siteId": "wohnzimmer", "id": null, "slots": [{"entity": "de.fhem.ABC", "value": {"kind": "Unknown", "value": "b"}, "slotName": "Ch", "rawValue": "berta", "confidence": 1.0, "range": {"start": 0, "end": 1, "rawStart": 0, "rawEnd": 5}}], "sessionId": "wohnzimmer-alexa-27a31494-5fd0-40d9-9321-bac52cb18d44", "customData": "WIKI de.fhem:ABC ein", "asrTokens": [[{"value": "b", "confidence": 1.0, "rangeStart": 0, "rangeEnd": 1, "time": null}]], "asrConfidence": 1.0, "rawInput": "berta", "wakewordId": "alexa", "lang": null}
hermes/dialogueManager/continueSession {"customData": "WIKI de.fhem:ABC einb","intentFilter":["de.fhem:ABC"],"sendIntentNotRecognized": true,"sessionId": "wohnzimmer-alexa-27a31494-5fd0-40d9-9321-bac52cb18d44","siteId": "wohnzimmer","text": "b"}
hermes/hotword/toggleOff {"siteId": "wohnzimmer", "reason": "dialogueSession"}
hermes/hotword/toggleOff {"siteId": "wohnzimmer", "reason": "ttsSay"}
hermes/tts/say {"text": "b", "siteId": "wohnzimmer", "lang": null, "id": "fa5dc6b1-d35f-4401-b88a-c28f04967738", "sessionId": "wohnzimmer-alexa-27a31494-5fd0-40d9-9321-bac52cb18d44", "volume": null}
hermes/tts/sayFinished {"siteId": "wohnzimmer", "id": "fa5dc6b1-d35f-4401-b88a-c28f04967738", "sessionId": "wohnzimmer-alexa-27a31494-5fd0-40d9-9321-bac52cb18d44"}
hermes/hotword/toggleOn {"siteId": "wohnzimmer", "reason": "ttsSay"}
hermes/hotword/toggleOn {"siteId": "wohnzimmer", "reason": "dialogueSession"}
hermes/nlu/query {"input": "ludwig", "siteId": "wohnzimmer", "id": null, "intentFilter": ["de.fhem:ABC"], "sessionId": "wohnzimmer-alexa-27a31494-5fd0-40d9-9321-bac52cb18d44", "wakewordId": "alexa", "lang": null, "customData": "WIKI de.fhem:ABC einb", "asrConfidence": 1.0, "customEntities": null}
hermes/nlu/intentParsed {"input": "l", "intent": {"intentName": "de.fhem:ABC", "confidenceScore": 1.0}, "siteId": "wohnzimmer", "id": null, "slots": [{"entity": "de.fhem.ABC", "value": {"kind": "Unknown", "value": "l"}, "slotName": "Ch", "rawValue": "ludwig", "confidence": 1.0, "range": {"start": 0, "end": 1, "rawStart": 0, "rawEnd": 6}}], "sessionId": "wohnzimmer-alexa-27a31494-5fd0-40d9-9321-bac52cb18d44"}
hermes/intent/de.fhem:ABC {"input": "l", "intent": {"intentName": "de.fhem:ABC", "confidenceScore": 1.0}, "siteId": "wohnzimmer", "id": null, "slots": [{"entity": "de.fhem.ABC", "value": {"kind": "Unknown", "value": "l"}, "slotName": "Ch", "rawValue": "ludwig", "confidence": 1.0, "range": {"start": 0, "end": 1, "rawStart": 0, "rawEnd": 6}}], "sessionId": "wohnzimmer-alexa-27a31494-5fd0-40d9-9321-bac52cb18d44", "customData": "WIKI de.fhem:ABC einb", "asrTokens": [[{"value": "l", "confidence": 1.0, "rangeStart": 0, "rangeEnd": 1, "time": null}]], "asrConfidence": 1.0, "rawInput": "ludwig", "wakewordId": "alexa", "lang": null}
hermes/dialogueManager/continueSession {"customData": "WIKI de.fhem:ABC einbl","intentFilter":["de.fhem:ABC"],"sendIntentNotRecognized": true,"sessionId": "wohnzimmer-alexa-27a31494-5fd0-40d9-9321-bac52cb18d44","siteId": "wohnzimmer","text": "l"}
hermes/hotword/toggleOff {"siteId": "wohnzimmer", "reason": "dialogueSession"}
hermes/hotword/toggleOff {"siteId": "wohnzimmer", "reason": "ttsSay"}
hermes/tts/say {"text": "l", "siteId": "wohnzimmer", "lang": null, "id": "ecb4b1fd-f5fc-4de2-a073-57c47f5902de", "sessionId": "wohnzimmer-alexa-27a31494-5fd0-40d9-9321-bac52cb18d44", "volume": null}
hermes/tts/sayFinished {"siteId": "wohnzimmer", "id": "ecb4b1fd-f5fc-4de2-a073-57c47f5902de", "sessionId": "wohnzimmer-alexa-27a31494-5fd0-40d9-9321-bac52cb18d44"}
hermes/hotword/toggleOn {"siteId": "wohnzimmer", "reason": "ttsSay"}
hermes/hotword/toggleOn {"siteId": "wohnzimmer", "reason": "dialogueSession"}
hermes/nlu/query {"input": "a wie anton", "siteId": "wohnzimmer", "id": null, "intentFilter": ["de.fhem:ABC"], "sessionId": "wohnzimmer-alexa-27a31494-5fd0-40d9-9321-bac52cb18d44", "wakewordId": "alexa", "lang": null, "customData": "WIKI de.fhem:ABC einbl", "asrConfidence": 0.6799470000000001, "customEntities": null}
hermes/nlu/intentParsed {"input": "a", "intent": {"intentName": "de.fhem:ABC", "confidenceScore": 1.0}, "siteId": "wohnzimmer", "id": null, "slots": [{"entity": "de.fhem.ABC", "value": {"kind": "Unknown", "value": "a"}, "slotName": "Ch", "rawValue": "a wie anton", "confidence": 1.0, "range": {"start": 0, "end": 1, "rawStart": 0, "rawEnd": 11}}], "sessionId": "wohnzimmer-alexa-27a31494-5fd0-40d9-9321-bac52cb18d44"}
hermes/intent/de.fhem:ABC {"input": "a", "intent": {"intentName": "de.fhem:ABC", "confidenceScore": 1.0}, "siteId": "wohnzimmer", "id": null, "slots": [{"entity": "de.fhem.ABC", "value": {"kind": "Unknown", "value": "a"}, "slotName": "Ch", "rawValue": "a wie anton", "confidence": 1.0, "range": {"start": 0, "end": 1, "rawStart": 0, "rawEnd": 11}}], "sessionId": "wohnzimmer-alexa-27a31494-5fd0-40d9-9321-bac52cb18d44", "customData": "WIKI de.fhem:ABC einbl", "asrTokens": [[{"value": "a", "confidence": 1.0, "rangeStart": 0, "rangeEnd": 1, "time": null}]], "asrConfidence": 0.6799470000000001, "rawInput": "a wie anton", "wakewordId": "alexa", "lang": null}
hermes/dialogueManager/continueSession {"customData": "WIKI de.fhem:ABC einbla","intentFilter":["de.fhem:ABC"],"sendIntentNotRecognized": true,"sessionId": "wohnzimmer-alexa-27a31494-5fd0-40d9-9321-bac52cb18d44","siteId": "wohnzimmer","text": "a"}
hermes/hotword/toggleOff {"siteId": "wohnzimmer", "reason": "dialogueSession"}
hermes/hotword/toggleOff {"siteId": "wohnzimmer", "reason": "ttsSay"}
hermes/tts/say {"text": "a", "siteId": "wohnzimmer", "lang": null, "id": "ab269f30-94c0-47eb-a06f-b4c6a7dce4ee", "sessionId": "wohnzimmer-alexa-27a31494-5fd0-40d9-9321-bac52cb18d44", "volume": null}
hermes/tts/sayFinished {"siteId": "wohnzimmer", "id": "ab269f30-94c0-47eb-a06f-b4c6a7dce4ee", "sessionId": "wohnzimmer-alexa-27a31494-5fd0-40d9-9321-bac52cb18d44"}
hermes/hotword/toggleOn {"siteId": "wohnzimmer", "reason": "ttsSay"}
hermes/hotword/toggleOn {"siteId": "wohnzimmer", "reason": "dialogueSession"}
hermes/nlu/query {"input": "theodor", "siteId": "wohnzimmer", "id": null, "intentFilter": ["de.fhem:ABC"], "sessionId": "wohnzimmer-alexa-27a31494-5fd0-40d9-9321-bac52cb18d44", "wakewordId": "alexa", "lang": null, "customData": "WIKI de.fhem:ABC einbla", "asrConfidence": 0.8039350000000001, "customEntities": null}
hermes/nlu/intentParsed {"input": "t", "intent": {"intentName": "de.fhem:ABC", "confidenceScore": 1.0}, "siteId": "wohnzimmer", "id": null, "slots": [{"entity": "de.fhem.ABC", "value": {"kind": "Unknown", "value": "t"}, "slotName": "Ch", "rawValue": "theodor", "confidence": 1.0, "range": {"start": 0, "end": 1, "rawStart": 0, "rawEnd": 7}}], "sessionId": "wohnzimmer-alexa-27a31494-5fd0-40d9-9321-bac52cb18d44"}
hermes/intent/de.fhem:ABC {"input": "t", "intent": {"intentName": "de.fhem:ABC", "confidenceScore": 1.0}, "siteId": "wohnzimmer", "id": null, "slots": [{"entity": "de.fhem.ABC", "value": {"kind": "Unknown", "value": "t"}, "slotName": "Ch", "rawValue": "theodor", "confidence": 1.0, "range": {"start": 0, "end": 1, "rawStart": 0, "rawEnd": 7}}], "sessionId": "wohnzimmer-alexa-27a31494-5fd0-40d9-9321-bac52cb18d44", "customData": "WIKI de.fhem:ABC einbla", "asrTokens": [[{"value": "t", "confidence": 1.0, "rangeStart": 0, "rangeEnd": 1, "time": null}]], "asrConfidence": 0.8039350000000001, "rawInput": "theodor", "wakewordId": "alexa", "lang": null}
hermes/dialogueManager/continueSession {"customData": "WIKI de.fhem:ABC einblat","intentFilter":["de.fhem:ABC"],"sendIntentNotRecognized": true,"sessionId": "wohnzimmer-alexa-27a31494-5fd0-40d9-9321-bac52cb18d44","siteId": "wohnzimmer","text": "t"}
hermes/hotword/toggleOff {"siteId": "wohnzimmer", "reason": "dialogueSession"}
hermes/hotword/toggleOff {"siteId": "wohnzimmer", "reason": "ttsSay"}
hermes/tts/say {"text": "t", "siteId": "wohnzimmer", "lang": null, "id": "533d6e0a-4de5-4295-8824-94906a1bdb71", "sessionId": "wohnzimmer-alexa-27a31494-5fd0-40d9-9321-bac52cb18d44", "volume": null}
hermes/tts/sayFinished {"siteId": "wohnzimmer", "id": "533d6e0a-4de5-4295-8824-94906a1bdb71", "sessionId": "wohnzimmer-alexa-27a31494-5fd0-40d9-9321-bac52cb18d44"}
hermes/hotword/toggleOn {"siteId": "wohnzimmer", "reason": "ttsSay"}
hermes/hotword/toggleOn {"siteId": "wohnzimmer", "reason": "dialogueSession"}
hermes/nlu/query {"input": "theodor", "siteId": "wohnzimmer", "id": null, "intentFilter": ["de.fhem:ABC"], "sessionId": "wohnzimmer-alexa-27a31494-5fd0-40d9-9321-bac52cb18d44", "wakewordId": "alexa", "lang": null, "customData": "WIKI de.fhem:ABC einblat", "asrConfidence": 1.0, "customEntities": null}
hermes/nlu/intentParsed {"input": "t", "intent": {"intentName": "de.fhem:ABC", "confidenceScore": 1.0}, "siteId": "wohnzimmer", "id": null, "slots": [{"entity": "de.fhem.ABC", "value": {"kind": "Unknown", "value": "t"}, "slotName": "Ch", "rawValue": "theodor", "confidence": 1.0, "range": {"start": 0, "end": 1, "rawStart": 0, "rawEnd": 7}}], "sessionId": "wohnzimmer-alexa-27a31494-5fd0-40d9-9321-bac52cb18d44"}
hermes/intent/de.fhem:ABC {"input": "t", "intent": {"intentName": "de.fhem:ABC", "confidenceScore": 1.0}, "siteId": "wohnzimmer", "id": null, "slots": [{"entity": "de.fhem.ABC", "value": {"kind": "Unknown", "value": "t"}, "slotName": "Ch", "rawValue": "theodor", "confidence": 1.0, "range": {"start": 0, "end": 1, "rawStart": 0, "rawEnd": 7}}], "sessionId": "wohnzimmer-alexa-27a31494-5fd0-40d9-9321-bac52cb18d44", "customData": "WIKI de.fhem:ABC einblat", "asrTokens": [[{"value": "t", "confidence": 1.0, "rangeStart": 0, "rangeEnd": 1, "time": null}]], "asrConfidence": 1.0, "rawInput": "theodor", "wakewordId": "alexa", "lang": null}
hermes/dialogueManager/continueSession {"customData": "WIKI de.fhem:ABC einblatt","intentFilter":["de.fhem:ABC"],"sendIntentNotRecognized": true,"sessionId": "wohnzimmer-alexa-27a31494-5fd0-40d9-9321-bac52cb18d44","siteId": "wohnzimmer","text": "t"}
hermes/hotword/toggleOff {"siteId": "wohnzimmer", "reason": "dialogueSession"}
hermes/hotword/toggleOff {"siteId": "wohnzimmer", "reason": "ttsSay"}
hermes/tts/say {"text": "t", "siteId": "wohnzimmer", "lang": null, "id": "0fc597fb-a96f-4cc2-8e08-f9f1cc6052d3", "sessionId": "wohnzimmer-alexa-27a31494-5fd0-40d9-9321-bac52cb18d44", "volume": null}
hermes/tts/sayFinished {"siteId": "wohnzimmer", "id": "0fc597fb-a96f-4cc2-8e08-f9f1cc6052d3", "sessionId": "wohnzimmer-alexa-27a31494-5fd0-40d9-9321-bac52cb18d44"}
hermes/hotword/toggleOn {"siteId": "wohnzimmer", "reason": "ttsSay"}
hermes/hotword/toggleOn {"siteId": "wohnzimmer", "reason": "dialogueSession"}
hermes/nlu/query {"input": "suche", "siteId": "wohnzimmer", "id": null, "intentFilter": ["de.fhem:ABC"], "sessionId": "wohnzimmer-alexa-27a31494-5fd0-40d9-9321-bac52cb18d44", "wakewordId": "alexa", "lang": null, "customData": "WIKI de.fhem:ABC einblatt", "asrConfidence": 1.0, "customEntities": null}
hermes/nlu/intentParsed {"input": "suche", "intent": {"intentName": "de.fhem:ABC", "confidenceScore": 1.0}, "siteId": "wohnzimmer", "id": null, "slots": [{"entity": "Ch", "value": {"kind": "Unknown", "value": "suche"}, "slotName": "Ch", "rawValue": "suche", "confidence": 1.0, "range": {"start": 0, "end": 5, "rawStart": 0, "rawEnd": 5}}], "sessionId": "wohnzimmer-alexa-27a31494-5fd0-40d9-9321-bac52cb18d44"}
hermes/intent/de.fhem:ABC {"input": "suche", "intent": {"intentName": "de.fhem:ABC", "confidenceScore": 1.0}, "siteId": "wohnzimmer", "id": null, "slots": [{"entity": "Ch", "value": {"kind": "Unknown", "value": "suche"}, "slotName": "Ch", "rawValue": "suche", "confidence": 1.0, "range": {"start": 0, "end": 5, "rawStart": 0, "rawEnd": 5}}], "sessionId": "wohnzimmer-alexa-27a31494-5fd0-40d9-9321-bac52cb18d44", "customData": "WIKI de.fhem:ABC einblatt", "asrTokens": [[{"value": "suche", "confidence": 1.0, "rangeStart": 0, "rangeEnd": 5, "time": null}]], "asrConfidence": 1.0, "rawInput": "suche", "wakewordId": "alexa", "lang": null}
hermes/dialogueManager/endSession {"customData": "WIKI de.fhem:ABC einblatt","intentFilter": null,"sessionId": "wohnzimmer-alexa-27a31494-5fd0-40d9-9321-bac52cb18d44","siteId": "wohnzimmer","text": "einblatt steht für  \u000a\u000adie pflanzengattung spathiphyllum aus der familie der aronstabgewächse\u000adie pflanzengattung malaxis aus der familie der orchideen"}
hermes/hotword/toggleOff {"siteId": "wohnzimmer", "reason": "ttsSay"}
hermes/tts/say {"text": "einblatt steht für  \n\ndie pflanzengattung spathiphyllum aus der familie der aronstabgewächse\ndie pflanzengattung malaxis aus der familie der orchideen", "siteId": "wohnzimmer", "lang": null, "id": "a3224350-cdbd-4007-95a0-0f7b962e69a2", "sessionId": "wohnzimmer-alexa-27a31494-5fd0-40d9-9321-bac52cb18d44", "volume": null}
hermes/hotword/toggleOn {"siteId": "wohnzimmer", "reason": "ttsSay"}
hermes/dialogueManager/sessionEnded {"termination": {"reason": "nominal"}, "sessionId": "wohnzimmer-alexa-27a31494-5fd0-40d9-9321-bac52cb18d44", "siteId": "wohnzimmer", "customData": "WIKI de.fhem:ABC einblatt"}
hermes/hotword/toggleOn {"siteId": "wohnzimmer", "reason": "dialogueSession"}
hermes/nlu/query {"input":{"customData": "WIKI de.fhem:ABC einblatt","intentFilter": null,"sessionId": "wohnzimmer-alexa-27a31494-5fd0-40d9-9321-bac52cb18d44","siteId": "wohnzimmer","text": "Habe abgebrochen"},"sessionId": "fhem.textCommand"}
hermes/tts/sayFinished {"siteId": "wohnzimmer", "id": "a3224350-cdbd-4007-95a0-0f7b962e69a2", "sessionId": "wohnzimmer-alexa-27a31494-5fd0-40d9-9321-bac52cb18d44"}


Gruß Jens
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 22 Dezember 2021, 17:04:18
Zitat von: JensS am 22 Dezember 2021, 16:14:12
Sorry, hab immer noch nicht kapiert worum es genau geht - ein MQTT-Mitschnitt einer solchen Stotterei wäre interessant.
Die Timeout-Option habe ich noch nicht genutzt und in der Referenz auch nicht gesehen.
Die Timeout-Option ist auch recht "frisch" und ich bin bisher auch nicht dazu gekommen, das vollständig zu testen, daher habe ich das bisher auch eher zurückhaltend kommuniziert. Tests sind aber willkommen. Im Kern geht es darum:
- U: Hi Rhasspy!
- R: Ping!
- U: Mach das Licht an!
- R: ist erledigt
- U: Mach alle Rollläden zu
- R: gerne!
- U: Stell das Licht auf 30%
- R: OK
- U: Das war's vorerst.
- R: Ping! (Dialog fertig)

Kurz: Man muss nicht ständig das wakeword bemühen, um die nächste Anweisung loszuwerden, sondern kann alles nacheinander abarbeiten.

Leider funktioniert das wie gesagt bei mir manchmal nicht und es verhakt sich was, ohne dass ich dem bisher auf die Schliche gekommen wäre (schon alleine mangels intensiverer Suche)...
Zitat
Hier ein WIKI-Dialog - ganz ohne Stotterei:
...das sieht beeindruckend aus :) .
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 22 Dezember 2021, 17:13:49
Wäre eine Rückfrage "sonst noch was?" mit "Mach alle Rollläden zu" bzw. "nein danke" eine Option?

p.s. Das ist mit dem normalen continueSession und dem steten Wechsel zw. "alle Intents ausser" und "confirm/cancelAction" zu lösen. Sehe kein Problem darin.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 22 Dezember 2021, 17:20:17
Zitat von: JensS am 22 Dezember 2021, 17:13:49
Wäre eine Rückfrage "sonst noch was?" mit "Mach alle Rollläden zu" bzw. "nein danke" eine Option?
"Nein Danke" dürfte nicht das Problem sein, das ist einfach "CancelAction", und das bleibt momentan so oder so aktiviert.

Bei qualifizierten Rückfragen sind wir wieder in der "intent not recognized"-Geschichte. Woher sollte RHASSPY wissen, wie es weitergeht? (könnte man ggf. irgendwie aus statistischen usw. Daten ableiten, ja, ist aber (m.E. zu) aufwändig).

Was ggf. denkbar wäre: Ein Hinweis, dass der Dialog noch offen ist. Hat aber den Nachteil, dass die Rückmeldung dadurch in jedem Fall länger wird (eine Bestätigung sollte unabhängig davon erfolgen), und es evtl. nur eine Gewohnheitsfrage ist: Wem klar ist, dass der Dialog (kurz) noch offen ist, wird entweder nichts mehr sagen oder aktiv zu machen... Daher habe ich das erst mal zurückgestellt, zumal ich auch nicht wußte, ob diese Art der Dialogfortführung überhaupt "gefällt"...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 23 Dezember 2021, 08:16:14
Mit einem Attribut "continue = 1" könnte man auswerten, ob der Nutzer die eine oder andere Variante bevorzugt.
EDIT: In die Response-Sub müsste dann eine Weiche, welche den Hash entweder abschließend verarbeitet oder den Response-Text + "Sonst noch was?" für den Wert "text:" an die Dialog-Sub übergibt.
CancelAction müsste direkt durchgestellt werden.
Du hast dafür bestimmt schon eine Lösung - war mal wieder zu faul, das Modul durchzustöbern...

Gruß Jens
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 23 Dezember 2021, 09:44:03
Zitat von: JensS am 23 Dezember 2021, 08:16:14
Du hast dafür bestimmt schon eine Lösung - war mal wieder zu faul, das Modul durchzustöbern...
Das ganze ist "einfacher" gestrickt, man braucht kein extra Attribut (für sowas ein Attribut zu "verschwenden" halte ich für überflüssig), und wie es funktioniert, hatte ich eigentlich ansatzweise schon erläutert - es gibt einen "globalen" Hauptschalter in der DEF, in den man auch gleich den konkreten timeout (in Sekunden) eintragen kann, den man haben will:
sessionTimeout=15
Der wirkt dann für alle Satelliten.

Über spezielle Readings kann man dieses allgemeine Verhalten überlagern, indem man pro Satelliten einen eigenen timeout setzt. Man kann diesen auch auf "0" setzen, dann wird für den betreffenden Satelliten das "mach gleich zu"-Verhalten erzwungen (z.B. "setreading <rhasspy> sessionTimeout_wohnzimmer 0"). Dazu steht was in der commandref.

So jedenfalls die Theorie ::) . Damit kann man z.B. auf ein bestimmtes wakeword reagieren und dann den timeout ein- oder ausschalten, so dass z.B. nur "Mann" testet...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Gisbert am 25 Dezember 2021, 19:17:33
Hallo Jörg,

heute habe ich erstmalig eine kleine unerwartete Reaktion gefunden. Änderungen am gesprochenen Text und der Installation habe ich in den letzten Tagen keine vorgenommen.

Der Befehl wird ausgeführt, aber als Antwort bekomme ich in etwa das folgende:
ZitatZu Diensten [editiert] senkrechter Strich Gerne [editiert] senkrechter  Strich Ok usw.

Viele​ Grüße​ Gisbert​

Edit: es wird senkrechter Strich und nicht nur Strich ausgegeben
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 26 Dezember 2021, 09:54:34
Welche version war das?
Hast du ggf. auch den Intent, den du aufgerufen hattes?

@all: Habe noch ein paar Kleinigkeiten im svn aufgeräumt, u.a. gibt es im Fehlerfall bei SetOnOff jetzt (hoffentlich) qualifiziertere Rückmeldungen, an was es hapert.

Aktuelle version bekommt man am einfachsten per
{ Svn_GetFile('contrib/RHASSPY/10_RHASSPY.pm', 'FHEM/10_RHASSPY.pm') } (Dann Neustart oder reload)

Oder per wget (unter Linux):
"wget https://svn.fhem.de/trac/export/HEAD/trunk/fhem/contrib/RHASSPY/10_RHASSPY.pm -O ./FHEM/10_RHASSPY.pm"
Nix funktional revolutionäres, eher Code-Vereinfachungen...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Prof. Dr. Peter Henning am 26 Dezember 2021, 10:55:43
Ich habe immer noch ein Problem mit der TTS-Umelitung aus Rhasspy

Wenn ich in der Rhasspy-Oberfläche als Text-to-Speech (TTS) "Hermes MQTT" einstelle, und mit einem MQTT2_CLIENT+DEVICE auf hermes/tts/say lausche, kann ich problemlos die Sprachausgabe von Rhasspy auf mein System umleiten. Allerdings erwartet Rhasspy auch eine Bestätigung. Laut Beschreibung des Hermes-Protokolls muss diese die entsprechenden Parameter aus dem "say"-Aufruf enthalten. Mit dem Code

sub speakMQTT($$){
  my ($name,$evt) = @_;
  my $dec      = decode_json($evt);
  my $text     = $dec->{'text'};
  my $siteid   = $dec->{'siteId'};
  my $sessionid   = $dec->{'sessionId'};
  my $id       = $dec->{'id'};
  my %enc      = ( 'id' => $id, 'siteId' => $siteid, 'sessionId' => $sessionid);
  my $json = encode_json \%enc;

  speak($siteid,$text); # Das ist mein TTS-System

  fhem('set SpeakMQTT_Client publish hermes/tts/sayFinished '.$json);
}
   

geht es aber nicht - Rhasspy wartet auf die Bestätigung und geht nach 30 Sekunden in ein Timeout. Hat jemand eine Idee, woran das liegen kann?

LG

pah
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Gisbert am 26 Dezember 2021, 12:31:22
Hallo Jörg,

ich hatte eigentlich die bis gestern aktuelle Version von RHASSPY im FHEM-Verzeichnis. Der Fehler kam bei mehreren Befehlen, es waren aber alle vom Typ setOn/setOff.

Ich hab die aktuelle Version runtergeladen, ein Upload durchgeführt und im RHASSPY-Modul ein update all durchgeführt - danach läuft jetzt alles fehlerfrei.

Vorher stand das im Reading state:
http://192.168.1.46:12101/api/intents: empty answer received

Viele​ Grüße​ Gisbert​
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 26 Dezember 2021, 13:30:42
Schön, dass es jetzt wieder funktioniert.

@pah: Kann es sein, dass der Audio-Server auf Daten wartet (playWav)?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 26 Dezember 2021, 14:01:35
@pah
... wie schon erwähnt, wäre ein MQTT-Mitschnitt interessant.
TTS ist ja nur ein Teil des Systems. Wurde der laufende Dialog vor TTS in continueSession versetzt oder mit endSession auf sessionEnded vorbereitet?

Gruß Jens
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Prof. Dr. Peter Henning am 26 Dezember 2021, 15:06:30
@Beta-User:
ZitatKann es sein, dass der Audio-Server auf Daten wartet
Kein Audioserver. Schau mal auf <IP-Adresse Rhasspy>:12101/docs/text-to-speech/

So wie ich das verstehe, gibt es eine Message an hermes/tts/say, wenn diese beendet ist muss etwas an hermes/tts/sayFinished zurückkommen.

@JensS: Mag ja sein - aber wo steht das in der Dokumentation?

Der Ablauf ist seltsam, Das Rhasspy-Log sieht so aus
Zitat[ERROR:2021-12-26 14:53:19,770] rhasspyserver_hermes:
Traceback (most recent call last):
  File "/usr/lib/rhasspy/.venv/lib/python3.7/site-packages/quart/app.py", line 1821, in full_dispatch_request
    result = await self.dispatch_request(request_context)
  File "/usr/lib/rhasspy/.venv/lib/python3.7/site-packages/quart/app.py", line 1869, in dispatch_request
    return await handler(**request_.view_args)
  File "/usr/lib/rhasspy/rhasspy-server-hermes/rhasspyserver_hermes/__main__.py", line 1699, in api_text_to_speech
    results = await asyncio.gather(*aws)
  File "/usr/lib/rhasspy/rhasspy-server-hermes/rhasspyserver_hermes/__main__.py", line 1685, in speak
    say_chars_per_second=say_chars_per_second,
  File "/usr/lib/rhasspy/rhasspy-server-hermes/rhasspyserver_hermes/__init__.py", line 617, in speak_sentence
    handle_finished(), messages, message_types, timeout_seconds=timeout_seconds
  File "/usr/lib/rhasspy/rhasspy-server-hermes/rhasspyserver_hermes/__init__.py", line 995, in publish_wait
    result_awaitable, timeout=timeout_seconds
  File "/usr/lib/python3.7/asyncio/tasks.py", line 423, in wait_for
    raise futures.TimeoutError()
concurrent.futures._base.TimeoutError
[DEBUG:2021-12-26 14:52:49,763] rhasspyserver_hermes: Handling TtsSayFinished (topic=hermes/tts/sayFinished, id=39ebcd9f-2234-4dde-88d7-60bfa95ae20b)
[DEBUG:2021-12-26 14:52:49,763] rhasspyserver_hermes: Handling TtsSayFinished (topic=hermes/tts/sayFinished, id=fcf40d25-a095-4cf4-a774-b71db64888aa)
[DEBUG:2021-12-26 14:52:49,762] rhasspyserver_hermes: Handling TtsSayFinished (topic=hermes/tts/sayFinished, id=aa66560d-d6f9-4c64-89e8-a947d9439044)
[DEBUG:2021-12-26 14:52:49,762] rhasspyserver_hermes: Handling TtsSayFinished (topic=hermes/tts/sayFinished, id=acf9739e-23c9-4a99-b6ba-8114d0c9e500)
[DEBUG:2021-12-26 14:52:49,735] rhasspyserver_hermes: Publishing 141 bytes(s) to hermes/tts/say
[DEBUG:2021-12-26 14:52:49,735] rhasspyserver_hermes: -> TtsSay(text='Das ist ein Test', site_id='default', lang=None, id='06ea1d58-b7b8-494c-ac47-d099f9b201f2', session_id='', volume=1.0)
[DEBUG:2021-12-26 14:52:49,733] rhasspyserver_hermes: TTS timeout will be 30 second(s)
[ERROR:2021-12-26 14:51:28,242] rhasspyserver_hermes:
Traceback (most recent call last):
  File "/usr/lib/rhasspy/.venv/lib/python3.7/site-packages/quart/app.py", line 1821, in full_dispatch_request
    result = await self.dispatch_request(request_context)
  File "/usr/lib/rhasspy/.venv/lib/python3.7/site-packages/quart/app.py", line 1869, in dispatch_request
    return await handler(**request_.view_args)
  File "/usr/lib/rhasspy/rhasspy-server-hermes/rhasspyserver_hermes/__main__.py", line 1699, in api_text_to_speech
    results = await asyncio.gather(*aws)
  File "/usr/lib/rhasspy/rhasspy-server-hermes/rhasspyserver_hermes/__main__.py", line 1685, in speak
    say_chars_per_second=say_chars_per_second,
  File "/usr/lib/rhasspy/rhasspy-server-hermes/rhasspyserver_hermes/__init__.py", line 617, in speak_sentence
    handle_finished(), messages, message_types, timeout_seconds=timeout_seconds
  File "/usr/lib/rhasspy/rhasspy-server-hermes/rhasspyserver_hermes/__init__.py", line 995, in publish_wait
    result_awaitable, timeout=timeout_seconds
  File "/usr/lib/python3.7/asyncio/tasks.py", line 423, in wait_for
    raise futures.TimeoutError()
concurrent.futures._base.TimeoutError
[DEBUG:2021-12-26 14:50:58,245] rhasspyserver_hermes: Handling TtsSayFinished (topic=hermes/tts/sayFinished, id=fcf40d25-a095-4cf4-a774-b71db64888aa)
[DEBUG:2021-12-26 14:50:58,244] rhasspyserver_hermes: Handling TtsSayFinished (topic=hermes/tts/sayFinished, id=aa66560d-d6f9-4c64-89e8-a947d9439044)
[DEBUG:2021-12-26 14:50:58,244] rhasspyserver_hermes: Handling TtsSayFinished (topic=hermes/tts/sayFinished, id=acf9739e-23c9-4a99-b6ba-8114d0c9e500)
[DEBUG:2021-12-26 14:50:58,218] rhasspyserver_hermes: Publishing 141 bytes(s) to hermes/tts/say
[DEBUG:2021-12-26 14:50:58,218] rhasspyserver_hermes: -> TtsSay(text='Das ist ein Test', site_id='default', lang=None, id='bf2a5edc-5bcf-45a8-a5ed-6d476e6cee01', session_id='', volume=1.0)
[DEBUG:2021-12-26 14:50:58,216] rhasspyserver_hermes: TTS timeout will be 30 second(s)
[ERROR:2021-12-26 14:50:24,531] rhasspyserver_hermes:
Traceback (most recent call last):
  File "/usr/lib/rhasspy/.venv/lib/python3.7/site-packages/quart/app.py", line 1821, in full_dispatch_request
    result = await self.dispatch_request(request_context)
  File "/usr/lib/rhasspy/.venv/lib/python3.7/site-packages/quart/app.py", line 1869, in dispatch_request
    return await handler(**request_.view_args)
  File "/usr/lib/rhasspy/rhasspy-server-hermes/rhasspyserver_hermes/__main__.py", line 1699, in api_text_to_speech
    results = await asyncio.gather(*aws)
  File "/usr/lib/rhasspy/rhasspy-server-hermes/rhasspyserver_hermes/__main__.py", line 1685, in speak
    say_chars_per_second=say_chars_per_second,
  File "/usr/lib/rhasspy/rhasspy-server-hermes/rhasspyserver_hermes/__init__.py", line 617, in speak_sentence
    handle_finished(), messages, message_types, timeout_seconds=timeout_seconds
  File "/usr/lib/rhasspy/rhasspy-server-hermes/rhasspyserver_hermes/__init__.py", line 995, in publish_wait
    result_awaitable, timeout=timeout_seconds
  File "/usr/lib/python3.7/asyncio/tasks.py", line 423, in wait_for
    raise futures.TimeoutError()
concurrent.futures._base.TimeoutError
[DEBUG:2021-12-26 14:49:54,529] rhasspyserver_hermes: Handling TtsSayFinished (topic=hermes/tts/sayFinished, id=aa66560d-d6f9-4c64-89e8-a947d9439044)
[DEBUG:2021-12-26 14:49:54,528] rhasspyserver_hermes: Handling TtsSayFinished (topic=hermes/tts/sayFinished, id=acf9739e-23c9-4a99-b6ba-8114d0c9e500)
[DEBUG:2021-12-26 14:49:54,503] rhasspyserver_hermes: Publishing 141 bytes(s) to hermes/tts/say
[DEBUG:2021-12-26 14:49:54,503] rhasspyserver_hermes: -> TtsSay(text='Das ist ein Test', site_id='default', lang=None, id='8a32f023-b00c-421f-ab6d-80782311fe2a', session_id='', volume=1.0)
[DEBUG:2021-12-26 14:49:54,501] rhasspyserver_hermes: TTS timeout will be 30 second(s)

Das ist natürlich von unten nach oben zu lesen: Hier habe ich 3x nacheinander in der Rhasspy-Weboberfläche den Service "speak" aufgerufen, jeweils mit dem text "Das ist ein Test". Der wird auch wunderbar ausgegeben, und jedesmal liefere ich (mit der gleichen Id) ein SayFinished zurück. Das Log sagt auch, dass ein SayFinished gehandled wird - das hat aber eine andere Id, die ich auch nicht migeliefert habe. Sondern mein Logging auf der FHEM-Seite besagt

Zitat2021.12.26 14:48:27 1: set SpeakMQTT_Client publish hermes/tts/sayFinished {"siteId":"default","sessionId":"","id":"0dc56167-53b5-4173-a8a1-5aa8ffbdf638"}
2021.12.26 14:49:54 1: [speakTablet] name=Tab2.EG text=Das ist ein Test
2021.12.26 14:49:54 1: [speakMQTT] siteId=default text=Das ist ein Test
2021.12.26 14:49:54 1: set SpeakMQTT_Client publish hermes/tts/sayFinished {"id":"8a32f023-b00c-421f-ab6d-80782311fe2a","sessionId":"","siteId":"default"}
2021.12.26 14:50:58 1: [speakTablet] name=Tab2.EG text=Das ist ein Test
2021.12.26 14:50:58 1: [speakMQTT] siteId=default text=Das ist ein Test
2021.12.26 14:50:58 1: set SpeakMQTT_Client publish hermes/tts/sayFinished {"sessionId":"","id":"bf2a5edc-5bcf-45a8-a5ed-6d476e6cee01","siteId":"default"}
2021.12.26 14:52:49 1: [speakTablet] name=Tab2.EG text=Das ist ein Test
2021.12.26 14:52:49 1: [speakMQTT] siteId=default text=Das ist ein Test
2021.12.26 14:52:49 1: set SpeakMQTT_Client publish hermes/tts/sayFinished {"sessionId":"","id":"06ea1d58-b7b8-494c-ac47-d099f9b201f2","siteId":"default"}

Das ist hier von oben nach unten zu lesen, und wie man sieht, gebe ich dieselbe id zurück, die mit der say-Message empfangen wurde.

Was mich stutzig macht, ist dass die sayFinished-Messages offenbar von Rhasspy nicht abgerufen werden, sondern in der Queue verbleiben. Darum werden dann im letzten (oder beim Rhasspy-Log obersten Eintrag) mehrere solcher sayFinished-Messages abgearbeitet, von denen aber offenbar keine die richtige Id hat.

Also ist die Frage: Was sorgt in Rhasspy dafür, dass die von mir zurückgelieferte Id in eine andere verbogen wird?

LG

pah
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 26 Dezember 2021, 15:10:04
SayFinished ist lt. meinem Verständnis der Doku die Info, dass die Konvertierung in Sound durch ist, nicht die Sound-Ausgabe...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Prof. Dr. Peter Henning am 26 Dezember 2021, 16:04:05
Ich habe jetzt die Bestätigungsnachricht sowohl an

hermes/audioServer/default/playFinished

als auch an

hermes/audioServer/default/playBytes/$id

($id ersetzt durch die Message-id) gesendet. Im Falle von playFinished tut sich gar nichts, im zweiten Fall gibt es vor dem Timeout auch noch einen Audioserver-Error.

Aus meiner Sicht ist das auch nicht sehr logisch: Rhasspy weiß nur, dass es ein "say" abgesetzt hat, es sollte also auf eine Rückmeldung von say warten.

Aber gut, auch das habe ich nioch ausprobiert: Zuerst den text nach say gepublished, prinma, wird ausgegeben. Dann von FHEM aus playBytes mit einer Länge von 0 aufgerufen, und dann eine Nachricht an playFinished abgesetzt
Zitat2021.12.26 15:58:35 1: set SpeakMQTT_Client publish hermes/audioServer/default/playBytes/muellIdFromFhem {"wav_bytes":0,"siteId":"default","requestId":"muellIdFromFhem"}
2021.12.26 15:58:35 1: set SpeakMQTT_Client publish hermes/audioServer/default/playFinished {"id":"muellIdFromFhem"}

(Das das mit dem beliebigen Id-String funktioniert, habe ich schon beim Abarbeiten eines Intents gecheckt, den ich von außen an Rhasspy sende)

Ergebnis dasselbe: Audioserver Fehler, und dann wieder der Timeout. Die Frage, worauf Rhasspy eigentlich wartet, ist damit immer noch ungeklärt.

LG

pah
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 26 Dezember 2021, 21:33:41
@pah
Dein TTS gibt den Text von hermes/dialogueManager/continueSession oder von hermes/dialogueManager/endSession wieder.
Dabei wird vom Dialog-Manager im Schritt vorher bestimmt, ob die Session anschließend offen bleibt oder geschlossen wird.
https://docs.snips.ai/reference/dialogue#end-session
https://rhasspy.readthedocs.io/en/latest/reference/#dialogue-manager
Aus deinen Log-Auszügen kann ich diese Info nicht entnehmen. Ein Mitschnitt über mosquitto_sub bringt bestimmt schneller Licht ins Dunkel.

Gruß Jens
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 27 Dezember 2021, 06:31:59
@pah: Wenn RHASSPY diese Rolle beim Messenger-Dialog übernimmt, sind da nur zwei Datenpunkte im JSON:
my $sendData =  {
        id           => $data->{id},
        siteId       => $hash->{siteId}
    };
    my $json = _toCleanJSON($sendData);
    IOWrite($hash, 'publish', qq{hermes/tts/sayFinished $json});

Als spec-Notiz habe ich mir diesen Link notiert: https://rhasspy.readthedocs.io/en/latest/reference/#tts_say (https://rhasspy.readthedocs.io/en/latest/reference/#tts_say)

Da in diesem Fall FHEM selbst der Dialogpartner ist, paßt auch die siteId, du müßtest die mAn. anders setzen.

Da du die Befehle "drumrum" scheinbar fertig hast nochmal das Angebot, RHASSPY für diesen Teil direkt als IO-Modul zu erweitern, tts/say wird "eh" schon abonniert...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Prof. Dr. Peter Henning am 28 Dezember 2021, 07:18:47
Ich werde es heute nochmal probieren (Golf fällt vermutlich ins Wasser..).

Ich denke nicht, dass das eine Frage des "Dialogmanagements" ist - wir wissen einfach noch nicht, auf welche Message Rhasspy dann wartet (sayFinished offenbar nicht, und ein PlayBytes mit Null Bytes löst einen Fehler aus).

Zitat
SayFinished ist lt. meinem Verständnis der Doku die Info, dass die Konvertierung in Sound durch ist, nicht die Sound-Ausgabe...
So steht es auf der einen Seite (Link in der Rhasspy-Oberfläche). Aber hier https://rhasspy.readthedocs.io/en/latest/reference/#tts_say steht das Gegenteil:
Zitathermes/tts/sayFinished (JSON)

    Indicates that the text to speech system has finished speaking



Möglichweise werde ich wirklich mal MQTT bei einem internen TTS-Service mitschneiden müssen. Obwohl mich so etwas ärgert, denn ein Protokoll wie Hermes sollte sauber dokumnetiert sein, ohne dass man erst ein solches Reverse Engineering betreiben muss.

LG

pah
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 28 Dezember 2021, 07:29:41
Na ja, "eigentlich" ist die Doku von Rhasspy eher als sehr gut zu bezeichnen, und vermutlich ist mein erster Link veraltet, und "sayFinished" ist wirklich die Info, dass das Sprechen fertig ist. Jedenfalls habe ich bei eher oberflächlicher Suche keine Probleme wahrgenommen mit der dargestellten Messenger-Variante (hatte vorher mit einigen anderen Elementen im JSON gespielt, und da hat das nicht so gut funktioniert).

"hermes" war halt nach meinem Verständnis die Entwicklung von Snips, die ja nicht mehr exisitieren, und am ehesten von Rhasspy-Seite weiterentwickelt wird, von daher ist der Wunsch nach "noch besserer" Doku zwar nachvollziehbar, ich sehe aber nicht, wer den einlösen sollte...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 28 Dezember 2021, 09:24:35
Also ich finde die Doku von Snips gut. Leider hat Rhasspy nicht alle Funktionalitäten übernommen.
Die Beendigung der Session ist aus meiner Sicht eindeutig:
continueSession: Die Session wird nach der TTS mit den Optionen aus der continueSession-Anweisung wieder aufgenommen.
endSession: Wartet auf sayFinished und schließt dann die Session mit SessionEnd.
kein Text in continueSession bzw. endSession: DIe Session wird sofort geschlossen.
Dazu gibt ja einen Sitzungsleiter (Dialog-Manager).

Gruß Jens
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Prof. Dr. Peter Henning am 28 Dezember 2021, 09:32:18
Hm. Snips habe ich schon vor langer Zeit verwendet - der Seminarvortrag dazu ist > 2 Jahre alt. Und schon da fand mein Team die Doku grenzwertig.

Betreffend die "Beendigung": Ich habe mehrfach (auch mit dem verwendeten) Code gezeigt, dass sayFinished mit korrekter id und siteId das Warten eben nicht beendet. Also woran liegt es?

LG

pah
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 28 Dezember 2021, 09:39:14
Weiß nicht, ob es um's "Übernehmen" ging oder vielmehr ums "Nachbilden", aber klar ist, dass es Abweichungen gibt, und daher im Zweifel immer die aktuellste Doku bei Rhasspy maßgeblich ist, und nicht die Theorie/Darstellung aus der "Ursuppe".

Hier geht es nach meinem Verständnis aber erst mal darum, dass im Rahmen eines Dialogs (und zwar unabhängig davon, ob der anschließend zugemacht werden soll oder nicht) Rhasspy/das Sessionmanagement informiert wird, dass das Synthetisieren und Sprechen (im Rahmen eines ganz bestimmten Dialogs mit einer bestimmten Ausgabestelle) beendet wurde - und daher z.B. auch das Mikro wieder auf "hotword-detection" gestellt werden darf.

Zitat von: Prof. Dr. Peter Henning am 28 Dezember 2021, 09:32:18
Betreffend die "Beendigung": Ich habe mehrfach (auch mit dem verwendeten) Code gezeigt, dass sayFinished mit korrekter id und siteId das Warten eben nicht beendet. Also woran liegt es?
Hast du es auch mit dem eingeschränkten JSON versucht? Also nur genau diese zwei Elemente, nicht mehr.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Prof. Dr. Peter Henning am 28 Dezember 2021, 09:47:17
Aber ja. Hier nochmal im Detail, gerade eben durchgeführt.

Zuerst sende ich - aus der "Home"-Seite von Rhasspy:
Zitat[DEBUG:2021-12-28 09:39:22,800] rhasspyserver_hermes: -> TtsSay(text='Das ist noch ein fünfter Versuch', site_id='default', lang=None, id='3ae8e3ed-363b-42dd-866c-2b24dbb97727', session_id='', volume=1.0)

Das geht über den MQTT-Server als
Zitat[DEBUG:2021-12-28 09:39:22,800] rhasspyserver_hermes: Publishing 157 bytes(s) to hermes/tts/say

Wird bei mir wunderbar ausgeführt,
Zitat2021.12.28 09:39:22 1: [speakTablet] name=Tab2.EG text=Das ist noch ein fünfter Versuch

und umgehend beantwortet mit
Zitat2021.12.28 09:39:22 1: set SpeakMQTT_Client publish hermes/tts/sayFinished {"siteId":"default","id":"3ae8e3ed-363b-42dd-866c-2b24dbb97727"}

Das kommt auch - irgendwie - bei Rhasspy an, denn das Rhasspy-Log meldet
Zitat[DEBUG:2021-12-28 09:39:22,830] rhasspyserver_hermes: Handling TtsSayFinished (topic=hermes/tts/sayFinished, id=970ec854-df84-4261-9b2d-73990f8c9167)

Nur, und das ist die Kernfrage: Woher kommt die geänderte Id ????

Denn Rhasspy erkennt die Antwort nicht und geht nach 30 Sekunden in einen Timeout

Zitat[ERROR:2021-12-28 09:39:52,829] rhasspyserver_hermes:
Traceback (most recent call last):
  File "/usr/lib/rhasspy/.venv/lib/python3.7/site-packages/quart/app.py", line 1821, in full_dispatch_request
    result = await self.dispatch_request(request_context)
  File "/usr/lib/rhasspy/.venv/lib/python3.7/site-packages/quart/app.py", line 1869, in dispatch_request
    return await handler(**request_.view_args)
  File "/usr/lib/rhasspy/rhasspy-server-hermes/rhasspyserver_hermes/__main__.py", line 1699, in api_text_to_speech
    results = await asyncio.gather(*aws)
  File "/usr/lib/rhasspy/rhasspy-server-hermes/rhasspyserver_hermes/__main__.py", line 1685, in speak
    say_chars_per_second=say_chars_per_second,
  File "/usr/lib/rhasspy/rhasspy-server-hermes/rhasspyserver_hermes/__init__.py", line 617, in speak_sentence
    handle_finished(), messages, message_types, timeout_seconds=timeout_seconds
  File "/usr/lib/rhasspy/rhasspy-server-hermes/rhasspyserver_hermes/__init__.py", line 995, in publish_wait
    result_awaitable, timeout=timeout_seconds
  File "/usr/lib/python3.7/asyncio/tasks.py", line 423, in wait_for
    raise futures.TimeoutError()
concurrent.futures._base.TimeoutError

LG

pah


Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 28 Dezember 2021, 10:04:30
Hmm, kann grade nicht testen, aber wenn ich meine Testmessages so ansehe, fällt mir auf, dass "id" da in der Regel mit "null" belegt ist bzw. in lastIntentPayload (das ist aber kein Roh-Wert, sondern toJSON von $data) findet sich dazu nichts...
Evtl. mal (echtes) "null" übergeben (also ohne Quotes)?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 28 Dezember 2021, 10:58:16
Es gibt auch noch ein schönes Bildchen, welches aber nur bedingt aussagekräftig ist.
https://snips.gitbook.io/tutorials/t/technical-guides/listening-to-intents-over-mqtt-using-python (https://snips.gitbook.io/tutorials/t/technical-guides/listening-to-intents-over-mqtt-using-python)
Der Dialogmanager ordnet mit dem Text von endSession ein tts/say an. TTS übernimmt die id und verkündet dann die erfolgte Ausgabe.
Hier ein Mitschnitt einer Bestätigungsabfrage mit continueSession und Endsession. Auf die Topics mit Audioframes habe ich verzichtet.mosquitto_sub -v -t hermes/hotword/# -t hermes/dialogueManager/# -t hermes/asr/# -t hermes/audioServer/+/playFinished -t hermes/nlu/# -t hermes/error/# -t hermes/tts/# -t hermes/feedback/#
hermes/hotword/alexa/detected {"modelId": "alexa", "modelVersion": "", "modelType": "personal", "currentSensitivity": 0.5, "siteId": "wohnzimmer", "sessionId": null, "sendAudioCaptured": null, "lang": null, "customEntities": null}
hermes/dialogueManager/sessionStarted {"sessionId": "wohnzimmer-alexa-7e57b60f-47da-47f6-bd67-0a075f42d8c0", "siteId": "wohnzimmer", "customData": "alexa", "lang": null}
hermes/hotword/toggleOff {"siteId": "wohnzimmer", "reason": "dialogueSession"}
hermes/asr/startListening {"siteId": "wohnzimmer", "sessionId": "wohnzimmer-alexa-7e57b60f-47da-47f6-bd67-0a075f42d8c0", "lang": null, "stopOnSilence": true, "sendAudioCaptured": true, "wakewordId": "alexa", "intentFilter": null}
hermes/asr/textCaptured {"text": "stehlampe an", "likelihood": 0.9419979, "seconds": 3.83437726192642, "siteId": "wohnzimmer", "sessionId": "wohnzimmer-alexa-7e57b60f-47da-47f6-bd67-0a075f42d8c0", "wakewordId": null, "asrTokens": [[{"value": "stehlampe", "confidence": 0.987926, "rangeStart": 0, "rangeEnd": 10, "time": {"start": 0.01116, "end": 1.54037}}, {"value": "an", "confidence": 1.0, "rangeStart": 10, "rangeEnd": 13, "time": {"start": 1.5453, "end": 4.14}}]], "lang": null}
hermes/asr/stopListening {"siteId": "wohnzimmer", "sessionId": "wohnzimmer-alexa-7e57b60f-47da-47f6-bd67-0a075f42d8c0"}
hermes/hotword/toggleOn {"siteId": "wohnzimmer", "reason": "dialogueSession"}
hermes/nlu/query {"input": "stehlampe an", "siteId": "wohnzimmer", "id": null, "intentFilter": ["de.fhem:SetAllOn", "de.fhem:ViomiRhasspy", "de.fhem:RhasspyGetTimer", "de.fhem:WIKI", "de.fhem:GetTime", "de.fhem:GetNumeric", "de.fhem:GetAllOff", "de.fhem:SetColor", "de.fhem:Wikipedia", "de.fhem:Fernsehprogramm", "de.fhem:Respeak", "de.fhem:SetNumeric", "de.fhem:RhasspySetTimer", "de.fhem:Status", "de.fhem:SetMute", "de.fhem:SetAllOff", "de.fhem:Witze", "de.fhem:SetOnOff", "de.fhem:Wetter", "de.fhem:MediaControls", "de.fhem:GetWeekday", "de.fhem:Shortcuts", "de.fhem:GetOnOff"], "sessionId": "wohnzimmer-alexa-7e57b60f-47da-47f6-bd67-0a075f42d8c0", "wakewordId": "alexa", "lang": null, "customData": "alexa", "asrConfidence": 0.9419979, "customEntities": null}
hermes/nlu/intentParsed {"input": "stehlampe on", "intent": {"intentName": "de.fhem:SetOnOff", "confidenceScore": 1.0}, "siteId": "wohnzimmer", "id": null, "slots": [{"entity": "de.fhem.Device", "value": {"kind": "Unknown", "value": "stehlampe"}, "slotName": "Device", "rawValue": "stehlampe", "confidence": 1.0, "range": {"start": 0, "end": 9, "rawStart": 0, "rawEnd": 9}}, {"entity": "Value", "value": {"kind": "Unknown", "value": "on"}, "slotName": "Value", "rawValue": "an", "confidence": 1.0, "range": {"start": 10, "end": 12, "rawStart": 10, "rawEnd": 12}}], "sessionId": "wohnzimmer-alexa-7e57b60f-47da-47f6-bd67-0a075f42d8c0"}
hermes/dialogueManager/continueSession {"customData": "alexa","intentFilter":["de.fhem:ConfirmAction","de.fhem:CancelAction"],"sendIntentNotRecognized": true,"sessionId": "wohnzimmer-alexa-7e57b60f-47da-47f6-bd67-0a075f42d8c0","siteId": "wohnzimmer","text": "bestätige stehlampe an"}
hermes/asr/stopListening {"siteId": "wohnzimmer", "sessionId": "wohnzimmer-alexa-7e57b60f-47da-47f6-bd67-0a075f42d8c0"}
hermes/hotword/toggleOff {"siteId": "wohnzimmer", "reason": "dialogueSession"}
hermes/hotword/toggleOff {"siteId": "wohnzimmer", "reason": "ttsSay"}
hermes/asr/toggleOff {"siteId": "wohnzimmer", "reason": "ttsSay"}
hermes/tts/say {"text": "bestätige stehlampe an", "siteId": "wohnzimmer", "lang": null, "id": "d52aadcd-1447-4753-9234-d4862a872b58", "sessionId": "wohnzimmer-alexa-7e57b60f-47da-47f6-bd67-0a075f42d8c0", "volume": null}
hermes/tts/sayFinished {"siteId": "wohnzimmer", "id": "d52aadcd-1447-4753-9234-d4862a872b58", "sessionId": "wohnzimmer-alexa-7e57b60f-47da-47f6-bd67-0a075f42d8c0"}
hermes/hotword/toggleOn {"siteId": "wohnzimmer", "reason": "ttsSay"}
hermes/asr/toggleOn {"siteId": "wohnzimmer", "reason": "ttsSay"}
hermes/asr/startListening {"siteId": "wohnzimmer", "sessionId": "wohnzimmer-alexa-7e57b60f-47da-47f6-bd67-0a075f42d8c0", "lang": null, "stopOnSilence": true, "sendAudioCaptured": true, "wakewordId": null, "intentFilter": null}
hermes/audioServer/wohnzimmer/playFinished {"id": "d52aadcd-1447-4753-9234-d4862a872b58", "sessionId": "d52aadcd-1447-4753-9234-d4862a872b58"}
hermes/asr/textCaptured {"text": "ja bitte", "likelihood": 1.0, "seconds": 5.306720254011452, "siteId": "wohnzimmer", "sessionId": "wohnzimmer-alexa-7e57b60f-47da-47f6-bd67-0a075f42d8c0", "wakewordId": null, "asrTokens": [[{"value": "ja", "confidence": 1.0, "rangeStart": 0, "rangeEnd": 3, "time": {"start": 0.0, "end": 0.93}}, {"value": "bitte", "confidence": 1.0, "rangeStart": 3, "rangeEnd": 9, "time": {"start": 0.93, "end": 5.42}}]], "lang": null}
hermes/asr/stopListening {"siteId": "wohnzimmer", "sessionId": "wohnzimmer-alexa-7e57b60f-47da-47f6-bd67-0a075f42d8c0"}
hermes/hotword/toggleOn {"siteId": "wohnzimmer", "reason": "dialogueSession"}
hermes/nlu/query {"input": "ja bitte", "siteId": "wohnzimmer", "id": null, "intentFilter": ["de.fhem:ConfirmAction", "de.fhem:CancelAction"], "sessionId": "wohnzimmer-alexa-7e57b60f-47da-47f6-bd67-0a075f42d8c0", "wakewordId": "alexa", "lang": null, "customData": "alexa", "asrConfidence": 1.0, "customEntities": null}
hermes/nlu/intentParsed {"input": "OK", "intent": {"intentName": "de.fhem:ConfirmAction", "confidenceScore": 1.0}, "siteId": "wohnzimmer", "id": null, "slots": [{"entity": "Mode", "value": {"kind": "Unknown", "value": "OK"}, "slotName": "Mode", "rawValue": "ja bitte", "confidence": 1.0, "range": {"start": 0, "end": 2, "rawStart": 0, "rawEnd": 8}}], "sessionId": "wohnzimmer-alexa-7e57b60f-47da-47f6-bd67-0a075f42d8c0"}
hermes/dialogueManager/endSession {"customData": "alexa","intentFilter": null,"sessionId": "wohnzimmer-alexa-7e57b60f-47da-47f6-bd67-0a075f42d8c0","siteId": "wohnzimmer","text": "Ok - Stehlampe im wohnzimmer ist eingeschaltet"}
hermes/hotword/toggleOff {"siteId": "wohnzimmer", "reason": "ttsSay"}
hermes/asr/toggleOff {"siteId": "wohnzimmer", "reason": "ttsSay"}
hermes/tts/say {"text": "Ok - Stehlampe im wohnzimmer ist eingeschaltet", "siteId": "wohnzimmer", "lang": null, "id": "18e18822-5851-464d-b6f4-dbc7622ce03b", "sessionId": "wohnzimmer-alexa-7e57b60f-47da-47f6-bd67-0a075f42d8c0", "volume": null}
hermes/tts/sayFinished {"siteId": "wohnzimmer", "id": "18e18822-5851-464d-b6f4-dbc7622ce03b", "sessionId": "wohnzimmer-alexa-7e57b60f-47da-47f6-bd67-0a075f42d8c0"}
hermes/hotword/toggleOn {"siteId": "wohnzimmer", "reason": "ttsSay"}
hermes/asr/toggleOn {"siteId": "wohnzimmer", "reason": "ttsSay"}
hermes/asr/stopListening {"siteId": "wohnzimmer", "sessionId": "wohnzimmer-alexa-7e57b60f-47da-47f6-bd67-0a075f42d8c0"}
hermes/dialogueManager/sessionEnded {"termination": {"reason": "nominal"}, "sessionId": "wohnzimmer-alexa-7e57b60f-47da-47f6-bd67-0a075f42d8c0", "siteId": "wohnzimmer", "customData": "alexa"}
hermes/hotword/toggleOn {"siteId": "wohnzimmer", "reason": "dialogueSession"}
hermes/audioServer/wohnzimmer/playFinished {"id": "18e18822-5851-464d-b6f4-dbc7622ce03b", "sessionId": "18e18822-5851-464d-b6f4-dbc7622ce03b"}

Gruß Jens

@Beta-User
Bei genauerer Betrachtung denke ich den Grund für die Stotterei gefunden zu haben. ASR und Hotword werden gestartet, obwohl es noch keine Bestätigung von playFinished gibt.hermes/dialogueManager/continueSession {"customData": "alexa","intentFilter":["de.fhem:ConfirmAction","de.fhem:CancelAction"],"sendIntentNotRecognized": true,"sessionId": "wohnzimmer-alexa-7e57b60f-47da-47f6-bd67-0a075f42d8c0","siteId": "wohnzimmer","text": "bestätige stehlampe an"}
hermes/asr/stopListening {"siteId": "wohnzimmer", "sessionId": "wohnzimmer-alexa-7e57b60f-47da-47f6-bd67-0a075f42d8c0"}
hermes/hotword/toggleOff {"siteId": "wohnzimmer", "reason": "dialogueSession"}
hermes/hotword/toggleOff {"siteId": "wohnzimmer", "reason": "ttsSay"}
hermes/asr/toggleOff {"siteId": "wohnzimmer", "reason": "ttsSay"}
hermes/tts/say {"text": "bestätige stehlampe an", "siteId": "wohnzimmer", "lang": null, "id": "d52aadcd-1447-4753-9234-d4862a872b58", "sessionId": "wohnzimmer-alexa-7e57b60f-47da-47f6-bd67-0a075f42d8c0", "volume": null}
hermes/tts/sayFinished {"siteId": "wohnzimmer", "id": "d52aadcd-1447-4753-9234-d4862a872b58", "sessionId": "wohnzimmer-alexa-7e57b60f-47da-47f6-bd67-0a075f42d8c0"}
hermes/hotword/toggleOn {"siteId": "wohnzimmer", "reason": "ttsSay"}
hermes/asr/toggleOn {"siteId": "wohnzimmer", "reason": "ttsSay"}
hermes/asr/startListening {"siteId": "wohnzimmer", "sessionId": "wohnzimmer-alexa-7e57b60f-47da-47f6-bd67-0a075f42d8c0", "lang": null, "stopOnSilence": true, "sendAudioCaptured": true, "wakewordId": null, "intentFilter": null}
hermes/audioServer/wohnzimmer/playFinished {"id": "d52aadcd-1447-4753-9234-d4862a872b58", "sessionId": "d52aadcd-1447-4753-9234-d4862a872b58"}

Das ist aus meiner Sicht ein Fehler in der Reihenfolge. Siehst du das auch so?
Meine Lösung, das Mikro des Satelliten beim Abspielen des Antworttextes zu muten, macht hierbei Sinn. Besser wäre natürlich, die Reihenfolge zu korrigieren.
Da es bei Rhasspy im Moment einige Umbrüche gibt, sehe ich nicht, wer das dort machen würde.

Gruß Jens

p.s. @Beta-User
Das Mikro wird vielleicht für das Stoppen der Sprachausgabe geöffnet. Dann muss ein lokales Echo-Canceling her...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 28 Dezember 2021, 11:31:40
Hmm, also wird die id doch durchgeschleust...

Das "Problem" mit diesem Muster-Dialog ist allerdings, dass vermutlich als TTS-Komponente grade nicht Hermes-MQTT eingestellt ist (bei meinen Messenger-Dialogen aber sehr wohl, nur dass dort die "FHEM-Site" nicht als für die Komponente relevante SiteId eingetragen ist).

@pah: evtl. wäre es eine Idee, das mal auf dem Default zu lassen und dann die betreffenden SiteId's für diesen Dienst bei Rhasspy zu löschen?
Ist nur ein Experiment, und an sich sieht mir das nach einer kaputten (im Sinne von nicht der Spec entsprechenden) Implementierung auf Rhasspy-Seite aus, die man im dortigen Forum hinterfragen sollte.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Prof. Dr. Peter Henning am 28 Dezember 2021, 13:00:26
Klar, wenn ich einen der internen TTS-Services nutze, ist ja alles OK - das ist aber nicht das Problem.

@JensS: Es wäre interessant, zu diesem Mitschnitt noch das Rhasspy-Log zu sehen. Nämlich, ob das Handling des sayFinished auch die id verändert, oder dieselbe id beibehält.

Ich vermute, dass an dieser Stelle der Fehler in Rhasspy ist.

LG

pah
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 28 Dezember 2021, 13:06:09
Zitat von: Prof. Dr. Peter Henning am 28 Dezember 2021, 13:00:26
Klar, wenn ich einen der internen TTS-Services nutze, ist ja alles OK - das ist aber nicht das Problem.
Mein Vorschlag war, Rhasspy "auszutricksen":
- Soweit ich das in Erinnerung habe, kommt die Meldung auf dem "say-Topic" immer, egal, welchen TTS-Handler man eingestellt hat (=> immer abgreifbar! Das ist im Beispiel von JensS so, paßte aber auch bei meinem Messenger-SiteId-Versuchen)
- der "picoTTS-default" (?) ist aber nur aktiv, wenn eine "ihm gehörende" SiteId genannt wird.
Will man den also "eigentlich" gar nicht nutzen, muss man ihm "nur" alle SiteId's entziehen und braucht ihn nicht explizit durch was anderes ersetzen.

Klar ist das eine Fehlfunktion, wenn es so klappt, aber immerhin eine Option.

Schreibe das nur für den Fall, dass das vorher missverstanden worden sein sollte.

EDIT: Wegen des Posts bei Rhasspy: Du solltest vielleicht noch erwähnen, dass Hermes-MQTT als TTS-Dienst ausgewählt ist, und der auch für den Satelliten "default" zuständig ist.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Prof. Dr. Peter Henning am 28 Dezember 2021, 14:11:07
Ich habe das jetzt mal hier gepostet

https://community.rhasspy.org/t/mqtt-issue-with-external-tts-service/3384

LG

pah
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 28 Dezember 2021, 15:47:23
Ups, das wäre mir beinahe durch...:
Zitat von: JensS am 28 Dezember 2021, 10:58:16
Das ist aus meiner Sicht ein Fehler in der Reihenfolge. Siehst du das auch so?
Es klingt plausibel. In diese Richtung hatte ich auch schon überlegt, allerdings ist es schade, dass man die zeitlichen Zusammenhänge nicht deutlich erkennen kann, und irritierend ist auch, dass es sehr wechselhaft ist, ob man weiterreden kann oder nicht.

Zitat
Meine Lösung, das Mikro des Satelliten beim Abspielen des Antworttextes zu muten, macht hierbei Sinn. Besser wäre natürlich, die Reihenfolge zu korrigieren.
Da es bei Rhasspy im Moment einige Umbrüche gibt, sehe ich nicht, wer das dort machen würde.
Na ja, es ist ja nicht so, dass der Hauptentwickler nicht mehr da wäre, es geht halt uU. etwas langsamer wie früher.

Bei den Dialog-Themen hier würde ich auch tippen, dass das bisher einfach nicht so sehr im Fokus war, weil es eher darum ging, nach einem wakeword einen Befehl abzusetzen und gut ist, und es nicht besonders schwer ist, das zu fixen...

Zitat
p.s. @Beta-User
Das Mikro wird vielleicht für das Stoppen der Sprachausgabe geöffnet. Dann muss ein lokales Echo-Canceling her...
Den Absatz verstehe ich im Moment nicht.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Prof. Dr. Peter Henning am 28 Dezember 2021, 17:30:33
Anbei mal mein Schema für die Anbindung von Babble an Rhasspy. An einem Wiki-Artikel, der die Vor- und Nachteile der jeweiligen Alternativen auflistet, arbeite ich auch schon. Ich habe das jetzt so gelöst, dass ich mit dem Wakeword "Hallo Jeannie" (Precise, selbst trainiert, via Rhasspy und MQTT) meine Spracherkennung starte (auf Tablets, also via Google. Ist einfach um Klassen besser als die vorhandenen Open Source Lösungen).

Der fertige Befehlssatz wird an Babble zur Auswertung (also Intent-Erkennung und Handling) weitergeleitet, es sei denn, ich sage
"Hallo Jeannie. Sage Mycroft: <Hier der Text>". In diesem Falle wird der nachfolgende Text an hermes/nlu/query weitergeleitet.

LG

pah

Edit: Sehe gerade, dass der eine blaue Pfeil noch falsch ist - der muss auch über RHASSPY laufen.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 28 Dezember 2021, 17:49:28
Auf die Schnelle ein erster Eindruck: Es könnte m.E. einiges entfallen, wenn man wollte...

- Das notify (+Perl-Code für "Hey Jeannie"): die Funktionalität ähnelt dem, was bei "normalen" RESIDENTS-Message-Events (in RHASSY) "veranstaltet" wird
- MQTT2_DEVICE: Das hat ja nur eine Art "Relay-Stations-Funktionalität". Sollte sich einfach in RHASSPY integrieren lassen (Damit entfällt auch Konfigurationsaufwand am MQTT2_CLIENT)
- Perl-Code zum Start der Spracherkennung: Müßte auch recht einfach zu integrieren sein. RHASSPY müßte "nur" wissen, welches AMADDevice anzusprechen ist. (Rhasspy-) wakeword-abhängig?

In welchen Fällen ist denn Rhasspy noch für STT verantwortlich? Wenn ich das richtig deute, eigentlich nie. Oder nur bei "anderen" Wakewords?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 28 Dezember 2021, 18:25:15
Zitat von: JensS am 28 Dezember 2021, 10:58:16
p.s. @Beta-User
Das Mikro wird vielleicht für das Stoppen der Sprachausgabe geöffnet. Dann muss ein lokales Echo-Canceling her...
Die Reihenfolge von WakeWord, ASR und playFinished kann gewollt sein, um das Mikro beim Abspielen einer Antwort offen zu haben. Dann könnte man Rhasspy "das Maul stopfen".
Manche WIKI-Antwort oder Programmvorschau dauert und dauert...
Wakeword und ASR müssten in dem Fall, den momentan gesprochenen Audiostream aus der momentanen Aufnahme des Mikros ausfiltern/abziehen, um der ASR eine brauchbare AUfnahme zu übermitten. Ein solches Echo-Canceling könnte über Pulse oder auf Hardwareebene realisiert werden. Das ist natürlich keinem Nutzer zuzumuten. Ein fertiges Image für eine festgelegte Hardware wäre die Lösung, welche wiederum andere Hardware aussen vor lässt.

s. Folgender Test:
Nach dem Fernsehprogramm gefragt. Ton-Ausgabe kommt.
Dann beim Satelliten den Ton auf 0 gestellt, so dass kein augegebener Ton aufgenommen werden kann.
In der laufenden Ausgabe Wakeword gesprochen und in der WIKI nachschlagen lassen.
Ergebnis:
Rhasspy arbeitet die zweite Aufforderung sauber ab, kapert beim Antworten den Tonausgang und würgt das Fernsehprogramm ab. Mit einem guten Echo-Canceling durchaus brauchbar.

Trotzdem überlege ich im Moment, mein LED-Script für RPi0W umzuschreiben. Es gibt für den Respeaker2MicHat keine mute/unmute-Funktion. So muss die Mikrolautstärke definiert werden.
Der Ablauf würde dann so aussehen: Bei tts/say würde der Ton auf 0 und nach playFinished auf 90 gestellt werden. Im Mute-Modus würden die LEDs leicht blau leuchten. Falls playFinished ausbleibt, könnte man mit einem kurzen Tastendruck das Mikro wieder auf 90 stellen. Das generelle Deaktivieren des Mikros nach 3 Sekunden Tastendruck würde ebenso drin bleiben, wie das Herrunterfahren des Satelliten nach 10 Sekunden drücken.

@pah
Hübsch bunt.  :)
Läuft es jetzt? Ich denke, dass jemand in die Session quatscht, der eigentlich den Mund halten sollte. Ein zweiter Teilnehmer mit der SiteId "default" z.B..

p.s. sh. s.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Prof. Dr. Peter Henning am 28 Dezember 2021, 19:05:32
Zitat- Das notify (+Perl-Code für "Hey Jeannie"): die Funktionalität ähnelt dem, was bei "normalen" RESIDENTS-Message-Events (in RHASSY) "veranstaltet" wird
Kein Widerspruch.

Zitat
- MQTT2_DEVICE: Das hat ja nur eine Art "Relay-Stations-Funktionalität". Sollte sich einfach in RHASSPY integrieren lassen (Damit entfällt auch Konfigurationsaufwand am MQTT2_CLIENT)
Auch richtig. Allerdings ist die Doku von 10_RHASSPY.pm derzeit noch so unübersichtlich, dass man das sehr gut beschreiben müsste.
Zitat
- Perl-Code zum Start der Spracherkennung: Müßte auch recht einfach zu integrieren sein. RHASSPY müßte "nur" wissen, welches AMADDevice anzusprechen ist. (Rhasspy-) wakeword-abhängig?
Das wechselt - müsste als Parameter à la siteid übergeben werden.

ZitatIn welchen Fällen ist denn Rhasspy noch für STT verantwortlich? Wenn ich das richtig deute, eigentlich nie. Oder nur bei "anderen" Wakewords?
Richtig gedeutet. Die STT Transformation auf Basis von Phonemen und lokal hinterlegten Dictionaries ist der Erkennung von Google um Lichtjahre hinterher. Dabei müsste man nicht über ein Android-Gerät gehen. Ich habe schon länger vor, das direkt in FHEM zu integrieren (per Zugriff auf Google Cloud Dienste).

Das mache ich ja auch mit der TTS-Transformation - wobei ich hierzu Amazon Polly bevorzuge, wegen der hohen Sprachqualität (Amazon hat hier die beste Firma aufgekauft). Bei mir daheim erfolgt die Sprachausgabe auf allen Geräten mit derselben Stimme (Marlene). Auf Android-Geräten erfordert das nur die Installation der Sprachdateien und einen Aufruf von AMAD. Auf allen anderen Geräten werden die Textdaten an AWS geschickt und ein MP3 zurückgeliefert.

LG

pah
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Prof. Dr. Peter Henning am 28 Dezember 2021, 19:16:49
ZitatLäuft es jetzt? Ich denke, dass jemand in die Session quatscht, der eigentlich den Mund halten sollte. Ein zweiter Teilnehmer mit der SiteId "default" z.B..
Nö, nach wie vor dasselbe. Ich habe jetzt in meine Antworten genau die Parameter eingebaut, die auch nanoTTS zurückliefert - keine Chance, immer noch timeout.

Ich habe auch eine Subscription für hermes/# laufen lassen - da kommt nichts dazwischen.

Sobald ich die Ausgabe über nanoTTS laufen lasse, aber trotzdem die Subscription für /hermes/tts/say aufrecht erhalte, gibt es die doppelte Sprachausgabe - und wunderbarerweise keinen Timeout. Ich bin inzwischen ziemlich überzeugt davon, dass hier Rhasspy einen Fehler hat, wenn "nur" MQTT als TTS eingestellt wird.

LG

pah
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 28 Dezember 2021, 19:26:50
Wie sieht der Ablauf mitmosquitto_sub -v -t hermes/hotword/# -t hermes/dialogueManager/# -t hermes/asr/# -t hermes/audioServer/+/playFinished -t hermes/nlu/# -t hermes/error/# -t hermes/tts/# -t hermes/feedback/#aus?

p.s. Doofe Frage:
Hast du "Audio Playing" auf "Hermes MQTT" gestellt?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Prof. Dr. Peter Henning am 28 Dezember 2021, 22:08:28
ZitatHast du "Audio Playing" auf "Hermes MQTT" gestellt?
Nein.Warum auch ?

Die Antwort auf die erste Frage: Check ich morgen mal.

LG

pah
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 29 Dezember 2021, 00:20:51
Das Ganze hat dann doch spät abends meinen Ehrgeiz gepackt und daraus ist eine kleine TTS entstanden:#!/usr/bin/perl -w
use Net::MQTT::Simple;
use JSON;
use strict;

my $mqtt = Net::MQTT::Simple->new("localhost");
$mqtt->run(
    "hermes/tts/say" => sub {
        my ($topic, $message) = @_;
        my $tts_json = JSON->new->allow_nonref->decode( $message );
        my $siteId = $tts_json->{siteId};
        my $id = $tts_json->{id};
        my $sessionId = $tts_json->{sessionId};
        my $text = '"'.$tts_json->{text}.'"';
        my $ausgabe = {id => $id, sessionId => $sessionId, siteId => $siteId};
        my $sayFinish = JSON->new->utf8->encode( $ausgabe );
        qx(pico2wave -l "de-DE" -w test.wav $text);
        $mqtt->publish("hermes/tts/sayFinished" => $sayFinish);
        qx(aplay test.wav);
        my $playausgabe = {id => $id, sessionId => $sessionId};
        my $playFinish = JSON->new->utf8->encode( $playausgabe );
        $mqtt->publish("hermes/audioServer/$siteId/playFinished" => $playFinish);
    },
);

Bei der Base steht TTS auf "Hermes MQTT" und beim Satelliten ist nur "Audio Recording" und "Wake Word" aktiv. Die Sprachausgabe lasse ich mit aplay auf der Base ausgeben.mosquitto_sub -v -t hermes/hotword/# -t hermes/dialogueManager/# -t hermes/asr/# -t hermes/audioServer/+/playFinished -t hermes/nlu/# -t hermes/error/# -t hermes/tts/# -t hermes/feedback/#
hermes/hotword/alexa/detected {"modelId": "alexa", "modelVersion": "", "modelType": "personal", "currentSensitivity": 0.5, "siteId": "wohnzimmer", "sessionId": null, "sendAudioCaptured": null, "lang": null, "customEntities": null}
hermes/dialogueManager/sessionStarted {"sessionId": "wohnzimmer-alexa-4002e615-32b1-4e7a-8b22-0fc83098bcef", "siteId": "wohnzimmer", "customData": "alexa", "lang": null}
hermes/hotword/toggleOff {"siteId": "wohnzimmer", "reason": "dialogueSession"}
hermes/asr/startListening {"siteId": "wohnzimmer", "sessionId": "wohnzimmer-alexa-4002e615-32b1-4e7a-8b22-0fc83098bcef", "lang": null, "stopOnSilence": true, "sendAudioCaptured": true, "wakewordId": "alexa", "intentFilter": null}
hermes/asr/textCaptured {"text": "licht an", "likelihood": 0.9855946, "seconds": 5.811926366994157, "siteId": "wohnzimmer", "sessionId": "wohnzimmer-alexa-4002e615-32b1-4e7a-8b22-0fc83098bcef", "wakewordId": null, "asrTokens": [[{"value": "licht", "confidence": 1.0, "rangeStart": 0, "rangeEnd": 6, "time": {"start": 0.0, "end": 1.3}}, {"value": "an", "confidence": 1.0, "rangeStart": 6, "rangeEnd": 9, "time": {"start": 1.30341, "end": 6.19}}]], "lang": null}
hermes/asr/stopListening {"siteId": "wohnzimmer", "sessionId": "wohnzimmer-alexa-4002e615-32b1-4e7a-8b22-0fc83098bcef"}
hermes/hotword/toggleOn {"siteId": "wohnzimmer", "reason": "dialogueSession"}
hermes/nlu/query {"input": "licht an", "siteId": "wohnzimmer", "id": null, "intentFilter": ["de.fhem:SetColor", "de.fhem:Wikipedia", "de.fhem:Fernsehprogramm", "de.fhem:Respeak", "de.fhem:SetNumeric", "de.fhem:RhasspySetTimer", "de.fhem:Status", "de.fhem:SetMute", "de.fhem:SetAllOff", "de.fhem:SetAllOn", "de.fhem:ViomiRhasspy", "de.fhem:RhasspyGetTimer", "de.fhem:WIKI", "de.fhem:GetTime", "de.fhem:GetNumeric", "de.fhem:GetAllOff", "de.fhem:GetOnOff", "de.fhem:Witze", "de.fhem:SetOnOff", "de.fhem:Wetter", "de.fhem:MediaControls", "de.fhem:GetWeekday", "de.fhem:Shortcuts"], "sessionId": "wohnzimmer-alexa-4002e615-32b1-4e7a-8b22-0fc83098bcef", "wakewordId": "alexa", "lang": null, "customData": "alexa", "asrConfidence": 0.9855946, "customEntities": null}
hermes/nlu/intentParsed {"input": "licht on", "intent": {"intentName": "de.fhem:SetOnOff", "confidenceScore": 1.0}, "siteId": "wohnzimmer", "id": null, "slots": [{"entity": "de.fhem.Device", "value": {"kind": "Unknown", "value": "licht"}, "slotName": "Device", "rawValue": "licht", "confidence": 1.0, "range": {"start": 0, "end": 5, "rawStart": 0, "rawEnd": 5}}, {"entity": "Value", "value": {"kind": "Unknown", "value": "on"}, "slotName": "Value", "rawValue": "an", "confidence": 1.0, "range": {"start": 6, "end": 8, "rawStart": 6, "rawEnd": 8}}], "sessionId": "wohnzimmer-alexa-4002e615-32b1-4e7a-8b22-0fc83098bcef"}
hermes/dialogueManager/endSession {"customData": "alexa","intentFilter": null,"sessionId": "wohnzimmer-alexa-4002e615-32b1-4e7a-8b22-0fc83098bcef","siteId": "wohnzimmer","text": "Ok - Licht im wohnzimmer ist eingeschaltet"}
hermes/hotword/toggleOff {"siteId": "wohnzimmer", "reason": "ttsSay"}
hermes/asr/toggleOff {"siteId": "wohnzimmer", "reason": "ttsSay"}
hermes/tts/say {"text": "Ok - Licht im wohnzimmer ist eingeschaltet", "siteId": "wohnzimmer", "lang": null, "id": "eaa7aa87-8bad-4648-894e-9a6912afa226", "sessionId": "wohnzimmer-alexa-4002e615-32b1-4e7a-8b22-0fc83098bcef", "volume": null}
hermes/tts/sayFinished {"sessionId":"wohnzimmer-alexa-4002e615-32b1-4e7a-8b22-0fc83098bcef","siteId":"wohnzimmer","id":"eaa7aa87-8bad-4648-894e-9a6912afa226"}
hermes/hotword/toggleOn {"siteId": "wohnzimmer", "reason": "ttsSay"}
hermes/asr/toggleOn {"siteId": "wohnzimmer", "reason": "ttsSay"}
hermes/asr/stopListening {"siteId": "wohnzimmer", "sessionId": "wohnzimmer-alexa-4002e615-32b1-4e7a-8b22-0fc83098bcef"}
hermes/dialogueManager/sessionEnded {"termination": {"reason": "nominal"}, "sessionId": "wohnzimmer-alexa-4002e615-32b1-4e7a-8b22-0fc83098bcef", "siteId": "wohnzimmer", "customData": "alexa"}
hermes/hotword/toggleOn {"siteId": "wohnzimmer", "reason": "dialogueSession"}
hermes/audioServer/wohnzimmer/playFinished {"id":"eaa7aa87-8bad-4648-894e-9a6912afa226","sessionId":"wohnzimmer-alexa-4002e615-32b1-4e7a-8b22-0fc83098bcef"}
Es gibt keine Dopplungen oder Timeouts.
Gruß Jens

p.s. Die Zeile "$mqtt->publish("hermes/tts/sayFinished" => $sayFinish);" habe ich etwas vorgezogen, das es bei einer längeren Sprachausgabe (>10sec) zu einem Timeout kommen würde.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 29 Dezember 2021, 07:13:38
Zitat von: Prof. Dr. Peter Henning am 28 Dezember 2021, 22:08:28
Nein.Warum auch ?
Weil im Rhasspy-Ökosystem jeder "seine" Rolle kennen muss...?

Nachdem ich noch einige Zeit über das Thema nachgedacht habe, meine ich auch, dass das mit der "doppelten" Ausgabe daran liegt, dass sich deine "base" (siteId: "default") weiter für zuständig für die Soundausgabe hält und halt nicht rechtzeitig "Futter" bekommt. Du willst aber ja gar nicht, dass sie (aus Rhasspy heraus) Sound ausgibt, sondern daran vorbei. Also muss der entsprechende Dienst für diesen Satelliten deaktiviert werden.
Das kann man darüber erreichen, dass eben entweder ein "externer Dienst" als Service angegeben wird, oder eben direkt die entsprechende SiteId _nicht_ im betreffenden Funktionsbereich als "Adressat" angegeben wird.

Da du anscheinend ein "headless" setup (Audio- Ein- und Ausgabe nicht über den zentralen Rhasspy-Server) anpeilst, würde ich einfach die defaults belassen, aber die SiteId's der "externen" Stellen nicht mit angeben. Dann kannst du halt nicht die Web-Oberfläche für den Text-Input nutzen, aber das geht ja auch über RHASSPY (da kann/muss man die siteId auch angeben).

Zitat von: Prof. Dr. Peter Henning am 28 Dezember 2021, 19:05:32
Kein Widerspruch.
[...]
Auch richtig. Allerdings ist die Doku von 10_RHASSPY.pm derzeit noch so unübersichtlich, dass man das sehr gut beschreiben müsste.
Bin prinzipiell für Vorschläge - auch zur Doku - offen.

Zitat
Das wechselt - müsste als Parameter à la siteid übergeben werden.
Einig. Jedes Ein- und Ausgabegerät braucht seine siteId.

Das ist nicht nur für die RHASSPY-interne Ordnung wichtig, sondern auch zur klaren Abgrenzung der Zuständigkeiten im Rhasspy-Ökosystem (s.o.).

Zitat
Richtig gedeutet. Die STT Transformation [...]
OK, damit ist das Bild erst mal für mich halbwegs klar.

Würde vorschlagen, für den "FHEM-Rhasspy-TTS/STT"-Funktionsteil ein neues Attribut einzuführen. Vorsichtshalber würde ich das mal generisch benennen, war erst geneigt, was mit "AMAD" zu wählen, aber es könnten dann ja auch andere dienste in Frage kommen. Ist halt komplettes Neuland, muss mal sehen, ob/was ich da zusammenschustern kann. Wenn es irgend geht, will ich aber nicht noch eine App installieren und mich mit irgendwelchen "Flows" belasten, von daher wäre es nett, wenn mich jemand mit "Testdaten" versorgen könnte.
Brauche für's erste:
- Wie kommt man von AMADDevice auf die passende AMADComBridge-Instanz (zweistufig, also gehe ich davon aus, dass man das aus dem/den AMADDevice-Instanzen ableiten kann?)
- Wie sehen die Events aus, wenn STT auf dem Adroiden abgeschlossen ist?

Damit sollte es in Schritt 1 möglich sein, einen Schlüssel "AMAD: siteIdA:AMAD-Devicename-A siteIdB:AMAD-Devicename-B" zu generieren. Für den TTS-Teil könnte es so aussehen: "TTS: siteIdA:"set $device <command> $text"  siteIdB:{perl($device,$text) }"
(Übergeben werden der aus der siteId abgeleitete Device-Name sowie der zu sprechende Text).

EDIT: Für die Weiterleitung wäre dann noch ein "sage MyCroft"-Schlüssel erforderlich...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Prof. Dr. Peter Henning am 29 Dezember 2021, 15:33:54
Langsam, ein alter Mann ist kein D-Zug.

Heute morgen hatte ich glücklicherweise etwas Anderes zu tun - Endredaktion meines neuen Buches, https://www.europa-verlag.com/Buecher/6611/WiderdieAngst.html

Zum Setting: Ich lasse Rhasspy derzeit im Docker laufen, mosquitto_sub ist darin nicht bekannt. Das lässt sich aber auch erreichen, indem ich ein MQTT2_DEVICE (XXX) auf alles subscribe - das habe ich gestern schon ausprobiert. Und keinerlei Nachrichten vom Dialog-Manager bekommen. Nochmal in Kürze

1. Versuch: TTS auf einen der mitgelieferten Dienste eingestellt, sagen wir nanoTTS:
- hermes/tts/say wird sowohl von meinem TTS-Service, als auch vom Test-Device XXX, als auch von nanoTTS empfangen.
- Ausgeführt von beiden Diensten
- Bestätigt sowohl von meinem TTS-Dienst (rot) als auch von nanoTTS (grün)
- Ergebnis: Rhasspy ist zufrieden, kein Timeout, alles in Butter

Zitat2021.12.29 15:20:21 4: MQTT2_DEVICE_Parse: MQTT2_XXX hermes/tts/say => { Log 1, $EVENT;;json2nameValue($EVENT) }
2021.12.29 15:20:21 1: {"text": "Das ist Test Nummer 1234", "siteId": "default", "lang": null, "id": "1a6eef5c-5314-43ae-baa4-b4be931c4d82", "sessionId": "", "volume": 1.0}
2021.12.29 15:20:21 4: MQTT2_DEVICE_Parse: MQTT2_XXX hermes/tts/sayFinished => {Log 1, $EVENT;;json2nameValue($EVENT) }
2021.12.29 15:20:21 1: {"siteId": "default", "id": "1a6eef5c-5314-43ae-baa4-b4be931c4d82", "sessionId": ""}
2021.12.29 15:20:21 4: MQTT2_DEVICE_Parse: MQTT2_XXX hermes/audioServer/default/playFinished => {Log 1, $EVENT;;json2nameValue($EVENT) }
2021.12.29 15:20:21 1: {"id": "1a6eef5c-5314-43ae-baa4-b4be931c4d82", "sessionId": "1a6eef5c-5314-43ae-baa4-b4be931c4d82"}
2021.12.29 15:20:21 4: MQTT2_DEVICE_Parse: MQTT2_XXX hermes/tts/sayFinished => {Log 1, $EVENT;;json2nameValue($EVENT) }
2021.12.29 15:20:21 1: {"siteId": "default", "id": "1a6eef5c-5314-43ae-baa4-b4be931c4d82", "sessionId": ""}
2021.12.29 15:20:25 4: MQTT2_DEVICE_Parse: MQTT2_XXX hermes/audioServer/default/playFinished => {Log 1, $EVENT;;json2nameValue($EVENT) }
2021.12.29 15:20:25 1: {"id": "1a6eef5c-5314-43ae-baa4-b4be931c4d82", "sessionId": "1a6eef5c-5314-43ae-baa4-b4be931c4d82"}

2. Versuch: TTS auf Hermes MQTT eingestellt:
- hermes/tts/say wird nur von meinem TTS-Service, als auch vom Test-Device XXX
- Ausgeführt 
- Bestätigt nur von meinem TTS-Dienst (rot)
- Ergebnis: Rhasspy reagiert nichjt,geht nach 30 Sekunden in Timeout

Zitat2021.12.29 15:23:40 4: MQTT2_DEVICE_Parse: MQTT2_XXX hermes/tts/say => { Log 1, $EVENT;;json2nameValue($EVENT) }
2021.12.29 15:23:40 1: {"text": "Das ist Test Nummer 1236", "siteId": "default", "lang": null, "id": "9b7a2deb-dd30-4280-b69e-a545591db943", "sessionId": "", "volume": 1.0}
2021.12.29 15:23:40 4: MQTT2_DEVICE_Parse: MQTT2_XXX hermes/tts/sayFinished => {Log 1, $EVENT;;json2nameValue($EVENT) }
2021.12.29 15:23:40 1: {"siteId": "default", "id": "9b7a2deb-dd30-4280-b69e-a545591db943", "sessionId": ""}
2021.12.29 15:23:40 4: MQTT2_DEVICE_Parse: MQTT2_XXX hermes/audioServer/default/playFinished => {Log 1, $EVENT;;json2nameValue($EVENT) }
2021.12.29 15:23:40 1: {"id": "9b7a2deb-dd30-4280-b69e-a545591db943", "sessionId": "9b7a2deb-dd30-4280-b69e-a545591db943"}

Keine Störung, nicht _eine_ weitere MQTT-Message dazwischen. Nix Dialogmanager, oder Fortsetzungsbefehl. Wirklich identische Bestätigungsmessages von nanoTTS und von mir. Die eine wird akzeptiert, die andere nicht :-((

Zum Post von Beta-User: Ich habe derzeit keine Satelliten dran, nur die Base. Ist ja auch noch alles in der Experimentalphase.


LG

pah
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 29 Dezember 2021, 16:04:10
Hallo zusammen,
habe zwischenzeitlich auch etwas rumprobiert, dokumentiert ist mal wieder noch nichts...

Funktional haben wir es mAn. mit drei Bereichen zu tun, die sich nur in Teilen überschneiden. Um "alles" zu aktivieren, braucht man in der DEF einen "Babble"-Key, der auf eine Babble-Instanz verweist.
defmod RHASSPY RHASSPY baseUrl=[...] Babble=babble
Ohne die Babble-Anbindung geht einfach alles "ungefiltert" in die Rhasspy-NLU-Analyse und man kann auch den "filterFromBabble" in "rhasspySTT" nicht setzen.

attr RHASSPY rhasspySTT filterFromBabble=sage Mycroft\
AMADCommBridge=AMADBridge\
allowed=AMADDev_A
attr RHASSPY rhasspyTTS AMADDev_A=siteId=android_wohnzimmer ttsCommand={fhem("set $DEVICE ttsMsg $message")}


Mit dem Attribut "rhasspySTT" teilt man RHASSPY also mit, dass man AMAD.* für STT im Einsatz hat und es auf Events in der AMADCommBridge hören soll. Welches Device es war, steht hoffentlich zum gleichen Zeitpunkt auch schon in einem dortigen Reading, damit kann RHASSPY dann entscheiden, ob dieses Device (unter den komma-separierten) "allowed" ist und der Text verarbeitet werden soll.

Danach sollte geprüft werden, ob Babble Vorrang hat (so vorhanden und der filterFromBabble gesetzt ist). Wenn ja, erfolgt ein "Babble_Doit", wenn nein, wird der Text (um den Filter gekürzt) an Rhasspy-NLU weitergegeben. Dazu wird ein ähnlicher Mechanismus genutzt wie für die "normalen" msg-Dialoge, so dass man prinzipiell nur die RHASSPY-siteId für den NLU-Service in Rhasspy eintragen muss (falls noch nicht für den msg-Dialog erfolgt). Intern weiß RHASSPY anhand der sessionId, wohin welche Info zu gehen hat.

Das Attribut "rhasspyTTS" dient erst mal dazu, im Prinzip beliebigen Devices einen Text-Synthetisierungs-Kommand zuzuweisen und ihnen eine zusätzliche siteId zu erlauben.
Die wiederum braucht man, wenn man eine hotword-Message dazu nutzen will, den voiceInput zu aktivieren. Könnte bereits mit AMADDevices klappen, auch ohne dass man den ttsCommand explizit setzen müßte, (das ist hier nur als Beispiel gedacht, gehen müßte es mit FHEM-Kommandos und Perl).
Es gibt auch eine (vorrangige) Reading-basierte Zuordnung von siteId auf FHEM-Device, anhand Readings der Form siteId2ttsDevice_<siteId>, mit der man das (hoffentlich) im laufenden Betrieb dynamisch ändern könnte und auch den Key im Attribut nicht setzen muss...

...soviel zur Theorie, getestet ist erst mal - mehr oder weniger - nichts...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Prof. Dr. Peter Henning am 29 Dezember 2021, 18:21:44
Ist das Thema "Timer" jetzt eigentlich stabil? Ich würde das gerne mal mit dem vergleichen, was ich mit Babble/Rivescript gebaut habe.

LG

pah
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Prof. Dr. Peter Henning am 29 Dezember 2021, 20:50:48
Ich habe den "kleinen TTS" von JensS ausprobiert (mit dem Unterschied, dass ich den Text nicht sprechen lasse, sondern einfach in eine Datei schreibe). Gleiches Ergebnis: śayFinished wird nicht akzeptiert.

Ein anderes Device am MQTT-Server erkennt auch die richtigen Messages:

ZitatMQTT2_DEVICE_Parse: MQTT2_XXX hermes/tts/say => { Log 1, $EVENT;;json2nameValue($EVENT) }
2021.12.29 20:42:53 1: {"text": "Noch mal, aber jetzt nur über MQTT", "siteId": "default", "lang": null, "id": "bc3e649f-379e-4e92-b055-de38acf35d6c", "sessionId": "", "volume": 1.0}
2021.12.29 20:42:53 4: MQTT2_DEVICE_Parse: MQTT2_XXX hermes/tts/sayFinished => {Log 1, $EVENT;;json2nameValue($EVENT) }
2021.12.29 20:42:53 1: {"id":"bc3e649f-379e-4e92-b055-de38acf35d6c","sessionId":"","siteId":"default"}
2021.12.29 20:42:53 4: MQTT2_DEVICE_Parse: MQTT2_XXX hermes/audioServer/default/playFinished => {Log 1, $EVENT;;json2nameValue($EVENT) }
2021.12.29 20:42:53 1: {"id":"bc3e649f-379e-4e92-b055-de38acf35d6c","sessionId":""}
2021.12.29 20:42:53 4: MQTT2_DEVICE_Parse: MQTT2_XXX hermes/tts/sayFinished => {Log 1, $EVENT;;json2nameValue($EVENT) }
2021.12.29 20:42:53 1: {"siteId":"default","sessionId":"","id":"bc3e649f-379e-4e92-b055-de38acf35d6c"}
2021.12.29 20:42:53 4: MQTT2_DEVICE_Parse: MQTT2_XXX hermes/audioServer/default/playFinished => {Log 1, $EVENT;;json2nameValue($EVENT) }
2021.12.29 20:42:53 1: {"id":"bc3e649f-379e-4e92-b055-de38acf35d6c","sessionId":""}

Kommt hier doppelt: Einmal vom "JensS-TTS-Service", und einmal von meinem.

Was mich etwas auf die Palme treibt: Beide Message-Paare kommen auch bei Rhasspy an. Aber, ums Verrecken, wieder mit einer anderen id. Woher kommt das? Ich tappe im Dunkel.


Zitat[ERROR:2021-12-29 20:43:23,422] rhasspyserver_hermes:
Traceback (most recent call last):
  File "/usr/lib/rhasspy/.venv/lib/python3.7/site-packages/quart/app.py", line 1821, in full_dispatch_request
    result = await self.dispatch_request(request_context)
  File "/usr/lib/rhasspy/.venv/lib/python3.7/site-packages/quart/app.py", line 1869, in dispatch_request
    return await handler(**request_.view_args)
  File "/usr/lib/rhasspy/rhasspy-server-hermes/rhasspyserver_hermes/__main__.py", line 1699, in api_text_to_speech
    results = await asyncio.gather(*aws)
  File "/usr/lib/rhasspy/rhasspy-server-hermes/rhasspyserver_hermes/__main__.py", line 1685, in speak
    say_chars_per_second=say_chars_per_second,
  File "/usr/lib/rhasspy/rhasspy-server-hermes/rhasspyserver_hermes/__init__.py", line 617, in speak_sentence
    handle_finished(), messages, message_types, timeout_seconds=timeout_seconds
  File "/usr/lib/rhasspy/rhasspy-server-hermes/rhasspyserver_hermes/__init__.py", line 995, in publish_wait
    result_awaitable, timeout=timeout_seconds
  File "/usr/lib/python3.7/asyncio/tasks.py", line 423, in wait_for
    raise futures.TimeoutError()
concurrent.futures._base.TimeoutError
[DEBUG:2021-12-29 20:42:53,413] rhasspyserver_hermes: Handling TtsSayFinished (topic=hermes/tts/sayFinished, id=3ad6cd22-1d74-4d65-95d4-b8767cdd7645)
[DEBUG:2021-12-29 20:42:53,400] rhasspyserver_hermes: Handling TtsSayFinished (topic=hermes/tts/sayFinished, id=3ad6cd22-1d74-4d65-95d4-b8767cdd7645)
[DEBUG:2021-12-29 20:42:53,387] rhasspyserver_hermes: Publishing 159 bytes(s) to hermes/tts/say
[DEBUG:2021-12-29 20:42:53,386] rhasspyserver_hermes: -> TtsSay(text='Noch mal, aber jetzt nur über MQTT', site_id='default', lang=None, id='bc3e649f-379e-4e92-b055-de38acf35d6c', session_id='', volume=1.0)
[DEBUG:2021-12-29 20:42:53,384] rhasspyserver_hermes: Subscribed to hermes/audioServer/default/playBytes/#
[DEBUG:2021-12-29 20:42:53,382] rhasspyserver_hermes: Subscribed to hermes/audioServer/Wohnzimmer/playBytes/#
[DEBUG:2021-12-29 20:42:53,381] rhasspyserver_hermes: Subscribed to hermes/error/audioServer/play
[DEBUG:2021-12-29 20:42:53,380] rhasspyserver_hermes: Subscribed to hermes/audioServer/GalaxyS6/playBytes/#
[DEBUG:2021-12-29 20:42:53,378] rhasspyserver_hermes: Subscribed to hermes/error/tts
[DEBUG:2021-12-29 20:42:53,377] rhasspyserver_hermes: Subscribed to hermes/tts/sayFinished
[DEBUG:2021-12-29 20:42:53,375] rhasspyserver_hermes: TTS timeout will be 30 second(s)

Das mosquitto-log hilft auch nicht weiter:
Zitat1640806973: New connection from 192.168.0.94 on port 1883.
1640806973: New client connected from 192.168.0.94 as Net::MQTT::Simple[YXHBGHGEWE] (c1, k60).
1640806973: Socket error on client Net::MQTT::Simple[YXHBGHGEWE], disconnecting.
1640807001: Client c16a640b-6e09-4162-a279-0e6adb148a83 has exceeded timeout, disconnecting.
1640807001: Socket error on client c16a640b-6e09-4162-a279-0e6adb148a83, disconnecting.
1640807005: Socket error on client Net::MQTT::Simple[EUFVQTOBDB], disconnecting.
1640807036: Client 56d85477-d812-4b85-ae87-122d0a8c704b has exceeded timeout, disconnecting.

Frustration...

LG

pah
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 29 Dezember 2021, 22:24:24
@pah
Mich wundert, dass tts/say keine sessionId enthält. Kommt tts/say letztlich gar nicht vom DialogManager? Die sessionId ist zwar optional, ist aber in diversen Tests immer enthalten.

Beim RHASSPY-M2C sind die IP und der Port eingetragen, mit welchen du ein mosquitto_sub -h IP -p Port auf dem FHEM-Server starten kannst.

Wenn der M2C keine Info vom DialogManager erhält, tippe ich darauf, das die Topics nicht aboniert sind. Trage testweise die Topics des mosquitto_sub im M2C ein. Hier die Werte von meinem M2C:attr rhasspyMQTT2 clientOrder RHASSPY MQTT_GENERIC_BRIDGE MQTT2_DEVICE
attr rhasspyMQTT2 subscriptions hermes/intent/+ hermes/dialogueManager/sessionStarted hermes/dialogueManager/sessionEnded hermes/start hermes/nlu/intentNotRecognize
Für deine TTS müsste noch hermes/tts/say rein. Bestimmt ist das richtig eingetragen aber vergleichen schadet nicht.

Ein tcpdump auf den mqtt-Port des Docker-Hosts mit anschließender Auswertung in Wireshark oder TShark würde den Störenfried identifizieren.

Gruß Jens

p.s. Bin erstaunt, was die Rhasspy-Console so alles ausgibt. Hier ein Auszug mit der kleinen TTS:[DEBUG:2021-12-30 10:10:36,638] rhasspydialogue_hermes: <- DialogueEndSession(session_id='wohnzimmer-alexa-dd58a452-839c-4186-97c3-71cf4aec9c0f', text='Ok - Licht im wohnzimmer ist eingeschaltet', custom_data='alexa')
[DEBUG:2021-12-30 10:10:36,641] rhasspydialogue_hermes: -> HotwordToggleOff(site_id='wohnzimmer', reason=<HotwordToggleReason.TTS_SAY: 'ttsSay'>)
[DEBUG:2021-12-30 10:10:36,641] rhasspydialogue_hermes: Publishing 44 bytes(s) to hermes/hotword/toggleOff
[DEBUG:2021-12-30 10:10:36,643] rhasspydialogue_hermes: -> AsrToggleOff(site_id='wohnzimmer', reason=<AsrToggleReason.TTS_SAY: 'ttsSay'>)
[DEBUG:2021-12-30 10:10:36,644] rhasspydialogue_hermes: Publishing 44 bytes(s) to hermes/asr/toggleOff
[DEBUG:2021-12-30 10:10:36,644] rhasspydialogue_hermes: Say: Ok - Licht im wohnzimmer ist eingeschaltet
[DEBUG:2021-12-30 10:10:36,647] rhasspydialogue_hermes: -> TtsSay(text='Ok - Licht im wohnzimmer ist eingeschaltet', site_id='wohnzimmer', lang=None, id='8c5183d4-c083-4581-af07-6ea422c9a803', session_id='wohnzimmer-alexa-dd58a452-839c-4186-97c3-71cf4aec9c0f', volume=None)
[DEBUG:2021-12-30 10:10:36,647] rhasspydialogue_hermes: Publishing 224 bytes(s) to hermes/tts/say
[DEBUG:2021-12-30 10:10:36,648] rhasspydialogue_hermes: Waiting for sayFinished (id=8c5183d4-c083-4581-af07-6ea422c9a803, timeout=10.0)
[DEBUG:2021-12-30 10:10:36,652] rhasspyasr_kaldi_hermes: <- AsrToggleOff(site_id='wohnzimmer', reason=<AsrToggleReason.TTS_SAY: 'ttsSay'>)
[DEBUG:2021-12-30 10:10:36,653] rhasspyasr_kaldi_hermes: Disabled (AsrToggleReason.TTS_SAY)
[DEBUG:2021-12-30 10:10:39,954] rhasspydialogue_hermes: <- TtsSayFinished(site_id='wohnzimmer', id='8c5183d4-c083-4581-af07-6ea422c9a803', session_id='wohnzimmer-alexa-dd58a452-839c-4186-97c3-71cf4aec9c0f')
[DEBUG:2021-12-30 10:10:39,956] rhasspydialogue_hermes: -> HotwordToggleOn(site_id='wohnzimmer', reason=<HotwordToggleReason.TTS_SAY: 'ttsSay'>)
[DEBUG:2021-12-30 10:10:39,957] rhasspydialogue_hermes: Publishing 44 bytes(s) to hermes/hotword/toggleOn
[DEBUG:2021-12-30 10:10:39,958] rhasspydialogue_hermes: -> AsrToggleOn(site_id='wohnzimmer', reason=<AsrToggleReason.TTS_SAY: 'ttsSay'>)
[DEBUG:2021-12-30 10:10:39,959] rhasspydialogue_hermes: Publishing 44 bytes(s) to hermes/asr/toggleOn
[DEBUG:2021-12-30 10:10:39,960] rhasspydialogue_hermes: Session ended nominally: wohnzimmer-alexa-dd58a452-839c-4186-97c3-71cf4aec9c0f
[DEBUG:2021-12-30 10:10:39,961] rhasspydialogue_hermes: -> AsrStopListening(site_id='wohnzimmer', session_id='wohnzimmer-alexa-dd58a452-839c-4186-97c3-71cf4aec9c0f')
[DEBUG:2021-12-30 10:10:39,962] rhasspydialogue_hermes: Publishing 94 bytes(s) to hermes/asr/stopListening
[DEBUG:2021-12-30 10:10:39,965] rhasspyasr_kaldi_hermes: <- AsrToggleOn(site_id='wohnzimmer', reason=<AsrToggleReason.TTS_SAY: 'ttsSay'>)
[DEBUG:2021-12-30 10:10:39,965] rhasspyasr_kaldi_hermes: Enabled
[DEBUG:2021-12-30 10:10:39,967] rhasspydialogue_hermes: -> DialogueSessionEnded(termination=DialogueSessionTermination(reason=<DialogueSessionTerminationReason.NOMINAL: 'nominal'>), session_id='wohnzimmer-alexa-dd58a452-839c-4186-97c3-71cf4aec9c0f', site_id='wohnzimmer', custom_data='alexa')
[DEBUG:2021-12-30 10:10:39,967] rhasspydialogue_hermes: Publishing 155 bytes(s) to hermes/dialogueManager/sessionEnded
[DEBUG:2021-12-30 10:10:39,969] rhasspydialogue_hermes: -> HotwordToggleOn(site_id='wohnzimmer', reason=<HotwordToggleReason.DIALOGUE_SESSION: 'dialogueSession'>)
[DEBUG:2021-12-30 10:10:39,969] rhasspydialogue_hermes: Publishing 53 bytes(s) to hermes/hotword/toggleOn
[DEBUG:2021-12-30 10:10:39,972] rhasspyasr_kaldi_hermes: <- AsrStopListening(site_id='wohnzimmer', session_id='wohnzimmer-alexa-dd58a452-839c-4186-97c3-71cf4aec9c0f')
[DEBUG:2021-12-30 10:10:39,972] rhasspyasr_kaldi_hermes: Stopping listening (session_id=wohnzimmer-alexa-dd58a452-839c-4186-97c3-71cf4aec9c0f)
[DEBUG:2021-12-30 10:10:39,995] rhasspydialogue_hermes: <- AudioPlayFinished(id='8c5183d4-c083-4581-af07-6ea422c9a803', session_id='wohnzimmer-alexa-dd58a452-839c-4186-97c3-71cf4aec9c0f')
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 30 Dezember 2021, 06:54:53
pah: Wie ist die Einstellung von "Audio Playing" an deiner Rhasspy-Zentrale? Bei mir steht die  auf "Disabled", und ich meine, das wäre auch für dein Setup mit "externalisierter Soundausgabe" die richtige.

Zitat von: Prof. Dr. Peter Henning am 29 Dezember 2021, 18:21:44
Ist das Thema "Timer" jetzt eigentlich stabil?
Mir sind keine Klagen bekannt - außer vielleicht der, dass die Doku verbesserungsfähig ist.
Letzter Stand dazu war der von drhirn aus https://forum.fhem.de/index.php/topic,113180.msg1148809.html#msg1148809:
ZitatErgebnis:
Keine Auffälligkeiten
(Da stehen auch Beispielsätze - einschl. des Abbrechens - drin.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 30 Dezember 2021, 10:28:55
Beim vorigen Logauszug hatte ich an der Base versehentlich die TTS auf "Disabled" gestellt, was der TTS-Ausgabe aber nichts ausmachte.
Hier ein Auszug mit TTS "Hermes MQTT".[DEBUG:2021-12-30 10:25:23,488] rhasspydialogue_hermes: <- DialogueEndSession(session_id='wohnzimmer-alexa-25f9f7bd-3cf0-40e0-a35f-c09915d5fcb4', text='Ok - Licht im wohnzimmer ist ausgeschaltet', custom_data='alexa')
[DEBUG:2021-12-30 10:25:23,490] rhasspydialogue_hermes: -> HotwordToggleOff(site_id='wohnzimmer', reason=<HotwordToggleReason.TTS_SAY: 'ttsSay'>)
[DEBUG:2021-12-30 10:25:23,491] rhasspydialogue_hermes: Publishing 44 bytes(s) to hermes/hotword/toggleOff
[DEBUG:2021-12-30 10:25:23,493] rhasspydialogue_hermes: -> AsrToggleOff(site_id='wohnzimmer', reason=<AsrToggleReason.TTS_SAY: 'ttsSay'>)
[DEBUG:2021-12-30 10:25:23,494] rhasspydialogue_hermes: Publishing 44 bytes(s) to hermes/asr/toggleOff
[DEBUG:2021-12-30 10:25:23,495] rhasspydialogue_hermes: Say: Ok - Licht im wohnzimmer ist ausgeschaltet
[DEBUG:2021-12-30 10:25:23,496] rhasspydialogue_hermes: -> TtsSay(text='Ok - Licht im wohnzimmer ist ausgeschaltet', site_id='wohnzimmer', lang=None, id='32004ce7-ade0-46e4-8f25-30a1f6265962', session_id='wohnzimmer-alexa-25f9f7bd-3cf0-40e0-a35f-c09915d5fcb4', volume=None)
[DEBUG:2021-12-30 10:25:23,497] rhasspydialogue_hermes: Publishing 224 bytes(s) to hermes/tts/say
[DEBUG:2021-12-30 10:25:23,497] rhasspydialogue_hermes: Waiting for sayFinished (id=32004ce7-ade0-46e4-8f25-30a1f6265962, timeout=10.0)
[DEBUG:2021-12-30 10:25:23,500] rhasspyasr_kaldi_hermes: <- AsrToggleOff(site_id='wohnzimmer', reason=<AsrToggleReason.TTS_SAY: 'ttsSay'>)
[DEBUG:2021-12-30 10:25:23,500] rhasspyasr_kaldi_hermes: Disabled (AsrToggleReason.TTS_SAY)
[DEBUG:2021-12-30 10:25:26,842] rhasspydialogue_hermes: <- TtsSayFinished(site_id='wohnzimmer', id='32004ce7-ade0-46e4-8f25-30a1f6265962', session_id='wohnzimmer-alexa-25f9f7bd-3cf0-40e0-a35f-c09915d5fcb4')
[DEBUG:2021-12-30 10:25:26,844] rhasspydialogue_hermes: -> HotwordToggleOn(site_id='wohnzimmer', reason=<HotwordToggleReason.TTS_SAY: 'ttsSay'>)
[DEBUG:2021-12-30 10:25:26,845] rhasspydialogue_hermes: Publishing 44 bytes(s) to hermes/hotword/toggleOn
[DEBUG:2021-12-30 10:25:26,847] rhasspydialogue_hermes: -> AsrToggleOn(site_id='wohnzimmer', reason=<AsrToggleReason.TTS_SAY: 'ttsSay'>)
[DEBUG:2021-12-30 10:25:26,847] rhasspydialogue_hermes: Publishing 44 bytes(s) to hermes/asr/toggleOn
[DEBUG:2021-12-30 10:25:26,848] rhasspydialogue_hermes: Session ended nominally: wohnzimmer-alexa-25f9f7bd-3cf0-40e0-a35f-c09915d5fcb4
[DEBUG:2021-12-30 10:25:26,849] rhasspydialogue_hermes: -> AsrStopListening(site_id='wohnzimmer', session_id='wohnzimmer-alexa-25f9f7bd-3cf0-40e0-a35f-c09915d5fcb4')
[DEBUG:2021-12-30 10:25:26,850] rhasspydialogue_hermes: Publishing 94 bytes(s) to hermes/asr/stopListening
[DEBUG:2021-12-30 10:25:26,852] rhasspydialogue_hermes: -> DialogueSessionEnded(termination=DialogueSessionTermination(reason=<DialogueSessionTerminationReason.NOMINAL: 'nominal'>), session_id='wohnzimmer-alexa-25f9f7bd-3cf0-40e0-a35f-c09915d5fcb4', site_id='wohnzimmer', custom_data='alexa')
[DEBUG:2021-12-30 10:25:26,853] rhasspydialogue_hermes: Publishing 155 bytes(s) to hermes/dialogueManager/sessionEnded
[DEBUG:2021-12-30 10:25:26,854] rhasspydialogue_hermes: -> HotwordToggleOn(site_id='wohnzimmer', reason=<HotwordToggleReason.DIALOGUE_SESSION: 'dialogueSession'>)
[DEBUG:2021-12-30 10:25:26,854] rhasspydialogue_hermes: Publishing 53 bytes(s) to hermes/hotword/toggleOn
[DEBUG:2021-12-30 10:25:26,859] rhasspyasr_kaldi_hermes: <- AsrToggleOn(site_id='wohnzimmer', reason=<AsrToggleReason.TTS_SAY: 'ttsSay'>)
[DEBUG:2021-12-30 10:25:26,860] rhasspyasr_kaldi_hermes: Enabled
[DEBUG:2021-12-30 10:25:26,862] rhasspyasr_kaldi_hermes: <- AsrStopListening(site_id='wohnzimmer', session_id='wohnzimmer-alexa-25f9f7bd-3cf0-40e0-a35f-c09915d5fcb4')
[DEBUG:2021-12-30 10:25:26,863] rhasspyasr_kaldi_hermes: Stopping listening (session_id=wohnzimmer-alexa-25f9f7bd-3cf0-40e0-a35f-c09915d5fcb4)
[DEBUG:2021-12-30 10:25:26,884] rhasspydialogue_hermes: <- AudioPlayFinished(id='32004ce7-ade0-46e4-8f25-30a1f6265962', session_id='wohnzimmer-alexa-25f9f7bd-3cf0-40e0-a35f-c09915d5fcb4')
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Prof. Dr. Peter Henning am 30 Dezember 2021, 10:38:37
So, ich habe jetzt noch ein paar weitere Tests gefahren. Rahmenbedingungen:

1. Alle eigenen MQTT2_CLIENTS abgekoppelt
2. Nur den "kleinen TTS-Service" von JensS angebunden
3. TTS auf Hermes MQTT gestellt

Variierte Parameter:

a.) interner MQTT-Server an Port 12183 oder externer MQTT-Server an Port 1883 -> Kein Unterschied
b.) "kleiner TTS" auf Maschine A oder auf Maschine B -> Kein Unterschied
c.) Audio Playing aplay oder disabled -> Kein Unterschied

Jedesmal wieder das gleiche Ergebnis: hermes/say wird vom "kleinen TTS" empfangen (und als Text in eine Datei geschrieben)
Die Antwort vom "kleinen TTS" wird von Rhasspy empfangen, aber irrerweise immer mit einer anderen id angezeigt, und Rhasspy geht nach 30 Sekunden in einen Timeout.

Beispiel:
ZitatTraceback (most recent call last):
...
    raise futures.TimeoutError()
concurrent.futures._base.TimeoutError
[DEBUG:2021-12-30 10:18:21,451] rhasspyserver_hermes: Handling TtsSayFinished (topic=hermes/tts/sayFinished, id=b29e6c7c-0675-471d-88b1-ea543bbc386c)
[DEBUG:2021-12-30 10:18:21,432] rhasspyserver_hermes: Publishing 147 bytes(s) to hermes/tts/say
[DEBUG:2021-12-30 10:18:21,432] rhasspyserver_hermes: -> TtsSay(text='Noch ein weiterer Test', site_id='default', lang=None, id='a37099f9-88c9-4c94-a991-0110a3cda6e8', session_id='', volume=1.0)

Der einzige Weg, den Timeout zu vermeiden, ist bisher, TTS nicht auf "Hermes MQTT" zu stellen. Sondern auf einen der internen TTS-Dienste. Dessen Ausgabe kann man zwar mit "Audio Playing"=disabled unterdrücken, das hat aber keinen Einfluss auf das Ergebnis.

Interessant ist der MQTT-Mitschnitt, wenn z.B. nanoTTS angekoppelt ist:
Zitat[DEBUG:2021-12-30 10:21:48,310] rhasspyserver_hermes: Handling AudioPlayBytes (topic=hermes/audioServer/default/playBytes/ae2cced7-0ace-4950-a6ef-605478a3e409, id=799aaaed-07f1-42d3-b454-aa2578c147c6)
[DEBUG:2021-12-30 10:21:48,192] rhasspyserver_hermes: Handling TtsSayFinished (topic=hermes/tts/sayFinished, id=799aaaed-07f1-42d3-b454-aa2578c147c6)
[DEBUG:2021-12-30 10:21:48,176] rhasspyserver_hermes: Publishing 141 bytes(s) to hermes/tts/say
[DEBUG:2021-12-30 10:21:48,175] rhasspyserver_hermes: -> TtsSay(text='Es grünt so grün', site_id='default', lang=None, id='ae2cced7-0ace-4950-a6ef-605478a3e409', session_id='', volume=1.0)

Hier kommt auch eine zweite Id ins Spiel - die das erste Mal bei sayFinished verwendet wird. Sie wird ebenfalls verwendet beim playBytes - aber dort taucht die erste id (nicht siteId !) als MQTT Knoten auf.

LG

pah
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 30 Dezember 2021, 10:46:45
Da ist der Wurm drin...
Ich schlage vor, alle Instanzen + Docker + Images zu deaktivieren, löschen und komplett neu zu installieren.
Auf meiner Base ist das deb-Paket installiert.

Gruß Jens

p.s. Mir fällt auf, dass in deiner Log "rhasspyserver_hermes" und in meiner "rhasspydialogue_hermes" steht. Als DialogManager nutze ich "Rhasspy (Recommend)".

p.p.s. @pah Wie sind deine Erfahrungen mit der offline "Mozilla DeepSpeech" als STT? Kaldi funktioniert zwar aber wenn es besser gehen würde, wäre das nicht schlecht.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Gisbert am 01 Januar 2022, 20:03:55
Hallo Jörg,

der "senkrechte Strich" hat wieder bei mir zugeschlagen.
Die Antworten aus der Android-App waren einige Tage in Ordnung, d.h. wie erwartet. Heute bekomme ich aber als gesprochene Antwort anscheinend alle Optionen, die vorgesehen sind, inkl. der "senkrechten Striche".

Der Befehl wird ausgeführt, aber als Antwort bekomme ich in etwa das folgende:
ZitatZu Diensten senkrechter Strich Gerne senkrechter Strich Ok usw.
Die Reihenfolge kann u. U. auch anders sein.

In der Andriod-App steht unter "DIALOGUE" "EndSession text": Gerne!|wird erledigt|ok|jawohl|zu diensten - siehe auch Screenshot.

Kannst du dich der Sache annehmen?

Viele Grüße Gisbert
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 02 Januar 2022, 08:17:36
Zitat von: Gisbert am 01 Januar 2022, 20:03:55
der "senkrechte Strich" hat wieder bei mir zugeschlagen.
Hmmm....

Leider habe ich Schierigkeiten, diese Fehlerbeschreibung in konkrete Code-Stellen umzusetzen.
Zum einen bin ich ziemlich sicher, dass nirgendwo eine Funktion verbaut ist, die einen vorhandenen "senkrechten-Strich-Text" erst auseinandernimmt und dann wieder anders zusammensetzt. Wenn es also unterschiedliche Ausgaben gibt, waren die auch bereits unterschiedlich notiert - irgendwo in deiner Konfiguration. Die kenne ich aber nicht im Detail. Das hier gepostete sieht nach "DefaultConfirmation" aus, und da hatte ich bisher keinen vergleichbaren Effekt bei mir beobachten können, wenn die Antwort aus den Standardroutinen generiert wird.

Das kann durchaus anders sein, wenn die response aus einen individuellen Mapping kommt, und da bin ich nämlich auch nicht sicher, dass das "shuffle" nicht an allen Stellen korrekt implementiert ist.

Daher brauche ich etwas spezfischere Info:

- Wenn das passiert, ist es immer so? Oder beim nächsten vergleichbaren Befehl an dasselbe Gerät wieder anders?
- Ist es die Antwort aus dem "Standard-Repertoire" oder ist sie gerätespezfisch (rhasspyMapping)? Wenn du was gerätespezifisches angegeben hast, würde ich empfehlen, dort was anzugeben, das sich vom Standard unterscheidet (sonst macht es so oder so keinen Sinn, außer zum debuggen...).
- wenn es wirklich aus dem Standard käme (was ich mir noch nicht recht vorstellen kann), und nach "kaputt" auch erst mal dauerhaft auf "kaputt" bleibt: Ist das Verhalten nach einem Neustart wieder "zufällig" (und mit einzelnen Antworten), oder gibt es (empfunden) keine erkennbare Logik hinter dem, was passiert?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 02 Januar 2022, 08:20:05
Zitat von: Beta-User am 29 Dezember 2021, 16:04:10
(239.67 kB - runtergeladen 0 Mal.)
?

Kein Interesse an der "Babble/STT/TTS-Version"? Keine Zeit bisher? Übersehen?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Prof. Dr. Peter Henning am 02 Januar 2022, 10:00:34
Bisher keine Zeit: Jahresabschluss meines Unternehmens, Umsatzsteuervoranmeldung, Endredaktion des neuen Buches, Vorbereitung Landesparteitag, Vorbereitung Lehre Wien. Und so unbedeutende Sachen wie Familie.

LG

pah
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 02 Januar 2022, 11:07:37
Generell finde ich es gut, das Modul für eine Mehrstufigkeit zu öffnen. Vorerst beschäftige ich mich allerdings mit Verbesserung der akustischen Erkennung und der Dialogfähigkeit.
In der SNIPS-Hermes-Referenz steht was zur Nutzung von Slots in continueSession. Die Info habe ich auch bei anderen HERMES-MQTT-Produkten gesehen, außer bei Rhasspy. Allerdings fand ich in bei Keinem einen Code dazu, die Daten auszuwerten. Scheint wohl ein ToDo von Snips gewesen zu sein...

Gruß Jens
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Prof. Dr. Peter Henning am 02 Januar 2022, 18:59:15
ZitatGenerell finde ich es gut, das Modul für eine Mehrstufigkeit zu öffnen

Das sollte man genauer überlegen. Man könnte - so wie ich das vor etlichen Jahren mit OWX gemacht habe - ein generisches Sprachsteuerungsmodul haben, das zusätzlich spezifische Interface-Module kennt (z.B. Rhasspy) kennt und verschiedene Backends zum Schalten/Abfragen

LG

pah
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 03 Januar 2022, 09:48:21
Zitat von: Prof. Dr. Peter Henning am 02 Januar 2022, 18:59:15
Das sollte man genauer überlegen. Man könnte - so wie ich das vor etlichen Jahren mit OWX gemacht habe - ein generisches Sprachsteuerungsmodul haben, das zusätzlich spezifische Interface-Module kennt (z.B. Rhasspy) kennt und verschiedene Backends zum Schalten/Abfragen
Prinzipiell wäre das denkbar. Zumindest sind die meisten internen Strukturen bereits so aufgebaut, dass man die Funktionsblöcke relativ leicht wiederverwenden können sollte, und die zur Verfügung stehenden Optionen sind nach meinen Eindruck (der allerdings betr. andere Lösungen zugegebenermaßen sehr oberflächlich ist) sehr gut auf FHEM abgestimmt und bieten eine ziemliche Flexibilität in der Konfiguration von "speziellen Fällen" und Anforderungen. Da die Hauptkonfiguration "an den Devices" stattfindet (ggf. mehrsprachig), ist es mAn. auch vergleichsweise durchschaubar.

Der zentrale "mach was"-Dispatcher ist auch eher simpel, es müssen halt input-seitig passende Datenstrukturen geliefert werden... Der Teil sollte kein Hexenwerk sein, wenn denn passender Input kommt.

Antworten ist auch eher simpel, aber jeder Partner (im Moment: Rhasspy, "msg" und "external speak") hat dann doch im Detail etwas andere Anforderungen.

Die Hauptschwierigkeit ist vermutlich, aus Gesprochenem/Geschriebenem passende Datenstrukturen zu generieren bzw. ggf. dann auch die Gegenseite mit "slots" zu versorgen...

Bin für Vorschläge offen :) .
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 03 Januar 2022, 10:46:11
Zitat von: Beta-User am 03 Januar 2022, 09:48:21
Die Hauptschwierigkeit ist vermutlich, aus Gesprochenem/Geschriebenem passende Datenstrukturen zu generieren bzw. ggf. dann auch die Gegenseite mit "slots" zu versorgen...
Durch die Schaffung eines generischen Sprachsteuerungsmoduls, welchem die Deviceattribute gDT, speechEnable, speechMapping, speechName, speechRoom, etc. zugeordnet sind, würde es einen Standard und eine Schnittstelle für div. Sprachsteuererungs-, Chat- und Bot-Module bieten. Rhasspy würde seinen Dienst dort zur Verfügung stellen und könnte dabei auf einen Datenbestand zurückgreifen bzw. müsste nicht selbst alles einsammeln. Die statischen Sentences wären eine andere Baustelle.

Mit deiner umfangreichen gDT-Generierung könnten bei Definition des zentr. Moduls, alle Devices vorbelegt und erstmal deaktiviert werden.

Gruß Jens
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 03 Januar 2022, 10:59:26
Zitat von: JensS am 03 Januar 2022, 10:46:11
Durch die Schaffung eines generischen Sprachsteuerungsmoduls, welchem die Deviceattribute gDT, speechMapping, SpeechName, speechRoom, etc. zugeordnet sind, würde einen Standard und eine Schnittstelle für div. Sprachsteuererungsmodule, Chat- und Bot-Module bieten. Rhasspy würde seinen Dieste dort zur Verfügung stellen un könnte dabei auf einen Datenbestand zurückgreifen bzw. müsste nicht selbst alles einsammeln.
MAn: Jein.
Das zentrale Modul würde  dann das Einsammeln übernehmen, wobei - wie jetzt bei RHASSPY - mehrere Instanzen möglich sein müssen, um mehrere User (mit unterschiedlichen Berechtigungen), mehrere Sprachen, .... möglich zu machen. Im Prinzip würde man mAn. den eigentlichen Kern belassen und dann nur die "Schnittstellen" drumrum anders bedienen.

Wie hatte ich das sinngemäß neulich zum generischen "Messenger"-Interface geschrieben: RHASSPY etabliert eine "sprachliche Meta-Ebene", die man im Prinzip ohne weiteres generisch nutzen kann. Wobei "eine" eben verkürzt ist: es können auch "mehrere sprachliche Meta-Ebenen" sein, RHASSPY hat damit mAn. kein prinzipielles Problem...

Zitat von: JensS am 03 Januar 2022, 10:46:11
Mit deiner umfangreichen gDT-Generierung könnten bei Definition des zentr. Moduls, alle Devices vorbelegt und erstmal deaktiviert werden.
Hmmm, zum einen: Es gibt ja auch weitere Lösungen, die ihr eigenes "homeBridgeMapping" kennen (das sich gelegentlich "beißt", wenn ich das v.a. bzgl. gassistant richtig verstanden habe). Müßte/könnte man ggf. auch berücksichtigen, ich habe bisher allerdings nicht die Notwendigkeit gesehen, mich da näher einzufuchsen.
Zum anderen sind im rhasspyMapping ja auch Antwortsätze drin. Wenn das so bleiben soll, muss das pro Instanz vorgehalten werden, eine "one-for-all"-Lösung geht dann nicht. Tendenziell sehe ich - abgesehen vom höheren Datenvolumen im Speicher - im Moment noch kein wirkliches Argument, warum man an der Stelle was anderes bauen sollte.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Prof. Dr. Peter Henning am 03 Januar 2022, 21:31:16
ZitatRHASSPY hat damit mAn. kein prinzipielles Problem...
Na ja. Alle tappen immer noch Dunklen wegen der externen MQTT-Anbindung eines TTS-Service, auch im Rhasspy-Forum wird nur wild geraten

Babble habe ich inzwischen um Attribute für Devices erweitert:
- babbleDeviceType (fast dasselbe wie genericDeviceType. habe das nur temporär etwas stärker eingeschränkt, siehe unten)
- babblePlace (eben nicht der "Room" - sondern hier kann man auch einen Wert wie "hinter der Kellertür" ablegen)

Auf entfernten FHEM-Installationen kann man mit ein paar Codezeilen (z.B. in einer Datei 99_BabbleUtils.pm) einen Service installieren, der beim Aufruf von <ip>:8083/fhem/babble_devlist eine JSON-Struktur liefert, die im lokalen Data-Hash von Babble abgelegt wird. Damit kann Babble auch Devices steuern und abfragen, die auf den externen FHEM-Installationen liegen. Und zwar ohne dass ich sie Babble explizit bekannt mache.

Der Satz "Schalte das Licht hinter der Kellertür an" wird zunächst in die Struktur Gerät=licht, Verb=schalten, Ort=hinter der Kellertür transformiert (das ist die zentrale Aufgabe von der semantischen Analyse).

- Wenn dazu ein Kommando im Babble-Datenhash {DATA}{licht}{hinter der Kellertür}{schalten} vorliegt, wird das ausgeführt. Diese Möglichkeit ist deshalb wichtig, weil damit in der Babble-Weboberfläche von Babble beliebig komplizierte Kommandos definiert werden können, die lokal oder entfernt ausgeführt werden (eben nicht generische Kommandos)

- Wenn nicht, werden die von den auf den entfernten und der lokalen FHEM-Installation vorliegenden Devices mit babbleDeviceType=light durchsucht, ob eines den babblePlace=hinter der Tür hat, und ggf. dieses geschaltet (eben generische Kommandos)
- Wenn auch das nicht weiterführt, wird der Satz an den Chatbot weitergereicht

LG

pah
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 03 Januar 2022, 23:38:05
Zitat von: Prof. Dr. Peter Henning am 03 Januar 2022, 21:31:16
Na ja. Alle tappen immer noch Dunklen wegen der externen MQTT-Anbindung eines TTS-Service, auch im Rhasspy-Forum wird nur wild geraten
Die Notlaufvariante ist für mich derzeit die Naheliegendste. Das kann man vermutlich in rhasspyserver_hermes/__init__.py ab #537 verorten. Übrigens - wie sieht deine profile.json aus?

Gruß Jens
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 04 Januar 2022, 05:57:08
Zitat von: Prof. Dr. Peter Henning am 03 Januar 2022, 21:31:16
Na ja. Alle tappen immer noch Dunklen wegen der externen MQTT-Anbindung eines TTS-Service, auch im Rhasspy-Forum wird nur wild geraten
Zum einen: Ich hatte geschrieben, dass RHASSPY damit mAn. kein prinzipielles Problem hat, es ging nicht um Rhasspy...

Mein Bauchgefühl meint immer noch, das mit der Verwendung von "default" als "Einheits-siteId" wäre ein Problem, aber ich komme an der Stelle auch nicht zum Testen.

Deine neuen Attribute schaue ich mir bei Gelegenheit an, im svn war dazu nichts zu finden. Spontan finde ich
- die Doppelung zu genericDeviceType fragwürdig
- das mit "babblePlace" bedenkenswert (bisher habe ich sowas über Doppelungen am Device-Namen oder im rhasspyRoom gelöst)
- die Idee, auf "fremden" Instanzen was schalten zu können sehr interessant. (Komme von einem "Einheitssystem", da hat man sowas nicht unbedingt im Fokus. Das läßt sich bis auf weiteres nur dadurch lösen, dass man die betreffenden Devices in die Zielinstanz holt oder eine 2. Rhasspy-Instanz aufsetzt, die dann aber andere/eigene Intents bzw. Satelliten braucht).

Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Prof. Dr. Peter Henning am 04 Januar 2022, 06:18:49
Ich habe mir noch ein paar weitere Gedanken über ein generisches Modul gemacht. Nennen wir es mal Nlui (NLU Intenthandler).

- Nlui wird mit 5 Parametern aufgerufen:
-- device = zu steuerndes/abzufragendes Gerät. Dabei kann es sich um ein generisches Device handeln (z.B. "Temperatur") oder um ein spezielles Device (z.B. "Depot")
-- place = Ort des Gerätes. Das kann ein Raum sein, muss aber nicht. Man könnte hier hierarchisch arbeiten, z.B. "Wohnzimmer" und "Wohnzimmer:Decke"
-- verb = durchzuführende Handlung, z.B. "stellen/setzen", "öffnen", "schließen", "sagen"
-- target = optionaler Wert, auf den das Gerät zu setzen ist, z.B. "xx Prozent", "yy Grad", bzw. welcher Wert abzufragen ist
-- sink = Gerät für die Weiterverarbeitung des Ergebnisses, auch das könnte wieder zweiteilig sein, z.B. "speak:SoundTouchEG"

Nlui sollte erstens natürlich über eine interne Liste der generischen Devices verfügen. Wobei mir die Frage in den Sinn kommt, ob wir so etwas im Wiki haben, Wenn nicht, sollte dies schnellstmöglich angelegt werden und als Standard für FHEM gelten.

Nlui sollte auch Übersetzungen vornehmen, je nach eingestellter Sprache sollte also

Nlui("Temperatur","Wohnzimmer","sagen","","speak:SoundTouchEG")

Nlui("temperature","Living Room","say","","speak:SoundTouchEG")

dasselbe bewirken.

Die Kombination aus device und verb bestimmt eindeutig das generische Device, z.B.

Nlui("Temperatur","Gästebad","stellen","21 Grad","confirm") => Generisches Gerät ist "thermostat" (Spezialfälle Ofen und Kühlschrank werden damit ebenso abgedeckt). Die Kombination von "thermometer"und "Gästebad" führt bei mir z.B. zum FHEM-Kommando "set GB.HMHz_Clima desired-temp 21". Wichtig ist mir, dass das dieses Kommando ggf. auf einer anderen FHEM-Installation ausgeführt wird. Die Bestätigung erfolgt durch ein kurzes "OK" auf dem Spracheingabesystem (ein Tablet, in der Regel).

Nlui("Temperatur","Außen","sagen","speak:Tab1.EG") ==> Generisches Gerät ist "thermometer". FHEM-Kommando auf der entfernten FHEM-Installation ist "speak('Tab1.EG','Die Temperatur im Außenbereich beträgt '.ReadingsVal('A.OWB.T','temperature',undef).' Grad')". Dazu muss das FHEM-Device A.OWB.T nur über das Attribut genericDeviceType=thermometer und room=Aussenbereich verfügen. Das Matching "Außen" = "Aussenbereich" wird in Nlui vorgenommen (geht bei mir über Reguläre Ausdrücke ODER die Levenshtein-Distanz)

Alle nicht-generischen Geräte können sehr viel kompliziertere Dinge ausführen: Beispiel:

Nlui("Depot","","sagen","Wert","speak:SoundTouchEG") => sprich den Wert des Depots sowie die prozentuale Veränderung zu gestern auf der SoundTouch im Erdgeschoss

Nlui("Haus","","stören","aus","confirm") => schalte das Haus in den Nichtstören-Modus und bestätige dies auf dem Default-Weg

Soweit erstmal meine Anforderungen.

Natürlich könnte es verschiedene Nlui-Module geben. Wenn man sich auf die obigen Parameter einigen könnte, würde man bei jedem sprachverarbeitendem System jeweils nur angeben "RHASSPY", oder "Babble" und würde das entsprechend dann so nutzen. Die Schnittstelle kann von mir aus auch MQTT sein, obwohl ich das nicht für zielführend halte - mindestens ein direkter Unterprogrammaufruf "RHASSPY_Nlui" oder "Babble_Nlui" sollte möglich sein.

LG

pah
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Prof. Dr. Peter Henning am 04 Januar 2022, 06:24:09
Sieh an, auch schon wach...

Zitatdie Doppelung zu genericDeviceType fragwürdig
Das ist nur temporär, siehe den roten Text im vorigen Post.

Zitatdie Idee, auf "fremden" Instanzen was schalten zu können sehr interessant.
Funktioniert bei Babble schon seit Jahren (Attribute remoteFHEM0...3)

Ist aber in meiner Bastelversion von Babble wesentlich erweitert. Auf dem Zielsystem muss nur
########################################################################################
#
# 99_BabbleUtils.pm
#
# Collection of various routines for Babble purpose
# Prof. Dr. Peter A. Henning
#
# $Id: 99_BabbleUtils.pm 2022-01- pahenning $
#
########################################################################################
#
#  This programm is free software; you can redistribute it and/or modify
#  it under the terms of the GNU General Public License as published by
#  the Free Software Foundation; either version 2 of the License, or
#  (at your option) any later version.
#
#  The GNU General Public License can be found at
#  http://www.gnu.org/copyleft/gpl.html.
#  A copy is found in the textfile GPL.txt and important notices to the license
#  from the author is found in LICENSE.txt distributed with these scripts.
#
#  This script is distributed in the hope that it will be useful,
#  but WITHOUT ANY WARRANTY; without even the implied warranty of
#  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
#  GNU General Public License for more details.
#
########################################################################################

package main;
use strict;
use warnings;
use POSIX;
use JSON;

sub BabbleUtils_Initialize($$)
{
  my ($hash) = @_;
 
  $data{FWEXT}{"/Babble_devlist"}{FUNC} = "Babble_GatherDevices";
  $data{FWEXT}{"/Babble_devlist"}{FORKABLE} = 0;
}

sub Babble_GatherDevices(){

  my %devlist = ();
 
  foreach my $dev (sort keys %defs) {
    my $name  = $defs{$dev}{NAME};
    my $type  = AttrVal($name,"babbleDeviceType",undef);
    #-- skip if empty babbleDeviceType attribute
    next if( !$type );
    #-- more Babble data
    my $place  = AttrVal($name,"room",undef);
    my $bplace = AttrVal($name,"babblePlace",undef);
    my $bname  = AttrVal($name,"babbleDevice",undef);
   
    $devlist{$dev}->{'type'}=$type;
    $devlist{$dev}->{'place'}=(defined($bplace))?$bplace:$place;
    $devlist{$dev}->{'bname'}=(defined($bname))?$bname:$name;
  }
  my $json = encode_json \%devlist;
  $FW_RETTYPE = "application/json";
  $FW_RET="";                                         
  FW_pO $json;
  return ($FW_RETTYPE, $FW_RET);         
}
1;

als Modul existieren, dann holt Babble sich die Liste der generischen Devcies und legt sie in sein Datenhash.

Zitatim svn war dazu nichts zu finden
Stimmt, das ist brandneu.

LG

pah
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Prof. Dr. Peter Henning am 04 Januar 2022, 09:09:30
Zitatdie Doppelung zu genericDeviceType fragwürdig

Noch ein Nachtrag dazu. Es braucht m.E. drei Attribute

- ein genericDeviceType 
- ein NLU-friendly-Devicename ==> nluDevice
- einen NLU-bezogenen Ort ==> nluPlace

LG

pah

Edit: Ich habe hier https://wiki.fhem.de/wiki/Attribut_genericDeviceType#genericDeviceType mit einem solchen Wiki-Eintrag begonnen. ACHTUNG: Das ist noch nicht vollständig, das Ziel ist hier einen Konsens zu finden, der den unterschiedlichen Systemen (von A wie Alexa bis Z wie Rhasspy) als Standard dienen kann. Und ich würde gerne das FHEM-fremde "homebridgemapping" aus dieser Tabelle herauslassen, dass kann jedes der genannten Systeme selbst definieren.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 04 Januar 2022, 10:06:12
Zu den Nlui-Ideen und -Anforderungen:

Meine Thesen:
- Es sollte ein "leading FHEM" (pro Sprache, "Server") geben können,  Nlui sollte einen Client-Modus beherrschen, über den das "leading FHEM" entfernte Konfigurationen abfragen und integrieren kann;
- (otionale) Mehrsprachigkeit ist Pflicht;
- Es braucht pro Sprache eine Nlui-Instanz
- Nlui hat ein "single point of entry" pro Sprache, (wenn der content potentiell für andere Instanzen gedacht sein könnte), es gibt pro Sprache also nur eine Nlui-"Server"-Instanz;
- Der "mach was"-Aufruf hat (in der Regel) mit benannten Parametern zu erfolgen (!)
- Das Gesamtsystem der Nlui-Optionen ist so auszulegen, dass beliebig viele Sprachen und Client-Systeme angebunden werden können, dabei kann FHEM_A für Sprache x "Server" (Zentralinstanz) sein, für FHEM_B aber Client (in einer anderen Sprache);
- Es sollte Optionen geben, im Prinzip beliebige Optionen aus einer Nlui-Instanz direkt auszuführen (ohne "dummy+x"-Geraffel), einschließlich beliebigem Perl-Code;
- interne Gruppen-Strukturen sind Pflicht.

Zitat von: Prof. Dr. Peter Henning am 04 Januar 2022, 06:18:49
- Nlui wird mit 5 Parametern aufgerufen:
MAn. ist das eine überflüssige Einschränkung. Häufig reichen 2-3 Angaben (aus vielen möglichen), um eine eindeutige Aktion ausführen zu können. Es sollte Aufgabe von Nlui sein, "richtig raten" zu können, was der User letztendlich will. Zu übergeben sind strukturierte Daten, würde "parseParams"-kompatible Schreibweisen vorschlagen, alternativ JSON-encoded. "Raten nach Stellung im Array" ist möglich, aber eine Notlösung. Prototypes für Parameter-Vorgaben gehen gar nicht (!). Die sind in diesem Kontext hier mAn. extrem fehleranfällig, sobald User ins Spiel kommen und damit hantieren sollen.

Zitat-- device = zu steuerndes/abzufragendes Gerät. Dabei kann es sich um ein generisches Device handeln (z.B. "Temperatur") oder um ein spezielles Device (z.B. "Depot")
"generische Devices" in diesem Sinne sind mAn. in mehrfacher Hinsicht ein Problem.
- es gibt effektiv keine Eindeutigkeit zwischen gDT und verfügbaren Optionen, v.a. nicht, wenn es um Abfragen geht. MAn. kann man das nur lösen, indem man die "Reading-Namen" normiert (z.B.: gemessene Temperatur ist immer "temperature", Ziel-Temperatur ist immer "desired-temp"). Sonst braucht man "für jeden Scheiß" einen readingsProxy (oder dev_proxy). Man denke an einen Raumthermostat (thermostat) oder einen Shelly/ZWave-Aktor mit externem Temp-Fühler (gDT: switch)
- "Device" in diesem Sinn kann auch eine Gruppe von Devices sein. Der Umweg über (z.B.) structure sollte unnötig sein, Nlui sollte wissen, wie man mit sowas umzugehen hat.

Zitat-- place = Ort des Gerätes. Das kann ein Raum sein, muss aber nicht. Man könnte hier hierarchisch arbeiten, z.B. "Wohnzimmer" und "Wohnzimmer:Decke"
Überlegenswert.

Zitat-- verb = durchzuführende Handlung, z.B. "stellen/setzen", "öffnen", "schließen", "sagen"
Muss ich mir erst eine Meinung zu bilden. Finde es als alleiniges Kriterium fehleranfällig, es sollte Möglichkeiten geben, Nlui eine klare "Absicht" mitzuteilen, wenn diese bekannt ist.

Zitat-- target = optionaler Wert, auf den das Gerät zu setzen ist, z.B. "xx Prozent", "yy Grad", bzw. welcher Wert abzufragen ist
Ja. Kann aber mehrteilig/mehrdeutig sein. Wünschenswert wäre eine Vorverarbeitung außerhalb Nlui und die Übergabe strukturierter Daten (Wert und (ggf.) Einheit getrennt).

Zitat-- sink = Gerät für die Weiterverarbeitung des Ergebnisses, auch das könnte wieder zweiteilig sein, z.B. "speak:SoundTouchEG"
agreed. Ist m.E. optional, Nlui kann das per default aus der "Quelle" der Anfrage herleiten. Diese ist (otional, aber erwünscht) zu übergeben.

ZitatNlui sollte erstens natürlich über eine interne Liste der generischen Devices verfügen. Wobei mir die Frage in den Sinn kommt, ob wir so etwas im Wiki haben, Wenn nicht, sollte dies schnellstmöglich angelegt werden und als Standard für FHEM gelten.
a) die heute vorhandene Liste der gDT ist bereits "unendlich" (sensor, ContactSensor, Contact, ...);
b) die Festlegung einer sinnvollen Zahl von "supporteten gDT" wäre wünschenswert, Nlui kann ein "Standardisierungs-mapping" in diese gDT bereitstellen;
c) gDT => Option funktioniert häufig nicht (s.o.). gDT ist daher nur ein Anhaltspunkt, wichtiger sind aus meiner Sicht standardisierte Reading-Namen (bisher: keine konstruktive Resonanz auf meine diesbezügliche Initiative im Developer-Bereich (!)). Aus dem Reading-Namen ergibt sich die Abfrage-Möglichkeit, für setter ist der User zuständig (?).

ZitatNlui sollte auch Übersetzungen vornehmen, je nach eingestellter Sprache sollte also

Nlui("Temperatur","Wohnzimmer","sagen","","speak:SoundTouchEG")

Nlui("temperature","Living Room","say","","speak:SoundTouchEG")

dasselbe bewirken.
Sehe ich skeptisch. Es dürfte kein Problem sein, Nlui eine "Übersetzung" für standardisierte allgemeine Begrifflichkeiten (Temperature=>temperature, sagen=>say, mach=>set) machen zu lassen. Das sollte aber relativ eng begrenzt sein, das Ziel immer Kleinschreibung/englische bzw. numerische Standardisierung (rot=>0).
Was mAn. nicht geht, ist die Übersetzung von "FHEM-Variablen" wie 'wohnzimmer=>"living room"'. Das ist mAn. Aufgabe des Konfigurators, das pro Sprache (je in einer eigenen Nlui-Instanz) festzuzurren.

Daher sehe ich das auch nicht als zwingend bzw. teilweise zu eng an:
Zitat von: Prof. Dr. Peter Henning am 04 Januar 2022, 09:09:30
Noch ein Nachtrag dazu. Es braucht m.E. drei Attribute

- ein genericDeviceType 
- ein NLU-friendly-Devicename ==> nluDevice
- einen NLU-bezogenen Ort ==> nluPlace
- Dass man (uU. mehrere!) "sprechbare Namen" (pro Sprache!) braucht, ist klar. Ist der Device-Name "unaussprechlich", ist es zwingend...
- Der "sprechbare Ort" kann sich bereits aus "room" ergeben. Das ist daher m.E. nicht zwingend. Wichtiger: ein Device kann sich (gleichzeitig) an mehreren Orten "befinden". Ich will sagen können: "Mach alle Lichter im Erdgeschoss aus"

ZitatDie Kombination aus device und verb bestimmt eindeutig das generische Device, z.B.

Nlui("Temperatur","Gästebad","stellen","21 Grad","confirm") => Generisches Gerät ist "thermostat" (Spezialfälle Ofen und Kühlschrank werden damit ebenso abgedeckt). Die Kombination von "thermometer"und "Gästebad" führt bei mir z.B. zum FHEM-Kommando "set GB.HMHz_Clima desired-temp 21".
Provokativ formuliert: Das paßt nur, we man das Beispiel passend wählt...
Was machst du, wenn im Wohnzimmer 2 oder Devices da sind, die "thermostat" sind?
Und wieso soll "mach wärmer" oder "mach leiser" nicht auch ausreichen?

Zitat
Wichtig ist mir, dass das dieses Kommando ggf. auf einer anderen FHEM-Installation ausgeführt wird. Die Bestätigung erfolgt durch ein kurzes "OK" auf dem Spracheingabesystem (ein Tablet, in der Regel).
Remote-Anbidnung kann ich nachvollziehen, wie, wäre zu diskutieren.
Bestätigungsoptionen sind m.E. auch ein "Muss".

Zitat
Nlui("Temperatur","Außen","sagen","speak:Tab1.EG") ==> Generisches Gerät ist "thermometer". FHEM-Kommando auf der entfernten FHEM-Installation ist "speak('Tab1.EG','Die Temperatur im Außenbereich beträgt '.ReadingsVal('A.OWB.T','temperature',undef).' Grad')". Dazu muss das FHEM-Device A.OWB.T nur über das Attribut genericDeviceType=thermometer und room=Aussenbereich verfügen. Das Matching "Außen" = "Aussenbereich" wird in Nlui vorgenommen (geht bei mir über Reguläre Ausdrücke ODER die Levenshtein-Distanz)
Das mit der Levenshtein-Distanz wäre was neues, der Rest sollte sich mit obigen allgemeinen Anforderungen abdecken lassen.

Zitat
Alle nicht-generischen Geräte können sehr viel kompliziertere Dinge ausführen: Beispiel:
Prinzipiell stellt sich dann halt die Frage, wie man "nicht-generische Geräte" allgemein kenntlich macht bzw. der Server-Instanz mitteilen kann, dass/wie beliebiger Perl-Code auf der Remote-Instanz "ausgelöst" werden kann. In diese Richtung geht jedenfalls für Abfragen mein Vorschlag mit dem gDT "info".

Zitat
Natürlich könnte es verschiedene Nlui-Module geben.
Wenn möglich, würde ich dafür plädieren, ein einziges Nlui-Modul bereitzustellen. Es ist (aus Usersicht) komplex genug, dieses dann jeweils zu konfigurieren, wir brauchen m.E. nicht auch noch mehrere Varianten...

Zitat
Wenn man sich auf die obigen Parameter einigen könnte, würde man bei jedem sprachverarbeitendem System jeweils nur angeben "RHASSPY", oder "Babble" und würde das entsprechend dann so nutzen.
Wie gesagt: Der zu übergebende Parameter-Satz muss aus meiner Sicht flexibel im Sinne von "einige aus vielen" sein.

Zitat
Die Schnittstelle kann von mir aus auch MQTT sein, obwohl ich das nicht für zielführend halte - mindestens ein direkter Unterprogrammaufruf "RHASSPY_Nlui" oder "Babble_Nlui" sollte möglich sein.
Ich hänge nicht speziell an MQTT und würde in jedem Fall innerhalb einer FHEM-Installation auch immer den direkten Programmaufruf bevorzugen (aber mit benannten Parametern bzw. der Übergabe eines Hashes!). Die Frage ist eher, wie man strukturierte Daten als Parameter an entfernte FHEM-Instanzen übergibt. Da ist MQTT/JSON für mich halt "easy", bin aber offen für andere Vorschläge.

[OT]
:o Nicht ernst gemeint, oder:
Zitat von: Prof. Dr. Peter Henning am 04 Januar 2022, 06:24:09

package main;
[...]
use POSIX;

[/OT]
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Prof. Dr. Peter Henning am 04 Januar 2022, 10:34:55
Zitat- Es sollte ein "leading FHEM" (pro Sprache, "Server") geben können,  Nlui sollte einen Client-Modus beherrschen, über den das "leading FHEM" entfernte Konfigurationen abfragen und integrieren kann;
Das halte ich für wenig hilfreich, weil das bedeuten würde, entfernte Nluis auch zu konfigurieren. Das oben beschriebene Verfahren mit einem ganz schlanken Code auf Seite der Slaves, der keine Konfiguration benötigt, halte ich für nutzerfreundlicher

Zitat- (otionale) Mehrsprachigkeit ist Pflicht;
Ich bin einer der Wenigen, der in Module so etwas einbaut...

Zitat- Es braucht pro Sprache eine Nlui-Instanz
Das folgt schon aus der unterschiedlichen Grammatik

Zitat- Der "mach was"-Aufruf hat (in der Regel) mit benannten Parametern zu erfolgen (!)
Das ist zwar Folklore, aber dem werde ich mich nicht entgegenstellen.

Zitat
- Das Gesamtsystem der Nlui-Optionen ist so auszulegen, dass beliebig viele Sprachen und Client-Systeme angebunden werden können, dabei kann FHEM_A für Sprache x "Server" (Zentralinstanz) sein, für FHEM_B aber Client (in einer anderen Sprache);


Zitat- Es sollte Optionen geben, im Prinzip beliebige Optionen aus einer Nlui-Instanz direkt auszuführen (ohne "dummy+x"-Geraffel), einschließlich beliebigem Perl-Code;
OK, Du meinst "Operationen", nehme ich an.

Zitat- interne Gruppen-Strukturen sind Pflicht.
Aber wir haben doch Gruppenstrukturen in FHEM - warum das Rad zum zweiten Mal erfinden? Siehe unten.

ZitatZitat von: Prof. Dr. Peter Henning am Heute um 06:18:49
    - Nlui wird mit 5 Parametern aufgerufen:
MAn. ist das eine überflüssige Einschränkung.
OK

Zitat"generische Devices" in diesem Sinne sind mAn. in mehrfacher Hinsicht ein Problem.
Nein, wenn man es richtig macht, eben nicht. Schau mal in den (angefangenen) Wiki-Eintrag dazu

Zitat
a) die heute vorhandene Liste der gDT ist bereits "unendlich" (sensor, ContactSensor, Contact, ...);
b) die Festlegung einer sinnvollen Zahl von "supporteten gDT" wäre wünschenswert, Nlui kann ein "Standardisierungs-mapping" in diese gDT bereitstellen;
c) gDT => Option funktioniert häufig nicht (s.o.). gDT ist daher nur ein Anhaltspunkt, wichtiger sind aus meiner Sicht standardisierte Reading-Namen (bisher: keine konstruktive Resonanz auf meine diesbezügliche Initiative im Developer-Bereich (!)). Aus dem Reading-Namen ergibt sich die Abfrage-Möglichkeit, für setter ist der User zuständig (?).
Habe ich im Developer-Bereich bisher nicht gesehen, muss ich mir ansehen. Ich wäre dafür, die gDT-Liste stark einzuschränken und nur für diese mandatorische Readings/Settings festzulegen


Zitat
- Dass man (uU. mehrere!) "sprechbare Namen" (pro Sprache!) braucht, ist klar. Ist der Device-Name "unaussprechlich", ist es zwingend...
- Der "sprechbare Ort" kann sich bereits aus "room" ergeben. Das ist daher m.E. nicht zwingend. Wichtiger: ein Device kann sich (gleichzeitig) an mehreren Orten "befinden". Ich will sagen können: "Mach alle Lichter im Erdgeschoss aus"
Klar. Dafür habe ich (auch hierarchische) Structures.
"Schalte das Licht am Esstisch aus" geht direkt auf das Device, "Schalte das Licht im Erdgeschoss aus" geht auf die Structure. Ich halte gar nichts von einer zusätzlichen Gruppenbildung in Nlui, denn diese bräuchte wieder eine komplexe Ausführungslogik (z.B. zeitlicher Versatz von Devices, Propagation von Attributen und Befehlen etc.), die in "structure" schon existiert und das Nlui unnötig komplizieren würde.

Zitat
Was machst du, wenn im Wohnzimmer 2 oder Devices da sind, die "thermstat" sind?
Wer so etwas macht, ist selbst Schuld. Pro Raum sollte es nur eine Stelle geben, an der man die Temperatur regelt - wenn nicht, muss eben "Wohnzimmer:Ostseite" und "Wohnzimmer: Westseite" unterschieden werden.

Zitat
Und wieso soll "mach wärmer" oder "mach leiser" nicht auch ausreichen?
"Spiele Musik" mündet bei mir in einen Dialog, um weitere Parameter abzufragen.

ZitatPrinzipiell stellt sich dann halt die Frage, wie man "nicht-generische Geräte" allgemein kenntlich macht bzw. der Server-Instanz mitteilen kann, dass/wie beliebiger Perl-Code auf der Remote-Instanz "ausgelöst" werden kann. In diese Richtung geht jedenfalls für Abfragen mein Vorschlag mit dem gDT "info".
Geht in Babble längst im Web-Frontend.

Zitat
Wenn möglich, würde ich dafür plädieren, ein einziges Nlui-Modul bereitzustellen. Es ist (aus Usersicht) komplex genug, dieses dann jeweils zu konfigurieren, wir brauchen m.E. nicht auch noch mehrere Varianten...
Na ja, Wettbewerb der Systeme. Ich bin immer für die Konfiguration auf der Web-Oberfläche, andere bevorzugen das Editieren einer Datei.

ZitatWie gesagt: Der zu übergebende Parameter-Satz muss aus meiner Sicht flexibel im Sinne von "einige aus vielen" sein.
OK

ZitatPOSIX
Ach, das ist eine Leiche in meinen leeren Modul-Templates.

LG

pah
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 04 Januar 2022, 10:43:25
Hier tut sich ja einiges in Sachen gSD.  :)
Sollte dafür ein extra Thread im Development aufgemacht werden, um den Entwicklern anderer Module den Mehrwert nahe zu bringen?

Gruß Jens
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 04 Januar 2022, 11:43:48
Zitat von: JensS am 04 Januar 2022, 10:43:25
Sollte dafür ein extra Thread im Development aufgemacht werden, um den Entwicklern anderer Module den Mehrwert nahe zu bringen?
...von mir aus gerne, die Frage ist allerdings, wer sich (im Moment) noch dafür interessiert. Die "großen Systeme" (mit externer "cloud" Spracherkennung wie gassistant usw.) brauchen anscheinend die Devices auch "externalisiert"...

Zitat von: Prof. Dr. Peter Henning am 04 Januar 2022, 10:34:55
Das halte ich für wenig hilfreich, weil das bedeuten würde, entfernte Nluis auch zu konfigurieren. Das oben beschriebene Verfahren mit einem ganz schlanken Code auf Seite der Slaves, der keine Konfiguration benötigt, halte ich für nutzerfreundlicher
"Keine" stimmt ja auch nicht, die Attribute müssen a) vorhanden sein, und b) gesetzt werden. Unklar ist mir dann noch, wie Geräte auf der entfernten Instanz geschaltet/angefragt werden sollen. Muss mir wohl mal reinziehen, was in deinem obigen Kontext das
FW_pO $json;bewirkt...

Zitat
OK, Du meinst "Operationen", nehme ich an.
Ja, sorry.

Zitat
Aber wir haben doch Gruppenstrukturen in FHEM - warum das Rad zum zweiten Mal erfinden? Siehe unten.
Die Gruppenstrukturen in FHEM sind - mit Verlaub - "Murks".
Den Rest (optionaler Versatz, ersetzen von internen durch externe Gruppen, setter-Mappings) kann RHASSPY bereits, das muss man nicht nochmal erfinden ;) . Und zwar weniger pauschal als structure, und ohne dass man groß was manuell konfigurieren müßte :P .

Zitat
Nein, wenn man es richtig macht, eben nicht. Schau mal in den (angefangenen) Wiki-Eintrag dazu
Es weicht in zwei Punkten massiv von meinem bisherigen Weltbild ab, weiß noch nicht, ob ich das gut oder erforderlich finde:
- mehrere gDT-Angaben waren bisher afaik nicht usus, das gibt uU. Probleme mit anderen Sprachsteuerungssystemen, wenn man mehrere parallel nutzen will
- "weniger ist mehr": warum "switch" auf "on/off" beschränken? Ist imo dasselbe wie "outlet" und kann ggf. auch ein power-Reading haben.
- "light" und "dimmer": Wenn ein Device pct, dim, bri oder brightness kann, ist es dimmbar. Es braucht keinen Dualismus, und v.a. keine Einschränkung auf pct-Setter, sonst muss man wieder zu viel umrechnen, ohne dass das einen Mehrwert bringt (was nicht bedeutet, dass Nlui nicht intern in 0-100-Skalen "ticken" sollte!).
- "blind" - da muss ich mir jetzt überlegen, wie ich den ZWave und CUL_HM-Geräten open/closed beibiege.
- ein gDT "hygrometer" bringt uns keinen Deut weiter, außer dass explizit damit verbunden ist, dass Nlui ein Reading suchen soll, das dazu paßt. Kann man bei einem Erstdurchlauf auch zwanglos machen, wenn es "nur" ein "sensor" oder ein "thermostat" (oder was auch immer) ist.
Vorteil: Man hat eine Einschränkung der in Frage kommenden Devices, ok. Muss man sonst anders lösen, wenn die Anfrage zu wenige Daten liefert, um direkt zum Ergebnis zu kommen (RHASSPY-Lösung: priority)
Unklar: Was tun, wenn das zugehörige Reading nicht ermittelt werden kann. Dann muss man so oder so manuell eingreifen.

Bin eher nicht überzeugt, dass dieser Ansatz zielführend ist.

Zitat
Habe ich im Developer-Bereich bisher nicht gesehen, muss ich mir ansehen. Ich wäre dafür, die gDT-Liste stark einzuschränken und nur für diese mandatorische Readings/Settings festzulegen
Das mit den mandatorischen Settern halte ich für bestehende Module für schwierig, und manche Einschränkungen ergeben sich aus der Hardware. Für künftige Entwicklungen hatte ich hier mal was geschrieben: https://forum.fhem.de/index.php/topic,117933.msg1123606.html#msg1123606

Zitat
Wer so etwas macht, ist selbst Schuld. Pro Raum sollte es nur eine Stelle geben, an der man die Temperatur regelt - wenn nicht, muss eben "Wohnzimmer:Ostseite" und "Wohnzimmer: Westseite" unterschieden werden.
Jein. Zum einen arbeiten meine CUL_HM-Thermostate eh' im Verbund, und das war eher auch ein Testszenarium, was das "set" angeht. Für Abfragen ist es was anderes, da will ich in der Regel den Raumfühler haben (definiert über prio in room), kann aber auch meine Thermostate eigenständig abfragen (was in der Regel auch sinnlos ist, aber es geht erst mal um die strukturellen Fragen. Hat man im selben Raum einen Backofen, ändert sich das Abfrage- und Setter-Szenarium doch deutlich, oder?).

Zitat
"Spiele Musik" mündet bei mir in einen Dialog, um weitere Parameter abzufragen.
Es braucht imo keinen Dialog, wenn das Ergebnis an sich eindeutig ist, und mein Beispiel war "mach lauter", nicht: "Spiele Musik"... Die läuft also schon, und jedenfalls in eindeutigen Fällen nervt dann ein Dialog...

Zitat
Geht in Babble längst im Web-Frontend.
Na ja, kommt eben darauf an, wie man das Gesamtsystem sieht. Soweit erkennbar, macht Babble die Konfiguration bisher zentral, nicht dezentral. Tendenziell finde ich es flexibler, wenn man Device-spezifische Einstellungen auch da erledigt, sobald man eine Mischung mit zentralen Kommandos hat, kommt sich das gerne mal ins Gehege. Aber "die" Lösung gibt es für diese Anforderung nicht.

Zitat
Na ja, Wettbewerb der Systeme. Ich bin immer für die Konfiguration auf der Web-Oberfläche, andere bevorzugen das Editieren einer Datei.
Bin auch eher bei Konfiguration über das Web-Interface, sehe aber auch kein Problem darin, das mit sowas wie (relativ unveränderlichen und in vielen Installationen verwendbaren) Einstellungen in der language-file zu kombinieren. Viel Device-spezifisches Zeug in externen Files zu konfigurieren ist imo nicht erstrebenswert. Andererseits: wenn es jemand haben will, braucht man halt einen passenden parser und "gut ist"...

Grüße,
Beta-User
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Prof. Dr. Peter Henning am 04 Januar 2022, 12:05:57
ZitatEs weicht in zwei Punkten massiv von meinem bisherigen Weltbild ab
Ich war noch nie politisch korrekt...


ZitatDie Gruppenstrukturen in FHEM sind - mit Verlaub - "Murks".
structure gibt es in 6473 Instanzen auf 1378 verschiedenen FHEM-Systemen... Wenn ein Nlui-Modul genutzt werden soll, kannst Du nicht gleichzeitig verlangen, dass alle ihre structures auf den Müll werfen.


FW_pO $json;

Das macht nur die Ausgabe im FHEMWEB. Installier doch einfach den Code aus meinem Post auf einer Deiner Kisten, und frage im Webbrowser http://<ip>:8083/fhem/Babble_devlist ab. Vorausgesetzt, dass ein babbleGenericDevice Attribut gesetzt ist, sonst musst Du den Code umschreiben.

Die Ausführung auf dem remote FHEM erfolgt entweder durch Ausführen der remoteFunc0..3 mit dem Kommando als Parameter (meine FHEMs kommunizieren über eine Perlfunktion fhemxxCmd(") miteinander, die xx steht für das letzte Tripel der IP-Adresse) oder über

my $url    = "http://".$ip."/fhem?XHR=1&amp;fwcsrf=".$token."&amp;cmd.$fhemdev=$cmd";
          HttpUtils_NonblockingGet({
            url => $url,
            callback => sub($$$){}
          });


LG

pah
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 04 Januar 2022, 12:20:01
Zitat von: Prof. Dr. Peter Henning am 04 Januar 2022, 12:05:57
Ich war noch nie politisch korrekt...
Ich bin auch nicht eben berühmt dafür, unpopuläre Dinge nicht auszusprechen...

Die Frage bleibt aber, ob es sinnvoll ist, "Revolution" zu rufen, wenn ein kleiner Evolutionsschritt es auch schon tut, und die Revolution keine wirklichen Vorteile bietet.

Zitat
structure gibt es in 6473 Instanzen auf 1378 verschiedenen FHEM-Systemen... Wenn ein Nlui-Modul genutzt werden soll, kannst Du nicht gleichzeitig verlangen, dass alle ihre structures auf den Müll werfen.
Tue ich doch nicht. Wer eine structure hat und die schalten will, darf und kann das doch gerne auch weiterhin tun, wo ist das Problem?

Mein Ansatz ist nur: Wer (heute) keine structure hat, muss die nicht extra basteln, nur um einen simplen Befehl wie "mach alle Lichter im Esszimmer aus" ausführen zu können... Und wenn die Gruppenanweisung an einer kleinen Stelle Schwierigkeiten hat (z.B. ein einzelnes Device, das einen Zeit-Versatz braucht) , oder cleverer gelöst werden kann (Beispiel: HUE-Gruppe oder virtueller Taster in CUL_HM), sehe ich keinen Vorteil, die User auf bereits existierende 6,5T structure-Devices hinzuweisen, sondern dann wollen die vermutlich genau ein solches kleines "Special" haben und mit dem Rest nicht behelligt werden :P ...

Zitat
Das macht nur die Ausgabe im FHEMWEB. [...]
Ok, damit ist es klarer, werd's mal testen (wird aber etwas dauern) :) .
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 04 Januar 2022, 13:16:35
Zitat von: Beta-User am 04 Januar 2022, 12:20:01
Ok, damit ist es klarer, werd's mal testen (wird aber etwas dauern) :) .
Das Einsammeln habe ich doch schon mal ausgetestet. Nice :) .

Prinzipiell kann man das auch recht einfach ausbauen, soweit klar.

Meine gedanklichen Probleme haben sich daher auf diesen Punkt verlagert:
ZitatDie Ausführung auf dem remote FHEM erfolgt entweder durch Ausführen der remoteFunc0..3 mit dem Kommando als Parameter (meine FHEMs kommunizieren über eine Perlfunktion fhemxxCmd(") miteinander, die xx steht für das letzte Tripel der IP-Adresse) oder über
Um zu wissen, was dann passieren soll, muss man uU. Werte kennen, (unterscheiden, ob man "in Bulk" ist), eine Queue anlegen für die Rückmeldung/Auswertung, ... Oder eben laufend dafür sorgen, dass die möglichen, zur Abfrage oder Berechnung benötigten Werte aktuell gehalten werden. Auch nicht schön.
Klingt jedenfalls auf den ersten Blick alles in allem ziemlich komplex.

Oder man muss eine vergleichsweise intelligente Gegenstelle aufrufen, die z.B. mit "mach im Wohnzimmer 15 % heller" was anfangen kann. Dann ist es aber mit dem Einfach-Code vorbei, mit dem man mehr oder weniger einmalig ein paar einfache Daten abruft, und man wäre wirklich bei einer Server/Client-Struktur...

Hmm, wird wohl etwas dauern, bis ich mir dazu den Kopf zerbrochen habe... Bin mal gespannt, was andere dazu meinen.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 04 Januar 2022, 13:28:47
Zitat von: Beta-User am 21 Dezember 2021, 06:54:52
Da es im Wiki stand, wollte ich das schlicht ausprobieren und kann nicht sagen, ob "float" das genauso gut kann...
Hatte dann auch die "1...9"-Version ausprobiert, allerdings mit demselben Ergebnis. Wenn wir "customFloat" nicht brauchen, sollte man es aus dem Wiki werfen. @drhirn: Schaust du dir das bei Gelegenheit an?

Sicher brauchen wir den. Rhasspy kann leider mit "zweiundzwanzig komma fünf" nichts anfangen. Der Custom-Converter hat früher also mal aus dem gesprochenen eine brauchbare Zahl gemacht. Ich frag mal im Rhasspy-Forum, was da los ist.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 04 Januar 2022, 13:39:21
Zitat von: drhirn am 04 Januar 2022, 13:28:47
Sicher brauchen wir den. Rhasspy kann leider mit "zweiundzwanzig komma fünf" nichts anfangen. Der Custom-Converter hat früher also mal aus dem gesprochenen eine brauchbare Zahl gemacht. Ich frag mal im Rhasspy-Forum, was da los ist.
Danke!

Ansonsten könnten wir notfalls auch noch einen "Decimal"-Tag für sowas einführen und dann einfach eine "Value += 0.{Decimal}"-Sonderlocke im JSON-Parser berücksichtigen. Aber schön ist was anderes...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 04 Januar 2022, 16:56:02
Zitat von: Beta-User am 04 Januar 2022, 13:39:21
Ansonsten könnten wir notfalls auch noch einen "Decimal"-Tag für sowas einführen und dann einfach eine "Value += 0.{Decimal}"-Sonderlocke im JSON-Parser berücksichtigen. Aber schön ist was anderes...

Ja. Bin schon der Meinung, dass Rhasspy das von sich aus können sollte. In meiner Test-Umgebung funktioniert der Converter übrigens. In meiner produktiven aber genau so wenig, wie bei euch.

https://community.rhasspy.org/t/nluexception-with-custom-converter/3395
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 05 Januar 2022, 19:29:56
(0..255[komma:.(0..9)]){Value} und =~ s/ . /./
wäre auch möglich. Dann müssten die User keinen extra Konverter installieren.

Gruß Jens
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Gisbert am 05 Januar 2022, 20:24:16
Zitat von: Beta-User am 02 Januar 2022, 08:17:36
Hmmm....

Leider habe ich Schierigkeiten, diese Fehlerbeschreibung in konkrete Code-Stellen umzusetzen.
Zum einen bin ich ziemlich sicher, dass nirgendwo eine Funktion verbaut ist, die einen vorhandenen "senkrechten-Strich-Text" erst auseinandernimmt und dann wieder anders zusammensetzt. Wenn es also unterschiedliche Ausgaben gibt, waren die auch bereits unterschiedlich notiert - irgendwo in deiner Konfiguration. Die kenne ich aber nicht im Detail. Das hier gepostete sieht nach "DefaultConfirmation" aus, und da hatte ich bisher keinen vergleichbaren Effekt bei mir beobachten können, wenn die Antwort aus den Standardroutinen generiert wird.

Das kann durchaus anders sein, wenn die response aus einen individuellen Mapping kommt, und da bin ich nämlich auch nicht sicher, dass das "shuffle" nicht an allen Stellen korrekt implementiert ist.

Daher brauche ich etwas spezfischere Info:

- Wenn das passiert, ist es immer so? Oder beim nächsten vergleichbaren Befehl an dasselbe Gerät wieder anders?
- Ist es die Antwort aus dem "Standard-Repertoire" oder ist sie gerätespezfisch (rhasspyMapping)? Wenn du was gerätespezifisches angegeben hast, würde ich empfehlen, dort was anzugeben, das sich vom Standard unterscheidet (sonst macht es so oder so keinen Sinn, außer zum debuggen...).
- wenn es wirklich aus dem Standard käme (was ich mir noch nicht recht vorstellen kann), und nach "kaputt" auch erst mal dauerhaft auf "kaputt" bleibt: Ist das Verhalten nach einem Neustart wieder "zufällig" (und mit einzelnen Antworten), oder gibt es (empfunden) keine erkennbare Logik hinter dem, was passiert?

Hallo Jörg,

ich komme (leider) erst jetzt dazu dir zu antworten.
Das Verhalten tritt bei jedem Device mit allen (aber nur) wenigen Befehlen immer auf.

Ich habe mal testweise in der Rhasspy-de.cfg meine Lieblingsantworten (Sir, yes Sir und Ai Captain ;) ;D) reingesetzt und ein Update des Fhem-RHASSPY-Moduls durchgeführt. Bis auf die Tatsache, dass ich eine deutsch gesprochene Antwort bekomme, sind diese beiden Optionen auch dabei.

Hier mal ein list meines RHASSPY-Moduls:

Internals:
   CFGFN      ./FHEM/GoogleAssitant.cfg
   CONFIGFILE ./rhasspy-de.cfg
   DEF        baseUrl=http://192.168.1.46:12101 devspec=genericDeviceType=.+ language=de
   FUUID      61978863-f33f-e986-532e-c2d28847a3d59476
   IODev      rhasspyMQTT2
   LANGUAGE   de
   LASTInputDev rhasspyMQTT2
   MODULE_VERSION 0.5.04a
   MSGCNT     6
   NAME       Rhasspy
   NR         1206
   STATE      http://192.168.1.46:12101/api/intents: empty answer received
   TYPE       RHASSPY
   baseUrl    http://192.168.1.46:12101
   defaultRoom default
   devspec    genericDeviceType=.+
   encoding   utf8
   fhemId     fhem
   prefix     rhasspy
   rhasspyMQTT2_MSGCNT 6
   rhasspyMQTT2_TIME 2022-01-05 20:01:17
   useGenericAttrs 1
   READINGS:
     2022-01-04 11:02:11   IODev           rhasspyMQTT2
     2022-01-01 20:20:22   intents         de.fhem:SetOnOff,de.fhem:SetNumeric
     2022-01-05 20:01:16   lastIntentPayload {"Device":"rollladen westseite","Value":"off","customData":null,"input":"fahr den rollladen westseite off","intent":"SetOnOff","lang":null,"probability":1,"rawInput":"fahr den rollladen westseite runter","requestType":"voice","sessionId":"9bfaa119-372c-bd7e-e875-111b10f27890","siteId":"Pixel4a"}
     2022-01-05 20:01:16   lastIntentTopic hermes/intent/de.fhem_SetOnOff
     2021-11-20 14:23:28   listening_default 0
     2021-11-26 06:27:56   listening_master 0
     2021-11-26 06:49:16   listening_pixel4a 0
     2022-01-05 20:01:16   responseType    voice
     2021-12-18 20:51:27   siteId2room_Pixel4a wohnzimmer
     2021-11-21 21:16:59   siteIds         Pixel4a
     2022-01-04 11:02:21   state           http://192.168.1.46:12101/api/intents: empty answer received
     2022-01-01 20:20:29   training        Training completed in 7.16 second(s)
     2021-11-19 20:34:33   updateSentences Wrote 21 char(s) to ['/opt/rhasspy/profiles/de/intents/de.fhem.Shortcuts.ini']
     2022-01-01 20:20:22   updateSlots     OK
     2022-01-05 20:01:16   voiceResponse   gerne|wird erledigt|ok|jawohl|zu diensten
   TIMER:
   helper:
     bm:
       CODE(0x5644f21446c8):
         cnt        15
         dmx        -1000
         dtot       0
         dtotcnt    0
         mTS        04.01. 21:07:11
         max        0.0001068115234375
         tot        0.00118827819824219
         mAr:
           HASH(0x5644f2131a70)
           ARRAY(0x5644f5e36d30)
           HASH(0x5644f48b14b8)
     devicemap:
       devices:
         RollladenSchlafzimmerFelix:
           alias      rollladen
           groups     rollladen
           names      rollladen
           rooms      schlafzimmer felix,schlafzimmer von felix,zimmer felix,zimmer von felix
           intents:
             SetNumeric:
               setTarget:
                 cmd        pct
                 cmdStop    Stop
                 type       setTarget
             SetOnOff:
               SetOnOff:
                 cmdOff     DriveDown
                 cmdOn      DriveUp
                 type       SetOnOff
           numeric_ValueMap:
             10         Event Slit
         RollladenSchlafzimmerGisbert:
           alias      rollladen
           groups     rollladen
           names      rollladen
           rooms      schlafzimmer von gisbert,schlafzimmer gisbert,meinem schlafzimmer
           intents:
             SetNumeric:
               setTarget:
                 cmd        pct
                 cmdStop    Stop
                 type       setTarget
             SetOnOff:
               SetOnOff:
                 cmdOff     DriveDown
                 cmdOn      DriveUp
                 type       SetOnOff
           numeric_ValueMap:
             10         Event Slit
         RollladenWohnzimmerSued:
           alias      rollladen südseite
           groups     rollladen
           names      rollladen südseite
           rooms      wohnzimmer
           intents:
             SetNumeric:
               setTarget:
                 cmd        pct
                 cmdStop    Stop
                 type       setTarget
             SetOnOff:
               SetOnOff:
                 cmdOff     DriveDown
                 cmdOn      DriveUp
                 type       SetOnOff
           numeric_ValueMap:
             10         Event Slit
         RollladenWohnzimmerTerrasse:
           alias      rollladen terrasse
           groups     rollladen
           names      rollladen terrasse,rollladen terrassentür
           rooms      wohnzimmer
           intents:
             SetNumeric:
               setTarget:
                 cmd        pct
                 cmdStop    Stop
                 type       setTarget
             SetOnOff:
               SetOnOff:
                 cmdOff     DriveDown
                 cmdOn      DriveUp
                 type       SetOnOff
           numeric_ValueMap:
             10         Event Slit
         RollladenWohnzimmerWest:
           alias      rollladen westseite
           groups     rollladen
           names      rollladen westseite
           rooms      wohnzimmer
           intents:
             SetNumeric:
               setTarget:
                 cmd        pct
                 cmdStop    Stop
                 type       setTarget
             SetOnOff:
               SetOnOff:
                 cmdOff     DriveDown
                 cmdOn      DriveUp
                 type       SetOnOff
           numeric_ValueMap:
             10         Event Slit
         Wohnzimmer.Licht:
           alias      licht
           groups     switch
           names      licht
           rooms      wohnzimmer
           intents:
             GetOnOff:
               GetOnOff:
                 currentVal state
                 type       GetOnOff
                 valueOff   off
             SetOnOff:
               SetOnOff:
                 cmdOff     off
                 cmdOn      on
                 type       SetOnOff
       rhasspyRooms:
         meinem schlafzimmer:
           rollladen  RollladenSchlafzimmerGisbert
         schlafzimmer felix:
           rollladen  RollladenSchlafzimmerFelix
         schlafzimmer gisbert:
           rollladen  RollladenSchlafzimmerGisbert
         schlafzimmer von felix:
           rollladen  RollladenSchlafzimmerFelix
         schlafzimmer von gisbert:
           rollladen  RollladenSchlafzimmerGisbert
         wohnzimmer:
           licht      Wohnzimmer.Licht
           rollladen südseite RollladenWohnzimmerSued
           rollladen terrasse RollladenWohnzimmerTerrasse
           rollladen terrassentür RollladenWohnzimmerTerrasse
           rollladen westseite RollladenWohnzimmerWest
         zimmer felix:
           rollladen  RollladenSchlafzimmerFelix
         zimmer von felix:
           rollladen  RollladenSchlafzimmerFelix
     lng:
       commaconversion 1
       mutated_vowels:
         Ä         Ae
         Ö         Oe
         Ü         Ue
         ß         ss
         ä         ae
         ö         oe
         ü         ue
       responses:
         DefaultCancelConfirmation Habe abgebrochen
         DefaultChangeIntentRequestRawInput wechseln zu $rawInput
         DefaultChoiceNoOutstanding warte grade nicht auf eine Auswahl
         DefaultConfirmation gerne|wird erledigt|ok|jawohl|zu diensten
         DefaultConfirmationBack also nochmal
         DefaultConfirmationNoOutstanding warte grade nicht auf eine bestätigung
         DefaultConfirmationReceived Ok, werde ich machen
         DefaultConfirmationRequestRawInput bestätige $rawInput
         DefaultConfirmationTimeout Tut mir leid, da hat etwas zu lange gedauert
         DefaultError Da passt irgend was nicht
         NoActiveMediaDevice Tut mir leid, es ist kein Wiedergabegerät aktiv
         NoDeviceFound Tut mir leid, ich konnte kein passendes Gerät finden
         NoMappingFound Tut mir leid, ich konnte kein passendes Mäpping finden
         NoMediaChannelFound Tut mir leid, der angefragte Kanal scheint nicht zu existieren.
         NoNewValDerived Tut mir leid, ich konnte den Zielwert nicht ausrechnen
         NoTimedOnDeviceFound Das gewählte Gerät unterstützt leider keine taimer Kommandos
         NoValidData ich habe leider zu wenig Daten um den Vorgang auszuführen
         RequestChoiceDevice Es kommen mehrere Geräte in Frage, bitte wähle zwischen $first_items oder $last_item
         RequestChoiceRoom Es kommen mehrere Geräte in verschiedenen Räumen in Frage, wähle einen Raum von  $first_items oder $last_item
         SilentCancelConfirmation
         duration_not_understood Tut mir leid, ich habe die Dauer nicht verstanden
         reSpeak_failed Tut mir leid, ich kann mich nicht erinnern
         timeRequest Es ist $hour Uhr $min
         timerCancellation $label im $room gelöscht
         weekdayRequest Heute ist $weekDay
         Change:
           brightness $deviceName ist auf $value gestellt
           desired-temp Die Solltemperatur von $location beträgt $value Grad
           humidity   Die Luftfeuchtigkeit von $location beträgt $value Prozent
           knownType  $mappingType von $location beträgt $value Prozent
           setTarget  $device ist auf $value gesetzt
           soilMoisture Die Bodenfeuchte von $location beträgt $value Prozent
           unknownType Der Wert von $location beträgt $value Prozent
           volume     $deviceName ist auf $value gestellt
           waterLevel Der Wasserstand von $location beträgt $value Prozent
           battery:
             0          Der Batteriestand von $location ist $value
             1          Der Batteriestand von $location beträgt $value Prozent
           temperature:
             0          Die Temperatur von $location ist $value
             1          Die Temperatur von $location beträgt $value Grad
         timerEnd:
           0          $label abgelaufen
           1          $label im raum $room abgelaufen
         timerSet:
           0          $label im Raum $room ist gestellt auf $seconds sekunden
           1          $label im Raum $room ist gestellt auf $minutetext $seconds
           2          $label im Raum $room ist gestellt auf $minutetext
           3          $label im Raum $room ist gestellt auf $hours stunden $minutetext
           4          $label im Raum $room ist gestellt auf $hours uhr $minutes
           5          $label im Raum $room ist gestellt auf morgen, $hours uhr $minutes
       stateResponses:
         inOperation:
           0          $deviceName ist fertig
           1          $deviceName läuft noch
         inOut:
           0          $deviceName ist ausgefahren
           1          $deviceName ist eingefahren
         onOff:
           0          $deviceName ist ausgeschaltet|$deviceName ist aus
           1          $deviceName ist eingeschaltet|$deviceName ist an
         openClose:
           0          $deviceName ist geöffnet|$deviceName ist offen
           1          $deviceName ist geschlossen|$deviceName ist zu
       units:
         unitHours:
           0          stunden
           1          eine stunde
         unitMinutes:
           0          minuten
           1          eine minute
         unitSeconds:
           0          Beispiel 1a: einige Sekunden
           1          Beispiel 1b: genau eine Sekunde
       words:
         and        und
         off        aus
         on         an
Attributes:
   comment    Installation von Modulen.
in FHEM: { Svn_GetFile('contrib/RHASSPY/10_RHASSPY.pm', 'FHEM/10_RHASSPY.pm') }
in Linux: "wget https://svn.fhem.de/trac/export/HEAD/trunk/fhem/contrib/RHASSPY/10_RHASSPY.pm -O ./FHEM/10_RHASSPY.pm"
   languageFile ./rhasspy-de.cfg
   room       Rhasspy


Viele Grüße​ Gisbert​
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 06 Januar 2022, 05:57:36
Zitat von: Gisbert am 05 Januar 2022, 20:24:16

Internals:
   MODULE_VERSION 0.5.04a

...wie hast du es geschafft, wieder downzugraden?
Im svn ist 0.5.10 verfügbar:
https://svn.fhem.de/trac/browser/trunk/fhem/contrib/RHASSPY/10_RHASSPY.pm#L323 (https://svn.fhem.de/trac/browser/trunk/fhem/contrib/RHASSPY/10_RHASSPY.pm#L323)

@pah: Anbei auch die letzte Überarbeitung, bringt aber gg. der von neulich nur eine Beschreibung der neuen Attribute in der commandref.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Gisbert am 06 Januar 2022, 20:53:03
Hallo Jörg,

Zitatwie hast du es geschafft, wieder downzugraden?
Im svn ist 0.5.10 verfügbar:

Ich hab das Modul hiermit runter geladen:
{ Svn_GetFile('contrib/RHASSPY/10_RHASSPY.pm', 'FHEM/10_RHASSPY.pm') }
Anschließend habe ich das Modul per reload in Fhem aktualisiert. Es bleibt dabei bei der Version 5.04a.

Viele​ Grüße​ Gisbert​
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 07 Januar 2022, 09:11:08
Zitat von: Gisbert am 06 Januar 2022, 20:53:03
Anschließend habe ich das Modul per reload in Fhem aktualisiert. Es bleibt dabei bei der Vetsion 5.04a.
Ein "reload" führt zwar dazu, dass die aktualisierten Funktionen verwendet werden, ändert aber nicht per se die  Internals. Dazu muss die Funktion ausgeführt werden, die das betreffende Internal "füttert", für dieses Internal hier ist das die "Define"-Funktion.

Von daher: die Versionsanzeige paßt nach einem Neustart oder dem Anfassen der DEF...

Wichtiger: Bereits nach dem reload müßte das "shuffle" eigentlich (wieder)  funktionieren. Dazu fehlt aber eine aktuelle Rückmeldung von dir.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Gisbert am 08 Januar 2022, 08:45:47
Guten Morgen Jörg,

ZitatWichtiger: Bereits nach dem reload müßte das "shuffle" eigentlich (wieder)  funktionieren. Dazu fehlt aber eine aktuelle Rückmeldung von dir.

Nach dem reload funktioniert die Antwort von Rhasspy wie geplant, d.h. es wird nur eine Option geantwortet ohne die "schrägen Striche".
Nach einem modify der Fhem-Definition des Rhasspy-Devices bekomme ich die Version 5.10.0.

Merkwürdig ist allenfalls noch, dass ich dieses Verhalten (... "schräger Strich") schon mal hatte, dann ist es verschwunden, wieder aufgetaucht - und jetzt wieder behoben.

Viele​n Dank und viele​ Grüße​
Gisbert​
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Gisbert am 08 Januar 2022, 15:44:18
Hallo Jörg,

so, neue Erkenntnis. Nach einem heutigen Fhem-Update trat der Fehler wieder auf. Ich hab das Modul jetzt vom update ausgeschlossen; ich hoffe, dass dies die richtige Maßnahme ist.

Viele​ Grüße​ Gisbert​
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Prof. Dr. Peter Henning am 09 Januar 2022, 16:25:11
Ich habe jetzt noch einmal alle Installationen erneuert. es bleibt leider beim Sachverhalt.

- Rhasspy im Docker Image, alle Funktionen in Ordnung.
- Angekoppelt ein externes MQTT2_CLIENT, das auf die Topics
Zitathermes/tts/# rhasspy/tts/# hermes/hotword/#
susbcribed. Und bei hermes/tts/say eine Spaachausgabe macht sowie 2x JSON an den MQTT-Server zurücksendet.


Test 1:
Im Rhasspy-Webinterface als TTS-Server nanoTTS ausgewählt. Subscription des eigenen MQTT-Client beibehalten. Eintippen eines Textes auf der Homepage des Webinterface
Ergebnis: 2x Sprachnachricht. Rhasspy ok. Mitschnitt des mosquitto_sub
Zitathermes/tts/say {"text": "es ist 17 uhr 31", "siteId": "default", "lang": null, "id": "54b2cc5f-37e7-4512-b17e-a3de038924fe", "sessionId": "", "volume": 1.0}
hermes/tts/sayFinished {"siteId":"default","sessionId":"","id":"54b2cc5f-37e7-4512-b17e-a3de038924fe"}
hermes/audioServer/default/playFinished {"sessionId":"54b2cc5f-37e7-4512-b17e-a3de038924fe","id":"54b2cc5f-37e7-4512-b17e-a3de038924fe"}
hermes/tts/sayFinished {"siteId": "default", "id": "54b2cc5f-37e7-4512-b17e-a3de038924fe", "sessionId": ""}
hermes/audioServer/default/playFinished {"id": "54b2cc5f-37e7-4512-b17e-a3de038924fe", "sessionId": "54b2cc5f-37e7-4512-b17e-a3de038924fe"}
Wie man sieht, erhält Rhasspy identische Rückgaben von beiden TTS-Servern. Unterschiede nur in der Reihenfolge der Attribut-Wert-Paare und in ein paar Leerzeichen - die aber laut JSON-Spezifikation nichts ausmachen.

Test 2: Im Rhasspy-Webinterface als TTS-Server Hermes TTS ausgewählt. Subscription des eigenen MQTT-Client beibehalten. Eintippen eines Textes auf der Homepage des Webinterface
Ergebnis: 1x Sprachnachricht. Rhasspy akzeptiert die Rückgaben nicht und geht nach 30 Sekunden in einen Timeout. Mitschnitt des mosquitto_sub:
Zitathermes/tts/say {"text": "es ist 17 uhr 32", "siteId": "default", "lang": null, "id": "1d84dddd-52a9-4d65-87c6-d69bd58b16fb", "sessionId": "", "volume": 1.0}
hermes/tts/sayFinished {"siteId":"default","id":"1d84dddd-52a9-4d65-87c6-d69bd58b16fb","sessionId":""}
hermes/audioServer/default/playFinished {"sessionId":"1d84dddd-52a9-4d65-87c6-d69bd58b16fb","id":"1d84dddd-52a9-4d65-87c6-d69bd58b16fb"}

Sag mir einer, was da los ist.

LG

pah
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 09 Januar 2022, 16:41:37
Wie sieht es bei Spracheingabe über einen Satelliten oder ein Handy aus?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Prof. Dr. Peter Henning am 09 Januar 2022, 17:32:28
Kein Problem - die Eingabe eines Textes via Handy resultiert in entweder zwei Sprachausgaben (Fall 1) oder einer Sprachausgabe (Fall 2). Allerdings gibt es keinerlei Log-Eintrag, der auf ein Problem hinweist. Auch im Log der Rhasspy-App gibt es nichts. Das läuft also einfach durch.

LG

pah
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 09 Januar 2022, 18:07:30
Imo ist weiter die Erwartungshaltung zu hinterfragen, wieso Rhasspy _nicht_ in einen Timeout gehen sollte, wenn _per MQTT keine_ Audiodaten kommen... Die Zentrale ist eher schlicht nicht für TTS zuständig, wenn alles extern abläuft.
Ist beim Testszenarium mit der App das Handy als Satellit für TTS registriert oder nicht? (Soll: man. nicht registriert).
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 09 Januar 2022, 19:12:30
Zitat von: Prof. Dr. Peter Henning am 09 Januar 2022, 17:32:28Allerdings gibt es keinerlei Log-Eintrag, der auf ein Problem hinweist. Auch im Log der Rhasspy-App gibt es nichts. Das läuft also einfach durch.
... bedeutet, dass es zu keinem Timeout kommt - also wie gewünscht?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 09 Januar 2022, 22:44:35
Im Rhasspy-Forum ist mir der kleine Unterschied "" beim MQTT-Log aufgefallen."sessionId": ""vs."sessionId":""
Das deutet auf https://github.com/rhasspy/rhasspy-dialogue-hermes/blob/0d697cb1631880688fd484177f1cdf50351f4a3e/rhasspydialogue_hermes/__init__.py#L900 (https://github.com/rhasspy/rhasspy-dialogue-hermes/blob/0d697cb1631880688fd484177f1cdf50351f4a3e/rhasspydialogue_hermes/__init__.py#L900) und https://github.com/rhasspy/rhasspy-server-hermes/blob/ba9ce182dc2d7387f73dc3920cc2ebe88f0b6218/rhasspyserver_hermes/__init__.py#L544 (https://github.com/rhasspy/rhasspy-server-hermes/blob/ba9ce182dc2d7387f73dc3920cc2ebe88f0b6218/rhasspyserver_hermes/__init__.py#L544) hin, welches bessersession_id = str,odersession_id = None,sein sollte; besser noch, im Folgenden die tatsächliche sessionId beinhalten sollte.
Der Fehler tritt bei mir nicht auf, da immer eine sessionId vergeben wurde. Umgehen kann das Problem eventuell, wenn man die Länge von sessionId prüft und bei 0"sessionId": nulloder"sessionId": ""in tts/sayFinished an Rhasspy übergibt. https://rhasspy.readthedocs.io/en/latest/reference/#text-to-speech (https://rhasspy.readthedocs.io/en/latest/reference/#text-to-speech)
tts/playFinished ist dabei nur die Kür, da die Schließung der Session bereits mit tts/sayFinished veranlasst wird.

Gruß Jens

p.s. Es bleibt zu klären, weshalb die sessionId in tts/say nicht vergeben wird. Im Rhasspy-Code scheint die siteId "default" generell einen VIP-Status zu haben und andere Wege zu nehmen, als die anderen stiteIds.
Vermutlich könnte es helfen, bei keiner Instanz (Basis und Satelliten) "default" als siteId zu nutzen. Das keine Infos zu Konfigurationen, bzw ausführliche MQTT-Mitschnitte vorliegen - mal wieder geraten.

p.p.s. Vielleicht würde ein simples my $tts_json = JSON->new->allow_nonref->utf8->decode( $message );genügen.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 10 Januar 2022, 16:50:07
Zitat von: JensS am 09 Januar 2022, 22:44:35
Vermutlich könnte es helfen, bei keiner Instanz (Basis und Satelliten) "default" als siteId zu nutzen.
Ob es bei keiner Instanz sein muss, wäre die Frage. Meine nennt sich "base", was aber vermutlich nichts zur Sache tut. Die Zentrale scheint mir jedenfalls auch privilegiert zu sein, und wir wollen ja gerade keine Audio-Ausgabe über Rhasspy-interne Mechanismen. Von daher meine ich weiter, dass alles über andere Satelliten-Id's laufen sollte.

Hier jedenfalls mal auszugsweise meine config:
{
    "dialogue": {
        "satellite_site_ids": "motox,buero,büro,Küche",
        "system": "rhasspy",
        "volume": "1"
    },
    "intent": {
        "lang": "de",
        "satellite_site_ids": "motox,buero,büro,Küche,defhem",
        "system": "fsticuffs"
    },
    "mqtt": {
        "enabled": ""
    },
    "sounds": {
        "error": "${RHASSPY_PROFILE_DIR}/sounds/error.wav",
        "recorded": "${RHASSPY_PROFILE_DIR}/sounds/end_of_input.wav",
        "wake": "${RHASSPY_PROFILE_DIR}/sounds/start_of_input.wav"
    },
    "speech_to_text": {
        "satellite_site_ids": "motox,buero,büro,Küche",
        "system": "kaldi"
    },
    "text_to_speech": {
        "larynx": {
            "vocoder": "vctk_small"
        },
        "nanotts": {
            "volume": "2"
        },
        "satellite_site_ids": "motox,buero,büro,Küche",
        "system": "nanotts"
    },
    "wake": {
        "porcupine": {
            "keyword_path": "bumblebee_linux.ppn",
            "udp_audio": "0.0.0.0:12199:motox"
        },
        "satellite_site_ids": "motox,buero,büro,Küche",
        "snowboy": {
            "apply_frontend": true,
            "model": "alexa.umdl",
            "sensitivity": "0.6",
            "udp_audio": "0.0.0.0:12199:motox"
        },
        "system": "porcupine"
    }
}

Die genannten Satelliten "motox,buero,büro,Küche" sind entweder die mobile app, ein ESP32 (https://github.com/Romkabouter/ESP32-Rhasspy-Satellite/blob/master/m5atomecho.md (https://github.com/Romkabouter/ESP32-Rhasspy-Satellite/blob/master/m5atomecho.md)), oder es steckt ein weiterer Rhasspy dahinter. "base" (oder "default") taucht da gar nicht auf.

Für den Abschnitt "intent" ist das dann ergänzt um "defhem", was es erlaubt, über FHEM (via msgConfig zu ROOMMATE/GUEST, vermutlich mit 0.5.11 auch via AMADComBridge) eingehende Text-Messages zur Analyse an Rhasspy weiterzusenden und die Antwort aus RHASSPY an den Messenger (und vermutlich auch an ein allgemeines TTS-System) weiterzuleiten.
Für diesen speziellen "Satelliten" ist also TTS-mäßig meine "base" (bzw. "default") nicht zuständig!
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 10 Januar 2022, 17:06:38
Zitat von: Beta-User am 10 Januar 2022, 16:50:07
"base" (oder "default") taucht da gar nicht auf.
Daher wird es wahrscheinlich "Satellite siteIds:" heißen.

ZitatESP32 (https://github.com/Romkabouter/ESP32-Rhasspy-Satellite/blob/master/m5atomecho.md (https://github.com/Romkabouter/ESP32-Rhasspy-Satellite/blob/master/m5atomecho.md))
Läuft das gut? Welches Mikro und welche Soundausgabe nutzt du dazu?
Bei mir sind es bisher rpi0w, die ihren Dienst gut tun aber natürlich empfindlich bei Stromtrennung und SD-Card-Fehlern sind.

Gruß Jens
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 10 Januar 2022, 17:22:24
Zitat von: JensS am 10 Januar 2022, 17:06:38
Daher wird es wahrscheinlich "Satellite siteIds:" heißen.
...vermutlich... Wie dem auch sei, dass "default" vermutlich eine unglückliche Wahl ist und man für "externes Zeug" eine eigene Satellite/siteId vergeben sollte ist das, was mir testweise in der ganzen MQTT-Traffic-Analyse bisher gefehlt hatte.
Daher auch dieser "Zwischenruf":
Zitat von: Beta-User am 09 Januar 2022, 18:07:30
Imo ist weiter die Erwartungshaltung zu hinterfragen, wieso Rhasspy _nicht_ in einen Timeout gehen sollte, wenn _per MQTT keine_ Audiodaten kommen... Die Zentrale ist eher schlicht nicht für TTS zuständig, wenn alles extern abläuft.
Ist beim Testszenarium mit der App das Handy als Satellit für TTS registriert oder nicht? (Soll: man. nicht registriert).

Zitat
Läuft das gut? Welches Mikro und welche Soundausgabe nutzt du dazu?
Na ja, es ist "Micky-Maus"-like und eher eine Spielerei (ich habe aber die neuesten firmwares nicht getestet, da hat sich wohl zumindest bei den "Verschluckern" was getan). Effektiv nutze ich - wie bereits mehrfach erwähnt - mehr oder weniger ausschließlich den Shortcut-Button am Handy...
Was mir an der ESP32-Lösung (der Atom M5 ist "fertige Hardware", wenn, dann genutzt "as is" - liegt wie der Pi (ich hasse die Dinger...) grade im Eck) nicht gefällt: die Wakeword-Erkennung läuft auch auf der "base", es werden die ganze Zeit Audio-Daten gestreamt. Der Atom M5 taugt(e) allerdings zum Testen, (daher auch die "umlauts") und hat mir v.a. geholfen zu verstehen wie das mit den Satelliten - und der Zuordnung von "Verantwortlichkeiten" - eigentlich gedacht ist.
Wenn man "zu wenige Beteiligte" hat, ist das Zusammenspiel mAn. nicht besonders gut zu erkennen, weil alles scheinbar "in one" ist.

Muss das Würfelchen (M5) mal wieder rauskramen wegen der neueren Spielereien...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 10 Januar 2022, 17:39:13
Zitat von: Beta-User am 10 Januar 2022, 17:22:24
... nicht gefällt: die Wakeword-Erkennung läuft auch auf der "base", es werden die ganze Zeit Audio-Daten gestreamt.
Das ist ja genau wie bei der Handy-App. Die streamt auch die ganze Zeit. Mal sehen, ob's in demnächst was Besseres gibt - vielleicht von Mycroft.

Gruß Jens
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 10 Januar 2022, 17:54:02
Zitat von: JensS am 10 Januar 2022, 17:39:13
Das ist ja genau wie bei der Handy-App. Die streamt auch die ganze Zeit. Mal sehen, ob's in demnächst was Besseres gibt - vielleicht von Mycroft.
...nur, wenn man es an der Handy-App einschaltet. Bei mir ist es meistens aus, ich nehme den "shortcut".

Zur Klarstellung: Der ESP32 streamt via MQTT, wenn ich das richtig im Kopf habe, nicht per UDP (mir letztlich egal, ich finde es in beiden Varianten nicht prickelnd).

Es gibt aber anscheinend "Bewegung" in Richtung der Miniaturisierung der Wakeword-Geschichte - mal sehen, ob bzw. wann da was vernünftiges rauskommt ::) .



@drhirn:
Zitat von: Gisbert am 08 Januar 2022, 15:44:18
so, neue Erkenntnis. Nach einem heutigen Fhem-Update trat der Fehler wieder auf. Ich hab das Modul jetzt vom update ausgeschlossen; ich hoffe, dass dies die richtige Maßnahme ist.
Das scheint daher zu kommen, dass 0.5.10 noch nicht auf github ist. Darauf bezog sich das:
Zitat von: Beta-User am 26 Dezember 2021, 09:54:34
Oder per wget (unter Linux):
"wget https://svn.fhem.de/trac/export/HEAD/trunk/fhem/contrib/RHASSPY/10_RHASSPY.pm -O ./FHEM/10_RHASSPY.pm"
(Damit ich nicht immer die aktuelle version aus dem svn hier zusätzlich anhängen muss...)
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 10 Januar 2022, 18:27:46
Zitat von: Beta-User am 10 Januar 2022, 17:54:02
@drhirn:Das scheint daher zu kommen, dass 0.5.10 noch nicht auf github ist.

Im dev-Zweig sogar 0.5.11.
Gisbert verwendet doch eh SVN!?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Prof. Dr. Peter Henning am 10 Januar 2022, 19:29:00
Auch romkabouter aus dem Rhasspy-Forum teilt meine Einschätzung, dass es sich hier um einen Fehler handelt. Ich habe ein "Issue" bei Github aufgemacht, warten wir es ab.

LG

pah

Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 11 Januar 2022, 10:26:00
Zitat von: Prof. Dr. Peter Henning am 10 Januar 2022, 19:29:00
Auch romkabouter aus dem Rhasspy-Forum teilt meine Einschätzung, dass es sich hier um einen Fehler handelt. Ich habe ein "Issue" bei Github aufgemacht, warten wir es ab.
Das wollte/kann ich auch nicht ausschließen. Das Verhalten ist jedenfalls gefühlt in der Tat "komisch".

Bei mir ist nur in dem Zusammenhang weiter die Frage offen, was bei "Hermes-TTS" eigentlich die seitens der zentralen Diensteverwaltung in Rhasspy (die vermutlich für den timeout verantwortlich ist) erwartete Rückmeldung sein soll. Ist das "nur" die Info, dass die Ausgabe fertig ist, oder sind es Audiodaten via MQTT?

Unabhängig davon stellt sich die Frage, wie man externe "Dienstleister" eigentlich bei Rhasspy registrieren sollte. Und da stehe ich im Moment auf dem Standpunkt, dass jedes "autonome" Audio-Gerät (bzw. die Kombi aus Mikro und Lautsprecher) eine Art eigene siteId haben sollte (wenn FHEM/RHASSPY die Verwaltung macht, wer was bekommt, kann das auch eine "Sammel-siteId sein").
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 11 Januar 2022, 14:42:38
Zitat von: Beta-User am 11 Januar 2022, 10:26:00
Bei mir ist nur in dem Zusammenhang weiter die Frage offen, was bei "Hermes-TTS" eigentlich die seitens der zentralen Diensteverwaltung in Rhasspy (die vermutlich für den timeout verantwortlich ist) erwartete Rückmeldung sein soll. Ist das "nur" die Info, dass die Ausgabe fertig ist, oder sind es Audiodaten via MQTT?
Der Dialogmanager von Rhasspy sendet den zu sprechenden Text mit tts/say und wartet auf die Bestätigung des (externen) TTS durch tts/sayFinished. Danach wird die Session vom Dialogmanager geschlossen oder an die ASR übergeben - wenn continueSession im Spiel ist.
Bleibt tts/sayFinished aus oder passt die Antwort nicht zu tts/say, kommt es zu einem Timeout.

Gruß Jens
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 11 Januar 2022, 15:00:40
Woher nimmst du die Sicherheit, dass es _keine Audiodaten_ sind, auf die (auch!) (via MQTT) gewartet wird?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 11 Januar 2022, 16:35:04
Das steht so in der ref und meine Teststellung läuft fehlerfrei.
TTS erzeugt eine WAV und sendet das im RIFF-Format zum Audioserver, welcher dann mit playFinished das Ende des Abspielens bekannt gibt.
Wenn man die, mit eigenem TTS erzeugte Sonddatei, lokal verarbeitet, muss natürlich auch die Info playFinished bekannt gegeben werden.
Wie es allerdings aussieht, wenn man die Bestätingungstöne einschaltet, habe ich nicht getestet.
Dabei wird vom Session-Manager eine vorhandene WAV an den Audioserver (Audio Playing) per RIFF über MQTT gesandt.
Sollte "Audio Playing" deaktiviert sein, sollte (vermutlich) auch kein Bestätigungston durch den MQTT geschoben werden.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 11 Januar 2022, 16:53:27
Aus den Ausführungen werde ich nicht so recht schlau.
Wenn (wav-riff) Audiodaten via MQTT gesendet werden, ist das genau das, was ich behauptet hatte: Es wird bei "Hermes MQTT" darauf gewartet, dass der Audio-Server mit Daten gefüttert wird. Das erfolgt aber nach meinem Verständnis in pah's Experimenten bislang nicht, bei ihm wird das Audio-Ergbnis ohne den MQTT-Umweg direkt auf die Soundausgabe gegeben (aplay o.ä.). Damit ist Rhasspy aber nicht einig, weil (Audio-) Datenlieferung per MQTT "zugesagt" worden war.
Kann auch sein, dass ich falsch liege, aber deine Schilderung bestätigt doch gerade diese Annahme, oder verstehe ich das nicht richtig?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Prof. Dr. Peter Henning am 11 Januar 2022, 16:57:38
Ich denke, dass Ihr beide falsch liegt. Rhasspy wartet nicht auf Audiodaten, weil es dafür nicht zuständig ist. Und weder aus der Spezifikation, noch aus dem tatsächlichen Ablauf ist irgendetwas von "ContinueSession" zu lesen.

Das wäre auch nicht Stand der Technik bei solchen Protokollen.

LG

pah
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 11 Januar 2022, 17:12:20
Aha. Du hättest uns ja früher verraten können, dass Audio-Output bei dir auf "dummy" steht. Mit "ContinueSession" hat das ganze m.E. im Übrigen erst mal nichts zu tun.

Ansonsten sehe ich einen gewissen Missmatch in der Doku:
Unter
https://rhasspy.readthedocs.io/en/latest/services/#text-to-speech - Output messages findet sich:
ZitatFinished generating audio (actually spoken with playBytes)
In https://rhasspy.readthedocs.io/en/latest/reference/#tts_sayfinished steht dagegen:
ZitatIndicates that the text to speech system has finished speaking
Das erstere (samt der Hervorhebung in kursiv) passt eher zu den bisherigen Beobachtungen, aber ich habe ja in der Tat keine Ahnung vom "Stand der Technik bei solchen Protokollen"...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 11 Januar 2022, 17:19:48
Zitat von: Prof. Dr. Peter Henning am 11 Januar 2022, 16:57:38
Ich denke, dass Ihr beide falsch liegt. Rhasspy wartet nicht auf Audiodaten, weil es dafür nicht zuständig ist. Und weder aus der Spezifikation, noch aus dem tatsächlichen Ablauf ist irgendetwas von "ContinueSession" zu lesen.

Das wäre auch nicht Stand der Technik bei solchen Protokollen.

LG

pah
Das behauptet keiner... Rhasspy ist nur der Vermittler. Die Daten werden zwischen den Modulen getauscht und diese nutzen Rhasspy zur Bekanntgabe der dazugehörigen Mitteilungen.
ContinueSession wird dir schon noch begegnen, wenn du tiefer ins erweiterte Dialog-Thema einsteigst. Das brauchst auf jeden Fall für einen Bot o.ä..

@Beta-User
Wie oben geschrieben, wartet Rhasspy lediglich auf Nachrichten und weist den Modulen Aufgaben zu. Die einzige Ausnahme sollten die Bestätigungstöne sein. Darum habe ich mich aber noch nicht gekümmert, da ich die Bestätigungen über LEDs machen lasse.

Gruß Jens
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 11 Januar 2022, 17:40:07
Zitat von: JensS am 11 Januar 2022, 17:19:48
@Beta-User
Wie oben geschrieben, wartet Rhasspy lediglich auf Nachrichten und weist den Modulen Aufgaben zu. Die einzige Ausnahme sollten die Bestätigungstöne sein. Darum habe ich mich aber noch nicht gekümmert, da ich die Bestätigungen über LEDs machen lasse.
...was auch immer man unter "Nachrichten" versteht. Jedenfalls wäre mein Verständnis von https://rhasspy.readthedocs.io/en/latest/audio-output/#mqtthermes, dass der Audio-Server auf Nachrichten des Typs "Audio" (riff-wav) wartet und in einen timeout läuft, wenn er diese nicht bekommt.
Da steht übrigens auch eine (mögliche) Erklärung, wie der Wechsel der ID zustande gekommen sein könnte:
ZitatRhasspy plays WAV audio data sent with the hermes/audioServer/<siteId>/playBytes/<requestId> topic. The requestId part of the topic is simply a unique ID that will be sent back in id field of the hermes/audioServer/playFinished response.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 11 Januar 2022, 19:15:16
Grundlegend stimmt da was nicht im Session-Management (sh. Beitrag zu sessionId = ""). Es wird sich nicht an eigene Konventionen gehalten.
Jetzt habe ich den Fehler nachstellen können. Er tritt bei meiner Installation nur auf, wenn auf der WebGUI der Basis das "Speak"-Kommando genutzt wird.
Heraus kommt, dass in der Tat wirklich auf RIFF-Daten gewartet wird. Das sieht aber eher nach einem Fehler in der Folge der Verarbeitung der Webanfrage aus.[ERROR:2022-01-11 19:13:09,638] rhasspyserver_hermes:
Traceback (most recent call last):
  File "/usr/lib/rhasspy/usr/local/lib/python3.7/site-packages/quart/app.py", line 1821, in full_dispatch_request
    result = await self.dispatch_request(request_context)
  File "/usr/lib/rhasspy/usr/local/lib/python3.7/site-packages/quart/app.py", line 1869, in dispatch_request
    return await handler(**request_.view_args)
  File "/usr/lib/rhasspy/rhasspy-server-hermes/rhasspyserver_hermes/__main__.py", line 1699, in api_text_to_speech
    results = await asyncio.gather(*aws)
  File "/usr/lib/rhasspy/rhasspy-server-hermes/rhasspyserver_hermes/__main__.py", line 1685, in speak
    say_chars_per_second=say_chars_per_second,
  File "/usr/lib/rhasspy/rhasspy-server-hermes/rhasspyserver_hermes/__init__.py", line 617, in speak_sentence
    handle_finished(), messages, message_types, timeout_seconds=timeout_seconds
  File "/usr/lib/rhasspy/rhasspy-server-hermes/rhasspyserver_hermes/__init__.py", line 995, in publish_wait
    result_awaitable, timeout=timeout_seconds
  File "/usr/lib/rhasspy/usr/local/lib/python3.7/asyncio/tasks.py", line 449, in wait_for
    raise futures.TimeoutError()
concurrent.futures._base.TimeoutError
[DEBUG:2022-01-11 19:12:39,649] rhasspyserver_hermes: Handling TtsSayFinished (topic=hermes/tts/sayFinished, id=bf0de8b5-a8c3-44b0-a520-3da7b1fa8ae1)
[DEBUG:2022-01-11 19:12:39,649] rhasspyserver_hermes: Handling TtsSayFinished (topic=hermes/tts/sayFinished, id=01758859-a148-432a-b4a7-7adc255b5db7)
[DEBUG:2022-01-11 19:12:39,648] rhasspyserver_hermes: Handling TtsSayFinished (topic=hermes/tts/sayFinished, id=645e0969-1bb6-4b23-aad6-b9ab792adabb)
[DEBUG:2022-01-11 19:12:39,648] rhasspyserver_hermes: Handling TtsSayFinished (topic=hermes/tts/sayFinished, id=db95c2ae-dec4-4dab-b5c5-d194b288d70d)
[DEBUG:2022-01-11 19:12:39,606] rhasspyserver_hermes: Publishing 139 bytes(s) to hermes/tts/say
[DEBUG:2022-01-11 19:12:39,605] rhasspyserver_hermes: -> TtsSay(text='Das ist ein Test', site_id='boden', lang=None, id='2c22cf7f-1ab8-4ca3-980f-c8c33de72e99', session_id='', volume=1.0)
[DEBUG:2022-01-11 19:12:39,603] rhasspyserver_hermes: TTS timeout will be 30 second(s)
Also schnell den "kleinen TTS" angepasst, dass es so aussieht, als würden Audiodaten gesendet:#!/usr/bin/perl -w
use Net::MQTT::Simple "localhost";
use JSON;
use strict;
use Net::MQTT::Simple;

my $mqtt = Net::MQTT::Simple->new("localhost");
$mqtt->run(
    "hermes/tts/say" => sub {
        my ($topic, $message) = @_;
        my $tts_json = JSON->new->allow_nonref->decode( $message );
        my $siteId = $tts_json->{siteId};
        my $id = $tts_json->{id};
        my $sessionId = $tts_json->{sessionId};
        my $text = '"'.$tts_json->{text}.'"';
        my $ausgabe = {id => $id, sessionId => $sessionId, siteId => $siteId};
        my $sayFinish = JSON->new->utf8->encode( $ausgabe );
        my $bytes = "leer";
        my $bytesausgabe = {siteId => $siteId, requestId => $id, wav_bytes => $bytes};
        my $playBytes = JSON->new->utf8->encode( $bytesausgabe );
        qx(pico2wave -l "de-DE" -w test.wav $text);
        $mqtt->publish("hermes/tts/sayFinished" => $sayFinish);
        qx(aplay test.wav);
        my $playausgabe = {id => $id, sessionId => $sessionId};
        my $playFinish = JSON->new->utf8->encode( $playausgabe );
        $mqtt->publish("hermes/audioServer/$siteId/playBytes/$id" => $playBytes);
        $mqtt->publish("hermes/audioServer/$siteId/playFinished" => $playFinish);
    },
);

Nun geht's auch über das Webinterface der Basis:[DEBUG:2022-01-11 19:14:45,849] rhasspyserver_hermes: Handling AudioPlayBytes (topic=hermes/audioServer/boden/playBytes/f58fd47e-41b8-4b60-80e2-bc8d02b54122, id=9fd73023-db86-44cd-91b3-486deadd553f)
[DEBUG:2022-01-11 19:14:45,848] rhasspyserver_hermes: Handling AudioPlayBytes (topic=hermes/audioServer/boden/playBytes/f58fd47e-41b8-4b60-80e2-bc8d02b54122, id=bf0de8b5-a8c3-44b0-a520-3da7b1fa8ae1)
[DEBUG:2022-01-11 19:14:45,848] rhasspyserver_hermes: Handling AudioPlayBytes (topic=hermes/audioServer/boden/playBytes/f58fd47e-41b8-4b60-80e2-bc8d02b54122, id=01758859-a148-432a-b4a7-7adc255b5db7)
[DEBUG:2022-01-11 19:14:45,847] rhasspyserver_hermes: Handling AudioPlayBytes (topic=hermes/audioServer/boden/playBytes/f58fd47e-41b8-4b60-80e2-bc8d02b54122, id=645e0969-1bb6-4b23-aad6-b9ab792adabb)
[DEBUG:2022-01-11 19:14:45,847] rhasspyserver_hermes: Handling AudioPlayBytes (topic=hermes/audioServer/boden/playBytes/f58fd47e-41b8-4b60-80e2-bc8d02b54122, id=db95c2ae-dec4-4dab-b5c5-d194b288d70d)
[DEBUG:2022-01-11 19:14:44,300] rhasspyserver_hermes: Handling TtsSayFinished (topic=hermes/tts/sayFinished, id=9fd73023-db86-44cd-91b3-486deadd553f)
[DEBUG:2022-01-11 19:14:44,300] rhasspyserver_hermes: Handling TtsSayFinished (topic=hermes/tts/sayFinished, id=bf0de8b5-a8c3-44b0-a520-3da7b1fa8ae1)
[DEBUG:2022-01-11 19:14:44,299] rhasspyserver_hermes: Handling TtsSayFinished (topic=hermes/tts/sayFinished, id=01758859-a148-432a-b4a7-7adc255b5db7)
[DEBUG:2022-01-11 19:14:44,299] rhasspyserver_hermes: Handling TtsSayFinished (topic=hermes/tts/sayFinished, id=645e0969-1bb6-4b23-aad6-b9ab792adabb)
[DEBUG:2022-01-11 19:14:44,299] rhasspyserver_hermes: Handling TtsSayFinished (topic=hermes/tts/sayFinished, id=db95c2ae-dec4-4dab-b5c5-d194b288d70d)
[DEBUG:2022-01-11 19:14:44,258] rhasspyserver_hermes: Publishing 139 bytes(s) to hermes/tts/say
[DEBUG:2022-01-11 19:14:44,257] rhasspyserver_hermes: -> TtsSay(text='Das ist ein Test', site_id='boden', lang=None, id='f58fd47e-41b8-4b60-80e2-bc8d02b54122', session_id='', volume=1.0)
[DEBUG:2022-01-11 19:14:44,253] rhasspyserver_hermes: TTS timeout will be 30 second(s)


Gruß Jens

p.s. Dabei muss "Audio Playing" deaktiviert sein, sonst meckert der Audioserver zu Rechtwave.Error: file does not start with RIFF idund es kommt "leer" als Knackser aus dem Lautsprecher.
Natürlich kann man ein leeres RIFF mit RIFF-ID erzeugen, doch die Audioausgabe soll ja sowieso andere Wege gehen.

p.p.s. Die Ursache des Timeouts geht auf die Web-Api zurück, welche mitif isinstance(play_bytes, AudioPlayBytes):
return play_bytes.wav_bytes
auf die Info der abzuspielenden Audiodatei wartet. Diese Info soll vom Audioserver kommen.from rhasspyhermes.audioserver import (
    AudioPlayBytes,

Hier wäre es angebracht, die Abfrage auf "AudioPlayFinished" umzustellen. Zumindestens für die Web-Api. Die normale MQTT-Api ist davon ja nicht betroffen.
https://github.com/rhasspy/rhasspy-server-hermes/blob/master/rhasspyserver_hermes/__main__.py#L1688 (https://github.com/rhasspy/rhasspy-server-hermes/blob/master/rhasspyserver_hermes/__main__.py#L1688)f.
https://github.com/rhasspy/rhasspy-server-hermes/blob/master/rhasspyserver_hermes/__init__.py#L621 (https://github.com/rhasspy/rhasspy-server-hermes/blob/master/rhasspyserver_hermes/__init__.py#L621)ff.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 12 Januar 2022, 10:41:22
Bei der Testerei mit dem externen TTS ist mir aufgefallen - wie bereits von pah bemerkt - , dass der Audioserver von Rhasspy die sessionId in playFinished falsch ausgibt. Das kann der "kleine TTS" besser.  8)
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 12 Januar 2022, 10:50:45
 :) Schön, dass wir mit dem Thema anscheinend ein paar Schritte weiter sind. Wäre nett, wenn die Erkenntnisse auch ihren Weg ins Rhasspy-Forum fänden.

Fühle mich erst mal in der Sichtweise bestärkt, dass man (mind.) für TTS also eine eigene siteId für (partielle) "externe" Lösungen an der "base" ("default") registrieren sollte (oder den jeweiligen Dienst (und teilweise das drumrum?) an "default" ganz abschalten muss). Leider sind die Zusammenhänge insgesamt reichlich undurchsichtig - egal ob mit oder ohne Verbesserungsbedarf auf der Rhasspy-Sessionmanagement-Seite...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 12 Januar 2022, 11:05:27
Ich warte erst einmal die Ergebnisse von pah ab und es wäre mir auch lieber, wenn ihr das ins ausländische übersetzt postet. Wie schon erwähnt, geht's bei mir nur mit Hilfe von Go+.*?le.  ;)
Die siteId "default" hatte ich getestet und die Verarbeitung lief durch - also doch kein Problem.

Gruß Jens
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Prof. Dr. Peter Henning am 13 Januar 2022, 09:58:47
Dieses ganze Dialogmanagement ist ein einziges Chaos, und auch die Protokolle sind nicht sauber implementiert.

Rhasspy sollte über MQTT die Sprachausgabe anstoßen, und dann nur noch auf eine einzelne Meldung warten. Es ist nunmal nicht Aufgabe der zentralen Instanz, den Versand an irgendeinen Audioserver sicherzustellen.

Wenn Du als Chef den Versand einer Broschüre an die Kunden einleitest, gehst Du ja auch nicht in die Poststelle und schaust, ob die Briefe auch ordentlich frankiert werden.

LG

pah
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 13 Januar 2022, 10:16:01
Bin nicht sicher, ob der Vergleich trägt. Wenn du "Audio per MQTT" zusagst, ist das m.E. eher so, wie wenn du einem konkreten Päckchenempfänger eine Sendung ankündigst und dann deiner Sekretärin sagst, sie soll das verschicken.
Kommt nichts an, wunderst du dich auch nicht, wenn dein Päckchenempfänger nach ein paar Tagen nachhakt, ob das denn versendet wurde...

Das ganze ändert aber nichts daran, dass es vermutlich buggy ist, aber hier eigentlich der falsche Ort ist, das zu diskutieren. Im Moment können wir hier nicht viel mehr tun wie die Fragen (und Lösungsansätze) in Richtung Rhasspy zu adressieren und auf der RHASSPY/FHEM-Seite dafür zu sorgen, dass wir nicht grade dort unser Glück versuchen, wo wir wissen, dass es fraglich ist, ob es klappt...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 13 Januar 2022, 11:12:42
Nachtrag noch zu dem hier:
Zitat von: Prof. Dr. Peter Henning am 13 Januar 2022, 09:58:47
Es ist nunmal nicht Aufgabe der zentralen Instanz
Was ist denn in einem Rhasspy-Setup die zentrale Instanz?

Auf jeder Rhasspy-Instanz wird konkret festgelegt, wie sie zu adressieren ist (default-siteId ist "default", bei allen anderen muss man m.E. was anderes nehmen), und für was sie welchen Dienst verwendet. Es gibt keine Verpflichtung für keine Instanz, bestimmte Aufgaben zu übernehmen, oder anders gesagt: Es gibt gar keine allgemeingültige Festlegung einer Zentrale... Das betrifft jeweils nur einzelne Aspekte.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 13 Januar 2022, 11:40:52
@pah
Es ist etwas komplexer.

Der kleine TTS macht seinen Dienst auf MQTT-Ebene ohne Timeout oder Fehlermeldungen, selbst wenn playBytes und playFinished auskommentiert sind.
Es wird nach ref verfahren. Hier steht einer Bereitstellung eines eigenen TTS nichts im Weg.

Sollte der TTS auch noch den Ausgangspart des Audioservers übernehmen, ist es gerechtfertigt, dass Rhasspy die Statusmeldung playFinished erhält. Diese Meldung ist optional und kann zusätzlich zum Echo-Canceling des Satelliten genutzt werden.

Wird die Web-Api bemüht, wird auf playBytes gewartet.
Dazu habe ich die Vermutung, dass die Web-Api ausschließlich für die GUI entwickelt wurde, um den User bei der lokalen Konfiguration zu unterstützen und fehlerhafte Einstellungen sofort zu melden.
Die Prüfung sollte aber an die tatsächliche Konfiguration angepasst sein und maximal auf ein playFinished warten. Alles Weitere kann man der Log entnehmen.

Diese Web-Konfigurations-Api wird in der Form adäquat zur MQTT-Api vollständig zur Verfügung gestellt. Das macht wenig Sinn. Zielführender wäre die Schaffung einer separaten Web-Api für die Nutzung externer Dienste. Bei einem Gemischt-Betrieb wäre es sinnvoll, der Rhasspy-Web-Instanz, einen AudioFile2RIFF-Konverter zu spendieren. Bei Nur-Web-Betrieb sollte auf Forderung von RIFF verzichtet werden und mit AudioFile2WAV bzw. nur mit WAV gearbeitet werden.

Insgesamt sehe ich Rhasspy als gut durchdacht an. Es müsste - genau wie die Referenz - , nur mal "ins Reine" geschrieben werden.

Gruß Jens

p.s. Es gibt zwei Wege, den TTS anzusteueren. Einmal durch den Dialogmanager, der im tts/say den Text und die vorhandene SessionId übergibt und zum anderen, eine direkte Übergabe des Textes mit tts/say optional mit einer erdachten sessionId.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 14 Januar 2022, 10:26:49
@Alle
Kennt jemand eine gute Noice-Reduction und/oder Echo-Canceling für den RPI0W mit ReSpeaker 2-Mics Pi HAT?
Meine Versuche in Richtung Pulse mit ec, etc. waren mit mäßigem Erfolg gekrönt...

Gruß Jens
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 15 Januar 2022, 15:33:38
Auf der Suche nach einer Lösung zu den per Standard deaktivierten Intents, war folgende Ergänzung in https://github.com/rhasspy/rhasspy-nlu-hermes/blob/master/rhasspynlu_hermes/__init__.py#L87 (https://github.com/rhasspy/rhasspy-nlu-hermes/blob/master/rhasspynlu_hermes/__init__.py#L87) erfolgreich:
                def intent_filter(intent_name: str) -> bool:
                    """Filter out intents."""
                    if not query.intent_filter and "_disabled" in intent_name:
                        return False
                    if query.intent_filter and "_disabled" in intent_name and not intent_name in query.intent_filter:
                        return False
                    if query.intent_filter:
                        return intent_name in query.intent_filter
                    return True

Durch das Einfügen von                     if not query.intent_filter and "_disabled" in intent_name:
                        return False
                    if query.intent_filter and "_disabled" in intent_name and not intent_name in query.intent_filter:
                        return False
in der Base, wird es nun möglich, [de.fhem:IntentName_disabled] per Standard zu deaktivieren.
Aktiviert wird der Intent, wenn er in "hermes/dialogueManager/configure->intents" oder/und in "hermes/dialogueManager/continueSession->intentFilter" aufgenommen wird.
Somit entfällt eine aufwändige Abfrage der Intents und Eintragung in die Negativliste von RHASSPY.
RHASSPY müsste dabei auf die erweiterten Namen angepasst und ein eventuelles Notify auf "event: start" deaktiviert werden.

Gruß Jens
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 17 Januar 2022, 14:38:47
Hmm, mal sehen, ob das Eingang findet...

Schöner wäre es ja, wenn man diesen Namensbestandteil prinzipiell weglassen könnte, aber es ist in FHEM ja kein größeres Problem, ggf. die Intents umzuleiten.
Fyi: Ein notify gibt es nicht, FHEM macht das disable hat bei jedem Start und/oder wenn es feststellt, dass ein erwarteter Filter nicht aktiv zu sein scheint (bei silent cancellation).

Das würde dann eben eine gewisse Sicherheit zum Zusstand von Rhasspy nach dem Start reinbringen, aber leider nicht das Problem beseitigen, dass deaktivierte Intents halt zu "not recognized"-Messages führen, der Intent an sich aber weiter "da" ist.

Mehr fällt mir im Moment dazu nicht ein.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Prof. Dr. Peter Henning am 17 Januar 2022, 17:33:36
ZitatKennt jemand eine gute Noice-Reduction und/oder Echo-Canceling für den RPI0W mit ReSpeaker 2-Mics Pi HAT?
Meine Versuche in Richtung Pulse mit ec, etc. waren mit mäßigem Erfolg gekrönt...

Alle diese Systeme bauen in das Audiosignal Artefakte ein, die wiederum die Wakeword-Erkennung stören.

LG

pah
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 17 Januar 2022, 19:47:28
Zitat von: Beta-User am 17 Januar 2022, 14:38:47
... aber leider nicht das Problem beseitigen, dass deaktivierte Intents halt zu "not recognized"-Messages führen, der Intent an sich aber weiter "da" ist...
Dazu wird es derzeit auch keine Lösung geben, da der Text von der STT erkannt wird und der NLU übergeben wird. Man müsste die Worte/Wortgruppen bei deaktiviertem Intent im ASR "abtrainieren" und bei Aktivierung neu lernen. Das kostet Zeit. Der "_disabled"-Vorschlag verschlankt jedenfalls die MQTT-Pakete, da bei jedem NLU- und Dialogvorgang fast alle Intentnamen übertragen werden müssen. Mal sehen, was draus wird...

Zitat von: Prof. Dr. Peter Henning am 17 Januar 2022, 17:33:36
Alle diese Systeme bauen in das Audiosignal Artefakte ein, die wiederum die Wakeword-Erkennung stören.
Das klingt interessant. Hast du einen Tipp, was man sonst machen kann?
Neulich habe ich ein Echo 2 geschenkt bekommen. Da kommt natürlich Rhasspy drauf.  :) Vielleicht läuft es da etwas besser, als beim ReSpeaker.

Gruß Jens

Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 18 Januar 2022, 08:40:13
Zitat von: JensS am 17 Januar 2022, 19:47:28
Neulich habe ich ein Echo 2 geschenkt bekommen. Da kommt natürlich Rhasspy drauf.  :) Vielleicht läuft es da etwas besser, als beim ReSpeaker.

Moment mal. Wie? Hast du da eine brauchbare Anleitung bei der Hand?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: dkreutz am 18 Januar 2022, 10:23:15
Zitat von: JensS am 14 Januar 2022, 10:26:49
Kennt jemand eine gute Noice-Reduction und/oder Echo-Canceling für den RPI0W mit ReSpeaker 2-Mics Pi HAT?
Meine Versuche in Richtung Pulse mit ec, etc. waren mit mäßigem Erfolg gekrönt...

Ergänzend zu dem was pah bereits angemerkt hat:

Ich habe eine Übersicht deutschsprachiger STT-Modelle (https://domcross.github.io/german-stt-evaluation/) erstellt. Dabei habe ich auch Testreihen mit RNNoise (https://github.com/xiph/rnnoise) durchgeführt und das Audiosignal damit mit "entrauscht". Das hat die Erkennungsrate nur marginal verbessert, bei manchen Modellen sogar verschlechtert (vermutlich weil diese mit "verrauschtem" Audio trainiert worden sind).
Das RNNoise-LADSPA-Plugin  (https://github.com/werman/noise-suppression-for-voice) kann über PulseAudio eingebunden werden, erzeugt aber zusätzliche Latenzen und der Nutzen ist begrenzt.

Rein softwarebasiertes Echo-Cancelling funktioniert auf dem RPI3 nur leidlich, zumindest war ich mit VoiceEngine-EC (https://github.com/voice-engine/ec) nicht erfolgreich. Der Respeaker 2Mic-Hat hat mWn auch keinen Hardware-Loopback, was für Echo-Cancelling sehr hilfreich wäre...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 18 Januar 2022, 17:28:27
Zitat von: drhirn am 18 Januar 2022, 08:40:13
Moment mal. Wie? Hast du da eine brauchbare Anleitung bei der Hand?
https://andrerh.gitlab.io/echoroot/ (https://andrerh.gitlab.io/echoroot/)
https://github.com/echohacking/wiki/wiki/Echo#amazon-echo-hardware-root-via-emmc-debug-pins (https://github.com/echohacking/wiki/wiki/Echo#amazon-echo-hardware-root-via-emmc-debug-pins)

@dkreutz
Danke für die Links, welche wie bei dir gewohnt, sehr gut recherchiert sind.
Auf deinem Github findet man viel zu Mycroft. Was meinst du zu Rhasspy vs. Mycroft?
Michael Hansen hat ja seit dem 10.11.21 nur noch in "The Future of Rhasspy" geposted.

Gruß Jens
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: dkreutz am 18 Januar 2022, 18:01:42
Zitat von: JensS am 18 Januar 2022, 17:28:27
Danke für die Links, welche wie bei dir gewohnt, sehr gut recherchiert sind.
Auf deinem Github findet man viel zu Mycroft. Was meinst du zu Rhasspy vs. Mycroft?
Michael Hansen hat ja seit dem 10.11.21 nur noch in "The Future of Rhasspy" geposted.

Ich habe bisher ausschließlich Mycroft genutzt, für Rhasspy habe ich mir bisher nicht  die Zeit genommen. Rhasspy hat einige interessante Features, z.B. das Hermes-Protocol für Satelliten-Lösungen oder MQTT statt dem propietären Message-Bus bei Mycroft. Dem Ziel des kompletten Offline-Betriebs ist Rhasspy inzwischen vermutlich  näher als es Mycroft ist. Aber Michael Hansen hat ja angekündigt, dass er diverse Features in Mycroft übernehmen will.

Bei Mycroft nervt ein wenig der Fokus auf die englische Sprache. Es kommt immer wieder vor, dass Skills nach einem Update nicht funktionieren, weil die Lokalisierung neuer Intents/Features fehlt und dann der Skill in Gänze nicht mehr geladen wird.

Aktuell beschäftige ich mich viel mit deutschsprachigen STT und TTS, da kommt die Pflege meiner Mycroft-Skills auch etwas zu kurz...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 19 Januar 2022, 07:01:13
Im Rhasspy-Forum wird nun auch die Werbetrommel für Mycroft gerührt...
Das Hermes-Protokoll-Konzept finde ich super zur zentralen Steuerung der einzelnen Prozesse aller Teilnehmer im Base-Satellite-Umfeld.
Jedoch ist MQTT nicht für Audiostreams, sondern für kurze Message-Slots gedacht. Da heißt es mitunter "schlangestehen" am Server und die MQTT-Übertragung von RIFF-Elementen ist nicht sonderlich effektiv.
Die Lösung von pah, alles ab der TTS auf eine andere Schiene zu legen, begrüße ich daher. Auch die Übertragung (Base+Sat.) der Sprache zur ASR, sollte abgekoppelt sein.
Die generelle Auslagerung der Audio-Streams zu einem STUN der Basis mit einem großen Cache wäre ein Ansatz. Das Hermes-Protokoll gibt dabei reichlich Möglichkeiten zu den Statusmeldungen der ausgelagerten Prozesse vor.
Nun warte ich erstmal ab, wann/wie die Anfragen im Forum beantwortet werden.

Gruß Jens
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 19 Januar 2022, 12:43:58
Zitat von: JensS am 19 Januar 2022, 07:01:13
Im Rhasspy-Forum wird nun auch die Werbetrommel für Mycroft gerührt...
Das habe ich bisher nicht unbedingt so empfunden - die dortige Community scheint teils erhebliche Vorbehalte gegen jeglichen kommerziellen Mitbewerber zu haben.

Wie dem auch sei, wir werden es erleben, wie es weitergeht, und bis dato funktioniert ja auch "alles" (bis auf dieses Wolfram-Thema bei der Installation, das sich sicher auch leicht lösen liese) weiter "as expected".

Bisher habe ich (entgegen meinen Erwartungen) auch noch keine großartigen Auswirkungen des "Missbrauchs" von MQTT als Transportmittel für Audio-Daten gespürt und finde es auch nicht dramatisch, dass die default-TTS-engine jetzt keine berauschenden Ergebnisse zeitigt.

Trotzdem wäre es natürlich interessant zu wissen, ob denn die experimentellen features im RHASSPY-Modul (insbesondere für externe TTS-Verarbeitung innerhalb der FHEM-Welt, v.a. mit AMAD.*) schon jemand getestet hat....? Ich selbst nutze wenn, dann die Telegram-Anbindung, und die ist rein text-basiert.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Prof. Dr. Peter Henning am 20 Januar 2022, 04:16:04
ZitatTrotzdem wäre es natürlich interessant zu wissen, ob denn die experimentellen features im RHASSPY-Modul (insbesondere für externe TTS-Verarbeitung innerhalb der FHEM-Welt, v.a. mit AMAD.*) schon jemand getestet hat....? Ich selbst nutze wenn, dann die Telegram-Anbindung, und die ist rein text-basiert.

Die Anbindung der Wakeword-Engine (mit selbsttrainiertem Modell) precise an meine AMAD-Devices läuft astrein, das ist schon eine Produktiversion. Womit ich derzeit noch kämpfe, ist die Verzweigung der Rückgaben.

"Hallo Jeannie" => precise => Rhasspy => MQTT-Device => aktiviere Spracheingabe auf einem AMAD-Device => TTS via Google => Ausführung via Babble.

Wenn allerdings der im TTS empfangene Satz beginnt mit "Sage Mycroft, <HIER KOMMT DER REST>...", soll dieser rest nahtlos via MQTT an Rhasspy weitergeleitet werden.

Best Erfahrungen mache ich dabei (auch fürs Training) mit dem Mikro hier: https://www.amazon.de/Blue-Microphones-Snowball-iCE-Microphone/dp/B014PYGTUQ/

Was noch kommen soll, sind diverse Satelliten. Und wünschen würde ich mir auch, dass ich eine gute (!) und selbst trainierbare Wakeword-Engine find, die auf mindestens 2 verschiedene Wakewords lauschen kann.

Leider bin ich derzeit beruflich stark belastet, so dass das alles sehr langsam geht.

LG

pah

P.S.: Unter AMAD ist immer noch nur halb gelöst, was bei fehlender Audio-Eingabe passiert, e.g., wie man das doofe Google-Fenster wegbekommt, das zur Wiederholung auffordert. Ich habe zwar einen Automagic-Prozess, der automatisch auf den Wiederholungsbutton klickt - aber ohne Audioeingabe bekommt man das derzeit eben nicht weg.

Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 20 Januar 2022, 06:30:33
Zitat von: Prof. Dr. Peter Henning am 20 Januar 2022, 04:16:04
Wenn allerdings der im TTS empfangene Satz beginnt mit "Sage Mycroft, <HIER KOMMT DER REST>...", soll dieser rest nahtlos via MQTT an Rhasspy weitergeleitet werden.
Was meinst du mit "nahtlos ... an Rhasspy weitergeleitet"? Ein if-else-Problem, sowie Probleme bei der Mustererkennung, schließe ich bei dir aus.

Gruß Jens
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 20 Januar 2022, 09:00:15
Zitat von: Prof. Dr. Peter Henning am 20 Januar 2022, 04:16:04
Die Anbindung der Wakeword-Engine (mit selbsttrainiertem Modell) precise an meine AMAD-Devices läuft astrein, das ist schon eine Produktiversion. Womit ich derzeit noch kämpfe, ist die Verzweigung der Rückgaben.

"Hallo Jeannie" => precise => Rhasspy => MQTT-Device => aktiviere Spracheingabe auf einem AMAD-Device => TTS via Google => Ausführung via Babble.

Wenn allerdings der im TTS empfangene Satz beginnt mit "Sage Mycroft, <HIER KOMMT DER REST>...", soll dieser rest nahtlos via MQTT an Rhasspy weitergeleitet werden.
Aha, du testest im Moment also noch mit der zweigleisigen Lösung.

Die letzte gepostete Dev-Version von RHASSPY sollte diese Unterscheidung zwanglos intern und ohne die Hilfsdevices ermöglichen, allerdings (ohne Eingriff) mit "Sage Rhasspy" statt "Sage Mycroft" (wo auch immer das herkam, aber auch eingestellt werden kann).
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Prof. Dr. Peter Henning am 20 Januar 2022, 16:25:45
Du meinst die Version vom 29.12. ?

gegen das "Sage Rhasspy" habe ich noch den Vorbehalt, dass dies eine Anleitung erfordert, wie man das auszusprechen hat.

LG

pah
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 20 Januar 2022, 16:36:34
Zitat von: Prof. Dr. Peter Henning am 20 Januar 2022, 16:25:45
Du meinst die Version vom 29.12. ?
Im Prinzip: Ja, wobei es danach noch ein reines "commandref-update" gab:
Zitat von: Beta-User am 06 Januar 2022, 05:57:36
@pah: Anbei auch die letzte Überarbeitung, bringt aber gg. der von neulich nur eine Beschreibung der neuen Attribute in der commandref.
Zitatgegen das "Sage Rhasspy" habe ich noch den Vorbehalt, dass dies eine Anleitung erfordert, wie man das auszusprechen hat.
Ok, mir war nicht klar, dass das schwieriger ist wie (das aber vermutlich schon vorhandene?) "Mycroft" ;D ...



Zwei andere Themen noch:
- zum einen gibt es "automagic" nicht mehr beim großen "g". Man kann es zwar noch von der Herstellerseite holen, aber das sieht mir nach einer Sackgasse aus (und verdirbt mir zumindest die Freude am Einrichten irgendwelcher Flows).

- zum anderen hat hier jemand was vorgestellt für TTS via IBM watson: https://community.rhasspy.org/t/simple-shell-script-to-use-watson-ibms-cloud-tts-service-in-rhasspy/3431. Allerdings muss ich zugeben, dass mich die Betonung des deutschen Beispielsatzes in https://www.ibm.com/demos/live/tts-demo/self-service/home nicht davon überzeugt hat, dass diese Lösung wirklich ein toller Ersatz für "08/15-Rhasspy-TTS" wäre...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: dkreutz am 20 Januar 2022, 17:18:13
Zitat von: Beta-User am 19 Januar 2022, 12:43:58
Das habe ich bisher nicht unbedingt so empfunden - die dortige Community scheint teils erhebliche Vorbehalte gegen jeglichen kommerziellen Mitbewerber zu haben.

Soweit das Mycroft betrifft, sollte man aber schon zwischen dem Unternehmen "Mycroft AI Inc.", das Hardware und "professionellen Support" anbietet und der Open-Source Software (https://github.com/MycroftAI) unterscheiden.

Mycroft KANN vollständig offline betrieben werden, wenn man entsprechend Abstriche bei TTS-Qualität, STT-Fehlerrate und Komfort (Setup, Device-Konfiguration, Skill-Settings) in Kauf nimmt.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Gisbert am 13 Februar 2022, 09:55:00
Hallo Jörg,

gibt es noch eine Weiterentwicklung des RHASSPY-Moduls? Fhem scheint noch keinen Download bereitzustellen, zumindest nicht, als ich letztens geschaut habe.

Das Modul funktioniert bei meinen Anwendungen problemlos und auch besser als Google Assistant, der immer mal wieder nach "Rollläden in deiner Nähe" sucht.

Das state sieht gelegentlich so aus, die Sprachbefehle funktionieren aber:
state
http://192.168.1.46:12101/api/intents: empty answer received


Viele​ Grüße​ Gisbert​
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 13 Februar 2022, 11:08:23
Zitat von: Gisbert am 13 Februar 2022, 09:55:00
Das Modul funktioniert bei meinen Anwendungen problemlos und auch besser als Google Assistant, der immer mal wieder nach "Rollläden in deiner Nähe" sucht.
:) Freut mich zu hören!

Zitat von: Gisbert am 13 Februar 2022, 09:55:00
gibt es noch eine Weiterentwicklung des RHASSPY-Moduls?
Es gibt nichts aktuelles im svn, aber ich bin an ein paar Kleinigkeiten dran, die man verbessern kann. Leider fehlt bisher weiter Rückmeldung zu den AMAD.*-Geschichten, das würde ich eigentlich gerne vorher abschließen, sonst muss ich die Doku ändern...

Zitat
Das state sieht gelegentlich so aus, die Sprachbefehle funktionieren aber:
Hmmm, sowas hat mich bisher nicht gestört, bin auch grade nicht sicher, ob das ein Hinweis auf eine mögliche Fehlfunktion ist.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 21 Februar 2022, 12:03:15
Zitat von: Beta-User am 13 Februar 2022, 11:08:23
aber ich bin an ein paar Kleinigkeiten dran, die man verbessern kann. Leider fehlt bisher weiter Rückmeldung zu den AMAD.*-Geschichten, das würde ich eigentlich gerne vorher abschließen, sonst muss ich die Doku ändern...
...jetzt habe ich halt erst mal die Doku geändert...

Im Anhang ist mal folgendes "adressiert" (auch wenn ich bei den ganzen Diskussionen drumrum teilweise nicht sicher bin, ob das jetzt "so herum" eigentlich richtig ist):
Zitat von: Beta-User am 17 Februar 2022, 14:23:17
- "encode": (https://forum.fhem.de/index.php/topic,126088.0.html (https://forum.fhem.de/index.php/topic,126088.0.html)) Ersetzen von decode_json durch "nicht-transformative" Varianten (Test läuft bereits);
- Umstellung auf "setNotifyDev()";
- "auto-training": Ändert man relevante Attribute, soll Rhasspy relativ direkt die aktualisierten Infos automatisch erhalten (Idee von martinp876). code dazu ist am werden.

Der Zweite Punkt bedingt, dass _zwingend_ eine recht aktuelle fhem.pl erforderlich ist (max. 2-3 Wochen alt oder so).
Der dritte Punkt ist möglicherweise nicht funktional und nur bis zu dem Punkt getestet, dass zwei neue (versteckte) Readings angelegt werden, in denen stehen sollte, was Rhasspy "weiß".

Das update ist eher für Tester und Mitentwickler gedacht :) . "Normale Anwender", die bisher gut klargekommen sind, dürfen sich (außer einer etwas verbesserten Doku) keine großen Hoffnungen auf substantielle Verbesserungen machen (ist ja auch nicht zwingend nötig).
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Prof. Dr. Peter Henning am 21 Februar 2022, 18:16:56
ZitatLeider fehlt bisher weiter Rückmeldung zu den AMAD.*-Geschichten, das würde ich eigentlich gerne vorher abschließen
Ich auch. Bin aber fremdgesteuert jetzt am Semesterende...

Ich habe die neue Modulversion mal in meinem Produktivsystem installiert (zitter...).

In dem Moment, wo ich versuche, das Attribut rhasspySTT zu setzen, kommt die Fehlermeldung, dass zuerst ein BabbleKey ins DEF gehöre - und dann wird die komplette Definition des Rhasspy-Devices gelöscht (inklusive aller mühsam gesetzten Attribute) :(

Log-Eintrag nur
ZitatPERL WARNING: Use of uninitialized value $siteId in concatenation (.) or string at /opt/fhem/FHEM/10_RHASSPY.pm line 1863.
2022.02.21 18:16:34 1: PERL WARNING: Use of uninitialized value $siteId in substitution (s///) at /opt/fhem/FHEM/10_RHASSPY.pm line 1864.
2022.02.21 18:16:34 1: PERL WARNING: Use of uninitialized value $siteId in lc at /opt/fhem/FHEM/10_RHASSPY.pm line 1866.
2022.02.21 18:18:34 1: Connection to Rhasspy base failed: read from http://192.168.0.115:12101 timed out

LG

pah
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 22 Februar 2022, 10:06:51
Zitat von: Prof. Dr. Peter Henning am 21 Februar 2022, 18:16:56
Ich auch. Bin aber fremdgesteuert jetzt am Semesterende...
Danke für den Versuch, volles Verständnis!

Zitat
In dem Moment, wo ich versuche, das Attribut rhasspySTT zu setzen, kommt die Fehlermeldung, dass zuerst ein BabbleKey ins DEF gehöre - und dann wird die komplette Definition des Rhasspy-Devices gelöscht (inklusive aller mühsam gesetzten Attribute) :(

Log-Eintrag nur
Hmm, seltsam, der Effekt scheint aus einer Interaktion mit Rhasspy zu kommen, jedenfalls sind die Warnings nur erklärlich, wenn irgendeine Message kam, (ohne siteId) und das hat eigentlich - zumindest auf den ersten Blick - nichts mit den Babble&Co-Einstellungen und -Attributen zu tun.

Im Testsystem (ohne Rhasspy dahinter) unter fhem.pl 25684 2022-02-15@Perl5.32.1 kann ich sowohl
- einen Teil der Keys in rhasspySTT setzen, die nichts mit Babble zu tun haben,
- eine korrekte Rückmeldung sehen, wenn ich den filterFromBabble setze ohne DEF-Eintrag und
- den Filter setzen, wenn der DEF-Eintrag vorhanden ist.
Das sieht also eigentlich unauffällig aus.

Kannst du mir deine DEF zeigen bzw. die weiteren Schlüssel über die Adresse hinaus? War da gleich auch "autoTraining" gesetzt?

Bin grade ratlos. Bei Gelegenheit muss ich dann halt mal auch eine "Pseudo-AMAD-Babble-Umgebung" in meinem Hauptsystem aufziehen, vielleicht sieht man da mehr...
Der Code läuft da schon seit mehreren Tagen, allerdings hatte ich bisher auch den ESP32 nicht wieder in Betrieb genommen, um Umlaut-siteId's zu testen (das könnte mit den Warnings zusammenhängen).

Falls sonst jemand Ideen hat, bitte melden!
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Prof. Dr. Peter Henning am 22 Februar 2022, 20:50:54
Hier mal ein List. Obwohl das AMAD-Device ordentlich funktioniert, gibt es weder einen Empfang vom AMAD-Device, noch eine Sprachausgabe darauf.

LG

pah



Internals:
   Babble     Babble
   CONFIGFILE /opt/fhem/rhasspy-de.cfg
   DEF        baseUrl=http://192.168.0.115:12101
Babble=Babble
   FUUID      6213cb45-f33f-8771-7d02-22c1a85ae4d28723
   IODev      rhasspyMQTT2
   LANGUAGE   de
   LASTInputDev rhasspyMQTT2
   MODULE_VERSION 0.5.13
   MSGCNT     89
   NAME       rhasspyDev
   NOTIFYDEV  AMADBridge,TYPE=(ROOMMATE|GUEST)
   NR         1098236
   NTFY_ORDER 50-rhasspyDev
   STATE      online
   TYPE       RHASSPY
   baseUrl    http://192.168.0.115:12101
   defaultRoom default
   devspec    genericDeviceType=.+
   encoding   utf8
   fhemId     fhem
   prefix     rhasspy
   rhasspyMQTT2_MSGCNT 89
   rhasspyMQTT2_TIME 2022-02-22 20:42:11
   siteId     defhem
   useGenericAttrs 1
   READINGS:
     2022-02-22 14:43:24   IODev           rhasspyMQTT2
     2022-02-22 20:41:00   hotwordAwaiting_default 1
     2022-02-22 14:55:31   intents         de.fhem:SetOnOff,de.fhem:Musik,de.fhem:GetOnOff,de.fhem:GetTime,de.fhem:GetState
     2022-02-22 20:42:11   lastIntentPayload {"customData":null,"input":"wie spät ist es","intent":"GetTime","lang":null,"probability":1,"rawInput":"wie spät ist es","requestType":"text","sessionId":"fhem.textCommand","siteId":"default"}
     2022-02-22 20:42:11   lastIntentTopic hermes/intent/de.fhem_GetTime
     2022-02-22 20:41:00   listening_default 0
     2022-02-22 20:42:11   responseType    text
     2022-02-22 14:55:22   siteIds         default
     2022-02-22 15:08:07   state           online
     2022-02-22 20:42:11   textResponse    Es ist 20 Uhr 42
     2022-02-22 15:08:07   updateSlots     OK
     2022-02-22 20:19:13   voiceResponse   Es ist 20 Uhr 19
   TIMER:
   helper:
     STT:
       config:
         AMADCommBridge AMADBridge
         allowed    Tab2.EG
         filterFromBabble sage.mycroft
     TTS:
       default    Tab2.EG
       config:
         Tab2.EG:
           siteId     default

      (hier ungefähr 20 Devices mit genericdevicetype herausgenommen)

       rhasspyRooms:
         default:
       
    (hier diverse rhasspyRooms herausgenommen)

     lng:
       commaconversion 1
       mutated_vowels:
         Ä         Ae
         Ö         Oe
         Ü         Ue
         ß         ss
         ä         ae
         ö         oe
         ü         ue
       responses:
         DefaultCancelConfirmation Habe abgebrochen
         DefaultChangeIntentRequestRawInput wechseln zu $rawInput
         DefaultChoiceNoOutstanding warte grade nicht auf eine Auswahl
         DefaultConfirmation Gerne!|wird erledigt|ok|jawohl|zu diensten
         DefaultConfirmationBack also nochmal
         DefaultConfirmationNoOutstanding warte grade nicht auf eine bestätigung
         DefaultConfirmationReceived Ok, werde ich machen
         DefaultConfirmationRequestRawInput bestätige $rawInput
         DefaultConfirmationTimeout Tut mir leid, da hat etwas zu lange gedauert
         DefaultError Da passt irgend etwas nicht
         NoActiveMediaDevice Tut mir leid, es ist kein Wiedergabegerät aktiv
         NoDeviceFound Tut mir leid, ich konnte kein passendes Gerät finden
         NoMappingFound Tut mir leid, ich konnte kein passendes Mäpping finden
         NoMediaChannelFound Tut mir leid, der angefragte Kanal scheint nicht zu existieren.
         NoNewValDerived Tut mir leid, ich konnte den Zielwert nicht ausrechnen
         NoTimedOnDeviceFound Das gewählte Gerät unterstützt leider keine taimer Kommandos
         NoValidData ich habe leider zu wenig Daten um den Vorgang auszuführen
         RequestChoiceDevice Es kommen mehrere Geräte in Frage, bitte wähle zwischen $first_items oder $last_item
         RequestChoiceRoom Es kommen mehrere Geräte in verschiedenen Räumen in Frage, wähle einen Raum von  $first_items oder $last_item
         SilentCancelConfirmation
         duration_not_understood Tut mir leid, ich habe die Dauer nicht verstanden
         reSpeak_failed Tut mir leid, ich kann mich nicht erinnern
         timeRequest Es ist $hour Uhr $min
         timerCancellation $label im $room gelöscht
         weekdayRequest Heute ist $weekDay
         Change:
           brightness $deviceName ist auf $value gestellt
           desired-temp Die Solltemperatur von $location beträgt $value Grad
           humidity   Die Luftfeuchtigkeit von $location beträgt $value Prozent
           knownType  $mappingType von $location beträgt $value Prozent
           setTarget  $device ist auf $value gesetzt
           soilMoisture Die Bodenfeuchte von $location beträgt $value Prozent
           unknownType Der Wert von $location beträgt $value Prozent
           volume     $deviceName ist auf $value gestellt
           waterLevel Der Wasserstand von $location beträgt $value Prozent
           battery:
             0          Der Batteriestand von $location ist $value
             1          Der Batteriestand von $location beträgt $value Prozent
           temperature:
             0          Die Temperatur von $location ist $value
             1          Die Temperatur von $location beträgt $value Grad
         getStateResponses:
           STATE      $deviceName hat den Status [$device:STATE]
           price      Der aktuelle Preis für $reading in $deviceName beträgt [$device:$reading:d] Euro
           update     update für $deviceName ist angestoßen
         timerEnd:
           0          $label abgelaufen
           1          $label im raum $room abgelaufen
         timerSet:
           0          $label im Raum $room ist gestellt auf $seconds sekunden
           1          $label im Raum $room ist gestellt auf $minutetext $seconds
           2          $label im Raum $room ist gestellt auf $minutetext
           3          $label im Raum $room ist gestellt auf $hours stunden $minutetext
           4          $label im Raum $room ist gestellt auf $hours uhr $minutes
           5          $label im Raum $room ist gestellt auf morgen, $hours uhr $minutes
       stateResponses:
         inOperation:
           0          $deviceName ist fertig
           1          $deviceName läuft noch
         inOut:
           0          $deviceName ist ausgefahren
           1          $deviceName ist eingefahren
         onOff:
           0          $deviceName ist ausgeschaltet|$deviceName ist aus
           1          $deviceName ist eingeschaltet|$deviceName ist an
         openClose:
           0          $deviceName ist geöffnet|$deviceName ist offen
           1          $deviceName ist geschlossen|$deviceName ist zu
       units:
         unitHours:
           0          stunden
           1          eine stunde
         unitMinutes:
           0          minuten
           1          eine minute
         unitSeconds:
           0          Beispiel 1a: einige Sekunden
           1          Beispiel 1b: genau eine Sekunde
       words:
         and        und
         off        aus
         on         an
     shortcuts:
     tweaks:
Attributes:
   IODev      rhasspyMQTT2
   group      Rhasspy-Fhem
   languageFile /opt/fhem/rhasspy-de.cfg
   rhasspySTT allowed=Tab2.EG
AMADCommBridge=AMADBridge
filterFromBabble=sage mycroft
   rhasspyTTS Tab2.EG=siteId=default ttsCommand={speak("$DEVICE","$message")}
   room       RhasspyRoom
   verbose    3

Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 22 Februar 2022, 21:44:35
Hmmm, das list sieht m.E. OK aus, von daher wären die Events bzw. Readings an der AMADBridge interessant. Passt evtl. noch nicht zu dem, was NotifyFn erwartet?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 23 Februar 2022, 10:42:01
Melde mich auch wiedermal und lade zu einem Brainstorming ein:

Der Timer funktioniert nicht, wenn ich eine Satelliten-Gruppe habe (z.B. siteIds wohnzimmer.01 + wohnzimmer.02) weil die Ausgabe ja im Endeffekt auf einen Raum fixiert ist und nicht auf die siteId. Beziehungsweise RHASSPY nicht weiß, auf welcher von mehreren siteIds in einem Raum es die Ausgabe machen soll, wenn ich den Timer von einem anderen Raum aus starte.

Wie könnten wir das am Besten lösen?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 23 Februar 2022, 10:54:46
Kannst du mal checken, ob das paßt, wenn das Kommando geändert wird (#4856 und #4862) und statt auf $timerRoom auf $siteId  ausgegeben wird?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 23 Februar 2022, 11:00:38
Vermutlich.
Aber wenn ich in der Küche sage "Stell den Timer im Wohnzimmer auf x", woher soll dann RHASSPY wissen, auf welcher siteId im Wohnzimmer es die Ausgabe machen soll?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 23 Februar 2022, 11:13:51
OK, korrekt, löst nur einen Teil des Problems... ::)

Das ganze ist möglicherweise nicht nur auf "sendSpeakCommand" beschränkt, sondern auch ein Thema für "setPlayWav", und ein wenig bin ich der Auffassung, dass das eigentlich in Rhasspy gelöst werden sollte und nicht in RHASSPY.
Ansatzpunkt wäre eine Analogie zum siteId2room-Reading? Also: Wenn "speak" ausgeführt werden soll, schau, welcher Raum betroffen ist bzw. ob das eine "echte" siteId ist, wenn nein, nimm die Vorgabe aus dem Reading, wenn nicht, nimm die längste siteId, die zu dem Raum paßt...?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 23 Februar 2022, 11:17:31
Zitat von: Beta-User am 23 Februar 2022, 11:13:51
und ein wenig bin ich der Auffassung, dass das eigentlich in Rhasspy gelöst werden sollte und nicht in RHASSPY.

Rhasspy kennt aber die Räume nicht. Weiß also nicht, welche siteId in welchem Raum ist. Oder hab ich dich gerade falsch verstanden?


Zitatwenn nicht, nimm die längste siteId, die zu dem Raum paßt...?

Du meinst quasi einen Buchstaben-Vergleich nach der Art: Es gibt einen Raum "wohnzimmer", gibt's auch eine siteId mit "wohnzimmer"?
Was aber, wenn die siteIds gleich lang sind?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 23 Februar 2022, 11:30:32
Zitat von: drhirn am 23 Februar 2022, 11:17:31
Rhasspy kennt aber die Räume nicht. Weiß also nicht, welche siteId in welchem Raum ist. Oder hab ich dich gerade falsch verstanden?
Na ja, nach meinem Verständnis macht das mit den Gruppen nur Sinn, wenn mehrere Rhasspy in einem Raum vorhanden sind, aber klar, die Logik "Raum" = "Gruppenname" ist nicht 100% zwingend. Rhasspy sollte aber eigentlich irgendwie intern entscheiden, wie ein an eine Gruppe abgesetzter "Befehl" (unabhängig davon, um was es sich konkret handelt) an die einzelnen Gruppenmitglieder "zugestellt" wird.

Zitat
Du meinst quasi einen Buchstaben-Vergleich nach der Art: Es gibt einen Raum "wohnzimmer", gibt's auch eine siteId mit "wohnzimmer"?
Was aber, wenn die siteIds gleich lang sind?
Im Zweifel: Zufall...
Man könnte auch noch alphanumerisch innerhalb der Länge sortieren oä.. War nur erst mal der Spur nach, und besser "irgendwo in der Nähe" eine Ausgabe als gar keine ::) ... Die Logik zu verfeinern ist dann nicht das große Thema, schwieriger ist die Frage, wann diese (zentrale) Logik anzusteuern ist.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Prof. Dr. Peter Henning am 23 Februar 2022, 16:46:19
Also, erstmal mein Senf zum Thema "mehrere Sites" in einem Raum.

Ich habe stellenweise mehrere AMAD-Devices in einem Raum. Die haben bei mir Attribute z.B. babbleRoom=wohnzimmer:esstisch. Eines der Devices hat _keinen_ "Unterraum". Das wird für Ausgabe genommen, wenn ein solcher "Unterraum" nicht angegeben wird. Wenn die Ausgabe direkt auf eine Eingabe folgte, findet die Ausgabe generell dort statt, wo auch die Eingabe war.

Jetzt zum Thema AMAD und RHASSPY: Ich habe mir da wirklich einen Wolf gesucht und erwarte dafür die Gabe eines Glases Alkohol.

1. Das Modul RHASSPY startet die Spracheingabe auf einem AMAD-Device Tab2.EG. Das ist aber falsch, denn diesen Devicenamen kennt RHASSPY nur aus dem Attribut
rhasspyTTS Tab2.EG=siteId=default ttsCommand={speak("$DEVICE","$message")}
Und sorry, aber die Spracheingabe hat mit TTS nichts zu tun.

2. Das Modul RHASSPY startet die Spracheingabe auf einem AMAD-Device leider _nicht_, wenn das "Hotword detected" wurde (wie es eigentlich sein sollte). Was läuft ab?
a. Nach der Hotword-Erkennung sendet Rhasspy eine Nachricht hermes/hotword/toggleOff, um die Hotword-Erkennung auszuschalten. Denn dann wird der Hotword-Erkennungston abgespielt.
b. Unmittelbar danach sendet Rhasspy eine Nachricht hermes/hotword/toggleOn, um die Hotword-Erkennung wieder einzuschalten ===> In diesem Moment startet RHASSPY die Spracherkennung - also eigentlich zu spät.
c. Dann wird eine Dialogsession gestartet, dafür wieder mit  hermes/hotword/toggleOff die Hotword-Erkennung ausgeschaltet.
d. Die Dialogsession wird natürlich im nachfolgenden Auszug nicht gefüllt. Also geht Rhasspy nach 30 Sekunden in einen Timeout, und schaltet die Howord-Erkennung mit einem hermes/hotword/toggleOn wieder ein. Macht Sinn, denn es soll ja jetzt erneut auf das Hotword gelauscht werden. ===> Durch den Fehler in RHASSPY startet die Spracherkennung aber bei diesem hermes/hotword/toggleOn erneut.

Die beiden Fehler müssten irgendwie behoben werden, damit das einsetzbar ist.

LG

pah


2022.02.23 16:06:23 5: RHASSPY: [rhasspyDev] Parse (IO: rhasspyMQTT2): Msg: hermes/hotword/hallo-jeannie-3/detected => {"modelId": "hallo-jeannie-3.pb", "modelVersion": "", "modelType": "personal", "currentSensitivity": 0.5, "siteId": "default", "sessionId": null, "sendAudioCaptured": null, "lang": null, "customEntities": null}
2022.02.23 16:06:23 5: Parsed value: default for key: siteId
2022.02.23 16:06:23 1: [VoiceMQTT] Hotword hallo-jeannie detected =====> Das ist OK so !!!

2022.02.23 16:06:23 5: RHASSPY: [rhasspyDev] Parse (IO: rhasspyMQTT2): Msg: hermes/hotword/toggleOff => {"siteId": "default", "reason": "playAudio"}
2022.02.23 16:06:23 5: Parsed value: default for key: siteId
2022.02.23 16:06:23 5: RHASSPY: [rhasspyDev] Parse (IO: rhasspyMQTT2): Msg: hermes/hotword/toggleOn => {"siteId": "default", "reason": "playAudio"}
2022.02.23 16:06:23 5: Parsed value: default for key: siteId
2022.02.23 16:06:23 5: analyzeAndRunCmd called with command: set Tab2.EG activateVoiceInput
2022.02.23 16:06:23 5: set Tab2.EG activateVoiceInput is a FHEM command

2022.02.23 16:06:23 5: RHASSPY: [rhasspyDev] Parse (IO: rhasspyMQTT2): Msg: hermes/dialogueManager/sessionStarted => {"sessionId": "default-hallo-jeannie-3-c5604fc3-acb8-4fd9-8a24-0eaded724e92", "siteId": "default", "customData": "hallo-jeannie-3", "lang": null}
2022.02.23 16:06:23 5: Parsed value: hallo-jeannie-3 for key: customData
2022.02.23 16:06:23 5: Parsed value: default-hallo-jeannie-3-c5604fc3-acb8-4fd9-8a24-0eaded724e92 for key: sessionId
2022.02.23 16:06:23 5: Parsed value: default for key: siteId
2022.02.23 16:06:23 5: default room used
2022.02.23 16:06:23 5: RHASSPY: [rhasspyDev] Parse (IO: rhasspyMQTT2): Msg: hermes/hotword/toggleOff => {"siteId": "default", "reason": "dialogueSession"}
2022.02.23 16:06:23 5: Parsed value: default for key: siteId

2022.02.23 16:06:27 1: [Hear] from device Tab2.EG
2022.02.23 16:06:27 1: [speakTablet] name=Tab2.EG text=Das Haus ist Nicht Gesichert und im Modus Normal. Es ist Tageszeit, letzter Übergang war Nachmittag.

2022.02.23 16:06:27 5: [rhasspyDev] NotifyFn called with event in AMADBridge
2022.02.23 16:06:53 5: RHASSPY: [rhasspyDev] Parse (IO: rhasspyMQTT2): Msg: hermes/dialogueManager/sessionEnded => {"termination": {"reason": "timeout"}, "sessionId": "default-hallo-jeannie-3-c5604fc3-acb8-4fd9-8a24-0eaded724e92", "siteId": "default", "customData": "hallo-jeannie-3"}
2022.02.23 16:06:53 5: Parsed value: default for key: siteId
2022.02.23 16:06:53 5: Parsed value: hallo-jeannie-3 for key: customData
2022.02.23 16:06:53 5: Parsed value: default-hallo-jeannie-3-c5604fc3-acb8-4fd9-8a24-0eaded724e92 for key: sessionId
2022.02.23 16:06:53 5: default room used

2022.02.23 16:06:53 5: RHASSPY: [rhasspyDev] Parse (IO: rhasspyMQTT2): Msg: hermes/hotword/toggleOn => {"siteId": "default", "reason": "dialogueSession"}
2022.02.23 16:06:53 5: Parsed value: default for key: siteId
2022.02.23 16:06:53 5: analyzeAndRunCmd called with command: set Tab2.EG activateVoiceInput
2022.02.23 16:06:53 5: set Tab2.EG activateVoiceInput is a FHEM command

2022.02.23 16:06:58 1: [Hear] from device Tab2.EG
2022.02.23 16:06:58 1: [Babble_DoIt] Executing from hash: meister.sitzgruppe.spielen.none/ 
2022.02.23 16:06:58 1: [speakTablet] name=Tab2.EG text=:002:
2022.02.23 16:06:58 5: [rhasspyDev] NotifyFn called with event in AMADBridge

Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 23 Februar 2022, 17:06:42
Zitat von: Prof. Dr. Peter Henning am 23 Februar 2022, 16:46:19
Ich habe stellenweise mehrere AMAD-Devices in einem Raum. Die haben bei mir Attribute z.B. babbleRoom=wohnzimmer:esstisch. Eines der Devices hat _keinen_ "Unterraum". Das wird für Ausgabe genommen, wenn ein solcher "Unterraum" nicht angegeben wird. Wenn die Ausgabe direkt auf eine Eingabe folgte, findet die Ausgabe generell dort statt, wo auch die Eingabe war.

Guter Workaround! Bedingt halt ein zusätzliches Devices. In meinem Fall egal, Hardware hab ich genug herumliegen ;)
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 23 Februar 2022, 17:37:13
Zitat von: Prof. Dr. Peter Henning am 23 Februar 2022, 16:46:19
Also, erstmal mein Senf zum Thema "mehrere Sites" in einem Raum.

Ich habe stellenweise mehrere AMAD-Devices in einem Raum. Die haben bei mir Attribute z.B. babbleRoom=wohnzimmer:esstisch. Eines der Devices hat _keinen_ "Unterraum". Das wird für Ausgabe genommen, wenn ein solcher "Unterraum" nicht angegeben wird. Wenn die Ausgabe direkt auf eine Eingabe folgte, findet die Ausgabe generell dort statt, wo auch die Eingabe war.
Dieses setup macht m.E. Sinn und sollte daher für die meisten Fälle passen bzw. sich auch so im Rhasspy-Kontext umsetzen lassen.

Damit auch 1:1 das Ausgangsdevice wieder angesprochen wird, ist anbei das mit siteId statt timerRoom umgesetzt.

Zitat von: drhirn am 23 Februar 2022, 17:06:42
Guter Workaround! Bedingt halt ein zusätzliches Devices. In meinem Fall egal, Hardware hab ich genug herumliegen ;)
Wieso das? Es müßte doch reichen, eines der vorhandenen "doppelten" umzubenennen, oder?

@pah: Da war noch ein "Klopper" in notifySTT()...
Babble_DoIt() wurde aus dem falschen Kontext heraus aufgerufen, jetzt geht das über die Indirektion AnalyzePerlCommand() und sollte daher "save" sein. Wenn das Zugeschlagen hätte, müßte aber eigentlich FHEM komplett abgeschmiert sein.

ZitatJetzt zum Thema AMAD und RHASSPY: Ich habe mir da wirklich einen Wolf gesucht und erwarte dafür die Gabe eines Glases Alkohol.
Ich trinke gerne zum Opfer ein Glas ordentlichen Rotweins auf dich ;D ...
(Im Ernst: einen gemeinsamen Verzehr jeweils einer "Gabe" sollten wir ins Auge fassen.)

Zitat1. Das Modul RHASSPY startet die Spracheingabe auf einem AMAD-Device Tab2.EG. Das ist aber falsch, denn diesen Devicenamen kennt RHASSPY nur aus dem Attribut
rhasspyTTS Tab2.EG=siteId=default ttsCommand={speak("$DEVICE","$message")}
Und sorry, aber die Spracheingabe hat mit TTS nichts zu tun.
Was die Namenswahl des Attributs angeht: An sich berechtigter Einwand, aber man kann das ja auch nur unidirektional nutzen, um reine Ausgaben zu machen. Und weil es einigermaßen naheliegend ist, dass Geräte, die für die Ausgabe verwendet werden, auch für die Eingabe tauglich sind, wird halt das herangezogen, was da ist. Sonst müßte man doppelt konfigurieren, was auch unschön wäre... (Doku ist eine weitere Frage, klar).

Zitat
2. Das Modul RHASSPY startet die Spracheingabe auf einem AMAD-Device leider _nicht_, wenn das "Hotword detected" wurde (wie es eigentlich sein sollte).
Habe den Teil, der für "activateVoiceInput" verantwortlich ist verschoben von #3022ff nach #3042ff. Das sollte jetzt also auf "detected" reagieren und nicht mehr "doppelt" auf "toggleOn".

Kann aber noch nicht abschätzen, wie weit das trägt; da scheint auch noch manches andere mit aktiv zu sein, dessen Einfüsse auf das Gesamtgeschehen ich im Moment nicht so schnell überblicken kann.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 23 Februar 2022, 17:43:41
Zitat von: Prof. Dr. Peter Henning link=topic=11944
... und erwarte dafür die Gabe eines Glases Alkohol.
Undank ist der Welten Lohn.  ;D
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 23 Februar 2022, 17:47:15
Zitat von: Beta-User am 23 Februar 2022, 17:37:13
Damit auch 1:1 das Ausgangsdevice wieder angesprochen wird, ist anbei das mit siteId statt timerRoom umgesetzt.

Sicher, dass damit in der Küche der Satz "Timer im Wohnzimmer auf X" funktioniert? Der eine Kurztest von mir heute hat in meiner schnellschnell zusammengestückelten Testumgebung ergeben, dass dann die siteId der Küche genommen wird. Kann mich aber auch getäuscht haben.

ZitatWieso das? Es müßte doch reichen, eines der vorhandenen "doppelten" umzubenennen, oder?

Nein. Dann funktioniert ja die "Gruppenfunktionalität" von Rhasspy nicht mehr und es reagieren wieder beide auf das Kommando nach dem Wakeword.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 23 Februar 2022, 17:54:09
Zitat von: drhirn am 23 Februar 2022, 17:47:15
Sicher, dass damit in der Küche der Satz "Timer im Wohnzimmer auf X" funktioniert? Der eine Kurztest von mir heute hat in meiner schnellschnell zusammengestückelten Testumgebung ergeben, dass dann die siteId der Küche genommen wird. Kann mich aber auch getäuscht haben.
...vermutlich nicht, jedenfalls vorerst wieder zurückgedreht.

Zitat
Nein. Dann funktioniert ja die "Gruppenfunktionalität" von Rhasspy nicht mehr und es reagieren wieder beide auf das Kommando nach dem Wakeword.
Blöd; da bin ich doch glatt froh, dass ich praktisch nur die Mobile-App nutze...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 23 Februar 2022, 18:27:59
Zitat von: Prof. Dr. Peter Henning am 23 Februar 2022, 16:46:19
Jetzt zum Thema AMAD und RHASSPY: Ich habe mir da wirklich einen Wolf gesucht und erwarte dafür die Gabe eines Glases Alkohol.
Zitat von: JensS am 23 Februar 2022, 17:43:41
Undank ist der Welten Lohn.  ;D

Ach du meine Güte, ich wollte darauf ja reagieren. Ist im beruflichen Trubel leider vergessen worden.
Angebot steht jederzeit. Allerdings in Wien ;)
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Prof. Dr. Peter Henning am 23 Februar 2022, 20:12:10
ZitatWenn das Zugeschlagen hätte, müßte aber eigentlich FHEM komplett abgeschmiert sein.
Nö, wie man an dem Log-Auszug sieht wurde da bisher analyzeAndRunCmd verwendet, das ist sicher gegen Abstürze.

ZitatGuter Workaround! Bedingt halt ein zusätzliches Devices.
Nö, kein Workaround, habe ich auch nicht. Der Trick ist, eine Liste für das Attribut zuzulassen. Das ist auch aus dem folgenden Grund sinnvoll.

ZitatUnd weil es einigermaßen naheliegend ist, dass Geräte, die für die Ausgabe verwendet werden, auch für die Eingabe tauglich sind, wird halt das herangezogen, was da ist
Nein, entschiedener Widerspruch. Beispielsweise lasse ich bestimmte Sprachausgaben eben nicht auf den Tablets machen, sondern (auch aus Gründen der Audioleistung!) auf einem Gerät meiner BOSE Soundtouch-Systeme. Und wenn der housemode (im YAAHM-Device) auf "donotdisturb" gestellt ist, wird die Ausgabe nur auf einem Display angezeigt.

ZitatAngebot steht jederzeit. Allerdings in Wien
Kein Problem. Ich habe als einen meiner Nebenjobs einen Lehrauftrag am Institut für Bildungswissenschaft der Universität Wien, war zuletzt im Oktober da und mag die Stadt sehr gern. Auch wenn ich den Lehrauftrag wahrscheinlich auslaufen lassen werde: Schon alleine für den Besuch unserer Lieblingspizzeria fahre ich mit meiner Frau gerne mal wieder 2000 km.

LG

pah
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 24 Februar 2022, 09:51:12
Zitat von: Prof. Dr. Peter Henning am 23 Februar 2022, 20:12:10
Nö, wie man an dem Log-Auszug sieht wurde da bisher analyzeAndRunCmd verwendet, das ist sicher gegen Abstürze.
Ich dachte an eine andere Stelle...

Zitat
Nein, entschiedener Widerspruch. Beispielsweise lasse ich bestimmte Sprachausgaben eben nicht auf den Tablets machen, sondern (auch aus Gründen der Audioleistung!) auf einem Gerät meiner BOSE Soundtouch-Systeme. Und wenn der housemode (im YAAHM-Device) auf "donotdisturb" gestellt ist, wird die Ausgabe nur auf einem Display angezeigt.
Vielleicht erst mal prinzipiell:
- Schritt 1 ist m.e. erst mal, einen "Pfad" durch das Dickicht zu bekommen. Den Code dann auszubauen, und z.B. zusätzliche Abfragen einzubauen ist dann ggf. nicht das große Problem.
- Der Rückgriff auf den Attributwert ist nach dem Code übrigens bereits jetzt der "Notnagel" ;) . Die Info, wohin gesprochen werden soll, kann zur Laufzeit auch pro siteId über ein Reading beeinflusst werden, siehe Ende der commandref (da fehlt nur der "experimental"-Hinweis).
- Die Frage der Aktivierung des voiceInputs ist nochmal spezieller, weil das wirklich nur auf passenden (FHEM-) Geräten geht, und da ist uU. die Auswertung des Readings in der Tat nicht zielführend (oder zumindest verwirrend)...

Klar: Vermutlich müssen wir die Bausteinchen noch weiter verfeinern und ggf. diese impliziten Zuordnungen von TTS- und STT-Angaben irgendwie anders benennen, sortieren, verattributieren usw.. Aber dazu muss m.E. erst mal die "Karte gezeichnet" und ein erster Pfad da sein.

Vielleicht kann in diesem Kontext auch der befehl "msg" weiterhelfen, müßte man klären oder entscheiden. Wobei das dann eher eine "personenbezogene Denke" ist, die nicht so recht zu der bisherigen ortsabhängigen Logik zu passen scheint.

Grüße, Beta-User
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 24 Februar 2022, 10:19:03
Zitat von: Prof. Dr. Peter Henning am 23 Februar 2022, 20:12:10
Kein Problem. Ich habe als einen meiner Nebenjobs einen Lehrauftrag am Institut für Bildungswissenschaft der Universität Wien, war zuletzt im Oktober da und mag die Stadt sehr gern. Auch wenn ich den Lehrauftrag wahrscheinlich auslaufen lassen werde: Schon alleine für den Besuch unserer Lieblingspizzeria fahre ich mit meiner Frau gerne mal wieder 2000 km.

Ja, das mit dem Lehrauftrag hab ich irgendwo mal gelesen. Wie gesagt, Angebot steht. Meld dich einfach, wenn du das nächste Mal da bist.
Welche Pizzeria ist denn das?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Prof. Dr. Peter Henning am 25 Februar 2022, 09:35:06
Ich teste derzeit die jüngste RHASSPY-Version parallel zu meinen eigenen Routinen. Daraus ergeben sich schon ein paar klare Erkenntnisse.

1. Das Abfangen der Wakeword-Erkennung in RHASSPY ist nicht zielführend. Es sollte vielmehr die Option bestehen, Wakeword-Events mit komplett eigenen FHEM-Kommandos zu belegen. Also die Events "detected", "toggleOn" und "toggleOff", und diese FHEM-Kommandos (die natürlich auch Perl-Kommandos sein dürfen) können auch den gesamten JSON-Payload als Parameter mitbekommen. Damit kann der FHEM-Nutzer dann selber entscheiden, was danach passiert. Lösungsvorschlag: in RHASSPY Attribute für die entsprechenden FHEM-Kommandos einführen. Bei meinen eigenen Routinen wird das in einem MQTT2_DEVICE umgesetzt durch
VoiceMQTT_Client:hermes/hotword/.*/detected:.* { rhasspyHotword($NAME,'hotword',$EVENT) }
VoiceMQTT_Client:hermes/hotword/toggleOn:.* { rhasspyHotword($NAME,'on',$EVENT) }
VoiceMQTT_Client:hermes/hotword/toggleOff:.* { rhasspyHotword($NAME,'off',$EVENT) }


2. Der direkte Aufruf von AMAD-Spracherkennung ist auch nicht zielführend. Schönes Anwendungsbeispiel: Wenn ich die AMAD-Spracherkennung auf meinen Devices im Wohnzimme starte, muss vorher die Audioanlage gemutet werden. Also sollte RHASSPY nicht selbst nach AMAD-Devices suchen, sondern einfach ein beliebiges (per Attribut konfigurierbares) FHEM-Kommando aufrufen. Das natürlich, wie oben, auch ein Perl-Kommando sein darf. Bei mir wird das unter anderem dafür genutzt, dasjenige Spracherkennungsdevice auszuwählen, das am nächsten an den Bewohnern dran ist. Auch hier könnte man den Payload aus Rhasspy weitergeben.

LG

pah
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 25 Februar 2022, 10:10:20
Hmm, irgendwie hatte ich bei den jüngsten Umbauten schon so ein Gefühl, dass das direkte Einschalten des voiceInput noch nicht der Weißheit letzter Schluss ist  ;D ....

Erste Anmerkungen:
- Das Verhalten kann man jetzt schon ausschalten, wenn man das siteId2ttsDevice_<siteId>-Reading für jedes bekannte AMAD-Device auf "0" setzt. Für Testzwecke würde ich das mal empfehlen, ansonsten wäre es auch nicht das große Problem, die Abfrage in #3045 erst mal tot zu stellen, bis wir wissen, ob das jemand braucht (ggf. einschaltbar über einen key in DEF?).

Zitat von: Prof. Dr. Peter Henning am 25 Februar 2022, 09:35:06
Es sollte vielmehr die Option bestehen, Wakeword-Events mit komplett eigenen FHEM-Kommandos zu belegen. Also die Events "detected", "toggleOn" und "toggleOff", und diese FHEM-Kommandos (die natürlich auch Perl-Kommandos sein dürfen) können auch den gesamten JSON-Payload als Parameter mitbekommen.
Auch das geht mit gewissen Einschränkungen heute schon:
- Es gibt siteId-spezifische hotword-Reading-Events für on/off. Soweit mir in Erinnerung, gibt es da kaum mehr an Info wie "welches hotword" und welche siteId. Stellt sich die Frage, inwieweit eine Doppelung Sinn macht oder ob da nicht einfach ein notify angeflanscht werden kann/soll? (Meine Sorge: Mehr Optionen = mehr Verwirrung für die User, aber nicht wirklich mehr Funktionalität).
- für "detected" gibt es ebenfalls bereits Funktionalität, allerdings "pro hotword". Die siteId findet sich bei einem Perl- oder FHEM-Kommando-Aufruf wie üblich in $ROOM, $VALUE müßte für das hotword stehen. Würde das schon reichen, oder braucht es wirklich mehr? Wenn ja: Ideen für die Erweiterung des "handleHotword"-Attributs?
(Den kompletten JSON weiterzugeben, ist zumindest vom ersten Bauchgefühl her unnötig kompliziert).
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 26 Februar 2022, 09:26:03
Im Rhasspy-Forum habe ich nochmals den Feature Request zur Erweiterung des Dialogmanagements nach oben geholt. Ich fürchte, dass die Bitten zur Umsetzung der deaktivierten Intents sowie des zusätzlichen Slot-Aufrufs in continueSession nicht in die Version 2.6 einfließen werden und so das Dialogmanagement weiterhin in einer rudimentären Fassung bleibt.  :(
Habt Ihr eine Idee, wie man das den Rhasspy-Leuten schmackhaft machen könnte?

Gruß Jens
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 27 Februar 2022, 10:05:28
Hallo zusammen,

habe eben eine aktualisierte dev-Fassung ins svn geschubst (@drhirn: wg. github). Doku ist noch geringfügig ergänzt, und ein Fehler beim Zusammenbau des NOITIFYDEV (hoffentlich) ausgemerzt (der sich aber nicht auf das list von pah neulich ausgewirkt hatte, von daher habe ich weiter keine Idee, warum das nicht "funktioniert" hatte).

Jetzt wollte ich selbst mal AMAD.* in Betrieb nehmen, aber die Ersteinrichtungsroutine auf automagic läuft nicht sauber durch (die Doku ist auch verbesserungsfähig...). Mal sehen, ob ich noch auf den Trichter komme, woran es hängt.

Zitat von: JensS am 26 Februar 2022, 09:26:03
Habt Ihr eine Idee, wie man das den Rhasspy-Leuten schmackhaft machen könnte?
Ich gehe davon aus, dass das bei den devs da so oder so auch auf der Liste steht; allerdings glaube ich nicht, dass die vorgeschlagene Lösung derjenigen entspricht, die am Ende Eingang in den Code findet. Das über den Namen zu machen würde jedenfalls mit gewaltig widerstreben, das fühlt sich  einfach wie ein workaround an...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 27 Februar 2022, 10:25:44
Zitat von: Beta-User am 27 Februar 2022, 10:05:28
Das über den Namen zu machen würde jedenfalls mit gewaltig widerstreben, das fühlt sich  einfach wie ein workaround an...

Das wäre (aus meiner derzeitigen Sicht) eine Lösung, welche Hermes-Konform ist und keine Änderung oder Erweiterung des Protokolls bedarf.
Die Anfrage nach deaktivierten Intents kam bereits von anderen Usern aber noch keine Lösung dazu.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Prof. Dr. Peter Henning am 27 Februar 2022, 10:48:11
ZitatStellt sich die Frage, inwieweit eine Doppelung Sinn macht oder ob da nicht einfach ein notify angeflanscht werden kann/soll? (Meine Sorge: Mehr Optionen = mehr Verwirrung für die User, aber nicht wirklich mehr Funktionalität).

Na ja, was denn nun? Nach meiner Auffassung ist das jetzt ein entscheidender Punkt in der Entwicklung des RHASSPY-Moduls.

- Soll es als alleinige Schnittstelle für die Ankopplung von FHEM an Rhasspy dienen? Wenn JA, muss es schon die Funktionalitäten bieten, die eine Anbindung sowohl "nach oben" (also z.B. an Spracherkennungsdevices wie AMAD-Geräte) als auch "nach unten" (also z.B. an Babble) komfortabel möglich machen. Der Preis dafür ist hoch, nämlich wie Du zu Recht geschrieben hast, erfordert das viel mehr Optionen und erzeugt mehr Verwirrung.

- Oder soll es der einfache Weg zur Ankopplung von FHEM an RHASSPY sein? Wenn JA, sollte der ganze Kram mit AMAD und Babble aus dem Modul heraufallen. Das vermeidet auch unnötige gegenseitige Abhängigkeiten.

Tertium non datur, und ich plädiere für den zweiten Weg. So habe ich das ja auch beim Shelly-Modul gemacht, und das hat sich als sehr erfolgversprechend herausgestellt: Schnell und direkt verwendbar. Wer die Shelly-Devices detaillierter ausnutzen (oder steuern) will, sollte sie über MQTT anbinden.

LG

pah
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 27 Februar 2022, 10:56:14
So, nachdem ich AMAD jetzt doch noch ans laufen gebracht habe, gibt es im SVN jetzt eine Version, bei der die Datenübergabe auch soweit erkennbar sauber durchläuft :) .
Da war die "allowed" Prüfung "verbogen" gewesen, sorry...

Zitat von: JensS am 27 Februar 2022, 10:25:44
Das wäre (aus meiner derzeitigen Sicht) eine Lösung, welche Hermes-Konform ist und keine Änderung oder Erweiterung des Protokolls bedarf.
Die Anfrage nach deaktivierten Intents kam bereits von anderen Usern aber noch keine Lösung dazu.
Es geht nicht (nur) darum, ob der Bedarf dafür besteht...

Ob es "hermes"-konform ist, ist dagegen m.E. nicht primär wichtig (wenn auch "wünschenswert", weil es dann wenigstens eine Doku dazu gibt).

Zitat von: Prof. Dr. Peter Henning am 27 Februar 2022, 10:48:11
Na ja, was denn nun?
...muss ich mal noch drüber nachdenken, jetzt ist erst mal der Schritt insoweit gemacht, dass sich über AMAD.*=> RHASSPY Lichter schalten lassen :) .

Jetzt bekomme ich halt über Telegram irgendwelchen  "Forwarded Message"s :o .
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 27 Februar 2022, 11:03:05
Zitat von: Prof. Dr. Peter Henning am 27 Februar 2022, 10:48:11
- Oder soll es der einfache Weg zur Ankopplung von FHEM an RHASSPY sein? Wenn JA, sollte der ganze Kram mit AMAD und Babble aus dem Modul heraufallen. Das vermeidet auch unnötige gegenseitige Abhängigkeiten.

Also wenn man mich fragt, wär das mein Weg. Weil, wo fängt das an und wo hört das auf? Man könnte unter Umständen zusätzliche Readings einbauen, die dann von wo anders abgerufen werden können. Aber alles andere wird viel zu kompliziert.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 27 Februar 2022, 11:40:15
Zitat von: Beta-User am 27 Februar 2022, 10:56:14
Ob es "hermes"-konform ist, ist dagegen m.E. nicht primär wichtig (wenn auch "wünschenswert", weil es dann wenigstens eine Doku dazu gibt).
Da die verschiedenen Module für ASR, etc. beliebig gewechselt werden können, sehe ich eine Konformität auf Protokoll-Ebene als zwingend an. Vielleicht ist die Notwendig der Entwicklung der Dialogfähigkeit aktuell nach hinten gestellt. Dabei sucht @synesthesiam gerade genau jetzt nach einer Lösung zur gleichzeitigen Nutzung von der klassischen Steuerung und des offenen Modus...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 28 Februar 2022, 13:44:13
Zitat von: Prof. Dr. Peter Henning am 27 Februar 2022, 10:48:11
Na ja, was denn nun?
Nach etwas Nachdenken, ist die Welt m.E. nicht ganz so "entweder oder". Meine Sichtweise:

- RHASSPY sollte _eingangsseitig_ die alleinige Schnittstelle für die Ankopplung von FHEM an Rhasspy sein.
Den MQTT2_CLIENT zusätzlich "anzuzapfen", um dieselben Topics auszuwerten, die auch RHASSPY entweder "sowieso" oder optional abhört, macht die Gesamtkonstruktion sehr viel unübersichtlicher und bietet keinen wirklichen Vorteil.
Ergo "muss" RHASSPY die eingehenden Infos "ähnlich" wie MQTT2_DEVICE in FHEM weitergeben können, einschl. des direkten Aufrufs von Perl-Code.
Bzgl. der Hotword-Geschichte bin ich zwar immer noch skeptisch, ob es wirklich die Weitergabe von "$EVENT" braucht, aber darauf kommt es dann auch nicht mehr an ;D .
Die in dieser Hinsicht noch verbleibende Flanke wäre "intentNotRecognized", aber das würde ich erst mal zurückstellen, da sind mir im Moment noch zu viele Variablen drumrum. Prinzipiell wäre es aber auch kein Ding, das z.B. in "Tweaks" mit zu erschlagen und dann halt "irgendein" Kommando mit den Daten zu füttern.

Zitat von: drhirn am 27 Februar 2022, 11:03:05
Also wenn man mich fragt, wär das mein Weg. Weil, wo fängt das an und wo hört das auf? Man könnte unter Umständen zusätzliche Readings einbauen, die dann von wo anders abgerufen werden können. Aber alles andere wird viel zu kompliziert.
Damit ist m.E. das "Pflichtprogramm" umrissen und es ist auch nicht allzu kompliziert im Modul zu verorten und auch nicht in der Erklärung für die User.

Entsprechender Code ist in der Vorbereitung, ich will aber zuerst selbst noch testen, wird etwas dauern.

ZitatWenn JA, muss es schon die Funktionalitäten bieten, die eine Anbindung sowohl "nach oben" (also z.B. an Spracherkennungsdevices wie AMAD-Geräte)
Den Teil hoffe ich in dem Zuge auch vollends erledigen zu können. Prinzipiell bin ich mit den "textorientierten Eingabemethoden" im Zusammenwirken mit RHASSPY/Rhasspy zufrieden, das erweitert die Möglichkeiten doch sehr, und es gibt im Prinzip auch nur zwei Methoden, die (demnächst) beide implementiert sind, nämlich "one-shot"-Verfahren (so ist AMAD.* (mit und ohne Babble) grade konzipiert) und "Kennwort + (FHEM-interner) Dialog bleibt eine zeitlang offen" (ala msgDialog). Falls da also (neben der sowieso generischen (!) Schnittstelle msgConfig) noch was käme, sollte es nicht allzu schwierig sein, das noch zusätzlich einzubauen.

Zitatals auch "nach unten" (also z.B. an Babble)
Was die Ausgangsseite angeht: Eine "nahtlose" Integration ist zwar wünschenswert, allerdings stellt sich in der Tat die Frage, wie das ganze sinnvoll gegeneinander abzugrenzen sein soll, und wie der interne Datenfluss sein müßte.
Die Abgrenzung über "Sage mycroft" ist jedenfalls mal ein erster Ansatz, auch wenn das irgendwie noch nicht "schön" ist. Mittelfristig könnte man das z.B. erweitern oder ergänzen um ein Reading (rhasspy2babble_.*), anhand dem (zusätzlich? als override?) eingestellt werden kann, ob Rhasspy eventuellen Input bekommen soll oder (z.B.) Babble. Dann kann der User @runtime (z.B. anhand des wakewords?) entscheiden, wohin eine Info soll...

Letztlich wird es auf dieser Seite der Strecke immer so sein, dass persönliche Vorlieben und ggf. historisch gewachsene Strukturen berücksichtigt werden müssen, und zumindest nach meinem jetzigen Kenntnisstand eben jede Lösung ihre Stärken hat.

Da der Weg m.E. nicht mehr allzuweit ist, um das zumindest für Babble auch noch hinzubekommen (und das auch nicht allzu spezifisch ist), würde ich gerne versuchen wollen, das vollends soweit zum Laufen zu bekommen, dass man sich Gedanken darüber machen kann, ob das "zu kompliziert" ist, oder ob sich das insgesamt gut integriert anfühlt (bzw. unter welchen weiteren Voraussetzungen und mit welchen weiteren Ergänzungen).

Zitat von: JensS am 27 Februar 2022, 11:40:15
Da die verschiedenen Module für ASR, etc. beliebig gewechselt werden können, sehe ich eine Konformität auf Protokoll-Ebene als zwingend an.
Wir reden vermutlich aneinander vorbei: Rhasspy-intern ist es zwingend, dass die verschiedenen Module dasselbe Verständnis vom verwendeten Protokoll haben. Was aber nicht heißt, dass das "hermes-pur" oder "hermes-original" sein muss. Man kann das weiterentwickeln oder neue/andere Konventionen festlegen. Zu vermeiden ist aber Verwirrung, also alte Syntax, neue Bedeutung.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Prof. Dr. Peter Henning am 28 Februar 2022, 19:31:17
In dieser Woche habe ich noch etwas Zeit zu Testen. Nächste Woche bin ich zum Golfen in Südfrankreich, falls die Welt bis dahin noch steht.

LG

pah
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 28 Februar 2022, 20:15:03
...na dann, bevor die Welt vollends untergeht: habe eben die nur ganz kurz angetestete Fassung ins svn geschubst, damit auch die Änderungen leichter auszumachen sind: https://svn.fhem.de/trac/changeset/25757/

Betr. "hotword" sollte die commandref ausreichend aufschlussreich sein, ansonsten hoffe ich mal dass man jetzt auch eine Antwort bekommt, wenn Aktionen per AMAD.* angeschubst wurden.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 01 März 2022, 10:36:22
Hallo zusammen,

kurz die Fassung von gestern (im svn) angetestet und festgestellt, dass die Antwort immer noch an die falsche Adresse geht :-[ .

Jetzt habe ich mir diesen Teil des Pfades auch nochmal etwas intensiver (theoretisch) angesehen und glaube auch, noch einige Ungereimtheiten gefunden zu haben, die mit zu großen Parallelitäten zum msgDialog-Pfad zu tun hatten. Weiß noch nicht, ob das alles war, aber Schritt für Schritt sollten wir uns dem Ziel nähern...

Es gibt jetzt auch ein Reading "rhasspy_dialogue" am "Startdevice" für STT/TTS (typischweise: AMADDevice), anhand dem man erkennen kann, ob RHASSPY erwartet, dass die Sitzung fortgesetzt werden soll, z.B. weil es eine Rückfrage gab und nach der Sprachausgabe (deren Dauer RHASSPY nicht kennt) das Mikro wieder eingeschaltet werden sollte. Kann sein, dass es mittelfristig elegantere Lösungen gibt, aber auf die Schnelle ist mir erst mal nichts besseres eingefallen ::) .
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 02 März 2022, 13:36:54
Zitat von: Beta-User am 01 März 2022, 10:36:22
Weiß noch nicht, ob das alles war, aber Schritt für Schritt sollten wir uns dem Ziel nähern...
...es war noch nicht alles, mind. eine entscheidende Stelle hatte ich übersehen, bei der der Code in Richtung msg-System statt TTS "abgebogen" war...

Groß zum Testen komme ich aber derzeit nicht.

EDIT: aber wenigstens klein getestet: Jetzt gibt es eine Sprachausgabe 8) - allerdings ist das ganze gefühlt bei der Ausgabe sehr viel langsamer als Rhasspy direkt.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 03 März 2022, 11:19:35
Fyi: die aktuellste Fassung findet sich jetzt wieder im svn, relevant ist das erst mal v.a. für Mittester an dem "AMAD-feature", außerdem ist die Version ggf. für die interessant, die irgendwas spezielleres rund um "wakeword" realisieren wollen* (siehe commandref).

Wie gestern abend bereits mitgeteilt, funktioniert jetzt auch die Sprachausgabe der $response via AMADDevice, was in etwa so viel bedeutet wie: Der "Pfad" ist bekannt, jetzt geht es um's "aufräumen" und ausbauen.

Noch ungetestet sind folgende Aspekte:
- (*) wakeword - spezielle Aktionen, Parameterübergabe usw.
- Verhalten bei Rückfragen/Bestätigungen (das betrifft im Übrigen auch den msgDialog-Teil). Mit etwas Glück funktioniert das, aber auch der Teil muss jeweils noch getestet werden, wobei bei der "voice"-Variante (AMAD) hinzukommt, dass man den voiceInput ja auch wieder aktivieren muss (im Moment muss man das per Eventhandler selber organisieren**)

Was das "aufräumen" angeht, ist im Moment noch das Attribut rhasspyTTS erforderlich, um den Rückweg zu organisieren, aber "eigentlich" müßte es möglich sein, (für eine "default-Verwendung") praktisch alles automatisch einzurichten, wenn der User eine schlicht und einfach angibt, welche AMADDevice-Instanz(en) als "Text-to-Rhasspy"-Input genutzt werden dürfen.

Abweichungen zum "default" könnte man dann (hoffentlich zwanglos) einfach in der "üblichen key=value-Schreibweise" in einer Zeile unterbringen, die mit dem Schlüssel des Namens der Gegenstelle beginnt...? Da könnte man auch eine wakeword=>Input-Device-Zuordnung machen?

Hmm, mal schauen...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 05 März 2022, 11:34:53
Hallo zusammen,

habe eben im svn eine Fassung eingecheckt, die das hier umsetzt:
Was das "aufräumen" angeht, ist im Moment noch das Attribut rhasspyTTS erforderlich, um den Rückweg zu organisieren, aber "eigentlich" müßte es möglich sein, (für eine "default-Verwendung") praktisch alles automatisch einzurichten, wenn der User eine schlicht und einfach angibt, welche AMADDevice-Instanz(en) als "Text-to-Rhasspy"-Input genutzt werden dürfen.

Man muss nur noch den "allowed"-Key in rhasspySTT (auf ein/mehrere vorhandene/s AMADDevice/s) setzen, dann weiß RHASSPY, dass auf Events in den zugehörigen AMADCommBridge zu hören ist. Damit ist es prinzipiell relativ einfach einzurichten, den voiceInput muss man halt noch "selbst"  aktivieren (kann sein, dass das auch recht einfach geht, wenn man das passende wakeword angibt, ist an der Stelle noch ungetestet).

Vermutlich bekommt das Attribut dann noch einen anderen Namen, da es funktional jetzt bidirektional ist.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Prof. Dr. Peter Henning am 05 März 2022, 19:49:45
OK, Bericht zur aktuellen Version aus dem SVN.

Erste Angelegenheit:

1. Wenn ich aus FHEM ein textCommand absende, z.B. "schalte den nichtstoerenmodus an" => prima, wird in Rhasspy in den Intent übersetzt, zurück an RHASSPY gesendet und ausgeführt.
2. Wenn ich aus der App ein Kommando absende, z.B. "schalte den nichtstoerenmodus an" => prima, wird in Rhasspy in den Intent übersetzt, zurück an RHASSPY gesendet und ausgeführt.
3. Wenn ich aus der App das Kommando absetze "wie spaet ist es" (bewusst mit ae, so ist der Intent definiert), wird der Intent erkannt und - weil als TTS-Device in Rhasspy ein MQTT-Server eingetragen ist - die Sprachausgabe wieder in einer anderen Ecke von FHEM gemacht. => prima, passt auch
2. Wenn ich aber als textCommand in RHASSPY absetze "wie spaet ist es", kommt in RHASSPY

- manchmal die Fehlermeldung "read from http://192.168.0.115:12101 timed out" und gar nichts an bei RHASSPY
- manchmal geht es durch zu RHASSPY:
[DEBUG:2022-03-05 19:39:36,769] rhasspyserver_hermes: Sent 362 char(s) to websocket
[DEBUG:2022-03-05 19:39:36,765] rhasspyserver_hermes: <- NluIntent(input='wie spaet ist es', intent=Intent(intent_name='de.fhem:GetTime', confidence_score=1.0), site_id='default', id=None, slots=[], session_id='fhem.textCommand', custom_data=None, asr_tokens=[[AsrToken(value='wie', confidence=1.0, range_start=0, range_end=3, time=None), AsrToken(value='spaet', confidence=1.0, range_start=4, range_end=9, time=None), AsrToken(value='ist', confidence=1.0, range_start=10, range_end=13, time=None), AsrToken(value='es', confidence=1.0, range_start=14, range_end=16, time=None)]], asr_confidence=None, raw_input='wie spaet ist es', wakeword_id=None, lang=None)


Aber ohne dass eine Ausgabe erfolgt. Das RHASSPY-Modul sollte aber - wie unter Punkt 3 - ein TTS-Kommando an Rhasspy senden, das dann auch ausgeführt wird. Macht es aber nicht, oder nicht korrekt. Wohlgemerkt, das "speak"-Kommandu in RHASSPY funktioniert korrekt.

Zweite Angelegenheit:
Das Handling von Umlauten ist kryptisch. Mein Android-Device mit der App sendet utf8 - "ä" wird als "ä" erkannt. FHEM sendet bei mir eine andere Codierung, das textCommand "wie spät ist es" wird also nicht korrekt erkannt. Das sollte irgendwo in der language-Datei abgefangen werden, eine Dokumentation dazu habe ich aber nicht gefunden.

LG

pah
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 06 März 2022, 08:54:38
Zum Verständnis: "App"=AutoMagic, nicht die Rhasspy-App?
In global ist das "encoding-Attribut" nicht gesetzt?

Mein AMAD-Androide beantwortet "wie spät ist es" ordnungsgemäß (aber spät).

Das encoding der languageFile legt der User fest, die wird nur eingelesen "as is" (so jedenfalls mein Verständnis dessen, was Rudi dazu in Development gesagt hat).

Soviel in der Kurzversion, den Rest muss ich mir in Ruhe anschauen.

Viel Spaß beim Golfen! (hoffe, das kann stattfinden!!!)
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Prof. Dr. Peter Henning am 06 März 2022, 09:33:07
ZitatZum Verständnis: "App"=AutoMagic, nicht die Rhasspy-App?
ZitatDoch, Rhasspy-App ist gemeint.

In global ist das "encoding-Attribut" nicht gesetzt?
Das halte ich für irrelevant, weil entsprechende Befehle auch von anderen Systemen in meinem Haus kommen können. Müsste m.E. von RHASSPY abgefangen werden.

LG

pah
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 06 März 2022, 09:47:08
Zitat von: Prof. Dr. Peter Henning am 06 März 2022, 09:33:07
Das halte ich für irrelevant, weil entsprechende Befehle auch von anderen Systemen in meinem Haus kommen können. Müsste m.E. von RHASSPY abgefangen werden.
Im Prinzip schon klar, wobei es uU. eben auch ein Thema ist, dass diese "anderen Systeme" "ordentliche " Daten abliefern. Bei der Frage ging es erst mal darum, rauszufinden, ob es im "noch-default" Probleme gibt, oder das ganze schon verkompliziert ist...

"wie spät ist es" funktioniert bei mir auch mit der R-App.

textCommand ist eigentlich gar nicht für die Sprachausgabe gedacht, die Antwort kommt nicht-triggernd in textResponse. Dazu müßte man sich den flow nochmal ansehen, auch im Hinblick darauf, was man ggf. an Infos mitgeben muss, damit klar ist, wo dann eigentlich eine Reaktion erwartet wird.

Da du von TTS sprichst: in der aktuellsten Version gibt es dieses Attribut m.E. gar nicht mehr. (0.5.19)
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Prof. Dr. Peter Henning am 06 März 2022, 18:30:26
Nutze ich ja auch nicht, weil der MQTT-Server dafür in Rhasspy definiert ist.

Du hattest allerdings gesagt, Du wolltest RHASSPY zur alleinigen Schnittstelle zu Rhasspy machen - dann muss auch (wie aus der Rhasspy-App) die Möglichkeit bestehen, einen Text als Befehl an Rhasspy zu senden.

LG

pah
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 06 März 2022, 19:12:43
Imo ist diese App wie ein normaler Satellit zu behandeln und hat mit der Schnittstellendiskussion bezgl. FHEM nicht direkt was zu tun. Gehört für mich zur Rhasspy-Sphäre, RHASSPY kann nicht unterscheiden, welche Art Satellit das ist.
Für einen ESP-basierten Satelliten gilt btw. dasselbe.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 07 März 2022, 09:23:00
Zitat von: Prof. Dr. Peter Henning am 05 März 2022, 19:49:45
2. Wenn ich aber als textCommand in RHASSPY absetze "wie spaet ist es", kommt in RHASSPY

- manchmal die Fehlermeldung "read from http://192.168.0.115:12101 timed out" und gar nichts an bei RHASSPY
- manchmal geht es durch zu RHASSPY:
[DEBUG:2022-03-05 19:39:36,769] rhasspyserver_hermes: Sent 362 char(s) to websocket
[DEBUG:2022-03-05 19:39:36,765] rhasspyserver_hermes: <- NluIntent(input='wie spaet ist es', intent=Intent(intent_name='de.fhem:GetTime', confidence_score=1.0), site_id='default', id=None, slots=[], session_id='fhem.textCommand', custom_data=None, asr_tokens=[[AsrToken(value='wie', confidence=1.0, range_start=0, range_end=3, time=None), AsrToken(value='spaet', confidence=1.0, range_start=4, range_end=9, time=None), AsrToken(value='ist', confidence=1.0, range_start=10, range_end=13, time=None), AsrToken(value='es', confidence=1.0, range_start=14, range_end=16, time=None)]], asr_confidence=None, raw_input='wie spaet ist es', wakeword_id=None, lang=None)


Habe ich hier einen Umbau beim textCommand von MQTT zu Websocket verpasst?
Wie bereits erwähnt, sollte man bei einer Übertragungsart (MQTT) bleiben und die Nutzung des Rhasspy-Webinterfaces (Websocket) tunlichst vermeiden.

Gruß Jens
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 07 März 2022, 12:52:08
Es gab keinen Umbau in Richtung websocket.
Im Code ist noch zu erkennen, dass ganz früher mal ein anderer Topic benutzt worden ist, um einen "fake command" abzusetzen.
Das ist aber "schon ewig", das das an nlu/query geht.

Gestern scheine ich vor lauter "App" und "andere App" etwas auf dem Schlauch gestanden zu haben:
Zitat von: Prof. Dr. Peter Henning am 06 März 2022, 18:30:26
dann muss auch (wie aus der Rhasspy-App) die Möglichkeit bestehen, einen Text als Befehl an Rhasspy zu senden.
Prinzipiell funktioniert das auch. Im Moment kann ich folgende Problemkreise erkennen:
- verwendet man den textCommand-Befehl an RHASSPY selbst, ist der "anonym", fhem/RHASSPY kann allenfalls anhand der sessionId erkennen, dass die Anfrage eine eigene ist. Die Zuordung einer Antwort zu irgendeiner Stelle in FHEM ist nicht vorgesehen und so auch nicht ohne weiteres möglich.
- Die "veranlassende Stelle" kann aber die "textResponse" abgreifen - vorausgesetzt, RHASSPY erzeugt ein Event an sich. Da war eine (vermutete) Lücke, die m.E. am effektivsten geschlossen wird, indem man ans Ende von sub response() das return auf return $hash->{NAME} aufbohrt. (Kommt bei nächster Gelegenheit). Hatte uU. Auswirkungen bei "devicelosen" Intents wie "GetTime".

- prinzipiell schwierig wird es, wenn eine Rückfrage zu beantworten wäre (Welches Device oder eine Bestätigung). Hab's nicht geprüft, aber Zweifel, ob das klappt bzw. überhaupt klappen kann.

- Besser wird die Situation mit den beiden jetzt etablierten Wegen, den Text-Input bei "Personen" (msgDialog/RESIDENTS/pushMsgReceived) bzw. "Hardware-Instanzen" (AMAD.*) abzugreifen. Da ist es "relativ einfach", den Rückweg zu ermitteln und auch temporär benötigte Daten vorzuhalten (weiß aber im Moment noch nicht, ob das überall wirklich klappt).

Prinzipiell müßte es auch möglich sein,
- z.B. den RESIDENTS-Ansatz auf andere (Text-) Input-Optionen aufzuweiten, falls dafür Bedarf bestehen sollte;
- bei textCommand (o.ä) eine "respond_command"-Info mitzugeben, allerdings wäre dann gleich die Anschlussfrage, wie das dann umzusetzen wäre; technisch würde man wohl das komplette (FHEM/Perl-) Kommando benötigen.

NACHTRAG noch:
Ein spezielles Thema sind "not recognized"-Rückmeldungen von Rhasspy. Im Moment werden die (in der Regel) einfach ignoriert. Hatte man eine Text-Message reingegeben, wäre vermutlich eine Rückmeldung hilfreich, dass eben die Message nicht verwertet werden konnte. Muss mal bei Gelegenheit schauen, ob/was man da was aus dem MQTT-Verkehr an Infos in RHASSPY darstellen kann/sollte.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: chicco am 08 März 2022, 05:46:39
Hallo zusammen,

bisher bin ich noch mit Snips unterwegs, wollte jetzt aber mal rhasspy probieren (weil ich bald umziehe und in der neuen Wohnung brauche in Satelliten, das wird schwierig mit Snips).
Bin laut der Schnellstart-Anleitung vorgegangen, aber ich scheiter am define des rhasspy-device.

Nach Eingabe von
defmod rhasspy RHASSPY baseUrl=http://192.168.0.128:12101
bekomme ich die Antwort: Cannot load module RHASSPY

Im Log steht:
2022.03.08 05:10:58 1: reload: Error:Modul 10_RHASSPY deactivated:
Can't locate FHEM/Core/Timer/Register.pm in @INC (you may need to install the FHEM::Core::Timer::Register module) (@INC contains: ./lib ./FHEM . /etc/perl /usr/local/lib/arm-linux-gnueabihf/perl/5.28.1 /usr/local/share/perl/5.28.1 /usr/lib/arm-linux-gnueabihf/perl5/5.28 /usr/share/perl5 /usr/lib/arm-linux-gnueabihf/perl/5.28 /usr/share/perl/5.28 /usr/local/lib/site_perl /usr/lib/arm-linux-gnueabihf/perl-base ./FHEM/lib) at ./FHEM/10_RHASSPY.pm line 46.
BEGIN failed--compilation aborted at ./FHEM/10_RHASSPY.pm line 46.


Hab den Fehler gegoogelt, aber nix brauchbares gefunden.
Was kann ich machen?

Gruß
chicco
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 08 März 2022, 07:48:11
Dann mal willkommen in der RHASSPY-Welt!

Dein FHEM ist "zu alt". RHASSPY setzt grundsätzlich ein ziemlich aktuelles FHEM voraus (aktuell: <ca. 3 Wochen), von daher kannst du froh sein, dass es so alt ist, dass diese lib (noch) nicht vorhanden ist, die wird seit längerem mit FHEM "geliefert".

Nach einem update sollte es klappen.

Nachtrag noch: Falls du als "prefix" "snips" wählst, könnte es sein, dass RHASSPY die betreffenden Attribute auch direkt mit auswertet. Wenn ich das aus den Augenwinkeln richtig erfasst habe, sollte die (Attribut-) Syntax häufig kompatibel sein von "snips" nach "RHASSPY@MQTT-classic" bis hin zu jetzt RHASSPY heute.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: chicco am 08 März 2022, 21:56:05
Danke für die schnelle Antwort.

Mein fhem war in der Tat schon länger nicht mehr geupdatet.
-> update gemacht, lief sauber durch
-> fhem neu gestartet

Wenn ich jetzt das rhasspy-device anlegen will, schmiert fhem ab, oben links kommt "connection lost, trying reconnect..."
Nach ca. 90 Sek. ist fhem wieder erreichbar.
Das rhasspy-device ist dann nicht vorhanden.

Im Log finde ich diesen Eintrag:
Can't use string ("en") as a HASH ref while "strict refs" in use at ./FHEM/10_RHASSPY.pm line 3462.
Statt "en" steht da manchmal auch "en_US"

Wenn ich die angegebene baseUrl im Browser aufrufe, sehe ich das rhasspy-web-interface.
Attribut language vom global-device steht auf "DE"
Den docker-container habe ich gestartet mit "profile en" (aus der Schnellstart-Anleitung abgeschrieben)

Netter Hinweis mit dem prefix, aber soweit bin noch nicht :-(
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 08 März 2022, 22:40:43
Zitat von: chicco am 08 März 2022, 21:56:05
Attribut language vom global-device steht auf "DE"
Den docker-container habe ich gestartet mit "profile en" (aus der Schnellstart-Anleitung abgeschrieben)
rhasspy -p de

Gruß Jens
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: chicco am 09 März 2022, 03:52:48
@Jens:
ich nehme an, du wolltest mir mit deinem Schnipsel sagen, dass ich den rhasspy-docker-container mit einem deutschen Profil starten soll.
Mich irritiert der Parameter -p, beim docker run Befehl werden damit doch die Ports angegeben.

Ich habe den rhasspy-docker-container jetzt mit "--profile de" gestartet. Wenn ich dann in fhem das rhasspy-device erstellen will, kommt der gleiche Fehler, nur mit "de" in der Fehlermeldung:
Can't use string ("de") as a HASH ref while "strict refs" in use at ./FHEM/10_RHASSPY.pm line 3462.

Ich habe das hier gefunden:
https://forum.fhem.de/index.php?topic=97159.0
Die Fehlermeldung dort klingt ähnlich und es geht um MQTT2 (was ja bei rhasspy auch verwendet wird). Dort wird die Perl-Version diskutiert, ich habe hier v5.28.1
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 09 März 2022, 04:48:59
Hmmm, habe Schwierigkeiten, diese Fehlermeldung mit https://svn.fhem.de/trac/browser/trunk/fhem/contrib/RHASSPY/10_RHASSPY.pm#L3462 (https://svn.fhem.de/trac/browser/trunk/fhem/contrib/RHASSPY/10_RHASSPY.pm#L3462) (rev. 25778) in Verbindung zu bringen.

Bitte die aktuellste Version verwenden (sollte so zu bekommen sein: { Svn_GetFile("contrib/RHASSPY/10_RHASSPY.pm", "FHEM/10_RHASSPY.pm") }), und bei solchen Dingen dann bitte auch angeben, mit welcher DEF du es versucht hattest. Bei mir läuft es jedenfalls seit langem ohne ausdrückliche Angabe einer  language in der DEF von RHASSPY.

Für das define des Moduls ist es auch erst mal unwichtig, ob überhaupt ein Rhasspy läuft und wie dessen Spracheinstellungen sind...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: chicco am 09 März 2022, 06:24:39
Zitat von: Beta-User am 09 März 2022, 04:48:59
Hmmm, habe Schwierigkeiten, diese Fehlermeldung mit https://svn.fhem.de/trac/browser/trunk/fhem/contrib/RHASSPY/10_RHASSPY.pm#L3462 (https://svn.fhem.de/trac/browser/trunk/fhem/contrib/RHASSPY/10_RHASSPY.pm#L3462) (rev. 25778) in Verbindung zu bringen.
Ich habe ebenfalls rev. 25778

Zitat von: Beta-User am 09 März 2022, 04:48:59
Bitte die aktuellste Version verwenden (sollte so zu bekommen sein: { Svn_GetFile("contrib/RHASSPY/10_RHASSPY.pm", "FHEM/10_RHASSPY.pm") })
Der gleiche Befehl steht so auch im Wiki, den habe ich vorgestern so ausgeführt und gestern nach dem fhem-Update dann nochmal.

Zitat von: Beta-User am 09 März 2022, 04:48:59
und bei solchen Dingen dann bitte auch angeben, mit welcher DEF du es versucht hattest. Bei mir läuft es jedenfalls seit langem ohne ausdrückliche Angabe einer  language in der DEF von RHASSPY.

Jetzt wollte ich eben die DEF für dich raussuchen und habe es nochmal probiert und es hat geklappt  ???
Unterschied zu vorher: jetzt grade läuft der raspi mit dem Docker-Container nicht!

Nochmal von vorne:
Ich habe einen pi4, darauf läuft fhem.
Ich habe einen pi3, mit Mikro und Lautsprecher, darauf läuft snips.

Um jetzt rhasspy zu testen habe ich eine andere SD-Karte genommen, darauf ist ein frisches bullseye gebrannt. Damit dann den pi3 gebootet, docker installiert, und per "docker run..." das rhasspy image gezogen und gestartet.

Mit dieser DEF habe ich es versucht:
defmod rhasspy RHASSPY baseUrl=http://192.168.0.128:12101
192.168.0.128 ist der pi3

Wenn der pi3 mit der rhasspy-sd-Karte läuft, bekomme ich den Fehler.
Wenn der pi3 mit der snips-sd-Karte läuft oder ausgeschaltet ist, bekomme ich keinen Fehler und das rhasspy-device wird erstellt.

Wenn das device erstellt wird, kommt natürlich ein Fehler im STATE:
192.168.0.128: Keine Route zum Zielrechner (113) -> wenn der pi3 ausgeschaltet ist
192.168.0.128: Verbindungsaufbau abgelehnt (111) -> wenn der pi3 mit der snips-sd-Karte läuft
Die STATE-Fehler können wir hier natürlich ignorieren, denn wenn der pi3 nicht läuft bzw. wenn snips darauf läuft, kann da natürlich kein rhasspy antworten.

Ich denke ich mache jetzt so weiter:
pi3 ausschalten, device erstellen, pi3 booten und dann weiter nach Anleitung...
Müsste funktionieren, oder?

Vielleicht hilft euch meine Fehlerbeschreibung bei der Fehlersuche, hier ist es auf jeden Fall reproduzierbar.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 09 März 2022, 07:19:26
Ich tippe mal darauf, dass keine Satelliten definiert sind.
Bei der Suche nach satellite_site_ids wird das ganze JSON durchsucht und bei language: "de" streikt Perl, weil es sich um einen String handelt.
In meinem Vorschlag zu fetchSiteIds hatte ich bewusst $ref->{'dialogue'}{'satellite_site_ids'});geschrieben, da die SiteIds des Dialogmanagers verwendet werden sollten und nicht die SiteIds anderer Module (wakeword, etc.).

Gruß Jens
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 09 März 2022, 07:36:04
Zitat von: JensS am 09 März 2022, 07:19:26
Ich tippe mal darauf, dass keine Satelliten definiert sind.
Bei der Suche nach satellite_site_ids wird das ganze JSON durchsucht und bei language: "de" streikt Perl, weil es sich um einen String handelt.
In meinem Vorschlag zu fetchSiteIds hatte ich bewusst $ref->{'dialogue'}{'satellite_site_ids'});geschrieben, da die SiteIds des Dialogmanagers verwendet werden sollten und nicht die SiteIds anderer Module (wakeword, etc.).
Das sieht mir eher so aus, als hätte sich irgendwas an der Antwort an sich geändert, und @chicco ist einfach der erste, der einen aktualisierten container getestet hat. Jedenfalls würde  diese Beschränkung den Absturz m.E. auch nicht verhindern.
Die Hereinnahme weiterer möglicher siteId's mag man kritisch sehen, hat aber eigentlich kaum eine praktische Relevanz.

Bitte das aktuelle update aus dem svn holen, das sollte das beheben (und @pah: auch immer triggern, wenn es eine "devicelose" Anwort gibt).
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 09 März 2022, 17:34:05
Nun will ich nicht die Laune verderben aber es handelt sich um eine Frage des Datentyps.  ;)
!defined $ref->{$_}{satellite_site_ids};fragt nach einen Subkey {'satellite_site_ids'}.
Wenn der Hauptkey {'language'} an der Reihe ist, crasht die Abfrage, da es dort keine Subkeys gibt und der String-Value "de" die Frage nach einem Key nicht versteht.

Die Abfrage auf den Key {'dialogue'} zu beschränken, macht insofern Sinn, da im Dialog von Rhasspy nur die Satelliten verarbeitet werden, welche dort aufgeführt sind.

Gruß Jens
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 09 März 2022, 19:39:53
Wie dem auch sei, mit der aktuellen svn-Version sollte es dieses Problem nicht mehr geben...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: chicco am 09 März 2022, 20:10:10
Ich habe die aktuelle Version mit Svn_GetFile() geholt, habe es nochmal probiert und hatte wieder einen crash.
Als fhem nach dem crash neu gestartet war, habe ich es nochmal versucht, dann hat es geklappt, rhasspy device ist erstellt und state ist online.
Ich nehme an, man muss fhem neu starten nachdem man Svn_GetFile() ausgeführt hat? Dann würde sich der crash beim ersten Versuch erklären.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 09 März 2022, 22:21:46
Na ja, ohne (wenigstens) einen reload kein aktueller code im Speicher...
Aber klappt ja jetzt...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 10 März 2022, 22:12:20
next if ref $ref->{$_} ne 'HASH'...hast ein wenig getrickst um die Klippe zu umschiffen.  ;)
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 19 März 2022, 07:05:27
Hallo zusammen,

auf Anregung von pah gibt es im svn ein kleines update.

Das kann eine Liste von Sätzen oder einen einzelnen Satz (via jeweiligem Get) an Rhasspy senden und  schreibt dann die Ergebnisse in eine Ergebnisdatei. Finde das ganz interessant, weil man damit relativ schnell und im Überblick sehen kann, wo ggf. noch Verbesserungspotential bei der Konfiguration der sentences.ini bzw. der RHASSPY-Attribute in einer Installation besteht.

Zitat von: Beta-User am 18 März 2022, 11:26:08
[...], sollte
- die Ergebnisfile nur noch da Rückmeldungen enthalten, wo ein Ergebnis kam;
- auch die Auswertung für diverse "Abfragen" in den Ergebnissen enthalten sein (für die ganzen "setter" wäre es ggf. sehr viel schwieriger!);
- ein neues Reading etwas mehr Aufschluss geben, was die "ratio" betrifft und wo das ganze zu finden ist.
Muss mal noch schauen, ob es sehr aufwändig wäre, das so aufzubohren, dass man auch die Rückmeldungen auf "Set"-Anweisungen rückgemeldet bekommt, aber Rom und so...

Jetzt warte ich auch mal auf eure Rückmeldungen zum Thema.

Fehlen noch weitere "Testsätze" - pah's Muster ist etwas anders gestrickt als meine Steuerungsanforderungen, von daher war auch die erste Sätze insgesamt / Treffer - "ratio" nicht allzu prickelnd ::) .
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Prof. Dr. Peter Henning am 19 März 2022, 15:54:07
Zitatpah's Muster ist etwas anders gestrickt als meine Steuerungsanforderungen
na fein, dann lass doch mal Deine Anforderungen sehen - ich bau sie gerne auch in meine Tests ein.

LG

pah
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 20 März 2022, 11:29:27
Gemach, eins nach dem anderen...

Vorab mal: Das mit den Tests ist klasse, damit kann man recht fix rausfinden, was RHASSPY jeweils angeliefert bekommt, und selbst da, wo es keine "unmittelbare" Info gibt, wie das ausgewertet wurde, kann man in etwa erahnen, was an Steuerungsbefehlen dann abgeleitet wird. War eine schöne Gelegenheit, meine sentences.ini weiter zu optimieren :) .

Weiter auch ein Anlass, das mit den erweiterten GetState-Optionen mal auszutesten - leider nur in Teilen erfolgreich ::) .

Hier mal ein paar weitere Sätze:
  mach alle jalousien im esszimmer zu
  mach alle jalousien im wohnzimmer halb auf
  fahr die jalousie in der mitte halb zu

  wie warm ist es draussen
 
  färbe die stehlampe links rot
  stelle die stehlampe rechts auf blau
 
  mach überall die rollläden auf fünfzig
  mach alle lichter im wohnzimmer heller
  mach alle leuchten im wohnzimmer dunkler
 
  mach lauter
  mach die musik leiser
 
  halte die wiedergabe an
  halte die musikwiedergabe an
 
  wie wird das wetter heute
  was kostet diesel in Karlsruhe


Würde vorschlagen, dass wir für diesen Teil einen separaten Thread starten? Hier kann es gerne darum gehen, ob/wie man das Tool erweitern kann (die Set-Zweige im Code auch noch für Tests ergänzen?) und ggf. wie die Rückmeldungen verbessert werden könnten (HASH-Fälle => Klartext kommt bei Gelegenheit), aber m.E. ist das eine Super-Sache, um die Interaktion zu analysieren und dann zu diskutieren, an welcher Stelle man ggf. sinnvollerweise Anpassungen vornimmt und was eigentlich in welchen Intent rein sollte (Wetter-Abfrage ist bei mir jetzt ein GetState).
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Prof. Dr. Peter Henning am 20 März 2022, 12:12:21
Machen wir doch glatt:

https://forum.fhem.de/index.php/topic,126864.0.html

zum Thema testen.

Zu Deinen Sätzen ein paar Fragen - sorry fürs nachbohren, aber die Semantik von Daten ist eines meiner Hauptarbeitsgebiete

- Was ist der Unterschied zwischen Jalousien und Rollläden bei Dir?
- Warum würde man "alle Jalousien" von "die Jalousien" unterscheiden?
- Gibt es vorgefertigte Szenen für die Jalousien/Rollläden?
- Gibt es einen Unterschied zwischen "halb zu" und "halb auf"?
- Fragst Du auch nach dem Dieselpreis in anderen Orten?
- Wie viele Farben erkennt das System?

LG

pah
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 20 März 2022, 12:32:44
Zitat von: Prof. Dr. Peter Henning am 20 März 2022, 12:12:21
Machen wir doch glatt:

https://forum.fhem.de/index.php/topic,126864.0.html (https://forum.fhem.de/index.php/topic,126864.0.html)
Danke.

Habe eben noch eine Version ins svn geschubst, die etwas länger mit dem asyncOutput wartet und die vereinzelten HASH-responses auch noch "verklartextet".

Zitat
Zu Deinen Sätzen ein paar Fragen - sorry fürs nachbohren, aber die Semantik von Daten ist eines meiner Hauptarbeitsgebiete
Kein Problem mit den Fragen :) .

Zitat
- Was ist der Unterschied zwischen Jalousien und Rollläden bei Dir?
Jalousien haben drehbare Lamellen, und es gibt ein "special" dazu. Rollladen ist das, was  einen "Panzer" hat. Effektiv gibt es in der Steuerungslogik sonst keine weiteren Unterschiede, sind beides gDT "blind".

Zitat- Warum würde man "alle Jalousien" von "die Jalousien" unterscheiden?
"alle" und "sämtliche" sind bei mir die "Kenner" für Gruppenintents (wir hatten die Diskussion über structure schon, aus dem Folgenden wird vielleicht klarer, warum ich das anders passender finde).

Prinzipiell ist noch fraglich, ob wir einen "Durchbruch" von Einzel- zu Gruppenintent brauchen könnten, und was ggf. die Kriterien wären, das zu machen ("mach das licht aus" => mehre Möglichkeiten (im Raum)).

Zitat- Gibt es vorgefertigte Szenen für die Jalousien/Rollläden?
Bisher nicht.
Wäre dann aber eine vom gDT abgekoppelte Sache, die über "SetScene" laufen würde

Zitat- Gibt es einen Unterschied zwischen "halb zu" und "halb auf"?
Nein.
Steuert beides einen "speziellen" Zwischenstand, so dass ich die "Panzer-Wicklung" bei den Rollläden (CUL_HM) berücksichtigen könnte (49.5=> ca. 30, "spezielles Feature", ursprünglich entwickelt für/mit Gisbert)

Zitat- Fragst Du auch nach dem Dieselpreis in anderen Orten?
Bisher nicht, das hatte ich jetzt erst mal auf die Schnelle hingepinselt wegen der Tests. Aber prinzipiell sollte das auch ohne weiteres funktionieren, wobei hier das spezielle Thema noch nicht gelöst ist, dass eigentlich ein Reading abgefragt werden soll. STATE ginge schon, Rest ist "Todo".

Zitat- Wie viele Farben erkennt das System?
Das ist (fast) der slot aus der de-cfg, der nach meiner Erinnerung das Farbrad mit 360 Grad Farben in ca. 15 Grad-Schritten auflöst.
(Die Erläuterung zu Farben steht im Wiki, meine ich; das Prinzip ist Rhasspy-Farbe => Nummer => RHASSPY => HUE-Nummer auf der individuellen Skala des Devices, wenn das nicht geht Mapping zu rgb-Wert).
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 20 März 2022, 17:36:04
Zitat von: Beta-User am 20 März 2022, 12:32:44
wobei hier das spezielle Thema noch nicht gelöst ist, dass eigentlich ein Reading abgefragt werden soll. STATE ginge schon, Rest ist "Todo".
...stimmt gar nicht, jedenfalls nicht, was den Type "price" angeht. Man muss nur "richtig fragen":
was kostet{Type:price} (Diesel){Reading} [( in | an | bei )] $de.fhem.Device-info{Device}
(und die Doku anpassen/ergänzen... ::) . Und das Ganze erweitern um eventuelle weitere Type's?)

Dafür kommt noch was anderes auf meine Liste:
Die Antwort auf die Abfrage, was RHASSPY "kann", erhöht vermutlich deutlich die Transparenz und auch die Akzeptanz beim Umfeld, von daher werde ich mal sehen, ob ich den GetState-Intent noch etwas aufbohre um eigene Abfragen zu RHASSPY (mit raumbezogenen Rückmeldungen).

@pah: Prinzipiell würde mich noch interessieren, ob die Rückmeldungen im  Test-Modus in etwa so sind, wie du dir das gedacht hattest?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 22 März 2022, 16:20:30
Na nu?!? So still hier...?

Hat denn zwischenzeitlich jemand mal das Test-File-feature ausprobiert? Gibt es weitere Meinungen dazu...?

Wie bereits geschrieben: Die Ergebnisse sind recht aufschlussreich, und ich habe das auch zum Anlass genommen, nochmal kräftig an allen Ecken und Enden nachzujustieren, angefangen damit, dass man (vielleicht) auch "mach wärmer" oder "etwas heller bitte" sagen können sollte, "GetState" zu "allem möglichen" "missbrauchen" kann und voraussichtlich dann auch ein gewisser "probability-score" erreicht sein sollte...

Werde das ganze jetzt erst mal selbst still vor mich hin testen, wenn niemand "will haben" ruft... (Es gibt dann voraussichtlich noch ein paar kleinere Änderungen zum vorherigen Stand bzgl. der "keys" zu GetState usw.).
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 24 März 2022, 18:32:25
...immer noch still...?!?

Na ja, es gibt jetzt jedenfalls eine neue Version im svn, die de-Sprachdatei ist auch aktualisiert, weil es ein paar neue Antwort-Möglichkeiten gibt => braucht einen Neustart.

changelog:

- confidenceMin (tweak)
Ein (einstellbarer) Mindestwert (global oder pro Intent) muss erreicht sein, sonst wird keine Aktion ausgeführt

- blacklistIntents (special)
einzelne Intents können ignoriert werden, um z.B. "stop"-Kommandos aus HTTPMOD nicht als Kommando verfügbar zu machen

- intent SetNumeric
erlaubt mehr "devicelose" Kommandos (wärmer/kälter usw.)

- GetState überarbeitet:
-- erlaubt es, beliebige Inhalte auszuwerten, indem in rhasspyMapping GetState mit einem type und einer stateFormat-artigen "response" angeben wird;
-- Status-Infos zu RHASSPY selbst können abgefragt werden (insbesondere auf den aktuellen Raum der Anfrage bezogen)

=> neue keys für languageFile => Neustart notwendig!

- Test-Modus
Neue getter, getestet werden kann mit File und einzelnen Sätzen (es werden keine Schaltbefehle ausgeführt).

- Export von rhasspyMapping
Neuer getter, hilfreich vielleicht, wenn man was individualisieren will oder auf ein anderes Device kopieren.

Im Anhang dann auch die etwas erweiterte "Testsuite" von pah mit einem "Schnellschuss" zur Erkennung von Dialogen etc..

Viel Spaß beim Testen.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Gisbert am 24 März 2022, 19:05:50
Hallo Jörg,

ich lese eifrig mit und lade in regelmäßigen Abständen die neueste Version runter.
Rhasspy empfängt meine Sprachbefehle über die Handy-App und sagt "Ok, zu Diensten" oder dergleichen.

Eine weiterführende Kommunikation mit Rhasspy habe ich noch nicht versucht, da ich es für mich zu schwierig ansehe, es umzusetzen. Interesse ist im Grunde schon gegeben, aber bis da der Groschen wieder fällt, das könnte dich und mich an unsere Grenzen bringen ;D

Viele​ Grüße​ Gisbert​
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 25 März 2022, 10:46:18
Also, dann mal der Versuch einer "Kurzanleitung" für einen "Test" mit der im letzten Beitrag angehängten FEST.txt (oder der Ausgangsversion von pah):

Diese Datei so irgendwohin speichern, dass der User "fhem" sie lesen darf (z.B. nach /opt/fhem/FEST.txt mit passenden Rechten).
Dann das Testen mit "get <RHASSPY> test_file ./FEST.txt" starten, und etwas warten. Wird der Test halbwegs zeitnah fertig (bis 30 Sekunden), gibt es eine qualifizierte Rückmeldung, wenn nicht, eben eine timeout-Meldung. Für Sicherheitsfanatiker: bei mir läuft der Test ohne Stress durch, aber sicherheitshalber die statefile vorher wegzuschreiben kann nicht schaden, falls wider Erwarten doch was schief geht...

Während der Test läuft, ist ein Internal "testline" vorhanden, das hochgezählt wird und dann auch wieder gelöscht wird. Geht irgendwas schief, ändert sich die Zahl nicht mehr, und man kann dann den Prozess mit einem "get <RHASSPY> test_sentence bla blub" oä. stoppen. Da das ganze als "Ping-Pong"-Spiel zwischen RHASSPY und Rhasspy abläuft, wird FHEM auch in der Zeit nicht blockiert, Schaltanweisungen werden (hoffentlich) keine ausgeführt.

Die "FEST.txt" enthält einfach "nur" eine Sammlung von möglichen Ergebnissen aus einem speech2text-Prozess, die zeilenweise nacheinander getestet werden. Man kann die Zeilen (oder andere Sätze) genausogut jeweils einzeln testen: "get <RHASSPY> test_sentence <hier steht der gesprochene Text>".

Also eigentlich: Super-easy, und wer RHASSPY bis dahin ans Laufen gebracht hat, sollte damit keine ernsthaften Probleme haben.

Die spannende Frage ist: Warum sollte man das tun?!?

Nun ja, vermutlich wird/muss dazu jeder seine eigene Antwort finden...

Um zu erklären, was es für mich (bisher) gebracht hat, ein paar ergänzende Ausführungen.

Meine Nutzungsweise ist ähnlich wie bei Gisbert:
ZitatRhasspy empfängt meine Sprachbefehle über die Handy-App und sagt "Ok, zu Diensten" oder dergleichen.
Da die App sehr bewußt gestart bzw. das "Mikro" aktiviert wird, wenn man was tun will, und dann recht klar umrissene Sätze gesagt werden, die sowohl der Sprecher und Rhasspy jeweils schon gut "kennen", sind die Ergebnisse meist auch zur vollen Zufriedenheit.
Die "Problemchen" der "normalen User", die per hotword aktivieren, und dann "eigenwillige" Schaltaktionen (oder Ansagen, Timer-Erstellungen, ....) beobachten, kenne ich daher nicht so richtig aus eigener Anschauung. Dazu kommt, dass es ist im normalen Betriebsmodus auch recht mühsam zu rekonstruieren ist, warum was (nicht) passiert ist, wenn mal was schiefgeht.

Läßt man die "geballte Ladung" (aus FEST.txt) auf RHASSPY los, erhält man dagegen recht schnell einen Überblick darüber,
- ob Rhasspy daraus überhaupt was ableitet oder "intent not recognized" ist (=> in der "result" bleibt einfach nur der Ausgangssatz stehen);
- welchen Intent Rhasspy abgeleitet hat und welche "keys" an RHASSPY übergeben wurden;
- wie RHASSPY das verarbeitet hat (jetzt: jedenfalls meistens).

Unmittelbare Folgen aus meinen bisherigen Tests:
1. Bei den ersten Tests war dann recht schnell klar, dass RHASSPY (nach meinem Geschmack) in zu vielen Fällen noch "irgendwas" gemacht hat, obwohl Rhasspy schon "weiß nicht so recht" gemeldet hat - was einem niedrigeren "confidence"-Level entspricht. Diesen (auch) auszuwerten, war eigentlich schon lange auf meiner "muss ich mir mal ansehen"-Liste, aber wegen der oben beschriebenen bewußten Aktivierung stand ja mehr oder weniger immer eine "1" da - das sah also "sinnfrei" aus.

Anders gesagt: Die "Radio/Fernsehen macht den Rollladen zu"-Fraktion sollte also (ganz ohne Tests) deutlich von der aktuellen Version profitieren, schlicht, weil (vermutlich) zufälliger "Kauderwelsch" eher aussortiert wird. Allerdings kann es sein, dass die (allgemeine) Grenze für "confidence" jetzt zu hoch oder niedrig angesetzt ist :P . Das rauszufinden, könnte einer der denkbaren Anstösse sein, um mal das "get" auszuprobieren 8) .

2. Da die FEST.txt Beispielsätze dazu enthält, was andere User (und deren Mitbewohner) mit ihrer Sprachsteuerung so "tun", ist das ganze auch eine Fundgrube für eventuelle Verbesserungen und/oder Ergänzungen, von der man ggf. Gebrauch machen kann... Teilweise waren dazu Änderungen im RHASSPY-Code erforderlich, und für manches werden wird das ggf. auch noch zu besprechen haben, ob bzw. was noch fehlt.
Da manche von pah's Ausgangssätzen mit leichten Modifikationen zu "besseren" Ergebnissen führen, sind diese (teilweise) als Beispiel am Ende angefügt. Mittelfristig wäre es vermutlich sinnvoller, Varianten direkt untereinander zu listen und ggf. z.B. die Abschnitte zu kennzeichnen, so dass man auch eine gesonderte mengenmäßige Erfassung einzelner Themengebiete vornehmen könnte.

Hoffe, damit wird das Bild etwas klarer :) .
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 25 März 2022, 13:18:41
Ich bekomm hier bei
get Rhasspy test_sentence wer bist du
nur "Timeout for test sentence - most likely this is no problem, check testResult reading later, but your system seems to be rather slow..."
Was ich aber echt nicht glaube ;)

testResult ist immer "Test mode stopped (might have been running already)"
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 25 März 2022, 13:33:31
Hmmm, kennt Rhasspy die siteId von deinem FHEM (typischerweise für "de": "defhem")?

Die muss zumindest im NLU-Modul auf der Rhasspy-Seite mit aufgeführt sein. Sorry, dass ich das in der Anleitung wohl ausgelassen habe (es steht hoffentlich in der commandref).
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 25 März 2022, 13:36:19
Guter Hinweis. Hat aber leider nichts geändert.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 25 März 2022, 13:48:39
Bleibt auch das Internal stehen, oder ist es jetzt weg?

Kurz zur Erläuterung: Nach einem "Abbruch" sollte es weg sein, erst der darauf folgende Versuch wird dann wieder effektiv an Rhasspy geschickt.

Hmmm, muss mir wohl noch was überlegen für einzelne Sätze und "Intent not recognized"...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 25 März 2022, 13:50:14
Das bleibt stehen

--EDIT--

Aber nur bei test_sentence. Bei test_file geht's wieder weg.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 25 März 2022, 14:13:26
Hmm, entweder ich habe beim Einchecken irgendwas verwechselt, oder mein Echtsystem verhält sich anders...

Wie dem auch sei: Der Fall war nicht abgedeckt, dass gar keine Rückmeldung kommt, und der "Einzeltimeout" ist auch eine gute Stelle, um nochmal auf das siteId-Thema hinzuweisen. Außerdem kann bei der Einzelabfrage der ausdrückliche Hinweis nicht schaden, dass die Rückmeldung "intent not recognized" erfolgt war (also überhaupt was passiert ist).

Anbei ein vorläufiges update dazu.

EDIT/PS: wie findest du, was in der FEST_result.txt so alles steht...?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 25 März 2022, 15:09:53
Sorry, ich bin ein Depp. Hab die rhasspy-de.cfg ins falsche Verzeichnis kopiert. Liegt jetzt im richtigen und so funktioniert's. Zumindest test_sentence.

Bei test_file bekomme ich zwar "Test file ./FEST.txt is initiated. See if internal 'testline' is rising and check testResult reading later" und das internal wird erstellt. Internal bleibt aber irgendwie immer bei 11. Wie lange dauert so ein Durchgang bei dir?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 25 März 2022, 15:24:23
Zitat von: drhirn am 25 März 2022, 15:09:53
Sorry, ich bin ein Depp. Hab die rhasspy-de.cfg ins falsche Verzeichnis kopiert. Liegt jetzt im richtigen und so funktioniert's. Zumindest test_sentence.
Ähm, dieser Zusammenhang erschließt sich mir nicht auf die Schnelle. Wenn die languageFile nicht geladen werden kann (oder einen alten Stand hat), wird halt ggf. der default (englisch)-Kontent genommen.

Zitat
Bei test_file bekomme ich zwar "Test file ./FEST.txt is initiated. See if internal 'testline' is rising and check testResult reading later" und das internal wird erstellt. Internal bleibt aber irgendwie immer bei 11. Wie lange dauert so ein Durchgang bei dir?
11 ist zu lesen als Zeile 12 (Array-Nummerierung beginnt bei Element 0). Das entspricht (wegen der vorherigen "Kommentierungen") dem ersten "echten" Test (wer bist du), und der gibt anscheinend keine Antwort, warum auch immer.

Da du ja deine FHEM-siteId zwischenzeitlich bei Rhasspy eingetragen hast, habe ich dafür vorläufig keine naheliegende Erklärung mehr, vermutlich sollte man für so einem Fall dann einen weiteren Timer einbauen, der das ganze als erfolglos beendet.

Vielleicht sollte man die Grundfunktionalität erst testen mit unserem "hello world" ("Wie spät ist es")? Das sollte reibungslos durchlaufen und mit einem Dialogfeld als Rückmeldung enden.

Kompletter Durchlauf dauert bei mir knapp über 14 Sekunden... (dualcore-uralt-AMD, Rhasspy (und anderes wie deconz) auf demselben System):
Zitattested 174 sentences, failed total: 114, amongst these in dialogues: 17. Testing time: 14.02 seconds. See FEST_result.txt for detailed results.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 25 März 2022, 15:41:55
Zitat von: Beta-User am 25 März 2022, 15:24:23
Ähm, dieser Zusammenhang erschließt sich mir nicht auf die Schnelle. Wenn die languageFile nicht geladen werden kann (oder einen alten Stand hat), wird halt ggf. der default (englisch)-Kontent genommen.
Hmm, ja. Stimmt eigentlich. Komisch.

Zitat
Vielleicht sollte man die Grundfunktionalität erst testen mit unserem "hello world" ("Wie spät ist es")? Das sollte reibungslos durchlaufen und mit einem Dialogfeld als Rückmeldung enden.
Mit einer Datei, in der nur "wie spät ist es" steht, hat's funktioniert.
Die funktioniert auch:

wie spät ist es
wie spät
licht aus
licht ein


Die nicht mehr:

wie spät ist es
wie spät
licht aus
licht ein
notfall


Kann es sein, dass RHASSPY aussteigt, sobald ein Wort kommt, das Rhasspy nicht kennt?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 25 März 2022, 15:51:48
Zitat von: drhirn am 25 März 2022, 15:41:55
Kann es sein, dass RHASSPY aussteigt, sobald ein Wort kommt, das Rhasspy nicht kennt?
RHASSPY wartet - im Moment bis in alle Ewigkeit - bis Rhasspy auf die grade aktuelle Anfrage eine Antwort sendet, und sendet dann erst die nächste raus.

Die Ursache für das unterschiedliche Verhalten unserer beiden Systeme liegt daher auf der Rhasspy-Seite, das müßten wir ggf. morgen mal gegeneinanderhalten. Jedenfalls kennt auch mein Rhasspy eine ganze Menge der Worte nicht, die in der File stehen, das alleine ist es nicht...

Prinzipiell zeigt sich aber, dass wir einen (zusätzlichen) Timer-Mechanismus brauchen, der solche Fälle abfängt. Muss mal nachdenken, wird etwas brauchen, weil sichergestellt sein muss, dass es nicht zu sich überkreuzenden Messages kommt. Tendenziell müßte daher der ganze Vorgang abgebrochen werden und halt in die "result" geschrieben, was bis dato bekannt ist (wenn du ein list anschaust, siehst du das, was bisher gesammelt wurde, und wo es nicht weiter geht).
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 25 März 2022, 16:00:09
Zitat von: Beta-User am 25 März 2022, 15:51:48
Die Ursache für das unterschiedliche Verhalten unserer beiden Systeme liegt daher auf der Rhasspy-Seite, das müßten wir ggf. morgen mal gegeneinanderhalten.
Kann dir nicht versprechen, dass ich morgen zu irgendwas komme. Aber unsere Bases sind mit Sicherheit unterschiedlich konfiguriert.

Da mal meine Config:

{
    "dialogue": {
        "group_separator": ".",
        "satellite_site_ids": "wohnzimmer.pc,wohnzimmer.03,wohnzimmer.sofa,vorraum,küche,schlafzimmer,defhem"
    },
    "intent": {
        "satellite_site_ids": "wohnzimmer.pc,wohnzimmer.03,wohnzimmer.sofa,vorraum,küche,schlafzimmer,defhem",
        "system": "fsticuffs"
    },
    "sounds": {
        "error": "${RHASSPY_PROFILE_DIR}/error.wav",
        "recorded": "${RHASSPY_PROFILE_DIR}/end_of_input.wav",
        "wake": "${RHASSPY_PROFILE_DIR}/start_of_input.wav"
    },
    "speech_to_text": {
        "kaldi": {
            "allow_unknown_words": true,
            "cancel_word": "alexa"
        },
        "satellite_site_ids": "wohnzimmer.pc,wohnzimmer.03,wohnzimmer.sofa,vorraum,küche,schlafzimmer,defhem",
        "system": "kaldi"
    },
    "text_to_speech": {
        "satellite_site_ids": "wohnzimmer.pc,wohnzimmer.03,wohnzimmer.sofa,vorraum,küche,schlafzimmer,defhem",
        "system": "nanotts"
    }
}
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 25 März 2022, 16:08:31
OK, bei mir ist innerhalb von "fsticuffs" noch "fuzzywuzzy" aktiv mit einer "min_confidence" von "0.01", bei "dialogue" und dem ganzen Rest ist "defhem" nicht als siteId drin, das steht wirklich nur bei "intent" mit drin.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 25 März 2022, 16:29:21
Sollte alles eigentlich keinen Unterschied machen
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 25 März 2022, 17:14:50
Dann habe ich im Moment keine Idee.

Anbei eine erste Version mit timeout. "Müßte" eigentlich durchlaufen bzw. bricht ab, wenn nichts kommt (letzteres ist getestet).
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 25 März 2022, 17:37:01
...doch. Den MQTT-Verkehr ansehen. intentNotRecognized sollte was melden. Ggf.passen die subsciptions am M2Client nicht?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 26 März 2022, 06:54:58
Zitat von: Beta-User am 25 März 2022, 17:37:01
...doch. Den MQTT-Verkehr ansehen. intentNotRecognized sollte was melden. Ggf.passen die subsciptions am M2Client nicht?
Das steht beim meinem MQTT2_CLIENT auf "setByTheProgram".

Habe im svn eine aktualisierte Fassung eingecheckt, die zumindest nach ersten Tests auf dem Hauptsystem ok zu sein scheint.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 27 März 2022, 11:43:54
...und noch ein update im svn, mit dem dann auch das "priority"-mapping für desired-temp funktionieren sollte...

@Gisbert: War meine Anleitung soweit nachvollziehbar?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Gisbert am 27 März 2022, 17:58:30
Hallo Jörg,

Zitat@Gisbert: War meine Anleitung soweit nachvollziehbar?

von weitem betrachtet, hast du mir Mut gemacht; dann kam aber deine Konversation mit drhirn - da hab ich auf Durchzug geschaltet, ich bin noch nicht soweit und bis Ostern hab ich eher weniger Zeit mich damit auseinanderzusetzen. Aufgeschoben ist nicht aufgehoben.

Viele​ Grüße​ Gisbert​
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 28 März 2022, 07:51:42
Zitat von: Gisbert am 27 März 2022, 17:58:30
bis Ostern hab ich eher weniger Zeit mich damit auseinanderzusetzen. Aufgeschoben ist nicht aufgehoben.
...kein Problem...

Die Diskussion hat zumindest mal aufgezeigt, wo die Anleitung lückenhaft war.

Es würde mich natürlich weiter interessieren, ob es jetzt auch bei anderen funktioniert, aber früher oder später wird da schon die eine oder andere Rückmeldung kommen...

Hier jedenfalls mal die aktualisierte Anleitung:
1. siteId von der FHEM Instanz (siehe entsprechendes Internal) im Bereich "Intent Recognition" der Rhasspy-Base eintragen.

2. mit "get <RHASSPY> test_sentence wie spät ist es" testen, ob die Kommunikation in den "Positiv-Fällen" klappt.

3. mit "get <RHASSPY> test_sentence alice kann von bob nicht erhört werden" (oder irgendeinem Unsinn, den Rhasspy nicht versteht) die Negativ-Fälle testen. Es sollte eine Antwort kommen, die in etwa so aussieht: "Test failed, result is: alice kann von bob nicht erhört werden => Intent not recognized."
Kommt ein Timeout, ist der "not recognized"-Topic vermutlich nicht in den "subscriptions" am MQTT2_CLIENT enthalten; wer die subscriptions von RHASSPY verwalten läßt ("attr rhasspy2mqtt subscriptions setByTheProgram") sollte dieses Problem nicht haben.

Wenn beides klappt, kann man die "geballte Ladung" auf Rhasspy loslassen:

Zitat von: Beta-User am 25 März 2022, 10:46:18
Also, dann mal der Versuch einer "Kurzanleitung" für einen "Test" mit der im letzten Beitrag angehängten FEST.txt (oder der Ausgangsversion von pah):

Diese Datei so irgendwohin speichern, dass der User "fhem" sie lesen darf (z.B. nach /opt/fhem/FEST.txt mit passenden Rechten).
Dann das Testen mit "get <RHASSPY> test_file ./FEST.txt" starten, und etwas warten. Wird der Test halbwegs zeitnah fertig (bis 30 Sekunden), gibt es eine qualifizierte Rückmeldung, wenn nicht, eben eine timeout-Meldung. Für Sicherheitsfanatiker: bei mir läuft der Test ohne Stress durch, aber sicherheitshalber die statefile vorher wegzuschreiben kann nicht schaden, falls wider Erwarten doch was schief geht...

Während der Test läuft, ist ein Internal "testline" vorhanden, das hochgezählt wird und dann auch wieder gelöscht wird. Geht irgendwas schief, ändert sich die Zahl nicht mehr, und man kann dann den Prozess mit einem "get <RHASSPY> test_sentence bla blub" oä. stoppen. Da das ganze als "Ping-Pong"-Spiel zwischen RHASSPY und Rhasspy abläuft, wird FHEM auch in der Zeit nicht blockiert, Schaltanweisungen werden (hoffentlich) keine ausgeführt.

Die "FEST.txt" enthält einfach "nur" eine Sammlung von möglichen Ergebnissen aus einem speech2text-Prozess, die zeilenweise nacheinander getestet werden. Man kann die Zeilen (oder andere Sätze) genausogut jeweils einzeln testen: "get <RHASSPY> test_sentence <hier steht der gesprochene Text>".

Also eigentlich: Super-easy, und wer RHASSPY bis dahin ans Laufen gebracht hat, sollte damit keine ernsthaften Probleme haben.

Die spannende Frage ist: Warum sollte man das tun?!?
[...]

Ich habe übrigens noch eine weitere Antwort auf die Frage gefunden: Weil man damit Lücken im Programmablauf aufdecken kann...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 28 März 2022, 09:18:27
Zitat von: Gisbert am 27 März 2022, 17:58:30
von weitem betrachtet, hast du mir Mut gemacht; dann kam aber deine Konversation mit drhirn - da hab ich auf Durchzug geschaltet

Ignorier einfach alle Unterhaltungen zwischen Beta-User, pah, JensS oder mir. Das verwirrt im "Anfängerstadium" nur und hat (noch) keine Relevanz. Auch wenn das jetzt arrogant klingt. Ist nicht so gemeint.

Mach zu deinen Fragen einfach einen neuen Thread auf. Da bekommst du zielgerichtete Antworten und es bleibt übersichtlicher.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 28 März 2022, 09:33:35
Zitat von: Beta-User am 28 März 2022, 07:51:42
Kommt ein Timeout, ist der "not recognized"-Topic vermutlich nicht in den "subscriptions" am MQTT2_CLIENT enthalten; wer die subscriptions von RHASSPY verwalten läßt ("attr rhasspy2mqtt subscriptions setByTheProgram") sollte dieses Problem nicht haben.


test(s) passed successfully. Summary: tested 160 sentences, failed total: 123, amongst these in dialogues: 0. Testing time: 4.10 seconds. See ./FEST_result.txt for detailed results., duration: 4.10 s


;)
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 28 März 2022, 09:49:09
Zitat von: drhirn am 28 März 2022, 09:33:35

test(s) passed successfully. Summary: tested 160 sentences, failed total: 123, amongst these in dialogues: 0. Testing time: 4.10 seconds. See ./FEST_result.txt for detailed results., duration: 4.10 s


;)
Danke für die Rückmeldung, sonst wären mir wirklich die Ideen ausgegangen...
Und ja: Performance auf dem Server ist offenkundig nicht das Problem ;D .

Jetzt bin ich nur mal gespannt, ob dir die Analyse der FEST_result.txt auch das eine oder andere "aha"-Erlebnis bringt (oder die Frage aufwirft, wie man die dahinter stehende Aufgabe am effizientesten löst) 8) .

Notizen an mich selbst:
- die "not recognized"-Fälle sollte man bei den "echten" Messenger-Fällen vermutlich auch noch gesondert mit einer Antwort bedenken, damit der Anfragende jedenfalls eine Rückmeldung bekommt;
- die doppelte Zeitausgabe muss nicht sein...
- Die ergänzte "Anleitung" sollte noch in den anderen Thread.

@all und insbesondere Gisbert: da kann man dann auch die Fragen zum Testen an sich und ggf. eben den Ergebnissen loswerden (so sie nichts mit den "internen Abläufen" zu tun haben).
Und: ruhig auch als "Einsteiger" testen; nur wenn eventuelle Fragen auftauchen, kann man was verbessern, sei es an den Programmabläufen, sei es an der Doku :) .
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 28 März 2022, 09:54:17
Zitat von: Beta-User am 28 März 2022, 09:49:09
Und ja: Performance auf dem Server ist offenkundig nicht das Problem ;D .
Nein, haha. Nur das Beste für meine VMs ;)

ZitatJetzt bin ich nur mal gespannt, ob dir die Analyse der FEST_result.txt auch das eine oder andere "aha"-Erlebnis bringt (oder die Frage aufwirft, wie man die dahinter stehende Aufgabe am effizientesten löst) 8) .
Nicht so wirklich. Liegt aber daran, dass bei mir Sprachassistenten seit jeher ein Schattendasein führen. Rhasspy wird bei mir (und nur mir) verwendet, um den PC und den TV einzuschalten und Lichtszenen im Wohnzimmer zu ändern. Das war's ;)
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 28 März 2022, 10:38:36
Zitat von: drhirn am 28 März 2022, 09:54:17
Nicht so wirklich. Liegt aber daran, dass bei mir Sprachassistenten seit jeher ein Schattendasein führen. Rhasspy wird bei mir (und nur mir) verwendet, um den PC und den TV einzuschalten und Lichtszenen im Wohnzimmer zu ändern. Das war's ;)
:) Spricht ja auch nichts dagegen, das so zu halten, ging mir ja lange genauso...

Allerdings war ich auch "überrascht", wie relativ genau man Anweisungen erteilen muß, um ein Ergebnis zu bekommen, es ist also (zum Teil auch) ein "Henne-Ei"-Problem. Dazu kommt ggf. noch das, was man als fehlende "Dialogfähigkeit" bezeichen könnte: die allgemeinere Akzeptanz einer solchen Lösung hängt u.A. auch davon ab, dass man sich mit ihr "unterhalten" kann (wenn ich insbesondere pahs Ausführungen zu diesem Thema korrekt verstanden/interpretiert habe). Bei RHASSPY war sowas (bisher) eher wenig bis nicht vorhanden...

Mit der Option, per Messenger Infos abzufragen, ist für mich aber ein interessantes Spielfeld dazugekommen, das m.E. auch flexibler ist als das, was z.B. msgDialog kann.

Nun ja, mal sehen, was wir da noch hinfrickeln können.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Prof. Dr. Peter Henning am 28 März 2022, 13:22:42
Ich bin in den letzten Wochen durch meinen Beruf mal wieder komplett blockiert und komme wenig zum Testen.

Zum Thema Messenger: Ich habe Telegram an mein System angekoppelt. Über Telegram Keyboards für die wesentlichen Aufgaben - aber faktisch kann ich darüber alles abfragen und (bis auf sicherheitskritische Dinge) auch alles steuern, was ich per Spracheingabe tun kann.

LG

pah
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 28 März 2022, 13:45:48
Zitat von: Prof. Dr. Peter Henning am 28 März 2022, 13:22:42
Ich bin in den letzten Wochen durch meinen Beruf mal wieder komplett blockiert und komme wenig zum Testen.
...nun ja, die bestellte Pizza wird halt kalt, aber ich vermute, damit kannst du leben... ;D

Zitat
Zum Thema Messenger: Ich habe Telegram an mein System angekoppelt. Über Telegram Keyboards für die wesentlichen Aufgaben - aber faktisch kann ich darüber alles abfragen und (bis auf sicherheitskritische Dinge) auch alles steuern, was ich per Spracheingabe tun kann.
Ich habe auch Telegram und darüber ein paar Favoriten-Menüs im Einsatz. Alles mögliche Schalten oder abfragen geht sowieso, wenn man die Namen kennt. Als derzeitiger Maintainer von msgDialog habe ich es sogar in der Hand, das ggf. weiter zu verbessern, und mit dem "aktiviere etwas nur, wenn es über den Meta-Dialog kommt"-Mechanismus kann man damit auch nette Sachen basteln, die helfen, wenn man den/die Namen grade nicht parat hat.

Mein "Problem": irgendwie widerstrebt es mir, dafür extra nochmal eine zweite "Meta-Sprach-Ebene" einzuziehen - vermutlich ist das bei mir ähnlich wie bei dir mit Babble (und bei anderen glt ggf. dasselbe für Talk2FHEM oder TEERKO (?)). Deswegen nutze ich eben jetzt FEST.txt um die noch fehlenden Bausteinchen für eine sehr flexible Abfrage- und Ansage-Ebene zusammenzupuzzeln...

Gedanklich hänge ich grade an einer Anweisung wie "mach ein bißchen heller". Gibt es nur ein Gerät, das dafür in Frage kommt, ist es einfach, aber wie könnte man das umsetzen, wenn es sich um eine Gruppe von Leuchtmitteln handelt?
Vor allem, wenn da eventuell ein paar reine ein/aus-Geräte dabei sind, einige derzeit ausgeschaltet, ... (von "mach einfach die Rollläden auf, wenn es Tag ist" gar nicht zu sprechen...).
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 28 März 2022, 14:55:25
Zitat von: Beta-User am 28 März 2022, 13:45:48
Gedanklich hänge ich grade an einer Anweisung wie "mach ein bißchen heller". Gibt es nur ein Gerät, das dafür in Frage kommt, ist es einfach, aber wie könnte man das umsetzen, wenn es sich um eine Gruppe von Leuchtmitteln handelt?
Vor allem, wenn da eventuell ein paar reine ein/aus-Geräte dabei sind, einige derzeit ausgeschaltet, ... (von "mach einfach die Rollläden auf, wenn es Tag ist" gar nicht zu sprechen...).

Das wäre meiner Meinung nach in FHEM abzubilden. Aber da kenn ich mich nicht aus ;D
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 28 März 2022, 15:25:19
Zitat von: drhirn am 28 März 2022, 14:55:25
Das wäre meiner Meinung nach in FHEM abzubilden. Aber da kenn ich mich nicht aus ;D
To be discussed... :P

Also: Gedanklicher Ausgangspunkt war bei mir "mach wärmer" - das ging bis gestern ohne Device oder Gruppe gar nicht, obwohl doch eigentlich klar ist, was der Sprechende (in etwa) haben will, nämlich eine Anhebung der Solltemperatur in dem Raum, in dem er sich befindet...
Bei "mach lauter" ging diese Device-lose Logik "schon immer" (wobei ich mich im Moment frage, ob es immer an das richtige Device geht, wenn es zwei aktive gibt), jetzt geht es bei "desired-temp", wenn es genau ein passendes Gerät gibt (das habe ich jetzt durch "priority/inRoom"-Specials erzwungen, wo es nicht eindeutig war).

Das Problem, dass FHEM ohne RHASSPY nach meinem Gefühl im Moment hat: Ohne konkreten Anknüpfungspunkt kann es nicht abgrenzen, wo und was eigentlich im Detail passieren soll. Selbst wenn man z.B. eine structure gäbe, müßte man die zunächst identifizieren. Entweder der Sprechende tut es, (indem er den Namen nennt...) oder es müßte eine Art "Fallback" geben, den RHASSPY dann heranzieht.
Letzteres hat aber m.E. kaum Vorteile gg. einer dynamisch erstellten "RHASSPY-Struktur", wie sie im Kern ja bereits angesprochen wird, wenn man "dimme gruppe xy runter" sagt. (Bei einer structure hagelt es übrigens Log-Einträge, wenn man eine Mischung von dim- und on/off-Geräten hat).

An sich müßte es möglich sein, eine Art "virtuelle Durchschnittshelligkeit" zu bestimmten, die eine solche spontan abgegrenzte Gruppe grade hat, und die zu verändern, indem man eben entweder Dimm-Befehle ausführt, oder einzelne Geräte ab (ggf. individuellen) Grenzwerten ein- oder ausschaltet. Aber ja: Es ist und bleibt relativ komplex rauszufinden, was in welchem Fall konkret passieren soll, und die Geschmäcker sind verschieden, und viele Anwendungsfälle kann man vermutlich über Szenen besser abbilden...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 28 März 2022, 15:34:19
Hmm. Naja, wenn einer "mach wärmer" sagt, dann wissen wir ja schon mal, was er will (sofern er nicht das Licht wärmer stellen will). Und wir wissen, wo er wahrscheinlich ist (siteId). Müsste man ja nur noch ein Gerät finden, dass man wärmer stellen kann (GDT). Und wenn's mehrere gibt, nachfragen.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 28 März 2022, 15:43:43
Zitat von: drhirn am 28 März 2022, 15:34:19
Hmm. Naja, wenn einer "mach wärmer" sagt, dann wissen wir ja schon mal, was er will (sofern er nicht das Licht wärmer stellen will). Und wir wissen, wo er wahrscheinlich ist (siteId). Müsste man ja nur noch ein Gerät finden, dass man wärmer stellen kann (GDT). Und wenn's mehrere gibt, nachfragen.
Na ja, bei meinen CUL_HM-Klimageräten ist es so, dass die entweder "geteamt" sind (es reicht, einen zu stellen, der andere folgt dann nach), oder man sinnigerweise den Wandthermostaten anspricht (mit identischer Folgewirkung). Beides ist eine Ausgangssituation, bei der man mit "priority" für eindeutige Verhältnisse in "SetNumeric" sorgen kann, und das z.B. dann zweimal im Jahr zu ändern, falls man noch eine Klimaanlage hat, ist dann die Lösung für die, die keinen dummy+eigene Logik dazwischenklemmen wollen...

Aber nochmal: Wo ist der Unterschied zur Beleuchtung...? Außer der vermuteten größeren Anzahl (=>SetNumericGroup) der betroffenen Devices (und den daraus so oder so resultierenden Detailfragen)?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 28 März 2022, 21:10:58
...da ich ja grade eh' dabei war, wieder etwas tiefer im Code zu graben, habe ich eben noch ein update ins svn geschubst, das im Intent "SetTimer" einen "key" "GetTimer" (ähnlich wie "CancelTimer") versteht und dann zurückmeldet, wann der ggf. abläuft. Geht nur mit Timern, die RHASSPY erstellt hat bzw. die dessen Namenskonvention folgen...

Die "üblichen" Zusätze für Räume und Label sind auch für die Abfrage erlaubt, und beim Testen bekommt man jetzt auch dafür eine Rückmeldung (wenn gesetzt, was über Tests nicht erfolgt).

[de.fhem:SetTimer]
[...]
wann klingelt{GetTimer} [<labels>{Label}] [<rooms>]
\[auf] wann{GetTimer} ist [<labels>{Label}] [<rooms>] ( gestellt | fällig | zu erwarten )


Da es eine neuen Antwort für "es gibt keinen passenden Timer" gibt, braucht dieses update einen Neustart (und eine passende de-cfg, wenn man es in DE haben will).
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 29 März 2022, 10:49:01
Cool!

Ein "stopp" wäre super, wenn der Timer klingelt. Aber ich weiß nicht, wie man das lösen könnte. Irgendwie hört Rhasspy nicht zu, während es Audio ausgibt.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 29 März 2022, 11:16:07
Zitat von: drhirn am 29 März 2022, 10:49:01
Cool!
...das stand jetzt lange genug unter "ToDo", ohne dass sich jemand anders dazu hätte breitschlagen lassen ;D - und da sowas in pah's Testsuite auftaucht, war es schwieriger, diese Anforderung zu ignorieren ::) ...

Allerdings ist mir gestern noch was raus:
- zum einen CancelTimer+Testmodus => wurde doch gelöscht...
- ein key in der de-cfg fehlt noch für "NoIntentRecognized"

Da ich wegen dem ersten Punkt sowieso nochmal ran musste, habe ich mir für die Tests dann auch noch "MediaChannels" und "Shortcuts" angesehen. Da auch dort die ggf. auszulösenden Aktionen über die zentralen internen Ausführungs-Routinen laufen, sollte es unproblematisch sein, nun auch diese Zweige für die Tests zu aktivieren. Damit müßte dann alles testbar sein, was intern abläuft :) .
Custom Intents gehen prinzipbedingt nicht zu testen, aber das sollte verschmerzbar sein.

Falls du zum Testen kommst, kannst du dir für den key in der de-cfg gerne was ausdenken und die gesammelten Werke einchecken. Weiß nicht, wann ich dazu komme.

Zitat
Ein "stopp" wäre super, wenn der Timer klingelt. Aber ich weiß nicht, wie man das lösen könnte. Irgendwie hört Rhasspy nicht zu, während es Audio ausgibt.
Nun ja, ohne input kein output... Das muss demnach außerhalb gelöst werden.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 29 März 2022, 11:23:24
Wie kann ich den "NoIntentRecognized" triggern?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 29 März 2022, 11:43:06
Zitat von: drhirn am 29 März 2022, 11:23:24
Wie kann ich den "NoIntentRecognized" triggern?
:)
Dazu muss der Input entweder über msgDialog (an einem RESIDENT/GUEST) kommen, oder über ein AMAD.*-Gerät. Ist eine Folge von
Zitat von: Beta-User am 28 März 2022, 09:49:09
Notizen an mich selbst:
- die "not recognized"-Fälle sollte man bei den "echten" Messenger-Fällen vermutlich auch noch gesondert mit einer Antwort bedenken, damit der Anfragende jedenfalls eine Rückmeldung bekommt;
Ist also für einen "nur-Rhasspy"-Nutzer gar nicht so ohne weiteres nachzustellen ;D ...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 29 März 2022, 11:44:36
Aha

Naja, habe mich für "Ich konnte leider keinen passenden Intent finden" entschieden und die beiden Files eingecheckt.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 29 März 2022, 13:29:23
Zitat von: Beta-User am 24 März 2022, 18:32:25
- GetState überarbeitet:
-- erlaubt es, beliebige Inhalte auszuwerten, indem in rhasspyMapping GetState mit einem type und einer stateFormat-artigen "response" angeben wird;
-- Status-Infos zu RHASSPY selbst können abgefragt werden (insbesondere auf den aktuellen Raum der Anfrage bezogen)

Kannst du das mal genauer erläutern bitte? Wie sieht z.B. dein Diesel-Preis Mapping aus?
Danke!
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 29 März 2022, 13:52:45
Zitat von: drhirn am 29 März 2022, 13:29:23
Kannst du das mal genauer erläutern bitte? Wie sieht z.B. dein Diesel-Preis Mapping aus?
Das sind eigentlich zwei bis 3 Themen...

"Diesel" ist eine "price"-Type-Anfrage, für die es in den fertigen Antwortsätzen eine Standardantwort gibt. Die Anfrage dazu sieht so aus:
was kostet{Type:price} (Diesel|Benzin:SuperE10|Super:SuperE5){Reading} [( in | an | bei )] $de.fhem.Device-info{Device}
Abgefragt wird (hier und im Moment) ein (gDT: info) HTTPMOD, der als Readings eben "Diesel", "SuperE10" und "SuperE5" kennt.

Richtig "frei" wird es, wenn man den Weg nimmt, wie im Wetter-Beispiel aus https://forum.fhem.de/index.php/topic,124240.msg1215241.html#msg1215241 (https://forum.fhem.de/index.php/topic,124240.msg1215241.html#msg1215241) aufgezeigt. Damit kann man dann im Prinzip völlig beliebige Abfragen und auch Infos/Readings von anderen Devices "vorlesen lassen", das "Reading" muss dann nicht mal exisitieren, sondern es genügt, wenn diese Bezeichnung als "Anker" im rhasspyMapping steht ;) .

Mein etwas ausgebauter Satz dazu:
wie ( ist | wird ){Type:heute} ( [das] wetter{Device} | [der] Wetterbericht{Device:wetter} [für] ) [ ( heute | morgen{Type:morgen} | übermorgen{Type:übermorgen} ) ]

Weiteres Beispiel dazu:
sind alle fenster{Type:openWindow} [und] [Türen] geschlossen{Device} 
ist irgendwo ein fenster{Type:openWindow} [oder eine tür] offen{Device:geschlossen}

führt zu folgendem monitoring-Device:
attr Fenster_monitoring genericDeviceType info
attr Fenster_monitoring rhasspyMapping GetState:type=openWindow,response=Es sind grade [Fenster_monitoring:allCount] Fenster und Türen offen.
attr Fenster_monitoring rhasspyName geschlossen


Antwort Teil 3 - RHASSPY-Abfragen sehen in etwa so aus:

(Wie kannst du mir helfen | was kannst du [alles] ){Type:generic}
(Was|welche geräte) kannst du [<rooms>] ( steuern | [(an|aus)] schalten ){Type:control}

(Ich habe grade noch ein paar weitere im Test (v.a. wegen Szenen), bin mir aber nicht sicher, ob/was davon genau schon funktioniert...).

Hoffe, es ist jetzt etwas klarer?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 29 März 2022, 13:58:25
Ja, jetzt klarer. Aber noch nicht ganz klar. Den Rest werde ich durch ausprobieren rausfinden ;)
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 29 März 2022, 14:00:30
Aaahhhmm, ich hab keinen GDT "info". Wo kommt der her?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 29 März 2022, 14:12:54
...den hat "jemand" "erfunden", weil ihm nichts besseres eingefallen ist...
Bin für Alternativ-Vorschläge offen, in RHASSPY ist das halt ein "Marker", über den die Auswertung gewisser setter (z.B. update, reread, reload) zugelassen wird und (prinzipiell) die Abfrage von STATE.
Meine "wie wird das wetter"-Abfrage war ursprünglich nur ein Verlesen des STATE, den ich via stateFormat passend formatiert hatte. Das ist in der Leseansicht aber unübersichtlicher als das, was Weather standardmäßig macht, und "morgen" etc. kann es auch nicht, was mich dann auf den "Trick" mit den Pseudo-Readings gebracht hat...

Jetzt sind wir aber eigentlich schon mitten drin in der "anderen" Diskussion, wie man die neuen Optionen denn jetzt sinnigerweise nutzt, und was ggf. noch fehlt...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 29 März 2022, 14:37:02
Zitat von: Beta-User am 29 März 2022, 14:12:54
...den hat "jemand" "erfunden", weil ihm nichts besseres eingefallen ist...
Bin für Alternativ-Vorschläge offen, in RHASSPY ist das halt ein "Marker", über den die Auswertung gewisser setter (z.B. update, reread, reload) zugelassen wird und (prinzipiell) die Abfrage von STATE.
Hehe
Ich find "info" eh gut. Hab mich nur gewundert, dass der in meiner inzwischen ewig langen Liste an GDTs nicht drinnen war.


ZitatJetzt sind wir aber eigentlich schon mitten drin in der "anderen" Diskussion, wie man die neuen Optionen denn jetzt sinnigerweise nutzt, und was ggf. noch fehlt...
Dazu fehlt mir noch die Info, was eigentlich alles und wie geht.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 29 März 2022, 14:53:39
Zitat von: drhirn am 29 März 2022, 14:37:02
Ich find "info" eh gut. Hab mich nur gewundert, dass der in meiner inzwischen ewig langen Liste an GDTs nicht drinnen war.
Bei mir gibt's keine vorgegebene Liste, aber verwendet wird halt nur das, was RHASSPY versteht...

Zitat
Dazu fehlt mir noch die Info, was eigentlich alles und wie geht.
Da sind wir zu zweit ;D ...

Im Ernst: Relativ viel bekommt man über pah's Testsuite raus, v.a., wenn man die "Raumbezogenheit" von RHASSPY mit berücksichtigt und "siteId2room_defhem" mal mit etwas unterschiedlichen Orten vor jedem Durchlauf befüllt.

Soweit ich das bisher beurteilen kann, kommt man dann v.a. zu folgenden Problemkreisen:
- Priorisierungen (kann der User entscheiden)
- "Mach heller", wenn es kein dimmbares angeschaltetes Gerät gibt*
- Szenenauswahl: was gibt es + Auswahldialog*
- Konfiguration von allgemeinen Abfragen; wie macht man das am cleversten...**

Vermutlich sollte ich jetzt mal meine vollständige GetStates-Sätze zeigen, dann kannst du aus der Differenz ggf. ableiten, wo grade mein Stand für Tests ist...:
[de.fhem:GetState]
query=<de.fhem:GetDate.query>
#[de.fhem:GetDate]
#query=( weißt du [bitte] | ( könntest | kannst ) du mir [bitte] sagen | sag mir [bitte] )
den=<de.fhem:SetOnOff.den>
rooms=<de.fhem:SetOnOff.rooms>
#rooms=([(im|in dem|auf dem|in der|auf der)] $de.fhem.Room{Room})
\[<query>] ( wie ist der status | ( sag | sage ) [mir] [bitte] ){State} [(vom | von ( dem | der ) | (den (Stand|Zustand) [von] ) )] $de.fhem.Device{Device} [<rooms> | $de.fhem.Room-info]
(erneuere | aktualisiere ){Update} <den> $de.fhem.Device-info{Device}
was kostet{Type:price} (Diesel|Benzin:SuperE10|Super:SuperE5){Reading} [( in | an | bei )] $de.fhem.Device-info{Device}
wie ( ist | wird ){Type:heute} ( [das] wetter{Device} | [der] Wetterbericht{Device:wetter} [für] ) [ ( heute | morgen{Type:morgen} | übermorgen{Type:übermorgen} ) ]
Welche ( Räume:rooms | (Szenen | Szenarien | Einstellungen):scenes){Type} kennst du [<rooms>]
Welche (Szenen | Szenarien | Einstellungen){Type:scenes} (kennt|kann) [(der | die | das)] $de.fhem.Device-scene{Device}
(Wie kannst du mir helfen | was kannst du [alles] ){Type:generic}
(Was|welche geräte) kannst du [<rooms>] ( steuern | [(an|aus)] schalten ){Type:control}
welche Informationen (kannst|kennst){Type:info} du [<rooms>] [( liefern | [an] sagen | nennen )]
sind alle fenster{Type:openWindow} [und] [Türen] geschlossen{Device} 
ist irgendwo ein fenster{Type:openWindow} [oder eine tür] offen{Device:geschlossen}


* wären Punkte, die man im Modul ggf. mit lösen muss, bei ** braucht es ggf. zusätzlich eben noch weitere Klärung, was überhaupt in welcher Form Sinn macht...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 29 März 2022, 15:48:57
Muss ich mir ansehen.

Mal was anderes: Ich hab ja - wie du - ein HM Thermostat. Da würde ich gerne die aktuelle Temperatur und die aktuelle Solltemperatur abfragen. Also bei _Weather und _Climate jeweils ein GetNumeric Mapping erstellt. rhasspyName bei _Weather ist "temperatur", bei _Climate "heizung".
Frage ich jetzt nach "wie warm ist es im wohnzimmer" fragt mich RHASSPY:

{"text": "Es kommen mehrere Geräte in Frage, bitte wähle zwischen heizung oder temperatur", "siteId": "wohnzimmer", "lang": null, "id": "a60147f4-f306-478f-86ad-1aea2d5cd6b5", "sessionId": "wohnzimmer-porcupine_raspberry-pi-bf42a432-1d59-4bfd-80f9-cca98b9de2b6", "volume": null}

Will ich zwar nicht die Frage, bekomm sie aber auch nicht weg.
Meine Anwort "temperatur" liefert dann aber:

{"text": "färbe temperatur rot", "likelihood": 0.46558900000000003, "seconds": 3.9034894359938335, "siteId": "wohnzimmer", "sessionId": "wohnzimmer-porcupine_raspberry-pi-bf42a432-1d59-4bfd-80f9-cca98b9de2b6", "wakewordId": null, "asrTokens": [[{"value": "färbe", "confidence": 0.994153, "rangeStart": 0, "rangeEnd": 6, "time": {"start": 0.0104221, "end": 2.96268}}, {"value": "temperatur", "confidence": 1.0, "rangeStart": 6, "rangeEnd": 17, "time": {"start": 2.96268, "end": 3.55}}, {"value": "rot", "confidence": 0.477236, "rangeStart": 17, "rangeEnd": 21, "time": {"start": 3.55011, "end": 4.14}}]], "lang": null}

und das ganze bricht mit einem IntentNotRecognized ab. Lange danach kommt dann: "Tut mir leid, da hat etwas zu lange gedauert."

Mir scheint, RHASSPY will da einen Intent zur Fragebeantwortung. Gibt's natürlich nicht.

Frage 1: Hast du eine Ahnung, was da bei mir falsch eingestellt ist?
Frage 2: Wie schaff ich's, dass ich die Abfrage, welches Gerät ich will, wegbekomme?

---EDIT---
Ad 2: Hihi, mit getState  ;D. Aber das kann nicht die Lösung sein
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 29 März 2022, 16:17:49
Hmm, also:

"wie ist die wunschtemperatur vom heizkörper südwest" liefert mir was anderes wie "wie ist die temperatur vom heizkörper südwest"
Intent dazu sieht so aus:
[de.fhem:GetNumeric]
query=<de.fhem:GetDate.query>
\[<query>] [wie [ist [die]]] ((Solltemperatur | Wunschtemperatur | Zieltemperatur){Type:desired-temp} | ( warm | kalt | heiß | Temperatur ){Type:temperature}) [ist es | von | vom | ist ] (<de.fhem:SetOnOff.rooms> | [das] ($de.fhem.Device-thermostat | $de.fhem.Device-thermometer ){Device})


Der "Trick" ist: Es gibt beide Temperaturen im _Clima-Channel, beide Abfragen gehen also an dasselbe Device, aber auf ein anderes Reading.

Andere Variante: "eigentlich" verbirgt sich hinter der Solltemperatur nur ein externer (BT-) Sensor, dessen Wert dann als virtueller peer in _Climate landet (da kommt die Antwort aber auch tatsächlich her, wenn man so konkret fragt). Die "normale Abfrage" "wie warm ist es (im wohnzimmer)" landet via priority-Setting (rhasspySpecials) auf diesem Gerät,  die Soll-Temperatur käme dann von einem anderen (mit dem o.g. geteamten) RT-DN:

Raumfuehler_Wohnzimmer => priority:inRoom=temperature
Thermostat_Wohnzimmer_SSO_Clima =>  priority:inRoom=desired-temp


Ach so: Sowohl die Thermostate wie der BT-Sensor haben keine explizit gesetzten rhasspyMappings, das kommt aus gDT "thermostat" bzw. "thermometer".

Nachtrag noch:
Vergleichbares für einen Wandthermostaten (_Climate-Channel):Thermostat_EssZi_Climate => priority:inRoom=desired-temp,temperature,humidity
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 29 März 2022, 17:39:04
Danke. rhasspySpecials war die Lösung! Hatte ich probiert, wusste aber nicht, wie man das richtig verwendet.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 29 März 2022, 17:45:18
Wo kann man sich beim RHASSPY (B.A.) einschreiben?  8)
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 29 März 2022, 17:56:45
Haha. Frag pah ;)
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 29 März 2022, 18:04:47
Zitat von: JensS am 29 März 2022, 17:45:18
Wo kann man sich beim RHASSPY (B.A.) einschreiben?  8)
https://forum.fhem.de/index.php/topic,126913.0.html (https://forum.fhem.de/index.php/topic,126913.0.html)  :P

(Zugegeben, meine sentences sind jetzt "reichlich abgefahren"...)

Zitat von: drhirn am 29 März 2022, 17:39:04
Danke. rhasspySpecials war die Lösung! Hatte ich probiert, wusste aber nicht, wie man das richtig verwendet.
Vorschläge zur Doku sind willkommen...

An der "SetTimer"/"GetTimer"-Doku habe ich geringfügig geschraubt, und mit der angehängten Fassung scheint auch die Raum- und Szenenanfrage was vernünftiges zu liefern 8) . (Nur nicht auf meinem Hauptsystem, da hat es bei meinem einzigen Szenen-Gerät die Szenen verschluckt, warum auch immer...).
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 29 März 2022, 18:20:48
Weshalb integrierts du GetTimer in SetTimer? Eine Trennung in Set- und Get-Intents, wie bei SetOnOff/GetOnOff, wäre nachvollziehbar und würde einer gewissen Ordnung entsprechen.
Man muss zu viel Hintergrundwissen anhäufen, um RHASSPY richtig zu konfigurieren...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 29 März 2022, 18:21:53
Zitat von: JensS am 29 März 2022, 18:20:48
Weshalb integrierts du GetTimer in SetTimer? Eine Trennung in Set- und Get-Intents, wie bei SetOnOff/GetOnOff, wäre nachvollziehbar und würde einer gewissen Ordnung entsprechen.

Den Gedanken hatte ich auch schon. Ich würde also Jens mit der Meinung unterstützen.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 30 März 2022, 07:45:04
 ;D Der Grund ist relativ einfach: Den Code gab's grad fast umsonst second hand bei ebay...

Würde vorschlagen, hier nicht die Umleitung über "GetTimer" zu nehmen, sondern den umgekehrten Weg zu gehen und den ganzen Intent generisch zu benennen ("Timer").
Hintergrund wäre der Gedanke, den  eventuell dann noch aufzubohren ;) , und zwar um die Möglichkeit, generischen Code anzuflanschen: "welche Termine habe ich heute", "wer hat heute/demnächst Geburtstag", "wann kommt die Müllabfuhr"....
Das ginge zwar auch über GetState, allerdings gibt es da bisher keine Möglichkeit, Perl-Code anzuflanschen. Braucht man mAn. aber für sowas, und ich bin  nicht sicher, ob es sinnvoller wäre, das bei GetState zu erlauben (da ist es auch eine Frage der Syntax).

Meinungen dazu?

Was die Benennung von Intents angeht, gleich eine weitere Sache: Prinzipiell stellt sich auch die Frage, ob es nicht sinnvoller wäre, die Abfragen ChoiceRoom und ChoiceDevice zusammenzulegen und einen "Einheits-" Choice-Intent zu schaffen. Zum einen hatte ich nie an Szenen gedacht, zum anderen ist das Deaktivieren der Intents aufwändig und bzgl. der eigentlich beabsichtigten Begrenzung der Erkennung ja bekanntermaßen auch nicht im erhofften Maß zielführend...
Dazu kommt, dass eine etwas generalisierte Antwortmöglichkeit vermutlich intuitiver zu "besprechen" ist, also der Sprechende ggf. sogar mehr (oder andere) Infos liefert als vorgesehen ("ich hätte gerne die deckenlampe im esszimmer").

Meinungen dazu?



Den Grund für die verlorenen scenes bei meinem Verstärker habe ich vermutlich auch identifiziert: Da ist RHASSPY einfach schneller wie YAMAHA_AVR mit der Bereitstellung der setter. Es muss wohl eine 2. Schleife für die devicemap-Erstellung nach FHEM-Start her...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 30 März 2022, 10:41:52
Bin nach wie vor für eine Trennung in Set und Get. Sonst werden die sentence-Files irgendwann unübersichtlich. Aber grundsätzlich bin ich da sehr situationselastisch.

Kann Timer eh nicht verwenden, solange uns keine schlaue Lösung für das "Satellitengruppen-Problem" einfällt.

Bzgl. Scenes wusste ich gar nicht, dass man die jetzt überhaupt steuern kann. Und auch nicht, wie. ;)
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 30 März 2022, 12:20:48
Zitat von: drhirn am 30 März 2022, 10:41:52
Bin nach wie vor für eine Trennung in Set und Get. Sonst werden die sentence-Files irgendwann unübersichtlich. Aber grundsätzlich bin ich da sehr situationselastisch.
...jedem sein Himmelreich ::) ...

Bin da relativ leidenschaftslos, für den ersten Wurf war es erst mal wichtiger, überhaupt Code zu haben, und da waren es einfach recht moderate Eingriffe, um das ans Laufen zu bringen.
Habe jetzt schlicht (ungetestet) die "Umleitungen" auf "Timer" eingebaut, dann kann es jeder halten, wie er will. Ich finde die Trennung komplett unnötig, da für alle "Timer"-Varianten dieselben Variablen (Textbausteinchen, v.a. "Label") gebraucht werden und ich die dafür erforderlichen Referenzierungen in sentences.ini nicht toll finde. Eine Leerzeile reicht mir, um optisch zu erfassen, dass es da um was anderes geht...

Zitat
Kann Timer eh nicht verwenden, solange uns keine schlaue Lösung für das "Satellitengruppen-Problem" einfällt.
Bevor ich jetzt lange in den Untiefen diverser Threads suche: Kannst du mir da schnell mal (wieder ::) ) auf's Pferd helfen? vielleicht fällt mir ja jetzt was ein...?

Zitat
Bzgl. Scenes wusste ich gar nicht, dass man die jetzt überhaupt steuern kann. Und auch nicht, wie. ;)
Hmmm, den SetScene-Intent gibt es ja gefühlt schon ewig, und ich meine auch, dass wir den ausgetestet gehabt hätten. Ich habe das in der Praxis allerdings nicht wirklich genutzt, vermutlich weil es in die Kategorie "warum funktioniert das eigentlich manchmal nicht?!?" gefallen war und auch sonst keiner großes Interesse an dem Thema gehabt zu haben schien...
Zwischenzeitlich ist mir auch klar warum, siehe letzten Beitrag ::) . Mein Testgerät ist zu langsam mit seiner eigenen Initialisierung...
Dazu kommt, dass es bisher auch mangels Nachfrage keinen gDT "scene" gab ("scene" scheint für sowas allgemein gebräuchlich zu sein?).

Der Ablauf ist der, dass RHASSPY Rhasspy mit "sprechbaren Namen" für jede Szene versorgt und die dann unter dem key "Scene" zurückliefert. RHASSPY macht dann den Versuch, das einer "technischen Szene" zuzuordnen, wie unter "set" am Device zu finden.

Aktueller rudimentärer "Satz" zum Testen:

[de.fhem:SetScene]
<de.fhem:SetOnOff.cmdmulti> <de.fhem:SetOnOff.den> $de.fhem.Device-scene{Device} [<de.fhem:SetOnOff.rooms>] auf [ ( die Szene | den Modus ) ] $de.fhem.Scenes [Modus]
"stelle den Verstärker auf den Musik hören modus" oder "stelle den Verstärker auf Musik hören" führen bei mir mit der Version von gestern (nach manuellem devicemap-update) zu "set Yamaha_Main scene scene1"

rhasspySpecials dazu sehen wie folgt aus:
scenes:scene1="Musik hören" scene2="Film ansehen" scene3=none scene4="vorderen Eingang auswählen"
priority: inRoom=volume outsideRoom=volume,scene
confirm: SetOnOff="wirklich $target $Value schalten?" SetScene

Na ja, anbei jedenfalls der in größeren Teilen ungetestete Versuch, das eine oder andere zu fixen bzw. zu ergänzen:
- "Timer" intent und "Derivate"
- "Choice" intent und die bisherigen beiden als "Derivate" (noch nicht irgendwo direkt verwendet)
- Initialisierungs-Timer für "langsame Klienten" (2 Minuten).
- gDT "scene", (Erwähnung in den zugelassenen gDT der commandref)
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 30 März 2022, 15:49:59
Zitat von: Beta-User am 30 März 2022, 12:20:48
Bin da relativ leidenschaftslos, für den ersten Wurf war es erst mal wichtiger, überhaupt Code zu haben, und da waren es einfach recht moderate Eingriffe, um das ans Laufen zu bringen.
Mach, wie du meinst. Wenn's jemandem nicht passt, kann er ja jederzeit einen Patch liefern.

Zitatda für alle "Timer"-Varianten dieselben Variablen (Textbausteinchen, v.a. "Label") gebraucht werden und ich die dafür erforderlichen Referenzierungen in sentences.ini nicht toll finde. Eine Leerzeile reicht mir, um optisch zu erfassen, dass es da um was anderes geht...
Das ist natürlich auch wieder wahr.

ZitatBevor ich jetzt lange in den Untiefen diverser Threads suche: Kannst du mir da schnell mal (wieder ::) ) auf's Pferd helfen? vielleicht fällt mir ja jetzt was ein...?
Das Problem ist, wenn ich gruppierte Satelliten habe (wohnzimmer.01, wohnzimmer.02), weiß RHASSPY nicht, an welchen Satelliten es dann den Timerablauf schicken soll. Weil die siteId "wohnzimmer" ist. Und man kann natürlich auch nicht aus einem anderen Raum einen Timer im Wohnzimmer stellen. RHASSPY müsste also wissen, welche siteIDs es in welchen Raum gibt. Und dann für die Ausgabe per Zufall einen auswählen bzw. auf ein "Special" hören.

ZitatHmmm, den SetScene-Intent gibt es ja gefühlt schon ewig, und ich meine auch, dass wir den ausgetestet gehabt hätten.
Tatsache. Der steht sogar im README in GitHub. Ohne Text ;D.
Aber deine Code-Beispiele haben in der Tat gerade meine grauen Zellen geweckt. Da war mal was...
Probier ich gleich nochmal.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 30 März 2022, 16:02:03
Oh Mann, ich hatte sogar einen SetScenes-Intent in den sentences. Ich werd echt alt...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 30 März 2022, 16:41:23
Zitat von: drhirn am 30 März 2022, 16:02:03
Ich werd echt alt...
Ich bin es schon...

Die SuFu hat dann auch einen Treffer zu dem room2siteId-Thema geliefert.

Anbei der Versuch, das irgendwie zu lösen, ich kann aber für nix garantieren. Habe dazu eine Funktion reingewurstelt, die bei "speak" und "playWav" dann checken müßte, ob es eine explizite Zuweisung seitens des Users gibt (via Reading, siehe Readings-Beschreibung am Ende der commandref), ob es dafür einen 100%-Match in siteIds gibt oder ob wenigstens der "Startanteil" darin zu finden ist, und dann dasselbe nochmal veranstaltet für die ursprünglich übergebene siteId. Erst wenn darüber nichts gefunden wird, wird halt einfach die übergebene siteId verwendet (also im schlechtesten Fall der Raumname wie bisher).

Ansonsten habe ich noch eine "Durchbrechung" des Set/Get-Prinzips gemacht, indem bei SetScene jetzt ein Schlüssel {Get:scenes} einen Auswahldialog öffnen sollte, der verliest, was es am angefragten Device so alles gibt (braucht wieder einen update der de-cfg).

Bin selbst mal gespannt, ob das alles so reibungslos durchläuft, ist ausdrücklich experimentell!
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 30 März 2022, 16:58:33
Nope, leider.

hermes/tts/say:
{"text": "Taimer im Raum wohnzimmer ist gestellt auf 15 Sekunden", "siteId": "wohnzimmer.pc", "lang": null, "id": "ca732039-4784-41ed-bf6c-31006578fd8a", "sessionId": "wohnzimmer.pc-porcupine_raspberry-pi-3688bf24-5a42-4ab9-b24b-7b5abf5bcc25", "volume": null}

hermes/dialogueManager/startSession:
{"init":{"canBeEnqueued": true,"customData": "de.fhem","text": "Taimer abgelaufen","type": "notification"},"siteId": "wohnzimmer"}

Reading ist gesetzt:
room2siteId_wohnzimmer.pc wohnzimmer
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 30 März 2022, 17:01:48
Zitat von: Beta-User am 30 März 2022, 16:41:23
Ansonsten habe ich noch eine "Durchbrechung" des Set/Get-Prinzips gemacht, indem bei SetScene jetzt ein Schlüssel {Get:scenes} einen Auswahldialog öffnen sollte, der verliest, was es am angefragten Device so alles gibt (braucht wieder einen update der de-cfg).

Du meinst so?
(was für szenen kennst du){Get:scenes} im $de.fhem.Room{Room}

Meldet bei mir: "Ich habe leider zu wenig Daten um den Vorgang auszuführen"
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 30 März 2022, 17:24:43
Das mit room2siteId ist anders rum gemeint:
room2siteId_wohnzimmer wohnzimmer.pc
Was steht im Reading "siteIds"?

Zitat von: drhirn am 30 März 2022, 17:01:48
Du meinst so?
(was für szenen kennst du){Get:scenes} im $de.fhem.Room{Room}

Meldet bei mir: "Ich habe leider zu wenig Daten um den Vorgang auszuführen"
Das ist als Device-Abfrage konzipiert, muss mal schauen, ob das überhaupt klappen kann, wenn man kein Device angibt (_vielleicht_ ginge das, wenn es im Raum nur ein Szenen-Gerät gibt).

Versuch's mal damit:
Welche (Szenen | Szenarien | Einstellungen){Get:scenes} (kennt|kann) [(der | die | das)] $de.fhem.Device-scene{Device}
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 30 März 2022, 18:16:26
Zitat von: Beta-User am 30 März 2022, 17:24:43
Was steht im Reading "siteIds"?

Grummel. Jetzt
mobile-app6,wohnzimmer.pc,wohnzimmer.sofa,vorraum,küche,schlafzimmer,defhem
Vorher war da noch "wohnzimmer" dabei.

Ich hab jetzt im Wohnzimmer (wo ich allerdings derzeit nur einen Satelliten habe) und von der App aus getestet. Und beide Male kam die Ansage aus dem richtigen Satelliten. Braucht noch mehr Tests, aber sieht mal gut aus.
Ach ja, weil's eh falsch war, hab ich vor den Tests das Reading room2siteId_ wieder gelöscht.

Zitat
Versuch's mal damit:
Welche (Szenen | Szenarien | Einstellungen){Get:scenes} (kennt|kann) [(der | die | das)] $de.fhem.Device-scene{Device}
Immer noch zuwenig Daten.

Nur zur Sicherheit, ich rede von folgender LightScene:

defmod lightSceneWz LightScene HUEBridge_HUEDevice5 enoAcLightWzTable [...]
attr lightSceneWz genericDeviceType scene
attr lightSceneWz rhasspyMapping SetOnOff:cmdOn=set lightSceneWz scene AllesAn,cmdOff=set lightSceneWz scene AllesAus
attr lightSceneWz rhasspyName Licht,beleuchtung
attr lightSceneWz rhasspyRoom Wohnzimmer
attr lightSceneWz rhasspySpecials scenes:scene1="Alles an" scene2="Alles aus" scene3="Computerlicht" scene4="Esslicht"
attr lightSceneWz room Rhasspy,System->Devices



{"Device":"licht","Get":"scenes","confidence":1,"customData":"porcupine_raspberry-pi","input":"Welche scenes kennt das licht","intent":"SetScene","lang":null,"rawInput":"welche szenen kennt das licht","requestType":"voice","sessionId":"wohnzimmer.pc-porcupine_raspberry-pi-a1dbe020-a512-4c1c-895f-ebb9be832997","siteId":"wohnzimmer.pc"}
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 30 März 2022, 18:37:06
Soooo, hab jetzt auch noch einen zweiten Satelliten angeschlossen und von der App aus einen Timer gestelllt. Was soll ich sagen, Antwort kommt aus einem Satelliten im Wohnzimmer. Sehr cool!
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 31 März 2022, 09:31:49
Zitat von: drhirn am 30 März 2022, 18:37:06
Soooo, hab jetzt auch noch einen zweiten Satelliten angeschlossen und von der App aus einen Timer gestelllt. Was soll ich sagen, Antwort kommt aus einem Satelliten im Wohnzimmer. Sehr cool!
8) .

Dann wird wohl auch das (jetzt besser beschriebene) Reading helfen...
Reading, damit man das ohne weiteres auch zur Laufzeit ändern kann (z.B. wenn man per PRESENCE feststellt, dass ein Satellit weg ist).

(OT: Das wirft die Folgefrage auf, wie man eigentlich eine Erinnerung nicht an einen Raum "zustellt", sondern an einen "Sprecher"...)

Zitat von: drhirn am 30 März 2022, 18:16:26
Immer noch zuwenig Daten.
(Leider) logisch, die Initialprüfung im Intent kannte diesen "Sonderfall" noch nicht. Update ist im svn.



Ansonsten wirft dein Beitrag eine ganze Reihe von Fragen auf...

- ist für "alle an/aus" SetScene (vial LightScene) eigentlich der "richtige" Intent/die beste Methode? (Hier läuft das über OnOffGroup)
- warum wird das Device überhaupt noch für SetScene erkannt, wenn es ein rhasspyMapping gibt (ohne SetScene)?
- wie erklärt man das mit den Specials zu diesem Punkt am besten... (die Nummerierung aus dem YAMAHA_AVR-Beispiel scheint irreführend zu sein)?

Vermutlich wird das klarer, wenn wir uns mal devicemap ansehen, einmal mit dem ausdrücklichen rhasspyMapping, einmal mit dem, was (jetzt hoffentlich) automatisch erkannt wird, wenn das gelöscht war.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 31 März 2022, 11:07:56
Zitat von: Beta-User am 31 März 2022, 09:31:49
(OT: Das wirft die Folgefrage auf, wie man eigentlich eine Erinnerung nicht an einen Raum "zustellt", sondern an einen "Sprecher"...)
Was meinst du damit?

Zitat(Leider) logisch, die Initialprüfung im Intent kannte diesen "Sonderfall" noch nicht. Update ist im svn.
Welchen Sonderfall?

Zitat- ist für "alle an/aus" SetScene (vial LightScene) eigentlich der "richtige" Intent/die beste Methode? (Hier läuft das über OnOffGroup)
In meinem Fall ja. Ich handle alles im Wohnzimmer über LightScene ab. Da wird nie eine einzelne Lampe geschalten. Und wenn ich die Szenen eh schon habe, warum soll ich für RHASSPY was neues erfinden?

Zitat- warum wird das Device überhaupt noch für SetScene erkannt, wenn es ein rhasspyMapping gibt (ohne SetScene)?
Warum nicht? GDT "scene" ist ja da. Ich dachte, eigene rhasspy*-Attribute ergänzen/ersetzen GDTs einfach

Zitat- wie erklärt man das mit den Specials zu diesem Punkt am besten... (die Nummerierung aus dem YAMAHA_AVR-Beispiel scheint irreführend zu sein)?
Kann ich nicht sagen, weiß nicht, wie sie funktionieren sollen ;D

Zitat
Vermutlich wird das klarer, wenn wir uns mal devicemap ansehen, einmal mit dem ausdrücklichen rhasspyMapping, einmal mit dem, was (jetzt hoffentlich) automatisch erkannt wird, wenn das gelöscht war.
Also, aktuell sieht das so aus. GDT "scene", rhasspyChannels und rhasspyMapping gesetzt:

         lightSceneWz:
           alias      licht
           names      licht,beleuchtung
           rooms      wohnzimmer
           Channels:
             Computerlicht set lightSceneWz scene Computerlicht
             Esslicht   set lightSceneWz scene Esslicht
             Fernsehlicht set lightSceneWz scene Fernsehlicht
             Helles Licht set lightSceneWz scene HellesLicht
             Schlummerlicht set lightSceneWz scene Schlummerlicht
           intents:
             SetOnOff:
               SetOnOff:
                 cmdOff     set lightSceneWz scene AllesAus
                 cmdOn      set lightSceneWz scene AllesAn
                 type       SetOnOff
             SetScene:
               SetScene:
                 AllesAn    AllesAn
                 AllesAus   AllesAus
                 Computerlicht Computerlicht
                 DunklesFernsehlicht DunklesFernsehlicht
                 Esslicht   Esslicht
                 Fernsehlicht Fernsehlicht
                 HellesLicht HellesLicht
                 Nachtlicht Nachtlicht
                 Schlummerlicht Schlummerlicht
                 cmdBack    previousScene
                 cmdFwd     nextScene


Entferne ich rhasspyChannels und rhasspyMapping sieht das so aus:

         lightSceneWz:
           alias      licht
           names      licht,beleuchtung
           rooms      wohnzimmer
           intents:
             SetScene:
               SetScene:
                 AllesAn    AllesAn
                 AllesAus   AllesAus
                 Computerlicht Computerlicht
                 DunklesFernsehlicht DunklesFernsehlicht
                 Esslicht   Esslicht
                 Fernsehlicht Fernsehlicht
                 HellesLicht HellesLicht
                 Nachtlicht Nachtlicht
                 Schlummerlicht Schlummerlicht
                 cmdBack    previousScene
                 cmdFwd     nextScene
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 31 März 2022, 11:32:54
Zitat von: drhirn am 31 März 2022, 11:07:56
Was meinst du damit?
Nun ja, ggf. will der "Einsprecher" ja eigentlich gar keine Erinnerung in einem bestimmten Raum haben, sondern z.B. an einen ROOMMATE, und zwar da, wo der grade (zum Zeitpunkt der Erinnerung) halt ist. Dann kann das Ausgabegerät eben ein Rhasspy-Satellit sein, oder eine Telegram-Message, email, whatever...
(Geht aber vermutlich, sowas mit Bordmitteln umzusetzen, wenn man den betreffenden Trigger abgreift, den es ja nach Ablauf des Timers auch noch gibt...)

Zitat
Welchen Sonderfall?
"Get"-Key innerhalb von "SetScene". Bisher war dieser Intent davon ausgegangen, dass er zwingend eine {Scene} bekommt. Aus dieser Perspektive betrachtet ist die Abfrage eben ein "Gänsefüßchen"-Sonderfall ;) .

Zitat
In meinem Fall ja. Ich handle alles im Wohnzimmer über LightScene ab. Da wird nie eine einzelne Lampe geschalten. Und wenn ich die Szenen eh schon habe, warum soll ich für RHASSPY was neues erfinden?
Berechtigte Frage. Es gibt vermutlich auf die Frage des "wie löst man das am geschicktesten" auch nicht "die" Antwort. Ich _glaube_, dass "alles aus" besser über SetOnOffGroup gelöst werden kann, aber das ist neben dem, was man schon hat und kennt wohl auch eine Geschmacksfrage :) .

Zitat
Warum nicht? GDT "scene" ist ja da. Ich dachte, eigene rhasspy*-Attribute ergänzen/ersetzen GDTs einfach
Schon. Aber eigentlich "komplett verdrängend". Muss mir anschauen, was da (so meine Bewertung) schief läuft. SetScene sollte es nicht geben, wenn es nicht in rhasspyMapping auftaucht!

Zitat
Kann ich nicht sagen, weiß nicht, wie sie funktionieren sollen ;D
In etwa so (weiß nicht, ob das mit den daddeln-Alternativen klappt):
attr lightSceneWz rhasspySpecials scenes:Fernsehlicht="Kino zu zweit" Computerlicht="(Computer spielen | daddeln)" DunklesFernsehlicht=none Nachtlicht="das ist irgendwas sprechbares für diese szene"

=> "stell das licht im wohnzimmer auf daddeln"

Ob in diesem setting dann rhasspyChannels noch Sinn macht, sei mal dahingestellt...

Hoffe, das ist nun etwas klarer?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 31 März 2022, 11:49:52
Zitat von: Beta-User am 31 März 2022, 11:32:54
In etwa so (weiß nicht, ob das mit den daddeln-Alternativen klappt):
attr lightSceneWz rhasspySpecials scenes:Fernsehlicht="Kino zu zweit" Computerlicht="(Computer spielen | daddeln)" DunklesFernsehlicht=none Nachtlicht="das ist irgendwas sprechbares für diese szene"

=> "stell das licht im wohnzimmer auf daddeln"

Also, für ganz Dumme wie mich:
attr lightSceneWz rhasspySpecials scenes:<Name der Szene>=<frei gewählter Text der gesprochen wird> ...
Korrekt?
Und verstehe ich richtig, dass "none" bedeutet, dass alles Szenen der Reihe nach aufgelistet werden müssen? Und "none" dann einfach die Szene "ausschließt"?

ZitatOb in diesem setting dann rhasspyChannels noch Sinn macht, sei mal dahingestellt...
Natürlich nicht :D
Ich teste ja nur. Und das ist die einzige lightScene, die ich habe. In der Praxis wird bei mir trotzdem rhasspyChannels bleiben. Ich gebe gerne kurze, knackige Kommandos. "Porcupine, Computerlicht" ist ein bisschen kürzer als "Porcupine, stell das Licht auf die Szene Computerlicht" ;)

--edit---
Wobei der kurze Befehl eigentlich auch mit SetScene lösbar sein sollte .. Nein
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 31 März 2022, 12:17:27
Zitat von: drhirn am 31 März 2022, 11:49:52
Korrekt?
Soweit paßt das.

Zitat
Und verstehe ich richtig, dass "none" bedeutet, dass alles Szenen der Reihe nach aufgelistet werden müssen? Und "none" dann einfach die Szene "ausschließt"?
Eine bestimmte Reihenfolge ist nicht erforderlich, "none" wirft die Szene einfach aus der Erkennung (mein Verstärker hat 4 "scene"-Einstellungen, ich brauche davon aber nur 3). "all=none" ist durch das Special "blacklistIntents" eigentlich überflüssig geworden, aber sowas wie "rest=none" könnte man noch überlegen).

Prinziell ist es so, dass das "frei gewählter Text" als Teil des betreffenden Slots an Rhasspy geschickt wird und direkt eben der technischen scene-Bezeichnung für den {Scene}-Key zugeordnet wird. Ausgenommen sind nur die "vor/zurück"-Kommandos, das muss man selbst in sentences.ini reinnehmen (Status: ungetestet).

ZitatIch gebe gerne kurze, knackige Kommandos.
Hmm, das Problem dabei ist: eine gewisse Grundlänge sollten sie haben, sonst wird das schnell zu mehrdeutig, und SetScene muss auch ein Device identifizieren können (derzeit noch ohne versucht zu haben, das über den Raum abzuleiten), aber "licht für computer" sollte heute schon möglich sein...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 31 März 2022, 12:20:26
Zitat von: Beta-User am 31 März 2022, 12:17:27
Hmm, das Problem dabei ist: eine gewisse Grundlänge sollten sie haben, sonst wird das schnell zu mehrdeutig
Jup. Nachdem das die einzigen Kommandos sind, die ich an Rhasspy schicke, geht das aber gut ;D

Zitatund SetScene muss auch ein Device identifizieren können (derzeit noch ohne versucht zu haben, das über den Raum abzuleiten), aber "licht für computer" sollte heute schon möglich sein...
Ja, das geht.

Bekomme ich die "vor/zurück"-Szenen irgendwie weg wenn ich sie nicht brauche?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 31 März 2022, 12:45:56
Zitat von: drhirn am 31 März 2022, 12:20:26
Jup. Nachdem das die einzigen Kommandos sind, die ich an Rhasspy schicke, geht das aber gut ;D
...vielleicht... Ich hätte den leisen Verdacht, dass zu kurze sentences-Sequenzen mit die Ursache dafür sind, dass "Fernseh-Kauderwelsch" als Kommando interpretiert wird ;) ... Mangels Einsatz von Hotword kann ich dazu aber nicht viel aus eigener Anschauung beitragen ::) .

Zitat
Ja, das geht.
...das ist doch schon mal was...
Muss mal schauen, ob wir den Intent noch dahingehend verbessert bekommen, dass das matching auch (nur) über den Raum geht (wobei man die Szenenbezeichnung dann ja zusätzlich hat und darüber sogar noch zwischen verschiedenen Devices unterscheiden könnte!)...

Zitat
Bekomme ich die "vor/zurück"-Szenen irgendwie weg wenn ich sie nicht brauche?
Hmmm, also...
Das ist noch recht "jung", aber ein kurzer Test mit "cmdFwd:none" sagt: ja, geht ;) . (Und eine Idee, wie man das aus GetState rausbekommt, habe ich auch).

Muss mir aber generell was dazu überlegen, bin noch nicht sicher, wie das mit diesem Intent insgesamt weitergehen soll. Du siehst ja an meinen eher zögerlichen Antworten, dass das auch bei mir eher noch in der Erprobungsphase ist...
Generell finde ich das aber eine sehr generische Lösung für "alles mögliche", von daher dürfte es lohnenswert sein, da noch etwas mehr zu tüfteln.



Merkposten an mich selbst noch:
Aus einem "generischeren Choice"-Intent heraus sollte sich übrigens auch ableiten lassen, ob ggf. ein anderer Intent gemeint war.



Den "override"-Schalter für rhasspyMapping verdrängt Automatik habe ich übrigens gefunden, stellt sich die Frage, ob man es "scharf schalten" sollte. Meinungen?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 31 März 2022, 13:31:26
Zitat von: Beta-User am 31 März 2022, 12:45:56
...vielleicht... Ich hätte den leisen Verdacht, dass zu kurze sentences-Sequenzen mit die Ursache dafür sind, dass "Fernseh-Kauderwelsch" als Kommando interpretiert wird ;) ... Mangels Einsatz von Hotword kann ich dazu aber nicht viel aus eigener Anschauung beitragen ::) .
Ist wirklich so. Deswegen wird bei mir auch die Hotword-Erkennung abgeschaltet, wenn der TV ein geht ;D
Andererseits, gestern hat sich die Heizung auf 11° gestellt, während ich telefoniert habe. Und dazu braucht's schon einen längeren Satz. Also nur kurze Sätze sind nicht schuld.

ZitatDas ist noch recht "jung", aber ein kurzer Test mit "cmdFwd:none" sagt: ja, geht ;) . (Und eine Idee, wie man das aus GetState rausbekommt, habe ich auch).
Geht wirklich. Perfekt!

ZitatMuss mir aber generell was dazu überlegen, bin noch nicht sicher, wie das mit diesem Intent insgesamt weitergehen soll. Du siehst ja an meinen eher zögerlichen Antworten, dass das auch bei mir eher noch in der Erprobungsphase ist...
Generell finde ich das aber eine sehr generische Lösung für "alles mögliche", von daher dürfte es lohnenswert sein, da noch etwas mehr zu tüfteln.
Laut den FHEM Statistiken wird lightScene überraschend selten verwendet (LightScene/444/1209). Hätte ich auf mehr getippt. Ich find's schon cool. Aber gebraucht wird's nicht unbedingt. rhasspyChannels wäre ja ein Ersatz.

ZitatDen "override"-Schalter für rhasspyMapping verdrängt Automatik habe ich übrigens gefunden, stellt sich die Frage, ob man es "scharf schalten" sollte. Meinungen?
Mag sein, dass wir gerade aneinander vorbei reden. Ich war der Meinung, GDT legt Regeln fest. Solange kein Mapping da steht. Ist eines da, überschreibt (bzw. ergänzt) das die GDT-Regeln. Und das finde ich eigentlich sehr gut so. Und bisher war ich der Meinung, das funktioniert auch genau so. Zumindest ist mir nichts anderes aufgefallen.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 31 März 2022, 13:49:28
Zitat von: drhirn am 31 März 2022, 13:31:26
Ist wirklich so. Deswegen wird bei mir auch die Hotword-Erkennung abgeschaltet, wenn der TV ein geht ;D
Andererseits, gestern hat sich die Heizung auf 11° gestellt, während ich telefoniert habe. Und dazu braucht's schon einen längeren Satz. Also nur kurze Sätze sind nicht schuld.
Na ja, ich weiß ja nicht, was du mit deinem Heizungsbauer besprochen hast... (jedenfalls sind längere Sätze iVm. einem min-confidence-Level schon mal ein guter Anfang...).

Zitat
Geht wirklich. Perfekt!
Perfekt ist es nicht, im Anhang sollte jetzt auch "rest=none" funktionieren, damit man das nicht einzeln machen muss.

Haken an der Sache: Jemand muss dringend testen, ob das funktioniert, was ich zu den cmd-Ausschlüssen in die globale Abfrage ("welche Szenen kennst du" (ohne Device) in GetState) reingeknödelt habe...

ZitatLaut den FHEM Statistiken wird lightScene überraschend selten verwendet (LightScene/444/1209). Hätte ich auf mehr getippt. Ich find's schon cool. Aber gebraucht wird's nicht unbedingt. rhasspyChannels wäre ja ein Ersatz.
Mißverständnis: Das betrifft nicht nur LightScene, sondern eben auch meinen Verstärker, diverse HUEDevice-Instanzen usw..

Zitat
Mag sein, dass wir gerade aneinander vorbei reden. Ich war der Meinung, GDT legt Regeln fest. Solange kein Mapping da steht. Ist eines da, überschreibt (bzw. ergänzt) das die GDT-Regeln. Und das finde ich eigentlich sehr gut so. Und bisher war ich der Meinung, das funktioniert auch genau so. Zumindest ist mir nichts anderes aufgefallen.
Jein. Es geht eben genau um die Frage, wie "richtig" es sein soll, dass ein "gleichnamiges" (bzw. funktional gleichwertiges) rhasspy*-Attribut die Ergebnisse aus der autmatischen Analyse überschreiben soll. Ich war (weil ich eigentlich nur Automatik mache) überrascht, dass dein SetOnOff nicht dazu geführt hat, dass SetScene noch vorhanden war und halte das eigentlich nach wie vor für eine Fehlfunktion... Die Regel sollte sein: Wer manuell was setzt, will "alles in der Hand haben" => gar keine (diesbezügliche) Automatik.

Ist daher im Anhang auch anders gelöst (dafür gibt es ja neuerdings "get ... export", wenn man das als Startpunkt weiter verwenden will, was die Automatik erkannt hatte).
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 31 März 2022, 13:59:37
Zitat von: Beta-User am 31 März 2022, 13:49:28
Haken an der Sache: Jemand muss dringend testen, ob das funktioniert, was ich zu den cmd-Ausschlüssen in die globale Abfrage ("welche Szenen kennst du" (ohne Device) in GetState) reingeknödelt habe...
Mach ich dann, wenn ich zuhause bin.

ZitatMißverständnis: Das betrifft nicht nur LightScene, sondern eben auch meinen Verstärker, diverse HUEDevice-Instanzen usw..
Kein Mißverständnis. Ich hab nur zuwenig weit gedacht ;)

ZitatDie Regel sollte sein: Wer manuell was setzt, will "alles in der Hand haben" => gar keine (diesbezügliche) Automatik.
Seh ich schrägerweise ganz anders. Ich empfand das als Komfort-Funktion, dass ein Device über GDT mal grundsätzlich funktioniert. Passt mir aber ein kleiner Aspekt der Grundfunktion nicht, kann ich das jederzeit über ein Mapping ändern. Find ich echt super. Kann ja auch sein, dass ein GDT mal nicht alle Funktionen eines Devices abdeckt. Oder der GDT nicht zu 100% passt. Deswegen alles händisch machen zu müssen find ich blöd ;)
Siehe meine lightScene und SetOnOff. Sonst hätte ich extra noch etwas zusätzlich basteln müssen.

Gibt's da vielleicht noch eine dritte Meinung dazu?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 31 März 2022, 14:10:11
Zitat von: Beta-User am 31 März 2022, 13:49:28
Haken an der Sache: Jemand muss dringend testen, ob das funktioniert, was ich zu den cmd-Ausschlüssen in die globale Abfrage ("welche Szenen kennst du" (ohne Device) in GetState) reingeknödelt habe...

Moment. GetState? Wie würde da die sentences.ini aussehen?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 31 März 2022, 14:23:26
Zitat von: drhirn am 31 März 2022, 13:59:37
Gibt's da vielleicht noch eine dritte Meinung dazu?
Will ergänzend dazu noch den Hinweis auf das "Special" blacklistIntents plazieren. Bisher war es nämlich so, dass das händische Setzen von rhasspyMapping "eigentlich" der einzige Weg gewesen wäre, um das automatische Mapping ganz loszuwerden...

Zitat von: drhirn am 31 März 2022, 13:59:37
Seh ich schrägerweise ganz anders. Ich empfand das als Komfort-Funktion, dass ein Device über GDT mal grundsätzlich funktioniert.
8) so war es gedacht  ;D ;D ;D

Zitat
Passt mir aber ein kleiner Aspekt der Grundfunktion nicht, kann ich das jederzeit über ein Mapping ändern. Find ich echt super. Kann ja auch sein, dass ein GDT mal nicht alle Funktionen eines Devices abdeckt. Oder der GDT nicht zu 100% passt. Deswegen alles händisch machen zu müssen find ich blöd ;)
Na ja, wie gesagt kann man das, was die Automatik erkannt hat, ja (zwischenzeitlich) prinzipiell ohne weiteres exportieren, ohne sich erst stundenlang mit der Doku zur richtigen Syntax rumschlagen zu müssen...

Zitat
Gibt's da vielleicht noch eine dritte Meinung dazu?
Von daher gibt es evtl. auch noch einen "dritten Weg" dazu: "Jemand" könnte einen Tweak bauen, mit dem man das komplette Löschen als default erzwingt, ansonsten bleibt es bei der offenkundig ja niemanden störenden Automatik, dass nur ersetzt wird, was gleichnamig in rhasspyIntents vorhanden ist...?!?

Damit wären wir aber wieder bei:
Zitat von: JensS am 29 März 2022, 17:45:18
Wo kann man sich beim RHASSPY (B.A.) einschreiben?  8)
Wobei: zum einen ist das ja schlicht eine Option unter "ferner liefen" für denjenigen, der nach sowas sucht, und zum anderen fand ich dann einige Antworten zu den Fragen, die wir "zwischendrin" hier diskutiert hatten auch im Wiki bei https://wiki.fhem.de/wiki/RHASSPY/Vertiefung (z.B. zur Frage, wie man das mit den Thermostaten und prio lösen könnte) 8) . Allerdings schwant mir, dass man das dann auch bei Gelegenheit nochmal intensiver ansehen sollte, weil sich eben doch zwischenzeitlich wieder das eine oder andere ergeben hat...

Zitat von: drhirn am 31 März 2022, 14:10:11
Moment. GetState? Wie würde da die sentences.ini aussehen?
Welche ( Räume:rooms | (Szenen | Szenarien | Einstellungen):scenes){Type} kennst du [<rooms>]
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 31 März 2022, 14:47:51
Zitat von: Beta-User am 31 März 2022, 14:23:26
Na ja, wie gesagt kann man das, was die Automatik erkannt hat, ja (zwischenzeitlich) prinzipiell ohne weiteres exportieren, ohne sich erst stundenlang mit der Doku zur richtigen Syntax rumschlagen zu müssen...

Schon. Aber jetzt ein Beispiel:

Ich habe einen HM Thermostat. GDT "thermostat" und alles klappt. Weil ich aber auch einfach "Heizung aus" (=5°) und "Heizung ein" (=21°) sagen wollte, hab ich einfach ein SetOnOff ergänzt.

Jetzt muss ich zuerst auf's RHASSPY Device gehen und mir dort die Einstellungen exportieren. Die muss ich dann im Thermostat in das rhasspyMapping packen. Und dann noch den SetOnOff-Intent dazu. Das ist viel mehr Arbeit. Und ich mag keine Arbeit ;D
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 31 März 2022, 14:53:00
Neuer Tweak? done :P .
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 31 März 2022, 14:59:58
Versteh ich jetzt nicht. Der Tweak macht ja genau das, was du eh schon eingebaut hast!? Oder hast du das wieder zurückgebaut?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 31 März 2022, 15:02:36
Zitat von: drhirn am 31 März 2022, 14:59:58
Versteh ich jetzt nicht. Der Tweak macht ja genau das, was du eh schon eingebaut hast!? Oder hast du das wieder zurückgebaut?
Ja. Aber der default entspricht jetzt dem von dir gewünschten Verhalten, wenn nicht angewendet ;) .
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 31 März 2022, 16:21:22
Wenn ich bei meinem Thermostat jetzt - nur zum Testen - einen abgeänderten SetNumeric über rhasspyMapping hinzufüge, habe ich dann beim Export des Mapping zwei SetNumeric Intents. Einer geht laut "list" dann auf desired-temp, der andere auf temperature. Anstatt den anderen zu ersetzen.

Ohne rhasspyMapping:

           intents:
             GetNumeric:
               desired-temp:
                 currentVal desired-temp
                 type       desired-temp
               temperature:
                 currentVal measured-temp
                 type       temperature
             SetNumeric:
               desired-temp:
                 cmd        desired-temp
                 currentVal desired-temp
                 maxVal     28
                 minVal     10
                 step       0.5
                 type       temperature


Mit rhasspyMapping:

           intents:
             GetNumeric:
               desired-temp:
                 currentVal desired-temp
                 type       desired-temp
               temperature:
                 currentVal measured-temp
                 type       temperature
             SetNumeric:
               desired-temp:
                 cmd        desired-temp
                 currentVal desired-temp
                 maxVal     28
                 minVal     10
                 step       0.5
                 type       temperature
               temperature:
                 cmd        desired-temp
                 currentVal desired-temp
                 maxVal     28
                 minVal     10
                 step       0.5
                 type       temperature
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 31 März 2022, 16:43:12
 :) Da ist wohl schon der Export kaputt...

Und das Überschreiben klappte auch "schon immer" nicht...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 01 April 2022, 05:56:36
*grummel*
Diese "Sonderlocke" mit desired-temp war irgendwie hartnäckig beim "export", jetzt sollte das mit der svn-Version aber auch gehen. Weiß nur nicht, ob so ein "händisches" Device dann auch funktioniert oder ob das beim Finden der Antwort irgendein Problem gibt...

Weiter habe ich was reingeknödelt, das dann beim "Überschreiben" jeweils die Intents für sich überschreibt, das "falsche" Mapping von gestern sollte jetzt also dahingehend "korrekt" sein, dass kein 2. SetNumeric mehr erscheint. (ist aber nicht groß getestet, sondern schlimmstenfalls genauso kaputt wie bisher).
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 01 April 2022, 08:48:00
Nun, ich kann nur positives berichten.

Habe rhasspyMapping gelöscht -> Export wunderbar
Habe rhasspyMapping mit Export-Werten befüllt -> Export wunderbar
Habe einen Intent geändert -> Export wunderbar

Keine doppelten Einträge, keine "falschen" Einträge. Mein Kurztest sagt, es tut genau so, wie ich mir das gewünscht habe. Betonung auf "Kurztest". Danke dir!
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 01 April 2022, 09:09:44
Zitat von: drhirn am 01 April 2022, 08:48:00
Mein Kurztest sagt, es tut genau so, wie ich mir das gewünscht habe. Betonung auf "Kurztest". Danke dir!
:)
Danke zurück!

Gehe davon aus, dass der "Kurztest" ausreichend ist, das Problem liegt meistens eher in der Strukturierung (so war es m.E. auch hier). Unklar ist dann nur, ob der "händische" Intent dann auch funktioniert und v.a. auch die passende Antwort kommt. Diesen Teil des Codes hatte ich mir bisher nicht angeschaut, kann sein, dass wir da irgendwann noch eine Sonderlocke wg. desired-temp-type benötigen...
Für's erste können wir ja mal abwarten, ob/wann sich jemand beschwert :P .

Dann bin ich jetzt erst mal auf pah's Rückmeldung zur "kalten Pizza" gespannt ;D , und kau' ansonsten mal gedanklich ein bißchen auf dem "wann ist es sinnvoll, den vorgegebenen Intent zu verlassen"-Thema rum...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 01 April 2022, 15:28:05
Vielleicht hier auch mal was leicht [OT]

Zitat von: drhirn am 30 März 2022, 10:41:52
Bzgl. Scenes wusste ich gar nicht, dass man die jetzt überhaupt steuern kann. Und auch nicht, wie. ;)
Mit einem gewissen Interesse verfolge ich ja hin und wieder, was in "Hogwarts" so los ist: https://community.rhasspy.org/t/hogwarts-assistant/2882 (https://community.rhasspy.org/t/hogwarts-assistant/2882)

"Szenen" bzw. die Frage, wie man was abfragt, was man Rhasspy so sagt, wenn man was wissen will usw. sind ja echt spannende Geschichten - sowohl sprachlich wie eben auch hinsichtlich der Frage, wie man das "vercoded" bekommt... Und da freut es mich immer, wie vergleichsweise komfortabel man seine jeweiligen individuellen Anforderungen und Gewohnheiten mit dem Gespann FHEM+RHASSPY an und mit Rhasspy umgesetzt bekommt - kein Vergleich zu dem (durchaus interessanten) Verteilen von individualisierten Bruchstücken über (gefühlt) tausende Zeilen Code, wie sie z.B. im letzten Video zu sehen sind....
(Klar: irgendwo muss man festlegen, was wann geschehen soll, und das ist durchaus ein nicht unerheblicher Aufwand, aber der sollte halt für den "Konfigurator" möglichst gering ausfallen).

Wobei das mit dem passenden (schaurigen) Hintergrundgeräusch durchaus was hätte (wenn auch nicht für alle Mitbewohner... ;D )
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 01 April 2022, 16:25:41
Bringt mich auf die Idee, dass man eigentlich auch mit SSH Audio-Files abspielen lassen könnte. Zumindest, wenn der Satellit ein Linux-Derivat ist. Bräuchte dann aber halt ein paar Änderungen an der Sound-Konfiguration, damit die Audioausgabe von Rhasspy nicht geblockt wird. Aber so könnte man dann auch die Timer-Ende Ausgabe abbrechen.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 02 April 2022, 07:30:32
Zitat von: drhirn am 01 April 2022, 16:25:41
Bringt mich auf die Idee, dass man eigentlich auch mit SSH Audio-Files abspielen lassen könnte. Zumindest, wenn der Satellit ein Linux-Derivat ist. Bräuchte dann aber halt ein paar Änderungen an der Sound-Konfiguration, damit die Audioausgabe von Rhasspy nicht geblockt wird.
Doppelte Wege bzw. Varianten, die nur auf einem "Sonderweg" funktionieren, sind nicht soooo prickelnd. Irgendwie sah das in dem Video so aus, als wäre die doppelte Soundausgabe das Ergebnis einer Mischanweisung an den Audio-Server, aber das kann auch eine Fehlinterpretation sein.

Zitat
Aber so könnte man dann auch die Timer-Ende Ausgabe abbrechen.
Nur zur Sicherheit:
https://rhasspy.readthedocs.io/en/latest/reference/#audioserver_playfinished (https://rhasspy.readthedocs.io/en/latest/reference/#audioserver_playfinished) und das danach folgende
Zitat

       
  • hermes/audioServer/toggleOff (JSON)

            
    • Disable audio output
    • siteId: string = "default" - Hermes site ID
hattest du mal ausprobiert? Kann ja durchaus sein, dass der Audioserver das auch mitliest und nicht nur informatorisch am Ende raushaut...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 02 April 2022, 10:23:12
mosquitto_pub -t 'hermes/audioServer/toggleOff' -m '{ "siteId": "default"}'beendet den Audio-Server.
Das bedeutet, dass keine Daten zwischen MQTT und z.B. aplay übergeben werden.
Eine laufende Ausgabe von aplay würde dabei nicht gestoppt.
Eine mögliche Lösung wäre, dass eine neue Session zum Intent [gib Ruhe] mit einer kurzen Antwort "ok" initiiert wird. Dass funktioniert aber nur, wenn ein Echo-Canceling vorhanden ist oder man schreit halt.  ;)
Eine andere Möglichkeit wäre neue playBytes-Anweisung mit einer kurzen (leeren) Audiodatei.

Zum Thema "Hogwarts" - hier braucht sich RHASSPY nicht verstecken und kann bei einer ähnlichen Darstellung ebenfalls Beachtung finden.

Gruß Jens
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 02 April 2022, 15:20:06
Zitat von: JensS am 02 April 2022, 10:23:12
mosquitto_pub -t 'hermes/audioServer/toggleOff' -m '{ "siteId": "default"}'beendet den Audio-Server.
Das bedeutet, dass keine Daten zwischen MQTT und z.B. aplay übergeben werden.
Eine laufende Ausgabe von aplay würde dabei nicht gestoppt.
Klar, was bereits auf dem Satelliten in Richtung Soundkarte unterwegs ist, bekommt man damit nicht gestoppt.

Zitat
Eine andere Möglichkeit wäre neue playBytes-Anweisung mit einer kurzen (leeren) Audiodatei.
Hmm, wenn ich es richtig interpretiert habe, ging es darum, von FHEM aus "irgendwie" die grade laufende Ausgabe an einem beliebigen Satelliten abzubrechen. Dafür wäre Rhasspy als Input m.E. nicht zwingend, und es wäre auch nicht dramatisch, wenn es "ein wenig" dauert.

Nun ja, vielleicht hat da ja jemand eine Idee, ob sich aus diesem Fragment was basteln läßt...

Zitat
Zum Thema "Hogwarts" - hier braucht sich RHASSPY nicht verstecken und kann bei einer ähnlichen Darstellung ebenfalls Beachtung finden.
:)
Videos drehen ist jetzt nicht so meine Kernkompetenz, und an sich ging es eigentlich auch nicht um "Werbung" mit Hilfe einer "ähnlichen Darstellung", sondern einfach nur darum mitzuteilen, dass ich unsere Lösung einfach "cool" finde  8) .
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 02 April 2022, 16:12:35
Eigentlich müssten wir ja nur die Wiederholungen abbrechen können. Wenn welche eingestellt sind. Das wäre dann ja wieder eine RHASSPY Geschichte.
Vorausgesetzt, als Ausgabe ist ein kurzes WAV konfiguriert, dass sich wiederholt.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 02 April 2022, 16:54:47
Zitat von: Beta-User am 02 April 2022, 15:20:06
Hmm, wenn ich es richtig interpretiert habe, ging es darum, von FHEM aus "irgendwie" die grade laufende Ausgabe an einem beliebigen Satelliten abzubrechen.
Da stellt sich die Frage, wie der Abbruch initiiert werden soll.?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 02 April 2022, 17:17:22
Zitat von: drhirn am 02 April 2022, 16:12:35
Eigentlich müssten wir ja nur die Wiederholungen abbrechen können. Wenn welche eingestellt sind. Das wäre dann ja wieder eine RHASSPY Geschichte.
Vorausgesetzt, als Ausgabe ist ein kurzes WAV konfiguriert, dass sich wiederholt.
Wenn es nur um die Wiederholungen geht, ist das an sich kein größeres Problem: das at definiert sich jeweils selbst wieder, wenn ich das richtig im Kopf habe => delete-Befehl von FHEM aus bzw. CancelTimer-Intent, falls man Rhasspy zum Zuhören überreden kann... Man muss nur wissen, welche Textbausteinchen da verarbeitet wurden, um das (temporäre) at zu benennen  ;) .
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 02 April 2022, 17:42:44
Kurze Frage - wie überrede ich das RHASSPY-Device, ein textCommand mit der siteId=wohnzimmer aufzurufen?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 02 April 2022, 17:51:31
Zitat von: JensS am 02 April 2022, 17:42:44
Kurze Frage - wie überrede ich das RHASSPY-Device, ein textCommand mit der siteId=wohnzimmer aufzurufen?
Im Moment ist das so nicht vorgesehen, patches welcome...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 03 April 2022, 09:05:19
Hallo zusammen,

gestern gab es eine Anfrage im Rhasspy-Forum (https://community.rhasspy.org/t/turn-off-garage-and-porch-lights-multiple-values-for-same-slot/3591), die in ähnlicher Form immer mal wieder auftaucht:
ZitatIs it possible to say "go vacuum the kitchen and the dining room" and have it recognize "govacuum" as the intent and the slot "room" would be "kitchen, dining room" or something like that? This would also work for split level hvac, turning on/off multiple lights ect.

Eigentlich sollte es nicht allzu schwierig sein, eine "Verundung" reinzubasteln, für's erste wäre SetOnOff mit mehreren Geräten ({Device}, {Device1} ... {Device.}) ein eventueller Prototyp.

Meinungen?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 03 April 2022, 09:38:55
Für's Erste funktioniert das. In der sentences.ini sind leider keine {Device(n)} vorgesehen. Es müssten alle denkbaren Szenarien optional abgebildet werden.

p.s. Hier ein wirres Beispiel:
Slot "de.fhem.Test"([ und [(den | dem | der | die | das)] ]) (stuhl){moebel2}
([ und [(den | dem | der | die | das)] ]) (sessel){moebel1}


sentences.ini (hab SetOnOff missbraucht...)wische den bereich um dem $de.fhem.Test [$de.fhem.Test]

Text: "wische den bereich um dem sessel und dem stuhl"

JSON:{
    "entities": [
        {
            "end": 32,
            "entity": "moebel1",
            "raw_end": 32,
            "raw_start": 26,
            "raw_value": "sessel",
            "start": 26,
            "value": "sessel",
            "value_details": {
                "kind": "Unknown",
                "value": "sessel"
            }
        },
        {
            "end": 46,
            "entity": "moebel2",
            "raw_end": 46,
            "raw_start": 41,
            "raw_value": "stuhl",
            "start": 41,
            "value": "stuhl",
            "value_details": {
                "kind": "Unknown",
                "value": "stuhl"
            }
        }
    ],
    "intent": {
        "confidence": 1,
        "name": "de.fhem:SetOnOff"
    },
    "raw_text": "wische den bereich um dem sessel und dem stuhl",
    "raw_tokens": [
        "wische",
        "den",
        "bereich",
        "um",
        "dem",
        "sessel",
        "und",
        "dem",
        "stuhl"
    ],
    "recognize_seconds": 0.11035313599859364,
    "slots": {
        "moebel1": "sessel",
        "moebel2": "stuhl"
    },
    "speech_confidence": 1,
    "text": "wische den bereich um dem sessel und dem stuhl",
    "tokens": [
        "wische",
        "den",
        "bereich",
        "um",
        "dem",
        "sessel",
        "und",
        "dem",
        "stuhl"
    ],
    "wakeword_id": null
}

Gruß Jens

p.p.s. In pyjsgf gibt es einen Wiederholungsparameter ($de.fhem.Test)+, der in Rhasspy nicht übernommen wurde.
https://pyjsgf.readthedocs.io/en/latest/api/expansions.html?highlight=repeat#jsgf.expansions.Repeat (https://pyjsgf.readthedocs.io/en/latest/api/expansions.html?highlight=repeat#jsgf.expansions.Repeat)
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 03 April 2022, 18:36:11
Nanu, so ruhig hier? Gibt's heute keine Pizza?  ;D

($de.fhem.Test)+ wird wohl nicht implementiert sein, weil man sonst eine unendliche Wiederholung im Wörterbuch der möglichen Frasen einfügen muss.
Vielleicht lässt sich @synesthesiam überreden, 2 Wiederholungen bei ()+ als Standard zu setzen und eine andere maximale Anzahl als Zusatz mit anzufügen.
z.B. ($de.fhem.Test)+5
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 03 April 2022, 18:41:06
Ja, das irgendwie in einen mehr oder weniger passenden Key zu bekommen, ist vermutlich nicht so sehr das Problem, eher dann die Auswertung, zumal es dann Mischungen zwischen {Device(n)}, {Room(n)} und {Group(n)}geben könnte...
Sicher alles interessant, aber erst muss ich mal das mit der Auswahl nach "getConfirmation" fixen, das ist irgendwie (noch) seltsam ::) ...

Die Pizza scheint einem Shelly-firmware-Problem zum Opfer gefallen zu sein (oder dem Wetter?!?)...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 03 April 2022, 19:03:50
Zitat von: Beta-User am 03 April 2022, 18:41:06
Jist vermutlich nicht so sehr das Problem, eher dann die Auswertung, zumal es dann Mischungen zwischen {Device(n)}, {Room(n)} und {Group(n)}geben könnte...
Beim eingehenden Intent könnte man die [moebel(1-2)] zählen, die einzelnen Devices in ein Hilfsarray packen und die folgende SetOnOff-Funktion x-mal abarbeiten. Allerdings dürfte die Session zwischenzeitlich nicht geschlossen werden.
Eine von viele Möglichkeiten.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 04 April 2022, 14:12:29
Zitat von: Beta-User am 03 April 2022, 18:16:05
Hmm, da war noch eine "device-lose" Abfrage nach "braucht das eine Bestätigung" - ist im svn gefixt.
Gibt jetzt zwar ein Folgeproblem, weil ich jetzt plötzlich für "mach wärmer" trotz priority nach einer Auswahl (nach Bestätigung) gefragt werde, aber eins nach dem anderen...

Fyi:
- Das Problem mit der (fehlerhaften) device-losen Abfrage wg. der Bestätigung existiert(e) nicht nur in SetOnOff, sondern noch in ein paar anderen Intents (das ganze war eine Folge der Erweiterung der Funktion auch für Gruppen);
- den Grund für die Auswahlabfrage (nach Bestätigung in SetNumeric) konnte ich auch dingfest machen;
- autoTraining ist auch einen halben Schritt vorangekommen;
- ein paar Perlcritics sind gefixt, für ein paar andere (die m.E. nicht allzu berechtigt sind) Pflaster geklebt.

Soweit so gut, werde jetzt erst mal selbst etwas testen, weil dabei auch regexe etwas verändert worden sind, danach kann es wieder für die Allgemeinheit weiter gehen :) .

Zitat von: JensS am 03 April 2022, 19:03:50
Beim eingehenden Intent könnte man die [moebel(1-2)] zählen, die einzelnen Devices in ein Hilfsarray packen und die folgende SetOnOff-Funktion x-mal abarbeiten. Allerdings dürfte die Session zwischenzeitlich nicht geschlossen werden.
Eine von viele Möglichkeiten.
Das Problem scheint mir weniger zu sein, auf die Schnelle was zusammenzuschreiben, sondern für den Fall der Fälle würde ich mir das schon so vorstellen, dass man im Prinzip beliebige "Gruppierungsmerkmale" kombinieren kann, also:
Device 1 + Device 2
Device 1 + Gruppe a
Gruppe a + Device 1
Gruppe a+ Gruppe b
"Gruppe a  mit Name xy" in Raum 1 + Raum 2
...

Anders gesagt: Ich glaube, es spricht sich nur dann "organisch", wenn man nicht groß überlegen muss, was sich hinter den einzelnen Elementen verbirgt. Das bedeutet aber, dass man checken muss, ob in einem Intent "falsche" Keys drin sind, und das dann zum Anlass nehmen müßte, erst mal zu sammeln... Möglicherweise ist es trivial, möglicherweise näherungsweise unmöglich, im Moment noch keine Ahnung ;D .

Damit ergibt sich aber nicht nur "zwanglos" eine Liste mit betroffenen Devices, sondern es stellen sich ein paar Folgefragen:
- Ist das dann insgesamt als "Gruppenanweisung" zu verstehen, oder sollen "Genehmigungsvorbehalte" aus Einzeldevices noch relevant sein?
- Wenn ja: Soll der "nicht betroffene Rest" vorab durchgeführt werden...? Oder alles erst nach Genehmigung? Wie soll die aussehen...?
(Tendiere zu: Wenn irgendwo eine Genehmigung für einen Teil erforderlich ist: Warten mit allem, "raw-Rückfrage". Mehrere Devices können identifiziert werden: Genehmigungs-tweak für Gruppen-Intent greift.)

Schwierig wird es uU., wenn man zwar eine Gruppe hat, aber kein Device kann, was die Anweisung will (muß man das erst checken, bevor man ein Device in die Liste aufnimmt...?).

Hat man dann die Liste, muss man sie uU. erst mal (wegen der Genehmigung) "auf die Seite packen", und dann (ggf. später)nochmal durchflözen wegen der Frage, in welcher Reihenfolge man das ganze schaltet... Prinzipiell ist vermutlich auch dieser Teil irgendwie schon gelöst, aber das ganze dann wieder fehlerfrei zusammenzustückeln ist vermutlich nicht ganz trivial (siehe das mit dem "confirm"-Special und der seltsamen Auswahl-Folge)...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 04 April 2022, 18:26:22
Zitat von: Beta-User am 03 April 2022, 09:05:19
Eigentlich sollte es nicht allzu schwierig sein, eine "Verundung" reinzubasteln, für's erste wäre SetOnOff mit mehreren Geräten ({Device}, {Device1} ... {Device.}) ein eventueller Prototyp.

Meinungen?
Nun, meinen Vorschlag hast du ja. Ob du was draus machst, ist natürlich dir überlassen. Memo an mich: Nicht alles wörtlich nehmen...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 05 April 2022, 08:02:12
Zitat von: Beta-User am 04 April 2022, 14:12:29
Soweit so gut, werde jetzt erst mal selbst etwas testen, weil dabei auch regexe etwas verändert worden sind, danach kann es wieder für die Allgemeinheit weiter gehen :) .
Das scheint soweit zu passen, umfassend testen ist aber schwierig. Jedenfalls ist seit eben ein update im svn :) .

Neben dem hoffentlich gefixten Thema mit der "Einzelbestätigung" scheint jetzt auch "autoTraining" voll funktional zu sein, ich neige dazu, das mittelfristig zur Standardeinstellung mit einem timeout von ca. 60 Sekunden zu machen.

Meinungen dazu?



Was auch etwas besser geworden ist, ist das Ding mit den "kontinuierlichen Dialogen". Funktional ist es trotzdem noch nicht, aber im Zuge der letzten paar Code-Reviews sind mir schon einige Stellen ins Auge gesprungen, die so nicht optimal waren. Mal sehen, vielleicht klappt es auch noch, diesen Knoten vollends durchzuhauen.


Da wir im svn sind, kann man für support-Zwecke sowieso die svn-Nummer als eindeutigen Kenner (ggf. mit Anmerkungen zu Test- und Zwischenversionen) heranziehen. Das entsprechende Internal bräuchten wir daher m.E. eigentlich nicht mehr.



Zitat von: JensS am 04 April 2022, 18:26:22
Nun, meinen Vorschlag hast du ja.
Ich habe die Rückmeldung als "finde ich gut" gewertet. Das ganze Thema bedarf auch für mich noch der "Reifung", und sorry, wenn ich in dem Zusammenhang einfach versuche, meine Gedanken auch mal irgendwo niederzuschreiben.
Vermutlich vergeht noch einige Zeit, bis daraus vielleicht der Versuch entsteht, funktionalen Code zu basteln.

Vor allem will ich jetzt erst mal die übrigen Punkte von der ToDo-Liste haben, der Weg scheint mir nicht mehr allzu weit zu sein :) .



Bzgl. der AMAD.*-Geschichte fehlt mir noch eine Idee, wie das "eine" Attribut künftig heißen sollte; ansonsten wäre noch offen, wie man den Voice-Input wieder öffnet für Rückfragen etc.. Manuell klappt das jedenfalls nicht, muss auch dazu nochmal in den Code schauen.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 05 April 2022, 09:20:02
Zitat von: Beta-User am 05 April 2022, 08:02:12
Neben dem hoffentlich gefixten Thema mit der "Einzelbestätigung" scheint jetzt auch "autoTraining" voll funktional zu sein, ich neige dazu, das mittelfristig zur Standardeinstellung mit einem timeout von ca. 60 Sekunden zu machen.
Was ist dieses "autoTraining"?

ZitatDa wir im svn sind, kann man für support-Zwecke sowieso die svn-Nummer als eindeutigen Kenner (ggf. mit Anmerkungen zu Test- und Zwischenversionen) heranziehen. Das entsprechende Internal bräuchten wir daher m.E. eigentlich nicht mehr.
Das Internal "Version"? Das brauch ich nämlich um zu wissen, welche Version ich gerade installiert habe.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 05 April 2022, 10:18:59
Zitat von: drhirn am 05 April 2022, 09:20:02
Was ist dieses "autoTraining"?
Muss wohl nochmal ausholen...

Hatte vor einiger Zeit eine längere pm-Diskussion mit martinp876 zu diversen Themen, u.a. allgemein um das, was man wohl eine stringente Nutzerführung nennen könnte. Dabei war seine These, dass ein Modul wie RHASSPY eigentlich in der Lage sein sollte, die Konfiguration auch des externen Systems konsistent zu halten, also konkret: Auf Änderungen in/an Attributen, die Auswirkungen auf die von Rhasspy erkannten Sätze haben können zui prüfen, ob ein Training erforderlich wäre und das dann ggf. auch automatisch anzuschubsen.

Genau das macht dieses feature, was im Moment als key in DEF umgesetzt ist: Es reagiert per NotifyFn() (ggf. u.a. auch) auf diverse globale Events, und setzt bzw. erneuert dann einen Timer. Ist der abgelaufen, wird geprüft, ob sich der an Rhasspy zu sendende Content geändert hat, wenn ja => update der Daten. Wenn angekommen, dann Training veranlassen :) . ("attr global showInternalValues 1" sollte zeigen, gegen was im Detail geprüft wird).

Falls das zum default würde, wäre es dann eher per Tweak deaktivierbar?

Zitat
Das Internal "Version"? Das brauch ich nämlich um zu wissen, welche Version ich gerade installiert habe.
Na ja, nachdem es eine svn-Nummer hat, kann man die "version" ja auch ganz regulär abfragen. Es gibt dann nur noch diese eine Stelle, die "jemand" pflegen muss ;) . Zwischenversionen kann man nämlich durch Änderung in der ID-Zeile kenntlich machen.

Eigentlich wäre es auch an der Zeit, das Modul für "Meta" vorzubereiten, dann gäbe es wohl auch automatisch ein passendes Internal. Aber das ist immer etwas mühsam aufzubereiten (ich müßte das eigentlich auch in ein paar anderen "geerbten" Modulen noch nachpflegen ::) ).
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 05 April 2022, 10:22:01
Zitat von: Beta-User am 05 April 2022, 10:18:59
Genau das macht dieses feature, was im Moment als key in DEF umgesetzt ist: Es reagiert per NotifyFn() (ggf. u.a. auch) auf diverse globale Events, und setzt bzw. erneuert dann einen Timer. Ist der abgelaufen, wird geprüft, ob sich der an Rhasspy zu sendende Content geändert hat, wenn ja => update der Daten. Wenn angekommen, dann Training veranlassen :) . ("attr global showInternalValues 1" sollte zeigen, gegen was im Detail geprüft wird).

Ah. Sehr cool!

ZitatFalls das zum default würde, wäre es dann eher per Tweak deaktivierbar?
Nach meiner FHEM-Logik eher als Attribut, oder?

ZitatNa ja, nachdem es eine svn-Nummer hat, kann man die "version" ja auch ganz regulär abfragen. Es gibt dann nur noch diese eine Stelle, die "jemand" pflegen muss ;) . Zwischenversionen kann man nämlich durch Änderung in der ID-Zeile kenntlich machen.
Verwendet aber nicht jeder SVN  ;)
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 05 April 2022, 10:32:09
Zitat von: drhirn am 05 April 2022, 10:22:01
Ah. Sehr cool!
:)
Hatte eher eine skeptische Reaktion erwartet, aber wenn wir beide das cool finden, sollten wir nach deinen ersten Tests mal über die Frage eines "guten" Timeout-Werts nachdenken :) .

Zitat
Nach meiner FHEM-Logik eher als Attribut, oder?
"tweak" meint: Ein Schlüssel innerhalb "rhasspyTweaks". Ein eigenes Attribut dafür finde ich übertrieben...
Entweder es ist "gut", dann sollte es allgemein aktiv sein, oder es "hakt", dann bleibt es experimentell ;D . Wer ein "gutes" feature deaktivieren will, sollte das tun können, aber ein "Silbertablett" braucht es dafür nach meiner Ansicht/Logik nicht.

Zitat
Verwendet aber nicht jeder SVN  ;)
Ist egal. Solange $Id "gepflegt ist, kommt auch was raus, wenn man z.B. auf GitHub oder hier veröffentlichten Versionen "irgendwelche" Informationen dort reinschreibt. Ich lasse z.B. in der Regel die svn-Version als Basis stehen und ergänze mit Datum + ggf. einer weiteren Unternummer. Das "nicht jeder" ist also m.E. kein "schlagendes" Argument. Was damit "verloren" geht, wäre der "Masterplan" in Richtung auf "1.0" :P ... Im Moment sind wir gefühlt jedenfalls mind. auf 0.6 8) .
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 05 April 2022, 11:18:09
Zitat von: Beta-User am 05 April 2022, 10:32:09
Entweder es ist "gut", dann sollte es allgemein aktiv sein, oder es "hakt", dann bleibt es experimentell ;D . Wer ein "gutes" feature deaktivieren will, sollte das tun können, aber ein "Silbertablett" braucht es dafür nach meiner Ansicht/Logik nicht.
Naja, das Feature nimmt direkt Einfluss auf die Verhaltensweise des Moduls. Unabhängig von irgendwelchen Rhasspy-Devices, Sätzen oder sonstiges. Somit hätte ich es schon als "wichtiger" angesehen, als rhasspyTweaks z.B.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 05 April 2022, 11:55:44
Na ja, mAn. hängt das von der Sichtweise ab: Für dich als langjährigem RHASSPY-Nutzer ist es "normal", den update-devicemap+training-Prozess manuell "anschubsen" zu müssen. Ich hatte auch gewisse Schwierigkeiten, mich von dem Gedanken
"aber das dauert doch etwas, bis das training durch ist, und ich will das in der Hand haben, wann es stattfindet! Schließlich weiß ich ja, was zu tun ist...!"
lösen zu können und martinp876's Sichtweise als "normal" zu akzeptieren, dass der User auf der einen Seite was ändert, und dann eben erwartet, dass Rhasspy das schon mitbekommen wird, ohne dass er was explizit in diese Richtung veranlasst.

Von daher: Es war nach Meinung gefragt, und das klingt jetzt doch etwas skeptischer, als ich es zunächst wahrgenommen hatte...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 05 April 2022, 12:24:11
Zitat von: Beta-User am 05 April 2022, 11:55:44
Von daher: Es war nach Meinung gefragt, und das klingt jetzt doch etwas skeptischer, als ich es zunächst wahrgenommen hatte...

Falsch verstanden. autoTraining find ich super. Daran wird sich auch nichts ändern. Wir diskutieren hier doch nur, ob Tweak oder Attribut ;)
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 05 April 2022, 12:32:28
 ;D dann eindeutig (!) Tweak. Da ist doch schon jetzt manches beieinander, das in eine ähnliche Richtung geht (v.a. updateSlots, intentFilter, mappingOverwrite)...

Notiz an mich selbst: Die commandref sollte an der Stelle mal überarbeitet werden, der Einleitungssatz ist schon länger nicht mehr up-to-date, und die Gruppierung ein wenig willkürlich... ::)
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 05 April 2022, 12:40:36
Haha, nein. Eindeutig Attribut ;D
"updateSlots", "intentFilter", "mappingOverwrite" geht immer davon aus, dass schon Daten in Rhasspy da sind, hat aber keinen Einfluss auf die Grundfunktionen von RHASSPY. Bei autoTraining ist das umgekehrt.

Aber - wie immer - ich nehm's, wie's kommt.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 05 April 2022, 12:54:04
Hehe, ich glaube, wir lassen es einfach als key in der DEF, drehen aber den default um ::) .

Das Problem: "Tweaks" finden sich in der Regel irgendwo im "helper" wieder, das meiste aus DEF (sei es implizit, sei es explizit) kommt als direkt sichtbares Internal. Das da zu lassen, ist zum einen "prominenter", und zum anderen innerhalb der sonst üblichen Logik...

Da wir grad beim "Kleben von Etiketten" sind: "rhasspySpeechDialog" statt "rhasspySTT"? (Analog zu "rhasspyMsgDialog").
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 05 April 2022, 12:59:15
Zitat von: Beta-User am 05 April 2022, 12:54:04
Das Problem: "Tweaks" finden sich in der Regel irgendwo im "helper" wieder, das meiste aus DEF (sei es implizit, sei es explizit) kommt als direkt sichtbares Internal. Das da zu lassen, ist zum einen "prominenter", und zum anderen innerhalb der sonst üblichen Logik...

Jetzt bin ich verwirrt...
Ja, eh in der DEF. Dachte es ging nur darum, ob man in Tweaks oder als Attribut das in der DEF konfigurierte Verhalten ändern kann.

ZitatDa wir grad beim "Kleben von Etiketten" sind: "rhasspySpeechDialog" statt "rhasspySTT"? (Analog zu "rhasspyMsgDialog").
Kann ich nicht sagen. Weiß wieder mal nicht, was das ist ;D
STT heißt für mich in dem Kontext aber SpeechToText
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 05 April 2022, 13:27:39
Zitat von: drhirn am 05 April 2022, 12:59:15
Ja, eh in der DEF. Dachte es ging nur darum, ob man in Tweaks oder als Attribut das in der DEF konfigurierte Verhalten ändern kann.
"Eh" war die Frage. Ich war nahe dran, das da komplett rauszunehmen und eventuelle Abweichungen zum default rein auf Basis von einem Attribut-Wert zuzulassen. Aber in der DEF ist es eh' einfacher, auch, wenn man das zur Definitionszeit eigentlich noch nicht wissen muss...

Zitat
Kann ich nicht sagen. Weiß wieder mal nicht, was das ist ;D
STT heißt für mich in dem Kontext aber SpeechToText
Muss wohl etwas weiter ausholen:
Es gab "früher mal" zwei Attribute für STT und TTS (für die AMAD.*-Integration und "Babble"-Umleitung). "Irgendwann" ist dann "TTS" überflüssig geworden, weil eigentlich nur eine einzige Abgabe "zwingend" war, um das ganze in beide Richtungen (halbwegs) funktional zu bekommen (allowed). Da aber STT im allgemeinen nur für die eine Richtung steht, war die Bezeichnung eben "falsch" geworden, was jetzt in der Frage mündet, wie man das Kind denn umtaufen möchte....

(Prinzipiell funktioniert das, und die Sprachausgabe ist auch etwas angenehmer als bei Rhasspy-direkt; offen ist da aber ein Problem im Zusammenhang mit Dialogen bzw. Rückfragen, da puzzelt RHASSPY die (nacheinander kommenden) Teile wohl was noch nicht ganz korrekt zusammen bzw. baut ggf. manches auch nicht wieder korrekt ab, wenn ein "logischer Abschnitt" erledigt ist.)
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 05 April 2022, 13:31:22
Zitat von: Beta-User am 05 April 2022, 13:27:39
Es gab "früher mal" zwei Attribute für STT und TTS (für die AMAD.*-Integration und "Babble"-Umleitung). "Irgendwann" ist dann "TTS" überflüssig geworden, weil eigentlich nur eine einzige Abgabe "zwingend" war, um das ganze in beide Richtungen (halbwegs) funktional zu bekommen (allowed). Da aber STT im allgemeinen nur für die eine Richtung steht, war die Bezeichnung eben "falsch" geworden, was jetzt in der Frage mündet, wie man das Kind denn umtaufen möchte....
Ach so. Dann ist "rhasspySpeechDialog" eh ok.

Zitatdie Sprachausgabe ist auch etwas angenehmer als bei Rhasspy-direkt
Ach, mit Google WaveNet ist sie schon gut ;D
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 05 April 2022, 14:49:22
Kannst du mir bitte mal schreiben, wie die DEF ausschauen muss, wenn ich autoTraining verwenden will? Kapier's wiedermal nicht.
Und, was ist denn z.B. eine Aktion, die ein autoTraining auslösen würde?

Btw. wenn du beim Thema Version das Internal "FVERSION" gemeint hast, damit kann ich gut leben.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 05 April 2022, 14:58:21
Wenn irgendwo in der DEF dann ein "autoTraining=30" auftaucht, bedeutet das, dass RHASSPY 30 Sekunden wartet, z.B. nachdem du das letzte rhasspyMapping- oder rhasspyName-Attribut angefaßt hast.

Ob alles klappt, siehst du im list, da taucht dann (mindestens) "global" in NOTIFYDEF auf, und nach einer relevanten Änderung gibt's dann einen Eintrag unter "TIMER" (bis der ausgeführt wurde).

Was das Internal FVERSION angeht: das gibt's afaik nur, wenn der Installer aktiv ist - aber eine ähnliche Ausgabe erhält man auf jedem System via "version RHASSPY". Damit ist das manuell gepflegte MODULE_VERSION wohl Geschichte...?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 05 April 2022, 15:10:54
Zitat von: Beta-User am 05 April 2022, 14:58:21
Wenn irgendwo in der DEF dann ein "autoTraining=30" auftaucht, bedeutet das, dass RHASSPY 30 Sekunden wartet, z.B. nachdem du das letzte rhasspyMapping- oder rhasspyName-Attribut angefaßt hast.

Ob alles klappt, siehst du im list, da taucht dann (mindestens) "global" in NOTIFYDEF auf, und nach einer relevanten Änderung gibt's dann einen Eintrag unter "TIMER" (bis der ausgeführt wurde).
Hmm, bei mir tut sich nichts.

ZitatDamit ist das manuell gepflegte MODULE_VERSION wohl Geschichte...?
Keine Einwände
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 05 April 2022, 15:27:26
version = 25920?

Das funktioniert erst mit dem letzten update.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 05 April 2022, 15:30:17
25920 2022-04-05 05:38:54Z Beta-User


defmod Rhasspy RHASSPY baseUrl=http://rhasspy:12101 defaultRoom=wohnzimmer language=de autoTraining=30
attr Rhasspy languageFile ./FHEM/rhasspy-de.cfg
attr Rhasspy room System
attr Rhasspy verbose 5


bzw.


Internals:
   CONFIGFILE ./FHEM/rhasspy-de.cfg
   DEF        baseUrl=http://rhasspy:12101 defaultRoom=wohnzimmer language=de autoTraining=30
   FUUID      60a4f0b5-f33f-b353-61c1-92d87e5ee0719dd3
   FVERSION   10_RHASSPY.pm:0.259200/2022-04-05
   IODev      rhasspyMQTT2
   LANGUAGE   de
   NAME       Rhasspy
   NR         39
   NTFY_ORDER 50-Rhasspy
   STATE      online
   TYPE       RHASSPY
   autoTraining 30
   baseUrl    http://rhasspy:12101
   defaultRoom wohnzimmer
   devspec    genericDeviceType=.+
   disableNotifyFn 1
   encoding   utf8
   fhemId     fhem
   prefix     rhasspy
   siteId     defhem
   useGenericAttrs 1
   TIMER:
   helper:
     devicemap:
       devices:
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 05 April 2022, 15:54:29
Hmm, komisch...

Auf meiner Hauptinstanz ist noch AMAD&Co aktiv, da sieht das NOTIFYDEV nochmal anders aus, und auf der Testinstanz ist schon wieder was geändert. Na ja, dann versuch's halt nochmal mit der, bitte...

(Die sollte den Key schon nicht mehr nicht brauchen).

EDIT:
Habe eben nochmal die svn-Version "pur" runtergeladen. Da wird auf meinem Testsystem NOTIFYDEV ordnungsgemäß ermittelt. Schräg...
DEF        baseUrl=http://192.168.33.1:12101 language=de autoTraining=20
IODev      m2client
LANGUAGE   de
NAME       RHASSPY
NOTIFYDEV  global


Hab' grad keine Idee, wo das Problem liegen könnte :-[ .
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 05 April 2022, 16:42:28
Bei meiner Docker-Installation zuhause hat's auch nicht geklappt.

In meinem produktiven System (DEB-Installation) allerdings auf Anhieb:


   TIMER:
     Rhasspy_autoTraining:
       HASH       Rhasspy
       MODIFIER   autoTraining
       NAME       Rhasspy_autoTraining


Das ist etwas merkwürdig
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 05 April 2022, 16:48:59
Unterschied Docker <-> Prod:

disableNotifyFn 1

Kann das ein Grund sein? Und wie bekomm ich das weg?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 05 April 2022, 17:00:32
Ist das FHEM auf der docker-Installation aktuell?

Die Funktion zum Setzen des NOTIFYDEV via devspec ist noch nicht besonders alt (setNotifyDev()), und wenn NotifyFn() aktiviert werden soll, muss dieser Command durchlaufen. Das Deaktivieren geht dagegen auch mit einer etwas älteren fhem.pl (notifyRegexpChanged () - die setzt dann auch das Internal auf 1). Wenn es das ist, ist nur komisch, dass das Modul überhaupt lädt... (OK, hab's grade testweise mit was anderem versucht - die Existenz einer zu importierenden Funktion wird nicht geprüft...) Aber schmiert FHEM dann nicht ab...? Sehr seltsam, das!

EDIT: siehe https://svn.fhem.de/trac/changeset/25541/trunk/fhem/fhem.pl und https://forum.fhem.de/index.php/topic,125381.0.html
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 05 April 2022, 17:12:40
Verwende das Image fhem:dev. Und ein Update hab ich vor dem Test gemacht. Also alles aktuell.

Image fhem:latest macht - wie erwartet - keinen Unterschied
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 05 April 2022, 17:23:15
Hmm, bin grad etwas verloren. Das wäre - neben der Abwesenheit der Funktion - eigentlich nur nachvollziehbar, wenn
{devspec2array('global')}
kein Ergebnis liefern würde...

Die relevanten Codezeilen sind ab #1581 zu finden, vielleicht unmittelbar vor der letzten Abfrage (#1594) mal eine Logausgabe einbauen, was bis dahin in $devsp steht?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 05 April 2022, 17:43:55
"disable_msgDialog" wird bei mir nicht ausgeführt
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 05 April 2022, 17:52:01
Aha, in der einen Installation gibt es anscheinend ein msgConfig, in der anderen nicht...

(Nicht eben übersichtlich, diese Indirektionen ::) ...)

Kannst du mal am Ende von #1537 noch eine Abfrage einbauen?
return 'No global configuration device defined: Please define a msgConfig device first' if !$modules{msgConfig}{defptr} && $attrVal;
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 05 April 2022, 17:59:52
Zitat von: Beta-User am 05 April 2022, 17:52:01
Kannst du mal am Ende von #1537 noch eine Abfrage einbauen?
return 'No global configuration device defined: Please define a msgConfig device first' if !$modules{msgConfig}{defptr} && $attrVal;

Fieser Edit ;D

Ja, jetzt funktioniert's.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 05 April 2022, 19:19:36
Zitat von: drhirn am 05 April 2022, 17:59:52
Fieser Edit ;D
::) Ups, da warst du aber schnell...

Zitat
Ja, jetzt funktioniert's.
Habe diese Version jetzt wieder ins svn eingecheckt, weil jetzt auch fortgesetzte Dialoge über AMAD.* klappen. Jetzt könnte man sich dran machen, das Event auszuwerten, das nach Abschluss des speak commands erscheint, um dann das Mikro wieder anzuschalten:
lastSetCommandState setCmd_done
Dazu muss das AMADDevice aber erst mal nach NOTIFYDEV... (ein andermal...)
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 06 April 2022, 16:04:55
Hatte hier jemand Pizza Quattro Stagioni bestellt?!?

Zitat von: JensS am 04 April 2022, 18:26:22
Nun, meinen Vorschlag hast du ja. Ob du was draus machst, ist natürlich dir überlassen.

Ich hätte eine über, sehr frisch aus dem Ofen :P . Also Vorsicht: könnte sehr heiß sein, zu scharf, whatever...

Was bringt die?
Man kann (vorerst) dem Intent "SetOnOff" "fremde" bzw "zu viele" Datenfelder übergeben, also z.B.:

- Device 1 + Device 2 + Device(n)
-- zu übergebende Keys: {Device}, {Devicex}; (sicherheitshalber sollte man {Device} in diesen Fällen immer als erstes bzw. mindestens füllen);
-- für jedes {Devicex} muss halt der Schlüsselnamen mit "Device" beginnen, der Rest sollte beliebig sein;
-- Trockenübung mit {Device} und {Device1} hat funktioniert,

- Device 1 + Gruppe a
(noch nicht getestet, ad {Device} siehe oben),

- "Device mit Name xy" in Raum 1 + Raum 2
-- ad {Device} s.o., die Room-Keys sind dann wieder wie bei den Devices, also der erste am besten {Room}, der Rest {Roomx} mit "x" für irgendwas;
-- grob angetestet,

- "Device mit Name xy" + "Device mit Name YZ" in Raum a + Raum b
(noch nicht getestet, ad {Device}/{Room} siehe oben).

Das ganze ist generisch angelegt, im Prinzip sollte sich mit wenig Code-Änderung in den Einzelintents mehr oder weniger alles von Einzel- auf Gruppen-Intent umbiegen lassen, was heute da ist, und auch die Gruppen-Intents müßten sich relativ zwanglos aufbohren lassen 8) .

Bestätigungen habe ich erst mal noch nicht dazugenommen, kann aber sein, dasss auch das bereits funktioniert. Prinzipiell wird erst mal alles gesammelt und geschaut, ob ein Device bzw. eine Gruppe dabei ist, die so oder so eine Bestätigung haben will, wenn ja, ist die für alles erforderlich (einmalig).
Dazu gibt es noch einen speziellen Gruppen-Namen "virtualGroup", unter dem man für sowas noch eine eigene Bestätigungsanforderung anfordern kann.
Intern findet ein Wechsel vom Einzel- zum Gruppen-Intent statt, was bedeutet, dass
- für eventuelle Bestätigungen auch ein eventuell gesetzter Tweak für allgemeine Gruppen-Schaltanweisungen beachtet wird, und
- ggf. "partOf"-Anweisungen für Gruppenschaltungen an den beteiligten Devices relevant werden (z.B. wenn man statt eines Geräts dann auf eine HUE-Gruppe oder FHEM-structure verwiesen hat)

Vermutlich haben jetzt alle viele Fragezeichen auf der Stirn? Dann erst mal ausprobieren, eventuelle Probleme melden und wegen der ggf. in der Beschreibung hier unklaren Details vorab mal rund um https://wiki.fhem.de/wiki/RHASSPY/Vertiefung#Gruppen-Intents (https://wiki.fhem.de/wiki/RHASSPY/Vertiefung#Gruppen-Intents) nachlesen.

Falls es aus der Einleitung nicht klar geworden war: Nutzung auf eigenes Risiko!

PS: Da ist dann noch etwas weitgehend ungetesteer Code drin für
- Event-Handling betr. das Wiedereröffnen des Mikros@AMAD.* und
- das Thema "continous dialogues".
Kann sein, dass es insbesondere im Hinblick auf letzteren Punkt auch einige regressions gibt ::) ...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 06 April 2022, 17:32:59
Zitat von: Beta-User am 06 April 2022, 16:04:55
Hatte hier jemand Pizza Quattro Stagioni bestellt?!?
Danke, hab sie gleich gegessen, obwohl sie noch heiß ist. ;)
Licht im Wonhzimmer und im Flur an.  = läuft
Licht und Stehampe im Wohnzimmer an. = läuft
EDIT: Licht und Stehlampe an. = Licht im Schlafzimmer und Stehlampe im Wohnzimmer gehen an
Zu weiteren Tests komme ich später.

Gruß Jens
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 06 April 2022, 17:48:26
 :)
Kurz nachgedacht, und ja, das mit 2 Devices und keinem Raum ist eine Lücke, wenn die nicht beide in dem "Sprechraum" sind, muß mal schauen, wie man diesen "Sonderfall" abfangen kann.

Was mich (leider) mehr beschäftigt:
Eventuell gibt es ein größeres Problem, wenn man die messenger-Schnittstelle anspricht (wenn das das Problem ist, gilt das vermutlich identisch für AMAD.*). Bitte also im Moment diese Schnittstellen vorsichtshalber nicht benutzen!
Muss aber auch erst mal schauen, wo das Problem genau liegt, kann dauern...

EDIT: Aber das mit der raumlosen "Sammlung" scheint mit dem Anhang hier jetzt zumindest mal zu klappen...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 06 April 2022, 18:34:57
Funktioniert noch nicht.

"Licht" ist jeweils die Deckenbeleuchtung in jedem Raum.

Bei "Licht an" - gesprochen im WZ, geht das Licht im WZ an.
Bei "Licht und Stehlampe" an - gesprochen im WZ, geht jetzt das Licht im Flur und die Stehleuchte im WZ an.
Bei "Licht und Stehlampe im Wohnzimmer an" - gehen Licht und Stehlampe im WZ an.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 07 April 2022, 10:48:12
Zitat von: JensS am 06 April 2022, 18:34:57
Funktioniert noch nicht.
Ok, irgendwie nachvollziehbar...

Die Fassung im Anhang sollte das geringfügig besser machen, komplett lösen läßt sich ein an der Stelle sichtbar werdendes Grundproblem allerdings nicht (s.u.).

Vorab aber die Info: Die messenger-Schnittstelle war in der Tat kaputt, das ist jetzt wieder auf einem (hoffentlich) funktionierenden Stand (testen kann ich den Teil aber voraussichtlich erst am WE), ob AMAD.* klappen, kann ich auch noch nicht sagen. Für den Teil ist jetzt eine Erweiterung der NotifyFn() drin, der "activateVoiceInput" ausführen sollte, wenn eine Sprachausgabe fertig ist und der Dialog fortgesetzt werden soll (wie erwähnt: ungetestet!).

Nun zum Grundproblem:
Zitat
"Licht" ist jeweils die Deckenbeleuchtung in jedem Raum.
Wir lassen "relativ unpräzise" Anweisungen zu und versuchen daher, aus den ggf. sehr spärlichen Infos den (z.B. für eine Schalt-Anweisung erforderlichen) "Rest" zu ermitteln. Wenn sich dann ergibt, dass etwas nicht geht, stellt sich die Frage, was passieren soll. Ergibt sich aus dem Kontext des Intents ("SetOnOff") und des Sprach-Raums ("siteId") nichts eindeutiges, bekommt man eine Rückmeldung.

Wird die Eindeutigkeit durchbrochen (z.B. durch ein weiteres {Devicex}), stellt sich die Frage, was passieren soll, wenn nur ein Teil "aufgelöst" werden kann. Bisher läuft der Code kommentarlos durch und schaltet halt, was ermittelt werden konnte.

Besser (optimal?) wäre es, wenn man zusätzlich zu "erledigt" dann noch die Info bekommen würde, dass (und welche) Teile eben nicht zugeordnet werden konnten. Dann wird aber die Antwortlogik nochmal deutlich komplexer als bisher...
In Ansätzen sind Gedanken dazu da, (u.a.) daher auch noch eine kleine Erweiterung der de-cfg. Aber das so umzusetzen, dass es komplett (=in allen denkbaren Verästelungen!) funktioniert, dürfte was größeres werden.

Zitat von: JensS am 06 April 2022, 17:32:59
EDIT: Licht und Stehlampe an. = Licht im Schlafzimmer und Stehlampe im Wohnzimmer gehen an
Falls das mit der Ausgangsversion so war, stellt sich die Frage nach dem Kontext. Die beigefügte Version dürfte de facto wieder dasselbe Ergebnis bringen, allerdings auf einem anderen Weg ermittelt, und es sollte identisch zu dem sein, was auch je eine einzelne Anweisung ergeben hätte.

Falls ich dazu noch was im Detail nachvollziehen soll, bräuchte ich etwas mehr Kontext. (Die Zwischenversion von gestern abend hatte die Rauminfo ganz gelöscht, und das war nun auch wieder des Guten zu viel...).
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 07 April 2022, 11:27:34
Nachträge noch:
- Mit einer (zusätzlichen) Gruppen-Angabe scheint es auch durchzulaufen.
- Das "Eindeutigkeits-Thema" hat auch (schon immer) eine Kehrseite: Wenn man einen Raum angibt, darin aber das explizit angefragte Gerät gar nicht vorhanden ist (aber sonst irgendwo), wird das Gerät "trotzdem" geschaltet. "Eigentlich" müßte der Code einen Unterschied machen, ob die Raum-Info "nur" aus dem "Sprach-Raum" abgeleitet ist, oder ob sie explizit angewiesen gewesen war. Spannend...

Um den letzten Punkt eventuell etwas zu verdeutlichen: "Mach die Nachtischlampe aus" gesprochen/erkannt im Wohnzimmer, ergibt vermutlich keine Irritationen, wenn dann im Schlafzimmer ein Schaltvorgang ausgelöst wird. Wird von der Spracherkennung aber "Mach die Nachtischlampe im Wohnzimmer aus" geliefert, impliziert das, dass der Sprecher entweder ein anderes Gerät oder einen anderen Raum meint - oder die Spracherkennung ggf. falsch war; eigentlich sollte man sowas dann "dialogisch" klären.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 07 April 2022, 16:44:39
...das mit dem
Zitat von: Beta-User am 07 April 2022, 11:27:34
"Mach die Nachtischlampe aus" [...] "Mach die Nachtischlampe im Wohnzimmer aus"
hat mir keine Ruhe gelassen...

Also Code angeschaut, und siehe da: Wenn man keinen Match im Room hatte, kam danach ein "for (keys ...)" gefolgt von einem "wenn 'das' paßt, gib 'das' zurück". Jetzt muss man dazu wissen, dass ein solcher Zugriff zu zufälligen Ergebnissen (!) führt! (Jedenfalls dann, wenn es nicht aus anderen Gründen eindeutig ist - wer CUL_HM nutzt und Anfang letzten Jahres ein update gemacht hatte, kann vielleicht nachvollziehen, was das in etwa bedeutet).
Wie dem auch sei - es kam der "Autsch, das geht ja mal gar nicht"-Impuls...

Ergebnis anbei, wie "üblich" in großen Teilen ungetestet...

News da drin:
- die zentrale Funktion zur {Device}=>FHEM-Name-Findung akzeptiert ein paar weitere Argumente, mit denen sich insbesondere feststellen läßt, ob es ein "abgeleiteter" Raumname ist, oder ob der schon in den Ausgangsdaten drin war;
- wenn ja: match im Room ist zwingend! (=> Änderung im Verhalten!)
- wenn nein:
-- ein "sort"-Pflaster für den Zugriff auf die Raum-"keys" (=> gesteuerterer Zufall);
-- Beachtung von "priority outsideRoom" (kann sein, dass das nicht funktioniert) => erster match = Ergebnis;
-- Sammlung aller passend benannter Devices
=> genau eines? => Ergebnis;
=> keins oder mehr als eines? => kein Ergebnis. (=> Änderung im Verhalten!)

Ansonsten ist noch "überall" der Wechsel von Einzel- (bzw. Mehrfach-Gruppe oder -Raum) zu Gruppen-Intent reingeknödelt (also überall da, wo es einen Intent mit "Group" am Ende gibt).

Mal sehen, was ihr dazu meint...

EDIT: kleines update, das ggf. noch "false dupes" aussortiert, wenn ein und dasselbe Device in mehreren Räumen zu finden ist...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 07 April 2022, 18:23:56
Wow, ich bin begeistert!

Alles Folgende ist im Wohnzimmer gesprochen.
Licht im Wonhzimmer und im Flur an.  = läuft
Licht und Stehampe im Wohnzimmer an. = läuft
Licht und Stehlampe an. = läuft
Nachttischlampe und Licht an. = läuft (Nachttischlampe im SZ un Licht im WZ)
Flurlicht und Nachttischlampe an. = läuft
Licht und Nachttischlampe im Flur an. = läuft (Licht im Flur und Nachttischlampe im SZ)
u.v.m....

Gruß Jens
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 07 April 2022, 19:07:50
Zitat von: JensS am 07 April 2022, 18:23:56
Wow, ich bin begeistert!
8) Das hört man doch gerne!

Aber:

Licht und Nachttischlampe im Flur an. = läuft (Licht im Flur und Nachttischlampe im SZ)

Das ist nach meinem Verständnis noch ein bug, weil die Beschränkung auf "Flur" übergangen wird. Aber sonst klingt es doch erst mal ganz ok.... ::)
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 07 April 2022, 19:17:08
Es gibt nur eine Nachttischlampe in der Rhasspy-Devicelist. Von daher finde ich es gut, dass ein eindeutiges Device bedient wird.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 07 April 2022, 19:46:30
Es ist und bleibt eine Überschreitung einer vom User gesetzten Grenze, wenn ein Raum genannt ist (aber auch nur dann)...!
Imo ein bug...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 08 April 2022, 17:55:34
Zitat von: Beta-User am 07 April 2022, 19:46:30
Es ist und bleibt eine Überschreitung einer vom User gesetzten Grenze, wenn ein Raum genannt ist (aber auch nur dann)...!
Imo ein bug...
Na ja, jedenfalls am Testsystem scheint das Verhalten hier anders gewesen zu sein, also: keine Schaltung, was außerhalb ist.

Wie dem auch sei, habe mal noch versucht, da eine Bestätigungsanfrage mit reinzubasteln, mit Hinweis, was nicht paßt. Hoffe, der Code ist so flexibel, dass man dann ggf. an zentraler Stelle noch irgendeine Option reinfrickeln kann, mit der man das Verhalten dann noch umschalten können könnte....

Die Zahl der keys in den möglichen Antworten ist nochmal gewachsen, bei Gelegenheit liefere ich dann ggf. noch die de-Fassung nach (falls nicht jemand schneller ist).

Viel Spaß beim Testen, wobei es klasse wäre, wenn das jemand erst mal auf ein größeres Testsystem loslassen könnte... Mal sehen, zu was ich am WE in der Hinsicht komme ::) .
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 08 April 2022, 18:06:37
Hmm, Licht und Nachttischlampe im Flur an = Licht im Flur an + Nachttischlampe aus + Ausgabe: "Ok, mach ich."
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 08 April 2022, 18:27:32
Hmmm, keine 2. Schaltung; gut. Keine Rückfrage: nicht gut...

Neustart ist übrigens Pflicht, macht aber in der Hinsicht wohl keinen Unterschied.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 08 April 2022, 18:31:16
reload und def sollte reichen - oder?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 08 April 2022, 18:38:58
...kann sein. Kann grad nicht testen, man sollte es im lng-Abschnitt sehen, ob da mehr engl. Sätze auftauchen...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 08 April 2022, 18:40:44
Ich nutze den FHEM-internen Editor, der lädt das Modul zwangsweise neu.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 09 April 2022, 07:21:10
....habe auf dem Hauptsystem eh' einen update gemacht. Testergebnis und Schaltverhalten in der Realität stimmen soweit erkennbar überein:

Zitattest(s) passed successfully. Summary: Test ok, result is: schalt das licht am esstisch und das radio an => SetOnOff {"Device":"licht am esstisch","Device1":"radio","Value":"on","confidence":1,"customData":null,"input":"schalt das licht am esstisch und das radio on","intent":"SetOnOff","lang":"de","rawInput":"schalt das licht am esstisch und das radio an","sessionId":"defhem_0_testmode","siteId":"defhem"} => redirected group intent (SetOnOffGroup), adressed devices: Licht_Essen,Yamaha_Main
Zitattest(s) passed successfully. Summary: Test ok, result is: schalt das licht am esstisch und das radio im garten an => SetOnOff {"Device":"licht am esstisch","Device1":"radio","Room":"garten","Value":"on","confidence":1,"customData":null,"input":"schalt das licht am esstisch und das radio im garten on","intent":"SetOnOff","lang":"de","rawInput":"schalt das licht am esstisch und das radio im garten an","sessionId":"defhem_0_testmode","siteId":"defhem"} => Response: Du hast widersprüchliche Angaben gemacht: licht am esstisch und garten passen nicht zusammen. Soll licht am esstisch mit dem Namen und dem besprochenen Gerät ermittelt werden?

Zitattest(s) passed successfully. Summary: Test ok, result is: schalt das licht am esstisch und das radio im garten und im esszimmer an => SetOnOff {"Device":"licht am esstisch","Device1":"radio","Room":"garten","Room1":"esszimmer","Value":"on","confidence":1,"customData":null,"input":"schalt das licht am esstisch und das radio im garten und im esszimmer on","intent":"SetOnOff","lang":"de","rawInput":"schalt das licht am esstisch und das radio im garten und im esszimmer an","sessionId":"defhem_0_testmode","siteId":"defhem"} => redirected group intent (SetOnOffGroup), adressed devices: Licht_Essen,Yamaha_Zone2

Beispielsatz dazu:
[de.fhem:SetOnOff]
rooms=([(im|in dem|auf dem|in der|auf der)] $de.fhem.Room{Room})
morerooms=([[und] (im|in dem|auf dem|in der|auf der)] $de.fhem.Room{Room1})
devSetOnOff=($de.fhem.Device-SetOnOff{Device})
onOff=((an|ein){Value:on}|aus{Value:off})
den=(den|die|das)
cmdmulti=(schalte|schalt|mache|mach|stelle|stell)

(<cmdmulti>|starte) [<den>] <devSetOnOff> [[und] [<den>] $de.fhem.Device-SetOnOff{Device1}] [<rooms> [<morerooms>]] <onOff>


Es gab/gibt ggf. noch eine "unitialized"-Warnung in 1997, die dann für alle bei der nächsten Iteration erledigt sein wird, sonst ist mir auf die Schnelle nichts aufgefallen.

Da die erweiterte de-cfg auch mit der bisherigen svn-Version funktionieren sollte, habe ich die eben zusammen mit was anderem direkt im svn hinterlegt.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 09 April 2022, 08:53:31
Danke für die neuer Version aber in den nächsten Tagen komme ich nicht zum testen.
Kann man {Room} weglassen und gleich {Room1} schreiben?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 09 April 2022, 09:22:47
Zitat von: JensS am 09 April 2022, 08:53:31
Danke für die neuer Version aber in den nächsten Tagen komme ich nicht zum testen.
Kann man {Room} weglassen und gleich {Room1} schreiben?
Kann sein, dass das geht, wäre nicht schlecht, wenn es jemand testen würde...

Hier noch ein update, das dann auch das AMADDevice-voiceInput wieder aktiviert, wenn eine Rückfrage kommt :) .
Aber auch hier der Hinweis: scheint prinzipiell zu funktionieren, vertieft getestet ist es noch nicht, gelegentliches save statefile vor/während des Testens ist anzuraten ::) .
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 09 April 2022, 09:37:56
So, nun wird gerade gar nichts mehr geschaltet. Das kann ich mir nochmal abends ansehen.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 09 April 2022, 11:12:23
Das ist komisch, schon gleich, wenn gar keine Rückmeldung seitens RHASSPY erfolgt (?). Kann im Moment keine größeren Probleme feststellen...

Zitat von: JensS am 09 April 2022, 08:53:31
Kann man {Room} weglassen und gleich {Room1} schreiben?
Hmm, nach etwas Nachdenken: Für "multi"-Anweisungen ist es egal, aber bei "normalen" Kommandos "mach das licht in der küche an" wird dann {Room1} nicht nach {Room} "geloopt" => kann passen, muss nicht...

Jedenfalls für den Moment sehe ich auch keine Notwendigkeit, in diese Richtung was anzupassen (besonders kompliziert wäre es allerdings vermutlich nicht, diese Art Sonderfall abzufangen).
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Prof. Dr. Peter Henning am 10 April 2022, 10:27:23
Nachdem ich jetzt ein paar Wochen fast FHEM-abstinent war (too much to do): Könntet Ihr mal die aktuellen Ergänzungen zu FEST.txt in dem Thread hier posten? https://forum.fhem.de/index.php/topic,126864.0.html

Ich habe außerdem das große Problem, dass ich der Unterhaltung hier immer nur sporadisch folgen kann - und dann fehlt bei vielen Posts der Kontext. Vorschlag: Im allerersten Post des Threads auf wichtige Zwischenergebnisse hinweisen, mit Link auf den entsprechenden Post. Das ist zwar mehr Arbeit, lohnt sich aber im Endeffekt.

LG

pah

Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 10 April 2022, 10:51:44
Hmm, also:
- Die Sätze (einschl. der letzten Ergänzungen wegen "multi-Commands") und die komplettierte Datei sind jetzt auch wie gewünscht in deinem allgemeinen Thread zu finden.
- die geraffte Zusammenfassung der "news" zu RHASSPY ist im 0.5-er "offene Themen" zu finden. Da habe ich bisher nur das "multi-command-feature" nicht separat herausgehoben, das braucht noch Tests. Funktionieren sollte jetzt aber (mit der gestern hier angehängten Version) insbesondere auch AMAD.* (!).
- Werde mal überlegen, ob die Developer-Version ggf. im ersten Post der "offenen Themen" besser aufgehoben wäre, andererseits bin ich geneigt, die recht direkt wieder ins svn zu übernehmen - vorausgesetzt, es gibt wegen der "multi-command-feature"-Sache keinen Einspruch seitens @drhirn. Das ganze ist etwas sehr spontan entstanden und enthält doch jetzt einige tiefergreifende Eingriffe in den Code...

Insgesamt ist dieser Thread in der Tat zwischenzeitlich sehr lang und wenig geeignet, "normale User" auf dem Laufenden zu halten. Das war der Grund für den "offene Punkte"-Thread. Vielleicht sollten wir irgendwann hier auch einfach wieder zumachen, das meiste findet sich ja dann doch jetzt im Wiki etc.. M.E. wäre der richtige Zeitpunkt dann, wenn ein paar mehr Rückmeldungen zum "multi-command-feature" da sind und die Entwicklung der aktuellen Evolutionsstufe soweit als abgeschlossen betrachtet werden kann?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 11 April 2022, 09:39:21
Zitat von: Beta-User am 10 April 2022, 10:51:44
vorausgesetzt, es gibt wegen der "multi-command-feature"-Sache keinen Einspruch seitens @drhirn. Das ganze ist etwas sehr spontan entstanden und enthält doch jetzt einige tiefergreifende Eingriffe in den Code...
Kein Einspruch. Funktioniert eh schon erstaunlich gut.

ZitatInsgesamt ist dieser Thread in der Tat zwischenzeitlich sehr lang und wenig geeignet, "normale User" auf dem Laufenden zu halten. Das war der Grund für den "offene Punkte"-Thread. Vielleicht sollten wir irgendwann hier auch einfach wieder zumachen, das meiste findet sich ja dann doch jetzt im Wiki
"Normale" User sollten bei Fragen eigene Threads aufmachen. Der kann ruhig für uns offen bleiben.
Aber ich könnte im ersten Beitrag anmerken, dass es bessere Informationsquellen als diesen Thread gibt?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 11 April 2022, 11:16:08
Zitat von: drhirn am 11 April 2022, 09:39:21
Kein Einspruch. Funktioniert eh schon erstaunlich gut.
8)
Habe noch ein paar kleinere offene Punkte damit, die sich aber auch recht einfach fixen lassen sollten (bzw. wo ich die Fixes noch testen muss):
- Beim Testen per File hatte ich eine "Echt-Schaltung" (Ursache vermutlich lokalisiert/gefixt)
- Bin nicht sicher, ob die Erkennung immer klappt, dass eine Bestätigung erforderlich/erwünscht ist (falls jemand was ähnliches feststellt, wären die Rahmenbedingungen interessant, um das ggf. nachvollziehen zu können; ist vermutlich wenn, dann auch nur eine Kleinigkeit).
- Doku... (commandref, ggf. auch Wiki)

Zitat
"Normale" User sollten bei Fragen eigene Threads aufmachen. Der kann ruhig für uns offen bleiben.
Keine Einwände.

Zitat
Aber ich könnte im ersten Beitrag anmerken, dass es bessere Informationsquellen als diesen Thread gibt?
Schadet sicher nicht, ein paar (kurze) Hinweise aufzunehmen, wo ggf. was zu finden ist. Ich werde dann auch dazu übergehen, das nächste "pre-release" vielleicht dann über den ersten Beitrag in "Offene Themen" anzupinnen (falls es nicht direkt per svn kommt, die aktuellste scheint ja (bei 3 Testern?) im wesentlichen keine Probleme zu machen.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 11 April 2022, 11:20:23
Zitat von: Beta-User am 11 April 2022, 11:16:08
Schadet sicher nicht, ein paar (kurze) Hinweise aufzunehmen, wo ggf. was zu finden ist.
Ist schon erledigt.

ZitatIch werde dann auch dazu übergehen, das nächste "pre-release" vielleicht dann über den ersten Beitrag in "Offene Themen" anzupinnen (falls es nicht direkt per svn kommt, die aktuellste scheint ja (bei 3 Testern?) im wesentlichen keine Probleme zu machen.
Nein, bitte nicht. Mir ist lieber, die hängen da in den Beiträgen. Dann kann ich auf GitHub als Commit-Message einfach nur die ID der Nachricht (bzw. den Link drauf) anhängen. Sonst weiß ich unter Umständen nicht mehr genau, in welchem Beitrag zugehörige Änderungen erklärt werden.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 11 April 2022, 11:43:02
Zitat von: drhirn am 11 April 2022, 11:20:23
Ist schon erledigt.
Thx!

Zitat
Nein, bitte nicht. Mir ist lieber, die hängen da in den Beiträgen. Dann kann ich auf GitHub als Commit-Message einfach nur die ID der Nachricht (bzw. den Link drauf) anhängen. Sonst weiß ich unter Umständen nicht mehr genau, in welchem Beitrag zugehörige Änderungen erklärt werden.
Na ja, dieses Prinzip brauchst du deswegen ja eigentlich nicht aufzugeben. Ob das jeweils dann direkt im "Kommentar-Beitrag" angepinnt war oder irgendwo anders, oder aus dem svn per download kommt, ist ja sekundär.

Und jetzt sollte es auch wieder "ruhiger" zugehen, so dass dann ggf. die Infos, was wie zu verwenden ist, dann auch wieder aus der Doku entnommen werden kann (bzw. diese Hinweise dann da auch nachgepfelgt werden, wenn sie fehlen).

Was Doku betrifft: Im Wiki fehlen - soweit ich das im Kopf habe - v.a. die noch Intent-Beschreibungen sowie passende "sentences", oder?
UU. ist auch nicht ganz aktuell, was mindestens geliefert werden muss. Z.B. "mach wärmer" sollte vermtlich lt. Doku nicht gehen, klappt aber faktisch (jedenfalls prinzipiell).

Generell noch: Was die Einrichtung angeht, stellt sich ja jetzt mit der Option der "Testsuite" (und des "AMAD.+"-Wegs) die Frage, wie man User am besten durch die Doku lotst, damit die schnell finden, wie sie bestimmte Anforderungen umgesetzt bekommen.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 11 April 2022, 12:06:49
Zitat von: Beta-User am 11 April 2022, 11:43:02
Was Doku betrifft: Im Wiki fehlen - soweit ich das im Kopf habe - v.a. die noch Intent-Beschreibungen sowie passende "sentences", oder?
UU. ist auch nicht ganz aktuell, was mindestens geliefert werden muss. Z.B. "mach wärmer" sollte vermtlich lt. Doku nicht gehen, klappt aber faktisch (jedenfalls prinzipiell).
Ich hab da leider den Überblick verloren. Nach der Grund-Erstellung der Artikel habe ich mich (wie angekündigt) nicht mehr darum gekümmert. Und bekomme auch leider keine Benachrichtigungen, wenn sich an den Artikel was ändert.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 11 April 2022, 12:24:35
Zitat von: drhirn am 11 April 2022, 12:06:49
Ich hab da leider den Überblick verloren. Nach der Grund-Erstellung der Artikel habe ich mich (wie angekündigt) nicht mehr darum gekümmert. Und bekomme auch leider keine Benachrichtigungen, wenn sich an den Artikel was ändert.
:)
War auch eher als Feststellung gemeint...
(Ich habe nur leider zwischenzeitlich so komplexe Sätze, dass man das kaum einem Einsteiger erklären kann, was das soll. Zudem braucht man dazu eigentlich den Gesamtkontext => muss mir was überlegen, wie man das ggf. aufbereiten kann...

PS:
Um schnell zu sehen, wer was in welchem Umfang geändert hat, kann man auch das Wiki befragen, z.B. mit
https://wiki.fhem.de/wiki/Spezial:Letzte_%C3%84nderungen?hidebots=1&limit=50&days=7&enhanced=1&urlversion=2 oder dem Aufruf der Änderungsgeschichte zu einem Artikel.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Prof. Dr. Peter Henning am 11 April 2022, 13:16:21
ZitatIch hab da leider den Überblick verloren.
Das spricht mir aus der Seele. Fachlich habt ihr das sehr gut vorangetrieben, keine Frage - aber der Einsteiger sieht hier den Wald vor Bäumen nicht.

LG

pah
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 11 April 2022, 13:49:04
Nun ja, man muss (v.a. als Einsteiger) auch nicht vom Stand weg alle möglichen Optionen kennen - geschweige denn verstehen.

Was man immer braucht, sind
- eine funktionierende Rhasspy-"base", also einen Dienst, der entweder
-- "Sprache" (also Sound, via Mikro oder "abgesetztem Mikro" (=ESP32 oder Rhasspy-App)) entgegennimmt und das in Text umwandelt, oder
-- direkt Text entgegennimmt (z.B. von einer externen STT-Engine (z.B. via AMADDevice) oder einem Rhasspy-Satelliten),

und eine RHASSPY-Instanz, die
- FHEM-Devices in "Text-Bausteine" für diese Rhasspy-"base" liefert und
- den (vereinfacht) in key/Value-Paare umgewandelten Text entgegennimmt und dann in FHEM-Aktionen umsetzt.

An diesem Grundpinzip hat sich eigentlich seit Anbeginn nichts geändert ::) ...

Das ganze ist halt dann besonders schwierig zu überblicken, wenn man "alles auf einmal" einrichten und umsetzen will.

Da wir hier in "development" zu RHASSPY sind, hier noch die direkte Rückfrage zu dem hier:
Zitat von: Prof. Dr. Peter Henning am 11 April 2022, 13:21:37
1. Input: Was ist der Text, den das NLP-System bekommen hat?
Die Zeile bleibt entweder "pur" stehen oder es erfolgen weitere Infos. Wird ein explizites "not recognized" oder ähnliches gewünscht?

Zitat
2. Ergebnis: Was hat es daraus gemacht, i.e., was sind die Eckpunkte des Intents (Ort? Gerät? Zeit? Aufgabe?)
Hier kommen bei RHASSPY alle intern verfügbaren "keys" samt Werten. Ist das "to much"? Abspecken wäre relativ viel Aufwand, daher: eher ungern...

Zitat
3. Wenn "nur" eine Antwort erfolgte, wie lautete diese?
Kommt, wenn es eindeutig ist (s.u.).

Zitat
4. Wenn eine echte Aktion durchgeführt wurde, welches FHEM-Kommando wurde abgesetzt?
Bei Einzelanweisungen kommt die Info, wie der FHEM-Befehl aussehen würde bzw. ggf. auch Perl-Code. Eine Ausführung erfolgt nicht, daher ist uU. auch der Perl-Code halt "as is"... Sollte bis dahin ok sein (abgesehen davon, dass wir den einen offenen Punkt dazu noch hatten).

Wenn Gruppen adressiert werden, kann man das in RHASSPY nicht (bzw: vermutlich nicht ohne größeren Aufwand) so detailiert erfassen, m.E. sind aber die Angabe der Device-Namen iVm. Intent etc. soweit eindeutig, dass auch fortgeschrittene Einsteiger was damit anfangen können sollten.

Die eigentliche Frage dahinter, die für mich noch nicht eindeutig geklärt ist: Paßt das soweit, oder ist das eine "betriebsblinde" Sichtweise? (Rückmeldungen dazu fehlen bisher, von daher kann ich nur spekulieren...)
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Prof. Dr. Peter Henning am 12 April 2022, 04:44:46
Zitat1. Input: Was ist der Text, den das NLP-System bekommen hat?

Die Zeile bleibt entweder "pur" stehen oder es erfolgen weitere Infos. Wird ein explizites "not recognized" oder ähnliches gewünscht?
ich lasse die Zeile "pur" stehen.


Zitat2. Ergebnis: Was hat es daraus gemacht, i.e., was sind die Eckpunkte des Intents (Ort? Gerät? Zeit? Aufgabe?)

Hier kommen bei RHASSPY alle intern verfügbaren "keys" samt Werten. Ist das "to much"? Abspecken wäre relativ viel Aufwand, daher: eher ungern...
Kommt bei mir auch relativ viel Zeug. Müsste halt eingerückt sein, damit man es einfacher igrnorieren kann.

Zitat
    3. Wenn "nur" eine Antwort erfolgte, wie lautete diese?

Kommt, wenn es eindeutig ist (s.u.).
Stimmt. Sonst s.u.

Zitat
    4. Wenn eine echte Aktion durchgeführt wurde, welches FHEM-Kommando wurde abgesetzt?

Bei Einzelanweisungen kommt die Info, wie der FHEM-Befehl aussehen würde bzw. ggf. auch Perl-Code. Eine Ausführung erfolgt nicht, daher ist uU. auch der Perl-Code halt "as is"... Sollte bis dahin ok sein (abgesehen davon, dass wir den einen offenen Punkt dazu noch hatten).
Ebenso. Beispiele:
[Babble_DoIt] Input:    sag mir die feuchte im wohnzimmer
              Ergebnis: Category=2.1.7: Gerät=feuchte Ort=wohnzimmer Verb=sagen Ziel=status /
              Ausführung: {speak('Tab1.EG','Die Feuchte im Wohnzimmer beträgt '.ReadingsVal('humProfileC','WZ.rH','').' Prozent')}


[Babble_DoIt] Input:    mache etwas dunkler
              Ergebnis: Category=1.3.0: Gerät=etwas Ort=none Verb=schalten Ziel=dunkler /
              Antwort:  {speak('Tab1.EG','Es tut mir leid, das habe ich nicht verstanden')}



ZitatWenn Gruppen adressiert werden, kann man das in RHASSPY nicht (bzw: vermutlich nicht ohne größeren Aufwand) so detailiert erfassen, m.E. sind aber die Angabe der Device-Namen iVm. Intent etc. soweit eindeutig, dass auch fortgeschrittene Einsteiger was damit anfangen können sollten.
Aber gruppen sollten doch auch eindeutige Gerätenamen haben. Auf die Frage "Welche Geräte kennst Du" sollten alle Geräte und Gruppennamen zurückkommen.

LG

pah
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 12 April 2022, 08:13:54
Also: Aktualisierte Fassung ist im svn, damit ist
- das "multicommand"-feature allgemein verfügbar...
- (hoffentlich) das Schalten aus dem Test per File heraus Geschichte;
- die Rückmeldung nach Test per File auch wieder lesbar.

Über die Formatierung der Rückgabe für's Testen muss ich mir dann mal gesondert einen Kopf machen, das erfordert vermutlich wieder eine etwas andere Strukturierung der Daten.

Über
ZitatAber gruppen sollten doch auch eindeutige Gerätenamen haben. Auf die Frage "Welche Geräte kennst Du" sollten alle Geräte und Gruppennamen zurückkommen.
muss ich noch etwas nachdenken.

Prinzipiell ist es so, dass eine "Gruppe" aus RHASSPY-Perspektive "nur" ein "Abgrenzungslabel" ist, das - genausowenig wie der "Name" - eindeutig sein müßte. Gruppen sind jedenfalls keine "Geräte" (bzw.: Device-Instanzen) im FHEM-Sinn. Sie werden intern eher (!) gehandhabt wie dynamisch erstellte "structure"-Instanzen - deswegen war es auch relativ einfach, die bestehenden Gruppen-Intents "aufzubohren" für diese multi-Strukturierungselement-Geschichte.
Weiter kann ein "Gerät" viele Namen haben und auch zu vielen Gruppen gehören.

Alles anzusagen, ist daher m.E. in der Regel nicht sinnvoll. Was Namen angeht, begrenzt RHASSPY das daher auf die "Haupt-Namen" (bzw. "Haupt-Räume"). Von denen gibt es pro Device nur einen.
Bei Gruppen-Etiketten gibt es (jedenfalls vermutlich und im Moment) keine "Hauptgruppe" im eigentlichen Sinn. Muss mir mal näher ansehen, ob es überhaupt im Moment irgendeine halbwegs schnelle Methode gibt, sowas wie Gruppennamen pro Raum zu ermitteln. Aber selbst wenn, bliebe vermutlich das Problem, dass das uU. "endlos" ist (wobei: Das ggf. passend zu konfigurieren, sollte möglich sein, wenn man auch für dieses Strukturierungsmerkmal sowas wie "Hauptgruppen" einführt).
Hmm, mal sehen...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 13 April 2022, 14:26:43
Zitat von: Prof. Dr. Peter Henning am 28 Dezember 2021, 17:30:33
Anbei mal mein Schema für die Anbindung von Babble an Rhasspy.
Hättest du ggf. dazu noch den "Quellcode"? Dann könnte ich ggf. versuchen, mal den aktuellen Stand in Sachen AMAD.* (und msgDialog) einzupflegen...

Update der Dev-Version des Moduls ist in https://forum.fhem.de/index.php/topic,124952.0.html zu finden, da ist v.a. auch die Ausgabe der Testergebnisse in der "result"-File modifiziert (ich will nicht behaupten, dass das bereits besonders schön und/oder optimal wäre ::) ).
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Prof. Dr. Peter Henning am 19 April 2022, 14:21:53
Anbei der "Quellcode" für das Diagramm.

Ich grübele gerade über einer Möglichkeit, der precise Wakeword-Engine zusätzliche Parameter mitzugeben, wenn sie von Rhasspy gestartet wird. Hintergrund: ich hab ein meinem Wakeword-Modell immer noch zu viele "false positives". Ich möchte also abends, wenn der Fernseher mal läuft, auf derselben Hardware die Wakeword-Erkennung mit dem Parameter -d falsepos laufen lassen. Wenn ich dann sicherstelle, dass niemand von uns tatsächlich "Hallo Jeannie" sagt, verfüge ich danach über eine ganze Sammlung von Audioschnipseln, die man zum Training eines neuen Modells verwenden kann.

LG

pah
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 23 April 2022, 10:35:06
Gestern habe ich die SVN eingespielt und die multicommand-Anweisungen funktionieren gut.
Gibt es die Möglichkeit, vorhandene confirm-Abfragen in den rhasspySpecials der einzelnen Devices zwingend aufzurufen?

Gruß Jens
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 23 April 2022, 19:24:47
Zitat von: JensS am 23 April 2022, 10:35:06
Gestern habe ich die SVN eingespielt und die multicommand-Anweisungen funktionieren gut.
Gibt es die Möglichkeit, vorhandene confirm-Abfragen in den rhasspySpecials der einzelnen Devices zwingend aufzurufen?
Muss ich mir nochmal in Ruhe ansehen, wie das im Detail gelöst ist, hätte eigentlich gedacht, dass ein"single-needs-confirmation" bei einem beteiligten Device auch einen confirmation-request für diesen "speziellen Gruppen-Intent" verursacht.

Dass man allgemein eine confirmation für alle diese "ad-hoc"-Gruppen-Anweisungen anfordern kann, dürfte angekommen sein (ich habe aber bisher nicht gegengecheckt, ob das so funktioniert wie gedacht).

Wäre super, wenn  du auch mit der aktuellsten dev-Version testen könntest (aus https://forum.fhem.de/index.php/topic,124952.msg1195323.html#msg1195323). Da ist allerdings nichts passiert bzgl. des confirmation-Themas.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 29 April 2022, 16:00:54
Anbei zumindest mal das etwas überarbeitete Schaubild als jpeg und im Ausgangsformat.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 29 April 2022, 19:29:38
Wie gesagt - hübsch bunt.  ;D
Die Abbildung zeigt nur geringe Teile des tatsächlichen Prozessablaufs und ist notdürftig skizziert.
Z.B ist das Dialogmanagement ist ein extra Layer. Dieser erhält Daten vom STT und spricht seine Module (ASR, NLU, etc.) über MQTT an, sowie übergibt den erkannten Intent per MQTT an RHASSPY, welches sich dann um die Fortsetzung der Session kümmert.

Gruß Jens
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 30 April 2022, 10:42:21
Na ja, alle Verästelungen zu zeigen wäre vermutlich der absolute "Overkill"... Geht ja "nur" darum, erst mal sowas wie eine Idee zu vermitteln, was alles möglich ist.

Vermutlich bastle ich dann noch eine abgespeckte Version, in der dann "RHASSPY pur" dargestellt ist (also ohne Babble, AMAD.* und msgConfig+). Dann sieht man als Einsteiger eher, was man eigentlich (nur) braucht.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 01 Mai 2022, 08:55:27
Zitat von: JensS am 23 April 2022, 10:35:06
Gestern habe ich die SVN eingespielt und die multicommand-Anweisungen funktionieren gut.
Gibt es die Möglichkeit, vorhandene confirm-Abfragen in den rhasspySpecials der einzelnen Devices zwingend aufzurufen?
Habe eben ein update ins svn eingespielt, das neben dem geänderten output-Format (es gab keine Klagen...) auch eine Reparatur für die confirm-Prüfung bei den multi-Commands enthält. Bitte um Rückmeldung, wenn ich doch noch was übersehen haben sollte ::) ...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Prof. Dr. Peter Henning am 01 Mai 2022, 09:06:21
ZitatDie Abbildung zeigt nur geringe Teile des tatsächlichen Prozessablaufs und ist notdürftig skizziert.
Das ist nicht richtig. Der innere Ablauf von Rhasspy ist für die Ankopplung an FHEM derzeit irrelevant.

Die Kunst der wissenschaftlichen Abbildung besteht darin, solche irrelevanten Dinge herauszulassen.

LG

pah
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 01 Mai 2022, 09:51:15
Zitat von: Prof. Dr. Peter Henning am 01 Mai 2022, 09:06:21
Das ist nicht richtig. Der innere Ablauf von Rhasspy ist für die Ankopplung an FHEM derzeit irrelevant.

Die Kunst der wissenschaftlichen Abbildung besteht darin, solche irrelevanten Dinge herauszulassen.

LG

pah

Mag sein, dann sollte die Darstellung aber keine "alternativen" Wahrheiten beinhalten.
Entweder, man lässt alle Rhasspymodule weg oder man stellt das Dialogmanagement als Zwischenlayer dar. Eine gleichwertige Einordnung zu den Untermodulen ist faktisch falsch.

Gruß Jens
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Prof. Dr. Peter Henning am 01 Mai 2022, 09:53:59
Da bin ich anderer Ansicht und würde das in einer Publikation (egal ob Buch oder wissenschaftliches Paper) genau so darstellen, wie es hier der Fall ist. Es geht eben _nicht_ um die genaue Darstellung der inneren Abläufe von Rhasspy.

LG

pah
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 01 Mai 2022, 09:58:51
Genau das macht es für Suchende besonders schwierig, weil die Darstellung irreführend ist und mit dem Prozessablauf überhaupt nichts zu tun hat.
Wenn es nun so sein soll, dann gehören zumindestens die inneren Pfeile weg...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 02 Mai 2022, 07:49:23
Na ja, der (gedankliche) Fokus dieser (und wohl auch der originalen) Darstellung lag und liegt auch weniger auf den Feinheiten der inneren Abläufe auf der Rhasspy-Seite, sondern eher auf dem, was man in FHEM braucht bzw. aus FHEM heraus machen kann.
Dabei muss ich zugeben, dass ich die Pfeilchen in/bei Rhasspy zum Teil auch nicht unbedingt notwendig oder intuitiv fand. Mal sehen...

Bisher war das mit der Grafik auch eher als Abgleich zu dem gemeint, was pah gemacht hatte. Von daher würde mich in Schritt 1 daher eigentlich mehr interessieren, ob alles soweit auch im Kontext der "großen Landschaft" funktioniert, die pah aufgezeicht hatte. Ich habe zwar manches getestet, aber eben z.B. nicht, wie das mit der Soundausgabe auf unterschiedlichen Geräten klappt (z.B. dem TV auf der Grafik). (Btw.: Weiß jemand zufällig, wie man (für automagic) einen shortcut für "activateVoiceInput" @ Android mit einem Icon versieht? Bei mir ist das einfach "durchsichtig"...).

Die Schwierigkeit in der Darstellung ist ansonsten eigentlich immer, dass Rhasspy halt eine Sammlung von Tools ist, die man ganz nach Belieben zusammensetzen und aktivieren kann - oder eben auch nicht. Ähnlich ist es bei Teilfunktionalitäten von RHASSPY: man kann einiges machen, wenn man das will, aber man muss nicht....
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 02 Mai 2022, 09:12:20
Zitat von: Beta-User am 02 Mai 2022, 07:49:23sondern eher auf dem, was man in FHEM braucht bzw. aus FHEM heraus machen kann.

Zwischen "brauchen" und "kann" ist im Falle RHASSPY aber ein riesen Unterschied ;D
Wenn ich mir als Anfänger die Grafik ansehen würde, würde ich gleich zum nächsten Produkt weiter ziehen. Ist eher eine Grafik für die, die Rhasspy/RHASSPY schon am Laufen haben und es erweitern möchten.
Der Anfänger braucht Base und Modul. Mehr nicht. MQTT ist per Default eh in der Base integriert, Audio - Ein- und Ausgabe kann eine Base grundsätzlich auch.
Was in Rhasspy genau abgeht, muss ihn auch nicht interessieren.

Also eigentlich bräuchte man da drei Grafiken. Anfänger, Fortgeschrittene, Experte ;)

Und irgendwo müsste noch eine Audio-Ausgabe über Rhasspy hin (also Standardverhalten). Die fehlt da.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 02 Mai 2022, 10:02:18
Zitat von: drhirn am 02 Mai 2022, 09:12:20
Zwischen "brauchen" und "kann" ist im Falle RHASSPY aber ein riesen Unterschied ;D
:o ;D 8) :P ::) 8)

Zitat
Wenn ich mir als Anfänger die Grafik ansehen würde, würde ich gleich zum nächsten Produkt weiter ziehen. Ist eher eine Grafik für die, die Rhasspy/RHASSPY schon am Laufen haben und es erweitern möchten.
Der Anfänger braucht Base und Modul. Mehr nicht. MQTT ist per Default eh in der Base integriert, Audio - Ein- und Ausgabe kann eine Base grundsätzlich auch.
Was in Rhasspy genau abgeht, muss ihn auch nicht interessieren.

Also eigentlich bräuchte man da drei Grafiken. Anfänger, Fortgeschrittene, Experte ;)

Und irgendwo müsste noch eine Audio-Ausgabe über Rhasspy hin (also Standardverhalten). Die fehlt da.
Na ja, "nur drei"...?!? Eigentlich bräuchte man ggf. für jeden in RHASSPY enthaltenen Teilbereich "erweiterter Funktionalität" nämlich eine separate Grafik...?

Für die Basis sollte ein Anfänger eigentlich diese hier kennen, muss mal schauen, ob es dazu auch irgendwo den Quelltext gibt:
https://rhasspy.readthedocs.io/en/latest/#services

Und man braucht für die "base" eigentlich auch keine Audio-Hardware, wer FHEM und einen Androiden hat, kann das eigentlich am näherungsweise komfortabelsten via AMAD lösen (*duck und weg*).
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 02 Mai 2022, 10:09:58
Zitat von: Beta-User am 02 Mai 2022, 10:02:18
Und man braucht für die "base" eigentlich auch keine Audio-Hardware, wer FHEM und einen Androiden hat, kann das eigentlich am näherungsweise komfortabelsten via AMAD lösen (*duck und weg*).

Mal überlegen...
Die Mehrheit experimentiert mit Rhasspy am Anfang mit einem Raspberry Pi als Base. Auch wenn du den nicht magst. Lautsprecher und Mikro anhängen und in der Konfiguration der Base zwei Hackerl setzen.
oder...
Zusätzlich zu dem Pi als Base noch AMAD auf FHEM und Android konfigurieren müssen, was jetzt auch nicht so einsteigerfreundlich ist.

Meine Entscheidung wäre klar ;D

ZitatFür die Basis sollte ein Anfänger eigentlich diese hier kennen
Ja, seh ich auch so.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 02 Mai 2022, 11:37:06
Zitat von: drhirn am 02 Mai 2022, 10:09:58
Die Mehrheit
Aha... (Überstimmt ::) ).

Vielleicht für diese Mehrheit wie in der Anlage...?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 02 Mai 2022, 11:41:26
Nein. Die Mehrheit wie im Rhasspy-Forum ersichtlich.
Ich formulier's um: Wenn man das Rhasspy-Forum durchliest, verwenden die meisten User eine Pi.

Ja. Anhang macht Sinn. Für blutige Anfänger.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Prof. Dr. Peter Henning am 02 Mai 2022, 17:15:53
ZitatWenn ich mir als Anfänger die Grafik ansehen würde, würde ich gleich zum nächsten Produkt weiter ziehen
Ui, welch eine Drohung  ;D

Meine FHEM-Bücher haben sich eigentlich ganz gut verkauft, insofern sehe ich das ganz selbstgefällig locker. Mein neuestes Buch dümpelt noch so vor sich hin, hat aber auch nichts mit Informatik zu tun.

Und die Korrelation "Anfänger" und "Blut" hatte ich auch schon manchmal im Sinn.

LG

pah

Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 02 Mai 2022, 18:03:02
...weiß nicht, ob mit "Produkt" ein Buch gemeint gewesen war, hätte eher auf das Modul getippt...

Ansonsten ist Rhasspy/RHASSPY ja "unvergleichlich", mir unerklärlich, zu welcher Konkurrenz man wechseln wollte :P .

Und bei "Blut" kommen mir alternativ auch gleich "Schweiß und Tränen" in den Sinn (obwohl es bis 40,000 Headmen noch weit ist, https://www.youtube.com/watch?v=q0zaGcSjKgM)

Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 07 Mai 2022, 10:36:08
@Beta-User
https://community.rhasspy.org/t/whats-the-craziest-thing-you-can-or-cannot-do-with-rhasspy/3648/3 (https://community.rhasspy.org/t/whats-the-craziest-thing-you-can-or-cannot-do-with-rhasspy/3648/3) gefällt mir.  :)

Das aktuelle Bild in der WIKI finde ich gut. In das Dialog-Element könnten ASR und NLU als Unterelemente rein oder man leitet Pfeile für ASR+NLU durch das Dialogelement. Man hat einen ersten Eindruck, wie Rhasspy aufgebaut ist - das genügt.

Gruß Jens
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Prof. Dr. Peter Henning am 08 Mai 2022, 10:44:35
ZitatVielleicht für diese Mehrheit wie in der Anlage...?

MQTT Broker wird als Bezeichnung nicht mehr verwendet, heißt jetzt schon länger MQTT Server.

LG

pah
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 09 Mai 2022, 13:58:49
Zitat von: Prof. Dr. Peter Henning am 08 Mai 2022, 10:44:35
MQTT Broker wird als Bezeichnung nicht mehr verwendet, heißt jetzt schon länger MQTT Server.
Danke für den Hinweis, hab's geändert.

Zitat von: JensS am 09 Mai 2022, 13:34:43
Du hattest "intentNotRecognized" zur Sprache gebracht - hier ist eine Idee dazu.  ;)
...ich mache mal hier weiter, das scheint mir hier besser aufgehoben...

Ja, ich habe pah's Anregung aus
Zitat von: Prof. Dr. Peter Henning am 08 Mai 2022, 17:10:21
Eine klare Erkenntnis aus meinen Forschungsprojekten kann ich nicht oft genug zitieren: Jedes Sprachsteuerungssystem benötigt eine "dialog closure" am Ende, die auf noch so absurde Fragen und Antworten der Nutzer reagiert und immer irgendetwas zurückliefert,
aufgegriffen und (an der falschen Stelle) die/eine "Übersetzung" in die Rhasspy-Sprache vorgenommen, und dann eben an der falschen Stelle die Rückmeldung gegeben, dass meine aktuellen Überlegungen dazu keinen wirklichen Fortschritt gebracht haben...

Zitat von: JensS am 09 Mai 2022, 13:34:43
Beim intentNotRecognized wird ja etwas erkannt und ausgegeben. Von der NLU wird nur kein passender Intent gefunden.
Das ist soweit verstanden ;) .

Zitat
"wie spät ist es jetzt" wird nicht erkannt, weil "jetzt" zuviel ist. Wird der Text mit den vorhandenen Intents verglichen, kann der enthaltene Intent "wie spät ist es" gefiltert werden und der Intent könnte nach einer Rückfrage: "Meinst du - wie spät ist es?" per sessionContinue an die Session zurückgegeben werden.
Das Problem dabei ist folgendes: das würde funktionieren, wenn man genau eine RHASSPY-Instanz voraussetzt und die zuliefernde Rhasspy-Installation dazu da wäre, genau diese eine RHASSPY-Instanz zu versorgen.

Sobald aber derselbe MQTT-Server für
- mehrere RHASSPY-Instanzen und/oder
- mehrere Rhasspy-Installationen
"zuständig" ist, ist komplett unklar, wer
- die "intentNotRecognized"-Message verursacht hat,
- warum das der Fall ist
- wer dafür zuständig ist, den Faden aufzugreifen (es könnte auch eine andere externe Logik den rawInput "abgreifen", z.B. pah mit MQTT2_DEVICE->notify->Babble, oder eine eigene python-App in den Weiten des Universums suchen...?!?)?

Im Moment sehe ich noch keine wirklich befriedigende "automatische" Lösung. Sehr eventuell wäre was denkbar, das
- der "Konfigurator" aktiv anschaltet, und
- ggf. mit einem Timer kurz wartet, ob nicht doch noch jemand anderes was in dieser Sache unternimmt, um dann eben die Sitzung zuzumachen.

PS: Fall sich jemand wundert, warum das z.B im Rahmen der Tests scheinbar doch klappt: Da kommt die jeweilige Anfrage aus FHEM, und aus diesem Grund haben wir dann auch die Info, dass "uns" die Daten gehören...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 09 Mai 2022, 14:23:01
Ok, "intentNotRecognized" wird vom Dialogmanager ausgeworfen. Dieser gibt auch zwingend eine sessionId und eine siteId mit. Eine Eindeutigkeit ist also gegeben.
Sollte eine zweite Rhasspy/RHASSPY-Instanz existieren, würde das Topic mit der fremden sessionId verworfen, da die sessionId vom Audio-Server der betreffenden Instanz generiert wurde.

p.s. Eine Konstellation mit mehreren RHASSPY- und Rhasspy-Instanzen an einem MQTT ist denkbar - aber auch sinnvoll? Dazu sollte doch eher eine zusätzliche MQTT-Instanz mit einem anderen Port genutzt werden.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 09 Mai 2022, 14:35:13
Zitat von: JensS am 09 Mai 2022, 14:23:01
Ok, "intentNotRecognized" wird vom Dialogmanager ausgeworfen. Dieser gibt auch zwingend eine sessionId und eine siteId mit. Eine Eindeutigkeit ist also gegeben.
Jein. Eine RHASSPY-Instanz weiß mAn. nämlich erst, ob eine sessionId "ihr" gehört, wenn die "intent-id" paßt. Alles andere findet "außerhalb" der FHEM-Sphäre statt, nur ist z.B. das Aktualisieren eines Wakeword-Events kein Eingriff in die laufende session, von daher ist das in dem Fall egal, dass etwas "auf Verdacht" passiert...

Zitat
Sollte eine zweite Rhasspy/RHASSPY-Instanz existieren, würde das Topic mit der fremden sessionId verworfen, da die sessionId vom Audio-Server der betreffenden Instanz generiert wurde.
Vielleicht übersehe ich ja was, aber ein "normaler Sitzungsstart" ergibt doch einfach eine zufällige sessionId, oder? Man kann zwar die siteId und das wakeword (letzteres vermutlich nur, wenn eines benutzt wurde) daraus ableiten, aber im "multi-language-Fall" hören alle Rhasspy-Installationen zu und es wird ggf. anhand des wakewords entschieden, welche den "Zugriff" tätigt.
Eine von mehreren RHASSPY-Instanzen weiß aber ggf. nicht, welche davon "zu ihr" gehört...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 09 Mai 2022, 15:01:34
Zitat... da die sessionId vom Audio-Server der betreffenden Instanz generiert wurde.
ist natürlcih Quatsch. Das wird vom Dialog-Manager erledigt, sobald eine Session durch hermes/dialogueManager/startSession gestartet wurde.
Am besten, ich schreibe ein kleines Script zur Veranschaulichung. Das kann aber etwas dauern, da mir im Moment die Hände teilweise gebunden sind.
Trotz aller Bedenken sollte es in allen Konstellationen funktionieren, da auf die eindeutige Ursprungs-Session zurückgesprungen wird.

Gruß Jens
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 09 Mai 2022, 15:10:06
Zitat von: JensS am 09 Mai 2022, 15:01:34
Das wird vom Dialog-Manager erledigt,
[...]
Trotz aller Bedenken sollte es in allen Konstellationen funktionieren, da auf die eindeutige Ursprungs-Session zurückgesprungen wird.
Nach meinem Verständnis ist es der Dialog-Manager, der (in der Regel) eine Session startet (EDIT: oder besser formuliert: der auf Anforderung eine SessionId vergibt) - wohl meist ausgelöst durch ein Wakeword.

Aber nochmal: sobald man zwei Rhasspy-Installationen hat, die denselben MQTT-Server nutzen (multi-language-Umgebung), kennt RHASSPY mAn. die eigentliche Veranlassung für das Öffnen der session nicht, und weiß auch nicht, ob es der Dialogmanager von "Rhasspy-de" oder (z.B.) von "Rhasspy-es" war, der eine Sitzung aufgemacht hatte. Erst, wenn eine Sitzung bekanntermaßen einer RHASSPY-Instanz zugeordnet war ("continouos session"), könnte man mehr dazu wissen. Das ist aber die Ausnahme...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 09 Mai 2022, 15:46:58
Zitat von: Beta-User am 09 Mai 2022, 15:10:06
Nach meinem Verständnis ist es der Dialog-Manager, der (in der Regel) eine Session startet (EDIT: oder besser formuliert: der auf Anforderung eine SessionId vergibt) - wohl meist ausgelöst durch ein Wakeword.
Richtig - sobald eine Wakeword erkannt wurde oder eine hermes/dialogueManager/startSession-Anweisung (von außen) zum MQTT geschickt wird, startet der Dialog-Manager eine Session mit hermes/dialogueManager/sessionStarted und vergibt die eindeutige sessionId.

Edit: Einen Sonderfall gibt es bei der Android-App. Dort wird offensichtlich das ASR mit hermes/asr/toggleOn direkt eingeschaltet und die App vergibt dann die sessionId mit hermes/asr/startListening.

ZitatAber nochmal: sobald man zwei Rhasspy-Installationen hat, die denselben MQTT-Server nutzen (multi-language-Umgebung), kennt RHASSPY mAn. die eigentliche Veranlassung für das Öffnen der session nicht, und weiß auch nicht, ob es der Dialogmanager von "Rhasspy-de" oder (z.B.) von "Rhasspy-es" war, der eine Sitzung aufgemacht hatte. Erst, wenn eine Sitzung bekanntermaßen einer RHASSPY-Instanz zugeordnet war ("continouos session"), könnte man mehr dazu wissen. Das ist aber die Ausnahme...
Zu einer "RHASSPY-ES"-Instanz muss eine "Rhasspy-es"-Instanz mittels "rhasspy -p es" gestartet sein. Ein Zugriff auf eine "Rhasspy-de"-Instanz würde u.a. wegen der Intentbezeichnung de.fhem.... scheitern. Es gibt also keine sinnvolle Verbindung zwischen den Instanzen verschiedener Sprachen. Daher finde ich einen eigenen MQTT pro Sprache sinnvoll.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 09 Mai 2022, 15:54:42
Zitat von: JensS am 09 Mai 2022, 15:46:58
Zu einer "RHASSPY-ES"-Instanz muss eine "Rhasspy-es"-Instanz mittels "rhasspy -p es" gestartet sein. ... Es gibt also keine sinnvolle Verbindung zwischen den Instanzen verschiedener Sprachen. Daher finde ich einen eigenen MQTT pro Sprache sinnvoll.
Es gibt aber uU. gemeinsam genutzte Hardware. Es mag nicht sinnvoll erscheinen, aber es ist denkbar, genauso, wie es denkbar ist, dass mehrere FHEM-Instanzen auf "die eine" Rhasspy-Installation "lauschen".

Wie sinnvoll das im einzelnen ist, sei mal dahingestellt, ich will ja erst mal nur deutlich machen, dass es wegen dieses offenen Zusammenspiels der einzelnen Komponenten zu Verwirrung kommen _kann_ und es sich daher m.E. verbietet, "einfach alles abzugreifen".

Zitat von: JensS am 09 Mai 2022, 15:46:58
Ein Zugriff auf eine "Rhasspy-de"-Instanz würde u.a. wegen der Intentbezeichnung de.fhem.... scheitern.
Genau diese Intentbezeichnung existiert aber in dem "not recognized"-Fall gerade nicht... Also entweder ist vorher schon was passiert, das die laufende Sitzung gerade dieser RHASSPY-Instanz zuordnet, oder es ist eben unklar.

ZitatEdit: Einen Sonderfall gibt es bei der Android-App. Dort wird offensichtlich das ASR mit hermes/asr/toggleOn direkt eingeschaltet und die App vergibt dann die sessionId mit hermes/asr/startListening.
Das stimmt aber auch nur dann, wenn ein bestimmter Haken in der App _nicht gesetzt_ ist... Man kann auch bei Nutzung der App das session management der base übergeben ;) .
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 09 Mai 2022, 16:07:25
Zitat von: Beta-User am 09 Mai 2022, 15:54:42
Es gibt aber uU. gemeinsam genutzte Hardware.
Ok, das sollte für zwei eigenständigen Instanzen mit einer gemeinsam genutzten Audiohardware über PulseAudio möglich sein. Die Unterscheidung müsste dann per Wakeword passieren.

Zitat
Wie sinnvoll das im einzelnen ist, sei mal dahingestellt, ich will ja erst mal nur deutlich machen, dass es wegen dieses offenen Zusammenspiels der einzelnen Komponenten zu Verwirrung kommen _kann_ und es sich daher m.E. verbietet, "einfach alles abzugreifen".
Genau diese Intentbezeichnung existiert aber in dem "not recognized"-Fall gerade nicht... Also entweder ist vorher schon was passiert, das die laufende Sitzung gerade dieser RHASSPY-Instanz zuordnet, oder es ist eben unklar.
Das stimmt aber auch nur dann, wenn ein bestimmter Haken in der App _nicht gesetzt_ ist... Man kann auch bei Nutzung der App das session management der base übergeben ;) .
Die Verwirrung kann es nicht geben, da die Weichen bereits bei sessionStarted gestellt sind. Dort wird per "customData" das Wakeword mitgegeben.
Oder wie ordnet Rhasspy/RHASSPY die Sprachen zu?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 09 Mai 2022, 16:23:11
Zitat von: JensS am 09 Mai 2022, 16:07:25
Die Unterscheidung müsste dann per Wakeword passieren.
So war auch mein Verständnis.

Zitat
Die Verwirrung kann es nicht geben, da die Weichen bereits bei sessionStarted gestellt sind. Dort wird per "customData" das Wakeword mitgegeben.
Oder wie ordnet Rhasspy/RHASSPY die Sprachen zu?
"customData" ist aber volatil und kann im Prinzip beliebig geändert werden. Das Wakeword wird zwar zum Bestandteil der sessionId, von daher hätte man diese Info durchaus - aber nur in den Fällen, in denen wirklich ein wakeword involviert ist (nicht: App+"Knopf"+session management@Rhasspy)...
Aber das hat nach meinem Verständnis dann wieder nicht wirklich was mit Sprachen zu tun, und ob die Sprachinfo in den "not recognized"-Fällen überhaupt enthalten ist, wäre ggf. zu klären.
RHASSPY interessiert sich übrigens eigentlich gar nicht für die Sprache, für das Modul ist alles Text und die Sprache ein "Neutrum", das ggf. einfach als Info mitgegeben wird. Ansonsten spielt die mAn. keine eigenständige Rolle (wenn man von der erwarteten Intent-Namensgebung und der Vergaben der slot-Namen absieht).
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 09 Mai 2022, 17:54:24
Zitat von: Beta-User am 09 Mai 2022, 16:23:11
Das Wakeword wird zwar zum Bestandteil der sessionId, von daher hätte man diese Info durchaus - aber nur in den Fällen, in denen wirklich ein wakeword involviert ist (nicht: App+"Knopf"+session management@Rhasspy)...
Ein Punkt mehr, eine eigene MQTT-Instanz pro Sprache aufzumachen.

Zitat
RHASSPY interessiert sich übrigens eigentlich gar nicht für die Sprache, für das Modul ist alles Text und die Sprache ein "Neutrum"...
Lustig ist es, eine "RHASSPY language=en" an eine "rhasspy -p de" zu koppeln. ;D

Gruß Jens
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 10 Mai 2022, 11:35:13
Zitat von: JensS am 09 Mai 2022, 17:54:24
Lustig ist es, eine "RHASSPY language=en" an eine "rhasspy -p de" zu koppeln. ;D
;D klingt so, als hättest du das mal ausprobiert...?
Wenn es wirkt, wie ich vermute, klingt es manchmal (?) lustig...

Zitat von: JensS am 09 Mai 2022, 17:54:24
Ein Punkt mehr, eine eigene MQTT-Instanz pro Sprache aufzumachen.
Prinzipiell habe ich auch die Vermutung, dass so eine Empfehlung an sich berechtigt wäre. Nur: Erzwingen will ich das nicht, denn es kommt bestimmt sonst "morgen" jemand um's Eck, der kreativer ist wie meine Gedankenwelt...

Also sollte alles, was mit "not recognized" zu tun hat, durch Konfiguration durch den "Administrator" beeinflussbar sein.

Diese Themenkreise habe ich dazu bisher wahrgenommen:
1. Rückmeldung an den Sprecher: "so geht es nicht"
2. Logging entsprechender "Sätze"
3. "Weiterverarbeitung" (bis hin zur Ergänzung der sentences.ini)

Die Punkte 1 und 2 wären (dem Bauchgefühl nach) relativ einfach* per "tweak" einzubauen, und bei 3 wird es vermutlich sehr schnell individuell. 3 könnte man daher als Alternative zu 1 als "Unterform" von "handleCustomIntent" aufgefasst werden, und ich wäre fast geneigt, das (also diese (optionale!) Umleitung) direkt einzubauen.

* Ein Problem bleibt dabei aber: "not recognized" kann (!) auch vorkommen, wenn ein Satz an sich bekannt, der betreffende Intent aber grade deaktiviert ist (über "intent filter" global bzw. für die laufende Sitzung)... Innerhalb einer laufenden Sitzung sollte dann vermutlich keine "externe"  Verarbeitung angestoßen werden. Wie wir mit diesen Fällen allerdings umgehen sollten, war eine der seit längerem ungeklärten Fragen, und ich habe bis dato auch noch keine für mich selbst halbwegs schlüssige Antwort gefunden...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 10 Mai 2022, 12:09:02
Übrigens: https://www.amazon.science/blog/amazon-releases-51-language-dataset-for-language-understanding
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 10 Mai 2022, 13:27:45
Zitat von: drhirn am 10 Mai 2022, 12:09:02
Übrigens: https://www.amazon.science/blog/amazon-releases-51-language-dataset-for-language-understanding (https://www.amazon.science/blog/amazon-releases-51-language-dataset-for-language-understanding)
Vielleicht trägst du den Link noch in pah's "Testsuite-Thread" ein? (Wobei mir auf die Schnelle nicht klar ist, was da alles in den Materialien drin ist, die da verlinkt sind).


Zitat
"wie spät ist es jetzt" wird nicht erkannt, weil "jetzt" [...]
Zitat von: Prof. Dr. Peter Henning am 10 Mai 2022, 12:56:55
ist ein typisches Beispiel für einen Satz, der ohne Kontext nicht interpretierbar ist. Das kann man mit Amazon Alexa gut ausprobieren
"Alexa, wie spät ist es jetzt" ==> aktuelle Uhrzeit
"Alexa, wie früh ist es" ==> aktuelle Uhrzeit
"Alexa, wie spät ist es morgen" ==> Datum von morgen
"Alexa, wie früh ist es morgen" ==> "Das könnte Deine Frage beantworten..." dann Datum von morgen
"Alexa, wie früh ist es vorgestern" ==> "Das weiß ich leider nicht"
"Alexa, wie spät ist es jetzt in Timbuktu" ==> Datum und Uhrzeit in Timbuktu

Hier wird also offenbar zunächst fest substituiert "wie spät" ==> Ausgabe Zeit/Datum.
Dann aber ist ein Zeitpunkt und ein Ort festzustellen, und dafür gibt es default-Annahmen.
Vermutlich ist das hier besser aufgehoben...

Anscheinend spielt da auch noch eine gewisse "Trefferwahrscheinlichkeit" mit rein, was man an den Variante 3 und 4 (bzw. auch 5) ganz gut ablesen kann. 3 +4 gingen vielleicht gerade so noch mit einer reinen Textanalyse und "Nähebetrachtung", aber für logische Implikationen ala "das kann eigentlich nicht gemeint sein", braucht es etwas mehr.

Soweit ich das bisher (im Rhasspy-Forum) überblicken kann, gibt es außer FHEM keine "Musterlösung", das die "confidence"-Angaben auch mit berücksichtigt 8) .

Das Problem mit der semantischen Nähe und der Frage, wie eine Eingabe _wahrscheinlich_ zu verstehen sein soll, war letztlich mit der Grund, warum jetzt die "Choice"-Varianten zusammengeführt worden sind: Sprachlich sind alle Arten einer Auswahl-Antwort ähnlich, sie unterscheiden sich nur in den Schlüsselwörtern, also danach, was (ggf. mit "kleinem Kontext" wie "im" für einen Raum) an "Auswahlwörtern" rund um den (kurzen!) eigentlichen "Content" rum passiert, und zudem ist die Wahrscheinlichkeit relativ hoch, dass ein "normaler menschlicher Sprecher" ggf. auch Dinge wiederholt (oder klarstellt bzw. korrigiert), die vorher ggf. eigentlich schon "klar" waren.

Übrigens bin ich nicht sicher, ob ich heute nochmal eine Unterscheidung zwischen den Einzel- und Gruppenintents machen würde - genau aus dem Grund, dass es beim Sprechen kaum einen Unterschied macht, und uU. dem Sprecher auch gar nicht klar ist, ob er jetzt eigentlich grade eine Gruppe anspricht oder ein einzelnes Device. Tendenziell würde ich versuchen wollen, das mittelfristig wieder zusammenzubringen bzw. "Umleitungspfade" vorzusehen, z.B. für den Fall, dass
- kein Einzelmatch (im Raum) klappt,
- aber eine Gruppenbezeichnung im Raum passen würde.

Sind aber wieder möglicherweise schwerwiegende Eingriffe in das Verhalten des Moduls... (Aber wenn, dann tendenziell jetzt dann...).
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Prof. Dr. Peter Henning am 10 Mai 2022, 14:55:59
Das MASSIVE-Dataset von Amazon hat eine Mitarbeiterin schon gefunden, wir überlegen derzeit, ob wir bei der Konferenz etwas einreichen. In meinem "Test Suite-Thread" habe ich die deutschen Sprachdaten aus MASSIVE kommentiert (und drhirn den Credit für den ersten Hinweis in FHEM gegeben).

Ist aber sehr gemischte Qualität. Ich werde meine Jeannie niemals fragen "Alles fit im Schritt?".


LG

pah
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 10 Mai 2022, 15:49:22
Zitat von: Prof. Dr. Peter Henning am 10 Mai 2022, 14:55:59
Ist aber sehr gemischte Qualität. Ich werde meine Jeannie niemals fragen "Alles fit im Schritt?".
Na ja, die Geschmäcker sind verschieden, und einen "Flirt-Chatbot" zu bauen, der auch anzügliche Witze macht, darf gerne jemand anderes übernehmen, ist auch nicht so meins...

Nicht so meins ist auch das Datenformat. Sollte es für sowas dann nicht eine Art "Intermediär" geben, den man "zeilenweise" abrufen und "füttern" kann? (Eigentlich hatte ich nicht die große Neigung, mich da in irgendein (für mich) obskures Datenformat einzulesen...).
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 16 Mai 2022, 17:17:29
Wie versprochen: Hier eine Erkenntnis.

"Welches Szenen kennt die Beleuchtung?"
Rhasspy liest mir dann brav alle Szenen vor, die ich bei dem Device habe. Sind ein paar. Sobald das erledigt ist, bekomme ich die "Fehler-WAV" vorgespielt und RHASSPY meint, da habe etwas zu lange gedauert. Da wird offenbar eine Antwort erwartet?


hermes/dialogueManager/intentNotRecognized

{"sessionId": "wohnzimmer.pc-porcupine_raspberry-pi-5ed6c5a7-f699-4035-be3a-53aa8ca46260", "siteId": "wohnzimmer.pc", "input": "<unk> lass <unk> abbrechen <unk> nimm alles aus", "customData": "Computerlicht,Alles an,Leselicht,Fernsehlicht,Nachtlicht,Schlummerlicht,DunklesFernsehlicht,Esslicht,Alles aus"}
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 16 Mai 2022, 17:35:57
 ;D ...wie angedeutet...: Scheint noch nicht "fertig" zu sein...

Das "Get" in "SetScene" ist als Frage-Antwort-Spiel konzipiert, daher der timeout. Weiß noch nicht, ob das (in Kombination mit dem sentence) glücklich ist...
Hinzu kommt, dass die Antwort uU. recht lang ist, und von daher hier möglicherweise der timer abläuft, bevor man sich überhaupt entscheiden konnte. (Den üblichen timeout für diesen Anwendungsfall einfach zu erhöhen (verdoppeln? Rechnen mit der Zahl der Szenen?), wäre keine große Übung).

Man kann die Anfrage übrigens auch über GetState machen, dann ist es eine reine Info, kann aber dafür auch einfach "alles in einem bestimmten Raum" (Device-los; hoffe ich zumindest ::) )...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 16 Mai 2022, 17:41:16
Das ganze wird ja via tts/say ausgegeben. Geht das vielleicht auch anders? Damit der dialogueManager wartet?

Aber eigentlich macht da ein "get" keinen Sinn, das geht ja wirklich mit GetState. Aber mit einem "set" und einer Nachfrage, wenn da was nicht verstanden wird, haben wir das Problem trotzdem.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 16 Mai 2022, 17:53:19
Der Timeout kommt nicht vom dialogueManager, sondern aus dem Modul (ca. #5113). Von daher wäre es nicht das Thema, dort z.B. sowas reinzuschreiben:
return setDialogTimeout($hash, $data, _getDialogueTimeout($hash)*1.5, $response, $toActivate);

Und irgendwie kommt es mir dunkel so vor, als wäre der Plan gewesen, den sentence in die Richtung umzuschreiben, dass sprachlich besser zum Ausdruck kommt, das der Sprecher tatsächlich (am Ende) eine Szene schalten will, aber eben noch nicht genau weiß, welche. In diesem Fall ist es dann auch nicht ganz unwichtig, welchen Intent der Sprecher ursprünglich mal angesprochen hatte, dahin geht dann nämlich prinzipiell (aus "Choice" heraus, war aber bei gesplitteten Choice-Typen auch schon so) auch die Antwort. Könnte man natürlich irgendwie vor dem User verbergen, aber das nimmt kaum Komplexität raus...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 17 Mai 2022, 10:06:40
...etwas anderes Thema:
Nachdem ich gestern nochmal drübergestolpert bin, dass der Code keine Antwort bei "intentNotRecognized" liefert, bin ich nochmal über die möglichen Ursachen gegangen - und habe was gefunden, allerdings an anderer Stelle wie vermutet ::) .

Update ist im Nachbarthread zu finden.

Und zumindest nach dem list müßte es auch möglich sein, an der Stelle (vorrangig zur Standardantwort) eigenen Perl-Code anzuflanschen. Müßte beispielsweise so klappen:
attr RHASSPY rhasspyIntents intentNotRecognized=myIntentNotrecognized(NAME,siteId,input)

Damit sollte sich dann auch ggf. der Antwort-Code aus https://community.rhasspy.org/t/whats-the-craziest-thing-you-can-or-cannot-do-with-rhasspy/3648/26 anflanschen lassen (falls es nicht bereits Beispiele gibt, wie man aus FHEM heraus z.B. alexa anfragt. Habe bisher nicht nach sowas gesucht...).

Eventuell braucht man dann auch noch sowas wie einen "asynchronen call", um die session offen zu halten und später die Antwort einschleusen zu können.



Bliebe dann die Frage, wie man am anderen Ende (also auf der Rhasspy-Seite) sinnvollerweise die STT-Einstellungen konfiguriert, damit man wirklich eher "frei" sprechen kann und nicht zwanghaft bei irgendwas landet, was in sentences.ini angelegt war. Ist Neuland für mich - meine Versuche, "open transcription" zu aktivieren haben in endlosen trainings-sessions geendet... Also falls jemand einen "schnellen Tipp" hat: her damit!
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 18 Mai 2022, 18:04:14
Zitat von: Beta-User am 17 Mai 2022, 10:06:40
Eventuell braucht man dann auch noch sowas wie einen "asynchronen call", um die session offen zu halten und später die Antwort einschleusen zu können.

Was in der Theorie einfach ist, lässt sich offensichtlich praktisch nicht umsetzen.
Mit der Wakeworderkennung wird mit hermes/dialogueManager/startSession eine neue Session erzeugt. In dem Standardszenario ist eine Option sendIntentNotRecognized nicht vorgesehen. Auch ein passender Startparameter der Wakeword- und Dialogengine ist nicht vorhanden. Somit endet die Session automatisch mit hermes/dialogueManager/endSession. Man müsste den Rhasspy-Code editieren, was natürlich den Usern nicht zuzumuten ist.
Momentan tue ich mich schwer dabei, eine verständliche Frage für das Rhasspy-Forum zu formulieren...

Gruß Jens

https://github.com/rhasspy/rhasspy-dialogue-hermes/blob/0d697cb1631880688fd484177f1cdf50351f4a3e/rhasspydialogue_hermes/__init__.py#L652 (https://github.com/rhasspy/rhasspy-dialogue-hermes/blob/0d697cb1631880688fd484177f1cdf50351f4a3e/rhasspydialogue_hermes/__init__.py#L652)
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 18 Mai 2022, 19:13:58
Hallo zusammen, habe eben eine neue Version ins svn geschubst - kann sein, dass die an der einen oder anderen Stelle wieder etwas "experimentell" ist....

Verbessert worden sollte v.a. sein
- Rückwärtssuche nach "tauglichen" Geräten anhand des Namens (mein doppeltes verstärkerlein... Kann sein, das man das noch weiter verbessern kann, indem man auch noch die Kombination von "intent" und "typ" auswertet)
- die Rückmeldung bei intentNotRecognized. Das ist jetzt nicht mehr "experimentell", sondern default, wer keine Rückmeldung will, muss ggf. den dazugehörigen Satz auf "leer" stellen ;) .

Zitat von: JensS am 18 Mai 2022, 18:04:14
Was in der Theorie einfach ist, lässt sich offensichtlich praktisch nicht umsetzen.
Mit der Wakeworderkennung wird...
Weiß nicht, ob das unzulässige "Brechstange" ist, aber es müßte m.E. gehen, ggf. die alte Sitzung wieder aufzumachen. RHASSPY kann ggf. die Sitzungsdaten speichern...

Was im Moment noch nicht so richtig klappen wollte, wäre erst eine "Choice" und dann eine Bestätigung. Muss ich mir ansehen, das scheint mir aber auch kein neues Thema zu sein, sondern eher ein bisher unentdecktes.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 18 Mai 2022, 22:18:53
Zitat von: Beta-User am 18 Mai 2022, 19:13:58
Weiß nicht, ob das unzulässige "Brechstange" ist, aber es müßte m.E. gehen, ggf. die alte Sitzung wieder aufzumachen...

Würde ich so sehen. Lieber die Alte kommentarlos enden lassen und mit hermes/dialogueManager/startSession eine Neue starten. Natürlich ware es schöner, eine neue query in dir Session zurück zu geben.

Zitat
Was im Moment noch nicht so richtig klappen wollte, wäre erst eine "Choice" und dann eine Bestätigung. Muss ich mir ansehen, das scheint mir aber auch kein neues Thema zu sein, sondern eher ein bisher unentdecktes.
Wie soll da der komplette Ablauf aussehen?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 19 Mai 2022, 09:31:27
Zitat von: JensS am 18 Mai 2022, 22:18:53
Würde ich so sehen. Lieber die Alte kommentarlos enden lassen und mit hermes/dialogueManager/startSession eine Neue starten. Natürlich ware es schöner, eine neue query in dir Session zurück zu geben.
Wie üblich muss man sich die Details dann mal näher ansehen. Allerdings macht es (so nicht intentFilter im Spiel ist) m.E. wenig Sinn, eine neue query zu machen (das Ergebnis war ja grade "not recognized"), sondern wenn, dann geht es m.E. darum, dass man "nach dem Spiel" woanders anfragt, ob z.B. Babble was damit anfangen kann, oder "alexa", oder.... Und wenn dann von da eine "Heureka"-Rückmeldung kommt (es konnte eine Antwort auf die Frage gefunden oder eine Aktion ausgeführt werden), dann muss halt irgendwie die Antwort an den betreffenden Satelliten zurückkommen (und ggf. die Sitzung (? oder nur das Mikrofon?) für weitere Rückfragen offen gehalten werden.

Zitat
Wie soll da der komplette Ablauf aussehen?

Vorausgesetzt, die Rahmenbedingungen sind entsprechend (mehrere gleich benannte Devices, anderer Sprecher-Raum wie beide Devices, Bestätigung erforderlich):
ZitatU: Schalte den Verstärker an!
R: Wohnzimmer oder Esszimmer?!?
U: Esszimmer...
R: Bitte bestätige das
U: Ja mach!
R: OK

So der Soll-Ablauf. Im Moment kommt statt des "OK" halt die Rückmeldung, dass keine Bestätigung erwartet wird...
EDIT: Vermutlich habe ich die betreffenden Stellen identifiziert, die dafür verantwortlich waren. Man muss bei asynchronem Datengeschubse wirklich aufpassen, was man wo wie lange vorhalten sollte...




Weiteres feature der neuen Version:
Für den key "Value" wird ein "custom-flaot-converter" angwandt, also "5 . 77" wird immer zu "5.77". (Thx. @drhirn für das präventive Rausnehmen des bisherigen Codes).
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 19 Mai 2022, 09:38:48
Zitat von: Beta-User am 19 Mai 2022, 09:31:27
Wie üblich muss man sich die Details dann mal näher ansehen. Allerdings macht es (so nicht intentFilter im Spiel ist) m.E. wenig Sinn, eine neue query zu machen (das Ergebnis war ja grade "not recognized"), sondern wenn, dann geht es m.E. darum, dass man "nach dem Spiel" woanders anfragt, ob z.B. Babble was damit anfangen kann, oder "alexa", oder.... Und wenn dann von da eine "Heureka"-Rückmeldung kommt (es konnte eine Antwort auf die Frage gefunden oder eine Aktion ausgeführt werden), dann muss halt irgendwie die Antwort an den betreffenden Satelliten zurückkommen (und ggf. die Sitzung (? oder nur das Mikrofon?) für weitere Rückfragen offen gehalten werden.

Ich hätte das spontan eher als "Fire and Forget" behandelt. Und v.a. optional. Das Progrämmchen, dass dann die nicht erkannten Intents behandelt, muss sich selber um Rückmeldungen kümmern. RHASSPY ist zu dem Zeitpunkt raus.

Zitat(Thx. @drhirn für das präventive Rausnehmen des bisherigen Codes).
Hab nichts gemacht. Nur den Hinweis gelöscht, dass der Code nicht funktioniert. Tut er nämlich schon.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 19 Mai 2022, 10:07:23
Zitat von: drhirn am 19 Mai 2022, 09:38:48
Ich hätte das spontan eher als "Fire and Forget" behandelt. Und v.a. optional. Das Progrämmchen, dass dann die nicht erkannten Intents behandelt, muss sich selber um Rückmeldungen kümmern. RHASSPY ist zu dem Zeitpunkt raus.
Der Code ist heute (hoffentlich) so strukturiert, dass man einen "custom intent" "intentNotRecognized" ansteuern kann. Wie der dann agiert, ist komplett offen, und im Prinzip auch "fire and forget". Verhindert wird damit in jedem Fall, dass die Standardantwort kommt.
ABER: Man kann zum einen natürlich eine passendere Antwort darüber generieren ("einen Moment, ich frage mal beim alphabet") oder Rückmeldungen dazu von innerhalb aufgerufenem Code (? BabbleDoIt()) weiterleiten, einschließlich der Aufforderung, die Sitzung offen zu halten (was ggf. Probleme machen könnte).
Muss man sich ansehen.

Offen ist auf jeden Fall, wie man damit umgehen müßte, wenn externe Dienste angezapft werden. Das läuft sinnvollerweise asynchron, und die Rückmeldung müßte dann wieder der Sitzung zugeordnet werden, damit auch die Ausgabe wieder an dem Satelliten erfolgt, den der betr. User für die Eingabe genutzt hatte.
Ich habe dazu im Moment keine konkreten Pläne, u.a. auch deswegen, weil mir im Moment noch kein Code über den Weg gelaufen ist, über den man aus FHEM heraus z.B. irgendwelche "handelsüblichen Anfragen" an welchen Dienst auch immer stellen (und verarbeiten) könnte.

Zitat
Hab nichts gemacht. Nur den Hinweis gelöscht, dass der Code nicht funktioniert. Tut er nämlich schon.
Hmm, bei mir wollte das mit dem customConverter nicht, die sentences wollte Rhasspy nicht akzeptieren. Hatte aber bisher auch nicht die Muße, da nochmal nachzusehen, warum es nicht will wie es soll (abgesehen vom Checken, welche Art Zeilenumburch die Datei enthält). Ist auch nicht wirklich wichtig, im Zweifel hält doppelt genäht besser...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 19 Mai 2022, 10:14:04
Zitat von: Beta-User am 19 Mai 2022, 10:07:23
Offen ist auf jeden Fall, wie man damit umgehen müßte, wenn externe Dienste angezapft werden. Das läuft sinnvollerweise asynchron, und die Rückmeldung müßte dann wieder der Sitzung zugeordnet werden, damit auch die Ausgabe wieder an dem Satelliten erfolgt, den der betr. User für die Eingabe genutzt hatte.
Ich habe dazu im Moment keine konkreten Pläne, u.a. auch deswegen, weil mir im Moment noch kein Code über den Weg gelaufen ist, über den man aus FHEM heraus z.B. irgendwelche "handelsüblichen Anfragen" an welchen Dienst auch immer stellen (und verarbeiten) könnte.

Eigentlich könnte man RHASSPY überhaupt außen vor lassen. Nicht erkannte Intents könnte ja z.B. auch einfach ein Python-Progrämmchen gleich direkt bearbeiten.
Aber, wenn schon RHASSPY im Spiel ist, hätte ich mir gedacht, dass man den Input einfach weiterleitet. Mit siteId. Wie auch immer. Um den Rest kümmert sich dann wer anderer. Auch um die Rückmeldung an die richtige Adresse.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 19 Mai 2022, 10:38:02
Zitat von: drhirn am 19 Mai 2022, 10:14:04
Eigentlich könnte man RHASSPY überhaupt außen vor lassen. Nicht erkannte Intents könnte ja z.B. auch einfach ein Python-Progrämmchen gleich direkt bearbeiten.
An sich wäre es wünschenswert, wenn man sowas als eine Art "Zwischenprüfung" innerhalb von Rhasspy zentral verfügbar hätte, keine Frage. Ein "Progrämmchen" dürfte allerdings untertrieben sein, weil das ein asynchrones Vorgehen erfordert und mAn. zumindest einige wenige Sitzungsdaten (ggf. auch parallel) gepuffert werden müssen.

Zitat
Aber, wenn schon RHASSPY im Spiel ist, hätte ich mir gedacht, dass man den Input einfach weiterleitet. Mit siteId. Wie auch immer. Um den Rest kümmert sich dann wer anderer. Auch um die Rückmeldung an die richtige Adresse.
Genau dasselbe Problem mit dem Puffern hat man, wenn man es innerhalb FHEM versucht. Zwar kann man an customIntent ja alles (!) weiterleiten, was sich in $data befindet, aber das (zusätzliche) "Sitzungsmanagement" ist ja bereits in RHASSPY drin - es ist also m.E. wesentlich einfacher, diesen Teil einfach (geringfügig?) zu erweitern, statt nochmal eine Parallelstruktur (in Perl oder Python) aufzubauen...

Kann aber durchaus sein, dass ich damit falsch liege :) .
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 19 Mai 2022, 18:11:32
Zitat von: Beta-User am 19 Mai 2022, 09:31:27
U: Schalte den Verstärker an!
R: Wohnzimmer oder Esszimmer?!?
U: Esszimmer...
R: Bitte bestätige das
U: Ja mach!
R: OK
U: Schalte den Verstärker an! - Gibt den Intent [setOnOff] mit dem $DEVICE Verstärker ohne $Raum aus.
R: sessionContinue wird mit dem Text "Wohnzimmer oder Esszimmer?!?" und dem temporär aktivierten Intent [Raum] mit dem Inhalt $Raum gestartet. Alle sonstigen Daten kommen in customData.
U: Esszimmer... - Gibt den Intent [Raum] mit dem $Raum Esszimmer aus.
R: Bastelt sich aus $Raum und und customData ein passendes Szenario zusammen und fragt mit einem weiteren sessionContinue (Intent confirm/cancel) mit dem Text "Bitte bestätige ...", ob das in Ordnung wäre.
U: Ja mach!
R: Führt die Aktion, welche in sessionContinue->customData gespeichert ist aus und schließt die Session mit endSession und dem Text "OK".

Ich denke, so könnte es gehen. Beim ABC funktioniert es jedenfalls.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 19 Mai 2022, 18:43:56
Zitat von: Beta-User am 19 Mai 2022, 09:31:27
EDIT: Vermutlich habe ich die betreffenden Stellen identifiziert, die dafür verantwortlich waren. Man muss bei asynchronem Datengeschubse wirklich aufpassen, was man wo wie lange vorhalten sollte...
Jetzt auch getestet; Fix ist im svn...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 23 Mai 2022, 16:15:15
Im Nebenthread (https://forum.fhem.de/index.php/topic,124952.msg1195323.html#msg1195323) gibt's wieder eine Testversion, mit in der DEF aktivierten Key "experimental=1" wechselt RHASSPY jetzt vom
- Gruppen- zum Einzelintent, wenn diese kein Mitglied im Raum hat und es (genau) ein Gerät mit gleichem Namen (im Raum, notfalls auch außerhalb, aber nicht mehr wie eines) gibt und
- Einzel- zum Gruppenintent, wenn es kein (ohne weiteres identifizierbares) Gerät mit diesem Namen gibt und eine gleich benannte Gruppe mind. ein Mitglied im Raum hat.

Das umzusetzen war weniger schwierig als gedacht, und es dürfte auch eher erwartete Ergebnisse zeitigen wie mein gestriger gedanklicher Ansatz:
Zitat von: Beta-User am 22 Mai 2022, 10:20:54bei der "welche Devices passen?"-Anfrage dann nicht nur Arrays mit "im Raum" und "außerhalb Raum" zu liefern, sondern zusätzlich "Devices in so benannten Gruppen im Raum" und "Devices in so benannten Gruppen außerhalb Raum" zu liefern.
Weiß aber noch nicht so recht, ob der jetzige Lösungsvorschlag wirklich alle Fälle abdeckt. Daher das Ganze als Testversion ;) .

Zitat von: Beta-User am 19 Mai 2022, 09:31:27
Weiteres feature der neuen Version:
Für den key "Value" wird ein "custom-flaot-converter" angwandt, [...]
Der ist seit der gestrigen svn-Version  so ergänzt, dass er mit "allen möglichen" Zahlenspielchen in Value umgehen können sollte, einschließlich negativer Zahlen.

Diese Version sollte auch mit pah's Ergänzungen in FEST.txt umgehen können, und hat für alle Varianten von "schriftlichem Input" (Messenger, AMAD.* und Tests) einen Konverter drin, der Kommazahlen so für Rhasspy vorbereitet, dass dann auch wieder die Einzelteile verwertbar nach Value kommen (passende sentences vorausgesetzt). Schriftlich "10,5 Grad" werden also als "10 komma 5 Grad" an Rhasspy-NLU übergeben, das gibt dann "10 . 5" zurück und der "custom-flaot-converter" macht daraus dann wieder "10.5"...
Theoretisch könnte man das noch etwas ausbauen, mit "minus", "12:44 Uhr" und ähnlichem habe ich mich noch nicht befasst.
EDIT: z.B. "12:44 Minuten" als Textübergabe sollten jetzt auch funktionieren.

Zitat von: Beta-User am 17 Mai 2022, 10:06:40
Bliebe dann die Frage, wie man am anderen Ende (also auf der Rhasspy-Seite) sinnvollerweise die STT-Einstellungen konfiguriert, damit man wirklich eher "frei" sprechen kann und nicht zwanghaft bei irgendwas landet, was in sentences.ini angelegt war. Ist Neuland für mich - meine Versuche, "open transcription" zu aktivieren haben in endlosen trainings-sessions geendet... Also falls jemand einen "schnellen Tipp" hat: her damit!
...gilt weiter...

Seid ihr eigentlich alle im Urlaub, oder warum ist es so still grade?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 23 Mai 2022, 18:32:49
Zitat von: Beta-User am 23 Mai 2022, 16:15:15
Seid ihr eigentlich alle im Urlaub, oder warum ist es so still grade?

Im Urlaub hätte ich Zeit und Muße... Es gibt bestimmt noch mehr Tester*innen; oder sagt man Testende?   :o
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Gisbert am 23 Mai 2022, 19:17:10
Zitat von: Beta-User am 23 Mai 2022, 16:15:15
Seid ihr eigentlich alle im Urlaub, oder warum ist es so still grade?

Hallo Jörg,
nein, eigentlich nicht - aber anscheinend gibt es noch wichtigere Dinge, die mich vom Fhem-Forum ferngehalten haben. Ich verfolge deine Rhasspy-Threads im Groben und muss sagen, dass ich deinen Diskussionen mit drhirn und Jens(S) nicht Schritt halten kann. Das darf als Kompliment verstanden werden; das ist echt eine Menge Arbeit, die du in dieses Projekt gesteckt hast. Ich bin gerne bereit demnächst zu testen, wenn ich genau weiß, was und wie ich es anstellen muss - im Moment wüsste ich es auf Anhieb noch nicht. Fhem halte ich sehr regelmäßig up-to-date, einmal wöchentlich.

Was mich vor allem interessiert, ist ein Dialog, wenn meine Anweisung nicht eindeutig ist, und ein Abbruch durch mich, wenn die weiteren Versuche ebenso nicht eindeutig sind. Die Verbindung zu AMAD würde mich auch interessieren, da ich dieses schon nutze. Schubs mich gerne mit einem Vorschlag an, wie ich den Einstieg in die Veränderungen finde.

Viele Grüße Gisbert
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 23 Mai 2022, 19:51:59
Zitat von: JensS am 23 Mai 2022, 18:32:49
Im Urlaub hätte ich Zeit und Muße...
...und ich keinen hinreichenden Zugriff auf FHEM+Rhasspy, um vernünftig testen zu können ;D ... Daher die Frage.

Aber Danke für die Rückmeldungen bis dato. Ich habe halt keinen wirklichen Anhaltspunkt, wer auf welchem Stand ist und wie zufrieden (oder eben auch nicht ::) ).

Prinzipiell bin ich allerdings sehr froh, dass anscheinend seit längerem keiner irgendwelche berechtigten Beschwerden vorzutragen hat ;D .

Zitat von: Gisbert am 23 Mai 2022, 19:17:10
wenn ich genau weiß, was und wie ich es anstellen muss - im Moment wüsste ich es auf Anhieb noch nicht. Fhem halte ich sehr regelmäßig up-to-date, einmal wöchentlich.
Die letzten Eingriffe waren jedoch "unter der Haube" schon etwas tiefgreifender. Von daher würde mich  bis z.B. Ende der Woche schon die Rückmeldung beruhigen, dass alles keine Auffälligkeiten bringt... Jeder "testbereite User" könnte eine Sicherheitskopie seiner aktuell genutzten .pm machen und entweder die aktuelle svn-Version oder die Test-Version runterladen (Rechte checken) + einfach nutzen (oder ggf. zusätzlich eben den "experimental"-key auf 1 setzen).

Ich bin allerdings dann in der Tat ein paar Tage weg, daher die Sicherheitskopie nicht vergessen (oder rausfinden, wie man notfalls (s)eine alte Version aus dem svn holt).

Zitat
Was mich vor allem interessiert, ist ein Dialog, wenn meine Anweisung nicht eindeutig ist, und ein Abbruch durch mich, wenn die weiteren Versuche ebenso nicht eindeutig sind.
An sich funktioniert "das dialogische" nach meinem Eindruck (jetzt auch mit multi-Kommandos und der svn-Version) ganz gut. Ich weiß aber nicht, auf welchem Stand deine sentences dazu sind usw..
Im Zweifel dazu auf eine der beiden aktuellen Versionen wechseln und dann einen separaten Thread dazu aufmachen oder den "neue Ufer"-Thread fortsetzen, dann können wir das separat - ohne die "komplizierten Zwischenrufe" - so durchackern, dass es (hoffentlich) für dich paßt :) .

Ein wesentliches Hilfsmittel für mich bei dieser Sache war übrigens pah's Testsuite - deswegen hatte ich dazu vor längerem mal einen eigenen Thread dazu aufgemacht. Damit kann man u.A. eben feststellen, wie Rhasspy bestimmte Dinge interpretiert und welche Geräte in FHEM dann ggf. tatsächlich angesprochen werden. Bei Interesse an diesem Punkt bitte einfach diesen "Faden" aufgreifen.

Zitat
Die Verbindung zu AMAD würde mich auch interessieren, da ich dieses schon nutze. Schubs mich gerne mit einem Vorschlag an, wie ich den Einstieg in die Veränderungen finde.
Wenn du bisher AMAD nicht für "voiceInput"-Aktionen genutzt hattest, sollte es reichen,
- dein RHASSPY-FHEM (genauer: dessen siteId wie im gleichnamigen Internal zu finden) als Satelliten für die Intent-Recognition bei Rhasspy anzugeben; das braucht man übrigens auch für das Testen und die Interaktion per msg (Telegram&Co))
- das AMAD-Device als "zulässig" zu benennen, z.B. so:
attr RHASSPY rhasspySpeechDialog allowed= TabletWohnzimmer
Dann mußt du nur noch "irgendwie" den voiceInput aktivieren (ich habe dazu einen shortcut für diese "automagic-Aktion" angelegt), und schon kannst du RHASSPY/Rhasspy auf diesem Weg mit "mach was"-Anweisungen "füttern".

Für mehr Details dazu bitte diese Anleitung per Zitat in einen neuen Thread zu AMAD+RHASSPY, auch das ist vermutlich ein Thema, das besser gesondert abgehandelt wird, damit es übersichtlich bleibt. Und eines, das vielleicht noch nicht hinreichend bekannt ist - damit kann man nämlich auch ohne zusätzliche Hardware (offline-) Sprachsteuerung für FHEM verwirklichen! Und zwar "internationalisiert" und nicht auf die deutsche Sprache beschränkt...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Prof. Dr. Peter Henning am 23 Mai 2022, 20:23:41
ZitatSeid ihr eigentlich alle im Urlaub, oder warum ist es so still grade?
Ich habe in dieser Woche rund 50 Stunden feste Termine und nächste Woche LEARNTEC - wolltest Du tauschen?

LG

pah
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 23 Mai 2022, 20:36:43
Zitat von: Prof. Dr. Peter Henning am 23 Mai 2022, 20:23:41wolltest Du tauschen?
Danke, nein; mein Stressbedarf ist bereits gefühlt lebenslänglich gedeckt...
Viel Freude jedenfalls mit der LEARNTEC!

Vor diesem Hintergrund aber ein ausdrückliches und fettes Danke für deinen Input über das WE - das hat mich in der Tat weitergebracht und geholfen, manches (teils nur gefühltes) Hindernis (hoffentlich) vollends in den Griff zu bekommen.

PS: du kannst "alle" in den Beispiel-Sätzen gerne ganz oder zum Teil durch "die" oder ähnliches ersetzen. Hatte das als "Gruppenkennwort" eh' schon seit längerem mit drin (es war aber nicht mehr gegenwärtig). Jetzt ist das <die> - vermutlich mit kleineren Einschränkungen - (technisch) nicht mehr  erforderlich. Gleichwohl ist es zum Sprechen aber mit <die> (gefühlt) "runder".
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Prof. Dr. Peter Henning am 24 Mai 2022, 18:32:10
ZitatViel Freude jedenfalls mit der LEARNTEC!
Sehn wir mal. Ich hatte eine feste Zusage der Bundesministerin für Bildung und Forschung Bettina Stark-Watzinger für die Eröffnung - jetzt wird sie zwar live, aber nur virtuell da sein.

LG

pah
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 25 Mai 2022, 12:42:01
Zitat von: Prof. Dr. Peter Henning am 24 Mai 2022, 18:32:10
Sehn wir mal. Ich hatte eine feste Zusage der Bundesministerin für Bildung und Forschung Bettina Stark-Watzinger für die Eröffnung - jetzt wird sie zwar live, aber nur virtuell da sein.
Nun denn, immer wieder erhellend zu sehen, welchen Stellenwert welches Thema bei wem so zu haben scheint...
Na ja, vielleicht täuscht das auch. Viel Erfolg jedenfalls.

Im Nebenthread gibt es noch ein update für die Testversion. Da ist jetzt das "changeover"-feature standardmäßig aktiviert, über einen neuen key im DEF kann man einstellen, ob man ganz ausschalten will oder nur changeover von {Device} nach {Group} verhindern (das erscheint mir potentiell "gefährlicher"). Bin unschlüssig, ob die Einstellungsmöglichkeit an dieser Stelle verbleiben soll oder in Tweaks wandern, aber vorab wäre erst mal wichtig, ob es irgendwelche Probleme verursacht und/oder allgemein begrüßt wird (=default würde geändert, wenn zu viele Gegenstimmen kämen)...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Prof. Dr. Peter Henning am 25 Mai 2022, 15:26:36
ZitatNa ja, vielleicht täuscht das auch.
Leider nicht, heute morgen hat sie ganz abgesagt. Ich habe meinen Unmut schon in die politischen Kanäle eingespeist.

LG

pah
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 28 Mai 2022, 12:29:44
Zitat von: Beta-User am 23 Mai 2022, 16:15:15
Seid ihr eigentlich alle im Urlaub, oder warum ist es so still grade?
Ja, war ich wirklich ;)

Wollte gerade mit dem "etwas lauter" spielen. Dabei ist mir etwas anderes aufgefallen:

Ich habe einen TV und einen RCV. Beide mit genericDeviceType "media". Wenn ich jetzt "mach etwas lauter" sage, nimmt sich RHASSPY per Zufall (?) eines der beiden Geräte. Sollte da nicht automatisch nachgefragt werden, welches Device verwendet werden soll?


2022.05.28 12:15:38 5: Response is: Wird erledigt
2022.05.28 12:15:38 5: TV volume 29.5 is a normal command
2022.05.28 12:15:38 5: analyzeAndRunCmd called with command: volume
2022.05.28 12:15:38 5: [Rhasspy] getNeedsConfirmation called, regex is TV
2022.05.28 12:15:38 5: Device selected: TV
2022.05.28 12:15:38 5: room is identified using siteId as wohnzimmer
2022.05.28 12:15:38 5: handleIntentSetNumeric called
2022.05.28 12:15:38 5: Parsed value: mache ein bisschen lauter for key: rawInput
2022.05.28 12:15:38 5: Parsed value: mache ein 0.75 volUp for key: input
2022.05.28 12:15:38 5: Parsed value: 1 for key: confidence
2022.05.28 12:15:38 5: Parsed value: volUp for key: Change
2022.05.28 12:15:38 5: Parsed value: porcupine_raspberry-pi for key: customData
2022.05.28 12:15:38 5: Parsed value: 0.75 for key: Factor
2022.05.28 12:15:38 5: Parsed value: wohnzimmer.pc for key: siteId
2022.05.28 12:15:38 5: Parsed value: SetNumeric for key: intent
2022.05.28 12:15:38 5: Parsed value: wohnzimmer.pc-porcupine_raspberry-pi-8b11b43c-167a-4754-bb11-035452cc9053 for key: sessionId
2022.05.28 12:15:38 5: RHASSPY: [Rhasspy] Parse (IO: rhasspyMQTT2): Msg: hermes/intent/de.fhem_SetNumeric => {"input": "mache ein 0.75 volUp", "intent": {"intentName": "de.fhem:SetNumeric", "confidenceScore": 1.0}, "siteId": "wohnzimmer.pc", "id": null, "slots": [{"entity": "Factor", "value": {"kind": "Unknown", "value": "0.75"}, "slotName": "Factor", "rawValue": "bisschen", "confidence": 1.0, "range": {"start": 10, "end": 14, "rawStart": 10, "rawEnd": 18}}, {"entity": "Change", "value": {"kind": "Unknown", "value": "volUp"}, "slotName": "Change", "rawValue": "lauter", "confidence": 1.0, "range": {"start": 15, "end": 20, "rawStart": 19, "rawEnd": 25}}], "sessionId": "wohnzimmer.pc-porcupine_raspberry-pi-8b11b43c-167a-4754-bb11-035452cc9053", "customData": "porcupine_raspberry-pi", "asrTokens": [[{"value": "mache", "confidence": 1.0, "rangeStart": 0, "rangeEnd": 5, "time": null}, {"value": "ein", "confidence": 1.0, "rangeStart": 6, "rangeEnd": 9, "time": null}, {"value": "0.75", "confidence": 1.0, "rangeStart": 10, "rangeEnd": 14, "time": null}, {"value": "volUp", "confidence": 1.0, "rangeStart": 15, "rangeEnd": 20, "time": null}]], "asrConfidence": 0.7460910000000001, "rawInput": "mache ein bisschen lauter", "wakewordId": "porcupine_raspberry-pi", "lang": null}
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Prof. Dr. Peter Henning am 28 Mai 2022, 19:59:09
Das ist ein generelles Problem der unbestimmten Orte - beispielsweise auch "überall" und "irgendwo".

Hier sollte in der Tat immer ein Dialog eingeleitet werden. Beispiel:


----> Starting dialog
[Babble_DoIt] Input:  bitte spiele musik
              Ergebnis: Category=1.3.0: Gerät=musik Ort=none Verb=spielen Ziel=none /
              Antwort:  {speak('Tab2.EG','Das mache ich gerne, bitte sage mir wo Du gerade bist')}
---->
[Babble_DoIt] Input:  ich bin im wohnzimmer
              Ergebnis: Category=3.4.7: Gerät=ich Ort=wohnzimmer Verb=none Ziel=none /
              Antwort:  {speak('Tab2.EG','Von wem soll ich im wohnzimmer Musik spielen? ')}
---->
[Babble_DoIt] Input:  von den pogues
              Ergebnis: Category=3.2.5: Gerät=pogues Ort=none Verb=none Ziel=den /
              Antwort:  {speak('Tab2.EG','OK, ich werde im wohnzimmer die spezielle Musik pogues von   spielen ')}
----> Ending dialog
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 28 Mai 2022, 20:13:19
Hmmm, das scheint mir eher ein spezielles Überbleibsel aus der Zeit vor der Dialog-Option zu sein ("nimm das erste passende Gerät aus dem aktuellen Raum"). Muss mal schauen, ob diese Spezialbehandlung noch sinnvoll ist oder ergänzt/umgebaut werden sollte...Vermutlich ist es wirklich zufällig (for keys ...).
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Prof. Dr. Peter Henning am 29 Mai 2022, 10:06:38
Eine der wichtigsten Sachen bei Benutzungsoberflächen (auch sprachbasierten) ist die Modellbildung. Der Benutzer oder die Benutzerin müssen immer wissen, warum etwas geschieht. Wenn also ein System eine zufällige Handlung ausführt, muss also eine Erklärung geliefert werden: "Ich nehme an, Du meinst das Gerät X" - das "warum" ist hier also eine Annahme des Systems.

LG

pah
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 30 Mai 2022, 14:05:37
Im Nebenthread ist eine Aktualisierung zu finden, die zumindest das "mach etwas lauter" nachvollziehbarer handhaben müßte.

Bisher wurde so eine Anweisung über "getActiveDeviceForIntentAndType()" geschleust, die einfach der erste "angeschaltete" Element aus den Listen "inside room" bzw. "outside  room" geliefert hatte - dabei war wirklich ein "for keys" vorgeschaltet, also ein gewisses Zufallselement integriert.

Jetzt kann man getDeviceByIntentAndType() gleich so aufrufen, dass nur angeschaltete Devices kommen, was für "SetNumeric" keine weiteren Probleme aufwirft, da das sowieso damit umgehen kann, dass ggf. mehrere Devices geliefert werden und dann nachgefragt werden muss.

Die "getActive"-Anfrage gab es dann noch in handleIntentMediaControls(), da ist das jetzt ebenfalls umgestellt (aber noch nicht getestet).

(Irgendwie hatte es mich schon gewundert, dass da noch keiner drübergestolpert gewesen war)...

Durch die Umstellung kann es allerdings auch ansonsten zu einem geänderten Verhalten kommen, da die "prio"-Vorgaben jetzt auch berücksichtigt werden müßten. Nach meinem Verständnis ist das aber in jeden Fall eine Verbesserung... (also z.B.: Wenn Verstärker und Fernseher an ist, verweist "prio" immer auf den Verstärker). (Kann aber sein, dass man eine eigene Priorisierung für den "an"-Fall vorsehen sollte?)

Zitat von: Prof. Dr. Peter Henning am 29 Mai 2022, 10:06:38
Wenn also ein System eine zufällige Handlung ausführt, muss also eine Erklärung geliefert werden: "Ich nehme an, Du meinst das Gerät X" - das "warum" ist hier also eine Annahme des Systems.
Na ja, eigentlich sollte man mAn. komplett zufällige Verhaltensweisen gar nicht erst "einplanen", von daher ist/war das hier nach meinem Verständnis gar nicht der "warum"-Fall. Sowas könnte aber eine Rolle spielen, wenn man Wahrscheinlichkeiten (oder schlechte "confidence"-Werte) berücksichtigt.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 30 Mai 2022, 14:23:31
Zitat von: Beta-User am 30 Mai 2022, 14:05:37
Durch die Umstellung kann es allerdings auch ansonsten zu einem geänderten Verhalten kommen, da die "prio"-Vorgaben jetzt auch berücksichtigt werden müßten. Nach meinem Verständnis ist das aber in jeden Fall eine Verbesserung... (also z.B.: Wenn Verstärker und Fernseher an ist, verweist "prio" immer auf den Verstärker). (Kann aber sein, dass man eine eigene Priorisierung für den "an"-Fall vorsehen sollte?)

Wie setz ich die nochmal?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 30 Mai 2022, 14:29:12
Lt. commandref:
attr sensor_outside_main rhasspySpecials priority:inRoom=temperature outsideRoom=temperature,humidity,pressureMein Verstärker (teils zum Testen):
attr Yamaha_Main rhasspySpecials scenes:scene1="Musik hören" scene2="Film ansehen" scene3=none scene4="vorderen Eingang auswählen"\
priority: inRoom=volume outsideRoom=volume,scene\
confirm: SetOnOff="wirklich $target $Value schalten?" SetScene


Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 30 Mai 2022, 14:31:32
Ah ja, hatte ich mir am Wochenende eh schon mal angesehen. Ich verstehe aber leider die Bedeutung von "inRoom" und "outsideRoom" nicht so richtig. Kannst du mir das bitte schnell erklären? Danke!
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 30 Mai 2022, 14:43:01
Hmm, kann's ja mal versuchen:
"inRoom" gibt die Priorisierung vor, wenn es mehrere Geräte im Raum (={Room} bzw. aus siteId abgeleitet) gibt, die passen können.
"outsideRoom" kommt erst dann zum Tragen, wenn es kein passendes Gerät im Raum gibt und "irgendwo" gesucht werden muss, ob irgendwas passendes gefunden wird.

In meinem Beispiel - es gibt hier noch einen Verstärker, der ist aber im Esszimmer (der andere im Wohnzimmer):
attr Yamaha_Zone2 rhasspySpecials priority:inRoom=volume
Wenn du also "mach lauter" sagst, wird immer einer dieser beiden angesprochen werden (wenn angeschaltet), obwohl es mind. noch ein weiteres Gerät in diesen beiden Räumen gibt, das auch "volume"-Kommandos versteht (und RHASSPY bekannt ist, ein MPD-Device).
Im/für das Esszimmer gesprochen wirkt der Befehl eben auf "zone2", sonst auf den "main".
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 30 Mai 2022, 15:05:07
Danke!
Mich verwirrt, dass du in den Beispielen bei outsideRoom immer mehrere Einträge hast. In der CRef auch. Wenn ich die Lautstärke schalten will, sind mir doch Szenen egal. Und wenn ich die Temperatur wissen will (CRef), muss ich Luftfeuchtigkeit und Luftdruck doch nicht wissen!?
Oder ist das so zu verstehen, dass du 5 Räume hast, in denen jeweils Thermometer hängen. Im sechsten ist keiner. Wenn du aber in Raum 6 nach der Luftfeuchtigkeit fragst, willst du immer den Wert aus Raum 1 haben?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 30 Mai 2022, 15:18:52
Na ja, wie geschrieben: Teils sind meine eigenen Beispiele auch so, weil ich das zum Testen brauch(t)e ::) ...
Tatsächlich sind in praktisch allen Räumen Thermometer vorhanden, das ist eher ein Rest aus dem "outsideRoom"-Test. Nicht überall vorhanden sind aber z.B.  Luftdruck-Sensoren. Wenn ich aber den Luftdruck wissen will, dann eigentlich immer den von draußen.

Die Kritik an den "Szenen" (oder allgemein: den Mehrfach-Angaben) kann ich nicht ganz nachvollziehen, prinzipiell geht es (auch) darum zu zeigen, dass man nicht darauf beschränkt ist, ein einziges "Schlüsselwort" für diese Priorisierungen anzugeben. Und für die Frage, wie man es denn "gut" macht mit all den vielen Optionen gibt es sogar einen ganzen Thread ;D ... (Da ist es nur ziemlich ruhig ??? ).
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 30 Mai 2022, 15:38:22
Das war keine Kritik. Find's grundsätzlich sogar gut. Sieht man gleich, dass mehrere Optionen möglich sind. Ich hab's nur einfach nicht verstanden ;)
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 30 Mai 2022, 15:48:50
...ist ja auch nicht unbedingt selbsterklärend, das alles...
"outsideRoom" kommt bei mir auch eher selten vor, "inRoom" aber schon. Hier vielleicht noch zwei+ Beispiele betr. die Temperatur-Regelung:

Esszimmer - es gibt einen Raumthermostat, über den läuft alles - Abfragen und "set"-Anweisungen. Es gibt noch viel mehr Thermometer (bzw. "desired-temp"-Geräte)...

Thermostat_EssZi_Climate     priority:inRoom=desired-temp,temperature,humidity


Wohnzimmer: Kein Raumthermostat, die Homematic-RT-DN bekommen eine virtuelle Temperatur (vom "Raumfuehler) und arbeiten im Team => man muss nur einen ändern, dann bekommt der andere das irgendwann auch mit...
Raumfuehler_Wohnzimmer     priority:inRoom=temperature
Thermostat_Wohnzimmer_SSO_Clima     priority:inRoom=desired-temp
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 31 Mai 2022, 08:09:56
Zitat von: Prof. Dr. Peter Henning am 28 Mai 2022, 19:59:09Beispiel:


----> Starting dialog
[Babble_DoIt] Input:  bitte spiele musik
              Ergebnis: Category=1.3.0: Gerät=musik Ort=none Verb=spielen Ziel=none /
              Antwort:  {speak('Tab2.EG','Das mache ich gerne, bitte sage mir wo Du gerade bist')}
---->
[Babble_DoIt] Input:  ich bin im wohnzimmer
              Ergebnis: Category=3.4.7: Gerät=ich Ort=wohnzimmer Verb=none Ziel=none /
              Antwort:  {speak('Tab2.EG','Von wem soll ich im wohnzimmer Musik spielen? ')}
---->
[Babble_DoIt] Input:  von den pogues
              Ergebnis: Category=3.2.5: Gerät=pogues Ort=none Verb=none Ziel=den /
              Antwort:  {speak('Tab2.EG','OK, ich werde im wohnzimmer die spezielle Musik pogues von   spielen ')}
----> Ending dialog

...nicht dass du denkst, ich hätte die Herausforderung übersehen ::) ...

Sollen wir zu diesem Intent(kreis) einen separaten Thread starten?

Da wirbeln bei mir im Moment ziemlich viele unfertige Gedanken durcheinander, angefangen von der Frage, ob es sinnvoll ist, meine Sammlung zu "versloten" (https://community.rhasspy.org/t/whats-the-craziest-thing-you-can-or-cannot-do-with-rhasspy/3648/24; ich habe da arge Bedenken, dass das nicht ein heilloses Chaos hingäbe, schon alleine wegen der Interpreten/Alben-Namen in den diversen Sprachen, die man halt so in einer normalen Sammlung hat), oder ob man nicht besser/auch einen "allgemeinen Buchstabier-Choice-Auswerte-Code" bereitstellen sollte bis hin zu der spaßigen Frage, wie man das am besten umsetzt, wenn nicht zwangsläufig in jedem Raum dieselbe Ausgabe-Methode anwendbar ist....

Von daher würden mich Details zu der von dir gezeigten Lösung sehr interessieren!
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 31 Mai 2022, 16:54:48
Wollte euch mal kurz an meinen Versuchen zur Vorbereitung für einen eventuellen "allgemeinen Buchstabier-Choice-Auswerte-Code" teilhaben lassen...

Man nehme:

- einen neuen slot, der diverse Buchstabiertafeln enthält (siehe Anhang):
( a | Alfa | Anton | Albert | Augsburg | Aachen ):a
( ä | Alfa-Echo | Ärger | Änderung | Umlaut-A | Umlaut Aachen ):ä
( be | Bravo | Berta | Bruno | Bernhard | Berlin ):b
( ze | Charlie | Cäsar | Cottbus ):c
( zeha | Charlie-Hotel | Charlotte | Chemnitz [Hamburg]):ch
( de | Delta | Dora | David | Düsseldorf ):d
( e | Echo | Emil | Essen ):e
( äf | Foxtrot | Friedrich | Fritz | Frankfurt ):f


- eine "kleine" Ergänzung in "Choice":
[de.fhem:Choice]
choose= ( nimm [bitte] | [bitte] nimm | ich hätte gerne | [ich] (wähle|nehme) )
letter= ($de.letters | (0..9) | ( leerzeichen | platz |  nächstes wort ):space | ( bindestrich | strich |  minus ):- | ( Apostroph):' )

<choose> [( den (Song | Titel ){Type:title} | das Album{Type:album} | die Platte{Type:album} | den ( Interpreten | Sänger ){Type:artist} | die ( Band | Gruppe ){Type:artist} )] <letter>{L1} <letter>{L2} [<letter>{L3} [<letter>{L4} [<letter>{L5} [<letter>{L6} [<letter>{L7} [<letter>{L8} [<letter>{L9} [<letter>{L10} [<letter>{L11} [<letter>{L12} [<letter>{L13} [<letter>{L14} [<letter>{L15} ]]]]]]]]]]]]] [und] <letter>{Llast}


Dann lasse man Rhasspy in Ruhe trainieren (öhm, mein Server kam da an seine Grenzen...), und schon kann man sich sauberen Buchstabensalat liefern lassen, denn man ohne weitere auch wieder zusammenkleben könnte...

Beispiel (zur Demo mit explizitem Leerzeichen):
Zitatich hätte gerne die band berlin ludwig ida nürnberg Köln strich eins acht zwei platz
{"L1":"b","L2":"l","L3":"i","L4":"n","L5":"k","L6":"-","L7":1,"L8":8,"L9":2,"Llast":"space","Type":"artist","confidence":1,"customData":null,"input":"ich hätte gerne die artist b l i n k - 1 8 2 space","intent":"Choice","lang":"de","rawInput":"ich hätte gerne die band berlin ludwig ida nürnberg Köln strich eins acht zwei platz","requestType":"voice","sessionId":"defhem_0_testmode","siteId":"defhem"}

So weit so gut...
Das ganze zerstört nur leider den bisher fluffigen Performance-Eindruck, die Rhasspy auf meiner ollen Murmel hinterlassen hat => Neue Hardware oder andere Lösung :'( ... (klar, man kann das gleich an einigen Enden abspecken, aber dann ist es vermutlich weniger intuitiv).

Na ja, soviel jedenfalls  erst mal dazu...

Die gestrige Version ist (um überflüssigen Code erleichtert) eingecheckt, es gab ja keine rechtzeitigen Beschwerden, sondern eher keine Klagen über die letzten Änderungen ::) .
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 31 Mai 2022, 17:28:48
Jössas Maria!
"Erste Allgemeine Verunsicherung"
"Electric Light Orchestra"
"Earth, Wind & Fire"
"Fury in the Slaughterhouse"
"Fragements of Unbecoming"
"Me First And The Gimme Gimmes"
Da wirst beim Buchstabieren ja alt :D
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 31 Mai 2022, 17:51:29
Lustig sind auch
Van der Graaf Generator
George Thorogood & The Destroyers
Albert King with Stevie Ray Vaughan


Na ja, nachdem bei "den paar Buchstaben" schon einige "unbekannte Wörter" dabei waren, wird es bei ausländischen Band- und Künstlernamen dann halt vermutlich lustig....
Der Trick wäre ggf. der, einige wenige Buchstaben ausreichen zu lassen für eine regex-basierte Suche. Mit normalen Tastatureingaben klappt das ja eigentlich auch ganz ordentlich und fix (in meinem Fall MPD+MALP).
(Falls jemand noch den Buchstabiercode von JensS im Hinterkopf parat hat: Da sehe ich das Problem, dass zu kurze Sequenzen dann gerne nach "IntentNotRecognized" gehen würden (wenn/solange Choice deaktiviert ist. Das Abfangen dieses Effekts finde ich in "CancelAction" besser aufgehoben.)

Oder hat da jemand Erfahrung, wie gut das mit kompletten Künstlernamen klappt? (Also nicht nur bei 10-20...). Ich fürchte halt, dass der Nacharbeitsaufwand (bis zur "Sprechbarkeit") nicht zu schaffen wäre...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 31 Mai 2022, 22:20:09
Hier nochmal die Buchstabier-Sub für die Wikipedia:sub ABC{
my $data = shift // return;
my $Buchstabe = shift // return;
my $SessionJSON = decode_json($data);
my $SessionID = $SessionJSON->{'sessionId'};
my $SiteID = $SessionJSON->{'siteId'};
my $CustomData = $SessionJSON->{'customData'}.$Buchstabe;
if ($Buchstabe ne "suche"){
my $ReturnHash = {
sendIntentNotRecognized => q{true},
intentFilter => [qq{de.fhem:ABC}],
customData => $CustomData,
text => $Buchstabe
};
return $ReturnHash;
}
else{
$CustomData =~ s/WIKI de.fhem:ABC //g;
$CustomData =~ s/suche//g;
Wikipedia($data,$CustomData);
}
}

Der Intent [ABC] ist per Standard deaktiviert und wird bei Bedarf plus Cancel-Intent als Filter gesetzt.
Wenn das Wort "suche" erkannt wird, ruft der else-Zweig die Wikipedia-Sub mit den Session-Daten und CustomData auf.
Das würde auch mit eine Regex-Sub gehen...

Das Problem bei der Erkennung von einzelnen Buchstaben wie "a" ist, dass die ASR schon auf den Sprecher hört, obwohl aus dem Lautsprecher noch Sprachausgabe tönt. Echocanceling ist dabei unerläasslich oder man verzichtet auf die akustische Rückgabe der gesprochenen Buchstaben. Bei der Langversion (nach DIN) "Anton" ist daher die Erkennung besser.

Gruß Jens
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 01 Juni 2022, 09:48:42
Zitat von: Beta-User am 31 Mai 2022, 16:54:48
Dann lasse man Rhasspy in Ruhe trainieren (öhm, mein Server kam da an seine Grenzen...)

Von durchschnittlich 4s für's Training auf
Training completed in 73.96 second(s)

;D
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 01 Juni 2022, 10:30:29
Zitat von: drhirn am 01 Juni 2022, 09:48:42
Von durchschnittlich 4s für's Training auf
Training completed in 73.96 second(s)

;D
;D ;D ;D ...
Hatte ja "Spaß" versprochen 8) . Bei meiner ollen 2-Kern-AMD-Murmel kannst du bequem Faktor 10 nehmen, und wie gesagt: Man merkt es dann auch in der Auswertung (was ich bei deinem Server noch nicht annehme)...
(OT: Es hat sich für mich bewährt, sowas auf eher schwächerer Hardware auszutesten. Auch meine damaligen ersten Fehlkonfigurationen in FHEM wären mir vermutlich auf meinem jetzigen Server gar nicht aufgefallen, auf dem Pi2B aber schon...)

Na ja, jedenfalls ist die "Endlosbuchstabier-Option" mAn. nicht der Stein der Weisen, selbst wenn man das vermutlich in erträgliche Regionen bringt, wenn man z.B. die Zahl der möglichen Buchstaben etwas reduziert und/oder die möglichen Varianten pro Buchstabe.

Grundlage war übrigens von hier: https://de.wikipedia.org/wiki/Buchstabiertafel#Tabelle_mit_historischen,_aktuellen_und_diskutierten_Versionen (und auch das u.a. darunter zu findende ICAO-Alphabet).

Wenn Buchstabieren, dann also eher nach dem Vorschlag von JensS. Muss ich aber auch erst mal in Ruhe testen...
Zitat von: JensS am 31 Mai 2022, 22:20:09
Das Problem bei der Erkennung von einzelnen Buchstaben wie "a" ist, dass die ASR schon auf den Sprecher hört, obwohl aus dem Lautsprecher noch Sprachausgabe tönt. [...] Bei der Langversion (nach DIN) "Anton" ist daher die Erkennung besser.
Neben dem Echo-Thema sehe ich aber ein paar weitere "Wölkchen am Horizont":
- Die Kurzversionen dürften "nogo-Zone" sein. Sonst wird Stille nicht nach "CancelAction" ("nein" ist mein kürzestes Wort und das wird anscheinend für Stille erkannt) abgeleitet und so ggf. dann auch kein IntentFilter-Reset durchgeführt. Außerdem könnte es sein, dass sonst neuerdings eine Sprachausgabe ertönt, weil (bei deaktiviertem Intent ) "intentNotRecognized"-Messages versendet werden.
- Wenn man einzeln buchstabiert, muss der User immer sauber aufpassen, dass er im Timing bleibt;
- läßt man Mehrfacheingaben zu (vielleicht bis zu max. 5-8?), gilt das vermutlich umso mehr;
- im Prinzip müßte/könnte man zwischendurch prüfen lassen, ob das (Zwischen-) Ergebnis bereits hinreichend ist (das klingt aber nach (für meine Begriffe) ziemlich komplexem Code);
- das ganze müßte generischer aufgebaut sein, also für im Prinzip beliebige Eingaben tauglich sein (das Ende wäre dann durch einen entsprechenden Key, z.B. {Spelling:end} zu kennzeichnen). customData dürfte dann dazu dienen, das zu füllende Datenfeld zu benennen? (Zwischenspeichern muss dann anders gehen, was aber kein allzugroßes Ding sein sollte, machen wir in anderen Fällen ja auch).
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 01 Juni 2022, 10:36:45
Ich würde da nicht zu viel Energie rein stecken. Hab so das Gefühl, da kommen keine wirklich brauchbaren Lösungen raus.
Das Einzige, was ich mir vorstellen könnte ist, dass Rhasspy das Profil bzw. die Sprache wechseln kann. Und man dann halt einen Satz wie "Spiel bitte das englische Lied Blowing in the Wind" verwendet.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 01 Juni 2022, 11:11:00
Na ja, "Energie reinstecken" ist relativ.

Prinzipiell fände ich es cool, wenn das mit der Musikauswahl (abseits irgendwelcher starren vorgefertigten Lösungen, z.B. via Playlist/Szenenauswahl) klappen würde. Manchmal muss man halt auf sowas eine Zeitlang "rumkauen" bis man einen brauchbren Weg findet. Mal sehen.
Und wenn einzelne Bausteinchen mal getestet bzw. optimiert (oder als Irrweg bekannt) sind, hat das ja auch was...

In
Zitat von: drhirn am 01 Juni 2022, 10:36:45
einen Satz wie "Spiel bitte das englische Lied Blowing in the Wind" verwendet.
ist vermutlich ein doppeltes Problem zu finden:
- Die Auswertung (Schalter für "englisch") müßte "zwischendurch" in Rhasspy erfolgen. Wäre mir neu, dass das bei der Eingabe ginge (@JensS: Das Beispiel für die Ausgabe mit Miminc 3 hatte ich gesehen, cool!)
- Wenn Rhasspy weiß, welche phonemische Schreibweise "Blowing in the Wind" hat, ist es vermutlich völlig egal, welche Sprache es ursprünglich mal war, das muss halt im Zeitpunkt der Erkennung hinterlegt sein. Daher auch mein Hinweis, dass es mir eher unwahrscheinlich erscheint, meine Sammlung ohne größeren Nacharbeitsaufwand per script in einen slot zu packen.

Wobei: Mein nächster gedanklicher Angang wäre gewesen, zumindest mal zu versuchen, eine "artist"-Liste mit den "wichtigsten" Künstlern zu basteln (z.B.: alle, die mehr wie 20-100 Titel in der Datenbank haben). Weiß nicht, ob da "Earth, Wind & Fire" auftaucht, aber "Boold, Sweat &Tears" bestimmt, und dann würde man zumindest mal eine Vorstellung davon bekommen, wie in etwa der tatsächliche Aufwand aussähe...

OT:
Falls jemand eine allgemeine Script-Idee dazu hat (also für ein slot program, https://rhasspy.readthedocs.io/en/latest/training/#slot-programs (https://rhasspy.readthedocs.io/en/latest/training/#slot-programs), analog https://community.rhasspy.org/t/whats-the-craziest-thing-you-can-or-cannot-do-with-rhasspy/3648/24 (https://community.rhasspy.org/t/whats-the-craziest-thing-you-can-or-cannot-do-with-rhasspy/3648/24)), würde mir das ggf. schon sehr weiterhelfen. Nur eben nicht für KODI, und nach Möglichkeit auch nicht "alles auf einmal"... Hier ginge die Abfrage entweder auf dem "MPD-Way" oder über DNLA-Methoden (es läuft auch ein miniDNLA-Server (oder wie auch immer das heutzutage heißt)).

Nachtrag: ggf. eine Basis - https://manuel-io.github.io/blog/2020/03/29/query-minidlna-to-list-media-files/
(https://manuel-io.github.io/blog/2020/03/29/query-minidlna-to-list-media-files/)und auch interessant: https://python.hotexamples.com/de/examples/mpd/MPDClient/list/python-mpdclient-list-method-examples.html
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 01 Juni 2022, 15:50:29
https://kamprianis.eu/michalis/i.think/personal/210612-home-assistant-example.html (https://kamprianis.eu/michalis/i.think/personal/210612-home-assistant-example.html)
Sowas in der Art?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 01 Juni 2022, 16:26:23
Zitat von: JensS am 01 Juni 2022, 15:50:29
https://kamprianis.eu/michalis/i.think/personal/210612-home-assistant-example.html (https://kamprianis.eu/michalis/i.think/personal/210612-home-assistant-example.html)
Sowas in der Art?
Jo!

Nur halt für MPD oder eben "ReadyMedia" (wie miniDNLA jetzt wohl heißt). Das Problem ist wohl, dass die beide - zumindest nach meinen bisherigen kurzen Recherchen - keine abgegrenzten Suchläufe (in obigem Code: "die ersten 100 Playlisten") zu kennen scheinen. Bedeutet: Man muss sich wohl für diese beiden mehr oder weniger immer eine Gesamtliste/die ganze Datenbank schicken lassen und kann dann selbst rauswerfen, was man nicht braucht. Tja, wenn man jetzt programmieren könnte...

Na ja, jedenfalls war bisher der "Playlisten-Modus" nicht so meiner (es gibt ihn, aber mehr als Hilfsmittel, um Radiostationen aus TvHeadend abzuspielen), aber gerade das scheint zum einen der häufiger anzutreffende Weg zu sein und zum anderen ist das auch der, für den am meisten Code schon (für mich) einfach zu verwerten vorhanden wäre (in Perl ;) , im MPD-Modul)....
Mal sehen, ob ich damit (irgendwann!) anfange?

An sich wäre es "besser" (=generischer und auch für meinen "2. Player" universeller nutzbar), den DNLA-Weg zu nehmen, MPD scheint etwas aus der Mode gekommen zu sein (kann aber "normalize" für die Lautstärke, daher ist mir der zumindest im Moment noch sehr viel lieber ;) ). Oder nehme ich doch noch mal einen Anlauf mit KODI?!? (Oder schau mal in den UPNP-FHEM-Modul-Code, da war doch auch einiges los in letzter Zeit...?!?)

Muss da wohl noch etwas drauf rumkauen ;D ::) ;D ...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 01 Juni 2022, 17:36:58
Beim mpd kannst du über telnet u.a. nach den Playlists fragen:
echo listplaylists | nc 192.168.x.x 6600
Mit commands kanst du dir die commands auflisten lassen.

p.s. Wenn du das in (FHEM) perl machen willst, kannst du doch ein MPD-Device definieren und mit get MPD playlists oder get MPD music arbeiten. Der ganzen Ramsch muss dann aber rüber zu Rhasspy und dort in ein Verzeichnis geschrieben werden.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 01 Juni 2022, 19:29:35
Thx, die Ausgabe erklärt dann auch, was im MPD-Modulcode erst etwas komisch anmutet...

Damit ich's wiederfinden: https://mpd.readthedocs.io/en/latest/protocol.html enthält die komplette Beschreibung, und eine gute Ausgangsbasis hat man, wenn man schlicht erst mal alles abruft mit
echo list album group albumartist | nc 192.168.xx.xx 6600 > mpdcontents.txt (strg+c für's Beenden des Vorgangs).

Da sowieso eine Nachbearbeitung erforderlich erscheint, ist es vermutlich einfacher, erst mal damit eine (automatisiert erstellte) slot-Datei zu basteln, statt direkt ein slot-Programm draus zu machen (bei mir sind da u.A. auch unicode-codierte Interpretennamen in japanischen Schriftzeichen (?) dabei...).

Achso: Das MPD-Device direkt anzuzapfen ist vermutlich keine gute Idee, irgendwann (ziemlich schnell) hatte ich dem verboten, nach den ergänzenden Infos beim Server anzuklopfen. Stellt man loadPlaylists oder loadMusic auf was anderes wie "0", steht FHEM praktisch ::) ... Hat mich bisher nicht näher interessiert, warum, weil andere Wege sowieso bequemer waren, und auch jetzt geht es ja eigentlich darum, wie man es generisch macht - also optimalerweise ganz außerhalb von FHEM (was ja Perl nicht ausschließt ;) ).
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 02 Juni 2022, 07:40:27
Zitat von: Beta-User am 01 Juni 2022, 19:29:35
echo list album group albumartist | nc 192.168.xx.xx 6600 > mpdcontents.txt (strg+c für's Beenden des Vorgangs).
Kleiner Tipp - ein -q 1 beendet die Verbindung automatisch.
echo list album group albumartist | nc -q 1 192.168.x.x 6600 > mpdcontents.txt

Letztlich wäre (aus meiner Sicht) ein Script in Python die beste Wahl, da Rhasspy das in allen Systemen mitbringt.

Gruß Jens

p.s. Hab gerade mit Hilfe deines Links zu MPD Folgendes gelesen:
ZitatAll data between the client and the server is encoded in UTF-8
Unicode wäre dann ungewöhnlich.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 02 Juni 2022, 20:13:31
Hier ein lauffähiges Pythonscript in /username/.config/rhasspy/profiles/de/slots/import
Diese Datei muss ausfürbar sein. Es werden automatisch die Slots import und fhemtester angelegt.
Leider zickt MPD rum und es kommt nur OK MPD 0.21.4. Mit dem list .* beim FHEM-Telnetport funktioniert es.
#!/usr/bin/env python3

import socket

server_addr = ("192.168.x.x", 6600)
client_socket = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
client_socket.settimeout(2)
file = open("/pi/.config/rhasspy/profiles/de/slots/fhemtester","w")
client_socket.connect(server_addr)
sendestring = b'listplaylists\n'
client_socket.send(sendestring)
while True:
  datenstring = client_socket.recv(2048)
  datenstring = datenstring.decode()
  file.write((datenstring+"\n"))
  if "OK\n" in datenstring:
    break
file.close()
client_socket.close()
del client_socket
print("Das ist eine Platzhalterdatei")


Aufgerufen wird das Ganze beim Training durch [fhemtest]
$import
in der sentences.ini.

p.s. Geht nun doch.  :)
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 02 Juni 2022, 20:53:36
 :) Bin mit Perl schon etwas weiter...

#!/usr/bin/perl

#perl ./getMpdSlots.pl > mpd_contents_out.txt

use strict;
use warnings;
use IO::Socket;

my $host = '127.0.0.10';
my $port = '6600'; #default
my $timeout = 2;
my $password = '';

my $maxartists = 10;

my $sock = IO::Socket::INET->new(
    PeerHost => $host,
    PeerPort => $port,
    Proto    => 'tcp',
    Timeout  => $timeout
    );

printf("started\n");
die $! if !$sock;

printf("sock ok\n");

while (<$sock>)  # MPD rede mit mir , egal was ;)
{ last if $_ ; } # end of output.

chomp $_;

die  "not a valid mpd server, welcome string was: $_." if $_ !~ m{\AOK MPD (.+)\z};

if ($password ne '') {
  # lets try to authenticate with a password
  print $sock "password $password\r\n";
  while (<$sock>) { last if $_ ; } # end of output.

  chomp;

  if ( $_ !~ m{\AOK\z} ) {
    print $sock "close\n";
    close($sock);
    die "password auth failed : $_." ;
  }
}

my ($artists, $artist, @playlists);

#start playlist request
print $sock "listplaylists\r\n";
while (<$sock>) {
  die  "ACK ERROR $_" if $_ =~ s/^ACK //; # oops - error.
  last if $_ =~ m/^OK/;    # end of output.

  if ( $_ =~ m{\A(?:playlist[:]\s)(.+)} ) {
    push @playlists, $1;
  }
}

print $sock "list album group albumartist\r\n";
while (<$sock>) {
  die "ACK ERROR $_" if $_ =~ s/^ACK //; # oops - error.
  last if $_ =~ m/^OK/;    # end of output.

  if ( $_ =~ m{\A(?:AlbumArtist[:]\s)(.*)} ) {
    $artist = $1;
  }
  if ( $_ =~ m{\A(?:Album[:]\s)(.*)} ) {
    next if !$artist || !$1 || $artist eq "Various Artists";
    $artists->{$artist}->{cnt}++;
    push @{$artists->{$artist}->{albums}}, $1;
  }
}

#got all data?
print $sock "close\n";
close($sock);


printf("Playlists section \n\n") if @playlists;
for ( @playlists ) {
    printf("( ( %s ):%s )\n", $_, $_);
}

printf("\n") if @playlists;
my @artlist = sort {
        $artists->{$b}{cnt} <=> $artists->{$a}{cnt}
        or
        $artists->{$a} <=> $artists->{$b}
        }  keys %{$artists};

printf("Artists section \n\n") if @artlist;
my $albums;
for my $i (0..$maxartists-1) {
    printf("( ( %s ):%s )\n", $artlist[$i], $artlist[$i]);
    for my $alb ( @{$artists->{$artlist[$i]}->{albums}} ) {
        $albums->{$alb} = 1;
    };
}

printf("\nAlbums section \n\n") if @artlist;
for my $alb (sort keys %{$albums}) {
    printf("( ( %s ):%s )\n", $alb, $alb);
}

1;

__END__

ABER: Das Ergebnis ist nur bedingt "tauglich" (wie erwartet).

Werde vermutlich mal versuchen,
- einen "cleanup"-Code zwischenzuschalten, der die Rohdaten "links" so aufbereitet, dass Rhasspy das auch trainiert...
- einen kombinierten Slot zu basteln, der Album und Artist gleich in tauglicher Kombination zusammenbringt {Album} <by> {Artist}.

Dazu ist vermutlich mein "Altschnippselchen" hier noch hilfreich:
for my $i (0..$maxartists-1) {
    for my $alb ( @{$artists->{$artlist[$i]}->{albums}} ) {
        printf("( ( %s ):%s )\n", $alb, $alb);
    };
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 03 Juni 2022, 17:16:55
Zitat von: JensS am 02 Juni 2022, 20:13:31
p.s. Geht nun doch.  :)
:)

Das Problem (oder besser: eines der vielen Probeme....) ist weniger die Playlist-Geschichte. Das sollte in den Griff zu bekommen sein, obwohl "MediaControl" bisher auch noch keinen passenden Command kann. ABER: Zumindest das kann MPD heute schon, wenn man ihn passend füttert... (der Verstärker wohl eher nicht).

Ab da wird es aber dann lustig...

Ein paar findings:
- MPD (heutiges FHEM-Modul) kann keine Artist/Album-Anweisungen verarbeiten (=> kleine Erweiterung notwendig);
- Die Syntax, um das dann sinnvoll zu befüllen, ist lustig (https://mpd.readthedocs.io/en/latest/protocol.html#escaping-string-values) => die Vorverarbeitung der dann eventuell irgendwann in RHASSPY ankommenden Daten ist noch viel lustiger...
- Mein erster Wurf für "kombinierten Bereinigungscode" scheint zu laufen, da kommt dann z.B. sowas raus:
( ( Chicago three ):Chicago III ){Album} <by> ( ( Chicago ):Chicago ){AlbumArtist}
( ( [The] Song Remains the Same ):The Song Remains the Same ){Album} <by> ( ( Led Zeppelin ):Led Zeppelin ){AlbumArtist}
( ( Preservation Act one ):Preservation Act 1 ){Album} <by> ( ( [The] Kinks ):The Kinks ){AlbumArtist}
( ( Ballads  and  Blues 1982 - 1994 ):Ballads & Blues 1982 - 1994 ){Album} <by> ( ( Gary Moore ):Gary Moore ){AlbumArtist}
( ( Happiness Is the Road  Volume 1  Essence ):Happiness Is the Road, Volume 1: Essence ){Album} <by> ( ( Marillion ):Marillion ){AlbumArtist}

Bin mal gespannt, ob Rhasspy mit den so bereinigten Zwischenergebnissen im Training klarkommt. Überraschend fand ich gestern, dass die "guesses" von Rhasspy eigentlich ganz ok waren, wie denn die (relativ wenigen) englischen Begriffe so auszusprechen wären.

Wie man erahnen kann, ist da einiges dabei, was man trotzdem nochmal nachbearbeiten müßte oder auf eine Art "ignore"-Liste setzen. Da Rhasspy die slots immer wieder zu "shuffeln" scheint, ist Wiederfinden irgendeiner Info ziemlich spaßfrei, und man kann das ganze mAn. auch nur zu einem gewissen Punkt sinnvoll automatisieren. Mit "einfach mal so nebenbei" machen lassen, ist vermutlich kein Blumentopf, aber ein Stall von Problemem zu gewinnen, v.a., wenn man eine größere Sammlung hat.

Danach dann der nächste Schritt => Vorbereitung für die MPD-Ansteuerung.

Daneben habe ich mal in die commandref zu YAMAHA_.* geschaut, v.a. auch YAMAHA_MC. Aber da findet sich nichts in Sachen Playlist-Steuerung (obwohl mein Yamaha das "irgendwie" kann, wenn ich die Musiccast-App auf meinen ReadyMedia-Server loslasse...). Muss wohl damit etwas spielen und ggf. auch die "neuen" Module zu DLNA-Geräten mal installieren...

Alles also ein weites Feld ::) .
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 04 Juni 2022, 13:09:37
So, nach etwas testen ein kleiner Zwischenstand:

RHASSPY (svn-Version, Doku und Feinschliff fehlen noch) kann jetzt auch "playlist"-Befehle absetzen (MPD wird automatisch erkannt).

sentence dazu:
[de.fhem:MediaControls]
atDevice=[(am|des|bei|beim|auf dem)] $de.fhem.Device-media{Device}

spiele{Command:cmdPlaylist} $de.playlists{Playlist} <atDevice>

Theoretisch sollte das mit einer etwas abgewandelten Fassung von JensS's Script direkt gehen.




Ansonsten ist es weniger "spaßig", weil das Training mit meinen automatisierten slots/Keys nicht so recht will. Es hilft zwar weiter, den "input" um Klammern usw. zu erleichtern, aber Klammern "hinten" führen auch zu Syntaxfehlern beim Training. 

Mal sehen, für mich wäre der "Umweg" über die musicbrainz-Tags denkbar:
echo list album group artist group musicbrainz_albumid | nc 192.168.xx.xx 6600

Und es könnte für den Rest auch ausreichend sein, die "unleserlichen" Teile einfach wegzulassen, und das ganze dann z.B. an MPD als Perl-regex-like EXPRESSION zu übergeben. Das ist dann aber schon sehr speziell auf MPD zugeschnitten. Für mich nicht der Beinbruch, aber eben doch dann nicht so universell.

Na ja, anbei jedenfalls mal meine aktuellen weiteren Codes, falls jemand mit basteln will ;) ...

Zum MPD siehe auch https://forum.fhem.de/index.php/topic,18517.msg1223957.html#msg1223957 (https://forum.fhem.de/index.php/topic,18517.msg1223957.html#msg1223957), es geht damit auch sowas:set myMPD addSelection ((artist =~ 'Gary.M') AND (album =~ 'Run.for'))

EDIT: script ist so geändert, dass es auch als slot-Programm tauglich sein sollte (oben einfach den "$mode" entsprechend einstellen. Wenn möglich, gibt es jetzt die/eine musicbrainz-Id aus (es kann zu Problemen/Verwechslungen mit gleich benannten Alben kommen, wenn man den "Einzel-slot" generieren läßt).
"Problemzeichen" sind durch Punkte ersetzt, v.a. da, wo es keine eindeutige ID gibt (v.a. bei Albennamen mit Sonderzeichen).
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 05 Juni 2022, 11:35:43
Zitat von: Beta-User am 04 Juni 2022, 13:09:37
Es hilft zwar weiter, den "input" um Klammern usw. zu erleichtern, aber Klammern "hinten" führen auch zu Syntaxfehlern beim Training. 

Rhasspy verarbeitet die Syntax der sentences.ini nicht immer sauber. Wenn eine Zeile innerhalb eines Intents mit "[" beginnt, sollte ein Backslash davor helfen. Die Erfahrungen sind aber anders und im Anwendungsfall hilft eine Kapselung der eckigen Klammern vorn und eventuell auch hinten, da Rhasspy alle eckigen Klammer hinten als Abschluss eines Intents erkennt.
spiele{Command:cmdPlaylist} $de.playlists{Playlist} ([(am|des|bei|beim|auf dem)] $de.fhem.Device-media{Device})

Bin mal wieder auf dem Sprung und schaffe es dieses WE auch nicht zu testen.

Gruß Jens
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 05 Juni 2022, 16:24:17
Na ja, mal sehen...

Anbei eine aktualisierte Fassung des scripts

Was leider nicht ganz klappt, ist das Ding gleich universell als slot-script via bash aufrufen zu können, mit der Frage, wie man den "$mode" mit dem Aufruf auf der shell übergibt, bin ich bisher nicht klargekommen...

Was aber gehen sollte: Auf die eigenen Bedürfnisse anpassen, und dann entprechend viele Kopien unter passendem Namen (und dem jeweiligen korrekten $mode) verwenden.

In $mode=4 kommt dann bei Alben, die musicbrainz-ID's haben dann z.B. sowas raus:
( ( Lola versus Powerman and the Moneygoround  Part One ):(895abd03-6d7d-4fde-8016-05dcee7fc4b7) ){AlbumId} [<by> ( ( [The] Kinks ):(The.Kinks) ){AlbumArtist}]
( ( Radiation ):(cf54eea5-b411-42e0-9a74-d8c140ef34e3) ){AlbumId} [<by> ( ( Marillion ):(1a02e1e4-000e-46fa-83de-f3a36674e4fc) ){AlbumArtistId}]

Damit müßte sich was anfangen lassen....

Ist das nicht so optimiert getaggt, müßte auch sowas hier ausreichen:
( ( Chicago eight teen ):(Chicago.18) ){Album} [<by> ( ( Chicago ):(Chicago) ){AlbumArtist}]
MPD kann ja auch Perl-regex-like Anweisungen verarbeiten.

Jetzt lasse ich mal Trainieren und irgendwann schau' ich dann mal, wie man das "an den MPD" bringt 8) ...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 06 Juni 2022, 11:44:45
Immer noch nicht getestet aber eine Idee zur Argumenteübergabe.
sentences.iniwähle (alle{$Intent,print=all}|playlist{$Intent,print=playlist}|genres{$Intent,print=genres}|artists{$Intent,print=artists})
getMpdSlots.pl$md = $ARGV[0] // "print=playlist";
if ($md eq "print=all"){$mode = 0}elsif($md eq "print=playlist"){$mode = 1}elsif($md eq "print=genres"){$mode = 2}elsif($md eq "print=artists"){$mode = 3};
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 06 Juni 2022, 14:54:44
Mein MPD-Device musste ich gerade löschen, weil irgendwas FHEM komplett blockiert hat. Das hängt aber nicht mit der Änderung zusammen. Hatte es schonmal und damals verdrängt. Irgendein Radiosender scheint nicht kompatibel zu sein...

Das Konstrukt zw. 73_MPD.pm, sentences.ini, getMpdSlots.pl und slot_programs/??? gibt mir noch Rätsel auf. Wo soll was hin?
In meinem Pythonscript hatte ich ein die gefundenen Slotwerte in eine Hilfsdatei slots/fhemtester geschrieben.
Wenn man die Slotwerte direkt im Slotprogramm ausgibt, funktioniert zwar die Erkennung aber man kann nicht separat auf die Slotwerte zugreifen.
Sie erscheinen nicht im Webinterface unter Slots und auch nicht beim Webaufruf /api/slots.
Für eine Argumenteverarbeitung wäre aber wichtig, die generierten Slotelemente auswerten zu können.

Gruß Jens
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 06 Juni 2022, 18:04:02
Zitat von: JensS am 06 Juni 2022, 14:54:44
Mein MPD-Device musste ich gerade löschen, weil irgendwas FHEM komplett blockiert hat. Das hängt aber nicht mit der Änderung zusammen. Hatte es schonmal und damals verdrängt. Irgendein Radiosender scheint nicht kompatibel zu sein...
Es ist m.e. eher der Versuch, "alles" zu laden. Die load.*-Attribute auf "0" setzen sollte helfen. (Muss mal schauen, ob es sinnvoll ist, das default-Verhalten zu ändern).

Zitat
Das Konstrukt zw. 73_MPD.pm, sentences.ini, getMpdSlots.pl und slot_programs/??? gibt mir noch Rätsel auf. Wo soll was hin?
Die 73_MPD kann halt zusätzlche Befehle, die wir hoffentlich irgendwann brauchen.

Das Perl-Script kann dazu genutzt werden, entweder "alles" anzuzeigen, oder eben unter je einem eigenen Namen und passendem Wert für $mode DIREKT als slot-Programm genutzt werden.

Ich mache damit im Moment einen Gesamt-output und scheibe den per > in eine Datei und kopiere dann die Teile jeweils zum Testen raus - das aber bisher nur in Teilen...

Zitat
In meinem Pythonscript hatte ich ein die gefundenen Slotwerte in eine Hilfsdatei slots/fhemtester geschrieben.
Dieser Umweg ist m.E. ein komischer workaround. "Ganz oder gar nicht"...

Das ganze ist im Moment eine Baustelle mit vielen offenen Fragen. Die Einzelteile sehen aber schon ganz ok aus :) .
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 08 Juni 2022, 07:14:45
Beim MPD-Test muss ich passen. Das MPD-Modul blockieret hin und wieder beim Senderwechsel und dann muss FHEM gekillt werden.
Die Inhalte des MPD habe ich auf eine MP3-Datei und drei Radiosender gekürzt.
Hab den MPD mal mit einem eigenen Steuerungsscript getestet - da gab's bisher noch keine Abstürze. Bin noch auf der Suche...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 08 Juni 2022, 14:52:25
Zitat von: JensS am 08 Juni 2022, 07:14:45
Beim MPD-Test muss ich passen. Das MPD-Modul blockieret hin und wieder beim Senderwechsel und dann muss FHEM gekillt werden.
Die Inhalte des MPD habe ich auf eine MP3-Datei und drei Radiosender gekürzt.
Hmm, unschön...

Komme auch nicht recht weiter mit dem Testen, hatte aber bisher keine Blockaden beobachtet.
Meine playlists sind aber auch eher kurz (was Name und Inhalt angeht). Die verweisen nur auf Sendernamen wie "SWR 1", abgespielt werden sollte dann eigentlich ein Stream, der vom TvHeadend-Server bereit gestellt wird. Da hat sich aber auch irgendwas geändert, so dass ich zwar sehe, dass (im MPD) die ind er playlist stehende Streamnummer geändert wird, aber effektiv kommt dann kein Ton...

Gibt es irgendwelche Sender, bei denen das mit dem Hängenbleiben besonders gerne passiert? Weisen die irgendwelche Besonderheiten auf (Umlaute, Apostrophen, sowas in der Art...)?

Zitat
Hab den MPD mal mit einem eigenen Steuerungsscript getestet - da gab's bisher noch keine Abstürze. Bin noch auf der Suche...
Bisher hat mein MPD auf den abgespeckten Code aus dem Modul immer zackig reagiert, von daher würde ich ungerne zu viel Code "außerhalb" des FHEM-(MPD)-Moduls durch RHASSPY aufrufen lassen.
Allerdings: nachdem ich ein wenig mit dem MPD-Modul und dem Protokoll an sich (https://mpd.readthedocs.io/en/latest/protocol.html) rumgespielt habe, ist es vermutlich am Ende das einfachste, doch eine Art "Roh-Kommando" auf der RHASSPY-Seite zusammenzubasteln und das dann komplett über "mpdCMD" an MPD zu übergeben. Das gibt dann so oder so ein paar "Sonderlocken", um das hinzubiegen...

Wenn dieser "Master" dann mal steht, können wir ja versuchen, das auf "DNLA-Geräte" zu übertragen. Viel mehr Typen scheinen ja im Moment nicht im Umlauf zu sein, und wer einen "sowieso-online-Dienst" wie spotify im Einsatz hat, hat vermutlich schon das Problem, dass es nicht nur "viele" unbekannte Worte sind, sondern "zu viele" für eine Rhasspy-"Verslottung"....
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 12 Juni 2022, 14:04:42
Zitat von: Beta-User am 11 Juni 2022, 19:04:26
- Für MPD sind jetzt ein paar features drin, von denen ich bisher auch nicht in vollem Umfang weiß, ob sie funktionieren.
[...]
Jetzt muss ich erst mal meinen MPD (oder genauer gesagt: das OS von dem Rechner, auf dem der läuft) updaten, dann sehen wir weiter...
Ein paar kleinere Anpassungen waren noch nötig, aber im Prinzip sollte man jetzt beliebige FILTER-Anweisungen an einen halbwegs aktuellen mpd-Dienst (immer über das MPD-Modul) schicken können und/oder das ganze begrenzen auf eine gewisse Anzahl von hinzuzufügenden Elementen. Wenn man das letztere macht, gibt es ein zufälliges Ergebnis aus den gesamten zur Verfügung stehenden passenden Titeln (oder eben der vorhandenen Gesamtzahl, wenn die geringer ist als die übergebene max.-Anzahl).

Konkret getestet:
"spiele ein paar songs von Marillion"

Es sollte aber auch sowas gehen:
"spiele 20 Lieder aus Dark Side of the Moon"
"spiele auch 100 jazz titel"
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Prof. Dr. Peter Henning am 12 Juni 2022, 21:22:14
Ich halte das MPD-Modul (und MPD...) für nicht ganz ausgereift. Wenn ich Musik auf einer Linux-Kiste abspiele, geht das über den mpg123 und ein paar Perl-Routinen zur Ansteuerung.

Insofern sollte man sich vielleich über eine Abstraktionsschicht einigen:  Welches sind die generischen Kommandos, die eine Sprachsteuerung für das Abspielen von Musik beherrschen sollte?

LG

pah

Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 12 Juni 2022, 22:47:58
Zitat von: Prof. Dr. Peter Henning am 12 Juni 2022, 21:22:14
Ich halte das MPD-Modul (und MPD...) für nicht ganz ausgereift.
Dem kann ich mich anschließen.
Die Ursache für den Halt von FHEM durch das MPD-Modul liegt darin begründet, dass der MPD-Server irgendwann keine Antwort mehr sendet und eine while-Schleife im Modul blockiert. Ein Fork inkl. wait und/oder $SIG{ALRM} könnte zumindestens FHEM am laufen halten. In der jetzigen Fassung ist eine Nutzung von 73_MPD.pm zu riskant. Ich schau mal, was ich da machen kann.

Gruß Jens
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 13 Juni 2022, 10:24:24
Zitat von: Prof. Dr. Peter Henning am 12 Juni 2022, 21:22:14
Insofern sollte man sich vielleich über eine Abstraktionsschicht einigen:  Welches sind die generischen Kommandos, die eine Sprachsteuerung für das Abspielen von Musik beherrschen sollte?
Hmmm, ich würde da vor dem Hintergrund meiner bisherigen Erfahrungen mit dem Thema in mehrerlei Hinsicht zwischen "Pflicht" und "Kür" trennen...

Ausgangspunkt ist zum einen, dass eine Sprachsteuerung in der Lage sein sollte, eine Anzahl Basiskommandos umzusetzen, die grob in
https://wiki.fhem.de/wiki/DevelopmentGuidelinesAV (https://wiki.fhem.de/wiki/DevelopmentGuidelinesAV) (Kommandos) umrissen sind, wobei ich on/off nicht direkt dazuzählen würde, sondern es auf die "Klassiker" play/pause/stop beschränken würde. Im "engeren Kreis" würde ich dann noch "playlist" sehen, wobei das als Teil einer "Content-Steuerung" schon zur "Kür" gehört.

Alles, was an "content-Steuerung" darüber hinausgeht, gehört in den Bereich "nice to have". Die jetzige "Lösung" mit MPD und der automatisierten Generierung von slots für RHASSPY ist auch imo irgendeine Form von Kompromis, von dem ich noch nicht weiß, ob er ein guter ist... Ziel war erst mal, _eine mögliche_ Lösung für die Aufgabe "spiele Musik von den Pogues" zu präsentieren :P .

RHASSPY erkennt die obigen Basiskommandos, wenn vorhanden, sowie auch "playlist" und kann dann das betreffende Gerät direkt steuern, wenn man die entsprechenden Werte nach {Command} übergibt bzw. ggf. dann zusätzlich {Playlist}.

Aber bereits da beginnen gewisse "Problemchen" - playlist-Kommandos setzen nämlich nicht nur voraus, dass das Gerät das auch kann (device-media ist daher nur eine Art Vor-Filter), sondern das Gerät dann auch noch genau diese Playlist kennt. Wenn man also nicht nur ein entsprechendes Gerät hat, wird es schnell "spaßig". Das gilt dann noch viel mehr für "generelle Content-Ermittlung" (anhand Genre, Interpret, ...).

Will man sowas umsetzen, erweitert sich der Kreis der generischen Kommandos dann noch um "füge zur aktuellen Abspielliste noch etwas hinzu" und "ersetze die aktuelle Abspielliste mit einer neuen (dynamisch erstellten)". Habe dafür mal die "Etiketten" 'cmdAddSelected' und 'cmdPlaySelected' vergeben.

Will man eine "generalisierte Content-Ermittlung" haben, ist es (zumindest für "cloud-free"-Lösungen) m.E. zweckmäßig, einen einzigen zentralen Dienst vorzusehen, der dann als "Infoquelle" einerseits für die Sprachsteuerung dient (@Rhasspy: slot-Erstellung), und andererseits eben von möglichst allen "Abspielgeräten" als Medienquelle genutzt werden kann.

Zitat von: Prof. Dr. Peter Henning am 12 Juni 2022, 21:22:14
Ich halte das MPD-Modul (und MPD...) für nicht ganz ausgereift. Wenn ich Musik auf einer Linux-Kiste abspiele, geht das über den mpg123 und ein paar Perl-Routinen zur Ansteuerung.
MPD (der Dienst) ist für mich bisher der beste (aktuelle) Kompromis für die Musikwiedergabe gewesen.

Vielleicht hole ich an der Stelle etwas aus:
Früher hatte ich für sehr lange Zeit Amarok (1.4) im Einsatz, dafür gab es (irgendwann später) auch eine App (oder ein WEB-UI?), mit der man den kontrollieren konnte. Das war für mich und meine damaligen Anforderungen super: Datenbankbasierte Musikauswahl, replay gain, crossfade, wenn keine Albumwiedergabe, tolerant gegen alle möglichen und unmöglichen Audio-Formate, clevere "auto-playlisten" Funktionen (? oder gab's die erst in 2.0)...
Irgendwann gab es dann jedenfalls 2.0 und einen Stall von bis dato nicht gekannten Problemen. MPD hat die meisten gelöst, im Moment vermisse ich eigentlich nur das "clevere cossfade" und diese "auto-playlisten"-Funktion (das war irgendein script von der Uni Zürich, wenn ich das richtig im Kopf habe). Und auch die Auswahl via App (es gibt einige schlechte, für mich hat sich MALP am besten bewährt) ist damit halbwegs erträglich, damit ist nur das Verschieben von Titeln innerhalb der Playlist ein wunder Punkt (aber für sowas kann man dann Cantata+Bildschirm hernehmen).
Worauf ich nicht verzichten wollte, ist replay gain (also die automatisierte Lautstärkeanpassung abhängig von einem als Tag (!) gespeicherten relativen Lautstärkewert eines Titels (bzw. Albums)).
Letzteres ist mAn. der Schwachpunkt bei DLNA-basierten Lösungen, wobei ich da nur "die App" meines Yamaha-Receivers vor Augen habe, die auch von der Bedienung her eher "schwach" ist (Musikauswahl macht damit sowas von keinen Spaß, aber vielleicht habe ich auch nur den richtigen Haken noch nicht gefunden...).

Von daher mag MPD als Dienst verbesserungsfähig sein, aber bevor mir nicht jemand bessere Alternativen aufzeigt (die Frage stand im Raum!), ist der für mich erst mal "gesetzt".



Back to RHASSPY:
Prinzipiell ist das Modul derzeit/jetzt so aufgebohrt, dass es erkennt, ob ein Gerät bestimmte Befehle kann, TYPE=MPD bekommt eine Sonder-/Vorzugsbehandlung, nachdem die Optionen 'cmdAddSelected' und 'cmdPlaySelected' intern umgesetzt sind. An der Stelle der Hinweis: um die max.-Anzahl zu ermitteln, wird eine direkte Rückmeldung vom MPD-Dienst ausgewertet; ein fork wäre dafür vermutlich ein Problem.
Es sollte aber möglich sein, z.B. via rhasspySpecials auch beliebige andere Geräte entsprechend zu erweitern (aber dann wohl via Perl-Code). Oder jemand bastelt aus den vorhandenen Bausteinchen was für mpg123... (EDIT: gemeint war: ein Modul).
(Wobei erfahrungsgemäß das Thema sound-Ausgabe aus Linux-Kisten für spaßfreie Abende gut ist...).



Zum MPD-FHEM-Modul:
Es mag sein, dass manches nicht optimal gelöst ist, und den default für den Verbindungsabbruch (2 Sekunden; EDIT: das kann man verkürzen auf 1 Sek., was ggf. immer noch (zu) viel ist) halte ich auch für eher hoch. Tendenziell sehe ich das forken des FHEM-Prozesses eher kritisch (neben dem Problem, dass RHASSPY auf die "count"-Anfrage eine unmittelbare Rückmeldung braucht ist auch der dauerhafte Speicherverbrauch ein Thema!) und würde als Lösung eher eine konfigurierbare Zeit und eine Art "non-blocking ping" sehen, um den Verbindungsstatus regelmäßig zu checken, bevor die eigentliche "while"-Aktion jeweils losläuft.
Kenne mich mit sowas aber vermutlich auch zuwenig aus (beide Server laufen hier 24/7).
EDIT: zur Klarstellung - das RHASSPY-Modul aus dem svn braucht bisher keine Anpassungen im MPD-Modul, allerdings sollte man uU. verbose auf 2 setzen, weil die "mpdCMD"-Anweisungen alle auf verbose-3-Level im Log landen...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Prof. Dr. Peter Henning am 13 Juni 2022, 13:46:00
ZitatAusgangspunkt ist zum einen, dass eine Sprachsteuerung in der Lage sein sollte, eine Anzahl Basiskommandos umzusetzen

Missversteh mich nicht, da bin ich ja voll auf Deiner Seite. Ich störe mich eher am ungenauen Sprachgebrauch, z.B. "etwas" oder "ein paar songs" etc.

LG

pah
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 13 Juni 2022, 14:19:11
Zitat von: Prof. Dr. Peter Henning am 13 Juni 2022, 13:46:00
Ich störe mich eher am ungenauen Sprachgebrauch, z.B. "etwas" oder "ein paar songs" etc.
OK, das ist jetzt was ganz anderes...

Prinzipiell bin ich bei dir, dass man im Umgang mit Ungenauigkeiten eine gewisse Vorsicht walten lassen sollte und ggf. dann eigentlich lieber rückfragen sollte, wenn da ein "zu großer" Interpretationsspielraum bleibt.

Was "etwas" oder "ein paar" sein soll, kann der "Administrator" (oder vielleicht besser: Konfigurator) bestimmen, und es geht selbstredend auch direkt numerisch mit "spiele 5/10/20 Songs". Mir liegen diese eher umgangs- oder allgemeinsprachlichen Quantifizierungen näher als entweder Zahlenarrays auswerten zu lassen, (damit (1..100) funktioniert, was aber zunehmend schmerzhafterweise Trainingszeit kostet) oder mir beim späteren Sprechen zu überlegen, welche einzelnen konkreten Zahlenwerte ich denn jetzt jeweils vorgesehen hatte.

Die Alternative wäre, in Richtung von strukturierten Dialogen zu gehen, was aber bei "ein paar Songs" mAn. künstlich & aufgesetzt wirkt, und v.a. weitere Fragen aufwerfen würde, die vielleicht beherrschbar wären, wenn wir "on the fly" slots ändern bzw. "Sätze" aktivieren/deaktivieren könnten. In der momentanen Situation würde ich aber nicht Richtung voice2json votieren wollen...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 13 Juni 2022, 19:10:12
MPD sendet jeweils zwei Antworten. Wenn die erste kommt, geht's in der Schleife. Fehlt die 2. Antwort, wirkt der Socket-Timeout nicht. Die ganze Prozedur müsste überwacht und ggf. abgebrochen werden. Der blockierende Aufruf ist eh ungünstig für FHEM.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 15 Juni 2022, 10:36:15
Zitat von: JensS am 13 Juni 2022, 19:10:12
MPD sendet jeweils zwei Antworten. Wenn die erste kommt, geht's in der Schleife. Fehlt die 2. Antwort, wirkt der Socket-Timeout nicht. Die ganze Prozedur müsste überwacht und ggf. abgebrochen werden. Der blockierende Aufruf ist eh ungünstig für FHEM.
Für manche Aktionen muss* es m.E. blockierend sein - hier z.B. die "count"-Anfrage. Bei sowas dürfte es auch kaum zu Problemen kommen. (*: Muss ist vielleicht sehr hart, aber die Alternative, das nonblocking auszulegen, erscheint mir extrem aufwändig).

Letztlich ist diese Diskussion aber hier fehl am Platze - ich nehme an, Wzut ist gerne bereit, konkrete Vorschläge ins Modul zu übernehmen und hat ggf. auch mehr Erfahrungen damit wann/wie es zu Problemen kommt. Den Teil sollten wir dann auch dort thematisieren.

Hier könenn wir aber gerne darüber diskutieren, was ggf. Alternativen wären und wie man die dann einbindet :) .
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 18 Juni 2022, 14:15:31
So, ein Lösungsvorschlag ist raus. https://forum.fhem.de/index.php/topic,18517.msg1225316.html#msg1225316 (https://forum.fhem.de/index.php/topic,18517.msg1225316.html#msg1225316)

Gruß Jens
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 19 Juni 2022, 10:53:55
Wie bekomme ich aktuell die playlists und music in die slots?
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 19 Juni 2022, 10:57:36
Zitat von: Beta-User am 05 Juni 2022, 16:24:17
Anbei eine aktualisierte Fassung des scripts

Was leider nicht ganz klappt, ist das Ding gleich universell als slot-script via bash aufrufen zu können, mit der Frage, wie man den "$mode" mit dem Aufruf auf der shell übergibt, bin ich bisher nicht klargekommen...

Was aber gehen sollte: Auf die eigenen Bedürfnisse anpassen, und dann entprechend viele Kopien unter passendem Namen (und dem jeweiligen korrekten $mode) verwenden.

In $mode=4 kommt dann bei Alben, die musicbrainz-ID's haben dann z.B. sowas raus:
( ( Lola versus Powerman and the Moneygoround  Part One ):(895abd03-6d7d-4fde-8016-05dcee7fc4b7) ){AlbumId} [<by> ( ( [The] Kinks ):(The.Kinks) ){AlbumArtist}]
( ( Radiation ):(cf54eea5-b411-42e0-9a74-d8c140ef34e3) ){AlbumId} [<by> ( ( Marillion ):(1a02e1e4-000e-46fa-83de-f3a36674e4fc) ){AlbumArtistId}]

Damit müßte sich was anfangen lassen....
Um die Zahl der Interpreten etc. erst mal zu begrenzen, kann man "die häufigsten xy" einstellen. Im Moment habe ich das Gesamt-Ergebnis in eine Datei schreiben lassen und die einzelnen Teile schlicht noch per c&p in die Slots kopiert.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 19 Juni 2022, 12:21:10
Ok, muss die getMpdSlots.pl umschreiben, da es im Moment keine Albums, sondern nur Playlists gibt.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 19 Juni 2022, 12:37:20
Sollte trotzdem mehr oder weniger as is funktionieren. Ggf $mode ändern.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Gisbert am 19 Juni 2022, 13:02:45
Hallo Jörg,

eine kurze Rückmeldung von mir.

Rhasspy gibt bei meiner Installation eine Antwort, wenn der Befehl unvollständig bzw. mehrdeutig ist. Meistens kommt eine längere Ansage, die kaum verständlich ist, vermutlich ein englischer Text, der in deutsch gesprochen wird. Manchmal kommt eine kurze, verständliche Antwort, dann ist aber die Zeit zu kurz, um darauf zu reagieren; in der Gedenksekunde, die ich benötige, wird das Mikrofon (Android-App) geschlossen.

Kannst du mit dieser Info etwas anfangen, bzw. welche weiteren Informationen benötigst du?

Viele​ Grüße​ Gisbert​
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 19 Juni 2022, 13:15:00
Hmm, vermutlich sind das zwei Themen:

- ist die Sprachdatei aktuell? Es sind ein paar Optionen dazugekommen, von daher kann es sein, dass die (bei dir derzeit) nicht alle übersetzt sind. Ein Blick in das list von RHASSPY sollte zeigen, was ggf. englisch ist.
(Es gibt bzgl. MPD auch ein paar nicht übersetzte Antworten, die kann man derzeit auf diesem Weg auch nicht fixen, die sind hier aber vermutlich nicht gemeint).
- Bei den Dialogen bin ich auch nicht sicher, ob ich da nicht an der falschen Stelle zu viel weggeräumt habe/hatte; muss ich mir anschauen, falls es mit der aktuellsten svn-Version noch ein Thema ist (ich hatte das afaik wieder etwas revidiert, aber noch nicht getestet; es ist leider immer etwas aufwändig, Testszenarien zu bauen).
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Gisbert am 20 Juni 2022, 21:10:05
Hallo Jörg,

Zitat- ist die Sprachdatei aktuell? Es sind ein paar Optionen dazugekommen, von daher kann es sein, dass die (bei dir derzeit) nicht alle übersetzt sind. Ein Blick in das list von RHASSPY sollte zeigen, was ggf. englisch ist.

Hier ein list; wie gesagt, gibt es längere, nicht verständliche Antworten auf einen nicht eindeutigen Befehl:
Internals:
   CFGFN      ./FHEM/myRhasspy.cfg
   CONFIGFILE ./rhasspy-de.cfg
   DEF        baseUrl=http://192.168.1.46:12101 devspec=genericDeviceType=.+ language=de
   FUUID      61978863-f33f-e986-532e-c2d28847a3d59476
   IODev      rhasspyMQTT2
   LANGUAGE   de
   LASTInputDev rhasspyMQTT2
   MSGCNT     21
   NAME       Rhasspy
   NOTIFYDEV  global
   NR         1219
   NTFY_ORDER 50-Rhasspy
   STATE      online
   TYPE       RHASSPY
   autoTraining 60
   baseUrl    http://192.168.1.46:12101
   defaultRoom default
   devspec    genericDeviceType=.+
   encoding   utf8
   eventCount 24
   fhemId     fhem
   prefix     rhasspy
   rhasspyMQTT2_MSGCNT 21
   rhasspyMQTT2_TIME 2022-06-20 15:52:13
   siteId     defhem
   useGenericAttrs 1
   READINGS:
     2022-06-19 21:02:36   IODev           rhasspyMQTT2
     2022-06-19 21:02:36   enableMsgDialog 0
     2022-04-19 10:37:20   hotwordAwaiting_Pixel4a 1
     2022-06-19 22:13:28   intentNotRecognized [Pixel4a] nimm rollladen im meinem schlafzimmer ein
     2022-06-15 10:39:07   intents         de.fhem:ChoiceRoom,de.fhem:SetNumeric,de.fhem:ConfirmAction,de.fhem:SetOnOff,de.fhem:CancelAction,de.fhem:ChoiceDevice
     2022-06-20 15:52:13   lastIntentPayload {"Device":"rollladen westseite","Room":"wohnzimmer","Value":"10","confidence":1,"customData":null,"input":"fahre den rollladen westseite im wohnzimmer auf 10","intent":"SetNumeric","lang":null,"rawInput":"fahre den rollladen westseite im wohnzimmer auf lücke","requestType":"voice","sessionId":"51c5420f-59e3-6801-82d6-bfd73821adaf","siteId":"Pixel4a"}
     2022-06-20 15:52:13   lastIntentTopic hermes/intent/de.fhem_SetNumeric
     2021-11-20 14:23:28   listening_default 0
     2021-11-26 06:27:56   listening_master 0
     2021-11-26 06:49:16   listening_pixel4a 0
     2022-04-19 10:37:20   listening_wohnzimmer 0
     2022-06-20 15:52:13   responseType    voice
     2021-11-21 21:16:59   siteIds         Pixel4a
     2022-06-20 10:47:14   state           online
     2022-06-19 22:13:28   textResponse    Your input could not be assigned to one of the known intents!
     2022-06-20 10:47:14   training        Training completed in 7.47 second(s)
     2021-11-19 20:34:33   updateSentences Wrote 21 char(s) to ['/opt/rhasspy/profiles/de/intents/de.fhem.Shortcuts.ini']
     2022-06-20 10:47:07   updateSlots     OK
     2022-06-20 15:52:13   voiceResponse   zu diensten
   TIMER:
     Rhasspy_autoTraining:
       HASH       Rhasspy
       MODIFIER   autoTraining
       NAME       Rhasspy_autoTraining
     Rhasspy_null:
       HASH       Rhasspy
       MODIFIER   null
       NAME       Rhasspy_null
       enable     false
       toDisable:
         ConfirmAction
         CancelAction
         Choice
         ChoiceRoom
         ChoiceDevice
   helper:
     bm:
       CODE(0x55ba3a6df3d0):
         cnt        12
         dmx        -1000
         dtot       0
         dtotcnt    0
         mTS        20.06. 07:34:48
         max        0.183072090148926
         tot        0.186280727386475
         mAr:
           HASH(0x55ba3a7a96d0)
           ARRAY(0x55ba3dd95c40)
           HASH(0x55ba3baa3c10)
       CODE(0x55ba3a6e5160):
         cnt        3
         dmx        -1000
         dtot       0
         dtotcnt    0
         mTS        20.06. 21:01:32
         max        0.00129604339599609
         tot        0.0014193058013916
         mAr:
           HASH(0x55ba3a7a96d0)
           ARRAY(0x55ba404e3730)
           HASH(0x55ba3fe53820)
       CODE(0x55ba3aa414a8):
         cnt        73
         dmx        -1000
         dtot       0
         dtotcnt    0
         mTS        20.06. 10:46:11
         max        0.0201249122619629
         tot        0.677152395248413
         mAr:
           HASH(0x55ba3a7a96d0)
           HASH(0x55ba2d2feda8)
     devicemap:
       Channels:
       Colors:
       devices:
         Haustuer.Licht:
           alias      licht
           groups     switch
           names      licht
           rooms      haustür
           intents:
             GetOnOff:
               GetOnOff:
                 currentVal state
                 type       GetOnOff
                 valueOff   off
             SetOnOff:
               SetOnOff:
                 cmdOff     off
                 cmdOn      on
                 type       SetOnOff
         RollladenSchlafzimmerFelix:
           alias      rollladen
           groups     rollladen
           names      rollladen
           rooms      schlafzimmer felix,schlafzimmer von felix,zimmer felix,zimmer von felix
           intents:
             SetNumeric:
               setTarget:
                 cmd        pct
                 cmdStop    Stop
                 type       setTarget
             SetOnOff:
               SetOnOff:
                 cmdOff     DriveDown
                 cmdOn      DriveUp
                 type       SetOnOff
           numeric_ValueMap:
             10         Event Slit
         RollladenSchlafzimmerGisbert:
           alias      rollladen
           groups     rollladen
           names      rollladen
           rooms      schlafzimmer von gisbert,schlafzimmer gisbert,meinem schlafzimmer
           intents:
             SetNumeric:
               setTarget:
                 cmd        pct
                 cmdStop    Stop
                 type       setTarget
             SetOnOff:
               SetOnOff:
                 cmdOff     DriveDown
                 cmdOn      DriveUp
                 type       SetOnOff
           numeric_ValueMap:
             10         Event Slit
         RollladenWohnzimmerSued:
           alias      rollladen südseite
           groups     rollladen
           names      rollladen südseite
           rooms      wohnzimmer
           intents:
             SetNumeric:
               setTarget:
                 cmd        pct
                 cmdStop    Stop
                 type       setTarget
             SetOnOff:
               SetOnOff:
                 cmdOff     DriveDown
                 cmdOn      DriveUp
                 type       SetOnOff
           numeric_ValueMap:
             10         Event Slit
         RollladenWohnzimmerTerrasse:
           alias      rollladen terrasse
           groups     rollladen
           names      rollladen terrasse,rollladen terrassentür
           rooms      wohnzimmer
           intents:
             SetNumeric:
               setTarget:
                 cmd        pct
                 cmdStop    Stop
                 type       setTarget
             SetOnOff:
               SetOnOff:
                 cmdOff     DriveDown
                 cmdOn      DriveUp
                 type       SetOnOff
           numeric_ValueMap:
             10         Event Slit
         RollladenWohnzimmerWest:
           alias      rollladen westseite
           groups     rollladen
           names      rollladen westseite
           rooms      wohnzimmer
           intents:
             SetNumeric:
               setTarget:
                 cmd        pct
                 cmdStop    Stop
                 type       setTarget
             SetOnOff:
               SetOnOff:
                 cmdOff     DriveDown
                 cmdOn      DriveUp
                 type       SetOnOff
           numeric_ValueMap:
             10         Event Slit
         Wohnzimmer.Licht:
           alias      licht
           groups     switch
           names      licht
           rooms      wohnzimmer
           intents:
             GetOnOff:
               GetOnOff:
                 currentVal state
                 type       GetOnOff
                 valueOff   off
             SetOnOff:
               SetOnOff:
                 cmdOff     off
                 cmdOn      on
                 type       SetOnOff
       rhasspyRooms:
         haustür:
           licht      Haustuer.Licht
         meinem schlafzimmer:
           rollladen  RollladenSchlafzimmerGisbert
         schlafzimmer felix:
           rollladen  RollladenSchlafzimmerFelix
         schlafzimmer gisbert:
           rollladen  RollladenSchlafzimmerGisbert
         schlafzimmer von felix:
           rollladen  RollladenSchlafzimmerFelix
         schlafzimmer von gisbert:
           rollladen  RollladenSchlafzimmerGisbert
         wohnzimmer:
           licht      Wohnzimmer.Licht
           rollladen südseite RollladenWohnzimmerSued
           rollladen terrasse RollladenWohnzimmerTerrasse
           rollladen terrassentür RollladenWohnzimmerTerrasse
           rollladen westseite RollladenWohnzimmerWest
         zimmer felix:
           rollladen  RollladenSchlafzimmerFelix
         zimmer von felix:
           rollladen  RollladenSchlafzimmerFelix
     lng:
       commaconversion 1
       mutated_vowels:
         Ä         Ae
         Ö         Oe
         Ü         Ue
         ß         ss
         ä         ae
         ö         oe
         ü         ue
       responses:
         ContinueSession Something else? | Any more wishes?
         DefaultCancelConfirmation Habe abgebrochen
         DefaultChangeIntentRequestRawInput wechseln zu $rawInput
         DefaultChoiceNoOutstanding warte grade nicht auf eine Auswahl
         DefaultConfirmation Gerne!|wird erledigt|ok|jawohl|zu diensten
         DefaultConfirmationBack also nochmal
         DefaultConfirmationNoOutstanding warte grade nicht auf eine bestätigung
         DefaultConfirmationReceived Ok, werde ich machen
         DefaultConfirmationRequestRawInput bestätige $rawInput
         DefaultConfirmationTimeout Tut mir leid, da hat etwas zu lange gedauert
         DefaultError Da paßt irgend was nicht
         NoActiveMediaDevice Tut mir leid, es ist kein Wiedergabegerät aktiv
         NoDeviceFound Tut mir leid, ich konnte kein passendes Gerät finden
         NoIntentRecognized Your input could not be assigned to one of the known intents!
         NoMappingFound Tut mir leid, ich konnte kein passendes Mäpping finden
         NoMediaChannelFound Tut mir leid, der angefragte Kanal scheint nicht zu existieren.
         NoMinConfidence Minimum confidence not given, level is $confidence
         NoNewValDerived Tut mir leid, ich konnte den Zielwert nicht ausrechnen
         NoTimedOnDeviceFound Das gewählte Gerät unterstützt leider keine taimer Kommandos
         NoValidData ich habe leider zu wenig Daten um den Vorgang auszuführen
         NoValidIntentResponse Error. respond function called by $intent without valid response!
         NoValidResponse Error. respond function called without valid response!
         RequestChoiceDevice Es kommen mehrere Geräte in Frage, bitte wähle zwischen $first_items oder $last_item
         RequestChoiceGeneric There are several options, choose between $options.
         RequestChoiceRoom Es kommen mehrere Geräte in verschiedenen Räumen in Frage, wähle einen Raum von  $first_items oder $last_item
         SilentCancelConfirmation
         duration_not_understood Tut mir leid, ich habe die Dauer nicht verstanden
         reSpeak_failed Tut mir leid, ich kann mich nicht erinnern
         timeRequest Es ist $hour Uhr $min
         timerCancellation $label im $room gelöscht
         weekdayRequest Heute ist $weekDay
         Change:
           brightness $deviceName ist auf $value gestellt
           desired-temp Die Solltemperatur von $location beträgt $value Grad
           humidity   Die Luftfeuchtigkeit von $location beträgt $value Prozent
           knownType  $mappingType von $location beträgt $value Prozent
           setTarget  $device ist auf $value gesetzt
           soilMoisture Die Bodenfeuchte von $location beträgt $value Prozent
           unknownType Der Wert von $location beträgt $value Prozent
           volume     $deviceName ist auf $value gestellt
           waterLevel Der Wasserstand von $location beträgt $value Prozent
           battery:
             0          Der Batteriestand von $location ist $value
             1          Der Batteriestand von $location beträgt $value Prozent
           temperature:
             0          Die Temperatur von $location ist $value
             1          Die Temperatur von $location beträgt $value Grad
         ParadoxData:
           confirm    Switch $val[0] based on name and site id?
           hint       The received data is paradoxical: $val[0] and $val[1] do not fit together.
         XtendAnswers:
           unknownDevs $uknDevs could not be identified.
         getRHASSPYOptions:
           control    In $room amongst others the following entities can be controlled $deviceNames
           generic    Actions to devices may be initiated or information known by your automation can be requested
           info       Especially $deviceNames may serve as information source in $room
           rooms      Amongst others i know $roomNames as rooms
           scenes     $deviceNames in $room may be able to be set to $sceneNames
         getStateResponses:
           STATE      $deviceName hat den Status [$device:STATE]
           price      Der aktuelle Preis für $reading in $deviceName beträgt [$device:$reading:d] Euro
           reading    [$device:$reading]
           update     update für $deviceName ist angestoßen
         timerEnd:
           0          $label abgelaufen
           1          $label im raum $room abgelaufen
         timerSet:
           0          $label im Raum $room ist gestellt auf $seconds sekunden
           1          $label im Raum $room ist gestellt auf $minutetext $seconds
           2          $label im Raum $room ist gestellt auf $minutetext
           3          $label im Raum $room ist gestellt auf $hours stunden $minutetext
           4          $label im Raum $room ist gestellt auf $hours uhr $minutes
           5          $label im Raum $room ist gestellt auf morgen, $hours uhr $minutes
           6          $label in room $room is not existent
       stateResponses:
         inOperation:
           0          $deviceName ist fertig
           1          $deviceName läuft noch
         inOut:
           0          $deviceName ist ausgefahren
           1          $deviceName ist eingefahren
         onOff:
           0          $deviceName ist ausgeschaltet|$deviceName ist aus
           1          $deviceName ist eingeschaltet|$deviceName ist an
         openClose:
           0          $deviceName ist geöffnet|$deviceName ist offen
           1          $deviceName ist geschlossen|$deviceName ist zu
       units:
         unitHours:
           0          stunden
           1          eine stunde
         unitMinutes:
           0          minuten
           1          eine minute
         unitSeconds:
           0          Beispiel 1a: einige Sekunden
           1          Beispiel 1b: genau eine Sekunde
       words:
         and        und
         off        aus
         on         an
     shortcuts:
     tweaks:
Attributes:
   comment    Installation von Modulen.
in FHEM: { Svn_GetFile('contrib/RHASSPY/10_RHASSPY.pm', 'FHEM/10_RHASSPY.pm') }
in Linux: "wget https://svn.fhem.de/trac/export/HEAD/trunk/fhem/contrib/RHASSPY/10_RHASSPY.pm -O ./FHEM/10_RHASSPY.pm"
   languageFile ./rhasspy-de.cfg
   room       Rhasspy


Viele Grüße Gisbert
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 20 Juni 2022, 21:19:35
OK, da z.B.
NoMinConfidence Minimum confidence not given, level is $confidence
[...]
NoValidIntentResponse Error. respond function called by $intent without valid response!
NoValidResponse Error. respond function called without valid response!
There are several options, choose between $options.
auftaucht, ist die Sprachdatei nicht vollständig, siehe insbesondere die Änderungen in https://svn.fhem.de/trac/changeset/25937/ (https://svn.fhem.de/trac/changeset/25937/). Am einfachsten den "default"-Bereich rauskopieren und in deine aktuelle einfügen. Dann bleiben deine eigenen Angaben in "user" erhalten.

version RHASSPY ist 26144?

PS: ein "siteId2room_pixel4a"-Reading sehe ich auch nicht. Es würde dir das Leben vermutlich erleichtern, wenn du das mal austesten würdest - dann enfallen nämlich uU. auch diverse Rückfragen, weil für RHASSPY dann mehr "klar" ist, was du schalten willst. (Soll nicht heißen, dass das mit den Choices nicht auch funktionieren müßte bzw. ggf. repariert werden muss!)
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Gisbert am 20 Juni 2022, 22:04:27
Hallo Jörg,

Zitatversion RHASSPY ist 26144?
Nein, ich habe anscheinend eine ältere Version. Ich werde das updaten, dachte aber, dass Updates mittlerweile über das Fhem-Update reinkommen.

rhasspy-de.cfg, das hab ich:
#$Id: rhasspy-de.cfg 25354 2021-12-18 06:50:10Z Beta-User $

Es gibt diese Version im SVN vom 9.4.2022:
https://svn.fhem.de/trac/browser/trunk/fhem/contrib/RHASSPY/rhasspy-de.cfg?rev=25937 (https://svn.fhem.de/trac/browser/trunk/fhem/contrib/RHASSPY/rhasspy-de.cfg?rev=25937)
Soll ich diese runterladen und in meinem Fhem-Verzeichnis (/opt/fhem) speichern?

Viele Grüße Gisbert

PS: "siteId2room_pixel4a" - das ist mein Handy, das ja mit mir durchs Haus wandert, also nicht an einem Ort ist.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 20 Juni 2022, 22:16:15
Zitat von: Gisbert am 20 Juni 2022, 22:04:27
Nein, ich habe anscheinend eine ältere Version. Ich werde das updaten, dachte aber, dass Updates mittlerweile über das Fhem-Update reinkommen.
Kann sein, wenn es über die controls von drhirn läuft und das in github übernommen wurde. Werde mal bei Gelegenheit drüber nachdenken, ob das in den regulären svn-Zweig kann/soll.

Zitat
rhasspy-de.cfg, das hab ich:
[...]
Soll ich diese runterladen und in meinem Fhem-Verzeichnis (/opt/fhem) speichern?
Die wird in jedem Fall auch künftig nicht einfach überschrieben, weil das aus diversen Gründen als "Einheitsfile" konfiguriert ist. Prinzipiell geht es auch, die komplette Datei zu übernehmen, dann sind halt ggf. in "user" gemachte eigene Einstellungen auch weg.

Zitat
PS: "siteId2room_pixel4a" - das ist mein Handy, das ja mit mir durchs Haus wandert, also nicht an einem Ort ist.
Das ist mir schon klar - mache ich ja genauso, weise aber dann das Handy einem Raum zu, wenn ich da länger bin. Den Raum extra dazusagen geht ja trotzdem, wenn man mal eben kurz woanders ist und nicht für die nähere Zukunft alle Befehle woanders ausführen will...
Deswegen ist das ja via Reading gelöst (und nicht per Attribut): Man kann es jederzeit ändern (am einfachsten immer noch über die bereits mehrfach erwähnte myUtils...)
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Gisbert am 20 Juni 2022, 22:44:21
Die neue Rhasspy-Version und aktuelle rhasspy-de.cfg laufen schon viel geschmeidiger; zumindest kommen jetzt verständliche Worte als Antwort, wenn auch der Sinn zuweilen holprig ist.
Die aktuelle rhasspy-de.cfg und meine Datei vom 2022-01-06 sind im user-Bereich nahezu identisch, default ist exakt identisch, die meisten Änderungen gibt es im Bereich "responses".

Viele Grüße Gisbert
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 21 Juni 2022, 10:31:08
Zitat von: Gisbert am 20 Juni 2022, 22:44:21
Die neue Rhasspy-Version und aktuelle rhasspy-de.cfg laufen schon viel geschmeidiger; zumindest kommen jetzt verständliche Worte als Antwort, wenn auch der Sinn zuweilen holprig ist.
Das klingt doch schon mal gut, Vorschläge für bessere/verständlichere "default"-Sätze sind gerne gesehen, ich habe den Schwerpunkt in der Regel erst mal auf der Funktionalität, da fällt das schon gerne mal "hinten runter".

An sich sollten die jeweils relevanten Änderungen in der Kurzfassung auch im "offene Themen"-Thread zu finden sein, konkret würde ich empfehlen, das "Choice"-Thema aus https://forum.fhem.de/index.php/topic,124952.msg1222260.html#msg1222260 mal näher anzusehen (da sind Änderungen an der sentences.ini empfohlen).

Zitat
Die aktuelle rhasspy-de.cfg und meine Datei vom 2022-01-06 sind im user-Bereich nahezu identisch, default ist exakt identisch, die meisten Änderungen gibt es im Bereich "responses".
Na ja, wie auch immer es im Detail sein mag, ich wollte nur anmerken, dass du eben die von dir gemachten Änderungen ggf. verlierst, wenn du die Datei komplett übernimmst. That's all...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Gisbert am 14 Juli 2022, 19:11:35
Hallo Jörg,

mit deiner Hilfe konnte ich das Modul zum Laufen bringen. Ich hab an irgendeiner Stelle der Installation, glaube ich, eine relativ synthetische Stimme gewählt, die mir in der Android-App Antwort gibt. Ich wünsche mir mittlerweile dort eine persönlichere Ansprache, weiß aber nicht, wie ich das anstellen könnte, falls es möglich ist.

Viele​ Grüße​ Gisbert​
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 15 Juli 2022, 08:42:14
Die Stimme kannst du in den Einstellungen von Rhasspy unter "Text to Speech" ändern: https://rhasspy.readthedocs.io/en/latest/text-to-speech/

Die Antworten, die Rhasspy zurück gibt, sind in der rhasspy-de.cfg zu finden. Die musst nur einfach nur editieren und danach in FHEM ein set <rhasspy-device> update language ausführen. In der rhasspy-de.cfg änderst du am besten im Abschnitt "user" (ca. Zeile 145). Da kannst du gewünschten Zeilen aus dem Abschnitt "default" einfach hin kopieren und dann entsprechend ändern.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 15 Juli 2022, 11:17:40
Ergänzende Anmerkungen:

1. Es gibt zum Thema "Stimmen" bessere Helfer wie mich, und das ganze gehört eigentlich nicht in diesen Thread :) .
2. Was ggf. (am Rande) in diesen Thread gehören würde: über den AMAD-Weg kann man (indirekt) auch Google für STT und TTS verwenden. Diese Stimme(n?) klingt/klingen auch ganz ok, und über das etwas "freiere" Text-Matching zu dem, was Rhasspy kennt, ergeben sich auch neue Aspekte (die bisher hier nicht/nur von mir (an-)diskutiert wurden). Interessantes Feld, aber eigentlich - zumindest in den Basics - einen eigenen Thread wert...
3. Ich experimentiere grade auch mit "thorsten_low" als alternativer Stimme aus Mimic 3 (drop in via maryTTS-Einstellung in Rhasspy) rum. Klingt ganz ok, wirft aber auch ein paar Fragen auf, die ggf. auch gesondert zu diskutieren wären.
Weiß aber nicht, ob der ThinClient dafür ausreicht, die preview-Version hatte meinen T620 (2 Kerne-AMD-CPU) ziemlich ausgelastet. Das wäre aber ggf. einen Versuch wert (läuft auch offline).

Da das ggf. auch für andere TTS-Varianten (Text2Speech-Modul, derzeit nur in der gepatchten Version) interessant ist, wäre das m.E. auch in einem eigenen Thread besser aufgehoben. Die eigentliche Einrichtung in Rhasspy ist trivial (wenn es mal läuft, was aber auch kein Hexenwerk ist).
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 15 Juli 2022, 12:54:57
Zitat von: Beta-User am 15 Juli 2022, 11:17:40
2. Was ggf. (am Rande) in diesen Thread gehören würde: über den AMAD-Weg kann man (indirekt) auch Google für STT und TTS verwenden.

Für TTS geht das mit Rhasspy eh auch. Google Wavenet. Ist bei mir im Einsatz.

Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 15 Juli 2022, 13:10:24
Zitat von: drhirn am 15 Juli 2022, 12:54:57
Für TTS geht das mit Rhasspy eh auch. Google Wavenet. Ist bei mir im Einsatz.
Danke für den Hinweis.

Tatsächlich habe ich bisher keine großen Experimente mit unterschiedlichen Stimmen gemacht, u.a. schon deswegen, weil es entweder zusätzlichen Installationsaufwand bedeutet hätte, oder (wie bei Wavenet) dann eben nicht mehr rein lokal läuft.

Für Mimic 3 hatte ich jetzt den Zusatz-Aufwand mal getrieben, v.a., weil mich "thorsten" als rein lokale "natürliche" Lösung interessiert hat. Ist verbesserungsfähig, aber weil ich (open source-) offline-Lösungen gut finde, werde ich wohl einen gewissen Aufwand drumrum treiben, "Wavenet" solo kommt für mich dagegen nicht in Frage.

Die AMAD-Lösung nutzt das zwar auch, aber für mich ist es "nur" eine Backup-Lösung, die zusätzlich zu der reinen offline-Lösung funktioniert und von der ich noch nicht so recht weiß, ob die auch für andere Mitbewohner in Frage kommt... "Blöd" ist, dass ich es bisher nicht "geschafft" habe, ein Icon für den Shortcut anzeigen zu lassen (das Ding ist einfach ein durchsichtiger Bereich, und bisher war mein Drang recht begrenzt, das intensiver zu erforschen, woran das liegt...).
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Gisbert am 15 Juli 2022, 16:50:42
Google Wavenet (und andere) scheinen bei mir nicht zu funktionieren.
Ich hab natürlich die Settings gespeichert, in Fhem sicherheitshalber auch set Rhasspy update all durchgeführt, aber die Fhem-App bleibt stumm, wobei allerdings der Befehl an sich schon ausgeführt wird.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Raemsna am 25 August 2022, 14:25:10
Hallo in die Runde,

ich habe gerade meine FHEM inkl. des Rhasspy Moduls geupdatet und habe festgestellt, dass eine bisher gut laufende Funktion nicht mehr funktioniert.

aktuelle Version:
10_RHASSPY.pm                26102 2022-05-31 14:22:24Z Beta-User

davor (laufende Version):
10_RHASSPY.pm                25948 2022-04-12 05:30:56Z Beta-User

Rhasspy list:
Internals:
   CONFIGFILE /opt/fhem/FHEM/rhasspy-de.cfg
   DEF        MQTT2Client_Rhasspy baseUrl=http://192.168.0.248:12101 devspec=room=Rhasspy language=de defaultRoom=Wohnzimmer
   FUUID      626f84cf-f33f-242d-acdf-54e82315630dc5e1
   IODev      MQTT2Client_Rhasspy
   LANGUAGE   de
   LASTInputDev MQTT2Client_Rhasspy
   MQTT2Client_Rhasspy_MSGCNT 14
   MQTT2Client_Rhasspy_TIME 2022-08-25 14:17:36
   MSGCNT     14
   NAME       Rhasspy
   NOTIFYDEV  global
   NR         664
   NTFY_ORDER 50-Rhasspy
   STATE      online
   TYPE       RHASSPY
   autoTraining 60
   baseUrl    http://192.168.0.248:12101
   defaultRoom Wohnzimmer
   devspec    room=Rhasspy
   encoding   utf8
   eventCount 28
   fhemId     fhem
   prefix     rhasspy
   siteId     defhem
   useGenericAttrs 1
   READINGS:
     2022-08-22 11:32:22   IODev           MQTT2Client_Rhasspy
     2022-08-22 11:32:22   enableMsgDialog 0
     2022-08-25 14:14:04   intents         de.fhem:AddTask,de.fhem:GetTime,GetTime,de.fhem:MediaChannels,de.fhem:ConfirmAction,de.fhem:SetTimedOnOff,de.fhem:GetNumeric,de.fhem:SetOnOff,GetTemperature,de.fhem:SetTimer,GetGarageState,ChangeLightState
     2022-08-25 14:17:36   lastIntentPayload {"Channel":"erstellen","Device":"termin","Hourabs":14,"Min":30,"confidence":1,"customData":null,"day":5,"input":"termin erstellen am 5 September um 14 Uhr 30","intent":"MediaChannels","lang":null,"month":"September","rawInput":"termin erstellen am fünf september um vierzehn uhr dreißig","requestType":"voice","sessionId":"9d1c16e0-0c6c-86ab-caf2-3575b4f73044","siteId":"mobile-app0"}
     2022-08-25 14:17:36   lastIntentTopic hermes/intent/de.fhem_MediaChannels
     2022-08-22 08:45:19   listening_Wohnzimmer 0
     2022-08-25 14:17:36   responseType    voice
     2022-05-02 09:14:25   siteIds         default,mobile-app0,mobile-app1,mobile-app2
     2022-08-25 14:14:22   state           online
     2022-08-25 14:14:22   training        Training completed in 17.66 second(s)
     2022-08-25 14:14:04   updateSlots     OK
     2022-08-25 14:17:36   voiceResponse   Tut mir leid, der angefragte Kanal scheint nicht zu existieren.
   TIMER:
     Rhasspy_null:
       HASH       Rhasspy
       MODIFIER   null
       NAME       Rhasspy_null
       enable     false
       toDisable:
         ConfirmAction
         CancelAction
         Choice
         ChoiceRoom
         ChoiceDevice
   helper:
     devicemap:
       Channels:
         Wohnzimmer:
           erstellen:
             dummy_Rhasspy_Kalendereintrag
         wohnzimmer:
           aus:
             LS_Wohnzimmer
           indirekt:
             LS_Wohnzimmer
       Colors:
       devices:
         Garten_Schupfasteckdose:
           alias      brunnen
           names      brunnen
           rooms      garten
           intents:
             SetOnOff:
               SetOnOff:
                 cmdOff     off
                 cmdOn      on
                 type       SetOnOff
         Garten_Wasserpumpe:
           intents:
         LS_Wohnzimmer:
           alias      licht
           groups     licht
           names      licht
           rooms      wohnzimmer
           Channels:
             aus        set LS_Wohnzimmer scene aus
             indirekt   set LS_Wohnzimmer scene indirekt
           intents:
         MQTT2Client_Rhasspy:
           intents:
         OG_Licht_BadDeckenlicht:
           alias      licht
           names      licht
           rooms      bad
           intents:
             SetOnOff:
               SetOnOff:
                 cmdOff     off
                 cmdOn      on
                 type       SetOnOff
         OG_Licht_DeckeAnnelie:
           alias      licht
           names      licht
           rooms      spielzimmer
           intents:
             SetOnOff:
               SetOnOff:
                 cmdOff     off
                 cmdOn      on
                 type       SetOnOff
         OG_Licht_DeckeBuero:
           alias      licht
           names      licht
           rooms      büro
           intents:
             SetOnOff:
               SetOnOff:
                 cmdOff     off
                 cmdOn      on
                 type       SetOnOff
         OG_Licht_DeckeFlur:
           alias      licht
           names      licht
           rooms      flur
           intents:
             SetOnOff:
               SetOnOff:
                 cmdOff     off
                 cmdOn      on
                 type       SetOnOff
         OG_Licht_DeckeKindII:
           alias      licht
           names      licht
           rooms      kinderzimmer
           intents:
             SetOnOff:
               SetOnOff:
                 cmdOff     off
                 cmdOn      on
                 type       SetOnOff
         OG_Licht_DeckeSchlafzimmer:
           alias      licht
           names      licht
           rooms      schlafzimmer
           intents:
             SetOnOff:
               SetOnOff:
                 cmdOff     off
                 cmdOn      on
                 type       SetOnOff
         OG_Licht_Speicher:
           alias      licht
           names      licht
           rooms      speicher
           intents:
             SetOnOff:
               SetOnOff:
                 cmdOff     off
                 cmdOn      on
                 type       SetOnOff
         Relaiskarte_SteckdosenGarten:
           alias      steckdosen
           names      steckdosen
           rooms      garten
           intents:
             SetOnOff:
               SetOnOff:
                 cmdOff     off
                 cmdOn      on
                 type       SetOnOff
         Rhasspy:
           alias      rhasspy
           names      rhasspy
           rooms      wohnzimmer
           intents:
         SonoffS20_3:
           alias      musik
           names      musik
           rooms      büro
           intents:
             SetOnOff:
               SetOnOff:
                 cmdOff     OFF
                 cmdOn      ON
                 type       SetOnOff
         Sonoff_OG_Buero_Echo:
           alias      musik
           names      musik
           rooms      büro
           intents:
             SetOnOff:
               SetOnOff:
                 cmdOff     off
                 cmdOn      on
                 type       SetOnOff
         Structure_EG_Licht:
           alias      licht
           names      licht
           rooms      erdgeschoss
           intents:
             SetOnOff:
               SetOnOff:
                 cmdOff     off
                 cmdOn      on
                 type       SetOnOff
         Structure_Haus:
           alias      licht
           names      licht
           rooms      haus
           intents:
             SetOnOff:
               SetOnOff:
                 cmdOff     off
                 cmdOn      on
                 type       SetOnOff
         dummy_Rhasspy_Kalendereintrag:
           alias      termin
           names      termin
           rooms      Wohnzimmer
           Channels:
             erstellen  {Rhasspy_Kalendereintrag_decodePayload ("getText","none")}
           intents:
       rhasspyRooms:
         Wohnzimmer:
           termin     dummy_Rhasspy_Kalendereintrag
         bad:
           licht      OG_Licht_BadDeckenlicht
         büro:
           licht      OG_Licht_DeckeBuero
           musik      Sonoff_OG_Buero_Echo
         erdgeschoss:
           licht      Structure_EG_Licht
         flur:
           licht      OG_Licht_DeckeFlur
         garten:
           brunnen    Garten_Schupfasteckdose
           steckdosen Relaiskarte_SteckdosenGarten
         haus:
           licht      Structure_Haus
         kinderzimmer:
           licht      OG_Licht_DeckeKindII
         schlafzimmer:
           licht      OG_Licht_DeckeSchlafzimmer
         speicher:
           licht      OG_Licht_Speicher
         spielzimmer:
           licht      OG_Licht_DeckeAnnelie
         wohnzimmer:
           licht      LS_Wohnzimmer
           rhasspy    Rhasspy
     lng:
       commaconversion 1
       mutated_vowels:
         Ä         Ae
         Ö         Oe
         Ü         Ue
         ß         ss
         ä         ae
         ö         oe
         ü         ue
       responses:
         ContinueSession Sonst noch was? | Weitere Wünsche?
         DefaultCancelConfirmation Habe abgebrochen
         DefaultChangeIntentRequestRawInput Wechseln zu $rawInput
         DefaultChoiceNoOutstanding Warte grade nicht auf eine Auswahl
         DefaultConfirmation Gerne!|Wird erledigt|Ok|Jawohl|Zu Diensten
         DefaultConfirmationBack Also nochmal
         DefaultConfirmationNoOutstanding 'Warte grade nicht auf eine Bestätigung
         DefaultConfirmationReceived Ok, werde ich machen
         DefaultConfirmationRequestRawInput Bestätige $rawInput
         DefaultConfirmationTimeout Tut mir leid, da hat etwas zu lange gedauert
         DefaultError Da paßt irgend was nicht
         NoActiveMediaDevice Tut mir leid, es ist kein Wiedergabegerät aktiv
         NoDeviceFound Tut mir leid, ich konnte kein passendes Gerät finden
         NoIntentRecognized Ich konnte leider keinen passenden Intent finden
         NoMappingFound Tut mir leid, ich konnte kein passendes Mäpping finden
         NoMediaChannelFound Tut mir leid, der angefragte Kanal scheint nicht zu existieren.
         NoMinConfidence Deine Angaben waren mit rechnerischen $confidence nicht ausreichend, um eine Aktion auszulösen!
         NoNewValDerived Tut mir leid, ich konnte den Zielwert nicht ausrechnen
         NoTimedOnDeviceFound Das gewählte Gerät unterstützt leider keine taimer Kommandos
         NoValidData Ich habe leider zu wenig Daten um den Vorgang auszuführen
         NoValidIntentResponse Fehler. Die respond Funktion wurde von $intent ohne Antworttext aufgerufen
         NoValidResponse Fehler. Die respond Funktion wurde ohne Antworttext aufgerufen
         RequestChoiceDevice Es kommen mehrere Geräte in Frage, bitte wähle zwischen $first_items oder $last_item
         RequestChoiceGeneric Es gibt diese Möglichkeiten, unter denen du wählen kannst: $options
         RequestChoiceRoom Es kommen mehrere Geräte in verschiedenen Räumen in Frage, wähle zwischen $first_items oder $last_item
         SilentCancelConfirmation
         duration_not_understood Tut mir leid, ich habe die Dauer nicht verstanden
         reSpeak_failed Tut mir leid, ich kann mich nicht erinnern
         timeRequest Es ist $hour Uhr $min
         timerCancellation $label im $room gelöscht
         weekdayRequest Heute ist $weekDay
         Change:
           brightness $deviceName ist auf $value gestellt
           desired-temp Die Solltemperatur von $location beträgt $value Grad
           humidity   Die Luftfeuchtigkeit von $location beträgt $value Prozent
           knownType  $mappingType von $location beträgt $value Prozent
           setTarget  $device ist auf $value gesetzt
           soilMoisture Die Bodenfeuchte von $location beträgt $value Prozent
           unknownType Der Wert vom $location beträgt $value Prozent
           volume     $deviceName ist auf $value gestellt
           waterLevel Der Wasserstand von $location beträgt $value Prozent
           battery:
             0          Der Batteriestand von $location ist $value
             1          Der Batteriestand von $location beträgt $value Prozent
           temperature:
             0          Die Temperatur vom $location ist $value
             1          Die Temperatur vom $location beträgt $value Grad
         ParadoxData:
           confirm    Soll $val[0] mit dem Namen und dem besprochenen Gerät ermittelt werden?
           hint       Du hast widersprüchliche Angaben gemacht: $val[0] und $val[1] passen nicht zusammen.
         XtendAnswers:
           unknownDevs $uknDevs konnten nicht ermittelt werden
         getRHASSPYOptions:
           control    Im $room kann ich unter anderen diese Geräte steuern: $deviceNames
           generic    Es können einige Geräte gesteuert werden oder Informationen aus der Haussteuerung abgefragt werden
           info       Insbesondere $deviceNames stehen als Informationsquellen im $room zur Verfügung
           rooms      Unter anderem kenne ich die Räume $roomNames
           scenes     $deviceNames in $room kann auf die Szenen $sceneNames gestellt werden
         getStateResponses:
           STATE      $deviceName hat den Status [$device:STATE]
           price      Der aktuelle Preis für $reading in $deviceName beträgt [$device:$reading:d] Euro
           reading    [$device:$reading]
           update     Update für $deviceName ist angestoßen
         timerEnd:
           0          $label abgelaufen
           1          $label im Raum $room abgelaufen
         timerSet:
           0          $label im Raum $room ist gestellt auf $seconds Sekunden
           1          $label im Raum $room ist gestellt auf $minutetext $seconds
           2          $label im Raum $room ist gestellt auf $minutetext
           3          $label im Raum $room ist gestellt auf $hours Stunden $minutetext
           4          $label im Raum $room ist gestellt auf $hours Uhr $minutes
           5          $label im Raum $room ist gestellt auf morgen, $hours Uhr $minutes
           6          kein $label im Raum $room gestellt
       stateResponses:
         inOperation:
           0          $deviceName ist fertig
           1          $deviceName läuft noch
         inOut:
           0          $deviceName ist ausgefahren
           1          $deviceName ist eingefahren
         onOff:
           0          $deviceName ist ausgeschaltet|$deviceName ist aus
           1          $deviceName ist eingeschaltet|$deviceName ist an
         openClose:
           0          $deviceName ist geöffnet|$deviceName ist offen
           1          $deviceName ist geschlossen|$deviceName ist zu
       units:
         unitHours:
           0          stunden
           1          eine stunde
         unitMinutes:
           0          minuten
           1          eine minute
         unitSeconds:
           0          Beispiel 1a: einige Sekunden
           1          Beispiel 1b: genau eine Sekunde
       words:
         and        und
         off        aus
         on         an
     shortcuts:
     tweaks:
Attributes:
   DbLogExclude .*
   IODev      MQTT2Client_Rhasspy
   languageFile /opt/fhem/FHEM/rhasspy-de.cfg
   rhasspyRoom Wohnzimmer
   room       Rhasspy
   verbose    5


Systematik:
Über Rhasspy wird auf ein Device "dummy_Rhasspy_Kalendereintrag" zugegriffen, dass über einen MediaChannel eine Sub auslöst und mir einen Termin im Kalender erstellt

list dummy_Rhasspy_Kalendereintrag:
Internals:
   FUUID      626507d3-f33f-242d-a1ce-3a6cc2d5d7a98425
   LASTInputDev MQTT2Client_Rhasspy
   MQTT2Client_Rhasspy_MSGCNT 1
   MQTT2Client_Rhasspy_TIME 2022-08-24 09:08:31
   MSGCNT     1
   NAME       dummy_Rhasspy_Kalendereintrag
   NR         661
   STATE      ???
   TYPE       dummy
Attributes:
   DbLogExclude .*
   rhasspyChannels erstellen={Rhasspy_Kalendereintrag_decodePayload ("getText","none")}
   rhasspyName termin
   room       Rhasspy
   userattr   rhasspyChannels:textField-long
   verbose    3


Problem (siehe verbose 5 FHEM log):
Es scheint als würde das Device nicht richtig gefunden und damit auch der angelegte MediaChannel obwohl dieser angelegt ist und zuletzt funktioniert hat:
2022.08.25 14:17:36 5: RHASSPY: [Rhasspy] Parse (IO: MQTT2Client_Rhasspy): Msg: hermes/intent/de.fhem_MediaChannels => {"input": "termin erstellen am 5 September um 14 Uhr 30", "intent": {"intentName": "de.fhem:MediaChannels", "confidenceScore": 1.0}, "siteId": "mobile-app0", "id": null, "slots": [{"entity": "de.fhem.Device", "value": {"kind": "Unknown", "value": "termin"}, "slotName": "Device", "rawValue": "termin", "confidence": 1.0, "range": {"start": 0, "end": 6, "rawStart": 0, "rawEnd": 6}}, {"entity": "de.fhem.MediaChannels", "value": {"kind": "Unknown", "value": "erstellen"}, "slotName": "Channel", "rawValue": "erstellen", "confidence": 1.0, "range": {"start": 7, "end": 16, "rawStart": 7, "rawEnd": 16}}, {"entity": "rhasspy/number", "value": {"kind": "Number", "value": 5}, "slotName": "day", "rawValue": "fünf", "confidence": 1.0, "range": {"start": 20, "end": 21, "rawStart": 20, "rawEnd": 24}}, {"entity": "Monat", "value": {"kind": "Unknown", "value": "September"}, "slotName": "month", "rawValue": "september", "confidence": 1.0, "range": {"start": 22, "end": 31, "rawStart": 25, "rawEnd": 34}}, {"entity": "rhasspy/number", "value": {"kind": "Number", "value": 14}, "slotName": "Hourabs", "rawValue": "vierzehn", "confidence": 1.0, "range": {"start": 35, "end": 37, "rawStart": 38, "rawEnd": 46}}, {"entity": "rhasspy/number", "value": {"kind": "Number", "value": 30}, "slotName": "Min", "rawValue": "dreißig", "confidence": 1.0, "range": {"start": 42, "end": 44, "rawStart": 51, "rawEnd": 58}}], "sessionId": "9d1c16e0-0c6c-86ab-caf2-3575b4f73044", "customData": null, "asrTokens": [[{"value": "termin", "confidence": 1.0, "rangeStart": 0, "rangeEnd": 6, "time": null}, {"value": "erstellen", "confidence": 1.0, "rangeStart": 7, "rangeEnd": 16, "time": null}, {"value": "am", "confidence": 1.0, "rangeStart": 17, "rangeEnd": 19, "time": null}, {"value": "5", "confidence": 1.0, "rangeStart": 20, "rangeEnd": 21, "time": null}, {"value": "September", "confidence": 1.0, "rangeStart": 22, "rangeEnd": 31, "time": null}, {"value": "um", "confidence": 1.0, "rangeStart": 32, "rangeEnd": 34, "time": null}, {"value": "14", "confidence": 1.0, "rangeStart": 35, "rangeEnd": 37, "time": null}, {"value": "Uhr", "confidence": 1.0, "rangeStart": 38, "rangeEnd": 41, "time": null}, {"value": "30", "confidence": 1.0, "rangeStart": 42, "rangeEnd": 44, "time": null}]], "asrConfidence": null, "rawInput": "termin erstellen am fünf september um vierzehn uhr dreißig", "wakewordId": null, "lang": null}
2022.08.25 14:17:36 5: Parsed value: termin for key: Device
2022.08.25 14:17:36 5: Parsed value: 14 for key: Hourabs
2022.08.25 14:17:36 5: Parsed value: 1 for key: confidence
2022.08.25 14:17:36 5: Parsed value: termin erstellen am fünf september um vierzehn uhr dreißig for key: rawInput
2022.08.25 14:17:36 5: Parsed value: MediaChannels for key: intent
2022.08.25 14:17:36 5: Parsed value: 9d1c16e0-0c6c-86ab-caf2-3575b4f73044 for key: sessionId
2022.08.25 14:17:36 5: Parsed value: erstellen for key: Channel
2022.08.25 14:17:36 5: Parsed value: 5 for key: day
2022.08.25 14:17:36 5: Parsed value: September for key: month
2022.08.25 14:17:36 5: Parsed value: mobile-app0 for key: siteId
2022.08.25 14:17:36 5: Parsed value: 30 for key: Min
2022.08.25 14:17:36 5: Parsed value: termin erstellen am 5 September um 14 Uhr 30 for key: input
2022.08.25 14:17:36 5: handleIntentMediaChannels called
2022.08.25 14:17:36 5: room is identified using siteId as mobile-app0
2022.08.25 14:17:36 5: Device selected (by hash, using only name): dummy_Rhasspy_Kalendereintrag
2022.08.25 14:17:36 5: No device for >>termin<< found, especially not in room >>mobile-app0<< (also not outside)!
2022.08.25 14:17:36 5: Response is: Tut mir leid, der angefragte Kanal scheint nicht zu existieren.
2022.08.25 14:17:36 5: published hermes/dialogueManager/endSession {"intentFilter": null,"sessionId": "9d1c16e0-0c6c-86ab-caf2-3575b4f73044","siteId": "mobile-app0","text": "Tut mir leid, der angefragte Kanal scheint nicht zu existieren."}
2022.08.25 14:17:36 4: [Rhasspy] dispatch result is Rhasspy


Danke für Eure Hilfe! :)
Raemsna
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 25 August 2022, 20:50:34
@Raemsna

offensichtlich wird vorausgesetzt, dass dummy_Rhasspy_Kalendereintrag (rhasspyName termin) einem rhasspyRaum zugeordnet sein muss. Vorzugsweise "mobile-app0".
attr dummy_Rhasspy_Kalendereintrag rhasspyRoom mobile-app0
Generell sollte jedes Device einem rhasspyRoom zugeordnet sein.

Gruß Jens
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Raemsna am 26 August 2022, 09:29:28
@JensS: Danke für deine schnelle Antwort:
Dann musste das in meiner zuletzt installierten Rhasspy Version aber nicht der Fall sein (da funktioniert noch alles).

10_RHASSPY.pm                25948 2022-04-12 05:30:56Z Beta-User

Plus: mobile-app0 ist ja "nur" ein mobiles Gerät, das den Befehl ausführt (ich habe mehrere Geräte im Einsatz mobile-app1, ....).
Würde für mich inhaltlich keinen Sinn machen, ein zu steuerndes Gerät *einem* mobilen Endgerät zuzuordnen.
(ich möchte ja mit allen Geräten Termine erstellen können)...

Grüße
Raemsna

Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 26 August 2022, 13:21:26
Muss ich mit ansehen, sollte eigentlich gehen. Wird aber ein paar Tage dauern.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 01 September 2022, 19:43:03
Zitat von: Beta-User am 26 August 2022, 13:21:26
Muss ich mit ansehen, sollte eigentlich gehen. Wird aber ein paar Tage dauern.
So, es ist ein update im svn, das dieses Thema hoffentlich löst (ich nutze keine Channels und wollte mir nicht unbedingt extra was einrichten, daher bitte testen und rückmelden).

Das Problem hing damit zusammen:
Zitat von: Beta-User am 20 Mai 2022, 12:21:16
hier schon mal das "changelog":

1. Identifikation von Devices
Die Funktion ist jetzt überarbeitet und sollte nur noch Devices berücksichtigen, die "das angefragte" auch umsetzen können.

Anders herum gab es  Restriktionen bei "isValidData()", das noch nicht mitbekommen hatte, dass die Device-Ermittlung hinreichend genau sein sollte, dass mit weniger Daten entweder ein Device ermittelt werden kann oder eine Rückfrage erfolgen könnte...
Leider habe ich dabei übersehen, dass es ja noch diese "alten" Methoden Channels und Colors gibt, und für diese "Sonderlocken" hatte dann der Code an der falschen Stelle nachgesehen.

Zu dem Vorschlag betr. room noch: Das hätte das Problem auf andere Weise umschifft, und für solche "mobilen" Devices bin ich immer noch der Ansicht, dass eine siteId2room-Hilfsfunktion (wie z.B. im Wiki beschrieben) die Bedienung deutlich vereinfachen kann - bitte aber erst mal ohne testen, sonst wird der hier relevante Code-Teil nicht genutzt ;D .
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Raemsna am 02 September 2022, 12:35:13
Scheint immer noch nicht zu funktionieren.

Version:
Downloading https://raw.githubusercontent.com/fhem/fhem-rhasspy/main/controls_fhem-rhasspy.txt

fhem-rhasspy
nothing to do...

10_RHASSPY.pm 26102 2022-05-31 14:22:24Z Beta-User


Verbose 5:
2022.09.02 12:32:55 1: Logfile gelöscht
2022.09.02 12:33:00 5: RHASSPY: [Rhasspy] Parse (IO: MQTT2Client_Rhasspy): Msg: hermes/intent/de.fhem_MediaChannels => {"input": "termin erstellen Morgen um 8 Uhr", "intent": {"intentName": "de.fhem:MediaChannels", "confidenceScore": 1.0}, "siteId": "mobile-app0", "id": null, "slots": [{"entity": "de.fhem.Device", "value": {"kind": "Unknown", "value": "termin"}, "slotName": "Device", "rawValue": "termin", "confidence": 1.0, "range": {"start": 0, "end": 6, "rawStart": 0, "rawEnd": 6}}, {"entity": "de.fhem.MediaChannels", "value": {"kind": "Unknown", "value": "erstellen"}, "slotName": "Channel", "rawValue": "erstellen", "confidence": 1.0, "range": {"start": 7, "end": 16, "rawStart": 7, "rawEnd": 16}}, {"entity": "Wochentag", "value": {"kind": "Unknown", "value": "Morgen"}, "slotName": "day", "rawValue": "morgen", "confidence": 1.0, "range": {"start": 17, "end": 23, "rawStart": 17, "rawEnd": 23}}, {"entity": "rhasspy/number", "value": {"kind": "Number", "value": 8}, "slotName": "Hourabs", "rawValue": "acht", "confidence": 1.0, "range": {"start": 27, "end": 28, "rawStart": 27, "rawEnd": 31}}], "sessionId": "520c578d-945b-7503-c8bc-541862cc1c45", "customData": null, "asrTokens": [[{"value": "termin", "confidence": 1.0, "rangeStart": 0, "rangeEnd": 6, "time": null}, {"value": "erstellen", "confidence": 1.0, "rangeStart": 7, "rangeEnd": 16, "time": null}, {"value": "Morgen", "confidence": 1.0, "rangeStart": 17, "rangeEnd": 23, "time": null}, {"value": "um", "confidence": 1.0, "rangeStart": 24, "rangeEnd": 26, "time": null}, {"value": "8", "confidence": 1.0, "rangeStart": 27, "rangeEnd": 28, "time": null}, {"value": "Uhr", "confidence": 1.0, "rangeStart": 29, "rangeEnd": 32, "time": null}]], "asrConfidence": null, "rawInput": "termin erstellen morgen um acht uhr", "wakewordId": null, "lang": null}
2022.09.02 12:33:00 5: Parsed value: termin erstellen Morgen um 8 Uhr for key: input
2022.09.02 12:33:00 5: Parsed value: 8 for key: Hourabs
2022.09.02 12:33:00 5: Parsed value: MediaChannels for key: intent
2022.09.02 12:33:00 5: Parsed value: erstellen for key: Channel
2022.09.02 12:33:00 5: Parsed value: 520c578d-945b-7503-c8bc-541862cc1c45 for key: sessionId
2022.09.02 12:33:00 5: Parsed value: termin erstellen morgen um acht uhr for key: rawInput
2022.09.02 12:33:00 5: Parsed value: Morgen for key: day
2022.09.02 12:33:00 5: Parsed value: mobile-app0 for key: siteId
2022.09.02 12:33:00 5: Parsed value: 1 for key: confidence
2022.09.02 12:33:00 5: Parsed value: termin for key: Device
2022.09.02 12:33:00 5: handleIntentMediaChannels called
2022.09.02 12:33:00 5: room is identified using siteId as mobile-app0
2022.09.02 12:33:00 5: Device selected (by hash, using only name): dummy_Rhasspy_Kalendereintrag
2022.09.02 12:33:00 5: No device for >>termin<< found, especially not in room >>mobile-app0<< (also not outside)!
2022.09.02 12:33:00 5: Response is: Tut mir leid, der angefragte Kanal scheint nicht zu existieren.
2022.09.02 12:33:00 5: published hermes/dialogueManager/endSession {"intentFilter": null,"sessionId": "520c578d-945b-7503-c8bc-541862cc1c45","siteId": "mobile-app0","text": "Tut mir leid, der angefragte Kanal scheint nicht zu existieren."}
2022.09.02 12:33:00 4: [Rhasspy] dispatch result is Rhasspy
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 02 September 2022, 12:36:19
Falsche Datei, bitte aus dem svn holen.

EDIT - z.B. mit:
{ Svn_GetFile('contrib/RHASSPY/10_RHASSPY.pm', 'FHEM/10_RHASSPY.pm') }
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 02 September 2022, 13:01:45
Ist jetzt auch in Github
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Raemsna am 02 September 2022, 13:14:46
OK. Sorry.

Mit dieser Version:
10_RHASSPY.pm 26367 2022-09-01 17:28:44Z Beta-User

gleiches Ergebnis:
2022.09.02 13:14:26 5: RHASSPY: [Rhasspy] Parse (IO: MQTT2Client_Rhasspy): Msg: hermes/intent/de.fhem_MediaChannels => {"input": "termin erstellen Morgen um 9 Uhr", "intent": {"intentName": "de.fhem:MediaChannels", "confidenceScore": 1.0}, "siteId": "mobile-app0", "id": null, "slots": [{"entity": "de.fhem.Device", "value": {"kind": "Unknown", "value": "termin"}, "slotName": "Device", "rawValue": "termin", "confidence": 1.0, "range": {"start": 0, "end": 6, "rawStart": 0, "rawEnd": 6}}, {"entity": "de.fhem.MediaChannels", "value": {"kind": "Unknown", "value": "erstellen"}, "slotName": "Channel", "rawValue": "erstellen", "confidence": 1.0, "range": {"start": 7, "end": 16, "rawStart": 7, "rawEnd": 16}}, {"entity": "Wochentag", "value": {"kind": "Unknown", "value": "Morgen"}, "slotName": "day", "rawValue": "morgen", "confidence": 1.0, "range": {"start": 17, "end": 23, "rawStart": 17, "rawEnd": 23}}, {"entity": "rhasspy/number", "value": {"kind": "Number", "value": 9}, "slotName": "Hourabs", "rawValue": "neun", "confidence": 1.0, "range": {"start": 27, "end": 28, "rawStart": 27, "rawEnd": 31}}], "sessionId": "2e686af5-d82a-e066-dc9b-d7f18f4a6870", "customData": null, "asrTokens": [[{"value": "termin", "confidence": 1.0, "rangeStart": 0, "rangeEnd": 6, "time": null}, {"value": "erstellen", "confidence": 1.0, "rangeStart": 7, "rangeEnd": 16, "time": null}, {"value": "Morgen", "confidence": 1.0, "rangeStart": 17, "rangeEnd": 23, "time": null}, {"value": "um", "confidence": 1.0, "rangeStart": 24, "rangeEnd": 26, "time": null}, {"value": "9", "confidence": 1.0, "rangeStart": 27, "rangeEnd": 28, "time": null}, {"value": "Uhr", "confidence": 1.0, "rangeStart": 29, "rangeEnd": 32, "time": null}]], "asrConfidence": null, "rawInput": "termin erstellen morgen um neun uhr", "wakewordId": null, "lang": null}
2022.09.02 13:14:26 5: Parsed value: 9 for key: Hourabs
2022.09.02 13:14:26 5: Parsed value: erstellen for key: Channel
2022.09.02 13:14:26 5: Parsed value: MediaChannels for key: intent
2022.09.02 13:14:26 5: Parsed value: termin erstellen Morgen um 9 Uhr for key: input
2022.09.02 13:14:26 5: Parsed value: mobile-app0 for key: siteId
2022.09.02 13:14:26 5: Parsed value: termin for key: Device
2022.09.02 13:14:26 5: Parsed value: 1 for key: confidence
2022.09.02 13:14:26 5: Parsed value: 2e686af5-d82a-e066-dc9b-d7f18f4a6870 for key: sessionId
2022.09.02 13:14:26 5: Parsed value: termin erstellen morgen um neun uhr for key: rawInput
2022.09.02 13:14:26 5: Parsed value: Morgen for key: day
2022.09.02 13:14:26 5: handleIntentMediaChannels called
2022.09.02 13:14:26 5: room is identified using siteId as mobile-app0
2022.09.02 13:14:26 5: Device selected (by hash, using only name): dummy_Rhasspy_Kalendereintrag
2022.09.02 13:14:26 5: No device for >>termin<< found, especially not in room >>mobile-app0<< (also not outside)!
2022.09.02 13:14:26 5: Response is: Tut mir leid, der angefragte Kanal scheint nicht zu existieren.
2022.09.02 13:14:26 5: published hermes/dialogueManager/endSession {"intentFilter": null,"sessionId": "2e686af5-d82a-e066-dc9b-d7f18f4a6870","siteId": "mobile-app0","text": "Tut mir leid, der angefragte Kanal scheint nicht zu existieren."}
2022.09.02 13:14:26 4: [Rhasspy] dispatch result is Rhasspy

Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 02 September 2022, 14:50:23
OK, (Rest-) Problem vermutlich gefunden, werd's dann heute abend einchecken, falls du schon testen willst: gefixtes Modul anbei.

EDIT: Jetzt wieder im svn.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Raemsna am 03 September 2022, 14:30:41
habe das Modul über das SVN geholt und kann Bestätigen, dass es jetzt ohne sonstige Änderungen in meinem Setup wieder funktioniert.
Vielen Dank für die Hilfe!
:)

10_RHASSPY.pm 26373 2022-09-02 19:21:55Z Beta-User

Liebe Grüße
Raemsna
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 03 September 2022, 15:30:55
Dank zurück für's geduldige Testen!

Und sorry, dass ich diesen Teil nicht direkt auf dem Schirm hatte.

@drhirn: Kannst/magst du das wieder in github einpflegen?

Nachdem wir eine kleine aber feine Fan-Basis haben und soweit erkennbar keine ernsthaften Probleme mehr: regulär einchecken? (Ich kann auch den Maintainer dafür machen).
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 03 September 2022, 15:42:50
Ist in GitHub.

Ja, können wir gerne regulär einchecken. Wäre dir aber in der Tat sehr dankbar, wenn du den Maintainer machst.
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 15 November 2022, 14:54:48
Zur Info - vorhin gefunden: Rhasspy is Joining Nabu Casa (https://community.rhasspy.org/t/rhasspy-is-joining-nabu-casa/4007)
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 15 November 2022, 15:07:04
Cool! Danke für die Info. Die HomeAssistant-Lastigkeit find ich persönlich jetzt aber nicht so toll, wie alle anderen dort ;)
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 15 November 2022, 15:16:13
Na ja, mir ist das mit der HA-Lastigkeit relativ gleichgültig, solange sich nicht grundlegend was ändert (danach klang es nicht), und v.a. dann wieder aktualisierte Installationspakete etc. kommen...
Verbesserungen sind selbstredend auch gerne gesehen, aber an sich bin ich ja auch (wie ihr alle wohl auch) mit dem Stand ganz zufrieden. Und über Fragen wie Wie kann ich Alexa (einfach)den Ladestand meines Stromspeichers vorlesen lassen? (https://forum.fhem.de/index.php/topic,130322.0.html) kann ich im Moment auch nur müde lächeln. Rhasspy macht sowas klaglos in jeglich erdenklicher Form.... 8)
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 15 November 2022, 18:09:01
Zitat von: Beta-User am 15 November 2022, 15:16:13
Na ja, mir ist das mit der HA-Lastigkeit relativ gleichgültig, solange sich nicht grundlegend was ändert (danach klang es nicht), und v.a. dann wieder aktualisierte Installationspakete etc. kommen...
Verbesserungen sind selbstredend auch gerne gesehen, aber an sich bin ich ja auch (wie ihr alle wohl auch) mit dem Stand ganz zufrieden. Und über Fragen wie Wie kann ich Alexa (einfach)den Ladestand meines Stromspeichers vorlesen lassen? (https://forum.fhem.de/index.php/topic,130322.0.html) kann ich im Moment auch nur müde lächeln. Rhasspy macht sowas klaglos in jeglich erdenklicher Form.... 8)
Ich auch ...  8)

Die Ankündigung klingt gut. Bisher warte ich noch auf die Version 2.6 (am 16.02.22 angekündigt).

Gruß Jens
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 17 November 2022, 19:45:47
Wie es aussieht, wird Audio künftig mit SIP übertragen und MQTT wird für die Steuerung genutzt.
https://community.rhasspy.org/t/use-voip-device-with-rhasspy/4018/2 (https://community.rhasspy.org/t/use-voip-device-with-rhasspy/4018/2)

Fand ich schon immer gut.  8)
https://forum.fhem.de/index.php/topic,119447.msg1201753.html#msg1201753 (https://forum.fhem.de/index.php/topic,119447.msg1201753.html#msg1201753)
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 17 November 2022, 19:57:41
Hat dir auch keiner widersprochen ;D
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Raemsna am 28 Dezember 2022, 11:45:01
Nur zur INFO:
ich habe zufällig gesehen, dass es nun wieder eine Weiterentwicklung von Rhasspy geben soll/wird:

https://community.rhasspy.org/t/2023-year-of-voice/4130 (https://community.rhasspy.org/t/2023-year-of-voice/4130)

Edit:

und hier...
https://community.rhasspy.org/t/rhasspy-is-joining-nabu-casa/4007 (https://community.rhasspy.org/t/rhasspy-is-joining-nabu-casa/4007)
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 30 Dezember 2022, 11:50:27
 :) Ja, da ist wieder deutlich mehr Bewegung im Rhasspy-Forum. Mal sehen, was das neue Jahr dann bringen wird, ich hoffe nur sehr, dass "unsere" Schnittstellen keinen großen Änderungen unterworfen sein werden (HTTP-API und MQTT), sonst wird das vermutlich (nicht) "lustig"...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Thyraz am 28 Januar 2023, 13:24:49
In Verbindung mit HA tut sich da gerade viel. Mit der iOS Beta dann auch über Shortcuts / Siri
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 29 Januar 2023, 10:55:22
@Thyraz

Die Beiträge im Rhsspy- und im HA-Forum erschließen sich mir nicht.
@synesthesiam hat Version 3 angekündigt, welche grundlegende Änderungen in der Modulkommunikation haben soll.
Trotzdem wird die Version 2.5 weiterhin gepusht...
Insgesamt ist in HA die Struktur gut aufgebaut und das Auslagern des Parseres hat Performancevorteile.
Hast du ingendwelche Infos, wie das neue Rhasspy konkret arbeiten wird?

Gruß Jens
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 29 Januar 2023, 11:03:22
@Thyraz - vorab mal herzlichen Dank für die Arbeit, die du in grauer Vorzeit mal in den Vorgänger des heutigen Moduls gesteckt hast!!!

Was das HomeAssistant-Ding angeht, kommt es mir so vor, als wären wir in FHEM meilenweit vorneweg, jedenfalls, wenn ich die sentences.ini-Schnipsel so sehe, die seitens der HA-User zu finden sind.

Und ehrlich gesagt glaube ich auch nicht, dass das Parsen der Messages für FHEM performancemäßig eine große Last bedeutet. So viele Infos sind es dann nicht, die ausgewertet werden müssen...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 15 Februar 2023, 18:56:27
Zitat von: Beta-User am 29 Januar 2023, 11:03:22
Was das HomeAssistant-Ding angeht, kommt es mir so vor, als wären wir in FHEM meilenweit vorneweg, jedenfalls, wenn ich die sentences.ini-Schnipsel so sehe, die seitens der HA-User zu finden sind.
Das denke ich auch. Da @synesthesiam jetzt direkt für HomeAssistant arbeitet, wird es dort (irgendwann) einen Schub geben. Momentan ist die HA-Einbindung nicht mit FHEM-RHASSPY-Modul zu vergleichen.
@synesthesiam hält sich noch mit der Version 3 bedeckt. Habe ihn vor Tagen darum gebeten, mich in den Kreis der Tester aufzunehmen - bisher ohne Antwort...
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: JensS am 07 März 2023, 07:42:24
Rhasspy 3 ist nun am Start und läuft in der Erkennung recht gut, auch wenn etwas Leistung gefragt ist.
https://community.rhasspy.org/t/rhasspy-3-developer-preview/4409/1 (https://community.rhasspy.org/t/rhasspy-3-developer-preview/4409/1)
Die Module kommunizieren untereinander mit pipes und das Ganze ist im derzeitigen Entwicklungsstadium noch ohne Satelliten.
Mal sehen, ob dort jemand eine MQTT-Bridge schreibt - dann spare ich mir Arbeit.  ;D

Gruß Jens