Completely replaced Example 11, which showed how to use setPrimary() since this no longer seems to have any impact on HomeKit. Changed sketch name from ServiceOptions to ServiceNames.
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!
If LOG1() or LOG2() is only provided with a SINGLE argument, then Serial.print() is called. This allows you to continue using LOG1() and LOG2() to directly print any variable or object that is handled by Serial.print(), such as an int, double, or even an IPAddress.
If LOG1() or LOG2() is provided with multiple arguments, the first is considered the format and Serial.printf(format...) is called. This allows you to use printf-like functionality within LOG1() and LOG2().
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.
Greatly simplifies use interface. No need to specify or save channels. And no need to even save pin number since that can be found using LedPin->getPin() method whenever needed.
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.
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.
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)
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.
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
No need for any new methods - default is now that longPress repeats every longTime milliseconds provided button continues to be held down. Once a longPress is triggered, a shortPress will not be triggered until button is released.
SpanButton now instantiates PushButton instead of keeping track of its own triggering logic. This means that SpanButton longPress() is triggered by holding down the button for longTime WITHOUT the need to release. This is a desired change.
Next: Must update Example 15 to state that SpanButtons trigger a long press withouth needing to be released.
To do: Consider adding a "repeating mode" for longPress in which the SpanButton re-triggers every longTime while button continues to be pressed. Best way to implement is probably by creating a PushButton::extend() method.
Also moved StatusCode definitions from Settings.h to HAPConstants.h. There was no reason to have the user return a StatusCode of OK or UNABLE from update() since the only other choice was BUSY and HomeKit does not seem to distinguish errors. Either it's okay or not okay, which can more easily be represented by a simply return of TRUE or FALSE from update().
The user now needs to know nothing about StatusCodes. All Examples were modified to change StatusCode update() to boolean update() and return(StatusCode:OK) to return (true).
Much simpler.
Includes abilty to change brightness of light through HomeKit as well as with button. However, the vent light is too unstable to do this perfectly, and increasing brightness by stepping through multiple decreases is annoying. To do: Create Zephyr3 without brightness control and test to see how it works in practice.
AND updated Example 13 to reflect new loop() framework in place of SpanEvents. ALSO found a bunch of inconsistencies with WindowCovering HAP documentation. PositonState and HoldPosition are NOT used by HomeKit. However, HomeKit has a full slider for controlling shades which makes a Hold Button no longer needed. See Example 13 for details. Open to do: add commentary to Example 13 and eliminate SpanEvents from library!
Renumbered Example 11 (RGB_LED) to Example 10; Example 12 (ServiceOptions) to Example 11; Example 13 (ServiceLoops) to Example 12; and Example 14 (TargetStates) to Example 13. Example 14 is now the PushButton example (previously the TimedReset Example).
To do: Must update Door and Window code in Example 13 (TargetStates) to utilize new loop() framework. Must also delete all references to TimedResets in library code.
Updated Example 10NEW to fully reflect the use of loop() methods instead of TimedResets to emulate a push button. Renamed Example 10 to Example 14, since it must come after we introduce loops(). Deleted both original Example 10 and Example 10NEW
This uses loop() method to auto-reset the blinking LED controller after 3 seconds instead of requiring the use of a TimedReset object. To do: eliminate all TimedReset code as it is no longer needed. Will also need to renumber examples, since new Example 10 uses loop() which is not introduced until after current Example 13.
Completed new framework for using loop() methods and deleted all code related to new SpanEvent() and event() loops. Re-worked Example 13 to utilize new framework and validated it functions as expected.
Service loops() called for only those Services with over-ridden loop() methods. TO DO: update event logic to follow new framework. Vector should point to all CHARACTERISTICS that are updated to setVal()
Added detailed notes section to further explain all processes related to Event Notifications. Foreshadowed next example, which will be a Service supporting current and target state characteristics.
converted checkedTimeResets() from two-pass logic that first computes the required size of SpanBuf to a single-pass that utilizes vector<SpanBuf> instead. Much cleaner and easier.
checkEvents() now allows for multiple characteristics to be updated by service->notify(). This change included the use of vector<SpanBuf> to dynamically create the the temporary storage needed. To do: re-work similar routines to use vector<SpanBuf> instead of needing to perform two passes each time to gauge size of SpanBuf array needed.
creating code to allow for multiple characteristics to be updated within event() call. To Do: define anogther sensor that supports multiple characteristics. also need to check that "new SpanEvent" works as expected from within a defined service.
Transtioned to all getter methods: getVal(), getNewVal(), updated(), using templates for all floats.
Finalized templates for getVal and getNewVal, including making <int> default so it does not have to be set for most getVal() and getNewVal() calls. Works for booleans as well. TO DO: Re-work and check ALL prior examples to ensure they use getVal, etc., and DON'T access value, newValue, isUpdated, directly.
Gregg