Re: [Nut-upsuser] Apple Mac slave

2017-06-14 Thread Charles Lepple
On Jun 14, 2017, at 9:12 AM, Robbie van der Walle  
wrote:
> 
> But I cannot load it with the command: 
> 
> $ sudo launchctl load /Library/LaunchAgents/com.networkupstools.upsmon.plist
> 
> /Library/LaunchAgents/com.networkupstools.upsmon.plist: Invalid property list
> 

I will try to look into this later, but three quick things:

1) does the base filename need to match the Label key? com.network... vs 
org.network...

2) maybe it doesn't like the comments (between "")?

3) should only need to go in /Library/LaunchDaemons  (LaunchAgents is to make 
it run at login, rather than system startup.)___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Unable to use nut-2.7.4 with Eaton 5E1500I USB

2017-06-14 Thread Manuel Wolfshant

Hello



On 06/14/2017 03:32 PM, Arnaud Quette wrote:



On Jun 7, 2017, at 5:47 AM, Manuel Wolfshant > wrote:



>
>If that matters, the OS is a fully updated CentOS 6.9
and this (latest stable ) version of nut was packaged by me.
The problem appears on any of the USB ports ( well, I tried
the 2 in front and one in the back of the server ).
>
> lsusb -v reports:
...
> wDescriptorLength 549
>  Warning: incomplete report descriptor
>  Report Descriptor: (length is 9)
>Item(Main  ): (null), data=none

Because both NUT and lsusb are having trouble retrieving the
HID Report Descriptor, I think the problem is at a lower
level: probably between the UPS, the kernel, and the USB HCI.
The archives have a number of unresolved emails about the 5E
and "broken pipe" errors.

Probably worth checking with Eaton, too.


Charles is right in both the fact that the issue is (or at least
seems to be) upstream to NUT, and also that it's worth checking
with "Eaton"


I've approached "them" ( apparently my request for supported
landed at after-sales support/Romania ) as soon as Charles
replied. Unfortunately the "dialogue" rather stalls, they seem to
have a policy to not send more than one email every 3 days.
Leaving aside that after telling them that I am using an *USB
*unit (and providing USB-related logs ) they wanted to know if I
was using *SNMP*.


no comments ;)

 still no reply from them ...




Could you please tell me your kernel

[root@belgrade ~]# uname -r
2.6.32-696.3.1.el6.x86_64


that may be part of the issue... long time I've not tried the 2.x 
series, not sure how it goes nowadays.

btw, any interesting "usb" messages from your syslog?
also, would you be able to test with a 3.x or 4.x, at least to see if 
that improves / solves the issue?


It's a bit tricky. I tried to use the kernel-lt package from the elrepo 
repository ( incidentally I am also part of the elrepo team but I am in 
charge with other packages, not the kernels ) and failed miserably. For 
reasons unknown to me ( and not logged ) the system failed to boot and a 
colleague from that office had to manually make it use the stock CentOS 
kernel ( typing what I was dictating to him over the phone .. )
Due to a complete lack of logs, I have absolutely no idea what happened 
and since the machine is critical for the activity there, I am a bit 
reluctant to try again





Would you also be able to test some github code?
We have the libusb-1.0 branch that provides both libusb 1.0
support (interesting to test to see if the problem still happens)
along with few other improvements (though these should not help
for your issue):
https://github.com/networkupstools/nut/tree/libusb-1.0



I can and I will test ( tomorrow, probably ).



I just packaged and tested it ( see below some comments, not important 
for my issue here )

Unfortunately there is no change in the output:

[root@belgrade ~]#u root -x explore -x vendorid="0463" -a eaton
Network UPS Tools - Generic HID driver 0.42 (2.7.4.1)
USB communication driver (libusb 0.1) 0.33
   0.00 [D1] debug level is '4'
   0.012088 [D1] upsdrv_initups...
   8.248213 [D2] Checking device (0463/) (002/004)
   9.249069 [D2] - VendorID: 0463
   9.249094 [D2] - ProductID: 
   9.249129 [D2] - Manufacturer: unknown
   9.249135 [D2] - Product: unknown
   9.249140 [D2] - Serial Number: unknown
   9.249145 [D2] - Bus: 002
   9.249151 [D2] - Device release number: 0001
   9.249156 [D2] Trying to match device
   9.249199 [D2] Device matches
   9.249209 [D2] failed to claim USB device: could not claim 
interface 0: Device or resource busy

   9.249373 [D2] detached kernel driver from USB device...
   9.249394 [D3] nut_usb_set_altinterface: skipped 
usb_set_altinterface(udev, 0)
   9.249991 [D2] Unable to get HID descriptor (error sending 
control message: Broken pipe)

   9.250002 [D3] HID descriptor length (method 1) -1
   9.250009 [D4] i=0, extra[i]=09, extra[i+1]=21
   9.250017 [D3] HID descriptor, method 2: (9 bytes) => 09 21 10 01 
