Hello all, I’m running into an unexpected problem. I have Rhasspy running inside of a Docker container, and I have another program which starts at boot on a Raspberry Pi. My other program connects to the MQTT broker provided by Rhasspy, and once the connection callback fires, it immediately publishes a pair of notifications indicating that the system has initialized to the dialogue manager. However, these notifications are never actually played. Any subsequent notifications get turned into spoken dialogue as expected. In addition, if I start my other program manually after the system has finished booting, the pair of notifications indicating initialization are played properly. This really feels like a timing issue, where even though I’m able to connect to the broker, the dialogue manager or the text-to-speech system is not ready yet, and the notifications are getting skipped. Is there any way to tell when Rhasspy will be in a state to handle the notifications? I definitely don’t want to do an arbitrary time delay.
I guess the only idea that I have had so far for this is to subscribe to the dialogue manager session started topic and to wait until I get a message there in response to trying to publish my initialization notification. I have looked at the documentation, and I don’t see anything that would be better at determining when the system is initialized.
You could try to publish the notification from your program as retained.
That’s an interesting idea, but the last time I read about retained, only a single message for each topic can be retained, and there may potentially be multiple notifications depending on how long it takes for the system to completely initialize. I’m currently using a Raspberry Pi 3 for this, and I don’t know when I will be able to obtain a 4 because of the shortage, so that’s probably not helping.
Ah yes, that is a problem if you have more than one message. Maybe combine them in to one if possible?
Also, maybe you can add a delayed start on the program?
Another idea might be to add one notification as retained and let you program listen to hermes/tts/sayFinished and when that message arrives, publish the second notification.
Just trying to come up with some ideas here 
Yeah, the idea of waiting for sayFinished is pretty similar to the idea I’m trying now, which is publishing the first notification to the dialogue manager and waiting for sessionStarted. If I don’t get that message within a certain amount of time, I’m expecting to have a timeout and republish.
It took me forever to finish trying this, but unfortunately it doesn’t seem to work. I was trying to publish a new notification using the dialogue manager every second, until a session started message appeared. It took about five seconds to get a session started message, but unfortunately this still did not produce any speech. I don’t know what else to try.
Again, my update is super delayed. I was able to get this working. What I’m doing is repeatedly starting a new dialogue manager session until I get a sayFinished message from the text-to-speech system. I’m not absolutely in love with this approach, but it does work. I really wish there was a way to query the status of the overall system, or be notified that it is fully initialized.