Skip to main content

Triggers

Triggers (also called Attribute Triggers) are event-driven automations that execute actions when attribute values change and meet specified conditions. Unlike schedules (time-based) or macros (manually executed), triggers respond immediately to system events.

Each attribute change is filtered through the trigger's condition, active days/hours, and debounce before the macro runs:

Overview​

Triggers enable reactive automation:

  • Attribute Monitoring: Watch any attribute for changes
  • Conditional Execution: Only act when conditions are met
  • Immediate Response: Execute within seconds of event
  • Scheduled Availability: Limit trigger to specific days/hours
  • Debouncing: Prevent rapid repeated executions

Viewing Triggers​

The main grid displays all configured triggers with the following columns:

  • ID - Unique trigger identifier
  • Name - Internal trigger name
  • Active Days - Day enable mask (read-only in grid)
  • Active Hours - Hour enable mask (read-only in grid)
  • Debounce (min) - Minimum minutes between activations
  • Actions - Configured actions summary (read-only in grid)
  • Last Triggered - Last time trigger executed (read-only in grid)
  • Enabled - Whether trigger is active

Grid Actions​

  • Add - Create a new trigger
  • Edit - Modify an existing trigger
  • Delete - Remove a trigger
  • Reload - Refresh the grid data

Creating a Trigger​

To create a new trigger:

  1. Click Add in the grid toolbar
  2. The trigger creator opens with these main sections:
    • Basic Settings
    • Trigger Condition
    • Additional Condition (optional gate)
    • Action to Execute
    • Schedule Configuration
  3. Configure all sections (see below)
  4. Click Create Trigger

Trigger Configuration​

Basic Settings​

Trigger Name

  • Internal identifier (lowercase_with_underscores)
  • Examples: motion_lights, door_alert, temp_warning
  • Auto-formatted on blur

Debounce (minutes)

  • Minimum time between trigger activations
  • Prevents rapid repeated execution
  • Example: Motion sensor triggering every second
    • Set debounce: 5 minutes
    • Trigger executes max once per 5 minutes
  • Default: 0 (no debouncing)

Status

  • Toggle to enable/disable trigger
  • Disabled triggers:
    • Don't monitor attributes
    • Don't execute actions
    • Configuration preserved

Trigger Condition​

Define what attribute change triggers the action:

Condition Builder provides:

Attribute Selection:

  • System Target: device, macro, monitor, site, site_space, subsystem, system, variable, zone
  • Target Object: Specific entity (shown as [ID] name for easy identification). For variable and system targets the object is fixed and the row jumps straight to attribute selection.
  • Attribute Name: Which attribute to monitor

Comparison:

  • Equals (=)
  • Not Equals (!=)
  • Greater Than (>)
  • Less Than (<)
  • Greater Than or Equal (>=)
  • Less Than or Equal (<=)
  • Contains (for strings)
  • Does Not Contain (for strings)
  • Is Empty / Is Not Empty
  • Matches (regex pattern)
  • Does Not Match (regex pattern)

Value:

  • Value to compare against
  • Input type adapts to the selected attribute:
    • bool attributes show a true/false dropdown
    • int attributes show a numeric input (whole numbers)
    • float attributes show a numeric input (decimals allowed)
    • Attributes with value options show a dropdown of allowed values (with fill-in)
    • All other types show a text input
  • Can reference dynamic expressions (e.g., [$sunrise], [zone.5.level]+10). See Attributes — Dynamic Attribute Values.

Logic:

  • AND: All conditions must be true
  • OR: Any condition can be true

Example Conditions:

Motion Detected:

System Target: zone
Target ID: front_porch_motion
Attribute: motion
Comparison: equals
Value: detected

Temperature Too High:

System Target: zone
Target ID: living_room_thermostat
Attribute: temperature
Comparison: greater than
Value: 78

Door Opened:

System Target: zone
Target ID: front_door
Attribute: contact
Comparison: equals
Value: open

Multiple Conditions (AND):

Condition 1: motion = detected
AND
Condition 2: light_level < 30

Multiple Conditions (OR):

Condition 1: front_door = open
OR
Condition 2: back_door = open

Additional Condition (Gate)​

An optional secondary check evaluated after the trigger condition matches but before actions run. Use it to gate execution on the live value of any other attribute without complicating the primary trigger condition.

How it differs from a Trigger Condition:

  • The trigger condition is what the system watches for change. When that attribute changes and matches, the trigger is "armed".
  • The gate condition is read on-demand at fire time against the current value of any attribute (does not need to be the one that changed).
  • If the gate fails, the fire is logged as skipped with reason gate condition in Run History and no action runs.

Configuration:

Uses the same condition builder as the trigger condition, with one extra Reference dropdown that selects which entity to evaluate against:

ReferenceDescription
Specific target (default)Pick a fixed system_target + target — the gate reads that one attribute every time the trigger fires.
Same target that firedEvaluates against whichever entity matched the primary condition. Useful with dynamic-name-pattern primary conditions (e.g. any zone ending in _door opens AND that same door has notify_enabled=true).
Parent subsystem of fired zoneWhen the primary condition fires on a zone, the gate reads from the zone's subsystem. Useful for subsystem-level enable flags.

Leave blank for no gate.

Example — only run during night mode (specific target):

Trigger Condition:    zone.front_porch_motion.motion = detected
Additional Condition: variable.0.home_mode = night
Action:               command (porch_light on)

Example — only alert on doors that opt in (same-target gate, fan-out trigger):

Trigger Condition:    zone.*_door.contact = open  (dynamic name pattern)
Additional Condition: Reference: Same target that fired
                      Attribute: notify_enabled
                      Value: true
Action:               webpush_notification

The trigger fires on every door, but only fires for doors whose own notify_enabled attribute is true.

tip

Use a gate condition instead of adding a second trigger condition when the second value rarely changes (e.g. site mode, home/away, schedule flag). Trigger conditions react to changes on every listed attribute — gate conditions are read only when the trigger fires.

Action to Execute​

Define what happens when trigger fires:

Action Type Selection:

Command:

  • Send command to device or zone
  • Configure: Device, Zone, Command, Parameters
  • Example: Turn on porch light to 75%

Macro:

  • Execute a macro
  • Configure: Macro selection, Arguments
  • Example: Run "security_alert" macro

Email:

  • Send email notification
  • Configure: Recipients, Subject, Message
  • Example: Email "Front door opened" to homeowner

SMS:

  • Send SMS text message
  • Configure: Phone number, Message
  • Example: Text "Motion detected" to security phone

Web Request:

  • Send HTTP request to external service
  • Configure: URL, Method, Headers, Body
  • Example: POST to webhook API

Set Attribute:

  • Modify another attribute value
  • Configure: System target, Target ID, Attribute, Value
  • Example: Set variable "last_motion" to current timestamp

WebPush Notification:

  • Send browser push notification
  • Configure: UI, Title, Message, Priority
  • Example: Push "Door opened" to mobile app

Schedule Configuration​

Limit when trigger can execute:

Active Days​

Select which days trigger is active:

Interface:

  • Visual grid of 7 days: SUN, MON, TUE, WED, THU, FRI, SAT
  • Click day to toggle
  • Select All / Clear All buttons

Use Cases:

  • Weekdays Only: Work-related automation
  • Weekends Only: Leisure automation
  • All Days: Always-active triggers

Examples:

Motion lights (all days): Sun-Sat all checked
Office hours (weekdays): Mon-Fri checked
Weekend guest access: Sat-Sun checked

Active Hours​

Two modes are available for controlling when a trigger is active during the day: Hour Mask and Time Range. Switch between them using the tabs above the hours section.

Hour Mask​

Select specific hours the trigger is active:

Interface:

  • Visual grid of 24 hours: 12AM, 1AM, 2AM, ... 11PM
  • Click hour to toggle
  • Select All / Clear All buttons

