RTI

The RTI page generates a ready-to-load Integration Designer project (.apex file) from the current GEM configuration. Instead of hand-programming source buttons, driver settings, and feedback bindings for every remote, GEM fills a pre-styled template with the sources of a selected AV zone and hands back a file that opens directly in Integration Designer.

Generation works with the GEM Automation RTI driver, the bidirectional TCP bridge that connects an RTI XP processor to GEM (default port 6336). Remotes programmed this way appear on the Remotes page like any other IP remote.

Workflow

1. Pick a template. A stock ISR-2 template ships with GEM — on a fresh install it is seeded into the template folder automatically, so there is nothing to author. For other panel models, author a golden template in Integration Designer (see below) and upload it with the Upload Template button; uploads are validated before they are accepted, and uploading a file with the same name replaces the existing template. A program GEM generated is refused, naming the template it came from: feeding output back in looks like it works and does not — the previous run's source buttons read as a hand-drawn list, so the source and channel pages are skipped and a provider's renumbered channels would stay at their old values with no warning. To refresh a program against current data, use Regenerate on the Linked Remotes list, which rebuilds from the stored recipe off the original template. Delete removes the selected template from the controller — programs already exported to remotes keep working, but a remote whose recipe references the deleted template cannot regenerate until a template with that name is uploaded again (the page warns which remotes are affected before deleting). A project straight out of the new-project wizard already works.
2. The page comes back the way you left it. Selecting a template you have exported before restores its remote rows from what that export stored on each remote — the UI, AV zone, room name, spare slots, checked subsystems, excluded sources and the exact slot numbers, plus the model-cloned rows that exist only in generated output. Nothing extra is saved to make this work; it is read back from the remotes. A row whose UI has since been deleted comes back without one and asks for a new one, and Start from the template instead discards the restore for a clean sheet. A template you have never exported seeds fresh rows instead:
3. The page seeds one remote row per panel the template carries. Add <model> appends more remotes of a model, and Add a remote for every room seeds one per AV zone in one click (see Site Programs below). A template room named like an AV zone claims that zone automatically.
4. For each remote row, pick the UI it mirrors (only shown when the site has more than one; the UI supplies the row's AV zones, its subsystem list and the generated theme — GEM's seeded catch-all "All" UI is not offered, since a remote mirrors a room, and the page says so when the site has no UI at all and offers Create a UI, which opens the UI creator in a dialog over this page — the uploaded template, the remote rows and your overrides live only in the page until you export, so leaving for UI › UIs would discard them; a remote can only mirror an enabled UI, and a new one defaults to disabled) and the AV zone it controls (if not already auto-matched). The checkbox beside each row selects it for export — uncheck rooms that shouldn't be in this program (no AV zone, no remote yet, audio-only spaces you'll cover later); an unchecked row keeps its configuration for next time. Everything else is derived — sources with slots and labels, the RTI room name, the UI theme, and the linked GEM remote (an existing remote bound to the zone, or a new one provisioned on export). Expand a row to override any of it: include/exclude sources, edit labels and slots, check subsystem pages and order them, hide individual zones, adjust spares. What you override by hand is stored on the remote and survives a Regenerate — see What you change by hand survives a regenerate.
5. Set the site's Wi-Fi Network (SSID) and Wi-Fi Password in the Connection section once. They are stored with the site (the passphrase encrypted at rest) and baked into every exported program's 802.11 settings, so the remotes join the house network without a trip through Integration Designer's own network defaults — which is what a generated program would otherwise inherit from whichever machine last opened it. WPA2-PSK. Leave the password blank on later exports to keep the stored one; clearing the SSID clears both. RTI stores the passphrase in the program file in the clear, so treat an exported .apex as a secret.
6. Check the Connection section — the GEM address and RTI processor IP are pre-filled where possible; the client name defaults from the site record. Bridge ports are assigned automatically.
7. Optionally click Preview Screens to draw the pages the export would produce, without downloading or saving anything — see Preview the Screens Before You Download.
8. Click Export RTI Project. The .apex file downloads in the browser.
9. Open the file in Integration Designer and download it to the processor and remotes as usual.

Golden Templates

A golden template is a normal Integration Designer project that carries the visual design: pages, layouts, styling, hard-key assignments, and the devices themselves (processor, remote, and the GEM Automation driver). Author it once per remote model; generation never alters layout or styling. See RTI Golden Template Authoring for a step-by-step build guide.

Two hard requirements: the GEM Automation driver installed on the processor, and at least one page on every remote panel — generation is clone-and-edit, and every page it builds derives from the panel's first page, so a wizard project saved without a page template applied to the panel has nothing to build on. The template list flags such a panel the moment the template is selected, and an export that asks for content on one fails with the same message rather than producing an empty program. A project straight out of Integration Designer's new-project wizard (processor + room + controller with a page template applied + driver) is already a working template — generation wires every unprogrammed standard hard-key tag to the matching GEM driver function and seeds source buttons with a built-in style. Everything beyond that is optional customization:

• A source button tagged GEM: Source 1 — the prototype. When present, generation clones your styling for every source instead of the built-in style, continuing the spacing defined by an optional GEM: Source 2 button. Slots drawn by hand are used exactly as drawn; the number in the tag is the source highlight slot — the rti_source_<n> variable the button's active state binds to.
• Control pages named GEM: Video, GEM: Audio, or GEM: Source (the generic fallback). Each generated source button page-links to the page matching the source's AV type. One page serves every source of its type — the GEM driver's transport and navigation functions always act on the zone's current source.
• Hand-wired hard keys. Auto-wiring only touches tags with no macros, so anything you program yourself always wins.
• A source can appear on multiple pages; put a slot-1 prototype (or a hand-drawn copy with the same slot tag) on each page.

During generation, each mirrored source gets a button: the text becomes the source label, the press macro selects the source and links to its control page, and the highlight feedback is bound to the source's slot. Placeholders with no source assigned are removed from the generated project, along with their tags and macros.

Site Programs — Multiple Remotes, One Processor

An XP processor runs a single program, so a site with several remotes on one processor (the normal shape now that ISR remotes are WiFi — one remote per room) must generate them together: downloading a program generated for one remote alone would wipe its siblings.

The page handles this automatically: a single remote row on a single-panel template exports the classic single-remote program, and anything more — a template carrying several panels, or extra rows added with Add <model> — exports as one site program. In a site program:

• every panel gets its own GEM driver instance, cloned from the template's, with its own source/zone variable pools and its own bridge port — the ports come from each panel's linked GEM remote, so every panel must be linked to (or create) a remote;
• each panel's buttons, pages, and hard keys are generated only on that panel, in that panel's room, bound to that panel's instance;
• hard keys shared between panels (same button tag on both) are wired per room; exclusive ones stay global;
• each room is renamed to its panel's mirrored zone.

The template does not have to carry every remote in advance. A parts-bin template holds one panel per remote model; rows the template's own panels cover claim those panels directly, and every row added with Add <model> stamps a fresh clone of that model's archetype — its own RTI address and serial number, its own room, and a full copy of the archetype's pages and hard-key layers. Archetype panels no row targets directly are pruned from the output, so one stock template covers any mix of rooms and panel counts. See Parts-bin templates for authoring.

Regenerating any member remote regenerates the whole site — the badges on Linked Remotes track each member separately, but the file is always the complete program. A model-cloned panel regenerates by cloning again from the pristine template (its generated address exists only in generated output). Templates carrying hand-drawn GEM: Source N placeholders are a single-remote concept; a site export warns and ignores them (it seeds per-room buttons instead), so prefer a clean wizard project as the site template.

Driver Package

