Wer im Mehrfamilienhaus wohnt, hat ein Problem: Für eine eigene Wetterstation auf dem Dach fehlt der Platz, die Erlaubnis und oft auch die Aussicht. Aber wenn der Nachbar gegenüber sein Gartenhaus bereits mit einer Funkwetterstation bestückt hat, liegt die Datenspur förmlich in der Luft. Man muss sie nur einsammeln.

Was funkt, kann man auch empfangen

Die meisten handelsüblichen Wetterstationen - Bresser 5-in-1, 7-in-1, Davis, Fine Offset, Ecowitt - senden ihre Messdaten im ISM-Band auf 433,92 MHz (Europa auch 868 MHz). Das sind lizenzfreie Frequenzen, und das Signal ist nicht verschlüsselt. Die Station des Nachbarn sendet ohnehin in alle Richtungen, und wer ein kompatibles Funkmodul betreibt, empfängt genau die gleichen Telegramme wie das hübsche Display im Wohnzimmer des Nachbarn. Rechtlich bewegt man sich dabei im Rahmen: es geht um den Empfang von Funk, der ohnehin in der Wohnung ankommt, nicht um das Eindringen in fremde Systeme.

Die Werkzeuge dafür sind erstaunlich günstig und gut dokumentiert. Die Open-Source-Software rtl_433 dekodiert über 200 verschiedene Funkprotokolle - von Wetterstationen über Temperaturfühler bis hin zu Türschlössern. Was man braucht ist ein Empfänger und ein bisschen Konfigurationsarbeit.

Der ESP32 als Funkempfänger

Es gibt zwei gängige Ansätze, um die Daten ins eigene Smart Home zu bringen. Der erste ist der klassische Weg über einen RTL-SDR-Dongle am Raspberry Pi: ein USB-Stick für rund 15 Euro, der als Software Defined Radio arbeitet und das gesamte Frequenzband aufzeichnet. Der Nachteil: man braucht einen dedizierten Pi oder einen Server mit USB-Anschluss.

Der elegantere Weg läuft über einen ESP32 mit angeflanschtem Funkmodul. Zwei Hardware-Kombinationen haben sich bewährt:

- ESP32 + CC1101: Das CC1101-Modul von Texas Instruments ist ein Sub-GHz-Funktransceiver, der auf 300 bis 928 MHz arbeiten kann. Es wird per SPI an den ESP32 angeschlossen und kostet um die 2 Euro. In Kombination mit der Bibliothek rtl_433_ESP für ESPHome dekodiert der ESP32 die Funktelegramme direkt und veröffentlicht sie per MQTT im Netzwerk. Der Anschluss erfordert sechs Drähte (VCC, GND, SCK, MOSI, MISO, CS) plus ein GPIO für den GDO0-Pin. Lötarbeit ist nötig, weil das CC1101-Board 2-mm-Pinraster hat, die nicht auf ein Breadboard passen.

- Heltec WiFi LoRa 32 V2/V2.1: Ein ESP32-Board mit integriertem SX1276/Sub-GHz-Funkchip. Kein Löten, kein separates Funkmodul. Die Antenne ist auf dem Board, der Versand per USB-Kabel. Das ist die schmerzfreiste Lösung für alle, die nicht löten wollen. Das Board kostet um die 15 Euro und wird ebenfalls über rtl_433_ESP in ESPHome eingebunden.

Beide Varianten unterstützen 433 MHz und 868 MHz - wichtig, weil europäische Stationen wie die Bresser 7-in-1 oft auf 868,30 MHz senden.

Die Software-Seite: ESPHome und rtl_433_ESP

ESPHome ist der De-facto-Standard, um ESP32-Geräte in Home Assistant einzubinden. Für den Funkempfänger braucht man die rtl_433_ESP-Komponente, die direkt in der ESPHome-Konfiguration aktiviert wird. Die Konfiguration gibt an, auf welcher Frequenz empfangen wird (433.92 MHz oder 868.30 MHz) und welches Protokoll dekodiert werden soll. Wer die Protokollnummer seiner Station kennt - rtl_433 listet über 200 - pinnt sie mit dem `-R`-Parameter fest und bekommt stabilere Empfangswerte ohne Fehlalarme vom Nachbar-Garagentor.

Die dekodierten Messwerte landen per MQTT im Home Assistant. Dort werden sie automatisch als Sensoren erkannt - Temperatur, Luftfeuchtigkeit, Windgeschwindigkeit, Regenmenge, UV-Index, je nach Station. Ab da gelten die Daten wie jede andere Sensorquelle: Dashboard-Karten, Automatisierungen, Historie. „Wenn die Windgeschwindigkeit über 50 km/h steigt, schließe die Markise" ist dann eine ganz normale Automatisierung.

Reichweite und Antenne

Die Reichweite zwischen Station und Empfänger hängt von der Bauweise ab. Im Mehrfamilienhaus sind 20 bis 50 Meter durch Mauern realistisch, im Freien deutlich mehr. Eine einfache 433-MHz-Stabantenne (17,3 cm Viertelwellenlänge) oder eine 868-MHz-Antenne (8,6 cm) direkt am Modul verbessert den Empfang spürbar. Wer das CC1101-Modul mit der winzigen Spiralantenne betreibt, die mitgeliefert wird, verschenkt Reichweite. Ein kurzes Stück Draht als Monopolantenne, gelötet oder gesteckt, kostet Cent und wirkt Wunder.

Was man noch braucht