Use Cases:

  • Night Only: Security alerts, motion lights
  • Daytime Only: Occupancy-based climate
  • Business Hours: Office automation
  • Off Hours: Maintenance windows

Examples:

Night motion lights: 8PM-6AM checked (20-5)
Daytime climate: 6AM-10PM checked (6-21)
Business hours: 8AM-6PM checked (8-17)
Time Range​

Define a start and end time for the active window. This is especially useful when active hours should follow dynamic values like sunrise or sunset rather than fixed hourly blocks.

Interface:

  • Start Time and End Time fields
  • Each can be set to Variable or Static Time mode

Variable Mode:

  • Select a date-type variable (e.g., sunrise, sunset) from the dropdown
  • Optionally add an offset in minutes (positive = after, negative = before)
  • Example: Variable sunset with offset -30 → active starts 30 minutes before sunset

Static Mode:

  • Enter a fixed time (e.g., 08:00, 17:00)

Overnight Ranges: Time ranges that cross midnight are supported. If the start time is later than the end time, the range wraps overnight.

  • Example: Start 22:00, End 06:00 → active from 10 PM to 6 AM

Examples:

Sunset to sunrise:  Start: [$sunset]  End: [$sunrise]
Dusk with offset:   Start: [$sunset]-30  End: [$sunrise]+30
Fixed range:        Start: 08:00  End: 17:00
tip

Time Range mode is ideal for triggers that should follow astronomical events. Use the sunrise and sunset system variables with minute offsets instead of manually adjusting the hour mask seasonally.

Common Trigger Examples​

Motion-Activated Lights​

Name: porch_motion_lights
Debounce: 5 minutes

Conditions:
  zone.front_porch_motion.motion = detected
  AND
  zone.front_porch_light.power = off
  AND
  variable.0.light_level < 30

Action: command
  Zone: front_porch_light
  Command: on
  Level: 100%

Days: All days
Hours: Sunset to Sunrise (approximate: 18-6)
Enabled: Yes

Result: When motion detected at night and light is off and it's dark, turn on porch light. Won't re-trigger for 5 minutes.

Door Open Alert​

Name: front_door_alert
Debounce: 0 (alert every time)

Conditions:
  zone.front_door.contact = open
  AND
  variable.0.home_mode = away

Action: webpush_notification
  Message: "Front door opened while away!"
  Priority: critical

Days: All days
Hours: All hours
Enabled: Yes

Result: When away and front door opens, send immediate push notification.

Temperature Control​

Name: ac_auto_on
Debounce: 30 minutes

Conditions:
  zone.living_room_thermostat.temperature > 76
  AND
  zone.living_room_thermostat.mode != cool

Action: command
  Zone: living_room_thermostat
  Command: set_mode
  Mode: cool
  Setpoint: 72

Days: All days
Hours: 9AM-11PM (9-22, not overnight)
Enabled: Yes

Result: If temperature exceeds 76°F and AC not in cool mode, switch to cooling (max once per 30 min, daytime only).

Low Battery Alert​

Name: sensor_low_battery
Debounce: 1440 (once per day)

Conditions:
  device.motion_sensor_1.battery_level < 20

Action: email
  To: installer@example.com
  Subject: "Low Battery Alert"
  Body: "Motion sensor battery at {device.battery_level}%"

Days: All days
Hours: 9AM only (single notification time)
Enabled: Yes

Result: Daily email at 9 AM if motion sensor battery below 20%.

Device Offline Notification​

Name: thermostat_offline
Debounce: 15 minutes

Conditions:
  device.main_thermostat.connection_state = disconnected

Action: sms
  Number: +15551234567
  Message: "HVAC thermostat offline!"

Days: All days
Hours: All hours
Enabled: Yes

Result: SMS notification if thermostat disconnects (max once per 15 minutes).

Trigger vs. Schedule vs. Macro​

When to Use Triggers​

Best For:

  • Event-driven automation (motion, door, sensor)
  • State-based responses (temperature thresholds)
  • Alert notifications (errors, status changes)
  • Reactive behavior (respond to changes)

Examples:

  • Motion detected → Turn on lights
  • Door opened → Send alert
  • Temperature too high → Activate cooling

When to Use Schedules​

Best For:

  • Time-based automation (daily routines)
  • Predictable recurring events
  • Astronomical timing (sunrise/sunset)

Examples:

  • 7:00 AM → Good morning macro
  • Sunset → Turn on outdoor lights
  • 10:30 PM → Goodnight macro

When to Use Macros (Manual)​

Best For:

  • User-initiated actions
  • On-demand sequences
  • UI buttons
  • Complex multi-step operations

Examples:

  • "Movie Time" button → Movie macro
  • "All Off" button → All off macro
  • Access control → Unlock sequence

Combining All Three​

Example: Comprehensive Porch Light Automation

Trigger: Motion detected + dark + nighttime → Turn on light

Schedule: Sunset → Turn on light (base level)

Macro: "Party Mode" → Override automation, force lights on

All three work together for complete automation.

Debouncing​

Purpose of Debouncing​

Prevents trigger spam from rapidly-changing attributes:

Without Debounce:

Motion sensor triggers every 1 second
↓
Lights commanded on every 1 second
↓
100s of redundant commands per day

With Debounce (5 minutes):

Motion detected at 8:00:00 PM → Lights on
Motion detected at 8:00:15 PM → Ignored (within 5 min)
Motion detected at 8:03:30 PM → Ignored (within 5 min)
Motion detected at 8:05:01 PM → Lights on (>5 min elapsed)

Debounce Guidelines​

No Debounce (0 minutes):

  • Critical alerts that should always fire
  • Infrequent events
  • Single-occurrence events

Short Debounce (1-5 minutes):

  • Motion sensors
  • Door sensors
  • Frequent but important events

Medium Debounce (10-30 minutes):

  • Temperature thresholds
  • Light level changes
  • Moderate frequency events

Long Debounce (60-1440 minutes):

  • Low battery alerts (daily max)
  • Status reports
  • Infrequent notifications

Day/Hour Masks​

Purpose​

Restrict trigger execution to specific times:

Benefits:

  • Security lights only at night
  • Office automation only during business hours
  • Weekend-specific automation
  • Seasonal behavior changes

Day Mask​

7-bit binary mask: 1111111 (all days enabled)

Format: SMTWTFS (Sun, Mon, Tue, Wed, Thu, Fri, Sat)

Examples:

1111111  → All days
0111110  → Weekdays only (Mon-Fri)
1000001  → Weekends only (Sat-Sun)
0010000  → Wednesdays only

Hour Mask​

24-bit binary mask: 111111111111111111111111 (all hours enabled)

Format: Hours 0-23 (midnight to 11 PM)

Examples:

000000111111111111110000  → 6 AM to 9 PM
111111000000000000111111  → Night hours (10 PM to 5 AM)
000000000111111111000000  → Business hours (9 AM to 5 PM)

Time Range (JSON)​

When using Time Range mode, the hour mask is stored as a JSON object with start and end fields:

{"start": "[$sunset]-30", "end": "[$sunrise]+30"}
{"start": "08:00", "end": "17:00"}

Values can be:

  • Static time: HH:MM format (e.g., 08:00)
  • Variable reference: [$variable_name] with optional +N or -N minute offset

Combined Masks​

Example: "Office Hours Only"

Days: Mon-Fri (0111110)
Hours: 8 AM-6 PM

Result: Trigger only active weekdays 8 AM-6 PM.

Action Types​

Triggers can execute various action types:

Command Action​

Send command to device or zone:

Configuration:

  • Device or Zone
  • Command name
  • Command parameters
  • Delay before execution (optional)

Example:

Action: command
Target: Zone - living_room_lights
Command: set_level
Parameters: {level: 75, ramp: 2}

Macro Action​

Execute a macro:

Configuration:

  • Macro selection
  • Macro arguments (optional)

Example:

Action: macro
Macro: security_alert
Arguments: {location: "front_door", type: "open"}

Email Action​

Send email notification:

Configuration:

  • To: Email addresses (comma-separated)
  • CC: CC addresses (optional)
  • Subject: Email subject
  • Body: Email message (supports variables)

Example:

Action: email
To: homeowner@example.com, security@example.com
Subject: Front Door Alert
Body: Front door opened at {timestamp} by {user}

SMS Action​

Send SMS text message:

Configuration:

  • Phone number(s) — multiple numbers can be separated by commas or semicolons
  • Message text (160 characters max recommended)

Each recipient is checked individually against Notification Profiles. If a recipient is blocked by a profile, the message is skipped for that recipient but still sent to others.

Example:

Action: sms
Number: +15551234567, +15559876543
Message: Motion detected at front door

Web Request Action​

Send HTTP request to external service:

Configuration:

  • URL: Endpoint URL
  • Method: GET, POST, PUT, DELETE
  • Headers: HTTP headers (JSON)
  • Body: Request body (JSON)

Example:

Action: web_request
URL: https://api.service.com/alert
Method: POST
Headers: {"Content-Type": "application/json", "X-API-Key": "secret"}
Body: {"event": "motion", "location": "front_door", "timestamp": "{timestamp}"}

Set Attribute Action​

Modify another attribute:

Configuration:

  • System Target: zone, device, variable, etc.
  • Target ID: Specific entity
  • Attribute Name: Attribute to set
  • Value: New value
  • Type: Value type (string, int, float, bool)

Example:

Action: set_attribute
System Target: variable
Target ID: 0
Attribute: last_motion_time
Value: {timestamp}
Type: date

WebPush Notification Action​

Send browser push notification:

Configuration:

  • UI: Which UI to notify (or all)
  • Title: Notification title
  • Message: Notification body
  • Priority: info, warning, error, critical
  • Icon: Notification icon (optional)

Example:

Action: webpush_notification
UI: all
Title: Security Alert
Message: Motion detected at front door
Priority: warning
Icon: security

Call Notification Action​

Send a native incoming call notification to mobile devices. Triggers the full-screen incoming call UI (CallKit on iOS, full-screen notification on Android). Only delivered to native mobile app clients — web browsers are skipped.

Configuration:

  • Caller Name: Name displayed on the incoming call screen
  • Answer URL: Page to navigate to when the user answers (e.g., /controls/gates)
  • Target UIs: Which UIs to notify
  • Target Users: Which users to notify
  • Override Notification Profile: Send regardless of user notification preferences

Example:

Action: call_notification
Caller Name: Front Gate
Answer URL: /controls/gates
UI: all
Override Profile: Yes
tip

Call notifications require the GEM mobile app. Configure push notification tokens via the Mobile App admin page.

Condition Builder​

The condition builder creates complex attribute queries:

Simple Condition​

Single Attribute Check:

zone.front_door.contact = open

Configuration:

  • System Target: zone
  • Target ID: front_door (select from dropdown)
  • Attribute: contact
  • Operator: equals
  • Value: open

Dynamic Name Matching​

Instead of selecting a specific target, you can match targets by name pattern using wildcards. This is useful when you want a single trigger condition to apply to any entity whose name matches a pattern.

  1. Select a System Target (zone, device, macro, monitor, or site_space)
  2. Check the dynamic name checkbox below the Target dropdown
  3. Enter a name pattern using * as a wildcard

Pattern examples:

  • *_climate — matches any target ending in _climate
  • living_* — matches any target starting with living_
  • *_motion_* — matches any target containing _motion_

The Target dropdown still selects a specific entity to load its available attributes for configuration, but at runtime the condition evaluates against all entities matching the name pattern.

tip

Dynamic name matching is ideal for conditions that should apply broadly — for example, triggering on any zone whose name ends with _climate rather than creating separate conditions for each climate zone.

Compound Conditions​

AND Logic (all must be true):

zone.motion_sensor.motion = detected
AND
variable.0.home_mode = away
AND
zone.front_door.contact = closed

OR Logic (any can be true):

zone.smoke_detector_1.alarm = triggered
OR
zone.smoke_detector_2.alarm = triggered
OR
zone.smoke_detector_3.alarm = triggered

Nested Conditions​

Complex Logic:

(zone.motion = detected AND zone.light = off)
OR
(zone.door = open AND time > sunset)

Current Limitation: Basic AND/OR supported. Complex nesting may require multiple triggers or macro logic.

Comparison Operators​

Equals (=):

  • Exact match
  • Case-sensitive for strings
  • Example: power = on

Not Equals (!=):

  • Does not match
  • Example: mode != vacation

Greater Than (>):

  • Numeric comparison
  • Example: temperature > 75

Less Than (<):

  • Numeric comparison
  • Example: battery_level < 20

Greater Than or Equal (>=):

  • Inclusive upper threshold
  • Example: humidity >= 60

Less Than or Equal (<=):

  • Inclusive lower threshold
  • Example: volume <= 10

Contains:

  • Substring match
  • Example: error_message contains "timeout"

Matches (regex):

  • JavaScript regular expression match against the source value as a string
  • Example: device_name matches "sensor_.*"
  • The value is the raw pattern, no / delimiters (e.g. ^\d+$ for "is a number")
  • A preset dropdown beside the value field offers common patterns (valid number, non-blank, valid email, valid IPv4, etc.)

Does Not Match (regex):

  • Inverse of Matches — true when the pattern does not match
  • Example: gate on device_name does_not_match "^test_" to skip test devices

Common Trigger Patterns​

Security Triggers​

Intrusion Alert:

Conditions: zone.motion.motion = detected AND variable.home_mode = away
Action: webpush_notification + email + macro (alarm)
Days: All days
Hours: All hours
Debounce: 1 minute

Door Left Open:

Conditions: zone.front_door.contact = open for 5 minutes
Action: webpush_notification "Door left open!"
Days: All days
Hours: All hours
Debounce: 5 minutes

Comfort Triggers​

Auto Climate:

Conditions: zone.thermostat.temperature > 78
Action: command (set_mode: cool, setpoint: 74)
Days: All days
Hours: 8AM-10PM
Debounce: 30 minutes

Morning Light:

Conditions: zone.bedroom_motion.motion = detected
Action: command (bedroom_lights, set_level, 30%)
Days: All days
Hours: 5AM-8AM only
Debounce: 60 minutes (once per morning)

Energy Triggers​

Peak Demand Reduction:

Conditions: variable.energy_price > 0.30
Action: macro (reduce_non_essential_loads)
Days: Weekdays
Hours: 2PM-7PM (peak hours)
Debounce: 60 minutes

Solar Optimization:

Conditions: variable.solar_production > 5000 AND variable.battery_charge < 80
Action: macro (charge_batteries)
Days: All days
Hours: 10AM-4PM (peak solar)
Debounce: 30 minutes

Notification Triggers​

Device Offline:

Conditions: device.critical_device.connection_state = disconnected
Action: email + sms (device offline alert)
Days: All days
Hours: All hours
Debounce: 15 minutes

Low Supply Alert:

Conditions: variable.water_level < 20
Action: email (low water alert)
Days: All days
Hours: 9AM-5PM (business hours for service call)
Debounce: 1440 minutes (daily)

Advanced Topics​

Trigger Chaining​

Triggers can trigger other triggers:

Example:

Trigger 1: Motion detected → Set variable "occupancy" = yes
Trigger 2: Variable "occupancy" = yes → Turn on welcome lights
Trigger 3: Variable "occupancy" = no for 30 minutes → Turn off lights

State Machines​

Implement complex state management:

States: home, away, vacation, sleep, party

Triggers:

Trigger 1: All users leave → Set mode = away
Trigger 2: Mode changes to away → Execute "leaving home" macro
Trigger 3: User arrives → Set mode = home
Trigger 4: Mode changes to home → Execute "arriving home" macro

Computed Attributes​

Use triggers to calculate derived values:

Example:

Trigger: Any zone's power changes
Action: Set attribute "total_lights_on" = count of zones with power=on

Cascading Actions​

One trigger's action creates conditions for another:

Example: Escalating Alerts

Trigger 1: Temperature > 100 → Set variable "overheat_warning" = yes
Trigger 2: Variable "overheat_warning" = yes for 5 min → Send email
Trigger 3: Variable "overheat_warning" = yes for 10 min → Send SMS + shut down

Best Practices​

  1. Specific Conditions: Make conditions as specific as possible to avoid false triggers

  2. Appropriate Debounce: Set debounce to prevent spam while remaining responsive

  3. Schedule Limits: Use day/hour masks to prevent unwanted execution

  4. Testing: Test triggers thoroughly, especially complex conditions

  5. Logging: Monitor trigger execution in logs

  6. Naming: Use descriptive names indicating what triggers and what happens

  7. Error Handling: Consider what happens if action fails

  8. Avoid Loops: Don't create trigger loops (A triggers B triggers A...)

  9. Documentation: Document complex trigger logic in description/comments

  10. Review Regularly: Audit triggers quarterly to remove unused ones

Troubleshooting​

Trigger Not Firing​

Check:

  1. Enabled: Trigger is enabled
  2. Conditions: Conditions are actually being met
  3. Day/Hour: Current day and hour are enabled
  4. Debounce: Not within debounce period
  5. Attribute Changes: Attribute is actually changing
  6. Logs: Review trigger logs for evaluation results

Trigger Firing Too Often​

Solutions:

  1. Increase Debounce: Lengthen minimum time between activations
  2. Narrow Conditions: Make conditions more specific
  3. Limit Hours: Restrict to fewer hours per day
  4. Add Conditions: Add additional conditions to filter

Trigger Firing at Wrong Times​

Check:

  1. Day Mask: Verify correct days are checked
  2. Hour Mask: Verify correct hours are checked
  3. Time Zone: System time zone matches location
  4. Conditions: Conditions include time-based checks if needed

Action Not Executing​

Check:

  1. Action Config: Action properly configured
  2. Device Online: Target devices are online
  3. Permissions: System has permission to execute action
  4. Syntax: Email/SMS/Web request syntax is valid
  5. Logs: Check for action execution errors

Too Many Notifications​

Solutions:

  1. Increase Debounce: Reduce notification frequency
  2. Limit Hours: Only notify during waking hours
  3. Increase Threshold: Adjust condition to be less sensitive
  4. Batch Notifications: Use digest mode if available

Metadata and Monitoring​

Last Triggered​

Grid shows last trigger time:

  • Timestamp of most recent execution
  • Helps verify trigger is working
  • Useful for debugging

Trigger Logs​

View detailed trigger activity:

  1. Navigate to Insights > Logging or Insights > Activity
  2. Filter by trigger name
  3. Review:
    • When trigger evaluated
    • Whether conditions met
    • Whether action executed
    • Any errors

Run History (in-editor)​

The trigger editor has a Run History panel that lists every recorded fire of the open trigger. Rows include started-at, status (success / failed / skipped — skipped rows are masked, debounced, or gate-blocked fires), duration, reason, and the attribute change that satisfied the condition (context.system_target.target_id.attribute_name = value). Skip reasons include mask (day/hour mask), debounce, and gate condition.

Clicking a row opens the Cause Chain modal which shows the downstream macros, schedules, or follow-on triggers the fire kicked off. Useful when a single attribute change cascades into several actions and you need to see which trigger fired first.

Trigger fires also render as vertical markers on Attribute History when the corresponding attribute is charted (green = success, red = failed, grey-dashed = skipped). Retention is governed by the Automation History settings under Data Retention.