Modulentwicklung für Rhasspy Sprachassistent

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

Vorheriges Thema - Nächstes Thema

JensS

@Beta-User
ZitatDann haken wir diesen Teil also ab :) .
Gern - Codebereinigung halte ich generell für vorrangiger.

SetAllOff hatte ich mal auf Wunsch eines Freundes geschrieben und als zweckmäßig empfunden. Da bin ich ganz bei Dir - es ist ein erster Ansatz um Gruppen zu definieren und anzusprechen.

Kind - kommt so von Rhasspy und ist wohl so gewollt. Wichtig sind ja die folgenden Werte. Eine Manpage habe ich nicht gefunden.
Hier ein paar Links:
https://github.com/rhasspy/rhasspy/issues/25
https://forum.iobroker.net/topic/28411/rhasspy-offline-sprachsteuerung/192
EMPF-CODE:
{
"input": "schalte die wandspots ein",
"intent": { "intentName": "Lampen",
"confidenceScore": 1.0
},
"siteId": "volti",
"id": null,
"slots": [
{ //<--- slots[0]
"entity": "name",
"value": { //<---slots[0].value
"kind": "Unknown",
"value": "wandspots" //<------- = slots[0].value.value
},
"slotName": "name",
"rawValue": "wandspots",
"confidence": 1.0,
"range": {
"start": 12,
"end": 21,
"rawStart": 12,
"rawEnd": 21
}
},
{ //<--- slots[1]
"entity": "state",
"value": {  //<---slots[1].value
"kind": "Unknown",
"value": "ein" //<------- = slots[1].value.value
},
"slotName": "state",
"rawValue": "ein",
"confidence": 1.0,
"range": {
"start": 22,
"end": 25,
"rawStart": 22,
"rawEnd": 25
}
}
],
"sessionId": "volti-snowboy-36f74062-40c8-47eb-a05c-96d87fd476fb",
"customData": null,
"asrTokens": [
[
{
"value": "schalte",
"confidence": 1.0,
"rangeStart": 0,
"rangeEnd": 7,
"time": null
},
{
"value": "die",
"confidence": 1.0,
"rangeStart": 8,
"rangeEnd": 11,
"time": null
},
{
"value": "wandspots",
"confidence": 1.0,
"rangeStart": 12,
"rangeEnd": 21,
"time": null
},
{
"value": "ein",
"confidence": 1.0,
"rangeStart": 22,
"rangeEnd": 25,
"time": null
}
]
],
"asrConfidence": null,
"rawInput": "schalte die wandspots ein",
"wakewordId": "snowboy"
}
Debian auf APU2C4, HM-CFG-USB2, SIGNALduino, HM-ES-PMSw1-Pl, TFA 30.3121, TFA 30.3125, ITS-150, PIR-5000, configurable Firmata USB & LAN, 1-wire: DS-18B20, DS-18S20, DS-2408, DS-2413, diverse I2C-Komponenten, zigbee2mqtt, ESPEasy etc.

Cordula

#271
Hab beim getNumeric noch ein Problem.

