This question was originally posted on DCIM Support by Raza Khan on 2017-11-07
I have installed a leak-rope sensor at my client's data center, where we integrated a hooter/siren with its relay. To sound the alarm on leak-rope alert.
Everything done perfectly & its working, but now I got an issue:
The leak-rope's alert shows for about 30 minutes, even after wiping the rope dry it won't disappear.
Since we have attached a hooter with this sensor, it has become so annoying with powerful sound making noise for 30 minutes.
is there any way we can limit the alerts for 5-10 minutes or less ?
if not, then is there any documentation from APC which I can provide to my client & close this issue ?
Please urgent help required,
Thanks in advance
M. Raza Khan
Solved! Go to Solution.
This answer was originally posted on DCIM Support by Steven Marchetti on 2017-11-07
Even if you wipe the cable dry on the outside, the moisture can remain inside the cable for some time (as you've seen). There's little that can be done other than totally drying the cable. It works simply as if there is conductivity, the appliance will show leak. If you need to have the cable dry, perhaps using a hair dryer or something like that.
On the alert side of things, the only thing I can suggest is turning off the alarm action for the extra 1/2 an hour, changing state of the relay (assuming it's using the relay output), or disconnect the buzzer.
This comment was originally posted on DCIM Support by Raza Khan on 2017-11-13
Thanks for your response.
Your answer is somehow acceptable but still my client wants to know why it takes exactly 30 minutes to clear the alert from DCE window, he says that the same leak-rope sensor takes around 4-5 minutes to clear on a different server (other than APC).
I have suggested them to disconnect & reconnect the sensor cable to clear the alert when someone reached to rectify the issue.
If this 30 minutes duration setting is "hardware default" & cannot be altered, could you please provide any document that I can show to my client & satisfy them ?
its actually needed to close this issue which is pending from about 6 months.
M. Raza Khan
This comment was originally posted on DCIM Support by Steven Marchetti on 2017-11-13
You mentioned the time to clear the event however you never mentioned this was the time to clear in DCE. I assumed with the information provided that it was just the device itself. Since it was the "hooter" that was hooked up to the device, I was assuming it was that device that was in question.
Now you state:
he says that the same leak-rope sensor takes around 4-5 minutes to clear on a different server (other than APC).
Please explain. Are you polling the device using SNMP? Is the event actually clearing on the device but NOT in DCE? To what "different server" are you referring? Is it an SNMP server monitoring the device or is it another device that the sensor is connected to and not the NetBotz (I'm assuming it's a 570 as you seemed to switch the numbers around calling it a 750)?
This comment was originally posted on DCIM Support by Raza Khan on 2017-11-15
Well yes I guess I've created some confusions here, let me rephrase my question:
I have a perfectly working NetBotz Rack Monitor 570 (earlier wrote 750 by mistake).
I have attached a hooter (12V DC with external power). It will activate when it gets a signal from Relay 1 at NC-COM dry ports.
So far, everything's working fine.
when we tested it by pouring some water on leak-rope, it generated an error in DCE, & which triggered Relay-1 in NetBotz & activated the hooter.
Now the problem we're facing, it (hooter) won't shutup untill the alert disappears from DCE screen.
If I pull out RJ45 connector from leak-rope, it clears the alert from DCE & hooter gets quite.
My client want the "alert" to disappear after 4-5 minutes & must not take 30 minutes. And no manual reset is allowed by them.
Hope you get a clear picture now.
M. Raza Khan
This comment was originally posted on DCIM Support by Steven Marchetti on 2017-11-15
What shows on DCE should make no difference. What should make a difference is if it still shows on the NetBotz appliance itself. I'd suggest looking at advanced view.
If you have created an action where the relay will change state such as follows:
Then while the event is still showing, the alarm will continue. This is by design. Again, wiping the cable may not cause the conductivity that causes the alarm to stop the current, turning off the alarm.
If it never turns off, make sure the threshold does not have this user input requirement set on the advanced page:
Also verify if there is a return to normal delay on this same page. Make sure there is only 1 threshold for this leak sensor so you don't have multiple thresholds to check and configure.
What version of Botzware is on the appliance?
Just to be sure, I have just finished testing this on a 450 running 4.6.1 botzware.
I had never seen this before but I am now able to replicate on the up to date firmware. Even stranger, when I look at the alert details, I see what appears to be a continuation of the event every 5 minutes:
Additionally, I never caused a leak. I only shorted out two of the pins at the end of the cable.
If you want to try some older firmware you can and as I mentioned, it may be something brought in on a newer revision but it appears to be a bug and I'll have to put it in the system. I can't say when it may be addressed.
This answer was originally posted on DCIM Support by Raza Khan on 2017-11-22
So, I've rechecked the things you asked for, everything is fine.
no "Return to normal" option checked.
not more than one threshold created for this alert. etc.
And if I sum up this conversation, what you're saying is that this 30 minutes delay is system default & we cannot change this. Unless we manually disconnect the leak-rope to clear the alert.
Could you provide any APC document saying that this duration is by default & cannot be changed, it is required by my client to close this issue.
i'll also speak with them & invite into this conversation.
M. Raza Khan
This answer was originally posted on DCIM Support by Steven Marchetti on 2017-11-22
there re is no documentation stating this is the default and I believe it should not be this way. I have however put in a bug report and hopefully this can be corrected in a future revision. If they decide it is normal behavior however, the only documentation stating this will be a knowledge base document we would create after this is decided.
Discuss challenges and get support in energy and automation with 30,000+ experts and peers.
Over 10,000+ support articles are available to help you find answers to your product and business challenges.
Find peer based solutions to your questions. Provide answers for fellow community members!