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
Beides eingecheckt.
Beim uebersetzen kriege ich die Fehlermeldung:
ZitatCompiling 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.
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
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];)
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
Wenn sich der Hersteller an diese Aussage aus dem Prospekt hält, sollte es funktionieren.
Zitat
Ü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 (http://www.fhemwiki.de/wiki/WMBUS).
Wenn du noch die Wahl hast, wäre vielleicht die EnergyCam (http://www.fhemwiki.de/wiki/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
Zitat von: kaihs am 13 Oktober 2014, 21:20:10
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 (http://www.fhemwiki.de/WMBUS).
Wenn du noch die Wahl hast, wäre vielleicht die EnergyCam (http://www.fhemwiki.de/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