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
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: drhirn am 11 März 2021, 16:23:47
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
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
Zitat
Debian 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
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
Ü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:
Zitat
Raum: 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
Glaube das Problem gefunden zu haben: Die Parameternamen wurden nämlich im Hash ausgetauscht.

Eine Lösung für welches Problem?

Zitat
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).

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

Zitat
Bin 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.
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
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:
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).

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
Verständnisfrage meinerseits: Hat das bisher (bis V. 0.2.x) geklappt :o ?

Nein. Ist ein Feature-Request ;)

Zitat
Auf 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.

Zitat
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.

Ja, können wir gerne machen.

Zitat
Zumindest 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...)

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

Zitat
Ja, 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
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:
Zitat
Ich 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
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
Mir ist aufgefallen, dass man reinit devicemap nach einem Neustart explizit aufrufen muss. Sonst ist der Hash leer. Ist das Absicht?
[....] 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).

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
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
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
Ich habe gerade die Möglichkeit eingebaut, die Ausgabe-Lautstärke einer siteId zu ändern.
:)
Zitat
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?
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};
    }
Zitat
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?
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;
}

Zitat
Und, 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
Ob das viel "besser" ist:

Finde schon :)

Zitat
Vermutlich 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.

Zitat
Habe 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
Finde schon :)
...na dann 8) .

Zitat
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.
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
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
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
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.


Zitat
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...).

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
... 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
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").
Zitat
Viiiiel 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...

Zitat
Mach ich gleich.
Viel Erfolg.

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.

Zitat
Zeile 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
SetNummeric 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
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
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) .

Zitat
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.
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...)

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

Zitat
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.
Meine Rede! Auch wenn das Jens wahrscheinlich gar nicht gerne hört ;D

Zitat
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...
Welches Video?

Zitat
Doku: $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
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
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...

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

Zitat
Welches 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
Ä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.

Zitat
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.

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.


Zitat
Wenn 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
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
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.

Zitat
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.
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).

Zitat
Ich 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).

Zitat
Reicht 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 ::) .

ini?
sentences.ini (dafür war doch dieser verschachtelte code, oder? Da standen erst {minutes}, im Modulcode aber {min}...)
Zitat
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?
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
(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
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 ;)

Zitat
Bei 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.


Zitat
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).

Ja, da bin ich deiner Meinung.

Zitat
Also: 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?

Zitat
Kannst ja mal schauen, ob und was da bei dir wie im Hash landet ;) .
Mach ich
 
Zitat
Von 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
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
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...

Deswegen [...]
Schaue ich mir an, aber eigentlich sehe ich diesen Teil auch nicht wirklich als meine aktuelle Baustelle an...

Zitat
Ich 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
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

Zitat
Schaue 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

Zitat
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).
Beim Homebridge-Mapping kann ich gar nicht helfen. Da hab ich null Erfahrung.

Zitat
Jedenfalls 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
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.

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

Zitat
Beim 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...

Zitat
Das 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...

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
Hattest du Zweifel?!?
An dir nicht. Aber ich war mir nicht sicher, was Rhasspy mit so vielen Klammern macht.

Zitat
Btw.: 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
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
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
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
(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
Ö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.

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:
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!
Zitat
Wenn 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.
Zitat
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.
Wär ne tolle Sache!
Zitat
nur bei Hash-Nutzung wird alles auf Kleinschreibung "getrimmt"
...sehe ich kritisch, da in den Rhasspy-Attributen bzw. sentences.ini beides erlaubt ist.
Zitat
Dazu 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.
Zitat
Dazu 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.
Zitat
Ich 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
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.).

Zitat
Zeile 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...

Zitat
p.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.
Zitat
Die 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...?

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

Zitat
Bzgl. 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.

Zitat
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.
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
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
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
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...

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
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
Also, 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.)

Zitat
Jetzt 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.

Zitat
Und 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
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:

Danke 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
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).

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.

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

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
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:
Guten Morgen,

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

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)
Zitat
my $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.

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.

@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
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
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;
}


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};
"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:
Zitat
define <name> RHASSPY <devspec> <defaultRoom> <language> <fhemId> <prefix> <useGenericAttrs> <encoding>
Und kann neue Tests starten.

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;
}
Zitat
define <name> RHASSPY <devspec> <defaultRoom> <language> <fhemId> <prefix> <useGenericAttrs> <encoding>
Cool, da hat man viele Anpassungsmöglichkeiten bereits in der Definition.  8)

