[Rhasspy] on-for-timer Umsetzung?

[Raemsna]

Hallo zusammen,

ich nutze Rhasspy in meinen persönlichen Anfangsschuhen und spiele aktuell gerne an den Implementierungen verschiedener Devices.

Frage:
ist eine "direkte" Umsetzung eines on-for-timer Commands möglich, ähnlich SetOnOff?

Oder ist es aktuell nur "über Umwege" eines at oder notify o.Ä. möglich?
Ich stelle mir vor, verschiedene Geräte per Sprachbefehl für eine bestimmte Zeit einzuschalten.

Vielen Dank für die Hilfe.
und Tausend Dank für die tolle Rhasspy Implementierung und Doku!!

Grüße
Raemsna

[drhirn]

Ist aktuell nur über Umwege möglich. Aber ich nehme das gerne als Feature Request auf.

[Beta-User]

...jetzt wollte ich auch grade eine lange Liste von Fragen dazu schreiben...

"An sich" sollte das gehen, aber einen völlig freien "mach {Device} für 10 Stunden, 32 Minuten und 10 Sekunden an"-Intent (oder "... bis um 12 Uhr 15") zu kreieren ist nicht ganz so einfach, beide "Steinbrüche" (SetTimer und SetOnOff) sind für sich genommen schon nicht die einfachsten, und das zu verheiraten dementsprechend schwierig.

Würde gerne aber gleich noch ein paar Fragen/Anmerkungen dazu loswerden wollen:
- geht es "nur" um "on-for-timer", oder reden wir auch über "off-for-timer" und ähnliches?
- Wie wollen wir das Set-Kommando umsetzen? Eigentlich müsste ausgewertet werden, ob "das Zielobjekt" den Timer (ggf. via SetExtensions) verwalten kann, oder ob RHASSPY das übernehmen muss...
- Wer sich dranwagen will, das zu vercoden: Eigentlich müßte das Modul jetzt auch schon soweit vorbereitet sein, dass man das über myUtils-Code austesten kann...
- Ist es ggf. so, dass "eigentlich" (bei Schaltung über RHASSPY) immer ein "TimedOn" gemeint ist, wenn ein bestimmtes Gerät eingeschaltet werden soll?
- Wenn ja: Immer für dieselbe Dauer?

(Ja auf Die letzten beiden Fragen wären eher was für "specials").

Bestimmt fällt mir noch mehr ein, aber das Thema ist mal richtig schwierig und dementsprechend interessant...

[drhirn]

Ich hätte mir gedacht, das Gerät muss es können, RHASSPY liefert nur die Dauer. Sonst müsste man das Rad nochmal erfinden.

[Beta-User]

Ich hätte mir gedacht, das Gerät muss es können, RHASSPY liefert nur die Dauer. Sonst müsste man das Rad nochmal erfinden.

...wünsch dir was...
(Die ersten beiden, die es austesten, werden solche sein, die entweder a) das mit dummy versuchen , oder b) einen Tasmota unter MQTT_DEVICE (oder dem Tasmota-Modul) betreiben => man muss da SetExtensions aktiv anschalten, wenn die das überhaupt "können"...)

"Gut" ist eine Lösung mAn. erst, wenn wir zumindest rückmelden können, dass das Zielobjekt es nicht kann (was mit getAllSets() kein Hexenwerk ist)...

[drhirn]

"Gut" ist eine Lösung mAn. erst, wenn wir zumindest rückmelden können, dass das Zielobjekt es nicht kann (was mit getAllSets() kein Hexenwerk ist)...

Hab nichts anderes gesagt

Und außerdem: Was du immer mit den Dummies hast...
(Hast du eine bessere Idee für ein Testsystem ohne Hardware?)

[Beta-User]

Und außerdem: Was du immer mit den Dummies hast...

ca. 90% der dummy-Devices, die v.a. im Anfängerbereich des Forums so rumfliegen, sind mAn. überflüssig und dahingehend "schädlich", dass sie grade bei Anfängern den Eindruck erzeugen, FHEM sei kompliziert (was es wird, wenn man Infos ständig unnötig umpackt und versucht, alles händisch synchron zu halten...)

(Hast du eine bessere Idee für ein Testsystem ohne Hardware?)

Nope. Aber praktisch JEDE real schaltbare Hardware ist besser als ein dummy, daher war meine Empfehlung neulich auch: Nimm irgendwas (mit einer bestimmten Priorisierung). Für die Doku würde ich sagen: je exotischer, desto besser... (dann kommt man nicht auf die Idee, es 1:1 zu kopieren )

[Raemsna]

Ich hätte mir gedacht, das Gerät muss es können, RHASSPY liefert nur die Dauer. Sonst müsste man das Rad nochmal erfinden.

Genauso wäre meine "Erwartungshaltung" gewesen.
Ich habe bspw. einen Haufen Homematic Wired Geräte, die mit setExtensions arbeiten können (ich persönlich nutze eigentlich nur on-for-timer, wäre für mich auch der gängigste Anwendungsfall, also zB Schalte die Wasserpumpe für x Minuten an).
Aber auch viele andere Geräte oder Dummys können ja mit on-for-timer was anfangen.

Falls es natürlich zu kompliziert wird, geht es sicher auch über Umwege..

Danke für die Hilfe!!
Raemsna

[Ziton]

Da ich den Thread grade zufällig gelesen habe meine spontane Idee dazu.
Verzeiht mir falls ich mir das zu einfach denke oder diverse Fallstricke nicht erkenne.

Wäre es ggf. möglich für diesen Anwendungsfall eine Kombination aus vorhandenem und neuen Befehl zu generieren?
Im Detail dachte ich daran das vorhanden SetOnOff zu nutzen um das Gerät einzuschalten und im zweiten Schritt ein "at"- Device zu definieren um es nach
mitgelieferter Zeit wieder auszuschalten.

Somit müsste das Ziel Device noch nicht mal zwingen on-for-timer beherrschen und es wäre im umgekehrten Fall auch "off-for-timer" möglich.

[Beta-User]

OK, halten wir fest: Es gibt größeres Interesse an einem generalisierten "on-for-timer"-Intent...

Das Erkennen, ob ein Gerät "on-for-timer" kann oder nicht (und ggf. auch "off-for-timer") ist nicht besonders schwierig.

Viel schwieriger ist aber, dazu noch eine eigene Timerverwaltung zu bauen und - und da sehe ich das eigentliche Problem - dann noch sicherzustellen, dass sich das nicht mit anderen Steuerungsmechanismen ins Gehege kommt.

Beispiel: Mann zu Rhassy: "Licht für 30 Minuten an" => Licht an, at anlegen, Mann geht in den Keller, Frau hat zwischenzeitlich das Licht ausgeschalten, hört aber, dass Mann mit einer schönen Flasche Wein aus dem Keller kommt und schaltet daher das Schummerlicht wieder ein.
=> was passiert mit dem at...?

Kurz: der Timer gehört auf dem "üblichen Weg" so nah an das Gerät, wie es geht, und lieber soll dann mal die Rückmeldung kommen, dass was nicht geht, wie dass beim Einschenken der gute Tropfen mangels Licht (oder wegen heftiger Lachanfälle) nicht im Glas landet...

Ich schau's mir  an, eigentlich sollte das ganze nicht so schwierig sein, wenn man Code-Teile recycelt; schwieriger wird eventuell das Vermeiden von Erkennungs-Überschneidungen mit der (allgemeinen) Timer-Geschichte. Möglicherweise muss man sich für das eine oder andere entscheiden oder "keywords" in die sentences aufnehmen.

[Beta-User]

Fyi: den "single" TimedOnOff-Intent habe ich gestern "kurz" in die Testversion eingebaut: https://forum.fhem.de/index.php/topic,119447.msg1159007.html#msg1159007, das war überraschend unaufwändig und funktioniert auch bei weiter aktiviertem "Timer"-Intent ganz gut.
Tendiere dazu, die entsprechende Gruppenfunktion auch noch zu implementieren - da sollte dann aber ins Log geschrieben werden, wenn Devices das nicht können...

Was gut wäre: ich habe nur einen kurzen Test gemacht, und auch nur den einen Satz in sentences.ini getestet. Die Auswertung ist aber im Prinzip gleich wie beim Timer-Intent, so dass auch "Mach das Radio bis um 12 Uhr 30 an" usw. funktionieren sollte, wenn man das entsprechend übergibt.

EDIT: da habe ich noch einen bug gefunden, update gibt's dann zusammen mit der "group"-Variante nach dem Test. Und leider ist mir auch eine Vorversion reingerutscht, die noch viel zu lange Laufzeiten berechnet...