Modulentwicklung für Rhasspy Sprachassistent

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

Vorheriges Thema - Nächstes Thema

drhirn

INFO

Ich habe das GitHub-Repository nach https://github.com/fhem/fhem-rhasspy verschoben.

Das ursprüngliche gibt's zwar noch. Ist aber Read-Only und nur aus sentimentalen Gründen (vorläufig) noch vorhanden. Bitte nicht mehr verwenden.

Beta-User

#586
Das mit den Auswahldialogen scheint soweit zu laufen, ein paar "uninitialized" sind mir noch über den Weg gelaufen, und zu den "odd elements" ist mir auch was eingefallen, das zu helfen scheint... Vermutlich gibt's trotzdem noch das eine oder andere, wo man nacharbeiten muss.

Für die Vermeidung von Auswahldialogen gibt's dann auch noch ein "special" ( ::) ) "priority".

"humidity" sollte jetzt überall passen.

Dann müssten wir mal wieder sammeln, ob bzw. was ggf. noch fehlt bzw. Priorität hat. Auf die Schnelle wäre das aus meiner Sicht gDT "scene".

EDIT: Wg. der utf8/UTF-8-Geschichte: Das ist eher Rumprobieren als konsolidierte Erkenntnis; hatte gesehen, dass in einer deiner früheren Versionen mal utf8 als default gesetzt war und selbst mit UTF-8 ein paar Probleme gesehen...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Beta-User

#587
Zitat von: Beta-User am 06 Mai 2021, 08:23:09
Dann müssten wir mal wieder sammeln, ob bzw. was ggf. noch fehlt bzw. Priorität hat. Auf die Schnelle wäre das aus meiner Sicht gDT "scene".
...so ruhig hier...?

Habe mal in der Zwischenzeit noch etwas am Thema "scenes" rumgekaut; mir ist klar, dass du das bisher über shortcuts gelöst hast, aber mir schwebte eine eher generische Lösung vor ::) .

Hier also eine Fassung, die "SetScene" als intent kennt :) .
Man kann entweder ein SetScene-mapping in rhasspyMapping erstellen, oder bei gesetztem genericDeviceType (das kann "media" sein oder irgendwas anderes, das bisher bekannt ist), das automatisch erkennen lassen und dann die dazu passenden "Worte" über "specials" einfügen:
defmod Sonos dummy
attr Sonos devStateIcon play:audio_play pause:audio_pause stop:audio_stop next:audio_ff previous:audio_rew
attr Sonos genericDeviceType media
attr Sonos readingList power volume scene
attr Sonos rhasspyGroup Multimedia
attr Sonos rhasspyName Sonos
attr Sonos rhasspyRoom Wohnzimmer
attr Sonos rhasspySpecials scenes:scene2="Kino zu zweit" scene3=none scene1=none scene4=none
attr Sonos room Rhasspy,Wohnzimmer
attr Sonos setList on:noArg off:noArg volumeStraight:slider,-80,1,16 volume:slider,0,1,100 volumeUp volumeDown input:audio1,audio2,audio3,audio4,audio5,av1,av2,airplay,bluetooth,deezer,hdmi1,hdmi2,hdmi3,hdmi4,hdmi5,juke,musiccastlink,netradio,napster,phono,qobuz,server,spotify,tidal,tuner,usb,v-aux mute:on,off,toggle remoteControl:setup,up,down,left,right,return,option,display,tunerPresetUp,tunerPresetDown,enter scene:scene1,scene2,scene3,scene4 straight:on,off 3dCinemaDsp:off,auto adaptiveDrc:off,auto direct:on,off surroundDecoder:dolbypl,dolbypliimovie,dolbypliimusic,dolbypliigame,dolbypliixmovie,dolbypliixmusic,dolbypliixgame,dtsneo:6cinema,dtsneo:6music dsp:hallinmunich,hallinvienna,chamber,cellarclub,theroxytheatre,thebottomline,sports,actiongame,roleplayinggame,musicvideo,standard,spectacle,sci-fi,adventure,drama,monomovie,surrounddecoder,2chstereo,7chstereo enhancer:on,off sleep:off,30min,60min,90min,120min,last bass:slider,-6,0.5,6 treble:slider,-6,0.5,6 partyMode:on,off extraBass:off,auto ypaoVolume:off,auto tunerFrequency displayBrightness:slider,-4,1,0 statusRequest:noArg


Das ganze generiert zwei neue slots, sentences habe ich bisher noch nicht dazu getestet, aber sowas sollte klappen:
[de.fhem:SetScene]
stelle ( der| die | das ) $de.fhem.Device-scene{Device} [( im [Raum] | in der ) $de.fhem.Room){Room}] auf [( [die] Szene | den Modus )] $de.fhem.Scenes [Modus]

Bin mal gespannt auf dein/euer feedback, und allgemein würde mich interessieren, ob und wie das mit den "slots-by-intent" ankommt. Theoretisch sollte es auf dem bei dem SetScene gewählten Weg auch möglich sein, (weitgehend?) unabhängig von gDT zusätzliche slots zu generieren, die jeweils dann nur die Devices beinhalten, die den jeweiligen Intent auch tatsächlich "können".

Praktisch ist es auch nicht wirklich schwierig, siehe Anhang...

EDIT2: Nanu, kein Download bisher?
Da war noch ein kleiner Typo drin, aber jetzt sieht es ganz ok aus. Hier noch mein aktueller  sentence:
[de.fhem:SetScene]
stelle ( den | die | das ) $de.fhem.Device-scene{Device} [ ( im | in der ) $de.fhem.Room{Room} ] auf [ ( die Szene | den Modus ) ] $de.fhem.Scenes [Modus]
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

drhirn

Ich war leider unfreiwillig offline die letzten Tage und habe mich daher auf's schöne Wetter konzentriert. Deswegen so ruhig ;)

ZitatMan kann entweder ein SetScene-mapping in rhasspyMapping erstellen
Wie würde das aussehen?

Beta-User

...dann mal willkommen zurück in der online-Welt!

(Das schöne Wetter hat meine RHASSPY-Aktivitäten auch etwas gebremst, aber wir sind auch m.E. zwischenzeitlich auf einem Stand, den ich mal als "ziemlich komplett" ansehen würde, s.u.).

attr lampe1 rhasspyMapping SetScene:scene1=Das wäre TV ansehen,scene2=Das wäre was anderes,scene5=und nochmal was anderes

Wie sich das auswirkt, siehst du am besten in einem list vom RHASSPY-Device und dem, was dann an slots dazu erstellt wird. Du bekommst den Text (z.B. "Das wäre TV ansehen") als komplette Elemente in den "Erkennungstext" im slot von Rhasspy (z.B. in "de.fhem.SetScene"), und dann "{Scene:scene1}" zurück, wenn der betreffende Text erkannt wird, und das ganze läßt sich beschränken auf Devices, die "SetScene" überhaupt verarbeiten können.

Was ggf. zur Abrundung noch fehlt, ist "nextScene" bzw. "previousScene", aber da bin ich zum einen noch unsicher, ob das sinnvoll ist und wie es ggf. umzusetzen wäre (bin bei lightScene eher noch Anfänger, und z.B. mein Verstärker kann das nicht orginär).



Insgesamt habe ich den Eindruck, dass das mit den jeweils für bestimmte Kommandos "passenden" Device-slots eine gute Idee war, das paßt jetzt bei meinen Tests sehr viel besser wie früher.




Was auch gut klappt, ist das mit "priority". Konkret läuft das bei mir jetzt so, dass für (Ist-) Temperaturen "outsideRoom" der Außenfühler herangezogen wird, und in den Innenräumen jeweils der "Raumfühler" - was entweder ein (CUL_HM-) Wandthermostat ist oder ein HUEDEvice bzw. MQTT2_DEVICE (das als "virtueller Wandthermostat" auch die Thermostate steuert). Für die Soll-Temperatur wird dann entweder der "echte Raumfühler" herangezogen, oder eben einer der beiden ("geteamten") Thermostate.

"volume" ist dann jeweils der Verstärker, nicht der MPD.

Damit hat sich das mit den Rückfragen auch weitestgehend erledigt...



Bin aber wegend des schönen Wetters auch noch nicht komplett durch mit Testen und Umbauen meiner sentences ;) .
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

drhirn

Das mit der Priorität, wie sieht das in der Praxis aus? Könntest du mir das ein Beispiel-Special schreiben bitte?

Beta-User

Hier mal die fraglichen 3 (den RT-DN mit prio für desired-temp kann man sich dazudenken)

