On Jan 1, 2014, at 2:58 PM, Ariel Wainer wrote:
> On 01/01/14 16:12, Charles Lepple wrote:
>> In your testing, do you have suggestions on better debug levels? We
should probably log the status changes at level 2 or less, since the hex dump is
only useful for those who know the protocol. Also, I'm not sure how many of
the messages we should print while scanning the bus.
> I'm not sure I understand this question but I'll try to cover it,
please
> feel free to ask again if it's not what you meant*.
> The status transitions are being correctly detected IMHO, as seen in the
> status variable. Adding debug messages will certainly be useful.
I think you have the right idea. upsc/upsd see the ups.status value, but while
setting things up, it is useful for the driver debug messages to explicitly say
what is detected (and what will be written to ups.status).
> Do you need me to run the driver again with more "-D" ?
Probably not now. I might ask again after adding a few more debug messages.
>> Good to hear that the rest of the driver works. Can you check the
shutdown feature? (run the driver with "-k", or execute
"upsdrvctl shutdown"). I wonder if the "0x01" in the
shutdown command corresponds to the time between when the command is sent, and
when the UPS actually turns off the load.
>>
>
> This doesn't work, load remains with power after issuing this command
> both while on AC and on batteries.
> Again, maybe the UPS is not capable of doing this. It has a power
> button, that feels "physical". Maybe after the warranty time (6
months I
> think) is over I can open it up and add more insight on the capabilities.
Disappointing. I will add a note in the man page for that, too. (Maybe it is
only after the UPS is in the low battery state? You mentioned that it did shut
down when you did the capture with the Windows software.)
--
Charles Lepple
clepple at gmail