On Jun 27, 2017, at 9:23 AM, Andrea de Lutti <adelutti at gmail.com> wrote:> > Sorry, I didn't received it...You should be subscribed to the list now.> I don't have any REPLBATT messageRight, you would only get REPLBATT messages when the UPS reports that the battery *needs to be replaced* (and then at regular intervals per the upsmon.conf parameters).> , but when in battery test I have OL CAL status: it would be good to have the result."OL CAL" or "OB CAL"? If the UPS is powering the load from the battery during calibration, it should report "OB CAL". The ONBATT handler in NOTIFYCMD can check for CAL at that point. I don't think we considered the case where CAL is paired with OL.> Anyway I still not receive any email on any test (power cord disconnected and/or reconnected for example)Oh, I misinterpreted "working script" as a script that was sending email, rather than work-in-progress. Does that same command work from the command line? Can you add something like "logger" before the mailx line to be sure that the script is executing properly? Be sure to "chmod a+x" the script. I forget if I mentioned this earlier, but for testing notifications, you can use the dummy-ups driver: http://networkupstools.org/docs/man/dummy-ups.html The timer example will simulate the OL-OB-LB transition.> Does the runtime calibration test alter the values of ups.conf? Or do I have to change it manually? Which would be the right procedure for changing the battery for calibrating NUT (over the manufacturer's suggestions)?The automatic calibration/battery test invoked by upscmd (or the UPS front panel button, if any) is for the UPS low battery warning. The manual calibration ups.conf parameters are necessary (and need to be maintained separately) because Qx-based protocols do not all report the state-of-charge as calculated by the UPS. I would recommend both forms of calibration after replacing the battery.> _______________________________________________ > Nut-upsuser mailing list > Nut-upsuser at lists.alioth.debian.org > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
> > , but when in battery test I have OL CAL status: it would be good to > have the result. > > "OL CAL" or "OB CAL"? If the UPS is powering the load from the battery > during calibration, it should report "OB CAL". The ONBATT handler in > NOTIFYCMD can check for CAL at that point. > > I don't think we considered the case where CAL is paired with OL. > > ?I confirm it, during battery testing I have OL CAL?> > Anyway I still not receive any email on any test (power cord > disconnected and/or reconnected for example) > > Oh, I misinterpreted "working script" as a script that was sending email, > rather than work-in-progress. Does that same command work from the command > line? Can you add something like "logger" before the mailx line to be sure > that the script is executing properly? Be sure to "chmod a+x" the script. >?Yep, the script works flawlessy with a command line. It is a "modified" script from other jobs, and I receive daily all the emails from them?> > I forget if I mentioned this earlier, but for testing notifications, you > can use the dummy-ups driver: > > http://networkupstools.org/docs/man/dummy-ups.html > > The timer example will simulate the OL-OB-LB transition. >?Maybe I have missing someting. I have exported my configuration to a .dev file, and then used for dummy ups, configured as dummy. Do i need to make circular tests (timer configuration) or may I do them manually? Just beacuse the only command allowed in dummy mode (upscmd -l dummy at artu) is load.off> > Does the runtime calibration test alter the values of ups.conf? Or do I > have to change it manually? Which would be the right procedure for changing > the battery for calibrating NUT (over the manufacturer's suggestions)? > > The automatic calibration/battery test invoked by upscmd (or the UPS front > panel button, if any) is for the UPS low battery warning. > > The manual calibration ups.conf parameters are necessary (and need to be > maintained separately) because Qx-based protocols do not all report the > state-of-charge as calculated by the UPS. > > I would recommend both forms of calibration after replacing the battery. > > ?Ok, thanks. I will replace the battery and test it?-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20170629/edc5e527/attachment.html>
On Jun 29, 2017, at 6:52 AM, Andrea de Lutti wrote:>>> Anyway I still not receive any email on any test (power cord disconnected and/or reconnected for example) >> >> Oh, I misinterpreted "working script" as a script that was sending email, rather than work-in-progress. Does that same command work from the command line? Can you add something like "logger" before the mailx line to be sure that the script is executing properly? Be sure to "chmod a+x" the script. >> > ?Yep, the script works flawlessy with a command line. It is a "modified" script from other jobs, and I receive daily all the emails from them?Bear in mind that upsmon runs as user "nut" on Ubuntu, as does the NOTIFYCMD script. At one point, you said that the script is in /root, which is not commonly readable by other users. Does the script work if you move it to, say, /usr/local/bin? (With Ubuntu 16.04, there should be some error messages from upsmon in 'journalctl' referencing permissions.)>> >> I forget if I mentioned this earlier, but for testing notifications, you can use the dummy-ups driver: >> >> http://networkupstools.org/docs/man/dummy-ups.html >> >> The timer example will simulate the OL-OB-LB transition. >> > ?Maybe I have missing someting. I have exported my configuration to a .dev file, and then used for dummy ups, configured as dummy. Do i need to make circular tests (timer configuration) or may I do them manually? Just beacuse the only command allowed in dummy mode (upscmd -l dummy at artu) is load.off >Under the Bugs heading, the man page says "Instant commands are not yet supported in Dummy Mode..." - one of the use cases was automated developer testing of NUT, and there isn't much use in simulating all of the commands in that case. "load.off" is probably worth implementing at some point for user testing. So for your use case, the timers would probably be the easiest way with the current code.