search

networkupstools / nut

The Network UPS Tools repository. UPS management protocol Informational RFC 9271 published by IETF at https://www.rfc-editor.org/info/rfc9271 Please star NUT on GitHub, this helps with sponsorships!
https://networkupstools.org/
Other
1.87k stars 340 forks source link

VOLT Micro works with blazer_usb but not with nutdrv_qx #2534

Open mwatney-mars opened 1 month ago

mwatney-mars commented 1 month ago

VOLT POLSKA MICRO 1000VA 600W 1x9ah

Using "nutdrv_qx" I get the following output and NO battery percentage when starting the agent:

Using protocol: Mustek 0.07
Can't autodetect number of battery packs [-1/13.20]
Battery runtime will not be calculated (runtimecal not set)

When using "blazer_usb" I get battery percentage and the following message when starting the agent: 

Supported UPS detected with megatec protocol
Vendor information unavailable
No values provided for battery high/low voltages in ups.conf

Using 'guestimation' (low: 10.400000, high: 13.000000)!
Battery runtime will not be calculated (runtimecal not set)

Any plans to add this UPS to the compatibility list anytime soon?

jimklimov commented 1 month ago

Just in case, which NUT release version?

Any plans to add this UPS to the compatibility list anytime soon?

Are you ready to work on making it happen? :)

mwatney-mars commented 1 month ago

Version "2.8.0-7" I guess, checked the package version with "dpkg -l"

Are you ready to work on making it happen?

Of course, how can I help?

jimklimov commented 1 month ago

First of all, gotta find a flag in the sand, marked "Do not approach", and cut a hole in the reactor... :D

On a more serious note, a good first step is to check if the current NUT codebase has not "by chance" already figured out that issue. According to https://github.com/networkupstools/nut/blob/master/NEWS.adoc there were a few changes about battery charge handling in these drivers for NUT releases 2.8.1 and later.

Notes at https://github.com/networkupstools/nut/wiki/Building-NUT-for-in%E2%80%90place-upgrades-or-non%E2%80%90disruptive-tests can help you get the needed prerequisites, build NUT from sources and test the new driver programs (can do right from the build workspace, do not have to overwrite the packaged installation until you like the custom build better).

Still, given that there were a few recent reports like this, about blazer* drivers being better in some regards than nutdrv_qx supposed to replace them eventually (though none from most recent master/releases, IIRC - distros tend to package and ship older versions), there is a chance that your issue is not yet solved. Then it would be needed to get the programmer's hat on and compare the two logical code paths about how the devices initialize, and in particular how they might differ in the early "guesstimation" part, and thanks to the prepared build/test environment - experiment about making those behaviors the same.

mwatney-mars commented 1 month ago

I just upgraded to 2.8.1-3.1 and it behaves exactly the same way, so I think this has to be the hard way