Stell dir eine Wohnung vor, die es so nicht gibt, aber sofort vertraut wirkt. Du kommst mit zwei Einkaufstaschen durch die Tür. Auf dem Boden hängt ein kleiner Saugroboter dramatisch an einem Schnürsenkel. Am Handgelenk vibriert die Apple Watch, weil noch eine Nachricht eingegangen ist. Auf dem Balkon misst ein selbstgebauter ESP32-Sensor ruhig Temperatur und Feuchte, ohne irgendjemanden zu benachrichtigen. Welches dieser Dinge ist jetzt „smart“? Die ehrliche Antwort lautet: Das Wort hilft fast gar nicht. Der Saugroboter besitzt Sensoren, Motoren und einen Handlungsspielraum – und scheitert trotzdem sichtbar. Die Uhr sammelt Kontext, rechnet und kommuniziert, bewegt aber nicht autonom die Welt. Der Sensor macht genau eine langweilige Sache, vielleicht besser als beide. Wer Gadgets beurteilen will, sollte deshalb nicht nach Glanz sortieren, sondern nach vier Fragen: Was misst das Gerät? Was entscheidet es? Was verändert es? Und wovon hängt das Ganze ab?
Im Flur zeigt der Schnürsenkel, was ein Roboter wirklich verspricht
Ein Roboter muss nicht laufen, sprechen oder wie C-3PO aussehen. Die von der International Federation of Robotics wiedergegebene ISO-Kernidee beschreibt einen programmierten betätigten Mechanismus mit einem Grad an Autonomie für Bewegung, Manipulation oder Positionierung. [2] Ein stationärer FANUC-Arm in einer Fabrik ist damit klarer Roboter, obwohl er keinen Schritt macht. Ein Saugroboter ist ebenfalls einer: Er bewegt sich, nimmt Sensoren ernst und wählt innerhalb einer Aufgabe Handlungen.
Der Schnürsenkel im erfundenen Flur ist kein Vorwurf an ein bestimmtes Produkt. iRobot dokumentiert für bestimmte kamerabasierte Roomba-Modelle eine PrecisionVision-Hinderniserkennung, die unter anderem Kabel, Spielzeug und Tierkot erkennen soll. [4] Das ist eine konkrete Fähigkeit für konkrete Modelle – keine Aussage, dass jeder Roomba jede Schnur unter jedem Licht erkennt.
Teilautonomie reicht. Die IFR beschreibt Serviceroboter nicht als völlig unabhängige Maschinenwesen; Menschen können Ziel, Raum und Startzeit setzen, während das Gerät den Weg selbst wählt. [3] Der faire Test lautet daher nicht „Ist er intelligent?“, sondern „Welche Situationen bewältigt er ohne Hilfe, und wann muss ich eingreifen?“
In der Küche steckt ein Computer, der keine Aufmerksamkeit will
Die Spülmaschine misst Wasserstand und Temperatur, schaltet Ventile, Pumpe und Heizung und folgt einem Programm. Damit enthält sie ein eingebettetes System. NIST fasst darunter einen Computer als Teil eines größeren Systems mit zweckgebundener Rechenfunktion. [1] Der Computer ist nicht das Produkt; er erledigt im Produkt eine Aufgabe.
WLAN ändert diese Grundrolle nicht. Eine App kann den Status zeigen oder einen Start verzögern. Dadurch wird das Gerät vernetzt und als smart vermarktet, aber es wird nicht automatisch robotisch. Pumpen und rotierende Sprüharme sind Aktoren, doch die Maschine erfüllt nicht jede Robotikdefinition bloß, weil sich in ihr etwas bewegt.
Der interessante Kaufvergleich ist banal: Hilft die Vernetzung bei einer echten Handlung? Wer ohnehin vor der geschlossenen Maschine stehen muss, um sie zu beladen, gewinnt durch Fernstart vielleicht wenig. Eine verständliche Restzeitanzeige, ein zuverlässig lokaler Zeitplan oder eine klare Fehlermeldung kann nützlicher sein als zwölf Push-Nachrichten.
Am Handgelenk ist die Apple Watch voller Sensoren und trotzdem kein Roboter
Apples aktuelle technische Daten der Apple Watch Series 11 nennen unter anderem elektrische und optische Herzsensoren, Temperatur- und Umgebungslichtsensor, Beschleunigungsmesser, Gyroskop, Höhenmesser und Tiefenmesser. Dazu kommen haptisches Feedback, Lautsprecher, Mikrofon, GPS, WLAN und Bluetooth. [5] Das ist ein dichtes cyber-physisches Gerät am Körper.
Die Uhr misst, rechnet, zeigt, vibriert und kommuniziert. Sie ist eingebettet und vernetzt; einzelne Funktionen reagieren auf Kontext. Trotzdem nennen wir sie gewöhnlich nicht Roboter. Ihr haptischer Aktor gibt Rückmeldung, aber sie besitzt keinen autonomen Mechanismus, der eine Bewegungs-, Manipulations- oder Positionierungsaufgabe in der Umgebung erfüllt.
Das Beispiel schützt vor einer beliebten Kurzform: Sensor plus Aktor gleich Roboter. Sonst wären Rauchmelder, Lautsprecher und Thermostat ebenfalls Roboter. Entscheidend ist nicht, ob irgendein physischer Effekt entsteht, sondern welche programmierte Aufgabe der Mechanismus mit welchem Handlungsspielraum übernimmt.
Auf dem Balkon ist der ESP32 nur das Gehirn, nicht die Idee
ESP32 ist eine reale Bausteinfamilie von Espressif. Das aktuelle Datenblatt dokumentiert Prozessor, Wi-Fi, Bluetooth, GPIOs, Analogwandler, Timer und Schnittstellen wie SPI, I²C und UART. [6] Diese Ausstattung macht den Chip enorm praktisch für Sensoren, Schalter und kleine Steuerungen. Sie macht ihn nicht von selbst smart.
Erst das Projekt legt die Rolle fest. Ein ESP32 kann alle fünf Minuten einen Temperaturwert lokal auf eine Speicherkarte schreiben. Er kann denselben Wert per MQTT an einen Server senden. Oder er kann bei Trockenheit eine Pumpe schalten. Hardware bleibt ähnlich; Datenpfad, Abhängigkeit und Wirkung ändern sich fundamental.
Der stille Balkonsensor aus unserem Szenario ist vielleicht das nützlichste Gerät der Wohnung, obwohl er weder App noch KI besitzt. Wenn er lokal stabil misst, seine Batterie lange hält und die Daten verständlich exportiert, erfüllt er ein klares Versprechen. Technik wird nicht durch möglichst viele Funktionen erwachsen, sondern durch eine gut begrenzte Aufgabe.
In der Werkstattecke bewegt Arduino einen Servo – mehr noch nicht
Mit der offiziellen Arduino Servo Library kann ein Board Hobbyservos ansteuern. Die Dokumentation beschreibt Standardservos, deren Welle auf Winkel gesetzt wird, sowie kontinuierlich drehende Varianten. [7] Das ist echte Aktorik: Code verändert eine mechanische Position.
Ein Servo, der auf Knopfdruck immer auf 90 Grad fährt, ist trotzdem noch kein überzeugender Roboter. Es fehlen möglicherweise Sensorik, Zustandsmodell und eine selbst gewählte Reaktion auf die Umgebung. Baut man zwei Servos, einen Abstandssensor und eine Regel hinzu, entsteht schrittweise ein Mechanismus mit eigenem Handlungsspielraum.
Für Maker ist diese Grenze befreiend. Nicht jedes Projekt muss sofort KI-Robotik heißen. Ein sauberer automatischer Pflanzenlüfter kann besser gebaut sein als ein wackliger „Roboter“, der in einer Demo einmal winkt. Die präzise Bezeichnung nimmt dem Projekt keinen Coolnesspunkt; sie zeigt, was tatsächlich funktioniert.
Hinter der App beginnt oft ein unsichtbarer Teil des Produkts
Ein vernetztes Gadget endet selten am Gehäuse. NIST zählt bei Consumer IoT ausdrücklich auch Companion-App, Gateway und Cloud-Backend zu möglichen Produktkomponenten. [8] Wenn der Roboter seine Karte nur nach Kontoanmeldung zeigt oder die Leuchte ohne Herstellercloud keinen neuen Zeitplan annimmt, gehören diese Dienste zur versprochenen Funktion.
Das erklärt, warum ein technisch intaktes Gerät plötzlich dumm wirken kann. DNS, Zertifikat, App-Store, Loginserver oder Anbieterbetrieb fallen aus, obwohl Sensor und Motor im Wohnzimmer gesund sind. Umgekehrt kann eine gute Cloud rechenintensive Dienste, Fernzugriff und schnelle Updates liefern. Cloud ist weder automatisch schlecht noch automatisch intelligent.
Vor dem Kauf hilft ein einfacher Offline-Test auf Papier: Was funktioniert ohne Internet? Was funktioniert ohne Konto? Was funktioniert, wenn die App in fünf Jahren nicht mehr installiert werden kann? Je näher eine Funktion an Tür, Heizung, Gesundheit oder Sicherheit liegt, desto weniger darf die Antwort „hoffentlich alles“ lauten.
Smartness zeigt sich im Scheitern, nicht im Unboxing
Eine Demo räumt den Boden, lädt den Akku und stellt perfektes Licht her. Der Alltag liefert dunkle Teppiche, offene Türen, Haustiere, schwaches WLAN und eben Schnürsenkel. Gute Autonomie erkennt nicht nur die Idealsituation. Sie begrenzt Fehler, meldet Unsicherheit und fordert Hilfe, bevor aus Stolpern Schaden wird.
Für den Flurroboter sind deshalb Rückfragen interessanter als Saugleistung allein: Erkennt er Hindernisse lokal? Bleibt die Karte nach Netzausfall verfügbar? Kann er einen Raum überspringen, ohne die ganze Wohnung neu zu lernen? Stoppt er bei blockiertem Rad? Lassen sich Fehlermeldungen verstehen, ohne im Forum Detektiv zu spielen?
Dass ein Gerät scheitert, ist nicht automatisch ein Skandal. Reale Welt ist schwierig. Problematisch wird es, wenn Marketing den Betriebsbereich verschweigt und die App nur „Etwas ist schiefgelaufen“ sagt. Ein cooles Gadget macht seine Grenze sichtbar und lässt den Menschen elegant übernehmen.
Datenschutz beginnt bei der Frage, welche Funktion welche Daten braucht
Ein Bodenplan, Herzsignal, Mikrofonstream und Temperaturwert sind nicht dieselbe Datenklasse. Entscheidend sind Zweck, Empfänger, Speicherdauer, Zugriff und Löschbarkeit. Die Frage „Sendet das Gerät Daten?“ ist zu grob. Ein lokaler Befehl und ein dauerhaftes Cloudprofil können denselben Funkstandard benutzen und völlig andere Risiken erzeugen.
NIST IR 8425 betrachtet deshalb das gesamte Consumer-IoT-Produkt, nicht nur das Gerät im Gehäuse. [10] Sicherheit hängt ebenso an App, Backend, Support und Herstellerprozessen. Ein verschlüsselter Sensor nützt wenig, wenn das Konto schwach wiederhergestellt werden kann oder Updates ohne klare Laufzeit enden.
Für Haushalte reicht eine kurze Verhandlung: Welche Daten sind für die gewünschte Funktion zwingend? Gibt es lokale Alternativen? Können mehrere Personen getrennte Rollen erhalten? Lassen sich Karten und Verläufe exportieren und löschen? Wer diese Fragen gemeinsam beantwortet, macht Datenschutz vom Verzichtsthema zur normalen Haushaltsorganisation.
Updates sind Teil des Kaufpreises, auch wenn sie später kommen
ETSI EN 303 645 formuliert für Consumer IoT eine Sicherheitsbasis mit Themen wie eindeutiger Authentisierung, Schwachstellenmanagement, sicheren Updates, Schutz persönlicher Daten und Ausfallsicherheit. [9] Das ist kein Testsiegel für ein beliebiges Produkt, aber eine brauchbare Erinnerung: Vernetzung erzeugt Pflichten über den Verkaufstag hinaus.
Ein Hersteller sollte sagen, wie lange Sicherheitsupdates mindestens kommen, wie das Gerät ihre Echtheit prüft und was nach Supportende geschieht. Ein Produkt, das ohne Cloudkonto nicht zurückgesetzt oder weitergegeben werden kann, besitzt eine eingebaute Ablaufunsicherheit. Niedriger Kaufpreis kann dann nur vertagte Entsorgung bedeuten.
Bei einem ESP32-Eigenbau liegt diese Verantwortung beim Maker: Bibliotheken pflegen, Schlüssel schützen, Updateweg planen, offene Ports kennen. Bei Apple Watch oder Roomba liegt mehr davon beim Unternehmen. In beiden Fällen bleibt dieselbe Grundfrage: Wer hält die versprochene Funktion sicher am Leben?
Der Fünf-Fragen-Kaufcheck passt zwischen Haustür und Kasse
Erstens: Welche konkrete Alltagshandlung wird besser? „Die Wohnung ist sauber, bevor Besuch kommt“ ist eine Aufgabe. „Hat KI und App“ ist keine. Zweitens: Welche Sensoren und Daten braucht genau diese Aufgabe? Alles Weitere ist Zusatzlast, die Nutzen beweisen muss.
Drittens: Was entscheidet das Gerät selbst, und wann greift ein Mensch ein? Beim Roboter betrifft das Betriebsbereich und Fallback, bei der Uhr die Interpretation einer Messung, bei der Spülmaschine nur den Programmablauf. Viertens: Welche Kernfunktion bleibt ohne Internet, Konto und Anbieter bestehen?
Fünftens: Wie endet die Beziehung? Updatezeitraum, Datenlöschung, Eigentümerwechsel, Ersatzteile und lokale Weiterverwendung gehören vor dem Kauf auf den Tisch. Ein günstiges Gadget mit drei Jahren erzwungener Cloud kann teurer sein als ein schlichtes Gerät, das zehn Jahre ruhig arbeitet.
Dann sortiert sich die Wohnung von selbst. Die Apple Watch ist ein hochkomplexes vernetztes Wearable, aber kein Roboter. Der ESP32 ist ein vielseitiger eingebetteter Baustein, aber noch kein Smartprodukt. Arduino plus Servo liefert Aktorik, aber nicht automatisch Autonomie. Der Roomba ist ein echter mobiler Roboter, auch wenn er gerade am Schnürsenkel hängt. Und das unscheinbarste Gerät kann das klügste sein, wenn es eine sinnvolle Aufgabe zuverlässig, verständlich und ohne unnötige Abhängigkeit löst.
Aktuelle Herstellerdaten sowie NIST-, ISO/IFR- und ETSI-Grundlagen zu Embedded, Robotik und Consumer IoT
- NIST FIPS PUB 11-3 – Dictionary for Information Systems (standard-reference)
- International Federation of Robotics – Robot Definitions (industry-reference)
- International Federation of Robotics – Service Robot Definition (industry-reference)
- iRobot Support – Roomba Obstacle Detection (manufacturer-support-primary)
- Apple – Apple Watch Series 11 Technical Specifications (manufacturer-primary)
- Espressif – ESP32 Series Datasheet (manufacturer-datasheet-primary)
- Arduino Documentation – Servo Library (manufacturer-technical-primary)
- NIST Cybersecurity for IoT – Frequently Asked Questions (standard-institution)
- ETSI EN 303 645 V3.1.3 – Consumer IoT Baseline Requirements (standard-primary)
- NIST IR 8425 – Consumer IoT Product Profile (standard-primary)
Recherche- und Redaktionsstand: 17. August 2026. Redaktionell verantwortlich: Benjamin Metzig.