Delayed audio at GH minis

[cc4005]

I have several event notifications consisting of a .wav tone followed by a speak action. Of late I'm having consistent delays of ~120 seconds for the audio to play on my GH minis via the chromecast PI. (Sometimes the .wav plays immediately, but the TTS seems to always be delayed). I've confirmed that the events are firing properly, just the audio is delayed.

The problem seems to have started when I segmented my IoT devices--including the minis--to a separate vlan/subnet, and I'm hoping someone here can give me advice on troubleshooting. My HS server and z-net are on my trusted network (vlan1/192.168.0.xxx) and minis are on vlan107/192.168.107.xxx. Firewall rules allow established and related connections from vlan107 -> vlan1, and all other traffic is dropped. No restrictions from vlan 1 -> vlan107. Might I need to poke another hole for the minis to work properly? I have no understanding of how Bonjour works and whether my firewall may be causing a problem there. I also read elsewhere about an issue with the GH going to sleep although I doubt that's the issue as I've repeated the test within minutes with the same results--and they shouldn't have gone to sleep that quickly.

I've attached a debug log that I started just before manually running an event with the notification actions. I disabled the log just after the audio actually played--about 2 minutes later.

Any advice appreciated. Thanks.

-Wade

edit: On the past 4 tests, 3 times the .wav file played immediately and the TTS was delayed 2+ minutes. The other time both were delayed.


MESSAGE BOARD (copy/paste section below to message board posts)

Current Date/Time: 7/1/2019 9:13:25 PM
HomeSeer Version: HS3 Standard Edition 3.0.0.534
Operating System: Microsoft Windows 10 Pro - Work Station
System Uptime: 0 Days 4 Hours 21 Minutes 58 Seconds
IP Address: 192.168.0.16
Number of Devices: 683
Number of Events: 393
Available Threads: 400
HSTouch Enabled: True
Event Threads: 1
Event Trigger Eval Queue: 0
Event Trigger Priority Eval Queue: 0
Device Exec Queue: 0
HSTouch Event Queue: 0
Email Send Queue: 0
Anti Virus Installed: Windows Defender
In Virtual Machine: No MFG: dell inc.
Enabled Plug-Ins
2.0.59.0: BLBackup
3.0.25.0: BLLock
2.0.28.0: BLOccupied
2.0.66.0: BLOnkyo
3.1.3.33206: Blue-Iris
3.0.0.34: Chromecast
3.0.0.65: EasyTrigger
3.0.0.31: EnvisaLinkAdemco
3.0.0.8: MeiUnifi
1.2019.211.1740: MyQ
3.0.0.33: Nest
3.0.0.63: PHLocation2
1.0.0.7: Restart
3.0.7.0: SDJ-Health
0.0.0.5: Sure Petcare 3P
3.0.2.261: Z-Wave

[AllHailJ]

I have a similar problem speaking to Android tablets. Most of my TTS is now pre-recorded and saved as .mp3 files. I have my tablets on a different subnet as you do. I also run HS3 on linux. I have not had delays as long as you have, but it is different to each tablet and can be delayed for 1-5 seconds. I run a ubiquity edgemax router so I don't think I need to upgrade and iperf says I have plenty of bandwidth. My TTS timing improved when I went to pre-recorded files because I was getting delays on up to 10 seconds with TTS conversion.

Below is the site I used to build my pre-recorded text to speech files.

https://soundoftext.com/

Hope this helps.

[cc4005]

I have a similar problem speaking to Android tablets. Most of my TTS is now pre-recorded and saved as .mp3 files. I have my tablets on a different subnet as you do. I also run HS3 on linux. I have not had delays as long as you have, but it is different to each tablet and can be delayed for 1-5 seconds. I run a ubiquity edgemax router so I don't think I need to upgrade and iperf says I have plenty of bandwidth. My TTS timing improved when I went to pre-recorded files because I was getting delays on up to 10 seconds with TTS conversion.

Below is the site I used to build my pre-recorded text to speech files.

https://soundoftext.com/

Hope this helps.

Thanks for the reply and suggestions. I'm hopeful I can solve the problem in some other way since I've had no delay problems until very recently. If it's due to the network segmentation it seems like I should be able to correct it. But if not I'll look into the pre-recorded speech files.

[cc4005]

I've done a bit more testing. If I remove the play audio (.wav) action, the TTS plays immediately on trigger, as expected. As soon as I insert the audio action, the .wav plays immediately and the TTS is delayed ~ 2 min. (3 consecutive tests using the Run button in the action). Checking or unchecking "Wait for audio to finish" has no effect. Puzzling. It worked correctly for months.

I have several event notifications consisting of a .wav tone followed by a speak action. Of late I'm having consistent delays of ~120 seconds for the audio to play on my GH minis via the chromecast PI. (Sometimes the .wav plays immediately, but the TTS seems to always be delayed). I've confirmed that the events are firing properly, just the audio is delayed.