"fake" Raumfühler, TYPE=MQTT2_DEVICE:
attr Raumfuehler_Wohnzimmer rhasspySpecials priority:inRoom=temperature,humidity
Wand-Thermostat TYPE=CUL_HM:attr Thermostat_EssZi_Climate rhasspySpecials priority:inRoom=desired-temp,temperature,humidity
Außentemperatur etc:
attr MYSENSOR_97 rhasspyMapping GetNumeric:currentVal=temperature2,type=temperature\GetNumeric:currentVal=humidity3,type=humidity
attr MYSENSOR_97 rhasspyName aussenthermometer,thermometer
attr MYSENSOR_97 rhasspyRoom garten,draussen
attr MYSENSOR_97 rhasspySpecials priority:outsideRoom=temperature inRoom=temperature


Ob man inRoom _und_ outsideRoom setzt, ist eine Zweckmäßigkeitsfrage; tendenziell wäre ich zurückhaltend mit "outside".

Generell wäre es ggf. hilfreich, mal einen Wiki-Artikel zu RHASSPY anzufangen, dann kann man das gleich verlinken, wenn es irgenwohin passende Querbezüge gibt?
Z.B. das mit den "MainRooms" und dem "alias" steht bisher auch nirgends, wo es herkommt und was es soll (ist zwar "fast selbsterklärend", aber verkehrt wäre es nicht, auch das mal darzustellen, falls es "bleiben darf"?)...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Beta-User

#592
Update nach  der Jagd nach ein paar weiteren "uninitialized"-Meldungen...

Ist sonst grade noch was offen?

Ich bin übrigens im großen und ganzen zufrieden damit, wie das jetzt läuft.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

DrBasch

Guten Morgen.

Entschuldigt bitte, dass ich mich hier einklinke... 

;D
Zitat von: Beta-User am 19 Mai 2021, 08:33:06
Update nach  der Jagd nach ein paar weiteren "uninitialized"-Meldungen...

Ist sonst grade noch was offen?

Da Du gerade nach uninitialized-Meldungen fragst... bin eben über eine gestolpert.  ;D

Ich habe jetzt 14 Tage versucht, das Rhasspy-Modul bei mir an den Start zu bringen. Es wollte und wollte einfach nicht funktionieren (d.h. ich konnte kein Dummy o.a. on/off-schalten). Heute bin ich der Sache endlich auf die Spur gekommen.

Nach einer Einrichtung gemäß github/readme bzw. cref konnte ich mit verbose 5 quasi nur Logeintäge vom MQTT2_CLIENT-Device finden. Das RHASSPY-Modul machte sich nur durch ein
"perl warning: use of uninitialized string in ne ... 10_RHASSPY.pm"
bemerkbar.

