Manual Alarm doesn't restore previous state after reboot

[Molodax]

Make sure you are running the latest version of Home Assistant before reporting an issue.

You should only file an issue if you found a bug. Feature and enhancement requests should go in the Feature Requests section of our community forum:

Home Assistant release (hass --version):
0.57.x
0.58.x
Python release (python3 --version):
3.4.2 (Raspberry Pi 3)

Component/platform:
Manual Alarm Control Panel

Description of problem:
The Manual Alarm Control Panel does not restore its previous "armed away" state after rebooting homeassistant.

Expected:
Restore the state after reboot.

Problem-relevant configuration.yaml entries and steps to reproduce:

alarm_control_panel:
  platform: manual
  code: 7777

Traceback (if applicable):

Additional info:
It seems like the issue has been introduced with some update since 0.57.x

[lackhove]

i have the same issue on 0.60.0

[pplucky]

Same here in 0.60.0. Would it possible to fix this behavior?

[balloobbot]

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates.

Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍

[fanaticDavid]

According to #11552, this is still a thing.

[pplucky]

Still happens in 0.64.3

[FuzzyMistborn]

This custom sensor solves the problem, but would be nice if it wasn't necessary: https://github.com/gazoscalvertos/HASS-Persistence

[mrphyslaw]

Still an issue on 0.67.0. My alarm state goes back to "Armed Away" after every restart. I guess no one cares to try and resolve it?
edit: I guess I will try the "persistence" sensor above...

[asosso]

Still this issue on 0.69.1

[FuzzyMistborn]

Yeah and the persistence sensor i linked to above hasn't been updated to fix it's issues. So i'm unaware of any workaround/working solution to this problem.

[iAutom8]

Seriously! Still not fixed! Is the alarm component not a "security" element of HA? We had power outage for a couple hours today and was reminded of this issue when all my automation since have not worked. UPS did its job but no one was around to gracefully turn some things off and back on when power was restored. I am however happy my HA installation on Raspberry PI started back up without issue!

I originally commented on #11552. Being aware of this issue I know to reset the alarm when I do upgrades but have forgotten at times.

Why is this issue not being prioritize?

[mrphyslaw]

Bump.

[mbo18]

Same here

[iAutom8]

Why is this still an issue!? It's a security component!

[basharfaraj]

I had the same issue with my alarm system and I finally was able to fix it by using this method:

https://github.com/gazoscalvertos/HASS-Persistence

[makingwilliam]

Just adding my concern for this issue to be resolved. I am also using manual alarm with mqtt component and the recorder component and still the state is reset to disarmed after a restart. Home Assistant 0.78.3

If you read this issue, please like it or comment on it so that we can get this issue resolved faster.

concerns: restart, power outage, automatic update scripts

Possible workaround, but NOT a definite solution: use the Manual Alarm with MQTT component, setup a sensor to keep track of the alarm state from MQTT, add an automation for restart that changes the manual alarm state to that of the MQTT alarm sensor. The problem with this method is that it will cause any arming automations to fire, which in my case includes several external notifications and internal audible announcements which I wouldn't want going off multiple times.

[FuzzyMistborn]

I don't think those numbers are for watching this issue, it means how many are watching the entire git for HASS.

I've written an AppDaemon script that restores the state of the alarm. Here's my code:

import appdaemon.plugins.hass.hassapi as hass
import shelve
import time
import json

#
# App to reset alarm_control_panel to previous state after HA restart
#
# Args:
#
# file - file in which to save state
#

class AlarmReset(hass.Hass):

  def initialize(self):
    self.alarm_handler = self.listen_event(self.store_alarm_state, "call_service", domain = "alarm_control_panel")
    self.listen_event(self.restore_alarm_state, "plugin_started")

  def store_alarm_state(self, event_name, data, kwargs):
    with shelve.open(self.args["file"]) as db:
        db["alarm setting"] = json.dumps({'state': data['service'], 'entity': data['service_data']['entity_id'], 'code': data['service_data']['code'] })
    self.log("Alarm state changed to {}".format(data['service']))

  def restore_alarm_state(self, event_name, data, kwargs):
      self.cancel_listen_event(self.alarm_handler) # to avoid a potential loop, not so bad though
      with shelve.open(self.args["file"]) as db:
          alarm_settings = json.loads(db["alarm setting"])
          self.log("Restoring state to {}".format(alarm_settings['state']))
          state = alarm_settings['state']
          entity_id = alarm_settings['entity']
          code = alarm_settings['code']
          self.call_service("alarm_control_panel/{}".format(state), entity_id = entity_id, code = code)
      self.alarm_handler = self.listen_event(self.store_alarm_state, "call_service", domain = "alarm_control_panel")

And the config portion is this:

Alarm_Reset:
  class: AlarmReset
  module: alarmreset
# Choose where to store the states across restarts
  file: /home/homeassistant/.homeassistant/alarm

[makingwilliam]

@FuzzyMistborn I did edit those numbers out, I didn't realize it was for the entire project. I'm not entirely sure how to incorporate your fix. I am curious, why the recorder wouldn't be able to save the state though just like it does for other entities. It certainly keeps a history of the alarm state over time, so reason would have it that it could keep the state of the alarm just as it does boolean_datetime states for instance.

[FuzzyMistborn]

I agree it's something the recorder should pick up on and restore, but I'm not expert enough to make that fix.

