Native Homekit support

[JohnMaree]

It is well known at this stage that the Homekit API has been available for developers. I have coded a few things with it myself for the esp8266 module and was wondering if this library uses any Homebridge-exclusive functionalities that cannot be adapted into a native solution. I think it would be a cool side project to work on as relying on a server is obviously less ideal than native support.

[taligentx]

Hi @JohnMaree - native HomeKit support would be excellent! The HomeKit example sketch doesn't use any Homebridge-exclusive functions - as far as I've checked, Homebridge seems to provide a fairly straightforward intermediary to HomeKit without introducing its own processing logic.

One of the design goals for the library is to be implementation-agnostic - it will provide status and virtual keypad but otherwise the rest is up to the sketch and other external software.

In the past I've looked through ESP8266-HomeKit and esp-homekit-demo to see what would be involved in a native solution - the priority has been decoding the Keybus so porting the library to another framework is a maybe on the todo list. Which framework are you targeting?

[JohnMaree]

Hi! Thanks for the timely response!

Okay, its amazing to hear it doesn't have any custom homebridge functions! I based what I learnt from the Homekit API from esp-homekit-demo and built my own codes from that (with OPEN-RTOS of course) and the pdf provided by apple. If by framework you mean what type of alarm system - I have the P1616 series. I haven't hooked it up to any of the sketches yet but ill try do so by today.

In terms of implementing - the HomeKit API essentially only needs status feedback from your various functions in your library and the ability to send commands. Which I know you have already achieved with Homebridge. I have played with Homebridge in the past but am not all that confident with its various ways of assigning accessories, services etc..

I think it would be cool to at least have an example or proof of concept that this library can just be implemented into a native solution. I suppose the goal would be to have an ESP8266 that you can just add to the Alarm system and wouldn't be dependent on a server.

I have attempted going through some of your Keybus code as understanding what each function does is important and I couldn't find much in the ways of a comprehensive documenttion on it, but I pretty much got overwhelmed very quickly, you have really got an extensive library here and admittedly you seem to be a maestro with the coding aspect of it. I will carry on going through the library and seeing how one can possibly use the functions in a native HomeKit sketch!

Impressive stuff though!

[taligentx]

If you're looking at esp-open-rtos, is there a way to include the Arduino framework so you can compile Arduino libraries directly? It'd be nice if it was as easy as including Arduino.h but I suspect there is more to it. Otherwise the library would have to be re-written to substitute the Arduino-specific functions like digitalRead, attachInterrupt, bitRead, etc.

As far as the code, the function and variable names are verbose to help the code be more self-documenting, along with comments in most blocks of code. I'm a fan of documentation so feel free to point out where the code is unclear and I'll clarify.

As a general overview, there are a few different components:

• Data capture: dscClockInterrupt() and dscDataInterrupt() in dscKeybusInterface.cpp capture Keybus data using hardware and timer interrupts.
• Data writing: dscClockInterrupt() and write() in dscKeybusInterface.cpp handle writing keys to the panel for the virtual keypad.
• Processing: handlePanel() and handleModule() in dscKeybusInterface.cpp and the functions in dscKeybusProcessData.cpp extract information from the raw Keybus data and store the results in the variables and arrays you see used in the example sketches.
• Printing: dscKeybusPrintData.cpp is purely to help decode the Keybus protocol through the KeybusReader sketch and is not used at all by the Status example sketches.

It'd be great if the esp8266 could operate as a standalone HomeKit device, let me know if I can provide additional info or if there are adjustments needed in the library.

Edit: typo

[JohnMaree]

Unfortunately I have yet to see the Arduino library show up under the "Include" folder in esp-open-rtos. I also use esp-open-sdk which too doesn't seem to have the Arduino Library included. However I will do some digging as to whether this can be done (I admit it would be nice).
There are in-fact similar functions which do those exact Arduino functions that you mentioned, I'm not sure about the naming convention however unless your library and headers were coded with the Arduino.h library I am sure this shouldn't be too much of an issue. - Even so, find-and-replace saves lives ;-).

Thank you! I will let you know should I need any further explanations! That short list you posted has helped greatly summarise the main functions I will need. I was wondering however. I notice that you place the virtual Keybus as "optional". Does this mean that if you only want to monitor the status of your alarm, one would exclude the Keybus, but if one would like to Arm or Disarm the alarm you would need the Keybus? (This question is bases off of my limited understanding of alarm systems mind you).

To be clear, when going through the example status code for Homebridge:

1. Are the partitions (1, 2, etc.) controlled by a single accessory. i.e. Does one ESP8266 accessory control the commands for partition 1 and partition 2?

2. Are the commands 1A, 2A, etc. simply made for the mqtt plugin to distinguish between partitions or is it an apple required command which it uses to distinguish partitions?

I am ever so slowly going through code during my spare time in hopes to get this HomeKit integration working well so I apologise if it takes a long time. Trust me, I'd much rather have this done sooner rather than later! However advice or guidance by anyone more knowledgeable in this field is always welcomed!

[taligentx]

Actually Arduino.h is included as this library does use Arduino framework-specific functions. It follows the Arduino Style Guide and uses data types like byte instead of uint8_t, etc. If Arduino libraries can't be compiled as-is, the Arduino-specific functions would need to be ported to equivalents in esp-open-rtos. As you said, find & replace can take care of some of it. From a quick look it seems like some replacements are straightforward (gpio_write replaces digitalWrite and so on).

You're correct about virtual keypad - this is to send keys to the panel to control it (arm/disarm). Without virtual keypad, you can still read the full status and events of the alarm system.

Are the partitions (1, 2, etc.) controlled by a single accessory. i.e. Does one ESP8266 accessory control the commands for partition 1 and partition 2?

Each partition is setup in HomeKit as a separate Security System object - so if the DSC panel has 8 partitions, HomeKit would have 8 Security System objects that would show up as 8 separate accessories that can be individually armed/disarmed/triggered.

The zones are separate from the partitions, each zone can be setup as a Contact Sensor, Smoke Sensor, etc.

Are the commands 1A, 2A, etc. simply made for the mqtt plugin to distinguish between partitions or is it an apple required command which it uses to distinguish partitions?

This is only to distinguish the partitions between homebridge-mqttthing and the Status-MQTT-Homebridge sketch. The esp8266 MQTT client only subscribes to one topic, so the commands need to include the partition number to act on (instead of subscribing to a different topic per partition).

I view open source projects with an understanding that contributions are based on available interest and time - so no worries on the time scale. Sounds like a great way to get experience with RTOS on esp8266!

[taligentx]

Are the partitions (1, 2, etc.) controlled by a single accessory. i.e. Does one ESP8266 accessory control the commands for partition 1 and partition 2?

I just realized you may have meant the hardware - a single esp8266 module connected to one DSC panel can handle up to 8 partitions and up to 64 zones.

[JohnMaree]

Yea that is indeed what I meant. Thank you for clarifying! This is turning out to be fairly complex but I do think with time I can get this going

[taligentx]

@JohnMaree This is up and running!