Citeren Daniel O'Connor <[email protected]>:
It is tempting to base this on the size of the field that is
reported, but it would require a major amount of work on the base
usbhid-ups driver, since we only pass the parameters by value and not
by the full HID path information. Not that it isn't doable, but it
takes much more work than I'm prepared to spend on a vendor that
isn't really supportive with NUT.
Fair enough.
On top of this, APC is at the moment the only vendor for which we have
'battery.date' and 'battery.mfr.date' variables. This makes decoding
these values even more difficult, since if we don't exactly understand
what is meant, we cannot fallback to a device for which we have
information from the vendor to give us a clue what is going on.
Currently I really doubt that having a static 'battery.date' and
static 'battery.mfr.date' field is what was intended by APC. I don't
think they are using intelligent batteries (the ones I've seen so far
at least weren't), so I suspect that it should be possible to update
these fields when the battery is replaced. But how?
Because of the above I have my doubts if it is useful to use the HID paths
UPS.Battery.APCBattReplaceDate
UPS.PowerSummary.APCBattReplaceDate
at all (and therefor, if we should display either fields in this
case). On the other hand, the (serial) Smart-UPS protocol allows to
store this value in the EEPROM of the device, so it probably *is*
possible (but not through the usbhid-ups driver right now in NUT).
Best regards, Arjen
--
Please keep list traffic on the list
_______________________________________________
Nut-upsdev mailing list
[email protected]
http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
