UPB configuration into OminPro

Note on Links 243-250 - Macro Links

These are reserved for the UPB switches to communicate with the controller for macro type actions.
They have no effect in the lighting operations or HLC system.
They can be used for a number of functions, including lighting.
And they can be reused by different unit IDs and trigger completely different functions using the same link.
If they are not used as macro triggers they can be used freely as additional custom links for UPB scenes.

The Links 243-250 ostensibly correspond to "button 1-8" on an HLC 8 button house controller.
But they are really only logically related to their respective buttons, not hard coded.

When used for their intended purpose as Macro Execution they are programmed through the UPB Switch trigger in PCAccess.
The format will be "Unit X Switch Y"
In PCAccess you select a UPB Switch trigger.
In the popup you identify the UPB unit as a normal switch, or a 6 button room controller or an 8 button house controller (same selection for both).
Then you select the "button" pressed that you want to trigger the action.
(You can choose to identify a normal switch as a house controller in this area for macro purposes. i.e., you want a standard rocker switch to transmit the "Button 6" link. See more below.)
The resulting trigger will read something similar to this: OR I use the quoted term "button" intentionally.
The eight links correspond to logical "buttons" but they are not tied to actual physical button locations on the UPB/HLC unit.
Link 243 = "Button (or Switch) 1"
Link 244 = "Button (or Switch) 2"
Link 245 = "Button (or Switch) 3"
Link 246 = "Button (or Switch) 4"
Link 247 = "Button (or Switch) 5"
Link 248 = "Button (or Switch) 6"
Link 249 = "Button (or Switch) 7"
Link 250 = "Button (or Switch) 8"

The Omni controller is monitoring the UPB network for these links.
When it receives one of these 8 it checks which unit sent the link and takes appropriate action as programmed.
The controller does NOT check to see what actual physical button on the unit transmitted the link.
That data is available in the UPB messages sent, and can be viewed in UPStart, but the controller does not use it.
The controller only associates the Link number with the Unit ID.

So in the example above, it is waiting for Link 244 to be transmitted by Unit 2.
If it sees this combination, the program block will execute.
It doesn't matter if Unit 2 is a normal switch, a 6 or 8 button HLC controller, a SA US2-40 with a 4 button switch plate, or any other unit type.
AND, the link does NOT have to be physically programmed into "Button 2" of the UPB unit.
If your Unit 2 is a SA US2-40 with an 8 button faceplate, and you program button 8 (or any other button on the unit) to transmit Link 244, the macro will execute.

If the controller receives Link 244, and it was not sent by one of the identified units, it takes no action.

Since the controller only takes action when any of the 8 links are paired with a specific unit ID that transmits them, the links can be reused multiple times.
You could set up triggers for Unit 2 SW2, Unit 3, SW2, Unit 5 SW2, Unit 10 SW2, etc.
All would be unique combinations so each combination could trigger a different action.
So there are ostensibly 8 x 250 = 2000 unique combinations available for macro execution.

This is a great way to communicate/coordinate macros with the controller through the UPB network using the switches already installed.
It also can make use of the single/double tap action of something like a SA US11-40, where the single tap operates the local load (and transmits local status) and the double tap transmits the macro link.

You could also set up UPB units to receive and take some action when they receive one of these links.
In that case the lighting changes would occur, and then the Omni would take whatever macro action was associated with the link.
This is a good way to integrate macro actions that include lighting changes without adding UPB lighting operations in the programming lines of the Omni.
If this option is exercised, the lighting changes would occur with ALL transmissions of the link, regardless of source.
This could be used as a way to make a lighting change only with one transmitter, and couple the lighting change with some other macro actions when the link is transmitted by a different unit, while using the same link number.
For instance if the Omni itself transmits the link (the source would be seen as UPStart on the UPB network), only the lighting scene would execute.
But sending the link from an associated UPB unit would communicate to the controller to take additional macro actions while the lighting change was occurring.

Advanced:
Since the Omni controller and other PIM connected computers identify their source as "UPStart" on the UPB network, they can't trigger these macro actions.
If you have a computer program that can generate the actual serial commands that include the Unit ID in them, you could use it as a source for macro execution as well.
Alternatively, you could use something like the Western Mountain RUC to retransmit the link with the proper Unit ID tag based on any number of input criteria.
PCS has a utility to generate the serial commands that can then be copied into the RUC or a computer program so they appear to be transmitted from the correct UPB ID.
(sidebar - I also use this function of the RUC to enable the Omni to communicate to the individual channels of a two channel SA US22-40 switch.)

