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.
Author
Topic: CM11A Debugging (Read 7226 times)