Integrating a Wide Range of Zigbee, Z-Wave, and IoT Devices with Crestron

Crestron has been a premier provider of products for the smart home since 1972. Today they have products to automate homes, offices, classrooms, and much more. Their products are tightly integrated and robust enough to handle entire corporate and college campuses; large commercial buildings, including sports stadiums and convention centers; and mega-mansions for the rich and famous. I’ve personally worked on the design and development of a Crestron system for a 75,000-square-foot home.

The tight integration between Crestron’s automation processors and their peripherals provides the stability needed for the largest projects. However, engineering costs and the services they offer their dealers – including sales assistance, design assistance, training, and technical support – all have to be included in the prices that Crestron charges for their products. This has made a smart home based on Crestron products typically out of reach of the average homeowner.

The challenge for these homeowners isn’t just that a Crestron automation processor can be cost-prohibitive, but that the company’s peripheral products are also difficult to afford. A Crestron smart light switch, for instance, can cost upwards of 10 times the price of an off-the-shelf Zigbee or Z-Wave switch. And, while it might be tempting to mix and match off-the-shelf wireless smart home products with a Crestron processor to lower the overall cost for a Crestron automated home, Crestron discourages this approach.

Also, there are an array of non-Crestron Zigbee and Z-Wave smart home products that would be useful within a smart home but no way to integrate these products into a Crestron system. For example, in the past I’ve written about leak detection systems (Smart Water Management Solutions from Phyn, The 5 Best Smart Water Leak Detectors Compared) and how they can save a homeowner from thousands, or even tens of thousands, of dollars of damage to their home. Crestron doesn’t offer an easy to retrofit wireless products – such as the Z-Wave-based Dome Water Main Shutoff – to shut off the main water supply to a home.

In the future this will become even more of an issue as Apple, Google, and Amazon work together with the Zigbee Alliance on an update to the Zigbee wireless protocol. The stated goal of that effort is to allow Zigbee products to be compatible across the platforms of all three manufacturers.

Finally, today there are many people who have installed their own DIY automation systems as well as people that have purchased a house where a dealer has installed a basic system. In some cases, these people could benefit from the advanced features that a Crestron system offers. However, there has never been a way to transition their system to a Crestron processor without throwing away their entire investment in smart light switches, thermostats, and other IoT hardware.

My first step to solving this problem was to find a way to integrate the needed radios to communicate with Zigbee and Z-Wave products into the Crestron ecosystem. After some research, I found that the easiest way to do this was to find a way for a Crestron system to communicate with one of the off-the-shelf smart home hubs.

SmartThings Hub Integration with Crestron

My first attempt was to try to integrate a Samsung SmartThings hub with a Crestron system. I found a software developer that had already started working on this, and I helped to debug some issues in the code. The original developer wasn’t able to continue working on the project, so I hosted it on my Github and took over the responsibility for maintaining and enhancing it. Working with a number of other people, we expanded the types of peripheral products that the code supported.

While this code provided a stable way of integrating Zigbee and Z-Wave peripherals into a Crestron system, SmartThings was not an ideal platform for several reasons.

1. One of the advantages of a Crestron system is that all the processing takes place on the Crestron automation processor – not in the cloud. An internet outage doesn’t affect its operation. A SmartThings hub is the polar opposite. It is a cloud-based product, and during an internet outage your smart home ceases to function. Integrating a SmartThings hub with a Crestron-based smart home would significantly reduce the robustness of the overall system.
2. To provide a way for the SmartThings hub to communicate status of the peripherals back to the Crestron processor required creating a “port forward” on a homeowner’s router. In this day and age, this is a significant security issue. Without the “port forward,” if someone in the home manually turned on a smart light switch that was integrated with the SmartThings hub, the Crestron processor wouldn’t be made aware of the light’s new status. Then other smart home actions, such as turning the light off if a presence sensor in the room judged that it was no longer occupied, might not function properly.
3. The solution required programming expertise on both the Crestron processor and the SmartThings hub, further complicating the software development process.

