Unable to listen via secure websocket between Node Red and Rhasspy

Help
1

Hello,

I’m new to this forum and just started to use Rhasspy and Node Red. I’m running rhasspy secured (v2.5.9) on a Pi4 in a docker container using docker-compose and want to use node red to handle the messages coming from Rhasspy.
I tried several node-red setup’s (secured/unsecured, same Pi/other Pi, docker/straight via sudo apt install) to connect to the Rhasspy but without success. (websocket in: wss://hostname:12101/api/events/intent)

If I run Rhasspy unsecured (remove --certfile ‘certfile’ --keyfile ‘keyfile’ from docker-compose.yml) everything works fine. Node red connects to the websocket without a problem in each node red setup I try. (websocket in: ws://hostname:12101/api/events/intent).

Weird thing is that when I use the Websocket extention in Chrome I can connect to wss://hostname:12101/api/events/intent

And when I use node red I can establish a secure websocket connection to wss://echo.websocket.org

So Node Red is able to establish a secure websocket connection, but not to Rhasspy.
Secure websocket Rhasspy works because I can see the messages when I use the Chrome Websocket testing extention.

Can anyone explain what I’m missing?
If code is needed just let me know.
Thank you

2

New here as well, in fact, been using rhasspy for two days. Well, rather experimenting with it.

I’m using node red as well and there seems to be a bug in node red, in regards to websocket connections. If you create the flow in node for the first time (choose “connect to” as the method) and rhasspy is running, it works. But once you restart rhasspy after creating the node red node, it sill shows connected, but apparently it isn’t anymore.

You can confirm this by leaving rhasspy running and restarting node red. Then it should work and you can check this by attaching a debug node to the websocket one. Restart rhasspy again and no more messages are coming to node red.

It seems to be a timeout issue for what I’ve gathered so far. I shut down the pi over night and brought it back up again a couple of minutes ago and the websocket node was working again.

There is another post here on the forum talking about losing the websocket connection, where the solution was to use mqtt (which is a pain in itself, since you have to decode the message and the posted flows are not working for me either)

There is also an issue from 2015 on the node red github page where this behaviour was reported and fixed. So either we time traveled or something else is going on.

EDIT. I just reread your post and it seems I misunderstood you. Is the websocket connection also working after you restart rhasspy? And can you try again with the wss connection and restart node red after deploying? Maybe we are facing the same issue after all.

3

Hillbicks,

Thanks for the reply. I tried what you suggested but unfortunately without a positive result. I think we are facing a different problem, because when I use an unsecured websocket between node-red and an unsecured rhasspy everything works perfect. Only when I use secured rhasspy (https) then I can’t connect to it with a wss websocket from node-red.
But I can connect to a secured rhasspy with a chrome extention for testing websockets using wss. Also Node red is able to connect to other secure websockets.
Only the combination node red vs. secured rhasspy won’t work.

1 Like
4

Hello,
in the beginning I worked with webSockets and it seems to be good, cause it was easy to start with. I tried mqtt and it was hard to understand and to create orders in nodered functions. But:
I IS BETTER
Here I give you the nodered flow to get the slots:
screenshot

[{"id":"50d7c1b4.c9a7c","type":"mqtt in","z":"27a1dcd5.ab7ad4","name":"FromRhasspy","topic":"hermes/intent/#","qos":"2","datatype":"json","broker":"1d34925b.6e4b5e","x":230,"y":2200,"wires":[["2507442c.6fca4c"]]},{"id":"2507442c.6fca4c","type":"function","z":"27a1dcd5.ab7ad4","name":"InitSlots","func":"var slots = {\"room\":msg.payload.siteId}\n\nmsg.payload.slots.forEach(function(slot) {\n    slots[slot.slotName] = slot.value.value\n});\n    \nreturn {\n    \"topic\":msg.topic,\n    \"intentName\": msg.payload.intent.intentName,\n    \"siteId\": msg.payload.siteId,\n    \"slots\": slots\n}","outputs":1,"noerr":0,"initialize":"","finalize":"","x":420,"y":2200,"wires":[["dda01f51.03a03"]]},{"id":"dda01f51.03a03","type":"debug","z":"27a1dcd5.ab7ad4","name":"","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"true","targetType":"full","statusVal":"","statusType":"auto","x":570,"y":2200,"wires":[]},{"id":"1d34925b.6e4b5e","type":"mqtt-broker","name":"MQTT_MOND","broker":"10.2.254.1","port":"1883","clientid":"","usetls":false,"compatmode":true,"keepalive":"60","cleansession":true,"birthTopic":"","birthQos":"0","birthPayload":"","closeTopic":"","closeQos":"0","closePayload":"","willTopic":"","willQos":"0","willPayload":""}]

Give mqtt and nodered a try.

1 Like
5

@boro. Yeah, I figured I leave the post (after I read it more closely) in case our problems are related. It was worth a shot. Was there nothing in the logs on either side when you try to connect? (node red or rhasspy). One last idea: Remove the verify server certificate in the node red websocket TLS config, but I guess chrome would complain then as well.

@kaykoch: Thanks man! That saves me a lot of trouble creating the flows I want in node red. I have all my HA automations there, so I prefer to keep it all in one place. Thanks very much for sharing!
EDIT: Now I know why the function wasn’t working for me the first time. The mqtt node output has to be set to parsed json. very obvious in hindsight. Maybe amend your original post to include this hint, in case others find it? :slight_smile:

6

@kaykoch

Your approach works like a charm, thanks a lot for bringing it up !
As I’m also using an mqtt broker in my setup this solution makes a lot of sense and as @hillbicks already mentioned, it saves a lot of trouble when interacting with the mqtt broker. As I’m just beginning I was only focused on the ‘easy’ approach.
Your answer doesn’t solve the ws issue, but for me this will be the way forward, thanks again.
I will mark it as a solution.

1 Like