Modulentwicklung für Rhasspy Sprachassistent

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

Vorheriges Thema - Nächstes Thema

drhirn

Wie und wo ist denn dein FHEM installiert? Windows? Weil mir passiert das nicht. Ich bekomm mit deiner Codierung Probleme.

JensS

#16
ZitatDebian auf APU2C4, HM-CFG-USB2, SIGNALduino, HM-ES-PMSw1-Pl, AB440S, AB440R, TFA 30.3121, TFA 30.3125, ITS-150, PIR-5000, configurable Firmata USB & LAN, 1-wire: DS-18B20, DS-18S20, DS-2408, DS-2413, diverse I2C-Komponenten, zigbee2mqtt, ESPEasy etc.
Als Browser nutze ich einen aktuellen Edge auf Windows10 - alles in deutsch. Auf dier Rhasspy-Weboberfläche werden alle Umlaute richtig dargestellt.
Gruß Jens

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


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

p.p.s.{ qx(locale)}
LANG=de_DE.UTF-8
LANGUAGE=
LC_CTYPE="de_DE.UTF-8"
LC_NUMERIC="de_DE.UTF-8"
LC_TIME="de_DE.UTF-8"
LC_COLLATE="de_DE.UTF-8"
LC_MONETARY="de_DE.UTF-8"
LC_MESSAGES="de_DE.UTF-8"
LC_PAPER="de_DE.UTF-8"
LC_NAME="de_DE.UTF-8"
LC_ADDRESS="de_DE.UTF-8"
LC_TELEPHONE="de_DE.UTF-8"
LC_MEASUREMENT="de_DE.UTF-8"
LC_IDENTIFICATION="de_DE.UTF-8"
LC_ALL=
Debian auf APU2C4, HM-CFG-USB2, SIGNALduino, HM-ES-PMSw1-Pl, 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.

drhirn

Ist dein Debian deutsch?

Ja, zu spät gesehen.

JensS

#18
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.
Debian auf APU2C4, HM-CFG-USB2, SIGNALduino, HM-ES-PMSw1-Pl, 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.

drhirn

jRoom kennt das Modul nicht, das kennt nur Room. Und wenn der nicht vorhanden ist, wird Room durch die siteId ersetzt.

JensS

Wieso das denn? Im customIntent sollten die Werte 1:1 übergeben - und nicht verändert werden.
Debian auf APU2C4, HM-CFG-USB2, SIGNALduino, HM-ES-PMSw1-Pl, 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.

Beta-User

#21
Zitat von: JensS am 13 März 2021, 12:04:23
p.s. Grrrrr, jetzt wird die SiteId übergeben, statt des gesprochenen Raumnamens.
Vermutung: der Raumname matcht nicht mit was bekanntem, dann wird aus Raum siteId (immer).
(doppelt, eben durch drhirn bestätigt)
Und ja, es sollte die Info zu jRoom zurückgegeben werden, ich vermute an der Stelle ein Problem mit dem Encoding und/oder mit der Art, wie der JSON-Parser die Daten analysiert. Da werden (schon immer) uU. nicht alle Infos aus dem JSON geholt, (zumindest, wenn ich den Code richtig interpretiere, was aber an der Stelle eher flüchtig überflogen wurde, da er funktioniert hat und perlcritic nicht gemeckert hatte)...



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

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

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



Ansonsten anbei mein noch ziemlich unfertiger Zwischenstand. Neben den (hier deaktivierten) ersten weiteren Vorarbeiten zum Thema Flexibilisierung der Mapping-Generierung sind da auch noch kleinere Änderungen am Basiscode drin. Wäre ggf. gut, das wieder zu konsolidieren, damit es möglichst halbwegs synchron bleibt, was wir tun.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

JensS

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.
Debian auf APU2C4, HM-CFG-USB2, SIGNALduino, HM-ES-PMSw1-Pl, 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.

Beta-User

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...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

JensS

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.
Debian auf APU2C4, HM-CFG-USB2, SIGNALduino, HM-ES-PMSw1-Pl, 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.

drhirn

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.

Beta-User

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.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

drhirn

Zitat von: JensS am 13 März 2021, 14:05:17
Übrigens sind alle Systeme in meinem Netzwerk de_DE.UTF-8-codiert. Also nichts exotisches.

Eh nicht. UTF-8 sollte UTF-8 sein. Egal in welcher Sprache. Finde das etwas merkwürdig. Ich bin mir v.a. nicht ganz sicher, ob das wirklich an FHEM liegt.
Du hast doch sicher irgendeinen MQTT Explorer installiert (MQTT FX, etc.)? Wie sieht das dort aus?

drhirn

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.

Beta-User

Betr. das SetAllOff-Ding...:

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

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

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

Bzgl. UTF-8:
Es scheint so zu sein, dass bei JensS da irgendwo was schief hängt, sonst wäre ja gezeigte die Payload nicht "verbogen" gewesen. Wäre natürlich schön, wir könnten das allgemein mit UTF-8 lösen (und JensS die passende Stelle finden, die das verbiegt), aber falls das auf ein generelles Thema hindeutet, über das noch mehrere stolpern, sollten wir eine Möglichkeit bieten, das notfalls eben über das Modul zu fixen.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files