need switches for new install, what to choose?

There are some issues with the UPB suggestions.
It is still a very early alpha release, Michael only has a few devices.
The install I am doing is remote and I need reliability and do not have time to 'beta test' new software
I also do not have the luxury of installing 'another' controller, especially one that I have zero experience with.
With this being a remote install I have to fly in, install 50+ switches, configure and setup the software, I do not have time for much else. I also need to be able to support these remotely.
I am considering the UPB, but right now the interface is way too new and untested. so far the only person that claims to have it running, successfully is Michael. And he is doing so on a very small scale.
I also need to have this running by the end of next month....

Sorry to be short, but I am getting a bit frustrated as I believe I have taken a completely wrong path with my initial HS server install and framework plans. In my future install for this person I will definitely be looking at another base platform.

thanks for the ideas and suggestions.

On a side note I may consider taking on someone locally (San Diego, CA) to help install/configure/consult/troubleshoot as my time for this issue is extremely limited these days.
 
When the primary criteria is reliability you have eliminated the PC platform as the brains. You need a dedicated controller such as the ocelot. The ELK is likely a good choice, but I cannot speak from experience on that one.

The ocelot supports X10 for quick and cheap and it supports hardwired for reliable.

As you know I do not have a long history with UPB, but I'm very impressed with it and would put it on par with a direct wired connection. It has retry, notifications, and signal quality measurement built into its core firmware.

I have two circuit panels. One of my UPB devices is 600+ ft from the controller on one of the panels. The PC interface is one one phase of the second panel and the two light switches are on different circuits, different phases of the second panel. My worst case signal strength is 70% at the 600+ ft IO node.

When you use the Ocelot with Homeseer you are using the COM interface between two processes. The COM is a memory to memory interface. When you use xapmcsUPB you are using a Winsock (LAN) interface rather than a memory interface with two processes running as with the ocelot.

The LAN protocol is UDP which does not have the reliability of the TCP/IP used for typical internet and browser communications. I have a very busy xAP LAN and I do see incomplete messages every once in awhile. In the case of the xapmcsUPB and other X10/BSC messages supported by mcsXap plugin the xAP schema uses an acknowledge on received command execution. No acknowledge on a command results in an automatic retry.

What this means is that PIM to UPB module powerline communication has built-in command-acknowledge-retry and the mcsXap and xapmcsUPB have command-acknowledge-retry and this all done transparent to Homeseer or any application using the interface.

If something goes astray in the bowel of Windows then it does not matter what design provisions are made in the software running on top of Windows. Memory growth, 100% cpu utilization, lockups and other gremlins are all to common. On deals with it with watchdog approaches within the PC, with external timers, or with other PCs with the ultimate objective of rebooting the PC. While this is a reasonable recovery approach, it does take the automation offline for the detection and revoery time span. Since there are various manifestations of bad PC behavior there needs to be many methods to monitor and this gets to be a complex operation.

Just as X10 and Insteon, UPB has a finite powerline bandwidth. I know with CM11A on X10 it has a window of opportunity to get onto the powerline and if it is not successful the information is lost. UPB is much more robust, but I did not study the design docs enough to know whre the limit is reached. I think the UPB bandwidth is 4x that of X10, but my memory could be wrong on this number.

When one designs their lighting scheme they need to put some thought into it to effectively use the system. Each UPB module will have 16 commands to which it will respond. One command could be setup to be an "All Lights On / All Lights Off / All lights Dim" so that a single powerline command will be acted upon by every module. The same could be done by running a HS script or DeviceAction with an individual command to each module. Clearly the simultaneous action rather than sequential action will have a more pleasing result and will conserve powerline bandwidth.

My scheme is very simple. Each of my interior lights is primarily controlled by motion with snap on to preset level when motion is detected and fade to zero at some number of seconds after motion stops. These lights also respond to All On / All Off commands as well as the single-tap, double-tap, hold manual actions at the rocker switch itself. This is all done with use of three commands programmed into the switch.

I would guess that setting up your UPB architecture using the UPStart configuration software will be the same level of comlexity as using the configuration software for ELK. You need to get a little experience with the technologies before you can sweep in, install, and make a speedy exit.

There are usually unexpected behaviors as one progresses on an engineering development. The same is going to be true for any newer technology you elect to use. Just because the setup at house X has 100 nodes working it does not mean that you can get 40 working. It is through time and experiences that all the variables and their interactions become understood and design solutions to accomodate them are implemented. As technology moves faster and faster solutions becomes obsolete before they can mature.
 
You know, if they'd only come up with a UPB wireless capable controller, 99% of all UPB installations would not required something dedicated. I'm thinking about a plug-in module that can fire 10 or so links based on a wireless reception from a handheld device. That way, you wouldn't need something to bridge X10 wireless through a W800. Extra credit if this device was compatable with X10 wireless signals such as the ones transmitted by HR12A or hawkeye devices. Simply dedicate a housecode to individual links. With such a controller installed, setup would essentially be arriving on site with a laptop/PIM and setting up the network along with any associated links. After that programming was accomplished, the system would work autonomously. You could easily offer home theater scene control, all lights off, and tied tracklighting. Heck, you could even do Hawkeye motion sensing all without the need for a central program running anywhere.

SAI: do you monitor this forum? hint hint...
 
kwilcox,
The concept of a very modular interface with local intelligence is the direction I'm going with xAP. The xapmcsUPB module is a computing node that can converse on the LAN and manage the UPB. It represents a prototype that runs on a PC for ease of development, but the long term direction is that this logic is embedded in a microcontroller. xAP has been implemented in microcontrollers such as PIC and Rabbit.

In my install of xapmcsUPB it listens on the LAN to know when sunrise and sunset are and it listens for motion from the W800. All the control logic for the UPB lights are contained within a script running under xapmcsUPB. One W800 motion action will generate multiple UPB link commands. The link command will result in status return which goes out over the LAN so Homeseer or any other computing node can do whatever they want with new knowledge of a change of status.

It is possible to build super nodes that contain a lot of related functionality. A combined piece of hardware that does W800-like RF and UPB powerline is an approach and it will have a marketplace niche. A manufacturer could buid a UPB interface with a NEC-RF, Zwave-RF, 433 MHz-RF, etc backside. This would tend to drive cost up and increase development cycles.

My preference is to use IP as the common glue that binds the pieces together. The IP provides the Browser access to the system for administration and remote user access and it provides a standard by which technologies (RF) and (UPB) can be used together. The cost of an IP interface is rapidly decreasing and there is no real competion to IP technology.
 
kwilcox said:
You know, if they'd only come up with a UPB wireless capable controller, 99% of all UPB installations would not required something dedicated.
You mean like Z-Wave?
 
I was only musing about something that plugs into the wall and translates wireless signals such as what might be generated by a hawkeye or X10 remote into UPB link commands sent over the powerline. I thought Z-Wave was a wireless network in and of itself and had no powerline transmission capabilities. I must confess though that I have zero knowledge of Z-Wave.
 
Yes Z-Wave is totally wireless so there are no powerline problems to worry with. There are many that have had problems with the USB interface but I haven't read one bad report using the serial Z-Wave controller.
 
kwilcox said:
I was only musing about something that plugs into the wall and translates wireless signals such as what might be generated by a hawkeye or X10 remote into UPB link commands sent over the powerline. I thought Z-Wave was a wireless network in and of itself and had no powerline transmission capabilities.
There are some software and hardware packages out there which speak both UPB and Z-Wave, so you can theoretically have the benefit of both worlds. So you could use a Z-Wave controller to activate a virtual Z-Wave node which activates UPB links, etc.

Chris
 
xAP has been implemented in microcontrollers such as PIC and Rabbit.

Rabbit makes the microcontroller in the Stargate web interface module. Does this mean I can communicate directly to my Stargate via xAP?
 
@Michael McSharry:

hmm.... interesting. However I was thinking of something far simpler.

Imagine a plug in device with an X10 style housecode wheel on the outside. Setting this would select the housecode that the device listens for X10 RF input on. Bringing up UPStart would show this device as programmable for 16 different UPB links. Each link would be enabled by an "on" wireless X10 command for the associated unit code of the selected housecode. Likewise, an "off" command would disable the associated link. An essential bit of additional built in logic is required that would keep powerline traffic to a minimum: Don't fire the link activation command if the link is already active. Likewise with link deactivation. Knowledge about active links is inherent to the UPB spec btw, so this feature is trivial to implement, but has far reaching reliability implications.

Now you have some functionality! X10 wireless remotes can fire links with an on command and disable them with an off command. Additionally, Hawkeye sensors can now initiate links and disable them too. With the above traffic minimization logic, large hawkeye installations would be feasable since additional triggers from the same Hawkeye device would be ignored if the link was already active.

Can you build this? I'd wager there's a few bucks in it too. I'd gladly pay $100 for such a device...
 
I haven't been in this hobby for very long, however from the beginning it made since that IP be the glue - it's everywhere and very standardized at least up to layer 4. Also 5-7 make it very flexible. I've been wanting to play with xap since I first heard about it but as with many of us the time/resources for the hobby are limited. Thus I've drifted more "mainstream" from this and the HS board.

While I think I've seen it somewhere, is there a xap primer - something to give an idea of not only what can be done, but a bit of what is involved?
 
I wish there was a decent beginner's guide in getting started with XAP. I don't even know where to begin. I referenced the sites on XAP, but there is no real setup guide.
 
Back
Top