Modulentwicklung für Rhasspy Sprachassistent

[Beta-User]

Hinweis: Github hat einen kleinen Fehler, ")" statt "}", hinter on.

Generell stimme ich dir zu, dass 3 Dokus nicht optimal sind. Daher habe ich bisher den Wiki-Teil auch auf das "Starten mit genericDeviceType" beschränkt. MAn. brauchte es sowas, mir ist aber im Prinzip auch egal, wo es steht. Man könnte die Kurzformel auch in die commandref aufnehmen. Das Problem sind m.E. allerdings Beispielsätze, die sind immer sprachspezifisch, was eben nach einer (kurzen) de-Doku ruft...
Vielleicht sollten wir mal telefonieren (oder wie man das neuerdings halt so macht), wie wir insgesamt weiter vorgehen wollen?

Anbei auch noch ein kleines svg. Noch nicht 100% hübsch, aber vielleicht mag es ja jemand mit einem hübscheren Rahmen versehen...

[drhirn]

Das Problem sind m.E. allerdings Beispielsätze, die sind immer sprachspezifisch, was eben nach einer (kurzen) de-Doku ruft...

Ja. Hab eh immer gesagt, Technische-Doku bleibt, wo sie ist (CRef, GitHub). Und Beispiele sollen ins Wiki
Muss aber auch gestehen, GitHub hängt schwer hinten nach. Was einfach daran liegt, dass ich das meiste, was in letzter Zeit von euch dazu gebaut wurde, mangels Anwendungszweck nicht so richtig testen kann.

Vielleicht sollten wir mal telefonieren (oder wie man das neuerdings halt so macht), wie wir insgesamt weiter vorgehen wollen?

Im Sinne der Transparenz wäre ich fast dafür, dass wir das im Forum irgendwo abhandeln. Damit Interessierte auch daran teilhaben können.

Anbei auch noch ein kleines svg. Noch nicht 100% hübsch, aber vielleicht mag es ja jemand mit einem hübscheren Rahmen versehen...

Für's Wiki?

[Beta-User]

Für's Wiki?

Na ja, ich nutze das in FHEMWEB, wäre also mittelfristig eher was für den "icons"-Thread bzw. "contrib"-Material?

Ja. Hab eh immer gesagt, Technische-Doku bleibt, wo sie ist (CRef, GitHub). Und Beispiele sollen ins Wiki
Muss aber auch gestehen, GitHub hängt schwer hinten nach. Was einfach daran liegt, dass ich das meiste, was in letzter Zeit von euch dazu gebaut wurde, mangels Anwendungszweck nicht so richtig testen kann.

...mein erster Blick ging auch nach github, und da war dann auch mein Reflex: Ups, da wäre "action required", und das ist in der Tat eher "Beispiel"...

Die meisten neuen Sachen sind im Prinzip zumindest von mir angetestet, manches ist noch nicht ausgereift (text2rhasspy)

Im Sinne der Transparenz wäre ich fast dafür, dass wir das im Forum irgendwo abhandeln. Damit Interessierte auch daran teilhaben können.

Kein Problem. Ich wollte nur anfragen, ob zum einen Interesse besteht, dass ich die Co-Maintainerschaft offiziell übernehme, und zum anderen, was du mit Rudi besprochen hattest betr. der Frage, contrib vs. FHEM?

Zum ersten Punkt: War ja lange nicht sicher, ob ich bei Rhasspy bleibe, aber im Moment stellt sich die Frage nicht mehr . Jetzt hat sich gezeigt, dass Bedarf im Feinschliff für die besteht, die die Entwicklungsdiskussion nicht aktiv begleitet hatten. Dir daher die Verantwortung auf's Auge zu drücken für features, die du nicht (aktiv) nutzt bzw. nicht brauchst, ist daher diskussionswürdig ...

[JensS]

Wer eine vernünftige Offline-Spracherkennung/-steuerung implementieren möchte, kommt um Rhasspy nicht herum.
Bisher gab es keinen Einstieg für Suchende; Rhasspy wurde eher durch Zufall gefunden. Dass ist jetzt mit der Verlinkung im WIKI korrigieret. Danke dafür!
Selbst nutze ich die automatische Generierung per gDT nicht, da meine paar Devices per Hand definiert wurden.
Zum Einstieg in Rhasspy wäre ein Beispiel mit einem M2C-Device, einem Rhasspy-Device und einem Dummy-setOnOff ausreichend.
Alles weitere würde zu Beginn mehr Fragen aufwerfen, als Verständnis zum Konstrukt von Rhasspy zu vermitteln.

Gruß Jens

[drhirn]

Ich wollte nur anfragen, ob zum einen Interesse besteht, dass ich die Co-Maintainerschaft offiziell übernehme, und zum anderen, was du mit Rudi besprochen hattest betr. der Frage, contrib vs. FHEM?

Auf jeden Fall! Wenn wir uns ehrlich sind, bist du der Maintainer, nicht ich. Meine letzte Zeile Code ist schon ziemlich lange her
Mit Rudi habe ich eigentlich nur bzgl. contrib gesprochen. Ich würd's dabei belassen, bis die Userschaft wächst. Aber ich bin da meinungselastisch.

Dir daher die Verantwortung auf's Auge zu drücken für features, die du nicht (aktiv) nutzt bzw. nicht brauchst, ist daher diskussionswürdig

Fair

[drhirn]

Zum Einstieg in Rhasspy wäre ein Beispiel mit einem M2C-Device, einem Rhasspy-Device und einem Dummy-setOnOff ausreichend.
Alles weitere würde zu Beginn mehr Fragen aufwerfen, als Verständnis zum Konstrukt von Rhasspy zu vermitteln.

Wiederum: Ich sehe das wertfrei. Das ist nicht "mein" Modul, es ist nicht "meine" Doku. Alles, was Rhasspy und das Modul weiterbringt, freut mich. Insofern bin ich begeistert über jeden Input. Ich ermutige euch auch, selbst Hand anzulegen. Sei das Modul oder Doku. Sei das mit einem Patch für SVN oder einen Pull Request für GitHub. Ich hab das ganze nur gestartet, aber ich bin nicht beleidigt, wenn das jemand besser macht. Bin auch nicht der Meinung, ich hab die Weisheit mit Löffeln gefressen. In Wahrheit habt ihr mich alle wissenstechnisch schon lange überholt .

[JensS]

Ich hab das ganze nur gestartet...

Dafür ein dickes Lob und einen großen Dank!!!
Ich glaube es an einer anderen Stelle schon mal geschrieben zu haben - ohne diesen Start wäre das Snpis-Modul von Thyraz gestorben und keine vernünftige Alternative vorhanden.

Gruß Jens

[laberlaib]

Sagt mal, woher weiß ich den, welche Befehle so ein genericDeviceTyp unterstützt?
Ich hab hier eine Zigbee-Birne die ich mir mla mit einem Template folgendermaßen eingerichtet habe:

Code Auswählen Erweitern

defmod light_Stehlampe MQTT2_DEVICE zigbee_0xec1bbdfffe181343
attr light_Stehlampe IODev MQTT2_FHEM_Server
attr light_Stehlampe comment Licht nicht schlecht: F0F6FE\
FFC248
attr light_Stehlampe devStateIcon {zigbee2mqtt_devStateIcon255($name)}
attr light_Stehlampe genericDeviceType light
attr light_Stehlampe group dev_light
attr light_Stehlampe icon hue_filled_white_and_color_e27_b22
attr light_Stehlampe imageLink /fhem/deviceimages/mqtt2/LED1624G9.jpg
attr light_Stehlampe model zigbee2mqtt_light_rgb_hex
attr light_Stehlampe readingList zigbee2mqtt/0xec1bbdfffe181343:.* { json2nameValue($EVENT) }
attr light_Stehlampe rhasspy1Name Stehlampe
attr light_Stehlampe rhasspy1Room wohnzimmer
attr light_Stehlampe rhasspyEsName lampara
attr light_Stehlampe rhasspyEsRoom salon
attr light_Stehlampe room LIGHTER,Rhasspy
attr light_Stehlampe setList on:noArg zigbee2mqtt/0xec1bbdfffe181343/set {"state":"ON"}\
  off:noArg zigbee2mqtt/0xec1bbdfffe181343/set {"state":"OFF"}\
  brightness:colorpicker,BRI,0,5,255 zigbee2mqtt/0xec1bbdfffe181343/set {"state":"on","$EVTPART0":"$EVTPART1"}\
  hex:colorpicker,HEX,0,15,255 zigbee2mqtt/0xec1bbdfffe181343/set {"color":{"$EVTPART0":"#$EVTPART1"}}
attr light_Stehlampe stateFormat {lc ReadingsVal($name,"state",0)}
attr light_Stehlampe userReadings hex:color_y.* {Color::xyY2hex(ReadingsVal($name,"color_x",0),ReadingsVal($name,"color_y",0),ReadingsVal($name,"brightness",254))}
attr light_Stehlampe webCmd toggle:on:off:brightness:hex

Reicht dazu das gDT "light" aus?
Und dann würde ja weiter gehen mit blinds etc..

Zur Doku:
Ich finde, dass Github und Wiki im Grunde das gleiche sein könnten. Und das Wiki können halt alle editieren, bei Github tu zumindest ich mich schwerer.
Das Modul ist so speziell, dass es ja von niemandem isoliert ohne FHEM betrieben werden kann und daher auch keine für sich stehende Doku auf Github braucht.
Und die Commandref ist nochmal weniger von Helfern zu pflegen, daher würde ich hier nur kurz und einsprachig (Englisch, wegen der FHEM-Richtlinien) erläutern, um was es geht.

[Beta-User]

Auf jeden Fall!

OK, dann schaue ich mal, dass ich 0.5.03 ins svn/contrib schubse...

Und ohne speziell die Initiative von drhirn und euren support isgesamt (und manche kritische Rückfrage) wären wir ganz sicher nicht dahin gekommen, dass ca. 80% des Codes überarbeitet wurden und der ganz überwiegende Teil automatisch geht.

Was die gDT angeht, dürfte das "hex"-light zu 2/3 funktionieren, nämlich on/off und brightness. hex geht vermutlich nicht, wobei ich mich frage, ob man das nicht (im M2D) nach "rgb" ändern könnte, dann wären es 100%. Was geht, sieht man im RHASSPY-list . Bräuchte aber Info, was im Reading hex für Werte stehen (ob mit oder ohne #), sonst muss ich Code schauen...

[drhirn]

OK, dann schaue ich mal, dass ich 0.5.03 ins svn/contrib schubse...

Hab ich am Morgen schon gemacht

[Prof. Dr. Peter Henning]

Bin hier ab sofort mit dabei.

LG

pah

[Beta-User]

Bin hier ab sofort mit dabei.

Dann mal willkommen in unserer trauten Runde hier!

[drhirn]

Sagt mal, woher weiß ich den, welche Befehle so ein genericDeviceTyp unterstützt?

Das ist derzeit leider nur aus dem Code ersichtlich (sub _analyze_genDevType).
Für "light" ist das SetOnOff, GetOnOff und SetNumeric. Wobei bei letzterem brightness gesetzt wird. Und das ist - je nach Gerät - dim, pct oder brightness.

[drhirn]

Anbei auch noch ein kleines svg. Noch nicht 100% hübsch, aber vielleicht mag es ja jemand mit einem hübscheren Rahmen versehen...

Mir gefällt's überhaupt ohne Rahmen am besten: https://github.com/fhem/fhem-rhasspy/blob/main/extras/rhasspy.svg

[Beta-User]

Das ist derzeit leider nur aus dem Code ersichtlich (sub _analyze_genDevType).
Für "light" ist das SetOnOff, GetOnOff und SetNumeric. Wobei bei letzterem brightness gesetzt wird. Und das ist - je nach Gerät - dim, pct oder brightness.

Es fehlt: SetColor. Und ein Blick in den Code zeigt: hex wird automatisch als rgb behandelt. Das müßte mAn. daher also bei diesem Gerät direkt mit dem gDT light klappen.

Grundsätzlich zu dem Thema: einfach den (vermutlich) passenden gDT setzen und dann schauen, was der analyzer daraus macht => RHASSPY-list. Wenn es nicht gefällt oder zu 100% paßt, hat man schon mal eine Grundlage, die man dann "nur noch" anpassen muss...

Und die Commandref ist nochmal weniger von Helfern zu pflegen, daher würde ich hier nur kurz und einsprachig (Englisch, wegen der FHEM-Richtlinien) erläutern, um was es geht.

Prinzipiell fände ich es gut, wenn die (engl.) commandref alles enthalten würde, was man braucht. Dazu fehlen mind. noch ein paar Beispielsätze, und evtl. auch sowas wie eine Kurzfassung des Quick-Starts. Es ist aber völlig ok, wenn jemand dazu (und nicht nur zu den genannten Punkten) content-Vorschläge liefert oder bessere Formulierungen etc. vorschlägt usw.. Ich habe das bisher eher als schnellen "write-up" genutzt, in dem dann eben auch neue features etc. direkt dokumentiert wurden. Da besteht sicher noch Verbesserungspotential .

Mir gefällt's überhaupt ohne Rahmen am besten: https://github.com/fhem/fhem-rhasspy/blob/main/extras/rhasspy.svg

Finde ich gut. Wie wäre es mit einem Eincheck-Vorschlag an wuppi68?