I'm not sure if anyone has resolved this but I'm trying to decode simple dim commands being sent from the ti103 and received by the CM15A. If I send 1 DIM ($>28001N01ND40ND40F8# or N1 NDIM - note these are continous dims for a single command) I see:
5a020086
5a03020b84
As far as I can tell (no X10 doc still) the first line is 5A (received from the power line) 02 (2 bytes follow) 00 (it's an address) and 86 (X10 address - N1). The second line is 5A (power line), 03 (3 bytes follow), 02 (either 2 more bytes of an ID for DIM/BRIGHT), 0B (Dim % - still need to figure out the math) and 84 (NDIM).
I've also sent multiple dims:
1 DIM = 5a03020b84
2 DIM = 5a03020b84
3 DIM = 5a03021684
4 DIM = 5a03022184
5 DIM = 5a03022c84
Not sure what the math is on these. I'm guessing value/256 * 100 but that's just a guess. Any ideas?
It depends on the receiver (and manufacturer) but I worked out the math for an LM465 using a 100W lamp and my Kill A Watt meter. See...
formatting link
See the CM11A documentation for an explanation of the bytes from the CM15A. The third byte (02 in all but your first example) is a bit map that indicates which of the following bytes are addresses and which are functions.
All of my switches are Insteon ToggleLinc relay types (controlling old fluorescents) so I'm unable to test this for an X-10 dimmer switch. You would have to temporarily wire the dimmer switch to an outlet and then use the Kill A Watt and 100W lamp in the outlet.
Note that the CM11A documentation says 22 DIMs equals 100% but the lamp module never goes to 100%. The maximum is 96%. There's no measureable difference between 21 & 22 contiguous steps using both the Kill A Watt and a true RMS voltmeter.
Earlier versions of the CM11A firmware output after each dim/bright command rather than sending the cumulative total. I haven't confirmed this but I think there was no way to accurately estimate the actual level because you couldn't tell whether the dim/brights were contiguous.
Charles Sullivan has indicated he sees a difference depending on whether the DIM starts on a ZC rising edge or falling edge but I haven't verified that. (It is on my lengthy ToDo list.)
It looks like the TI103 promotes 1 DIM to 2 DIM to avoid micro-steps. The numbers in parentheses are the values calculated based on the Kill A Watt measurements.
Dang, you solve that one! This is good, so it goes:
5a - A 'What' (RF, Power Line, Macro, ACK, etc)
03 - Byte count
02 - ID (00 X10 Addr, 01 X10 Command, 02 X10 Dim/Bright, 08 Extended code?)
0b - reported intensity of Dim/Bright
84 - House Code/Function code
I saw the 210 in the CM11A documentation. With the TI103 22 continuous dims reports back 0xD2 intensity as does 24 dims.
I've not seen anything but cumulative with the CM15A. I don't really need accurate just a general 'what it means'. This is so Mr. House can use the CM15A.
Dave thanks this goes a long way towards getting the CM15A up and running with Mr. House. Next up is translating:
5a0508313f0667
The CM11A and Mr. House reports it as brighten A 1 to 100% (I think it's a preset bright command). I have to sit down and decode the middle 2 bytes. Here's what I've got so far:
5A - Power Lince
05 - 5 bytes
08 - Extended
31 - ASCII 1
3f -
06 -
67 - HC = A FC = Extended code
I'll have to sit down with the xtc797 doc to see if I can decode this.
Look at XTC798.TXT on my webpage. It's just the X-10 DOC reformatted to make it readable.
formatting link
N1 Extended Dim 63 (100%) gives 5A 05 01 87 06 3F 31 with the CM11A.
It looks like they changed the order of some of the bytes from the CM11A protocol.
One thing that might be worth checking is whether the 11, 22, 33, 44 seen when you convert your first 4 DIM levels to decimal holds for higher DIM levels.
Thanks, that will be very helpful! It looks like the have the following format (using the previous example):
5A - The what (Power line, RF, Macro, etc)
05 - Byte that follow
08 - Bit map type of data that follows
31 - data
3f - data
06 - data
67 - House code (high nibble) key code (low nibble)
The last byte seems to be the House code/Function code or House code/Address code is all the commands such as in the simple a1aoff:
(5a020066) A1 (5a020163) AOff
Easy enough to check, I can run a script adding dims to the end of the command issued. Here's the script:
(T="n1" ; for i in $(seq 1 23); do T="${T}nm"; echo $T; sudo perl ti103.pl $T; sleep 5; done; )
Basically it says run the script 23 time and send the string to the TI103. Each time the script loops it add an 'nm' (N Dim) to the end of the string. This will send from 1 to 23 dims. The output shows up in a Mr. House log. After I've cleaned it up and removed the redundant information (each dim burst is preceded by an N1 (5a020086)). It looks like this:
The numbers you get equal (DIMs-1)*11 through 209. So the CM15A is reporting the actual number of contiguous DIMs, making it much easier to calculate the actual level (using the figures I developed empirically). The small difference between 209 and MAX (210) is approximately what you see with actual measurements. (You can't discern it with the naked eye.)
However, since the LM14A and LM465 respond differently while Smarthome uses
32 levels tends to negate the benefit of knowing the actual number of contiguous DIMs.
This is related to one of the CM11A lock-up causes.
Prior to the LM14A & CM11A, Function 7 was defined as Extended Code but X-10 made nothing that did anything with it. With the LM14A, they converted it to always have the Unit, Data & Code ID follow the House & Function and a CM11A lock-up occurs when it sees the first part without the second following. The first 22 powerline bits are the same as in the older method.
This should be interpreted as follows: 5A Incoming data 05 Bytes that follow 08 Function bitmap 00001000 => 4th byte following (i.e., 67) is a function byte. 31 Extended Type/Function 31 => Extended Preset. 3F Preset value = 0x3F = 63 (scale 0-63) 06 X10 encoded Unit code for Unit 1. 67 Hi = 6 = House code A, Lo = 7 = Extended code
I'm not sure this holds up, an address has a bit map of 00 (binary), a function has a bit map of 01, a dim/bright a bitmap of 11 and then this odd command:
5A 07 15 F2 FE F2 FE F2 FE
We haven't figured out what this is yet. They're bit maped but they don't indicate where the function byte is. That generally seems to be the last byte though I doubt that's true in this command.
If interpreted as I suggested, the F2 would be functions (J On) and the FE would be addresses (J 2). This makes sense if the bytes are reported in reverse order (from the CM11A order) as the Extended Code commands are. But I think you indicated on another occasion that you weren't using housecode J, so who knows. (The CM15A has enough bugs that it wouldn't surprise me if that byte sequence turned out to be just garbage generated by RF pickup.)
What does the CM15A report if you send it several PLC commands in a row with the minimum gap between them, e.g., (A 1), (A On), (A 2), (A Off)? Do you get multiple reports (each beginning with 5A) or a single report?
Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.