Possible idea/need for new decoder post_proc lookup

[DigiH]

Having just created an initial test decoder for the Braun Bluetooth toothbrushes, of which there seem to be quite a lot of models, and creating the decoder so far with the information given in

1technophile/OpenMQTTGateway#767

the linked documents shows that many of the properties are taken from lookup tables from the decoded decimal values

https://github.com/Hypfer/Cybele/blob/master/lib/devices/OralBToothbrushDevice.js#L59

I've implemented this currently with underscore variants and conditions for the corresponding hex values, but even with leaving some states and sectors out this inflates the decoder badly, currently having had to increase the peak doc size very slightly for two included tests to run.

https://github.com/DigiH/decoder/tree/Braun-initial

So I'm wondering if a similar lookup table implementation would benefit from something this and possibly other similar device decoders. maybe even incorporating it into the already existing post_proc functionality, with "==" and the link to the relevant table, something like

"state":{
         "decoder":["value_from_hex_data", "manufacturerdata", 10, 2, false, false],
         ""post_proc":["==", STATES]
      },

with the additional definitions included in the decoder

STATES = {
    0: "unknown",
    1: "initializing",
    2: "idle",
    3: "running",
    4: "charging",
    5: "setup",
    6: "flight_menu",
    113: "final_test",
    114: "pcb_test",
    115: "sleeping",
    116: "transport"
};

Love to hear your thoughts on this, and if and how you think it should/could be implemented.

[h2zero]

Something similar to the ".cal" option could be done.

Something like:

"properties":{
      ".lut":{
          0: "unknown",
          1: "initializing",
          2: "idle",
          3: "running",
          4: "charging",
          5: "setup",
          6: "flight_menu",
          113: "final_test",
          114: "pcb_test",
          115: "sleeping",
          116: "transport"
      },
      "state":{
           "decoder":["value_from_hex_data", "manufacturerdata", 10, 2, false, false],
           "post_proc":[".lut"]
       },

And the decoder code would just save the ".lut" object and use the value extracted to index the table.

[koenvervloesem]

This .lut option would also simplify the MS-CDP decoder.

[DigiH]

That would be great @h2zero, and if no according value is found in the table the property fails. In the Braun toothbrush case it would probably require 3 luts - .mod(e), .stat(e) and .sect(or).

[h2zero]

I'll leave that as an exercise for the reader 😀.

The basic single table should be simple, expanding it to multiple tables would be more challenging.

[DigiH]

The basic single table should be simple, expanding it to multiple tables would be more challenging.

Just saying ;) as the Braun toothbrushes already has these 3 luts, but with restrictions to only really necessary states, modes and clarifications about what unknown sectors are, the largest could be implemented with a lut, while the others might still require a few underscore variants for starters.