Rhasspy 2.5 Pre-Release

Announcements
83

You can setup a UDP port for both the wakeword and speech to text services what perhaps does what you refer to:

By default, Rhasspy will stream microphone audio over MQTT in WAV chunks. When using Rhasspy in a master/satellite setup, it may be desirable to only send audio to the MQTT broker after the satellite as woken up. For this case, set both microphone.<MICROPHONE_SYSTEM>.udp_audio_port and wake.snowboy.udp_audio_port to the same free port number on your satellite. This will cause the microphone service to stream over UDP until an asr/startListening message is received. It will go back to UDP stream when an asr/stopListening .

Hope this helps.

2 Likes
84

Thanks @geoffrey! That worked perfectly with porcupine.

I’d still argue that constant streaming should not be the default behavior, otherwise a lot of people (likely w/o TLS or username/passwords on their broker) would be pretty easy to eavesdrop on with a user-level process on their network. What’s the right venue for that discussion-- here or an issue?

85

@synesthesiam is active in both channels, but I’d suggest to create a separate topic for this in this community.

86

Hello @synesthesiam,

I’ve aready created a pull request for the issue above, but afterwards I realized that it might be better to ask if you are interested in a little bit of beautifying the UI. I’ve tinkered a little with the forms and what I can offer you is more or less a improvement of the existing which looks a little bit “bootstrappy” like this:

image
image1473×603 17.1 KB

1 Like
87

image
image773×118 6.59 KB

:wink: hint hint

2 Likes
88

13 posts were split to a new topic: Rhasspy 2.5: Wake word and audio feedback issue

91

Ignorant question alert… :blush:
How should I go about getting the most recent version(s) of 2.5 Docker?
(I’d want the one for Intel NUC, but I may also give Rhasspy 2.5 a try on a Raspberry 3b+)

92

docker pull rhasspy/rhasspy:2.5.0-pre :slight_smile:

99

4 posts were split to a new topic: Training issue with Rhasspy 2.5 : Missing online.conf

107

A post was merged into an existing topic: Training issue with Rhasspy 2.5 : Missing online.conf

108

Just a heads up: the next Docker image will fix the NLU messages to align correctly again with Snips.

  • raw_value in slots will now be rawValue
  • Same thing for raw_start and raw_end
  • value will be a JSON object with kind and value properties

Rhasspy traditionally hasn’t differentiated between Snips’ entity and slotName fields. In the Rhasspy sentence (some text){tag}, I’d normally set both fields to tag and the value to some text. I’m trying something slightly different with slots now, and looking for feedback.

If you have the sentence ($mySlot){myTag} now, I’m setting the Snips entity to “mySlot” and the slotName to “myTag”. This works really well with numbers, because those are generated with a slot program. So (1..10){myNum} will have rhasspy/number as the entity and myNum as the slotName. Additionally, kind is automatically set to “Number”.

Unfortunately, Rhasspy’s intent JSON format has only ever had entity, so I’d be breaking backward compatibility there. My first attempt has been to leave entity alone, and add two new fields to each entity: source and kind. In the above example, the entity, source, and kind fields will contain “myNumber”, “rhasspy/number”, and “Number” respectively. I don’t like that Snips’ entity and Rhasspy’s entity fields have different values, but that may just be the price to pay.

Thoughts?

2 Likes
109

I think that entities should be placed in slots so I liked the way Snips did it.

The user defines entities (cities for instance that are not related to any specific intent or context) and place them in different slots with custom names depending on Intent context (from, to) that give meaning to the entities.

I think « entities in slots » is clearer than « sources in entities » (which is kind of confusing).

Regarding breaking changes, I think it might be acceptable for 2.5 if it improves clarity in the long term. it might be now or never :wink:

Maybe Discourse have a survey plugin to ask the whole community what they prefer?

110

A post was merged into an existing topic: Rhasspy 2.5: Wake word and audio feedback issue

111

3 posts were split to a new topic: Training issue with 2.5: string index out of range

112

Hello, congratulation from rhasspy 2.5!
I pulled latest docker rhasspy-2.5 image.
Actually home-assistant intent handling doens’t work anymore.

Configuration:

   "home_assistant": {
        "access_token": "...",
        "handle_type": "intent",
        "url": "http://192.168.0.100:8123"
    }

My sentences:

[LightOn]
accendi ($light){light}

My light slot:

(luce salone):luce_salone

On example “LightOn” intent triggering I have this error home-assistant side:

File “/usr/src/homeassistant/homeassistant/helpers/intent.py”, line 74, in async_handle
raise InvalidSlotInfo(f"Received invalid slot info for {intent_type}") from err
homeassistant.helpers.intent.InvalidSlotInfo: Received invalid slot info for LightOn

113

I think the value should just contain the value. Not the kind and the value. I think it was the same with snips earlier. Hence, it used to work directly with HA conversation intent components. Now I have to define separate intents just for Rhasspy. see the issue I raised in the git

114

OK so actually we need to do {{ slot.value }} on home-assistant intent configuration?

115

correct. Thatswhy I am kind of not in favor of this change as all my intents are defined in HA and I was reusing them until now. With this, I have to do a workaround to define similar intent with slot.value and call the same intent again. Kind of defeats the purpose.

116

I should be able to fix this for HA without disrupting other Snips-compatible services.

1 Like
117

thanks @synesthesiam will be looking forward for it.

It’s a wonderful project and a god send for the snips veterans :slight_smile:

1 Like