Modulentwicklung für Rhasspy Sprachassistent

[Beta-User]

...ach so, was ich eigentlich auch noch loswerden wollte:
Mit den letzten beiden Versionen funktionierte das Schalten von HUEDevice-Szenen .

Anmerkungen/eventuelle Einschränkungen:
- getestet mit deconz als HUEBridge
- bisher ohne "id"-Kenner, also "nur" Klartext-Namen, aber
- Szenennamen mit und ohne Leerzeichen werden geschaltet.

Jetzt werde ich die kommenden Tage erst mal versuchen, das Gruppen-Thema zu fixen, (=> wer zweckdienliche Hinweise einschließlich ähnlicher Probleme (!) hat: bitte melden (rhasspy-list (auszugsweise) wäre hilfreich) !), und mir dann überlegen, wo/auf welcher Ebene ich eigentlich welche Art der Gruppenschaltung sinnvollerweise realisiere (einschl. der Szenen-Optionen aus deconz und lightScene...).

[drhirn]

...ach so, was ich eigentlich auch noch loswerden wollte:
Mit den letzten beiden Versionen funktionierte das Schalten von HUEDevice-Szenen .

Ähm, wie? Du meinst, RHASSPY kann's. Aber HUEDevice.pm nicht?

[Beta-User]

Ähm, wie? Du meinst, RHASSPY kann's. Aber HUEDevice.pm nicht?

Nö, ich meine: Rhasspy erkennt die Szene, RHASSPY setzt das als Einzelbefehl um, HUEDevice akzeptiert den Befehl und haut das über das passende IO raus, und am Ende wird meine Lampe(ngruppe) auch entsprechend in der Realität umgeschaltet (konkret: Lichtfarbe und Dimmung geändert).

Kurz: works as intented ...

[drhirn]

Versteh ich nicht. Wie soll das gehen, wenn's das HUEDevice nicht kann?

Code Auswählen Erweitern


2021.06.02 09:40:22 5: RHASSPY: [Rhasspy] Parse (IO: rhasspyMQTT2): Msg: hermes/intent/de.fhem_SetScene => {"input": "stelle die stehlampe auf die Szene id=gbca4wF9Vni8oSb", "intent": {"intentName": "de.fhem:SetScene", "confidenceScore": 1.0}, "siteId": "default", "id": "8871b861-236c-4bc2-82f9-cc67ea6be059", "slots": [{"entity": "de.fhem.Device-scene", "value": {"kind": "Unknown", "value": "stehlampe"}, "slotName": "Device", "rawValue": "stehlampe", "confidence": 1.0, "range": {"start": 11, "end": 20, "rawStart": 11, "rawEnd": 20}}, {"entity": "Scene", "value": {"kind": "Unknown", "value": "id=gbca4wF9Vni8oSb"}, "slotName": "Scene", "rawValue": "entspannen", "confidence": 1.0, "range": {"start": 35, "end": 53, "rawStart": 35, "rawEnd": 45}}], "sessionId": "8871b861-236c-4bc2-82f9-cc67ea6be059", "customData": null, "asrTokens": [[{"value": "stelle", "confidence": 1.0, "rangeStart": 0, "rangeEnd": 6, "time": null}, {"value": "die", "confidence": 1.0, "rangeStart": 7, "rangeEnd": 10, "time": null}, {"value": "stehlampe", "confidence": 1.0, "rangeStart": 11, "rangeEnd": 20, "time": null}, {"value": "auf", "confidence": 1.0, "rangeStart": 21, "rangeEnd": 24, "time": null}, {"value": "die", "confidence": 1.0, "rangeStart": 25, "rangeEnd": 28, "time": null}, {"value": "Szene", "confidence": 1.0, "rangeStart": 29, "rangeEnd": 34, "time": null}, {"value": "id=gbca4wF9Vni8oSb", "confidence": 1.0, "rangeStart": 35, "rangeEnd": 53, "time": null}]], "asrConfidence": null, "rawInput": "stelle die stehlampe auf die szene entspannen", "wakewordId": null, "lang": null}
2021.06.02 09:40:22 5: Parsed value: stelle die stehlampe auf die szene entspannen for key: rawInput
2021.06.02 09:40:22 5: Parsed value: SetScene for key: intent
2021.06.02 09:40:22 5: Parsed value: id=gbca4wF9Vni8oSb for key: Scene
2021.06.02 09:40:22 5: Parsed value: stelle die stehlampe auf die Szene id=gbca4wF9Vni8oSb for key: input
2021.06.02 09:40:22 5: Parsed value: default for key: siteId
2021.06.02 09:40:22 5: Parsed value: 8871b861-236c-4bc2-82f9-cc67ea6be059 for key: sessionId
2021.06.02 09:40:22 5: Parsed value: stehlampe for key: Device
2021.06.02 09:40:22 5: Parsed value: 1 for key: probability
2021.06.02 09:40:22 5: handleIntentSetScene called
2021.06.02 09:40:22 5: default room used
2021.06.02 09:40:22 5: Device selected (by hash, with room and name): HUEDevice6
2021.06.02 09:40:22 5: analyzeAndRunCmd called with command: scene [id=gbca4wF9Vni8oSb]
2021.06.02 09:40:22 5: HUEDevice6 scene [id=gbca4wF9Vni8oSb] is a normal command
2021.06.02 09:40:22 1: default/icoEverything.png
2021.06.02 09:40:22 5: Running command [scene [id=gbca4wF9Vni8oSb]] on device [HUEDevice6]
2021.06.02 09:40:22 5: Response is: Gerne!