For these reasons I was always on the search for a better solution

Hubitat Elevation Integration with Crestron

Hubitat was founded in 2016 and is located in Scottsdale, AZ. Unlike most other smart home hub manufacturers, Hubitat believes that automation should all take place locally in a home so that the smart home should operate when the internet is down, so there won’t be any delays due to communications going through a cloud service, and so all data can be securely stored locally on the hub to enhance security and privacy.

A recent article on the Android Police website, titled Nest outages prove that the smart home needs a local fallback, highlighted the issues of smart home products that are dependent on internet access and cloud services; reaffirming the efficacy of Hubitat’s approach.

Based on this and Hubitat’s compatibility with almost 500 off-the-shelf devices, Hubitat appeared to be a better platform to integrate Z-Wave and Zigbee devices with a Crestron automation system.

My first approach to integrating the two platforms was to try and port the original SmartThings project to the Hubitat environment. However, after learning more about Hubitat, I found a much better solution.

Hubitat includes a built app called the Maker API that was designed as a way for third-party systems to communicate with a Hubitat Elevation hub. The Maker API turned out to be a great integration solution for several reasons:

1. For security, the Maker API allows you to designate which connected Zigbee, Z-Wave, and IoT devices can be accessed by a third-party system. Other devices can be excluded
2. Again, for security, the Maker API provides an OAUTH token needed for all messages sent to the hub
3. Communication takes place using industry standard http/https messaging
4. The Maker API can send unsolicited messages back to the third-party systems when the status of a connected device changes (such as when a person turns on a light switch by pressing the button on the switch)
5. The Maker API, and the entire Hubitat Hub, has a simple-to-use web interface

Based on all of that, I completely rewrote the original SmartThings integration project to make it work with the Hubitat Maker API. And, as part of that effort, I looked to greatly expand the types of third-party devices that could be integrated with a Crestron system through the Hubitat hub, compared to what I was able to provide with the SmartThings integration project. The code is now available for download from my Github https://github.com/jbasen/Crestron-Hubitat-Integration, and it includes support for:

• Buttons
• Contact Sensors
• Dimmers
• Environmental Sensors (Temperature and Humidity)
• Fan Controllers
• Garage Door Controllers
• Light Sensors
• Locks
• Moisture Sensors
• Motion Detectors
• Multi-Sensors (multiple sensors in a single device including any combination of contact closure, vibration, temperature, humidity, and light level)
• Phillips Hue Bulbs (White Ambiance and Color)
• Presence Sensors
• RGB and RGBW Bulbs
• Shades
• Switches / Outlets
• Thermostats
• Hubitat Device Groups
• Hubitat Scenes

While I don’t have the resources to test every device that is compatible with a Hubitat Elevation Hub, any compatible device that fits into the above categories should be able to be integrated with a Crestron system.

Installation of a Hubitat Elevation Hub

Installation of this system is very simple because there is no custom code needed on the Hubitat Elevation. I’ll outline the steps to get this working for a single Z-Wave or Zigbee switch. I keep using a switch as an example in this article not because a Z-Wave or Zigbee switch adds unique value when added to a Crestron system. I’m using it as an example because it is a simple device to describe and for readers to understand. That being said here are the steps:

1. First, make sure that both the Crestron processor and the Hubitat Elevation hub have either static IP addresses or DHCP reservations so their IP addresses won’t change over time. This is necessary for messages to reliably pass back and forth between the two systems
2. Assuming you have already registered your Hubitat Elevation Hub, connect to the IP address of the Hubitat hub using a browser and login using your username and password
3. Following the manufacturer’s directions, place your Z-Wave or Zigbee switch into “Acquire” mode
4. In your browser, select “Devices” from the Hubitat menu and then click on the “Discover Devices” button
5. Next, click on either the “Z-Wave” or “Zigbee” button depending on the type of switch that you are working with
6. Once the device is discovered, you can enter a name for the switch and click on the “Save” button
7. Next, click on “Apps” from the Hubitat menu
8. Click on the “Add Built-In App” button and select “Maker API” from the list of built in apps.
9. In the Maker API configuration screen, click on “Select Devices” to display a list of devices that are connected to your Hubitat hub. Then, check the box next to the switch you earlier connected to the Hubitat and click the “Update” button. This is very important. You must click the update button, or the device will look like it is selected but it will NOT work properly with the Maker API app
10. Next, scroll down to the bottom of the Maker API configuration screen. There you will see a series of http commands. Each command begins with: http://<IP Address of Hubitat hub>/apps/api/XX where XX is the ID of the Maker App. Save this number for later. Also notice that each command includes access_token=xxxx-xxxx-xxxx-xxxx-xxxx. Save the access token for later.
11. Right mouse button click on the “Get All Devices” link and select to open the link in a new browser tab. In the new browser tab, you will see the json returned by the Hubitat hub. This json includes data for all the devices attached to your hub. Find the entry for the switch you just added and copy down the “id” number of the switch. If you have a number of devices connected to your hub, then you may find it easier to read the json if you use one of the many json formatters on the internet
12. Finally, go back to the browser tab with the Hubitat hub user interface and press the “Done” button to close the Maker API app configuration page.
13. Next, using whatever procedure you are comfortable with, copy the .usp and .ush files from the Hubitat Demo.zip file to your Crestron Usrsplus directory. Each of the .usp files has a # INCLUDEPATH statement that defines where the Hubitat.clz file will be located. You need to change the include path to the location where this file will be located on your own computer. I have experienced compile issues when the .clz file is placed in the Crestron Usrsplus directory, so unfortunately this editing step is necessary. After editing each .usp file, you then just need to recompile them. Don’t forget to copy the hubitat.clz file to the directory you specified in the INCLUDEPATH.
14. After you have studied the code in the Hubitat Demo program, you just need to
    • Insert a “Hubitat Comm Manager” module into your own program.
    • Fill the parameter fields on the Comm Manager module in with
      1. The IP address of the Hubitat Hub
      2. The IP address of the Crestron Processor
      3. The communications port you specified in step 7
      4. The access token you copied down in step 10
      5. The Maker API app ID you copied down in step 10

1. • Insert a “Hubitat Switch” module into your program and fill in the Device ID parameter field with the switch’s device ID that you copied down in step 11.
   • Now connect the various signals on the two modules in the same way you see them connected in the demo program
   • You are done

While the above may seem a bit complicated, it really isn’t too bad. In addition, most of these steps are required only when you first set up the Hubitat Hub. Adding a second switch to be controlled by the Crestron system just requires you to:

• Discover the switch on the Hubitat Hub
• Add it to the list of devices in the Maker API app.
• Get its Device ID as described in step 13
• Add another Hubitat Switch Module to your Crestron program and add the switch’s ID to the parameter field of the module
• Connect the needed signals to the switch module

Hands On with the Hubitat Elevation

I have been using this code to integrate a Hubitat Elevation hub into my own Crestron system for a number of weeks without any issues. Because communication takes place without any trips to the cloud, it is quick, and the status messages from the Hubitat hub to the Crestron processor keep the Crestron system in synch with the true status of the devices connected to the hub.

It should be noted that certain devices are not discovered through the procedure I described above. These instead require their own built-in app on the Hubitat hub. For example, Philips Hue bulbs and the Ecobee thermostat are both added to a Hubitat hub this way. I tested this system with several Philips Hue bulbs and found they worked very well.

After adding the built-in Philips Hue app to the Hubitat Elevation Hub and connecting the hub to your Hue Bridge, all of the connected Philips bulbs will show up as available devices. They can then be added to the list of devices in the Maker API app and can then be controlled using the Hubitat Philips Hue module I wrote in SimplWindows.

It should be noted that sending commands too fast to the Hubitat Elevation hub can cause problems. If you want to send commands to multiple devices at the same time, then you should either create a Hubitat device group or scene. A device group allows commands to be sent to multiple devices of the same type as if they were a single device. Scenes allow settings for a diverse set of devices to be grouped together and the settings initiated with a single command. For example, a movie watching scene could turn off the main lights in a room but leave a few lights at a very dim level so people could make their way to the kitchen to get a snack.

There is a dedicated module for triggering scenes: Hubitat Scene v1.usp. However, if you are working with groups you will need to use the Hubitat RGB-RGBW Bulbs v1.usp module no matter what kind of devices you have gathered into a group.

IFTTT Integration

If This Then That (IFTTT) is a free (to consumers) cloud service that provides a way for manufacturers to expose their API in a way that makes it easier for consumers to use it to integrate smart home products into their homes. I wrote an IFTTT module for Crestron systems that can also be downloaded from my Github. Unfortunately, direct communication from IFTTT to a Crestron processor, using the IFTTT Webhooks service also requires a “port forward” on the home’s router. As I mentioned earlier, in this day and age this is a significant network security issue. Fortunately, integration of a Hubitat hub with a Crestron processor also offers a solution to this problem.

Instead of using the IFTTT Webhooks service to route IFTTT applet actions to the Crestron processor, the Hubitat hub can be used as an intermediary. This eliminates the need to forward a port to the Crestron processor.

First, start by adding the built-in IFTTT app to the Hubitat hub and link the hub with IFTTT (when the app is installed it will lead you through this linking process). Next, after selecting “Devices” on the Hubitat menu, add a “virtual switch” to the Hubitat hub and configure the “enable auto off” option to automatically turn the switch off one second after it is turned on. Virtual devices act just like any device internally to the hub, but there is no device in the physical world.

Next, add the switch to the list of included devices in both the Hubitat IFTTT app and the Hubitat Maker API app. Finally, add a Hubitat IFTTT Event module to your Crestron program with the device ID of the virtual switch.

An IFTTT applet can be created with an “action” to turn the virtual switch on any time the applet runs. That action will then trigger the Event_FB signal on the Crestron system’s Hubitat IFTTT Event module for one second.

Numerical data from IFTTT can also be transferred to a Crestron processor through a Hubitat hub. However, it requires a different technique and is a bit more complex. The IFTTT Webhooks service can be used to send a numerical value using one of the commands that is displayed on the Maker API Settings page. For example, the command

https://cloud.hubitat.com/api/[Hub UUID From the Settings Page] /apps/[Maker API APP ID]/devices/[Device_ID]/setTemperature/75?access_token=[Access Token]

will set the temperature of a virtual temperature sensor to 75. The Crestron Hubitat Numerical Value module I wrote can then be added to your Crestron program and the numerical data from IFTTT will be routed to the output of this module.

Triggering Alexa Routines

Alexa routines provide a way for you to automate tasks on an Amazon Alexa device. Unfortunately, there hasn’t been a way to trigger a routine from a Crestron system. The Crestron “Hubitat Alexa Virtual Contact Sensor Bridge” module solves this problem.

The module integrates with a virtual contact sensor on the Hubitat Elevation Hub that can then be used to trigger an Alexa routine. For this to work, you will first need to add the Amazon Echo Skill app to your Hubitat hub and go through the process of linking it to your Amazon account.

Next, add a virtual contact sensor to you Hubitat Hub and add it to the list of devices in both the Hubitat Amazon Echo Skill app and the Maker API app. Then, create your Amazon routine and add the virtual contact sensor to the “When this happens” portion of the routine. Now, add the Hubitat Alexa Virtual Contact Sensor Bridge module to your SimplWindows program and set the Device_ID to the ID of the virtual contact sensor. Finally, if the Alexa routine is triggered when the contact sensor closes, it is important in the Crestron program to first trigger the contact sensor to open, wait one second, and then trigger it to close. This assures that the routine will run. The one-second delay is necessary because sending messages too fast to the Hubitat hub can cause problems.

The Alexa routine can be programmed to have an Alexa device say a custom phrase, play specific music, or take any number of other actions.

Unfortunately, Alexa routines have their limitations. Here are some things you can’t do with routines:

