UPB link status / Elk workaround

[frankdr]

Ok - I'm trying to work around the problem where a UPB link updates some switches, but my Elk doesn't know what the new switch settings are.

Here's what I did.

1. Create a Link in UPStart with only the transmit button but no actual switch devices to receive.

2. Do a Elk rules 'whenever (linkname) is turned on' followed by all the 'SET xxx to yy% bright' commands that would normally be in the link.

The only problem is that if you have many switches, each one has to have it's own command sent, which takes a while and the switches don't change at the same time (looks like a ghost wandering through the house

SO . . .

I duplicated the light settings in both the UPB link and the elk rule, so that
#1 - The lights update at the same time and
#2 - Elk knows the current lighting levels
of course the light is sent the same command twice - once directly and once in the link.

Any ideas about how to make this more efficient etc?

Later,
Frank

 

[Steve]

I don't have links yet that turn on stuff like that, but I do have a turn off 'nightime' button. The lights do go off at slighly different times like the ghost wanderer but it doesn't bother me. Sometimes I actually think its kinda cool, and almost looks more natural as if someone is just walking thru and shutting off lights. It still only takes like around 3 or 4 seconds for them all to go off (guess someone is walking quickly). But I do see your point. Wonder where the delay is and if this also happens with X10 or Insteon.

 

[toymaster458]

I setup up a button that transmits a link to the Elk then a rule to run when it receives that link on that turns off 3 lights. It takes 4 seconds to turn them off.
I have been asking and asking that Elk needs to either improve the links by importing the link database from UPStart or have a way to querry a device from a rule. Maybe if we all SQUEEK together it may happen..

 

[frankdr]

I setup up a button that transmits a link to the Elk then a rule to run when it receives that link on that turns off 3 lights. It takes 4 seconds to turn them off.
I have been asking and asking that Elk needs to either improve the links by importing the link database from UPStart or have a way to querry a device from a rule. Maybe if we all SQUEEK together it may happen..

So, I guess we're using scenes as a way to capture the UPB desktop controllers, room controller, etc commands and doing all the work in the Elk rules, which is ok except if you want to do something like dim the room's main lights at the same time you ramp-up some accent lights in the same room. It looks *really* cool when you do this at the same time.

Having a UPStart link import would be useful, but having a 'then' rule to query a UPB device status is a 'must have' IMHO

I'm doing some testing with CQC and PDA's as an alternative to UPB controllers and touchscreen IR devices. I can get a used PDA for a little more than the price of a UPB 8 button controller and a lot cheaper than the color Pronto-type devices.

Later,
Frank

 

[stacyh3]

SQUEEK
I'm not at the point of installing the system in my new house, but I did notice the same thing in a house that I saw that used an HAI OmniPro II. A way to track link status would certainly be another competetive advantage.

Stacy

 

[bfisher]

I use HVPro (not Elk), but I also have this issue... Its a UPB issue, not a hardware (Elk, HVPro). When a UPB link is executed, it doesnt transmit the light levels, just the link status.

Therefore, there are 3 ways (that I've been using) to overcome this:
1) When a link is executed, use a "light setting = xx" in your controller.
Adv: links execute as programmed in UPStart. All lights transition at same time.
Dis: you need to program into your controller the levels you are transmitting for Links. If you change the links in Upstart, you need to change in controller.

2) After a link is executed, request an update of your UPB switches.
Adv: your controller knows exactly what your lights are set at. Only program links in UPStart
Dis: requires a few seconds to update all the switches

3) when a link is executed, it trigger the lights sequentially in your controller
Adv: your controller knows exact light status. Only need to program in your controller (not upstart)
Dis: lights "popping" on (not all simultaneous)

Personally, I use mostly method 2 and a little of 3. I started with #1 but got away from it because I don't like maintaining settings in 2 places. HVPro has a plug-in that automatically imports your UPB settings - but not the light levels for each Link... so #2 is the easiest. I wrote a simple status request macro that gets called 2 seconds after a link is executed... works very reliable. However, if you have a lot of devices, this could take a long time and not be a good strategy.

 

[toymaster458]

This is How I see the Status updates working from a rule

WHENEVER Lighting 193 (M01) CHANGES
         THEN GET STATUS Light 4 (A4)
         THEN GET STATUS Light 5 (A5)
         THEN GET STATUS Light 30 (B14)

This way no matter what is sent on the link either a dim or a on or whatever this rule would trigger and get the new status of the devices.

Sure we have to recreate what devices are part of what link but it is 100 time better then what we have now.

What would stream line this is exporting the configuration from UPStart and then having ElkRP import it and parse out the link table and then the link rules could run inside of the M1XSP and when ever it hears a link command over the power line it could look in the table and see what devices it effect and get the new status of those devices and update the M1 Lighting table. This way we are not using space up on the M1 with a lot of extra rules. Heck since we are parsing out information from the UPStart export we could go as far as automaticly configuring all the lights in the M1 to match those in UPStart.

 

[acheslow]

That would be awesome.

Squeek.