* Changed ~SpanService to virtual function to ensure any user-defined destructor is also called
* Found/corrected bug in error message related to defining a Characteristic without any Service
* Added warning/error ID numbers to warning/error messages
* Other misc changes to clean up compiler warnings
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.
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.
Gregg