Zwave Home Automation, Leviton RS232 Serial Interface RZC0P basic wiring for USB Serial Adapter

I've started to work with a ZWave home automation control product from Leviton, the RZC0P-1LW. This device allows the control of Zwave based wireless home automation devices via a RS-232 interface.

The Zwave system is a proprietary system requiring a licensing agreement with Zwave Alliance group. Joining this group and paying some level of fees gives a developer access to programming and related information. The lowest level of membership in 2009 appears to be the Affiliate Member with an annual fee of USD300 and perhaps the requirement to purchase a USD500 hardware development kit.

There are a couple of other ways to programmatically work with Zwave devices, there are several home automation software and hardware systems that put one or more layers on top of the Zwave proprietary protocol. Doing a Google search of home automation and zwave will give you a list of these product. There are even a couple of open source projects that have reverse engineered parts of the Zwave control protocols and devices.

And a third way, in a sense a mini home automation layer, is to use one of these RZC0P devices in an existing Zwave network. As far as I can tell so far, the RZC0P cannot be the primary controller of a Zwave network. And every Zwave network requires one of these primary controllers to add, delete and manage the devices in a Zwave network. However, the RZC0P can be included as what is called a secondary controller. And a small amount of documentation has been created by Leviton to show you how to do basic functions to Zwave devices via ASCII commands to the RZC0P.

I've studied the Zwave products, vendors and public information for a couple of years. More on what I have found about it and my opinions later.

But for now, I wanted to share some tech work I did to get the RZC0P running on a small Zwave network I have set up to explores of of the uses of these devices for both Aging In Place and Energy Management.

I am not a RS-232 expert nor an electrical engineering guru. But I have spend enough time in both of these areas that I knew that I had a problem talking to the RZC0P pretty quickly. I had the documentation on the ASCII commands and the RS-232 configuration requirements. Using these, I hooked the RZC0P up to a IBM Thinkpad with a build in RS-232 port and was able to start communicating with the device right a way. The problems came with I tried to move my testing to a Apple OS X computer with a KeySpan USA-19HS USB serial adapter. I wanted do my testing using the Python language and tools and was more comfortable with using these tools on Linux and OS X.

The problem I encountered was that I could not get the RZC0P to respond to commands when attached via the KeySpan USB serial port. I did not try the KeySpan USB adapter on the Windows machine, but I suspect from reading some posts on the web that I would have found a similar problem. I found several other people that indicated they were only successful in communicating with the RZC0P using a serial port directly attached to the Windows machine.

At first I suspected that I was not correctly toggling some of the RS-232 control signals, however the devices cable and documentation point to, but do not directly spell out, that only TX, RX and Signal Ground pins are required on the cable and no software or hardware handshaking is done.

A further interesting fact appear as I played around with various terminal emulators on OS X and cable combinations. At various points of these changes, the RZC0P would start communicating. I struggled to find the pattern that made it work.


Well bottom, apologizes for my long route to my conclusion here.. I suspect that the RZC0P has some bug or non-standard implementation of RS-232 electrical interface. I found that if I used a RS-232 break out box between the Keyspan USB serial adapter and the RZC0P, with just the three pins, TX, RX and Signal Ground connected, the unit would work consistently. I could plug and unplug it, power it off and it would always come right up and communicate with the Mac software. So what was special about this RS-232 break out box?

The breakout box connects a set of LED from the TX and RX lines to signal ground via pull up resistors. This allows you to visually see the signal states change on these and other lines on the RS-232 specification. The breakout box I was using is a totally passive unit that adds no power or logic to the RS-232 signals it monitors.

So my conclusion is that the signal ground and RX/TX lines on the RZC0P are wired internally in some way that caused the logic circuit to not correctly start RS-232 communications without some electrical connection/kick between the RX/TX lines ad signal ground line.

My solution to the problem was to build a mini 9 pin DB-9 Male to Female adapter that recreated the passive monitoring circuit I found in the RS-232 breakout box.

I am guessing there is a better and simpler solution to this problem, but this seems to be working, and you get some visual feed back of the communications occurring via the two LEDs. Below is a picture of the finished adapter.



Here are the parts and steps:

Parts:
Male 9 pin DB-9
Female 9 pin DB-9
2 - 560 ohm 1/4 watt resistors
2 - LED
wire to connect pin 2 to pin 2, male to female DB 9
wire to connect pin 3 to pin 3, male to female DB 9
wire to connect pin 5 to pin 5, male to female DB 9

