(sent from my S3... please excuse my brevity)
Le 20 mars 2015 20:02, Rob Groner rgro...@rtd.com a écrit :
I still have an unset draft answer to your previous mail... but you
seem to have progressed...
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…
Hopefully, yes ;)
Could you please check if usbhid-ups -D ... does list the above HID
data (UPS.PowerSummary.DelayBeforeShutdown DelayBeforeStartup)
The only case I see is that the base data are missing, since we don't
check if these HID path actually exists...
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.
Not at all!
Grep for these 2 vars in
https://github.com/networkupstools/nut/blob/master/drivers/mge-hid.c
You get your answer...
So this is indeed a bug, they should be readable.
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?
Feature is for the control pipe, either read or read/write
Notification is for interrupt, similar to snmp traps.
Neither used nor seen pure output but should be conversely similar to
notification...
answer here:
https://github.com/networkupstools/nut/blob/master/drivers/usbhid-ups.c#L1002
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.
Just shortcuts to avoid bothering with the immediate versions declaration
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?
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)?
Shutdown.return set both offdelay and ondelay.
Search for my previous mails on the topic
Thanks much for the help Arno
Welcome
Cheers
Arno
___
Nut-upsdev mailing list
Nut-upsdev@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev
