Elk and UPB

I adjust my UPB setup all the time but I never really needed to know how it works. However, I can see how HVPro communciates with the UPB system so I can see the command strings it assembles to communicate with the PIM. The status request is command type 30 (ie. 0 = off, 1 = on, 3 = brighten x times, etc.).

If the Elk doesn't support the command directly, can you manipulate strings sent out the serial port? Maybe you can manipulate the string to make it work?
 
I've just recently integrated my Elk with my UPB system and realized that I'm confused about how to configure UPB links to work with the Elk.

The M1XSP manual says that the Elk supports 192 individual addresses and 64 links. So I've setup my links in UPStart such that links 1-64 are scenes that I want to use with the Elk and links 65+ are links to individual devices that I don't need to use with the Elk since it can use the 192 individual addresses. My keypads (US2-40) use links 65+ to control individual loads and the Elk uses the 192 individual addresses.

However, I noticed tonight that when a keypad or UPStart activates one of the links numbered 65+, then one of the links numbered 1-64 also gets activated (I guess by the Elk?). For instance when I activate link #65, I see that link #1 also gets activated; when I activate link #66 I see that link #2 also gets activated, etc.

Am I not supposed to use links 65+ at all when using the Elk, or is something possibly wrong here? I have one PIM connected to the M1XSP and a second connected to a PC running UPStart, if that makes any difference.

Thanks,
 
Anybody? With so many Elk and UPB users here I'd have thunk that someone would have figured this out better than I have.
 
I will have to create a few links above 64 to see if I can repeat this, but logs haven't shown anything weird like this. Does it happen the other way around as well (for example, does link 65 activate when activating link 1)?
 
Sorry Alan - I can't help here. I don't have these issues on my HVPro and I have no experience with Elk to help. Sorry :)
 
Alan,

I think indeed you stumbled onto some weird Elk bug - I hope Spanky (or Don) is listening.

I just installed another switch and I was out of single rocker plates so I installed a half rocker with 4 buttons. While I was at it I thought I'd see if I could maybe duplicate some of your issues. So I configured 2 buttons on that switch to transmit link 69 and 70 respectively and set another close by light to receive link 69 and 70.

So I was playing with those buttons and watching the lights work as expected when the wife comes up to me and says - "why is the alarm on night instant mode"? I thought to myself all I did was program a few links, it could not possibly be me. So I pushed the buttons some more and sure enough for some reason if I press the button to activate link 70, the system armed. So after scratching my head a bit, I remembered I had a rule that armed the system on a keypad in my bedroom.

So I lookedk at my config and see I have a UPB link 6 defined on that keypad. In my rules I have a rule that whenever Button 6 (Link ID 6) turns on to arm the system. For some reason this link 70 also tripped that rule. That link (Button or link 6) is defined as lighting id 198.

That all works as it was supposed to but they key here is that Link 70 also trips that position. So, out of curiosity I made a rule for Button 5 (Link 5) - Elk id 197. Sure enough, if I activated Link 69, it also tripped it.

So.... I thought I had a hard time following your explanation but mine is equally as twisted. Funny thing, the lights associated with positions 5 and 6 do not activate, only the rules associated with links in positions 193 and up in the Elk config.

Seems like some kind of mapping bug and probably somehow related to your issue as well...
 
Looking into the issue!!!

Interesting that we were working on Insteon and UPB!!


EDIT: Found the problem. Fix will be in next M1XSP software update.

Thanks for the input.

ELK Engineering Team
 
electron - no, it doesn't work the other way around.

steve - thanks, it looks like we are seeing the same behavior, which is that activating link #X will also activate link #(X-64).

This reduces the number of usable links to 64, which I can see easily exhausting pretty quickly.
 
Spanky said:
Looking into the issue!!!

Interesting that we were working on Insteon and UPB!!


EDIT: Found the problem. Fix will be in next M1XSP software update.

Thanks for the input.

ELK Engineering Team
For anybody that may be wondering or still on the fence, or unsure why Elk products are so popular around here and elsewhere, this is a perfect example!

I emailed Spanky and referred him to this thread for detail this morning and they have jumped right on it, identified the problem and are creating a new XSP firmware build to test. Support just does not get better than that! (Well, ok, maybe CQC is just as good!)
 
I had a very strange issue at a job of mine with UPB. For the stangest unknown reason the M1 would send out on and off commands for Device 11 when ever I used link 2 and would not stop until I unplugged the PIM from the M1XSP. I changed the Link to 6 but still had issues. I ended up changing the device from 11 to 14 and all is well.
 
Thanks to Elk for identifying and fixing the problem so quickly.

Now back to the original topic... will there be a fix to let the Elk know the status of UPB devices that are updated through external links? Or are there any other workarounds besides the ones that frankdr mentioned:
One option is to create a UPB link without any UPB switches assigned to it. Have the Elk set the light levels itself when it recieves the link message. That way Elk / CQC knows the light level because it was the one that set them.


You can also have the Elk set the lights to the same level that the link switches are being set to with the UPB link setting

I don't like the first option because it turns the Elk into a central point of failure for all of my lights. I'd rather have the links/scenes controlled by the devices themselves. The second option may work but it sounds like a real PITA, especially when it comes to maintaining a growing number of links and devices that may change over time.
 
Okay, I'm really confused. I've got an Elk M1G and I'm using UPB, but I see nothing in the ElkRP that refers to links at all. Can I only tell if the button on the controller (SA US2-40) was pressed? And, how do I do that, since all I see is a way to describe device 30 (in my case) to be a switch, not an 8 button switch. It all makes sense in UPStart, I just don't see how to correlate that to the ELK.

Also, when I turn off a switch manually, the M1G doesn't seem to get the message. I can tell what the M1G thinks the switch state is from the keypad. I set up a rule that sets a virtual output and speaks the switch name when I hit the off button, but I hear nothing and the output is never set.

Help please. Thanks.
 
Familiarize yourself with Pages 12 and 13 of the XSP manual. Locations up to 192 are devices, locations 193-256 are links. Link 1 in Upstart maps to device 193 in ElkRP. So, for example lets say you have an 8 button keypad and you want the M1 to do stuff on button presses.

Assign say Button1 In Upstart to Link1, Button2 to Link2, etc. Make sure the switch is configured to transmit links. In ElkRP under lighting, define Button1 as device 193 as serial expander, on/off switch.

Then, assuming the label of Button1 in ElkRP position 193 definition, you can write a rule that says:

WHENEVER Button1 [193(M1)] IS TURNED ON
THEN whatever you want to do...

If you manually control a switch, the M1 should see it fine. A UPB switch will transmit its status locally, but if a switch changes as a result of receiving a link, then you will not see that switched status change. Thats an issue with UPB and the only solution is really to do polling - or, instead of having UPB devices control each other directly via links, have the M1 pick up the link and have the M1 control the device, then it will always know the status.
 
Back
Top