Wireless M-Bus in Home Assistant über ESP32 + MQTT – verteilte Empfänger, WebUI und automatische Erkennung

Integrationen
, ,
1

wmbusmeters ist ein hervorragender Decoder, aber die übliche Home-Assistant-Konfiguration setzt voraus, dass der Funkempfänger direkt mit dem Home-Assistant-Host verbunden ist.

Das wird unpraktisch, wenn sich die Zähler außerhalb der Funkreichweite befinden, wenn der Empfänger im Keller, Treppenhaus oder in der Garage platziert werden muss, wenn USB-Funksticks mit ZHA- oder Z-Wave-Sticks konkurrieren oder wenn mehrere Empfangspunkte benötigt werden.

Dieses Projekt trennt deshalb den Funkempfang von der Dekodierung.

image
image1116×1410 241 KB

Der ESP32 wird dort platziert, wo der Funkempfang am besten ist, und übernimmt ausschließlich die Funkseite. Er veröffentlicht Wireless-M-Bus-RAW-Telegramme über MQTT.

Dekodierung, AES-Schlüssel, Zählertreiber und die Erstellung der Home-Assistant-Entitäten bleiben auf dem Home-Assistant-Host. Mehrere ESP-Empfänger können denselben Decoder versorgen. Am Home-Assistant-Host selbst ist kein USB-Funkempfänger erforderlich.

LISTEN-Modus

Jeder empfangene Zähler erscheint automatisch in der WebUI — mit Hersteller, Zähler-ID, vorgeschlagenem Treiber, Empfangsstatistiken (15 min / 60 min) und einer Live-Vorschau der dekodierten Werte. Der Zähler kann also geprüft werden, bevor er konfiguriert wird. Dafür sind weder YAML noch ein Neustart erforderlich.

image
image1658×1291 317 KB

Zähler mit einem Klick hinzufügen

Ein erkannter Zähler kann direkt aus der WebUI hinzugefügt werden — vorgeschlagenen Treiber bestätigen oder ändern, bei Bedarf den AES-Schlüssel eintragen, fertig. Die Home-Assistant-Entitäten werden anschließend automatisch über MQTT Discovery erstellt, und zwar aus genau den Feldern, die tatsächlich im dekodierten JSON vorhanden sind. Keine manuellen Sensordefinitionen pro Treiber, keine Einträge in configuration.yaml. Das Hinzufügen löst nur einen Soft-Reload der Pipeline aus — das Add-on selbst startet nicht neu.

SEARCH-Modus

In Mehrfamilienhäusern können gleichzeitig Dutzende Zähler empfangen werden. Der SEARCH-Modus vergleicht den auf dem physischen Zähler angezeigten Messwert mit den live dekodierten Werten und identifiziert so den eigenen Zähler — ohne jede ID einzeln durchzuprobieren.

Pipeline-Dashboard

Die WebUI zeigt den gesamten Datenfluss:

ESP-Empfänger → MQTT → Decoder → Home Assistant

Jede Stufe zeigt ihren tatsächlichen Status und die aktuelle Aktivitätsrate. Eine Stufe wird nur dann als funktionsfähig angezeigt, wenn dort wirklich Daten fließen — die Oberfläche zeigt kein „grün", wenn im Hintergrund nichts verarbeitet wird.

image
image1644×595 53.4 KB

Selbstdiagnostizierender Start

Probleme mit dem MQTT-Broker werden als konkrete, verständliche Meldungen angezeigt: falsche Zugangsdaten, nicht erreichbarer Broker oder fehlende Pflichtfelder — die WebUI sagt direkt, welche Einstellung geprüft werden muss, statt leere Felder und unerklärte Striche zu zeigen.

image
image1391×612 40.7 KB

Weitere Funktionen

  • automatische Broker-Erkennung: Mosquitto über die Supervisor-API, EMQX über eine Broker-Probe (manuelle Konfiguration weiterhin möglich)

  • Unterstützung für CC1101, SX1276 und SX1262

  • AES-Schlüssel pro Zähler, verwaltet in der WebUI

  • mehrere ESP-Empfänger an einem gemeinsamen Decoder

  • WebUI in fünf Sprachen: Englisch, Polnisch, Deutsch, Tschechisch, Slowakisch

  • Betrieb auch als eigenständiger Docker-Container ohne Home Assistant

  • Funk-Firmware und Decoder werden unabhängig voneinander aktualisiert — neue Zählertreiber erfordern kein erneutes Flashen der Empfänger

Tests

Eine Decode-Regression-Suite läuft in der CI bei jedem Build im frisch gebauten Image und blockiert fehlerhafte Releases — mit Referenztelegrammen u. a. für Techem, Qundis, Kamstrup, Diehl, Apator, BMETERS, Maddalena und Integra. Regressionen in Treibern, Dekodierung und Feldzuordnung werden so früh erkannt.

Projektlinks

Die Funkkomponente basiert auf Arbeiten aus den ESPHome-Komponenten von SzczepanLeon. In diesem Projekt wurden Dekodierung und Zählertreiber aus der ESP-Firmware in das serverseitige Add-on verschoben; die ESP-Firmware übernimmt ausschließlich den Funkempfang.

Für wen ist das gedacht?

Dieses Projekt soll bestehende wmbusmeters-Installationen nicht ersetzen. Wenn ein USB-Funkempfänger direkt am Home-Assistant-Host zuverlässig alle Zähler erreicht, gibt es keinen Grund, etwas zu ändern.

Es richtet sich an Installationen, bei denen die Zähler nicht in der Nähe des HA-Hosts liegen, mehrere Empfangspunkte benötigt werden, kein USB-Gerät am Host erwünscht ist oder automatische Erkennung, WebUI und Diagnose gewünscht sind.

Der ESP steht dort, wo das Funksignal gut ist. Der Decoder läuft dort, wo Rechenleistung und Speicher vorhanden sind. MQTT verbindet beide.

2

sprich, die Vorteile ergeben sich insbesondere wenn man mehrere Empfänger benötigt und diese nicht einzeln mit ESPHome managen muss?

3

Genau, mehrere Empfänger sind der offensichtlichste Vorteil: N „dumme" ESPs, ein Decoder, eine zentrale Zählerliste — kein Zähler-YAML pro Board.

Aber der Punkt „nicht einzeln mit ESPHome managen" gilt schon ab einem einzigen Empfänger: der ESP wird einmal geflasht und danach nie wieder angefasst. Zähler hinzufügen/entfernen, Treiber wählen, AES-Schlüssel eintragen — alles passiert in der WebUI des Add-ons, ohne YAML, ohne Neukompilieren, ohne OTA.

Dazu kommen ein paar Dinge, die unabhängig von der Anzahl der Empfänger sind:

Treiber-Updates ohne Flashen: die Zählertreiber leben im Add-on (vollständiges wmbusmeters-Treiberset), nicht in der ESP-Firmware. Neuer Treiber oder Bugfix upstream → Add-on-Update, fertig. Kein Flash-Limit des ESP.
Discovery vor der Konfiguration: jeder gehörte Zähler erscheint in der WebUI mit Hersteller, Treibervorschlag und Live-Wert als Vorschau — bevor man ihn überhaupt anlegt.
AES-Schlüssel bleiben auf dem Server, nicht im ESP-YAML.
Wenn ein einzelner Empfänger mit der ESPHome-Komponente für dich gut funktioniert und du YAML magst — dabei bleiben, das ist völlig in Ordnung. Der Unterschied wird spürbar, sobald Zähler öfter wechseln, die Reichweite nicht reicht oder man das Flashen leid ist.

So sieht das bei mir live aus: drei Empfänger (Heltec, LilyGO, XIAO Seeed) an verschiedenen Standorten, ein Decoder — 70 Zähler in Reichweite, 27 Telegramme/min. Zähler hinzufügen, Treiber ändern, AES-Schlüssel eintragen — nichts davon hat je ein Reflash der Empfänger erfordert; das passiert komplett in der WebUI. (Firmware-Updates flashe ich natürlich gelegentlich — ich entwickle sie ja. :wink:)

image
image1422×344 26.1 KB

4

:star_struck: Ich habe gerade Wireless Mbus installiert. Der ESP32 mit CC1101 verkabelt und in ESPHome mit Hilfe von KI eingerichtet da es mit den Vorlagen nicht laufen wolte.
Ich muss dazu sagen das ich das Ganze zuhause ohne mbus-Geräte testen muss, klin gt blöd ist aber so, und in ca 2 Monaten meinen Schwiegereltern mit geben die es dann in 800km entfernten Ferienhaus anschließen sollen :zany_face:
Problem bisher ist das der ESP im Dashboard des Addons nicht erscheint, klar er kann keine Daten empfangen aber ist das so normal?
Ich tippe eher drauf das eine MQTT Einstellung fehlerhaft.
Im MQTT explorer erscheint der ESP32.

Hier meine YAML vom ESP32

esphome:
  name: wmbus-cc1101-bridge
  friendly_name: wMBus CC1101 Bridge

# Replace this with your actual platform if you aren't using ESP32.
esp32:
  board: esp32dev
  framework:
    type: arduino

api:
  encryption:
    key: "********************************************"
# API Code Verschlüsselung
ota:
  - platform: esphome

wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password
  ap:
    ssid: "wMBus-Bridge-Fallback-AP"
    password: ******* # Dein MQTT-Passwort
# WLAN-Verbindung (Zwingend erforderlich für MQTT)
#wifi:
#  ssid: "DEIN_WLAN"
#  password: "**********" # Dein MQTT-Passwort

# Fallback-Webserver zur Statuskontrolle (Optional, aber hilfreich)
web_server:
  port: 80

captive_portal:


# Externe Komponente für den wM-Bus RAW Empfang laden
external_components:
  - source: github://Kustonium/esphome-wmbus-bridge-rawonly@main
    components: [ wmbus_radio ]

# SPI-Bus für das CC1101 Modul definieren
spi:
  clk_pin: GPIO18
  mosi_pin: GPIO23
  miso_pin: GPIO19

# CC1101 Modul-Konfiguration und Pin-Zuweisung
wmbus_radio:
  radio_type: CC1101
  cc1101_allow_experimental: true  # Schaltet die Nutzung des CC1101 frei
  cs_pin: GPIO05
  gdo0_pin: GPIO02                 # Physisch mit GDO0 des CC1101 verbinden
  gdo2_pin: GPIO04                 # MUSS physisch mit GDO2 des CC1101 verbunden sein!


# Logger aktivieren (Zeigt empfangene Telegramme im ESPHome-Log an)
logger:
  level: DEBUG

# Verbindung zum Home Assistant MQTT Broker
mqtt:
#  broker: "192.168.88.88"      # IP-Adresse deines Home Assistant / Mosquitto Brokers
  broker: "192.168.1.65"      # IP-Adresse deines Home Assistant / Mosquitto Brokers  broker: "192.168.88.88"      # IP-Adresse deines Home Assistant / Mosquitto Brokers
  username: "mqtt_user"  # Dein MQTT-Benutzername
  password: ******  # Dein MQTT-Passwort
#  topic_prefix: wmbus_raw.   <-- original
  topic_prefix: wmbus/zaehler/Telegram. 
  # <---test
5

Danke für deinen Beitrag — und Glückwunsch, die Hardware-Seite hast du sauber verdrahtet! :slightly_smiling_face: Hier ist ein korrigiertes YAML mit deinen Daten, direkt flashbar:

substitutions:
  devicename: wmbus-cc1101-bridge
  friendly_name: "wMBus CC1101 Bridge"

esphome:
  name: ${devicename}
  friendly_name: ${friendly_name}
  min_version: 2026.1.3
  name_add_mac_suffix: false

esp32:
  board: esp32dev
  framework:
    type: esp-idf

external_components:
  - source: github://Kustonium/esphome-wmbus-bridge-rawonly@main
    components: [wmbus_radio]
    refresh: 0s

logger:
  level: info
  logs:
    mqtt: warn
    component: warn

wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password
  power_save_mode: none
  fast_connect: true

mqtt:
  broker: "192.168.1.65"
  username: "mqtt_user"
  password: !secret mqtt_password
  port: 1883
  skip_cert_cn_check: true

api:
ota:
  - platform: esphome
mdns:
  disabled: false
time:
  - platform: homeassistant

spi:
  clk_pin: GPIO18
  mosi_pin: GPIO23
  miso_pin: GPIO19

wmbus_radio:
  radio_type: CC1101
  cc1101_allow_experimental: true

  frequency: 868.950
  cs_pin: GPIO05

  gdo0_pin:
    number: GPIO02
    mode: input

  gdo2_pin:
    number: GPIO04
    mode: input

  listen_mode: t1
  listen_mode_filter_after_parse: false

  topic_name: "zaehler"
  diagnostic_mode: normal
  diagnostic_summary_interval: 60s

Wo lagen die inhaltlichen Fehler:

1. framework: arduino — die Komponente wird auf esp-idf entwickelt, gebaut und getestet (auch auf ESPHome 2026.7.0 verifiziert). Arduino ist ungetestetes Terrain. Der Tipp „nimm arduino" stammt aus der Welt anderer wmbus-Komponenten — hier ist er unnötig.

2. topic_prefix — die Komponente publiziert ihre Topics absolut: wmbus/zaehler/telegram und wmbus/zaehler/health, unabhängig vom topic_prefix. Deine Änderung hat nur die ESPHome-Status-Topics verbogen (daher das seltsame wmbus/zaehler/Telegram./... im Explorer). Mit topic_name: "zaehler" bekommst du genau die Benennung, die du wolltest — und das Addon findet sie auf dem Standard-raw_topic von selbst.

3. diagnostic_mode fehlte — damit meldet sich der ESP im Addon-Dashboard auch ohne einen einzigen Zähler in Reichweite. Nach dem Flashen: schau im MQTT Explorer nach wmbus/zaehler/health — sobald das da ist, muss der ESP im Addon erscheinen. Fehlt es trotzdem, zeig mir das ESPHome-Log vom Boot.

4. :warning: Und das Wichtigste: in deinem Post steht dein echtes Passwort im Klartext-Kommentar (Zeile ap:). Bearbeite den Beitrag und ändere das MQTT-Passwort — das Forum ist öffentlich.

Als Referenz liegt im Repo examples/CC1101/CC1101_clean.yaml — im Zweifel immer von dort starten.

6

Himmel, vielen herzlichen Dank, selten so eine fundierte Hilfe bekommen. Du kannst echt top erklären.
Ich habe Deine Vorlage übernommen und ja, sie läuft komplett durch.
Hier das Protokoll vom ESP:

INFO ESPHome 2026.7.0

INFO Loaded validated config cache for wmbus-cc1101-bridge.yaml, skipping validation.

INFO Starting looking for IP in topic esphome/discover/wmbus-cc1101-bridge

INFO Connected to MQTT broker!

INFO Send discover via MQTT broker topic: esphome/ping/wmbus-cc1101-bridge

INFO Found IP: ['192.168.3.187']

INFO Starting log output from 192.168.3.187 using esphome API

INFO Successfully resolved wmbus-cc1101-bridge @ 192.168.3.187 in 0.000s

INFO Successfully connected to wmbus-cc1101-bridge @ 192.168.3.187 in 0.079s

INFO Successful handshake with wmbus-cc1101-bridge @ 192.168.3.187 in 0.101s

[15:57:02.800][I][app:151]: ESPHome version 2026.7.0 compiled on 2026-07-20 15:47:03 +0200

[15:57:02.853][I][app:158]: ESP32 Chip: ESP32 rev1.0, 2 core(s)

[15:57:02.853][W][app:198]: Bootloader supports SRAM1 as IRAM (+40KB). Set sram1_as_iram: true under esp32 > framework > advanced

[15:57:20.813][I][wmbus:627]: DIAG summary / podsumowanie diag: topic=wmbus/zaehler/diag/summary interval=60s uptime_ms=420630 listen_mode=T1 only total=0 ok=0 truncated=0 dropped=0 crc_failed=0

[15:57:20.817][W][wmbus:635]: DIAG hint: NO_DATA | no packets received yet / brak odebranych ramek

[15:58:20.820][I][wmbus:627]: DIAG summary / podsumowanie diag: topic=wmbus/zaehler/diag/summary interval=60s uptime_ms=480641 listen_mode=T1 only total=0 ok=0 truncated=0 dropped=0 crc_failed=0

[15:58:20.826][W][wmbus:635]: DIAG hint: NO_DATA | no packets received yet / brak odebranych ramek

[15:59:20.814][I][wmbus:627]: DIAG summary / podsumowanie diag: topic=wmbus/zaehler/diag/summary interval=60s uptime_ms=540642 listen_mode=T1 only total=0 ok=0 truncated=0 dropped=0 crc_failed=0

[15:59:20.823][W][wmbus:635]: DIAG hint: NO_DATA | no packets received yet / brak odebranych ramek

[16:00:20.834][I][wmbus:627]: DIAG summary / podsumowanie diag: topic=wmbus/zaehler/diag/summary interval=60s uptime_ms=600658 listen_mode=T1 only total=0 ok=0 truncated=0 dropped=0 crc_failed=0

[16:00:20.839][W][wmbus:635]: DIAG hint: NO_DATA | no packets received yet / brak odebranych ramek

Dashboard
Dashboard1221×663 58.6 KB

logs
logs1283×864 136 KB

Müsste er so jetzt Zähler finden wenn ich ihn am späteren Aufstellungsort aktivieren lasse?
Ziel ist es einen APATOR 16-2 Wasserzähler sowie den von Tauron verbauten KAIFA MA110M ab zu fragen.
Den HAN Code von Tauron habe ich inzwischen… das war ja eine Geburt.
Ich dache ich kann den Zähler wie in D auch über die IR Schnittstelle auslesen… nix wars, die ist nur für deren Gebrauch.

Die MQTT Topics sind bei mir eigentlich so aufgebaut:
z.B. homeassistant/zaehler/stromzaehler/
Ich weiß nicht ob diese “Ordnung” Sinn macht oder es eine Regel gibt?

Danke für den Hinweis, das vermeindliche Passwort ist nicht mein Passwort, das hatte Chatbot AI auf einmal drin, ist mir garnicht aufgefallen :grin: Egal, habs entfernt.

7

Hi,

das NO_DATA im Log ist kein Konfigurationsfehler – die Platine meldet nur, dass sie bis jetzt keine Funktelegramme gehört hat. Wenn du dort kompilierst/testest, wo keine WM-Bus-Zähler in Reichweite sind, kann das Board nichts empfangen, und genau das zeigt der Zähler (total=0, ok=0) an.

Sobald die Platine am Einsatzort steht, wo Zähler per WM-Bus funken, tauchen die Telegramme im Log auf – und auf HA-Seite werden dir die empfangenen Zähler dann automatisch grafisch angezeigt. Den Kaifa MA110M solltest du dabei ganz normal sehen, sobald er sendet – es sei denn, er läuft über P1 statt WM-Bus oder das Telegramm ist AES-verschlüsselt und dir fehlt der Schlüssel.

Zu deiner MQTT-Frage: Bei HA MQTT-Discovery gibt es keine feste „richtige" Topic-Hierarchie – HA liest die Discovery-Config aus, und die zeigt auf dein state_topic, egal wie der Pfad heißt. Es gibt also keine Regel, die du verletzt. Eine Konvention gibt es aber: homeassistant/ ist der reservierte Discovery-Prefix (dort landen nur die .../config-Topics). Deine eigenen Messwerte würde ich deshalb nicht unter homeassistant/... legen, sondern unter einen eigenen Base-Topic.

Das Add-on macht es genau so getrennt: die Discovery-Configs unter homeassistant/sensor/wmbus_<id>/<feld>/config, die eigentlichen Messwerte aber unter wmbusmeters/<id>/state. Beides ist über discovery_prefix / state_prefix konfigurierbar.

8

Erst mal danke für Dein Projekt!
Die Bridge GUI ist echt top.

Der Test mit den XIAO LoRa Boards funktioniert gut, nur S1 gibt kein Signal.
Es werden verschiedene Meter aus der Umgebung angezeigt.

Bis jetzt habe ich noch keinen eigenen Anwendungfall, überlege aber die Wasserzähler Patrone smart zu ersetzen. Vielleicht irgendwelche Empfehlungen? :wink:

9

Danke dir!

Zu S1: das liegt nicht an deinem Aufbau. Ich habe das im August durchgemessen — der SX1262 hat keinen Defekt in der S1-Demodulation, er ist schlicht unempfindlicher. Meine Schwelle am Generator: SX1262 dekodiert bei −82 dBm, bei −85 dBm nicht mehr. Ein SX1276 (LilyGO T3-S3) dekodiert dieselbe Aussendung noch bei −99/−100 dBm. Es fehlen also 3–10 dB, und die gesamte S-Mode-Population hier kommt genau an dieser Schwelle oder darunter an.

Der XIAO ist dabei der schwächste der SX1262-Boards: kein FEM und eine 6-cm-Antenne (0,17 λ, elektrisch zu kurz) — bei mir hat er die höchste Rauschflur im ganzen Testfeld. Praktisch heißt das: SX1262 für T1/C1, SX1276 für S1. Dass du die Meter aus der Umgebung siehst, passt — die senden fast alle in T1/C1. Bevor du Hardware tauschst, bringen aber eine bessere Antenne (3–6 dB) und die Aufstellung (Höhe, weg vom Metall, 5–10 dB) am meisten.

Eine Empfehlung für eine smarte Wasserzähler-Patrone habe ich leider nicht — ich habe selbst keine getauscht und keinen eigenen Anwendungsfall dafür.

10

Kurzes feedback:

Ich hatte noch ein Heltec Wireless Paper V1.2 rumliegen, mit SX1262 (686MHz) Empfänger und Epaper Display. Auch das funktioniert mit wMbus :wink:

11

Hallo,

ich finde die Umsetzungsart eine tolle Idee und habe meine Hardware auf dein Addon umgeflasht.

Lief alles auf Anhieb.

Was mich am Anfang sehr irritiert und im weiteren Verlauf ziemlich genervt hat, ist die penetrante Zweisprachigkeit.

Wer so tief in die Bastelwelt eindringt, kann ganz sicher auch in Polen die paar Brocken englisch verstehen.

Wenn das unbedingt sein soll, so sollte man dann einfach auch den Sourcecode, bzw die Logmeldungen lokalisieren.

Völlig unangebracht finde ich, dass im Git Repo überall zuerst die polnische Version kommt und man endlos scrollen muss, bis man durch Zufall mal sieht, dass es das da unten auch in Englisch gibt.

Das schreckt ziemlich ab. Und nicht nur, weil du es hier alles auf deutsch anpreist…

12

Hallo Simon,

danke für das Feedback, und freut mich, dass alles auf Anhieb lief!

Mit der README hast du recht: Die Startseite des Add-ons ist jetzt auf Englisch, und die Übersetzungen, darunter eine vollständige deutsche Anleitung, sind oben direkt verlinkt. Die Änderung kommt mit dem nächsten Release.

Die Mehrsprachigkeit selbst ist allerdings Absicht. Nicht jeder, der so ein Projekt nutzt, spricht gut Englisch. Ich selbst gehöre auch dazu. Das Add-on ist inzwischen recht umfangreich, deshalb gibt es die Oberfläche und die Anleitung in fünf Sprachen, umschaltbar über die Flaggen. Die ESPHome-Firmware ist nur auf Englisch und Polnisch, das Add-on dagegen bewusst für mehr Nutzer.

Viele Grüße
Krzysztof

13

Hallo Krzysztof,

Schön, dass du meine Anmerkung umgesetzt hast, das wird Nachfolgende sicher weniger abschrecken. :slight_smile: Danke.