Steps:
Connect pin 2 to pin 2, male to female DB 9
Connect pin 3 to pin 3, male to female DB 9
Connect pin 5 to pin 5, male to female DB 9

Connect pin 2 on the male DB-9 connector to one lead of a 560 ohm 1/4 watt resistor
Connect the second lead of the 1st 560 ohm resistor to the anode lead of the 1st LED
Connect the cathode lead of the 1st LED to pin 5 on the male DB-9 connector

Connect pin 3 on the female DB-9 connector to one lead of the 2nd 560 ohm 1/4 watt resistor
Connect the second lead of the 2nd 560 ohm resistor to the anode lead of the 2nd LED
Connect the cathode lead of the 2nd LED to pin 5 on the female DB-9 connector

Review by Walt Mossberg @ WSJ of USB connectable Diabetes Meter

One of the areas I am interest in is easy to use medical measurement devices. Weight, blood pressure, temperature, glucose, pulse, breathing, sleep patterns are among the measurements that can be recorded as part of proactive medicine. These will let us Age In Place much more successfully.



Walt Mossberg has a review of a device that is a small first step toward easy to use and record products, the Bayer Contour USB blood glucose meter

A key piece that is missing from this device, is wireless upload, you have to connect it to your PC via USB. The technology in the area of low power wireless short range communication has really shot forward. I think any device that does not easily transfer its measurements wirelessly to a personal computer or some home health gateway is not useful enough to really jumpstart proactive medicine.

As Walt points out, the other major missing aspect of this device is it lack of ability to upload it's reading to one of the Personal Health Record systems, for example Microsoft HealthVault or Google Health. This is key so that a person's doctor and caregivers can have near real time information about these measurements.

So this is the right direction, just not enough of a step forward yet. Give Mr. Mossberg's text or video review read/listen.

I am excited about wireless devices that will help us live a much more healthy and happy total life.

User interfaces and online personal healthcare record web sites

I have been experimenting with the main online electronic personal medical records web sites. Mostly with Microsoft and Google's offerings. I have found both to be 'works in progress'. Microsoft's HealthVault is on the top of my list right now and the most mature and useable by normal, non-techies.

That said, the HealthVault product received a BIG negative rating mark from me today. I went into the site to add some blood pressure values and found that without notice they had modified their Silverlight based blood pressure data entry widget. I have no idea of all of the changes they made, right away just looking at the GUI you could sense a subtle change in the look. But the negative mark is give for transposing the SAVE and CANCEL button location! What DUMB move to make. It shows me that these developers still do not understand the human aspect of the user interfaces they develop and the profound changes that a change like this in a medical application could have.

On this day of the first flight of the Boeing 787 Dreamliner, I can only think of the heads that would roll if a SAVE and CANCEL button were reversed on the flight deck before first flight!

A lot of work and education needs to be done in order to get electronic medical records moving forward successfully.

I have followed Microsoft's work on HealthVault for almost a year now, they are working hard to make a good product. So want to be positive and give them a lot of 'that a boys [and girls]'. But this change today is a example of the experience they need to gain.

I have using this data entry widget on a daily basis for six months now, and noticed when they converted from Adobe Flash tool to Microsoft's Sliverlight. That change, in itself, showed the same lack of experience in code updates and the effect on the application's user. They are still catching up to the speed of operation of the Flash based widget.

I am very sure that in the picture below, the two buttons shown are transposed from were they were located yesterday.

Using the Nordic nRF24L01+ 2.4GHz transceiver with Adruino

I picked up a Nordic nRF24L01+ breakout board and keychain remote FOB from Sparkfun.com a while ago to see about using it as part of a Aging In Place electronics project. Finally got around to experimenting with the pair this weekend. It was a cathartic break from working a plumbing problem.

I could not find much info on using it with the Arduino platform. To get my feet wet I just moved an example program written for AVR PIC to Arduino's language. I have posted it below.

The Nordic communication chips seem to be a good product for low power, long life remote control. The questions of range and clashes with other products in the 2.4GHz bands are still open.

The steps to talk with the Nordic chips are very straight forward. It uses the SPI communications for interfacing and has a simple interrupt architecture for status [the code below does not use the interrupt]. The Sparkfun breakout board is a nice starting point as it allows hookup to either 5 volt or 3.3 volts products by providing onboard voltage for the Nordic. And the Nordic chips are natively able to talk 5 or 3.3 volt.

I will compare some of these functions and price points with some of the other similar products out there. The Texas Instruments wireless products are one set that I want to compare.

// nfr2401_02
// 13-December-2009
//
// learning how to communicate with a Nordic nfr2401 wireless communications module.
// this program will set up a nfr2401 as a receiver and receive data from the key presses on a Sparkfun Nordic nfr2401 keyfob.
//
// parts:
// Transceiver nRF24L01+ Module with Chip Antenna Sparkfun sku: WRL-00691
// Nordic FOB Sparkfun sku: WRL-08602
// Arduino Deiecimila
//

// based on Nordic-FOB-Tester-v10.c written by Nathan Seidle at Sparkfun.com in 6-19-2007
// based on article and code 'Interfacing a Serial EEPROM Using SPI' at Arduino.cc by Heather Dewey-Hagborg

// SPI registers defined in basic Arduino:
// SPCR SPI Control Register
// SPDR SPI Data Register
// SPSR SPI Status Register

/* Arduino SPI register info
Data registers simply hold bytes.
For example, the SPI data register (SPDR) holds the byte which is about
to be shifted out the MOSI line,
and the data which has just been shifted in the MISO line.

Status registers change their state based on various microcontroller conditions.
For example, the seventh bit of the SPI status register (SPSR) gets set to 1
when a value is shifted in or out of the SPI.

The SPI control register (SPCR) has 8 bits, each of which control a particular SPI setting.

SPCR
| 7    | 6    | 5    | 4    | 3    | 2    | 1    | 0    |
| SPIE | SPE  | DORD | MSTR | CPOL | CPHA | SPR1 | SPR0 |

SPIE - Enables the SPI interrupt when 1
SPE - Enables the SPI when 1
DORD - Sends data least Significant Bit First when 1, most Significant Bit first when 0
MSTR - Sets the Arduino in master mode when 1, slave mode when 0
CPOL - Sets the data clock to be idle when high if set to 1, idle when low if set to 0
CPHA - Samples data on the falling edge of the data clock when 1, rising edge when 0
SPR1 and SPR0 - Sets the SPI speed, 00 is fastest (4MHz) 11 is slowest (250KHz)

*/

#define DATAOUT 11 //MOSI
#define DATAIN  12 //MISO 
#define SPICLOCK  13 //SCK
#define CHIPSELECT 10 //CS, also called SS slaveselect

#define NFR_CE 9 // nRF2401 sets the chip to RX or TX mode
#define NFR_IRQ 8 // active low interrupt from nRF2401

byte clr;  // temp to hold discardable SPI return data

byte data_array[4];  // holds data in packet received from Key FOB

byte incoming;  // holds status register of nfr2401

int button_presses; // holds count of number of times a button had been pressed on FOB [since battery replaced]


// routine to send and receive a byte on SPI

char spi_transfer(volatile char data)
{

  SPDR = data;                    // Start the transmission
  while (!(SPSR & (1<<SPIF)))     // Wait the end of the transmission
  {
  };

  return SPDR;                    // return the received byte
}

// main arduino setup routine

