What's the best way to minimize TTS delay on my door-entry alerts?

When someone uses my guest bathroom, they are greeted with a welcome message and a pleasant melody. This is set up with an entry sensor on the door and a Google Home Mini on the countertop. When the door is closed, the greeting begins, then the music. When the door is opened again, the music stops and a goodbye message is played.

However, there is a ~3 second delay between when the door is opened/closed and when the Google TTS kicks in. I’m trying to figure out what my options might be for minimizing that as much as possible, and would appreciate any advice about which to pursue. I see 2 obvious possibilities:

  1. The entry sensor works through Wink because despite hours of trying, I have not been able to get HA to recognize on/off via Aeotec Z-stick. It seems like taking Wink out of the equation could potentially save a little time, but as of now I’m at a brick wall on this one.

  2. Replace TTS with a pre-generated MP3. I tried this, but the problem is that it does not seem to be possible to play that as a local file. Rather, it needs to be accessed via HTTP. Obviously there’s an HTTP server running on this thing, but I don’t know where to go for those files and whether I can drop some MP3s in there to have them accessible to a media_player. Is that possible? I’ve tried uploading the MP3s to an external web server and that works, but that’s really sub-optimal and I’d rather have it internal.

Does either of those sound more likely than the other to significantly reduce delay? Or are there any other options I should be looking at?

For #2, I have figured out how to make those accessible via local web server (added a ‘www’ directory into config and put files in there) and can access them from my browser. However apparently Home Assistant’s aversion to playing local files still applies. So when I have the same exact URL that works in my browser locally (e.g. http://hassio:8123/local/audio/voice/front-door-opened.mp3) it does NOT work when Home Assistant tries to access it. Any thoughts on why this is?

Put the mp3 in your www directory and the media_id is

http://your.ip.address:8123/local/name_of_track.mp3
1 Like

I can access that successfully in a web browser, but Home Assistant will not play it.

My service call is:

  - service: media_player.play_media
    data:
      entity_id: media_player.bathroom_speaker
      media_content_id: 'http://hassio:8123/local/front-door-opened.mp3'
      media_content_type: audio/mp3

If I go to http://hassio:8123/local/front-door-opened.mp3 in my browser it plays the file, but not in the above service call. If I point it to http://mydomain.com/front-door-opened.mp3 then Home Assistant will also play it.

I decided to try and wget that file via ssh, and I get a connection refused message. So it seems like Home Assistant really does not want to connect to itself…

Perhaps it just can’t resolve hassio:8123? Use the ip address. It definitely works here on a normal homeassistant install.

Wink is almost certainly responsible for most of that delay. As an example, I have a Zwave receptacle that was set up initially through Wink. There would be a 2-3sec delay between toggling the switch in HA and the switch turning on. As soon as I switched to a USB Zwave stick and native HA Zwave integration of the switch, toggling the switch in HA makes the switch react instantly. It’s almost scary how quick it reacts.

I would really love to cut out my reliance on anything outside of my immediate control (i.e. Wink). I do have 2 power switches that are WiFi and work through HA directly and the speed of those is frightening.

Unfortunately I’ve spent probably 3 hours trying to get my Linear WADWAZ-1 entry sensors working via Z-stick following the documentation (adding node from UI) and reading various posts and have begrudgingly given up, which I hate to do, but like I said, brick wall. Maybe I need to get a different sensor to try, but I’m using 4 of them so it would be a bit annoying to have to go replace them all.

Weird. I’ve tried localhost:8123, 127.0.0.1:8123, and its actual LAN IP:8123 and I’m getting connection refused on all of them. Wonder if it’s some sort of firewall setting on my router, which is an Asus RT-N66U. But wait, if it’s 127.0.0.1 then that shouldn’t even have to go through the router. I don’t know, I’m kind of at a loss there.

core-ssh:~# wget http://hassio:8123/local/front-door-opened.mp3
Connecting to hassio:8123 (172.30.32.2:8123)
wget: can’t connect to remote host (172.30.32.2): Connection refused
core-ssh:~# wget http://127.0.0.1:8123/local/front-door-opened.mp3
Connecting to 127.0.0.1:8123 (127.0.0.1:8123)
wget: can’t connect to remote host (127.0.0.1): Connection refused
core-ssh:~# wget http://localhost:8123/local/front-door-opened.mp3
Connecting to localhost:8123 (127.0.0.1:8123)
wget: can’t connect to remote host (127.0.0.1): Connection refused
core-ssh:~# ping hassio
PING hassio (172.30.32.2): 56 data bytes
64 bytes from 172.30.32.2: seq=0 ttl=64 time=0.335 ms
^C
— hassio ping statistics —
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 0.335/0.335/0.335 ms
core-ssh:~# ping 127.0.0.1
PING 127.0.0.1 (127.0.0.1): 56 data bytes
64 bytes from 127.0.0.1: seq=0 ttl=64 time=0.241 ms
64 bytes from 127.0.0.1: seq=1 ttl=64 time=0.205 ms
^C
— 127.0.0.1 ping statistics —
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 0.205/0.223/0.241 ms

Dunno then, needs a network guru to work it out.

Like I say, definitely works here on a local file with the IP address.

:man_shrugging:

No idea, sorry :confused:

I don’t have any experience with Wink whatsoever but in terms of z-wave, have you made sure to exclude the door sensor before trying to add it to the z-stick? Probably a stupid question but thought I may as well throw it out there.

You are using hassio so this is running in a docker container, right? I don’t use docker so couldn’t say exactly where to go, but look at port mappings on the docker container. My guess it is only listening on it’s local docker ip which is mapped out to something.

Can try netstat -nlp to see what is listening on what ports.

It was brand new, this particular sensor was never was linked to Wink to begin with. The others are through Wink, so my thinking was to set this one up first on Z-stick. So nothing to exclude it from.

That said, it does link with the Z-stick fine, and Z-stick will show it in the menu, and logs will show that it communicates. I’ve tried excluding and then adding again multiple times. Still sticks in the aforementioned behavior with always “sleeping.”

Thanks, I’ll look into that.

most z-wave device manuals I have for various devices all suggest to do an ‘exclude’ before an ‘include’ even when its brand new.

Have a look at the settings for the device in the z-wave control panel within Hass as maybe you just need to change the sleep timeout / poll time

It is normal that a battery powered device is always sleeping. My neo coolcam door detectors are always sleeping but if I check the logs they always wake up at the same times every day and exchange messages with the controller (wake up interval is 12hrs). The fact they are always sleeping doesn’t affect detecting open/close in my case.

Interesting, that’s good to know! I figured the sleeping status was related to the lack of state changes, but maybe that just comes down to something wrong in the config. It’s weird.

After excluding and re-pairing several times, many reboots, etc., I finally just said screw it and connected it through Wink. Hate to do that, I’m basically just punting on removing Wink until a later time, but too many enhancements on my backlog to take any more time trying the same things over and over again.

@Steven6702 - Were you able to figure out how to run local files through the google tts component? And did you come across any tricks that helped with reducing the slight delay between a sensor being tripped, and the google tts playing a saved MP3 file? I have 60 or 70 MP3s that HA broadcasts out throughout my house upon various events, and while the delay is typically less than 3 seconds, 3 seconds is 3 seconds too long for the the door, motion, etc. based broadcasts.