Since you asked about bit shifting:
As a rule of thumb: when decoding numbers you’ll shift a full byte (8 bits), or sometimes a nibble (4 bits), or any multiples of that. So, the 19 bits above are really unexpected, and the result is basically the same as bytes[5]<<5
along with sign extension. What were you trying to achieve there?
This basically just divides the value by 2, discarding the rightmost bit. What were you expecting here?
If you were trying to decode a single signed byte, then in JavaScript (which for bitwise operators always assumes signed 32-bits integers) you could use:
// Sign-extend a single byte to 32 bits to make JavaScript understand
// negative values, by shifting 24 bits to the left, followed by a
// sign-propagating right shift of the same number of bits.
params.temp_int = bytes[5]<<24>>24;
The above should correctly show you the integer part for both positive and negative temperatures. If you would be combining multiple bytes, the above translates to:
// Signed integers, MSB
var int8 = bytes[0]<<24>>24;
var int16 = bytes[0]<<24>>16 | bytes[1];
var int24 = bytes[0]<<24>>8 | bytes[1]<<8 | bytes[2];
var int32 = bytes[0]<<24 | bytes[1]<<16 | bytes[2]<<8 | bytes[3];
I explained much more on shifting in Payload Format / Decode for TM-901 / N1C2 sensor from KCS TraceME - #4 by arjanvanb.
As for the (unsigned) decimal/fractional part, and even a full decoder for your device, search is your friend: see Laird RS1xx payload format. Laird is using a weird encoding for this one.
Asides: for the initialization, var params = {};
really suffices, and please see How do I format my forum post? [HowTo]