Niagara PRO TIPS: Schedule Relations Part 1 Smart Relations and Px

Niagara PRO TIPS: Schedule Relations Part 1 – Smart Relations and Px

Video Tutorial: Niagara PRO TIPS: Schedule Relations Part 1 – Smart Relations and Px

Overview

This guide covers how to use smart relations to create dynamic connections between schedules and occupancy points in Niagara 4. Learn how to leverage tag rules, smart relations, and EquipmentQL (EQL) queries to build intelligent navigation and reporting systems that automatically track which schedules control which equipment - even through complex logic chains.

Part 1 Focus: Smart relations setup and use in PX graphics and BQL grids

Coming in Part 2: Building hierarchies locally and at the supervisor level using System Database

The Problem

Common Scenario

Station Structure:

Lon Network
└── Floors
    └── Air Handlers
        └── Points
            └── Occupancy Point

Schedule Structure:

Home Folder
└── Schedules
    ├── First Floor Weekly
    ├── Second Floor Weekly
    └── Global Boolean Weekly

The Challenge

Indirect Connections:

• Schedules are not always directly linked to control points

• Often connected through intermediate logic:

  • Selector blocks

  • Boolean logic

  • Other processing components

• Direct connection: Schedule → Point ✓

• Indirect connection: Schedule → Selector → Logic → Point ✗

EQL Limitations:

• EQL can query for relations

• EQL cannot query data links directly

• Can't leverage wire sheet connections in hierarchies or PX views

• Need a way to expose these connections as relations

Goal:
Create a smart relation that can:

1. Determine what schedules are linked to which points

2. Work through complex logic chains

3. Be queryable via EQL

4. Update dynamically as connections change

Solution: Smart Relations

What are Smart Relations?

Smart Relations are intelligent, implied relations that:

• Automatically resolve through data links

• Determine connections dynamically at query time

• Update as wire sheet connections change

• Are queryable via EQL

• Don't appear on relation sheets (only data links appear there)

• Appear in Spy Remote view under "Implied Relations"

Key Benefit: Bridge the gap between data links (wire sheet) and relations (EQL queryable)

Implementation Strategy

Overview of Components

1. Tag Dictionary - Define custom tags and relation definitions

2. Tag Rules - Automatically apply tags and relations to components

3. Smart Relation Component - VComPro weekly schedule relation

4. EQL Queries - Find and traverse the relations

Step 1: Create Tag Dictionary

Understanding Tag Dictionaries

Purpose:

• Define all tags used in your station

• Provide namespace for your custom tags

• Document expected tags for station users

• Organize tag definitions and relation definitions

Create Dictionary

1. Navigate to Tag Dictionary Service in station

2. Create new Smart Tag Dictionary

3. Configure:

   • Name: MyBuildingDictionary (or similar)

   • Namespace: b (or your chosen prefix)

Result: Tags created in this dictionary will use b: prefix

Step 2: Define Custom Tags

Create Weekly Schedule Marker Tag

Purpose: Identify components as weekly schedules specifically

Why Needed:

• end:schedule tag exists, but applies to ALL schedule types

• Need to differentiate weekly schedules from other types (trigger, day, etc.)

• Enables more specific tag rules

How to Create

1. Open your tag dictionary

2. Navigate to Tags folder

3. Drag out a Marker Tag

4. Configure:

   • Name: weeklySchedule

   • Full Tag: b:weeklySchedule

Purpose: Documents that this tag exists and is used in the station

Step 3: Define Smart Relation

Create Schedule Relation Definition

Component: Weekly Schedule Relation (from VComPro palette)

Purpose:

• Smart relation that connects schedules to control points

• Resolves through data links automatically

• Provides inbound/outbound relation paths

How to Create

1. Open VComPro Palette

2. Navigate to Relations folder

3. Locate Weekly Schedule Relation component

4. Drag into Relation Definitions in your tag dictionary

5. Configure:

   • Relation ID: scheduleRef

   • Full Relation: b:scheduleRef (namespace implied)

Result: Defines that b:scheduleRef is a valid relation in your system

Step 4: Create Tag Rules

Tag Rule 1: Occupancy Points

Goal: Apply tags and relation to occupancy control points

Rule Configuration

Type: AND Rule (all conditions must match)

Conditions:

1. Condition 1 - Point Type:

   • Type: Enum Point

   • Matches: Components that are enum points

2. Condition 2 - Name Match:

   • Property: name

   • Operator: equals

   • Value: occupancy

   • Matches: Points named "occupancy"

Tags to Apply:

1. Haystack Tags:

   • hs:occupied (from haystack dictionary)

   • hs:cmd (from haystack dictionary)

   • Purpose: Standard haystack identification

2. Smart Relation:

   • Type: Weekly Schedule Relation

   • Relation ID: scheduleRef

   • Purpose: Creates the smart relation on occupancy points

Tag Rule 2: Weekly Schedules

Goal: Apply tags and relation to weekly schedule components

Rule Configuration

Type: Boolean Filter Rule

Conditions:

1. Condition 1 - Has Schedule Tag:

   • Check for: end:schedule marker tag

   • Matches: Any schedule type

2. Condition 2 - Name Pattern:

   • Property: name tag

   • Operator: regex

   • Pattern: .*weekly$

   • Matches: Any schedule ending with "weekly"

   • Examples: "FirstFloorWeekly", "GlobalBooleanWeekly"

Tags to Apply:

1. Custom Marker Tag:

   • Tag: b:weeklySchedule

   • Purpose: Identifies as weekly schedule specifically

2. Smart Relation:

   • Type: Weekly Schedule Relation

   • Relation ID: scheduleRef

   • Purpose: Creates the smart relation on schedules

Step 5: Verify Relations

Viewing Implied Relations

Smart relations are implied - they don't show on relation sheets.

View on Occupancy Point

1. Navigate to occupancy point

2. Right-click → Spy Remote

3. Select Implied Relations section

What You'll See:

Inbound Relations:
- b:scheduleRef ← schedule:/Home/Schedules/FirstFloorWeekly

Meaning: This occupancy point is controlled by First Floor Weekly schedule

View on Schedule

1. Navigate to schedule

2. Right-click → Spy Remote

3. Select Implied Relations section

What You'll See:

Outbound Relations:
- b:scheduleRef → station:|slot:/Drivers/LonNetwork/Floor1/AH_01/points/occupancy
- b:scheduleRef → station:|slot:/Drivers/LonNetwork/Floor1/AH_02/points/occupancy
- b:scheduleRef → station:|slot:/Drivers/LonNetwork/Floor2/AH_01/points/occupancy
(... more points)

Meaning: This schedule controls multiple occupancy points throughout the station

Dynamic Resolution Example

Scenario: Schedule connected through selector block

Wire Sheet:

FirstFloorWeekly → ScheduleSelector → AH_03.occupancy

Initial State:

• Selector set to: First Floor Weekly

• Occupancy point shows: b:scheduleRef ← FirstFloorWeekly

Change Selector:

• Change to: Second Floor Weekly

• Refresh Spy view

• Occupancy point now shows: b:scheduleRef ← SecondFloorWeekly

Key Point: Relation resolves dynamically through the selector!

Use Case 1: Navigation in PX Graphics

Goal

Create a button on air handler graphics that navigates to the controlling schedule.

The Challenge

Starting Point: Air handler device
Need to Find:

1. Occupancy point under device

2. Schedule controlling that point

3. Navigate to schedule graphic

Complication: Schedule may be connected through complex logic

Solution: EQL with Relation Traversal

Step 1: Create Navigation Button

1. Open air handler PX graphic (relative view)

2. Add a Button widget

3. Add a Value Binding to the button

4. Configure hyperlink property (initially null)

Step 2: Build EQL Query - Find Occupancy Point

EQL Query:

equip:hs:occupied and hs:cmd|single:

Breakdown:

Part 1: Find Occupancy Point

equip:hs:occupied and hs:cmd

• equip: - Search under equipment (current device context)

• hs:occupied - Has occupied tag

• and - Boolean AND operator

• hs:cmd - Has command tag

• Result: Finds occupancy point under device

Part 2: Get Single Result

|single:

• | - Pipe operator (chain operations)

• single: - Get first/single item from query result

• Converts BIQuery result to single ORD

Full Query Resolves To:

station:|slot:/Drivers/LonNetwork/Floor1/AH_03/points/occupancy

Test: Click button → navigates to occupancy point property sheet ✓

Step 3: Extend Query - Traverse Relation to Schedule

Complete EQL Query:

equip:hs:occupied and hs:cmd|single:|equip:b:scheduleRef<-|single:

New Section Breakdown:

Part 3: Navigate Relation

|equip:b:scheduleRef<-

• Start from occupancy point (result of previous query)

• equip: - Search in equipment context

• b:scheduleRef - The schedule relation

• <- - Inbound direction (coming FROM schedule TO point)

• Result: Finds schedule(s) with relation TO this point

Part 4: Get Schedule

|single:

• Convert query result to single ORD

• Result: The schedule controlling this point

Full Query Resolves To:

