Support multiple .cal values in decoder

[koenvervloesem]

Is your feature request related to a problem? Please describe.

In #138 I need three .cal values to calculate acceleration in X, Y and Z axes. I defined a .cal value three times because I wanted to extract three bytes and and use these values in calculations, but it seems the decoder is only using the latest .cal value, so the three calculations are using the same extracted value.

Describe the solution you'd like

I'd like to be able to use more than one .cal value.

Describe alternatives you've considered

I haven't found an alternative way.

Additional context

This is the relevant code:

      ".cal":{
         "decoder":["value_from_hex_data", "servicedata", 12, 2, false, false],
         "post_proc":["/", 10]
      },
      "accx":{
         "condition":["servicedata", 8, "0000"],
         "decoder":["value_from_hex_data", "servicedata", 14, 2, false, false],
         "post_proc":["/", 100, "+", ".cal"]
      },
      "_accx":{
         "condition":["servicedata", 8, "0001"],
         "decoder":["value_from_hex_data", "servicedata", 14, 2, false, false],
         "post_proc":["/", 100, "+", ".cal", "+", 1]
      },
      "__accx":{
         "condition":["servicedata", 8, "0100"],
         "decoder":["value_from_hex_data", "servicedata", 14, 2, false, false],
         "post_proc":["/", 100, "+", ".cal", "*", -1]
      },
      "___accx":{
         "condition":["servicedata", 8, "0101"],
         "decoder":["value_from_hex_data", "servicedata", 14, 2, false, false],
         "post_proc":["/", 100, "+", ".cal", "+", 1, "*", -1]
      },
      ".cal":{
         "decoder":["value_from_hex_data", "servicedata", 20, 2, false, false],
         "post_proc":["/", 10]
      },
      "accy":{
         "condition":["servicedata", 16, "0000"],
         "decoder":["value_from_hex_data", "servicedata", 22, 2, false, false],
         "post_proc":["/", 100, "+", ".cal"]
      },
      "_accy":{
         "condition":["servicedata", 16, "0001"],
         "decoder":["value_from_hex_data", "servicedata", 22, 2, false, false],
         "post_proc":["/", 100, "+", ".cal", "+", 1]
      },
      "__accy":{
         "condition":["servicedata", 16, "0100"],
         "decoder":["value_from_hex_data", "servicedata", 22, 2, false, false],
         "post_proc":["/", 100, "+", ".cal", "*", -1]
      },
      "___accy":{
         "condition":["servicedata", 16, "0101"],
         "decoder":["value_from_hex_data", "servicedata", 22, 2, false, false],
         "post_proc":["/", 100, "+", ".cal", "+", 1, "*", -1]
      },
      ".cal":{
         "decoder":["value_from_hex_data", "servicedata", 28, 2, false, false],
         "post_proc":["/", 10]
      },
      "accz":{
         "condition":["servicedata", 24, "0000"],
         "decoder":["value_from_hex_data", "servicedata", 30, 2, false, false],
         "post_proc":["/", 100, "+", ".cal"]
      },
      "_accz":{
         "condition":["servicedata", 24, "0001"],
         "decoder":["value_from_hex_data", "servicedata", 30, 2, false, false],
         "post_proc":["/", 100, "+", ".cal", "+", 1]
      },
      "__accz":{
         "condition":["servicedata", 24, "0100"],
         "decoder":["value_from_hex_data", "servicedata", 30, 2, false, false],
         "post_proc":["/", 100, "+", ".cal", "*", -1]
      },
      "___accz":{
         "condition":["servicedata", 24, "0101"],
         "decoder":["value_from_hex_data", "servicedata", 30, 2, false, false],
         "post_proc":["/", 100, "+", ".cal", "+", 1, "*", -1]
      }

As seen in the test results of #138, the latest .cal value (the byte at index 28 of the service data) is used for all calculations that refer to .cal.

[h2zero]

Wow, the size of some of these is getting much bigger than I imagined. I think it best that the code simply uses the last .cal value provided before decoding the next data, order of operations sort of thing. I thought that would be happening already, but it's been a while since I looked at it.

[koenvervloesem]

I think it best that the code simply uses the last .cal value provided before decoding the next data, order of operations sort of thing.

Yes, that's also what I was expecting and why I was writing the decoder this way. This would probably be enough for many use cases.

[koenvervloesem]

Closing this issue because it's already supported: #138 (comment)