FHEM Forum

Hallo,

ich bin gerade leicht verwirrt, über die Umwandlung der Codierung von Perls 'lc'. Kann mich da bitte jemand aufklären?

Ich habe Geräte mit einem Attribut "raum". Den Inhalt dieses Attribute sammle ich (in einem Modul), wandle es mit 'lc' in Kleinbuchstaben um, und erstelle dann ein Reading. Jetzt mal so grob erklärt. Aber viel mehr passiert wirklich nicht.

readingsSingleUpdate($hash, "test_" . lc($room), $room, 1);

Ist jetzt ein Attribut "raum" mit "Küche" befüllt, habe ich danach ein Reading, das test_k?che heißt.

Wenn ich das ganze aber umwandle

$room = encode('iso-8859-1', $room);
readingsSingleUpdate($hash, "test_" . lc($room), $room, 1);

bekomme ich ein Reading test_küche.

print setlocale(LC_CTYPE); meint en_US.UTF-8, meine FHEM-Instanz ist auf englisch eingestellt.

Sollte UTF-8 nicht Umlaute können? Oder irre ich mich jetzt da?
Freue mich über jede Erklärung - und v.a. Vorschläge, wie man's eleganter löst.

Stefan

Auch wenn ich nicht wirklich was zu utf-Fragen beitragen kann: Umlaute sind eigentlich keine erlaubten Zeichen in Reading-Namen.

Vielleicht hilft dir makeReadingName() (und goodReadingName()) als Stichwort zur Suche in fhem.pl weiter?

(Und wenn ich readingsSingleUpdate() irgendwo sehe, habe ich den Reflex, nach dem nächsten Vorkommen der Funktion zu suchen und zu ergründen, ob man das nicht besser per Bulk-update verarbeiten kann).

Wiki tut's auch. Danke für den Hinweis! Da muss ich mir was überlegen. Eine Küche heißt nunmal Küche und keiner sagt Kueche ;)

Und außerdem: Tu nicht schon wieder vom Thema ablenken :D
Aber, wenn wir schon dabei sind: Gibt's noch einen anderen Unterschied zw. single und bulk, außer, dass ich mit bulk gleich mehrere setzen kann?

...ablenken war nicht beabsichtigt...

Wenn du irgendwo Umlaute brauchst, solltest du das irgendwie anders lösen, ist halt schwierig eine Idee zu entwickeln, wenn man a) grundsätzlich keine vertiefte Erfahrung von der Materie utf hat und b) keine Infos, wie die Readings verwendet werden sollen...

single="kleines bulk", das ruft intern auch nur bulk auf. Der wesentliche Unterschied ist der: jedes bulk-Ende (also indirekt auch single) ruft die komplette Event-Verarbeitung auf. Es ist daher m.E. grundsätzlich sinnvoll, alle Readings (eines Devices) auf einmal zu schreiben. Siehe ggf. die "Beispielschleife" in https://wiki.fhem.de/wiki/DevelopmentModuleIntro#X_Notify

makeReadingName ist eine super Sache! Damit ist mein Problem gelöst.
Hätte es halt gerne verstanden.

Gut, dann hab ich das mit single/bulk eh richtig verstanden. Schau ich mir genauer an, ob ich das optimieren kann. Meine ersten Versuche waren nicht erfolgreich.

Danke dir!

Zitat von: drhirn am 18 Februar 2021, 17:36:21
Hätte es halt gerne verstanden.

Mal schauen, ob das noch jemand kompetentes erklärt...

ZitatmakeReadingName ist eine super Sache! Damit ist mein Problem gelöst.

Thx für die Rückmeldung!

Ad OT:
Ist nur ein Reflex, ich habe halt bei meinen eigenen Modulen irgendwann gemerkt, dass da Potential drin war, und bis vor kurzem war ich da auch noch nicht so sensibel...
Und weil wir grade sowieso Teil-OT sind: Das RHASSPY-Ding bringt ja per default sowieso einen Broker mit, oder? Warum baust du das nicht generell nach MQTT2_CLIENT um? (Kann sein, dass du Rudi brauchst, damit das Modul als weiterer Client für die M2-IOs akzeptiert wird, ist aber vermutlich kein Hexenwerk).
(Ist schon klar, dass das für dich erst mal Zusatzufwand ist, aber nachfolgende User-Generationen würden es dir danken! Just my2ct.).

Ich bin mir ganz sicher, dass das auch mit MQTT2_CLIENT funktionieren würde, ohne dass ich viel Arbeit reinstecken müsste. Ich glaub, ich hab das vor Langem mit dem Snips-Modul sogar mal ausprobiert. Es hatte bis gestern einfach noch keine Priorität.

Fällt dir ein aktuelles Modul ein, bei dem ich mir das ansehen könnte?

Alles gut ;D .
Falls du dabei Hilfe benötigst: Sag' Bescheid!

Einen echten "Hybriden", der mit beiden IO-Typen kann, findest du in MQTT_GENERIC_BRIDGE; da leitet Parse() nach onMessage() (oder so ähnlich) um und entfernt vorab "M2-Spezifika" (das "autocreate-flag").

(Es würde sich ggf. anbieten, die relevanten Teile aus MGB in eine eigene Lib auszulagern und das ganze zu packagen, falls noch nicht geschehen)

Du wirst mit Sicherheit von mir hören. Ich hab nämlich keinen Plan ;)

MQTT_GENERIC_BRIDGE hast du eh schon erwähnt. Das ist mir zu komplex. Ich bräuchte ein Modul, bei dem ich auch verstehe, was es tut.

...es tut zu einem wesentlichen Teil was sehr ähnliches wie deines: Es schaltet - veranlasst durch eingehende MQTT-Kommandos - FHEM-Geräte bzw. aktualisiert Readings ;) .

(in die andere Richtung werden einfach Events in Topic+Message umgewandelt und an den Server geschickt, da, wo passende Attribute gesetzt sind).

Von daher könnte man den "Empfangs-Unterbau" auch bis zum Punkt "onMessage()" 1:1 kopieren ;) . Vielleicht bin ich "mal lustig" und versuche mich in meiner ersten lib...

Du kannst auch gerne in "meinem" Modul (https://github.com/drhirn/fhem-rhasspy) lustig sein. Das braucht eh dringend einen fachmännischen Blick. ;)

Über "fachmännisch" kann man streiten...

Hab's mal nach perlcritic.com gepastet und "harsh" dagegen laufen lassen, das würde ich "zur Übung" auch mal empfehlen. Über die "Frgezeichen"-Symbole kommt dann jeweils auch eine Erläuterung, warum das im einzelnen als nicht so prickelnd angesehen wird...

Dann das ganze gepackaged, ich hoffe, beim Importieren keine wichtige Funktion übersehen zu haben, sonst gibt's crashes...

Anbei mal ein erstes Zwischenergebnis als Diskussionsgrundlage.
Kann dazu funktional nicht viel sagen, es lädt, ist aber sonst ungetestet...

Das ist ja eine coole Seite! Ich staune
Danke für den Hinweis, sehe ich mir dann genauer an.

Und deine Version wird getestet.

Es hat gut ausgesehen. Bis ich das Device mal gelöscht habe und neu anlegen wollte:

ZitatUndefined subroutine &main::RHASSPY_Define called at fhem.pl line 3830.

Das mit mit "package" und die Benennung von "subs" verstehe ich sowieso nicht. Ich habe mich da beim Umbau des Modules an das "DevelopmentModuleIntro" aus dem Wiki gehalten. Aber wenn ich mir da neuere Module ansehe, scheint das nicht mehr ganz aktuell zu sein, oder? Hast du da einen Tipp für mich, wo ich weitere Informationen finde?

Danke!

Das sollte erst mal gegen den Absturz helfen:

    $hash->{DefFn}       = \&RHASSPY_Define;
    $hash->{UndefFn}     = \&RHASSPY_Undefine;
    $hash->{SetFn}       = \&RHASSPY_Set;
    $hash->{AttrFn}      = \&RHASSPY_Attr;
    $hash->{AttrList}    = "IODev defaultRoom rhasspyIntents:textField-long shortcuts:textField-long rhasspyMaster response:textField-long " . $readingFnAttributes;
    $hash->{OnMessageFn} = \&RHASSPY_onmessage;
Was "packages" angeht, mag man geteilter Meinung sein. Ich finde das zwischenzeitlich deutlich besser, weil man schlicht und ergreifend nicht aufpassen muss, dass man versehentlich irgendwas aus dem main-Kontext in den Abgrund reißt. Außerdem kann man manche Funktionen klarer adressieren (min vs. minNum).
Das Problem bei bestehenden Modulen ist nur, dass man erst mal sauber importieren muss, und diese Stelle habe ich dusseliger Weise übersehen...

Zitat von: Beta-User am 19 Februar 2021, 13:19:30
Das sollte erst mal gegen den Absturz helfen:

Code Auswählen Erweitern


    $hash->{DefFn}       = \&RHASSPY_Define;
    $hash->{UndefFn}     = \&RHASSPY_Undefine;
    $hash->{SetFn}       = \&RHASSPY_Set;
    $hash->{AttrFn}      = \&RHASSPY_Attr;
    $hash->{AttrList}    = "IODev defaultRoom rhasspyIntents:textField-long shortcuts:textField-long rhasspyMaster response:textField-long " . $readingFnAttributes;
    $hash->{OnMessageFn} = \&RHASSPY_onmessage;

Tut es, danke! Warum?

ZitatWas "packages" angeht, mag man geteilter Meinung sein. Ich finde das zwischenzeitlich deutlich besser, weil man schlicht und ergreifend nicht aufpassen muss, dass man versehentlich irgendwas aus dem main-Kontext in den Abgrund reißt. Außerdem kann man manche Funktionen klarer adressieren (min vs. minNum).

Gut, so hätte ich das auch verstanden. Aber das heißt, es gibt keine (FHEM-)Vorgaben, wie man's machen soll?

Warum POSIX nicht im main-Kontext?

Weil so nur eine Funktionsreferenz übergeben wird (innerhalb desselben namespace).

Es gibt zum Thema packaging keine wirklichen Vorgaben, aber eine nette Diskussion in der Perl-Ecke: https://forum.fhem.de/index.php/topic,110048.msg1040632.html#msg1040632 (https://forum.fhem.de/index.php/topic,110048.msg1040632.html#msg1040632). Irgendwo in dem Umfeld hatte auch Rudi dann aus der "myUtils-Mustervorlage" "use POSIX" rausgeworfen, eben weil diese Anweisung FÜR ALLE gilt und im main-namespace eigentlich schon durch fhem.pl so festgezurrt wird....

Das Problem bei eigenen Modulen ist: man schraubt im allgemeinen Namensraum rum. Das ist mit zunehmender Zahl von Modulen immer gefahrgeneigter, weil man die Seiteneffekte immer schlechter überblicken kann (ironischerweise vermutlich grade als "Einsteiger").

Anbei dann noch eine erste Version, die mit MQTT2_-IO's klarkommen könnte. Die subscriptions bei einem M2_CLIENT hat es zumindest erneuert, aber ob der dann die Dispatch-Funktion aufrufen würde, kann ich schlecht testen, weil mir sowohl das passende FHEM-Umfeld fehlt (also entsprechende zu steuernde Geräte) wie auch das, was der Dienst so an topic/messages generiert...

Das habe ich am M2_CLIENT mal per Attribut versucht:
clientOrder RHASSPY MQTT_GENERIC_BRIDGE MQTT2_DEVICEDamit hat er den auch in das Clients-Internal aufgenommen, das müßte daher eigentlich passen...

Mittelfristig gefällt mir der Hybrid nicht, ich würde eigentlich dazu neigen, das komplett auf die M2-IO's zuzuschneiden (vornehmlich CLIENT). Damit hat man dann 0 externe Abhängigkeiten mehr und kann auch SSL.

Zitat von: Beta-User am 19 Februar 2021, 13:56:19
Es gibt zum Thema packaging keine wirklichen Vorgaben, aber eine nette Diskussion in der Perl-Ecke: https://forum.fhem.de/index.php/topic,110048.msg1040632.html#msg1040632.

Den Thread hab ich sogar mal bei meinen Recherchen gelesen. Alles Bahnhof für mich. Keine Ahnung von Perl, wie gesagt. Und von anderen Programmiersprachen eigentlich auch nicht. Logo, das hab ich noch verstanden. Damals, als kleiner Bub.

Zitat
Das habe ich am M2_CLIENT mal per Attribut versucht:

Code Auswählen Erweitern

clientOrder RHASSPY MQTT_GENERIC_BRIDGE MQTT2_DEVICEDamit hat er den auch in das Clients-Internal aufgenommen, das müßte daher eigentlich passen...

Super! Werde ich dann ausprobieren.

ZitatMittelfristig gefällt mir der Hybrid nicht, ich würde eigentlich dazu neigen, das komplett auf die M2-IO's zuzuschneiden (vornehmlich CLIENT). Damit hat man dann 0 externe Abhängigkeiten mehr und kann aus SSL.

Jup. Wenn, dann gscheid. Sehe ich auch so.

Zitat von: drhirn am 19 Februar 2021, 14:09:22
Den Thread hab ich sogar mal bei meinen Recherchen gelesen. Alles Bahnhof für mich. Keine Ahnung von Perl, wie gesagt. Und von anderen Programmiersprachen eigentlich auch nicht. Logo, das hab ich noch verstanden. Damals, als kleiner Bub.

Na ja, immerhin kommst du irgendwie zurande mit deinem Umbau, also so schlimm kann es eigentlich nicht sein...

Zitat von: drhirn am 19 Februar 2021, 11:49:39
Das ist ja eine coole Seite! Ich staune

Ich bin in etwa auch bei "0" gestartet, was Programmierkenntnisse angeht, und diese Art der "formalisierten Kritik" (und die mehr oder weniger freundlichen Hinweise von RichardCZ zu "meinen" Modulen) haben dann schon was gebracht mit der Zeit. Bei vielem habe ich dann auch erst "häh?!?" gedacht, aber zwischenzeitlich schaue ich mir auch "cruel" an ;D (und erlaube mir dann, manches da zu ignorieren...). Da ist dann auch wieder vieles dabei, was schlicht zur Beschleunigung beiträgt...

Aber als "fachkundig" würde ich mich immer noch nicht bezeichnen...

ZitatJup. Wenn, dann gscheid. Sehe ich auch so.

OK, dann bauen wir das in die Richtung um, sobald du das Signal gibst!
Es sollte halt erst mal prinzipiell mit den M2-IO's laufen, bevor wir den anderen Zweig abschneiden...
(Ich vermute: publish klappt noch nicht).

EDIT: Evtl. klappt publish dann mit der angehängten Version...

Zitat von: Beta-User am 19 Februar 2021, 14:23:57Na ja, immerhin kommst du irgendwie zurande mit deinem Umbau, also so schlimm kann es eigentlich nicht sein...

Ich hab theoretische Programmierkenntnisse. Ich weiß, wie ich ein "If" baue, was für Arten Schleifen es gibt, etc. Ich kann Code in vielen Sprachen "verstehen". Und ich bin ein Meister in Copy&Paste und Suchmaschinen-Bedienung. Aber selber schreiben...
Und wenn's dann um fortgeschrittene Sachen geht, steige ich komplett aus.

ZitatOK, dann bauen wir das in die Richtung um, sobald du das Signal gibst!

Ich muss da kein Signal geben. Würde mich sehr freuen, wenn du dir die Arbeit antust und helfe gerne mit Tests und Erklärungen zu Rhasspy. Aber es ist nicht "mein" Modul. Kann jeder daran rumschrauben, der das möchte.

D.h. ich sollte mich mal mit MQTT2_X auseinandersetzen...

Zitat von: drhirn am 19 Februar 2021, 15:03:20
Ich muss da kein Signal geben. Würde mich sehr freuen, wenn du dir die Arbeit antust und helfe gerne mit Tests und Erklärungen zu Rhasspy. Aber es ist nicht "mein" Modul. Kann jeder daran rumschrauben, der das möchte.

Na ja, mit etwas Glück sollte es in der zuletzt geposteten Version erst mal mit beiden IO's laufen.
Ist halt auf die Dauer als "Hybrid" schwerer zu pflegen, und da man in den Standardeinstellungen sowieso ein separates IO hat, würde ich dazu neigen, die überflüssigen Teile dann wieder rauszuwerfen, wenn klar ist, dass es mit den M2-IO's (genauer: es reicht M2-CLIENT) läuft.

Soweit ich das im Moment überblicke, muss man dazu nur die clientOrder passend setzen (es reicht vermutlich, nur RHASSPY dort einzutragen).

Wenn wir den Code dann soweit haben, würde ich mich aus der Aktion dann wieder verabschieden wollen, von daher ist es eher "dein" Modul wie meines...

ZitatD.h. ich sollte mich mal mit MQTT2_X auseinandersetzen...

Abgesehen von diesem Attribut am Interface (und ggf. der Implementierung von "forceNEXT" in RHASSPY) braucht es dazu m.E. keine wirkliche Einarbeitung. Die IODev sind Interfaces und sollten im Hintergrund laufen, ohne den User mit irgendwelchen Details zu langweilen...
Den Teil "forceNEXT" sollte ich soweit beisteuern können, da geht es einfach darum, ob eingehende Messages exklusiv von RHASSPY verarbeitet werden oder noch an andere Module weitergereicht werden sollen.

Nachtrag noch: Die Parse-Fn sollte auch korrekt benannt werden: RHASSPY_Parse (#821), sonst knirscht das vermutlich auch dort...

So, ich hab jetzt da den MQTT2_CLIENT

defmod rhasspyMQTT2 MQTT2_CLIENT rhasspy:12183
attr rhasspyMQTT2 clientOrder RHASSPY MQTT_GENERIC_BRIDGE MQTT2_DEVICE


und ein neues Rhasspy-Device:

defmod Rhasspy RHASSPY rhasspyMQTT2 Wohnzimmer
attr Rhasspy IODev rhasspyMQTT2


Publish scheint zu funktionieren. Subscribe nicht.

OK, immerhin ein Teileerfolg.

In der ParseFn ist mir neben dem Namen auch noch ein bißchen was drumrum aufgefallen, es _könnte_ mit der Version besser (oder schlechter...) passen:

Ich merke da jetzt so spontan keinen Unterschied

Wenn du selber spielen willst, hier meine docker-compose.yml (für Windows)


version: '2'

services:
    rhasspy:
        image: "rhasspy/rhasspy"
        container_name: rhasspy
        depends_on:
            - fhem
        restart: unless-stopped
        volumes:
            - ".config/rhasspy/profiles:/profiles"
        ports:
            - "12101:12101"
            - "12183:12183"
        command: --user-profiles /profiles --profile de

    fhem:
        container_name: fhem-test
        restart: unless-stopped
        ports:
            - "8083:8083"
        image: fhem/fhem
        volumes:
            - ./opt/fhem/:/opt/fhem/
        environment:
            TZ: Europe/Vienna
           
    rhasspysat:
        image: "rhasspy/rhasspy"
        container_name: rhasspysat
        depends_on:
            - fhem
            - rhasspy
        restart: unless-stopped
        volumes:
            - ".config/rhasspysat/profiles:/profiles"
            - "./asound.conf:/etc/asound.conf"
        ports:
            - "13101:12101"
        command: --user-profiles /profiles --profile de
        environment:
            - PULSE_SERVER=host.docker.internal


Die asound.conf, wenn du auch einen Ton brauchst. Dann müsstest du aber auch noch pulseaudio zum Laufen bringen.

pcm.!default {
    type pulse
    hint.description "Default Audio Device"
}
ctl.!default {
    type pulse
}


Für Linux:

version: '3'

services:
    rhasspy:
        image: "rhasspy/rhasspy"
        container_name: rhasspy
        restart: unless-stopped
        volumes:
            - ".config/rhasspy/profiles:/profiles"
            - "/etc/localtime:/etc/localtime:ro"
            - "/etc/asound.conf:/etc/asound.conf"
        ports:
            - "12101:12101"
            - "12183:12183"
        command: --user-profiles /profiles --profile de
        devices:
          - "/dev/snd:/dev/snd"
        ipc: host


...das Problem war wohl eher die unvollständige Registrierung im Client, konnte das auch ohne docker nachvollziehen....

Mit der angehängten Fassung sollte das .clientArray ordentlich aufgebaut werden. Allerdings kann man den Code abschießen, wenn man z.B. non-JSON-Payload schickt an Topics, die für JSON ausgelegt sind. Unschön, aber vermutlich nicht neu, oder...?

(Kann sein, dass du bei purem Reload das clientOrder-Attribut anfassen mußt).

Die Intents ($topic) haben immer Doppelpunkte im Namen. Die werden jetzt irgendwo durch Unterstriche ersetzt. Weißt du wo und ist das Absicht? Wenn ja, warum? Kann man's ändern oder müssen wir damit leben?

Hmm, erst mal noch keine Ahnung. Kannst du mal schauen, ob das vor der ParseFn schon vom Client so geändert wird (dann schwierig) oder ob das intern irgendwo passiert?

Sollte sich über Zeile 851 rausfinden lassen, da den verbose-Level anpassen und es sollte im Log stehen, was an der Stelle "$topic" ist.

RHASSPY: [Rhasspy] Parse (MQTT2_CLIENT : 'rhasspyMQTT2'): Msg: hermes/intent/de.fhem_SetOnOff => {"input": "lampe wohnzimmer an", "intent": {"intentName": "de.fhem:SetOnOff", "confidenceScore": 1.0}, "siteId": "wohnzimmer", "id": null, "slots": [{"entity": "de.fhem.Device", "value": {"kind": "Unknown", "value": "lampe"}, "slotName": "Device", "rawValue": "lampe", "confidence": 1.0, "range": {"start": 0, "end": 5, "rawStart": 0, "rawEnd": 5}}, {"entity": "de.fhem.Room", "value": {"kind": "Unknown", "value": "wohnzimmer"}, "slotName": "Room", "rawValue": "wohnzimmer", "confidence": 1.0, "range": {"start": 6, "end": 16, "rawStart": 6, "rawEnd": 16}}, {"entity": "OnOffValue", "value": {"kind": "Unknown", "value": "an"}, "slotName": "Value", "rawValue": "ein", "confidence": 1.0, "range": {"start": 17, "end": 19, "rawStart": 17, "rawEnd": 20}}], "sessionId": "wohnzimmer-snowboy-36079a54-2f9f-4f14-a4c0-294511c4c5e6", "customData": null, "asrTokens": [[{"value": "lampe", "confidence": 1.0, "rangeStart": 0, "rangeEnd": 5, "time": null}, {"value": "wohnzimmer", "confidence": 1.0, "rangeStart": 6, "rangeEnd": 16, "time": null}, {"value": "an", "confidence": 1.0, "rangeStart": 17, "rangeEnd": 19, "time": null}]], "asrConfidence": null, "rawInput": "lampe wohnzimmer ein", "wakewordId": "snowboy", "lang": null}

Hmm, kommt aus #499 von M2C...

Eher schwierig zu ändern... Wenn es sein müßte, könnte man nur die Umkehr-Anweisung absetzen, bevor man onmessage aufruft. Die Frage ist aber, ob das lohnt, denn eigentlich steckt die Info dann ja nochmal in der Payload. Von daher wäre eher die Frage, ob man es von da nimmt?

Zitat von: Beta-User am 19 Februar 2021, 17:48:23
Von daher wäre eher die Frage, ob man es von da nimmt?

Verstehe ich nicht. Von wo soll man's nehmen?

Wir könnten auch einfach die Intent-Namen umbauen. Der Grund für den Doppelpunkt war beim Snips-Modul, dass man Snips-Intents von FHEM-Intents unterscheiden konnte. FHEM behandelt nur die mit Doppelpunkt. Das doofe ist, so ein Unterstrich ist halt sehr verbreitet. Und ich kann mir die Anfragen schon vorstellen, warum der Intent jetzt von Rhasspy und FHEM gleichzeitig angenommen wurde.

Die gute Nachricht ist, wenn ich in RHASSPY_onmessage die Doppelpunkt durch Unterstriche ersetze, scheint das ganz gut zu funktionieren.

[hat sich weitestgehend erledigt, selber Gedanke]
Da habe ich jetzt Schwierigkeiten, den Hintergrund zu verstehen. Unterscheiden sich Sende- und Empfangsrichtung nur dadurch, dass "snips" den Doppelpunkt im Topic verwendet und FHEM den "_"? Das wäre in der Tat schwierig.

Sonst habe ich nur das Problem gefunden, dass die Weiterverarbeitung nicht läuft mangels match im Topic.

Beiseitigt die beigefügte Version dieses Problem?

Nun, möchte man Intents von Rhasspy/Snips selbst intepretieren lassen (für z.B. Sachen, mit denen FHEM nichts zu tun hat), muss man irgendwie unterscheiden, welche Intents für Rhasspy und welche für FHEM sind. Die beiden abonnieren ja das selbe Topic (hermes/intent/+). Deswegen hat das Snips-Modul nur Intents mit Doppelpunkt verarbeitet. Alle anderen hat Snips (die Python Software) verarbeitet.
Mit Sende-/Empfangsrichtung hat das nichts zu tun. Geht nur um's Empfangen.

Die neue Version "behebt" das Problem, ja.

Ginge das nicht akkurater über "..[.]fhem[:_]"?

(Tappe da aber ziemlich im Nebel, nicht allzu ernst nehmen...)
Jedenfalls wollte Rudi den Doppelpunkt nicht (und ich selbst finde allgemein Sonderzeichen im Topic nicht gut).

Haben wir denn jetzt ein erntshaftes Problem oder eher nicht?

(Allg. Anmerkung noch: diese hart vercodeten Topics finde ich seltsam, aber vermutlich geht das nur mir so...?)

Könnte man natürlich so auch machen. Das "fhem" alleine sollte ja reichen. Das in Rhasspy zu ändern (also den Doppelpunkt rausnehmen) ist überhaupt kein Problem. Verstehe Rudis Ansicht vollkommen. Somit haben wir kein Problem :)

Das einzige Problem ist, dass die von dir verwendete Modul-Version nicht mehr die aktuellste war. Jetzt muss ich irgendwie rausfinden, wie ich das in GitHub richtig mergen kann ;)

Wie meinst du hart vercodeten Topics? Die drei @topics?

Mein Hirn versagt gerade, brauche nochmal deine Hilfe.

qr/^hermes\/intent\/.*[:_]/
filtert ja brav den Intent-Namen "de.fhem:GetTime"

Wie müsste es bei "de.fhem.GetTime" (ohne Doppelpunkt) heißen, wenn ich auf ".fhem." filtern will? Oder von mir aus "_fhem_" weil der Punkt in Regexen ja wieder schwierig ist?

...sollte normales regex sein. Mit sowas sollten sich alle Fälle erschlagen lassen:
qr/^hermes\/intent\/.*[._]fhem[.:_]/
Details siehe regex101.com.

Dann warte ich jetzt mal, bis du alles auf Stand hast.

Vermutlich ist es einfacher, ein diff zu erzeugen zwischen deiner github-Version und deiner aktuellsten und diesen dann in diese Fassung hier einzuarbeiten.

Ja, hätte ich auch geglaubt. Tut aber leider nicht.

Egal, ich führ das alles mal zusammen und kümmer mich dann darum.

https://github.com/drhirn/fhem-rhasspy/blob/testing/10_RHASSPY.pm

Das sieht jetzt mal sehr gut aus. Funktioniert soweit alles.
Was mir aber auffällt: Sobald ich das Rhasspy-Device definiere, aktualisiert sich FHEMWEB nicht mehr automatisch. Muss immer auf F5 drücken, um die aktuellen Readings/States/etc. zu sehen. Kennst du das Problem?

Keine Idee, was das für Einflüsse auf FHEMWEB haben könnte. Betrifft das nur das RHASSPY-Device oder allgemein? (Wenn ersteres: kann sein, dass da manche Readings nur aktualisiert werden, wenn MQTT als IO verwendet wird).

Ansonsten sollte es eher mit etwas anderem zu tun haben.

---

Mit "harten" topics war @topics gemeint, ja. Ist das immer richtig?

---

Generell: War das ein Startschuss in Richtung "bau 00_MQTT aus..."?
Vermutlich sollte man erst noch etwas testen, ich würde da noch etwas abwarten.

Zitat von: Beta-User am 20 Februar 2021, 11:53:10
Keine Idee, was das für Einflüsse auf FHEMWEB haben könnte. Betrifft das nur das RHASSPY-Device oder allgemein? (Wenn ersteres: kann sein, dass da manche Readings nur aktualisiert werden, wenn MQTT als IO verwendet wird).

Es ist definitiv das Rhasspy-Device schuld. Sobald ich das lösche, ist alles wieder normal.
Betrifft nicht nur Readings aus dem Rhasspy-Device, sondern alle anderen Devices auch. Irgendwas scheint das Longpolling/Websocket zu stören.
Passiert seit unseren Änderungen gestern.

Die @topics sind immer richtig, ja.

00_MQTT können wir schon ausbauen. Die 4 User, die das Modul verwenden haben ja noch die master-Branch zur Verfügung.

Die Branch 0.2.0 ist übrigens die aktuelle MQTT2_DEVICE Branch

Hmm, also:

- man braucht DateTime (steht das in der Doku, Debian: libdatetime-perl?)
- Hab's mal (aus einem Git) in mein Hauptsystem mit M2_SERVER gepackt und (ohne Gegenstelle) aktiviert/definiert. Geht, und longpoll ist auch weiter aktiv.

=> weiter keine Idee, was da schrägt hängt; wenn, dann hat es was mit der Kommunikation zwischen dem Dienst und M2C zu tun und dann sollte eigentlich FHEM komplett hängen. 
Gibt es Bestätigungen dazu von anderen? JensS liest ja auch mit...?

Wenn es ein Problem gibt, sollten wir Rudi dazu fragen, vermutlich am besten über einen separaten Thread in MQTT mit dem Verweis auf diesen Thread bzw. deinen anderen. (Dieser Arbeitstitel hier ist ziemlich "speziell"...)

Haha, du hast angefangen mit Vom-Thema-Ablenken :D

Ja, JensS hat auch angemerkt, dass die Readings nicht aktualisiert werden.

Ach ja, das mit DateTime hab ich vergessen zu dokumentieren. Da muss ich noch eine Lösung finden. Gefällt mir nicht, dass ich das brauche.

Ja, schaue hin und wieder rein.
Longpoll funktioniert bei mir auch noch nicht. Die elementaren Fuktionen laufen aber.
Gruß Jens

p.s. drhirn
Im Rhasspy-Thread meinte ich, dass das mute-reading nicht geschrieben wird und daher die mute-Funktion nicht funktioniert.

p.p.s. SetMute und nicht setMute - manchmal sind es die kleinen Dinge...

Bevor wir Rudi bemühen: Kannst du mal checken, ob alle bulkReading-updates sauber abgeschlossen werden?

Ich hab mal alle Updates auskommentiert bis auf ein SingleUpdate. Hat auch nicht funktioniert.
Kann ich das sonst irgendwie debuggen?

Übrigens: Ich bin dir sehr dankbar dafür, dass du dir die Arbeit antust!

Habe Rudi mal dazu angepingt, siehe https://forum.fhem.de/index.php/topic,118979.0.html - auch, falls ihr noch was anmerken wollt.

Die bulks habe ich mir auch ansgehen, das scheint es nicht gewesen zu sein...

Zitat von: drhirn am 20 Februar 2021, 16:49:20
Übrigens: Ich bin dir sehr dankbar dafür, dass du dir die Arbeit antust!

Gerne, aber die eine oder andere exemplarisch aufgezeigte Baustelle darfst du dann selber bearbeiten ;) .
Was das "Grundsätzliche" angeht: Wir werden vermutlich noch das eine oder andere "M2-Client+"-Modul benötigen, von daher ist das eben eine Art Prototyp... Und wer weiß, vielleicht schaue ich mir Rhasspy doch auch noch an, eine lokale Sprachsteuerungslösung ohne Cloud hat einen gewissen Reiz :) ...

