RTI Golden Template Authoring

This guide walks through building an ISR-2 golden template from scratch in Integration Designer 11. A golden template is a normal Integration Designer project that carries all of the visual design; the RTI page fills it with a site's actual sources at generation time. You author it once per remote model.

The contract in one paragraph: generation edits the GEM driver's connection settings, the text/wiring of buttons tagged GEM: Source 1 … GEM: Source 19, the name of the first room, the project's job info, and its 802.11 settings. It also fills gaps you leave open: unprogrammed standard hard-key tags get wired to the matching GEM driver functions, and if no GEM: Source 1 prototype exists, source buttons are seeded with a built-in style on generated pages of their own — after which the wizard scaffolding those pages replaced is removed. Everything you author yourself passes through byte-for-byte and always wins over the automatic fill.

The short version: Steps 1 and 2 alone — the new-project wizard plus the GEM driver — produce a working template. Every step after that is design polish, not a requirement. Do them when you want the remote to look like yours instead of like the default.

Prerequisites

• Integration Designer 11 (the template format is validated against 11.13.x).
• The current GEM Automation driver package (GEM Automation.rtidriver), version 2.2 or later — runtime labels, availability, and the connect-time manifest arrived in 2.1; the zone-feedback variable pool that lights subsystem zone buttons arrived in 2.2. The driver is embedded in the template, so an old template keeps shipping an old driver until it is re-saved with the new package.
• For the final round-trip test: an XP processor and ISR-2 on the same network as a GEM controller.

Step 1 — Create the project skeleton

