X10 Community Forum
🖥️ActiveHome Pro => SDK => Topic started by: hkactive on October 20, 2006, 01:11:14 PM
-
I'm kind of confused. Wonder if someone could clear up the documentation on the SDK.
The words "X10 Device Service" are really vague.
The X10 device service keeps track of the status of modules in the system by logging incoming and outgoing commands. You can ask the X10 service the status of any address by using the "queryplc" parameter of the SendAction function.
Is there a log stored on the CM15A and that is what the queryplc command is returning: the data on the log in the CM15A? Because I keep getting correct values for modules that are not 2-way: e.g. LM465, AM466, etc.
Or does queryplc command actually send a query via the CM15A to the actual X10 module: e.g. AM14A. And the AM14A is returning a value to the CM15A. And the CM15A returns that value to the return value of the queryplc command?
The reason I ask, is if I unplug the CM15A and reset it I get false values from the queryplc command.
Hank
-
I think all it's supposed to do is return the status of modules as stored by AHP for sent and received commands, not from polling any modules. If you specifically poll a 2-way module the status signal returned from that module ought to update AHP's record.
-
Thanks, Charles. That's what I was thinking. But wasn't sure.
sendplc address {AllUnitsOff | AllLightsOn | On | Off | Dim | Bright | AllLightsOff | ExtCode | HailRequest | HailAcknowledge | PresetDim1 | PresetDim2 | ExtendedDataTransfer | StatusOn | StatusOff | StatusRequest}
I got the above back in VB6 as a run time error message. So I'm presuming the programmer put in the right format in his error message.
But suppose I had a AM14A (2 way Appliance Module) at House Address E8 and wanted to poll it's status. What would I send?
Finally, figured it out. It's taken me a couple hours to write these few lines.
ActiveHome1.SendAction "sendplc", "e8 StatusRequest"
Using the above works.
What happens is that the above command sends a command to the CM15A to send out a status request to e8. If e8 is the house address of a 2 way module it sends data back to the CM15A. You can pick up both results in the RecvAction event procedure using the following code.
Private Sub ActiveHome1_RecvAction(ByVal bszAction As Variant, _
ByVal bszParm1 As Variant, ByVal bszParm2 As Variant, ByVal bszParm3 As Variant, _
ByVal bszParm4 As Variant, ByVal bszParm5 As Variant, ByVal bszReserved As Variant)
'
Debug.Print bszAction, bszParm1, bszParm2, bszParm3, bszParm4, bszParm5, bszReserved
'
End Sub
But this is what showed up in the Immediate Window when sending the above command:
Immediate
recvplc e8 StatusRequest
recvplc e8 StatusOff
The first response comes from the "sendplc", "e8 StatusRequest" command
But the second response comes from the 2way am14A, not the CM15A.
Well, you got me thinking and experimenting. But this should definitely help someone else out in working with the CM15A and 2way modules.
Regards,
Hank
P.S.
Someone said you wrote this:
but Charles Sullivan once said that the above extended preset dim could also be sent as: sendrawplc 07 67 0E 1F 31
Wonder if you could give a short explanation of those 5 hex values?
-
Someone said you wrote this:
but Charles Sullivan once said that the above extended preset dim could also be sent as: sendrawplc 07 67 0E 1F 31
Wonder if you could give a short explanation of those 5 hex values?
You'll need copies of the X10 powerline protocol and extended code protocol to encode/decode these values in general.
Get them from:
http://software.x10.com/pub/manuals/cm11a_protocol.txt
http://software.x10.com/pub/manuals/xtdcode.pdf
For the above extended code (which are all hexadecimal bytes):
0x07 Extended code follows
0x67 Housecode A (6) | Extended code (7)
0x0E Unit 2
0x1F Extended Preset level 31 (0 to 63 or 0x00 to 0x3F)
0x31 Extended type 3, Extended function 1 (= Set Extended Preset Level)
Note: When an LM14A is polled from the icon in AHP, an extended status request is sent and the module returns an extended status acknowledgment. The AHP Activity Monitor translates the extended preset level in the extended status_ack from the native level 0-63 (0x00-0x3F) to the proportionate level 0-210 (0x00-0xD2) for ordinary lamp dimmers. Unfortunately it also throws away the upper bits of the Level byte which indicate whether or not the bulb is burned out (or turned off). I don't know what happens if you poll with an extended status request (Extended type 3, function 7) from the SDK.
-
> I don't know what happens if you poll with an extended status request (Extended type 3, function 7) from the SDK.
You get back the extended response, which includes the "burned out bulb" bit. I recently added a hook to Misterhouse for this.
-
> I don't know what happens if you poll with an extended status request (Extended type 3, function 7) from the SDK.
You get back the extended response, which includes the "burned out bulb" bit. I recently added a hook to Misterhouse for this.
Hopefully you're using MH's independent code for the CM15A rather than some SDK module.
FYI, while the "burned out bub" bit for the LM14A seems to be fairly reliable, the equivalent "no load" bit in the Extended Status_Ack from the AM14A/PAM21/PAM22 Appliance Module is buggy and _almost always_ indicates a load is connected when it's not. I recently posted to comp.home.automation about this. See: http://groups.google.com/group/comp.home.automation/msg/4cdaa94109b3b766
-
Charles,
I am most assuredly not using the CPAN module. It is not even close to finished. I wrote a brand new treatment with the SDK and it works perfectly. It is a familiar pattern: USB-UIRT was an attempted hack that never got finished. Two days with that SDK and I had everything I wanted. They were using some external app to control Winamp, I switched to the SDK and found I could do all of the extra things that the other program couldn't. The SDK is the way to go unless you want to run everything on Linux. Misterhouse makes it possible to run your X10 processing on a proxy, so there is really no reason to mess with the half-finished (being charitable) CPAN module. They've been hacking on that thing since I first downloaded Misterhouse for my old CM11. Last I heard it was dead in the water.
One problem for those who wish to go download Misterhouse and try all of this stuff: much of it is not available in the public version. I started rewriting the app eight months ago and six months ago some crybaby who manages the source archive whined that my updates were overwhelming him. In danger of losing his self-proclaimed "genius" status, he locked the code down (keeping all of my updates of course.) Misterhouse is now pretty much a time capsule. I did get some helpful users to help merge in scene support a couple of months back, but then I sort of lost interest in the free version. I sent the CM15 treatment to a few key users a month back, but have no idea if or when it will be released. It took those 600+ (really about a half dozen, but they like big numbers) PERL developers six years to get a working CM11 module. I'm the one who finally finished it as I was tired of checksum errors instead of motion signals. (!)
And yeah, the LM14 is the only device I know of that works with the "burned out" bit. I guess the appliance modules don't need to anyway (no bulb.) If you want to track whether an appliance is unplugged, you are out of luck.
-
Charles,
... The SDK is the way to go unless you want to run everything on Linux. ...
David,
Have you found the CM15A SDK to be stable and reliable so far? I'm looking at using it to add CM15A support to my app.
Also, I noticed SDK commands mentioned in this thread (sendrawplc) that don't seem to be in the published docs. Is there a more complete document somewhere of all the commands for the SDK?
Thanks.
-
Hi jmattioni,
CM15A SDK does not seem to support send raw commands. If you want to send raw commands, you should use CM11A or TI103.
-
FYI, while the "burned out bub" bit for the LM14A seems to be fairly reliable, the equivalent "no load" bit in the Extended Status_Ack from the AM14A/PAM21/PAM22 Appliance Module is buggy and _almost always_ indicates a load is connected when it's not. I recently posted to comp.home.automation about this. See: http://groups.google.com/group/comp.home.automation/msg/4cdaa94109b3b766
My experience has been a bit different.
The CM14A use to handle the two-way modules a bit nicer, IMHO, than the CM15A ( for example, a conditional macro could poll a 2-way before evaluating its test). When the CM14A was connected up to a PC running its AH2 software, one would get a pop-up warning you that a burnt out bulb was just detected. I use to get a lot of false pop-ups from my LM14A's. :(
-
FYI, while the "burned out bub" bit for the LM14A seems to be fairly reliable, the equivalent "no load" bit in the Extended Status_Ack from the AM14A/PAM21/PAM22 Appliance Module is buggy and _almost always_ indicates a load is connected when it's not. I recently posted to comp.home.automation about this. See: http://groups.google.com/group/comp.home.automation/msg/4cdaa94109b3b766
My experience has been a bit different.
The CM14A use to handle the two-way modules a bit nicer, IMHO, than the CM15A ( for example, a conditional macro could poll a 2-way before evaluating its test). When the CM14A was connected up to a PC running its AH2 software, one would get a pop-up warning you that a burnt out bulb was just detected. I use to get a lot of false pop-ups from my LM14A's. :(
Walt2,
You have to distinguish between what the LM14A is sending and what ActiveHome is telling you it sent. Note that I've never seen a CM14A nor ever used "AH2", so don't know how good or bad it is/was compared with AH 1.42. I based my conclusions on the raw bytes transmitted by the LM14A and AM14A/PAM22 and received by a CM11A with my Linux software.
I've seen the "burnt out bulb" popup with AH 1.42 but never spent any time checking it's reliability with that program.