Using Node-RED with HomeKit

For users of Apple devices, choosing Apple Home as your smart home platform of choice makes a lot of sense. The Home app provides a clean and functional control interface with a decent ability to customize the layout to suit your specific needs, and the automation capabilities are sufficiently comprehensive to suit most users.

Power users and those with extensive Apple Home accessory collections are, however, bound to run into limitations. Whether it’s being unable to find a way to integrate a specific device or being unable to make an automation work the way you really want, there are several third-party tools that can help.

A popular option for data handling and automation is Node-RED. This is a low-code automation tool that can be used with various add-ons to enable all sorts of advanced functionality, including integration with HomeKit. With Node-RED you create ‘flows’ out of ‘nodes’ which you wire together to pass message between them in sequence. This allows for quite extensive logic beyond what you could easily achieve in Apple’s Shortcuts or Home automations.

When I first started playing with this solution, it wasn’t entirely clear how to get it to work, or what it could actually do. I’m going start with setting some expectations and then look at how to actually set it up, with some examples.

Node-RED Capabilities In Apple HomeKit

For Node-RED to really shine, it needs to be able to read and write data (or send commands) in some way. Integration with additional tool and platforms, like HomeKit, is done by adding community created nodes to Node-RED. The one we want for HomeKit is called node-red-contrib-homekit-bridged, also known within the community as NRCHKB.

This node provides a way to simulate a HomeKit accessory and to add it into HomeKit by emulating a bridge. If you’ve used other third-party or unofficial accessories, you’ll be familiar with this approach. The way this works in Node-RED can be a little confusing at first since you don’t create a node specifically for the Bridge, but we’ll get to that shortly.

Because all interaction with HomeKit from Node-RED is via these simulated accessories, there are some distinct limitations. HomeKit, being secure by nature, does not provide a way for external devices to read data from it and Node-RED is no exception. It can only access data for the accessories that it has created, which limits what you can do with automations within HomeKit itself.

HomeKit Bridged Accessories

HomeKit supports the notion of a bridge, which is typically a device that translates communication between HomeKit and other devices that can't natively talk to it. This is intended to support devices that use communication protocols or radios that Apple devices do not have, like ZigBee and Z-Wave.

A bridge can be set up with HomeKit support and present any deivces connected to it as HomeKit devices that can be used in the Apple Home app. Third-party tools have been created to leverage this functioanlity to provide interfaces to other unsupported devices via a software layer.

Tools like Homebridge, Scrypted, and even other platforms like Home Assistant and Athom Homey can also use this to push devices into Apple Home so you have one unified interface.

What can you do with HomeKit?

There are a couple of key uses for Node-RED that can leverage this accessory focused view.

1. You can create entirely new accessories for hardware that doesn’t support HomeKit natively. By using various data exchange methods within Node-RED, such as HTTP, MQTT, JSON and so forth, you can pull data and present it to HomeKit, then take HomeKit commands and push them back to the hardware.

2. You can use virtual accessories as interfaces to other external devices and services, either as simple triggers or by pulling data from the accessory’s characteristics you can set within HomeKit.

Setting Up The HomeKit Bridge

Earlier I talked about Node-RED handling bridges a little differently. As the bridge itself is not actually a function of Node-RED, the Homekit plugin nodes have to handle it themselves. While this uses a basic Node-RED feature - the configuration node - it isn’t obvious up front. as these types of nodes are somewhat hidden.

We’ll need a running Node-RED instance first. There is extensive documentation on that to get you set up on whatever host platform is your preference and to familiarize yourself with the basic editor user interface. The UI is quite simple, and you can get a good feel for it in a few minutes.

Next, we need to install the HomeKit nodes:

1. Click the hamburger menu in the top right.

2. Select Manage Palette from the drop down.

3. Click the Install tab.

4. Type node-red-contrib-homekit-bridged into the search box.

5. Click the small Install button to the right of the result.

This will download and add the HomeKit nodes to your palette on the left of the editor. There are two nodes visible here: service and status. The Service node is the primary one we’ll use as this is what simulates a HomeKit accessory by providing a HomeKit service. Most services are defined by characteristics, which are what HomeKit calls the attributes that define the data and actions a service provides. The NRCHKB wiki provides a list of supported characteristics, which you’ll need to refer to if you are building your own accessory.

There is a third node that is not shown in the palette. This is our configuration node. These are special nodes that hold (unsurprisingly) configuration data. For HomeKit, this configuration node is where we establish the bridge functionality.

