maximkulkin / esp-homekit Goto Github PK

During some experiments with the framework using the demos I´m observing a behavior I´m not sure its the expected.

I compiled the example with DEBUG ON, after reboot, pairing and normal configuration I observed that each time the HomeApp is opened in my iPhone the heap in the code running in my test device is reduced by aprox. 48 Bytes in average. Actually if between open and closes of the homeApp I wait about 30 secs the 48 bytes of reduction is quite constant, what is sure is the memory lost is not recovered by waiting any longer.

After some days of operation the code crash and the device in most of the cases is unable to reset itself and hang showing no response in the HomeApp.

Second fatal exception occured inside fatal exception handler. Can't continue.
ets Jan 8 2013,rst cause:1, boot mode:(1,6)
ets Jan 8 2013,rst cause:4, boot mode:(1,6)
wdt reset

Steps to reproduce:

1. Boot device
2. Open HomeApp, note heap size
3. wait 30 secs
4. Close HomeApp
5. Wait 30 Secs
6. Open Home App, note heap size reduced
7. Repeat from 3

Seems like the leak is at the homekit_server_on_get_characteristics function, but I´m not sure of this.

Attached a log showing the heap going from 12124 to 11000

HomekIt_Leak.txt

Today I witnessed that you have a 'trap' in your state machine.
If for some reason (I have traced one) the verify step of the pairing process is not executed, then the device is considered paired and refuses to pair again.

Please see my repo for the use of the half-paired concept of how to solve it.
Summary: only consider pairing official once the GET /accessories URL has been received (and maybe even deeper in the flow, like the identify that seems to be triggered always nowadays.)

>>> HomeKit: Configuring mDNS
>>> HomeKit: [Client 4] Successfully paired
>>> homekit_client_process: [Client 4] Finished processing
>>> HomeKit: [Client 4] Closing client connection

no verify step follows, and after 22 seconds, iPhone starts again with step1/3

>>> HomeKit: Got new client connection: 4
>>> homekit_client_process: [Client 4] Got 125 incomming data
>>> homekit_server_on_pair_setup: Pair Setup
>>> homekit_server_on_pair_setup: Free heap: 35896
>>> tlv_debug: Got following TLV values:
>>> tlv_debug: Type 6 value (1 bytes): \x01
>>> tlv_debug: Type 0 value (1 bytes): \x00
>>> HomeKit: [Client 4] Pair Setup Step 1/3
>>> homekit_server_on_pair_setup: Free heap: 35800
>>> HomeKit: [Client 4] Refusing to pair: already paired
>>> send_tlv_response: [Client 4] Sending TLV response
>>> tlv_debug: Got following TLV values:
>>> tlv_debug: Type 7 value (1 bytes): \x06
>>> tlv_debug: Type 6 value (1 bytes): \x02
>>> client_send: [Client 4] Sending payload: HTTP/1.1 200 OK\x0D\x0AContent-Type: application/pairing+tlv8\x0D\x0AContent-Length: 6\x0D\x0AConnection: keep-alive\x0D\x0A\x0D\x0A\x07\x01\x06\x06\x01\x02
>>> homekit_client_process: [Client 4] Finished processing
>>> HomeKit: [Client 4] Closing client connection

The (current) code you use is not handling mdns correctly and is very very slow.
an iPhone taken by a user will emit an mdns query and it takes up to two seconds before it even starts emitting a TCP SYN packet. This should be like 100ms max.

Also, the current code does not comply to the rules of an mdns responder. It answers those queries that it shouldn't (if our name is already in the answer section) and it omits the transmission of its existence at startup and TTL expiry.

I also value open code reused from others, but considering the very limited mission this mdns responder has to deliver, I would appreciate the possibility by using a #define to use my mdns code instead of the current one. I'll be glad to explain why it works, e.g. in a wiki page.

I will start off by saying this is an edge case, but automations and notifications become unreliable if you have a lot of devices connected to HomeKit. I've just seen this happen at our office.

What happened:

• esp-homekit supports a maximum of 8 sessions.
• 8 clients had a session with the accessory, with the Home Hub being client 4.
• Client 4 (the home hub) closes its HAP session (this seems to be normal behavior)
• A new client started a session a few seconds after. Causing it to take the spot of the Home Hub
• The Home Hub tries to start a session again 30 seconds after closing its connection, but the accessory doesn't allow any new sessions anymore.

I think this issue exists because esp-homekit currently only supports a max of 8 sessions while the specs call for a minimum of 16 sessions. I think that HomeKit has a mechanism that activates once 16 sessions has been reached, probably routing new sessions through the home hub or other clients. But since we never even allow 16 sessions, this mechanism never starts working.

Edit Jan 16 2018: Updated wording of pairing vs sessions

Are there any examples or can someone provide an example on how to get a speaker working with this library?

I wonder if there exists some callback to let user know when the accessoire is ready, such as pairing process has been successfully done, ..

This callback is really helpful to initialize other tasks, for example, creating a task to read PIR status, ... These tasks cannot be started at beginning as they will take memory, then, there exists very less memory for homekit paring.

Could you please advise me what to do?

Hi,

The use of the area from 2Mbyte up is not compatible with the use of devices build by Sonoff which are probably our biggest target for real life deployment. Personally I would use 0x7A000 as being compatible with such devices and allowing FOTA strategies

HI, I have my accessories shared with a some of the family, seems when any of those additional clients connects, my accessory crashes:-

target temperature set to : 17.000000
Target set to on

HomeKit: [Client 4] Update Characteristics

target temperature set to : 16.500000
Target set to on

HomeKit: [Client 4] Update Characteristics

target temperature set to : 16.000000
Target set to on

HomeKit: [Client 4] Update Characteristics
HomeKit: [Client 4] Update Characteristics

target heating cooling state set to : 3
Target set to auto
Target Auto, current now off, current temp 19.500000, target temp 16.000000

HomeKit: Got new client connection: 5
HomeKit: [Client 5] Pair Verify Step 1/2
HomeKit: [Client 5] Pair Verify Step 2/2
HomeKit: [Client 5] Found pairing with 856FCE22-3DA1-4066-A021-BC1A1DC64344
HomeKit: [Client 5] Verification successful, secure session established
HomeKit: [Client 5] Get Accessories
Fatal exception (28):
epc1=0x4000bf80
epc2=0x00000000
epc3=0x4020349d
excvaddr=0x00000000
depc=0x00000000
excsave1=0x40002ad0
Registers:
a0 40002ad0 a1 3fffc3e0 a2 00000000 a3 fffffffc
a4 000000ff a5 0000ff00 a6 00ff0000 a7 ff000000
a8 0000001f a9 00000022 a10 00000002 a11 0000005c
a12 000000c8 a13 00000000 SAR 00000018

Stack: SP=0x3fffc3e0

Free Heap: 4796
_heap_start 0x3fff1ba8 brk 0x3ffff388 supervisor sp 0x3ffffb00 sp-brk 1912 bytes
arena (total_size) 55264 fordblks (free_size) 2884 uordblocks (used_size) 52380

When accessory starts blank slate, it starts in pair setup mode allowing any controller to pair with it. mDNS TXT has "sf=1" record. After initial pairing, pair setup mode should be disabled, accessory should refuse to pair and mDNS TXT should have "sf=0". Vise versa, after removing last (admin) controller, accessory should switch back to pairing mode and announce that through mDNS.

Unfortunately, current mDNS library does not support run-time reconfiguration and should be extended/replaced to support that. It seems that "lwip" library already has support for mDNS and it would be beneficial to reuse that one instead of custom library that we use now.

Task is to

1. implement mDNS responder based on lwip library
2. add calls to mDNS reconfiguration when pairing is done/removed

After I upload code to the magic home controller it outputs the following and I can't pair any devices.

>>> HomeKit: Starting server
!!! HomeKit: Failed to read flash magic
>>> HomeKit: Formatting flash at 0x100000
!!! HomeKit: Failed to erase flash
>>> HomeKit: Generated new accessory ID: E3:07:15:6F:9F:3E
!!! HomeKit: Failed to write accessory ID to flash
>>> HomeKit: Generated new accessory key
!!! HomeKit: Failed to write accessory key to flash
Function called without core lock

Function called without core lock
Function called without core lock
Function called without core lock
Function called without core lock
Function called without core lock
Function called without core lock
Function called without core lock
Function called without core lock

I tried to add it manually to the esp-homekit folder but it doesn't gets picked up when I run make menuconfig

I'm trying to upload to a magic home led strip controller and on boot it outputs

HomeKit: Starting server
!!! HomeKit: Failed to read flash magic
HomeKit: Formatting flash at 0x100000
!!! HomeKit: Failed to erase flash
HomeKit: Generated new accessory ID: E3:07:15:6F:9F:3E
!!! HomeKit: Failed to write accessory ID to flash
HomeKit: Generated new accessory key
!!! HomeKit: Failed to write accessory key to flash

I found a little challenge at led_status example (line 6):

void on_event(homekit_event_t event) {
    if (event == HOMEKIT_EVENT_SERVER_INITIALIZED) {
        led_status_set(led_status, paired ? &normal_mode : &unpaired);
    }
    else if (event == HOMEKIT_EVENT_CLIENT_CONNECTED) {
        if (!paired) //<- Here is the little unexpected comparison
            led_status_set(led_status, &pairing);
    }
    else if (event == HOMEKIT_EVENT_CLIENT_DISCONNECTED) {
        if (!paired)
            led_status_set(led_status, &unpaired);
    }
...
}

I would have expected at line 6:

  if (paired) // not (!paired)
      led_status_set(led_status, &pairing);

How setup camera?

Please help

Hi,

we're considering using this implementation on a linux based system. Would you generally be opposed to adding a whole bunch of ifdefs for posix compatibility?

Please add support bridge feature of HomeKit, so on esp32 we can host multi accessories with single server.
and add demo how to use.

