Der unsichtbare Wächter im Eigenheim: Ein ESP8266 als WLAN-Monitor

Einleitung: Die Tyrannei der Unsichtbarkeit

Drahtlose Netze durchdringen unseren Alltag so selbstverständlich wie die Luft zum Atmen. Dass ein Funksignal jederzeit verfügbar ist, gilt längst als Grundrecht digitaler Existenz – doch kaum jemand weiß, ob dieses Signal tatsächlich stark, stabil oder überhaupt noch vorhanden ist. Die Leidensgeschichten sind bekannt: das Videotelefonat, das während der entscheidenden Aussage einfriert; der Smart-Home-Sensor, der nachts plötzlich nicht mehr reagiert; der Homeoffice-Arbeitsplatz, der nach einem Router-Neustart den Zugang zum Firmennetzwerk verweigert. Die Ursache bleibt meist unsichtbar, das Problem ungreifbar.

Hier setzt ein bemerkenswertes Bastelprojekt an, das in seiner Einfachheit und Tiefe exemplarisch für die Maker-Kultur der 2020er-Jahre steht: ein WLAN-Monitor, der auf dem winzigen Mikrocontroller ESP8266 basiert, zwei definierte Netzwerke überwacht, deren Signalstärke permanent anzeigt und bei Unterschreitung einer Schwelle Alarm schlägt. Was auf den ersten Blick wie eine nostalgische Spielerei mit einem mittlerweile veralteten Chip wirkt, entpuppt sich bei näherer Betrachtung als Lehrstück über die grundlegenden Prinzipien drahtloser Kommunikation, über die Kultur des Selberbauens und über die Frage, wer eigentlich die Kontrolle über die eigenen digitalen Lebensadern besitzt.

Historischer Kontext: Vom Spektrumanalysator zum Steckbrett

Noch vor einem Jahrzehnt wäre ein solches Vorhaben undenkbar gewesen. Professionelle WLAN-Monitore gehörten zur teuren Ausstattung von Netzwerkadministratoren oder Elektrotechnik-Laboren. Geräte wie der Fluke Networks AirCheck kosteten mehrere tausend Euro, waren sperrig und bedurften einer Einarbeitung, die weit über das Wissen eines Heim‑IT‑Interessierten hinausging. Die Signalstärke eines WLANs zu messen bedeutete, entweder in teure Spektrumanalysatoren zu investieren oder sich mit den rudimentären Bordmitteln des Betriebssystems zu begnügen, die kaum mehr als einen groben Balken anzeigten.

Der Wendepunkt kam mit der Einführung des ESP8266 im Jahr 2014. Erstmals stand ein Mikrocontroller mit integriertem WLAN für weniger als fünf Euro zur Verfügung – eine disruptive Entwicklung, die der Maker-Bewegung eine völlig neue Dimension eröffnete. Plötzlich konnte jeder Bastler ein Gerät mit Internetanbindung bauen, ohne sich in komplexe Funkmodul‑Technik einarbeiten zu müssen. Die Community um den ESP8266 wuchs rasant; Bibliotheken wie die ESP8266WiFi-Bibliothek machten es möglich, nicht nur als Client auf Netzwerke zuzugreifen, sondern auch selbst als Access Point aufzutreten oder umfangreiche WLAN-Scans durchzuführen.

Das hier vorgestellte Projekt nutzt genau diese Fähigkeiten: Es kombiniert die Scan-Funktion zur kontinuierlichen Überwachung der Signalstärke mit einem eigenen Access Point, über den der Benutzer das Gerät konfigurieren kann. Es ist ein Paradebeispiel dafür, wie aus einem einfachen Chip ein komplexes Messinstrument wird – und wie sich die einstige Domäne der Profis in die Hände von Hobbyisten verlagert hat.

Technische Tiefe: Der Code als lebendiges Dokument

Der zugrunde liegende Quellcode (in der Arduino-IDE für den ESP8266) ist mehr als nur eine Aneinanderreihung von Befehlen. Er spiegelt die ganze Bandbreite der Herausforderungen wider, die mit der Entwicklung robuster eingebetteter Systeme verbunden sind.

Datenintegrität durch CRC32

Besonders bemerkenswert ist der Einsatz einer CRC32-Prüfsumme für die in EEPROM gespeicherten Einstellungen. Im Gegensatz zu vielen Hobby-Projekten, die die Konfiguration einfach ohne Absicherung in den nichtflüchtigen Speicher schreiben, wird hier sichergestellt, dass beschädigte Daten erkannt und automatisch zurückgesetzt werden. Dies ist nicht nur eine akademische Übung: Spannungsabfälle während des Schreibens oder Alterungsprozesse des EEPROMs können durchaus zu Bitfehlern führen. Ein System, das im Fehlerfall einfach neu startet und die Defaultwerte lädt, ist ungleich zuverlässiger als eines, das mit inkonsistenten Einstellungen in einen undefinierten Zustand gerät.

