LinuxMCE Forums

General => Users => Topic started by: Riggs on July 11, 2010, 06:58:12 AM

Title: X10 CM19A
Post by: Riggs on July 11, 2010, 06:58:12 AM
Ok so i got a CM19a and want it to work in LMCE

so first i did a search and fount a driver:
download it here: http://m.lemays.org/projects/x10-cm19a-linux-driver

Install the driver: http://pr0gr4mm3r.com/linux/getting-your-x10-cm19a-module-working-in-linux/

1 Go to your terminal, and cd into that extracted directory.
2 As per the instructions in the software's readme file, run the following commands:

    sudo make
    sudo make install
    sudo modprobe x10-cm19a

sudo gedit /etc/modprobe.d/blacklist
    Then add to the end of the file:

    # causes the custom cm19a driver to fail
    blacklist lirc_atiusb
    blacklist ati_remote

Type in a terminal:

    sudo rmmod lirc_atiusb
    sudo rmmod ait_remote

sudo gedit /etc/udev/rules.d/40-permissions.rules
     Add the following to the end of the file:

    KERNEL=="cm19a0″, MODE="0666″

reboot

then type sudo chmod 0666 /dev/cm19a0

You're done, yay! Now it's time to test it out. Remember, this driver only provides an interface to the module. You will have to write your own software / scripts / cron jobs to make it useful.The interface works by sending strings to it. To turn on A1, we send +A1 to it. To turn off C4, we send -C5 to it. In practice, type in the following command to turn on A1:

    echo +A1 > /dev/cm19a0

I found all this info so i'm no expert if you need help you will need to ask at the above forum.

Now i have a working drive I have now got to get LMCE to work with it any help would be greate

Thanks to Thom on the IRC for giving so pointers



Title: Re: X10 CM19A
Post by: tschak909 on July 11, 2010, 06:14:58 PM
These steps will have to be placed into a post install script for the driver package you will need to create, so people will not have to do this by hand.

-Thom
Title: Re: X10 CM19A
Post by: Riggs on July 12, 2010, 01:58:21 AM
so far i have created a template
Device Template #2148
Description CM19A
Implements DCE
Command line: Generic_Serial_Device
Device Category*: Interfaces #71
Manufacturer*: Pluto #1
This device is controlled via category: Device Category: Computers
Packages: Pluto Generic Serial Device
Comm Method: USB
Comments: Active Home Pro CM19A

Device data:
#162  Only One Per PC(bool)     only one per pc    1

Commands:
Ruby Internal Commands

Plug & Play:
Vendor Model ID 0bc70002    PNP protocol HAL USB
Comments CM19A USB device.

No code has been written yet as i don't know how yet
Title: Re: X10 CM19A
Post by: tschak909 on July 12, 2010, 02:07:46 AM
Have you verified that the device is found when you plug it in?

-Thom
Title: Re: X10 CM19A
Post by: Riggs on July 12, 2010, 02:08:56 AM
how would i do that
Title: Re: X10 CM19A
Post by: tschak909 on July 12, 2010, 02:10:27 AM
*hmm*

make sure the device isn't in your device tree.

Plug it in.

Does an orbiter mention that it has found the device?

-Thom
Title: Re: X10 CM19A
Post by: Riggs on July 12, 2010, 02:12:17 AM
LOL sorry just looked at the weborbiter it has fount it and ask me if i want to use it
Title: Re: X10 CM19A
Post by: Riggs on July 12, 2010, 02:14:10 AM
im reading up on ruby stuff on the wiki and im not getting any where so my brain is a bit slow to think about the obvious, orbiter 
Title: Re: X10 CM19A
Post by: Riggs on July 12, 2010, 02:41:44 AM
To control the transceiver, format the commands as

[-+][a-p][01][1-9]

For example:
echo +A1 > /dev/cm19a0
- to turn on device a1: +a1
- to turn off device a1: -a1
- etc.

[udlr][a-p]

Ninja Pan'n'Tilt commands:
u = up
d = down
l = left
r = right

[bs][a-p][01][0-9]
Lamp module commands:
b = brighten
s = soften
Title: Re: X10 CM19A
Post by: Riggs on July 12, 2010, 02:59:42 AM
So reading the wiki i fount some code I figure i could use this and a just it:
no i need to send echo +A > /dev/cm19a0 for on so do i replace A with devPort

cmdId       = cmd.id_                                                      # Command ID: ON, OFF, SET LEVEL
cmdTo       = cmd.devidto_                                              # Device ID in LinuxMCE
devPort     = device_.childdevices_[cmdTo].devdata_[12]      # 12 contains a port/channel
childType   = device_.childdevices_[cmdTo].devtemplid_       # Template ID to know type of device: switch or dimmer

case cmdId
     when 192 #192 is ON                    
          command = 'echo +devPort > /dev/cm19a0'          
     when 193 #193 is OFF                        
          command = 'echo -devPort > /dev/cm19a0'
     when 184 #184 is Level of dimmer
          command = '<your SET LEVEL command format>'                  
end