• Turn off all the music playing on Alexa devices around your home with a single command. This would be so useful in a leaving-for-work routine instead of franticly running around a home yelling “Alexa, stop” to turn off all the music your family left streaming when you are at risk of missing your bus
• Play music on a group of Alexa devices. This would be very useful as part of a party routine that sets your lights, shades, etc. for entertaining
• Turn off guard mode. You can turn on guard mode in a routine, but Amazon doesn’t let you turn it off. Amazon lets any potential intruder issue the “stop guarding” command by talking through the window you left cracked open for ventilation, but you can’t tie turning off guard mode to a presence sensor telling the system that you have returned home.

Hubitat Modes

The Hubitat includes built-in modes for Day, Evening, Night, and Away. These modes are exclusive, meaning that only one can be active at a time. They can be used on the Hubitat to drive user-defined logic that determines how devices are controlled. An owner can also change the names of these modes as well as define additional ones.

The Hubitat Modes v1 module allows the modes on the Hubitat to be set by a Crestron system and for feedback on mode changes that take place on the hub to be reflected in the Crestron system. However, for this module to operate properly, the setting labeled “Include location events to be sent by POST?” on the Maker API App settings page, in the Hubitat web interface, must be turn ON.

Hubitat Modes can be used in concert with the Hubitat Safety Monitor app. The Hubitat Safety Monitor allows a Hubitat to act, in many ways, like a security system. For example, sensors connected to the Hubitat can be configured to trigger alarms to sound, lights to flash, and even notifications to be sent to the homeowners’ smart phones. Hubitat modes can be used to place the Hubitat Safety Monitor app into armed or disarmed states.

Additional Integration Possibilities

As mentioned earlier, Hubitat is compatible with almost 500 third-party, off-the-shelf, smart home devices. A full compatibility list can be found here. However, it doesn’t stop there. Hubitat provides an open platform for developers to create drivers for products they want to integrate into their own smart homes and many of these drivers are made available within the Hubitat Community site. For example, a driver, with instructions, is available for integrating Ikea motorized roller blinds with a Hubitat hub

Areas for Improvement

My experience with the Hubitat Elevation Hub is that it is easy to use and provides a robust solution for integrating with off-the-shelf smart home products. That doesn’t mean that it can’t be improved upon. For instance, firmware updates are only installed manually through the hub’s web interface. Given the need to keep IoT devices up to date, with all the latest security patches offered by a manufacturer, there needs to be an option to auto-update the hub. Once a homeowner has completed work on their smart home, it could be months or years before they go to the Hubitat hub’s web interface and find that there is a firmware update that should be installed. This could leave vulnerabilities open to hackers.

I would like to see the next generation of Hubitat include a Bluetooth radio, so it can directly connect to Bluetooth devices and eliminate the need for homeowners to purchase bridges for each Bluetooth product they own. This could eliminate the need for homeowners to purchase bridge products from Philips, SwitchBot, and others. This is a logical next step in the addition of radios to a hub and would save homeowners a good deal of money.

I would like to see Hubitat allow multiple entries in the Maker API app’s “URL to “send device events to by POST” field so that multiple third-party processors could be sent device update messages by the Hubitat hub.

I would like to see Hubitat include the ability to add a security token to all messages sent by the Hubitat hub to third-party systems through Maker API http Post messages. Messages sent to the Hubitat hub for the Maker API require a security token, and it is just as important that third-party systems can validate that messages they receive are really from the Hubitat hub.

Finally, I would like to see the Maker API provide an error response (possibly just a message through the post URL) if a third-party system sends a command to a device through the Maker API and the device is, for whatever reason, unavailable and the command is not carried out. This could be because a Zigbee/Z-Wave device is offline or an IoT device that works through a cloud service can’t be reached because the cloud service is down.

In summary, a Hubitat Elevation hub is a great companion processor to a Crestron system. It is inexpensive, greatly expands the types of devices that can be integrated with a Crestron system, is simple to work with, is a stable and robust product, and aligns with Crestron’s philosophy of keeping the smart home inside the network, not in the cloud.