Das Warning konnte ich auf die Parse-Funktion zurückführen.
sub Parse {
    my $iodev = shift // carp q[No IODev provided!] && return;
    my $msg   = shift // carp q[No message to analyze!] && return;

  ...

    return q{[NEXT]} if !grep( { m{\A$shorttopic}x } @topics);

    my @instances = devspec2array('TYPE=RHASSPY');

    for my $dev (@instances) {
        my $hash = $defs{$dev};
        # Name mit IODev vergleichen
->        next if $ioname ne AttrVal($hash->{NAME}, 'IODev', undef);
        next if IsDisabled( $hash->{NAME} );
        my $topicpart = qq{/$hash->{LANGUAGE}\.$hash->{fhemId}\[._]|hermes/dialogueManager};
        next if $topic !~ m{$topicpart}x;


Das Attribut "IODev" wird offensichtlich im Gegensatz zu Internal bzw. Reading "IODev" nicht automatisch gesetzt. Erst nach händischem setzen des Attributs
"attr Rhasspy IODev mqtt_Rhasspy" konnte ich mit dem RHASSPY-Modul mein switch-dummy schalten.

Ich war so glücklich wie ein junger Vater, dessen Sohn (namens Jarvis) seinen ersten Satz gesprochen hat:
"Sorry but something went not as expected"
... so etwas bleibt einem ein Leben lang in Erinnerung... hab immer noch Tränen in den Augen ;D

Der cref bzw. der github-Doku hab ich nicht entnehmen können, dass ich das Attribut setzen muss.
Sollte man das nicht als wichtigen Hinweis in die Doku aufnehmen (oder es mehr hervorheben, falls ich es schlichtweg überlesen habe) ?
Oder kann man die IODev über ein Internal referenzieren, das ggf. FHEM-neustartübergreifend abhängig vom IODev-Attribut gesetzt wird?

In jedem Fall möchte Euch für die Entwicklung des Moduls danken, das eröffnet uns neue Welten in unserem smart home-Universum.

Mögen die Spiele beginnen!

drhirn

Zitat von: Beta-User am 19 Mai 2021, 08:33:06
Update nach  der Jagd nach ein paar weiteren "uninitialized"-Meldungen...
Danke!

Zitat
Ist sonst grade noch was offen?
Bei mir nicht. Ich muss aber gestehen, ich mache derzeit gar nichts mit Rhasspy. Zu viele andere Sachen um die Ohren. Ich hör dem Ding nur zu, wie es sich mit meinem TV unterhält. Ansprachen von mir werden ja in der Regel leider ignoriert. ;)

Beta-User

#595
Zitat von: DrBasch am 19 Mai 2021, 12:20:14
Guten Morgen.

Entschuldigt bitte, dass ich mich hier einklinke... 
Kein Problem, gerne!

Zitat

        # Name mit IODev vergleichen
->        next if $ioname ne AttrVal($hash->{NAME}, 'IODev', undef);


Das Attribut "IODev" wird offensichtlich im Gegensatz zu Internal bzw. Reading "IODev" nicht automatisch gesetzt. Erst nach händischem setzen des Attributs [...]
...irgendwie hatte ich schon darauf gewartet, dass mir die jüngsten Änderungen rund um AssignIOPort vor die Füße fallen:
Zitat von: rudolfkoenig am 02 Mai 2021, 20:16:20
Wenn man im Modul auf das Vorhandensein des IODev Attributes prueft, dann kann das zu Problemen fuehren.
Ich bin der Meinung, dass das nicht notwendig ist, das Modul soll (wenn ueberhaupt!) nur das IODev Internal anfassen.
Eigentlich sollte die Kommunikation zwischen den beiden Modulen ueber IOWrite() bzw Dispatch laufen.
Das "Problem" hier (und bei MQTT_GENERIC_BRIDGE) ist aber etwas anders gelagert wie bei den Funk-IO's, bei denen es zu _anders gelagerten_ Doppelungen usw. kommen kann; muss ich mir ansehen, wie man das am besten löst.

Bisher war es (jedenfalls in meiner Erinnerung) so, dass IODev als Attribut automatisch immer gesetzt wurde (und meinem Bauchgefühl nach _hier_ (!) auch weiter gesetzt werden sollte). Muss mal ein paar Tests machen...

Zitat
Oder kann man die IODev über ein Internal referenzieren, das ggf. FHEM-neustartübergreifend abhängig vom IODev-Attribut gesetzt wird?
Ist das Attribut gesetzt, wird das Internal auch entsprechend angelegt; das "Problem" ist, dass das Internal einen Neustart nicht überlebt, und AssignIOPort (soweit ich mich entsinne) immer das _letzte_ passende IO in der cfg heranzieht, und daraus dann eben neuerdings kein Attribut mehr macht, sondern (auch) ein _Reading_ (das dann auch (saubere) Neustarts überlebt)...

Diese Kaskade könnte auf die Schnelle so aussehen:
next if $ioname ne AttrVal($hash->{NAME}, 'IODev', ReadingsVal($hash->{NAME}, 'IODev', InternalVal($hash->{NAME}, 'IODev', 'none')));
Bin aber nicht sicher, ob das schon alles war, weil auch das bezogene IOWrite() muss ja auch auf das "richtige" IODev verweisen...

ZitatSollte man das nicht als wichtigen Hinweis in die Doku aufnehmen (oder es mehr hervorheben, falls ich es schlichtweg überlesen habe) ?
Sollte man wohl, es war nur bis eben gar nicht als Problem bekannt ;) .

ZitatIn jedem Fall möchte Euch für die Entwicklung des Moduls danken, das eröffnet uns neue Welten in unserem smart home-Universum.
(Von meiner Seite:) Gerne!

War für mich auch eine sehr hilfreiche Erweiterung :) .
Zitat
Mögen die Spiele beginnen!
Dann mal viel Spaß - und ruhig weiter Fragen stellen, wenn was unklar ist bzw. (v.a.) die cref verbessert werden kann!

