[Nut-upsuser] MGE Ellipse 800 shutdown problems

[Arjen de Korte]

>> This is not what 'ondelay' is meant to do. Please checkout 'man 8
>> mge-shut' for a description of what the function of this is.
>>
> May I missing some thing? I read this carefully:
>   http://web.iesrodeira.com/cgi-bin/man/man2html?mge-shut+8

The 'ondelay' timer will be started at the same time as the 'offdelay'
timer and is really only meant to provide a means to prevent a deadlock
when the power returns before the UPS shuts down. The better solution is
documented in 'docs/shutdown.txt' which you have been told to read on
several occasions already.

>>> Also using some script to manage start of driver more reliable - I
>>> experienced  two times that it is failed from about 40 times of
>>> restart.
>>
>> See above. Did you use the suggestion under KNOWN ISSUES?
>
> I do not mean "data stale" or loss communication, I talk about that driver
> does not start at all, on start up: on Debian is it a script
> /etc/init.d/nut what contain a row
>
>   ! /sbin/upsdrvctl start >/dev/null 2>&1 && \
>     log_progress_msg "(upsdrvctl failed)" || log_progress_msg "upsdrvctl"
>
> I experienced several times that it is give a failure, but the upsd and
> upsmon is started!

This should not happen. Is the driver running at that time (but failing to
talk to the UPS) or does it terminate after a while ('ps' is your friend
here). I don't use Debian myself, so I have no idea if the above would
continue to start 'upsd' and 'upsmon' if starting the driver failed. If
so, that would be a bug in the init script.

Another interesting thing would be to know if this also happens with the
'newmge-shut' driver. The existing 'mge-shut' driver terminates at some
conditions where I would rather see it retry. Especially when it fails to
read and parse the report descriptor, it should probably retry forever
(complaining once in a while) instead of bailing out. After all, the user
has specified that a UPS is present on the port configured, so we have
every reason to expect this. Since the report descriptor is quite a chunk
of data (hundreds of bytes), it could be that communication errors lead to
the driver terminating. The 'newmge-shut' driver will behave more like it
should in this respect, although Arnaud has his doubts about some HID
mappings in the 'mge-hid' subdriver. We can probably work around those, so
I would rather fix that, than try to fix the 'mge-shut' driver.

> I modified this row with a small function, where I tries start driver 5
> times - to be save.

This should not be needed, a driver should retry by itself if it has any
chance of solving the problem (ie, in case of communication errors) other
than problems that won't go away without user intervention (a permission
problem for instance). The fact that this doesn't happen, is a bug in the
'mge-shut' driver.

[...]

> No, it is could be connected only through good, old RS-232C:) Other
> question that here should be some problems around firmware, and as I said
> aerlier it has quite a primitiv/simplified controller - cheep and dirty.

I very much question your last remark. You can build excellent UPS'es
without microcontrollers and just good old trusty NE555's. The fact that
this doesn't happen anymore is because we can do this cheaper and more
flexible with microcontrollers than with analog timers nowadays. But it
can be done.

> Also, may be, the new batteries could cause some problems - I could not
> get exactly the same batteries what was installed originally, new
> batteries are have slightly better capacity and not 100% compatible with
> the old ones.

That could very well explain why your UPS shutsdown too early. Are you
sure these new batteries are capable of providing currents in excess of
20A without dropping too much voltage? Not all batteries that may look
similar to the old will be able to do so. Also, have you made sure that
the connection to the battery terminals is solid? I have found the latter
to be difficult without making new cables.

Best regards, Arjen
-- 
Eindhoven - The Netherlands
Key fingerprint - 66 4E 03 2C 9D B5 CB 9B  7A FE 7E C1 EE 88 BC 57