Medium-size UPB Installation Experience

[ChrisWalker]

Well, I too am a little surprised by your installation difficulties and ongoing noise issues.  I'm also suprised to see you actually had UPStart go "belly up" on you.  What version were you using?  I noticed it happened as it was searching for a PIM...  Does it always crash when its searching for the PIM?  For that matter, what PIM are you using?  Maybe that is part of the problem.  I myself use a PCS USB PIM and I haven't had any issues with it.

It's the latest version, which we downloaded from the Simply Automated website: v4.2, build 71. I spoke with one of their techs, and he indicated that he had experienced crashes as well. The crashes also occured in other situations, such as trying to turn a device on or off. I am attaching another screenshot. For the PIM, it's the standard Simply Automated serial module. I wish it were USB.

I use UPB switches to control low voltage tracklighting - I have halo tracklighting with transformers on the individual lights - and haven't noticed any problems, nor have I encountered any of the noise problems you are seeing.  I use the US11 switch body however so it may be that SAI is having issues with the newer version that you are installing.

It's interesting that almost all of the track lighting (low voltage) works great with the newer SA US2-40 switches. It's just a few of the circuits that have problems, and it's really bad on one in particular.

What do you mean by "real time status updates" btw?  I set my switches to ACK on successful command completion, but I don't know of a way to get my devices to periodically send a status out without being polled.  Is this what you refer to as being potentially problematic?

The switches can send out a message when they are turned on manually, which is important when designing a GUI/event-driven software package to show which lights are on vs. off, to fire off events (like a timer when a light or fan is turned on). But in a situation where a UPB command is already being transmitted when a person flips a switch, or a user turns on a number of UPB switches at the same time, especially ones who have their retransmit count cranked up, a lot can get lost. So it becomes necessary to check up on all the switches in the background (which then adds more traffic, unfortunately).

But for installations where the switches are self-contained and don't need to interact with other smart systems which need status updates, UPB should work much nicer. And with enough software wizardry, I imagine that a good compromise could be made with the way it works now. Also, if UPB gains collision avoidance intelligence, this whole issue may become less problematic.

I'm also intrigued by your reliability issues.  I have a virtual 3 way set up for the library spiral staircase which controls tracklight stair illumination as well as a recessed overhead and haven't had a single problem.  Did you install a phase coupler?  This is recommended for all UPB installations btw... perhaps you had the same issues I had with computer UPS devices.  Does the entertainment system have a UPS in it?  Also, just a wild thought, but this house has standard split single phase service right?  I'm using the PCS coupler attached to my dryer circuit but would go with the SAI version that installs as a double gang circuit breaker if I could only find one somewhere...

Yes, yes--very good advice. The house does have split-phase. We did install the new SAI wire-in phase coupler (since there was no room for the circuit breaker one) across one of the 220-volt appliance set of circuits. The virtual 3-way works nicely--it's the status update on the LED of the "virtual switches" that needs the retransmits to make it through mostly. 2 attempts didn't cut it, but 4 attempts seems to work well, at least in our time-limited testing.

Chris

 

[kwilcox]

Ahh.... got what you mean about "real time status" now. That's how mine are set too. I didn't consider collisions to be much of a problem because simultaneous switch operation would be a relatively rare event for me. I just don't have a lot of powerline traffic in my 1900 sq ft ranch with only 30 or so X10/UPB devices.

 

[bfisher]

For the PIM, it's the standard Simply Automated serial module. I wish it were USB.

I use a USB - Serial Converter ... works well - no issues with UPStart

 

[PeterW]

I've had a few "strange" things happen with my UPB setup. I can't really put my finger on it. Sometimes switches or modules just disappear for a while. Particularly ones in the kitchen.

I'm starting to suspect the passive bridge (capacitor) in the breaker box somehow. I ran a few extension cords before we left on a 3 week trip to get all my UPB modules on the same phase as my computer and the problems went away.

I'm a little concerned about the audible capacitor discharge noise that the devices make when they transmit. It makes me wonder if the caps are degrading over time or something, or might in the future. The audible noise is certainly a big negative in the WAF equation.

Until recently, the system had been absolutely reliable. I've been using it for lighting and water controls on my 30+ fish aquariums. I'd been using HCA for controlling the UPB modules, but after months of frustration at HCA problems I eventually gave up and wrote my own stuff instead.

I wish there was an active phase repeater/coupler like PCS use for UPB.. err... I mean "pulseworx".. on commercial buildings.

 

[Dean Roddey]

But in a situation where a UPB command is already being transmitted when a person flips a switch, or a user turns on a number of UPB switches at the same time, especially ones who have their retransmit count cranked up, a lot can get lost. So it becomes necessary to check up on all the switches in the background (which then adds more traffic, unfortunately).

Which was my whole point from a previous thread a couple weeks ago. Nothing gets you out of the requirement for polling in the end if you are going to implement a really smart home, so you need the bandwidth to do it. Async notifications helps, because you don't have to poll as often and you can avoid polling a module you just heard from recently via a successful async notification. But you still have to do it, and when there are a lot of modules, it's just not possible to do that with a low enough latency unless the network is pretty fast.

Neither Z-Wave/Zigbee nor UPB meet this requirement, unfortunately. Probably IP based or hard wired systems will be the only ones that do. That doesn't mean Z-Wave, Zigbee, or UPB aren't useful. But, if you have a large system, unless you are willing to give up two way on all but a core set of modules, or to accept being out of sync with all but a set of core modules (i.e. never depend on their current status in automation logic), they are not going to be acceptable and you should look to a hard-wired system of some sort, IMHO.

 

[kwilcox]

I'd been using HCA for controlling the UPB modules, but after months of frustration at HCA problems I eventually gave up and wrote my own stuff instead.

I also use HCA but haven't had any UPB related issues. What specific problems did you have with your UPB setup and HCA?

 

[ChrisWalker]

Neither Z-Wave/Zigbee nor UPB meet this requirement, unfortunately. Probably IP based or hard wired systems will be the only ones that do.

Without hijacking the thread here, I will respectfully (and politely) disagree Z-Wave has built-in delivery confirmation, collision detection/frequency hopping, and live status update capabilities, making it ideal for both small and large installations.

The other protocols have their pros and cons, but I do not think that it's necessary to move to an IP-based or proprietary hard-wired system to achieve these goals. At least technology-wise.

Chris

 

[Dean Roddey]

Without hijacking the thread here, I will respectfully (and politely) disagree  Z-Wave has built-in delivery confirmation, collision detection/frequency hopping, and live status update capabilities, making it ideal for both small and large installations.

Maybe I'm still not really getting my point across. It doesn't matter if it has all those things, which UPB does as well (plus all the modules report status.) The point is that if you want the controller to know abuot the status of everything, and it must if you want to create a truely smart home, it cannot passively sit and just accept notifications because, as you just reported above, they don't always get there. Since they don't always get there, the controller will not reliably know the status of the devices unless that controller is always asking them for their status, since that's the only way it will know if a module has gone away (and therefore the value it has for that module is not reliable.)

Or, alternatively every module must send out regular heartbeat messages at a fairly reasonably clip, like every 10 or 15 seconds, so that the controller can always know if they are there or not and what their status us. If it doesn't hear from one in that period of time, it assumes the module is not working or offline and makes the user aware of that fact proactively, and it fails any automation logic that relies on the value of that module, instead of just silently going through the motions with out of date information.

Those are the only two ways you can create a truly robust system, and neither Z-Wave nor UPB can do that in a large system because they don't have the bandwidth.

As I said, that doesn't mean they are useless at all. I use Z-Wave, and in a system of my size, it's perfectly acceptable. The modules can be polled actively in a quite reasonable time, and therefore the controller can always know if a module is responding or not. And in a bigger system, if I was willing to make a good number of them one way, and I probably would, it would be still be ok.

If you aren't really trying to create a smart home, and you are just using these things for lights, then ehhh... it's not such a big deal. If you get out of sync, perhaps it's no biggie. But I wouldn't trust any really serious to it unless the controller can actively poll it or it sends active heartbeat messages so that the controller can know that it's current knowledge of that module us reliable. And when I say serious, I mean where automation logic is reacting to the status of the module without human intervention in a way that the results would not be good if the controller had no idea it was out of sync with the module.

 

[Dean Roddey]

Oh, as always, assume there's a "unless I'm really missing something" tacked on at the end there. I'm putting forward what I believe to be the nature of these two systems, and if I'm wrong then of course the whole premise of my argument is without merit.

And, in the end, it's not about either of these particular systems, it's about the generic issue of what it takes to make a truely reliable system. And I don't believe that Z-Wave or UPB can do that. I believe that they are reliable enough for most folks, in a reasonably sized system, or where two way of a lot of modules isn't required. But if you really want to make a foolproof system that can go into Mr. and Ms. Nontechnical's house and then create automation logic for them that does non-trivial stuff and always either works or tells them to call for help reliably, then you need a system where the controller always knows, with low latency, the state of the state.

That's my basic premise, and that a pure async notification system cannot achieve that.

 

[rocco]

Dean, I would have to respectfully disagree as well, with regards to ZigBee.

I understand your point, and it certainly applies to UPB. I do not know about ZWave.

it cannot passively sit and just accept notifications because, as you just reported above, they don't always get there.

and here is where your concern doesn't apply to ZigBee: The notification is guaranteed to get there. When a 'binding' is created between devices, the coordinator will insure that the notifications are delivered and acknowledged. The coordinator also handles the heartbeats and is responsible for any necessary polling.

So, in effect, all of those things that you need to do are already being done at the network layer in ZigBee. It has to be. ZigBee's largest market is industrial automation, where you can't afford to have your devices out of sync.

 

[Dean Roddey]

Ok, I thought Zigbee was closer to Z-Wave than that. So, Zigbee is mostly off the hook if you are correct

Just for funzies though, what happens if the controller is offline for two days and you've got 600 modules out there? How does it get back in sync with that many modules that it has to proactively gather the values for over a fairly low bandwidth network? If it takes 2 seconds on average for a response, that would take 20 minutes just to get into sync again.

 

[Steve]

Just wanted to add my $.02 regarding my very small UPB installation. I only currently have 2 switches - 1 SAI and 1 HAI. Aside from the issues I brought up in THIS thread, I only have 3 observations so far.

1. I too have had less than optimal luck with UPStart. I am using SAI Version 4.2 Build 71. When I went to add my second device I had all kinds of problems with the SW, well at least I think it was just the SW. After putting the switch in setup, UPStart went a little nuts. It showed flashing yellow boxes all over the place during discovery. Finally when it settled down and I started to config the switch, it failed during writing and I had to start over. It started showing no signal, etc. It took me about 3 or 4 tries to finally get the switch added. It was very frustrating for something that should have been very simple. With everything added, things seem to work ok.

2. Also related to the SW, it seems the MFG may 'tweak' the pages for their HW. For example, if I go into the config for a US11 then go to Advanced Tab, there is a section title 'Rocker Options' which has settings for "Load controlled by rocker" and "Store Last Level". If you Edit an HAI device (35A00) those options aren't there. I haven't tried the HAI provided SW because it was a rev back. These options seem generic and curious why they only show up for SAI dwitch?

3. Maybe it is just me, but I have been experiencing some difficulty with adjusting dim levels from the switch. Several times (especially with the HAI switch) when you dim or brighten load to certain level and save it, the next time (assuming the last on level is checked - which SAI has separately (see 2) is may or may not come to last level - sometimes it goes to full bright. Sometimes it doesn't save the last level - ie. brighten them to say 40 or 50%, shut them off, then back on, it goes to 100%. Also, I have noticed a 'bounce' in the light. Say lights are on around 80% and you press and hold bottom to dim, release at say around 20% - many times the light will brighten back up a bit when you release bottom rocker - or when you release it will brighten for a second then come back down to what you set. Kind of hard to describe. It's a bit annoying sometimes but livable.

Because of some of these strange issues combined with the fact that my x10 switches seem to work fine now after installing a phase coupler/amplifier, I may just hold off a bit and see how well Insteon compares. All said and done there prob will only be a dozen or two total switches.

Martin: You have UPB switches installed - what kind of experiences have you had?

 

[Dean Roddey]

Actually, I should have called you on this one:

and here is where your concern doesn't apply to ZigBee: The notification is guaranteed to get there.

Actually, that's not possible. All it can do is keep trying to send that notification. But if there is some problem between it and the controller the controller cannot know anything is wrong unless the devices all send heartbeats or the controller polls them.

If all Zigbee modules send heartbeats, then Zigbee has it covered. But the fact that a module proactively tries to get a notification to a known place still isn't good enough because it's the controller who needs to know the notification isn't arriving.

 

[upstatemike]

Some really good points in this thread but I need to catch up on some things I may have missed (or misunderstood):

1- I agree with Dean that bandwidth is important in a large installation for the reasons he detailed. What I don't understand is why these new technologies (Zwave, UPB, Insteon) were designed to be as slow as they are. If you are designing something from the ground up to replace 1970s technology it should be magnitudes faster, not 8 or 10 times faster. Something like the performance curve in PC processors over the same time span.

2- If Zigbee is doing so well in the industrial arena what is the holdup in producing consumer products?

3- There are lots of technologies for transmitting high bandwidth signals over power lines. Adapters to send ethernet, video, and telephone signals over home power wiring are common and cheap. Why are none of these technologies being adapted to make high bandwidth switches?

 

[rocco]

You're right. To say that "a notification is guaranteed to get there" makes me sound like a marketing person. I will attempt to be more specific. I will try to keep it short and simple.

ZigBee has no controllers. It has two types of devices: Full-Function -Devices (FFDs) and Reduced-Function-Devices (RFDs). A battery operated device would typically be a RFD, while a device that is powered by AC would typically be a FFD.

If called upon, an FFD is expected to be able to:
Act as PAN-coordinator (Master of the Personal-Area-Network)
Act as a coordinator (sub-coordinates for the PAN-coordinator)
Route packets under direction of a coordinator
Hold down it's day job (like controlling a light)

When an FFD powers up, it tries to join a PAN. If it finds none, it creates one and dubs itself the PAN-Coordinator. As other devices come alive, they join that new network, and some may become additional coordinators. Routing tables and binding tables are constantly updated (yes, polling takes place) and replicated across the network. If a coordinator disappears, another FFD is selected to replace it. If the PAN-coordinator disappears, another coordinator is elevated to PAN-coordinator. If all coordinators should disappear, the remaining FFDs would form a new PAN. If some device swamps the frequency that the PAN is operating at, the entire network moves to a different channel (there are 16 ZigBee channels in the 2.4MHz band). No single point of failure should cause the PAN to stop operating.

I would assume that the FFD that is hooked to the computer running CQC (call it the 'interface') would have a binding with each device that CQC cared about. When the device changed state, it would inform it's coordinator. The coordinators would then see to it that all devices with a binding to that device are informed. As long as the interface has a binding and is still connected to the PAN, it will get a notification.

If the device could not inform the coordinator of the change of state, the coordinator would eventually realize it had not heard from that device, and the entire PAN would search for it. This is what facilitates a ZigBee device to move around. If the device cannot be located, CQC could eventually get a notification that the device has left the building.

sorry that that wasn't as short as I would have liked.