Zitat von: Beta-User am 20 Februar 2021, 17:27:41
Gerne, aber die eine oder andere exemplarisch aufgezeigte Baustelle darfst du dann selber bearbeiten ;) .

Ich hab schon ein paar Sachen ausgebessert. Nur nicht in der 0.2.0 branch. perlcritics und ich sind schon Freunde geworden.

Zitat
Und wer weiß, vielleicht schaue ich mir Rhasspy doch auch noch an, eine lokale Sprachsteuerungslösung ohne Cloud hat einen gewissen Reiz :) ...

Ja, hat es. Geht rasant voran mit Rhasspy. Die Tatsache, dass alles Open Source ist, macht's noch interessanter.

Was hat dieser Thread eigentlich in den Anfängerfragen zu suchen?

Vielleicht noch ein paar Anmerkungen zum Modul an sich.

Angeschubst durch diese Regex auf "de.fhem": Man spricht deutsch...

Da gibt es zwei Punkte, die mAn. anders gelöst werden sollten, von daher ist es auch hilfreich, wenn betateilchen als "Wissender" hier mitliest ;D .

- Zum einen ist es generell ungeschickt, wenn diese ganzen Sprachschnipsel hart im Modul vercodet überall verteilt rumliegen, und
- zum anderen sollte man das so gestalten, dass man recht einfach die Sprache wechseln kann.

Meine Ideen (ohne Anspruch auf Vollständigkeit oder optimierte Gestaltung):
- die Textbausteine in einen Hash  packen und den zentral ablegen (irgendwo unter $hash->{helper})
- ein language-Attribut bzw. Internal vorzusehen (per default aus global zu füllen)
- den Internal-Wert dann bei der regex (${language}.fhem) mit berücksichtigen und beim Aufbau des Hashs
- Die Texte sollten dann außerhalb des Moduls abgelegt werden (separate config-file), das ganze dann so, dass configDB es auch versteht (FileRead nutzen und Internal .configfile setzen (?)). Am einfachsten vermutlich im JSON-Format (?). Dann können die User das separat bearbeiten und ggf. viel einfacher wechselseitig austauschen.

---

Ansonsten: Gibt es eigentlich irgendeinen Grund, warum das IODev in der DEF vercodet werden müßte? (Falls bei der Initialisierung irgendwas in Richtung IO zu schreiben ist, war es schon immer besser, damit zu warten, bis das auch sicher bereit ist, und zum anderen sollte das jetzt ohne weiteres in der (ggf. timerbasiert aufgerufenen) Startroutine erfolgen können; da ist dann auch das IODev-Attribut gelesen).

---

Soll der Ausbau von 00_MQTT eigentlich in der 0.2.0 erfolgen, oder baust du erst deine ausgebesserten Sache da ein und gibst Laut, wenn das erfolgt ist?

---

@betateilchen: Falls du irgendeine Idee hast, was longpoll beeinträchtigen könnte, wären wir daran interessiert... ::)

Uhhhh, du sprichst da ein Thema an, das sehr an mir nagt. Die Fixierung auf Deutsch stört mich auch gewaltig! Das war im Original-Modul (Snips) schon so. Und mir fehlt leider einfach noch das Perl-/FHEM-Wissen um das zu lösen. Deshalb habe ich zwar versucht, meine Erweiterungen mehrsprachig zu bauen (deswegen auch DateTime), wollte das Sprach-Thema aber erst mal auf später verschieben. Ich hoffe ja noch immer, dass die RHASSPY-Benutzerbasis breiter wird und sich irgendwann User finden, die auch noch FHEM verwenden und Perl-Wissen mitbringen ;).

---

IODev: Ehrlich? Ich weiß es nicht. Hatte das bisher nicht als Problem erkannt.

---

Ich hätte eine Version 0.2.1 gemacht

Bzgl. "de" nehme ich das mal auf die Liste für den Umbau und werde ggf. versuchen, ein paar "Planken" in die aufgezeigte Richtung einzubauen (falls nicht jemand Kompetenteres bessere Lösungen vorschlägt).

IODev aus DEF kannst du für 0.2.1 selbst ausbauen, oder?

---

Generell: Ich schreib' halt auf, was mir auffällt, das ist nicht böse gemeint, und muss auch nicht immer "richtig" (oder berechtigt) sein.
Es wäre ggf. besser, wenn du einen Developer-Status beantragst und wir das in der Developer-Ecke weiterdiskutieren (=> nochmal verschieben); da stolpert eher jemand drüber, der mehr Ahnung (ggf. auch zu einzelnen Aspekten) hat und dann weiterhelfen kann. Außerdem sind manche Themen vermutlich auch nicht so singulär, kann durchaus sein, dass der eine oder andere Developer da auch was "abgreifen" will.
Beispiele:
- das Sprachthema: da habe ich auch erst vor nicht allzu langer Zeit WDT auf "nimm was in global steht" umgebaut)
- Packages usw.: min und max sind immer wieder Stoplersteine, siehe https://forum.fhem.de/index.php/topic,118985.0.html (auch zu prototype mismatch).
(@JensS: Tester würde es auch tun und wäre m.E. auch passend).

Zitat von: Beta-User am 21 Februar 2021, 09:30:42
Bzgl. "de" nehme ich das mal auf die Liste für den Umbau und werde ggf. versuchen, ein paar "Planken" in die aufgezeigte Richtung einzubauen (falls nicht jemand Kompetenteres bessere Lösungen vorschlägt).

Cool! Danke!

Zitat
IODev aus DEF kannst du für 0.2.1 selbst ausbauen, oder?

Wir werden sehen. Ich kann's mal versuchen.

Zitat
Generell: Ich schreib' halt auf, was mir auffällt, das ist nicht böse gemeint, und muss auch nicht immer "richtig" (oder berechtigt) sein.

Keine Sorge, ich nehm dir das ganz sicher nicht übel. Ganz im Gegenteil.
Nur mein 3D-Drucker. Der ist sauer, weil ich das Wochenende nicht - wie geplant - mit ihm verbringe ;)

Zitat
Es wäre ggf. besser, wenn du einen Developer-Status beantragst und wir das in der Developer-Ecke weiterdiskutieren

Hmpf, das wollte ich eigentlich vermeiden. Ich weiß nicht, ob ich mit der Verantwortung umgehen kann ;). Aber ich schau mir mal die Voraussetzungen an.

Zitat von: JensS am 20 Februar 2021, 21:15:35
Irgendwie wird mein ResponseOnOff($DEVICE) nicht mehr ausgeführt.
https://forum.fhem.de/index.php/topic,113180.msg1119611.html#msg1119611 (https://forum.fhem.de/index.php/topic,113180.msg1119611.html#msg1119611)
Es dauert lange, bis der Befehl ausgeführt wird. Ein Response findet nicht statt.

Will mich nicht in den anderen Thread einklinken, daher hier bzgl. $main:
Schnellerer Würgaround wäre, Doppelpunkte vor die Funktion zu setzen.
Also in das Attribut zu schreiben:
::ResponseOnOff($DEVICE)

Die mAn. korrekte Fassung wäre, in RHASSPY_execute() erst EvalSpecials aufzurufen, um die drei Variablen aufzulösen und das ganze dann an
AnalyzePerlCommand() zu übergeben. Damit wäre man indirekt dann wieder im main-Kontext. Volle Version zum Testen folgt...

Hui, also für Einsteiger ist die DevelopmentModuleAPI Seite im Wiki nichts ;)

Kann dem nicht unbedingt beipflichten, aber vermutlich ist es so, dass es bei jedem Mal besser wird ;) .

Kannst du "AnalyzePerlCommand" in den Import mit aufnehmen und dann das hier mal testen:

sub RHASSPY_execute {
    my $hash   = shift // return;
    my $device = shift // carp q[No target device provided!] && return;
    my $cmd    = shift // carp q[No command provided!]       && return;
    my $value  = shift // carp q[No value provided!]         && return;
    my $siteId = shift // $hash->{helper}{defaultRoom};
    $siteId = $hash->{helper}{defaultRoom} if $siteId eq "default";


    # Nutervariablen setzen
    my %specials = (
         '$DEVICE' => $device,
         '$VALUE'  => $value,
         '$ROOM'   => $siteId
    );
    for my $special (keys %specials) {
      $special =~ s{\$}{\\\$}gxms; 
      $cmd     =~ s{$special}{$specials{$special}}gxms;
    }

    # CMD ausführen
    #my $returnVal = eval $cmd;
    return AnalyzePerlCommand( $hash, $cmd );
}

Jetzt wird mir das Mapping vorgelesen :D


PERL WARNING: Use of uninitialized value within %specials in substitution iterator at ./FHEM/10_RHASSPY.pm line 279.
2021.02.22 11:31:22.387 1: ERROR evaluating {ResponseOnOff()}: Not enough arguments for main::ResponseOnOff at (eval 615) line 1, near "()"


Da fehlt das "$DEVICE" zwischen den Klammern.

...auch nicht unbedingt mein Spezialgbiet...

Hier noch ein Versuch mit EvalSpecials (=>Import):
sub RHASSPY_execute {
    my $hash   = shift // return;
    my $device = shift // carp q[No target device provided!] && return;
    my $cmd    = shift // carp q[No command provided!]       && return;
    my $value  = shift // carp q[No value provided!]         && return;
    my $siteId = shift // $hash->{helper}{defaultRoom};
    $siteId = $hash->{helper}{defaultRoom} if $siteId eq "default";


    # Nutervariablen setzen
    my %specials = (
         '%DEVICE' => $device,
         '%VALUE'  => $value,
         '%ROOM'   => $siteId
    );
   
    $cmd  = EvalSpecials($cmd, %specials);
 
    # CMD ausführen
    #my $returnVal = eval $cmd;
    return AnalyzePerlCommand( $hash, $cmd );
}

Mal ein paar erste Versuche noch zum Thema $language...

Leider kann ich mal wieder nicht viel mehr sagen wie: es läßt sich laden ::) .

Edit: jetzt mit Anhang...

Zitat von: Beta-User am 22 Februar 2021, 11:51:56
Hier noch ein Versuch mit EvalSpecials (=>Import):

Der funktioniert! Danke!

Sprache sehe ich mir gleich an. Wo würdest du da die unterschiedlichen Ausdrücke platzieren? In %languagevars nehm ich an?

Zitat von: drhirn am 22 Februar 2021, 13:29:15
Der funktioniert! Danke!

Ufff...

Zitat
Sprache sehe ich mir gleich an. Wo würdest du da die unterschiedlichen Ausdrücke platzieren? In %languagevars nehm ich an?

Jein...

Damit wollte ich erst mal eine Art Machbarkeitsanalyse vorbereiten mit wenigen Elementen, wobei ich mir auch mit der Struktur noch unsicher bin:
Es gibt ja da nicht nur Sätze, die zurückgegeben werden, sondern auch ein paar regexe, die passen müssen (z.B. "lauter|leiser" für "Lautstärke"). Diese müssen auch irgendwo abgelegt sein und dynamisch verwendet werden. (Der Code sieht um das Suchwort "Lautstärke" herum aber auch - unabhängig von der Sprache - irgendwie provisorisch aus).

Mittelfristig sollte dann dieser Hash woanders herkommen:

Zitat von: Beta-User am 21 Februar 2021, 08:41:56
Meine Ideen (ohne Anspruch auf Vollständigkeit oder optimierte Gestaltung):
- die Textbausteine in einen Hash  packen und den zentral ablegen (irgendwo unter $hash->{helper})
- ein language-Attribut bzw. Internal vorzusehen (per default aus global zu füllen)
- den Internal-Wert dann bei der regex (${language}.fhem) mit berücksichtigen und beim Aufbau des Hashs
- Die Texte sollten dann außerhalb des Moduls abgelegt werden (separate config-file), das ganze dann so, dass configDB es auch versteht (FileRead nutzen und Internal .configfile setzen (?)). Am einfachsten vermutlich im JSON-Format (?). Dann können die User das separat bearbeiten und ggf. viel einfacher wechselseitig austauschen.

Der Code sollte bis hierher erst mal nur den 2. Spiegelstrich erfüllen, ohne dass die Funktionalität leidet, da, wo jetzt statt des harten "de" $language bzw. ${language} steht...
Nächster Schritt wäre dann, alle "de"-Vorkommen durch die Variable zu ersetzen.
Erst danach würde man den Hash füllen und beginnen, die lookups einzubauen, und dann ist es auch schon nicht mehr weit, dass man dann auch andere Sprachen unterstützen würde... 8)
(Es sei denn, jemand hat eine bessere/cleverere Idee und/oder man könnte das (in Teilen?) schon woanders finden?)

Verstehe. Also, ich kann berichten: Es funktioniert mal nichts nicht. Die Slots/Sentences werden wie erwartet jetzt mit "en.fhem.xxx" benannt. Ansonsten tu ich mir mit dem Testen gerade ein bisschen schwer. Da muss ich mir in einer Pause etwas überlegen.

Darf ich dich bitten, mal die aktuelle testing-Branch runter zu laden und dort weiter zu machen. Da sind auch sonst noch ein paar kleine Änderungen von mir dabei. Würde mir das Zusammenführen einfacher machen.

"updateSlots" funktioniert so nicht.

