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.
This allows the "src.ino" test file to once again properly compile without requiring modifications to any existing HomeSpan sketches. This was needed to ensure src.ino can find object code in "extras", which is now required to use the new statusDevice() method. Since the Arduino IDE only copies files that are in "src" folders, "extras" needed to be moved to "src/extras". For backwards compatibility with all other sketches, the "extras" directory now contains stubs for the ".h" include files.
Rather than use ESP32 timers, simply spawn a new task that turn on/off LED using simple delays. By avoiding the use of the ESP32 timer, we are no longer limited by the number of Blinkers possible. Also, Blinker relied on the timer interrupt, which crashed when it tried to call Pixel since Pixel in turn uses interrupts from the RMT. Switching to spawned tasks is much cleaner and does not consume more CPU time since the timer interrupts were driven by CPU anyway.
Blinker class and generic LED class are now in extras.h. Blinkable Interface is also in extras.h.
To Do: Incorporate new Blinker class into HomeSpan code
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.
This optional flag does not seem to have any affect on the Home App and does not produce any messages indicating that the device needs additional setup. Was hopeful this would have prevented the "Not Supported" message on a Home App Tile that is configured as a bridge, but without any other Accessories.
Gregg