GSD to drive a Weeder I/O WTDIO-M - Revision history

Mstovenour: Added to Category: Programmer's Guide

2007-08-11T14:35:30Z

Added to Category: Programmer's Guide

←Older revision		Revision as of 14:35, 11 August 2007
Line 1:		Line 1:
			[[Category: Programmer's Guide]]

	== General notes ==		== General notes ==

Juliet at 13:31, 16 March 2007

2007-03-16T13:31:31Z

Wikiadmin: /* How to talk to the board */

2006-06-17T13:52:53Z

How to talk to the board

←Older revision		Revision as of 13:52, 17 June 2006
Line 16:		Line 16:
	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 we want to control), and to define in the parent device some logic (Ruby code) to handle the commands that suit our needs.		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 we want to control), and to define in the parent device some logic (Ruby code) to handle the commands that suit our needs.

Wikiadmin: /* A (very) simple example */

2006-06-17T13:50:38Z

A (very) simple example

←Older revision		Revision as of 13:50, 17 June 2006
Line 85:		Line 85:
	end		end
	if id=="3"		if id=="3"
	conn_.Send("ALC\r")#send string to set Low the B channel of A board		conn_.Send("ALC\r")#send string to set Low the C channel of A board
	end		end
	end		end

Wikiadmin: /* A (very) simple example */

2006-06-17T13:50:06Z

A (very) simple example

←Older revision		Revision as of 13:50, 17 June 2006
Line 24:		Line 24:

	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 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:		Let's configure it with proper parameters:

Line 33:		Line 35:
	''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 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.		Then we 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)''.		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.		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		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 Pluto 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).
Line 63:		Line 65:

	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 77:		Line 79:
	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 B channel of A board
	end		end
	end		end

Wikiadmin: /* How to talk to the board */

2006-06-17T13:28:11Z

How to talk to the board

←Older revision		Revision as of 13:28, 17 June 2006
Line 11:		Line 11:
	== 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:
Line 18:		Line 18:
	'''ModuleAddress-Command-OptionalParameters'''		'''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.		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 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 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.		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 ==		== A (very) simple example ==

Wikiadmin: /* A (very) simple example */

2006-06-17T13:12:44Z

A (very) simple example

←Older revision		Revision as of 13:12, 17 June 2006
Line 59:		Line 59:
	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 (Pluto Admin - Wizard->Devices ->Generic Serial Devices->Ruby Source Code)

Wikiadmin: /* A (very) simple example */

2006-06-17T12:00:20Z

A (very) simple example

←Older revision		Revision as of 12:00, 17 June 2006
Line 101:		Line 101:
	It is a matter of parsing the received strings and interact with proper Pluto variables or talking directly to DCE router.		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.		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.

Wikiadmin: /* A (very) simple example */

2006-06-17T11:59:36Z

A (very) simple example

←Older revision		Revision as of 11:59, 17 June 2006
Line 97:		Line 97:
	This basically receives the output from the serial device and prints it into the log.		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 ~~that i~~ do), i.e ''Process IDLE'' and ''Process Incoming Data''.		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.		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.		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.		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.

Wikiadmin: /* A (very) simple example */

2006-06-17T11:58:00Z

A (very) simple example

←Older revision		Revision as of 11:58, 17 June 2006
Line 45:		Line 45:
	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:

←Older revision		Revision as of 13:31, 16 March 2007
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 ==		== 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 18:		Line 18:
	'''ModuleAddress-Command-ChannelAddress-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 we want to control), and to define in the parent device some logic (Ruby code) to handle the commands that suit our needs.		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 ~~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.		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 ==
Line 25:		Line 25:
	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 33:		Line 33:
	''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 we 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 following.		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 ~~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'll find the ruby code I use form my own board. 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.
Line 62:		Line 62:
	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.		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
Line 89:		Line 89:
	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 two simple lines in the ''Process Incoming Data'' section:		To have some feedback from your serial device, you may add two simple lines in the ''Process Incoming Data'' section:
Line 99:		Line 99:

	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''.		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.		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 ~~Pluto~~ variables or talking directly to DCE router.		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.		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.