Wasserzähler Lorenz wmbus einbinden

[scp]

Es geht um die Anbindung eines Wasserzählers von Lorenz.
Habe meinen nanoCUL auf rfmode und T Modus eingestellt . Momentan ist ein Sontex Wärmemengenzähler und 4 Joyh100 wärmemengenzähler erfasst 
Aus irgendeinem Grund wird der Lorenz Wasserzähler nicht automatisch erfasst.

Jemand eine Idee ?
Im Anhang befindet sich auch die von mir angeforderte Bedienungsanleitung

Der geforderte 10 cm Abstand wurde eingehalten . Der Display zeigt ein "|".
Kann es sein, das er erst ab dem Stichtag sendet ?

OMS Modus T1
AES aktiv : ja
AES Mode 5
kurzes Telegramm

Stichtag: 31 Dezember
-Solleinschaltzeit: 0 Uhr
-Sollausschaltzeit 24 Uhr
-Seneintervall alle 5 Minuten
Funk aktiv nein ( habe ich denke ich nun selber angeschaltet)
Funk aktivierbar

[chopsor]

Hoi,

Probierst du gerade auf 433Mhz oder 868 Mhz ?


Mein Sensus iperl hatte ich anfangs auch über 868Mhz Probiert letztendlich funkt er aber auf 433Mhz.

MfG Daniel

[scp]

Das wäre natürlich sehr unerwartet . OMS V3 T1 müsste mit 868 MHz senden.
Also ich habe schon mal den S und C Mode eingestellt dafür , aber da kam auch nichts.

Sehr interessant. Ob der CUL wohl eine maximale Teilnehmerzahl von 5 hat ?!

Ok habe mit dem Verkäufer geredet , der hat meine Vermutung bestätigt, dass ich den Funk korrekt aktiviert habe und er auf 868 MHz alle 5 minuten funken sollte. Man könnte natürlich noch mal mit dem Hersteller reden...

Habe im Anhang zwei Bilder.
Eines zeigt die aktuelle Einstellung des Wasserzählers. Wobei der angezeigte Warnhinweis erst später dazu gekommen ist, nachdem ich öfters auf den Knopf gedrückt habe um zu prüfen ob der Funk auch an ist. Allerdings hätte davor schon etwas emfpangen werden müssen. Jetzt taucht er übrigens nicht mehr auf

Das andere Bild zeigt die momentan über wMBUS eingebunden Geräte ( nano CUL)

[kaihs]

Sehr interessant. Ob der CUL wohl eine maximale Teilnehmerzahl von 5 hat ?!

Nein, hat er nicht. Der CUL schickt die empfangenen Daten einfach auf die serielle Schnittstelle, der Inhalt ist egal. Er speichert auch nichts.
Allerdings werden Telegramme mit ungültiger Prüfsumme verworfen.

Es kann aber auch sein, dass das fhem WMBUS Modul mit den Daten nichts anfangen kann. Dann sollten aber entsprechende Meldungen im Log stehen.

[scp]

von diesem Zähler wird einfach nichts empfangen. Jetzt habe ich 2 unterschiedliche Heizkostenverteiler integriert, auch mit AES Key ( 1 x Sontex und 4 x Joymeter).
Die Readings werden immer in bestimmten Abständen dargestellt.
Aber dieser Wasserzähler erscheint gar nicht in den Logfiles.
Habe natürlich das ganze auch mal neu gestartet etc.. Ich werde den Zähler mal in einen anderen Raum tun. Vielleicht braucht er mehr Abstand zum CUL 
Auch ein größerer Abstand hat erstmal nichts gebracht !

(Man kann übrigens in den Wasserzähler reinpusten um den Zählwert zu verändern. Das klappt in beide Richtungen erfolgreich. So wird der Wert auf seiner Anzeige inkre - bzw. dekrementiert.)

Hat es evtl. mit der Buffergräße etwas zu tun ?!
https://forum.fhem.de/index.php/topic,26021.msg190400.html#msg190400

[scp]

Bis jetzt habe ich noch keine Lösung gefunden !
Komischerweise ausgerechnet bei dem Gerät was alle Informationen beiliegend hatte 

[scp]

Interessant,
man hat mir heute die Information gegeben, dass der Wasserzähler im Modus C1 läuft und nicht T1 so wie auf der Rechnung beschrieben xD

Habe das mal eingestellt mit meinem nanoCUL. Warte aber vergebens auf eine autocreate Nachricht oder ähnliches.

Werde jetzt mal zu diesem Modus C1 recherchieren...


Hmm ich könnte versuchen den mal manuell anzulegen:
allerdings sind die parameter nicht genau beschrieben, aber etwas kann man schon reinschreiben, allerdings wird Seriennummer nirgendswo beschrieben xD:
define lorenzwasser WMBUS [DWZ 19014338 R80 0x07[CUL]] | < b[CUL] HexCode


ah mit dieser zeile kann man etwas anlegen xD

Code Auswählen Erweitern


define lorenzwasser WMBUS [DWZ 19014338 R80 7

Code Auswählen Erweitern


define <name> WMBUS [<manufacturer id> <identification number> <version> <type> [<MessageEncoding>]]|<b[<MessageEncoding>]HexCode>

Normally a WMBus device isn't defined manually but automatically through the autocreate mechanism upon the first reception of a message.
For a manual definition there are two ways.

    By specifying a raw WMBus message as received by an IODev. Such a message starts with a lower case 'b' and contains at least 24 hexadecimal digits. The WMBUS module extracts all relevant information from such a message.
    Explictly specify the information that uniquely identifies a WMBus device.
    The manufacturer code, which is is a three letter shortcut of the manufacturer name. See dlms.com for a list of registered ids.
    The identification number is the serial no of the meter.
    version is the version code of the meter
    type is the type of the meter, e.g. water or electricity encoded as a number.
    MessageEncoding is either CUL or AMB, depending on which kind of IODev is used. The default encoding is CUL.

So sieht meine neu angelegtes WMBUS Device aus... allerdings empfängt es keine Daten

Code Auswählen Erweitern


Internals:
   CFGFN     
   DEF        [DWZ 19014338 R80 7
   DeviceMedium Water
   DeviceType 7
   FUUID      5db727be-f33f-05c5-6199-6471f8e0b7d657e1
   IODev      CUL1
   IdentNumber 19014338
   Manufacturer [DWZ
   MessageEncoding CUL
   NAME       lorenzwasser
   NR         211
   STATE      ???
   TYPE       WMBUS
   Version    R80
   addr       [DWZ_19014338_R80_7
Attributes:
   IODev      CUL1


Hier die list von meinem nanoCUL

Code Auswählen Erweitern

Internals:
   CMDS       ABbCEeFfGhiKlMmRTtUVWXxYZ
   CUL1_MSGCNT 399
   CUL1_TIME  2019-10-28 18:43:34
   Clients    :WMBUS:HMS:CUL_IR:STACKABLE_CC:TSSTACKED:STACKABLE:
   DEF        /dev/ttyUSB0@38400 1234
   DeviceName /dev/ttyUSB0@38400
   FD         7
   FHTID      1234
   FUUID      5d6e3192-f33f-05c5-4184-b9d4a59afd3ff2f1
   MessageEncoding CUL
   NAME       CUL1
   NR         15
   PARTIAL   
   RAWMSG     b3E44F9A9364431910108DD737A59003025E6148AF00886F6B6F292920B25200307203A761082B430EB3E0E9448B88D4D19E897E59AF4E8BCF62EFE1C110CD6CF128865D67F325CD95C8023
   RSSI       -56.5
   STATE      Initialized
   TYPE       CUL
   VERSION    V 1.67 nanoCUL868
   initString X21
brt
   MatchList:
     8:HMS      ^810e04....(1|5|9).a001
     D:CUL_IR   ^I............
     H:STACKABLE_CC ^\*
     J:WMBUS    ^b.*
     M:TSSTACKED ^\*
     N:STACKABLE ^\*
   READINGS:
     2019-10-23 17:29:55   cmds             A B b C E e F f G h i K l M m R T t U V W X x Y Z
     2019-10-28 18:43:34   state           Initialized
Attributes:
   rfmode     WMBus_C

[scp]

Schade auch im C Modus wird nichts empfangen....
Ich habe gerade den S Modus angeschaltet beim CUL aber auch das hilft nicht (((((((((((((((((((((((((((I

[kaihs]

Es kann sein, dass die auf deinem CUL installiert culfw WMBUS-C noch nicht unterstützt.

Das kann man leider nicht aus der Version ablesen. Um das zu testen müsstest du bei deinem CUL das Attribut verbose auf 5 setzen und dann das Kommando

Code Auswählen Erweitern


set CUL1 raw brc

eingeben.

Anschließend ins Log schauen.
Wenn da sowas steht

Code Auswählen Erweitern


2019.10.29 19:48:37.084 3: set CUL_0 raw brc
2019.10.29 19:48:37.085 5: SW: brc
2019.10.29 19:48:37.137 5: CUL/RAW: /OFF


wird C-Mode nicht unterstützt.
Wenn der CUL mit CMODE antwortet wird es unterstützt.

Wenn es bei dir nicht unterstützt wird musst du die culfw selber compilieren und den CUL neu flashen.

Wie das geht ist am Beispiel eines nanoCULs hier beschrieben.
Dabei auch das hier beschriebene zusätzlich beachten.

Wenn du das nicht hinbekommst kann ich dir auch eine fertige culfw zur Verfügung stellen wenn du mir sagst was genau für einen CUL du hast.

[scp]

Guten Tag kaihs,

vielen Dank für deine Antwort !
Ich habe das Attribut verbose auf 5 gesetzt und anschließend das Kommando set CUL1 raw brc eingeben.
Die Antwort im Log lautet :

Code Auswählen Erweitern

2019.11.05 11:20:40 3: set CUL1 raw brc
2019.11.05 11:20:40 5: SW: brc
2019.11.05 11:20:40 5: CUL/RAW: /OFF

2019.11.05 11:20:40 4: CUL_Parse: CUL1 OFF
2019.11.05 11:20:40 5: CUL1: dispatch OFF
2019.11.05 11:20:40 3: CUL1: Unknown code OFF, help me!


ah verstehe dieser von dir vorgeschlagene raw Befehl ändert wohl irgendwie den CUL Modus. habe das auch mal mit brt versucht^^  dort wird dann wirklich angezeigt, dass er in den TMODE gewechselt hat. Für den C-Mode geht das nicht !

Code Auswählen Erweitern

019.11.05 15:10:36 3: set CUL1 raw brt
2019.11.05 15:10:36 5: SW: brt
2019.11.05 15:10:36 5: CUL/RAW: /TMODE

2019.11.05 15:10:36 4: CUL_Parse: CUL1 TMODE
2019.11.05 15:10:36 5: CUL_Parse: switched to TMODE


2019.11.05 15:10:57 3: set CUL1 raw brc
2019.11.05 15:10:57 5: SW: brc
2019.11.05 15:10:57 5: CUL/RAW: /OFF

2019.11.05 15:10:57 4: CUL_Parse: CUL1 OFF
2019.11.05 15:10:57 5: CUL1: dispatch OFF
2019.11.05 15:10:57 3: CUL1: Unknown code OFF, help me!


das deutet wohl wirklich darauf hin, dass der C-Mode nicht aktiviert ist

Was mir hierbei spontan einfällt ist ,dass ich ja bereits den CUL selber compilieren musste , damit überhaupt etwas empfangen wird ( hat auch geklappt ! ) ...
ich habe zu diesem Zeitpunkt bereits Code geändert , board.h oder so ähnlich, heißt die zu ändernde Datei !
Ich werde nun mal schauen , was man denn noch ändern muss, um den C Mode zu aktivieren

Vielen Dank 


Habe mir auch mal die anderen raw Befehle angeschaut..
Meine CUL SW ist:
CUL1 raw => V 1.67 nanoCUL868
CUL1 ccconf => freq:800.000MHz bWidth:203KHz rAmpl:33dB sens:8dB

( hier sollte doch eigentlich 868 stehen... naja muss man dann mal schauen was sonst noch so eingestellt ist xD
ob set CUL freq 868.350 hier wohl Sinn macht ?)
Hea nach wiederholter anfrage steht dann dort doch :
CUL1 ccconf => freq:868.950MHz bWidth:325KHz rAmpl:33dB sens:8dB

Also hier ist mal eine board.h :

Code Auswählen Erweitern


#ifndef _BOARD_H
#define _BOARD_H

#include <stdint.h>

/* if you have an Arduino with only 8MHz disable the next line */
#define HAS_16MHZ_CLOCK

/* if you are using a CC1101 module for 868MHz disable the next line
* ok wurde auskommentiert*/
//#define HAS_CC1100_433


#define SPI_PORT PORTB
#define SPI_DDR DDRB
#define SPI_SS 2
#define SPI_MISO 4
#define SPI_MOSI 3
/* die aufgelötete gelbe LED ist an PB5/SCLK angeschlossen! */
#define SPI_SCLK 5

#define CC1100_CS_DDR SPI_DDR
#define CC1100_CS_PORT          SPI_PORT
#define CC1100_CS_PIN SPI_SS


/* CC1101 GDO0 Tx / Temperature Sensor */
#if 0
#define CC1100_OUT_DDR DDRC
#define CC1100_OUT_PORT         PORTC
#define CC1100_OUT_PIN          PC0
#define CC1100_OUT_IN           PINC
#define CCTEMP_MUX              CC1100_OUT_PIN
#else
#define CC1100_OUT_DDR DDRD
#define CC1100_OUT_PORT         PORTD
#define CC1100_OUT_PIN          PD3
#define CC1100_OUT_IN           PIND
#define CCTEMP_MUX              CC1100_OUT_PIN
#endif

/* CC1101 GDO2 Rx Interrupt */
#define CC1100_IN_DDR DDRD
#define CC1100_IN_PORT          PIND
#define CC1100_IN_PIN           PD2
#define CC1100_IN_IN            PIND

#define CC1100_INT INT0
#define CC1100_INTVECT          INT0_vect
#define CC1100_ISC ISC00
#define CC1100_EICR             EICRA

/* externe LED */
#define LED_DDR                 DDRB
#define LED_PORT                PORTB
#define LED_PIN                 1

//#define LED_ON_DDR              DDRB
//#define LED_ON_PORT             PORTB
//#define LED_ON_PIN              1


#define BOARD_ID_STR            "nanoCUL868"
#define BOARD_ID_STR433         "nanoCUL433"

/* define this device as a 433 MHz one */
/* this isn't done like a CUL by reading a port pin but instead a fixed value of 0 for mark433_pin is used */
#define MULTI_FREQ_DEVICE
#define MARK433_PIN mark433_pin
#define MARK433_BIT             0
extern const uint8_t mark433_pin;

#define HAS_UART
#define UART_BAUD_RATE          38400

/* ATMega328P has only one UART, no need to define the UART to use */
//#define USART_RX_vect           USART0_RX_vect
//#define USART_UDRE_vect         USART0_UDRE_vect

#define TTY_BUFSIZE             200 // um2 byte ? erhöht


#define RCV_BUCKETS            2      //                 RAM: 25b * bucket
#define FULL_CC1100_PA                // PROGMEM:  108b
#define HAS_RAWSEND                   //
#define HAS_FASTRF                    // PROGMEM:  468b  RAM:  1b
#define HAS_ASKSIN
/* Intertechno Senden einschalten */
#define HAS_INTERTECHNO
#define HAS_TCM97001
/* Intertechno Empfang einschalten */
#define HAS_IT
#define HAS_REVOLT
#define HAS_CC1101_RX_PLL_LOCK_CHECK_TASK_WAIT
#define HAS_CC1101_PLL_LOCK_CHECK_MSG
#define HAS_CC1101_PLL_LOCK_CHECK_MSG_SW
/* HAS_MBUS requires about 1kB RAM, if you want to use it you
   should consider disabling other unneeded features
   to avoid stack overflows
*/
#define HAS_MBUS // wichtig

#define HAS_ASKSIN_FUP
#define HAS_MORITZ
#define HAS_RWE
#define HAS_ESA
#define HAS_TX3
#define HAS_UNIROLL
#define HAS_HOERMANN
#define HAS_HOERMANN_SEND
#define HAS_MEMFN
#define HAS_SOMFY_RTS
//#define HAS_FHT_80b                     // PROGMEM: 1374b, RAM: 90b
//#define HAS_FHT_8v                    // PROGMEM:  586b  RAM: 23b
//#define HAS_FHT_TF
#define FHTBUF_SIZE          174       //                 RAM: 174b
//#define HAS_KOPP_FC                   // auskommentiert
//#define HAS_ZWAVE                     // PROGMEM:  882


#endif




Hiern noch mal die c- datei

Code Auswählen Erweitern


/* Copyright Rudolf Koenig, 2008.
   Released under the GPL Licence, Version 2
   Inpired by the MyUSB USBtoSerial demo, Copyright (C) Dean Camera, 2008.
*/

#include <avr/boot.h>
#include <avr/power.h>
#include <avr/eeprom.h>
#include <avr/interrupt.h>
#include <avr/io.h>
#include <avr/pgmspace.h>
#include <avr/wdt.h>

#include <string.h>

#include "board.h"

#include "spi.h"
#include "cc1100.h"
#include "clock.h"
#include "delay.h"
#include "display.h"
#include "serial.h"
#include "fncollection.h"
#include "led.h"
#include "ringbuffer.h"
#include "rf_receive.h"
#include "rf_send.h"
#include "rf_moritz.h"
#include "ttydata.h"
#include "fastrf.h"
#include "rf_router.h"
#include "i2cmaster.h"
#include "intertechno.h"
#include "adcw.h"
#include "cctemp.h"
#include "fht.h"
#include "memory.h"

#ifdef HAS_ASKSIN
#include "rf_asksin.h"
#endif
#ifdef HAS_MORITZ
#include "rf_moritz.h"
#endif
#ifdef HAS_RWE
#include "rf_rwe.h"
#endif
#ifdef HAS_INTERTECHNO
#include "intertechno.h"
#endif
#ifdef HAS_SOMFY_RTS
#include "somfy_rts.h"
#endif
#ifdef HAS_MBUS
#include "rf_mbus.h"
#endif
#ifdef HAS_KOPP_FC
#include "kopp-fc.h"
#endif
#ifdef HAS_ZWAVE
#include "rf_zwave.h"
#endif



#ifdef HAS_CC1100_433
const uint8_t mark433_pin = 0x00;
#else
const uint8_t mark433_pin = 0xff;
#endif

const PROGMEM t_fntab fntab[] = {

#ifdef HAS_ASKSIN
  { 'A', asksin_func },
#endif
  { 'B', prepare_boot },
#ifdef HAS_MBUS
  { 'b', rf_mbus_func },
#endif
  { 'C', ccreg },
#ifdef HAS_RWE
  { 'E', rwe_func },
#endif
  { 'e', eeprom_factory_reset },
  { 'F', fs20send },
#ifdef HAS_FASTRF
  { 'f', fastrf_func },
#endif
#ifdef HAS_RAWSEND
  { 'G', rawsend },
#endif
#ifdef HAS_HOERMANN_SEND
  { 'h', hm_send },
#endif
#ifdef HAS_INTERTECHNO
  { 'i', it_func },
#endif
#ifdef HAS_RAWSEND
  { 'K', ks_send },
#endif
#ifdef HAS_KOPP_FC
  { 'k', kopp_fc_func },
#endif
#ifdef HAS_BELFOX
  { 'L', send_belfox },
#endif
  { 'l', ledfunc },
#ifdef HAS_RAWSEND
  { 'M', em_send },
#endif
#ifdef HAS_MEMFN
  { 'm', getfreemem },
#endif
#ifdef HAS_RFNATIVE
  { 'N', native_func },
#endif
  { 'R', read_eeprom },
  { 'T', fhtsend },
  { 't', gettime },
#ifdef HAS_UNIROLL
  { 'U', ur_send },
#endif
#ifdef HAS_RF_ROUTER
  { 'u', rf_router_func },
#endif
  { 'V', version },
  { 'W', write_eeprom },
  { 'X', set_txreport },
  { 'x', ccsetpa },
#ifdef HAS_SOMFY_RTS
  { 'Y', somfy_rts_func },
#endif
#ifdef HAS_MORITZ
  { 'Z', moritz_func },
#endif
#ifdef HAS_ZWAVE
  { 'z', zwave_func },
#endif
  { 0, 0 },
  { 0, 0 },
};

int
main(void)
{
  wdt_disable();
#ifdef HAS_16MHZ_CLOCK
  /* set clock to 16MHz/2 = 8Mhz */
  clock_prescale_set(clock_div_2);
#endif

//  LED_ON_DDR  |= _BV( LED_ON_PIN );
//  LED_ON_PORT |= _BV( LED_ON_PIN );

  led_init();
  LED_ON();

  spi_init();
// init_adcw();

  //eeprom_factory_reset("xx");
  eeprom_init();

  // Setup the timers. Are needed for watchdog-reset
  OCR0A  = 249;                            // Timer0: 0.008s = 8MHz/256/250 == 125Hz
  TCCR0B = _BV(CS02);
  TCCR0A = _BV(WGM01);
  TIMSK0 = _BV(OCIE0A);

  TCCR1A = 0;
  TCCR1B = _BV(CS11) | _BV(WGM12);         // Timer1: 1us = 8MHz/8


  MCUSR &= ~(1 << WDRF);                   // Enable the watchdog
  wdt_enable(WDTO_2S);

#ifdef HAS_16MHZ_CLOCK
  uart_init( UART_BAUD_SELECT(UART_BAUD_RATE,F_CPU) );
#else
  uart_init( UART_BAUD_SELECT_DOUBLE_SPEED(UART_BAUD_RATE,F_CPU) );
#endif
  fht_init();
  tx_init();
  input_handle_func = analyze_ttydata;

  display_channel = DISPLAY_USB;

#ifdef HAS_RF_ROUTER
  rf_router_init();
  display_channel |= DISPLAY_RFROUTER;
#endif

  LED_OFF();

  sei();

  for(;;) {
    uart_task();
    RfAnalyze_Task();
    Minute_Task();
#ifdef HAS_FASTRF
    FastRF_Task();
#endif
#ifdef HAS_RF_ROUTER
    rf_router_task();
#endif
#ifdef HAS_ASKSIN
    rf_asksin_task();
#endif
#ifdef HAS_MORITZ
    rf_moritz_task();
#endif
#ifdef HAS_RWE
    rf_rwe_task();
#endif
#ifdef HAS_KOPP_FC
    kopp_fc_task();
#endif
#ifdef HAS_MBUS
    rf_mbus_task();
#endif
#ifdef HAS_ZWAVE
    rf_zwave_task();
#endif
  }

}


Naja konnte bis jetzt noch nicht rausfinden wie man den CModus anschaltet

[kaihs]

Du musst nur die neueste Version der culfw aus dem svn Repository verwenden, dann ist Typ C automatisch dabei wenn WMBUS in der board.h aktiviert ist.
Also z. B. diese ZIP Datei herunterladen.

Die vorcompilierte culfw von culfw.de basiert auf einer älteren Version.

Die Frequenz und die anderen Parameter brauchst du nicht selbst einstellen. Das passiert automatisch, wenn der entsprechende WMBUS Modus eingeschaltet wird.

[scp]

Vielen Dank für deine Antwort.
Mich wundert auf jeden Fall, dass ich ja die culfw ( so nehme ich zumindest an ) bereits vor , etwa 3 Monaten selbst kompiliert habe und den CUL damit bespielt habe. Davor habe ich die board.h entsprechend geändert, also has mbus aktiviert.
Ich denke ich habe bereits eine relativ neue Version. Da müsste der C-Modus doch schon aktiviert worden sein.
Naja auf jeden Fall werde ich jetzt die neuste Version suchen.

Mir fällt aber auf, dass die Dateien von deinem Link schon 3 Jahre alt sind:
Ob das wohl die richtigen sind ?...

Code Auswählen Erweitern


README 2014-12-08 kaihs [r477] nanoCUL: added link to wiki to the README file
board.h 2016-11-23 rudolfkoenig [r557] Version 1.67 (Hoermann send + RFR Filter)
makefile 2016-10-19 kaihs [r556] Add zwave support to nanoCUL
nanoCUL.c 2016-11-23 rudolfkoenig [r557] Version 1.67 (Hoermann send + RFR Filter)
nanoCUL.hex 2016-11-23 rudolfkoenig [r557] Version 1.67 (Hoermann send + RFR Filter)


Die Dateien online auf http://culfw.de/culfw.html
Current Version: (as of 2017-09-07) is 1.67. See the CHANGED file for current changes.
haben sogar ein neueres Datum.

Also eine vorkompilierte Datei wäre doch die Hex Datei oder ?
Also diese habe ich ja bereits in der Vergangenheit aktualisieren müssen
Random seite im Internet:
"The compiler converts each .c file into assembly code.
The assembler converts those into object files. These files use relative addressing.
The linker puts all the object files together into the series of hex digits in the .hex file, and gives them the addresses required by the device. It also brings in any external object files for which you don't have the source code (or have already compiled it in a previous iteration)."

Es steht ja auch noch mal auf http://culfw.de/commandref.html#flashing
Also so habe ich das auch in der Vergangenheit gemacht:

Compile (optional)
Change into your device directory (e.g. culf/Devices/CUL)
Type "make", which will output text like:

    Compiling C: CUL.c
    [...]

[kaihs]

Der Link liefert immer die neueste Version aus dem culfw svn-repository.

Entscheidend für die Unterstützung des Mode C sind die Dateien clib/rf_mbus.c und clib/rf_mbus.h.

Die Änderungen habe ich am 24.6.2018 vorgenommen, die Dateien müssen also einen Zeitstempel von diesem Datum oder neuer haben.
Wenn in der rf_mbus.c der Text WMBUS_CMODE vorkommt ist es die richtige Version.

[scp]

Vielen Dank für die Antwort


Ich denke an dieser Stelle muss ich noch einiges nachholen / wieder auffrischen, was das wmbus modul angeht.
Ich kann mich auf jeden Fall daran erinnern, dass ich den Ordner nanoCUL kompiliert habe in Linux ( Raspbian) und dann auch auf den nanoCUL gespielt habe.

Wichtig ist zu erwähnen, dass bei deinem Link, das Package (.zip) , bei mir (vor einigen Tagen) ,beim Anklicken, nicht direkt als Download angeboten wurde. Das führte natürlich zu noch mehr Unklarheit. Heute habe ich einfach auf den Link geklickt und das Package wurde einfach zum Downloaden angeboten. Jetzt weiß ich wenigsten welches Package zu meinst Davor musste ich auf der Seite die vorhandenen Ordner anschauen, wobei ich nie wusste welches du meinst xD

Jetzt hast du mich mit den Dateinen clib/rf_mbus.c und clib/rf_mbus.h konfrontiert und ich muss erst mal schauen wo ich die im Gesamtkonzept einordnen kann
Update: ich nehme an du meinst das Datum der Dateien dient nur als Indiz dafür, dass die culfw Dateien in Ordnung sind. Mit den rf_mbus.h etc. Dateien muss man wahrscheinlich nichts machen

Die Zeitstempel bei diesen beiden Dateien sind wirklich vom 24.06.2018

Werde jetzt dazu erst mal etwas recherchieren

Update: ok ich habe mir mal ein Package angeschaut, was ich evtl. verwendet habe. In der switch-Verzweigung sehe ich wirklich keinen C Mode... was ein Indiz dafür sein könnte, dass es kein C Mode unterstützt...

Code Auswählen Erweitern


switch (mmode) {
    case WMBUS_SMODE:
      for (uint8_t i = 0; i<200; i += 2) {
        if (sCFG(i)>0x40)
          break;
        cc1100_writeReg( sCFG(i), sCFG(i+1) );
      }
      break;
    case WMBUS_TMODE:
      for (uint8_t i = 0; i<200; i += 2) {
        if (tCFG(i)>0x40)
          break;
        cc1100_writeReg( tCFG(i), tCFG(i+1) );
      }
      break;
    default:
      return;
  }


In dem Package, auf das dein Link verweist ist hingegen ein C Mode vorhanden Was wiederum ein Indiz dafür sein könnte, dass es den C Mode unterstützt

Code Auswählen Erweitern


// load configuration
  switch (mmode) {
    case WMBUS_SMODE:
      for (uint8_t i = 0; i<200; i += 2) {
        if (sCFG(i)>0x40)
          break;
        cc1100_writeReg( sCFG(i), sCFG(i+1) );
      }
      break;
    case WMBUS_TMODE:
    // T-mode settings work for C-mode, which allows receiving
    // both T-mode and C-mode frames simultaneously. See SWRA522D.
    case WMBUS_CMODE:
      for (uint8_t i = 0; i<200; i += 2) {
        if (tCFG(i)>0x40)
          break;
        cc1100_writeReg( tCFG(i), tCFG(i+1) );
      }
      break;
    default:
      return;
  }


Update: Ah, auch meinem Raspbian System sehe ich gerade einen Ordner mit dem ich wahrscheinlich gearbeitet habe. Und in seinem rf_mbus ist auch kein C Mode.
Dabei habe ich darauf geachtet, dass es eine neue Version ist xD Trotzdem fehlt C Mode

Vielleicht klappt das ja jetzt wenn ich das ganze noch einmal neu flashe das wäre echt gut

Habe das ganze jetzt noch mal geflasht , mal schauen !



Update: Ja es war so ! Ich empfange nun im C Modus den den Wasserzähler ! Der value 2 Stand ist sogar der gleiche wie auf dem Display, was nicht selbstverständlich ist !

Zusammenfassend: Auf der Rechnung des Wasserzählers stand der falsche WMBUS Modus, nämlich T . Durch Nachfragen beim Hersteller konnte dieser sehr schnell sagen, dass es der C Modus ist ! Dann wurde trotzdem nicht empfangen. Grund: die culfw auf dem nanoCUL war nicht auf dem neusten Stand.

Damit ist das Thema erstmal fertig.
Vielen Dank für die Hilfe.
Und einen guten Rutsch xD