New Lighting Protocol

[upstatemike]

X10 (unreliable), UPB (delays), Z-wave (closed system) and Insteon (bugs) all suck. I'm starting to like the idea of hard wired systems.

I have a new lighting protocol that I wanted to run by the folks here to see how much interest there would be before I pitch it to the investors. It is targeted to be simple enough for “Home Depot†consumers and still be robust enough for central automation controller applications. This is a feature description excluding the hardware layer part:

This simplified protocol (I’ll call it Upstate Simple Protocol or USP) is modeled off of X-10 as far as setup and is designed to co-exist in a mixed environment with X-10. Each device has a fixed hardware address similar to Insteon but that address is only used for programming and special Automation Controller applications. For basic automation each switch is assigned a USP address in the same format as X-10. When you install a switch, you will actually assign it a USP address from A1 to P16 just like X-10. In fact, you can do this by using an X-10 Maxi-Controller. Simply hold the top paddle down for 10 seconds to put the switch in programming mode, press the address you want on the Maxi-Controller (say A5 for example) and that’s it. The corresponding USP address, A5, is now programmed into the switch. You can also program an X-10 address into the switch by following the same procedure only you press the lower paddle for 10 seconds to put the switch into X-10 programming mode. You can program a switch to respond to just USP, just X-10, or both. Of course the addresses don’t have to match; A5 for USP and L7 for X-10 for example, would be fine. By using an X-10 controller for basic programming, a user is not forced into a PC interface right off the bat and yet there is no back and forth running around to set up individual links between devices either.

When switches are operated manually they transmit a USP broadcast such as A5 ON (similar to X-10) and will also broadcast the appropriate X-10 command (L7 ON) if an X-10 address has been programmed. The USP broadcast also includes the hardware address of the originating switch. This information is ignored by other switches but is used by automation controllers. Any switch that has the same USP or X-10 address will switch ON (or OFF) in response to the broadcast and will send a status acknowledgement containing their hardware address (not USP or X-10 address) and new state. These acknowledgements are used by automation controllers and ignored by other switches.

Switches also periodically send out status updates to confirm their status to automation controllers. Automation controllers can also poll a device and force it to transmit its status at any time. Since these transmissions use the hardware address and do not contain any USP or X-10 address information, they are ignored by other switches.

Besides the primary USP address, a switch can have several secondary USP addresses. These are used for scenes and switches react to them the same way they do to the primary USP address. The only difference is that these addresses are not broadcast when the switch is operated manually. A secondary or scene address simply uses different ramp rate and level settings to create the scene.

An interesting feature is that ramp rate and level can be set separately for ON and OFF commands. This means each secondary or scene address can define 2 different scenes, one for ON and one for OFF. You can also use this feature with the primary address to define OFF to be a dim level for example, to provide a nightlight for a bathroom or hall. It is also valid to use the Primary USP address for one switch as a secondary scene address for another. Say A5 is the top of the basement stairs and A6 is another light in the basement. Make A5 a secondary address in the other switch and set the ON level to X (no change). The Other light will not go on unless you specifically turn it on but will always go off when you turn off the switch at the top of the stairs.

Another important feature is that right from day one there will be a TW523 translator. This unit will plug into any existing X-10 controller that uses a TW523 (Stargate, HAL, W800RF32A, etc.) and map the X-10 commands to USP commands. This means all of your palmads and hawkeyes will still work with the new protocol. There may even be an option within the translator to select banks of addresses or even go address by address and decide if you want it to be X-10 or USP.

Of course the real fun comes if you use a PC to interact with your switches. The PC interface uses the hardware address in the switches to communicate with them. If you access a switch from a PC you can set every parameter remotely including primary and secondary (scene) USP addresses, X-10 addresses, ramp rates, on and off levels, etc. You can also request status from any switch or send commands to individual devices (via hardware address or USP address) or groups of devices via USP broadcast commands.

This is getting way too long but you get the general idea. Would anybody buy something like this?

 

[WayneW]

probably, assuming the price is right and you could convince me that the product would be around for at least 5-10 years

 

[rocco]

A few cents, depreciated to zero over the years:

Except for the unique 'MAC" address, I will never again use a protocol that relies on addresses. You should be able to assign descriptive names, preferably hierarchical. Though I still use X10, I believe backward compatibility is too much of a liability.

oops, gotta go . . . will fill in other thoughts later.

 

[upstatemike]

A few cents, depreciated to zero over the years:

Except for the unique 'MAC" address, I will never again use a protocol that relies on addresses. You should be able to assign descriptive names, preferably hierarchical. Though I still use X10, I believe backward compatibility is too much of a liability.

oops, gotta go . . . will fill in other thoughts later.

The reason for having a software address is because it simplifies communications between devices. If you use a hardware address for direct communications from switch to switch then you have to maintain device tables within each switch, create individual links, and generally make things a lot more complicated than is necessary or useful. A software broadcast address works just as well between switches and is easier to set up and maintain.

As for descriptive names; that only works when you have a PC involved. While you or I might insist on using a PC to set up our switches, "Home Depot Guy" might be intimidated by that requirement. The simple A1 - P16 scheme makes it easy to program switches with existing X-10 controllers, and easy to map existing X-10 systems to the new protocol. Any system that requires a PC to set up is immediately limiting the scope of potential customers.

Unfortunately X-10 coexistence is a requirement if any new system is going to attract the broad user base required to survive. When was the last time you saw a UPB chime module or an Insteon screw-in module or a Z-Wave triggered Barking Dog module? For every X-10 user that is satisfied with just switches and lamp modules, there are 100 who are unwilling to do without that "special" X-10 device they have come to depend on. Feedback on the various boards suggest that people are willing to wait a few months for those items to be available in a new technology but they get absolutely violently angry when they discover the wait is more likely going to be many, many, months (or years) just to duplicate their existing functionality within the new protocol. Since it is not practical to reproduce the entire universe of X-10 devices within a short span of time, X-10 coexistence is a requirement for survival.

 

[Dean Roddey]

Unfortunately X-10 coexistence is a requirement if any new system is going to attract the broad user base required to survive. When was the last time you saw a UPB chime module or an Insteon screw-in module or a Z-Wave triggered Barking Dog module? For every X-10 user that is satisfied with just switches and lamp modules, there are 100 who are unwilling to do without that "special" X-10 device they have come to depend on.

That depends on what market you are talking about. In the professional market, X-10 is long since a memory and almost no professional installer would use it (or anything else that had its limitations probably.) If you are talking about the hobbyist market, then X-10 is obviously still alive, but it's still probably not got much of a life at this point (other than as a legacy technology.)

If you are going out there to get some investment money, one of the first things they are going to ask is about the potential market. And the potential hobbyist market probably isn't going to get them very excited.

Just my opinion of course...

 

[huggy59]

It sounds good, though the kicker will be price point, signal collision recovery capabilites, signal-to-noise ratios, and action latency for me. I hope you're designs don't have costly patent issues, either.

 

[Spanky]

If it is simple enough for my wife or the average Home Depot Joe to add a Christmas Tree light switch, then you have a real winner. My wife can add a switch with X10 but none of the other technologies.

 

[Mike]

Sounds good. A good indicator will be when it can be carried in Home Depot stores. If it is mature and stable enough to survive the wrath of a million returns or the 'average joe' not understanding it, it is probably ready for prime time.

On that note, I am curious what Insteon will look like if they make it into the Home Depot stores and will the current issues be just a memory at that point.

 

[upstatemike]

If it is simple enough for my wife or the average Home Depot Joe to add a Christmas Tree light switch, then you have a real winner. My wife can add a switch with X10 but none of the other technologies.

The unfortunate thing is that the technologies are not inherently complicated, it is just the way they have been implemented.

 

[rocco]

The reason for having a software address is because it simplifies communications between devices. If you use a hardware address for direct communications from switch to switch then you have to maintain device tables within each switch, create individual links, and generally make things a lot more complicated than is necessary or useful.

I'm not suggesting that you have to use the MAC address for communication, I'm suggesting that additional addresses should not be required to conform to an X10 format.

As for descriptive names; that only works when you have a PC involved.

That's not true. Look at ZWave.

What would be different from your original proposal if you set the descriptive name to A4 or P16? The descriptive name could even be set automatically from the Maxi-Controller. It would not preclude X10 address, it would simply not require them.

What would be wrong with an address that looks like an Insteon address, a ZWave address or a UPB address? The point would be to allow bridges to other protocols, without building other protocols into the new protocol. Even if you design your own chip, as SmartLabs has done, supporting multiple protocols will increase your costs.

Unfortunately X-10 coexistence is a requirement if any new system is going to attract the broad user base required to survive.

Agreed. But coexistence can exist without having every new device contain the X10 protocol.

 

[upstatemike]

Agreed. But coexistence can exist without having every new device contain the X10 protocol.

As an example:

I have some locations that are not on switches and use screw-in modules. Because an Insteon switch in the room is programmed with a legacy X-10 address it can control those lights. If a switch that did not support X-10 was there, I would have to depend on a controller to somehow trigger the X-10 modules when the other technology switch is pressed without introducing unacceptable latency. Most such arrangements that I have tested have been too slow, too expensive, and not consumer friendly enough to satisfy "Home Depot Guy".

 

[un-wired]

It all sounds pretty good, but why not use a slight variation...

Keep the mac addresses, use an IP like addressing based on those mac addresses, and then add a third communication...like Netbios. Simple common names which refer to mac addresses or IP like addresses.

For example:

Kitchen Counter Lights: 192.168.1.4: 00-0C-A4-E1-7D-14

This way any IP address, mac address, or common name can be used to operate the switches.

p.s. If you use my idea and make millions of dollars, don't forget me. Send me like a postcard or a giant fat check...whichever you feel is proper.

 

[upstatemike]

I'm not sure I understand what you are saying. The protocol already includes the software (ip-like) address and the hardware (mac-like or Insteon-like) address in each communication. The point is that there is no value in having switches do anything with the hardware address since that would force them to keep track of other devices that they are associated with, which in turn introduces unecessary complexity.

There is no reason why a switch should need to be reprogrammed if another switch that it is associated with is replaced due to failure, or if a switch is relocated in relation to other switches. As long as switches send and respond to group broadcasts, they really don't need to know anything about what other devices are in the group or where they are.

A Home Automation Controller on the other hand needs to work with the hardware address of the switch. It needs to be able to access individual devices to program them, needs to get verification that commands are successfully executed, and needs to be able to respond to input from a specific devices as well as group to commands.

The simple common names don't add any value in switch to switch communication and are not something you need to transmit within the protocol. You can certainly associate simple common names with the hardware address of devices within the HA controller.

 

[IVB]

This might be insinuated above, i'm not seasoned enough in this area to "get it" - are you talking about a power-line controlled protocol?

If so, my current issue with PLC's is that I have a 95yr old house, no 3rd wire in many locations. From what I understand, that immediately disqualifies me from Insteon/UPB. Is that a problem here?

 

[Spanky]

Should a serial number or IP type address be used, also allow for address mapping from 1 to 256 so that it can overlay the operation of other lighting systems. Insteon does not allow this type of mapping and it is a pain to overlay its operation onto the way other lighting systems work.

It must be seamless for control manufacturers to support the protocol.