Die Einkaufsliste ist kurz: ein ESP32-Board (5 Euro), ein CC1101-Modul (2 Euro) oder ein Heltec-Board (15 Euro) samt Antenne, ein USB-Netzteil und ein paar Drähte. Auf der Software-Seite reichen ESPHome, ein MQTT-Broker (Mosquitto, oft schon im Home-Assistant-Setup enthalten) und die rtl_433_ESP-Konfiguration. Wer die Station des Nachbarn erst einmal nur belauschen will, bevor er sie ins Dashboard hängt, kann rtl_433 auf dem ESP32 im Log-Modus starten und sieht alle empfangenen Telegramme live auf der Seriellen Konsole.

Die Kurve vom „ich würde gern wissen, wie das Wetter draußen ist" bis zur funktionsfähigen Wetteranzeige im Home Assistant ist kurz. Und der Nachbar muss es nicht einmal merken.

Es beginnt immer harmlos. Jemand tippt in ein Chatfenster: „Schreib mir einen LabVIEW-Code für eine Messwerterfassung mit Trigger und Filter." Die künstliche Intelligenz antwortet freundlich, umfassend, selbstbewusst - und liefert etwas, das aussieht wie ein Blockdiagramm, sich anfühlt wie ein Blockdiagramm und dennoch mit großer Wahrscheinlichkeit nicht funktioniert. Der Kollege, der es ausprobiert hat, sitzt jetzt seit drei Stunden vor dem Bildschirm und verschiebt Drähte. Er hätte den Code von Hand schneller geschrieben.

Die Fassade sieht gut aus - der Kern ist leer

Das Problem ist nicht, dass KI dumm wäre. Das Problem ist, dass sie überzeugend aussieht. Ein Sprachmodell, das LabVIEW-Code erzeugt, imitiert die Oberfläche der grafischen Programmiersprache: Kästchen, Drähte, Schleifenrahmen, Terminals. Was fehlt, ist das Datenflussprinzip selbst. LabVIEW ist keine Textsprache, die man Zeile für Zeile generieren kann. Es ist ein Datenflussmodell, in dem die Ausführungsreihenfolge nicht durch Befehle entsteht, sondern dadurch, wann Daten an Knoten ankommen. Ein Sprachmodell sieht die Pixel. Es versteht nicht den Fluss.

Dazu kommt: LabVIEW-Code existiert als Binärformat. Es gibt keinen verbreiteten offenen Standard, kein einfaches Textformat, das ein Modell ausgeben könnte und das die Entwicklungsumgebung direkt lädt. Was die KI liefert, sind Pseudobeschreibungen, Screenshots von Blockdiagrammen oder VIs, die mühsam nachgebaut werden müssen. Der Nachbau ist die eigentliche Arbeit - und die macht immer noch der Mensch.

Warum textbasierte Sprachen hier im Vorteil sind

Python, C, JavaScript: Diese Sprachen bestehen aus Text. Ein Modell kann sie erzeugen, ein Compiler kann sie prüfen, ein Testlauf kann sie validieren. Die Rückkopplungsschleife ist kurz. Bei LabVIEW bricht diese Schleife auseinander. Es gibt keinen Compiler in der Schleife, der der KI sagt: „Das war falsch, versuch es anders." Die Maschine rät ins Blaue, und der Mensch zahlt die Rechnung mit Zeit.

Projekte wie der experimentelle „G-CLI-Zugang" oder einzelne Forschungsansätze, Blockdiagramme aus natürlicher Sprache zu generieren, existieren. Sie bleiben Demonstratoren. Sie funktionieren für demonstrative Beispiele - ein Taschenrechner, ein Blinklicht - und scheitern an realer Komplexität: Versionskonflikte, Hardwaretreiber, Timing-Regeln, Realzeit-Anforderungen und dem Umstand, dass jede Messanlage ihre Eigenheiten hat, die in keinem Trainingskorpus steht.

Die Verführung und ihre Kosten

Die eigentliche Gefahr ist nicht der kaputte Code. Es ist die Verschiebung der Kompetenz. Wer jahrelang Blockdiagramme gezogen hat, entwickelt ein Gespür für Datenfluss, Race Conditions und Speicherzuordnung. Dieses Gespür entsteht durch Fehler, durch Debuggen, durch Freitagabende vor laufender Messung. Wer diese Phase überspringt, weil die KI ja „schnell was zusammenbaut", hat später niemanden im Haus, der beurteilen kann, ob das Ergebnis stimmt. Und ein Messsystem, das falsch misst, fällt nicht laut auf. Es fällt leise auf - in den Daten.

Dazu kommt die Frage der Verantwortung. Wenn ein generiertes VI eine Messkette falsch takten lässt und dadurch ein Prüfling durchgeht, haftet niemand auf die KI. Es haftet der, der es ausgeliefert hat. „Die Maschine hat es so generiert" ist keine Verteidigung, die eine Auditierung übersteht.

Was stattdessen geht

Die vernünftige Arbeitsteilung sieht so aus: Die KI erklärt Konzepte, schlägt Architekturen vor, hilft bei Formeln, entwirft Zustandsmaschinen als Textbeschreibung. Der Mensch setzt um, prüft, testet, dokumentiert. Das ist kein Rückschritt, sondern ehrliche Arbeitsteilung - die Maschine denkt laut, der Ingenieur entscheidet. Genau wie früher, nur mit besserem Nachschlagewerk.

Der Comic, der zu diesem Artikel gehört, zeigt das Dilemma in einem Bild: der Nerd vor drei Monitoren, die KI antwortet „Selbstverständlich!", und irgendwo im Hintergrund flackert der Zweifel. Der Zweifel hat recht. LabVIEW von der KI schreiben zu lassen ist wie Navigation vom Beifahrer, der noch nie dort war: Die Richtung stimmt ungefähr, die Abzweigung kommt zu früh, und die Brücke ist eine Fähre. Man kommt manchmal an. Aber man sollte nicht damit rechnen.