Hello,

Do you think it is possible to have this library as standalone component (a library, precisely) to embed into another kernel for ESP8266, such as for instance Arduino Core?

We want to use it in our devices, but we don't plan to change the underlying kernel

Best regards
Paolo

In some situations when the accessory is first power up clients like the Apple TV or the iOS Home App will not connect immediately (HomeApp connect after open it), this limits the ability for the accessory to send events on power up.

From the logs I have taken I was able to find that after some time there seems to be an incoming client connection and after that notifications and automations start working properly (Have not yet measured if this time is constant)

I have not been able to find any public functions to rebroadcast accessories or verify if it's already connected in order to hold the event broadcast until the accessory is really connected to a client, without this power up event get lost.

I observed something that might be a bug or an undesired feature (IMO).
I would say that when a specific phone sets the value, it should not receive an event of this.
Also, when setting up a new client context, I notice it happens twice in a row. Maybe that makes the event gets send to self?

In the log below, I added a 200ms repeating Task that reports heap and time...

--27868@0012869ms
>>> HomeKit: Got new client connection: 4
...
>>> HomeKit: [Client 4] Verification successful, secure session established
>>> homekit_client_process: [Client 4] Finished processing
--24268@0014069ms
>>> homekit_client_process: [Client 4] Got 84 incomming data
>>> homekit_client_process: [Client 4] Decrypting data
>>> homekit_client_process: [Client 4] Decrypted 66 bytes, available 0
Decrypted data (66 bytes): "GET /accessories HTTP/1.1\x0D\x0AHost: Sample\\032LED._hap._tcp.local\x0D\x0A\x0D\x0A"
>>> HomeKit: [Client 4] Get Accessories
>>> homekit_server_on_get_accessories: Free heap: 25876
>>> send_json_response: [Client 4] Sending JSON response
>>> send_json_response: [Client 4] Payload: {"accessories":[{"aid":1,"services":[{"iid":1,"type":"3E","hidden":false,"primary":false,"characteristics":[{"aid":1,"iid":2,"type":"23","perms":["pr"],"description":"Name","format":"string","value":"Sample LED"},{"aid":1,"iid":3,"type":"20","perms":["pr"],"description":"Manufacturer","format":"string","value":"HaPK"},{"aid":1,"iid":4,"type":"30","perms":["pr"],"description":"Serial Number","format":"string","value":"037A2BABF19D"},{"aid":1,"iid":5,"type":"21","perms":["pr"],"description":"Model","format":"string","value":"MyLED"},{"aid":1,"iid":6,"type":"52","perms":["pr"],"description":"Firmware Revision","format":"string","value":"0.1"},{"aid":1,"iid":7,"type":"14","perms":["pw"],"description":"Identify","format":"bool"}]},{"iid":8,"type":"43","hidden":false,"primary":true,"characteristics":[{"aid":1,"iid":9,"type":"25","perms":["pr","pw","ev"],"ev":false,"description":"On","format":"bool","value":false}]}]}]}
>>> send_json_response: [Client 4] Sending HTTP response: HTTP/1.1 200 OK
Content-Type: application/hap+json
Content-Length: 926
Connection: keep-alive

{"accessories":[{"aid":1,"services":[{"iid":1,"type":"3E","hidden":false,"primary":false,"characteristics":[{"aid":1,"iid":2,"type":"23","perms":["pr"],"description":"Name","format":"string","value":"Sample LED"},{"aid":1,"iid":3,"type":"20","perms":["pr"],"description":"Manufacturer","format":"string","value":"HaPK"},{"aid":1,"iid":4,"type":"30","perms":["pr"],"description":"Serial Number","format":"string","value":"037A2BABF19D"},{"aid":1,"iid":5,"type":"21","perms":["pr"],"description":"Model","format":"string","value":"MyLED"},{"aid":1,"iid":6,"type":"52","perms":["pr"],"description":"Firmware Revision","format":"string","value":"0.1"},{"aid":1,"iid":7,"type":"14","perms":["pw"],"description":"Identify","format":"bool"}]},{"iid":8,"type":"43","hidden":false,"primary":true,"characteristics":[{"aid":1,"iid":9,"type":"25","perms":["pr","pw","ev"],"ev":false,"description":"On","format":"bool","value":false}]}]}]}
>>> client_send: [Client 4] Encrypting payload
>>> homekit_client_process: [Client 4] Finished processing
--24036@0014269ms
>>> homekit_client_process: [Client 4] Got 193 incomming data
>>> homekit_client_process: [Client 4] Decrypting data
>>> homekit_client_process: [Client 4] Decrypted 175 bytes, available 0
Decrypted data (175 bytes): "PUT /characteristics HTTP/1.1\x0D\x0AHost: Sample\\032LED._hap._tcp.local\x0D\x0AContent-Length: 49\x0D\x0AContent-Type: application/hap+json\x0D\x0A\x0D\x0A{"characteristics":[{"aid":1,"iid":9,"ev":true}]}"
>>> HomeKit: [Client 4] Update Characteristics
>>> homekit_server_on_update_characteristics: [Client 4] Processing element {
	"aid":	1,
	"iid":	9,
	"ev":	true
}
>>> homekit_server_on_update_characteristics: [Client 4] There were no processing errors, sending No Content response
>>> client_send: [Client 4] Encrypting payload
>>> homekit_client_process: [Client 4] Finished processing
>>> homekit_client_process: [Client 4] Got 193 incomming data
>>> homekit_client_process: [Client 4] Decrypting data
>>> homekit_client_process: [Client 4] Decrypted 175 bytes, available 0
Decrypted data (175 bytes): "PUT /characteristics HTTP/1.1\x0D\x0AHost: Sample\\032LED._hap._tcp.local\x0D\x0AContent-Length: 49\x0D\x0AContent-Type: application/hap+json\x0D\x0A\x0D\x0A{"characteristics":[{"aid":1,"iid":9,"ev":true}]}"
>>> HomeKit: [Client 4] Update Characteristics
>>> homekit_server_on_update_characteristics: [Client 4] Processing element {
	"aid":	1,
	"iid":	9,
	"ev":	true
}
>>> homekit_server_on_update_characteristics: [Client 4] There were no processing errors, sending No Content response
>>> client_send: [Client 4] Encrypting payload
>>> homekit_client_process: [Client 4] Finished processing
--25620@0014469ms
...
--25620@0019669ms
>>> homekit_client_process: [Client 4] Got 95 incomming data
>>> homekit_client_process: [Client 4] Decrypting data
>>> homekit_client_process: [Client 4] Decrypted 77 bytes, available 0
Decrypted data (77 bytes): "GET /characteristics?id=1.9 HTTP/1.1\x0D\x0AHost: Sample\\032LED._hap._tcp.local\x0D\x0A\x0D\x0A"
>>> HomeKit: [Client 4] Get Characteristics
>>> homekit_server_on_get_characteristics: Free heap: 25564
>>> homekit_server_on_get_characteristics: [Client 4] Query paramter id = 1.9
>>> homekit_server_on_get_characteristics: [Client 4] Requested characteristic info for 1.9
>>> send_json_response: [Client 4] Sending JSON response
>>> send_json_response: [Client 4] Payload: {"characteristics":[{"aid":1,"iid":9,"value":false}]}
>>> send_json_response: [Client 4] Sending HTTP response: HTTP/1.1 200 OK
Content-Type: application/hap+json
Content-Length: 53
Connection: keep-alive

{"characteristics":[{"aid":1,"iid":9,"value":false}]}
>>> client_send: [Client 4] Encrypting payload
>>> homekit_client_process: [Client 4] Finished processing
--25608@0019869ms
...
--25608@0021269ms
>>> homekit_client_process: [Client 4] Got 193 incomming data
>>> homekit_client_process: [Client 4] Decrypting data
>>> homekit_client_process: [Client 4] Decrypted 175 bytes, available 0
Decrypted data (175 bytes): "PUT /characteristics HTTP/1.1\x0D\x0AHost: Sample\\032LED._hap._tcp.local\x0D\x0AContent-Length: 49\x0D\x0AContent-Type: application/hap+json\x0D\x0A\x0D\x0A{"characteristics":[{"aid":1,"iid":9,"value":1}]}"
>>> HomeKit: [Client 4] Update Characteristics
--24752@0021469ms
>>> homekit_server_on_update_characteristics: [Client 4] Processing element {
	"aid":	1,
	"iid":	9,
	"value":	1
}
>>> client_notify_characteristic: Got characteristic 1.9 change event
>>> client_notify_characteristic: Sending event to client 4
>>> homekit_server_on_update_characteristics: [Client 4] There were no processing errors, sending No Content response
>>> client_send: [Client 4] Encrypting payload
>>> homekit_client_process: [Client 4] Finished processing
>>> homekit_server_process_notifications: [Client 4] Received event for 1.9
>>> send_characteristic_event: [Client 4] Sending EVENT
>>> send_characteristic_event: [Client 4] Payload: {"characteristics":[{"aid":1,"iid":9,"value":true}]}
>>> send_characteristic_event: [Client 4] Sending EVENT: EVENT/1.0 200 OK
Content-Type: application/hap+json
Content-Length: 52

{"characteristics":[{"aid":1,"iid":9,"value":true}]}
>>> client_send: [Client 4] Encrypting payload
>>> homekit_server_process_notifications: [Client 4] Freeing event
--25608@0021669ms
...
--25608@0023269ms
>>> homekit_client_process: [Client 4] Got 193 incomming data
>>> homekit_client_process: [Client 4] Decrypting data
>>> homekit_client_process: [Client 4] Decrypted 175 bytes, available 0
Decrypted data (175 bytes): "PUT /characteristics HTTP/1.1\x0D\x0AHost: Sample\\032LED._hap._tcp.local\x0D\x0AContent-Length: 49\x0D\x0AContent-Type: application/hap+json\x0D\x0A\x0D\x0A{"characteristics":[{"aid":1,"iid":9,"value":0}]}"
>>> HomeKit: [Client 4] Update Characteristics
>>> homekit_server_on_update_characteristics: [Client 4] Processing element {
	"aid":	1,
	"iid":	9,
	"value":	0
}
>>> client_notify_characteristic: Got characteristic 1.9 change event
>>> client_notify_characteristic: Sending event to client 4
>>> homekit_server_on_update_characteristics: [Client 4] There were no processing errors, sending No Content response
>>> client_send: [Client 4] Encrypting payload
>>> homekit_client_process: [Client 4] Finished processing
>>> homekit_server_process_notifications: [Client 4] Received event for 1.9
>>> send_characteristic_event: [Client 4] Sending EVENT
>>> send_characteristic_event: [Client 4] Payload: {"characteristics":[{"aid":1,"iid":9,"value":false}]}
>>> send_characteristic_event: [Client 4] Sending EVENT: EVENT/1.0 200 OK
Content-Type: application/hap+json
Content-Length: 53

{"characteristics":[{"aid":1,"iid":9,"value":false}]}
>>> client_send: [Client 4] Encrypting payload
>>> homekit_server_process_notifications: [Client 4] Freeing event
--24004@0023469ms

report code:

void print_timeheap_task(void *arg) {
#ifdef HOMEKIT_DEBUG
    for(;;) {
        printf("--%05d@%07dms\n", sdk_system_get_free_heap_size(), sdk_system_get_time()/1000);
//        vTaskDelay(10);   //100ms
        vTaskDelay(20);   //200ms
//        vTaskDelay(100); //1s
    }
#endif
    vTaskDelete(NULL);
}

void homekit_server_init(homekit_server_config_t *config) {
    xTaskCreate(print_timeheap_task, "TimeHeap", 256, NULL, 1, NULL);
    xTaskCreate(homekit_server_task, "HomeKit Server", 1700, server, 1, NULL);

Hello!

1st: Awesome job to get the HomeKit run native on ESP8266 !!

Thank´s for that!

My Problem:

I want to bring up a garagedoor accessory to simple digital in/outs...
But i have big problems to understand this api-style coding.

Ok, this is my very first try, and i always get "error: 'homekit_permissions_write'":
Can anybody help me to get this Task running?

Big thanks !

#include <stdio.h>
#include <espressif/esp_wifi.h>
#include <espressif/esp_sta.h>
#include <esp/uart.h>
#include <esp8266.h>
#include <FreeRTOS.h>
#include <task.h>

#include <homekit/homekit.h>
#include <homekit/characteristics.h>
#include "wifi.h"


static void wifi_init() {
    struct sdk_station_config wifi_config = {
        .ssid = WIFI_SSID,
        .password = WIFI_PASSWORD,
    };

    sdk_wifi_set_opmode(STATION_MODE);
    sdk_wifi_station_set_config(&wifi_config);
    sdk_wifi_station_connect();
}


#define SENSOR_PIN 4



void garage_identify(homekit_value_t _value) {
    printf("GarageLock identify\n");
}

			
homekit_characteristic_t name = HOMEKIT_CHARACTERISTIC_(NAME, "Garage");
homekit_characteristic_t currdoor = HOMEKIT_CHARACTERISTIC_(CURRENT_DOOR_STATE, 0);
homekit_characteristic_t currlock = HOMEKIT_CHARACTERISTIC_(LOCK_CURRENT_STATE, 0);
homekit_characteristic_t tardoor = HOMEKIT_CHARACTERISTIC_(TARGET_DOOR_STATE, 0);
homekit_characteristic_t tarlock = HOMEKIT_CHARACTERISTIC_(LOCK_TARGET_STATE, 0);
homekit_characteristic_t detect = HOMEKIT_CHARACTERISTIC_(OBSTRUCTION_DETECTED, false);


void garage_sensor_task(void *_args) {
    gpio_set_pullup(SENSOR_PIN, false, false);

   
    while (1) {
        int open = gpio_read(SENSOR_PIN);
            
        if (open) {            
            homekit_characteristic_notify(&currdoor, HOMEKIT_UINT8(0));
            
        } else {
            homekit_characteristic_notify(&currdoor, HOMEKIT_UINT8(1));
        }

        vTaskDelay(3000 / portTICK_PERIOD_MS);
    }
}


void garage_sensor_init() {
    xTaskCreate(garage_sensor_task, "Garage Sensor", 256, NULL, 2, NULL);
}




homekit_accessory_t *accessories[] = {
    HOMEKIT_ACCESSORY(.id=1, .category=homekit_accessory_category_garage, .services=(homekit_service_t*[]){
        HOMEKIT_SERVICE(ACCESSORY_INFORMATION, .characteristics=(homekit_characteristic_t*[]){
            &name,
            HOMEKIT_CHARACTERISTIC(MANUFACTURER, "Maxim&i"),
            HOMEKIT_CHARACTERISTIC(SERIAL_NUMBER, "037A2BABF19D"),
            HOMEKIT_CHARACTERISTIC(MODEL, "GarageLock"),
            HOMEKIT_CHARACTERISTIC(FIRMWARE_REVISION, "0.1"),
            HOMEKIT_CHARACTERISTIC(IDENTIFY, garage_identify),
            NULL
        }),
        HOMEKIT_SERVICE(GARAGE_DOOR_OPENER, .primary=true, .characteristics=(homekit_characteristic_t*[]){
            &name,
            &currdoor,
            &currlock,
            &tardoor,
            &tarlock,
            &detect,	                       
            NULL
        }),
        NULL
    }),
    NULL
};

homekit_server_config_t config = {
    .accessories = accessories,
    .password = "111-11-111"
};

void user_init(void) {
    uart_set_baud(0, 115200);

    wifi_init();
    garage_sensor_init();
    homekit_server_init(&config);
}

After the move of tlv.h to the include folder, when I try to compile, I get this error:

make: *** No rule to make target '/esp/components/homekit/src/tlv.h', needed by 'build/homekit//src/tlv.o'. Stop.

Is any change in the Makefile needed?

Update: I can work around this by adding an empty tlv.h in the same directory tlv.c resides, but I shouldn't have to. I'm using an ESP8266 (I figure it's relevant, since the project supports two toolchains).

Having successfully built and flashed a couple of examples, I am now having some issue with pairing. Seems immediately after the verification step is complete, and the get accessories is called, I then get a remove pairing event, summary and detailed traces below, any ideas?

HomeKit: Got new client connection: 4
HomeKit: [Client 4] Pair Setup Step 1/3
HomeKit: [Client 4] Pair Setup Step 2/3
HomeKit: [Client 4] Pair Setup Step 3/3
HomeKit: Added pairing with 856FCE22-3DA1-4066-A021-BC1A1DC64344
HomeKit: Configuring mDNS
HomeKit: [Client 4] Successfully paired
HomeKit: [Client 4] Closing client connection
HomeKit: Got new client connection: 4
HomeKit: [Client 4] Pair Verify Step 1/2
HomeKit: [Client 4] Pair Verify Step 2/2
HomeKit: [Client 4] Found pairing with 856FCE22-3DA1-4066-A021-BC1A1DC64344
HomeKit: [Client 4] Verification successful, secure session established
HomeKit: [Client 4] Get Accessories
HomeKit: [Client 4] Remove Pairing
HomeKit: Removed pairing with 856FCE22-3DA1-4066-A021-BC1A1DC64344
HomeKit: Last admin pairing was removed, enabling pair setup
HomeKit: Configuring mDNS
HomeKit: [Client 4] Closing client connection

Detailed trace:-

HomeKit: Got IP, starting
HomeKit: Configuring mDNS
run_server: Staring HTTP server
mdns_recv: pbuf too big
HomeKit: Got new client connection: 4
homekit_pairing_task: Starting pairing task
homekit_pairing_task: Free heap: 29248
homekit_pairing_task: [Client 4] Got 128 incomming data
homekit_server_on_pair_setup: Pair Setup
homekit_server_on_pair_setup: Free heap: 29096
tlv_debug: Got following TLV values:
tlv_debug: Type 6 value (1 bytes): \x01
tlv_debug: Type 0 value (1 bytes): \x00
HomeKit: [Client 4] Pair Setup Step 1/3
homekit_server_on_pair_setup: Free heap: 29000
crypto_srp_new: Initializing SRP
homekit_server_on_pair_setup: [Client 4] Initializing crypto
homekit_server_on_pair_setup: Free heap: 28336
homekit_server_on_pair_setup: [Client 4] Using user-specified password: 111-11-111
crypto_srp_init: Generating salt
crypto_srp_init: Setting SRP username
crypto_srp_init: Setting SRP params
crypto_srp_init: Setting SRP password
crypto_srp_init: Getting SRP verifier
mdns_recv: pbuf too big
crypto_srp_init: Setting SRP verifier
crypto_srp_get_public_key: Calculating public key
send_tlv_response: [Client 4] Sending TLV response
tlv_debug: Got following TLV values:
tlv_debug: Type 6 value (1 bytes): \x02
tlv_debug: Type 2 value (16 bytes): \xD2\x80\xCBU\x08""\xC7\xCFk\xF0\xAD\xB3\xD1E\xB2
tlv_debug: Type 3 value (384 bytes): \xDB\xA9\xF0\x92\x1BB\x1D<\xED\xF3\x88>\xFF\x90\xA7\x9F1\xF7\x11l\xF2\xDB\x97y\xC7\xF7!)|L'\xF6\x1E_<FO)\xF0D*\x93\xEAJUH\xB9\x1F>\xAAAg\xB1uL\xE0>\xF7{\xA116\xFF\x05\xFD\xB8\xCC\x1E\x9F'\xFB|\xD3\xC4\x81\xC0\xB6\xC4\xC4\xE5\x91\x8D\x1F\x8E\xC6\xD5\x9F\xBBsk\x0F\xED\xA6\x98\x02\xB4\xD00\xDB\xF1M\xFA\xD8\xC7\\\xC6\xEE\xEFZzz\x1BF{\x86vc\xB4\x17W\xCC\xF5aMwb{\xAE\x97*\xB5\x87\xE4\xD9\xC9kG\xB9\x92\xAB\xB3U\xC9;\\\x04\xA6\x87\xB3\x9C\x87}d\xEA\xC7V]A\xE2\xCDD\xD1\xF3\xAF\xFC\xE8\x8D\x80\x92\xD0\xB9\xACS\\\xA5&F*'\xF4\x0E\xD7\x1C\x89~*\xDD\xD2u\xA6\xB7\xD0Y2\xF2\x9A\xCF_e%\xE6<\xAF\xFB\xF4\x831\xF9.\x1EH#\xD8\xEE\x9D+\x13N\x99\xF4\xFF\x02q\x05#\xC1z{\x09\x09\x82\xB9\xFA\x90\x96\x03␡\x0F\x84\x8B\xEA\xBB\xD6\xC6\x9CVOk\x07\x8E\x18\xF7\xCD&yQ^>\xFF\xCEE\xE9\xD4Vy\xEAn\x12G_\x81\x95\xCA^+\xE3\\|\x13S>\xB1\x1B\xF4\xA1]\x06\xCC}\x8D%\xDF*{\xC00P\x84\xA3f3\x16?\xFE.\x00\xCC\xABI}:I\xC1\xBA\xCFdB\xE5cxt\x83d\xE0tq\x0F$\x8E\xFCI\x85!\xE0\x15~\x07J\xF4\xC5D\xA2m\xB9\xC4\xF4\xEE\x0AF\xC6\xA7\xA09AQ\x8Eo0\xFE\x01\xA0V\xC6\x9AT\x98bv\xFA5\xF5\xCD\x97\xB3\xCAJ\xFA\x08To@\xB2
homekit_pairing_task: [Client 4] Got 256 incomming data
homekit_pairing_task: [Client 4] Got 256 incomming data
homekit_pairing_task: [Client 4] Got 69 incomming data
homekit_server_on_pair_setup: Pair Setup
homekit_server_on_pair_setup: Free heap: 26128
tlv_debug: Got following TLV values:
tlv_debug: Type 4 value (64 bytes): E\xDBb\xE2\xBE\x93h\x0F\x07[\xFE8\xD9\xB6\xBDPW/\x0Bl\xE9\xAB\x8FG\xC9\xA5k\xDD\x87\xCA[\x80r\xF0\x0D\xA5z\xD6t^8v\x8CC\x86\xB3\xFB\xFA\xAD\xC41\xAA\xEC\x0Dm@0\xAA\xA2\xC6\x07\x08\x9A\xA3
tlv_debug: Type 3 value (384 bytes): \x1D{\x13+.\x1C\x17\x0B\xE4/\x89\x9A\x1A\xF6\xEC\xFC\xD5\xA7\xEF\x09L\xEBl\xA2.\xDFa\xEAq\xA9\xFE\xE4\x03\xC0\xAA\xA1\x18\x80t\xAF)\xE5<17\xDB\xC1\x8As\x95>\x9C5\xA5W\xBF\x8A\xB7\xFD\xAB\x00\x99\xF7J\xD9\xFF/\xB2\xC8\xDD\x0Du\xCA^\x18X\xCE\x1A\xF2\xB4\xFEx\xD9\xCC\xDC\x05f\x8B\x03]\xB7\xB3\xE2\xBD\x91T\x16\xB5\x08q]\x8C\xA0\x94eI\x81uv{2\x8FF\xB9Um%\x96\xB0\x15\xCA\xA94\xD0\xEB\x93F\xDCK\x15\xE2\xEFI\xD0QS2\xFFg\xF8Hu&M\xE2Af\xDE\xC9\x0A\xC9\x04a\x85\xA4/\xB6|\xE0k\x0A\xD7i\x18\x87u\xBD|z-xN(\x185\x8F\xEE\x96\xE5\xC2\xBEW\x19T\x90X\xCA#\xDB\xEA\xEB\xA1\xFE\xD6\xED\xEC*\x00>\xA1\x91DB\xB2\x0Fd\xDB\xE8t!\xBFZ\xE7-WWE\xB9\x9D\xF6SpU\\\xC1\xB4\xE4%H\xC5TBl\xB4o\xA6\x8C\xA9~\x9D\x09\xBC\x93\xE7\xCF\x1Cj-\xA9\xD4\xB6\xB9\xAEv\xF1JR4x\x93\xC6\xF1\xF9\x89\x04\xC6\x8D6\xFFo\x0B\xBB\xF6\x15\xEA[\xA1\xA7-\x11D3\x08\xBF\x8D\xFDz\xB4\xE9\xEC\xAC\xD7O\xF5\xC7\xEF\x05K\xC6\xB2\x07p_\x1A&3\xE5\x04}+\x81\xD4T\x03\xE9\x85\xB25\x9E\x96\xBD\xD9?\xB1Y\xC62.}\xF4\xA8\x96␡T\xD9\x91\x0F\xDD\x1D3\x92=HmI+\x93\xEA\xB2\xE1\x1E\xEFs\x96\xD0Y\x06\xC0\x92\xCCn\x85t\xC5a\x06[\x08 \xD8\xAAHnJ\xF8\x88\xE6+U7\xAC:\x0D tlv_debug: Type 6 value (1 bytes): \x03 HomeKit: [Client 4] Pair Setup Step 2/3 homekit_server_on_pair_setup: Free heap: 25432 homekit_server_on_pair_setup: [Client 4] Computing SRP shared secret homekit_server_on_pair_setup: Free heap: 25432 mdns_recv: pbuf too big homekit_server_on_pair_setup: [Client 4] Verifying peer's proof homekit_server_on_pair_setup: Free heap: 25884 homekit_server_on_pair_setup: [Client 4] Generating own proof send_tlv_response: [Client 4] Sending TLV response tlv_debug: Got following TLV values: tlv_debug: Type 6 value (1 bytes): \x04 tlv_debug: Type 4 value (64 bytes): \x13E\x95\x0A\xBB\xB4\xDBg\x81%!\xB4\x0D\x00j\xD9\xF9\x92\xE2\xC9\xFE\x84\xCB\xCB)%\xD2\xBEWcM\xFD\xDA\x8BH\xD4\xA6\xC8?\xE91Nd\xF8\xED0\xDFBe\xB6\xD9\xEF\xBE!\xC6h\xD0\xAE=S\xE3\xCB\xC0\x04 homekit_pairing_task: [Client 4] Got 256 incomming data homekit_pairing_task: [Client 4] Got 27 incomming data homekit_server_on_pair_setup: Pair Setup homekit_server_on_pair_setup: Free heap: 26724 tlv_debug: Got following TLV values: tlv_debug: Type 6 value (1 bytes): \x05 tlv_debug: Type 5 value (154 bytes): \xE8\xD0ac\xBC\x9C\xB8T\xA7j/\xF6i\xCC\x17d\x90\xB1\xE8@\xE8\x04Yl\xA1\xACVY\xC42\x8D\x81\xAB\xAD hF\x19\xBA'b]\x05zs?#\x8B1\xE3\xDC\x1D?F\xBE$m\x18\x18\xD9\xB8\xDB\x8B\x05\xEA6?Q\xC2KH\xB7c\xF1\x1B\xF3\x13vCM9\x9FqJ\xBE\x11\x810\xF7\xFB\xD6z\xBF\x8C\xC0l:\x18\xDEop\xF4\xCF|s\x19H\x9F8\xF2\x87\xB9H\xE2x\x08#\x87\xC1EBQ\xBB\xE5\x00Ca+D\xF3\xC1\xEB\xE3\xFBi\xFBA\xB1\x8An\x0C\xEFi\x08\xE4\xBD\xD6nJN\xD6B\xD4
HomeKit: [Client 4] Pair Setup Step 3/3
homekit_server_on_pair_setup: Free heap: 26484
homekit_server_on_pair_setup: [Client 4] Calculating shared secret
homekit_server_on_pair_setup: [Client 4] Decrypting payload
homekit_server_on_pair_setup: [Client 4] Importing device public key
homekit_server_on_pair_setup: [Client 4] Calculating DeviceX
homekit_server_on_pair_setup: [Client 4] Verifying device signature
HomeKit: Added pairing with 856FCE22-3DA1-4066-A021-BC1A1DC64344
homekit_server_on_pair_setup: [Client 4] Exporting accessory public key
homekit_server_on_pair_setup: [Client 4] Calculating AccessoryX
homekit_server_on_pair_setup: [Client 4] Generating accessory signature
homekit_server_on_pair_setup: Free heap: 26340
tlv_debug: Got following TLV values:
tlv_debug: Type 10 value (64 bytes): c\xEA\xD9\xBD)}\x9A\x80\x19\x8A\xAC\xA4\xC7\xB56\x07[\xC3/\x99\xFApU\xB99\x9B\xE4\x8E\xF1\xF9\xB7R^\xF9\xE0\x1C\xB9Q\xFB\x1F\xB0\x89#\x16RML<\xD8#u\xFCH\x9F"Z\xFD\xB4\x91\xA1\xDF\xED6\x02
tlv_debug: Type 3 value (32 bytes): \x8B\xB9G+\xBD\xA3/.\xCC\\xCB\x0E~\xBE\x12\xD7#\x8F!R\xC5\x1B\xB0\x8Ceg\xA4\xD7R\xD2&\x9F
tlv_debug: Type 1 value (17 bytes): 64:1F:22:57:C3:BC
homekit_server_on_pair_setup: [Client 4] Encrypting response
send_tlv_response: [Client 4] Sending TLV response
tlv_debug: Got following TLV values:
tlv_debug: Type 5 value (135 bytes): |P\xCF\xBC}\x8B\xE25\x0E\xEE\xCC\xB9\x88␡2\x13X:]\xF5\xA1!1Uh\xA9\xDFi\xD1\xE3\x94\x9F\xB8\x01\xC5l/\x0B\xB7\x0CE\xC2i\x88\x8D\x8Eer\xE6␡\xF3\\P\x01\xCE\xC4\x14(h\xF2\xE6\x9A\xA2YF\x931\x10␡\x9B\xDEg\x9Bw\xBAO\xB1\xA9\xE3\xFDg\xBC,\xA0\xF9b\xBF \x82]0\x86M\x8C\x8E6a\xDD\x0C\x1C\xF1\xE2\xB1D\x96\xB6\xE5\x87\xC8V\x84\x94Y\xA8Es\xEC\x09\xAAW\xBD\x07\xC8|\xD2\xA7o\xC3\xF5j\xC5\xC8\xED{ tlv_debug: Type 6 value (1 bytes): \x06 HomeKit: Configuring mDNS HomeKit: [Client 4] Successfully paired homekit_client_task: Starting client task homekit_client_task: Free heap: 22832 homekit_client_task: [Client 4] Got 0 incomming data HomeKit: [Client 4] Closing client connection HomeKit: Got new client connection: 4 homekit_client_task: Starting client task homekit_client_task: Free heap: 24992 homekit_client_task: [Client 4] Got 161 incomming data homekit_server_on_pair_verify: HomeKit Pair Verify homekit_server_on_pair_verify: Free heap: 23844 tlv_debug: Got following TLV values: tlv_debug: Type 3 value (32 bytes): \xAC\xC5\x9E@TJ\x16\xFFp{\xA4x\xB9\x99\x8C\xDB\x95V\xC4\xF8\xFF\x17d\x96g\x87\xA5n\x80\x863
tlv_debug: Type 6 value (1 bytes): \x01
HomeKit: [Client 4] Pair Verify Step 1/2
homekit_server_on_pair_verify: [Client 4] Importing device Curve25519 public key
homekit_server_on_pair_verify: [Client 4] Generating accessory Curve25519 key
homekit_server_on_pair_verify: [Client 4] Exporting accessory Curve25519 public key
homekit_server_on_pair_verify: [Client 4] Generating Curve25519 shared secret
homekit_server_on_pair_verify: [Client 4] Generating signature
homekit_server_on_pair_verify: [Client 4] Generating proof
homekit_server_on_pair_verify: [Client 4] Encrypting response
send_tlv_response: [Client 4] Sending TLV response
tlv_debug: Got following TLV values:
tlv_debug: Type 5 value (101 bytes): \xFE\x8E\xF5\xC3\x9C\x84\x1A~*\x91\xC8\xC6r\xBF{Dp\xF1<\xC6\x13"Ol\xAD\x88\xF4fa\xB4'\xA9\x91/!\x9A\x10\x94\xF62lg+\xE2\x1C\xFE\xA1R\x97e\xF7\xA6\xC3\x9FmZ\xDD\x8A\xB5\xD5NMY\xFD\x1C\xA2\xF3\xF6\x97\xC8\x80\x89\x08h+\xBC\x8DWR:J \xE3\x81\xCB\x96L\xA86>\xCB\xCD:\xB4\x8DA\x11\xD2\x00\x1A\x82
tlv_debug: Type 3 value (32 bytes): \xC4\xDE\xCB!\x0C%\x9FL\xDD%\x9E\x07K\xA49\xEE\xCA\x96\xC3\xBE\x09\xCCt\x1Brf\x9B\xA7`=\xFDV
tlv_debug: Type 6 value (1 bytes): \x02
homekit_client_task: [Client 4] Got 250 incomming data
homekit_server_on_pair_verify: HomeKit Pair Verify
homekit_server_on_pair_verify: Free heap: 23524
tlv_debug: Got following TLV values:
tlv_debug: Type 6 value (1 bytes): \x03
tlv_debug: Type 5 value (120 bytes): \x1C\x049\xCEp\xA8\x04\xAC\xE2\xFB\x93"\x1F\\x97\xA8\x14k\xEA\xC1\xAFemJ\xAF\x05,\xC1\x80\x91\x10\xED\xE3$\x88\x07\xE9\xF6\xEA\x96\xE7\x8A%\xDC7\xE0\xED\x1A\x87\xA0\xFBh\x9Cd\xBA\x9F\x15[\xAF\xC1V\x04\xFA\x93\xF2\xF3\x196\x9A4\x05=\xC52\xF5\x97t\x1C-\x80\xEBG\xD5F\xC5\xE2\xF3\xC9\xA81\xA1\x06)\x02\x02F+m\x14\xA0\xCF2~\x8C\x04\xBB\xA4\x17\xC8\xBB\x9A\xF3\xA0a+\xF8\xBFm\x9F\x93
HomeKit: [Client 4] Pair Verify Step 2/2
homekit_server_on_pair_verify: [Client 4] Decrypting payload
homekit_server_on_pair_verify: [Client 4] Searching pairing with 856FCE22-3DA1-4066-A021-BC1A1DC64344
HomeKit: [Client 4] Found pairing with 856FCE22-3DA1-4066-A021-BC1A1DC64344
homekit_server_on_pair_verify: [Client 4] Verifying device signature
send_tlv_response: [Client 4] Sending TLV response
tlv_debug: Got following TLV values:
tlv_debug: Type 6 value (1 bytes): \x04
HomeKit: [Client 4] Verification successful, secure session established
homekit_client_task: [Client 4] Got 81 incomming data
homekit_client_task: [Client 4] Decrypting data
homekit_client_task: [Client 4] Decrypted 63 bytes, available 0
Decrypted data (63 bytes): "GET /accessories HTTP/1.1\x0D\x0AHost: Thermostat._hap._tcp.local\x0D\x0A\x0D\x0A"
HomeKit: [Client 4] Get Accessories
homekit_server_on_get_accessories: Free heap: 23656
send_json_response: [Client 4] Sending JSON response
send_json_response: [Client 4] Payload: {"accessories":[{"aid":1,"services":[{"iid":1,"type":"3E","hidden":false,"primary":false,"characteristics":[{"aid":1,"iid":2,"type":"23","perms":["pr"],"description":"Name","format":"string","value":"Thermostat"},{"aid":1,"iid":3,"type":"20","perms":["pr"],"description":"Manufacturer","format":"string","value":"HaPK"},{"aid":1,"iid":4,"type":"30","perms":["pr"],"description":"Serial Number","format":"string","value":"0012345"},{"aid":1,"iid":5,"type":"21","perms":["pr"],"description":"Model","format":"string","value":"MyThermostat"},{"aid":1,"iid":6,"type":"52","perms":["pr"],"description":"Firmware Revision","format":"string","value":"0.1"},{"aid":1,"iid":7,"type":"14","perms":["pw"],"description":"Identify","format":"bool"}]},{"iid":8,"type":"4A","hidden":false,"primary":true,"characteristics":[{"aid":1,"iid":9,"type":"23","perms":["pr"],"description":"Name","format":"string","value":"Thermostat"},{"aid":1,"iid":10,"type":"F","perms":["pr","ev"],"ev":false,"description":"Current Heating Cooling State","format":"uint8","minValue":0,"maxValue":2,"minStep":1,"valid-values":[0,1,2],"value":3},{"aid":1,"iid":11,"type":"33","perms":["pr","pw","ev"],"ev":false,"description":"Target Heating Cooling State","format":"uint8","minValue":0,"maxValue":3,"minStep":1,"valid-values":[0,1,2,3],"value":3},{"aid":1,"iid":12,"type":"11","perms":["pr","ev"],"ev":false,"description":"Current Temperature","format":"float","unit":"celsius","minValue":0,"maxValue":100,"minStep":0.10000000149011612,"value":20.100000381469727},{"aid":1,"iid":13,"type":"35","perms":["pr","pw","ev"],"ev":false,"description":"Target Temperature","format":"float","unit":"celsius","minValue":10,"maxValue":38,"minStep":0.10000000149011612,"value":21},{"aid":1,"iid":14,"type":"36","perms":["pr","pw","ev"],"ev":false,"description":"Temperature Display Units","format":"uint8","minValue":0,"maxValue":1,"minStep":1,"valid-values":[0,1],"value":0}]},{"iid":15,"type":"82","hidden":false,"primary":false,"characteristics":[{"aid":1,"iid":16,"type":"23","perms":["pr"],"description":"Name","format":"string","value":"Humidity Sensor"},{"aid":1,"iid":17,"type":"10","perms":["pr","ev"],"ev":false,"description":"Current Relative Humidity","format":"float","unit":"percentage","minValue":0,"maxValue":100,"minStep":1,"value":58.099998474121094}]}]}]}
send_json_response: [Client 4] Sending HTTP response: HTTP/1.1 200 OK
Content-Type: application/hap+json
Content-Length: 2325
Connection: keep-alive

{"accessories":[{"aid":1,"services":[{"iid":1,"type":"3E","hidden":false,"primary":false,"characteristics":[{"aid":1,"iid":2,"type":"23","perms":["pr"],"description":"Name","format":"string","value":"Thermostat"},{"aid":1,"iid":3,"type":"20","perms":["pr"],"description":"Manufacturer","format":"string","value":"HaPK"},{"aid":1,"iid":4,"type":"30","perms":["pr"],"description":"Serial Number","format":"string","value":"0012345"},{"aid":1,"iid":5,"type":"21","perms":["pr"],"description":"Model","format":"string","value":"MyThermostat"},{"aid":1,"iid":6,"type":"52","perms":["pr"],"description":"Firmware Revision","format":"string","value":"0.1"},{"aid":1,"iid":7,"type":"14","perms":["pw"],"description":"Identify","format":"bool"}]},{"iid":8,"type":"4A","hidden":false,"primary":true,"characteristics":[{"aid":1,"iid":9,"type":"23","perms":["pr"],"description":"Name","format":"string","value":"Thermostat"},{"aid":1,"iid":10,"type":"F","perms":["pr","ev"],"ev":false,"description":"Current Heating Cooling State","format":"uint8","minValue":0,"maxValue":2,"minStep":1,"valid-values":[0,1,2],"value":3},{"aid":1,"iid":11,"type":"33","perms":["pr","pw","ev"],"ev":false,"description":"Target Heating Cooling State","format":"uint8","minValue":0,"maxValue":3,"minStep":1,"valid-values":[0,1,2,3],"value":3},{"aid":1,"iid":12,"type":"11","perms":["pr","ev"],"ev":false,"description":"Current Temperature","format":"float","unit":"celsius","minValue":0,"maxValue":100,"minStep":0.10000000149011612,"value":20.100000381469727},{"aid":1,"iid":13,"type":"35","perms":["pr","pw","ev"],"ev":false,"description":"Target Temperature","format":"float","unit":"celsius","minValue":10,"maxValue":38,"minStep":0.10000000149011612,"value":21},{"aid":1,"iid":14,"type":"36","perms":["pr","pw","ev"],"ev":false,"description":"Temperature Display Units","format":"uint8","minValue":0,"maxValue":1,"minStep":1,"valid-values":[0,1],"value":0}]},{"iid":15,"type":"82","hidden":false,"primary":false,"characteristics":[{"aid":1,"iid":16,"type":"23","perms":["pr"],"description":"Name","format":"string","value":"Humidity Sensor"},{"aid":1,"iid":17,"type":"10","perms":["pr","ev"],"ev":false,"description":"Current Relative Humidity","format":"float","unit":"percentage","minValue":0,"maxValue":100,"minStep":1,"value":58.099998474121094}]}]}]}

client_send: [Client 4] Encrypting payload
homekit_client_task: [Client 4] Got 183 incomming data
homekit_client_task: [Client 4] Decrypting data
homekit_client_task: [Client 4] Decrypted 165 bytes, available 0
Decrypted data (165 bytes): "POST /pairings HTTP/1.1\x0D\x0AHost: Thermostat._hap._tcp.local\x0D\x0AContent-Length: 44\x0D\x0AContent-Type: application/pairing+tlv8\x0D\x0A\x0D\x0A\x00\x01\x04\x06\x01\x01\x01$856FCE22-3DA1-4066-A021-BC1A1DC64344"
homekit_server_on_pairings: HomeKit Pairings
homekit_server_on_pairings: Free heap: 23204
tlv_debug: Got following TLV values:
tlv_debug: Type 1 value (36 bytes): 856FCE22-3DA1-4066-A021-BC1A1DC64344
tlv_debug: Type 6 value (1 bytes): \x01
tlv_debug: Type 0 value (1 bytes): \x04
HomeKit: [Client 4] Remove Pairing
HomeKit: Removed pairing with 856FCE22-3DA1-4066-A021-BC1A1DC64344
HomeKit: Last admin pairing was removed, enabling pair setup
HomeKit: Configuring mDNS
send_tlv_response: [Client 4] Sending TLV response
tlv_debug: Got following TLV values:
tlv_debug: Type 6 value (1 bytes): \x02
client_send: [Client 4] Encrypting payload
HomeKit: [Client 4] Force disconnect
HomeKit: [Client 4] Closing client connection

If I call homekit_characteristic_t current = HOMEKIT_CHARACTERISTIC_(CURRENT_DOOR_STATE, 0); and then call printf("Current: %d\n", current.value.int_value); it outputs "Current: 0" as expected. But when I call homekit_characteristic_notify(&current, HOMEKIT_UINT8(3)); it still outputs "Current: 0"

Right now password is hardcoded to be "111-11-111". This should be configurable: developer should be able to either provide a custom password or specify that random password should be generated each time. In later case, there should be a configuration option to provide password callback, so that random password could be exposed to user during pairing process.

Hi,

I want to generate QR codes for the devices I make.
I could use the Homekit simulator to fill in all the exact values and this program will generate the QR code I could use.
In the ESP HomeKit code I find all the necessary fields (Name, Manufacturer, Serial, Model, Password, ...) except something for the SETUP ID. I suppose I need this setup ID field in the ESP as well.
Is that field available and/or can this be added?

Korstiaan

I'm building a fan controller for a 3-speed fan, this controller will use custom values for format, unit, min_value, max_value and min_step on the rotation speed characteristic.

However, I often get Error reading data from socket (code 104) when using the Apple Home app to control the fan. It closes the client connection and as soon as the client reconnects it sends the characteristics again which works fine, but after changing the slider again there is a chance the error is thrown again.

I think this has something to do with the home app writing both the Active and Rotation Speed characteristic for every change of the slider. If I use Elgato eve or Matthias his Home app and change just one characteristic it works without throwing the error.

My code for the fan controller can be found here: https://github.com/renssies/esp-homekit-demo/tree/3_speed_fan

I've tested this on 2 Wemos D1 Mini boards with 4MB of flash and an ESP12E. Both give the same issue. I've also tested this with and without the socket timeout change, the published code is without the removal of the socket timeout.

First of all, I want to say thank you all for this amazing library. The moment I got it working on my ESP32 I was super excited 👏

Is there an existing way to check wether the server is paired yet? I want to include a status led that blinks when the accessory is not yet paired.

I know that the homekit_server_t struct contains a bool paired but there is no way to access this server struct from my code since homekit_server_init returns void.

What would be the best way to implement this? I want to create a PR but fail to see how.

Hello,

I am trying to integrate the HK server to make it work side-by-side with an MQTT client. Unfortunately, when I run both the modules, the HK server gets stuck (doesn't even start, at least, it seems so to me..)

Did anyone ever tried to do so, or to make it work, say, with some kind other "client module", such as for instance HTTP?

Best
Paolo

I am trying to make an Irrigating system (sprinkler) accessory and I found out that in "types.h", at line 63:
"homekit_accessory_category_sprinkler = 28,"
should be changed to:
"homekit_accessory_category_irrigation_system = 28,".

The accessory name is changed by Apple and also in "characteristics.h" the sprinkler is defined as irrigation system.

After this change my code is successfully compiled.

Thanks in advance

Hi,

the answer to list pairings (server.c lines 2625ff) seems to be reversed. IMHO list pairings is one of the few occasions that TLVs are dependend on a special order. The spec on page 55ff says to construct a TLV with items:

• kTLVType_State
• kTLVType_Idendtifier <PairingID controller 1>
• kTLVType_PublicKey <Public key controller 1>
• kTLVType_Permissions <Permissions controller 1>
• kTLVType_Separator
• kTLVType_Idendtifier <PairingID controller ...>
• kTLVType_PublicKey <Public key controller ...>
• kTLVType_Permissions <Permissions controller ...>

Everything after the separator is repeated for all additional pairings.

If I do such a request to a esp-homekit on a esp8266 I get:
In python:

[(11, bytearray(b'\x01')), (3, bytearray(b'Q<cWH\x05*\xe1\x13`\xd1\x11\xb1\xb4\xa2\x9d\xda7\xb84+w\xc6\xa59\x04\x993\xb07\xcd\xc3')), (1, bytearray(b'764e5722-07e6-464b-82f6-3d2c17f2185f')), (6, bytearray(b'\x02'))]

and also while monitoring the esp over serial line:

>>> HomeKit: [Client 4] List Pairings
>>> send_tlv_response: [Client 4] Sending TLV response
>>> tlv_debug: Got following TLV values:
>>> tlv_debug: Type 11 value (1 bytes): \x01
>>> tlv_debug: Type 3 value (32 bytes): Q<cWH\x05*\xE1\x13`\xD1\x11\xB1\xB4\xA2\x9D\xDA7\xB84+w\xC6\xA59\x04\x993\xB07\xCD\xC3
>>> tlv_debug: Type 1 value (36 bytes): 764e5722-07e6-464b-82f6-3d2c17f2185f
>>> tlv_debug: Type 6 value (1 bytes): \x02
>>> client_send: [Client 4] Sending payload: HTTP/1.1 200 OK\x0D\x0AContent-Type: application/pairing+tlv8\x0D\x0AContent-Length: 78\x0D\x0AConnection: keep-alive\x0D\x0A\x0D\x0A\x0B\x01\x01\x03 Q<cWH\x05*\xE1\x13`\xD1\x11\xB1\xB4\xA2\x9D\xDA7\xB84+w\xC6\xA59\x04\x993\xB07\xCD\xC3\x01$764e5722-07e6-464b-82f6-3d2c17f2185f\x06\x01\x02
>>> homekit_client_process: [Client 4] Finished processing
>>> HomeKit: [Client 4] Closing client connection

Is it possible to reverse the order of the items in the TLV so it is according to the specs? This would be a big advantage!

Regards
Joachim

PS: up to this issue, your code works superb with my https://github.com/jlusiardi/homekit_python code. Good work!

Can your library connect a PlatformIO?

Hello,
I need some status information for my OLED-display:

• Is homekit paired?
• Is homekit pairing?
• Get the current (and not the last) accessory_id?

I like functions like this:

bool homekit_server_paired();
bool homekit_server_pairing();
char* homekit_server_accessory_id();

Is it possible to get the new procedures?

What does that error mean? It occurs about 60-180min after program start.
After few minutes iOS says "no response"
(ESP32-DevKitC)

!!! HomeKit: [Client 56] Error reading data from socket (code 113). Disconnecting
>>> HomeKit: [Client 56] Closing client connection

It turns out, that the only way to get this to compile for ESP32 is to manually remove mdnsresponder.c and mdnsresponder.h.

For some reason this line of code is ignored, any idea why?

Hey,

I followed the led example from here, and I ran it properly the first time. However, I didn't change the code, (I even pulled the repo completely new) and now I'm getting an error Message when I monitor the ESP via terminal:

Opening /dev/cu.SLAB_USBtoUART at 115200bps...
pp_task_hdl : 3ffefd90, prio:14, stack:512
pm_task_hdl : 3ffef7f0, prio:1, stack:176
frc2_timer_task_hdl:0x3ffeeac0, prio:12, stack:200

ESP-Open-SDK ver: 0.0.1 compiled @ Feb 16 2018 13:12:41
phy ver: 273, pp ver: 8.3

mode : sta(5c:cf:7f:76:f8:1a)
add if0
>>> HomeKit: Starting server
>>> HomeKit: Using existing accessory ID: A7:24:08:04:91:30
>>> HomeKit: Found admin pairing with 2A4EABB8-9692-4D05-B603-D53899BAD14E, disabling pair setup
>>> HomeKit: Waiting for IP
scandone
add 0
aid 3
cnt

connected with G&W-Lan, channel 6
dhcp client start...
ip:192.168.0.24,mask:255.255.255.0,gw:192.168.0.1
>>> HomeKit: Got IP, starting
>>> HomeKit: Configuring mDNS
>>> mdns_recv: pbuf too big
>>> mdns_recv: pbuf too big

Any idea why this is and how I can resolve it?
It ran properly today, but now it doesn't anymore.

Just wondered if there is OTA Upgrade option scheduled in roadmap?

it exists both in homekit.h and server.h and with conflicting definitions...

After I upload code to the magic home controller it outputs "Failed to read flash magic" and I can't pair any devices.

I have done some profiling and noticed that you did not use the same concept as I did with respect to the curve25519 code.
In the current code you require a whopping 6 seconds to do the pair-verify procedure.
Unlike pairing, this procedure is mission critical since it is executed often while using the Accessory.
Using my approach bottom and not using ED25519_SMALL the speed of the crypto goes up by a factor of 20! bringing a new connection (and offering service to the user) back to 1 second.
It will require a bigger task and this brings me to the next improvement needed.

The current task structure is set on an initial task of 1700 stack which continues to do mdns and spawning additional tasks for each connected client at 768 bytes.

This should be changed such that only two tasks remain, a small one for mdns and a big one for all the clients together.
I have not gone deeper in this area to prevent my spaghetti coding skill in a pull request, but we can discuss the strategy. It is the one I applied in my repository.

I think this project is amazing, but anyone tried to add some libraries to make the software compatible with other domotic systems like domoticz, home assistant or Google home?

Hey guys, I'm quite new to the homekit and ESP development. I've written simple led stripe controller but after a while (2-10 minutes) of seamless function my app crashes and restarts with exception (see below). Can you please at least point me in the right direction?

I found out this table which says that Fatal error 28 is LoadProhibited and the reason is "CPU tried to load memory from a region which is protected against reads". So I guess somehow wrongly configured memory ranges somewhere in the makefiles?

It doesn't happen always, but when it does it happens after this:
HomeKit: [Client 4] Update Characteristics
HomeKit: [Client 4] Update Characteristics

I'm running the code on this module.

Fatal exception (28):
epc1=0x40105ac4

0x40105ac4: get_chunk_from_ptr at /home/src/esp/newlib-cygwin/build/xtensa-lx106-elf/newlib/libc/stdlib/../../../../../newlib/libc/stdlib/nano-mallocr.c:202
(inlined by) _free_r at /home/src/esp/newlib-cygwin/build/xtensa-lx106-elf/newlib/libc/stdlib/../../../../../newlib/libc/stdlib/nano-mallocr.c:367

epc2=0x00000000
epc3=0x40203469

0x40203469: prvCheckTasksWaitingTermination at /home/zach/homekit/esp-open-rtos/FreeRTOS/Source/tasks.c:4662
(inlined by) prvIdleTask at /home/zach/homekit/esp-open-rtos/FreeRTOS/Source/tasks.c:3241

excvaddr=0x0000000c
depc=0x00000000
excsave1=0x401059b6

0x401059b6: free at /home/src/esp/newlib-cygwin/build/xtensa-lx106-elf/newlib/libc/stdlib/../../../../../newlib/libc/stdlib/malloc.c:173

Registers:
a0 401059b6 a1 3fff6420 a2 3fff6674 a3 00000010

0x401059b6: free at /home/src/esp/newlib-cygwin/build/xtensa-lx106-elf/newlib/libc/stdlib/../../../../../newlib/libc/stdlib/malloc.c:173

a4 401059a4 a5 00000000 a6 3fff6020 a7 00000000

0x401059a4: free at /home/src/esp/newlib-cygwin/build/xtensa-lx106-elf/newlib/libc/stdlib/../../../../../newlib/libc/stdlib/malloc.c:171

a8 00000003 a9 00000450 a10 00000001 a11 00000001
a12 0000000c a13 3fff6674 SAR 0000001b

Stack: SP=0x3fff6420
0x3fff6420: 3fff6628 3ffe8e80 40215320 401059b6

0x40215320: client_notify_characteristic at /home/zach/homekit/esp-homekit/src/server.c:2892

0x401059b6: free at /home/src/esp/newlib-cygwin/build/xtensa-lx106-elf/newlib/libc/stdlib/../../../../../newlib/libc/stdlib/malloc.c:173

0x3fff6430: 00000100 3fff6674 3fff7ad4 402373ae

0x402373ae: cJSON_Delete at /home/zach/homekit/esp-homekit-demo/components/cJSON/cJSON/cJSON.c:1200

0x3fff6440: 00000000 3ffe8e80 3fff7978 3fff7978
0x3fff6450: 00000100 3ffe8e80 00000000 40237398

0x40237398: cJSON_Delete at /home/zach/homekit/esp-homekit-demo/components/cJSON/cJSON/cJSON.c:1200

0x3fff6460: 00000000 3ffe8e80 3fff7a18 3fff7a18
0x3fff6470: 00000100 3ffe8e80 00000000 40237398

0x40237398: cJSON_Delete at /home/zach/homekit/esp-homekit-demo/components/cJSON/cJSON/cJSON.c:1200

0x3fff6480: 3fff6628 00000001 3fff0978 3fff7b08
0x3fff6490: 00000100 3ffe8e80 00000000 40237398

0x40237398: cJSON_Delete at /home/zach/homekit/esp-homekit-demo/components/cJSON/cJSON/cJSON.c:1200

Free Heap: 29636
_heap_start 0x3fff1b00 brk 0x3fffa51c supervisor sp 0x40000000 sp-brk 23268 bytes
arena (total_size) 35356 fordblks (free_size) 6368 uordblocks (used_size) 28988

ets Jan 8 2013,rst cause:2, boot mode:(3,6)

load 0x40100000, len 2292, room 16

0x40100000: _stext at ??:?

tail 4
chksum 0x57
load 0x3ffe8000, len 772, room 4
tail 0
chksum 0x0b
csum 0x0b

I (143392) wifi: n:11 0, o:11 2, ap:255 255, sta:11 2, prof:1
!!! HomeKit: [Client 55] Error reading data from socket (code 113). Disconnecting
STA disconnected
>>> HomeKit: [Client 55] Closing client connection

What does it mean? This error occurs while normal usage.

Is there a way to silence the outputs on the serial port?

I can't seem to find specs for category of irrigation system. Several services include them however I have no idea for example what states can be defined in Program Mode etc, seems like official Apple documentation lacks any specs for sprinkler, faucet and irrigation system. Is there any source I can look at to get an idea how this works?

I was testing the contact sensor I made at Awkward. Here we have 21+ devices that have HomeKit setup. 8 Devices share the same iCloud account and the other 13 are HomeKit guests.

Setting up the device works fine, but after the setup all the other devices want to start a session too. This causes esp-homekit to eventually crash.

After the crash the device restarts and the sessions are eventually restored, so it's not a high priority, but it is something that happens.

Crash log:

>>> homekit_client_process: [Client 7] Finished processing
>>> homekit_client_process: [Client 8] Got 257 incomming data
>>> homekit_server_on_pair_verify: HomeKit Pair Verify
>>> homekit_server_on_pair_verify: Free heap: 6704
>>> tlv_debug: Got following TLV values:
>>> tlv_debug: Type 6 value (1 bytes): \x03
>>> tlv_debug: Type 5 value (120 bytes): \x11s\x98\x87z\xED\xD4zT\xD4-\\H\xED\xDA1Z\xE1o\xCA\xBD\xFB-E\x9F.\xFE\xFC\xC0w\xBF\xA6\xF1\xD8\xB6S\xC6+\xA1s\xE5\xE3'\x052S1\xF1U\xB4B\xE4\x05\x17v>&#\xDB\x16R\xAD\x16\x89\x1Aa-\xF2\x862\xB8(C{\x9A6\x18\xCB|]+0\x93\x1A\xCAX}>\xF5L\xE2\xBC\xCA\x9C\x8A\xBA\xE9P_J.S\xD6\xF5<,L\x08\xF9\xE5X^\xF4#\xDA\xCC\xAFPXF
>>> HomeKit: [Client 8] Pair Verify Step 2/2
>>> homekit_server_on_pair_verify: [Client 8] Decrypting payload
>>> homekit_server_on_pair_verify: [Client 8] Searching pairing with 39AB5966-3CCD-494E-9CB6-FB41DA29BC9B
>>> HomeKit: [Client 8] Found pairing with 39AB5966-3CCD-494E-9CB6-FB41DA29BC9B
>>> homekit_server_on_pair_verify: [Client 8] Verifying device signature
>>> send_tlv_response: [Client 8] Sending TLV response
>>> tlv_debug: Got following TLV values:
>>> tlv_debug: Type 6 value (1 bytes): \x04
>>> client_send: [Client 8] Sending payload: HTTP/1.1 200 OK\x0D\x0AContent-Type: application/pairing+tlv8\x0D\x0AContent-Length: 3\x0D\x0AConnection: keep-alive\x0D\x0A\x0D\x0A\x06\x01\x04
>>> HomeKit: [Client 8] Verification successful, secure session established
>>> homekit_client_process: [Client 8] Finished processing
>>> HomeKit: Got new client connection: 11
>>> homekit_client_process: [Client 10] Got 168 incomming data
>>> homekit_server_on_pair_verify: HomeKit Pair Verify
>>> homekit_server_on_pair_verify: Free heap: 3996
>>> tlv_debug: Got following TLV values:
>>> tlv_debug: Type 3 value (32 bytes): \x11\x0F\x18\xE7\x19*\xA1\x89:x\x8EO\xC3y\x0C\xE2\x16\x1B4oS\xCBRY/\x8B\x80&\xFD}\xF7q
>>> tlv_debug: Type 6 value (1 bytes): \x01
>>> HomeKit: [Client 10] Pair Verify Step 1/2
>>> homekit_server_on_pair_verify: [Client 10] Importing device Curve25519 public key
>>> homekit_server_on_pair_verify: [Client 10] Generating accessory Curve25519 key
>>> homekit_server_on_pair_verify: [Client 10] Exporting accessory Curve25519 public key
>>> homekit_server_on_pair_verify: [Client 10] Generating Curve25519 shared secret
>>> homekit_server_on_pair_verify: [Client 10] Generating signature
>>> homekit_server_on_pair_verify: [Client 10] Generating proof
>>> homekit_server_on_pair_verify: [Client 10] Encrypting response
>>> send_tlv_response: [Client 10] Sending TLV response
>>> tlv_debug: Got following TLV values:
>>> tlv_debug: Type 5 value (101 bytes): \xC92\xFB\xBAd\x9ABw\xD4\x94\xFA\x1A\xFF\xF3\x9F\x84\xA7\xE2_\x8E,\x1A?\xC1:\x99\x0A{\x82O\xF7v\xD5i\x8D\x96\x08\x00\xC8.\xF8\x96\x9B+8\xAB\x91g\x18\xA7=\\\xA5#).\xC1\xD5\x02\x07\xAB\x81*\xDA\x090DZtX\x98\x86E\xE6\xED\xAB\x1C\xC6\xC75S#\xF3O\xC8*\x08\xBB\xA0Uq:Rm\x07!%\xFE^\xEA\xA1
>>> tlv_debug: Type 3 value (32 bytes): PjIh\x1F\x16\xB1\xDAX\xB0\x96u$\x84T*h\x87\x1Bb\x87f\xDAC\x98\xE7\x0Dj\xE9\x14S\x14
>>> tlv_debug: Type 6 value (1 bytes): \x02
>>> client_send: [Client 10] Sending payload: HTTP/1.1 200 OK\x0D\x0AContent-Type: application/pairing+tlv8\x0D\x0AContent-Length: 140\x0D\x0AConnection: keep-alive\x0D\x0A\x0D\x0A\x05e\xC92\xFB\xBAd\x9ABw\xD4\x94\xFA\x1A\xFF\xF3\x9F\x84\xA7\xE2_\x8E,\x1A?\xC1:\x99\x0A{\x82O\xF7v\xD5i\x8D\x96\x08\x00\xC8.\xF8\x96\x9B+8\xAB\x91g\x18\xA7=\\\xA5#).\xC1\xD5\x02\x07\xAB\x81*\xDA\x090DZtX\x98\x86E\xE6\xED\xAB\x1C\xC6\xC75S#\xF3O\xC8*\x08\xBB\xA0Uq:Rm\x07!%\xFE^\xEA\xA1\x03 PjIh\x1F\x16\xB1\xDAX\xB0\x96u$\x84T*h\x87\x1Bb\x87f\xDAC\x98\xE7\x0Dj\xE9\x14S\x14\x06\x01\x02
>>> homekit_client_process: [Client 10] Finished processing
>>> HomeKit: Got new client connection: 12
>>> homekit_client_process: [Client 8] Got 88 incomming data
>>> homekit_client_process: [Client 8] Decrypting data
>>> homekit_client_process: [Client 8] Decrypted 70 bytes, available 0
Decrypted data (70 bytes): "GET /accessories HTTP/1.1\x0D\x0AHost: Contact\\032Sensor._hap._tcp.local\x0D\x0A\x0D\x0A"
>>> HomeKit: [Client 8] Get Accessories
>>> homekit_server_on_get_accessories: Free heap: 3384
>>> client_send: [Client 8] Sending payload: HTTP/1.1 200 OK\x0D\x0AContent-Type: application/hap+json\x0D\x0ATransfer-Encoding: chunked\x0D\x0AConnection: keep-alive\x0D\x0A\x0D\x0A
Fatal exception (29):
epc1=0x4000e143
epc2=0x00000000
epc3=0x4025fec9

0x4025fec9: sdk_pp_attach at ??:?

excvaddr=0x00000000
depc=0x00000000
excsave1=0x400018cc
Registers:
a0 400018cc a1 3fffb4e0 a2  00000000 a3  00000001
a4  00000001 a5  00000000 a6  4023eee5 a7  4023eee5

0x4023eee5: json_flush at ??:?


0x4023eee5: json_flush at ??:?

a8  4023eee4 a9  00000000 a10 4023eee5 a11 0000007b

0x4023eee4: json_flush at ??:?


0x4023eee5: json_flush at ??:?

a12 3fffb5c0 a13 00000001 SAR 00000010

Stack: SP=0x3fffb4e0
0x3fffb4e0: 40105e36 60000000 00000074 3fff53ce

0x40105e36: __ssputs_r at /home/src/esp/newlib-cygwin/build/xtensa-lx106-elf/newlib/libc/stdio/../../../../../newlib/libc/stdio/nano-vfprintf.c:233

0x3fffb4f0: 3fff5734 4023eee4 3fff53b8 0000001e

0x4023eee4: json_flush at ??:?

0x3fffb500: 00000020 3fff5734 3fff55a4 4023eee4

0x4023eee4: json_flush at ??:?

0x3fffb510: 00000000 3fff5734 3fffb5c0 4010601c

0x4010601c: _svfprintf_r at /home/src/esp/newlib-cygwin/build/xtensa-lx106-elf/newlib/libc/stdio/../../../../../newlib/libc/stdio/nano-vfprintf.c:531

0x3fffb520: 3fffc1c9 3fffc193 00000000 00000037
0x3fffb530: 3fff53b8 00000000 3f3020a4 40214531

0x40214531: __sflush_r at /home/src/esp/newlib-cygwin/build/xtensa-lx106-elf/newlib/libc/stdio/../../../../../newlib/libc/stdio/fflush.c:226

0x3fffb540: 0000000a 00000000 3fff5490 4020494e

0x4020494e: prvCopyDataToQueue at /Volumes/case-sensitive/esp-open-rtos/FreeRTOS/Source/queue.c:2332

0x3fffb550: 00000000 00000000 3fff5490 40204c24

0x40204c24: xQueueGenericSend at /Volumes/case-sensitive/esp-open-rtos/FreeRTOS/Source/queue.c:2332


Free Heap: 3196
_heap_start 0x3fff1ae0 brk 0x3ffffe78 supervisor sp 0x40000000 sp-brk 392 bytes
arena (total_size) 58264 fordblks (free_size) 2804 uordblocks (used_size) 55460

ets Jan  8 2013,rst cause:2, boot mode:(3,7)

load 0x40100000, len 2292, room 16

0x40100000: _stext at ??:?

tail 4
chksum 0x57
load 0x3ffe8000, len 772, room 4
tail 0
chksum 0x0b
csum 0x0b

rBoot v1.4.0 - [email protected]
Flash Size:   8 Mbit
Flash Mode:   DOUT
Flash Speed:  40 MHz
rBoot Option: Big flash
rBoot Option: RTC data

Booting rom 0.
pp_task_hdl : 3ffefd20, prio:14, stack:512
pm_task_hdl : 3ffef780, prio:1, stack:176
frc2_timer_task_hdl:0x3fff4228, prio:12, stack:200

ESP-Open-SDK ver: 0.0.1 compiled @ Jan 16 2018 09:11:40
phy ver: 273, pp ver: 8.3

Edit Jan 16 2018: Updated wording of pairing vs sessions

Currently accessory data (including internal key and pairing info) is stored on a flash by doing raw flash memory reads/writes. For flexibility it should support alternative storage backend - SPIFFS - which would allow accessory developers to choose from different options based on their own needs. Storages should be picked via preprocessor defines which will alias storage functions to particular implementation (e.g. homekit_storage_init() will be aliased either to homekit_flash_storage_init() or homekit_spiffs_storage_init()).

With SPIFFS storage user should be able to specify base directory for HomeKit related configuration files.

Hi,
I try to add Hue characteristic like this way, but doesn't work

            HOMEKIT_CHARACTERISTIC(
                HUE, 100,
                .getter=led_hue_get,
                .setter=led_hue_set
            ),

Could you help me with this?

I was able to make it work using hap node with a raspberry as a node, but I was wondering if it's possible to write an accessory and create the hardware for that.

Tried using wifi_config.h
but when it connects to the AP the homekit device is not discoverable and it needs a reset.

void on_wifi_ready() {
    homekit_server_init(&config);
}

void user_init(void) {
    uart_set_baud(0, 115200);
    create_accessory_name();
    gpio_init();
    wifi_config_init("ESP-Homekit-Motor", NULL, on_wifi_ready);
}