[Nut-upsdev] Spurious messages on start

[Peter Selinger]

Arjen de Korte wrote:
> 
> 
> > I finally understand what the DUMPALL command does. I agree with your
> > proposal. It's fine for upsmon sit there and watch the variable list
> > slowly get populated, as long as ups.status is present.
> 
> I committed this change to the trunk. Do you think we should change the
> behaviour of the DUMPALL command in the drivers, to make sure ups.status
> is the first that is sent? Otherwise (in case of newhidups for instance)
> we might be dumping lots of (irrelevant) data before ups.status is finally
> updated. Or would it be better to just ask for ups.status first and then
> perform a DUMPALL, so that the order in which the data arrives is no
> longer relevant? The first could be accomplished rather easily by putting
> ups.status in the root of the tree and changing the order how the tree is
> being walked through. Which by the way is a nice side effect of setting
> ups.status to "WAIT" after clearing the tree in the server, it will always
> be in the root.

Probably, from the point of view of robustness, a server-side solution
is better than driver-side. Changing all the drivers will be no fun
task, and is prone to error. Some drivers may implement a fixed
communication sequence to obtain their ups.status information, and in
some cases (like newhidups), the status flags are actually assembled
from a variety of device-side variables.

-- Peter