Desert_AIP - kudos to you for the good explanations of HLC in this thread.  This should be a sticky!

Thank you

I was thinking of cutting and pasting it to the resource or blog areas.
It's been a while since I played with the setup and this thread prompted me to go back in and look at the UPB log activity to sus out exactly what's really happening.
It was a good learning experience for me and I wanted to document what I found before my memory faded.

With what I've learned I plan on going back and streamlining some of my programming to take advantage of the HLC operations.
Since much of the HLC behavior is hard coded in the firmware, it creates efficiencies by not having to use as many programming lines.

Tips & Tricks

Cross Room Status Tracking

I have several whole house scenes that affect units across multiple rooms.
This can create status tracking problems.
The default solution would be to issue status requests to each of the units in the other rooms when the link in question is receieved/transmitted.
But this could eat up a LOT of programming lines and be very tedious if the links affect multiple units in multiple rooms.
If each room has 6 units and you have a link that affects all units in 4 rooms, you'd need 19 additional program lines just to track status for that one link.
HLC would track the first 6 units automatially (assuming you used a room specific link), but you'd have to tell it to update the other 18 units in the other 3 rooms.
e.g.
 

WHEN HLC Room 1 Link A ON
    THEN HLC Room 2 Unit 2 STATUS REQUEST
    THEN HLC Room 2 Unit 3 STATUS REQUEST
    THEN HLC Room 2 Unit 4 STATUS REQUEST
    THEN HLC Room 2 Unit 5 STATUS REQUEST
    THEN HLC Room 2 Unit 6 STATUS REQUEST
    THEN HLC Room 2 Unit 7 STATUS REQUEST
    THEN HLC Room 3 Unit 2 STATUS REQUEST
    THEN HLC Room 3 Unit 3 STATUS REQUEST
...
    THEN HLC Room 4 Unit 7 STATUS REQUEST
 

Click to expand...

 
 
To get around this I generally do not use the D link in any room.
I reserve it for status updates, and label it "Master Bedroom Status", "Kitchen Status", etc.
No switch is programmed to respond to it.
So nothing appears to occur when the link is transmitted.
But the Omni still associates it with the room, and when it sees the link on the UPB network it updates all the unit statuses in that room.

So you can update all the units in a room with one line of programming and make no changes to the actual lighting conditions of any unit.

In the example above, if Room 1 Link A was your trigger for the multi-room scene, the PCAccess code would only be 4 lines instead of 19.
e.g. (pseudo code)
 

WHEN HLC Room 1 Link A ON
    THEN HLC Room 2 Link D ON
    THEN HLC Room 3 Link D ON
    THEN HLC Room 4 Link D ON

Click to expand...

 
This would tell the controller to update the status of all 4 rooms sequentially.

With a single line added, this can also be used to update status when the same link (and group of lights) is turned off.
 

WHEN HLC Room 1 Link A ON
WHEN UPB Link 3 OFF
    THEN HLC Room 2 Link D ON
    THEN HLC Room 3 Link D ON
    THEN HLC Room 4 Link D ON

Click to expand...

 
You have to use the UPB version of the link with the Deactivate command since all HLC commands (except the room toggle links noted above) are executed via the Activate command.

So if I understand what HAI/Leviton was thinking with their arrangement, it was each room will have a room controller, and this room controller will have an all on, an all off, and 4 scenes for that room.  The house controller shows you which rooms have lights/fan on, and allows you to shut them all off with one button.  That makes sense. But I'm a bit surprised that it doesn't seem that HAI/Leviton really allows whole house scenes, like "Party Time" and it would seem that these are what people would actually use. 
 
I'm trying to understand their thought process (if there was one) in laying this out.  Were they thinking that if you wanted "Whole House Party Time" you would just define it as one of the scenes for each room, and you would set each room to "Party Time" one by one?  Or do they expect you to use these extra links, and just lose the ability to track light levels in this situation?

Tips & Tricks

Logical Rooms

An HLC "Room" is just a collection of UPB Unit IDs and Links.
It does not have to be a physical room and all of the units do not have to be in the same physical room or location.
It can be a group of units that have similar functions, or it can be used to sub-divide the operations of units in rooms with only a single unit.

I use this convention in several places, the most common to most people would be the "Fans" room and the "Bedrooms" room.

