Fresh start, OH+Node-RED and UI = HomeKit only

Setup, Configuration and Use Items & Sitemaps
1

I want to use OH for bindings/items and Node-RED for my flows/rules and HomeKit integration.
I’ve installed the MQTT binding in OH and I’ve installed a broker (Mosquitto) and installed NodeRed.
Now comes the hard part, trying to understand what I’m doing here xD
My goal is to have everything working with HomeKit, this way I can control everything with Apple’s Home app, with Siri and with my Apple Watch.

I guess for a switch the basic idea would be that the HomeKit node as input should be sent to the MQTT subscriber (OH) with the command and then the MQTT publisher (OH) should sent the new state to the subscriber (NodeRED) which then informs HomeKit of the new state?

Would it be possible to give some examples on how to do a basic setup of:

  • Switch ON/OFF
  • Dimmer
  • Harmony activity
1 Like
2

While this topic doesn’t necessarily cover using an MQTT broker, it should give you some insight. There is an excellent tutorial about 3 or 4 posts down. I used it to integrate my door lock as a door lock in HomeKit rather than a light switch.

3

I’m operating a bit in parallel to this (though I have 0% experience with Homekit). so will see if I can help. I ended up moving all my zwave control over to HomeSeer and use the HomeSeer MQTT plugin to interface them to Node-Red (my rules engine and connections to things like Harmony and Sonos through contrib nodes) and OH for other bindings and my UI interface through Imperihome (through the items file).

The points I’m unsure on that I’d like clarification before I just start overloading you with suggestions are:

  • Will homekit be directly communicating with the majority of your items or are you going to have the majority communicating through the OH bindings?
  • Will you be using any of the OH UI’s or only Homekit?

Once I have a better understanding of those two pieces I can make some suggestions based on my trial and error.

4

Through OH bindings for sure.
I currently use sitemaps and Paper UI from OH, but I plane to use only HomeKit.

5

These demo videos look promising! Thanks, I’ll read it through.

6

Ok, that helps.

How I’d suggest approaching it then, is to start on the OH side. You can either just map everything to MQTT at the event bus (be sure and define a separate publish / subscribe topic structure (I just add /set at the end of my subscribe topics for OH): http://docs.openhab.org/addons/bindings/mqtt1/readme.html#event-bus-binding-configuration

If you want more granular control, you can do it item by item in your .items file. I’d also strongly suggest leaving retain off on a global basis because it can cause chaos in your Node-Red rules on a restart…

Now in Node-Red I’d start by creating simple linkages between your OH/MQTT items and your Homekit nodes so that any mqtt updates published from OH changes the state of your corresponding Homekit item and any change in Homekit sends an MQTT update to the OH subscription (hence the reason to use the different topic for subscribe / publish topics to prevent logic loops) .

Once you have that setup and fully working you can start adding in your rules in Node-Red where they will send updates to both the OH MQTT items and the Homekit items upon execution.

Hopefully that gives you some ideas on an overall framework, definitely let me know any specific areas that could use better explanation and good luck!! (sounds like a long weekend)

7

So far this is what I have setup for the MQTT binding.

mqtt.cfg
mybroker.url=tcp://localhost:1883

mqtt-eventbus.cfg
broker=mybroker
statePublishTopic=/myhome/state/${item}
commandPublishTopic=/myhome/in/${item}
stateSubscribeTopic=/myhome/out/${item}
commandSubscribeTopic=/myhome/command/${item}/state

These are some of the working items (in the basic UI) I currently have in my items file:

Switch Switch_A "Bamboo Deur" <light> [ "Lighting" ] { channel="rfxcom:lighting4:usb0:switch_17493:command" }
Dimmer DIMMER_TAFEL "Tafel [%s %%]" <slider> [ "Lighting" ] {  channel="zwave:device:52a72468:node2:switch_dimmer" }
String HUB_ACTIVITY "[%s]" <video> { channel="harmonyhub:hub:HarmonyHubFonteinstraat:currentActivity" }
String SceneSwitch "Scènes" <colorlight>
Rollershutter SHUTTERS "Rolluiken" [ "Switchable" ] { channel="rfxcom:rfy:2e084c4c:shutter" }

So the output of NodeRed should got to “/myhome/command/${item}/state” to control a device?
The message in NodeRed should be ON/OFF for switches and 0-100 for dimmers?
Can you give an example of what I use for ${item} looking at the items I have?

8

Let’s start with your MQTT config. Remember that publish is from OH to MQTT and subscribe is from MQTT to OH. I would suggest the following:

statePublishTopic=/myhome/${item}
commandPublishTopic=/myhome/${item}
stateSubscribeTopic=/myhome/${item}/state
commandSubscribeTopic=/myhome/${item}/set

Then from Node-Red if you are sending a command to OH you would publish to the /myhome/${item}/set topic ( state updates for sensors and the like would go to /myhome/${item}/state

The message in NodeRed should be ON/OFF for switches and 0-100 for dimmers?

Correct

Can you give an example of what I use for ${item} looking at the items I have?

In Node-Red a sample out topic would look like(using my proposed structure): /my home/Switch_A/set

9

OK I chaned the eventbus setup (used ‘command’ instead of ‘set’, just a preference) and restarted.

Eureka, I just managed to turn on/off my switch using MQTT and NodeRED, I got here faster than I expected!!

In my test flow I noticed that the buttons I used also have an input field for the topic.
I left them empty since I setup the topic in the MQTT node, but when would one set a topic in the switch itself?

36
Schermafbeelding 2017-12-02 om 09.23.36.png2062×502 42.4 KB

Update
Next up getting the state pushed into NodeRED. I’m pressing the switch and changing the slider through classic sitemap UI, but I don’t get anything in the debug output…

04
Schermafbeelding 2017-12-02 om 18.16.04.png2160×1158 294 KB

11

If you just used a generic mqtt node you could send the topic from the inject node or from a change node in your flow. I prefer just having unique mqtt nodes for my devices. I don’t think it has any impact on overall performance.

To trouble shoot, I’d first double check your mqtt config file, then I’d look at your OH log files (I’d change mqtt to debug), then your mqtt log files (assuming you have them set to verbose) and if everything is tracking there, then your Node-Red log files to see if you can isolate where communication is failing. I think it’s ok to send both state and command to the same topic but you could also change those up to see if I was wrong in that suggestion (been too long since I ran the eventbus version).

Edit: Another good trick is that you can use a wildcard on your inbound mqtt node. Just set it to /myhome/# and change your debug node to full object and you will be able to watch everything that is getting published to mqtt in your debug window

1 Like
12

The issue I have was related to a bug in node-red-contrib-homekit. I fixed it in https://github.com/mschm/node-red-contrib-homekit/pull/58

1 Like