VPE, multiple satellites, which wins on wake word does not work well

I have a problem I did not expect. I have three VPE’s, and I put one in my office, one in the living room, and one in the Kitchen. The Living Room and Kitchen are maybe 5-6 meters apart, and the office about 12 meters down a long hall.

My house is often quiet. If I say “Hey Mycroft” sitting under a meter from the VPE in a quiet voice it often does not hear the wake word, but in a reasonably, conversational voice it does – however one or both of the other two do as well.

As I understand it there’s no prioritization (e.g. by volume) only first-come-wins. If that happens to be the wrong one (maybe a faster network), then the problem is that the STT processing does NOT seem that sensitive, and frequently gets “no text”. I.e. if I look in debug the office says duplicate, the living room may say duplicate, the kitchen says “no text” and nothing happens.

I have reduced wake word sensitivity to “Slightly sensitive” (the lowest). That’s actually bad and why a quiet voice a meter away may fail. But if I set it more sensitive the problem gets worse.

10m should be about 30ms. That SHOULD Be plenty of time to get a consistent winner that is the closest one. My network is pretty flat – wired AP’s all over the place, not over-loaded at all, 1g to the core switch, 10g to the HA server. They are running encrypted API so I’m not sure I can reasonably sniff the traffic to see if the actual earliest arrival is the one chosen (I guess I could un-encrypt it and try).

Am I missing something that might be leading to the “wrong” one being selected?

I can try to increase the gain on the remote VPE’s so they actually hear the command as well (running local OpenAI STT and it has a gain) but that’s not really what I want – I really want the one meter away one to win, not the 10m away one.

Could HA (is it HA?) actually be picking the wrong winner for some reason, something I may not have configured well?

Linwood

I guess this must not be a common problem, but in case others find it, I found a substantial contributor to it.

The developers for reasons a bit unclear decided to turn power saving to light, despite the VPE’s not being battery powered.

Turns out that may make a big difference, at least doing ping testing it definitely does. I realize ping is not the same as the TCP streams for API, but it is a lot easier to test and the numbers are so different it seems likely to have an impact. In brief testing I haven’t reproduced the problem. I doubt this is a complete solution, but it sure does treat a possible cause.

Incidentally, I did some packet traces and arrival time on HA was definitely the issue – HA is picking the “right” one in terms of which arrives first, it is actual packet arrival time that is coming out of distance order.

Incidentally, all these have great signals (-44-46db) both at the AP and at the VPE, airtime utilization on the AP’s are good (I have 5 around the house), client population is small. It’s not a perfect, delay free environment, not saying it is – but look at how much difference power saving made.

I wonder if the developers had a reason for power saving = light?

All times in this chart are Milliseconds, timestamps captured from the ping command in HAOS.