Alle Beiträge

Home Assistant Business: Kann man auf Open Source ein Geschäft bauen?

Kein Hersteller im Rücken, ständig beim Kunden, Updates die alles zerschießen — die drei großen Ängste vor einem Home-Assistant-Business. Warum WordPress dieselben Ängste hatte und trotzdem eine ganze Dienstleisterbranche hervorbrachte.

Die Frage hinter der Frage

„Kann man davon eigentlich leben?” Die Frage taucht in den Foren immer wieder auf, manchmal direkt, öfter verkleidet. Jemand schreibt, er habe Home Assistant seit Jahren im Haus, Freunde fragten ihn dauernd, ob er das nicht auch bei ihnen einrichten könne — und dann der Satz, der das eigentliche Zögern verrät: „Aber kann man auf so etwas ein richtiges Geschäft aufbauen? Ist ja Open Source, da steht ja keiner dahinter.”

Ich finde diese Frage ehrlich, und ich verstehe sie. Wer sein Einkommen auf etwas stellt, will wissen, worauf er sich verlässt. Bei einem Closed-System mit Hersteller, Hotline und Vertrag ist das auf den ersten Blick klarer. Bei Home Assistant scheint da erst mal — niemand zu sein.

Nur stimmt dieser erste Blick nicht. Und der Beweis dafür ist über fünfzehn Jahre alt, läuft auf rund vierzig Prozent aller Websites im Netz und heißt WordPress.

Drei Ängste, die alle dasselbe Muster haben

Wenn ich mit Leuten rede, die mit dem Gedanken spielen, professionell HA-Installationen zu betreuen, kommen fast immer dieselben drei Bedenken. Nicht als Ausreden — als echte, berechtigte Sorgen.

Die erste: Es steht kein Hersteller dahinter. Wer haftet, wenn etwas kaputtgeht? Auf wen zeige ich, wenn der Kunde fragt, warum sein Türschloss seit dem Update nicht mehr reagiert? Bei Loxone oder Control4 gibt es einen Vendor, eine Zertifizierung, eine Eskalationskette. Bei Open Source gibt es ein GitHub-Issue und im Zweifel ein Schulterzucken.

Die zweite: Ich muss ständig vor Ort sein. Die Vorstellung, dass jede Störung eine Anfahrt bedeutet, weil man nicht aus der Ferne eingreifen kann, ist für ein Geschäftsmodell ruinös. Wer pro Vorfall vierzig Minuten im Auto sitzt, kann keine zwanzig Kunden betreuen. Höchstens fünf, und auch die nur, wenn nicht alle gleichzeitig Probleme machen.

Die dritte: Das Ding ist instabil. Updates schießen Konfigurationen ab, ein Plugin bricht nach einem HACS-Update, eine Breaking Change in der Core macht über Nacht eine Automation tot. Home Assistant gilt vielen immer noch als Bastelplattform — und auf Bastelei baut man kein Gewerbe.

Drei Ängste, ein gemeinsamer Nenner: das Gefühl, sich auf etwas zu stützen, das jederzeit unter einem wegbrechen kann, ohne dass jemand auffängt. Genau dieses Gefühl gab es schon einmal. In einem anderen Ökosystem, mit verblüffend ähnlicher Geschichte.

WordPress hatte exakt diesen Ruf

Spul zurück, sagen wir, ins Jahr 2010. WordPress war Open Source, kostenlos, von einer Community getragen. Und es hatte genau den Ruf, den Home Assistant heute hat. „Updates zerschießen die Seite.” „Plugins sind ein Sicherheitsalbtraum.” „Kein offizieller Support, du bist auf dich allein gestellt.” „Für ein ernsthaftes Business nimmst du was Richtiges, kein Bastelding aus dem Netz.”

Wer damals einem Mittelständler vorschlug, seine Firmenseite auf WordPress zu bauen, musste sich rechtfertigen. Heute ist es umgekehrt — wer es nicht vorschlägt, muss erklären, warum.

Was ist passiert? Nicht, dass WordPress über Nacht stabil wurde und ein Konzern die Haftung übernahm. Passiert ist etwas anderes: Es entstand eine ganze Branche von Menschen, die WordPress professionell betreiben. Agenturen, Freelancer, Ein-Personen-Buden, die nicht eine Seite bauen und sich verabschieden, sondern dauerhaft pflegen. Updates einspielen, Backups fahren, im Störfall reagieren — gegen Geld, monatlich, planbar. Die berühmten Wartungs- und Care-Pläne, die heute das Rückgrat unzähliger Agenturen sind. Wiederkehrender Umsatz aus einer Software, für die niemand eine Lizenzgebühr zahlt.