$deviceData =qq({"intents/$language.fhem.Shortcuts.ini":"[$language.fhem:Shortcuts]\n); geht nicht

$deviceData='{"intents/'.$language.'.fhem.Shortcuts.ini":"['.$language.'.fhem:Shortcuts]\n'; das geht

Das explizite concat gefällt mir noch nicht so recht... Kannst du mal noch das hier testen:
$deviceData =qq({"intents/${language}.fhem.Shortcuts.ini":"[${language}.fhem:Shortcuts]\n);

2. Nachtrag: Und dann gleich noch das:
      $deviceData->{qq(${language}.fhem.Device)} = \@devices if @devices;


Sorry, den hatte ich erst übersehen...

Zitat von: drhirn am 22 Februar 2021, 14:19:08Verstehe. Also, ich kann berichten: Es funktioniert mal nichts nicht. Die Slots/Sentences werden wie erwartet jetzt mit "en.fhem.xxx" benannt. Ansonsten tu ich mir mit dem Testen gerade ein bisschen schwer. Da muss ich mir in einer Pause etwas überlegen.

Ziel sollte wie gesagt erst mal sein, dass "de" weiter funktioniert wie gehabt. Dann bauen wir ggf. den Hash (für de) auf, und erst danach könnten/sollten wir uns mit "en" beschäftigen, da gibt es im Moment ja nichts, was wir testen könnten.

ZitatDarf ich dich bitten, mal die aktuelle testing-Branch runter zu laden und dort weiter zu machen. Da sind auch sonst noch ein paar kleine Änderungen von mir dabei. Würde mir das Zusammenführen einfacher machen.

...hab's mal versucht, gleich 00_MQTT.pm ausgebaut und verwurstelt, was mit spontan vor die Flinte gelaufen ist...

$deviceData =qq({"intents/${language}.fhem.Shortcuts.ini":"[${language}.fhem:Shortcuts]\\n);

So geht's. Der letzte Backslash musste noch escaped werden. Der muss im "Klartext" übermittelt werden.

Ansonsten funktioniert alles.

$language sollten wir aber wo anders definieren. Kann ja sein, dass man das im laufenden Betrieb ändern will. Im Moment wird sie aber nur bei der ersten Initialisierung des Moduls gesetzt. Da bin ich gerade drauf rein gefallen ;).
Ich hätte das gleich am Anfang gemacht. Dort wo jetzt my $language = 'en'; steht. Wie verpönt wäre das?

Und ich frage mich gerade, ob es nicht schlauer wäre, die Sprache in der DEF des Moduls zu bestimmen. Sonst vergessen alle, eines der Attribute zu setzen. Was meinst du?

Zitat von: drhirn am 22 Februar 2021, 17:26:04
Ansonsten funktioniert alles.

8)
Sehr cool, Danke für die Rückmeldung!

Was $language angeht:
- Die Variable wird (hoffentlich) beim Starten aktualisiert, entsprechend der gesetzten Attribute (erst Device, dann global, wenn da nichts steht auf "en", entsprechend der von dir zitierten Setzung);
- wenn man das Attribut setzt, wird aktualisiert;
- wenn man das Attribut löscht, wird ebenfalls aktualisiert. (?)

Die "Lücke" entsteht, wenn man es später in global ändert. Halte ich für verschmerzbar, ggf. muss man halt die DEF anfassen (Leerzeichen), dann wird auch wieder alles aktualisiert, oder?

M.E. wäre es zielführend, wenn (auch) RHASSPY den user etwas dahingehend (=>cref) leitet, dass man die Grundeinstellungen in global passend setzt; wer es mehrsprachig braucht/will, kann dann am Device was verändern (und ggf. auch aktiv danach suchen). Hat z.B. auch Auswirkungen auf WDT und cref-Sprache.

Ansonsten bin ich kein Freund von "Doppeloptionen", sonst muss man nur erklären, wie die Prio ist (es gibt sowas bei Twilight, aber da teilweise aus historischen Gründen).

Wir brauchen auf alle Fälle eine Logik, die erlaubt, den Hash im laufenden Betrieb neu einzulesen, ggf. braucht es einen setter/Perl-Command dafür (damit man ggf. auch testen kann...)

Haben wir schon alle "de"-Stellen erwischt?
(Wenn nein, bitte den konsolidierten aktuellen Code nach github laden).

Wenn ja, sollten wir mal versuchen, eine Response dynamisch aufzubauen. Würde für die Zeitabfrage votieren...?

Zitat von: JensS am 22 Februar 2021, 17:36:03
Nachdem ich gestern Abend die 0.2.0 getestet habe, wurde mein Logfile (./log/Rhasspy_Intent.log Rhasspy:lastIntentPayload.*) nicht weiter gefüllt.
Es scheint, als wurde kein Event ausgelöst.
Gruß Jens

Habe ich gesehen, kann aber im Moment nicht zuordnen, was die Rückmeldung bedeutet und ob das noch aktuell ist...?
(@JensS: Tester? @drhirn hat sich auch schon mit dem "developer" "angefreundet"... :P )

Ich hatte global auf DE. RHASSPY hab ich von EN auf DE gesetzt. Es hat mir trotzdem EN genommen. Erst nach einem FHEM-Neustart hat's gepasst. Muss das aber noch genauer testen.

Muss für heute nur leider aufgeben. Aktueller Stand ist auf GitHub (testing).

Danke dir nochmal!

Das language-Problem hing mit der Parameterübergabe zusammen, beim Löschen wird als Attributwert nichts übergeben, so wäre es richtig:
# Attribute setzen / löschen
sub RHASSPY_Attr {
    my $command = shift;
    my $name = shift;
    my $attribute = shift // return;
    my $value = shift;


Ok, danke!
Dann  muss ich jetzt eine Frage stellen, die mir eine Internet-Recherche nicht beantworten konnte: Was bedeutet "//"? Und "// return" im Speziellen?

Kurzform
my $attribute = shift // return;

Langform
my $attribute = shift;
return if (!defined($attribute));

Ahhhh, danke!

Gar nicht so leicht, nach "//" zu suchen.

Habe im Code auch ein paar Anmerkungen verteilt. Eine davon:
# Device anlegen
sub RHASSPY_Define { my $hash = shift;
    my $def  = shift // return; #Beta-User: Perl defined-orMit diesem Schlagwort hättest du wohl auch  dann was im Inet gefunden ;) . (Und du kannst die dann ruhig rauslöschen, wenn du es "zur Kenntnis genommen" hast...)

Man kann da auch mehrere Funktionen dahinter schreiben oder die die defined-or-Abfragen verketten (letzteres werden wir evtl. noch brauchen...)

Zwei Funktionen bei !defined:
    my $device = shift // carp q[No target device provided!] && return;


Ich dachte, das war als Hinweis gedacht, dass du mein if (defined... rausgelöscht hast  :-[

Zitat von: Beta-User am 23 Februar 2021, 07:58:03
Das language-Problem hing mit der Parameterübergabe zusammen, beim Löschen wird als Attributwert nichts übergeben, so wäre es richtig:

Code Auswählen Erweitern

# Attribute setzen / löschen
sub RHASSPY_Attr {
    my $command = shift;
    my $name = shift;
    my $attribute = shift // return;
    my $value = shift;


Ich musste das Device zuerst löschen und neu anlegen, damit er die Änderungen im Attribut übernommen hat. Jetzt kann ich im laufenden Betrieb ändern.

Zitat von: drhirn am 23 Februar 2021, 08:33:35
Ich dachte, das war als Hinweis gedacht, dass du mein if (defined... rausgelöscht hast

...dafür gibt's "diff"-Werkzeuge ::) , aber ich hätte ja auch eine Bedienungsanleitung schreiben können (wenn es die schon gegeben hätte, manches hat sich halt auch einfach so ergeben im Lauf der Zeit ::) .)

Anbei jetzt eine Version, die bei Dispatch was zurückliefert. Ganz 100% glücklich bin ich noch nicht, weil das bisher "nur" der Name der verarbeiteten RHASSPY-Instanz ist (hoffentlich, mit zweien habe ich nicht getestet...), und es eigentlich effizienter sein dürfte, auch gleich die veranlassten Änderungen an "untergeordneten" Devices mit abzufrühstücken. Dazu müßte man die aber irgendwie durch den Code rückwärts verfolgen (intent?).

Wenn das mit dem longpoll dann wieder funktioniert (Test bei mir sah auf den ersten Blick gut aus), könnten wir das mit dem Sprachhash dann mal angehen...

Das Ergebnis ist durchwachsen. Ich habe zwei Browser-Fenster offen. Eines mit dem Rhasspy-Device, eines mit dem Raum RHASSPY (in dem die zu schaltenden Devices - Deckenlampe + Radio - sind).
Die Readings des Rhasspy-Devices werden jetzt wieder aktualisiert.
Der Status von Deckenlampe und Radio bleibt aber der selbe. Ändert sich nur, wenn ich die Seite aktualisiere.

Habe mit forceNEXT 0 und 1 getestet

Hier das Log:

2021.02.23 14:03:59.072 5: rhasspyMQTT2: dispatch autocreate=no\000rhasspyMQTT2\000hermes/dialogueManager/sessionStarted\000{"sessionId": "wohnzimmer-snowboy-64242b0e-c8a2-4237-929c-f2aba9c4e925", "siteId": "wohnzimmer", "customData": "snowboy", "lang": null}
2021.02.23 14:03:59.073 5: RHASSPY: [Rhasspy] Parse (IO: rhasspyMQTT2): Msg: hermes/dialogueManager/sessionStarted => {"sessionId": "wohnzimmer-snowboy-64242b0e-c8a2-4237-929c-f2aba9c4e925", "siteId": "wohnzimmer", "customData": "snowboy", "lang": null}
2021.02.23 14:03:59.073 5: Parsed value: wohnzimmer for key: siteId
2021.02.23 14:03:59.073 5: Parsed value: wohnzimmer-snowboy-64242b0e-c8a2-4237-929c-f2aba9c4e925 for key: sessionId
2021.02.23 14:03:59.073 5: Starting notify loop for Rhasspy, 1 event(s), first is listening_wohnzimmer: 1
2021.02.23 14:03:59.074 5: End notify loop for Rhasspy
2021.02.23 14:04:02.566 5: rhasspyMQTT2: dispatch autocreate=no\000rhasspyMQTT2\000hermes/intent/de.fhem_SetOnOff\000{"input": "deckenlampe aus", "intent": {"intentName": "de.fhem:SetOnOff", "confidenceScore": 1.0}, "siteId": "wohnzimmer", "id": null, "slots": [{"entity": "de.fhem.Device", "value": {"kind": "Unknown", "value": "deckenlampe"}, "slotName": "Device", "rawValue": "deckenlampe", "confidence": 1.0, "range": {"start": 0, "end": 11, "rawStart": 0, "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": "wohnzimmer-snowboy-64242b0e-c8a2-4237-929c-f2aba9c4e925", "customData": null, "asrTokens": [[{"value": "deckenlampe", "confidence": 1.0, "rangeStart": 0, "rangeEnd": 11, "time": null}, {"value": "aus", "confidence": 1.0, "rangeStart": 12, "rangeEnd": 15, "time": null}]], "asrConfidence": null, "rawInput": "deckenlampe aus", "wakewordId": "snowboy", "lang": null}
2021.02.23 14:04:02.567 5: RHASSPY: [Rhasspy] Parse (IO: rhasspyMQTT2): Msg: hermes/intent/de.fhem_SetOnOff => {"input": "deckenlampe aus", "intent": {"intentName": "de.fhem:SetOnOff", "confidenceScore": 1.0}, "siteId": "wohnzimmer", "id": null, "slots": [{"entity": "de.fhem.Device", "value": {"kind": "Unknown", "value": "deckenlampe"}, "slotName": "Device", "rawValue": "deckenlampe", "confidence": 1.0, "range": {"start": 0, "end": 11, "rawStart": 0, "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": "wohnzimmer-snowboy-64242b0e-c8a2-4237-929c-f2aba9c4e925", "customData": null, "asrTokens": [[{"value": "deckenlampe", "confidence": 1.0, "rangeStart": 0, "rangeEnd": 11, "time": null}, {"value": "aus", "confidence": 1.0, "rangeStart": 12, "rangeEnd": 15, "time": null}]], "asrConfidence": null, "rawInput": "deckenlampe aus", "wakewordId": "snowboy", "lang": null}
2021.02.23 14:04:02.567 5: Parsed value: wohnzimmer-snowboy-64242b0e-c8a2-4237-929c-f2aba9c4e925 for key: sessionId
2021.02.23 14:04:02.567 5: Parsed value: deckenlampe aus for key: input
2021.02.23 14:04:02.567 5: Parsed value: 1 for key: probability
2021.02.23 14:04:02.568 5: Parsed value: wohnzimmer for key: siteId
2021.02.23 14:04:02.568 5: Parsed value: SetOnOff for key: intent
2021.02.23 14:04:02.568 5: Parsed value: deckenlampe for key: Device
2021.02.23 14:04:02.568 5: Parsed value: deckenlampe aus for key: rawInput
2021.02.23 14:04:02.568 5: Parsed value: aus for key: Value
2021.02.23 14:04:02.569 5: handleIntentSetOnOff called
2021.02.23 14:04:02.569 5: Device selected: lampe1
2021.02.23 14:04:02.569 5: rhasspyMapping selected: cmdOn=on,cmdOff=off
2021.02.23 14:04:02.569 5: Cmd: >set lampe1 off<
2021.02.23 14:04:02.569 4: dummy set lampe1 off
2021.02.23 14:04:02.570 5: Running command [off] on device [lampe1]
2021.02.23 14:04:02.570 5: Starting notify loop for Rhasspy, 4 event(s), first is lastIntentTopic: hermes/intent/de.fhem_SetOnOff
2021.02.23 14:04:02.570 5: End notify loop for Rhasspy
2021.02.23 14:04:03.400 5: rhasspyMQTT2: dispatch autocreate=no\000rhasspyMQTT2\000hermes/dialogueManager/sessionEnded\000{"termination": {"reason": "nominal"}, "sessionId": "wohnzimmer-snowboy-64242b0e-c8a2-4237-929c-f2aba9c4e925", "siteId": "wohnzimmer", "customData": "snowboy"}
2021.02.23 14:04:03.400 5: RHASSPY: [Rhasspy] Parse (IO: rhasspyMQTT2): Msg: hermes/dialogueManager/sessionEnded => {"termination": {"reason": "nominal"}, "sessionId": "wohnzimmer-snowboy-64242b0e-c8a2-4237-929c-f2aba9c4e925", "siteId": "wohnzimmer", "customData": "snowboy"}
2021.02.23 14:04:03.401 5: Parsed value: wohnzimmer-snowboy-64242b0e-c8a2-4237-929c-f2aba9c4e925 for key: sessionId
2021.02.23 14:04:03.401 5: Parsed value: wohnzimmer for key: siteId
2021.02.23 14:04:03.401 5: Starting notify loop for Rhasspy, 1 event(s), first is listening_wohnzimmer: 0
2021.02.23 14:04:03.401 5: End notify loop for Rhasspy


Ich gehe jetzt mal davon aus, dass es immer nur EINE verarbeitende Instanz gibt. Mehr macht keinen Sinn. Und wenn doch, wären das wahrscheinlich zwei unterschiedliche MQTT2_CLIENTs.

OK, dann ist das "richtig", was in der Anmerkung steht:
#Beta-User: return value should be reviewed. If there's an option to return the name of the devices triggered by Rhasspy, then this could be a better option than just RHASSPY's own name.

Bedeutet, wir müssen diese Gerätenamen irgendwie "durchschleusen"...
Anbei der Versuch, das exemplarisch für onOff-Devices zu implementieren. Damit sollte "lampe1" "rot leuchten" ;D .

Edit: "forceNEXT" hat nur was mit anderen Modulen zu tun, nicht irritieren lassen...

Leider keine guten Nachrichten. Hat nichts geändert.
Mal abgesehen davon, dass SetOnOff den Zustand schaltet, nicht GetOnOff.

Aber ich verstehe gerade nicht ganz, was du vor hast. Wie da was heißt, ist ja eigentlich nicht relevant. Oder? Das Modul hat schon bisher den rhasspyName dem richtigen Device-Name zugeordnet. Und das FHEM-Device wird ja auch geschalten.

...wer lesen kann ist im Vorteil, das "Get" ist mir im Eifer grade raus...

War eh' an dem "%umlauts" dran, dann kannst du das auch gleich mit testen, selbst wenn es nichts hilft, das $device zurückzuliefern (falls du es auch bei set eingebaut hattest).

Der Punkt mit der Rückgabe ist (nach meinem möglicherweise noch unvollständigen Verständnis) der: Der "matching-Mechanismus" ist bei MQTT_DEVICE und bei MQTT2_DEVICE ein grundlegend anderer. MQTT_DEVICE (und Derivate wie RHASSPY, MQTT_BRIDGE oder MYSENSORS_DEVICE (das senselben matching-Mechanismus nutzt), arbeiten an Dispatch vorbei, was mAn. OK ist, solange sowieso nur einzelne Readings an einzelnen Devices ein update bekommen).
Wärend man "in Dispatch" ist, scheint die Eventverarbeitung angehalten zu sein und das Modul, das per Dispatch aufgerufen wurde, muss eine (vollständige...) Liste aller Devices zurückliefern, die es upgedatet hat sowie die Info, ob ggf. versucht werden soll, die Info noch an weitere Client-Module weiterzugeben (hier also MGB oder MQTT2_DEVICE), damit die das auch noch auswerten können.

Ich glaub, das %umlauts brauchen wir gar nicht mehr. Hab das eh durch "makeReadingName" ersetzt. Nur noch nicht genügend getestet.

Odd number of elements in anonymous hash at ./FHEM/10_RHASSPY.pm line 55
Can't use an undefined value as a HASH reference at ./FHEM/10_RHASSPY.pm line 930

Zeile 55:
my %languagevars = (

Zeile 930:
my %mutated_vowels = \%languagevars{$language}->{mutated_vowels};

Zitat von: drhirn am 23 Februar 2021, 15:30:29
Ich glaub, das %umlauts brauchen wir gar nicht mehr. Hab das eh durch "makeReadingName" ersetzt. Nur noch nicht genügend getestet.

Na ja, sollte auch nur erläutern, wie das Prinzip gedacht war; aber wenn es eh' nicht funktioniert, ist es ggf. besser, das an der Stelle asap (ganz) auszubauen.

Stellt sich nur die Frage, wie das auf Französisch klappen soll ::) . Dazu steht in "makeReadingName" noch nichts...

Kannst du mir eine passende topic-message-Kombi (sowie ggf. ein passendes RAW-Device zum Schalten) zum Testen zukommen lassen, ich würde das gerne zum Laufen bringen ;) . Mit meinem Test-Publish kam da nicht viel rum außer ein paar "uninitialized"-Warnungen mit anderer Ursache, fix anbei...

Zeile 55 läuft hier (auch vorher) anstandslos durch (Perl 5.32.1), da habe ich im Moment noch keine Idee; 5.28 teste ich bei Gelegenheit.

Du kannst (fast) alles von mir haben. Ich schulde dir ja inzwischen schon mindestens einen halben LKW voll Bier. ;)

FHEM hat kaum englischsprachige User. Sollte da irgendwann ein Franzose auftauchen, können wir uns darum immer noch Gedanken machen ;).

Ein RAW-Device:

defmod lampe2 dummy
attr lampe2 rhasspyMapping SetOnOff:cmdOn=on,cmdOff=off\
GetOnOff:currentVal=state,valueOff=off
attr lampe2 rhasspyName lampe,radio
attr lampe2 rhasspyRoom wohnzimmer,schlafzimmer
attr lampe2 room Rhasspy
attr lampe2 setList toggle on off


Was du mit topic-message-Kombi meinst, ist mir nicht ganz klar. Sowas?
Msg: hermes/intent/de.fhem_SetOnOff => {"input": "radio an", "intent": {"intentName": "de.fhem:SetOnOff", "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": "OnOffValue", "value": {"kind": "Unknown", "value": "an"}, "slotName": "Value", "rawValue": "ein", "confidence": 1.0, "range": {"start": 6, "end": 8, "rawStart": 6, "rawEnd": 9}}], "sessionId": "wohnzimmer-snowboy-009282bf-8a7d-4e2b-937f-fa6a15d83268", "customData": null, "asrTokens": [[{"value": "radio", "confidence": 1.0, "rangeStart": 0, "rangeEnd": 5, "time": null}, {"value": "an", "confidence": 1.0, "rangeStart": 6, "rangeEnd": 8, "time": null}]], "asrConfidence": null, "rawInput": "radio ein", "wakewordId": "snowboy", "lang": null}

Perl-technisch bist du weit vor mir. Die Docker-Version hat 5.028001. Könnte ein Grund sein.

Hmm, ok, dann muss ich wohl mal downgraden... Hatte jetzt eher vermutet, dass 5.32.x Probleme macht, weil "will be fatal in ..." da true ist :) . (es gab da ein paar verdächtige regexe, "unescaped left brace..." und so...)

lampe2 bekomme ich mit RHASSPY geschaltet, "longpoll-los", versteht sich, es steht NIX im log (verbose 3). Aber damit kann ich zumindest das durchreichen versuchen nachzuvollziehen.

Bzgl. Fremdsprachen: https://forum.fhem.de/index.php/topic,119044.0.html
(Es geht da wirklich eher darum, gewisse Optionen generell vorzusehen, die dann ggf. "recht einfach" von den Usern angepaßt werden können, wenn man sie denn braucht; der Aufwand, das zu implementieren, sollte halt im Rahmen bleiben. Ein zentraler Hash hat zudem den Vorteil, dass man das auch einfacher pflegen kann, wie wenn es überall verstreut ist).

Dass die Franzosen immer davon ausgehen, dass man sie eh versteht, fasziniert mich schon einigermaßen... :D

Aber du rennst diesbezüglich bei mir offene Türen ein. Ich seh das einfach nur als "Verbesserung". Priorität hat bei mir derzeit eher "Fehlerfreiwerdung".

Nachdem es mir auch gelungen ist, FHEM mit passender Testsmessage abzuschießen, vorab erst mal  eine, bei der das zumindest auf dem 5.32.1 dann nicht mehr passiert war, hoffe, das ist auch 5.28-kompatibel... (da ist trotzdem ein 1-er Warning im Log, aber darum können wir uns später kümmern).

Da ist jetzt am Ende von Parse eine Zeile drin, die uns ins log schreibt, was denn von Parse() zurückgeliefert wird. Bei MGB ist es der Name (bzw. die Namen) des angesteuerten Devices, und so sollte das auch hier sein. Wäre nett, wenn du das kurz testen könntest.

Guten Morgen!

Stürzt jetzt nicht mehr ab.

Hier das Rhasspy-Log:

2021.02.24 08:08:29.091 5: Parsed value: wohnzimmer-snowboy-d7762105-c690-44bd-9b39-61d92274ad69 for key: sessionId
2021.02.24 08:08:29.091 5: Parsed value: wohnzimmer for key: siteId
2021.02.24 08:08:29.091 5: mutated_vowels regex is SCALAR(0x5605cc54fe10)
2021.02.24 08:08:29.092 5: RHASSPY: [Rhasspy] Parse returned ARRAY(0x5605cc62e000)
2021.02.24 08:08:32.186 5: RHASSPY: [Rhasspy] Parse (IO: rhasspyMQTT2): Msg: hermes/intent/de.fhem_SetOnOff => {"input": "deckenlampe an", "intent": {"intentName": "de.fhem:SetOnOff", "confidenceScore": 1.0}, "siteId": "wohnzimmer", "id": null, "slots": [{"entity": "de.fhem.Device", "value": {"kind": "Unknown", "value": "deckenlampe"}, "slotName": "Device", "rawValue": "deckenlampe", "confidence": 1.0, "range": {"start": 0, "end": 11, "rawStart": 0, "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": "wohnzimmer-snowboy-d7762105-c690-44bd-9b39-61d92274ad69", "customData": null, "asrTokens": [[{"value": "deckenlampe", "confidence": 1.0, "rangeStart": 0, "rangeEnd": 11, "time": null}, {"value": "an", "confidence": 1.0, "rangeStart": 12, "rangeEnd": 14, "time": null}]], "asrConfidence": null, "rawInput": "deckenlampe ein", "wakewordId": "snowboy", "lang": null}
2021.02.24 08:08:32.186 5: Parsed value: wohnzimmer-snowboy-d7762105-c690-44bd-9b39-61d92274ad69 for key: sessionId
2021.02.24 08:08:32.187 5: Parsed value: wohnzimmer for key: siteId
2021.02.24 08:08:32.187 5: Parsed value: an for key: Value
2021.02.24 08:08:32.187 5: Parsed value: SetOnOff for key: intent
2021.02.24 08:08:32.187 5: Parsed value: deckenlampe for key: Device
2021.02.24 08:08:32.187 5: Parsed value: 1 for key: probability
2021.02.24 08:08:32.187 5: Parsed value: deckenlampe an for key: input
2021.02.24 08:08:32.187 5: Parsed value: deckenlampe ein for key: rawInput
2021.02.24 08:08:32.188 5: handleIntentSetOnOff called
2021.02.24 08:08:32.188 5: Device selected: lampe1
2021.02.24 08:08:32.188 5: rhasspyMapping selected: cmdOn=on,cmdOff=off
2021.02.24 08:08:32.188 5: Running command [on] on device [lampe1]
2021.02.24 08:08:32.189 5: RHASSPY: [Rhasspy] Parse returned ARRAY(0x5605cc781420)
2021.02.24 08:08:32.979 5: RHASSPY: [Rhasspy] Parse (IO: rhasspyMQTT2): Msg: hermes/dialogueManager/sessionEnded => {"termination": {"reason": "nominal"}, "sessionId": "wohnzimmer-snowboy-d7762105-c690-44bd-9b39-61d92274ad69", "siteId": "wohnzimmer", "customData": "snowboy"}
2021.02.24 08:08:32.979 5: Parsed value: wohnzimmer for key: siteId
2021.02.24 08:08:32.979 5: Parsed value: wohnzimmer-snowboy-d7762105-c690-44bd-9b39-61d92274ad69 for key: sessionId
2021.02.24 08:08:32.979 5: mutated_vowels regex is SCALAR(0x5605cc54fe10)
2021.02.24 08:08:32.980 5: RHASSPY: [Rhasspy] Parse returned ARRAY(0x5605cc62d670)


Hmm, irgendwo ging $device verloren, da war so eine "definiere mal vorsorglich ein paar Variablen"-Orgie im Weg...
So triggern dann auch wieder die Updates am Zieldevice.

Dann gibt es eine "sort_unique", könnte man vermutlich ausbauen, um das ganze gleich mit länger vor kürzer zu bekommen...? (Falls es auch in größerem Maßstab funktioniert => auch an anderer Stelle "recyceln").

Den Hash-lookup habe ich erst mal deaktiviert, damit keiner Anlass hat, sich über unnötige Logeinträge zu beschweren.

Irgendwie bin ich grade am überlegen, ob es jetzt nicht an der Zeit wäre, onmessage() (teilweise?) in Parse() zu integrieren, aber onmessage ist angeblich schon "high complexity", von daher sollte man das wohl eher zwar tun, dabei aber die Sache eher vereinfachen (durch Aufruf "speziellerer" Subs)...

Tendenziell würde ich mich jetzt erst mal wieder zurückhalten und mal abwarten, was dir selbst zum Code noch einfällt (unterstellt, das funktioniert erst mal alles soweit wieder zur Zufriedenheit)?

Hm, einen habe ich doch noch, nämlich das mit der anonymen sub in RHASSPY_ReplaceReadingsVal()...

Auch das scheint zu funktionieren, viel mehr weiß ich mal wieder nicht ::) .

Woooooow, jetzt funktioniert's wirklich wieder. Das Update der Devices mein ich.  Danke! 8)

Meine To-Dos sind momentan:

1. überlegen, was ich zu Mittag esse
2. versuchen, deine ganzen Verbesserungen zu verstehen
3. den Timer verbessern
4. überprüfen, warum die FHEM-Befehle bei Shortcuts nicht mehr ausgeführt werden
5. Code aufräumen

Dazu eine Frage:
Wenn ich da wirklich siteIDs auslesen soll, wie das im anderen Thread überlegt wurde, sollte ich das fast bei Initalisierung des Moduls machen. Wie verpönt ist das? Und wie gehe ich das am Besten (=FHEM konformsten) an?

Zitat von: Beta-User am 24 Februar 2021, 12:24:20
Hm, einen habe ich doch noch, nämlich das mit der anonymen sub in RHASSPY_ReplaceReadingsVal()...

Haha, perfekt! Die wollte ich auch schon mal angehen. Aber keine Ahnung, was die tut. Jetzt erspar ich mir das :D

Zitat von: drhirn am 24 Februar 2021, 12:26:33
Woooooow, jetzt funktioniert's wirklich wieder. Das Update der Devices mein ich.  Danke! 8)

Danke für die Rückmeldung!

Dann ist der wichtigste Schritt in Richtung 0.3 wohl gegangen...?

Zitat
Meine To-Dos sind momentan:

1. überlegen, was ich zu Mittag esse
2. versuchen, deine ganzen Verbesserungen zu verstehen
3. den Timer verbessern
4. überprüfen, warum die FHEM-Befehle bei Shortcuts nicht mehr ausgeführt werden
5. Code aufräumen

Dazu eine Frage:
Wenn ich da wirklich siteIDs auslesen soll, wie das im anderen Thread überlegt wurde, sollte ich das fast bei Initalisierung des Moduls machen. Wie verpönt ist das? Und wie gehe ich das am Besten (=FHEM konformsten) an?

Vermutlich wird 4. recht einfach zu lösen sein, wenn du durch 2. mal soweit durch bist (das ist nur eine vage Vermutung). Das mit dem Aufräumen geht dann vermutlich auch "nebenbei". Dabei halt aufpassen, ob das, was die Prototypes suggerieren auch richtig ist (siehe unseren Attribute-Fall).

Was mehrere Sprachen/RHASSPY-Instanzen angeht, hatte ich auch schon die Frage im Hinterkopf, ob es nicht sinnvoll wäre, das ähnlich zu machen wie bei MGB: Da kann man für jede Instanz ein eigenes "MQTT-Präfix" definieren, das dann in den (global verfügbaren) Attributnamen wieder auftaucht. Fände ich für Schritt 1 erst mal gut (die Notation in MGB mit den Konstanten gefällt mir dagegen nicht so sehr).
MGB "sammelt" bei der Initialisierung auch erst mal alles ein, das wäre vermutlich auch für RHASSPY eine gute Idee, wobei das ziemlich "Bauchgefühl" ist, denn so ganz verstanden habe ich die Zusammenhänge noch nicht.

Weiter fand ich es "befremdlich", bei einem "onOff"-Device überhaupt ein Mapping angeben zu müssen (jedenfalls war es bei dem Muster-dummy dabei, was mir suggeriert, man würde es benötigen). Ich würde mal pauschal annehmen, dass das der Default für alle Devices ist. Eventuell schwirren dann noch Stichworte wie genericDeviceType im Raum, wobei ich noch keine Idee habe, wie und wo man das nutzen kann...

Ggf. solltest du dir mal jsonlist und jsonlist2 zu Gemüte führen.

Aber Rom und so, erst mal guten Appetit!

Zitat von: drhirn am 24 Februar 2021, 12:29:16
Haha, perfekt! Die wollte ich auch schon mal angehen. Aber keine Ahnung, was die tut. Jetzt erspar ich mir das :D

Ersetzungen vornehmen. Aber das Ding sah' von der Struktur her "schwierig" aus (eher: man muß wissen, nach was man sucht, um es umzubauen), deswegen dachte ich, es würde dir gefallen, wenn es von der Liste käme... Deiner Rückmeldung entnehme ich, dass auch der Teil weiter funktioniert?

Zitat von: Beta-User am 24 Februar 2021, 12:50:47
Dann ist der wichtigste Schritt in Richtung 0.3 wohl gegangen...?

Eindeutig.

Zitat
Vermutlich wird 4. recht einfach zu lösen sein, wenn du durch 2. mal soweit durch bist (das ist nur eine vage Vermutung).

2 wird länger dauern ;)
4 dürfte in der Tat eher leicht sein. Das Kommando wird richtig gebaut, kommt aber irgendwie falsch an. Tippe auf ein "Umwandlungsproblem" der geschwungenen Klammern.

Zitat
Was mehrere Sprachen/RHASSPY-Instanzen angeht, hatte ich auch schon die Frage im Hinterkopf, ob es nicht sinnvoll wäre, das ähnlich zu machen wie bei MGB: Da kann man für jede Instanz ein eigenes "MQTT-Präfix" definieren, das dann in den (global verfügbaren) Attributnamen wieder auftaucht.

Klingt nach einem guten Plan!

Zitat
Weiter fand ich es "befremdlich", bei einem "onOff"-Device überhaupt ein Mapping angeben zu müssen (jedenfalls war es bei dem Muster-dummy dabei, was mir suggeriert, man würde es benötigen). Ich würde mal pauschal annehmen, dass das der Default für alle Devices ist. Eventuell schwirren dann noch Stichworte wie genericDeviceType im Raum, wobei ich noch keine Idee habe, wie und wo man das nutzen kann...

Das Mapping ist keine Pflicht. Du kannst ohne halt den Status des Gerät nicht abfragen ;).
Warum Thyraz das damals so gelöst hat, weiß ich nicht. Ich schätze mal, um flexibel zu bleiben. Es soll ja Geräte geben, deren "Ein-Status" nicht "on" ist.

Zitat
Ggf. solltest du dir mal jsonlist und jsonlist2 zu Gemüte führen.

Kenn ich ausnahmsweise mal beide :)
Warum?

Zitat
Aber das Ding sah' von der Struktur her "schwierig" aus (eher: man muß wissen, nach was man sucht, um es umzubauen), deswegen dachte ich, es würde dir gefallen, wenn es von der Liste käme... Deiner Rückmeldung entnehme ich, dass auch der Teil weiter funktioniert?

Mir ist in einem Kurztest nichts Negatives aufgefallen. Bin mir halt nicht sicher, warum Thyraz eine abgespeckte Variante gebaut hat. Und nicht-sprechende Variablen sind halt ein bisschen mühsam ;).

Zitat von: drhirn am 24 Februar 2021, 14:34:52
4 dürfte in der Tat eher leicht sein. Das Kommando wird richtig gebaut, kommt aber irgendwie falsch an. Tippe auf ein "Umwandlungsproblem" der geschwungenen Klammern.

Falls ich was beitragen kann, bräuchte ich eine Anleitung für dummies und passende topic/payload-Schnipsel + RAW-defs ;) .

Zitat
Klingt nach einem guten Plan!

Dann wäre auch hier Schritt 1, alle Vorkommen des Präfixes im Code durch eine entsprechende Variable zu ersetzen. Die kann dann aus der DEF kommen, Code dazu fände sich in MGB (btw.: die cref von RHASSPY ist an der Stelle überholt).

ZitatDas Mapping ist keine Pflicht. Du kannst ohne halt den Status des Gerät nicht abfragen ;) .

Na ja, wenn man als default von einen onOff-Gerät und on bzw. off (als lc(state)) ausgeht, sollte das häufig schon befriedigende Ergebnisse erbringen...

Zitat
Warum Thyraz das damals so gelöst hat, weiß ich nicht. Ich schätze mal, um flexibel zu bleiben. Es soll ja Geräte geben, deren "Ein-Status" nicht "on" ist.

Man könnte ihn fragen. Aber es spricht ja nichts dagegen, eine Mapping-Option zu haben, nur eben nicht verpflichtend, sondern "//" ;) .

Zitat
Kenn ich ausnahmsweise mal beide :)
Warum?

Ich hatte die lange nicht auf dem Radar ::) . Darüber bekommst du Rückmeldung, welche Setter ein Device hat, so dass darüber auch rauszubekommen sein sollte, ob onOff zulässig ist, ohne dass man es explizit in irgendeinem mapping angibt...

ZitatMir ist in einem Kurztest nichts Negatives aufgefallen. Bin mir halt nicht sicher, warum Thyraz eine abgespeckte Variante gebaut hat. Und nicht-sprechende Variablen sind halt ein bisschen mühsam ;) .

Den Grund kenne ich auch nicht (s.o.), aber der Code kam mir an der Stelle irgendwie verbogen vor, daher der Versuch, das funktionsgleich "sauber" zu machen. Ob es Abgespeckt war, hat mich an der Stelle nicht unbedingt interessiert.
Die Adressierung ist aber mAn. weiter eindeutig und hinreichend "sprechend", da ist kein wesentlicher Unterschied zu vorher (außer, dass man die "interne sub" jetzt nicht mehr versehentlich "von außen" ansprechen kann (früher: in main!)...

(@JensS als potentiellem "Tester":
Ich höre deine Skepsis, was die massiven Umbauten angeht, nehme aber an, dass zwischenzeitlich halbwegs klar ist, dass das packaging das Gefahrenpotential eher verkleinern sollte...
Die Sub's betr. genericDeviceType habe ich gesehen, werde aber erst mal zuwarten, ob/welche Ideen da von eurer Seite kommen. Zum Hintergrund: ich kenne das ganze Thema Sprachsteuerung  nur vom Hörensagen und kann daher diese ganzen Dinge nicht wirklich gut einordnen und hatte auch auf die Schnelle nicht die zündende Idee, wo die Funktionen grade andocken (aber auch nicht lange nachgedacht)...).

Werde jetzt wie gesagt erst mal zuwarten. Falls konkrete Fragen sind, bitte einfach stellen, ihr seht ja auch an der Rückmeldung von Wzut und betateilchen, dass durchaus der eine oder andere mitliest, der ggf. sogar besser helfen kann.

Sodala, los geht's :D

Bezüglich Shortcuts hast du zu viele Parameter als Pflicht angenommen und mir "// return" abgebrochen, wenn die nicht da waren. Deshalb wurden die nie ausgeführt.

Da mal der aktuelle Code: https://github.com/drhirn/fhem-rhasspy/blob/testing/10_RHASSPY.pm

Ich hab das wieder hin gebogen. Es funktioniert alles.

Allerdings hab ich da wieder das "Status-Ändert-Sich-Nicht"-Problem beim geschalteten Device. Mir ist ja inzwischen klar, warum. Aber ich hab noch nicht ganz verstanden, wie ich das lösen könnte. Auch in Anbetracht dessen, dass ein Shortcut nicht immer ein FHEM-Befehl sein muss.
Selbiges übrigens auch mit set textCommand ..

Die Shortcuts werden im 10_Rhasspy-Device angelegt, deswegen hier nur ein Attribut:

attr Rhasspy shortcuts ton aus={fhem ("set RXV777 off")}\
ton an={fhem ("set RXV777 on")}\
du bist cool={fhem ("set Rhasspy speak siteId='wohnzimmer' text='Danke du auch'")}


MSG:

Msg: hermes/intent/de.fhem_Shortcuts => {"input": "ton an", "intent": {"intentName": "de.fhem:Shortcuts", "confidenceScore": 1.0}, "siteId": "wohnzimmer", "id": null, "slots": [], "sessionId": "wohnzimmer-snowboy-4f44e811-513a-4f44-9144-97b7b221f66f", "customData": null, "asrTokens": [[{"value": "ton", "confidence": 1.0, "rangeStart": 0, "rangeEnd": 3, "time": null}, {"value": "an", "confidence": 1.0, "rangeStart": 4, "rangeEnd": 6, "time": null}]], "asrConfidence": null, "rawInput": "ton an", "wakewordId": "snowboy", "lang": null}


Darf ich dich diesbezüglich nochmal aus der "Rente" zurück holen? ;)

 :) Perl-defined-or scheint also zwischenzeitlich klar zu sein ;D .

Das Aktualisierungs-Thema ist da tieferliegend.

Erste Maßnahme sollte wohl sein, dafür zu sorgen, dass immer zumindest der Name der RHASSPY-Instanz zurückgeliefert wird, das passiert vermutlich im Moment gar nicht.

Ein paar (ggf. nicht vollständig durchdachte) Ansatzpunkte im Anhang. Grundproblem bleibt, dass wir eigentlich irgendwie das geschaltete Device ermitteln müßten. Ist aber schwierig zu konfigurieren. Die Alternative könnte sein, den Shortcut-Befehl mit einem InternalTimer Aufzurufen, dann wäre Parse() beendet, wenn das Device effektiv geschalten wird...

Zitat von: Beta-User am 24 Februar 2021, 16:43:03
Ist aber schwierig zu konfigurieren.

Hab' mir den shortcut-Pfad mal angesehen. Tendenziell würde ich die ganze Syntax und auch den Ablauf ändern...
Skizze:
- Gleich bei der Attribut-Eingabe einen Parser drüberlaufen lassen, der
-- einen hash erstellt mit den shortcuts;
-- ggf. einen Syntax-Check macht, wo Perl angesagt ist;
-- unterscheiden kann zwischen Perl-Anweisungen und fhem-Kommandos;
-- ein "Rückgabedevice" erlaubt (sonst den Namen der Instanz).

Syntax eventuell in diese Richtung (ungetestet, sollte ggf. ParseParams-kompatibel sein):
attr Rhasspy shortcuts i="ton aus" f="set RXV777 off" n=RXV777\
i="ton an" f="set $NAME on" n=RXV777\
i="du bist cool" f="set $NAME speak siteId='wohnzimmer' text='Danke du auch'"\
i="führe Perl myFunction aus" p='myFunction("argument")' n="device1,device2"

(Alte Syntax könnte man dann mit dem split in "i" und "p" trennen). ggf. könnte man noch "r" erlauben für eine bestimmte Rückgabe/ein response-pattern).

- Dann müßte man halt die Aufrufe ändern etc...
- und vorher noch EvalSpecials drüberlaufen lassen, damit manche Parameter aufgelöst werden können (ist einfacher portierbar, aber nicht zwingend).

Grundsätzlich die richtige Richtung oder zu kompliziert?

Ist schon kompliziert und fehleranfällig.
Im Grunde sind die Shortcuts ja eigentlich auch nur ein Intent. Und deswegen gehört das eigentlich sowieso aus "onmessage" raus. Damit hätten wir das Problem eventuell schon gelöst. So die kurze Überlegung gestern vor'm Einschlafen.

Ich bin nur unglücklicherweise heute morgen von meinem Arbeitgeber ordentlich mit Arbeit eingedeckt worden. Das verhindert momentan eine ausgiebige Beschäftigung mit dem interessanteren Thema FHEM + Rhasspy ;)

...ganz so einfach ist es leider nicht...

Man muss schon die message auspacken, um überhaupt den intend zu bekommen, und das ist im Moment dann in onmessage. Aber es wäre m.E. sowieso eine Frage, warum man nicht diesen Teil nach Parse rübernimmt.
Werde mir das mal vornehmen, der Ablauf v.a. bei den shortcuts kommt mir irgendwie ineffektiv und schlecht nachvollziehbar vor: da wird bei jeder message erst das shortcut-Attribut immer wieder auseinandergenommen & analysiert & sortiert (und das dann ggf. später nochmal?). Sollte eigentlich nicht soooo schwer sein, das in einen Hash-lookup umzubasteln, wenn man es anders strukturiert. Mal sehen...

Aus Rhasspy-Sicht ist das ein Intent.

{"input": "ton an", "intent": {"intentName": "de.fhem:Shortcuts",...

So wie ich das sehe, kein Grund mehr, das in onmessage getrennt von den anderen Intents zu behandeln. Snips hat das damals anders gemacht, deswegen das extra elsif.
Das wollte ich damit sagen.

A propos Hash-Lookup (bzw. Hash-Dispatch): Hättest du da ein Beispiel für mich, das so einfach ist, dass ich das auch verstehe? Also wie eine if-elsif-Abfrage entsprechend umgebaut werden kann. Ich finde bei Recherchen nur Beispiele, die ich nicht kapiere ;).

An dem Hash-lookup bastle ich grade rum, mein "Steinbruch" dazu ist in Twilight zu finden (extWeather).
Ein (hoffentlich) halbwegs einfaches Beispiel wäre der go_eCharger (m2-attrTemplate):
attr DEVICE userReadings charger_state:car.* { my $val = ReadingsVal($name,"car","none");; my %rets = ("none" => "-1","1" => "Ready","2" => "Charging","3" => "waiting for car","4" => "Charging finished",);; $rets{$val}}
Das "car"-Reading ist nummerisch, das macht da dann einen passenden lesbaren Text in das userReading...

Und andersrum fragt man einfach ab, ob der Hash defined ist (da muss man nur aufpassen, dass man nicht versehentlich den "davorstehenden" Hash generiert, obwohl er bis dahin nicht da war...). Wenn ja, rechnet man einfach mit dem Wert weiter, fertig.

Was die Funktionsreferenzen via Hash angeht, hatte ich den mAn. einfachsten Fall mit MySensors bereits an passender Stelle im Code genannt, es gibt dazu auch in der Perl-Ecke eine Diskussion, wie das entstanden ist. Da ist auch zu finden, dass das da etwas "komisch" aussieht, weil der lookup-Wert einer Konstante  zu entnehmen ist; eigentlich sollte das hier einfacher zu notieren sein, weil den Käse mit Konstanten fangen wir hier bitte gar nicht erst an ;) ...

Eine Anmerkung noch:
Dieser Stil gefällt mir nicht so, erst mal eine Ladung Variablen zu definieren und die dann zu füllen. Abgesehen von "außerhalb conditionals" zu definierenden Variablen (und wirklich wichtigem Zeug) mache ich das zwischenzeitlich immer so, dass eine Variable genau dann definiert wird, wenn ich sie das erste Mal brauche. MAn. ist das so herum sauberer, weil man sich sonst ständig die Frage stellt, welchen Wert die Variable denn hat und wo das herkommt...

Zitat von: Beta-User am 25 Februar 2021, 13:57:34
Eine Anmerkung noch:
Dieser Stil gefällt mir nicht so, erst mal eine Ladung Variablen zu definieren und die dann zu füllen. Abgesehen von "außerhalb conditionals" zu definierenden Variablen (und wirklich wichtigem Zeug) mache ich das zwischenzeitlich immer so, dass eine Variable genau dann definiert wird, wenn ich sie das erste Mal brauche. MAn. ist das so herum sauberer, weil man sich sonst ständig die Frage stellt, welchen Wert die Variable denn hat und wo das herkommt...

Gefällt mir auch nicht. Habe ich auch immer so gemacht, wie du. Aber - wenn ich mich recht erinnere - hat perlcritic das mal angemeckert. Oder ich hab das aus einem Tutorial. Irgendwo her auf jeden Fall.

Hmm, perlcritic war's wohl nicht, gerade ausprobiert. Dann mach ich das wieder anders.

So, ein wenig kann man erkennen, in welche Richtung es gehen könnte...

Hab's mal mit diesen Attributinhalten versucht, aber noch nicht vollständig durchgetestet
attr RHASSPY shortcuts ton aus={fhem ("set RXV777 off")}\
i="du bist cool" f="set $NAME speak siteId='wohnzimmer' text='Danke du auch'"\
i="ton an" p={fhem ("set $NAME on")} n=RXV777
Die Änderungen bzgl. der Auswertung des Attributs kann man an einfachsten in einem list sehen.

Viel Spaß beim Testen!

Ich hab das - wie hier (https://github.com/drhirn/fhem-rhasspy/blob/shortcuts/10_RHASSPY.pm) zu sehen - mal aus onmessage rausgenommen. Und mir dann überlegt, wie ich das Kommando auseinandernehmen könnte. Was eigentlich leicht wäre. Ist nicht fertig, wird also unter Umständen Fehler werfen.

Ja, irgendwann ist mir auch aufgegangen, was du gemeint hattest mit dem, dass es eigentlich dasselbe ist...

Du solltest mal meine letzte Version downloaden und ein diff machen  ;) .

Anbei eine Fassung, die mal die letzten Stände soweit konsolidieren dürfte, also das aus deinem github, meine Version von gestern und was mir sonst noch so auf- und eingefallen ist...

Was kann das?
- "alte Attribut-Werte" in "shortcuts" und die neuen parsen und (hoffentlich) zutreffend auswerten (slots: s.u.);
- Attribute "disable" und "disableForIntervals";
- "onmessage" darf m.E. bleiben, das in Parse() reinzubasteln, würde die Struktur m.E. nur verkomplizieren, nicht vereinfachen...
- die einzelnen Funktionausfrufe sind aus der "elsif-Hölle" entkommen und (weitestgehend) zu Hash-Referenzen umgebaut;
- Shortcuts werden ebenfalls durch Referenzierungen auf den aus dem Attribut gebauten Hash ausgewertet und ausgeführt. Damit sollte eigentlich dann RHASSPY_allRhasspyShortcuts() entfallen können. Unklar ist mir, ob das umgebaute RHASSPY_updateSlots() jetzt noch tut...
Vermutlich kann jetzt "Shortcuts" dasselbe wie "custom intent" (?)...
- Es gibt eine "array-Kürzen- und -Sortieren"-Funktion;

Was nicht so richtig will, ist das RHASSPY_EvalSpecialsDefaults(), da habe ich mich noch in der Hash-(de-)-Referenzierungshölle verheddert und muss wohl auch noch das eine oder andere Nachlesen....

Falls Fragen sind: her damit ;) .

Noch ein update. Könnte das "siteId"-Problem von https://forum.fhem.de/index.php/topic,113180.msg1135606.html#msg1135606 (https://forum.fhem.de/index.php/topic,113180.msg1135606.html#msg1135606) lösen, sonst ist nicht wirklich viel passiert:

Du bist mir zu schnell. Ich hab mir doch gerade erst vor ein paar Minuten deine Änderungen von heute morgen angesehen :D

Timer hat bei mir immer funktioniert. Weiß noch nicht, was Thargor für ein Problem hat.

Außerdem bin ich jetzt verwirrt. Kann am Mittagessen liegen. Aber kannst du mir bitte folgendes in einen Satz übersetzen: $room = $room // $siteId;

Ich brauche im Timer sowohl $value, als auch $time. Nachdem ich ja das eine in Sekunden umrechne, will ich nicht, dass als Antwort "Timer gesetzt auf 3600 Sekunden" zurück kommt, wenn ich ihn auf eine Stunde stelle ;).

Vermutlich ist das Problem bei dir nicht vorhanden, weil $siteId und $room bei dir identisch sind; bei ihm nicht. Ich vermute, dass die Variable $room einmal an der falschen Stelle reingerutscht war:
$cmd = "defmod timer_$room at +$time set $name speak siteId=\"$siteId\" text=\"taimer abgelaufen\";;setreading $name timer_".$room." 0";vs.
$cmd = "defmod timer_$room at +$time set $name speak siteId=\"$room\" text=\"taimer abgelaufen\";;setreading $name timer_".$room." 0";
$room = $room // $siteId;Bedeutet: $room bleibt $room, wenn es definiert ist, ansonsten erhält es den Wert von $siteId.

Das mit $value/$time ist einleuchtend, hoffe es wieder repariert zu haben...

Letzte Zeile bei SetTimer
return [$name];

Die eckigen Klammern sind keine Absicht, oder?

Die eckigen Klammern sind der Versuch Perl zu signalisieren, dass es das als Array zurückgeben soll.
Was ähnliches verbirgt sich auch hinter (#1411 in der Anlage):
$device = split m{,}x, $shortcut->{NAME};
Da geht es auch darum, dass ggf. ein Array zurückgegeben wird, selbst, wenn nur ein Device angegeben war.

Nach der Beschäftigung mit https://perldoc.perl.org/perlreftut (https://perldoc.perl.org/perlreftut) habe ich es dann auch noch hinbekommen, das RHASSPY_EvalSpecialsDefaults() zumindest halbwegs funktional zu bekommen (indem eine Hash-Referenz übergeben wird statt des Hashes, alles klar...?). Was ich mir noch unsicher bin: Überschreiben die übermittelten Hash-Elemente immer die in der Funktion vorhandenen? Sollte eigentlich so sein, aber ob das hinhaut, wird man vermutlich nur mit etwas Testen in Erfahrung bringen können.

Jetzt wäre dann eigentlich (neben Code-Cleanup und Testen) dann das Dynamisieren der Sprache dran...

Oder erst mal die Präfix-Attribut-Namen?

Soweit mal gar nichts klar ehrlich gesagt. Das war in der Woche mehr Perl, als mein Hirn verkraftet hat ;).

Aber, bezüglich eckige Klammer hab ich gefragt weil: ERROR: >ARRAY(0x55b208b39008)< returned by the RHASSPY ParseFn is invalid, notify the module maintainer

Ansonsten muss ich jetzt mal alles testen. Mir sind da schon ein paar Ungereimtheiten aufgefallen, die es zu lösen gilt.

Ja, war einiges an Perl ;D ...

$device muss als scalar zurückgegeben werden ( ::) ), das war wohl nix mit dem Array an dieser Stelle...

Anbei zu guter Letzt noch ein update, das das behebt und generell fhem.pl-Fehlermeldungen vermeidet, wenn irgendwo "Unsinn" konfiguriert ist bzw. als $device zurückgegeben wird (bei den get-Funktionen kann man das wohl lassen, oder?).

Ich hoffe, dass es nicht allzuviele Ungereimtheiten sind, manches wird erst sichtbar, wenn man Testet und ins Log schreibt. Das machen die letzten Fassungen etwas sehr exzessiv bei verbose 4/5, hab's jetzt wieder (an "meinen" Stellen) etwas reduziert und - grade was das %specials-Thema angeht - an hoffentlich auch für andere Funktionen hilfreicher Stelle plaziert...

...und noch ein letzter für heute: prefix in Variablenform, samt Löschen der Attribute bei Löschen des RHASSPY-devices... (weiß noch nicht, ob das in der Testphase so glücklich ist, aber das kann man ja mit einem einfachen return an der richtigen Stelle vorläufig verhindern...)

Zitat von: JensS am 28 Februar 2021, 11:51:49
@drhirn: Hab die gestrige Version von Beta-User installiert. Läuft alles - bis auf die Shortcuts natürlich.
[...]

(Danke für den Mut zum Testen und die Rückmeldung!)

...das mit "natürlich" ist seltsam. Ein list (kein RAW) vom RHASSPY-Device wäre hilfreich, damit ich sehen kann, dass das Attribut sauber ausgewertet wird.

@drhirn: Zur Attributbeschreibung ist auch m.E. noch eine Korrektur in der cref erforderlich (gg. dem, was in deiner letzten github-Version steht): parseParams kann den Teil nach dem "=" nur als zusammengehörig erkennen, wenn es irgendwie "geklammert" wird. Und FHEM-Kommandos gehen zwar, aber wenn, dann muss man die "Kürzel" "i" _und_ "f" setzen, sonst wird es als Perl interpretiert:

i="mute off" f"=set receiver mute off"
oder
mute off='fhem("set receiver mute off")'

Die "alte Notation" sollte auch gehen, dann wird es als Perl ausgeführt

Was hattest du im Kopf, als du dich für die Buchstaben "i" und "f" entschieden hast?

Zitat von: Beta-User am 25 Februar 2021, 18:05:14
Hab's mal mit diesen Attributinhalten versucht, aber noch nicht vollständig durchgetestet

Code Auswählen Erweitern

attr RHASSPY shortcuts ton aus={fhem ("set RXV777 off")}\
i="du bist cool" f="set $NAME speak siteId='wohnzimmer' text='Danke du auch'"\
i="ton an" p={fhem ("set $NAME on")} n=RXV777
Die Änderungen bzgl. der Auswertung des Attributs kann man an einfachsten in einem list sehen.

Also funktionieren sollten:
i => intent (damit muss eine Zeile starten, damit nicht alte Syntax unterstellt wird, Leerzeichen können vorher kommen)
f => FHEM-Kommando
p => Perl-Kommando (hat Vorrang vor "f")
n => Name des zurückzugebenden Devices (für longpoll ;) ); sonst wird der Rückgabewert versucht
r => Response (sonst der Rückgabewert)

Wollte es nicht so lange haben, und die Buchstaben/Anfänge waren alle unterschiedlich... (Ist aber kein Muss und schnell geändert).

Ansonsten: Hut ab, du scheinst die Änderungen wirklich alle zumindest grob überflogen zu haben!

Perfekt, ich danke vielmalst!

Natürlich sehe ich mir die Änderungen an. Passiert bei einem DIFF zwangsläufig ;). Aber ich will ja wissen, was du da machst. Auch wenn ich manchmal viel nicht verstehe.

Mal schauen, ob ich heute noch zum Testen komme.

Aufgrund der Info von JensS: Irgendwo ist noch ein Typo drin, es gibt jetzt zwei keys in helper->shortcuts; In Zeile 1208 (github) sollte wohl klein geschrieben werden.
(Ist aber eher nicht die Ursache)

Ansonsten würde mich der Attributwert interessieren, ich vermute eine Doppelung von ' und {. Benötigt wird nur eines, ich kann's aber grade nicht nachstellen...

Zitat von: drhirn am 28 Februar 2021, 12:28:50
Perfekt, ich danke vielmalst!

Natürlich sehe ich mir die Änderungen an. Passiert bei einem DIFF zwangsläufig ;) . Aber ich will ja wissen, was du da machst. Auch wenn ich manchmal viel nicht verstehe.

Na ja, an der einen oder anderen Stelle meine ich, dass da was verändert wurde, und das (bis auf die benannte Stelle in der cref) sinnvoll! Darfst gerne nachfragen, wenn was unklar ist...

Nachtrag noch zum Thema "r": muss zugeben, dass ich diesen Teil erst mal nur "angedacht" hatte und mich zunächst auf die Perl- und FHEM-Unterscheidung konzentriert hatte, damit das sauber erkannt und auch ausgeführt wird. (Daher war das "r" bis vorhin auch noch nicht offen aufgetaucht...)

Von daher ist die "response"-Logik vermutlich noch nicht ausgereift, mir ging es vorrangig erst mal darum, (auch) das sauber aufzulösen, den (via list sichtbaren) Hash zu schreiben und für die Basisfunktion klarzumachen, wo bei der Ausführung dann was hergeholt/referenziert wird.
@drhirn & JensS: Wollt ihr versuchen, das zu fixen?

Die Kleinschreibung ist mal der Grund, warum updateSlots jetzt überhaupt wieder funktioniert.

Ansonsten bekomme ich immer den "DefaultError" als Response zurück, obwohl richtig geschalten wird (inkl. "Longpoll"-Aktualisierung). Das versuche ich gerade zu ergründen.

Morgen Beta-User,

wie könnten wir die Sprache (wo) anders setzen? Ich habe nämlich gerade das Rätsel gelöst, warum die bei mir immer englisch ist, obwohl überall deutsch eingetragen ist: Das passiert immer nach einem Reload des Moduls. Ändere ich das Attribut, stimmt's wieder. Bis zum nächsten Reload.
Hast du eine Idee?

Moin!

Bei der Sprache bin ich mir nicht sicher, ob es was bringen würde, die in DEF reinzubasteln, ich habe jedenfalls das Verhalten auf dem Testsystem nicht, dass ein reload die Sprache ändern würde. Von daher: ratlos. Ggf. erst mal übergangsweise hart (anders) vercoden?

Grundsätzlich bin ich aber am Überlegen, ob es nicht besser wäre, das Modul auf "parseParams" umzustellen, dann wäre es z.B. auch einfacher möglich, weitere Parameter einzuführen (z.B. useAlexaRooms=true). Wirkt sich halt auf "define", "set" und "get" aus...

Anbei auch noch eine Version, die zumindest grade nicht rumzickt, was $mutuated_vovels angeht (deine Commits von vor 45 Min sollten drin sein). Kannst du kurz testen, ob das die Ersetzungen wie beabsichtigt macht (oder das ganze in den Abgrund zieht...)?

Schlechte Nachricht:
Can't use an undefined value as a HASH reference at ./FHEM/10_RHASSPY.pm line 1036

Zeile 1036 ist
my $mutated_vowels = \%languagevars{$language}->{mutated_vowels};

Und außerdem, falls das hilft:

PERL WARNING: %languagevars{...} in scalar context better written as $languagevars{...} at ./FHEM/10_RHASSPY.pm line 1038, <$fh> line 114.
PERL WARNING: Useless use of push with no values at ./FHEM/10_RHASSPY.pm line 1108, <$fh> line 114.
PERL WARNING: Reference found where even-sized list expected at ./FHEM/10_RHASSPY.pm line 57, <$fh> line 114.


OK, vielleicht ein paar kleine Schritte weiter...

parseParams ist jetzt aktiv, was ggf. dazu führt, dass set nicht mehr geht ::) . Dafür kann man jetzt in der DEF die Sprache angeben, das Attribut ist weg.
Na jedenfalls, _wenn_ das mit set alles noch funktioniert, sollten die Voraussetzungen dafür vorhanden sein, dass man ggf. auch "alexaName" usw. mit auswertet. Sowas müßte dann in einen ähnlichen Parser wie das Shortcut-Ding, nur eben über alle Geräte ausgewertet und in den internen helper-Hash gepackt...

Könnte sein, dass das mit den Umlauts jetzt geht und dann auch die Rückmeldungen für Timer-Befehle in de und en funktionieren 8) . Ist aber nicht wirklich getestet...

Blöde Frage: Warum sollte ich alexaName auswerten wollen?

Na ja, nach meinem möglicherweise unvollständigen Verständnis gibt es viele Parallelen zwischen praktisch allen Sprachsteuerungslösungen.

Ich fände es z.B. als siri-Nutzer wenig intuitiv, wenn ich für eine weitere Lösung nochmal "dasselbe" Attribut (unter anderem Namen) anlegen müßte und nicht einfach (z.B. zum Testen) sagen könnte: "Nimm alle Geräte, die auch im Alexa-Room sind und verwende die alexa- oder siri-Namen" und die bereits vergebenen mappings aus dem homebridgeMapping..."

(Ich habe noch keinen Schimmer, inwieweit das vergleichbar ist und ob ich mit dem Bachgefühl richtig liege, aber diese "sortierten Lookups" bei jedem Durchlauf sehen mir nicht optimal aus, that's all...)

Das ist schon richtig. Könnte aber natürlich auch sein, dass ich mit einer Alexa nicht die selben Geräte steuern möchte. Aber ist wahrscheinlich eher selten der Fall (außer man testet - wie ich - schon seit Jahren eine "beste" Lösung). Weiß auch nicht, was da schlauer ist.

Zitat
Zeile 1295: "Beta-User: warum eigentlich nicht direkt nur den Befehl absetzen...?"

Geht auch. Ich bin es einfach so gewohnt, dass ich mir zuerst die "Config" zusammenschreibe und danch den Befehl bastle. Macht's für mich übersichtlicher. Und ich kann den Befehl dann einfach nur kopieren und irgendwo anders genau so wieder einfügen.

Zitat von: drhirn am 01 März 2021, 14:53:39
Das ist schon richtig. Könnte aber natürlich auch sein, dass ich mit einer Alexa nicht die selben Geräte steuern möchte. Aber ist wahrscheinlich eher selten der Fall (außer man testet - wie ich - schon seit Jahren eine "beste" Lösung). Weiß auch nicht, was da schlauer ist.

...ich erst recht nicht...
Vom Bauchgefühl her würde ich das auch nicht zum default machen, sondern wenn, dann optional. Was ggf. auch interessant wäre, wäre Devices über devspec auszuwählen.
Will ja nur andeuten, dass der Weg über rhasspyRoom ggf. ergänzt werden könnte. (Das war doch bisher das Kriterium, oder?)

Falls du irgenwo eine Übersicht hast, wie der matching-Prozess eigentlich läuft, wäre das ggf. hilfreich, ich muss mir das sonst aus dem Code zusammenreimen; bisher hatte ich einfach mit einigen wenigen topic/payload getestet, ob der On/off und Shortcut-Prozess unverändert durchläuft, nicht, ob er (abgesehen von unnötigen Code-Doppelungen an diversen Stellen) optimal ist ::) .

Zitat
Geht auch. Ich bin es einfach so gewohnt, dass ich mir zuerst die "Config" zusammenschreibe und danch den Befehl bastle. Macht's für mich übersichtlicher. Und ich kann den Befehl dann einfach nur kopieren und irgendwo anders genau so wieder einfügen.

Ich bin da auch nicht "durch" und finde es an der Stelle auch nachvollziehbar, weil sich ja (theoretisch) immer mal wieder was ändern kann, und da ist es dann einfacher, wenn die Parameter sauber untereinander weg kommen...
Wenn ich es als "falsch" empfunden hätte, hätte ich mal wieder "einfach gemacht"... ::)

Jetzt hamma zu viel kaputt gemacht :D

Beim Zusammensammeln von Geräten, Räumen, etc. wird nur noch der erste Fund zurück gegeben. Außer bei RHASSPY_allRhasspyColors. Das funktioniert noch.

set updateSlots, set trainRhasspy und fetchSiteIds geht noch.

Alles andere nicht mehr ;)


PERL WARNING: Use of uninitialized value in substitution iterator at ./FHEM/10_RHASSPY.pm line 1081.

$room =~ s/($keys)/$mutated_vowels->{$1}/g;


--edit--
Gelogen. Nur set speak geht nicht.
Da bleiben $unnamedParams und $namedParams leer. Interessantes Detail am Rande: Genau das war der Grund, warum ich angefangen habe, das Modul umzubauen. Hat nämlich damals auch genau deswegen nicht funktioniert. :D

Uff...

Zitat von: drhirn am 01 März 2021, 15:17:36
Gelogen. Nur set speak geht nicht.
Da bleiben $unnamedParams und $namedParams leer. Interessantes Detail am Rande: Genau das war der Grund, warum ich angefangen habe, das Modul umzubauen. Hat nämlich damals auch genau deswegen nicht funktioniert. :D

Irgendwie finde ich es (noch) nicht logisch, dass (nur) da die Listen leer sein sollen, müßte man sich ansehen, und an dem direkten join sollte es auch nicht liegen...? Habe mal ein Log eingebaut:

(Und was die anderen Meldungen angeht, würde mich auch interessieren, wo die herkommen; meine Zeilennummern waren schon wieder andere...)

Unsere Zeilennummer werden immer andere sein. Der GitHub-Stand ist nie der aktuellste. Das soll dich nicht beunruhigen.

@values ist leer


print Dumper([$anon,$h,$name,$command,@values]);

$VAR1 = [
          [],
          {
            'text' => 'test',
            'siteId' => 'wohnzimmer'
          },
          'Rhasspy',
          'speak'
        ];


Was hast du eingegeben?

bzw. von wo kommt das Kommando?

Wenn FHEMWEB, muss man aufpassen, dass es parseParams-kompatibel ist, also in der Regel in Quotes packen;

Wenn wir das über "text=test" im Hash bekommen, müssen wir umpacken.

Anbei mal ein Versuch, wobei mir das seltsam vorkommt, dass das in der Form dann überhaupt an der Stelle aufschlägt...

Der Befehl lautete bis jetzt:
set Rhasspy speak siteId="wohnzimmer" text="das ist ein text"

Der Versuch ist durchwachsen. Jetzt geht auch textCommand nicht mehr. Weiß aber noch nicht, warum.

Hast du RHASSPY_allRhasspyShortcuts absichtlich nicht mehr drinnen?

--edit--
Tippfehler. Muss so heißen:

    $dispatch = {
        speak       => \&RHASSPY_speak,
        textCommand => \&RHASSPY_textCommand,
        play        => \&RHASSPY_playWav
    };


Zitat von: drhirn am 01 März 2021, 16:30:36
Unsere Zeilennummer werden immer andere sein. Der GitHub-Stand ist nie der aktuellste. Das soll dich nicht beunruhigen.

na ja, in dem Fall ist es eher beuruhigend...

Hinweis: Wenn "mal wieder" Prototypen wegfallen, sollte FHEM auch wieder neu gestartet werden, das kann sonst komische Effekte geben - da waren ein paar dabei..., aktueller Stand:

ZitatTotal lines: 2140
Code lines: 1311
Comment lines: 312
Data lines: 1
Blank lines: 398
POD lines: 118
Total violations: 131
Severity 5: 22
Severity 4: 9
Severity 3: 100
Total subroutines: 59
Average McCabe: 7.88

Je nachdem würde mich dann auch interessieren, welche Sprache wir grade sprechen, rudimentäres English sollte zwar auch gehen, aber das ist in der Tat ein leerer Hash...

Zitat von: drhirn am 01 März 2021, 17:15:14
Der Befehl lautete bis jetzt:

Code Auswählen Erweitern

set Rhasspy speak siteId="wohnzimmer" text="das ist ein text"

Der Versuch ist durchwachsen. Jetzt geht auch textCommand nicht mehr. Weiß aber noch nicht, warum.

Hast du RHASSPY_allRhasspyShortcuts absichtlich nicht mehr drinnen?

textCommand hatte ich verbogen :o , habe jetzt den Hash-Verweis auch noch entsprechend angepasst, siehe Anhang.

Für RHASSPY_allRhasspyShortcuts zähle ich noch einen (auskommentierten) Treffer => brauchen wir in der Form m.E. nicht mehr, ist durch den Attribut-Parser ersetzt.

Zitat von: Beta-User am 01 März 2021, 17:21:31
Hinweis: Wenn "mal wieder" Prototypen wegfallen, sollte FHEM auch wieder neu gestartet werden, das kann sonst komische Effekte geben

Was meinst du mit "Prototypen wegfallen"?
Und was ist das für eine interessante Auflistung?

ZitatJe nachdem würde mich dann auch interessieren, welche Sprache wir grade sprechen, rudimentäres English sollte zwar auch gehen, aber das ist in der Tat ein leerer Hash...

Ähm, kann gerade nicht folgen. Sprache?

ZitattextCommand hatte ich verbogen :o , habe jetzt den Hash-Verweis auch noch entsprechend angepasst, siehe Anhang.

Ja. Auch gefunden. Mein Edit war zur selben Zeit, wie dein Posting.

Zitat
Für RHASSPY_allRhasspyShortcuts zähle ich noch einen (auskommentierten) Treffer => brauchen wir in der Form m.E. nicht mehr, ist durch den Attribut-Parser ersetzt.

Verstehe. Perfekt!

Zitat von: drhirn am 01 März 2021, 17:28:56
Was meinst du mit "Prototypen wegfallen"?

Wenn aus
sub RHASSPY_getMapping($$$$;$) {sowas hier wird:
sub RHASSPY_getMapping {

ZitatUnd was ist das für eine interessante Auflistung?

http://perlcritic.com/critique/file (http://perlcritic.com/critique/file) => show stats


Ähm, kann gerade nicht folgen. Sprache?

Zitat von: Beta-User am 01 März 2021, 14:29:17
Könnte sein, dass das mit den Umlauts jetzt geht und dann auch die Rückmeldungen für Timer-Befehle in de und en funktionieren 8) . Ist aber nicht wirklich getestet...

Will sagen: Ich habe einen Versuch unternommen, den "Sprach-Hash" aufzubohren und an der Stelle mal anzuzapfen, weiß aber noch nicht, ob das funktioniert ::) ... (oder eben Fehler wirft).

Zitat
Ja. Auch gefunden. Mein Edit war zur selben Zeit, wie dein Posting.

Hatte ich dann nicht mehr gesehen, aber doppelt genäht und so...

Zitat
Verstehe. Perfekt!

So ähnlich sollte man dann einen Parser aufbauen, der die "Device-Attribute" auswertet; dafür bräuchten wir dann vermutlich einen setter oder wir müßten Events abhören (=> NotifyFn). Letzteres finde ich hier aber fast overdone, (wenn wir sonst keine benötigen und sowieso in der Eventloop eingeklinkt wären).

Ziel wäre, alles an relevanten Infos intern zu sammeln, damit man diese relativ aufwändigen Auswerte-Loops nicht immer fahren muss, sondern eben "einfach" den passenden Hash abfragt, ob da was ist...
Hoffe, es wird langsam etwas klarer, wie das gemeint ist ;) .

Ähm, vielleicht zu dem hier noch nach etwas Nachdenken:

set Rhasspy speak siteId="wohnzimmer" text="das ist ein text"

Das wird man dann wohl jetzt eher so schreiben müssen:
set Rhasspy speak 'siteId="wohnzimmer" text="das ist ein text"'
Schlimm?

Ansonsten müssten wir uns was überlegen, wie man den Command entweder wieder zusammenbauen kann oder eben direkt den $h-Parameter weitergeben... ginge ja auch.

Hab ich schon versucht so. Das geht auch nicht.

Ansonsten zum Thema Timer: Der wird gesetzt. Und als Bestätigung dafür sagt mir die Sprachausgabe: "Timer in $room has been set to $value $unit". Und zwar wirklich genau so. Klingt lustig :D

Abgesehen davon, dass die Sprache schon wieder auf englisch gesetzt wurde. Nach einen Reload des Moduls.

Hm, also:
Habe mal versucht, den Hash durchzureichen.

Und immerhin zieht er schon mal den richtigen Text raus (language wird jetzt über die DEF gesetzt, falls es vorher per Attribut am Device war).
Hab' da ne Kleinigkeit geändert, aber das Verhalten wird sich vermutlich (noch) nicht ändern...

Haha, das mit dem Anführungszeichen statt "q" hab ich mir auch überlegt. Aber ich hab mich nicht getraut ;)
Egal, es hätte eh nichts geändert.

Dafür funktioniert "speak" jetzt wieder wie gehabt. Super!

P.S.: Die Sprache ist bei mir über's DEF gesetzt

qq() im Code drumrum?

Auch schon probiert. Dann wird sich darüber beschwert, dass die Variablen nicht deklariert sind. Was irgendwie klar ist.

Im, code, nicht im hash

Ich steh gerade auf der Leitung  :-[

...anbei der Versuch, das qq() an etwas anderer Stelle (erst mal nur für die genannte Timer-Rückmeldung; geändert u.a. Zeile 1956) zu plazieren. Das "Problem" ist, dass man die Variablen zur richtigen Zeit auflösen muss...

Wenn das vollends klappt, würde ich vorschlagen, mal mit den default answers weiterzumachen?

Was $language angeht, ist mir jetzt auch so langsam klar, dass das so nicht bleiben kann ::) . Wir werden das wohl ersetzen müssen durch $hash->{language} und jeweils zur Laufzeit auflösen (ggf., indem wir das in eine kürzere Variable packen).

Das war's leider auch nicht.
Ich glaub, wir müssen die Sätze einfach aufteilen und zur Laufzeit zusammen stückeln. Am besten so, dass man einzelne Stücke via Attribut ändern kann.

Aber können wir das Sprach-Feature vorerst pausieren? Auch wenn's dir Spaß zu machen scheint? Ich würde das Modul gerne mal auf Herz und Nieren testen und dann ein paar Baustellen aufräumen. Shortcuts z.B. Und sollte dann noch CRef und GitHub-Doku anpassen. Damit wir wiedermal einen stabilen Stand bekommen. Und nebenbei sollte ich auch wieder mal meinen Arbeitgeber glücklich stellen ;)

get_unique liefert z.B. immer nur einen Wert zurück. Und ich versteh nicht ganz, was da passiert. Woher kommen $seen, $a und $b her? Und warum wird %seen nicht verwendet?

Ad get_unique: Das ist "eigentlich" nur ausgelagert, was z.B. "schon immer" (noch) in RHASSPY_allRhasspyChannels steht.

Die modifizierte Form kam durch Perlcritic und den im/über der Funktion stehenden Link aus stackoverflow, da habe ich jetzt auch den Hinweis gefunden, dass das Probleme geben kann, wenn das array nicht sortiert ist.

Würde daher die Vor-Sortiererei mal noch austesten:
sub get_unique {
    my @arr    = sort shift; #we may need to sort, see https://stackoverflow.com/a/30448251
    my $sorted = shift; #true if shall be sorted (longest first!)
    my %seen;
   
    #method 2 from https://stackoverflow.com/a/43873983
    my @unique = grep {!$seen{$_}++} @arr;

    return @unique if !$sorted;

    my @sorted = sort { length($b) <=> length($a) } @unique;
    return @sorted;
}
%seen wird definiert, und dann die noch nicht vorhandenen Hash-Elemente mit "Zahlen" belegt. Ist also eigentlich auch nichts anderes wie das, was vorher da stand, nur etwas komprimierter. Wenn's nicht funktioniert, muss da dann einfach statt "method 2" die alte Zeile rein:
# Doubletten rausfiltern
%roomsHash = map { if (defined($_)) { $_, 1 } else { () } } @rooms;
@rooms = keys %roomsHash;
Wobei %roomsHash eben %seen heißt und @rooms @unique...

$a und $b sind "Perl-specials": Laufvariablen für's sortieren. Daher gibt es Leute, die dringlich darauf hinweisen, dass deren Verwendung im "normalen" Kontext nicht stattfinden sollte (das ist der Hintergrund, weswegen ich jedes Mal, wenn mir eines vor die Flinte läuft @a in @arr umbenenne ;) ).

---

Was das $language-Thema angeht, habe ich vernommen, dass wir eine Pause einlegen sollten. Ich _glaube_ aber, dass der Aufwand für den Rückbau fast größer ist wie der Versuch, das vollends (in Grundzügen) in den bereits angelegten Teilen erst mal zum Laufen zu bringen und werde das noch in diese Richtung angehen (ich habe mal wieder was übersehen, als ich vorhin geantwortet habe: der Plan war schon immer, eigentlich auf den internen Hash zuzugreifen und eigentlich in den meisten Fällen auf $language verzichten zu können (nach der Initialisierung)...

Sätze aufteilen kann nicht die Lösung sein, das macht es nur unnötig kompliziert. Die Sprachkonfiguration muss m.E. stattdessen in separate files, wobei je nach Sprache bzw. Userkonfiguration dann genau eine ausgewählt/eingelesen wird.

Muss mal hirnen, wie ich ggf. den Rückmeldesatz testweise ermitteln kann, da wäre es hilfreich, noch einen topic-message-Datensatz zu haben, mit dem das ausgelöst wird...

Danke für die Infos! Ich schau mir das an. Im Moment wundere ich mich noch ein bißchen, dass in get_unique nicht alle Devices ankommen. Aber das kann meinem fehlendem Perl-Grundverständnis geschuldet sein.

Guter Hinweis mit $a und $b!

Rückbau? Warum sollten wir etwas zurück bauen? Der Timer ist gerichtet, wenn man eine Zeile ein- und eine andere auskommentiert. Der Rest funktioniert ja soweit. Sofern man kein Reload des Moduls macht ;).

Topic für welchen Rückmeldesatz hättest du gerne?

Zitat von: drhirn am 02 März 2021, 10:22:25
Danke für die Infos! Ich schau mir das an. Im Moment wundere ich mich noch ein bißchen, dass in get_unique nicht alle Devices ankommen. Aber das kann meinem fehlendem Perl-Grundverständnis geschuldet sein.

Na ja, nach dem, was du schilderst, kommen nicht alle raus...
Aber vielleicht hast du recht und man müsste erst mal checken, ob da alles reingeht, was soll... Hab's jedenfalls so umgestellt, dass nur die Referenz auf das Array übergeben wird, sollte so oder so besser sein...

Zitat
Rückbau? Warum sollten wir etwas zurück bauen? Der Timer ist gerichtet, wenn man eine Zeile ein- und eine andere auskommentiert. Der Rest funktioniert ja soweit. Sofern man kein Reload des Moduls macht ;) .

Guter Hinweis! Das mit dem Auskommentieren wäre eine Idee, dann können wir ggf. auch weiter recht einfach testen :) .
Jetzt sollte das ganze auch einen reload des Moduls überleben, derselbe Webfehler war btw. auch in $prefix drin gewesen, hoffe, das auch an der Stelle beseitigt zu haben.

ZitatTopic für welchen Rückmeldesatz hättest du gerne?

Eigentlich weniger der Rückmeldesatz, sondern das Timer-Kommando; was dann rauskommt, sollte ja im Reading "voiceResponse" zu sehen sein, oder? Werden die Parameter aufgelöst, müßte da dann ja auch was lesbares stehen...
Na ja, wie dem auch sei, die "Default"-Answers berücksichtigen jedenfalls die Sprache (brauchte ich zum Testen...).

