- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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..
Following is my environment.
HAT: Version 1.0 (66)
SDK: Wiced-SDK-MFi-3.1.2
Eval board: BCM943362WCD4 EVB
Attachment : HAT log
- Labels:
-
SPI
- Tags:
- homekit
- wiced bridge
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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 ) );
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Discussion is being locked. If you have any follow-up questions, please start a new discussion.