Modulentwicklung für Rhasspy Sprachassistent

[Cordula]

Shortcuts mit Confirmation funktionieren bei mir jetzt auch. Nach dem shortcut/erste Frage wird bei voiceResponse ein Hash angezeigt. Nach der Confirmation die richtige Antwort.

Der Timer-Intent funktioniert bei mir einwandfrei. Hier noch eine Ergänzung für die Sentence.ini.

Code Auswählen Erweitern


# Timer auf eine viertel/halbe/dreiviertel Stunde
\[<labels>{Label}] [in|im|in der|auf der] [$de.fhem.Room{Room}] (in|auf) ((eine viertel){Min:15}|(eine halbe){Min:30}|(eine dreiviertel){Min:45}) (stunde|stunden)

# Timer auf eine viertel/halbe/dreiviertel Minute
\[<labels>{Label}] [in|im|in der|auf der] [$de.fhem.Room{Room}] (in|auf) ((eine viertel){Sec:15}|(eine halbe){Sec:30}|(eine dreiviertel){Sec:45}) (minute|minuten)


[Beta-User]

Vermutlich habe ich die Ursache für den übergangsweisen Hash identifiziert, der sollte mit dem Anhang der Vergangenheit angehören.

Zur Erläuterung: Es wird neuerdings versucht, alle anderen intents zu deaktivieren, solange diese Anfrage läuft. Dazu muss aber in den Parameter etwas mehr als nur der reine Text => was zusätzlich ist, wird mit in einen Hash verpackt, und den habt ihr dann gesehen...

[drhirn]

Ich muss meinen Shortcut ändern. Ich hab seit Samstag dauernd ein unbändiges Verlangen nach Schweinsbraten

Shortcut:

Code Auswählen Erweitern


i="geh kochen" f="set Stehlampe on" n="Stehlampe" c="Magst du Schweinsbraten"


Sentences:

Code Auswählen Erweitern


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


Tut jetzt alles wie erwartet. Super! 

[drhirn]

Also, bei GetNumeric und desired-temp kann ich auch nur Positives berichten. In der rhasspy-de.cfg war in Zeile 72 nur ein kleiner Tippfehler bei Solltemperatur

[Beta-User]

 

Dann scheinen wir ja erst mal auf Stand zu sein? Dann wäre es an der Zeit, mal zu sammeln, wo denn grade noch mehr oder weniger bekannte "Baustellen" zu finden sind.

Erst mal die Shortlist:
- kein "match in room" bei GetNumeric
- "kind" und wie man es füllen könnte (mehr Dialoge)
- Bestätigungsdialoge - weitere Anwendungsfelder
- gDT: mehr und bessere mappings?
- Farbe und Farbtemperatur

Im Detail:
kein "match in room" bei GetNumeric

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)

Die Vermutung war leider nicht richtig, jedenfalls habe ich bisher keinen wirklich guten "Dreh" gefunden, um die zusätzliche Info zielsicher irgendwie reinzupacken. Klingt für mich danach, als müßte man ggf. einen etwas allgemeingültigeren Ansatz wählen, um Zusatz-Sätze oder ähnliches anzuflanschen.
Persönliche Prio: niedrig

"kind" und wie man es füllen könnte (mehr Dialoge)

Ich weiß jetzt auch nicht, wofür "kind" ist. Aber ich habe mal nachgefragt und werden dann berichten. Die Frage ist allerdings, ob man's überhaupt setzen kann.

Hast du mir da einen Link?
Im aktuellen Code ist teilweise eine "subType"-Logik angerissen, evtl. wäre es möglich, das irgendwie zusammenzubringen.

Ansonsten werde ich ggf. auch selbst mal da posten, nachdem das mit der Bestätigung ja jetzt bei allen funktioniert. Meine momentane Idee wäre, einen "all.fhem-labels"-slot vorab mit allen denkbaren Auswahlmöglichkeiten zu füllen (für Trainingszweche), und den dann dynamisch nur mit den Werten zu arbeiten, die im jeweiligen Auswahldialog eine Rolle spielen. Das könnte dann auch das "kein match in room"-Problem auf andere Weise lösen.
Bin aber noch nicht überzeugt, dass das die einzige Variante ist, die funktionieren kann und will nicht massive Code-Eingriffe vorschlagen, bevor das geklärt ist. Insbesondere geht mir das hier nicht aus dem Kopf:

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...

Persönliche Prio: schwierig, aber m.E. das vordringlichste der Dialog-Themen

Bestätigungsdialoge - weitere Anwendungsfelder
Wie bereits erwähnt: shortcuts war eigentlich nur die Spielwiese. Die nächste Frage wäre dann, wo es (optional!) dann noch möglich sein sollte.
MAn. vorrangig wären da die Themen SetOnOff(Group), (mit Abstand) gefolgt von den SetNumeric-Varianten.
Könnte mir vorstellen, dass es pro FHEM-Device eine Zeile in "specials" gibt mit dem Schlüsselwort "confirm:":

Code Auswählen Erweitern

attr <device> rhasspySpecials confirm:SetOnOff

Code Auswählen Erweitern

attr <device> rhasspySpecials confirm:SetOnOff=cmdOff
(Alle, oder eben nur eine Teilmenge)
Persönliche Prio: mittel

gDT: mehr und bessere mappings?
Hat zwei Teilaspekte:
- Zum einen sind die vorhandenen Mappings halt erst mal auf die Schnelle "zusammengestupft" und schon alleine deswegen ausbaufähig. Wer passenden Code hat, kann da laufend was beisteuern.
- Zum anderen sind (neben den mich nicht so "drückenden" Farbthemen) insbesondere "scene" und "media" interessant. Da habe ich mir mal angesehen, was denn da so an settern an diesen beiden "Großtypen" vorhanden ist, und - na ja - wie sage ich es: meine Fresse...
Da geht kaum was über einen Kamm zu schehren, und es gibt Überschneidungen. Mein Receiver kann z.B. auch Szenen, dafür eben kein "play" und "pause", und die Mainzone kann andere Dinge wie die sehr viel eingeschränktere Zone 2.

Die große Frage ist, wie damit umgehen. Meine aktuelle Idee wäre, "einfach" eine Art "generischer setter-Analyse" drüberlaufen zu lassen, also z.B. bei "media" dann zu schauen, ob "play" vorhanden ist (dann kommt das rhasspy-Mapping auch in den Hash), oder eben nicht (=> kein Eintrag im Hash), und das ganze dann eben für eine "typische" Auswahl an wichtigen Steuerungselementen.
Hat den Vorteil, dass man z.B. auch Szenennamen darüber erfahren könnte und gleich an Rhasspy übermitteln, aber den Nachteil, dass das ganze dann erst mal jemand machen muss...
Persönliche Prio: relativ hoch, aber auch da ist es so, dass ich mir nicht sicher bin, ob es nicht bessere Lösungen gibt. Weiter ist mir unklar, ob das in die derzeitigen RHASSPY-Kategorien alles auch reinpaßt (Szenen sind mit einiger Sicherheit ein neuer intent). Andererseits:

Fände ich ganz gut. Ich bilde meinen Lichtszene derzeit ja mit rhasspyChannels ab.

Ist evtl. für diesen Teilbereich auch eine Lösung, da Channels ja "alles"erlaubt. Aber man muss dann eben auch händisch ran...

Farbe und Farbtemperatur

Interessanter wäre - und deswegen habe ich wegen gDT im Code gefragt - ein Typ "colorlight" oder so. Um die Farbe des Lichts setzen zu können.

Zur Idee zusätzlicher dDT-Type hatte ich ja schon was geschrieben, aber bei Licht kommt m.E. noch das Zusatzproblem dazu, dass das ganze afaik kaum normiert ist, sobald man die halbwegs gesicherten Gefilde von on/off und pct/brightness hinter sich gelassen hat...
Persönliche Prio: Ist für mich persönlich eher unwichtig.

Fragen meinerseits:
- fehlt was auf der shortlist?
- wie seht ihr das? Angefangen bei der jeweiligen persönlichen Prio-Liste.
(- ist das obige überhaupt verständlich dargestellt...?)

[drhirn]

Pfuh, langer Beitrag. Versuche mal, zu antworten und hab schon auch noch ein paar kleine Punkte.

Zuerst muss ich aber sagen, dass ich bis 29. gerne eine Feature-Freeze hätte. Prio muss jetzt Testen, Testen, Bugfixing, Doku und Testen haben. Sonst muss ich immer von vorne anfangen mit meinen Tests.

Ad "kein "match in room" bei GetNumeric": Andere Alternative wäre: "Kein passendes Gerät gefunden". Fände ich schöner, als die derzeitige Lösung und wäre wahrscheinlich leicht zu lösen. Später können wir dann einen Dialog einbauen.

Bzgl. der "kind"-Sache kannst du gerne den Link haben. Es hat mir bis dato aber niemand geantwortet. https://community.rhasspy.org/t/what-is-slots-value-kind-for/2610
Ansonsten weiß ich gerade nicht, was du mit subtype vor hast und wofür wir das brauchen könnten.

Zu den Bestätigungsdialogen: Überhaupt keine Priorität für mich derzeit.

gDTs sind cool, da weiter zu bauen fände ich schon interessant. Da würde ich aber sagen, wir halten uns an die minimalen FHEM-Vorgaben was Setter betrifft. Für z.B. AV-Geräte gibt's ja das hier: https://wiki.fhem.de/wiki/DevelopmentGuidelinesAV. Unterstützt ein Gerät einen definierten Befehl nicht, Pech gehabt.
Lightscenes werden wir nicht abbilden können, weil wir ja nicht wissen, wie die heißen.

Bei Farbe und -Temperatur war ich eigentlich der Meinung, dass das auch in FHEM normiert ist. Kann mich da aber täuschen. Wir setzen einfach rgb (oder was halt Standard ist) und ct. Wenn's ein Gerät nicht kann, wieder Pech.

Ich hab am Anfang der 10_RHASSPY.pm noch ein paar Punkte:

• Wir brauchen eine schlauere Lösung, wie wir das Training bis nach dem Update der Slots/Sentences verzögern
• Änderung von rhasspyGroup öffnet im GUI ein textField-long. Nur textfield würde reichen
• Im GetOnOff Intent sollten wir State statt Status verwenden. Natürlich auch in den Sentences
• Den Intent Status hätte ich gerne in GetState umbenannt
• Wenn ich bei MediaChannels einen Kanal angebe, der nicht existiert, gibt's "da ist etwas schiefgegangen". "Diesen Kanal gibt es leider nicht" fände ich schöner. Kann ich aber eh gerade nicht nachvollziehen.
• Shorcuts:
  - Wäre dafür, dass wir "n" in "d" für device umbenennen
  - Beim ersten Aufruf eines Perl-Commands nach einem Neustart gibt das PERL WARNING: Use of uninitialized value $ret in pattern match (m//) at ./FHEM/10_RHASSPY.pm line 2399.
  - Außerdem funktioniert bei einem Perl-Kommand der "Longpoll" nicht, obwohl "n" angegeben ist
  
• Setze ich einen Timer auf 10:15, bekomme ich als Antwort die Sekunden/Minuten bis dahin. "Timer auf 10:15 gesetzt" wäre besser

Aber wie gesagt, alles keine Priorität für mich derzeit. Ich brauche nur dringend Unterstützung beim Testen.

[Beta-User]

Zuerst muss ich aber sagen, dass ich bis 29. gerne eine Feature-Freeze hätte. Prio muss jetzt Testen, Testen, Bugfixing, Doku und Testen haben.

Sehe ich auch so. Wenn, dann geht es vorrangig erst mal um Verbesserung der vorhandenen features.

Ad "kein "match in room" bei GetNumeric": Andere Alternative wäre: "Kein passendes Gerät gefunden". Fände ich schöner, als die derzeitige Lösung und wäre wahrscheinlich leicht zu lösen. Später können wir dann einen Dialog einbauen.

Habe die Stelle mal gemarkert, an der das einzubauen wäre. Wir bräuchten dann noch eine spezielle Rückmeldung dazu (ist easy) und den Willen, das auf die Art umzusetzen. Bin selbst unentschlossen, aber die Mehrheit scheint eher für "keine numerische Rückmeldung" zu sein. Was mir an der "keine Info"-Lösung nicht gefällt: sie gibt keine Alternative zur Auswahl. Das erscheint mir nicht als motivierend.

Bzgl. der "kind"-Sache kannst du gerne den Link haben. Es hat mir bis dato aber niemand geantwortet. https://community.rhasspy.org/t/what-is-slots-value-kind-for/2610

Thx; evtl. hänge ich mich da mit dran und versuche mal das dahinterliegende Problem zu erläutern.

Ansonsten weiß ich gerade nicht, was du mit subtype vor hast und wofür wir das brauchen könnten.

Ist im Moment auch nur ein diffuses Bauchgefühl, dass man "sowas" brauchen könnte. Schwierig zu erklären, wo das Bauchgefühl herkommt, ist nur nicht ganz selten eine gute Idee, es zu beachten...

Zu den Bestätigungsdialogen: Überhaupt keine Priorität für mich derzeit.

Nachvollziehbar.

gDTs sind cool, da weiter zu bauen fände ich schon interessant. Da würde ich aber sagen, wir halten uns an die minimalen FHEM-Vorgaben was Setter betrifft. Für z.B. AV-Geräte gibt's ja das hier: https://wiki.fhem.de/wiki/DevelopmentGuidelinesAV. Unterstützt ein Gerät einen definierten Befehl nicht, Pech gehabt.

Das "Problem" bei den "minimalen" FHEM-Vorgaben ist folgendes: Es sind keine "minimalen" setter, die immer da sind, sondern nur der zusammengefasste Konsens, wie diese setter heißen sollten WENN sie (funktional gesehen) vorhanden sind.
Die eigentliche Aufgabe ist also, nur das zu mappen, was auch da ist. Das rauszufinden, ist gar nicht so schwierig, getAllSets() liefert einem das frei Haus (oder jsonlist2 etc.).
Das wäre also eine Verbesserung innerhalb des bestehenden Codes .

Lightscenes werden wir nicht abbilden können, weil wir ja nicht wissen, wie die heißen.

Doch, wissen wir (bzw. können wir abfragen): mittels getAllSets(). Das Unschöne daran ist nur, dass das eher "technische" Namen sind, von denen wir nicht wissen, ob sie gut auszusprechen sind.

Bei Farbe und -Temperatur war ich eigentlich der Meinung, dass das auch in FHEM normiert ist. Kann mich da aber täuschen. Wir setzen einfach rgb (oder was halt Standard ist) und ct. Wenn's ein Gerät nicht kann, wieder Pech.

Wieder wie oben: es ist m.E. nicht zielführend, Kommandos zuzulassen, die effektiv doch nicht da sind. Und wenn sie da sind: rgb ist noch relativ eindeutig, aber auch da ist es afaik nicht immer in Großschreibung... Ganz davon abgesehen, dass wir dafür grade noch kein RHASSPY-Kommando/intent haben. Color ist "irgendwie anders".
Und der Wertebereich für CT ist afaik wirklich näherungsweise willkürlich, aber eine wissentschaftliche Analyse habe ich dazu nicht vorzuweisen. Auch hier: wir haben noch keine Kommandos/intents...

Ich hab am Anfang der 10_RHASSPY.pm noch ein paar Punkte:

Sorry, war mir entgangen, meine stehen kurz nach __END__...
- Training verzögern: Muss ich mir in Ruhe ansehen. Aber eigentlich haben wir ja die Rückmeldung, wenn updateSlots durch ist, oder? Es wir ja ein Reading gesetzt. Ergo müßte man an der Stelle dann auch ein (in dem vorherigen Aufruf gesetztes, ggf. verstecktes) Internal abfragen können.

(ungetestet, auf der RHASSPY-Seite) erledigt sollten sein:
- textField für rhasspyGroup;
- State statt Status und "GetState";
- (englische) fehlende Kanal-Meldung;
- Shortcuts:
-- d statt n;
-- initialized-Warning;

"Longpoll" muss ich mir ansehen.

"Timer auf 10:15": Kommt darauf an, wie lange es noch dahin ist. Die Rückmeldung in Sekunden/Minuten erfolgt nur, wenn die Zeit bis dahin eher kurz ist, und da finde ich persönlich das sehr viel intuitiver, wenn ich "klingelt in 10 Minuten" zurückbeckomme wie "... um 10:15 Uhr".
Klar, Geschmacksfrage, und über die Grenzsetzungen bei der jeweiligen Abgrenzung können wir uns gerne unterhalten, evtl. könnte man das sogar konfigurierbar machen. Das war ein erster Schuss, und genau deswegen hatte ich ja auch speziell zum Thema Timer immer wieder gefragt, ob das jetzt allgemein als "gut" angesehen wird...

[drhirn]

Zitat von: drhirn am Heute um 14:14:32

    Zuerst muss ich aber sagen, dass ich bis 29. gerne eine Feature-Freeze hätte. Prio muss jetzt Testen, Testen, Bugfixing, Doku und Testen haben.

Sehe ich auch so. Wenn, dann geht es vorrangig erst mal um Verbesserung der vorhandenen features.

Nicht mal das. Dann muss ich nur wieder von vorne testen.

Ad "kein "match in room" bei GetNumeric": Andere Alternative wäre: "Kein passendes Gerät gefunden". Fände ich schöner, als die derzeitige Lösung und wäre wahrscheinlich leicht zu lösen. Später können wir dann einen Dialog einbauen.

Habe die Stelle mal gemarkert, an der das einzubauen wäre. Wir bräuchten dann noch eine spezielle Rückmeldung dazu (ist easy) und den Willen, das auf die Art umzusetzen. Bin selbst unentschlossen, aber die Mehrheit scheint eher für "keine numerische Rückmeldung" zu sein. Was mir an der "keine Info"-Lösung nicht gefällt: sie gibt keine Alternative zur Auswahl. Das erscheint mir nicht als motivierend.

Ist es auch nicht. Aber für den Moment, denke ich, können wir damit leben.

gDTs sind cool, da weiter zu bauen fände ich schon interessant. Da würde ich aber sagen, wir halten uns an die minimalen FHEM-Vorgaben was Setter betrifft. Für z.B. AV-Geräte gibt's ja das hier: https://wiki.fhem.de/wiki/DevelopmentGuidelinesAV. Unterstützt ein Gerät einen definierten Befehl nicht, Pech gehabt.

Das "Problem" bei den "minimalen" FHEM-Vorgaben ist folgendes: Es sind keine "minimalen" setter, die immer da sind, sondern nur der zusammengefasste Konsens, wie diese setter heißen sollten WENN sie (funktional gesehen) vorhanden sind.
Die eigentliche Aufgabe ist also, nur das zu mappen, was auch da ist. Das rauszufinden, ist gar nicht so schwierig, getAllSets() liefert einem das frei Haus (oder jsonlist2 etc.).
Das wäre also eine Verbesserung innerhalb des bestehenden Codes .

Ah, das wusste ich nicht. Dann ab auf die ToDo-Liste

Lightscenes werden wir nicht abbilden können, weil wir ja nicht wissen, wie die heißen.

Doch, wissen wir (bzw. können wir abfragen): mittels getAllSets(). Das Unschöne daran ist nur, dass das eher "technische" Namen sind, von denen wir nicht wissen, ob sie gut auszusprechen sind.

Ja, das auch. Könnte man aber auch dem User überlassen, die hübsch zu benennen.

Sorry, war mir entgangen, meine stehen kurz nach __END__...

Oh, die hab ich übersehen

- Training verzögern: Muss ich mir in Ruhe ansehen. Aber eigentlich haben wir ja die Rückmeldung, wenn updateSlots durch ist, oder? Es wir ja ein Reading gesetzt. Ergo müßte man an der Stelle dann auch ein (in dem vorherigen Aufruf gesetztes, ggf. verstecktes) Internal abfragen können.

Stimmt, das Reading wäre da. Egal, keine Priorität. Die jetzige Lösung funktioniert ja.

- textField für rhasspyGroup;

Leider nicht

- State statt Status und "GetState";

- (englische) fehlende Kanal-Meldung;

Kann ich nicht mehr testen. Rhasspy liefert immer einen existierenden Kanal, egal was ich sage. Weiß nicht, warum plötzlich.

- Shortcuts:
-- d statt n;
-- initialized-Warning;

"Timer auf 10:15": Kommt darauf an, wie lange es noch dahin ist. Die Rückmeldung in Sekunden/Minuten erfolgt nur, wenn die Zeit bis dahin eher kurz ist, und da finde ich persönlich das sehr viel intuitiver, wenn ich "klingelt in 10 Minuten" zurückbeckomme wie "... um 10:15 Uhr".

Ahhhh, dachte mir doch, das ist nicht ganz konsistent. Jetzt weiß ich auch, warum.

Klar, Geschmacksfrage, und über die Grenzsetzungen bei der jeweiligen Abgrenzung können wir uns gerne unterhalten, evtl. könnte man das sogar konfigurierbar machen. Das war ein erster Schuss, und genau deswegen hatte ich ja auch speziell zum Thema Timer immer wieder gefragt, ob das jetzt allgemein als "gut" angesehen wird...

ToDo-Liste

[Beta-User]

Ah, das wusste ich nicht. Dann ab auf die ToDo-Liste

Nur nicht hetzen...!

Ja, das auch. Könnte man aber auch dem User überlassen, die hübsch zu benennen.

Na ja, bei meinem Receiver geht das schon mal nicht, jedenfalls, wenn ich das Handbuch richtig gelesen habe.
Und "sprechbare" Szenennamen hätten vermutlich häufig auch Leerzeichen drin. Das geht dann vermutlich auch nicht so einfach...

Leider nicht

Ähm, vermutlich, weil das Attribut in der global-Liste drin steht; einmal drin, immer drin. Für "neue" sollte es jetzt aber passen.

Kann ich nicht mehr testen. Rhasspy liefert immer einen existierenden Kanal, egal was ich sage. Weiß nicht, warum plötzlich.

Na ja, vermutlich war das Training erfolgreich, und du musst den slot manuell "kaputt" machen...

Ahhhh, dachte mir doch, das ist nicht ganz konsistent. Jetzt weiß ich auch, warum.
ToDo-Liste

Was genau? Bzw. wie soll es genau sein?

[drhirn]

Ahhhh, dachte mir doch, das ist nicht ganz konsistent. Jetzt weiß ich auch, warum.
ToDo-Liste

Was genau? Bzw. wie soll es genau sein?

Naja, manchmal hat mir Rhasspy Sekunden ausgegen, manchmal die Uhrzeit. Also wie von dir geplant. Wusste das nur nicht.

Verbesserungen daran auf die ToDo-Liste. Mir persönlich würde es besser gefallen, wenn ich bei einem Timer mit Uhrzeit auch die Uhrzeit zurück bekomme. Aber ich richte mich nach der Mehrheit. Bzw. bei einem 1:1 nach dir

[Beta-User]

Na ja, das "Problem" ist, dass man sich bei "absoluten" Angaben dann merken müßte, dass es eine solche war und das entsprechend gesondert behandeln. Im Moment wird "stumpf" die Differenz betrachtet.

Aber eigentlich finde ich die kleine Irritation wegen der "anderen" Rückmeldung ganz ok, weil man damit auch mitbekommt, wenn es "gleich" ist (was man ggf. gar nicht gedacht hatte).
Aber wenn es Wünsche gibt, das konfigurierbar zu machen, schaue ich mir das bei Gelegneheit mal im Detail an; an sich sollte sich das ggf. sogar getrennt konfigurieren lassen. ("tweaks"...)

[drhirn]

Na ja, das "Problem" ist, dass man sich bei "absoluten" Angaben dann merken müßte, dass es eine solche war und das entsprechend gesondert behandeln. Im Moment wird "stumpf" die Differenz betrachtet.

Wir hätten ja "Hourabs"

Aber eigentlich finde ich die kleine Irritation wegen der "anderen" Rückmeldung ganz ok, weil man damit auch mitbekommt, wenn es "gleich" ist (was man ggf. gar nicht gedacht hatte).
Aber wenn es Wünsche gibt, das konfigurierbar zu machen, schaue ich mir das bei Gelegneheit mal im Detail an; an sich sollte sich das ggf. sogar getrennt konfigurieren lassen. ("tweaks"...)

Es ist sowas von gar nicht wichtig. Wenn dir mal langweilig ist.

[Beta-User]

Sodale...

Jetzt sollte das Training erst anlaufen, wenn der slot-update als erfolgreich zurückgemeldet wird.

Timer habe ich mir auch angesehen und ein bißchen was vorbereitet:
Die Zeiten stecken jetzt in einem Array (#3172), das man ggf. dann mit einem aus der User-Späre vergleichen könnte. 4 Elemente wären als Zeitgrenzen gedacht: 0-3 entsprechen den Grenzen für die Stufen 0-3 aus "timerSet" (Sprach-Hash), Element 4 wäre die Grenze (in Sekunden), ab wann die Uhrzeit statt der "Zeit bis" angesagt werden würde.
Derzeitige Grenzen:

Code Auswählen Erweitern


my @timerlimits = $hash->{helper}->{timerLimits} // (101, 9*MINUTESECONDS, HOURSECONDS, 3*HOURSECONDS,3*HOURSECONDS );

[drhirn]

Weil im Demo-FHEM auch ein sunRise Device vorkommt, dachte ich mir, das wäre eigentlich ein guter Anschauungspunkt für Shortcuts.

Bekommen wir das hin, dass so ein Shortcut funktioniert?

Code Auswählen Erweitern

i="wann geht die sonne auf" f="" r="um [Astro:sunRise] uhr"

Derzeit wird mir die Response einfach vorgelesen (voiceResponse: um [Astro:sunRise] uhr).

[drhirn]

Bzgl. rhasspyGroup und textfield-long

Ähm, vermutlich, weil das Attribut in der global-Liste drin steht; einmal drin, immer drin. Für "neue" sollte es jetzt aber passen.

Was meinst du mit "neue"? Neue FHEM-Installationen?
Ich hab nämlich gerade ein neues Device angelegt und hab noch immer das textfield-long.