RHASSPY: [Rhasspy] Parse (IO: RhasspyMQTT2): Msg: hermes/intent/de.fhem_GetNumeric => {"input": "temperature im arbeitszimmer", "intent": {"intentName": "de.fhem:GetNumeric", "confidenceScore": 1.0}, "siteId": "arbeitszimmer", "id": null, "slots": [{"entity": "Type", "value": {"kind": "Unknown", "value": "temperature"}, "slotName": "Type", "rawValue": "wie ist die temperatur", "confidence": 1.0, "range": {"start": 0, "end": 11, "rawStart": 0, "rawEnd": 22}}, {"entity": "de.fhem.Room", "value": {"kind": "Unknown", "value": "arbeitszimmer"}, "slotName": "Room", "rawValue": "arbeitszimmer", "confidence": 1.0, "range": {"start": 15, "end": 28, "rawStart": 26, "rawEnd": 39}}], "sessionId": "arbeitszimmer-Okay Kalle-3117dfb0-43e9-4751-89b2-c2158e39da76", "customData": null, "asrTokens": [[{"value": "temperature", "confidence": 1.0, "rangeStart": 0, "rangeEnd": 11, "time": null}, {"value": "im", "confidence": 1.0, "rangeStart": 12, "rangeEnd": 14, "time": null}, {"value": "arbeitszimmer", "confidence": 1.0, "rangeStart": 15, "rangeEnd": 28, "time": null}]], "asrConfidence": null, "rawInput": "wie ist die temperatur im arbeitszimmer", "wakewordId": "Okay Kalle", "lang": null}
2021.04.09 17:22:59 5: Parsed value: temperature im arbeitszimmer for key: input
2021.04.09 17:22:59 5: Parsed value: temperature for key: Type
2021.04.09 17:22:59 5: Parsed value: GetNumeric for key: intent
2021.04.09 17:22:59 5: Parsed value: arbeitszimmer-Okay Kalle-3117dfb0-43e9-4751-89b2-c2158e39da76 for key: sessionId
2021.04.09 17:22:59 5: Parsed value: arbeitszimmer for key: Room
2021.04.09 17:22:59 5: Parsed value: wie ist die temperatur im arbeitszimmer for key: rawInput
2021.04.09 17:22:59 5: Parsed value: 1 for key: probability
2021.04.09 17:22:59 5: Parsed value: arbeitszimmer for key: siteId
2021.04.09 17:22:59 5: handleIntentGetNumeric called
2021.04.09 17:22:59 5: matches in room: Az.Heizung, matches outside: Bad.Heizung Sz.Heizung Gaestezimmer.Heizung Wetter.Temperatur Wz.Heizung Fritzbox_repeater Aussenstation Ebus
2021.04.09 17:22:59 5: Az.Heizung


Bei der Antwort holt er sich scheinbar aus der Config einen falschen Wert.

voiceResponse = temperature von arbeitszimmer beträgt 21,70 Grad Prozent

Die Gradangabe in der Antwort kommt von der Variablen. Die Prozent scheinbar aus der Config-Datei eventuell aus dem Eintrag:

"knownType": "$mappingType von $location beträgt $value Prozent",

Ein Eintrag für temperature ist vorhanden:

"temperature": {
        "0": "Die Temperatur von $location ist $value",
        "1": "Die Temperatur von $location beträgt $value Grad"
      },

Hab schon verschiedene Änderungen an der config gemacht, ohne Reaktion. Update Language habe ich gemacht.

Bei der Luftfeuchtigkeit habe ich keine Probleme.

drhirn


JensS

Bei GetNumeric bin ich auch noch nicht glücklich über {Type:temperature} in sentences.ini.
Mal ist was in deutsch und groß geschrieben, mal klein und in englisch. Irgendwo müsste das eindeutig beschrieben sein. Da wären wir wieder beim Wiki-Artikel...
Debian auf APU2C4, HM-CFG-USB2, SIGNALduino, HM-ES-PMSw1-Pl, TFA 30.3121, TFA 30.3125, ITS-150, PIR-5000, configurable Firmata USB & LAN, 1-wire: DS-18B20, DS-18S20, DS-2408, DS-2413, diverse I2C-Komponenten, zigbee2mqtt, ESPEasy etc.

Cordula

So:
attr Az.Heizung rhasspyMapping GetNumeric:currentVal=Temperatur,type=temperature

Beta-User

@Cordula: (ergänzend) Ist da eventuell eine CustomResponse im Spiel?
Sieht für mich so aus, als wäre es entweder das, oder das Reading ist ein anderes, müßte erforderlichenfalls in die Details gehen.

Bzgl. "kind"
Dass das gewollt ist, ist soweit klar; irgendwie müßte es aber möglich sein, Rhasspy mitzuteilen, welches "Ding" welcher "kind" ist, diffuse Vermutung: der JSON zur Bildung des slots müßte entsprechende zusätzliche Infos enthalten...
(Muß mal schauen, wie das intern abgespeichert wird).

Mit der "silence" muss ich auch mal sehen, interessant war aber auf die Schnelle das Stichwort "rebranded-the-matrix-voice-to-esp32-rhasspy-satellite"; einen ESP32 hätte ich ggf. für's Wohnzimmer übrig ;D ...

Zitat von: JensS am 09 April 2021, 18:13:59
Bei GetNumeric bin ich auch noch nicht glücklich über {Type:temperature} in sentences.ini.
Mal ist was in deutsch und groß geschrieben, mal klein und in englisch. Irgendwo müsste das eindeutig beschrieben sein. Da wären wir wieder beim Wiki-Artikel...
Die Regel ist eigentlich klar: die MQTT-Messages sollten im Ergebnis ALLE allgemeingültige (englische) Begriffe beinhalten, die eigentliche Sprache kommt dann erst wieder bei der Sprachausgabe zum Tragen. Alles dazwischen sollte (einheitlich) englisch sein.

Von daher ist es uU. das Mapping, das hier Probleme macht und (irgendwie) umgestellt werden müßte. Es kann aber sein, dass der Readingname da aus irgendeinem Grund nicht sauber übernommen wird. Bin an der Stelle auch noch unschlüssig, wie man das lösen kann.
Wie wird das denn in den Hash übernommen, und heißt das abzugreifende Reading wirklich Temperatur?
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

Cordula

Problem gelöst. Ich habe die Gradangabe in der Variablen entfernt (also statt : 21,6 Grad nur noch 21,6). Jetzt funktionierts. Scheinbar gibts da ein Problem, wenn Textzusätze in der Variablen stehen.

drhirn

Zitat von: Cordula am 09 April 2021, 18:33:56
Problem gelöst. Ich habe die Gradangabe in der Variablen entfernt (also statt : 21,6 Grad nur noch 21,6). Jetzt funktionierts. Scheinbar gibts da ein Problem, wenn Textzusätze in der Variablen stehen.

Da gab's mal part für's Mapping: https://github.com/Thyraz/Snips-Fhem#getnumeric
Ist noch im Code, aber ich weiß gerade nicht, ob's funktioniert. Probier's einfach.

JensS

#278
@drhirn
Wie lauten die offiziellen Übersetzungen für Helligkeit, Temperatur, Sollwert, Lautstärke, Luftfeuchtigkeit, Batterie, Wasserstand? Gilt die englische Kleinscheibung auch für {device}, {room}, {value}, {etc.}?
Mit https://github.com/drhirn/fhem-rhasspy/blob/0.4.7b/README.md kann ich leider meine sentences.ini und mappings nicht umstellen.
Debian auf APU2C4, HM-CFG-USB2, SIGNALduino, HM-ES-PMSw1-Pl, TFA 30.3121, TFA 30.3125, ITS-150, PIR-5000, configurable Firmata USB & LAN, 1-wire: DS-18B20, DS-18S20, DS-2408, DS-2413, diverse I2C-Komponenten, zigbee2mqtt, ESPEasy etc.

Cordula

Ich denke, da stimmt die Antwort noch nicht ganz.

