Charles Lepple
2014-Dec-23 20:00 UTC
[Nut-upsuser] NUT - Driver looks well, but connection from from client is lost or unavailable
[please use the nut-upsuser@ address rather than nut-upsuser-owner@ and be sure to use Reply-All - thanks!] On Dec 23, 2014, at 1:52 PM, Janez Kremzer <janez256 at gmail.com> wrote:> Hi! > > I woud like to use Raspberry Pi with NUT installed whic coud shut down NAS in the office. > NAS doesn't have comport and this is the reasion why not to use NAS directly. > > Today i spend almost all day with reading man nut, making serial cable, and configuring.... > At first was gone with progress but at the end i have not idea what goes wrong. I decided to write on this mailing list and i get a little help. > > > > Enviroment: > Raspberry Pi Model B+ 512MB RAM with 8GB SD Card, > > Raspbian Debian Wheezy 2014-09-09 - Kernel version: 3.12 from ISO image, > > ATEN USB TO RS232 UC232A (Debian found it without aditional driver) - I also tryed with RS232 to TTL but it works worse than USB converter, > > APC Smart-UPS SC450 RM (apcsmart driver documentation tell that this is new driver with only serial port), > > Home made 940-0024C cable tested by Windows PowerCute (UPS was recognised well without losing connections) > > > Instalation: > > I'm have little NUT experiance. Because of that was read that blog at the begining. > I made same installation of nut but without usb drivers at the begining. > > I setup apcsmart driver on port /dev/ttyUSB0 in ups.conf and check that runing user=root. >user=root is only for testing- this may cause other permissions problems later. I have been meaning to collect some information on using serial UPSes with NUT via USB-to-serial converters, but you can adapt the udev rules to match your converter, and even create a symlink so that it will not change names. (If a process has /dev/ttyUSB0 open, and the USB cable is unplugged, udev will create /dev/ttyUSB1 when it is next plugged in, which will not match the configuration file)> Then i test driver with that command: /lib/nut/apcsmart -D -a ups > > Results: > > Network UPS Tools - APC Smart protocol driver 3.04 (2.6.4) > APC command table version 3.0 > 0.000000 debug level is '1' > 0.051518 attempting firmware lookup using command 'V' > 0.112106 APC - attempting to find command set > 0.792347 APC - Parsing out supported cmds and vars > 1.822792 protocol_verify - APC: [d] unrecognized > 2.873615 APC - About to get capabilities string > 4.963132 supported capability: 75 (I) - input.transfer.high > 4.963474 supported capability: 6c (I) - input.transfer.low > 4.963678 supported capability: 65 (4) - battery.charge.restart > 4.963862 supported capability: 6f (I) - output.voltage.nominal > 4.964063 supported capability: 73 (4) - input.sensitivity > 4.964312 supported capability: 71 (4) - battery.runtime.low > 4.964514 supported capability: 70 (4) - ups.delay.shutdown > 4.964689 supported capability: 6b (4) - battery.alarm.threshold > 4.964853 supported capability: 72 (4) - ups.delay.start > 4.965061 supported capability: 45 (4) - ups.test.interval > 4.965258 APC - UPS capabilities determined > 4.965387 detected Smart-UPS SC450 RM [5S1004T68623] on /dev/ttyUSB0 > > I think that this looks ok.Agreed.> > Then i run that command: upsdrvctl start > > Results: > > Network UPS Tools - UPS driver controller 2.6.4 > Network UPS Tools - APC Smart protocol driver 3.04 (2.6.4) > APC command table version 3.0 > > I think that is this also ok.If you start the driver manually (especially with debug options), be sure to stop it before using the init scripts for the rest of NUT. This is an open issue: https://github.com/networkupstools/nut/issues/168> I finished configurations and i try to run a service. > Command: service nut-server start (command take some time around 20 s like driver) > > Results: > [....] Starting NUT - power devices information server and drivers: driver(s). [ ok. > > At the end i try to run client service. > > command: service nut-client start > > Results: > Broadcast Message from root at rasp > (somewhere) at 18:49 ... > > Communications with UPS ups at 127.0.0.1 lost > > > Broadcast Message from root at rasp > (somewhere) at 18:49 ... > > UPS ups at 127.0.0.1 is unavailable > > > This looks that client can't establish connection with the server but why? I checked all my configuration again but i didn't found errors. > > How can i found solution for that? > > p.s.: > > Also upsc command return error: "Error: Driver not connected"This means the driver is not talking to upsd. See previous comments about permissions and extra drivers. I can try to test this on a Pi later today.> > But how driver is not connected? I tested driver several time and everything was work. > > Kind regards, > Janez > > > > > > > > > > > > > > > > > > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20141223/18dc9b35/attachment.html>
Charles Lepple
2014-Dec-23 22:58 UTC
[Nut-upsuser] NUT - Driver looks well, but connection from from client is lost or unavailable
>> I setup apcsmart driver on port /dev/ttyUSB0 in ups.conf and check that runing user=root. >> > user=root is only for testing- this may cause other permissions problems later.It looks like the simplest way to handle this on Debian is to add the system 'nut' user to the 'dialout' group: $ sudo adduser nut dialout> I have been meaning to collect some information on using serial UPSes with NUT via USB-to-serial converters, but you can adapt the udev rules to match your converter, and even create a symlink so that it will not change names. (If a process has /dev/ttyUSB0 open, and the USB cable is unplugged, udev will create /dev/ttyUSB1 when it is next plugged in, which will not match the configuration file) >Just confirmed that the default udev rules for Raspbian wheezy will create some symlinks in /dev/serial/by-path and /dev/serial/by-id which should be useful. I have an inexpensive USB-to-serial cable which does not have a unique serial number, so I can only use one of that model at a time, and still uniquely identify it. But this is what it produces: $ ls -l /dev/serial/by-id/ total 0 lrwxrwxrwx 1 root root 13 Dec 31 1969 usb-Prolific_Technology_Inc._USB-Serial_Controller-if00-port0 -> ../../ttyUSB0 Although it is unwieldy, the pathnames under /dev/serial/by-id should always point to the correct /dev/ttyUSB? node. -- Charles Lepple clepple at gmail -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20141223/c1846b79/attachment.html>
Janez Kremzer
2014-Dec-24 07:51 UTC
[Nut-upsuser] NUT - Driver looks well, but connection from from client is lost or unavailable
Thanks a lot Charels. I just comment root user in usb.conf and add sudo adduser nut dialout. Now everything works well. Thanks again you save me a lot of time :) I wish all of you merry chrismas, Janez 2014-12-23 23:58 GMT+01:00 Charles Lepple <clepple at gmail.com>:> I setup apcsmart driver on port /dev/ttyUSB0 in ups.conf and check that > runing user=root. > > user=root is only for testing- this may cause other permissions problems > later. > > > It looks like the simplest way to handle this on Debian is to add the > system 'nut' user to the 'dialout' group: > > $ sudo adduser nut dialout > > I have been meaning to collect some information on using serial UPSes with > NUT via USB-to-serial converters, but you can adapt the udev rules to match > your converter, and even create a symlink so that it will not change names. > (If a process has /dev/ttyUSB0 open, and the USB cable is unplugged, udev > will create /dev/ttyUSB1 when it is next plugged in, which will not match > the configuration file) > > > Just confirmed that the default udev rules for Raspbian wheezy will create > some symlinks in /dev/serial/by-path and /dev/serial/by-id which should be > useful. > > I have an inexpensive USB-to-serial cable which does not have a unique > serial number, so I can only use one of that model at a time, and still > uniquely identify it. But this is what it produces: > > $ ls -l /dev/serial/by-id/ > total 0 > lrwxrwxrwx 1 root root 13 Dec 31 1969 > usb-Prolific_Technology_Inc._USB-Serial_Controller-if00-port0 -> > ../../ttyUSB0 > > Although it is unwieldy, the pathnames under /dev/serial/by-id should > always point to the correct /dev/ttyUSB? node. > > -- > Charles Lepple > clepple at gmail > > > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20141224/cbbfd6be/attachment-0001.html>