A HomeBridge plugin to expose Connector Motor Hub blinds, shades, curtains and similar devices to Homekit
APACHE-2.0 License
Bot releases are hidden (Show)
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.
Published by gormanb 10 months ago
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.
Published by gormanb 11 months ago
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.
Published by gormanb 11 months ago
Published by gormanb about 1 year ago
1.1.2
where certain devices would receive incorrect messages claiming that the user's app key was invalid (see #17, #18).Published by gormanb about 1 year ago
Published by gormanb about 1 year ago
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.
Published by gormanb about 1 year ago
Published by gormanb over 1 year ago
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.
Published by gormanb over 1 year ago
Added support for multiple hubs, and for standalone WiFi devices which communicate directly with the plugin. Fixes #4.
Published by gormanb almost 2 years ago
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.
Published by gormanb almost 2 years ago
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
...
Published by gormanb almost 2 years ago
General robustness and logging improvements:
Published by gormanb almost 2 years ago
This release fixes the following issues:
Published by gormanb almost 2 years ago
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.
Published by gormanb almost 2 years ago
Initial release of the plugin.