conn_.Send(command)
Title: Re: X10 CM19A
Post by: tschak909 on July 12, 2010, 03:06:40 AM
Not quite.

If you read, by default GSD assumes that you are opening a connection to a serial port, or to a TCP port. Conn_.send contents go to the port specified in your interface's devicedata.

Since your device falls outside this constraint (it is a device file being exposed by a kernel device driver.), you need to use Ruby's IO commands to read and write to it, instead of using the Conn object.

However, the basic code structure of using the case statements to determine which command to send is correct
What I would do, is define a new method inside the Private Method Listing. Call it something useful like def sendToDevice, and use this method instead of Conn_.send to send the needed strings.

Since this device doesn't really expose any events, you can choose to do the opening and closing of the file handle inside your new method, to make things transactionally atomic, either that, or if you want to leave it open, open the device in Process Initialize, and set a class variable for it, so that your sendToDevice method can use it. It's up to you.

-Thom
Title: Re: X10 CM19A
Post by: Riggs on July 12, 2010, 04:44:10 AM
So to start simple i did this
created a file named "test.rb" and in it i put
#!/usr/bin/ruby
sendToDevice = File.new("/dev/cm19a0", "a")
sendToDevice.puts "+A5"

then i did chmod +x
then ./test.rb
and it switched on a light

so no i know how to write to the device file

I'm sorry Thom but i'm not a programmer so i need to start simple and work up

Title: Re: X10 CM19A
Post by: Marie.O on July 12, 2010, 08:26:41 AM
Riggs,

hang in there, you are progressing nicely!
Title: Re: X10 CM19A
Post by: Riggs on July 12, 2010, 05:44:12 PM
how do i get it to log, so i can see what my code is doing, i know it don't work but don't know why
Title: Re: X10 CM19A
Post by: tschak909 on July 12, 2010, 05:46:39 PM
GSD does not provide a logging function, for the running code itself.

However, you can use the log method that ddamron wrote for his PLM device, just cut and paste it into your private method listing. You can then call it to output a log line to xx_Generic_Serial_Device.log.

But GSD does provide rudimentary logging for the interpreter in the abovementioned log file.

-Thom
Title: Re: X10 CM19A
Post by: Riggs on July 12, 2010, 05:55:42 PM
where would i start looking for this code, ie wiki or forum
Title: Re: X10 CM19A
Post by: tschak909 on July 12, 2010, 06:06:43 PM
It is in the private method listing for the Insteon PLM driver. Either by looking at the Ruby Codes attached to the device template for the Insteon PLM, or by looking at the Insteon PLM page in the wiki.

-Thom
Title: Re: X10 CM19A
Post by: Riggs on July 12, 2010, 06:11:22 PM
are you talking about this: http://wiki.linuxmce.org/index.php/Insteon_PLM_Ruby_Code_373

looking at this code is like an English speaking guy trying to read native Latin, and then trying to talks his way out of not getting killed in Latin  

for instance: Latina lingua non utor (I don't speak Latin) yahoo answers
Title: Re: X10 CM19A
Post by: Riggs on July 12, 2010, 06:32:07 PM
the code is wrong i know, i want to start basic and see something work and then make it better:

cmdId = cmd.id_                                                     # Command  ID: ON, OFF, SET LEVEL
cmdTo = cmd.devidto_                                             # Device ID in LinuxMCE
devPort = device_.childdevices_[cmdTo].devdata_[12]   # 12 contains a port/channel
childType = device_.childdevices_[cmdTo].devtemplid_  # Template ID to know type of device:
sendToDevice = File.new("/dev/cm19a0", "a")

case cmdId
      when 192 #192 is ON
              sendToDevice.puts "+devPort"
      when 193 #193 is OFF
              sendToDevice.puts "-devPort"
      when 184 #184 is Level of dimmer
              sendToDevice.puts ""
end
Now i don't know what is right and what is wrong in this code I just got it from the wiki because it looked like what i need and all i needed to do was change it a bit.
i do not understand any of it, well I know that sendToDevice = File.new("/dev/cm19a0", "a")  
means from now on File.new("/dev/cm19a0", "a") is gonna be called  sendToDevice,
and File.new is the command RB use to write to a file, /dev/cm19a0 is the file i want to write to and "a" means append to file

so i came up with sendToDevice.puts "+devPort"   as in i want RB to write a + and the devport in said file, but i guessing it is writing +devPort in the file instead of A1

Title: Re: X10 CM19A
Post by: Riggs on July 12, 2010, 06:43:25 PM
I guess i should scrap that code and write it from scratch, to do so i need some basic info,

does device_.childdevices_[cmdTo].devdata_[12] get me the channel and port number ie, A1
does cmdId_ get me the switch type ie, on off
Title: Re: X10 CM19A
Post by: tschak909 on July 12, 2010, 06:44:42 PM
If you look at the database table, DeviceData, it will become clear, look at the primary keys...

-Thom
Title: Re: X10 CM19A
Post by: Riggs on July 12, 2010, 08:01:12 PM
ok is the template messed up as well as my code or just my code, see log below:

Complete log
Device CM19A, # 60    
Device Template CM19A, device category Specialized, manufacturer Pluto.   
   
157 lines, displaying from 0 to 157   
1   

== ATTEMPT FRESH START ==
1   07/11/10 19:21:46   /usr/pluto/bin/Spawn_Device.sh 60 (spawning-device)   23901 Dev: 60; Already Running list: 15,16,18,19,31,32,46,44,21,27,25,26,30,36,23,22,34,
== FRESH START ==
1   07/11/10 19:21:46   /usr/pluto/bin/Spawn_Device.sh 60 (spawning-device)   device: 60 ip: localhost cmd_line: Generic_Serial_Device
0   07/11/10 19:21:46   60 (spawning-device)   Entering 60
========== NEW LOG SECTION ==========
1   07/11/10 19:21:46   60 (spawning-device)   Starting... 1
1   07/11/10 19:21:46   60 (spawning-device)   Found /usr/pluto/bin/Generic_Serial_Device
05   07/11/10 19:21:46.904      Connection for client socket reported NEED RELOAD IP=127.0.0.1, device 60 last error 2 <0xb70938d0>
05   07/11/10 19:21:46.904      The router must be reloaded before this device is fully functional <0xb70938d0>
05   07/11/10 19:21:46.905      void ClientSocket::Disconnect() on this socket: 0xa0201e8 (m_Socket: 5) <0xb70938d0>
05   07/11/10 19:21:46.909      Connection for client socket reported NEED RELOAD IP=127.0.0.1, device 60 last error 2 <0xb70938d0>
05   07/11/10 19:21:46.910      Running without DeviceData, will try to add device <0xb588fb90>
01   07/11/10 19:21:46.952      GSD Port is not specified. Instantiating non-IO Wrapper. <0xb588fb90>
RCODE:
   0:require 'Ruby_Generic_Serial_Device'
   1:class Command < Ruby_Generic_Serial_Device::RubyCommandWrapper
   2:end
   3:class Device_60 < Ruby_Generic_Serial_Device::RubySerialWrapper
   4:#### START SETTERS ####################################################################
   5:def initialize()
   6:super
   7:@returnParamArray=Array.new
   8:end
   9:####  END  SETTERS ####################################################################
  10:end
12:05   07/11/10 20:03:56.947      Got a reload command from 0  <0xb588fb90>
05   07/11/10 20:03:57.275      void ClientSocket::Disconnect() on this socket: 0xa0205a8 (m_Socket: 8) <0xb70938d0>
Return code: 2
2   07/11/10 20:03:57   60 (spawning-device)   Device requests restart... count=1/50 dev=60
Sun Jul 11 20:03:57 CDT 2010 Restart
========== NEW LOG SECTION ==========
1   07/11/10 20:04:05   60 (spawning-device)   Starting... 1
1   07/11/10 20:04:05   60 (spawning-device)   Found /usr/pluto/bin/Generic_Serial_Device
05   07/11/10 20:04:06.488      Connect() failed, Error Code 111 (Connection refused)) <0xb6ff68d0>
05   07/11/10 20:04:07.496      Connect() failed, Error Code 111 (Connection refused)) <0xb6ff68d0>
01   07/11/10 20:04:10.781      GSD Port is not specified. Instantiating non-IO Wrapper. <0xb57f2b90>
RCODE:
   0:require 'Ruby_Generic_Serial_Device'
   1:class Command < Ruby_Generic_Serial_Device::RubyCommandWrapper
   2:end
   3:class Device_60 < Ruby_Generic_Serial_Device::RubySerialWrapper
   4:def cmd_ReceiveCommandForChild(cmd)
   5:cmdId            = cmd.id_                                                                       # Command ID: ON, OFF, SET LEVEL
   6:cmdTo           = cmd.devidto_                                                             # Device ID in LinuxMCE
   7:devPort         = device_.childdevices_[cmdTo].devdata_[12]      # 12 contains a port/channel
   8:childType      = device_.childdevices_[cmdTo].devtemplid_       # Template ID to know type of device: switch or dimmer
   9:
  10:case cmdId
  11:      when 192 #192 is ON                     
  12:           command = 'echo +devPort > /dev/cm19a0'           
  13:      when 193 #193 is OFF                       
  14:           command = 'echo -devPort > /dev/cm19a0'
  15:      when 184 #184 is Level of dimmer
  16:           command = ''                   
  17:end
  18:
  19:conn_.Send(command)
  20:
  21:end
  22:#### START SETTERS ####################################################################
  23:def initialize()
  24:super
  25:@returnParamArray=Array.new
  26:end
  27:####  END  SETTERS ####################################################################
  28:end
