ADT+ Alarm System No Longer Disarming Troubleshooting Guide

Jul 23, 2025 by JurnalWarga.com 60 views

ADT+ Alarm System No Longer Disarming: A Homebridge Automation Issue

Hey everyone! Let's dive into a frustrating issue that some of us using ADT+ alarm systems with Homebridge and Google Home are experiencing. It seems like the disarm functionality, which used to work smoothly through automations, has hit a snag. This article will break down the problem, explore the steps to reproduce it, and analyze the logs to hopefully find a solution or workaround. If you're scratching your head about why your ADT+ system isn't disarming as expected, you're in the right place!

Describe The Bug

The core issue we're tackling today is that the ADT+ alarm base, when integrated with Homebridge and Google Home, is refusing to disarm via automated routines. Previously, users had a clever workaround: creating a Google Home routine triggered by an Apple Home automation. This routine would send a command to "disarm the base" followed by the ADT+ pin code. This effectively bypassed the lack of a direct disarm setting. However, in recent weeks, this method has stopped working.

Instead of disarming, the Google Nest Hub Max now displays a screen prompting for manual pin entry. This defeats the purpose of automation, forcing users to physically interact with the device. It's worth noting that other alarm functions like arming in “Stay,” “Away,” and “Night” modes are still functioning correctly. This inconsistency points to a specific problem with the disarm command processing.

To fully understand the scope of this problem, it's essential to consider the impact on users. Home automation is all about convenience and seamless integration. When a key function like disarming fails, it disrupts the entire ecosystem. Imagine arriving home with your arms full, expecting the alarm to disarm automatically, only to be met with a pin entry screen. This not only adds an extra step but also raises security concerns if the system isn't disarmed promptly. The frustration is compounded by the fact that this setup used to work, highlighting a recent change in behavior. This is precisely why we need to dig deep into the troubleshooting process and identify the root cause.

Furthermore, this issue underscores the delicate balance of relying on workarounds. While the initial setup was ingenious, it relied on a chain of commands and integrations across multiple platforms. Any change in one component (ADT+, Google Home, Homebridge) could potentially break the chain. This is a crucial lesson for anyone building complex home automation systems: while clever hacks can be effective, they may not be as robust as native solutions. As we investigate this issue, we should also be thinking about more sustainable and reliable ways to manage ADT+ alarm systems within a smart home environment. Perhaps there are alternative plugins, direct integrations, or API calls that could provide a more stable solution in the long run. For now, let's focus on diagnosing the immediate problem, but keep in mind that the ultimate goal is to create a dependable and user-friendly system.

To Reproduce

To replicate this bug, follow these steps. This is essential for both understanding the problem and potentially finding a fix. Let's break it down:

Set up a routine in Google Home: This routine should be triggered by an accessory. In this case, a virtual security system within Apple Home (using Homebridge Security System) acts as the trigger. This triggers a dummy switch (Homebridge Dummy), which in turn initiates the Google Home routine. This intricate setup highlights the interconnected nature of the problem.
Define the routine actions: This is where the crucial commands are set. The routine should include custom actions:
- 2a) Disarm Base: This is the primary command intended to disarm the ADT+ system.
- 2b) [PIN]: This action sends the ADT+ pin code, which previously acted as the confirmation for disarming.
Observe the behavior: Run the automation and watch what happens. The routine is running, but the ADT+ base will not disarm. Instead, the Nest Hub Max displays the dreaded pin entry screen, halting the automated process.

Let’s elaborate on these steps. The use of a virtual security system and a dummy switch might seem convoluted, but it's a common workaround for bridging different smart home ecosystems. Apple Home and Google Home don't always play nicely together natively, so Homebridge acts as a translator. Understanding this architecture is crucial for troubleshooting. The fact that the routine runs but fails to disarm indicates the issue lies specifically in the disarm command processing, not in the triggering mechanism itself. This narrows down our search considerably.

Now, let's talk about the custom actions. The "Disarm Base" command is likely interpreted by Google Assistant and passed on to the ADT+ system. The subsequent pin code entry is intended to authenticate the disarm request. The failure suggests that either the disarm command itself is being misinterpreted, or the pin code is not being processed correctly. It's possible that ADT+ has implemented a security update that requires a different authentication method, or that Google Assistant's interpretation of the command has changed. We need to investigate both possibilities.

The observation step is where the rubber meets the road. The pin entry screen on the Nest Hub Max is a clear symptom of the problem. It confirms that the system is partially receiving the command but is failing to complete the disarm process without manual intervention. This is a crucial piece of evidence. It suggests that the command is reaching the ADT+ system, but the system is requesting additional authentication that the automated routine cannot provide. This could be a change in ADT+'s security protocols or a bug in the integration. By meticulously following these steps to reproduce the issue, we can ensure we're all talking about the same problem and can effectively test potential solutions.

Expected Behavior

Ideally, when the routine is triggered, the ADT+ base should disarm seamlessly. This is the expected behavior, and it's what the user experienced previously. The goal of home automation is to simplify tasks, and a security system that requires manual intervention defeats that purpose. The automation should handle the disarming process in the background, without requiring any physical interaction with the Nest Hub Max or any other device. This seamlessness is the key to a truly smart home experience.

The expected behavior is based on the principle of consistent functionality. If a system worked in a certain way before, users naturally expect it to continue working that way unless there's a clear indication of a change. In this case, the sudden failure of the disarm automation is a deviation from the norm and a significant inconvenience. It disrupts the user's workflow and creates a sense of distrust in the system. When automations fail unexpectedly, it erodes the value proposition of a smart home.

Furthermore, the expected behavior is also tied to user intent. When someone sets up an automation to disarm their security system, they're expressing a clear desire for hands-free operation. They want the system to respond predictably and reliably to the trigger, whether it's arriving home, a specific time of day, or any other condition. The system should interpret the intent and execute the disarm command without ambiguity. The fact that the system now prompts for manual pin entry indicates a disconnect between user intent and system behavior. This disconnect is a usability issue that needs to be addressed.

In the context of home security, the expected behavior is also crucial for safety. Imagine a scenario where someone is rushing into their home during an emergency. They might rely on the automated disarm to prevent a false alarm and potential panic. If the system fails to disarm automatically, it could lead to confusion and delays, potentially jeopardizing safety. Therefore, restoring the expected behavior is not just about convenience; it's also about ensuring the security system functions as intended in critical situations. By clearly defining the expected behavior, we set a benchmark for evaluating the system's performance and identifying the gap between what should happen and what is actually happening. This gap is the focus of our troubleshooting efforts.

Logs

Analyzing logs is a crucial step in debugging. The provided logs offer valuable clues about what's happening behind the scenes. Let's break down some key sections and try to decipher what they mean.

[22/07/2025, 21:28:35] [Google Smart Home] {
  '2e637e9c469c5553f4168c7fe2518709bb3b83da4f8948c319763a653d15fdc0': {
    on: true,
    online: true,
    brightness: 100,
    color: { temperatureK: 6000 }
  },
  ...
  '9d6b90d55fedad188993d1edf8e89c41e207afa32cf10e7976d938f98abb8381': {
    on: true,
    online: true,
    isArmed: false
  },
  ...
}

This section shows the state of various devices connected through the Google Smart Home integration. The device with the ID '9d6b90d55fedad188993d1edf8e89c41e207afa32cf10e7976d938f98abb8381' is particularly interesting. It appears to represent the security system, as it has properties like isArmed: false. This snippet likely represents the initial state of the system before any commands are sent.

[22/07/2025, 21:30:10] [Security System] Target mode (Night)
[22/07/2025, 21:30:10] [Security System] Current mode (Night)
...
[22/07/2025, 21:30:11] [Arm Night] On
[22/07/2025, 21:30:11] [Arm Night] Delaying 10s…

These logs indicate an arming action. The system is being set to “Night” mode, and there's a 10-second delay. This confirms that arming functionality is working as expected, which further isolates the issue to disarming.

[22/07/2025, 21:30:46] [Security System] Target mode (Off)
[22/07/2025, 21:30:46] [Security System] Current mode (Off)
...
[22/07/2025, 21:30:46] [Disarm] On
[22/07/2025, 21:30:46] [Disarm] Delaying 10s…

This is the crucial section. It shows the attempt to disarm the system. The logs indicate that the target mode is being set to “Off,” and the “[Disarm] On” message suggests the disarm command is being triggered. The 10-second delay might be a configured setting within the Homebridge plugin or the ADT+ system itself. However, this is where the process seems to falter. There are no subsequent logs confirming a successful disarm, which aligns with the reported issue.

[22/07/2025, 21:30:47] [Google Smart Home] {
  "type": "report-state",
  "body": {
    "9d6b90d55fedad188993d1edf8e89c41e207afa32cf10e7976d938f98abb8381": {
      "on": true,
      "online": true,
      "isArmed": false
    },
    ...
  }
}

This section is a state report sent to Google Smart Home. Notice that the security system ('9d6b90d55fedad188993d1edf8e89c41e207afa32cf10e7976d938f98abb8381') has isArmed: false. This might seem contradictory, but it could indicate that Homebridge thinks the system is disarmed, even though the ADT+ base is still requesting a pin. This discrepancy is a key piece of the puzzle. It suggests a potential communication gap between Homebridge and the ADT+ system. Homebridge might be sending the disarm command, but ADT+ isn't fully acknowledging it without manual pin entry. This could be due to a change in ADT+'s API or a bug in the Homebridge plugin. By carefully dissecting these logs, we can start to form hypotheses about the root cause and devise targeted solutions.

Homebridge Config

 "name": "Google Smart Home",
 "token": "TOKEN",
 "notice": "Keep your token a secret!",
 "twoFactorAuthPin": "PIN",
 "debug": true,
 "betaServer": false,
 "discoveryTimeout": 5,
 "discoveryWait": 15,
 "platform": "google-smarthome"

This is the configuration snippet for the Google Smart Home plugin within Homebridge. Let's break down the key elements and see if anything stands out as a potential issue.