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

Alarm disabled without code in particular conditions #941

Open
DaniDF opened this issue May 14, 2024 · 1 comment
Open

Alarm disabled without code in particular conditions #941

DaniDF opened this issue May 14, 2024 · 1 comment
Labels
bug Something isn't working waiting for user input

Comments

@DaniDF
Copy link

DaniDF commented May 14, 2024

Alarmo Version

v1.10.1

HA Version

2024.5.3

Bug description

General Configuration:

  • Disarm after trigger: disabled
  • Enable MQTT: disabled
  • Enable alarm master: enabled

Areas:

  • Area_0:
    • Sensors:
      • sensor_0 (Allow open initially: disabled)
  • Area_1:
    • No sensors

Codes

  • Require code for arming: disabled
  • Require code for disarming: enabled
  • Require code for switching mode: enabled
  • Code format: "PINCODE"

When the alarm of the Area_1 is armed, the alarm of Area_0 is disabled and the sensor_0 is "open" (state in which if armed Area_0 will trigger the alarm).

In this state when trying to arm the master alarm the system immediately disarm all the alarm in all areas without asking the code.

Steps to reproduce

  1. Arm Area_1
  2. Disarm Area_0
  3. Put sensor_0 in "open" state (that will trigger the alarm of Area_0 if armed)
  4. Arm "master"

After these steps the system automatically disarm all alarms without asking the code.

Relevant log output

No response

@DaniDF DaniDF added the bug Something isn't working label May 14, 2024
@nielsfaber
Copy link
Owner

In this state when trying to arm the master alarm the system immediately disarm all the alarm in all areas without asking the code.

What would you expect to happen instead? The alarm master attempts to synchronize the states of all areas, so it should either arm all areas or disarm all areas. In this case arming is not possible, so disarming happens.
It could be argued that it would be better to restore the states of the areas as they were before, but I don't know if this information is available.

In the documentation the following is stated:

  • The Alarm Master cannot determine its state if some are disarmed while others are armed. If the Alarm Master is used for arming/disarming the alarm, this condition should not occur.
  • If the areas are independently operated, the user is reponsible to maintain synchronism between the areas. If independent operation is desired, usage of the Master Alarm is not recommended.

What is meant here, is that users should choose either to operate their areas via the master OR operate the areas independently.
You are using a mix of them, which is very difficult to handle by design.
A lot of scenarios can occur and the implementation will be able to deal with all to your expectation.
If one area is armed and the other is disarmed, the state of the alarm master cannot be determined, also the transitions between states of the areas are not the same.

To extend the discussion, let's consider another (more extreme) scenario:

  • area A is in state disarmed
  • area B is in state armed home
  • area C is in state triggered

User attempts to set alarm to armed away via the master.
However, area B has a sensor active that prevents that area to go into state armed away.
What would you expect to happen to all 3 areas and what should become the state of the alarm master?

If you have a clear idea how the master alarm should behave, I could see if I could improve the implementation.
However since I have been struggling with this during implementation, at the moment the disclaimers in the documentation should be taken as advice/warning.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working waiting for user input
Projects
None yet
Development

No branches or pull requests

2 participants