Here I have updated reportBuilder such that it keeps a local copy of the "max" CBOR map it receives during a sample interval. Then someone can get a copy of that "max" CBOR map and decode it to discover any relevant information they want. In this case upon aggregation, the rbrCodaSensor driver will copy the "max" CBOR map and parse through it looking for the desired node's rbrCodaType system config. The rbrCodaSensor driver will then stamp its aggregated sample with that type such that the Report Builder pass that RBR type on to Spotter who will then be able to bitpack the data appropriately.
The reason for decoding the CBOR map is so that the rbrCodaType that the rbrCodaSensor driver, Report Builder, and Topology/CRC reference is the same. This will guarantee that when a BMSensorData1 message is received on the backend there will be no mismatch between the BMSensorData1 messages CRC and its bitpacked data.
Here I have updated reportBuilder such that it keeps a local copy of the "max" CBOR map it receives during a sample interval. Then someone can get a copy of that "max" CBOR map and decode it to discover any relevant information they want. In this case upon aggregation, the rbrCodaSensor driver will copy the "max" CBOR map and parse through it looking for the desired node's
rbrCodaTypesystem config. The rbrCodaSensor driver will then stamp its aggregated sample with that type such that the Report Builder pass that RBR type on to Spotter who will then be able to bitpack the data appropriately.The reason for decoding the CBOR map is so that the
rbrCodaTypethat the rbrCodaSensor driver, Report Builder, and Topology/CRC reference is the same. This will guarantee that when a BMSensorData1 message is received on the backend there will be no mismatch between the BMSensorData1 messages CRC and its bitpacked data.