Rhasspy 2.5 Pre-Release

[jrb5665]

Mine is also a satellite and always set to external

[synesthesiam]

Just a heads up: lots of bug fixes will be coming soon, hopefully by the end of today. The move to Python 3.7 and a newer version of the quart web framework broke quite a bit more than I expected. But it has made the code ultimately simpler and easier to maintain!

I’m adding more and more unit tests, so bugs should stay squashed for good

As one example, the websocket API was completely broken outside of a web browser because the quart guy decided that the HTTP Origin header was now a requirement, despite being explicitly optional in the spec. Node-RED doesn’t set this header, so I have to monkey patch quart to fix the problem

[geoffrey]

Something else I noticed in NodeRed when connecting to the external MQTT broker is that the messages are not recognized as JSON objects but rather plain text.

I have to set the Output property of the mqtt in node to a parsed JSON object instead of the default auto-detect (string or buffer).

Your previous post made me think of it I came across this when having issues with the websockets connection and tried changing to MQTT.

Thank you for the continued effort and heads up!

[thomas_cologne]

Not a bug, but maybe a proposal for one of the next versions:

Sometimes it´s hard to hit the correct position in the upper bar. Maybe it is possible to enlarge the link not just to the red marked zone, but extense it to the blue marked?
Does it makes sence?
As I said, just a smaller remark.

[synesthesiam]

I agree. I’m always hoping someone will really want to take the web stuff off my hands…

[NathanC]

Hey! I just joined the forum-- I set up rhasspy ~ 2 weeks ago (used to use Snips).

This project is super cool, and I just tried the pre-release and it works like a charm (although I need to use the rhasspy dialog manager, hermes has some issues). Excited to leverage the new expanded hermes spec-compliance in my python intent handler.

One thing I noticed is that audio frames are getting streamed over MQTT even w/o the wake word being detected. What do you think about some (potentially default) setting to only stream the frames after the wakeword is detected? Otherwise mic data is going to be going over the queue 24/7 which seems privacy impacting.

I’m going to look into contributing to this project later! Also, my background is in Comp Sci but my current focus is AppSec-- feel free to ping me if you ever want to bounce around security questions or do any threat modeling.

side note: the new web UI for the pre-release is a lot smoother, especially the settings section! great job

[geoffrey]

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 .

Wake Word

Hope this helps.

[NathanC]

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?

[geoffrey]

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

[orca8119]

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:

[kahless]

hint hint

[Andrew49]

Ignorant question alert…
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+)

[synesthesiam]

docker pull rhasspy/rhasspy:2.5.0-pre

[synesthesiam]

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?

[fastjack]

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

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