Re: [Nut-upsuser] MACOSX-UPS Client/Server Communications Issues

2015-08-01 Thread AIYL
I’ve already completed the tests, setting up NUT in FreeBSD running in a Parallels virtual machine.Results:a.- Can you try 'upscups@10.0.2.151' from another system on the network?NUT Client running in FreeBSD connects to NUT server in OSX, upsc@10.0.2.151, output:battery.charge: 100battery.runtime: 480battery.voltage: 13.500device.mfr: (unknown)device.model: Back-UPS ES 550 FW:843.K2 .D USB FW:K2device.type: upsdriver.name: macosx-upsdriver.parameter.pollinterval: 2driver.parameter.port: autodriver.parameter.synchronous: nodriver.version: 2.7.3driver.version.internal: 1.1ups.status: OL CHRGb.- NUT Server setup in FreeBSD to test NAS’es NUT client connection to a server monitoring a “real “ UPS deviceBoth NAS’es ReadyNas and Synology have succesfully connected to the NUT server and correctly recognized the UPS deviceConclusions:a.- The OSX firewall is correctly setup to allow communications between the NUT server and the NUT clientsb.- The NAS’es NUT clients connection to a NUT Server in FreeBSD monitoring a “real” UPS device successfully identify the UPS device connected to the NUT server.See FreeBSD NUT server setup messages and NAS’es UPS screens attached.The NUT software running the driver MACOSX-UPS is a great and unique tool (I’ve found no other option able to manage my setup while using the OSX Power Management services), any further development effort will be of great value. For example to manage several networked Mac computers, while using the OSX Power Management Services in all of them.Thank you.Adolfo Yanesbattery.charge: 100
battery.charge.low: 10
battery.charge.warning: 50
battery.date: not set
battery.mfr.date: 2010/12/23
battery.runtime: 532
battery.runtime.low: 120
battery.type: PbAc
battery.voltage: 13.5
battery.voltage.nominal: 12.0
device.mfr: APC
device.model: Back-UPS ES 550
device.serial: 3B1052X38339  
device.type: ups
driver.name: usbhid-ups
driver.parameter.pollfreq: 30
driver.parameter.pollinterval: 2
driver.parameter.port: auto
driver.parameter.synchronous: no
driver.version: 2.7.3
driver.version.data: APC HID 0.95
driver.version.internal: 0.39
input.sensitivity: high
input.transfer.high: 139
input.transfer.low: 92
input.voltage: 122.0
input.voltage.nominal: 120
ups.beeper.status: enabled
ups.delay.shutdown: 20
ups.firmware: 843.K2 .D
ups.firmware.aux: K2 
ups.load: 38
ups.mfr: APC
ups.mfr.date: 2010/12/23
ups.model: Back-UPS ES 550
ups.productid: 0002
ups.serial: 3B1052X38339  
ups.status: OL
ups.timer.reboot: 0
ups.timer.shutdown: -1
ups.vendorid: 051d
Network UPS Tools - Generic HID driver 0.39 (2.7.3)
USB communication driver 0.32
Network UPS Tools - UPS driver controller 2.7.3
battery.charge: 100
battery.runtime: 480
battery.voltage: 13.500
device.mfr: (unknown)
device.model: Back-UPS ES 550 FW:843.K2 .D USB FW:K2
device.type: ups
driver.name: macosx-ups
driver.parameter.pollinterval: 2
driver.parameter.port: auto
driver.parameter.synchronous: no
driver.version: 2.7.3
driver.version.internal: 1.1
ups.status: OL CHRG
On Jul 28, 2015, at 10:10 PM, Charles Lepple clep...@gmail.com wrote:On Jul 28, 2015, at 12:13 PM, AIYL adliya...@gmail.com wrote:Before contacting Synology and Netgear/Readynas, I’d prefer to make sure that the NUT UPS Server has been setup correctly and that the “experimental” MACOSX-UPS driver is equivalent to a standard “usb” driver in terms of server/client communications.I flagged it "experimental" because the UPS-to-driver interface is not as robust as USB or serial, but that shouldn't affect the upsd-to-NAS connection. Once the driver starts, and assuming the UPS is not disconnected, things should work similarly to other drivers.Gracefully handling disconnection is a known issue for the macosx-ups driver, and it is also known that the information provided by OS X is less detailed than what you would get from usbhid-ups on a non-OSX system. Hopefully the latter is not causing an issue: the NAS should not be relying on anything other than "ups.status" and possibly a few other variables.
--Charles Leppleclepple@gmail


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

Re: [Nut-upsuser] MACOSX-UPS Client/Server Communications Issues

2015-07-28 Thread Charles Lepple
On Jul 28, 2015, at 12:13 PM, AIYL adliya...@gmail.com wrote:

 Before contacting Synology and Netgear/Readynas, I’d prefer to make sure that 
 the NUT UPS Server has been setup correctly and that the “experimental” 
 MACOSX-UPS driver is equivalent to a standard “usb” driver in terms of 
 server/client communications.

