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

Begonnen von Ralf9, 24 Januar 2018, 20:04:44

Vorheriges Thema - Nächstes Thema

Ralf9

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:
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
FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7

cs-online

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

Ein get Version gibt 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...
FHEM auf DELL Thinclient, HM-WLAN-Gateway, einige HM-Aktoren,2x EBUSD an Heizung+Solar, ESP8266/32 am Strom-,Gas-,Wasserzähler, in WLAN-Steckdosen und Relaisleisten, Sonoff S20+S26,Shelly1/2/2.5, Lacrosse-Gateway+Sensoren,Sduino,Alexa-Fhem,Huawei PV+Speicher, alles auf einem TC und da geht noch mehr

Ralf9

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"
FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7

cs-online

ccconf liefert

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

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
FHEM auf DELL Thinclient, HM-WLAN-Gateway, einige HM-Aktoren,2x EBUSD an Heizung+Solar, ESP8266/32 am Strom-,Gas-,Wasserzähler, in WLAN-Steckdosen und Relaisleisten, Sonoff S20+S26,Shelly1/2/2.5, Lacrosse-Gateway+Sensoren,Sduino,Alexa-Fhem,Huawei PV+Speicher, alles auf einem TC und da geht noch mehr

Ralf9

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
FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7

Reinhard.M

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