Da gibt es ja immer verschiedene Faktoren
Erstmal: openHABian. Das ist eine Scriptsammlung, mehr nicht. Ja, es gibt ein Image für den Raspberry, aber da handelt es sich auch nur um ein Standard Raspberry Pi OS lite Image mit vorinstallierten openHABian Scripten.
openHABian hat bestimmte Vorstellungen, wie etwas umgesetzt wird, angefangen vom Systemnamen über die Freigaben bis hin zur den Usern. Grundsätzlich ist es aber kein Problem, auch andere Software "nebenher" laufen zu lassen. Wenn Software im Zusammenhang mit den Scripten Ärger macht, dann hat das in den meisten Fällen mit Ports und Rechten zu tun. Gewöhnlich gibt es die gleichen Probleme dann auch ohne openHABian, weil die Probleme eigentlich eher mit openHAB zu tun haben.
openHABian bringt einige sehr nützliche Tools mit, die man sonst recht mühsam von Hand einrichten muss, z.B. frontail und motd, um nur zwei zu nennen.
openhabian-config schraubt gerne mal an Dateien rum, die eventuell auch von anderen Programmen geändert werden (ganz vorn mit dabei die smb.conf). Da ist es dann halt so, dass man eine gewisse Reihenfolge einhält. Also man beginnt mit der Grundeinstellung über openhabian-config. Später Software dazu installieren ist kein Thema, genauso openHAB-Optionen ändern. Aber eben nicht mehr mit openhabian-config an Samba rumschrauben.
Danach packt man dann die zusätzliche Software drauf. Wenn man Samba nutzt, muss man natürlich auch darauf achten, dass andere Software die Konfiguration nicht zerschießt.
openHABian ist also keine schlechte Option, auch mit anderer Software, wenn man einigermaßen aufpasst, was man tut. Man muss nur im Hinterkopf behalten, dass openHABian immer davon ausgeht, ein jungfäuliches System exklusiv zu nutzen und entsprechend openhabian-config eher früher als später einsetzen.
Wie sehen die Eckdaten des Systems aus? Wieviel RAM, wieviele Kerne, welcher Prozessor? Was soll alles parallel zu openHAB installiert werden?
Abhängig von diesen Parametern kann man grob drei Wege beschreiten, das wären:
- Alles auf einem System
- virtualisiert mit Containern
- virtualisiert mit Hypervisor
Alles auf einem System: braucht weniger RAM und Prozessorleistung. Dafür können sich die Programme aber recht gut in die Quere kommen. Ein Prozess kann den ganzen Rest mit in den Abgrund reißen.
Virtualisiert: braucht mehr Ressourcen. Dafür ist die Software aber besser voneinander abgeschottet.
Container: sind sparsamer. Es werden Teile der Infrastruktur des Host Systems direkt verwendet. Die Anwendungen werden aber weitgehend voneinander abgeschirmt. Solange eine Software nicht böswillig versucht, auszubrechen, sind die Prozesse virtuell voneinander getrennt.
Docker als derzeit wohl bekannteste Container Plattform ermöglicht es, mit wenigen Befehlen zusätzliche Container zu starten. So kann man NAS, PiHole, MediaNetz, openHAB, Datenbanken und so weiter recht schlank laufen lassen, wenn ein Dienst mal ausfällt, reicht es, den betreffenden Container zu treten und es läuft wieder.
"Echter" Hypervisor: damit wird es möglich, die virtuellen Maschinen vollkommen voneinander zu trennen. Es sollte damit extrem schwer werden, andere Programme im Ablauf zu stören (aber auch aus VMs kann man ausbrechen...) Die Betriebssysteme müssen nichts mehr miteinander zu tun haben. Ich habe z.B. auf meinem Proxmox neben openHAB und diversen anderen LXC-Containern auch eine freePBX laufen (das ist FreeBSD - kein Linux) und ein paar Windows VM liegen da auch noch rum - z.B. für die Steuer und die Administration meines knx Systems (die ETS gibt es nur als Windows Software)
Nachteil eines vollwertigen Hypervisors sind die Anforderungen an die Hardware, ein 64-Bit Prozessor ist zwingend, um alle Funktionen nutzen zu können braucht es Features wie VT-d und VMMU (und noch diverse andere Kürzel...) Aktuelle Systeme bringen meist alles Nötige mit, aber das ist nicht 100% sicher.
Ein Nachteil der Virtualisierung sollte nicht verschwiegen werden: In dem Moment, wo Du mit openHAB direkt Hardware ansprechen willst, musst Du etwas Aufwand treiben. Was zu tun ist, hängt dann stark von der Hardware und der Art der Virtualisierung ab.
Dafür bringt die Virtualisierung aber auch einen großen Vorteil (egal, wie man virtualisiert), man kann sehr einfach Backups erstellen. Im Fall von Proxmox kann man gar automatisch Snapshots erstellen, die VM oder der Container können dann binnen weniger Sekunden auf einen beliebigen Zeitpunkt zurückgerollt werden. Gerade bei größeren Software Updates kann so etwas hilfreich sein. Mit einem zweiten System (das muss nicht unbedingt ein Proxmox sein) kann man sogar automatisch diese Backups und Snapshots kopieren, so dass man nicht nur eine lokale, sondern auch eine entfernte Kopie der Daten hat. Hat man die Möglichkeit, den passenden Server außer Haus zu parken, geht das auch übers Internet (eine normale DSL-Anbindung mal vorausgesetzt). Damit wären Daten potenziell sogar bei einem Brand sicher.
Als Betriebssystem bevorzuge ich ganz klar debian, aber das ist auch ein Stück weit Geschmackssache.
debian ist traditionell gut abgehangen, man bekommt also nicht die neuesten Features (es sei denn, man geht auch auf unstable oder zumindest testing), dafür sollte eine Software aber auch ohne große Probleme funktionieren. Updates und Upgrades sind unter debian kein Thema (abgesehen von den grundsätzlichen Dingen, die uneingeschränkt für alle Systeme gelten, nämlich a) Backups anzufertigen und b) mal vorher zu schauen, ob es irgendwelche breaking changes gibt. debian weist aber während des Upgrade Prozesses eigentlich immer auf mögliche Probleme hin.
Ubuntu setzt auf debian auf bzw. nutzt einen großen Teil der debian Pakete. Es gibt verschiedene Anwendungen und auch Teile des Betriebssystems, welche neuer sind, das ist aber nicht immer ein Vorteil
Einen Desktop braucht es zur Verwaltung eines Servers nicht. Entsprechend sollte man immer die desktoplose Variante installieren (bei debian den Desktop nicht installieren, bei Ubuntu die Server-Variante wählen).
)
Daher klingt dies im Moment am naheliegensten.