Das ist der Punkt, an dem ich angehende HA-Integratoren gerne festnagle. Der fehlende Hersteller ist kein Loch. Er ist die Geschäftsgrundlage. Genau weil keine Hotline existiert, braucht der Kunde jemanden, der diese Rolle ausfüllt — und das bist du. „Kein Vendor im Rücken” heißt aus Sicht des Kunden: „Ich brauche einen Menschen, dem ich vertraue.” Das ist kein Defizit. Das ist Nachfrage.

Der Teil, den die meisten übersehen: das Werkzeug

Aber — und das ist mir wichtig, weil hier oft zu schnell „dann mach doch einfach” gesagt wird — die WordPress-Branche ist nicht allein durch guten Willen entstanden. Sie wurde möglich, weil irgendwann die Werkzeuge da waren, um den Wahnsinn zu bändigen.

Stell dir einen Dienstleister mit achtzig WordPress-Kundenseiten vor. Achtzig Logins. Achtzig Plugin-Listen. Achtzig Backup-Routinen, achtzig Update-Stände. Wer sich da jeden Morgen einzeln in jede Seite einloggt, um zu schauen, ob die Nacht etwas kaputtgemacht hat, gibt nach zwei Wochen auf. Das skaliert nicht. Das ist die Vor-Ort-Angst der WordPress-Welt, nur eben digital.

Gelöst hat das eine Klasse von Programmen, die man Management-Dashboards nennt. Das bekannteste freie Beispiel ist MainWP — selbst gehostet, Open Source, gebaut für genau diesen Schmerz. Du installierst eine kleine Erweiterung auf jeder Kundenseite, und ab dann siehst du alles aus einem einzigen Dashboard: welche Seite ein Update braucht, wo ein Plugin veraltet ist, welche gerade offline ist, wann das letzte Backup lief. Updates für Core, Plugins und Themes über alle Seiten auf einmal. Uptime-Monitoring. Security-Checks. Reports, die du dem Kunden schickst, damit er sieht, wofür er zahlt.

Statt sich in achtzig Seiten einzuloggen, schaut der Dienstleister einmal auf ein Board und sieht, wo Handlungsbedarf ist. Was Fernzugriff braucht, erledigt er aus der Ferne. Die Anfahrt — das große Schreckgespenst — schrumpft auf die wenigen Fälle, in denen wirklich jemand mit der Hand ran muss.

Genau dieses Werkzeug fehlte für Home Assistant lange. Und solange es fehlt, bleibt die Vor-Ort-Angst berechtigt.

HA Fleet Manager ist das MainWP-Moment für Home Assistant

Hier kommt das Produkt ins Spiel, hinter dem dieser Blog steht — und ich sage bewusst dazu, was es ist und was nicht, weil mir Werbesprech bei diesem Thema selbst auf die Nerven geht.

HA Fleet Manager ist für Home Assistant gedacht, was MainWP für WordPress ist. Ein zentrales Dashboard für viele Instanzen. Du installierst eine Custom Integration auf jeder Kundeninstallation, und danach siehst du den Zustand des ganzen Portfolios auf einen Blick: welche Instanz online ist, welche Integrationen laufen, welche HACS-Plugins in welcher Version installiert sind, ob kritische Fehler in den Logs stehen. Fernzugriff auf die HA-Oberfläche, wenn du eingreifen musst — aber erst, nachdem der Kunde es freigegeben hat, und nur für ein befristetes Fenster. Eine Wartungshistorie, die nicht aus deinem Gedächtnis besteht.

Die Parallele trägt bis ins Detail. Die Vor-Ort-Angst löst sich in der HA-Welt aus demselben Grund auf wie damals in der WordPress-Welt: weil du nicht mehr zu jeder Installation hinfahren oder dich einzeln einloggen musst, um zu wissen, wie es ihr geht. Du siehst es. Und wenn etwas ist, greifst du remote ein. Wie das im Alltag aussieht, habe ich an anderer Stelle als kleine Geschichte durchgespielt — die Z2M-Kaskade an einem Donnerstagnachmittag, drei Kunden, vierzig Minuten, keine Anfahrt.

