Perl - Modul 10_RHASSPY.pm "professionalisieren"

[Beta-User]

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

[drhirn]

Haha, du hast angefangen mit Vom-Thema-Ablenken

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.

[JensS]

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

[Beta-User]

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

[drhirn]

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!

[Beta-User]

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

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

[drhirn]

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.

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.

[betateilchen]

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

[Beta-User]

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 .

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

[drhirn]

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

[Beta-User]

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

[drhirn]

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!

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

Wir werden sehen. Ich kann's mal versuchen.

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

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.

[Beta-User]

Irgendwie wird mein ResponseOnOff($DEVICE) nicht mehr ausgeführt.
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:

Code Auswählen Erweitern

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

[drhirn]

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

[Beta-User]

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:

Code Auswählen Erweitern


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