{"id":3698,"date":"2026-03-12T17:18:23","date_gmt":"2026-03-12T16:18:23","guid":{"rendered":"https:\/\/g7itchme.wordpress.com\/?p=3698"},"modified":"2026-03-12T17:18:23","modified_gmt":"2026-03-12T16:18:23","slug":"vom-maker-tool-zum-industrie-profi-der-esp32-und-seine-alternativen-im-provisioning-dschungel","status":"publish","type":"post","link":"https:\/\/technodidact.de\/en\/vom-maker-tool-zum-industrie-profi-der-esp32-und-seine-alternativen-im-provisioning-dschungel\/","title":{"rendered":"Vom Maker-Tool zum Industrie-Profi: Der ESP32 und seine Alternativen im Provisioning-Dschungel"},"content":{"rendered":"\n

Autor: DerSchneider<\/strong><\/p>\n\n\n\n

Einleitung<\/h2>\n\n\n\n

Was vor wenigen Jahren noch als Spielzeug f\u00fcr Bastler galt, hat heute die IoT-Welt im Sturm erobert: der ESP32. Mit integriertem WLAN und Bluetooth, einer beeindruckenden Peripherie und einem Preis von oft unter f\u00fcnf Euro hat Espressifs System-on-Chip die Maker-Szene revolutioniert. Doch sobald ein Prototyp den Schreibtisch verlassen und als Produkt in die Welt hinaus soll, stellen sich Fragen, die im Hobbykeller gerne \u00fcbersehen werden: Wie bringe ich hunderten Ger\u00e4ten auf einmal sicher und benutzerfreundlich die WLAN-Zugangsdaten bei? Und reicht der ESP32 \u00fcberhaupt f\u00fcr professionelle Anforderungen aus?<\/p>\n\n\n\n

Dieser Artikel beleuchtet die Provisionierungsmethoden f\u00fcr den ESP32, zeigt ihre St\u00e4rken und Schw\u00e4chen auf und wagt den Blick zu den etablierten Alternativen aus der Industrie. Denn was f\u00fcr den Maker ein gefeierter Allesk\u00f6nner ist, st\u00f6\u00dft in der Fertigung, Medizintechnik oder Automatisierung schnell an Grenzen \u2013 aber nicht immer.<\/p>\n\n\n\n

Hauptteil<\/h2>\n\n\n\n

1. Provisioning \u2013 Die verkannte K\u00f6nigsdisziplin des IoT<\/h3>\n\n\n\n

Provisioning bezeichnet den Prozess, einem noch nicht vernetzten Ger\u00e4t die notwendigen Zugangsdaten f\u00fcr das heimische oder firmeneigene Netzwerk sicher zu \u00fcbergeben. F\u00fcr den Einzelbastler ist das oft eine l\u00e4stige Kleinigkeit: Man kodiert SSID und Passwort fest in den Code, kompiliert und flasht. F\u00fcr ein Produkt, das ein Endkunde in Betrieb nehmen soll, ist dieser Weg jedoch ein Graus.<\/p>\n\n\n\n

Die Anforderungen an professionelles Provisioning sind hoch:<\/p>\n\n\n\n

    \n
  • Sicherheit:<\/strong>\u00a0Keine \u00dcbertragung von Klartext-Passw\u00f6rtern. Schutz vor Man-in-the-Middle-Angriffen.<\/li>\n\n\n\n
  • Benutzerfreundlichkeit:<\/strong>\u00a0Keine manuelle Eingabe langer Netzwerknamen auf einem winzigen Display. Kein Umherirren in den WLAN-Einstellungen des Smartphones.<\/li>\n\n\n\n
  • Skalierbarkeit:<\/strong>\u00a0Die Methode muss f\u00fcr tausende Ger\u00e4te gleichzeitig funktionieren.<\/li>\n\n\n\n
  • Flexibilit\u00e4t:<\/strong>\u00a0Unterst\u00fctzung verschiedener Transportmedien (WLAN, Bluetooth, Ethernet, Mobilfunk).<\/li>\n<\/ul>\n\n\n\n

    Der ESP32 bietet hier drei Standardwege, die ich in der folgenden Tabelle gegen\u00fcberstelle.<\/p>\n\n\n\n

    Methode<\/th>Transport<\/th>Typische App<\/th>Sicherheit<\/th>Benutzerfreundlichkeit<\/th>Industrietauglich?<\/th><\/tr><\/thead>
    BLE Provisioning (Espressif)<\/td>Bluetooth LE<\/td>ESP BLE Provisioning (offiziell)<\/td>Hoch (Proof-of-Possession, TLS)<\/td>Sehr gut (Nutzer bleibt im WLAN)<\/td>Bedingt (f\u00fcr kleinere Serien)<\/td><\/tr>
    SoftAP Provisioning<\/td>WLAN (ESP als Hotspot)<\/td>Webbrowser<\/td>Mittel (nur WPA2 auf Hotspot)<\/td>Mittel (WLAN-Wechsel n\u00f6tig)<\/td>Kaum<\/td><\/tr>
    Improv WiFi<\/td>BLE<\/td>Improv-kompatible Apps<\/td>Hoch (offener Standard)<\/td>Sehr gut<\/td>Wird gr\u00f6\u00dfer (z.B. Home Assistant)<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

    Die Praxis-Erfahrung:<\/strong> Wer schon einmal versucht hat, einer \u00e4lteren Person die Verbindung mit einem SoftAP-Hotspot zu erkl\u00e4ren, wei\u00df, warum BLE-basierte Verfahren heute bevorzugt werden. Die offizielle Espressif-App \u201eESP BLE Provisioning\u201c ist dabei ein gutes Werkzeug \u2013 f\u00fcr den Prototypen. Sie ist aber nicht f\u00fcr den Produkt-Branding gedacht und setzt voraus, dass der Endkunde die richtige App aus dem Store herunterl\u00e4dt. Das ist f\u00fcr ein Consumer-Produkt oft eine H\u00fcrde zu viel.<\/p>\n\n\n\n

    2. Die ESP32-spezifischen Limitierungen aus Industriesicht<\/h3>\n\n\n\n

    Bevor wir zu Alternativen kommen, m\u00fcssen wir ehrlich die Schw\u00e4chen des ESP32 benennen. Espressif selbst hat mit der ESP32-S3, C3 und neuerdings C6 und H2 viele Verbesserungen gebracht, doch die grundlegende Architektur bleibt f\u00fcr viele Industrieanwendungen problematisch.<\/p>\n\n\n\n

    Echtzeitverhalten:<\/strong> Der ESP32 basiert auf Tensilica Xtensa- oder RISC-V-Kernen mit einem propriet\u00e4ren RTOS-basierten Framework (FreeRTOS). Die integrierten WLAN- und Bluetooth-Stacks laufen auf dem gleichen Chip und erzeugen Latenzen, die f\u00fcr harte Echtzeitanforderungen (z. B. Motorregelung mit unter 1 \u00b5s Jitter) ungeeignet sind. Zwar gibt es die M\u00f6glichkeit, einen Kern ausschlie\u00dflich f\u00fcr die Anwendung zu reservieren, doch die Interrupt-Latenzen sind nicht deterministisch genug f\u00fcr sicherheitskritische Regelungen.<\/p>\n\n\n\n

    Stromverbrauch im aktiven Modus:<\/strong> Mit aktivem WLAN zieht der ESP32 typisch 80\u2013120 mA. Im Deep-Sleep sind 5\u201310 \u00b5A respektabel, aber ein batteriebetriebener Sensor, der alle paar Minuten eine Messung durchf\u00fchrt und per WLAN sendet, wird keine Jahreslaufzeit erreichen. Hier sind spezialisierte BLE- oder LoRa-Chips haushoch \u00fcberlegen.<\/p>\n\n\n\n

    Langzeitverf\u00fcgbarkeit:<\/strong> Espressif garantiert f\u00fcr seine Standard-ESP32-Module keine 10-Jahres-Verf\u00fcgbarkeit. F\u00fcr die Automobil- oder Medizintechnik ist das ein Ausschlusskriterium. Hersteller wie STMicroelectronics oder Texas Instruments bieten dagegen gezielte Langzeitverf\u00fcgbarkeitsprogramme (oft 10\u201315 Jahre) an.<\/p>\n\n\n\n

    3. Professionelle Hardware-Alternativen im Vergleich<\/h3>\n\n\n\n

    Nach dieser ern\u00fcchternden Bestandsaufnahme \u2013 welche Plattformen sind denn nun wirklich \u201eprofessionell\u201c? Ich habe die relevantesten Alternativen in der folgenden Tabelle gegen\u00fcbergestellt.<\/p>\n\n\n\n

    Merkmal<\/th>ESP32 (Referenz)<\/th>STM32 (z.B. STM32U5\/STM32H7)<\/th>Nordic nRF5340<\/th>Raspberry Pi Pico W (RP2040)<\/th><\/tr><\/thead>
    Kerne<\/td>2x Xtensa LX6 (240 MHz)<\/td>1-2x Cortex-M33 (160\u2013480 MHz)<\/td>2x Cortex-M33 (128+256 MHz)<\/td>2x Cortex-M0+ (133 MHz)<\/td><\/tr>
    Integrierte Funktechnik<\/td>WLAN 802.11b\/g\/n, BT 5.0<\/td>Kein integriertes WLAN (externe Module)<\/td>BT 5.2, (kein WLAN)<\/td>WLAN 802.11n (CYW43439)<\/td><\/tr>
    Echtzeitf\u00e4higkeit (Jitter)<\/td>\u00b110\u201350 \u00b5s typisch<\/td>\u00b10,5\u20132 \u00b5s (mit Timer)<\/td>\u00b11\u20133 \u00b5s<\/td>\u00b15\u201315 \u00b5s<\/td><\/tr>
    Tiefschlafstrom<\/td>5\u201310 \u00b5A<\/td><1 \u00b5A (STM32U5: 0,9 \u00b5A)<\/td><1 \u00b5A<\/td>18 \u00b5A (Pico W)<\/td><\/tr>
    Langzeitverf\u00fcgbarkeit<\/td>3\u20135 Jahre (typisch)<\/td>10\u201315 Jahre (garantiert)<\/td>5\u201310 Jahre<\/td>Unklar (Raspberry Pi \u2013 eher kurz)<\/td><\/tr>
    Typischer Preis (Einzelst\u00fcck)<\/td>ca. 3\u20135 \u20ac<\/td>4\u201315 \u20ac (je nach Peripherie)<\/td>ca. 5\u20138 \u20ac<\/td>ca. 6 \u20ac<\/td><\/tr>
    Typische Einsatzgebiete<\/td>Smart Home, Maker, Consumer IoT<\/td>Motorsteuerung, Medizin, Industrieautomatisierung<\/td>Wearables, BLE-Sensoren, Audio-Streaming<\/td>Hobby, Bildung, einfache Steuerungen<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

    Interpretation:<\/strong> Der STM32 ist der Platzhirsch f\u00fcr alles, was deterministisch, sicher und langlebig sein muss. Dass er kein eigenes WLAN mitbringt, ist kein Nachteil, sondern eine bewusste Architekturentscheidung: In der Industrie setzt man lieber auf zertifizierte Funkmodule (z. B. von u-blox oder Murata), die separat gepr\u00fcft und getauscht werden k\u00f6nnen. Der Nordic nRF5340 ist der unangefochtene K\u00f6nig bei hochkomplexen Bluetooth-Anwendungen (z. B. professionelle Headsets, medizinische Sensoren). Der Pico W ist eher eine weitere Maker-Plattform, kein echter Industriesprung.<\/p>\n\n\n\n

    4. Provisioning in der Industrie \u2013 jenseits von BLE und SoftAP<\/h3>\n\n\n\n

    Was aber, wenn ich ein Produkt mit einem STM32 entwickle und es dennoch bequem per Smartphone einrichten m\u00f6chte? Hier kommen professionelle Provisioning-Architekturen ins Spiel, die oft auf einer Kombination aus Hardware-Sicherheit und Cloud-Backend basieren.<\/p>\n\n\n\n

    Zero-Touch Provisioning (ZTP):<\/strong> Das Ger\u00e4t wird ab Werk mit einem Ger\u00e4tezertifikat ausgestattet, das in einem sicheren Element (z. B. dem STM32Trust TEE) gespeichert ist. Bei der ersten Inbetriebnahme verbindet es sich automatisch mit einem vorkonfigurierten Netzwerk (z. B. Ethernet im Fabrikgeb\u00e4ude) oder \u00fcber einen QR-Code auf dem Geh\u00e4use. Der Nutzer scannt den Code mit einer App, und die Cloud \u00fcbernimmt den Rest. Kein WLAN-Passwort muss jemals manuell eingegeben werden.<\/p>\n\n\n\n

    Mobilfunk-basiertes Provisioning:<\/strong> Ger\u00e4te mit integriertem LTE-M oder NB-IoT-Modem (z. B. \u00fcber ein Modul von Quectel oder das Walter SoM) erhalten ihre Konfiguration direkt \u00fcber das Mobilfunknetz. Die SIM-Karte dient als Hardware-Root-of-Trust. Plattformen wie Soracom Krypton<\/strong> nutzen genau diese Idee: Das Ger\u00e4t authentifiziert sich \u00fcber die SIM und bezieht dann seine Netzwerkzugangsdaten f\u00fcr lokales WLAN oder die Cloud-Zertifikate \u2013 alles ohne jegliches Zutun des Benutzers.<\/p>\n\n\n\n

    Cloud-gest\u00fctztes Device Management:<\/strong> F\u00fcr gr\u00f6\u00dfere Flotten (ab 100 Ger\u00e4ten) setzen Unternehmen auf Plattformen wie den Bosch IoT Remote Manager<\/strong> oder EnOS Device Provisioning Service<\/strong>. Diese Dienste bieten nicht nur das einmalige Onboarding, sondern auch:<\/p>\n\n\n\n