Zitat
labels=( 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
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.

Zitat
Cool, 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).

Zitat
Bei 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).

Zitat
Wenn 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
@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...?

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
@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
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
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
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
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...

Zitat
Aber 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"...)

Zitat
Oder 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...?

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
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.cfgsetstate 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ámetrosoder 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
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?

Zitat
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.

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

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.

Zitat
Wie 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.

Zitat
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.
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
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
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
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:
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....

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

Zitat
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
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.

Zitat
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).
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...).

Zitat
Gibt'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...

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

Zitat
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...).

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.

Zitat
Es 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

Zitat
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.

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

Zitat
rhasspyMaster 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?

Zitat
Wobei 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
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...

Zitat
Nun 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.

Zitat
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.
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...)

Zitat
Ja. Eindeutig. :D
Wie gesagt: muss mal nachdenken/spielen...

Zitat
Nochmal "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.

Zitat
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:
[...]
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
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.

Zitat
Bin 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.

Zitat
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).

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
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
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 ;) .

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

Zitat
Bin 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...)

Zitat
Funktioniert. 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
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

Zitat
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.

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"

Zitat
Das ist nun gar nicht mein Kenntnishorizont...

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

Zitat
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 ";"?).

Keine Ahnung. Müsste jemand anderes beantworten.

Zitat
snipsRoom 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.

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

Ja, unbedingt!

Zitat
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.

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

Zitat
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"
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.

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

Zitat
Keine 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...)

Zitat
War 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.

Zitat
Ja, 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
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?

Zitat
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?

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
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.
Zitat
Solange 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
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 ::) ...

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

Zitat
Info: {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
Zitat
Prima, 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?

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
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));
    }
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...

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

Zitat
Kann'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...

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
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
@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
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
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
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
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:
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
Zitat
schalte ü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
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...

Zitat
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?

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.

Zitat
Da 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
@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...!)

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 ;) ..
Zitat
Oder 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...

Zitat
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 ;) .
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.

Zitat
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.
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...

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
Zum einen, weil ich (eventuell fälschlicherweise) davon ausgegangen war, dass Room eine eher größere Gruppe darstellen sollte

Ist auch meine FHEM-Logik


Zitat
Neben 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.

Zitat
Bei 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.

Zitat
Eventuell 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.

Zitat
medias 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
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
Zitat
Dann 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 ...

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
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"
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
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
Zitat
Verwendest 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)
Zitat
Sobald 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.

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

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.

(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
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.

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.

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

Zitat
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...

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

Zitat
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.

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

Zitat
Das 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
Die neue "Default-Branch" ist jetzt 0.4.7b.
:)

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
Ä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.

Zitat
Vielleicht 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

Zitat
Only 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...).

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

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

Zitat
Ja, 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
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
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.

Zitat
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...)

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

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.

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

Zitat
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.

Ich habe das zwar nicht behauptet, weil ich das nicht wusste. Aber ich werde das gleich ausprobieren.

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

Suuuper, danke!

Zitat
Auch 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

Zitat
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?

Darf ich dich bitten?


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

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
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
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
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).
Also, ich weiß bis jetzt nur, dass ein Mixed Language Model Weight Wert  [...]
...klingt spannend...

Suuuper, danke!
8)

Zitat
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
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
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.

Zitat
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 .

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

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

Zitat
Ich 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
Zitat 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
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.

Ist es auch nicht. Aber für den Moment, denke ich, können wir damit leben.

Zitat
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. 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
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.
Ja, das auch. Könnte man aber auch dem User überlassen, die hübsch zu benennen.

Zitat
Sorry, 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

Zitat
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...
ToDo-Liste
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 13 April 2021, 17:24:06
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.

Zitat
Kann 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
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?

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

Zitat
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"...)

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

Ä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 ;) ).

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

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
Wie 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
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.

Zitat
Mah, 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
Bitte auch in der cref anpassen.

Erledigt.

Zitat
Btw.: 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. ;)

Zitat
Wü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
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
Zitat
in 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.

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
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
...das mit dem Bier klingt gut!

