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.alessan...@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+...@gmail.com> > *Inviato:* giovedì 14 settembre 2023 15:21 > *A:* Alessandro Mandelli <mandelli.alessan...@ngi.it> > *Cc:* Arnaud Quette via Nut-upsuser <nut-upsuser@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.alessan...@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+...@gmail.com> > *Inviato:* giovedì 14 settembre 2023 13:17 > *A:* Alessandro Mandelli <mandelli.alessan...@ngi.it> > *Cc:* Arnaud Quette via Nut-upsuser <nut-upsuser@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.alessan...@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+...@gmail.com> > *Inviato:* giovedì 14 settembre 2023 11:48 > *A:* Alessandro Mandelli <mandelli.alessan...@ngi.it> > *Cc:* nut-upsuser@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@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@alioth-lists.debian.net > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser > >
_______________________________________________ Nut-upsuser mailing list Nut-upsuser@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
