Zones indicate violated when clearly closed

[zaffyhp]

Hello everyone.  This is my first post to Cocoon Tech as a member and my first time with the ELK M1Gold. I guess I should start with an overview of what I have and current status. 
 
62 hardwired zones (40 windows, 8 doors, 13 PIRs, 1 tamper box). 
One M1XRFTW transceiver for zones 17-32 on BUS 2.
Three M1XIN on BUSs 3, 4, and 5
Four KPNAV keypads set to 01, 02, 03, and 04
One M1EXP Ethernet Interface
One M1DBH data bus hub
There is more stuff on the power and output side but this is probably enough for now.
 
I am connected to the panel with the M1EXP and the ELKRP2 software.  All the latest firmware has been downloaded and applied.  There are no conflicts between the panel and the ELKRP2 data base for my account.  Every device on the hub is properly enrolled and so is the M1EXP (they all show up as enrolled in the ELKPRP2 software under "Send/Receive - Enroll/Update Control and Devices").
 
The problem I am having is related to the zones I have on the M1XIN expander cards.  To start with, when the system is unarmed I can open a perimeter zone on one of my M1XINs, then immediately close that zone and minutes later that zone will show up on my NAV keypad as one zone violated.  At that point the panel is Not Ready to Arm and I can't clear the violation because the zone is already closed.  If I wait five or 10 minutes (I haven't actually measured the time yet for accuracy) the violation disappears and the system is Ready to Arm.  This happens to all the zones I have checked so far on my three MIXIN cards including the PIRs.
 
Once the NAV keypads say "Ready to Arm" I can violate a perimeter window of a zone on a M1XIN and press Exit (Away mode) and the system starts to count down for arming!  I expected the keypad to tell me a zone was violated and could not arm until I cleared the violation.  At this point I just put in my user pin to cancel the arming.
 
When I try the same sequence above on a perimeter zone on the main panel (Zones 1-16) the system responses normally.  The keypad tells me I have a violated zone, I close it, the violation goes away, and I can arm.
 
I suspect a data communication problem with the M1XINs and the panel but I don't know were to start troubleshooting.  Everything is enrolled and I have triple checked all the wiring.  The LEDs on the M1XINs are flashing.  I have a jumper on the M1XINs on the "no termination 485" side, and a jumper on JP3 on the main panel.  I could really use some help.

 

[mikefamig]

Hello everyone.  This is my first post to Cocoon Tech as a member and my first time with the ELK M1Gold. I guess I should start with an overview of what I have and current status. 
 
62 hardwired zones (40 windows, 8 doors, 13 PIRs, 1 tamper box). 
One M1XRFTW transceiver for zones 17-32 on BUS 2.
Three M1XIN on BUSs 3, 4, and 5
Four KPNAV keypads set to 01, 02, 03, and 04
One M1EXP Ethernet Interface
One M1DBH data bus hub
There is more stuff on the power and output side but this is probably enough for now.
 
I am connected to the panel with the M1EXP and the ELKRP2 software.  All the latest firmware has been downloaded and applied.  There are no conflicts between the panel and the ELKRP2 data base for my account.  Every device on the hub is properly enrolled and so is the M1EXP (they all show up as enrolled in the ELKPRP2 software under "Send/Receive - Enroll/Update Control and Devices").
 
The problem I am having is related to the zones I have on the M1XIN expander cards.  To start with, when the system is unarmed I can open a perimeter zone on one of my M1XINs, then immediately close that zone and minutes later that zone will show up on my NAV keypad as one zone violated.  At that point the panel is Not Ready to Arm and I can't clear the violation because the zone is already closed.  If I wait five or 10 minutes (I haven't actually measured the time yet for accuracy) the violation disappears and the system is Ready to Arm.  This happens to all the zones I have checked so far on my three MIXIN cards including the PIRs.
 
Once the NAV keypads say "Ready to Arm" I can violate a perimeter window of a zone on a M1XIN and press Exit (Away mode) and the system starts to count down for arming!  I expected the keypad to tell me a zone was violated and could not arm until I cleared the violation.  At this point I just put in my user pin to cancel the arming.
 
When I try the same sequence above on a perimeter zone on the main panel (Zones 1-16) the system responses normally.  The keypad tells me I have a violated zone, I close it, the violation goes away, and I can arm.
 
