Another wireless sensor/M1XRF issue

IVB

Senior Member
Just noticed another window that I'm using a wireless sensor in reporting as being open, even though it's closed. This time, thank god, it was before we armed it, not after.

The M1XRF is in the crawlspace, but only perhaps 50' max away from this. Anyone else having issues? All seemed fine for at least a month if not more, can't remember when I put these in.
 
Hey IVB:

I've had this issue with two different GE Crystal Micro contact sensors - luckily each of them has only had the problem once. The first time, we were laying in bed at 5AM and heard a voice chime ("front bedroom window") immediately followed by the alarm of course. This is on the complete opposite side of the house from where we sleep, and needless to say I thought it was for real, so I had a gun in my hand and was running that way within 10 seconds (but hey, I live in Texas). I got to the front bedroom and all was well with the window. I was able to immediately silence/acknowledge/re-arm with my keyfob, so the violation of the window was only transient. I put it down to some peculiar occurence of interference with the crystal frequency and went on with my life, albeit with a tanking WAF due to the scare.
About 2 weeks later, I'm sitting in my living room (which is open to the kitchen) with the Elk disarmed, and I hear a chime for the kitchen window - same deal - no actual violation could have occurred. THANK GOD the wife was shopping at the time.....I got a little worried when this happened, but neither of them has acted up since.
To test range, I took both of the sensors twice as far away as they originally were, and walk-tested them in mid-air (with my wife's help). I could not get either of them to lose signal with the receiver until I was more than 500 feet away, and that was through A LOT of obstructions both times, so I don't think it's a range issue. Both of these sensors are in sight of the street in front of my house, which is fairly busy. For these reasons, I suspect that something is causing a passing inteference with the transmitters, although that SHOULD cause a transmitter missing trouble, and not a violation.
No false alarms while away from the house yet though, (knock on my wooden head) and I admit that after the second time this happened, I did get a little worried about false away alarms, which would cause my wife's phone and work email to receive text messages, thoroughly freaking her out and making her question our investment. The security side of my Elk is COMPLETELY wireless and relies entirely on the M1XRF, so this is particulary pertinent to me......
I asked Jim at Automated Outlet if he ever experienced this issue when he was beta-testing the receiver for Spanky prior to its release - he said he never did have this happen. I asked Martin too, but if I remember correctly, he didn't beta test this particular Elk module. Anyway, I believe there is something very specific happening here, and I hope whatever it is stays FAR away from my house from now on......
 
The GE/Caddx/ITI transmitters check in with their door open/closed status about every 62 minutes. Should the transmitter not check in for 24 hours you will get a missing transmitter message on the keypad.

The long data packets have checksums. Two of eight data packets must match and the 3 byte transmitter ID must be an ID stored in the M1 before the data packet is sent to the M1 for processing.

Make sure you have M1XRF software version 1.0.8. Pre-production beta versions did not have the dual packet comparison protocol.

It is really, really, really, really hard to get a valid false data packet over the air.

I have seen some transmitters do some funky things though.
 
Thanks for the replies (and the props). Yep, on 1.0.8.

Obviously, this has the wife irritated and wanting me to replace the wireless windows with wired, which is a crapload of work. Any other thoughts other than "see if it happens again"?
 
i'm just throwing this out there, so i'm sure you've already thought of it, and it's off the top of my head so details may be off a little, but isn't there two types you can assign each zone to, a short violation and a long violation? i think it's fast loop response and slow loop. can you set these wireless zones to be slow loop responses, so that they have to be violated for a significant portion of a second for them to be considered violated, or am i not understanding the usefulness of these values?
 
They're not set for Fast Loop Response, but thanks.

At this point i'm declaring the use of wireless sensors to be a big mistake. I'm going to pull them all out and replace with wired ones. If your network wifi cxn drops out, the cops don't come. Another one failed, wife couldn't alarm the system, and had to get me out of bed as I had decided to go to sleep early in advance of a big day tomorrow. Oh well, I guess another 8 cups of coffee day is in my future.
 
The Fast and Slow Loop response does not work for wireless zones. The transmitters do all the loop response timing. When they detect a valid opening or closing, they send the message to the RF receiver which then sends it to the control.
 
Well I would just like to point out that, aside from the above mentioned occurrences, my system has worked flawlessly. I have 22 wireless contacts, as well as motions, glass breaks, and smokes, all wireless devices, and everything has been very reliable in general. The two incidents mentioned above occurred right when I first got my elk and all sensors and had just set everything up at once about a week beforehand. For the past month it has been absolutely dead-on perfect. I'm not quite at the point of sharing IVB's position on wireless sensors yet - but then I have no other choice for reasons I won't go into regarding my house. Needless to say I have made a considerable investment (over half my startup cost was the wireless sensors) and I'm not ready to give up on it .

With that in mind, wouild also like to admit to Spanky that a small percentage of my devices are SAW and not Crystal, just in case that furthers the cause here. I'm referring to my 4-button keyfobs as well as my PIR's (I think that's all). Could there be any "*intra*ference" or signal confusion on 319.5? I know we've been round and round about that topic recently, but not in this context. Thanks.
 
My biggest issue is that any form of "see if this works" requires a call from NextAlarm and/or a visit by our police department on event of failure. Now that it's 3 inside of 7 days, it *might* be the receiver or might not, but there's no easy way to tell and I certainly don't have the confidence that anyone else has in it.
 
Well I monitor myself for now, so I can try all the "see if this works" stuff without incident - I'll just need to disable the bosses (read: wife's) text and email notifications temporarily in the M1XEP setup (she doesn't actually act on them anyway, she just calls me). So I certainly don't mind being anyone's guinea pig to an extent (which is why I asked if you needed any hardware beta testers for Vista Spanky) However, I think the thing is that, until someone can predictably reproduce this transient problem, it is going to be difiicult for Elk to know how to approach it, or if it warrants approach at all VERSUS being an issue with intermittently faulty sensors or receiver that IVB or me could have for all we know. I guess what I mean is that I'm not sure how Spanky could really tell us any "see if this works" tips at the moment, and understandably so.

Feel free to make me eath those words though Spankster. This thread has given me an idea for something else to ask about, but I don't want to hijack this thread, so Ill create a separate topic for it. Thanks.
 
Back
Top