Number of Notifications After Initial Does Not Work

[Anonymous user]

Smart-UPS RT 3000 XL

v6.4.0

Last night, I set my emails to trigger every 15 minutes and stop at 5. Woke up to over 600 emails from my different  UPS.

I made a separate  email recipient with just my account and put in to email me every 30 seconds and to only do 1 after the first.

Yet, I still receive emails indefinitely.

[BillP]

Hi Brennon,

Can you share your .tar file as explained here -> http://www.schneider-electric.us/en/faqs/FA156131 I'll double check the configuration and see what I can find.

Or, at a minimum, event.txt and config.ini are what I need.

I was thinking if the battery condition is happening and clearing every minute, it will be a new instance of the alarm rather than a problem with repeating just one original instance. The event log can help me see if that's the case. 

Lastly, if you open one of the emails you got, do you see the event code in there? Something like 0x0119? We need to compare it to the event you've configured because in some applications we have separate event code IDs but the same description (which don't ask me why cause that is not straight forward and obvious). I think way back when, it was because of different types of UPSs supported by each but the descriptions should be different.

[BillP]

Thanks! So these hex codes are how we can look at the events and what I can see in the [EventActionConfig] section of config.ini.

0x0106 pertains to self test failed event. 0x0119 is the UPS: At least one faulty battery exists. event so that is what I expected you to say was in those emails and would align with the emails in your screenshot.

You can also see these in the event.txt you shared:

06/13/2016	14:07:22	Device	UPS: Self-Test Failed	0x0106
06/13/2016	14:07:08	Device	UPS: At least one faulty battery exists.	0x0119

I uploaded your [EventActionConfig] to my NMC to make it easier to read. It does appear that most of the events are currently disabled for all recipients - is that right? Is that the way it was prior or did you make any further modifications since the problem? Seems like earlier today a few hours ago in the event log you did turn off email recipient 3's generation of events. And what recipient was that screenshot of the mailbox for? Definitely the one that starts with bwood as shown in the first screenshot? Did you clear the event log or did the system - just asking because I wanted to verify how many times the "UPS: At least one faulty battery exists." events showed. I only see it once prior to yesterday. I just need to understand the history of when alerts started and when you changed any configuration.

It is feasible an event could get stuck by the event repeater task. Let's assume everything checks out, the events only happened once (both self test failed and at least one faulty batt exists) and your configuration at the time was as you showed in the screenshot for the particular recipient we are looking at. I would've rebooted the network management interface to see if it stopped. I haven't seen this issue before and we have a lot of users with this particular application so if that didn't work then I'd really have to check the configuration again and understand how it was when these emails came through and what has been changed since.

[BillP]

Ohh, OK on the firmware. Agreed, upgrading would've rebooted the management interface. Was the problem happening before then too or just when you got to 6.4.0? And did you notice, is it only with these events we have discussed or all events?

I'll comb over that new config in a little bit and report back as well.

[Anonymous user]

Rebooting seemed to have fixed it. I don't know what caused it to do this.

Everything that I did:

Logged into NCM (To check user/pass)

Logout

Update Firmware via some kind of program that did everything for me, I just put in the IP

Logged into NCM and customized it. 

There were email settings from before my time, that I assumed were overridden if I reapplied the email to all the alerts again. (They had about half of the alerts before, but my boss wanted all but 5 so it would be easier to add the email to all and remove those 5) 

Before the updated firmware, there was no faulty battery alarm, but after I updated it appeared. It also did a self test after the update, which it failed. I don't think this was relevant, but I thought I would include it.

[BillP]

Hi - OK, thanks. If you went from version 5 firmware to version 6, which sounds like that is what happened, your log would've been cleared as well as the event notifications being reset since version 5 and version 6 are pretty different.

An NMC firmware update can't actually trigger a self test so either it detected a new alarm somehow (since I don't see a self test started event in the log) or it as a coincidence that it happened around the update. In your config, you have the self test set to every 14 days. Turning the UPS on also could've caused a self test but a firmware upgrade doesn't turn off or reboot the UPS either. Anyway, don't think it is related.

If you updated before configuring the email, then I wouldn't expect an issue. But if you did it before, I suspect settings for that particular function (specifically frequency, delays, enable/disable for events) would've been wiped and set to defaults which is all events every two minutes until the condition cleared.

I'll get back to you in a bit with that second configand what I see.

[BillP]

Hi Brennon,

I took a look at the config.ini showing your original configuration. With this configuration, I agree that you shouldn't have received all of those emails but I can't see exactly what happened at the time you saw the issue. I am not aware of any known issues or bugs that would've caused this either. As I mentioned earlier, it is possible the event repeater task got stuck which I've seen in an isolated case but a reboot took care of it. Nothing similar reported on v6.4.0 by other users.

If you have the configuration set like this again and see the issue again, I'd recommend you grab the .tar file and then go ahead and disable the emails if you need to so I have that .tar while the issue is actively occurring. The .tar file has a few extra debug files in there that will be useful depending on what is in the event log if it does happen again. I didn't see anything in your most recent event log that would indicate extra info available in the debug file.

Let me know if you have any other questions on my comments. I wish I could see something obvious but I don't. The config.ini for the events we've discussed in the original config you provided look OK.

[Anonymous user]

Thanks for your help! 

[BillP · Accepted solution]

You're welcome!