Baffeled buy the direction of HA

[Dean Roddey]

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

Ok, the power glitches, or the user flips a breaker, or causes one to pop. It doesn't matter what it is. The point is, it's possible at any time for the control system, for whatever reason, to have to assume that it know longer can really be sure of the state of the state, and therefore it must go out and get that state proactively, before reporting the user that it is back in business.

If you have 200 modules, and it takes 2 seconds at best to ask each one what it's value is, then it's going to be 400 seconds, or 6.66 minutes, before the controller can reliably report the values of all those modules. And after a power event, that's probably a time when you'll want as quickly as possible to verify the state of the state.

Even if the controller is on a UPS, all of the modules are not. How do you know that one of them didn't go away? How do you know some of them didn't fail to restart?

You guys might not worry about these things, but as an automation system vendor, I stress about it all the time. All it takes is to get the automation system out of sync with one thing, and then a bad automatic decision to be made based on that, and suddenly the custom installer is getting an angry call in the middle of the nigh, and he's going to turn around and come after me.

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

And if, for some reason, it's not getting through? How does the controller ever figure this out if it does not continue going around the horn periodically and making sure that modules are there if it doesn't hear from them on a regular basis? it really doesn't matter if the module is smart enough to know its message isn't getting through. What matters is that the controller know this, and it can't if the messages aren't getting through. It can never assume anything, it has to go look itself.

 

[AutomatedOutlet]

Dean,

Ok, the power glitches, or the user flips a breaker, or causes one to pop. It doesn't matter what it is.

Dean, none of these things would affect a hardwired controller. They are on battery backup.

Even if the controller is on a UPS, all of the modules are not. How do you know that one of them didn't go away? How do you know some of them didn't fail to restart?

Well, after an outage, even though the panel doesn't go down, it will know that there has been a power failure. If you wanted to poll the switches after a power failure, you could. The likelyhood of a power outage killing a switch though is pretty slim. In that case you'll have to replace the hardware....

How do you know some of them didn't fail to restart?

When it's dark - just kidding B)

And if, for some reason, it's not getting through?

Again, I'm going to ask you. Have you tried the UPB devices? Once you try them, you'll see what we are talking about with the reliability.

 

[upstatemike]

I can give an example of why knowing the state is important. I have some lights controlled by momentary contact buttons connected to a digital input. The logic works like this:

If
...Digital Input Toggles

Then
...If
......A1 is ON

...Then
......A1 OFF

...Else
......A1 ON

...End
End

If the system doesn't know the correct state of A1 it may send the incorrect command on the first push of the button forcing me to press it a second time. (And we know from other threads that the delay from sending an X-10 command even 1 time is a problem so there is no way doubling the latency is going to be acceptable.)

 

[Dean Roddey]

Again, I'm going to ask you. Have you tried the UPB devices? Once you try them, you'll see what we are talking about with the reliability.

But that's not really the point. The point is, unless they are absolutely 100% reliable in the face of all of the wierdness that can go on, then the controller cannot assume anything, because if we get out of sync, we get the call, not the UPB folks. You are looking at it from the 'oh well, sometimes it might get out of sync'. I'm looking at it from the 'it can never get out of sync' standpoint, because that's the kind of guarantee I'm trying to make to my customers, who are not generally hobbysts. They want this thing to just work. And it can't just work if it doesn't practice a level of paranoia that would cause a human to be hospitalized.

I'm not trying to dis UPB, I'm trying to do the right thing for my customers. And there's no such thing as guaranteed unless the controller asks proactively and get's a reply, or it gets regular heartbeats from the device so that it knows the device is still there. Knowing that a device has gone away is every bit as important as knowing it turned on or off.

 

[kwilcox]

My system commands a UPB light and expects an ack. If it fails to receive the ack, it commands again. At that point, if no ack was received, I suppose I could status the device and if nothing was received from that either, set the device into a "broken" state and send an email or something. I've just never had an ack failure of any kind yet so I haven't programmed in the "device is broken" logic. I suppose if I ever start installing controller based systems, I'd do that. There's nothing like being proactive to homeowner issues and getting a call from me saying "Your system notified me of a problem with the bathroom sensor" might be something they'd like....

This thread's possibly in a badly hijacked state btw. My apologies for any instigation... Here's an attempt to tie it back.

New standards are emerging to address the need for more speed and reliability IMO. UPB and Insteon represent two different approaches to the solution. Neither will become like X10 in terms of low cost however, because both compete for market share. They are not alone either, so the market is further fractured making it less likely that the cheap switch won't be realized any time soon unless the older X10 protocol is its basis. Me, I'm quite willing to pay $55 for a switch that gives me the additional features and reliability of one of the newer protocols. I like many things about the SAI switches but must admit that I long for a UPB version of the Switchlinc 2380W. The illumination level bar on the left along with easy local ramp rate and level setting make this one fine switch IMO. It's too bad that SmartHome is in the other camp...

 

[Dean Roddey]

My system commands a UPB light and expects an ack. If it fails to receive the ack, it commands again. At that point, if no ack was received, I suppose I could status the device and if nothing was received from that either, set the device into a "broken" state and send an email or something.

That scenario is the same as sending a query and getting a response. It's the controller talking to the device proactively and getting a response. What we are talking about here is a much wider issue. What if you change it locally through the switch? Yes it sends a notification, but there's no guarantee it'll get to the controller. There might be a guarantee it'll *keep trying* to get it to the controller, but not that it'll get there.

So the controller cannot assume that this mechanism always works 100% reliably if it wants to be serious about guaranteeing to the customer that it's always presenting valid state information. Notficatiosn are fine, and they can lower latency in the 'all is working fine' scenario, but they don't get the controller out of the business of proctively going round the horn to be sure it's not missing something. Unless, the devices send a heartbeat, in which case the passive failure to receive a heartbeat in some period of time is proof the device is not getting thruogh or is not there, and getting the heartbeat is proof it is alive and well, or if it's a connection oriented protocol like TCP/IP where you know just by looking at the state of the connection whether the other side went away.

That's the basic gist of it. CQC never silently ignores your attempt to access a driver value that is not valid, or to write to a driver field that's not online. It's pretty hard to create a system that remains robust in the face of errors if the automation system doesn't insure that any data you access is good, and that any commands you send out actually went somewhere and were accepted.

 

[kwilcox]

@upstatemike:

Good example on your device toggle programming illustration. UPB treats those devices a bit differently. I believe its a deliberate attempt by the designers to avoid the programming situation you illustrate. The "toggle" state is actually kept in the device itself so when you press the controller's button, it actually sends a "link abc activate" or "link abc deactivate". If no links are tied to the button then nothing at all would be sent unless you had "send status when state changes" checked. In this case a status of the device's transmit element (button number) would be sent. If your controller captured UPB status, you'd get "<upb address of controller> <transmit element> status on" or "<upb address> <transmit element> status off" and could send the appropriate on or off commands.

 

[AutomatedOutlet]

Dean,

I really didn't want to get into a pissing contest so I'm just going to ask one question to you then - Please tell me what you think is a more rock solid system than UPB switches and a hardwired controller?

By the way, we have a dealer/installer base of close to 400 now, the large majority of them have all switched to UPB because of the reliability.

 

[kwilcox]

A missed status, if coupled with a subsequent missed command could create an issue I guess. I depend on my "lights out" macros to provide any final cleanup in that unlikely event. Double tapping off on certain switches by doors as well as hitting "blue fish on" (don't ask me to explain my 3 year old's naming conventions B) ) from the bedside controller accomplishes this. It could also be a good place to do a system-wide status poll too since everybody would be either gone or in bed and system activity would be minimal.

 

[Dean Roddey]

I really didn't want to get into a pissing contest so I'm just going to ask one question to you then - Please tell me what you think is a more rock solid system than UPB switches and a hardwired controller?

It's not a pissing contest. I'm making zero claims about the reliability of UPB. I'm explaining to you the realities of writing a solid automation system, something I know intimately. When you write an automation system, you simply MUST assume all the devices you deal with will fail, often for reasons beyond their control or even because the occupants mess with them when they shouldn't, and the automation system has to be prepared to deal with that, hopefully to recover but at worst to be aware of the problem and not let it silently continue.

It doesn't matter if it only happens once a year or twice a day. If I fail to deal with that gracefully, I'm going to be in trouble.

So don't keep trying to make this into a UPB Bad vs. UPB Good argument, because I've said a number of times it has nothing to do with that. It's like you would like to assume that your children will always do the right thing, but you have to, as a practical matter, be careful because they might not, and it reflects on you when they don't.

The earlier discussion, from which this has mutated now, was not about reliabilty, it was about practicality. From a practicality standpoint, a fast, wired system is clearly superior except on technical grounds, though clearly not if you need to retrofit or you can't afford it. A wired system can scale up very large and can be connection oriented if it is a network like IP over ethernet.

 

[kwilcox]

Let's take a look at the "person turns on a light" scenario. Now why would the system care about this? The most obvious reasons are: to automatically turn that light off if the person forgets or to activate a scene. If the scene based event is missed, the scene fails and to correct this you need very high speed polling or there will be a noticable delay. Are there any HA systems out there that can poll 200 devices in less than a second? I've never personally had a scene fail btw. This using switchlinc devices. Perhaps its because I tend to do scene lighting on the same circuit if possible.

Now lets examine the other reason. If the system will turn off the device after a timeout then either a sensor is there too (we don't like the lights going off if someone's in the room) or its a closet and the all lights off which inevetably occurs each night fixes it. Or its outside lighting and if the off doesn't automatically occur, the system works like the old manual house: someone notices that they left the outside lights on and turns them off or all lights off fixes it.

My point here is that you can get a lot of functionality even with X10 tolerances. My system is designed using the above rationale and UPB is making the manual or all lights off intervention a less common event. If low enough, then I will begin to install more than just simple home theater scene lighting. As I've stated before, I have high hopes for UPB.

 

[kwilcox]

maybe in a way, this discussion plays to the answer of the "where's that cheap switch" question that started everything out. As can be seen, there's a lot of intelligence required to make a rock solid HA system and this can keep device cost high.

 

[Dean Roddey]

Are there any HA systems out there that can poll 200 devices in less than a second? I've never personally had a scene fail btw. This using switchlinc devices. Perhaps its because I tend to do scene lighting on the same circuit if possible.

It doesn't necessarily need to be 200 devices a second. That's generally not practical. It just needs to be some reasonable period of latency. 5 minutes is not reasonable, 5 seconds probably is for that many devices. There is always a chance, if you depend on instant feedback, that you will fail on any system. You do have to be reasonably forgiving.

But that's not really related to what I've been talking about, at least in the latest mutation of the thread. I'm talking about how do you know the state of the state within some reasonable amount of latency, and that includes knowing that somehing has been unplugged or stopped replying or failed in some way. It's a 'purely passive controller' scenario vs. a 'purely active controller' and various gradients in between. You cannot through purely passive means be aware of the state of the state, because by definition that requires that you are told everything that happens. But, if one of the things that happens is that something stops responding, maybe because the kid unplugged it and is now shoving a jelly sandwich into it, you cannot be made aware of that through passive means.

 

[smee]

It's like you would like to assume that your children will always do the right thing, but you have to, as a practical matter, be careful because they might not, and it reflects on you when they don't.

This is completely off-topic, but the last part of this quote really bugs me. I'm sure it's just a poor analogy.

 

[rocco]

I believe Dean has legitimate concerns, based on his position as the provider of control software. And I believe most everyone else has good reason to be happy with the reliability of UPB.

But UPB is not failsafe. PCS has never stated it was 100% reliable. Here are two situations where things can get out of sync, and Dean's software would have to try to recover. It would not effect the rest of us.

Links.
Many devices can be programmed to respond to a link. That is the purpose of a link. Because of this, an acknowledgment is not generally requested on a link command, and if one was requested, only one device would need to respond to satisfy the request. In this situation, the controller needs to follow up by individually requesting the status of each device that belongs to the link. (BTW, Insteon has this same issue with their Group commands.)

Manual Operation.
When a switch is manually operated locally, a broadcast packet is generated. Since a broadcast is not directed to any particular device, it is not acknowledged. If it is lost or garbled by noise, no one would know.