Autor Thema: Perl - Modul 10_RHASSPY.pm "professionalisieren"  (Gelesen 11457 mal)

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 14653
  • "Developer"?!? Meistens doch eher "User"
Antw:Perl - Umlaute mit lc
« Antwort #15 am: 19 Februar 2021, 13:19:30 »
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...
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn:MySensors, Weekday-&RandomTimer, Twilight,  AttrTemplate {u.a. mqtt2, mysensors, zwave}

Offline drhirn

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1641
Antw:Perl - Umlaute mit lc
« Antwort #16 am: 19 Februar 2021, 13:33:45 »
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;

Tut es, danke! Warum?

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

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 14653
  • "Developer"?!? Meistens doch eher "User"
Antw:Perl - Umlaute mit lc
« Antwort #17 am: 19 Februar 2021, 13:56:19 »
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:
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.
« Letzte Änderung: 19 Februar 2021, 14:43:20 von Beta-User »
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn:MySensors, Weekday-&RandomTimer, Twilight,  AttrTemplate {u.a. mqtt2, mysensors, zwave}

Offline drhirn

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1641
Antw:Perl - Umlaute mit lc
« Antwort #18 am: 19 Februar 2021, 14:09:22 »
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:
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.

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

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 14653
  • "Developer"?!? Meistens doch eher "User"
Antw:Perl - Umlaute mit lc
« Antwort #19 am: 19 Februar 2021, 14:23:57 »
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 ;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...

Zitat
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...
« Letzte Änderung: 24 Februar 2021, 08:01:05 von Beta-User »
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn:MySensors, Weekday-&RandomTimer, Twilight,  AttrTemplate {u.a. mqtt2, mysensors, zwave}

Offline drhirn

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1641
Antw:Perl - Umlaute mit lc
« Antwort #20 am: 19 Februar 2021, 15:03:20 »
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.

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

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 14653
  • "Developer"?!? Meistens doch eher "User"
Antw:Perl - Umlaute mit lc
« Antwort #21 am: 19 Februar 2021, 15:15:01 »
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...

Zitat
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.
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn:MySensors, Weekday-&RandomTimer, Twilight,  AttrTemplate {u.a. mqtt2, mysensors, zwave}

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 14653
  • "Developer"?!? Meistens doch eher "User"
Antw:Perl - Umlaute mit lc
« Antwort #22 am: 19 Februar 2021, 15:25:18 »
Nachtrag noch: Die Parse-Fn sollte auch korrekt benannt werden: RHASSPY_Parse (#821), sonst knirscht das vermutlich auch dort...
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn:MySensors, Weekday-&RandomTimer, Twilight,  AttrTemplate {u.a. mqtt2, mysensors, zwave}

Offline drhirn

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1641
Antw:Perl - Umlaute mit lc
« Antwort #23 am: 19 Februar 2021, 15:29:07 »
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.

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 14653
  • "Developer"?!? Meistens doch eher "User"
Antw:Perl - Umlaute mit lc
« Antwort #24 am: 19 Februar 2021, 15:41:18 »
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:
« Letzte Änderung: 24 Februar 2021, 08:00:42 von Beta-User »
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn:MySensors, Weekday-&RandomTimer, Twilight,  AttrTemplate {u.a. mqtt2, mysensors, zwave}

Offline drhirn

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1641
Antw:Perl - Umlaute mit lc
« Antwort #25 am: 19 Februar 2021, 15:45:01 »
Ich merke da jetzt so spontan keinen Unterschied

Offline drhirn

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1641
Antw:Perl - Umlaute mit lc
« Antwort #26 am: 19 Februar 2021, 15:50:00 »
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
« Letzte Änderung: 19 Februar 2021, 15:56:20 von drhirn »

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 14653
  • "Developer"?!? Meistens doch eher "User"
Antw:Perl - Umlaute mit lc
« Antwort #27 am: 19 Februar 2021, 16:59:56 »
...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).
« Letzte Änderung: 24 Februar 2021, 08:00:28 von Beta-User »
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn:MySensors, Weekday-&RandomTimer, Twilight,  AttrTemplate {u.a. mqtt2, mysensors, zwave}

Offline drhirn

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1641
Antw:Perl - Umlaute mit lc
« Antwort #28 am: 19 Februar 2021, 17:16:17 »
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?

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 14653
  • "Developer"?!? Meistens doch eher "User"
Antw:Perl - Umlaute mit lc
« Antwort #29 am: 19 Februar 2021, 17:28:18 »
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.
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn:MySensors, Weekday-&RandomTimer, Twilight,  AttrTemplate {u.a. mqtt2, mysensors, zwave}

 

decade-submarginal