Was HA Fleet Manager nicht ist: ein fertiges, jahrzehntelang ausgehärtetes Produkt mit dem Funktionsumfang etablierter RMM-Suiten. Es ist jung. Es entsteht gerade. Aber MainWP war 2013 auch jung, und WordPress 2010 erst recht. Ökosysteme reifen, wenn jemand anfängt, die Werkzeuge zu bauen, die die Profis brauchen.

Bleibt die dritte Angst: Stabilität

Über den fehlenden Hersteller und die Vor-Ort-Sorge haben wir geredet. Die dritte — „das System versagt, weil Updates Dinge kaputt machen” — verdient eine eigene, ehrliche Antwort. Denn anders als die beiden anderen lässt sie sich nicht mit „WordPress hat das auch geschafft” wegwischen.

Erstens: Ja, Updates brechen manchmal Dinge. Das ist wahr und bleibt wahr. Aber genau das ist der professionelle Hebel, kein Ausschlusskriterium. Der Unterschied zwischen einem Hobbyisten und einem Dienstleister ist nicht, dass beim Dienstleister nie etwas kaputtgeht. Er ist, dass der Dienstleister es als Erster merkt — bevor der Kunde anruft. Wer ein Update kontrolliert auf einer Pilot-Installation ausrollt, beobachtet, und erst dann auf die Flotte gibt, hat aus „etwas ging kaputt” eine geplante Operation gemacht. Genau dafür ist ein Flotten-Dashboard da: nicht um Fehler zu verhindern, sondern um sie früh und gesammelt zu sehen.

Zweitens: Der „bastelig”-Ruf hinkt der Realität hinterher. Home Assistant ist längst aus der Kellerecke heraus. Es gibt eine Foundation, einen festen Release-Zyklus, das Programm „Works with Home Assistant”, offizielle Hardware. Das ist kein Wochenend-Skript mehr, sondern eine Plattform mit Millionen Installationen. Wer heute noch „Bastelding” sagt, beschreibt den Zustand von vor fünf Jahren.

Und drittens, der Punkt, der mir am meisten am Herzen liegt: Stabilität ist bei Open Source keine Eigenschaft, die der Hersteller liefert. Sie ist eine Leistung, die der Dienstleister erbringt. Das klingt nach mehr Verantwortung — ist es auch. Aber es ist genau die Verantwortung, für die der Kunde bezahlt. Ein Wartungsvertrag verkauft nicht „die Software geht nie kaputt”. Er verkauft „wenn etwas ist, kümmert sich jemand, und meistens, bevor du es merkst”. Das kann ein Vendor mit Closed-System oft schlechter liefern als ein Mensch, der genau diese zwanzig Installationen kennt.

Was das für dich heißt, wenn du anfängst

Ich will hier nichts schönreden. Ein HA-Business aufzubauen ist Arbeit, und es ist kein garantierter Selbstläufer. Aber die Ausrede „geht nicht, ist ja nur Open Source” ist historisch widerlegt. Sie wurde in einem strukturell sehr ähnlichen Markt schon einmal widerlegt, gründlich, und von Leuten, die heute gut davon leben.

Was es braucht, ist dasselbe wie damals: die Bereitschaft, die Rolle des fehlenden Herstellers selbst auszufüllen — als Vertrauensperson, nicht als Bastler. Ein Geschäftsmodell mit wiederkehrendem Umsatz, damit du nicht von Notfall zu Notfall lebst. Und ein Werkzeug, das dich nicht zwingt, dich morgens in zwanzig Installationen einzeln einzuloggen. Wie dieser Beruf konkret aussieht, vom typischen Tag bis zu den Stundensätzen, habe ich im Berufsbild des HA-Integrators ausführlicher beschrieben. Und wenn du noch unentschlossen bist, welches Werkzeug für deine Größenordnung passt, hilft vielleicht der Vergleich der sechs Wege, mehrere HA-Instanzen zu verwalten.

Die WordPress-Leute hatten 2010 kein MainWP und keine Gewissheit, dass ihre Branche entstehen würde. Sie haben einfach angefangen. Heute fängst du an, und das Werkzeug existiert schon.

Das ist, ehrlich gesagt, ein ziemlich guter Zeitpunkt.


Disclosure: HA Fleet Manager ist das Produkt hinter diesem Blog. Die WordPress-Parallele ist trotzdem keine Verkaufsmasche — sie ist der Grund, warum ich glaube, dass dieser Markt funktioniert.

DO
Denny Ovčar
Founder · ha-fleet-manager.com
Antworten
Teilen