Any interest in a Subcategory for Homebridge?

[CatmanV2]

I know we talked about this a while back, but wondered if anyone has any ideas at all? It's still a 5-10 second pause between initiating a TTS event and getting the output.

This is using either a direct Luup call or the most excellent VeraTTS plug in.

I noticed that executing from reactor using the little 'run' icon, I'm getting an occasional '0 timeout undefined' error (even though the event eventually happens

Any thoughts, anyone?

C

[gwp1]

I'd just love to know how you got the Vera>Alexa TTS to work. My AMZ account has 2FA enabled (because why wouldn't you use 2FA everywhere...?) and my VeraSecure is on 7.31 (the 7.32 beta just still seems flakey from what I keep reading) and these two things together seem to be the death knoll for therealdb Vera plugin.

[CatmanV2]

Pass. I don't have 2FA because (without getting into a huge argument about relative risks) why would I

And I don't use Vera because, again, why would I

And both TTS and voice control work absolutely marvellously apart from this slightly irritating 5-10 sec delay

C

[gwp1]

I believe I'm confused. I thought the topic was Vera>Alexa TTS and I was inquiring how you got it to work, that's all. If you're not using Vera... guess that's where my confusion about Vera>Alexa TTS stems from.

Re 2FA, to each his own. That's not the topic.

[CatmanV2]

Ahh, well that's a fair call. The plugin is called Vera Alexa, even though I run it on OpenLuup......

Clearer?

C

[gwp1]

Yep, clear.

[Elcid]

@gwp1
I have tts working in vera and openluup with 2FA enabled and I auto update the cookie. Occasionally i have to update by hand but that's rare. If you want help just ask.

[Elcid]

@catmanv2 I have no speed issues, maybe your system is overloaded?

[CatmanV2]

@elcid said in Vera Alexa TTS slowwwww (still):

@catmanv2 I have no speed issues, maybe your system is overloaded?

It seems unlikely

I'm running OpenLuup on an Intel NUC

top - 18:09:57 up 126 days, 11:16,  1 user,  load average: 0.10, 0.11, 0.09

Everything else is nice and snappy (with the exception of the door sensors which are utter rubbish, but it's an old issue with these devices)

Even if I tell Alexa to turn on a device via HA Bridge, the command is typically executed before I get the 'OK' from Alexa.

The only exception is when I have (typically Reactor, but the delay is apparent in direct Luup calls) dealing with a response. If I have a voice command that triggers Speech > device activation, the activation waits for (up to) 10 seconds for the speech to complete, then the device activation is immediate. If I change the order to Device activation > Speech the devices activate immediately, then there's a (up to) 10 second pause for the spoken response (Not the "OK" that's immediate)

Where are you based @Elcid ?

C

[therealdb]

Sounds weird, but look at logs. I’ve not touched it since ages, but I could dedicate some time during the weekends.

I have 2fa enabled and I’m using oath tool to automatically renew the cookie. I’ve not touched it since years. I’ve moved away from the Plugin because I’m using a custom udp server to offload the Vera, but it’s running the same sh script anyway.

[Elcid]

@catmanv2 said in Vera Alexa TTS slowwwww (still):

Where are you based

Near Brighton.

[CatmanV2]

@elcid so it's not country specific then!

C

[toggledbits]

@therealdb does the Vera Alexa plugin do anything self-reflexive, like make (or cause to be made by something else) an HTTP request to the Vera/openLuup, or ask that it play a file on the Vera/openLuup system?

I had an issue with getting the Sonos plugin running on openLuup.... there was a strange delay, not unlike the situation described here. It turned out that the Sonos plugin was, in its HTTP request handler, asking the Sonos to play a file and waiting for the Sonos to ack that it had started it, but the Sonos couldn't play the file because (!) openLuup's web server is single-threaded and can only process one request at a time, and it was in a request already. So until the originating request timed out, the Sonos player couldn't get the media file it needed from openLuup, but the original request was waiting for the Sonos to signal it was playing it (fortunately it had a timeout).

MSR performs actions by making HTTP requests to openLuup...

[therealdb]

@toggledbits it’s not doing http calls, but it’s waiting for a bash command to complete. I’m not sure it this is correlated, but I’ll take a look.