Ein Funkzähler ist kein automatisch integrierter Home-Assistant-Sensor. Er sendet vielleicht Daten. Das heißt noch nicht, dass dein Gateway den Funkmodus empfängt, dass der Inhalt zum richtigen Treiber passt oder dass du verschlüsselte Daten lesen kannst.
Genau an dieser Stelle wird aus einer vermeintlich kleinen YAML-Aufgabe ein Fehlersuchprojekt. Die schlechte Reihenfolge lautet: Gerät kaufen, Zählername raten, Konfiguration kopieren, auf Werte warten. Die bessere Reihenfolge ist ein Preflight: Empfangsfähigkeit prüfen, ein echtes Telegramm erfassen, daraus Treiber und Felder bestimmen, bei Bedarf den Schlüssel einrichten und erst dann Sensoren bauen.
Das IoTLabs wM-Bus Gateway ist dafür interessant, weil es Daten von Wireless-M-Bus-Zählern lokal empfangen und über ESPHome weiterreichen soll. Die Produktseite nennt ausdrücklich T1- und C1-Frames sowie die Einbindung in Home Assistant über ESPHome.[1] Das ist eine brauchbare Grundlage. Es ist aber keine Zusage für deinen Zähler. Entscheidend bleibt immer das konkrete Telegramm, das an deinem Standort ankommt.
Weiterführende Guides#
- Home Assistant & Smart Home Themenhub
- Home Assistant Apps sinnvoll auswählen
- Home Assistant Dashboard mit YAML
Der Preflight in einem Satz#
Prüfe zuerst, ob dein konkreter Zähler tatsächlich im vom Gateway unterstützten T1- oder C1-Modus sendet. Erfasse dann ein Telegramm im Log. Bestimme damit die Meter-ID, den passenden Treiber und die verfügbaren Felder. Kläre bei Verschlüsselung den Schlüssel. Erst danach legst du wmbus_meter und die gewünschten Sensoren an.[1][2]
Das ist keine Pedanterie. Es verhindert, dass du eine Meter-ID vom Aufkleber mit einer ID aus dem Funktelegramm verwechselst, einen Feldnamen aus einem fremden Beispiel übernimmst oder einen verschlüsselten Zähler für einen Empfangsfehler hältst.
Was das Gateway sicher kann – und was daraus nicht folgt#
IoTLabs beschreibt das Gerät als lokalen Wireless-M-Bus-Empfänger im 868-MHz-Band mit externer Antenne und ESPHome-Anbindung. Die Produktseite nennt T1 und C1 als unterstützte Frame-Typen; die Projektkonfiguration bindet dafür die Komponenten wmbus_radio und wmbus_meter ein.[1][6]
Daraus folgt nur dies: Ein Zähler, der in T1 oder C1 sendet, ist ein Kandidat für den Test. Es folgt nicht, dass jeder Wasser-, Wärme-, Gas- oder Stromzähler mit Funk sofort lesbar ist. Der Funkmodus kann abweichen. Der Treiber kann fehlen oder zu einem anderen Datenformat passen. Das Telegramm kann verschlüsselt sein. Und ein Standort, an dem kein verwertbares Telegramm ankommt, liefert auch mit sauberer YAML keine Messwerte.
Die klare Kauf- und Einrichtungsregel lautet deshalb: Keine Kompatibilität aus einem Produktnamen, Baujahr oder Foto ableiten. Ein erfasstes Telegramm ist belastbarer als jede Liste im Netz.
Vor dem Einschalten: Antenne montieren#
Montiere die externe Antenne vollständig, bevor du das Gateway mit Strom versorgst. Das Projekt-README warnt ausdrücklich davor, das Gerät ohne angeschlossene Antenne einzuschalten, weil das Funkmodul dabei beschädigt werden kann.[2]
Das ist kein optionaler Optimierungsschritt. Erst Antenne fest montieren, dann USB-Strom anschließen. Wenn du später den Standort wechselst oder die Antenne neu positionierst, schalte das Gerät vorher aus. Du musst daraus keine Antennenwissenschaft machen. Du brauchst eine sichere Ausgangslage für einen wiederholbaren Empfangstest.
Schritt 1: Nicht konfigurieren, sondern zuhören#
Nimm das Gateway in ESPHome unter Kontrolle und öffne die Logs. Das README beschreibt genau diesen Ablauf: Nach der WLAN-Einrichtung wird das Gerät im ESPHome Dashboard übernommen; anschließend sollen die Logs auf ein eingehendes wM-Bus-Telegramm warten.[2]
Die werkseitige Blueprint-Konfiguration enthält dafür einen wmbus_radio-Abschnitt. Er protokolliert die Meter-ID und erzeugt einen Link zum wmbusmeters-Analyzer, der den empfangenen Frame enthält.[3] Lass diesen Empfangspfad an, bis du einen echten Datensatz deines Zählers gesehen hast.
Arbeite dabei mit einer kleinen Notiz statt mit Vermutungen:
- Datum, Uhrzeit und Aufstellort des Gateways
- Meter-ID aus dem Log
- Analyzer-Link beziehungsweise Frame aus dem Log
- erkannter oder vorgeschlagener Treiber
- verfügbare Felder
- Hinweis, ob der Frame verschlüsselt ist
- sichtbarer RSSI-Wert, sobald der Zähler als Sensor angelegt ist
Der letzte Punkt ist Diagnose, keine Qualitätsnote. RSSI hilft dir, verschiedene Standorte unter gleichen Bedingungen zu vergleichen. Ein einzelner Wert garantiert weder vollständige Telegramme noch einen stabilen Betrieb. Er ist aber deutlich nützlicher als „funktioniert bei mir“.
Schritt 2: Den richtigen Treiber aus dem Telegramm ableiten#
Das README nennt die Reihenfolge klar: Nach dem Empfang analysierst du den Frame, prüfst dabei bei Bedarf den Entschlüsselungsschlüssel und schaust, welche Datenfelder dekodierbar sind. Erst wenn Meter-ID, Schlüssel und interessante Felder identifiziert sind, soll die Gerätekonfiguration bearbeitet werden.[2]
Der type-Wert ist dabei kein frei erfundener Gerätetyp. Er ist der Treibername, den die Analyse für genau dieses Telegramm ergibt. Das Component Schema der verwendeten Version validiert type gegen die verfügbaren Treiber. Eine geraten kopierte Zeichenfolge wird also entweder beim Build abgewiesen oder dekodiert nicht sinnvoll.[8]
Wichtig: Der lesbare Name auf dem Zähler ist nicht automatisch dieser Treibername. Auch eine plausible Meter-ID aus Unterlagen ersetzt die ID aus dem tatsächlich empfangenen Frame nicht. Die Analyse liefert den Zusammenhang, den du brauchst.
Schritt 3: Verschlüsselung ist ein Stoppschild, kein YAML-Problem#
Wenn der Analyzer einen verschlüsselten Frame zeigt, ist der Empfang bereits gelungen. Jetzt fehlt nicht „besserer Funk“, sondern der Schlüssel. Ohne passenden Schlüssel kannst du die Nutzdaten nicht seriös in Sensoren übersetzen.
Die Komponente akzeptiert key optional; das Schema akzeptiert einen Schlüssel als Hex- oder ASCII-kodierte Zeichenfolge. Fehlt key, werden Pakete als unverschlüsselt verarbeitet.[8] Das README nennt denselben Ablauf: Schlüssel im Analyzer prüfen, dann in der Konfiguration ergänzen.[2]
Trage keinen Schlüssel in einen Artikel, ein Git-Repository oder einen Screenshot ein. Lege ihn als ESPHome-Secret ab und referenziere ihn aus der Gerätekonfiguration. Auch wenn du momentan nur lokal arbeitest: Das ist der kürzere Weg, später nicht versehentlich Zugangsdaten zu veröffentlichen.
Wenn du den Schlüssel nicht hast, halte hier an. Sensoren auf Verdacht anzulegen bringt nichts. Kläre den Schlüssel mit der Stelle, die den Zähler betreibt, oder entscheide bewusst, dass dieser Zähler vorerst nicht integrierbar ist.
Schritt 4: Aktuelle YAML-Struktur für einen konkreten Wasserzähler#
Die folgende Konfiguration ist absichtlich ein Muster, kein Copy-paste-Rezept. 12345678 und treiber_aus_deiner_analyse musst du durch die Werte aus deinem eigenen Log und Analyzer ersetzen. Die auskommentierte key-Zeile aktivierst du nur, wenn der konkrete Zähler verschlüsselt sendet und du den korrekten Schlüssel als Secret hinterlegt hast.
wmbus_meter:
- id: wasserzaehler_keller
meter_id: "12345678" # Beispiel: durch Meter-ID aus dem empfangenen Frame ersetzen
type: treiber_aus_deiner_analyse # Platzhalter: exakten Treibernamen aus dem Analyzer einsetzen
# key: !secret wasserzaehler_wmbus_key # Nur bei verschlüsseltem Telegramm
sensor:
- platform: wmbus_meter
id: wasserzaehler_gesamt
parent_id: wasserzaehler_keller
field: total_m3
name: "Wasserzähler Gesamtverbrauch"
device_class: water
state_class: total_increasing
- platform: wmbus_meter
id: wasserzaehler_rssi
parent_id: wasserzaehler_keller
field: rssi_dbm
name: "Wasserzähler RSSI"
device_class: signal_strength
state_class: measurementDas entspricht der aktuellen Aufteilung: Der Block wmbus_meter beschreibt ein Messgerät über id, meter_id, type und optional key. Jeder veröffentlichte Wert ist anschließend ein eigener Sensor mit platform: wmbus_meter, parent_id und field.[3][8][9]
Die Blueprint-Datei des Gateways zeigt genau diese Struktur auch für total_m3 und rssi_dbm.[3] Die Komponenten-Version des Gateways referenziert für die externen ESPHome-Komponenten v1.2.5; dort ist meter_id Pflicht, type Pflicht und key optional.[6][7][8]
Zwei Details sind wichtig:
total_m3ist nur dann korrekt, wenn dein Analyzer dieses Feld für deinen Treiber zeigt. Nicht jeder Zähler nennt seinen Gesamtwert gleich.- Der Platzhalter bei
typemacht die Beispiel-YAML absichtlich noch nicht buildbar. Das ist besser als ein echter Treibername, der nur zufällig in einem fremden Beispiel vorkommt. Ersetze ihn erst nach der Analyse.
Sobald du Sensoren über wmbus_meter definierst, lädt die Komponente die benötigten Felder für den zugehörigen Treiber automatisch. Einen zusätzlichen globalen wmbus_common-Block brauchst du für diese einfachen Sensoren nicht.[9]
Schritt 5: RSSI für Standorttests nutzen#
Der RSSI-Sensor gehört in die Konfiguration, weil du damit Standortentscheidungen auf Daten statt Bauchgefühl stützt. Teste nicht fünf Dinge gleichzeitig. Lass Antenne und Konfiguration unverändert und vergleiche nacheinander zwei oder drei mögliche Positionen.
Ein brauchbarer Test sieht so aus:
- Antenne montieren, Gateway ausschalten und an Standort A platzieren.
- Einschalten, auf echte Telegramme warten und RSSI sowie die Anzahl sichtbar eingehender Updates notieren.
- Gateway ausschalten, an Standort B umsetzen, wieder einschalten und den gleichen Zeitraum beobachten.
- Den Standort wählen, der in deinem Test nachvollziehbar verwertbare Telegramme liefert.
Das ist bewusst kein Funkversprechen. Wände, Metallflächen, Schächte, Leitungen und die Ausrichtung des konkreten Zählers verändern den Empfang. Aus dem RSSI kannst du eine lokale Entscheidung ableiten; du kannst daraus keine allgemeine Reichweite, Antennenempfehlung oder Erfolgsgarantie ableiten.
Wenn an keinem sinnvollen Ort ein Telegramm auftaucht, geh zurück zu Schritt eins. Prüfe zuerst erneut, ob dein Zähler T1 oder C1 sendet und ob du lange genug geloggt hast. Das Gateway unterstützt laut Produktseite diese beiden Modi, nicht pauschal jeden Wireless-M-Bus-Betriebsmodus.[1]
Schritt 6: Den Gesamtzähler korrekt in Home Assistant einordnen#
Ein Wasserzählerstand ist ein kumulativer Wert, kein aktueller Durchfluss. Für den Sensor mit field: total_m3 sind deshalb device_class: water und state_class: total_increasing die passenden Angaben. Home Assistant verlangt für manuell integrierte Wasserzähler unter anderem Geräteklasse, Zustandsklasse und Einheit; für kumulative Wasserzähler ist total_increasing vorgesehen.[4]
Danach gehst du in Home Assistant zu Einstellungen -> Dashboards -> Energy und fügst den Sensor dort als Wasserzähler im Energy-Dashboard hinzu. Home Assistant nutzt dafür Langzeitstatistiken und kann den Verbrauch zeitlich darstellen.[4]
Wichtig ist die Trennung: Der Zählerstand bleibt die Quelle der Wahrheit. Er wird nicht für eine Monatsansicht umgerechnet und auch nicht durch einen Durchflusswert ersetzt. Wenn der physische Zähler getauscht oder zurückgesetzt wird, kann Home Assistant bei total_increasing einen neuen Zählerzyklus behandeln und die bis dahin erfassten Werte in den Langzeitstatistiken behalten.[4]
Optional: Utility Meter für Abrechnungsperioden#
Der Energy-Bereich beantwortet die Frage „Wie hat sich der Verbrauch entwickelt?“. Für eine monatliche Abrechnungsperiode kann zusätzlich ein Utility Meter sinnvoll sein. Die Integration verfolgt einen Quellsensor in festen Zyklen und setzt ihren eigenen Zähler zum Start der gewählten Periode zurück.[5]
Du kannst ihn in der Oberfläche als Helper anlegen: Quellsensor ist dein sensor.wasserzaehler_gesamt, Zyklus etwa monatlich. Nimm die UI, wenn ein normaler Kalendermonat genügt. YAML ist nur nötig, wenn du einen abweichenden Termin per Cron brauchst.
utility_meter:
wasserverbrauch_monat:
source: sensor.wasserzaehler_gesamt
name: Wasserverbrauch Monat
cycle: monthlyDas Muster ist absichtlich klein. Es baut auf den Gesamtzähler auf und erstellt keinen zweiten Funkempfänger, keinen separaten Zählerstand und keine Doppelzählung. Utility Meter speichert seine Werte über Neustarts hinweg; der erste Zyklus ist jedoch unvollständig, bis die erste volle Periode erreicht ist.[5]
Die Reihenfolge, die Ärger spart#
Ein sinnvoller Abschluss ist keine lange Kompatibilitätsliste, sondern diese Prüfung:
- Antenne vor dem Einschalten montiert?
- Sendet dein konkreter Zähler nachweislich T1 oder C1?
- Liegt ein echtes Telegramm aus deinen ESPHome-Logs vor?
- Sind Meter-ID, Treiber und Feldname aus dem Analyzer abgeleitet?
- Ist bei Verschlüsselung der richtige Schlüssel sicher als Secret hinterlegt?
- Ist
total_m3wirklich ein dekodiertes Feld dieses Zählers? - Zeigt der RSSI-Sensor bei deinem gewählten Standort wiederholt Daten?
- Ist der Gesamtwert als Wasser- und
total_increasing-Sensor im Energy Dashboard eingetragen?
Wenn du diese Punkte sauber beantwortet hast, ist die YAML klein. Genau so soll sie sein. Die Arbeit steckt nicht im Tippen der Sensorblöcke. Sie steckt darin, vor dem Tippen den realen Zähler zu verstehen.
Passende Produktrecherchen#
Wenn du Alternativen für deinen Internetzugang vergleichen möchtest:
Hinweis: Dieser Link ist ein Starlink-Empfehlungslink. Wenn du darüber bestellst, können für dich und kalika.de Vorteile nach den jeweils geltenden Starlink-Bedingungen entstehen.
Quellen#
- IoTLabs: wM-Bus Gateway Produktseite
- IoTLabs: README des wM-Bus-Gateway-Projekts
- IoTLabs: aktuelle raw blueprint.yaml
- Home Assistant: Integrating your water usage
- Home Assistant: Utility Meter
- IoTLabs: Gateway-Paketdefinition v1.1.7
- IoTLabs: Versionsdefinition mit ESPHome Components v1.2.5
- IoTLabs: wmbus_meter Component Schema v1.2.5
- IoTLabs: wmbus_meter Sensor Schema v1.2.5