Rhasspy, mein Weg zu neuen Ufern: es läuft

Begonnen von Gisbert, 19 November 2021, 23:08:07

Vorheriges Thema - Nächstes Thema

Beta-User

#45
Hi Gisbert,

:) vorab mal Danke für die Rückmeldung, dass du jetzt "Erfolg" melden konntest!
Es war vermutlich für uns beide erst mal etwas frustrierend, dass du unbedingt das "schwerstmögliche Device" per Sprache steuern wolltest, und nicht auf meinen Vorschlag (via Wiki gemacht) eingegangen bist, erst mal noch mit ein paar Lichtern usw. zu experimentieren.

(Für mich ist das nicht so schlimm, weil ich dadurch eben noch ein paar Lücken füllen konnte, die mit "normalen" Devices gar nicht entstehen...).

Zitat von: Gisbert am 29 November 2021, 14:09:46
Hallo Jörg,
- ist damit gemeint, dass möglichst viele Varianten in einer Zeile abgehandelt werden sollen?
Nein, nicht ganz. Ich würde das eher so formulieren:
"Wenn möglich, sollten in einer Zeile alle sinnvoll zusammenpassenden Varianten abgehandelt werden, und zwar so, dass möglichst auch nur die FHEM-Devices genannt sind, die mit der entsprechend erkannten Anweisung auch was sinnvolles anfangen können!"

Wirft man alles in einen Topf, wird Rhasspy zwar auch ein Ergebnis liefern, aber RHASSPY kann das dann nicht umsetzen. Beispiel:
"Färbe {Device} schwarz" macht nur Sinn für Geräte, die in der Lage sind, sich einzufärben. Man kann zwar auch einen Rollladen so hinbiegen, dass er aus "schwarz" mit "geschlossen" reagiert, aber sinnvolle Sprachanweisungen sehen nach meinem persönlichen Geschmack eben anders aus. Daher würde ich obige Anweisung immer über den slot "$de.fhem.Device-light" einschränken.

Anweisungen wie "auf" und "zu" passen nur auf Rollläden, Schlösser und Fenster&Türen (so jeweils automatisch betrieben) => nur die slots ($de.fhem.Device-blind|$de.fhem.Device-lock) in den Satz bauen. (Ich bin damit auch noch nicht ganz fertig, sonst wäre es einfacher...)

EDIT:
MAn. macht es daher Sinn, die Fahrbefehle in eine extra Zeile zu nehmen, etwa so:
[de.fhem:SetOnOff](schalte|schalt|mache|mach|stelle|stell) [den|die|das] $de.fhem.Device-SetOnOff{Device} [(im|in dem|auf dem|in der|auf der) $de.fhem.Room{Room}] ((an|ein){Value:on}|aus{Value:off})
(mache|mach|fahre|fahr) [den|die|das] $de.fhem.Device-blind{Device} [(im|in dem|auf dem|in der|auf der) $de.fhem.Room{Room}] ((hoch|auf){Value:on}|(zu|runter){Value:off})

Damit kann es zwar immer noch sein, dass ein Rollladen "ein"-geschaltet wird, aber mit "hoch" und "runter" erwischt man wirklich nur nur diese Geräte und hat dann auch wieder Optionen, dass es nicht zu sehr ins Gehege kommt mit "dimme das licht runter"...




Jetzt noch was zu den (rhasspy-) Names:
Auf dem screenshot der App ist zu erkennen, dass der betreffende Rollladen "rollladen schlafzimmer felix" heißt. Das ist m.E. nicht zu empfehlen, sondern die beiden Infos "Rollladen" und "Schlafzimmer Felix" sollten an der richtigen Stelle hinterlegt werden.

Das bedeutet: rhasspyName für beide Rollläden ist einfach "rollladen", rhasspyRoom ist dann entweder (ggf. u.a.) "schlafzimmer von felix,felix zimmer" und "schlafzimmer von gisbert,schlafzimmer,meinem schlafzimmer" (OT an mich selbst: siteId2person und/oder wakeword2person?).

Dann weiß RHASSPY, was passieren soll, wenn du mit "Mach den Rollladen in meinem Schlafzimmer zu" meinen könntest, und du kannst das "felix" weglassen, wenn die Info von einem Satelliten kommt, der sich in seinem Zimmer befindet (oder mit site2room dahin "beordert" wurde).
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

Beta-User

Vielleicht noch ein weiterer Nachtrag zu der Sache mit den eingeschränkten slots. Hier mal mein (vermutlich auch noch optimierungsfähiger!) Satz von MediaControls-Sätzen:
[de.fhem:MediaControls]
( (stoppe|stop){Command:cmdStop} | (starte|start){Command:cmdPlay} ) [die wiedergabe] [am] [$de.fhem.Device-media{Device}] [[im] $de.fhem.Room{Room}]
(pausiere | halte ){Command:cmdPause} [die wiedergabe] [am] [$de.fhem.Device-media{Device}] [[im] $de.fhem.Room{Room}] [an]
(nächstes|nächster){Command:cmdFwd} (lied|titel) [[(am|auf dem)] $de.fhem.Device-media{Device}] [[im] $de.fhem.Room{Room}]
(vorheriges|voriges|vorheriger|voriger){Command:cmdBack} (lied|titel) [$de.fhem.Device-media{Device}] [[im] $de.fhem.Room{Room}]

Da gäbe es ggf. Überschneidungen mit dem SetNumeric-stop-Kommando für die blind-Geräte, wenn jeweils nur ein "allgemeiner" {Device}-slot verwendet würde. So sollte das aber parallel klappen ;) .
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

Gisbert

Hallo Jörg,

vielen Dank für die ergänzenden Erklärungen, es wird damit weiter deutlich für mich, worauf es ankommt. Ich versuche dann ab nächstem WE die Vorgaben umzusetzen. Erst muss ich die nächsten Tage beruflich ausfüllen und bin dafür unterwegs.

Viele​ Grüße​ Gisbert​
Aktuelles FHEM | PROXMOX | Fujitsu Futro S740 | Debian 12 | UniFi | Homematic, VCCU, HMUART | ESP8266 | ATtiny85 | Wasser-, Stromzähler | Wlan-Kamera | SIGNALduino, Flamingo Rauchmelder FA21/22RF | RHASSPY

htschors

Hallo,

ist es ok, wenn ich mich mit einer Frage an diesen Thread hänge? Ich denke es ist vielleicht übersichtlicher als ein neues Thema aufzumachen. Ich habe rhasspy gestern bei mir eingerichtet und soweit funktionieren die Basics wie im Wiki beschrieben. Leider kann ich allerdings keine Devices schalten. Ich denke die Ursache ist, dass in der devicemap keine Kommandos für SetOnOff aufgeführt sind. Ich verstehe aber nicht, warum das so ist. Ich habe für ein paar Schalter probehalber den GenericDeviceType auf light und switch gestellt und die devicemap aktualisiert. Könnt ihr mir helfen, woran es liegen kann?

devicemap:
       Channels:
       Colors:
       devices:
         Licht_KUE:
           alias      licht
           names      licht
           rooms      küche,logo
           intents:
         Licht_KZ:
           alias      licht
           names      licht
           rooms      kinderzimmer,logo
           intents:
         Test_Licht:
           alias      licht
           names      licht
           rooms      dummy
           intents:
         Test_Schalter:
           alias      schalter
           names      schalter
           rooms      dummy
           intents:
       rhasspyRooms:
         dummy:
           licht      Test_Licht
           schalter   Test_Schalter
         kinderzimmer:
           licht      Licht_KZ
         küche:
           licht      Licht_KUE
         logo:
           licht      Licht_KZ

Beta-User

Hast du mal ein list von einem der Geräte?
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

htschors

Der ist zum Schalten des Lichts. Ist bisschcen speziell, da die Steuerung im Haus mit einer Siemens Logo gemacht wird und ich micht mit FHEM da drauf setze.

Internals:
   ADDRESS    1076
   AREA       db
   DATATYPE   u16
   DB         0
   DEF        AQ3
   FUUID      61799ee7-f33f-8c9f-d565-5b8e7eb25b2e2b07
   IODev      UG_Logo1
   LASTInputDev UG_Logo1
   LENGTH     2
   MSGCNT     81232
   NAME       Licht_KUE
   NR         47
   STATE      0
   TYPE       S7_ARead
   UG_Logo1_MSGCNT 81232
   UG_Logo1_TIME 2021-11-30 22:13:21
   READINGS:
     2021-11-29 21:33:52   IODev           UG_Logo1
     2021-11-30 22:13:21   state           0
Attributes:
   IODev      UG_Logo1
   alias      Licht
   genericDeviceType light
   room       Küche,Logo
   userattr   S7_ARead S7_ARead_map structexclude


Dann noch zwei Dummys die ich angelegt habe um einen einfacheren Weg zur Verbindung mit Rhasspy zu finden:

Internals:
   CFGFN     
   FUUID      61a54258-f33f-8c9f-7905-e77f311ee59bc1c6
   NAME       Test_Schalter
   NR         555
   STATE      TRIGGER
   TYPE       dummy
   READINGS:
     2021-11-29 22:16:19   state           TRIGGER
Attributes:
   alias      Schalter
   genericDeviceType switch
   room       Dummy
   webCmd     on:off:TRIGGER


Internals:
   CFGFN     
   FUUID      61a66589-f33f-8c9f-1be0-fc73512c5753262b
   NAME       Test_Licht
   NR         11496
   STATE      ???
   TYPE       dummy
Attributes:
   alias      Licht
   genericDeviceType light
   rhasspyMapping attr Test_Licht rhasspyMapping SetOnOff:cmdOn=TRIGGER,cmdOff=TRIGGER,response="All right"

   room       Dummy

Beta-User

Versuch's mal mit folgendem rhasspyMapping:
attr Licht_KUE rhasspyMapping SetOnOff:cmdOn=1,cmdOff=0
Das sollte funktionieren, wenn der Einschaltbefehl in FHEMWEB "set Licht_KUE 1" ist.

Ansonsten bitte ein "{getAllSets('Licht_KUE')}" zeigen.

Vielleicht bei der Gelegenheit ein paar weitere allgemeine Hinweise - ich unterstelle mal, dass die auch im Sinne von Gisbert sind:
- ist gDT gesetzt, analysieren RHASSPY, was obiger Befehl liefert. Paßt das zu einer RHASSPY "bekannten" Auswahl an Möglichkeiten, werden die entsprechenden Werte automatisch gesetzt. Wenn nicht, passiert das, was hier (und bei dem speziellen Rollladen) der Fall war: Es wird im RHASSPY-list nichts angezeigt oder eben nur eine kleinere Auswahl der eigentlichen Möglichkeiten.
Dann muss man halt manuell eingreifen, aber auch da hat man ziemlich viele Möglichkeiten, das passend zu machen.
- dummy "dazwischenzubasteln" ist ganz generell keine gute Idee, (jedenfalls, wenn es um die direkte Steuerung von Hardware geht,) und für RHASSPY schon gleich gar nicht erforderlich. Deswegen bitte ich auch eventuelle Mitleser, davon abzusehen zu erläutern, wie man das hinbiegt!
- wenn ein "Intermediär" sinnvoll sein sollte, dann ggf. ein "readingsProxy": Dem kann man dann zum einen "bekannte Befehle" verpassen, und zum anderen bringt er "SetExtensions" mit, so dass dann auch "on-for-timer" & Co. zur Verfügung stehen ;) . Und zwar ohne, dass man mit irgendwelchen Verrenkungen versuchen müßte, von der Steuerung kommende Werte irgendwie wieder in den dummy zu verfrachten, um eine sinnvolle Anzeige zu bekommen.
(Kann sein, dass das Modul "S7_ARead" sowas auch kann, wenn man es "fertig" konfiguriert; das habe ich jetzt nicht untersucht, wäre m.E. dann aber readingsProxy vorzuziehen, wenn es geht...).
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

