SML: support for byte stuffing for Kamstrup devices

[JanSchmidt3]

Kamstrup devices (i.e. water meter, heat meter) use a byte stuff algorithm, whith cannot be handelt be SML raw decoder. So I created a patch to xsns_53_sml.ino as followes

The principle is to add a "stuff type" (I used 'k' for Kamstrup) before the data type (the example can be used for Kamstrup multical 21 water meter):

>D

>B

->sensor53 r

>M 1

+1,3,rN2,0,1200,WASSER,1,20,803F1007004403EC0063004A00F30124012BE2C30D

1,0044280443kUUuuUUuu@1000,Verbrauch,m³,volume,19

1,004A290200kUUuu@1,flow,l/h,flow,20

1,03EC330400kUUuuUUuu@1,hours,h,hours,0

1,0124250100kuu@1,water temp,°C,watertemp,0

1,012b250100kuu@1,meter temp,°C,metertemp,0

#

If the decoder finds that 'k', the following information will be destuffed before decoding. I modified only the datatypes which are used by kamstrup devices.

This patch works for me, I compiled the project with gitpod, but cannot create a pull request. Maybe someone with proper rights can patch the code and update the docu.

Jan

diff --git a/tasmota/tasmota_xsns_sensor/xsns_53_sml.ino b/tasmota/tasmota_xsns_sensor/xsns_53_sml.ino index c3a9a9743..214435066 100644 --- a/tasmota/tasmota_xsns_sensor/xsns_53_sml.ino +++ b/tasmota/tasmota_xsns_sensor/xsns_53_sml.ino @@ -1777,12 +1777,27 @@ char *skip_double(char *cp) { return 0; }

+uint8_t byte_destuff (uint8_t typ, uint8_t **cp, uint8_t index)
+{

• uint8_t retval = *(*cp + index);
• if (typ == 'k')
• {
• if (*(*cp + index) == 0x1b)
• {

•  retval = ~*(*cp + index + 1);
  

•  (*cp)++;
  

• }
• }
• return retval;
  +}

void SML_Decode(uint8_t index) {
const char mp=(const char)meter_p;
int8_t mindex;
uint8_t *cp;
uint8_t dindex = 0, vindex = 0;

• uint8_t destuff_typ = ' ';
  delay(0);

  while (mp != NULL) {
  @@ -1973,8 +1988,15 @@ void SML_Decode(uint8_t index) {
  cp += skip;
  }
  }

•        } else if (*mp == 'k') {
  

•          mp++;
  

•          destuff_typ = 'k';
         } else if (!strncmp(mp, "UUuuUUuu", 8)) {
  

•          uint32_t val = (cp[0]<<24) | (cp[1]<<16) | (cp[2]<<8) | (cp[3]<<0);
  

•          //uint32_t val = (cp[0]<<24) | (cp[1]<<16) | (cp[2]<<8) | (cp[3]<<0);
  

•          uint32_t val = byte_destuff (destuff_typ, &cp, 0) << 24;
  

•          val |= byte_destuff (destuff_typ, &cp, 1) << 16;
  

•          val |= byte_destuff (destuff_typ, &cp, 2) << 8;
  

•          val |= byte_destuff (destuff_typ, &cp, 3);
           mp += 8;
           cp += 4;
           if (*mp == 's') {
  

@@ -1996,7 +2018,9 @@ void SML_Decode(uint8_t index) {
ebus_dval = val;
mbus_dval = val;
} else if (!strncmp(mp, "UUuu", 4)) {

•          uint16_t val = cp[1] | (cp[0]<<8);
  

•          //uint16_t val = cp[1] | (cp[0]<<8);
  

•          uint16_t val = byte_destuff (destuff_typ, &cp, 0) << 8;
  

•          val |= byte_destuff (destuff_typ, &cp, 1);
           mbus_dval = val;
           ebus_dval = val;
           mp += 4;
  

@@ -2030,7 +2054,9 @@ void SML_Decode(uint8_t index) {
mp += 4;
cp += 2;
} else if (!strncmp(mp, "uu", 2)) {

•          uint8_t val = *cp++;
  

•          //uint8_t val = *cp++;
  

•          uint8_t val = byte_destuff (destuff_typ, &cp, 0);
  

•          cp++;
           mbus_dval = val;
           ebus_dval = val;
           mp += 2;
  

[TheChatty]

@JanSchmidt3 Nice extension. Please edit this file by clicking the little pen in the upper right corner, "Propose changes" and "Create pull request" - done.
By the way... {your | all SML] code deserves some code comments.

Also, just my thoughts, "byte stuffing" could be made the default for Kamstrup protocol (spare the extra k in the meter definition)... currently the only protocol where it's meaningful.

[JanSchmidt3]

Sorry, I didn't see the Kamstrup protocol before... (In my point of view, kamstrup could be decoded via the raw decoder.)
But with the support for spezial protocol the send string is easyer to create and byte stuffing is already implemeted for both sending and receiving. With using the dedicated protocol, my path is not required anymore.

[TheChatty]

Gemu only recently added Kamstrup.

When I quickly read your initial post I thought it would handle the different length responses (if reading multiple values at once). Nevermind. Have fun using the new protocol like this.

[oliverjoa]

Hi @JanSchmidt3,

I have a multical 21, but still can not read out the values. How did you do it? Do you have some blog or detailed explanation?
Could you please help out here? I can not find any documentation about successfully reading values from a multical 21 via IR.

Thanks a lot.

[LinusHoppe]

@oliverjoa : Multical21 via IR wasn't possible for me - I used the wmbus protocol and wmbusmeters with standard configuration. You need the encryption key to do so.

[TheChatty]

I read the MC with TTL-Adapter and with ESP: see here.

[oliverjoa]

@TheChatty , I have a multical 21, I can not find that on your page?
@LinusHoppe, thats the problem, I am not allowed to get the key
thanks

[jnissen]

Hello,
ist this possible with Tasmota Default ?, or must I Patch any thing ?