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

[dadoc]

Guten Abend,
ich habe jetzt die drei Wärmezähler aufgerüstet (1 x Funkmodul, 2 x Impulszähler) und entsprechend verkabelt und das Ganze per IR-Lesekopf und Software parametriert.
Und das sieht schon mal prima aus, denn der Espduino, nach Umstellung auf rfmode MBUS T, empfängt.
Nur das Anlegen eines MBUS Geräts klappt noch nicht:

Code Auswählen Erweitern

2022.09.30 18:42:28 4: mkduino3/msg READ: MN;D=5146C514461787940004DCCA7ABE0000002F2F046D1C31DE290406CBF737C3000001FD17400413BE4C6200043B54C0DE000000042BFF030000025B4000025F3650C80002611D0484C040130000000003FD0CD85505000002FD0B1031E4CB810F;N=12;
2022.09.30 18:42:28 4: mkduino3 Parse_MN: Found 2-FSK Protocol id 209 length 192 RSSI = -66.5 LQI = 129 -> WMBUS T
2022.09.30 18:42:28 4: mkduino3 ParseMN: ID=209 dmsg=b5146C514461787940004DCCA7ABE0000002F2F046D1C31DE290406CBF737C3000001FD17400413BE4C6200043B54C0DE000000042BFF030000025B4000025F3650C80002611D0484C040130000000003FD0CD85505000002FD0B1031E4CB810F
2022.09.30 18:42:28 4: mkduino3 Dispatch: b5146C514461787940004DCCA7ABE0000002F2F046D1C31DE290406CBF737C3000001FD17400413BE4C6200043B54C0DE000000042BFF030000025B4000025F3650C80002611D0484C040130000000003FD0CD85505000002FD0B1031E4CB810F,  dispatch
2022.09.30 18:42:28 1: reload: Error:Modul 36_WMBUS deactivated:
Attempt to reload WMBus.pm aborted.
Compilation failed in require at ./FHEM/36_WMBUS.pm line 13.
BEGIN failed--compilation aborted at ./FHEM/36_WMBUS.pm line 13.

2022.09.30 18:42:28 0: Attempt to reload WMBus.pm aborted.
Compilation failed in require at ./FHEM/36_WMBUS.pm line 13.
BEGIN failed--compilation aborted at ./FHEM/36_WMBUS.pm line 13.

2022.09.30 18:42:28 0: ERROR: Cannot autoload WMBUS
2022.09.30 18:42:28 3: mkduino3: Unknown code b5146C514461787940004DCCA7ABE0000002F2F046D1C31DE290406CBF737C3000001FD17400413BE4C6200043B54C0DE000000042BFF030000025B4000025F3650C80002611D0484C040130000000003FD0CD85505000002FD0B1031E4CB810F, help me!
2022.09.30 18:42:29 4: mkduino3/msg READ: MN;D=3046C5144617879400049AD17249178794C514020CBE0000002F2F042B186D1C31DE298440060000000003FD0C05541C000002FD0B10335EEF8A0F;N=12;
2022.09.30 18:42:29 4: mkduino3 Parse_MN: Found 2-FSK Protocol id 209 length 118 RSSI = -66.5 LQI = 138 -> WMBUS T
2022.09.30 18:42:29 4: mkduino3 ParseMN: ID=209 dmsg=b3046C5144617879400049AD17249178794C514020CBE0000002F2F042B186D1C31DE298440060000000003FD0C05541C000002FD0B10335EEF8A0F
2022.09.30 18:42:29 4: mkduino3 Dispatch: b3046C5144617879400049AD17249178794C514020CBE0000002F2F042B186D1C31DE298440060000000003FD0C05541C000002FD0B10335EEF8A0F,  dispatch
2022.09.30 18:42:29 1: reload: Error:Modul 36_WMBUS deactivated:
Attempt to reload WMBus.pm aborted.
Compilation failed in require at ./FHEM/36_WMBUS.pm line 13.
BEGIN failed--compilation aborted at ./FHEM/36_WMBUS.pm line 13.

2022.09.30 18:42:29 0: Attempt to reload WMBus.pm aborted.
Compilation failed in require at ./FHEM/36_WMBUS.pm line 13.
BEGIN failed--compilation aborted at ./FHEM/36_WMBUS.pm line 13.

2022.09.30 18:42:29 0: ERROR: Cannot autoload WMBUS
2022.09.30 18:42:29 3: mkduino3: Unknown code b3046C5144617879400049AD17249178794C514020CBE0000002F2F042B186D1C31DE298440060000000003FD0C05541C000002FD0B10335EEF8A0F, help me!
Ralf: Braucht man dafür auch ein modifiziertes 36_WMBUS.pm?

