Too slow to find new accessory after wiced_homekit_recalculate_accessory_database() is called.

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
Anonymous
Not applicable

Dear,

I am developing homekit bridge, and trying below sequence.

1. connect iOS (or HAT) and homekit (bridge) device.

2. add new accessory with new service and characteristic to bridge device.

3. just after 2, iOS found new device via bridge device.

1 and 2 works well but I have to wait about 3-5min before find new device from iOS.

snippet is like below.

-------------------

// setup bridge device

wiced_homekit_add_accessory( &bridge_accessory );

wiced_homekit_add_service( &bridge_accessory, &bridge_service );

wiced_homekit_add_characteristic( &bridge_service , &bridge_characteristic );

...

// start homekit

wiced_homekit_start( &apple_homekit_discovery_settings, &wiced_heap_allocated_for_database )


// setup another device when the device is connected to bridge

wiced_homekit_add_accessory( &new_accessory );

wiced_homekit_add_service( &new_accessory, &new_service );

wiced_homekit_add_characteristic( &new_service , &new_characteristic );

...

uint32_t recalcurated_size = wiced_homekit_recalculate_accessory_database();

-------------------

According to header file, it looks to ok to call wiced_homekit_recalculate_accessory_database() after service / characteristic / accessory are added. However, I have to wait so long....

Do you have any suggestion?

Note : size of "wiced_heap_allocated_for_database" and "recalcurated_size" is same..

SS.png

Following is my environment.

HAT: Version 1.0 (66)

SDK: Wiced-SDK-MFi-3.1.2

Eval board: BCM943362WCD4 EVB

Attachment : HAT log

0 Likes
3 Replies
Anonymous
Not applicable

I dont know this is correct way or not, but I can reduce connection delay by changing "homekit_host_advertise_service" func in

library/mfi/apple_homekit/homekit_gedday_host.c as below.

//    gedday_add_service( wiced_homekit_discovery_settings->name, MFI_CONFIGURE_SERVICE_TYPE_LOCAL, MFI_CONFIGURE_PORT, 300, (const char*)gedday_text_record_get_string( &homekit_text_record ) );

    gedday_add_service( wiced_homekit_discovery_settings->name, MFI_CONFIGURE_SERVICE_TYPE_LOCAL, MFI_CONFIGURE_PORT, 30, (const char*)gedday_text_record_get_string( &homekit_text_record ) );

0 Likes
Anonymous
Not applicable

There are a few things at play here.

One is that whenever a characteristic is updated or a new entry is added to the accessory table, this change is stored as a configuration number update, which is part of the mdns text record. However, we don't advertise this text record update, rather we wait for the controller such as HAT to ask us for it ( in order to reduce network traffic and comply to HomeKit spec ). So recalculating the database wont be seen until HAT requests it, which takes place every couple of minutes.

The other thing is regarding the HAT tool itself. I had a look at replicating your test case, and found something interesting. Once I have dynamically updated the database, and try to rediscover it through HAT, HAT does not seem to issue a 'Discover' command (GET accessories), immediately after the Discover request, but rather 3 minutes later. I get the impression HAT is ignoring the request and simply getting the text record, seeing that the configuration number has been incremented and issuing a discover only then. I believe you may see this too if you have a look at the HTTP transport section (seen in your your screen shot, though not expanded to show details). Can you confirm this? If so, it may be something which will be addressed in next release of HAT.

P.S

I'm not seeing the wiced_heap_allocated_for_database" and "recalculated_size" to be same. This could happen  if you executed wiced_homekit_start after wiced_heap_allocated_for_database.

0 Likes
Anonymous
Not applicable

Discussion is being locked. If you have any follow-up questions, please start a new discussion.

0 Likes