Significantly reduces memory usage - unordered_sets take up much more memory and using std::find from <algorithm> is as efficient as using find() method of an unordered_set.
To do: Remove all uses of unordered_set across HomeSpan wherever possible
This has no effect on the code but the names of the macros can be used as flags for an external script to autogenerate documentation in the form of a list of all services and characteristics supported by HomeSpan
Similar to CUSTOM_CHAR_STRING() macro, but does not include a parameter to set the default value (since the user can type an invalid string). Instead, user setData after creating the Characteristic as needed.
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.
Need to revisit Television sketch - the latest iOS seemed to have disabled the ability to dynamically set visibility of input sources. Checking/Un-Checking the visibility radio buttons either during pairing, or after pairing on the settings screen, seems to be ignored by the Home App (the same input sources are shown in the selector regardless of any changes made). However, dynamically changing the name of an input source seems to work fine.
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.
Characteristic::ConfiguredNameStatic() is no longer needed since you can now change permissions on ConfiguredStatic to remove PW with removePerms(PW). Updated Television Example accordingly.
To Do: Add getLinks() and setPerms/addPerms/removePerms to API Reference Documentation
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).
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 "custom" Characteristic is identical to ConfiguredName() but only allows paired-read and notifications. By excluding paired-write it prevents the user from editing the name of a TV input source from the Home App. This is useful when some sources are fixed, such as "netflix" instead of generic, such as "hdmi 1".
To enable save/restore for a Characteristic, set second parameter to TRUE when instantiating. Since first parameter was optional as well, this requires setting it as well.
Next up: Must add logic to setVal() to store new value as well.
Only throw a non-fatal warning instead of a fatal error if a Service is missing a required Characteristic. This allows for user flexibility in leaving out required Characteristics for Services that don't seem to need them (contrary to the HAP docs).
Also, changed PositionState Characteristic back to Required (instead of Optional) in WindowCovering Service (as specified by HAP). If PositionState is not included this will only throw an error instead of a warning as a result of the above change.
To Do: Update Example 13 to properly incorporate PositionState Characteristic.
Also added new flag "staticRange" for all Characteristics that indicates whether the min/max range can be changed. An ERROR will be thrown if setRange is attempted for a Characteristic having staticRange=true.
Warning will be thrown if setVal() request is outside of mix/max range for the Characteristic, though min/max range not yet modified by SpanRange().
TO DO: Create new Characteristic methods setRange(typename T_MIN, typename T_MAX) and setRange(typename T_MIN, typename T_MAX, typename T_STEP) that will reset min/max, or min/max/step, and trigger required output in database. Add in checks to ensure setRange is NOT used to STRING or BOOLEAN. Also add check to ensure STEP is always>0. Add new UVAL for STEP that is normally zero, which indicates NO step size has been set (and does not need to be reported to database). Then, set warnings about SpanRange being deprecated at some point in the future.
Gregg