Perl - Modul 10_RHASSPY.pm "professionalisieren"

[Beta-User]

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

[drhirn]

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?

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

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?

[Beta-User]

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

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

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.

[drhirn]

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.

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.

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

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

[Beta-User]

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

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

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

[drhirn]

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

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

[Beta-User]

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

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

[Beta-User]

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

[drhirn]

So, ich hab jetzt da den MQTT2_CLIENT

Code Auswählen Erweitern


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


und ein neues Rhasspy-Device:

Code Auswählen Erweitern


defmod Rhasspy RHASSPY rhasspyMQTT2 Wohnzimmer
attr Rhasspy IODev rhasspyMQTT2


Publish scheint zu funktionieren. Subscribe nicht.

[Beta-User]

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:

[drhirn]

Ich merke da jetzt so spontan keinen Unterschied

[drhirn]

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

Code Auswählen Erweitern


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.

Code Auswählen Erweitern


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


Für Linux:

Code Auswählen Erweitern


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


[Beta-User]

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

[drhirn]

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?

[Beta-User]

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.