Zitat von: drhirn am 19 Mai 2021, 13:00:24
Bei mir nicht. Ich muss aber gestehen, ich mache derzeit gar nichts mit Rhasspy. Zu viele andere Sachen um die Ohren. Ich hör dem Ding nur zu, wie es sich mit meinem TV unterhält. Ansprachen von mir werden ja in der Regel leider ignoriert. ;)
;D
Wenn man das Handy zückt, um mit dem "Knopf" die App zu aktivieren, klappen Anweisungen in der Regel sogar bei lauter Musik im Hintergrund... :P
(Man muss die App aber gelegentlich neu starten, irgendwie verliert sie gelegentlich die Verbindung).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

drhirn

Zitat von: DrBasch am 19 Mai 2021, 12:20:14
Das Attribut "IODev" wird offensichtlich im Gegensatz zu Internal bzw. Reading "IODev" nicht automatisch gesetzt. Erst nach händischem setzen des Attributs
"attr Rhasspy IODev mqtt_Rhasspy" konnte ich mit dem RHASSPY-Modul mein switch-dummy schalten.

Das hat mich jetzt doch schwer gewundert, weil das bei mir immer automatisch gesetzt wurde. Und wird. Hab ich gerade ausprobiert.

Es wird aber nicht automatisch gesetzt, wenn clientOrder im MQTT2_CLIENT nicht richtig gesetzt ist habe ich gerade herausgefunden.

Wie dem auch sei, in der aktuellen dev-Version gibt's sowohl in CRef, als auch README einen Hinweis auf Kontrolle des Attributs.

Danke für den Hinweis!

DrBasch

Zitat von: Beta-User am 19 Mai 2021, 13:06:43

Ist das Attribut gesetzt, wird das Internal auch entsprechend angelegt; das "Problem" ist, dass das Internal einen Neustart nicht überlebt, und AssignIOPort (soweit ich mich entsinne) immer das _letzte_ passende IO in der cfg heranzieht, und daraus dann eben neuerdings kein Attribut mehr macht, sondern (auch) ein _Reading_ (das dann auch (saubere) Neustarts überlebt)...

Diese Kaskade könnte auf die Schnelle so aussehen:
next if $ioname ne AttrVal($hash->{NAME}, 'IODev', ReadingsVal($hash->{NAME}, 'IODev', InternalVal($hash->{NAME}, 'IODev', 'none')));
Bin aber nicht sicher, ob das schon alles war, weil auch das bezogene IOWrite() muss ja auch auf das "richtige" IODev verweisen...

Wow  :D... Danke für die Erklärung... AssignIOPort u. IOWrite Begriffe, mit denen ich mich noch nicht auseinandersetzen musste... ich glaube aber prinzipiell verstanden zu haben worum es geht.
Vor allem aber hast Du mir bewußt gemacht, dass _Readings_ Neustarts überstehen können... Die Sache mit der fhem.save hab ich zwar irgendwann schonmal gelesen, aber mangels praktischem Bezug nicht verinnerlicht...


Zitat von: drhirn am 19 Mai 2021, 13:07:52
Das hat mich jetzt doch schwer gewundert, weil das bei mir immer automatisch gesetzt wurde. Und wird. Hab ich gerade ausprobiert.

Es wird aber nicht automatisch gesetzt, wenn clientOrder im MQTT2_CLIENT nicht richtig gesetzt ist habe ich gerade herausgefunden.

clientOrder war bei mir auf "RHASSPY" gesetzt; ohne MQTT_GENERIC_BRIDGE bzw. MQTT2_DEVICE. MQTT läuft hier z.Zt. ja ausschließlich für Rhasspy.


Da das Testsystem noch lief, konnte ich zwei Versuchsreihen durchlaufen lassen. Einmal mit Modulversion 0.4.12 und einmal 0.4.14:

- Bestehende Devices MQTT2_CLIENT und RHASSPY gelöscht und fhem.cfg gespeichert.

- Module /opt/fhem/FHEM kopiert und FHEM neu gestartet. Zuerst 0.4.12 im zweiten Durchlauf 0.4.14.

- MQTT2_CLIENT-Device und RHASSPY-Device anlegen.
define mqtt2_Rhasspy MQTT2_CLIENT 127.0.0.1:12183
attr mqtt2_Rhasspy clientOrder RHASSPY MQTT_GENERIC_BRIDGE MQTT2_DEVICE
attr mqtt2_Rhasspy subscriptions hermes/intent/+ hermes/dialogueManager/sessionStarted hermes/dialogueManager/sessionEnded
define Rhasspy RHASSPY
save



