[Nut-upsdev] Prolink UPS NUT driver

[Jim Klimov]

Also, regarding current NUT on CentOS 6: I was curious, so confirmed this
is possible (can build and pass programmatic self-tests, did not try it
against hardware devices), although it did need a little chiseling around
some rough edges.

Details posted in PR https://github.com/networkupstools/nut/pull/1804 which
will be merged into the "master" branch when no other CI farm systems
complain about the proposed change.

Hope this helps,
Jim Klimov


On Mon, Jan 9, 2023 at 9:53 AM Jim Klimov <jimklimov+nut at gmail.com> wrote:

> > Previously, the manufacturer tested this UPS on version 2.6.5-6 NUT for
> Windows.
>
> Thanks for this important detail.
>
> For immediate re-testing, I would recommend to use either NUT v2.8.0
> already packaged by some distributions in their testing/bleeding-edge
> repositories (unfortunately, during the almost year since release many
> distros - especially for LTS versions - did not change recipes to bump up
> from 2.7.4), or better yet to build from
> https://github.com/networkupstools/nut/ sources on a POSIX platform
> (Linux, MacOS, *BSD, Solaris/illumos, etc.) which they would be more
> comfortable with - to take advantage from recent bug fixes and
> improvements, including some that impacted USB drivers and drivers talking
> the Megatec Qx (numbered "x") family of protocols (which includes older
> blazer drivers and newer nutdrv_qx with its many subdrivers).
>
> For your target deployment, ensuring a build on CentOS 6 makes sense and
> might be or not be an adventure of its own. For preparing a build
> environment, CentOS chapter in
> https://github.com/networkupstools/nut/blob/master/docs/config-prereqs.txt
> and general container setup notes in
> https://github.com/networkupstools/nut/blob/master/docs/ci-farm-lxc-setup.txt
> might help. Also maybe an older discussion on builds for the platform
> https://alioth-lists.debian.net/pipermail/nut-upsdev/2015-March/006922.html
> would inspire new work...
>
> In any case, old NUT releases are "set in stone" so further fixes (if
> needed) can only be made over the master branch, which is a moving target
> and snapshots of which eventually become releases - and that fixing would
> need confirmation the problems are in fact there today (and a way to check
> that a fix solves them).
>
> *** For more context about NUT for Windows builds ***
>
> NUT for Windows was a side-branch project; the latest release of which
> (tagged 2.6.5-6 in codebase) was in 2014, and then it was not addressed at
> all. I am not certain at the moment if the published MSI installers were
> from this revision or some even older code.
>
> During the last year (after NUT v2.8.0 release) the differences of that
> branch compared to its contemporary NUT codebase (late 2.6 - early 2.7)
> were analyzed to bring back Windows build-ability and make it part of NUT
> "master" branch, to allow further developers to complete and test this code
> (AFAIK nobody stepped up yet, although there were some promising
> exploratory discussions), and to pass CI builds for at least non-regression
> of current achievements.
>
> However this effort is not fully finished - in particular, the installer
> was not addressed (which I suppose allows libusb driver hooks to be added
> to the OS at high enough privilege level to actually capture USB device
> data, not only see their identification). Also, libusb0 (used before NUT
> 2.8.0) effectively died off, and libusb1 changes were I think the networked
> drivers (SNMP, NetXML) and possibly Serial-port drivers should work
> however. There are also some functional codebase differences, including a
> few methods that were not converted from POSIX to WIN32 coding and are just
> place-holders, but this should only impact a certain small subset of
> programs.
>
> Recent CI results and binary artifacts can be seen in
> https://ci.appveyor.com/project/nut-travis/nut/history (look for a top
> entry that says only "master <> commit-id" for shared codebase iterations
> based on merged pull-requests, and the Artifacts tab there - e.g.
> https://ci.appveyor.com/project/nut-travis/nut/builds/45872949/artifacts
> for latest build as of today). I think the persistent latest-build link is
> https://ci.appveyor.com/project/nut-travis/nut/build/artifacts but may
> show PRs as well. These archives are just tarballs of the build's `make
> install` proto area including third-party FOSS DLLs, which help in testing
> when unpacked but are not currently a "proper" Windows package installer.
>
> Helpful links:
>
> * https://github.com/networkupstools/nut/labels/Windows - all issues and
> PRs tagged for this subject
> * https://github.com/orgs/networkupstools/projects/2 - tracking what was
> done and what remains to do in NUT for Windows effort
> * https://github.com/networkupstools/nut/issues/5 details much of that
> work as it progressed
> * https://github.com/networkupstools/nut/issues/1690 contains some
> analysis for libusb installation to the OS
>
> Hope this helps,
> Jim Klimov
>
>
> On Mon, Jan 9, 2023 at 8:04 AM Alexander <ak at enfall.com> wrote:
>
>> Hello Jim,
>>
>> Thank you for your feedback,
>>
>> [Jim]: *did you have a chance to test those devices with current NUT
>> master branch from Github (some time last year, preferably after 2.8.0
>> release in April)?*
>>
>> [Alexander]:
>>
>> Now we don't have UPS samples on hands, we will ask the manufacturer to
>> try testing NUT 2.8.0.
>>
>> Previously, the manufacturer tested this UPS on version 2.6.5-6 NUT for
>> Windows.
>> Could you suggest the correct link to download NUT v2.8.0 for Windows?
>>
>> Best regards
>>
>> Alexander Kirillov
>>
>> company Enfall
>>
>> mobile: +7 904 333 38 86 (WhatsApp, Telegram)
>>
>> e-mail: ak at enfall.com
>>
>> ENFALL
>>
>> energy for all
>>
>>
>>
>> *УВЕДОМЛЕНИЕ О КОНФИДЕНЦИАЛЬНОСТИ:*
>>
>> *Это электронное сообщение и любые документы, приложенные к нему,
>> содержат конфиденциальную информацию. Настоящим уведомляем Вас о том, что
>> если это сообщение не предназначено Вам, использование, копирование,
>> распространение информации, содержащейся в настоящем сообщении, а также
>> осуществление любых действий на основе этой информации, строго запрещено.
>> Если Вы получили это сообщение по ошибке, пожалуйста, сообщите об этом
>> отправителю по электронной почте и удалите это сообщение. *
>>
>> *CONFIDENTIALITY NOTICE:** This email and any files attached to it are
>> confidential. If you are not the intended recipient you are notified that
>> using, copying, distributing or taking any action in reliance on the
>> contents of this information is strictly prohibited. If you have received
>> this email in error please notify the sender and delete this email. *
>>
>>
>>
>>
>>
>>
>>
>> *From:* Jim Klimov [mailto:jimklimov+nut at gmail.com]
>> *Sent:* Sunday, January 8, 2023 4:43 AM
>> *To:* Alexander <ak at enfall.com>
>> *Cc:* nut-upsdev <nut-upsdev at alioth-lists.debian.net>; Pavel <
>> pp at enfall.com>
>> *Subject:* Re: [Nut-upsdev] Prolink UPS NUT driver
>>
>>
>>
>> Hello all,
>>
>>
>>
>>   I really hope somebody picks up this bounty :)
>>
>>
>>
>>   Going forward, however, nutdrv_qx driver should be evolved via new
>> subdrivers (and used) rather than older Qx drivers like blazer.
>>
>>
>>
>> @Alexander : did you have a chance to test those devices with current NUT
>> master branch from Github (some time last year, preferably after 2.8.0
>> release in April)?
>>
>>
>>
>>   If tests were done earlier with packaged NUT version, I suppose it
>> would be 2.7.4 or older. If they used whatever CentOS 6 packaged, it could
>> be even more antique (2.6.5?). As a community, we can only support and
>> patch current NUT codebase, not directly old releases, but it is mostly
>> evolution so what worked years before should not be worse now :)
>>
>>
>>
>>   I *guess* current NUT might just build on CentOS 6, but CI farm
>> regularly only tests CentOS 7 as an example old platform (and recently
>> Solaris 8 buildability was revived), so there may be some chizeling needed
>> or not for builds there.
>>
>>
>>
>> On Sun, Jan 8, 2023, 00:39 Alexander <ak at enfall.com> wrote:
>>
>> Hello NUT developers,
>>
>> Happy New Year!
>> We sent a similar request to the mailing list earlier in 2022, hope
>> somebody can be interested now and help us with the issue described below.
>> Of course, we are ready to reward for such help, if you have the
>> opportunity to solve the problem, please let us know the price of the
>> solution. Feel free to email us directly at ak at enfall.com.
>>
>>
>>
>> The manufacturer Prolink has an 650VA UPS model. To supply this UPS to
>> the customer, we should first ensure the compatibility of this UPS model
>> with the NUT monitoring system.
>> The customer’s NUT monitoring system works on CentOS 6.
>>
>> At the moment, information has been received from the manufacturer about
>> NUT monitoring support, but only partially support (not all necessary data
>> can be obtained from this UPS).
>>
>> Below is a list of data that needs to be obtained from 650VA UPS from
>> Prolink using NUT. Commands that according to Prolink are currently not
>> supported are indicated below:
>> 1)     UPS status (ups.status)  --》OK
>>
>> 2)     Battery charge level (battery.charge)--- >> Only support battery
>> voltage.
>>
>> 3)     Expected battery life (battery.runtime)---》not support
>>
>> 4)     Input line parameters (input.voltage)---》OK
>>
>> 5)     UPS model (ups.model)- 》OK
>>
>> 6)     Current UPS load (ups. load)- 》OK
>>
>> 7)     The UPS shall transmit to the NUT driver the resulting Runtime
>> value calculated from UPS controller side (without calculation from the
>> driver side)- 》not support
>>
>>
>>
>> Prolink claims that to fully support NUT, the NUT driver “blaser_usb” for
>> 650VA UPS needs to be improved, so we are asking you for help.
>>
>> 1. Please clarify whether it is technically possible to modify the
>> existing driver for the 650VA Prolink UPS and provide the ability to
>> transfer all data from this UPS to NUT in accordance with the list above?
>>
>> 2. In what time frame is it possible to modify the driver?
>>
>> 3. How much does it cost to upgrade the driver?
>>
>> 4. What information and materials do you need to improve the driver for
>> the Apex800, besides the protocol from Prolink? We are ready to provide and
>> receive everything needed from the manufacturer.
>>
>>
>>
>>
>>
>> Best regards
>>
>> Alexander Kirillov
>>
>> company Enfall
>>
>> mobile: +7 904 333 38 86 (WhatsApp, Telegram)
>>
>> e-mail: ak at enfall.com
>>
>> ENFALL
>>
>> energy for all
>>
>>
>>
>> *CONFIDENTIALITY NOTICE:** This email and any files attached to it are
>> confidential. If you are not the intended recipient you are notified that
>> using, copying, distributing or taking any action in reliance on the
>> contents of this information is strictly prohibited. If you have received
>> this email in error please notify the sender and delete this email. *
>>
>>
>>
>> _______________________________________________
>> Nut-upsdev mailing list
>> Nut-upsdev at alioth-lists.debian.net
>> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/nut-upsdev/attachments/20230112/1b400c70/attachment-0001.htm>