"Official" HomeKit integration

I expose only switches/dimmers and Fans to Homebridge. Plus one Door Lock and two Presence Sensors.

Only the things I feel I'll need to tap to "fix" something. I don't use it to debug, so I don't care to know about sensors, etc.

My homebridge server is a Mac Mini, but I had a day where that got broken and I quickly deployed a rPi while I got the Mini working right. I doubt it took an hour to get the rPi to run.

My primary use for HomeKit is presence sensor. Everything I need to have that work, gives me all the switches and fans 'for free'. :slight_smile:

If I had to review the last 100 times I used Home App, it would be a) to test that the latest edit, is in fact working, (30 times) and b) fighting with my kids to turn off their bedroom light because it's bed time. (70 times) :smiley:

2 Likes

Appreciate your response and like the way you think :joy: I ordered the hub, just want local but less time consuming then Home Assistant.

2 Likes

Hubitat is exactly that then.

After flipping a bunch of breakers today I really hope this comes one day.
All of my Homebridge device rooms reset again.
I thought I was past those days.

We lost power yesterday for about an hour and experienced the same thing. All my rooms favorits etc were reset in the Home app. Strangely the order of the buttons stayed the same. Real pain to set them all back again. Not sure why when I reset the hub and rPi separately this doesn't happen. Must have something to do with the order they boot up? I know the rPi boots faster than the hub and maybe that's what resets it? Never seemed to happen back when I was on Vera.

1 Like

There's been discussion on this but I haven't seen a cure. It revolves around the .homebridge/persist/ files, apparently:

~/.homebridge/persists/IdentifierCache.xxxxxxxxxxxx.json is used to persist the mapping of (long) UUIDs to (short) AIDs (for accessories) and IIDs (for services and characteristics) used in the HAP protocol. If you run DEBUG=* homebridge -D, the HAP calls are logged, including the AIDs and IIDs.

I think that boot order is an element because I read that if the UUID isn't available, a new one gets created.

A wild guess: homebridge boots but the Hubitat App isn't avail to send it the device list. Homebridge, when it connects to HomeKit has nothing to offer and it clears out /persist/

Recovery of /persist/ has been a common "cure."

1 Like

I need to make rolling backups. ..

That makes perfect sense. I'll just have to make regular backups of that folder and hopefully restoring it will put things back in order.

1 Like

+1 - Would love to see this.

I’ve been using Homebridge since the beginning. The only time I see it having any effect on HE is when there is a communication issue between Homebridge and HE. That results from a change to the Homebridge for Hubitat app, from shutting down Homebridge for an extended period (generates many errors in HE), or reboot HE without rebooting Homebridge.

Aside from that, I’ve been unable to connect Homebridge to any slowdowns or Hub lockups.
Each night my hub become very slow between 1am and 3pm. I’ve yet to find the cause. Reboot to Homebridge, or shutting down Homebridge when the slowdown is occurring has not changed anything.

So, can HE team put efforts into HomeKit support? Yes of course they can, especially with the relaxation of the requirements on Apple’s side. But Apple HomeKit as an important home automation platform is not proven. This from a long time MacOS and iOS user, so if you think I’m biased towards another operating system, you’d be wrong.

1 Like

Similar experience....

I used Homebridge on ST and as soon as it became available on Hubitat, I've been using it. Three times in the past year, I heard the 'rumor' that Homebridge was the cause of slowdowns and to avoid it, I removed Homebridge. Since 1) slowdowns didn't go away, and 2) I missed HomeKit, I'd brought Homebridge back to my Hub.

Since I've converted to three hubs and Homebridge is on the third "coordinator hub" I continue to NOT have any incidents that I can blame on Homebridge. In other words, for a year, I've used Homebridge and other than the 2-3 month cumulative time I had it removed prophylacticly it's always worked. One shift has occured over the year's time though.. I started with a Dashboard approach to Homebridge and kinda selected all. Hubitat's dashboard is good enough for my needs and so since the last time I restored HomeBridge, I only select switches, dimmers and outlets. Garage Door Opener and Presence round out my list. I have no motion or door sensors, etc being sent to HomeBridge. Maybe that's contributing to my high stability, maybe my third hub is, maybe it's just my generally pleasant demeanor ... ok, yea, can't be that.

I believe that one day, Hubitat's engineers will find themselves so short of challenging things to do, that they will tackle HomeKit...

1 Like

. . . in their spare time.

I'd really like to control HomeKit compatible devices from Hubitat, with official support.
Got nothing against the community, but I can't really build a smart home solution for a couple of customers without it... Also this seems to be one of the most sought after features in our Hungarian DIY Smarthome facebook group...

I use HOOBS/Homebridge using @dan.t's amazing Hubitat Maker API plugin and it works great. There is zero custom code on the Hubitat hub to accomplish this. I really don't see Hubitat fully supporting HomeKit any time soon...but I would welcome that as well. We can hope, right? :wink:

3 Likes

If you haven't checked it out recently, I'd recommend looking at the new Homebridge plugin that uses Maker API: New Homebridge Plug-in via MakerAPI

With the old plugin/app, I had all the problems:

  • homebridge locking up and having to reboot my rPi
  • weird timing bugs
  • Once a month, it would make HomeKit forget what rooms all my devices were in.

Ever since switching to the newer plugin, I have had 0 issues. I haven't had to reboot my rPi even once, and it has never forgotten the rooms. I haven't compared the code of the two, but I believe the new one must be a much more robust architecture. (and no shade to the folks who wrote the first one. This stuff is not easy and they did it for free)

4 Likes

To be clear, you want to control HomeKit devices directly from Hubitat, not mimic HomeKit devices managed by Hubitat?

Do note that the above integrations are the opposite direction: Hubitat to HomeKit. It sounds like you want HomeKit to Hubitat. That is not currently supported, either, and the only workarounds I can think of (unless the device also natively supports Hubitat) would be to use the existing integration plus a "shadow"/"virtual" device to mirror as much functionality between the two platforms as possible.

Not fun, but possible. :slight_smile: Does Apple have an official way for non-iOS systems to control HomeKit devices? That's the only thing that would make the other direction natively possible, and even then I'd still consider it unlikely to be official any time soon on the Hubitat side.

2 Likes

Exactly, like the HomeKit Controller that can be found in Home Assistant.

The devs at Home Assistant were able to do this. I'm not sure about the exact implementation as I'm not familiar with python, but here is the repo for it: core/homeassistant/components/homekit_controller at dev · home-assistant/core · GitHub for inspiration :wink:

Privacy wise... it would be a killer and enable "native integration" for a whole new range of devices. For example: one of Europe's most prominent electrical manufacturers, Legrand just got into the smart home business with it's Netatmo line-up. Their solution is Zigbee based, but the gateway translates to homekit on LAN.
To go further, IKEA's Trådfri can also communicate over HomeKit...
You probably get my point :slight_smile:

I really love the mentality behind Hubitat and HomeKit is a local protocol (one thing that Apple did right...), it seems to be a big thing to miss out on.

5 Likes