Mal sehen, wann wir die Frage bekommen, wann man den Hash über eine externe Datei einlesen kann, damit das Ding spanisch (oder französisch) spricht...
(Ziel wäre, den englischen default (?) im Modul zu lassen, und alles andere extern. So hat man ein "Musterpattern" für einen JSON-Editor im Modul und kann dann ggf. eigene Sprachdateien dafür erstellen...

Aha, aha, jetzt kommen alle Devices an. Sehr gut! Doppelte Einträge werden aber nicht mehr gelöscht. Und bei mehreren "devices" ist eine eckige Umklammerung zuviel:

Updating Rhasspy Slots with data (de): {"de.fhem.Color":["grün","blau","gelb","rot"],"de.fhem.Device":[["Musik","deckenlampe","licht","lampe","radio","licht"]],"de.fhem.MediaChannels":[["orf eins","orf zwei","orf drei"]],"de.fhem.NumericType":["Helligkeit"],"de.fhem.Room":[["bad","küche","bad","wohnzimmer","schlafzimmer"]]}


Die Sprache übersteht einen Reload. Gute Arbeit!

Bzgl. Timer:

Msg: hermes/intent/de.fhem_SetTimer => {"input": "taimer im bad auf 10 minuten", "intent": {"intentName": "de.fhem:SetTimer", "confidenceScore": 1.0}, "siteId": "wohnzimmer", "id": null, "slots": [{"entity": "de.fhem.Room", "value": {"kind": "Unknown", "value": "bad"}, "slotName": "Room", "rawValue": "bad", "confidence": 1.0, "range": {"start": 10, "end": 13, "rawStart": 10, "rawEnd": 13}}, {"entity": "rhasspy/number", "value": {"kind": "Number", "value": 10}, "slotName": "Value", "rawValue": "zehn", "confidence": 1.0, "range": {"start": 18, "end": 20, "rawStart": 18, "rawEnd": 22}}, {"entity": "Unit", "value": {"kind": "Unknown", "value": "minuten"}, "slotName": "Unit", "rawValue": "minuten", "confidence": 1.0, "range": {"start": 21, "end": 28, "rawStart": 23, "rawEnd": 30}}], "sessionId": "wohnzimmer-snowboy-a4ab8b5e-da43-402f-bf90-4dc8a6bb17d7", "customData": null, "asrTokens": [[{"value": "taimer", "confidence": 1.0, "rangeStart": 0, "rangeEnd": 6, "time": null}, {"value": "im", "confidence": 1.0, "rangeStart": 7, "rangeEnd": 9, "time": null}, {"value": "bad", "confidence": 1.0, "rangeStart": 10, "rangeEnd": 13, "time": null}, {"value": "auf", "confidence": 1.0, "rangeStart": 14, "rangeEnd": 17, "time": null}, {"value": "10", "confidence": 1.0, "rangeStart": 18, "rangeEnd": 20, "time": null}, {"value": "minuten", "confidence": 1.0, "rangeStart": 21, "rangeEnd": 28, "time": null}]], "asrConfidence": null, "rawInput": "taimer im bad auf zehn minuten", "wakewordId": "snowboy", "lang": null}

AT sieht dann so aus:
defmod timer_bad at 2021-03-02T13:35:17 set Rhasspy speak siteId="bad" text="taimer abgelaufen";;setreading Rhasspy timer_bad 0

voiceResponse:
Taimer in $room gesetzt auf $value $unit.

Hmm, dann vermutlich besser nicht die Referenz übergeben, sort könnte genügen? Hab's mal ohne Referenzierung... (Um dann auf unter 100 violations zu kommen, habe ich das get_unique() noch an anderer Stelle eingebaut. 8) ). 

Bzgl. Sprache:  ;D 8) ;D
Die ersten Schnipsel für FileRead sind jetzt auch drin, aber das ist noch nicht effektiv funktional und braucht nach dem Fertigstellen dann noch Tests.

Jetzt klappt das auch mit den Variablen, aber man braucht einen ziemlichen Umweg, habe daher noch RHASSPY_EvalSpecialsDefaults() etwas optimiert.
Wird halt "tricky" werden zu erklären, wann welche Variablen gehen und wann nicht.

Nachtrag: Wenn ich noch ein Beispiel für CustomIntent (Attribut + myUtils-Codeschnipsel) bekomme, kann ggf. auch mal checken, ob man das noch vereinfachen kann bzw. auch im helper-hash vorhalten. Werde im Moment aber aus dem Code nicht recht schlau, was der eigentlich im einzelnen tun soll...

Jetzt ist da halt wieder das Problem, dass nur ein Device/Raum/etc. übergeben wird ;)

print Dumper(@arr) in Zeile 385 bring:

$VAR1 = 'Musik';


print Dumper(@devices) in Zeile 433 meldet

$VAR1 = 'Musik';
$VAR2 = 'deckenlampe';
$VAR3 = 'licht';
$VAR4 = 'lampe';
$VAR5 = 'radio';
$VAR6 = 'licht';


Und ein print Dumper (@_) in Zeile 381

$VAR1 = 'Musik';
$VAR2 = 'deckenlampe';
$VAR3 = 'licht';
$VAR4 = 'lampe';
$VAR5 = 'radio';
$VAR6 = 'licht';
$VAR7 = 1;


Sehr verwirrend

Und wenn das für's Verständnis hilft, hier ist die DEF der "Deckenlampe":

defmod lampe1 dummy
attr lampe1 userattr lightSceneParamsToSave lightSceneRestoreOnlyIfChanged:1,0 rhasspyChannels:textField-long rhasspyColors:textField-long
attr lampe1 readingList brightness rgb
attr lampe1 rhasspyChannels orf eins=set lampe1 on\
orf zwei=set lampe1 off\
orf drei=set lampe1 on
attr lampe1 rhasspyColors rot=rgb FF0000\
grün=rgb 00FF00\
blau=rgb 0000FF\
gelb=rgb 00F000
attr lampe1 rhasspyMapping SetOnOff:cmdOn=on,cmdOff=off\
GetOnOff:currentVal=state,valueOff=off\
GetNumeric:currentVal=brightness,type=Helligkeit\
SetNumeric:currentVal=brightness,minVal=0,maxVal=255,map=percent,cmd=brightness,step=1,type=Helligkeit\

attr lampe1 rhasspyName deckenlampe,licht
attr lampe1 rhasspyRoom küche,bad
attr lampe1 room Rhasspy
attr lampe1 setList brightness rgb toggle on off
attr lampe1 useSetExtensions 1


Hmm, habe zwischenzeitlich wieder in Richtung der Ausgangsversion umgebaut.

Das hier ist dir vermutlich entgangen:

Zitat von: Beta-User am 02 März 2021, 15:28:45
Nachtrag: Wenn ich noch ein Beispiel für CustomIntent (Attribut + myUtils-Codeschnipsel) bekomme, kann ggf. auch mal checken, ob man das noch vereinfachen kann bzw. auch im helper-hash vorhalten. Werde im Moment aber aus dem Code nicht recht schlau, was der eigentlich im einzelnen tun soll...

Updating Rhasspy Slots with data (de): {"de.fhem.Color":["HASH(0x56360372fdf8)"],"de.fhem.Device":["HASH(0x56360372f870)"].... :D

Sorry, das ist mir wirklich entgangen. Ich hab nur den einen Custom Intent von JensS. Hab das nie verwendet. Der sieht aber auf jeden Fall so aus:


sub Respeak(){
    my $name = "Rhasspy"; # Rhasspy durch eigenen Rhasspy-Device-Namen ersetzen
    my $Response = ReadingsVal($name,"voiceResponse","Ich kann mich nicht mehr erinnern");
    return $Response;
}


Und das Rhasspy-Attribut dazu:

attr Rhasspy rhasspyIntents Respeak=Respeak()



--edit--
Da wäre noch die Erklärung von Thyraz dazu für's Snips-Modul: https://github.com/Thyraz/Snips-Fhem#f%C3%BCr-fortgeschrittene-eigene-custom-intents-erstellen-und-in-fhem-darauf-reagieren

OK, das könnte weiterhelfen...

Hab's jetzt an anderer Stelle dereferenziert und vollends (?) auf die get_unique() umgebaut...

Was custom intent angeht, scheint das via parseParams dann wirklich einfacher zu gehen, mal sehen.

Updating Rhasspy Slots with data (de): {"de.fhem.Color":1,"de.fhem.Device":1,"de.fhem.MediaChannels":1,"de.fhem.NumericType":1,"de.fhem.Room":1}

Jetzt haben wir dann bald alle Möglichkeiten durch :D

puh, jetzt sollte es gehen...

Jeeeeee :)

Was war jetzt der Schlüssel zum Erfolg?

Dereferenzierung des übergebenen Parameters... (shift bei get_unique() vergleichen).

Gut, da wäre ich nie drauf gekommen.

Hui, und der Timer redet auch wieder richtig! Ich bin grenzenlos begeistert.

Für mehr Tests habe ich jetzt leider keine Zeit. Da wollen Mäuler gestopft werden. Ich hoff, ich komm morgen dazu.

Danke dir!

So, hoffe, es hat vielfach gemundet und schaffe mal Platz für noch mehr Tests:

- Der Parser für die eigenen Intents ist umgebaut, und der Weg macht nach meinem jetzigen Verständnis auch Sinn, wenn man Parameter aus der Rhasspy-Analyse mitgeben will (wie bei der Wikipedia-Anfrage). Anm.: Für parameterlose Perl-aufrufe ist m.E. der Shortcuts-Weg der elegantere.

Allerdings ist mir völlig unklar, warum da scheinbar immer der $hash (->RHASSPY-Instanz) mit übergeben wird? Müßte eigentlich bei der hier üblichen Notation der Perl-Funktionen in myUtils mit Prototypen Mismatches werfen. Aber vielleicht übersehe ich auch mal wieder was...
Stand: Ungetestet.

- die deutsche Sprachkonfiguration ist jetzt außerhalb des Moduls untergebracht,  ist es auch configDB-kompatibel 8) (einen Test betr.  Migration nach configDB habe ich aber nicht gemacht).
Kann die nicht geladen werden, wird eben englisch gesprochen...
(Der englische default-Teil sollte vermutlich auch noch JSON-encoded abgelegt werden, dann müßte es auch mit o'clock funktionieren.)

Soweit erkennbar, klappt es auch, die Sprach-Daten über
set <rhasspy> reinit language neu einzulesen, wenn man was angepasst hat.
Die als Muster angehängte cfg enthält - soweit ich das überblicken kann - alle "de-Strings" und damit mehr, als im Moment aufgelöst werden können, und mit der (im Modul bereits vorher vorhandenen) eval { }-Variante können auch Variablen relativ einfach aufgelöst werden :) . (siehe time und weekday-requests, wobei ich mir nicht sicher bin, ob es Sinn macht, für jede mögliche Frage eine Routine zu basteln).

Bestimmte Dinge, die regional unterschiedlich sein können, sind jetzt optional (Punkt=>Komma, mutated_vovels).

Was vermutlich (in weiten Teilen) nicht optimal ist, ist die Verwendung von regexen als keys für die Hashes. Das aufzudröseln, wäre vermutlich sinnvoll, allerdings sollten wir einen Weg finden, wie man das machen kann, ohne alle Texte mehrfach eingeben zu müssen... Könnte man auch über loops lösen, ist aber m.E. unelegant. Ging jetzt aber erst mal darum den Weg zu zeigen, wie man Sprache und Code einigermaßen entkoppeln kann und das Regexen ggf. durch Hash-Lookups schneller zu erledigen. Von daher würde mich erst mal interessieren, ob das ein guter/gangbarer Weg ist...

Überhaupt Doppelarbeit: eigentlich müßte es in Teilen doch für sowas Standardlibs geben, die man anzapfen könnte...? Also, falls da jemand was kennt?

Na ja, wie dem auch sei: erst mal viel Spaß beim Testen und Überlegen, ob das in dieser Form prinzipiell Sinn macht oder nicht. 8)

Nachtrag - "Bedienungsanleitung":
Sprachfile irgendwohin speichern, wo fhem Zugriff hat, also z.B. nach /opt/fhem/rhasspy-de.cfg (fhem:dialout).
In das configFile-Attribut den Pfad geben:
attr <rhasspy> configFile./rhasspy-de.cfg

...und nun wird es experimentell...

Diese Version kann dann erst mal in wesentlichen Teilen nur deutsch, müßte aber dafür alle Vergleiche usw. aus der Sprachfile ziehen. Will sagen: Spanisch ist im Bereich des Möglichen 8) .

Wenn das klappt, müßte man erst überlegen, ob die JSON-Struktur so "gut" (auch im Sinne von ggf. ausbaufähig) ist, und wenn das soweit geklärt ist dann asap ins Englische übersetzen, damit keiner auf die Nase fällt, der es ohne Sprachdatei versucht...

EDIT: jetzt sollte auch der englische Teil vollständig sein...

Ich habe - wie gesagt - zur Zeit ein bisschen viel um die Ohren. Drum war ich da so still. Heute sieht's aber ganz gut aus. Werde daher gleich mal anfangen zu testen. Hab da ja einiges aufzuholen.

Zuerst mal: Der aktuelle Stand von dir ist im Github in Version 0.4.0beta verewigt. Die rhasspy-de.cfg habe ich auch ins Repo aufgenommen.

Dann: Das funktioniert :). Zumindest hat ein Kurz-Test nichts Gegenteiliges ergeben.

Und zuletzt: Danke!

Eine Bitte hätte ich noch: Könntest du bitte bei Gelegenheit die CRef mal überfliegen? Ich bin mir nicht ganz sicher, ob ich da alles dokumentiert habe. Und richtig. Ich mach mich in der Zwischenzeit ans Testen.

Zitat von: drhirn am 05 März 2021, 11:04:19
Ich habe - wie gesagt - zur Zeit ein bisschen viel um die Ohren. Drum war ich da so still. Heute sieht's aber ganz gut aus. Werde daher gleich mal anfangen zu testen. Hab da ja einiges aufzuholen.

Kein Problem, so hatte ich auch Ruhe, um den einen oder anderen Gedanken auszutesten (nachdem ich mir überlegt hatte, wie man das ohne Rhasspy testen kann)...

Zitat
Zuerst mal: Der aktuelle Stand von dir ist im Github in Version 0.4.0beta verewigt. Die rhasspy-de.cfg habe ich auch ins Repo aufgenommen.

Dann: Das funktioniert :) . Zumindest hat ein Kurz-Test nichts Gegenteiliges ergeben.

8)
Danke für die Rückmeldung!

Ist denn (in groben Zügen) klar, wie es funktioniert?

Zitat
Eine Bitte hätte ich noch: Könntest du bitte bei Gelegenheit die CRef mal überfliegen? Ich bin mir nicht ganz sicher, ob ich da alles dokumentiert habe. Und richtig. Ich mach mich in der Zwischenzeit ans Testen.

Mache ich bei Gelegenheit.

Ich habe aber gemerkt, dass noch ein Teil der Rückmeldungen/Abfragen noch gar nicht fertig ist (da wird dann noch auf die harten de-Codes zurückgegriffen.

Das ist in den beiden angehängten Dateien zum Teil korrigiert, vermutlich kannst du daran gut sehen, wie die Baustelle in etwa bearbeitet werden soll - wir brauchen dann hoffentlich nur am Ende noch eine Abfrage, ob wir einen Hash vor uns haben (dann $response->{$isNumber}) oder nicht...
Da scheint mir aber auch noch ein "Loch" in der cfg zu sein.
Habe aber im Moment noch keinen Plan, wie ich das Testen kann, von daher wäre es gut, wir wären soweit sicher, dass diese Baustelle bis dahin erst mal funktioniert. Da habe ich nur noch keinen Plan, wie ich das selbst testen könnte...

ZitatUnd zuletzt: Danke!

Gerne!

EDIT: Nachtrag noch zur Statistik

Total lines:	2439
Code lines:	1549
Comment lines:	317
Data lines:	1
Blank lines:	410
POD lines:	162
Total violations:	70
Severity 5:	0
Severity 4:	0
Severity 3:	70
Total subroutines:	64
Average McCabe:	6,95

Zitat von: Beta-User am 05 März 2021, 11:17:09
(nachdem ich mir überlegt hatte, wie man das ohne Rhasspy testen kann)

Ich bin jederzeit gerne bereit, dich bei einer Rhasspy-Test-Installation zu begleiten. Mit Docker ist das fix erledigt. Und kann rückstandslos wieder gekübelt werden. Brauchst nur ein Mikro/Webcam für den Betrieb. Wenn's dich interessiert.

ZitatIst denn (in groben Zügen) klar, wie es funktioniert?

In groben Zügen. Im Detail hab ich's mir noch nicht angesehen.

Hast du in der letzten 10_RHASSPY.pm Änderungen von gestern wieder rückgängig gemacht? Bin gerade ein bisschen verwirrt.

Zitat von: drhirn am 05 März 2021, 11:57:08
Hast du in der letzten 10_RHASSPY.pm Änderungen von gestern wieder rückgängig gemacht? Bin gerade ein bisschen verwirrt.

Au; wenn, dann unbeabsichtigt... :o >:(

(Basis war aber (hoffentlich) meine gestrige Version, nicht deine von github, von daher sind gewisse Differenzen normal).

Grummel, vermutlich muss ich mir das selbst anschauen, was ich da angerichtet habe; nicht alles dürfte falsch sein... (geht aber nicht sofort). Vielleicht kannst du ja auch versuchen nachzuvollziehen, was ich mir mit den heutigen Änderungen so gedacht habe (da ist aber auch einiges noch (auskommentiert) drin, das nicht funktioniert hat).

Zitat von: drhirn am 05 März 2021, 11:42:50
Ich bin jederzeit gerne bereit, dich bei einer Rhasspy-Test-Installation zu begleiten. Mit Docker ist das fix erledigt. Und kann rückstandslos wieder gekübelt werden. Brauchst nur ein Mikro/Webcam für den Betrieb. Wenn's dich interessiert.

Danke für's Angebot, aber so einfach ist es vermutlich dann doch nicht:
- Die docker-Basis ist derzeit bei keinem meiner Server installiert (ok, kann man auch rückstandsfrei, und evtl. findet sich ja noch ein alter Pi im Keller...)
- Mikro ist zwar vorhanden, aber wenn, dann nur eins mit Kabel oder ich muss mir was mit BT überlegen.
=> relativ viel Aufwand, denn selbst wenn ich das soweit dann zusammengeschustert habe, fehlen zu guter Letzt- die entsprechenden settings in meinen FHEM-Devices, damit man die abfragen kann...

Kurzum: mit den entsprechenden dummy- (oder mqtt2-) Devices und passenden Topic-payload-Infos kann ich das "gezielter" simulieren ;) . Habe mir nur noch nichts überlegt für die Abfragen usw., das ist einfach zu neu.

Wenn, dann würde ich überlegen wollen, ob ich ein "Bedienungs-FHEM" bastle und das dann via MQTT_GENERIC_BRIDGE mit den "eigentlichen Devices" fülle und darauf dann Rhasspy loslasse - setzt aber voraus, dass es möglich wäre, eine Art "einfacher Funk-Mikrophone" zu nutzen, um einen zentralen Rhasspy anzusteuern. (Super wäre eine handy-app, die man kurz aktivieren kann, damit die den "Sound" an die Zentrale schickt, aber sowas scheint es nicht zu geben).

Zitat
Im Detail hab ich's mir noch nicht angesehen.

Grundzüge sind erst mal ok, in die Details kommt man am einfachsten rein, wenn man sich die Struktur der Sprachdaten im list anzeigen läßt.

Tipp für's Editieren der JSON-Struktur: https://jsoneditoronline.org/ (aber ruhig auch mal austesten, was passiert, wenn du es mit einem "malformed" versuchst...).

Zitat von: Beta-User am 05 März 2021, 12:14:43
Danke für's Angebot, aber so einfach ist es vermutlich dann doch nicht:

Ich teste auf meinem Windows-Rechner. Der hat sowieso Boxen und Webcam. Docker startet eine FHEM- und zwei Rhasspy-Instanzen. Und als FHEM-Devices habe ich ein paar Dummies.

Zitat von: Beta-User am 05 März 2021, 12:14:43
(Super wäre eine handy-app, die man kurz aktivieren kann, damit die den "Sound" an die Zentrale schickt, aber sowas scheint es nicht zu geben).

https://github.com/razzo04/rhasspy-mobile-app

Hab ich aber noch nicht ausprobiert.

Hm, also: Hab's mal soweit überflogen, auf Basis deiner 0.4.0 beta von ca. 11:00 Uhr (ec5457bcd3a24848ddb41b0433f98e3da4cce6da).

Da sind nicht die riesigen Änderungen drin gewesen gegenüber dem, was ich gestern gemacht hatte, oder ich übersehe was.

Habe dann beim Überfliegen noch den einen oder anderen kleineren Punkt geändert, aber (hoffentlich) nichts substantielles, playWav sollte auch weiter gehen.

Das mit der App ist interessant, vielleicht werde ich doch noch zum aktiven Nutzer...? Mal sehen... (Wenn, komme ich auf dein Angebot zurück, falls Fragen auftauchen :) ).

playWav geht nicht mehr. $namedParams ist leer.
Drum hatte ich das umgebaut. In $cmd steht eh alles drinnen, was wir brauchen.

Aber mal was ganz was anderes, damit ich das auch noch verstehe.

Ich hab - weil ich gerade eine neu bekommen habe - einen Shelly Motion mit dem Rhasspy-MQTT verbunden. Und die "subscriptions" vom MQTT2_CLIENT um "shellies/+" ergänzt.

Das Device sieht so aus:

defmod MQTT2_rhasspyMQTT2 MQTT2_DEVICE rhasspyMQTT2
attr MQTT2_rhasspyMQTT2 IODev rhasspyMQTT2
attr MQTT2_rhasspyMQTT2 model shellymotion
attr MQTT2_rhasspyMQTT2 readingList rhasspyMQTT2:shellies/announce:.* { json2nameValue($EVENT) }\
rhasspyMQTT2:shellies/shellymotionsensor-60A42397610C/status:.* { json2nameValue($EVENT) }\
rhasspyMQTT2:shellies/shellymotionsensor-60A42397610C/online:.*  online


Stimmt das so? Irgendwie glaube ich ja. Weil zumindest die "annouce"-Readings angelegt und aktualisiert werden. Alle anderen aber nicht.

Da ich mir sicher bin, dass die Frage irgendwann kommt: Ist das die richtige Vorgangsweise und wie bekomme ich die anderen Readings auch noch?

Zitat von: drhirn am 05 März 2021, 15:19:12
playWav geht nicht mehr. $namedParams ist leer.
Drum hatte ich das umgebaut. In $cmd steht eh alles drinnen, was wir brauchen.

OK, anbei der Versuch, das playWav wieder auf deinen Stand zurückzudrehen, Media Control sollte jetzt auch spanisch können...
(Falls du Test-dummies und topic/payload hast, kann ich gerne auch versuchen, das zu testen...)

(Werde noch versuchen, auch die noch fehlenden "isNumber"-Referenzen zu ergänzen, dann sollte das erst mal soweit vollständig sein).

Zitat von: drhirn am 05 März 2021, 15:39:43
Aber mal was ganz was anderes, damit ich das auch noch verstehe.
[...]
Da ich mir sicher bin, dass die Frage irgendwann kommt: Ist das die richtige Vorgangsweise und wie bekomme ich die anderen Readings auch noch?

Prinzipiell sollte das Erweitern der subscriptions (und Aktivieren von autocreate/simple) der richtige Weg sein, es kommt ja auch was an.

ABER: Man sollte bei CLIENT ein "Sortierdevice" zwischenschalten, weil sonst alles, was über den CLIENT kommt erst man per autocreate dem Device zugeschlagen wird, das die passende CID hat, also bei dir MQTT2_rhasspyMQTT2 (CID: rhasspyMQTT2). Daher: dieses Device via attrTemplate (General bridge oder so) mit einer bridgeRegexp versehen. Dann verhält sich das (bei default-Topics in den externen Clients wie dem Shelly) zusammen fast wie MQTT2_SERVER und "sortiert" passenden Input dann jeweils in ein eigenes Device.

Das ganze hat aber noch einen "Haken": über den "shellies/"-Topic kommen auch die an die Shelly gerichteten Kommandos wieder zurück. Daher sollte man die via ignoreRegexp am IO "ausknipsen".
Das war jetzt die "Kurzform"...

Und die bridgeRegexp, lass ich die so? Shellie kommt ja vor. Oder soll ich da alle anderen Einträge löschen?

Zitat von: JensS am 05 März 2021, 15:47:10
@drhirn && Beta-User
Die Möglichkeiten von Rhasspy sind u.a. durch CustomIntents erweiterbar. Ist es möglich/ratsam, die Erweiterungen in separate .pms in einem Unterordner RHASSPY zu legen und diese über Github zentral zur Verfügung zu stellen? So könnte man sich sein Rhasspy, je nach Bedarf, durch wenige Anpassungen zusammenstellen.

Vielleicht nochmal in dem Zusammenhang eine kurze Bezugnahme auf das hier:

Zitat von: Beta-User am 04 März 2021, 08:04:54
- Der Parser für die eigenen Intents ist umgebaut, und der Weg macht nach meinem jetzigen Verständnis auch Sinn, wenn man Parameter aus der Rhasspy-Analyse mitgeben will (wie bei der Wikipedia-Anfrage). Anm.: Für parameterlose Perl-aufrufe ist m.E. der Shortcuts-Weg der elegantere.

Allerdings ist mir völlig unklar, warum da scheinbar immer der $hash (->RHASSPY-Instanz) mit übergeben wird? Müßte eigentlich bei der hier üblichen Notation der Perl-Funktionen in myUtils mit Prototypen Mismatches werfen. Aber vielleicht übersehe ich auch mal wieder was...
Stand: Ungetestet.

Generell bin ich bei drhirn: Wenn es möglich ist, die Aufgabe außerhalb von FHEM abzuwickeln, haben vermutlich mehr Leute was davon, wenn man die Möglichkeiten der Rhasspy-scripte erweitert.

Ich sehe daher die beiden Optionen "Shortcut" und "rhasspyIntents" eher als Option, flexibel eine Interaktion zu ermöglichen, bei der wirklich FHEM benötigt wird.
Interessiert mich in der Perl-Verarbeitung nichts, was Rhasspy an Infos mitschickt, sollte m.E. der "Shortcut"-Weg gewählt werden, da sind (hoffentlich) die Möglichkeiten einfacher, z.B. über den "r:"-Parameter auch sprach-agnostische Rückmeldungen einzubauen (will sagen: kann der User leichter anpassen, wie wenn er in myUtils rumfrickeln muss).
NUR, wenn für die Weiterverarbeitung in Perl Parameter aus der Vorverarbeitung in Rhasspy übergeben werden sollen, macht es m.E. überhaupt Sinn, über rhassypIntents zu gehen.
(So würde ich das auch in der cref darstellen; ad cref noch: ich würde empfehlen, die "named parameter"-Darstellung dort aufzunehmen, die "alte" Schreibweise ist nur ein Kompabilitäts-feature...)

(Ggf. könnten wir überlegen, ob wir die Option in Shortcuts einbauen sollten, $data komplett zu bekommen; funktioniert evtl. sogar heute schon). Dann macht rhassypIntents an sich wenig Sinn (außer für Kompabilität und um es dem geneigten User zu ersparen, ausdrückliche Hash-Werte abzufragen).

Mit beiden Parsern habe ich mich aber nur soweit beschäftigt, dass es kompatibel sein sollte; kann durchaus sein, dass es Optimierungsmöglichkeiten gibt.

Zitat von: drhirn am 05 März 2021, 16:16:43
Und die bridgeRegexp, lass ich die so? Shellie kommt ja vor. Oder soll ich da alle anderen Einträge löschen?

Laß, wie ist, schadet kaum. Du wirst sonst irgendwann wieder an mich denken, wenn du einen Tasmota in Betrieb nimmst oder sonst irgendwas, was grade noch nicht rumfleucht...

So, zum krönenden Abschluss noch was zum Testen, jetzt sollte es auch spanische (oder zumindest englische) Rückmeldungen aus RHASSPY_handleIntentGetNumeric() geben können, und ein paar Klammern etc. habe ich auch noch "erlegt" (in der Hoffnung, dass es trotzdem noch korrekt tut, aber übersichtlicher ist...
(McCabe meint, es sei einfacher, aber das halte ich für ein Gerücht ;D ...)

Zitat von: Beta-User am 04 März 2021, 08:04:54
Allerdings ist mir völlig unklar, warum da scheinbar immer der $hash (->RHASSPY-Instanz) mit übergeben wird? Müßte eigentlich bei der hier üblichen Notation der Perl-Funktionen in myUtils mit Prototypen Mismatches werfen. Aber vielleicht übersehe ich auch mal wieder was...

Ok, habe jetzt rund um die App-Beiträge gesehen, wann es eingebaut wurde.

Rückmeldung: Finde das in der jetzigen Form nicht gut, das Prinzip sollte sein, dass man zurückbekommt, was man "bestellt", dann wird auch der Unterschied zu "Shortcuts" für den Anwender m.E. klarer erkennbar.
Würde daher vorschlagen, dass wir ein paar "Keywords" einbauen, damit man "HASH", "NAME" und "DATA" "bestellen" kann, also optional. V.a. an @JensS: Einwände oder bessere Vorschläge?

Zitat von: Beta-User am 04 März 2021, 16:33:17
Wenn das klappt, müßte man erst überlegen, ob die JSON-Struktur so "gut" (auch im Sinne von ggf. ausbaufähig) ist [...]

Die Hash-Struktur war irgendwie sehr aus dem Handgelenk geschüttelt, wenn es also mit den ganzen Referenzierungen klappt wie erhofft, sollte man die m.E. schnellstmöglich überarbeiten, ich glaube nämlich _nicht_, dass mir an der Stelle mehr gelungen ist wie "funktioniert halt irgendwie und ist nicht komplett seltsam"...

@JensS:
Danke für die schnelle Rückmeldung.
So?
sub RHASSPY_handleCustomIntent {
    my $hash       = shift // return;
    my $intentName = shift;
    my $data       = shift;
   
    if (!defined $hash->{helper}{custom} || !defined $hash->{helper}{custom}{$intentName}) {
        Log3($hash->{NAME}, 2, "handleIntentShortcuts called with invalid $intentName key");
        return;
    }
    my $custom = $hash->{helper}{custom}{$intentName};
    Log3($hash->{NAME}, 5, "handleCustomIntent called with $intentName key");
   
    my ($intent, $response, $room);

    if (exists $data->{Device} ) {
      $room = RHASSPY_roomName($hash, $data);
      $data->{Device} = RHASSPY_getDeviceByName($hash, $room, $data->{Device}); #Beta-User: really...?
    }

    my $subName = $custom->{function};
    my @paramNames = $custom->{args};

    if (defined $subName) { #might not be necessary...
        my @params;
        for (@paramNames) {
            if ($_ eq 'NAME') {
               $_ = $hash->{NAME};
            } elsif ($_ eq 'HASH') {
               $_ = $hash;
            } elsif ($_ eq 'DATA') {
                $_ = $data;
            } elsif (defined $data->{$_}) {   
                $_ = $data->{$_}
            }
        }
        my $params = join q{,}, @params;
        my $cmd = qq{ $subName( $params) };
        Log3($hash->{NAME}, 5, "Calling sub: $cmd");
        my $error = AnalyzePerlCommand($hash, $cmd);
        $response = $error if $error !~ m{Please.define.*first}x;
     
    }
    $response = $response // RHASSPY_getResponse($hash, 'DefaultError');

    # Antwort senden
    return RHASSPY_respond ($hash, $data->{requestType}, $data->{sessionId}, $data->{siteId}, $response);
}

(Wobei mir grade 'DefaultError' komisch vorkommt...)

Zitat von: JensS am 06 März 2021, 11:09:39
@Beta-User
Wie sieht dann mein Respeak aus?

Code Auswählen Erweitern

sub Respeak(){
my $name = "Rhasspy"; # Rhasspy durch eigenen Rhasspy-Device-Namen ersetzen
my $Response = ReadingsVal($name,"voiceResponse","Ich kann mich nicht mehr erinnern");
return $Response;
}


Gruß Jens

Biete mal 3-4 Alternativen an:
1. Aufruf ohne Parameter im Attribut: (Respeak=Respeak())
a)
Deine Variante sollte wie bisher funktionieren (mit deiner Version der sub in der .pm müßte es eigentlich einen Prototype-missmatch gegeben haben?).
b)
ohne Prototype gingen beide Varianten der sub in  der .pm:
sub Respeak{
my $name = "Rhasspy"; # Rhasspy durch eigenen Rhasspy-Device-Namen ersetzen
my $Response = ReadingsVal($name,"voiceResponse","Ich kann mich nicht mehr erinnern");
return $Response;
}


2. Aufruf mit Parameter im Attribut:
Wenn man die eigentlichen features dieses Attributs nutzen will, kann man (im Attribut) mit Parameter definieren; jetzt sollten gehen:
a) Respeak(NAME)

sub Respeak {
my $name = shift // q{Rhasspy};; # Rhasspy durch eigenen Rhasspy-Device-Namen ersetzen
my $Response = ReadingsVal($name,"voiceResponse","Ich kann mich nicht mehr erinnern");
return $Response;
}
Erläuterung: "//" ist "Perl-defined-or-operator. Gibt es was zum shiften, wird das als $name verwendet, ansonsten eben der dahinter hart vercodete Name.
Dies Variante funktioniert also auch, wenn man keinen NAME-Parameter angegeben hat...

b) Respeak(HASH)
sub Respeak {
my $hash = shift // return;
my $name = $hash->{NAME};
my $Response = ReadingsVal($name,"voiceResponse","Ich kann mich nicht mehr erinnern");
return $Response;
}
Hier geht dann ohne HASH nichts mehr...

So sieht man auch, warum es a) bisher ggf. Probleme gab, wenn man das "Zwangshash" übersehen hatte ($hash wird btw. in FHEM üblicherweise als erster Parameter übergeben...),
b) warum die shift-Variante ggf. direkter ist, was Ersatzwert-Zuweisung angeht;
c) dass das mit den Prototype-Definitionen nicht in allen Fällen (auch für Einsteiter) hilfreich ist.

Hoffe, das halbwegs verständlich aufgedröhselt zu haben?

(Anm.: Das feature "spiel's noch einmal, Sam!" würde ich als Standardfeature ansehen und vorschlagen, es direkt in das Modul zu integrieren. Soll aber der Maintainer entscheiden :P .

Zitat von: JensS am 06 März 2021, 13:06:52
@Beta-User
Alternative 2.a) hatte ich genau so gemacht. [...] Allerdings bringt shift nichts - es wird immer die Ersetzung bei undef gemacht. Sobald ich "Rhasspie" schreibe, hat Alexa Alzheimer.

::)
Zu schnell gestrickt meinerseits.

So könnte es klappen:
sub RHASSPY_handleCustomIntent {
    my $hash       = shift // return;
    my $intentName = shift;
    my $data       = shift;
   
    if (!defined $hash->{helper}{custom} || !defined $hash->{helper}{custom}{$intentName}) {
        Log3($hash->{NAME}, 2, "handleIntentShortcuts called with invalid $intentName key");
        return;
    }
    my $custom = $hash->{helper}{custom}{$intentName};
    Log3($hash->{NAME}, 5, "handleCustomIntent called with $intentName key");
   
    my ($intent, $response, $room);

    if (exists $data->{Device} ) {
      $room = RHASSPY_roomName($hash, $data);
      $data->{Device} = RHASSPY_getDeviceByName($hash, $room, $data->{Device}); #Beta-User: really...?
    }

    my $subName = $custom->{function};
    my @params = $custom->{args};

    if (defined $subName) { #might not be necessary...
        for (@params) {
            if ($_ eq 'NAME') {
               $_ = $hash->{NAME};
            } elsif ($_ eq 'DATA') {
                $_ = $data;
            } elsif (defined $data->{$_}) {   
                $_ = $data->{$_}
            }
        }
        my $params = join q{,}, @params;
        my $cmd = qq{ $subName( $params) };
        Log3($hash->{NAME}, 5, "Calling sub: $cmd");
        my $error = AnalyzePerlCommand($hash, $cmd);
        $response = $error if $error !~ m{Please.define.*first}x;
     
    }
    $response = $response // RHASSPY_getResponse($hash, 'DefaultError');

    # Antwort senden
    return RHASSPY_respond ($hash, $data->{requestType}, $data->{sessionId}, $data->{siteId}, $response);
}

"HASH" habe ich gleich wieder rausgeworfen, weil es m.E. ausreicht, wenn man eines von beidem zurückgibt. Habe zugunsten des NAME entschieden; für die Anwender ist es in der Regel einfacher, und wer Funktionen für "intern" vorbereiten will, kann den Hash auch aus %defs holen...

Mal für den Merkzettel:
Befehl nur mit Bestätigung ausführen, https://forum.fhem.de/index.php/topic,118986.0.html.

Vermutlich wäre sowas nicht allzu schwer zu verwirklichen, wenn man es erlaubt, genau einen Befehl zu "parken", zumindest iVm. "Shortcut". Da würde man einfach einen weiteren Parameter dazupacken (c=1 für "confirmation required" oder "c='soll ich wirklich den Server neu starten' ).

Nur, weil ich grade drüber gestolpert bin...

Hab jetzt auch die letzten Änderungen ins GitHub übernommen (0.4.0beta). Danke!

Zitat von: Beta-User am 05 März 2021, 17:27:32
und ein paar Klammern etc. habe ich auch noch "erlegt" (in der Hoffnung, dass es trotzdem noch korrekt tut, aber übersichtlicher ist...

Ist lustig, ich bin gewöhnt, dass man in jeder Programmiersprache, die ich "kenne", Klammern (richtig) setzen MUSS. Macht mich fertig, dass das da nicht so ist ;). Ich persönlich find's mit Klammern übrigens übersichtlicher.

Und jetzt seh ich mir den Rest eurer Unterhaltung an. Mir ist da im Überfliegen eine gute Idee von dir ins Auge gesprungen.

Mir ist gerade etwas beim Intent MediaControls bezüglich Sprache aufgefallen:

Man definiert einen Satz in Rhasspy z.B. so:
starte{Command:play} die wiedergabe $de.fhem.Device{Device}

Das Zeug in geschwungener Klammer, unter welchem "Namen" der Text davor in FHEM ankommt.
Z.B. bei Device wäre das dann Device=>Radio

Man kann aber für einen erkannten Text auch angeben, was in FHEM ankommen soll. Passiert in diesem Beispiel bei "{Command:play}". Wenn ich also "starte Radio" spreche, kommt in FHEM play Radio an.

play, stop, ... dürfen wir also nicht aus dem Sprach-File nehmen. Das muss immer gleich bleiben.

Wir können natürlich schon die jeweilige Sprache nehmen. Dann laufen wir aber Gefahr, dass der User etwas anderes in seinen Rhasspy-Sentences eingetragen hat, was wir in unserer Sprach-Datei haben.

Dasselbe auch bei GetNumeric.

Ich bastel dir übrigens gerade eine Liste mit Payloads, damit du testen kannst.

Das folgende File ist auch im GitHub. Ist ein Test-Device und Payloads für alle momentan verfügbaren Intents.

In der CRef habe ich übrigens ganz unten eine ToDo-Liste angehängt.


----Device----
defmod lampe1 dummy
attr lampe1 userattr lightSceneParamsToSave lightSceneRestoreOnlyIfChanged:1,0 rhasspyChannels:textField-long rhasspyColors:textField-long
attr lampe1 readingList brightness rgb
attr lampe1 rhasspyChannels orf eins=set lampe1 on\
orf zwei=set lampe1 off\
orf drei=set lampe1 on
attr lampe1 rhasspyColors rot=rgb FF0000\
grün=rgb 00FF00\
blau=rgb 0000FF\
gelb=rgb 00F000
attr lampe1 rhasspyMapping SetOnOff:cmdOn=on,cmdOff=off,response=Okidoki\
GetOnOff:currentVal=state,valueOff=off\
GetNumeric:currentVal=brightness,type=Helligkeit\
SetNumeric:currentVal=brightness,minVal=0,maxVal=255,map=percent,cmd=brightness,step=1,type=Helligkeit\
Status:response=Die Temperatur in der Küche beträgt [lampe1:brightness] Grad\
MediaControls:cmdPlay=play,cmdPause=pause,cmdStop=stop,cmdBack=previous,cmdFwd=next\

attr lampe1 rhasspyName deckenlampe,licht,radio
attr lampe1 rhasspyRoom küche,bad
attr lampe1 room Rhasspy
attr lampe1 setList brightness rgb toggle on off play stop pause next previous

----Payloads----
SetMute
Msg: hermes/intent/de.fhem_SetMute => {"input": "on", "intent": {"intentName": "de.fhem:SetMute", "confidenceScore": 1.0}, "siteId": "wohnzimmer", "id": null, "slots": [{"entity": "Value", "value": {"kind": "Unknown", "value": "on"}, "slotName": "Value", "rawValue": "gute nacht", "confidence": 1.0, "range": {"start": 0, "end": 2, "rawStart": 0, "rawEnd": 10}}], "sessionId": "wohnzimmer-snowboy-4db538ac-d4ad-4633-af0d-79134ea856c7", "customData": null, "asrTokens": [[{"value": "on", "confidence": 1.0, "rangeStart": 0, "rangeEnd": 2, "time": null}]], "asrConfidence": null, "rawInput": "gute nacht", "wakewordId": "snowboy", "lang": null}
Msg: hermes/intent/de.fhem_SetMute => {"input": "off", "intent": {"intentName": "de.fhem:SetMute", "confidenceScore": 1.0}, "siteId": "wohnzimmer", "id": null, "slots": [{"entity": "Value", "value": {"kind": "Unknown", "value": "off"}, "slotName": "Value", "rawValue": "guten morgen", "confidence": 1.0, "range": {"start": 0, "end": 3, "rawStart": 0, "rawEnd": 12}}], "sessionId": "wohnzimmer-snowboy-9cafa03f-726f-4076-a123-25634dd8899f", "customData": null, "asrTokens": [[{"value": "off", "confidence": 1.0, "rangeStart": 0, "rangeEnd": 3, "time": null}]], "asrConfidence": null, "rawInput": "guten morgen", "wakewordId": "snowboy", "lang": null}

Shortcuts:
Msg: hermes/intent/de.fhem_Shortcuts => {"input": "ton an", "intent": {"intentName": "de.fhem:Shortcuts", "confidenceScore": 1.0}, "siteId": "wohnzimmer", "id": null, "slots": [], "sessionId": "wohnzimmer-snowboy-cc4118d8-cb3b-4eb5-b4ed-99f18bb0fd85", "customData": null, "asrTokens": [[{"value": "ton", "confidence": 1.0, "rangeStart": 0, "rangeEnd": 3, "time": null}, {"value": "an", "confidence": 1.0, "rangeStart": 4, "rangeEnd": 6, "time": null}]], "asrConfidence": null, "rawInput": "ton an", "wakewordId": "snowboy", "lang": null}

SetOnOff:
Msg: hermes/intent/de.fhem_SetOnOff => {"input": "licht küche aus", "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": "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": "wohnzimmer-snowboy-2ee5ec15-58f4-41ad-aef7-63ec373714ab", "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 küche aus", "wakewordId": "snowboy", "lang": null}

GetOnOff:
Msg: hermes/intent/de.fhem_GetOnOff => {"input": "läuft radio wohnzimmer", "intent": {"intentName": "de.fhem:GetOnOff", "confidenceScore": 1.0}, "siteId": "wohnzimmer", "id": null, "slots": [{"entity": "Status", "value": {"kind": "Unknown", "value": "läuft"}, "slotName": "Status", "rawValue": "läuft", "confidence": 1.0, "range": {"start": 0, "end": 5, "rawStart": 0, "rawEnd": 5}}, {"entity": "de.fhem.Device", "value": {"kind": "Unknown", "value": "radio"}, "slotName": "Device", "rawValue": "radio", "confidence": 1.0, "range": {"start": 6, "end": 11, "rawStart": 6, "rawEnd": 11}}, {"entity": "de.fhem.Room", "value": {"kind": "Unknown", "value": "wohnzimmer"}, "slotName": "Room", "rawValue": "wohnzimmer", "confidence": 1.0, "range": {"start": 12, "end": 22, "rawStart": 12, "rawEnd": 22}}], "sessionId": "wohnzimmer-snowboy-9b65e415-bbd3-408b-80ae-651a0c9b7c2e", "customData": null, "asrTokens": [[{"value": "läuft", "confidence": 1.0, "rangeStart": 0, "rangeEnd": 5, "time": null}, {"value": "radio", "confidence": 1.0, "rangeStart": 6, "rangeEnd": 11, "time": null}, {"value": "wohnzimmer", "confidence": 1.0, "rangeStart": 12, "rangeEnd": 22, "time": null}]], "asrConfidence": null, "rawInput": "läuft radio wohnzimmer", "wakewordId": "snowboy", "lang": null}

SetNumeric:
Msg: hermes/intent/de.fhem_SetNumeric => {"input": "deckenlampe auf 50 prozent", "intent": {"intentName": "de.fhem:SetNumeric", "confidenceScore": 1.0}, "siteId": "wohnzimmer", "id": null, "slots": [{"entity": "de.fhem.Device", "value": {"kind": "Unknown", "value": "deckenlampe"}, "slotName": "Device", "rawValue": "deckenlampe", "confidence": 1.0, "range": {"start": 0, "end": 11, "rawStart": 0, "rawEnd": 11}}, {"entity": "rhasspy/number", "value": {"kind": "Number", "value": 50}, "slotName": "Value", "rawValue": "fünfzig", "confidence": 1.0, "range": {"start": 16, "end": 18, "rawStart": 16, "rawEnd": 23}}, {"entity": "Unit", "value": {"kind": "Unknown", "value": "prozent"}, "slotName": "Unit", "rawValue": "prozent", "confidence": 1.0, "range": {"start": 19, "end": 26, "rawStart": 24, "rawEnd": 31}}], "sessionId": "wohnzimmer-snowboy-0ae191fc-c0d7-47f5-9ead-8d19e7302c39", "customData": null, "asrTokens": [[{"value": "deckenlampe", "confidence": 1.0, "rangeStart": 0, "rangeEnd": 11, "time": null}, {"value": "auf", "confidence": 1.0, "rangeStart": 12, "rangeEnd": 15, "time": null}, {"value": "50", "confidence": 1.0, "rangeStart": 16, "rangeEnd": 18, "time": null}, {"value": "prozent", "confidence": 1.0, "rangeStart": 19, "rangeEnd": 26, "time": null}]], "asrConfidence": null, "rawInput": "deckenlampe auf fünfzig prozent", "wakewordId": "snowboy", "lang": null}
Msg: hermes/intent/de.fhem_SetNumeric => {"input": "deckenlampe auf 25", "intent": {"intentName": "de.fhem:SetNumeric", "confidenceScore": 1.0}, "siteId": "wohnzimmer", "id": null, "slots": [{"entity": "de.fhem.Device", "value": {"kind": "Unknown", "value": "deckenlampe"}, "slotName": "Device", "rawValue": "deckenlampe", "confidence": 1.0, "range": {"start": 0, "end": 11, "rawStart": 0, "rawEnd": 11}}, {"entity": "rhasspy/number", "value": {"kind": "Number", "value": 25}, "slotName": "Value", "rawValue": "fünfundzwanzig", "confidence": 1.0, "range": {"start": 16, "end": 18, "rawStart": 16, "rawEnd": 30}}], "sessionId": "wohnzimmer-snowboy-8f199cba-d4c6-46e5-989e-08ec167c20ea", "customData": null, "asrTokens": [[{"value": "deckenlampe", "confidence": 1.0, "rangeStart": 0, "rangeEnd": 11, "time": null}, {"value": "auf", "confidence": 1.0, "rangeStart": 12, "rangeEnd": 15, "time": null}, {"value": "25", "confidence": 1.0, "rangeStart": 16, "rangeEnd": 18, "time": null}]], "asrConfidence": null, "rawInput": "deckenlampe auf fünfundzwanzig", "wakewordId": "snowboy", "lang": null}

GetNumeric:
Msg: 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": "Helligkeit"}, "slotName": "Type", "rawValue": "helligkeit", "confidence": 1.0, "range": {"start": 0, "end": 10, "rawStart": 0, "rawEnd": 10}}, {"entity": "de.fhem.Device", "value": {"kind": "Unknown", "value": "deckenlampe"}, "slotName": "Device", "rawValue": "deckenlampe", "confidence": 1.0, "range": {"start": 11, "end": 22, "rawStart": 11, "rawEnd": 22}}, {"entity": "de.fhem.Room", "value": {"kind": "Unknown", "value": "bad"}, "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": "Helligkeit", "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}

Status:
Msg: hermes/intent/de.fhem_Status => {"input": "wie ist der status licht bad", "intent": {"intentName": "de.fhem:Status", "confidenceScore": 1.0}, "siteId": "wohnzimmer", "id": null, "slots": [{"entity": "Status", "value": {"kind": "Unknown", "value": "status"}, "slotName": "Status", "rawValue": "status", "confidence": 1.0, "range": {"start": 12, "end": 18, "rawStart": 12, "rawEnd": 18}}, {"entity": "de.fhem.Device", "value": {"kind": "Unknown", "value": "licht"}, "slotName": "Device", "rawValue": "licht", "confidence": 1.0, "range": {"start": 19, "end": 24, "rawStart": 19, "rawEnd": 24}}, {"entity": "de.fhem.Room", "value": {"kind": "Unknown", "value": "bad"}, "slotName": "Room", "rawValue": "bad", "confidence": 1.0, "range": {"start": 25, "end": 28, "rawStart": 25, "rawEnd": 28}}], "sessionId": "wohnzimmer-snowboy-6906f9f6-f7bf-416c-bc07-78da7bc2ef7d", "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": "der", "confidence": 1.0, "rangeStart": 8, "rangeEnd": 11, "time": null}, {"value": "status", "confidence": 1.0, "rangeStart": 12, "rangeEnd": 18, "time": null}, {"value": "licht", "confidence": 1.0, "rangeStart": 19, "rangeEnd": 24, "time": null}, {"value": "bad", "confidence": 1.0, "rangeStart": 25, "rangeEnd": 28, "time": null}]], "asrConfidence": null, "rawInput": "wie ist der status licht bad", "wakewordId": "snowboy", "lang": null}

MediaControls:
Msg: hermes/intent/de.fhem_MediaControls => {"input": "previous lied radio bad", "intent": {"intentName": "de.fhem:MediaControls", "confidenceScore": 1.0}, "siteId": "wohnzimmer", "id": null, "slots": [{"entity": "Command", "value": {"kind": "Unknown", "value": "previous"}, "slotName": "Command", "rawValue": "voriges", "confidence": 1.0, "range": {"start": 0, "end": 8, "rawStart": 0, "rawEnd": 7}}, {"entity": "de.fhem.Device", "value": {"kind": "Unknown", "value": "radio"}, "slotName": "Device", "rawValue": "radio", "confidence": 1.0, "range": {"start": 14, "end": 19, "rawStart": 13, "rawEnd": 18}}, {"entity": "de.fhem.Room", "value": {"kind": "Unknown", "value": "bad"}, "slotName": "Room", "rawValue": "bad", "confidence": 1.0, "range": {"start": 20, "end": 23, "rawStart": 19, "rawEnd": 22}}], "sessionId": "wohnzimmer-snowboy-7b7bdb95-93f5-4a3a-b386-d3cff3e37828", "customData": null, "asrTokens": [[{"value": "previous", "confidence": 1.0, "rangeStart": 0, "rangeEnd": 8, "time": null}, {"value": "lied", "confidence": 1.0, "rangeStart": 9, "rangeEnd": 13, "time": null}, {"value": "radio", "confidence": 1.0, "rangeStart": 14, "rangeEnd": 19, "time": null}, {"value": "bad", "confidence": 1.0, "rangeStart": 20, "rangeEnd": 23, "time": null}]], "asrConfidence": null, "rawInput": "voriges lied radio bad", "wakewordId": "snowboy", "lang": null}

GetTime:
Msg: hermes/intent/de.fhem_GetTime => {"input": "wie spät ist es", "intent": {"intentName": "de.fhem:GetTime", "confidenceScore": 1.0}, "siteId": "wohnzimmer", "id": null, "slots": [], "sessionId": "wohnzimmer-snowboy-e0312349-ae17-4e92-905a-cce515525efe", "customData": null, "asrTokens": [[{"value": "wie", "confidence": 1.0, "rangeStart": 0, "rangeEnd": 3, "time": null}, {"value": "spät", "confidence": 1.0, "rangeStart": 4, "rangeEnd": 8, "time": null}, {"value": "ist", "confidence": 1.0, "rangeStart": 9, "rangeEnd": 12, "time": null}, {"value": "es", "confidence": 1.0, "rangeStart": 13, "rangeEnd": 15, "time": null}]], "asrConfidence": null, "rawInput": "wie spät ist es", "wakewordId": "snowboy", "lang": null}

GetWeekday:
Msg: hermes/intent/de.fhem_GetWeekday => {"input": "welcher tag ist heute", "intent": {"intentName": "de.fhem:GetWeekday", "confidenceScore": 1.0}, "siteId": "wohnzimmer", "id": null, "slots": [], "sessionId": "wohnzimmer-snowboy-02724c86-d588-45e4-9a7e-5a17345b04f8", "customData": null, "asrTokens": [[{"value": "welcher", "confidence": 1.0, "rangeStart": 0, "rangeEnd": 7, "time": null}, {"value": "tag", "confidence": 1.0, "rangeStart": 8, "rangeEnd": 11, "time": null}, {"value": "ist", "confidence": 1.0, "rangeStart": 12, "rangeEnd": 15, "time": null}, {"value": "heute", "confidence": 1.0, "rangeStart": 16, "rangeEnd": 21, "time": null}]], "asrConfidence": null, "rawInput": "welcher tag ist heute", "wakewordId": "snowboy", "lang": null}

MediaChannels:
Msg: hermes/intent/de.fhem_MediaChannels => {"input": "Schalte um auf orf zwei", "intent": {"intentName": "de.fhem:MediaChannels", "confidenceScore": 1.0}, "siteId": "wohnzimmer", "id": null, "slots": [{"entity": "de.fhem.MediaChannels", "value": {"kind": "Unknown", "value": "orf zwei"}, "slotName": "Channel", "rawValue": "orf zwei", "confidence": 1.0, "range": {"start": 15, "end": 23, "rawStart": 15, "rawEnd": 23}}], "sessionId": "wohnzimmer-snowboy-6665801a-8946-4ff2-82a8-d3be87fcc60c", "customData": null, "asrTokens": [[{"value": "Schalte", "confidence": 1.0, "rangeStart": 0, "rangeEnd": 7, "time": null}, {"value": "um", "confidence": 1.0, "rangeStart": 8, "rangeEnd": 10, "time": null}, {"value": "auf", "confidence": 1.0, "rangeStart": 11, "rangeEnd": 14, "time": null}, {"value": "orf", "confidence": 1.0, "rangeStart": 15, "rangeEnd": 18, "time": null}, {"value": "zwei", "confidence": 1.0, "rangeStart": 19, "rangeEnd": 23, "time": null}]], "asrConfidence": null, "rawInput": "schalte um auf orf zwei", "wakewordId": "snowboy", "lang": null}

SetColor:
Msg: hermes/intent/de.fhem_SetColor => {"input": "schalte deckenlampe blau", "intent": {"intentName": "de.fhem:SetColor", "confidenceScore": 1.0}, "siteId": "wohnzimmer", "id": null, "slots": [{"entity": "de.fhem.Device", "value": {"kind": "Unknown", "value": "deckenlampe"}, "slotName": "Device", "rawValue": "deckenlampe", "confidence": 1.0, "range": {"start": 8, "end": 19, "rawStart": 8, "rawEnd": 19}}, {"entity": "de.fhem.Color", "value": {"kind": "Unknown", "value": "blau"}, "slotName": "Color", "rawValue": "blau", "confidence": 1.0, "range": {"start": 20, "end": 24, "rawStart": 20, "rawEnd": 24}}], "sessionId": "wohnzimmer-snowboy-cad9a0ea-d333-4fde-81a9-924fb576cbc0", "customData": null, "asrTokens": [[{"value": "schalte", "confidence": 1.0, "rangeStart": 0, "rangeEnd": 7, "time": null}, {"value": "deckenlampe", "confidence": 1.0, "rangeStart": 8, "rangeEnd": 19, "time": null}, {"value": "blau", "confidence": 1.0, "rangeStart": 20, "rangeEnd": 24, "time": null}]], "asrConfidence": null, "rawInput": "schalte deckenlampe blau", "wakewordId": "snowboy", "lang": null}

SetTimer:
Msg: hermes/intent/de.fhem_SetTimer => {"input": "taimer im wohnzimmer auf 10 sekunden", "intent": {"intentName": "de.fhem:SetTimer", "confidenceScore": 1.0}, "siteId": "wohnzimmer", "id": null, "slots": [{"entity": "de.fhem.Room", "value": {"kind": "Unknown", "value": "wohnzimmer"}, "slotName": "Room", "rawValue": "wohnzimmer", "confidence": 1.0, "range": {"start": 10, "end": 20, "rawStart": 10, "rawEnd": 20}}, {"entity": "rhasspy/number", "value": {"kind": "Number", "value": 10}, "slotName": "Value", "rawValue": "zehn", "confidence": 1.0, "range": {"start": 25, "end": 27, "rawStart": 25, "rawEnd": 29}}, {"entity": "Unit", "value": {"kind": "Unknown", "value": "sekunden"}, "slotName": "Unit", "rawValue": "sekunden", "confidence": 1.0, "range": {"start": 28, "end": 36, "rawStart": 30, "rawEnd": 38}}], "sessionId": "wohnzimmer-snowboy-63e0d711-7842-4e99-9a65-9a764c9952b3", "customData": null, "asrTokens": [[{"value": "taimer", "confidence": 1.0, "rangeStart": 0, "rangeEnd": 6, "time": null}, {"value": "im", "confidence": 1.0, "rangeStart": 7, "rangeEnd": 9, "time": null}, {"value": "wohnzimmer", "confidence": 1.0, "rangeStart": 10, "rangeEnd": 20, "time": null}, {"value": "auf", "confidence": 1.0, "rangeStart": 21, "rangeEnd": 24, "time": null}, {"value": "10", "confidence": 1.0, "rangeStart": 25, "rangeEnd": 27, "time": null}, {"value": "sekunden", "confidence": 1.0, "rangeStart": 28, "rangeEnd": 36, "time": null}]], "asrConfidence": null, "rawInput": "taimer im wohnzimmer auf zehn sekunden", "wakewordId": "snowboy", "lang": null}


So, habe mal wieder etwas nachgedacht und getestet, und will euch weder meine Gedanken noch den Code vorenthalten...

Was ich schon immer "seltsam" fand, war das mit dem "Zwangsraum". Daher gibt es jetzt als Vorschlag einen Parameter für die DEF mit dem sinnigen Namen "devspec". Damit kann man jetzt (hoffentlich) z.B. auch folgendes machen (auch für das folgende: alle Parameter sind optional!):
defmod RHASSPY RHASSPY devspec=room=Rhasspy,room=MQTT2_DEVICE,lampe3,alexaName=.+

Weiter habe ich den Verdacht, dass man ggf. auch weitere Topics bzw. Unterscheidungsmerkmale braucht, wenn man z.B. unterschiedliche FHEM-Instanzen und/oder mehrere User hat, die unterschiedliches dürfen bzw. per RHASSPY ansteuern können sollen. Daher gibt es jetzt vorsorglich mal den Vorschlag, eine "fhemId" vergeben zu können...?
defmod RHASSPY RHASSPY fhemId=fhem2

Generell scheint es so zu sein, dass wir auf der "de->en"-Mapping-Seite ziemlich beschäftigt damit sind, zwischenzeitlich(!) unglücklich gewordene Entscheidungen aus der Vergangenheit wieder gradezubiegen. Paradebeispiel:
starte{Command:play} die wiedergabe $de.fhem.Device{Device}Da frage ich mich, warum dann nicht gleich das passende Mapping an dieser Stelle mitgegeben wird:starte{Command:cmdPlay} die wiedergabe $de.fhem.Device{Device}Das ist auch für einen Franzosen vermutlich recht einfach anzupassen, oder...?
Na jedenfalls sollte der Code mit obiger Schreibweise klarkommen, und daneben noch die "alten" mappings (einschl. "zurück") verstehen, die aber bitte möglichst a) von den Usern umgestellt und b) von der Doku nicht mehr beworben werden sollten.
Da das dann a) statisch ist und b) direkt im Code verwendet werden kann, ist es aus der cfg ganz raus ;) .

Merksatz an der Stelle: "Weniger ist mehr".

Da ich vermute, dass das mit "Helligkeit" und evtl. den meisten anderen "deutschen" Keywords ähnlich ist, würde ich anregen, das mal in diese Richtung zu überdenken.

---

Was CustomIntents angeht, habe ich zumindest das Respeak mit NAME repariert, ob das ganze auch funktioniert, wenn andere Elemente und insbesondere DATA angefordert werden, habe ich noch nicht ausgetestet...

---

Was die ToDo's angeht, ist das eine oder andere erledigt, insbesondere die set-Anweisungen sollten jetzt alle triggernd durchlaufen.

Was das "get" angeht, bin ich grade noch etwas ratlos, wie ich das angehen kann bzw. wie eigentlich der Aktionspunkt aussieht.

---

Vielleicht noch ein paar Hintergedanken zum Thema rhasspyRoom/devspec und mapping:
Wenn "brightness" nicht mehr Helligkeit heißt, kann man auch "raten", dass ein setter/Reading "brightness" ggf. der Wert ist, den man wissen bzw. steuern will, eventuell wäre sogar "pct" in der FHEM-Welt die erste Wahl, die man austestet.
Und wenn es keinen rhasspyName gibt, aber einen alexaName und die devspec paßt, warum sollte man dann nicht die homebridgeMappings ausschlachten und das Device durch RHASSPY ansteuerbar machen?
Das setzt aber ggf. etwas mehr Logik bei der Auswertung der Parameter voraus, von daher wäre an der Stelle ggf. dann wieder der Gedanke: Pack' alles relevante in einen Hash und lies es von da...
Das ist auch der gedankliche Hintergrund, warum die Aktualisierung der language nicht als eigener setter hart vercodet ist, sondern "reinit" künftig auch weitere Parameter zulassen könnte ("devices" oder "all", um mal was völlig willkürliches in den Raum zu werfen...)

Jetzt wünsche ich erst mal viel Spaß beim Testen und freue mich über Rückmeldungen zu meinen Gedanken...

Zitat von: Beta-User am 08 März 2021, 13:26:51
Was ich schon immer "seltsam" fand, war das mit dem "Zwangsraum". Daher gibt es jetzt als Vorschlag einen Parameter für die DEF mit dem sinnigen Namen "devspec". Damit kann man jetzt (hoffentlich) z.B. auch folgendes machen (auch für das folgende: alle Parameter sind optional!):

Code Auswählen Erweitern

defmod RHASSPY RHASSPY devspec=room=Rhasspy,room=MQTT2_DEVICE,lampe3,alexaName=.+

Der Raum in der DEF dient nur als "Ausweichraum", sollte im Befehl kein Raum gesprochen werden (aber mehrere Devices mit dem selben rhasspyName in unterschiedlichen rhasspyRooms vorkommen).
Habe ich also ein Device mit rhasspyName "licht" im rhasspyRoom "wohnzimmer" und ein Device "licht" im rhasspyRoom "schlafzimmer" und spreche das Kommand "licht ein" im rhasspyRoom "küche", wird das "licht" in dem Raum geschalten, der im DEF steht. Theoretisch. Ausprobiert hab ich das nie.

ZitatWeiter habe ich den Verdacht, dass man ggf. auch weitere Topics bzw. Unterscheidungsmerkmale braucht, wenn man z.B. unterschiedliche FHEM-Instanzen und/oder mehrere User hat, die unterschiedliches dürfen bzw. per RHASSPY ansteuern können sollen. Daher gibt es jetzt vorsorglich mal den Vorschlag, eine "fhemId" vergeben zu können...?

Code Auswählen Erweitern

defmod RHASSPY RHASSPY fhemId=fhem2

Das entzieht sich vollkommen meiner Expertise. FHEM ist bei mir nur Backend. Die User bedienen Schalter oder TabletUI. Ich sehe für sowas also - für mich - keine Verwendung. Und würde das Thema auch nicht angehen, bevor nicht der Wunsch danach kommt. Das wird sonst alles zu kompliziert.

ZitatGenerell scheint es so zu sein, dass wir auf der "de->en"-Mapping-Seite ziemlich beschäftigt damit sind, zwischenzeitlich(!) unglücklich gewordene Entscheidungen aus der Vergangenheit wieder gradezubiegen.

Es war einfach nie ein "fertiges" Modul. Für die wenigen deutschsprachigen User hat's gereicht, was Thyraz gemacht hat.

Zitat
Paradebeispiel:

Code Auswählen Erweitern

starte{Command:play} die wiedergabe $de.fhem.Device{Device}Da frage ich mich, warum dann nicht gleich das passende Mapping an dieser Stelle mitgegeben wird:

Code Auswählen Erweitern

starte{Command:cmdPlay} die wiedergabe $de.fhem.Device{Device}Das ist auch für einen Franzosen vermutlich recht einfach anzupassen, oder...?

Hab ich mir auch schon überlegt. Spricht nichts dagegen.

ZitatWenn "brightness" nicht mehr Helligkeit heißt, kann man auch "raten", dass ein setter/Reading "brightness" ggf. der Wert ist, den man wissen bzw. steuern will, eventuell wäre sogar "pct" in der FHEM-Welt die erste Wahl, die man austestet.
Und wenn es keinen rhasspyName gibt, aber einen alexaName und die devspec paßt, warum sollte man dann nicht die homebridgeMappings ausschlachten und das Device durch RHASSPY ansteuerbar machen?

Könnte man :D
Aber wieder Aufwand. Ich hätte lieber gerne vorerst eine Version, in der mal alles funktioniert, was es bisher an Features gab. Danach bin ich für alles offen.

ZitatJetzt wünsche ich erst mal viel Spaß beim Testen und freue mich über Rückmeldungen zu meinen Gedanken...

Ich mache mich frisch und fröhlich ans Werk...

Danke dir!

Zitat von: drhirn am 08 März 2021, 13:49:22
Ich mache mich frisch und fröhlich ans Werk...

Danke dir!

Dann erst mal viel Spaß!

Zitat von: drhirn am 08 März 2021, 13:49:22
Könnte man :D
Aber wieder Aufwand. Ich hätte lieber gerne vorerst eine Version, in der mal alles funktioniert, was es bisher an Features gab. Danach bin ich für alles offen.

Da liegt ganz klar die Prio!

Die "features" bzw. sonstigen Vorbereitungen sollten nicht "hindern" oder besonders gefählich sein, du wirst es am diff sehen, dass devspec und fhemId relativ moderate Eingriffe in den Code sind...

ZitatDer Raum in der DEF dient nur als "Ausweichraum", sollte im Befehl kein Raum gesprochen werden (aber mehrere Devices mit dem selben rhasspyName in unterschiedlichen rhasspyRooms vorkommen).

Da sprechen wir von unterschiedlichen Dingen, sorry, wenn ich da in die falsche Kiste gegriffen habe: der default-room hat mich bisher nicht wirklich beschäftigt, aber "devspec" wird bei der Ermittlung der überhaupt zu beobachtenden Devices eine wesentliche Rolle (bisher starr: "room=Rhasspy"). Dieser Parameter sollte also die Ersteinrichtung deutlich vereinfachen (ich arbeite da an der Stelle potentiell auch für mich selbst...).

ZitatDas entzieht sich vollkommen meiner Expertise. FHEM ist bei mir nur Backend. Die User bedienen Schalter oder TabletUI. Ich sehe für sowas also - für mich - keine Verwendung. Und würde das Thema auch nicht angehen, bevor nicht der Wunsch danach kommt. Das wird sonst alles zu kompliziert.

Na ja, ich bin auch "Einheitsuser", alles läuft in einem System, bisher stressfrei. Es gibt aber einige User, die einige FHEM parallel betreiben. Da kann es durchaus vorkommen, dass die unterschiedliche Befehle an unterschiedliche FHEM schicken wollen. Noch viel mehr denke ich allerdings über die Frage nach, wie sich das verhält, wenn unterschiedliche User ins Spiel kommen. Kann aber durchaus sein, dass mir da irgendein Bausteinchen auf der Rhasspy-Seite fehlt ::) . Aber wenn ich mit FHEM sprechen kann, wollen das ziemlich sicher noch ein paar mehr, und das muss dann so klappen, dass mir keiner die Musik leiser dreht, der nicht auch im Raum ist...

Zitat
Es war einfach nie ein "fertiges" Modul. Für die wenigen deutschsprachigen User hat's gereicht, was Thyraz gemacht hat.

Schon klar, dass das erst mal für den "Eigenbedarf" konzipiert war. Ich komme jetzt eben da irgendwie "quer" rein und versuche, das ganze irgendwie abstrakt zu verstehen und generisch auszulegen, damit "jeder" es relativ leicht auf seine Bedürfnisse anpassen kann - auch, was z.B. die Rückmeldesätze an sich angeht. Bisher hat das nach meinem Eindruck relativ gut geklappt, ohne dass wir (dauerhaft) massive Probleme bekommen hätten. Btw.: die Grundstruktur von Thyraz ist und war m.E. solide ausgearbeitet, alles baut solide aufeinander auf und man kann "die Planken" recht gut nach und nach wechseln.

Zitat
Hab ich mir auch schon überlegt. Spricht nichts dagegen.

Dann sollten wir das in diese Richtung weiterverfolgen, auch was "Helligkeit" und Co. angeht.
Das könnte man dann ähnlich lösen wie bei "zurück": die de-en-Übersetzung als Zwischenschritt einbauen, wo es auf direktem Weg nicht klappt, diesen Hash dann aber (mittelfristig) nicht mehr in der cfg zeigen.
Apropos cfg: Da war die Idee, einen "default"-Hash und einen "user"-Hash zu bauen. In "user" könnte dann stehen, was der einzelne anders haben will wie in default; dann kann man nämlich den default ggf. leichter ändern, wenn sich dazu eine Notwendigkeit ergibt...

Aber Rom und so: erst machen wir das ganze wieder 100% funktional :) .

Ich habe jetzt mal die DEF angepasst:

defmod Rhasspy RHASSPY devspec=room=Musik Wohnzimmer de

Und dann ein updateSlots gemacht. Dabei hat er mir nur noch die Devices hoch geladen, die im Raum "Musik" sind. Das scheint also zu funktionieren.

Zitat von: drhirn am 08 März 2021, 14:42:21
Ich habe jetzt mal die DEF angepasst:

Code Auswählen Erweitern

defmod Rhasspy RHASSPY devspec=room=Musik Wohnzimmer de

Und dann ein updateSlots gemacht. Dabei hat er mir nur noch die Devices hoch geladen, die im Raum "Musik" sind. Das scheint also zu funktionieren.

;D

Den Teil hatte ich sogar getestet...

Btw.: Bitte möglichst aus "pädagogischen Gründen" die DEF nur noch in der "parseParams"-Hash-kompatiblen Schreibweise posten, also
defmod Rhasspy RHASSPY devspec=room=Musik defaultRoom=Wohnzimmer language=de
Ist vermutlich für die meisten Einsteiger leichter zu verarbeiten, wenn man es immer macht, selbst wenn die Auswertung kompatibel ist, solange man bei den "alten" Argumenten die Reihenfolge einhält... Für die neuen Argumente wird aber gar nicht mehr in das unnamed-Array geschaut...

Ich nehme an, du pflichtest mir bei, dass das eine kleine aber feine Modifikation ist, oder...?

betr. bugfixing auch gleich noch eine Sache:
Bisher gab es immer eine "seltsame" Meldung, wenn man das configFile-Attribut gelöscht hat. Die habe ich eben noch ausgemerzt.

Ich hätte drei Fragen zum Timer (der ist aktualisiert seit heute; im GitHub verfügbar).

1. Wie bekomme ich das in die Sprach-Datei und wie kann ich's dann auswerten
my @unitHours = ('stunde','stunden','hour','hours','heure','heures');

Ich muss ja die siteIds abfragen, damit ich nachsehen kann, ob es im gewünschten Raum einen Satelliten gibt. Ich dachte mir, ich schreib das nach $hash->{helper}{siteIds}. Deshalb
2. Geht das schöner?
    my @siteIds = split /,/,$hash->{helper}{siteIds};
    my $timerRoom = $siteId;
    if ( grep {/^$room$/i} @siteIds ) {$timerRoom = $room};
3. Die siteIds bräuchte ich schon beim Start von FHEM bzw. des Moduls. Wo baue ich den Aufruf von fetchSiteIds am schlausten ein und wie?

Ad 1: Da meine ich, das eigentlich schon mal eingebaut gehabt zu haben; es gibt in der cfg. jedenfalls einen Hash mit "units", in der dann nur das drin steht, was für die jeweilige Sprache relevant ist, allerdings als regex, der Code drumrum war also anders, ich find's aber grade leider nicht mehr. Ist dann aber ähnlich wie bei "upward"...

Ad 3: Dürfte in firstInit() gut aufgehoben sein (alternativ RHASSPY_Define()). Unterschied zwischen beidem: zum firstInit()-Zeitpunkt sind alle Geräte und Attribute bereits bekannt; wenn also die Rückmeldung via MQTT kommt, sollte man bis dahin warten, damit auch der CLIENT sicher läuft.

Ad 2: Da fehlt mir noch das Bruchstückchen, was denn als Rückmeldung beim Modul ankommt, damit man es in einen Hash schieben kann. Grundsätzlich finde ich diese grep-Konstruktion notorisch der Umgehung des Hash-lookup-features von Perl verdächtigt :P .
Eigentlich _glabe_ ich, dass es mal wieder ein Hash sein sollte, der in $hash->{helper}{siteIds} zu finden sein sollte, nämlich mit den
siteId => room-Paaren. (oder ist das wirklich immer identisch?)Dann wieder die übliche Logik my $timerRoom = $hash->{helper}{siteIds}->{$siteId} // ... (=> default room);
Aber ohne Basisdaten ist das schwierig...

Nachtrag:
a) das split dient hier ja nur dazu, ein Array zu bekommen, dessen einziger Zweck es dann wieder ist, dass man darüber ein grep macht.
Das schreit m.E. danach, das direkt mit einer regex zu machen...

b) die Doppelung zwischen Internal und Reading erschließt sich mir nicht, zumal das Reading ja auch einen Neustart überlebt.

Anbei der Versuch, das anders zu lösen, gleich auch mit der regex-Lösung für die Timer-Geschichte.

Die Doppelung ist einfach nur zum Spaß da. Als Notnagel, falls das mit dem Internal nicht funktioniert ;).

Ich finde Internal aber schöner. Sonst werden's langsam ganz schön viele Readings. Und wenn man's schafft, dass das Internal eh gleich beim Start geschrieben wird, ist es ja egal, wenn's keinen Neustart überlebt.

Zitat von: drhirn am 08 März 2021, 17:21:39
Die Doppelung ist einfach nur zum Spaß da. Als Notnagel, falls das mit dem Internal nicht funktioniert ;) .

Ach so, das war vorher gar nicht da...? ???

ZitatIch finde Internal aber schöner. Sonst werden's langsam ganz schön viele Readings. Und wenn man's schafft, dass das Internal eh gleich beim Start geschrieben wird, ist es ja egal, wenn's keinen Neustart überlebt.

Na ja, wenn die Readings nur geschrieben werden, wenn was (halbwegs) wichtiges passiert, finde ich das mit vielen Readings nicht schlimm, v.a., wenn man darauf achtet, nicht zu viele Trigger-loops auszulösen. Von daher kann man den update auch bedingt durch das Vorhandensein des Readings auslösen, falls sich sowieso kaum was ändert?

Grundsätzlich finde ich diese Sache aber als Reading besser aufgehoben: Das ist nichts, was vom Modul selbst direkt verwaltet wird, sondern es kommt "von außen" und kann auch von Rhasspy aus geändert werden (k.A., ob sich Clients da "abmelden" können und man das dann "gepusht" bekommt; wenn das so wäre, ist es m.E. deutlich eher Reading als Internal...

Das Reading schon, das Internal hab ich am Wochenende eingebaut.

Das mit "von außen" ist ein Argument. Aber es ist keine Information, die man wissen muss. Und es wird nichts gepushed. Änderungen gibt's nur, wenn ein Satellit weg- oder dazu kommt. Und das passiert alles manuell. Und wahrscheinlich so gut wie nie.

Zwei von den gelisteten Items sollten mit der Fassung anbei gelöst sein.

Wie das mit SetMute ablaufen soll, ist mir leider unklar, aus dem Code alleine bin ich nicht schlau geworden, und nur das Reading listening_.* zu setzen, wäre zwar möglich gewesen, aber vermutlich zu oberflächlich, da soll ja wohl irgendwas nach irgendwohin rausgehen, oder?

Wirfst du noch den "Media"-Hash aus deiner cfg auf github?

---

Und habe ich das richtig verstanden, dass wir uns mit sowas "beliefern" lassen könnten:
mache $de.fhem.Device{Device} heller{brightness:up}
mache $de.fhem.Device{Device} leiser{volume:down}bzw. (der Spur nach):
mache $de.fhem.Device{Device} leiser{Command:volDown}
(Wenn ja: wie käme das dann via MQTT an?)

SetMute stellt $mute auf true od. false. Wenn true, hört das Modul zwar noch zu (um mute wieder false setzen zu können), führt aber keine sonstigen Befehle aus. Das führt dazu, dass die Dialogue-Session (hermes/dialogueManager/endSession) nicht mehr beendet wird. Was wir sonst mit RHASSPY_respond machen, wenn ein Befehl ausgeführt wird.

"Media"-Hash ist entfernt. Danke für den Hinweis.

Und ja, heller/dunkler, leiser/lauter, wärmer/kälter geht auch.
Ein Mapping sieht z.B. so aus:

SetNumeric:currentVal=volume,cmd=volume,minVal=0,maxVal=99,step=10,type=Lautstärke


Und von Rhasspy kommt folgendes:

Msg: 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": "lauter"}, "slotName": "Change", "rawValue": "lauter", "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": "lauter", "confidence": 1.0, "rangeStart": 11, "rangeEnd": 17, "time": null}]], "asrConfidence": null, "rawInput": "mach das radio lauter", "wakewordId": null, "lang": null}

Ich hab das in der device_playload.txt ergänzt.

Hm, ok, ich meine, das Problem mit den _anderen Messages_, die im "muted"-Zustand eintrudeln können nun verstanden zu haben...

Könnte in dieser Fassung gelöst sein...

---

Bei dem lauter (etc.)-Thema sprechen wir noch von verschiedenen Dingen -
du vom Ist-Zustand, ich vom Soll-Zustand (definiert durch mein Bauchgefühl...):

Worauf ich raus will ist folgendes: Wir haben zum einen in Change@rhasspy-de.cfg einige Übersetzungen und regexe drin, die man nur deswegen braucht, weil von Rhasspy eben deutsche Schlüsselbegriffe geliefert werden. Die werden dann mehr oder weniger umständlich gemappt...

In Schritt 1 wäre zu fragen, ob man das mapping nicht auch so machen kann:
SetNumeric:currentVal=volume,cmd=volume,minVal=0,maxVal=99,step=10,type=volumeSound
Schritt 2 wäre etwas radikaler:
SetNumeric:currentVal=volume,cmd=volume,minVal=0,maxVal=99,step=10Da wir einen "passenden" Namen "volume" haben, könnten wir ggf. auch einfach "tippen", dass sich der Modulautor des Zielgeräts an https://wiki.fhem.de/wiki/DevelopmentGuidelinesAV (https://wiki.fhem.de/wiki/DevelopmentGuidelinesAV) gehalten hatte und sich (per default) auch ableiten läßt, dass currentVal=volume auch zugleich das cmd-Reading ist...Da müßte man sich dann nur noch klar werden, ob das durch volumeSound erstetzte "Matchword" in RHASSPY nicht gleich nur "volume" heißen sollte bzw. der "value" statt "lauter" eben "volUp"...
Letzteres in:
Msg: 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": "volUp"}, "slotName": "Change", "rawValue": "lauter", "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": "lauter", "confidence": 1.0, "rangeStart": 11, "rangeEnd": 17, "time": null}]], "asrConfidence": null, "rawInput": "mach das radio lauter", "wakewordId": null, "lang": null}(oder eben gleich nur "up" bzw. "down", vermutlich (!) ist es egal, grade machen wir ja auch nur pauschal "upward" in der cfg...)

Schritt 3 könnte dann ggf. auf den ganzen Schnickschnack verzichten, und einfach (per änderbarem default) unterstellen, dass ein genericDeviceType speaker eben einen passenden setter bzw. ein passendes Reading hat... (entsprechend für blind oder light)

Der Weg wäre dann:
- Usern mitteilen, dass sie zukünftig die englischen Schlüsselbegriffe liefern sollen.
- Übersetzungen wieder "ins Modul" (aus der cfg) nehmen, im Code dann immer zuerst prüfen, ob wir schon ein passendes Schlüsselwort geliefert bekommen => keine Umwege, Fremdsprachler können direkt die englischen Begriffe liefern...
(Wenn nein: Komfort für die heutigen Nutzer: mit der internen "Tabelle" übersetzen...)

Hoffe, es ist jetzt klarer, dass ich _glaube_, dass die Übersetzung schon auf der Rhasspy-Seite erfolgen sollte. Das ist zwar eventuell im ersten Moment etwas schwieriger/umständlicher zu konfigurieren, aber - soweit ich das beurteilen kann - die Mehraufwände scheinen relativ moderat zu sein, und man muss sowieso vieles manuell konfigurieren, damit die Erkennung passt...?

Was wir ggf. noch bräuchten, wäre eine Art qualifizierter Rückmeldung, damit man Typos etc. leichter findet?

Was von Rhasspy kommt, können wir selber festlegen. Da gibt's keine Vorgabe. Die User müssen sich dann einfach nur dran halten.

Ich möchte aber schon ein bisschen Flexibilität bei behalten. Zum einen ist das mit "an Guidelines halten" so eine Sache. Zum anderen kann man das Zeug so absichtlich "missbrauchen". Ich steuer z.B. meinen Saugroboter über MediaControls ;).

Aber das mit dem genericDeviceType ist eigentlich eine gute Idee!

Zeile 1354 bei dir:

Zitat#Beta-User: könnte effizienter notiert werden, wenn sicher ist, dass es nur diese beiden $type geben kann...

Es kann nur diese beiden Typen geben.

Zitat von: drhirn am 09 März 2021, 15:51:54
Zeile 1354 bei dir:
Es kann nur diese beiden Typen geben.

Wie wäre es dann mit
    $type eq 'voice' ?
        readingsBulkUpdate($hash, 'voiceResponse', $response)
      : readingsBulkUpdate($hash, 'textResponse', $response);


Zitat von: drhirn am 09 März 2021, 15:40:26
Was von Rhasspy kommt, können wir selber festlegen. Da gibt's keine Vorgabe. Die User müssen sich dann einfach nur dran halten.

Dann werden wir das wohl versuchen, in diese Richtung umzubauen, oder?
Als ersten Schritt mal eine geringfügig abgespeckte cfg, die aus "soundVolume" nur "volume" macht...

Zitat
Ich möchte aber schon ein bisschen Flexibilität bei behalten. Zum einen ist das mit "an Guidelines halten" so eine Sache. Zum anderen kann man das Zeug so absichtlich "missbrauchen". Ich steuer z.B. meinen Saugroboter über MediaControls ;) .

Grundsätzlich sollte die Flexibilität nicht unter den Vorschlägen leiden, der Saugrobi sollte/könnte dann eben auf "cmdPlay" reagieren. Der Plan wäre, zumindest die Mapping-Möglichkeiten so zu erhalten, wie sie heute sind, nur ggf. diese leiser/lauter-zurück-Geschichte ggf. dann irgendwann (!) auszubauen und statt Helligkeit dann eben brightness zu verwenden (weil die zusätzliche Prüfung eben etwas Performance kostet)...

Zitat
Aber das mit dem genericDeviceType ist eigentlich eine gute Idee!

Das hört man doch gerne 8) .

Dann wird das Ziel hinter "devspec" jetzt vermutlich auch klarer...

Zitat von: Beta-User am 09 März 2021, 16:00:52
Grundsätzlich sollte die Flexibilität nicht unter den Vorschlägen leiden, der Saugrobi sollte/könnte dann eben auf "cmdPlay" reagieren. Der Plan wäre, zumindest die Mapping-Möglichkeiten so zu erhalten, wie sie heute sind, nur ggf. diese leiser/lauter-zurück-Geschichte ggf. dann irgendwann (!) auszubauen und statt Helligkeit dann eben brightness zu verwenden (weil die zusätzliche Prüfung eben etwas Performance kostet)...

Wie gesagt, wir sind da vollkommen flexibel. Wir können auch - wie von dir vorgeschlagen - pct nehmen.

Wir müssen nur dran denken, dass zwischen "stell die lampe auf 50" und "stell die lampe auf 50 prozent" ein Unterschied ist ;)

Und - weil's mir gerade wieder einfällt - $device ist eigentlich nicht, was ich bei der Sprachausgabe hören will. Ich möchte das als Sprachausgabe bekommen, was ich zuvor gesprochen habe. Deswegen habe ich bei RHASSPY_handleIntentGetOnOff "$deviceName" eingeführt. Damit ich nicht den FHEM-Namen zurück bekomme, sondern den rhasspyName.

Bisher war's so, dass ich eigentlich alle SetNumeric-Geschichten in Rhasspy mit einem Satz abdecken konnte:

\[stell|stelle|mach|mache|schalt|schalte] $de.fhem.Device{Device} [$de.fhem.Device{Room}] [auf|um] [(0..100){Value}] [(prozent|grad|dezibel){Unit}] [(heller|dunkler|wärmer|kälter|lauter|leiser){Change}]

Mit unserem Plan, müsste man für jede Änderung einen eigenen Satz bauen:

\[mach] $de.fhem.Device{Device} lauter{Change:volumeUp}
\[mach] $de.fhem.Device{Device} leiser{Change:volumeDown}


Das nur zur Erklärung.

Musste in onmessage noch den "type" ergänzen. Sonst hat RHASSPY_respond nicht funktioniert.


    if ($mute) {
        $data->{requestType} = $message =~ m{${fhemId}.textCommand}x ? 'text' : 'voice';
        RHASSPY_respond($hash, $data->{requestType}, $data->{sessionId}, $data->{siteId}, q{ });
        return \@updatedList;
    }


Zitat von: drhirn am 09 März 2021, 16:05:09
Wie gesagt, wir sind da vollkommen flexibel. Wir können auch - wie von dir vorgeschlagen - pct nehmen.

Ich habe dazu auch noch keine abschließende Meinung; grundsätzlich ist "pct" halt in FHEM alles, was man zwsischen 0 und 100 (bzw. 99=>ZWave) regeln kann. Von daher würde sich das anbieten.
Tendenziell müssen wir das aber auch nicht "gleich" festlegen, erst wäre
- der Mechanismus umzustellen (die Übersetzung nach intern mit vorrangiger Prüfung auf was auch immer, das bräuchten wir vorerst ja nicht offenzulegen);
- die Verwaltung der mappings nach intern zu verlegen. Wenn wir nämlich mehrere Quellen haben, sollten wir irgendwie dem User zeigen, was ganz am Ende das mapping geworden ist?

Zitat
Wir müssen nur dran denken, dass zwischen "stell die lampe auf 50" und "stell die lampe auf 50 prozent" ein Unterschied ist ;)

Korrekt, wobei mein bisheriger Eindruck vom Code der war, dass "percent" eine separate Kategorie ist, die nicht deckungsgleich sein muss mit "Helligkeit" (dann: ggf. "pct")

Zitat von: drhirn am 09 März 2021, 16:13:16
Und - weil's mir gerade wieder einfällt - $device ist eigentlich nicht, was ich bei der Sprachausgabe hören will. Ich möchte das als Sprachausgabe bekommen, was ich zuvor gesprochen habe. Deswegen habe ich bei RHASSPY_handleIntentGetOnOff "$deviceName" eingeführt. Damit ich nicht den FHEM-Namen zurück bekomme, sondern den rhasspyName.

Sory, das war mir rausgegangen...

Wobei ich da ggf. was kürzeres vorschlagen würde ($devname, $r_name oder $alias?).

Zitat von: drhirn am 09 März 2021, 16:26:13
Bisher war's so, dass ich eigentlich alle SetNumeric-Geschichten in Rhasspy mit einem Satz abdecken konnte:

Code Auswählen Erweitern

\[stell|stelle|mach|mache|schalt|schalte] $de.fhem.Device{Device} [$de.fhem.Device{Room}] [auf|um] [(0..100){Value}] [(prozent|grad|dezibel){Unit}] [(heller|dunkler|wärmer|kälter|lauter|leiser){Change}]

Ins Unreine - geht so etwas:
\[stell|stelle|mach|mache|schalt|schalte] $de.fhem.Device{Device} [$de.fhem.Device{Room}] [auf|um] [(0..100){Value}] [dezibel{Unit:decibel}][grad{Unit:degree}][prozent{Unit:percent}] [(heller|wärmer|lauter){Change:up}|(dunkler|kälter|leiser){Change:down}]
Aber ja, ich sehe das Problem, das ist wirklich relativ unübersichtlich und vermutlich dann doch über ein cfg-Mapping einfacher zu erledigen...
Wobei da jetzt wieder ein paar neue Dinge drin sind, mal sehen, was mir ggf. dazu im Lauf der Zeit noch in den Sinn kommt.

onmessage habe ich rüberkopiert, Danke für's reparieren...

ZitatWobei ich da ggf. was kürzeres vorschlagen würde ($devname, $r_name oder $alias?).

Ich bin da situationselastisch wie man bei uns in Österreich sagt ;). Wenn ich's mir aussuchen kann, hätte ich gerne etwas Sprechendes ohne Unterstriche.

Zitat
Ins Unreine - geht so etwas:

Code Auswählen Erweitern

\[stell|stelle|mach|mache|schalt|schalte] $de.fhem.Device{Device} [$de.fhem.Device{Room}] [auf|um] [(0..100){Value}] [dezibel{Unit:decibel}][grad{Unit:degree}][prozent{Unit:percent}] [(heller|wärmer|lauter){Change:up}|(dunkler|kälter|leiser){Change:down}]

Ähm, ja. Könnte gehen. Hab's jetzt aber nicht ausprobiert. Solange man nicht "Stelle Device auf 100 Dezibel Grad Prozent" sagt ;)

Stelle fest, du kennst dich mit Rhasspy schon gut aus :D

Zitat von: drhirn am 09 März 2021, 17:27:14
Ich bin da situationselastisch wie man bei uns in Österreich sagt ;) . Wenn ich's mir aussuchen kann, hätte ich gerne etwas Sprechendes ohne Unterstriche.

Unterstriche finde ich auch nicht so prickelnd, ich bevorzuge halt prinzipiell eher "kurz und knackig", von daher ist die spontane Tendenz eher zu $alias, aber letztlich ist mir das "juck wie jack". Falls das mit der "erweiterten maping-Analyse" kommt, wird man eben voraussichtlich diesen "Label" (ohne $) auch im List vom RHASSPY-Device über den möglichen Werten finden; spätestens dann ist auch für die User klarer, was gemeint ist (die werden eh' zu 95+% copy/paste machen...)

Zitat
Ähm, ja. Könnte gehen. Hab's jetzt aber nicht ausprobiert. Solange man nicht "Stelle Device auf 100 Dezibel Grad Prozent" sagt ;)

Klar, Unsinn kann man damit treiben, wobei die Frage im Raum steht, ob dann mehrfach die "Unit" im JSON auftaucht. ..?

ZitatStelle fest, du kennst dich mit Rhasspy schon gut aus :D

Ein gewisses Gesamtbild schwebt schon vor meinen Augen, auch wenn ich bisher noch keinen Docker am Laufen habe... Es wird also so langsam.
Jedenfalls ist mein Eindruck sehr positiv, das sieht alles einigermaßen staight forward aus :) .

Prinzipiell wäre eben die Frage, wie oft man sowas editieren muss und inwieweit es copy/paste von vorhandenen Vorlagen ist.
Wenn es zu 99,5%+ funktioniert und man dann nur einmalig einen etwas komplexeren Ausdruck editieren/anpassen muss, neige ich (leicht) zu der Auffassung, dass es aus User-Sicht besser ist, sowas nur an einer Stelle anfassen zu müssen

---

Was ganz anderes: Gibt es eigentlich die Option, eine "SPELL"-Anweisung zurückzugeben.
Anwendungfall: wir können ein Mapping nicht auflösen und wollen dem User mitteilen, welches das übergebene "keyword" war.

Zitat von: Beta-User am 09 März 2021, 17:51:35Prinzipiell wäre eben die Frage, wie oft man sowas editieren muss und inwieweit es copy/paste von vorhandenen Vorlagen ist.

Die "Sätze" in Rhasspy? Muss man 1x erstellen. Sofern sie passen, braucht man das dann nie wieder.

ZitatWas ganz anderes: Gibt es eigentlich die Option, eine "SPELL"-Anweisung zurückzugeben.
Anwendungfall: wir können ein Mapping nicht auflösen und wollen dem User mitteilen, welches das übergebene "keyword" war.

Verstehe ich nicht. Wir können in die reponse ja packen, was wir wollen.

Zitat von: JensS am 09 März 2021, 19:07:18
@Beta-User
Meine Tests musste ich wieder einstellen, da meine CustomIntents mit Übergabe von Werten (z.B. SetAllOff) nur Fehler gebracht haben.

Ich hoffe, die Ursache gefunden zu haben, aktualisierter Code anbei.

Zitat von: drhirn am 09 März 2021, 18:32:44
Die "Sätze" in Rhasspy? Muss man 1x erstellen. Sofern sie passen, braucht man das dann nie wieder.

Nachdem ich auch die "Sätze" für diese SetAllOn-Geschichte mal etwas näher angesehen habe, scheint es mir so zu sein, dass man auch das "Problem" aus

ZitatÄhm, ja. Könnte gehen. Hab's jetzt aber nicht ausprobiert. Solange man nicht "Stelle Device auf 100 Dezibel Grad Prozent" sagt

wohl durch passende Syntax gut lösen kann. Neige daher noch mehr dazu, das auf der "sentences.ini"-Ebene zu lösen und das Modul gleich passend beliefern zu lassen...

Zitat
Verstehe ich nicht. Wir können in die reponse ja packen, was wir wollen.

Klar. Meine eigentliche Frage war: wie bringen wir die Sprachausgabe dazu, etwas zu buchstabieren? Leerzeichen zwischen die einzelnen Buchstaben packen?

Ja. Habe ich nicht wirklich zum Ausdruck gebracht. Bin ebenfalls dafür, dass die sentences.ini schon alles richtig liefert.

ZitatKlar. Meine eigentliche Frage war: wie bringen wir die Sprachausgabe dazu, etwas zu buchstabieren? Leerzeichen zwischen die einzelnen Buchstaben packen?

Ja, das funktioniert.

Bei den Mappings gibt's ja die Möglichkeit, ein response= anzugeben. Das war eigentlich dazu gedacht, eine individuelle Sprach-Antwort festzulegen.

SetOnOff:cmdOn=on,cmdOff=off,response=Okidoki

Jetzt kann man da auch Aufrufe zu Sachen in der myUtils.pm unterbringen. Was cool ist.
Aber eine einfache Sprachausgabe geht nicht mehr ;).

Ich finde leider den Teil im Code nicht, wo das abgehandelt wird. Oder kapier's nicht. Kannst du mir da helfen?

Ähm, auf die Schnelle ist das schwierig, ich breche grade die ganzen Hashes auf, um diese interne Kompabilitätsebene einzuziehen.

Des Pudels Kern sollte eigentlich das hier sein:
https://github.com/drhirn/fhem-rhasspy/blob/0.4.2beta/10_RHASSPY.pm#L1714
Das ist im wesentlichen unverändert, von daher deutet es darauf hin, dass das mapping kaputt ist. Den Code, um das zu ermitteln, haben wir aber afaik nicht substantiell angefasst...

Ah, genau. Da war das. Danke! Ich schau mal, was ich raus finde.

Keine Ahnung, warum das überhaupt funktioniert hat...
Finde auch im Code von Thyraz keine Erklärung dafür. Ich glaube langsam, ich bilde mir das nur ein. Andererseits hab ich in meinem produktiven FHEM ein Mapping gefunden. Es muss also irgendwie funktioniert haben. Ich kann's nur leider nicht mehr überprüfen.

