Re: [Nut-upsuser] SOHO Serial Solution needed
> I'm looking to backup a small network (Hughes DW7000 satellite > modem, small consumer grade Internet Broadband router+wireless, Soekris > NET4801 single board computer + 4 port lan card, Cisco 2900 switch) > and want a small form factor (This is sitting on a small shelf) and > light. Without digging too deep into this, you would surely get more useful answers if you can give an estimate for the maximum size that would fit your needs, power demands, backup time needed, the amount of $$$ you're prepared to spend on it, etc. > The main thing I'm running into is that it *HAS* to be serial. > (The Soekris only has 1 USB port and I plan on using a 4G memory stick > and don't want it via a hub). I'm having a really hard time finding one > that seems to fit the bill, and then to know what serial cable to get > and then know someone has used it with NUT. If you've found something yourself already, if the device is mentioned in the list of supported UPSes, it most likely will work. Most of the time if a special cable is needed, it will either be provided with the UPS and/or instructions on how to make it are given. Regards, Arjen > Suggestions? If you want to off-list, I'll summarize. > > Thanks, > Tuc ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Old Contact UPS Info
Martin Rheumer schreef: > I have an old Deltec PowerRite Pro 2 UPS which has a 9 pin serial cable. > By trial and error Im pretty sure I found LB = DCD, but can not get the > combination for OB / OL. No matter what I do I get the results below. First of all, overriding the input lines via 'ups.conf' in genericups (OL and LB) is currently broken. It has been fixed most likely in the CVS development tree, but if you don't use that, it is not working like it should. Therefor, you can't use OL or LB overrides, unless you use the development version. > driver.name: genericups > driver.parameter.CP: CTS This won't work. CTS is an input pin, not an output pin. NUT can do a lot of things, but is not able to make an output from an input pin (or vice versa). You probably need to make a custom cable to fix this and connect this pin from your UPS to an output pin (DTR or RTS) on your system monitoring it. > driver.parameter.LB: DCD See the first paragraph. Trying to override this in 'ups.conf' will currently make it inpossible to detect any states on this pin. > driver.parameter.OL: DTR Again, DTR is an output and what NUT expects for OL is an input pin, so this won't work like expected. > driver.parameter.SD: DTR+RTS This might work, since only output pins are involved. > driver.parameter.upstype: 21 > driver.version: 2.0.2 > driver.version.internal: 1.30 > ups.mfr: Generic > ups.model: Generic RUPS 2000 > ups.status: OB > Anyone happen to have some hints as to what the correct settings might be ? This UPS is mentioned in the archives of the mailinglist: http://lists.alioth.debian.org/pipermail/nut-upsuser/2005-July/26.html I don't have the time now to completely go through that thread, but it may give you some clues about how to deal with your hardware. Regards, Arjen ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] APC Smart-UPS v/s 650 variables.
> Hi all, > when I try to get infos from this ups, the only variables that upsc > print is: > > # upsc [EMAIL PROTECTED] > driver.name: apcsmart > driver.version: 2.0.0 Please upgrade to the latest version first. The one you're using now is almost two years old and a lot has happened to the 'apcsmart' driver since that release. > driver.version.internal: 1.99.6 > ups.mfr: APC > ups.status: OL > > Is it not possible to get voltage and other infos from that model of > UPS? Thanks. > > Regards, > Dio. ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] APC Smart-UPS v/s 650 variables.
> Thanks for your reply. I tried to update nut to 2.0.2, but upsc print > out the same informations: > > # upsc [EMAIL PROTECTED] > driver.name: apcsmart > driver.version: 2.0.2 > driver.version.internal: 1.99.7 > ups.mfr: APC > ups.status: OL Two things you might check: 1) What cable are you using? 2) What does the driver mention upon startup? Note that the info you currently get from upsc, may be all that you will ever see. Older APC models will not support more than that. I can't tell from the information you provided so far if your UPS is among these models. Regards, Arjen ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] 3110us
Rob MacGregor schreef: >> is 3110us supported now? > You may want to provide details of the manufacturer... We had quite thread on this UPS about half a year ago. The full name is Powerware 3110 USB and as far as I know little has changed in the support status (not yet) for this device. Regards, Arjen ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] preventing automatic reboot
> I'd like to prevent my servers from rebooting when power comes back after > a > power failure. With powerchute (which I used before), there is an > "automatic > reboot" parameter. Is there an equivalent with nut ? If this is possible with NUT, depends on whether the driver for your UPS supports the 'shutdown.stayoff' command. Since you mentioned PowerChute, I assume you have an APC UPS and are using the 'apcsmart' driver. If that's the case, the man page for this driver 'man apcsmart' will tell you exactly what to do (set 'sdtype=2' in ups.conf). Regards, Arjen ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Status of tripplite_usb driver?
> there might be 2 things: > - the Changes to 'upsdrvctl' Arjen has made not long ago, I doubt it, Gregory is using version 2.0.3 and these changes were not backported from Development yet (as you also indictated). Besides that, basically the only functional change was, that it will check for both old and new styles of the pid filenames (naming changed with 2.1.0). Other than that, the changes are just a coding style related and have no functional impact. > - the volatile /var directory I've seen on Debian (don't know for other). > For this one, check my last post about "Problems starting upsd with > newhidups". That would be a volatile '/var/run' directory I presume? I would hate to see /var/spool to be cleared on reboot (we had some queued mail? not anymore). Or doesn't Debian keep the spool directory under /var? Regards, Arjen ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Problem after reboot
> Hello all, > > Rebooted my server by mistake (don't ask...) - everything was working OK > before the reboot, but after the reboot, NUT stopped working - so had a > look and I found I couldn't track the exact problem - I'm quite stumped > as there's nothing indicating that there's a problem, but it just > doesn't work... > > In a nutshell > > destiny:/usr/local/ups/bin# ./upsdrvctl start > Network UPS Tools - UPS driver controller 2.0.2 > Network UPS Tools (version 2.0.2) - APC Smart protocol driver > Driver version 1.99.7, command table version 2.0 > getpwnam(nut): Success > Driver failed to start (exit status=1) > destiny:/usr/local/ups/bin# > > I see a "Success" and then a "Failed" notice. Which is which? And what > has failed? And how? > > I tried running the driver on its own: > > destiny:/usr/local/ups/bin# ./apcsmart /dev/ttyS0 -x cable=940-0024C > Network UPS Tools (version 2.0.2) - APC Smart protocol driver > Driver version 1.99.7, command table version 2.0 > getpwnam(nut): Success > destiny:/usr/local/ups/bin# > > which points to me there's a problem with upsdrvctl somehow. No. The 'getpwnam(nut): Success' should not be displayed by the driver as far as I can tell. Throughout the sources, the word 'getpwnam' is only used to display a fatal error when NUT isn't able to locate a userid, in this case for 'nut'. Where this 'Success' is coming from, is beyond me. My guess would be that the user 'nut' doesn't exist. Try if adding '-u root' to the list of commandline parameters solves this (temporarily). Sometimes 'id nut' may be helpful too. > Am running an APC Smart UPS V/S 1400 with a home made serial cable. My > ups.conf contains: > > [ups] > driver=apcsmart > port=/dev/ttyS0 > cable=940-0024C > desc="UPS" > > and nothing else. > > Any ideas how I can fix this problem? > > Thanks very much for your help in advance! > > Cheers - Piers > > ___ > Nut-upsuser mailing list > Nut-upsuser@lists.alioth.debian.org > http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser > > ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Problem after reboot
> The reason for "Success" is that the code calls
>
> fatal("getpwnam(%s)", user);
>
> and not
>
> fatalx("getpwnam(%s)", user);
>
> While this fact is not widely documented, the only difference between
> the (badly named) procedures fatal() and fatalx() is that fatal()
> prints an error message based on errno, whereas fatalx() does not. So
> one should only call fatal() in the case of an error condition that
> has actually set errno.
Thanks for this explanation. I also saw your patch on commits. While this
patch will surely help in this particular instance, I would rather see a
more general solution to this. I really think that the fatal() function
should never, ever print ': Success'. It aborts execution prematurely and
as such, 'Success' is probably the opposite of what is going on.
To fix this for all programs using a call to fatal() to bail out, I
propose the following addition to the fatal() function (no diff yet, as
I'm not behind my development machine now):
void fatal(const char *fmt, ...)
{
va_list va;
va_start(va, fmt);
- vfatal(fmt, va, 1);
+ vfatal(fmt, va, (errno > 0) ? 1 : 0);
va_end(va);
exit(EXIT_FAILURE);
}
Besides this, we should really try to be more verbose in the error
messages. The error message is not very informative to non-programmers:
getpwnam(nut): Success
since it doesn't really help in locating the problem. I think something in
the line of
error: can't get uid for user 'nut'
would have a better chance of directing the OP to finding the cause of the
driver not being able to start (non existant nut user).
Arjen
___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Square One QP1010
> Hi guys, > > Please bare with me, as this is my first attempt at setting up a UPS > under Linux. > > I've been trying to setup a UPS on one of my clients servers. > The model of the UPS is a Square one QP1000/QP1010 1Kva > > I've looked on the following link > http://eu1.networkupstools.org/compat/stable.html > > It says that it should be compatible with the "powermust" driver, then > in my /etc/nut/driver.list this driver doesn't exist. > > I've searched around quite a bit and from what I've found, is that this > uses the "megatec protocol", which is the fentonups driver, am I > correct in what I've found out? > > I've tried using all sorts of drivers so far, and either I have a faulty > UPS, or I am still using the wrong driver. > > This is what I get when using the "fentonups" driver... > > [EMAIL PROTECTED]:/var/state/ups# upsdrvctl start > Network UPS Tools - UPS driver controller 2.0.0 Before anything else, please upgrade to the latest stable version (2.0.3). The one you're using now is past its 'use by' date. > Network UPS Tools - Fenton UPS driver 1.21 (2.0.0) > Short read during UPS id sequence > Short read during UPS id sequence > Short read during UPS id sequence > Short read during UPS id sequence > Short read during UPS id sequence > Unable to detect a Fenton or Megatec protocol UPS > Driver failed to start (exit status=1) > > Any assistance would be appreciated. > > Thanks! > > Neil Wilson > Powered by Linux, driven by passion! > > -- > This email and all contents are subject to the following disclaimer: > http://www.dcdata.co.za/emaildisclaimer.html ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Square One QP1010
> 2006/4/6, Neil Wilson <[EMAIL PROTECTED]>: >> Arnaud Quette wrote: >> > but did you check that /dev/ttyS0 has the right perms for the nut user >> > (ie the one supplied during configure --with-user=username, and which >> > default to nobody)? >> >> Yip, permissions look correct, user and group are both nut. >> >> crw---1 nut nut4, 64 Apr 6 10:08 ttyS0 > > try to broaden perms to the group too (ie crw-rw) > and to launch the driver manually in debug mode, ie: > /path/to/powermust -D -a SquareOne > > and send back the trace. The latter won't provide any more useful output, since the powermust driver doesn't use the upsdebug/upsdebugx commands at all (unfortunately). Neil might want to do a serial PnP probe, to see if anything is attached to the port and recognized (serial_probe). This is a long shot though, since even many recent serial UPSes don't support serial PnP and will remain silent until activated by a driver. Arjen ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Ablerex MARS
Carlos Rodrigues schreef: > Right now megatec just calculates a linear approximation. It doesn't > give accurate values, but it is enough to have a fuzzy idea of the > charge left (like saying "it's almost noon" instead of "it's 12:45"), > and I'm not seeing how to plot a more accurate charge that fits all > the models that megatec is supposed to support (especially given I'm > no electrical engineer). I'm an electrical engineer and have worked with lead acid batteries (telecom power supplies) for more than a decade. The only reliable way to determine the charge level for a battery is monitoring the current going in- and out of the battery (coulomb counting). And even then you'll have to compensate for a lot of variables (change of charge efficiency- and retention over temperature and lifetime for instance). All methods relying on measuring terminal voltage are unreliable at best. There are far too many variables involved (temperature, age of the battery, exact type of chemistry, history of (ab)use, etc) that make it impossible to give an estimate based on voltage alone. Arjen ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Ablerex MARS
> I have no opinion on computing the charge from the voltage; it does > not actually matter, the only charge nut really cares about is "too > low". Indeed, unless you want to calculate when to replace the batteries when their capacity falls between a certain limit, but I don't think one can expect that sophistication from low- and medium end UPSes. > However, seeing a maximum voltage of 3V on a unit that is nominally > 96V seems wrong, even if that is 8 batteries of 12V each. Could there > be a conversion error? Perhaps 2.3V should be 23V? I think it reports the single cell voltage. In that case, a value of 2.3V would be about the right voltage for a fully charged cell (in float operation that is) and 1.8V the lower discharge limit (lower than that you risk permanent damage). I would expect a better resolution in the voltage though if this is true. With 0.1V resolution, there are not an awful lot of steps between a fully charged battery and an empty one. ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] SNMP-UPS with Sicon Masterys MC
> Hello, > > I have in production one big ups of 30 kVA (MAS-MC 330). I bought > recently one Netvision SNMP card and NUT is working with snmp-ups > driver: [...] > I would like to know if NUT working with this UPS is able to shutdown > gracefully linux boxes, because I saw that snmp-ups is marked as > experimental. I can't perform a test because the UPS is providing > power for 70 computers. I strongly suggest to find a way to actually *do* perform a test at a time that is convenient. You don't want to find out something is wrong in your setup when the power is really going down and all 70 clients loose power unexpectedly (and simultanously) with you being somewhere off-site. At the very least, you should verify that your clients receive (and act upon) a force shutdown command issued to the upsmon master and that the upsmon master is able to see power state changes. Personally, I would also check to see if the system is able to shutdown cleanly in case of a power failure and subsequent reboot when the power returns. Arjen ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Recommended UPS to buy for use with NUT?
Clay Barnes wrote: > I am running a home box (600watt total load, may expand to 800-900) and > I need a UPS that can sustain power to that for at least 20 min, but > I want as much time as I can get. Is that rated load, or actual load? That seems like an awful lot of power for a single system. And unless you've a very complicated shutdown procedure, 20 minutes looks like a very long runtime. If you need that much runtime, consider if you're not better served by a smaller (in terms of runtime) capacity UPS backed by a petrol (or diesel) generator (which will give you hours/days/weeks of runtime, depending on the amount of fuel in the tank). [...] > Generally speaking, what mfrs. and models are very well supported? The website has a nice section on that http://www.networkupstools.org/compat/ It badly needs updating, but if your UPS is listed there, it is supported by NUT (check the driver documentation for the level of support). If you want optimum support, MGE seems to be a good choice however, since they officially support NUT (through Arnaud Quette). > Which should I avoid at all costs? The ones not listed in above mentioned lists. Regards, Arjen ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Recommended UPS to buy for use with NUT?
Clay Barnes wrote: >>> I am running a home box (600watt total load, may expand to 800-900) and >>> I need a UPS that can sustain power to that for at least 20 min, but >>> I want as much time as I can get. >> Is that rated load, or actual load? That seems like an awful lot of > Hm... It's the max draw of my combined tower, screen, scanner and > printer (it's not laser, I know not to do *that*). I want to be able to > use all of them for a short time after a power failure. There is a difference between the max load a UPS can handle and the average load it sees. The first determines mainly how powerful the electronics that convert the battery voltage to mains must be. The latter how large the storage capacity of the battery must be. Most of the time, a bigger UPS will also have more battery capacity, but this is not always true and in that case, buying a beefier UPS will not give you a longer runtime. Therefor it is always important to consider both peak load and average load. Regards, Arjen ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Recommended UPS to buy for use with NUT?
Peter Selinger wrote: I am running a home box (600watt total load, may expand to 800-900) and I need a UPS that can sustain power to that for at least 20 min, but I want as much time as I can get. >>> Is that rated load, or actual load? That seems like an awful lot of > 600 watt (or 600VA) does not strike me as an unduely large load rating > for a UPS. Please don't mix up VA and Watt ratings, they are very different things. > My smallest UPS has 800 VA. This is irrelevant when it comes to runtime. You can have an 800 VA UPS with a Watt rating of just 10 Watts and a runtime of 1 second for instance. Not very useful, but it is possible. The VA rating of a UPS says nothing about the runtime. > What did you have in mind Arjen? As a summary from my previous post, you should consider both peak load and average load when selecting a UPS. Just considering peak load, will mean that you will select a way too big UPS if the average load is much smaller, which is usually the case for computers. I have yet to see a home computer system that draws more than about 50% of the full load on average (and usually this figure is even lower). > Also, 20 minutes runtime is not too much to ask. Probably not, but at a load of 900W, conversion efficiency of 80% and lifetime derating (due to aging of the battery) to 80%, this will require a 1400 Wh of battery capacity (which is about 120Ah @ 12V, which is a very large battery). You won't see many consumer grade UPSes with that amount of battery storage installed (if there are any). Therefor my question, if this is rated or actual (or better put, average) load? > It's true that the system can shut down faster than that, but a human might > appreciate a chance to save his work. Of course. I'm not questioning the legitimacy of the need for a 20 min runtime, it's the amount of power drawn that looks excessive. Regards, Arjen ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Recommended UPS to buy for use with NUT?
Peter Selinger wrote: > I understand your technical points, but I think you are overkilling > this user with information. He asked a simple question about what UPS > he should buy. For reference, here is his original question: > > Clay Barnes wrote: > >> I am running a home box (600watt total load, may expand to 800-900) and >> I need a UPS that can sustain power to that for at least 20 min, but >> I want as much time as I can get. I read this question but I have to disagree with you that this is a simple one. Clay may have a setup that is indeed drawing that much power (heaven kwows what is connected to his UPS, he may be wanting to power a laser printer from it too). My concern is that people are blindly going for the box that is listing the highest VA rating, without considering what they really need and if that need it is going to be satisfied by the UPS. I fully agree that for most people running a single computer from a UPS, just about any unit that is sold nowadays will satisfy their needs. However, Clay made it quite clear (and also in his follow up posts) that he needs 20 minutes runtime and preferably even longer. In that case, he should not only consider the maximum rating for the UPS, but more importantly the average power used and battery capacity available. At least here in the Netherlands, quite a few (cheap) UPSes are sold nowadays that sport high VA ratings, but really lack the battery capacity needed to power even a modest load for more than a few minutes. Clay should avoid these at all cost. Regards, Arjen ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] protocol for "Surge MAX"
Brian Read wrote: > I am sorry if this is an FAQ, but there doesn't seem to be searchable > archives, and the supported manufacturer's list doesn't include "surge > master". Google was also not much help. > > I have just put a Linux box and the customer has a "surge max " UPS. > Anyone any ideas what protocol it uses? There is a Green serial cable. > > The manufacturers web site is here: > > http://www.surgemax.net/list_cat.php?category=2 > > But it isn't much use... The devices pictured on this page are identical to the Fenton PowerPal P600 I have here and which is supported by the safenet driver. It also mentions SafeNet Version 1 software, which is indicative that this is the same unit. Regards, Arjen ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] safenet on debian etch
> I just got myself a new everpower-1000va. > > according to the compatibility list, the 'safenet' driver supposed to support it, That depends. The hardware this driver is written for is usually OEM equipment and vendors tend to shop for the lowest bidder. So quite often they change the internals of the UPS, without changing the typenumber or even the box it is packaged in. If your UPS came with 'SafeNet v1.0' software for Windows (either in the box or via download) it should be supported by this driver. If something else is bundled, you'll have to continue your search as it probably won't be supported by this driver. > however, when I try, I get this in syslog: > > Jul 24 15:05:22 tv upsd[26458]: Can't connect to UPS [everpower1000] (safenet-ttyS1): No such file or directory This usually means the safenet driver isn't running. You may want to run the driver from the commandline with '-D' added to make it more verbose. Chances are that it will be telling you why it can't be started. This can be as trivial as a serial port without the proper permissions. [...] > I am using nut installed via apt on debian-etch. This isn't very helpful for people not running Debian. Please list version number of kernel and NUT. Regards, Arjen -- Eindhoven - The Netherlands Key fingerprint - 66 4E 03 2C 9D B5 CB 9B 7A FE 7E C1 EE 88 BC 57 -- Eindhoven - The Netherlands Key fingerprint - 66 4E 03 2C 9D B5 CB 9B 7A FE 7E C1 EE 88 BC 57 ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] safenet on debian etch
> I just got myself a new everpower-1000va. > > according to the compatibility list, the 'safenet' driver supposed to > support it, That depends. The hardware this driver is written for is usually OEM equipment and vendors tend to shop for the lowest bidder. So quite often they change the internals of the UPS, without changing the typenumber or even the box it is packaged in. If your UPS came with 'SafeNet v1.0' software for Windows (either in the box or via download) it should be supported by this driver. If something else is bundled, you'll have to continue your search as it probably won't be supported by this driver. > however, when I try, I get this in syslog: > > Jul 24 15:05:22 tv upsd[26458]: Can't connect to UPS [everpower1000] > (safenet-ttyS1): No such file or directory This usually means the safenet driver isn't running. You may want to run the driver from the commandline with '-D' added to make it more verbose. Chances are that it will be telling you why it can't be started. This can be as trivial as a serial port without the proper permissions. [...] > I am using nut installed via apt on debian-etch. This isn't very helpful for people not running Debian. Please list version number of kernel and NUT. Regards, Arjen -- Eindhoven - The Netherlands Key fingerprint - 66 4E 03 2C 9D B5 CB 9B 7A FE 7E C1 EE 88 BC 57 ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] safenet on debian etch
> # /etc/init.d/nut start > Starting Network UPS Tools:Network UPS Tools - UPS driver controller 2.0.2 > Network UPS Tools - Generic SafeNet UPS driver 0.03 (2.0.2) > > Communications with UPS lost: Status read failed > Communications with UPS lost: Status read failed > SafeNet protocol compatible UPS not found on /dev/ttyS1 > Driver failed to start (exit status=1) > (upsdrvctl failed). > > any suggestions? Run the driver in debug mode, I already suggested this in the previous message. The driver will be more verbose about what the cause is that it won't run. Regards, Arjen -- Eindhoven - The Netherlands Key fingerprint - 66 4E 03 2C 9D B5 CB 9B 7A FE 7E C1 EE 88 BC 57 ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] safenet on debian etch
>> Run the driver in debug mode, I already suggested this in the previous >> message. The driver will be more verbose about what the cause is that it >> won't run. > how do I run it in debug mode? Run (as root) /safenet -a everpower1000 -D > I think that the problem is that the device does not support the safenet > protocol. Maybe, maybe not. > when I cat /dev/ttyS1, I get no output at all. > is that normal for safenet? Yes. The device will only answer when a query or a command is sent. Regards, Arjen PS Keep the mailinglist CC-ed. I will not reply to private messages. ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] safenet on debian etch
Omry Yadan wrote: > Here is my output: > > > # /lib/nut/safenet -a everpower1000 -D > > Network UPS Tools - Generic SafeNet UPS driver 0.03 (2.0.2) > > debug level is '5' > > C : ZCADLIOPERJD > S : [empty] > > C : ZCADLIOPERJD > S : [empty] > > C : ZCADLIOPERJD > S : [empty] > > C : ZCADLIOPERJD > S : [empty] > Communications with UPS lost: Status read failed > > C : ZCADLIOPERJD > S : [empty] > Communications with UPS lost: Status read failed > SafeNet protocol compatible UPS not found on /dev/ttyS1 Either the UPS is not connected to /dev/ttyS1 (version 0.03 of the driver does not include hardware detection, which was added in 0.04) or your version of the Everpower 1000 UPS is not supported. Regards, Arjen ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] cpsups : segfault
> I'm running a Debian server (amd64) with the latest nut package > (2.0.3-4). Version 2.0.4 was released just yesterday. Since it contains a fix for an uninitialized variable, you may want to checkout that version first. Regards, Arjen -- Eindhoven - The Netherlands Key fingerprint - 66 4E 03 2C 9D B5 CB 9B 7A FE 7E C1 EE 88 BC 57 ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Can't get stuff to start automatically.
Rich Osman wrote: > Okay, I'm still trying to get nut running. [...] > The system is a SUSE 10.1 install. Did you install the SuSE provided RPM? As far as I know, this will pretty much do all what is necessary with regard to port handling and such (it does for me). Regards, Arjen ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Unable to open /dev/cuad0: Device busy
> freebsd 540$ /usr/local/etc/rc.d/nut restart > nut not running? (check /var/db/nut/upsd.pid). > Network UPS Tools - UPS driver controller 2.0.4 > Network UPS Tools - Generic UPS driver 1.32 (2.0.4) > UPS type: APC Back-UPS (940-0023A cable) > > Unable to open /dev/cuad0: Device busy Stopping a driver is an asynchronous process. Therefor, if you restart NUT, you may attempt to start the driver again before the previous one has stopped (and may still be locking the port). In that case, adding a delay of about three seconds between stopping and starting is usually sufficient to fix this. You can do this by adding 'sleep 3' in the startup script between the stopping and starting of the driver, or alternatively stop and start the driver from the commandline. Best regards, Arjen -- Eindhoven - The Netherlands Key fingerprint - 66 4E 03 2C 9D B5 CB 9B 7A FE 7E C1 EE 88 BC 57 ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] OL/OB on RD
> Which one is modem status pin? Look in the 'genericups' man page where the use of the serial lines is explained. > What about other pins? You can use any of the RS232 serial inputs if you're making your own serial cable. I suggest to pick one of the UPS types already defined since it will save you from the trouble of having to use the override option to define your own cable layout. Best regards, Arjen -- Eindhoven - The Netherlands Key fingerprint - 66 4E 03 2C 9D B5 CB 9B 7A FE 7E C1 EE 88 BC 57 ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Sweex 1000VA UPS
> I'm trying to get a sweex ups working with nut on debian sarge. Good luck! Sweex is notorious for changing their products internally, without telling you. Have you noticed that their online documentation still mentions the SafeNet software? And that they even have the guts to mention that their UPS is 'fully compatible with Unix'. Upon asking, they boldly stated that you can power a Unix box from it, but you can't monitor it. Yeah, right! > This one: > http://www.sweex.com/producten.php?lang=1&%20sectie=&item=59&artikel=95 > It's shipped with UPSmart and according to the compatibility list it > should work with the genericups upstype=7 driver. But it doesn't. I have one unit that does. But that doesn't neccessarily mean that yours does too (unfortunately, see above). > I get: > > mybox:/etc/nut# /etc/init.d/nut start > Starting Network UPS Tools: (upsdrvctl failed). > mybox:/etc/nut# This could be a configuration problem. Can you post the contents of the /etc/ups/ups.conf file here and also the permissions on the serial port you configured in there? Checking out with the bundled (Windows) software on a Windows box may be worthwile too, to rule out problems in the serial cable and/or UPS. > So I guess I'm using the wrong driver. I'm not ready to jump to that conclusion yet. > I already tried the savenet driver too, but no succes. That one for sure won't work, since that one is only good for devices that were shipped with the SafeNet 1.0 for Windows software. Yours apparently wasn't. > I found on the net someone using the ippon driver with a 500VA sweex ups, > but this doesn't work for me. All help is very appreciated. Best regards, Arjen -- Eindhoven - The Netherlands Key fingerprint - 66 4E 03 2C 9D B5 CB 9B 7A FE 7E C1 EE 88 BC 57 ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Sweex 1000VA UPS
> radius1:/etc/nut# /lib/nut/genericups -a ups_name > Network UPS Tools - Generic UPS driver 1.30 (2.0.1) > No upstype set - see help text / man page! The last line should ring a bell, don't you think so? > radius1:/etc/nut# /lib/nut/genericups upstype=7 -a ups_name > Network UPS Tools - Generic UPS driver 1.30 (2.0.1) > No upstype set - see help text / man page! Honestly, you didn't read the genericups man page, did you? You can't specify an upstype like this (the correct way is explained in the man page). > My ups.conf looks like this: > > radius1:/etc/nut# cat ups.conf > # Network UPS Tools: example ups.conf > # > user = nut > > [ups_name] > driver = genericups upstype=7 > port = /dev/ttyS0 > desc = "Sweex 1000VA UPS" In short, each configuration parameter in this file should be on a separate line, like the following: [ups_name] driver = genericups upstype = 7 port = /dev/ttyS0 desc = "Sweex 1000VA UPS" Also make sure that NUT is able to access the serial port, so you may want to check permissions: ls -l /dev/ttyS0 Kind regards, Arjen PS Please keep the mailinglist posted. Others may benefit from problems (and solutions) you have with configuring NUT to get your UPS working. -- Eindhoven - The Netherlands Key fingerprint - 66 4E 03 2C 9D B5 CB 9B 7A FE 7E C1 EE 88 BC 57 ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Sweex 1000VA UPS
>> [ups_name] >> driver = genericups >> upstype = 7 >> port = /dev/ttyS0 >> desc = "Sweex 1000VA UPS" > Ok, I tried this. > The driver was loaded and. the server shutdown immediately. Lesson #1: Always first test whether the driver is producing good results (you must be able to read the status from your UPS correctly), before using it to shutdown a system. > I had to attach a screen and a keyboard to the server and boot it in > single user mode to disable nut in /etc/default/ Lesson #2: Unless you're sure of #1, don't put NUT in scripts that are started automatically to prevent deadlocks... :-) [...] > This gives me: > > radius1:/var/log# ls -l /dev/ttyS0 > crw-rw 1 root dialout 4, 64 2005-02-26 07:39 /dev/ttyS0 > > So, I guess not good. What is the correct chown? > chown root:nut /dev/ttyS0 ? > > Could this be the reason of the instant shutdown? No, not really. When the genericups driver fails to lock the serial port (because of wrong permissions or it is locked by another process) it will fail to startup. Are you absolutely sure that the UPS is connected to /dev/ttyS0? For 'upstype=7' the signals for 'on battery' and 'low battery' are -CTS and -DCD (both zero). I wouldn't be surprized at all if this is the same as nothing connected to the port you're monitoring (although I can't test that right now). Note that the genericups driver is not able to detect whether or not something is connected to the port it is monitoring, unlike many other (somewhat) smarter protocols that are used by other drivers. This is due to the limitations of the contact closure protocol used, not by the driver. > I don't want this to happen again. (radius) Lesson #3: You really, REALLY, shouldn't experiment with a UPS on a live system... :-) When in doubt, it is always better to follow the instructions from the genericups man page under the chapter 'TESTING COMPATIBILITY' to prevent inadvertent shutdowns of your system. Kind regards, Arjen ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Sweex 1000VA UPS
YvesDM wrote: >> Are you absolutely sure that the UPS is connected to /dev/ttyS0? For >> 'upstype=7' the signals for 'on battery' and 'low battery' are -CTS and >> -DCD (both zero). I wouldn't be surprized at all if this is the same as >> nothing connected to the port you're monitoring (although I can't test >> that right now). > The machine kept rebooting, even with no serial cable to the UPS > connected anymore, so I guess that's a yes? I would say that if it doesn't make a difference whether the serial cable is attached or not, that would be a safe bet, yes. I just checked with genericups monitoring a serial port without anything connected and as expected, it showed LB OB (low battery and on battery), which would force a system shutdown had upsmon been running: # upsc [EMAIL PROTECTED] driver.name: genericups driver.parameter.port: /dev/ttyS1 driver.parameter.upstype: 7 driver.version: 2.0.3 driver.version.internal: 1.31 ups.mfr: CyberPower ups.model: Power99 ups.status: LB OB (Shame on me, even I'm not using the lastest NUT version) > How can I be absolutely sure it's connected to /dev/ttyS0? I don't know. The trouble with contact closure type UPSes is, there is no way to determine if the correct UPS is connected and in many cases, no way to check if something is connected at all. Short of a couple of ones that support serial PnP (I know of at least APC has a model that does), but that's not used by NUT (should be handled at a different level). > That proliant server has a serial A and a serial B RS232, I took serial A. If you have a serial loopback plug (or a breakout box), you could check if you can access that port, but looking at your past replies I fear that you even don't know what I'm talking about right now (no pun intended). I'm not familiar with proliant servers, so I can't offer much more help here. [...] >> Lesson #3: You really, REALLY, shouldn't experiment with a UPS on a live >> system... :-) > Yes, Easy to say when the system is already operational. I didn't have > that much choice. Disconnecting a UPS from a live server and testing it at a separate workstation is a MUST if you're not absolutely sure the configuration is correct. I would never use an UPS on a production system without double checking that monitoring works. Otherwise your investment gives you a false sense of security. Bottom line is that a UPS should make a power loss to your system predictable, it can't prevent it always, so you MUST check if that works. Even when monitoring the status of the UPS works, you must still make sure the system shuts down cleanly and reboots when power returns. There is no better way to guarantee that, than to yank the mains cable from the UPS and see what happens (at a convenient time, that is). >> When in doubt, it is always better to follow the instructions from the >> genericups man page under the chapter 'TESTING COMPATIBILITY' to prevent >> inadvertent shutdowns of your system. > Yes, I guess you're right, but I start to get sick of it. You have every reason to. You expected something to work (and if your UPS indeed would have used the SafeNet software, it would, or else give you an error message that the configuration was not OK) and instead it is giving you all sorts of trouble. Please complain to the company that sold you the UPS (or better yet, to Sweex for providing incorrect information on their website). > As I said before this is a live system and I can't mess with it to much. > I really hope someone can give me the link I 'm missing here. > Otherwise it's better to stop waisting my time on that ups and look for > another one better supported. MGE? If it should 'just work' and you don't find enjoyment in trying to make it work, do yourself a favor and indeed swap it for one that is better supported by the manufacturer (MGE indeed comes to mind, since they officially sponsor NUT). > Suggestions from recent models working without problems are welcome. > I use the stable debian package, nut 2.0.1-4 That version is already quite old, we're at 2.0.4 already, with 2.0.5 lurking just around the corner. Kind regards, Arjen ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Sweex 1000VA UPS
Udo van den Heuvel wrote: >> So what is your upsdrvctl problem? >> Are we talking the same UPS here? > I have a Sweex, 800VA or so? That is a totally different one than the Sweex 1000VA one (that shippes with UPSmart software). Please bear in mind that Sweex is basically rebranding stuff they buy from OEMs. So by just looking at the box (or even the typenumber on the box), you still don't know what you're actually getting. Since I already had written the SafeNet driver, I thought I would buy another Sweex 500VA UPS that listed the same software as for the 1000VA. Much to my dismay, only the manual still mentioned SafeNet, but the software that came with it was totally different and incompatible to the previous version. >> If yes, I wish I knew ! > Maybe try the source to see what the function does that is mentioned in > the error? No need to, it is not compatible. The 800VA and 1000VA versions are made by different OEMs. I bet your 800VA UPS didn't come with UPSmart. Best regards, Arjen ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Sweex 1000VA UPS
>> Disconnecting a UPS from a live server and testing it at a separate >> workstation is a MUST if you're not absolutely sure the configuration is >> correct. I would never use an UPS on a production system without double >> checking that monitoring works. Otherwise your investment gives you a >> false sense of security. [...] > But anyway, I will do it in a free day next week and test things out on a > spare proliant server I 'm lucky to have right now. While you're at it, try the UPS on a Windows machine with the bundled software to exclude that the UPS or serial cable are the culprits. It's a long shot, but you wouldn't be the first to find out that there is a problem in that area. It also guarantees that the UPS is indeed compatible to the UPSmart software. [...] > I definately will complain to sweex! I will ask them to send me the > manage software for linux. As they claim on their website it's supported. Don't hold your breath. And chances are that they direct you to a shoddy binary only package for RedHat 6.2 or some other ancient Linux version, which isn't very useful anymore. >> If it should 'just work' and you don't find enjoyment in trying to make >> it work, do yourself a favor and indeed swap it for one that is better >> supported by the manufacturer (MGE indeed comes to mind, since they >> officially sponsor NUT). > Don't get me wrong. I enjoy searching for things and trying to make things > work the right way. > I would never use opensource if I didn't enjoy this, would I? > But this time it's just to critical and I'm to much in a rush to get this > working. That's exactly what I meant. Personally I enjoyed reverse engineering the SafeNet protocol and writing a driver for it. And I don't feel too bad about Sweex providing erronous information on their website and not willing to provide the details on the device needed to write a driver. However, as a professional I would be outraged if I had to spend hours and hours on a €75 UPS trying to make it work because I need it so badly. In that case, you'd better invest a few euros more and buy a device that is really supported by the manufacturer (MGE for instance). [...] >> That version is already quite old, we're at 2.0.4 already, with 2.0.5 >> lurking just around the corner. > Yes I know, but I tried to keep the system as much as possible with the > stable brand. > But If it wouls solve my problems I could of course grab nut from unstable > or testing. Don't bother. Although there were some changes in genericups, the're not major and unlikely to be the root cause of your problems. If you're willing to try a few more things, comment out the part in the NUT startup script where 'upsmon' is started/stopped and fire it up. With 'upsc [EMAIL PROTECTED]' you should be able to see the status of the UPS, without the risk of shutting down your system when things are not configured properly. Try at least /dev/ttyS[0-3] with the UPS in different serial ports on your server. Remember to stop the script before modifying and starting it again. Good luck! Kind regards, Arjen ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Sweex 1000VA UPS
YvesDM wrote: > Ok, I think it's working. > The problem was the serial cable. That why I recommended to try it under Windows with the bundled software, to rule out a problem like this. > I had 2, one came with the ups, the other came with another ups. > During my tests I changed the original cable with the other one. > I never changed it back, thinking they were exactly the same. For contact closure type UPSes, they almost never are. > Now I changed it back and used the serial cabel that came with the ups > again. [...] > I don't know if the ups will actually shutdown the system now on low > battery. Assuming that the monitoring works (which looks like it), it probably will, as you already found out during earlier tests where your system kept on rebooting when the serial cable was not connected. This is essentially the same as OB LB for upstype=7. > upsc ain't showing much information on the battery status here, but as > far as I remember I've read somewhere in the docs that this is normal with > genericups > drivers, not? On Battery and Low Battery are the only two status signals available, so no fancy voltage readings, load percentages and battery charge. If you want that, you need a smarter UPS. > It's not the right time now to check if the system really is shutdown > when the battery is getting low. That would be a recommendation indeed. See the notes on this in the genericups man page. > (live system) I will test this asap and keep this list informed. Good! I'm glad that in the end things worked out for you. Kind regards, Arjen ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Sweex 1000VA UPS
YvesDM wrote: >> Assuming that the monitoring works (which looks like it), it probably >> will, as you already found out during earlier tests where your system >> kept on rebooting when the serial cable was not connected. This is >> essentially the same as OB LB for upstype=7. > Yes, but I just want to be sure tht the state "LB" is going to show up. > When this happens I'm pretty sure the thing will do what it's supposed > to do. Just remember to verify that the UPS is able to provide power long enough for your system to shutdown after signalling LB. It may take some time to shutdown your system cleanly and some UPSes simply don't have the stamina to keep powering the load long enough. So make sure your server is not powered by the UPS (and use a suitable load of incandescant lamps to simulate the server load). > I'm also wondering if the system will boot up when the powerline comes > online again. That would be very nice! That depends both on the UPS and system configuration. Most 'dumb' UPSes will turn on again once power returns, so I don't expect surprises here. The second thing to check, is whether your system will startup when power is applied. In the days of the AT power supplies (until about a decade ago), this was no issue since they had a hard power switch. Since the introduction of the ATX power supply, this usually requires a jumper/dipswitch on the mainboard or a BIOS setting. Kind regards, Arjen ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Segmentation fault
>> Can your reproduce this behavior using just NUT commands (rather than >> init scripts?) > > I made a script nut-ss that looks like this (the init-script also uses > upsdrvctl) (I started out with no driver running); > > [EMAIL PROTECTED] ~]# cat ./nut-ss > /usr/local/ups/bin/upsdrvctl stop > /usr/local/ups/bin/upsdrvctl start One thing that comes to mind is that stopping a driver is an asynchronous process. Which means that you may be starting the new driver before the previous one has terminated. Could you try again if you can reproduce the results if you put a 'sleep 5' between these statements in the nut-ss script? Kind regards, Arjen -- Eindhoven - The Netherlands Key fingerprint - 66 4E 03 2C 9D B5 CB 9B 7A FE 7E C1 EE 88 BC 57 ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Spurious messages on start
> Adding a 20 second sleep between starting upsd and starting upsmon > seems to solve the problem so I guess this happens because upsmon is > started right away when upsd hasn't started communicating with the UPS > but is already accepting connections. Did you also try adding a 5 second sleep between starting upsdrvctl and upsd? I think the problem lies there, upsd is trying to connect to the driver that is still in the process of starting up. Since upsd will periodically retry connecting to the driver if it failed, it will try to reconnect after 15 seconds (if memory serves). A 20 second delay for starting upsmon would blank reporting this problem. > I added a 30 second sleep to my init file just to be on the safe side. > Seems to work fine now but it seems like a bug in the way upsd and > upsmon interact on startup. Note that upon startup upsd will poll all configured UPSes to prevent upsmon reporting stale data. However, if it can't connect to a driver (because the driver has not finished starting up), this mechanism doesn't work and it will rightfully tell you so that it can't connect to the driver. Kind regards, Arjen -- Eindhoven - The Netherlands Key fingerprint - 66 4E 03 2C 9D B5 CB 9B 7A FE 7E C1 EE 88 BC 57 ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Spurious messages on start
> ! /sbin/upsdrvctl start >/dev/null 2>&1 && echo -n " (upsdrvctl failed)" > start-stop-daemon -S -q -p $upsd_pid -x $upsd >/dev/null 2>&1 > start-stop-daemon -S -q -p $upsmon_pid -x $upsmon >/dev/null 2>&1 Can you add '-D' as a parameter to the startup of upsmon and post the output of all three of these redirected to a single file? And preferably, also the relevant output of the system log file (since that will also tell us something about the relation in time). Kind regards, Arjen ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] (no subject)
Mike Hill wrote: > I have installed the NUT 2.0.3 RPM for Fedora Core 4 and I have it working > with an MGE Pulsar Evolution 500, but I cannot get the USB interface to > work. > > When I plug in the USB cable I get the following message in my system log: > > kernel: usbhid: probe of 2-1:1.0 failed with error -5 > > Any ideas? If you want to use USB with NUT, you need to install the latest development version. The newhidups driver is very much 'work in progress' and a lot of problems from earlier versions have been fixed by now. Having said that, your UPS should be supported through the USB port then. Kind regards, Arjen ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Spurious messages on start
>> 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 the problem is > there. See below. > Using -D on upsd seems to stop it from going in the background, so > upsmon doesn't get to run. Since the problem seems to be between the > driver and upsd that's probably ok. Yes. I should have warned you for that (my apologies). > /var/log/daemon.log shows this: > > Nov 16 00:48:46 ulisses newhidups[5196]: Startup successful > Nov 16 00:48:46 ulisses upsd[5197]: /etc/nut/upsd.conf is world readable > Nov 16 00:48:46 ulisses upsd[5197]: Connected to UPS [mge1200]: > newhidups-auto > Nov 16 00:48:46 ulisses upsd[5197]: /etc/nut/upsd.users is world readable > Nov 16 00:48:55 ulisses upsd[5197]: Pinging UPS [mge1200] > Nov 16 00:48:57 ulisses upsd[5197]: UPS [mge1200]: dump is done This is indicative of where the problems lie. The dump should have completed before pinging the driver. The fact that it didn't tells us that the initial dump has either failed or took too long, which should have prevented this in the first place. > Nov 16 00:49:02 ulisses upsd[5197]: Got PONG from UPS [mge1200] > Nov 16 00:49:10 ulisses upsd[5197]: Pinging UPS [mge1200] > Nov 16 00:49:14 ulisses upsd[5197]: Got PONG from UPS [mge1200] > Nov 16 00:49:22 ulisses upsd[5197]: Pinging UPS [mge1200] > Nov 16 00:49:22 ulisses upsd[5197]: Got PONG from UPS [mge1200] > Nov 16 00:49:30 ulisses upsd[5197]: Pinging UPS [mge1200] > Nov 16 00:49:34 ulisses upsd[5197]: Got PONG from UPS [mge1200] > Nov 16 00:49:42 ulisses upsd[5197]: Pinging UPS [mge1200] > (...) > > 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 than the 15 seconds that are hardcoded in upsd. Or it may have failed alltogether. > Pinging UPS [mge1200] > UPS [mge1200]: dump is done Similar as above, this is the 'wrong' order of things. > Got PONG from UPS [mge1200] > Pinging UPS [mge1200] > Got PONG from UPS [mge1200] > Pinging UPS [mge1200] > (...) > > 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, this will show a similar effect. I have fixed the latter in the trunk (we now try to reconnect first), so you might want to check out if this solves your problem. If not, we probably need to increase the timeout for the synchronization in upsd to see if that fixes this. Kind regards, Arjen ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Spurious messages on start
>> > 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, this will show a similar effect. I have fixed the latter >> in the trunk (we now try to reconnect first), so you might want to check >> out if this solves your problem. If not, we probably need to increase >> the timeout for the synchronization in upsd to see if that fixes this. > Shouldn't this timeout be configurable via a configuration variable? That would be a really neat solution. I'll have a look at it, this should be a relatively easy thing to do. However, I would like to know if this problem still exists after the latest change to upsd (the fix to try to (re)connect first before declaring a data stale). Best regards, Arjen ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Re: FreeBSD 6.1, MGE Ellipse ASR600USBS, newhidups & upsd
> 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 root > Network UPS Tools upsd 2.0.4 > Connected to UPS [mge]: newhidups-auto > Synchronizing giving up > Pinging UPS [mge] > Data for UPS [mge] is stale - check driver > Pinging UPS [mge] > Pinging UPS [mge] > Pinging UPS [mge] > Pinging UPS [mge] > ... 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. > Seems that it should be necessary to increase synchronizing time at upsd > startup. What value would be reasonable for INITIAL_WAIT_MAX ? I will make this value configurable later today in the (development) trunk. It will basically have the same default value, which can be overridden by specifying INITIALWAITMAX in upsd.conf, but again I really doubt this is your problem. Please note that you don't want to overdo this. All the time you spend in the initial waiting, upsmon isn't running (yet), so you're basically blind to any changes in power/battery state. Which may be a problem if you loose power repeatedly without the batteries fully recharged again in the mean time. Best regards, Arjen -- Eindhoven - The Netherlands Key fingerprint - 66 4E 03 2C 9D B5 CB 9B 7A FE 7E C1 EE 88 BC 57 ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Spurious messages on start
>> 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 than the 15 > seconds that are hardcoded in upsd. Oops! This should read '5 seconds', which would bring it better in line to the observation from your system log which shows the dump is received about 11 seconds after the connection is made. I will make this configurable later today with a default value of 5 seconds in order not to break existing installations. Best regards, Arjen ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Re: FreeBSD 6.1, MGE Ellipse ASR600USBS, newhidups & upsd
Eric Masson wrote: > If I launch newhidups via : > [EMAIL PROTECTED]:~# /usr/local/libexec/nut/upsdrvctl start mge > Network UPS Tools - UPS driver controller 2.0.4 > Network UPS Tools: New USB/HID UPS driver 0.28 (2.0.4) > > Detected a UPS: MGE UPS SYSTEMS/ELLIPSE > Using subdriver: MGE HID 0.9 > > upsd finds the socket but doesn't synchronize : > [EMAIL PROTECTED]:~# /usr/local/sbin/upsd -DDD -u root > Network UPS Tools upsd 2.0.4 > Connected to UPS [mge]: newhidups-auto > Synchronizing giving up > Pinging UPS [mge] > ... >From SVN r595 the problem with the startup delay of upsd and 'synchronizing giving up' should be fixed. Basically, this is a cosmetic bug, since after a while upsd should be able to receive replies from the driver anyway (regardless whether it can synchronize on the first try or not). Within about 30 seconds the data should no longer be stale. Note that in case of newhidups you may need to increase the value of MAXAGE in upsd.conf from the default 15 seconds to something like 30 seconds in order to prevent the staleness warnings. Regards, Arjen ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Re: FreeBSD 6.1, MGE Ellipse ASR600USBS, newhidups & upsd
> Is it possible to just use newhidups & upsd from latest svn to test or > do I have to install the whole stuff ? You'll need the full source, since there are changes in other parts of the sources that are relevant too. Provided you make sure you start up the driver in the correct way (preferably through upsdrvctl), you would only use the binaries for newhidups & upsd for testing. >> Basically, this is a cosmetic bug, since after a while upsd should be >> able to receive replies from the driver anyway (regardless whether it >> can synchronize on the first try or not). > In my setup, upsd has never succeeded in connecting to newhidups. In that case, something else is probably wrong. Regards, Arjen ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Re: FreeBSD 6.1, MGE Ellipse ASR600USBS, newhidups & upsd
> In my setup, upsd has never succeeded in connecting to newhidups. Could you try with the dummy-ups driver from SVN? Please add the following two lines to your ups.conf file: [dummy] driver = dummy-ups If upsd is not able to monitor this dummy UPS, there is something very wrong in your configuration. Regards, Arjen ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] FreeBSD 6.1, MGE Ellipse ASR600USBS, newhidups & upsd
> I still see occasional loss of connections, but things seem to work a lot > better in 2.1. I have noticed that too. The UPSes I monitor (via serial interface) lose connection every couple of days (random) and reconnect almost immediately. I suspect that this is due to a glitch in the PING/PONG between upsd and driver. Currently, the server is not really robust in this aspect, since right after retrying to PING a driver (if it failed to respond the first time), it will be declared stale (without allowing it time to reply). This needs to be changed, so that there is time to retry at least once allowing enough time for processing it without declaring the driver stale. Best regards, Arjen -- Eindhoven - The Netherlands Key fingerprint - 66 4E 03 2C 9D B5 CB 9B 7A FE 7E C1 EE 88 BC 57 ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Client behind firewall
>>> The problem is I really don't want to open a port form the dmz >>> to the internal network where the master UPS machine resides. I have >>> data from various clients that I can't have comprised. >> What has opening a port to do with that? > Arjen, I think Mike was referring to the fact that the client > initiates the TCP connection to the server, and not the other way > around. This requires opening a hole in the server's firewall (grant > access to port 3493, or another port if configured by ./configure > --with-port). Initiating traffic is only one thing. Regarding the security of this setup, it doesn't make a whole lot of difference whether the connection is initiated from the DMZ or internal network. For some firewalls it may be somewhat easier to setup, but security is just as bad either way. See below. > I don't see any reason, in principle, why the server could not > initiate the connection to the client instead. However, this would > require a lot more configuration on the server side (which clients to > connect to, what to do if it fails etc), and might also upset the > startup sequence (currently the server is started before the clients). > So in practice it would be quite difficult to implement. It wouldn't help. If you can't trust the upsmon client on the DMZ, you're toast anyway. Someone might have compromized the system in the DMZ and replaced upsmon by a malicious program, trying to gain entry through upsd. Then he only needs to wait for upsd to call in and the connection is there. The real issue here is that we need two-way communications in NUT. Only if you do something like broadcasting server status via UDP and don't listen for replies, it might make a difference. In that case, one might place the UPS master on the internal network and forward the broadcast packets to the DMZ. There would be no communication from DMZ to internal network, so security is not compromized in any way. But in that case, it would be impossible to wait for slaves to shutdown before the master takes the UPS down. And on a network with multiple UPS'es, the traffic would explode, since you would have to broadcast the full server state (and all variables) as there is no way to know when slaves start listening. To facilitate configurations like the one mentioned, we might add a 'ups.status' broadcast mode in upsd and provide an additional 'listen-only' mode in upsmon, but I certainly wouldn't recommend such a setup. Regards, Arjen ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Client behind firewall
> Only if you do something like broadcasting server status via UDP and don't > listen for replies, it might make a difference. In that case, one might > place the UPS master on the internal network and forward the broadcast > packets to the DMZ. There would be no communication from DMZ to internal > network, so security is not compromized in any way. But in that case, it > would be impossible to wait for slaves to shutdown before the master takes > the UPS down. And on a network with multiple UPS'es, the traffic would > explode, since you would have to broadcast the full server state (and all > variables) as there is no way to know when slaves start listening. > > To facilitate configurations like the one mentioned, we might add a > 'ups.status' broadcast mode in upsd and provide an additional > 'listen-only' mode in upsmon, but I certainly wouldn't recommend such a > setup. s/broadcast/multicast/g Best regards, Arjen ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] howto setup BNT-1500AP on gentoo
>> data receiving error (-1 instead of 16 bytes) [...] > The logfile '/tmp/powercom.log' will help narrow down which code path > is returning '-1'. Looking at the sources, it is quite obvious where this error occurs (in upsdrv_updateinfo). Sending a command to the UPS apparently is not a problem, but the '-1' indicates that the UPS is not responding at all (most likely, ser_get_buf_len times out). I agree with Charles' remark to checkout the cable. Regards, Arjen -- Eindhoven - The Netherlands Key fingerprint - 66 4E 03 2C 9D B5 CB 9B 7A FE 7E C1 EE 88 BC 57 ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Correct shutdown scripts for Ubuntu or Suse
pico wrote: > I would like to switch off my UPS once all upsmon clients have been > disconnected from the upsd server, so that when power returns all the > hosts connected to the ups will be powered up again. > > In the documentation it states that I should edit my shutdown scripts to > add the command: > /usr/local/ups/bin/upsdrvctl shutdown > > Unfortunately I don't know what file to add the command to. > Does anyone know the correct file to edit for both Ubuntu and Suse. > If I had to take a guess, I should edit /etc/init.d/halt > Is this correct? I don't know about Unbutu, but from SuSE 10.1 onwards this is being dealt with in the installation of the nut package by default. You don't need to modify the startup scripts yourself. Best regards, Arjen ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Correct shutdown scripts for Ubuntu or Suse
Charles Lepple wrote: > However, if you are installing from source, you can still use the > startup/shutdown scripts as a guide. I forgot to mention earlier that > you will need to link /etc/init.d/nut into the appropriate shutdown > directory (probably /etc/rc0.d; my Ubuntu box is not on at the > moment). If you want to install a newer version than SuSE provides at the moment, it is probably best to install the sources from SuSE. You can then modify the .spec file that is provided to use a newer version. This does require some tweaking of the patches that are used, since SuSE installs some files in different locations or under different names. I usually have RPM's available for the latest version of the trunk and testing branches. I'm currently using openSUSE 10.2, but as far as I know, the source RPM's build cleanly on other versions as well. If you're interested, just let me know. Best regards, Arjen ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Unitek iZi UPS 525
> I've got an Unitek iZi UPS 525 with a serial interface. The supplied cable looks fairly simple: RX->RX , TX->TX and GND->GND. Using this cable and Minicom with 2400 8N1 I'm able to issue commands to the UPS using the "Megatec Protocol" http://www.networkupstools.org/protocols/megatec.html so I know the UPS is fairly "intelligent" :-) and the serial connection works. Good. > Questions: > > 1. Which cable should I use for "Megatec Protocol"? Yes, I've read the aforementioned document but the hardware spec they give there doesn't look OK to me: e.g. "RX <-- TX (pin 9)"... Pin 9 is supposed to be RI, or not? :-| The cable you used for testing. Sometimes manufacturers make special cables, so that you'll have to buy them from them (for a premium). In other cases, a straight through connection like you used, is fine. Note that the document you're referring to lists a specific UPS model, it doesn't state that all devices using this protocol use this pin layout. > 2. Which driver should I use for "Megatec Protocol"? The only Megatec references (in "UPS features and support" > http://www.networkupstools.org/compat/stable.html) are for "genericups upstype=21". Trouble is, "genericups" looks more like an enclosure type of driver rather than a smart one. It starts OK but OL and LB are always ON, no wonder since the cable has only three wires. :-| > > Any hints? The compatibility list you're referring to is outdated. There have been quite some changes recently (also in the new megatec driver) and nut-2.0.5 will be released in just a couple days from now. If you can't wait for that, grab it from the SVN trunk. > PS. As per "UPS features and support" I've also tried "fentonups", just to be on the safe side although to me "fenton" looks more like a simple ON/OFF signaling rather than a complex serial protocol. The new megatec driver replaces many older drivers (including fentonups, if memory serves) with much more functionality. > PPS. Yes, the UPS has "Linux" written on the box and they do provide some kind of daemon, it's just that it requires JRE and X! =:-o The 'Linux' support for many of those system, usually comprises of a closed source driver for ancient Linux distro's. Don't count on it if it's written on the box, unless you're bying MGE which provides excellent Linux support. Regards, Arjen -- Eindhoven - The Netherlands Key fingerprint - 66 4E 03 2C 9D B5 CB 9B 7A FE 7E C1 EE 88 BC 57 -- Eindhoven - The Netherlands Key fingerprint - 66 4E 03 2C 9D B5 CB 9B 7A FE 7E C1 EE 88 BC 57 -- ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Unitek iZi UPS 525
> I've got an Unitek iZi UPS 525 with a serial interface. The supplied cable > looks fairly simple: RX->RX , TX->TX and GND->GND. Using this cable and > Minicom with 2400 8N1 I'm able to issue commands to the UPS using the > "Megatec Protocol" http://www.networkupstools.org/protocols/megatec.html > so I know the UPS is fairly "intelligent" :-) and the serial connection > works. Good. > Questions: > > 1. Which cable should I use for "Megatec Protocol"? Yes, I've read the > aforementioned document but the hardware spec they give there doesn't look > OK to me: e.g. "RX <-- TX (pin 9)"... Pin 9 is supposed to be > RI, or not? :-| The cable you used for testing. Sometimes manufacturers make special cables, so that you'll have to buy them from them (for a premium). In other cases, a straight through connection like you used, is fine. Note that the document you're referring to lists a specific UPS model, it doesn't state that all devices using this protocol use this pin layout. > 2. Which driver should I use for "Megatec Protocol"? The only Megatec > references (in "UPS features and support" > http://www.networkupstools.org/compat/stable.html) are for "genericups > upstype=21". Trouble is, "genericups" looks more like an enclosure type of > driver rather than a smart one. It starts OK but OL and LB are always ON, > no wonder since the cable has only three wires. :-| > > Any hints? The compatibility list you're referring to is outdated. There have been quite some changes recently (also in the new megatec driver) and nut-2.0.5 will be released in just a couple days from now. If you can't wait for that, grab it from the SVN trunk. > PS. As per "UPS features and support" I've also tried "fentonups", just to > be on the safe side although to me "fenton" looks more like a simple > ON/OFF signaling rather than a complex serial protocol. The new megatec driver replaces many older drivers (including fentonups, if memory serves) with much more functionality. > PPS. Yes, the UPS has "Linux" written on the box and they do provide some > kind of daemon, it's just that it requires JRE and X! =:-o The 'Linux' support for many of those system, usually comprises of a closed source driver for ancient Linux distro's. Don't count on it if it's written on the box, unless you're bying MGE which provides excellent Linux support. Regards, Arjen -- Eindhoven - The Netherlands Key fingerprint - 66 4E 03 2C 9D B5 CB 9B 7A FE 7E C1 EE 88 BC 57 ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Unitek iZi UPS 525
> I've got an Unitek iZi UPS 525 with a serial interface. The supplied cable looks fairly simple: RX->RX , TX->TX and GND->GND. Using this cable and Minicom with 2400 8N1 I'm able to issue commands to the UPS using the "Megatec Protocol" http://www.networkupstools.org/protocols/megatec.html so I know the UPS is fairly "intelligent" :-) and the serial connection works. Good. > Questions: > > 1. Which cable should I use for "Megatec Protocol"? Yes, I've read the aforementioned document but the hardware spec they give there doesn't look OK to me: e.g. "RX <-- TX (pin 9)"... Pin 9 is supposed to be RI, or not? :-| The cable you used for testing. Sometimes manufacturers make special cables, so that you'll have to buy them from them (for a premium). In other cases, a straight through connection like you used, is fine. Note that the document you're referring to lists a specific UPS model, it doesn't state that all devices using this protocol use this pin layout. > 2. Which driver should I use for "Megatec Protocol"? The only Megatec references (in "UPS features and support" > http://www.networkupstools.org/compat/stable.html) are for "genericups upstype=21". Trouble is, "genericups" looks more like an enclosure type of driver rather than a smart one. It starts OK but OL and LB are always ON, no wonder since the cable has only three wires. :-| > > Any hints? The compatibility list you're referring to is outdated. There have been quite some changes recently (also in the new megatec driver) and nut-2.0.5 will be released in just a couple days from now. If you can't wait for that, grab it from the SVN trunk. > PS. As per "UPS features and support" I've also tried "fentonups", just to be on the safe side although to me "fenton" looks more like a simple ON/OFF signaling rather than a complex serial protocol. The new megatec driver replaces many older drivers (including fentonups, if memory serves) with much more functionality. > PPS. Yes, the UPS has "Linux" written on the box and they do provide some kind of daemon, it's just that it requires JRE and X! =:-o The 'Linux' support for many of those system, usually comprises of a closed source driver for ancient Linux distro's. Don't count on it if it's written on the box, unless you're bying MGE which provides excellent Linux support. Regards, Arjen -- Eindhoven - The Netherlands Key fingerprint - 66 4E 03 2C 9D B5 CB 9B 7A FE 7E C1 EE 88 BC 57 -- Eindhoven - The Netherlands Key fingerprint - 66 4E 03 2C 9D B5 CB 9B 7A FE 7E C1 EE 88 BC 57 ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
RE: [Nut-upsuser] Unitek iZi UPS 525
> Really? Silly me then; Megatec looked like a fairly evolved protocol so I > was afraid that, since no RTS/CTS signaling was in place into the > manufacturer supplied cable, maybe plain RX/TX/GND won't do. For example > Minicom showed "Offline" all the time during the tests. Most (if not all) smart protocols only use RX/TX for communication. If other pins are used (DTR and RTS) they are usually used for powering the PC side of the serial interface. Hardware handshaking is seldomly used at these slow speeds (1200/2400 baud) and not needed anyway. Only when you're running at significantly higher speeds and risk buffer overflows if the processing can't keep up with the data flow, you might need some form of flow control. But in that case, XON/XOFF (software) flow control, works just as good as RTS/CTS (hardware) flow control. Usually, manufacturers just don't want to spend the additional hardware (opto-isolators for instance) required to do the latter. >> The compatibility list you're referring to is outdated. There >> have been quite some changes recently (also in the new >> megatec driver) > ... :-D Good to know. Last night I've ended up soldering all but one of > the cables listed in the "Cables" page of NUT just to discover that it > wasn't the cable, it was simply the driver. Oops! If a cable is supplied with the UPS, you should be using that. Only if you don't have a cable, you could try making one yourself. This is also somewhere in the documentation, but you already found out the hard way. > Note to anyone Googling for Unitek iZi UPS 525 and Linux: it's a Mustek > UPS and at least with NUT 2.0.3 it works with "powermust" driver using the > supplied cable. Note that powermust has also been replaced by megatec in nut-2.0.5. > Missing the cable? It's a simple straight RX/TX/GND; on > DB9: > 2->2, 3->3, 5->5. Before doing any tests with NUT make sure you can > communicate with the UPS using Minicom: go for 2400 8N1, turn hardware > flow control off and issue a Q1 command, UPS should answer with a "(value > value value..." type of string. Sound advice. >> and nut-2.0.5 will be released in just a >> couple days from now. If you can't wait for that, grab it >> from the SVN trunk. > 2.0.3 is biting me bad in the upssched department so I guess I'll have to > go for SVN. :-( Like how? There have not been too many major bugs in upssched and as far as I know this has not changed significantly (if at all) since nut-2.0.3. Could you please describe what is not working for you here? This may be just a configuration error or something more sinister which requires work from the developers. Best regards, Arjen -- Eindhoven - The Netherlands Key fingerprint - 66 4E 03 2C 9D B5 CB 9B 7A FE 7E C1 EE 88 BC 57 ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] MGE 800, ttyS0, frequent timeout
> Dear all, > > I am having trouble with > MGE Pulsar Evolution 800 Tower UPS. > > I use this UPS on several computers under RH9.0 O/S -- and the effect > is the same. > > Each computer has two UPS connected: one on ttyS0 (MGE) and the other > on ttyS1 (generic). One UPS is MGE, the other one is usually some > inexpensive generic UPS. > > The software I am running is nut-2.0.3. If the problems only occur for the MGE UPS, chances are this is driver related. In that case, first upgrade to the latest version from SVN or wait a couple of days for the release of nut-2.0.5 which should be available shortly. There have been quite some changes/improvements to mge-shut since nut-2.0.3 was released. Best regards, Arjen -- Eindhoven - The Netherlands Key fingerprint - 66 4E 03 2C 9D B5 CB 9B 7A FE 7E C1 EE 88 BC 57 ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Unitek iZi UPS 525
Ciprian Vizitiu wrote: > Ok, most likely it's me but I'm out of ideas right now; last night my very > first attempt was to use "NOTIFYCMD" with > > NOTIFYFLAG ONLINE SYSLOG+WALL+EXEC > NOTIFYFLAG ONBATT SYSLOG+WALL+EXEC > NOTIFYFLAG LOWBATT SYSLOG+WALL+EXEC > > ... and the very simple script for sending mails worked just fine. So upsmon > is actually taking into consideration "NOTIFYCMD" section. I presume that you see the status changes on upsmon reflected in the system logs, do you? Upssched won't work for a UPS that you don't monitor. > Next step was to try and add upssched to the very same script. No luck; > reading the 4th time the doc, I've figured out that upssched must be the > NOTIFYCMD param in order to work, apparently it can't be inside the script. > So right now I have in upsmon.conf: > > RUN_AS_USER nut > > NOTIFYCMD /usr/sbin/upssched > > NOTIFYFLAG ONLINE SYSLOG+WALL+EXEC > NOTIFYFLAG ONBATT SYSLOG+WALL+EXEC > NOTIFYFLAG LOWBATT SYSLOG+WALL+EXEC OK, that should work. You did restart upsmon after making changes to the upsmon.conf file, did you? Note that the daemons will not pickup any changes in configuration files, unless you tell them to reread (or restart) them. > Before you ask: > > -rwxr-xr-x 1 root root 21316 Jul 12 21:09 /usr/sbin/upssched* Fine. > Ok, upssched.conf: > > CMDSCRIPT /usr/sbin/upssched-cmd > > PIPEFN /var/run/upssched/upssched.pipe > LOCKFN /var/run/upssched/upssched.lock > > AT ONBATT [EMAIL PROTECTED] START-TIMER onbattwarn 60 > AT ONLINE [EMAIL PROTECTED] CANCEL-TIMER onbattwarn If upssched is called, you should see this in the system logfile (and you'll see that the PIPEFN exists). If not, it doesn't make sense to go and modify the upssched-cmd file, since that will only be called after the timer has elapsed. > Ok, pipe folder first: > > drwxrwxrwx 2 nut nut 4096 Dec 26 00:46 /var/run/upssched That is overly lenient, the following should be enough: drwxr-xr-x 2 nut root 4096 2006-12-27 08:48 /var/run/upssched Note that in some cases, being very lax will not work either. I know of quite a few programs that will refuse to run when they determine that the protections are not restrictive enough (although nut is not one of them, so far). So you'd better get this right from the start. > The script itself: > > -rwxrwxrwx 1 nut nut 501 Dec 26 10:51 /usr/sbin/upssched-cmd* > > ... I know, I know, I know; but I've ended up 777-ing everything just to see > it working! :-@ Ditto. > The script now looks like this: > > #! /bin/bash > # > > #case $1 in > # onbattwarn) > > #/usr/sbin/upsmon -c fsd > > echo 'Booo' > /tmp/upstest > > # ;; > # *) > # logger -t upssched-cmd "Unrecognized command: $1" > # ;; > #esac NUT comes with an example script that logs to syslog. Please use that first to checkout if everything works. [...] > BTW: It takes this Unitek UPS some 1 min to decide that the power is back. > Scary so to say, at first it looks as if the system will never come back > on-line after a power down. The displayed values for this timing are way > smaller: > > # upsrw [EMAIL PROTECTED] > [...] > > [ups.delay.start] > Interval to wait before (re)starting the load (seconds) > Type: STRING > Value: 3 > > Isn't that "3" supposed to mean "3 seconds"? Apparently not... Restarting the load is something different than reporting the line status. Also remember that you may be looking at the ups.delay.reboot interval. Which one is used, depends on whether line voltage is present or not at the time of sending the shutdown command to the UPS. Also note that (although NUT will use a precision in seconds) the UPS may have a reboot interval that can only be specified with a 1-minute interval. The driver will probably round this up to one minute. Best regards, Arjen ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Unitek iZi UPS 525
Ciprian Vizitiu wrote: > Another thing: am I supposed to be able to see some activity in the > PIPEFN/LOCKFN folder during the declared "AT" timings? 'coz there is none! > :-o And upssched.conf has the same perms like all other files in /etc/ups/ You should see some activity there (the PIPEFN is created when the timer starts). Another thing to try is # export [EMAIL PROTECTED] # export NOTIFYTYPE=ONBATT # /usr/bin/upssched You should now see that the timer is started in the system log. # export NOTIFYTYPE=ONLINE # /usr/bin/upssched Now the timer must be cancelled (provided you did the above within 60 seconds of firing up upssched for the first time). Best regards, Arjen ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] ups poweroff with cyberpower text protocol
Anton Piatek wrote: > shutting down my CyberPower OP500TE doesn't seem to work. > Does anyone know if it is possible? (if not I will just change the > shutdown script as suggested in the faq, but it would be nice to do the > proper way). The cpsups driver badly needs maintenance. The driver has some problems we can't fix, because there are no active developers for this driver. If you're willing to take up this task, please do so and join the upsdev mailinglist. Otherwise I fear that this driver will be dropped from the tree in a few revisions if this situation is not improved. > Thanks, > > Anton > > %/etc/init.d/ups-monitor poweroff > Shutting down the UPS ... > Network UPS Tools - UPS driver controller 2.0.1 We are currently at nut-2.0.4 and nut-2.0.5 is just a matter of days from release. Please upgrade to the latest released version, before asking for support. The problem you are experiencing may (or may not) be fixed already. Best regards, Arjen ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] ownership of pid directory
> The cpsups driver has some flow control issues... my cyberpower 1200AVR > is kinda dumb. The cpsups driver is rightfully flagged 'experimental'. There has been no active maintenance on this driver for at least two years. We have tried to fix some obvious errors in it, but if we can't find a developer to iron out the remaining issues with it, it probably deserves to be flagged 'broken' instead. Best regards, Arjen -- Eindhoven - The Netherlands Key fingerprint - 66 4E 03 2C 9D B5 CB 9B 7A FE 7E C1 EE 88 BC 57 ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] ownership of pid directory
Doug Reynolds wrote:
> After during some extreme testing of my CPS1200AVR, the trouble isn't
> 100% with the driver. The driver itself works the way it should.
I beg to differ. If the UPS shuts down without warning, which it doesn't
when you're using the genericups driver or Windows software, the problem
*is* in the driver.
> I've found if you issue those UPS commands thru a serial port, the UPS acts
> the same (shuts down after a couple minutes). The ups worked _great_
> with the generic driver, but you don't get all those nifty, smart
> features).
That's an interesting remark. If I understand correctly, you use
upstype=7 with the genericups driver? We could try if setting up cable
power helps here.
> The only difference I can figure out is that the Windows UPS
> driver holds one of the control pins high until it wants the UPS to shut
> down (I noticed this when I had the ups on my Windows machine and was
> monitoring the serial port).
Can you figure out which pin? I suspect that the normal situation will
be RTS=1 and DTR=0 and that they reverse when shutting down (this mimics
upstype=7 for the genericups driver). It might be that this UPS has two
shutdown methods ('smart' via the "S01R0001\r" command and 'dumb'
through raising DTR). It could be that the Windows software uses both to
handle both smart and dumb UPS'es with the same driver.
> At that time, I didn't really think it was
> important. However, not being super knowledgeable with c/cpp (or the
> NUT format, for that matter), I haven't been able to do much
> experimentation with it. I guess I'm going to have to subscribe to
> nut-dev.
Excellent! In the mean time, could you try if the following patch helps
to resolve this issue?
Best regards, Arjen
===
--- drivers/cpsups.c(revision 670)
+++ drivers/cpsups.c(working copy)
@@ -470,9 +470,19 @@
void upsdrv_initups(void)
{
+ int dtr_bit = TIOCM_DTR;
+ int rts_bit = TIOCM_RTS;
+
upsfd = ser_open(device_path);
ser_set_speed(upsfd, device_path, B2400);
+ /*
+* Set RTS and clear DTR to provide power for
+* the serial interface. It looks like some
+* Cyberpower UPS'es require this.
+*/
+ ioctl(upsfd, TIOCMBIS, &rts_bit);
+ ioctl(upsfd, TIOCMBIC, &dtr_bit);
}
void upsdrv_cleanup(void)
___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Help with nut 2.0.4, MGE Ellipse 1000 and FreeBSD
Miwa Forever wrote: > As for changing MAXAGE directive - with values 60 and greater ups become > available from pc, at least i can see it's state with upsc. But in > /var/log/messages we can see next: > > Dec 29 17:13:37 zork3 upsd[14370]: UPS [MGE-Ellipse] data is no longer > stale > Dec 29 17:13:39 zork3 upsd[14370]: Data for UPS [MGE-Ellipse] is stale - > check driver > Dec 29 17:13:39 zork3 upsd[14370]: UPS [MGE-Ellipse] data is no longer stale > Dec 29 17:13:42 zork3 upsd[14370]: Data for UPS [MGE-Ellipse] is stale - > check driver > Dec 29 17:13:42 zork3 upsd[14370]: UPS [MGE-Ellipse] data is no longer stale > Dec 29 17:13:44 zork3 upsd[14370]: Data for UPS [MGE-Ellipse] is stale - > check driver > Dec 29 17:13:44 zork3 upsd[14370]: UPS [MGE-Ellipse] data is no longer > stale > Dec 29 17:13:47 zork3 upsd[14370]: Data for UPS [MGE-Ellipse] is stale - > check driver > Dec 29 17:13:47 zork3 upsd[14370]: UPS [MGE-Ellipse] data is no longer stale > Dec 29 17:13:50 zork3 upsd[14370]: Data for UPS [MGE-Ellipse] is stale - > check driver > Dec 29 17:13:50 zork3 upsd[14370]: UPS [MGE-Ellipse] data is no longer stale > > I'm not sure that it's good desision to leave this "as is". Am i right? It looks like the connection between driver and upsd is continuously dropping. This could be a driver problem or an upsd problem. Since the driver is not reporting anything out of the ordinary, I suggest to checkout the latest version from SVN. There were a couple of problems with the staleness checks in upsd which were fixed in the trunk. Best regards, Arjen ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Help with nut 2.0.4, MGE Ellipse 1000 and FreeBSD
>> It looks like the connection between driver and upsd is continuously >> dropping. This could be a driver problem or an upsd problem. Since the >> driver is not reporting anything out of the ordinary, I suggest to >> checkout the latest version from SVN. There were a couple of problems >> with the staleness checks in upsd which were fixed in the trunk. > Alternatively to SVN, you may upgrade to 2.0.5-pre1, which was > released on Dec 20. I think this contains all of the relevant > bugfixes. Ah, I forgot about that. Indeed, the fixes are in nut-2.0.5-pre1, so that one should be fine also. Best regards, Arjen -- Eindhoven - The Netherlands Key fingerprint - 66 4E 03 2C 9D B5 CB 9B 7A FE 7E C1 EE 88 BC 57 ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Help with nut 2.0.4, MGE Ellipse 1000 and FreeBSD
>>> It looks like the connection between driver and upsd is continuously >>> dropping. This could be a driver problem or an upsd problem. Since the >>> driver is not reporting anything out of the ordinary, I suggest to >>> checkout the latest version from SVN. There were a couple of problems >>> with the staleness checks in upsd which were fixed in the trunk. >> Alternatively to SVN, you may upgrade to 2.0.5-pre1, which was >> released on Dec 20. I think this contains all of the relevant >> bugfixes. > Ah, I forgot about that. Indeed, the fixes are in nut-2.0.5-pre1, so that > one should be fine also. Never mind that remark, it looks like I have some backporting to do from the trunk if we want to include these changes. The changes to server/upsd.c and server/sstate.c are currently *not* in Testing and therefor, *not* in nut-2.0.5-pre1. Other than that, I think that some recent changes to common/state.c should be backported too, to fix a memory leak in state_delcmd(). Arnaud, what do you think about that? Regards, Arjen -- Eindhoven - The Netherlands Key fingerprint - 66 4E 03 2C 9D B5 CB 9B 7A FE 7E C1 EE 88 BC 57 ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] close pc
Marc Collin wrote: > i think nut close the computer when the battery is low... > is there a way to close it after a few time is electricity is off? This is in the FAQ (docs/FAQ): - Q: How can I make upsmon shut down my system after some fixed interval? A: You probably don't want to do this, since it doesn't maximize your runtime on battery. Assuming you have a good reason for it (see the next entry), then look at upssched.txt or the upssched man page for some ideas. - Q: Why doesn't upsmon shut down my system? I pulled the plug and nothing happened. A: Wait. upsmon doesn't consider a UPS to be critical until it's both 'on battery' and 'low battery' at the same time. This is by design. Nearly every UPS supports the notion of detecting the low battery all by itself. When the voltage drops below a certain point, it _will_ let you know about it. If your system has a really complicated shutdown procedure, you might need to shut down before the UPS raises the low battery flag. For most users, however, the default behavior is adequate. Ask yourself this: why buy a nice big UPS with the matching battery and corresponding runtime and then shutdown early? If anything, I'd rather have a few more minutes running on battery during which the power might return. Once the power's back, it's business as usual with no visible interruption in service. If you purposely shut down early, you guarantee an interruption in service by bringing down the box. See upssched.txt for information on how you can shutdown early if this is what you really want to do. - ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] close pc
>>> i think nut close the computer when the battery is low... >>> is there a way to close it after a few time is electricity is off? >> This is in the FAQ (docs/FAQ): > it's only to be sure the computer will shutdown if the battery is low. That's something that NUT will do for you, provided you give it the right SHUTDOWNCMD and your UPS has enough stamina to keep your PC running for the duration of the shutdown sequence. > how to be sure the pc will shut down? You mean poweroff? That will be handled by the sending the UPS a command to shutdown in the halt sequence. > may will get some right access problem We can't do anything about that, that's your job to get it right. In essence, if you're worried this doesn't work (and you should be), the only way to be sure is to try it out. Power your PC directly from the mains and load the UPS with a lightbulb of about 100 Watt. Pull the plug on your UPS and wait. If your PC shuts down before the lamp goes out, you're fine. If not, upssched is your friend and you need a timed shutdown after the mains is lost. Best regards, Arjen -- Eindhoven - The Netherlands Key fingerprint - 66 4E 03 2C 9D B5 CB 9B 7A FE 7E C1 EE 88 BC 57 ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] close pc
>> In essence, if you're worried this doesn't work (and you should be), the >> only way to be sure is to try it out. Power your PC directly from the >> mains and load the UPS with a lightbulb of about 100 Watt. Pull the plug >> on your UPS and wait. If your PC shuts down before the lamp goes out, >> you're fine. If not, upssched is your friend and you need a timed >> shutdown >> after the mains is lost. > It would probably be better to test with his PC, if he can do so safely. If you have no idea that the low battery detection works (which is the case the first time you try it out), you should *never* power your PC from the UPS. You'd risk corruption of you filesystems if there is something wrong or not configured correctly. > Otherwise it would be better to measure how much current his PC draws > to make sure he is testing with a large enough load. The average user won't be able to make a more accurate measurement than an estimate of 100W. You're not interested in the average current (which gives you the VA rating of you PC), but rather the real power (which can't be measured without simultanously measuring current, voltage and phase relation between them. For an initial test, this is not needed anyway. You'd have to test with the real load too of course, but only after verifying that it shutsdown in this test. >(100W might not be enough.) An average load of 100W is sufficient for most PC systems. Power supplies are rated for peak power, but on average your system load will be way below that. If your PC draws much more power than that, chances are that your UPS will not have the stamina to keep up with that for any significant time anyway, so you'd need to shutdown before LB (batteries degrade over time). Best regards, Arjen ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Re: Re: Newpoint 200897 UPS
> Good. So now you should observe how this state changes in response to > power events (lose power, on battery, low battery, battery charging, > etc). If enough of the above flags change in a predictable way, we can > use this to set the ups.status register, which will be enough to drive > upsmon. In fact, that's the only thing upsmon ever looks at. Regards, Arjen -- Eindhoven - The Netherlands Key fingerprint - 66 4E 03 2C 9D B5 CB 9B 7A FE 7E C1 EE 88 BC 57 ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Help with nut 2.0.4, MGE Ellipse 1000 and FreeBSD
> bug fixes are definitely welcome for the final 2.0.5... > so don't hesitate to backport theses change. I already did. :-) > More generally, I'll start a discussion about the driver polling rate > (2 sec) which was accurate with the dumb and old smart units, but > which is really too high for recent / verbose units (that also support > an interrupt / notification mechanism, allowing to lower the polling > rate, while not missing events). That is a no-brainer. We already support changing the polling rate through the -i command line option for the drivers. Just advise people to set this to 30 seconds or so for the drivers in question and we should be fine. > thanks for the MGE support during my vacation ;-) The bill is in the mail. ;-) Best regards, Arjen -- Eindhoven - The Netherlands Key fingerprint - 66 4E 03 2C 9D B5 CB 9B 7A FE 7E C1 EE 88 BC 57 ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Help with nut 2.0.4, MGE Ellipse 1000 and FreeBSD
>> More generally, I'll start a discussion about the driver polling rate >> (2 sec) which was accurate with the dumb and old smart units, but >> which is really too high for recent / verbose units (that also support >> an interrupt / notification mechanism, allowing to lower the polling >> rate, while not missing events). > That is a no-brainer. We already support changing the polling rate through > the -i command line option for the drivers. Just advise people to set this > to 30 seconds or so for the drivers in question and we should be fine. Or by adding 'pollinterval = 30' in 'ups.conf' for these drivers once it has been determined that this is the cause of the problems. Alternatively, we could remove the 'static' from static unsigned int poll_interval = 2; in 'drivers/main.c' and add static unsigned int poll_interval; to 'drivers/main.h' so that driver authors can set this value to a more sensible default for their driver if the UPS is known not to handle the two second polling interval that is default now. I wouldn't want to see the default changed to a higher value for backwards compatibility. Hammering a driver with too many polling commands will probably show up in the logs somewhere (or otherwise give unsatisfactory results) while silently increasing this to a higher value may mean that power events are missed on older systems/installations. The latter may go unnoticed until it causes a problem. Best regards, Arjen ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Help with nut 2.0.4, MGE Ellipse 1000 and FreeBSD
> Alternatively, we could remove the 'static' from > > static unsigned int poll_interval = 2; > > in 'drivers/main.c' and add > > static unsigned int poll_interval; The latter should read extern unsigned int poll_interval; of course (the fingers were quicker than the brain). Best regards, Arjen (off to have a cup of coffee now) ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Geek Squad UPS Systems
Kory Hamzeh wrote: > Thanks for the info. I will give it a try. It has both a USB and a > serial port. Eventually, I'd like to use the USB interface instead of > the serial. We have not tested the USB connection, but based on other drivers, this likely is not going to work. Unless the serial-to-USB converter that is most likely used in the UPS is recognized by the kernel (in is installed as a /dev/ttyUSB* device), this requires 'serial_usb.o' which is not yet available. > Few questions: > > 1. Off hand, do you know the name of the serial device for Com1 on > Fedora Core 6.0? > 2. If this works, do I need to download the latest development version > to get your drive? Yes, you do. You need the version from the SVN trunk which I'm about to submit in a couple of minutes from now. > 3. Also, how do I tell the drive to use the USB interface? If you connect the USB cable and a /dev/ttyUSB* interface is made available, you could use that. Otherwise, you don't (it won't work). Best regards, Arjen ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Windows XP clients
> But ... I'd like to put my wife's XP machine on the UPS, and have the Sun > shut it down, when appropriate. I see there is an XP port of NUT, so ... > before I start down the path of horror that is trying to install > and configure software on XP, can I actually *do* what I want here? Provided you have administrator access, yes. I used WinNUT on a Windows XP system and it installed (and runs) without problems. Best regards, Arjen -- Eindhoven - The Netherlands Key fingerprint - 66 4E 03 2C 9D B5 CB 9B 7A FE 7E C1 EE 88 BC 57 ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] APC Question...
>> I've been following through the instructions on how to connect an APC >> BackUPS 650 ES to USB, and have it monitored with NUT... [...] >> [EMAIL PROTECTED]:/usr/src/nut-2.0.4# ./drivers/newhidups -a apc -u root >> Network UPS Tools: New USB/HID UPS driver 0.28 (2.0.4) >> >> No matching USB/HID UPS found >> [EMAIL PROTECTED]:/usr/src/nut-2.0.4# >> >> Can anyone suggest a course of action I can take?.. > > this should be due to the fact that you have not set the hotplug or udev > rules. Not very likely. He's running the driver as root, so this looks more like what was reported on the Bugs Tracker for an APC Back-Ups ES725: http://alioth.debian.org/tracker/?func=detail&atid=411542&aid=304333&group_id=30602 Solution is to upgrade to nut-2.0.5-pre2. Best regards, Arjen -- Eindhoven - The Netherlands Key fingerprint - 66 4E 03 2C 9D B5 CB 9B 7A FE 7E C1 EE 88 BC 57 ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Client-only Make option?...
> Is there a Make/Config option that would build JUST the client binaries, > upsmon and upsc?... Right after installing the sources, the answer is no. You need to compile some common stuff too, for which we have no separate options available. The question is, why do you want to do that in the first place? If you just want to change some things in the clients and don't want to recompile the whole lot (which can take quite some time), just do your modifications in the clients directory and run 'make' there again. In that case, only the changed sources will be recompiled and new clients will be build. Best regards, Arjen -- Eindhoven - The Netherlands Key fingerprint - 66 4E 03 2C 9D B5 CB 9B 7A FE 7E C1 EE 88 BC 57 ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Client-only Make option?...
Richard Whittaker wrote: > Well, for a UPS connected client system with network ties to upsd, > there's no reason to build any of the driver stuff, the only items I'm > looking for would be upsmon, and possibly upsc, so I thought there might > be a "configure --client-only" option or something. That's a rather unusual configuration. Most of the time, people will be running at least one driver and upsd server, so you'll need to build the lot at least once. Only when your clients can't run the binaries you created for your server, this might be of interest, but this doesn't seem to be that common. But feel free to provide a patch that provides this functionality. Best regards, Arjen PS Of course there is no reason to *install* the things you don't need, so the only thing wasted is CPU cycles to compile the code you didn't want. ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] CyberPower 1250AVR UPS. Anybody got one?
[...] > My reason for this is this. When our power goes out, most everything is > automatic. If it goes out and stays out more than about 5 or 10 > minutes, it's going to be a while. It may be 2 hours or all day. If it > is going to come back on after resetting itself, it will do so in about > 3 or 4 minutes. > > Anybody care to share their config for a similar situation? You didn't look at docs/FAQ, did you? - Q: How can I make upsmon shut down my system after some fixed interval? A: You probably don't want to do this, since it doesn't maximize your runtime on battery. Assuming you have a good reason for it (see the next entry), then look at upssched.txt or the upssched man page for some ideas. - What you want to achieve can be found in upssched.txt. Best regards, Arjen -- Eindhoven - The Netherlands Key fingerprint - 66 4E 03 2C 9D B5 CB 9B 7A FE 7E C1 EE 88 BC 57 ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Network UPS Tools version 2.0.5 released
>> Any idea when those committed powercom specs will be incorporated? >From the FAQ: "Any time there is a gap in features, it's usually because the group of people who own that hardware and the group of people who write code don't overlap. The fix is to make them overlap - turn an owner into a developer or vice-versa." Unless someone picks up writing a driver around the protocol specification that was committed by Alexey Sidorov (December 22nd), this may never happen. None of the active developers has one of these devices, as far as I know. >> I'm eagerly awaiting them -- if there's a cvs snapshot or something I can >> check out I can help you with testing. See above. Don't hold your breath. > digging back the powercom king-pro thread, I don't see anything more > than "it doesn't work with the powercom driver but it should with > genericups" I never heard of you again after suggesting to try the genericups driver. That doesn't really help in persuading me to look into this. > I don't see any commited specs too?! Since the specifications were posted in the development mailing list, but nobody picked up the task for writing a driver for it, I don't see any need to rush it. Best regards, Arjen ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] CyberPower 1250AVR UPS. Anybody got one?
> Somewhat off topic here. E, right. That was my mistake, I accidentally typed in the 'wrong' mailing list (the development list is where I hangout most of the time). I'll reply to your message in the 'right' one. Best regards, Arjen -- Eindhoven - The Netherlands Key fingerprint - 66 4E 03 2C 9D B5 CB 9B 7A FE 7E C1 EE 88 BC 57 ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] CyberPower 1250AVR UPS. Anybody got one?
> Well, thing is, I don't want it to wait until the battery is about > dead. That is not good for the batteries either. My UPS will last > about a hour but I don't want it to run that long. I mostly got the UPS > because of the blinking our lights do sometimes. As in previous post, > if it is out more than about 10 minutes, it's going to be a while. May > as well shutdown and call it a day. In that case, upssched is what you need. But in order for it to work, you *must* make sure that upsmon is triggered by the mains/battery events. If that doesn't happen (for a variety of reasons), it will never be called. NUT comes with an example script and since version nut-2.0.5 we also have a 'dummy-ups' driver. I found the latter extremely helpful in debugging all sorts of interprocess communication. > I am using Gentoo Linux on this rig. To be honest, I used Mandrake for > a good while. I hated the upgrade process so I switched to Gentoo. > With Mandrake I was using Powstat and it did just what I wanted it to > do. It would sense as soon as the power failed and would wait a bit, > then shut down my system. Thing is, I can't get powstat to work on > Gentoo. Sorry, I don't know powstat, so can't be much of help here. > I'll go dig around and find the configs and post them in a bit. I was > hoping someone had a UPS like mine and could just send me theirs. Then > maybe it would work right. I thought it was working until a power > failure a while back. I found out it wasn't then. First course of action is to find out whether upsmon is seeing any status changes at all. Power your computer directly from the mains, while still monitoring the UPS. If you pull the plug on your UPS, upsmon should notice the change. If this doesn't work, running upsd or the driver in debug mode should aid in sorting out where things go wrong. > I did get the other to work though. Nice to hear. Best regards, Arjen ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] APC Smartups protocol - Hidden Programming Mode
> Hope nut-upsuser is an appropriate place to post additional info about > the smartups protocol, please tell me if not. We would prefer nut-devel I think, since that's more about the development of drivers and such. [...] > Using car batteries > === [...] > I'm a bit concerned about the different capacity of the batteries: Since > the batteries are connected in series, the weakest one will be > discharged the most, which in turn hurts its capacity. I'm thinking > about connecting a resistor (e.g. 220 Ohm, 1W) in parallel to each > battery, so that they at least get the same tension when being charged. What do you think a car battery actually is? Six individual 2V cells connected in series. What you're essentially doing with connecting four car batteries in series, is just adding more cells in the battery string. As long as you use the same make/type/age of batteries, there is no need for equalizing with a resistor, the capacity will be practically the same. Besides wasting energy, you might prevent the charging circuit from detecting full battery state (since the charge current will never go to virtually zero). Only in *very* large installations it is worthwhile (and cost effective) to charge and monitor each cell separately to make the most out of the lifetime of them. But you'd be looking at the scale of batteries used in submarines, rather than at a home/small office UPS. Best regards, Arjen -- Eindhoven - The Netherlands Key fingerprint - 66 4E 03 2C 9D B5 CB 9B 7A FE 7E C1 EE 88 BC 57 ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] "no longer stale" when disconnected with 2.0.5 newhidups
> After reconnect the ups, the communication is ok and nut works until I > disconnect again. Which version of NUT are you using? > I tired also different values for pollinterval. Which values? Did you also change the MAXAGE value for upsd? > We want to shutdown the server, if the ups is disconnected from the server > (e.g. if the ups is defect). You can do this by means of a script that is called by NOTIFYCMD (see 'man 5 upsmon.conf') or through upssched (see 'man 8 upssched'), which is more flexible. Best regards, Arjen -- Eindhoven - The Netherlands Key fingerprint - 66 4E 03 2C 9D B5 CB 9B 7A FE 7E C1 EE 88 BC 57 ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] [UPS on Serial vs. USB] USB slow to update, serial instant.
> When I disconnect my UPS from the wall, I have to wait 15-30 seconds > before the USB drier 'polls' this information and tells me that the UPS is > on battery power (via knutclient or syslog via nut): > > [EMAIL PROTECTED] POWER ALERT on Fri Jan 26 12:49:29 EST 2007 > > With a serial connection, I would get the alerts IMMEDIATELY (0.5-1 > seconds) after disconnecting the UPS. My new machine does not have a > serial port built-in, only a serial header, and of course does not come > with an included cable, so I chose to use USB. Which serial driver have you been using so far? Most serial drivers will poll the UPS every two seconds for status updates. So on average, you'll see status changes in about half that time, which equals about one second. So far the number of UPSes that issue alerts on line status changes is limited and hence we don't have that many drivers that use this feature. But generally speaking, what you're seeing is normal for a driver that uses the serial interface. > My question is, how do I change the polling time that nut uses to poll the > device to match that of the serial port? That depends on the driver you're using. If you're using the newhidups driver (which will be renamed usbhid-ups in the next release), there is probably not much you can do about this. Many USB protocols are *very* verbose and don't allow polling the status every two seconds. Therefore, the newhidups has a build in mechanism to only do a full status update every 30 seconds (if memory serves). If you're using another driver, you could try the 'pollinterval' parameter (see 'man 5 ups.conf' for a description after verifying that the man page of the driver does not mention it). > The reason I'd like to is I am not going to see any power alerts for > unless there is a power outage for longer than 15-30 seconds. Use a less verbose (serial) driver in that case. There is probably nothing else we can do for you right now. A driver that uses a more intelligent mechanism to read status changes more frequently is planned, but so far we have no schedule for its release (not even for an experimental/trial version, don't ask). > I've checked the FAQ on this, do I have to change the 'MAXAGE' parameter > to force more frequent updates? No. The MAXAGE parameter only determines when to declare a driver stale. If we don't hear anything from a driver for this many seconds, it is declared stale. This has nothing to do with the polling interval. Best regards, Arjen -- Eindhoven - The Netherlands Key fingerprint - 66 4E 03 2C 9D B5 CB 9B 7A FE 7E C1 EE 88 BC 57 ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Meaning of ups.delay.*
> As I'm currently porting the HP PowerTrust driver from nut-1.4.3, I have > a question regarding ups.delay.*. > > The PTs can delay the Shutdown/Restart and Kill commands by an arbitrary > number of seconds, i.e. they wait for n seconds and then shutdown or > kill. The delay for the restart after the shutdown can't be changed. > Which of the ups.delay.* variables correspond to these values? See my answer on the development list <[EMAIL PROTECTED]> Regards, Arjen -- Eindhoven - The Netherlands Key fingerprint - 66 4E 03 2C 9D B5 CB 9B 7A FE 7E C1 EE 88 BC 57 ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] "no longer stale" when disconnected with 2.0.5
Peter Selinger wrote: > If I understood Markus correctly, the problem is not that the data > goes stale (it should do that when disconnecting the UPS > communications line), but that it goes unstale immediately afterwards > (even when the UPS is still disconnected). That's entirely possible if he's using a version older than 2.0.4. That's why I asked him which version he's using. > This shouldn't really happen. Maybe some debugging is needed. Maybe, but in that case I would still like to know the version, in order to interpret the output in the right way. We've applied some bugfixes in this aspect, especially in the code that decides whether a UPS is stale or not. > Markus: the function that decides whether your UPS is stale or not is > server/sstate.c:sstate_dead(). Perhaps you can insert some debugging > statements to figure out what this function returns and why. If sstate_dead() is the problem, I'm almost certain that Markus is using something older than 2.0.4. In that case he'd better update to something newer. Best regards, Arjen ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] "no longer stale" when disconnected with 2.0.5
> Yes, but he said "2.0.5" in the subject line. -- Peter That stood out pretty obvious... :-) Best regards, Arjen ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] "no longer stale" when disconnected with 2.0.5 newhidups
> After I disconnect the UPS the upsd write "Data for UPS [apc] is stale - > check driver" in /var/log/messages. In the same second it tells "UPS [apc] > data is no longer stale". This repeats all the time the ups is > disconnected: > > Jan 25 14:45:03 degpn026w226 kernel: usb 4-1: USB disconnect, address 3 > Jan 25 14:45:06 degpn026w226 upsd[4275]: Data for UPS [apc] is stale - > check driver > Jan 25 14:45:08 degpn026w226 upsd[4275]: UPS [apc] data is no longer stale > Jan 25 14:45:10 degpn026w226 upsd[4275]: Data for UPS [apc] is stale - > check driver > Jan 25 14:45:10 degpn026w226 upsd[4275]: UPS [apc] data is no longer stale [...] Now that Peter has pointed me in the right direction, forget my previous posts. This is really weird. There are basically two ways for upsd (by means of the sstate_dead() function) to determine the *driver* is stale (it has nothing to do with the UPS, we'd better change the wording of the error messages). Either the driver has not send us anything within MAXAGE seconds or upsd has problems maintaining the connection to the driver socket. Unless you've changed the value of MAXAGE to some ludicrous low value of two seconds, this might be a socket problem. I recall someone having similar problems on a *BSD system a while ago. What system are you using? Could you check if the socket is in /var/state/ups? Whatever happens, the driver should *not* remove the socket if it can't communicate with the UPS. It should call dstate_datastale() rather than giving up the socket in that case (this is not how the line of communication works). So the problem is probably in the driver, since it has no problems keeping the socket fresh when the UPS is connected. Best regards, Arjen -- Eindhoven - The Netherlands Key fingerprint - 66 4E 03 2C 9D B5 CB 9B 7A FE 7E C1 EE 88 BC 57 ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] sweex 1000VA LB OB issue
Herman wrote: > I have a question regarding a sweex product. Its bundled with UPSmart v > 2.12. > I installed nut accordingly to the user manual included in the software. > A quick check of data/drivers.list revealed to me i should use the: > "Sweex" "500/1000" "contact closure - shipped with > UPSmart""genericups upstype=7" driver > > this driver loads just fine. I also checked the other sweex's drivers > they won't load. Are you absolutely sure that the UPS is connected to /dev/ttyS0? The fact that the driver is reporting "OB LB" may also mean nothing is connected to the port. Best regards, Arjen ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] "no longer stale" when disconnected with 2.0.5
Peter Selinger wrote: > If I understood Markus correctly, the problem is not that the data > goes stale (it should do that when disconnecting the UPS > communications line), but that it goes unstale immediately afterwards > (even when the UPS is still disconnected). > > This shouldn't really happen. Maybe some debugging is needed. > > Markus: the function that decides whether your UPS is stale or not is > server/sstate.c:sstate_dead(). Perhaps you can insert some debugging > statements to figure out what this function returns and why. In retrospect, that is a good idea. We've seen more problems in the past with this (repetitive stale/not stale reports from upsd), so we'd better put this in the code ourselves. Markus, could you checkout the latest code from the SVN trunk and run upsd with -D to see what is happening? Best regards, Arjen ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] sweex 1000VA LB OB issue
Herman wrote: >> Are you absolutely sure that the UPS is connected to /dev/ttyS0? The >> fact that the driver is reporting "OB LB" may also mean nothing is >> connected to the port. > Thank you for your fast reply, > Yes i am quite sure my Sweex UPS 1000VA is connected to the correct > port. This port is also owned by the NUT user. > I have tested this by connecting a modem and sending an AT commando to > it. It happily replayed with OK. That should be enough. OK, the port is right. What about the cable, you did use the one provided with the UPS I guess, since you also used it with the Windows software (with the same cable?) > Also i have connected the UPS to a windows machine. The bundled software > worked on that machine UPSmart 2.14. The linux software on the CD wasn't > useful since i don't run X. The manual i got with the UPS was a > complete waste of time. It was written for a different version software > i guess you would call it the "safenet" protocol. > > This suggests that sweex doesn't know what UPS'es they are actually > shipping. Or to stupid to include the right manual.. Spot on. I have told them this more than two years ago, but apparently they just don't care about it. They are notorious for not caring at all about this... :-( Could you try to snoop the serial communication between Windows driver and the UPS? The following link will point you to some software that may aid in this: http://www.microsoft.com/technet/sysinternals/Utilities/Portmon.mspx If you post the first 10 seconds of output, someone might be able to figure out what protocol is used and if we have a driver for it. Best regards, Arjen ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] sweex 1000VA LB OB issue
> I am sorry i have to give up this early but its already working with the > mustec/megatec driver. That's not giving up, you found the right driver. Can you list the output of 'upsc' (see 'man upsc') to see what variables are supported and if the output looks right to you? Preferably with the contents of 'ups.conf' too, to see if any parameters need to be passed there? > If your still interested in the serial logging output i will be glad to > offer it to you. We don't need the serial logging anymore now that you've found a suitable driver. Apparently Sweex has switched over to yet another supplier (and monitoring software) for the 1000VA model, again without changing documentation (so that's lagging two versions behind now). I can't say I'm surprised. What we would like to know is as much information as possible on the labeling on the UPS and the software that came with it (although I guess there is not much more to tell about the latter) so that we can list this in the compatibility list. Best regards, Arjen ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] sweex 1000VA LB OB issue
> That's not giving up, you found the right driver. Can you list the output > of 'upsc' (see 'man upsc') to see what variables are supported and if the > output looks right to you? Preferably with the contents of 'ups.conf' too, > to see if any parameters need to be passed there? OK, we already saw that (our posts crossed). Best regards, Arjen ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] sweex 1000VA LB OB issue
> PS: why isn't "reply-to" set for NUT's lists? I keep forgetting and > replying only to the original poster instead of the list. Whether or not it is a good idea to setup the 'reply-to' address to that of a mailinglist has been discussed to death on many lists already. Don't ask. :-) Best regards, Arjen -- Eindhoven - The Netherlands Key fingerprint - 66 4E 03 2C 9D B5 CB 9B 7A FE 7E C1 EE 88 BC 57 ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] sweex 1000VA LB OB issue
Herman wrote: > The UPS itself has a blank Model.: number on the bottom and a little > sticker on its back stating: > 0761106 > UF-01V2EJX > KE11064267 > Made In China That is quite similar to a model I have here, but which runs with totally different software (safenet). Probably the people from Sweex can tell which one is which just looking at the labels, but I have the faint suspicion that they will not be eager to share this with us. > The packaging states MADE IN HOLLAND This merely describes the origin of the cardboard box I'm afraid... :-) > oh and it looks like this: > http://www.sweexeurope.com/media/prodimages/BC100020_img-pre_pro_a.jpg > > But then.. they all do ;) Indeed. We'll probably have to list all drivers that are known to work with these devices and let people figure out which one to use by just trying them out. From the pictures or model numbers there is no way to tell what you have. :-( Best regards, Arjen ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Network UPS Tools version 2.0.5 released
> I've tried with GenericUPS, had no luck (didn't get any response from the > driver at all indicating it was online (or that serial comms were > happening at all). I'll double check this more in the coming week, it's > possible I have a wrong cable or something. There will be no feedback, other than the OL OB LB status indication. The genericups 'protocol' just looks at modem status lines, there is nothing more to display. All other variables are just hardcoded. > It should be possible to test this with just the driver, manually, in > debug mode, right? No, without connecting a UPS this is useless. > Or have I been going about this all wrong? I guess. You'll *have* to connect a UPS, otherwise there is nothing to verify. We already know the genericups driver works with other UPS'es, so there is no need to check that. You need to check if it works with *your* UPS. Best regards, Arjen ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Network UPS Tools version 2.0.5 released
>> I guess. You'll *have* to connect a UPS, otherwise there is nothing to >> verify. We already know the genericups driver works with other UPS'es, >> so >> there is no need to check that. You need to check if it works with >> *your* >> UPS. > I have a UPS connected, I meant running the driver manually without > running upsd. You'd better start upsd too, in order to make upsc work (to query for the line status). Best regards, Arjen ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] "no longer stale" when disconnected with 2.0.5
[...] > I think this output doesn't help very much. This is very helpful. The problem is not in the connection to the driver, upd->data_ok switches between 0 and 1. Only the driver can change this value by repetitively switching between DATASTALE and DATAOK. There is nothing upsd can do about this, this is a driver problem. This is consistent with the observation that all people reporting similar problems are using the newhidups (or usbhid-ups) drivers. I can't reproduce this with the 'safenet' driver either (different UPS though). Could you run the driver with -D enabled to see why it is reporting this when the UPS is unplugged? > I have an additional problem with 2.1, "upscmd" doesn't work anymore. Please indicate the exact command that you're issuing. Possibly with the output of upsd with the -D option enabled (to see if it is receiving any commmand). Also, running 'upscmd -l ' may be helpful. Best regards, Arjen ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] "no longer stale" when disconnected with 2.0.5
[...] > I hope this small part of the log helps. Maybe someone with more experience with the 'usbhid-ups' driver is able to decipher what is going on. I'm still waiting for someone to send me a USB-HID UPS so that I can debug things like this myself. Best regards, Arjen ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
