ELK Keypad losing comms overnight after M1XEP installation

I've recently added the M1XEP to my M1 setup and since then every night without fail my Keypad will start beeping in the early hours complaining about "Lost comms". If i power cycle the M1 terminal using the switch, the keypad happily reconnects. I've performed a few bus re-enrollments since but still not joy. I've also gone as far as disconnecting the M1XEP (and performing a re-enroll) but it's still happening.
 
Any ideas?
 
Setup:
 
M1XRFTW Wireless receiver (data bus terminated, home run from M1, cat5e cabling)
M1KP2 Keypad (data bus terminated, home run from M1, cat5e cabling)
M1XEP Ethernet port interface (RS232 connected to M1)

Welcome to Cocoontech!
 
From the info you've provided so far, it doesn't sound like a power problem.   But I'll ask anyway... Do you have any other devices connected to the VAUX power output on the M1?  Is the XEP powered by the P1216 wall wart?
 
Any other keypads or devices, such as M1XINs connected to the data bus?
 
One possible cause is poor connections to the data bus on either the keypad end or the panel end.  It might have nothing to do with the XEP, other than you disturbed the wiring when you installed the XEP.   So double check your connections to the keypad and data bus terminals.   If you are using an M1DBH for the data bus connections, it's worth re-terminating the RJ45 connectors.

I had the same symptom of the keypad losing comms after removing a p212s power supply that was installed as keypad #15. The keypad #1 was giving the error and I couldn't find trouble with anything. Then I noticed that keypad #15 was still showing in M1TOGO even though it was removed. I ended up resetting the M1 via global settings and then re-installing the customer account which fixed the problem.
 
I know this is not the same as your situation but thought that it may be food for thought.
 
Mike.

RAL said:

Welcome to Cocoontech!
 
From the info you've provided so far, it doesn't sound like a power problem.   But I'll ask anyway... Do you have any other devices connected to the VAUX power output on the M1?  Is the XEP powered by the P1216 wall wart?
 
Any other keypads or devices, such as M1XINs connected to the data bus?
 
One possible cause is poor connections to the data bus on either the keypad end or the panel end.  It might have nothing to do with the XEP, other than you disturbed the wiring when you installed the XEP.   So double check your connections to the keypad and data bus terminals.   If you are using an M1DBH for the data bus connections, it's worth re-terminating the RJ45 connectors.

Click to expand...

No other devices powered off the VAUX (i was planning on eventually doing this, but for the moment i'm using the provided power adapter).
 
I'll take a look at the connections, but if this was the case i would assume that connection loss would be apparent upon system power up.

Looking at the log, i do see the following related to about the time comms was last lost:
 
Event: 1141 = Expansion Module Trouble
Extended Data: Keypad 1

Keypad diagnosis DataBusErrors shows the following too if this helps:
 
Retry T2A2 00001

CWhite said:

I'll take a look at the connections, but if this was the case i would assume that connection loss would be apparent upon system power up.

Click to expand...

 
You could have a data bus connection that is just a little bit flaky.   It can be solid enough that things work most of the time, and will get through the boot process, but every once in a while will result in an error.
 
 

CWhite said:

Looking at the log, i do see the following related to about the time comms was last lost:
 
Event: 1141 = Expansion Module Trouble
Extended Data: Keypad 1

Click to expand...

 
This sure seems to point to the keypad as the source of the problem.  One other thing you can check is to measure the voltage at the keypad on the black and red wires to make sure the keypad is getting proper power.   You should see 12V or more there (hopefully something around 13V).
 
 

CWhite said:

Keypad diagnosis DataBusErrors shows the following too if this helps:
 
Retry T2A2 00001

Click to expand...

 
This is a bit puzzling.  In some other threads, it was explained that T2 refers to a bus device type, where the 2 is the code for an input expander.  A2 means device address = 2.  Is that that address you have the M1XRFTW set to?
 
Might be a good idea to check the voltage and wire connections on the M1XRFTW as well.
 
But based on this thread, it seems like the error count of 00001 is nothing to be concerned about, unless you see it increasing at a good clip.  The error with the XRFTW might just be a coincidence.

CWhite said:

Keypad diagnosis DataBusErrors shows the following too if this helps:
 
Retry T2A2 00001

Click to expand...

Some data bus errors are expected. I think that it is just retransmissions due to checksum errors and a few per minute is considered acceptable. You can check them through the keypad and if you can watch them adding up quickly then you have a problem.
 
I did a search of this site and here is a quote from Spanky who I'm told developed the Elk system:
 
The first thing to understand about the ELK data bus is it is a RS-485 data bus with all modules wired in series and a termination resistor at each end of the data bus. If you power down the M1 and measure the resistance across the bus, it should read about 65 ohms +- 10 ohms. The normal problem is when an unterminated spur is wired off the bus and line echos start causing data bus errors. Short runs of a few feet are OK like in the control box.

Data bus errors that are displayed on the keypad are the number of times the M1 retries a message to a module. It is common to see a few errors. Maybe one every few minutes. If you can look at the keypad error display and see them counting up every few seconds, then you have a data bus problem. Normally a wiring problem. Make sure eveything is wired in series and a termination resistor is enabled at the extreme ends of the data bus.
 
Mike.

CWhite - was this ever resolved for you?  I was having a similar issue.  Very frustrating.  Just re-did all connections, re-enrolled, etc. and it didn't fix it.  The keypad would work 99% of the time and get a "Lost Comm" - usually in the middle of the night and it would start beeping.  Wife would think alarm was going off. 
 
I just realized that the keypad giving me trouble is the M1KP2 keypad with hardware version1.6 (older ones are 1.4)  Elk recently released a bootware and firmware update for this to specifically address this issue.  I'm doing this now, and I assume this will fix my issue. 
 
OT, but there's also firmware for the panel and the wireless expander.  I was having some issues on reboot where my wireless zones would not act properly, and it looks like ELK is addressing that as well.  (Actually I'm seeing this is addressed in the new firmware for the M1G panel itself)  Kudos to them for constantly improving things - I'm hoping these updates will kill these little gremlins I've been dealing with...

I did eventually see this problem magically go away (whether that was a firmware update on Elks part, or something odd to do with re-connecting the M1EXP and providing it with ethernet i'm not sure). I have yet to try measuring the resistance across the bus as suggested by mikefamig.