In the Fans room, I included all of the exhaust fans in the house.
This allows me to control them individually or collectively, and maintain status tracking.
Assume Fans is Room 1; HLC Units 1-8 and Links 1-6.
The fans are located in several rooms and on both floors of the house.
Here is the breakdown in PCAccess (this is a case where I use the D link to operate a unit).
Unit 1 - Fans (no physical unit installed)
Unit 2 - Master Bath Shower Fan
Unit 3 - Master Bath Commode Fan
Unit 4 - Guest Bath Fan
Unit 5 - Powder Room Fan
Unit 6 - Laundry Room Fan

Link 1 - Room ON - All 5 units turn ON
Link 2 - Room OFF - All 5 units turn OFF
Link 3 - Room Link A - Master Shower and Master Commode Fans ON
Link 4 - Room Link B - Guest Bath Fan ON
Link 5 - Room Link C - Powder Room Fan ON
Link 6 - Room Link D - Laundry Room Fan ON

If there is a fire and I want to activate all of the exhaust fans to clear smoke, I issue Link 1 ON.
If there is a burglary and I want to stop any fan that may be running to silence them, or turn them off after the fire timer expires, I issue Link 2 ON
If I want to activate or deactivate an individual room's fan(s), I issue Links 3-6 ON as appropriate.

The controller updates the status of ALL the units when ANY of the links is transmitted.
I also use a free form link to individually control the Master Bath Commode fan, but that requires very little programming for a single unit.
The Fans room does NOT respond to the ALL ON / ALL OFF commands.

The lights in the associated rooms control their corresponding fans by transmitting the associated link, A, B, C or D.
So when I turn on the Master Shower Light, the local light load turns on and it transmits Link 3 Activate to turn on the Master Shower Fan and Commode Fan.
The fan units have internal timers set to this link so they only stay on for 1 hour.
When I turn off the Master Shower Light, the local light load turns off and it transmits Link 3 Activate to reset the internal timer to a full hour, eseentially "turning the fans ON" a second time.
The shower light is a SA US11-40, so it transmits its own status whenever the switch is pressed. The fan link prompts the Omni to update the fan status when it turns on.
Since the timer on the fan is internal to the UPB switch, the Omni is not aware of when the switch turns off.
I set a timer in the Omni associated the fan link to check the status after the timer expires.
I use the internal UPB switch timer instead of the Omni as a redundancy. The internal timer will always turn off the load, regardless of whether or not it receives an external command. If I left it solely up to the Omni, there is a very slight possibility the link might get missed and the fan would continue running.
The internal timer operates independenlty of the controller, it does not require the presence of the controller to function.


In the Bedrooms room, I included all of the additional bedroom lights in a collective group.
Each bedroom only has a single UPB fixture.
This allows me to control each room individually or collectively, and maintain status tracking.
Assume Bedrooms is Room 2; HLC Units 9-16 and Links 7-12.
Here is the breakdown in PCAccess (this is a case where I use the D link to update status).
Unit 9 - Bedrooms (no physical unit installed)
Unit 10 - Guest Bedroom Light
Unit 11 - Bedroom 3 Light
Unit 12 - Bedroom 4 Light

Link 7 - Room ON - All 3 units turn ON
Link 8 - Room OFF - All 3 units turn OFF
Link 9 - Room Link A - Guest Bedroom Light ON
Link 10 - Room Link B - Bedroom 3 Light ON
Link 11 - Room Link C - Bedroom 4 Light ON
Link 12 - Room Link D - Status Update Only

Again, this allows me to turn all of the light on or off collectively, or each individually, and all of the unit statuses are updated whenever any of the units are changed, without additional programming lines.

I primarily use this convention more as an efficiency measure to maximize use of the available Rooms and UPB unit IDs.
Since each room only has a single Unit, and they are generally only operated in an ON/OFF fashion (or the lighting level is adjusted locally at the wall switch) it seemed a waste to use up 8 Unit IDs and 6 Links on each room.
Since I did not separate out each bedroom into a separate HLC room, it frees up the room links that would be used in those additional HLC rooms for general use.
It also allows me to use the UPB Unit IDs for things like UPB IO modules.
The Bedrooms room does respond to the ALL ON / ALL OFF commands.

ano said:

So if I understand what HAI/Leviton was thinking with their arrangement, it was each room will have a room controller, and this room controller will have an all on, an all off, and 4 scenes for that room.  The house controller shows you which rooms have lights/fan on, and allows you to shut them all off with one button.  That makes sense. But I'm a bit surprised that it doesn't seem that HAI/Leviton really allows whole house scenes, like "Party Time" and it would seem that these are what people would actually use. 
 
