LinuxMCE Forums
Archive => Archive => Pluto Main General Issues => Topic started by: archived on September 01, 2005, 12:43:03 am
-
Does anyone know if Pluto supports the firecracker (CM17A - http://www.smarthome.com/1141.html), or is the CM11A the way to go?
-
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
-
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...
-
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.
-
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
-
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.
-
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,
-
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.
-
Has *anyone* done any GSD coding for Pluto, that have examples of Ruby code that was added?
-
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.
-
It'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.
-
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
-
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.
-
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
-
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!
-
I have made some preliminary code to support the firecracker (CM17A) transmitter.
On/Off commands work fine, but DIM must be improved.
It's some ruby codes that uses bottlerocket. so you need to
apt-get install bottlerocket on the machine where your firecracker is connected.
Create a GSD device and use this ruby code:
ser_dev=device_.devdata_[37]; #37 is serial device
id=device_.childdevices_[cmd.devidto_].devdata_[12]; #12 is device ID
house = id[/\w/]; # extract house code
dev = id[/\d+/]; # extract device id
br_cmd="/usr/bin/br --port="+ser_dev+" --house="+house+" ";
case cmd.id_
when 192 then # POWER ON
system(br_cmd+" --on="+dev);
when 193 then # POWER OFF
system(br_cmd+" --off="+dev);
when 184 then # DIM value
system(br_cmd+" --off="+dev);
bright=(cmd.params_[76].to_i/100.0*12).round.to_s;
puts "Now brightening by "+bright;
system(br_cmd+" --dim="+bright+","+dev);
puts "Brightened.";
end
Worked ok for me.
Then I bought a CM11A and I'm still fighting with it (it doesn't like the events fired by other controllers like wireless, gets "checksum error" and must be unplugged and replugged to work again. But that's a different topic :)
-
The Firecracker is able to transmit X10 lighting commands and the data is send on an RS232 port using the control-lines. The Firecracker uses the US 310MHz RF frequency only.
www.rfxcom.com sells an USB RF transmitter that is able to transmit X10 lighting AND X10 security commands. There is an US version (310MHz) and a European version (433.92MHz) available. The USB devices use a VirtualComPort protocol and a Linux driver is available.
They also have USB RF receivers for:
- X10 310MHz (US)
- X10 433.92MHz (European)
- Visonic alarm systems
All receivers have a 32 bits mode which is compatible with the W800. Additionally they have a variable length receiving mode so that receiving of the Digimax (European thermostat) is also possible.
The Visonic receiver translates the received sensor signals to X10 equivalents so that the software only has to be programmed for X10 sensors.
One USB interface can have 2 receivers so that a Visonic and an X10 receiver can co-exist in one USB interface and both signals are available to the software.
The RFXSensor wireless RF temperature, humidity and barometric pressure sensors can be received by the RFXCOM receiver and also by the W800.
Soon the RFXPower will be released. This is a Power Metering device with RF transmitter. The 48 bits data can be received by the RFXCOM X10 receiver.
Bert