Drahtlose Netze durchdringen unseren Alltag so selbstverst\u00e4ndlich wie die Luft zum Atmen. Dass ein Funksignal jederzeit verf\u00fcgbar ist, gilt l\u00e4ngst als Grundrecht digitaler Existenz \u2013 doch kaum jemand wei\u00df, ob dieses Signal tats\u00e4chlich stark, stabil oder \u00fcberhaupt noch vorhanden ist. Die Leidensgeschichten sind bekannt: das Videotelefonat, das w\u00e4hrend der entscheidenden Aussage einfriert; der Smart-Home-Sensor, der nachts pl\u00f6tzlich nicht mehr reagiert; der Homeoffice-Arbeitsplatz, der nach einem Router-Neustart den Zugang zum Firmennetzwerk verweigert. Die Ursache bleibt meist unsichtbar, das Problem ungreifbar.<\/p>\n\n\n\n
Hier setzt ein bemerkenswertes Bastelprojekt an, das in seiner Einfachheit und Tiefe exemplarisch f\u00fcr die Maker-Kultur der 2020er-Jahre steht: ein WLAN-Monitor, der auf dem winzigen Mikrocontroller ESP8266 basiert, zwei definierte Netzwerke \u00fcberwacht, deren Signalst\u00e4rke permanent anzeigt und bei Unterschreitung einer Schwelle Alarm schl\u00e4gt. Was auf den ersten Blick wie eine nostalgische Spielerei mit einem mittlerweile veralteten Chip wirkt, entpuppt sich bei n\u00e4herer Betrachtung als Lehrst\u00fcck \u00fcber die grundlegenden Prinzipien drahtloser Kommunikation, \u00fcber die Kultur des Selberbauens und \u00fcber die Frage, wer eigentlich die Kontrolle \u00fcber die eigenen digitalen Lebensadern besitzt.<\/p>\n\n\n\n
Noch vor einem Jahrzehnt w\u00e4re ein solches Vorhaben undenkbar gewesen. Professionelle WLAN-Monitore geh\u00f6rten zur teuren Ausstattung von Netzwerkadministratoren oder Elektrotechnik-Laboren. Ger\u00e4te wie der Fluke Networks AirCheck<\/em> kosteten mehrere tausend Euro, waren sperrig und bedurften einer Einarbeitung, die weit \u00fcber das Wissen eines Heim\u2011IT\u2011Interessierten hinausging. Die Signalst\u00e4rke eines WLANs zu messen bedeutete, entweder in teure Spektrumanalysatoren zu investieren oder sich mit den rudiment\u00e4ren Bordmitteln des Betriebssystems zu begn\u00fcgen, die kaum mehr als einen groben Balken anzeigten.<\/p>\n\n\n\n Der Wendepunkt kam mit der Einf\u00fchrung des ESP8266 im Jahr 2014. Erstmals stand ein Mikrocontroller mit integriertem WLAN f\u00fcr weniger als f\u00fcnf Euro zur Verf\u00fcgung \u2013 eine disruptive Entwicklung, die der Maker-Bewegung eine v\u00f6llig neue Dimension er\u00f6ffnete. Pl\u00f6tzlich konnte jeder Bastler ein Ger\u00e4t mit Internetanbindung bauen, ohne sich in komplexe Funkmodul\u2011Technik einarbeiten zu m\u00fcssen. Die Community um den ESP8266 wuchs rasant; Bibliotheken wie die ESP8266WiFi<\/em>-Bibliothek machten es m\u00f6glich, nicht nur als Client auf Netzwerke zuzugreifen, sondern auch selbst als Access Point aufzutreten oder umfangreiche WLAN-Scans durchzuf\u00fchren.<\/p>\n\n\n\n Das hier vorgestellte Projekt nutzt genau diese F\u00e4higkeiten: Es kombiniert die Scan-Funktion zur kontinuierlichen \u00dcberwachung der Signalst\u00e4rke mit einem eigenen Access Point, \u00fcber den der Benutzer das Ger\u00e4t konfigurieren kann. Es ist ein Paradebeispiel daf\u00fcr, wie aus einem einfachen Chip ein komplexes Messinstrument wird \u2013 und wie sich die einstige Dom\u00e4ne der Profis in die H\u00e4nde von Hobbyisten verlagert hat.<\/p>\n\n\n\n Der zugrunde liegende Quellcode (in der Arduino-IDE f\u00fcr 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.<\/p>\n\n\n\n Besonders bemerkenswert ist der Einsatz einer CRC32-Pr\u00fcfsumme f\u00fcr die in EEPROM gespeicherten Einstellungen. Im Gegensatz zu vielen Hobby-Projekten, die die Konfiguration einfach ohne Absicherung in den nichtfl\u00fcchtigen Speicher schreiben, wird hier sichergestellt, dass besch\u00e4digte Daten erkannt und automatisch zur\u00fcckgesetzt werden. Dies ist nicht nur eine akademische \u00dcbung: Spannungsabf\u00e4lle w\u00e4hrend des Schreibens oder Alterungsprozesse des EEPROMs k\u00f6nnen durchaus zu Bitfehlern f\u00fchren. Ein System, das im Fehlerfall einfach neu startet und die Defaultwerte l\u00e4dt, ist ungleich zuverl\u00e4ssiger als eines, das mit inkonsistenten Einstellungen in einen undefinierten Zustand ger\u00e4t.<\/p>\n\n\n\n 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\u00fchrt zu dem bekannten Effekt, dass der Monitor im Webinterface nicht st\u00e4ndig 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\u00e4t konfigurieren m\u00f6chte, muss also entweder w\u00e4hrend einer Scan-Pause verbinden oder das Scan-Intervall so gro\u00df w\u00e4hlen (etwa 60 Sekunden), dass der Access Point ausreichend lang pr\u00e4sent ist. Diese L\u00f6sung ist ein sch\u00f6nes Beispiel daf\u00fcr, dass gute Embedded-Entwicklung oft in der Akzeptanz von Hardware-Limitationen besteht, nicht in deren Verleugnung.<\/p>\n\n\n\n Der Code f\u00fchrt nicht nur einen einfachen Scan nach den beiden konfigurierten Netzwerken durch, sondern analysiert gleichzeitig die Belegung der WLAN-Kan\u00e4le (1\u201313). Es wird die Anzahl der Netzwerke pro Kanal erfasst und ein Mittelwert ihrer Signalst\u00e4rke gebildet. Anschlie\u00dfend wird ein Score berechnet, der aus der Anzahl der Netzwerke und der Signalst\u00e4rke besteht, um den am wenigsten gest\u00f6rten Kanal zu ermitteln. Das Ergebnis wird auf dem Display und im Webinterface ausgegeben.<\/p>\n\n\n\n Diese Funktion ist weit mehr als eine Spielerei. WLAN-St\u00f6rungen durch Nachbarnetzwerke sind eine der Hauptursachen f\u00fcr instabile Verbindungen. Die Empfehlung eines Kanals, der wenig belegt ist, kann die Performance erheblich verbessern \u2013 und das ohne teure Analyse-Tools. In den Beispiel-Logs wurde nach einem Scan Kanal 2 als optimal ausgewiesen, w\u00e4hrend Kanal 5 sechs Netzwerke aufwies. Das entspricht exakt den Empfehlungen der Netzwerktechnik, die auf nicht \u00fcberlappenden Kan\u00e4len (1, 6, 11) beharrt.<\/p>\n\n\n\n Bei der Inbetriebnahme des Monitors zeigten sich typische Probleme, die jedem Maker vertraut sind:<\/p>\n\n\n\n Die Tabelle zeigt, dass viele vermeintliche Softwarefehler auf Hardware\u2011 oder Konfigurationsprobleme zur\u00fcckgehen. Der ESP8266 ist kein Allesk\u00f6nner; seine Pins haben spezielle Funktionen (z.\u202fB. m\u00fcssen die I2C-Pins f\u00fcr das Display genau den definierten GPIOs entsprechen). Der Code selbst ist oft weniger die Fehlerquelle als die Umgebung, in der er l\u00e4uft.<\/p>\n\n\n\n \u00dcber 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 \u00e4hnliches leisten? Die Antwort liegt in der grundlegenden Haltung der Maker-Bewegung: Selbstbestimmung und Transparenz. Eine Smartphone-App zeigt zwar die aktuelle Signalst\u00e4rke an, aber sie ist auf das Betriebssystem angewiesen, l\u00e4uft im Hintergrund und teilt oft Daten mit dem Hersteller. Ein eigenes Ger\u00e4t hingegen ist autonom, bleibt im eigenen Netzwerk und funktioniert unabh\u00e4ngig von propriet\u00e4rer Software.<\/p>\n\n\n\n Gleichzeitig ber\u00fchrt das Projekt eine ethische Dimension: Die F\u00e4higkeit, jederzeit die Signalst\u00e4rke zweier fremder Netzwerke zu \u00fcberwachen, k\u00f6nnte durchaus in die N\u00e4he von \u00dcberwachung r\u00fccken. Hier wird sie jedoch zweckgebunden eingesetzt: Der Nutzer \u00fcberwacht seine eigenen Netzwerke, um Verbindungsabbr\u00fcche zu diagnostizieren. Das ist ein Akt der Selbsterm\u00e4chtigung, nicht der Fremdkontrolle.<\/p>\n\n\n\n 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\u00fcr einfache, stromsparende IoT\u2011Projekte. Sein Erfolg hat eine ganze Generation von Entwicklern gepr\u00e4gt und gezeigt, dass komplexe Netzwerktechnik nicht das Privileg von Profis sein muss.<\/p>\n\n\n\n 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\u00e4rke gemessen wird und welche Fallstricke lauern, kann gezielt Gegenma\u00dfnahmen ergreifen \u2013 und ist nicht mehr auf die vagen Aussagen von Support-Hotlines angewiesen.<\/p>\n\n\n\n Die Zukunft solcher Monitoringsysteme liegt in der Vernetzung. Denkbar w\u00e4ren mehrere, verteilte ESP8266, die gemeinsam ein Hausnetz \u00fcberwachen, oder die Integration mit Home-Assistant, um bei schlechtem Signal automatisch einen Repeater zu aktivieren. Auch die Analyse \u00fcber l\u00e4ngere Zeitr\u00e4ume w\u00e4re wertvoll: Statt nur einen Momentwert anzuzeigen, k\u00f6nnte der Monitor Verlaufskurven zeichnen und so wiederkehrende St\u00f6rungen identifizieren.<\/p>\n\n\n\n Doch auch in seiner aktuellen Form ist der WLAN-Monitor ein beeindruckendes Beispiel daf\u00fcr, wie ein handels\u00fcblicher Mikrocontroller mit wenigen Euro Materialkosten und einem durchdachten Programm zu einem n\u00fctzlichen Werkzeug werden kann \u2013 f\u00fcr alle, die endlich wissen wollen, was in ihren unsichtbaren Netzen wirklich geschieht.<\/p>\n\n\n\n cpp<\/p>\n\n\n\n (Hinweis: Aus Gr\u00fcnden der \u00dcbersichtlichkeit wurden Teile des Codes (z.\u202fB. die Webseiten-Generierung, die vollst\u00e4ndige EEPROM-Logik und die Scan-Funktionen) hier nur angedeutet. Der vollst\u00e4ndige Quellcode ist unter [GitHub-Link] verf\u00fcgbar oder kann beim Autor angefordert werden.)<\/em><\/p>\n\n\n\n ESP8266, WLAN-Monitoring, Maker-Kultur, Signalanalyse, Elektrotechnik, Open-Source-Hardware, Netzwerksicherheit<\/p>\n","protected":false},"excerpt":{"rendered":" Einleitung: Die Tyrannei der Unsichtbarkeit Drahtlose Netze durchdringen unseren Alltag so selbstverst\u00e4ndlich wie die Luft zum Atmen. Dass ein Funksignal jederzeit verf\u00fcgbar ist, gilt l\u00e4ngst als Grundrecht digitaler Existenz \u2013 doch kaum jemand wei\u00df, ob dieses Signal tats\u00e4chlich stark, stabil oder \u00fcberhaupt noch vorhanden ist. Die Leidensgeschichten sind bekannt: das Videotelefonat, das w\u00e4hrend der entscheidenden […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[42,45,26],"tags":[2237,4296,4872,5108,6340,7814],"class_list":["post-2685","post","type-post","status-publish","format-standard","hentry","category-elektrotechnik","category-hardware-im-test","category-mit-den-handen","tag-esp8266","tag-maker-kultur","tag-netzwerksicherheit","tag-open-source-hardware","tag-signalanalyse","tag-wlan-monitoring"],"_links":{"self":[{"href":"https:\/\/technodidact.de\/en\/wp-json\/wp\/v2\/posts\/2685","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/technodidact.de\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/technodidact.de\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/technodidact.de\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/technodidact.de\/en\/wp-json\/wp\/v2\/comments?post=2685"}],"version-history":[{"count":0,"href":"https:\/\/technodidact.de\/en\/wp-json\/wp\/v2\/posts\/2685\/revisions"}],"wp:attachment":[{"href":"https:\/\/technodidact.de\/en\/wp-json\/wp\/v2\/media?parent=2685"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/technodidact.de\/en\/wp-json\/wp\/v2\/categories?post=2685"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/technodidact.de\/en\/wp-json\/wp\/v2\/tags?post=2685"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}Technische Tiefe: Der Code als lebendiges Dokument<\/h3>\n\n\n\n
Datenintegrit\u00e4t durch CRC32<\/h4>\n\n\n\n
Fallstricke der WLAN-Messtechnik<\/h4>\n\n\n\n
Kanalanalyse als intelligenter Mehrwert<\/h4>\n\n\n\n
Praxis und Fallstricke: Die Realit\u00e4t der Hardware<\/h3>\n\n\n\n
Problem<\/th> Ursache<\/th> L\u00f6sung<\/th><\/tr><\/thead> Access Point wird nicht angezeigt<\/td> Scan-Intervall zu kurz, AP nur in Pausen sichtbar<\/td> Intervall auf >30 s erh\u00f6hen oder w\u00e4hrend Scan-Pause verbinden<\/td><\/tr> Keine serielle Ausgabe<\/td> Falscher USB-Treiber (CH340\/CP2102)<\/td> Treiber aktualisieren, anderen USB-Port nutzen<\/td><\/tr> Display bleibt dunkel<\/td> I2C-Adresse oder Pinbelegung falsch<\/td> Adresse pr\u00fcfen (meist 0x3C oder 0x3D), Pins auf D5 (SCL) \/ D6 (SDA) legen<\/td><\/tr> Netzwerke werden nicht erkannt<\/td> Case\u2011sensitiver Vergleich im Code<\/td> Auf equalsIgnoreCase()<\/code> umgestellt, damit Gro\u00df-\/Kleinschreibung egal ist<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\nKulturelle Einordnung: Die Ethik des Heim-Monitorings<\/h3>\n\n\n\n
Fazit und Ausblick: Wohin steuert die Maker-Bewegung?<\/h3>\n\n\n\n
\n\n\n\nAnhang: Vollst\u00e4ndiger Quellcode f\u00fcr den ESP8266-WLAN-Monitor<\/h2>\n\n\n\n
#include <U8g2lib.h>\n#include <Wire.h>\n#include <ESP8266WiFi.h>\n#include <ESP8266WebServer.h>\n#include <EEPROM.h>\n\n\/\/ OLED Display (I2C) mit konfigurierbaren Pins<\/em>\n#define OLED_SCL 14 \/\/ D5 auf NodeMCU<\/em>\n#define OLED_SDA 12 \/\/ D6 auf NodeMCU<\/em>\n#define OLED_RESET U8X8_PIN_NONE\nU8G2_SSD1306_128X64_NONAME_F_SW_I2C u8g2(U8G2_R0, OLED_SCL, OLED_SDA, OLED_RESET);\n\n\/\/ Web Server mit Authentifizierung<\/em>\nESP8266WebServer server(80);\nString www_username = \"admin\";\nString www_password = \"monitor123\"; \/\/ Bitte \u00e4ndern!<\/em>\n\n\/\/ EEPROM Adressen<\/em>\n#define EEPROM_SIZE 512\n#define ADDR_SSID1 0\n#define ADDR_SSID2 32\n#define ADDR_SCAN_INT 64\n#define ADDR_THRESHOLD 68\n#define ADDR_AP_PASSWORD 72\n#define ADDR_CRC 124\n#define ADDR_WEB_PASSWORD 128\n#define ADDR_CONFIG_VERSION 156\n\n#define CONFIG_VERSION 2\n\n\/\/ Standardwerte<\/em>\nString network1 = \"FRITZI\";\nString network2 = \"Smu\";\nint scanInterval = 10;\nint alarmThreshold = -80;\nString apPassword = \"wlanmonitor\";\nString webPassword = \"monitor123\";\n\n\/\/ Status<\/em>\nint rssi1 = -100;\nint rssi2 = -100;\nbool found1 = false;\nbool found2 = false;\nunsigned long lastScan = 0;\nbool alarmActive = false;\nint scanCount = 0;\nint bestChannel = 1;\nunsigned long lastAPCheck = 0;\nbool apActive = true;\n\n\/\/ Animation<\/em>\nint animPos = 0;\nunsigned long lastAnimUpdate = 0;\n\n\/\/ Signalqualit\u00e4t mit erweiterter Skala<\/em>\nString getSignalQuality(int rssi) {\n if (rssi >= -50) return \"AUSGEZEICHNET\";\n if (rssi >= -60) return \"SEHR GUT\";\n if (rssi >= -70) return \"GUT\";\n if (rssi >= -80) return \"MITTEL\";\n if (rssi >= -90) return \"SCHLECHT\";\n if (rssi >= -100) return \"SEHR SCHLECHT\";\n return \"KEIN SIGNAL\";\n}\n\nint getSignalPercentage(int rssi) {\n if (rssi >= -50) return 100;\n if (rssi <= -100) return 0;\n return map(rssi, -100, -50, 0, 100);\n}\n\n\/\/ CRC32 Berechnung<\/em>\nuint32_t calculateCRC32(const uint8_t *data, size_t length) {\n uint32_t crc = 0xffffffff;\n while (length--) {\n uint8_t c = *data++;\n for (uint32_t i = 0x80; i > 0; i >>= 1) {\n bool bit = crc & 0x80000000;\n if (c & i) bit = !bit;\n crc <<= 1;\n if (bit) crc ^= 0x04c11db7;\n }\n }\n return crc;\n}\n\n\/\/ EEPROM Reset<\/em>\nvoid resetEEPROM() {\n Serial.println(\"EEPROM wird zur\u00fcckgesetzt...\");\n EEPROM.begin(EEPROM_SIZE);\n for (int i = 0; i < EEPROM_SIZE; i++) EEPROM.write(i, 0);\n String default1 = \"FRITZI\", default2 = \"Smu\", defaultAPPass = \"wlanmonitor\", defaultWebPass = \"monitor123\";\n for (int i = 0; i < 32; i++) {\n EEPROM.write(ADDR_SSID1 + i, i < default1.length() ? default1[i] : 0);\n EEPROM.write(ADDR_SSID2 + i, i < default2.length() ? default2[i] : 0);\n EEPROM.write(ADDR_AP_PASSWORD + i, i < defaultAPPass.length() ? defaultAPPass[i] : 0);\n EEPROM.write(ADDR_WEB_PASSWORD + i, i < defaultWebPass.length() ? defaultWebPass[i] : 0);\n }\n EEPROM.put(ADDR_SCAN_INT, 10);\n EEPROM.put(ADDR_THRESHOLD, -80);\n EEPROM.put(ADDR_CONFIG_VERSION, CONFIG_VERSION);\n uint32_t crc = calculateCRC32(EEPROM.getDataPtr(), ADDR_CRC - 4);\n EEPROM.put(ADDR_CRC, crc);\n EEPROM.commit();\n EEPROM.end();\n network1 = default1; network2 = default2;\n apPassword = defaultAPPass; webPassword = defaultWebPass;\n scanInterval = 10; alarmThreshold = -80;\n www_password = defaultWebPass;\n Serial.println(\"EEPROM zur\u00fcckgesetzt auf Standardwerte\");\n}\n\n\/\/ EEPROM laden mit CRC-Validierung<\/em>\nbool loadSettings() {\n EEPROM.begin(EEPROM_SIZE);\n int savedVersion;\n EEPROM.get(ADDR_CONFIG_VERSION, savedVersion);\n if (savedVersion != CONFIG_VERSION) {\n Serial.println(\"Alte Konfigurationsversion, setze zur\u00fcck\");\n EEPROM.end(); resetEEPROM(); return true;\n }\n uint32_t savedCRC, calculatedCRC = calculateCRC32(EEPROM.getDataPtr(), ADDR_CRC - 4);\n EEPROM.get(ADDR_CRC, savedCRC);\n if (savedCRC != calculatedCRC) {\n Serial.println(\"CRC-Fehler! EEPROM-Daten korrupt.\");\n EEPROM.end(); return false;\n }\n \/\/ Netzwerk 1<\/em>\n network1 = \"\";\n for (int i = 0; i < 32; i++) {\n char c = EEPROM.read(ADDR_SSID1 + i);\n if (c == 0) break;\n if (c < 32 || c > 126) { network1 = \"FRITZI\"; break; }\n network1 += c;\n }\n \/\/ Netzwerk 2, AP Passwort, Web Passwort analog...<\/em>\n \/\/ (Aus Platzgr\u00fcnden hier gek\u00fcrzt; vollst\u00e4ndige Logik im Original)<\/em>\n \/\/ ...<\/em>\n EEPROM.end();\n www_password = webPassword;\n return true;\n}\n\n\/\/ Weitere Funktionen (saveSettings, analyzeChannels, scanWifi, updateDisplay, etc.)<\/em>\n\/\/ sind im vollst\u00e4ndigen Code enthalten und werden hier nicht nochmals ausgef\u00fchrt.<\/em>\n\nvoid setup() {\n Serial.begin(115200);\n u8g2.begin();\n loadSettings();\n WiFi.mode(WIFI_AP);\n String apName = \"WLAN-Monitor-\" + String(ESP.getChipId());\n if (apPassword.length() > 0) WiFi.softAP(apName.c_str(), apPassword.c_str());\n else WiFi.softAP(apName.c_str());\n server.on(\"\/\", handleRoot);\n server.on(\"\/save\", handleSave);\n server.on(\"\/scan\", handleScan);\n server.on(\"\/reset\", handleReset);\n server.on(\"\/reboot\", handleReboot);\n server.begin();\n scanWifi();\n updateDisplay();\n lastScan = millis();\n}\n\nvoid loop() {\n server.handleClient();\n if (millis() - lastScan >= scanInterval * 1000UL) {\n scanWifi();\n updateDisplay();\n lastScan = millis();\n }\n delay(100);\n}<\/pre>\n\n\n\n
\n\n\n\nQuellen<\/h2>\n\n\n\n
\n
\n\n\n\nKategorisierung<\/h2>\n\n\n\n
\n
Schlagworte<\/h2>\n\n\n\n