[Ralf9]

siehe hier
https://forum.fhem.de/index.php/topic,24517.msg1237302.html#msg1237302

[Ralf9]

Ich habe die Zusammenfassung zu meiner ESP32 firmware, in den ersten Beitrag hier verschoben.
Ich habe auch die Seite mit den rfmodes überarbeitet
https://forum.fhem.de/index.php/topic,106594.msg1005067.html#msg1005067



Das mit dem Autoreconnect habe ich mal mit einer Fritzbox getestet.

Ich habe die ESP32 board Version 1.06 und den Wifimanager 2.0.11 und 2.0.12 (die 2.0.13 bringt beim kompilieren Fehler) verwendet.
Beim Ändern des Wlan Kanals hat der reconnect fast immer funktioniert.

Im seriellen Monitor der Arduino IDE wurde dabei folgendes ausgegeben:

Code Auswählen Erweitern

WiFi lost connection. Reason: 200
*wm:[2] [EVENT] WIFI_REASON:  200
WiFi lost connection. Reason: 201
*wm:[2] [EVENT] WIFI_REASON:  201
*wm:[2] [EVENT] WIFI_REASON: NO_AP_FOUND
WiFi lost connection. Reason: 4
---WiFi try reconnect---
*wm:[2] [EVENT] WIFI_REASON:  4
WiFi lost connection. Reason: 205
*wm:[2] [EVENT] WIFI_REASON:  205
*******Connected*****


Evtl verhält es sich beim automatischen Kanalwechsel anders.

Kann mal bitte jemand von Euch den ESP32 an den PC anschließen und die Debugausgaben posten, wenn beim automatischem Kanalwechsel der reconnect nicht funktioniert?



Ich habs auch mal mit der ESP32 board Version 2.0.4 versucht.

Es werden damit weniger wifi Events ausgegeben als mit dem board 1.06

Ich habs mal damit versucht:
https://randomnerdtutorials.com/solved-reconnect-esp32-to-wifi/

Damit hat der reconnect nicht funktioniert
Ich bekomme die folgende Debugausgaben:
Im "WiFi try reconnect(loop)" mache ich ein WiFi.reconnect()

Code Auswählen Erweitern


WiFi lost connection. Reason: 200
*wm:[2] [EVENT] WIFI_REASON:  200
---WiFi try reconnect(loop)---
---WiFi try reconnect(loop)---
WiFi lost connection. Reason: 201
*wm:[2] [EVENT] WIFI_REASON:  201
*wm:[2] [EVENT] WIFI_REASON: NO_AP_FOUNE (94533) wifi:sta is connecting, return error
D---WiFi try reconnect(loop)---
evtl hängt es mit dieser Ausgabe zusammen

Code Auswählen Erweitern

E (94533) wifi:sta is connecting, return error

[dadoc]

Hallo Ralf,

siehe hier
https://forum.fhem.de/index.php/topic,24517.msg1237302.html#msg1237302

Danke, ich habe dort dann auch ausführlich geposted, aber der Thread scheint ziemlich inaktiv (hatte dort seinerzeit auch meine allererste Anfrage zum Thema gestellt, die ohne Antwort blieb).
Der Esp32 empängt eifrig vom WMBUS-Modul des Wärmezählers. Wie oft gesendet wird (schwankt stark) und warum immer mal wieder etwas anderes gesendet wird weiß ich nicht, und ich kann noch weniger einschätzen, ob das am Espduino liegt oder am FMBUS-Modul.

Könnte es sein, dass in der Espduino-Firmware der Puffer zu klein ist für größere Datenpakete? Man hat das Gefühl, dass das Umsetzen der Werte in Readings an irgendeinem Punkt "abgeschnitten" wird, in der Regel geht es bis max. Reading #11.

Ich habe versucht, mit notify- und doif-Workarounds die Daten der Telegramme dem jeweiligen Zähler zuzuordnen, klappt aber nicht zuverlässig. Es ist zwar unschön, dass ich die Daten aus den drei Zählern in fhem nicht eindeutig zugeordnet bekomme; in der Praxis derzeit aber nicht so schlimm, da die drei Zähler deutlich unterschiedliche Stände haben und ich daher weiß, welcher neue Wert zu welchem Zähler gehört.

Ich habe es auch mal mit der manuellen Konfiguration des Inhalts des MBUS-Telegramms mittels der Device Monitor Software versucht. Da lassen sich zwar die einzelnen Telegrammelemente auswählen und als Konfiguration auf den Zähler übertragen (und auch korrekt wieder auslesen); ich habe jedoch keine Veränderung beim empfangenen Telegramm ausmachen können, außer dass die plötzlich sehr unregelmäßig empfangen wurden.