So, das war leicht.

Allerdings, wenn man einen Text in Anführungszeichen eingibt, haut's FHEM auf's Maul.

Can't use string ("set lampe2 off") as an ARRAY ref while "strict refs" in use at ./FHEM/10_RHASSPY.pm line 2290.

Das ist diese Zeile in RHASSPY_ReplaceReadingsVal
my $to_analyze = join q{ }, @{$arr};

Da habe ich keine Lösung gefunden.

Nach etwas Rumspielen mit der response: Das funktioniert schon, wenn man es richtig macht, ist aber nicht ganz ungefährlich, wie du ja auch bemerkt hast:
SetOnOff:cmdOn=on,cmdOff=off,response=state
SetOnOff:cmdOn=on,cmdOff=off,response={"wird erledigt"}


Wie man das mit dem bareword lösen kann (abgesehen von stricture vorübergehend auszuschalten), wird ggf. noch zu klären sein, dazu muss man erst mal checken, von wo aus dieser Code-Teil überhaupt angefahren wird...


Anbei jedenfalls der Umbau:
Es gibt jetzt ein paar mehr interne Hashes, die Logik ist dann (hoffentlich) immer die: Wenn der Wert direkt verwertbar ist (z.B. {Change:up}), dann nimm' den, wenn nicht, schau, ob der (althergebrachte) englische Wert/die regex passt, und wenn auch das nicht klappt, versuch's mit den deutschen Begriffen.

Soweit ich das bisher getestet habe, funktioniert es, und der jetzt noch in der cfg verbliebene Teil ist auch relativ überschaubar und in der Struktur vereinfacht.

Dann mal wieder viel Spaß beim Testen.

Ich hab das jetzt einfach so gelöst:


sub RHASSPY_getValue { #($$$;$$)
    my $hash      = shift // return;
    my $device    = shift // return;
    my $getString = shift // return;
    my $val       = shift;
    my $siteId    = shift;
   
    # Perl Command oder in Anführungszeichen? -> Umleiten zu RHASSPY_runCmd
    if ($getString =~ m{\A\s*\{.*\}\s*\z}x || $getString =~ m/^\s*".*"\s*$/) {
        return RHASSPY_runCmd($hash, $device, $getString, $val, $siteId);
    }

    # Soll Reading von einem anderen Device gelesen werden?
    if ($getString =~ m{:}x) {
        my @replace = split m{:}x, $getString;
        $device = $replace[0];
        $getString = $replace[1] // $getString;
        return ReadingsVal($device, $getString, 0);
    }
    # If it's only a string without quotes, return string for TTS
    else {
        return $getString;
    }
}


Klingt logisch...

Aber mach' die "else" weg. Wir sind doch schon am Ende des Codes und hören - wie es sich gehört - mit einer return-Anweisung auf ;) .

Nachtrag:
Wenn "$getstring" ein Reading-Name ist, macht es durchaus Sinn, den R-Val zurückzugeben. Also so?
sub RHASSPY_getValue { #($$$;$$)
    my $hash      = shift // return;
    my $device    = shift // return;
    my $getString = shift // return;
    my $val       = shift;
    my $siteId    = shift;
   
    # Perl Command oder in Anführungszeichen? -> Umleiten zu RHASSPY_runCmd
    if ($getString =~ m{\A\s*\{.*\}\s*\z}x || $getString =~ m/^\s*".*"\s*$/) {
        return RHASSPY_runCmd($hash, $device, $getString, $val, $siteId);
    }

    # Soll Reading von einem anderen Device gelesen werden?
    if ($getString =~ m{:}x) {
        my @replace = split m{:}x, $getString;
        $device = $replace[0];
        $getString = $replace[1] // $getString;
        return ReadingsVal($device, $getString, 0);
    }
    # If it's only a string without quotes, return string for TTS
    return ReadingsVal($device, $getString, $getString);
}

Sehr schlau! :)

Dein
SetOnOff:cmdOn=on,cmdOff=off,response=state
wird halt nicht mehr funktionieren. Also schon, aber es wird nicht das Reading gesprochen.

Was mich daran erinnert, dass

response=[lampe1:state]

leider auch nicht funktioniert. Weiß aber noch nicht, warum nicht.

Zitat von: drhirn am 10 März 2021, 15:01:22
Dein

Code Auswählen Erweitern

SetOnOff:cmdOn=on,cmdOff=off,response=state
wird halt nicht mehr funktionieren. Also schon, aber es wird nicht das Reading gesprochen.

Siehe meinen Nachtrag...

Zitat
Was mich daran erinnert, dass

Code Auswählen Erweitern


response=[lampe1:state]

leider auch nicht funktioniert. Weiß aber noch nicht, warum nicht.

Na ja, die eckigen Klammern sollte man dann nach "if ($getString =~ m{:}x) {" und vor dem split entfernen, falls die da sind. Diese "set magic"-Syntax ist aber bisher nicht als funktionierend dokumentiert...

Bei SetNumeric wird immer in Prozent gerechnet. Weil der Code davon ausgehen, dass das so sein soll, wenn im Mapping "percent" vorkommt.

my $forcePercent = (defined $mapping->{map} && lc($mapping->{map}) eq 'percent') ? 1 : 0;

Das stimmt nicht, es soll nur in Prozent gerechnet werden, wenn die Unit "percent" ist.

Mein Fehler. Das soll wirklich so sein.

Aber, wie sollen diese beiden Sätze jetzt "richtig" aussehen?


\[stell|stelle|mach|mache|schalt|schalte] $de.fhem.Device{Device} [$de.fhem.Device{Room}] [auf|um] [(0..100){Value}] [(prozent|grad|dezibel){Unit}] [(heller|dunkler|wärmer|kälter){Change}]
\[mach] $de.fhem.Device{Device} lauter{Change:upward}


Hm, (hinsichtlich der Klammersetzung) vermutlich etwa so:
\[stell|stelle|mach|mache|schalt|schalte] $de.fhem.Device{Device} [$de.fhem.Device{Room}] [auf|um] [(0..100){Value}] [(prozent{Unit:percent}|grad{Unit:degree}|dezibel{Unit:decibel})] [((heller|wärmer){Change:up}|(dunkler|kälter){Change:down})]
\[mach] $de.fhem.Device{Device} lauter{Change:up}

Also, ich weiß jetzt nicht, ob das an mir oder am Code liegt. Aber irgendwie wird immer das erste gefundene Mapping verwendet.

Payload:
Msg: hermes/intent/de.fhem_SetNumeric => {"input": "stell radio um 5 decibel up", "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": 6, "end": 11, "rawStart": 6, "rawEnd": 11}}, {"entity": "rhasspy/number", "value": {"kind": "Number", "value": 5}, "slotName": "Value", "rawValue": "fünf", "confidence": 1.0, "range": {"start": 15, "end": 16, "rawStart": 15, "rawEnd": 19}}, {"entity": "Unit", "value": {"kind": "Unknown", "value": "decibel"}, "slotName": "Unit", "rawValue": "dezibel", "confidence": 1.0, "range": {"start": 17, "end": 24, "rawStart": 20, "rawEnd": 27}}, {"entity": "Change", "value": {"kind": "Unknown", "value": "up"}, "slotName": "Change", "rawValue": "lauter", "confidence": 1.0, "range": {"start": 25, "end": 27, "rawStart": 28, "rawEnd": 34}}], "sessionId": "wohnzimmer-snowboy-ca7b4bf6-5649-492a-ac8a-7bfb85b597c3", "customData": null, "asrTokens": [[{"value": "stell", "confidence": 1.0, "rangeStart": 0, "rangeEnd": 5, "time": null}, {"value": "radio", "confidence": 1.0, "rangeStart": 6, "rangeEnd": 11, "time": null}, {"value": "um", "confidence": 1.0, "rangeStart": 12, "rangeEnd": 14, "time": null}, {"value": "5", "confidence": 1.0, "rangeStart": 15, "rangeEnd": 16, "time": null}, {"value": "decibel", "confidence": 1.0, "rangeStart": 17, "rangeEnd": 24, "time": null}, {"value": "up", "confidence": 1.0, "rangeStart": 25, "rangeEnd": 27, "time": null}]], "asrConfidence": null, "rawInput": "stell radio um fünf dezibel lauter", "wakewordId": "snowboy", "lang": null}

(wildes) Device:

defmod lampe2 dummy
attr lampe2 readingList pct temperature volume
attr lampe2 rhasspyMapping SetOnOff:cmdOn=on,cmdOff=off\
GetOnOff:currentVal=state,valueOff=off\
GetNumeric:currentVal=temperature,type=Temperatur\
MediaControls:cmdPlay=play,cmdPause=pause,cmdStop=stop,cmdBack=previous,cmdFwd=next\
SetNumeric:currentVal=pct,minVal=0,maxVal=255,cmd=pct,step=1,type=Helligkeit\
SetNumeric:currentVal=temperature,minVal=0,maxVal=255,cmd=temperature,step=1,type=Temperatur\
SetNumeric:currentVal=volume,minVal=-40,maxVal=20,cmd=volume,step=0.5,type=Lautstärke
attr lampe2 rhasspyName lampe,radio,licht
attr lampe2 rhasspyRoom wohnzimmer,schlafzimmer
attr lampe2 room Rhasspy
attr lampe2 setList pct temperature toggle on off play stop pause next previous volume


Log:

RHASSPY: [Rhasspy] Parse (IO: rhasspyMQTT2): Msg: hermes/intent/de.fhem_SetNumeric => {"input": "
Parsed value: up for key: Change
Parsed value: 1 for key: probability
Parsed value: wohnzimmer-snowboy-ca7b4bf6-5649-492a-ac8a-7bfb85b597c3 for key: sessionId
Parsed value: 5 for key: Value
Parsed value: SetNumeric for key: intent
Parsed value: stell radio um 5 decibel up for key: input
Parsed value: decibel for key: Unit
Parsed value: radio for key: Device
Parsed value: stell radio um fünf dezibel lauter for key: rawInput
Parsed value: wohnzimmer for key: siteId
handleIntentSetNumeric called
Device selected: lampe2
rhasspyMapping selected: currentVal=pct,minVal=0,maxVal=255,cmd=pct,step=1,type=Helligkeit
runCmd called with command: pct
lampe2 pct 171 is a normal command
RHASSPY: [Rhasspy] Parse (IO: rhasspyMQTT2): Msg: hermes/dialogueManager/sessionEnded => {"termin


Hmm, da steige ich auf die Schnelle auch nicht durch, aber was ich mir notiert hatte war:
muss auf lauter/leiser begrenzt werden? Was ist mit Kleinschreibung? (Letzteres muss/kann ggf. vorher erledigt werden?

ABER:
Und etwas weiter hinten wird dann noch nach dem Type sortiert. Den sollten wir dann auch mitgeben. Geht sowas:
\[stell|stelle|mach|mache|schalt|schalte] $de.fhem.Device{Device} [$de.fhem.Device{Room}] [auf|um] [(0..100){Value}] [(prozent{Unit:percent}|grad{Unit:degree}|dezibel{Unit:decibel}{Type:volume})] [(heller{Change:up}{Type:brightness}|dunkler{Change:down}{Type:brightness}|wärmer{Change:up}{Type:temperature}|kälter{Change:down}{Type:temperature}|lauter{Change:up}{Type:volume}|leiser{Change:down}{Type:volume}
)]
\[mach] $de.fhem.Device{Device} lauter{Change:up}{Type:volume}
(Ich habe aber noch keine Idee, ob der interne JSON-Parser das sauber auseinanderfieselt...

Nachtrag: vermutlich ist es einfacher, über das zu gehen, was grade "changeType" heißt. (nicht sicher, ob der Name und die Keywords da drin "gut" sind, vermutlich verbesserungsfähig nach (z.B.) "changeRel",  "volUp", "tempDown" etc...)
\[stell|stelle|mach|mache|schalt|schalte] $de.fhem.Device{Device} [$de.fhem.Device{Room}] [auf|um] [(0..100){Value}] [(prozent{Unit:percent}|grad{Unit:degree}|dezibel{Unit:decibel})] [(heller{changeType:brighter}|dunkler{changeType:darker}|wärmer{changeType:warmer}|kälter{changeType:cooler}|lauter{{changeType:louder}|leiser{changeType:lower})]
\[mach] $de.fhem.Device{Device} lauter{Change:up}{Type:volume}

Das wird jetzt dann sehr kompliziert :D

Ursprünglich konnten wir ja anhand von "type" im Mapping unterscheiden. Das war aber halt so eine sprachabhängige Lösung.

Der zweite Satz geht auf keinen Fall.

Wir müssen uns also auf Begriffe einigen und danach dann im Code entscheiden. "volUp", "volDown", etc. finde ich ganz gut.

Können wir mit sowas umgehen:

$de.fhem.Device{Device} [0..10]{Value} [dezibel]{Unit:decibel}(lauter|rauf){Change:volUp}
$de.fhem.Device{Device} [0..10]{Value} [grad]{Unit:decibel}(leiser|runter){Change:volDown}
$de.fhem.Device{Device} [0..10]{Value} [grad]{Unit:degree} (kälter|runter){Change:tempDown}
...


Gefällt mir und sollte machbar sein!
Kannst du dazu MSG/payload generieren?
Dann schaue ich bei Gelegenheit, wie man das hinbiegen kann.Vorerst wäre wichtig, dass die alte Syntax noch geht, aber das müsste eigentlich der Fall sein...

Msg: hermes/intent/de.fhem_SetNumeric => {"input": "Musik bad 10 decibel volUp", "intent": {"intentName": "de.fhem:SetNumeric", "confidenceScore": 1.0}, "siteId": "wohnzimmer", "id": null, "slots": [{"entity": "de.fhem.Device", "value": {"kind": "Unknown", "value": "Musik"}, "slotName": "Device", "rawValue": "musik", "confidence": 1.0, "range": {"start": 0, "end": 5, "rawStart": 0, "rawEnd": 5}}, {"entity": "de.fhem.Room", "value": {"kind": "Unknown", "value": "bad"}, "slotName": "Room", "rawValue": "bad", "confidence": 1.0, "range": {"start": 6, "end": 9, "rawStart": 6, "rawEnd": 9}}, {"entity": "rhasspy/number", "value": {"kind": "Number", "value": 10}, "slotName": "Value", "rawValue": "zehn", "confidence": 1.0, "range": {"start": 10, "end": 12, "rawStart": 10, "rawEnd": 14}}, {"entity": "Unit", "value": {"kind": "Unknown", "value": "decibel"}, "slotName": "Unit", "rawValue": "dezibel", "confidence": 1.0, "range": {"start": 13, "end": 20, "rawStart": 15, "rawEnd": 22}}, {"entity": "Change", "value": {"kind": "Unknown", "value": "volUp"}, "slotName": "Change", "rawValue": "lauter", "confidence": 1.0, "range": {"start": 21, "end": 26, "rawStart": 23, "rawEnd": 29}}], "sessionId": "wohnzimmer-snowboy-26e76002-22ab-47dd-9f55-ca64e5a49019", "customData": null, "asrTokens": [[{"value": "Musik", "confidence": 1.0, "rangeStart": 0, "rangeEnd": 5, "time": null}, {"value": "bad", "confidence": 1.0, "rangeStart": 6, "rangeEnd": 9, "time": null}, {"value": "10", "confidence": 1.0, "rangeStart": 10, "rangeEnd": 12, "time": null}, {"value": "decibel", "confidence": 1.0, "rangeStart": 13, "rangeEnd": 20, "time": null}, {"value": "volUp", "confidence": 1.0, "rangeStart": 21, "rangeEnd": 26, "time": null}]], "asrConfidence": null, "rawInput": "musik bad zehn dezibel lauter", "wakewordId": "snowboy", "lang": null}

Msg: hermes/intent/de.fhem_SetNumeric => {"input": "Musik bad decibel volUp", "intent": {"intentName": "de.fhem:SetNumeric", "confidenceScore": 1.0}, "siteId": "wohnzimmer", "id": null, "slots": [{"entity": "de.fhem.Device", "value": {"kind": "Unknown", "value": "Musik"}, "slotName": "Device", "rawValue": "musik", "confidence": 1.0, "range": {"start": 0, "end": 5, "rawStart": 0, "rawEnd": 5}}, {"entity": "de.fhem.Room", "value": {"kind": "Unknown", "value": "bad"}, "slotName": "Room", "rawValue": "bad", "confidence": 1.0, "range": {"start": 6, "end": 9, "rawStart": 6, "rawEnd": 9}}, {"entity": "Value", "value": {"kind": "Unknown", "value": ""}, "slotName": "Value", "rawValue": "", "confidence": 1.0, "range": {"start": 10, "end": 9, "rawStart": 10, "rawEnd": 9}}, {"entity": "Unit", "value": {"kind": "Unknown", "value": "decibel"}, "slotName": "Unit", "rawValue": "", "confidence": 1.0, "range": {"start": 10, "end": 17, "rawStart": 10, "rawEnd": 9}}, {"entity": "Change", "value": {"kind": "Unknown", "value": "volUp"}, "slotName": "Change", "rawValue": "lauter", "confidence": 1.0, "range": {"start": 18, "end": 23, "rawStart": 10, "rawEnd": 16}}], "sessionId": "wohnzimmer-snowboy-13933d03-8d48-4d58-95a5-d6fb588516a2", "customData": null, "asrTokens": [[{"value": "Musik", "confidence": 1.0, "rangeStart": 0, "rangeEnd": 5, "time": null}, {"value": "bad", "confidence": 1.0, "rangeStart": 6, "rangeEnd": 9, "time": null}, {"value": "decibel", "confidence": 1.0, "rangeStart": 10, "rangeEnd": 17, "time": null}, {"value": "volUp", "confidence": 1.0, "rangeStart": 18, "rangeEnd": 23, "time": null}]], "asrConfidence": null, "rawInput": "musik bad lauter", "wakewordId": "snowboy", "lang": null}

Vermutlich war mein dummy-mapping (bzgl. decibel) nicht vollständig, aber in den Grundzügen scheint es so zu funktionieren - und übersichtlicher ist es m.E. auch noch :) .

"decibel" ist bisher auch keine Kategorie, die das Modul kennen würde. Kann also auch daran liegen.

Die deutschen Begriffe "Lautstärke usw. sollten jetzt auch wieder in den Mappings erkannt werden.

Ist denn sonst grade noch was offen?

Nicht viel erfreulicherweise. Und ich muss sagen, das, was tut, tut sehr zuverlässig. Echt gute Arbeit von dir!

Ich hab derzeit noch das:
- playWav liefert noch den Fehler
- getValue muss noch gut getestet werden. Funktioniert v.a. nicht mit [Device:Reading] Ausdrücken

set Rhasspy play siteId="wohnzimmer" path="/opt/fhem/test.wav"

In den Mappings wollen wir doch gar keine deutschen Begriffe?

Ach ja, und das hier:

PERL WARNING: Argument "" isn't numeric in multiplication (*) at ./FHEM/10_RHASSPY.pm line 1947.

Das passiert in SetNumeric ständig bei allen Berechnungen. Ich weiß aber noch nicht, warum. Irgendwo bekommen wir eine falsche / keine Zahl zurück.

Zitat von: Beta-User am 11 März 2021, 10:36:25
"decibel" ist bisher auch keine Kategorie, die das Modul kennen würde. Kann also auch daran liegen.

Brauchen wir das {Unit} überhaupt noch? Eigentlich nicht, oder?

Und kannst du mir bitte schreiben, wie ein korrektes Mapping jetzt aussehen muss?

Zitat von: drhirn am 11 März 2021, 10:59:41
Nicht viel erfreulicherweise. Und ich muss sagen, das, was tut, tut sehr zuverlässig. Echt gute Arbeit von dir!

Danke für die Rückmeldung!

ZitatIn den Mappings wollen wir doch gar keine deutschen Begriffe?

Jein. Wollen nicht, aber da die im Moment da sind, ist jetzt eben dieser Kompabilitäts-Layer eingezogen, und der fehlte an der Stelle noch.
Mittelfristig sollte man tatsächlich von den deutschen Begriffen weg, aber dann am besten auch gleich so, dass wir eben ein pct- oder brightness-Reading ohne Angabe eines Mappings erkennen können. Der User sollte m.E. den Anpassungsaufwand nur einmal haben bzw. ggf. können wir den ("umgezogenen") Kompabilitäts-Layer dann auch beibehalten, wenn wir diese Routine dann ggf. nur bei "reinit devices" durchlaufen...?

ZitatIch hab derzeit noch das:
- playWav liefert noch den Fehler

Code Auswählen Erweitern

set Rhasspy play siteId="wohnzimmer" path="/opt/fhem/test.wav"

Sollte jetzt auch gefixt sein.

Zitat- getValue muss noch gut getestet werden. Funktioniert v.a. nicht mit [Device:Reading] Ausdrücken

Versuch's mal mit dieser Änderung in RHASSPY_getValue():

    # Soll Reading von einem anderen Device gelesen werden?
    if ($getString =~ m{:}x) {
        $getString =~ s{\[([^]]+)]}{$1}x; #remove brackets
        my @replace = split m{:}x, $getString;
        $device = $replace[0];
        $getString = $replace[1] // $getString;
        return ReadingsVal($device, $getString, 0);
    }

Zitat von: drhirn am 11 März 2021, 11:13:46
Brauchen wir das {Unit} überhaupt noch? Eigentlich nicht, oder?

Puh, du kannst Fragen stellen... Im Moment vermutlich sinnvoll für percent?

Zitat von: drhirn am 11 März 2021, 11:09:30

Code Auswählen Erweitern

PERL WARNING: Argument "" isn't numeric in multiplication (*) at ./FHEM/10_RHASSPY.pm line 1947.
Das passiert in SetNumeric ständig bei allen Berechnungen. Ich weiß aber noch nicht, warum. Irgendwo bekommen wir eine falsche / keine Zahl zurück.

Habe ein Pflaster geklebt; die eigentliche Ursache ist aber woanders, aber dahin kommen wir ggf. später erst nochmal...

Zitat von: drhirn am 11 März 2021, 11:28:14
Und kannst du mir bitte schreiben, wie ein korrektes Mapping jetzt aussehen muss?

Die "verständlichen Schlüsselworte" sind in $internal_mappings->{Change}, also "lightUp" bis "setDown".
Funktionieren sollte, was dort in {Type} zu finden ist, also insbesondere:
SetNumeric:currentVal=pct,minVal=0,maxVal=255,cmd=pct,step=1,type=brightness\
SetNumeric:currentVal=temperature,minVal=0,maxVal=255,cmd=temperature,step=1,type=temperature\
SetNumeric:currentVal=volume,minVal=-40,maxVal=20,cmd=volume,step=0.5,type=volumeDas Mapping scheint man nur zu benötigen, wenn es mehrere SetNummeric gibt, oder?

(Der mittelfristige Plan wäre, z.B. pct dann direkt brightness zuzuordnen mit minVal=0 und maxVal=100 (bzw. 99 für TYPE=ZWave), so dass man da nur was angeben muss, wenn man es anders haben will...? "temperature" und "volume" sind "doppelt" und daher eigentlich unnötig.)

Fyi: Habe mal das rhasspy-deb auf einem meiner Server installiert (x86), und die App hat auch Kontakt aufgenommen. Viel mehr ist aber noch nicht passiert...

Zitat von: Beta-User am 11 März 2021, 12:06:42
Jein. Wollen nicht, aber da die im Moment da sind, ist jetzt eben dieser Kompabilitäts-Layer eingezogen, und der fehlte an der Stelle noch.
Mittelfristig sollte man tatsächlich von den deutschen Begriffen weg, aber dann am besten auch gleich so, dass wir eben ein pct- oder brightness-Reading ohne Angabe eines Mappings erkennen können.

Die User müssen dann eh noch mehr umbauen. Ich wäre daher fast dafür, dass wir einen "harten Schnitt" machen.

ZitatPuh, du kannst Fragen stellen... Im Moment vermutlich sinnvoll für percent?

Wenn im Mapping ein map=percent steht, soll in Prozent gerechnet werden. Sonst eh nicht.

ZitatFyi: Habe mal das rhasspy-deb auf einem meiner Server installiert (x86), und die App hat auch Kontakt aufgenommen. Viel mehr ist aber noch nicht passiert...

Cooool :)

Zitat von: drhirn am 11 März 2021, 13:24:48
Die User müssen dann eh noch mehr umbauen. Ich wäre daher fast dafür, dass wir einen "harten Schnitt" machen.

Bin noch nicht sicher, ob wir es nicht so hinbekommen, dass auch weiter die "alten" Vorgehensweisen und Werte erlaubt bleiben (und nur nicht mehr "beworben" werden).

Mein Ziel wäre eher, das so zu machen, dass es
- "international verwendbar" ist (weitestgehend done, oder?) und
- für Neueinsteiger ggf. mit deutlich weniger Aufwand einzurichten ist, v.a., wenn bereits mappings für andere Lösungen da sind.

Im Moment bedeuten die Umbauten "hinter der Fassade" einfach, dass jemand, der jetzt einsteigt dann eben direkt die englischen Begriffe im Mapping verwenden und die englischen "keywords" an das Modul übergeben sollte, that's all...

So, wie es jetzt gebaut ist, bedeutet es an fast allen Stellen (außer der Auswertung des mappings!) eigentlich nur, dass es einen kleinen Overhead gibt, wenn man entweder die deutschen oder keine keywords angibt; wer es "richtig macht", bekommt auch ohne Umschweife ein passendes Ergebnis ;) .

ZitatWenn im Mapping ein map=percent steht, soll in Prozent gerechnet werden. Sonst eh nicht.

Das stimmt jedenfalls im Moment nicht, und ich meine auch, an der Logik an sich nichts gedreht zu haben. Wenn man Unit=>percent (bzw. bisher: "Prozent" ) übergeben hat, wird auch in Prozent gerechnet, und das finde ich - jedenfalls bis dato -auch ok so. Das gilt umso mehr, da man ggf. später auf den "Luxus" eines expliziten Mappings verzichten können soll ;) .

ZitatCooool :)

Mal sehen, wie "cool" das ist; werde jetzt erst mal verstehen müssen, wie der Dienst funktioniert und dann auch, was mir ggf. noch an scripten fehlt; der Debian-Way ist dann doch etwas anders als Docker, und für eine eventuell Sprachausgabe muss ich mir auch was ausdenken, falls es nicht über das Handy zu machen wäre... Alles noch "black box".

Zitat von: Beta-User am 11 März 2021, 13:45:06
Das stimmt jedenfalls im Moment nicht, und ich meine auch, an der Logik an sich nichts gedreht zu haben. Wenn man Unit=>percent (bzw. bisher: "Prozent" ) übergeben hat, wird auch in Prozent gerechnet, und das finde ich - jedenfalls bis dato -auch ok so. Das gilt umso mehr, da man ggf. später auf den "Luxus" eines expliziten Mappings verzichten können soll ;) .

Also, laut Tyraz:

Zitat
Erläuterung zu map=percent:
Ist die Option gesetzt, werden alle numerischen Stellwerte als Prozentangaben zwischen minVal und maxVal verstanden.
Bei einer Lampe mit minVal=0 und maxVal=255 und map=percent verhält sich also Stelle die Lampe auf 50
genauso wie Stelle die Lampe auf 50 Prozent.
Dies mag bei einer Lampe mehr Sinn ergeben als Werte von 0...255 anzusagen.
Beim Sollwert eines Thermostats hingegen wird man die Option eher nicht nutzen,
da dort die Angaben normal in °C erfolgen und nicht prozentual zum möglichen Sollwertbereich.

Aber ja, spricht nichts dagegen, es so zu machen.

Zitat
Mal sehen, wie "cool" das ist; werde jetzt erst mal verstehen müssen, wie der Dienst funktioniert und dann auch, was mir ggf. noch an scripten fehlt; der Debian-Way ist dann doch etwas anders als Docker, und für eine eventuell Sprachausgabe muss ich mir auch was ausdenken, falls es nicht über das Handy zu machen wäre... Alles noch "black box".

Debian ist eigentlich sogar einfacher. Sofern die Installation problemlos durchläuft und keine Requirements fehlen.
Wie gesagt, ich stehe zur Verfügung, wenn's Fragen gibt.

Modul kann noch immer nicht rechnen ;)

Ich bekomm unreproduzierbar bei "mach lampe dunkler"

Msg: hermes/intent/de.fhem_SetNumeric => {"input": "mach lampe lightDown", "intent": {"intentName": "de.fhem:SetNumeric", "confidenceScore": 1.0}, "siteId": "wohnzimmer", "id": null, "slots": [{"entity": "de.fhem.Device", "value": {"kind": "Unknown", "value": "lampe"}, "slotName": "Device", "rawValue": "lampe", "confidence": 1.0, "range": {"start": 5, "end": 10, "rawStart": 5, "rawEnd": 10}}, {"entity": "Value", "value": {"kind": "Unknown", "value": ""}, "slotName": "Value", "rawValue": "", "confidence": 1.0, "range": {"start": 11, "end": 10, "rawStart": 11, "rawEnd": 10}}, {"entity": "Change", "value": {"kind": "Unknown", "value": "lightDown"}, "slotName": "Change", "rawValue": "dunkler", "confidence": 1.0, "range": {"start": 11, "end": 20, "rawStart": 11, "rawEnd": 18}}], "sessionId": "wohnzimmer-snowboy-67f0563c-282d-4035-b486-7cc373587b55", "customData": null, "asrTokens": [[{"value": "mach", "confidence": 1.0, "rangeStart": 0, "rangeEnd": 4, "time": null}, {"value": "lampe", "confidence": 1.0, "rangeStart": 5, "rangeEnd": 10, "time": null}, {"value": "lightDown", "confidence": 1.0, "rangeStart": 11, "rangeEnd": 20, "time": null}]], "asrConfidence": null, "rawInput": "mach lampe dunkler", "wakewordId": "snowboy", "lang": null}
PERL WARNING: Argument "" isn't numeric in subtraction (-) at ./FHEM/10_RHASSPY.pm line 1971
Das ist hier:

                # Stellwert um Wert x ändern ("Mache Lampe um 20 heller" oder "Mache Lampe heller")
                #elsif ((!defined $unit || $unit ne 'Prozent') && defined $change && !$forcePercent) {
                elsif ( ( !defined $unit || !$ispct ) && defined $change && !$forcePercent) {
                    $newVal = ($up) ? $oldVal + $diff : $oldVal - $diff;
                }


Reproduzierbar wird aber gar nicht gerechnet. Das Reading wird aktualisiert, ändert sich aber nicht.

Aktuelles Mapping:

SetNumeric:currentVal=pct,minVal=0,maxVal=100,cmd=pct,step=1,type=brightness


Generell gibt's bei allen Arten von Satz hin und wieder Use of uninitialized value-Meldungen. Das kann ich aber nicht reproduzieren.

Aber, damit ich nicht nur schlechte Nachrichten habe:
"lampe um 10 prozent heller" funktioniert

Glaube, die Ursache gefunden zu haben:
Da wurden teils Hashes mit leerem Inhalt erzeugt, '' ist halt nicht undef...

---

OT:
Da wir hier jetzt die ganze Zeit eigentlich eher Rhasspy-spezifisches diskutieren, bin ich nicht mehr sicher, ob der Thread noch im richtigen Forenbereich ist ::) ...

Zitat von: rudolfkoenig am 11 März 2021, 12:37:20
Im Development Bereich des Forums [...] das Ziel ist aber Signal/Noise Ratio hoch zu halten, damit man das Abonnieren fuer Maintainer zu Pflicht machen kann.

Wir machen grade ziemlich viel "noise"...

(Für spezielle Fragen zu Rhasspy@Debian würde ich aber so oder so bei Bedarf einen separaten Thread aufmachen).

Alles klar, machen wir das so. Hier geht's weiter: https://forum.fhem.de/index.php/topic,119447.0.html