Elk M1XRF319 wireless zones acting opposite - READY=NOT READY and NOT READY=READY

[jcd]

Hello!

Like many before me, I've been migrating from an HAI OmniPro II to the Elk M1 and I've spent the past couple months slowly (re)building my knowledge with the language, settings, and features of this new architecture. I'm at the stage where I'm configuring wireless security sensors (GE/Interlogix) and have run into one major idiosyncrasy I'm unable to resolve:

When I enroll a sensor successfully (itself a VERY fussy process!) I am finding that Elk interprets the OPPOSITE state/status desired. For example, a wireless (reed) window sensor shows READY when the window is open, and shows NOT READY when the window is closed! Same with Ion (plunger) sensors I'm using for doors: the M1 reads the sensor as READY when the door is open, and NOT READY when the door is closed.

ElkRP (which loads and connects fine without any conflicts, BTW) shows settings configured properly (as I understand) as:

• Zones are Enabled
• Definition = 01 Burglar Entry/Exit (window contact) or 03 Burglar Perimeter Instant (Ion plunger)
• Type = 1 Normally Closed (for both)
• Supervised = 1 Normal Supervision
• Loop = 2

Tx ID, DL, and H ID values in the setup are all populated and when the zone is activated I can see the Tx/Rx lights and bus activity on the M1XRF319 board, so it does seem that everything is working and setup as it should be.

I've tried to mess around with all of the above settings, but these as shown are "right" and if I change anything then it doesn't work at all. So as configured it is recognized and "works" but it's just backwards!

Is there something I'm missing?

Thanks in advance to the many people who so graciously share their expertise and learned experience here!

System: M1G
Hardware: 0.13
Boot: 3.3.6
Firmware: 5.3.18

System: M1XRF319
Hardware: 8.0
Boot: 0.0.0
Firmware: 23.2.2

 

[RAL]

Are you seeing this when you first start up the M1? Or does it continue to show the opposite even after you open and close the door or window several times?

 

[jcd]

Hi RAL - yep, it's consistent behaviour. On startup, within ElkRP, and persistent even after opening/closing/arming/disarming/connecting/disconnecting, etc. over the course of days. I've even cleared (un-enrolled) the sensors and re-enrolled multiple times and it's the same thing always. It's very strange!

 

[jcd]

Adding to the fun here, now I'm getting reports of a "lost transmitter" - even though both transmitters I'm testing, backwards as they are, are in fact still showing and operating/triggering (again, just in reverse). And both of the transmitters I'm testing have new batteries and are less then 4 feet away from the M1 and the M1XRF radio (bench testing), so I know it's not a range/blocking/interference issue.

Something is not right here. I'll reach out to Elk technical support and see if they can discern what's gone wrong here. Will report back when I get an update!

 

[McKinneySmart]

One thing I remember about the M1 is that the zones used different value end-of-line resistors.
Just fuel for thought.

 

[Sandpiper]

I seem to recall that this can happen if the sensor is programmed incorrectly. Check the installation manual for the sensor, on the part for the initial programming. Seems to me that when programming, the sensor must go from the secure state to the non-secure state or visa versa. Some sensors require the tamper to be tripped instead of the alarm sensor.

You may have to delete the zone and re-install.

 

[jcd]

One thing I remember about the M1 is that the zones used different value end-of-line resistors.
Just fuel for thought.

Thanks Jay (love your signature, BTW about line resistors!)... yes, but this is wireless

 

[jcd]

I seem to recall that this can happen if the sensor is programmed incorrectly. Check the installation manual for the sensor, on the part for the initial programming. Seems to me that when programming, the sensor must go from the secure state to the non-secure state or visa versa. Some sensors require the tamper to be tripped instead of the alarm sensor.

You may have to delete the zone and re-install.

That's what I'm thinking, thanks - though I've also gone through the myriad different options and the ONLY set of config I can get it to work on (at all) is how configured. But yeah, I'll keep at it and I've got some Elk tech support lined-up to try to help me get sorted. I'll post back what I learn!

 

[RAL]

This is a bit of a long shot, but worth checking. Is there any chance that you have the Data A and Data B wires swapped on the connection of the M1XRF319 to the M1 (e.g. Data A on one end to Data B on the other end)? I would think that if you did, it wouldn't work at all, but I guess it is worth looking at just in case.

 

[Sandpiper]

Try changing the type to "normally open."

 

[jcd]

Hey friends! Well, good news: I think we can chalk this one up to operator error (ish)...

For the record, the correct zone setting is: Type 0 = EOL Hardwire / Wireless

I think the real lesson here is: don't change too many variables at once! Between enrolling, unenrolling, configuring, updating the DB, writing to the control, etc. etc. I think there were just too many variables in play. I swear I did try this zone setting of "0" but I'm sure somewhere it got lost in the various other things one needs to do (saving, writing, updating config in two different places (!?) and so forth. So I remind myself: change one thing at a time; test, repeat.

I'm always happier with a user error than a technical error in any case, and anyway, all working now and appears stable. I appreciate those who took the time to give this a think with me - THANK YOU!

 

[Sandpiper]

Nice.