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.
To do: Create special-handling code for ProgrammableSwitchEvent Characteristic (according to HAP, it has read permission, but must always return a null). Consider adding special flag to PR+EV
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.
Completed macro to use HAPCharType for define Span Characteristic structures. HAPCharType includes name, ID, and permissions. The macro adds value type (e.g. int, double) and default value. To do: Create Span Characteristics for all remaining HAPCharTypes defined in HAPConstants.h
Created HAPCharType and added vectors for required and optional characteristics to every service. Next up: add all HAP characteristic types to HAPCharType
This prevents re-visits to the landing-page that resets the statusLED every time. Also eliminates the need to keep track of when landing page is accessed and to perform any initial re-direction.
Ensures statusLED indicates a client is connected as soon as it received its first GET, even if the re-direction to /landing-page is yet to be accessed. This was needed to trigger LED_AP_CONNECTED when connecting with QR code.
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...
Instead of pre-defining RF433 and RF315, the user should define their own RFControl{pin} as a variable in their device-specific DEV_*.h file. Makes RFControl more generic and not specific to any transmitter name (such as 433 or 315). Also means that the pin can be set by the user instead of having to modify RFControl.h deep in the library.
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.
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.
Gregg