View source for GSD to drive a Weeder I/O WTDIO-M

<table width="100%"> <tr><td bgcolor="#FFCFCF">This page was written by Pluto and imported with their permission when LinuxMCE branched off in February, 2007.  In general any information should apply to LinuxMCE.  However, this page should be edited to reflect changes to LinuxMCE and remove old references to Pluto.</td></tr> </table>== 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 seral port and by reading back the answer.
The protocol takes care also of collision on the common media (seral line) so you don't have to bother with anything else.

The command string usually is something like this: 

'''ModuleAddress-Command-OptionalParameters'''

So from a Pluto 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 you 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 Rouby code in each and every child device, as Pluto 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 PlutoAdmin to your core/hybrid or to the MD where the board is phisically 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 exaclty like this if you want it working)

Then you can add some child devices. Go to Pluto 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 allow to establish the correspondence between child device and board channel. It will be more clear in the following.

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

Following you find the ruby code. 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, '''H'''igh 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 walue entered in the field ''#12 Port/Channel Number(string)'' of each child device record, that is accessed 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 (Pluto Admin - Wizard->Devices ->Generic Serial Devices->Ruby Source Code)

  if cmd.id_ == 192 #192 is ON 
    id=device_.childdevices_[cmd.devidto_].devdata_[12]
    if id=="1"
     conn_.Send("AHA\r")
    end 
    if id=="2"
     conn_.Send("AHB\r")
    end 
    if id=="3"
     conn_.Send("AHC\r")
    end 
  end
  if cmd.id_ == 193 #193 is OFF
    id=device_.childdevices_[cmd.devidto_].devdata_[12]
    if id=="1"
     conn_.Send("ALA\r")
    end
    if id=="2"
     conn_.Send("ALB\r")
    end
    if id=="3"
     conn_.Send("ALC\r")
    end
  end

You can monitor the messages to GSD by looking at the corresponding log file in Pluto, o by using the  "Follow Log" option in the Pluto 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 Pluto system.
It is a matter of parsing the received strings and interact with proper Pluto 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.