setMaxConnections() was deprecated many version ago and is now deleted
reserveSocketConnections() is no longer needed since new HomeKit architecture does not require more than a few connections - this function has been deprecated and if used will not do anything
This hopefully addresses memory leak that occurs when not using a Home Hub and connections constantly drop and re-establish.
To do: must add back logic for notifications using new hap linked-list structure, and then delete static hap array code.
Also adds: homeSpan.controllerListBegin(), homeSpan.controllerListEnd()
Also adds: Controller::isAdmin(), Controller::getID(), Controller::getLTPK()
To accomplish this, needed to move Controller definition from HAP.h to HomeSpan.h
Also, converted Controller from struct to class to ensure Controller data is protected from being modified now that it is exposed through condstant iterators.
It appears that HomeKit requires devices with more than 3 Accessories to be configured as a bridge. If not, the Home App will ignore any functional Services in the first Accessory and treat it like a bridge regardless. Device with 3 or less Accessories do not require a bridge configuration.
Checked that this is correctly interpreted by HomeKit using adaptive light TLV.
TLV code is now ready for documentation and then transfer to dev branch.
...as well as SpanService.getIID() and SpanCharacteristic.getIID().
This provides control of IIDs used for each Service and Characteristic.
By using this with adaptive lighting test, was able to verify that HomeKit can interpret TLV values of 1 byte, 2 bytes, and 4 bytes, but not 3 bytes. Suggests that TLV values need to be multiples of 2 (i.e. uint8, uint16, uint32). Will change TLV value-writing methodology so that padding zeros are used to round to 1, 2, 4, or 8 bytes.
Add getLen() and getTag() method to get length and tag of tlv8_t.
Also overrode subscript operator [] so you can access any element of internal uint8_t array.
Given previous additions (such as getVal()) there is now no reason to need to access the underlying std::unique_ptr directly.
Makes it easier to chain .add() functions as well as dynamically create sub TLVs.
Changing TLV8::add() in this fashion also required updating various use cases of TLV::add() in HAP.cpp where add() was used to reserve space for a blank TLV element. All changes have been tested.
This is much more memory efficient. Instead of decoding entire STRING from base64 to a temporary buffer or potentially very large size and then unpacking into TLV object, we decode a maximum of 48 characters at a time and unpack the resulting 36 (max) bytes until entire STRING is consumed.
getTLV() returns pack_size of final TLV, unless there is a problem with conversion, in which cae TLV is wiped and return value=0
Works, but is memory-inefficient since it decodes entire string before unpacking. Need to add new functionality to TLV8 so that unpacking can be done in chunks similar to how pack() works.
Also need to create getNewTLV() OR make all get/getNew generic to reduce code size.
Though this increases space requirement for TLV8 (just a little), using std::list allows adding elements directly to end, which ensure the order is maintained when packing and unpacking. Will avoid potential confusion when TLV8 is used for Characteristics.
Throws warning, but still performs change, if setVal() is used within update() to change the value of a Characteristic that is being updated by the Home App, UNLESS the Characteristics has requested a write-response (in which case setVal() is expected).
Throw warning, and DOES NOT perform change, if setVal() is used on a Characteristic without EV permission, UNLESS it has been used in update() in response to a write-response request.
Also added diagnostic to 'i' CLI command that indicates which connections have currently asked to EV Notifications for each Characteristic. Only applies if EV permission is set for a Characteristic.
Gregg