search for: hu_type_cmds

W dniu 24.08.2018 o 13:10, Charles Lepple pisze: > Sorry, I didn't mean to imply that the master branch was necessarily going to be different, just wanted to make sure you had everything set up to recompile. The real test is to see if things change after commenting out that line (such as by changing it to start with "//"): > > // { "shutdown.return", 0, 0,

W dniu 23.08.2018 o 02:16, Charles Lepple pisze: > > For some reason, this is being hardcoded to 1: > > drivers/apc-hid.c- /* used by APC BackUPS CS */ > drivers/apc-hid.c: { "shutdown.return", 0, 0, "UPS.Output.APCDelayBeforeReboot", NULL, "1", HU_TYPE_CMD, NULL }, > > Can you rebuild the NUT drivers as described here?

I'm doing testing of the UPS-side code, including being able to tell the UPS to shutdown and then come back up after a while (if power has returned). I'm trying to use upscmd so that I don't have to do an actual shutdown, but when I have it list the commands for my UPS, I just see 4 commands, and they're not the ones I thought I had specified. load.on load.off shutdown.return

Hi Rob I still have an unset draft answer to your previous mail... but you seem to have progressed... 2015-03-20 16:32 GMT+01:00 Rob Groner <rgroner at rtd.com>: > I?m doing testing of the UPS-side code, including being able to tell the > UPS to shutdown and then come back up after a while (if power has returned). > > > > I?m trying to use upscmd so that I don?t have to

W dniu 24.08.2018 o 23:13, Karol Olszewski pisze: > Hi > I'm bit closer :) > Acctually change "UPS.Output.APCDelayBeforeReboot" to > >   { "shutdown.return", 0, 0, "UPS.Output.APCShutdownAfterDelay", NULL, > "90", HU_TYPE_CMD, NULL }, > > Now, UPS turn off load after 90 sec, but not power ON when power is back > Dear nut

Hi all, I am trying to get a APC Back-UPS CS 500 running on my QNAP 419P Nas. Since on all my work I figure out the following: from Network UPS Tools upscmd 2.4.1 [~] # upscmd -l qnapups Instant commands supported on UPS [qnapups]: beeper.disable - Disable the UPS beeper beeper.enable - Enable the UPS beeper beeper.mute - Temporarily mute the UPS beeper beeper.off - Obsolete (use

On Aug 23, 2018, at 10:46 AM, Karol Olszewski <karol.olszewski at ipflow.pl> wrote: > > W dniu 23.08.2018 o 02:16, Charles Lepple pisze: >> >> For some reason, this is being hardcoded to 1: >> >> drivers/apc-hid.c- /* used by APC BackUPS CS */ >> drivers/apc-hid.c: { "shutdown.return", 0, 0, "UPS.Output.APCDelayBeforeReboot", NULL,

W dniu 22.08.2018 o 14:41, Charles Lepple pisze: > /lib/nut/usbhid-ups -a apc -DDD -k Please see attachement. -- Karol Olszewski ipflow.pl -------------- next part -------------- A non-text attachment was scrubbed... Name: APC_BackUPS_CS_650_fsd.log.gz Type: application/gzip Size: 5735 bytes Desc: not available URL:

I don't understand how the info_len element from the hid_info_t structure is used in usbhid-ups. It appears to me that the only use of this element is now to indicate the length of the string: > float info_len; /* if ST_FLAG_STRING: length of the string */ The above is clear, if the element is flagged as a string, the size of this string is put in this variable, so that we can use this in

Now tackling sending the UPS commands to have it turn off and back on (with some delay), I'm just putting this out there to make sure I'm on the right track. I want to design this to be as close as possible to "industry standard", or at least concensus. Looking through the other HU_TYPE_CMDs out there, it seems that most UPSs use "UPS.PowerSummary.DelayBeforeShutdown" for load.off.delay, and "UPS.PowerSummary.DelayBeforeStartup" for load.on.delay. Belkin appears to use custom codes (reserved for vendors), which I know I could do, but guess I don't see the reaso...

On Aug 22, 2018, at 1:20 PM, Karol Olszewski <karol.olszewski at ipflow.pl> wrote: > > W dniu 22.08.2018 o 14:41, Charles Lepple pisze: >> /lib/nut/usbhid-ups -a apc -DDD -k > Please see attachement. 1.872180 Report[buf]: (2 bytes) => 40 00 1.872196 Path: UPS.Output.APCDelayBeforeReboot, Type: Feature, ReportID: 0x40, Offset: 0, Size: 8, Value: 0 [...] 1.872439

On Mar 17, 2015, at 11:46 AM, Philip Taylor <philip at kelsotowers.co.uk> wrote: > Charles, > > Did you get chance to look at the data I sent you, please? > > I?ve done some more work myself and the conclusion I?ve reached is that if the minibus OpenUPS doesn?t support instant commands, then sending ?upsdrvctl shutdown? won?t ever work, as it would need to send instant

I got sick & tired of constant power outages with no warning, so when I saw various UPSes at the store, I decided to get one, and the one I got was a model 200897 from Newpoint (a.k.a. Power Sentry). A couple of days later the power went out and I decided to use the opportunity to hook up the UPS. I added up the wattages of the equipment I would be connecting, and found that the only way I

Charles, to your specific points : > The other HID drivers seem to trigger shutdown by writing to the various timers (e.g. UPS.PowerSummary.DelayBeforeReboot). Your firmware seems to have UPS.PowerSummary.PresentStatus.ShutdownRequested, which according to the HID PDC spec, is read/write. I wonder if the firmware responds to this? So are you suggesting if I modify openups-hid.c to include

Charles, Did you get chance to look at the data I sent you, please? I?ve done some more work myself and the conclusion I?ve reached is that if the minibus OpenUPS doesn?t support instant commands, then sending ?upsdrvctl shutdown? won?t ever work, as it would need to send instant commands! Also from the trace I sent you, it appears that after the ?RunTimeToEmpty? query, the interface tries to

Charles, Thanks again for your help, and sorry I didn?t :cc - noted for the future! I?m suspicious that the OpenUPS doesn?t behave properly in a number of ways, of which the USB traffic is the one of immediate concern. It seems to me that NUT can read from it but probably not write to it: and the OpenUPS doesn?t flag ?low battery? conditions correctly either. It does shut itself down at a

I think having this logic buried within libhid/libusb (libusb:libusb_open(), line 179 to 206) is ultimately a mistake, albeit one that I am probably responsible for. Would it make sense to confine libhid to low-level operations, and leave the decision of trying to reopen vs. retrying to open to the high-level driver, in this case usbhid-ups? I envision that the code in usbhid-ups:reconnect_ups()