Re: [Nut-upsuser] Info for decoding report from UPS
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 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 > *Inviato:* giovedì 14 settembre 2023 15:21 > *A:* Alessandro Mandelli > *Cc:* Arnaud Quette via Nut-upsuser > *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 > *Inviato:* giovedì 14 settembre 2023 13:17 > *A:* Alessandro Mandelli > *Cc:* Arnaud Quette via Nut-upsuser > *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: > >
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 > *Inviato:* giovedì 14 settembre 2023 13:17 > *A:* Alessandro Mandelli > *Cc:* Arnaud Quette via Nut-upsuser > *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 > *Inviato:* giovedì 14 settembre 2023 11:48 > *A:* Alessandro Mandelli > *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. > > Af
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 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 > *Inviato:* giovedì 14 settembre 2023 11:48 > *A:* Alessandro Mandelli > *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
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
