leafney
commented
1 year ago Upon further testing, I found that there is no issue with the situation in Node-Red. I apologize for the confusion, as it was my mistake.
The reason for loading the default configuration values was due to a type error in the parameters, as I directly used the provided sample code. The problem was resolved by changing "cache":"True", to "cache":true,.
msg.payload={
"chime_path":"custom_components/chime_tts/mp3s/ding_dong.mp3",
"delay":450,
"final_delay":50,
"message":"Hello World",
"tts_platform":"edge_tts",
"cache":false,
"announce":true
}
return msg;
nimroddolev
Checklist
Is your feature request related to a problem? Please describe.
This is a fantastic project. Thanks.
In the first scenario, when calling the service through HomeAssistant:
If
cache=Trueis set, when playing a TTS audio, it will first play the previously played audio or only start playing a part of it before playing the current audio content.If
cache=Falseis set, the first time a TTS audio is played after that, it will also play the previously played audio once again before playing the latest TTS content. After that, the TTS audio will play normally without playing the previous audio content.In the second scenario, when calling it in Node-Red:
The data passed is as follows:
The output log is as follows:
The problem is: although
cache=Trueis set, it doesn't seem to work. The generated file/media/sounds/temp/chime_tts/l11vjl9d.mp3cannot be found in the file system, but the TTS audio output is normal.Describe the solution you'd like
no.
Describe alternatives you've considered
I am also puzzled by the situation where it did not take effect in Node-Red. I will conduct further tests to find the reason.
Additional context
chime_tts version: v0.7.4-beta1 home-assistant version: 2023.10.3 home-assistant platform: docker node-red version: v3.0.2 node-red installed node-red-contrib-home-assistant-websocket version: v0.57.4