Fallback for online services

[denics]

Dear all,
what you are doing is amazing. I have been thinking of the cases when you hit a fallback for STT and TTS services and I think it could be an improvement to change the way fallbacks are declared. At the moment we have:

module: "",
fallback-module: ""

this case is working fine, but it is limiting because, for example, it forces the user to choose to run the fallback as local or remote service when the case to hit a fallback can be multiple.

For example, I finish my tokens in my remote service TTS , so my main service fail and I hit the fallback that could be, for example, another account with the same service or another online service. However, I could also be in the situation where I have a very limited or no connection and thus my fallback should be an offline service.

A possible solution can be to define the services differently like an ordered list:

module: [
  - online_service1,
  - online_service2,
  - offline_service
]

With this configuration, if I do not have internet, the modules keep failing until starting the offline service.

just an idea.

[NeonDaniel]

I'm thinking we might want to assign offline stt/TTS separately since we already track connection states now. So, instead of trying online and falling back, we directly call offline options when offline.

I guess we already have tagging for online requirements, so maybe we could implement config as you suggest and then add some logic in core to skip ones that don't have sufficient networking available?

[JarbasAl]

I'm thinking we might want to assign offline stt/TTS separately since we already track connection states now. So, instead of trying online and falling back, we directly call offline options when offline.

I guess we already have tagging for online requirements, so maybe we could implement config as you suggest and then add some logic in core to skip ones that don't have sufficient networking available?

as discussed in chat this is not optimal, this came up because default vosk stt fallback consumed too much memory for a pi3A+

this would move the problem to a later stage, once connecting was lost core would load vosk and run out of memory then

i prefer the approach of a list of engines, it is more expandable. at same time i agree all plugins should honor network requirements and started implementing this in PHAL already, will give it some thinking for wakeword/tts/stt equivalents

[NeonDaniel]

as discussed in chat this is not optimal, this came up because default vosk stt fallback consumed too much memory for a pi3A+

If anything, wouldn't this help the issue by not loading the online STT engine while offline?

this would move the problem to a later stage, once connecting was lost core would load vosk and run out of memory then

This is a config problem IMO; a device shouldn't configure an incompatible STT engine