no DISPATCH from WMBUS Msg´s - Software extension for WMBUS

[HomeAutoUser]

Specifications for new sensor / switch / or other device ...

• manufacturer: WMBUS

Specifications

• Microcontroller: < not matter >
• Version (Firmware): < uninteresting at first, FW expansion can be done later >

• Versionmodul (FHEM Module):

--> dmsg to test b3E44F536803364000108E78F7A260020252D808A1E0D99FDD34E3FF9F33D39824440BAF1DE3BF2AC825DDED53A9A2D92917CED2CD80F800C0001090086B41E00638814011E070416C582
or
bY304497264202231800087A2F0020A50457C508BEA56C7D29465806AC25CDF908444703F7ABD458735A2F10E65628FAC88900F7
or
b4344272050092021101A00FE8C2014900F002C25150402000047FB1739CC350EDF577A140020071040424DB4646CD0DDB47209ADF4DFD28CBA854A2BC8ADA20B920F453C7A8695D4ED3ECAAA791A84D9

--> modulregex needs to be adjusted
--> a new protocol definition must be created

--> ToDO_check: length min definable? 82
--> ToDO_check: length max definable ? 223

[elektron-bbs]

Die Definitionen für WMBus haben wir ja jetzt im FHEM. Wir würden jetzt gern die Verarbeitung auch in die SIGNALduino-Firmware einbauen.
Ich habe jetzt nur noch nicht die richtige Idee, wie wir dem SIGNALduino mitteilen, das die WMBus-Nachrichten anders in der Firmware verarbeitet werden müssen als die bisher bekannten FSK-Nachrichten.
Die WMBus-Nachrichten müssen schon in der Firmware anders verarbeitet werden, da sie verschiedene Längen haben, die nicht in den FIFO passen. Zum anderen können sie 3-out-of-6 oder Manchester codiert sein. Außerdem wird dort schon eine CRC-Prüfung durchgeführt. Im cc1101_rf_Gateway (https://github.com/HomeAutoUser/cc1101_rf_Gateway/tree/pre-release) ist es bereits integriert und funktioniert damit auch schon seit einigen Monaten.

Ich dachte erst, das die Unterscheidung anhand irgend eines Registers möglich sein müsste, aber das scheint mir mittlerweile nicht so richtig zuverlässig in Blick auf zukünftige Erweiterungen zu sein.

Wir müssten also dem SIGNALduino bei jeder Änderung des rfmode mitteilen, ob es sich um bei dem Mode um WMBus handelt oder nicht. Diese Einstellung müsste im SIGNALduino in einer Variable und auch im EEPROM gespeichert werden.

[HomeAutoUser]

@sidey79 , hier #1247 (comment) kam eine Frage auf, wo wir vielleicht eine Idee benötigen oder du es vielleicht anders lösen würdest.

[sidey79]

Ich weiss leider überhaupt nicht was da zu entscheiden wäre.

Ich habe bisher nur verstanden, dass wir einen anderen Betriebsmodi brauchen und der wiederum müsste über ein Kommando gesetzt werden.

[HomeAutoUser]

@sidey79

Ich habe bisher nur verstanden, dass wir einen anderen Betriebsmodi brauchen und der wiederum müsste über ein Kommando gesetzt werden.

Damit liegst du schonmal richtig.
letztendlich hat @elektron-bbs es hier #1247 (comment) schonmal versucht zu erläutern.

Ausschlaggebend sollte sein
"... wie wir dem SIGNALduino mitteilen, das die WMBus-Nachrichten anders in der Firmware verarbeitet werden müssen als die bisher bekannten FSK-Nachrichten."
"... Wir müssten also dem SIGNALduino bei jeder Änderung des rfmode mitteilen, ob es sich um bei dem Mode um WMBus handelt oder nicht. Diese Einstellung müsste im SIGNALduino in einer Variable und auch im EEPROM gespeichert werden."
... oder kurz gesagt, die Software muss der Firmware beim Umschalten des Modes mitteilen das diese nun die andere Verarbeitung nutzen muss ;-)

[HomeAutoUser]

@sidey79 Erinnerung daran :-) #1247 (comment)
Eine Implementierung wäre ein schönes Feature für sehr viele.

[sidey79]

Ich habe hieran nicht mehr gedacht. Die Erinnerung war schon mal gut :)

Vielleicht fangen wir klein an:

Gebraucht wird eine Einstellmöglichkeiten die einen Empfangsmodus verändert.

Aktuell würde ich zwei Zustande kennen:

Mode 0 = MU,MS und MC ist möglch
Mode 1 = MN ist möglich
Mode 3 = WM Bus Besonderheiten
Mode 4 = frei für was zukünftiges

Ich würde dann erst mal implementieren, dass man diese vier Zustände setzen und abfragen kann.

[elektron-bbs]

Naja, eigentlich bräuchte der SIGNALduino nur noch eine Info, ob er FSK als das bisher bekannte behandeln soll, oder eben als Besonderheit, das er die FSK-Nachrichten als WM-Bus-Nachrichten behandelt.
Das eine FSK-Modulation vorliegt wird ja bereits aus einem Register des CC110x ausgelesen.
Wir müssten also aus FHEM nur bei den beiden WM-Bus Modes (rfMode WMBus_S / WMBus_T) z.B. ein WM=1 und bei allen anderen WM=0 übermitteln. Im SIGNALduino dachte ich dann an die Stelle, wo diese Config gespeichert wird:

  int8_t dat = ms | mu | mc | red | afc;
  EEPROM.write(addr_features, dat);

Da sind ja noch 3 Bit frei.
Als Zugabe könnte man dann vielleicht auch gleich noch die Ausgabe von get config automatisch anpassen:

config   MS=1;MU=1;MC=1;MN=1;AFC=0;Mred=1

Dieser SIGNALduino ist aktuell in rfMode Bresser_5in1. MS, MU und MC sind also aktuell gar nicht möglich.

Ich würde dann eigentlich gern die WM-Bus-Erweiterung gleich in die Version 4.0.0 einbauen, die wir vor gut einem Jahr produziert haben, einbauen. Diese ist aber noch nicht offiziell verfügbar.

[sidey79]

So grob war auch meine Idee nur dass die Werte für MU,MS,MC bei Nutzung FSK ja sinnfrei sind.

Sozusagen wären ja deutlich mehr als 3 bit frei.
AFC wiederum kann man bei MU,MS und MC auch nicht setzen, also wäre so ein Schalter mit mehreren Werten ja nicht so übel aus dessen Einstellung erhalten die Register dann eine jeweils unterschiedliche Bedeutungen.

[elektron-bbs]

Ich hatte noch die Idee, das man bei den beiden WM-Bus-Modes einfach noch einen zusätzlichen Wert bei den Register-Settings anhängt, wie z.B. ,'5001'. Dann bräuchte man im SIGNALduino-Modul gar nichts ändern.

EDIT:
Ich denke, das vergessen wir schnell wieder. Es müsste ja dann auch bei jeder Änderung (set cc1101_reg) wieder mitgesendet werden.

[elektron-bbs]

Ich habe es jetzt so gestaltet, das ich in der Firmware dieses Byte erweitert habe:

  #if defined (CMP_CC1101) && (defined (ESP8266) || defined (ESP32))
    wmbus = wmbus << 5;
    wmbus_t = wmbus_t << 6;
    int8_t dat = ms | mu | mc | red | afc | wmbus | wmbus_t;
  #else
    int8_t dat = ms | mu | mc | red | afc;
  #endif

Die Ausgabe von get config in FHEM sieht jetzt je nach Prozessor und Modulationsart so aus:

Nano OOK/ASK:
config   MS=1;MU=1;MC=1;Mred=1
Nano FSK:
config   MN=1;AFC=0
ESP8266 FSK WMBus aus
config   MN=1;WMBus=0;WMBus_T=1;AFC=0
ESP8266 FSK WMBus ein
config   MN=1;WMBus=1;WMBus_T=1;AFC=1

Die Verarbeitung der WMBus-Nachrichten (z.Z. nur Empfang) erfolgt nur beim ESP8266 und ESP32. Beim Nano ist der RAM zu knapp bemessen.

@sidey79
Kommen wir uns ins Gehege, wenn ich jetzt einen Pull request der Firmware mache (du bist auch gerade an einer Änderung dran)?

[sidey79]

Vermutlich gibt es dann irgend einen Konflikt, aber das ist dann lösbar.

Viel Interessanter finde ich, macht's denn Sinn MS, MU, MC zu aktivieren wenn man diesen neuen WM Bus Modus aktiviert?
Ich vermute mal, dass die Kombination nicht möglich ist. Liege ich falsch?

[elektron-bbs]

Das funktioniert natürlich nicht. Dafür bräuchte man dann schon 2 CC110x, da das eine OOK- und das andere FSK-Modulation ist.

Ich kann auch noch warten, bis du fertig bist.

[sidey79]

Nein warten brauchen wir nicht, aber mein Kommentar vom 3. September ist immer noch aktuell.
Ich hab halt nur nichts umgesetzt, weil ich nicht sicher war ob ich es korrekt verstanden habe.

Jetzt denke ich aber, dass mein Verständnis durchaus gut war.

Gäbe es denn Nachteile wenn wir einen vorgelagerten Modusschalter einbauen der die weiteren Schalter dann jeweils definiert?

[elektron-bbs]

Mhmm, wozu wir einen zusätzlichen "Modusschalter" bräuchten, erschließt sich mir jetzt nicht.
Der Schalter ist ja schon da: Die Auswahl des rfmode
Dadurch schaltet der SIGNALduino in den jeweiligen Modus:
OOK/ASK
FSK kein WMBus
FSK WMBus

[elektron-bbs]

@sidey79
Ich habe jetzt jeweils in RFFHEM und SIGNALduino einen neuen Branch master_WMBus mit meinen Änderungen angelegt.
Soll ich gleich pull request starten oder siehst du dir das erst mal an?

[sidey79]

Ich schau es mir über den PR an

[HomeAutoUser]

Ich bestätige schon mal unabhängig von den Tests, das die Version aus dem PR funktioniert auch mit einem eingegebenen WMBus-Schlüssel. @elektron-bbs , ich erhalte die selben Werte wie mit dem Gateway.

[elektron-bbs]

@sidey79
Ich will ja nicht drängeln, aber wie sieht es mit den pull requests aus?