dyvel:
Hi guys
I have a Wood Pellet Boilers installed in our house that has a RS485 communication port. I know it's possible to buy an accessory module that allow me to control the burner through SMS (start/stop/status etc).
The chip on the boiler is a SP483C. Found the data sheet for those who are interested SP483CS (Sipex) - Low Power Half-Duplex RS-485 Transceivers
But to get to the point - I'd like to hook into that communication port and control the boiler from my Arduino. I'm quite new to RS485, but I understand I can get a TTL to RS485 converter, so my Arduino can communicate using RS485.
But what are my options - is it even possible to "tab" into that line knowing nothing about the protocol and commands that are used?
I have the firmware the boiler runs on, but it's compiled into a .uc3 file and not readable (to me at least). It's compiled to run on an Atmel 32uc3a0512 http://www.atmel.com/devices/AT32UC3A0512.aspx
Any pointers or guidance would be appreciated - even if the answer is - don't do it, not possible 
Have a nice day!
This is an old post, but having done a significant amount of device control programming, it is interesting to me.
First, yes... converting Arduino serial I/O to RS485 will be fairly easy, and you can both buy or build such adapters without too much fuss.
But on to the bigger issue of actually controlling and or monitoring the device. Before trying to reverse engineer the code (often difficult even if you had the current version of source code), it is usually best to start by making every effort to get some documentation on the communication protocol right from the manufacturer. Sometimes it takes approaching them as if you were a company looking to make an add on (maybe much like what you are planning) which could then add value of their device and potentially bolster sales. That strategy works especially well if you have some backing, such interest on behalf of several of their customers for the device you're planning.
In the absence of getting the protocol handed to you, yes... it is still possible to connect an RS485 device as a "listener"/recorder, if you have one of the devices the unit is supposed to connect with. This is often the only way to find out what is needed to communicate with a device when a manufacture is unwilling to be cooperative. but this is still not an easy task. As one other person pointed out though, RS485 is half duplex, requiring the protocol to have an agreed understanding as to which side initiates conversation. In your case it is likely that the available module would be the side initiating requests, but it can become difficult at times to know which messages are coming from which device, except in the rarer case or 4 wire RS485. On a two wire path, often if you can monitor the signals with an oscilloscope, there will be a good chance you'd see a slight different in the amplitude peak levels of bit streams from each device, because each may have a slightly different 5 volt supply. That may help to identify who is speaking at any given instant. Hopefully there will be a small number of messages for a given function, and with the recorder you might be able to capture what is going on.
But there are other challenges here too. First, you need to know particulars of the serial communication (baud rate, parity, and number data and of stop bits, and that's just if its ASYNC communication!). Since you don't, you may be recording garbage for a while before finding anything that makes sense. And to make it even worse, if the protocol is pure binary (such as a MODBUS, DNP, or completely "in house" protocol), it will be difficult to tell whether recorded data streams get you a buffer full of garbage, or real data. It is possible using an oscilloscope to observe and analyze the data and at least figure out the baud rate, by observing minimum "bit" times and doing the necessary math. It is important to get the serial details right because if you don't, "playing back" your captured messages through the UART will just turn the garbage into worse garbage.
As you can see, you could get lucky, but it could also become a nearly impossible task. If its a simpler text based protocol is being used you may have a shorter time to analyze before things make obvious sense. sadly, text based protocols are unlikely for something like this. And beyond just the data part of the protocol, there are other less likely but possible problems. If the devices use proprietary serial electronics, for example to generate a non standard number of data bits or some other protocol not based on serial standard serial communications, you're ARDUINO will not easily record what is being transmitted, except possibly as an A/D input with some tricky analysis. On top of that, if the manufacturer has any security scheme in place whose purpose it to prevent "unauthorized" control, your time to crack the protocol could rapidly get to the "not worth it" point.
But despite all that negativity, I can tell you its do-able. I've worked with a team of folks whose job it was to crack such communication schemes, mostly for the purpose of monitoring electrical measurements available from the device we wanted to connect to. It wasn't always easy, but there were usually at least a few happy surprises along the way. Good luck!