Ergebnis mit Modul 0.4.12:
Internals:
   CFGFN     
   FUUID      60a50bf9-f33f-a4a6-7a4a-342599eafb9e3309
   IODev      mqtt2_Rhasspy
   LANGUAGE   de
   MODULE_VERSION 0.4.12
   NAME       Rhasspy
   NR         42
   STATE      ???
   TYPE       RHASSPY
   baseUrl    http://127.0.0.1:12101
   defaultRoom default
   devspec    room=Rhasspy
   encoding   UTF-8
   fhemId     fhem
   prefix     rhasspy
   useGenericAttrs 1
   READINGS:
     2021-05-19 15:00:41   IODev           mqtt2_Rhasspy
   helper:
     lng:
       responses:
         DefaultCancelConfirmation Thanks aborted
...
         unitSeconds:
           0          seconds
           1          one second
Attributes:


Ergebnis mit Modul 0.4.14:
Internals:
   CFGFN     
   FUUID      60a510a6-f33f-a4a6-7983-6c267ef3f15a44b3
   IODev      mqtt2_Rhasspy
   LANGUAGE   de
   MODULE_VERSION 0.4.14
   NAME       Rhasspy
   NR         24
   STATE      ???
   TYPE       RHASSPY
   baseUrl    http://127.0.0.1:12101
   defaultRoom default
   devspec    room=Rhasspy
   encoding   utf8
   fhemId     fhem
   prefix     rhasspy
   useGenericAttrs 1
   READINGS:
     2021-05-19 15:20:38   IODev           mqtt2_Rhasspy
   helper:
     lng:
       responses:
         DefaultCancelConfirmation Thanks aborted
         ...
         unitSeconds:
           0          seconds
           1          one second
Attributes:


Keine der beiden Modulversionen legt bei mir automatisch Attribute an. Irgendetwas scheint unsere Systeme zu unterscheiden. Ich würde gerne verstehen, was den Unterschied ausmacht, und ob mir das - bei anderen Modulen, in vergleichbare Situationen - erneut um die Ohren fliegt  :-\. Ich muss noch für die Sommerferien ein DIY-Bewässerungssystem für unsere Kübelpflanzen bauen... das wollte ich eigentlich per MQTT steuern.

DrBasch

Zitat von: Beta-User am 19 Mai 2021, 13:06:43
Dann mal viel Spaß - und ruhig weiter Fragen stellen, wenn was unklar ist bzw. (v.a.) die cref verbessert werden kann!


Das Angebot nutze ich gleich nochmal schamlos aus... ;D

1. Beim Anlegen des RHASSPY-Devices hab ich mich das ein oder andere mal vertippt. Ich schrieb z.B.
"define Rhasspy RHASSPY ... devspe=genericDeviceType=.+" 
anstatt
"define Rhasspy RHASSPY ...devspec=...".

Dann hat das Modul -nachvollziehbar- den devspec-default "room=Rhasspy" übernommen. Das fiel mir dann aber erst sehr viel später auf.
Ein anders Mal schrieb ich "baseURL" anstatt "baseUrl". Der Fehler hat sich wiederum sehr schnell bemerkbar gemacht.

Syntaxfehler werden somit zwar irgendwie abgefangen, aber dem Anwender nicht aktiv rückgemeldet, z.B. durch einen Log-Eintrag "define <Devicename> with an unknown argument 'devspe=genericDeviceType=.+', please check Internals manually").
Ich habe keine Ahnung, wie aufwänding es wäre eine Syntaxprüfung zu implementieren - mit parseParameters hab ich mich noch nicht auseinandergesetzt. Eine solche Erweiterung der Rhasspy_DefFn wäre in meinen Augen nett, ist aber definitiv nichts was als zwingend oder dringlich priorisiert werden müsste... eher etwas für langweilige, verregnete Tage mit miesem TV-Programm wenn die Frau/Freundin/Familie die Schwiegereltern besucht  ;)

2. Ich habe bis jetzt nur ein Dummy-Device angelegt, dass sprachgesteuert on/off geschaltet werden sollte. 
Nach einem "set Rhasspy update devicemap/slots/all" finde ich im Rhasspy-Webinterface slots wie z.B. "de.fhem.Device", "de.fhem.Room", "de.fhem.AllKeywords" mit den jeweils korrekten values ("lampe", "wohnzimmer").
Jedesmal wurde auch ein Sentence-File "intents/de.fhem.Shortcuts.ini" mit dem (leeren) intent "[de.fhem:Shortcuts]" angelegt.

Was ich vermisst habe, war ein automatisches Anlegen von z.B. "[de.fhem:SetOnOff]", insbes. dann, wenn ich mit attr rhasspyMapping SetOnOff:cmdOn=on,cmdOff=off" die beabsichtigten intentions vorgegeben habe.
Bei meinem allerersten Einrichtungsversuch war mir nämlich nicht klar, wie und wo ich die sentences eingeben muß ("sentence.ini"? "intents/de.fhem.Shortcuts.ini"? Ganz wo anders?). Nachdem ich dann auf Youtube den FHEM-Monatsrückblick geschaut habe und einen kurzen Blick auf Eure Rhasspy Konfiguration erhaschen konnte bin ich nachfolgend dazu übergegangen für jede intention eine eigene .ini anzulegen. Ist dieses Vorgehen okay, oder kann/sollte man besser alle intentions einfach in die sentence.ini kloppen?

3. Das gettingstarted von cb2sela https://github.com/cb2sela/fhem-rhasspy-gettingstarted ist mE in Bezug auf den derzeitigen Enwicklungsstand eures Moduls outdated.

ZitatIn FHEM folgendes angelegt:

define RhasspyMQTT MQTT [ip_des_rhasspy]:12183
define Rhasspy RHASSPY RhasspyMQTT Wohnzimmer
attr RhasspyMQTT room Rhasspy
attr RhasspyMQTT rhasspyRoom Wohnzimmer
attr Rhasspy room Rhasspy
attr Rhasspy rhasspyRoom Wohnzimmer
Funktioniert das Rhasspy-Modul denn noch mit MQTT? Ich hatte es so verstanden, dass man MQTT2_CLIENT oder MQTT2_SERVER benötigt.

last but not least... okay, jetzt wird es kleinkariert...:
4. Im Github readme wird unter "Attributes (ATTR)" noch (das alte) "configFile" anstelle von "languageFile" erklärt.


Bitte kriegt nicht den Eindruck ich würde nur meckern wollen...
Ich bin wirklich, wirklich dankbar für das Modul, euer Engagement und eure Bereitschaft auf die Anwender einzugehen.

Beta-User

#599
Anbei dann erst mal eine Version, die die uninitialized-Warnung bei nicht gesetztem IODev-Attribut vermeidet und dann auf Reading/Internal zurückgreift - samt entsprechender Anpassung der cref. Bin auch noch nicht ganz durch, aber mAn. wird das Attribut künftig nicht mehr automatisch gesetzt.

OT-Anmerkung dazu: Das ist vermutlich in allen den Fällen kein Problem, in denen es sowieso nur eine lose Verbindung zwischen IO und Information gibt (wie bei den meisten Funklösungen, bei denen dann fhem.pl Duplikate vorrab aussortiert).
In allen Fällen, in denen es sein kann, dass - vermeintlich - identische Information über unterschiedliche IO's reinkommen kann (vornehmlich MQTT, aber auch MySensors!), muss die Koppelung zwischen IO und Client-Modul im zweistufigen Modulkonzept aber "gehärtet" werden, was bei MySensors z.B. schon länger dadurch erfolgt, dass da das Attribut durch das Modul gesetzt wird, statt auf AssignIOPort zu vertrauen...

Anders gesagt: Wenn (und solange) man z.B. auch bei MQTT_GENERIC_BRIDGE das Attribut gesetzt hat, ist alles fein...

Für die Zukunft wird es vermutlich auch dort (und bei MQTT2_DEVICE?) eine Ergänzung brauchen, die das klarstellt.
[/OT]

Zitat von: DrBasch am 20 Mai 2021, 02:11:10
Das Angebot nutze ich gleich nochmal schamlos aus... ;D
Gerne!

Ad 1.: Guter Vorschlag, hab's auf die ToDo genommen. Vermutlich wird sich das aber "nur" darauf beschränken müssen, das auf korrekte Schreibweise der "Schlüsselworte" (und evtl. die Zahl der unbenannten Parameter) zu checken.
(OT: das ist nicht wirklich ein originäres parseParams-Problem, das hilft nur, die Optionen selektiv setzen zu können [/OT]).