Beta-User

Nachtrag: Habe etwas an der automatischen Befehlserkennung nachjustiert. Falls du es verschmerzen kannst, mit einer etwas experimentellen Version zu hantieren, wäre der Code in https://forum.fhem.de/index.php/topic,119447.msg1190437.html#msg1190437 zu finden (bzw. ggf. schauen, ob es noch was neueres gibt). Dann könnte es uU. auch direkt klappen, ohne dass du manuell eingreifen mußt ;) .
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

Beta-User

#53
Noch ein Nachtrag...

Wenn ich die Doku von S7_ARead zutreffend interpretiere, ist Licht_KUE eigentlich ein read-only Datenpunkt, und der Schreibbefehl muss wo ganz anderes hin... Ich würde daher mal versuchen, die beiden Teil-Elemente Licht_KUE/S7_ARead und (Namen bitte anpassen) Licht_KUE_out/S7_AWrite so zusammenführen, dass sie sich über ein einziges Device repräsentieren lassen.

Das könnte so klappen:
defmod rp_Licht_KUE readingsProxy Licht_KUE
attr rp_Licht_KUE setFn { my $do =$CMD eq 'on' ? 'ON' : 'OFF';; fhem("set Licht_KUE_out $do") }
attr rp_Licht_KUE setList on off
attr rp_Licht_KUE valueFn { !$VALUE ? "off" : "on" }

Unterstellt das klappt so, müßte das auch mit der von dir genutzten RHASSPY-Version mittels gDT "switch" als schaltbares Device erkannt werden...
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

TomLee

Sry, kurze Zwischenfrage, les nur nebenbei mit.

Ich kann hier nicht folgen mit dem angehängten _out, ist das nur "dazwischengerutscht" ?

Zitatdefmod rp_Licht_KUE readingsProxy Licht_KUE
attr rp_Licht_KUE setFn {fhem("set Licht_KUE_out ". ($CMD eq "on")? "ON" : "OFF" ) }
attr rp_Licht_KUE setList on off
attr rp_Licht_KUE valueFn { !$VALUE ? "off" : "on" }

Wenn "dazwischengerutscht" dann mein ich brauchts das fhem("set Licht_KUE " in setFN nicht:

Zitatdefmod rp_Licht_KUE readingsProxy Licht_KUE
attr rp_Licht_KUE setFn {($CMD eq "on")? "ON" : "OFF"}
attr rp_Licht_KUE setList on off
attr rp_Licht_KUE valueFn { !$VALUE ? "off" : "on" }

Wenn ich da mit dem Licht_KUE_out danebenliege und total überlese, den Beitrag einfach ignorieren.

Beta-User

Zitat von: TomLee am 01 Dezember 2021, 15:20:46
Ich kann hier nicht folgen mit dem angehängten _out, ist das nur "dazwischengerutscht" ?
Danke für die Zwischenfrage, scheinbar hatte ich das nicht deutlich genug hervorgehoben. Es ist tatsächlich Absicht, dass hier ein ganz anderes Device adressiert wird, weil bei S7 ganz unterschiedliche Geräte in Sende- und Empfangsrichtung genutzt werden, und man das erst "verknüpfen" muss, damit ein bedienbares Gerät entsteht. Sonst könnte das schon mit der neuen Version von RHASSPY direkt abgefackelt werden, aber "sidekicks" sind damit nicht möglich...

Das war mit "und (Namen bitte anpassen) Licht_KUE_out/S7_AWrite" gemeint gewesen (es war aus den bereitgestellten Daten afaik noch nicht zu erkennen, wie das Device zum Schreiben heißt, daher hatte ich einen Namen erfunden).

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

htschors

Hallo Beta-User,

erst einmal eine kurze Rückmeldung zur Logo. Vielen Dank für die proaktiven Beiträge :) Das war tatsächlich auch eine Frage, welche ich mir gestellt hatte. Ich bin noch ziemlich an der Oberfläche unterwegs und übernehme bisher meistens nur die Grundfunktionen aus dem Wiki oder Beispielen. Es war ein Fehler von mir, wie du richtig erkannt hast war das Device zum Lesen des Zustands. Zum Schalten habe ich 3 weitere Schalter pro Lampe (!), welche jeweils einem Netwerkeingang der Logo zugeordnet sind - ein, aus und automatisch (über Bewegungsmelder). Siehe Bilder. Ziemlich umständlich. Das wäre dann zum Ein- und Ausschalten über Rhasspy auch entsprechend kompliziert geworden. Ich schaue es mir jetzt mal an, wie ich den Schalter aus mehreren Devices zusammenfügen kann und dann schaue ich mir deine anderen Hinweise bzgl. Rhasspy an. Danke erst mal. Ich melde mich noch mal..


Beta-User

Falls wir hier nicht weiterkommen, wäre es vermutlich das beste, einen separaten Thread aufzumachen und erst mal ein funktionales Device zu basteln. Aus den Bausteinchen würde ich jetzt aber vermuten, dass dir zum einen entgangen war, dass ich den Ausgangsvorschlag nochmal geändert hatte. Aus irgendeinem Grund mochte readingsProxy das Zusammenziehen des Kommandos am Ende nicht, es scheint aber zu klappen, wenn man erst die Teile ermittelt.

Falls ich das richtig verstanden habe, hast du an der SPS verschiedene Eingänge für Ein und Aus, die jeweils mit einem "TRIGGER"-Kommando angesprochen werden. Das ergäbe (RAW-DEF):
attr rp_Licht_KUE setFn { my $dev = $CMD eq 'on' ? 'Licht_KUE_ein' : 'Licht_KUE_aus';; fhem("set $dev TRIGGER") }
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

Gisbert

ZitatJetzt noch was zu den (rhasspy-) Names:
Auf dem screenshot der App ist zu erkennen, dass der betreffende Rollladen "rollladen schlafzimmer felix" heißt. Das ist m.E. nicht zu empfehlen, sondern die beiden Infos "Rollladen" und "Schlafzimmer Felix" sollten an der richtigen Stelle hinterlegt werden.

Das bedeutet: rhasspyName für beide Rollläden ist einfach "rollladen", rhasspyRoom ist dann entweder (ggf. u.a.) "schlafzimmer von felix,felix zimmer" und "schlafzimmer von gisbert,schlafzimmer,meinem schlafzimmer"

Hallo Jörg,

ich hänge an dieser Stelle. Ich habe verstanden (bzw. glaube es im Moment), dass man rhasspyName und rhasspyRoom trennen sollte.
Also habe ich die sentences.ini wie folgt angelegt:
[de.fhem:SetNumeric]
(fahre|fahr|stelle|stell) [den|die|das] $de.fhem.Device-blind{Device} [(im|in|in dem|auf dem|in der|auf der)] $de.fhem.Room{Room} auf Lücke{Value:10}
(halte|stopp|stoppe) [den|die|das] $de.fhem.Device-blind{Device} [(im|in|in dem|auf dem|in der|auf der)] $de.fhem.Room{Room} [an] {Change:cmdStop}

[de.fhem:SetOnOff]
(schalte|schalt|mache|mach|stelle|stell|fahre|fahr) [den|die|das] $de.fhem.Device-SetOnOff{Device} [(im|in|in dem|auf dem|in der|auf der)] $de.fhem.Room{Room} ((an|ein|hoch|auf){Value:on}|(aus|zu|runter){Value:off})

