Strange. Can you rule out a permissions problem? What is the content
of /var/state/ups? Are you running both the driver and upsd with "-u
root"? Are you sure driver and upsd are from the same NUT version?
(I sometimes have problems when running a driver directly from the NUT
source directory agains
Peter Selinger a écrit :
Hello Peter,
Your problem may be related to the way upsd and upsdrvctl interact.
There are several ways to start the driver:
(1) newhidups [options] auto
(2) newhidups [options] -a myprofile
(3) upsdrvctl start myprofile
where "myprofile" is the name of a profile defi
Your problem may be related to the way upsd and upsdrvctl interact.
There are several ways to start the driver:
(1) newhidups [options] auto
(2) newhidups [options] -a myprofile
(3) upsdrvctl start myprofile
where "myprofile" is the name of a profile defined in ups.conf.
Except for testing purpo
Eric Masson wrote:
>
> Arjen de Korte a =E9crit :
>
> Hello Arjen,
>
> > This is a different problem, your driver is not answering at all and it
> > looks like the dumpall command is not processed. Upgrading to the lates=
> t
> > development version would be a good idea now, since a few things h
Arjen de Korte a écrit :
Hello Arjen,
This is a different problem, your driver is not answering at all and it
looks like the dumpall command is not processed. Upgrading to the latest
development version would be a good idea now, since a few things have
changed in the newhidups driver lately.
>> And outputs on the command line:
>>
>> /etc/nut/upsd.conf is world readable
>> Connected to UPS [mge1200]: newhidups-auto
>> /etc/nut/upsd.users is world readable
>> Network UPS Tools upsd 2.0.4
>> Synchronizing giving up
>
> You see, there it is. Apparently the initial dump takes more t
> I've just received a mail from Pedro Côrte Real telling me that waiting
> before launching upsd could solve the problem.
>
> I've tried, but no luck. newhidups was launched 2 hours ago, and I tried
> to launch upsd 15 minutes ago.
>
> upsd output is :
> [EMAIL PROTECTED]:~> sudo upsd - -u ro
On 11/16/06, Eric Masson <[EMAIL PROTECTED]> wrote:
When I launch upsd, it barfs vith :
[EMAIL PROTECTED]:~> /usr/local/sbin/upsd -u root
Password:
Network UPS Tools upsd 2.0.4
Connected to UPS [mge]: newhidups-auto
Synchronizing giving up
This looks like the same problem I was having.
On 11/15/06, Doug Reynolds <[EMAIL PROTECTED]> wrote:
I have a 1200AVR. I found out from the website that you can program
Windows XP to use it as a contact-closure type of UPS. The generic
windows custom UPS settings are: Power Fail/On Battery - Negative, Low
Battery - Negative, UPS Shutdown - Po
>> > I guess the problem is that "Synchronizing..." step.
>> Indeed. Either the driver needs more time to dump all the data than is
>> allowed for in upsd or it could also be that the first connection to the
>> driver always fails. Since we first declare a driver stale before
>> (re)connecting, th
Eric Masson a écrit :
Hello,
I've tried to stop and relaunch it many times but output is always the
same.
I've just received a mail from Pedro Côrte Real telling me that waiting
before launching upsd could solve the problem.
I've tried, but no luck. newhidups was launched 2 hours ago, and
Hello,
I'm facing problems as I'm installing NUT to monitor a MGE Ellipse
ASR600USBS on a FreeBSD 6.1 box.
UPS is recognized as :
ugen0: MGE UPS SYSTEMS ELLIPSE, rev 1.10/42.41, addr 2
I'm temporarily using root profile (devfs/devd scripts not modified atm).
newhidups starts & runs fine (unp
This is a permissions problem. Either set up hotplugging, or run the
driver with "-u root". -- Peter
Mike Hill wrote:
>
> I tried to run newhidups myself with the debugging messages turned on and I
> got the following response:
>
> debug level is '4'
> Checking device (/) (003/001)
> - V
I tried to run newhidups myself with the debugging messages turned on and I
got the following response:
debug level is '4'
Checking device (/) (003/001)
- VendorID:
- ProductID:
- Manufacturer: unknown
- Product: unknown
- Serial Number: unknown
- Bus: 003
Trying to match device
Arjen de Korte wrote:
>
> > I guess the problem is that "Synchronizing..." step.
>
> Indeed. Either the driver needs more time to dump all the data than is
> allowed for in upsd or it could also be that the first connection to the
> driver always fails. Since we first declare a driver stale befor
>> Yes, this was what I tried first and it made no difference. upsdrvctl
>> seems to wait until the driver is fully initialized and only then goes
>> into the background.
> Looks like I hadn't tried it with a 30 second sleep. Putting a "sleep
> 30" between upsdrvctl and upsd also works so I guess
16 matches
Mail list logo
