Wireless M-Bus für CUL

[setstate]

ich bekomme

Code Auswählen Erweitern


2018.01.17 16:27:51 2: WMBUS Error during LinkLayer parse:message too short, expected 178, got 140 bytes
2018.01.17 16:27:51 2: Please make sure that TTY_BUFSIZE in culfw is at least two times the message length + 1


wenn ich in der board.h auf 357 erhöhe,

Code Auswählen Erweitern

#define TTY_BUFSIZE             357

meldet sich das Board nur noch als

V 1.67 nanoCUL433 und es passiert nix mehr.

Bei TTY_BUFSIZE   256 meldet sich ein V 1.67 nanoCUL868 und ich bekomme die WMBUS raw msg  im LOG.

Ich habe schon alle defines ausser

Code Auswählen Erweitern

#define HAS_MBUS

auskommentiert.

Was kann ich noch machen, um Speicher zu sparen? Liegt es am Speicher?

Nachtrag:
Was ich noch rausgefunden habe: Ab 256 wird uint16_t benutzt.

Code Auswählen Erweitern


#if TTY_BUFSIZE < 256
typedef struct
{
  uint8_t putoff;
  uint8_t getoff;
  uint8_t nbytes;       // Number of data bytes
  char buf[TTY_BUFSIZE];
} rb_t;
#else
typedef struct
{
  uint16_t putoff;
  uint16_t getoff;
  uint16_t nbytes;       // Number of data bytes
  char buf[TTY_BUFSIZE];
} rb_t;
#endif


Aber warum ist dann nur noch nanoCUL433 möglich?

[bilbolodz]

Is there a way to "simulate" receiving message from CUL (reply saved real signal during development). My meter sends telegrams between 8AM to 4 PM - it's very inconvenient time (for me) to play with module.....

Any ideas how to inject fake message to module?

[kaihs]

Any ideas how to inject fake message to module?

I think there was once a discussion about this in this forum, but I can't remember the details.

You'll probably get more responses if you ask the question in a new thread in the 'English Corner' of this forum.
This thread has probably only few readers.

[bilbolodz]

I think there was once a discussion about this in this forum, but I can't remember the details.

Could you please try to find these topic? I don't speak German so it's hard to find it using keyword but I can try to read it using google translator. I've almost ready module to read my Apator Water Meter but I need to check it more throughly.

[kaihs]

Was kann ich noch machen, um Speicher zu sparen? Liegt es am Speicher?

Wenn man die culfw compiliert kommt am Ende eine Meldung über den verwendeten Speicher, z. B,

Code Auswählen Erweitern


Size after:
   text    data     bss     dec     hex filename
  19590     138    1448   21176    52b8 nanoCUL.elf


data+bss ist der statische RAM Verbrauch, dazu kommt dann noch der Stack.
Der ATMega328p hat nur 2048 Bytes RAM.

Welche Zahlen stehen da bei dir?

[setstate]

Code Auswählen Erweitern

Size after:
   text    data     bss     dec     hex filename
  11712     120    1783   13615    352f nanoCUL.elf

[kaihs]

Code Auswählen Erweitern

Size after:
   text    data     bss     dec     hex filename
  11712     120    1783   13615    352f nanoCUL.elf

Das ist knapp, da kann es durchaus zu einem Stacküberlauf kommen. Danach ist dann alles möglich, auf jeden Fall funktioniert die culfw dann nicht mehr ordentlich.

Wie gut kennst du dich mit C-Entwicklung aus?
Wahrscheinlich kann man mit manueller Optimierung noch bei ausschließlicher WMBUS Benutzung unnötigen Code entfernen.

Als ich mir das damals angeschaut habe war mit aufgefallen, dass man die Pufferverwaltung wahrscheinlich optimieren könnte.
Es gibt nämlich drei Puffer die durch TTY_BUFSIZE beeinflusst werden, aus ttydata.c:

Code Auswählen Erweitern


rb_t TTY_Tx_Buffer;
rb_t TTY_Rx_Buffer;
static char cmdbuf[TTY_BUFSIZE+1];


