I lost another Mini last night, spontaneously and without warning. This one just won't power up at all... Very odd, and at this rate, I won't have anything left to run I7 by the time it is released!!
More to your input about having a 'single point of failure' regarding the PLM I've been thinking along those exact same lines. I've decided that a good way to see what happens is to turn off the Mac Mini and then live 2 or 3 days without the mini booted up.... Put the home into "Survival Mode." I want to see how handicapped my house becomes with only insteon and z-wave devices installed with nothing but a few links between them to keep things going.
I believe the home should be able to run without a Mac Mini if worst comes to worse... I just want to see what, if any of Indigo's oversight functions, I simply can't live without... because for some of it, maybe there's an easy fix. Taking the Mac Mini Indigo Automation Server off line for a few days might reveal a few other surprises that need attention.
We run a lot of schedules and triggers (good thing considering my abysmal graphics and control page skills) so our home is quite crippled without automation. The Indigo server is (was) also the main repository for roughly 35,000 audio tracks for Sonos and Plex-delivered movies & other recordings. It is (was) also the local repository for about 30 years of family photos, although those are backed up in multiple locations.
My current thinking is along the line of dual automation servers, in a hot/cold configuration such that the cold one is offline until some watchdog mechanism determines that the primary server is unavailable an not recoverable by reboot. At that point, the watchdog would start Indigo on the secondary server. for syncing between the two, I'm thinking of some type of shared storage over the network, either AFP/CIFS or block storage through iSCSI. I may even replicate the storage server using gluster or something similar, or I might just have a central repository that hold the latest copy of the indigo DB and external scripts/plugins and such that is copied to/from the central storage system on Indigo startup/shutdown with some scripts.
I'm also thinking more about the architecture of the system as a whole, perhaps moving command/control away from Indigo and to the "hub" devices responsible for each part of the automation. As and example, since I use Insteon for lighting that would mean something like an ISY for Insteon control, Home sensor information would be handled by the DSC alarm system, perhaps move HVAC to Nests, etc. That ensures that the failure of a single component or system does not impact automation as a whole. Along those same lines, I would most likely move the touchscreen functionality to another external system as well, whether it be standalone HTML, or an app such as Imperihome, Command Fusion, Roomie, SimpleHome, etc. The main reason we don't use Indigo Control Pages now is that I need more controls for A/V, a separate interface system would more readily allow for that.
In this scenario, Indigo is more of an "Orchestration Engine" and "Complex Event Processor", still serving as the "brain", but having a distributed (rather than central) nervous system. This will place more of a reliance on communication such JSON, MQTT, etc. to make systems communicate with each other. Indigo will need plugins (a revival of the defunct ISY plugin, usage of the existing MQTT plugin, etc.), but it will only concern itself with properly sequencing events and actions. The touchscreen system, Alexa, Siri, etc. would speak directly to the sub-system to be controlled. "Alexa, play Christmas music in the kitchen", will speak directly to the kitchen Sonos and not depend on the Orchestration Engine (Indigo) for mediation. Indigo might have a rule to dim the Kitchen lights when Christmas music is played, listening to events that fire and responding to the appropriate subsystem accordingly. Likewise, if we wish to override the dimming rule and have the lights at full bright - a light switch press, or a touchscreen action will interface directly with the lighting system, while updating Indigo appropriately of current state.
This approach isn't set in stone, and there are many variables and what-ifs to consider. It's definitely a big-corporate-IT-shop design tact (but hey, that's my field), and it may not directly translate to home automation, but after two hardware failures in less than a month, I definitely see benefits to a redundant, distributed approach.
Terry