search

Steve-Mcl / node-red-contrib-buffer-parser

A node-red node to convert values in a buffer, integer array or hex string into many different data type(s). Supports Big/Little Endian, BCD, byte swapping and much more.
MIT License
26 stars 9 forks source link

feature request: allow two or more post processing operations #18

Open nonujigu opened 1 year ago

nonujigu commented 1 year ago

As far as I understand, the scale input box only allows one operation. According to my experience, there are many scenarios where it is necessary to carry out two operations to transfer a raw value into a physical value. A typical scenario is the multiplication with a scale factor and the addition with an offset (*physical_value = raw_value scale_facror + offset**). Or in other words: In many scenarios the scale factor is not equal to 1 while at the same time the offset is not equal to 0. Because of this missing feature, what I end up doing is to not override the default value (1) in the scale input box and utilize a function node for post processing. This would not be necessary if the scale input box would allow 2 or more operations. As an example I would like to mention the dbc file format, which contains information on how to decode raw data from a CAN bus. In a dbc file editor, a new decoding rule is initialized with scale factor 1.0 and offset 0.0. However, the user has the ability to override both. As an alternative it might be worth considering to allow the functionality of the "range" node within each scale input box.

Steve-Mcl commented 1 year ago

It is a good suggestion but I didn't initially want to develop a full blown AST parser (for speed implications). We could perhaps have additional simple evaluators that are operated upon sequentially (or perhaps use a special character for separating operations like a comma or bar?)

nonujigu commented 1 year ago

Maybe this could be the perfect use case for JSONata. It is already built into Node-RED and therefore might be relatively easy to implement. A lot of Node-RED users are already familiar with JSONata. Actually, the post processing method that I initially described (utilizing a function node) could also be done by utilizing JSONata within a "change" node. The downside of JSONata might be that certain operations like "bit shift" are not available in JSONata.

Steve-Mcl commented 1 year ago

I have fairly strong aversion to jsonata. I find it thoroughly unintuitive & often terribly slow. That said, I suppose we could add it as an option for other users. In order to make this backwards compatible though, the "scale" typedInput entry will have to have both the original "simple scale equation" feature (default option, as it is now) and the jsonata as a secondary choice.

Are you up for developing this and raising a pull request? My day job is very demanding of my time right now so it would help get it implemented sooner rather than later.

nonujigu commented 1 year ago

I have zero experience in developing nodes, but I think this could be the first step into this. However, my day job does not allow such a project, meaning it would probably not speed up anything.

Steve-Mcl commented 1 year ago

I am happy to leave this to you (perhaps you want to use it as a foot into programming and development?)

Happy to guide you through the steps if you wish?

Otherwise, let me know and I will attempt to get it done.

(PS, feel free to nudge me if you done see anything within a couple of weeks)

nonujigu commented 1 year ago

I am happy to leave this to you (perhaps you want to use it as a foot into programming and development?)

Happy to guide you through the steps if you wish?

Otherwise, let me know and I will attempt to get it done.

(PS, feel free to nudge me if you done see anything within a couple of weeks)

Thanks. I did take a look at the code. It will take me some time to fully understand the specification object and the associated parser.