void setup()
{
  Serial.begin(9600);
  
  Serial.println("Configuring the nRF2401.");

  pinMode( DATAOUT, OUTPUT);
  pinMode( DATAIN, INPUT);
  pinMode( SPICLOCK, OUTPUT);
  pinMode( CHIPSELECT, OUTPUT);
  
  pinMode( NFR_CE, OUTPUT);
  pinMode( NFR_IRQ, INPUT);


  //interrupt enabled,spi enabled,msb 1st,master,clk low when idle,
  //sample on leading edge of clk,system clock/4 rate (fastest)

  SPCR = (1<<SPE)|(1<<MSTR);
  clr=SPSR;
  clr=SPDR;
  delay(10);


  digitalWrite(CHIPSELECT, HIGH); //disable SPI comm with device
  digitalWrite(NFR_CE, LOW); //chip disable the nRF2401  
  

  digitalWrite(CHIPSELECT, LOW); //enable comm with SPI device 
  spi_transfer(0x20); //enable RX irq, CRC enabled, be a receiver
  spi_transfer(0x39);
  digitalWrite(CHIPSELECT, HIGH); //disable SPI comm with device

  digitalWrite(CHIPSELECT, LOW); //enable comm with SPI device
  spi_transfer(0x21);  // disable auto-acknowledge
  spi_transfer(0x00);
  digitalWrite(CHIPSELECT, HIGH); //disable SPI comm with device
    
  digitalWrite(CHIPSELECT, LOW); //enable comm with SPI device
  spi_transfer(0x23);  // set address width to 5 bytes (default, not really needed)
  spi_transfer(0x03);
  digitalWrite(CHIPSELECT, HIGH); //disable SPI comm with device

  digitalWrite(CHIPSELECT, LOW); //enable comm with SPI device
  spi_transfer(0x26);  //air data rate 1 Mbit, 0dBm, setup LNA
  spi_transfer(0x07);
  digitalWrite(CHIPSELECT, HIGH); //disable comm with SPI device
  
  digitalWrite(CHIPSELECT, LOW); //enable comm with SPI device
  spi_transfer(0x31);  // 4 byte receive payload
  spi_transfer(0x04);
  digitalWrite(CHIPSELECT, HIGH); //disable comm with SPI device
  
  digitalWrite(CHIPSELECT, LOW); //enable comm with SPI device
  spi_transfer(0x25);  // rf channel 2 (default, not really needed)
  spi_transfer(0x02);
  digitalWrite(CHIPSELECT, HIGH); //disable comm with SPI device
  
  digitalWrite(CHIPSELECT, LOW); //enable comm with SPI device
  spi_transfer(0x2a);  //set RX pipe 0 address
  spi_transfer(0xe7);
  spi_transfer(0xe7);
  spi_transfer(0xe7);
  spi_transfer(0xe7);
  digitalWrite(CHIPSELECT, HIGH); //disable comm with SPI device
  
  digitalWrite(CHIPSELECT, LOW); //enable comm with SPI device
  spi_transfer(0x20);  // RX interrupt, power up, be a receiver
  spi_transfer(0x3b);
  digitalWrite(CHIPSELECT, HIGH); //disable comm with SPI device

  Serial.println("Done setting up.");
  digitalWrite(NFR_CE, HIGH); //receiver enable the nRF2401 

}

// main arduino program loop

void loop()
{
  Serial.println("Startup up communications with nRF2401.");
  Serial.println("Waiting for message from Nordic Key FOB.");
  
  // loop forever
  while(1)
  {
    digitalWrite(CHIPSELECT, LOW); //enable comm with SPI device 
    incoming = spi_transfer(0xff); // get nRF2401 status register contents
    digitalWrite(CHIPSELECT, HIGH); //disable comm with SPI device
    // transmission received from FOB
    if (incoming & 0x40)
      {

        // get data from nRF2401
        digitalWrite(NFR_CE, LOW); //disable receiver in the nRF2401 
        digitalWrite(CHIPSELECT, LOW); //enable comm with SPI device 
        spi_transfer(0x61);
        data_array[0] = spi_transfer(0xff);
        data_array[1] = spi_transfer(0xff);        
        data_array[2] = spi_transfer(0xff);
        data_array[3] = spi_transfer(0xff);
        digitalWrite(CHIPSELECT, HIGH); //disable comm with SPI device
 
        digitalWrite(CHIPSELECT, LOW); //enable comm with SPI device 
        spi_transfer(0xe2);  // flush RX FIFO
        digitalWrite(CHIPSELECT, HIGH); //disable comm with SPI device

        digitalWrite(CHIPSELECT, LOW); //enable comm with SPI device 
        spi_transfer(0x27);  // clear RF FIFO interrupt
        spi_transfer(0x40);
        digitalWrite(CHIPSELECT, HIGH); //disable comm with SPI device
        digitalWrite(NFR_CE, HIGH); //receiver enable the nRF2401 
                
        // figure out which key on FOB was pressed
        
        switch( data_array[0] )
        {
          case 0x17: Serial.print("Left button  "); break;
          case 0x1e: Serial.print("Bottom button"); break;
          case 0x1b: Serial.print("Right button "); break;
          case 0x1d: Serial.print("Top button   "); break;
          case 0x0f: Serial.print("Center button"); break;
          default: Serial.print(  "No button!   "); break;
        }
        // display the total number of times that a button had been pressed on the FOB
        // since battery in FOB replaced
        button_presses = (data_array[1] << 8) + data_array[2];
        Serial.print(" pressed ");
        Serial.print( button_presses, DEC );
        Serial.println(" times.");

        // wait a bit before checking for another key press packet, may need some adjusting.       
        delay(10);
      }
  }
}