X10 Community Forum
🖥️ActiveHome Pro => SDK => Topic started by: Dee Earley on July 28, 2011, 04:13:40 AM
-
Hello all.
We have a CM15A module here and we're making use of it via the ActiveHome (ahscript) object.
On my computer, when using an RF remote, any RF commands received are forward to the power line which works fine.
When the same unit is plugged into another computer (same ring, same remote, same version sdk 3.0.0.183), the commands are not forwarded.
Having a look around the forum, it suggests setting up the transceived house codes, but they all talk about the ActiveHomePro software itself.
Is there any way to configure this outside of the software and is it machine or CM15 specific?
I've found the settings at HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{001000AF-2DEF-0103-10B6-DC5BA692C858}\X10 but changing them hasn't seemed to have any effect on the operation even after a replug.
Thanks
-
Try reinstalling the SDK.
Is the problem PC running the same OS?
Is the problem PC 64 bit?
-
The latest SDK was reinstalled to confirm everything was up to date and the same on all machines.
All machines are 32-bit and of the machines here, the one that works runs Windows 7, the others are Vista, but the original problem was reported on a Windows 7 machine.
Thanks
-
The CM15A isn't PC specific.
Is AHP loaded on these other PCs as well?
With the CM15A connected and the software you have to receive commands running check to see if X10nets is running.
-
Odd...
AHP (or at least its registry settings) is on one of the failing machines but is NOT installed on my machine or the other failing machine.
I will check my colleagues when I can.
Note that the CM15 does not have a battery.
Would this cause it to get its settings on connection from each PC?
How do we see if it is/is not set to transceive anything?
In all cases, it's the same device code that is being used, and only ahcview runnign to see what's happening.
Thanks
-
Note that the CM15 does not have a battery.
Would this cause it to get its settings on connection from each PC?
Without the battery, the CM15A loses all of its memory when you unplug it.
So, it is resetting the transceived house codes setting when you move it from one machine to another.
Try putting batteries in, and see if that helps.
-
Oh, and x10nets is running on mine and the failing test machine (and is started when I create the scripting object).
Out of interest, what is setting the transceive state and where from?
I've tried adjusting HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{001000AF-2DEF-0103-10B6-DC5BA692C858}\X10\Interface\Ports\HIDTransceiveMask but it had no effect even after replugging.
Thanks again
-
Setting the transceive state is done from AHP, tools /hardware configuration.
-
Thank you for that, but as I'm not use AHP itself (just the ahscript object) why would different machines be behaving differently?
I presume it's being set by the drive/ahscript but where does that get its setting from?
Many thanks
-
Thank you for that, but as I'm not use AHP itself (just the ahscript object) why would different machines be behaving differently?
I presume it's being set by the drive/ahscript but where does that get its setting from?
Many thanks
Those settings need to be set in AHP. If you don't have batteries in your CM15A, and you then unplug it and move it to a new PC, then those settings are lost.
Try putting batteries in it, setting it on the PC with AHP, downloading the configuration to the CM15A, THEN moving it to the other PC.
-
Thanks Noam.
I will be doing that, but it still doesn't explain why my machine (without AHP and never has had AHP) is causing it to transceive but other machines don't....
-
One other thought:
When you are moving the CM15A to the other systems, you are plugging it into different outlets, and possible different circuits in the house.
Have you confirmed that you can send powerline commands from those PCs through the CM15A at each of those locations?
Perhaps it IS working, but the signals aren't getting through due to a long signal path and/or other noise.
-
That is strange as the tranceived house codes are stored in the CM15A and the batteries are not needed.
I did two CM15As.
One I disabled all the house codes tranceived and the other selected B and C only.
Used the store in interface tab on the bottom of the screen.
Disconnected for an hour with no batteries.
Monitored the power line with my 1132CU.
Plugged each into an outlet not even connected to the computer.
One tranceived no house codes and the other B and C only.
I did not test for the Automatic Choice for Tranceived House Codes. So how it acts. I do not know.
-
That is strange as the tranceived house codes are stored in the CM15A and the batteries are not needed.
I did two CM15As.
One I disabled all the house codes tranceived and the other selected B and C only.
Used the store in interface tab on the bottom of the screen.
Disconnected for an hour with no batteries.
Monitored the power line with my 1132CU.
Plugged each into an outlet not even connected to the computer.
One tranceived no house codes and the other B and C only.
I did not test for the Automatic Choice for Tranceived House Codes. So how it acts. I do not know.
Interesting test. So the "transceived house codes" setting is stored in non-volatile memory? That's pretty interesting.
So, now what is your theory about Dee's results?
-
One other thought:
When you are moving the CM15A to the other systems, you are plugging it into different outlets, and possible different circuits in the house.
Have you confirmed that you can send powerline commands from those PCs through the CM15A at each of those locations?
Perhaps it IS working, but the signals aren't getting through due to a long signal path and/or other noise.
We weren't always testing by controlling a physical device.
The initial problem was on one computer where the recvplc command wasn't seen after a recvrf, and the device didn't switch (it did when changing direct from the CM15).
Taking it downstairs (definately a different ring), I WAS seeing the recvplc (but couldn't see the physical device to check).
A quick test on another machine on the downstairs ring, 2 sockets away, DIDN'T see the recvplc.
I assumed (yeah, I know) that that meant it was the CM15 only transceiving when on my PC.
Does it explicitly show a recvplc after it's sent a command or is that just concidence of the wiring?
When I get access to the PC with AHP on it, I will try and see what the CM15 is actually set to.
-
I've just tried forcing it to transceive all house codes and that hasn't had any effect when moving back to the original PC.
I'll try doing a more exhaustive test when I can move all the kit around and have a battery to hand :)
-
Just curious?
You state your testing a CM15A however forum shows your connecting from the UK.
Is this indeed a CM15A(North American version) or CM15E (European version)?
-
Pass, the label says "CM15 PC USB interface".
'tis one of these:
http://www.icode.co.uk/icatcher/cctvshop/cm15pro-x10-computer-interface-and-rf-transceiver-p-501.html
We get them from another UK reseller so I presume they are the European version.
-
Are you using the European or US version of AHP?
-
On the one machine with it installed, I can't tell. All the about says is "ActiveHome Pro with SmartMacros" version 3.226
How can I tell?
-
Okay that's the European version of the CM15
Most here use the North American version which use different frequencies for RF and operate on 110 volt.
The SDK software should work fine for both cm15 versions as programs I and others created work fine for users of the CM15E.
There isn't a setting for transceives in the SDK.
The SDK sees all HC and transceives all unless you code something to ignore some House codes.
I've notice some actions aren't reported with the SDK samples, I assume it is just a mater of coding.
The fact that the device doesn't turn on or off from one machine but does from another indicates (to me) you have a noise issue from the problem PC.
-
Ok, Is the fact that I see the "recvplc" when I send commands purely down to "echo" on the PLC side?
i.e. It's not reporting the fact that IT has sent the plc commands, but it has received back its own commands.
Things make slightly more sense now I think... :)
-
Ok, Is the fact that I see the "recvplc" when I send commands purely down to "echo" on the PLC side?
i.e. It's not reporting the fact that IT has sent the plc commands, but it has received back its own commands.
Things make slightly more sense now I think... :)
Sounds like you got it.
The SDK will report a "recvplc," even for commands it SENDS out over the powerline.
The Activity Monitor in AHP usually reports correctly if it sent a command versus receiving it.