30:05   07/11/10 21:19:06.388      Process Queue = 1 <0xb57f2b90>
01   07/11/10 21:19:06.401      For obscure reasons could not handle the message <0xb4ff1b90>
05   07/11/10 21:19:26.388      Socket::ReceiveData 0x967e5a8 failed, bytes left 0 start: 89160000 1: 0 1b: 0 2: 0 2b: 0 m_Socket: 8 Command_Impl1 Dev #60 <0xb57f2b90>
05   07/11/10 21:19:26.389      Socket::ReceiveString2 ReceiveData failed m_Socket: -1 Command_Impl1 Dev #60 <0xb57f2b90>
01   07/11/10 21:19:26.389      Receive string failed in HandleRequestSocket 18:ReceiveData failed Command_Impl1 Dev #60 <0xb57f2b90>
05   07/11/10 21:19:26.389      Dumping 1 locks <0xb57f2b90>
05   07/11/10 21:19:26.389      finished check for exceptions <0xb57f2b90>
05   07/11/10 21:19:26.389      OL: (0x967e6f4) (>93) MessageQueue Command_Impl.cpp l:822 time: 6:00:00p (1278901166 s) thread: 3053403024 Rel: Y Got: Y <0xb57f2b90>
Return code: 2
2   07/11/10 21:19:26   60 (spawning-device)   Device requests restart... count=1/50 dev=60
Sun Jul 11 21:19:26 CDT 2010 Restart
========== NEW LOG SECTION ==========
1   07/11/10 21:19:34   60 (spawning-device)   Starting... 1
1   07/11/10 21:19:34   60 (spawning-device)   Found /usr/pluto/bin/Generic_Serial_Device
01   07/11/10 21:19:34.697      GSD Port is not specified. Instantiating non-IO Wrapper. <0xb57fbb90>
RCODE:
   0:require 'Ruby_Generic_Serial_Device'
   1:class Command < Ruby_Generic_Serial_Device::RubyCommandWrapper
   2:end
   3:class Device_60 < Ruby_Generic_Serial_Device::RubySerialWrapper
   4:def cmd_ReceiveCommandForChild(cmd)
   5:cmdId         = cmd.id_                                    # Command ID: ON, OFF, SET LEVEL
   6:cmdTo         = cmd.devidto_                               # Device ID in LinuxMCE
   7:devPort       = device_.childdevices_[cmdTo].devdata_[12]  # 12 contains a port/channel
   8:childType     = device_.childdevices_[cmdTo].devtemplid_   # Template ID to know type of device: switch or dimmer
   9:sendToDevice  = File.new("/dev/cm19a0", "a")
  10:case cmdId
  11:      when 192 #192 is ON                     
  12:           sendToDevice.puts "echo +devPort"           
  13:      when 193 #193 is OFF                       
  14:           sendToDevice.puts "echo -devPort"
  15:      when 184 #184 is Level of dimmer
  16:           sendToDevice.puts ""                 
  17:end
  18:end
  19:#### START SETTERS ####################################################################
  20:def initialize()
  21:super
  22:@returnParamArray=Array.new
  23:end
  24:####  END  SETTERS ####################################################################
  25:end
27:05   07/12/10 7:38:55.767      Going to rotate logs... <0xb57fbb90>
05   07/12/10 12:44:40.338      Socket::ReceiveData 0x98245a8 failed, bytes left 0 start: 724540000 1: 0 1b: 0 2: 0 2b: 0 m_Socket: 8 Command_Impl1 Dev #60 <0xb57fbb90>
05   07/12/10 12:44:40.338      Socket::ReceiveString2 ReceiveData failed m_Socket: -1 Command_Impl1 Dev #60 <0xb57fbb90>
01   07/12/10 12:44:40.338      Receive string failed in HandleRequestSocket 18:ReceiveData failed Command_Impl1 Dev #60 <0xb57fbb90>
05   07/12/10 12:44:40.338      Dumping 1 locks <0xb57fbb90>
05   07/12/10 12:44:40.338      finished check for exceptions <0xb57fbb90>
05   07/12/10 12:44:40.338      OL: (0x98246f4) (>75) MessageQueue Command_Impl.cpp l:822 time: 6:00:00p (1278956680 s) thread: 3053439888 Rel: Y Got: Y <0xb57fbb90>
== ATTEMPT FRESH START ==
1   07/12/10 12:47:38   /usr/pluto/bin/Spawn_Device.sh 60 (spawning-device)   16919 Dev: 60; Already Running list: 15,16,18,19,31,32,46,
== FRESH START ==
1   07/12/10 12:47:38   /usr/pluto/bin/Spawn_Device.sh 60 (spawning-device)   device: 60 ip: localhost cmd_line: Generic_Serial_Device
0   07/12/10 12:47:38   60 (spawning-device)   Entering 60
========== NEW LOG SECTION ==========
1   07/12/10 12:47:38   60 (spawning-device)   Starting... 1
1   07/12/10 12:47:38   60 (spawning-device)   Found /usr/pluto/bin/Generic_Serial_Device
05   07/12/10 12:47:38.271      Creating child 61 <0xb6ff48d0>
05   07/12/10 12:47:38.272      Note: Device manager has attached a device of type 38 that this has no custom event handler for.  It will not fire events. <0xb6ff48d0>
05   07/12/10 12:47:38.272      Note: Device manager has attached a device of type 38 that this has no custom handler for.  This is normal for IR. <0xb6ff48d0>
05   07/12/10 12:47:38.272      Creating child 62 <0xb6ff48d0>
05   07/12/10 12:47:38.272      Note: Device manager has attached a device of type 37 that this has no custom event handler for.  It will not fire events. <0xb6ff48d0>
05   07/12/10 12:47:38.272      Note: Device manager has attached a device of type 37 that this has no custom handler for.  This is normal for IR. <0xb6ff48d0>
01   07/12/10 12:47:38.305      GSD Port is not specified. Instantiating non-IO Wrapper. <0xb57f0b90>
RCODE:
   0:require 'Ruby_Generic_Serial_Device'
   1:class Command < Ruby_Generic_Serial_Device::RubyCommandWrapper
   2:end
   3:class Device_60 < Ruby_Generic_Serial_Device::RubySerialWrapper
   4:def cmd_ReceiveCommandForChild(cmd)
   5:def cmd_ReceiveCommandForChild(cmd)
   6:devPort      = device_.childdevices_[cmdTo].devdata_[12] #port/channel
   7:sendToDevice = File.new("/dev/cm19a0", "a")
   8:  if cmd.id == 192                 
   9:     sendToDevice.puts "devPort"
  10:     sendToDevice.puts "+"
  11:end
  12:end
  13:#### START SETTERS ####################################################################
  14:def initialize()
  15:super
  16:@returnParamArray=Array.new
  17:end
  18:####  END  SETTERS ####################################################################
  19:end
