> 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/20230109/8296dd7d/attachment-0001.htm>