Los decodificadores de carga útil del sensor se proporcionan principalmente como código javascript por parte de los fabricantes de sensores. Como estoy usando diferentes tipos de sensores, quiero usar los decodificadores originales sin reescribirlos en otros idiomas. Así que estoy usando un AWS Lambda (NodeJS) dentro de las reglas de AWS IoTCore para decodificar las diferentes cargas útiles de los sensores, lo que funciona bien.
En una regla de IoTCore posterior, quiero enviar la carga útil del sensor decodificado a una base de datos de AWS Timestream. Los tipos de datos de AWS Timestream se corrigen durante la primera escritura. Entonces, si el primer valor de medición "temperatura" era un número flotante como 23,14 grados, el tipo de medición se fija en un tipo Timestream::Double, que es lo que quiero.
Sin embargo, si el sensor mide un valor de 23,0 grados planos la próxima vez, la operación de escritura de Timestream genera el error "El nombre de medida ya tiene un tipo de valor de medida asignado. Cada nombre de medida puede tener solo un tipo de valor de medida y no puede ser cambió."
La razón radica en el analizador AWS Timestream, que funciona así: A numeric value without a decimal point is interpreted as a BigInt type. Asi que,...
> const f1 = 23.4 > const f2 = 23.0 > console.log(f1, typeof f1, f2, typeof f2) 23.4 'number' 23 'number' parseFloat(23.14) // becomes Javascript::Number 23.14 Timestream::Double. ==> ok! parseFloat(23.00) // becomes Javascript::Number 23 Timestream::BigInt ==> Error! No quiero usar parseFloat(23.00).toFixed(2) ya que se convierte en un valor de cadena, ni parseFloat(23.00) + 0.001 ya que está cambiando el valor y requiere siempre convertir/redondear valores al procesar los valores de AWS Timestream más adelante en.
¿Cómo resolver eso?
Resuelto omitiendo el marco de reglas de IoTCore y escribiendo en Lambda directamente en Timestream, allí puedo establecer explícitamente el tipo de valor de measureValueType = "DOUBLE" , lo que evita ese tipo de problema.