21:01   07/12/10 12:47:38.360      Failed loading code: Error loading code:
error: (eval):9: compile error
(eval):9: unterminated string meets end of file
(eval):9: syntax error, unexpected tSTRING_END, expecting tSTRING_CONTENT or tREGEXP_END or tSTRING_DBEG or tSTRING_DVAR, line: 9
. <0xb4fefb90>
Title: Re: X10 CM19A
Post by: Riggs on July 12, 2010, 09:01:15 PM
if i run  in the echo +A1 > /dev/cm19a0 terminal i get -bash: /dev/cm19a0: Invalid argument
and if i look in dnesg i see  [ 190.812686] x10-cm19a: devf_open: Couldn't submit interrupt input URB: -22

Now if i reboot the core and do echo +A1 > /dev/cm19a0 in the terminal before the core is fully up it works 
Title: Re: X10 CM19A
Post by: Riggs on July 12, 2010, 09:38:43 PM
I have deleted my ruby code then clicked update so i could just start from scratch but there is now a load of code in there and i dint put it there
Title: Re: X10 CM19A
Post by: Riggs on July 12, 2010, 10:01:40 PM
I think i might as well give up and just type terminal commands to use x10.
I'm not a programmer and it seems i never will be, i cant get anything working not even a simple peace of code that writes to a file when it receives the on command, F*&^ knows how i will get the x10 IR blaster working.
Title: Re: X10 CM19A
Post by: rperre on August 03, 2010, 04:51:56 AM
Riggs, have you tried using the cm15a code in lmce, looks like it's a similar device.

I have a bunch of x10 stuff and think this cm15A or cm19A would be nice to have and hopefully more reliable then the cm11a i have now.

Richard
Title: Re: X10 CM19A
Post by: Riggs on August 03, 2010, 06:20:40 PM
No never tried it, I now have a CM15A that i thought would work with LMCE but it never did, and i'm no dev so i dont think there is any chance of me using my X10 stuff on LMCE it seem as Linux world will only support what the main people have at the time, so I'm just using Active Home Pro with smart macros and VB Script with some .bat files to get what i want.

The guys here are doing a great job i just don't have the Linux skills to support my stuff.
Title: Re: X10 CM19A
Post by: tschak909 on August 03, 2010, 06:22:04 PM
Do yourself a favour and go z-wave. a lot easier to set up, as much of it is automatic.

-Thom
Title: Re: X10 CM19A
Post by: rperre on August 03, 2010, 06:50:16 PM
Yes Z-wave is better, it's also 4 times more expensive (at least). X10 supported devices could get more people to run lmce because of the ease and cheap way to get modules, etc... more people that run it gives more people that are able to create devices or even help develop. I know i'm not the best in programming, i'm trying though to understand the system and hopefully make it better in some way.

The same with the USB UIRT vs Vista MCE IR receivers, but that's another thread.

I've had my eyes on the CM19A, it's only $10 shipped and RF which will help in reliability!!!

Richard
Title: Re: X10 CM19A
Post by: Marie.O on August 03, 2010, 06:58:28 PM
But at the moment there is no support for the CM19A.

rperre, please invest some time and write a device template for it, so other people can save some money and use the CM19A
Title: Re: X10 CM19A
Post by: tschak909 on August 03, 2010, 07:51:28 PM
Do they use the same protocol?

-Thom
Title: Re: X10 CM19A
Post by: Riggs on August 03, 2010, 09:24:59 PM
CM19A is cheap and you must have a wireless transceiver module ie TM751, but i must admit investing in the CM15A was worth it, But CM19A will get you started.

In Windows if you use the AHP SDK you can use command prompt to send commands, the CM19A you would use (ahcmd.exe sendrf A1 on)
where as the CM15A you can use ( ahcmd.exe sendplc A1 on, or the above command ) there is also receive commands and more,
I'm not sure about the protocol but CM19A is only RF, if there is any test on windows i can run for you i will, I'm just useless at writing code
Title: Re: X10 CM19A
Post by: Riggs on August 03, 2010, 09:30:26 PM
X10 will always be a first choice becuase it is easy just plug in select a channel and done, it has been the home automation standed since 1975 and there is loads of moduls for it and all different ways you can mod it, it is a cheap mans market but what is wrong with cheap we all start some where, and anyway i thought Linux was about open source why support proprietary Zwave more than the open X10
Title: Re: X10 CM19A
Post by: tschak909 on August 03, 2010, 09:32:58 PM
it's also a flaming piece of shit from a design standpoint with endless design flaws, and crazy workarounds, not to mention no introspection like ZWave or some of the other home automation busses....

...but that's all you'll hear from me on the subject. I mean, what do I know? I only know all of the standards intimately...

-Thom
Title: Re: X10 CM19A
Post by: Riggs on August 03, 2010, 09:46:12 PM
No one is saying anything about your knowledge Thom, or that Zwave is not better even I know it is way better than X10, but from a customer stand point it is nice to be able to have a choice to spend say $45 on just a Zwave 2 way dimmer switch or $49 for software a controller module 4x appliance modules and a IR blaster.

And if i did want to spend the money i would go for Insteon
Title: Re: X10 CM19A
Post by: rperre on August 04, 2010, 04:05:34 AM
Ordered the CM19A and will make a device template when i get it (pnp ofcourse :) I should be able to use the CM15A stuff as it is a very similar device.

They both use the same protocol for wireless, the only difference is that you can do both wireless and over the powerline signals with the CM15A, the CM19A is only wireless, I already have 2 or 3 751 which will go around the house for reliability.

If i can get this to work nicely i will start expanding with motion sensors and cameras.... sweet

Richard
Title: Re: X10 CM19A
Post by: Riggs on August 04, 2010, 05:01:21 AM
I hope you have better look than i did getting the X10 stuff to work, if you read this thread from page 1 you will see were i got, and there is also this http://forum.linuxmce.org/index.php?topic=5449.0 for the CM15A, .
If you can, keep me updated on how it goes.
Title: Re: X10 CM19A
Post by: joerod on August 24, 2010, 04:56:06 PM
I really liked where this thread was going, and the insight it gave me in template creation and ruby programming.  I ordered a few x10 stuff and I'm going to be playing around with it once it gets here (about a week). 

Please post updates on the what you've done rperre.
Title: Re: X10 CM19A
Post by: DragonK on August 24, 2010, 08:57:45 PM
Quote from: rperre on August 04, 2010, 04:05:34 AM
Ordered the CM19A and will make a device template when i get it (pnp ofcourse :) I should be able to use the CM15A stuff as it is a very similar device.

They both use the same protocol for wireless, the only difference is that you can do both wireless and over the powerline signals with the CM15A, the CM19A is only wireless, I already have 2 or 3 751 which will go around the house for reliability.

If i can get this to work nicely i will start expanding with motion sensors and cameras.... sweet

Richard

Hi Richard,
I've ordered a CM11A, but I would get a CM19A if you think its worth it? Would it be a better option than the CM11A?
Else the only reason why I would get the CM19A is to help test.
I'm new to Z-wave and X10 so I want to learn.

KArel
Title: Re: X10 CM19A
Post by: rperre on August 24, 2010, 10:18:49 PM
I currently have a device driver that works with the CM19A (Based on a driver i found on the net :) and i'm creating a linuxmce device as we speak, this is going a little slower because i have to learn the exact steps and want to make it work PnP (which is my goal).

If i get any closer to starting to test i'll post my results.

Richard

Title: Re: X10 CM19A
Post by: joerod on August 25, 2010, 12:18:04 AM
I ordered a CM15A(USB) which I believe replaces the CM11A(serial) and also includes wireless transmition and the 11A doesn't.  I had to order it with the software to receive a discount and it came to a total of $29.  I understand that the difference between the CM15A and CM19A is that the 19A only does wireless and you'd need another module to go from wireless to wired. 

From what I understand the 11a and 15a are already plug and play ( I'll be testing that next week ) and the 19a is like less that $10 online.

It sounds like the prices on these products are great and since X10 has been aroud a while there are people around here that have it and don't even know they have it (cause it doesn't work and they forgot how to configure it).  Giving this X10 products a new look with linuxmce sounds pretty cool, so I hope to add to the wiki / forums as much as I can with info on how to get it to work.
Title: Re: X10 CM19A
Post by: rperre on August 25, 2010, 03:39:38 AM
Just for reference:

CM11A is pc interface to powerline only
CM15A is pc interface to powerline PLUS wireless signals (RF)
CM19A is wireless signals (RF) only (you'll need a 751 or other to convert to powerline signals)

Richard
Title: Re: X10 CM19A
Post by: DragonK on August 25, 2010, 07:54:29 AM
Richard,

So the CM15A would be the one to go for? But if u have a limited budget it would be the CM19A?
Cant wait for mine to arrive. New toys to play with....  ;D

Karel
Title: Re: X10 CM19A
Post by: Marie.O on August 25, 2010, 08:18:45 AM
If you have a limited budget, you don't get toys, but stuff that works. And sometime investing more is a more sound decision, than buying cheaper toys.
Title: Re: X10 CM19A
Post by: Riggs on August 26, 2010, 07:22:17 PM
Well I can tell you all my CM15A is working no probs, I have to MS16A sensors and they bnoth work on LMCE.
The AVWizard will not detect the CM15A it seems like it is only setup to detect the Zwave stuff, so you will need to create you own scenarios, I for one can get the lights to turn off when I play Hulu, but I can't get them to come back on when I stop the media, I have tried the responed to events wizard but it that will not work for me at all i think there is a bug in there I can't find.

I will say that some times if i set the alarm it will prompt me to wait for the sensors to clear.
Title: Re: X10 CM19A
Post by: valent on December 19, 2010, 09:53:59 PM
Do latest LinuxMCE snapshots support CM19A out of the box, or should I buy CM11 and be a little more patient for CM19A?
Title: Re: X10 CM19A
Post by: karelvdm on December 20, 2010, 07:49:52 AM
Valent,

CM15Ais a better option and is allready supported.

Karel
Title: Re: X10 CM19A
Post by: valent on December 20, 2010, 09:08:27 AM
Quote from: karelvdm on December 20, 2010, 07:49:52 AM
Valent,

CM15Ais a better option and is allready supported.

Karel

Thank you!

CM15A wasn't listed in X10 devices in WIKI, just as an tutorial article. I added missing categories so now you can see CM15A on WIKI:
http://wiki.linuxmce.org/index.php/Category:X10

Are there some other X10 devices that you know that are working but aren't listed in the X10 wiki page? We can work together to fix and create missing X10 pages so WIKI becomes more usable also for others.

Cheers,
Valent.
Title: Re: X10 CM19A
Post by: DragonK on December 20, 2010, 02:54:32 PM
Quote from: karelvdm on December 20, 2010, 07:49:52 AM
Valent,

CM15Ais a better option and is allready supported.

Karel

Valent,

Looks like I subconciosly logged in as the first account that I originally created.......  ;D I forgot the password and the email adres i used then isnt working anymore. So I couldn't retrieve my password. Hari could delete that account karelvdm. Back to the topic.

Currently I have;
CM11SA
3x PLC-R2263E to control lights
1x PLC-R2268HE for fluorescent light
1x TM13SA for RF signal communication for Motion sensors
2x MS13E2 Motion sensor
1x UM7206 this is a universal module that acst as a relay/dry contact switch. Controlling my electric/automated gate.
The "SA" behind the CM11SA and TM13SA is just indication that its suitable for the South African market. 220V

Karel
Title: Re: X10 CM19A
Post by: valent on December 21, 2010, 11:16:43 AM
Karel this information is pure gold! Thank you for this info.

I added one South African X10 shop to our wiki:
http://wiki.linuxmce.org/index.php/Where_to_Buy#Africa

If you know some more shops please add them on the WIKI.

Also it would be very helpful for others if you could help edit WIKI and add X10 have on your WIKI page and also to add any X10 serial and USB controllers that you know that work ok with LinuxMCE.

Cheers from Croatia,
Valent.
Title: Re: X10 CM19A
Post by: tekoholic on October 13, 2011, 03:26:58 AM
Just wanted to check on status for support of the CM19A, or any developments still in progress?

I ordered a CM15A, and they sent me a CM19A / TM751 combo instead, claiming they were out of stock on the 15a, and saying that this combo was equal or better (yeah, sure it is...).

I've chatted with them, as well as called them up about it, and they've promised to send me the 15a as soon as it's back in stock, but it sounded like hot air.

In the meantime, I'm stuck with this 19a, so I was just hopin'...
Title: Re: X10 CM19A
Post by: Techstyle on October 13, 2011, 03:42:29 AM
My CM15A worked 3 months ago with 0810, we are moving so it is in a box .

I have some TM751's and they work also
Title: Re: X10 CM19A
Post by: rchamp on June 26, 2012, 11:29:39 PM
I know this thread is a little old, but is still relevant. Is the CM19a supported now?

or should i stick with getting a CM15a? Main reason i ask is my core doesn't have a serial port, meaning I would need to install a PCI card...

Title: Re: X10 CM19A
Post by: tschak909 on June 27, 2012, 01:12:32 AM
Honestly, if you have a choice, I would recommend ditching X-10 entirely, and at least going Z-Wave or Insteon.

The CM19 is not supported, as nobody has written code for it. Feel free to do so if you wish.

-Thom
Title: Re: X10 CM19A
Post by: mkbrown69 on June 27, 2012, 03:57:50 AM
Mochad <http://mochad.sourceforge.net/> is a good project to use to create a driver.  From the wiki,

Everything sent by mochad appears on netcat standard output. In the simplest use case, mochad/netcat can be used to see X10 PL and RF activity. For example, run mochad on one host with a CM15A(CM19a) then connect to it using netcat from a netbook. Walk around with various X10 RF remote controls and the netbook to see which remotes work from various locations.

<http://sourceforge.net/apps/mediawiki/mochad/index.php?title=Main_Page>

I'm using it with Misterhouse right now, and would need to port that to LMCE.  I'm using it with X10 RF keypads to trigger scenes, and to send commands to devices behind Arc Fault Breakers (haven't converted everything to Insteon yet. 

Thom,  what would be the best method to implement a driver using mochad, given that netcat is normally used to send and receive data from mochad (which then handles the interaction with the CM15/19a)?

Thanks!

/Mike
Title: Re: X10 CM19A
Post by: tschak909 on June 27, 2012, 04:53:59 AM
The most correct approach for mochad is to wrap the C in the C++ provided by our DCE driver.

If you look on the wiki, under Developing a DCE Device, you'll see an article detailing how to set things up so that this can be done, as well as an explanation of the device template, its parameters, etc.

At the other end of the spectrum, would be a GSD device, that launches mochad, and talks to it via its pipe.

-Thom
Title: Re: X10 CM19A
Post by: Techstyle on July 04, 2012, 05:24:28 PM
Quote from: rchamp on June 26, 2012, 11:29:39 PM
I know this thread is a little old, but is still relevant. Is the CM19a supported now?

or should i stick with getting a CM15a? Main reason i ask is my core doesn't have a serial port, meaning I would need to install a PCI card...



my CM15a is USB?
Title: Re: X10 CM19A
Post by: mkbrown69 on July 06, 2012, 03:51:48 AM
Quote from: tschak909 on June 27, 2012, 04:53:59 AM
The most correct approach for mochad is to wrap the C in the C++ provided by our DCE driver.
-Thom

Thom, if I'm understanding you correctly, you're saying it would be best to take the mochad C source code functions, and put those into the C++ functions provided by the DCE driver, correct?  Or are you meaning to wrap the binary like the General Info plugin wraps the mailx binary?  I'm not a C programmer by any stretch of the imagination, so I'm just looking to clarify my understanding of which direction you're pointing me in ;-)

Thanks!

/Mike
Title: Re: X10 CM19A
Post by: tschak909 on July 06, 2012, 07:50:30 AM
I am referring to wrapping the C functions into the C++ driver. This would minimize the dependencies needed, although feel free to implement in whatever fashion you feel is most comfortable.

-Thom
Title: Re: X10 CM19A
Post by: mkbrown69 on July 09, 2012, 06:14:44 PM
Thom,

Mochad is GPL v3.  Is there any issue with rolling it's code into a DCE device driver, which I think is GPL v2?  I plan on contacting the author of Mochad as well, to see if he has any issues with rolling it into LMCE.

If all's good there, I'll likely implement it as a C++ driver, and as a GSD.  It'll give me some experience with both, and there's a possible use case of the GSD with a remote mochad instance running on another computer/embedded device.

Would it be sufficient for me to set up a chrooted dev environment, or do you recommend a separate development environment (VM).  I'm not running production workload on my LMCE instance at this point in time, so I'm not overly concerned about it.

Thanks for your time!

/Mike

Title: Re: X10 CM19A
Post by: tschak909 on July 09, 2012, 07:30:07 PM
There are no issues with integration GPLv2 and GPLv3 code in our case, as we do not touch any of the additional clauses that GPLv3 provides.

As for a dev environment, you can do either. There are no show stoppers with either approach.

-Thom
Title: Re: X10 CM19A
Post by: rchamp on July 09, 2012, 08:39:45 PM
main reason i was considering x10 was because of price. avg price of a wall module $20 USD whereas z-wave or insteon is ~$40-60 USD
Title: Re: X10 CM19A
Post by: tschak909 on July 09, 2012, 09:55:20 PM
I've said this several times in the past, you get what you pay for.

X-10 is cheap precisely because there are faster; more reliable options out there. Z-Wave is more expensive, yes, but you get:

(1) confirmation that commands or events sent were sent correctly, if not, the originating device tries again.
(2) faster data transmission rate, even the oldest Z-Wave revision communicates at 9,600 bits per second, opposed to 150 bits per second over X-10. This becomes more noticeable as larger scenarios trigger more devices.
(3) X-10 is _very_ susceptible to transient disruptions on the power line. A refrigerator, or a washer/dryer can literally cause X-10 devices to spontaneously turn on/off. It requires literally a phase coupler and a filter to try and mitigate the problems. Z-Wave side steps this problem entirely, by not signalling over the mains, and INSTEON deals with this, by advanced error correction techniques. KNX, on the other hand, normally sends these signals on its own wiring (although RF and Powerline options are available there as well.)

-Thom