Sale!
Home Automation Plugins

Device Event Triggers

Login or Register to see price!


Device Event Triggers is likely to be one of the most powerful Dash Apps that can be added to your systems.  This plugin truly unleashes the flexibility of URC Programming by allowing you to trigger Macros in the background (multi-tasking), nest Universal Macros, and much more.  With Device Event Triggers, your system will be able to bring automation to the next level.  See the documentation for a detailed explanation of many (but never all) of the ways this app can be utilized on your projects.


Sold by: Dash OS
SKU: urc-event-triggers. Category: .

Product Description

Device Event Triggers may be difficult to understand at first read, but learning what this Dash App is and what it is capable of is a huge step to increasing the capabilities of your system(s) in a significant way.  At its core, Device Event Triggers allows you to trigger URC’s “Device Events” directly from any macro.  While this may seem similar to URC’s “Universal Macro” feature, it is actually significantly different and more powerful.

By triggering Device Events, we can allow the URC System to send commands “into the background” so they can be processed simultaneously with other events.  This allows the system to multi-task, speeding up the execution of various events significantly.

Additionally, since Device Events can then trigger Universal Macros, this allows us to have a Universal Macro essentially trigger another Universal Macro.  For systems that rely heavily on Universal Macros to function, this is a key feature allowing your URC Logic to perform much more complex tasks.  You can also trigger your Device Events in multiple ways, and this is important to understand.  Below we will take a look at the fundamental features of the App.

We have asked our testers to tell us how they are actually using Device Event Triggers in the field to provide a more automated / powerful system to their end-users.  Since Device Event Triggers is really just a tool that provides more flexibility while programming your systems, the possibilities truly are endless.  If you are still confused as-to what this plugin may provide, you can view a few examples below (also make sure to check out the Dash App Tour).

Boardroom / Conference Room

One user of Device Event Triggers uses the app to speed up the execution / setup of the board rooms / meeting spaces that they setup.  Projectors can require long delays before they are ready for commands, with Device Event Triggers this dealer was able to completely bypass that wait by sending the command into the background.

This way his system could continue to setup it’s various sources and provide control to the user while the projector continues to boot up.  To the user, no delay is noticeable and the macro will complete in seconds rather than the 60+ seconds it would otherwise be stuck on the “please wait” screen.

Since the projector will rarely actually be on an input other than it’s set input, this means that the user is able to operate their system as quickly as possible (once the picture is visible) rather than having to wait for the projector to turn on and switch sources every time.

Garage Door Monitor

One of the more popular uses of Device Event Triggers is to monitor the garage door using delayed macro triggering.  Essentially each time the garage is opened, an event is scheduled to occur in 30 minutes warning the user that they have left their garage door open.

During this time, if the garage door is ever closed by the user, it will cancel the execution of the notification.  This way the user only gets notified when the garage door was left open consistently for longer than 30 minutes.  Simple, but effective!

Occupancy Monitoring

When used in conjunction with Dash Time Tools, which allows us to time how long has passed since any macro or event has occurred within our system, we can track the last time the project was occupied and automatically trigger various events once a certain time has passed (using Interval Device Events).

For example, we may reset the Time Tools timer each time any occupancy is detected within the project.  We may also reset the timer any time a TKP-100 or Lutron Keypad (or any other event) since we can fairly easily assume if they can press the keypad button they are at the location (being sure not to put this macro on any macro that could be triggered using Offsite Control).

We setup a Device Event Trigger to occur every XX Minutes (1+ Minutes) that will check the time since the timer was reset.  We can then use simple URC IF/ELSE Statements to trigger various commands to occur once the timer reaches a certain value.

Nested Universal Macros

Universal Macros are extremely handy for offloading tasks that may need to be done many times as your end-user utilizes the system.  For example, you may want to create “programming shorcuts” to setup lighting, volume levels, favorites, etc.

One of the biggest obstacles you may run into as you begin designing systems in this much more powerful manner is the fact you can not trigger another Universal Macro from within a Universal Macro.  For example, if you are setting up a room source, and want to trigger a favorite (which is placed in its own universal macro), you would have trouble doing this.

Device Event Triggers makes it easy to trigger macros in any way you want, and even use its powerful multi-tasking features to process longer macros while continuing its triggering of the programmed macro.

While more advanced, these features can make your systems run significantly smoother as perceived by the end-user when utilized correctly.

Door Lock Monitor

Another popular feature.  When used in conjunction with any URC-Controlled Door Locks (Z-Wave, etc), we can monitor our door locks in a few different ways to generate powerful automation capabilities.

One user has a system similar to the Garage Door Monitor Example above.  It will notify the user if the door lock was left unopened for a specific period of time letting them know that they forgot to re-lock the door.

Taking that to the next level, the user has recently upgraded their program to first check who it was that opened the door and notify only them first (using Push Notifications).  Should the door still not be locked within the set time, it will then notify all users that the doors have remained unlocked past a certain time limit.

Another user also added a “Night Monitor” to this example.  In their program, between 10 PM – 6 AM if the door is left unlocked it will automatically lock the door (and further close the garage door and turn off the lights in unoccupied rooms).

Activity Time Limiting

You can limit the time an activity may be used fairly easily.  This has been used in a variety of ways to provide powerful end-user configuration.

For example, say we wanted to limit using of a game console to a set time period.  We could do this easily with delayed macro execution.  We could even build in parent-only macros that allow them to extend the limits at any time.  After the time period expires, perhaps we warn the user first that the time will be expiring soon.  Once the time expires the system will automatically be shutdown.

When used in conjunction with Time Tools (or using URC’s Macro Scheduling Features) we could limit the amount of times the system can even be used each day.  This way once their time expires, they will not be able to turn the gaming system on again.

Using Sensors, variables, and more we can even check to see if the system was manually turned back on and automatically turn it off and/or warn the parents that the system was turned back on (using Push Notifications).

This concept could of course be applied to any event or macro in your system.

Night Monitor

Touched on in another example, an increasingly popular feature that is made much easier and more powerful with Device Event Triggers is to create a “Night Monitor.”  This will engage based on a URC Event Timer in most cases (but sometimes it may use Interval Events, etc).  Once engaged, the Night Monitor triggers every XX Minutes (based on users preference) and check the status of the home.

Using TCL Commands, proper variable settings, etc the night monitor can check whether doors have been left unlocked, garage doors are left opened, kids are up and using their systems after bedtime, and much more.  It can then automatically trigger commands (or in the case of kids using their systems, warn the user via Push Notifications).

Any kind of monitors can be created to consistently check up on the systems statuses and react automatically once a change has been detected.

Reactive Reminders

A more detailed example can be found in the Reactive Notifcations Product Page.  Essentially when combined with Dash Reactive Notifications, Event Triggers can be used to provide reminders of various things throughout the home.  For example, maybe your system will send the user a Push Notification that they forgot to lock their door or close the garage if not closed within a period of time.  With Dash’s Reactive Notification capabilities, right from the lock screen the end-user can swipe and close or lock the device without ever having to open the app.  These types of things take only seconds to setup and can really add to the value of your system(s).


Dash App Overview

Below you will find various information about the Dash App.  This includes the download link and where you will find it within your URC Programming Software.

Download Link:
Accelerator Location:
My > IP Database > AUX > Dash Apps > Device Event Triggers
Driver File Name:
Dash – Device Event Triggers.csd

Download & Import the Dash App

In order for the Dash App to become recognized by the URC Programming Software we will need to import the provided TCM File into the Software.  Once this has been done properly the Dash App should show up in the “Add Other Devices” programming step in the “Accelerator Location” provided on the overview tab.

Step 1

In your Programming Software locate the “Import TCM Files” button in the File tab of the top menu toolbar.  Click it to open the Windows File Browsing window.  Browse to the TCM file you wish to import and select it.

Step 2

Based on the Dash App / Module you are importing, a dialog similar to the above will appear.  This window indicates what interfaces are supported by the TCM File you selected.  System Plugins may only show “Driver” and “Base Station Files” when no User Interface is provided by the module.

Step 3

Confirm that the Dash App was successfully imported.  You can do this by navigating to the driver where the Dash App is installed (see Overview Tab) and making sure a checkbox is provided for “8. Select 2-Way Modules for Network Remotes / Keypads”

Dash App "Network Setup"

Network Setup is a step that is required regardless of if the module is communicating with a physical device.  This step will go over how your Network Setup should be configured for this Dash App.  You will generally find the Dash App under “Network Setup > Non URC Device” in your URC Program.

This Dash App does not require that a specific IP Address is setup for it to operate.  However, it should be assigned an “Instance ID.”  When a module does not require a specific IP Address be setup, you can assign any IP Address to the Dash App that is unique from any other device in the list.

Your IP Address will be used as an “Instance ID” which will separate it from any other Dash Apps or URC Modules you have setup.  This ID is helpful when you want to create jumps to the Dash App / Module in multiple rooms / areas of your programming.

In the example below we have added two Dash Apps, “System Monitor” and “Time Tools.”  Each has been given a unique value “0.0.0.1” and “0.0.0.2.”  If they were assigned the same value the Dash App would result in an error and would not start up properly.

If you are adding the same Dash App into multiple rooms, it is important that each time it is listed in the Network Setup step that we give it the same “Instance ID / IP Address.”  This will determine whether it should try to create a completely new module (which may also be helpful at times) or if it should simply create another jump into the same module (thus not wasting processor memory).

Below we have an example of this with “Dash Access” where the Dash App is added into each room but we assign it the same IP Address each time:

Port Assignment

Port Assignment generally will not matter or will be set by default.  Should this need to be changed it will be noted within this documentation.

Dash App Parameters

Correctly configuring the Dash App Parameters is critical for your Dash App to work properly. This is generally completed in the “3rd Party 2-Way Settings” step of your URC Programming.

This Dash App does not require any Parameters to be setup.

Dash App Feature Tour / Walkthroughs

Welcome to the Dash App Feature Tour!   This page will go over the features available to you when using the Dash App within your Dash OS-powered systems.  These tours may include specific programming guides, file examples, drivers, or simply detailed explanations of the features listed on the Product Description tab.  Use the tabs to the left to select a feature that you would like to learn more about!  Enjoy!

Dash App Tour File

Device Events 101

Device Events

Device Events allow you as the URC Programmer to program various events that you are interested in integrating with.  You are able to create any number of Device Events and can use simple text fields & drop-downs to configure which Events you are interested in.  Whenever your parameters are met, the macro you program into the Device Event will occur immediately.

Device Events run in the background and do not interrupt what the user is doing.  This means that the system can actually trigger many commands simultaneously and constantly be running your various tasks.  This is the heart of Event Triggers and is where most of our programming will occur.

In the examples provided below, we will provide a few examples of Device Events that are possible today.  No matter what, when the parameters listed are met, the custom macro that you provide will be triggered automatically without any user input required!  These are just a few of the thousands of available Device Events.

Examples of Device Event Macros:

  • When Nest Ambient Temperature Rises Above 80 Degrees…
  • When Nest Goes into Away Mode…
  • When the Honeywell Security Alarm is Triggered…
  • When the Honeywell Security System is Armed…
  • When Lutron Occupancy Sensors Become Occupied…
  • When Lutron Lighting Rises Above 80%…
  • When User Responds to a Push Notification…
  • When a Z-Wave Door Lock is Unlocked…
  • When a Z-Wave Door Lock is Unlocked using the specified PIN Code…
  • Many More…

TCL Commands / Queries

TCL Commands can be added to any Macro.  It doesn’t matter if it is a macro triggered by an end-users button press or from within Sensor or Device Event Macros.  TCL Commands are programmed similarly to Device Events but have a very different purpose.  With these commands we are filling out parameters that will be sent into a module to be processed.  From there they could do anything from controlling devices to triggering events & macros.

TCL Commands can also be used to query devices.  Values can be passed back into your programming and saved into your URC Variables and used in any way you see fit!  Each TCL Command that returns a value into your URC Variable will generally have a guideline as-to how it works and what information it will return.

TCL Commands essentially allow us to query and control devices easily just by filling out simple forms.  Since these commands are filled out dynamically as we write our macros, it is extremely easy to create commands & control that would normally take us hours to create, and it generally only takes seconds to do!  Below are a few examples of TCL Commands & Queries that are available today…

