Baffeled buy the direction of HA

[Dean Roddey]

I think this is a great argument for having more than one standard. What's wrong with two? A low-bandwidth one that is everywhere for controlling things like lights. A high-bandwidth one where necessary for things like media.

But the network is already there in almost all cases, so it's essentially free from the control system's point of view, or worst case it's use for other things highly amortizes the cost of the network as a charge against automation.

As I mentioned above, it could be combined with a very localized control system for dumb devices, and that localized dumb system could be very low cost because it only has to deal with devices in a room and uses the IP network for connection back to the control system. So it would not start bogging down as the system gets larger, something that UPB, Z-Wave, and X-10 will always all suffer from, due to low bandwidth.

The implied point above is that bandwidth isn't just about one device, it's about all the devices in a system. It doesn't matter if you can turn one light on or off with X-10 pretty easily. You still can't poll 100 of them with any kind of reasonable latency, because of low bandwidth.

 

[smee]

I'm not saying that you should be happy with the bandwidth of x10. But I hardly think I need 100Mbps ethernet to turn my lights on and off (or poll them).

And the network that's already there is your AC power. I think the convenience of using this will outweigh the benefits of higher bandwidth for quite a while to come. Maybe something like "ethernet over AC" will be the answer. I just think it's a good idea to make use of the wires that are already going to every location.

A local node that is connected to your ethernet network and controls mutliple devices is certainly a possibility, but it will require local wiring (as you mention). I can see this becoming quite complicated if modifications need to be made (unless you are like me and you don't mind having "exposed" wiring running all over the place). I guess a local RF network (non-ethernet) connected to the house-wide ethernet network (wired or wireless) could reduce this problem.

The alternative of hardwiring ethernet to every switch and outlet will require quite a lot of home-run wiring (how much room and money will be needed for ethernet switches?) or distributed switches. I'm not sure how practical that would be (although it could be extremely versatile).

 

[bfisher]

As I mentioned above, it could be combined with a very localized control system for dumb devices, and that localized dumb system could be very low cost because it only has to deal with devices in a room and uses the IP network for connection back to the control system. So it would not start bogging down as the system gets larger, something that UPB, Z-Wave, and X-10 will always all suffer from, due to low bandwidth.

The implied point above is that bandwidth isn't just about one device, it's about all the devices in a system. It doesn't matter if you can turn one light on or off with X-10 pretty easily. You still can't poll 100 of them with any kind of reasonable latency, because of low bandwidth.

I don't know about the other technologies - but UPB does not require polling of any kind (it updates levels whenever they change - either via the switch or a central controller). Therefore, the only time bandwidth becomes an issue with UPB in a very large installation would be if you are turning on/off many devices at a time (and they offer a link feature to accomodate this).

 

[kwilcox]

Also with regards to X10 bandwidth: I'm really starting to notice that .8 second lag now. Once you start using a newer technology, this becomes very irratating.

 

[Rupp]

Also with regards to X10 bandwidth: I'm really starting to notice that .8 second lag now. Once you start using a newer technology, this becomes very irratating.

Dang you must blink fast B)

 

[Dean Roddey]

I don't know about the other technologies - but UPB does not require polling of any kind (it updates levels whenever they change - either via the switch or a central controller). Therefore, the only time bandwidth becomes an issue with UPB in a very large installation would be if you are turning on/off many devices at a time (and they offer a link feature to accomodate this).

Any time the control system losses connection to the UPB network, for any reason, it has to assume that it doesn't know any longer what's going on when it reconnects. So it will have to ask every module for it's status in order to get up to date. How long would it take to do that on UPB with a 200 module system?

And you still have to poll, since the notifications probably aren't guaranteed delivery and you have to catch a module having gone away for some reason. You can poll more slowly on the assumption that you shouldn't miss too many messages, but you still have to do it, and that still eats up capacity on a really low bandwidth network.

 

[rocco]

Any truly ubiquitous standard has to be able to distribute media as well as turn lights on and off.

