Overview
GEM is a single-controller automation platform. One GEM server runs on a machine at the site and talks to every piece of equipment — AV receivers, lighting and shade controllers, thermostats, locks, cameras, access control panels — through a library of device drivers. Clients (web, mobile, and wall-mounted touchpanels) connect to that server to view and control the system in real time.
How the pieces fit together
- Server — a Node.js process (
server.js) that owns all device connections, automation, and state. Everything else is a client of it. - Drivers — one per equipment type. A driver knows how to connect to a device and translate GEM commands (
on,off,open,set_level) into the device's native protocol. - Database — PostgreSQL stores configuration: devices, zones, subsystems, users, macros, schedules, and attributes. Live runtime values are held in memory and merged onto these records.
- Clients — the web app, the mobile app, and touchpanel UIs all speak to the server over REST and a real-time WebSocket connection.
Core concepts you'll meet
| Term | What it is |
|---|---|
| Subsystem | A category of equipment — lighting, shades, climate, security, AV. |
| Zone | A controllable endpoint within a subsystem — "Kitchen Lights", "Living Room Shades". |
| Device | A physical or virtual controller, driven by a driver, that one or more zones live on. |
| Attribute | A named value on any entity (brightness, temperature, online status). Configuration and live state are both attributes. |
| Macro | A saved sequence of steps — the building block of automation and scenes. |
| Trigger | A rule that runs a macro when an attribute changes or a condition is met. |
For a deeper treatment, see Concepts. To get a system running, continue to Requirements.