Again, I think especially in Homeautomation, there’s a bunch of more or less bulletproof, stable and reliable hardware actuators not hardware server. You should aim to use these stable actuators and it would be less costly (in terms of money and time spent) to use these appliances instead of routines, logic and stuff within openHAB.
So, in terms of High Availabilty and reducing possible Points of Failure:
- get robust, stable hardware actuators
- use their interfaces to connect stable hardware to openHAB
- use openHAB to let’s say orchestrate or bridge inter-hardware use cases
- don’t use openHAB as a central and single point of functionality/logic
Just to get an example:
- don’t connect valves to openHAB to regulate your central heating
- instead: use a robust (local! not cloud-dependend!) heating solution
- and use the interface of your heating solution to read the environment variables for your heating to trigger some sort of actions in openHAB for “luxury” purposes
- you avoid failures along the way, beginning from an misconfigured openHAB to a failing SD card to a broken IP-connection, …
- if your openHAB dies, you still have a warm house, even if you can’t see temperatures or your openHAB tells you to close the windows in the room upstairs…
Don’t fall for the fallacy, openHAB has to organise everything, know everything, works as a central intelligence. It’s not designed for that. It’s a central logic, which extends already in place appliances and their logics.