The M1XEP TCP Drop: Your Panel Disconnects When You Need It Most
Here's the scariest thing I've discovered about the ELK M1 + Home Assistant integration:
During an active burglar alarm, the M1XEP drops its TCP connection.
Your alarm triggers. Your automation sends a disarm command via HA. HA reports success. But the panel stays alarmed. The command was sent to a dead socket. The M1 never received it.
The one moment you need remote control to work — and it doesn't.
Why This Happens
The M1XEP ethernet module has a firmware limitation: it drops active TCP connections when the panel enters burglar alarm state. This is documented on CocoonTech forums but not in ELK's official documentation. It affects firmware 2.0.51 and likely earlier versions.
The HA integration doesn't detect the dropped connection immediately. It sends the disarm command, gets no error (the socket hasn't timed out yet), and reports success. The M1 never receives it.
How I Discovered It
I built an alarm response automation: alarm triggers → flash all lights → send notification with DISARM button → tap button → disarm. Beautiful in theory.
First real test: my alarm triggered. I got the notification. I tapped DISARM. HA said "disarmed." Lights kept flashing. Panel still screaming. Tried again. Same result. Had to physically walk to the panel.
Three sessions of debugging later, I found the TCP drop. The most important automation in the system was built on a broken foundation.
The Workaround
I built a double-disarm sequence with integration reload:
First disarm attempt
Wait 3 seconds
Check if panel is still triggered
If yes: reload the ELK integration (re-establishes TCP connection)
Wait 5 seconds for reconnection
Second disarm attempt
Notify with result + "if still triggered, use physical keypad"
Plus a cleanup automation that fires on any panel state change — not just "disarmed." This catches disarms from the physical keypad, ElkRP2, or HomeKit. If the alarm_active boolean is ON and the panel transitions to any non-triggered state, the cleanup runs: stops the light flash, resets the boolean, sends confirmation.
The Real Fix
A physical keypad. The ELK-M1KTP2 ($120-250) connects directly to the M1 data bus — no network dependency. Walk to the keypad, enter your code, alarm disarmed. Always works.
If your house already has keypad home runs (check your panel — CAT5e cables with no voltage that aren't connected to expanders are likely keypad runs), installation is straightforward.
I have three keypad runs in my walls. Haven't installed the keypad yet. It's the single most important hardware purchase remaining in my system.
What About Port 2101?
The M1XEP has a non-TLS port (2101) in addition to the TLS port (2601). It's possible that port 2101 stays up during alarm while 2601 drops. I haven't tested this — if anyone has, I'd love to hear the result.
In theory, you could run a second HA integration entry on port 2101 as a fallback. But "in theory" isn't what you want during an alarm.
Quick Tips
Always close ElkRP2: It holds the M1XEP's single TCP connection. HA can't connect while ElkRP2 is open. Even minimized. Even on a different machine.
Use
!secret elk_code: Never hardcode your alarm panel code in YAML. It ends up in git repos, backups, and log files. Put it insecrets.yaml.Back up before big changes: HA full backup before deploying alarm automations. One YAML typo in alarm_response can leave you with lights flashing and no way to stop them except pulling the HA power cable.
What I'm Building This Week
A zone mapping methodology — systematic process for mapping every zone in an inherited ELK system. Walk tests, swap tests, voltage measurements. Will share the full methodology on Thursday.
— The Automated Home