1. Start a new project. The Add Workspace Item window guides the initial build.
2. Main processor: select your XP processor (XP-3 or similar). The GEM driver runs on the processor — do not choose <Standalone>.
3. Rooms: add exactly one room. Name it anything ("Room 1" is fine) — generation renames the first room to the mirrored AV zone's name. Do not add a second room; the phase-1 generator only manages one.
4. Controllers: select the ISR-2 and place it in the room (local placement — the template is single-room by design). On the controller options screen:
   • Page Template: any design you want to build on — but pick one. A panel with no pages at all cannot host generation (every generated page clones the panel's first page), and the RTI admin page will refuse to export for it.
   • Options: choose Button Menus, not List Menus. List menus auto-populate from RTI's room/activity system, which generation does not drive — the source list will be your own tagged buttons instead.
   • Add Pages: designer's choice; the default home and weather pages are safe to keep or remove. Wizard pages the generated page set replaces are removed from the finished program anyway (see Template page cleanup).

Step 2 — Install the GEM Automation driver

1. Copy GEM Automation.rtidriver into Documents\Integration Designer\Drivers on the programming PC.
2. In Add Workspace Item, open the Drivers tab and switch the library dropdown from SYSTEM to USER.
3. Select GEM Automation and add it to the Global area (it serves the whole processor, not one room).
4. In the driver's configuration, set GEM Address and GEM Port to your test controller. The values don't matter for the template itself — generation overwrites them per site — but real values let you test the template live before saving it.
5. Switch the library dropdown back to SYSTEM afterward so future driver adds behave normally.

Do not add RTI source devices, activities, or driver-provided pages for the sources the remote will control. GEM sources arrive at generation time through the placeholder buttons in Step 4.

Step 3 — Build the pages

Full designer freedom: backgrounds, fonts, clock, layout. Two structural rules:

• Source selection lives on plain buttons you draw yourself (Step 4), not on a system source list or activity menu.
• Keep every page in the one room / the ISR-2's page set. Anything you add here ships untouched in every generated file — with one exception: a page nothing points at once generation has finished is removed from the output. Give a page a macro link, GEM content, or a GEM: name and it always survives.

A minimal proven page set: a Home page with the source buttons, and the hard-key layer programmed once (Step 5). Pages for lighting/climate can come later — those are a later generation phase.

Step 4 — Source prototype buttons

This is the part generation consumes — and you only need to draw one or two buttons.

1. On the source page, draw the button for slot 1. Style both states:

   • Normal state — how an inactive source looks.
   • Active state — the highlight. Give it strong contrast (fill or border change); this is what lights up when the source is playing. Generation binds the active state to the driver's rti_source_1 variable for you.

2. Set the button's text to anything readable ("Source 1"). At generation the text becomes a reference to a GEM text tag that carries the live source name, with the generated label as its fallback, so a rename in GEM renames the button without a re-download. Use plain static text — do not bind the label to a variable.

3. Open the button's Tag tab (or the Button Tags toolbar) and type the tag name exactly:

   GEM: Source 1

   Capital GEM, colon, space, Source, space, plain number — no leading zeros. The number is the source highlight slot.

4. Do not program a macro or feedback on this button. Generation writes both (the press macro and the highlight binding) and deletes anything you wired on these tags. Wiring one temporarily to test is fine — just know it won't survive.

5. Optionally, copy the button, tag the copy GEM: Source 2, and place it where the second source should sit. The offset between slots 1 and 2 defines the position step — generation clones slot 1 for every additional source the site needs, continuing that spacing. Without a slot-2 button, clones stack straight down at the prototype's height plus a small gap.

6. If the source list should appear on more than one page, put a GEM: Source 1 button on each page. Generated buttons appear on every layer that carries the slot-1 prototype.

You can still draw all the placeholders by hand — any slot you draw yourself is used exactly as drawn, and generation only creates buttons for slots that don't exist. Hand-drawing is the way to get a grid or any non-linear arrangement; the cloner only continues a straight series. Generation warns when a cloned button would land off the 240×320 screen, so a template intended for big source counts should place slot 1 high and keep the step tight, or draw the extra slots itself.

Step 4b — Source control pages (optional, recommended)

After selecting a source, the remote can land on a control page for it. Because every GEM driver function is contextual — Transport play always acts on the zone's current source — one page per source type serves every source of that type. No per-source pages are needed.

1. Create a page and rename it exactly GEM: Video (page name, not a button tag). Design it for video sources: transport row, navigation pad, whatever fits.
2. Optionally add GEM: Audio for music sources, and GEM: Source as the generic fallback for types without a page of their own.
3. Program the page's buttons with the contextual GEM Automation functions from the Step 5 table. They are shared by every source that lands there.
4. For a live title, bind a text object on the page to the driver's Source Name variable — it reads "Roku" or "Sonos" depending on what's active, at runtime.

At generation, every source button gets a page link — Integration Designer's own native link, written on the button's tag rather than as a macro step — to the page matching the source's AV type in GEM (video → GEM: Video), falling back to GEM: Source. The button's macro is left to do the one thing it does: select the source. If the template has no GEM: pages at all, no page link is added and buttons only select the source.

Step 5 — Hard keys and fixed controls

Program these once; they ship untouched in every generated file. Select each hard key on the ISR-2's hard-key layer (and any drawn transport/volume buttons), confirm its standard tag, and drag the matching GEM Automation driver function into its macro:

Key / tag	GEM Automation function	Parameter
Volume Up / Volume Down	Volume / Channel (Repeat)	volume_up / volume_down
Mute	Volume / Channel	mute_toggle
Channel Up / Channel Down	Volume / Channel (Repeat)	channel_up / channel_down
Play / Pause / Stop	Transport	play / pause / stop
Scan Back / Scan Forward	Transport	rewind / fast_forward
Previous / Next	Transport	skip_back / next
Up / Down / Left / Right	Navigation (Repeat)	up / down / left / right
OK / Select	Navigation	select
Back / Return	Navigation	back
Menu	Navigation	menu
Home	Navigation	home
Power	Power	—
Digits 0–9	Keypad	0 … 9

The Repeat variants matter: they re-fire while the key is held, which is what makes volume ramps and directional scrolling feel right. GEM routes every one of these generic verbs to whatever device is active in the remote's AV zone, and the Power key's behavior is configured per remote on the Remotes page — none of it is baked into the template.

Step 6 — Optional live status (recommended)

These driver variables update over the bridge at runtime and survive generation. Bind them wherever they fit the design:

• A text object bound to Source Name and/or Now Playing / Artist.
• A text object bound to Zone Name (GEM pushes the zone's label on connect).
• A text object bound to Temperature and/or Setpoint (driver 2.3+), and reverse-state feedback on a hand-drawn mode button bound to one of the four climate mode booleans — climate_mode_heat, climate_mode_cool, climate_mode_auto, climate_mode_off (driver 2.3.2+). Reverse-state feedback binds a boolean, so lighting one of four buttons takes four variables; GEM pushes the whole set with exactly one true. All of these follow the remote's designated climate zone, set on the Remotes page or written back when a climate page is generated.

Hand-drawn zone buttons can use the same feedback pool the generator binds: the Zones variable category holds 32 boolean slots (true while the zone is on, open, unlocked, or armed), Zone Labels their live names, and Zone Availability whether GEM currently has a zone in the slot. GEM assigns slot numbers during generation for a linked remote and logs the map; the Zone Names driver settings rename the slots in the variable list.

• A volume gauge or slider bound to Volume.
• A connection indicator bound to Connected — useful during commissioning.

Bind via the button/object's variable window, selecting the GEM Automation driver and the variable.

Step 7 — Test, save, deploy

1. With the driver pointed at your test GEM controller, download the project to the processor and ISR-2 and confirm the hard keys work end to end (transport keys reach the zone's active source, volume ramps, status text updates).
2. Save the project — a name like golden_isr2.apex keeps intent obvious.
3. On the RTI admin page, click Upload Template and select the file (or copy it into the controller's rti/templates folder by hand). The upload is validated on arrival — a file without the GEM Automation driver is rejected, a program GEM generated is rejected (it names the template it came from), and re-uploading the same name replaces the previous version.
4. The template should now list as valid, showing the driver version and the number of source placeholders it found.
5. Generate against a real AV zone, open the output in Integration Designer, and spot-check: source buttons renamed, driver address updated, room renamed, leftover placeholders gone, the generated menu first in the page list. Download to the ISR-2 and confirm a source button selects its source and highlights when active.

What generation changes vs. what it never touches

Generation changes	Generation never touches
GEM Address / GEM Port driver config	The design of any page it keeps: layers, layout, styling, bitmaps
Text + macro + highlight binding of GEM: Source N tagged buttons	Hard-key programming and any macro on other tags
Clones the slot-1 prototype for slots that aren't drawn	Status/variable bindings from Step 6
Adds a native page link to the matching GEM: <type> control page	Contents of the control pages themselves
Slot label names in the driver config	Processor, controller, and driver membership
First room's name	Every field it doesn't understand
Job info client name/notes, network key
The project's 802.11 settings, when the site has a Wi-Fi network saved on the RTI page
Removes unused GEM: Source N placeholders
Removes the wizard's list widget from a layer it seeds source buttons onto (classic layout only)
Removes template pages the generated pages replaced, and puts the generated menu first in the page list (see below)

Pages generation removes

The default menu-home layout builds its own entry points, so the wizard scaffolding it replaces — "Home - Buttons", "Power Menu" and the like — is dropped from the finished program rather than left in the page list. A page you authored survives if anything still points at it:

• it is named GEM: ... (a control page a generated button can land on),
• it carries a button tagged GEM: ... (this is what keeps the home page in the classic sources-on-home layout),
• a macro page-links to it, or
• it is the last page left on that panel.

Nothing is removed from a panel generation built no pages onto, and the export summary lists what went. If a hard key was linked to a removed page, the summary names the key so you can repoint it. Set home_menu false in the generation request to keep the classic layout, or prune_template_pages false to keep every template page.

Parts-bin templates (site programs)

A site program normally expects the template to already carry every remote, one per room, the way Integration Designer's new-project wizard builds a multi-remote job. A parts-bin template removes that requirement: author a template with one panel per remote model you support (one ISR-2, one ISR-4, ...). On the RTI admin page, the template's own panels seed the first remote rows, and Add <model> appends more — each added row names the panel by model instead of by RTI address.

For each added row, generation clones the matching archetype panel — a fresh RTI address and serial number, its own room, and a full copy of the archetype's pages, hard-key layers, and control pages — then generates that panel's content as usual. Archetype panels no row targets directly are removed from the output, so the generated program carries only the site's real remotes. One stock template covers any mix of rooms and panel counts.

Identity fields Integration Designer fills at download time (device hash, target MAC) are left blank on clones exactly as the wizard leaves them on a new panel, so the first download pairs the hardware normally.

Common mistakes

• Tag typo — Gem: Source 1, GEM:Source 1, and GEM: Source 01 are all different tags and won't be found. The prefix must match exactly.
• List Menus selected when adding the controller — the auto-populated source list stays empty because generation doesn't create RTI activities. Button Menus with your own tagged buttons remain the cleanest layout. The default menu-home layout never draws on the wizard's home page, so its list machinery is left alone; only in the classic sources-on-home layout (home_menu false) does generation remove the wizard's list widget from a layer it seeds source buttons onto, so the seeded buttons receive presses — a hand-drawn layout is never touched.
• A second room in the template — only the first room is renamed; a second room ships with its template name in every generated file.
• Variable-bound text on a placeholder — generation removes bindings on GEM: Source N tags when it writes the highlight binding; use static text.
• Macros left on placeholder tags — harmless but pointless: generation deletes and rewrites them.
• Uploading a generated program as the template — refused, naming the template the program was generated from. The output is not a donor: its GEM: Source N buttons read as a hand-drawn list, so the source and channel pages would be skipped and a provider's renumbered channels would stay at their old values silently. Upload the Integration Designer project it came from, or use Regenerate on the Linked Remotes list to refresh a program against current data.
• Stale driver in the template — the driver package is embedded in the project file. When the GEM Automation driver is updated, update it in the template and re-save; generated files carry whatever version the template holds.

Related Documentation

• RTI - Generating programs from this template
• Remotes - Runtime key mapping, source slots, and status updates