Speak text through MQTT

Help
1

Hi everybody,

I’d like to have text spoken while giving that command via MQTT. Now I understand I need to publish a message to the topic “hermes/tts/say”.

However I can’t get it to work. What am I doing wrong here? That’s the message I’m publishing as a test:

{
text=‘dies ist eine testnachricht’,
site_id=‘default’,
id=‘780953c9-2790-4f9b-b42f-220a1343df1b’,
session_id=’’
}

There is no entry in the log file, nor is there an audible output of course.

When going to the main page of the interface and have it speak the text of the input field everything works fine, so it’s not an audio issue.

2

I’ve just tested by publishing this to hermes/tts/say

{
  "text": "The temperature is 51.4 degrees",
  "siteId": "Base",
  "sessionId": ""
}

And it sends properly - looks like you need to remove the underscores and camelCase the objects (e.g. change site_id to siteId, etc.)

3

Indeed, have a look at the documentation of Rhasspy Hermes, for instance the hermes/tts/say topic:

The site_id syntax (snake_case) is used for Python code, while the siteId syntax (camelCase) is for the corresponding attributes in JSON payloads. You can see the difference in the example MQTT message and example code of the Rhasspy Hermes documentation.

4

Ok, I understand the difference in syntax. However it still doesn’t work with this:

{
"text": "dies ist eine testnachricht", 
"siteId": "default",
"lang": "de_DE"
}

Do you know if a certain version is required for this? As a voice response is a relatively basic feature I wouldn’t think so. My installation is running on 2.4.20 (can’t upgrade currently because of problems with my microphone hardware in the newer versions).

If Rhasspy is sending recognized commands via MQTT - receiving the voice output to be spoken should work in terms of general settings, shouldn’t it?

5

I’m sorry, I haven’t been using the 2.4 release for more than a year, so I can’t say whether this syntax works there.

6

I just remembered I have another Rhasspy installation running 2.5.7 (without a working microphone, but that doesn’t matter here).

Weirdly it doesn’t log the MQTT packet either.

Are you using the internal MQTT server or an external one?

7

I’m using an external one, Mosquitto running in its own Docker container.

8

Great, my exact setup… :neutral_face:

Thanks for your responses anyway!

9

Try it without lang:
{
“text”: “dies ist eine testnachricht”,
“siteId”: “default”,
}
I remember, this worked for me in one configuration. Not sure

kay

10

I’ve observed my 2.4 and the 2.5 installation.

When sending the message 2.4 stays silent in its logs. On 2.5 I see at least something:

[ERROR:2020-11-17 22:11:32,261] rhasspytts_cli_hermes: parse_mqtt_message (topic=hermes/tts/say)
Traceback (most recent call last):
  File "/usr/lib/rhasspy/rhasspy-hermes/rhasspyhermes/client.py", line 303, in parse_mqtt_message
    json_payload = json.loads(payload)
  File "/usr/lib/python3.7/json/__init__.py", line 343, in loads
    s = s.decode(detect_encoding(s), 'surrogatepass')
UnicodeDecodeError: 'utf-8' codec can't decode byte 0x93 in position 2: invalid start byte

I have no idea what it’s complaining about here. I’m using MQTT.fx as MQTT client. I don’t see any possibility to explicitly set an encoding there. I copied your example, removed the last “,” though.

11

Upgrading to the recently published version 2.5.8 seems to have solved many of my previous problems. I have no idea if they were really addressed in that version or the upgrade just caused some kind of reset.

After the upgrade the docker log would at least give me syntax errors in the message it did now receive. Here’s the message body that worked for me:

{
"text":"dies ist eine testnachricht",
"site_id":"default",
"lang":"de-DE",
"id":"cf9320fc-f5d4-4436-8347-cbbb552c4722",
"session_id": "",
"volume":"1.0"
}