Modulentwicklung für Rhasspy Sprachassistent

[drhirn]

Ahh, Käse. Es gibt bei HUEDevices ein set scene. Das wusste ich nicht.

Code Auswählen Erweitern

off:noArg on:noArg toggle:noArg statusRequest:noArg pct:colorpicker,BRI,0,1,100 bri:colorpicker,BRI,0,1,254 color:colorpicker,CT,2000,1,6500 ct:colorpicker,CT,154,1,500 dimUp:noArg dimDown:noArg ctUp:noArg ctDown:noArg alert:none,select,lselect rename scene:Energie#tanken#[id=1N0Ow9IjFvwJWOb],Energie#tanken#[id=iJiMFXkE57qvCJ7],Energie#tanken#[id=ykGAH5vm9qguUhm],Entspannen#[id=MkBqmt1iphIRayB],Entspannen#[id=g9hPzEGZkAR2g5j],Entspannen#[id=gbca4wF9Vni8oSb],Frühlingsblüten#[id=amg18-TICTPiayR],Frühlingsblüten#[id=fmsyN3Ve4fYGqhG],Frühlingsblüten#[id=wZdk5cpy35oldlw],Gedimmt#[id=7r1VzbwX5H5VVqW],Gedimmt#[id=nEY-TZ2qVEx6WpP],Gedimmt#[id=oZRhLrscoEgC7Xu],Hell#[id=Kd35TY8qIb6pTax],Hell#[id=QszaD6316SsOGNX],Hell#[id=jJAU3n8QlDZI4Zh],Konzentrieren#[id=WGjGSBvWPfW0JH0],Konzentrieren#[id=ig9Hb2jZ6iP9X0E],Konzentrieren#[id=kcz2eYl2goK91Hz],Lesen#[id=IYY-Qkhs6577mil],Lesen#[id=qk7qNpKVeugEugh],Lesen#[id=s-co9adxMQsAsEz],Nachtlicht#[id=0F5VwJFcHpymkm2],Nachtlicht#[id=Ke4VCTMCsSNaIli],Nachtlicht#[id=yJ0tWdBhE-emL3q],Nordlichter#[id=UloxktBtdsVJEUg],Nordlichter#[id=l9gNnheN-NwDIgY],Nordlichter#[id=lk39fWLRdxjTqVl],Sonnenuntergang#Savanne#[id=968VgE7b29JysiY],Sonnenuntergang#Savanne#[id=J88yqZyARhlQh4q],Sonnenuntergang#Savanne#[id=SOcyx8ZWLqI73MR],Tropendämmerung#[id=1a6rDrpjg-i33u8],Tropendämmerung#[id=Li5XQV2Ckvcl9ac],Tropendämmerung#[id=yzMdTFOtJPAIVel] off-for-timer on-till-overnight on-till blink off-till off-till-overnight on-for-timer intervals attrTemplate:?,----subordinated-devices-section--------,C_01_Eurotronic_SPZB0001_Spirit_ZigBee,D_01_Xiaomi_Aqara_MCCGQ11LM_Window_Door_Sensor,E_01a_Xiaomi_Aqara_WSDCGQ11LM_Temperature_Sensor,E_01b_Xiaomi_Aqara_WSDCGQ11LM_Pressure_Sensor,E_01c_Xiaomi_Aqara_WSDCGQ11LM_Humidity_Sensor,F_01a_Xiaomi_Aqara_RTCGQ11LM_Lightlevel_Sensor,F_01a_Xiaomi_Aqara_RTCGQ11LM_Motion_Sensor,G_01_Xiaomi_Aqara_WXKG02LM_Double_Switch

Der Slot ist jetzt mit den Szenen aus "getAllSets" gefüllt. Das Training schlägt natürlich fehl.

[Beta-User]

Ahh, Käse. Es gibt bei HUEDevices ein set scene. Das wusste ich nicht.

In der Theorie war mir das klar, nur nicht, wie es in der Praxis aussieht, wenn man Szenen konkret definiert hat .

Wie dem auch sei, es ist tricky bzw. irgendwie auch "eigen", was da aus dem HUEDevice kommt...

Mach mal diese Änderung in #1148 rein:

Code Auswählen Erweitern

