The v1.7 version uses:
//SHT20,temperature,units:℃
TempC_SHT:((bytes[2]<<24>>16 | bytes[3])/100).toFixed(2),
That yields a text result. To convert to a proper JSON number (which will output 5 for "5.00" and 5.1 for "5.10"), prefix with a plus:
// SHT20 temperature; unit: °C
// Sign-extend to 32 bits to support negative values, by shifting
// 24 bits to the left (16 too far), followed by a sign-propagating
// right shift of 16 bits, to effectively shift 8 bits. And unary plus
// operator to convert string result of toFixed to number:
TempC_SHT: +((bytes[2]<<24>>16 | bytes[3])/100).toFixed(2),
// SHT20 humidity; unit: %
Hum_SHT: +((bytes[4]<<8 | bytes[5])/10).toFixed(1),
Actually, as dividing by 100 should never yield excessive decimals in JavaScript, I’d remove the toFixed. (This would be different for, e.g., multiplying by 0.01, like 2224 * 0.01 yields 22.240000000000002, while 2224 / 100 is simply 22.24.)
(There are a few more occurences in that code.)
And aside, the following:
//DS18B20,temperature,units:℃
TempC_DS:
{
"1":((bytes[7]<<24>>16 | bytes[8])/100).toFixed(2),
}[bytes[6]&0xFF],
… could be written as:
TempC_DS: bytes[6] === 1 ?
+((bytes[7]<<24>>16 | bytes[8])/100).toFixed(2) : null
Still ugly, but that’s due to using return without any temporary variables. I’d use some switch-case instead.
I wonder if think the 0xFF in bytes[6] & 0xFF is an error. It has no effect. All other code uses 0x7F instead.