Auch habe ich die Umstellung des Zählers auf den S-Mode versucht (angeblich möglich), aber die Einstellung S bleibt nicht erhalten.

Kann mal bitte jemand von Euch den ESP32 an den PC anschließen und die Debugausgaben posten, wenn beim automatischem Kanalwechsel der reconnect nicht funktioniert?

Was das Autokanal-Problem betrifft: Bei mir war das mit 2.0.12beta. Sobald ich mal wieder einen PC im Keller habe, kann ich versuchen, ob ich den Esp32 beim automatischen Kanalwechsel "erwische" - dürfte allerdings viel Geduld erfordern.
Hast Du es auch mal mit verborgenem AP getestet?

[Ralf9]

Danke, ich habe dort dann auch ausführlich geposted, aber der Thread scheint ziemlich inaktiv (hatte dort seinerzeit auch meine allererste Anfrage zum Thema gestellt, die ohne Antwort blieb).

Ja, der maintainer vom WMBUS Modul @kaihs war das letzte mal am 26.07.2022 online.

Könnte es sein, dass in der Espduino-Firmware der Puffer zu klein ist für größere Datenpakete?

Der Puffer sollte groß genug sein. Der Empfangspuffer hat 584 Bytes.
Der Puffer für die dekodierte Pakete, die dann als MN Nachricht ausgegeben werden, hat 291 Byte

Was das Autokanal-Problem betrifft: Bei mir war das mit 2.0.12beta

Die 2.0.12beta ist vermutlich die WiFi Manager Version, mich interessiert die ESP Firmware Version (im Boardmanager nach ESP32 filtern)

[dadoc]

Der Puffer sollte groß genug sein. Der Empfangspuffer hat 584 Bytes.
Der Puffer für die dekodierte Pakete, die dann als MN Nachricht ausgegeben werden, hat 291 Byte

Denke ich mittlerweile auch, denn die Daten kommen ja im Log an. Beim "großen" Datenpaket mit den Daten der drei Zähler, das nach mir noch nicht einleuchtenden zeitlichen Kriterien verschickt bzw. empfangen wird, handelts es sich wohl um drei einzelne Pakete. Das sieht z.B. so aus:

Code Auswählen Erweitern

2022-10-07_16:11:45 WMBUS_EFE_94871746_0_4 RSSI: -138
2022-10-07_16:11:45 WMBUS_EFE_94871746_0_4 LQI: 166
2022-10-07_16:11:45 WMBUS_EFE_94871746_0_4 1_type: VIF_TIME_POINT_DATE_TIME
2022-10-07_16:11:45 WMBUS_EFE_94871746_0_4 1_storage_no: 0
2022-10-07_16:11:45 WMBUS_EFE_94871746_0_4 1_value: 2022-10-07 16:10
2022-10-07_16:11:45 WMBUS_EFE_94871746_0_4 1_unit:
2022-10-07_16:11:45 WMBUS_EFE_94871746_0_4 1_value_type: Instantaneous value
2022-10-07_16:11:45 WMBUS_EFE_94871746_0_4 2_type: VIF_ENERGY_WATT
2022-10-07_16:11:45 WMBUS_EFE_94871746_0_4 2_storage_no: 0
2022-10-07_16:11:45 WMBUS_EFE_94871746_0_4 2_value: 50454000
2022-10-07_16:11:45 WMBUS_EFE_94871746_0_4 2_unit: Wh
2022-10-07_16:11:45 WMBUS_EFE_94871746_0_4 2_value_type: Instantaneous value
2022-10-07_16:11:45 WMBUS_EFE_94871746_0_4 3_type: VIF_ERROR_FLAGS
2022-10-07_16:11:45 WMBUS_EFE_94871746_0_4 3_storage_no: 0
2022-10-07_16:11:45 WMBUS_EFE_94871746_0_4 3_value: 3634
2022-10-07_16:11:45 WMBUS_EFE_94871746_0_4 3_unit:
2022-10-07_16:11:45 WMBUS_EFE_94871746_0_4 3_value_type: Instantaneous value
2022-10-07_16:11:45 WMBUS_EFE_94871746_0_4 4_type: VIF_VOLUME
2022-10-07_16:11:45 WMBUS_EFE_94871746_0_4 4_storage_no: 0
2022-10-07_16:11:45 WMBUS_EFE_94871746_0_4 4_value: 6470.626
2022-10-07_16:11:45 WMBUS_EFE_94871746_0_4 4_unit: m³
2022-10-07_16:11:45 WMBUS_EFE_94871746_0_4 4_value_type: Instantaneous value
2022-10-07_16:11:45 WMBUS_EFE_94871746_0_4 5_type: VIF_VOLUME_FLOW
2022-10-07_16:11:45 WMBUS_EFE_94871746_0_4 5_storage_no: 0
2022-10-07_16:11:45 WMBUS_EFE_94871746_0_4 5_value: 0.149
2022-10-07_16:11:45 WMBUS_EFE_94871746_0_4 5_unit: m³/h
2022-10-07_16:11:45 WMBUS_EFE_94871746_0_4 5_value_type: Instantaneous value
2022-10-07_16:11:45 WMBUS_EFE_94871746_0_4 6_type: VIF_ELECTRIC_POWER
2022-10-07_16:11:45 WMBUS_EFE_94871746_0_4 6_storage_no: 0
2022-10-07_16:11:45 WMBUS_EFE_94871746_0_4 6_value: 225
2022-10-07_16:11:45 WMBUS_EFE_94871746_0_4 6_unit: W
2022-10-07_16:11:45 WMBUS_EFE_94871746_0_4 6_value_type: Instantaneous value
2022-10-07_16:11:45 WMBUS_EFE_94871746_0_4 7_type: VIF_FLOW_TEMP
2022-10-07_16:11:45 WMBUS_EFE_94871746_0_4 7_storage_no: 0
2022-10-07_16:11:45 WMBUS_EFE_94871746_0_4 7_value: 30
2022-10-07_16:11:45 WMBUS_EFE_94871746_0_4 7_unit: °C
2022-10-07_16:11:45 WMBUS_EFE_94871746_0_4 7_value_type: Instantaneous value
2022-10-07_16:11:45 WMBUS_EFE_94871746_0_4 8_type: VIF_RETURN_TEMP
2022-10-07_16:11:45 WMBUS_EFE_94871746_0_4 8_storage_no: 0
2022-10-07_16:11:45 WMBUS_EFE_94871746_0_4 8_value: 29
2022-10-07_16:11:45 WMBUS_EFE_94871746_0_4 8_unit: °C
2022-10-07_16:11:45 WMBUS_EFE_94871746_0_4 8_value_type: Instantaneous value
2022-10-07_16:11:45 WMBUS_EFE_94871746_0_4 9_type: VIF_TEMP_DIFF
2022-10-07_16:11:45 WMBUS_EFE_94871746_0_4 9_storage_no: 0
2022-10-07_16:11:45 WMBUS_EFE_94871746_0_4 9_value: 1.29
2022-10-07_16:11:45 WMBUS_EFE_94871746_0_4 9_unit: K
2022-10-07_16:11:45 WMBUS_EFE_94871746_0_4 9_value_type: Instantaneous value
2022-10-07_16:11:45 WMBUS_EFE_94871746_0_4 10_type: VIF_MODEL_VERSION
2022-10-07_16:11:45 WMBUS_EFE_94871746_0_4 10_storage_no: 0
2022-10-07_16:11:45 WMBUS_EFE_94871746_0_4 10_value: 18446744073625665536
2022-10-07_16:11:45 WMBUS_EFE_94871746_0_4 10_unit:
2022-10-07_16:11:45 WMBUS_EFE_94871746_0_4 10_value_type: Instantaneous value
2022-10-07_16:11:45 WMBUS_EFE_94871746_0_4 11_type: VIF_PARAMETER_SET_ID
2022-10-07_16:11:45 WMBUS_EFE_94871746_0_4 11_storage_no: 0
2022-10-07_16:11:45 WMBUS_EFE_94871746_0_4 11_value: 12560
2022-10-07_16:11:45 WMBUS_EFE_94871746_0_4 11_unit:
2022-10-07_16:11:45 WMBUS_EFE_94871746_0_4 11_value_type: Instantaneous value
2022-10-07_16:11:45 WMBUS_EFE_94871746_0_4 batteryState: ok
2022-10-07_16:11:45 WMBUS_EFE_94871746_0_4 is_encrypted: 1
2022-10-07_16:11:45 WMBUS_EFE_94871746_0_4 decryption_ok: 1
2022-10-07_16:11:45 WMBUS_EFE_94871746_0_4 no errors
2022-10-07_16:11:45 WMBUS_EFE_94871746_0_4 rawmsg: Y
2022-10-07_16:11:46 WMBUS_EFE_94871746_0_4 RSSI: -137.5
2022-10-07_16:11:46 WMBUS_EFE_94871746_0_4 LQI: 97
2022-10-07_16:11:46 WMBUS_EFE_94871746_0_4 1_type: VIF_TIME_POINT_DATE_TIME
2022-10-07_16:11:46 WMBUS_EFE_94871746_0_4 1_storage_no: 0
2022-10-07_16:11:46 WMBUS_EFE_94871746_0_4 1_value: 2022-10-07 16:10
2022-10-07_16:11:46 WMBUS_EFE_94871746_0_4 1_unit:
2022-10-07_16:11:46 WMBUS_EFE_94871746_0_4 1_value_type: Instantaneous value
2022-10-07_16:11:46 WMBUS_EFE_94871746_0_4 2_type: VIF_ENERGY_WATT
2022-10-07_16:11:46 WMBUS_EFE_94871746_0_4 2_storage_no: 0
2022-10-07_16:11:46 WMBUS_EFE_94871746_0_4 2_value: 61171000
2022-10-07_16:11:46 WMBUS_EFE_94871746_0_4 2_unit: Wh
2022-10-07_16:11:46 WMBUS_EFE_94871746_0_4 2_value_type: Instantaneous value
2022-10-07_16:11:46 WMBUS_EFE_94871746_0_4 3_type: VIF_MODEL_VERSION
2022-10-07_16:11:46 WMBUS_EFE_94871746_0_4 3_storage_no: 0
2022-10-07_16:11:46 WMBUS_EFE_94871746_0_4 3_value: 18446744073625665536
2022-10-07_16:11:46 WMBUS_EFE_94871746_0_4 3_unit:
2022-10-07_16:11:46 WMBUS_EFE_94871746_0_4 3_value_type: Instantaneous value
2022-10-07_16:11:46 WMBUS_EFE_94871746_0_4 4_type: VIF_PARAMETER_SET_ID
2022-10-07_16:11:46 WMBUS_EFE_94871746_0_4 4_storage_no: 0
2022-10-07_16:11:46 WMBUS_EFE_94871746_0_4 4_value: 13072
2022-10-07_16:11:46 WMBUS_EFE_94871746_0_4 4_unit:
2022-10-07_16:11:46 WMBUS_EFE_94871746_0_4 4_value_type: Instantaneous value
2022-10-07_16:11:46 WMBUS_EFE_94871746_0_4 batteryState: ok
2022-10-07_16:11:46 WMBUS_EFE_94871746_0_4 is_encrypted: 1
2022-10-07_16:11:46 WMBUS_EFE_94871746_0_4 decryption_ok: 1
2022-10-07_16:11:46 WMBUS_EFE_94871746_0_4 no errors
2022-10-07_16:11:46 WMBUS_EFE_94871746_0_4 rawmsg: Y
2022-10-07_16:11:47 WMBUS_EFE_94871746_0_4 RSSI: -138
2022-10-07_16:11:47 WMBUS_EFE_94871746_0_4 LQI: 5
2022-10-07_16:11:47 WMBUS_EFE_94871746_0_4 1_type: VIF_TIME_POINT_DATE_TIME
2022-10-07_16:11:47 WMBUS_EFE_94871746_0_4 1_storage_no: 0
2022-10-07_16:11:47 WMBUS_EFE_94871746_0_4 1_value: 2022-10-07 16:10
2022-10-07_16:11:47 WMBUS_EFE_94871746_0_4 1_unit:
2022-10-07_16:11:47 WMBUS_EFE_94871746_0_4 1_value_type: Instantaneous value
2022-10-07_16:11:47 WMBUS_EFE_94871746_0_4 2_type: VIF_ENERGY_WATT
2022-10-07_16:11:47 WMBUS_EFE_94871746_0_4 2_storage_no: 0
2022-10-07_16:11:47 WMBUS_EFE_94871746_0_4 2_value: 20551000
2022-10-07_16:11:47 WMBUS_EFE_94871746_0_4 2_unit: Wh
2022-10-07_16:11:47 WMBUS_EFE_94871746_0_4 2_value_type: Instantaneous value
2022-10-07_16:11:47 WMBUS_EFE_94871746_0_4 3_type: VIF_MODEL_VERSION
2022-10-07_16:11:47 WMBUS_EFE_94871746_0_4 3_storage_no: 0
2022-10-07_16:11:47 WMBUS_EFE_94871746_0_4 3_value: 18446744073625665536
2022-10-07_16:11:47 WMBUS_EFE_94871746_0_4 3_unit:
2022-10-07_16:11:47 WMBUS_EFE_94871746_0_4 3_value_type: Instantaneous value
2022-10-07_16:11:47 WMBUS_EFE_94871746_0_4 4_type: VIF_PARAMETER_SET_ID
2022-10-07_16:11:47 WMBUS_EFE_94871746_0_4 4_storage_no: 0
2022-10-07_16:11:47 WMBUS_EFE_94871746_0_4 4_value: 13328
2022-10-07_16:11:47 WMBUS_EFE_94871746_0_4 4_unit:
2022-10-07_16:11:47 WMBUS_EFE_94871746_0_4 4_value_type: Instantaneous value
2022-10-07_16:11:47 WMBUS_EFE_94871746_0_4 batteryState: ok
2022-10-07_16:11:47 WMBUS_EFE_94871746_0_4 is_encrypted: 1
2022-10-07_16:11:47 WMBUS_EFE_94871746_0_4 decryption_ok: 1
2022-10-07_16:11:47 WMBUS_EFE_94871746_0_4 no errors
2022-10-07_16:11:47 WMBUS_EFE_94871746_0_4 rawmsg: Y
Abgesehen davon, dass die Raw Message immer nur als Y gespeichert wird, ist es wohl so, dass die Daten der drei Zähler im Abstand von 1s eintrudeln und immer die gerade eine Sekunde davor empfangenen Verbrauchs-Readings (und andere) überschreiben, da diese gleich heißen (0_4 2_value). Mir ist wie gesagt nicht klar, ob dies auf den Esp32 oder auf das WMBUS-Modul zurückzuführen ist.

