New Lighting Protocol

[rocco]

Steve, I'm not speaking to the user experience, that I agree is quite good. I'm speaking to the robustness of UPB, and the ability to support future applications.

As I said, the reliability of the physical portions of the protocol has you seeing few problems. But UPB has little room for error. If you look back at some threads, there are instances of peoples lights coming on a half hour after a switch is activated. This is what noise can do to UPB, but fortunately UPB has high noise immunity.

I don't believe that will last for long. The powerline is getting noisier every day, and the worst is yet to come. When I started using X10 in the early 80s, it was 100% reliable. In the late 90s, with switching power supplies, things went downhill fast.

Remember, if you set up a UPB network to broadcast a command four times, It take up almost two seconds of powerline time. That means no one else can flip a switch without a collision, and UPB has no real collision avoidance. In other words, UPB is very fragile.

If a protocol is going to rely on acknowledgments and retries, it should at least have the bandwidth to do so without requiring exclusive use of the medium for extended periods of time. This is why ZWave and Insteon have so much more bandwidth than UPB.

 

[Steve]

I don't believe that will last for long. The powerline is getting noisier every day, and the worst is yet to come. When I started using X10 in the early 80s, it was 100% reliable. In the late 90s, with switching power supplies, things went downhill fast.

Well, hopefully I'll sell this place and build a new place with a hardwire system before UPB becomes as bad as X10. And if not, I don't ever expect to have a thousand devices in my modest piece of the planet so maybe I'll be ok.

It would be cool though to have demo homes, small, medium and large to see how these protocols scale and perform in the real world. I just don't trust specs because I've seen systems with awful specs on paper perform great and systems with fantastic specs perform horribly.

 

[huggy59]

Anyone here remember the original ARCNet protocol and hardware? 256 "addresses" usually set by switches on each device. Sort of a cross between token passing (token ring) and broadcast (ethernet), but with a limit of 256 per net. What about something like that?

Or, how about just a specialized ethernet device for HA controlling? Right, just put an ethernet port and network stack on it... much like putting a Lantronics serial port server on the network...

 

[upstatemike]

Anyone here remember the original ARCNet protocol and hardware? 256 "addresses" usually set by switches on each device. Sort of a cross between token passing (token ring) and broadcast (ethernet), but with a limit of 256 per net. What about something like that?

Or, how about just a specialized ethernet device for HA controlling? Right, just put an ethernet port and network stack on it... much like putting a Lantronics serial port server on the network...

I liked Arcnet. I never thought about a token passing protocol for light switches but maybe...

Hardware folks tell me that ethernet is overkill in this application and just can't meet the price point. I do kind of like the idea though... until you accidently assign your server the same address as your toaster and toast all your data!

 

[George West]

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.

If the example of Intermatic Z-Wave products and the INSTEON products that are currently in Lowes and on HomeDepot.com are any example, pretty much like the standard products...

Something to consider is that there are always current issues; usually new ones. The real key is how fast are the issues addressd and resolved. When I did product development engineering, which included release to manufacturing as well as sustaining engineering, our motto was when you solve your biggest problem you get to promote your second biggest...

George

 

[PeterW]

My biggest wishes:

* Make a computer interface that is a first class citizen not an abomination to program for. eg: more like the UPB PIM than the Insteon powerlincV2.

* If you use A1-P16, then please make sure that devices are also addressible by their hardware mac/serial/whatever address. eg: so that a remote device can configure it completely from blank. consider a setup button that broadcasts its existence so that HA software can identify it, configure it and incorporate it automatically.

* positive acknowledgement of every command is a must.

* design some sort of repeating or boosting system into the protocol from the start. UPB suffers in my house because of this. Something simple like the old ethernet 'RIP' protocol.. each device periodically broadcasts a list of devices it can hear and what signal strength they have. Then make routing decisions accordingly.

* Don't get side tracked with unimportant things that could be better served as add-ons. eg: what happened to the powerlincV2 and SALad. The hardware doesn't have enough resources to do everything, so it sucks at them all. It would have been better to have a simple, fast and reliable piece of hardware to interface to a computer, and have an add-on programmable controller as needed.

* For security, I'd rather call an electrician to install a clamp-on signal blocker (eg: like the X10 leviton blockers) than be inflicted with a half-baked and disruptive security system like Insteon or a simply ineffectual one like UPB.

* IMHO no need to go RF. X10RF is good enough if you can bridge it.

* IMHO also.. I'd like to have the ability to do simple pairing, even if that means tables in devices. ie: each device has its own address, unlike X10. With X10 if you want to have a switch control two slave devices, you have to program them all to the same address. I'd rather have the option to have device A1 know that it has to turn on devices A2 and A3.

* groups/scenes are a bandaid for protocol problems (poor reliability, speed, whatever). If you can make it fast enough, skip scenes as part of the protocol and instead address each device as needed.

* Include a 'goto level, rate' command. UPB has this, Insteon does not. With Insteon you can't send an arbitary change command to a switch that specifies both the level you want to go to and the speed to do so with.

* Firmware upgradeable devices. if you have a fast enough network, and if the microcontrollers support it, then allow HA software to update device firmware on the fly.

* consider doing something really off-the-wall.. investigate whether it is possible to use the homeplug ethernet family of chipsets, support hardware, etc for the carrier mechanism instead of rolling your own. It would be abolutely stunning if you could go and buy a standard $50 homeplug ethernet adapter device to connect to your computer to talk to your embedded devices. If they used that signalling system between themselves (or a cut down version of it) then they'd essentially be communicating by small ethernet frames. Note: I said frames, not a whole darn tcp/ip stack! Ok, maybe this is too hairbrained, but it would be seriously cool. It would certainly solve the speed problem though... Probably would be too expensive.

Anyway, thats my wish list even though I know it isn't practical.

On the other hand, I'd probably be satisified with UPB without the delay, without the buzz, and with residential repeater/booster system.

I'd be just as happy with a debugged Insteon system with a halfway decent computer interface that could transmit computer originated messages at more than 1% of the PLC system's rated speed.

-Peter

 

[dublin00]

Personally, I vote for the "No new lighting protocol" approach. I.e. don't wire in the lightly protocol like everyone else (X10, Zwave, Insteon, etc...). We are in the age of software and having ROM firmware is just soo last century. Yes, the physical link layer protocol needs to be in hardware, but nothing else needs to be.

My own advice as an E.E. is to go raid the cell phone industry for hardware solutions and make all of your firmware/software download-able. That way you can change the lighting protocol, fix bugs, etc all with a few keystrokes. I.e. no returned switches to fix firmware bugs.

If you want an example the cell phone industry produces tons of really small form factor, low power, easy to program microcontrollers and support components. In the existing HA world the standard list of companies often use 1970s style PIC micro-controllers. They use them because that is what they have always done. In the cell phone hardware universe you can find ARM9, MIPS16, etc micro-controllers with 32-192KB of on chip Flash-ROM and 8-32KB of on chip SRAM easily (just pick the Flash-ROM/SRAM size based on your budget). Ask any of the PIC programmers out there if they would like to switch to an ARM9 using a standard C/C++ compiler instead manually programming a PIC in assembly.

For the physical layer do as the previous poster said and pick up Intellion's power line networking layer I.C. They have a small form factor version that is very low power that is intended for applications like this. It doesn't run at full ethernet data rates, but you still get the benefits of a robust debugged physical layer.

If you want to go wild and get crazy throw in a cell phone wireless modem I.C. from T.I. or Motorola. You don't need to invent a new wireless physical layer, just re-use an existing one (GPRS, etc, take your pick). Turn down the transmit power to 100mw and you can leverage all that R&D. Anyway, that one probably needs more thought, but it is just a thought.

 

[upstatemike]

All good ideas as long as you can hit a $30 retail price point for the resulting product.

 

[dublin00]

All good ideas as long as you can hit a $30 retail price point for the resulting product.

Is that really the issue?

Take a step back for a moment and look at what all the existing (and new) HA companys are doing with lighting from the 10,000 ft level. How important is the physical connection to the end customer? As long as they don't need to cut up the drywall in their home they probably don't care.

My point is that the software is what really has the value, not the hardware. All of the companys making HA light switches today are focused way way too much on the hardware side of things and way too little on the software side. They are also shortening their products life by hardwiring too much (old style thinking), especially with new technology that doesn't have much field exposure yet.

As for the $30 retail price target, I don't see that being very difficult if you use standard consumer electronics build-to-ship vs retail price margins.

The issue is that the existing HA companys have a very high gross margin. A case in point: A few years back PCS posted the slides from a UPB developer conference on the WEB. The slides detailed how PCS built an existing X10 SmartSwitch V1 for $5-6 and then sold them for $59.95 retail. That is a 10:1 ratio (which is very high). The large consumer electronics companys (I worked for one back in the 90s) typically use a 2:1 to 4:1 sliding ratio depending on the retail price of the product. For instance, high priced TVs are often sold at 4:1 gross margin while $69 CD/DVD players often have a lower 2:1 gross margin on sales.

If you use a more typical consumer electronics 2:1 gross margin that allows you up to $15 for your entire build-to-ship cost (that is everything: production, testing, package goods, and shipping). Thankfully light switches are small and can often be shipped togther to dealers in bulk, so you save something there. That probably leaves you $10 for the switch itself of which $6-8 is the actual bomb cost before assembly & testing. Off the top of my head that doesn't seem out of the realm of possibility (minus the RF modem).

The bottom line here is the business model. Todays typical HA companys are structured as high gross margin firms because they are niche market players that dream of growing up to be big players. But, you need to start out the other way around with a business model based on high volume to get there, they don't just come (to paraphrase "the field of dreams"). This is because a lower gross margin firm can offer more functionality at the same price point which attracts more customers. This is also why many small firms are destroyed by larger ones when an emerging market transforms from niche to high volume.

To me building a company on making HA light switches alone doesn't make sense. You'll never break out of the niche market and you'll have lots of competition. The light switches are the nuts and bolts, but the value added software is where the money really could be because you can keep selling it to your customers long after they have installed the hardware. Software can also be sold direct to the customer through downloads after install which lets you keep the entire gross profit, no more splits with the dealer. Software also allows you to expand your product line beyond just light switches, but that is another whole discussion.

 

[Brightan]

good day! I have been lurking for a little while and although I am not ready to make any official announcements, I can't help but jump into this conversation (which I am finding very interesting). I have been selling a hardwired lighting system for a number of years (mostly oem yachts) and am in the middle of a complete redesign that will take the existing (proven) system and tweak it to offer the following:
1) hardwired network using CAN (Controller Area Network) at 500kbps
2) low cost modules starting at the $59-$99 price range (example, a controller that controls 4 rooms (2 switches, 2 status leds, IR input and dimmer output for each room)
3) open protocol (who else does that???)
4) third party switches (choose from whomever you want, Touchplate etc)
5) third party compatible dimmer modules or kits from us that can be local certified
6) firmware can be downloaded from PC. You can even change the functionality of a module (assuming connectors match new application etc)
7) free configuration software with graphic interface showing floorplans etc.
8) protocol uses set node and device numbers but each device is also addressed by name when using the configuation program
9) interface to a number of 3rd party control programs, CQC etc
10) Scenes that feature
- any number of lights, any brightness and any amount of time (instant to 9 hours)
- you can brighten and dim an entire scene (or only certain lights within a scene)
- simple logic within a scene so you can do things like trigger a scene at sunset but only turn on if it is currently off. If-then-else logic is based on time, day/night, brightness of light etc
11) home run wired for local dimmer panels or retro-fit by running cat-5 cable to switch location and installing solid state relay in existing switch box.

and a bunch of other features too many to list.
One comment on this discussion... if you are going to create a decent protocol for lighting control, don't limit yourself to anything as ancient as X-10. Forget about making it as simple to use as a regular light switch, we already have those...the real power in home automation is in the features that go way beyond what we already have. More complex yes, but, I have never had a customer want to give up their lighting system after using it for the first week (and I have had a couple of real techno-phobes)
Also, forget about wireless, it will always lag behind hardwired in every way except the ability to retro-fit so unless this is paramount, don't hold your breath (IMHO) Ok, so I'm a little biased...
Steve
(old web site at www.brightan.com this will be updated in a couple of months with the new system)

 

[upstatemike]

looks like I'm going to have some competition so I better come up with some cool new features... like telepathic scene control maybe.

In any case Steve, welcome to CocoonTech! Hope you keep us up to date on your progress.

 

[rocco]

Welcome, Steve.

I am surprised nobody has used CAN in the past. I've considered it for some robotic apps, but always butted my head on the cable length/speed trade-off.

So here is my question: Since the CANopen specification calls out 100 meters as the maximum network length for 500 Kbps CAN, do you really have enough length available to do a whole house?

Maybe BSR should split us off into a new thread now, before it's too late . . .

 

[Dean Roddey]

So here is my question: Since the CANopen specification calls out 100 meters as the maximum network length for 500 Kbps CAN, do you really have enough length available to do a whole house?

Does it have a hub concept? If so, then you could have a couple of hubs, with 100 meters between hubs I assume....

 

[Brightan]

you can run it without any hub for the lowest cost system or with a 5 port hub for 10 seperate branches (in and out of each of the 5 ports) and you can add more hubs if that still isn't enough.
CAN is being used by other HA systems, including another lighting system doing hardwired.
Steve

 

[rocco]

Or you could bring the data rate down to 50Kbps, and therefore allow up to 1000 meters.

You would still be faster than ZWave, Insteon, UPB and X10 COMBINED.

Just a silly suggestion . . .