New Lighting Protocol

[dublin00]

Some trivial improvements to even the X10 hardware layer would go a long way to improve the reliability of your new protocol.

1.) Use a real CRC (Cycle Redundancy Check) byte on your packets instead of a checksum or dark ages inversion check fields like X10. A CRC not only gives iron clad packet protection, but it can also correct bad/corrupt bits depending on the length of the CRC versus the packet bit length.

2.) Every request packet has a response packet so that the transmitter knows if the sender received the packet or not. That one is obvious.

3.) Collision retry like half duplex ethernet, but this is soo heavily patented that you'll get sued for certain...

 

[upstatemike]

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.

That is one of the reasons for using the A1 to P16 address scheme. It is easy to take A5 from an older protocol and map it to A5 of the new protocol.

I'm not sure why Insteon cannot do this. There are 254 slots in an Insteon PowerLinc. If those are mapped to A1 through P14 it should be a snap. You just use some linking software, like PowerHome, to link the Insteon Hardware Address(s) to the appropriate PowerLinc slot and you are in business.

 

[rocco]

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".

Well that's a poor implementation then.

An X10 bridge should add NO measurable latency, assuming:

1) The new protocol is fast. I think you would need to be at least in the ZWave or ZigBee range (250 k-bits/sec, raw) to be accepted in the marketplace.

2) A microcontroller can do the mapping in a couple of microseconds.

Given the above, a bridge should add a millisecond or two to a protocol that takes over 600 milliseconds.

I would also contend that a single bridge would be both cheaper and easier to configure. It could be configured with a simple tap-tap sequence.

Also keep in mind that the "Home Depot Guy" probably doesn't have any X10 (though he may get some later), and to force X10 addressing on him would be a disservice.

 

[upstatemike]

2.) Every request packet has a response packet so that the transmitter knows if the sender received the packet or not. That one is obvious.

Not entirely obvious. While it is useful for an HA controller to get an acknowledgement that a command is received, it is not as valuable when the sender is another switch. What is the sending switch going to do if there is no acknowledgement? Send the packet again? And how many times will it retry? 3? 5? Eventually it must give up. You get the same likelihood of successful delivery if you dumb down the switch and just have it repeat the command 3 or 5 times by default.

Collision avoidance is already in use by high end X-10 devices as well as by newer protocols. I don't think there will be a patent issue.

 

[upstatemike]

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?

I am talking about the theory of how devices interact with each other and with Home automation controllers which is independent of the physical communication medium used. I understand what you are saying about wanting it to work without a requiring a neutral wire though.

 

[upstatemike]

An X10 bridge should add NO measurable latency, assuming:

1) The new protocol is fast. I think you would need to be at least in the ZWave or ZigBee range (250 k-bits/sec, raw) to be accepted in the marketplace.

2) A microcontroller can do the mapping in a couple of microseconds.

Given the above, a bridge should add a millisecond or two to a protocol that takes over 600 milliseconds.

I would also contend that a single bridge would be both cheaper and easier to configure. It could be configured with a simple tap-tap sequence.

Also keep in mind that the "Home Depot Guy" probably doesn't have any X10 (though he may get some later), and to force X10 addressing on him would be a disservice.

I agree as long as:

1- The new protocol is, as you mentioned, fast and so is all associated hardware including the interface between the microcontroller and the new protocol's transmission medium.

2- The microcontroller is tuned to prioritize responses to guarantee microsecond processing regardless of any other activities it may be engaged in.

3- The Interface for the microcontroller to receive input from the controlling switch is separate from the interface used to transmit to the X-10 device.

 

[rocco]

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.

But why shouldn't you be able to use common names in switch communications. That is part of the point. If the names were allowed to be hierarchical, and aliases were supported, you would already support scenes, groups and links.

Rather than having "Kitchen Overhead Light", you could make it hierarchical, and have:

Kitchen ---------> Overhead light
................\----> Cabinet lights

Then, when you command "Kitchen", both lights could respond. At the same time, you could create an alias "Kitchen, Dim", which both lights could respond to as a scene. You could also have keywords, like ALL, LIGHTS and APPLIANCES that devices could respond to, such as "Kitchen APPLIANCES" OFF.

This whole approach borrows from the ZWave concept of a "Master Remote" to define the hierarchy. Of course, you could forgo the remote, and program X10 addresses into the devices with a Maxi-Controller.

 

[Steve]

How about if you just took UPB, removed the delay and the buzz and reduced the price. Would that not be close to your ideal solution? Would be a whole lot cheaper than trying something new and trying to compete with Smarthome, PCS and Zwave.

 

[upstatemike]

How about if you just took UPB, removed the delay and the buzz and reduced the price. Would that not be close to your ideal solution? Would be a whole lot cheaper than trying something new and trying to compete with Smarthome, PCS and Zwave.

If you add the hardware X-10 translator (TW523 replacement) into the deal you would come pretty close. I don't see UPB prices dropping anytime soon though.

 

[upstatemike]

But why shouldn't you be able to use common names in switch communications. That is part of the point. If the names were allowed to be hierarchical, and aliases were supported, you would already support scenes, groups and links.

Rather than having "Kitchen Overhead Light", you could make it hierarchical, and have:

Kitchen ---------> Overhead light
................\----> Cabinet lights

Then, when you command "Kitchen", both lights could respond. At the same time, you could create an alias "Kitchen, Dim", which both lights could respond to as a scene. You could also have keywords, like ALL, LIGHTS and APPLIANCES that devices could respond to, such as "Kitchen APPLIANCES" OFF.

This whole approach borrows from the ZWave concept of a "Master Remote" to define the hierarchy. Of course, you could forgo the remote, and program X10 addresses into the devices with a Maxi-Controller.

OK, I see where you are coming from now. I'll take another look at it.

 

[elcano]

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

Exactly. You got the point.

I dont think there's a need of adding a fifth competitor to Electron's poll. You just need to observe the results of the pool, select a potential future winner and build up from there.

Which one has the best opportunity of winning if correctly implemented? What changes would you do? I would focus in those two questions in addition to another not less important: What is the target market? Consumers want a product to be a all-around panacea, but product owners have to make decisions to please their target market because otherwise nobody will be happy. If your target market is the Home Depot users, then we will have problems pleasing high demanding DIYs and the professional market.

On fixing the existing technologies I would say:

X10 - No majors issues here according to the poll. Is there anything fixable that have not been tried yet?

Z-Wave - Reduce the prices. Make live status update required for every device (maing issue for me). Be more open the the public about the protocol. We dont trust protocols that are not openly documented.

UPB - Build your own ASIC to reduce price (main issue for me). Eliminate the delay and buzz. Build a linking interface that permit simple device and scene programming by pressing just a few buttons in the devices. Complex programming can still be done with software or dedicated device. Did I said reduce the price?

Insteon - Recruit a new QA Department manager (main issue). Hire an IS department and give the software free. Same as UPB, need to be able to do simple programming without software. Solve the fake security issue (this is another main issue).

I think that all four have a life, but only the last three (in addition to potentially ZigBee) have potential. Remember that most of us are preconditioned to PLC for historical reasons, but RF is convenient too and came here to stay.

 

[rocco]

Some trivial improvements . . .
1.) Use a real CRC (Cycle Redundancy Check) byte on your packets instead of a checksum or dark ages inversion check fields like X10. A CRC not only gives iron clad packet protection, but it can also correct bad/corrupt bits depending on the length of the CRC versus the packet bit length.

Yes!

Actually, rather then a CRC, a forward-error correction code would be desirable. That way, retries can be avoided if noise corrupts only part of a packet.

Parity and a longitudinal-check character is all that is required to correct single bit errors, and some simple hamming codes would work for small, multi-bit errors, with not much more overhead than a CRC.

But I (personally) would go with something like a Reed-Solomon code, arranged such that large error bursts or multiple error bursts can be corrected.

 

[rocco]

How about if you just took UPB, removed the delay and the buzz and reduced the price. Would that not be close to your ideal solution?

The one problem with UPB that most people don't often notice is that it is slow. It is only 4 times faster than X10, and more than 1000 times slower than ZigBee.

The physical transmission is so reliable, that you don't notice. But it still takes 1/4 of a second for each packet. If you want an acknowledgment from the devices in a link, it can take a few seconds.

I don't think it is a good investment in the future (IMHO).

 

[Steve]

How about if you just took UPB, removed the delay and the buzz and reduced the price. Would that not be close to your ideal solution?

The one problem with UPB that most people don't often notice is that it is slow. It is only 4 times faster than X10, and more than 1000 times slower than ZigBee.

The physical transmission is so reliable, that you don't notice. But it still takes 1/4 of a second for each packet. If you want an acknowledgment from the devices in a link, it can take a few seconds.

I don't think it is a good investment in the future (IMHO).

Well, I am not an engineer so I really don't look at the underlying specs. I think what is imporant to the average human being that consumes this technology is how well it works in practice, not on paper.

I can tell you for a fact that when I press a button on my touchscreen, which routes thru the GUI, thru the driver to the M1 then thru the M1 (UPB) to the switch, the light comes on virtually instantly, there is no perceptible delay. The status is updated on the screen almost as fast (less than a second).

So to say Zigbee is 1000 times faster? 1000 times faster than instant is still instant! I will give you the local switch delay in UPB, but as far as control thru the system... c'mon let's be realistic please.

As you said - 'that people often don't notice' is the key. And if I don't notice it, its good enough for me (and probably most fellow humans). Now if I were trying to win a speed race, then maybe nanoseconds makes a difference.

 

[az1324]

So to say Zigbee is 1000 times faster? 1000 times faster than instant is still instant! I will give you the local switch delay in UPB, but as far as control thru the system... c'mon let's be realistic please.

That may be true in the simple case but say you have 1000 messages in the system at the same time. Then you are going to notice the difference.

Maybe that case will not occur in a reasonably sized lighting-control-only system but start adding entertainment control, HVAC, pool, security, and other systems to that databus and the traffic will grow. The value of a protocol most certainly should include its ability to scale in all directions.