Each template carries its own embedded copy of the GEM Automation driver, frozen at whatever version was installed when the template was saved — so a driver release normally means re-opening every template in Integration Designer. The Driver section on the admin page removes that round-trip: upload the packaged driver (.rtidriver), and GEM rewrites the embedded driver inside every stored template in place. Everything the integrator owns — layouts, styling, the template's GEM address, hard-key wiring — is untouched; only the driver payload changes.

• The stored package's version becomes the release the Linked Remotes badges compare against, replacing the built-in default.
• Each template is listed with its embedded driver version; Refresh Templates re-applies the stored package, which covers templates uploaded after the package was stored.
• Download Driver Package hands back the stored .rtidriver — install it in Integration Designer when authoring a golden template for a new panel model, instead of hunting for the file.
• Remotes still run whatever was last downloaded to them — after a refresh, regenerate and download in Integration Designer as usual. The driver-outdated badge tracks which remotes are behind.

Source Slots

Slots 1–19 match the rti_source_0..19 highlight variables declared by the GEM Automation driver (slot 0 is reserved for "no source active"). The admin page assigns slots in list order; a source's slot can be edited before generating. The generated file also names each slot in the driver's configuration, so Integration Designer shows "Roku" rather than "RTI Source 2" in its variable list.

The slot numbering in the generated project must agree with what GEM reports at runtime — see Source Highlight Slots for how GEM resolves the slot for each source.

Generated Pages and Styling

• One button per device — if the AV zone lists the same device twice (two source entries pointing at the same box), only the first gets a source button. The two would send the identical command anyway, and the remote's slot map is keyed by device, so the second one would take the first one's slot and leave that button unlabeled. The export summary names the duplicate.

• Theme matching — generated buttons and pages take their colors from the mirrored UI's theme (--surface-color, --primary-color, --border-color, --text-primary), so the remote matches the house look. A GEM: Source 1 prototype in the template overrides this entirely.

• Button faces — generated buttons are drawn as rounded, gradient-shaded faces (normal and active/pressed states) baked into the program as bitmaps, in the theme's colors. A button that gets faces carries no flat fill underneath, so nothing square shows at the corners when it highlights; the flat per-state colors are used only as the fallback for templates without a bitmap store. Pass button_faces: false in the generation request to keep the flat vector style.

• Per-source control pages — each source gets a page holding only the functions its device actually supports, minus whatever the template's hard keys already cover. A now-playing header leads the page: the track title (falling back to the source name until the first update) and artist, live from the zone's media metadata over the bridge. An author page named exactly GEM: <source label> always wins; the per-type pages (GEM: Video…) remain the fallback.

• Channels page — a source whose device carries a channel lineup (Roku and Apple TV sync their installed apps into GEM automatically; tuners use their channel list) gets a generated Channels page, linked from the source's control page. Each button selects the source and launches the channel. Favorites lead in their sort order and the rest of the enabled lineup follows, continuing onto numbered pages when the list runs past one screen — up to 60 channels per source, which is six pages deep and keeps the baked logo set to a sane size in the file. A lineup longer than that is trimmed from the far end with a generation warning naming what was left off; favorites always come first. A source with no favorites gets no page, so mark favorites on the source's channel list; regenerating picks up the changes, and the Linked Remotes badge flags when the channels have drifted from the installed program. Channel logos are baked into the program as icons — the logo sits in the top band of the button with the label along the bottom edge — fetched from each channel's logo and cached on the controller (rti/logos), so repeat exports don't re-download them; a channel whose logo can't be fetched gets a text-only button.

• System power page — a generated System Off page, linked from the menu home, with one off per thing the remote actually carries: <Subsystem> Off for each on/off subsystem exported to it (Lights Off, Fans Off, …) and AV Off for the remote's AV zone. It is named System Off rather than Power because a site can have a Power subsystem of its own, and two menu entries reading Power is a coin toss for whoever presses one. Both resolve on the controller when the button is pressed — the subsystem's zones and the AV zone's devices are read live — so a zone or source added later is covered without regenerating. Climate is left out (a thermostat's off is a different thing, and it should not be one press away on a power page), and so are shades, gates, garages and lifts, which open and close rather than turn off. A remote with no on/off subsystems and no sources gets no page.

