WebSocket API doesn't catch intents on base, only on satellite about rhasspy

[synesthesiam]

I got this working this morning for the wake/text/intent websocket messages. The base station will now check the satellite site ids for the respective wake/ASR/NLU system and forward those events to the base websocket clients.

This seems to be a problem only with MQTT base/satellite set ups. Using remote HTTP works because the base handles all the requests as if they were its own.

[synesthesiam]

Pushing a new Docker image with a fix for the missing siteId. Added in the sessionId, customData, and wakewordId for good measure.

The master/satellite issue needs some more thought. The easy fix is to have the master web server automatically listen for siteIds from all satellites. Is there ever a case where a user would not want to do this?

[koenvervloesem]

I'm not sure about all possible cases (Rhasspy allows a lot ;-)), but the most common case seems to be that the master does intent recognition and the satellites are just audio receivers and players with wake word recognition. So at least for that case, I would expect that listening to the ws://rhasspy:12101/api/events/intent WebSocket URL on the master will also get me the intents originating from sentences spoken on the satellites.

I can't find a case where this behaviour is not wanted. But maybe I'm thinking about this with my MQTT hat on, which I'm much more accustomed to than WebSockets. Maybe @ulno has more experience with this?

[synesthesiam]

I'll plan to add it in for now. We just need to be extra careful about which messages the master web server responds to. Me forgetting small things tends to lead to some service duplicating a response :/

[ulno]

tried a new version today in venv and still had no siteId - i am now using change nodes in Node-Red and remember the siteid myself based on teh websocket I am listening to.

[synesthesiam]

Should be in the main Docker image now.