d4rkmen

process_characteristics_update: HAPStatus status = HAPStatus_Success; ... if (ch->setter_ex) { status = ch->setter_ex(ch, h_value); ... return status; Usecase is very important: when user made an action, which cannot be completed on...

Its weird, but HomeKit uses mDNS to check accessory online/offline status. Current responder implementation seems not stable.

This custom implementation is for sure the smallest memory and code footprint. Btw, the [Mongoose OS port](https://github.com/mongoose-os-libs/homekit-adk) of the ADK has affordable memory usage too. It uses user defined buffer...

@maximkulkin according to HAP spec, accessory should send notifications once in a second max. In case there are more notifications, need to queue it for a next send session, exceptions...

Constraints like min=0, max=100, step=25 makes characteristic values to 0, 25, 50, 75, 100 Other values are binding to the closest one

@nonameplum this is the thing worth to try for sure. I am really impressed how the framework saves 90% of dev time. mDNS library is very close to RFC standard...

@maximkulkin thanks, I have noticed this. There is a good range/valid value check routine in your lib (no chance to add an accessory to HomeKit otherwise) but the step value...

@maximkulkin Your idea to use a bitmask for notification status is cool, but it looks a bit complicated. Actually, a `server->characteristic_infos[]` elements could be extended with such kind of bitmask...

Pairing is still a weak place for this library. One of two times pairing step 1,2 connection dropps and process restarted (try 2), but faced "Another pairing in progress" error,...

> It was always ~30 seconds on ESP8266 did u ever tested mbedtls for this? interesting to compare