State out of sync with actual state

[egburr]

I had a problem this morning that at first might seem related to issue #534 but it is not.

Last night, I armed my system using the alarmdotcom integration. This morning, alarmdotcom shows it is disarmed. Both the panel and alarm.com show it is still armed. Normally, as per issue #534, reloading the integration resolves this. Today it does not. Restarting HA does not resolve this. However, alarm.com logs alarmdotcom's login after each reload and the restart.

Now comes an even stranger part: telling alarmdotcom to arm the system (which it thinks is disarmed) appears to have no effect, except alarm.com logs the arm order (doing nothing because it is already armed). Telling alarmdotcom to disarm the system has no effect, I assume because it thinks the system is already disarmed and does not need to send the order.

After disarming the system at the panel, alarmdotcom is now able to arm the system, see/display the proper status, and disarm the system.

The only entries in the HA Core log for alarmdotcom is the "ALARM.COM DEBUG DATA FOR SYSTEM:" entry for each login after a reload, listing all the devices and system state.

Alarmdotcom acted like it was out of sync and could not resync, even through a restart, until I changed the actual system to match the state alarmdotcom thought it was in. I don't know how it got into this state, so I have no suggestions on how to reproduce this. But I want to ask is there anything I can do to capture some useful data if it happens again?

alarmdotcom 4.0.1-beta.2
HA Core 2026.5.0

[smshapiro85]

+1 on this, and looking at the open issues and last release, I hope that @elahd is still up to maintaining this project, it has been amazing for us and rock solid. Any update you can provide would be greatly appreciated. Thank you!

[smshapiro85]

For anyone else checking this in the future, I am adding this automation update to check if the alarm arm/disarm succeeded and if not, reloading the integration, as this is the only work around that resolves the issue of the state being out of sync.

choose:
    sequence:
      - device_id: 1a1895e0283c97f1f6581c3a08eaf19d
        domain: alarm_control_panel
        entity_id: alarm_control_panel.house_alarm_2
        type: arm_home
        code: "XXXX"
      - delay:
          hours: 0
          minutes: 0
          seconds: 20
          milliseconds: 0
      - if:
          - condition: state
            entity_id: alarm_control_panel.house_alarm_2
            state: armed_home
        then: []
        else:
          - action: homeassistant.reload_config_entry
            target:
              entity_id: alarm_control_panel.house_alarm_2
            data: {}
          - wait_template: >-
              {{ states('alarm_control_panel.house_alarm_2') not in
              ['unavailable','unknown'] }}
            timeout:
              hours: 0
              minutes: 0
              seconds: 60
              milliseconds: 0
            continue_on_timeout: true
          - delay:
              hours: 0
              minutes: 0
              seconds: 5
              milliseconds: 0
          - if:
              - condition: state
                entity_id: alarm_control_panel.house_alarm_2
                state: armed_home
            then: []
            else:
              - action: notify.pushover
                data:
                  message: >-
                    Alarm did not arm... sigh. [verify-then-reload, state={{
                    states('alarm_control_panel.house_alarm_2') }}]
                  title: 🚨 Alarm Status
default: []

[egburr]

Thanks for this!
I hadn't even thought to try that. I had just setup a nightly reload_config_entry for the alarm_control_panel. But I like this better.
What are you using as the trigger, though? A change in state of the alarm_control_panel entity?
It's hard to test, since I don't know how to get it out of sync! But from what I remember (the little data I had is long gone now) one of the symptoms was that the state never changed, which became my visible clue that the integration needed to be reloaded. Is the attempt to change state enough to trigger?

[smshapiro85]

Glad it helped!

No state trigger, that's the trick. You're right that it wouldn't fire, since the state never changes when it's stuck. The "trigger" is just my existing scheduled arm/disarm automations (a time trigger at 6:45 AM and 10:00 PM). The verify-and-reload runs as steps right after the command in the same automation:

1. Send the disarm/arm command.
2. Wait ~15-20 seconds.
3. If the entity is already in the state I commanded, done.
4. Otherwise, call homeassistant.reload_config_entry, re-check, and notify only if it's still wrong.

So it doesn't wait for a state-change event. It actively reads the state after the delay and compares it to what I asked for. Sending the command alone isn't enough to update HA, which is why the reload step does the syncing. It's basically your nightly reload, but only fired when a command didn't actually take.

The reason this is enough for me is that the only thing I use this integration for is automating arm/disarm, and I kick both off through HA, so the command is always the trigger. I don't rely on it for door/window sensors, the alarm actually going off, or anything else, so I don't need the WebSocket to be healthy for anything beyond confirming the command I just sent.

If you do depend on those other entities staying live, you'd still want something like your nightly reload as a backstop.

Here is what Claude said about the bug pulling down the repo and doing a debug session:

As for the underlying issue, my reading of the code and logs is that the integration is effectively WebSocket-only. Despite the cloud_polling label, there doesn't appear to be a polling fallback, so Home Assistant only receives state updates through the live WebSocket connection.

What seems to happen is that Alarm.com periodically closes the socket with close code 1008 ("rejected token"). Most of the time the client reconnects successfully, but the pyalarmdotcomajax WebSocket implementation has a hard limit of 25 consecutive reconnect failures. Once that threshold is reached, it calls stop() and exits without any mechanism to restart itself. The integration also doesn't appear to detect or recover from that condition.

The result is a silent failure mode: the WebSocket feed dies, state updates stop flowing into Home Assistant, and the integration remains stuck in that state until the config entry is reloaded.

That also explains why a reload consistently resolves the problem. The arm/disarm commands continue to work because they're sent over the REST API. The Alarm.com panel receives and executes them correctly, but Home Assistant never receives the corresponding state updates once the WebSocket client has stopped.

That behavior matches what I observed in my own history. Everything updated normally for several days, then state changes stopped entirely for roughly 2.5 days. A manual config-entry reload immediately restored updates, which is exactly what would be expected if the WebSocket task had terminated and never restarted.

@elahd you are missed! If you need access to my alarm.com in order to get back up and running while you get your own install in order please reply back, I am good doing this in order to support the integration/community.

[egburr]

I don't have the arming/disarming automated. My schedule is too irregular for that. I usually do it manually from the alarm control card in the HA app on my phone. I could code up separate buttons to force your check, but that feels awkward for my purpose. However...

That info from your debug / claude session gives me an idea. I'll have to wait for another de-sync event to test it out though. Monitor the last_reported timestamp of the alarm_control_panel state object. While working, it appears to get an update roughly every 5 minutes. I've set up an automation to run every hour to check if the most recent report is over 30 minutes old, and notify me. And if this is good, then change that to do a reload.

alias: alarmdotcom stale last_reported check
description: ""
triggers:
  - trigger: time_pattern
    hours: /1
conditions:
  - condition: template
    value_template: >-
      {{ (as_timestamp(now()) -
      as_timestamp(states.alarm_control_panel.system.last_reported))|int > 1800
      }}
actions:
  - action: notify.persistent_notification
    metadata: {}
    data:
      message: >-
        {{ now() }} alarmdotcom stale last_reported: 
        {{ states.alarm_control_panel.system.last_reported }}
mode: single

[egburr]

I finally had another stale event happen. My automation above detected and notified me as I had hoped. So I updated it to include your reload action, and on the next hour, it detected, notified, and reloaded. I have now also updated it to just trigger on the last_reported going stale (being over 30 minutes) rather than checking every hour; going to see how that does. Don't know why I didn't think of that before. It'll leave me a potential 30 minute gap where I would have to do a manual reload, but I can live with that, I think.

alias: alarmdotcom stale last_reported check
description: ""
triggers:
  - trigger: template
    value_template: |-
      {{ (as_timestamp(now()) -
            as_timestamp(states.alarm_control_panel.system.last_reported))|int > 1800
            }}
conditions: []
actions:
  - action: notify.persistent_notification
    metadata: {}
    data:
      message: >-
        {{ now() }} alarmdotcom reloading due to stale last_reported:  
        {{ states.alarm_control_panel.system.last_reported }} : {{
        time_since(states.alarm_control_panel.system.last_reported) }} 
  - action: homeassistant.reload_config_entry
    target:
      entity_id: alarm_control_panel.system
    data: {}
mode: single

[ibasebcast]

For anyone still experiencing this issue, I maintain an actively developed fork of the Alarm.com integration here:

https://github.com/ibasebcast/ha-alarmdotcom

The fork has been updated for current Home Assistant releases and includes fixes for stale or frozen entity states, reconnect recovery, device registry compatibility, authentication issues, and other problems that remain unresolved in this repository.

The current stable release is 2026.7.9.3. The Alarm.com API client is now vendored directly into the integration, and the project includes automated testing, diagnostics with credential redaction, and ongoing compatibility updates.

In addition to maintaining compatibility with current Home Assistant releases, I am actively developing new features and enhancements. Camera support is already integrated in the current release, and additional functionality is planned for future updates.

Installation instructions for HACS, release notes, and a complete changelog are available in the repository. If you encounter any issues or have feature requests, please open them here:

https://github.com/ibasebcast/ha-alarmdotcom/issues

Feedback, testing, and contributions are always welcome.