Texecom Ricochet PIR sensors not detecting movement for a long period

[Beverly27]

Our Texecom 64-W is connected to several Ricochet sensors. I noticed this problem when I came downstairs last week and forgot to turn the bedtime mode (part-arm mode) off, meaning that the ground floor Ricochet PIR sensors were all still active.
The alarm did not activate for a decent period of time, which I presume means that the Ricochet sensors didn't detect my movement and activate immediately, which they should have done. Ricochet Monitor does not show any battery issues, so I'm reaching out here to ask what the common causes of an issue like this might be, and how I solve it.

 

[secureiam]

Very vague and could be absolutely anything,

What do you mean by didn’t activate for a decent period of time
what sensors?
How are they programmed?
What height they set to?

 

[secureiam]

Anything recorded in the log, from passing g the sensors to alarm activating and you silencing with code.

 

[Beverly27]

Very vague and could be absolutely anything,

What do you mean by didn’t activate for a decent period of time
what sensors?
How are they programmed?
What height they set to?

Fair comment, Secureiam! I installed the alarm system a few years ago. The PIR sensors downstairs usually activate immediately when we come downstairs in the morning, detecting our movements. The first one that picks us up is in guard mode, allowing us to turn the alarm off at the keypad. If we don't do this, the others detect us and trigger the alarm. Therefore, the sensors' height is not the issue because they had always worked up until recently. In terms of the time before the PIR sensors triggered on the occasion in question, they had previously always done so immediately. Still, on this occasion, and it continues to happen, neither the guard PIR nor the other PIR sensors downstairs activate for fifteen to twenty minutes. During this time, we have been wandering around downstairs. We have now taken to deactivating bedtime mode once we come downstairs, even though the PIR sensor on guard mode no longer detects us, which it always had done previously. None of the PIR sensors' positions or heights have been adjusted. The PIR sensors are Texecom Premier Compact PW-W. In terms of how they're programmed, I'm not sure what you mean.

 

[Beverly27]

Anything recoded in the log, from passing g the sensors to alarm activating and you silencing with code.

When I come down tomorrow, I'll not turn off the alarm so that I can then check the log to see.

 

[secureiam]

you have to remember if we didn’t install your alarm or look at the setup directly or aware of its history we would first need to establish some information.

Whilst you may have posted before we are not likely to try and guess what you have now or if the setups changed from your previous posts.

E/E zones start entry tones
Guard access zones don’t sound if e/e has started and first entry timer hasn’t expired at default but people often reprogram this zone
Guard zones set off alarm normally if triggered first, these functions may change from full set and part set depending on how they are configured.

Zones omitted during a particular part set won’t activate at all.

If no programming has changed.

If you sensors have been in a while 2 years plus, change batteries in first instance.

If that doesn’t solve the issue place a device on chime wait 5 minutes and see if the device chimes or there is a delay. Try every 5 minutes on pirs all the time on wireless shocks and contacts

You can go through the event log at any time it has lots of events stored and would expect it could show something of interest.

For example if the system wasn’t set there be not entry for that set,

If the system didn’t start the entry timer as usual if the system was set, but as I don’t know if like many others it’s setup correctly, not uncommon to see wrong zone type and zone omitted in part set or that the correct zone type but attributes changed so functionality changes.

 

[Beverly27]

I understand Secureiam and am grateful for your advice. I haven't reprogrammed anything, so the E/E zone isn't functioning properly because the entry tone used to start when we came downstairs, which it no longer does, nor are the guard zones detecting us immediately. When I have a moment at the weekend, I'll check the log from today and will post it. Thanks again!

 

[secureiam]

okay if you open one of the devices does the tamper go off?

I suspect either low battery or signals may be being jammed.

That’s assuming programming not changed

by putting the chime on a sensor and ensuring chime is working.

If the system is being jammed you may get the odd chime, or a delayed chime. (Easiest to do on door contacts as they are always awake).

I have seen this recently where no warnings regarding jamming have been given but system didn’t appear to activate all the time or chines were delayed.

The culprit was the wireless street lamps and when it was fixed the system worked normally.

However we need to establish the behaviour first, so battery replacements is

Not a fan of petwise sensors but as it was working for you would expect it to still work if nothing else has changed

 

[Beverly27]

