[Nut-upsuser] MGE Ellipse 800 shutdown problems

[tovis]

>
>>> 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.
>
It means that this is not the mean setting of "ups.delay.start" parameter
of UPS? This delay not only could help on deadlock situation, but also
gives time for battery recharge and save the system about spuriouse line
instability which I have seen here (similar to prell).

>>>> 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.
Excerpt from start/stop script /etc/init.d/nut on Debian 4.0:

  start)
    ! /sbin/upsdrvctl start >/dev/null 2>&1  &&  \
      log_progress_msg "(upsdrvctl failed)" || log_progress_msg upsdrvctl"
    start-stop-daemon -S -q -p $upsd_pid -x $upsd >/dev/null 2>&1
  ;;
On start up I have several times:
  (upsdrvctl failed) upds upsmon
in result
ps -A | grep ups
  .. .. upsd
  .. .. upsmon

ps -A | grep mge
  nothing - it does not running at all!

uspdrvctl returns with failure, but upsd and upsmon started! When I'm stop
the service (#/etc/init.d/nut stop - result that failure on stop of
upsdrvctl) and after start manually it "stands up" correctly! To be save,
that system starts correctly I have put some extra code to init script:

#########################################################
#	check and retry start the driver by tovis 2007

cycle_counter=5

start_driver_checked () {
while [ $cycle_counter -gt 0 ]
    do
	/sbin/upsdrvctl start >/dev/null 2>&1
	if [ $? -ne 0 ]
	then
    	    log_progress_msg "(upsdrvctl failed)  "
	else
	    log_progress_msg "upsdrvctl"
	    break
	fi
	echo $cycle_counter
	cycle_counter=`expr $cycle_counter - 1`
    done
}

start_stop_server () {
  case "$START_UPSD" in
    y|Y|yes|YES|Yes)
      case "$1" in
        start)
          start_driver_checked
#--          ! /sbin/upsdrvctl start >/dev/null 2>&1  &&  \
#--            log_progress_msg "(upsdrvctl failed)" || log_progress_msg
"upsdrvctl"
          start-stop-daemon -S -q -p $upsd_pid -x $upsd >/dev/null 2>&1
          ;;
        stop)

This retries (for now) 5 times to start driver - I met similar solution
from some one on the WEB, but I can not find it again, sorry:(

> 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
BUT IT IS NOT!
> 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.

I'm an old man in this profession, analog circuits has many, many seriouse
problems (need manual tunning, using large electrolitical or tantal based
capacitors - timings up to several minutes - this are crucial for
prodaction of reasonably large series). I do not explore what for used
NE555 but I think it work here only as a cheep comparator.

>
>> 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.

Are you kidding, where you can get same batteries and how much those will
cost? - now days 3-4 years means that everythinbg is changed, you can not
by same thing again. Batteries are also always "improved", and nobody care
about old models - "the new should be good". Of course I could by a new
UPS, but what would be changed to me?

>
> 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.

I started with this - specifications provide better capacity and drop down
parameters even on high load.

> 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.

I have checked them. they are good enough.

After all, this settings - configuration is met my demands. shutdown early
on time, switch of some what later to finish shutdown and wait anough
after line is back to avoid spuriouse line failures and support recharge
of my batteries. I do not care about availability so much, most important
the stored datas and system are in safe:D

Thanks
  tovis