Illustration zum Smart Home ohne Hersteller-APP

Smart Home ohne Hersteller-App

von

oder, warum braucht meine Steckdose einen Account?

Schnellnavigation

Smart Home ohne Hersteller-App: Wunsch oder Wirklichkeit?

Ein Smart Home klingt auf dem Papier immer herrlich einfach: Gerät kaufen, einrichten, automatisieren, fertig. In der Praxis sieht es oft anders aus. Plötzlich braucht die Steckdose einen Account, der Luftreiniger möchte Standortfreigabe, die Kamera will in eine Cloud, und das Heizungs-Gateway besteht darauf, dass man erst einmal die passende Hersteller-App installiert.

Dabei ist der Wunsch nach einem Smart Home ohne Hersteller-App gar nicht besonders exotisch. Viele Nutzer wollen ihre Geräte nicht zwingend ohne App nutzen, sondern ohne App-Zwang betreiben. Das ist ein wichtiger Unterschied.

Eine App zur Einrichtung, Diagnose oder komfortablen Bedienung kann sinnvoll sein. Problematisch wird es dann, wenn ein Gerät technisch lokal funktionieren könnte, aber künstlich an einen Account, eine Cloud oder eine geschlossene Herstellerwelt gebunden wird.

Oder kürzer gesagt: Warum braucht meine Steckdose einen Account?

Zigbee, Z-Wave und Matter zeigen, dass lokal funktionieren kann

Bei vielen klassischen Smart-Home-Geräten sieht man sehr gut, dass lokale Steuerung kein Hexenwerk ist. Zigbee, Z-Wave und ähnliche Funkstandards sind dafür gute Beispiele.

Eine Zigbee-Steckdose, ein Bewegungsmelder oder ein Türkontakt muss nicht zwingend mit irgendeinem Server auf der anderen Seite des Planeten reden. Das Gerät kommuniziert lokal mit einem Koordinator oder Gateway. Von dort aus kann es in Systeme wie Home Assistant, ioBroker oder andere Smart-Home-Zentralen eingebunden werden.

Das ist einer der Gründe, warum Zigbee und Z-Wave im Smart-Home-Bereich so beliebt sind:

  • viele Geräte laufen lokal,
  • die Reaktionszeiten sind kurz,
  • Automationen funktionieren auch ohne Internet,
  • Geräte verschiedener Hersteller lassen sich oft kombinieren,
  • man ist nicht vollständig von einer einzelnen App abhängig.

Natürlich ist auch hier nicht alles perfekt. Geräteprofile, herstellerspezifische Eigenheiten und Firmware-Unterschiede können nerven. Aber das Grundprinzip ist gesund: Das Gerät gehört ins lokale Netz beziehungsweise ins lokale Smart-Home-System. Nicht zuerst in eine Cloud.

Und genau deshalb wird es so absurd, wenn ausgerechnet einfachere Geräte plötzlich mehr Online-Zwang haben als ein halbes Industrieprotokoll.

Shelly als positives Gegenbeispiel: Es geht auch anders

Bevor es nur ums Meckern klingt: Es gibt durchaus Hersteller, die zeigen, dass es besser geht. Shelly ist dafür ein sehr gutes Beispiel.

Viele Shelly-Geräte lassen sich nicht nur per App einrichten, sondern direkt über die Web-Oberfläche des Geräts konfigurieren. Man ruft die IP-Adresse im Browser auf und kann dort praktisch alle Einstellungen vornehmen: WLAN, Relaisverhalten, Eingänge, Timer, Skripte, MQTT, Webhooks, lokale Aktionen und je nach Gerät weitere Funktionen.

Das klingt banal, ist aber im Smart-Home-Alltag ein großer Unterschied. Denn damit gehört das Gerät nicht nur formal dir, sondern fühlt sich auch so an. Du bist nicht darauf angewiesen, dass eine App gerade funktioniert, ein Cloud-Dienst erreichbar ist oder ein Hersteller meint, eine Funktion hinter einem neuen Menü verstecken zu müssen.

Besonders angenehm ist: Shelly zwingt dich nicht in genau einen Bedienweg. Wer die App nutzen möchte, kann das tun. Wer lokal arbeiten will, bekommt dafür brauchbare Möglichkeiten. Wer tiefer einsteigen möchte, kann mit Skripten, HTTP-RPC, MQTT oder direkter Gerätekommunikation arbeiten.

Genau so sollte es sein:

  • App für Komfort,
  • Web-UI für direkte lokale Konfiguration,
  • lokale Schnittstellen für Automationen,
  • Cloud optional statt zwingend.

Shelly ist damit nicht automatisch perfekt. Auch dort gibt es Firmwarestände, Modellunterschiede und gelegentliche Eigenheiten. Aber die Grundhaltung ist deutlich angenehmer: Das Gerät kann lokal benutzt, konfiguriert und automatisiert werden, ohne dass man sich komplett einem App-Kosmos ausliefert.

Gerade deshalb fällt bei anderen Herstellern umso stärker auf, wie unnötig streng manche Geräte an Apps und Accounts gebunden sind.

Wenn lokale Geräte trotzdem eine Hersteller-App brauchen

Je spezieller ein Gerät wird, desto häufiger landet man wieder bei einer Hersteller-App. Nicht unbedingt, weil es technisch zwingend nötig wäre, sondern weil der Hersteller die Bedienung, Einrichtung oder Integration kontrollieren möchte.

Das betrifft nicht nur billige WLAN-Steckdosen aus irgendeinem App-Baukasten. Es betrifft auch hochwertige Geräte aus Bereichen wie Heizung, Warmwasser, Kameraüberwachung, Energiemanagement oder Raumklima.

Gerade dort ist es besonders ärgerlich. Denn diese Geräte hängen oft ohnehin im eigenen Hausnetz, haben lokale Schnittstellen, kommunizieren intern mit Gateways oder könnten problemlos über dokumentierte APIs, MQTT, Modbus, RTSP, ONVIF oder andere etablierte Standards angebunden werden.

Stattdessen bekommt man häufig:

  • eine Hersteller-App,
  • einen Account,
  • Cloud-Kommunikation,
  • eingeschränkte lokale Schnittstellen,
  • und im schlimmsten Fall eine Funktion, die nur so lange existiert, wie der Hersteller den Dienst weiterbetreibt.

Das ist kein Smart Home. Das ist betreutes Wohnen für Elektronik.

Beispiele aus der Praxis: Heizung, Warmwasser, Kameras und Energiespeicher

Buderus Heizungs-Gateway

Ein Heizungs-Gateway wie das von Buderus ist ein gutes Beispiel für ein Gerät, das eigentlich perfekt in ein lokales Smart Home passen würde. Heizungsdaten sind für Automationen extrem spannend: Temperaturen, Betriebszustände, Warmwasser, Heizkreise, Fehlercodes und Verbrauchswerte.

Gerade solche Daten möchte man lokal auswerten können. Nicht nur, weil es bequem ist, sondern weil Heizung ein zentraler Teil der Haustechnik ist. Wenn das Internet ausfällt, sollte die grundlegende Kontrolle und Auswertung im eigenen Haus nicht plötzlich blind werden.

Eine App kann hier trotzdem sinnvoll sein. Sie kann die Einrichtung vereinfachen, Statusmeldungen anzeigen, Firmware-Updates anbieten oder weniger technikaffinen Nutzern eine verständliche Oberfläche geben. Das Problem entsteht erst dann, wenn diese App zur einzigen offiziell vorgesehenen Steuerzentrale wird und man ohne diese das Gateway gar nicht einrichten kann.

Bosch Durchlauferhitzer

Auch ein smarter Durchlauferhitzer von Bosch (bezahlter Link) zeigt sehr gut, wie absurd die Grenze zwischen lokalem Gerät und App-Zwang werden kann. Ein Durchlauferhitzer hängt im Haus, erfüllt eine klar lokale Aufgabe und muss nicht grundsätzlich mit einer Cloud reden, nur damit man Temperaturen, Betriebsarten oder Verbrauchsdaten komfortabel nutzen kann.

Für den Alltag kann eine App trotzdem praktisch sein. Man kann Einstellungen ändern, Verbrauchswerte ansehen oder Komfortfunktionen nutzen. Aber warum nicht zusätzlich eine lokale Schnittstelle anbieten? Warum nicht Modbus, MQTT, eine lokale HTTP-API oder zumindest eine saubere Integration für gängige Smart-Home-Systeme?

Gerade bei Energie- und Verbrauchsdaten wäre lokale Verfügbarkeit ein echter Mehrwert. Nicht nur für Nerds, sondern auch für alle, die Stromkosten, Lastspitzen oder Warmwasserverhalten besser verstehen wollen.

Reolink Kameras

Bei Kameras wird es besonders interessant, weil Reolink (bezahlter Link) im Vergleich zu vielen Cloud-Kamera-Systemen durchaus viele lokale Möglichkeiten bietet. RTSP, ONVIF, NVR-Anbindung (bezahlter Link) und lokale Aufzeichnung sind hier je nach Modell und Konfiguration ein großer Vorteil.

Trotzdem spielt auch hier die Hersteller-App eine wichtige Rolle. Sie ist bequem, zeigt Push-Benachrichtigungen, erleichtert die Einrichtung und macht den Fernzugriff simpel. Für viele Nutzer ist genau das der Grund, warum sie solche Systeme überhaupt verwenden.

Die App ist also nicht das Problem. Das Problem wäre, wenn lokale Standards eingeschränkt, versteckt oder künstlich schlechter gemacht würden, nur damit man möglichst in der App bleibt.

Bei Kameras gilt besonders: Wer seine Aufnahmen lokal speichern und lokal auswerten möchte, sollte diese Möglichkeit behalten. Eine Kamera ist kein Wetter-Widget. Sie filmt private Bereiche, Einfahrten, Haustüren oder Gärten. Da ist lokale Kontrolle kein Luxus, sondern ein ziemlich naheliegender Wunsch.

Anker SOLIX

Bei Energiespeichern und Balkonkraftwerk-Systemen wie Anker SOLIX (bezahlter Link) wird der Wunsch nach lokaler Integration schnell offensichtlich. Solche Systeme erzeugen, speichern und verteilen Energie im eigenen Haushalt. Die Daten sind für Automationen hochinteressant: Ladezustand, Erzeugung, Einspeisung, Verbrauch, Zeitpläne und Betriebsmodi.

Lange wirkte genau dieser Bereich wie ein typisches Beispiel für App- und Cloud-Abhängigkeit: schöne Graphen in der Hersteller-App, aber nur eingeschränkte Möglichkeiten für lokale Smart-Home-Integration. Aus Sicht des Herstellers ist das teilweise nachvollziehbar. Die App ist Support-Werkzeug, Diagnoseoberfläche, Update-Zentrale und Kontrollzentrum in einem. Für den Nutzer bleibt das System dadurch aber schnell eine Blackbox.

Interessant ist allerdings, dass Anker hier anscheinend dazulernt. Mit der offiziellen Home-Assistant-Integration ha-anker-solix-official gibt es inzwischen ein deutlich positiveres Signal. Diese Integration stammt direkt von Anker beziehungsweise Anker Innovations und setzt nicht einfach auf einen inoffiziellen Cloud-Umweg, sondern auf lokale Kommunikation per Modbus TCP im heimischen Netzwerk.

Das ist genau die Richtung, die man sich bei solchen Geräten wünscht: Die Solarbank steht im eigenen Haus, arbeitet mit dem eigenen Strom, also sollten wichtige Daten und Steuerfunktionen auch lokal erreichbar sein. Laut Beschreibung der offiziellen Integration läuft die Kommunikation im LAN, ohne Cloud-Server, ohne API-Key und ohne Internetabhängigkeit. Unterstützt wird dabei unter anderem die Anker SOLIX Solarbank Max AC*, die damit wohl direkt lokal angesprochen werden kann.

Ganz ohne App kommt man allerdings auch hier nicht aus. Modbus TCP muss offenbar zunächst in der Anker-App unter den Einstellungen für Drittanbietersteuerung aktiviert werden. Das ist aber ein deutlich besserer Kompromiss als ein vollständig cloudgebundenes System: Die App dient dann zur Einrichtung und Freischaltung, während der laufende Betrieb lokal über Home Assistant erfolgen kann.

