RS485 communication techniques

RS485

Introduction

RS485 is a physical layer communication standard typically used in automation systems as a way for sensors and other devices to communicate to a central automation computer.  It is also used in computer system peripherals for data communication between devices.  A couple examples of this are the Small Computer Systems Interface, or SCSI-2 and SCSI-3 interfaces for hard disk drives.  Different systems use different protocols as their defined standards outlining the "language" they will use to communicate to each other.   In this short article I will discuss data communication using an RS485 serial bus and the best practices for an error free signal.

What is RS485?

RS485 has sometimes been referred to as a protocol, which it is not.   It is simply a communications interface wiring standard.  Unlike RS232 serial which is used for point to point serial communications, RS485 is a standard used for multi-point serial communications.  RS485 communication is typically done at half duplex using two wires  handling both transmit and receive.  Full duplex operation can be achieved using 4 wires depending on signal and speed needs.  Below is a diagram of an RS485 serial bus showing the master node and slave nodes.
RS485 Bus Diagram
As can be seen in the diagram, there is the two data lines, or differential pair, where the master and slaves connect, and at the end of the differential pair is a series of termination resistors.  Because the wires are a differential pair, the termination resistors are used to prevent reflections of the signal from back-feeding on to the line and causing collisions.  An RS485 network should only have termination resistors at the beginning and end of the transmission line.

The communication

Data transmitted on an RS485 bus can be heard by all nodes connected to that bus.  Because of this, a protocol is used to determine how that communication is managed.   The protocol must define a system for how data is transmitted, how a node knows that the data is meant for that node and how that node responds to the data it receives.  There have been a number of different protocol standards used in RS485 communication, with one of the most notable standards being the Modbus protocol.

RS485 interface types

RS485 USB Interface

There are many different types of RS485 interfaces on the market.  One is a USB type interface as seen on the left. This type will allow you to use a laptop or desktop PC as a master device, or a slave node on the network.  Another type such as the interfaces shown below are typically used to connect to a micro-controller such as an Arduino or a PICAXE, or small credit card size computers like the Raspberry PI or Beaglebone Black.  Interfaces such as the ones below typically come with the termination resistors integrated on to the board and may need to be removed if being used as slave nodes in the network.Microcontroller RS485 interfaces

RS485 bus setup

In an RS485 topology, the network is designed as one single line with multiple drops, or slave nodes.  As mentioned previously, termination resistors are put in place at both ends of the line to prevent signal reflection.  When termination resistors are not used, signal reflection can distort the signal on the line to the point of causing data loss or corruption.  These reflections are more noticeable on longer runs because the length of the pulse is long enough for the full pulse to make it to the far receiving end.  Once it reaches the end, it is then reflected back causing ghost signals that can differ in phase by the time it has ended.  On shorter cable runs, the the delay of the reflected signal is short enough that the distortion may not affect things because the phase difference will be negligible.
RS485 bus termination
Termination resistors should not be used at the slave nodes as this will cause unwanted signal attenuation.  With too much attenuation the signal may get lost completely.  Therefore, on node adapters where termination resistors are in place by default, such as the ones pictured above, you may need to remove them if they are not acting as the end node.

Conclusion

RS485 can be a good way of connecting automation devices where wired connection between devices is critical in preventing drops in signal.  Following these simple rules for connecting the bus, the signal transmission between devices should be quite reliable.

Related Images:

Adding HVAC overlays to MisterHouse

Introduction

DISCLAIMER: This is an old topic that I migrated from my old website due to the traffic it used to get.  I no longer use MisterHouse for my automation, so I will not be able to answer any questions regarding this topic.  Some of this information may be out of date, but may still work.

indoor temperatures graph

For some time now I have been using the MisterHouse automation software with my Raspberry Pi as my main automation software.  One of the features that I use is the weather data from the internet_weather.pl common code module.  I also have an RCS-TR40 RS485 thermostat and 7 one-wire temperature sensors throughout the house that I use with this setup also.  The weather module has a graphing feature that allows me to graph the indoor temperatures from my one-wire sensors.  A sample of this is shown to the right.  Though this was a nice feature, there was somehting missing.  I wanted a visual representation of my HVAC operation overlayed on the graph.  I saw a perfect example of what I was looking for on Marc Merlin's blog site marc.merlins.org/perso/homeha/2009-12.html.  About 1/4 of the way down the page you will see the 2 graphs.  Marc uses cacti with RRD to get his results, but I was using a module in MisterHouse that did not have this functionality.  This post shows the steps I took to modify the code in the weather module to be able to do this.

The Code Modification for HVAC Overlays

Before performing any of the steps described here, it is always a good idea to make backups of the files that you are modifying in the event that you need to revert back.  With that said, let's proceed.

The main file that you will need to modify is the weather_rrd_update_graphs file located in the MisterHouse/bin folder of your installation.  When I made the modifications to my setup, I had to start a new RRD database file because of the way that I modified the file.  I am going to show you how to do this in a way that SHOULD NOT affect your current RRD database.

The first step is to locate the section of code that defines the default color codes for the graphs.  In my file, this started at line 44.  Depending on the number of HVAC zones and whether you want to show heating, cooling or both for these zones, this will determine the number of tempspares that you will want to sacrifice for this.  In my setup I only have single zone heating and cooling, so I would only need to hijack $tempspare9 and $tempspare10.  The default color codes used for 9 and 10 are "66FFFF" and "0000CC" respectively.  These will need to be changed.  I used "FF6F7D88" (9) for the heating color, and "6F87FF88" (10) for the cooling color.  One thing you will notice that is different with these 2 values is that they are longer than the original values with the added "88" at the end of each. This is very important as the last 2 hex values are the transparency values.  This is what allows the HVAC color bars to be overlayed over thetemperature line graphs and still have them visible.

The next part is a bit tricky.  You will need to remove the tempspare RRD DEFinitions for whatever $tempspares you are using for this.  In my setup I would remove tempspare9 and tempspare 10 DEFs.  For each tempspare, you will need to remove 6 lines of code.

1 ."\"DEF:mintempspare9=$RRD:tempspare9:MIN\","
2 .($weather_uom_temp eq 'C' ? "\"CDEF:fmintempspare9=mintempspare9,32,-,5,9,/,*\"," : "\"CDEF:fmintempspare9=mintempspare9\",")
3 ."\"DEF:maxtempspare9=$RRD:tempspare9:MAX\","
4 .($weather_uom_temp eq 'C' ? "\"CDEF:fmaxtempspare9=maxtempspare9,32,-,5,9,/,*\"," : "\"CDEF:fmaxtempspare9=maxtempspare9\",")
5 ."\"DEF:tempspare9=$RRD:tempspare9:AVERAGE\","
6 .($weather_uom_temp eq 'C' ? "\"CDEF:ftempspare9=tempspare9,32,-,5,9,/,*\"," : "\"CDEF:ftempspare9=tempspare9\",")

Now, where you deleted these lines of code, you will add 2 lines for each tempspare you are replacing.

1
."\"DEF:tempspare9=$RRD:tempspare9:AVERAGE\","
2 ."\"CDEF:ftempspare9=tempspare9,1,EQ,INF,UNKN,IF\","

Next, you will need to change the LINE2 definitions for your tempspares to AREA plots.  Find the following lines:
. ($sensor_names{tempspare9} ? "\"LINE2:... :'')

Remove the "LINE2" and "GPRINT" lines from each and replace with this:

"\"AREA:ftempspare9#${colortempspare9}:" . sprintf("%-${max}s",$sensor_names{tempspare9}) . "\","

For the last code modification, you need to edit the weather_rrd_update.pl file in "misterhouse/code/common/".  Look for this block of code:

if($config_parms{weather_uom_temp} eq 'C') {
grep { $_=convert_c2f($_) unless $_ eq 'U' } ($rrd_TempOutdoor, $rrd_TempIndoor,
$rrd_TempSpare1, $rrd_TempSpare2, $rrd_TempSpare3, $rrd_TempSpare4,
$rrd_TempSpare5, $rrd_TempSpare6, $rrd_TempSpare7, $rrd_TempSpare8,
$rrd_TempSpare9, $rrd_TempSpare10, $rrd_DewOutdoor, $rrd_DewIndoor,
$rrd_DewSpare1, $rrd_DewSpare2, $rrd_DewSpare3, $rrd_TempOutdoorApparent
);
}

You will need to remove all references to TempSpareXX that you are converting.  If not done, this could prevent the HVAC bars from showing up if you have your user configuration "weather_uom_temp" set to "C"elsius.

HVAC overlays user code additions

Now you need to define things in your user code.  This will vary for each setup as thermostats and/or ways of identifying that the furnace or AC is on are done differently in each setup.  This is basically how I have it set up in my user code:

# Define the weather hash's initial starting HVAC values
if ($Startup or $Reload) {
    $Weather{TempSpare9}  = int(0);
    $Weather{TempSpare10} = int(0);
}

#### Now, if your furnace is on tempspare 9, the code will be something like this: ####
if ($RCS_current_state eq 'heat') {
# Tell the weather hash that the furnace is on
$Weather{TempSpare9} = int(1);
} else {
# Tell the weather hash that the furnace is off
$Weather{TempSpare9} = int(0);
}

Last, you can tweak your setup in your mh.private.ini file adding your own sensor names for each tempspare that you set up.  You can also tweak the colors of your displayed bars from here the same as your other sensors.  Remember though, if you change color values in your mh.private.ini file, you NEED to add the transparency value to each color.  I found 88 to be a good transparency value for me, but your situation may differ.

Below is a sample output of my setup with the furnace overlays in place.

Related Images:

My Home Automation Setup

The start

So over the years I have mostly used X10 for my home automation hardware. I used it because it was pretty much the cheapest solution out there. The hardware worked, but it had it's problems and limitations. So last year when my Raspberry Pi had died that I had running a PERL based automation software called MisterHouse, I wanted to explore other solutions. I ended up stumbling on the MySensors website. MySensors is an open source DIY home automation hardware platform that works with a good number of automation controller softwares, many of which are open source themselves. Orange Pi PC Board I started with a software called Domoticz and had it running on a new kind of development board that I picked up cheap ($18 US). The board is the Orange Pi PC.  The board is roughly the same size as a Raspberry Pi and it runs a similar version of embedded linux.   All I needed to do to get started with MySensors was to build a gateway node that  would talk to the sensors.  There were a few different options for communications hardware.  nRF24L01+ BoardI ended up choosing the nRF24L01+ radio boards.  The main reason was because hey were wireless which meant that I could put sensors in places that before were near impossible.  But they were also cheap.  I was hooked.  I could build whatever sensors I wanted, and there were plenty of examples to get me started.  My goal was to completely replace my old X10 hardware and upgrade it to MySensors as much as possible.  I started with a node for controlling and monitoring my garage door opener.  From there I was hooked.  I wanted to MySensorize everything.  So it continued.

Changing controllers yet again

So after using Domoticz for a while, I ended up finding a few limitations.  Being a member of the MySensors forum for a while, I decided to do some searching.  I noticed that a few of the people on the site were using a platform called Vera.  Vera is a hardware device type of automation controller and it has a plugin architecture that can support many different types of hardware, one of them being MySensors.  I ended up requesting and getting a Vera Plus controller as a gift.  It is a great platform and is very customizable with LUA scripting.   The plugins for it are pretty much all built with LUA script.  I have yet to find a problem I can't solve with it.

My current setup

I currently have 40 plus home automation nodes and it keeps growing.  From MySensors nodes to WiFi controlled relays to my Amazon Echo and more, my system continues to grow.  I am always looking for new ways to automate my life.  I don't think I will ever stop.

Conclusion

I encourage you to go out and automate your life.  It is a lot of fun.  Check back to see other posts from me about my journey through my automated life.

Related Images: