External PIR-s constantly 'on', Alarm Pro night mode problem

[stachoo]

I am using Idra for my house's alarm system and I'm having two problems, which I can't solve:
1. External (non Idra) sensors remain on for long periods of time.
I use external motion sensors (non Idra) connected to an ODI. My sensors work in NC mode (they open contact when they sense a movment). From time to time, Cortex shows these sensors as red (sensing a movment) for extremely long periods of time (several hours) despite the fact that there is no movement around and the sensor is reporting no movment (open contact).
I think it might be due to Cortex sometimes missing a message reporting the ODI input got opened. How could I avoid it? Will it influence the alarm system?

2. In Alarm Pro, there's a special "Occupied (night) mode alarm" which is used to protect a property when the owners are asleep. I have configured this alarm with connections from external sensors placed in the garden. However, the system seems to be detecting movments from internal sensors that have been configured in the "Inputs affecting arming control" tab as "Sensors which will be ignored whilst user is on the way to disarming the alarm but will be used to detect an intruder when armed".
I can't remove these sensors from that tab since they are necessary for the basic "Unoccupied (day) mode alarm".
Is there a way to make the night mode ignore sensors defined in "inputs affecting arming control"? Or maybe there's another way of getting around this problem?

[Viv]

1. If you check the electrical state on the input of the ODI you can verify what the real condition of the input is (low or high).

Cortex should not miss a message. Indeed it will poll the ODI approx every 5 minutes and ask what state it is in to check it is working and what state the inputs are in.
I suspect your PIR is working in the reverse state so you need to use the Invert input option.

2. You are using the development version of Cortex 25.0.0.84 or earlier. An update is available to disable "Sensors which will be ignored whilst..." inputs for the Occupied Night alarm.

Viv.

[stachoo]

Viv,
Thanks very much for Your prompt answer and remedy for the night alarm problem. I have tested it and it works without any problem.

Regarding the external PIRs, I have mesured the input with a multimeter and the sensor works correctly (reporting a closed contact - no movment detected) while cortex is showing 'red'. The PIR is configured as 'inversed' as you suggest.
The last line of the events log for that PIR is showing 'movment sense'. When I stop and restart the network, the PIR icon in Cortex turns off to the correct state and a 'movement off' message is appended to the events log. The problem happens from time to time for different external PIRs connected to different ODI-s, so I suppose it isn't hardware-related.
What else could I check to fix this??

[Karam]

May I suggest when you next notice this issue that you perform a node profile analysis on the ODI that is involved (Tools | Node Profile utility, select module from drop down and then click on Read Node) and send us the resulting analysis output. Also let us know which input the PIR is connected to. Also check to see if the PIR indication in Cortex goes back to an OFF state after the analysis process.

[stachoo]

Karam,
I have just performed the analysis and I'm sending You the results below. The PIR indicator didn't go off after the the analysis and it didn't go off after a network stop and restart.
Two faulty PIRs are connected to inputs 1 and 2 of this ODI.
On input 3, there's a rain detector that seems to be working correctly. When I mesured the inputs with a multimeter, they were showing ca. 40 ohm resistance. Short-circuiting the inputs with a wire didn't change the state of the input.
The same problem happens with another ODI in my network.


Here is the analysis result:

Name= 100C Wejścia cyfrowe 3
Version
Master firmware version= 10
Year= 08
Month= 03
Day= 07
Slave firmware version= 00
Variant= 1
Hardware ID= 022
OS Parameters
Max NIDs= 01
NID 01= 100C
Max ZIDs= 02
ZID 01= 00
ZID 02= 00
Max TIDs= 02
TID 01= 12 General Digital input
TID 02= 12 General Digital input
Max NIDMASKs= 00
Min bit rate= 13
Max len bytes-1/max bit rate exp= 01
Receive Buffer Length= 3C
Transmit Buffer Length= 1B
Bit Rate Setting= 2E
Reset status=00
Module (general)
Par#0= 00
Vector 01 (Init)
Addr=FFFF
EX
Par#0= 0B
Par#1= 07
Par#3= 00
Par#4= 14
Vector 01
Addr=FFFF
Vector 02
Addr=FFFF
Vector 03
Addr=FFFF
Vector 04
Addr=FFFF
Vector 05
Addr=FFFF
Vector 06
Addr=FFFF
Vector 07
Addr=FFFF
Vector 08
Addr=FFFF

[Karam]

The node profile would appear to confirm that the module is set up correctly and at the time of the profile both PIRs were closed circuit i.e. as you measured and confirmed by using a wire link to short (though if you measure resistance with module power on and switch 'open' you won't necessarily get correct results because the digital inputs feed current into the switch).

In your first statement you say that the PIR units are NC when not sensing motion but at end of same paragraph you say '...no movement (open contact)'. I'm guessing overall that you do mean that the PIRs are NC output when no motion is sensed as this is the more typical mode of operation. In which case I think the PIR signal Input property should NOT be inverted in the PIR behaviour menu (as Cortex assumes NC operation mode as default). So I suggest you try that first. You should stop the network, clear the invert option in the relevant PIR menus and then restart the network and then perhaps do a walk test and come back and view the logged results. Bear in mind that some sensors are set to have a few seconds dwell period.

In terms of Cortex 'losing messages' I'd be surprised for that to be a 'silent' root cause, in other words without other symptoms also appearing such as Cortex reporting errors with communications with the module or with the PC interface. Communications on the IDRANet bus itself have collision arbitration, are acknowledge based, and data content protected in various ways. A module will automatically retry many times if it does not receive an acknowledge. So the chances of losing even one packet (let alone a few within a few days) on the network itself are very slim indeed and infact not a known root cause to date. Other possibilities such the PC/IDRAnet interface module malfunctioning or Cortex itself, are unlikely not to create pretty visible error reports. But you can never say never in this business so if it doesn't turn out just to be a set up problem we will obviously continue to investigate with you.

[Kevin]

Stachoo ... just wondering did you ever resolve the issue you were having with the ODI inputs ?

Kevin