When enabled, read and write supported configuration entities, send commands, and run macros over a token-authenticated HTTP interface.
Developer platform
Use what ships. Extend what doesn’t.
GEM provides documented APIs, programmable automation, custom web services, and an in-product driver environment for the work that falls outside a standard integration.
Documented interfaces
Connect GEM to the software around it.
Choose a conventional request-and-response API, a live subscription channel, or a narrow endpoint written for the project.
Use GEM’s Socket.io surface for live state, subscriptions, commands, attributes, and richer interactive operations.
Create purpose-built HTTP endpoints inside GEM for inbound webhooks, third-party integrations, and project-specific APIs.
REST and real-time operations use GEM’s role-based permission model. Custom inbound web services are part of the Web Services feature module and have their own configured authentication.
Custom driver authoring
Work against the real device.
Write a JavaScript driver in GEM, extend an existing transport or driver, and apply changes to a selected test device without moving the work into a separate toolchain.
The editor includes syntax checking, formatting, console output, breakpoints, step controls, watch expressions, variable inspection, and evaluation while paused.
StartChoose a base driver
BuildConnect · Command · Parse · Disconnect
VerifyReload · Debug · Test on equipment
Once proven, move the driver as a portable artifact to another GEM installation.
Creating custom drivers and using the script console require the Custom Driver Authoring feature module. Existing custom drivers continue to run if the license later changes.
Extension points
Put code at the right boundary.
Not every variation needs a new driver. GEM exposes smaller programming surfaces for automation logic, webhooks, and transport-specific equipment.
Macro scripts
Elevated administrators can add JavaScript to an automation step when standard actions and conditions do not cover the project.
Custom web services
Receive a webhook, shape a response, call an outside service, or expose a narrow endpoint for another system.
Generic transports
Start from TCP, HTTP, serial, infrared, or the device base instead of rebuilding connection handling from nothing.
Custom drivers
Translate a device protocol into GEM commands, attributes, feedback, and zones using the same operating model as built-in drivers.
Macro scripts, web services, and runtime custom drivers are trusted administrator code. Their VM contexts help shape the available runtime environment, but they can reach GEM’s server API and are not a boundary for running untrusted code.
Portable building blocks
Move known-good work forward.
Export supported configuration artifacts as reviewable JSON bundles, validate their references on the target installation, and resolve naming differences before import.
This is useful for staging, repeated room types, standard floor plans, and projects that share a tested integration pattern.
Import/export is not a backup. Secure attributes such as passwords and API keys are omitted, and bundles containing scripts or drivers should come only from a trusted source.
- Custom drivers
- Command sets
- Devices and zones
- Site spaces and modes
- Interfaces and widgets
- Macros
A public contract
Build against documented surfaces.
GEM treats its REST paths, real-time event names, driver methods, and script helpers as compatibility-sensitive interfaces. Additions can arrive without repurposing existing names; changes that would break stored work require a deprecation path.
The technical documentation covers authentication, permissions, payloads, scripting helpers, driver structure, and the current boundaries of each surface.
Bring the unusual requirement.
Show us the equipment, API, or workflow. We’ll help determine whether it fits a built-in driver, an open protocol, or a focused extension.