Hardware Feature comparison?

WayneW

Senior Member
I know we have all been debating the pros & cons of these (and any others I missed?) technologies. But what truly makes them different? In other words, what features might one system have than another does not?

I know that any of the new technologies are supposed to be significantly faster than X-10. And I don't really consider reliability or failure rate a feature, although it can affect a purchase decision, along with price.

Personally, I have never tried to use scenes in hardware. I believe that all of these support scenes, although some are easier to use than others.

So what makes these guys truly different from each other? Can one of them do something useful that the others cannot?
 
I believe the only way to solve this would be for some knowledgable person (or better yet persons) to incorporate each technology in their home and run them through a test phase for a couple of weeks, noting the pros and cons of each.

It would help the manufacturers of each of these items to provide their products for this testing suggestion as it would clarify issues and hopefully get people to decide which technology they would like to purchase.

I believe Wayne is correct as there are a lot of people waiting "on the fence" who want to jump in and purchase one of these technologies, but are unsure of each feature and desired performance.
 
Well, I run X10 and UPB, specifically SwitchLinc 2380/2381 and SAI US-11 switches. I can say that the UPB devices respond about twice as fast as their X10 counterparts. The SAI 1000 watt dimmers are cheaper than their Switchlinc counterparts as well. UPB devices always report their status so a scene command will correctly update the status on your central controller for all affected devices.

I'm also using a UMI32 to control my HVAC system. It replaces two universal and one powerflash module. I've not had an issue with this setup yet. I have had an unexplained event in the office however. One time, I noticed that the light attached to a UPB lamp module was lit. Normally, this light is only activated as part of the office "lights on" link triggered by a hawkeye sensor or a single tap on the office overhead light switch. My central controller showed the lamp as lit and the logs recorded the "on" status sent by the module, but it appeared that no command to turn it on was issued.
 
kwilcox,
It may help if you mention the software interface your using if your even using one. The reason I say that is - When I click on my X10 light switches the light immediately comes on so it would be hard for a UPB switch to be faster. I'm using HomeSeer as my interface and I can issue a command from the HS GUI and my X10 lights come on nearly instantly. When I issue this same command via the TouchPad HTML interface it takes less than half second to turn the lights off. I use the PowerLinc USB as my X10 interface. I used to use a CM11A and the PowerLinc is about twice as fast. The TI103 is supposed to be even faster. I'm mentioning all of this as a point of reference so others realize that "twice as fast" is a very relative term and may not be as important as the other UPB benefits.
 
Good point. I'm using HCA with the houselinc X10 interface, a W800RF and a PCS PIM. On my X10 devices when I see a hawkeye trigger, I can always count "1-mississippi" before the lights come on. With UPB its about half that; noticably faster at any rate. Keep in mind that my hawkeye sensors don't directly control devices, rather they start programs which in turn control devices if necessary. However, the difference is consistent with the fact that the UPB powerline protocol sends twice as much data per cycle as X10 and the X10 command is slightly longer.

For example, using X10, turning on a device is 100 bits/zero crossings (send start then h/u twice, followed by gap, then h-on twice followed by gap). The UPB equivalent takes 40 zero crossings (80 bits consisting of 10 bytes: Preamble, 2 byte Control Word, Network ID, Destination ID, Source ID, "Goto", Level, Rate, Chksum). Using X10, 100 zero crossings takes about .8 seconds and UPB's 40 zero crossings take about .35 seconds.

Things get even faster when group commands are compared. IIRC, the X10 command to light up a group is start, h/u twice, h/u twice, h/u twice etc... gap, h-on twice, gap whereas the UPB link command is still only 80 bits. This is because the link itself is a unique id stored by all associated devices, so the command's destination ID simply specifies the link identifier instead of a device address. As such, the UPB link replaces X10 groups as well as scenes because the devices also store a level and rate for the link. However, this can be overridden by the link command.

BTW: UPB achieves 2 bits per zero crossing by sending precisely timed pulses at about the 50V level of the 120V AC sine wave (thus the 50V UPB signal claim). These pulses can be in one of 4 locations on the sine wave depending on the value: 00, 01, 10 or 11. This is also the reason for the resiliency of the UPB signal. The spike doesn't appear at the zero crossing point so most noise filters tend to ignore it while the 50V signal itself is much less prone to attenuation. However, the drawback to this scheme is that 3 phase wired buildings do not do UPB well without complex signal regeneration devices attached to all 3 phases.
 
Well, I had another incident of my UPB lamp module glitch last night. This time I went into UPStart and disabled the manual switch activation feature. Like an X10 lamp module, this module can sense a mechanical off-on transition of the lightswitch to turn on the lamp. We'll see if this solves it...
 
I don't use this feature on my lamp modules... instead my HVPro can toggle the light based on an IR command (based on the room I'm in, etc) so I never used it (easier to hit 01 on a remote than it is to manually turn on the light). I've never had a problem with my lamp modules.
 
Yeah, I don't use it either. The feature just defaults to "enabled" and I never bothered to change it when I first installed the module....
 
kwilcox said:
Good point. I'm using HCA with the houselinc X10 interface, a W800RF and a PCS PIM. On my X10 devices when I see a hawkeye trigger, I can always count "1-mississippi" before the lights come on. With UPB its about half that; noticably faster at any rate. Keep in mind that my hawkeye sensors don't directly control devices, rather they start programs which in turn control devices if necessary. However, the difference is consistent with the fact that the UPB powerline protocol sends twice as much data per cycle as X10 and the X10 command is slightly longer.
Hi kwilcox

How is performing your HCA software. I like HCA too and I would like to hear your experience !
I´m using CM11A, have you used HCA with CM11A ?

Tell me your experience please, I will loved to hear it !!

Best ;)
 
I use a houselinc controller with HCA Plus running on a server grade, dual PII Dell. I also have a CM11A and did try it but I found that the houselinc had better performance. I've also tested the Powerlinc USB interface and that works quite well too. I find HCA to be very easy to use and quite powerful. I have a houselinc, W800RF and a USB version of the PCS UPB PIM attached and it works with all of them. The visual programmer is an especially nice feature IMO. I am, however, having a verifiable issue with my W800RF module: when two hawkeye motion sensors get triggered simultaneously, neither of them are recognized or logged. I am currently working with HCA to determine whether this is a W800RF issue or an HCA issue. The problem is quite easy to duplicate: simply set two hawkeyes having the same housecode but with different unit codes next to each other and trigger simultaneously. HCA logs will not show either of the two "ON" commands. I have not repeated this test using different housecodes yet though.

UPStart, the programmer for UPB modules, was written by the same company: Advanced Quonset Technology inc. btw.
 
kwilcox said:
. . . when two hawkeye motion sensors get triggered simultaneously, neither of them are recognized or logged.
A little off topic, but this should be expected. X10 RF encodes it's broadcasts as ASK, so two devices would garble each other if broadcasting simultaneously. It's like two AM radio stations broadcasting on the same frequency.
 
If I were you, I would install a trial copy of Girder, or Homeseer, or HAL, or any other package which supports the W800, and found out that way to see where the issue is. You could even use hyperterminal , just trigger the sensors seperately to see how it shows up in hypterterminal, then try them at the same time.
 
rocco said:
A little off topic, but this should be expected. X10 RF encodes it's broadcasts as ASK, so two devices would garble each other if broadcasting simultaneously. It's like two AM radio stations broadcasting on the same frequency.
This is exactly what I thought originally. I only got interested when I read a thread on this forum where one user was experiencing this same issue and others with large hawkeye installations posted to say that they were not. When I found the other poster also used HCA, I got really interested.

@electron: That's a very good idea to use hyperterminal to test this! Thanks! At least then I'll be able to either verify the collision or determine whether there's something unusual about the way the W800 handles simultaneous reception.
 
by kwilcox:
when two hawkeye motion sensors get triggered simultaneously, neither of them are recognized or logged.
This may be a stupid question (has never stopped me from asking) but do those hawkeye motion detctors have the same X-10 house and unit code?
 
No. Same HC but different UC. In my test I used D10 and D11. I'm going to try the hyperterminal test and if I get encouraging results I'll repeat the test using HCA and different housecodes.
 
Back
Top