luci-app-nut: mfr, model fields not valid on usbhid-ups driver

[rpavlik]

Is there an existing issue for this?

• I have searched among all existing issues (including closed issues)

screenshots or captures

Actual behaviour

1. Set "Manufacturer (Display)" or "Model (Display)" to something non-empty
2. Observe that they show up in /var/etc/nut/ups.conf
3. Observe that the nut server will not start because it says mfr or similar is not a valid option

Expected behaviour

If this is used only in LuCI for display, then it shouldn't be templated into the nut config file.

Otherwise, if it's only for some drivers, would be great if it were conditional on the driver type.

(Also it doesn't appear to restart nutserver on change but that's a different problem. Further, restart nutserver is not enough to get it to work again, I have to replug the UPS or reboot)

Steps to reproduce

See "Actual Behavior"

Additional Information

{
	"kernel": "6.6.119",
	"hostname": "bluebell",
	"system": "ARMv8 Processor rev 4",
	"model": "OpenWrt One",
	"board_name": "openwrt,one",
	"rootfs_type": "squashfs",
	"release": {
		"distribution": "OpenWrt",
		"version": "24.10.5",
		"revision": "r29087-d9c5716d1d",
		"target": "mediatek/filogic",
		"description": "OpenWrt 24.10.5 r29087-d9c5716d1d",
		"builddate": "1766005702"
	}
}

What browsers do you see the problem on?

Firefox

Relevant log output

Wed Jan  7 12:09:01 2026 daemon.info usbhid-ups[11516]: Network UPS Tools - Generic HID driver 0.52 (2.8.1)
Wed Jan  7 12:09:01 2026 daemon.info usbhid-ups[11516]: USB communication driver (libusb 1.0) 0.46
Wed Jan  7 12:09:01 2026 daemon.info usbhid-ups[11516]:
Wed Jan  7 12:09:01 2026 daemon.info usbhid-ups[11516]: Fatal error: 'mfr' is not a valid variable name for this driver.
Wed Jan  7 12:09:01 2026 daemon.info usbhid-ups[11516]:
Wed Jan  7 12:09:01 2026 daemon.info usbhid-ups[11516]: Look in the man page or call this driver with -h for a list of
Wed Jan  7 12:09:01 2026 daemon.info usbhid-ups[11516]: valid variable names and flags.


Wed Jan  7 12:09:01 2026 daemon.info usbhid-ups[11516]: Network UPS Tools - Generic HID driver 0.52 (2.8.1)
Wed Jan  7 12:09:01 2026 daemon.info usbhid-ups[11516]: USB communication driver (libusb 1.0) 0.46
Wed Jan  7 12:09:01 2026 daemon.info usbhid-ups[11516]:
Wed Jan  7 12:09:01 2026 daemon.info usbhid-ups[11516]: Fatal error: 'mfr' is not a valid variable name for this driver.
Wed Jan  7 12:09:01 2026 daemon.info usbhid-ups[11516]:
Wed Jan  7 12:09:01 2026 daemon.info usbhid-ups[11516]: Look in the man page or call this driver with -h for a list of
Wed Jan  7 12:09:01 2026 daemon.info usbhid-ups[11516]: valid variable names and flags.

[systemcrash]

OK - thanks for the report. I recommend filing a bug report for nut in its package repo. It needs a procd flag to monitor the config file, so it restarts the daemon if the config changes, although it seems to have that in its init file at present.

OK so usbhid + mfr equals no go?

[rpavlik]

usbhid + mfr, usbhid + model, are both no-go

[danielfdickinson]

FYI mfr is used by genericups https://networkupstools.org/docs/man/genericups.html.

Due the sheer number of drivers, displaying options depending on driver is a daunting task.

Upstream is apparently working on making this easier (some of that may have already landed), so this may be possible to automate in future.

[rpavlik]

ahh, ok. That makes sense, it does seem like a hard problem to generalize. well if nothing else now there is a github issue that people might find.

[systemcrash]

I attempted to make nut a bit smarter, but I think ultimately the best solution is that NUT just ignores parameters that shouldn't be there, especially if the driver doesn't take them. A solution here works, but it's subject to change.

I've send a PR upstream to see if the 'exit on unknown param' can be fixed.

[danielfdickinson]

Apparently each driver now supports:

-L

    Print a parsable list of driver variables. Mostly useful for configuration wizard programs.

Which outputs json with the options and 'type' of the option that the particular driver supports. In theory this could be used to limit what options a user can set for any given driver.

[systemcrash]

It has utility, but it's not very useful when the system is already up and running. It also does not output JSON... :/

[danielfdickinson]

It also does not output JSON

Well that's disappointing. I guess I got mixed up with upsc with now has a json option (though I have to figure out out to enable compiling with json to take advantage of it).

[systemcrash]

Not to worry. IT would be weird to change output formats based on how a binary was compiled instead of via a flag (expectation that output is stable).

[jimklimov]

Speaking of JSON, some changes were made in NUT after 2.8.4 (so now CGI programs and upsc can print it). I suppose drivername -L can be extended similarly (adding say -J) to report this info as a list of JSON tuples rather than whitespace-separated lines magically known to be three columns of some opaque info.

upsc with now has a json option (though I have to figure out out to enable compiling with json to take advantage of it).

It should be just "compiling" (per e.g. https://github.com/networkupstools/nut/wiki/Building-NUT-for-in%E2%80%90place-upgrades-or-non%E2%80%90disruptive-tests) - the JSON output is an ad-hoc series of printf's from the code, no extra libs on NUT side.

Apparently each driver now supports -L...

git blame says "now" began 21 years ago with import from SVN to Git, so practically even before that ;)

[jimklimov]

It has utility, but it's not very useful when the system is already up and running

I think the workflow implied above was:

• user has a new openwrt deployment, or rather a new UPS
• nut-scanner or other magic suggests a driver
• web-UI calls drivername -L to see supported options, uses that to render the web page to edit such options
• known-supported options are saved into ups.conf

[systemcrash]

Well, thanks @jimklimov having the JSON is an improvement, but the GUI portion is configuring a system which is typically already running (it won't run if the params are not accepted, but we'll skip the misconfiguration part). But parsing driver output to know which params are legit is helpful.

So typically (ish)

• user installs
• system auto starts the new daemon
• GUI available if also installed
• user goes to configure
• daemon restarted as a result of new config

[jimklimov]

Also note that drivername -L seems to list options specific to a driver; the standard ones provided by the driver core (port, driver for sanity-check, etc.) are not listed this way, and that set evolves over the years somewhat.

Also there are override.*, default.* etc. magic prefixes that allow drivers to use values they can't get from a device.