Difference between revisions of "GSD to drive a Weeder I/O WTDIO-M"

From LinuxMCE
Jump to: navigation, search
m (Added to Category: Programmer's Guide)
 
(13 intermediate revisions by 2 users not shown)
Line 1: Line 1:
<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 ==
+
[[Category: Programmer's Guide]]
 +
 
 +
== General notes ==
  
 
Weeder boards are very nice and inexpensive pieces of hardware that fit well enough to many situations related to home automation.
 
Weeder boards are very nice and inexpensive pieces of hardware that fit well enough to many situations related to home automation.
Line 11: Line 13:
 
== How to talk to the board ==
 
== 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 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 (seral line) so you don't have to bother with anything else.
+
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:  
 
The command string usually is something like this:  
  
'''ModuleAddress-Command-OptionalParameters'''
+
'''ModuleAddress-Command-ChannelAddress-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.
+
  
 +
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 ==
 
== 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).
 
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".
+
 
 +
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:
 
Let's configure it with proper parameters:
  
Line 32: Line 35:
 
''COM Port on PC:'' /dev/ttyS1 (or whatever applies to your box)
 
''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)
+
''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 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.
+
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)''.
 
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 next section.
+
This field allows 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
+
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 find the ruby code. It's very simple and rude, but it's working.
+
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).
 
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).
 
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 lignt scenario that corresponds to channel 1 of my Weeder Board).
+
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:
 
The proper command string to send is:
  
Line 59: Line 62:
 
The question now is: how can I tell that a specific child device corresponds to a specific board channel?
 
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.
+
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 (Pluto Admin - Wizard->Devices ->Generic Serial Devices->Ruby Source Code)
+
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  
 
   if cmd.id_ == 192 #192 is ON  
     id=device_.childdevices_[cmd.devidto_].devdata_[12]
+
     id=device_.childdevices_[cmd.devidto_].devdata_[12] #get child device number
 
     if id=="1"
 
     if id=="1"
     conn_.Send("AHA\r")
+
     conn_.Send("AHA\r")#send string to set High the A channel of A board
 
     end  
 
     end  
 
     if id=="2"
 
     if id=="2"
     conn_.Send("AHB\r")
+
     conn_.Send("AHB\r")#send string to set High the B channel of A board
 
     end  
 
     end  
 
     if id=="3"
 
     if id=="3"
     conn_.Send("AHC\r")
+
     conn_.Send("AHC\r")#send string to set High the C channel of A board
 
     end  
 
     end  
 
   end
 
   end
Line 78: Line 81:
 
     id=device_.childdevices_[cmd.devidto_].devdata_[12]
 
     id=device_.childdevices_[cmd.devidto_].devdata_[12]
 
     if id=="1"
 
     if id=="1"
     conn_.Send("ALA\r")
+
     conn_.Send("ALA\r")#send string to set Low the A channel of A board
 
     end
 
     end
 
     if id=="2"
 
     if id=="2"
     conn_.Send("ALB\r")
+
     conn_.Send("ALB\r")#send string to set Low the B channel of A board
 
     end
 
     end
 
     if id=="3"
 
     if id=="3"
     conn_.Send("ALC\r")
+
     conn_.Send("ALC\r")#send string to set Low the C channel of A board
 
     end
 
     end
 
   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).
+
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
+
 
 +
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.

Latest revision as of 14:35, 11 August 2007


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.