Ja, die Lokalisierung an sich ist auch sehr gut. Aber das meinte ich mit “Zweisprachigkeit” garnicht.

Das meinte ich damit. Es verwirrt, wenn im Debuglog hinter der englischen Bezeichnung statt der Daten erstmal etwas in einer “für normale Menschen” unverstänlichen Sprache kommt und erst dann die Nutzdaten.

Hast du sowas schon in anderen Addons gesehn?

Ich selbst habe mich damit “abgefunden”, aber das ist etwas, das ich anders machen würde…

Es ist Kritik auf hohem Niveau, aber es könnte Anderen den Einstieg NOCH einfacher machen.

Ich empfinde dein Addon als das für den Nichtprofi bisher als am einfachsten umzusetzendes System.

Ah, ich habe das Ganze übrigens mit einem c3 und dem cc1101 gebaut.

14

Hallo jaybee,

zuerst: Entschuldigung für das „Simon“ – ich habe den Namen der Seite (simon42) für deinen Namen gehalten.

Und danke für die Erklärung, jetzt habe ich verstanden, was du meintest. Du hast recht: In anderen Projekten habe ich so etwas nicht gesehen, und im Debuglog stört es wirklich.

Ich habe deinen Vorschlag umgesetzt: Das Log der Firmware ist jetzt nur auf Englisch. Die Änderung ist schon im Repo – einfach die Firmware neu kompilieren und flashen.

Und danke für die Info mit dem C3 und dem CC1101 – das ist die erste Rückmeldung von außen, dass diese Kombination auf Anhieb läuft. Das freut mich sehr, genauso wie dein Satz, dass es für Nichtprofis das einfachste System ist.

Viele Grüße
Krzysztof

15

Kein Problem. :slight_smile: Simon ist der “Eigentümer” des Forums.

Ich vermute, wenn er dein Projekt entdeckt, wird er wohl sogar ein YT Video dazu machen. :slight_smile:

Mit der am 1.1. beginnenen Pflicht für fernauslesbare Verbrauchszähler für Vermieter, wird bald ein großer Bedarf an solchen Projekten bestehen.

Und wie gesagt, deine Umsetzung ist die am einfachsten zu realisierende, die ich bisher gesehen habe. Meine Multical 303 funktionieren auf Anhieb damit. Die wurden sofort erkannt und nach dem Anklicken und Eintragen des AES Keys wurden sofort automatisch die entsprechenden Geräte in Homeassitant angelegt und alle Entitäten erstellt.

Und sie ist unschlagbar Günstig. Alles zusammen für unter 10€ und es gibt eine direkte Druckdatei für ein Gehäuse. Da passt sowohl die standard Drahtantenne rein (die übrigens fast so guten Empfang hat, wie die kleinen Stummelantennen), als auch ein externer Antennenanschluss für den 1101.

Dazu baue ich erstmal eine weitere Hardware, die Erste ist nämlich schon in Verwendung :slight_smile:

16

Danke für deine Antwort.

Als ich mich im Februar dieses Jahres daran gesetzt habe, hatte ich nur eine erste Idee im Kopf – ich war selbst mit meiner bisherigen Lösung gegen eine Wand gelaufen. Ich hatte ausschließlich an Nutzer aus meinem Land gedacht und lange gezögert, ob ich das Projekt auch in einem größeren Forum außerhalb Polens teilen soll. Von Anfang an war das Ziel, dass die erste Inbetriebnahme für Einsteiger einfach ist – keine Raketenwissenschaft. Und ich glaube, dieses Ziel habe ich erreicht :slightly_smiling_face:

17

Hast du auf jeden Fall. :slight_smile:

18

Danke dir! :slightly_smiling_face: Dann hat sich die Hartnäckigkeit gelohnt – und die Arbeit mit KI auch. Ohne sie hätte ich das in dieser Form allein nicht geschafft.

19

grafik
grafik1920×934 312 KB

20

Schöner Aufbau! :slightly_smiling_face: Aber warum ist das Gehäuse so pink?