What does “doesn’t update” mean? Are you sure you’re not getting the very same payload from the device, every time step == 6?
Testing with your 0010E423060C44B7204544ADD6AB44A3C1440A50 nicely decodes to:
{
"field1": 1465.0084228515625,
"field2": 1390.7083740234375,
"field3": 1310.03955078125
}
Of course, I don’t know what the expected values are. But when indeed expecting floating point numbers (MSB) then the decoder seems fine.
For future readers who might like to use your Decoder: can you add some details about the meter? (Brand, type, …)
(Some asides: for the meterID see also 32 Bit overflow in Payload Format decoder, as I’m sure you’re not expecting that to ever be decoded into a negative value, though you’re not outputting that anyhow. The accuracy of the float values is not truly that many decimals; you can use toFixed to limit the decimals. Also, nbytes seems to suggest the payload might be shorter or longer as well, and bytestofloat does not use its bytes parameter at all. And finally: it seems the meter includes a CRC, which I feel is not needed as LoRa already adds a CRC, and the LoRaWAN message already includes a MIC. But I assume that’s out of your control.)