ELK Lost Transmitter Error

[Piasa]

I have a number of 5800s which are functioning as expected.
 
What do you mean by allowing them to time out from their sleep functionality?  I understand from reading the accompanying literature that "during normal operation, only one transmission sequence will occur in a three minute period to conserve battery life"  Is this what you are referring to?  If so, I would not know how to circumvent this feature even if I wished.

 

[Del91574]

It's more of a question about your configuration and choice of devices.
 
It's published information by Elk that the 5800PIR is not a "listed" device so issues may arise. They may work, they may have intermittent issues. As I said, I had issues with GE wireless billtraps that were by all rights, supposed to be compatible but not on the list of "approved" devices. Quirks arose and then it became a wait for Elk to write a firmware to fix the issue in my case and then release as an update.
 
If you're expecting the PIR's to constantly trip the chime feature, they will not. There is the inherent 3 minute transmission inhibit as well as they will not send restoral reports, so chime on most RF motions will not function the same as a RF contact. Nature of the beast. They will time out for 3 minutes from each fault transmission unless in walk test mode (PIR only). You're never going to get the chime to function properly.

What will I do with this information?

 

[Piasa]

Elk literature states the the ELK-M1XRF2H is "compatible with Honeywell 5800 series one-way transmitters..."
 
Are you saying that the ELK-M1XRF2H is compatible with the 5800PIR, but the ELK-M1XRF2H is not compatible with the M1?  
 
Does the 5800PIR communicate through the 2H directly with the M1, or does it communicate with the 2H, and then the 2H communicates with the M1?

 

[RAL]

Elk literature states the the ELK-M1XRF2H is "compatible with Honeywell 5800 series one-way transmitters..."
 
Are you saying that the ELK-M1XRF2H is compatible with the 5800PIR, but the ELK-M1XRF2H is not compatible with the M1?  
 
Does the 5800PIR communicate through the 2H directly with the M1, or does it communicate with the 2H, and then the 2H communicates with the M1?

 
What DEL is getting at is that if you look at the title page for the M1XRF2H manual, it says:
 
"Compatible with specific models of HoneywellTM (AdemcoTM ) "5800" Style Wireless Sensors.
Refer to page 8 for a listing of compatible sensors."
 
Elk has tested the M1XRF2H with the listed models, and has found them to work properly with the M1.  But there are many other 5800 type sensors out there that have not been tested, and because they may be implemented slightly differently, they may have problems.  Some types work and others may not.
 
The M1XRF2H receives the signals from the sensors and translates them from 5800 protocol to M1 data bus protocol. The 5800 sensors don't talk directly to the M1.  It's in that translation process where there is potential for incompatibilities.
 
Are the PIRs that are giving you trouble the only two PIRs that you have, or do you have other identical PIRs that still work ok?

 

[Piasa]

I have 4 PIRs that work.  And many window and door sensors.
 
If the 5800PIR communicates with the M1XRF2H, which translates and communicates with the M1, how can there be a compatibility issue?  The H in the M1XRF2H presumably refers to "Honeywell", and the 5800PIR is Honeywell, so surely the two are compatible (he says with tongue firmly implanted in cheek).  And if the 2H communicates correctly with the M1 for the other 5800PIRs, as well as the multitude of other wireless sensors installed, where could compatibility issues arise?

 

[RAL]

I have 4 PIRs that work.  And many window and door sensors.
 
If the 5800PIR communicates with the M1XRF2H, which translates and communicates with the M1, how can there be a compatibility issue?  The H in the M1XRF2H presumably refers to "Honeywell", and the 5800PIR is Honeywell, so surely the two are compatible (he says with tongue firmly implanted in cheek).  And if the 2H communicates correctly with the M1 for the other 5800PIRs, as well as the multitude of other wireless sensors installed, where could compatibility issues arise?

 
Speaking in general, anytime you have a protocol, there will be a data stream that has defined fields and acceptable values.  It's common for a receiver to do some checking on the received data for validity.  Sometimes, the checking that is implemented is more specific than it should be.  For example, the person who wrote the code might check an incoming value against a list of values that current transmitters are known to send, rather than against the list of all allowable values.  Then, sometime in the future, a new type of transmitter sends a valid, but unexpected value in that field, and things don't work.
 
Or, an untested type of transmitter might send a different sequence of events than those that have been tested, and that sequence brings out a bug on the receiving end.
 
In both cases, you end up with an incompatibility.
 
That said, since you say you have other PIRs (of the same model type?) that do work ok, I don't think you have an incompatibility issue.
 
Some possible causes that I can think of:
 
1. Even though you've replaced the batteries, replace them again.  I've seen supposedly new batteries that are weak or bad more than once.
 
2. Check for dirty or corroded battery contacts on the PIR.
 
3. The PIRs have failed.  Seems unlikely that two would fail at the same time, but not impossible.  Here's a thread where multiple GE wireless sensors failed. So it can happen!
 
4. Some type of RF interference.  But it's hard to explain why it would affect just 2 sensors and not others, and why they would still fail when placed close to the receiver.

 

[Piasa]

RAL,
Thanks.  I have certainly considered that the devices are bad.  I've measured the voltage of the batteries, so am confident that they are not the problem.  Also, I have a audio system that picks up sounds when the device is triggered, so I know that it is sending something each time it is triggered after the timeout period.  So it seems that whatever it is sending is not identified as a valid transmitter code by the receiver.

 

[RAL]

RAL,
Thanks.  I have certainly considered that the devices are bad.  I've measured the voltage of the batteries, so am confident that they are not the problem.  Also, I have a audio system that picks up sounds when the device is triggered, so I know that it is sending something each time it is triggered after the timeout period.  So it seems that whatever it is sending is not identified as a valid transmitter code by the receiver.

 
Well, it could be that even though the PIR appears to be sending something, the transmitter circuitry is what has failed and is not transmitting a clean signal.  Or that the batteries are just barely strong enough to power the PIR, but not strong enough to actually transmit a reliable signal.
 
The best way to test the batteries is under a maximum load.  Measuring the voltage with no load won't give you a reliable good/bad indication.
 
I don't think you have a problem that is caused by the receiver.  If the receiver were bad, I'd expect errors from the other sensors as well.

 

[Del91574]

The fact you stated the devices were installed at differing times points to possible incompatibility issues or background other issues. FWIW, the 5800PIR has had at least 3 redesigns and add's since it has been introduced, so that comes into play.
 
Lithium batteries may meter fine for voltage using a DMM, however they typically fail under load (transmission in the case of RF devices). This is the specific reason why many manufacturers specify the brand of battery to be installed....in the case of Honeywell, a 3V lithium battery across the board is not equivalent. They typically specify Panasonic, Duracell and a few others (I can picture the label but not the name) because other units can't handle the total load imposed by the circuit though they're still a CR123 and 3V.
 
As for what Honeywell devices transmit, it's the hex value ESN and a loop number (simplified in this case).

 

[drvnbysound]

I didn't really read through all of this, but I helped a friend install a XRF2H this past weekend and he has since enrolled a 5800PIR and it's working without issue.