schedule:/Home/Schedules/SecondFloorWeekly/graphic/detail

Understanding Relation Direction

Direction Symbols:

Inbound <-:

• Relation coming FROM another component TO current component

• Arrow points toward current component

• Example: Schedule → Point (from schedule's perspective, outbound; from point's perspective, inbound)

Outbound ->:

• Relation going FROM current component TO another component

• Arrow points away from current component

In Our Case:

Point perspective: b:scheduleRef<- (inbound from schedule)
Schedule perspective: b:scheduleRef-> (outbound to point)

Complete Hyperlink Configuration

Property: Hyperlink
Value:

equip:hs:occupied and hs:cmd|single:|equip:b:scheduleRef<-|single:

Behavior:

1. User clicks button on AH_03 graphic

2. Query finds: AH_03/points/occupancy

3. Traverses inbound b:scheduleRef relation

4. Resolves to: SecondFloorWeekly schedule

5. Navigates to schedule graphic

Dynamic Behavior:

• If selector changes to First Floor Weekly

• Button automatically navigates to First Floor Weekly instead

• No changes to PX graphic needed!

Use Case 2: BQL Grid Reports

Goal

Create a report showing all equipment controlled by a specific schedule.

BQL Grid Component

Component: BQL Grid (from Reports palette)

Purpose:

• Display tabular query results

• Embed in PX graphics

• Double-click navigation

• Real-time updates

Example 1: Find All Occupancy Points

Basic Query

Base ORD:

station:|slot:/Drivers/LonNetwork

EQL Query:

equip:hs:occupied and hs:cmd

Result: 76 rows - all occupancy points in station

Example 2: Filter by Schedule

Goal: Find Only Points Controlled by First Floor Weekly

Enhanced Query:

equip:hs:occupied and hs:cmd and b:scheduleRef<- and end:name=="FirstFloorWeekly"

Breakdown:

Part 1: Find Occupancy Points

equip:hs:occupied and hs:cmd

• Finds all occupancy points

Part 2: Check for Schedule Relation

and b:scheduleRef<-

• Must have inbound schedule relation

• Traverses to the schedule

Part 3: Filter by Schedule Name

and end:name=="FirstFloorWeekly"

• Check the schedule's name tag

• Must equal "FirstFloorWeekly"

• == - Exact match operator

Result: Only points controlled by First Floor Weekly schedule

Adding BQL Projection

Problem

EQL query returns BIQuery result (equipment query)
BQL Grid needs BITable result (tabular data)

Solution: Add BQL SELECT

Complete Query:

equip:hs:occupied and hs:cmd and b:scheduleRef<- and end:name=="FirstFloorWeekly"|
bql:select parent.parent.displayName as Equipment

BQL Section Breakdown:

Navigation:

parent.parent.displayName

• Start at: Occupancy point

• parent - Up to points container

• .parent - Up to air handler device

• .displayName - Get device display name

Aliasing:

as Equipment

• Column header name

Additional Columns (Examples):

bql:select 
  parent.parent.displayName as Equipment,
  displayName as Point,
  parent.parent.parent.displayName as Floor,
  out.display as Status

Configuring Grid Navigation

Default Behavior

Double-click row: Navigates to occupancy point (query result)

Custom Navigation

Hyperlink Property: Supports relative backup ORDs

Example: Navigate to Device

slot:../../

Breakdown:

• slot: - Current component (occupancy point)

• .. - Up one level (points container)

• /.. - Up another level (device)

Result: Double-clicking row navigates to air handler device, not point

Embedding Grid in PX Graphics

Use Case: Schedule Graphics

Goal: Show all equipment controlled by this schedule

Setup:

1. Create BQL Grid component under schedule folder

2. Configure query to filter by current schedule

3. Embed grid in schedule PX graphic

4. Configure hyperlink for device navigation

Benefits:

• See all controlled equipment at a glance

• Navigate directly to equipment graphics

• Updates dynamically as relations change

• Single query, works for all schedules

Complete EQL Syntax Reference

Basic EQL Structure

[base:]tag1 and tag2 or tag3|operation:|operation:

Finding Components

Search by Tags:

equip:hs:occupied and hs:cmd

Search in Scope:

station:tagName          # Search entire station
equip:tagName            # Search under equipment
slot:tagName             # Search from current context

Traversing Relations

Inbound Relation:

b:scheduleRef<-

Outbound Relation:

b:scheduleRef->

Filtering

Check Tag Existence:

and hs:occupied

Check Property Value:

and end:name=="FirstFloorWeekly"

Regex Pattern:

and end:name~=".*weekly"

Result Conversion

Get Single ORD:

|single:

Convert to BQL:

|bql:select ...

Tag Rule Best Practices

Tag Definition Strategy

Always Define Tags:

• Create marker tags in dictionary first

• Documents expected tags

• Provides namespace organization

• Helps other developers understand station

Namespace Selection:

• Use short, meaningful prefixes: b:, myco:, proj:

• Avoid conflicts with standard namespaces

• Document namespace meaning

Tag Rule Design

Be Specific:

• Use multiple conditions to narrow matches

• Avoid overly broad rules that match unintended components

• Test rules on subset before full deployment

Use Standard Tags:

• Leverage haystack tags when applicable (hs:occupied, hs:cmd)

• Combine with custom tags for specific needs

• Maintain compatibility with standard tools

Order Matters:

• Apply base tags before relations

• Ensure dependencies are met

• Consider rule execution order

Testing Tag Rules

Verification Steps:

1. Apply Rules

   • Save tag rules

   • Wait for automatic application

2. Check Components

   • Verify tags appear on target components

   • Use Spy Remote to view relations

3. Test Queries

   • Run EQL queries to verify findability

   • Check relation traversal works

4. Validate Results

   • Confirm only intended components matched

   • Check for false positives/negatives

Troubleshooting

Smart Relation Not Appearing

Problem: Implied relation doesn't show in Spy Remote

Possible Causes:

• Tag rule not applied

• Relation definition not created

• Wrong relation ID

• Component doesn't match tag rule conditions

Solutions:

• Verify tag rule exists and is active

• Check relation definition in dictionary

• Confirm relation ID matches exactly

• Review tag rule conditions

Relation Doesn't Resolve Through Logic

Problem: Can't traverse through selector or logic

Possible Causes:

• Data links not properly connected

• Smart relation not on both endpoints

• Intermediate component breaking chain

Solutions:

• Verify wire sheet connections

• Ensure relation applied to both schedules and points

• Check that smart relation component handles logic type

EQL Query Returns No Results

Problem: Query doesn't find expected components

Possible Causes:

• Tags not applied

• Wrong tag names in query

• Incorrect relation direction (<- vs ->)

• Wrong scope (equip: vs station:)

Solutions:

• Verify tags on target components

• Check tag names match exactly (case-sensitive)

• Try reversing relation direction

• Expand search scope

BQL Grid Shows Error

Problem: Grid displays error instead of results

Possible Causes:

• EQL returns BIQuery instead of BITable

• Missing bql:select projection

• Syntax error in BQL statement

Solutions:

• Add |bql:select ... to convert to table

• Verify BQL syntax

• Test query in component directly first

Key Takeaways

✅ Smart relations bridge data links and EQL queries
✅ Tag dictionaries define custom tags and relations
✅ Tag rules automatically apply tags and relations
✅ Weekly schedule relation resolves through complex logic
✅ EQL traversal uses <- for inbound, -> for outbound
✅ Implied relations appear in Spy Remote, not relation sheets
✅ Dynamic resolution updates as wire sheet changes
✅ BQL grids provide tabular reports with navigation
✅ PX navigation leverages relations for intelligent hyperlinks
✅ Relations are queryable unlike data links

Coming in Part 2

The next video will cover:

• Building local hierarchies in the JACE using smart relations

• Creating enterprise hierarchies at supervisor level

• Leveraging System Database for relation-based hierarchies

• Advanced hierarchy navigation techniques

Quick Reference

Create Smart Relation

1. VComPro Palette → Relations → Weekly Schedule Relation
2. Add to Tag Dictionary → Relation Definitions
3. Set Relation ID (e.g., "scheduleRef")

Apply to Components via Tag Rules

Occupancy Points:
- Conditions: Enum Point, name="occupancy"
- Apply: hs:occupied, hs:cmd, b:scheduleRef relation

Schedules:
- Conditions: end:schedule, name matches ".*weekly"
- Apply: b:weeklySchedule, b:scheduleRef relation

EQL Navigation Pattern

equip:tags to find component|single:|equip:relationName<-|single:

BQL Grid with Schedule Filter

equip:hs:occupied and hs:cmd and b:scheduleRef<- and end:name=="ScheduleName"|
bql:select parent.parent.displayName as Equipment

Presenter: James Johnson
Series:Niagara PRO TIPS
Topic:Schedule Relations Part 1 – Smart Relations and PX
Part:1 of 2
Key Concept:Using smart relations to create dynamic, queryable connections between schedules and control points, enabling intelligent navigation and reporting even through complex logic chains

YouTube: http://www.youtube.com/@TridiumInc