Hello,
I am testing a PR52-18_CC for a fire alarm supervisory application, and I believe I have found a startup/heartbeat state reporting issue on the sensor node.
Im building this project with the NCD Enterprise Gateway EG 5120
8-PR52-18_CC Dry contact Sensor Nodes
Node-Red 3.1.15
Use case:
• Input 2 is wired to monitor a normally closed loop in a building fire alarm circuit.
• Normal state = loop closed
• Alarm/trouble state = loop open
Problem observed:
• After the node is power cycled, Input 2 does not report its true closed-loop state correctly.
• On startup and on heartbeat packets, Input 2 reports as 0 even though the loop is physically closed.
• The flow dashboard then shows Input 2 in the wrong state until I physically disturb Input 2.
• Once I open/close Input 2, it begins reporting correctly and subsequent heartbeats continue to show the correct value.
Important additional observation:
• I tested whether activity on another input would force a refresh of Input 2.
• I triggered the test input, but Input 2 still did not correct itself.
• Input 2 only updates to the correct state after Input 2 itself is physically interrupted and restored.
Example debug output:
• After reboot / and heartbeat: (1min intervals)
o input_1: 0
o input_2: 0
o input_3: 0
o input_4: 0
o input_5: 0
o input_6: 0
o input_7: 0
• After physically disturbing Input 2:
o input_2 changes to 1
• Later heartbeats (1 min intervals):
o input_2 remains 1
Why this is a problem for my project:
This is intended for production monitoring of a fire alarm loop and Water supply risers for the building sprinkers. In service, I cannot disturb the physical loop just to force the transmitter to report the correct state. I need the node to report the true state of Input 2 immediately after boot and on heartbeat/status packets without requiring a transition on that input. Ideally, for each node heartbeat sent at one min intervals, Id like to see the true state of every input for true accurate states for this critical project.
Can you advise:
- Whether this is expected behavior or a firmware/configuration issue
- Whether there is a configuration setting that forces a true input-state read on startup
- Whether there is a firmware update that corrects this behavior
Thank you!
Tim F