Haben wir uns auch verdient

Zitat
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....
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
Haben wir uns auch verdient
:) Unbedingt!

Zitat
Das sind ja auch alles Feiglinge ;D
Du bist der Boss!

Zitat
Meine 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
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

Zitat
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"
Ja, gute Idee mit "rhasspySpecials"

Zitat
Den 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.


Zitat
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...)

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
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_Taimerbzw.:
attr RHASSPY rhasspyTweaks timerSounds= default=./flasche.wav Eier=3:20:./flasche1.wav Kartoffeln=5:./flasche2.wavAber 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...

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
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
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}
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
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
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
...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



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

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
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
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
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
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
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
(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
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
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
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
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
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
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?

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

Zitat
Schon 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
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.).

Zitat
Und 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
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
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
...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.

Zitat
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.
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
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.

Zitat
Meine Kunstwerke wären die MySensors-Module, Weekday- und RandomTimer sowie Twilight...

Ist notiert.

Zitat
Nachtrag: 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
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:
Zitat
DefaultError= 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
- "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.

Zitat
Das 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.

Zitat
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).

In GitHub gibt's auch Commits.

Zitat
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).

"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
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=1Zusätzlich habe ich mal testweise die Option drin, overwrite auszuschalten:
attr rhasspy updateSlots=overwrite_all=falseBin noch nicht sicher, ob das eine gute Idee ist...
Jedenfalls ist "tweaks" jetzt um diese Einträge länger

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

Zitat
In 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
...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


Zitat
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=1Zusätzlich habe ich mal testweise die Option drin, overwrite auszuschalten:
attr rhasspy updateSlots=overwrite_all=falseBin 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=falseoder?

Zitat
configFile heißt jetzt auch languageFile, allerdings muss das für configDB weiter als Internal CONFIGFILE heißen.
8)

Zitat
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"?
Es ist eigentlich kein "update". Je nachdem, von welcher Seite man das sieht. ;)
Aber ist ok für mich.

Zitat
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?
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
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=falseoder?
 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
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
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
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.

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
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
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
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
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
Zum 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.

Zitat
Es 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?

Zitat
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.
Eben nicht. Device-light ist ja nur eine Untermenge von Device.

Zitat
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.
Ja, war so. Und ich fand's lästig ;).

Zitat
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...
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
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
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).

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

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.

Zitat
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.
Ich dachte, wir haben uns darauf geeinigt, den Zopf abzuschneiden :D


Zitat
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.
Ist richtig, ist immer gleich. Aber der User kann's ändern, wenn er das möchte. Oder neue Farben hinzufügen.

Zitat
Andere 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
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.)

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
Doch 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
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

...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
Ging 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
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...

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

Zitat
gerade 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
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
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.

Zitat
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).
Ahhhhhh. Man dankt!
Titel: Antw:Modulentwicklung für Rhasspy Sprachassistent
Beitrag von: Beta-User am 24 April 2021, 17:39:30
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
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
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?

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"
    }
}

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
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?
Wäre irgendwie schöner. Dachte nur, da gibt's vielleicht irgendwelche Vorgaben.

Zitat
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.
Meine Rede :D

Zitat
Der 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.

Zitat
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.
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
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
:-[ 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.

Zitat
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...
Macht's halt wieder teurer.

Zitat
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
Danke!

Zitat
Jetzt 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
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
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?

Zitat
Ich hab gestern noch bei Delete $prefix definiert. Das hat gefehlt.
stimmt.
Löschen bzw. umbenennen der Attribute ist aber eh' noch ein Thema...

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
und ich finde das Konzept des 360°-Farbkreises eigentlich ganz einleuchtend.

Ja, ist nicht blöd.

Zitat
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?

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


Zitat
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.

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
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:
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"!

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

Zitat
Und 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
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.

Zitat
da 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...

Zitat
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.
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
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
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:?

Zitat
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).
Ja, geht. Aber mit vollkommen falschen Werten.
Aus 2000 von Rhasspy wird 90000 in FHEM
Aus 6500 von Rhasspy wird 292500 in FHEM

Zitat
Hilft 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
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
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
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.

Zitat
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.
...und hab nicht daran gedacht, dass ct ja auch für richtige Farben verwendet wird.

Zitat
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).
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
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
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
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
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 (?)