Support alert_once/tag for TTS notifications

[djak250]

Is your feature request related to a problem? Please describe.
I'm using TTS as a workaround for some device specific limitations which prevent using alarm_stream from overriding silent/DND settings. However, TTS notifications are not treated the same as a normal notification. As such, setting a tag and the alert_once property do not have any affect. I looked through the code, and I understand that it's just not something that's supported yet.

Describe the solution you'd like
Allow a tag and alert_once to be sent with a TTS notification, and if a duplicate is sent after the first has announced, then the second should not announce.

Describe alternatives you've considered, if any

• I went down a failed path of trying to store some form of state to track that the "tag" had already been sent within my automation, but due to the tight scope of variables, I wasn't able to find a way.
• I toyed with the idea of making a sensor helper that would just hold the last five tts notification tags and checking if the tag existed in that before firing the notification. This solution isn't very portable sadly. I'm updating a widely used blueprint, and I think it's too much of a requirement to ask any user to make their own helper sensor and integrate it.

Additional context
Alternatively, it'd be helpful to expose a last_tts_notification sensor, similar to the last_notification that's already present in the companion app's entity. However, that would only help for back to back notification cases, and falls apart when TTS notifications come out of sync:

• For example, messageA -> messageB -> messageA would trigger each time, due to the "last_nofication" being different each iteration

[dshokouhi]

However, TTS notifications are not treated the same as a normal notification. As such, setting a tag and the alert_once property do not have any affect. I looked through the code, and I understand that it's just not something that's supported yet.

TTS notifications have nothing to do with a standard notification and they should not be expected to behave the same.

Allow a tag and alert_once to be sent with a TTS notification, and if a duplicate is sent after the first has announced, then the second should not announce.

This feels like something that can be handled by the automation in question rather than the device itself. In fact we have no way of knowing which TTS message is currently speaking as we have no insight into the TTS queue. You are asking for functionality that simply does not exist.

• I went down a failed path of trying to store some form of state to track that the "tag" had already been sent within my automation, but due to the tight scope of variables, I wasn't able to find a way.

cant you just set the automation mode so the test does not run over and over again? Maybe add a delay to account for the speech length?

This does not seem like a request that can be handled in the way you wish it to. This feels like something the automation can better handle.

Also did you consider making use of the command to stop TTS?

[djak250]

I realize that they're different in their actual implementation. I made sure to do my due diligence and read through the code where TTS is actually handled before making the request.

cant you just set the automation mode so the test does not run over and over again? Maybe add a delay to account for the speech length?

Sadly, not in this case, as the automation is also repeating to update the image in an actual notification with an updated snapshot of a camera alert upon receipt of a new MQTT value. The TTS notification is sent in tandem to get around restrictions of using alert_stream to bypass DND on Samsung phones (discussed at length here: #1465.) The workaround is working as expected, with both notifications being received correctly, with the only quirk that I can't find a way to prevent subsequent TTS notifications after the first one fires.

Alas, I will keep looking for ways to accomplish it with changes to the automation.

[dshokouhi]

closing as we have no way of knowing what text is in the TTS queue so we cant reliably skip them, this still feels like a better job for a automation mode.