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

Das mit dem Stop ist der SetNumeric-intent,
Zitat von: Beta-User am 22 November 2021, 13:08:58
- da Gisbert unbedingt mit einem Rollladen starten wollte, ist mir aufgefallen, dass ein "stop"-Kommando doch auch ganz nett wäre. Könnte sein, dass es klappt, wenn der Rollladen so einen setter hat und man in "Change" für "stop" "cmdStop" übergibt ([de.fhem:SetNumeric] => ( halte | stoppe ) ( den | die ) $de.fhem.Device-blind{Device} [an] {Change:cmdStop}). Da ziemlich sicher meine Lamellen dann "falsch" stehen bleiben werden, gibt es auch noch einen weiteren Eintrag in den "specials" für venetian blinds... (Achtung: Status insgesamt ist komplett ungetestet ::) ).
Details sollten der commandref zu entnehmen sein.

Da dein ESP nicht "nummerisch" spricht, musst du mit "slit" warten, bis ich dazu komme, mir dafür was zu überlegen.

Nach meiner eigenen Erfahrung kommt es nicht ganz so genau darauf an, und "pct 10" sind z.B. bei dem CUL_HM-Geräten in etwa das, was du mit "slit" erreichst.
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,

vielleicht noch eine Beobachtung, die etwas merkwürdig ist.

In der Android-App werden die hinterlegten Befehle (DriveUp, DriveDown, Stop, DriveSlit - letzeres ohne Funktion) ausgeführt und mit "ok" quittiert.
Das Merkwürdige ist, dass faktisch runter gefahren wird, egal welcher gesprochene Befehl gesendet wird, nicht durchgängig, deshalb noch merkwürdiger. Ich dachte schon, dass ich (wiedermal) klebende Relais hab, aber das kann ich zu 99.9% ausschließen, da Vorort-Befehle, von Fhem oder per Google Assistant richtig ausgeführt werden, zeitlich vor und nach Rhasspy-Aktionen.

Rhasspy und mein MQTT-DEVICE laufen mit Mosquitto über den gleichen Port 1883. Kann da etwas in Schieflage geraten?

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

Beta-User

SetOnOff erwartet "on" oder "off". Da wird wohl alles als off interpretiert... => sentences.ini anpassen.
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

...etwas länger:
In der aktualisierten commandref (ist zwischenzeitlich über contrib zu bekommen) gibt es hinten eine Liste, welcher Intent welche Schlüssel erwartet (und wo relevant: welche Werte).

Für SetOnOff verwende ich derzeit noch:

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

mit einem eigenen slot OnOffValue:
aus:off
on
zu:off
auf:on
off
an:on


Das ist aber m.E. eigentlich nicht mehr "state of the art"...

Das hier sollte eine genauere Treffsicherheit erzeugen:
[de.fhem:SetOnOff]
(fahr | mach) [den|die|das] $de.fhem.Device-blind{Device} [( im | in dem | in der ) $de.fhem.Room{Room}] ( auf{Value:on} | zu{Value:off} )
( öffne{Value:on} | schließe{Value:off} ) [den|die|das] $de.fhem.Device-blind{Device} [( im | in dem | in der ) $de.fhem.Room{Room}]
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

Danke für die Erklärung.

Umgesetzt vor deinem letzten Beitrag hab ich in sentences.ini das folgende:
(fahre) $de.fhem.Device{Device} (hoch){Value:on} [$de.fhem.Room{Room}]
(fahre) $de.fhem.Device{Device} (runter){Value:off} [$de.fhem.Room{Room}]

In Fhem-Device hab ich on off mit mit eventMap ausgewertet, so dass jetzt die Fahrtrichtung richtig funktioniert.

Wichtig wäre mir auch, dass ich die Funktion DriveSlit, "auf Lücke" fahren abbilden kann.
Mit eventMap kann ich ja eigentlich jeden Wert auf das abbilden, was ich gerne hätte. Was könnte Rhasspy an Werten außer on off liefern?

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

Beta-User

Zitat von: Gisbert am 28 November 2021, 13:13:16
In Fhem-Device hab ich on off mit mit eventMap ausgewertet, so dass jetzt die Fahrtrichtung richtig funktioniert.

Wichtig wäre mir auch, dass ich die Funktion DriveSlit, "auf Lücke" fahren abbilden kann.
Mit eventMap kann ich ja eigentlich jeden Wert auf das abbilden, was ich gerne hätte. Was könnte Rhasspy an Werten außer on off liefern?
"Liefern" kann Rhasspy alles mögliche, aber ausgewertet wird nur das, was in der commandref steht.
Und das hat erst mal NICHTS mit eventMap zu tun. RHASSPY macht aus "on" den cmdOn command. Basta. Wenn der dann (mit eventMap) gemappt wird, wird das entsprechend beachtet, aber das ist eine ganz andere Diskussion und hier auch keine gute Lösung!
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

Zitat von: Beta-User am 28 November 2021, 13:44:24
"Liefern" kann Rhasspy alles mögliche, aber ausgewertet wird nur das, was in der commandref steht.
Und das hat erst mal NICHTS mit eventMap zu tun. RHASSPY macht aus "on" den cmdOn command. Basta. Wenn der dann (mit eventMap) gemappt wird, wird das entsprechend beachtet, aber das ist eine ganz andere Diskussion und hier auch keine gute Lösung!

Hallo Jörg,

ich bin ja stets bemüht dazuzulernen, aber da brauche ich deine Anleitung. eventMap kannte ich halt und habe es dann für meine Zwecke eingesetzt. Wenn es einen besseren Weg gibt, um das, was Fhem in der Kommandozeile kann, per Sprache ausführen zu lassen, dann bin ich gerne dabei, es zu benutzen.
In der Kommadozeile funktionieren diese Befehle:
set <Rollladendevice> Event Down|Up|Stop|Slit

Ich hab eine Ergänzung in Github bei Quickinfo/Vorbereitungen reingebracht mit "[Gisbert: ...]". Wenn es für dich in Ordnung ist, dann entferne die Kommentar-Formatierung, ansonsten kannst du es natürlich so abändern oder löschen, wie es für dich sinnvoll ist.

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

JensS

Hallo Gisbert,

du könntest den Intent MediaControls nutzen.

Gruß Jens
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.

Beta-User

Vermutlich geht auch ein eventMap, das diskrete pct-Werte auf die Tasmota-Commamds mapt.
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

Zitat von: Beta-User am 28 November 2021, 19:44:17
Vermutlich geht auch ein eventMap, das diskrete pct-Werte auf die Tasmota-Commamds mapt.
Zitat von: JensS am 28 November 2021, 19:32:28
Hallo Gisbert,
du könntest den Intent MediaControls nutzen.
Gruß Jens
Ich würde euch ja gerne folgen, benötige aber etwas konkreteres, gerne vorgekaut, veradauen würde ich es dann selbst :o 8)
Aktuelles FHEM | PROXMOX | Fujitsu Futro S740 | Debian 12 | UniFi | Homematic, VCCU, HMUART | ESP8266 | ATtiny85 | Wasser-, Stromzähler | tuya local | Wlan-Kamera | SIGNALduino, Flamingo Rauchmelder FA21/22RF | RHASSPY | DEYE | JK-BMS | ESPHome

JensS

#40
Einfach mal ins Blaue...
sentences.ini:[de.fhem:MediaControls]
\[fahre] ($de.fhem.Device){Device} (stopp:cmdStop | hoch:cmdFwd | runter:cmdBack | auf Spalt:cmdPlay){Command}

rhasspyMapping:MediaControls:cmdFwd={fhem("set $DEVICE Event Up")},cmdBack={fhem("set $DEVICE Event Down")},cmdStop={fhem("set $DEVICE Event Stop")},cmdPlay={fhem("set $DEVICE Event Slit")}

Gruß Jens
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.

Beta-User

Vielleicht nochmal ein paar grundsätzliche Anmerkungen:

- Es fördert meine Laune nicht unbedingt, wenn meine "Schubser" in Richtung der Nutzung der eingeschränkteren Slots ungehört verhallen. Wenn man von vornherein zum einen gDT setzt, und dann zum anderen "$de.fhem.Device-blind{Device}" verwendet, um nur Rollladen-Geräte bei der Bildung des Datenmodells in Rhasspy zu berücksichtigen, skaliert das System bei der Erkennung des "richtigen Gerätes" am Ende mAn. deutlich besser, wenn man irgendwann mehr Geräte einbindet. Am Anfang ist der Unterschied zwar nicht spürbar, wenn man es nur mit zwei Rollladen und einem "switch" zu tun hat, es wäre mir aber aus "didaktischen Gründen" sehr daran gelegen, wenn das jetzt bitte einfach so gemacht werden würde. Oder hat jemand prinzipielle Einwände?

- Man kann in FHEM und auch in RHASSPY und Rhasspy an sehr vielen Stellen irgendwas einstellen, um am Ende das gewünschte Ergebnis zu erzielen. (Man könnte auch "Colors" dazu hernehmen oder einen eigenen Intent basteln, oder ...) Dabei stellt sich oft die Frage, welches der Weg ist, der mittel- und langfristig am ehesten trägt. Nach meiner bisherigen Erfahrung sind es in der Regel die Varianten, die generisch angelegt sind. Da ein Rollladen typischerweise eben neben "auf" und "zu" (die wir hier ja bereits via SetOnOff im Griff haben, wenn ich das richtig verstanden habe) nummerische Positionskommandos haben will, sollten alle Positionskommandos auch via _SetNumeric_  angehandelt werden. Das gibt den typischerweise den kleinsten "Hackel", wenn ein anderer dazukommt, der irgendwie anders "tickt". Das ist der tiefere Grund, warum "cmdStop" sich innerhalb der nummerischen Kommandos findet. Von der Auswertung her ist es so nämlich aufwändiger als irgendein workaround...

Zitat von: Beta-User am 28 November 2021, 19:44:17
Vermutlich geht auch ein eventMap, das diskrete pct-Werte auf die Tasmota-Commamds mapt.
Würde mal folgendes Experiment in den Raum werfen:
attr RollladenSchlafzimmerGisbert eventMap /Event Up:opens/Event Down:closes/Event Up:DriveUp/Event Stop:Stop/Event Slit:DriveSlit/Event Down:DriveDown/pct 10.01:DriveSlit/mit
attr RollladenSchlafzimmerGisbert rhasspyMapping SetOnOff:cmdOn=DriveUp,cmdOff=DriveDown\
SetNumeric:cmdStop=Stop,type=setTarget,cmd=pct
und:
[de.fhem:SetOnOff]
(fahr | mach) [den|die|das] $de.fhem.Device-blind{Device} [( im | in dem | in der ) $de.fhem.Room{Room}] ( auf{Value:on} | zu{Value:off} )
( öffne{Value:on} | schließe{Value:off} ) [den|die|das] $de.fhem.Device-blind{Device} [( im | in dem | in der ) $de.fhem.Room{Room}][de.fhem:SetNumeric]
stelle ( den | die ) $de.fhem.Device-blind{Device} [[(im | in der )] $de.fhem.Room{Room}] auf Spalt{Value:10.01}
( halte | stoppe ) ( den | die ) $de.fhem.Device-blind{Device} [[(im | in der )] $de.fhem.Room{Room}] [an] {Change:cmdStop}
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

Guten Morgen Jörg,

ZitatEs fördert meine Laune nicht unbedingt, wenn meine "Schubser" in Richtung der Nutzung der eingeschränkteren Slots ungehört verhallen.
Ich hoffe das galt nicht mir, denn ich bin redlich bemüht, alles umzusetzen, was in meinen Möglichkeiten steht - manchmal fehlen mir aber schlicht Grundlagen, die die Geduld von Modulautoren auf die Probe stellen können. Du gibst dir soviel Mühe mit diesem Projekt und mir, das ist bewundernswert.

So sieht mein sentences.ini jetzt aus (leicht modifiziert-hoffentlich noch richtig):
[de.fhem:SetOnOff]
(schalte) $de.fhem.Device{Device} (an){Value:on} [$de.fhem.Room{Room}]
(schalte) $de.fhem.Device{Device} (aus){Value:off} [$de.fhem.Room{Room}]
(fahr|fahre|mach|mache) [den|die|das] $de.fhem.Device-blind{Device} [(im|in dem|in der) $de.fhem.Room{Room}] ( auf{Value:on} | hoch{Value:on} | zu{Value:off} | runter{Value:off} )

[de.fhem:SetNumeric]
(fahr|fahre|stell|stelle) [den|die|das] $de.fhem.Device-blind{Device} [(im|in dem|in der) $de.fhem.Room{Room}] auf Lücke{Value:10.01}
(halte|stopp|stoppe) [den|die|das] $de.fhem.Device-blind{Device} [(im|in dem|in der) $de.fhem.Room{Room}] [an] {Change:cmdStop}

und das rhasspyMapping:
attr <device> rhasspyMapping SetOnOff:cmdOn=DriveUp,cmdOff=DriveDown
SetNumeric:cmdStop=Stop,type=setTarget,cmd=pct


Abspeichern und Update hab ich gemacht.
Hoch- und Runterfahren funktioniert, nicht aber der Stop- und der Lückebefehl.
cmdStop liefert voiceResponse Tut mir leid, ich konnte den Zielwert nicht ausrechnen
"Lücke" / 10.01 liefert VoiceResponse: Gerne!

In beiden Fällen wird aber keine Aktion am Rollladen durchgeführt.
Anbei Screenshots noch von den beiden Eingaben/Sprache in der Android-App.

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

Beta-User

#43
Hi Gisbert,

doch, zum großen Teil galt das schon dir ::) .
Kleines aktuelles Beispiel:
(schalte) $de.fhem.Device{Device} (aus){Value:off} [$de.fhem.Room{Room}]Irgendwo in diesem Thread sollte eine besser sprechbare Variante mit "$de.fhem.Device-SetOnOff{Device}" zu finden sein...

Zu dem Rollladen-Thema habe ich mir jetzt was anderes überlegt, bitte den Code und die Modulversion aus https://forum.fhem.de/index.php/topic,119447.msg1189969.html#msg1189969 austesten, und dann "Lücke" so übergeben: "Lücke{Value:10}"
Zu dem stop-Befehl scheine ich über das eventMapping gestolpert zu sein, evtl. geht "Event Stop" besser:
Damit wäre das die betreffende Zeile in rhasspyMapping:SetNumeric:cmdStop=Event Stop,type=setTarget,cmd=pct

Nachtrag noch: Kann sein, dass das numericValueMap etwas anders sein muss:
attr RollladenSchlafzimmerGisbert rhasspySpecials numericValueMap:10='Event Slit'
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,

Zitat"Schubser" in Richtung der Nutzung der eingeschränkteren Slots
- ist damit gemeint, dass möglichst viele Varianten in einer Zeile abgehandelt werden sollen?
Wenn ja, dann hab ich das jetzt so umgesetzt; wenn es dir noch nicht gefällt, dann schubse gerne nochmals kräftig ??? :-X
[de.fhem:SetNumeric]
(fahre|fahr|stelle|stell) [den|die|das] $de.fhem.Device-blind{Device} [(im|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 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 dem|auf dem|in der|auf der) $de.fhem.Room{Room}] ((an|ein|hoch|auf){Value:on}|(aus|zu|runter){Value:off})


Attribute im Rollladen-Device:

attr <device> eventMap /Event Up:opens/Event Down:closes/Event Up:DriveUp/Event Stop:Stop/Event Slit:DriveSlit/Event Down:DriveDown
attr <device> genericDeviceType blind
attr <device> rhasspyMapping SetOnOff:cmdOn=DriveUp,cmdOff=DriveDown\
SetNumeric:cmdStop=Stop,type=setTarget,cmd=pct
attr <device> rhasspyName Rollladen <name>
attr <device> rhasspySpecials numericValueMap:10='Event Slit'


Damit funktionieren alle 4 Fahrbefehle :) :-*
Eigenartigerweise funktioniert cmdStop=Stop jetzt - da will ich mich nicht beschweren.
Ich hab diese Rhasspy-Version benutzt: https://forum.fhem.de/index.php/topic,119447.msg1189987.html#msg1189987

Vielen Dank und viele Grüße
Gisbert
Aktuelles FHEM | PROXMOX | Fujitsu Futro S740 | Debian 12 | UniFi | Homematic, VCCU, HMUART | ESP8266 | ATtiny85 | Wasser-, Stromzähler | tuya local | Wlan-Kamera | SIGNALduino, Flamingo Rauchmelder FA21/22RF | RHASSPY | DEYE | JK-BMS | ESPHome