GSD to drive a Weeder I/O WTDIO-M

General notes

Weeder boards are very nice and inexpensive pieces of hardware that fit well enough to many situations related to home automation.

The model I'm referring to is WTDIO-M, that is a 14 channel digital I/O board that connects to pc via RS232 and is also stackable to a max of 32 modules (that means 448 I/O channels, quite enough ...). Further details can be found here -> http://www.weedtech.com/wtdio-m.html

Usually they require some extra hardware (you cannot drive directly any relays, so some transistor are needed in between) but it's something that does not require a rocket scientist to be done.

How to talk to the board

The board has its own communication protocol, that allow you to write/read a specific channel of a specific module by sending the appropriate string to the serial port and by reading back the answer. The protocol takes care also of collision on the common media (serial line) so you don't have to bother with anything else.

The command string usually is something like this:

ModuleAddress-Command-ChannelAddress-OptionalParameters

So from a LinuxMCE point of view it is a matter of defining a GSD device with some child devices attached (each child device corresponding to a board channel we want to control), and to define in the parent device some logic (Ruby code) to handle the commands that suit our needs. It is not necessary to handle Ruby code in each and every child device, as LinuxMCE allows to pass the command received from a child device to its parent, that is in charge to process it.

A (very) simple example

In this example I will explain how to use this board to switch on/off some channel (corresponding to some lights/simple appliances).

First of all let's create a GSD device in LinuxMCE Admin to your core/hybrid or to the MD where the board is physically connected. Say that we name it "Weeder Board".

Let's configure it with proper parameters:

COM Port BaudRate: B9600 (write it like this, "B9600", I lost days entering simply "9600" and having it not working ...)

COM Port on PC: /dev/ttyS1 (or whatever applies to your box)

COM Port ParityBit/Stop: N81 (that stands for No parity, 8 bits, 1 stop bit, as said before enter it exactly like this if you want it working)

Then we can add some child devices. Go to LinuxMCE Admin - Advanced->Configuration->Devices, select the newly added GSD device (Weeder Board) and add some new child devices, naming them according to your needs. On each child device record don't forget to fill in the field #12 Port/Channel Number(string). This field allows to establish the correspondence between child device and board channel. It will be more clear in the following.

Then we are ready to add some Ruby code to manage our channels. To do it we can press the button "Ruby Source Code" that we can find in LinuxMCE Admin - Wizard->Devices ->Generic Serial Devices

Following you'll find the ruby code I use form my own board. It's very simple and rude, but it's working.

Basically it processes all command issued to child devices (that in my case are related to channels of the board, i.e. lights/appliance). If command (cmd.id) equals to 192 (means "ON") then it checks from wich child it is coming from (device_.childdevices_[cmd.devidto_].devdata_[12]), and according to this it decides which is the proper command string to send to GSD (Weeder Board, in this example).

Say that I press "ON" button on Orbiter (button that actually is a light scenario that corresponds to channel 1 of my Weeder Board). The proper command string to send is:

 AHA

that stands for A module, High level, A channel. Don't forget to add a "\r" to properly close the string. In case I press "ON" for channel 3, the string is

 AHC

The same story applies when pressing "OFF", that corresponds to a cmd.id = 193

The question now is: how can I tell that a specific child device corresponds to a specific board channel?

As I mentioned above, this is done by the value entered in the field #12 Port/Channel Number(string) of each child device record, that is accessed in Ruby by reading the variable device_.childdevices_[cmd.devidto_].devdata_[12]. With this value (treated as a string) you can decide what to send to what channel of your Weeder Board or in general to your Generic Serial Devices that can drive multiple channels/device.

This is the code that I entered in the Process Receive Command For Child section of the Ruby code interface (LinuxMCE Admin - Wizard->Devices ->Generic Serial Devices->Ruby Source Code)

 if cmd.id_ == 192 #192 is ON 
   id=device_.childdevices_[cmd.devidto_].devdata_[12] #get child device number
   if id=="1"
    conn_.Send("AHA\r")#send string to set High the A channel of A board
   end 
   if id=="2"
    conn_.Send("AHB\r")#send string to set High the B channel of A board
   end 
   if id=="3"
    conn_.Send("AHC\r")#send string to set High the C channel of A board
   end 
 end
 if cmd.id_ == 193 #193 is OFF
   id=device_.childdevices_[cmd.devidto_].devdata_[12]
   if id=="1"
    conn_.Send("ALA\r")#send string to set Low the A channel of A board
   end
   if id=="2"
    conn_.Send("ALB\r")#send string to set Low the B channel of A board
   end
   if id=="3"
    conn_.Send("ALC\r")#send string to set Low the C channel of A board
   end
 end

You can monitor the messages to GSD by looking at the corresponding log file in LinuxMCE, o by using the "Follow Log" option in the LinuxMCE Admin - Advanced->Configuration->Devices->Weeder Board (or whatever name you gave to your device).

To have some feedback from your serial device, you may add two simple lines in the Process Incoming Data section:

 buffer = conn_.Recv(100,500);
 print buffer;

This basically receives the output from the serial device and prints it into the log.

There are many other section in the Ruby code interface that may be interesting to use (or use better than I do), i.e Process IDLE and Process Incoming Data. The first should deal with some polling to perform when no commands are issued, the second should be used to give some decent feedback from serial device to the rest of LinuxMCE system. It is a matter of parsing the received strings and interact with proper LinuxMCE variables or talking directly to DCE router.

No clear idea of the possible use of the remaining section, but I'm sure that someone will add interesting notes to help us to find it out.