Creating the bridge

You create a configuration node by accessing it within a node that uses it. In this case that would be a service node. Drag a service node onto the canvas (the middle workspace of the editor) and double click on it. Among all the various configuration fields for the service itself, there is one field called Bridge. Clicking the + button next to that will create a new configuration node for our HomeKit bridge.

You’ll get another configuration window will all the bridge details, but we really only need to editor the Name field and everything should be work as-is. Just click the Add button in the top right to finish. We can now select that bridge name in the Bridge field drop down on any Service node we add to Node-RED. You can have multiple bridges if you want to segregate things, but there’s nothing stopping you simply using the one bridge for all your flows.

You can access the configuration node through any service node, or you can use the cog wheel button on the sidebar to the right. This will show all configuration nodes in your Node-RED instance, where they are being used and by how many nodes. Just double click on the name here to edit it.

Be sure to click Deploy at the top of the editor to make your changes active. You have to have an active service node that is using the configuration for it to be available for pairing. If you delete all your service nodes, the configuration will be ‘unused’, but still available as a configuration node for use in other nodes.

Pairing the bridge

Now we have an active bridge running we need to pair it with HomeKit.

1. Use the Home app to Add Accessory as normal.

2. You won’t have a QR code to scan, so tap More Options…

3. Select the bridge name you entered or tap My Accessory Isn’t Shown Here.

4. Enter the code shown in the configuration node in the PIN Code field.

5. Accept the warning that the accessory is Uncertified.

6. Complete the pairing process as normal.

You’re active Node-RED services using this bridge will appear in the same Room as you specified when pairing the bridge. You can move and rename these as normal accessories if you wish.

Select More Options…

Select the bridge name

Accept the warning and enter the PIN

Node-RED Examples For HomeKit

If we can’t really set up complex automations for HomeKit in Node-RED, then what can we use it for?

These use cases can be a bit niche, and are better suited to power users and the maker community. Broader technical knowledge is definitely require in most cases, but for those cases, Node-RED provides a versatile and easy to manage solution. To help understand where Node-RED fits into the HomeKit eco-system, I’ll look at some practical examples. Some of these use additional nodes that need to be installed to provide the necessary data hooks, but that’s all part of the beauty of Node-RED.

Sprinkler Valve using an Omron PLC

This one is an extension of some basic valve control flows that uses a PLC node set to provide connectivity. The PLC state is read every 5 seconds at the start of the flow and uses both data conversion and function nodes to massage the data between what the PLC needs and what HomeKit needs in the service node. The Service node then has an ouput which allows the valve to be controlled from the Home app. Get full configuration details here.

Omron PLC Valve Controller flow

Basic Temperature Sensor

This is a simple flow that create both a temperature and humidity sensor in HomeKit based on MQTT messages from a Sonoff sensor. A function node is used to format the message input into the necessary characteristic JSON format. Get more details here.

Sonoff temp/humidity sensor

URL hook to trigger Siri Announcements

In order to have Siri make announcements as part of our automations, we need to use a full shortcut as the limited set of actions in the Home app doesn’t include the Intercom action we need. I use a tool called Pushcut to trigger full shortcuts from a URL call that allows it to run unattended.

Normally we can use the Get contents of URL action in the Home app shortcut, but this is currently broken as of iOS18. This flow provides an (albeit simple) example of how we can interface with other services. By creating a virtual switch, we can read the On state and use it to trigger the URL call from an automation. The switch automatically turns off again after 1 second so it’s ready to be called again.

Pushcut URL call button

Arduino based dimmer bulb

This flow allows control of an Arduino-based dimmable light. The Arduino code uses MQTT to publish and read messages from several topics to control various aspects of the light (brightness, color, etc). Again, we see function blocks used to convert the MQTT data into HomeKit characteristics and back again to pass commands back to the Arduino via the same MQTT topics. See more details here.

Arduino-based smart light via MQTT

Summary

While Node-RED can’t be used for general automation flows in HomeKit due to a lack of access to the platform’s data, it can be a tremendously powerful tool for creating interfaces to other hardware and services via virtual accessories.

The simple editor and extensible nature of the available nodes provide a lor of functionality and an easy way to do low code logic programming that can be used to not only simulate smart devices but automate a wide range of data processing tasks and integrations.

Given is easy to set up a Node-RED instance on very low spec hardware, it definitely worthwhile considering it as part of a solution to your next challenging smart home problem.