I'm having trouble with the Elk and simply automated UPB's.

First, I want to be able to distinguish whether a UPB is activated via the Elk or turned on from the switch or some other device. I'm using the "whenever light XX is turned on by some external device" rule, but it doesn't show "true" I turn the light on at the switch. Am I missing something?
The second problem is that the elk does not appear to recognise when a light is turned on or off via a link. Any ideas welcome.
Thanks

In UPStart on the "Options" tab for each switch, there is a checkbox "Report light level after any button or rocker is pressed". If you haven't enabled this, you will need to do so.

Doug

What Doug said...


But note also that this wont fix the problem with the Elk knowing about link activations. Further, the web interface of the M1XEP doesnt play very
nice with UPB. If it happens to think something is already on (or off) it wont send an on (or off). And even more surprising, if it thinks a device is on and you move to a lighting page that shows it as on, it will send an on command! Combine this feature with the lack of link tracking and you'll soon realize that, as far as UPB is concerned, the lighting interface on the M1XEP is not very useful.

I had the checkbox doug suggested checked, and that worked for non-link activation. I noticed in the m1xsp manual the following
"Limitations:
UPB modules will not send their recent status changes in response to link commands. Therefore, the status displayed by the
M1 Controller may not always match the true status of UPB devices if they have been controlled by a Link command."

Have you tried tracking the senes (193 and on ) - that's my next try!

I see what you mean about links - they are not really on/off switches!!

Power Home Automation 2.1 fixes this issue with LINKS, ELK and direct access commands. Whenever I turn a link off, I am able to update all the lights on the link so that RM is correctly showing status.

-=*Sharby*=-

What is this "Power Home Automation 2.1"? Hopefully you aren't referring to Dave's PowerHome as many people don't want to run a PC 24/7 to enable lights to function correctly, especially if they already have an Elk.

Hopefully UDI will come out with a UPB version of the ISY this coming year. The UDI guys really know how to make a standalone controller that plays well with the ELK (kept the ELK informed of any changes in device status) I am NOT knocking Powerhome at all. It is a great piece of software as is Homeseer but I prefer a standalone device that does not need a PC running 24/7. When I used the ISY with Insteon I thought that the ISY was near perfect. Again hopefully a UPB version is coming soon.

That's how I feel - no PC please. Has anyone had any luck detecting link commands with the Elk - If I could recognise these, I could turn the UPB units on from the Elk, which would serve my purpose. The link commands are defined as on/off switch on the elk, which makes no sense to me.

Unfortunately, PowerHome is the ONLY working solution for the UPB ELK issues. I've worked with ELK, PCS, Webmtn, and PH for over a year and this is the only solution thus far. I've been looking at mini PDAs with serial support that would eliminate the 24/7 full blown PC solution for you. It's unfortunate that ELK will not being upgrading their M1 firmware for this issue.

-=*Sharby*=-

I don't understand why they would say that. I have a house full of Simply Automated UPB devices, and they most certainly report their status when it is changed in response to a link.

Doug

UPB devices do not report their status when it is changed in response to a link. The best they can do is to report that they have received a command. As configured from the factory, the SAI devices dont request an acknowledgment when they transmit a link. Likewise, when the Elk transmits a link or any packet for that matter, it doent ask for an acknowledgment either. The only time I know of when an SAI switch will report status is when it is configured to transmit its status on a button press. This helps the Elk a bit, but not quite enough. So, even if the transmitting device were to request an ack from the receivers, the driver would still have to be smart enough to know which devices were linked and what commands they send themselves when the link is activated... or it could simply poll each device for status after it notices a link command has been transmitted. The former is difficult for a couple of reasons. Just consider a long slow fade rate, the latter sounds easier but suffers from the same problem as the former and if there are many devices in the link, the UPB bus will be jammed up for some time while the polling is going on (at least 1 second per device in the link).

I am not trying to imply that it's impossible to get right... but it is enjoyingly difficult.

If Upstart can do it, then Elk should be able to do it also.

I just want to make sure that nobody is confused by your first sentence above. I think you meant to say "by default". I have SA switches and I've enabled "Report light level after any button or rocker is pressed". When a button is pressed OR when a link is received, the switch sends a UPB message reporting it's new light level. I assume this is true of all vendors.

Doug

That is not true. When a Simply Automated link is received, it does not report to the Elk that the status has changed. Only when a rocker is pressed AND that rocker is assigned to a load.

I just talked to SA and they confirmed

Has there been any progress on this issue? It's annoying that the M1 incorrectly reports the status of my lights, but I'm considering using a UPB module to control my sprinklers and I definitely want to know when those are on or off. I haven't checked here in a while and was hoping there may have been a firmware update or other solution?

Thanks,

It's not something ELK can fix It's a UPB 'limitation'.

Thanks. And something tells me that SA would say it's an Elk limitation ;-)

Are there any other workarounds then? I seem to remember a thread that I can't find now which described a way to have all of the transmitters send link commands to the Elk, and then the Elk would send different sets of link commands to the receivers. This way the Elk would always know and report the correct status of the loads since it is the only device that is transmitting links to the receivers.

Is that right or am I hallucinating?

[Edit: I found the previous thread at http://www.cocoontech.com/forums/index.php?showtopic=5978]

Links are just numbers to an ELK or other controller watching the powerline. So by itself, and ELK could never know which switches are to change when a link is activated, but it could be resolved. The UpStart file contains this information, which is how programs like HomeSeer CAN respond correctly to link changes. Also, HAI somewhat gets around this problem as well, IF and only IF you use its internal link creation and management. If you program your links in UPStart, HAI works like an ELK. ELK would need some type of utility to import a UPStart export file, and use that to tell it which links control what. Certainly possible to do, but not at this point.

I was planning on trying the following simple idea when I get the time:

Switches are A, B, C where A has the load and B and C or virtual 3 way etc.

When A is turned on and off the ELK sees its status change (no problem)

When B is turned on and off dont link it directly to A but have the ELK see it. So When B is turned on turn on A and when B is turned of turn off A though the ELK. Since teh ELK will be telling A what to do it will know the status of A at all times. Do the same for C.

Not sure it would work but it seems like it would.

UPB Link commands will always be problematic. A lot of us were just wishing Elk would implement the capability of an M1XSP to resend a direct command to a device if it doesn't receive an ACK back. Currently it doesn't even do that...

It's most certaintly NOT a UPB limitation. The protocol has full support for link tracking. There are even controllers out there that get it right. It's just not easy and takes a bit of program space and RAM. The Elk is very short on both. I will, at least, agree with the first part of your statement.

Which controller supports tracking each device, via a link activation, without being the device responsible for activating that link (or have an internal database which requires manually entering/configuring which device belongs to what link)?

Hmmm... clever change of subject ;) But it's a great question. Assuming you dont consider upstart to be a controller, the only controller I know of that fits your description is my own (not yet released). Since the protocol supports it, I'd think others have done it too. But I'll admit to not having done the market research.

The trick, as you point out is having that internal database. The protocol supports querying each device to determine which links it responds to and what it does in response to receiving the link. That's what I do. Another other way to get this information is from reading the upstart export file. This approach is a bit easier and seems to be what most others are doing. I dont have a list of the controllers that do this so I'll have to hope others will chime in here.

My point was that controllers can choose not to implement or make good use of the protocol. But it's their choice, not a limitation of UPB. In the case of the elk, it would take an external processor with a bit more memory to pull it off.

If you are interested in hearing about the features of the UPB protocol that make it all possible, I'd be happy to get you started.

Well you haven't proven me wrong yet From what I can tell, a UPB device still can't broadcast a status change whenever they respond to a link command. You are relying on a database (which will probably take a while to generate if you have a good amount of UPB hardware) to compensate for something which UPB devices don't support, unless I misunderstood you.

Would love to learn more about that controller of yours tho, sounds very interesting

I am not quite sure what I should be proving. Your first statement was that Elk couldnt get it right because of a limitation inherit with UPB. My response was that the Elk couldnt get it right because of it's limited CPU and memory resources. A weak position would be that we are both right. To some extent we are.

When it comes to the limitations of UPB it might be helpful to spell out exactly what is lacking. From your comments I'm assuming that you think the problem is that UPB devices dont broadcast a status change whenever there is one. I'd have to agree that would be a great feature especially if the goal was to make it easy to implement a controller. Sadly, engineering is all about trade-offs.

The root of the "problem" with implementing that feature, in my opinion, is the low bandwidth of the connection between the devices. 30 bytes (or so) per second over a broadcast medium isnt all that much. Now consider that a device status report can take up to 23 bytes. Most only send about 10 but that's still 1/3 second. The fun starts when a link with more than just a few devices is activated. Now you've got all these devices all trying to reply at the same time and having to figure out if their reply made it to it's destination. Imagine a link with all 250 devices, it could take minutes to sort itself out all the while your button presses at the switches would have to fight for a chance to send their messages. While this is a solved problem (ethernet works like this) it does put a bit of load on the individual device and, to work in a timely fashion, needs a lot of bandwidth. Note also that I havent even mentioned the problems associated with reporting the status of a slow fade.

The UPB designers chose to keep the cost down and not put that kind of power into the devices. Instead, they chose to put the burden on the controller. Back to the trade-offs again. If they doubled the price of the device, they could probably pull it off.

The designers, I assume, didnt feel the need to implement this feature. They likely considered the problem it would solve to be a non-problem because the protocol has support for device discovery and configuration. Any controller can query the network and build the database needed to track the device state.

What, I think, they didnt count on is that nobody (except perhaps a crazed hobbyist) would want to implement a controller that actually made full use of the protocol! What's really sad is their decision not to publish the source code for upstart. I am sure that with a "reference implementation" available to third parties, there would be much better software support for their devices. The engineers did a great job of making a very usable protocol. I suspect someone in marketing perceives some value in keeping the key to using it all locked up.

In the case of the Elk, I gather from all the postings here that it has long been at the limits of it's CPU and memory resources. So, much like the UPB designers being stuck with some of their decisions (300 baud) the Elk designers have to deal with what they have. Specifically, a box designed to work with the much simpler X10 protocol. They had to make a lot of trade-offs to get it to work at all with UPB. I am not surprised that they didnt get link tracking right. What does surprise me is that they missed a couple of simple things that would make their UPB support a bit better at least with respect to its interaction with controllers that do have more smarts. The ability to set the ackrq bit and repeat count, for example.

So who's to blame for the Elk not properly supporting UPB? I guess we can agree to disagree here, but it seems odd to me to blame UPB for not implementing a protocol that can be easily used by devices designed for X10... especially when the main complaint centers around a feature that X10 never had.



Right now I have support for UPB, Elk, Brultech, 1-wire, Intellitouch, Statnet (AprilAire), and RFXCOM. The primary goal of the package is to simplify adding support for new devices. At this point it's a collection of device drivers that map hardware to higher level virtual devices. But the drivers are all coded with a common toolkit designed to decode and encode data from packed binary and ASCII protocols and publish the results to a distributed, object oriented database.

Lately I've been putting thought into how to license the code. On the one hand I'd like to turn it into a product. On the other, I'd really like to simply release it as open source. A dual license (GPL/commercial) is not out of the question, but since I prefer to write code over contracts, that decision is likely to take some time. And since I still need to pay the bills, the code is not getting my full attention.

The HAI Omni Pro II will track links if you use its method of creating the links (not Upstart). HomeSeer will track links but you have to import in the UPStart DB for it to do it. CQC uses a rather primative way to track links by polling every switch involved in a link after the link is activated/deactivated. This is rather slow, but it generally works.

Reviewing the responses to this topic, I'm thinking that 2 possible scenerios can be done to have true status:

1. Work with ELK tech support in writing a rule using their RS323 protocol spec to "Get Status" to lights affiliated with a LINK

2. Writing a rule that "Gets Status" to selected lights when a particular link is executed.

I understand that have a PC running (with Powerhome) is not an option. However, the logging and currently configuration allows every light to show true status when a LINK is triggered. PH knows to adjust the light statuses accordingly PLUS initiate "Get Statuses" to only those affiliated devices on the LINK. And with GenII technology, I have a 99.9% reliability of the true status.


-=*Sharby*=-

Can anyone who has an Elk M1G installed with UPB lighting system comment on how reliable the integration is *without* external PC help?

How happy are you with your UPB purchase?

How reliable are scenes using only physical rockers?

How reliable is Elk trigger a scene (i.e., are lights not turned on/off)?

I have been spending dozen of hours reading Internet posts and talking directly with Elk Technical Support (thanks Brad). Elk Technical Support indicates that UPB is one of the more reliable lighting technologies it supports.

ELK M1G has a documented limitation related to tracking current load (on/off/dim) status if the UPB Link command feature. Since I am not yet allowed to post URLs, then Google: “UPB Link command” and click on Simply Automated FAQs.htm, Item#9.

Limitations:
UPB modules will not send their recent status changes in response to link commands. Therefore, the status displayed by the M1 Controller may not always match the true status of UPB devices if they have been controlled by a Link command.
From my understanding, If the UPB Link command *is* issued by any Elk control software, then Elk M1G will statically update the on/off status of each device that is part of scene. I believe the M1G know which devices that are part of scene because configuration map it imported into ElkRP. But if the Link command is manually invoked by, ”scene switch,” then Elk’s view of the lighting network will be desynchronized.
Elk Technical Support:


My lighting/load automation system will have around 20-30 switches/plugins. I am leaning more towards UPB because I am not a big fan of wireless technologies in general (this is really a personal preference and less about technical superiority). My biggest concern is Elk integration. In addition, I am not very excited to use any PC-based helper applications.
For my lighting needs, I want to create functional or story-book types of light scenes. Each scene emulates a “typical” behavior. Example may be:
• Leave House Scene
• Coming Home Scene
• Going to Bed Scene
• Having a Party Scene
• Suspicious Event Outside/Nighttime Scene

man the more i read the more i flip flop.


At 1st zwave sounded great.

Then I read about patent suits and worried about future product availability and development

So then I study UPB. UPB sounds great.

Then I read about ELK issues with it.





As asked, elk and upb users - please comment

I'm not exactly sure what is being asked. The prior post pretty much sums it up with the choices. It really all depends on what you are trying to do and how you want to implement it. If you have UPB devices talking directly to each other with links, then no, Elk will not know the correct status of the switch. BUT, is that important to you? If you don't have a touchscreen or separate control software that will either display the status or need to use it, then whats the difference? So it comes down to what is the role of the M1 in your lighting? If you need to depend on the M1 always having the right status, whether it will be checked in rules or you need to display it or use it in external apps, then you need to have Elk do all the commands. Instead of switches responding directly to point to point links, have your switch send a link to Elk and then have Elk do the control commands.

For example, for a "Going to Bed Scene" lets say you want that invoked by a button on an SAI 8 button keypad. In rules you would write

WHENEVER ButtonX is TURNED ON
THEN action1
THEN actionx

where action 1 thru action x would be adjusting other lights, etc.

The only negatives to this are:
1. You will use up alot of rule space if you have alot of multilight complex scenes
2. You are dependent on the Elk for lighting, so if your Elk is down your scenes won't work standalone

Some may complain about delays or whatever but I have not seen that to be a concern.

Not sure exactly what it was you wanted answered so I can try to answer more specific questions.

Exactly!

As far as delays I believe that there is a slight delay but nobody else in the house notices nor do guests (at least they dont mention it).

In the future hopefully UDI will come out with an ISY for UPB (it has been rumored for a year or more now I think). That will allow you to off load the lighting from the M1 to the ISY.

That still doesn't mitigate the problem that the M1 doesn't look for an ACK even when using direct commands from the M1 to a device.

My UPB setup still suffers from an occassional missed command even with phase couplers in the main and sub-panel right next to the main and only sporatic noise. i.e:

WHENEVER THE TIME IS 4:00 AM
AND THE DAY(S) OF THE WEEK IS/ARE S--W--S
THEN TURN Garage Entry [12[A12]] ON, FADE RATE = 0 FOR 2 HRS

This can still result in the M1 showing the light as on when it's not (or off after 2 hrs when it's really still on) because the M1 assumes a direct command was sucessful. So even if you use the above workaround to handle link commands the direct commands from the M1 can still be missed by the device but the M1 doesn't know it.

True (I guess I am just lucky and have not noticed any missed commands with UPB). That is where the ISY would really come in handy. The ISY cleaned up a whole host of problems with Insteon and I guess there are a few that it would help UPB and Zwave with.

My questions had two motives.
1) If you have a large investment in UBP technology, how happy are you with the purchase? From a financial investment standpoint, installing a HA lighting system is not cheap. For my system, I estimated it would cost about $1800. I was trying to probe to see if actual users are happy with their purchase. I know that I can get my feet wet and purchase $182 UBP trial kit. The trial kit may work fine if only 4 load devices are being used. What happens when the number goes up 40 devices? Does the lighting system become less stable?
2) I wanted to understand if any Elk/UPB user’s are using M1G as the scene controller – instead of using the UBP link command. The documentation says that 528 rules are supported. Would one scene only use a single rule – even if the action list is large?
In regards to the delay if M1G is scene controller, I would only be concerned about a delay would cause any household user to start questioning whether the lights were broken. Talking about 100, 200, 300ms delays is much different than if you have actually experienced the delay first hand.
Before purchasing the M1G, one of the criteria was that Security/HA controller had to be 24x7 device. If Elk M1G cannot do HA/Security reliably, then the whole premise of original purchase will need to be reexamined. I can live with some limitations if I understand them up-front before plunking down lots of dineros. Problems like lights “frequently” not turning on/off, in my eyes, would be a deal breaker.
[As a side issue, the next device that UDI is delivering is ISY-99Z (Z-Wave). To manufacture/deliver a new controller, costs lots of money and time. As such, my suspicion would be the ISY-99UPB will not be forthcoming for some time.]

I've got nearly 60 UPB switches, mostly SA US2-40's. I am very happy with the purchase. UPB is pretty rock solid. The number of switches doesnt really matter. The upstart tool let's you check out signal strength to and between devices. Unless you have an odd source of intermittent noise, you'll know what to expect of a device right away. I had only two switches that gave a very low signal strength. Adding a phase coupler did the trick.

As for a controller, I do have an Elk but dont use it much for lighting. With my initial UPB purchase I bought a PCS TEC (Timed event controller). It's a small wall wart sized device that is programmable through upstart. My plan was to use it initially with the more sophisticated Elk replacing it eventually. Three years in and I am still using the TEC. Putting timed schedules into the Elk is a bit of a pain. Changing the schedule is more of a pain.

The Elk is really an alarm panel that has some home automation functionality built in (or bolted on). As an alarm panel it is quite nice and more than capable. As a home automation controller it leaves a lot to be desired. While more difficult to program than the TEC, it is more capable. My rules for dealing with the garage lights would be impossible to do with the TEC, but the Elk handles it just fine.

Most of my lighting commands come from the UPB rocker switches. This is, in my opinion, how people expect to control lighting. The TEC is great at giving the house the lived in look when we are away and at turning on the outside lighting and inside "path" lighting at sunset.


A rule in the Elk is very simple, one trigger and one action count as a rule. If you want two actions (a second light) it will cost you another rule.

It would be great if the Elk tracked the state of the lighting devices. That it doesnt isnt all that much of a problem unless you are trying to compensate for a noisey UPB environment. Most of my Elk lighting rules simply send "link" activation commands. A "link" is what UPB calls a scene. Each UPB device can belong to 16 or so links and can adjust it's load differently in response to each. So for example, each of my UPB devices belong to at least 4 or 5 links: All Lights, All Inside, All <room name>, Device Name. (Having a link for each device makes some programming easier). Then some devices belong to links like Bedtime, Wake Up, Midnight Snack, or Watch TV. These links can be used equally well from either the Elk or the TEC.


All of the SA switches have a built-in 300-400ms (750ms by default) delay used to disambiguate a single click from a double click. Many posts have been written on the subject. They take some getting used to. I tried pretty hard to make the lighting in the house seem "normal" to guests. Most people get it pretty quickly but some have trouble. The biggest problem is that some folks will press and hold the rocker waiting for something to happen. The problem is that a press-and-hold causes the load to start dimming up from nothing. So with the delay it can take quite a while for a visible difference to show at the load. I find myself telling guests to "just click the button and wait".

If the Elk were to do nothing but activate a single light I doubt you would notice the difference between it doing it and a UPB switch sending the command itself. If the Elk were to send separate commands to say 10 different lights, you will notice it. Each UPB command will take at least 300ms to transmit. That's why UPB has links.


The Elk is certainly a reliable 24x7 security and HA device. UPB is, for most, a very reliable lighting platform. The two do work together nicely. When I think of what I'd like in a home automation controller, I think of like something Premise. The Elk doesnt get you anywhere near there. The more important a task is, the less software, hardware and wires I want involved in it's execution. I control the heating system with the Elk, but turning the light on over the bar at 5pm, that's a job for Premise (which, btw, tracks UPB link state changes). A "fancy system" will give you a nice user interface and allow easy changes to the configuration. The Elk is not fancy. Think of it as your alarm system as well as the eyes (sensors inputs) and hands (relay outputs) of your automation system and you wont be disappointed. From your questions, however, I think you are expecting more.

Well put!

My ELK M1 is rock solid and capable but not as flexible or sophisticated as my HA software. Put the two of them together and they can tackle anything.


This is an excellent thread that makes me want to get off my duff and connect that UPB gear I bought 2 months ago ... so many projects, so little time.

Thanks for the very thoughtful reply! This is exactly the kind of information I was seeking.
I didn't catch the, "Additional AND and THENs each one additional rule each." comment at bottom of ElkRP>Automation>Rules>New Rule editor dialog.
From a lighting and security standpoint, there are four use cases which are important to me and require Elk>Lighting integration.
1) Leave house daytime or nightime- Turn off all inside lights. If night time, then leave on few key lights
2) Entering house – Turn on all lights leading into kitchen
3) Intruder - All lights blinking on/off
4) Suspicious activity outside - Turn on all flood lights
If Elk has trouble maintaining a consistent view of which lighting loads are on/off, then I was concerned that these “integrated” events may not work correctly. Thus, I was concerned about the statement in the Elk M1XSP manual.
I am just finishing up the security part of my Elk M1G installation.

Resurrecting this thread as I'm tinkering again and want to see if my thinking is on track.

It seems from the thread that the best approach would be to take a hybrid approach to the UPB and ELK integration. The first question you should ask for any given link would be whether the ELK really needs to know the status of that link. For a lot of rules, you probably don't need to know the status of the switches, so just issue the link. FI, if I want all lights on, it doesn't really matter what the status is, just turn on the "all lights on" link. If I want my porch light to turn on at dusk, it doesn't really matter if it is already on, just send the link in case it is off. In those cases, the Elk can use a link that can also be set up in UpStart and sent from a switch or keypad. OTOH, If you have a rule or other reason that requires the Elk to know a switch status, then only use the Elk for controlling that link.

I guess what I'm concluding is that it doesn't need to be a choice between using UpStart or the Elk for UPB control, but instead to determine which is better on a link by link basis.

Of course, an ISY-99u would solve many of these problems, but I believe it was on the UDI web-site that I saw that they are no longer planning on making a UPB version, Anybody know why they made that decision?

A UDI Rep frequents Cocoontech so maybe he will chime in.

I've got around 20 UPB switches. Pretty unhappy. Elk integration is poor, you can't get the real status of the switch. On top of that, you can't run any of the lhigh efficiency lights, as they are flouresant. Mean time to failure on these lights on the UPB system is around 90 days.

I have all CFL's etc in my house and UPB since August of 2008. I think I replaced one bulb outside and one or two inside but some of them are getting old so I would expect them to fail. I am using almost all SA devices (a few PCS).

Kind of wierd that the CFL's will be failing. Do you have the switches set to "Snap"?

While the UPB communications seem to be perfectly reliable I also see where the ELK is not always up to date. I am experimenting with it but havent had enough time to get anything really accomplished.

I don't think that ELK (or any system) could poll UPB devices to get state unless a good deal of delay was acceptable. Given the bandwidth of the UPB protocol and the fact that a link could control 256 devices I think the time to poll all those devices would be excessive.

Those systems that don't import the UPB config file or scan the UPB network need to do so. They can then build an internal database of the UPB network. Then the system can at least respond to links and track them. Granted that doesn't mean that each device controlled by the link is in the correct state but its much better then nothing.

I can't say with 100% certainty why plans for a UPB ISY were shelved, but I believe it was primarily a ROI decision.

That's unfortunate. I can understand that UDI has a lot of time and money invested via Insteon, so I hope the decision wasn't based on a fear that they would be cannibalizing their own product. I could see a use for having both products. Insteon and UPB each have unique and appealing properties as well as frustrating limitations. Many of the limitations of Insteon are mitigated by the ISY99. Having an ISY for each (or even better a hybrid ISY that could control both) would allow a person to mix and match UPB and Insteon instead of having to choose one or the other.

In my situation, a couple years ago, to test each system I installed UPB in the North half of the house and Insteon in the South half. I like them both and am frustrated with both. I really don't want to have to choose one or the other.

Not at all. As a matter of fact, we are actively working on a Z-Wave compatible product. I believe the decision was completely based on ROI. We'd love to see a wide range of ISYs for a variety of technologies, the limit is available resources.

What are your frustrations with UPB?

For one, the issue we were discussing the other day: http://www.cocoontech.com/forums/index.php?showtopic=14863

2nd (and related to #1): availability of a reasonably priced UPB keypad with lighted indicators that also controls a load. AFAIK, the only UPB one so far is from PCS and costs $342 from AO. Compare that to an Insteon keypad for $69.99. How will UPB ever reach critical mass at these prices?

3rd - not my frustrations yet - but the ELK integration issues which prompted the OP to start this thread.

I'm sure others with more UPB experience than me could add a few more to the list.

Thanks for the info.

#1 The only way I have been able to make this work involves some additional hardware to respond to links and issue others in response, as I mentioned in the other post.

#2 It may be that this particular combination is not viewed as being in demand, I just don't know. The SA units can have up to 8 non-lighted buttons and dimmer combined, close but not quite there.

#3 Maybe the new ELK M2 will fully support the UPB protocol. As I understand it the M1 does have enough resources to do this. Time will tell.

Good luck.