Wireless M-Bus für CUL

[bilbolodz]

I've managed to reply (via pipe) message:

Code Auswählen Erweitern

b32446850296586536980EDECA0058420000050080000DB07E7070000F62B00000000000000000000000000000000FFFF000000000000000000FF

and route it into Techem HKV object. Just for record, the key issue is: MANUAL CREATE device with correct ID. In that case:

Code Auswählen Erweitern

define techem TechemHKV 53866529

Now I've to understand (more) how is working Techem and correctly convert to serve my meter. Question:

Function TechemHKV_SanityCheck checks CRC AND removed crc from message?

[herrmannj]

Yes

[bilbolodz]

One more question:

in TechemHKV_Parse there are calls to "more detailed parse functions". These functions get's as a parameter "message":

Code Auswählen Erweitern

sub
TechemHKV_ParseID(@) {
  my @m = @_;
  return ("$m[6]$m[5]$m[4]$m[3]", "$m[4]$m[3]");
}

As I understand $m is striped from first byte (length) of original message? (actually two bytes because of "b")  Am I right? (serial number should be at 4567 position not 3456).

[herrmannj]

Can't recall from mind but I guess you are right

[herrmannj]

After reading again be careful. In your 9.04 post id does not match with define. The id start right after 6850

[bilbolodz]

Right. Incorrect CRTL+C CTRL+V. Corrected previous post.

[bilbolodz]

Hmmmm. Another problem. It looks that message doesn't get my parse function....
My message is:

b89441486D0F9020003034CCEA0812433000C4000142A0F0510011234023CDC4E0A0306FF0C394C2A00C7902A009D1BF3EC2A0071AA2B00A29C2D00C7722F001DD4404930001AAF31006E083200AC583200C8FE24A03200F8FA3200030000000037D4081F9D4F000000002000000000000023000000007C6224000000000000270000002800000000BB5F00002C00200301050C2F0000000000004B2480

sub
ApatorWM_Initialize(@) {
  my ($hash) = @_;

  # require "Broker.pm";

  $hash->{Match}      = "^b..441486[\\d]{8}0303....A0.*";

  $hash->{DefFn}      = "ApatorWM_Define";
  $hash->{UndefFn}    = "ApatorWM_Undef";
  $hash->{SetFn}      = "ApatorWM_Set";
  $hash->{GetFn}      = "ApatorWM_Get";
  $hash->{NotifyFn}   = "ApatorWM_Notify";
  $hash->{ParseFn}    = "ApatorWM_Parse";

  $hash->{AttrList}   = "".$readingFnAttributes;

Log3 ("ApatorWM", 0, "Init: $hash->{Match}");

  return undef;
}

Internals:
   CMDS       Nocmdsfordummies
   Clients    :TechemHKV:ApatorWM:WMBUS:HMS:CUL_IR:STACKABLE_CC:TSSTACKED:
   DEF        /home/bilbo/robota/fhem-5.8/CUL_fifo@directio 1234
   DeviceName /home/bilbo/robota/fhem-5.8/CUL_fifo@directio
   FD         20
   FHTID      1234
   MessageEncoding CUL
   NAME       cul_emu
   NEXT_OPEN  1516274997
   NR         20
   PARTIAL
   RAWMSG     b89441486D0F9020003034CCEA0812433000C4000142A0F0510011234023CDC4E0A0306FF0C394C2A00C7902A009D1BF3EC2A0071AA2B00A29C2D00C7722F001DD4404930001AAF31006E083200AC583200C8FE24A03200F8FA3200030000000037D4081F9D4F000000002000000000000023000000007C6224000000000000270000002800000000BB5F00002C00200301050C2F0000000000004B2480
   RSSI       -138
   STATE      Initialized
   TYPE       CUL
   VERSION    V
   cul_emu_MSGCNT 3
   cul_emu_TIME 2018-01-18 12:29:04
   initString X21
brt
   Matchlist:
     8:HMS      ^810e04....(1|5|9).a001
     D:CUL_IR   ^I............
     H:STACKABLE_CC ^\*
     J:WMBUS    ^b.*
     M:TSSTACKED ^\*
   Readings:
     2018-01-18 12:28:57   cmds            No answer
     2018-01-18 12:29:04   state           Initialized
Attributes:
   dummy      1
   rfmode     WMBus_T
   room       WMBUS

Code Auswählen Erweitern

