LinuxMCE - User contributions [en]

DCERouter Programmer's Guide

2008-04-12T10:08:29Z

AVJohn:

[[Category: Programmer's Guide]]

'''[[Developers Guide]] is the most recent information regarding architecure and getting started with development.'''

DCE Router is actually a very simple program, and consists of only 1 class: DCERouter. This class reads in the configuration for the installation from the [[pluto_main database]] to open a socket for incoming connections. When devices connect to it, DCE Router gives them a copy of their own configuration data, as well as a list of all the other devices in the installation. Before accepting incoming connections, it first loads all the plug-ins into it's own name space. If your device is loaded as a Plug-in, rather than the main() function being called, the Register() function will be called, and you will be passed a pointer to the DCERouter class.
You use the pointer to the DCERouter class to do primarily 2 things: First, you can [[Message Interceptors]]. This means that you want your plug-in to get any messages that meet a certain criteria before they are forwarded to the actual destination. You also can get a list of the other loaded plug-ins, and pointers to their primary class, derived from Command_Impl (for command implementation). In this way plug-ins can call each other's member functions directly and implement their own plug-in architecture. For example, the **Datagrid plug-in** receives any messages related to generating data-grids. Orbiters generate data-grid requests when they want to display data-grids with dynamic information, such as a list of devices, or what TV shows are playing. The Datagrid Plug-in exposes its own plug-in architecture allowing other plug-ins to **register with it** to handle certain types of data-grids. The Datagrid plug-in is, therefore, a general purpose "router" like DCERouter is, and it hands off all data-grid processing to another plug-in that actually generates the data-grids. This way the building of the data-grids is logically handled in the appropriate plug-in. The Plug-in that is responsible for TV viewing will be the one that registers with the Datagrid Plug-in to build tv-related data grids. The Media Plug-in also implements its own plug-in architecture for media devices.
To run DCERouter, you only need to be sure it has the database connection parameters so it has access to the [[pluto_main database]] or in the **pluto.conf** file.

Talk:Serial Hack

2007-10-19T21:41:19Z

AVJohn:

When you figure out a better way, edit the article. Until then this is just discussion. [[User:Trout|Trout]] 08:06, 21 September 2007 (MST)

:When you have something usefull to add for a change, edit the article. Otherwise, quit pestering the people that do --[[User:Zaerc|Zaerc]] 12:59, 21 September 2007 (MST)

I am at a loss to understand this battle. The original commit was another way to accomplish the same thing. There are a lot pages on this site that have very similar issues. What is the harm in giving people more than one option even if that option is one in the same. If nothing else it offers all of us an opportunity to learn something different. The second option (perl) is another example. Personally I feel both should be left on the page and just remove the editorial commitments as these are truly the things that belong in discussions.

*[http://en.wikipedia.org/wiki/Wikipedia:Talk_page_guidelines#Good_practice Good Wiki Practices]
*[http://en.wikipedia.org/wiki/Wikipedia:Talk_page_guidelines#Behavior_that_is_unacceptable Behavior that is unacceptable]
--[[User:Rwilson131|Rwilson131]] 09:27, 23 September 2007 (MST)

I'm sure AVJohn is very happy with you pissing all over his page just to prove a point Trout. And how nice of you to make it personal. So thanks for the lessons on properly maintaining a wiki, you're a real champ. --[[User:Zaerc|Zaerc]] 02:50, 24 September 2007 (MST)

:Keep the articles clean and use the discussion-pages for...ahh, discussions! And when you reply, please indent, it's so much easier to follow a discussion that way. --[[User:Samme|Samme]] 02:58, 24 September 2007 (MST)

:Zaerc, you keep making it more clear that you don't understand how a wiki works. First of all, I tried to be nice by just moving the discussion piece of the page to the discussion area. This was not acceptable to you, and you moved it back with a nasty comment. I tried again with the same result, and a worse comment from you. So, IMO you are the one who made it personal. Second, when you sait "... all over his page", you are completely wrong about page ownership. The page belongs to the wiki and it's not personally AVJohns, this misunderstanding of yours is exactly what caused you to be upset to see "your text" moved to the discussion page. Having the discussion moved to it's correct place is not something to take personally. BTW: you're welcome for the wiki lessons. [[User:Trout|Trout]] 04:50, 24 September 2007 (MST)

::So I'm the one putting a personal rant aimed at you on that page? Have some respect for the people who actually contribute, because it seems more like all the pages here belong to you. --[[User:Zaerc|Zaerc]] 07:40, 24 September 2007 (MST)

:::Yes, this is an insult to me "please don't edit pages unless you actually have something to add". I feel that I am adding clarity when I move your comments to the discussion page. You are personally attacking me when you imply I am not adding anything. "go find something usefull to do, instead of pestering people that actually add information" Again another insult, implying that I have nothing better to do than mess with your addition for no purpose. Also discounting my contributions as though they are somehow less important than yours. I don't think that all the pages belong to me and I have stated so. I am sorry if you perceived that, it was not my intent.
:::I really think that the page is better served without different options of editing a file. The page is about detecting serial ports, not how to create a text file. It should be enough to say "create a file like this ..." IMO this would serve the users best. [[User:Trout|Trout]] 09:07, 24 September 2007 (MST)

::'''Hey hey hey!''' No you have to stop, both of you, we're in this together, work with each other, not against each other, now we end this discussion and continue the work with the wiki - '''and''' from now on discussions goes on to the pages that are designated for discussions so we can stick to the facts in the articles. Do we have a agreement? --[[User:Samme|Samme]] 09:49, 24 September 2007 (MST)

:::Samme, Of course I'm in agreement, this was my point from the beginning. [[User:Trout|Trout]] 10:57, 24 September 2007 (MST)

::::You guys make me sick with all your hypocritical bullshit. And then that pathetic excuse that this is to "serve" the users, seems pretty obvious this is '''not''' done in ''their'' best interest. But I guess coming forward to say what it is really about would actually take a pair. --[[User:Zaerc|Zaerc]] 11:56, 25 September 2007 (MST)

Hi, i took the liberty to add a new page to the wiki [[Editing_Text]] where I put the tricks the two of you offered.

And I linked to the new page from the appropriate passage within the article...

I hope, this will end the fight... And I hope I will read a lot from both of you on this wiki in the future.

Best Regards, [[User:Chewi|Chewi]]

== Comment about better solutions by AVJohn ==

I would suggest, that we leave the comment about finding better versions in there.
The reason is that the article describes a hack and AVJohn says in his article that the new script is inferior to the original script.
So the request for other/better solutions is an important notice to

A) let people know it is only a hack

B) remind others that have acomplished it a different way to add their version

C) make other Developers make a "more undirty" workaround

D) remind actual LMCE-Developers (no offence to AVJohn) to provide an improvement/update that makes the hack unnessasary.

So I endorse to go back to the previous version for those reasons. Feel free to add your oppinions.

Best regards, --[[User:Chewi|Chewi]] 07:00, 27 September 2007 (MST)

The discussion belongs here IMO. Otherwise it grows out of control into a forum. Not that there's anything wrong with the discussion, but it just doesn't belong on the main page. Think about it from the point of view of someone who just wants to know the best way right now. They don't want to wade through a lot of discussion text to get the answer.

A) they should know it's a hack by the title
B) someone who's already accomplished it probably either 1) wants to edit the wiki with their knowledge 2) is just checking out how wiki recommends it. The mere fact that it's a wiki is enough encouragement IMO.
C) okay, but they don't want to wade through a pile of blogs to see the best result. They only would want to see the best result (the wiki page) and compare it to what they have in mind.
D) same as C)
[[User:Trout|Trout]] 07:43, 27 September 2007 (MST)

:''(Never said anything on the main-page ???)'' Basically, you're right with all of your points. But I still think that the extra-encouragement here would be a good thing, as a wiki-page without a comments-section feels like a final statement and feels like allowing editing only by "the inner circle", which is not the case here. This needs the extra-input. This is at least how I feel about wikis. Therefore, I stay with my recommendation. Regards--[[User:Chewi|Chewi]] 08:06, 27 September 2007 (MST)

::''(I never said anything about main-page either.)'' I said "main page" e.g. There is a main page for every article (the link is labeled 'article') and there is a discussion for every article. That's what I was referring to. I will try to use 'article' now. You can have your opinion about "the inner circle" concept, but I don't feel that way. Also I believe that others know how to use a wiki and that the expectation is user participation. Also, you havn't said anything about the mess it'll make or how to prevent a flame war on the article instead of where it belongs (the discussion) [[User:Trout|Trout]] 08:23, 27 September 2007 (MST)

:::Ok, that must have been a missunderstanding. Of course I think that discussions about the article itself belong here, just as we are having it now. And I don't want to move that part to the main page. Just for short annotations an area on the mail-article-page ;) is what I prefer. And an area for comments and annotations that does not serve as a forum or discussion-replacement, does not support flame wars. Those can happen everywhere, but I don't see why they should happen here in particular.

:::I'm still not convinced, but it is not up to me. Let's see, if there are additional oppinions on this. Until then, lets leave it as it is right now, without comments. Best regards --[[User:Chewi|Chewi]] 09:48, 27 September 2007 (MST)

== does this fix the "serial hack" ? ==

does this fix the "serial hack" ? [[Blocking Access To Serial Port]] [[User:Trout|Trout]] 12:21, 28 September 2007 (MST)

== Trout: Please stop vandalizing this page ==

Somebody cleaned up the mess you made and now you have to spit in his face by continuing to vandalize the page. Your arguments of percieved problems are insignificant and irrelevant. I don't think this is apropriate behavior for a "wiki admin". Please join in on the forum discussion if you feel this is so important. [http://forum.linuxmce.org/index.php?topic=2593.15]. --[[User:Zaerc|Zaerc]] 04:42, 30 September 2007 (MST)

What specifically are you talking about? I think you are sadly confused. [[User:Trout|Trout]] 10:03, 30 September 2007 (MST)

:I think that becomes pretty clear in the discussion we are having on the forum. You can also check the page history if you have such a short memory. Meanwhile, please don't edit my comments either. --[[User:Zaerc|Zaerc]] 12:11, 30 September 2007 (MST)

And yet you continue to chose vandalism over debate by even removing comments here. Please stop it. --[[User:Zaerc|Zaerc]] 16:31, 30 September 2007 (MST)

You want debate? I have not '''vandalized''' anything. Yet you try to put false comments on the page to make yourself feel superior. The only thing that is clear is that you have a lot of growing up to do. There is no reason for this section on the discussion page or anywhere else, This is more of a discussion between you and me, that doesn't concern anyone else here. If you have a problem with me, I don't really care. I tried numerous times to be kind to you, to no avail. This is a wiki and the content will change whether you like it or not. When you contribute, it becomes the Wiki's text, and doesn't belong to you anymore. The same is true for me and everybody else... and yet you cannot grasp that simple concept. So I recommend that you either contribute in a wiki-community way or not at all. I have nothing against you and I wish you'd accept that your text will change and continue to contribute in spite of it. I'm done having a flame war with you, and I will remove this section of the discussion page soon. [[User:Trout|Trout]] 18:30, 30 September 2007 (MST)

:Announcing your vandalism is not going to help either, so why don't you ''grow up'' and join the rest of the community in discussing this. That you don't care for anyone's opinion but your own needs no further pointing out. --[[User:Zaerc|Zaerc]] 04:10, 1 October 2007 (MST)

::Come on guys, I think we all need to turn the intensity down a notch or two on this one. This has obviously become quite personal. Perhaps the agrieved parties should take a breather from this article for a few days? [[User:Lozzo|Lozzo]] 07:33, 1 October 2007 (MST)

:::I think we already had a breather, with continued vandalism as the result. Please join the rest of the community in discussing these new policies on the forum or stop "enforcing" them. This wiki belongs to the community and not to a few (new) "wiki admins" to do as they please and then make up new policy as they go to justify that. --[[User:Zaerc|Zaerc]] 08:57, 1 October 2007 (MST)

:Somehow you seem to think that there is kindness in your vandalism, and now you would like me to spell it out for you. Okay here we go, this is an [http://wiki.linuxmce.org/index.php?title=Serial_Hack&oldid=5536#Comments addition], now this is vandalism [http://wiki.linuxmce.org/index.php?title=Serial_Hack&oldid=5539#Comments count 1], [http://wiki.linuxmce.org/index.php?title=Serial_Hack&oldid=5566#Comments count 2] and [http://wiki.linuxmce.org/index.php?title=Serial_Hack&oldid=5592#Comments count 3] leading up to the defacement of the page which seems also to be considered vandalism, so that's [http://wiki.linuxmce.org/index.php?title=Serial_Hack&oldid=5606 count 4] (I just wish you would stop being so "nice" to me). Then [[User:Chewi|Chewi]] steps in to intermediate and [http://wiki.linuxmce.org/index.php?title=Serial_Hack&oldid=5833 restores] the page and there you go again, vandalism [http://wiki.linuxmce.org/index.php?title=Serial_Hack&oldid=5838 count 5]. Sparking another debate on the talk page ''afterwards'' in which [[User:Chewi|Chewi]], another contributor, somehow has to convince you again not to take things of the page for no good reason. And now you can't even stop vandalizing my comments on the talk page, or do I need to spell that out too?

:Just to be clear, is this the kind of behavior that you mean by "contribute in a wiki-community way"? And why exactly can't we discuss this on the community forum? --[[User:Zaerc|Zaerc]] 16:09, 1 October 2007 (MST)

Zearc, could you please [http://en.wikipedia.org/wiki/Wikipedia:Assume_good_faith assume good faith] and stop throwing around terms like vandalism? [[User:Lozzo|Lozzo]] 11:03, 3 October 2007 (MST)

:And Trout, goading people [http://wiki.linuxmce.org/index.php?title=Serial_Hack&diff=5606&oldid=5605 like this] should be beneath you. [[User:Lozzo|Lozzo]] 11:06, 3 October 2007 (MST)

:Sure no problem, as soon as the unreasonable vandalism of contributions and comments ("in good faith" or otherwise) stops. And just to point out the obvious, that rant adressed at me was never "in good faith", not even by the widest stretch of imagination. And allow me to quote from the link you gave: ''Bad faith editing can include deliberate disruption just to prove a point, playing games with policies, and vandalism.'' I think we've seen all of those symptoms right here.

:Furthermore I feel that we can really do without this kind of misguided righteousness regardless of the intentions. Even with assuming good faith it seems pretty obvious that this kind of behavior is not appropriate, let alone a basis to lecture other people on how to edit the wiki. --[[User:Zaerc|Zaerc]] 16:38, 3 October 2007 (MST)

== Better Solutions ==

I merely put this page here as an aid to people who were having problems with USB->Serial devices listing incorrectly, and wanted someone better equipped in the ways of bash to come up with an autodetect script for them, or an alternative to using 'tree' as it is an additional dependency that I would like to see removed again.

Also, no offence taken Chewi, I know this is a dirty hack, I needed to get this working for a client of mine, so it had to be done on the quick :P

Anyway, does anyone have any ideas regarding this? --[[User:AVJohn|AVJohn]]

DCE from commandline

2007-09-25T15:35:31Z

AVJohn:

==Sending DCE events from command line==
There is a utility in pluto (/usr/pluto/bin) that allows sending proper DCE message from command line. If you want for instance to trip motion sensors on/off you can achieve this in simple way (ID means ID of particular device that you send event for) :

Event "tripped on"
ID -1000 2 9 25 1

Event "tripped off"
ID -1000 2 9 25 0

Event "temperature changed"
ID -1000 2 25 30 temperature_value

Event "output on"
ID -1000 2 28

Event "output off"
ID -1000 2 29

Event "light on"
ID -1000 2 48 10 1

Event "light off"
ID -1000 2 48 10 0

For instance -

A. tripping security sensor with ID of 195 to ON :
/usr/pluto/bin/MessageSend dcerouter 195 -1000 2 9 25 1

B. play media (/home/public/data/tts/0.wav) on Xine player with ID of 44 :
/usr/pluto/bin/MessageSend localhost 0 44 1 37 29 "" 41 "" 42 "" 59 "/home/public/data/tts/0.wav"

C. report that light with ID of 210 is ON :
/usr/pluto/bin/MessageSend dcerouter 210 -1000 2 48 10 1

==Sending DCE commands from command line==

Change HouseMode command :
I've sniffed DCERouter logs and this is what happens when you change security state from Orbiter :
06 09/11/07 16:06:53.512 Evaluated Event Handler: 1 to: 0 once per: 0 last fired 1189519147 (time is 1189519613)
07 09/11/07 16:06:53.512 Received Message from 13 (Security Plug-in / Utility) to -1001 (unknown / ), type 2 id 43 Event:House Mode Changed, parameters:
07 09/11/07 16:06:53.512 Parameter 38(PK_DeviceGroup): 0
07 09/11/07 16:06:53.512 Parameter 39(PK_HouseMode): 1
08 09/11/07 16:06:53.512 Received Message from 13 (Security Plug-in / Utility) to Apex Destiny 6100(217), type 1 id 19 Command:Set House Mode, parameters:
08 09/11/07 16:06:53.512 Parameter 5(Value To Assign): 1
08 09/11/07 16:06:53.512 Parameter 17(PK_Users): 7
08 09/11/07 16:06:53.512 Parameter 99(Password): 5678
08 09/11/07 16:06:53.512 Parameter 100(PK_DeviceGroup): 0
08 09/11/07 16:06:53.512 Parameter 101(Handling Instructions): R
08 09/11/07 16:06:53.513 Received Message from 13 (Security Plug-in / Utility) to OnScreen Orbiter(20),tinia Symbian Series 60 mobile(31),Lapitopi(38),OnScreen Orbiter(40),OnScreen Orbiter(88),Windows XP PC/tablet (Horiz)(102),Generic Proxy Orbiter(164),Windows XP PC/tablet (Horiz)(170),HC Center(174),Ati Symbian Series 60 mobile(247), type 1 id 8 Command:Remove Screen From History, parameters:
08 09/11/07 16:06:53.513 Parameter 10(ID):
08 09/11/07 16:06:53.513 Parameter 159(PK_Screen): 13
05 09/11/07 16:06:53.513 The target device 217 (routed to 217) has not registered.
13 09/11/07 16:06:53.513 No response expected. returning

But sending this command from command line doesn't work :

/usr/pluto/bin/MessageSend localhost 0 -1000 1 19 5 2 17 7 99 5678 100 0 101 R

Also sending event House Mode Changed doesn't actually change house mode (that's ok, cause events are meant for notifying):

/usr/pluto/bin/MessageSend localhost 0 -1000 2 43 38 0 39 2

I have found out the reason. -1000 is DCERouter address, but this kind of message should be addressed directly to Security plugin - in my case this is ID of 13. I'm following this, although don't understand distinction of -1000 and 13 - if DCERouter is addressed it should relay message to security plugin anyway - so I don't understand why this is necessary - any opinion ?
<div style="padding-left: 30px; background: #DDDDDD;">As far as I can tell, the reason for '-1000' is to allow devices to broadcast events to the system as a whole rather than to a specific device, presumably for event-based devices that do not do a specific function. I shall look more into this... -AVJohn.</div>

/usr/pluto/bin/MessageSend localhost 0 13 1 19 5 6 17 7 99 5678 100 0 101 R

Now it changes security mode properly... Parameters in this command line are :
0 from, 13 to Security plugin, 1-Type: Command, 19-Command "Set house mode", and the rest:
08 09/11/07 16:06:53.512 Parameter 5(Value To Assign): 1
08 09/11/07 16:06:53.512 Parameter 17(PK_Users): 7
08 09/11/07 16:06:53.512 Parameter 99(Password): 5678
08 09/11/07 16:06:53.512 Parameter 100(PK_DeviceGroup): 0
08 09/11/07 16:06:53.512 Parameter 101(Handling Instructions): R

==Other interesting DCE messages==

Will parse the meaning of DCE messages below in future. Just wrote it here to remember....

It seems like "Goto Screen" command
/usr/pluto/bin/MessageSend localhost 0 64 1 741 10 "Whatever" 159 53 9 'A message|Ok|Remind me later' 137 '-targetType device <%=!%> 15 1 67 13 "/root/Something.sh" 51 "--answer yes"|-targetType device <%=!%> 15 1 67 13 "/root/Something.sh" 51 "--answer no"'

To display Text Alert on Orbiter :
/usr/pluto/bin/MessageSend localhost 0 20 1 809 9 "Text to Display" 70 "alert" 182 "30" 251 "??"

Also interesting command is #397 "Show popup", but I have yet to discover how to use it...

Does anyone know how to display popup with question and few answer buttons (yes/no for example) ? Can this be done without Designer to create screen - just to specify question, texts on buttons and actions on click ?

Serial Hack

2007-09-19T00:15:43Z

AVJohn:

== Serial List Hack ==
In some situations, (which, I might add are becoming more and more common now) a core or core/hybrid may not have enough, or indeed, any serial ports for automation kit such as the X10 modules to jack into.

In these cases a USB-to-Serial converter may be used, but the pluto system does not list these correctly in its admin pages. This is due to the script "/usr/pluto/bin/ListSerialPorts.sh" which creates the list of serial ports, not giving the correct path (usually /dev/ttyUSB#, where # is a number).

A simple replacement, which, while inferior to the current script in that it does not detect the ports in use, does correctly list all serial ports, both USB and normal serial. However, it requires the 'tree' command, so:

<pre>sudo apt-get install tree</pre>

Once that has completed, tree will have been installed, and we can use its '-fi' mode to produce full paths, then it is just a simple matter of removing the origional ListSerialPorts.sh file and writing our own, I use vim for this, but any other terminal or graphical text editor will do the job:

<pre>
sudo rm /usr/pluto/bin/ListSerialPorts.sh
sudo vim /usr/pluto/bin/ListSerialPorts.sh
</pre>

Now that vim is open, enter the following:

<pre>
#!/bin/bash

tree -fi /dev | grep ttyS
tree -fi /dev | grep ttyUSB
</pre>

== Comments ==

If someone out there has a better way of doing this, please post it here! -AVJohn

[[Category: GSD]]
[[Category: LinuxMCE_Devices]]
[[Category: Programmer's Guide]]

Generic Serial Device

2007-09-19T00:15:40Z

AVJohn:

Generic_Serial_Device (also known as '''GSD''') is a LinuxMCE device that allows end-user to do simple programming for RS232, serial USB (See [[Serial Hack]] for details on getting USB to serial adapters identified properly in the admin panel!) or network connected devices.
:Note : The information is not quite complete because I'm not the original author.

== Short description ==
It's a standard DCE device, it only can execute commands and send events .
The main idea is instead of programming a device in C++, compile, link with proper libraries you can edit (in a webpage) few lines of code in ruby which will be executed when device receives that command. It exports several objects into ruby so you'll have access to devicedata, device hierarchy, established connection and so on.

The ruby code for each device template is stored somewhere in ''InfraredGroup_Command'' table. To edit the code go to Wizard> Devices > Generic_Serial_Devices on [[LinuxMCE-admin]] website. You have to add a device from a device template in order to see anything in that page.

Select the device, and click "RubyCodes" button to be able to edit code that will be executed.
You should be able to see commands that are specified in device template (like ON/OFF/WhateverElse) and a group of ''Internal Commands'' which are used to perform certain actions are to add helper functions.

If the command you are trying to add doesn't show on first page, go to ''Add/Remove commands'' and add more commands for your device.

=== Ruby source code ===

There are 2 forms of ruby code you can write :
* standard ruby code (check [http://www.ruby-lang.org/en/] and [http://poignantguide.net/ruby/] for syntax, references and programming guides)
* short form for '''conn_.Send'''
<$"PWON\r"$>
:which simply will send the string ''"PWON\r"'' to device.

You'll have to quick reload router to get new code. Restarting GSD only will keep old code because the code is supplied by [[Infrared_Plugin]] which caches pluto_main and won't update it's cache without full restart of [[DCERouter]]. With this code it creates a ruby source which will be interpreted by embedded ruby.

It will create methods called "cmd_CmdIDx" for each command(x) defined in web interface except ''Private_Method_Listing'' which will be inserted in the body of the class directly without wrapping.

The source usually looks like (''DevID'' is iPK_Device of specific device, ''CmdIDx'' is iPK_Command ) :

require 'Ruby_Generic_Serial_Device'
class Command < Ruby_Generic_Serial_Device::RubyCommandWrapper
end
class Device_DevID < Ruby_Generic_Serial_Device::RubySerialWrapper
def cmd_CmdID1(paramlist)
@returnParamArray.clear
### WEB CODE for CmdID1 GOES HERE ###
return @returnParamArray
end
def cmd_CmdID2(paramlist)
@returnParamArray.clear
### WEB CODE for CmdID2 GOES HERE ###
return @returnParamArray
end
...
def cmd_ReceiveCommandForChild(cmd)
### Process_Receive Command_For_Child GOES HERE ###
end
...
### Private_Method_Listing GOES HERE ###
...
def initialize()
super
@returnParamArray=Array.new
end
### Generated Setters/Getters goes here (may be empty, but usually looks like below) ###
def data_set(value)
@returnParamArray[19]=value
end

end

There might be more then one class definition in that source. This may happen when child device is itself a GSD device.

=== Command details ===
When the command from DCE arrives it is routed to specific device and ''cmd_XXX'' is run. The commands are run one by one, meaning that you cannot run 2 commands simultaneously. This limitation is implied by embedded ruby interpretor which fails if run from multiple threads.
DCE commands may have return parameters (well known GetVideoFrame), as ruby can return only 1 parameter the ''@returnParamArray'' was added. You can see that in each method we insert '''@returnParamArray.clear''' then the real code and then '''return @returnParamArray'''. Also some setters are generated (like the one from above) for code readability.

Beside usual DCE command you'll see some ''Internal Commands''. Here goes a small list and what they do:
* '''Private Method Listing''' - used to insert all kind of helpers
* '''Process IDLE''' - method executed once in a while (may be used to keep connection alive, scan for new devices on serial bus)
* '''Process Incoming Data''' - called when some data is available
* '''Process Receive Command For Child''' - called if the device has children and those are pretty dummy (like Lights under CM11), so practically the parent will do the job. As a parameter you have ''cmd'' which is a wrapper for DCEMessage, so you'll have access to deviceId, senderId, commandID and so on.
* '''Process Initialize''' - called when device is starting (to perform handshake with device or some other initialisation required by protocol)
* '''Process Release''' - to close gracefully connection with device (say "good bye" or something)

== Implementation notes ==
There are several classes that actually need to be touched. Most of the other classes are just for wrapping DCE objects (like Device, Message, Connection and so on) and exporting them into ruby.

Most important classes :
* '''RubyDCEDeviceNode''' is actually the Device, responsable with initialisation and partially a message handler.
* '''RubyDCEEmbededClass''' is bridge between DeviceNode and ruby, it has ''CallCmdHandler'' which does the real call to ruby and sends back result.
* '''RubyIOManager''' is the one responsible for instantiating RubyDCEDeviceNodes, code retrieval, command handler and serializing ruby calls.
* '''RubyDCECodeSupplier''' gives you the ruby code
* '''RubyCommandWrapper''' a wrapper for Message
* '''GSDMessageProcessing''' is [[Message_Translation|message translator]] which will try to run command if it's implemented without translation.
* '''RubySerialIOConnectionWrapper''' helps to wrap Serial and TCP/IP based connection under same interface, see down the hierarchy the connection you need.

There are also some files needed for building a library for ruby with SWIG, let them alone, it should work.

The compilation will give you '''Generic_Serial_Device''' and '''Ruby_Generic_Serial_Device.so''', first file is the binary itself, second file is the bridge library and it will be included by ruby (the request for it is in the first line of the generated source)

== Known issues ==

* Only '''ONE''' command can be executed at a time. This is a limitation of embedded ruby, which should be run from one thread only.
* If command expected an answer, it would wait about 20 seconds for the ruby command to complete, and if the command haven't completed yet, it would send an empty response.
* Most of the data are pretty cryptic (like ''device_.devdata_[114]''), you have to look that that number represents (device data id, command id, command parameter id, event id, event parameter id, some other id)

== Short example ==
For more details about exported classes and available methods check [[GSD_Ruby_Interface]]

Here is a short example from ''Panasonic IP Camera'':
0:require 'Ruby_Generic_Serial_Device'
1:class Command < Ruby_Generic_Serial_Device::RubyCommandWrapper
2:end
3:class Device_47 < Ruby_Generic_Serial_Device::RubySerialWrapper
4:#### 84 ####################################################################
5:def cmd_84(data, format, disable_aspect_lock, streamid, width, height)
6:@returnParamArray.clear
7:conn_.Reconnect()
8:auth_s=device_.devdata_[114]+":"+device_.devdata_[115]
9:auth_a=Array.new;
10:auth_s.each{|c| auth_a.push(c)}
11:
12:fix_path=device_.devdata_[2];
13:fix_path='/'+fix_path if(fix_path[0]!='/'[0]);
14:
15:s = "GET "+fix_path+" HTTP/1.0\r\n"
16:s+= "Accept: */*\r\n"
17:s+= "Authorization: Basic "+auth_a.pack("m").chop+"\r\n"
18:s+= "\r\n"
19:
20:conn_.Send(s)
21:recv=""
22:while(true)
23: buff=conn_.Recv(16384, 5000)
24: if(buff.length() == 0)
25: break
26: end
27: recv = recv + buff
28:end
29:if (recv=~ /^HTTP[^\r\n]+200\sOK.+?\r\n\r\n(.+)$/m)
30: data_set($1)
31: format_set('jpg')
32:end
33:return @returnParamArray
34:end
...
194:#### START SETTERS ####################################################################
195:def initialize()
196:super
197:@returnParamArray=Array.new
198:end
199:def data_set(value)
200:@returnParamArray[19]=value
201:end
202:def format_set(value)
203:@returnParamArray[20]=value
204:end
205:#### END SETTERS ####################################################################
206:end
You can see how command 84 (GetVideoFrame) is implemented:
* it has 6 parameters ''cmd_84(data, format, disable_aspect_lock, streamid, width, height)'', parameters ''data'' and ''format'' are also output parameters
* to set output parameters methods like ''data_set'' and ''format_set'' are automatically generated
* ''device_.devdata_[114]'', ''device_.devdata_[115]'' are the username and password to login into camera
* then it creates HTTP header with basic authorization
* ''device_.devdata_[2]'' is the path to the snapshot (it is configurable because it can change between models)
* it sends the request and waits for the answer
* reads the answer, regexp parse it and gets JPEG content
* sets output parameters
* returns @returnParamArray (the return statement is added automatically)

== Example - Adding Clipsal Interface ==

We can control lights, curtains and climate controls using Clipsal Interface that connects through Serial Port.

[[Here is a detailed example of how to add Clipsal Interface using Generic Serial Device.|Adding Clipsal Interface using Generic Serial Device]]

== Useful Pages ==
* [[Serial Hack]] - A quick and dirty hack to fix the USB to Serial adapter problem! (Device not showing the correct block device on the admin panel)

[[Category: GSD]]
[[Category: LinuxMCE_Devices]]
[[Category: Programmer's Guide]]

Serial Hack

2007-09-19T00:03:43Z

AVJohn: