Please login or register.

Login with username, password and session length
Pages: [1] 2

Author Topic: CM11A Debugging  (Read 6107 times)

prlaba

  • Newbie
  • Helpful Post Rating: 0
  • Posts: 4
CM11A Debugging
« on: October 04, 2016, 11:10:51 PM »

Sorry if there's another topic covering the AHP and the CM11A; if there is I couldn't find it.

I'm a longtime X10 user.  For several years I successfully controlled my X-10 devices (about 30 of them) using a PowerLinc 1132u controller and SmartHome Manager software.

Recently my 1132u PLC died.  When I was unable to find a used one at any reasonable price, I decided to try to resurrect my old CM11A controller and see if I could get it working with AHP 3.013.  I might add that I'm running AHP on Windows 10 Pro 64-bit.

I had no trouble installing and configuring AHP on my PC.  Other than initially asking me to register and complaining periodically that no interface was connected (I was awaiting a USB-to-Serial adapter I had ordered), it seemed to work just fine.  I was able to define all of my devices, timers and macros with no difficulty.

I finally received my USB-to-Serial adapter today.  When I plugged the CM11A + adapter into a USB port Windows found the COM device and installed its driver (the adapter I bought uses an FTDI chip; Windows has a driver for that chip).  From Device Manager I could see the device, configured as COM3.

Next I restarted AHP, went into the 'CM11 Configuration...' menu and changed the COM port from  'Disabled' to 'COM3'.  At that point the little 'no interface connected' icon disappeared and AHP stopped complaining about no interface connected.  But I was surprised to find there wasn't an icon or any visual indication that it was connected to a CM11A and able to communicate with it.  I discovered that even if I disconnected the CM11A from my PC, AHP would not complain that it had lost its connection.  Apparently, once you go into the 'CM11A Configuration...' menu and assign *any* valid COM port number, even the wrong one, AHP will happily behave as if it's connected to the CM11A.

I then tried turning on and off a few lights in the room I was in.  Nothing.  I verified that I had correctly identified the lights' devices as 'Older Lamps (No SoftStart)', as some people said that was necessary.  I then tried turning some lamps in other rooms on and off.  Still nothing.  I tried exiting and restarting AHP a few times, with no success.  Then, suddenly, a couple of lamps responded to my On/Off commands.  Then, just as suddenly, they stopped responding.  Noise?  I tried plugging the CM11A into an outlet farther away from my PC.  No difference.

Then I got suspicious that maybe my CM11A wasn't really working at all.  I tried the 'Download Timers and Macros' command.  When I did that, an animated 'Downloading' icon appeared on the status bar, indicating that AHP was indeed communicating with the CM11A.  But after 5 minutes of no change I became suspicious that AHP maybe wasn't actually communicating with the CM11A.  I exited and restarted AHP, this time trying the 'Clear Interface Memory' command.  Again, the animated 'Download'ing' icon appeared, but it's been running now for more than 20 minutes.

Are there other ways within AHP to know that AHP is communicating correctly with my CM11A?  The lack of status makes it difficult for me to know what's going on.

That got me thinking: Are there other COM settings, like baud rate, stop bits, parity, flow control, etc., needed to match AHP's settings?  I couldn't find any AHP menus to change these settings, nor could I find any information online about AHP's COM settings for the CM11A other than the port number itself.

I then tried using the Activity Monitor so I could see what was being transmitted by the CM11A when I tried turning a device on and off.  What I saw was even more puzzling.  The activity monitor continuously listed lines like this:

141    10/4/2016  10:09:23 PM    Transmit       B On (Side Door Wall Light)

Am I correct in reading this to mean the CM11A is continuously transmitting an X-10 'B On' code?  And if so, why?  When I turn a device on or off from within AHP, I do not see the X-10 command(s) being sent in the activity monitor.  Is that another indication that AHP is not communicating correctly with the CM11A?

So at this point I'm not sure if the CM11A is working correctly, or that AHP is communicating with it correctly.  I can't seem to control any of my devices from within AHP, nor can I download my timers and macros to the CM11A.  Furthermore, the activity monitor seems to indicate that the CM11A is transmitting a continuous stream of 'B On' commands.

I even created a new ahx file with only a single A1 lamp module defined. I couldn't turn my A1 lamp on or off from AHP, and the activity monitor showed the CM11A continuously (once every 1-2 seconds) transmitting an 'A Off' code.  Bizarre.

All ideas and suggestions welcome!
Logged

Brian H

  • Community Organizer
  • Hero Member
  • ***
  • Helpful Post Rating: 305
  • Posts: 13259
Re: CM11A Debugging
« Reply #1 on: October 05, 2016, 06:10:20 AM »

Glad you found us. I remember corresponding with you on the Smarthome Forums. I am forum member BLH there.

Not all USB to Serial Port adapters work with a CM11A.
The CM11A uses the RI (Ring Indicate) signal for some functions. If your adapter does not support it. The CM11A may not work.
The Protocol paper says 4,800 Baud Rate, 8 Bits, 1 Stop Bit, No parity.

If you have a bad CM11A {I would look at all other possibilities first}. The X10 Shop bought out a production run of the CM11A interfaces and still has new unused ones.
http://www.thex10shop.com/product/x10-genuine-cm11a-activehome-serial-computer-interface

Though I would go for a CM15A if a new one was needed.

I just did a test. AHP set to a Serial Port CM11A with no interface connected. AHP was happy and did show commands sent in the Activity Monitor. Even though no interface was there.

Also the CM11A support was added to AHP when the CM15A was not available. I don't believe all the bugs where ever worked out. Before X10WTI went belly up.
« Last Edit: October 05, 2016, 06:21:59 AM by Brian H »
Logged

dhouston

  • Advanced Member
  • Hero Member
  • ******
  • Helpful Post Rating: 37
  • Posts: 2547
    • davehouston.org
Re: CM11A Debugging
« Reply #2 on: October 05, 2016, 01:12:04 PM »

Here's a link to the CM11A Communication Protocol.
http://wanderingsamurai.net/electronics/cm11a-x10-protocol-document

You do need to set the Com Port to match the fixed specs of the CM11A. See Section 2 of the above linked document.

While Brian is correct that USB-Serial adapters vary in handling of 'handshake' signals, I think RI is only needed for macros stored in the PC. And, IIRC, not all PCs handled RI (it was intended to wake a sleeping PC prior to sending data). See Section 6 of the above linked document. Jeff Volp may have more expertise in this area.
Logged
This message was composed entirely from recycled letters of the alphabet using only renewable, caffeinated energy sources.
No twees, wabbits, chimps or whales died in the process.
https://www.laser.com/dhouston

Brian H

  • Community Organizer
  • Hero Member
  • ***
  • Helpful Post Rating: 305
  • Posts: 13259
Re: CM11A Debugging
« Reply #3 on: October 05, 2016, 01:43:14 PM »

Just noticed.
Is the 3.013 the version of AHP you are running?
You may want to see if there is a way to get 3.318 the last revision.
There where some CM11A fixes in the latest revisions.
http://kbase.x10.com/wiki/ActiveHome_Pro_Software_Revision_History
« Last Edit: October 05, 2016, 03:46:18 PM by Brian H »
Logged

dhouston

  • Advanced Member
  • Hero Member
  • ******
  • Helpful Post Rating: 37
  • Posts: 2547
    • davehouston.org
Re: CM11A Debugging
« Reply #4 on: October 05, 2016, 05:31:32 PM »

A bit more detail. You need to set the Com Port parameters within Windows Control Panel, Device Manager.

This may also be a factor.
http://www.techrepublic.com/article/ftdi-uses-windows-update-to-disable-devices-using-counterfeit-chips/
I believe other chipmakers have done similar things.
Logged
This message was composed entirely from recycled letters of the alphabet using only renewable, caffeinated energy sources.
No twees, wabbits, chimps or whales died in the process.
https://www.laser.com/dhouston

JeffVolp

  • Community Organizer
  • Hero Member
  • ***
  • Helpful Post Rating: 122
  • Posts: 2285
    • XTB Home Page
Re: CM11A Debugging
« Reply #5 on: October 06, 2016, 09:29:27 AM »

While Brian is correct that USB-Serial adapters vary in handling of 'handshake' signals, I think RI is only needed for macros stored in the PC. And, IIRC, not all PCs handled RI (it was intended to wake a sleeping PC prior to sending data). See Section 6 of the above linked document. Jeff Volp may have more expertise in this area.

Yes, RI is used to wake up a sleeping PC.  Back when I designed the XTB-232, I initially had the polarity of the RI wrong.  That seemed to work fine until someone tried using it with XTension on a Mac (if I recall correctly).  We identified the polarity problem, and it worked fine when that was flipped.  So some automation programs may actually use the RI as part of the normal communication process.

Jeff
Logged
X-10 automation since the BSR days

dhouston

  • Advanced Member
  • Hero Member
  • ******
  • Helpful Post Rating: 37
  • Posts: 2547
    • davehouston.org
Re: CM11A Debugging
« Reply #6 on: October 06, 2016, 11:37:01 AM »

It's been several years since I had extensive 'hands-on' but I recall that few USB-Serial converters handled all of the signals used by PC Com Ports. I don't recall ever seeing one that handled RI. I recently came across one that did not handle DTR which is used for Reset by most Atmel based devices like the Arduino.
Logged
This message was composed entirely from recycled letters of the alphabet using only renewable, caffeinated energy sources.
No twees, wabbits, chimps or whales died in the process.
https://www.laser.com/dhouston

Alan V

  • Hero Member
  • *****
  • Helpful Post Rating: 8
  • Posts: 171
Re: CM11A Debugging
« Reply #7 on: October 06, 2016, 11:43:32 AM »

I believe that the Olimex CH340 USB to serial bridge lets you control RI.
Logged

dhouston

  • Advanced Member
  • Hero Member
  • ******
  • Helpful Post Rating: 37
  • Posts: 2547
    • davehouston.org
Re: CM11A Debugging
« Reply #8 on: October 06, 2016, 04:38:49 PM »

I believe that the Olimex CH340 USB to serial bridge lets you control RI.
Do you have a link? While the CH340G chip supports RTS, DTR, DCD, RI, DSR and CTS not all adapters based on it support all the above. The few adapters using it that I've seen so far also tend to be DIY models intended for breadboards.

I have one of these...
https://www.tindie.com/products/blkbox/ch340g-basic-for-arduino-pro-mini-ftdi-replace/
which claims...
Quote
Standard FTDI Basic 6-pin interface. (GND / CTS / VCC / TXD / RXD / DTR)

But, at this point, I'm still unconvinced that RI explains what the OP is seeing. I suspect he needs to set the Com Port parameters in Device Manager as well as update the X10 software.
« Last Edit: October 06, 2016, 04:57:12 PM by dhouston »
Logged
This message was composed entirely from recycled letters of the alphabet using only renewable, caffeinated energy sources.
No twees, wabbits, chimps or whales died in the process.
https://www.laser.com/dhouston

Alan V

  • Hero Member
  • *****
  • Helpful Post Rating: 8
  • Posts: 171
Logged

dhouston

  • Advanced Member
  • Hero Member
  • ******
  • Helpful Post Rating: 37
  • Posts: 2547
    • davehouston.org
Re: CM11A Debugging
« Reply #10 on: October 06, 2016, 05:36:19 PM »

That's just the datasheet for the various versions of the CH340 chip. While it shows some reference designs, those features may or may not show up in actual final product USB-Serial adapter hardware. The only Olimex CH340 hardware I can find...
https://www.olimex.com/Products/Breadboarding/BB-CH340T/
does not handle the handshake signals, utilizing only Vdd, Tx, Rx & GND.
« Last Edit: October 06, 2016, 08:42:10 PM by dhouston »
Logged
This message was composed entirely from recycled letters of the alphabet using only renewable, caffeinated energy sources.
No twees, wabbits, chimps or whales died in the process.
https://www.laser.com/dhouston

Alan V

  • Hero Member
  • *****
  • Helpful Post Rating: 8
  • Posts: 171
Re: CM11A Debugging
« Reply #11 on: October 06, 2016, 11:45:38 PM »

I have several boards populated with the CH340G version. The data sheet for that chip shows that RI is on pin 11.
Logged

Brian H

  • Community Organizer
  • Hero Member
  • ***
  • Helpful Post Rating: 305
  • Posts: 13259
Re: CM11A Debugging
« Reply #12 on: October 07, 2016, 06:10:15 AM »

One more thing you may want to look at.
Make sure the clock is set in the CM11A. If not I believe it keeps requesting the clock to be set and will do nothing until it is set.
Logged

prlaba

  • Newbie
  • Helpful Post Rating: 0
  • Posts: 4
Re: CM11A Debugging
« Reply #13 on: October 08, 2016, 11:16:16 PM »

Thanks for the great info and suggestions.  I have some 'better' news to report.  Not great, but better.

Since I have a bunch of PCs here at home running Windows 10, I decided to try moving my AHP/CM11A setup to another PC, hoping that would give better, or at least different, results. 

I installed the serial-to-USB adapter and AHP on a Dell system running Windows 10 Pro 64-bit with no problems.  When I changed the CM11A's configuration from 'Disabled' to 'COM3', the little 'no interface' icon disappeared, indicating AHP was able to see and communicate with the CM11A.  I then opened the Hardware Configuration windows to init the CM11A's clock and load the dusk/dawn table for my location.  When I clicked 'Update Interface', the configuration window disappeared immediately, indicating the information was downloaded correctly to the CM11A.  I then went ahead and downloaded the sample macros.  For the very first time a progress bar appeared on the  status bar for about a second, before it and the downloading icon disappeared.  This looked promising, much better than the problems I saw on my own PC (and reported in my earlier post).

I then played around with the typical AHP stuff -- creating my own rooms and devices and verifying that I could turn devices on and off through the menus and icons.  Everything I tried worked exactly as expected.  The activity monitor was especially handy in confirming which commands were being transmitted by the CM11A.

I then created some macros to turn on and off multiple devices.  I created two macros, one to turn on my E1 and E2 lights ('E Lights On'), the other to turn off the same lights ('E Lights Off').  I assigned the first macro the trigger E8 On, the second E8 Off.  I downloaded both macros to the CM11A, with no problems reported.  When I triggered the two macros from within AHP (by clicking their 'Run Macro' buttons), they worked as expected, as confirmed in the activity monitor.  But when I triggered them via the E8 on and off buttons on a wireless remote, I got very strange results.  When I pressed the E8 On button, the activity monitor showed the CM11A receiving the commands E8, EOn (as expected) but then the CM11A transmitting these four commands: A1, AOn, A2, AOn.  For some reason, the CM11A transmitted X-10 commands with incorrect X-10 addresses -- each address contained the device's correct unit code, but always the A house code instead of the device's defined house code.  I walked around and confirmed that my  E1 and E2 lamps were off, while my A1 and A2 lamps were now on (so the activity monitor wasn't lying).  Even more strange, when I pressed the E8 Off button, the activity monitor showed the CM11A receiving the commands E8, EOff, then transmitting the correct commands E1, EOff, E2, EOff. 

To see if there might be something 'special' about the E house code, I redefined the same two macros using house codes F1 and F2 instead of E1 and E2.  I got the same strange results as before: pressing the E8 On button on my remote caused the CM11A to transmit commands using the A house code instead of F; pressing the E8 Off button caused the CM11A to transmit commands with the correct F house codes.

To shed more light on why the 'E Lights On' macro failed but the 'E Lights Off' macro worked, I tried this experiment: I created a new macro, triggered by E7 On, to turn *on* the E1 lamp and turn *off* the E2 lamp.  When I pressed the E7 On button on my remote, the CM11A received the commands E7, EOn, and transmitted these commands: A1, AOn, E2, EOff.  In other words, turning *on* the E1 lamp from within the macro caused the CM11A to transmit an X-10 address with the wrong A house code, but turning *off* the E1 lamp transmitted an address with the correct E house code.

On a hunch I unchecked the macros' 'Store in interface' checkbox and triggered the same macros again from my remote.  This time the activity log showed the correct house codes in all cases.  This suggested the problem was within the CM11A; running the macro from within AHP meant AHP was transmitting the necessary commands through the CM11A, essentially the same as pressing the 'Run Macro' button in AHP to run the macro (which works fine).

So for some reason, when I create a macro that turns one or more devices *on* and store that macro in the CM11A, triggering the macro externally (not from within AHP) causes the CM11A to generate X-10 addresses for those devices using A house codes, regardless of the device's actual house code.   However, if the macro turns any devices *off*, the transmitted addresses contain the devices' correct house codes .  Finally, if I uncheck the macros' 'Store in interface' checkbox (so the macros are run by AHP instead of the CM11A), triggering the macro externally transmits addresses with the correct house codes.

By the way, when I created timers that ran these same macros, I got the same strange results.

What's going on?  Although my tests point to a problem within the CM11A, I'm having a hard time believing a hardware problem would cause the CM11A to 'almost' work.  And if it were a downloading problem between AHP and the CM11A, I would again expect the CM11A to behave much worse than it is.  Finally, this is clearly not a X-10 noise problem, since the activity monitor is reporting incorrect house codes being transmitted by the CM11A, regardless of what X-10 commands might be received at the other end of the transmission.

Whatever this bug is, it's a 'deal-breaker' for me because I need to have the CM11A located in a different room from my PC.  Besides, I don't want to have my PC running 24/7.

Has anyone ever seen or heard of such a problem?  Any idea why this might be happening?  More important, any suggestions on how to fix it or work around it?

Thanks.
Logged

Brian H

  • Community Organizer
  • Hero Member
  • ***
  • Helpful Post Rating: 305
  • Posts: 13259
Re: CM11A Debugging
« Reply #14 on: October 09, 2016, 10:00:18 AM »

Have you updated AHP to the last version 3.318?
Earlier version that had CM11A support in them had added issues.
Logged
Pages: [1] 2
 

X10.com | About X10 | X10 Security Systems | Cameras| Package Deals
© Copyright 2014-2016 X10.com All rights reserved.