$clscene = (split m{[#]\[id}xms, $clscene)[0] if $clscene =~ m{[#]\[id}xms;
Damit bekomme ich immerhin mal ein "sauberes" listing von RHASSPY hin, allerdings ist es ggf. rückwärts dann "spannend", was passiert, wenn man eines von den "dreifachen Lottchen" haben will? RHASSPY müßte sich eigentlich eines aussuchen, welches wir vermutlich über einen unsortierten Hash-Zugriff ermittelt und damit zufällig...

(Irgendwie irritiert es mich, dass da soviel Tech-Content an FHEM abgeliefert wird; ich würde tippen, dass die entweder alle gleich sind, oder nur einer funktioniert und die anderen irgendwie "outdated" sind...)

[drhirn]

Kein Änderung, leider.

Ich hab da keine Szene definiert. Die sind "ab Werk" auf der HueBridge definiert. Warum das jeweils drei sind, weiß ich nicht. Kann aber mit dem Wechsel der Bridge zusammen hängen.

Können wir nicht all=none als Standard definieren?

[Beta-User]

Zwischenzeitlich habe ich mir das auch nochmal angesehen, irgendwie hatte ich bisher nicht realisiert, dass ja _auch_ die "Technames" scheinbar ein Problem darstellen und das mapping direkt auf der Rhasspy-Seite erfolgt...

Eine "Sonderlocke" für "echte" HueBridges (mein Test-HUEDevice unter deconz kennt diese Art von scene nicht) finde ich unglücklich, aber im Moment sehe ich auch keine wirkliche Alternative. Hab's jetzt aber (hoffentlich) anders gelöst, indem eben in diesem Fall die id "durchgeschleust" und beim setter wieder rekonstruiert wird.

Unsicher war ich schon immer, ob es nicht gut wäre, die Device-Info da noch mit reinzubasteln, um gleiche Szenen auseinanderzuhalten. Diese Aktion hier deutet sehr darauf hin, dass es evtl. wirklich eine gute Idee wäre. Das würde aber bedeuten, dass man den ganzen Mapping-Mechanismus an der Stelle nochmal aufbrechen muss und wieder von Rhasspy auf RHASSPY verlagern. Kein Hexenwerk, aber potentiell fehleranfällig und evtl. mit anderen Problemen verbunden...

[drhirn]

Cool! Jetzt werden die Szenen brauchbar hochgeladen 
Danke!

Mal schauen, ob ich das dann auch testen kann. Hab die noch nie verwendet.

[Beta-User]

Danke erst mal für Rückmeldung Teil 1 - es war mir erst mal sehr wichtig, dass wir Rhasspy nicht mit diesem feature "aus dem Tritt" bringen.

Bin mal gespannt, ob das mit dem Anwenden auch klappt (=Teil2) - ich habe das nämlich mit HUEDevice auch noch nie genutzt, nur mit "normalen" Technames (= ohne Sonderzeichen, v.a. ohne das "kommentarverdächtige" #)...

(Falls keine offenkundigen Probleme vorhanden sind, wäre ein svn-Update vermutlich nicht schlecht, weil sonst evtl. der nächste "echte" HueBridge-User über das Thema stolpert).

[drhirn]

Bin mal gespannt, ob das mit dem Anwenden auch klappt (=Teil2) - ich habe das nämlich mit HUEDevice auch noch nie genutzt, nur mit "normalen" Technames (= ohne Sonderzeichen, v.a. ohne das "kommentarverdächtige" #)...

Ich wollte gerade mal wissen, was überhaupt passiert, wenn ich eine Szene auf einem HUEDevice schalte. Das hier

Code Auswählen Erweitern

Unknown argument scene, choose one of off on toggle statusRequest pct bri dimUp dimDown alert rename scene off-for-timer on-till-overnight on-till blink off-till-overnight off-till on-for-timer intervals attrTemplate

Also, keine Ahnung, was das mit den Szenen da soll.

--edit--
Dafür weiß ich jetzt, warum's drei sind: Für jeden HUE-Raum eine

[Beta-User]

Ähm, häh...?!?

Kann man die ("gleichnamigen" 3) scene(s) denn über das FHEMWEB-Interface schalten? Eigentlich müßte es dort ein dropdown geben... Oder kommt da auch diese Meldung zurück? Oder steht in dem dropdown was ganz anders als vermutet? - Ja, scheint so... Aber bedeutet das, dass man den Befehl dann ohne die "#" zusammenbauen muss? Oder gar, dass "id=xyz" reicht?!?

Wäre klasse, wenn du das mal etwas intensiver testen könntest, ich vermute fast, dass HUEDevice auch parseParams nutzt und dann das "unnütze Bewerk" einfach verwirft....

RHASSPY sollte jedenfalls bei verbose 5 loggen, welcher Befehl versuchsweise abgesetzt wurde.

[drhirn]

HUEDevice.pm kann's nicht wie's aussieht. Hab nur das hier gefunden: https://forum.fhem.de/index.php/topic,100827.0.html
Aber ja, wenn ich's über FHEMWEB schalte, kommt genau die Meldung.

Können wir die Szenen nicht einfach nur sammeln, wenn das Device gDT "Scene" od. "Media" hat?

[Beta-User]

Hmm, also:
Habe mal via phoscon Szenen angelegt, allerdings erst mal nur an einem Device (einer Gruppe, genauer gesagt) => die werden ohne die id an FHEM übergeben, und ein "set" in FHEMWEB läuft auch ohne direkt erkennbare Fehlermeldung durch.
Von daher bin ich nicht unbedingt für die Lösung, "scene" auf die beiden genannten gDT zu begrenzen.

Aus dem verlinkten Thread werde ich nicht so recht schlau, weil da unklar bleibt, ob es (ohne Modul-Anpassung?) klappt, wenn man die id korrekt übergibt, oder ob das (ggf. auch ohne id) nur dann geht, wenn man die modifizierte Version verwendet? ("Lustig" dort: lc und utf8...)

Allerdings hatte ich den Eindruck, dass das mit dem Anwenden der (id-losen) Szenen dann effektiv keine Auswirkungen in der Realität hat...?!? Ein Blick in den Code (der Teil findet sich in HUEBridge) verrät dann (jedenfalls war das mein vorläufiges Verständnis): Sowohl die "originalen" Szenen der HueBridge wie auch deCONZ-Szenen brauchen die id, und die wird identifiziert anhand der "Verpackung" in eckigen Klammern, der Rest der Argumente scheint als unnötiges Beiwerk betrachtet zu werden... 
EDIT: "Brauchen" wohl nicht, aber _wenn_ sie vorhanden ist, erfolgt die Identifizierung wohl (nur) per id.

Na ja, wie dem auch sei, mal meine vorläufige Meinung zu diversen Aspekten:
- bin dagegen, die Funktionalität an dieser Stelle "künstlich" zu begrenzen;
- Workaround ist vorhanden, Rhasspy wird auch ohne workaround nicht gestört => kein unmittelbarer Handlungsdruck;
- "kaputte" (im Sinne von nicht von FHEM aus setzbare) Szenen sind eigentlich ein HUEDevice-Problem und sollten an der richtigen Stelle gefixt werden => eher den verlinkten Thread nochmal aufgreifen
- "ganz kaputte Szenen" (=auch nicht auf der HueBridge selbst setzbare) sind ggf. vom User aus der Bridge zu löschen (grundsätzliches Aufräumen ist nicht RHASSPY-Aufgabe...)

Brauche vermutlich noch ein paar Tests, auch mit "Leerzeichen-Szenen" und mehr Szenen auf mehr HUEDevice-Geräten, anbei jedenfalls mal eine Version, die
- zum einen keine # an Rhasspy liefern sollte, wenn keine id gesetzt ist, aber "Leerzeichen" enthalten sind (HUEDevice füllt die auf), und
- zum anderen dann _nur_ die "richtig verpackte" (?) id an die "set"-Anweisung übergibt.
Vielleicht kommen wir ja so weiter, ansonsten wäre wie gesagt m.E. justme1968 isns Boot zu holen.

[Raemsna]

Sooo, für mutige (und FHEM-mäßig akuelle!) Tester und User....

(Intern wird jetzt die Register.pm zur Timerverwaltung genutzt. Das kommt mit dem update erst seit ein paar Tagen, ich hab's aber (mit RHASSPY) noch nicht intensiv getestet...)

Dafür kann das Ding jetzt vielleicht on-for-timer...

Beim gDT-Mapping ist mir auch was kaputt gegangen gewesen, das ist auch repariert.

sentence.ini zum Testen:

Code Auswählen Erweitern


[de.fhem:SetTimedOnOff]
(schalt|mach) (den|die|das) $de.fhem.Device-SetOnOff{Device} [in|im|in der|auf der] [$de.fhem.Room{Room}] für [((1..60){Hour!int} (stunde|stunden))] [und] [((1..60){Min!int} (minute|minuten))] [und] [((1..60){Sec!int} (sekunde|sekunden))] $OnOffValue{Value}

Hi,

nachdem ich jetzt FHEM aktuell habe, wollte ich eben on-for-timer in Rhasspy testen.

- Ich hab die neueste Version aus Post https://forum.fhem.de/index.php/topic,119447.msg1160270.html#msg1160270 eingespielt.
- Modul lädt, scheint alles i.O. zu sein
- updates von FHEM aus gemacht (update devicemap, slots, all)
- Train in Rhasspy aufgerufen

Dann wollte ich die oben angehängte Sentence einfügen.

Ergebnis in Rhasspy:
AssertionError: Missing slot $OnOffValue

Ich bin mir aktuell nicht sicher, ob ich etwas händisch einfügen muss, oder ob das das FHEM Modul könnten sollte?

Danke und Grüße
Raemsna

[drhirn]

Das ist ein Slot, den Beta-User und ich händisch angelegt haben. Sieht so aus:

Code Auswählen Erweitern


(an|einschalten|ein|anschalten|aktiviere|aktivieren|anmachen|schließe|schließen|runter|zu|raus|ausfahren|rausfahren|läuft|rennt):an
(aus|ausschalten|ab|abschalten|deaktiviere|deaktivieren|ausmachen|öffne|öffnen|rauf|auf|rauf|rein|einfahren|reinfahren):aus


Du kannst das aber in dem "sentence" durch

Code Auswählen Erweitern


... (an|ein|aus){Value}

ersetzen. Dann brauchst du den Slot nicht.

[Beta-User]

Ist bei mir etwas anders:

Code Auswählen Erweitern

aus:off
on
zu:off
auf:on
off
an:onValue ist dann gleich "international".
Könnte man ggf. (überarbeitet) auch in de-cfg über nehmen, müsste dann aber de.fhem.... vor den slot-Namen packen.

[drhirn]

Naja, schwierig. Dann müssten wir alle englischen Möglichkeiten abdecken. Weil, ist ja nicht nur ein/aus, sondern z.B. auch auf/zu, runter/rauf, etc. Glaube, es ist einfacher, wenn das jeder selber macht. Und ein bisschen Rhasspy-Wissen schadet ja nicht.

Aber hast recht, mein Beispiel war nicht ganz korrekt. Hätte so heißen sollen:

Code Auswählen Erweitern


(an|ein){Value:on}
(aus){Value:off}


[Beta-User]

Ja, ist ein Thema, das eigentlich auch etwas mehr "Hirnschmalz" vertragen könnte...
Bin z.B. auch noch nicht dazu gekommen, das "auf/zu"-Ding abzuspalten (und z.B. mit "öffne/schließe" zu ergänzen); das sollte m.E. eigentlich in einen eigenen Slot, damit es zu gDT blind paßt (aber bisher waren meine Erkennungsergebnisse seit der Umstellung der sentences auf -group auch so ok => eilt nicht).

Was allerdings immer noch nicht wollte (bzw. mit den letzten Versionen effektiv noch "schlechter" war), ist das Schalten bestimmter Gruppen. Leider habe ich da den Dreh' noch nicht gefunden, warum (in der angehängten Fassung wenigstens) die erste von zwei Gruppen funktioniert, die andere aber nicht, wenn die als letzte steht und ein Leerzeichen enthält...
Muss ich mir nochmal intensiver ansehen, das scheint irgendwie an der regex zu hängen. Nach regex101.com wäre die aber an sich ok, bin grade ratlos.

(Ansonsten sind nur noch zwei weitere "uninitialized"-Stellen gefixt).