Für diesen Beitrag ist Anker SOLIX damit ein spannender Sonderfall. Einerseits steht Anker für genau die Art moderner Energiegeräte, die lange zu stark an App und Cloud gebunden wirkten. Andererseits zeigt die offizielle lokale Home-Assistant-Integration, dass Hersteller durchaus auf Nutzerwünsche reagieren können.

So sollte Entwicklung aussehen: Nicht zwingend App abschaffen, sondern lokale Schnittstellen nachreichen. Ein Energiespeicher, der lokal mit Home Assistant, Shelly, ioBroker oder einem lokalen Energiemanagement zusammenarbeiten kann, ist wesentlich mächtiger als ein Speicher, der nur hübsche Graphen in einer App zeigt.

Tado

Tado (bezahlter Link) ist ein gutes Beispiel für smarte Heizungssteuerung, die im Alltag für viele Menschen sehr komfortabel ist. Die App ist übersichtlich, Funktionen wie Zeitpläne, Geofencing und Raumsteuerung sind praktisch, und für normale Nutzer ist das deutlich zugänglicher als ein selbstgebautes Regelwerk in Home Assistant oder ioBroker.

Aber auch hier bleibt die Frage: Warum muss so viel über Herstellerdienste laufen? Heizkörperthermostate, Raumtemperaturen und Zeitpläne sind keine grundsätzlich globalen Informationen. Sie entstehen lokal und werden lokal gebraucht.

Eine gute Lösung wäre nicht: App weg. Eine gute Lösung wäre: App plus lokale Schnittstelle. Wer die App nutzen will, nutzt sie. Wer sein System lokal integrieren will, bekommt eine dokumentierte Möglichkeit dazu.

VeSync

VeSync-Geräte, etwa Luftreiniger (bezahlter Link) oder andere Haushaltsgeräte, zeigen ein weiteres typisches Muster. Die App ist bequem, sieht ordentlich aus und bündelt mehrere Geräte in einer Oberfläche. Für viele Nutzer reicht das völlig aus.

Aus Smart-Home-Sicht ist das aber oft unbefriedigend. Ein Luftreiniger könnte lokale Daten liefern: Luftqualität, Lüfterstufe, Filterstatus, Betriebsmodus. Das sind perfekte Werte für Automationen. Zum Beispiel: Wenn der Feinstaubwert steigt, Lüfter hoch. Wenn niemand zuhause ist, Modus ändern. Wenn nachts Ruhe ist, leiser Betrieb.

Dafür braucht man nicht zwingend eine Cloud. Man braucht eine lokale Schnittstelle.

Tuya allgemein

Tuya (bezahlter Link) ist vermutlich eines der bekanntesten Beispiele für die große App-Wolke im Smart Home. Unzählige Geräte verschiedenster Marken basieren auf Tuya-Plattformen: Steckdosen, Lampen, Sensoren, Schalter, Thermostate und vieles mehr.

Der Vorteil ist offensichtlich: Geräte sind günstig, schnell eingerichtet und für Hersteller leicht auf den Markt zu bringen. Für normale Nutzer funktioniert das oft erstaunlich unkompliziert.

Der Nachteil ist genauso offensichtlich: Viele Geräte hängen stark an der Tuya-App beziehungsweise an der Tuya-Cloud. Lokale Kontrolle ist je nach Gerät, Firmware und Plattform mal möglich, mal umständlich, mal gar nicht sinnvoll vorgesehen.

Das Ergebnis ist ein seltsamer Zustand: Man besitzt die Hardware, aber die eigentliche Nutzbarkeit hängt an einer Plattform, die man nicht kontrolliert.

Warum Hersteller-Apps nicht automatisch schlecht sind

Bei aller Kritik: Hersteller-Apps sind nicht grundsätzlich schlecht. Im Gegenteil. Für viele Menschen sind sie der Grund, warum Smart Home überhaupt nutzbar wird.

Eine gute App kann sehr viel leisten:

  • einfache Ersteinrichtung,
  • geführte WLAN-Konfiguration,
  • Firmware-Updates,
  • Push-Benachrichtigungen,
  • Diagnose und Fehlerhinweise,
  • Support-Funktionen,
  • Fernzugriff ohne eigene VPN-Lösung,
  • verständliche Oberfläche für normale Nutzer.

Nicht jeder möchte MQTT-Topics anlegen, Docker-Container pflegen oder sich fragen, ob sein Gerät jetzt per CoAP, HTTP, Modbus, RTSP oder schwarzer Magie kommuniziert.

Für viele Nutzer ist eine App also genau richtig. Gerät auspacken, QR-Code scannen, verbinden, fertig. Das ist legitim.

Auch Hersteller haben nachvollziehbare Gründe für Apps. Sie reduzieren Supportaufwand, vereinheitlichen die Bedienung, ermöglichen Updates und können Sicherheitsfunktionen zentral bereitstellen. Gerade bei Geräten, die potenziell sicherheitsrelevant sind, ist das nicht komplett unsinnig.

Die Frage ist nicht, ob Apps existieren dürfen. Die Frage ist, ob sie die einzige Tür zum Gerät sein müssen.

Das eigentliche Problem: Zwang statt Option

Der Kern des Problems ist nicht die App. Der Kern ist der Zwang.

Eine App als Komfortfunktion ist gut. Eine App als einzige offizielle Schnittstelle ist problematisch. Eine Cloud als optionale Fernzugriffslösung ist praktisch. Eine Cloud als Pflichtvoraussetzung für lokale Grundfunktionen ist fragwürdig.

Geräte im eigenen Haus sollten nicht unnötig abhängig sein von:

  • Hersteller-Servern,
  • Accounts,
  • App-Stores,
  • Geschäftsmodellen,
  • Abo-Plänen,
  • Produktlebenszyklen,
  • oder der Laune eines Konzerns, eine Plattform weiterzubetreiben.

Wer ein Gerät kauft, sollte es auch dann noch sinnvoll nutzen können, wenn der Hersteller die App einstellt, eine Cloud abschaltet oder ein neues Modell verkaufen möchte.

Gerade im Smart Home ist das wichtig. Eine smarte Lampe ist vielleicht noch verschmerzbar. Aber bei Heizung, Energie, Kameraüberwachung oder Sicherheitsfunktionen sieht die Sache anders aus.

Was ein gutes Smart-Home-Gerät können sollte

Ein gutes Smart-Home-Gerät muss nicht ausschließlich lokal sein. Es muss auch nicht ohne App ausgeliefert werden. Aber es sollte dem Nutzer Wahlfreiheit geben.

Aus meiner Sicht wäre ein ideales Gerät so aufgebaut:

1. App für normale Nutzer

Die App darf bleiben. Sie sollte Einrichtung, Bedienung, Updates und Support einfach machen. Wer nur schnell seine Heizung einstellen oder eine Kamera ansehen will, soll das tun können.

2. Lokale Schnittstelle für Fortgeschrittene

Zusätzlich sollte es eine dokumentierte lokale Schnittstelle geben. Je nach Gerät kann das MQTT, HTTP, Modbus, RTSP, ONVIF, Matter, CoAP oder etwas Vergleichbares sein.

Wichtig ist nicht, dass jedes Gerät alles unterstützt. Wichtig ist, dass lokale Integration nicht als unerwünschter Hack behandelt wird.

3. Cloud nur optional

Cloud-Funktionen können sinnvoll sein: Fernzugriff, Benachrichtigungen, Backups, Sprachassistenten oder Analysefunktionen. Aber lokale Grundfunktionen sollten nicht davon abhängen.

4. Keine unnötigen Accounts

Ein Account kann für Fernzugriff sinnvoll sein. Für eine lokale Steckdose, einen Sensor oder einen einfachen Schalter ist er oft übertrieben. Nicht jedes Gerät muss eine Kundenbeziehung simulieren.

5. Saubere Dokumentation

Hersteller müssen nicht ihre komplette interne Entwicklung offenlegen. Aber eine einfache, stabile und dokumentierte API wäre ein großer Schritt. Gerade für Smart-Home-Nutzer, Integratoren und Bastler.

Warum lokale Steuerung auch für normale Nutzer wichtig ist

Man könnte sagen: Das betrifft doch nur Nerds. Leute mit Home Assistant, ioBroker, Zigbee2MQTT und zu vielen beschrifteten Netzteilen.

