HomeKit Accessory Protocol (HAP) is Apple’s proprietary protocol that enables third-party accessories in the home (e.g., lights, thermostats and door locks) and Apple products to communicate with each other. HAP supports two transports, IP and Bluetooth LE. The information provided in the HomeKit Accessory Protocol Specification (Non-Commercial Version) describes how to implement HAP in an accessory that you create for non-commercial use and that will not be distributed or sold.
The HomeKit Accessory Protocol Specification (Non-Commercial Version) can be downloaded from the HomeKit Apple Developer page.
HAP-NodeJS is a Node.js implementation of HomeKit Accessory Server.
With this project, you should be able to create your own HomeKit Accessory on Raspberry Pi, Intel Edison or any other platform that can run Node.js :)
The implementation may not 100% follow the HAP MFi Specification since MFi program doesn't allow individual developer to join.
Remember to run npm install before actually running the server.
Users can define their own accessories in: accessories/name_accessory.js files, where name is a short description of the accessory. All defined accessories get loaded on server start. You can define accessories using an object literal notation (see Fan_accessory.js for an example) or you can use the API (see below).
You can use the following command to start the HAP Server in Bridged mode:
node BridgedCore.jsOr if you wish to host each Accessory as an independent HomeKit device:
node Core.jsThe HAP-NodeJS library uses the debug library for log output. You can print some or all logs by setting the DEBUG environment variable. For instance, to see all debug logs while running the server:
DEBUG=* node BridgedCore.jsHint: the Homekit Application Protocol (HAP) allows that you can pair a Homekit device with one device. As soon as the Homekit device is paired, its not possible to pair with another iOS device anymore.
HAP-NodeJS provides a set of classes you can use to construct Accessories programatically. For an example implementation, see Lock_accessory.js.
The key classes intended for use by API consumers are:
- Accessory: Represents a HomeKit device that can be published on your local network.
- Bridge: A kind of Accessory that can host other Accessories "behind" it while only publishing a single device.
- Service: Represents a set of grouped values necessary to provide a logical function. Most of the time, when you think of a supported HomeKit device like "Thermostat" or "Door Lock", you're actualy thinking of a Service. Accessories can expose multiple services.
- Characteristic: Represents a particular typed variable assigned to a Service, for instance the
LockMechanismService contains aCurrentDoorStateCharacteristic describing whether the door is currently locked.
All known built-in Service and Characteristic types that HomeKit supports are exposed as a separate subclass in HomeKitTypes.
See each of the corresponding class files for more explanation and notes.
Special thanks to Alex Skalozub, who reverse engineered the server side HAP. You can find his research at here. (Sadly, on Nov 4, Apple sent the DMCA request to Github to remove the research.)
There is a video demo running this project on Intel Edison.
If you are interested in HAP over BTLE, you might want to check this.
- Homebridge - HomeKit support for the impatient - Pluggable HomeKit Bridge. Plugins available for e.g. Pilight, Telldus TDtool, Savant, Netatmo, Open Pixel Control, HomeWizard, Fritz!Box, LG WebOS TV, Home Assistant, HomeMatic and many many more.
- OpenHAB-HomeKit-Bridge - OpenHAB HomeKit Bridge bridges openHAB items to Apple´s HomeKit Accessory Protocol.
- homekit2mqtt - HomeKit to MQTT bridge.
- pimatic-hap - Pimatic homekit bridge.
- node-red-contrib-homekit - Node-RED nodes to simulate Apple HomeKit devices.
- ioBroker.homekit - connect ioBroker to HomeKit.
- AccessoryServer - HomeKit integration for IR/RF/IP-devices