I'm trying to understand their thought process (if there was one) in laying this out.  Were they thinking that if you wanted "Whole House Party Time" you would just define it as one of the scenes for each room, and you would set each room to "Party Time" one by one?  Or do they expect you to use these extra links, and just lose the ability to track light levels in this situation?

Click to expand...

 
I think that is what they envisioned using the 8 Macro links for.

When a Macro link is transmitted, the programming required would only need to transmit the room ON Links (or the various level Links) as required.
That only requires a single line per room.
 

WHEN Party Mode ON
    THEN Room 1 LINK A ON (80%)
    THEN Room 2 LINK B ON (60%)
    THEN Room 3 LINK C ON (40%)
    THEN Room 4 LINK A ON (80%)

WHEN Good Night ON
    THEN Room 1 OFF
    THEN Room 2 OFF
    THEN Room 3 OFF
    THEN Room 4 LINK D ON (Leave Room 4 on at 20%)

Click to expand...

 
The ALL ON / ALL OFF function works the same way.

Remember, they have to program a default interface into the touchpads, and they need a simple mechanism for operating scenes from both UPB units and consoles.
Most end users probably want simplicity over the complex interactive actions you can make the system perform.

They probably also have memory constraints they are programming to.

I'm sure this was mentioned somewhere in this thread, but what unit number do house controller occupy?  Can you have multiple home controllers?  I'm doing some wiring on my new house and I was thinking of having a few home contrllers, but probably no room controllers.

If the 8 button switch is meant to be a House Status switch, it must be the 8th unit of a room.
If it is a macro executer, it can be any unit 2-7, in each room.
 
The House Status switches can control and track 8 rooms each, you can duplicate or select which rooms are tracked on each one.

I have read this thread several times and am pretty sure I followed the directions accurately but yet my OPII does not update status when load is controlled locally. What could I be missing?

Are you using the local load links 240/241?

The easiest way is to have the switch transmit status when it is changed.
That can be configured in UPStart.

using link 241 off, and 242 on. Those are the reserved HLC links for on/off as seen in PCA
 
rockers set on "status"
 
Using upstart I can see they are transmitting status but the OPII status is not changing. OPII can control the switches as well, so I am assuming it is all configured correctly, but no status update.

Post pictures of one UPB switch Upstart configuration.  The links / sending out stuff is on multiple tabs for one switch.
 
Relating to screen snapshots and easy photo resizing I utilize Polyview here in Windows and Linux.  Its been over twenty years now and it appears that author is retiring and offering software for free these days.
 
Polyview can be found here and it is not adware or malware.  Looks like the website too has been retired.
 
I have attached a clean download of Polybytes Polyview before website was retired.
 
Polyview

[sharedmedia=gallery:images:848]
[sharedmedia=gallery:images:849]
[sharedmedia=gallery:images:850]
 
I have the scene links as  UPB link 241(off), and 242 (on) as dictated in the HLC on OPII.
The units in PCA are configued as HLC. 

I am guessing you saved and uploaded to the OPII a block of Units in HLC mode as outlined in the spreadsheet examples above. 
 
Note nothing happens to the OPII in vivo unless you upload your changes to the OPII panel.
 
I played with HLC stuff but never implemented it. 
 
I did do a quickie test here using Upstart connected to one HAI UPB PIM floater and PCA looking at the status of the swtich.
 
I did a test ON in Upstart of one switch and did see the status change in PCA (connected to the panel).
 
I also went to the PCA Unit switch status and turned it on and off and saw the changes vivo in UPB Upstart.
 
Additionally went to the switch physically and turned it on or off and saw the status change in Upstart and PCA Unit status.
 
Another thing I did was turn on and off one switch while watching the status on the Omnitouch screen (its above the switch) and it did change with the switch button pushes.
 
One more thing was watching the Homeseer UPB status of the switch while pressing the button physically and it too showed the change in status on or off or dim.
 
One push on the rocker is dim and a double push is 100% brightness.  (I have double rockers on this switch as there are more lights being controlled in the room).
 

 
Here though (and I do not know if it has anything to do with anything) I have three PIMs/ UPB repeater online 24/7.  First HAI UPB PIM is connected to the OPII panel.  Second PIM is connected to my automation software and the third is just sitting on a Quatech serial server to use from wherever on the network   (4th PIM is a floater which is only plugged in on demand).  I talk to the UPB switches with the Homeseer automation software and the OmniproII panel.