RHASSPY: [Rhasspy] Parse (IO: RhasspyMQTT2): Msg: hermes/intent/de.fhem_GetNumeric => {"input": "wie ist die airHumidity im küche", "intent": {"intentName": "de.fhem:GetNumeric", "confidenceScore": 1.0}, "siteId": "arbeitszimmer", "id": null, "slots": [{"entity": "Type", "value": {"kind": "Unknown", "value": "airHumidity"}, "slotName": "Type", "rawValue": "luftfeuchtigkeit", "confidence": 1.0, "range": {"start": 12, "end": 23, "rawStart": 12, "rawEnd": 28}}, {"entity": "de.fhem.Room", "value": {"kind": "Unknown", "value": "küche"}, "slotName": "Room", "rawValue": "küche", "confidence": 1.0, "range": {"start": 27, "end": 32, "rawStart": 32, "rawEnd": 37}}], "sessionId": "arbeitszimmer-Okay Kalle-0eb668f5-8860-402b-8872-bda42c3651ae", "customData": null, "asrTokens": [[{"value": "wie", "confidence": 1.0, "rangeStart": 0, "rangeEnd": 3, "time": null}, {"value": "ist", "confidence": 1.0, "rangeStart": 4, "rangeEnd": 7, "time": null}, {"value": "die", "confidence": 1.0, "rangeStart": 8, "rangeEnd": 11, "time": null}, {"value": "airHumidity", "confidence": 1.0, "rangeStart": 12, "rangeEnd": 23, "time": null}, {"value": "im", "confidence": 1.0, "rangeStart": 24, "rangeEnd": 26, "time": null}, {"value": "küche", "confidence": 1.0, "rangeStart": 27, "rangeEnd": 32, "time": null}]], "asrConfidence": null, "rawInput": "wie ist die luftfeuchtigkeit im küche", "wakewordId": "Okay Kalle", "lang": null}
2021.04.09 22:46:56 5: Parsed value: arbeitszimmer for key: siteId
2021.04.09 22:46:56 5: Parsed value: 1 for key: probability
2021.04.09 22:46:56 5: Parsed value: wie ist die luftfeuchtigkeit im küche for key: rawInput
2021.04.09 22:46:56 5: Parsed value: küche for key: Room
2021.04.09 22:46:56 5: Parsed value: arbeitszimmer-Okay Kalle-0eb668f5-8860-402b-8872-bda42c3651ae for key: sessionId
2021.04.09 22:46:56 5: Parsed value: GetNumeric for key: intent
2021.04.09 22:46:56 5: Parsed value: airHumidity for key: Type
2021.04.09 22:46:56 5: Parsed value: wie ist die airHumidity im küche for key: input
2021.04.09 22:46:56 5: handleIntentGetNumeric called
2021.04.09 22:46:56 5: matches in room: , matches outside: Gaestezimmer.Feuchtigkeit Flur.Feuchtigkeit Bad.Feuchtigkeit Sz.Feuchtigkeit Az.Feuchtigkeit Wz.Feuchtigkeit
2021.04.09 22:46:56 5: Gaestezimmer.Feuchtigkeit


Antwort: Die Luftfeuchtigkeit von gaestezimmer beträgt 39,62 Prozent

In der Küche gibt es aber keinen Luftfeuchtigkeitssensor. Matches outside sind keine wirklichen Treffer.

Meiner Meinung nach sollte die Antwort etwa so lauten:

Ich kann keine Luftfeuchtigkeit in der Küche feststellen oder eine allgemeinere Fehlermeldung.

Was meint ihr dazu?

Cordula

@drhirn
part=1 funktioniert nicht, Es wird nicht die Zahl geholt, sondern der Zusatz. Damit findet er dann wieder nicht die richtige Antwort. Ist aber kein Problem. Über ein entsprechendes Attribut userreadings hab ich mir ein passendes reading erzeugt. Damit geht's.

Beta-User

Puh, jetzt sind ja viele Fragen im Raum...

Vorab mal zu "part" und allgemeinen mapping-Fragen:
- die Grundstruktur der Mappings folgt (zumindest einstweilen) weiter der alten Logik und bildet die von der (alten) Funktion zurückgegebene Hash-Struktur eben in dem Gesamthash direkt ab, die gDT-Geschichte versucht "nur", passende Einstellungen für "unbekannte Geräte" zu erraten, indem z.B. das Vorhandensein bestimmter setter geprüft wird.
- Daher sollte v.a. auch part weiter funktionieren, allerdings wäre der erste Teil vermutlich "0", nicht "1";

