New Home Automation Hardware

Mike, you are almost there with ZigBee. The addressing is as you describe, with 64 bit MAC addresses (over 18 million-trillion devices), the addressing is invisible to the customer. Switches and light controls are logically defined as distinct "objects", so a wall switch may be a single "device", but containing two objects in separately addressable "endpoints": a switch endpoint and a light endpoint.

The "scenes" are created with a mechanism called "bindings", but programming is a little simpler. I believe it works like this:

Each switch and light would have a small, recessed push-button (much like the one on the SwitchLincs). You would push the button on the "switch" that you wish to "bind" lights to. After setting a light to the desired level, you then push the button on that light to bind it to the switch. When you have selected all the lights for the scene, you then push the button on the switch again.

No central controller or other "infrastructure" is required. Any line-powered device should be eligible to be a router. Unlike ZWave, the mesh network auto-configuring and self healing. There is no practical limit to the networks size. No single failure can bring down the network. Best of all, it should be down to a couple of bucks per device in a year or two.
 
Thanks, this really helps. There is a tendency to let the technology define the product and application. But the world is full of technology in serch of a utility

I can use this type of input to drive toward the products customers would want or need.

Would the ability to make a scene or two be enough for an out of the box product? Obviously with a setup system more complex capabilities are possible but a couple of scenes out of the box setup with the buttons on the devices (which would be more plug in modules than in-wall devices) be adequate?

I believe Lonworks is capable of the same level and type of system as Zigbee.
 
I am not familiar with Zigbee or Lonworks so I don't know if they do what I'm describing or not. The reason for not limiting things to just a few scenes is that the core vision has every switch triggering at least 2 scenes and every switch able to participate in any or all scenes. If you have 20 switches then you have 40 scenes defined in your system. If you have 20 switches and 2 8-address tabletop controllers then you have 40+32=72 scenes, etc.

Remember when you press the large paddle on a switch it transmits a unique scene trigger and that is all it transmits. There are no ON, OFF, DIM, BRIGHT, signals transmitted. Only triggers for the scenes that you have defined.

Example:
There is no "ALL LIGHTS ON" button. If you wanted that feature you would program all of your switches to be at full on when one of the buttons on a tabletop controller is pressed. You could define the same thing to happen when the top is pressed on a certain wall switch but it would not be triggering "the same scene" but a different scene that is defined to do the same thing.

Example:
You install a switch for your porch light. You leave the top of the paddle (scene A) at the factory default so it turns on the porch light. (It is actually transmitting a trigger for Scene A for that Unique ID. It happens that the only switch set to respond to that scene is the same one that is transmitting the trigger. The setting that switch goes to when it sees that particular scene trigger is full ON.) You then decide to change what happens when the bottom of the paddle is pressed and scene B is transmitted. You program all of your switches that are controlling outside lights to to respond to the scene B trigger from the porch switch and have them turn OFF for this scene. Now pressing the top of the paddle on the porch switch turns the porch light ON and pressing the bottom of the paddle turns all outside lights OFF.

I guess because scenes are the ONLY commands transmitted, I don't see how you could get away with just "a couple of scenes out of the box". Each outside switch in these examples is included in both the "All Lights ON" scene from a tabletop controller button, AND an "OFF" scene from porch switch scene B, AND probably their own scene A and B triggers AND some scenes triggered by other tabletop controllers or motion sensor or whatever.

Is this pretty much how Zigbee works?
 
Upstatemike:

I'm still researching Zigbee so I'm not sure,but its seems close. Its not immediately clear if ZigBee is peer to peer or controller based. http://www.zigbee.org/en/spec_download/download_request.asp I have seen some hits against its reliability and the complexity of the underlying software, but that's from competitors. Their roadmap is to get cheap fast, but the first markets are industrial where the speed is more important.

Lonworks works very much as you describe. And can implement your proposal pretty easily. see http://www.echelon.com/products/lonworks/default.htm

Z Wave doesn't work that way and needs a controller. It can do most of what you describe the hard way, but the switches available now do not transmit, they can transmit status when polled by the controller. They also do not store scenes, that is all in the controller.

I have not dug into UPB enough yet to know.

And it may be possible to use other systems but most are really controller centric architectures.

I think I see the benefit of a controllerless environment here. Setup can get complex with 20+ switches if they are all involved in a given scene but not difficult with 2-6 devices. Critical is having the switch work as expected (i.e. a switch/dimmer) out of the box.

I guess my question really was how many scene options from a single point do people use? (Excluding a "Maxicontroller" type device) And is there a need for a handheld remote?
 
I don't use hand held remotes much except when watching TV so I'm not sure how to estimate their appeal to the Home Depot HA novice.

I also wonder about wireless "mesh" technologies for this market. I have a long narrow house with 5 large stone chimneys distributed throughout. If I go to Home Depot and buy a 2-switch starter kit to control a light at each end of the house there is no way the signal is going to get through to let those switches talk to each other. I would have to install several switches for the signal coverage to be good enough for a reliable system. As an HA novice I am not going to understand that, and will probably give up when the first 2 switches don't work as advertised.
 
Yeah, I'm not a big fan of meshed wireless HA technologies for those reasons too. Powerline based protocols can be highly reliable now as UPB demonstrates. I think that insteon is simply a technology designed to backward compatible with X10. As such, its only option to achieve high reliability is to use wireless.

Here's another option for your peer based system: switches need to be able to send different commands based on single or double taps. This gives the homeowner the ability to program multiple lighting effects into the same switch. Popular choices are the "all lights off" effect when a door switch is double tapped off. I personally have tracklighting in the library so my library overhead switches also activate the tracklights if they are double tapped.

As far a physical switch features go, I also really like the SwitchLinc brightness indication strip on the left side of the toggle. I miss that display on the UPB switches I have.
 
I like the "double tap" idea. How do you think it will go over in households with old folks though? (Older people tend to dislike buttons that do different things depending on how you press them or current context or anything like that.)

I agree the brightness strip is important and I further stipulate that it must be yellow and/or blue to distinguish our ideal switch from current product offerings.
 
Hello All,

I have been into HA for about 6 months now, and I am liking it. What I would like to see is this. Cheap switches and modules controlled by some sort of a controller. The switches and modules should have a soft start feature, ramp rate setting and of course dim and bright. I don't need scenes stored or controlled with in the switches. Yes the scenes stored in the devices is a nice idea but there is no logic involved. True HA should allow you have total control , from the controller, to do all the scene settings, timers and logic. My vision of HA is to be able to walk into a room after sunset and have the light come on automattically, and turn off when I leave. Control lights in areas where there is not a lot of traffic, so if they were turned on and not turned off they will turn off by them selves. Alert me when someone has entered my driveway. Table top controllers are nice but to have a AC cord running across the floor to your coffee table is ugly, so hand held remotes are a must. I have accomplished most of this with the X10 technology, but we all know how easily RF signals get stepped on by other RF signals, How powerline commands can get corrupted and not complete there task. X10 is unreliable.

By keeping the switches and modules simple should keep the cost down. This is important. I would like to be able to control every light in my house via this technology but switches at $50 - $60 a pop is extremly cost prohibitive. Oh yes, a good reliable, flexible motion sensor is a must. In addition to the motion sensor I would like to see some sort of trip beam, that when crossed you could active a device. Motion sensors are nice but they don't fit every application thus the need for a trip beam. Naturally they should be wireless.

What bothers me most is the way new products are brought to market. A good example is INsteon. They sold a starter kit that had a tabletop controller, lamp module, and the RF devices. 1 month later they release the wall switches. Well this is very frustrating. The new system does nothing, except turn lights on and off. I guess we are supposed to be beta testers for the manuf. Bring the complete line of product to market in a resonable period of time. I don't want to wait 1 year for the product line to be available.

Thanks for listening.
T.
 
@upstatemike

Well, people who dislike double taps don't have to program that feature I guess. Home Depot would sell twice as many switches to those individuals! Of course, they could also carry the double toggle version that fits in a single gang box.
 
expanding on TCassio's sensor discussion:

Trip beams should also be able to convey direction. This should consist of a simple device that attaches near a door and works wirelessly. Now you're in business! The controller can count entry and exit trips, turning on lights when the room count goes from zero and turning off the lights when the room count goes back to zero. In fact, the sensor itself could designed to signal "on" when the count went up from zero and "off" when the count went back to zero. That way, it could work in a Peer based system too. Multiple devices should be "linkable" so their room counts were syncronized. This allows easy installation for rooms with more than one egress.

I actually designed and built a sensor like this back in the late 70's. It consisted of two IR detectors mounted next to each other and an IR source on the other side of the door. It was a very successful light controller for the bedroom. Unfortunately, there was no X10 infrastructure available yet so I eventually abandoned the project since I needed a "nighttime" detector and a bedroom "off" manual switch that disabled the thing. At the time, everything was hardcoded using TTL chips.

You know, I should dust off those schematics and add a UPB protocol interface..... That bedroom counter was the best I've ever used because there was no "off" delay after the room was exited and the lights never turned themselves off when sombody was in the bedroom either....
 
TCassio:
What you propose can be done now with Z Wave. Its a command based system with a wireless controller directing everything. Your paradigm is very different from the other proposed so far. Its very user interactive with a remote at hand.

Its possible the two systems may share a common infrastructure but I don't think it would work well. Perhaps two different systems for different customers.

Trip beams are not an easy install and can be confused (stand in a doorway). Still the occupancy monitor/management is a key component of energy savings. The real challenge is battery life on a wireless system.

Is energy savings an important part of home automation to most consumers? I have heard from utility guys that Americans do not hold energy savings as important.

The conversation here is getting more interesting. I'm going to be traveling for the next two weeks (not able to monitor this well) and I hope it will continue. I will do my best to monitor it. And do my best to influence the development of products to support the ideas expressed here.
 
TCassio:

I agree with most of your ideas for the kind of system I would like as opposed to what a “Home Depot HA Novice†might feel is important. If we are going the True HA centralized controller route then my feature wish list is a little different:

1. A protocol that is so fast and so reliable that there is no need for scene information to be stored within the switch. I’m talking about setting a scene from the controller that includes 20 or more switches and is set by the controller sending an individual command to each switch in the scene AND receiving a confirmation from each switch that the command was carried out successfully. The entire process for all 20 switches in the scene must occur within 300ms to avoid any perceptible delay to the user.

2. The central controller must constantly and instantly be aware of the state of every LOAD in the system. NOT a table that remembers commands sent and received but a CONFIRMATION of the load status that is refreshed MANY TIMES PER SECOND for EVERY DEVICE IN THE SYSTEM. The system should instantly know if a load changes regardless of whether it is due to a command, manual operation, power failure, bulb failure, or whatever.

3. The controller needs to easily track other things besides light switches: Total power consumption tracked by phase, circuit and device. Consumption of water and natural gas. HVAC demand time vs. cycle time. The true status of every household appliance (what channel is the TV on, what cycle is the dishwasher currently at, etc.

4. The system should automatically synchronize every clock in the house regardless of whether it is in your VCR, bedside alarm, setback thermostat, PC, microwave, answering machine, or whatever.

5. Instead of trip beams the system should track occupancy with floor joist stress sensors that are so sensitive they can identify who is in a room by how much they weigh. (This also eliminates the need to wear RFID type devices). The logic should be smart enough to handle multiple people in a room, somebody carrying something heavy, etc.

6. All displays should be bright LED or Fluorescent types that are easy to read from across the room. NO LCD’s with green LED backlights that you have to get right next to, to read!

7. The controller needs to have enough processor power to handle situation where many things happen at once. For example: it should be able to simultaneously greet someone at the door, announce the door visitor throughout the house, adjust the HVAC system and record a voicemail from a telephone caller, all without any perceptible delay to any of these individual tasks.

8. TTS and VR should be indistinguishable from talking to a human.

9. The controller should not use a computer except for programming the system and maybe to provide some browser interfaces via touch screens. It should not rely on, or in any way require, components licensed by Microsoft.
 
#1, #2, and #3 are the killers for X-10, Z-Wave, and probably UPB though I've not done a driver for that technology yet. Without that, there's no way to create a really smart automation system. Those technologies are just not fast enough to keep latency down for more than a handful of modules. Z-Wave is way better than X-10 and can probably do 10 or so modules with a latency of a few seconds, but a big home with 100 modules, forget about it. X-10, IMHO, can't really do more than a couple with any kind of decent latency. Not sure about UPB, but it's not a high speed network and probably can't do a lot better than Z-Wave/Zigbee.

Due to costs/size (and frequency licensing?) I would assume that it'll be a while before we see a Zigbee-esque system that run at say 1Mb/s or some such thing. That would provide the kind of speed to do the things required, and to rival a hardwired system. You'd think that a 1Mb/s wireless system running a stripped down IP stack (but part of it's own network of course, not part of the home network) would be very inexpensive, but I guess not inexpensive enough or someone would have done it already.

Even a more expensive wireless system like Lutron RadioRA doesn't provide diming level feedback, only on/ff feedback, if I remember correctly from doing that driver. Though, within that constraint, it's a lot better about keeping up with the status of modules and making them available to the controller with low latency.


I semi-disagree with #6. It should be an option, but must be disabled if desired. No one wants something like that in a home theater room.


I definitely disagree with #9. $12,000 Crestron ISYS panels use Microsoft OS products, so it is definitely not a problem if it's done right. The issue is that if you want it to be stable, it shouldn't be treated like a general purpose computer, it should be a closed box, preferably running Embedded XP if it's an appliance type device. There are many devices out there that do so and they are every bit as reliable as an HAI or Elk panel. Though, you can certainly combine such a panel with a higher level automation system.


#7 is non-issue if you can get over #9. Even a whimpy modern motherboard can handle many simultaneous operations.
 
I semi-disagree with #6. It should be an option, but must be disabled if desired. No one wants something like that in a home theater room.

I have a Squeezebox in my media room and it is no problem at all. I can dim or turn off the display right from my remote but I also have the option to run it at full brightness so I can read it without leaving my seat.

My main gripe is with thermostat and keypad displays. The green backlit LCD is OK if you are right at the device operating it but if you glance from across the room to see what the temperature is or to view an automation message you just can't read it.

#7 is non-issue if you can get over #9. Even a whimpy modern motherboard can handle many simultaneous operations.

You may be correct. Assuming you hang enough sound cards and I/O hardware off it to support all the simultaneous functions, a modern motherboard should be able to keep up. The key there is to have a truly closed system as you decribe so there is no chance that the OS is going to preempt a real-time response and divert cpu cycles to redrawing some complex video screen or something.
 
It can still have a video display and not be a problem. A modern system isn't going to get bogged down enough even with a very complex display that it will be an issue with processing things in the background. You don't need real time in the strict sense for most home automation problems. You don't want the controller to go of into the ozone for a minute, but that's not going to happen unless it's very badly designed. CQC is constantly doing many things at once, and has no problem doing that on even a low end system, because 90% of what anautomaiton system does is device I/O of some sort another, all of which is done asynchronously on a standard PC (though it may be done in a polling loop on a small controller, which can be a problem.)

Even if you are talking to 25 different devices over various serial, IP, USB, etc... connections, and even if those devices are fairly fast, the data going over that connection is almost always unbelievably slow by the CPU's standards, and it's not much involved anyway. The data is pulled in and sent out via DMA in most cases, and the CPU isn't even involved. The CPU spends the vast bulk of it's time just twiddling its thumbs, even more so in an appliance type system where you strip out a lot of the auto-magical background stuff.

Even on a pretty loaded and active CQC Master Server (which provides centralized services like data storage) that is also running CQCServer (which is where the drivers are loaded), on what would be a bottom end CPU these days (say 1GHz), the CPU load will usually not be more than 3 to 5 percent. It will hit peaks if you change screens on the interface or something, but it still doesn't max out and the peak is short. When there are significant delays, those are almost always caused by the device being controlled, e.g. the digital projector that won't even talk to you for 15 to 20 seconds after you power it on and so forth.

In a system like CQC, which is highly network distributed, there are certainly latencies that get introduced, but they are fairly minimal. Sometimes they are problematic. For instance, someone will say "But I can press this button on my remote control and hold it down and the action repeats really quickly, why can't this expensive system do that?" But it's because the button press on the touch screen packages up some data, posts an async message, which gets picked up by a timer message, which sees a write command, which makes a call to the ORB client, which bundles up the call data and drops it into a queue on the appropriate client connection manager for the target server, which spools it out over the network, where it's picked up by a reader thread on the target server process, which puts it into a queue, where it's pulled out by a worker thread, which unbundles the data, looks up the target remote object, and calls that object with the parameter data, and that target driver object has to wait for the thread that is polling the device to stop, then gets it to do the write of the data to the device, which has to wait for the device to ack that the operation worked ok (or failed.)

Then the whole thing works back the other way to get the acknowledgement back ot the client touch screen that it worked. All that for just one IR or serial or IP event to be sent out to a device. It's actually amazingly fast considering what all is going on, but it can make highly interactive operations, like dragging a volume slider with your finger, kind of spongey, and certainly less immediate than just pressing a button on a 'send and pray' type IR remote.

In almost all cases the primary delay problem is the device itself. And this relates back to the original #1 problem. If you have a device that must be polled for data, and that's very common, in order to have low latency you have to poll it rapidly. But if you poll it rapidly, that means that the connection to the device is in use a greater and greater percentage of the time. This means that, when the user presses that button and wants to send out something, the odds go up that the driver will be in the process of polling the device at that time, and the incoming thread that processes the write has to wait for that to complete since it cannot talk out the port at the same time. If the device responds very fast and the link is fast, it's not a problem. If you poll every 250ms, and the round trip is 50ms, that's not too bad. But if the round trip is 1 second, then there' always the chance that you'll want to cause a write command at just the point when it starts the poll cycle and the write gets delayed by a second.
 
Back
Top