homebridge-connector-hub

Made two new configuration options available: the number of times to retry a failed request, and the delay between retries. These can be adjusted if the hub does not respond in a timely manner, or in cases where attempts to control a large number of devices simultaneously results in some devices failing to move, as described in #28.

Fixes the behaviour of the plugin for unidirectional blinds, which do not report explicit position information. They will now correctly reflect the open or closed position of the blinds as cached by the hub or set by the Home app. In cases where an external app is used to stop the blinds midway through opening or closing, the plugin will approximate this state by showing the blinds as 50% open since their exact position cannot be determined.

Fixes an issue whereby some brands of blinds, contrary to the standard network protocol spec, require the AccessToken to be supplied on read requests as well as write requests. See #26 for details.

• In addition to periodically scanning for new devices registered with the Connector+ or other vendor app, the plugin will now automatically remove devices from Homebridge and Homekit when they are de-registered from the app.
• Added the ability to reverse device direction. This can be used for any device models or brands which move in the opposite of the expected direction when using the plugin.
• Reduced the verbosity of log messages generated by the plugin when not in debug mode.
• Improved the config screen layout by separating settings into different sections.
• Fixed a minor bug which caused problems when generating device names.

• Fixed a bug introduced in 1.1.2 where certain devices would receive incorrect messages claiming that the user's app key was invalid (see #17, #18).

• Added a new code for previously-unrecognised Hub devices per #14
• Fixed an issue where binary-state devices were logging spurious "invalid ack" messages

Minor update that improves the discovery process and more gracefully handles the scenario where an invalid App Key is supplied; previously, this would result in a crash.

• Implemented support for Top-Down Bottom-Up blinds. Two accessories will be created for such blinds, one controlling the bottom part and the other controlling the top.
• Introduced a new device discovery mechanism. This should work better in multicast environments, for hubs with more than 15 devices, and for configurations with more than one hub. The plugin will now also periodically scan for new devices that have been added to the hub since startup.

The previous release introduced a new feature whereby values are read "actively" from each device once per minute, in contrast to the "passive" reads which are performed every five seconds. The difference is that the latter are cached values read from the hub, while the former require the hub to contact the device to obtain real-time values.

However, in practice it turned out that performing active reads this frequently had a significant negative impact on battery life, causing my blinds to fall to 0% in a matter of weeks rather than months. At the same time, the plugin cannot rely exclusively on passive reads; while passive reads will report the decline of a battery's remaining power, they seemingly do not report the battery's increasing level when it is plugged in to charge. Without active reads, a device's battery indicator in Homekit would thus fall to 0% and remain there indefinitely, even after the device has been recharged.

To work around this, I've decreased the frequency of active reads from once per minute to once per hour. From experience, it takes about 5-6 hours to fully charge one of my blinds; a one-hour active read interval should therefore ensure that the plugin notices and tracks the change in charging state, while having negligible impact on battery life.

• Added support for more than 15 devices attached to a single hub. Hubs can typically manage up to 30 devices, but only report a maximum of 15 per network message. The plugin now waits to see whether the hub reports a second set of devices during discovery. Fixes #5.
• The plugin will now proactively sync values which the hub does not update in passive status requests (e.g. battery level, charging state) once per minute.
  • NOTE: this change turned out to have a negative impact on battery life. Release 1.0.9 fixes this issue.

Added support for multiple hubs, and for standalone WiFi devices which communicate directly with the plugin. Fixes #4.

Improved integration with third-party apps.

Apple's own Home app does some client-side work to deduce the current state of a given device. For instance, if it successfully sends a setTargetPosition request to a blind, it will automatically set the device into Opening or Closing state based on its knowledge of the blind's previous position. When the blind reports that its position now matches the target, the Home app infers that the movement is complete, and will set the device to Open or Closed state, or to X% Open as applicable.

However, third-party Homekit apps (e.g. the Eve app) often do not perform these kinds of client-side deductions; instead, they are entirely reliant on the device to explicitly tell them everything about their state. Previously, this meant that devices managed by this plugin would show up with odd states in these apps, such as being stuck in Closing state regardless of what the device is actually doing.

This release fixes these issues by exhaustively reporting all required properties of the device state to Homekit.

Improved initial discovery of devices. Previously, devices appeared in Homekit with generic default names:

Connector Blind 1
Connector Blind 2
Connector Blind 3
Connector Blind 4
...

Device names will now resolve to their actual type upon discovery, as <Device Type> #<DeviceNum>:

Roller Blinds #1
Roller Blinds #2
Awning #3
Venetian Blinds #4
...

General robustness and logging improvements:

• Validate the configuration on startup, and suspend the plugin if any malformed entries are found
• More detailed logging if the plugin fails to set a blind's target position
• Catch and log network exceptions if the hub is not reachable

This release fixes the following issues:

• #2 Plugin does not work for devices which only support binary open / close commands
• #3 Battery level and charging state values are sometimes not in the expected range

Fixes #1. Some runtime dependencies were mistakenly listed as devDependencies, causing the plugin to throw MODULE_NOT_FOUND on startup. This release addresses the issue by specifying which of the dependencies are required for a production install.

Corrected package metadata, added more details to README.

Initial release of the plugin.