News:

Rule #1 - Be Patient - Rule #2 - Don't ask when, if you don't contribute - Rule #3 - You have coding skills - LinuxMCE's small brother is available: http://www.agocontrol.com

Main Menu

X-10 firecraker (CM17A) adapters

Started by brett_schwarz, September 01, 2005, 12:43:03 AM

Previous topic - Next topic

archived

Does anyone know if Pluto supports the firecracker (CM17A - http://www.smarthome.com/1141.html), or is the CM11A the way to go?

archived

we don't have a device driver for it, in fact I have never seen the firecracker before.  It's possible it uses the same protocol is the CM 11A and is therefore compatible.  You may want to consider calling smarthome's tech support, I found them to be pretty helpful usually

archived

Quote from: "aaron.b"we don't have a device driver for it, in fact I have never seen the firecracker before.  It's possible it uses the same protocol is the CM 11A and is therefore compatible.  You may want to consider calling smarthome's tech support, I found them to be pretty helpful usually

How easy would it be for me to add a driver for that? Is that possible? Where would I look? There are already linux based drivers for it, so it would just be a matter of porting the code into Pluto...

archived

it's quite easy, normally we add drivers for stuff like that within a few hours, maybe a day max.  There are two ways to do it--in c++ or using our GSD model.  with GSD there is a web-based wizard where you pick off the commands and events the device implements, and then it gives you a fill in the blank style form where you indicate what commands to send the device, and it includes an embedded Ruby language interpreter, so you can add Ruby code to do stuff.  The nice thing about GSD is that there is no code to check-in or compile.  The snippets you enter for Ruby go in to your local database, which is automatically synchronized against a master server, and then propagated to all other users.  It's also very easy and you don't need to be much of a programmer to use it.

the other possibility is to use the same web-based wizard to pick up the commands and events and then run our tool called DCEGen which will build you a C++ project, complete with methods for the commands that are stubs for you to implement and methods you can call to fire events.  If you want to link in other libraries, or call other see code, then of course the C++ project is better, but in this case you'll need to send as the code so we can add it to our repository, and we will create a package definition so that the code is automatically compiled, build and release with each version.

archived

Quote from: "aaron.b"it's quite easy, normally we add drivers for stuff like that within a few hours, maybe a day max.  There are two ways to do it--in c++ or using our GSD model.  with GSD there is a web-based wizard where you pick off the commands and events the device implements, and then it gives you a fill in the blank style form where you indicate what commands to send the device, and it includes an embedded Ruby language interpreter, so you can add Ruby code to do stuff.  The nice thing about GSD is that there is no code to check-in or compile.  The snippets you enter for Ruby go in to your local database, which is automatically synchronized against a master server, and then propagated to all other users.  It's also very easy and you don't need to be much of a programmer to use it.

Ok, any hints on how to get started with this, and are there any examples I can look at, to get a feel for it?

thanks

archived

Practically Generic_Serial_Device makes an interface between DCERouter and your device. Right now only sending commands (usually from DCERouter to Device) is supported.
The nice catch is that you can write your own handler for each command you want to implement in Ruby. This way you don't need to go down to low level C++ programming.

GSD exports into Ruby some variables like device configuration data, connection opened to device so you can communicate with it and so on.

There are also some "default" methods that you can implement :
- Process_Initialize is called when your device is started maybe you need some global variables, or send something to device to notify it that you are online.
- Process_Incoming_Data is called then device is trying to send you some data, here you usually read the data, acknowledge the transmission and do other things depending on what the device sent to you.
- Process_Receive_Command_For_Child is called when you have child devices attached to your GSD device. This is the case of more sophisticated devices like for example Bang&Olufsen interface: you have one device attached to CORE, but there are more devices attached to that devise, so you can not send something directly to a child device, you need to say to parent device to send that and that to one of his children.

In Ruby context you may call following methods to communicate with your device:
conn_.Send(<string to send>)        => returns number of characters sent
conn_.Recv(<numeric max buffer size>,<numeric timeout in ms>)        => returns a string which was read

Some useful variables:
- device_.devdata[<a number>]        => gives you acces to data you entered in "Device Data" section when you added the device

In web interface you can write Ruby code that will execute when the device is receiving a
command. The connection to device is exported into Ruby so for example on Process_Incoming_Data you can simply put:
buffer = conn_.Recv(100,500);
print buffer;

it will receive a buffer of max 100 characters, waiting 0.5 seconds to receive it, and will print it, the result can be seen in log (/var/log/pluto/XXXX_Generic_Serial_Device.newlog)

Try to look for GSD devices and take a look at ruby code for some samples.

archived

Quote from: "torindan"
In web interface you can write Ruby code that will execute when the device is receiving a
command. The connection to device is exported into Ruby so for example on Process_Incoming_Data you can simply put:
buffer = conn_.Recv(100,500);
print buffer;

it will receive a buffer of max 100 characters, waiting 0.5 seconds to receive it, and will print it, the result can be seen in log (/var/log/pluto/XXXX_Generic_Serial_Device.newlog)

Try to look for GSD devices and take a look at ruby code for some samples.

That's what I am having problems with....trying to find out *how* to add a new device, and to find *examples* of what has already been done. Are there any devices that come with the core that have Ruby code? If so, how do I get there....I can't seem to figure out how to get there.

thanks,

archived

Dan can provide a more complete reply, but....  First upgrade to 29 which we just released--we improved the GSD page.

Then in Pluto Admin go to Wizard, Devices, Generic Serial Devices.  Click 'add device'.  Choose the manufacturer and category, and click 'add model'.  On the GSD page, the 'edit gsd code' lets you edit the Ruby snippets.

Also, check this out: http://plutohome.com/support/index.php?section=document&docID=113

Admittedly our docs need some organizing and improving.  Remember the docs are wiki-style, so if you go to the support site on your own core you can always add/change them.

archived

Has *anyone* done any GSD coding for Pluto, that have examples of Ruby code that was added?

archived

This is code which implements "Get Video Frame" command in IP cameras (works with Panasonic and Axis, as long as device_.devdata_[2] is correct)

conn_.Reconnect()
auth_s=device_.devdata_[114]+":"+device_.devdata_[115]
auth_a=Array.new;
auth_s.each{|c| auth_a.push(c)}

s = "GET "+device_.devdata_[2]+" HTTP/1.0\r\n"
s+= "Accept: */*\r\n"
s+= "Authorization: Basic "+auth_a.pack("m").chop+"\r\n"
s+= "\r\n"

conn_.Send(s)
recv=""
while(true)
 buff=conn_.Recv(16384, 5000)
 if(buff.length() == 0)
    break
  end
  recv = recv +  buff
end
if (recv=~ /^HTTP[^\r\n]+200\sOK.+?\r\n\r\n(.+)$/m)
 data_set($1)
 format_set('jpg')
end


As you can see I send a request to an IP camera via HTTP protocol, I'm waiting for response, getting actual image, and setting output parameters so when the call will return back to C++ I will have output parameters filled.

It's plain ruby code which uses several variables and methods provided by GSD framework, like connection object (conn_ + Send/Recv), setters for output parameters (data_set(), format_set()) and that's it.
Not such a big deal.

If you are doing programming for a serial device, no problem, conn_ is still a connection to device and you can send a string containing some byte sequence, which will be processed by device. You can receive the response, decrypt it (usually it's just a sequence of bytes not a clear text message) and do whatever you want to do with that data.

archived

QuoteIt's possible it uses the same protocol is the CM 11A and is therefore compatible.
Nope.  The firecracker uses pulses of signals on the serial port (e.g., sending binary codes by bit-flipping RTS and DTR.)  

http://www.geocities.com/ido_bartana/Firecracker_protocol.htm

Might work, but I think it would be better to get a smarter interface, since the pluto boxes can get busy doing things.

archived

is there a way to code a device that just executes commands on the local system?  There is currently an open source program that controls the CM17A, you can see it (and download it) at: http://www.lickey.com/flipit/.  So if pluto's lighting module can just make system calls, it would be easy for me to use the firecracker.  There was also a software called bottlerocket for the firecracker, but the site for it isnt up anymore (appears to have been hosted at a university).  it appears that Both pieces of software are available through apt-get, but I have not verified this.

Elliot

archived

You can try and install those packages.
Being in Ruby you simply can call
system("/usr/bin/CM17Binary some parameters")
This way when GSD device receives "ON" command for a light you can call
system("/usr/bin/CM17Binary ON "+device_.devdata_[12])
or something simmilar...(i don't know exaclty how those binary is called or what kind of parameter it needs)

You practically can do whatever you want and that's the beauty of GSD.

archived

sounds good.  I will review the documentation on the GSD and just code a device thats a wrapper for this binary.

Thank you very much

archived

FYI
I am not sure, but I understand tat firecracker is a unidirectional device only,  proboably not what you want to work with
you may want to loo at http://www.wgldesigns.com/w800.html as an alternative.
have not tried it but was on the same path and this was what I found, let me know!