[Nut-upsdev] telling apart USB devices

Arnaud Quette aquette.dev at gmail.com
Sun Nov 6 19:10:53 UTC 2005


Hi there,

I just got a bit of time to see this mail... still late (and busy) as always

2005/11/6, Peter Selinger <selinger at mathstat.dal.ca>:
>
> I just noticed the following curious behavior when using newhidups
> with upsdrvctl and two different USB devices:
>
> ...
>
> On the other hand, if I assign two different dummy "ports" to these
> devices:
>
> [belkinusb]
> driver = newhidups
> port = auto1
> desc = "Belkin UPS, USB interface"
> vendorid=050d
>
> [mgeusb]
> driver = newhidups
> port = auto2
> desc = "MGE UPS, USB interface"
> vendor = "MGE.*"
>
> then the two devices will be distinguished correctly. Is this behavior
> documented? The man page currently says:
>
> IMPLEMENTATION
> newhidups only support 1 UPS at this time. You can put the "auto" value
> for port in ups.conf, i.e.:
>
> [newhidups]
> driver = newhidups
> port = auto
>
> This is now most definitely outdated. But the fact that the "port" is
> used in this way, although it does not mean anything, should probably
> be documented.
>
> Arnaud, any thoughts on this? -- Peter



yep, 2 in facts:
1) the above problem is due to the state sockets and driver pidfile naming.
These are currently build using "drv-name"-"port" (adding ".pid" for the
pidfile).
This is, as you stated, not enough now with the newhidups case and its
"auto" port probing!
I've thinked about that when starting newhidups, and come to the conclusion
that using the ups definition name (ie belkinusb and mgeusb) would be
sufficient. A good way to ensure a unique filename. A special case is when
the driver is launched manually (ie just with a port, no -a and not with
upsdrvctl). In that case, we'll use the current behavior.
I'm preparing that for the cvs Dev. Watch the commit list this evening...

2) having the above done, newhidups manpage can be updated, and the problem
solved. Peter, I let you handle this part.

Arnaud
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20051106/d45a5634/attachment.htm


More information about the Nut-upsdev mailing list