Aber das stimmt nur teilweise.

Lokale Steuerung bringt auch normalen Nutzern Vorteile:

  • Geräte reagieren schneller.
  • Automationen funktionieren auch bei Internetausfall.
  • Private Daten bleiben eher im eigenen Netz.
  • Geräte sind länger nutzbar.
  • Man ist weniger abhängig von App-Änderungen.
  • Ein Herstellerwechsel wird einfacher.

Heute klingt das vielleicht nach Spezialthema. Aber spätestens wenn ein Hersteller eine Cloud abschaltet, ein Abo einführt oder eine App verschlimmbessert, wird lokale Kontrolle plötzlich sehr praktisch.

Dann ist es gut, wenn das Smart Home nicht komplett auf Treibsand gebaut wurde.

Smart Home ohne Hersteller-App heißt nicht Smart Home ohne Komfort

Ein Smart Home ohne Hersteller-App bedeutet nicht, dass man jede App löschen und alles nur noch per Kommandozeile bedienen muss. Es bedeutet auch nicht, dass Cloud-Funktionen grundsätzlich böse sind.

Es geht um Kontrolle.

Die beste Lösung wäre ein zweigleisiger Ansatz:

  • App für einfache Bedienung,
  • lokale Schnittstelle für Integration,
  • Cloud nur für Funktionen, die wirklich Cloud brauchen.

So könnten Hersteller normale Nutzer abholen und gleichzeitig verhindern, dass fortgeschrittene Nutzer ihre Geräte mit inoffiziellen Umwegen, Reverse Engineering oder halb kaputten Integrationen ins lokale Smart Home prügeln müssen.

Denn genau das passiert aktuell oft: Geräte können eigentlich viel, aber die offiziellen Möglichkeiten sind künstlich begrenzt. Also entstehen Community-Lösungen, Bastelwege, lokale Hacks und API-Experimente.

Das ist spannend. Aber es sollte nicht nötig sein.

Fazit: Die App darf bleiben, aber bitte nicht als Käfig

Hersteller-Apps sind nicht automatisch schlecht. Sie können Einrichtung, Bedienung und Support erheblich vereinfachen. Gerade für normale Nutzer sind sie oft der beste Einstieg ins Smart Home.

Aber eine App sollte ein Werkzeug sein, kein Käfig.

Wenn ein Gerät im eigenen Haus steht, lokal Strom schaltet, Wärme regelt, Wasser erhitzt, Luft reinigt, Energie speichert oder Bilder aufnimmt, dann sollte es auch lokal ansprechbar sein. Nicht zwingend ausschließlich lokal, aber zumindest optional.

Zigbee, Z-Wave, Matter und viele klassische Netzwerkstandards zeigen, dass lokale Kommunikation funktioniert. Es fehlt oft nicht an der Technik, sondern am Willen der Hersteller, diese Möglichkeit sauber freizugeben.

Und genau deshalb bleibt die Frage berechtigt:

Warum braucht meine Steckdose einen Account?

Vielleicht lautet die ehrlichere Antwort: Weil der Hersteller nicht nur die Steckdose verkaufen will, sondern auch die Beziehung danach kontrollieren möchte.

Für ein wirklich gutes Smart Home wäre mir aber lieber: Ich kaufe das Gerät. Ich nutze die App, wenn sie gut ist. Und wenn ich es lokal integrieren will, lässt man mich einfach machen.

Noch mehr Smart Home

Wenn du tiefer in lokale Smart-Home-Automation einsteigen möchtest, passen dazu besonders diese Beiträge: In Smart Home ohne Cloud geht es um die grundsätzliche Idee, Geräte möglichst unabhängig von Herstellerdiensten zu betreiben. Praktische Beispiele findest du in Shelly Direktverknüpfung – lokale Automationen ohne Cloud, Shelly Script oder Home Assistant und Echtes Smart Home – Automatisierung statt Fernbedienung. Für die Protokollseite lohnt sich außerdem ein Blick auf Zigbee, Z-Wave, WLAN, what MATTERs, während Hisense per MQTT steuern zeigt, wie spannend lokale Gerätesteuerung auch abseits klassischer Lampen und Steckdosen werden kann.

Schreibe einen Kommentar