Now rhasspy:
I have master with MQTT enable, host = its own IP, site-id salle
I have a pi 0 with MQTT enable, host = its own IP, site-id studio
I can only turn on/off the device itself. If I run the command on ‘salle’ with site ‘studio’ nothing happens and vice versa.
I tried to set MQTT on the sat with the master IP as host, but it does the same.
With MQTT explorer, I can see that the mqtt message isn’t received by the other device.
Is it normal right now, or am I missing something ?
Should each rhasspy have its own IP as MQTT host, or all rhasspy devices should have the master IP as MQTT host ?
I don’t know how next full hermes/serviced rhasspy will change all base/sat settings and such, so if all such settings and workflow will change with next version and such setup is premature, let me know
mm… Looking at the code it seems that the satellite should only have their siteId and the master should have all the siteIds (his and all the satellites’).
I’d try:
on master : salle, studio
on sat : studio
@synesthesiam could you confirm or not that a master should have in mqtt settings siteid its id and all satallites ids comma separated ? Sort of siteId : master,sat1,sat2
Yes, this is how it’s supposed to work. The first siteId (“master” in your example) is what Rhasspy should use to publish new messages.
For responses, though, the same siteId is used. So if a hermes/nlu/query comes in, the hermes/intent/<intentName> response from Rhasspy will have the siteId of the query.
Hello everybody,
I folowed all this mqtt disscussions for a while and there is something that I really do not understand.
WHY ???
Rhasspy works with API and web sockets. This works perfekt with nodered. You want to implement a full hermes compatible mqtt comunication. Where is the advantage?
Even if mqtt is (full) implemented, web socket should be remain, as I read. In your plan, you also want to run an own Broker on the satellites. This takes recources (PI zero).
With websocket you have a direct connection between sat and master. No one else is involved. And you can keep wakeword and voice recognition on sat and the rest on master.
Pleas do not missunderstand. I do not want to put your idea down, but i want to understand it.
Thank you in advance
Kay
PS:
Would it be possible to disable the browser gui for zeros. Maybe this would save recources.
Hello Kay,
Well we need some kind of a message bus between the separate components inside Rhasspy. MQTT is a very easy way to do this and pretty common in home automation systems, but there are definetly other ways to achieve this aswell.
I do not really see a reason to run a mqtt broker on any satellite devices, since they can simply connect to the broker on the main device and broadcast their audio once the hotword was detected, at least thats how it worked with Snips.
Re Browser Gui. Just as with the MQTT Broker there is no reason to run this on the satellite devices, since satellite devices only need to detect the wakeword and broadcast the audio afterwards (You only have to create Intents on the Main Device anyways). This is basically a big reason to have separate services for everything starting v2.5 since this way it is pretty simple to deploy for example only the hotword/broadcast audio service to satellite devices and have the other services like the ASR that are more recource intense running on a central device like e.g. a normal Raspberry Pi.
I would not really worry about recource requirements for the MQTT Broker, because they are very low even when the broker is actively used.
I agree with you for mqtt (all connected to the master of course), but I would keep GUI on satellites and especially some endpoints. /api/text-to-speech and /api/listen-for-command for example are two I use on satellites and will really need in the future. Or find a way so we can use them with siteId on master and the master forward them through mqtt to the satellite. Which doesn’t work actually. Or even some /api/mqtt/{topic:’’, payload:} …
Also the GUI is very usefull to access settings (wakeword, mqtt for siteId and master ip, tts) and see if running, log to debug what happens, etc. Each satellite should have a lite version of the GUI.
Oh I simply forgot about this
But since it is modular I suppose this is something everyone can deploy the way he wants
I do not think that there is any performance problem for satellite devices anyways, since both wakeword and GUI do not really require much recources
However when someone wants to have a gui but does not want to have it running all the time he could still simply start the gui container on a user interaction like e.g. a settings button on the satellite device I suppose, just as he might want to have a mute button on there aswell that could simply kill the wakeword container
Thanks for your answers. I also have zeros, connected by websocket. This works.
Of course there must be one kind of information transfer.
If you prefer mqtt and this would solve problems, (which really exist) and which are not solved with a method that actually exist, I also would change. But in this case I would change completly. If mqtt is the better system we could leave websocket and api behind.
Mqtt would be, as snips shows, the only system.
If you have a modular system and could chooce between mqtt and another messaging system, it would only makes sence if there is a real advantage in one.
I know mqtt and its great, useful and lightweight. But then there is no reason for another system, which makes the same. Only work to keep both systems up to date.
A mixture between both will end in trouble, I guess.
So I will build up a second docker nodered with mqtt rhasspy and see whats coming.
I mean:
sat receives message
master “reads” intents and slots
nodered does somthing like switching lamps and sends answers back to sat
“I switched on the light”
or answerd
The time ist 13:15h
So the sat hast to receive text to say.
…
