SIGNALESP: Firm- und Hardware für SIGNALduino direkt auf ESP8266 oder ESP32

Ralf9 · 22 Oktober 2026, 22:03:39

mit einem "set rfmode WMBus_T_u_C..." oder " set rfmode WMBus_S..." müsste es jetzt funktionieren.

Bei WMBus_T_u_C steht dann im reading rfmode "WMBus_T_u_C__N12_ab_firmw_V422 => ok,N=12,ccmode=8,mbus_init"

Ein "get cmdBank" ergibt:

Code Auswählen

cmdBank: 
A: b=1 freq:868.950MHz bWidth:325KHz rAmpl:33dB sens:8dB (DataRate:103149.41Baud) [boffs=0100]

   N=12 ccmode=8 sync=543D Modulation:2-FSK (SYNC_MODE:16/16 + carrier-sense above threshold) DEVIATN:38.086kHz

mit "get cmdBank s" siehst Du die Belegung der Bänke

cs-online · 23 Oktober 2026, 17:06:41

Hmmm.... Woran kann ich erkennen,ob da überhaupt irgendwas empfangen wird?

Ein get Version gibt

Code Auswählen

version: V 4.2.3-dev250212 SIGNALduinoAdv ESP32 cc1101 (R: A1* b-) - compiled at Feb 12 2025 13:16:08
Und im Hilfetext steht bei kleinen Buchstaben ist der Empfang deaktiviert. Ich meinte, ich hätte das aktivieren können, unter RAW steht rxA=1, aber egal ob mit 868.950 oder 868.300 MHz, mit Autocreate on wird nichts angelegt, also vermutlich nichts empfangen...

Ralf9 · 23 Oktober 2026, 18:48:57

Nach einem "attr ESPduino verbose 4" kannst Du im log sehen ob was empfangen wird.

Bitte mach mal ein "set rfmode WMBus_..." und poste dann "get ccconf" und "get cmdBank"

cs-online · 24 Oktober 2026, 08:33:17

ccconf liefert

Code Auswählen

ccconf: freq:868.950MHz bWidth:325KHz rAmpl:33dB sens:8dB (DataRate:103149.41Baud)

Modulation:2-FSK (SYNC_MODE:16/16 + carrier-sense above threshold) DEVIATN:38.086kHz

get cmdBank

Code Auswählen

cmdBank: 
A: b=1 freq:868.950MHz bWidth:325KHz rAmpl:33dB sens:8dB (DataRate:103149.41Baud) [boffs=0100]

   N=12 ccmode=8 sync=543D Modulation:2-FSK (SYNC_MODE:16/16 + carrier-sense above threshold) DEVIATN:38.086kHz

Ralf9 · 24 Oktober 2026, 11:10:54

Hast Du mal in der Anleitung geschaut welchen wmbus du benötigst?
Bei wmbus S benötigst Du den rfmode WMBus_S

Evtl hast Du ein cc1011 Modul mit ungenauer Frequenz (ca +- 50 bis 100 kHz), durch einen ungenauen Quarz, erwischt.
Du kannst mal in 0,05 MHz Schritten mit "set cc1101_freq .." nach oben und unten die Frequenz ändern

Reinhard.M · 10 November 2026, 08:21:52

Hallo Ralf,
zum Thema wM-Bus Paketverluste (Empfang ist nicht regelmäßig, Verluste) habe ich etwas für dich. Den angefügten Text hat Claude für mich geschrieben.

Ich betreibe zwei Maple-SIGNALduinos (4.2.2-dev220712, WMBusT_C) für einen Sensus-iPERL-Wasserzähler. Beide Sticks haben jeweils 30–50 % der Telegramme verloren, auch bei −28 dBm Pegel. Ein RTL-SDR daneben hat alle empfangen. Mit TD sah jedes verlorene Telegramm gleich aus: L=53, danach kein mb L= mehr. Die Ursache ist ein Wettrennen am Paketende in mbus_task() : Endet das Paket genau zwischen der GDO2-Abfrage und dem mbus_on(FALSE) am Ende des Durchlaufs, ist der CC1101 schon IDLE. mbus_on() leert dann den FIFO mit dem fertig empfangenen Telegramm.
Mit einer kleinen Änderung in mbus.h (kein Neustart, solange RXinfo.state > 1, plus 100-ms-Absicherung) empfängt der Stick mit gutem Pegel jetzt 21 von 21 Telegrammen statt etwa der Hälfte.
Ausführliche Beschreibung, Messwerte und Patch findest du im Pull Request: [Link zum Pull Request]
Viele Grüße Reinhard

