Hi @jonaspaulo, welcome. This would work if you were using MQTT to connect your server and satellites, but HTTP only ever goes from satellite to server.
This happens because the server has no knowledge of the satellite IP addresses. With MQTT, the broker broadcasts to all connected clientd so the satellite can pick up the message and reach out to the server for TTS, etc.
Since the server has no audio output it isn’t forwarding the play wav to the client i guess.
Maybe I am missing something.
Thanks!
[EDIT] Nvm it works if we also set the audio play on the server to Hermes MQTT, although it doesn’t seem to close the stream since that after playing the wav it timeout:
ash-4.3# curl -X POST “http://192.168.1.88:12101/api/play-wav?siteId=livingroom,kitchen” -H “Content-Type: audio/wav” --data-binary @“alert.wav”
Ah, that’s interesting. The server can issue the play message over MQTT with the right site id, but it won’t hear the “done” message because it’s not subscribed to that same site id (livingroom).
One way to get around this is to POST to /api/mqtt/hermes/tts/say with a tts/say JSON message (siteId = livingroom). This will just put the MQTT message out and not wait for any kind of response. You can do this for all of the Hermes messages
But how to do it for a .wav file? Should I encode it in the json payload? and if yes calling which parameter? it seems that for tts/say the parameter is only a text:
That would be the playBytes message. Unfortunately, that one won’t work through the HTTP interface yet because the MQTT payload is the (binary) WAV data instead of JSON. But you can send that message through MQTT directly at least.
In the payload of the mqtt message there is only wav_bytes since siteId and requestId are already present in the topic so the topic will be:
hermes/audioServer/siteId/playBytes/requestId
and the payload will be the raw bytes of the .wav file.
payload: RIFF $ WAVEfmt >} data ecc…