Examples of TCL Commands:

  • Send a Push Notification with the specified Title, Message, & Sound…
  • Is the specified Z-Wave Door Lock currently Locked?
  • Is the DSC Security System Currently Armed?
  • How Long has the Garage Door been opened?
  • Set Lutron Lights to 52.5%…
  • Is the Living Room Currently Occupied?
  • Close the Garage Door…
  • What Time is it Currently?
  • What Time is Sunset Tonight?
  • Is it Currently Daytime?
  • Trigger the Specified Device Event Directly…
  • Trigger the Specified Device Event In 10 Minutes…
  • Trigger the Specified Device Event Every Minute…
  • Much More..

Executing an Event

Lets start with the most basic concept of the Device Event Triggers Dash App, the ability to directly initiate the triggering of any of the Device Events you have setup for the Event Triggers App.  This may seem like the same thing as triggering a “Universal Macro,” but in reality it is very different.

When we trigger a Universal Macro, it becomes apart of our main macro.  It is a completely linear process.  If we place a delay anywhere in the execution of the macro it will delay the entire macro.  We can’t multi-task in this scenario, but it is a safe way to program as we don’t need to consider multiple processes running seemingly at the same time.

Now we add Event Triggers to the mix and we enter a whole new world of flexibility.  Now our macro can be told to run multiple commands simultaneously.  Our macros can allow multiple universal macros to nest each other.  We can even create loops if we are careful that can process data and intelligently conduct a multitude of commands.  In other words, we open the doors to programming just about any solution we can imagine!

While this may sound scary at first, it is actually quite simple once you understand the concept.  Lets take a look at each process graphically below, study each and then we will continue.

Standard Universal Macros

Using Device Events

This is just one of many examples that becomes possible with Event Triggers and possibly one of the most basic.  We could use this concept to get exponentially more complex as needed for our situation.  We could actually create multiple branches and processes all firing simultaneously and all taking different times to complete.  During this time we can provide control back to the user so they don’t have to wait for everything to complete.

Lets take a look at programming our first very basic Device Event Trigger! You can follow along and program with us if you’d like.

Be sure to first import the TCM Files for System Monitor and Device Event Triggers before downloading the training Accelerator files!

Download File (Step 1)

The file linked above is essentially an empty file with some basic module setup provided.  You can discover your own MRX-10 (or convert it to a MRX-20 file) and add any interface / URC Mobile Setup so that you can test the file in your own environment.

Note that you will also need to enter your Dash OS Credentials into System Monitor and install Device Event Triggers onto your Controller Account.  If you are following along, open the file and jump to the “Edit User Interfaces” step.  You will see that nothing is currently programmed and we have an empty screen.

We will be programming a simple macro that will trigger a Device Event.  This macro will need to be programmed into “Room 1” as it is the only visible room in our system.  For the sake of this training, we are going to call the macro we have created “Trigger Event” and just place it on the main screen/menu of the Room.

For now we will skip programming the macro itself and jump to creating the Device Event that will be triggered by our Macro.  Once we specify a specific Device Event, we will be given a macro that can be programmed which will happen whenever the event is triggered by a macro (or even by another Device Event).

Navigate to Macro Editing > Automation Macros and make sure the the first option, “Device Events” is selected.

To create our first Device Event, click “Add Macro” and a window will pop up allowing us to specify the parameters of the Device Event was would like to create.

We can name our Device Event anything we’d like that will allow us to remember what it is once listed.  For this example, lets simply call it “Example Device Event.

We can then specify the “Available Device” which in this case should only show our Device Event Triggers Module.  In your own files you may see multiple options here as any module which supports Device Events will populate within this drop-down.

Home Automation Device Events

Now for the “Available Event” dropdown.  This dropdown will provide a listing of any Device Events that are available for the selected module.  In our case we have two options:

  • Trigger On What Event? – This allows us to create a macro that is given an ID.  Whenever we send this ID to the module (gone over in later steps), it will execute the programmed macro.
  • System Startup Event – This will trigger when your system first boots up.  This is helpful to setup variables, prepare your system for the end-user, and make sure that everything is in-sync as needed.

For our purposes we will be using the “Trigger On What Event?” event so select it from the drop-down menu.

Here you will notice two fields “Event ID” and “Cloud Event?”  For our purposes we are going to ignore the Cloud Event field as that is apart of a completely different Dash App, you can just leave that as “No.”

  • Event ID: The Event ID you create here will be used to trigger this macro in the future.  You can create any Event ID that you’d like, just make sure you will be able to remember it easily for later when we are wanting to trigger the event.

Event ID’s are Case Sensitive so remember exactly how you’ve written the Event ID here for later use.

Lets keep it simple for this guide and use the Event ID “Example” as shown in the screenshot to the right.  Once you have done this, press “Ok” and you should now see your device event populated in the listing of Device Events.  By selecting this Device Event you should now be able to start programming a macro that will occur whenever we trigger the event “Example” using our TCL Commands (which we will go over shortly).

First, you can download a new example file programmed up to this step for comparison if you are unsure of any steps we have gone over thus far.

Download File (Step 2)

Now we can program anything we want within this macro.  Maybe you want a projector to turn on and switch inputs, or you want lights to go on or off, URC does not limit what can or can’t be done within these macros for the most part.  A few things like page jumps are not available since this macro is not actually tied to your interface when it is executing.

In order to provide an end-result that will allow us to best visualize what is happening, we will be using the Dash OS feature “Output to Cloud Logs” within the macro so that we can see exactly what is going on with our macro when it is triggered.

Create a new TCL Command by clicking on the  icon in your Macro Toolbar.  This will bring up a similar window to adding a Device Event.  We will select System Monitor and Output to Cloud Logs as shown below.  More information on this is available by clicking the link above.

Whatever we type into the “Message” parameter will show up within our Cloud Logs if we are viewing them as the Device Event is triggered.  Lets start by showing us when the macro first is triggered.  In addition, we will want to be able to easily identify what part of the system is being triggered.

Since this is the Device Event Macro, we will start any cloud log message with “EVENT MACRO:” followed by our message, which in this case will be “Executed!

Cloud Logging for Home Automation Systems Output Example

Just to add a better visualization to the whole thing when we actually run the macro, which should help you to better understand exactly how Event Triggers works, lets place a 30 Second Delay into our Macro followed by another Output to Cloud Logs with the Message “EVENT MACRO: Completed!”  This should make our final Device Event Macro look something like the screenshot below.

Feel free to download the example file programmed up to this step below, or you can continue on with your own file if you are confident you haven’t missed anything!

Download File (Step 3)

Phew!  Now that we are done creating our Device Event, all that is left is to trigger it.  We can trigger it anywhere that we can program macro commands (even from within Device Events).  We will keep it simple for the sake of this guide and simply program the event to trigger when the custom macro we created earlier is pressed by the user.

Navigate to Macro Editing > Edit Macros by Room and select “Room 1” which is where we should have added our custom macro in the original steps.

Home Automation Edit Macros By Room

We can trigger the Device Event we created using a TCL Command, similar to how we programmed our “Output to Cloud Logs” in the previous steps.  However, this time we will be selecting our Device Event Triggersfrom theAvailable Devices” drop-down.

For “Available Command” we have a few options.  We are going to trigger this event immediately so select “Trigger Event.” Now it is asking for the “Event ID” that we would like to trigger.  If you remember from our earlier steps, when we created our Device Event we gave it the ID of “Example“.  This is the ID that we will need to use to trigger the event to occur.  It must be EXACTLY as you wrote it into the Device Event and is case-sensitive!

Trigger the Example Event

Once you have done this and pressed “Ok” to create the TCL Command, you should see it added to your macro.  As we did with the Device Event, we can program in a few “Output to Cloud Logs” so that we can get a better idea as-to what is going on as the macro runs.  This time lets use a prefix of “MACRO:”  (letting us know it’s the standard macro that is sending the logs) followed by our messages.

We made a few of these messages, each with the “MACRO:” preceding it.  In our example below we programmed “Executed!“, “Triggered Example Event“, a 5 Second Delay, then “Completed!”  We also added a Please Wait at the top so we can see exactly when the user is given control again.

That’s It!  Now all that is left is for us to download and test the results!  You can check out the “Video” tab to see the results as well as the video of us programming the Event Trigger as defined here!  You can also download the final file below to compare to your own implementation!

Hopefully you can start imagining ways that you can implement Device Events in this manner to benefit your projects in the future!

Download File (Final)
Empty tab. Edit page to add content here.
Empty tab. Edit page to add content here.
Empty tab. Edit page to add content here.

Dash App Update History

Version 1.15

  • Feature: Added the ability to cancel future executions that were previously scheduled.
  • Bug Fixes & Minor Speed Improvements