Specify with homeSpan.setSketchVersion(char *).
Read back with homeSpan.getSketchVersion().
Also, MDNS now broadcasts three new fields:
hspn = HomeSpan Version
sketch = Sketch Version
ota = "yes" if OTA enabled, else "no"
These are all optional to HAP but useful if trying to keep track of version updates when using OTA and Serial Monitor is not available.
OTA pasword now stored in NVS. Use 'O' command to change from default. Note password is stored as MD5 hash, and is therefore unrecoverable. Changes to password DO NOT take effect until next reboot. Password CAN be changed even if OTA has not been enabled for sketch. Blank passwords are not allowed.
Stored password can only be erased with 'E' command.
A 16-byte SALT with a leading zero would be sent as only a 15-byte number. The chance of this occuring is 1 in 256, which is small but still significant. Solution is to specify required size of MPI output in loadTLV. This forces mbedtls_mpi_write_binary() to pad with leading zeros.
Also eliminated unused code (TLV pack_old).
Setup ID can now be stored in NVS and set dynamically with the 'Q' command. However, homeSpan.setQRID(char *id) will override if present, but will not change the default stored in the NVS. This default wil be used once again if homeSpan.setQRID() is removed from the sektch.
If the NVS is empty, the default is set to "HSPN" as in version 1.1.4.
Class used for the creation and storage of a pairing QR Code (just the text, not the actual graphic) from a HAP Setup Code, HAP Category, and HAP Setup ID. The resulting QR Code text is output to Serial Monitor whenever the SetUp Code is generated or changed. The user can type this text into any QR Generator to create a QR Code graphic for pairing the device to HomeKit (in lieu of creating a printed tag of the Setup Code formatted using the Scancardium font).
Though not needed for HomeSpan, this class implements all the settings and parameters (such as Version and Reserved) used to generate any Apple HomeKit QR Code.
This class is used internally by HomeSpan and is not intended for the end-user.
HomeSpan now broadcasts a Hashed Setup ID as MDNS "sh", which is used when pairing with a QR Code instead of a Setup Code. A text version of the resulting QR code is output to the Serial Monitor whenever the 9-digit Setup Code is generated or changed. The text version of the QR code can then be input into any QR Code Generator to create a pairable QR Code.
The default Setup ID used to create the Hashed Setup ID is "HSPN". This can be changed with homeSpan.setQRCode(const char *id), where id is exactly 4 alphanumeric characters. If not, the request to change the Setup ID is silently ignored and remains "HSPN."
This allows the Serial Monitor to send NL or CR/NL at end of each line. A newline ('\n') must be at the end to terminate reading from the Serial Monitor, but any preceeding carriage returns are stripped out.
HomeSpan defaults to running the HAP Server on port 80 (the standard HTTP port). This method allows the user to over-ride the default and have HomeSpan run the HAP Server on any other port.
ALSO: In updating this portion of the code, identified an additional parameter to the ESP32 version of WiFiServer that allows one to specify the number of simultaneous Server connections. The ESP32 default is 4, which suggests that the ESP32 was internally juggling connections that HomeSpan was keeping open (since the HomeSpan default is 8 connections).
This WiFiServer call has been updated to now specify both the port number AND the number of maximum simultaneous connections (to match whatever has been set by HomeSpan). This may or may not result in improving performance when more than 4 clients are connected.
LED_BUILTIN is NOT defined for all ESP32 boards - some do not have a built-in LED! Instead, Status LED now defaults to Pin 13, as opposed to LED_BUILTIN. Also, added a new method, homeSpan.getStatusPin(), to return the pin number used for the Status LED, whether or not it remains the default (13) or is changed by user with homeSpan.setStatusPin(pin). This method is now used in the DEV_Identify.h file for each example, instead of using LED_BUILTIN (which otherwise won't compile for boards without a built-in LED)
Matches new logic in HomeSpan CLI, except that wait time cycles from 2 to 10 seconds in steps of 2 seconds, then repeats, since user is expected to be manually monitoring the process, and the Access Point auto times-out in 300 seconds anyway.
WiFi connection now occurs asynchronously so that if WiFi is lost, or cannot be connected at start-up, the device still operates intead of blocking while it tries to connect. The new logic should allow for a wider range of chips to connect.
Program now halts if more than 41 Accessories are defined. This allows for a bridge to have 40 Accessories. HAP limit is 150, but there is not enough memory in ESP32 to robustly handle more (testing up to 50 LightBulb Services worked, but was sluggish).
Switched from using fixed buffer, httpBuf, to a TempBuffer to allow for dynamic allocation of memory when assembling and transmitting large blocks of data. This was causing a memory overflow of the static httpBuf when responding to a getAccessories() request for a large number of Accessories.
1) Used `const char *` instead of `char *` where appropriate, including the need to create a dummy blank string for us in certain places.
2) Set initialization of WiFiClient to 0 instead of NULL, since WiFiClient is not a pointer (probably don't need to set it to anything since WiFiClient overrides the boolean operator anyway).
3) Cleaned up some of the messaging and logic when WiFi tries to connect so that users know to wait a bit.
4) Only remaining warning messages are for casting SpanService to (void *), which I think i unavailable (and is not forbidden).
To Do: Go through examples and check for warnings (will likely need to convert `char *` to `const char *` in many places.
User can specifiy a REQUIRED minimum version on the HomeSpan Library for the sketch to compile. If the library version is older, the pre-processor will halt the compilation with a #error output
RFControl::phase() allows you to add either a HIGH or LOW entry (i.e. a single phase of a pulse. RFControl::add() continues to add a full HIGH/LOW pulse so these changes are fully backwards compatible.
Made Characteristic::PositionState **optional** for Service::WindowCovering. This appears to be a bug/exception in HAP-R2. Need to reflect this in on-line docs.
* if Accessory ID is NOT specified, the default is aid=1+aid of last Accessory, with aid of very first Accessory always set to 1.
* aid of first Accessory must ALWAYS be set to 1 - if user over-rides with another value, error will be thrown
* validation now includes checking for duplicate aids, as well as ensuring the first Accessory is always aid=1
If not specified, "aid" defaults to an index number representing the order in which the Accessories were created. Values are stored as uint32_t (which is more limited than HAP requirements of uint64_t, but makes the code easier).
TO DO: Must add validation to ensure duplicate aid values are not used.
button(int pin, boolean isLong) changed to button(int pin, int pressType), where pressType can be SpanButton::LONG, SpanButton::SINGLE, or SpanButton::DOUBLE. Updated Example 16 and confirmed everything works as expected.
To do: Review all prior examples and update SpanButton when needed. Also need to update Zephyr Vent Hood code!
Added ServiceLabelIndex Characteristic, which seems to be required as noted in HAP specifications. However, linking to a ServiceLabel Service does not appear to be required, so there is no need to build any Service-Linking logic into homeSpan - will wait for use-case to be identified.
To do: Add support for double-click to SpanButton, then include in Example 16.
Gregg