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
Following up to be sure my post didnt get missed.
I tried direct contact to support and waiting on that response.
Please advise,
Thank you
Hello @TFancher Apologies for the delay in my response. To help isolate the issue, could you please test Input 1 (or any other available inputs) to see if the behavior is consistent with what you observed on Input 2?
Additionally, could you provide more details regarding your physical wiring?
what is the approximately total cable length between the sensor and the fire alarm system?
Thanks.
Thank you for your reply Eduardo. I will do some more testing with the other inputs and get back to you with results. Im seeing some weird anomaly that I havent encountered until now and want to verify my findings.
Thank you sir!
I did some more trouble shooting and this is what I found out.
Right now this project is in design/programming stage and is not in production.
I have a PR52-18_CC and the Enterprise Gateway on my bench. I am simulating input changes and states with small clips as I build the Node-Red Flows.
Example screen grab to illustrate my progress and you’ll see how I’m using the inputs of the node:
The issue was that after the node starts up after a power cycle, Input 2 would show as open, when in fact, electrically, its closed. Even after the 1min Heartbeat update, input 2 would never correct itself. Only after a input state change on any input would everything update correctly.
With more testing I discovered that placing a 10k resister on any input, would allow the Node to send the correct state of each input after a reboot. I placed the 10K resistor at input 6 which isnt used right now and in the above image it shows as closed, all other inputs are shown correctly.
Are all of the inputs sharing a common/reference or input-bias? I cant find any electrical specs requiring a load resister for the inputs.
Hi @TFancher Your interface look nice. Thank you for the information, it could be noise. Maybe your wires are too long. We would recommend to use the 10K resistor.
Thanks.
@Eduardo_Mtz Thank you for the comments!
Regarding the wires being too long. That’s just it, I’m not using any long loops right now. Its just two 12in jumpers connected together on each input, to simulate open and close. The Node doesn’t have any issues detecting state changes on the input. Its only after an initial startup, like a reset or reboot. The input bank simply doesn’t know what state any of the inputs are at unless there is a resistive load or termination on at least one of the inputs. It just doesn’t seem like a feature an engineer would employ and not document it. Something like: “Each input should have at least a 10k load to assure proper operation”
IF by chance the Node has internal pull down resistors to overcome this, it isn’t enough. If someone uses this Node and all inputs are Normally open from the start, they won’t have any problems. Me however, have one input that will always start out closed. This is how I discovered this.
This caused me a whole weeks worth of Trouble shooting and hair pulling until I tried a resistive load. It would be beneficial to others if Travis or Bhaskar would look into this for this product.
Thanks again for your input!
Tim
this one had 1M ohm pull down.
for future design i will recommend this one
it can be used as a contact closure.
2 Likes
@Bhaskar Its good to know this can be used for smaller input requirements but since I have worked around the issue with the PR52-18_CC this is the unit Ill be needing. I’ll be ordering 6 More PR52-18_CC to accommodate my project moving forward, and possible 3 more Gateways.
Thank you Sir!
1 Like
@Bhaskar Hello, I am back with a followup on my issue here after realizing that using a resistor as stated above was not the solution after all. Please, can you or another NCD tech confirm the behavior of the PR52-18_CC when it starts up? Is it supposed to return the current state of each input?
Example:
Input 1: Open
Input 2: Closed - Shorted
Input 3: Open
Input 4: Open
Input 5: Open
Input 6: Open
Input 7: Open
Node should send msg payload as:
4/7/2026, 10:59:04 AM[node: Zone Comm Debug]sensor_data : msg.payload : Object
object
input_1: 0
input_2: 1
input_3: 0
input_4: 0
input_5: 0
input_6: 0
input_7: 0
adc_1: 1023
adc_2: 1023
Correct?
This is after a reboot, node in resting state…no input states have changed.
Edit: Removed an unintended url link to my IIoT Gateway.
do you have a few minutes for a zoom call ?
Im sorry Bhaskar, I totally would talk with you but I am Hearing impaired and any kind of call is pretty difficult for me to do. Email is my main method of Direct communication, or the forum here.
No worries. Yes, at boot, it will send the current state value.
Ok, that confirms that my test unit ive been using for developement and testing is not working as intended I think. We purchased it back in April, 2024 along with a gateway.
We have ordered more PR52-18_CC and Ill give one of those a try before requesting to send this current one back for testing and repair.
let me run a test and confrim asap
I can do any testing you want me to do to compare my device output to one of yours if needed.
Thank you sir!
@Bhaskar, Just checking in to see if you had a chance to perform your test and the results.
i am waiting on a unit from production.
I received the 6 new PR52-18 units that we purchased for this project and set one up.
It behaves exactly like the test unit that I have been developing with.
– Not reporting the correct state of the inputs on the first payload sent (just all 0’s)
– Eventually correcting itself when there is at least one state change on an input.