The problem seems to have started when I segmented my IoT devices--including the minis--to a separate vlan/subnet, and I'm hoping someone here can give me advice on troubleshooting. My HS server and z-net are on my trusted network (vlan1/192.168.0.xxx) and minis are on vlan107/192.168.107.xxx. Firewall rules allow established and related connections from vlan107 -> vlan1, and all other traffic is dropped. No restrictions from vlan 1 -> vlan107. Might I need to poke another hole for the minis to work properly? I have no understanding of how Bonjour works and whether my firewall may be causing a problem there. I also read elsewhere about an issue with the GH going to sleep although I doubt that's the issue as I've repeated the test within minutes with the same results--and they shouldn't have gone to sleep that quickly.

I've attached a debug log that I started just before manually running an event with the notification actions. I disabled the log just after the audio actually played--about 2 minutes later.

Any advice appreciated. Thanks.

-Wade

edit: On the past 4 tests, 3 times the .wav file played immediately and the TTS was delayed 2+ minutes. The other time both were delayed.


MESSAGE BOARD (copy/paste section below to message board posts)

Current Date/Time: 7/1/2019 9:13:25 PM
HomeSeer Version: HS3 Standard Edition 3.0.0.534
Operating System: Microsoft Windows 10 Pro - Work Station
System Uptime: 0 Days 4 Hours 21 Minutes 58 Seconds
IP Address: 192.168.0.16
Number of Devices: 683
Number of Events: 393
Available Threads: 400
HSTouch Enabled: True
Event Threads: 1
Event Trigger Eval Queue: 0
Event Trigger Priority Eval Queue: 0
Device Exec Queue: 0
HSTouch Event Queue: 0
Email Send Queue: 0
Anti Virus Installed: Windows Defender
In Virtual Machine: No MFG: dell inc.
Enabled Plug-Ins
2.0.59.0: BLBackup
3.0.25.0: BLLock
2.0.28.0: BLOccupied
2.0.66.0: BLOnkyo
3.1.3.33206: Blue-Iris
3.0.0.34: Chromecast
3.0.0.65: EasyTrigger
3.0.0.31: EnvisaLinkAdemco
3.0.0.8: MeiUnifi
1.2019.211.1740: MyQ
3.0.0.33: Nest
3.0.0.63: PHLocation2
1.0.0.7: Restart
3.0.7.0: SDJ-Health
0.0.0.5: Sure Petcare 3P
3.0.2.261: Z-Wave

[cc4005]

I added a HS speaker client to the speaker list. The .wav file immediately plays on the speaker client, followed by the speak action as expected. The .wav file never plays on the GH minis and the TTS plays 2 minutes later. Possibly a problem with the .wav file playing and there's a 2 minute timeout before moving on to the TTS? Note that unchecking "wait for audio to finish" on the .wav action has no effect.

I substituted a different .wav file, but no change. Next uninstalled and reinstalled the chromecast PI--made sure the .ini was deleted and recreated. No change.

I guess next test will be to put one of the GH minis back onto my secure network (off my IoT segment). Appreciate any thoughts.

[cc4005]

Moving the GH mini onto the same network segment with HS seems to have fixed the problem so presumably it's a firewall issue. The problem occurs when the GH minis are on the IoT network. HS3 is on my secure network. Right now I'm allowing all established and related traffic from IoT network to secure network. All other traffic is dropped. No restrictions from secure to IoT. spud Are you aware of any other firewall holes that might be needed to make this work correctly?

Thanks.

[spud]

When using system TTS or when playing a .wav file, the HS3 web server is leveraged to serve the audio file to the GH/Chromecasts. So your GH need to be able to access the HS3 web server.

When using Google TTS, the GH/Chromecast directly access the audio from a google URL.

[cc4005]

When using system TTS or when playing a .wav file, the HS3 web server is leveraged to serve the audio file to the GH/Chromecasts. So your GH need to be able to access the HS3 web server.

When using Google TTS, the GH/Chromecast directly access the audio from a google URL.

Thanks for the reply. I'm a bit out of my depth here so please bear with me. Are you saying I would need to allow traffic initiated by the GH device to the network where the server resides? I.e., the GH mini needs to establish new communication to the server in addition to the server establishing communication to the GH mini?

If yes, it seems I have 2 options:
1. Move my GH devices back onto my secure network, or
2. Add pinholes to my firewall to all the GH devices to establish comms to the server.


The other thing that is confusing here is that the TTS will eventually play, just not immediately.

[cc4005]

Getting erratic response from all my GH devices now. Manually triggering an event with a .wav and speak action...the GH on the same network segment with HS worked once, then subsequently hasn't worked with repeated tests. Got one on another network segment to emit the the built-in GH "b-dink" notification once, but not my .wav or speak action. But now even my HS speaker client running on the same PC as HS isn't working reliably--seems to no longer play any speak actions even though the test in the client UI works fine. TTS actions are showing up in the HS log as expected. Looks like I may have a bigger problem than the chromecast PI. If anyone has any ideas for troubleshooting, I'm listening. May move this to the general forum. Thanks.