Zum gDT-Thema:
- In das Attribut sollten nur Werte geschrieben werden, die "allgemeingültig" sind, ein farbiges Licht ist in dieser Logik m.E. auch weiter "light", eine LightScene sollte "scene" sein;
Allgemeingültig meint: das Schlüsselwort kennen auch die anderen Sprachsteuerungslösungen.
- Für Farbe und Farbtemperatur ist mir noch nichts gescheites eingefallen, stand bisher nicht auf meiner persönlichen Prio-Liste. Der bisherigen Logik folgend müßte man das auch "RHASSPY"-konform in einen auswertbaren (Teil-) Hash packen. Neben vielem anderen ist da aber das Problem, dass es für CT z.B. keine normierten Werte gibt, ebenso ist HUE mWn. auch nicht wirklich standardisiert, rgb müsste nach rhasspyColor...
Das sind ziemlich viele Details, die man da kennen und beachten muß, daher wäre es uU. gut, wenn wir jemanden im Boot hätten, der mehr Erfahrung damit hat (z.B. justme1968 wäre super), damit man ggf. bereits bekannte Eckdaten aus homeBridgeMapping berücksichtigen könnte. Würde den Teil daher perspektivisch erst nach dem 29.04. angehen
- "scene" und speziell LightScene sind sicher interessant. Da wäre es super, wenn sich jemand das mal ansehen würde, der mit der bisherigen "Szenenfunktionalität" von RHASSPY etwas besser vertraut ist. Es gibt in den heutigen Beispielen zu "light" schon Varianten, die TYPE berücksichtigen, das ganze könnte man also so lösen, dass gDT "scene" vergeben wird, und dann ein ganzer Unterzweig sich vorab mit LightScene befasst und nur "der unbekannte Rest" mit irgendwelchen defaults (welchen...?) vorbelegt wird (oder eben gar nicht).

"Englisch" und Kleinschreibung
Vorab mal sorry, dass ich scheinbar die Frage hinter der Frage nicht verstanden hatte...
- Bekannt sind die "Type", die im Hashbereich "Change" hinterlegt sind, also:
temperature, brightness, airHumidity, soilMoisture, volume, waterLevel, battery, setTarget, knownType, unknownType
(sorry, dass es da auch nicht einheitlich klein oder groß ist).
Die sollten eigentlich auch aus der "alten Welt" direkt übersetzt werden, wenn sie im mapping stehen. Das Problem sind hier (vermutlich) nur die Anfragen aus sentences.ini.
- Die "Label" für die Kategorien sind unverändert. Da finde (und fand) ich die "technische Kennzeichnung" mit einem Großbuchstaben zum Start eine gute Sache. So sieht man gleich, dass es sich um was spezielles handelt.
Insbesondere {Device} und {Type} sind also in sentences.ini weiter korrekt;

- "unknownType" ist dabei eigentlich keine wirkliche Übersetzung, sondern (hoffentlich) halt eine Auffangkategorie für alles, was nicht in die vorherige Liste paßt. An der Stelle eine Warnung: mir ist im Moment unklar was passiert, wenn man eine "ungültige" Anfrage stellt, also z.B. nach einem Widerstand. Wer im Moment sowas macht, begibt sich evtl. auf gefahrgeneigtes Terrain, kann sein, dass man da was besser absichern muss;

Zu "matches outside"
Zitat von: Cordula am 09 April 2021, 22:58:34
Ich denke, da stimmt die Antwort noch nicht ganz.

[...] Meiner Meinung nach sollte die Antwort etwa so lauten:

Ich kann keine Luftfeuchtigkeit in der Küche feststellen oder eine allgemeinere Fehlermeldung.

Was meint ihr dazu?
...vorab bin ich ja froh, dass nicht nur ich das Problem habe...
Die jetzige Lösung legt immerhin schon mal offen, dass da ein Problem besteht, indem wenigstens der korrekte Raum angesagt wird.
Meine persönliche Vorstellung wäre:
1. Schritt: Andere Ansage - "Für die Küche kenne ich den Wert nicht, im Arbeitszimmer ..." (das sollte relativ einfach umzusetzen sein)
2. Schritt:
-- Gibt es nur einen passenden Wert "outside" => Ansage wie Schritt 1;
-- Gibt es mehrere: Abfrage, welchen (mit Abbruchmöglichkeit oder Timeout
Das würde ich auch auf "für später" auf die todo-Liste nehmen, denn es gibt dazu einen "kleinen Bruder", wie bereits angemerkt: mehrere Sensoren im Raum. Diese Variante finde ich persönlich dringlicher zu lösen, denn da kommen im Moment noch "falsche" Ergebnisse, wenn man z.B. "thermostat"-gDT-Geräte hat.

Hoffe, damit erst mal die gröbsten Unklarheiten erläutert zu haben, bitte melden, wenn ich was übersehen haben sollte.
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

Jössas Maria, ihr brauch aber wenig Schlaf ;D

Ich gebe zu, dass keine Doku derzeit brauchbar ist. Ich komme einfach nicht hinterher. Und meine Auszeit vor kurzem in der ihr fleissig weiter entwickelt habt, hat das nicht besser gemacht. Da ich nur dokumentiere, was ich vorher getestet habe, ist das alles sehr, sehr viel Aufwand. Unter anderem, weil's halt derzeit so ist, dass eine Doku nicht lange Bestand hat ;).

Deswegen bin ich auch gegen eine Wiki-Seite. Ich kann ich nicht noch um eine dritte Doku kümmern. Und ich fände es auch nicht gut, wenn plötzlich Wiki - CRef - README total auseinanderlaufen.

Es ist jetzt aber auch nicht so, dass das alles an mir hängen bleiben muss. Das Modul und die Doku sind bewusst auf GitHub. Es kann somit jeder mitarbeiten, der das möchte. Würde mich sogar freuen!
Ihr könnt mir auch gerne einfach Sachen hier ins Forum stellen, die ich dann einbaue.

Das Modul ist unglaublich mächtig geworden. Und teilweise extrem komplex (SetNumeric z.B.). Ich muss da selber erst mal alle Möglichkeiten entdecken. Das braucht Zeit. Ich verspreche aber, dass die Doku bis spätestens 29.04. zumindest alles Wichtige richtig beinhaltet.

Und wie gesagt, Hilfe ist herzlich willkommen! Ihr könntet mir z.B. mal erzählen, was der Timer jetzt so alles kann (incl. Sentences). Das Thema hab ich nämlich leider vollkommen verpasst.

Beta-User

Na ja, "das meiste" sollte eigentlich funktionieren wie gehabt, und bis auf den berechtigten Hinweis von JensS auf die Kategorien ist auch das meiste mAn. in der cref aktuell.
Was da fehlt, ist eine Beschreibung der am Ende gelisteten intents samt passender sentences-Beispiele.

Ich habe aber v.a. bzgl. der sentences.ini und intents ähnliche Probleme hinsichtlich Doku, nicht alles ist getestet oder optimiert, sondern ich habe zu einem großen Teil auch einfach erst mal kopiert, was da war, und die Frage steht weiter im Raum, ob man nicht manches dann noch auf der Rhasspy-Seite besser verstehen könnte.

Unter Vorbehalt daher hier mal mein kompletter aktueller Stand der sentences.ini:
[de.fhem:SetNumeric]
\[(schalt|mach)] $de.fhem.Device{Device} [um] [(0..10){Value!int}] [dezibel{Unit}] (lauter|höher){Change:volUp}
\[(schalt|mach)] $de.fhem.Device{Device} [um] [(0..10){Value!int}] [dezibel{Unit}] (leiser|niedriger){Change:volDown}
( mach | stelle ) $de.fhem.Device{Device} [um] [(0..10){Value!int}] [grad{Unit}] (höher|wärmer){Change:tempUp}
( mach | stelle ) $de.fhem.Device{Device} [um] [(0..10){Value!int}] [grad{Unit}] (niedriger|kälter){Change:tempDown}
( mach |schalt|schalte|stelle) $de.fhem.Device{Device} [um] [(0..100){Value}] [prozent{Unit:percent}] (heller){Change:lightUp}
( mach |schalt|schalte|stelle) $de.fhem.Device{Device} [um] [(0..100){Value}] [prozent{Unit:percent}] (dunkler){Change:lightDown}
(schalt | schalte | stelle ) $de.fhem.Device{Device} auf (0..100){Value!float}
( mehr{Change:lightUp} | weniger{Change:lightDown} ) $de.fhem.Device{Device} [$de.fhem.Room{Room}]

[de.fhem:SetNumericGroup]
\[(schalt|mach|fahr)] (alle | sämtliche ) $de.fhem.Group{Group} [im] [( überall:global | $de.fhem.Room){Room}] [um]  [(0..10){Value!int}] [dezibel{Unit}] (lauter|höher){Change:volUp}
\[(schalt|mach)] (alle | sämtliche ) $de.fhem.Group{Group} [im] [( überall:global | $de.fhem.Room){Room}] [um] [(0..10){Value!int}] [dezibel{Unit}] (leiser|niedriger){Change:volDown}
( mach | stelle ) (alle | sämtliche ) $de.fhem.Group{Group} [im] [( überall:global | $de.fhem.Room){Room}] [um] [(0..10){Value!int}] [grad{Unit}] (höher|wärmer){Change:tempUp}
( mach | stelle ) (alle | sämtliche ) $de.fhem.Group{Group} [im] [( überall:global | $de.fhem.Room){Room}] [um] [(0..10){Value!int}] [grad{Unit}] (niedriger|kälter){Change:tempDown}
( mach |schalt|schalte|stelle) (alle | sämtliche ) $de.fhem.Group{Group} [im] [( überall:global | $de.fhem.Room){Room}] [um] [(0..100){Value}] [prozent{Unit:percent}] (heller){Change:lightUp}
( mach |schalt|schalte|stelle) (alle | sämtliche ) $de.fhem.Group{Group} [im] [( überall:global | $de.fhem.Room){Room}] [um] [(0..100){Value}] [prozent{Unit:percent}] (dunkler){Change:lightDown}
(schalt | schalte | stelle ) (alle | sämtliche ) $de.fhem.Group{Group} [im] [( überall:global | $de.fhem.Room){Room}] auf (0..100){Value!float}
( mehr{Change:lightUp} | weniger{Change:lightDown} ) (alle | sämtliche ) $de.fhem.Group{Group} [im] [( überall:global | $de.fhem.Room){Room}]


[de.fhem:MediaControls]
(starte|start){Command:cmdPlay} [die wiedergabe] [$de.fhem.Device{Device}][im] [$de.fhem.Room{Room}]
(stoppe|stop){Command:cmdStop} [die wiedergabe] [$de.fhem.Device{Device}] [im][$de.fhem.Room{Room}]
(pausiere){Command:cmdPause} [die wiedergabe] [$de.fhem.Device{Device}][im] [$de.fhem.Room{Room}]
(nächstes|nächster){Command:cmdFwd} (lied|titel) [$de.fhem.Device{Device}] [im][$de.fhem.Room{Room}]
(vorheriges|voriges|vorheriger|voriger){Command:cmdBack} (lied|titel) [$de.fhem.Device{Device}][im] [$de.fhem.Room{Room}]

[de.fhem:GetWeekday]
\[bitte] weißt du [bitte] welcher Tag heute ist [bitte]
\[bitte] kannst du mir [bitte] sagen welcher Tag heute ist [bitte]
\[bitte] könntest du mir [bitte] sagen welcher Tag heute ist [bitte]
\[bitte] kannst du mir [bitte] den [heutigen] Tag sagen [bitte]
welcher [wochentag|tag] ist heute [bitte]
welchen [wochentag|tag] haben wir heute [bitte]

[de.fhem:GetTime]
wie spät [ist es]
sag mir die uhrzeit
wie schpät [isch es]

[de.fhem:GetNumeric]
( warm | kalt | heiß | Temperatur ){Type:temperature} [ist es | von | vom | ist ] ([(im|auf dem)]($de.fhem.Room){Room}|[das]($de.fhem.Device){Device})
(wie laut | Lautstärke){Type:volume} [ist es | von | vom | ist ] ([(im|auf dem)]($de.fhem.Room){Room}|[das]($de.fhem.Device){Device})

[de.fhem:SetTimer]
labels=( Wecker | Eier | Kartoffeln | Tee )
( Lösche | entferne ){Cancel} [den] ( timer | wecker ) [<labels>{label}]
( timer | wecker ) [<labels>{label}] auf [((1..60){hour} (stunde|stunden) | (1..24){hourabs} (uhr) )] [und] [((1..60){min})]
( timer | wecker ) [<labels>{label}] auf [((1..60){hour} (stunde|stunden) | (1..24){hourabs} (uhr) )] [und] [((1..60){min} (minute|minuten))] [und] [((1..60){sec} (sekunde|sekunden))]
( timer | wecker ) [<labels>{label}] auf (1..60){hour} (einviertel{min:15}|einhalb{min:30}|dreiviertel{min:45}) (stunde|stunden)
( timer | wecker ) [<labels>{label}] auf (1..60){min} (einviertel{sec:15}|einhalb{sec:30}|dreiviertel{sec:45}) (minute|minuten)

[de.fhem:ReSpeak]
was hast du gesagt

[de.fhem:SetMute]
(gute nacht){Value:on}
(guten morgen){Value:off}

[de.fhem:Shortcuts]
motor aus
auto an
motor an
ton aus
auto aus
ton an
du bisch cool

[de.fhem:ConfirmAction]
(ja mach | tu es | ist ok ){Mode:OK}
(lass es | nein | abbrechen | abbruch ){Mode}

[de.fhem:GetOnOff]
ist [der|die|das] $de.fhem.Device{Device} [$de.fhem.Room{Room}] (an|ein){Status}
(läuft){Status} $de.fhem.Device{Device} [$de.fhem.Room{Room}]

[de.fhem:Status]
wie ist der status{Status} $de.fhem.Device{Device} [(im|in der|auf der|draußen|auf dem)] [$de.fhem.Room{Room}]

[de.fhem:GetOnOff]
ist [der|die|das] $de.fhem.Device{Device} [$de.fhem.Room{Room}] $OnOffValue{Status}
(läuft){Status} $de.fhem.Device{Device} [$de.fhem.Room{Room}]

[de.fhem:SetOnOff]
\[(schalt|mach|fahr)] [den|die|das] $de.fhem.Device{Device} [$de.fhem.Room{Room}] $OnOffValue{Value}

[de.fhem:SetOnOffGroup]
\[(schalt|mach|fahr)] (alle | sämtliche ) $de.fhem.Group{Group} [im] [( überall:global | $de.fhem.Room){Room}] $OnOffValue{Value}

und der Slot "OnOffValue"
off
aus:off
zu:off
on
auf:on
an:on


Vorschlag zur Vorgehensweise wäre, das (gekürzt?) in die cref zu übernehmen und dann kenntlich zu machen, was getestet ist und was nicht (ggf. der ungetestete Teil einfach hinten dranpappen? Und bei den intents dann die getestete Variante?).
Feedback bzw. Rückmeldung von Usern zu einzelnen Teilen ist willkommen, und falls jemand weiß, wie bzw. ob man die sentences.ini irgendwie optimieren kann bzgl. der Reihenfolge der Einzelteile oder innerhalb eines intents: her damit...!

Anders gesagt: Man muss es nicht mögen, aber (englische) cref hat (entsprechend der in FHEM geltenden Konventionen) Prio vor allem anderen. Heißt aber mAn. nicht, dass die sentences englisch sein müßten, die sind ja "fast selbsterklärend" bzw. auch woanders gut dokumentiert; hier geht es nur darum zu zeigen, was FHEM eigentlich derzeit versteht.
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

Die Doku wird seeeeehr lang. Deswegen möchte ich das alles eigentlich nicht in der CRef haben. Die ist unübersichtlich und schlecht zu handhaben. Finde ich. Und schnell mal etwas ausbessern geht auch nur schwer, sollte das Modul mal ins SVN wandern.

Und alles Rhasspy-spezifische (Sentences, etc.) gehört eigentlich nicht in die CRef.

Mein Plan von Anfang an war:

CRef: Kurze Beschreibung, DEF+SET+ATTR+wichtige Hinweise+kurzes Beispiel
GitHub: Wie CRef + genaue Erklärung + Beispiele
(Wiki: mehr Beispiele + Tipps&Tricks)