Memory footprint for Bridge with >100 accessories

[mgoeller]

We are using the commercial esp-homekit-sdk available under NDA to develop a Bridge, and are testing with an amount of accessories close to the HomeKit limit of 150 per bridge. At ~120 single accessories, we are running into memory issues, and are not able to OTA update the ESP32 anymore, since the accessories are using approximately 140KB, and starting the HomeKit server another ~40KB.

A few general questions regarding this:

1. There also exists the port of the official Apple HomeKit ADK for ESP32. Does this have a smaller memory footprint?
2. Which SDK is recommended for new HomeKit hardware developers? esp-homekit-sdk or esp-apple-homekit-adk?
3. What about the memory allocation suggestions, mentioned by @maximkulkin here. Any improvements to the memory footprint in the pipeline?

Any advice on these questions @shahpiyushv? Thank you in advance!

[mgoeller]

Another option would be to use hap_stop() before an ota update, but this function is still mentioned as todo?

esp-homekit-sdk/components/homekit/esp_hap_core/src/esp_hap_main.c

Lines 384 to 389 in fac2032

	int hap_stop(void)
	{
	int ret = HAP_SUCCESS;
	//todo
	return ret;
	}

[shahpiyushv]

@mgoeller

1. There also exists the port of the official Apple HomeKit ADK for ESP32. Does this have a smaller memory footprint?

We haven't really done 1:1 comparison of the RAM footprints. The way the accessory database is managed by esp-homekit-sdk and the ADK is much different, which becomes more relevant in case of bridges.

2. Which SDK is recommended for new HomeKit hardware developers? esp-homekit-sdk or esp-apple-homekit-adk?

It actually depends on your requirements and the comfort you have using the APIs. The APIs of both the SDKs are very different. esp-homekit-sdk also has additional features required for real products, which includes Unified Provisioning (required for Android controllers) and Remote control (with Alexa/GVA integrations with ESP RainMaker), both of which can be found in this example. Additionally, the ADK is maintained by Apple, whereas esp-homekit-sdk is maintained by Espressif. So, we don't have much control over the ADK APIs and structure.

3. What about the memory allocation suggestions, mentioned by @maximkulkin Espress esp-homekit-sdk? maximkulkin/esp-homekit#185. Any improvements to the memory footprint in the pipeline?

I suppose the suggestions are meant for Apple's ADK, which as mentioned above, is maintained by Apple. Even then, as per my understanding, the pre-allocations done there could just be to ensure that the functionality (as expected by the Certification requirement) does not get affected because of any runtime allocation failures. I am not sure if the esp-homekit referenced here is meant for HomeKit Certified products or just for non commercial purposes. So it could potentially have lower footprint.