HE
Common abbreviation for Hubitat Elevation.
Often used in documentation and community discussion to distinguish Hubitat from Home Assistant, SmartThings and other platforms.
Reference
Hubitat ecosystem glossary.
Hubitat platform, device model, Rule Machine, Zigbee, Z-Wave, Matter/Thread, LAN and community terminology in one searchable page.
Reference
Search the glossary
Core Hubitat Platform
Hubitat Elevation is primarily a local automation platform. Current C-8/C-8 Pro hardware supports Zigbee 3.0, 800-series Z-Wave and Matter, while apps and drivers run within the hub's Groovy-based application environment.
Hubitat Elevation
The overall Hubitat home-automation platform, including the physical hub, embedded runtime, radios, web UI, built-in apps, drivers and cloud-assisted services.
Provides the execution environment within which devices, drivers and automation applications operate.
Hub
The physical Hubitat appliance running the Hubitat platform.
Acts as automation runtime, protocol controller and integration gateway.
C-8 Pro
Current high-performance Hubitat model with 2 GB RAM, 2.0 GHz processor, Zigbee 3.0, 800-series Z-Wave LR, Wi-Fi, Ethernet and Matter support.
Provides additional compute headroom for larger device estates, custom applications and complex automation.
C-8
Current-generation Hubitat model below the C-8 Pro, with 1 GB RAM and 1.4 GHz processor.
Functionally similar platform with less compute and memory capacity.
Platform Version
Version of the Hubitat operating/application platform installed on the hub.
Determines available platform APIs, built-in drivers, Rule Machine features and protocol functionality.
Firmware Update / Platform Update
Installation of a new Hubitat platform release.
Can alter drivers, radio behaviour, application APIs and automation functionality.
Local Processing
Execution of automation logic on the hub rather than relying on a remote cloud service.
Central to Hubitat's architecture. Internet loss does not necessarily stop locally executable automations.
Local Control
Control path where the hub communicates directly with a device or local service.
Usually lower latency and less dependent on external services than cloud integrations.
Cloud Integration
Integration where Hubitat communicates with an external vendor or Internet-hosted API.
Introduces Internet, authentication, API-rate and vendor availability dependencies.
Hub UI
Browser-based administrative interface hosted by the hub.
Primary interface for devices, apps, logs, settings, development and administration.
Location
Hubitat's logical representation of the installation associated with a hub.
Holds information such as mode, sunrise/sunset and HSM state and can generate location events.
Mode
Hub-wide logical state such as Day, Evening, Night or Away.
Provides a shared contextual variable that many automations can consume.
Mode Manager
Built-in application used to change modes based on schedules, presence or other conditions.
Separates environmental state management from individual automation logic.
Sunrise / Sunset
Calculated astronomical times associated with the hub's configured location.
Can be used as dynamic automation triggers or conditions.
Device
Hubitat object representing something that exposes controllable commands and/or measurable state.
May represent a physical device, cloud service, virtual object, group or abstraction.
App
Automation or integration logic running in the Hubitat application environment.
Consumes device events and issues commands.
Driver
Software adapter that represents a device to the Hubitat platform.
Translates between the native protocol/API of a device and Hubitat capabilities, attributes, commands and events.
Built-in App
Application supplied and maintained as part of the Hubitat platform.
Examples include Rule Machine, Room Lighting, Hubitat Safety Monitor and Maker API.
Built-in Driver
Device driver supplied by Hubitat.
Usually preferred where it supports the required device functionality.
Custom App
User or community-developed Hubitat application installed through Apps Code or a package mechanism.
Extends the platform beyond built-in functionality.
Custom Driver
User or community-developed device driver.
Common for unsupported hardware, LAN devices and specialist integrations.
Integration
Software arrangement connecting Hubitat to another system or technology.
May consist of an app, one or more drivers, network APIs and child devices.
Hubitat Mobile App
Hubitat's iOS/Android application providing remote access, device control, dashboards, presence and notifications.
Primarily complements the hub rather than replacing its local automation runtime.
Hubitat Device Object Model
Hubitat normalises devices into a capability-oriented model. Capabilities define expected attributes and commands so apps can interact with devices based on functionality rather than manufacturer-specific protocols.
Capability
Standard Hubitat interface describing functionality a device provides.
Switch, MotionSensor, ContactSensor, TemperatureMeasurement.
Attribute
Named piece of observable device state exposed by a capability or driver.
switch = on, motion = active, temperature = 23.4.
Command
Callable operation exposed by a driver.
on(), off(), setLevel(50), refresh().
Event
A state-change notification generated within Hubitat.
A motion detector changing from inactive to active generates a motion event.
Device Event
Event associated with a particular device attribute.
Apps subscribe to these events to initiate automation.
Location Event
Event associated with the hub/location rather than a device.
Mode changes and HSM changes are examples.
Current State
Hubitat's current stored value of a device attribute.
contact: closed.
State vs Event
State describes what is currently true; an event describes something that occurred.
A sensor may remain open for 30 minutes while only one initial open event occurred.
Command vs Event
A command requests an action; an event reports state.
switch.on() is a command. switch = on is an attribute event.
Capability Interface
Contract implied by a capability's attributes and commands.
An app requesting capability.motionSensor can work with many brands of motion sensor.
Custom Attribute
Attribute declared by a driver outside the standard capability model.
Useful for manufacturer-specific telemetry.
Custom Command
Driver command not defined by a standard capability.
Often invoked through Rule Machine's Run Custom Action.
Device ID
Hubitat database identifier for a device object.
Frequently used by internal APIs and Maker API.
Device Network ID - DNI
Identifier associating the Hubitat device object with its underlying network/device identity.
Format depends on the integration or protocol.
Device Name
Base descriptive name assigned to the device.
Often reflects the discovered device or original naming.
Device Label
User-friendly display name.
Normally the name users see throughout apps and dashboards.
Type
Driver currently assigned to the device.
Changing Type changes the software interpreting the device.
Preferences
User-configurable driver settings.
Reporting interval, sensitivity, transition duration, IP address, etc.
State Variables
Driver-maintained internal values shown on the device page.
Used by driver code and not equivalent to device attributes.
Data Values
Persistent metadata associated with a device.
Often includes model, manufacturer or protocol metadata.
Fingerprint
Device-identification information used to match a device with an appropriate driver.
Particularly important during Zigbee/Z-Wave pairing.
Generic Driver
General-purpose Hubitat driver implementing common device behaviour.
Useful when no device-specific driver is needed.
Virtual Device
Device object with no directly corresponding physical Hubitat-connected device.
Used as logical switches, presence devices, connectors and integration proxies.
Parent Device
Device representing a physical or logical parent that manages subordinate devices.
A multi-channel power strip may be represented as one parent plus several child switches.
Child Device
Device created and managed beneath another device or application.
Allows individual components or external resources to appear separately to Hubitat.
Component Device
Child device formally representing a component of a composite device.
Frequently used for multi-endpoint devices.
Composite Device
One physical device represented by multiple logical device objects.
Example: power board with independently controllable outlets.
Refresh
Command requesting the driver to obtain current state from a device where applicable.
Useful where state reporting is not automatically pushed.
Configure
Driver operation used to establish device configuration, subscriptions or reporting.
Often executed after pairing or driver changes.
Initialize
Driver lifecycle behaviour used to establish runtime connections or internal state.
Important for LAN/WebSocket drivers after hub restarts.
parse()
Driver method commonly used to process incoming protocol or network messages.
Turns raw Zigbee, Z-Wave or LAN traffic into meaningful state/events.
sendEvent()
Driver method used to generate/update Hubitat device events.
Example: converting an incoming LAN packet into motion = active.
Apps and Hubitat's Event-Driven Runtime
Hubitat apps normally remain dormant until activated by a subscription, scheduled job, HTTP endpoint or another relevant event.
App Instance
Installed/configured instance of an application.
One application implementation may have many separately configured instances.
Parent App
Application responsible for managing multiple related child applications or resources.
Common pattern for integrations and complex automation packages.
Child App
Application instance created beneath a parent application.
Rule Machine rules themselves are examples of child applications managed by Rule Machine.
Subscription
Registration telling Hubitat to invoke an application method when a particular event occurs.
Foundation of Hubitat's event-driven model.
Event Handler
App method executed in response to a subscribed event.
Example: motion event invokes motionHandler().
Scheduled Job
Execution scheduled for a later time by an app or driver.
Used for delays, periodic polling and future actions.
Polling
Periodically asking a device/service for its state.
Less event-efficient than push reporting but required by some integrations.
Push / Event-driven Integration
External service or device actively reports changes to Hubitat.
Generally reduces latency and unnecessary polling.
App State
Persistent application-specific data stored by Hubitat.
Used to retain values between executions.
state
Standard persistent data object available to applications and drivers.
Writes are persisted by the Hubitat runtime.
atomicState
Alternative persistent state mechanism intended for cases requiring immediately committed access semantics.
Should not automatically be used instead of state; concurrency behaviour is the reason for its existence.
installed()
Application lifecycle method invoked when an application instance is installed.
Usually performs initial setup.
updated()
Application lifecycle method invoked after configuration changes.
Frequently removes and rebuilds subscriptions and schedules.
initialize()
Common initialisation method called by app/driver lifecycle logic.
Used to recreate network connections or runtime state.
App Settings
Persisted values selected through the application UI.
Includes selected devices, options, variables and configuration values.
App Status Page
Diagnostic view exposing an app instance's settings, state, subscriptions and scheduled jobs.
Particularly useful when reverse-engineering or debugging automation dependencies.
Device Status Page
Diagnostic view of a device's state, events, commands, data and application usage.
Useful for determining how a device participates in the automation graph.
In Use By / Used By Apps
References showing applications that have selected or depend upon a device.
Important for impact analysis before removing or replacing a device.
Automation Applications
Basic Rule
Simplified built-in automation application.
Straightforward event-condition-action automations.
Simple Automation Rules
Built-in application for relatively simple trigger/action automations.
Useful where Rule Machine would be excessive.
Visual Rule Builder - VRB
Graphical automation builder for simple through moderately complex rules.
Useful where visual flow is preferable to Rule Machine's procedural representation.
Room Lighting
Built-in application designed specifically for lighting automation.
Often preferable to recreating sophisticated lighting behaviour in Rule Machine.
Button Controller
Built-in application mapping button events to actions.
Pico remotes, scene controllers and multi-button devices.
Groups and Scenes
Built-in application for aggregating devices and capturing/restoring predefined states.
Useful for logical groups and scene activation.
Group
Logical collection of devices controlled as one abstraction.
Example: all downstairs lights.
Scene
Captured set of device states that can later be restored.
Example: Movie Night.
Scene Activator
Virtual device representing activation of a scene.
Allows scenes to be consumed like devices by other apps.
Hubitat Safety Monitor - HSM
Built-in security/safety monitoring application.
Intrusion, smoke, water and other safety workflows.
HSM Status
Global HSM state such as armed or disarmed.
Exposed through location events and available to other automations.
Dashboard
User interface exposing device state and controls through tiles.
Operational control rather than automation logic.
Easy Dashboard
Newer simplified dashboard experience.
Faster dashboard creation with less configuration.
Rule Machine 5.1
Rule Machine is Hubitat's most powerful built-in general-purpose automation environment. Rule 5.1 uses an event-driven trigger model followed by a sequential action program.
Rule Machine - RM
Hubitat's advanced built-in automation application.
Suitable for complex logic, variables, branching, delays, reusable functions and integration actions.
Rule 5.1
Current Rule Machine rule architecture used by modern RM rules.
Older rules may continue functioning under previous rule versions.
Trigger Event
Event that causes a rule's actions to begin executing.
A trigger is an event, not merely a state being true.
Condition
Test of a current state or logical expression.
Door is open is a condition; Door changed to open is an event.
Required Expression
Expression that must be true for the rule's trigger processing to result in rule execution.
Provides a high-level gate before the rule's action logic.
Actions to Run
Ordered program executed when the rule runs.
Actions execute sequentially except where scheduling/wait behaviour changes flow.
Action
Individual executable instruction within a rule.
Turn device on, set variable, send message, call function, etc.
IF-THEN
Conditional branch based on an expression.
Procedural logic within Actions to Run.
ELSE-IF / ELSE
Alternative conditional branches.
Allows multi-path control flow.
END-IF
Terminates an IF structure.
Required to delimit nested conditional logic.
Simple Conditional Action
Condition applied only to the immediately following action.
Lighter-weight than a complete IF-THEN structure.
Delay
Schedules continuation/action execution after a duration.
A delay does not mean the hub's execution thread remains blocked.
Cancelable Delay
Delay that may subsequently be cancelled.
Useful where later events invalidate a pending action.
Cancel Delayed Actions
Cancels eligible outstanding delayed actions for that rule.
Prevents an obsolete scheduled action from firing.
Wait for Event
Suspends progression until a specified future event occurs.
Responds to the next qualifying event rather than continuously testing state.
Wait for Expression
Waits until a logical expression becomes true.
State-oriented counterpart to Wait for Event.
Repeat Actions
Repeatedly executes a block of actions according to defined logic.
Useful for notifications, retries or periodic actions.
Stop Repeating Actions
Terminates an active repeat construct.
Control-flow operation.
Exit Rule
Stops the current rule execution.
No subsequent actions from that execution are run.
Pause Rule
Prevents normal execution of another or current rule until resumed.
Different from cancelling only pending timers.
Resume Rule
Re-enables a paused rule.
Restores rule availability.
Run Rule Actions
Executes the Actions to Run section of another Rule Machine rule. It is not identical to generating that rule's trigger event.
Important when mapping Rule-to-Rule dependencies.
Rule Function
Special Rule Machine rule intended to be called from another Rule or Button Rule. It has no triggers or Required Expression, can receive an optional parameter and can return a String, Integer, Decimal or Boolean value.
Provides reusable functional logic rather than simply executing another rule's action list.
Function Parameter
Value passed into a Rule Function.
Accessible within the function through %param%.
Return Value
Value returned from a Rule Function to its caller.
Supports String, Integer, Decimal or Boolean.
Local Variable
Variable scoped to one Rule Machine rule.
Not directly shared globally.
Hub Variable
Hub-level typed variable available to multiple applications/rules.
Useful for shared state and cross-rule data.
Hub Variable Connector
Virtual device linked to a Hub Variable so applications expecting a device can interact with the variable.
Bridges variable state into the device/capability model.
Private Boolean
Boolean state belonging to a particular Rule Machine rule that can also be manipulated by other rules.
Historically used for inter-rule state and gating.
%value%
Rule Machine token containing context-dependent event/action data.
Exact meaning depends on what triggered or populated the rule context.
%device%
Token representing the device associated with the triggering event where applicable.
Useful in generic messages and rules with multiple trigger devices.
%param%
Parameter made available inside a Rule Function.
Specific to Rule Function invocation.
Local Endpoint
HTTP endpoint hosted by the hub that can trigger Rule Machine behaviour from the LAN.
Allows local external systems to initiate automation.
Cloud Endpoint
Hubitat cloud-accessible endpoint associated with a rule.
Enables an external Internet system to invoke the rule without direct LAN access.
Rule Machine API
Methods/endpoints allowing rules or their actions to be controlled programmatically.
Useful for external orchestration and custom applications.
Rule Logging
Diagnostic logging generated by Rule Machine.
Critical when analysing unexpected trigger, condition or action behaviour.
Zigbee
Zigbee devices communicate directly with Hubitat's Zigbee coordinator through a low-power IEEE 802.15.4 mesh. Hubitat supports Zigbee 3.0 and relevant earlier home-automation devices.
Zigbee
Low-power mesh networking protocol widely used for sensors, lights and switches.
One of Hubitat's primary native device networks.
Coordinator
Device that establishes and controls a Zigbee network.
The Hubitat hub performs this role.
Router
Mains-powered Zigbee device capable of forwarding traffic for other devices.
Extends mesh coverage and provides alternate routes.
End Device
Usually battery-powered Zigbee device that does not route other traffic.
Sleeps frequently to conserve battery.
Zigbee Mesh
Network formed by coordinator, routers and end devices.
Network resilience depends heavily on router placement and compatibility.
Zigbee Channel
RF channel used by the Zigbee network in the 2.4 GHz band.
Channel selection affects interference with Wi-Fi and other 2.4 GHz systems.
PAN
Personal Area Network.
Zigbee network controlled by the coordinator.
PAN ID
Identifier associated with the Zigbee network.
Distinguishes neighbouring Zigbee networks.
IEEE Address
Globally unique 64-bit hardware address of a Zigbee device.
Remains associated with the physical device even if network addressing changes.
Network Address
Short network-level address assigned to a Zigbee node.
May change and should not normally be treated as permanent identity.
Pairing / Join
Process by which a Zigbee device joins the Hubitat Zigbee network.
Hub must be in Zigbee discovery/join mode.
Rejoin
Existing Zigbee device reconnecting to its established network.
Normally does not require rebuilding automations.
Zigbee Endpoint
Logical function endpoint within a Zigbee device.
Multi-function devices may expose several endpoints.
Cluster
Standardised group of Zigbee functions.
Examples include On/Off, Level Control and temperature measurement clusters.
Cluster Attribute
Protocol-level data field inside a Zigbee cluster.
Driver often converts it into a Hubitat attribute/event.
Cluster Command
Protocol-level Zigbee command.
Driver translates Hubitat commands into appropriate Zigbee messages.
Reporting
Configuration causing a Zigbee device to automatically send attribute changes.
Preferable to frequent polling.
LQI
Link Quality Indicator.
One signal that may help diagnose link quality, but should not be treated as a complete mesh-health score.
RSSI
Received Signal Strength Indicator.
Measures RF signal strength at a particular reception point.
Repeater
Informal term generally referring to a Zigbee router used primarily to improve mesh coverage.
Proper Zigbee terminology is router.
Z-Wave
Hubitat acts as the central controller of its Z-Wave network. Current C-8/C-8 Pro hardware uses an 800-series Z-Wave implementation and supports Z-Wave Long Range.
Z-Wave
Sub-GHz wireless protocol designed for interoperable automation devices.
Native Hubitat device technology alongside Zigbee and Matter.
Z-Wave Controller
Device responsible for managing the Z-Wave network.
Hubitat is the central static controller.
Home ID
Identifier shared by nodes belonging to the same Z-Wave network.
Prevents devices from belonging to neighbouring Z-Wave networks accidentally.
Node ID
Network identifier assigned to a Z-Wave device.
Used throughout Z-Wave diagnostics and routing.
Inclusion
Process of adding a Z-Wave device to the network.
Equivalent to pairing.
Exclusion
Process of removing/resetting Z-Wave network membership.
Often required before previously paired devices can be included again.
SmartStart
Z-Wave provisioning mechanism using device information, commonly entered through QR/DSK data before installation.
Simplifies secure inclusion.
DSK
Device Specific Key used during secure Z-Wave commissioning.
Associated with S2 authentication.
S2 Security
Modern Z-Wave security framework.
Provides authenticated encrypted communication.
S0 Security
Older Z-Wave security scheme.
More network-overhead intensive than S2.
Security Grant
Security classes authorised during inclusion.
Determines how the device communicates after joining.
Z-Wave Mesh
Traditional routed Z-Wave network in which mains-powered nodes may relay traffic.
Route quality materially affects responsiveness.
Repeater (Z-Wave)
Z-Wave node that can relay network traffic.
Used to extend coverage and add routing alternatives.
Neighbour
Node that another Z-Wave device can communicate with directly.
Forms the basis of route selection.
Route
Path used for traffic between the hub and a Z-Wave node.
May be direct or traverse repeaters.
Z-Wave Repair
Process that updates neighbour/routing information where applicable.
Troubleshooting tool rather than something that should routinely be required.
Ghost Node
Community term for an incomplete or failed Z-Wave inclusion that leaves an unusable node entry.
Can interfere with routing or future inclusion and may require removal.
Failed Node
Node that the controller considers unreachable or non-functional.
May become eligible for forced removal.
Command Class
Standardised Z-Wave functional protocol definition.
Switch Binary, Sensor Multilevel and Configuration are examples.
Configuration Parameter
Manufacturer-defined device setting accessed through Z-Wave Configuration commands.
Controls device-specific behaviour.
Association
Mechanism allowing Z-Wave devices to communicate directly with other nodes for defined behaviours.
Can reduce reliance on controller-mediated actions in suitable use cases.
Lifeline Association
Primary association used for reporting important device status to the controller.
Normally points to Hubitat.
FLiRS
Frequently Listening Routing Slave. Battery device that wakes very frequently to receive commands.
Common in locks and certain battery-powered actuators.
Z-Wave Plus
Enhanced generation of Z-Wave certification/features.
Provides improved interoperability and network capabilities over older Z-Wave generations.
Z-Wave LR
Z-Wave Long Range mode using direct star-style communication rather than traditional mesh routing.
Designed for greater range and larger node counts. Current C-8/C-8 Pro hardware supports LR.
Matter and Thread
Hubitat is a Matter controller, meaning it can commission and operate Matter devices. Hubitat documentation explicitly distinguishes this from acting as a general Matter bridge that automatically exposes ordinary Hubitat devices as Matter devices.
Matter
IP-based smart-home interoperability standard.
Provides a common application layer across multiple network transports.
Matter Controller
Ecosystem controller that manages and operates Matter devices.
Hubitat performs this role.
Matter Bridge
Device/software that exposes non-Matter devices into a Matter fabric.
Hubitat's native Matter controller capability should not be confused with automatically bridging all Hubitat devices to Matter.
Commissioning
Process of securely adding a Matter device to a controller/fabric.
Similar in user intent to Zigbee pairing or Z-Wave inclusion.
Commissioner
Controller participating in the Matter commissioning process.
Hubitat can perform commissioning as a Matter controller.
Fabric
Secure logical Matter administrative domain containing controllers and devices.
A Matter device can participate in multiple fabrics.
Multi-Admin
Matter capability allowing a device to be shared across multiple controller ecosystems.
Allows, for example, the same Matter device to participate in Hubitat and another ecosystem.
Commissioning Code
Numeric/setup information used when adding a Matter device.
Usually represented by a QR code and/or numeric code.
Matter QR Code
Encoded commissioning information supplied with a Matter device.
Used during secure device onboarding.
Matter Endpoint
Logical functional endpoint within a Matter node.
A single physical Matter device may expose multiple endpoints.
Matter Cluster
Standardised Matter functional interface.
Conceptually similar to Zigbee clusters but implemented within the Matter data model.
Matter Attribute
State/data field contained within a Matter cluster.
Driver converts relevant Matter state into Hubitat attributes/events.
Matter Command
Operation defined by a Matter cluster.
Used by Hubitat's Matter driver layer when controlling devices.
Matter over Wi-Fi
Matter application protocol running over Wi-Fi/IP.
No Thread network is required.
Matter over Ethernet
Matter running over wired Ethernet/IP.
Common for bridges or mains-powered infrastructure devices.
Matter over Thread
Matter application protocol transported over a Thread network.
Requires access to an operational Thread network.
Thread
Low-power IPv6 mesh networking technology used by many Matter devices.
Thread supplies networking; Matter supplies the application interoperability layer.
Thread Border Router - TBR
Infrastructure connecting a Thread mesh to the normal IPv6 LAN.
Required for Matter-over-Thread communication where Hubitat is using an external Thread network.
Thread Mesh
Self-healing IPv6 low-power mesh used by Thread devices.
Separate from Zigbee even though both commonly operate in the 2.4 GHz band.
IPv6
Internet Protocol version used natively by Thread and Matter.
Matter is fundamentally IP-based, unlike traditional Zigbee or Z-Wave application networking.
LAN, IP and External Integration
Hubitat drivers can communicate using HTTP and several streaming/socket mechanisms, including WebSockets and Server-Sent Events/EventStream. Maker API provides a simpler REST-oriented integration boundary for external systems.
LAN Device
Device controlled through the local IP network rather than Zigbee/Z-Wave.
Examples include AV receivers, bridges and network appliances.
LAN Integration
App/driver communicating with devices or systems over the user's IP network.
Usually maintains Hubitat's local-control principle.
HTTP
Request/response web protocol.
Common transport for REST APIs and local device integrations.
HTTPS
HTTP protected by TLS encryption.
Common for cloud APIs and increasingly local APIs.
REST API
Resource-oriented HTTP API style.
Widely used for external Hubitat/device integrations.
Maker API
Built-in Hubitat application providing REST-style access to selected devices.
One of the simplest supported ways for an external platform to read Hubitat state and issue commands.
Maker API Device Selection
Explicit set of devices exposed through a Maker API instance.
Acts as an integration boundary rather than automatically exposing every device.
Access Token
Secret token authorising requests to an API/endpoint.
Should be treated like a credential.
OAuth
Authorisation mechanism used by Hubitat applications exposing secured endpoints.
Common foundation for cloud/local application endpoints.
Callback URL
External URL to which an application sends notifications or events.
Maker API can POST selected device events to an external system.
WebSocket
Persistent bidirectional IP connection.
Hubitat drivers can maintain WebSocket connections to external services.
Server-Sent Events - SSE
Long-lived HTTP connection through which a server streams events to a client.
Hubitat's EventStream interface supports this integration pattern.
EventStream Interface
Hubitat driver interface for maintaining an SSE/event-stream connection to an external endpoint.
Useful for low-latency event-driven LAN/cloud integrations.
TCP Socket
Persistent stream-oriented IP connection.
Used by some custom LAN drivers.
Raw Socket
Lower-level socket interface available to Hubitat drivers.
Useful for proprietary LAN protocols.
Telnet Interface
Driver interface for Telnet-based integrations.
Common with some legacy AV and automation equipment.
UDP
Connectionless IP transport.
Frequently used for discovery or lightweight LAN device messaging.
SSDP
Simple Service Discovery Protocol.
Common UPnP discovery mechanism used by various LAN devices.
mDNS
Multicast DNS service discovery.
Used by many modern LAN devices to advertise services.
Broadcast Discovery
Sending discovery traffic to multiple hosts/devices on the LAN.
Useful for integrations where devices do not have predetermined IP addresses.
Unicast
Network traffic directed to one destination.
Typical for normal device-to-hub communication after discovery.
Multicast
IP traffic delivered to members of a multicast group.
Used by protocols such as mDNS and Matter discovery.
Webhook
HTTP callback triggered by an event.
Generic pattern for connecting Hubitat with external automation systems.
Endpoint
Addressable HTTP/API function.
In Hubitat the word is overloaded: it may mean HTTP endpoint, Zigbee endpoint or Matter endpoint depending on context.
Multi-Hub Architecture
Hub Mesh allows multiple Hubitat hubs on the same LAN to share devices and, in current implementations, hub-variable information between hubs.
Hub Mesh
Native mechanism for sharing Hubitat devices between multiple hubs on the same LAN.
Enables workload, radio or geographic segmentation while retaining logical device access.
Mesh Device
Device shared from one Hubitat hub to another via Hub Mesh.
Appears on the consuming hub as a usable device representation.
Source Hub
Hub that owns the actual device or authoritative object.
Performs actual protocol communication.
Remote / Consuming Hub
Hub using a device shared from another hub.
Applications can treat the shared device much like a local device.
Hub Variable Sharing
Synchronisation of selected Hub Variables through Hub Mesh.
Allows state to be shared without constructing virtual-device workarounds.
Hub Link / Link to Hub
Older Hubitat multi-hub mechanism.
Hubitat documentation recommends Hub Mesh for modern installations.
Hub Segmentation
Architectural practice of distributing devices or automations across several hubs.
May isolate workloads, buildings, radio networks or critical functions.
Operations, Diagnostics and Troubleshooting
Logs
Real-time/recent application and device diagnostic output.
First point of investigation for most automation or driver failures.
Debug Logging
Verbose diagnostic logging typically enabled temporarily.
Useful during troubleshooting but unnecessary verbosity can increase log volume.
Info Logging
Normal operational information generated by an app or driver.
Shows significant activity without full debug detail.
Warning
Log entry indicating abnormal but potentially recoverable behaviour.
Often points to degraded operation.
Error
Log entry showing failed processing or an exception.
Requires investigation when persistent or functionally significant.
Scheduled Jobs
Future tasks currently registered by an app/driver.
Useful for identifying polling loops, delays and stale schedules.
Event History
Historical events generated by a device.
Helps distinguish device-reporting problems from automation problems.
Device Page
Hub UI page for viewing and controlling a specific device.
Essential for testing a driver independently of automation.
App Status
Diagnostic representation of an application instance.
Exposes settings, state, subscriptions and scheduled jobs.
Z-Wave Details
Hub UI exposing the hub's Z-Wave nodes and related status information.
Primary tool for diagnosing Z-Wave inclusion and routing issues.
Zigbee Details
Hub configuration/diagnostic information associated with the Zigbee network.
Used for radio/channel/network troubleshooting.
Matter Details
Hub configuration area associated with Matter configuration.
Used for Matter administration and troubleshooting.
Backup
Snapshot of hub configuration and application/device database.
Essential before significant changes.
Cloud Backup
Optional Hubitat service storing backups externally and supporting additional radio migration/restore capabilities.
Provides protection beyond an on-hub/local backup.
Restore
Replacing current hub configuration with a backup.
Used for recovery or migration.
Migration
Moving an existing Hubitat environment to another hub.
Can involve application database plus Zigbee/Z-Wave state depending on hub and backup method.
Soft Reset
Resets the hub's platform/database configuration without necessarily performing the same operation as a factory reset of every radio/device.
Common recovery procedure when restoring a known-good backup.
Reboot
Restarts the Hubitat operating environment.
Useful for applying updates or recovering transient platform/network conditions.
Shutdown
Controlled shutdown of the hub.
Preferable to abruptly removing power.
Diagnostic Tool
Low-level Hubitat maintenance/recovery interface.
Used when the main platform UI is unavailable or certain maintenance operations are required.
Hub Login Security
Optional authentication protecting access to the hub's administrative interface.
Can affect integrations that attempt to access protected internal/local interfaces.
Community and Extension Ecosystem
Hubitat Community
Official Hubitat-hosted user/developer discussion forum.
Major source of custom integrations, technical knowledge and support.
Community Driver
Non-Hubitat driver written by a third-party developer.
Not part of the core Hubitat platform.
Community App
Third-party Hubitat application.
Can substantially extend platform capability.
HPM
Hubitat Package Manager, a community-developed package-management application.
De-facto package manager for many community apps and drivers.
HPM Package
Installable package containing one or more Hubitat applications/drivers.
Can support dependencies, updates and optional components.
HPM Manifest
JSON metadata describing an installable package and its constituent files.
Allows HPM to install and update packages.
HPM Repository
Catalogue containing references to HPM packages.
Enables package discovery.
Match Up
HPM operation attempting to associate manually installed apps/drivers with managed packages.
Allows existing installations to become package-managed.
Bundle
Packaged collection of Hubitat code/resources that can be imported together.
Useful for larger integrations comprising multiple components.
Apps Code
Hub UI area where custom application source code is installed/edited.
Developer and manual-installation facility.
Drivers Code
Hub UI area where custom driver source code is installed/edited.
Equivalent facility for device drivers.
Groovy
Programming language used for Hubitat custom applications and drivers.
Hubitat exposes its own APIs and execution environment around Groovy.
Namespace
Identifier used with custom application/driver metadata to distinguish code ownership/source.
Helps avoid naming collisions.
GitHub Integration Pattern
Common practice of hosting Hubitat app/driver source code and HPM manifests in GitHub repositories.
Not itself a Hubitat platform dependency, but prevalent in the developer ecosystem.
Easily Confused Terms
Pairs of terms that sound similar but mean different things.
App vs Driver
An app implements automation/integration logic. A driver represents a device and exposes its capabilities, commands and attributes.
Device vs Physical Device
A Hubitat device is a software object. It may represent physical hardware, a cloud resource, virtual state, a group or another abstraction.
Capability vs Driver
A capability is an interface contract. A driver implements one or more capabilities.
Attribute vs State Variable
An attribute is externally visible device state consumed by apps. A state variable is internal driver/application storage.
Command vs Attribute
A command asks a device to do something. An attribute says what state the device reports.
Event vs State
An event is something that happened. State is what is currently true.
Trigger vs Condition
A trigger is an event that starts execution. A condition evaluates state.
Delay vs Wait
A delay schedules execution after time. A wait resumes when a particular event/expression occurs.
Run Rule Actions vs Trigger Rule
Run Rule Actions directly executes another rule's action section. It does not reproduce the complete semantics of the target rule receiving its normal trigger.
Run Rule Actions vs Rule Function
Run Rule Actions provides procedural reuse. A Rule Function provides callable logic with an optional input parameter and explicit return value.
Local Variable vs Hub Variable
Local variable belongs to one rule. Hub Variable is available more broadly across the hub.
Hub Variable vs Connector
The Hub Variable stores the value. The connector exposes that value through a virtual-device interface.
Virtual Device vs Child Device
Virtual describes the absence of a direct physical device. Child describes ownership/hierarchy. A child device can itself represent a physical or virtual function.
Zigbee Mesh vs Hub Mesh
Zigbee Mesh is an RF networking topology. Hub Mesh is a Hubitat application/platform mechanism for sharing devices between hubs.
Z-Wave Mesh vs Z-Wave LR
Traditional Z-Wave uses routed mesh paths. Z-Wave LR primarily uses long-range direct communication.
Matter vs Thread
Matter defines the application/interoperability layer. Thread is one possible IP network transport underneath Matter.
Matter vs Zigbee
Zigbee defines its own network and application models. Matter operates using IP over transports such as Ethernet, Wi-Fi and Thread.
Matter Controller vs Matter Bridge
A controller administers/controls Matter devices. A bridge exposes non-Matter resources into Matter. Hubitat's native role is a Matter controller.
Thread Border Router vs Matter Controller
A TBR connects Thread to the IP LAN. A Matter controller commissions and controls Matter devices. They are separate architectural roles.
Maker API vs Custom Driver
Maker API exposes existing Hubitat devices externally. A custom driver brings a new device/service into Hubitat's device model.
REST vs WebSocket
REST is predominantly request/response. WebSocket maintains a persistent bidirectional connection.
Polling vs Subscription
Polling repeatedly asks for state. Subscription/event-based integration reacts when state changes.
Device ID vs DNI
Device ID identifies the Hubitat database object. DNI links that object to its network/integration identity.
Name vs Label
Name is the underlying device name. Label is generally the user-facing friendly name.
Hub Backup vs Device Network Backup
Hub database backup and radio/network-state backup are related but conceptually separate concerns. Capabilities depend on hub generation and backup mechanism.
No terms match that search.