Wow!
this is amazing and thank you so much for the quick updates!
service: chime_tts.say
target:
entity_id: media_player.wohnzimmer
data:
tts_platform: amazon_polly
announce: true
message:
- type: chime
path: /media/notify/1_slow.mp3
audio_conversion: "-filter:a volume=.25"
- type: tts
message: Diese Nachricht ist für Nim. Vielen Dank für das schnelle turnaround!
delay: -3800
audio_conversion: "-filter:a volume=5"
volume_level: .4
works great so far!
An additional Idea:
also saving message array objects as a presets, with audio conversion filter, delay, and other options.
as in my example above, /media/notify/1_slow.mp3 with a delay of -3800 and volume of .25 works great, for the chime 6_ok a delay of -5800 is good.
Both are bells/chimes that have a very long sustain that fades out, you can find them here: 1.37 MB folder on MEGA they are all from notificationsounds.com albeit renamed )
And saving these with a preset would be a timesaver! (I could probably do that with a custom script for now)
I think I the overlay feature needs to be defined as a parameter of the first segment, and not the second, seeing as it is associated with the chime, and not the TTS audio. Also, I feel it would be easier to understand if it were added as a separate parameter to the delay parameter, Eg:
service: chime_tts.say
target:
entity_id: media_player.wohnzimmer
data:
tts_platform: amazon_polly
announce: true
message:
- type: chime
path: /media/notify/1_slow.mp3
audio_conversion: "-filter:a volume=.25"
overlay: 3800 # <-- Overlay with the next mesage segment
- type: tts
message: Diese Nachricht ist für Lukas. Vielen Dank für den tollen Vorschlag!
audio_conversion: "-filter:a volume=5"
Message Segment Presets
I really like the idea of defining preset message segments. You’re right in that you can achieve the same thing with scripts, but the whole idea of Chime TTS is to provide additional audio notifications functionality easily.
In addition to chime segments, the segment presets would also be useful for TTS segments. You could configure a TTS segment preset for each TTS platform (with the tts_platform, tts_playback_speed, options parameters, etc.) allowing you to only have to set the message string.
I think a good way to implement the feature would be to add a new multiline textfield to the Chime TTS configuration page, “Custom Segments”, which would hold a YAML array of N “chime” and/or “tts” segment object types, with the relevant parameter values. Each object would also have a unique “name” value which would serve as a reference when used in service calls to chime_tts.say and chime_tts.say_url.
An example of the “Custom Segments” textfield value:
- type: chime
path: /media/chimes/my_chime.mp3
audio_conversion: "-filter:a volume=1.5"
overlay: 3875
name: my_chime # <-- Reference ID to include in service calls
- type: tts
message: Replace this string when calling the service
tts_platform: amazon_polly
ttts_playback_speed: 115
name: amazon_polly # <-- Reference ID to include in service calls
great ideas!
I agree the overlay should be part of the chime. I like verbose names, may I suggest overlayStartMills
regarding the segments (this might just repeat what you were saying, not sure)
the segment presets could be used like templates, referencing a preset would take all of its values and overwrite with any given value. eg preset.update(given_values) https://docs.python.org/2/library/stdtypes.html#dict.update
- my_chime: # <-- Reference ID as Dict Key
type: chime
path: /media/chimes/my_chime.mp3
audio_conversion: "-filter:a volume=1.5"
overlayStartMills: 3875
Unfortunately the configuration page for integrations has quite limited UI capabilities. Currently it is not possible to add a multiline textarea to add segment presets as a YAML array string.
I have thought up the following ways to implement segment presets, none of which I like
1. Add individual segment preset textfields to the configuration
Without multiline textareas in the configuration page, I could instead add single line textfields, each defining a single segment preset YAML object, eg: - my_chime:\n type: chime\n path: /media/chimes/my_chime.mp3\n audio_conversion: "-filter:a volume=1.5"\n overlay: 3875
I used this approach for the 5 custom chime slots, but adding another set for the segment presets would extend the height of the configuration page even more. Another issue is that there is no way split up the configuration page with headings…it’s just one long list. Without headings it becomes visually quite difficult to understand, even if I add only 5 fields.
This approach is quite ugly, but the main issue I think is that it would be difficult to read & modify.
2. Add a new service: chime_tts.manage_presets
I could create a new Chime TTS service which users could use to both view and modify their segment presets. While this solution is straightforward, I don’t like the idea of having the configuration be split into two different locations.
3. Add a webpage to manage section presets
I could create a small web app inside Home Assistant, which could be accessible via the sidebar, to allow users to easily view and modify their segment presets. If I go down this road I would move the remaining configuration options as well to keep them all together…but it feels like overkill just to support the new feature.
would it be possible to move to (a) config.yaml?
lots of integrations a working on getting everything into the UI but if the setup is as limited, moving to the UI may just not be the best option yet.
Yes, it would probably make it easier, but at the same time it would break the current configuration values for users which would be a pain and also potentially break the integration for them.
I’m using Chime TTS with Raspiaudo Muse Luxe in ESP Home because I wanted a completely local solution. It’s great but unfortunately, Chime insists on sending the path to the created mp3 file using my Nabua Casa external URL, not my internal local ip. I’ve confirmed that in the Muse Luxe log file. How do I set it to use a local path ONLY
I could add a toggle parameter to the chime_tts.say_url service to define whether the URL should use the local or remote path, but I believe you can already achieve this using templating. You would need to perform a find/replace to switch the remote path to the local IP address.
Still looking for an answer on why chime_tts.say uses my external Nabu Casa URL for the path to the mp3 file created and not my local internal path when sending the play to ESP Muse luxe
The following is from the Muse luxe log file.
[D][media_player:066]: Media URL: https:/[redacted].ui.nabu.casa/media/local/sounds/temp/chime_tts/3ppbo8a7.mp3
I just released a beta version which switches the paths used for local files from the external URL to the internal local one.
Can you please upgrade the the new versinon, v0.12.1-beta2, and let me know if the issue is resolved?
Thanks, but that didn’t fix the problem, I also cleared the cache and performed a hard boot and that still failed to change to use the local path. Maybe Nabu Casa will give you a developer account to help with debugging and testing
and thank you so much for the quick updates!
i’m happy it’s working for you!
