Other homekit types through node-red

This might be a very stupid idea, hence bouncing it off against the community before looking into this in depth.

Homekit types are currently quite limited in Openhab and based on other topics (like HomeKit: support for additional accessory types) it doesn’t look like this will change any time soon.

That being said I have seen some people successfully use Node-Red and Openhab rules in parallel and Node-Red does seem to have nodes that do support the other accessory types.

Could it be a solution to configure the other accessory types outside of OH in Node-Red and use the OH node to interact with those? It sound like quick and dirty patch work but at least it should enable to control the other types through Siri and interact with them in OH.

Any thoughts or anyone that went this route?

1 Like

I’ve zero experience with Node Red or HomeKit, but I don’t have any concerns with this proposed approach.

If you make it work, post a tutorial in Tutorials and Examples.

OK, I did some testing and it works quite well.

Here is a small video of a window that was configured in OH and how it’s linked to Homekit. You see the window change in the Home application when it’s opened and closed
Second movie is a configured fan, you see fan can be turned on and off in Home app or Openhab and changes accordingly in the other UI.

Will do a short summary of how to do this in separate post.



Here is a brief description of how to setup other types in Homekit and link them to Openhab. It’s not exhaustive and there are probably more elegant ways but it works, something a lot of OH users have been asking for. So hopefully it’s a starting point for those.
It assumes you have node red running. For those using Openhabian from @ThomDietrich it’s easy, the openhabian install script takes care of the node red installation (it’s one of the optional components), for all others there are a lot of node red topics on the forum.

Now we have node red follow below
Step 1 : Install the homekit node https://www.npmjs.com/package/node-red-contrib-homekit .
Do sudo apt-get install libavahi-compat-libdnssd-dev
afterwards you can just install the homekit node as described or from the node red UI (At the right top corner of the node red UI there are 3 bars, click them and select manage palette. Search for the homekit node and install)
You now have a homekit node under the advanced section on the left.

Step 2: Add a homekit node and configuring it. (i.e. select the type of accessory, enter the pin, select the service which matches the acessory and give it a name).
Don’t forget to deploy.

Step 3: Add accessory in the home app. On your IOS device add accessory, you should see the accessory appear and can add it in the same way you added the openhab bridge by manually entering the PIN you configured in node red.

Step 4: link the openhab item to the accessory. This is merely a matter of conversion. Node red has an incredible debug window, this will help and below as an example the configuration for the window and the fan from the video.

The switch node detects an ON or OFF and switches based on this

The change node sends the payload in the correct homekit node format below the format for fan on. The fan off one is the same but with payload {“On”:0}

This will make the Home app fan change when the OH items changes.
Now we need to do the same from the Home accessory to OH (the righ hand side of the Homekit node).
The first node is a edit template node. configure it like this

The switch node evaluates the output true of false

And the edit change nodes convert it to an openhab ON OFF

which feeds into the OH item.

The window example is similar but since you don’t change the window in the Home app it only has a left hand side.

The switch node is configured as follows

every switch output has 2 edit change nodes, one for currentposition and one for targetposition. Below the ones for Window open. The window closed ones are the same but with 0 instead of 100 as a value.

I’m sure the conversions can be done in OH as well and probably more elegantly.
Any other type in Homekit is similar it’s just a mater of converting into the right JSON format.
To find out use the debug window and send {“foo”:“bar”} into the homekit node as suggested in the info field the debug window will show you all the variable that are appropriate for the accessory you want to add.


I don’t know if it’s kosher to bump a thread like this, but I just want to say that this is an absolutely fantastic tutorial. I had been using the OpenHAB home kit add-on, but it seems that it has hit a snag with ontology as of iOS 10, 11, etc. I was using my Door Lock with a simple [ “Lighting” ] tag to make it appear as a lightbulb in HomeKit, which worked fine, but was awkward when trying to control through Siri. Using your example as a guide I was able to get my door lock added and fully functional through HomeKit (as a lock)!!!

glad it helped :slight_smile:

I too am surprised this has not become more popular. It looks like Node-Red will solve some of my issues with HomeKit as well as the Rules engine. I hope this gains more traction.

This is great. I’ve had NodeRED installed awhile but haven’t really tried it out yet. This might give me the push to learn how it works.

One of my big frustrations is how HomeKit regularly “forgets” the configurations of my openHAB items; specifically, it often returns my items to the Default room and adds them back to favorites. Has anyone spent enough time with this approach to see if this behavior also occurs when using NodeRED?

Was able to get my new GD-00Z4 garage door opener integrated as well! It’s great to be close to home and ask Siri to open the garage so I can pull right in when I get there!

I found that I had to use the barrier state device on the left side to respond to the 255, 254, 253, 252, 0 states and had to use my remote switch item for on/off (open/close) control from HomeKit. Has anyone been able to find a good way to get Node-Red to only respond to On/Off commands rather than postUpdates as well? It’s made some of my flows a hair more complicated to write since I have to account for a postUpdate.

Not sure I fully understand the question but if Adam’s door is always receiving a command when your garage door opens and you want that to trigger the change in home kit you can use something similar than I do for window coverings.

I use the second output of the OH node and check whether it’s a command (so filtering out all state changes) and switch based on that (in my case here UP, DOWN, STOP but for you ON, OFF).

Does that help.

This is screenshot and the command filter node


Sorry I wasn’t clear. Really it was more of a side note anyway. My garage door operates fine as I’m not checking for on/off in my flow. Rather checking for number states for door position. On some devices, when my rules file processes any postUpdates (to keep basic UI updated with the actual state of a device when it is operated manually) it will run twice.

It doesn’t really affect anything but for instance when the state of my front door is changed anywhere aside from a remote unlock or lock, it sends an unnecessary command. Like when the door is unlocked manually it will also send a remote unlock command right after (which obviously isn’t needed).

Anyway, it was more curiosity because I just turned off the chime in the lock when it receives a command so it goes unnoticed by the rest of the house who has no desire to look at log files! :slight_smile:

Thanks for the tips though! I was scouring through the other node red alternative rules engine thread and tried to incorporate something similar directly into my HomeKit flow but it broke when i did that. I should probably just create a new flow with these suggestions you think?

@ae_0017 Adam, my guess is this is because of the pass-through of the homekit node. What comes in in the homekit node passes through and is probably triggering your OH commands on the right.

You can solve this by filtering on the right only the messages that were initiated by the Home app.

A message that was triggered in the home app contains msg.hap.context . So by adding a Switch node on the output of a HomeKit node to check the property msg.hap.context for is not null should filter out any pass throughs.


How exactly do you filter only messages triggered by the home app? I am facing the same issue that the messages passed through from left to right and sometimes trigger unnecessary commands :blush:

I’m abroad so can’t do screenshots now, will do this weekend if I don’t forget but it’s literally checking if msg.hap.contex is not null. All messages triggered from the home app have this msg.hap.contex value, the pass through messages don’t.

So straight after the HomeKit node put a switch node with 1 exit and set property to msg.hap.contex and set the check to is not null.

This will filter all pass through messages and will pass on all HomeKit initiated ones.

below the screenshots


with these settings:



Hi @rswennen,

thank you so much for this great tutorial. I just wanted to have my 7 radiator thermostats in the Home app. But maybe I’ve overdone this a little bit :wink:

1 Like

indeed impressive but what I start to really appreciate about node red is that despite the fact it’s fairly big for just some thermostats it’s still very readable and easy to understand.
Try doing this in rules without lots of comments and side notes, then put it aside for 6 months and relook at it again and it takes you hours to figure out what you were doing when you wrote it.

So the more I start using node red the more issues I find myself fixing in node red rather than rules (despite the fact that in principle I’m in favor of keeping things simple and in one place).

But indeed impressive (not just the flow but also the fact of having 2 thermostats per room in bedroom and living room) and glad it seems to work out for you

Hi @rswennen!
I´m running the current openhab2 and the up to date nodered.
I tried to expose my Window Contact sensors to homekit as you described in your example - and now there are some difficulties:

Items Fenster Küche comes from openhab and status changes when I open and close the window.
I guess the problem ist Fenster zu and Fenster offen because the string is not correct (I used yours)

I looked up the string in openhab which belongs to my Window Contacts (MAX! eq3).
It´s “contact_state” …do you or anybody knows how I can get this running?!

The problem that i see setup like this (homekit sandwidtced in between of openhab2-in and openhab2-out) is it causes circular loop. i.e. you send a command to test fan via openhab, message is propagated to homekit which will then propagate to openhab2-out and the state will come back in on openhab2-in.

You need to change the payload type to JSON before feeding it to Homekit

This turn out to be easily resolved by adding a function node after homekit node:

if (msg.hap.context !== undefined )
return msg;