[Nut-upsuser] Info for decoding report from UPS

[Jim Klimov]

One tool for one job :)

You can have another protocol client with GUI. NUT includes a python (qt5
or gtk) set of UI clients.

On Thu, Sep 14, 2023, 17:06 Alessandro Mandelli <mandelli.alessandro at ngi.it>
wrote:

> It works, but I got an allergy for CLI
>
>
>
> PS C:\Program Files (x86)\NUT\bin> .\upsc.exe UPS
>
> device.mfr: Richcomm dry-contact to USB solution
>
> device.model: UPS USB MON V1.4
>
> device.serial: unknown
>
> device.type: ups
>
> driver.debug: 0
>
> driver.flag.allow_killpower: 0
>
> driver.name: richcomm_usb
>
> driver.parameter.pollinterval: 2
>
> driver.parameter.port: auto
>
> driver.parameter.synchronous: auto
>
> driver.state: quiet
>
> driver.version: 2.8.0-2350-g9c6b22e61
>
> driver.version.internal: 0.12
>
> ups.mfr: Richcomm dry-contact to USB solution
>
> ups.model: UPS USB MON V1.4
>
> ups.productid: 1234
>
> ups.serial: unknown
>
> ups.status: OL
>
> ups.vendorid: 0925
>
>
>
>
>
>
>
>
>
> *Da:* Jim Klimov <jimklimov+nut at gmail.com>
> *Inviato:* giovedì 14 settembre 2023 15:21
> *A:* Alessandro Mandelli <mandelli.alessandro at ngi.it>
> *Cc:* Arnaud Quette via Nut-upsuser <nut-upsuser at alioth-lists.debian.net>
> *Oggetto:* Re: [Nut-upsuser] Info for decoding report from UPS
>
>
>
> Ah, I see. My take is that using or adapting something that exists is
> easier than starting from scratch - but to each their own. Surely you'll
> learn a lot :)
>
> Still, just to clarify: after the NUT v2.8.0 release I began a slow
> revival of old NUT for Windows effort (abandoned a decade ago at 2.6.5-8
> based branch), so now there are regular native win64 (CLI) builds regularly
> produced by CI, as a tarball of a result of `make install` area (plus the
> dependency DLLs). They can run in-place and do work for testing NUT
> behaviors on the platform, but are not "properly packaged" yet, have no
> installer, and indeed may need fiddling with USB libraries in particular
> (so that Windows "HID Battery" driver won't get in the way and would let
> libusb handle that node for NUT), but still sounds easier to give this a
> shot before constructing something new. This OS integration bit may have
> worked in that older 2.6.5 codebase, just I had no time to look hard at
> this recently, and nobody else stepped up either. PRs to complete this part
> are welcome, so fiddling would not be needed ;)
>
>
>
> Quoting from a recent post:
>
> For kicks, you can try starting different drivers from a NUT for Windows
> build - I'd be interested to know if it actually picks up a serial port
> device (with nutdrv_qx as a  first stop, to test for Megatec Qx protocol
> family). Getting USB handled directly may be quite a hassle currently
> (without a proper elevated installer), but may be doable too:
> https://github.com/networkupstools/nut/issues/1690#issuecomment-1455206002
>
>
>
> Can try a pre-built tarball from CI https://ci.appveyor
> .com/project/nut-travis/nut/history
>
> e.g. for currently-latest master-branch build: https://ci.appveyor
> .com/project/nut-travis/nut/builds/48009107/artifacts => https://ci.
> appveyor
> .com/api/buildjobs/kn42sp8aek4md9va/artifacts/NUT-for-Windows-x86_64-SNAPSHOT-2.8.0.725-master.7z
>
>
>
> Good luck,
>
> Jim
>
>
>
>
>
>
>
> On Thu, Sep 14, 2023 at 2:31 PM Alessandro Mandelli <
> mandelli.alessandro at ngi.it> wrote:
>
> Yeah, existing packages and libraries don’t work for me, introduce
> overhead and require fiddling well beyond the capabilities of a standard
> user.
>
> I’d like a native win64 app.
>
> Anyway, thanks for your help
>
>
>
>
>
> *Da:* Jim Klimov <jimklimov+nut at gmail.com>
> *Inviato:* giovedì 14 settembre 2023 13:17
> *A:* Alessandro Mandelli <mandelli.alessandro at ngi.it>
> *Cc:* Arnaud Quette via Nut-upsuser <nut-upsuser at alioth-lists.debian.net>
> *Oggetto:* Re: [Nut-upsuser] Info for decoding report from UPS
>
>
>
> So, do you plan to write some new program for that UPS instead of trying
> to use NUT? (Note there are also regular Windows builds on CI - with some
> caveats so far).
>
>
>
> I'm commuting now so can't find links easily, but can suggest you to
> peruse the issue/PR tracker, there's a discussion about an SMS Brazil
> device with links to PoC Python "driver" that's relatively straightforward.
> Or read up NUT drivers, nutdrv_qx, blazer, and some others for megatec
> protocol dialects. NUT website should have a protocol library with formal
> definitions for some of those.
>
>
>
> But really, not reinventing the wheel (at least, checking if ours does
> roll) might be the faster option ;)
>
>
>
> Jim
>
>
>
>
>
> On Thu, Sep 14, 2023, 13:07 Alessandro Mandelli <
> mandelli.alessandro at ngi.it> wrote:
>
> Thanks. I forgot to mention I am developing in c# for Windows.
>
> Porting or using existing ports seems like an effort with swinging results.
>
> My prototype is working, at least as proof of concept. I’d just like some
> directions to decode the raw reports.
>
>
>
> Thanks for your help.
>
>
>
>
>
> *Da:* Jim Klimov <jimklimov+nut at gmail.com>
> *Inviato:* giovedì 14 settembre 2023 11:48
> *A:* Alessandro Mandelli <mandelli.alessandro at ngi.it>
> *Cc:* nut-upsuser at alioth-lists.debian.net
> *Oggetto:* Re: [Nut-upsuser] Info for decoding report from UPS
>
>
>
> Seems like recent work on nutdrv_qx subdriver armac (merged to master last
> month) could handle it, or some older QX drivers like richcomm if it is a
> different brew of a loosely similar product.
>
>
>
> Try following
> https://github.com/networkupstools/nut/wiki/Building-NUT-for-in%E2%80%90place-upgrades-or-non%E2%80%90disruptive-tests
> for example, to check if it would "just work" now?
>
>
>
> Jim
>
>
>
>
>
> On Thu, Sep 14, 2023 at 9:40 AM Alessandro Mandelli via Nut-upsuser <
> nut-upsuser at alioth-lists.debian.net> wrote:
>
> Hi, everybody, I just subscribed, though I’ve been lurking around for some
> time.
>
> I searched for my question in the archive, but I wasn’t able to find an
> answer.
>
> Sorry if this question has been asked before.
>
> I am in the process of writing an interfacing software.
>
> After some trial and error, I was able to query the UPS and receive an
> answer, though I am not sure how to decode the report.
>
> The UPS is generic, non branded with VID/PID 0925/1234.
>
> The report is 6 bytes long and raw data look like “0x01 0x04 0x02 0xDE
> 0xFE 0xFF”. (The fifth byte changes now and then).
>
> Any help pointing me to the right decoding table would be much appreciated.
>
>
>
> Cheers
>
> _______________________________________________
> Nut-upsuser mailing list
> Nut-upsuser at alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/nut-upsuser/attachments/20230914/010106cd/attachment.htm>