You need to install AppDaemon to run my "fix" (it's not a fix, it's more of a work around). Google/look around the HASS forums for more info on how to get AppDaemon set up.

[GaryOkie]

Just adding to the thread to count me as another who is impacted by this issue. I'm not liking that I would have to go the Appdaemon or custom component route as a workaround just to restore the alarm state after a power outage.

[liaanvdm]

This issue's been bugging me for a while... Decided to have a crack at solving it myself.

[mrphyslaw]

I will PayPal you some cash if you fix it. I have no workaround as I can’t seem to get the HASS persistence script to run. It’s annoying when my alarm ends up armed after every restart.

[iAutom8]

Glad to see this is being fixed after almost a year!

[liaanvdm]

@murphyslaw05 The component initializes to disarmed state by default. I didn't see anything that would cause it to start up armed. My issue was certainly with it restarting and disarming the alarm.

Either way, the fix i submitted gets the last state from DB at startup, so hopefully will solve your issue 2.

[mrphyslaw]

Mine ALWAYS starts in an armed state. No clue why as I have never specified it that way. Great to hear that your submitted fix pulls the last state. That’ll solve both our problems.

[liaanvdm]

@murphyslaw05 Are you definitely using the manual alarm control panel, not the mqtt one?

[makingwilliam]

It would seem to me, the easiest fix would be for both the Manual Alarm and the Manual Alarm with MQTT to be added to the recorder for state history tracking. Although, upon further inspection, I do see a history for my alarm state, doesn't that mean the recorder is already saving the state over time? And if so, why are these two components not just retrieving their last state like most other components from the recorder? If this is an undesirable affect for everyone, then the alarm components could have a simple configuration flag added for retain_state. In my honest opinon, that is!

[makingwilliam]

@liaanvdm would your fix also work for the Manual Alarm Control Panel with MQTT Support? manual_mqtt:

[GaryOkie]

william, in referring to the in-progress fix PR (#17521) , liaanvdm specifically states "This fix will restore the last state that was logged by the logger component whenever hass restarts."

I did not see anywhere a mention of this fix also applying to the manual alarm with MQTT, so I can't comment that it would also apply.

[liaanvdm]

The fix wont apply to the mqtt component. I haven't used that component but can't you use retained messages feature of mqtt to restore the state? If not that would be a nice feature to add as well. But I could probably apply the same fix to the mqtt alarm component, I'll have a look tomorrow.

…

On Sun, Oct 21, 2018, 8:33 PM GaryOkie ***@***.***> wrote: william, in referring to the in-progress fix PR (#17521 <#17521>) , liaanvdm specifically states *"This fix will restore the last state that was logged by the logger component whenever hass restarts."* I did not see anywhere a mention of this fix also applying to the manual alarm with MQTT, so I can't comment that it would also apply. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#10793 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ApPKt50DcPKgC8MVdMN_Y-HA0Z3beDJVks5unL4RgaJpZM4Qqb-6> .

[makingwilliam]

@liaanvdm as with the Manual Alarm, I do not believe that this component restores from any state. Now, it would be fine with me if it restored it from the MQTT value, but no at this time it does not allow for retained messages to set its state after a reload either.

Also, I'd like to point out that the MQTT Support isn't mean for MQTT to be the alarm panel but only to update and read its state from the alarm panel within Home Assistant. Therefor, I would think it would be more proper to do it using the recorder, same as the manual alarm.

[liaanvdm]

@thewilliambond I've had a look and applying the same fix to restore the alarm state using states logged by the recorder component is not as straightforward as I'd hoped. The problem is the start up trigger is already used in the code to subscribe to the mqtt topics and I cant get the asynchronous db restore state methods to play well with this.

What I did see is that state changes are published to mqtt with the retain flag enabled so it looks to me like, as long as your mqtt keypad is also publishing with a retained state, the hass component should recover the state on startup.

[lasseklein]

Bumping this thread as this is still an issue with 0.82.0.

Any hope for a solution? I would really want my house to stay protected even if there has been a power failure.

[GaryOkie]

According to the release notes for 82.0, liaanvdm's fix was included.

Restore manual alarm-control-panel state using async_get_last_state (@liaanvdm - #17521) (alarm_control_panel.manual docs)

I haven't upgraded to it yet. So you have installed 82.0 and found that the alarm didn't restore to it's previous state after an HA restart?

[FuzzyMistborn]

And are you sure you're using the manual alarm and not manual alarm with mqtt? The patch does NOT fix the mqtt version

[liaanvdm]

And the fix will only work if you have the recorder component enabled and it's logging the manual alarm control panel's state.

…

On Wed, Nov 14, 2018, 5:54 PM Geoff ***@***.***> wrote: And are you sure you're using the manual alarm and not manual alarm with mqtt? The patch does NOT fix the mqtt version — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#10793 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ApPKt_5z1S8HkTD_sydYyUaGga8FX4Drks5uvDyrgaJpZM4Qqb-6> .

[GaryOkie]

Just upgraded to 82.0. Manual alarm (no mqtt) properly restored to alarmed state after HA restart.

Also tested rebooting Hassio, and that also restores the state properly.

Well done liaanvdm! Thanks so much for fixing this.

[lasseklein]

Sorry everyone. I was too quick. I have the one with mqtt.

[fotiDim]

There is a bug. If the status is Pending and I reboot Hassio then after the reboot the status remains in pending forever.

[liaanvdm]

Yikes, I never tested that case. Thanks for reporting
this, I will look into it and report back soon.