I suspect a data communication problem with the M1XINs and the panel but I don't know were to start troubleshooting.  Everything is enrolled and I have triple checked all the wiring.  The LEDs on the M1XINs are flashing.  I have a jumper on the M1XINs on the "no termination 485" side, and a jumper on JP3 on the main panel.  I could really use some help.

 
What do you mean by xin's on buses 3,4 and 5?
,
I would check the power supply to each xin:
 
With the system fully powered check the supply voltage at each xin and compare it to the supply voltage at the source (M1 in this case). You should see somethingin the neighborhood of 13.5vdc.
 
Check for proper data bus termination and wiring:
 
Power the system off and check the resistance across data "a" and data "b" at the m1 control. It should measure 65 ohms +- 10 ohms. If it is not within specs then there is either a wiring problem or improper bus termination. Check your data bus wiring WITH THE SYTEM POWERED OFF by carefully wiggling and tugging each connection with a small needle nose plier. If any screw terminals have more than one wire entering them then be sure that all wires are twisted together before connecting them to the terminal.
 
Mike.

 

[jpmargis]

Sounds like you are having some serious Data Bus communication issues.  Can you diagram the complete system data bus scheme?  I assume that by BUS 2 you mean J2 on the M1DBH, but you don't say what is connected to J1.  Terminator on the highest unused M1DBH jack?  And where are the keypads connected?

 

[RAL]

As Mike said, check your power supply output.  Are you running everything off of the M1's power supply, or do you have also have an auxiliary power supply?  If you are powering everything from the M1, you are very close to the maximum 1 Amp current load, even in a non-alarm condition.  And if you are powering the XEP from the M1 rather than the P1216 wall wart, you will be over the limit.  In general, you don't want to operate too close to the maximum.  Not sure if that could be causing your problems, but it is something to keep an eye on.
 
How many wireless devices do you have configured on the XRFTW?   Since you have XINs starting at bus address 3, you have to be very sure not to go configure any wireless devices above zone 32.   It's generally a good idea to configure the XINs up at the high end of the bus address range and grow them downward, and leave a gap between wired and wireless zones in case you ever want to grow the wireless above zone 32.  Otherwise, you end up having to reconfigure all the wired zones if/when you want to add more wireless.

 

[zaffyhp]

Hi Mike and RAL. I almost feel like I know you guys! I just spent two hours this morning reading (and believe it or not actually following) the 20 pages of discussion on Mike's garage 250 feet away.

Let me start by fessing up on the firmware and bootloader updates. After I wrote to the forum for help I went back to check my firmware status after reading in Mike's situation about being told by ELK to go to firmware version 5.3.0 for his panel. Somehow I remembered my system being at 5.2.something. Sure enough my panel was at 5.2.4 and my NAV keypads were at 1.0.5 (latest version is 1.0.26). The NAV keypad bootloader was also out of date. I had downloaded the updated firmware and bootloader for my panel and devices in ELKRP2 but didn't know I had another step to actually apply them. Newbie! So while you guys were writing me back I was applying the updated firmware.

I have only done one test after the firmware update but it is very promising. I went to the same perimeter window on a zone on a M1XIN input expander and opened the window to violate the zone. I went to the closest keypad and tried to arm in the STAY mode. The keypad told me that I had a violated zone. I viewed the zone and it was 43. I went back to the window, closed it, and the keypad said "Zone 43 Normal". (OBTW Zone 43 and that window matched in my plan). I then pressed stay and the System did a 60 silent second countdown.

I have more testing to do under different scenarios but my situation is looking promising. As Mike once said, I will take this as personal defeat if I can't figure this out.

 

[zaffyhp]

I think this issue may be solved with the firmware updates. I have tested the Exit and Stay functions and they are now working as expected. I have some PIRs in range of my keypads (they are defined as Burglar Interior Follower) and when I approach the keypad the keypad shows 1 zone violated for about two seconds while the PIR changes state back to normally closed. Then the violation message disappears and the keypad says Ready to Arm as expected. I will leave this problem open for another 24 hours before marking it solved and provide a final status tomorrow.

With regards to power, my panel is only powering the:

Three M1XIN expanders (from the M1DBH),
One M1XRFTW (from the M1DBH,
Four NAV keypads (from the M1DBH),
One SP12 speaker (panel Output 1)
One ELK-74 siren (panel Output 2)

I am not running anything off the panel AUX terminals.

The M1XEP is running off a P1216 plugged into a CyberPower 1500AVR UPS

I am using a ELK P412 (12vdc, 4a) power supply to power:

Five SL1 strobes via programmable panel Outputs #12-16 via a M1RB relay board via a PD9HC power distribution unit (P412 output #1)
Thirteen Honeywell DT-7435 motion detectors via two PD9HC power distribution units (P412 output #2)
One ELK 150RT and one ELK 71 via programmable panel Output#3 (P412 output #3)

Thanks to everyone for responding so quickly. More to follow tomorrow.

 

[zaffyhp]

RAL, I like your idea about starting high in my hardwired zone assignments and working down. I did not due that thinking I only would need a max of 16 wireless zones. Right now all 16 wireless zones are disabled because I don't have any sensors enrolled. I have three potential uses but have not bought any sensors yet. That is a project for another day.

Based on my last post about my power solution, do you still have concerns about hitting any amp limits?

 

[mikefamig]

It sounds like you have it under control but be careful not to hurry forward. I did that and learned the hard way to move ahead slowly and carefully. Let the system run and prove itself for a few days before moving forward.
 
Mike.

 

[mikefamig]

RAL, I like your idea about starting high in my hardwired zone assignments and working down. I did not due that thinking I only would need a max of 16 wireless zones. Right now all 16 wireless zones are disabled because I don't have any sensors enrolled. I have three potential uses but have not bought any sensors yet. That is a project for another day.

Based on my last post about my power solution, do you still have concerns about hitting any amp limits?

If you are registered with Elk you can download their current load worksheet
 
http://www.elkproducts.com/Owner_support_tools.html
 
Mike.

 

[RAL]

RAL, I like your idea about starting high in my hardwired zone assignments and working down. I did not due that thinking I only would need a max of 16 wireless zones. Right now all 16 wireless zones are disabled because I don't have any sensors enrolled. I have three potential uses but have not bought any sensors yet. That is a project for another day.

Based on my last post about my power solution, do you still have concerns about hitting any amp limits?

 
I can't take credit for the idea of placing the XINs at the top of the address range and working down.  I picked that idea up from another thread here when I was first learning about the M1.
 
I was also going to point you to the Elk current draw spreadsheet, but Mike beat me to it.  I think your load on the M1 is ok from what you've described, but run it through the spreadsheet to be sure.

 

[Del91574]

M1 sounds OK, but the largest mistake people make with the M1 is not factoring in the "active" state of power suckers like an XOVR or RB, not to mention the alarm state of all powered devices connected to whatever device (PS or panel).
 
For peripherals on the M1, you need to ensure their backup capacity exceeds the M1 otherwise it's not a pretty picture as a supply sags or LB condition exists.

 

[mikefamig]

1
I added a 4 amp aux power supply to my M1 on DEL's advice and am glad I did. I can't say for certain that it cured problems that I was having but I feel that the M1 is a little lacking in power if you add anything beyond zone sensors. Powered motions and wireless transmitter and other devices add up fast.
 
Play with Elk's spreadsheet and you'll see what I mean.
 
Mike.

 

[Del91574]

All systems are lacking in power....as others may say "horses for courses". Once you look at (and do the math) you find that all of them will require a separate power supply of some sort for anything but a basic and bare bones system.
 
Hell, even the large hardware I play with typically needs additional power and they come with 5A or larger supplies.

 

[zaffyhp]

Thanks to all for the support. It has been over 24 hours now and I have armed and disarmed many times under a number of different scenarios (doors and/or windows open, bypass, etc.) I am happy to report everything is working as it is supposed to base on all my reading. I don't have any more equipment to install at the moment so as Mike recommended I plan to take it slow and start planning what automation and tasks I may want to accomplish in the future. I also plan to take some the UTube Webcasts about Rules to start.

Thanks for the suggestion about the ELK current draw spreadsheet. I am an ELK member and have access to these ELK tools. I definitely plan to use the spreadsheet to run the numbers especially after what DELInstallations said about current draw of devices during active states. It will also help me if or when I expand the system.

I am going to code this issue as solved and I want to thank you all for your time, suggestions, and support. As I get smarter maybe I'll get a chance to help someone else out in the future.