Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix sms-brazil-protocol and sms_ser docs markup; quiesce driver service framework notifications when exiting due to bad CLI args #2796

Merged
merged 5 commits into from
Feb 5, 2025
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
15 changes: 11 additions & 4 deletions NEWS.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -113,6 +113,11 @@ https://github.com/networkupstools/nut/milestone/11
now to report human-friendly text instead of internal enum codes. Follow-up
to [issue #1590, PR #1777, PR #2136]

- drivers should no longer print warning messages about not-initializing the
notification subsystem because not running as a service when they are either
started explicitly to show the help message, or when their CLI arguments
are fatally wrong (no UPS name, no `port`, invalid trailing keywords...)

- drivers, `upsd`, `upsmon`: reduce "scary noise" about failure to `fopen()`
the PID file (which most of the time means that no previous instance of
the daemon was running to potentially conflict with), especially useless
Expand Down Expand Up @@ -273,6 +278,12 @@ https://github.com/networkupstools/nut/milestone/11
* ...should now track the fact of `assumed_LogMax` (typically when firmware
encoding logic is wrong, and `-1` is resolved by parser). [#1512, #1040]

- snmp-ups updates:
* added support to monitor BayTech RPC3-NC PDUs, with `baytech-rpc3nc-mib`
serving same basic data points as were available in `baytech-mib.c`,
but checking for a different model OID subtree and different OIDs for
the device model information. [#2779]

- Introduced a new driver concept for interaction with OS-reported hardware
monitoring readings. Currently instantiated as `hwmon_ina219` specifically
made for Texas Instruments INA219 chip as exposed in the Linux "hwmon"
Expand Down Expand Up @@ -745,10 +756,6 @@ https://github.com/networkupstools/nut/milestone/10
- snmp-ups driver:
* added support for Eaton EMP002 sensor for ATS16 NM2 sub-driver. [#2286]
* mapping table updates for apc-mib sub-driver. [#2264]
* added support to monitor BayTech RPC3-NC PDUs, with `baytech-rpc3nc-mib`
serving same basic data points as were available in `baytech-mib.c`,
but checking for a different model OID subtree and different OIDs for
the device model information. [#2779]

- usbhid-ups driver:
* `arduino-hid` subdriver was enhanced from "initial bare bones" experimental
Expand Down
9 changes: 9 additions & 0 deletions docs/Makefile.am
Original file line number Diff line number Diff line change
Expand Up @@ -123,6 +123,15 @@ EXTRA_DIST += $(ALL_TXT_SRC) $(SHARED_DEPS) $(IMAGE_FILES) \
$(IMAGE_LOGO_FILES) $(IMAGE_LOGO_FILES_JENKINS_NUT) $(CABLES_IMAGES) $(NUT_SPELL_DICT) \
docinfo.xml common.xsl xhtml.xsl chunked.xsl asciidoc.txt asciidoc-vars.conf

# NOTE: ALL_TXT_SRC does not include sms-brazil-protocol.txt because it
# primarily includes samples of configuration files with a lot of Spanish
# (Brazilian) words which confuse the spell-checker. Adding them to common
# NUT_SPELL_DICT would compromise its usefulness for purely English documents.
# FIXME: Add support for custom additional dictionaries for specific document
# files, e.g. "something.txt.dict" if present? There is precedent and code in
# nut-website recipes by now...
EXTRA_DIST += sms-brazil-protocol.txt

ASCIIDOC_HTML_SINGLE = user-manual.html \
developer-guide.html \
packager-guide.html \
Expand Down
7 changes: 4 additions & 3 deletions docs/man/sms_ser.txt
Original file line number Diff line number Diff line change
Expand Up @@ -15,8 +15,8 @@ SYNOPSIS

NOTE: This man page only documents the hardware-specific features
of the sms_ser driver. For information about the core driver, see
linkman:nutupsdrv[8], and for the technical background check in
doc/sms-brazil-protocol.txt.
linkman:nutupsdrv[8], and for the technical background check the
`docs/sms-brazil-protocol.txt` file in NUT sources.

NOTE: Given the proximity of this protocol to Megatec Qx family,
this driver may later become part of `nutdrv_qx` collection.
Expand All @@ -28,7 +28,8 @@ SUPPORTED HARDWARE
sms_ser supports only the "sms 1phase" SMS Product, as described in
the `monofasico.xml` file delivered with the device.

Other SMS protocols for their other products are not supported.
Other SMS protocols (for their other products) are not supported by
this driver.


AUTHOR
Expand Down
9 changes: 7 additions & 2 deletions docs/sms-brazil-protocol.txt
Original file line number Diff line number Diff line change
@@ -1,9 +1,14 @@
SMS Brazil Protocols
====================

Using the PowerView as source, there is a folder, called `protocols` inside the installed directory, e.g. `"C:\Alerta24h\SMS_Power_View\resource"`. There are 4 protocol files (`monofasico.xml`, `trifasico.xml`, `upsilon.xml` and `voltronic.xml`), and one file called `verificaProtocolo.xml`.
Using the PowerView (accompanying UPS application for Windows) as source,
there is a folder, called `protocols` inside the installed directory, e.g.
`"C:\Alerta24h\SMS_Power_View\resource"`. There are 4 protocol files
(`monofasico.xml`, `trifasico.xml`, `upsilon.xml` and `voltronic.xml`),
and one file called `verificaProtocolo.xml`.

The file `verificaProtocolo.xml` has serial/USB commands to be sent, to detect the UPS device.
The file `verificaProtocolo.xml` has serial/USB commands to be sent,
to detect the UPS device.

The file contents are:

Expand Down
13 changes: 12 additions & 1 deletion drivers/main.c
Original file line number Diff line number Diff line change
Expand Up @@ -131,6 +131,7 @@ static int nut_debug_level_protocol = -1;
/* everything else */
static char *pidfn = NULL;
static int help_only = 0,
cli_args_accepted = 0,
dump_data = 0; /* Store the update_count requested */
#endif /* DRIVERS_MAIN_WITHOUT_MAIN */

Expand Down Expand Up @@ -796,7 +797,7 @@ int do_loop_shutdown_commands(const char *sdcmds, char **cmdused) {
"too deeply nested, this seems to be either "
"a NUT programming error or a mis-configuration "
"of your 'sdcommands' setting", NUT_STRARG(upsname));
}
}

if (cmdused) {
if (*cmdused)
Expand Down Expand Up @@ -1833,6 +1834,15 @@ static void exit_cleanup(void)
dstate_setinfo("driver.state", "cleanup.exit");

if (!dump_data && !help_only) {
if (!cli_args_accepted && !getenv("NUT_QUIET_INIT_UPSNOTIFY")) {
/* Default to not yelling about notification method support (or
* lack thereof) when CLI arguments did not get handled early on.
* Set envvar to cause "upsnotify_report_verbosity = 1" in
* common.c::upsnotify() (if still applicable; if already
* reported - oh well).
*/
setenv("NUT_QUIET_INIT_UPSNOTIFY", "yes", 0);
}
upsnotify(NOTIFY_STATE_STOPPING, "exit_cleanup()");
}

Expand Down Expand Up @@ -2333,6 +2343,7 @@ int main(int argc, char **argv)
"Try -h for help.");
}

cli_args_accepted = 1;
assign_debug_level();

new_uid = get_user_pwent(user);
Expand Down