I understand Secureiam and am grateful for your advice. I haven't reprogrammed anything, so the E/E zone isn't functioning properly because the entry tone used to start when we came downstairs, which it no longer does, nor are the guard zones detecting us immediately. When I have a moment at the weekend, I'll check the log from today and will post it. Thanks again!

Apologies for the delay in posting. I've reviewed the event log, after testing this again today and it states:
QUICKPART1 Armed 00:25.11 05/11 (I presume this is when we part armed the alarm before going to bed last night)
Zone013 Alarm 09:14.51 05/11 (this must have been when the alarm triggered after I'd been downstairs this morning for a couple of minutes, before the PIR sensors detected me)
BELL Active 09:14.52 05/11
ALARM Active 09:14.52 05/11
Zone13 Restore 09:15.00 05/11 (Alarm deactivated by me I suspect)

There was nothing in the log about the sensors picking my movements up prior to the alarm being activated. Does this help shed any light on things?

 

[Beverly27]

okay if you open one of the devices does the tamper go off?

I suspect either low battery or signals may be being jammed.

That’s assuming programming not changed

by putting the chime on a sensor and ensuring chime is working.

If the system is being jammed you may get the odd chime, or a delayed chime. (Easiest to do on door contacts as they are always awake).

I have seen this recently where no warnings regarding jamming have been given but system didn’t appear to activate all the time or chines were delayed.

The culprit was the wireless street lamps and when it was fixed the system worked normally.

However we need to establish the behaviour first, so battery replacements is

Not a fan of petwise sensors but as it was working for you would expect it to still work if nothing else has changed

I'll give these steps a try Secureiam and will update you as to how I get along. If it was the batteries though, shouldn't the Ricochet monitor alert me? No change in programming and as you rightly point out, all was working as it should until recently.

 

[secureiam]

This tells me the alarm entry didn’t start, and zone 13 is working normally.

So when the system is part armed you would normally walk past a sensor that starts the entry tone, although some households don’t.

It doesn’t tell me which other zones you pass.

The panel should notify if the battery is low, depending on the version it may manifest itself as a tamper rather than low battery o some devices,

Ricochet monitor would show the devices and there current state.

So the priority is to check the programming and batteries for the device that should start the entry in the first instance.

If you do a walk test the devices should light up if they are working as you walk past them.

 

[Beverly27]

This tells me the alarm entry didn’t start, and zone 13 is working normally.

So when the system is part armed you would normally walk past a sensor that starts the entry tone, although some households don’t.

It doesn’t tell me which other zones you pass.

The panel should notify if the battery is low, depending on the version it may manifest itself as a tamper rather than low battery o some devices,

Ricochet monitor would show the devices and there current state.

So the priority is to check the programming and batteries for the device that should start the entry in the first instance.

If you do a walk test the devices should light up if they are working as you walk past them.

I'll do the walk test and see what happens. The entry mode programmed PIR seems to be working again now, because when I walked downstairs this morning it detected me and commenced the countdown - the log shows ENTRY Start 011 09:25.21 06/11. I then entered my code to deactivate the Part-Arm. After I had done so, the log then showed Zone012 Unbypass 09:25.28 06/11. Any idea what this means, please?

 

[secureiam]

What was the part arm recorded as in the log for this sequence of events?

Unbypass is interesting, you saying that this appeared in the log after you unset the system.

This suggests at some point it was omitted (bypassed). Now that is usually when it’s omitted manually and you can program the panel to omit a zone and remember to keep it omitted.

So for me we don’t have a full picture.

We won’t get to the bottom of this without the zones programming and full logs from set to unset along with the sequence of events you witnessed.
There should be somewhere in the log for example about zone 12 being omitted (bypass).

Going back a while now there was some strange behaviour on a version think is was version 4.x but can’t remember for sure, where there was strange behaviour when you part set the system 3 /4 times on the trot without a full set in between.

Not sure if this was posted on this forum but it certainly was on the Texecom forum.

Again I can’t remember the full details and can’t be certain it’s related but it’s a possibility .

I think I suggested it sounds like it was related to the number of times a zone before a zone locks out so you could program the zone by taking off the attribute.

summary panel version and programming and log but the event log is going to have to go back several arms and disarms to rule out the zone lock out thing for sure. At least between the last full arm before this issue started to recent days.