Presentation and application layers

The presentation and application layers define the content of the messages and how they’re interpreted. House codes are represented by specific sequential four-bit patterns, as shown in Table 1-1. Bit 0 is transmitted first, followed by the rest in order. The bit patterns for the codes do not correspond to ASCII codes, which would represent “A” as 1000001, but are unique to the X-10 system.


X-10 key and function codes are represented by the sequential five-bit patterns shown in Table 1-2. You can distinguish key codes from function codes using the last bit, which is zero for key codes and one for function codes. The key codes correspond to what X-10 calls unit codes in most retail documentation.


If you’ve been planning how you’d use these codes as you read, you’ve noticed that you can’t form a complete command in one transmission — that is, you can say things like B12 or B On, but you can’t write a message that says B12 On.What you have to do is send message sequences, such as B12 followed by B On. The requirement to send each message twice with a three-cycle gap between messages results in the final message sequence:

B12 - B12 – B On – B On

This example shows that it takes at least four messages to complete a command, and of course transmission errors can corrupt any of the four. The specific behavior you’ll see if one or more of the messages are corrupted depends on the devices involved, but all the effects are likely to appear as unreliable or erratic operation.

Because the addresses and commands are separate in the protocol, you can combine messages to give more complicated commands. For example, if you wanted to turn on both B3 and B12, you could use the command sequence:

B3 – B3 – B12 - B12 – B On – B On

Many command codes have straightforward meanings; On, Off, and All Lights Off, for example, do just what you’d expect. Status Request commands the addressed unit to respond with Status = on or Status = off if it supports status responses.

Less straightforward are Dim, Bright, Extended Code, Hail Request / Acknowledge, Pre-Set Dim, and Extended Data. Here’s what they do:

Dim, Bright, and Pre-Set Dim — Standard X-10 incandescent lamp dimmers have 16 dimming steps. The standard protocol for dimming to a specific level is to turn the lamp on, then send a dim command pair (which would be two Start code-house codedim sequences back-to-back with no intervening empty cycles) for each dim step. A sequence of 16 pairs should turn the lamp off completely. You can similarly send Off followed by a series of Bright commands to get the same effect.

The requirement to start at full on or full off, then ramp the intensity to reach a known level produces awkward results. The Pre-Set Dim command was intended to address that problem by directing the dimmer to go to a specific level directly. X-10 apparently never made any products that implemented the Pre-Set Dim command, although some others did, so it’s no longer defined in the protocol. (The sequence also violates the requirement that commands have the same house code as the prior address packets, potentially lowering the reliability of the system.) In the most recent documentation, X-10 has re-designated the Pre-Set Dim command code as being “for security messages.” Products using Pre-Set Dim will continue to work, of course, but as products come to market using that command code for security functions, your chances of conflicts go up should you use both categories of device.

Extended Code/Data — You can do a lot more with the X-10 protocol than the basic function code commands in Table 1-2 permit, because the Extended Code and Extended Data function codes let devices send arbitrary information. Standard X-10 devices ignore everything in the message following those function codes up to the next gap (i.e., power line cycles with no tones in either zero crossing), so in theory extended messages can be any length.

In practice, X-10 has defined specific extended message formats. Extended message format 1 follows an Extended Code function, and consists of 4 bits of unit code, 8 bits of data, and 8 bits of command. Five types of interpretation are defined for the data and command bytes:

Type 0: Shutters and Sunshades

Type 1: Sensors

Type 2: Security

Type 3: Control Modules (Dimmers and Appliances)

Type 4: Extended Secure Addressing

Type 5: Extended Secure Addressing for Groups

Nothing prevents you from using your own message formats with Extended Code or Data functions, except that repeaters may not properly echo your messages onto the other power line phases.

The longer messages increase the probability that one X-10 transmission will collide with another, so the xtc798.doc specification adds some access requirements to the protocol. Specifically, it says Extended Code systems must follow specific steps to ensure the power line is not being used by another device, must check for collisions during transmission, and must respond to collisions by terminating the operation and starting over from the state in which it’s verifying the power line is idle.

Hail Request/Acknowledge — A device can send Hail Request to locate X-10 transmitters on the system. Those transmitters are to respond with Hail Acknowledge. The commands are used for other purposes by some equipment, and not implemented by all transmitters.