<p dir="ltr"></p>
<p dir="ltr">(sent from my S3... please excuse my brevity)<br>
Le 20 mars 2015 20:02, "Rob Groner" <<a href="mailto:rgroner@rtd.com">rgroner@rtd.com</a>> a écrit :<br>
><br>
> >>I still have an unset draft answer to your previous mail... but you seem to have progressed...<br>
><br>
>  <br>
><br>
> Heh…that’s been known to happen.  J  I have the luxury of relatively un-interrupted development on this project, so it goes a lot faster now.  Hopefully that lasts…</p>
<p dir="ltr">Hopefully, yes ;)</p>
<p dir="ltr">>  <br>
><br>
> >>>Could you please check if "usbhid-ups -D ..." does list the above HID data (UPS.PowerSummary.DelayBeforeShutdown &DelayBeforeStartup)<br>
><br>
> >>>The only case I see is that the base data are missing, since we don't check if these HID path actually exists...<br>
><br>
> Ah, bingo I think.  It sees the two paths, but gives me a “broken pipe” when trying to retrieve the reports.  I don’t have reports implemented for those two commands because…well, they should only exist one way, there is nothing to read from them.  I’ll put in a dummy report for them and see if that makes it all better.</p>
<p dir="ltr"> Not at all!<br>
Grep for these 2 vars in<br>
<a href="https://github.com/networkupstools/nut/blob/master/drivers/mge-hid.c">https://github.com/networkupstools/nut/blob/master/drivers/mge-hid.c</a></p>
<p dir="ltr">You get your answer...<br>
So this is indeed a bug, they should be readable.</p>
<p dir="ltr">><br>
> On a side note…I have them implemented in the USB Report descriptor as a Feature, which I know is R/W.  I tried making them Input and Output, and I seem to remember each time, it still came back with “broken pipe” as though it were trying to get the value of that particular data item.  Is one of those types (Feature, Input, Output) actually correct for these commands?</p>
<p dir="ltr">Feature is for the control pipe, either read or read/write<br>
Notification is for interrupt, similar to snmp traps.<br>
Neither used nor seen pure output but should be conversely similar to notification...</p>
<p dir="ltr">><br>
> >>>answer here:<br>
> >>><a href="https://github.com/networkupstools/nut/blob/master/drivers/usbhid-ups.c#L1002">https://github.com/networkupstools/nut/blob/master/drivers/usbhid-ups.c#L1002</a><br>
><br>
>  <br>
><br>
> I found it in the code, but I still didn’t understand.  I get it now…it just calls my delayed command but with a delay of 0.  That’s good to know…I’ll have to take that value into account, I think I had just been checking that the delay *wasn’t* zero before.</p>
<p dir="ltr">Just shortcuts to avoid bothering with the "immediate" versions declaration</p>
<p dir="ltr">>>  <br>
>><br>
>> >>>3)      Finally…what is the usefulness of shutdown.stayoff?  It tells the UPS to shut off its load and not to turn it back on when the power comes back.  If so…how does the UPS ever know to turn that load back on?  You would have to hook a different PC to the UPS and run nut just to send the “load.on” command?<br>
><br>
>  <br>
><br>
> Ok, I kind of get that it’s a use-case or optional feature, and I might implement that.  I had up to now just figured they would configure their PC BIOS to handle the power-on event.  But I still have to ask…how does the UPS ever know to turn its load on again?  When the UPS itself is power cycled (again)? </p>
<p dir="ltr">Shutdown.return set both offdelay and ondelay.<br>
Search for my previous mails on the topic....</p>
<p dir="ltr">> Thanks much for the help Arno</p>
<p dir="ltr">Welcome<br>
Cheers<br>
Arno</p>