Allows for bi-directional transmission between main HomeSpan device and one or more remote devices.
To Do: Create and test with Temperature Sensor Example
Added SpanPoint::setAsHub(), which is called after homeSpan.begin() to set device as Hub so SpanPoint knows not to change WiFi channel.
Also added check to make sure there are no SpanPoint objects instantiated before a call to homeSpan.begin() (if it is called at all).
This enables SpanPoint to operate as a standalone library with no reliance on anything in HomeSpan.
To Do: migrate all HomePeer code into SpanPoint. This will yield a universal standalone HomePoint library that can be used for BOTH the receiver and the sender (which automatically means two-way communication is always possible)
Verified ESP-NOW is communicating correctly with HomeSpan. Verified encryption works. Next step - create linkages between incoming data and Services; create queue structure to transfer data.
Eliminated constructor that had no pin parameter. Pin parameter is now always required. Since PushButton was not part of HomeSpan API, these changes should not impact any users.
Only initialize MDNS, WebLog, and OTA when first connecting to WiFi. Do not re-initialize upon re-connections after a disconnect.
Also, add number of disconnects, and reset_reason() to WebLog
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.
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.
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.
Callback function must be of type void()(boolean isPaired). Will be called when device is paired and when device is unpaired. Allows for user-defineable actions upon device pairing/unpairing.
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.
This allows you to add an optional "description" to a Characteristic. This is not the same as the name of a Service and is generally not used by the Home App. However, it appears to be consumed by the Eve app, which can be helpful in some circumstances when developing custom characteristics.
This returns a vector of linked Services that can be used in a for-each loop as such:
for(auto services : getLinks()){ ... }
Must cast services into specific Service type to access anything not generic to the SpanService class
Second optional argument to setVal() determines whether or not HomeSpan sends notification of new value to HomeKit. Default if left blank is "true" for backwards compatibility.
And also converted ERRORS to WARNINGS when a Characteristic that is not in the REQ or OPT list is specified for a Service. This allows the user to add any Characteristic to any Service without forcing an Error (just a Warning).
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.
This will cause a Warning (not an Error) at compile time indicating the class has been deprecated and that the Characteristic::setRange() method should be used instead. Sketch will still run and SpanRange will still function correctly if used. Will delete from code base at some point in the future.
Gregg