Releases: gormanb/homebridge-connector-hub
v1.0.9
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.
v1.0.8
- 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.
v1.0.7
v1.0.6
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.
v1.0.5
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
...
v1.0.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