21 01 22 25 02

   9.250023 [D3] HID descriptor length (method 2) 549
   9.250028 [D2] HID descriptor length 549
   9.250515 [D2] Unable to get Report descriptor: Broken pipe







Comments on the new tree:
a)there seem to be some missing files in the tree:
- some bits for augeas, devs and udev:
configure.ac:1526: required file `scripts/augeas/nutupsconf.aug.in' not 
found

configure.ac:1526: required file `scripts/devd/nut-usb.conf.in' not found
configure.ac:1526: required file 

Re: [Nut-upsuser] Apple Mac slave

2017-06-14 Thread Robbie van der Walle
> To be honest, I haven't experimented much with this, but I saw a normal 
> shutdown/reboot when I just tried this from the command line (10.12):
> 
> reboot~ Mon Jun 12 08:36 
> shutdown  ~ Mon Jun 12 08:35 
> clepple   ttys007   Sun Jun  4 21:52 - shutdown (7+10:43)

> However, the "-u" flag did not seem to keep the Mac running for long after 
> the shutdown (certainly seemed shorter than five minutes).

I have the same result showing a shutdown and reboot running manually. 
Also the shutdown was shorter than five minutes. 


> I also have to find a solution for starting up upsmon when the Mac starts

I never finished the integration for this branch, but...

https://github.com/networkupstools/nut/compare/osx_launchd 


You can save off the Raw file, and replace @SBINDIR@ with /sw/sbin or whatever:

https://github.com/networkupstools/nut/blob/161efce6c6fc32f205817ca71f8963af253cec59/scripts/launchd/org.networkupstools.upsmon.plist.in
 



I have made a file com.networkupstools.upsmon.plist. in /Library/LaunchDaemons 
and /Library/LauchAgents 

-rw-r--r--   1 root  wheel   708 Jun 14 14:59 com.networkupstools.upsmon.plist

But I cannot load it with the command: 

$ sudo launchctl load /Library/LaunchAgents/com.networkupstools.upsmon.plist

/Library/LaunchAgents/com.networkupstools.upsmon.plist: Invalid property list


com.networkupstools.upsmon.plist:


http://www.apple.com/DTDs/PropertyList-1.0.dtd;>



Label
org.networkupstools.upsmon
ProgramArguments

/sw/sbin/upsmon
-D 

RunAtLoad

KeepAlive

SuccessfulExit
 





Kind Regards,

Rob



> On 12 Jun 2017, at 14:42, Charles Lepple  wrote:
> 
> On Jun 11, 2017, at 7:15 AM, Robbie van der Walle  
> wrote:
>> 
>> I see only a reboot. Not a shutdown.  But is this normal because shutdown -u 
>> -h +0 is used? 
>> 
> To be honest, I haven't experimented much with this, but I saw a normal 
> shutdown/reboot when I just tried this from the command line (10.12):
> 
> reboot~ Mon Jun 12 08:36 
> shutdown  ~ Mon Jun 12 08:35 
> clepple   ttys007   Sun Jun  4 21:52 - shutdown (7+10:43)
> 
> However, the "-u" flag did not seem to keep the Mac running for long after 
> the shutdown (certainly seemed shorter than five minutes).
> 
> Maybe I can test this on another machine with the full NUT stack later.
> 
> Thanks for posting the osascript example - that looks useful!
> ___
> Nut-upsuser mailing list
> Nut-upsuser@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser



smime.p7s
Description: S/MIME cryptographic signature
___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Unable to use nut-2.7.4 with Eaton 5E1500I USB

2017-06-14 Thread Arnaud Quette
2017-06-13 17:49 GMT+02:00 Manuel Wolfshant :

> On 06/13/2017 05:48 PM, Arnaud Quette wrote:
>
> Hi Manuel
>
>
> Hi Arno
>
>
Hi Manuel

>
>
> 2017-06-07 14:40 GMT+02:00 Charles Lepple :
>
>> On Jun 7, 2017, at 5:47 AM, Manuel Wolfshant 
>> wrote:
>> >
>> >If that matters, the OS is a fully updated CentOS 6.9 and this
>> (latest stable ) version of nut was packaged by me. The problem appears on
>> any of the USB ports ( well, I tried the 2 in front and one in the back of
>> the server ).
>> >
>> > lsusb -v reports:
>> ...
>> >  wDescriptorLength 549
>> >  Warning: incomplete report descriptor
>> >  Report Descriptor: (length is 9)
>> >Item(Main  ): (null), data=none
>>
>> Because both NUT and lsusb are having trouble retrieving the HID Report
>> Descriptor, I think the problem is at a lower level: probably between the
>> UPS, the kernel, and the USB HCI. The archives have a number of unresolved
>> emails about the 5E and "broken pipe" errors.
>>
>> Probably worth checking with Eaton, too.
>>
>
> Charles is right in both the fact that the issue is (or at least seems to
> be) upstream to NUT, and also that it's worth checking with "Eaton"
>
>
> I've approached "them" ( apparently my request for supported landed at
> after-sales support/Romania ) as soon as Charles replied. Unfortunately the
> "dialogue" rather stalls, they seem to have a policy to not send more than
> one email every 3 days. Leaving aside that after telling them that I am
> using an *USB *unit (and providing USB-related logs ) they wanted to know
> if I was using *SNMP*.
>

no comments ;)

>
> Could you please tell me your kernel
>
> [root@belgrade ~]# uname -r
> 2.6.32-696.3.1.el6.x86_64
>

that may be part of the issue... long time I've not tried the 2.x series,
not sure how it goes nowadays.
btw, any interesting "usb" messages from your syslog?
also, would you be able to test with a 3.x or 4.x, at least to see if that
improves / solves the issue?


>
> and libusb (0.1) version?
>
> [root@belgrade ~]# rpm -qa libusb
> libusb-0.1.12-23.el6.x86_64
>
>
>
> Would you also be able to test some github code?
> We have the libusb-1.0 branch that provides both libusb 1.0 support
> (interesting to test to see if the problem still happens) along with few
> other improvements (though these should not help for your issue):
> https://github.com/networkupstools/nut/tree/libusb-1.0
>
> I can and I will test ( tomorrow, probably ).
>
>
> Don't hesitate if you need more guidance for trying this branch.
>
> Do you happen to know how can I find the version of firmware run by the
> UPS, in _my_ conditions ( remote + the previously mentioned errors) ?
>

don't bother too much, in the end, such request only get an answer once it
has reached me ;)


> The guys who contacted me from Eaton did not reply yet to my email sent
> yesterday.
>

that requires the driver to be running, then it's published as ups.firmware.
as per my upsc output above (in my case): ups.firmware: 02.06.0019


>
> FYI, I've just made a test with the same unit, on a Debian jessie (kernel
> 3.16.43-2, libusb 0.1.12-25) both with 2.7.4 and the latest git master, and
> it works fine:
>
> battery.charge: 62
> battery.runtime: 2725
> battery.type: PbAc
> device.mfr: EATON
> device.model: 5E 1500i
> device.type: ups
> driver.name: usbhid-ups
> [...]
>
> I was expecting it to work fine, given https://risc-a-day.blogspot.
> ro/2014/09/getting-my-ups-to-work-with-linux.html ( before the purchase I
> assumed the units to be similar, modulo the maximum power )
>

you shouldn't be that far...


>
> cheers,
> Arno
>
> thanks a lot. I will come back with more data once I test the github code
> ( yes, I know, everybody hates this kind of threats :) )
>

looking forward to get news so ;)

cheers,
Arno
-- 
Eaton Data Center Automation Solutions - Opensource Leader -
http://42ity.org
NUT (Network UPS Tools) Project Leader - http://www.networkupstools.org
Debian Developer - http://www.debian.org
Free Software Developer - http://arnaud.quette.fr
___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Help with Elite 800VA usb UPS

2017-06-14 Thread Andrea de Lutti
Hi, it's me again.
I haven't yet tested my UPS with full load, but I have tried to insert some
values in ups.conf, I have kept the example on the blazer_usb driver hel
page:

runtimecal = 240,100,720,50


When I try to start the driver, I receive

root@artu:~# upsdrvctl start
Network UPS Tools - UPS driver controller 2.7.2
Network UPS Tools - Megatec/Q1 protocol USB driver 0.11 (2.7.2)
Supported UPS detected with megatec protocol
Rating information unavailable
Vendor information unavailable
No values provided for battery high/low voltages in ups.conf

Using 'guestimation' (low: -0.87, high: -1.08)!
Initial battery charge undetermined
Driver failed to start (exit status=1)

What should I do?
Thanks again,

Andrea




2017-06-12 17:34 GMT+02:00 Andrea de Lutti :

> Thanks a lot, I will do it and keep you informed.
> Best regards
>
> Andrea
>
> 2017-06-12 12:34 GMT+02:00 Manuel Wolfshant :
>
>> On 06/12/2017 12:56 PM, Andrea de Lutti wrote:
>>
>>
>>
>>> > I have also successfully tested the battery...
>>> >
>>> >  upscmd -uadmin -pups Elit@artu test.battery.start.quick
>>>
>>> I would also recommend testing the shutdown procedure and making sure
>>> that everything works as expected on power failures.
>>> Please, let us know the results of these tests, so that we can add a
>>> more informed report about your device to our library
>>> (http://networkupstools.org/ddl/).
>>>
>>
>> ​Nice, I would like to test it, but if I don't have battery runtime value
>> and / or battery charge, how may I test it correctly?
>> I have seen also some strange values for battery.voltage.high and
>> battery.voltage.loware they correct?
>>
>> run with a test load   ( at least twice, for 50% and 100% load for
>> instance ) and write down the periods between full charge and shutdown.
>> Then you can use runtimecal in ups.conf to obtain guestimations during
>> normal usage
>>
>
>
___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser