Hallo,
rhasspy.service ist definiert und gestartet. Ich bekomme aber keine Verbindung zum vorgesehenen MQTT-Broker:
Internals:
BUF
Clients :RHASSPY:MQTT_GENERIC_BRIDGE:MQTT2_DEVICE:
ClientsKeepOrder 1
DEF 192.168.1.46:12183
DeviceName 192.168.1.46:12183
FUUID 61978527-f33f-e986-ee32-8a8fd1dc8a8f3bb5
NAME rhasspyMQTT2
NEXT_OPEN 1637358155.69727
NR 1207
PARTIAL
STATE disconnected
TYPE MQTT2_CLIENT
clientId rhasspyMQTT2
connecting 1
nextOpenDelay 5
MatchList:
1:RHASSPY ^.
2:MQTT_GENERIC_BRIDGE ^.
3:MQTT2_DEVICE ^.
OLDREADINGS:
READINGS:
2021-11-19 22:42:30 state disconnected
helper:
bm:
MQTT2_CLIENT_Attr:
cnt 4
dmx -1000
dtot 0
dtotcnt 0
mTS 19.11. 19:55:00
max 0.0426030158996582
tot 0.0429978370666504
mAr:
set
rhasspyMQTT2
username
gis23
MQTT2_CLIENT_Define:
cnt 3
dmx -1000
dtot 0
dtotcnt 0
mTS 19.11. 20:22:10
max 0.0440831184387207
tot 0.116586923599243
mAr:
HASH(0x55ba99ded1e0)
rhasspyMQTT2 MQTT2_CLIENT 192.168.1.46:12183
MQTT2_CLIENT_Set:
cnt 147
dmx -1000
dtot 0
dtotcnt 0
mTS 19.11. 19:55:14
max 0.0351588726043701
tot 0.076606273651123
mAr:
HASH(0x55ba99ded1e0)
rhasspyMQTT2
password
zfmgs23
MQTT2_CLIENT_connect:
cnt 260110
dmx -1000
dtot 0
dtotcnt 0
mTS 19.11. 21:26:44
max 0.0252149105072021
tot 71.8889908790588
mAr:
HASH(0x55ba99ded1e0)
Attributes:
clientOrder RHASSPY MQTT_GENERIC_BRIDGE MQTT2_DEVICE
room Rhasspy
subscriptions hermes/intent/+ hermes/dialogueManager/sessionStarted hermes/dialogueManager/sessionEnded
username gis23
Wenn ich auf der Seite <ip-or-hostname-of-mqtt-server>:12101 den MQTT-Server mit Port 1883 einstelle, dann läuft rhasspy.service ohne Fehler, auch die Android-App bekommt mit Port 1883 eine Verbindung hin.
Ich habe bisher keine MQTT2-Devices sondern nutze MQTT_DEVICE mit dem Mosquitto-Broker.
Viele Grüße Gisbert
Edit: Titel geändert.
Hallo zurück :) .
Schnelle Lösung - DEF auf die richtige IP:Port-Kombi einstellen:
192.168.1.46:1883(falls das dieselbe Maschine ist, würde ich über localhost:1883 gehen)
Längerfristiges Thema:
Eigentlich war "meine Lösung" nicht gut, es ist nach meinen zwischenzeitlichen Erfahrungen m.E. sinnvoller, für Rhasspy dessen internen MQTT-Server zu verwenden. Vermutlich muss man dafür einfach in der service-file die Angaben zum Server komplett weglassen.
Empfehlung daher:
- für einen ersten Erfolg obige Änderung auf Port 1883 umstellen und dann über "wie spät ist es" freuen;
- dann Doks checken, wie man den internen Server aktiviert oder austesten, ob meine Annahme stimmt und dann die DEF wieder auf den Wert "12183" ändern, der per default von Rhasspy verwendet wird;
- für den internen MQTT-Server von Rhasspy kannst du dann auch die clientOrder auf RHASSPY beschränken. Die anderen Angaben sind nur relevant, wenn man den MQTT2_CLIENT noch für was anderes verwenden will.
Hallo Jörg,
ich hab versucht Doku über den internen MQTT-Broker zu finden, war aber erfolglos.
Ich werde dann erst mal mit port 1883 weitermachen.
Viele Grüße Gisbert
Hallo Jörg,
der nächste Cliffhanger - rhasspy.service und Android laufen, auch der Webserver, aber ich nicht die leiseste Ahnung wie Töne/Gesprochenes beim Webserver oder der Android-App zur Anwendung kommen.
Was immerhin geht in der Webpage (port 12101:
Text to regognize --> wie spät ist es --> führt zu GetTime
Aber schon Text to speak --> wie spät ist es --> führt zu "AudioServerException: Command '['aplay', '-q', '-t', 'wav']' returned non-zero exit status 1."
Wo setze ich denn hier an?
In Fhem habe ich einem Device das Attribut rhasspyName gegeben.
Die nächste Hürde, wo gebe ich aber das ein (Beispiel)?
SetOnOff:cmdOn=on,cmdOff=off
SetOnOff:cmdOn=on,cmdOff=off,response="Sir yes Sir"
SetOnOff:cmdOn=on,cmdOff=off,response="$DEVICE now [$DEVICE:state]"
Ok, gefunden, eine Datei de.fhem.SetOnOff.ini im Ordner intents anlegen.
Ist "de.fhem" im Namen und im Inhalt der Datei zwingend erforderlich oder nur zufällig so?
In der mitgelieferten Datei ist dazu enthalten:
[de.fhem:SetOnOff]
\[(schalte|mache|stelle)] [den|die|das] $de.fhem.Device{Device} [im|in der|auf dem|auf der] [$de.fhem.Room{Room}] (an|ein){Value:on}
\[(schalte|mache|stelle)] [den|die|das] $de.fhem.Device{Device} [im|in der|auf dem|auf der] [$de.fhem.Room{Room}] (aus){Value:off}
$de.fhem.Device{Device} ist damit der rhasspyName gemeint?
Ich glaube, das Brett wird für mich immer dicker, immerhin ein positiver Beitrag zur CO2-Vermeidung ;D
Viele Grüße Gisbert
Zitat von: Gisbert am 20 November 2021, 19:23:40
der nächste Cliffhanger - rhasspy.service und Android laufen, auch der Webserver, aber ich nicht die leiseste Ahnung wie Töne/Gesprochenes beim Webserver oder der Android-App zur Anwendung kommen.
Also:
Die "Basics" auf der Rhasspy-Server- und App-Seite scheinen also zu stehen. Das ist doch schon mal was. Da deine "base" (EDIT: headless) läuft, ist da gar keine Audio-Hardware, die an der siteId "base" was ausgeben könnte. Du kannst also auch "Audio playing" auf "Disabled" setzen.
RHASSPY wird immer (mind.) an die siteId sound schicken, die den "Mach was"-Input geliefert hat. Also lass erst mal diesen Teil außen vor.
Zitat
In Fhem habe ich einem Device das Attribut rhasspyName gegeben.
Die nächste Hürde, wo gebe ich aber das ein (Beispiel)?
Erst mal wieder kleinere Schritte machen:
- Das Device hat einen (bekannten) genericDeviceType? Und ist von der devspec in RHASSPY erfasst? => "set <RHASSPY> update" und dann mal ein "list <RHASSP>" anschauen. Dort sollte unter "helper->devicemap" das Gerät zu finden sein.
ZitatOk, gefunden, eine Datei de.fhem.SetOnOff.ini im Ordner intents anlegen.
Ist "de.fhem" im Namen und im Inhalt der Datei zwingend erforderlich oder nur zufällig so?
Kurzfassung: Nein.
Der Dateiname ist im Prinzip beliebig, es macht aber Sinn, das so zu organisieren, dass man auch was wiederfindet...
Zitat
$de.fhem.Device{Device} ist damit der rhasspyName gemeint?
:) Ja. Langfassung dazu:
$de.fhem.Device{Device} ist ein "slot", also eine art Variable innerhalb Rhasspy. Alle "slots" findest du, wenn du auf das "CD-Symbol" im Rhasspy-Web-Interface klickst. Dort dann aber ohne den "Kenner" $. RHASSPY füllt einen Teil der slots aus den Angaben, die du auch in "devicemap" im list siehst.
Dabei ist die Zusammensetzung wie folgt:
"de" => LANGUAGE der RHASSPY-Instanz
"fhem" => fhemId der RHASSPY-Instanz (es kann mehrere Instanzen geben, z.B. für mehrere User/mehrere Sprachen)
"Device" => (einer) der Gerätenamen, unter denen RHASSPY das Ziel identifizieren kann und einer FHEM-Device-Instanz zuordnen (es können auch mehrere rhasspyNames vergeben werden).
Zitat
Ich glaube, das Brett wird für mich immer dicker, immerhin ein positiver Beitrag zur CO2-Vermeidung ;D
Für mich sieht es eher danach aus, als würde gleich der Groschen vollends fallen ;D . Nach meiner bisherigen Erfahrung ist der Rest ein Kinderspiel, wenn erst mal klar ist, wie die vielen Bausteinchen zusammenspielen :) .
Danach beginnt dann die Feinarbeit. Man kann dann z.B. statt
[de.fhem:SetOnOff]
\[(schalte|mache|stelle)] [(den|die|das)] $de.fhem.Device{Device} [[(im|in der|auf dem|auf der) $de.fhem.Room{Room}] (an|ein){Value:on}
\[(schalte|mache|stelle)] [(den|die|das)] $de.fhem.Device{Device} [[(im|in der|auf dem|auf der) $de.fhem.Room{Room}] (aus){Value:off}Kurzformen verwenden, indem man die on/off-Alternativen zusammenfasst oder statt des "alle Gerätenamen"-slots einen verwendet, der nur die Namen listet, die auch wirklich "on/off" können:
[de.fhem:SetOnOff]
\[(schalte|mache|stelle)] [den|die|das] $de.fhem.Device-SetOnOff{Device}|) [[(im|in der|auf dem|auf der)] $de.fhem.Room{Room}] ( (an|ein){Value:on} | (aus){Value:off})
Hallo Jörg,
genericDeviceType wird anscheinend auch von Google Assistant benutzt, welches ich auch benutze. Hier werden die Gerätetypen per Pull-down-Menu zur Verfügung gestellt. Die beiden Devices haben den genericDeviceType blinds (mit "s") aber nicht blind, wie auf Github geschrieben.
Hier ein list des Devices Rhasspy nach dem Update:
Internals:
DEF baseUrl=http://192.168.1.46:12101 language=de
FUUID 61978863-f33f-e986-532e-c2d28847a3d59476
IODev rhasspyMQTT2
LANGUAGE de
LASTInputDev rhasspyMQTT2
MODULE_VERSION 0.4.41a
MSGCNT 18
NAME Rhasspy
NR 1208
STATE online
TYPE RHASSPY
baseUrl http://192.168.1.46:12101
defaultRoom default
devspec room=Rhasspy
encoding utf8
fhemId fhem
prefix rhasspy
rhasspyMQTT2_MSGCNT 18
rhasspyMQTT2_TIME 2021-11-20 14:36:02
useGenericAttrs 1
READINGS:
2021-11-20 10:50:39 IODev rhasspyMQTT2
2021-11-20 14:23:28 listening_default 0
2021-11-20 14:36:02 listening_master 0
2021-11-21 16:43:53 state online
2021-11-21 16:43:53 training Training completed in 6.44 second(s)
2021-11-19 20:34:33 updateSentences Wrote 21 char(s) to ['/opt/rhasspy/profiles/de/intents/de.fhem.Shortcuts.ini']
2021-11-21 16:43:47 updateSlots OK
TIMER:
Rhasspy_null:
HASH Rhasspy
MODIFIER null
NAME Rhasspy_null
enable false
toDisable:
ConfirmAction
CancelAction
ChoiceRoom
ChoiceDevice
helper:
bm:
CODE(0x55badcad7850):
cnt 143
dmx -1000
dtot 0
dtotcnt 0
mTS 21.11. 16:32:46
max 0.120627880096436
tot 0.632144451141357
mAr:
HASH(0x55badcad1060)
ARRAY(0x55bae419f520)
HASH(0x55bae402b9a0)
devicemap:
devices:
Rhasspy:
intents:
rhasspyMQTT2:
intents:
lng:
responses:
DefaultCancelConfirmation Thanks aborted
DefaultChangeIntentRequestRawInput change command to $rawInput
DefaultChoiceNoOutstanding no choice expected
DefaultConfirmation OK
DefaultConfirmationBack So once more
DefaultConfirmationNoOutstanding no command is awaiting confirmation
DefaultConfirmationReceived ok will do it
DefaultConfirmationRequestRawInput please confirm: $rawInput
DefaultConfirmationTimeout Sorry too late to confirm
DefaultError Sorry but something seems not to work as expected
NoActiveMediaDevice Sorry no active playback device
NoDeviceFound Sorry but I could not find a matching device
NoMappingFound Sorry but I could not find a suitable mapping
NoMediaChannelFound Sorry but requested channel seems not to exist
NoNewValDerived Sorry but I could not calculate a new value to set
NoTimedOnDeviceFound Sorry but device does not support requested timed on or off command
NoValidData Sorry but the received data is not sufficient to derive any action
RequestChoiceDevice there are several possible devices, choose between $first_items and $last_item
RequestChoiceRoom more than one possible device, please choose one of the following rooms $first_items and $last_item
SilentCancelConfirmation
duration_not_understood Sorry I could not understand the desired duration
reSpeak_failed i am sorry i can not remember
timeRequest it is $hour o clock $min minutes
timerCancellation $label for $room deleted
weekdayRequest today is $weekDay, $month the $day., $year
Change:
brightness $device was set to $value
desired-temp target temperature for $location is set to $value degrees
humidity air humidity in $location is $value percent
knownType $mappingType in $location is $value percent
setTarget $device is set to $value
soilMoisture soil moisture in $location is $value percent
unknownType value in $location is $value percent
volume $device set to $value
waterLevel water level in $location is $value percent
battery:
0 battery level in $location is $value
1 battery level in $location is $value percent
temperature:
0 temperature in $location is $value
1 temperature in $location is $value degrees
timerEnd:
0 $label expired
1 $label in room $room expired
timerSet:
0 $label in room $room has been set to $seconds seconds
1 $label in room $room has been set to $minutes minutes $seconds
2 $label in room $room has been set to $minutes minutes
3 $label in room $room has been set to $hours hours $minutetext
4 $label in room $room has been set to $hour o clock $minutes
5 $label in room $room has been set to tomorrow $hour o clock $minutes
stateResponses:
inOperation:
0 $deviceName is ready
1 $deviceName is still running
inOut:
0 $deviceName is out
1 $deviceName is in
onOff:
0 $deviceName is off
1 $deviceName is on
openClose:
0 $deviceName is open
1 $deviceName is closed
units:
unitHours:
0 hours
1 one hour
unitMinutes:
0 minutes
1 one minute
unitSeconds:
0 seconds
1 one second
shortcuts:
tweaks:
Attributes:
room Rhasspy
Noch klemmt der Groschen ;) :'( - und leichte Schläge auf den Hinterkopf mag ich nicht :-\
Viele Grüße Gisbert
Deine devspec ist nicht gut, sollte dann entweder die Geräte (komma-getrennt) erfassen, oder alles, was gDT gesetzt hat. gDT-Attribute notfalls via Kommandozeile setzen. blind statt blinds müsste auch für gassistant passen.
Hallo Jörg,
ich hab jetzt bei einem Fhem-Device ich folgende Attribute gesetzt (zusammenkopiert):
genericDeviceType blind
rhasspyGroup Rollladen
rhasspyMapping SetOnOff:cmdOn=on,cmdOff=off,response="All right"
GetOnOff:currentVal=state,valueOff=off
rhasspyName Rollladen Schlafzimmer, Rollladen Gisbert
rhasspyRoom Rollladen
Das list von Rhasspy:
Internals:
DEF baseUrl=http://192.168.1.46:12101 language=de
FUUID 61978863-f33f-e986-532e-c2d28847a3d59476
IODev rhasspyMQTT2
LANGUAGE de
LASTInputDev rhasspyMQTT2
MODULE_VERSION 0.4.41a
MSGCNT 18
NAME Rhasspy
NR 1208
STATE online
TYPE RHASSPY
baseUrl http://192.168.1.46:12101
defaultRoom default
devspec room=Rhasspy
encoding utf8
fhemId fhem
prefix rhasspy
rhasspyMQTT2_MSGCNT 18
rhasspyMQTT2_TIME 2021-11-20 14:36:02
useGenericAttrs 1
READINGS:
2021-11-20 10:50:39 IODev rhasspyMQTT2
2021-11-20 14:23:28 listening_default 0
2021-11-20 14:36:02 listening_master 0
2021-11-21 18:07:40 state online
2021-11-21 18:07:40 training Training completed in 7.81 second(s)
2021-11-19 20:34:33 updateSentences Wrote 21 char(s) to ['/opt/rhasspy/profiles/de/intents/de.fhem.Shortcuts.ini']
2021-11-21 18:07:32 updateSlots OK
TIMER:
Rhasspy_null:
HASH Rhasspy
MODIFIER null
NAME Rhasspy_null
enable false
toDisable:
ConfirmAction
CancelAction
ChoiceRoom
ChoiceDevice
helper:
bm:
CODE(0x55badcad7850):
cnt 217
dmx -1000
dtot 0
dtotcnt 0
mTS 21.11. 16:32:46
max 0.120627880096436
tot 1.07848930358887
mAr:
HASH(0x55badcad1060)
ARRAY(0x55bae419f520)
HASH(0x55bae402b9a0)
devicemap:
devices:
Rhasspy:
intents:
rhasspyMQTT2:
intents:
lng:
responses:
DefaultCancelConfirmation Thanks aborted
DefaultChangeIntentRequestRawInput change command to $rawInput
DefaultChoiceNoOutstanding no choice expected
DefaultConfirmation OK
DefaultConfirmationBack So once more
DefaultConfirmationNoOutstanding no command is awaiting confirmation
DefaultConfirmationReceived ok will do it
DefaultConfirmationRequestRawInput please confirm: $rawInput
DefaultConfirmationTimeout Sorry too late to confirm
DefaultError Sorry but something seems not to work as expected
NoActiveMediaDevice Sorry no active playback device
NoDeviceFound Sorry but I could not find a matching device
NoMappingFound Sorry but I could not find a suitable mapping
NoMediaChannelFound Sorry but requested channel seems not to exist
NoNewValDerived Sorry but I could not calculate a new value to set
NoTimedOnDeviceFound Sorry but device does not support requested timed on or off command
NoValidData Sorry but the received data is not sufficient to derive any action
RequestChoiceDevice there are several possible devices, choose between $first_items and $last_item
RequestChoiceRoom more than one possible device, please choose one of the following rooms $first_items and $last_item
SilentCancelConfirmation
duration_not_understood Sorry I could not understand the desired duration
reSpeak_failed i am sorry i can not remember
timeRequest it is $hour o clock $min minutes
timerCancellation $label for $room deleted
weekdayRequest today is $weekDay, $month the $day., $year
Change:
brightness $device was set to $value
desired-temp target temperature for $location is set to $value degrees
humidity air humidity in $location is $value percent
knownType $mappingType in $location is $value percent
setTarget $device is set to $value
soilMoisture soil moisture in $location is $value percent
unknownType value in $location is $value percent
volume $device set to $value
waterLevel water level in $location is $value percent
battery:
0 battery level in $location is $value
1 battery level in $location is $value percent
temperature:
0 temperature in $location is $value
1 temperature in $location is $value degrees
timerEnd:
0 $label expired
1 $label in room $room expired
timerSet:
0 $label in room $room has been set to $seconds seconds
1 $label in room $room has been set to $minutes minutes $seconds
2 $label in room $room has been set to $minutes minutes
3 $label in room $room has been set to $hours hours $minutetext
4 $label in room $room has been set to $hour o clock $minutes
5 $label in room $room has been set to tomorrow $hour o clock $minutes
stateResponses:
inOperation:
0 $deviceName is ready
1 $deviceName is still running
inOut:
0 $deviceName is out
1 $deviceName is in
onOff:
0 $deviceName is off
1 $deviceName is on
openClose:
0 $deviceName is open
1 $deviceName is closed
units:
unitHours:
0 hours
1 one hour
unitMinutes:
0 minutes
1 one minute
unitSeconds:
0 seconds
1 one second
shortcuts:
tweaks:
Attributes:
room Rhasspy
Viele Grüße Gisbert
Deine RHASSPY-devspec erfasst den blind immer noch nicht...?
Ja sieht so aus - wir haben ein Cliffhanger ;)
Auf jeden Fall hab ich "set Rhasspy update devicemap" mehrfach und mit zeitlichem Abstand betätigt.
Mobile Kurzantwort:
commandref zu RHASSPY-define/devspec hat ein paar Beispiele.
Hallo Jörg,
das hat wieder einen Schubser in die richtige Richtung gebracht.
Hier ein list:
Internals:
DEF baseUrl=http://192.168.1.46:12101 devspec=room=Rhasspy,room=Rollladen,HomeHM defaultRoom=Rollladen language=de
FUUID 61978863-f33f-e986-532e-c2d28847a3d59476
IODev rhasspyMQTT2
LANGUAGE de
MODULE_VERSION 0.4.41a
NAME Rhasspy
NR 1207
STATE online
TYPE RHASSPY
baseUrl http://192.168.1.46:12101
defaultRoom Rollladen
devspec room=Rhasspy,room=Rollladen,HomeHM
encoding utf8
fhemId fhem
prefix rhasspy
useGenericAttrs 1
READINGS:
2021-11-21 21:19:59 IODev rhasspyMQTT2
2021-11-21 21:19:59 intents ChangeLightState,GetTime,GetTemperature,GetGarageState
2021-11-20 14:23:28 listening_default 0
2021-11-20 14:36:02 listening_master 0
2021-11-21 21:16:59 siteIds Pixel4a
2021-11-21 21:20:14 state online
2021-11-21 21:20:14 training Training completed in 7.22 second(s)
2021-11-19 20:34:33 updateSentences Wrote 21 char(s) to ['/opt/rhasspy/profiles/de/intents/de.fhem.Shortcuts.ini']
2021-11-21 21:20:07 updateSlots OK
TIMER:
Rhasspy_null:
HASH Rhasspy
MODIFIER null
NAME Rhasspy_null
enable false
toDisable:
ConfirmAction
CancelAction
ChoiceRoom
ChoiceDevice
helper:
devicemap:
Channels:
Colors:
devices:
Anwesenheit.dum:
intents:
Bad.Alarm:
intents:
Gaeste_WC.Alarm:
intents:
Garage:
intents:
Garage.closeslit.notify:
intents:
Garage.down.notify:
intents:
Garage.open.notify:
intents:
Garage.slit.notify:
intents:
Garagentor.Alarm:
intents:
Garagentor.Kontakt:
intents:
Garagentor_notify:
intents:
Rhasspy:
intents:
Roll.SZFelix.Luecke.Fahrbefehl:
intents:
Roll.SZGisbert.Luecke.Fahrbefehl:
intents:
Roll.SchlafzimmerFelix.Luecke:
intents:
Roll.SchlafzimmerGisbert.Luecke:
intents:
Roll.Sued.Luecke:
intents:
Roll.Sued.Luecke.Fahrbefehl:
intents:
Roll.Terrasse.Luecke:
intents:
Roll.Terrasse.Luecke.Fahrbefehl:
intents:
Roll.West.Luecke:
intents:
Roll.West.Luecke.Fahrbefehl:
intents:
RollladenSchlafzimmerFelix:
alias szfelix
groups rollladen
names szfelix
rooms googleassistant,rollladen
intents:
RollladenSchlafzimmerGisbert:
alias rollladen schlafzimmer
groups rollladen
names rollladen schlafzimmer, rollladen gisbert
rooms rollladen
intents:
GetOnOff:
GetOnOff:
currentVal state
type GetOnOff
valueOff off
SetOnOff:
SetOnOff:
cmdOff off
cmdOn on
response "All right"
type SetOnOff
RollladenWohnzimmerSued:
alias wzsüd
groups rollladen
names wzsüd
rooms googleassistant,rollladen
intents:
RollladenWohnzimmerTerrasse:
alias wzterrasse
groups rollladen
names wzterrasse
rooms googleassistant,rollladen
intents:
RollladenWohnzimmerWest:
alias rollladen westseite
groups rollladen
names rollladen westseite
rooms rollladen
intents:
RollladengruppeOG:
intents:
RollladengruppeUp:
intents:
RollladengruppeWZ:
intents:
SZ.Gisbert.Alarm:
intents:
Treppenhaus.Markise:
intents:
Treppenhaus.Markise.hoch.notify:
intents:
Treppenhaus.Markise.runter.notify:
intents:
TreppenhausMarkisenBefehl:
intents:
mymonitoring:
intents:
rhasspyMQTT2:
intents:
rhasspyRooms:
googleassistant:
szfelix RollladenSchlafzimmerFelix
wzsüd RollladenWohnzimmerSued
wzterrasse RollladenWohnzimmerTerrasse
rollladen:
rollladen gisbert RollladenSchlafzimmerGisbert
rollladen schlafzimmer RollladenSchlafzimmerGisbert
rollladen westseite RollladenWohnzimmerWest
szfelix RollladenSchlafzimmerFelix
wzsüd RollladenWohnzimmerSued
wzterrasse RollladenWohnzimmerTerrasse
lng:
responses:
DefaultCancelConfirmation Thanks aborted
DefaultChangeIntentRequestRawInput change command to $rawInput
DefaultChoiceNoOutstanding no choice expected
DefaultConfirmation OK
DefaultConfirmationBack So once more
DefaultConfirmationNoOutstanding no command is awaiting confirmation
DefaultConfirmationReceived ok will do it
DefaultConfirmationRequestRawInput please confirm: $rawInput
DefaultConfirmationTimeout Sorry too late to confirm
DefaultError Sorry but something seems not to work as expected
NoActiveMediaDevice Sorry no active playback device
NoDeviceFound Sorry but I could not find a matching device
NoMappingFound Sorry but I could not find a suitable mapping
NoMediaChannelFound Sorry but requested channel seems not to exist
NoNewValDerived Sorry but I could not calculate a new value to set
NoTimedOnDeviceFound Sorry but device does not support requested timed on or off command
NoValidData Sorry but the received data is not sufficient to derive any action
RequestChoiceDevice there are several possible devices, choose between $first_items and $last_item
RequestChoiceRoom more than one possible device, please choose one of the following rooms $first_items and $last_item
SilentCancelConfirmation
duration_not_understood Sorry I could not understand the desired duration
reSpeak_failed i am sorry i can not remember
timeRequest it is $hour o clock $min minutes
timerCancellation $label for $room deleted
weekdayRequest today is $weekDay, $month the $day., $year
Change:
brightness $device was set to $value
desired-temp target temperature for $location is set to $value degrees
humidity air humidity in $location is $value percent
knownType $mappingType in $location is $value percent
setTarget $device is set to $value
soilMoisture soil moisture in $location is $value percent
unknownType value in $location is $value percent
volume $device set to $value
waterLevel water level in $location is $value percent
battery:
0 battery level in $location is $value
1 battery level in $location is $value percent
temperature:
0 temperature in $location is $value
1 temperature in $location is $value degrees
timerEnd:
0 $label expired
1 $label in room $room expired
timerSet:
0 $label in room $room has been set to $seconds seconds
1 $label in room $room has been set to $minutes minutes $seconds
2 $label in room $room has been set to $minutes minutes
3 $label in room $room has been set to $hours hours $minutetext
4 $label in room $room has been set to $hour o clock $minutes
5 $label in room $room has been set to tomorrow $hour o clock $minutes
stateResponses:
inOperation:
0 $deviceName is ready
1 $deviceName is still running
inOut:
0 $deviceName is out
1 $deviceName is in
onOff:
0 $deviceName is off
1 $deviceName is on
openClose:
0 $deviceName is open
1 $deviceName is closed
units:
unitHours:
0 hours
1 one hour
unitMinutes:
0 minutes
1 one minute
unitSeconds:
0 seconds
1 one second
shortcuts:
tweaks:
Attributes:
room Rhasspy
Viele Grüße Gisbert
Nimm lieber "genericDeviceType=.+".
Danach muss ein " set ... update" gemacht werden, damit das auch an Rhasspy gesendet wird (wg. der slots-Erstellung).
In https://forum.fhem.de/index.php/topic,119447.msg1188601.html#msg1188601 (https://forum.fhem.de/index.php/topic,119447.msg1188601.html#msg1188601) findest du eine aktualisierte Fassung, die ein paar der hier aufgetauchten Verständnisschwierigkeiten und auch "blinds" mit aufgreift.
Ich würde weiter vermuten, dass
devspec=genericDeviceType=.+für deinen Anwendungsfall die deutlich bessere Wahl wäre. Das ist in der o.g. Fassung der default, wenn man keine Angaben in DEF macht.
Du hast sonst einfach viel zu viele Devices mit drin, die keine Relevanz haben (z.B. rhasspyMQTT2 oder Rhasspy (die RHASSPY-Instanz) lassen sich nicht wirklich gut steuern).
Da du ja aber schon früher mal eine Sprachsteuerung eingesetzt hattest, müßte sich das eine oder andere Device finden lassen, und wenn dann die Struktur unter "helper" erst mal was enthält, wird es in der Regel klarer, wie die Zusammenhänge sind. Übrigens sind Rollläden mAn. nicht unbedingt die idealen Devices, weil uU. on/off mit denen gar nicht über den slot $...onOffDevice geht... Würde zum Einstieg eine (dimmbare) Lampe oder ein einfaches Relay empfehlen.
Ansonsten hast du auch noch keine Sprachfile konfiguriert, die Antworten kommen dann noch auf "denglish"... (Aber erst mal Schritt 1: das erste Device ans Laufen bringen).
Falls du wieder Fragen zu einem speziellen Gerät hast, das in der devicemap auftaucht, aber für dich "komisch" aussieht, solltest du eine RAW-Def hier einstellen (ohne Readings), damit ich ggf. besser sehen oder simulieren kann, an was es hängt.
Nachtrag noch: Der Thread-Titel ist zwischenzeitlich etwas seltsam, oder...?
Hallo Jörg,
ich stehe immer noch wie ein Ochs vorm Berg.
Das neue Modul ist eingespielt.
genericDeviceType ist von Google Assistant per Pull down belegt. Wenn ich bei einem Homematicgerät versuche den Wert in der raw-Definition auf ".+" zu ändern, lässt das Fhem auch nicht zu. Also komme ich hier nicht weiter.
Gut, dann ein Dummy-Device, welches on/off versteht, das kann man per raw-Definition zu ".+" abändern; dieses Device ist im room Network enthalten. Diesen Raumnamen habe ich in der Rhasspy-Definition ergänzt und Rhasspy upgedated.
Die Frage ist, wie es jetzt weitergeht - ich weiß es leider noch nicht.
Hier ist die raw-Definition des Dummy-Devices:
defmod Zuhause.Felix dummy
attr Zuhause.Felix devStateIcon on:user_available@red off:user_ext_away@gray
attr Zuhause.Felix genericDeviceType .+
attr Zuhause.Felix icon user_unknown
attr Zuhause.Felix room Heizung,Network
attr Zuhause.Felix setExtensionsEvent 1
attr Zuhause.Felix setList on off
attr Zuhause.Felix useSetExtensions 1
attr Zuhause.Felix userReadings _state {ReadingsVal('Zuhause.Felix','state','') eq "on" ? 1:0}
Ich werde erst nächstes WE wieder mehr Zeit zur Verfügung haben. Den Titel ändere ich noch.
Viele Grüße Gisbert
Also nochmal von vorn, wir scheinen aneinander vorbei zu reden:
Wenn ich von "devspec=genericDeviceType=.+" gesprochen(*) hatte, meinte ich damit eine Angabe im RHASSPY-Device. Die Wirkung dieser devspec ist schlicht, dass RHASSPY alle FHEM-Devices als "Zielgeräte" ansehen soll, die _mindestens ein Zeichen_ in dem betreffenden Attribut(**) stehen haben. _Was dort konkret steht_, ist dabei in Schritt 1 erst mal völlig egal.
Ergo ist es nicht nötig, _genau_ ".+" in das Attribut zu schreiben, sondern das kann u.a. sein: "blind", "blinds", "light", "X", ....
Welche das bei dir sind und welche Werte gesetzt sind, würdest du mit "list genericDeviceType=.+ genericDeviceType" sehen. Falls da irgendwas kommt, kannst du es erst mal gut sein lassen.
((**) - ja, theoretisch umfasst das auch Geräte, die ein entsprechendes Reading oder Internal gesetzt haben...)
(*) Seit 0.5.01 ist "devspec=genericDeviceType=.+" das, was RHASSPY automatisch setzt, wenn man gar keine Angabe macht (abgesehen von einer einzigen Ausnahme).
Nochmal zum grundsätzlichen Verständnis "meiner Philosophie" bei der Überarbeitung des ursprünglichen Moduls: Der User soll möglichst wenig selbst machen _müssen_, das meiste soll automatisch passieren. Dafür genügen sehr wenige Angaben, die Quintessenz ist eigentlich immer: Was ist das für ein "Grund-Typ" (Rollladen, Licht, Relay, Medienspieler, ...)? Anhand dieses Grund-Typs (der in genericDeviceType zu finden ist) versucht das RHASSPY-Modul dann die vorhandenen Setter auszuwerten.
Also sowas wie:
- 'Aha, das ist ein Licht. Es versteht aber nur "an" und "aus".' Oder:
- 'Aha, das ist ein Licht. Es versteht nicht nur "an" und "aus", sondern auch noch Helligkeit und Farbe (in HUE, von ... bis ...).'
Im Ergebnis musst du also eigentlich bitte erst mal alle verkrampften Versuche unterlassen, irgendwas "geradebiegen" zu wollen. Du brauchst an den Devices dann nämlich nur noch das im Detail nachzukonfigurieren, was dir nach der Automatik noch nicht gefällt. Das sind in der Regel eher Dinge wie Namen und Gruppenzugehörigkeiten. Lass' diese ganzen Gimmicks für die ersten Schritte bitte einfach weg! Falls noch nicht vorhanden, setz den gDT und lass die Erkennung drüber laufen, basta. Wenn dann in dem RHASSPY-list alles einigermaßen sauber aussieht, schaust du, ob die Infos auch bei Rhasspy (in den slots) angekommen sind. Erst wenn das soweit geklappt hat, geht es ggf. an die Feinarbeiten.
Ergo:
delete Zuhause.Felix
und starte mit diesen hier:defmod rhasspyMQTT2 MQTT2_CLIENT 192.168.1.46:12183
attr rhasspyMQTT2 clientOrder RHASSPY
attr rhasspyMQTT2 subscriptions setByTheProgram
(unterstellt, IP und Port passen noch)
Und
defmod Rhasspy RHASSPY baseUrl=http://192.168.1.46:12101
Hallo Jörg,
im wesentlichen konnte ich deinen Ausführungen folgen.
In den Slots (insgesamt 14 Stück) stehen unter z.B. in de.fhem.AllKeywords jetzt folgende Einträge:
Zitatzuhause.felix
rollladen gisbert
wzsüd
rollladen schlafzimmer
network
rollladen westseite
heizung
rollladen
googleassistant
szfelix
wzterrasse
Manche Einträge scheinen ein Überbleibsel meiner Bemühungen zu sein, es sind auch Fhem-Raumnamen dabei. Manche Fhem-Rollladendevices werden verständlich wiedergegeben (rollladen schlafzimmer) andere etwas verschmurgelt (szfelix, wzsüd, wzterrasse), man ahnt/weiß aber, worauf es sich bezieht.
Ok, ein Schritt weiter - wir sind aber noch nicht beim Sprechen.
Zur Sicherheit nochmals die beiden für Rhasspy benötigten Fhem-Devices:
Internals:
DEF baseUrl=http://192.168.1.46:12101 devspec=genericDeviceType=.+ language=de
FUUID 61978863-f33f-e986-532e-c2d28847a3d59476
IODev rhasspyMQTT2
LANGUAGE de
LASTInputDev rhasspyMQTT2
MODULE_VERSION 0.5.01
MSGCNT 3
NAME Rhasspy
NR 1207
STATE online
TYPE RHASSPY
baseUrl http://192.168.1.46:12101
defaultRoom default
devspec genericDeviceType=.+
encoding utf8
fhemId fhem
prefix rhasspy
rhasspyMQTT2_MSGCNT 3
rhasspyMQTT2_TIME 2021-11-24 20:57:04
useGenericAttrs 1
READINGS:
2021-11-24 20:56:48 IODev rhasspyMQTT2
2021-11-24 20:56:48 intents ChangeLightState,GetTemperature,GetTime,GetGarageState
2021-11-20 14:23:28 listening_default 0
2021-11-20 14:36:02 listening_master 0
2021-11-21 21:16:59 siteIds Pixel4a
2021-11-24 20:57:04 state online
2021-11-24 20:57:04 training Training completed in 6.56 second(s)
2021-11-19 20:34:33 updateSentences Wrote 21 char(s) to ['/opt/rhasspy/profiles/de/intents/de.fhem.Shortcuts.ini']
2021-11-24 20:56:58 updateSlots OK
TIMER:
Rhasspy_null:
HASH Rhasspy
MODIFIER null
NAME Rhasspy_null
enable false
toDisable:
ConfirmAction
CancelAction
ChoiceRoom
ChoiceDevice
helper:
bm:
CODE(0x55c8cb525340):
cnt 2
dmx -1000
dtot 0
dtotcnt 0
mTS 24.11. 20:49:06
max 0.0168130397796631
tot 0.0323879718780518
mAr:
HASH(0x55c8cb5209b0)
ARRAY(0x55c8cdabdc08)
HASH(0x55c8cd538700)
CODE(0x55c8cb527370):
cnt 58
dmx -1000
dtot 0
dtotcnt 0
mTS 24.11. 17:28:20
max 0.403781890869141
tot 0.767587900161743
mAr:
HASH(0x55c8cb5209b0)
ARRAY(0x55c8cc27d098)
HASH(0x55c8cdcf7f58)
devicemap:
Channels:
Colors:
devices:
RollladenSchlafzimmerFelix:
alias szfelix
groups rollladen
names szfelix
rooms googleassistant,rollladen
intents:
SetNumeric:
setTarget:
cmdStop Stop
RollladenSchlafzimmerGisbert:
alias rollladen schlafzimmer
groups rollladen
names rollladen schlafzimmer, rollladen gisbert
rooms rollladen
intents:
GetOnOff:
GetOnOff:
currentVal state
type GetOnOff
valueOff off
SetNumeric:
setTarget:
cmdStop Stop
SetOnOff:
SetOnOff:
cmdOff off
cmdOn on
response "All right"
type SetOnOff
RollladenWohnzimmerSued:
alias wzsüd
groups rollladen
names wzsüd
rooms googleassistant,rollladen
intents:
SetNumeric:
setTarget:
cmdStop Stop
RollladenWohnzimmerTerrasse:
alias wzterrasse
groups rollladen
names wzterrasse
rooms googleassistant,rollladen
intents:
SetNumeric:
setTarget:
cmdStop Stop
RollladenWohnzimmerWest:
alias rollladen westseite
groups rollladen
names rollladen westseite
rooms rollladen
intents:
SetNumeric:
setTarget:
cmdStop Stop
Zuhause.Felix:
alias zuhause.felix
names zuhause.felix
rooms heizung,network
intents:
rhasspyRooms:
googleassistant:
szfelix RollladenSchlafzimmerFelix
wzsüd RollladenWohnzimmerSued
wzterrasse RollladenWohnzimmerTerrasse
heizung:
zuhause.felix Zuhause.Felix
network:
zuhause.felix Zuhause.Felix
rollladen:
rollladen gisbert RollladenSchlafzimmerGisbert
rollladen schlafzimmer RollladenSchlafzimmerGisbert
rollladen westseite RollladenWohnzimmerWest
szfelix RollladenSchlafzimmerFelix
wzsüd RollladenWohnzimmerSued
wzterrasse RollladenWohnzimmerTerrasse
lng:
responses:
DefaultCancelConfirmation Thanks aborted
DefaultChangeIntentRequestRawInput change command to $rawInput
DefaultChoiceNoOutstanding no choice expected
DefaultConfirmation OK
DefaultConfirmationBack So once more
DefaultConfirmationNoOutstanding no command is awaiting confirmation
DefaultConfirmationReceived ok will do it
DefaultConfirmationRequestRawInput please confirm: $rawInput
DefaultConfirmationTimeout Sorry too late to confirm
DefaultError Sorry but something seems not to work as expected
NoActiveMediaDevice Sorry no active playback device
NoDeviceFound Sorry but I could not find a matching device
NoMappingFound Sorry but I could not find a suitable mapping
NoMediaChannelFound Sorry but requested channel seems not to exist
NoNewValDerived Sorry but I could not calculate a new value to set
NoTimedOnDeviceFound Sorry but device does not support requested timed on or off command
NoValidData Sorry but the received data is not sufficient to derive any action
RequestChoiceDevice there are several possible devices, choose between $first_items and $last_item
RequestChoiceRoom more than one possible device, please choose one of the following rooms $first_items and $last_item
SilentCancelConfirmation
duration_not_understood Sorry I could not understand the desired duration
reSpeak_failed i am sorry i can not remember
timeRequest it is $hour o clock $min minutes
timerCancellation $label for $room deleted
weekdayRequest today is $weekDay, $month the $day., $year
Change:
brightness $device was set to $value
desired-temp target temperature for $location is set to $value degrees
humidity air humidity in $location is $value percent
knownType $mappingType in $location is $value percent
setTarget $device is set to $value
soilMoisture soil moisture in $location is $value percent
unknownType value in $location is $value percent
volume $device set to $value
waterLevel water level in $location is $value percent
battery:
0 battery level in $location is $value
1 battery level in $location is $value percent
temperature:
0 temperature in $location is $value
1 temperature in $location is $value degrees
timerEnd:
0 $label expired
1 $label in room $room expired
timerSet:
0 $label in room $room has been set to $seconds seconds
1 $label in room $room has been set to $minutes minutes $seconds
2 $label in room $room has been set to $minutes minutes
3 $label in room $room has been set to $hours hours $minutetext
4 $label in room $room has been set to $hour o clock $minutes
5 $label in room $room has been set to tomorrow $hour o clock $minutes
stateResponses:
inOperation:
0 $deviceName is ready
1 $deviceName is still running
inOut:
0 $deviceName is out
1 $deviceName is in
onOff:
0 $deviceName is off
1 $deviceName is on
openClose:
0 $deviceName is open
1 $deviceName is closed
units:
unitHours:
0 hours
1 one hour
unitMinutes:
0 minutes
1 one minute
unitSeconds:
0 seconds
1 one second
shortcuts:
tweaks:
Attributes:
room RhasspyInternals:
BUF
Clients :RHASSPY:
ClientsKeepOrder 1
DEF localhost:1883
DeviceName localhost:1883
FD 72
FUUID 61978527-f33f-e986-ee32-8a8fd1dc8a8f3bb5
NAME rhasspyMQTT2
NR 1206
PARTIAL
STATE opened
TYPE MQTT2_CLIENT
WBCallback
clientId rhasspyMQTT2
lastMsgTime 1637784344.46074
nextOpenDelay 5
MatchList:
1:RHASSPY ^.
READINGS:
2021-11-24 20:52:40 state opened
helper:
bm:
MQTT2_CLIENT_Attr:
cnt 1
dmx -1000
dtot 0
dtotcnt 0
mTS 24.11. 20:52:40
max 0.0464980602264404
tot 0.0464980602264404
mAr:
set
rhasspyMQTT2
subscriptions
setByTheProgram
MQTT2_CLIENT_Read:
cnt 1330
dmx -1000
dtot 0
dtotcnt 0
mTS 24.11. 14:43:51
max 0.0424458980560303
tot 0.583535432815552
mAr:
HASH(0x55c8cb46a0d0)
MQTT2_CLIENT_Set:
cnt 21
dmx -1000
dtot 0
dtotcnt 0
mTS 24.11. 20:51:42
max 0.000118017196655273
tot 0.00121641159057617
mAr:
HASH(0x55c8cb46a0d0)
rhasspyMQTT2
?
MQTT2_CLIENT_connect:
cnt 4
dmx -1000
dtot 0
dtotcnt 0
mTS 24.11. 14:44:43
max 0.00244498252868652
tot 0.00421881675720215
mAr:
HASH(0x55c8cb46a0d0)
Attributes:
clientOrder RHASSPY
room Rhasspy
subscriptions setByTheProgram
username gis23Viele Grüße Gisbert
:) Geht doch voran...
Jetzt sollten wir als erstes mal versuchen, dein Handy zu einer Sprachantwort zu überreden. Leider war mir insgesamt nicht mehr gegenwärtig, dass RHASSPY etwas anders "filtert" als früher, und daher der eingestellte "GetTime"-Intent nicht mehr unmittelbar funktioniert.
Da bei dir
2021-11-24 20:56:48 intents ChangeLightState,GetTemperature,GetTime,GetGarageState
kommt, wird entsprechender Input als "nicht für mich" verworfen. Alles, was an diese RHASSPY-Instanz gehen soll, braucht "de.fhem:" vorneweg. In der sentences.ini muss der Intent also so benannt werden:
[de.fhem:GetTime]
In den "keywords" sind keine "Überbleibsel", die slots werden jedes mal nach einem "update slots" neu generiert und komplett überschrieben. Da hier aber zu erkennen ist, dass manches von vornherein keinen Sinn macht (room: googleassistant), werde ich mir mal überlegen, wie man sowas vorab rausfiltern kann (=> bitte hin und wieder in den dev-Thread schauen, ob da was kommt). Es stört aber auch im Moment nicht zu sehr => erst mal ignorieren.
Deine Rollladen-Devices scheinen sehr speziell zu sein. Bitte mal zeigen, was
{getAllSets('RollladenSchlafzimmerGisbert')} liefert (und Infos zum TYPE).
Falls da ein ESP8266 werkelt, würde ich mal einen Blick auf Tasmota empfehlen, falls es was anderes ist, wäre evtl. ROLLO als Zwischenschicht eine Idee. Jedenfalls sind das anscheinend keine guten Einsteigergeräte.
Hast du nicht irgendein "normales" dimmbares Licht, dem du mal gDT "light" verpassen kannst?
Hallo Jörg,
unter Sentences, sentences.ini steht jetzt:
[GetTime]
wie spät ist es
sag mir die uhrzeit
[GetTemperature]
wie ist die temperatur
wie (heiß | kalt) ist es
[GetGarageState]
ist das garagentor (offen | geschlossen)
[ChangeLightState]
light_name = (wohnzimmerlampe | garagenlicht) {name}
light_state = (ein | aus) {state}
schalte (die | das) <light_name> <light_state>
[de.fhem:GetTime]
wie spät ist es
sag mir die uhrzeit
Speichern und set Rhasspy update all führt zu folgendem Reading:
2021-11-25 17:55:09 intents GetTime,GetTemperature,ChangeLightState,GetGarageState,de.fhem:GetTime
{getAllSets('RollladenSchlafzimmerGisbert')} liefert
opens:noArg closes:noArg DriveUp:noArg Stop:noArg DriveSlit:noArg DriveDown:noArg Event:Up,Stop,Slit,Down
Es ist kein Problem ein on/off open/close ... in die Liste mitaufzunehmen, das geht mit dem Attribut eventMap.
opens/closes hat Google Assistant verlangt, also hab ich es zugefügt - die anderen hab ich mir ausgedacht:
eventMap /Event Up:opens/Event Down:closes/Event Up:DriveUp/Event Stop:Stop/Event Slit:DriveSlit/Event Down:DriveDown
Das physische Device ist ein ESP8266 mit Tasmota - in FHEM allerdings ein MQTT_DEVICE.
Viele Grüße Gisbert
Mobil&kurz: intents-Namen in sentences.INI ändern/ergänzen.
Langform:
Den Doppeleintrag habe ich nicht gesehen. Starte bitte einfach mal mit nur dem hier (keine weiteren intents):
[de.fhem:GetTime]
wie spät ist es
sag mir die uhrzeit
Dann: Um den Rollladen müssen wir uns gesondert kümmern. Das geht besser...
Zuletzt: wir brauchen ein Licht, bitteschön :) .
1. Punkt erledigt.
2. Punkt: bitteschön, hier ist ein Licht (das Device heißt Wohnzimmer.Licht), Auszug aus helper:
Wohnzimmer.Licht:
alias wohnzimmer.licht
groups switch
names wohnzimmer.licht
rooms homehm
intents:
GetOnOff:
GetOnOff:
currentVal state
type GetOnOff
valueOff off
SetOnOff:
SetOnOff:
cmdOff off
cmdOn on
type SetOnOff
Viele Grüße Gisbert
Notiz an mich selbst: nicht mehr wie 1-2 Aspekte auf einmal...
1a) ...dann sollte jetzt eine Antwort* auf "wie spät ist es" kommen?
1b) *die ist denglisch... => languageFile.
Guten Morgen Jörg,
die Spracheingabe in der Android-App funktioniert, es kommt eine denglische Antwort zurück. Ich denke, dass damit ein erster Meilenstein geschafft ist.
Eine kleine Klippe konnte ich selbst umschiffen. In Rhasspy (Rhasspy Voice Assistant) musste ich die SiteId auf den Wert einstellen, der im Reading von RHASSPY steht (gleicher Wert steht auch in der Einstellung der Android-App).
Antwort ist schon mal schön, englisch oder deutsch noch schöner, wobei mir die Antworten eigentlich weniger wichtig sind.
Mit dem Licht hab ich folgendes experimentiert (in sentences.ini):
[de.fhem:SetOnOff]
(schalte an){Value:on} $de.fhem.Device{Device} [$de.fhem.Room{Room}]
(schalte aus){Value:off} $de.fhem.Device{Device} [$de.fhem.Room{Room}]
Hinweis: Github hat einen kleinen Fehler, ")" statt "}", hinter on.
Reaktion in der Android-App: "ok", und Anzeige der identifizierten Worte. Allerdings wird die Eingabe so erwartet: "schalte ein wohnzimmer.licht", damit was sinnvolles passiert.
Der Groschen kommt gerade mächtig ins Rutschen :)
Viele Grüße Gisbert
Zitat
Der Groschen kommt gerade mächtig ins Rutschen :)
:) "blink" wird gerne unterschätzt... ;D
Zitat
Allerdings wird die Eingabe so erwartet: "schalte ein wohnzimmer.licht", damit was sinnvolles passiert.
Dann kümmern wir uns jetzt mal um die zwei Aspekte, die da drin stecken:
Ziel ist sowas:
"Schalte die Stehleuchte im Wohnzimmer an" oder "Schalte die Stehleuchte an" (gesprochen im Wohnzimmer*) soll denselben Effekt haben.
Dazu gibt es zum einen die Stellschraube sentences.ini:[de.fhem:SetOnOff]
schalte (den|die|das) $de.fhem.Device{Device} [(im|in (der|dem)) $de.fhem.Room{Room}] ( an{Value:on} | aus{Value:off} )
Da sind ein paar Alternativen und optionale Elemente drin, neben der offiziellen Doku würde ich mal empfehlen, dieses Video zu schauen: https://www.youtube.com/watch?v=sWVl0ZoXZEo (https://www.youtube.com/watch?v=sWVl0ZoXZEo)
Weiter wäre meine Empfehlung, in diesem Kontext dann einen anderen slot zu wählen, nämlich den, der nur die Geräte enthält, die "an" und "aus" "können": $de.fhem.Device-SetOnOff
Jetzt sollte funktionieren:
"Schalte die wohnzimmer.licht in der Wohnzimmer an" oder "Schalte das wohnzimmer.licht an" (gesprochen im Wohnzimmer*)
Zu * könntest du bei Gelegenheit "siteId2room" in der commandref suchen, ist aber eher eine Zusatzaufgabe für Fortgeschrittene ;) . (Wer nicht die App benutzt, kann seine siteId's bitte direkt passend benennen!)
2. Aspekt: Namensvergabe in FHEMWie du gesehen hast, greift sich RHASSPY bei der Auswertung deiner Geräte das an Infos, was vorhanden ist. Bei diesem Gerät gibt es z.B. keinen "alias" oder auch keinen "siriName", also nimmt RHASSPY notgedrungen erst mal den technischen Gerätenamen. Zur Vermeidung von Tippfehlern auf beiden Seiten wird dann (fast) für alles einheitlich Kleinschreibung verwendet. Nur Variablen und die Namen der "Übergabe-Felder" werden anders behandelt.
Ergo vergibst du jetzt bitte als erstes mal einen "alias" für dein Licht. Danach "update devicemap" und schauen, was im RHASSPY-list und in den slots zu finden ist.
Falls ein "Sprechname" nicht reicht, kannst du dich danach mal mit dem ersten "echten" RHASSPY-Attribut beschäfigen: rhasspyName. Tipp: nimm da mal was anderes als das, was in "alias" zu finden ist... (dann wieder update devicemap etc...).
PS: der nächste sinnvolle Schritt (wenn das alles klappt und RHASSPY deutsch spricht), wäre dann (mind.) eine weitere Lampe, optimalerweise dimmbar und farbig.
OT-Exkurs zu dem Rollladen-Thema:
In https://tasmota.github.io/docs/Blinds-and-Shutters/ ist die Info für die Grundkonfiguration zu finden. Damit sollten sich Tasmota-Versionen ab ca. 8.5 so konfigurieren lassen, dass ein "Prozent"-Fahrbefehl möglich ist. Nach dem, was in attrTemplate zu MQTT2_DEVICE zu finden ist, muss zum Anfahren von prozentualen Positionen weder JSON versandt werden noch braucht man für die Auswertung der Rückgabe ergänzenden Code, ergo sollte das auch als MQTT_DEVICE gehen.
Kommandos im Detail sind zu finden in https://tasmota.github.io/docs/Commands/#shutters, als Topics für den Prozentwert für das erste Relay-Paar werden (an den ESP) "CMNDTOPIC/ShutterPosition1" und kommend vom ESP "STATTOPIC/SHUTTER1" verwendet.
Damit sollte jemand mit Erfahrung in MQTT_DEVICE auch in der Lage sein, das Ding zu konfigurieren. Alternative: MQTT2_SERVER für anderen Port aufziehen und MQTT2_DEVICE anschauen.
Bitte bei Bedarf diese Infos kopieren und einen neuen Thread im MQTT-Bereich aufmachen. Dabei klarstellen, ob Ziel die Erweiterung des MQTT_DEVICE ist (da kann und will ich nicht helfen), oder der (testweise) Wechsel zu MQTT2_DEVICE.
Nachtrag noch: Unter https://wiki.fhem.de/wiki/Rhasspy habe ich jetzt mal einen "Quick-Start" ins Wiki gestellt.
Darfst gerne Rückmeldung geben, wenn da was unklar oder verbesserungswürdig ist, und ansonsten kannst du ja damit erst mal noch etwas weiterarbeiten.
Hallo Jörg,
das Wiki werde ich mir morgen anschauen und ggf. Vorschläge machen; am besten ich setze eckige Klammern rum und meinen Namen davor, dann musst du nicht lange suchen. Wenn es passt, dann kannst du es übernehmen.
Den Rollläden habe ich gDT blind verpasst und einen RhasspyName.
Meine Rollläden gehorchen in Fhem auf folgende Befehle:
set <Rollladen-Device> DriveUp|DriveDown|DriveSlit|Stop
Kann man Rhasspy davon überzeugen, diese Befehle umzusetzen?
Geht das mit RhasspyMapping? Muss ein neuer Slot angelegt werden?
Viele Grüße Gisbert
Zitat von: Gisbert am 27 November 2021, 21:41:20
Meine Rollläden gehorchen in Fhem auf folgende Befehle:
set <Rollladen-Device> DriveUp|DriveDown|DriveSlit|Stop
Kann man Rhasspy davon überzeugen, diese Befehle umzusetzen?
Geht das mit RhasspyMapping? Muss ein neuer Slot angelegt werden?
Vorbemerkung:
Im Wesentlichen schon, ABER: Meiner Ansicht nach ist dein Rollladen als Grund-Device nicht fertig konfiguriert... Was wir jetzt machen, ist ein Workaround, der AUSDRÜCKLICH NICHT ZUR NACHAHMUNG empfohlen ist!
Zumindest für die Anteile DriveUp, DriveDown und Stop geht es mit rhasspyMapping, benötigt werden die Intents SetOnOff und SetNumeric.
Hier mal, wie das ausschnittsweise im RHASSPY-list für einen Homematic-Rollladen aussieht:
SetNumeric:
setTarget:
cmd pct
cmdStop stop
currentVal pct
maxVal 100
minVal 0
step 13
type setTarget
SetOnOff:
SetOnOff:
cmdOff pct 0
cmdOn pct 100
type SetOnOffDas sollte dann für diese drei Befehle in etwa das hier ergeben:
attr <rollo> rhasspyMapping SetOnOff:cmdOn=DriveUp,cmdOff=DriveDown\SetNumeric:cmdStop=Stop,type=setTargetFür DriveSlit habe ich grade noch keine Idee, prinzipiell könnte es dafür mehrere Lösungsansätze geben. Macht aber erst Sinn, sich darüber Gedanken zu machen, wenn du als User die Gesamtzusammenhänge besser kennst. Bin auch am Überlegen, ob man "blind" (generisch) mit einer Art "scene"-Funktion ergänzen sollte, um solche "Spezialpositionen" besser abbilden zu können (ist aber dann ein Entwicklungsthema, aber z.B. somfy kennt "myPosition" o.ä.).
Nochmal zurück zur Eingangsbemerkung:
Falls deine Tasmotas im Web-Interface der ESP's slider für die Position haben: Sind die funktionsfähig, also wird der Rollladen dann jeweils an die richtige Position gestellt? Wenn nein, müßtest du erst noch die Laufzeiten konfigurieren.
Wenn das (schon/dann) klappt: magst du mal ein RAW-listing von dem MQTT_DEVICE einstellen? Dann versuche ich das doch mal mit den mapReadings_.* etc...
Dieser Weg ist im Ergebnis m.E. deutlich (!) einfacher!
Guten Morgen Jörg,
prinzipiell funktioniert dein Ansatz für DriveUp, DriveDown und Stop:
attr <device> rhasspyMapping SetOnOff:cmdOn=DriveUp,cmdOff=DriveDown\SetNumeric:cmdStop=Stop,type=setTarget
In Rhasspy hab ich das folgende definiert:
[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}]
(fahre) $de.fhem.Device{Device} (hoch){Value:DriveUp} [$de.fhem.Room{Room}]
(fahre) $de.fhem.Device{Device} (runter){Value:DriveDown} [$de.fhem.Room{Room}]
(halte) $de.fhem.Device{Device} (an){Value:Stop} [$de.fhem.Room{Room}]
(fahre) $de.fhem.Device{Device} (auf Lücke){Value:DriveSlit} [$de.fhem.Room{Room}]
Benötigt der Stop-Befehl nicht einen eigenen slot in sentence.ini? Es scheint aber so zu funktionieren.
Hier die raw-Definition meines Rollladen-Devices:
defmod RollladenSchlafzimmerGisbert MQTT_DEVICE
attr RollladenSchlafzimmerGisbert IODev MyBroker
attr RollladenSchlafzimmerGisbert alias SZGisbert
attr RollladenSchlafzimmerGisbert autoSubscribeReadings +/RollladenSZGisbert/+
attr RollladenSchlafzimmerGisbert cmdIcon DriveUp:fts_shutter_up@#2e5e87 Stop:fts_shutter_manual@grey DriveSlit:fts_shutter_shadding_stop@green DriveDown:fts_shutter_down@green
attr RollladenSchlafzimmerGisbert comment Platine: Shutter.zip
attr RollladenSchlafzimmerGisbert eventMap /Event Up:opens/Event Down:closes/Event Up:DriveUp/Event Stop:Stop/Event Slit:DriveSlit/Event Down:DriveDown
attr RollladenSchlafzimmerGisbert gassistantName Rollladen Schlafzimmer
attr RollladenSchlafzimmerGisbert genericDeviceType blind
attr RollladenSchlafzimmerGisbert group Rollladen
attr RollladenSchlafzimmerGisbert icon fts_shutter_automatic
attr RollladenSchlafzimmerGisbert publishSet_Event Up Stop Slit Down cmnd/RollladenSZGisbert/Event
attr RollladenSchlafzimmerGisbert
Ich benutze ja nach wie vor MQTT-DEVICE. DriveSlit (wie auch alle anderen Befehle) werden vom ESP8266/Tasmota empfangen und dort per Rule ausgewertet. Nur so ist gewährleistet, dass der Rollladen kurz vorm Fensterbrett/Boden anhält und auf Lücke steht; da kommt es ja auf Zehntel Sekunden an.
DriveSlit könnte über eine numerische Zahl von Rhasspy ins Rollladen-Device reinkommen, die ich dann in eventMap dann auf DriveSlit "biege". Wäre das eine Möglichkeit?
Viele Grüße Gisbert
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.
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
SetOnOff erwartet "on" oder "off". Da wird wohl alles als off interpretiert... => sentences.ini anpassen.
...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}]
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
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!
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|SlitIch 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
Hallo Gisbert,
du könntest den Intent MediaControls nutzen.
Gruß Jens
Vermutlich geht auch ein eventMap, das diskrete pct-Werte auf die Tasmota-Commamds mapt.
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)
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
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}
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=pctAbspeichern 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
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 (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'
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 (https://forum.fhem.de/index.php/topic,119447.msg1189987.html#msg1189987)
Vielen Dank und viele Grüße
Gisbert
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).
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 ;) .
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
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
Hast du mal ein list von einem der Geräte?
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
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...).
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 ;) .
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...
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.
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).
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..
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") }
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 felixAnschließ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 schlafzimmerHier 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 schlafzimmerHier 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
googleassistantHier 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
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.
Abgesehen davon, dass die Sentences nicht korrekt sind.
Der zweite Satz in [de.fhem:SetNumeric] ist ein MediaControls-Sentence.
Das mit dem Raum würde ich sicherheitshalber lieber so notieren:
[(im|in|in dem|auf dem|in der|auf der)] [$de.fhem.Room{Room}]
Zu dem Hinweis bzgl. stop: Das klappt (seit neuestem), wenn der blind das kann ;) . Stellt dann sogar bei Jalousien die Lamellen wieder auf den alten Stand, wenn man das entsprechend konfiguriert...
Deswegen schreibe ich ja, dass es sinnvoll ist, die eingeschränkten slots zu verwenden ;) . Sonst ist Verwirrung vorprogramiert....
Asche auf mein Haupt - ich hab mich schlicht bei rhasspyName und rhasspyRoom bei 2 von 5 Fhem-Devices verhauen - für mich ein leichter Gehirnverzwirner, da ich es immer anders gehandhabt habe. Kein Wunder, dass es dann wild durcheinander ging. Es macht aber Sinn den rhasspyName "rollladen" zu benennen und den rhasspyRoom "schlafzimmer,..." (in meinem Beispiel) zu benennen; das ist es ja auch das, was die Attributsnamen implizieren.
Viele Grüße Gisbert
Guten Morgen Jörg,
man muss sich ja immer etwas sammeln, bevor man einen Sprachbefehl abschickt. Wenn nicht, dann beendet Rhasspy bei Unterbrechungen die Aufnahme. Soweit so gut.
Mir ist beim Ausprobieren dann aufgefallen, dass Rhasspy Informationen ergänzt, die gar nicht beabsichtigt waren.
In sentences.ini hab ich die Angabe eines Raumes zwingend erforderlich gemacht, da ein Sprachbefehl wie
Zitatfahre den Rollladen hoch
auf alle Rollläden zutriffen könnte, allerdings möchte ich nicht alle öffnen.
sentences.ini (Auszug):
[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})In de.fhem.Room steht:
schlafzimmer gisbert
schlafzimmer von felix
wohnzimmer
schlafzimmer felix
zimmer von felix
zimmer felix
network
schlafzimmer von gisbert
heizung
meinem schlafzimmer
schlafzimmerWarum steht network und heizung drin? Ich hab es nirgends definiert. Es gibt aber in beiden Räumen Devices, die im Namen oder alias die Worte Schlafzimmer, Gisbert oder Felix enthalten. Oder könnten es Geräte mit on/off-Charakter sein, die Rhasspy veranlasst diese Räume aufzunehmen?
Wenn ich jetzt folgenden Satz spreche:
Zitatfahre den Rollladen hoch
gibt Rhasspy folgendes zurück:
Zitatfahre den Rollladen heizung hoch
Tatsächlich fährt er
meinen Rollladen hoch.
Wie kann ich verhindern, dass Rhasspy Informationen ergänzt, die gar nicht beabsichtigt sind? Lieber wäre mir keine Aktion und die Aufforderung Informationen zu ergänzen.
Viele Grüße Gisbert
Ergänzung:
Der gesprochene Befehl:
Zitatfahre den Rollladen im Arbeitszimmer hoch
wird zu:
Zitatfahre den Rollladen im Schlafzimmer hoch
Dein Satz in der sentences.ini erwartet einen Raum. Wird der nicht gesprochen, nimmt Rhasspy irgendeinen aus dem Slot. Wie genau die Auswahl erfolgt, hab ich auch noch nicht rausgefunden.
Um dein gewünschtes Ziel zu erreichen und alle Rollläden hochfahren zu können, müsstest du alle in eine Gruppe stellen und dafür den Intent SetOnOffGroup verwenden. Und natürlich "alle Rollläden" sprechen.
"network" und "heizung" werden schon irgendwo vorkommen. Ich vermute, als FHEM-Attribut "room".
"Arbeitszimmer" ist in dem Slot, den du gepostet hast, nicht enthalten. Deswegen nimmt Rhasspy einfach das, was am ähnlichsten klingt.
OK, vielleicht an der Stelle auch nochmal der Hinweis auf https://wiki.fhem.de/wiki/RHASSPY/Vertiefung (https://wiki.fhem.de/wiki/RHASSPY/Vertiefung), speziell (seit grade) https://wiki.fhem.de/wiki/RHASSPY/Vertiefung#.22must_match.22-Prinzip (https://wiki.fhem.de/wiki/RHASSPY/Vertiefung#.22must_match.22-Prinzip).
Ergo: Bitte mache den Raum wie bereits mehrfach empfohlen OPTIONAL! Solche ständigen Hinweise haben in der Regel einen Grund, auch wenn es in der Masse der Stellrädchen nicht immer gleich verständlich sein mag, warum etwas empfohlen wird, was einem zunächst unlogisch vorkommt...
Prüfe dann deine Annahme, ob "alle Rollläden" gefahren werden, wenn du eine raumlose Ansage machst ;) . (Und nein, wir werden zur Lösung dieses Themas erst später kommen!)
Danach wäre mein Tipp, dir https://wiki.fhem.de/wiki/RHASSPY#Beispiel:_Raumwechsel (https://wiki.fhem.de/wiki/RHASSPY#Beispiel:_Raumwechsel) anzusehen.
Zu guter Letzt: Wenn dir irgendwelche übertragenen Bestandteile in den slots seltsam vorkommen, bist du praktisch immer gut beraten, ein rhasspy-list nach dem betreffenden Bestandteil zu durchsuchen. Es gibt eher selten Ausnahmen zu diesem Grundprinzip.
Hallo Jörg,
vielen Dank für die prompte Antwort. Ich werde mir alle Dokumente anschauen und die Vorschläge umsetzen.
Die Räume hatte ich schon optional definiert. Als das geschilderte Verhalten auftrat, dachte ich, dass es mit zwingend erforderlichen Räumen nicht auftritt. Ich werde die Räume wieder optional angeben.
Viele Grüße Gisbert
Zitat"network" und "heizung" werden schon irgendwo vorkommen. ...
"Arbeitszimmer" ist in dem Slot, den du gepostet hast, nicht enthalten. Deswegen nimmt Rhasspy einfach das, was am ähnlichsten klingt.
Die Sache mit den Räumen "network" und "heizung" hat sich geklärt. Ich hatte in beiden Fhem-Räumen ein dummy-Device mit einem Attribut gDT versehen - wohl zum Üben bei den ersten Gehversuchen (ich Optimist, denn jetzt sind es immer noch Gehversuche).
Was mich allerdings nachdenklich stimmt ist, dass Rhasspy gnadenlos nach einer Lösung sucht.
Der gesprochene Satz: "fahre den rollladen im Klo hoch" wird zu "fahre den Rollladen in meinem Schlafzimmer hoch" - da sehe ich sprachlich zwischen "Klo" und "meinem Schlafzimmer" einen großen Unterschied. Ich würde etwas mehr Verbindlichkeit erwarten und im Zweifelsfall bei unklarer Aussprache oder Versprechern eher ein "Bitte wiederhole ..." als irgendeinen Befehl. Gibt es denn keine Möglichkeit, dass bei unklarer Lage lieber nichts gemacht wird?
Viele Grüße Gisbert
Zitat von: Gisbert am 07 Dezember 2021, 21:23:30
Was mich allerdings nachdenklich stimmt ist, dass Rhasspy gnadenlos nach einer Lösung sucht.
Dieses "must match"-Prinzip hat mir eine ganze Zeitlang auch Kopfzerbrechen bereitet...
Aus diesem Kopfzerbrechen sind zwei Dinge entstanden (Rhasspy hatte eine Vorliebe für meinen Verstärkter, und ich fand es nicht so lustig, dass das das "Lieblingszielgerät" von Rhasspy war :o ):
- zum einen die Option, bestimmte Geräte (oder Aktionen) nur nach Bestätigung auszuführen. Aus heutiger Sicht zwar ein wichtiger Schritt in Richtung von Dialogen, aber an sich ein workaround, dessen Anwendung ich zwischenzeitlich stark begrenzt habe.
- zum anderen die vielen slots. MAn. ist deren "korrekte" Verwendung der richtige Weg, um für hinreichend gute Ergebnisse zu sorgen. Setzt voraus, dass man prinzipiell sinnvolle Anweisungen spricht. "Mach den Rollladen im Klo zu" wird immer ein Problem bleiben, wenn es einen solchen dort nicht gibt...
Zitat
Der gesprochene Satz: "fahre den rollladen im Klo hoch" wird zu "fahre den Rollladen in meinem Schlafzimmer hoch" - da sehe ich sprachlich zwischen "Klo" und "meinem Schlafzimmer" einen großen Unterschied.
Na ja, wenn du unbedingt einen Room sprechen mußt, ist Rhasspy "gezwungen", einen auszuwählen... Wobei jetzt nicht ganz klar ist, ob Rhasspy noch das "Klo" sauber übergeben hatte, und die Abweichung zur Erwartung woanders (in RHASSPY) passiert ist (a), oder ob das schon ein "Problem" in der STT-Engine war (b). Wie dem auch sei, im nächsten update werden dann auch nochmal mehr Room-slots erzeugt werden, so dass man insbesondere auch für "blind"-Geräte dann auch eine eingeschränkte Raumliste verwenden kann...
Das führt aber im Zweifel dazu, dass aus "Klo" wirklich "Wohnzimmer" wird, weil "Klo" kein zulässiger Wert ist (entsprechend der Logik aus (b) iVm dem "must-match"-Prinzip).
Zitat
Ich würde etwas mehr Verbindlichkeit erwarten und im Zweifelsfall bei unklarer Aussprache oder Versprechern eher ein "Bitte wiederhole ..." als irgendeinen Befehl. Gibt es denn keine Möglichkeit, dass bei unklarer Lage lieber nichts gemacht wird?
Das Grundproblem ist, dass zumindest die per default verwendete STT-engine immer behauptet, das Ergebnis wäre klar. Ergo muss RHASSPY erst mal davon ausgehen, diese Behauptung wäre zutreffend (deshalb wird es bisher auch nicht geprüft).
Unterstellt, (a) wäre das "Problem":
- An sich schaut RHASSPY immer zuerst, ob die Aktion im gewünschten Raum klappt (und eindeutig ist). Geht das, wird genau das gemacht.
- Geht es nicht im Raum, wird geschaut, ob es nur genau eine Option gibt, das außerhalb des gewünschten Raumes zu machen. Wenn ja, wird geschaltet.
- Wenn auch das nicht eindeutig* ist (oder es mehrere Optionen im Wunsch-Raum gibt), erfolgt eine Rückfrage, und man kann den Raum bzw. das Gerät auswählen.
Falls also (a) das Problem gewesen war, unterstelle ich, dass es schlicht keinen zweiten Rollladen gegeben hat?
* Man kann für mehr Eindeutigkeit sorgen, indem man bestimmte Geräte als "vorzugswürdig" kennzeichnet...
Hoffe, das hilft irgendwie weiter?
Hallo Jörg,
hab nicht alles im Detail verstanden.
Was ich aber mitnehme ist, dass Rhasspy präzise Anweisungen verlangt, d.h. man muss sich beim Sprachbefehl konzentrieren und nicht einfach drauf los plappern.
Viele Grüße Gisbert
Weiß nicht, das war eigentlich eher nicht die Botschaft. Natürlich ist es wichtig, so zu sprechen, dass das zu dem paßt, was über sentences.ini abgebildet ist, aber in etwa genauso wichtig ist es, dass das, was sich als mögliche Sätze aus diesem "Verzweigungs-Muster" in den sentences.ini ergibt auch ausführbar ist. Deutlich sprechen mag auch helfen...
Neben gut strukturierten Sätzen ist es essentiell, dass die slots "sauber" sind, vielleicht solltest du da erst mal mit weniger Optionen für Räume arbeiten.
Hast du jetzt eine siteId2room-Logik für deinen mobilen Satelliten eingerichtet?
Nach meinem Eindruck wird das ganze nämlich schnell besser, wenn man zum einen nicht immer den Raum ansagen muss, und zum anderen mehr (verschiedene) Geräte da sind, die gesteuert werden können.
Hallo Jörg,
ZitatHast du jetzt eine siteId2room-Logik für deinen mobilen Satelliten eingerichtet?
Das habe ich nicht. Ich plane nur mit meinem Handy (das sauteuere Teil, was mit meiner linken Hand verwachsen ist ;D) als Spracheingabegerät.
Wenn ich die Limits kenne, kann ich mich ja darauf einstellen. Vermögende Leute haben Hauspersonal, die die Bitten der Herrschaften ausführen, unser einer macht es mit Technik wett.
Viele Grüße Gisbert
Gisbert, das war ein weiterer Zaunpfahl!
Ich nutze auch mehr oder weniger ausschließlich die Gedächtnisprothese, und habe mir was zum Thema überlegt, dass das Ding mal im Wohnzimmer, mal im Esszimmer oder im Büro ist...
Just do it!
ZitatWas ich aber mitnehme ist, dass Rhasspy präzise Anweisungen verlangt,
Darum gibt es Babble, mit den angeschlossenen Chatbot kann ich gut diskutieren.
ZitatVermögende Leute haben Hauspersonal, die die Bitten der Herrschaften ausführen, unser einer macht es mit Technik wett.
Vermögende Leute mit Intelligenz nutzen technisches Hauspersonal, wie eine KI.
LG
pah
@Gisbert:
Läuft jetzt eigentlich alles soweit und das mit siteId2room ist klar?
Ansonsten versuche mal:
setreading Rhasspy siteId2room_Pixel4a wohnzimmer
Vielleicht wird dann klarer, was das bewirkt...
Hallo Jörg,
vielen Dank für die Nachfrage.
Die grundlegenden Funktionen funktionieren ja, so dass ich außer der täglichen Anwendung keine weiteren Änderungen vorgenommen habe.
siteId2room ist mir noch nicht klar. Ich hab das setreading ausgeführt.
Wünschenswert wäre ein durchgängig gesprochener Aufruf wie bei "Ok Google" auf dem Handy. Schön wäre auch eine etwas abwechslungsreichere Antwort wie "Gerne!" Wenn es so was gibt, dann würde ich es gerne nutzen.
Viele Grüße Gisbert
Zitat von: Gisbert am 18 Dezember 2021, 21:05:49
Die grundlegenden Funktionen funktionieren ja, so dass ich außer der täglichen Anwendung keine weiteren Änderungen vorgenommen habe.
:) Das ist ja schon mal was...
Zitat
Schön wäre auch eine etwas abwechslungsreichere Antwort wie "Gerne!" Wenn es so was gibt, dann würde ich es gerne nutzen.
Gibt es in der aktuellen Version :) . Ein Beispiel, wie man das umsetzen kann, ist in https://svn.fhem.de/trac/browser/trunk/fhem/contrib/RHASSPY/rhasspy-de.cfg#L133 zu finden.
ZitatsiteId2room ist mir noch nicht klar. Ich hab das setreading ausgeführt.
Gut.
Etwas länger: Bin erst mal davon ausgegangen, dass dein Handy als Satellit weiter als Pixel4a benannt ist?
Dann sorgt dieses Reading dafür, dass RHASSPY diesen Satelliten (also dein Handy) dem Raum "wohnzimmer" zuordnet.
Dazu muss man wissen, dass man im Rhasspy-Ökosystem Satelliten üblicherweise immer nach dem Raum benennt, in dem sie zu finden sind, weswegen RHASSPY bei der Suche nach einem passenden Gerät bei fehlender Raumangabe (die ist bei dir in sentences.ini jetzt hoffentlich weiter optional?) zunächst in diesem Raum sucht, und die Aktion dann eben dort ausführt, (wenn das geht).
Da es ein Reading ist, kann man es ohne weiteres im laufenden Betrieb ändern. Dafür ist der Hilfscode/CustomIntent da...
ZitatWünschenswert wäre ein durchgängig gesprochener Aufruf wie bei "Ok Google" auf dem Handy.
Da ich Google nicht kenne, kann ich nur raten, was gemeint ist:
- wakeword ginge auch für die App, aber wie gesagt: Das läuft nicht lokal, weswegen ich das (meistens) nicht nutze. Vielleicht programmiert ja mal jemand eine lokale Extension dafür, es gibt zumindest jetzt wieder etwas Bewegung (alternativ zu dem von pah gezeigten Weg) für die Generierung von eigenen wakewords: https://community.rhasspy.org/t/picovoice-offline-voice-ai-engine-gets-free-tier-for-up-to-3-users/3328.
- Den Dialog nicht gleich zuzumachen, nachdem der erste Kommand ausgeführt wurde, kann man seit neuestem experimentell einstellen. Dir würde ich erst mal noch davon abraten, weil das aus Gründen, die ich auch noch nicht kenne, manchmal etwas seltsam reagiert.
Ich vermute, mit Gruppen-Intents hast du bisher nicht experimentiert? Das wäre m.E. der nächste Schritt und könnte den "Schmerz" eventuell etwas lindern, falls es dieser zweite Punkt war.
Hoffe, v.a. das mit siteId2room ist jetzt etwas klarer?
Grüße, Beta-User
Guten Morgen Jörg,
die abwechslungsreicheren Antworten habe ich heute morgen bemerkt; ich hab gestern abend das Modul upgedated. Jetzt bekomme ich "Jawohl", "zu Diensten", "Gerne", bin gespannt, wann "Sir, yes Sir" oder "Ai Captain" kommt ;D 8)
Kommt das Modul jetzt mit dem üblichen Fhem-Update, und was ist mit der cfg-Datei? Wird die dann auch automatisch upgedated?
Mein Pixel4a ist nach wie vor als Satellit vorhanden, und die Räume sind nach wie vor in sentences.ini weiter optional definiert. Mit deiner Erklärung ist siteId2room damit verständlich.
Mit Gruppen-Intents habe ich mich noch nicht beschäftigt. Ein Wakeword bei der Android-App wäre zwar schön, ist aber bei Weitem nicht so essentiell wie die tatsächliche Funktionalität.
Viele Grüße Gisbert
Zitat von: Beta-User am 19 Dezember 2021, 07:10:56
Gibt es in der aktuellen Version :) . Ein Beispiel, wie man das umsetzen kann, ist in https://svn.fhem.de/trac/browser/trunk/fhem/contrib/RHASSPY/rhasspy-de.cfg#L133 zu finden.
Coooool! :)
Zitat von: Gisbert am 19 Dezember 2021, 09:35:46
die abwechslungsreicheren Antworten habe ich heute morgen bemerkt; ich hab gestern abend das Modul upgedated. Jetzt bekomme ich "Jawohl", "zu Diensten", "Gerne", bin gespannt, wann "Sir, yes Sir" oder "Ai Captain" kommt ;D 8)
Zitat von: drhirn am 19 Dezember 2021, 10:08:36
Coooool! :)
8)
Diese Art, Alternativen anzugeben sollte übrigens zwischenzeitlich _überall_ funktionieren (nicht überall selbst getestet...).
Zitat
Kommt das Modul jetzt mit dem üblichen Fhem-Update, und was ist mit der cfg-Datei? Wird die dann auch automatisch upgedated?
Im Moment kommt nichts automatisch, man kann die Files aus dem contrib-Verzeichnis laden, was aber in deinem Fall nicht erforderlich ist, du bist mit den Files aus dem Nebenthread im Moment eh' auf Stand.
Mal sehen, vielleicht geht RHASSPY irgendwann in den normalen FHEM-update-Zyklus, im Moment würde ich gerne zumindest solange warten, bis die neuen Funktionen einigermaßen getestet sind.
Die languageFile sollte man eh' manuell anfassen, das wird man auch künftig manuell machen sollen (ist aber eher eine "Einmalaktion"). Warum, hatte ich hier oder im "Entwicklungs-Thread" neulich man eingehender erläutert.
Zitat
Mein Pixel4a ist nach wie vor als Satellit vorhanden, und die Räume sind nach wie vor in sentences.ini weiter optional definiert. Mit deiner Erklärung ist siteId2room damit verständlich.
Danke, dann erst mal viel Spaß beim testen. Erläuterungen zur myUtils sollte im Wiki zu finden sein, ansonsten hat die auch eine (sehr kurze) commandref, die man mit "helpRHASSPY_Utils_siteId2room" aufrufen kann (Verbesserungsvorschläge dürfen gemacht werden)...
ZitatMit Gruppen-Intents habe ich mich noch nicht beschäftigt.
Dann wäre das m.E. der nächste Schritt. Bitte im Wiki die "Fortgeschrittenen-Seite" konsultieren (https://wiki.fhem.de/wiki/RHASSPY/Vertiefung (https://wiki.fhem.de/wiki/RHASSPY/Vertiefung)) ;) .
Zitat von: Gisbert am 19 Dezember 2021, 09:35:46
Ein Wakeword bei der Android-App wäre zwar schön
Das geht doch, wenngleich es nur im eignen WLAN Sinn macht.
Es gibt einige Posts dazu. https://forum.fhem.de/index.php/topic,113180.msg1132773.html#msg1132773
Gruß Jens
Ich spiele seit kurzer Zeit mit Rhassspy, weil ich mein Snips nun leider ablösen musste.
Grundsätzlich funktioniert es, aber leider nicht so easy wie Snips.
Ich habe noch ein paar offene Fragen:
1. Kann man Rhasspy eigentlich so konfigurieren, dass an der base ein Mic und ein Lautsprecher dran ist und zusätzlich noch Satelliten anbinden?
2. Wie kann ich einen MPD damit steuern? (mit Snips ging das über Snips channels)
3. Wie kann man die Empfindlichkeit beim wake word beeinflussen?
4. Wie könnte man eine Wetteransage umsetzen?
VG Denis
Zitat von: denis.robel am 26 März 2022, 22:39:03
Grundsätzlich funktioniert es, aber leider nicht so easy wie Snips.
Snips kenne ich nicht, es würde mich aber interessieren, wo Snips "einfacher" war.
(Ok, RHASSPY ist seit gut einem Jahr deutlich umfangreicher in seinen Optionen im Detail, als RHASSPY 0.2 es war. Aber diese Optionen braucht man erst, wenn etwas nicht so funktioniert wie gedacht.)
Zitat
1. Kann man Rhasspy eigentlich so konfigurieren, dass an der base ein Mic und ein Lautsprecher dran ist und zusätzlich noch Satelliten anbinden?
Klar. Das ist vermutlich die häufigste bei FHEM-Usern eigesetzte Variante und in https://rhasspy.readthedocs.io/en/latest/tutorials/#server-with-satellites (https://rhasspy.readthedocs.io/en/latest/tutorials/#server-with-satellites) beschrieben.
Prinzipiell geht RHASSPY davon aus, dass es genau eine Base gibt, mit dem es kommuniziert. Die Satelliten sollten daher insbesondere "intent" über diese Base abwickeln (nur die kennt insbesondere die ganzen slots, die FHEM automatisch erstellt).
Zitat
2. Wie kann ich einen MPD damit steuern? (mit Snips ging das über Snips channels)
Klar. Für die Basisfunktionalität reicht es, ihn mit
attr myMPD genericDeviceType mediazu kennzeichnen und ggf. die devspec am RHASSPY zu ergänzen.
Meine "Sätze" dazu (die Variable für Räume muss dafür vorhanden sein):
[de.fhem:MediaControls]
( (stoppe|stop){Command:cmdStop} | (starte|start){Command:cmdPlay} ) [die wiedergabe] [am] [$de.fhem.Device-media{Device}][<de.fhem:SetOnOff.rooms>]
(pausiere | halte ){Command:cmdPause} [die wiedergabe] [am] [$de.fhem.Device-media{Device}] [<de.fhem:SetOnOff.rooms>] [an]
(nächstes|nächster){Command:cmdFwd} (lied|titel) [[(am|auf dem)] $de.fhem.Device-media{Device}] [<de.fhem:SetOnOff.rooms>]
(vorheriges|voriges|vorheriger|voriger){Command:cmdBack} (lied|titel) [$de.fhem.Device-media{Device}] [<de.fhem:SetOnOff.rooms>]
rhasspyChannels gibt es auch, das muss aber als userattr separat zugelassen werden. Ich vermute, dass der Weg über eine LightScene für Kanalwechsel usw. einfacher wäre*.
Zitat3. Wie kann man die Empfindlichkeit beim wake word beeinflussen?
Ja, siehe Rhasspy-Doku. Hängt halt vom verwendeten System ab... https://rhasspy.readthedocs.io/en/latest/services/#wake-word-detection (https://rhasspy.readthedocs.io/en/latest/services/#wake-word-detection)
Zitat4. Wie könnte man eine Wetteransage umsetzen?
Mache ich über GetState*, siehe Rückmeldung zu "get <RHASSPY> test_sentence ...":
wie wird das wetter heute => GetState {"Device":"wetter","Type":"heute","confidence":1,"customData":null,"input":"wie heute das wetter heute","intent":"GetState","lang":"de","rawInput":" wie wird das wetter heute","sessionId":"defhem_234_testmode","siteId":"defhem"} => Response: heute Den ganzen Tag lang Klar. Es hat zwischen 3 und 19 Grad und Wind bis 9 Kilometer pro Stunde.Das geht jetzt (seit ein paar Tagen, aktuelle svn-Version) auch für Type morgen und übermorgen und greift auf ein Weather-Device zu, wobei letzteres im Prinzip beliebig ist.
Bin noch nicht sicher, ob das der optimale Weg ist, aber hier mal ein "Satz" dazu:
wie ( ist | wird ){Type:heute} [das] wetter{Device} [ ( heute | morgen{Type:morgen} | übermorgen{Type:übermorgen} ) ]und das Device (auszugsweise):
attr DeinWetter genericDeviceType info
attr DeinWetter rhasspyMapping GetState:type=heute,response=heute [DeinWetter:fc1_condition] Es hat zwischen [DeinWetter:fc1_tempLow] und [DeinWetter:fc1_tempHigh] Grad und Wind bis [DeinWetter:fc1_wind] Kilometer pro Stunde.\
GetState:type=morgen,response=morgen [DeinWetter:fc2_condition] Es gibt zwischen [DeinWetter:fc2_tempLow] und [DeinWetter:fc2_tempHigh] Grad und Wind bis [DeinWetter:fc2_wind] Kilometer pro Stunde.\
GetState:type=übermorgen,response=Übermorgen [DeinWetter:fc3_condition] Es gibt zwischen [DeinWetter:fc3_tempLow] und [DeinWetter:fc3_tempHigh] Grad bei Wind bis [DeinWetter:fc3_wind] Kilometer pro Stunde.
attr DeinWetter rhasspyName wetter* bedeutet: Bin noch nicht sicher, was der beste Weg ist, und das ist Thema beim "RHASSPY mit Testsuite optimieren"-Thread...
Spannend ist, dass sobald ich für das Wakeword
den host:port:sitedid eintrge, geht die Wakeword Erkennung an der Base über die PS3 Eye nicht mehr. Lösche ich die Einträge klappt es von der Base.
Ich nutze Porcupine.
Mein Setup ist Fhem auf einem PI, mit eigenem MQTT2 Server auf 1883
Rhasspy im Container auf nem separaten Pi mit PS3 Eye, mit internem MQTT auf 20183
Ich habe im FHEM ein MQTT Client angelegt, der auf den internen MQTT Broker von RHASSPY zugreift und ein RHASSPY device.
Ich bekomme aber Wakeword detection von der App nicht hin.
Gibt es irgendwo ein Tutorial für den Mischbetrieb Lokales Mic an der Base + Sateliten via UDP?
Na ja, eigentlich ist das ein Thema, das m.E. besser im Rhasspy-Forum aufgehoben wäre.
Da meine base headless läuft, kann ich wenig weiterhelfen, gehe aber nach Lektüre dieses Threads bzw. Beitrags: https://community.rhasspy.org/t/udp-wakeword-detection-with-rhasspy-mobile-app/1795/17 davon aus, dass du auch den lokalen Audio-Input von der Base in einen UDP-Stream umleiten mußt (wie auch immer das genau geht).
Vielleicht hängst du dich direkt an den verlinkten Thread ran, da bekommst du vermutlich zu diesem Teilaspekt am schnellsten Hilfe.
Zitat von: denis.robel am 28 März 2022, 11:21:44
Gibt es irgendwo ein Tutorial für den Mischbetrieb Lokales Mic an der Base + Sateliten via UDP?
Das hat eigentlich alles mit UDP nichts zu tun. Am besten zu Beginn mal gar nicht von "UDP" verwirren lassen. Da geht es nur darum, dass nicht alles an den MQTT-Server übertragen wird, dass eigentlich gar nicht übertragen werden muss, weil man's auch lokal verarbeiten kann. Also, lassen wir das mal einfach außer Acht.
Grundsätzlich ist dein Setup kein Problem. Aber schauen wir zuerst mal, dass an der Base alles läuft und lassen bis dahin die Satelliten (bzw. App) links liegen. Ok?
Wie ist denn die Base derzeit konfiguriert? Kannst du bitte mal die profile.json der Base posten?
danke für die Rückmeldung.
ich habe hier was vom Jens gelesen ,dass das wahrscheinlich nicht geht:
https://forum.fhem.de/index.php/topic,113180.msg1132773.html#msg1132773
Ich werde erst einmal im Rhasspy Forum schauen und melde mich wieder.
Zitat von: denis.robel am 28 März 2022, 12:36:04
ich habe hier was vom Jens gelesen ,dass das wahrscheinlich nicht geht:
Zwei Beträge vor dem verlinkten (https://community.rhasspy.org/t/udp-wakeword-detection-with-rhasspy-mobile-app/1795/15):
ZitatShould be fixed in 2.5.11 and with other wakeword than raven.
@drhirn:
Ich bin da auch nicht so richtig drin, aber die App (und die ESP32-Lösung) kennen nur UDP als Transportlayer für die Wakeword-Geschichte.
Eigentlich sieht für meine diesbezüglich aber nicht allzu erfahrenen Augen das nach der Lösung für solche Fälle aus, was in https://rhasspy.readthedocs.io/en/latest/audio-input/#pyaudio unter "UDP Audio Streaming" beschrieben ist.
Zitat von: Beta-User am 28 März 2022, 12:43:39
@drhirn:
Ich bin da auch nicht so richtig drin, aber die App (und die ESP32-Lösung) kennen nur UDP als Transportlayer für die Wakeword-Geschichte.
Ja. Wurde mir gerade auch bewusst, als ich die App eben wieder mal getestet habe.
@denis.robel:
Trotzdem hat drhirn dahingehend recht, dass es sinnvoll ist, erst mal "klein anzufangen" und die base an's Laufen zu bekommen. Der Rest kommt dann schon auf die eine oder andere Weise*, wenn mal klar ist, wie das Gesamtsystem tickt. Zu viele Baustellen auf einmal sind nicht gut, die machen das ganze nur unübersichtlich.
Prinzipiell müßte es gehen => später wieder damit intensiver befassen, falls noch erforderlich...
Zitat von: drhirn am 28 März 2022, 13:00:59
Ja. Wurde mir gerade auch bewusst, als ich die App eben wieder mal getestet habe.
Dieser "Mangel" war für mich einer der Gründe,
- die ESP-Lösung erst mal auf die Seite zu legen und
- mir das mit AMAD.* mal anzusehen...
@denis.robel: * => evtl. ist mittelfristig eine AMAD.*-basierte Interaktion vom Handy aus auch für dich die bessere Lösung. Ich habe zwar noch einen offenen Punkt, was das Wiedereinschalten des Mikros im Fall von Rückfragen angeht, aber ansonsten gefällt mir diese Sache fast besser wie der Shortcut auf der Rhasspy-Mobile-App :) . Leider bekommt g.* dann mit, was ich da reinlabere, aber damit alleine fangen die auch noch nicht wirklich viel an...
Ich muss gleich sagen: Ich hab an meiner Base keine Audio-Hardware. Ich kann das also nicht verlässlich testen.
Aber, ich hab das jetzt so weit, dass ich vom Satellit und von der App aus Befehle erteilen kann. Und das Wakeword funktioniert auch auf beiden. Ist in der Tat etwas tricky. Und die App nicht unbedingt sehr stabil. Wird aber offenbar auch schon seit Längerem nicht mehr weiter entwickelt.
Der Trick war das Dialogue Management. Das muss auch an der Base aktiv sein. Aber da darf dann nur die siteId der App konfiguriert sein (bzw. App + Base). Sonst kommen die anderen Satelliten durcheinander. Und die IP in der WakeWord Konfiguration muss die vom Docker Container sein. Der UDP-Port muss natürlich nach außen geöffnet werden.
Hier die Konfiguration der Base:
{
"dialogue": {
"group_separator": ".",
"satellite_site_ids": "mobile-app6",
"system": "rhasspy"
},
"intent": {
"satellite_site_ids": "wohnzimmer,vorraum,küche,schlafzimmer,defhem,mobile-app6",
"system": "fsticuffs"
},
"microphone": {
"pyaudio": {
"udp_audio_port": ""
},
"system": "pyaudio"
},
"sounds": {
"error": "${RHASSPY_PROFILE_DIR}/error.wav",
"recorded": "${RHASSPY_PROFILE_DIR}/end_of_input.wav",
"system": "aplay",
"wake": "${RHASSPY_PROFILE_DIR}/start_of_input.wav"
},
"speech_to_text": {
"kaldi": {
"allow_unknown_words": true,
"cancel_word": "alexa"
},
"satellite_site_ids": "wohnzimmer,vorraum,küche,schlafzimmer,defhem,mobile-app6",
"system": "kaldi"
},
"text_to_speech": {
"satellite_site_ids": "wohnzimmer,vorraum,küche,schlafzimmer,defhem,mobile-app6",
"system": "nanotts"
},
"wake": {
"porcupine": {
"udp_audio": "172.28.0.2:20000:mobile-app6"
},
"satellite_site_ids": "wohnzimmer,vorraum,küche,schlafzimmer,defhem,mobile-app6",
"snowboy": {
"udp_audio": "172.28.0.2:20000:mobile-app6"
},
"system": "snowboy"
}
}
Screenshot hängt auch an.
Müsste also schon funktionieren, wenn da an der Base auch noch Audio-Geräte hängen. Aber wie gesagt, kann's nicht testen, weil ich meine USB-Soundkarte gerade nicht finde ;).
Hallo,
ich hatte klein angefangen, denn vorher hat ja von meiner Base aus das wesentliche funktioniert ....
Wie jetzt wieder.
Die App läuft, aber eben immer noch ohne wake word detection (ein Schritt zurück im Vergleich zu Snips und Snipek auf dem Jolla Riegel).
Ich habe noch eine Frage, was habt Ihr für Satelliten Hardware am Start?
Na dann, zeig und mal die Config deiner Base (Advanced im Menü oben). Mal schauen, ob wir das hin bekommen.
Ich hatte ein paar Raspberry PI 3A+ im Einsatz. Weil, super Preis-/Leistungsverhältnis. Hab mir dann einen Zero2 gekauft und bin begeistert. Werde umrüsten, sobald's wieder welche gibt.
Audio-Hardware hab ich Respeaker 2Mic HATs. Die sind aber nur so "naja".
{
"dialogue": {
"satellite_site_ids": "denismobile",
"system": "rhasspy"
},
"intent": {
"satellite_site_ids": "denismobile",
"system": "fsticuffs"
},
"microphone": {
"pyaudio": {
"device": "1",
"udp_audio_host": "",
"udp_audio_port": ""
},
"system": "pyaudio"
},
"mqtt": {
"enabled": ""
},
"sounds": {
"aplay": {
"volume": "0.6"
},
"system": "aplay"
},
"speech_to_text": {
"kaldi": {
"cancel_word": "abbrechen"
},
"satellite_site_ids": "denismobile",
"system": "kaldi"
},
"text_to_speech": {
"nanotts": {
"volume": "0.7"
},
"satellite_site_ids": "denismobile",
"system": "nanotts"
},
"wake": {
"porcupine": {
"keyword_path": "computer_raspberry-pi.ppn",
"sensitivity": "0.7",
"udp_audio": "172.17.0.2:20000:denismobile"
},
"satellite_site_ids": "denismobile",
und meine docker-compose.yml
rhasspy:
image: "rhasspy/rhasspy"
container_name: rhasspy
restart: unless-stopped
volumes:
- "$HOME/.config/rhasspy/profiles:/profiles"
- "/etc/localtime:/etc/localtime:ro"
ports:
- "12101:12101"
- "12183:12183"
- "20000:20000"
- "20001:20001"
- "20002:20002"
- "20003:20003"
devices:
- "/dev/snd:/dev/snd"
command: --user-profiles /profiles --profile de
@denis.robel
Die Settings funktionieren. Ob's korrekt ist, weiß ich nicht, da die Doku dazu keine Angaben macht.
Gruß Jens
Jetzt warst schneller, ich war noch am Test :)
Wollte aber vorschlagen, die siteId der Base bei dialogue noch einzutragen. Hätte auch reichen können.
Freut mich, dass es funktioniert!
Naja, mit der Erkennung hapert es, seit der letzten Rhasspy-Version aber es wird ja hoffentlich in der V2.6 ein neues WakeWord-System rauskommen.
Zitat von: JensS am 31 März 2022, 18:42:53
Naja, mit der Erkennung hapert es, seit der letzten Rhasspy-Version aber es wird ja hoffentlich in der V2.6 ein neues WakeWord-System rauskommen.
Echt? Bei mir geht das super mit der App. Besser als mit den Satelliten ;)
Zitat von: JensS am 31 März 2022, 18:37:16
@denis.robel
Die Settings funktionieren. Ob's korrekt ist, weiß ich nicht, da die Doku dazu keine Angaben macht.
Geht bei mir auch, wenn ich die IP weg lasse und das so eintrage:
:20000:mobile-app6Und in der docker-compose muss man eigentlich nur UDP freigeben:
ports:
[...]
- "20000:20000/udp"
ZitatEcht? Bei mir geht das super mit der App. Besser als mit den Satelliten
Doofe Frage: Wakeword mit der App???
LG
pah
Ja. App hört dann halt dauernd zu und der Netzwerkverkehr dürfte ordentlich ansteigen. Wie der Akku ordentlich leer wird.
Bin mal gespannt, ob bzw. wann da jemand erfolgreich daran arbeitet, die wakeword-engine direkt auf dem Andoiden unterzubringen, also (sound-technisch) offline.
Es gab dazu schon vor Jahren eine (von der Rhasspy-Mobile-App verschiedene) Demo-App, die aber auch ziemlich Akku gebraucht hat und wirklich nur "habe das (eine vorinstallierte) wakeword erkannt" gemeldet hat, also nix via MQTT verschickt oder so. Auf der Suche nach dem Link dahin bin ich bei "Picovoice" gelandet (https://github.com/Picovoice/cobra#android-demos). Sieht (unabhängig von der konkreten Lösung, die z.B. auch für ESP32 zu kompilieren zu sein scheint) allgemein so aus, als gäbe es da noch mehr Leute, die Bedarf sehen für so ein feature...
Also falls jemand in der Lage ist, da ein "add-on" draus zu basteln: feel free :) .
Hallo Jörg,
ich hab Google Assistant als Sprachsteuerung rausgeschmissen, da ich es nur noch unregelmäßig benutzt habe, und weil es unzuverlässig war. Die Antwort "Ich habe ... in deiner Nähe gefunden" nervte nur noch.
Bei der Entfernung von Google Assistant habe ich bei den Rollladen-Devices die Google Assistant-typischen Attribute gelöscht, bzw. in dem EventMap nur das für den Assistant notwendige.
Ich habe überprüft, ob die Spracheingabe mit der Android-App noch funktioniert, und das tat sie.
Heute Morgen liefert die App aber nur Fehler. Ich konnte den Fehler immerhin etwas eingrenzen. Wenn ich statt zu sprechen, den Befehl eintippe, führt Fhem den Befehl aus.
Hier der log aus der Android-App bei gesprochenem Befehl:
[D] TIME: 2022-04-19T08:17:09.211061 Starting mqtt... TAG: MQTT
[D] TIME: 2022-04-19T08:17:09.212931 Connecting to mqtt... TAG: MQTT
[D] TIME: 2022-04-19T08:17:09.318113 connected TAG: MQTT
[I] TIME: 2022-04-19T08:17:09.319061 Mosquitto client connected TAG: MQTT
[I] TIME: 2022-04-19T08:17:11.156649 Start recording TAG: APP
[D] TIME: 2022-04-19T08:17:11.157421 Send port: SendPort TAG: MQTT
[D] TIME: 2022-04-19T08:17:11.520859 generate new data session TAG: MQTT
[D] TIME: 2022-04-19T08:17:22.125939 received topic: hermes/asr/textCaptured TAG: MQTT
[D] TIME: 2022-04-19T08:17:22.251235 received topic: hermes/nlu/intentNotRecognized TAG: MQTT
[W] TIME: 2022-04-19T08:17:22.252745 IntentNotRecognized TAG: DIALOGUE
[D] TIME: 2022-04-19T08:17:22.253148 StopRecording request TAG: DIALOGUE
[I] TIME: 2022-04-19T08:17:22.253278 Stop recording TAG: APP
[D] TIME: 2022-04-19T08:17:24.285510 keepAlive TAG: MQTT
An der Android-App habe ich absolut gar nichts geändert. In Fhem hab ich die Rhasspy-Definitionen in eine eigene cfg geschoben und per include in fhem.cfg eingebunden, dannach einen Fhem-Neustart.
Hast du eine Idee, was da los sein könnte?
Viele Grüße
Gisbert
Hallo Jörg,
das Problem war ärgerlich wie einfach zu lösen. Heute abend hab ich gemerkt, dass das Mikrofon meines Handys nicht funktioniert. Nach einem Neustart des Handys war wieder alles gut.
Viele Grüße Gisbert
Zitat von: Gisbert am 19 April 2022, 21:56:02
das Problem war ärgerlich wie einfach zu lösen.
:) Schön, dass du die Ursache gefunden hast.
Deine implizite Rückmeldung zu RHASSPY vs. Google Assistant fand ich übrigens sehr motivierend 8) !
Hatte schon gezweifelt, ob alles ok ist oder ob du irgendein aktuelles und frustrierendes Problem hast, das dich so nervt, dass du RHASSPY den Rücken gekehrt hast oder vor der Fülle an Möglichkeiten kapituliert ::) .
Hallo Jörg,
ich verfolge interessiert deine weiteren Entwicklungen, ohne jedoch Details nachvollziehen zu können.
Ich hab mir gedacht, dass eine Kommunikation ganz schön wäre. Deshalb hab ich aus dem Wiki die folgenden Zeilen in sentences.ini ergänzt (zur Vollständigkeit die gesamte Datei):
[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|an der) $de.fhem.Room{Room}] ((an|ein|hoch|auf){Value:on}|(aus|zu|runter){Value:off})
[de.fhem:ChoiceRoom]
nimm [das Gerät] ( aus ( dem | der ) | im | den | die ) $de.fhem.MainRooms{Room}
[de.fhem:ChoiceDevice]
ich hätte gerne [das Gerät] $de.fhem.Aliases{Device}
[de.fhem:CancelAction]
(lass es | nein | abbrechen | abbruch ){Mode:Cancel}
[de.fhem:ConfirmAction]
( ja mach | tu es | ist ok | aber gerne doch ){Mode:OK}In Fhem habe ich ausgeführt:
set <mydevice> update allEs gibt jetzt 2 Fhem-Geräte mit dem rhasspyName-Attribut "licht", eines davon mit dem rhasspyRoom-Attribut "wohnzimmer", das andere "haustür".
Wenn ich in der Android-App sage: "schalte das licht an", kommt keine Rückfrage, es wird das Licht im "wohnzimmer" angeschaltet.
Bei der "haustür" ist die Funktionalität gegeben, denn der Befehl "schalte das licht an der haustür an" wird ausgeführt.
Anders verhält es sich bei folgendem Befehl: "halte den Rollladen an" - hier bekomme ich die Anwort von der App: "Tut mir leid, ich konnte kein passendes Gerät finden".
Wenn ich dann anschließend sage (Mikrofon erneut angeschaltet): "nimm das Gerät im Schlafzimmer von ..." bekomme ich die Anwort: "Warte gerade nicht auf eine Auswahl".
Im Wiki steht:
ZitatEigene Dialoge
Über Custom Intents in Verbindung mit passenden Rückgabewerten aus myUtils-Perl-Code lassen sich Sitzungen offen halten und so eigene Dialoge gestalten. (siehe Intents in eigenen Dateien)
Der Link am Schluss funktioniert nicht.
Ich hab auch von AMAD gelesen, das ich auch in Fhem nutze. Was hat es damit auf sich, oder mit anderen Worten, wie kann ich das in Zusammenhang mit Rhasspy nutzen.
Viele Grüße
Gisbert
Zitat von: Gisbert am 08 Mai 2022, 15:10:39
Wenn ich in der Android-App sage: "schalte das licht an", kommt keine Rückfrage, es wird das Licht im "wohnzimmer" angeschaltet.
Bei der "haustür" ist die Funktionalität gegeben, denn der Befehl "schalte das licht an der haustür an" wird ausgeführt.
Wenn direkt etwas geschaltet wird, ist aus RHASSPY-Sicht eine Eindeutigkeit gebeben. Das sollte eine der folgenden beiden Ursachen haben:
- Entweder du hast "Prioritäten" gesetzt (vermutlich noch nicht), oder
- dein Satellit befindet sich im "wohnzimmer" (siteId2room-Reading)?
Wenn es letzteres ist: Entweder das Reading mal löschen, oder es in den Raum "haustür" verlegen, oder in einen anderen Raum, in dem es _kein_ Device "licht" gibt...
Zitat
Anders verhält es sich bei folgendem Befehl: "halte den Rollladen an" - hier bekomme ich die Anwort von der App: "Tut mir leid, ich konnte kein passendes Gerät finden".
Kennt denn dein Rollladen einen "stop"-Befehl? Wenn ja: wie sieht der betreffende Abschnitt in deinem RHASSPY-devicelist-list aus?
Zitat
Wenn ich dann anschließend sage (Mikrofon erneut angeschaltet): "nimm das Gerät im Schlafzimmer von ..." bekomme ich die Anwort: "Warte gerade nicht auf eine Auswahl".
Wenn die Sache aus RHASSPY-Sicht "fertig" ist, werden die Sitzungsdaten gelöscht, das Einschalten des Mikrofons durch dich als User startet eine neue Sitzung. Einfach so in einen Auswahldialog reinzugehen ist jedenfalls derzeit nicht möglich/vorgesehen.
Zitat
Im Wiki steht:Der Link am Schluss funktioniert nicht.
Danke, ist repariert!
Zitat
Ich hab auch von AMAD gelesen, das ich auch in Fhem nutze. Was hat es damit auf sich, oder mit anderen Worten, wie kann ich das in Zusammenhang mit Rhasspy nutzen.
Im Prinzip kann AMAD.* die "mobile app" ersetzen (abgesehen von der wakeword-Funktionalität). Ich habe z.B. einen (leider nicht mit einem Icon versehenen) shortcut auf dem Handy, mit dem der "activateVoiceInput"-flow gestartet wird.
Damit das funktioniert, muss eigentlich nur das AMADDevice als "allowed" in dem RHASSPY-Attribut eingetragen sein. Bitte aber darauf achten, dass sich das nicht mit irgendwas anderem "beißt", das du ggf. bisher im Einsatz hast.
Es wäre ggf. sinnvoll, für den AMAD.*-Teil einen separaten Thread zu starten, das ist evtl. noch für andere User interessant (und bisher komplett undurchsichtig)...
Zitatund bisher komplett undurchsichtig
Na ja, sagen wir: nicht gut dokumentiert. Wird sich möglicherweise ändern, eines meiner nächsten Buchprojekte wird sich speziell mit Sprachsteuerung im SmartHome befassen.
Der Knackpunkt hierbei ist, dass die Spracherkennung auf den Android-Devices (mit Google...) einfach um Klassen besser ist als alles, was mit Open Source derzeit hinzubekommen ist. Mein Workflow ist also
Wakeword (in Rhasspy) -> MQTT Message aus Rhasspy an einen MQTT2_CLIENT -> Einschalten VoiceInput auf AMAD-Device -> Analyse des von Google erhaltenen Textes (Intent-Erkennung, bzw. Chatbot hinten dran) durch Babble -> Schaltbefehl an FHEM (ohne oder mit Sprachausgabe als Bestätigung, oder Abfrage von Daten aus FHEM (und Umwandlung in verständliche Sprache) oder nur Sprachantwort (z.B. vom Chatbot -> Triggern der Sprachausgabe (entweder auf AMAD-Devices, oder holen von Sprach-MP3-Dateien von Amazon Polly zur Ausgabe auf Linux-Geräten oder BOSE SoundTouch.
Zur Sprachausgabe nutze ich in der Regel Amazon Polly. Und zwar auch auf den AMAD-Devices mit derselben Stimme. Das geht deshalb, weil der Sprachsynthesedienst Ivona vor einigen Jahren von Amazon aufgekauft worden ist, und eine ziemlich alte App von Ivona immer noch gut funktioniert. Und auf Linux bzw. BOSE-Geräten wird halt der Text an Amazon Polly gesendet und für Null Euro als MP3 zurückgesendet. Da dabei vor-erzeugte MP3-Dateien mit aktualisierten Daten zusammengefügt werden, ist das auch cloud-sicher (nicht cloud-frei...) Der chinesische Geheimdienst kann von mir aus gerne erfahren, welche Temperatur in meinem Schlafzimmer herrscht.
Eine klare Erkenntnis aus meinen Forschungsprojekten kann ich nicht oft genug zitieren: Jedes Sprachsteuerungssystem benötigt eine "dialog closure" am Ende, die auf noch so absurde Fragen und Antworten der Nutzer reagiert und immer irgendetwas zurückliefert, das eben nicht eine mehr oder weniger höfliche Form von "Das habe ich nicht verstanden" ist.
Das alles kann man mit oder ohne das Modul RHASSPY machen.
LG
pah
Hallo Jörg,
Amad spare ich mir dann für später auf.
Ich habe das Reading siteId2room-Reading gelöscht, es hatte den Wert "wohnzimmer"; das erklärt dann wohl, dass ohne Angabe eines Raumes der Raum "wohnzimmer" genommen wurde.
Jetzt bekomme ich auf den Befehl "schalte das licht an" die Antwort "Tut mir leid, ich konnte kein passendes Gerät finden". Das kann eigentlich nicht sein, denn es gibt 2 Geräte, die einen rhasspyName "licht" haben. Eigentlich gute Voraussetzungen für eine Nachfrage seitens Rhasspy.
Das Attribut enableMsgDialog hat den Wert 0. Kann es daran liegen? Wie kann ich den Wert ändern (außer mit setreading)?
Viele Grüße Gisbert
Zitat von: Gisbert am 08 Mai 2022, 20:39:31
Jetzt bekomme ich auf den Befehl "schalte das licht an" die Antwort "Tut mir leid, ich konnte kein passendes Gerät finden". Das kann eigentlich nicht sein, denn es gibt 2 Geräte, die das einen rhasspyName "licht" haben. Eigentlich gute Voraussetzungen für eine Nachfrage seitens Rhasspy.
Das Attribut enableMsgDialog hat den Wert 0. Kann es daran liegen? Wie kann ich den Wert ändern (außer mit setreading)?
Das sieht mir nach einem Bug aus, muss ich mir ansehen.
Alles, was "msg" in der Benennung hat, hat mit wieder einer anderen Schnittstelle zu tun, das dürfte nicht mit der fehlenden Rückfrage zusammenhängen.
Die commandref enthält ein paar Infos, wie die Werte in dem Attribut ggf. aussehen sollten (ist aber wie AMAD ein separtes Thema!).
Zitat von: Prof. Dr. Peter Henning am 08 Mai 2022, 17:10:21
Na ja, sagen wir: nicht gut dokumentiert. Wird sich möglicherweise ändern, eines meiner nächsten Buchprojekte wird sich speziell mit Sprachsteuerung im SmartHome befassen.
Na ja, es gab bisher auch wenig Interessenten, um wesentlich mehr zu machen (und ggf. fertig zu entwickeln...) wie das, was jetzt in der Attribut-commandref zu finden ist...
Zitat
Eine klare Erkenntnis aus meinen Forschungsprojekten kann ich nicht oft genug zitieren: Jedes Sprachsteuerungssystem benötigt eine "dialog closure" am Ende, die auf noch so absurde Fragen und Antworten der Nutzer reagiert und immer irgendetwas zurückliefert, das eben nicht eine mehr oder weniger höfliche Form von "Das habe ich nicht verstanden" ist.
Danke für den nochmaligen Hinweis.
Das mit "intent not recognized" ist in der Tat so ein offener Faden, bei dem wir insgesamt noch nicht zu einem befriedigenden "was wollen wir damit machen" gekommen sind (in den anderen Fällen sollte eigentlich immer irgendwas zurückkommen, oder übersehe ich grade was?).
Zitat
Das alles kann man mit oder ohne das Modul RHASSPY machen.
Klar. Im Prinzip kann man RHASSPY auch als "dummes Zwischen-Interface" zu Rhasspy nutzen, ohne devicemap etc. zu füllen. Tendenziell meint mein Bauchgefühl zwar, dass es weiter sinnvoll ist, alle Admin- und notify-Routinen im Modul abzubilden, aber das kann täuschen...
Zitat von: Beta-User am 08 Mai 2022, 21:28:47
Das mit "intent not recognized" ist in der Tat so ein offener Faden, bei dem wir insgesamt noch nicht zu einem befriedigenden "was wollen wir damit machen" gekommen sind (in den anderen Fällen sollte eigentlich immer irgendwas zurückkommen, oder übersehe ich grade was?).
Da RHASSPY die sentences.ini auswertet, ist der "Open transcription mode" nicht wirklich zu gebrauchen. Die Sprachdaten zu einem Onlinedienst zu schicken, bringt nur teilweise etwas. Google und Co keinnen beispielsweise nicht die verwendeten RhasspyNamen, Gruppen, Räume,...
Interessant wäre die Auswertung von "intent not recognized" und anschließende Analyse durch eine KI (rasa o.a.). Dadurch könnten Absichten erlernt werden, welche dann von RHASSPY gezielt als Rückfrage gestellt werden.
ZitatKlar. Im Prinzip kann man RHASSPY auch als "dummes Zwischen-Interface" zu Rhasspy nutzen, ohne devicemap etc. zu füllen. Tendenziell meint mein Bauchgefühl zwar, dass es weiter sinnvoll ist, alle Admin- und notify-Routinen im Modul abzubilden, aber das kann täuschen...
Genau dahin ging der Ansatz des modularen Aufbaus von RHASSPY, ähnlich wie bei SIGNALduino und den Modulen SD_WS. etc..
Man könnte je nach Bedarf oder Kenntnis, RHASSPY mit den gewünschten Module zusammenstellen.
Gruß Jens
ZitatInteressant wäre die Auswertung von "intent not recognized" und anschließende Analyse durch eine KI (rasa o.a.). Dadurch könnten Absichten erlernt werden, welche dann von RHASSPY gezielt als Rückfrage gestellt werden.
Pardon, aber da muss ich klar widersprechen. Eine KI kann keinerlei Absichten aus nicht erkannten Sätzen lernen, und bei Rasa geht das schon gar nicht.
Babble schreibt übrigens alle nicht erkannten Sätze in eine Datei. In meinem RiveScript-Chatbot gibt es einen rudimentären Lernmodus, mit dem ich dem System neue Räume und Geräte hinzufügen kann.
LG
pah
Zitat von: Prof. Dr. Peter Henning am 09 Mai 2022, 05:44:25
Pardon, aber da muss ich klar widersprechen. Eine KI kann keinerlei Absichten aus nicht erkannten Sätzen lernen, und bei Rasa geht das schon gar nicht.
Schade, ich ging davon aus, dass Rasa auf Tensorflow basiert und RHASSPY die möglichen Sätze in der sentences.ini als Datenmenge zur Erkennung bereitstellt. Man könnte den Satz sich mit der höchsten Wahrscheinlichkeit durch eine Rückfrage mittels RHASSPY bestätigen/verneinen lassen und so (bei mehrmaliger Bestätigung) einen weiteren Datensatz in Tensorflow hinzufügen. Aber wenn das nicht geht, geht's halt nicht.
Gruß Jens
Zitat von: Beta-User am 08 Mai 2022, 21:28:47
Das sieht mir nach einem Bug aus, muss ich mir ansehen.
Kein bug, sondern schlicht bisher nicht als "Mache einen Request"-Pfad ausgelegt/vorgesehen. Finde ich aber an sich eine sinnvolle Ergänzung, muss aber erst mal selbst darauf rumtesten => wird (vermutlich kurz) dauern...
Zitat
Das mit "intent not recognized" ist in der Tat so ein [...]
... schwieriges Thema...
Mal abgesehen von allem anderen, ist es "im Prinzip" auch noch ziemlich anonym :( . Wie man aus https://rhasspy.readthedocs.io/en/latest/reference/#nlu_intentnotrecognized ablesen kann, ist da zwar die siteId mitgeliefert, aber damit ist noch lange nicht gesagt, dass FHEM/RHASSPY das in irgendeiner Form interessieren _müßte_. Zwar wird es in einer "Einheits-Normal-Installation" so sein, dass eine RHASSPY-Instanz da ist und nur ein FHEM (und auch keine andere Automatisierung iVm. Rhasspy), aber trotzdem habe ich sehr große Skrupel, einfach alles "unerkannte" durch RHASSPY einfach wieder "zuhauen" zu lassen. Das ergäbe im schlimmsten Fall unerwünscht geschlossene sessions mit mehrsprachigen "kannitverstahn"-Audio-Rückmeldungen...
Wenn, muss m.E. der "Administrator" sowas aktiv anschalten müssen.
Oder übersehe ich was?!?
Ansonsten:
Selbst wenn man wüßte, für welche siteId's eine RHASSPY-Instanz (ggf. iVm. bestimmten wakewords) dann "zuständig" sein soll, wäre es auch mit einem im Hintergrund gut funktionierenden KI-Tool schwierig zu entscheiden, an welcher Stelle denn eine Anpassung in der FHEM-Konfiguration vorzunehmen wäre. Dazu eine passende Logik zu entwerfen erscheint mir in keiner Relation zum Nutzen zu stehen.
Was das loggen von intentNotRecognized angeht:
An sich scheint mir das eine sehr gute Idee zu sein, von daher würde ich dazu neigen eine Option vorzusehen, $data in ein ein triggerndes Reading umleiten zu können. Dann kann man es mit den üblichen Bordmitteln (FileLog) mitschneiden. Ergänzend wäre dann aber die Frage, ob man nicht auch "erkannte", aber mangels min-confidence-Level verworfene Messages dann (bei ausreichendem/einstellbarem "Abstand" zum "ok"-Level auch gleich da reinschiebt...
Meinungen zum Ganzen?
Beim intentNotRecognized wird ja etwas erkannt und ausgegeben. Von der NLU wird nur kein passender Intent gefunden.
"wie spät ist es jetzt" wird nicht erkannt, weil "jetzt" zuviel ist. Wird der Text mit den vorhandenen Intents verglichen, kann der enthaltene Intent "wie spät ist es" gefiltert werden und der Intent könnte nach einer Rückfrage über sessionContinue: "Meinst du - wie spät ist es?" per hermes/nlu/query (mit den aktuellen Session-Daten) an die Session zurückgegeben werden.
Wenn der Sprecher immer wieder "jetzt" dranhängt, könnte man "wie spät ist es jetzt" als Alias zu "wie spät ist es" abspeichern und künftig sofort zurückgeben.
Die Mehrsprachigkeit ist durch den Startparameter von Rhasspy gegeben.
Klar ist das hoch gegriffen. Du hattest "intentNotRecognized" zur Sprache gebracht - hier ist eine Idee dazu. ;)
Gruß Jens
Zitat von: Gisbert am 08 Mai 2022, 20:39:31
"Tut mir leid, ich konnte kein passendes Gerät finden".
Update ist im "offene Themen (https://forum.fhem.de/index.php/topic,124952.msg1195323.html#msg1195323)"-Thread zu finden.
Falls Fragen zum Code an sich vorhanden sein sollten, bitte im allg. "Entwicklungs"-Thread posten, mit der Frage, wie denn sinnvollerweise die "Choice"-sentences zu bilden wären, können wir uns gerne hier kurz befassen (ich habe dazu noch keine "postbare" Idee).
Zitatwie spät ist es jetzt
ist ein typisches Beispiel für einen Satz, der ohne Kontext nicht interpretierbar ist. Das kann man mit Amazon Alexa gut ausprobieren
"Alexa, wie spät ist es jetzt" ==> aktuelle Uhrzeit
"Alexa, wie früh ist es" ==> aktuelle Uhrzeit
"Alexa, wie spät ist es morgen" ==> Datum von morgen
"Alexa, wie früh ist es morgen" ==> "Das könnte Deine Frage beantworten..." dann Datum von morgen
"Alexa, wie früh ist es vorgestern" ==> "Das weiß ich leider nicht"
"Alexa, wie spät ist es jetzt in Timbuktu" ==> Datum und Uhrzeit in Timbuktu
Hier wird also offenbar zunächst fest substituiert "wie spät" ==> Ausgabe Zeit/Datum.
Dann aber ist ein Zeitpunkt und ein Ort festzustellen, und dafür gibt es default-Annahmen.
LG
pah
Zitat von: Beta-User am 10 Mai 2022, 09:52:52
(ich habe dazu noch keine "postbare" Idee).
da grade im Development-Thread die Frage auf Auswahl kam, hier nochmal der betreffende Auszug aus dem 0.5 - Offene Punkte-Thread:
Zitat von: Beta-User am 20 Mai 2022, 12:21:16
2. Choice
Sinnvollerweise sollte man den generischen "Choice"-Intent benutzen statt der alten gesplitteten:
[de.fhem:Choice]
den=<de.fhem:SetOnOff.den>
choose= ( nimm [bitte] | [bitte] nimm | ich hätte gerne | [ich] (wähle|nehme) )
<choose> [ <den> [( Gerät | $de.fhem.Aliases{Device} )] ] ( aus ( dem | der ) | im | den | die ) $de.fhem.MainRooms{Room}
<choose> [ <den> ] $de.fhem.Aliases{Device} [ ( aus ( dem | der ) | im | den | die ) $de.fhem.MainRooms{Room} ]
<choose> [ ( die Szene | den Modus ) ] $de.fhem.Scenes [Modus] [ [( am | vom )] $de.fhem.Aliases{Device} ] [( aus ( dem | der ) | im | den | die ) $de.fhem.MainRooms{Room} ] [bitte]
Dadurch hat man als Sprechender die Möglichkeit, ggf. z.B. wegen des Raums dann noch korrigierend einzugreifen, wenn eine Zuordnung nicht so richtig passen sollte oder man sich versprochen hat...
Der Vollständigkeit halber - <de.fhem:SetOnOff.den> ist
den=(den|die|das)