Dean, I agree with almost everything you said, but I don't believe this is possible.

ZigBee was conceived because none of the other wireless technologies were capable of running on batteries. It also has respectable bandwidth (250kbits, raw).

Ultra-Wide-Band was conceived because WiFi was not suited for the bandwidth and QOS requirements of High-Definition media.

So, as Smee stated, what is wrong with two? or more? I believe both UWB and ZigBee will integrate well with Ethernet, and they address problems that IP can't.

 

[AutomatedOutlet]

Dean,

Any time the control system losses connection to the UPB network

Have you ever heard of this happening with a UPB system and a controller? I don't think I have.

And you still have to poll, since the notifications probably aren't guaranteed delivery

Not true, it is guaranteed.

Why are you so down on UPB? Have you tried it?

 

[kwilcox]

Also with regards to X10 bandwidth: I'm really starting to notice that .8 second lag now. Once you start using a newer technology, this becomes very irratating.

Dang you must blink fast B)

I was happy with X10 until I started putting in UPB. Sensor controlled lights behave like stand alone Leviton motion sensing switches now. .8 seconds is a long time. I had a friend over the other day and I was showing him the basement remodelling job. We walked into the sewing room and in .8 seconds he was able to identify where the lightswitch was and press it thus spoiling my little automation demo. Granted, the lightswitch was the first thing he saw when he opened the door but it brought home a real point: I had learned to live with the delay.

@Dean Roddey:

I've never had the situation you describe happen to me. The only time I've ever restarted my controller was after the W2K3 automatic patch process required a re-boot. HCA saves all state information so after the re-boot, it was pretty much in sync. Anything out of sync (like a light switch that was activated during the 45 second reboot process) re-synced automatically once that switch was operated again. I never request all device status reports for this reason. Do other controllers behave differently?

 

[AutomatedOutlet]

My Elk certainly doesn't need a re-boot

 

[Dean Roddey]

Have you ever heard of this happening with a UPB system and a controller? I don't think I have.

It could be nothing more than turning it off to move it. If it takes 5 minutes to get back in sync after you turn it back on, that's not very good.

Not true, it is guaranteed.

Does the module just keep trying to resend changes until it gets an acknowledgement back from the controller? What id the controller doesn't respond? There's really no such things as guaranteed unless the controller proactively askes and gets a response. That's the one and only way the controller can know for sure, if the devices don't send regular heartbeats.

Maybe they do, I dunno. Otherwise, a module that you've not heard anything from for 30 minutes could be on the way across town by then. The controller must proactively ping the device reguarly to know it's still alive and that data it has is valid. It doesn't have to do it as rapidly where async notificatoins are availalbe, but it still needs to do that.

Why are you so down on UPB? Have you tried it?

I'm not down it it. I'm just pointing out practical issues that are a problem with a slow medium with a lot of data to move. Maybe some of them don't apply to UPB for reasons I'm not familar with.


Maybe I'm misunderstanding the whole thing. Is there some smart device that the controller talks to and that device is always in conversation with the modules and which always has current status, and always knows which ones are there and guarantees that it has recent status, so that the controller only has to ask the device? It looked like a fairly small and simple device and I assumed it was basically just a gateway for the controller onto the powerline network.

 

[Dean Roddey]

HCA saves all state information so after the re-boot, it was pretty much in sync. Anything out of sync (like a light switch that was activated during the 45 second reboot process) re-synced automatically once that switch was operated again. I never request all device status reports for this reason. Do other controllers behave differently?

'Pretty much in sync' isn't good enough. CQC takes the approach that it will NEVER tell you anything that it cannot prove to be true with a high degree of confidence. Anything else is unacceptable, IMHO. When automated decisions are being made based on the status of devices in the network, any status that cannot be confirmed with a high level of confidence should be reported as in error.

In CQC, when it starts up, or when it ever loses connection to a device, puts the driver into offline state. It will not come back online until it can connect positively to the device. When it device seems to be responding, it puts all the fields in error state and will get all their values proactively before it comes online.

With a system like Z-Wave or X-10 or UPB, i.e. a system in which there is more than one device so there's not a strict ok/not-ok state, the driver will come up and leave those fields whose values it couldn't validate in error until it can do so, so that no decisions will be made based on them until their values are known.

It does use async notifications from devices where that's the way the device works, but it will still proactively get all values updated in driver memory before it comes online. And, the driver will periodically ping the device, to make sure it's there and to make sure that no aysnc notifications were missed.

This is another advantage that ethernet has. If the connection between me and widget X is lost, even if I'm not there to see it, I'll know that. With most other connection types, serial in particular, it's perfectly possible for the user to unplug the cable for some reason, to move the device or get behind it or whatever, and then plug it back in. The control system has no idea what happened during that period. Only if it pings on a fairly regular basis can it catch that this has happened and reset and start proactively getting status again.

I honestly wouldn't want to use a control system that takes these issues less seriously than that. Some of the above is orthogonal to UPB really, I'm just addressing a general issue since it came up.

 

[Dean Roddey]

My Elk certainly doesn't need a re-boot

What happens when you have to load new firmware? Does it not reboot after that?

 

[AutomatedOutlet]

It could be nothing more than turning it off to move it. If it takes 5 minutes to get back in sync after you turn it back on, that's not very good.

This is not an issue with hardware controllers at all. When was the last time anyone moved their alarm system?

Does the module just keep trying to resend changes until it gets an acknowledgement back from the controller? What id the controller doesn't respond?

Yes, it certainly does with the HAI panels and I would suspect we will see that from the Elk panels soon too.

Maybe I'm misunderstanding the whole thing.

I think this might be the key.

Is there some smart device that the controller talkes to and that device is always in conversation with the modules and which always has current status, so that the controller only has to ask the device?

All the UPB devices are smart. The programming is stored in the end devices so a lot of data traffic isn't needed to activate complex actions. No, the controller doesn't have to ask the device. The device automatically sends the data when the status is changed.

It looked like a fairly small and simple device and I assumed it was basically just a gateway for the controller onto the powerline network.

Ah, you're talking about the interface module. Yes, you are right in that the interface module is fairly simple and it is basically just the interface from the controller to the powerline. The key though is the intellegence in the controller and the end devices (i.e. light switches). Once the end devices are programmed, and you have a powerful controller, it's a rock solid system that has ultra high reliability. Much more reliable and faster than a PC based system could be.

There are advantages with PC based systems though as well. With a PC based system you can do a lot more of the fancy things better like voice, video, IR, etc. There is a place for systems like that for sure but for basic automation and lighting control that is integrated with your security system, nothing can touch a hardware controller.

 

[kwilcox]

Damn, this HA stuff sounds pretty complicated B)

I must say I must not be demanding enough of my system to require it's precise syncronization. Heck, I wouldn't even need a controller if it weren't for the fact that I depend on my W800 for so much. As it is, my system tends to sync itself; a deliberate engineering decision I made during its design which makes the system more resiliant IMHO. If a light is on and the system thinks it isn't then when an associated sensor trips, it turns it on again and the staus generated resyncs the light. Conversely, if a light is on and it should be off, the system resets the next time someone walks into the room. During my "go to bed" macro, If my garage door is closed and the system thinks its opened, it tells it to close again which could open it if the system is out of sync with the garage door, but then the open sensor would trip, re-syncing the system and it would command it to close again.

I've never had any of the above events occur with my UPB devices btw because my controller has never been offline long enough. I've had the lights-left-on issue because my X10 devices don't send an ack to the controller to acknowledge their successful completion of the command. This was aggravating but UPB's ack provision cured it. My garage door has two position sensors so the system expects an associated door position trigger soon after it commands a direction and receiving the wrong trigger restarts the command as well as the system's perception of the door's position. Consequently, my garage door has never given me a problem either.

What are some good examples of HA behaviors that require the precise syncronization of the entire system at any given instant? Is this a paradigm issue?