Open albfan opened 1 year ago
For repeated structures (you can receive several gps positions on same teltonika messages) or as mentioned several events, I'm not that clear about solution:
probably is better just reuse a buffer parser in a loop, removing already readed input:
https://flows.nodered.org/node/node-red-contrib-loop
But if you think there's an option to define a group of fields and read several times (where that times can be a previous field) that would be awesome.
And if we can name the groups and decide which one to use depending on other previous field, that would be the perfect solution.
NOTE I can collaborate on implementation, just checking if you find this use case interesting and there's a public interest for it.
I can code another example with AVL events to expose current solution and check for solutions on buffer-parser (Just let me know if this makes sense for this module)
teltonika messages (gps info) are dynamic. That means internally some positions define length for other fields or number of repeated structure to parse.
https://wiki.teltonika-gps.com/wikibase/index.php?title=Teltonika_AVL_Protocols&mobileaction=toggle_view_desktop#Codec_8
Examples: For UDP Codec 8, At very beginning, a field defines IMEI, wich length depends on a previous field "IMEI length":
AVL Packet Header:
NOTE: Doc says "IMEI length" is always 15, but forget just for this example. Get access to previous defined value would be great to avoid current solution, one buffer to read the length, a function node to setup the spec and continue reading:
Reading IMEI length:
Modify the spec to read that dynamic field:
so here if we can define length as a previous field, we will use imeiLength as input:
Attached flow injecting example data and parsing IMEI:
json export of "flow injecting example data and parsing IMEI"
NOTE: There are a special tricky section (AVL Events) like car ignition, gear change, where this would be specially useful as number of events is unknown and structure is really different from event to event.