Für den Empfang muss aber nur der TTY_Tx_Buffer groß genug sein, die anderen beiden könnten auf z. B. 128 stehen.
Dazu müsste aber auch der Code in ringbuffer.c angepasst werden, so dass dieser Puffer unterschiedlicher Größe verwalten kann.

Ein
#define MBUS_NO_TX
könnte evtl. auch was bringen.

Und zu guter Letzt könnte noch der Code in clib/mbus optimiert werden. Dieser verwendet nämlich nochmal einen eigenen Puffer um aus diesem dann wieder in den TTY_Tx_Buffer zu kopieren. Eigentlich könnte er gleich diesen Puffer verwendet.

Ist aber alles nicht mal eben so gemacht.

[setstate]

 
Da war ich auch schon heute und hatte die gleiche Idee: Tx kann int8 bleiben und Rx auf int16

Code Auswählen Erweitern

rb_t TTY_Tx_Buffer;
rb_t TTY_Rx_Buffer;


Da werde ich mal etwas fummeln

[kaihs]

Da war ich auch schon heute und hatte die gleiche Idee: Tx kann int8 bleiben und Rx auf int16

Code Auswählen Erweitern

rb_t TTY_Tx_Buffer;
rb_t TTY_Rx_Buffer;


Da werde ich mal etwas fummeln

Das wird nicht viel bringen, das sind ja nur die Indizes in den Puffer.

Am einfachsten ist es wahrscheinlich

Code Auswählen Erweitern


static char cmdbuf[128+1];

zu verwenden. Dafür muss nichts in ringbuffer.c geändert werden.
Der code in ttydata.c verwendet sizeof für die Größenermittlung von cmdbuf und muss daher auch nicht angepasst werden.

[kaihs]

Could you please try to find these topic?

I'm sorry, but I can't find it.

One way to create such an emulation might be to create a named pipe (mkfifo) and use this as the device file when defining the CUL device.
Than one could simply write the previously received messages into the fifo and the fhem CUL device would receive it.
Never tried this in practice though.

[bilbolodz]

I've defined CUL with fifo

define cul_emu CUL /home/bilbo/robota/fhem-5.8/CUL_fifo 1234

but "STATE" is disconnected In logs I can see:

2018.01.17 22:06:38 3: Opening cul_emu device /home/bilbo/robota/fhem-5.8/CUL_fifo
2018.01.17 22:06:38 1: PERL WARNING: can't getattr: Inappropriate ioctl for device at ./FHEM/DevIo.pm line 391.
2018.01.17 22:06:38 3: Can't open /home/bilbo/robota/fhem-5.8/CUL_fifo: Inappropriate ioctl for device

[kaihs]

2018.01.17 22:06:38 1: PERL WARNING: can't getattr: Inappropriate ioctl for device at ./FHEM/DevIo.pm line 391.

Hm, a FIFO isn't a real serial device and doesn't support the necessary ioctl.

Try

Code Auswählen Erweitern


define cul_emu CUL /home/bilbo/robota/fhem-5.8/CUL_fifo@directio 1234


because

If the baudrate is "directio" (e.g.: /dev/ttyACM0@directio), then the perl module Device::SerialPort is not needed, and FHEM opens the device with simple file io

[bilbolodz]

Thanks. Better it's working Now I've to check why module is not working

[bilbolodz]

I've copied module 32_TechemHKV and modified for my needs. Unfortunately message put into fifo is dispatched to WMBUS module and "served as usual" (Unsupported CI Field a0). I've found on forum a few examples of TechemHKV telegrams but every of them creates "generic WBMUS entry" with "Unsupported CI Field" error not  TechemHKV device..... I don't know how to check what's wrong. Does TechemHKV should be autocreated after receiving valid telegram?

[herrmannj]

TechemHKV intercepts the msg in an non-standard way. To listen, it requires an cul in wmbus_t mode. It may be that the FIFO setup does not satisfy that.  If no cul (TYPE = CUL) found or if it is not in WMBUS_T mode no msg at all is intercepted by TechemHKV

See sources about details.

add:
Techem devices will not be auto created. instead it must be defined by ID. But, if TechemHKV is working properly (cul present etc), it filters all techem msg, so no techem msg will be forwarded to WMBUS any more