65.53 triggered a bell to me.
does 65535 rings a bell to you ?
one less than 2 to the 16th power
there is a 16b integer somewhere in your value.
256 (2 to the 8th power) for 8 bits value. those numbers are important.
The harvested array changes because your data reached a limit.
below 65500 (I think it could-must be 65535), the low byte is 0 and the high is the value. If it increases, your low byte changes to 1 and you add the difference
in your case (1x65535) + 464 = = 65999 => 65.99 = 66.0 (precision)
Note: it could be different, depending if your register is signed or unsigned.
a signed value has a range of 32767 because the value can be also negative while an unsigned value has a range of a full 16bit, aka 65535 ! In your case, your modbus register is an unsigned 16b
of course, your modbus device could also have 32bit registers, you can count.
16b registers are common in modbus devices, some devices have only 16b registers. But you can harvest them an modify/split them the way you want.
I have one plc and before sending data to mqtt / node-red, I change them all to 16b to simplify the poll.
coils (relays), digital 0 or 1 => 16b register (0 or 1)
32b registers ? convert them to 16b registers and pay attention if their value is over 65535.
I'm lazy, so if I know that the 32b register I poll will never be over 65535 (by example a temperature on a float register), I divide them by 100, tranform them to 16b and multiply then by 100 on the other side to obtain 2 numbers after the comma.
Float1 = 45.35 ===> tempo = 45.35x100 = 4535 => transform to 16b => 4535 ===> node-red/etc ==> 4535 / 100 = 45.35 on the other side. Far easier than send floats and convert them with functions [low byte, high byte], etc !