PGNs with "LOOKUP_FIELD("Instance", BYTES(1), ENGINE_INSTANCE)" field do not handle values correctly about canboat

[keesverruijt]

Probably your best solution is to ignore the lookup value for this field; use analyzer -json -nv instead of analyzer -json so you always get the underlying value for a lookup, regardless of whether there is a description for that value. As you can see below, with -nv you always receive a numeric value, and possibly a name string.

 $ echo "2016-04-09T16:41:40.049Z,2,127488,16,255,8,00,7a,0c,ff,ff,7f,ff,ff" | ./rel/darwin-arm64/analyzer -json -nv
 {"version":"5.0.1","units":"std","showLookupValues":true}
 {"timestamp":"2016-04-09T16:41:40.049Z","prio":2,"src":16,"dst":255,"pgn":127488,"description":"Engine Parameters, Rapid Update","fields":{"Instance":{"value":0,"name":"Single Engine or Dual Engine Port"},"Speed":798.5}}
 $ echo "2016-04-09T16:41:40.049Z,2,127488,16,255,8,02,7a,0c,ff,ff,7f,ff,ff" | ./rel/darwin-arm64/analyzer -json -nv
 {"version":"5.0.1","units":"std","showLookupValues":true}
 {"timestamp":"2016-04-09T16:41:40.049Z","prio":2,"src":16,"dst":255,"pgn":127488,"description":"Engine Parameters, Rapid Update","fields":{"Instance":{"value":2},"Speed":798.5}}

As you say starting with three motors there may be different orders to the engine numbering system, so you are better of using the underlying data from CANBoat then add your own naming order in a higher layer.

We cannot revert the fact that this is marked as a lookup field for compatibility reasons with downstream projects. A proper downstream project would not care if it changed between these two, but I have been told that they are not programmed defensively.

[aldas]

personally: this is not a showstopper.

Downstream projects are probably in a little bit trouble if they start to generate Enums (if their language supports it) out of Lookups, and these are actually only a subset of used/possible values, and see unknown enum value during decoding/parsing.

one suggestion - currently when lookup value is found - the field in JSON is string ("Instance":"Single Engine or Dual Engine Port") but in case value is not found - it is number ("Instance":2). Maybe it would be better to output that unknown value also as string - at least you can use string method on that unknown value like known value and not have type related problems.

[keesverruijt]

one suggestion - currently when lookup value is found - the field in JSON is string ("Instance":"Single Engine or Dual Engine Port") but in case value is not found - it is number ("Instance":2). Maybe it would be better to output that unknown value also as string - at least you can use string method on that unknown value like known value and not have type related problems.

I'm not changing the output without a VERY good reason. If I did this, there is no way for a consumer of this output to recognise that there is no lookup string available, and that this is a raw value.

If you are using a strongly typed parser that does not know how to handle different datatypes, use the -nv style output.