sub
ApatorWM_Parse(@) {

Log3 ("ApatorWM", 0, "ApatorWM_Parse");
  my ($iohash, $msg) = @_;
  my ($message, $rssi);
  ($msg, $rssi) = split (/::/, $msg);
Log3 ("ApatorWM", 0, "Parse: $msg");

  $msg = ApatorWM_SanityCheck($msg);

Log3 ("ApatorWM", 0, "after ApatorWM_SanityCheck: $msg");
[..]


But in logs I can see:

2018.01.18 12:28:57 2: Switched cul_emu rfmode to WMBus_T
[..]
2018.01.18 12:28:57 0: Init: ^b..441486[\d]{8}0303....A0.*
2018.01.18 12:28:57 3: Define 195024
[..]
2018.01.18 12:47:57 2: WMBUS WMBUS_APT_00036030_3_3 Error during ApplicationLayer parse:Unsupported CI Field a0, remaining payload is 812433000c4000142a0f0510011234dc4e0a0306ff0c394c2a00c7902a009dec2a0071aa2b00a29c2d00c7722f001d4930001aaf31006e083200ac583200c8a03200f8fa3200030000000037d4081f000000002000000000000023000000002400000000000027000000280000000000002c00200301050c2f000000000000

What could be wrong?

[herrmannj]

What could be wrong?

cant say ... but parse will not be called (at least I cant see the log entry for it). So it is in the area of matching the client regex. May be you must place some more log point in fhem.pl dispatch to see what happens ...

update:
from CUL internals:
Clients    :TechemHKV:ApatorWM:WMBUS:HMS:CUL_IR:STACKABLE_CC:TSSTACKED:

So your module ís registered

[bilbolodz]

update:
from CUL internals:
Clients    :TechemHKV:ApatorWM:WMBUS:HMS:CUL_IR:STACKABLE_CC:TSSTACKED:
So your module ís registered

I know. There was an error in matching filed it should be:

Code Auswählen Erweitern

^b..441486[0-9a-fA-F]{8}0303....A0.*

[herrmannj]

makes sense. That is an difference on how techem does their ID but it may be an wise move to adapt that.

[bilbolodz]

Finally working..... (first version). Now next questions (not about programming of FHEM internals but rather "generally"):

1) My Meter reports water volume in let's sat "ticks" (it's addon for regular mechanical meter). To convert it into real cubic meter it's to be multiply by some factor. Factor probably depends on mechanical meter. By comparing ticks and visual numbers on meter I've computed that my factor is about:  0.000333333 but it could be different for another meter. Should I report "raw ticks" from meter or should I multiply it by factor and return real water volume? If real water volume how to put factor into module? Hardcoding it into source is probably bad idea I think it should be a parameter which can be set by FHEM but how to do it?

2) Meter besides volume ticks reports:

day number - changes +1 every day
day of month (for 24.12 it's 24)
day of week (strange because Friday is 1 ... Sunday is 3 .... Monday is 4 ... Thursday is 7)
hour
minute
seconds

How should I report it into FHEM ("as what")?

Meter sends of course more information that I've wrote but I don't know a meaning of it.

[setstate]

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.

Kann es sein, dass die ttydata.c auch an anderer Stelle noch nicht für Bufsize > 256 funktioniert?

Code Auswählen Erweitern

uint8_t cmdlen;

[herrmannj]

Finally working..... (first version). Now next questions (not about programming of FHEM internals but rather "generally"):

1) My Meter reports water volume in let's sat "ticks" (it's addon for regular mechanical meter). To convert it into real cubic meter it's to be multiply by some factor. Factor probably depends on mechanical meter. By comparing ticks and visual numbers on meter I've computed that my factor is about:  0.000333333 but it could be different for another meter. Should I report "raw ticks" from meter or should I multiply it by factor and return real water volume? If real water volume how to put factor into module? Hardcoding it into source is probably bad idea I think it should be a parameter which can be set by FHEM but how to do it?

2) Meter besides volume ticks reports:

How should I report it into FHEM ("as what")?

Meter sends of course more information that I've wrote but I don't know a meaning of it.

you can do that by introducing a attribute but because of the central importance it may also be part of the define (maybe rpm or whatever)

[kaihs]

Kann es sein, dass die ttydata.c auch an anderer Stelle noch nicht für Bufsize > 256 funktioniert?

Code Auswählen Erweitern

uint8_t cmdlen;

Ja, sieht so aus, die Größe dieses Puffers muss < 256 sein, damit es nicht zu einem Überlauf kommt.

[setstate]

Hab's jetzt hin bekommen mit getrennten Buffer-Größen.

128 für cmdbuf und TTY_Rx_Buffer;
358 für TTY_Tx_Buffer

Code Auswählen Erweitern

static char cmdbuf[TTY_BUFSIZE_R+1];

extern rb_t TTY_Tx_Buffer;
extern rb_t_r TTY_Rx_Buffer;

die WMBUS Devices werden angelegt und die Werte kommen. Beispiel: ca. 19 für DeviceMedium Heat.

Leider senden die Geräte nur von 6:00-18:00 Uhr, deshalb konnte ich gestern Abend nicht mehr testen.

Wer kann die Änderung in der culfw jetzt offiziell einbauen?

Update:
Zu früh gefreut, der nanoCUL antwortet nicht mehr. Da hat sich was aufgegangen.