I use HE just to pair and local control of all my devices, but then use HomeKit for 100% of the dashboard, app control, and voice control of the devices. I also have HomePod Minis and Apple TVs in every room of the house.
My Setup:
HE C-7 > Maker API app > Homebridge server > HomeKit hubs
Works perfectly, enjoying native Apple control of everything but also having access to hundreds of quality devices that don't carry the native HomeKit price tag.
Weird. I have two instances of HomeBridge, using @dan.t's MakerAPI integration. They're rock solid. No crashes, no bugs. Just work. The only HomeBridge plug-in I'm using is @dan.t's.
Same here.
Same, Maker API to Homebridge has been ROCK solid, zero issues, never crashed once in months.
Well, maybe I'm doing something wrong on the HOOBS/Homebridge side. I really like the comment from @lawsonad, that's exactly what I want to be able to do.
Right now all my home devices are 'native' in HE, by which I mean that I included each of them one by one directly, and I've done some simple automation scripting using HE, like turning on outside lights when it's sunset, changing illumination levels at night, etc.
When you @lawsonad say that you use HomeKit for 100% of the dashboard, where are your scripts running? On the HE, correct?
Would anyone here be willing to help me figure out how to do this?
Thanks in advance.
Sure. I don't use HOOBS, I use homebridge-config-ui-x, with these instructions to setup HomeBridge:
Most of my automations are done in Hubitat (actually Node-RED, but that doesn't matter). I used these instructions to setup the MakerAPI integration:
I don't use HE dashboards, but instead use the native Home app on my Apple devices to see status of my HE paired devices. As for scripting or automation, I do 98% of my automation programming in HE using Simple Automation Rule app, Rule Machine app, and Mode and Motion Lighting app. The only automations I do natively in HomeKit is ones that play sounds on my HomePod Minis (doorbell chime, HSM siren, etc).
Hope that helps.
My next project is stand up a true VM server and break apart my Homebridge into multiple instances. I've read multiple times that having one large Homebridge instance for all your devices can slow down the device refresh from HomeKit as it has to refresh every device per hub instead of selectively on a per device basis.
I have a fairly large system and try to keep individual instances to under 100 devices.
I just broke 50 devices in Homebridge, slowly growing since Oct 2020.
Here's the thing, and you should consider this an opinion, but it's not based on guesses, but knowledge from other companies that have done this. Commercial HomeKit licensing is expensive. So do I want Hubitat to sink their limited resources in paying Apple licensing fees for HomeKit commercial use? Big fat NO!
Adding Homebridge is simple and it's cheap for the end user. Something is wrong in your setup if it's unreliable. I have been using Homebridge with @dan.t 's MakerAPI plug-in as @aaiyar mentioned, for years. It should be working perfectly. If it's not then you have something wrong on your network and/or the computer that is running Homebridge.
With Apple HomePods as the hub, you can expose virtual switches to Homebridge and sync them to devices that are exposed to Homebridge, but are not directly HE compatible. To simply control devices that are already in Hubitat from Siri, you simply expose them to Homebridge, and then add Hombridge to HomeKit as an accessory, allowing all devices in Homebridge to be exposed to the HomeKit cloud.
Now if you're expecting to be able to get measurement data from things like temperature sensors that are HomeKit compatible, but not directly HE compatible, then you cannot do that with Homebridge. I would instead look at this project that will allow the use of HomeKit Controller in Home Assistant and bring those devices into HE. If you wanted to, you could potentially eliminate the use of Homebridge by also exposing devices from HE back to HA with this second integration and then use the HA HomeKit integration. That is different from their HomeKit Controller integration in that it exposes devices to HomeKit, rather than acting as a HomeKit bridge.
Both are simple to setup, and frankly although I find HA difficult to automate in, the good thing about the HA to HE integration is you don't have to. In fact, whether you're using the HomeKit controller integration or joining devices directly to HA to get them back into HE, it's only when joining a device that you ever need to touch HA. Setting up HA on a RPi or a virtual machine running on spare computer is very simple because they have created a ready-to-use image.
So you may be wondering, if HA can add HomeKit integration, why doesn't HE just do that. Well they could, but it would cost them a lot, and in turn it would likely either drive the cost of the hub higher (nobody wants that), or it will rob valuable resource from a small company for little benefit versus the easy to add Homebridge or HA. Since HA is an open source project, they fall under the non-commercial use category and so don't have to pay anything, and don't have restrictions. Same with Homebridge which uses the HomeKit APK. Although, I wonder about that long term, as HA does sell a version already installed on an ODROID-N2+, which constitutes commercial use, so they're actually breaking the rules a little.
I'm getting the same results as everyone else.. my instance of Homebridge has been rock solid since I began using @dan.t solution. I also run Node-Red on the same machine. Both are NodeJS apps and as a result they just seem to go on and on working every day for a very long time. (The date stamps on the directories on my computer holding Homebridge is Jan 2019. Node-Red is April 2020 ) I do have multiple instances of Homebridge, for no reason other than I can. 
I have a Thermostat and have a Homebridge instance dedicated to it. Mostly I just wanted to understand how-to and now I know. 
NodeJS can run on almost any Always-On Computer.. many use a Raspberry, as I did to first get my feet wet. Once I determined that I would be using it 'forever' I moved it to run on a Mac Mini that began life as a Media Server.
I’m running mine on a 2009 iMac. Probably a bit of a power hog but there is a bunch of other home automation stuff running on the same machine.
If you're a Mac user and have either the budget for a new Mac to be always on, or have an old Mac around (I'm using a 2011 MacBook Pro configured to stay running with the screen closed), it's a powerful, stable and low power consumption platform to run many things on at once.
My MacBook Pro is currently running Node.js for Google Assistant Relay, Insteon server, Homebridge, Google CastWeb API, and Virtual Box running a HASS.IO image. No slow downs. Bonus for a Mac household is you can easily access it with the built-in screen sharing. I'm also running TeamViewer should I ever need remote access to anything on the MacBook or any of my HE hubs via a browser on that MacBook Pro.
If you have reason for a computer to be always on before jumping into Homebridge or Node-Red, adding several NodeJS instances seems to be one of the easiest decisions around.
Not sure about the Mac Mini, but the 2011 MacBook Pro I'm running everything on only consumes 5 watts.
The Mac Mini is pretty much a laptop in a different shape box without screen or kbd. So the power is very low. I have 4 of them running in this room alone, with two more running in a different room.
At least once a month I'm checking ebay for slightly newer. Mine are a 2012 and four 2014 vintage Mini's, only one is a 2018 version.
I used to use TeamViewer as well but found that Apple's built in screen sharing works great without having to rely on a cloud based connection.
I had problems with HOOBS but have been running Homebridge on a Rasberry Pi (pre-built image) for almost a year. It’s been very stable. However, I use very few plugins - just Hubitat and Ring. All my devices are controlled from Apple Home but automations are in HE and/or Node-red. I have no HomeKit devices.
Download the Hubitat app
