[Nut-upsdev] Openups patch proposal

[Alphonse]

Hello,
I have an openups2 ups. It works very well with nut, except two things:
1) It keeps sending a 'libusb_get_string: invalid argument' message to
the log;
2) It does not report any command.

Following
http://nut-upsdev.alioth.debian.narkive.com/bmJyFFkO/libusb-get-string-invalid-argument,
I was able to fix the error message using the attached patch.

I do not know how ot fix the second point, but it is not really
important (it could be convenient).
Regards,
Alphonse.

[Charles Lepple]

Post by Alphonse
Hello,
1) It keeps sending a 'libusb_get_string: invalid argument' message to the log;
2) It does not report any command.
Following http://nut-upsdev.alioth.debian.narkive.com/bmJyFFkO/libusb-get-string-invalid-argument, I was able to fix the error message using the attached patch.

Thanks for the patch. For reference, what does the rest of the "upsc" output look like for this device?

Post by Alphonse
I do not know how ot fix the second point, but it is not really important (it could be convenient).

I don't think that the firmware supported commands when this sub-driver was written. It is certainly something we can check for, using the "explore" mode mentioned in the driver man page: http://networkupstools.org/docs/man/usbhid-ups.html (please stop after 30-60 seconds, and gzip the output)

[Alphonse]

Post by Charles Lepple
Thanks for the patch. For reference, what does the rest of the "upsc"
output look like for this device?

Here it is:

$ upsc openups2
Init SSL without certificate database
battery.capacity: 100
battery.charge: 100
battery.charge.low: 5
battery.charge.warning: 20
battery.current: 0.000
battery.mfr.date:
battery.runtime: 3932100
battery.temperature: 36.79
battery.type:
battery.voltage: 10.13
device.mfr: Mini-Box.Com
device.model: OPEN-UPS2
device.serial: LI-ION
device.type: ups
driver.flag.maxreport: enabled
driver.name: usbhid-ups
driver.parameter.pollfreq: 30
driver.parameter.pollinterval: 2
driver.parameter.port: auto
driver.parameter.productid: d005
driver.parameter.synchronous: no
driver.parameter.vendorid: 04d8
driver.version: 2.7.4
driver.version.data: openUPS HID 0.4
driver.version.internal: 0.41
input.current: 0.000
input.voltage: 12.08
output.current: 0.000
output.voltage: 12.04
ups.mfr: Mini-Box.Com
ups.model: OPEN-UPS2
ups.productid: d005
ups.serial: LI-ION
ups.status: OL
ups.vendorid: 04d8


Note that there is still a 'libusb_get_string: Invalid argument' message
into the log, but only when starting or resuming the system.

Post by Charles Lepple
I don't think that the firmware supported commands when this sub-driver was written. It is certainly something we can check for, using the "explore" mode mentioned in the driver man page: http://networkupstools.org/docs/man/usbhid-ups.html (please stop after 30-60 seconds, and gzip the output)

I'll try that as soon as possible.
Thanks for your consideration,
Alphonse.

[Charles Lepple]

Note that there is still a 'libusb_get_string: Invalid argument' message into the log, but only when starting or resuming the system.

I should mention that this is now in the master branch as commit e6d77c87d0b0

I added an issue to address the fact that we shouldn't ever retrieve String ID 0: https://github.com/networkupstools/nut/issues/454 (I might want to get your help testing a patch for that, when I get some extra time to test on other devices here.)

[Alphonse]

Post by Charles Lepple
I don't think that the firmware supported commands when this sub-driver was written. It is certainly something we can check for, using the "explore" mode mentioned in the driver man page: http://networkupstools.org/docs/man/usbhid-ups.html (please stop after 30-60 seconds, and gzip the output)

This is weird (for me): I have added the 'explore' option into the ups
configuration, and restarted the driver, but now it tells that the
device is offline! It is back to normal without this option.
I have attached the requested log.

[Charles Lepple]

This is weird (for me): I have added the 'explore' option into the ups configuration, and restarted the driver, but now it tells that the device is offline! It is back to normal without this option.
I have attached the requested log.

Right, I forgot to mention that the explore mode is not meant to send data to upsd - it just generates debug output.

There are a few extra variables that might be read/write, but I don't see the usual ones that translate into commands (such as UPS.BatterySystem.Battery.Test or UPS.PowerSummary.DelayBeforeShutdown).

Thanks for sending the upsc output.

[Alphonse]

Post by Charles Lepple
Right, I forgot to mention that the explore mode is not meant to send data to upsd - it just generates debug output.

And it is written in the man page... that I do had read!

Post by Charles Lepple
There are a few extra variables that might be read/write, but I don't see the usual ones that translate into commands (such as UPS.BatterySystem.Battery.Test or UPS.PowerSummary.DelayBeforeShutdown).
Thanks for sending the upsc output.

Another point is bugging me: the ups is not repported as a battery in
kde nor in the output of 'solid-hardware list'.
Do you have an idea for this problem?
Thanks!

[Charles Lepple]

Another point is bugging me: the ups is not repported as a battery in kde nor in the output of 'solid-hardware list'.
Do you have an idea for this problem?
Thanks!

To be honest, most of the NUT development effort is focused on shutting down servers, so there isn't a whole lot of work on the desktop side. Having not used KDE in many years, I hadn't heard of Solid.

For anyone else casually interested, this seems to be a good introduction: http://shubham.chaudhary.xyz/blog/2013/11/09/kde-solid-namespace/

And this bug seems to show that "solid-hardware list" is talking to UPower for battery information: https://lists.debian.org/debian-qt-kde/2015/03/msg00554.html

Before UPower came along, we had a version of usbhid-ups which was a bridge between the UPS and DeviceKit Power. It was, unfortunately, an either-or proposition: you could have the UPS show up in the GUI, or you could have the traditional NUT upsmon/upsd/driver stack, and all of the network connectivity of the latter. That bridge code no longer exists.

However someone could probably write a NUT client that does something similar: connect to a running upsd, and publish UPS information via DBus. I am not volunteering, but it does sound like an interesting idea.

In the near term, you might consider KNutClient <http://knut.prynych.cz> or NUT-Monitor <http://www.lestat.st/en/informatique/projets/nut-monitor>.

[Alphonse]

Post by Charles Lepple
To be honest, most of the NUT development effort is focused on
shutting down servers, so there isn't a whole lot of work on the
desktop side. Having not used KDE in many years, I hadn't heard of Solid.
For anyone else casually interested, this seems to be a good introduction: http://shubham.chaudhary.xyz/blog/2013/11/09/kde-solid-namespace/
And this bug seems to show that "solid-hardware list" is talking to UPower for battery information: https://lists.debian.org/debian-qt-kde/2015/03/msg00554.html
Before UPower came along, we had a version of usbhid-ups which was a bridge between the UPS and DeviceKit Power. It was, unfortunately, an either-or proposition: you could have the UPS show up in the GUI, or you could have the traditional NUT upsmon/upsd/driver stack, and all of the network connectivity of the latter. That bridge code no longer exists.
However someone could probably write a NUT client that does something similar: connect to a running upsd, and publish UPS information via DBus. I am not volunteering, but it does sound like an interesting idea.
In the near term, you might consider KNutClient <http://knut.prynych.cz> or NUT-Monitor <http://www.lestat.st/en/informatique/projets/nut-monitor>.

Thanks for the informations! Actually, I have written a script using
upsc to monitor the ups and handle the important events, but it should
be simpler to use some desktop interface. I hope someone will volunteer
for that; it is beyond my competences.

Anyway, I'd be happy to help by testing patches.