FAQ
Yes. This program has been designed to run alongside either or both of these previous forays into HomeKit so that you can easily and gently migrate your current HomeKit integration to HomeKit Bridge and away from the previous generations. To that end, you can use Wrappers and Aliases from HBB as devices for HomeKit bridge.
It should also be noted that you can Automatically Migrate From Homebridge Buddy and Homebridge-Indigo to HomeKit Bridge.
Eventually Device Extensions will be taking on that role but in a different way. More details on this will be forthcoming but just know that Wrappers and Aliases are not going away and will be, in fact, expanded and enhanced in the very near future.
First off, slow down and don't panic! HomeKit is not instantaneous in it's detection of accessories and it may take a moment before they show up. Go grab a drink and come back in a moment to see if they show up now.
If you recently added and then deleted an accessory in HomeKit then it may just be in limbo, again give it a few minutes to catch up.
If it's still not there then try changing the username by one character and restarting the server, sometimes this is all it takes to prime the pump and get the server to be seen by HomeKit. Worst case scenario is that you may have to create a new server and see if that comes up and if it does then you can transfer the devices from the non working server to the working server.
In the early development of this plugin you will only be able to use what has been defaulted in the plugin. This is to say that you can specify that your Light Bulb is a Lock but if it doesn't have the proper Indigo lock states then don't expect it to work.
The current roadmap has a plan to investigate the possibility of adding more complex device definitions that the user can play with, but it's only a wish list item right now. The reason is that when that time comes the decision has to be made whether or not adding the functionality will in any way compromise the core philosophy of the plugin to only be a server. If the same can be achieved using a wrapper in a different plugin then that may be where this ends up, if it makes more sense to allow advanced users the ability to hyper tweak the device mapping then that will happen.
This is a safety precaution to let you know that you have permanently excluded objects in HomeKit Bridge that will never be shown on any device or action group list again until included again. You get this message each time you start the plugin so that you don't forget that one time you are looking for device and cannot find it on your list that it's in your excluded items. You can manage your hidden items in the plugin menu.
When you shut down Indigo there is a time limit until Indigo forcibly kills the plugin and if you have more than one or two servers then when you restart HomeKit Bridge or disable it then it could take longer than Indigo likes to shut everything down cleanly. Instead the plugin will issue a "Blind Stop" to all servers, which is to say that we are telling them to shut down but are not waiting around to see if it was successful (99.9% of the time it is).
If you disable the plugin then you may see the "Blind Stop" status because the plugin never restarted and thus never changed the status to "Running" again. If you restart the plugin and see that then it's possible that you started up faster than the plugin could shut down the servers, in which case you can simply turn them on or off and they will resume their proper status.
When you restart your plugin one of the first things it will do is check the running status of your servers, so in the vast majority of instances you should never see this status.
All of the devices in HomeKit Bridge have been added from the HAP-NodeJS repository, which is the primary device library for Homebridge (which is what the integration to HomeKit is based upon). To that end, these are devices that have been farmed from the Apple API as valid devices but Apple may not yet have implemented them all in HomeKit. They have been added to the plugin because the hope is that in the future they will be implemented in HomeKit and when they are then HomeKit Bridge is ready to use them.
You can use these devices at any point, HomeKit will simply add "Not Supported" on the icon. You can leave them on your server in perpetuity as well, and when you install a release that supports that device type they will light up and work. There is no harm in having these in HomeKit for now.
My HomeKit device 'X' doesn't show the battery percentage even though the plugin says it should, what's wrong?
In most cases in HomeKit you don't get a battery level, you get a low battery warning, and that is dependent on the plugin prefs for the battery % you set the plugin threshold for (default is 20%). So because if you are at 80% battery you have not tripped the low battery warning. Set your prefs to 90% or something and you'll see an exclamation mark on the icon and you'll get the low battery warning in the details.
Battery level is only supported in a handful of devices at the moment in HomeKit.
In the vast majority of the cases you can simply rely on the console log that Indigo provides for you already (in Indigo go to Window -> Event Log to see it) but the plugin actually logs considerably more to the log files, you won't see these messages unless you turn on debug or thread debug logging via the plugin preferences. However, if you want to see every log item without turning on debug logging you can view them in the standard Indigo log folder (replace the version with your version of Indigo):
/Library/Application Support/Perceptive Automation/Indigo 7/logs/com.eps.indigoplugin.homekit-bridge
You should never really have to manage Homebridge on your own, but if there is a scenario that you think you need to remove the server folder or otherwise play with the configuration you will find it in this location (replace the version with your version of Indigo):
/Library/Application Support/Perceptive Automation/Indigo 7/Preferences/Plugins/com.eps.indigoplugin.homekit-bridge
There are rare circumstances that may require that you delete your plugin preferences for HomeKit Bridge. Such instances might be if your excluded devices get corrupted or you are experiencing strange issues in the plugin and other diagnostics have not helped the problem. Remember that when you remove this preference file that all of your excluded items will return and you must go into your plugin configuration from the plugin menu and save them again or your plugin may not work. For safety you should restart your plugin after removing or renaming (the preferred method) your preference file. You can find the file in this location, note that there will be a folder named almost the same and if you remove that then you will have to restart your plugin so it can rebuild all the server folders again (replace the version with your version of Indigo):
/Library/Application Support/Perceptive Automation/Indigo 7/Preferences/Plugins/com.eps.indigoplugin.homekit-bridge.indiPref
This can happen if something went wrong when you tried to add your Homebridge server to HomeKit or if your HomeKit database has gotten corrupt. The easiest way to resolve this is to change one character of the username and try to add it again. To do this follow these instructions to change one character of the Homebridge username.
A motion sensor detects motion while an occupancy sensor can detect multiple states of attributes such as motion, sound, temperature and infrared. The key difference is that motion tells you when something moved but an occupancy sensor can tell you if whatever moved is still in the proximity of the sensor, even if it is still.
First off, let's define "spike". It's unlikely that your CPU hits much more than 0.6% of CPU (0.3% actual on a dual CPU system), so in the grand scheme of things it's probably not too bad. But it's a spike nonetheless. Think about what HomeKit Bridge is doing: listening for anything from HomeKit and then updating Indigo and also listening for anything from Indigo, then checking if that action is tied to an object that is being sent to HomeKit and THEN if all that is true send an update to HomeKit. That can take a bit of CPU to get there.
There is nothing that really happens when idling. Once every minute or so the plugin will check to see if the HomeKit service is running so it can keep your device list up-to-date and that takes very little. However, each time something happens in Indigo we have to check to see if that something is interesting to us because it's attached to HomeKit so we have to do what is an extremely efficient search of an index, then dig into the object if it's in the index and do some brief calculations on whether or not the something that happened needs to be sent to HomeKit, which will then query Indigo briefly to get a status update before updating your HomeKit app.
When you think about all of that happening, a 0.6% spike isn't too bad of a price to pay for a responsive HomeKit integration. Now if it was pegged at 25% and spiked at 50% then we have a problem.