Issue with Elk and UPB

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.
 
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.]
 
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?
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.

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?
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.

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.
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.

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.
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.
 
... 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. ...
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?
 
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.
 
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.
 
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.
 
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

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