Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Security system current state should not be set automatically #170

Open
sjohnr opened this issue Oct 8, 2022 · 1 comment
Open

Security system current state should not be set automatically #170

sjohnr opened this issue Oct 8, 2022 · 1 comment

Comments

@sjohnr
Copy link

sjohnr commented Oct 8, 2022

Current behavior

When arming a security system from HomeKit, the target AND current state are set in Homebridge, and the Characteristic.SecuritySystemCurrentState is set to the new state automatically.

Expected behavior

When arming a security system from HomeKit, only the target state should be set, and no characteristics should be updated (since HomeKit has already set the Characteristic.SecuritySystemTargetState to the desired state. The downstream security system (e.g. the "accessory") should set the current state using the HTTP API only when the security system has actually armed itself.

Context

Using this library for a security system, HomeKit immediately arms the security system when the state is changed by a user. If the downstream security system later uses the API to update the current state, it has no effect because it is already set in Homebridge and propagated back to HomeKit by this plugin. Additionally, there is no opportunity for the security system to show "Arming" for a period of time. If the security system changes the current state to something else (such as OFF) during the arming period, it triggers a notification in HomeKit (e.g. that the system was disarmed), which should not happen.

Happy to submit a PR if desired.

@benzman81
Copy link
Owner

Since I do not use a security system feel free to provide a PR. Since this would change the behavior there should be an additional setting to activate your new behavoir to not break existing configurations.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants