Espress esp-homekit-sdk?

[TLCary]

Two months ago the manufacturer released an sdk for HomeKit. Espressif Homekit
Has anyone compared the two? I can't find any implementations of the Espressif code, there are implementations of this projects.
The code here hasn't been updated in years, which may simply be because its perfect.
Suggestions on where I should start, with this code base of ESpress's. Any insight?

[AramVartanyan]

@TLCary it is not true that esp-homekit is not up to date. The last commit was 3 days ago. MaximKulkin is taking good care of this library. It is fast and seamless.

And also not true that esp-homekit-sdk (by Espressif) does not have any implementations.
You can check original examples inside the link you have shared. They are working as explained.
I am doing my own test project https://github.com/AramVartanyan/esp-homekit-sdk/tree/master/examples/waterbatt. Stay tuned, if you’re interested.

[TLCary]

Somehow I missed those. Apple's own HomeKitADK has also been ported to the ESP8266 by Espress. But looking at the issues and examples, MaximKulkin's work appears to be more mature and easier to implement. I don't see Apple's code or Espress's code being any better than MaximKulkin's. Definitely interested in your testing. It would also be nice to see Bluetooth support enabled. It's in Apple's ADK but even Espress hasn't implemented it yet and its been over six months since they said they planned to. Thanks Aram.

[maximkulkin]

I tried HomeKitADK port by Espressif on ESP32, it does work. Haven't done any testing on ESP8266 though. esp-homekit is much better optimized in terms of memory usage. Just consider this: they allocate 1Kb input buffer and 1.5Kb output buffer for each potential session (which by default is set to 9). That's like 25Kb of RAM right there. Not to mention joy of defining an accessory services. Also, it is not actively maintained or developed either.
There's also Espressif's own HomeKit SDK (I guess, they started developing it earlier than Apple providing their SDK), is pretty awkward to use too. Also I find it pretty naive.

[d4rkmen]

This custom implementation is for sure the smallest memory and code footprint.
Btw, the Mongoose OS port of the ADK has affordable memory usage too.
It uses user defined buffer (1-2kb) for i/o and ~700 bytes/connection
From the other side it has features like notifications grouping, bind characteristic value to constraints (min/max/step) etc

[maximkulkin]

@d4rkmen just out of curiosity, what is those "notifications grouping, bind characteristic value to constraints (min/max/step)" features about?

[d4rkmen]

@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 are button events, these should be delivered immediately

[d4rkmen]

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]

@d4rkmen sorry for the off-topic. But could you briefly describe mongoose and it's homekit implementation cons/pros?
I was considering mongoose some time ago but in the end, I didn't try.

Especially their's mDNS stability and device availability.

[d4rkmen]

@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 and works good. adk-homekit on ESP32 works flawless, but ESP8266 UDP lags (packet dropps) and as result discovery service goes offline sometimes (probably problem in old NONOS SDK 3.0.x patched for LWIP2 used) But even so, it works fine, and with max connection = 16 still have 26kb of RAM. Optimised MBEDTLS makes ESP8266 pairing time to 12 secs (vs 26 in wolfssl)
Not related to mOS port but to entire apple ADK is: inconvinient accessory scructure definition (see examples), but if use code completition editor like VScode its much easier and can live with this.
Sorry for the offtopic.

[maximkulkin]

@d4rkmen Not sure if you've noticed, but min/max/step properties for characteristics, along with valid values and valid value ranges is available from day one in esp-homekit. As of notification grouping, I find it to be worthless feature: a) it's just a recommendation aimed to avoid a lot of network traffic, not a hard requirement; b) it increases notification lag. Implementation is trivial, but it's just not worth it. Do not update your characteristics multiple times a second.

[d4rkmen]

@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 is ignored. Offcourse this is not a big deal at all. I just want to say the ADK covering all these cases, thats all. As for notifications:

Network-based notifications must be coalesced by the accessory using a delay of no less than
1 second
Excessive or inappropriate notifications may result in the user being notified of a misbehaving
accessory and/or termination of the pairing relationship

Sounds very not like recomendations do. Anyway, it works for now :) I already faced one thing like this: after apdate to iOS 14.2 accessories, not changing the pairing flag in txt record just become unavailable, and before 14.2 it worked fine
Another thing about notifications (if you not mind):

Indications shall not be sent to the controller that changed the value of a characteristic if the change was due to a write from the
controller

This line, probably, should be rethought. Correct me if I miss something, please.

esp-homekit/src/server.c

Line 3060 in 7cb0512

homekit_characteristic_notify(ch, h_value);

[maximkulkin]

Sounds very not like recommendations do.

Well, they had to say that. Just don't let that happen. The only case I can imagine when that happening is when multiple controllers start changing values at the same time and updates will be spaced with subsecond intervals. Which is not likely in normal use.

after apdate to iOS 14.2 accessories, not changing the pairing flag in txt record just become unavailable, and before 14.2 it worked fine

That is a fair behavior IMO. You shouldn't do that.

Indications shall not be sent to the controller that changed the value of a characteristic if the change was due to a write from the controller

Yes, this is something I had before and then dropped in favor of optimizing memory usage. Now that I think of it, it can be easily added back at the cost of a few dozen bytes.

I might review notifications system sometime to make it more compliant.

[d4rkmen]

@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 field (1 bit for one active session)

I might review notifications system sometime to make it more compliant.

looking forward to see it. thanks