Daneben gibt es noch Sendungen mit den Verbauchsdaten von einem oder von zwei (in unterschiedlichen Kombinationen) Zählern.
Im Idealfall müsste es wohl möglich sein, dass in dieser Hardware-Konstellation statt eines drei Devices in fhem angelegt werden, eines für den Zähler mit dem Funkmodul, und jeweils eines für die Impulszähler. Oder dass die Readings pro VIF_PARAMETER_SET_ID unterschiedlich benannt werden.

Manchmal taucht übrigens auch so etwas auf:

Code Auswählen Erweitern

2022-10-07_16:42:22 WMBUS_EFE_94871746_0_4 RSSI: -128.5
2022-10-07_16:42:22 WMBUS_EFE_94871746_0_4 LQI: 200
2022-10-07_16:42:22 WMBUS_EFE_94871746_0_4 Decryption mode 7 failed, wrong key?
Vorher und danach klappt die Dekodierung ohne Meckern.

Die 2.0.12beta ist vermutlich die WiFi Manager Version, mich interessiert die ESP Firmware Version (im Boardmanager nach ESP32 filtern)

Esp-Firmware im Arduino IDE ist 1.0.6

[mirko_s]

Hallo zusammen,
in den letzen 4 Jahren habe ich zwei Selbstbau CUL mit 433 MHz und 868 MHz (für Intertechno & WMBus) betrieben. Mit dem WMBus habe ich allerdings so meine Probleme. Ständig ist der Buffer der Arduino Nano zum dekodieren zu klein und ich dachte (hoffe) das die Probleme mit einem ESP32 der Vergangenheit angehören müssten.

Beim Stöbern bin ich nun auf diesen Thread gestoßen, leider muss ich sagen das für mich als Neuling die Begriffe total verwirrend sind. SIGNALESP, SIGNALDuino, sduino, wlanCUN, Maple Mini und viele mehr.

Gibt es (Stand Oktober 2022) ein "Best Practice" Bauvorschlag für einen (kombinierten) 433 MHz und 868 MHz Empfänger? Also alles an einer Stelle, die Hardware (ESP32 + CC1101) inkl. Software und FHEM Befehle. Also eine eine einzige Seite bzw. Post wo alles beschrieben ist um Erfolg in FHEM zu haben?

Versteht mich nicht falsch, ich bin nicht zu faul zum Suchen aber leider ist es für einen Anfänger total verwirrend wenn es zig Module und zig Begriffe gibt.
@Ralf9, wäre es möglich das du deinen ersten Post hier Einsteigerfreundlich und mit einer klaren Empfehlung überarbeitest?

Danke und Gruß
Mirko

[Ralf9]

Hallo @dadoc

Mir ist wie gesagt nicht klar, ob dies auf den Esp32 oder auf das WMBUS-Modul zurückzuführen ist.

Dies "94871746_0_4" kommt vom Funkmodul und wird von der sduino Firmware an das WMBUS Modul weitergereicht.
Wenn sich im Funkmodul das 0_4 nicht pro Wärmemengenzähler konfigurieren lässt, dann müsstest Du in jeden Wärmemengenzähler ein extra Funkmodul einbauen.

Esp-Firmware im Arduino IDE ist 1.0.6

Ok, die Firmware passt.

Das erklärt auch, warum der andere Sduino die Verbindung nicht verliert, denn die Box im Dachgeschoss macht anscheinend trotz aktivem Autokanal keine Kanalwechsel (mangels Notwendigkeit?).

Wenn Du am Handy ein Hotspot mit dem selben WLAN Kanal aktivierst, dann müsste doch die Box im Dachgeschoss auch den Kanal wechseln?

[Ralf9]

Gibt es (Stand Oktober 2022) ein "Best Practice" Bauvorschlag für einen (kombinierten) 433 MHz und 868 MHz Empfänger?

Nein, momentan gibts dafür noch keine Platine.
Bei nur einem cc1101 Modul müsste die Verkabelung gut machbar sein.

Gruß Ralf

[mirko_s]

Hallo Ralf, mir ging es nicht um eine Platine. Ich würde mir so ein Teil schon selber zusammenlöten. Nur sind die ganzen Informationen total verstreut.

Was würdest du mir stand Oktober 2022 konkret empfehlen? Ich möchte 433MHz und 868MHz (WMBus) empfangen.

In deinem ersten Post hast du diesen Post https://forum.fhem.de/index.php/topic,83273.msg1234529.html#msg1234529 bezüglich Verkabelung verlinkt. Bei den Screenshots steht aber "ESP32_sduino". Ich hatte es bis jetzt so verstanden das der Begriff "sduino" bzw. SIGNALduino auf einen Arduino (wie bei einem nanoCUL) hindeutet. Hier wird der Begriff scheinbar für einen ESP32 verwendet wird....

Auch habe ich gelesen das der ESP32 Probleme mit dem Kanalwechsel im WLAN machen soll. Ist das immer noch so und wäre in diesem Fall ein ESP8266 dem ESP32 vorzuziehen?

Wenn ich nur zwei CC1101 an dem ESP32 anschließen würde, kann ich den dritten einfach weglassen oder muss in der Firmware etwas konfiguriert werden?

[Ralf9]

Was würdest du mir stand Oktober 2022 konkret empfehlen? Ich möchte 433MHz und 868MHz (WMBus) empfangen.

Dies hängt von der Art der Anbindung ab:
USB oder LAN: MapleSduino oder MapleCul
WLAN: ESP32 sduino

"sduino" bzw. SIGNALduino ist ein allgemeiner Begriff für die SIGNALduino Hardware, dies kann ein Arduino, MapleMini oder ESP sein.

Wenn ich nur zwei CC1101 an dem ESP32 anschließen würde, kann ich den dritten einfach weglassen oder muss in der Firmware etwas konfiguriert werden?

Per Default ist nur das cc1101 Modul B aktiv und der Bank 0 zugeordnet.
Weitere cc1101 müssen aktiviert und einer Bank zugeordnet werden, ich werde dies und das mit den rfmodes noch etwas ausführlicher beschreiben.
Es müssen nur die cc1101 Module verkabelt werden, die auch benötigt werden.

@Ralf9, wäre es möglich das du deinen ersten Post hier Einsteigerfreundlich und mit einer klaren Empfehlung überarbeitest?

Gibts außer dem aktivieren der cc1101, der Bankzuordnung und den rfmodes noch was anderes wo Einsteigerfreundlicher sein sollte?

Auch habe ich gelesen das der ESP32 Probleme mit dem Kanalwechsel im WLAN machen soll. Ist das immer noch so und wäre in diesem Fall ein ESP8266 dem ESP32 vorzuziehen?

Meine sduino firmware läuft nur auf dem ESP32
Die ESP firmware muss sich nebenher auch noch um andere Sachen wie z.B. das WLAN kümmern, da der ESP8266 nur einen core hat, ist dies sehr schwierig das in der sduino firmware so hinzubekommen, daß der ESP8266 noch genügend Zeit für seine internen Sachen bekommt. Der ESP32 hat dafür einen zweiten core.

Ja, das mit dem reconnect beim Kanalwechsel funktioniert noch nicht so richtig. Wenn ich zum Testen in der Fritzbox den WLAN Kanal ändere funktioniert der reconnect meistens, aber nicht immer.
Evtl verhält es sich beim Autokanal anders.
Es gibt dafür ja einen einfachen Workaround, es muss nur das mit dem Autokanal deaktiviert werden.
Ein Autokanal dürfte doch nur in sehr wenigen Fällen notwendig sein.
Als Gründe für einen automatischen Kanalwechsel fallen mir ein:
- Ein WLAN in der Nähe ist nicht immer aktiv. In der Zeit wo das andere WLAN nicht aktiv ist, kann per Autokanal auf dessen Kanäle gewechselt werden.
- Ein WLAN in der Nähe hat per Autokanal auf andere Kanäle gewechselt.

Gruß Ralf

[dadoc]

Moin Ralf,

Dies "94871746_0_4" kommt vom Funkmodul und wird von der sduino Firmware an das WMBUS Modul weitergereicht.

Das ist die (außen aufs Gehäuse aufgedruckte) Seriennumer des Zählers.

Wenn sich im Funkmodul das 0_4 nicht pro Wärmemengenzähler konfigurieren lässt, dann müsstest Du in jeden Wärmemengenzähler ein extra Funkmodul einbauen.

Das wäre ja ein ebenso teurer wie unnötiger Spaß (zumal wenn man wie ich die beiden Impulszählermodule bereits gekauft hat).
Vielleicht irre ich mich ja, aber ich glaube, dass das Ganze eine Art Geburtsfehler beim Anlegen des Device ist. Das wird ja in der Tat auf der Basis der Seriennummer des Zählers mit dem Funkmodul angelegt (Bezeichnung in der Auslesesoftware Device Manager: "Zähler-ID"). Mehr durch Zufall habe ich beobachtet, dass bei den Internals aber auch eine "Meter_ID" übergeben wird, und diese ist anscheinend pro Zähler unterschiedlich, stimmt aber auch nicht mit deren Seriennummer überein. Zwei habe ich bereits "erwischt":
2491881297
2491881289
Wenn beim Autocreate des Device statt mit der Seriennummer des sendenden Zählers (ggfalls optional) mit der Meter_ID jeweils ein Device angelegt würde, hätte man die Daten vermutlich sauber getrennt.
Wäre das der Job des EspDuino- oder des WMBUS-Moduls?

Wenn Du am Handy ein Hotspot mit dem selben WLAN Kanal aktivierst, dann müsste doch die Box im Dachgeschoss auch den Kanal wechseln?

Habe momentan nur iOS-Geräte zur Hand, und da kan man beim Personal Hotspot AFAIK keine Kanaleinstellungen machen.
Viele Grüße
Martin

[Ralf9]

Wenn beim Autocreate des Device statt mit der Seriennummer des sendenden Zählers (ggfalls optional) mit der Meter_ID jeweils ein Device angelegt würde, hätte man die Daten vermutlich sauber getrennt.
Wäre das der Job des EspDuino- oder des WMBUS-Moduls?

Das müsste im WMBUS-Modul gemacht werden, aber da kann ich nicht weiterhelfen.
Es müsste wahrscheinlich im WMBUS-Modul speziell für Wärmemengenzähler eine Anpassung gemacht werden.

[dadoc]

Moin,
wenn ich das Internal "Meter_Id" loggen wollte, wo müsste ich denn da (welche) Änderungen vornehmen? Scheint garnicht so trivial zu sein, Internals zu loggen bzw. Events erzeugen zu lassen.
Da es aber rawmsg_as_reading bereits als Attribut gibt (auch wenn es bei mir wie geschrieben nicht funktioniert, es wird immer nur "Y" angezeigt): Könnte man da mit der Meter_Id andocken?
In einem anderen Thread hattest Du geschrieben:

Damit sie ins filelog laufen, muß ein event erzeugt werden. Dies geht auch ohne readings mit DoTrigger.
Da es im filelog schon eine regexp gibt, müsste es auch ausreichen, wenn das erzeugen von events mit einem Attribut ein- und ausgeschaltet werden kann
z.B.
." msgEvent:none,RAWMSG,DMSG,RAWMSG+DMSG"

Die extra regexp in einem sduino Attribut hätte den Vorteil, daß eine Empfänger spezifische Filterung möglich wäre.

Nur blieb der Thread dann unvollendet

[Ralf9]

Wenn Du das Internal "Meter_Id" loggen willst musst Du wahrscheinlich im WMBUS Modul was einbauen damit ein event erzeugt wird, evtl gehts auch mit DOIF aber damit kenne ich mich nicht aus.

Ohne änderungen im WMBUS Modul wirds wahrscheinlich sehr aufwändig.

Du kannst mit einem notify oder DOIF auf ein event triggern das nach den Daten kommt, z.B. das event "decryption_ok"

In dem notify oder DOIF müsstest Du dann mittels einer Routine die readings "..._type" und "..._value" abfragen und dann readings oder events, die mit der VIF_PARAMETER_SET_ID anfangen, zusammenbauen

Evtl hat jemand z.B. bei Anfängerfragen oder bei DOIF eine bessere Idee