The only reason to have used getAccessory(aid) is to delete it, so the delete command is now invoked automatically. Function returns 0 on success (matching aid found) or -1 on fail (aid not found)
Method homeSpan.updateDatabase(boolean updateMDNS) recomputes database hash and compares with previous hash. If changed, config number is updated and saved in NVS along with new hash. If updateMDNS is true, a new "c#" MDNS record is also broadcast with the new config number. This triggers HomeKit to call for a database refresh. Method returns true if config number has changed, or false if it has not.
The "C" command computes a hash of the current database config and updates the config number if needed. If config number has changed, the MDNS "c#" record is updated and the new config number is rebroadcast. This triggers HomeKit to immediately request an update of the HAP database so that the changes can be shortly reflected in the Home App without the need to close any Client connections or reboot the device.
The config number logic has also been updated/fixed. Previously it would create a hash from the full HAP database, which includes the value of each characteristic. Thus, initial value changes of Characteristics, as a result of stored values in NVS, would cause an update to the config number upon reboot.
This is not problematic, but also not intended, as a change in value is not really a change in the database config. The new logic computes a hash of the database that EXCLUDES all Characteristic values.
Instead of creating a static configLog for display upon start-up, an info log will be generated based on real-time data whenever the 'i' CLI command is requested. This provides for more streamlined error-checking as well.
Rather than call homeSpan.poll() in the main Arduino loop() function, you can instead call homeSpan.start() at the end of the set-up function. This keeps the main Arduino loop() function free for user-defined code that will not block, and does not get blocked by, homeSpan.poll().
If using a dual-core processor, polling now occurs on core 0, instead of the core 1 (where all other Arduino stuff normally runs).
HomeSpan will throw a fatal error and halt processing if both homeSpan.poll() and homeSpan.start() are used in the same sketch.
Rather than auto-enable OTA if not already enabled in safemode, changed the logic to simply rollback to previous app if OTA was used to download a sketch that does not itself have OTA enabled, unless OTA was previously enabled without safemode.
To do: Delete all complicated SpanOTA logic that (unsuccessfully) tried to track OTA status and check SHA246 partition codes to determine if reboot was OTA or Serial. None of this is need, but some of the code may be useful for other things in the future.
Since much of the Arduino-ESP32 library is precompiled, you cannot use -DCONFIG_BOOTLOADER_APP_ROLLBACK_ENABLE to define this during compile time (it gets defined but is not used by the precompiled libraries).
TO DO: create an NVS entry that flags whether last update was via OTA. If so, automatically enable OTA regardless of enableOTA setting. This would ensure that OTA cannot be disabled accidentally by uploading a non-enabledOTA sketch to remote device.
Also updated SpanWebLog::addLog() so that the log message is also output to the Serial Monitor if the HomeSpan Log Level is set to 1 or greater.
To do: DOCUMENT ALL THIS!
Gets IP address (as char *) of last client to send a request. Useful as part of web log messages. Will return 0.0.0.0 if used outside of any code that is responding to a client request.
Added isEnabled to SpanWebLog to indicate whether Web Log has been enabled. This allows the use of homeSpan.webLog.addLog() without ever enabling (in which case the log entries are ignored).
Also included logic so that clockTime is set to "Unknown" is addLog() is called prior to WiFi being established.
Next up: replace addLog(const char *) with a variadic set of parameters with dynamic storage allocation.
Also, updated error checking so that the UUID for both custom Services and custom Characteristics are checked for syntax. A fatal error is thrown if an ill-formatted UUID is found, since this will definitely prevent pairing with the HomeApp.
The UUID for HAP Services and Characteristics are NOT error checked, since these are fixed in HomeSpan.
Also, the custom Characteristics are not validated against the optional list for a service. If the user adds a custom Characteristic to a HAP Service, it is assumed to be valid. Similarly, none of the Characteristics (HAP of Custom) in a Custom Service are validated at all.
Use homeSpan.reserveSocketConnections(n) to reserve n sockets *not* to be used for HAP. Multiple calls can be used to cumulate a total number of reserved sockets. This makes is easy to add reserveSocketConnections(n) at multiple point in the code whenever a certain number of sockets need to be reserved for use with that portion of the code. For example enableOTA() calls reserveSocketConnections(1).
If both setMaxConnections(), and one or more reserveSocketConnections(), methods are called HomeSpan will use the more restrictive net value.
Optional method to automatically turn off Status LED after a *duration* seconds. LED will resume normal operation any time it is re-triggered with a new pattern. This also resets the elapsed time used to check for autoOff.
Added true/false parsing to all integer-based Characteristics. Previously true/false was only parsed for BOOL Characteristics. For integer-based on/off Characteristics, the Home App would send a 0 for off, and a 1 for on, consistent with HAP-R2. BUT...when using Home App AUTOMATIONS, the Home App would send true/false for integer-based Characteristics, which is inconsistent with HAP-R2. This meant automations worked with lights (that use the boolean ON Characteristic) but not with fans (that use the uint8 ACTIVE Characteristic).
With this "fix", true/false will be recognized all the time (except for float- and string-based Characteristics. Confirmed that fans now work with Home App Automations.
Ranges are now checked for all Characteristics at the end of the configuration, instead of at the end of each Accessory definition. This is much cleaner and the output is easier to read.
To do: Revisit use of REQ and OPT - what should constitute a fatal error and what should be a warning.
To do: Revisit Character definitions - attempt to normalize using the methods implemented for Custom Characteristics
No need to specify both FORMAT and TYPE. For example, specifying UINT16 automatically sets type to be uint16_t.
To do: Explore if this can be used for standard Characteristics - revisit standard Characteristics definitions and structure to see if it can be simplified.
Re-worked code to allow for NO Status LED Pin and NO Control Pin. If Control Pin is not set explicitly with homeSpan.setControlPin(), there will be no Control Pin. There is no longer a default since there are too many board variations with S2 and C3 chips now supported. Same for Status Pin - it will not be defined unless set explicitly with homeSpan.setStatusPin(), with the exception that if LED_BUILTIN is defined (i.e. there is a built-in LED), then the Status LED Pin will default to LED_BUILTIN if not explicitly defined. MUST UPDATE DOCUMENTATION - THIS CHANGES DEFAULT BEHAVIOR OF HOMESPAN AND MAY REQUIRE UPDATES TO EXISTING SKETCHES
Simplified enableAutoStartAP() so it no longer takes any arguments. It now simply enables the auto launch of the WiFi Access Point at start-up if WiFi Credentials are not found.
New method setApFunction() will now be used to set an alternative method for the WiFi Access Point. This will be called anytime 'A' is typed into the CLI, which also covers the auto-launch of the AP at start-up a well as starting it via the Control Button, since both of these functions call processCommand('A').
To enable save/restore for a Characteristic, set second parameter to TRUE when instantiating. Since first parameter was optional as well, this requires setting it as well.
Next up: Must add logic to setVal() to store new value as well.
Allows the user to add a command function to the Command Line Interface. All User Commands are defined with a '@' prefix.
To Do: Document this new feature.
Only throw a non-fatal warning instead of a fatal error if a Service is missing a required Characteristic. This allows for user flexibility in leaving out required Characteristics for Services that don't seem to need them (contrary to the HAP docs).
Also, changed PositionState Characteristic back to Required (instead of Optional) in WindowCovering Service (as specified by HAP). If PositionState is not included this will only throw an error instead of a warning as a result of the above change.
To Do: Update Example 13 to properly incorporate PositionState Characteristic.
Check is not applied to STRING Characteristics. Check is performed at end of each Accessory definition so will account for any changes to min/max as a result of calls to setRange(). If initial value is outside allowable range, a WARNING (not an ERROR) is thrown.
Also added new flag "staticRange" for all Characteristics that indicates whether the min/max range can be changed. An ERROR will be thrown if setRange is attempted for a Characteristic having staticRange=true.
Next TO DO: Complete entry of default min/max into all Characteristics (except BOOL and STRING) defined Span.h so that setRange() error checking works for all Characteristics.
Added Characteristics.h file that defines all static data for HAP Characteristics. Changed macros in Services.h to use this new HapChar structure.
Code is now more streamlined and ready for mix/max range-checking to be added.
Ensures robustness and is fully backwards compatible. User does NOT have to specify a template parameter, as the compiler determines this from the setVal() argument itself. Allows for any numeric type to be properly mapped to correct HAP format for the Characteristic.
This change is also needed to prepare for the refactoring of SpanRange, the addition of UVals to store HAP min/max, and new error-checking of min/max limits within setVal.
Updated setVal() logic to ensure that every possible combination of parameter type and Characteristic type is handled properly, and without generating a compile-time error related to ambiguous parameters.
New SpanService method addLink(SpanService *svc), where svc is a pointer to the SpanService that is being specified as a Linked Service for the current Service.
addLink() returns a pointer to "this" so may be chained
homeSpan.enableOTA() is now homeSpan.enableOTA(boolean auth=true). Set auth=false to disable password authentication. Set to true, or leave blank, to enable password authentication.
homeSpan.begin() automatically resizes maxConnections to ensure it is at or below maxLimit, where maxLimit=CONFIG_LWIP_MAX_SOCKETS-2-otaEnabled.
maxConnections still defaults to 8 if unspecified, which means it is reduced to 7 if OTA is enabled. Users should set maxConnections to a lower number is they have implemented other socket-based services in their sketch
HomeSpan will call a user-defined function upon establishing WiFi connectivity.
Set function with homeSpan.setWifiCallback(f), where f must be of form void f().
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.
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."
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)
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).
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.
* 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.
Modified SpanCharacteristic::sprintfAttributes to streamline logic and add special handling for the ProgrammableSwitchEvent Characteristic as required by HAP: the value returned for the database or any read request must be set to null (i.e. "value":null). The only time the real value should be returned is when the device sends a EV/Notify message (when the button is pressed). Verified that the example works as expected!
TO DO: Add functionality to allow for Service Namespace and Index label so that you can have multiple programmable pushbuttons in one service - this requires logic for HAP LINKED SERVICE functionality.
Added validation to ensure all Accessories have a AccessoryInformation Service and all Accessories have a HAPProtocolInformation Service, unless the device is configured as a bridge, in which case only the first Accessory requires a HAPProtocolInformation Service.
Checks to ensure that: (A) Characteristic is allowable (i.e. either required or optional) for the defined Service, and (B) Characteristic has not already been instantiated for the defined Service.
The 'A' command now resets any existing WiFi functionality so that it can start an Access Point without needing to first reboot.
To Do: Add a method to cancel out of apConfigure() and reboot by pressing control button.
To Do: Create time-out for commandMode()
Changing code so that it is possible to run HomeSpan without configuring WiFi. HomeSpan can already run without being paired, but requires WiFi at start-up. No reason to force WiFi to be used if device has buttons to operate the appliance withouth the need for WiFi or a connection to HomeKit. Work in progress...
Zephyr3, the latest version, was moved into its own repo and renamed ZephyrVentHood.
Deleted Zephyr1, Zephyr2, and Zephyr3, which are no longer needed.
Flattened folder structure for Examples and placed them all in top-level directory
Started adding lists to the first few Services in Service.h. This is a longer-term project to enable HomeSpan to validate a configuration and check that all Services have all required Characteristics and that any optional Characteristics defined are indeed permitted.
Full initialization now depends on "isInitialized" flag instead of monitoring Wifi connection, to protect against a loss of WiFi causing a re-initialization, instead of just a wifi reconnect with initWifi() alone.
Gregg