Sorry about that 123. The extension won't be there in the final version. It is there so that older code I had can correctly set the betabrite's parameters for displaying data (since I wasn't using File class before). I plan on making all of my home code compatible with your file class structure when I'm done with the driver. I use the betabrite for all kinds of properties in Premise (brightness level, volume level, motion detection, weather and time).
Binary mode would fix the NULL issue... However, I was still having trouble getting RegEx to work with a binary array after I transformed it into a string. In some test code I made last night, I had to go through the binary array, pick out the corresponding character for each byte and make a string for RegEx to use. However, I couldn't get this working as the NULLs still appeared in the string and RegEx still got confused. A better method might be to make a string that represents the ascii hex values for each character of a received line (ie the string would look like "000000000001"). I think one could then use RegEx...?
At any rate, it turns out the two byte protocol is much more reliable from a communications stand point. The two byte protocol also has a fixed baud rate of 9600. This means there is no need to send 5 NULS (aka "] " in two byte mode). If I ask the betabrite something using the two byte protocol, it replies using the two byte protocol (which avoids NUL, STX, EOT etc...). I'm not sure what was going on before when the port became unresponsive, but it's not happening with two byte mode (after 8 hours of queries every 10 seconds). My guess is that one of these two caused the unresponsive port: the BetaBrite was miss calculating the baud rate from the 5 NULS at random or that Premise didn't like receiving so many NULS when I queried the sign.
I should have a solid driver to post that never has an unresonive port in a week or so