• Subsystem pages — the page's subsystem picker lists every subsystem with zones in the mirrored UI's scope. Each checked subsystem becomes a generated page, in one of these shapes:

  • Lighting subsystems get scene buttons, not individual zones (unless the UI carries a Lutron keypad — see below) — the same scenes the UI's lights view shows. When the UI defines explicit light scenes, each becomes a button that runs its scene macro; with none defined, the three auto scenes (Bright, Soft, Off — including any custom labels configured for them) drive every light zone in the UI's scope at 100/50/0. Auto-scene membership is resolved on the controller at press time, so lights added later are covered without a re-download; adding, removing, or renaming an explicit scene flags the remote as config changed — regenerate.
  • A lighting subsystem whose UI carries a Lutron keypad gets that keypad instead — when the mirrored UI has a Lutron control station on it (the lutron_qsx driver's Sync Areas writes lutron_control_station_id onto every UI it builds), the lighting page carries the keypad's own engraved buttons rather than GEM's scenes, exactly as the UI's lights view does. Each button presses the real button on the processor, so the keypad's own programming decides what happens and GEM never has to model the scene behind it — re-engrave or reprogram a button in the Lutron database and a regenerate follows it. Buttons run in button order, one per row where the page has the rows for it — mirroring the column of keys on the wall — and two-across when the keypad has more keys than that, because a keypad split across a More › link stops mapping to the thing on the wall. Buttons the processor reports as unprogrammed (an unassigned raise/lower pair) are left off. A UI carrying several keypads gets one page per keypad behind a hub of keypad names, because two keypads' buttons run together would read as one keypad that exists nowhere in the room. Press only — RTI has no hold gesture on a generated button. If the processor cannot be reached when you generate, the page falls back to scenes with a warning saying so; a keypad added, removed or re-engraved afterwards flags the remote as config changed — regenerate.
  • Shade subsystems get scene buttons too — the same scenes the UI's shades view shows, for the same reason lighting does: a facade is a dozen shades, each needing an Open and a Close button plus one of the 32 zone-feedback slots, and nobody drives a facade one shade at a time from a handheld. When the UI defines explicit shade scenes, each becomes a button that runs its scene macro; with none defined, the auto scenes are Open / Half / Close when the shade subsystem's device has a level command and Open / Stop / Close when it does not — exactly what the shades view offers. Membership and the level-versus-verb choice both resolve on the controller at press time, so a shade added later is covered without a re-download, and a shade page claims no zone-feedback slots at all, leaving the pool for the zones that still show live state. This covers shades, blinds and drapes; gates, garages and lifts keep their per-zone buttons, since "open the gate" names one gate.
  • Climate subsystems get one control page mirroring the UI's climate control layout: the current temperature large on the left, the setpoint with +/− step buttons on the right, and the zone's system-mode buttons (heat/cool/auto/off, narrowed to what the zone declares) anchored along the bottom edge of the page. The page carries a single zone — the remote's designated climate zone when it is in the UI's scope, otherwise the first climate zone by sort index — and generating writes that choice back to the remote's climate_zone_id, so the live temperature/setpoint feed always matches the page. The mode buttons show which mode is active, live over the connection — driver 2.3.2 declares one boolean per mode (heat/cool/auto/off) because reverse-state feedback binds a boolean and a single mode string cannot light one of four buttons; a template carrying an older driver keeps its mode buttons command-only. Setpoint steps are computed on the controller from the zone's live values — dual-setpoint zones move the side their mode selects, auto moves both — and dual-setpoint thermostats display the side their mode selects, refreshed on every side change or mode flip.
  • Fan subsystems get a speed page per zone mirroring the UI's fan control: the zone's name across the top and High / Med / Low / Off below, each sending the zone's level (100 / 66 / 33 / 0 — the same values and thresholds the UI control uses, so both agree on what a press did). The fan's button on the subsystem page opens that page instead of toggling, and keeps its live label and its on/off highlight. The four speed buttons carry no highlight of their own: the driver's zone pool has one boolean per zone, which says on or off and cannot say which speed.
  • Everything else gets zone buttons — open/close pairs for gates, garages and lifts, toggle for the rest.

• Menu glyphs — each entry on the generated menu wears the same icon that subsystem gets on the app's Controls grid, taken from the mirrored UI's theme where the theme ships a glyph and the core icon set otherwise. They are recolored to the button's text color, because the glyphs are monochrome and the generated faces are dark. An entry whose glyph cannot be read falls back to text only.

• Menu home (the default layout) — the remote lands on a generated menu of entry points: the source groups plus one button per exported subsystem page. When the mirrored sources include both audio and video types, the source list splits into Video and Audio entries, each landing on its own generated page of that type's sources (spare slots ride with the video/general group); a single-type source list stays one Sources entry. Nothing is drawn on the template's original home page (which also sidesteps List-style wizard homes, whose list machinery swallows presses aimed at buttons drawn over it) — it is removed from the finished program along with any other template page the generated pages replaced, see Template page cleanup below. The menu is placed first in the panel's page list, which is what the remote actually boots on. An unprogrammed Home hard key returns to the menu instead of sending the source a home command — the source verb stays available on the touch pages. A hand-drawn source prototype overrides the split: the menu's Sources entry links to the author's page as drawn.

• Classic layout — set home_menu false in the generation request to put sources directly on the template's home page instead. When generation seeds its own source buttons there, it removes the wizard's stock list widget from that layer so the buttons receive presses (a generation warning notes the removal; hand-drawn layouts are never touched).

• Live zone state — with driver 2.2 or later in the template, zone buttons show state: a fan's button lights while the zone is running, a gate's Open button while it is open, and a rename in GEM relabels the button over the live connection, no re-download needed. Each zone is assigned one of 32 feedback slots, persisted with the remote so regeneration never moves a slot an installed program still uses. Zones beyond the pool keep working as command-only buttons. Templates saved with an older driver stay command-only, exactly as before.

• Template page cleanup — once the generated pages are built, the template's own leftover pages are removed from the program, so what opens in Integration Designer is the site's page set and nothing else. A page stays if anything still points at it: a macro links to it, it carries generated GEM content (the classic sources-on-home layout keeps its home page this way), it is named GEM: ..., or it is the last page on that remote. Removed pages are listed in the export summary, and if a hard key was linked to one, a warning names the key so you can repoint it. Nothing is removed on a remote that generation didn't build pages for.

• Live text and navigation use Integration Designer's own mechanisms. A button whose label comes from GEM (source names, now-playing, zone labels, the climate readouts) references a text tag: its text reads $%TAG!<tag>%$, a text-tag link ties the button to the tag, and the tag carries the actual variable binding with the baked label as its fallback. Navigation is a page link on the button's tag, not a macro step — a source button keeps its macro (it selects the source) and takes a page link beside it. Templates old enough to have no text-tag table fall back to a baked static label, which does not update but does display.

• Synthesized pages clone the template's first page (background, chrome layers) and carry a copy of the hard-key layer, so physical keys keep working everywhere. Generated content is laid out inside the space the chrome actually leaves: the title bar, clock, and other shared-layer objects are measured, and buttons flow below the top band and above the bottom band rather than assuming a fixed margin — slimmer chrome in the template means more room for content. Row height is fitted to that space rather than fixed, so a page of six buttons fills the screen instead of stacking short rows with the bottom half empty; a sparse page stops growing at a comfortable maximum and a crowded one stops shrinking while its labels are still readable.

• A list too long for one screen continues onto the next page rather than being drawn off the bottom edge. The last cell becomes More ›, which opens <page name> 2, and every continuation page carries a ‹ Back to the one before it — chained as deep as the list needs, all at the same button size so the pages look like one set. This applies to every generated list: channels, zone buttons, scenes, source lists, the System Off page and the menu itself. A page that already fits is untouched — no More button, no extra page.

Preview the Screens Before You Download

Preview Screens (beside Export) runs exactly the generation Export would run and draws what comes out — every generated page at the panel's real proportions, with each button in the position, size and label it will actually have. Blue buttons open another page, grey ones send a command, dashed outlines are display-only, and a green ring marks a button bound to live state or a live label from GEM. Multi-panel site programs get a tab per remote.

Nothing is written: no file is downloaded, no remote is provisioned, no Wi-Fi credentials are stored, no recipe or slot map is saved, and the generated-file history is untouched. Warnings appear alongside the pages, so a label that will not fit or a subsystem that produced nothing is visible before anyone opens Integration Designer.

It is the same code path as Export on purpose — a preview built from a simplified layout would be a preview of a different program.

Linking a Remote

Each remote row links to a GEM remote — picking the AV zone auto-selects an existing remote already bound to that zone, or defaults to creating a new one. The link makes GEM the source of truth for the program:

• The final slot map is computed server-side, honoring any explicit rti_source device attributes, and persisted on the remote — runtime highlights and manifests can never disagree with the generated file.
• A generation stamp is written into the program and onto the remote. The GEM Automation driver (2.1+) reports its stamp when it connects; GEM logs a stale-program warning and records the reported value as the remote's program_generation attribute, so a remote running an outdated program is visible.
• Spare Slots adds hidden source buttons wired to select by slot. When a source is later added in GEM and the program is regenerated for the linked remote — or the slot map is otherwise updated — the manifest marks the slot used and the button appears on the remote, labeled and working, without opening Integration Designer.

Without a linked remote, generation behaves as before: slots are taken from the page as shown, and nothing is persisted.

Creating the remote during export

A row set to Create new remote (the default when no existing remote is bound to the zone) provisions the remote in the same stroke — GEM assigns it a free bridge port on the RTI Processor IP from the Connection section (baked into the program's driver settings, so nothing needs to be copied between pages), binds it to the row's AV zone, names it after the room unless a name is typed, and starts listening before the file downloads. The GEM Address field is pre-filled with the controller's LAN address; the processor IP is pre-filled from an existing remote when there is one.

Press test

Every linked remote's row carries a Press test button that streams the remote's key events live — press buttons on the physical remote and watch each one register with its resolved action, straight from the page you commissioned it on. Handy for the final walk-around: if a key doesn't appear in the stream, it never reached GEM.

Regenerate with one click

Generating for a linked remote also stores the generation recipe — the template, UI, AV zone, subsystem picks, and exclusions — on the remote. From then on, the remote's row in Linked Remotes carries a Regenerate button that rebuilds the program against the current configuration: sources added to the AV zone since the last run are included automatically (existing buttons never renumber), renames and zone changes flow through, and the fresh file downloads immediately. Adapting a remote to a config change becomes one click plus an Integration Designer download — no form to re-walk.

Sources deliberately excluded during the original generation stay excluded on regenerate. To change what's included, generate from the form again; the new run replaces the stored recipe.

What you change by hand survives a regenerate

Everything on a remote is derived from live configuration — that is what makes Regenerate safe to press. The exception is the handful of things an integrator deliberately overrides, and those are stored on the remote with the recipe so a rebuild reproduces them instead of reverting:

• Renamed buttons and pages. A Button Label edited in the source table, a subsystem's page name, and any zone's button label are all kept. Remote buttons are small: MASTER BEDROOM CEILING FAN does not fit and Fan does, and that decision should not have to be made twice.
• Zones kept off this remote. Expand a checked subsystem to see its zones and uncheck the ones that don't belong on this remote — the linen closet light, the zone on the far side of the house. They stay in the UI and in GEM; they simply don't get a button here. Hidden zones also stop consuming the 32-slot zone-feedback pool. Scene subsystems (lighting, shades) show no zone list, because a scene resolves the UI's zones on the controller at press time and hiding one here would change nothing on the remote.
• Menu order. The order of the subsystem list is the order of the remote's menu — use the ↑ / ↓ buttons to put the page the room actually uses at the top.

A remote with nothing overridden stores nothing extra, and a program generated before this existed rebuilds exactly as it did. Hiding or renaming does not read as configuration drift: the status check compares against the same overrides the last run used.

Linked remotes appear in the Linked Remotes section of the page with live badges. A remote configured by one of the export rows above shows its name as a link — click it to open and scroll to that row, so a drift badge leads straight to the configuration that produced it.

• current — the remote reports the expected generation. stale — re-download — it reports an older one. connected — the driver announced itself but its program carries no generation stamp (hand-built programs never have one, and Integration Designer's compiler has been seen dropping it from a generated program); the program's vintage is unknown, so it is never flagged stale. awaiting hello — connected but hasn't announced itself (drivers older than 2.1 never do). offline.
• config changed — regenerate — the configuration has moved under the current program: the AV zone gained or lost a source, a mirrored subsystem gained or lost a zone, a lighting/shade scene was added, removed or renamed, or a mirrored Lutron keypad's buttons changed (hover for the detail). One click on Regenerate produces the updated file.
• driver x.y.z — template needs re-save — the remote's program embeds a driver older than the current release. Update the driver package in Integration Designer, re-save the template, re-upload it, and regenerate.

Generated File Details

• Driver connection settings (GEM Address, GEM Port) and the generation stamp are set on the GEM Automation driver.
• Source button labels are bound to the driver's source_label_N variables with the generated name as fallback — renaming a source in GEM renames the button live, no re-download.
• The template's first room is renamed to the AV zone's name.
• The job's client name is set, and a note records when and from which template the file was generated.
• The project's network key is regenerated on every export, so generated systems never share the template's key.
• The last ten generated files are kept in rti/generated on the controller.

Troubleshooting

Template not listed

Only files ending in .apex inside the controller's rti/templates folder are shown. Use Upload Template to add one from the browser and Delete to remove the selected one. GEM seeds its stock templates into the folder only while it is empty and only until the first in-app delete — deleting a template marks the folder as integrator-owned (a hidden .integrator_owned file), so an emptied folder stays empty instead of restoring the stock set. Remove that marker file to re-enable seeding.

"Template is not usable"

The template does not contain the GEM Automation driver, or the file is not an Integration Designer project. Re-save the template from Integration Designer with the driver installed.

A source was skipped

A source needs either a hand-drawn button tagged with its slot number or a GEM: Source 1 prototype for generation to clone. The page warns before generating when neither exists; the generation result also warns when a cloned button would land off-screen — in that case tighten the prototype spacing or draw the extra slots in the template.

"No subsystem pages generated"

Subsystems were checked but none of them produced a page: the mirrored UI has no zones in those subsystems, or the row has no UI to mirror at all. Pick the room's UI on the row and export again, or check the UI's zone list.

The lighting page shows scenes instead of the keypad

The mirrored UI names a Lutron control station, but the processor did not answer for it when you generated — the page falls back to scenes and the result warns how many keypads could not be read. Check that the lutron_qsx device is online and still paired, then generate again. A UI that names no station has no keypad to mirror and always gets scenes.

Buttons work but don't highlight

The highlight binds to the slot number. Confirm the source resolves to the same slot at runtime (GEM logs remote rti source slots: when a remote loads) and that the remote's AV zone matches the zone selected during generation.

Related Documentation

• Remotes - Remote configuration, key mappings, and status updates
• AV Zones - AV zone configuration
• AV Sources - Source configuration
• Lutron - Control stations mirrored onto generated lighting pages