Ad. 2.
a) Weiß nicht, ob wir den "automatisiert erstellten" OnOff-Slot (via rhasspy-de.cfg) bereits implementiert haben bzw. das schon im svn ist. Machbar wäre es jedenfalls dafür zu sorgen, dass erst mal jeder ein relativ schnelles "hello world" zustande bringen kann, ohne sich (bis dahin)  intensiver mit der Rhasspy-Seite auseinandersetzen zu müssen.
b) das mit den leeren Shortcuts ist auf der ToDo-Liste, sollte sich ohne größere Aufwände vermeiden lassen.
c) Für jeden Intent eine eigene ini anzulegen erscheint mir sinnvoll. Ist zwar im ersten Moment unübersichtlicher, aber bei Überarbeitungen deutlich weniger fehleranfällig.

ad 3 und 4.:
Die aktuellste Doku ist die cref, da steht eindeutig: MQTT2-IO, empfohlen: M2C, alle andere Doku in den Untiefen des INet ist veraltet ::) .

Das git-HowTo war - soweit ich das beurteilen kann - eine (gute!) Art Notlösung, weil es keinen anderen praxistauglichen Ort gab. Es hat sich nur "leider" sehr viel geändert, auch, was die Frage der Herangehensweise bei der Einrichtung angeht usw.. Von daher wäre es m.E. an der Zeit,
a) die cref auf "Tauglichkeit" (im Sinne einer knappen manpage) zu checken, ob da alles wesentliche drin steht, was man braucht, und
b) einen (deutschen) Guide zu erstellen, der das wesentliche enthält. Die md im (fhem-) git deckt vieles ab, aber noch nicht alles aus der aktuellen dev-Version (und ist auch englisch).

Meine persönliche Vorstellung wäre:
- Ziel für den Guide wäre das FHEM-Wiki;
(- parallel cref im Auge behalten/überarbeiten, wo erforderlich)
- Basis die aktuelle dev-version
- Startpunkt für die Einrichtung von Geräten wäre - soweit das möglich ist - jeweils genericDeviceType zu setzen.

Unsere Probleme dabei:
- drhirn und andere, die die Vorversionen schon im Einsatz hatten, haben ihre Systeme "nach guter alter Väter Sitte" konfiguriert und "fremdeln" (noch) etwas mit dem gDT-Ansatz (was auch völlig ok ist, denn wir hatten ja auf (weitgehende) Kompabilität geachtet). Da besteht jetzt aber keine Veranlassung, am laufenden System was zu ändern, daher ist die Testintensität nicht wirklich hoch (genauer gesagt: mir liegt außer den eigenen Erfahrungen praktisch keine Rückmeldung dazu vor);
- "wir" sind etwas betriebsblind, was es immer schwierig macht, einen "einsteigerfreundlichen" Wiki-Artikel zu verfassen

Zitat
Bitte kriegt nicht den Eindruck ich würde nur meckern wollen...
Bei mir ist das als konstruktive Kritik angekommen. Du brauchst dich für Fragen nicht zu rechtfertigen, _noch_ ist die Doku nicht so, dass man dir ein rtfm um die Ohren hauen dürfte ;D .

Meine Bitte bzw. mein Vorschlag:
Wir brauchen (wieder) jemanden wie cb2sela, der hilft, eine passende (de-) Doku zu verfassen und die verbleibenden Lücken in der Doku, in der cref, in der rhasspy-de.cfg aufzuspüren, (uninitialized-warnings zu jagen) und ggf. mal ausführlichere Rückmeldung zum "gDT-Way" gibt.

Evtl. wäre es auch "Zeit", den "alten" Thread zu schließen (ähnlich, wie das mit den verschiedenen Versionen bei AutoShuttersControl der Fall war), um zu zeigen, dass der korrekte Startpunkt nicht mehr der 1. Threadbeitrag ist?

Wenn die Doku (halbwegs) fertig ist und die aktuelle dev-Version keine größeren Schwächen mehr zeitigt, wäre ggf. dann der Zeitpunkt gekommen, das ganze dann auch "scharf" zu schalten, also das Modul in den regulären update-Zyklus aufzunehmen (wir sollten aber ggf. wissen, wer von den 10 (in statistics) "gemeldeten" Installationen schon auf dem MQTT2_CLIENT-IO ist, damit wir nicht versehentlich/unangekündigt jemanden "abschießen").

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