cs-online · 12 November 2026, 20:06:14

Danke dir ! ich habe das ganze zumindest vorübergehend aufgegeben,meiner hat gar nichts empfangen,egal was ich probiert habe, inzwischen bin ich mir nicht Mal mehr sicher, dass der Zähler überhaupt und wenn, unverschlüsselt sendet, man findet unterschiedliche Beschreibungen zu dem Ding und mir fehlt die Zeit dazu, noch lange daran Rum zu doktorn...

Ralf9 · 13 November 2026, 00:22:06

Hallo Reinhard,

mit Claude habe ich bis jetzt noch nichts gemacht.

Zitat von: Reinhard.M am 10 November 2026, 08:21:52Die Ursache ist ein Wettrennen am Paketende in mbus_task() : Endet das Paket genau zwischen der GDO2-Abfrage und dem mbus_on(FALSE) am Ende des Durchlaufs, ist der CC1101 schon IDLE. mbus_on() leert dann den FIFO mit dem fertig empfangenen Telegramm.

Das ist aber ein sehr kurzer Zeitabstand, gefühlt müssten da die Paketverluste sehr gering sein. Evtl hängt dies stark von der Paketlänge ab.

Als Fix sollte dann aber auch funktionieren, wenn bei IDLE ein mbus_on() Aufruf übersprungen wird.
Ungefähr so:

Code Auswählen

init:
RXinfo.idleFlag = false;

if (RXinfo.state > 1) {
   if (cc1101::getMARCSTATE() != MARCSTATE_RX) {  // idle?
      if (RXinfo.idleFlag == false) {
         RXinfo.idleFlag = true;
      } else {
         mbus_on( FALSE );
      }
   }
} else {
  mbus_on( FALSE );
}

Gruß Ralf

Reinhard.M · 13 November 2026, 09:13:21

Grüß dich Ralf

Wie geschrieben habe ich auf GitHub einen Pull Request eingestellt mit ausführlicher Beschreibung und fertigem Fix. Der läuft bei mir jetzt schon seit einiger Zeit und hat deutliche Verbesserung gebracht.
Code Änderungen und Fehlersuche im Code überlasse ich Claude, ich analysiere in erster Linie und mache Vorgaben für Testläufe, Analysefunktionen, Testbenches und die eigentlichen Tests. Wo nötig mache ich Architektur Vorgaben. Die Handarbeit überlasse ich Claude, die Kiste ist da einfach wesentlich schneller und kennt die Syntax oder das IDE wesentlich besser als ich.
Ich bin inzwischen komplett von FHEM auf Home Assistant umgezogen, Jarolift, der wmBus, LaCross08 und ASControl waren meine letzten FHEM Bausteine. Für Jarolift bin ich auf einen ESP32 umgestiegen und verwende dafür https://github.com/Banabas/ESP32-Jarolift-PositionController. In dem Code waren einige Unzulänglichkeiten die ich wiederum mit Hilfe von Claude gefunden und gefixt habe. Die wmBus und LaCross Abfrage ist in Node-RED realisiert, das war auch die Testumgebung auf die der angehängte Bericht basiert. Als Ersatz für ASControl habe ich eigene Integrationen in HA aufgebaut. Alles mit dem Support von Claude, die Integrationen haben gerade mal 2 Tage in Anspruch genommen und decken alle für mich relevanten Themen aus ASControl ab.
Wie gesagt im Anhang eine Zusammenfassung der wmBus Analyse. Sollte jemand darüber hinaus Interesse an meinen Erfahrungen bezüglich dem Umstieg von FHEM auf HA oder der Arbeit mit KI im Smart Home Umfeld haben, meldet euch

Dir, Ralf, möchte ich an dieser Stelle einmal mehr für deinen unermüdlichen und geduldigen Support danken, das ist nicht selbstverständlich und sollte auch mal gewürdigt werden. Auch wenn es weniger und seltener geworden ist, ich verwende die Sduinos weiterhin und habe noch immer ein Ohr am Forum.

Gruß Reinhard