Es ist jetzt immer zwingend die Angabe eines Device(s) und Room(s) anzugeben.

Entsprechend habe ich das Fhem-Device mit den folgenden Attributen versehen, ein Beipiel hier:
rhasspyName rollladen,rolladen
rhasspyRoom schlafzimmer felix,schlafzimmer von felix,zimmer felix,zimmer von felix


Anschließend set Rhasspy update all durchgeführt - aber es läuft nicht rund bzw. der Sprachbefehl wird falsch interpretiert.

In de.fhem.Device-SetOnOff steht:
schlafzimmer gisbert
wohnzimmer.licht
rolladen
schlafzimmer von gisbert
rollladen
schlafzimmer
meinem schlafzimmer

Hier sollte nach meinem Verständnis nur "rollladen" und "rolladen" stehen, ggf. noch wohnzimmer.licht.

In de.fhem.Device-blind steht:
schlafzimmer gisbert
rollladen terrasse
rollladen südseite
rollladen westseite
rolladen
schlafzimmer von gisbert
rollladen
schlafzimmer
meinem schlafzimmer

Hier sollte nach meinem Verständnis nur "rollladen" und "rolladen" stehen, ggf. noch wohnzimmer.licht.

In de.fhem.Room steht:
schlafzimmer von felix
schlafzimmer felix
zimmer von felix
zimmer felix
network
rolladen
heizung
homehm
rollladen
googleassistant

Hier fehlen m.E. alle Definitionen, die ich bei rhasspyName schlafzimmer von gisbert,schlafzimmer gisbert,schlafzimmer,meinem schlafzimmer in einem weiteren Fhem-Device vorgenommen habe; andere Einträge sind vorhanden, die ich hier nicht erwarten würde.

Wie kann ich hier vorgehen?
Ich nehme an, dass eine händische Edition der Dateien nicht gewünscht ist; es wäre zumindest auf lange Sicht eher unpraktisch.

Viele Grüße Gisbert
Aktuelles FHEM | PROXMOX | Fujitsu Futro S740 | Debian 12 | UniFi | Homematic, VCCU, HMUART | ESP8266 | ATtiny85 | Wasser-, Stromzähler | Wlan-Kamera | SIGNALduino, Flamingo Rauchmelder FA21/22RF | RHASSPY

Beta-User

Also:

Der Raum kann optional sein. Wenn RHASSPY ansonsten ermitteln kann, welcher gemeint ist, geht es auch so. Geht über die Benennung des satelitte oder über die siteId2room-Reading-Funktion.
[de.fhem:SetNumeric]
(fahre|fahr|stelle|stell) [den|die|das] $de.fhem.Device-blind{Device} [[(im|in|in dem|auf dem|in der|auf der)] $de.fhem.Room{Room}] auf Lücke{Value:10}
(halte|stopp|stoppe) [den|die|das] $de.fhem.Device-blind{Device} [[(im|in|in dem|auf dem|in der|auf der)] $de.fhem.Room{Room}] [an] {Change:cmdStop}

[de.fhem:SetOnOff]
(schalte|schalt|mache|mach|stelle|stell|fahre|fahr) [den|die|das] $de.fhem.Device-SetOnOff{Device} [[(im|in|in dem|auf dem|in der|auf der)] $de.fhem.Room{Room}] ((an|ein|hoch|auf){Value:on}|(aus|zu|runter){Value:off})

Die slots sollten eigentlich automatisch erstellt werden, und ich würde mal behaupten, dass die "falschen" Werte aus anderen Devices kommen. Das sollte aus dem RHASSPY-list/devicemap zu erkennen sein. Ansonsten kannst du die devspec im der RHASSPY-DEF auch mal so eingrenzen, dass nur die beiden Geräte erfasst werden.
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