I spent a bit of time yesterday programming against the RFXCom reciever. The C# TcpClient class gets things up and running extremely quickly. In much same way as interacting with files (FileStream, StreamWriter), you can create a instance of a System.Net.Sockets.TcpClient, get a System.Net.Sockets.NetworkStream, and go to town with reading and writing of data off the socket.
It seems there are a few issues folks have encountered with Big vs. Little endian when sending/recieving messages across different platforms, this will not be as important a consideration for me, but something to keep in mind if you step down to this lower level.
What I’ve noticed in the stream from the RFXCom thus far is that there is no delimtter between messages, and I appear to be reading some incomplete bytes resulting in a few corrupt messages. I believe this is likely due to a read occuring when a byte isn’t fully populated. I plan to verify this by using the return value of the Read method (returns an integer representing bytes read) as I don’t expect to have instances where I am only reading a single byte.
Bert (and others) have done a tremendous job with documenting the device, but there isn’t enough information out there on direct socket programming to know exactly what to expect out of the device interactions.
My plan is to log the recieved messages along with date/time stamps into a SQL table that will be used as a message pump to a processing engine that will interpret the data, and push to a web service aggregator. I’m hoping to avoid the Lantronix middleware that maps the RFXCom IP to a local virtual serial port, which would make my package a little smaller, and easier to re-dist.
A self described geek, Chris' curiosity into how things work is often the motivator for new habits and ventures. A drinker of scotch, beer and vodka, and eater of meats as much as those green things beside them, Chris is as much at home behind the kitchen counter as being a diner at a local hot spot.