[Nut-upsdev] RFC: upscode2: handle/disable poll colliding auto UPS status messages, was: RFC: new variable battery.status

[thomas schorpp]

Hi Ted, upscode2 driver Authors

Am 08.11.2014 um 23:32 schrieb Ted Mittelstaedt:

>    The upscode2 driver has been a PIA for me for years, or maybe it isn't
> the driver but the UPS.  Yeah, probably it's the UPS.  Besides the issues with underreporting the battery state of charge, the upscode2
> driver periodically gets a no data response from the UPS.  Beats me why
> that is.

Must be periodic or event trigger'd automatic status messages mentioned in 3.1.1 and 4.6.1 Automatic messages ON/OFF of the spec colliding with a driver polling sequence
or firmware bug or non/other version -standard firmware,

see UC2concept-1002889j.odt doc from Powerware.

But according to this spec, it should be turned OFF in any model by default:

4.6.1Automatic messages ON/OFF
           DISABLE AUTOMATIC MESSAGES (DEFAULT)
UPDA (cr)
           ENABLE AUTOMATIC MESSAGES
UPEA (cr)

You may stop the driver and try issuing the UPDA cmd directly cat(?) "" > /dev/tty(USB)(n), but as I remember trying, it had no effect on the behaviour of my model.
Maybe try UPEA, too, and see what happens and if/what data comes in.
But this is not the recommended way of UPS serial line monitoring because You can't detect an UPS controller's failure this way fast enough, so polling is preferred,
otherwise the original authors would have implemented the driver for automatic messages monitoring from the beginning.

To handle this in the driver we either need to handle the serial line hardware handshake at UPS driver level if supported by ALL (usb)serial interface drivers AND cables,
the UPS should request remote polling stop and the line free for self initiated status reports using the DTR/RTS/... signals, but the line (not the driver?) does full duplex anyway,

or the UPS does the request to send by answering a polling seq with an "Empty value in UPDS" e.g. like in the driver error messages I've seen here in periods >weekly,
then we need to divert the buffer to another data to vars interpreter and formatter like specified in 3.1.1 -on the fly- , but this should be tricky in single threading
and without knowing the correct sequence and protocol and we need to handle all standard versions and implementations of this feature still in use by NUT.

Good luck with that and with decade after market devices today's manufacturers are unlikely to support us with such info.

>
> Ted
>

y
tom