[patch] Erweiterung 00_CUL.pm/culfw um RSSI für WMBUS

[kaihs]

Hallo Rudolf,

anbei zwei Patches mit der Bitte um Aufnahme.

1, Erweiterung der culfw um Ausgabe von RSSI/LQI im WMBus Modus
Die beiden Werte werden an das WMBus Paket hinten angehängt, erst LQI und dann RSSI
RSSI wird dann mit dem zweiten Patch bereits von 00_CUL.pm verarbeitet, LQI erst vom 36_WMBUS.pm
Die Werte werden, analog zu AskSin, nur bei X21 ausgegeben.

2. Erweiterung von 00_CUL.pm um die Verarbeitung des RSSI, analog zu AskSin

Das 36_WMBUS.pm Modul ist bereits für die Verarbeitung dieser Werte vorbereitet.

Gruß,

Kai

[rudolfkoenig]

Beides eingecheckt.
Beim uebersetzen kriege ich die Fehlermeldung:

Compiling C: ../../clib/mbus/3outof6.c
../../clib/mbus/3outof6.c: In function 'encode3outof6':
../../clib/mbus/3outof6.c:123: warning: 'data[0]' may be used uninitialized in this function

vielleicht kannst du danach auch schauen.

[kaihs]

Ich bekomme die Warnung nicht (avr-gcc 4.8.2) und bei der Warnung irrt sich dein Compiler wohl auch.

Der Code sieht so aus

Code Auswählen Erweitern


void encode3outof6 (uint8 *uncodedData, uint8 *encodedData, uint8 lastByte)
{
 
  uint8  data[4];
   
   // - Perform encoding -
   
  // If last byte insert postamble sequence
  if (lastByte)
  {
    data[1] = 0x14;
  }
  else
  {
    data[0] = encodeTab[*(uncodedData + 1) & 0x0F];
    data[1] = encodeTab[(*(uncodedData + 1) >> 4) & 0x0F]; 
  }
   
  data[2] = encodeTab[(*uncodedData) & 0x0F];
  data[3] = encodeTab[((*uncodedData) >> 4) & 0x0F];

  // - Shift the encoded 6-bit values into a byte buffer -
  *(encodedData + 0) = (data[3] << 2) | (data[2] >> 4);
  *(encodedData + 1) = (data[2] << 4) | (data[1] >> 2);
 
  if (!lastByte)
  {
    *(encodedData + 2) = (data[1] << 6) | data[0];
  }
}


Auf data[0] wird nur lesend zugegriffen wenn lastByte = 0, in diesem Fall wird data[0] aber initialisiert (    data[0] = encodeTab[*(uncodedData + 1) & 0x0F]

[Damian]

Hallo Kai,

ich habe gesehen, dass du das Modul 36_WMBUS produziert hast.

Weißt du vielleicht, ob die Kommunikation mit solch einem Funk-Modul funktionieren würde?

http://docuthek.kromschroeder.com/documents/download.php?lang=de&doc=34129

Ich betreibe CUL-868 im slowRF-Mode für FS20-Geräte.

Gruß

Damian

[kaihs]

Wenn sich der Hersteller an diese Aussage aus dem Prospekt hält, sollte es funktionieren.

Übertragungsprotokolle
M-Bus nach OMS
(Open Metering System), volume 3
Implementiert ist das M-Bus-Übertra-
gungsprotokoll nach OMS. In Verbindung
mit einem funkunterstützenden Kommuni-
kationsmodul werden die Daten verschlüs-
selt übertragen.

Falls die Verschlüsselung zum Einsatz kommt, benötigst du auch den Schlüssel.

Die bisherige Erfahrung ist leider, dass die Hersteller trotz Standard gerne ein eigenes Süppchen kochen, siehe auch die Anmerkungen in http://www.fhemwiki.de/wiki/WMBUS.

Wenn du noch die Wahl hast, wäre vielleicht die EnergyCam eine Option, von der weiß ich, dass sie funktioniert.

Der CUL kann nicht zeitgleich slowRF und WMBUS empfangen, da musst du dich für eins entscheiden oder ggf. einen zweiten Empfänger anschaffen.

Kai

[Damian]

Wenn sich der Hersteller an diese Aussage aus dem Prospekt hält, sollte es funktionieren.

Falls die Verschlüsselung zum Einsatz kommt, benötigst du auch den Schlüssel.

Die bisherige Erfahrung ist leider, dass die Hersteller trotz Standard gerne ein eigenes Süppchen kochen, siehe auch die Anmerkungen in http://www.fhemwiki.de/WMBUS.

Wenn du noch die Wahl hast, wäre vielleicht die EnergyCam eine Option, von der weiß ich, dass sie funktioniert.

Der CUL kann nicht zeitgleich slowRF und WMBUS empfangen, da musst du dich für eins entscheiden oder ggf. einen zweiten Empfänger anschaffen.

Kai

Danke erst mal für deine Einschätzung.

Gruß

Damian