alarmo icon indicating copy to clipboard operation
alarmo copied to clipboard

Alarmo switching to wrong mode after trigger time expires

Open JoeHogan opened this issue 1 year ago • 12 comments

Alarmo Version

v1.9.13

HA Version

2023.10.5

Bug description

Love Alarmo, but seeing an intermittent/random issue where after alarm is triggered and trigger time expires (and should re-arm), it re-arms in a different mode. I'm including a screenshot so you can see that trigger time is 5 minutes on my 'Home' mode, and it usually re-arms to Home mode, but sometimes it re-arms to Night mode.

image

Steps to reproduce

set a Home mode which re-arms after trigger time expires. Trigger it a bunch of times until it randomly sets something other than Home mode after trigger time expires.

Relevant log output

No response

JoeHogan avatar Nov 15 '23 04:11 JoeHogan

In my case it's switching the alarm OFF! Because of the open sensor I guess.

Beer17HWAM avatar Nov 24 '23 10:11 Beer17HWAM

In my case it's switching the alarm OFF!

I'm experiencing the same issue. For me it happened when setting a open sensor that is set to trigger the alarm immediately, as bypassed. After arming the alarming and leaving the building, the alarm turned off instead.

wardpieters avatar Dec 25 '23 13:12 wardpieters

@Beer17HWAM @wardpieters This is not related to this bug. Alarmo can only arm (or re-arm) the alarm if all sensors are inactive. If some sensor prevents this, you will need to intervene. You may wish to re-arm with one sensor bypassed, but alarmo will not decide to do so on its own. The main reason for this is that it might give the user the impression all is safe while the front door could be wide open.

@JoeHogan I tried to reproduce this behavior but so far I failed. I set the trigger time to 5 seconds and open/close one door to trigger the alarm and reset. Do you have any clues of what could be different in your usage? Looking at the code, alarmo will attempt to re-arm in the mode that is stored as the arm_mode. This property is exposed with the entity: image The property is set when the user arms (or attempts to) the alarm. Perhaps you send a request to arm (into a different mode) while the alarm is in the trigger state, but this request fails? Looking at the code, in this situation might explain the behaviour. The internally set property might become overwritten.

nielsfaber avatar Dec 27 '23 06:12 nielsfaber

sorry for the delayed response... I disabled my Home mode because of this issue (it would randomly switch to Night mode and trigger my Night automations (lights on, alarm blaring, etc), which was unlivable). But I did try this again yesterday and it only took one or two tries for the issue to manifest itself... Home mode armed, triggered for 5 minutes, then re-armed to Night mode automatically.

I'm not doing anything particularly weird... I do have one automation that automatically enables Night mode (if Night or Away mode is not armed) at 1:00AM every day, and switches it to Home mode at 8am every day. You can see here that the automation seems to be working as expected: image

Otherwise, this looks a little wonky to me... am i supposed to have 2 Alarmo device entries?

image

JoeHogan avatar Jan 25 '24 17:01 JoeHogan

I noticed when this happened again today, my door was open when Alarmo tried to re-arm my Home mode. I have a notification set up to let me kkow when re-arming fails, and that worked perfectly telling me, Alarm cannot be armed due to front door is open." But when I closed the door, Alarmo had re-armed in Night mode. I haven't validated this finding, but it may be related to force re-arming when a sensor is still triggered. Perhaps it is force-arming in the wrong mode.

JoeHogan avatar Jan 29 '24 01:01 JoeHogan

To expand on the above Force Arm comment, I do Force Arm Night mode in my night automation. History shows that this automation is indeed only performed at night, but thought I'd post it because it's the only thing that I can think of that may be contributing to the problem:

image

JoeHogan avatar Jan 29 '24 02:01 JoeHogan

Curious, maybe stupid question, sorry. what is the event triggering this automation? Is the script doing what you want? If the state is armed_home, disarmed, triggered, or arming the night mode service is executed/attempted because both of the conditions are not true, right?

cayossarian avatar Jan 29 '24 03:01 cayossarian

Yes, sorry... top condition got cut off... its time based...

image

JoeHogan avatar Jan 29 '24 03:01 JoeHogan

just following up - I can consistently recreate this behavior with the following:

Arm Night (automation with Force Arm at 1am) => Arm Home (automation with Force Arm at 7am) => Trigger (open a door to trigger alarm - remain triggered for 5 minutes, but keep door open) => Open sensor prevents rearm after trigger (get notification, alarm cannot be armed right now due to...) => Alarmo Arms night mode for some reason!

Here are my automations for arming night and arming home:

Arm Night Automation:

alias: Arm Alarm - Night
description: ""
trigger:
  - platform: time
    at: "01:00:00"
condition:
  - condition: and
    conditions:
      - condition: not
        conditions:
          - condition: state
            entity_id: alarm_control_panel.alarmo
            attribute: arm_mode
            state: armed_night
      - condition: not
        conditions:
          - condition: state
            entity_id: alarm_control_panel.alarmo
            attribute: arm_mode
            state: armed_away
action:
  - service: alarmo.arm
    data:
      mode: night
      skip_delay: true
      entity_id: alarm_control_panel.alarmo
      force: true
mode: single

Arm Home Automation:

alias: Arm Alarm - Morning
description: ""
trigger:
  - platform: time
    at: "07:00:00"
condition:
  - condition: and
    conditions:
      - condition: not
        conditions:
          - condition: state
            entity_id: alarm_control_panel.alarmo
            attribute: arm_mode
            state: armed_home
      - condition: not
        conditions:
          - condition: state
            entity_id: alarm_control_panel.alarmo
            attribute: arm_mode
            state: armed_away
action:
  - service: alarmo.arm
    data:
      mode: home
      skip_delay: true
      entity_id: alarm_control_panel.alarmo
      force: true
mode: single

JoeHogan avatar Feb 13 '24 14:02 JoeHogan

simplest way to reproduce this is to Arm night, then use service to Force Arm home... trigger alarm, leave sensor open so it cannot be rearmed automatically, and the state it reverts to is Night.

What i think is happening is that when Armed Night is FORCE changed to Arm Home, the revert_state gets set to Night, which is correct. But after Home is triggered and cannot be rearmed because of open sensor, it reverts to Night. Instead, what should happen, is since Home was force armed, it should FORCE Re-Arm after trigger. Instead, it just tries a standard re-arm which fails due to open sensor and re-arms to the revert_state (night, in this case).

In other words, when alarmo tries to re-arm after trigger, in needs to take into account if it was previously FORCE armed... so you need a revert_force_arm state that you manage along with the revert_state.

One workaround which would at least set it to Disarmed instead of Night is for me to Force Arm night => Disarm => Force Arm Home.

image

With non-ideal workaround: image

JoeHogan avatar Feb 16 '24 20:02 JoeHogan

@JoeHogan thank you for your efforts in investigating this issue. From your results it seems it should be easy to reproduce and tackle. I will look into it when I have some time available.

nielsfaber avatar Feb 16 '24 20:02 nielsfaber

yeah, i updated my comment above with what i think is happening - you may have missed that part.

JoeHogan avatar Feb 16 '24 21:02 JoeHogan

I am also having this issue with night mode. when I call service to arm to alarm to night mode, away mode is armed instead but if I call the service again, night mode will be enabled.

sheminasalam avatar Apr 17 '24 09:04 sheminasalam

This is issue is resolved with the new v1.10.1 release. I'm sorry for the long delay.

nielsfaber avatar May 08 '24 14:05 nielsfaber