Re: [Nut-upsdev] Patch for drivers.list

2009-07-29 Thread Charles Lepple

On Jul 29, 2009, at 5:26 AM, Svein Skogen (listmail account) wrote:


On a sidenote, I had a really hard time getting the usbhid-ups driver
working in FreeBSD running as a non-privileged user (even with
permissions on the /dev/ file set properly). Running it as root works,
though, so no biggie (I have the luxury of having the ups connected  
to a
dedicated box that is sufficiently fenced off from the rest of the  
network).


I don't have my FreeBSD box handy, but I seem to remember having to  
set permissions on both the bus (for libusb to enumerate the devices)  
and on the device's /dev node itself.


When it ran as a non-privileged user, the usbhid driver seemed to  
insist
on trying to load the generic driver, refusing to load the  
Cyberpower
one. As root, it loaded up the proper driver, and all is good. May  
just

be that my current FreeBSD-fu is low, or something.


Are you referring to the usbhid-ups driver for NUT, or the ugen  
generic USB driver in the kernel?


Also, what version of FreeBSD are you using?

___
Nut-upsdev mailing list
Nut-upsdev@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev


Re: [Nut-upsdev] Patch for drivers.list

2009-07-29 Thread Svein Skogen (listmail account)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Charles Lepple wrote:
 On Jul 29, 2009, at 5:26 AM, Svein Skogen (listmail account) wrote:
 
 On a sidenote, I had a really hard time getting the usbhid-ups driver
 working in FreeBSD running as a non-privileged user (even with
 permissions on the /dev/ file set properly). Running it as root works,
 though, so no biggie (I have the luxury of having the ups connected to a
 dedicated box that is sufficiently fenced off from the rest of the
 network).
 
 I don't have my FreeBSD box handy, but I seem to remember having to set
 permissions on both the bus (for libusb to enumerate the devices) and on
 the device's /dev node itself.

That I didn't try. I'll try it later (right now the weather here is too
unstable for me to consider messing with the UPS setup just when I might
need it). Thanks for the tip. (If this works, maybe it should be added
to some documentation?)

 When it ran as a non-privileged user, the usbhid driver seemed to insist
 on trying to load the generic driver, refusing to load the Cyberpower
 one. As root, it loaded up the proper driver, and all is good. May just
 be that my current FreeBSD-fu is low, or something.
 
 Are you referring to the usbhid-ups driver for NUT, or the ugen generic
 USB driver in the kernel?

the NUT driver. But that may, as you pointed to above, be that it
couldn't properly enumerate the bus.

 Also, what version of FreeBSD are you using?

RELENG_7 (currently in 7.2 stable)

//Svein

- --
- +---+---
  /\   |Svein Skogen   | sv...@d80.iso100.no
  \ /   |Solberg Østli 9| PGP Key:  0xE5E76831
   X|2020 Skedsmokorset | sv...@jernhuset.no
  / \   |Norway | PGP Key:  0xCE96CE13
|   | sv...@stillbilde.net
 ascii  |   | PGP Key:  0x58CD33B6
 ribbon |System Admin   | svein-listm...@stillbilde.net
Campaign|stillbilde.net | PGP Key:  0x22D494A4
+---+---
|msn messenger: | Mobile Phone: +47 907 03 575
|sv...@jernhuset.no | RIPE handle:SS16503-RIPE
- +---+---
 If you really are in a hurry, mail me at
   svein-mob...@stillbilde.net
 This mailbox goes directly to my cellphone and is checked
even when I'm not in front of my computer.
- 
 Picture Gallery:
  https://gallery.stillbilde.net/v/svein/
- 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkpwRBoACgkQODUnwSLUlKTpiQCbBta+jIL7+YsSB2rdEjXIqbXB
VP8AnjUKRt/HXAPWLadNj8twh7mUvgSO
=izQ3
-END PGP SIGNATURE-

___
Nut-upsdev mailing list
Nut-upsdev@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev


Re: [Nut-upsdev] [nut-commits] svn commit r1875 - in branches/AsciiDoc: . docs docs/icons

2009-07-29 Thread Charles Lepple

On Jul 29, 2009, at 8:39 AM, Arnaud Quette wrote:


btw, we will need 2 targets here:
- 1 for the documentation that will be shipped as part of the  
packages (HTML and optionally PDF),
- 1 for the website (ie the website specific part, including the  
homepage/news ; and the doc with a suitable layout for integrating  
to the website). The tricky part there is that I would like to have  
a separate file for the news, then included in the homepage.txt. so  
that we could then use the news.txt to serve an rss feed...


OK. I'll make two separate steps so that we can see at a glance if  
something breaks.



on that website side, we can start setting up the toolchain.
what I've in mind ATM is that you use your local buildbot to  
regenerate the dynamic part of the website, and an automated rsync  
on the Eaton webserver will pull these changes...


Sounds good.

Right now, our Buildbot configuration doesn't distinguish between  
trunk and branches, so there are broken links to non-existent  
documentation after trunk builds. I'll deal with that later.


In theory, this link should point to the latest generated documentation:

http://buildbot.ghz.cc/~buildbot/docs/latest/asciidoc.html

- Charles

___
Nut-upsdev mailing list
Nut-upsdev@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev


Re: [Nut-upsdev] Patch for drivers.list

2009-07-29 Thread Arnaud Quette
2009/7/29 Svein Skogen (listmail account) svein-listm...@stillbilde.net

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Charles Lepple wrote:
  On Jul 29, 2009, at 5:26 AM, Svein Skogen (listmail account) wrote:
 
  On a sidenote, I had a really hard time getting the usbhid-ups driver
  working in FreeBSD running as a non-privileged user (even with
  permissions on the /dev/ file set properly). Running it as root works,
  though, so no biggie (I have the luxury of having the ups connected to a
  dedicated box that is sufficiently fenced off from the rest of the
  network).
 
  I don't have my FreeBSD box handy, but I seem to remember having to set
  permissions on both the bus (for libusb to enumerate the devices) and on
  the device's /dev node itself.

 That I didn't try. I'll try it later (right now the weather here is too
 unstable for me to consider messing with the UPS setup just when I might
 need it). Thanks for the tip. (If this works, maybe it should be added
 to some documentation?)


sure, and even more knowing that we're working on the new shiny doc.
I'm also keen in automating the process, if possible, as for udev on Linux.

any hints / feedback is welcome since I'm not a *BSD user (simply due to a
lack of time, not of interest!)

cheers,
Arnaud
-- 
Linux / Unix Expert RD - Eaton - http://www.eaton.com/mgeops
Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org/
Debian Developer - http://www.debian.org
Free Software Developer - http://arnaud.quette.free.fr/
___
Nut-upsdev mailing list
Nut-upsdev@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev

Re: [Nut-upsdev] driver for IVT SCD solar controller ?

2009-07-29 Thread Arjen de Korte

Citeren Rainer Fuegenstein r...@kaneda.iguw.tuwien.ac.at:


There is a skeleton driver, and the rest
will be adapting to the SCD protocol.

according to the documentation on the NUT website, this shouldn't be
to hard [famous last words].


I already wrote an experimental 'ivtscd' driver. The source is  
available in the SVN trunk. Please let us know if this works for you.  
If not, make sure to post the output of


/path/to/ivtscd -DDD -a upsname

here so that we can fix remaining issues.

The driver allows you to override the build-in defaults for the power  
on and power off battery voltage by adding


default.battery.voltage.low = 10.80
default.battery.voltage.nom = 12.00

to 'ups.conf'. Note that I'm a little more conservative with the  
minimum battery voltage needed.


The driver also supports the 'reset.input.minmax' command to reset the  
minimum and maximum values reported by the controller.


