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.
HomeSpan