You know most people won’t use voice assist via a browser. If you are at your browser, click a button.
Esphome based devices won’t require ssl. Voip doesn’t either.
1 Like
@Kertz1954 : please read. no ssl, no assist
@petro: So I repeat, no one thought of this? Btw, as per the devs, Companion app does not have the same abilities as chrome, which does allow for insecure mic usage. But companion app uses Webview which does not. So again, not thought through.
@nickrout: ESPHome is a new child of HA and that’s fine, but maaaany people dislike it because it is not as useful as other integrations. It is nice, but too limited and not intuitive. So what is the solution for everyone else? And who wants to use ESPHome to use a mic? 0.x % of the people?
There is a companion app and that is the main entry point for most people with a mobile device. And it is the mic that everyone has. And it does not work with Assist.
So, I’m sorry, but what good is a year of the voice if the most obvious approaches are all not supported and nobody thought of a workaround?
Tablets, mobile phones, computers… they all use browsers/companion app. And all are available and used by most users. None will work.
Just saying: year of the voice was never a good idea but if it doesn’t even work with the “stock” app, it makes even less sense.
8 Likes
Have patience you angry man. Voice assist only started this month.
12 Likes
The year of the voice started January. From the beginning it must have been clear that this would not work without stock ssl capabilities.
And even if not, I just keep hearing “don’t use a browser”. What a useless comment. Then why implement it in companion app. I am looking for a solution and asking if anybody knows one and all the smart people just say “don’t use a browser because browsers won’t work”. You don’t say. Then what was the point of this Assist in companion app? 
1 Like
No one is saying don’t use a browser. We’re telling you that’s the limitation of a browser. If you want to use the browser, you have to set up SSL.
Relax, you’re being unreasonable.
12 Likes
Me neither.
I only found out about it because of this.
I find the documentation around TTS very confusing too. I only (re)read it because I found the new speak service.
They also seem to have ‘sneaked in’ the new announce parameter to the media_player.play_media service.
I have discovered though that the announce is used by default with tts.service_say which as far as I can tell prevents the media_player state being updated as well as all of it’s attributes.
I’m waiting for some feedback; see a few post further down from the post I linked to above (here) but I think this is a huge bug.
It is easy to test and see if it is just me or if it affects you (everyone?) too…
Watch the media player state in a separate window in the Dev Tools while a tts plays using a service called directly from the Dev Tools.
First: i want to say, there is a “setting” in EDGE and i believe chrome, where you “locally” can “Allow” non-secure, bla. bla. bla. , i shared it here in the forum and on discord … somehow your attitude made me forget exact url to this settings
So that 2 browser options
Second: yes it’s a Feature in it’s cradle
Third: if you think it’s such a bad idea, Don’t use it, pretend it doesn’t exist, go on with your life
IMHO, you are right. As are Petro and Nick.
And I do feel left in the dark too with this new feature. Great to experiment with a m5 Echo, but very Alpha just yet.
This seems to be the classic communication mixup: HA cheer halleluja for a new feature in its very very early stages of conception, and the regular end user ( does he/she even exist ) expects a fully fleshed out functionality because of all the exclamation marks surrounding the ‘awesome’ in the release notes/party….
Next we see the tech people ‘explain’ why (the hardware) things don’t work, while users need an explanation to get things to work…
Don’t think this will ever change, given some 6 years of experience in Awesome ness.
So try to go with the flow ( experiment along ) , make the best of it and shrug now and then. Accept things are nowhere near they are praised to be (yet) , but, helping out with positive and constructive feedback, make things come closer.
Also, even though Voice might be claimed to be the penultimate of awesomeness, we need to realize it’s a niche feature in a Home Automation system, in which we try to minimize incidental interaction in the first place?
Personally I’d love to see 10% of this Voice effort go to the Frontend , and finally facilitate some very long standing requests from the community.
That probably won’t happen either, so again, trying to make the best of it given what we do get in awesomeness 
)because that still is what this project is, again, imho(
10 Likes
I’ve updated from 2023.4.6 to 2023.5.2 and I can confirm yeah that local tuya is still working and my entities are still exposed to Google assistant and Alexa
For TTS I always used tts.google_translate_say and not tts.speak and it’s still working
1 Like
One of the best lines of advice I have ever seen on this forum.
Learn to shrug.
It’s all you have really.
2 Likes
Yes everything still works. No question.
But have you checked the state and attributes of your players?
I’d really like to know if the state changes to playing and the attributes e.g. media_duration changes.
@boheme61 :
Yes and no. It is a limitation of browsers which can be bypassed in some. However, Companion app uses Webview and you cannot bypass there. You need a fix in companion app or a nazive SSL support in HA.
@petro :
Don’t worry, I am relaxed. But I am not a fan of just saying "it’s the other people’s fault so our great new feature is not really all that well thought through (especially since from the beginning the team emphasized privacy and local).
I have not been this disinterested in the monthly updates since I started using HA. This was the first release this year that actually offered a tiny thing of interest: the ability to test voice in HA. And then… flopppp
Anyway, maybe someone will agree that native SSL is necessary if this voice approach is supposed to ever make sense. I will wait until then and if nobody agrees, then well, I will just hope that 2024 will finally be “Year of bug fixes and frontend”
3 Likes
Well, you might need to mention which “phone” you are using, as Kertz said above, works for him, and be surprised, works for me 2
I guess maybe you just have wrong “phone” , or some fancy iPhone
It is independent of the phone. You need ssl. If you have SSL installed on your HA setup, then it will work with Android and iPhone Companion apps. If not, it will not.
And HA stock does not have SSL capability. You need to install DuckDNS or another addon that will handle the certificates for you. This then requires external communication that I do not want.
Thats false.
wrong, i don’t have SSL installed in HA, and have an Android, AND there are several webviews
so maybe a fix for your (and others) device will turn up eventually
Using Samsung S10plus, Android 12. Current Companion app.
i have Android 9, older Samsung SM-G390F, and current APP
PS: try to go to settings/apps/default apps … and choose chrome as default
I don’t know how they have build the Companion APP, but if the choose d ,use platform-default, then i guess it’s the “Defaults Webview” it uses
Did you test the sentences you want to speak via typing. As >50% are not working here or dont do what is expected or described, I don’t care if I type them and they are not working or speak them and they are not working. 
FYI Balloob indicated that http voice access will be added to the app:
3 Likes