Sort out serComm

[astrobokonon]

For a Sunpower GenII cooler, the STATE command returns 265 bytes:

2021-08-13 03:46:11,108 INFO     Good write: b'STATE\r'
2021-08-13 03:46:11,858 INFO     265 bytes recieved in response
2021-08-13 03:46:11,858 INFO     b'STATE\r\nMODE    = 002.00\r\nTSTATM  = 000.00\r\nTSTAT   = 000.00\r\nSSTOPM  = 001.00\r\nSSTOP   = 000.00\r\nPID     = 002.00\r\nLOCK    = 000.00\r\nMAX     = 110.00\r\nMIN     = 050.00\r\nPWOUT   = 000.00\r\nTTARGET = 065.00\r\nTBAND   = 000.50\r\nTEMP KP = 050.00000\r\nTEMP KI = 001.00000\r\n'

For timeout values less than 0.75 sec, I was getting less than 265 bytes - seemed like 0.5 seconds would get ~208 bytes, causing this query to fail because some of it was left on the socket buffer 😞

[astrobokonon]

Controller comm parameters are 4800 baud, 8 data bits, 1 stop bit, no parity and no flow (so 9 bits total per word - I'm assuming it's a 16 bit word size but I have no good idea). No other comm options.

TimePerBit (in sec) is 1 / baud rate, so that's ~208 microseconds per bit right there. With 9 bits per word, and 265 bytes total, that's 0.497 sec right there without any overhead or anything else. So 0.5 seconds is definitely too short. Le sigh.

[astrobokonon]

The way to fix this is to change serComm to read until the buffer is empty, not read for however long the timeout happens to be. I should just do that.

[astrobokonon]

Since I'm using pyserial, if I open the socket with timeout=0 it implies that it'll read up to the specified number of bytes and return immediately. But I'm pretty sure I enabled the timeout because I was getting network hiccups/hangups, so idk what (if anything) to really do here. Maybe call 0.75 sec better than 1 second and call it an evening with the other speedups.

See https://pyserial.readthedocs.io/en/latest/pyserial_api.html#serial.Serial.__init__

[astrobokonon]

Had to fall back to 1.0 seconds because the LS325 and the Sunpower controllers were dropping/mangling responses! Annoying.