How to add your own GSD device - Revision history

Mcefan at 02:03, 20 October 2012

2012-10-20T02:03:14Z

←Older revision		Revision as of 02:03, 20 October 2012
Line 1:		Line 1:
	[[Category: Programmer's Guide]]		[[Category: Programmer's Guide]]
	[[Category: Serial]]		[[Category: Serial]]
	~~[[Category: Tutorials]]~~
	[[Category: GSD]]		[[Category: GSD]]

JoakimL at 13:01, 16 February 2011

2011-02-16T13:01:22Z

←Older revision		Revision as of 13:01, 16 February 2011
Line 195:		Line 195:
	The procedure for this is as follows:		The procedure for this is as follows:
	* Do an sqlCVS update from the web-admin to ensure that your database is up-to-date (Advanced --> sqlCVS --> Update, select all sections)		* Do an sqlCVS update from the web-admin to ensure that your database is up-to-date (Advanced --> sqlCVS --> Update, select all sections)
			** If it just returns without any reply, you're most likelly being tricked by your browser's pop-up blocker.
	* Create a Trac ticked describing your device (http://svn.linuxmce.org)		* Create a Trac ticked describing your device (http://svn.linuxmce.org)
	* Do a check-in of your changes: Use the sqlCVS diff function (Advanced --> sqlCVS --> Diff) to determine the updates to the "dce" and "ir" sections of your database and check them in anonymously. The comment of your check-in should mention the Trac ticket number. You should only check in the items related to your device template.		* Do a check-in of your changes: Use the sqlCVS diff function (Advanced --> sqlCVS --> Diff) to determine the updates to the "dce" and "ir" sections of your database and check them in anonymously. The comment of your check-in should mention the Trac ticket number. You should only check in the items related to your device template.

Sambuca at 10:25, 15 May 2010

2010-05-15T10:25:13Z

←Older revision		Revision as of 10:25, 15 May 2010
Line 9:		Line 9:
	Note, however, that a GSD device driver is more limited than a compiled driver. The GSD driver allows only a single communication channel with the device (RS232, serial USB or a TCP connection across a network).		Note, however, that a GSD device driver is more limited than a compiled driver. The GSD driver allows only a single communication channel with the device (RS232, serial USB or a TCP connection across a network).
	If your device has other communication channels (an UDP connection for example), you will have to write a driver in another language and compile it.		If your device has other communication channels (an UDP connection for example), you will have to write a driver in another language and compile it.

			It is also possible to use a GSD device to send DCE commands to other devices. See for instance the Toshiba RAS series template, which acts as a sort of message translator, translating DCE thermostat command to IR commands sent through a IR transmitter.

	== How to add your own GSD device ==		== How to add your own GSD device ==
Line 18:		Line 20:
	* Panasonic IP camera: A simple driver that enables the retrieval of video frames from this network enabled camera		* Panasonic IP camera: A simple driver that enables the retrieval of video frames from this network enabled camera
	* Proliphix NT series thermostat: A more elaborate driver for a network enabled thermostat. This driver also sends events to the LMCE system in case, for example, the ambient temperature changes.		* Proliphix NT series thermostat: A more elaborate driver for a network enabled thermostat. This driver also sends events to the LMCE system in case, for example, the ambient temperature changes.
			* Toshiba RAS series air condition: Another kind of GSD device, just receiving and sending DCE commands

	=== Creating a new GSD device ===		=== Creating a new GSD device ===
Line 26:		Line 29:
	Be sure that you have installed GSD package -		Be sure that you have installed GSD package -
	<pre>dpkg -l 'pluto-generic-serial-device'</pre>		<pre>dpkg -l 'pluto-generic-serial-device'</pre>
	(it should be there).		(it should be there). This shouldn't normally be necessary as LMCE should automatically install the package when you have added such a device.

	==== Create a device template ====		==== Create a device template ====
Line 138:		Line 141:

	Note that the same piece of code can be used to send commands instead of events. The only changes are that the message type will be 1 (command) instead of 2 (event), and that the destination will probably differ from the event handler device -1001.		Note that the same piece of code can be used to send commands instead of events. The only changes are that the message type will be 1 (command) instead of 2 (event), and that the destination will probably differ from the event handler device -1001.

			Note that the GSD framework currently does not allow you to get any return(out) parameters from commands.

	== Troubleshooting ==		== Troubleshooting ==
Line 191:		Line 196:
	* Do an sqlCVS update from the web-admin to ensure that your database is up-to-date (Advanced --> sqlCVS --> Update, select all sections)		* Do an sqlCVS update from the web-admin to ensure that your database is up-to-date (Advanced --> sqlCVS --> Update, select all sections)
	* Create a Trac ticked describing your device (http://svn.linuxmce.org)		* Create a Trac ticked describing your device (http://svn.linuxmce.org)
	* Do a check-in of your changes: Use the sqlCVS diff function (Advanced --> sqlCVS --> Diff) to determine the updates to the "dce" and "ir" sections of your database and check them in anonymously. The comment of your check-in should mention the Trac ticket number.		* Do a check-in of your changes: Use the sqlCVS diff function (Advanced --> sqlCVS --> Diff) to determine the updates to the "dce" and "ir" sections of your database and check them in anonymously. The comment of your check-in should mention the Trac ticket number. You should only check in the items related to your device template.
	* The developers will verify this and check the driver into the database		* The developers will verify this and check the driver into the database

Mhorst at 17:31, 11 April 2010

2010-04-11T17:31:29Z

←Older revision		Revision as of 17:31, 11 April 2010
Line 184:		Line 184:
	</pre>		</pre>
	This should start your device. If not, the output of that script is a good place to look for further clues.		This should start your device. If not, the output of that script is a good place to look for further clues.

			== Sharing your driver ==

			Once your driver is working properly, you can share it with the rest of the LinuxMCE community.
			The procedure for this is as follows:
			* Do an sqlCVS update from the web-admin to ensure that your database is up-to-date (Advanced --> sqlCVS --> Update, select all sections)
			* Create a Trac ticked describing your device (http://svn.linuxmce.org)
			* Do a check-in of your changes: Use the sqlCVS diff function (Advanced --> sqlCVS --> Diff) to determine the updates to the "dce" and "ir" sections of your database and check them in anonymously. The comment of your check-in should mention the Trac ticket number.
			* The developers will verify this and check the driver into the database

	== See also ==		== See also ==

Mhorst: /* Sending an event */

2010-04-11T14:55:21Z

Sending an event

←Older revision		Revision as of 14:55, 11 April 2010
Line 129:		Line 129:
	</pre>		</pre>

	This will send the command from your device (~~<pre>~~device_.devid_~~</pre>~~) to the LinuxMCE event handler (~~<pre>~~-1001~~</pre>~~), identifying it as a priority ~~<pre>~~1~~</pre>~~ message, of the event type (~~<pre>~~2~~</pre>~~).		This will send the command from your device (device_.devid_) to the LinuxMCE event handler (-1001), identifying it as a priority 1 message, of the event type (2).
	Furthermore the event has id ~~<pre>~~25~~</pre>~~, which means it's a "Temperature Changed" event (the device template page shows the ids of the events you have added to the device).		Furthermore the event has id 25, which means it's a "Temperature Changed" event (the device template page shows the ids of the events you have added to the device).

	Additional parameters of the event can be set by using the ~~<pre>~~cmd.params_~~</pre>~~ mapping. The device template page has an edit button for each event that enables you to see the parameters associated with that event, including a description of its use.		Additional parameters of the event can be set by using the cmd.params_ mapping. The device template page has an edit button for each event that enables you to see the parameters associated with that event, including a description of its use.
	In our example it shows that the parameter with index 30 is the current ambient temperature in degrees Celcius.		In our example it shows that the parameter with index 30 is the current ambient temperature in degrees Celcius.

	After the ~~<pre>~~cmd~~</pre>~~ object has been initialized it is send to the LinuxMCE system using the ~~<pre>~~SendCommand~~</pre>~~ function.		After the cmd object has been initialized it is send to the LinuxMCE system using the SendCommand function.

	Note that the same piece of code can be used to send commands instead of events. The only changes are that the message type will be 1 (command) instead of 2 (event), and that the destination will probably differ from the event handler device -1001.		Note that the same piece of code can be used to send commands instead of events. The only changes are that the message type will be 1 (command) instead of 2 (event), and that the destination will probably differ from the event handler device -1001.

Mhorst: Updated with my experiences of writing my first GSD driver

2010-04-11T14:25:23Z

Updated with my experiences of writing my first GSD driver

Show changes

Ray N at 01:13, 11 August 2009

2009-08-11T01:13:56Z

←Older revision		Revision as of 01:13, 11 August 2009
Line 1:		Line 1:
	[[Category: Programmer's Guide]]		[[Category: Programmer's Guide]]
	[[Category: Serial]]		[[Category: Serial]]
	[[Category: ~~LinuxMCE_Devices~~]]		[[Category: Tutorials]]
	[[Category: GSD]]		[[Category: GSD]]

Ddamron at 00:42, 27 February 2009

2009-02-27T00:42:30Z

←Older revision		Revision as of 00:42, 27 February 2009
Line 69:		Line 69:
	<li>		<li>
	NOTE: From trial and error, I have come to the assumption that ON/OFF and SETLEVEL, internally, have seperate values. Be careful as you can have a device that is OFF with a setlevel of 100%. This results in a pretty UGLY message when to attempt the following: Use cmd[184]=100 to turn a device ON. (but don't actually send a cmd[192].. when you attempt to turn the device OFF, you'll get an ugly message in the GSD device saying that the 'CMD[193] won't be processed because it is useless'. (I'm paraphrasing.. you get the idea...) What makes this worse, is when you use an orbiter to turn a device on, it will send you a cmd[184], not a cmd[192]. You will need to watch for this and send a cmd[192] as needed.		NOTE: From trial and error, I have come to the assumption that ON/OFF and SETLEVEL, internally, have seperate values. Be careful as you can have a device that is OFF with a setlevel of 100%. This results in a pretty UGLY message when to attempt the following: Use cmd[184]=100 to turn a device ON. (but don't actually send a cmd[192].. when you attempt to turn the device OFF, you'll get an ugly message in the GSD device saying that the 'CMD[193] won't be processed because it is useless'. (I'm paraphrasing.. you get the idea...) What makes this worse, is when you use an orbiter to turn a device on, it will send you a cmd[184], not a cmd[192]. You will need to watch for this and send a cmd[192] as needed.
			</li>
			<li>
			NOTE FOR ABOVE: I have found a way to force the command through. a bit of history first:
			The reason we get the infamous 'won't be processed because it is useless' is because DCE has to deal with NON Discrete codes.
			for instance: a device that has a power toggle. IF we turn it on, it turns on.
			Now, if we turn it ON again, DCE thinks it's on and because it's a toggle, it won't send the command. That is why we get this message.
			I dug pretty deep to find this next piece: params[120]=1
			this parameter, when set inside a command, will FORCE DCERouter to send the command regardless of what it thinks the state is.
			Hope this helps other GSD programmers. DDamron
	</li>		</li>

Aaron.b: /* Viewing the logs */

2008-08-14T17:20:28Z

Viewing the logs

←Older revision		Revision as of 17:20, 14 August 2008
Line 105:		Line 105:

	cd /var/log/pluto		cd /var/log/pluto

	ls		ls

Aaron.b: /* Viewing the logs */

2008-08-14T17:19:47Z

Viewing the logs

←Older revision		Revision as of 17:19, 14 August 2008
Line 98:		Line 98:

	Then move to the start of the line that starts with LogLevels, press 'i' for Insert mode in vim, type a # character, then press [ESC]:wq		Then move to the start of the line that starts with LogLevels, press 'i' for Insert mode in vim, type a # character, then press [ESC]:wq
	# at the start of a line means it's commented out, or ignored.		The # at the start of a line means it's commented out, or ignored.

	now do a reload router. You can do this from the console with: /usr/pluto/bin/MessageSend dcerouter 0 -1000 7 1		now do a reload router. You can do this from the console with: /usr/pluto/bin/MessageSend dcerouter 0 -1000 7 1