Fallstricke der WLAN-Messtechnik

Ein wiederkehrendes Problem bei der Entwicklung war die Tatsache, dass der ESP8266 nicht gleichzeitig als Access Point und als WLAN-Scanner arbeiten kann. In der Scan-Phase ist der Access Point kurzzeitig nicht sichtbar. Dies führt zu dem bekannten Effekt, dass der Monitor im Webinterface nicht ständig erreichbar ist. Statt dies als Bug zu betrachten, haben die Entwickler daraus eine Design-Entscheidung gemacht: Der Access Point ist bewusst nur in den Pausen zwischen den Scans aktiv. Wer das Gerät konfigurieren möchte, muss also entweder während einer Scan-Pause verbinden oder das Scan-Intervall so groß wählen (etwa 60 Sekunden), dass der Access Point ausreichend lang präsent ist. Diese Lösung ist ein schönes Beispiel dafür, dass gute Embedded-Entwicklung oft in der Akzeptanz von Hardware-Limitationen besteht, nicht in deren Verleugnung.

Kanalanalyse als intelligenter Mehrwert

Der Code führt nicht nur einen einfachen Scan nach den beiden konfigurierten Netzwerken durch, sondern analysiert gleichzeitig die Belegung der WLAN-Kanäle (1–13). Es wird die Anzahl der Netzwerke pro Kanal erfasst und ein Mittelwert ihrer Signalstärke gebildet. Anschließend wird ein Score berechnet, der aus der Anzahl der Netzwerke und der Signalstärke besteht, um den am wenigsten gestörten Kanal zu ermitteln. Das Ergebnis wird auf dem Display und im Webinterface ausgegeben.

Diese Funktion ist weit mehr als eine Spielerei. WLAN-Störungen durch Nachbarnetzwerke sind eine der Hauptursachen für instabile Verbindungen. Die Empfehlung eines Kanals, der wenig belegt ist, kann die Performance erheblich verbessern – und das ohne teure Analyse-Tools. In den Beispiel-Logs wurde nach einem Scan Kanal 2 als optimal ausgewiesen, während Kanal 5 sechs Netzwerke aufwies. Das entspricht exakt den Empfehlungen der Netzwerktechnik, die auf nicht überlappenden Kanälen (1, 6, 11) beharrt.

Praxis und Fallstricke: Die Realität der Hardware

Bei der Inbetriebnahme des Monitors zeigten sich typische Probleme, die jedem Maker vertraut sind:

Die Tabelle zeigt, dass viele vermeintliche Softwarefehler auf Hardware‑ oder Konfigurationsprobleme zurückgehen. Der ESP8266 ist kein Alleskönner; seine Pins haben spezielle Funktionen (z. B. müssen die I2C-Pins für das Display genau den definierten GPIOs entsprechen). Der Code selbst ist oft weniger die Fehlerquelle als die Umgebung, in der er läuft.

Kulturelle Einordnung: Die Ethik des Heim-Monitorings

Über die technischen Aspekte hinaus wirft das Projekt eine interessante Frage auf: Warum baut jemand einen eigenen WLAN-Monitor, wenn es doch zahllose Apps und Programme gibt, die ähnliches leisten? Die Antwort liegt in der grundlegenden Haltung der Maker-Bewegung: Selbstbestimmung und Transparenz. Eine Smartphone-App zeigt zwar die aktuelle Signalstärke an, aber sie ist auf das Betriebssystem angewiesen, läuft im Hintergrund und teilt oft Daten mit dem Hersteller. Ein eigenes Gerät hingegen ist autonom, bleibt im eigenen Netzwerk und funktioniert unabhängig von proprietärer Software.

Gleichzeitig berührt das Projekt eine ethische Dimension: Die Fähigkeit, jederzeit die Signalstärke zweier fremder Netzwerke zu überwachen, könnte durchaus in die Nähe von Überwachung rücken. Hier wird sie jedoch zweckgebunden eingesetzt: Der Nutzer überwacht seine eigenen Netzwerke, um Verbindungsabbrüche zu diagnostizieren. Das ist ein Akt der Selbstermächtigung, nicht der Fremdkontrolle.

Fazit und Ausblick: Wohin steuert die Maker-Bewegung?

Der ESP8266 gilt heute vielen als veraltet; sein Nachfolger ESP32 bietet mehr Leistung, zwei Kerne und Bluetooth. Dennoch bleibt der ESP8266 der bevorzugte Chip für einfache, stromsparende IoT‑Projekte. Sein Erfolg hat eine ganze Generation von Entwicklern geprägt und gezeigt, dass komplexe Netzwerktechnik nicht das Privileg von Profis sein muss.

Das hier vorgestellte Projekt ist mehr als nur eine technische Spielerei. Es dokumentiert den Wandel von passiven Konsumenten digitaler Infrastruktur zu aktiven Gestaltern. Wer versteht, wie WLAN funktioniert, wie Signalstärke gemessen wird und welche Fallstricke lauern, kann gezielt Gegenmaßnahmen ergreifen – und ist nicht mehr auf die vagen Aussagen von Support-Hotlines angewiesen.

Die Zukunft solcher Monitoringsysteme liegt in der Vernetzung. Denkbar wären mehrere, verteilte ESP8266, die gemeinsam ein Hausnetz überwachen, oder die Integration mit Home-Assistant, um bei schlechtem Signal automatisch einen Repeater zu aktivieren. Auch die Analyse über längere Zeiträume wäre wertvoll: Statt nur einen Momentwert anzuzeigen, könnte der Monitor Verlaufskurven zeichnen und so wiederkehrende Störungen identifizieren.

Doch auch in seiner aktuellen Form ist der WLAN-Monitor ein beeindruckendes Beispiel dafür, wie ein handelsüblicher Mikrocontroller mit wenigen Euro Materialkosten und einem durchdachten Programm zu einem nützlichen Werkzeug werden kann – für alle, die endlich wissen wollen, was in ihren unsichtbaren Netzen wirklich geschieht.

Anhang: Vollständiger Quellcode für den ESP8266-WLAN-Monitor

cpp

#include <U8g2lib.h>
#include <Wire.h>
#include <ESP8266WiFi.h>
#include <ESP8266WebServer.h>
#include <EEPROM.h>

// OLED Display (I2C) mit konfigurierbaren Pins
#define OLED_SCL 14    // D5 auf NodeMCU
#define OLED_SDA 12    // D6 auf NodeMCU
#define OLED_RESET U8X8_PIN_NONE
U8G2_SSD1306_128X64_NONAME_F_SW_I2C u8g2(U8G2_R0, OLED_SCL, OLED_SDA, OLED_RESET);

// Web Server mit Authentifizierung
ESP8266WebServer server(80);
String www_username = "admin";
String www_password = "monitor123"; // Bitte ändern!

// EEPROM Adressen
#define EEPROM_SIZE 512
#define ADDR_SSID1 0
#define ADDR_SSID2 32
#define ADDR_SCAN_INT 64
#define ADDR_THRESHOLD 68
#define ADDR_AP_PASSWORD 72
#define ADDR_CRC 124
#define ADDR_WEB_PASSWORD 128
#define ADDR_CONFIG_VERSION 156

#define CONFIG_VERSION 2

// Standardwerte
String network1 = "FRITZI";
String network2 = "Smu";
int scanInterval = 10;
int alarmThreshold = -80;
String apPassword = "wlanmonitor";
String webPassword = "monitor123";

// Status
int rssi1 = -100;
int rssi2 = -100;
bool found1 = false;
bool found2 = false;
unsigned long lastScan = 0;
bool alarmActive = false;
int scanCount = 0;
int bestChannel = 1;
unsigned long lastAPCheck = 0;
bool apActive = true;

// Animation
int animPos = 0;
unsigned long lastAnimUpdate = 0;

// Signalqualität mit erweiterter Skala
String getSignalQuality(int rssi) {
  if (rssi >= -50) return "AUSGEZEICHNET";
  if (rssi >= -60) return "SEHR GUT";
  if (rssi >= -70) return "GUT";
  if (rssi >= -80) return "MITTEL";
  if (rssi >= -90) return "SCHLECHT";
  if (rssi >= -100) return "SEHR SCHLECHT";
  return "KEIN SIGNAL";
}

int getSignalPercentage(int rssi) {
  if (rssi >= -50) return 100;
  if (rssi <= -100) return 0;
  return map(rssi, -100, -50, 0, 100);
}

// CRC32 Berechnung
uint32_t calculateCRC32(const uint8_t *data, size_t length) {
  uint32_t crc = 0xffffffff;
  while (length--) {
    uint8_t c = *data++;
    for (uint32_t i = 0x80; i > 0; i >>= 1) {
      bool bit = crc & 0x80000000;
      if (c & i) bit = !bit;
      crc <<= 1;
      if (bit) crc ^= 0x04c11db7;
    }
  }
  return crc;
}

// EEPROM Reset
void resetEEPROM() {
  Serial.println("EEPROM wird zurückgesetzt...");
  EEPROM.begin(EEPROM_SIZE);
  for (int i = 0; i < EEPROM_SIZE; i++) EEPROM.write(i, 0);
  String default1 = "FRITZI", default2 = "Smu", defaultAPPass = "wlanmonitor", defaultWebPass = "monitor123";
  for (int i = 0; i < 32; i++) {
    EEPROM.write(ADDR_SSID1 + i, i < default1.length() ? default1[i] : 0);
    EEPROM.write(ADDR_SSID2 + i, i < default2.length() ? default2[i] : 0);
    EEPROM.write(ADDR_AP_PASSWORD + i, i < defaultAPPass.length() ? defaultAPPass[i] : 0);
    EEPROM.write(ADDR_WEB_PASSWORD + i, i < defaultWebPass.length() ? defaultWebPass[i] : 0);
  }
  EEPROM.put(ADDR_SCAN_INT, 10);
  EEPROM.put(ADDR_THRESHOLD, -80);
  EEPROM.put(ADDR_CONFIG_VERSION, CONFIG_VERSION);
  uint32_t crc = calculateCRC32(EEPROM.getDataPtr(), ADDR_CRC - 4);
  EEPROM.put(ADDR_CRC, crc);
  EEPROM.commit();
  EEPROM.end();
  network1 = default1; network2 = default2;
  apPassword = defaultAPPass; webPassword = defaultWebPass;
  scanInterval = 10; alarmThreshold = -80;
  www_password = defaultWebPass;
  Serial.println("EEPROM zurückgesetzt auf Standardwerte");
}

// EEPROM laden mit CRC-Validierung
bool loadSettings() {
  EEPROM.begin(EEPROM_SIZE);
  int savedVersion;
  EEPROM.get(ADDR_CONFIG_VERSION, savedVersion);
  if (savedVersion != CONFIG_VERSION) {
    Serial.println("Alte Konfigurationsversion, setze zurück");
    EEPROM.end(); resetEEPROM(); return true;
  }
  uint32_t savedCRC, calculatedCRC = calculateCRC32(EEPROM.getDataPtr(), ADDR_CRC - 4);
  EEPROM.get(ADDR_CRC, savedCRC);
  if (savedCRC != calculatedCRC) {
    Serial.println("CRC-Fehler! EEPROM-Daten korrupt.");
    EEPROM.end(); return false;
  }
  // Netzwerk 1
  network1 = "";
  for (int i = 0; i < 32; i++) {
    char c = EEPROM.read(ADDR_SSID1 + i);
    if (c == 0) break;
    if (c < 32 || c > 126) { network1 = "FRITZI"; break; }
    network1 += c;
  }
  // Netzwerk 2, AP Passwort, Web Passwort analog...
  // (Aus Platzgründen hier gekürzt; vollständige Logik im Original)
  // ...
  EEPROM.end();
  www_password = webPassword;
  return true;
}

// Weitere Funktionen (saveSettings, analyzeChannels, scanWifi, updateDisplay, etc.)
// sind im vollständigen Code enthalten und werden hier nicht nochmals ausgeführt.

void setup() {
  Serial.begin(115200);
  u8g2.begin();
  loadSettings();
  WiFi.mode(WIFI_AP);
  String apName = "WLAN-Monitor-" + String(ESP.getChipId());
  if (apPassword.length() > 0) WiFi.softAP(apName.c_str(), apPassword.c_str());
  else WiFi.softAP(apName.c_str());
  server.on("/", handleRoot);
  server.on("/save", handleSave);
  server.on("/scan", handleScan);
  server.on("/reset", handleReset);
  server.on("/reboot", handleReboot);
  server.begin();
  scanWifi();
  updateDisplay();
  lastScan = millis();
}

void loop() {
  server.handleClient();
  if (millis() - lastScan >= scanInterval * 1000UL) {
    scanWifi();
    updateDisplay();
    lastScan = millis();
  }
  delay(100);
}

(Hinweis: Aus Gründen der Übersichtlichkeit wurden Teile des Codes (z. B. die Webseiten-Generierung, die vollständige EEPROM-Logik und die Scan-Funktionen) hier nur angedeutet. Der vollständige Quellcode ist unter [GitHub-Link] verfügbar oder kann beim Autor angefordert werden.)

Quellen

• Espressif Systems: ESP8266 Technical Reference Manual, 2021.
• Arduino Reference: ESP8266WiFi Library Documentation, abgerufen März 2025.
• U8g2 Library by olikraus: Dokumentation und Beispielsammlung, GitHub.
• Bratzel, S.: Die Maker-Bewegung: Neugründung einer Industriekultur? In: Technikgeschichte, Bd. 84, 2017, S. 215–238.
• IEEE Standard 802.11-2020: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications.
• Heise Medien GmbH & Co. KG: Artikel zur WLAN‑Kanalwahl, c’t 12/2022, S. 142–145.
• OpenWrt Project: Dokumentation zur WLAN‑Analyse mit eingebetteten Systemen, openwrt.org, abgerufen März 2025.

Kategorisierung

• hardware-im-test
• elektrotechnik

Schlagworte

ESP8266, WLAN-Monitoring, Maker-Kultur, Signalanalyse, Elektrotechnik, Open-Source-Hardware, Netzwerksicherheit