Hmm, maybe. I wonder if there might be better solutions for this problem, such as syslog on Linux systems. Not sure how syslog would work on an embedded device though, might be worthy of some research…does anyone know a good way to accomplish this? I’ll add a “log service” to the list of services in the notes I am keeping. Of course, a “log service” doesn’t necessarily have to be implemented using MQTT.
I assume you are asking how an end user would “install” services onto target devices? Not necessarily what the service “package” would look like (Docker, dpkg, dmg, etc)? Would this possibly be part of the administrative service and web interface or maybe an installation service? The end user might then specify a device (and type), select an appropriate service package for that device type, install it, and finally configure it? Hmm.
I’m thinking that talking about a “local” MQTT broker is really an implementation detail of how a logical collection of related services that might reside on a single device (or highly coupled devices) might choose to interact over a private API and not really in the scope of the overall architecture. It seems like these services still need to conform to the public API of each service, regardless of their implementation details. Talking about a “local” MQTT broker might be confusing the issue.
I’m also not sure I completely understand the details yet of when and how audio frames need to be visible between services. It does seem like an embedded device implementation of wakeup and audio recording for consumption by another service such as STT might not need to “share” audio frames prior to the publication of audio that is suitable for STT? Is event publication sufficient over a public API (via MQTT topic)? Does wakeup need to publish audio frames via an API at all? What is the use case for that? Is it possible that we can avoid “publishing” audio frames via MQTT by (e.g.) having the audio producer service simply publish a (stream) URL to an MQTT topic where it is then the responsibility of any client interested in that audio to connect to the URL and consume the audio stream? Optimizing an implementation (e.g. on a single device) might then just be sharing audio frames over a private, on-device mechanism without the need to push the audio out globally via MQTT. The service could still offer other clients an audio stream URL, but that doesn’t mean it has to be used if all the services that might require that audio stream are co-resident on a device. This still allows for flexibility if some future client was for some reason interested in that audio.
Why would we need to do this? Seems to me there is one global MQTT broker that serves as the communication fabric between services. If an implementation of a set of logically related services could be optimized for deployment on a single device (or even on a set of tightly coupled devices) with an internal MQTT broker, then so be it. I’m thinking that using an internal MQTT broker for this purpose is probably overkill, and that there are better ways of doing this.
Isn’t this simply publishing state changes to a retained MQTT topic? When a client subscribes to this state topic, it receives the current state and is subsequently informed of state changes via the topic subscription.
Would a rpi zero really be the target for all Rhasspy services? Wouldn’t one just install a small set of appropriate services on a pi zero and delegate other services to more capable hosts in the network? Why does a “device” need to know who the master is? I’m not sure I understand the use case for this, or why there needs to be any master. In my mind, there is just a set of services, each of which may be interested in “events” published by other services (e.g. on MQTT topics). Is there a need for a “workflow” manager that orchestrates the process, or can this be done in a more de-centralized manner where individual services take action when a triggering event occurs in the system (as published in various MQTT topics). It seems like it would be highly advantageous to avoid a “master” and/or a “orchestration” service. I think that would be hard to maintain and would unnecessarily constrain the flexibility of the system. But, I may certainly be missing something important here. I’m thinking this is mostly concerned with how STT audio input is constructed via wakeup and VAD and the desire to avoid unnecessarily publishing audio frames?
This is not to say that there isn’t some configuration “plumbing” that needs to occur such that individual services are aware of other services. For example, a STT service probably needs to know about the ID of each audio service such that the STT service can subscribe to MQTT topics of interest that the audio services publish audio available events to.
Gosh, sorry about how my posts seem to end up being so long winded. There just seems to be a lot of stuff to discuss. This is a good discussion!