Und was macht das "default/icoEverything.png" da? Das ist für mich immer ein Zeichen, dass etwas nicht funktioniert

[Beta-User]

Versteh ich nicht. Wie soll das gehen, wenn's das HUEDevice nicht kann?

Na ja, _mein_ HUEDevice kann das (wie bereits angemerkt: getestet aber bisher ohne, dass irgendwo das "magische" (eckige) id=... aufgetaucht wäre, muss mal schauen, ob/wie man das @deconz überhaupt "generieren" kann). Nach dem Code von HUEBridge zu urteilen, sollten eigentlich sowohl deconz wie auch die holländische Bridge "id=..." verarbeiten können. Wenn das nicht der Fall ist => Problem bitte bei HUEDevice/justme1968 einkippen, und dann eben "notfalls" den workaround mit "all=none" nutzen, wenn's nur Probleme macht...

(Wie gestern geschrieben: wenn "id=..." (in eckig) angegeben wird, scheint _nur noch das_ durchzuschlagen, der Rest ist imo irrelevant. Kann natürlich sein, dass ich was übersehe, aber der "volle" Kommand hat ja bei dir auch nicht funktioniert; da aber gefühlt >30% der HUEBridge-User auch deconz einsetzen, macht es m.E. keinen Sinn, über eine generelle Deaktivierung zu sprechen, das Thema ist anderswo zu lösen).

Code Auswählen Erweitern

Und was macht das "default/icoEverything.png" da? Das ist für mich immer ein Zeichen, dass etwas nicht funktioniertDas kann ich nicht zuordnen, aber das klingt nach einer "eigentlich" anderen Geschichte...

[drhirn]

Na ja, _mein_ HUEDevice kann das

Ahsooo

[Beta-User]

Ahsooo

Zur Klarstelung: Die Moduldatei ist aber nichts spezielles, sondern einfach nur die aktuelle svn-Fassung (dto. für HUEBridge):

Code Auswählen Erweitern

31_HUEDevice.pm 23912 2021-03-08 10:21:02Z justme1968

[drhirn]

Mein FHEM ist aktuellst, daran liegt's nicht. Mir ist das Thema aber auch nicht wichtig. Wozu soll ich die Szene einer Lampe schalten? Und die HUE-Szenen verwende ich sowieso nicht.

Was anderes: Ich hab das README letzte Woche aktualisiert. Könntest du bei Gelegenheit bitte mal kurz drüber sehen, ob ich etwas vergessen habe? Jetzt mal abgesehen von den paar Intents, die noch leer sind?

[Beta-User]

Mein FHEM ist aktuellst, daran liegt's nicht. Mir ist das Thema aber auch nicht wichtig. Wozu soll ich die Szene einer Lampe schalten? Und die HUE-Szenen verwende ich sowieso nicht.

Dann scheint es wirklich an der (originalen) HueBridge zu liegen, komisch eigentlich; ich gehe davon aus, dass justme1968 genau die (auch) nutzt...

Bisher hatte ich auch nicht das große Bedürfnis, mich mit den HUE-Szenen zu beschäftigen , aber für RHASSPY war's jetzt halt "notwendig" - und jetzt fand ich das sogar eine ziemlich coole Option, auch Gruppenschaltungen zu realisieren. Zum Hintergrund: Ich habe einen "ZigBee-Raum" (also einen physischen Bereich, in dem für Beleuchtung fast überall ZigBee-Zeug installiert ist), und eigentlich ist für bestimmte Gelegenheiten das Hue-feature für bestimmte Modi ideal, weil es "hardwarenah" ausgeführt wird...

Was anderes: Ich hab das README letzte Woche aktualisiert. Könntest du bei Gelegenheit bitte mal kurz drüber sehen, ob ich etwas vergessen habe? Jetzt mal abgesehen von den paar Intents, die noch leer sind?

Mache ich; auf die Schnelle sind mir schon ein paar Kleinigkeiten aufgefallen.

Btw.: Soll "GetWeekday" eigentlich weiter so heißen?

[drhirn]

Btw.: Soll "GetWeekday" eigentlich weiter so heißen?

Stimmt. Ist jetzt eigentlich blöd. Können wir gerne in GetDate umbenennen.

[Beta-User]

Stimmt. Ist jetzt eigentlich blöd. Können wir gerne in GetDate umbenennen.

here you are...

Habe vermutlich auch den Schalter gefunden, der das Leerzeichen in meiner Gruppenbenennung nicht mochte. Ist geändert, und ich hoffe auch, dass das nicht noch mehr Stellen betrifft (potentiell: Raumnamen mit Leerzeichen).

[JensS]

Hi, ich hab mal die aktuelle contrib probiert und gleich eine Frage. Was denkt ihr über confirm in den vorhandenen Set-mappings (z.B. SetOnOff und SetNumeric) - ist das machbar?
Gruß Jens

[Beta-User]

Hi, ich hab mal die aktuelle contrib probiert und gleich eine Frage. Was denkt ihr über confirm in den vorhandenen Set-mappings (z.B. SetOnOff und SetNumeric) - ist das machbar?
Gruß Jens

Generelle Bestätigungsmöglichkeiten sind derzeit noch nicht implementiert, das Interesse war bisher nicht übermäßig groß. (bei shortcuts geht das aber!)
Sowas (vollends) zu implementieren dürfte nicht allzu schwierig sein, ist aber Aufwand, auch beim Testen. Falls größeres Interesse besteht, würde ich das mal auf die Agenda nehmen... (Mein persönliches Problem, das mit in diese Richtung geschubst hatte, ist jetzt eher dadurch gelöst, dass mehr Slots zur Verfügung stehen, so dass Rhasspy "treffsicherer" ist).

Nehme dich mal auf die Liste der potentiellen Befürworter, bitte aber trotzdem darum, erst mal zu checken, ob ggf. auch die engeren Slots den größten Teil des Weges nicht abdecken könnten.

Was die Modulversion angeht: am besten die aktuelle aus meinem letzten Post nehmen, da klappen (@drhirn: getestet) jetzt auch "Leerzeichen-Gruppen" (und vermutlich auch L-Räume) wieder. FHEM vorher updaten (wg. Register.pm).


@drhirn betr. Doku: den pull-request hast du vermutlich gesehen.
Bin aber zunehmend unsicher, ob wir nicht doppelt Arbeit haben und das nicht (weitgehend) besser in die cref gehören würde. (Da wäre ggf. nochmal zu checken, ob nicht Teile der Überarbeitung dahin übernommen werden können).

Jetzt muss ich aber erst selbst mal wieder ein paar gDT-Attribute verteilen . Gefällt mir ausgesprochen gut, das Tool!

[drhirn]

Hinweis: Der Intent GetWeekday wurde umbenannt in GetDate

Was die Modulversion angeht: am besten die aktuelle aus meinem letzten Post nehmen, da klappen (@drhirn: getestet) jetzt auch "Leerzeichen-Gruppen" (und vermutlich auch L-Räume) wieder. FHEM vorher updaten (wg. Register.pm).

Die Version ist jetzt im SVN. Und ich habe einen Merge von dev auf main gemacht. Es ist somit alles aktuell.

@drhirn betr. Doku: den pull-request hast du vermutlich gesehen.

Ja. Großen Dank an dich und christoph-morrison!

Bin aber zunehmend unsicher, ob wir nicht doppelt Arbeit haben und das nicht (weitgehend) besser in die cref gehören würde.

Wie du weißt, war mein ursprünglicher Plan, die CRef kurz und knapp zu halten. Und Details im Readme unterzubringen. Jetzt ist halt das Modul schon so mächtig, dass "kurz und knapp" doch relativ lang ist. Ja, ist doppelte Arbeit. Ich weiß aber momentan nicht, wie wir das sonst lösen könnten. Hab aber im FHEM-GitHub mal eine Möglichkeit gesehen, wie man die CRef automatisch erstellen lassen kann .

Jetzt muss ich aber erst selbst mal wieder ein paar gDT-Attribute verteilen . Gefällt mir ausgesprochen gut, das Tool!

Ja! Hast du gut gemacht! Und ich finde das super, dass ich dich so angefixt habe

[Beta-User]

Die Version ist jetzt im SVN. Und ich habe einen Merge von dev auf main gemacht.

Thx (auch an Christoph für den review!). Imo sind wir mit V. 0.4.x jetzt ziemlich "durch" (s.u.).
Was "excerpt" angeht: das war wirklich im Sinne von "auszugsweise" gemeint, es gibt ja noch ein paar mehr als die auf der Liste, oder?

Was 0.4 angeht, geht es imo jetzt noch um das Fixen von eventuellen Problemen/uninitialized-Warnings usw., und dann wäre da noch die Frage der Vervollständigung der Doku im Hinblick auf "optimales Vorgehen" bzw. Abrundung der automatisiert (via de-cfg) erstellten slots. Da wäre z.B. noch der OnOff-Slot bzw. hoch/runter-Verfeinerungen usw.. Habe da auch noch keine abschließende Meinung zu, _glaube aber_, dass wir gut daran täten,  von vornherein "filigranere" Slots (Device-xy und OnOff-xy) zumindest vorzustellen und (via Modul und de-cfg) vorzubereiten.

(Ja, die FHEM-Doku kann keine Rhasspy-Doku ersetzen, aber es ist eng verzahnt, so dass sich da gewisse Doppelungen kaum vermeiden lassen, oder?).

Kann im Moment nicht sagen, was von der ToDo-Liste sonst noch aktuell ist.

war mein ursprünglicher Plan, die CRef kurz und knapp zu halten.

Finde ich nach wie vor richtig, andererseits finde ich aber die Doppelung definitiv nicht gut, da Doppelarbeit und immer dem Risiko ausgesetzt, dass es widersprüchlich ist. Sehe nur zwei Auswege (cref ist und bleibt Pflicht und steht daher nicht zur Diskussion): Entweder "alles" aus der md kommt in die cref (von mir aus gerne automatisiert), einschl. Tipps und Tricks, oder es gibt eine eindeutige Struktur in der md, die "zwingend" voraussetzt, dass man die Bezugspunkte in der cref daneben legt und die md diese nur ergänzt.
Da ich im Moment nicht glaube, dass noch besonders viele Anwendungshinweise dazu kommen, wäre ich  eher für eine "cref only"-Variante.


Was die Roadmap für 0.5/0.6 angeht, hätte ich folgende Punkte auf der Liste:
- automatisches Umschalten von Einzel- auf Gruppenkommando (wenn eine Gruppe in dem JSON ist, aber kein Device);
- (mehr) Bestätigungsoptionen