6 replies to this topic

[etc6849]

I was working on updating the betabrite driver. I finally felt confident in the updates so I exported the module and imported it onto my home server.

However, to my surprise, nothing was imported? I made a copy of the original module and tried again, same thing. I then rebooted the test PC where I wrote the driver, only to discover my work was all gone?!?

What is interesting is that you can see my work in the XDO file that's attached; it just won't import.

I was hoping that someone with a test PC could either try to import, or that an expert could examine the XDO file in notepad because I'm totally stumped... I'd try again and copy and paste from the XDO, but now I'm scared that I'll lose my work again... I thought it could be the comments that I copied and pasted from the PDF documentation file, but I tried deleting those and still didn't get anywhere.

Attached Files

•  betabrite_v3.zip   9.92K   33 downloads

[Waynedb]

I tried importing your driver on my test machine, nothing showed up in the modules list for me.
I can't help you on evaluating the code.

[123]

Look at the first post in "School of Hard Knocks" and read "Steer clear of special characters when scripting!". The problem is documented here in the original Premise Support forum.

Premise's Builder saves Modules in XML format (XDO file). However, Builder overlooks to convert special characters into a format that is XML-friendly. When it attempts to read the XDO file, it encounters the improperly formatted character and then rejects the entire XDO file.

Your Betabrite XDO file contains comments that appear to have been imported directly from MS Word because it contains characters that are not normally created in a text editor. I discovered them by changing the file's extension from XDO to XML and opening it with Internet Explorer. IE stops at each line containing a non-conforming XML statement.

For example, it contains Left and Right Double Quotation Marks (“ ”) as well as Right Single Quotation Mark (’) and the Em Dash (—). These characters are not XML-friendly and must be either escaped or replaced with plain vanilla double (") and single quotes (') and a hyphen (-), respectively. I've converted the offending characters in the attached file and it imports without error.

Attached Files

•  Betabrite_V3_XML_friendly.zip   9.92K   28 downloads

[etc6849]

Many thanks 123, you saved many hours of work (I'm slow at programming). I'll post the new version of the betabrite driver when I'm done. I really like your simple trick below; thanks for sharing

I'm contemplating adding your job class from the viziarf driver, as communications with the betabrite seem buggy. For example, when using the network query function every 20 seconds, the port becomes unresponsive after some time (less than an hour). I've implemented an auto port reset function, but I'm wondering if there's something I'm missing in the documentation because the failure rate seems very high. I'm going to have to research this more tonight.

Your Betabrite XDO file contains comments that appear to have been imported directly from MS Word because it contains characters that are not normally created in a text editor. I discovered them by changing the file's extension from XDO to XML and opening it with Internet Explorer. IE stops at each line containing a non-conforming XML statement.

[etc6849]

This is off topic, but why do rxTextLine strings starting with NUL show up as "" in the interpreter (even if the string contains some printable characters). The odd thing is they showed correctly once, but won't now after I restarted Premise. This is a big problem because the interpreter sees the string as zero length and RegEx won't work...

At any rate, I think I'm going to use the two byte protocol (replacing non-printable ascii with two printable ascii characters ie NUL becomes "] " and EOT becomes "]$") to avoid this issue with the betabrite (seems much more reliable, especially since I want to parse information from the betabrite using RegEx)... However, I'm still highly interested in the answer the above question (no rush though)

Edited by etc6849, 19 July 2010 - 10:08 PM.

[123]

In the C language, NUL (i.e. "\0") is used as a string terminator. If you have a buffer containing 10 bytes and NUL is the 5th one, then the first string is 4 characters long. If the buffer contains a single NUL, then the first string is zero-length.

I think if you need to handle NUL characters reliably you should consider using Binary mode (i.e. RxMode = false) instead of Text mode.

BTW, I went through the BetaBrite code and I have a question for you: Why do you extend the File class with SimpleExt?

Edited by 123, 20 July 2010 - 08:58 AM.

[etc6849]

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