Whenever I have a small number of Reactrons that are meant to work together as essentially a single unit, I call the arrangement a subcomplex.  It is a complex, in that it consists of more than one internal Reactron.  But it is "sub" in the sense that these internal units exist below a unified Reactron interface for the complex, so from the outside, it may appear as a single unit.

As an example, if you consider the Reactron coffemaker, water pump, and coffee-contextualized simple button, those are actually three separate Reactrons.  But, because these Reactrons are a special case scenario, where the button has a one-to-one relationship with the water pump, and the pump has a one-to-one relationship with the coffeemaker reservoir, they could have been structured as a single, three-unit subcomplex, with a single network interface, instead of three.  I didn't do it this way because these units were all conceived and added at completely different points in time.  Additionally, I like keeping the button and pump abstracted, because if I ever need a general purpose button elsewhere, or a pump, these designs can be replicated easily without de-coupling a coffeemaker.  That is one of the basic tenets of Reactron Overdrive - keep units simple and abstracted, and create desired complexity with increased numbers.

In developing the speech-interacting Integron, I have done a lot of testing and analysis, and suspect that the base unit is perhaps too complex.  It may be truer to the principles to abstract the speech processing from the human interaction, where the Linux module is a sub-Reactron module in its own right, and the sight, gesture, and audio components comprise a separate sub-Reactron.

I had been working on an "Integron relay" where a subset of the human interaction components were present, but offloaded the heavy processing to a separate unit.  My thought was to create a device that could act as a (door) threshold device, like a doorbell intercom, but fully integrated with the whole network.  If a doorbell, this would be externally mounted, and therefore subject to weather, damage, potential theft, etc.  So it would be beneficial to have it be cheap and replaceable, with nothing critical in it at all.  It would just be a dumb terminal, effectively.

After a lot of development on the Integron unit, I am thinking this should actually become the standard model.  All Integrons should be a sub-complex, with an Integron relay of whatever form (doorbell, automobile, desktop, wall-mounted, ceiling mounted, wrist-mounted) presented to the human, and all the data processing for speech and most Reactron network functions located on a separate unit. The two sub-units could be physically located together, but need not be.  This will allow the use of much higher performance computers to be utilized for speech processing, and will also create better machine utilization efficiency, since we generally do not need as many speech engines as we do interface points. The separation will allow a few-to-many relationship of engines to human interfaces.  

It also allows a completely different handling of the audio, escaping ALSA and allowing Linux to just handle received waveform data without trying to play it or capture it.  The real question is, will the transport of data to and from the relay units be faster than the capture, processing, and playout all on a local Linux SBC?  I don't know yet, but I am going to test it.

In the case of the Automobile Integron, I think the hardware will be pretty much the same, but wired and coded differently.  I will still use a BBB for the speech processor, but now the microcontroller will handle the audio capture and playout instead of ALSA. That subcomplex will be entirely local to the car, as GPRS would not be efficient enough data transport, performance-wise, and further, loss of signal would end up disabling the interface.  Also, BBB consumes much less power than a more powerful laptop, which is important as the unit needs to be aware and respectful of remaining battery power when the car is not running.  So that seems like it may be the right set of compromises there.

As this has gotten more complex, I will introduce a new project for the Integron itself, and keep my updates here about the Reactron architecture and network, as well as overall status and introductory remarks for new Reactron projects as they come about.  I have more in the pipeline, coming up later on.