I flagged it experimental because the UPS-to-driver interface is not as 
robust as USB or serial, but that shouldn't affect the upsd-to-NAS connection. 
Once the driver starts, and assuming the UPS is not disconnected, things should 
work similarly to other drivers.

Gracefully handling disconnection is a known issue for the macosx-ups driver, 
and it is also known that the information provided by OS X is less detailed 
than what you would get from usbhid-ups on a non-OSX system. Hopefully the 
latter is not causing an issue: the NAS should not be relying on anything other 
than ups.status and possibly a few other variables.

-- 
Charles Lepple
clepple@gmail



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

Re: [Nut-upsuser] MACOSX-UPS Client/Server Communications Issues

2015-07-28 Thread Charles Lepple
 I’ve not been able to solve some issues regarding the communication between a 
 NUT Server running the MACOSX-UPS driver and the NUT clients on networked 
 NAS’es.
 
 NUT Software installed on a Macmini running OSX Yosemite has managed to 
 shutdown the networked devices, a Readynas and a Synology NAS, being all 
 devices powered by the same UPS.
 
 Network setup:
 
 Network UPS Management Software:
 NUT ver 2.7.3, installed via Fink Commander in Mac mini.
 Driver: MACOSX-UPS Ver 1.1
 
 Macmini running NUT Server connected via USB to the UPS:
 Model Name:   Mac mini mid 2011
 System Version:   OS X 10.10.4 (14E46)
   Kernel Version: Darwin 14.4.0
 
 UPS:
 APC Back-UPS 550 BE550G
 
 NAS #1:
 Model: Netgear ReadyNAS NV+ v1 [X-RAID]
 Firmware: RAIDiator 4.1.14 [1.00a043] 
 Memory: 1024 MB [2.5-3-3-7]
 
 NAS #2:
 Model name: Synology DS211j
 DSM version: DSM 5.2-5592 Update 1
 
 NUT Terminal commands and output:
 A-Mac-mini:~ admmacmini$ sudo /sw/sbin/upsdrvctl start
 Password:
 Network UPS Tools - UPS driver controller 2.7.3
 Network UPS Tools - Mac OS X UPS meta-driver 1.1 (2.7.3)
 Warning: This is an experimental driver.
 Some features may not function correctly.
 
 kill: No such process
 A-Mac-mini:~ admmacmini$ sudo /sw/sbin/upsd
 Network UPS Tools upsd 2.7.3
 kill: No such process
 /sw/etc/nut/upsd.conf is world readable
 listening on 10.0.2.151 port 3493
 listening on 127.0.0.1 port 3493
 /sw/var/run/ups is world readable
 Connected to UPS [ups]: macosx-ups-ups
 /sw/etc/nut/upsd.users is world readable
 A-Mac-mini:~ admmacmini$ upsc ups

Can you try 'upsc ups@10.0.2.151' from another system on the network? This will 
rule out any firewall issues on the Mac Mini.

 battery.charge: 42
 battery.runtime: 180
 battery.voltage: 13.010
 device.mfr: (unknown)
 device.model: Back-UPS ES 550 FW:843.K2 .D USB FW:K2
 device.type: ups
 driver.name: macosx-ups
 driver.parameter.pollinterval: 2
 driver.parameter.port: auto
 driver.parameter.synchronous: no
 driver.version: 2.7.3
 driver.version.internal: 1.1
 ups.status: OL CHRG
 A-Mac-mini:~ admmacmini$ 
 
 
 Comments:
 1.- The two NAS’es performed a shutdown after UPS power loss. Main objective 
 accomplished.
 
 
 2.- The Readynas acknowledges partial connection to the UPS server, the 
 following messages can be read:
 
 a.- Frontview Health Report
 See fig ‘A
 
 b.- Frontview Log
 See fig “B

Not sure what you mean by partial connection. The original screenshot in Fig. 
A said Remote Error, Battery charge: 42%, 3 minutes / Out of Spec, and Fig B. 
said UPS is on Battery Power / Communication with UPS OK. The text in Fig. A 
is not coming directly from NUT, so it is unclear what the issue is - you may 
want to check the Synology documentation, or ask their support group. (A 
battery.runtime value of 180 (3 minutes) seems short, but that's all I can 
think of.)

 
 3.- The Synology inconsistently acknowledges connection to the UPS server , 
 the following messages can be read:
 
 a.- Control Panel UPS setup menu
 See fig “C
 
Information: Cannot connect to the network UPS server

See comments above regarding 'upsc'.

 b.- Logs Report
 See fig “D

Those log messages are also not generated by NUT.

 
 4.- Although the communication problem between the UPS server and the NAS’es 
 NUT clients has not been solved, it doesn’t affect the main function, which 
 is to shutdown the NAS’es during a power loss of the UPS.
 
 
 I’ll appreciate any help in setting up the NUT server configuration to 
 improve the communication between the clients and the server.
 
 
 Thanks,
 
 Adolfo Yanes
 
 
 

-- 
Charles Lepple
clepple@gmail



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

Re: [Nut-upsuser] MACOSX-UPS Client/Server Communications Issues

2015-07-28 Thread AIYL
To your comments:

1.- Can you try 'upsc ups@10.0.2.151 mailto:ups@10.0.2.151' from another 
system on the network?
I’ve just one computer in the network, it’s my home's network. However, I can 
do the following:
a.- Turn-off the Macmini’s firewall. (Note: I’ve already added “upsd 
to the OSX Firewall's exceptions, otherwise nothing works)
b.- Test WinNut running in a Windows XP VM in Parallels, with its own 
IP address. (Already tested, it works with Firewall “on”)
c.- Setup a FreeBSD VM in Parallels, with its own IP address, to run a 
NUT client. It’ll take some more time than a) and b).

2.- ReadyNAs and Synology connection issues. 
You’re right, the messages are not coming directly from the NUT Server but the 
from the Nas’es NUT implementation. The NAS’es messages are inconsistent, at 
the same time, one screen reports Server Connection OK and another screen 
reports No Server Connection or Server Connection with errors”. That is the 
reason that I presume a “partial” or incomplete communication between the 
client and the server.


My hypothesis is that the NAS’es NUT client is expecting to get some 
information from the NUT Server, that it’s not getting. The problem could be 
caused by the NAS'es NUT client and/or by the NUT UPS server running the 
MACOSX-UPS driver.

I’m expecting that the FreeBSD VM test will result in some information that 
will help understand the communications problem's origin, it’ll allow to:
a.- Test a FreeBSD VM NUT client connection to the Macmini’s NUT 
Server. 'upsc ups@10.0.2.151 mailto:ups@10.0.2.151'
b.- Test the NAS’es client connection to a FreeBSD VM NUT Server, 
having a real UPS device connected to the VM’s USB port.

Before contacting Synology and Netgear/Readynas, I’d prefer to make sure that 
the NUT UPS Server has been setup correctly and that the “experimental” 
MACOSX-UPS driver is equivalent to a standard “usb” driver in terms of 
server/client communications.


It’ll be a later matter, to workout some issues regarding the different 
(hardcoded) NAS’es NUT client configurations, like different ups name, same 
user name and different password. Those issues have not impaired the main 
function of shutting down the NAS’es and do not seem to cause the 
communications issue, because modifying the NUT server configuration to match 
the NAS’es particular configuration does not result in different messages shown 
in the NAS’es console.

A “upsd -DD” output makes me think that the UPS client “login to the UPS 
server is not “necessary” for the client to shutdown, it seems that the client 
just needs to get “connected” to the server in order for the client to monitor 
the NUT UPS server’s “upsd”. Therefore, username and password matching doesn’t 
seem to be a “necessary” condition.
Regarding the ups name, I’m not sure if “ups name” matching is “necessary” or 
if just “ip address” matching is “enough” to establish the client/server 
communication, get connected”.
The latter, “ip address” matching, would be the most convenient way for the 
server to grant communication to the client because it’s configurable in both 
NAS’es.

Due to the NAS’es hardcoded configurations and constant firmware updates, those 
configuration issues seem to be much more difficult and less effective to be 
handled on the NAS’es side, therefore working on the NUT UPS server side to 
handle those issues would be much more effective.


I expect to have the FreeBSD VM test’s results in a couple weeks. 

Thank you.

Adolfo Yanes




 On Jul 28, 2015, at 6:56 AM, Charles Lepple clep...@gmail.com wrote:
 
 I’ve not been able to solve some issues regarding the communication between 
 a NUT Server running the MACOSX-UPS driver and the NUT clients on networked 
 NAS’es.
 
 NUT Software installed on a Macmini running OSX Yosemite has managed to 
 shutdown the networked devices, a Readynas and a Synology NAS, being all 
 devices powered by the same UPS.
 
 Network setup:
 
 Network UPS Management Software:
 NUT ver 2.7.3, installed via Fink Commander in Mac mini.
 Driver: MACOSX-UPS Ver 1.1
 
 Macmini running NUT Server connected via USB to the UPS:
 Model Name:  Mac mini mid 2011
 System Version:  OS X 10.10.4 (14E46)
   Kernel Version:Darwin 14.4.0
 
 UPS:
 APC Back-UPS 550 BE550G
 
 NAS #1:
 Model: Netgear ReadyNAS NV+ v1 [X-RAID]
 Firmware: RAIDiator 4.1.14 [1.00a043] 
 Memory: 1024 MB [2.5-3-3-7]
 
 NAS #2:
 Model name: Synology DS211j
 DSM version: DSM 5.2-5592 Update 1
 
 NUT Terminal commands and output:
 A-Mac-mini:~ admmacmini$ sudo /sw/sbin/upsdrvctl start
 Password:
 Network UPS Tools - UPS driver controller 2.7.3
 Network UPS Tools - Mac OS X UPS meta-driver 1.1 (2.7.3)
 Warning: This is an experimental driver.
 Some features may not function correctly.
 
 kill: No such process
 A-Mac-mini:~ admmacmini$ sudo /sw/sbin/upsd
 Network UPS Tools upsd 2.7.3
 kill: No such process
 /sw/etc/nut/upsd.conf is world readable
 listening on 10.0.2.151 port