I managed to reproduce the problem you described. The problem was that the LED setting had to be written to EEPROM. That takes around 4 milliseconds. During that time the code didn't service the serial port. However, you continued to send more data which caused a buffer overrun. Subsequently the code failed to detect and handle that situation. So from that point onward the gateway would not receive any serial data anymore.
I checked the code of firmware 3.4 and confirmed that it would have the same problem. You say your script worked with 3.4. My guess is you only used it when the LEDs were already configured as you wanted. In that case the code detects no change is necessary and cleverly skips the EEPROM write operation.
Your method intrigued me, and now that responses can more easily be linked to their commands it makes sense to support it. So I started calculating: An EEPROM write takes 4 milliseconds. The shortest serial command is 4 characters + CR. Each character has a start and stop bit, adding up to a minimum of 50 bits for a command. At 9600 baud that takes 5.2 milliseconds. That means that the serial transmission of a possible next command takes long enough for the EEPROM write to complete.
So rather than just cleaning up when an overrun occurs, I decided it might be better to keep an eye on the serial interface while waiting for the EEPROM write to complete. As a result your bombardment of serial commands can now be handled by the gateway. The only time you need to allow the gateway some time is when you change the setback temperature. For that setting it may need to write 2 bytes to EEPROM, which takes 8 milliseconds.
But even if you immediately follow the SB command with another command, it will not hang up the serial interface. The command is just ignored, or leads to an error message. Sending a few LF characters after an SB command should provide the delay necessary for the gateway do its thing. Linefeeds are ignored by the gateway.
I can't think of any scenario that might still cause an overrun on the serial interface. But if it does happen, the code will now clean it up correctly.
These fixes are available in
firmware 4.0a10.
