So I finally switched from my patched 2.7.4 to the official 2.8.0 to notice my
Masterguard UPSen didn't attach any more.
Apart from an USB problem (I'll write another mail on that subject), the
problem turned out that in the qx2nut lookup table, some entries had been
prefixed by "experimental." but that change was missed in the claim
function.
The attached patch corrects that.
-------------- next part --------------
--- drivers/nutdrv_qx_masterguard.c.orig 2022-04-23 13:56:07.000000000 +0200
+++ drivers/nutdrv_qx_masterguard.c 2022-12-21 18:59:02.186441819 +0100
@@ -935,11 +935,11 @@ static int masterguard_claim(void) {
item_t *item;
/* mandatory values */
char *mandatory[] = {
- "series", /* SKIP */
+ "experimental.series", /* SKIP */
"device.model", /* minimal number of battery packs */
"ups.power.nominal", /* load computation */
"ups.id", /* slave address */
- "output_voltages", /* output voltages enum */
+ "experimental.output_voltages", /* output voltages enum */
#if 0
"battery.packs", /* battery voltage computation */
#endif
Edgar Fuß
2022-Dec-21 19:59 UTC
[Nut-upsdev] USB Device match (was: Masterguard/Phoenixtec USB driver)
> Apart from an USB problem (I'll write another mail on that subject)So this is that other mail. I have two identical UPSen connected via USB. Without talking their protocol, they are undistinguishable (when talking the protocol, you can use a "slave address" you may set individually). Back in the libusb0 days, I added a "device" attribute (like the "bus" attribute), but that seems to have gone missing during the libusb1 update. I tried to add it back (see the #if 0 part in the attached patch) using libusb_get_port_number()) but at least on my NetBSD machine, it turned out to be zero for both devices. I resorted to using the loop variable instead (see the #else branch), which made my UPSen work again. Does libusb_get_port_number() return anything useful on other OSes? Comments?