ELK m1 GOLD Wireless Group changes to HARDWARE after receive all with ELK RP-2

@ DELInstallations thank you, I rechecked all of the config and reviewed the install documents. The ELKRP software only gives me the "03=Burglar Perimeter Instant" so I selected that as you recommended, there are several options for the TYPE the install document suggests "1=Normally Closed" for the Ademco part 5817 and I selected that. I conducted a test by opening and closing one of the door with this sensor  - the chime worked, the keypad identified the door - but the status changed from NORMAL to VIOLATED and remains in that status. The system was not armed.
 
SGUPTA0001 said:
SGUPTA0001, on 01 Aug 2013 - 10:20, said:
@ DELInstallations thank you, I rechecked all of the config and reviewed the install documents. The ELKRP software only gives me the "03=Burglar Perimeter Instant" so I selected that as you recommended, there are several options for the TYPE the install document suggests "1=Normally Closed" for the Ademco part 5817 and I selected that. I conducted a test by opening and closing one of the door with this sensor - the chime worked, the keypad identified the door - but the status changed from NORMAL to VIOLATED and remains in that status. The system was not armed.
You might be confusing what the M1XRF2H install document is saying.
It's saying that on this particular sensor (5817 which has externally wired inputs) that the sensor expects you to be wiring/connecting N/C contacts (a N/C contact provides a closure or short when the door is closed and opens when door opens). That is the default expectation of the 5817. But in this industry you can also buy door/wnd contacts that are N/O (provides no connection when door is closed but provides a closure or short when door opens). So if you did use N/O contacts rather than N/C you'd need to modify the option bit in ELKRP (wireless zone option 2) in order to flip the logic.

Don't know if this is causing your problem or not but whenever you program a wireless zone you need to be programming the M1 Zone Def Type as 0=EOL Supervision/RF. Do not set this for 1=Normally Closed.
 
 
Thank you  - I appreciate the help. I now understand the basics; I have reconfigured all wireless door sensors as "03-Burglar Perimeter" and updated the TYPE to
"0=EOL Supervised/RF" and the status has changed to "NORMAL" for all sensors right after the install - but the issue remains that when a door is opened and closed the zone status changes to " VIOLATED" and does not automatically return to "NORMAL" as expected.
 
I have attached the screen shots - I will greatly appreciate if you can see the config of the devices on ELK-RP and let me know if I need to change or select any option.  
 
[sharedmedia=gallery:images:608]
[sharedmedia=gallery:images:607]
[sharedmedia=gallery:images:606]
 
You wouldn't want entry doors like garage and front door to be "Instant" - just burglar perimeter otherwise you won't get the entry delay when coming home.
 
It's something in the configuration... don't know if it'd be applicable, but do you ahve the option set for auto-restore like a motion would use?
 
The ELK-RP software does not list "Burglar Perimeter" the only option is "Burglar Perimeter Instant" the ELK RP software I am using is version 2.0.16. I assumed the PIR was only for Motion Sensor as soon as I selected that option all WIRELESS sensors are functioning as expected !! You are a GENIUS ! Thank You !!!!!
 
 
Thank you all who provided me with the setup guidance, I thought this was easy but I am grateful to the experts who helped me configure the system, I am looking forward to integrate with SIRI via SIRI-Proxy and some sort of VOICE command that will enable me to use my voice to send commands to the ELK-m1
 
I'd sure love to take credit but I don't think that's the right fix.
 
Just for grins, I finally pulled up a wireless zone - it's attached; I would expect that the problem lies in Option 1 and/or Option 2.
 
Also for the zone definition, you really should have Buglar Entry/Exit 1 - with instant your alarm will go off instantly when entering an armed house - you don't want that; this is what gives you an entry delay on the doors you'd enter the house from.
 
See my screenshot:
WirelessSensor.JPG
 
I think you said that was a 5817 sensor? If so the enrollment procedure is pretty specific, since that particular sensor can do 3 zones, and must be enrolled the right way.  Have you followed the instructions in the M1XRF2H manual? It shows how to set the LOOP which is what determines which of the 3 zones of the transmitter is used, depending on if it's using a magnet directly, hooked to another contact, etc.  After you enroll the transmitter via the LRN, you have to go back in and edit the zone to get the right LOOP... I'm guessing you missed that part?
 
From the manual for that sensor: Loop 1 is the main loop for a connected contact via the terminals; Loop 2 is what you'd select if it's not using an external contact and just uses a magnet directly next to it; Loop 3 is an extra NC set of terminals for external contact, and Loop 4 is for the internal tamper switches (can be its own supervisory zone).
 
It may not be showing violated right now, but it's nowhere near usable yet until you fix these things and the zone definition.
 
I updated the zone definition to Burglar Exit 1, didn't change the default for opt 1or 2 so neither are checked; all I needed to do is to check the PIR box for auto restore. That's what fixed the issue where the wireless door sensors were not recovering from being in the violated state after that door is open and close. All seems to be working as expected. Thank you
 
You don't want auto-restore on the doors... you want them to restore when the door closes.  You must still have the loop set wrong.
 
All seems to be working great, I am playing with rules - added the Garage on OUTPUT 3 without the relay and added a wired sensor for the garage door. Added the announcement on open/close included the NOT SECURE. I am like a kid in a candy store !!
I am trying to create a wakeup call - here is the rule:
 
WHENEVER THE TIME IS 5:40 AM
     AND THE DAY(S) OF THE WEEK IS/ARE –MTWTF-
          THEN ANNOUNCE Say Time (vm238)
 
When I test it the announcement is "EXIT ERROR ZONED" ?? I am lost, I checked to see if the system had the right time - the NTP is connected and working.
 
I have another rule to check if I closed the garage door - so at 10:00PM I
 
WHENEVER THE TIME IS 10:00 PM
     AND Garage Door (Zn 3) IS NOT SECURE
          THEN ANNOUNCE Garage Door (Zn 3)
 
this one is working exactly as expected - so its not a time sync issue ??
 
How about firing the first rule by changing the system time/date and allowing it to fire to see what is announced?
 
I haven't used that VM before, so I can't comment if it's a holdover that really never worked or not (as some in rules are).
 
I checked the SAY TIME VM (238) it seems that by default this version of RP had it set to EXIT ERROR as soon as I changed it to {Insert Time} its working
 
Work2Play said:
I think you said that was a 5817 sensor? If so the enrollment procedure is pretty specific, since that particular sensor can do 3 zones, and must be enrolled the right way.  Have you followed the instructions in the M1XRF2H manual? It shows how to set the LOOP which is what determines which of the 3 zones of the transmitter is used, depending on if it's using a magnet directly, hooked to another contact, etc.  After you enroll the transmitter via the LRN, you have to go back in and edit the zone to get the right LOOP... I'm guessing you missed that part?
 
From the manual for that sensor: Loop 1 is the main loop for a connected contact via the terminals; Loop 2 is what you'd select if it's not using an external contact and just uses a magnet directly next to it; Loop 3 is an extra NC set of terminals for external contact, and Loop 4 is for the internal tamper switches (can be its own supervisory zone).
 
It may not be showing violated right now, but it's nowhere near usable yet until you fix these things and the zone definition.
Do not use the PIR auto restore option for a door/window sensor.  You want them to send their own restore only after the door or window closes.   I suspect the tamper switch is not closed on the offending sensor(s) which will cause all loops to remain violated.  But setting the PIR auto restore option is not the solution.  In fact, it is masking over the problem by allowing M1 to force restore the zone even though the door or window may be wide open.  Check the tamper, or check the loop assignment like Work2Play has suggested.  Something is not correct.
 
Back
Top