Decoding Smart Waste Bin Detector payload

End Devices (Nodes)
10

It seems the device uses an old standard known as “packed binary-coded decimal” (BCD), which encodes each digit into its own nibble (4 bits). So, Tony is right about this:

Fixed for the octal problem (see further below), that would then read:

AirLevel = (bytes[2] >> 4) * 1000 
  + (bytes[2] & 0x0F) * 100 
  + (bytes[3] >> 4) * 10
  + (bytes[3] & 0x0F)

Just as another fun fact, one could abuse JavaScript’s type coercion and use intermediate string values:

// Convert to hexadecimal strings without any "0x" prefix, hence
// treated as decimal values when coercing back to a number (due
// to the multiplication and the explicit unary plus operator).
AirLevel = bytes[2].toString(16) * 100 + +bytes[3].toString(16)

Yes, that needs two plus-characters for that second part, one being addition and the second being the unary plus. (One could also multiply the second part by 1, to get a number.)

So:

function Decoder(bytes, port) {
  return {
    // Decode groups of 4 bits into single booleans
    BinFull: (bytes[0] & 0xF0) > 0,
    Fire: (bytes[0] & 0x0F) > 0,
    Fall: (bytes[1] & 0xF0) > 0,
    BatteryLow: (bytes[1] & 0x0F) > 0,

    // BCD: interpret hexadecimal 0x0230 as decimal 230, not decimal 560
    AirLevel: (bytes[2] >> 4) * 1000 
      + (bytes[2] & 0x0F) * 100 
      + (bytes[3] >> 4) * 10 
      + (bytes[3] & 0x0F)
  };
}

Which seems to pass all tests for the data we know.

Click to see the decoded examples

  • …giving for 00 00 10 34:

    {
  "AirLevel": 1034,
  "BatteryLow": false,
  "BinFull": false,
  "Fall": false,
  "Fire": false
}

  • …yields for 10 00 02 30:

    {
  "AirLevel": 230,
  "BatteryLow": false,
  "BinFull": true,
  "Fall": false,
  "Fire": false
}

  • …would yield:

    {
  "AirLevel": 303,
  "BatteryLow": true,
  "BinFull": false,
  "Fall": false,
  "Fire": false
}

  • …gives:

    {
  "AirLevel": 140,
  "BatteryLow": true,
  "BinFull": true,
  "Fall": false,
  "Fire": false
}

Some more asides:

So, it’s not encoded the way I figured above, as this would still show a value of 230 as hexadecimal 0x021E, not as 0x0230 like documented.

Welcome to the amazing world of octal numbers! :partying_face:

Above, 00001111 does not denote a binary number, but due to it starting with a zero, it’s interpreted as an octal number, where 10 is decimal 8. So rather than this being hexadecimal 0x0F or decimal 15, using 00001111 yields decimal 585. (This has changed in ECMAScript 6.)

The version of JavaScript that is used by the Payload Formats (being: ECMAScript 5) does not have any prefix to explicitly denote binary, like one can use 0x to prefix hexadecimal numbers, where 0x10 is decimal 16. (ECMAScript 6 allows for writing 0b00001111.)

One could use parseInt("00001111", 2), and as JavaScript is doing all kinds of type coercions for you, even parseInt(1111, 2) would work, where 1111 is first changed into the string “1111” and then interpreted as a binary number. But leaving out the quotes would not work with leading zeroes, as then it would first be interpreted as octal yielding 585 in decimal, after which the string “585” cannot be parsed as a binary number.

No need for explicit casting; (bytes[0] >> 4) != 0 is already a boolean, so suffices.

That’s indeed what I’d expect (though the parentheses are not needed when using a bitwise OR). But like you already wrote: given the examples I guess it’s not.

1 Like