Triggered state changes to disarmed even Disarm after trigger switch set off

[GSzabados]

Checklist

• I am using the latest version of Alarmo (latest version can be found here)
• I checked for similar existing requests (both open and closed) before posting.

Alarmo Version

v1.10.6

HA Version

2024.11.1

Bug description

If triggered and has not been disarmed should stay triggered or moved to armed again and triggered again, but NOT disarmed.

I cannot imagine an alarm system which disarms itself if an open/close sensor stays open in armed state.

In no case should disarmed, unless it is instructed.

Steps to reproduce

Arm Alarmo, open open closes sensor, leave it open for trigger time and wait for the system to Disarm.

Relevant log output

This error originated from a custom integration.

Logger: custom_components.alarmo.alarm_control_panel
Source: custom_components/alarmo/alarm_control_panel.py:673
integration: Alarmo (documentation, issues)
First occurred: 17:10:46 (1 occurrences)
Last logged: 17:10:46

Cannot transition from state triggered to state armed_away, there are open sensors

[nielsfaber]

I don't consider this as a bug report but a case of expectation vs. reality, since what you are describing is intended behaviour.

If triggered and has not been disarmed should stay triggered or moved to armed again and triggered again, but NOT disarmed.

You can choose whether alarmo should disarm or re-arm via this setting:

Also you can configure the triggered state to last forever (requiring user to disarm or re-arm):

Since you don't share the settings you made, I don't cannot judge regarding what should be expected to happen.

I cannot imagine an alarm system which disarms itself if an open/close sensor stays open in armed state.

Alarmo could do this.
The reason is that entering the armed state requires all sensors to have the correct (=safe) state.
You cannot arm the alarm with an open door (unless you configured this door may be bypassed).

Alarmo will not auto-bypass sensors that are not configured as such, since this could mean the alarm would be armed with , for example, the front door being wide open.
This would give the user a false impression the house is secure, which is clearly not the case.
So in the case of a front door having triggered the alarm (and remaining open), alarmo will not re-arm after being triggered. Since the arming failed, the alarm becomes disarmed.
The user is responsible to follow-up on this (he should be informed with push notifications or similar).

[GSzabados]

It just doesn't make any sense to Disarm, when the following 2 options are selected.

[nielsfaber]

Clear, so what do you propose to change?

[GSzabados]

Stay triggered and go back to armed if the sensor is not triggering it. But in no circumstances should Disarm, unless it is specifically instructed.

[nielsfaber]

Stay triggered and go back to armed if the sensor is not triggering it.

This is not an option since this would violate the configured 'trigger time' by users.
Many users have automations that enable (exterior) sirens whilst the alarm is in the triggered state, an implementation as you propose would result in their sirens to keep (or restart) blaring for an (unknown) extended duration.
This is not desirable due to disturbance in the neighbourhood, also I received feedback that some local governments have regulations that forbid exceeding a certain duration.

[GSzabados]

Could you add an additional option switch for this? I really think that the alarm should not Disarm, especially if a code is required for it.

I thought that the Disarm after trigger switch was for this, but obviously not.

What if from triggered it would move to pending and triggered again if it exceeds the trigger time? And this could be an additional switch.

And to be honest, I cannot remember when this behaviour started. I used to remember that if triggered then it went back to armed.

[GSzabados]

According the read.me from triggered it should change to triggered.

When alarm is in state arming: next_state is equal to the arm_mode.
When alarm is in state pending: next_state is triggered.
When alarm is in state triggered: next_state is triggered (if no trigger time is configured), disarmed (if 'disarm after triggering' setting is enabled) or equal to the arm_mode (otherwise).
In other cases, the next_state will be equal to the current state.

Considering the last sentence...

[github-actions]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 7 days

[GSzabados]

Would be possible at least expose somehow for an automation to catch this case? And re-arm by an automation, by using bypass sensors?