Hi,
I saw your email here
http://lists.alioth.debian.org/pipermail/nut-upsdev/2005-October/000243.html
about the Liebert UPS protocol and I was wondering if it actually got
in the NUT tree?
I had a look in the 2.2.2 tree but I can only find the closed contact
stuff :(
--
Daniel O'Connor
On Mon, 4 Aug 2008, Daniel O'Connor wrote:
Hi,
I saw your email here
http://lists.alioth.debian.org/pipermail/nut-upsdev/2005-October/0002
43.html about the Liebert UPS protocol and I was wondering if it
actually got in the NUT tree?
I had a look in the 2.2.2 tree but I can only find
supports - GRR)
I think I'll just stick with dry contact or it isn't supported I
think.. :)
--
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
The nice thing about standards is that there
are so many of them to choose from.
-- Andrew Tanenbaum
GPG
On Thu, 7 May 2009, Charles Lepple wrote:
On May 6, 2009, at 11:23 PM, Daniel O'Connor wrote:
I think I would really prefer that upslog didn't keep the log file
open,
that way it doesn't matter if the log file is rotated.
I'm starting to come around to this idea. For some reason, I
, for exactly the reason you mention here.
Can you elaborate?
I don't see any disadvantage to doing an open/close for each line. The
extra syscall load would be trivial.
--
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
The nice thing about standards
On Tue, 12 May 2009, Arjen de Korte wrote:
Citeren Daniel O'Connor docon...@gsoft.com.au:
It *should* background if it isn't logging to stdout, so if it
isn't, we might have a bug here. I'm not to keen on open/close for
each line we log, for exactly the reason you mention here.
Can you
On Wed, 13 May 2009, Arjen de Korte wrote:
Citeren Daniel O'Connor docon...@gsoft.com.au:
Even over NFS it would be trivial.
If you have flash and you're worried about excess writes it won't
make a difference.
How can you be so sure? NUT runs on many different configurations
On Thu, 14 May 2009, Arjen de Korte wrote:
Citeren Daniel O'Connor docon...@gsoft.com.au:
Obviously I can't prove a negative, but I find it extremely
unlikely it could possibly be an issue on ANY platform, embedded or
otherwise.
Well, one thing is that it *will* cause existing
On Fri, 15 May 2009, Arjen de Korte wrote:
Citeren Daniel O'Connor docon...@gsoft.com.au:
Well, one thing is that it *will* cause existing installations to
break, where upslog is started as 'root' and the NUT user doesn't
have write permissions to the log file. Obviously, send upslog
install it because this is on a production system.
Also, either my changes broke it or it's already busted, but -l - doesn't
keep it in the foreground..
--
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
The nice thing about standards
On Sat, 16 May 2009, Arnaud Quette wrote:
2009/5/7 Daniel O'Connor docon...@gsoft.com.au
On Wed, 6 May 2009, Arnaud Quette wrote:
I think I've found something, but I would need an upsd debug
output (level 3) to see what going on the state socket.
I've attached a log for you
make it difficult when you're debugging
program interaction? eg a UPS driver upsd.
--
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
The nice thing about standards is that there
are so many of them to choose from.
-- Andrew Tanenbaum
GPG
when I'll be able to test it though since the code could
potentially leave a remote system shut down with no way to turn it back
on :(
--
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
The nice thing about standards is that there
are so many of them
/libexec/nut/usbhid-ups -D -D -D -a ups1
Any ideas? The libusb support in 6.x is pretty crappy so maybe it's
that :(
--
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
The nice thing about standards is that there
are so many of them to choose from
.
This will make the driver ignore the interrupt pipe, hopefully
working around this problem.
Ahah, yes that works, awesome :)
Thanks!
PS the battery.date is odd, ie
battery.date: 1988/00/39
battery.mfr.date: 2008/12/08
--
Daniel O'Connor software and network engineer
for Genesis Software - http
then it should really just
be started by some system specific daemon on UPS connection (eg devd in
FreeBSD).
--
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
The nice thing about standards is that there
are so many of them to choose from.
-- Andrew
On Mon, 1 Jun 2009, Arjen de Korte wrote:
Citeren Daniel O'Connor docon...@gsoft.com.au:
I have an MGE Ellipse 1000 connected to a FreeBSD 7.1 system and it
works well except that if I yank the cable it doesn't detect a
problem.. It seems to quite merrily read the old data (upsc reports
On Mon, 1 Jun 2009, Arjen de Korte wrote:
Citeren Daniel O'Connor docon...@gsoft.com.au:
PS the battery.date is odd, ie
battery.date: 1988/00/39
battery.mfr.date: 2008/12/08
Most likely, this is a bug in the UPS firmware. This value is set by
the HID path
I'm shocked to hear you say
On Mon, 1 Jun 2009, Arjen de Korte wrote:
Citeren Daniel O'Connor docon...@gsoft.com.au:
OK, so it needs another entry for this particular UPS? I wonder if
there is some more general way of detecting this particular
implementation..
No. The problem here is that APC uses the same HID path
of detecting it isn't..
I sent a message to freebsd-usb@ about it, I'll let you know what
arises.
If you put the attached script in /usr/bin and chmod 555 it, it should
work.
--
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
The nice thing about standards
the proper path
where to install the .fdi files. I have no idea where these files
live on FreeBSD, so could you please find out what to do here? Do
these exist at all?
They live under /usr/local/share/hal/fdi/policy
--
Daniel O'Connor software and network engineer
for Genesis Software - http
by another header (subject to certain
historical things)..
The idea being that the programmer explicitly knows what they are
getting.
--
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
The nice thing about standards is that there
are so many
it installed (since any auto* using program
needs it to build).
The only thing to remember is to make sure your makefiles call ${MAKE}
if they need to invoke make.
I didn't actually look at the problem though..
--
Daniel O'Connor software and network engineer
for Genesis Software - http
On Mon, 25 Jan 2010, Arjen de Korte wrote:
Citeren Daniel O'Connor docon...@gsoft.com.au:
FWIW I've attached the current patches to the NUT port.
The USB one will probably have to stay until the libusb stuff gets
sorted out.. I made a stub port which supplies the necessary
support
On 26/09/2010, at 10:12, Ilya Evseev wrote:
There is FreeBSD 7.1, NUT 2.4.1, UPS APC Smart 2200 XL.
I haven't had much with USB UPS comms on FreeBSD before version 8.
I thought there was a 'pollonly' option which I used and that helped but I
can't see it in the docs now.
--
Daniel O'Connor
your UPS.
In fact if it showed up as ugen in dmesg then uhid didn't pick it up.
In 8.x the new USB stack allows a normal driver to attach while still retaining
access via ugen.
--
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
The nice thing about
26 matches
Mail list logo