Since you can't tell the controller to shutdown the load, the driver  
will hang around after


upsdrvctl shutdown

waiting for the battery voltage to return to nominal or the power  
being cut by the controller. This should be OK, since by the time this  
should be run, all file systems are mounted read-only. Note that after  
the driver exits, you need to call reboot in order to resume to normal  
operation, in a similar fashion as documented in the section on power  
races in docs/shutdown.txt.


Best regards, Arjen
--
Please keep list traffic on the list


___
Nut-upsdev mailing list
Nut-upsdev@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev


Re: [Nut-upsdev] driver for IVT SCD solar controller ?

2009-07-29 Thread Arjen de Korte

Citeren Rainer Fuegenstein r...@kaneda.iguw.tuwien.ac.at:


the serial ports on the atom mainboard are still not working, but today I
managed to connect the SCD to a different (centos 5) system and made the
following findings (via minicom) which may be of interest to you:

1) it is sufficient to just send the uppercase letter F (without cr/lf)


For the moment, I left these in (probably won't hurt).


2) this is what the output looks like:

R:12,57;- 1,1;20;12,57;13,18;- 2,1; 1,5;
R:12,57;- 1,0;20;12,57;13,18;- 2,1; 1,5;
R:12,57;- 1,1;20;12,57;13,18;- 2,1; 1,5;
R:12,57;- 1,1;20;12,57;13,18;- 2,1; 1,5;
R:12,57;- 1,1;20;12,57;13,18;- 2,1; 1,5;
R:12,57;- 1,1;20;12,57;13,18;- 2,1; 1,5;
R:12,57;- 1,2;20;12,57;13,18;- 2,1; 1,5;


Hmmm, this will require some simple reformatting of the data in order  
to extract the values. Done.



please note the blank between the minus sign and the actual value (but I
assume you're just using the first value which should never get negative).


No, we use whatever we get and map it to the appropriate NUT  
variables. You never know if someone finds a use for it. Especially  
the second value (actual current to/from the battery) is useful, since  
it allows us to see if the battery voltage (charge) tends to increase  
or decrease. If it is increasing, this is mapped to the NUT status OL  
(On Line), when it decreases OB (On Battery). You could set a timer on  
the ONBATT status to shutdown non-essential tasks when running on  
battery continuously for an hour or so for instance.



OK; please give me some time; I'll report back as soon as I got the first
test results.


I'll be on holiday a few days from now, but the driver is so simple  
someone else can pick it up if it needs changes (or you could do it  
yourself).


Best regards, Arjen
--
Please keep list traffic on the list


___
Nut-upsdev mailing list
Nut-upsdev@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev


Re: [Nut-upsdev] driver for IVT SCD solar controller ?

2009-07-29 Thread Rainer Fuegenstein

 1) it is sufficient to just send the uppercase letter F (without cr/lf)

 For the moment, I left these in (probably won't hurt).


I tested it (in 1887) without the cr/lf and in 1888 with cr/lf, but I
always get the following:

[...@helios drivers]$ ./ivtscd -DDD -a ivtscd
Network UPS Tools - IVT Solar Controller driver 0.01 (2.4.1-1888)
Warning: This is an experimental driver.
Some features may not function correctly.

   0.00 debug level is '3'
   0.001845 send: F
   0.364839 read:
   0.364937 IVT Solar Controller not detected

I checked the baud rate with stty and it is set to 1200, so this shouldn't
be the problem.

 No, we use whatever we get and map it to the appropriate NUT
 variables. You never know if someone finds a use for it. Especially
[...]
yes, that makes sense.

 I'll be on holiday a few days from now, but the driver is so simple
 someone else can pick it up if it needs changes (or you could do it
 yourself).
enjoy your vacation ! I'll dig into the source code tomorrow and see where
the response gets lost.

cu


___
Nut-upsdev mailing list
Nut-upsdev@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev