← Blog Hardware

BLE vs. WiFi für IoT-Geräte: Stromverbrauch, Reichweite und wann was

BLElinked

BLE 5.0 — GEST-Geräte nutzen BLE für 2 Jahre Batterielaufzeit bei einem Telemetrieintervall von 30 Sekunden

Die Protokollwahl zwischen BLE und WiFi prägt Ihre gesamte Produktarchitektur — Strombudget, Gateway-Anforderungen, PCB-Antennendesign und Benutzererfahrung.

Strom: Der Unterschied um eine Größenordnung

WiFi hält die Funkverbindung auch im Leerlauf aufrecht und zieht dabei kontinuierlich 1–8 mA. BLE kann mit einem Duty Cycle von <1 % Advertising senden und liegt damit im Durchschnitt unter 100 μA. Auf einer CR2032-Knopfzelle (225 mAh):

// Vergleich der Batterielaufzeit mit CR2032 (225 mAh)

WiFi (30s Telemetrie, 10s Verbindung): ~8 mA Ø  → ~3 Monate
BLE (30s Intervall, 500ms Verbindung): ~0,08 mA Ø → ~24 Monate

Deshalb setzt GEST ausschließlich auf BLE. Eine Batterielaufzeit von 2 Jahren beim erforderlichen Messintervall ist nur mit BLE erreichbar.

Wann BLE zu wählen ist

  • Batteriebetriebene Sensoren, die 1+ Jahr Laufzeit mit einer Knopfzelle anstreben
  • Geräte, die sich ohne Hub direkt mit Smartphones verbinden
  • BLE-Mesh für Sensornetzwerke in intelligenten Gebäuden

Wann WiFi zu wählen ist

  • Netzbetriebene Geräte, bei denen der Stromverbrauch keine Einschränkung darstellt
  • Anforderungen an hohen Durchsatz (4K-Streaming, große Dateiübertragungen)
  • Direkte Cloud-Verbindung ohne Gateway
💡 Hybridstrategie
OMNIYON nutzt WiFi 6 (netzbetrieben, 4K-Streaming). GEST nutzt BLE (batteriebetrieben). Beide verbinden sich über ein gemeinsames Gateway, das die Protokolle übersetzt, mit demselben Azure IoT Hub.

BLE-Mesh und Thread: Über Punkt-zu-Punkt hinaus

BLE 5.0 führte Bluetooth Mesh ein und ermöglicht damit Many-to-Many-Kommunikation über ein ganzes Gebäude hinweg. Jeder Knoten kann Nachrichten weiterleiten, sodass ein Sensor im Keller mit einem Gateway im obersten Stockwerk kommunizieren kann, indem er über zwischengeschaltete Geräte springt. Das macht BLE für große Smart-Building-Einsätze tauglich, bei denen es unpraktisch ist, an jeden Sensorstandort einen WiFi-Access-Point zu bringen.

Thread (das ebenfalls auf 802.15.4-Hardware läuft) ist ein weiteres stromsparendes Mesh-Protokoll, das in der Smart-Home- und der gewerblichen Gebäudeautomatisierung an Bedeutung gewinnt. Wenn Ihr Produkt sich in Apple-Home- oder Google-Home-Ökosysteme integrieren muss, ist Thread mit Matter zunehmend das Protokoll der Wahl. Thread-Geräte können jahrelang mit AA-Batterien laufen und dabei die Mesh-Konnektivität aufrechterhalten — vergleichbar mit BLE in Bezug auf die Energieeffizienz.

Gateway-Architektur

BLE- und Thread-Geräte benötigen ein Gateway, um das Internet zu erreichen — sie können sich nicht direkt mit Ihrem Cloud-Backend verbinden. Das fügt Ihrer Produktarchitektur eine Komponente hinzu: Das Gateway muss stets online sein, muss zuverlässige BLE-Reichweite zu allen Geräten haben und wird zum Single Point of Failure für die Cloud-Konnektivität. In vielen Einsätzen läuft das Gateway auf einem Raspberry Pi, einem eingebetteten Linux-Board oder einer Smartphone-App.

WiFi-Geräte verbinden sich ohne Gateway direkt mit Ihrem Cloud-Backend, was die Architektur zulasten eines höheren Stromverbrauchs vereinfacht. Für netzbetriebene Produkte, bei denen Einfachheit wichtiger ist als Batterielaufzeit — Umweltsensoren in Serverräumen, smarte Steckdosen, Industriemonitore — bleibt WiFi die pragmatische Wahl.

Überlegungen zum Antennendesign

Sowohl BLE als auch WiFi arbeiten im 2,4-GHz-Band und teilen sich dieselbe Antennenphysik. Der Unterschied liegt in Sendeleistung und Modulation: WiFi sendet mit bis zu 20 dBm, BLE typischerweise mit 0–8 dBm. Auf einer Superyacht mit Stahlschotten haben beide Protokolle gleichermaßen mit der Durchdringung zu kämpfen — die Wahl der Gateway-Platzierung und des Antennentyps (interne PCB-Leiterbahn vs. externe Stummelantenne) ist wichtiger als das Protokoll selbst.

Unser Hardware-Team berücksichtigt Antennenplatzierung und RF-Keepout-Zonen bei jedem PCB-Layout von Anfang an. Eine schlechte Antennenplatzierung gehört zu den Hauptursachen für Reichweitenprobleme im Feld — und sie lässt sich im Layout weitaus leichter beheben als nach der Montage von 10.000 Einheiten.

Entwickeln Sie ein IoT-Produkt?

FSS ist ein Full-Stack-IoT-Engineering-Team — Hardware, Firmware, Cloud und Mobile aus einer Hand.

Unsere IoT-Kompetenzen →